Architectural Design

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.
 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.
 Architectural Design

Establishing the overall structure

of a software system
 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?
 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
 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
 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
Packing robot control system
 Reference architectures

 Architectural models may be 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.
 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.
OSI reference model

7 Ap plicatio n Ap plicatio n

6 Presenta tio n Presenta tio n

5 Session Session

4 Transp or t Transp or t

3 Netwo rk Netwo rk Netwo rk

2 Data link Data link Data link

1 Phy sical Phy sical Phy sical

Co m m unica tio ns medium

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
Stakeholders

 Architect
 Requirements engineer
 Designer (also of other systems)
 Implementor
 Tester, integrator
 Maintainer
 Manager
 Quality assurance people

SE, Software
Architecture,
17
Hans van Vliet,
©2008
Role of the software architect

 Key technical consultant

 Make decisions
 Coach of development team
 Coordinate design
 Implement key parts
 Advocate software architecture

SE, Software
Architecture,
18
Hans van Vliet,
©2008
 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
 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 (Abstract Data types)
 A component may be simple or composite
 composite components describe a (sub)system
 an architecture consisting of composite components describes a system of
systems
 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
 Components and Connectors

 Components are connected by connectors.

 They are the building blocks with which an architecture can be
described.
 No standard notation has emerged yet.

SE, Software
Architecture,
22
Hans van Vliet,
©2008
 Types of components

 computational: does a computation of some sort. E.g. function, filter.

 memory: maintains a collection of data. E.g. data base, file system, symbol
table.
 manager: contains state + operations. State is retained between
invocations of operations. E.g. server.
 controller: governs time sequence of events. E.g. control module,
scheduler.

SE, Software
Architecture,
23
Hans van Vliet,
©2008
Types of connectors

 procedure call (including RPC)

 data flow (e.g. pipes)
 implicit invocation
 message passing
 shared data (e.g. blackboard or shared data base)
 instantiation

SE, Software
Architecture,
24
Hans van Vliet,
©2008
 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
26 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 models. The

requirements for model semantics depends on how the
Chapter 6 Architectural design

models are used.

27 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.

Chapter 6 Architectural design

 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.
CASE toolset architecture
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;
 Difficult to distribute efficiently.
 Client-server model

 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.

Film and picture library
Client-server characteristics
 Advantages
 Distribution of data is straightforward;
 Makes effective 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.
Abstract machine (layered) model OR
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.
35 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.

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 reliability 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 lower-level layers rather than
through the layer immediately below it. Performance can be a problem because of
multiple levels of interpretation of a service request as it is processed at each
layer.

Chapter 6 Architectural design

Version management system

Configuration management system layer

Object management system lay er

Database system layer

Operating system layer

37 A generic layered architecture

Chapter 6 Architectural design

38 The architecture of the LIBSYS system

Chapter 6 Architectural design

 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.
Invoice processing system
Object model advantages

 Objects are loosely coupled so their implementation can be modified

without affecting other objects.
 The objects may reflect real-world entities.
 OO implementation languages are widely used.
 However, object interface changes may cause problems and complex
entities may be hard to represent as objects.
 Function-oriented pipelining
 Functional transformations process their inputs to
produce outputs.

 May be referred to as a pipe and filter model.

 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.
Invoice processing system
 Pipeline model advantages

 Supports transformation reuse.

 Easy to add new transformations.
 Relatively simple to implement as either a concurrent or
sequential system.
 However, requires a common format for data transfer
along the pipeline.
Use of architectural models

 Used to document an architectural design.

 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 that shows
sub-system relationships.
 Distribution model that shows how sub-systems are distributed
across computers.
46 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.

Chapter 6 Architectural design

Architectural Design
Decisions
48 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.

Chapter 6 Architectural design

49 Architectural design decisions

 Is there a generic application architecture that can be used?

 How will the system be distributed?
 What architectural styles are appropriate?
 What approach will be used to structure the system?
 How will the system be decomposed into modules?
 What control strategy should be used?
 How will the architectural design be evaluated?
 How should the architecture be documented?

Chapter 6 Architectural design

 Types of decisions

 Implicit, undocumented
 tacit, of course knowledge
 Explicit, undocumented
 Vaporizes over time
 Explicit, explicitly undocumented
 Tactical, personal reasons
 Explicit, documented
 Preferred, exceptional situation

SE, Software
Architecture,
50
Hans van Vliet,
©2008
Why is documenting design decisions
important?
 Prevents repeating (expensive) past steps
 Explains why this is a good architecture
 Emphasizes qualities and criticality for
requirements/goals
 Provides context and background

SE, Software
Architecture,
51
Hans van Vliet,
©2008
Uses of design decisions
 Identify key decisions for a stakeholder
 Make the key decisions quickly available. E.g., introducing new people and
make them up2date.
 ..., Get a rationale, Validate decisions against reqs
 Evaluate impact
 If we want to change an element, what are the elements impacted (decisions,
design, issues)?
 ..., Cleanup the architecture, identify important architectural drivers

SE, Software
Architecture,
52
Hans van Vliet,
©2008
 Elements of a design decision

 Issues: design issues being addressed

 Decision
 Status: e.g., pending, approved
 Assumptions: underlying assumptions
 Alternatives
 Rationale; the why of the decision taken
 Implications: e.g. need for further decisions

SE, Software
Architecture,
53
Hans van Vliet,
©2008
 Taking decisions

Design Problem
problem space

sub- sub-
problem problem
(or (or
issue) issue)

Decision =
best option Decision
space
Design Design Design Design
option option option option

Decision =
Alternative Alternative best option
solutions solutions
SE, Software
Architecture,
54
Hans van Vliet,
©2008
 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
Example Architecture – Compiler

Sequential Parallel

Lexer Lexer Parser Semantor

Parser

Internal
Representation
Semantor

Optimizer
Code
Optimizer Generator
Code
Generator
Version management system

Version management

Object management

Database system
Operating
system
Packing robot control system
Vision
system

Object Arm Gripper

identification controller controller
system

Packaging
selection
system

Packing Conveyor
system controller
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
Architectural design process

 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
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
System organisation

 Reflects the basic strategy that is used to structure a system.

 Three organisational styles are widely used:
 A shared data repository style;
 A shared services and servers style;
 An abstract machine or layered style.
Modular decomposition styles

 Styles of decomposing sub-systems into modules.

 No rigid distinction between system organisation and modular
decomposition.
 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.
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 object;
 A pipeline or data-flow model where the system is decomposed
into functional modules which transform inputs to outputs.
 If possible, decisions about concurrency should be
delayed until modules are implemented.
Control styles

 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.
 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.
Call-return model
Real-time system control