Architectural Design

 Establishing the overall structure of a

software system
 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

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

What is Architecture?
 A high-level model of a thing
• Describes critical aspects of the thing
• Understandable to many stakeholders
• Allows evaluation of the thing’s properties before it is built
• Provides well understood tools and techniques for constructing the thing
from its blueprint
 Which aspects of a software system are architecturally relevant?
 How should they be represented most effectively to enable
stakeholders to understand, reason, and communicate about a
system before it is built?
 What tools and techniques are useful for implementing an
architecture in a manner that preserves its properties?
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10 Slide 2
What is Software Architecture?
 A software system’s blueprint
• Its components
• Their interactions
• Their interconnections
 Informal descriptions
• Boxes and lines
• Informal prose
 A shared, semantically rich vocabulary
• Remote procedure calls (RPCs)
• Client-Server
• Pipe and Filer
• Layered
• Distributed
• Object-Oriented

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

From Requirements to
Architecture
 From problem definition to requirements specification
• Determine exactly what the customer and user want
• Specifies what the software product is to do
 From requirements specification to architecture
• Decompose software into modules with interfaces
• Specify high-level behavior, interactions, and non-functional properties
• Consider key tradeoffs
» Schedule vs. Budget
» Cost vs. Robustness
» Fault Tolerance vs. Size
» Security vs. Speed
• Maintain a record of design decisions and traceability
• Specifies how the software product is to do its tasks

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

Focus of Software Architectures
 Two primary foci A framework for
• System Structure understanding system-
• Correspondence between level concerns
requirements and
implementation • Global rates of flow
• Communication patterns
• Execution Control Structure
• Scalability
• Paths of System Evolution
• Capacity
• Throughput
• Consistency
• Component Compatibility

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

Why Software Architecture?
 A key to reducing development costs
• Component-based development philosophy
• Explicit system structure
 A natural evolution of design abstractions
• Structure and interaction details overshadow the choice of algorithms
and data structures in large/complex systems
 Benefits of explicit architectures
• A framework for satisfying requirements
• Technical basis for design
• Managerial basis for cost estimation & process management
• Effective basis for reuse
• Basis for consistency, dependency, and tradeoff analysis
• Avoidance of architectural erosion

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

 theStorag e
What is the Problem?
aWarehouse
This is a simple
UML-A Generated Association Class:aNavPoint Association (0.5)
(1.0)
software system!
aRoute

UML-A Generated Dependency Class:aRouteCollection Association (0.5)

UML -A Genera ted De pend ency C lass :aRou teCol lectio n Ass ociatio n (0. 25)
theVehicleCollection
UML-A Generated Association Class:aW arehouse Association (1.0)

aVehicle

UML-A Generated Dependency Class:theRouter Dependency (1.0)

UML-A Generated Dependency Class:theRouter Dependency (0.5)
UML-A Generated Dependency Class:theRouter UML-AAssociation
UML-A
Generated(0.25)
UML-A
Generated
Association
UML-A
Generated
Association
UML-A
Generated
Class:aNavPoint
Association
Generated
UML-A
Class:aNavPoint
Association
UML-AClass:aNavPoint
Gene
Association
UML-A
Association
rated
Class:aNavPoint
Genera
Association
Association
GeneratedClass:aNavPoint
Association
ted
(1.0)
Depend
Clas
(1.0)
Association
Association s:theW
ency
Association
(1.0)Class
areh
(1.0)
Class:theRouter ouseCollec
:aRouteCollectio
(1.0) tion Depen
Association n Assden
(0.25)oc
UML-AUML-A
Generated
UML-A
Genera
Association
UML-A
Generated
ted UML-A
AsGenerated
socia
Class:theVehicleCollection
Association
UML-A
Generated
tion CAssociation
UML-
lass:
Generated UML-A
Class:theVehicleCollection
A
Association
theVe
UML-A
GenhicleC dollec onGenerated
Class:theVehicleCollection
erate
Association
UML-A
Generated
Class:theVehicleCollection
UML-A
Ass
Generated
Generalization
ociati
tion
Class:theVehicleCollection
Association
Generated
Genera
Cl
Association
Generalization
ass:th
lizatio
(1.0) UML-A
nDependency nGenerated
Class:theRouter
Class:theVehicleCollection
Association
eVehi
Generalization
(1.
Class:theVehicleCollection
cleCo
0)
Generalization
(1.0) Dependency
Dependency
Class:theVehicleCollection
llectio
Generalization
(1.0)
Ge (1.0)
nerali
Generalization
zation
(1.0) Class:theRouter
Generalization (1.0) (1.0) Dependency (1.0)
(0.5)
(1.0Generalization
) (1.0)
aTruck aShip aAirplane theW areho useCo llecti on UML- A Ge nerate d Gen eraliz ation Class :avail ableV ehicle Colle ction Depe ndenc y (1.0 )
UML-A
UML-AGenerated
GeneratedAssociation
AssociationClass:theVehicleCollection
Class:availableVehicleCollection
Dependency
Dependency
(0.5) (0.5)
UML-A Generated Dependency Class:theRouter Association (0.5)
UML-A Generated Dependency Class:theRouter Association (0.25)

UML-A Generated Dependency Class:theRouter Dependency (1.0)

UML-A Generated Dependency Class:theRouter Dependency (1.0) UML-AUML-A
Generated
Generated
Association
Association
Class:aDifficiency
Class:aDifficiency
Association
Association
(1.0) (1.0)
t heRou ter UML-A UML-A
Generated
Generated
UML-A Association
Association
Generated
U ML-AU ML-A
Gen Class:aDifficiency
UML-A
erated
Gen Class:aDifficiency
Association
erated
Asso
Generated
ciatio
Asso Association
Class:aDifficiency
nciatio
Association
Cla ss:aD
n ClaAssociation
ss:aD
ifficie (1.0) (1.0)
Association
Class:aDifficiency
ncy
ifficie
A ncy
ssoci (1.
A atio
sso
UML-A UML-A
GeneratedGenerated
Association
Association
Class:aDiff
Clas
UML-A Generated Association Class:aNavPoint Association (0.25) UML-AUML-A Genera
Generated ted AssociClass:aSu
Association ation C la
UML-A Generated Association Class:aNavPoint Association (0.25)
UML-A Generated Association
UML-A Generated Class:aW arehouse
Association Class:aWAssociation
UML-A
arehouse (0.5)
Generated
Association UML-A Generated
Association
(1.0) Association
Class:aNavPoint Class:aNavPoint
Association (0.25) Association (0.25)
UML-A Generated Dependency Class:theWarehouseCollection Dependency (1.0)
availableVehicleCollection aRouteCollection
UML-A Generated Dependency Class:theRouter Association (1.0)
UML-A Generated Dependency Class:theRouter Association (0.5)
UML-A Generated Association Class:theW arehouseCollection Dependency (0.5)
UML-A Generated
UML-ADependency
Generated Dependency
Class:theRouter
Class:theRouter
Association Association
(1.0) (1.0)

theCarg oRouter

UML -A Genera ted As socia tion C lass: theWa rehou seCo llectio n De pende ncy ( 0.25)
UML-A Generated Association Class:aRoute Association (0.5)

theAWT aLocation
UML-A Generated Association Class:theRouter Association (0.25)

UML-A
UML-A
UML-A Generated Generated
Generated
Association Association
Association
Class:aNavPointClass:aRoute
Class:aRoute
Association Association
Association
(0.5) (0.25)
(0.25)
UML-A
UML-A Generated Generated Association
Association Class:aRoute
Class:aNavPoint
UML-A Association
Generated
Association (0.5) (0.25)
Association Class:aRoute Association (0.25)

aVehiceDialog aWarehouseDialog aPortDialog aRouterDialog aNavPoint

UML-A GeneratedUML-A Generated
Association AssociationAssociation
Class:aNavPoint Class:aW arehouse
(0.5) Association (0.5)
UML-A Generated Association Class:aW arehouse Association (0.5)

availableGoods aPortC ollec tion theTimeNeeded

UML-A Generated
UML-A Generated Association
Association Class:aWClass:aW
arehousearehouse Association
Association (0.5) (0.5)

UML-A Generated Association Class:aW arehouse Association (0.5)

aPort aSurp lus aDifficiency

UML-A Generated Association Class:aW arehouse Association (0.5)

UML-A Generated
UML-A
Association
Generated
Class:availableGoods
Association Class:aW
Association
arehouse(0.5)
Association (0.5)

©Ian Sommerville 2000 theGoods

Software Engineering, 6th edition. Chapter 10 Slide 7
 The Usual Tool: Design Abstraction
aTruck aAirplane aShip
aLocation

aVehicle

aNavPoint aRoute theVehicleCollection

theRouter
RegularStorage

aRouteCollection

theStorage availableVehicleCollection
aWarehouse
theWarehouseCollection

RefrigeratedStorage

aSurplus aDeficiency theCargoRouter

theGoods theTimeNeeded
aRouterDialog
aPort theAWT

availableGoods

aPortDialog

aVehiceDialog
aWarehouseDialog
aPortCollection

We have to do better!
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10 Slide 8
 Architectural Abstraction
Cl ock :
Cl ock

8: request

Cl ockConn

9: notification 10: notification

Warehouse Del iveryPort Vehicle

7: request

1: request
4: request 3: request
RouterConn

2: notification

CargoRouter

5: request

GraphicsConn

6: notification

GraphicsBinding :
GraphicsBinding

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

Definitions of Software Architecture
 Perry and Wolf
• Software Architecture = { Elements, Form, Rationale }
what how why
 Shaw and Garlan
• Software architecture [is a level of design that] involves
» the description of elements from which systems are built,
» interactions among those elements,
» patterns that guide their composition, and
» constraints on these patterns.
 Kruchten
• Software architecture deals with the design and implementation of the high-
level structure of software.
• Architecture deals with abstraction, decomposition, composition, style, and
aesthetics.

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

Architectural design process
 System structuring
• The system is decomposed into several principal sub-systems
• 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 11

Key Architectural Concepts
 Three canonical building blocks
• components
• connectors
• configurations
 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 12

Components
 A component is a unit of computation or a data store
 Components are loci of computation and state
• clients
• servers
• databases
• filters
• layers
• ADTs
 A component may be simple or composite
• composite components describe a (sub)system
• an architecture consisting of composite components describes a
system of systems

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

Connectors
 A connector is an architectural element that models
• interactions among components
• rules that govern those interactions
 Simple interactions
• procedure calls
• shared variable access
 Complex and semantically rich interactions
• client-server protocols
• database access protocols
• asynchronous event multicast
• piped data streams

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

 Configurations/Topologies
 An architectural configuration or topology is a connected
graph of components and connectors that describes
architectural structure
• proper connectivity
• concurrent and distributed properties
• adherence to design heuristics and style rules
 Composite components are configurations
A C1 C2

B C C3 C4 C5

D C6 C7

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

Scope of Software Architectures
 Every system has an architecture.
 Details of the architecture are a reflection of system
requirements and trade-offs made to satisfy them
 Possible decision factors
• Performance
• Compatibility with legacy software
• Planning for reuse
• Distribution profile
» Current and Future
• Safety, Security, Fault tolerance requirements
• Evolvability Needs
» Changes to processing algorithms
» Changes to data representation
» Modifications to the structure/functionality

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

Example Architecture – Compiler
Sequential Parallel

Lexer Lexer Parser Semantor

Parser

Internal
Representation
Semantor

Optimizer
Code
Optimizer Generator
Code
Generator
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10 Slide 17
CASE toolset architecture
Design Code
editor generator

Design Project Program

translator repository editor

Design Report
analyser generator

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

Version management system
Version management

Object management

Database system
Operating
system

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

Packing robot control system
Vision
system

Object Arm Gripper

identification controller controller
system

Packaging
selection
system

Packing Conveyor
system controller

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

Film and picture library
Client 1 Client 2 Client 3 Client 4

Wide-bandwidth network

Catalogue Video Picture Hypertext

server server server server

Catalogue Film clip Digitiz ed Hypertext

files photographs web

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

Analogies to Software Architecture
 Hardware architecture
• small number of design elements
• scale by replication of (canonical) design elements
 Network architecture
• focus on topology
• only a few topologies considered
» e.g., star, ring, grid

 Building architecture
• multiple views
• styles

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

Architectural models
 Different architectural models may be produced
during the design process
 Each model presents different perspectives on the
architecture
• 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
• Deployment model shows the relationship between system
elements and hosts

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

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 24

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
 Key architectural concepts are components,
connectors, and configurations

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