Diagnosing architectural degeneration

Software systems evolve over time and undergo changes that can lead to a degeneration of the systems' architecture. Degeneration may eventually reach a level where a complete redesign of the software system is necessary, which is a task that requires significant effort. In this paper, we start by presenting examples of such degeneration and continue with an analysis of technologies that can be used to diagnose degeneration. These technologies can be employed in identifying, degeneration so that it can be treated as early as possible, before it is too late and the system has to undergo a costly redesign.

[1]  Roy H. Campbell,et al.  Monitoring compliance of a software system with its high-level design models , 1996, Proceedings of IEEE 18th International Conference on Software Engineering.

[2]  Rudolf K. Keller,et al.  Pattern-based reverse-engineering of design components , 1999, Proceedings of the 1999 International Conference on Software Engineering (IEEE Cat. No.99CB37002).

[3]  Melissa P. Chase,et al.  Recovering software architecture from multiple source code analyses , 1998, PASTE '98.

[4]  Hausi A. Müller,et al.  The Software Bookshelf , 1997, IBM Syst. J..

[5]  Chung-Horng Lung,et al.  Software architecture recovery and restructuring through clustering techniques , 1998, ISAW '98.

[6]  Rick Kazman,et al.  View extraction and view fusion in architectural understanding , 1998, Proceedings. Fifth International Conference on Software Reuse (Cat. No.98TB100203).

[7]  Audris Mockus,et al.  Does Code Decay? Assessing the Evidence from Change Management Data , 2001, IEEE Trans. Software Eng..

[8]  Mary Shaw,et al.  An Introduction to Software Architecture , 1993, Advances in Software Engineering and Knowledge Engineering.

[9]  Lutz Prechelt,et al.  Design recovery by automated search for structural design patterns in object-oriented software , 1996, Proceedings of WCRE '96: 4rd Working Conference on Reverse Engineering.

[10]  Alan Bundy,et al.  Automatic verification of Java design patterns , 2001, Proceedings 16th Annual International Conference on Automated Software Engineering (ASE 2001).

[11]  Jeff Kramer,et al.  Requirements for an effective architecture recovery framework , 1996, ISAW '96.

[12]  Mikael Lindvall,et al.  Evaluating software architectures , 2004, Adv. Comput..

[13]  Jukka Paakki,et al.  Architecture-centric software evolution by software metrics and design patterns , 2002, Proceedings of the Sixth European Conference on Software Maintenance and Reengineering.

[14]  Fred P. Brooks,et al.  The Mythical Man-Month , 1975, Reliable Software.

[15]  Meir M. Lehman,et al.  Laws of Software Evolution Revisited , 1996, EWSPT.

[16]  Michael W. Godfrey,et al.  Secrets from the Monster: Extracting Mozilla’s Software Architecture , 2000 .

[17]  Hausi A. Müller,et al.  Understanding Software Systems Using Reverse Engineering Technology , 1994, COODBSE.

[18]  Mikael Lindvall,et al.  Does the code match the design? A process for architecture evaluation , 2002, International Conference on Software Maintenance, 2002. Proceedings..

[19]  David Notkin,et al.  Reengineering with Reflection Models: A Case Study , 1997, Computer.

[20]  Paul Clements,et al.  Software architecture in practice , 1999, SEI series in software engineering.

[21]  Meir M. Lehman,et al.  Program evolution: processes of software change , 1985 .

[22]  P. Tonella,et al.  A cliche-based environment to support architectural reverse engineering , 1996, 1996 Proceedings of International Conference on Software Maintenance.

[23]  Paolo Tonella,et al.  ART: an architectural reverse engineering environment , 1999 .