Sa 008 patterns

Vakgroep Informatietechnologie – IBCN

Software Architecture

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 in a design context.

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, Broker, Microkernel, Reflection…


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)


What Makes a Architectural Pattern?

ContextA situation giving rise to a problem

Developing software systems with a flexible user interface Transforming data flows in real time Processing events in sensornetworks

Specifying the correct context for a pattern is difficult :

• Impossible to determine all situations

• Known context situations for a pattern give valuable guidance

Context Problems Solution



ProblemThe recurring problem arising in that context

Requirements the solution must fulfill Constraints you must consider : e.g.

Use a particular communication middleware: Corba Need to run on specific OS: Linux.

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

In the context of ADD these are

-Functional requirements

-Quality Requirements.

-Design Constraints




Solution Structure with components and relationships Run-time behavior Tactics

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.



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

Data streams Processing & transformations on the streams


Architectural Pattern: Pipes and Filters (Data Flow)

Context Problems Solution• Processing

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

1. Divide the system’s task into a sequence of processing stages

2. Define the data format to be passed along each pipe

3. Decide how to implement each pipe connection

4. Design and implement the filters

5. Design the error handling

6. Set up the processing pipeline

Example: Compilers




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

Passive data store: file, database– Data mining, Recommendation Engines,– Route planner

Blackboard Active data store: sends events to the

subscribers– Artificial Intelligence

– Speech and Pattern recognition

p. 14

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 : Instantiation

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 sourcesHEARSAY 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

- 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 2-Layered or Call based Client/Server N-Layered

Architectural Pattern: Layers

Context 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


p. 20


Structure Dynamics



Layers : Instantiation

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

N-layered architecture




+Modifiability

• Localize changes• Prevention of ripple effect• Defer binding time

Testability• Manage input/output

Usability• Separate user interface

•Reuse of layers•Support for standardization•Dependencies are kept local•Exchangeability

-Performance• Unnecessary work• Lower efficiency

Modifiability • Cascades of changing behavior•Difficulty of establishing the correct granularity of layers


Model-View-Controller


• Interactive application 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 and control the flow. Views and controllers together comprise the user interface.


Design Pattern: Model-View-Controller

MVC for web applications



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•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

p. 31

Broker Components: CRC


Broker : Instantiation

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…


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

Direct communication: same

protocol or proxy

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

p. 35

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 pattern: provide a surrogate through which clients can access remote objects

Structure Dynamics


Design Pattern: Proxy

+ Modifiability•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


Broker Proxies


Broker Pattern Revisited: Proxy


Broker Pattern Revisited: Proxy


Event Based Systems

Individual components announce data that they wish to share with other components: Publishers

Other components can register an interest in a class of data: Subscribers

Typically involves a message manager that controls communication between components

Example: debuggers, databases, brokers

MessageMessage

ManagerManager

Publish

Subscribe

p. 41


• 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

Dynamics 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

p. 43

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


Pattern: Inter-relationships

• 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

• Patterns need to collaborate 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 …

Technology

Sa 008 patterns