Chapter 7:

Architectural Design
 Objectives
• Introducing architectural design & its
importance
• Understand the decisions that have to be
made about the system architecture during
the architectural design process;
• Introducing 3 architectural styles
i. Organisation ii. Decomposition iii. Control
 Topics covered
• Architectural design decisions
• System organisation, architectural views
and architectural patterns
• Application architectures
• Control styles
 Software Architecture
☺Identifying the sub-systems/components that
make up a system and the framework for sub-
systems control & communication is known as
the architectural design.

☺It can serve as a design plan to negotiate

system requirements among clients, developers
and managers.

Process output: is an architectural model that

describes how the system is organized as a set
of communicating components.
 Architectural design
• An early stage of the system design process.
• Represents the link between
specification and design processes.
• Often carried out in parallel with some
specification activities.
• It involves identifying major system
components and their communications.
 Two levels of Abstraction for the
Software Architectural Design
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.
2. Architecture in the large is concerned with the
architecture of complex enterprise systems that
include other systems, programs, and program
components (distributed systems).
 Advantages of the explicit architecture

• System stakeholder communication

– Architecture will be a focus of discussion by stakeholders.

• Effects on none-functional requirements

– Architecture design decisions have effects on whether the system can
meet critical requirements such as performance, reliability and
maintainability.

• Large-scale reuse
– The architecture may be reusable for a range of systems.
 System Architects Vs Decisions
• 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 a set of fundamental questions
about the system.
 Fundamental Questions
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 processors?
3. What architectural patterns or styles might be used?
4. What is the fundamental approach 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?
 Architecture Vs System Characteristics
• Performance (if Performance is a critical requirement)
 Localize critical operations & minimize communications. Use large rather
than fine-grain components.
• Security (if Security is a critical requirement)
 Use a layered architecture with critical assets in the innermost layers, with a
high level of security validation.
• 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 small number of components.
• Availability (if Availability is a critical requirement)
 Include redundant components and mechanisms, so that it is possible to
replace and update components without stopping the system (fault tolerance).
• Maintainability (if Maintainability is a critical requirement)
 Use fine-grain, self-contained components that may easily be changed or
replaced.
 Architectural Conflicts
• Large-grain components improves
performance but reduces maintainability.
• Redundant data improves availability but
makes security more difficult.
• Localizing safety features means more
communication so degraded performance.
 Compromise solution must be found;
different architecture styles for different
parts of the system can be applied!
 System Structuring
• Concerned with decomposing the system into
interacting sub-systems.

• The architectural design is normally expressed

as a block diagram presenting an overview of
the system structure.
Packing robot control system
Vision
system

Object Arm Gripper

identifica tion contr oller contr oller
system

Packag ing
selection
system

Packing Con veyor

system contr oller
 System Organization
Reflects the basic strategy that is used to
structure a system.

• Three widely used organizational styles:

(1). Shared Data Repository Model;
(2). Client-Server Model;
(3). Layered Model.
 (1). The Repository Model
• Sub-systems must exchange data. This may be
done in two ways:
– Shared data is held in a central database or
repository and accessed by all sub-systems;
– Each sub-system maintains its own database and
passes data explicitly to other sub-systems.

 For large amounts of shared data, the

repository model is most commonly used.
 Example: CASE Toolset Architecture

Design Code
editor gener ator

Design Project Pr ogram

transla tor repository editor

Design Repor t
analyser gener ator
 Repository Model Evaluation
(+) Advantages
– Efficient way to share large amounts of data;
– Centralised management e.g. backup, security, etc.
– Easy to integrate new tools to share the repository.

(-) Disadvantages
– Sub-systems must agree on a repository data model. Inevitably a
compromise;
– Data evolution is difficult and expensive;
– No scope for specific management policies;
– Difficult to distribute the repository efficiently to multi-sys.
 (2). The Client-Server Model

• Set of servers; each provides a specific service

such as printing, file management or email.

• All clients call on these servers through a

network that allows them to access services .
Example: Film & Picture Library

Client 1 Client 2 Client 3 Client 4

Internet

Catalo gue Video Pictur e

Web serv er
server server server
Library Film clip Digitis ed Film and
catalo gue files photo g raphs photo info.
 Client-server Evaluation
(+) Advantages
– Effective distribution and use of networked systems.
– Easy to add new servers or upgrade existing servers.

(+) Disadvantages
– No shared data model so sub-systems use different data organisation.
Data interchange may be inefficient;
– Redundant management in each server;
– No central register of names and services - it may be hard to find out
what servers and services are available.
 (3). The Layered Model
• Used to model the interfacing of sub-systems.
• Organizes the system into a set of layers 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.
 A Generic Layered Architecture
Pattern for Software Applications
 An example of layered architecture pattern
How it can be applied to a library system ( LIBSYS)
Example: The OSI Reference Model
User

Application 7

Presentation 6

Session 5

Transport 4

Network 3

Data-Link 2

Physical 1

Communications
media
 Modular Decomposition Styles
• Styles of decomposing sub-systems into
Modules.

 No rigid distinction between system

organization (sub-systems) and modular
decomposition (modules).
 Sub-systems Vs Modules
• A sub-system is a system in its own right whose operation is
independent of the services provided by other sub-systems.

• A module is a system component that provides services to

other components but would not normally be considered as a
separate system.

•  sub-systems are decomposed into modules

 Control styles
• Are concerned with the control flow between
sub-systems. Distinct from the system
decomposition model.
(i). Centralized control
– One sub-system has overall responsibility for
control and starts and stops other sub-systems.
(ii). Event-based control
– Each sub-system can respond to externally
generated events from other sub-systems or the
system’s environment.