Objectives
z To Establish the overall structure of a software
system
z To introduce architectural design and to discuss
its importance
z To explain why multiple models are required to
document a software architecture
z To describe types of architectural model that may
be used
Software Engineering, Architectural Design Slide 1
What is Software architecture?
Architectural design is the design process for:
z identifying the sub-systems making up a
system, and
z the framework for sub-system control and
communication
z The output of this design process is a description
of the software architecture
Software Engineering, Architectural Design Slide 2
Architectural design
z Identify system components and their
communications
System Components –
Sub systems
Sub system 1
Sub system 2
communication
Software Engineering, Architectural Design Slide 3
Architectural design
z An early stage of the system design process
z Represents the link between specification and
design processes
z It involves identifying:
• major system components and
• their communications
Software Engineering, Architectural Design Slide 4
Advantages of explicit architecture
z Stakeholder communication
• Architecture may be used as a focus of discussion by system
stakeholders
z System analysis
• Means that analysis of whether the system can meet its non-
functional requirements is possible
Software Engineering, Architectural Design Slide 5
Architectural design process
z System structuring
• The system is decomposed into several principal sub-systems
and communications between these sub-systems are identified
z Control modelling
• A model of the control relationships between the different
parts of the system is established
z Modular decomposition
• The identified sub-systems are decomposed into modules
Software Engineering, Architectural Design Slide 6
Architectural models
z Static structural model that shows the major system
components
z Dynamic process model that shows the process structure
of the system
z Interface model that defines sub-system interfaces
z Relationships model such as a data-flow model
Software Engineering, Architectural Design Slide 7
Architecture attributes
z Performance
• Localise operations to minimise sub-system communication
z Security
• Use a layered architecture with critical assets in inner layers
z Safety
• Isolate safety-critical components
z Availability
• Include redundant components in the architecture
z Maintainability
• Use fine-grain, self-contained components
Software Engineering, Architectural Design Slide 8
Architectural design process: System
structuring
z Concerned with decomposing the system into interacting
sub-systems
z The architectural design is normally expressed as a
block diagram presenting an overview of the
system structure
z More specific models showing how sub-systems share
data, are distributed and interface with each other may
also be developed
Software Engineering, Architectural Design Slide 9
Example: Architectural design for
“Packing robot control system” Packing robot
Vision control system
system
Vision Subsystem
Object Arm Gripper
identification controller controller
system
Packaging
Arm controller sub selection
system
Packing Conveyor
system controller
Software Engineering, Architectural Design Slide 10
The repository model
z 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
z When large amounts of data are to be shared, the
repository model of sharing is most commonly
used
Software Engineering, Architectural Design Slide 11
Example: repository model for
CASE toolset architecture
Design Code
editor generator
subsystem Data repository
Design Project Program
translator repository editor
Design Report
analyser generator
Software Engineering, Architectural Design Slide 12
Repository model characteristics
z 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
z 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
Software Engineering, Architectural Design Slide 13
Client-server architecture
z Distributed system model which shows how data and
processing is distributed across a range of components
z Set of stand-alone servers which provide specific
services such as printing, data management, etc.
z Set of clients which call on these services
z Network which allows clients to access servers
Software Engineering, Architectural Design Slide 14
Example: Client-server architecture
for Film and picture library
Set of clients
Client 1 Client 2 Client 3 Client 4
Wide-bandwidth network
Catalogue Video Picture Hypertext
server server server server
Catalogue Film clip Digitized Hypertext
files photographs web
Set of servers
Software Engineering, Architectural Design Slide 15
Client-server characteristics
z 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
z 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
Software Engineering, Architectural Design Slide 16
Abstract machine model
z Used to model the interfacing of sub-systems
z Organises the system into a set of layers (or
abstract machines) each of which provide a set of
services
z Supports the incremental development of sub-
systems in different layers. When a layer
interface changes, only the adjacent layer is
affected
z However, often difficult to structure systems in
this way
Software Engineering, Architectural Design Slide 17
Example: Abstract machine model
for Version management system
Version management
Object management
Database system
Operating
system
Software Engineering, Architectural Design Slide 18
Control models
z Distinct from the system decomposition model
z Concerned with the control flow between sub-systems.
z Centralised control
• One sub-system has overall responsibility for
• control,
• Starts, and
• stops other sub-systems
z Event-based control
• Each sub-system can respond to externally generated events from
other sub-systems or the system’s environment
Software Engineering, Architectural Design Slide 19
Centralised control
z A control sub-system takes responsibility for
managing the execution of other sub-systems
z Two models of centralised control:
1. Call-return control model
2. Manager control model
Software Engineering, Architectural Design Slide 20
Centralised control:
Call-return control model
z Top-down subroutine model
z Control starts at the top of a subroutine hierarchy
and moves downwards.
z Applicable to sequential systems
Software Engineering, Architectural Design Slide 21
Example: Call-return control model
Main
program
Routine 1 Routine 2 Routine 3
Routine 1.1 Routine 1.2 Routine 3.1 Routine 3.2
Software Engineering, Architectural Design Slide 22
Centralised control:
Manager control model
z Applicable to concurrent systems.
z One system component controls
• the stopping,
• starting and
• coordination of other system processes.
z Can be implemented in sequential systems as a
case statement
Software Engineering, Architectural Design Slide 23
Example: Manager control model for
Real-time system control
Sensor Actuator
processes processes
System
controller
Computation User Fault
processes interface handler
Software Engineering, Architectural Design Slide 24
Event-driven systems
z Driven by externally generated events where the
timing of the event is out with the control of the
sub-systems which process the event
z 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
z Other event driven models include spreadsheets
and production systems
Software Engineering, Architectural Design Slide 25
Event-driven systems:
Broadcast model
z Effective in integrating sub-systems on different
computers in a network
z Sub-systems register an interest in specific
events.
• When these occur, control is transferred to the sub-system
which can handle the event
z 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
Software Engineering, Architectural Design Slide 26
Event-driven systems:
Selective broadcasting
Sub-system Sub-system Sub-system Sub-system
1 2 3 4
Event and message handler
Software Engineering, Architectural Design Slide 27
Event-driven systems:
Interrupt-driven systems
z Used in real-time systems where fast response
to an event is essential
z There are known interrupt types with a handler
defined for each type
z Each type is associated with a memory location
and a hardware switch causes transfer to its
handler
z Allows fast response but complex to program and
difficult to validate
Software Engineering, Architectural Design Slide 28
Event-driven systems:
Interrupt-driven control
Interrupts
Interrupt
vector
Handler Handler Handler Handler
1 2 3 4
Process Process Process Process
1 2 3 4
Software Engineering, Architectural Design Slide 29
Modular decomposition
z Another structural level where sub-systems are
decomposed into modules
z 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
z If possible, decisions about concurrency should
be delayed until modules are implemented
Software Engineering, Architectural Design Slide 30
Modular decomposition:
Object models
z Structure the system into a set of loosely coupled objects
with well-defined interfaces
z Object-oriented decomposition is concerned with
identifying object classes, their attributes and operations
z When implemented, objects are created from these classes
and some control model used to coordinate object
operations
Software Engineering, Architectural Design Slide 31
Example: Object models for Invoice
processing system
Customer Receipt
customer# invoice#
name date
address Invoice amount
credit period customer#
invoice#
date
amount
customer
Payment issue ()
invoice# sendReminder ()
date acceptPayment ()
amount sendReceipt ()
customer#
Software Engineering, Architectural Design Slide 32
Modular decomposition:
Data-flow models
z Functional transformations process their inputs to
produce outputs
z May be referred to as a pipe and filter model (as
in UNIX shell)
z 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
z Not really suitable for interactive systems
Software Engineering, Architectural Design Slide 33
Example: Data-flow models for
Invoice processing system
Issue
Receipts
receipts
Read issued Identify
invoices payments
Find Issue
payments payment Reminders
due reminder
Invoices Payments
Software Engineering, Architectural Design Slide 34
Domain-specific architectures
z Architectural models which are specific to some
application domain
z 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
z Generic models are usually bottom-up models;
Reference models are top-down models
Software Engineering, Architectural Design Slide 35
Generic models
z 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
z Generic compiler model may be organised
according to different architectural models
Software Engineering, Architectural Design Slide 36
Compiler model
Symbol
table
Lexical Syntactic Semantic Code
analysis analysis analysis generation
Software Engineering, Architectural Design Slide 37
Language processing system
Lexical Syntax Semantic
analyser analyser analyser
Pretty- Abstract Grammar
printer Optimizer
syntax tree definition
Symbol Output Code
Editor
table definition generator
Repository
Software Engineering, Architectural Design Slide 38
Reference architectures
z Reference models are derived from a study of the
application domain rather than from existing
systems
z 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
z OSI model is a layered model for communication
systems
Software Engineering, Architectural Design Slide 39
OSI reference model
7 Application
Application Application
6 Presentation Presentation
5 Session Session
4 Transport Transport
3 Network Network Network
2 Data link Data link Data link
1 Physical Physical Physical
Communications medium
Software Engineering, Architectural Design Slide 40
