Page 167 -

150 Chapter 6 Architectural design

Hofmeister et al. (2000) propose that a software architecture can serve firstly as a
design plan for the negotiation of system requirements, and secondly as a means of
structuring discussions with clients, developers, and managers. They also suggest
that it is an essential tool for complexity management. It hides details and allows the
designers to focus on the key system abstractions.
System architectures are often modeled using simple block diagrams, as in Figure 6.1.
Each box in the diagram represents a component. Boxes within boxes indicate that the
component has been decomposed to sub-components. Arrows mean that data and or con-
trol signals are passed from component to component in the direction of the arrows. You
can see many examples of this type of architectural model in Booch’s software architec-
ture catalog (Booch, 2009).
Block diagrams present a high-level picture of the system structure, which people
from different disciplines, who are involved in the system development process, can
readily understand. However, in spite of their widespread use, Bass et al. (2003) dis-
like informal block diagrams for describing an architecture. They claim that these
informal diagrams are poor architectural representations, as they show neither the
type of the relationships among system components nor the components’ externally
visible properties.
The apparent contradictions between practice and architectural theory arise
because there are two ways in which an architectural model of a program is used:

1. As a way of facilitating discussion about the system design A high-level
architectural view of a system is useful for communication with system stake-
holders and project planning because it is not cluttered with detail. Stake-
holders can relate to it and understand an abstract view of the system. They
can then discuss the system as a whole without being confused by detail. The
architectural model identifies the key components that are to be developed
so managers can start assigning people to plan the development of these
systems.
2. As a way of documenting an architecture that has been designed The aim here
is to produce a complete system model that shows the different components in
a system, their interfaces, and their connections. The argument for this is that
such a detailed architectural description makes it easier to understand and evolve
the system.

Block diagrams are an appropriate way of describing the system architecture dur-
ing the design process, as they are a good way of supporting communications
between the people involved in the process. In many projects, these are often the
only architectural documentation that exists. However, if the architecture of a system
is to be thoroughly documented then it is better to use a notation with well-defined
semantics for architectural description. However, as I discuss in Section 6.2, some
people think that detailed documentation is neither useful, nor really worth the cost
of its development.