Evaluation of an architecture's properties is critical to successful system development. However, reasoning about a system's intended architecture must be recognized as distinct from reasoning about its realized architecture. As design and eventually implementation of an architecture proceed, faithfulness to the principles of the intended architecture is not always easy to achieve. This is particularly true in cases where the intended architecture is not completely specified, documented, or disseminated to all of the project members. In our experience, this is the rule, and well-specified, documented, disseminated and controlled architectures are the exception. This problem is exacerbated during maintenance and evolutionary development, as architectural drift and erosion occur. However, if we wish to transfer our reasoning about the properties of a system's intended architecture to the properties of the implemented system, we must reconstruct the architecture of the realized system.
The implemented architecture of a software system typically exists only in artifacts such as source code, makefiles and occasionally designs that are directly realized as code (through, for example, the use of an architecture description language). In addition, it is infrequent that an implementation language provides explicit mechanisms for the representation of architectural constructs. Therefore, facilities for the reconstruction of a software architecture from these artifacts are critical for identifying the as implemented architecture.
Software architecture reconstruction also provides important leverage for the effective reuse of software assets. The ability to identify the architecture of an existing system that has successfully met its quality goals fosters reuse of the architecture in systems with similar goals; hence architectural reuse is the cornerstone practice of product line development.
Architecture reconstruction is an iterative and interactive process, comprising four phases. The first phase is the extraction, from implementation artifacts (including source code and dynamic information, such as event traces), of a set of extracted views that represent the system's fundamental structural and behavioral elements. The second phase is fusion of the extracted views to create fused views that augment or improve the extracted views. During the third phase, the analyst iteratively and interactively develops and applies patterns to the fused views to reconstruct architecture-level derived views. Patterns provide the medium for an analyst to express their understanding of a system’s architecture as structural and attribute-based relationships among its components. Finally, the derived views may be explored for the purposes of evaluating architectural conformance, identifying targets for reengineering or reuse, and analyzing the architecture's qualities.
The reconstruction process can be most effectively supported by the integration of existing tools and techniques. There currently exist a large number of commercial and research tools that provide the basic mechanisms for view extraction. Similarly, there are several tools and techniques available for performing view fusion and reconstruction. The synthesis of these tools and techniques provides a support environment for software architects and analysts reconstructing architectures. We have also co-developed an architecture reconstruction tool, called ARMIN.
Architecture Reconstruction Case Study
Liam O'Brien & Christoph Stoermer
Architecture Reconstruction Guidelines, Third Edition
Rick Kazman, Liam O'Brien, & Chris Verhoef
"Moving Towards Quality Attribute Driven Software Architecture Reconstruction." C. Stoermer, L. O'Brien, C. Verhoef. Working Conference on Reverse Engineering, Victoria, BC, Canada, November 13th - 16th, 2003.
Software Architecture Reconstruction: Practice Needs and Current Approaches
Liam O'Brien, Christoph Stoermer, & Chris Verhoef
For more information
Please tell us what you
think with this short
(< 5 minute) survey.