Page 169 -

152 Chapter 6 Architectural design

reliability of the system. This is a major topic in its own right and I cover it sepa-
rately in Chapter 18.
The architecture of a software system may be based on a particular architectural
pattern or style. An architectural pattern is a description of a system organization
(Garlan and Shaw, 1993), such as a client–server organization or a layered architecture.
Architectural patterns capture the essence of an architecture that has been used in dif-
ferent software systems. You should be aware of common patterns, where they can be
used, and their strengths and weaknesses when making decisions about the architec-
ture of a system. I discuss a number of frequently used patterns in Section 6.3.
Garlan and Shaw’s notion of an architectural style (style and pattern have come to
mean the same thing) covers questions 4 to 6 in the previous list. You have to choose
the most appropriate structure, such as client–server or layered structuring, that will
enable you to meet the system requirements. To decompose structural system units,
you decide on the strategy for decomposing components into sub-components. The
approaches that you can use allow different types of architecture to be implemented.
Finally, in the control modeling process, you make decisions about how the execu-
tion of components is controlled. You develop a general model of the control rela-
tionships between the various parts of the system.
Because of the close relationship between non-functional requirements and soft-
ware architecture, the particular architectural style and structure that you choose for
a system should depend on the non-functional system requirements:

1. Performance If performance is a critical requirement, the architecture should
be designed to localize critical operations within a small number of com-
ponents, with these components all deployed on the same computer rather than
distributed across the network. This may mean using a few relatively large com-
ponents rather than small, fine-grain components, which reduces the number of
component communications. You may also consider run-time system organiza-
tions that allow the system to be replicated and executed on different processors.
2. Security If security is a critical requirement, a layered structure for the architec-
ture should be used, with the most critical assets protected in the innermost lay-
ers, with a high level of security validation applied to these layers.

3. Safety If safety is a critical requirement, the architecture should be designed so
that safety-related operations are all located in either a single component or in a
small number of components. This reduces the costs and problems of safety val-
idation and makes it possible to provide related protection systems that can
safely shut down the system in the event of failure.
4. Availability If availability is a critical requirement, the architecture should be
designed to include redundant components so that it is possible to replace and
update components without stopping the system. I describe two fault-tolerant
system architectures for high-availability systems in Chapter 13.
5. Maintainability If maintainability is a critical requirement, the system architec-
ture should be designed using fine-grain, self-contained components that may