6

Architectural design

Objectives
The objective of this chapter is to introduce the concepts of software
architecture and architectural design. When you have read the chapter,
you will:

understand why the architectural design of software is important;

understand the decisions that have to be made about the system

architecture during the architectural design process;

have been introduced to the idea of architectural patterns, well-tried

ways of organizing system architectures, which can be reused in
system designs;

know the architectural patterns that are often used in different types
of application system, including transaction processing systems and
language processing systems.

Contents
6.1
6.2
6.3
6.4

Architectural design decisions

Architectural views
Architectural patterns
Application architectures

148

Chapter 6 Architectural design

Architectural design is concerned with understanding how a system should be
organized and designing the overall structure of that system. In the model of the software development process, as shown in Chapter 2, architectural design is the first
stage in the software design process. It is the critical link between design and
requirements engineering, as it identifies the main structural components in a system
and the relationships between them. The output of the architectural design process is
an architectural model that describes how the system is organized as a set of communicating components.
In agile processes, it is generally accepted that an early stage of the development
process should be concerned with establishing an overall system architecture.
Incremental development of architectures is not usually successful. While refactoring components in response to changes is usually relatively easy, refactoring a system architecture is likely to be expensive.
To help you understand what I mean by system architecture, consider Figure 6.1.
This shows an abstract model of the architecture for a packing robot system that
shows the components that have to be developed. This robotic system can pack different kinds of object. It uses a vision component to pick out objects on a conveyor,
identify the type of object, and select the right kind of packaging. The system then
moves objects from the delivery conveyor to be packaged. It places packaged objects
on another conveyor. The architectural model shows these components and the links
between them.
In practice, there is a significant overlap between the processes of requirements
engineering and architectural design. Ideally, a system specification should not
include any design information. This is unrealistic except for very small systems.
Architectural decomposition is usually necessary to structure and organize the specification. Therefore, as part of the requirements engineering process, you might propose an abstract system architecture where you associate groups of system functions
or features with large-scale components or sub-systems. You can then use this
decomposition to discuss the requirements and features of the system with stakeholders.
You can design software architectures at two levels of abstraction, which I call
architecture in the small and architecture in the large:
1.

Architecture in the small is concerned with the architecture of individual programs. At this level, we are concerned with the way that an individual program
is decomposed into components. This chapter is mostly concerned with program architectures.

2.

Architecture in the large is concerned with the architecture of complex enterprise systems that include other systems, programs, and program components. These enterprise systems are distributed over different computers,
which may be owned and managed by different companies. I cover architecture in the large in Chapters 18 and 19, where I discuss distributed systems
architectures.

Chapter 6 Architectural design

149

Vision
System

Object
Identification
System

Arm
Controller

Gripper
Controller

Packaging
Selection
System

Packing
System

Figure 6.1 The

architecture of a packing
robot control system

Conveyor
Controller

Software architecture is important because it affects the performance, robustness,

distributability, and maintainability of a system (Bosch, 2000). As Bosch discusses,
individual components implement the functional system requirements. The nonfunctional requirements depend on the system architecturethe way in which these
components are organized and communicate. In many systems, non-functional
requirements are also influenced by individual components, but there is no doubt
that the architecture of the system is the dominant influence.
Bass et al. (2003) discuss three advantages of explicitly designing and documenting software architecture:
1.

Stakeholder communication The architecture is a high-level presentation of the system that may be used as a focus for discussion by a range of different stakeholders.

2.

System analysis Making the system architecture explicit at an early stage in the
system development requires some analysis. Architectural design decisions
have a profound effect on whether or not the system can meet critical requirements such as performance, reliability, and maintainability.

3.

Large-scale reuse A model of a system architecture is a compact, manageable

description of how a system is organized and how the components interoperate.
The system architecture is often the same for systems with similar requirements
and so can support large-scale software reuse. As I explain in Chapter 16, it may
be possible to develop product-line architectures where the same architecture is
reused across a range of related systems.

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 control 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 Boochs software architecture 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) dislike 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 stakeholders and project planning because it is not cluttered with detail. Stakeholders 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 during 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.