Software Architecture Prof.Dr.ir. F. Gielen

Vakgroep Informatietechnologie – IBCN

Software ArchitectureProf.Dr.ir. F. Gielen

Architectural Patterns

Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 2

What is a Pattern?

“ Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice …”

Christopher Alexander


Taxonomy of Patterns & Idioms

Type Description Examples

Idioms Restricted to a particular language, system, or tool

C++ list and array processing.

Design patterns

Capture the static & dynamic roles & relationships in solutions that occur repeatedly

Active Object, Bridge, Proxy, Façade, Visitor, Factory,…

Architectural patterns

Express a fundamental structural organization for software systems that provide a set of predefined subsystems, specify their relationships, & include the rules & guidelines for organizing the relationships between them

Layers, Pipe-Filter, Blackboard, MVC, Client Server, Broker, Dataflow, Rule Based system,…

Optimization principle patterns

Document rules for avoiding common design & implementation mistakes that degrade performance

Avoid memory leaks with counting pointers


C++ idioms:

Array - Tabel Find an element in a list C++ idiom: for(int i = 0; i < N; i++) Typical mistake: array index overrun

Linked List Add or delete an element to a list. C++ idiom: for(link t=x; t !=0; t=t->next) Typical mistake : null pointers, memory leaks.


Design Patterns

Design Patterns Elements of Reusable Object-Oriented Software

E. Gamma, R. Helm,R. Johnson, J. Vlissides(the “Gang of Four”)

Addison-Wesley, 1995 ISBN: 0-201-63361-2


Design Patterns …

“Design patterns are descriptions of communicating objects and classes that are customized to solve a general design problem in a particular context”

Gang of Four


Design Pattern example : Strategy

searcherSearchAlgorithm

searchFor(String, Text)

SearchAlgorithm2


SearchAlgorithm1


TextProcessor

text

search(String)1

Use the Strategy pattern when Many related classes that differ only in their behaviour You need different variants of an algorithm An algorithm uses data that clients should not know about A class defines many behaviours


Architectural Design

From Mud to Structure Layers

Pipes and filters

Blackboard

Broker

Distributed systems Pipes and filters

Microkernel

Interactive systems MVC

PAC

Adaptable systems Microkernel

Reflection

Structural decomposition whole-part

Organization of work master-slave

Access control proxy

Management command processor

view handler

Communication Publisher-subscriber

Forwarder-Receiver

Architectural patterns can be used at the beginning of coarse grained design, when specifying the fundamental structure of an application (cf. first iteration(s) of the ADD method)

Design patterns are applicable towards the end of coarse-grained design when refining and extending the fundamental architecture of a software system. Design patterns are also applicable in the detailed design stage for specifying local design aspects (e.g. multiple implementations of a component)


Architectural patterns & ADD

1. Choose the module to decompose Start with entire system Inputs for this module need to be available

Constraints, functional and quality requirements

2. Refine the module Choose architectural drivers relevant to this decomposition Choose the architectural patterns that satisfies these drivers Instantiate modules and allocate functionality from use cases

representing using multiple views. Define interfaces of child modules. Verify and refine use cases and quality scenarios.

3. Repeat for every module that needs further decomposition


Architectural Style and Patterns

Architectural Styles are recurring organisational patterns and idioms. A style consists of key features and rules for combining those features so that the architectural integrity is maintained.

Benefits of Style: Reuse: well understood solutions applied to new

problems Common vocabulary leads to understandability

of organisation. (e.g. Client Server,broker,…) Style specific analysis.


Architectural Integrity


What Makes a Architectural Pattern?

ContextA situation giving rise to a problem

General context : developing software with a flexible human-computer interface

Specific context : managing the change-propagation in a flight simulator or avionics system

Specifying the correct context for a pattern is difficult :

• Impossible to determine all situations

• List known context situations for a pattern can give valuable guidance

Context Problems Solution



ProblemThe recurring problem arising in that context

Requirements the solution must fulfill : e.g. Peer-to-peer inter-process communication must be efficient

Constraints you must consider : e.g. That inter-process communication must follow a particular protocol, client has to run on smart phones

Desirable properties the solution should have : e.g. changing software should be easy

In the context of ADD these are quality requirements.

Constraints can be found in the feature description

Desirable properties are almost always related to modifiability and reuse




SolutionStructure with components and relationships

Run-time behavior

A pattern is a mental building block.

After applying a pattern architectures should include a particular structure that provides for the roles specified by the pattern,

but adjusted and tailored to the specific needs of the problem at hand.


Software Architecture Pattern is:

A set of componentcomponent types process, data repository, procedure

TopologicalTopological layout of the components configuration rules, relations

A set of semanticsemantic rules and constraints: compositions have well defined meanings

A set of connectorsconnectors for communication , co-ordination and co-operation between components

subroutine call, sockets, message queues


Architectural Style Catalogue

Data Centered

Blackboard Repository

Independent

Components

Communicating

Processes

Event Based

Systems

Call & Return

Layered Object Oriented

Virtual Machines

Interpreter Rule based

Data Flow

Pipes &

Filters

Batch

Sequential


Data Flow Architectures

Key feature: Dominated by motion of data through the system

datastreams

Pipes and Filters Filters are independent entities (components) incremental: output begins before input is consumed example : Unix shell programs, compiler


Architectural Pattern: Pipes and Filters (Data Flow)

Context Problems Solution• Processin

g data streams

• Motion of data through the system

• Future system enhancements should be possible

• Small processing steps

• Non-adjacent processing steps do not share information

• Different sources of input data exist

• Present or store final results in various ways

• Explicit storage of intermediate results for further processing

• You may not want to rule out multi-processing the steps

• Apply the Pipes and Filters architectural pattern: the tasks of a system are divided into several sequential processing steps, connected by the data flow through the system


Example : Multimedia



Data Centered


Independent

Components

Communicating

Processes

Event Based

Systems

Call & Return


Virtual Machines


Data Flow

Pipes &

Filters

Batch

Sequential


Data-Centered Architectures

Key Feature: Dominated by a complex central data store,

manipulated by independent components. RepositoryRepository

Passive data store: file, database

BlackboardBlackboard Active data store: sends events to the

subscribers– Artificial Intelligence

– Speech and Pattern recognition


Architectural Pattern: Blackboard (Data Centered)

Context Problems Solution• Experimental domain in

which no closed approach to a solution is known or feasible, different approaches for the problem are opportune

• There are different algorithms that solve partial problems

• Employing disjoint algorithms induces potential parallelism. If possible you should avoid a strictly sequential solution

• Apply the Blackboard architectural pattern: a collection of independent programs that work cooperatively on a common data structure

Blackboard

(shared data)•Vocabulary

•Hypothesis

•Abstraction level

Control

Knowledge

Source

Knowledge

SourceKnowledge

Source


Architectural Pattern: Blackboard

1. Define the problem

2. Define the solution space for the problem

3. Divide the solution process into steps

4. Divide the knowledge into specialized knowledge sources with certain subtasks

5. Define the vocabulary of the blackboard

6. Specify the control of the system

7. Implement the knowledge sourcesExample

HEARSAY II used a blackboard architecture to recognize human speech. In this case the raw data was acoustical data which was to be transformed into a database query. Contributors/knowledge sources existed for transforming acoustical data (level 0, wave forms) into phonetic data (level 1, phonemes), phonetic data into lexical data (level 2, words), lexical data into syntactical data (level 3, phrases), and syntactical data into queries (level 4).


Architectural Pattern: Blackboard

+ Modifiability•Individual knowledge sources, the control algorithm and the central data structure are strictly separated•Reusable knowledge sources

•The blackboard provides tolerance of noisy and uncertain conclusions as all results are just hypotheses

Experimentation

- Testability•Hypotheses are part of the solution process

Performance•Computational overhead•No support for parallelism•Difficult to establish a good control strategy



Data Centered


Independent

Components

Communicating

Processes

Event Based

Systems

Call & Return


Virtual Machines


Data Flow

Pipes &

Filters

Batch

Sequential


Call and Return Architectures

Key Feature Dominated by order of computation

Examples Abstract data types Object Oriented Layered Call based Client/Server


The Evolution of Middleware

There are multiple COTS middleware layers & research/business

opportunities

Historically, mission-critical apps were built directly atop hardware• Tedious, error-prone, & costly over lifecycles

Standards-based COTS middleware helps:

• Control end-to-end resources & QoS• Leverage hardware & software technology advances

• Evolve to new environments & requirements• Provide a wide array of reusable, off-the-shelf developer-oriented services

There are layers of middleware, just like there are layers of networking protocols

Hardware

Domain-SpecificServices

CommonMiddleware Services

DistributionMiddleware

Host InfrastructureMiddleware

& OS

Operating Systems & Protocols

Applications


Architectural Pattern: LayersContext Problems Solution• Large system

that requires decomposition

• Parts of the system should be exchangeable

• Reuse low-level issues

• No standard component granularity

• Group similar responsibilities

• System will be build by separated teams of programmers

• Layered architectural pattern: structure your system into an appropriate number of layers and place them on top of each other

Structure Dynamics


Architectural Pattern: Layers

Communication protocols

Ethernet

IP

TCP

FTP

Class Collaborator

Layer J Layer J-1

Responsibility

Provides services used by Layer J+1

Delegates subtasks to Layer J-1

1. Define the abstraction criterion

2. Determine the number of abstraction levels

3. Name the layers and assign tasks to each of them

4. Specify the services

5. Refine the layering

6. Specify the interfaces for each layer

7. Structure individual layers

8. Specify the communication between adjacent layers

9. Decouple adjacent layers


Architectural Pattern: Layers

+Modifiability Localize changes Prevention of ripple effect Defer binding time

Testability Manage input/output

Usability Separate user interface

Reuse of layersSupport for standardizationDependencies are kept localExchangeability

-

Performance•Unnecessary work•Lower efficiency

Modifiability •Cascades of changing behaviorDifficulty of establishing the correct granularity of layers


Model-View-Controller


• Interactive applications with flexible human-computer interface

• The same information is presented differently

• Display and behavior of the application must reflect data manipulations immediately

• Changes to the user interface should be easy, and even possible at run-time

• Supporting different ‘look and feel’ standards or porting the user interface should not affect code in the core application

• Apply the Model-View-Controller architectural pattern:

• The Model contains the core functionality and data.

• Views display information to the user,

• Controllers handle user input. Views and controllers together comprise the user interface.


MVC structure


Architectural Pattern: Model-View-Controller


MVC analysis

+ Modifiability•‘Pluggable’ views and controllers•Exchangeability of ‘look and feel’

Usability•Separate user interface•‘Pluggable’ views

•Multiple synchronized views of the same model

•Framework potential

- Performance•Inefficiency of data access in view•Potential excessive number of updates•Increased complexity, sometimes without gaining much flexibility: Modifiability•An additional encapsulation of platform dependencies may be required•Close coupling of views and controllers to a model•Difficulty of using MVC with modern user-interface tools



Data Centered


Independent

Components

Communicating

Processes

Event Based

Systems

Call & Return


Virtual Machines


Data Flow

Pipes &

Filters

Batch

Sequential


Independent Components

Key Features Dominated by communication patterns. Components communicate through messages.

They send data; notnot control.

Examples Event systems

Implicit invocation Announcers of events do not know which

components will be affected by the event

Communicating processes

Shaw and GarlanSoftware Architecture in Practice


Broker: Broker Forwarding PatternContext Problems Solution

• Distributed and possible heterogeneous system with independent cooperating components

• Components should be able to access services provided by others through remote, location-transparent service invocations

• Need to exchange, add, or remove components at run-time

• The architecture should hide system- and implementation-specific details from the user of components and services

• Apply the Broker architectural pattern: an intermediate component that is responsible for coordination communication, such as forwarding requests, as well as for transmitting results and exceptions

Client Server

1: clientRequest

4: forw

ardedReply

2: forwardedRequest3: serverReply

BrokerBroker


Broker Components: CRC

Client Server

BrokerBroker


Architectural Pattern: Broker

1. Define an object model

2. Decide which kind of component-interoperability the system should offer

3. Specify the API’s the broker component provides for collaborating with client and server

4. Use proxy objects to hide implementation details from clients and servers

5. Design the broker component in parallel with steps 3 and 4

• Specify protocol, message buffers, directory service, dynamic method invocation, IDL compiler…

CORBA

IBM SOM/DSOM

Microsoft’s OLE 2.x

World Wide Web: hypertext browers such as Netscape act as brokers and WWW servers play the role of service providers


Architectural Pattern: Broker

+ Modifiability•Location transparency•Changeability and extensibility of components•Portability of a broker system (in combination with proxy/bridge)•Interoperability between different broker systems•Reusability

Testability•An application developed from tested services is more robust and

easier to test

-Performance•Restricted efficiency

Availability•Lower fault tolerance

Testability•Many components involved


Broker Handle Pattern

B2: serviceH

andle

Client Server

B1: clientBrokerRequest

R2: registrationAckR1: registerService

B3: clientServiceRequest

B4: serverReply

Direct communication: same

protocol or proxy

Here the proxy takes some of the broker’s responsibilities for handling most of the communication activities

BrokerBroker


Design Pattern: Proxy


• The configuration of components in distributed systems is often subject to change as requirements evolve

• Low-level message passing (e.g., using sockets) is error-prone & fraught with accidental complexity

• Remote components should look like local components from an application perspective

• i.e., ideally clients & servers should be oblivious to communication mechanisms & locations

• Apply the Proxy design pattern: provide an OO surrogate through which clients can access remote objects

Proxy

service

Client

Service

service1 1

AbstractService

service: Service: Proxy: Client

service

service

pre-processing: e.g.,marshaling

post-processing: e.g., unmarshaling

Structure Dynamics


Design Pattern: Proxy

+ Performance•Enhanced efficiency and lower costModifiability•Decoupling clients from the location of server components•Separation of housekeeping code from functionality

- Performance •Less efficiency due to indirection (additional layer of indirection, usually negligible compared with the cleaner structure of clients and the gain of efficiency through caching or lazy construction…)•Overkill via sophisticated strategies, they do not always pay

Examples:

Firewall proxy, cache proxy, …

World Wide Web proxy describes aspects of the CERN HTTP server that typically runs on a firewall machine. It gives people inside the firewall concurrent access to the outside world. Efficiency is increased by caching recently transferred files (combination of different proxy types!!!)


Example: Java RMI

Remote Method Invocation (RMI) is a Java mechanism similar to RPCs.

RMI allows a Java program on one machine to invoke a method on a remote object.


Stub &skeleton implementation.


Broker Proxies


Broker Pattern Revisited: Proxy

message exchange

message exchange

*

marshalunmarhalreceive_resultservice_p

Client Proxy

calls*

*

call_service_pstart_task

Client

1

marshalunmarshaldispatchreceive_request

Server Proxy

calls*

start_upmain_loopservice_i

Server

1

1

main_loopsrv_registrationsrv_lookupxmit_messagemanage_QoS

Broker1

Structure


Broker Pattern Revisited: Proxy

Dynamics

operation (params)connect

send_requestmarshal

unmarshal

dispatchoperation (params)

result

marshalreceive_reply

unmarshal

result

start_upregister_service

assigned port

: Broker: Client Proxy : Server Proxy: Client : Server


Event Based Systems

Individual components announce data that they wish to

share with other components: PublishPublish. Other components can register an interest in a class of

data: SubscribeSubscribe. Typically involves a message manager that controls

communication between components Example: debuggers, databases, brokers

MessageMessage

ManagerManager

Publish

Subscribe



• I/O driven message based application

• Complex dependencies

• Real-time constraints

• Hard to schedule

• Expensive to evolve

• Scalability

• Apply the Publisher-Subscriber pattern to distribute periodic, I/O-driven data from a single point of source to a collection of consumers

Publisher-Subscriber

attachSubscriber

produce

pushEventevent

eventpushEvent

consume

detachSubscriber

: Event

: Subscriber: Event Channel: Publisher

Dynamics

Event*

Subscriber

consume

creates receives

Event Channel

attachPublisher detachPublisherattachSubscriberdetachSubscriberpushEvent

Filter

filterEvent

Publisher

produce

Structure


Publisher-Subscriber: Avionics example

Considerations for implementing the Publisher-Subscriber pattern for mission computing applications include:

• Event notification model

• Push control vs. pull data interactions

• Scheduling & synchronization strategies

e.g., priority-based dispatching & preemption

• Event dependency management

e.g.,filtering & correlation mechanisms

Airforce fighter jet uses the Publisher-Subscriber pattern to decouple sensor processing from mission computing operations

• Anonymous publisher & subscriber relationships• Group communication• Asynchrony


Publisher-Subscriber: example

VME

1553

1: Sensors generate data

Board 2

2: I/O via interrupts

4: Event Channel pushes events to subscribers(s)

5: Subscribers perform avionics operations

GPS IFF FLIR

HUD

NAV

WTS

Air Frame

Publishers

Subscribers

push(event)

push(event)

Event Channel

3: Sensor publishers push events to event channel

Board 1



Data Centered


Independent

Components

Communicating

Processes

Event Based

Systems

Call & Return


Virtual Machines


Data Flow

Pipes &

Filters

Batch

Sequential


Virtual Machine

Key Features Characterized by translation of one instruction

set into another.

Examples Interpreters

Style that simulates functionality that is not native to the hardware.

Rule based systems A means of codifying problem solving know-how of

human experts.


Interpreter

Components are the interpretation engine, memory that contains the program, the control state of the engine and state of the program.

Example : Java Virtual Machine GOAL: achieve portabilityportability Performance cost due to additional computations

Interpretation

Engine

Data(program state)

Program(being interpreted)

Internal

State

Input

Output

Program Instruction

Selected Instruction

Selected Data

State Data

Data Updates


Rule Based Architecture

RuleRule

InterpreterInterpreter

Working

Memory

Rule

Base

Rule and Data

Selection

Inputs

Outputs

Knowledge BaseKnowledge Base

Selected Rule

Selected Data

State Data

Data Updates

Fact

Memory

Components are essential the same as in the interpreter style.

Execution and sequence of rules is not predetermined but condition driven -> interpreter.

Makes heavy use of pattern matching. Example: Flight simulator


Exercise: Medical ImagingProblem• Having each client call a specific server is inefficient & non-scalable

• A “polling” strategy leads to performance bottlenecks

• Work lists could be spread across different servers

• More than one client may be interested in work list content

ContextIn large-scale electronic medical imaging systems, radiologists may share “work lists” of patient images to balance workloads effectively

ImageDatabase

RadiologyClient

RadiologyClient

RadiologyClient

RadiologyClient

RadiologyClient

RadiologyClient

RadiologyClient

RadiologyClient Radiology

ClientRadiology

Client


Decoupling Suppliers & Consumers

Decouple suppliers (publishers) & consumers (subscribers) of events:

• An Event Channel stores/forwards events

• Publishers create events & store them in a queue maintained by the Event Channel

• Consumers register with event queues, from which they retrieve events

• Events are used to transmit state change info from publishers to consumers

• For event transmission push-models & pull-models are possible

• Filters can filter events for consumers

Event

*

Subscriber

consume

creates receives

Event Channel

attachPublisher detachPublisherattachSubscriberdetachSubscriberpushEvent

Filter

filter

Publisher

produce

Solution• Apply the Publisher-Subscriber architectural pattern (P1) to decouple image suppliers from consumers

Solution• Apply the Publisher-Subscriber architectural pattern (P1) to decouple image suppliers from consumers


Applying the Publisher-Subscriber Pattern

Event

*

Radiologist

consume

creates receives

Event ChannelattachPublisher detachPublisherattachSubscriberdetachSubscriberpushEvent

Filter

filter

Modality

produce

ImageDatabase

RadiologyClient

RadiologyClient

RadiologyClient

RadiologyClient

RadiologyClient

RadiologyClient

RadiologyClient

RadiologyClient

RadiologyClient

RadiologyClient

EventChannelEvent

Channel

• Radiologists can subscribe to an event channel to receive notifications produced when modalities publish events indicating the arrival of new images & studies

• This design enables a group of distributed radiologists to collaborate effectively in a networked environment


Pattern: Inter-relationships

In many cases patterns are NOT atomic Applying a pattern creates new contexts Applying a pattern creates new problems and trade-offs Applying a pattern creates new solutions

In many cases several patterns need to collaborate in order to solve a problem

E.g. the broker pattern (distributed system) typically leads to the introduction of the proxy pattern (access control) and bridge pattern (service variation)

If the ADD method is applied appropriately it should be clear which pattern to use when and where:

System subsystem module submodule

e.g. Broker proxy/bridge …


Pattern Systems – No Pattern is an Island

Patterns have to be organized in patterns systems Patterns exist in mane ranges of scales and abstraction Can be applied in different phases of software development Address a variety of different problems Exhibit different relationships with each other

A patterns system is an organized set of patterns Describes all patterns uniformly Supports a useful overview Supports selection by means of appropriate search strategy Provides a set of guidelines Supports its own evolution


Heterogeneous Architecture Style

Filter Filter FilterPipe Pipe

Subscribe

RDBMS

RPC

Objects

Method Call

Layered

Component


Architectural Design

From Mud to Structure Layers

Pipes and filters

Blackboard

Broker

Distributed systems Pipes and filters

Microkernel

Interactive systems MVC

PAC

Adaptable systems Microkernel

Reflection

Structural decomposition whole-part

Organization of work master-slave

Access control proxy

Management command processor

view handler

Communication Publisher-subscriber

Forwarder-Receiver

Architectural patterns can be used at the beginning of coarse grained design, when specifying the fundamental structure of an application (cf. first iteration(s) of the ADD method)

Design patterns are applicable towards the end of coarse-grained design when refining and extending the fundamental architecture of a software system. Design patterns are also applicable in the detailed design stage for specifying local design aspects (e.g. multiple implementations of a component)


Pattern Systems: The architect’s toolbox !

The architecture – design pattern system is useful in the context of ADD Even the most comprehensive pattern system will not

cover every problem area of a software architecture Pattern systems evolve constantly, based on the

experience of the architect The pattern system for a software architect, active in

concurrent and networked systems will be totally different (e.g. half-sync/half-async or leader/followers concurrency patterns aren’t mentioned here…)

The pattern system should be a toolbox in function of the application domain that the architect is working in

Documents

Software Architecture Prof.Dr.ir. F. Gielen