Software Architecture Evaluation Methods

Here is yet another post on software architecture evaluation. After ATAM, LAE, Tactics Based Analysis, this time a more general one focusing on software architecture evaluation in general.

Software architecture evaluation goal is to determine whether the architecture design satisfies the architecturally significant requirements. Every evaluation method’s starting point is the definition of the analysis goals which usually can be classified in four categories:

  • Completeness analysis checks whether all system requirements have been addressed in the architectural design or whether all necessary architectural elements have been defined and whether all divisions have been made.
  • Consistency analysis means checking whether the defined architecture contains contradicting information or not.
  • Compatibility analysis is used for checking whether an architecture adheres to design guidelines and constraints defined by architectural styles, reference architectures and standards.
  • Correctness analysis is done with respect to some artifact of reference (for example system requirements)

Depending on their approach, software architecture methods can be classified as:

  • Architecture review. These are heavyweight or lightweight static analysis, performed manually, based on informal or semiformal architecture documentation. It relies on the experience and expertise of the reviewers. Architecture reviews are primarily used for correctness analysis.
  • Architecture description languages (ADLs) are formal languages for describing the architecture of a software system. Each ADL (for example xADL, ACME, AUTOSAR) defines a notation with precise syntax and semantics in which architecture models can be expressed, and provides a corresponding toolkit for working with the language. ADLs primarily support architecture evaluation of selected quality attributes. In addition, architecture models can be analyzed for completeness with respect to a modeling notation, and for consistency. Some ADLs, like ACME, also support compatibility analysis.
  • Dependency analysis approaches can be used for extracting and analyzing static dependencies from code and for comparing the actually implemented architecture with the intended architecture. It can be done with tools like Lattix or Structure 101.
  • Scenario-based architecture evaluation is a kind of architecture review which is based on the notion of a scenario (source of stimulus – stimulus – artifact – environment – response measure). Each identified scenario is checked whether is supported by the system’s architecture.
  • An architecture prototype is a functional subset of a system created to get early feedback from the stakeholders. Prototypes are used for performing dynamic and analysis based on an executable (but incomplete) system implementation. The strength of prototypes is that they permit architecture analysis under close-to-real conditions. Prototypes are used for answering questions that cannot be sufficiently answered by other analysis approaches like architecture reviews.
  • Ad hoc analysis means that architecture analysis is performed implicitly as part of architecture design and implementation activities based on experience, expertise, and argumentation. Ad hoc analysis supports all kinds of architecture analysis goals and can be performed with both formal and informal architecture documentation, or without any documentation at all. The analysis is performed manually by technical stakeholders, like software architects and developers.