References of General_Information_about_Reverse_Design

@Article{	  britcher.craig:using,
  author	= {Robert N. Britcher and James J. Craig},
  title		= {Using Modern Design Practices to Upgrade Aging Software
		  Systems},
  journal	= {IEEE Software},
  year		= {1986},
  pages		= {16-24},
  month		= may,
  class		= {Software_Reverse_Engineering, Reverse_Design,
		  General_Information_about_Reverse_Design}
}

@Article{	  rugaber.ornburn.ea:recognizing,
  author	= {Spencer Rugaber and Stephen B. Ornburn and Richard J.
		  LeBlanc, jr.},
  title		= {Recognizing Design Decisions in Programs},
  journal	= {IEEE Software},
  year		= {1990},
  volume	= {7},
  number	= {1},
  pages		= {46-54},
  month		= jan,
  abstract	= {The importance of capturing design decisions is described.
		  Design desicions are categorized in (1) composition and
		  decomposition (2) encapsulation and interleaving (3)
		  generalization and specialization (4) representation (5)
		  data and procedures (6) function and relation.
		  
		  The detection of design decision is bottom-up and
		  incremental with the following activities: (1) interleaving
		  program fragments (2) representing structured control flow
		  (3) interleaving by code sharing (4) data interleaving by
		  reusing variable names (5) generalizing code (6) variable
		  introduction (7) describing program architecture.
		  
		  The found decisions should be represented. A representation
		  should: (1) be easy to construct during development (2) be
		  easy to reconstruct during reverse engineering (3)
		  facilitate queries and report generation (4) be formal
		  enough to being automatically manipulated (5) let all
		  design information be attached (high level specification,
		  architectural overviews, detailed interfaces, resulting
		  code) (6) support requirements tracing, informal
		  annotations, version information.},
  ftp		= {ftp.cc.gatech.edu//pub/groups/reverse/repository/software.ps.gz}
		  ,
  note		= {In this paper it is advocated that in order to effectively
		  maintain an existing system, the maintenance programmer
		  must be able to sustain decisions made earlier in the
		  design process. To accomplish this, she/he must be able to
		  recognize and understand this decisions. A way is given to
		  characterize such decisions},
  class		= {Software_Reverse_Engineering, Reverse_Design,
		  General_Information_about_Reverse_Design}
}

@InProceedings{	  rugaber.stirewalt.ea:interleaving,
  author	= {Spencer Rugaber and Kurt Stirewalt and Linda M. Wills},
  title		= {The Interleaving Problem in Program Understanding},
  booktitle	= {2nd Working Conference on Reverse Engineering},
  address	= {Toronto, Ontario, Canada},
  month		= jul,
  year		= {1995},
  abstract	= {One of the factors that can make a program difficult to
		  understand is that code responsible for accomplishing more
		  than one purpose may be woven together in a single section.
		  We call this interleaving, and it may arise either
		  intentionally - for example, in optimizing a program, a
		  programmer may use some intermediate result for several
		  purposes - or unintentionally, dut to patches, quick fixes,
		  or other hasty maintenance practices. To understand this
		  phenomenon, we have looked at a variety of interleaving
		  instances in actual programs and have distilled
		  characteristic features. If the characterization proves to
		  be robust then it will enable the design of tools for
		  detection of interleavings and the extraction of the
		  individual strands of computation.},
  ftp		= {ftp.cc.gatech.edu//pub/groups/reverse/repository/interleaving.ps}
		  ,
  class		= {Software_Reverse_Engineering, Reverse_Design,
		  General_Information_about_Reverse_Design}
}

@Article{	  rugaber:program,
  author	= {Spencer Rugaber},
  title		= {Program Understanding},
  journal	= {Encyclopedia of Computer Science and Technology},
  year		= {1996},
  note		= {To Appear},
  abstract	= {Program comprehension is the process of acquiring
		  knowldege about a computer program. Increased knowledge
		  enables such activities as bug correction, enhancement,
		  reuse, and documentation. While efforts are underway to
		  automate the understanding process, such significant
		  amounts of knowledge and analytical power are required that
		  today program understanding is largely a manual task.
		  
		  This paper explaines relationship to other activities such
		  as reverse engineering, design recovery, and reengineering.
		  It answers the question why program understanding is that
		  difficult. It gives a brief overview about human and
		  automated program understanding and program comprehension
		  tools.},
  ftp		= {ftp.cc.gatech.edu//pub/groups/reverse/repository/encyc.draft.ps}
		  ,
  class		= {Software_Reverse_Engineering, Reverse_Design,
		  General_Information_about_Reverse_Design}
}