Architectural design

Lecture2
• 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, 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.
• Figure 6.1 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,
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. (Chapters 18 and 19, where distributed systems
architectures are discussed).
 Why Software architecture is
important?
• 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 architecture—the 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.
three advantages of explicitly designing and
documenting software architecture(cont.):

• 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. It may be possible to develop product-line architectures where the same architecture is
reused across a range of related systems.

• 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 [Hofmeister et al. (2000)]. Also 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.
• 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.

• 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.
 two ways in which an architectural model of a
program is used(cont.):
• 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.
• Architectural design is a creative process where you design a system organization that will satisfy the
functional and non-functional requirements of a system. Because it is a creative process, the activities within
the process depend on the type of system being developed, the background and experience of the system
architect, and the specific requirements for the system. It is therefore useful to think of architectural design
as a series of decisions to be made rather than a sequence of activities.

• During the architectural design process, system architects have to make a number of structural decisions that
profoundly affect the system and its development process. Based on their knowledge and experience, they
have to consider the following fundamental questions about the system:

1. Is there a generic application architecture that can act as a template for the system that is being designed?
2. How will the system be distributed across a number of cores or processors?
3. What architectural patterns or styles might be used?
4. What will be the fundamental approach used to structure the system?
5. How will the structural components in the system be decomposed into subcomponents?
6. What strategy will be used to control the operation of the components in the system?
7. What architectural organization is best for delivering the non-functional requirements of the system?
8. How will the architectural design be evaluated?
9. How should the architecture of the system be documented?
 Each software system is unique,
however
• systems in the same application domain often have similar architectures that reflect the
fundamental concepts of the domain.

• For example, application product lines are applications that are built around a core
architecture with variants that satisfy specific customer requirements. When designing a
system architecture, you have to decide what your system and broader application
classes have in common, and decide how much knowledge from these application
architectures you can reuse. Generic application architectures will be discussed in
Section 6.4 and application product lines in Chapter 16.

• For embedded systems and systems designed for personal computers, there is usually
only a single processor and you will not have to design a distributed architecture for the
system. However, most large systems are now distributed systems in which the system
software is distributed across many different computers. The choice of distribution
architecture is a key decision that affects the performance and reliability of the system.
This is a major topic in its own right and covered it separately 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 different software
systems. You should be aware of common patterns, where they can be used, and their strengths and
weaknesses when making decisions about the architecture of a system. Section 6.3 discusses a number of
frequently used patterns.

• 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 execution of components is
controlled. You develop a general model of the control relationships between the various parts of the system.
Because of the close relationship between non-functional requirements and software 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 components, with these components all deployed on the same computer rather than distributed across the
network. This may mean using a few relatively large components rather than small, fine-grain components, which reduces the
number of component communications. You may also consider run-time system organizations 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 architecture should be used, with the most critical
assets protected in the innermost layers, 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 validation 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. Chapter 13 describes two fault-tolerant
system architectures for high-availability systems.

5. Maintainability If maintainability is a critical requirement, the system architecture should be designed using fine-grain, self-
contained components that may 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 and architectural decisions:

• 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 architecture 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.
 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 system.

• Two issues that are relevant to both of these are :

1. What views or perspectives are useful when designing and documenting a system’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 documentation, you usually need to present multiple views of the
software architecture.
So, 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 scenarios.

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.

2. A process view, which shows how, at run-time, the system is composed of interacting processes. This
view is useful for making judgments about nonfunctional system characteristics such as performance and
availability.

3. A development view, which shows how the software is decomposed for development, 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 components 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
 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.

• Sommerville, 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.

• He doesn’t find the UML to be useful during the design process itself and prefer informal notations that
are quicker to write and which can be easily drawn on a whiteboard.

• 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(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 basis for
model-driven development. However, I believe that informal models and notations, such as
the UML, will remain the most commonly used ways of documenting system architectures.

• Users of agile methods claim that detailed design documentation is mostly unused. It is,
therefore, a waste of time and money to develop it. I largely agree with this view and I think
that, for most systems, it is not worth developing a detailed architectural description from
these four perspectives.
You should develop the views that are useful
for communication and not worry about
whether or not your architectural
documentation is complete.
• However, an exception to this is when you are developing critical systems, when you
need to make a detailed dependability analysis of the system. You may need to
convince external regulators that your system conforms to their regulations and so
complete architectural documentation may be required.

Architectural patterns
• The idea of patterns as a way of presenting, sharing, and reusing knowledge about software systems is
now widely used.

• The trigger for this was the publication of a book on object-oriented design patterns (Gamma et al.,
1995), which prompted the development of other types of pattern, such as patterns for organizational
design (Coplien and Harrison, 2004), usability patterns (Usability Group, 1998), interaction (Martin
and Sommerville, 2004), configuration management (Berczuk and Appleton, 2002), and so on.
 Architectural patterns(cont.)
• Architectural patterns were proposed in the 1990s under the name ‘architectural styles’ (Shaw
and Garlan, 1996), with a five-volume series of handbooks on pattern-oriented software
architecture published between 1996 and 2007 (Buschmann et al., 1996; Buschmann et al.,
2007a; Buschmann et al., 2007b; Kircher and Jain, 2004; Schmidt et al., 2000).

• Architectural patterns are introduced here and briefly a selection of architectural patterns that
are commonly used in different types of systems are described.

• For more information about patterns and their use, you should refer to published pattern
handbooks.

• An architectural pattern can be thought as a stylized, abstract description of good practice, which
has been tried and tested in different systems and environments. So, an architectural pattern
should describe a system organization that has been successful in previous systems. It should
include information of when it is and is not appropriate to use that pattern, and the pattern’s
strengths and weaknesses.
Figure 6.2 describes the well-known Model-View-
Controller pattern.
• This pattern is the basis of interaction management in many web-based systems. The
stylized pattern description includes the pattern name, a brief description (with an
associated graphical model), and an example of the type of system where the pattern is
used (again, perhaps with a graphical model). You should also include information about
when the pattern should be used and its advantages and disadvantages.
Graphical models of the architecture associated
with the MVC pattern are shown in Figures 6.3
and 6.4
• These present the architecture from different views—Figure 6.3 is a conceptual
view and Figure 6.4 shows a possible run-time architecture when this pattern is
used for interaction management in a web-based system.
some selected examples of patterns that are
widely used and which capture good architectural
design principles