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