References of Reengineering_in_General

@Article{	  adams:measuring,
  author	= { N. Adams },
  title		= { Measuring Maintenance Productivity and Quality },
  journal	= { Software Engineering },
  volume	= { 2(5) },
  year		= { July/August 1991 },
  pages		= { 5-13 },
  abstract	= { see Arnold's book },
  class		= {Reengineering_in_General, Costs }
}

@InProceedings{	  aebi:re-engineering,
  author	= {Daniel Aebi},
  title		= {Re-Engineering, Migration and Multi-Use of business Data},
  booktitle	= {1st  European Conference on Software Maintenance and
		  Reengineering 97},
  month		= mar,
  year		= {1997},
  publisher	= {IEEE Computer Society Press},
  abstract	= {},
  class		= {Reengineering_in_General, Process_Models}
}

@Article{	  ahrens.prywes:transition,
  author	= {J. D. Ahrens and N. S. Prywes},
  title		= {Transition to a Legacy- and Reuse-Based Software Life
		  Cycle},
  journal	= {IEEE Computer},
  pages		= {27-36},
  year		= {1995},
  month		= oct,
  class		= {Reengineering_in_General, Process_Models}
}

@Article{	  albee.shekleton:business,
  author	= {Albee, Kim and Shekleton, John},
  title		= {Business Re-Engineering and Information Systems: An
		  Opportunity for Business Partnership},
  journal	= {CASE Outlook},
  year		= {1992},
  volume	= {6(4)},
  pages		= {25-34},
  class		= {Reengineering_in_General, Business_Reengineering }
}

@Article{	  andrews:systems,
  author	= { D.C. Andrews },
  title		= { Systems Re-engineering: A Critical Perspective },
  journal	= { CASE Trends },
  year		= { July/August 1990 },
  pages		= { 15-16 },
  abstract	= { see Arnold's book },
  class		= {Reengineering_in_General,
		  The_Pros_and_Cons_and_Risks_of_Reengineering }
}

@InProceedings{	  antonini.canfora.ea:re-engineering,
  author	= {P. Antonini and G. Canfora and Aniello Cimitile},
  title		= {Re-engineering Legacy Systems to Meet Quality
		  Requirements: An Experience Report},
  booktitle	= {Proceedings of the  International Conference on Software
		  Maintenance ~1994},
  year		= {1994},
  pages		= {146-153},
  publisher	= {IEEE Computer Society Press},
  month		= sep,
  abstract	= {The paper is a summary of a third party re-engineering
		  project aiming to adjust a legacy system to the new quality
		  standard established by the customer. The quality standard
		  is defined in the form of a set of metrices each associated
		  with a range of acceptable values. A set of 100 programs
		  has been restructured and modularised to meet the quality
		  requirements. When possible, automated tools have been used
		  in order to reduce the costs, standadise the results, and
		  ease the transfer of techniques and methodologies to the
		  customer. The re-engineered programs habe replaces the
		  orginal versions in the customer production environment.
		  Their quality, and in particular their understandability
		  and maintainability, is considerably increased as confirmed
		  by the customer's technical personnel.
		  
		  The work described here is a preliminary step towards the
		  definition of a larger re-engineering project to bring the
		  customer's software portfolio into line with the new
		  quality standard.},
  class		= {Reengineering_in_General, Experiences}
}

@InProceedings{	  antonini.canfora.ea:reengineering,
  author	= { P. Antonini and G. Canfora and A. Cimitile },
  title		= { Reengineering Legacy Systems to Meet Quality
		  Requirements: An Experience Report },
  booktitle	= { Proceedings of the International Conference on Software
		  Maintenance {\rm (Victoria, B.C., Canada; September 19-23,
		  1994)} },
  year		= { 1994 },
  editor	= { Hausi A. M\"{u}ller and Mari Georges },
  pages		= { 146-153 },
  class		= {Reengineering_in_General, Experiences }
}

@InProceedings{	  arango.baxter.ea:maintenance,
  author	= {Guillermo Arango and Ira Baxter and Peter Freeman},
  title		= {Maintenance and Porting of Software by Design Recovery},
  booktitle	= {CSM'85: Proceedings of the 1985 Conference on Software
		  Maintenance, {\rm (Washington, DC; November 11-13, 1985)}},
  year		= {November 1985},
  pages		= {42-49},
  abstract	= {DRACO paper on porting through transformation from source
		  code to abstraction back to new code. Captures
		  domain-specific knowledge.},
  class		= {Reengineering_in_General, Experiences, Alteration,
		  Re-Code, Program_Transformations,
		  Software_Reverse_Engineering, Reverse_Design,
		  Knowledge-Based_Concept_Assignment,
		  Human_Oriented_Concept_Assignment_by_Informal_Reasoning },
  keywords	= {domain modeling, domain analysis, DRACO}
}

@Article{	  arango.baxter.ea:tmm*1,
  author	= {Guillermo Arango and Ira Baxter and Peter Freeman and
		  Christopher Pidgeon},
  title		= {{TMM}: Software Maintenance by Transformation},
  journal	= {IEEE Software},
  month		= {May},
  year		= {1986},
  volume	= {3},
  number	= {3},
  pages		= {27-39},
  abstract	= { . Another DRACO-based paper. . Uses least common
		  abstractions. },
  keywords	= {domain modeling, domain analysis, DRACO},
  class		= {Reengineering_in_General, Experiences, Alteration,
		  Re-Code, Program_Transformations,
		  Software_Reverse_Engineering, Reverse_Design,
		  Knowledge-Based_Concept_Assignment,
		  Human_Oriented_Concept_Assignment_by_Informal_Reasoning}
}

@Book{		  arango.prieto-diaz:domain,
  editor	= {Guillermo Arango and Rub\'{e}n Prieto-D\'{i}az},
  title		= {Domain Analysis and Software Systems Modelling},
  year		= {1991},
  publisher	= {IEEE Computer Society Press (Order Number 1996)},
  abstract	= {},
  class		= {Reengineering_in_General, Reengineering_Collections},
  keywords	= {domain modeling, domain analysis, DRACO}
}

@Article{	  arnold.frakes:software,
  author	= {Robert S. Arnold and V. B. Frakes},
  title		= {Software Reuse and Reengineering},
  journal	= {Case Trends},
  year		= {1992},
  volume	= {4},
  number	= {2},
  pages		= {44-48},
  class		= {Reengineering_in_General,
		  The_Pros_and_Cons_and_Risks_of_Reengineering}
}

@Article{	  arnold:common,
  author	= {Robert S. Arnold},
  title		= {Common Risks of Reengineering},
  journal	= {Reverse Engineering Newsletter},
  year		= {1992},
  pages		= {Rev-1 -- Rev-2},
  month		= apr,
  class		= {Reengineering_in_General,
		  The_Pros_and_Cons_and_Risks_of_Reengineering}
}

@Article{	  arnold:common*1,
  author	= { R.S. Arnold },
  title		= { Common Risks of Reengineering },
  journal	= { Reverse Engineering Newsletter },
  year		= { April 1992 },
  pages		= { Rev.1-Rev.2 },
  abstract	= { },
  class		= {Reengineering_in_General,
		  The_Pros_and_Cons_and_Risks_of_Reengineering }
}

@InProceedings{	  arnold:risks,
  author	= { R.S. Arnold },
  title		= { Risks of Reengineering },
  booktitle	= { Proceedings of the Reverse Engineering Forum, {\rm
		  (Washington University, St. Louis, Missouri)}},
  year		= { April 1991 },
  abstract	= { see Arnold's book },
  class		= {Reengineering_in_General,
		  The_Pros_and_Cons_and_Risks_of_Reengineering }
}

@Book{		  arnold:software,
  author	= {R.S. Arnold},
  title		= {Software Reengineering},
  publisher	= {IEEE Computer Society Press},
  year		= {1993},
  note		= {In this book an introduction to software reengineering is
		  provided. Context and definitions of key notions are
		  included. Then various subjects are treated in the form of
		  a collection of papers that are reprinted from other
		  sources. Subjects that we can find are: business process
		  reengineering, the connection with economics, experiences
		  with real-life reengineering projects, evaluation of tools
		  used in such projects, the technological aspects of
		  reengineering, data reengineering and its migration
		  problems, source code analysis, restructuring and
		  translation, the annotation and documentation of existing
		  programs, reusability aspects, design recovery, the object
		  oriented approach to recovery, program understanding, and
		  knowledge based program analysis. This book contains an
		  annotated bibliography},
  class		= {Reengineering_in_General, Reengineering_Collections}
}

@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 }
}

@Book{		  arnold:software*2,
  author	= {R.S. Arnold},
  title		= {Software Reengineering},
  year		= {1993},
  publisher	= {IEEE Computer Society Press},
  class		= {Reengineering_in_General, Reengineering_Collections }
}

@Article{	  arnold:software*3,
  author	= { R.S. Arnold },
  title		= { Software Restructuring },
  journal	= { Proceedings IEEE },
  year		= { 1989 },
  month		= {April},
  pages		= { 607-617 },
  abstract	= { },
  class		= {Reengineering_in_General, Reengineering_Collections }
}

@Article{	  arnold:software*4,
  author	= { Robert S. Arnold },
  title		= { Software Reengineering: A Quick History },
  journal	= { Communications of the ACM },
  volume	= { 37(5) },
  pages		= { 13-14 },
  year		= { May 1994 },
  class		= {Reengineering_in_General, Experiences }
}

@Book{		  arnold:tutorial,
  editor	= {Robert S. Arnold},
  title		= {Tutorial on software restructuring},
  year		= {1986},
  publisher	= {IEEE Computer Society Press (Order Number 680)},
  abstract	= {},
  class		= {Reengineering_in_General, Reengineering_Collections }
}

@InProceedings{	  arnold:tutorial*1,
  author	= {R.S. Arnold},
  title		= {Tutorial on Software Reengineering},
  booktitle	= {CSM'90: Proceedings of the 1990 Conference on Software
		  Maintenance, {\rm (San Diego, California; November 26-29,
		  1990)}},
  year		= {1990},
  month		= {November},
  publisher	= {IEEE Computer Society Press (Order Number 2091)},
  abstract	= {},
  class		= {Reengineering_in_General, Reengineering_Collections }
}

@InProceedings{	  b-w-weide.hollingsworth:reverse,
  author	= {B. W. Weide, W. D. Heym and J. E. Hollingsworth},
  title		= {Reverse Engineering of Legacy Code Exposed},
  booktitle	= {Proceedings of the 17th  International Conference on
		  Software Engineering },
  publisher	= {IEEE Computer Society Press},
  pages		= {327-331},
  year		= {1995},
  month		= apr,
  class		= {Reengineering_in_General}
}

@InProceedings{	  bar.bauer.ea:sanierung,
  author	= {Holger B{\"a}r and Markus Bauer and Oliver Ciupke and
		  Thomas Gen{\ss}ler and Radu Marinescu and Benedikt Schulz
		  and Joachim Weisbrod},
  title		= {{S}anierung objektorientierter {S}ysteme},
  booktitle	= {Proceedings of the 1st German Workshop on
		  Software-Reengineering},
  editor	= {J{\"u}rgen Ebert and Bernt Kullbach and Franz Lehner},
  series	= {Fachberichte Informatik},
  year		= {1999},
  organization	= {Universit{\"a}t Koblenz-Landau, Institut f{\"u}r
		  Informatik},
  month		= jul,
  address	= {Bad Honnef, Germany},
  pages		= {53--58},
  class		= {Reengineering_in_General, Experiences}
}

@Booklet{	  bar.ciupke.ea:famoos,
  title		= {The Famoos Handbook of Reengineering},
  author	= {Holger B{\"a}r and Oliver Ciupke and Serge Demeyer and
		  St{\'e}phane Ducasse and Radu Marinescu and Robb Nebbe and
		  Tamar Richner and Matthias Rieger and Benedikt Schulz and
		  Sander Tichelaar and Joachim Weisbrod},
  year		= {1998},
  month		= sep,
  class		= {Reengineering_in_General, Introductions_to_Reengineering}
}

@Article{	  bartholemew:charles,
  author	= { D. Bartholemew },
  title		= { Charles Schwab: Bullish on Reengineering },
  journal	= { Information Week },
  year		= { July 22, 1991 },
  pages		= { 12-13 },
  abstract	= { see Arnold's book },
  class		= {Reengineering_in_General,
		  The_Pros_and_Cons_and_Risks_of_Reengineering }
}

@Article{	  basili:viewing,
  title		= {Viewing maintenance as reuse oriented software
		  development},
  author	= {V. Basili},
  journal	= {{IEEE} Software},
  volume	= {7},
  number	= {1},
  pages		= {19--25},
  year		= {1990},
  note		= { In this paper the maintenance process is incorporated in
		  the life-cycle perspective geared towards the reusability
		  of the various components},
  class		= {Reengineering_in_General, Process_Models,
		  Software_Reverse_Engineering, Re-Use}
}

@Article{	  baumöhl.borchers.ea:einordnung,
  author	= {Ulrike Baumöhl and Jens Borchers and Stefan Eicker and
		  Knut Hildebrand and Reinhard Jung and Franz Lehner},
  title		= {Einordnung und Terminologie des Software Reengineering},
  journal	= {Informatik-Spektrum},
  year		= {1996},
  volume	= {19},
  pages		= {191-195},
  month		= {},
  class		= {Reengineering_in_General, Introductions_to_Reengineering}
}

@Article{	  belady.lehman:model,
  author	= {L. A. Belady and M. M. Lehman},
  title		= {A model of large program development},
  journal	= {IBM Systems Journal},
  year		= {1976},
  volume	= {15},
  pages		= {225-252},
  class		= {Reengineering_in_General, Process_Models }
}

@Article{	  benander.benander:empirical,
  author	= { A.C. Benander and B.A. Benander },
  title		= { An Empirical Study of Cobol Programs via a Style
		  Analyzer: The Benefits of Good Programming Style },
  journal	= { Journal of Systems and Software },
  volume	= { 10 },
  year		= { 1989 },
  pages		= { 271-279 },
  abstract	= { see Arnold's book },
  class		= {Reengineering_in_General, Experiences }
}

@Article{	  bendifallah.scacci:understanding,
  author	= {S. Bendifallah and W. Scacci},
  key		= {Bendifallah & Scacci},
  journal	= {IEEE Transactions on Software Engineering},
  title		= {Understanding Software Maintenance Work},
  year		= {1987},
  month		= mar,
  volume	= {SE-13},
  number	= {3},
  pages		= {311--323},
  kommentars	= {Allgemeine Betrachtung ueber Ablaeufe bei der Wartung von
		  Programmen},
  location	= {E & S Library},
  class		= {Reengineering_in_General, Introductions_to_Reengineering}
}

@Article{	  benedusi.cimitile.ea:reverse*1,
  author	= {P. Benedusi and A. Cimitile and U. {De~Carlini}},
  title		= {Reverse Engineering Processes, Design Document Production,
		  and Structure Charts},
  journal	= {The Journal of Systems and Software},
  year		= {1992},
  month		= {November},
  volume	= {19(3)},
  pages		= {225-24},
  abstract	= {},
  class		= {Reengineering_in_General, Process_Models }
}

@InProceedings{	  benedusi.cimitile.ea:reverse*2,
  author	= {P. Benedusi and A. Cimitile and U. {De~Carlini}},
  title		= {A Reverse Engineering Methodology to Reconstruct
		  Hierarchical Data Flow Diagrams for Software Maintenance},
  booktitle	= {Proceedings of the IEEE Conference on Software
		  Maintenance},
  year		= {October 1989},
  pages		= {180-189},
  abstract	= {},
  class		= {Reengineering_in_General, Process_Models}
}

@Article{	  bennett:automated,
  author	= { K.H. Bennett },
  title		= { Automated support of software maintenance },
  journal	= { Information and Software Technology },
  volume	= { 33 },
  number	= { 1 },
  month		= { February },
  year		= { 1991 },
  pages		= { 74-85 },
  abstract	= { . Detailed defn of SM; maintaining and producing
		  maintainable systems; describe ReForm, MACS, and REDO, (the
		  latter is a set of integrable tools to support RE) },
  class		= {Reengineering_in_General }
}

@Article{	  bennett:legacy,
  author	= {Keith Bennett},
  title		= {Legacy Systems: Coping with Success},
  journal	= {IEEE Software},
  year		= {1995},
  volume	= {12},
  number	= {1},
  pages		= {19-23},
  month		= {January},
  class		= {Reengineering_in_General, Introductions_to_Reengineering}
}

@Article{	  bergland:guided,
  author	= {G. D. Bergland},
  title		= {A guided tour of program design methodologies},
  journal	= {Computer},
  year		= {October 1981},
  pages		= {18-37},
  volume	= {14(10)},
  abstract	= {},
  class		= {Reengineering_in_General, Process_Models }
}

@Article{	  berlinger:reengineering,
  author	= { S. Berlinger },
  title		= { Reengineering: Leveraging Your CASE Investment },
  journal	= { American Programmer },
  volume	= { 3(10) },
  year		= { October 1990 },
  pages		= { 21-26 },
  abstract	= { see Arnold's book },
  class		= {Reengineering_in_General }
}

@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}
}

@Article{	  boehm:spiral,
  author	= {Barry W. Boehm},
  title		= {A Spiral Model of Software Development and Enhancement},
  journal	= {Computer},
  year		= {May 1988},
  pages		= {61-72},
  abstract	= {Seminal paper on the spiral model, which advocates a
		  series of prototypes and risk analysis steps.},
  class		= {Reengineering_in_General, Process_Models }
}

@TechReport{	  botsford.caldiera.ea:1992,
  key		= {Botsford et. al, 1992},
  author	= {J.E. Botsford and G. Caldiera and G.E. Kaiser and M.I.
		  Kellner and N.H. Madhavji},
  title		= {The 1992 Report on The Process Reuse Study (PRS) in CAS},
  institution	= {IBM Canada Ltd. Laboratory, Centre for Advanced Studies},
  year		= {1992},
  number	= {TR 74.106},
  address	= {895 Don Mills Road, North York, Ontario, Canada M3C 1W3},
  month		= nov,
  class		= {Reengineering_in_General, Process_Models}
}

@InProceedings{	  branch.jackson.ea:software,
  author	= {Mike A. Branch and M. Clay Jackson and Mark C. Laviolette
		  and Eric C. Frankel},
  title		= {Software Maintenance Management},
  booktitle	= {CSM'85: Proceedings of the 1985 Conference on Software
		  Maintenance, {\rm (Washington, DC; November 11-13, 1985)}},
  year		= {November 1985},
  pages		= {62-67},
  abstract	= {Advocates SM as change control, CM, and communication
		  among team members. Use maintenance procedures from other
		  disciplines.},
  class		= {Reengineering_in_General, Management }
}

@InProceedings{	  brice:existing,
  author	= { L. Brice },
  title		= { Existing Computer Applications. Maintain or Redesign: How
		  to Decide? },
  booktitle	= { Proceedings of the Computer Measurement Group },
  year		= { December 1981 },
  pages		= { 20-28 },
  abstract	= { see Arnold's book },
  class		= {Reengineering_in_General,
		  The_Pros_and_Cons_and_Risks_of_Reengineering }
}

@Article{	  britcher.craig:using*1,
  author	= {Robert N. Britcher and James J. Craig},
  year		= {May 1986},
  journal	= {IEEE Software},
  pages		= {16-24},
  title		= {Using Modern Design Practices to Upgrade Aging Software
		  Systems},
  volume	= {3(3)},
  abstract	= {},
  class		= {Reengineering_in_General, Process_Models }
}

@Article{	  britcher:re-engineering,
  author	= {Robert N. Britcher},
  year		= {1990},
  journal	= {IBM Systems Journal},
  pages		= {551-567},
  title		= {Re-engineering Software: A Case Study},
  volume	= {29(4)},
  abstract	= {},
  class		= {Reengineering_in_General, Experiences }
}

@Book{		  brodie.stonebraker:migrating,
  author	= {M.L. Brodie and M. Stonebraker},
  title		= {Migrating Legacy Systems --- Gateways, Interfaces \& The
		  Incremental Approach},
  publisher	= {Morgan Kaufmann Publishers, Inc.},
  year		= {1995},
  note		= {This book gives a detailed description of strategies for
		  migrating legacy systems. It advocates an incremental
		  approach for the migration instead of doing it in {\em one}
		  step. The legacy system is analyzed and the components to
		  be updated are identified. The legacy system and the new
		  system work in parallel and are connected via gateways.
		  Migrated components are removed from the legacy system and
		  added to the new system. The crucial steps in this process
		  are establishing the right ordering of the components to be
		  migrated and the use of powerful gateways. It is preferable
		  not to develop these gateways yourself but to obtain them
		  from third party software producers. A number of
		  case-studies is presented and these case-studies
		  demonstrate that these gateways are crucial even if all the
		  code of the legacy system becomes obsolete. The book
		  concludes with an extensive list of third party software
		  producers which produce gateways},
  class		= {Reengineering_in_General, Experiences, Alteration,
		  Re-Design}
}

@Book{		  brodie.stonebreaker:migrating,
  author	= { Michael L. Brodie and Michael Stonebreaker },
  title		= { Migrating Legacy Systems },
  publisher	= { Morgan Kaufmann },
  year		= { 1995 },
  class		= {Reengineering_in_General }
}

@Article{	  brooks-jr-:no,
  author	= {Frederick P. {Brooks Jr.}},
  title		= {No Silver Bullet: Essence and Accidents of Software
		  Engineering},
  journal	= {IEEE Computer},
  year		= {April 1987},
  volume	= {20(4)},
  pages		= {10-19},
  abstract	= {},
  class		= {Reengineering_in_General,
		  The_Pros_and_Cons_and_Risks_of_Reengineering }
}

@Article{	  bush:reverse,
  author	= { E. Bush },
  title		= { Reverse Engineering: What and Why },
  journal	= { American Programmer },
  volume	= { 3(10) },
  year		= { October 1990 },
  pages		= { 1-7 },
  abstract	= { see Arnold's book },
  class		= {Reengineering_in_General,
		  The_Pros_and_Cons_and_Risks_of_Reengineering}
}

@Article{	  buss.de-mori.ea:investigating,
  author	= {E. Buss and R. {De~Mori} and M. Gentleman and J. Henshaw
		  and H. Johnson and K. Kontogiannis and E. Merlo and H.
		  M\"{u}ller and J. Mylopoulos and S. Paul and A. Prakash and
		  M. Stanley and S. Tilley and J. Troster and K. Wong},
  title		= {Investigating Reverse Engineering Technologies: The CAS
		  Program Understanding Project},
  journal	= {IBM Systems Journal},
  volume	= {33(3)},
  year		= {February 1994},
  pages		= {477-500},
  abstract	= {},
  class		= {Reengineering_in_General, Experiences }
}

@TechReport{	  buss.henshaw:experiences,
  key		= {Buss \& Henshaw, 1992},
  author	= {Erich Buss and John Henshaw},
  title		= {Experiences in Program Understanding},
  institution	= {IBM Canada Ltd. Laboratory, Centre for Advanced Studies},
  year		= {1992},
  number	= {TR 74.105},
  address	= {895 Don Mills Road, North York, Ontario, Canada M3C 1W3},
  month		= jul,
  class		= {Reengineering_in_General, Experiences}
}

@InProceedings{	  buss.henshaw:experiences*1,
  author	= {Erich Buss and John Henshaw},
  title		= {Experiences in Program Understanding},
  booktitle	= {{CASCON'92}: Proceedings of the 1992 CAS Conference, {\rm
		  (Toronto, Ontario; November 9-12, 1992)}},
  year		= {November 1992},
  pages		= {157-189},
  publisher	= {IBM Canada Ltd.},
  abstract	= {},
  class		= {Reengineering_in_General, Experiences }
}

@TechReport{	  buss.henshaw:experiences*2,
  author	= {Erich Buss and John Henshaw},
  title		= {Experiences in Program Understanding},
  institution	= {IBM Software Solutions Toronto Laboratory Centre for
		  Advanced Studies},
  number	= {TR-74.105},
  year		= {July 1992},
  abstract	= { . Early version of their CASCON'92 paper. },
  class		= {Reengineering_in_General, Experiences }
}

@TechReport{	  buss.henshaw:software,
  key		= {Buss \& Henshaw, 1991},
  author	= {Erich Buss and John Henshaw},
  title		= {A Software Reverse Engineering Experience},
  institution	= {IBM Canada Ltd. Laboratory, Centre for Advanced Studies},
  year		= {1991},
  number	= {TR 74.065},
  address	= {895 Don Mills Road, North York, Ontario, Canada M3C 1W3},
  month		= sep,
  class		= {Reengineering_in_General, Experiences}
}

@InProceedings{	  buss.henshaw:software*1,
  author	= {Erich Buss and John Henshaw},
  title		= {A Software Reverse Engineering Experience},
  booktitle	= {Proceedings of CASCON~'91, {\rm (Toronto, Ontario; October
		  28-30, 1991)}},
  year		= {October 1991},
  pages		= {55-73},
  publisher	= {IBM Canada Ltd.},
  abstract	= { . Introduction . Ongoing need for adaptive, perfective,
		  and corrective maintenance . Maintainer must try to
		  understand the intent of the original author without the
		  benefit of his or her advice and guidance. . Most
		  production software in the marketplace can be characterised
		  as being in the maintenance phase of the software life
		  cycle. . Maintain the product's "conceptual integrity"
		  while operating under traditional time, productivity, and
		  quality-related objectives. . Reverse engineering:
		  terminology and concepts . Definition of RE, FE,
		  redocumentation(*), design recovery, restructuring,
		  re-engineering, PU . Diagram showing relationship between
		  terms and life-cycle phases. . Reverse engineering concepts
		  . PU takes place within the context of an "application
		  problem domain" and an "environmental domain." (Fodder for
		  thesis and D-R RE.) . Application PD employs specialised
		  terminology and paradigms, which determine software
		  artifact representations; application semantics
		  (implementation language, terminology, business rules, ...)
		  . Environmental semantics (OS, type of hardware,
		  configuration, ...) . Since RE is an open-ended,
		  context-dependent activity, it is important that toolkits
		  be similarly open-ended, flexible, extensible, and
		  versatile. . RE is "a solution looking for a problem": the
		  appplication of this technology requires a real-world
		  problem on which to focus. . Why is RE difficult? . Lists
		  10 reasons why (from another paper [11]). . (Use this as
		  introductory material in my thesis, "The problem.") . When
		  to re-engineer? . Lists 11 key indicators (from another
		  paper [2]). . The PU project . Integrate new FE technology
		  into existing "legacy" software. . Three options: (1) stay
		  the course; (2) replace part or all; (3) PU . The right
		  customer . Opportunity to use SQL/DS as the "real world"
		  subject system. . Successful RDBMS with a traditional
		  maintenance history. . Developers working under demanding
		  quality-related objectives, and are eager to take advantage
		  of new technologies. . SQL/DS is a proprietary IBM product,
		  therefore COTS tools not suitable. . They opted for REFINE
		  since it allows the requisite product-specific
		  customization (D-R RE): a customizable toolkit was a
		  necessity. . Their initial focus was on error detection. .
		  They hoped this would be integrated into the SQL/DS
		  maintenance process. . The SQL/DS product . SQL/DS:
		  Structured Query Language/Data System. . Uses many concepts
		  originally created in System R [15]. . They include a
		  useful diagram showing evolution of SQL/DS, from System R
		  (1976, PL/I, VM, prototype), to SQL/DS V1.0 (1982, PL/S,
		  190K, VM/SP, PP), to SQL/DS V3.2 (1991, PL/AS, >500K
		  (2.3M), VM/SP,VM/XA,VM/ESA,VSE, PP). . Erich says 2,079,369
		  lines of PL/AS in 1,147 modules (without comments); with
		  comments, 4,485,488 lines of PL/AS, over 247M of source
		  code! . Hence, SQL/DS is now 12 years old, and over two
		  million lines of code (in expanded form); it has code that
		  is 18 years old in it from System R. . Runs on S/370, but
		  several different OS's; mandates dual-path code which must
		  be maintained in sync. . There are about 8,000 SQL/DS
		  licenses worldwide (1991) (Probably more now with DB2 and
		  DB2/6000). . Implemented in PL/AS, a proprietary PL/I-like
		  dialect allowing imbedded S/370 assembler. A "close to the
		  metal" systems PL. Hence, COTS tools not applicable to
		  PL/AS. . SQL/DS has roughly 1,150 compile units, roughly
		  partitioned into three large units (and several smaller
		  ones). Clearly, this amount of code is far greater than any
		  individual can comprehend by themselves. It is necessary
		  for the developer to specialise in a particular component,
		  despite the fact that the various components interact! .
		  Application data "flows" through global data structures,
		  and is manipulated in concert by many different software
		  modules. . The devloper looks at code that is over 90\%
		  control logic, but the compiler sees over 90\% as data
		  structure declarations, placed in shared files and
		  \%INCLUDE'd. . Efficiency (speed) is of paramount
		  importance, especially given the industry-wide perception
		  that relational databased are sluggish. . They have too
		  much documentation: too much to maintain, and too much to
		  pissibly read and digest. . It is a typical legacy code
		  system: successful, mature, supporting an existing customer
		  base while growing in terms of supported environments and
		  functionality. . Good quote from Lehman and Belady paper
		  [18] on degenerating software structure as maintenance
		  continues. . The RE toolkit . Most application problem
		  domains have unique and specialised characteristics, thus
		  RE toolkits must be extensible and versatile. . it is
		  highly unlikely that a "turn key" reverse engineering
		  package will suffice for many users. Maybe this is why CASE
		  tools are better at FE than RE. Even the most sophisticated
		  CASE tools are currently capable of accepting only general
		  data definitions. . The tools and toolkit affects the way
		  you think about the problem domain [E. Dijkstra]. . Should
		  should know either exactly what you want to accomplish, or
		  you should place a premium on toolkit flexibility. . They
		  chose the Software Refinery by Reasoning Systems Corp. .
		  They include a diagram describing the three pieces of the
		  SF: DIALECT (for parsing), REFINE (the OO-DB), and
		  INTERVISTA (the UI). . (Note that given this breakdown, we
		  have similar pieces, and could concievable
		  replace/integrate Rigi with the SF's components). .
		  (Include such a diagram in the paper, but for Rigi.) .
		  DIALECT requires a grammar for the input PL nd a domain
		  model (a description of the object base, i.e. how the AST
		  should look like). It includes a reverse-parser which can
		  produce code out of the db. . The core of the SF is the
		  REFINE specification language, a multi-paradigm HLL. It has
		  the syntax of LISP (in fact, it gets translated to LISP to
		  run on the underlying LISP system), but included
		  Prolog-like logic, sets, and so on. . A significant major
		  feature of the SF is its extensiblity; this has been
		  demonstrated by its capability to integrate into various
		  commerical application domains (which ones?). . DIALECT =
		  rigireverse REFINE = rigiserver/rigiedit INTERVISTA =
		  rigiedit . A software RE experience . Their ultimate goal
		  was the qualitative and quantitative improvement of the
		  SQL/DS base code and maintenance process. . They key is
		  analysis, and they use the SF to convert the SQL/DS code
		  into something that is tractable and can be manipulated. .
		  They were guided (somewhat) by SQL/DS management to direct
		  their research to specific problem areas. . They spent
		  considerable time creating a parser for PL/AS: it is
		  context-sensitive, there is no formal grammer (there are
		  several dialects), and the imbedded assembler complicates
		  matters. They first built a special scanner to recognize
		  multiple symbols for the same keyword, skipping the
		  imbedded assembler and PL/AS listing format directives. .
		  They have a full-page process diagram of PL/AS on VM to SF
		  population. . (We need to include a similar picture, and
		  rationale as to why it is so much simpler.) . When they
		  encountered bizarre parsing errors, they went back and
		  fixed the source (it turned out to be wrong in some way
		  anyhow). . They found several errors in the source just
		  while testing their parser. . (It would be nice to get a
		  copy of the reports they submitted to SQL.) . One of their
		  most clearly stated conclusions is that any RE toolkit must
		  be extensible to meet your problem domain. . Future
		  directions . Stuff to work on (in increasing order of
		  difficulty). . (Address some of these issues in my thesis!)
		  . Static analysis. (Some of my work). . Code standard
		  checker (IBM Watson work); allow partially automated code
		  inspections against a specified standard. They considered
		  this the most promising area for immediate future work. .
		  Code flow analysis. The extraction of this information from
		  a single module is "easy"; representing and presenting this
		  information is hard. . Data flow/Structure analysis: map
		  the data structures and their relationships. Especially
		  important for SQL/DS due to its use of global data
		  structures to pass information, causing increased
		  complexity. . Test case generation. . Create REFINE/PLAS,
		  similar to REFINE/C and REFINE/FORTRAN. (These are examples
		  of instantiated D-RE RE environments for a specific
		  application domain.) . Performance analysis and tuning. .
		  Redundant code identification. . Program transformation. .
		  Program translation: produce a C equivalent of the PL/AS
		  source to SQL/DS. . Program reuse and generation. . Summary
		  and conclusions . Software maintenance is an economic
		  survival issue. . The PU project is analysis-oriented. .
		  Must control and minimise maintenance costs, understand
		  embedded business rules. . RE is not a well-understood
		  concept. In addition to the introduction of the basic
		  terminology, it is essential to manage the expectations of
		  the approach; many expectations in the area are
		  unrealistic. . Key is the conversion from source code to a
		  more tractable medium; they chose the SF's object base. (I
		  choose Rigi views, and must allow the user to choose others
		  as well.) . Mention "software archeologists," and offer an
		  interesting analogy: archeologists cannot usually
		  (after-the-fact) ask "why" something is the way it is, and
		  are forced to invent rational models for the existence of
		  particular artifacts. RE's have much the same task. },
  class		= {Reengineering_in_General, Experiences }
}

@Article{	  buss.mori.ea:investigating,
  author	= {E. Buss and R. De Mori and W. M. Gentleman and J. Henshaw
		  and H. Johnson and K. Kontogiannis and E. Merlo and H. A.
		  M\"{u}ller and J. Mylopoulos and S. Paul and A. Prakash and
		  M. Stanley and S. R. Tilley and J. Troster and K. Wong},
  title		= {Investigating Reverse Engineering Technologies for the
		  {CAS} Program Understanding Project},
  journal	= {IBM Systems Journal},
  volume	= {33},
  number	= {3},
  year		= {1994},
  pages		= {477-500},
  abstract	= {},
  class		= {Reengineering_in_General, Experiences }
}

@Article{	  butler.mccabe:clinical,
  author	= {Charles W. Butler and Thomas J. McCabe},
  title		= {A Clinical Approach to Reverse and Reengineering},
  journal	= {Reverse Engineering Newsletter},
  year		= {1992},
  pages		= {Rev-1 -- Rev-4},
  month		= jan,
  inhalt	= {Ma\3nahmen, um 'alternde' Systeme aufrecht zu erhalten (in
		  Anlehnung an die Gesundheitsvorsorge): - periodische
		  Untersuchung (je älter je häufiger) - Metriken erheben und
		  festhalten - falls sich die Werte verschlechtern,
		  korrigierende Ma\3nahmen einleiten: * Diagnose *
		  Gegenma\3nahmen ermitteln * Abwägung von Risiken/Kosten und
		  Nutzen
		  
		  Mögliche Metriken: - McCabes cyclomatic complexity V -
		  McCabes essential complexity EV
		  
		  auch zur Erkennung von Redundanz (gleiche V/EV von
		  Programmen => gleiche Funktionalität) und Wiederverwendung
		  (gleich V/EV von Program Description Language PDL und
		  existierendem Programm => gleiche Funktionalität) },
  class		= {Reengineering_in_General, Process_Models}
}

@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{	  byrne:software,
  author	= {Eric J. Byrne},
  title		= {Software Reverse Engineering: a Case Study},
  journal	= {Software---Practice and Experience, Wiley},
  year		= {1991},
  volume	= {21},
  number	= {12},
  pages		= {1349-1364},
  abstract	= {This paper presents lessons learned from an experiment to
		  reverse engineer a program. A reverse engineering process
		  was used as part of a project to develop an Ada
		  implementation of a Fortran program and upgrade the
		  existing documentation. To accomplish this, design
		  information was extracted from the Fortran source code and
		  entered into a software development environment. The
		  extracted design information was used to implement a new
		  version of the program written in Ada. This experiment
		  revealed issues about recovering design information, such
		  as, separating design details from implementation details,
		  dealing with incomplete or erroneous information,
		  traceability of information between implementation and
		  recovered design, and re-engineering. The reverse
		  engineering process used to recover the design, and the
		  experience gained during the study are reported.},
  note		= { Experience report describing the problem of
		  reimplementing a Fortran program in Ada. Instead of a
		  one-to-one translation, the original Fortran program is
		  analyzed and design information is extracted which is then
		  used to reimplement the program in Ada.},
  class		= {Reengineering_in_General, Experiences}
}

@Article{	  byrne:software*1,
  author	= { E.J. Byrne },
  title		= { Software Reverse Engineering: A Case Study },
  journal	= { Software --- Practice and Experience },
  year		= { December 1991 },
  pages		= { 1349-1364 },
  abstract	= { },
  class		= {Reengineering_in_General, Experiences }
}

@InProceedings{	  chen:repository-based,
  author	= {Yih-Farn Robin Chen},
  title		= {Repository-Based Reverse Engineering: An Experience
		  Report},
  booktitle	= {Proceedings of the 4th Reengineering Forum},
  year		= {1994},
  address	= {Victoria, Canada},
  pages		= {33.1 - 33.10},
  month		= sep,
  note		= {only slides},
  class		= {Reengineering_in_General, Experiences}
}

@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}
}

@InProceedings{	  chikofsky:case,
  author	= {Elliot J. Chikofsky},
  title		= {{CASE} and Reengineering: From Archeology to Software
		  Perestroika},
  booktitle	= {Proceedings of the 12th  International Conference on
		  Software Engineering },
  pages		= {122},
  month		= mar,
  year		= {1990},
  abstract	= {CASE (computer-aided software engineering), reverse
		  engineering, and reengineering together form a coherent set
		  of strategies for software organizations to get a handle on
		  and reclaim their existing software assets. Each of the
		  three supports and depends upon the others for long-term
		  success. It is argued that they will be a permanent part of
		  the process of evolutionary development. Even in future
		  CASE systems with reliable automatic generation of
		  executable code, the resulting system will be (perhaps
		  automatically) reread by a reverse engineering process back
		  into the CASE dictionary. This will allow the discovery of
		  ramifications and side effects which are not foreseeable in
		  the forward engineering process.},
  class		= {Reengineering_in_General,
		  The_Pros_and_Cons_and_Risks_of_Reengineering}
}

@Proceedings{	  ciupke.ducasse:ecoop99,
  title		= {{ECOOP}'99 Workshop on Experiences in Object-Oriented
		  Reengineering},
  year		= {1999},
  editor	= {Oliver Ciupke and St{\'e}phane Ducasse},
  number	= {2-6-6/99},
  series	= {FZI-Report},
  organization	= {Forschungszentrum Informatik},
  address	= {Karlsruhe, Germany},
  month		= jul,
  optnote	= {},
  optannote	= {},
  class		= {Reengineering_in_General, Reengineering_Collections}
}

@InProceedings{	  colbrook.smythe.ea:data,
  author	= {A. Colbrook and C. Smythe and A. Darlison},
  title		= {Data Abstraction in a Software Re-engineering Reference
		  Model},
  booktitle	= {Proceedings of the  International Conference on Software
		  Maintenance ~1990},
  year		= {1990},
  pages		= {2-11},
  organization	= {IEEE},
  publisher	= {IEEE Computer Society Press},
  abstract	= {The process of software re-engineering must incorporate
		  techniques for manipulating software which is imperative,
		  declarative or functional in nature. This generality needs
		  a mechanism for deriving the original requirements of the
		  underlying data structures contained within the source code
		  itself. In this paper a reference model is proposed from
		  which it is possible to derive the necessary techniques
		  required to implement such a mechanism. The reference model
		  is programming language independent and as such is well
		  suited to representing the general re-engineering
		  process.},
  class		= {Reengineering_in_General, Process_Models}
}

@Article{	  configuration-management-system:olin,
  author	= {Reengineering a Configuration-Management System},
  title		= {Olin Bray and Michael Hess},
  journal	= {IEEE Software},
  year		= {1995},
  volume	= {12},
  number	= {1},
  pages		= {55-63},
  month		= {January},
  class		= {Reengineering_in_General, Experiences, Alteration,
		  Re-Design, From_Mainframe_to_Client-Server_Architecture}
}

@Article{	  dedene.vresse:realities,
  author	= {Guido Dedene and Jean-Pierre De Vresse},
  title		= {Realities of Off-Shore Reengineering},
  journal	= {IEEE Software},
  year		= {1995},
  volume	= {12},
  number	= {1},
  pages		= {},
  month		= {January},
  class		= {Reengineering_in_General, Experiences}
}

@InProceedings{	  desclaux.ribault:macs,
  author	= {Christine Desclaux and Michel Ribault},
  title		= {MACS: Maintenance Assistence Capability for Software
		  Maintenance},
  booktitle	= {Proceedings of the  International Conference on Software
		  Maintenance ~1991},
  year		= {1991},
  pages		= {2-11},
  organization	= {IEEE},
  publisher	= {IEEE Computer Society Press},
  abstract	= {MACS goal is to offer a customizable software maintenance
		  assistance system. Its main concern is to help the
		  maintainer in gaining a deep understanding of existing or
		  in-progress applications, of the factual data (Change
		  Management World and Abstraction Recovery World) and the
		  design decisions rationale (Reasoning World), the mapping
		  of domain to programming components (Interconnection
		  World). Moreover this broad reverse-engineering approach is
		  enhanced by impact analysis techniques to better perceive
		  the interaction between components. The MACS supervisor
		  proposes a set of maintenance process models to guide the
		  maintainer through the MACS worlds. Knowledge Base and
		  Expert-System techniques are used in conjunction with
		  Software Engineering techniques, which makes MACS a KADME,
		  Knowledge Assistance for Development and Maintenance
		  Environment. },
  class		= {Software_Reverse_Engineering, Reverse_Design,
		  Knowledge-Based_Concept_Assignment,
		  Reengineering_in_General, Process_Models}
}

@InProceedings{	  ducasse.ciupke:ecoop99,
  author	= {St{\'e}phane Ducasse and Oliver Ciupke},
  title		= {{ECOOP}'99 Workshop on Experiences in Object-Oriented
		  Reengineering},
  booktitle	= {Object-Oriented Technology -- Ecoop'99 Workshop Reader},
  editor	= {Ana Moreira and Serge Demeyer},
  volume	= {1743},
  optnumber	= {},
  optseries	= {Lecture Notes in Computer Science},
  year		= {1999},
  optorganization={},
  publisher	= {Springer-Verlag},
  optaddress	= {},
  optmonth	= {},
  pages		= {164--183},
  optnote	= {},
  optannote	= {},
  class		= {Reengineering_in_General, Reengineering_Collections}
}

@InProceedings{	  dunn.knight:software,
  author	= {M. F. Dunn and J. C. Knight},
  title		= {Software Reuse in an Industrial Setting: A Case Study},
  booktitle	= {Proceedings of the 13th  International Conference on
		  Software Engineering },
  pages		= {329-338},
  year		= {1991},
  class		= {Reengineering_in_General, Experiences}
}

@InBook{	  hall:reverse,
  author	= {P. A. V. Hall},
  pages		= {209-243},
  title		= {Reverse Engineering - hype, hope or here?},
  series	= {Software Reuse and Reverse Engineering in Practice},
  class		= {Reengineering_in_General,
		  The_Pros_and_Cons_and_Risks_of_Reengineering}
}

@InBook{	  hall:software,
  author	= {P. A. V. Hall},
  pages		= {3-31},
  title		= {Software Reuse, Reverse Engineering, and Re-engineering},
  series	= {Software Reuse and Reverse Engineering in Practice},
  class		= {Reengineering_in_General,
		  The_Pros_and_Cons_and_Risks_of_Reengineering}
}

@InProceedings{	  heineman.kaiser:incremental,
  author	= {George T. Heineman and Gail E. Kaiser},
  title		= {Incremental Process Support for Code Reengineering},
  pages		= {282-290},
  booktitle	= {Proceedings of the  International Conference on Software
		  Maintenance ~1994},
  year		= {1994},
  publisher	= {IEEE Computer Society Press},
  month		= sep,
  abstract	= {Reengineering a large code base can be a monumental task,
		  and the situation becomes even worse if the code is
		  concomitantly being modified. Since January 1992, the
		  authors have been using the MARVEL process centered
		  environment (PCE) for all of their software development and
		  are currently using it to develop the OZ PCE (MARVEL's
		  successor). Towards this effort, the authors are
		  reengineering OZ's code base to isolate the process engine,
		  transaction manager, and object management system as
		  separate components that can be used in arbitrary systems.
		  In this paper, the authors show how a PCE can assist teams
		  of users in carrying out code reengineering while allowing
		  them to continue their normal code development. The key
		  features to this approach are its incremental nature and
		  the ability of the PCE to automate most of the tasks
		  necessary to maintain the consistency of the code base.},
  class		= {Reengineering_in_General, Process_Models}
}

@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}
}

@InBook{	  holloway:re-engineering,
  author	= {S. Holloway},
  pages		= {271-282},
  title		= {Re-engineering business systems to use the next generation
		  of software},
  series	= {Software Reuse and Reverse Engineering in Practice},
  class		= {Reengineering_in_General,
		  The_Pros_and_Cons_and_Risks_of_Reengineering}
}

@Article{	  keller.shen.ea:environment,
  title		= {Environment support for business reengineering: the
		  {M}acrotec approach},
  author	= {R.K. Keller and X. Shen and R. Lajoie and M. Ozkan and T.
		  Tao},
  journal	= {Software - Concepts and Tools},
  pages		= {31--40},
  volume	= {16},
  number	= {1},
  year		= {1995},
  note		= { A business reengineering approach is developed based on
		  the formalism of coloured Petri-nets. The Macrotec
		  environment has been engineered for the support and
		  validation of this approach. Macrotec is based on
		  Macronets, the latter being a variation of the Petri net
		  formalism},
  class		= {Reengineering_in_General, Business_Reengineering}
}

@Proceedings{	  kellner:proceedings,
  editor	= {M. Kellner},
  title		= {Proceedings Conference on Software Maintenance},
  publisher	= {{IEEE} Computer Society Press},
  year		= {1992},
  note		= { Several papers in these proceedings that are directly
		  related to reverse engineering are discussed separately in
		  this bibliography},
  class		= {Reengineering_in_General, Reengineering_Collections}
}

@Book{		  knöll.schwarze:re-engineering,
  author	= {H.-D. Knöll and M. Schwarze},
  title		= {Re-Engineering von Anwendungssoftware},
  publisher	= {BI Wissenschaftsverlag},
  year		= {1993},
  edition	= {1},
  abstract	= {Fallstudie, CASE-Tools im Vergleich},
  language	= {German},
  class		= {Reengineering_in_General, Experiences}
}

@InProceedings{	  kutscha.henning.ea:task,
  author	= {Sebastian Kutscha and Klaus Henning and Horst
		  Kesselmeier},
  title		= {The Task Artifact Cycle: A Conceptual Approach to
		  Maintenance and Re-engineering},
  booktitle	= {1st  European Conference on Software Maintenance and
		  Reengineering 97},
  month		= mar,
  year		= {1997},
  publisher	= {IEEE Computer Society Press},
  abstract	= {We present a model - the so-called task artifact cycle -
		  which integrates the development of a system being in use
		  into the software lifecycle. The basic assumption of the
		  model is, that the actual use of a system may considerably
		  differ from the original design. This has to be taken into
		  consideration in maintenance and reengineering. In
		  particular, the monitoring of this development process is
		  an important basis for maintainability. },
  class		= {Reengineering_in_General, Process_Models}
}

@InProceedings{	  kölsch.wallrath:process,
  author	= {Ulrike Kölsch and Mechtild Wallrath},
  title		= {A Process Model for Controlling and Performing
		  Re-engineering Tasks},
  booktitle	= {1st  European Conference on Software Maintenance and
		  Reengineering 97},
  month		= mar,
  year		= {1997},
  publisher	= {IEEE Computer Society Press},
  abstract	= {In this paper we present a process model for controlling
		  and performing re-engineering tasks. This process model is
		  based on a re-engineering methodology, that regards the
		  legacy system from the data-oriented perspective and aims
		  for decomposing and transforming it into an object-oriented
		  system along semantic units.
		  
		  The transformation from procedural to object-oriented
		  systems requires to deal with system models at different
		  abstraction levels which must be matched to each other. The
		  object identification and the match are controlled and
		  performed by two processes - the microprocess and the
		  macroprocess. In order to find and process information with
		  respect to an abstract object, the macroprocess initiates
		  and coordinates a set of microprocesses that perform
		  re-engineering tasks with respect to a secluded functional
		  and structural part of the IS. },
  class		= {Reengineering_in_General, Process_Models}
}

@Article{	  lafue:panel,
  author	= {Gilles M. E. Lafue},
  title		= {Panel on Software Re-Engineering},
  journal	= {IEEE},
  year		= {1990},
  pages		= {118},
  class		= {Reengineering_in_General}
}

@Article{	  lakhotia:understanding,
  author	= {Arun Lakhotia},
  title		= {Understanding Someone Else's Code: Analysis of
		  Experiences},
  journal	= {Reverse Engineering Newsletter},
  pages		= {Rev-6 -- Rev-8},
  inhalt	= { Erkenntnisse: 1) Der Programmierproze\3 besteht darin,
		  Abbildungen zu konstruieren (vom Anwendungsbereich in die
		  Implementierung). 2) Ein Programm zu verstehen involviert
		  die Rekonstruktion all dieser Abbildungen. 3) Der
		  Rekonstruktionsproze\3 ist erwartungsgesteuert durch
		  Schaffung, Bestätigung und Verfeinerung von Hypothesen.
		  
		  Anforderungen an die Organisation/Struktur zum besseren
		  Verständnis von Programmcode: Ebenen der Abbildungen
		  sollten reflektiert werden in einer Kombination aus -
		  physischer Organisation (Verzeichnisstruktur auf
		  Dateiebene) - modulare Dekomposition des Programmcodes
		  
		  Tools: - thesaurusbasiertes Tool, das nach Symbolen sucht,
		  deren Bedeutung nahe bei funktionsbeschreibenden Phrasen
		  liegt. - cross-reference-Information, die durch *
		  Datenbankanfragen oder * hypertextorientierten Browsern zur
		  Verfügung gestellt wird. - Tool, das das Design ermittelt,
		  das am natürlichsten ist, um den Problemtyp zu beschreiben.
		  Z.B.: * Proze\3orientierte Anwendung -> Endliche Automaten
		  * Datenintensive Anwendung -> ER-Diagramme - Tool sollte
		  den Systemgenerierungsproze\3 (Makefile) berücksichtigen -
		  das Tool sollte partielle Rekonstruktion des Designs
		  ermöglichen },
  class		= {Reengineering_in_General, Experiences}
}

@InProceedings{	  liu.chen.ea:design,
  author	= {Xiaodong Liu and Zhiqiang Chen and Hongji Yang and Hussein
		  Zedan and William. C. Chu},
  title		= {A Design Framework for System Re-engineering},
  booktitle	= {Proceedings of Joint Asia Pacific Software Engineering
		  Conference and International Computer Science Conference},
  publisher	= {IEEE Computer Society},
  year		= {1997},
  address	= {Hong Kong},
  month		= {December},
  abstract	= { We discuss the current situation of formal methods and
		  their use in the re-engineering of computing systems,
		  especially real time systems. Based on the analysis result,
		  a solution which uses a consistent 4-sector Wide Spectrum
		  Language (WSL) is proposed, which presently includes the
		  general architecture and work flow, the structure of
		  Object-Action Model, the syntax and semantics of ObTAM
		  (Object Oriented Temporal Agent Model) and TGCL (Timed
		  Guarded Command Language). A small case study shows an
		  optimistic future of our WSL technique. Further research
		  will aim to build the complete semantic kernel of the WSL
		  and its associated algebraic laws, including transformation
		  rules and abstraction rules. },
  keywords	= {formal methods, re-engineering, wide spectrum language,
		  real-time systems, object orientation, Interval Temporal
		  Logic},
  class		= {Reengineering_in_General Requirement_Tracability
		  Software_Reverse_Engineering Reverse_Specification
		  Process_Models }
}

@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}
}

@Book{		  mcclure:three,
  author	= {C. McClure},
  title		= {The Three Rs of Software Automation: Reengineering,
		  Repository, and Reusability},
  publisher	= {Engelwood Cliffs},
  year		= {1992},
  address	= {New Jersey},
  class		= {Reengineering_in_General, Introductions_to_Reengineering}
}

@InBook{	  mcgill:reverse,
  author	= {R. McGill},
  pages		= {245-252},
  title		= {Reverse Engineering - not yet?},
  series	= {Software Reuse and Reverse Engineering in Practice},
  class		= {Reengineering_in_General,
		  The_Pros_and_Cons_and_Risks_of_Reengineering}
}

@InProceedings{	  meltz:assessment,
  author	= {Peter Meltz},
  title		= {Assessment of the Options for Hardware Software
		  Reengineering of two KSG/GfS Full Scope Simulators},
  booktitle	= {1st  European Conference on Software Maintenance and
		  Reengineering 97},
  month		= mar,
  year		= {1997},
  publisher	= {IEEE Computer Society Press},
  abstract	= {Due to the problems in maintaining software and hardware
		  it was tried to port the individual software of two
		  powerplant simulators onto new hardware platforms within a
		  reeingineering project. The examinations that had been
		  carried out surprisingly lead to the result, that the least
		  risky, most economic and best result would not be achieved
		  by reengineering but by newly generating the software on
		  the base of actual powerplant data. },
  class		= {Reengineering_in_General, Experiences}
}

@Article{	  miller:software,
  author	= {J. Cris Miller},
  title		= {Software Reengineering: Getting Done is Twice the Fun},
  year		= {1987},
  pages		= {171-178},
  class		= {Reengineering_in_General,
		  The_Pros_and_Cons_and_Risks_of_Reengineering}
}

@InProceedings{	  moore:technique,
  author	= {Melody Moore},
  title		= {A Technique for Reverse Engineering User Interfaces},
  booktitle	= {Proceedings of the Fourth Reverse Engineering Forum},
  publisher	= {IEEE Computer Society},
  year		= {1994},
  month		= {November},
  note		= {Presentation slides available},
  class		= {Reengineering_in_General User_Interface_Migration
		  Re-Design Alteration }
}

@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}
}

@InProceedings{	  regelson.anderson:debugging,
  key		= {Regelson \& Anderson, 1994},
  author	= {Elaine Regelson and Andrew Anderson},
  title		= {Debugging Practices for Complex Legacy Systems},
  pages		= {137-143},
  booktitle	= {Proceedings of the  International Conference on Software
		  Maintenance ~1994},
  year		= {1994},
  publisher	= {IEEE Computer Society Press},
  month		= sep,
  abstract	= {Modern software development can require large numbers of
		  people over long periods of time to create complex
		  products. Industry trends showing rapid movement of people
		  between companies and job assignments and use of
		  specialized software maintenance groups for all maintenance
		  activities frequently mean that the software engineers
		  supporting (debugging, fixing, enhancing, and completing)
		  products were not involved in the original design or
		  coding. Hence it is important for engineers to be able to
		  quickly find defects in unfamiliar code and to safely make
		  changes. This paper describes results from an industrial
		  survey initiated to collect information about software
		  debugging and maintenance best practices. It describes
		  failure reproduction, defect isolation, and debugging
		  practices and tools. The paper is based on numerous actual
		  examples and results of problem solving and exercices.},
  class		= {Reengineering_in_General, Experiences}
}

@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{	  samuelson:reverse-engineering,
  title		= {Reverse-engineering someone else's software: is it
		  legal?},
  author	= {P. Samuelson},
  journal	= {{IEEE} Software},
  volume	= {7},
  number	= {1},
  pages		= {90--96},
  year		= {1990},
  note		= { The legal issues concerning reverse engineering are
		  discussed: does reverse engineering software infringe
		  intellectual-property law?{}},
  class		= {Reengineering_in_General, Legality}
}

@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}
}

@Article{	  slovin.malik:reengineering,
  author	= {M. Slovin and S. Malik},
  title		= {Reengineering to Reduce System Maintenance: A Case Study},
  journal	= {IEEE Transactions on Software Engineering},
  year		= {1991},
  month		= {July/August},
  pages		= {14-24},
  class		= {Reengineering_in_General, Experiences}
}

@InProceedings{	  sneed.kaposi:study,
  author	= {Harry M. Sneed and Agnes Kaposi},
  title		= {A study on the Effect of Reengineering on
		  Maintainability},
  booktitle	= {Proceedings of the  International Conference on Software
		  Maintenance ~1990},
  year		= {1990},
  pages		= {91-99},
  organization	= {IEEE},
  publisher	= {IEEE Computer Society Press},
  abstract	= {The report presented here on the effect of reengineering
		  upon software maintainablility stems from a laboratory
		  experiment conducted within the METKIT research project of
		  the European ESPRIT program for the study and promotion of
		  the use of metrics in Software-Engineering. The experiment
		  was conducted as a case study in measuring software
		  complexity and maintainablility. However, the results also
		  serve to assess the benefits of reengineering old programs.
		  Maintainability is defined as the effort to perform
		  maintenance tasks, the impact domain of the maintenance
		  actions and the error rate caused by those actions.
		  Complexity is defined as a combination of code, data, data
		  flow, structure, and control flow metrics. From the data
		  collected it demonstrates that reengineering can decrease
		  complexity and increase maintainability, but that
		  restructuring has only a minor effect on maintainability.},
  class		= {Reengineering_in_General, Experiences,
		  Software_Reverse_Engineering, Reverse_Design,
		  Metric-Based_Methods_in_Reverse_Design, Metrics,
		  Maintenance_Metrics}
}

@InProceedings{	  sneed:bank,
  author	= {Harry M. Sneed},
  title		= {Bank Application Reengineering and Conversion at the Union
		  Bank of Switzerland},
  booktitle	= {Proceedings of the  International Conference on Software
		  Maintenance ~1991},
  year		= {1991},
  pages		= {60-72},
  organization	= {IEEE},
  publisher	= {IEEE Computer Society Press},
  abstract	= {This paper describes a large software reengineering
		  project at the Union Bank of Switzerland. Seven bank
		  applications with 203 programs and 432 files were renovated
		  and migrated from a UNIVAC-494 to a UNISYS-1100. The
		  programs were restructured to fit a JSP-DELTA generator.
		  The data was remodelled to fit into a CODASYL database with
		  a data dictionary and a common COPY library.},
  class		= {Reengineering_in_General, Experiences}
}

@InProceedings{	  sneed:measuring,
  author	= {Harry M. Sneed},
  title		= {Measuring the Performance of a Software Maintenance
		  Department},
  booktitle	= {1st  European Conference on Software Maintenance and
		  Reengineering 97},
  month		= mar,
  year		= {1997},
  publisher	= {IEEE Computer Society Press},
  class		= {Reengineering_in_General, Experiences}
}

@Article{	  sneed:planning,
  author	= {H. Sneed},
  title		= {Planning the Reengineering of Legacy Systems},
  journal	= {IEEE Software},
  year		= {1995},
  volume	= {12},
  number	= {1},
  pages		= {24-33},
  month		= {January},
  class		= {Reengineering_in_General, Process_Models, Management}
}

@Article{	  sneed:software,
  author	= {Harry M. Sneed},
  title		= {Software Renewal: A Case Study},
  journal	= {IEEE Software},
  year		= {1984},
  pages		= {56-63},
  month		= jul,
  class		= {Reengineering_in_General, Experiences}
}

@InProceedings{	  solinger.engberts.ea:transferring,
  author	= {Mary Solinger and Andre Engberts and Jim Q. Ning},
  title		= {Transferring Re-engineering Technology to a Software
		  Development and Maintenance Organization: an Experience
		  Report},
  booktitle	= {Proceedings of the  International Conference on Software
		  Maintenance ~1994},
  year		= {1994},
  pages		= {100-108},
  publisher	= {IEEE Computer Society Press},
  month		= sep,
  abstract	= {Technology transfer does not happen spontaneously after
		  resaerch results and prototypes have been demostrated.
		  Resaerchers need to get more actively invovled in ``pushing
		  technology out of the door.'' This paper describes an
		  experiment that we conducted in 1993 to facilitate
		  technology transfer. There are two aspects of this
		  experiment: 1) the integration of a re-engineering process
		  into an existing software development and maintenance
		  organization and 2) the evaluation of a research prototype
		  in a ``real world'' situation. The experiment resulted in
		  recommendations on adapttation of the tool functionality
		  and on a configuration for use by different teams within
		  the target organization.},
  class		= {Reengineering_in_General, Experiences}
}

@Article{	  swanson:dimensions,
  author	= {E. Burton Swanson},
  title		= {The Dimensions of Management},
  pages		= {492-497},
  class		= {Reengineering_in_General, Management}
}

@InProceedings{	  tilley:management,
  key		= {Tilley, 1992},
  author	= {Scott R. Tilley},
  title		= {Management Decision Support Through Reverse Engineering
		  Technology},
  booktitle	= {Proceedings of CASCON'92},
  year		= {1992},
  pages		= {319-328},
  month		= nov,
  abstract	= {Managers of large software systems face enormous
		  challenges when it comes to making informed project-related
		  decisions. They require a high-level understanding of the
		  entire system and in-septh information on selected
		  components. Unfortunately, many software systems are so
		  comples and/or old that such information is not readily
		  available. Reverse engineering - the process of extracting
		  system abstractions and design information from existing
		  software systems - can provide some of this missing
		  information. This paper outlines how a software system can
		  benefit from reverse engineering, and describes how
		  management personnel can use the information provided by
		  this process as an aid in making informed decisions related
		  to large software projects.},
  class		= {Reengineering_in_General, Management}
}

@Article{	  ulrich:re-devolpment,
  author	= {William M. Ulrich},
  title		= {Re-devolpment Engineering: Formulating an Information
		  Blueprint for the 1990's},
  journal	= {Case Outlook},
  year		= {1990},
  pages		= {15-23},
  month		= feb,
  class		= {Reengineering_in_General}
}

@Article{	  wilde.huitt:maintenance,
  author	= {N. Wilde and R. Huitt},
  title		= {Maintenance Support for Object-Oriented Programs},
  journal	= {IEEE Transactions on Software Engineering},
  volume	= {18},
  number	= {12},
  pages		= {1038-1044},
  year		= {1992},
  class		= {Reengineering_in_General}
}

@PhDThesis{	  wong:reverse,
  author	= {Kenny Wong},
  title		= {The Reverse Engineering Notebook},
  school	= {University of Victoria},
  year		= {1999},
  abstract	= {Software must evolve over time or it becomes useless. Much
		  of software production today is involved not in creating
		  wholly new code from scratch but in maintaining and
		  building upon existing code. Much of this code resides in
		  old legacy software systems.
		  
		  Unfortunately, these systems are often poorly documented.
		  Typically, they become more complex and difficult to
		  understand over time. Thus, there is a need to better
		  understand existing software systems. An approach toward
		  this problem would be a first step toward easing changes
		  and extending the continuous evolution of these systems.
		  
		  This dissertation addresses the problem by enabling
		  continuous software understanding. There should be a base
		  of reverse engineering abstractions that are carried
		  forward during evolution.
		  
		  The proposed approach seeks to redocument existing software
		  structure, capture the analysis decisions made, and support
		  personal, customizable, and live perspectives of the
		  software in an online journal called the Reverse
		  Engineering Notebook.
		  
		  The premise that software reverse engineering be applied
		  continuously throughout the lifetime of the software has
		  major tool design implications. Thus, tool integration,
		  process, and adoption are key issues for the Notebook. In
		  particular, data integration requirements, control
		  integration via pervasive scripting, presentation
		  integration through the management of views, user roles,
		  methodology, end user needs, and goal-directed framework
		  for the Notebook are described.
		  
		  A major theme of the dissertation is learning from the
		  successes and failures of studies involving tool
		  integration and reverse engineering technologies. Case
		  studies and user experiments helped to evaluate various
		  aspects of the Notebook approach and provide feedback into
		  software understanding tool requirements.
		  
		  },
  keywords	= {reverse engineering, program understanding, tool
		  requirements},
  class		= {Interoperability Reengineering_in_General Using_graphs
		  Reverse_Engineering_Tools Rig Process_Models
		  Software_Reverse_Engineering
		  Intermediate_Representations_of_Source_Code Experiences }
}

@InProceedings{	  woods.obrien.ea:architecture,
  author	= {Steven Woods and Liam O'Brien and Tao Lin and Keith
		  Gallagher and Alex Quilici},
  title		= {An Architecture for Interoperable Program Understanding
		  Tools},
  booktitle	= {Euromicro Conference on Software Maintenance and
		  Reengineering},
  year		= {1999},
  publisher	= {Euromicro},
  class		= {Reengineering_in_General, Interoperability}
}

@InProceedings{	  yang.liu.ea:tackling,
  author	= {Hongji Yang and Xiaodong Liu and Hussein Zedan},
  title		= {Tackling the Abstraction Problem for Reverse Engineering
		  in a System Re-engineering Approach},
  booktitle	= {proceedings of the IEEE Conference on Software Maintenance
		  (ICSM'98)},
  publisher	= {IEEE Computer Society},
  year		= {1998},
  address	= {Washington D.C., USA},
  month		= {November},
  abstract	= {It is widely accepted that reverse engineering has three
		  components: restructuring, comprehension and production of
		  formal specification. In this paper, we advocate that the
		  three components could be achieved in a {\bf systematic}
		  approach by successfully applying a series of sound rules.
		  
		  The key approach to comprehension and the production of
		  formal specification is a notion of abstraction.
		  Abstraction is often interpreted as the act of hiding
		  irrelevant details. What constitute as relevant details is
		  often left open to different interpretations.
		  
		  A unified approach for reverse engineering is described
		  within which the notion of abstraction is classified and
		  precisely defined. Abstraction rules are given and applied
		  to various small examples. },
  keywords	= {reverse engineering, re-engineering, wide spectrum
		  language, abstraction, object oriented, Interval Temporal
		  Logic. },
  class		= {Reengineering_in_General Software_Reverse_Engineering
		  Reverse_Specification Formal_Methods Reverse_Design
		  Process_Models }
}

@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}
}