References of Process_Models_for_Reverse_Design

@InProceedings{	  antonini.benedusi.ea:maintenance,
  author	= {P. Antonini and P. Benedusi and G. Cantone and Aniello
		  Cimitile},
  title		= {Maintenance and Reverse Engineering: Low Level Design
		  Documents Production and Improvement},
  booktitle	= {Proceedings of the  International Conference on Software
		  Maintenance ~1987},
  year		= {1987},
  pages		= {91-100},
  organization	= {IEEE},
  publisher	= {IEEE Computer Society Press},
  class		= {Software_Reverse_Engineering, Reverse_Design,
		  Process_Models_for_Reverse_Design}
}

@Article{	  canfora.cimitile.ea:reverse*2,
  title		= {A Reverse Engineering Process for Design Level Document
		  Production from ADA Code},
  author	= {G. Canfora and A. Cimitile and U. De Carlini},
  journal	= {Information and Software Technology},
  volume	= {35},
  number	= {1},
  pages		= {23--34},
  year		= {1993},
  note		= { A reverse engineering process for producing design level
		  documents by static analysis of ADA code is described. This
		  is achieved via concurrent data flow diagrams describing
		  the task structure and the data flow between tasks.},
  class		= {Software_Reverse_Engineering, Reverse_Design,
		  Fundamental_Methods_in_Reverse_Design, Static_Analysis,
		  Process_Models_for_Reverse_Design}
}

@InProceedings{	  debaud:dare,
  author	= {Jean-Marc DeBaud},
  title		= {DARE: Domain-Augmented ReEngineering},
  booktitle	= {Proceedings of the Fourth Working Conference on Reverse
		  Engineering},
  publisher	= {IEEE Computer Society Press Los Alamitos California},
  year		= {1997},
  editor	= {Ira Baxter and Alex Quilici and Chris Verhoef},
  abstract	= {We present in this article the principles of a
		  domain-augmented reengineering approach (DARE) as well as
		  our initial experience applying sections of it. The
		  principal characteristic of the DARE approach is its focus
		  upon the computational context of a software system i.e.
		  the business or scientific domain to which it relates. This
		  context information is used both to drive the program
		  understanding as well as for the program evolution phases
		  of reengineering. In DARE a domain model (concepts and
		  associated relationships) serves as the structure denoting
		  context and is used for two purposes. First a dictionary of
		  possible domain concept realizations is populated. Second a
		  set of mappings from the domain to an existing tool or
		  library related to the domain is defined. Reengineering
		  then proceeds as follows: First a legacy system is analyzed
		  and annotated with the dictionary of domain concept
		  realizations. Then these matched concepts are transitioned
		  to the tool or library using the predefined mapping set.
		  Program evolution can then take place at the level of the
		  tool or library. Using our initial experience we discuss
		  DARE present an analysis and suggest implications for
		  future work.},
  class		= {Software_Evolution Software_Reverse_Engineering
		  Model_Generating Reverse_Specification Reverse_Design
		  Domain_Analysis Process_Models_for_Reverse_Design
		  Knowledge-Based_Concept_Assignmen }
}

@TechReport{	  kamper.rugaber:reverse,
  author	= {Kit Kamper and Spencer Rugaber},
  title		= {A Reverse Engineering Methodology for Data Processing
		  Applications},
  number	= {GIT-SERC-90/02},
  institution	= {Software Engineering Center Georgia Institute of
		  Technology, Atlanta, GA},
  year		= {1990},
  month		= mar,
  note		= {Figures are missing},
  abstract	= {Reverse engineering produces a high-level representation
		  of a software system from a low-level one. This paper
		  describes a methodology for reverse engineering that
		  constructs an architectural design for a system from its
		  source code and related documentation. The methodology
		  makes use of several techniques normally used during the
		  forward software development process as well as a new
		  technique called Synchronized Refinement. Synchronized
		  Refinement is a systematic approach to detecting design
		  decisions in source code and relating the detected
		  decisions to the functionality of the system. Examples are
		  given demonstrating the application of the methodology to
		  the reverse engineering of a production software system.},
  ftp		= {ftp.cc.gatech.edu//pub/groups/reverse/repository/synchronized.ps}
		  ,
  class		= {Software_Reverse_Engineering, Reverse_Design,
		  Process_Models_for_Reverse_Design,
		  Software_Reverse_Engineering, Reverse_Design,
		  Fundamental_Methods_in_Reverse_Design}
}

@InProceedings{	  ornburn.rugaber:reverse,
  title		= {Reverse engineering: resolving conflicts between expected
		  and actual software designs},
  author	= {S. Ornburn and S. Rugaber},
  booktitle	= {\cite{SM92}},
  pages		= {32--40},
  year		= {1992},
  note		= { Experience report describing the application of the
		  Synchronized Refinement method ~\cite{ROL90} to a real-time
		  embedded system},
  class		= {Software_Reverse_Engineering, Reverse_Design,
		  Process_Models_for_Reverse_Design}
}