Architecture Conformance

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; (3) or 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 are investigating 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, preventing mismatches from happening and/or repairing 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.

Additional Information

Areas of work at the SEI that complements our conformance research are:

• Architecture reconstruction
• Architecture-based evolution
• Predictability by construction

Contact Information: For more information about architecture conformance, contact Phil Bianco or Andres Diaz-Pace.

Working with the SEI: Learn more about working with the SEI in software architecture.