86 Chapter 4. Software Architecture
Properties. Properties are used to constrain the choice of architectural
elements – that is, the properties are used to define constraints on the
elements to the degree desired by the architecture.
Weight. Properties and relationships together define the minimum desired
constraints on the software architecture. A weight can be associated to a
property or relationship to indicate the importance of the property or
relationship, or to express the preference among a number of choices
among alternatives.
In Perry and Wolf’s definition, the rationale for the various choices made in
defining an architecture is an integral part of software architecture. The rationale
captures the motivation for the choice of architectural style, the choice of elements,
and the form. It explicates the satisfaction of system constraints determined by
users’ requirements both functional and non-functional.
Perry and Wolf’s definition considers software architecture from a
prescriptive point of view. From this viewpoint, software architecture is a design
document that prescribes how the system is to be built. In Perry and Wolf’s own
words, ‘architecture is concerned with the selection of architectural elements, their
interactions, and the constraints on those elements and their interactions necessary
to provide a framework in which to satisfy the requirements and serve as a basis
for the (detail) design’. Therefore, the rationale is an integral part of software
architecture and treated as first-class citizen. Barry Boehm and his students at USC
Center for Software Engineering [
3] further require that an architecture contains a
statement of stakeholders’ requirements of the system. From this point of view, not
every complex of diagrams and symbols is an architecture if there is no sufficient
rationale to ensure the components, connections and constraints will define a
system that satisfies the set of stakeholders’ requirements of the system. The
existence of a software architecture becomes a key milestone in software
development life cycle. Similarly, Hofmeister, Nord and Soni [
4] regard software
architecture as ‘purposeful design plan of a system’, although they agree with the
philosophical statement that every implemented software system has an
architecture regardless whether there is an explicit documentation describing it,
and/or whether it is good or bad.
4.2.2 Descriptive models
An alternative approach is the descriptive point of view, which considers
architecture as a description of the high level structure in terms of architectural
elements and the interactions between them. For example, Shaw and Garlan [
5]
wrote ‘abstractly, software architecture involves the description of elements from

Get Software Design Methodology now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.