References of Fundamentals

@InProceedings{	  arnold:software*1,
  author	= { R.S. Arnold },
  title		= { Software Restructuring: Foundation for Reengineering },
  booktitle	= { Proceedings of the Reverse Engineering Forum, {\rm
		  (Washington University, St. Louis, Missouri)}},
  year		= { 1990 },
  month		= {April},
  abstract	= { see Arnold's book },
  class		= {Reengineering_in_General, Fundamentals }
}

@Article{	  biggerstaff:design,
  author	= {Ted J. Biggerstaff},
  title		= {Design Recovery for Maintenance and Reuse},
  journal	= {IEEE Computer},
  year		= {1989},
  volume	= {22},
  number	= {7},
  pages		= {36-49},
  month		= jul,
  abstract	= {Design recovery recreates design abstractions from a
		  combination of code, existing design documentation,
		  personal experience, and general knowledge about problem
		  and application domains. The recovered design abstractions
		  must include conventional software engineering
		  representations such as formal specifications, module
		  breakdowns, data abstractions, dataflows, and program
		  description languages. In addition, they must include
		  informal linguistic knowledge about problem domains,
		  application idioms, and the world in general. Automated
		  design recovery needs a knowledge base - a domain model -
		  that captures expertise. The design recovery process
		  consists of three steps: (1) supporting program
		  understanding for maintenance: (1.a) What are the modules?
		  (1.b) What are the key data items? (1.c) What are the
		  software engineering artifacts? (1.d) What are the other
		  informal design abstractions? (1.e) What is the relation of
		  the design abstractions to the code? (2) supporting
		  population of reuse and recovery libraries: The design
		  abstractions of the former step are generalized and
		  integrated into the reuse library and the recovery
		  knowledge base (the domain model). (3) applying the results
		  of design recovery: The abstract design components stored
		  in the domain model now become the starting point for
		  discovering candidate concrete realizations of themselves
		  in a new system's code. \end{enumerate}
		  
		  Two key properties distinguish this design recovery model
		  from similar models: use of informal information and use of
		  a domain model. The domain model is knowledge base of
		  expectations expressed as patterns of program structures,
		  problem domain structures, language structures, naming
		  conventions etc.
		  
		  A model-based design recovery system, called DESIRE, that
		  is partially implemented as a prototype is presented.
		  Related work is described. },
  note		= {Design recovery uses the source code of a system as well
		  as external information, such as documentation, personal
		  experience, and knowledge of problem and application
		  domain, to make a higher level abstraction. The key
		  property is the formalization of informal information and
		  domain knowledge},
  class		= {Reengineering_in_General, Fundamentals}
}

@InProceedings{	  byrne:conceptual,
  title		= {A conceptual foundation for software re-engineering},
  author	= {E. Byrne},
  pages		= {226--235},
  booktitle	= {Proceedings of the  International Conference on Software
		  Maintenance ~1992},
  year		= {1992},
  note		= { A conceptual foundation for software reengineering is
		  presented yielding a general model of software
		  reengineering. This model is described and is shown to be
		  useful for examining reengineering issues such as the
		  reengineering process and strategies for reengineering},
  class		= {Reengineering_in_General, Fundamentals}
}

@InProceedings{	  byrne:conceptual*1,
  author	= {Eric J. Byrne},
  title		= {A Conceptual Foundation for Software Re-engineering},
  pages		= {216-235},
  booktitle	= {Proceedings of the  International Conference on Software
		  Maintenance ~1992},
  year		= {1992},
  publisher	= {IEEE Computer Society Press},
  month		= nov,
  abstract	= {This paper presents a conceptual foundation for software
		  re-engineering. The foundation is composed of properties
		  and principles that underlie reengineering methods, and
		  assumptions about reengineering. The value of this
		  conceptual foundation is its ability to model our
		  understanding of reengineering, how it is praticed, and how
		  it can be practiced. A general model of software
		  re-engineering is established, based on this foundation.
		  This model, along with its underlying foundation, proves
		  useful for examinining re-engineering issues such as the
		  re-engineering process and re-engineering strategies.},
  class		= {Reengineering_in_General, Fundamentals}
}

@InProceedings{	  byrne:conceptual*2,
  author	= {Eric J. Byrne},
  title		= {A Conceptual Foundation for Software Re-engineering},
  booktitle	= {Proceedings of the 1992 Conference on Software Maintenance
		  (CSM~'92), {\rm (Orlando, Florida; November 9-12, 1992)}},
  year		= {November 1992},
  publisher	= {IEEE Computer Society Press (Order Number 2980)},
  abstract	= { . levels of abstraction: . conceptual, requirements,
		  design, implementation . separation of concerns: for each
		  level of abstraction there exists a system representation
		  that explicitly describes a system's characteristics. each
		  level of abstraction defines a different set of
		  characteristics . information inclusion: information
		  contained within a level of abstraction influences
		  information contained at lower abstraction levels;
		  information contained within a level of abstraction has no
		  influence on information contained at higher levels of
		  abstraction [I disagree with this...] . information volume:
		  as the level of abstraction descreases, the amount of
		  information describing a system increases },
  class		= {Reengineering_in_General, Fundamentals }
}

@Article{	  chikofsky.cross:reverse,
  key		= {Chikofsky \& Cross},
  author	= {Elliot J. Chikofsky and James H. Cross II},
  title		= {Reverse Engineering and Design Recovery: A Taxonomy},
  pages		= {13--17},
  journal	= {IEEE Software},
  year		= {1990},
  month		= jan,
  note		= {Definitions of a number of key notions in the field of
		  reverse engineering are proposed. Forward and reverse
		  engineering, redocumentation, design recovery,
		  restructuring, and reengineering are described},
  class		= {Reengineering_in_General, Fundamentals}
}

@TechReport{	  holdbrook.tebaut:survey,
  author	= {H. B. Holdbrook and S. M. Tebaut},
  title		= {A Survey of Software Maintenance Tools that Enhance
		  Program Understanding},
  institution	= {Software Engineering Research Center, University of
		  Florida/ Purdue University},
  year		= {1987},
  number	= {SERC-TR-9-F},
  class		= {Reengineering_Tools, Software_Reverse_Engineering,
		  Software_Reverse_Engineering_Tools,
		  Reengineering_in_General, Fundamentals}
}

@InProceedings{	  maiocchi:reengineering,
  author	= {M. Maiocchi},
  title		= {Reengineering: Can a Program Put Intelligence in Stupid
		  Programs?},
  booktitle	= {Proceedings of the 12th  International Conference on
		  Software Engineering },
  pages		= {123--124},
  month		= mar,
  year		= {1990},
  abstract	= {The reengineering of old programs is approached as a
		  purely technical problem. The relevance of organizational
		  aspects is pointed out, and the needed tools are indicated.
		  The ideal environment should allow the description of the
		  structure of the organization; the description of the
		  software development cycle; the description of the
		  procedural rules for configuration, version, and change
		  management and control; a collection of tools for measuring
		  properties of the software; tools for helping in decisions
		  on the basis of the measures obtained on a product; and a
		  collection of tools for supporting technical activities
		  (specifications, design, coding, debugging, etc.).},
  class		= {Reengineering_in_General, Fundamentals}
}

@Misc{		  n:special,
  author	= {N.N.},
  key		= {Case Outlook},
  title		= {Special Issue on ''Case Tools for Reverse Engineering''},
  journal	= {Case Outlook},
  volume	= {2},
  number	= {2},
  pages		= {1-15},
  year		= {1988},
  class		= {Reengineering_Tools, Software_Reverse_Engineering,
		  Software_Reverse_Engineering_Tools,
		  Reengineering_in_General, Fundamentals}
}

@Article{	  rekoff:on,
  title		= {On reverse engineering},
  author	= {M. Rekoff},
  journal	= {{IEEE} Transactions on Systems, Man and Cybernetics},
  volume	= {3/4},
  pages		= {244-252},
  year		= {1985},
  note		= { This paper is a tutorial on reverse engineering that
		  defines some key notions},
  class		= {Reengineering_in_General, Fundamentals}
}

@Article{	  schneidewind:introduction,
  title		= {Introduction to the special section on software
		  maintenance},
  author	= {N. Schneidewind},
  journal	= {{IEEE} Transactions on Software Engineering},
  volume	= {{SE}-13},
  number	= {3},
  pages		= {301},
  year		= {1987},
  note		= { This preface introduces a special section on software
		  maintenance},
  class		= {Reengineering_in_General, Fundamentals}
}

@Article{	  schneidewind:state,
  title		= {The state of software maintenance},
  author	= {N. Schneidewind},
  journal	= {{IEEE} Transactions on Software Engineering},
  volume	= {{SE}-13},
  number	= {3},
  pages		= {303--310},
  year		= {1987},
  note		= { An overview of the state of the art in software
		  maintenance and criticizes the apparent disinterest in the
		  research field is provided},
  class		= {Reengineering_in_General, Fundamentals}
}

@Article{	  sharon:reverse,
  key		= {Sharon},
  author	= {David Sharon},
  title		= {A Reverse and Re--Engineering Tool Classification Scheme},
  pages		= {Rev-3--Rev5},
  journal	= {Reverse Engineering Newsletter},
  year		= {1990},
  month		= {},
  inhalt	= { Eine Taxonomie für Werkzeuge des Reverse Engineerings
		  wird angegeben.
		  
		  1. Existierende Systeme Untersucht wird ein vorhandenes
		  System auf der Code-Ebene und Informationen auf höherer
		  Abstraktionsebene zur Verfügung gestellt.
		  
		  1.1 Enhancement Die Werkzeuge unterstützen das Verständnis
		  eines Programmes, bevor es geändert wird.
		  
		  1.2 Assessment Der Quellcode des Systems wird bezüglich
		  Industriemetriken vermessen.
		  
		  1.3 Conditioning Die Werkzeuge automatisieren den
		  Verbesserungsproze/3 eines Systems. Oft wird Quellcode in
		  eine strukturierte Form transformiert.
		  
		  2.0 Repository Load/Enhancement and Reconciliation Daten-
		  und proze/3bezogener Quellcode wird gelesen und übersetzt
		  in das Informationsmodell eines anderen Zielrepository. },
  class		= {Reengineering_Tools, Software_Reverse_Engineering,
		  Software_Reverse_Engineering_Tools,
		  Reengineering_in_General, Fundamentals}
}

@Book{		  zuylen:redo,
  title		= {The {R}e{D}o compendium: reverse engineering for software
		  maintenance},
  editor	= {Zuylen, H. van},
  publisher	= {Wiley},
  year		= {1993},
  note		= {Gives an overview of the results of the REDO project and
		  covers most aspects of reverse engineering. Various
		  approaches are discussed: (a) compilation of COBOL programs
		  to equational specifications, restructuring and
		  simplification of these specifications, and regeneration of
		  COBOL code from them; (b) compilation of COBOL to UNIFORM,
		  an intermediate language supporting all features of both
		  COBOL and JCL; (c) compilation of COBOL to COBOL-IF, a
		  simplified syntactic representation of COBOL programs; (d)
		  abstraction of the meaning of COBOL code in the form of Z++
		  specifications. Various experimental tools providing
		  partial support for the above techniques are discussed. The
		  results described in this book should be considered as
		  useful experiments. Since the techniques have not been
		  applied to a number of large scale projects the method does
		  not yet constitute a mature reverse engineering
		  methodology},
  class		= {Reengineering_in_General, Fundamentals}
}