Software architecture is the primary carrier of a software system's quality attributes such as performance, modifiability, or reliability. An implementation is said to conform to its architecture if it adheres to the design principles and constraints prescribed by that architecture. Conformance is required for the implemented system to exhibit the desired quality attributes. Unfortunately, there is often a sizeable gap between the abstractions used to reason about an architecture and the code written to realize the architecture, and implementations can diverge from the architecture.
Divergence of an implementation from the intended architecture may be due to (1) the lack of suitable architectural design documentation (2) a tendency of programmers to "over design" with little consideration for quality-attribute requirements, or (3) just the natural evolution of the system. Over time, this problem tends to become worse and reliance on the originally specified software architecture decreases, preventing organizations from reasoning architecturally about the consequences of new features or other architectural changes.
We have investigated technologies and practices that improve an organization's ability to ensure that the implementation is in conformance with its architecture. Basically, this means that the implementation should be divided into the prescribed elements, these elements should interact with each other in the prescribed fashion, and each element should fulfill its responsibilities to the others as dictated by the architecture. We see architecture enforcement as a systematic process in which the developers periodically align the architectural design documentation and the code, to prevent mismatches from happening and/or to repair existing mismatches. Tool support is crucial to make this process cost effective.
Candidate approaches that can help to enforce architectural design decisions include
- Code generation: Tools implementing model-driven engineering approaches can be used to generate complete implementations from models; in such cases, conformance is a given unless developers subsequently edit the code.
- Code instrumentation and profiling: Techniques to collect data from running systems can give insights on the behavior and structure of the system, and furthermore, provide inputs for reconstructing the architecture "as-implemented."
- Aspect-oriented technologies: Mechanisms such as compile-time declarations can be used to check that dependencies not allowed in the architecture are not added to the code.
- Law governance frameworks: The specification and enforcement of protocols of interaction for heterogeneous components can define boundaries of allowed behaviors and foster the development of trusted systems.
- Change impact analysis: Artifacts such as dependency matrices can be used to identify potential design problems in a system, keeping mappings to the corresponding implementation units. Thus, it is possible to statically check compliance of components and code to specific design rules.
Areas of work at the SEI that complement our conformance research are
Software Architecture Training and Publications