Page 170 -

6.2 Architectural views 153

readily be changed. Producers of data should be separated from consumers and
shared data structures should be avoided.

Obviously there is potential conflict between some of these architectures. For
example, using large components improves performance and using small, fine-grain
components improves maintainability. If both performance and maintainability are
important system requirements, then some compromise must be found. This can
sometimes be achieved by using different architectural patterns or styles for different
parts of the system.
Evaluating an architectural design is difficult because the true test of an architec-
ture is how well the system meets its functional and non-functional requirements
when it is in use. However, you can do some evaluation by comparing your design
against reference architectures or generic architectural patterns. Bosch’s (2000)
description of the non-functional characteristics of architectural patterns can also be
used to help with architectural evaluation.

6.2 Architectural views

I explained in the introduction to this chapter that architectural models of a software
system can be used to focus discussion about the software requirements or design.
Alternatively, they may be used to document a design so that it can be used as a basis
for more detailed design and implementation, and for the future evolution of the sys-
tem. In this section, I discuss two issues that are relevant to both of these:

1. What views or perspectives are useful when designing and documenting a sys-
tem’s architecture?
2. What notations should be used for describing architectural models?

It is impossible to represent all relevant information about a system’s architecture in
a single architectural model, as each model only shows one view or perspective of the
system. It might show how a system is decomposed into modules, how the run-time
processes interact, or the different ways in which system components are distributed
across a network. All of these are useful at different times so, for both design and doc-
umentation, you usually need to present multiple views of the software architecture.
There are different opinions as to what views are required. Krutchen (1995), in
his well-known 4+1 view model of software architecture, suggests that there should
be four fundamental architectural views, which are related using use cases or scenar-
ios. The views that he suggests are:

1. A logical view, which shows the key abstractions in the system as objects or
object classes. It should be possible to relate the system requirements to entities
in this logical view.