New Metrics for Architectural Design and Assessment

A new science of software architecture metrics is slowly emerging, amazingly in the absence of any generally accepted definition of software architecture. Software engineers have been coasting on the metaphor of building architecture for a long time. Some clarity is developing, but it is scarcely more than extending the metaphor. For example, an early (1994) intuitive definition states the following:

There is currently no single, universally accepted definition of software architecture, but typically a systems architectural design is concerned with describing its decomposition into components and their interconnections.^[15]

Actually, this is not a bad start. When one of the authors became manager of a large-scale computer design at Univac as chief architect in 1966, this was the operative definition of computer (hardware) architecture. It was sufficient only because of the tradition of hardware systems design, which had led to the large-scale multiprocessor computer system.^[16]

But to be more precise for software that comes later to this tradition, software architecture is "the structure of the components of a program/system, their interrelationships, and principles and guidelines governing their design and evolution over time."^[17] While descriptive, these definitions still do not give us enough leverage to begin defining metrics for the architectural assessment of software. We would like to again quote Shaw and Garlan's more recent definition:

Abstractly, software architecture involves the description of elements from which systems are built, interactions among those elements, patterns that guide their composition, and constraints on those patterns. In general, a particular system is defined in terms of a collection of components and the interactions among those components.^[18]

A software design pattern is a general repeatable solution to a commonly occurring problem in software design. It is not a finished design that can be transformed directly into program code. Rather, it is a description of or template for how to solve a problem that can be used in many different situations. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved. Algorithms are not thought of as design patterns, because they solve computational problems rather than design problems.

In practice, architectural metrics are involved not only upstream in the software development process and architecture discovery but also further downstream before coding begins as architectural review. These terms were introduced by Avritzer and Weyuker^[19] for use at AT&T and will be used here as well.