Architectural Design

● Establishing the overall 
structure of a software system

©Ian Sommerville 2000  Software Engineering, 6th edition. Chapter 10 Slide 1

Objectives
● To introduce architectural design and to discuss 
its importance
● To explain why multiple models are required to 
document a software architecture
● To describe types of architectural model that may 
be used
● To discuss how domain­specific reference models 
may be used as a basis for product­lines and to 
compare software architectures

©Ian Sommerville 2000  Software Engineering, 6th edition. Chapter 10 Slide 2

Topics covered
● System structuring
● Control models
● Modular decomposition
● Domain­specific architectures

©Ian Sommerville 2000  Software Engineering, 6th edition. Chapter 10 Slide 3

Software architecture
● The design process for identifying the sub­
systems making up a system and the framework 
for sub­system control and communication is 
architectural design
● The output of this design process is a description 
of the software architecture

©Ian Sommerville 2000  Software Engineering, 6th edition. Chapter 10 Slide 4

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

©Ian Sommerville 2000  Software Engineering, 6th edition. Chapter 10 Slide 5

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

©Ian Sommerville 2000  Software Engineering, 6th edition. Chapter 10 Slide 6

Architectural design process
● System structuring
• The system is decomposed into several principal sub­systems 
and communications between these sub­systems are identified
● Control modelling
• A model of the control relationships between the different parts 
of the system is established
● Modular decomposition
• The identified sub­systems are decomposed into modules

©Ian Sommerville 2000  Software Engineering, 6th edition. Chapter 10 Slide 7

Sub­systems and 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

©Ian Sommerville 2000  Software Engineering, 6th edition. Chapter 10 Slide 8

Architectural models
● Different architectural models may be produced 
during the design process
● Each model presents different perspectives on the 
architecture

©Ian Sommerville 2000  Software Engineering, 6th edition. Chapter 10 Slide 9

Architectural models
● Static structural model that shows the major 
system components
● Dynamic process model that shows the process 
structure of the system
● Interface model that defines sub­system 
interfaces
● Relationships model such as a data­flow model

©Ian Sommerville 2000  Software Engineering, 6th edition. Chapter 10 Slide 10

Architectural styles
● The architectural model of a system may conform 
to a generic architectural model or style
● An awareness of these styles can simplify the 
problem of defining system architectures
● However, most large systems are heterogeneous 
and do not follow a single architectural style

©Ian Sommerville 2000  Software Engineering, 6th edition. Chapter 10 Slide 11

Architecture attributes
● Performance
• Localise operations to minimise sub­system communication
● Security
• Use a layered architecture with critical assets in inner layers
● Safety
• Isolate safety­critical components
● Availability
• Include redundant components in the architecture
● Maintainability
• Use fine­grain, self­contained components

©Ian Sommerville 2000  Software Engineering, 6th edition. Chapter 10 Slide 12

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
● More specific models showing how sub­systems 
share data, are distributed and interface with each 
other may also be developed

©Ian Sommerville 2000  Software Engineering, 6th edition. Chapter 10 Slide 13

 V
iidenO
sty
tsybe o
n
m
jifecam
tionconA
Packing robot control system

rtm
o
l
e
r G
rconitpoler
P
aseclykegitm
n
o
©Ian Sommerville 2000 
Pasycktein
mCg o
ctrl n veyo
r
Software Engineering, 6th edition. Chapter 10 Slide 14
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 may 
be accessed by all sub­systems
• Each sub­system maintains its own database and passes data 
explicitly to other sub­systems
● When large amounts of data are to be shared, the 
repository model of sharing is most commonly 
used

©Ian Sommerville 2000  Software Engineering, 6th edition. Chapter 10 Slide 15

 D e D
stranliagtnor D e
dstig
on
rP
r
oj
e
c
tC
g
e
no
d
e
r
a
t
r P
r
o
g
a
m
e
ps
i
r
y e
d
i
t
r
CASE toolset architecture

e
sanlyign
©Ian Sommerville 2000 
R
ep
o
r
t
ergna
Software Engineering, 6th edition. Chapter 10 Slide 16
Repository model characteristics
● Advantages
• Efficient way to share large amounts of data
• Sub­systems need not be concerned with how data is produced 
Centralised management e.g. backup, security, etc.
• Sharing model is published as the repository schema
● 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 efficiently

©Ian Sommerville 2000  Software Engineering, 6th edition. Chapter 10 Slide 17

Client­server architecture
● Distributed system model which shows how data 
and processing is distributed across a range of 
components
● Set of stand­alone servers which provide specific 
services such as printing, data management, etc.
● Set of clients which call on these services
● Network which allows clients to access servers

©Ian Sommerville 2000  Software Engineering, 6th edition. Chapter 10 Slide 18

 C lient 1C lienW
Film and picture library
t 2ide­bandw C
lith netw
ieonrtk 3C lient 4
C
aC
tasterllvogue
ogueFV
s
ilfm i
rd
v e o
 ecslippD P
si
ect
vu re H
y
s
ihogtizraepdhsHp
yp
ewer
v tx
rbtx
©Ian Sommerville 2000  Software Engineering, 6th edition. Chapter 10 Slide 19
Client­server characteristics
● Advantages
• Distribution of data is straightforward
• Makes effective use of networked systems. May require 
cheaper hardware
• 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

©Ian Sommerville 2000  Software Engineering, 6th edition. Chapter 10 Slide 20

Abstract machine model
● 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 difficult to structure systems in 
this way
©Ian Sommerville 2000  Software Engineering, 6th edition. Chapter 10 Slide 21
 V
eO
rb
sD
ijaO
o n
 ctpbam
asret ninyg
egstemn
tm
syem
Version management system

©Ian Sommerville 2000  Software Engineering, 6th edition. Chapter 10 Slide 22

Control models
● Are concerned with the control flow between 
sub­systems. Distinct from the system 
decomposition model
● Centralised control
• One sub­system has overall responsibility for control and starts 
and stops other sub­systems
● Event­based control
• Each sub­system can respond to externally generated events 
from other sub­systems or the system’s environment

©Ian Sommerville 2000  Software Engineering, 6th edition. Chapter 10 Slide 23

Centralised control
● A control sub­system takes responsibility for 
managing the execution of other sub­systems
● Call­return model
• Top­down subroutine model where control starts at the top of a 
subroutine hierarchy and moves downwards. Applicable to 
sequential systems
● Manager model
• Applicable to concurrent systems. One system component 
controls the stopping, starting and coordination of other system 
processes. Can be implemented in sequential systems as a case 
statement

©Ian Sommerville 2000  Software Engineering, 6th edition. Chapter 10 Slide 24

 R
o
u
ti
n
e
 
1
Call­return model
M
a
p
r
o
g
R
o
u
t
ii
n
m
n
e
 
2 R
o
u
t
in
e
 
3
R
outine 1.Routine 1.2Routine 3.1Routine 3.2
©Ian Sommerville 2000  Software Engineering, 6th edition. Chapter 10 Slide 25
 Sens
o
r
procecSy s
t e m A
c
t
u
a
p
r
o
e
so r
on ro l
r
Real­time system control

C
om
p u
trcesaioninU
©Ian Sommerville 2000 
stfearc hF
anu
ldter
Software Engineering, 6th edition. Chapter 10 Slide 26
Event­driven systems
● Driven by externally generated events where the 
timing of the event is outwith the control of the 
sub­systems which process the event
● Two principal event­driven models
• Broadcast models. An event is broadcast to all sub­systems. 
Any sub­system which can  handle the event may do so
• Interrupt­driven models. Used in real­time systems where 
interrupts are detected by an interrupt handler and passed to 
some other component for processing
● Other event driven models include spreadsheets 
and production systems
©Ian Sommerville 2000  Software Engineering, 6th edition. Chapter 10 Slide 27
Broadcast model
● Effective in integrating sub­systems on different 
computers in a network
● Sub­systems register an interest in specific 
events. When these occur, control is transferred 
to the sub­system which can handle the event
● Control policy is not embedded in the event and 
message handler. Sub­systems decide on events 
of interest to them
● However, sub­systems don’t know if or when an 
event will be handled
©Ian Sommerville 2000  Software Engineering, 6th edition. Chapter 10 Slide 28
S
ub­s1ytemS
ub­s2
y
tE em
Selective broadcasting

vent and m S ub­s
3yt
e
m
esage handler S
u
b
­
s
y
t
e
m
4
©Ian Sommerville 2000  Software Engineering, 6th edition. Chapter 10 Slide 29
Interrupt­driven systems
● Used in real­time systems where fast response to 
an event is essential
● There are known interrupt types with a handler 
defined for each type
● Each type is associated with a memory location 
and a hardware switch causes transfer to its 
handler
● Allows fast response but complex to program and 
difficult to validate

©Ian Sommerville 2000  Software Engineering, 6th edition. Chapter 10 Slide 30

 IH n
tandlevrecrouptH
Interrupt­driven control
I
n
t
er
u
p
t
s
P 1
ro1cesP an2dle
r
ro2cesPH
an3d l
e
r
ro3cesPH
an4dle
r
ro4ces
©Ian Sommerville 2000  Software Engineering, 6th edition. Chapter 10 Slide 31
Modular decomposition
● Another structural level where sub­systems are 
decomposed into modules
● Two modular decomposition models covered
• An object model where the system is decomposed into 
interacting objects
• A data­flow model where the system is decomposed into 
functional modules which transform inputs to outputs. Also 
known as the pipeline model
● If possible, decisions about concurrency should 
be delayed until modules are implemented

©Ian Sommerville 2000  Software Engineering, 6th edition. Chapter 10 Slide 32

Object models
● Structure the system into a set of loosely coupled 
objects with well­defined interfaces
● Object­oriented decomposition is concerned with 
identifying object classes, their attributes and 
operations
● When implemented, objects are created from 
these classes and some control model used to 
coordinate object operations

©Ian Sommerville 2000  Software Engineering, 6th edition. Chapter 10 Slide 33

 C u
tcncudaestroitm s o m e
r
e sperr#iod idnm
I
n
v
v
o
i
c
e
#o
i
c
e R
i
n
v
o
i
d
a
t
m
u
c
s
oe
c
i
#
n
t
m
e
r
#p
t
a
t
Invoice processing system

idcnm
v o P
iatseoucma y m
#
nter# cpent c
i
s
a u
n
t
s
o
m
u
 
(
)
e
n
d
R
e
c
p
t
Pe
r
m
i
n
d
a
ye
r
 
(
)
t
©Ian Sommerville 2000  Software Engineering, 6th edition. Chapter 10 Slide 34
Data­flow models
● Functional transformations process their inputs to 
produce outputs
● May be referred to as a pipe and filter model (as 
in UNIX shell)
● Variants of this approach are very common. 
When transformations are sequential, this is a 
batch sequential model which is extensively used 
in data processing systems
● Not really suitable for interactive systems

©Ian Sommerville 2000  Software Engineering, 6th edition. Chapter 10 Slide 35

R
eiaInnd
 vo
ivoscicueesdpP
Iadayeym
nm r
eIs
c
tiefnysts payF u
i
pe
t
s R eci
p ts
Invoice processing system

im
nd Isu
eutsrpeaym e
n
tidr R
em
inders
©Ian Sommerville 2000  Software Engineering, 6th edition. Chapter 10 Slide 36
Domain­specific architectures
● Architectural models which are specific to some 
application domain
● Two types of domain­specific model
• Generic models which are abstractions from a number of real 
systems and which encapsulate the principal characteristics of 
these systems
• Reference models which are more abstract, idealised model. 
Provide a means of information about that class of system and 
of comparing different architectures
● Generic models are usually bottom­up models; 
Reference models are top­down models

©Ian Sommerville 2000  Software Engineering, 6th edition. Chapter 10 Slide 37

Generic models
● Compiler model is a well­known example 
although other models exist in more specialised 
application domains
• Lexical analyser
• Symbol table
• Syntax analyser
• Syntax tree
• Semantic analyser
• Code generator
● Generic compiler model may be organised 
according to different architectural models
©Ian Sommerville 2000  Software Engineering, 6th edition. Chapter 10 Slide 38
 eanxliycsalS
L y
Compiler model

n Sy
m
b
o
t
a
el
talacsi S
eanm
alynsticgenC
ord
eation
©Ian Sommerville 2000  Software Engineering, 6th edition. Chapter 10 Slide 39
 L
e x
ianlycsaelraS yn
tlasx
e
rS
ae
m
a
n
n
l
yt
i
c
s
e
r
P
rp
e
tE
­diny
ritorsyS Ab
s
ny t
r
x
 tamact
e G
r
a
m
d
e
f
i
na
r
t
o
n O
p
t
i
m
ze
r
Language processing system

beolR O
u
t
d
e
f
i
n
epositryp
o
n C
o
d
e
g
e
n
r
a
tr
©Ian Sommerville 2000  Software Engineering, 6th edition. Chapter 10 Slide 40
Reference architectures
● Reference models are derived from a study of the 
application domain rather than from existing 
systems
● May be used as a basis for system 
implementation or to compare different systems. 
It acts as a standard against which systems can be 
evaluated
● OSI model is a layered model for communication 
systems

©Ian Sommerville 2000  Software Engineering, 6th edition. Chapter 10 Slide 41

 7654A lP
iS
tT
r
rpe
as
ni
sn
oc
p a
o
n
i
r
t A
p
l
i
c
a
P
r
e
s
n
S
i
o
T
r
a
n
s
pt
o
n
i
r
t
321N
eD
tP w o k N e
t wo rk N
e
t
w
ok
OSI reference model

ahys lcianCD
lPa
 om
iuhnyiscatnions m D
a
 
l
i
n
P
h
y
s
c
a
Application

©Ian Sommerville 2000 
edium
Software Engineering, 6th edition. Chapter 10 Slide 42
Key points
● The software architect is responsible for deriving 
a structural system model, a control model and a 
sub­system decomposition model
● Large systems rarely conform to a single 
architectural model
● System decomposition models include repository 
models, client­server models and abstract 
machine models
● Control models include centralised control and 
event­driven models
©Ian Sommerville 2000  Software Engineering, 6th edition. Chapter 10 Slide 43
Key points
● Modular decomposition models include data­flow 
and object models
● Domain specific architectural models are 
abstractions over an application domain. They 
may be constructed by abstracting from existing 
systems or may be idealised reference models

©Ian Sommerville 2000  Software Engineering, 6th edition. Chapter 10 Slide 44