Software Architecture and
Patterns
1
Outline Introduction
Software Architecture and Architectural Design Architectural Styles
System StructuringModular DecompositionControl Styles
PatternsPattern Categories
Architectural Patterns Design Patterns Idioms
Summary
2
What do we think an architecture is?
The term architecture has been used for centuries to denote the physical structure of an artifact.
3
Introduction
Architecture in Software Engineering
The software engineering community has adopted the term to denote the gross-level structure of software systems.
Due to the increasing complexity and the increasing size of the applications, the global structure of the software system became an important issue.
4
Introduction
Definition of Software Architecture
"The structure of the components of a program/system, their interrelationships, and principles and guidelines governing their design and evolution over time." [D.Garlan et al., 1995]
"The software architecture of a program or computing system is the structure or structures of the system, which comprise software components, the externally visible properties of those components, and the relationships among them."L. Bass, P. Clements & R. Kazman, Software Architecture in Practice, Addison Wesley 1998.
5
Introduction
Architectural design
The design process for identifying the sub-systems making up a system and the framework for sub-system control and communication is architectural design.
Represents the link between specification and design processes.
6
Introduction
Advantages of explicit architecture
Support stakeholder communication.Enable parallel development.Facilitate large-scale reuse.Support several quality factors.
7
Introduction
Packing robot control system
8
Visionsystem
Objectidentification
system
Armcontroller
Grippercontroller
Packagingselectionsystem
Packingsystem
Conveyorcontroller
Introduction
What is an architectural style?
An architectural style is a pattern of system organisation such as client-server architecture or a layered architecture.
Styles constraints the component types and their patterns of interaction.
9
Architectural Styles
Knowledge about architectural styles can simplify the problem of defining system architectures.
For ex., Client/Server is a common architectural style.
Different architectural models such as a structural model, a control model and a decomposition model may be developed.
10
Role of Architectural styles in Design
Architectural Styles
System structuring
Basic strategy that is used to structure a system.Three styles are widely used:
A shared data repository style;A shared services and servers style;An abstract machine or layered style.
11
Architectural Styles
The repository model
Suitable for sharing large amounts of data.Shared data is held in a central database or
repository and may be accessed by all sub-systems.
12
System Structuring
CASE toolset architecture
13
Projectrepository
Designtranslator
Programeditor
Designeditor
Codegenerator
Designanalyser
Reportgenerator
System Structuring
Repository model characteristics
AdvantagesEfficient way to share large amounts of data;Facilities for centralised management e.g.
backup, security, etc.Disadvantages
Sub-systems must agree on a repository data model.
Data evolution is difficult and expensive.
14
System Structuring
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.
15
System Structuring
Film and picture library
16
Catalogueserver
Librarycatalogue
Videoserver
Film clipfiles
Pictureserver
Digitisedphotographs
Web server
Film andphoto info.
Client 1 Client 2 Client 3 Client 4
Internet
System Structuring
Client-server characteristics
AdvantagesDistribution of data is straightforward.Makes effective use of networked systems.Easy to add new servers.
DisadvantagesNo shared data model so data interchange among
subsytems may be difficult.Separate management in each server.No central register of names and services.
17
System Structuring
Layered model
Organises the system into a set of layers each of which provide a set of services.
When a layer interface changes, only the adjacent layer is affected.
For ex: Layered communication protocols.Structuring systems in a layered fashion is a
difficult task.
18
System Structuring
Version management system
19
Configuration management system layer
Database system layer
Operating system layer
Object management system layer
System Structuring
Modular decomposition
Another structural level where sub-systems are decomposed into modules.
Two modular decomposition models coveredAn 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.
20
Modular Decomposition
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.
21
Object
Object
Modular Decomposition
Invoice processing system
22
issue ()sendReminder ()acceptPayment ()sendReceipt ()
invoice#dateamountcustomer
invoice#dateamountcustomer#
invoice#dateamountcustomer#
customer#nameaddresscredit period
Customer
Payment
Invoice
Receipt
Modular Decomposition
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.
23
Modular Decomposition
Function-oriented pipelining -1
Functional transformations process their inputs to produce outputs.
Characterized as a series of transformations of input data.
24
Input data Output
Transformation 1
Transformation 2
Transformation 3
Modular Decomposition
Function-oriented pipelining -2
Relatively simple to implement.Requires a common format for data transfer
along the pipeline.Not suitable for interactive systems.
25
Modular Decomposition
Invoice processing system
26
Read issuedinvoices
Identifypayments
Issuereceipts
Findpayments
due
Receipts
Issuepaymentreminder
Reminders
Invoices Payments
Modular Decomposition
Control styles
Are concerned with the control flow between sub-systems.
Centralised controlOne sub-system has overall responsibility for control and
starts and stops other sub-systems.
Event-based controlEach sub-system can respond to externally generated
events from other sub-systems or the system’s environment.
27
Control Styles
Centralised control – Call&Return model
Top-down subroutine model where control starts at the top of a subroutine hierarchy and moves downwards.
28
Routine 1.2Routine 1.1 Routine 3.2Routine 3.1
Routine 2 Routine 3Routine 1
Mainprogram
Control Styles
Centralised control - Manager Model
One system component controls the stopping, starting and coordination of other system processes.
29
Systemcontroller
Userinterface
Faulthandler
Computationprocesses
Actuatorprocesses
Sensorprocesses
Control Styles
Event-based control
Driven by externally generated events where the timing of the event is not controlled by the sub-systems that process the event.
Two principal event-driven modelsBroadcast models. An event is broadcast to all sub-
systems. Interrupt-driven models. Used in real-time systems
where interrupts are detected by an interrupt handler and passed to some other component for processing.
30
Control Styles
Broadcast model
Sub-systems register an interest in specific events.
Control is transferred to the sub-system which can handle the event.
Sub-systems decide on events of interest to them.
31
Control Styles
Selective broadcasting
32
Sub-system1
Event and message handler
Sub-system2
Sub-system3
Sub-system4
Control Styles
Interrupt-driven model
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 interrupt type is associated with a memory location.
Allows fast response but complex to program and difficult to validate.
33
Control Styles
Interrupt-driven control
34
Handler1
Handler2
Handler3
Handler4
Process1
Process2
Process3
Process4
Interrupts
Interruptvector
Control Styles
PatternsThe concept of patterns in software
development has been derived from the writings of an architect Christopher Alexander.
A pattern is the abstraction of a problem in a specific domain and the representation of a generic solution to be used in different contexts.
Software patterns became popular with the book titled “Design Patterns: Elements of Reusable Object-Oriented Software” by Erich Gamma et al.
35
Patterns
General Characteristics of Patterns -1 [Buschmann et al,1996]Patterns are heavily used in software
architecture and design in the software community.
A pattern describes a solution to a recurring problem that arises in specific design situations.
Patterns are derived from well-proven design expertise.
Patterns describe a group of components (e.g., classes or objects) and the interaction between the components.
36
Patterns
General Characteristics of Patterns -2 [Buschmann et al,1996]Patterns are a means of documenting software
architectures.Patterns provide a conceptual skeleton for a
solution to a design problem.Patterns help designers manage the complexity
of the software. Patterns provide a vocabulary for communication
among designers.
37
Patterns
Pattern Categories Patterns can be grouped according to their
level of abstraction: 1. Architectural patterns 2. Design patterns 3. Idioms
Each category includes patterns that have a similar range of scale and abstraction.
38
Patterns
Architectural patterns An architectural pattern expresses a fundamental
structural organization schema for software systems. It provides a set of predefined subsystems, specifies their responsibilities, and includes rules and guidelines for organizing the relationships between them.[Buschmann et al,1996]
Examples of architectural patterns include;1. Pipes and Filters pattern. 2. Layered systems.3. Model-View-Controller(MVC).
39
Patterns
Model-view controller -1An architectural pattern for GUI design.MVC applications are splitted into three parts
which comprises a relationship between a Model object, a View object and a Controller.
40
Patterns
Model-view controller -2MVC pattern decouples changes to how data
are manipulated from how they are displayed or stored.
Allows for multiple presentations of an object and separate interactions with these presentations.
41
Patterns
Model-view-controller -3
42
Model methods
Controller methods View methods
Userinputs
view modificationmessages
Model edits
Model queriesand updates
Controller state View state
Model state
Patterns
Design patterns -1A design pattern provides a scheme for refining
the subsystems of a software system, or the relationships between them.
A design pattern describes a commonly recurring structure of communicating components that solves a general design problem within a particular context.[Gamma et al. 1994]
43
Patterns
Design patterns -2Medium-scale patterns.The choice of a design pattern does not affect the
fundamental structure of a software system but affects the structure of a subsystem.
Independent of the implementation language to be used.
They often rely on object characteristics such as inheritance and polymorphism.
44
Patterns
Design patterns -3
Gamma et al., presents a catalog of design patterns organized according to their purpose:Creational
Are related to the process of object orientation.Structural
Deal with the composition of classes or objects.Behavioral
Are related to the interaction between classes or objects.
45
Patterns
Multiple displays
46
A: 40B: 25C: 15D: 20
Observer 1
A
B
C
D
Observer 2
Subject
0
50
25
A B C D
Patterns
The Observer pattern Name
Observer. Description
Separates the display of object state from the object itself.
Problem description Used when multiple displays of state are needed.
Solution description Define a one-to-many dependency between objects so that
when one object changes state, all its dependents are notified and updated automatically.
47
Patterns
The Observer pattern
48
Subject Observer
Attach (Observer)Detach (Observer)Notify ()
Update ()
ConcreteSubject
GetState ()
subjectState
ConcreteObserver
Update ()
observerState
observerState = subject -> GetState ()return subjectState
for all o in observers o -> Update ()
Patterns
IdiomsAn idiom is a low-level pattern specific to a
programming language. An idiom describes how to implement particular aspects of components or the relationships between them using the features of the given language. [Buschmann et al., 1996]
49
Patterns
Counted Body (Coplien,1992)An idiom for storage management of shared
objects in C++.The interface of a class is separated from its
implementation.Access to a shared object is controlled
through two classes a Body (representation) class and a Handle (access) class.
50
Patterns
Software Architectures - summaryThe software architecture is the fundamental framework
for structuring the system.Different architectural models such as a structural model, a
control model and a decomposition model may be developed.
System structuring models include repository, client-server and abstract machine models.
Control models include centralised control and event-driven models.
Modular decomposition models include object models and pipelining models.
51
Summary
Patterns A pattern is the abstraction of a problem in a specific
domain and the representation of a generic solution to be used in different contexts.
An architectural pattern expresses a fundamental structural organization schema for software systems.
Design patterns are high-level abstractions that document successful design solutions.
An idiom is a low-level pattern specific to a programming language.
52
Summary