Design Requirements for an Architecture Consistency Tool

Software architecture and its related documentation are acknowledged as some of the most important artefacts created during system design. However, often the implemented system diverges, over time, from the designed architecture. This phenomenon is called architectural drift and is either a result of inconsistent evolution of the system, or a failure to keep the architectural documentation up to date. A case study, performed at IBM, over two years showed how architectural drift can occur in small development teams over time. It suggested that even when approaches are in place to identify architectural drift, they may prove insufficient for subsequent removal of the drift, and some possible reasons for this were derived. Consequently, this document outlines the resultant design requirements for an approach to inhibit architectural drift, primarily by identifying it as, or before, it is introduced.

[1]  Richard C. Holt,et al.  Using development history sticky notes to understand software architecture , 2004, Proceedings. 12th IEEE International Workshop on Program Comprehension, 2004..

[2]  David Notkin,et al.  Reengineering Reflexion Models: A Case Study , 1997 .

[3]  Janice Singer,et al.  An examination of software engineering work practices , 1997, CASCON.

[4]  Jim Buckley,et al.  Exercising control over the design of evolving software systems using an inverse application of reflexion modeling , 2006, CASCON.

[5]  Rainer Koschke,et al.  Equipping the reflexion method with automated clustering , 2005, 12th Working Conference on Reverse Engineering (WCRE'05).

[6]  David Notkin,et al.  Software reflexion models: bridging the gap between source and high-level models , 1995, SIGSOFT FSE.

[7]  Jim Buckley.  Requirements-Based Visualization Tools for Software Maintenance and Evolution , 2009, Computer.

[8]  David Notkin,et al.  Software Reflexion Models: Bridging the Gap between Design and Implementation , 2001, IEEE Trans. Software Eng..

[9]  Jens Knodel,et al.  A Comparison of Static Architecture Compliance Checking Approaches , 2007, 2007 Working IEEE/IFIP Conference on Software Architecture (WICSA'07).

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

[11]  Jens Knodel,et al.  Understanding Software Architectures by Visualization--An Experiment with Graphical Elements , 2006, 2006 13th Working Conference on Reverse Engineering.

[12]  Carolyn B. Seaman,et al.  Qualitative Methods in Empirical Studies of Software Engineering , 1999, IEEE Trans. Software Eng..

[13]  Lorin Hochstein,et al.  Diagnosing architectural degeneration , 2003, 28th Annual NASA Goddard Software Engineering Workshop, 2003. Proceedings..

[14]  Rainer Koschke,et al.  Hierarchical reflexion models , 2003, 10th Working Conference on Reverse Engineering, 2003. WCRE 2003. Proceedings..

[15]  Mary Shaw,et al.  The golden age of software architecture , 2006, IEEE Software.

[16]  Michael Eichberg,et al.  Defining and continuous checking of structural program dependencies , 2008, 2008 ACM/IEEE 30th International Conference on Software Engineering.

[17]  Jens Knodel,et al.  Static evaluation of software architectures , 2006, Conference on Software Maintenance and Reengineering (CSMR'06).

[18]  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.

[19]  Mikael Lindvall,et al.  Avoiding architectural degeneration: an evaluation process for software architecture , 2002, Proceedings Eighth IEEE Symposium on Software Metrics.

[20]  Lucas Layman,et al.  Toward Reducing Fault Fix Time: Understanding Developer Behavior for the Design of Automated Fault Detection Tools , 2007, ESEM 2007.

[21]  Gabriela Avram,et al.  An Experiential Report on the Limitations of Experimentation as a Means of Empirical Investigation , 2007, PPIG.

[22]  Muhammad Ali Babar,et al.  An industrial case study of architecture conformance , 2008, ESEM '08.

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

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

[25]  Thomas R. G. Green,et al.  Cognitive dimensions of notations , 1990 .

[26]  Margaret-Anne D. Storey.  Source Code Comments: Graffiti or Information? , 2008, PPIG.

[27]  Michael W. Godfrey,et al.  Architectural repair of open source software , 2000, Proceedings IWPC 2000. 8th International Workshop on Program Comprehension.

[28]  Rainer Koschke,et al.  Encapsulating targeted component abstractions using software Reflexion Modelling , 2008, J. Softw. Maintenance Res. Pract..