Chapter 6 – Architectural Design
12/04/2021 Chapter 6 Architectural Design 1
Topics covered
● Architectural design decisions
● Architectural views
● Architectural patterns
● Application architectures
12/04/2021 Chapter 6 Architectural Design 2
Architectural design
● Architectural design is concerned with understanding
how a software system should be organized and
designing the overall structure of that system.
● Architectural design is the critical link between design
Loading…
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.
12/04/2021 Chapter 6 Architectural Design 3
Agility and architecture
● It is generally accepted that an early stage of agile
processes is to design an overall systems architecture.
● Refactoring the system architecture is usually expensive
because it affects so many components in the system
12/04/2021 Chapter 6 Architectural Design 4
The architecture of a packing robot control
system
Loading…
12/04/2021 Chapter 6 Architectural Design 5
Architectural abstraction
● 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.
● 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.
12/04/2021 Chapter 6 Architectural Design 6
Advantages of explicit architecture
● Stakeholder communication
● Architecture may be used as a focus of discussion by system
stakeholders.
● System analysis
● Means that analysis of whether the system can meet its non-
functional requirements is possible.
● Large-scale reuse
● The architecture may be reusable across a range of systems
● Product-line architectures may be developed.
12/04/2021 Chapter 6 Architectural Design 7
Architectural representations
● Simple, informal block diagrams showing entities and
relationships are the most frequently used method for
documenting software architectures.
● But these have been criticised because they lack
semantics, do not show the types of relationships
between entities nor the visible properties of entities in
the architecture.
● Depends on the use of architectural [Link]
requirements for model semantics depends on how the
models are used.
12/04/2021 Chapter 6 Architectural Design 8
Box and line diagrams
● Very abstract - they do not show the nature of
component relationships nor the externally visible
properties of the sub-systems.
● However, useful for communication with stakeholders
and for project planning.
12/04/2021 Chapter 6 Architectural Design 9
Use of architectural models
● 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.
● 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.
12/04/2021 Chapter 6 Architectural Design 10
Architectural design decisions
Loading…
12/04/2021 Chapter 6 Architectural Design 11
Architectural design decisions
● Architectural design is a creative process so the process
differs depending on the type of system being
developed.
● However, a number of common decisions span all
design processes and these decisions affect the non-
functional characteristics of the system.
12/04/2021 Chapter 6 Architectural Design 12
Architectural design decisions
12/04/2021 Chapter 6 Architectural Design 13
Architecture reuse
● Systems in the same domain often have similar
architectures that reflect domain concepts.
● Application product lines are built around a core
architecture with variants that satisfy particular customer
requirements.
● The architecture of a system may be designed around
one of more architectural patterns or ‘styles’.
● These capture the essence of an architecture and can be
instantiated in different ways.
12/04/2021 Chapter 6 Architectural Design 14
Architecture and system characteristics
● Performance
● Localise critical operations and minimise communications. Use
large rather than fine-grain components.
● Security
● Use a layered architecture with critical assets in the inner layers.
● Safety
● Localise safety-critical features in a small number of sub-
systems.
● Availability
● Include redundant components and mechanisms for fault
tolerance.
● Maintainability
● Use fine-grain, replaceable components.
12/04/2021 Chapter 6 Architectural Design 15
Fine-grain components OR large components?
● Large components improves performance,
● While small, fine-grain components improves
maintainability.
● If both performance and maintainability are important
system requirements then you need to compromise
12/04/2021 Chapter 6 Architectural Design 16
Evaluating architectural design
● 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
12/04/2021 Chapter 6 Architectural Design 17
Architectural views
12/04/2021 Chapter 6 Architectural Design 18
Architectural views
● What views or perspectives are useful when designing
and documenting a system’s architecture?
● What notations should be used for describing
architectural models?
● Each architectural 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. For both
design and documentation, you usually need to present multiple
views of the software architecture.
12/04/2021 Chapter 6 Architectural Design 19
Architectural views
12/04/2021 Chapter 6 Architectural Design 20
4 + 1 view model of software architecture
● A logical view, which shows the key abstractions in the
system as objects or object classes.
● A process view, which shows how, at run-time, the
system is composed of interacting processes.
● A development view, which shows how the software is
decomposed for development.
● A physical view, which shows the system hardware and
how software components are distributed across the
processors in the system.
● Related using use cases or scenarios (+1)
12/04/2021 Chapter 6 Architectural Design 21
Representing architectural views
● Some people argue that the Unified Modeling Language
(UML) is an appropriate notation for describing and
documenting system architectures
● I disagree with this as I do not think that the UML
includes abstractions appropriate for high-level system
description.
● Architectural description languages (ADLs) have been
developed but are not widely used
12/04/2021 Chapter 6 Architectural Design 22
Architectural patterns
12/04/2021 Chapter 6 Architectural Design 23
Architectural patterns
● Patterns are a means of representing, sharing and
reusing knowledge.
● An architectural pattern is a stylized description of good
design practice, which has been tried and tested in
different environments.
● Patterns should include information about when they are
and when the are not useful.
● Patterns may be represented using tabular and
graphical descriptions.
12/04/2021 Chapter 6 Architectural Design 24
The Model-View-Controller (MVC) pattern
Name MVC (Model-View-Controller)
Description Separates presentation and interaction from the system data. The system is
structured into three logical components that interact with each other. The
Model component manages the system data and associated operations on
that data. The View component defines and manages how the data is
presented to the user. The Controller component manages user interaction
(e.g., key presses, mouse clicks, etc.) and passes these interactions to the
View and the Model. See Figure 6.3.
Example Figure 6.4 shows the architecture of a web-based application system
organized using the MVC pattern.
When used Used when there are multiple ways to view and interact with data. Also used
when the future requirements for interaction and presentation of data are
unknown.
Advantages Allows the data to change independently of its representation and vice
versa. Supports presentation of the same data in different ways with
changes made in one representation shown in all of them.
Disadvantages Can involve additional code and code complexity when the data model and
interactions are simple.
12/04/2021 Chapter 6 Architectural Design 25
The organization of the Model-View-Controller
12/04/2021 Chapter 6 Architectural Design 26
Web application architecture using the MVC
pattern
12/04/2021 Chapter 6 Architectural Design 27
Layered architecture
● Used to model the interfacing of sub-systems.
● Organises the system into a set of layers (or abstract
machines) each of which provide a set of services.
● Supports the incremental development of sub-systems
in different layers. When a layer interface changes, only
the adjacent layer is affected.
● However, often artificial to structure systems in this way.
12/04/2021 Chapter 6 Architectural Design 28
The Layered architecture pattern
Name Layered architecture
Description Organizes the system into layers with related functionality
associated with each layer. A layer provides services to the
layer above it so the lowest-level layers represent core services
that are likely to be used throughout the system. See Figure
6.6.
Example
Loading…
A layered model of a system for sharing copyright documents
held in different libraries, as shown in Figure 6.7.
When used Used when building new facilities on top of existing systems;
when the development is spread across several teams with
each team responsibility for a layer of functionality; when there
is a requirement for multi-level security.
Advantages Allows replacement of entire layers so long as the interface is
maintained. Redundant facilities (e.g., authentication) can be
provided in each layer to increase the dependability of the
system.
Disadvantages In practice, providing a clean separation between layers is often
difficult and a high-level layer may have to interact directly with
12/04/2021 lower-level layers
Chapter rather than
6 Architectural through the layer immediately
Design 29
below it. Performance can be a problem because of multiple
