Page 171 -

154 Chapter 6 Architectural design

2. A process view, which shows how, at run-time, the system is composed of inter-
acting processes. This view is useful for making judgments about non-
functional system characteristics such as performance and availability.
3. A development view, which shows how the software is decomposed for devel-
opment, that is, it shows the breakdown of the software into components that are
implemented by a single developer or development team. This view is useful for
software managers and programmers.
4. A physical view, which shows the system hardware and how software compo-
nents are distributed across the processors in the system. This view is useful for
systems engineers planning a system deployment.

Hofmeister et al. (2000) suggest the use of similar views but add to this the notion
of a conceptual view. This view is an abstract view of the system that can be the basis
for decomposing high-level requirements into more detailed specifications, help
engineers make decisions about components that can be reused, and represent
a product line (discussed in Chapter 16) rather than a single system. Figure 6.1,
which describes the architecture of a packing robot, is an example of a conceptual
system view.
In practice, conceptual views are almost always developed during the design
process and are used to support architectural decision making. They are a way of
communicating the essence of a system to different stakeholders. During the design
process, some of the other views may also be developed when different aspects of
the system are discussed, but there is no need for a complete description from all per-
spectives. It may also be possible to associate architectural patterns, discussed in the
next section, with the different views of a system.
There are differing views about whether or not software architects should use
the UML for architectural description (Clements, et al., 2002). A survey in 2006
(Lange et al., 2006) showed that, when the UML was used, it was mostly applied in
a loose and informal way. The authors of that paper argued that this was a bad thing.
I disagree with this view. The UML was designed for describing object-oriented
systems and, at the architectural design stage, you often want to describe systems at
a higher level of abstraction. Object classes are too close to the implementation to be
useful for architectural description.
I don’t find the UML to be useful during the design process itself and prefer infor-
mal notations that are quicker to write and which can be easily drawn on a white-
board. The UML is of most value when you are documenting an architecture in
detail or using model-driven development, as discussed in Chapter 5.
A number of researchers have proposed the use of more specialized architectural
description languages (ADLs) (Bass et al., 2003) to describe system architectures.
The basic elements of ADLs are components and connectors, and they include rules
and guidelines for well-formed architectures. However, because of their specialized
nature, domain and application specialists find it hard to understand and use ADLs.
This makes it difficult to assess their usefulness for practical software engineering.
ADLs designed for a particular domain (e.g., automobile systems) may be used as a