SS ZG653Second Semester 2012-13 1 Topic Architectural Patterns – Review of Patterns.

SS ZG653Second Semester 2012-13 1

Topic

Architectural Patterns – Review of Patterns


What is a Pattern

• A pattern for software architecture describes a particular recurring design problem that arises in specific design contexts, and represents a well-proven generic scheme for its solution. The solution scheme is specified by describing its constituent components, their responsibilities and relationships, and the ways in which they collaborate

– Buschmann, F. et al, Pattern Oriented Software Architecture – Volume1, Wiley, 1996


Pattern – Three-part Schema

Pattern

Context

Problem

Solution

A situation giving rise to a problem

The recurring problem arising in that context

A proven solution of the problem


Patterns – Three Categories

ArchitectureDesignIdiomR

efined

Implementation


Architectural Patterns

Mud to Structure

Distributed Systems

Interactive Systems

Adaptive Systems

LayersPipes and Filters

Blackboard

Model-View-ControllerPresentation-Abstraction-

Control

Broker

MicrokernelReflection


Mud to Structure


LAYERED ARCHITECTURAL STYLEMud to Structure


LayersThe layers architectural pattern helps to structure application that can be decomposed into groups of subtasks in which each group of subtasks is at a particular level of abstraction


Layers• Implementing protocols• Conceptually different issues split into

separate, interacting layers• Functionality decomposed into layers; helps

replace layer(s) with better or different implementation


Layers – 3 part schemaPattern

Context A large system that requires decomposition

Problem Mix of low- and high-level issues, where high-level operations rely on low-level onesA typical pattern of communication flow consists of requests moving from high level to low level, and answers to requests, incoming data and notification about events traveling in the opposite directionForces•Code changes should not ripple through the system•Stable interfaces; standardisation•Exchangeable parts•Grouping of responsibilities for better understandability and maintainability

Solution Structure the system into appropriate number of layers


OSI 7-Layer Model

Physical

Data Link

Network

Transport

Session

Presentation

Application

Layer 1

Layer 2

Layer 3

Layer 4

Layer 5

Layer 6

Layer 7

Transmits bits: velocity, bit-code, connection etc.

Detects and corrects errors in bit sequences

Selects route from sender to receiver

Breaks messages into packets and guarantees delivery

Provides dialog control and synchronization facilities

Structures information and attaches semantics

Provides miscellaneous protocols for common activities


Layers• Main characteristic is

services of Layer J are only used by Layer J+1

• No further direct dependencies between layers

• Each layer may be further composed of many components

ClassLayer J

Responsibility• Provides services

user by Layer J+1• Delegates

subtasks to Layer J-1

Collaborators• Layer J-1


Layers

Layer 1

Layer N-1

Layer NClient


Layers - Detailed


Dynamics• Scenario I

– Top Down communication– Client issues a request to Layer N– Layer N, cannot carry out the request on its own,

it calls Layer N-1– N-1 to N-2 till Layer 1 is reached


Dynamics• Scenario II

– Bottom Up communication– Chain of actions starts from Layer 1– Translates events to internal format and reports to

Layer 2– Notifications flow till the topmost layer and then

processed


Dynamics• Scenario III

– Top Down Communication– Request may not reach the bottom most layer


Dynamics• Scenario IV

– Bottom Up Communication– Request may not reach the top most layer


Dynamics• Scenario V

– Involves two stacks communication with each other

Layer 1

Layer N-1

Layer N

Layer 1

Layer N-1

Layer N


Implementation Steps# Steps1 Define the abstraction criteria

2 Determine the numbers of abstraction levels

3 Name the layers and assign tasks to each of them

4 Specify the services

5 Refine the layering

6 Specify an interface for each layer

7 Structure individual layers

8 Specify the communication between adjacent layers

9 Decouple adjacent layers

10 Design error handling strategy


1: Define abstraction criteria• Use various paradigms to arrive at an

abstraction criteria• Degree of customization for specific domains• Degree of conceptual complexity• An Example [Ordered from Top to Bottom]–- User-visible elements - Specific Application Modules- Common Service Levels- OS Interface Level- Hardware


2: Determine the no. of abstraction levels• Typically each abstraction level is one layer• Map the abstraction levels to layers; one-one

may not be as obvious• Use mechanisms to keep number of layers to

optimum number• Too Few Layers Can Result in Poor Structure• Too Many Layers Impose Unnecessary

Overhead


3: Name the layers and assign tasks• Use a top down or bottom up approach to

assign tasks• Requires experience to achieve this


4: Specify the services• Strict separation of layers• No component should spread over two layers• Inverted pyramid of use


5: Refine the layering• Iterate to arrive at the best possible number

and functionality of layers• Define components and services and impose

structure of layers should be avoided


6: Specify an interface for each layer• Use a black box approach• Layer N does treats Layer N-1 as a black box


7: Structure individual layers• Focus should be on proper relationships between

layers• Individual layers should not be a chaos• Structure the individual layers thru decomposition• Make use of other patterns (bridge, strategy)• Bridge Pattern Supports multiple implementations

of services provided by a layer• Strategy Pattern Supports Dynamic exchange of

algorithms used by a user


8:Specify communication bet. Adja. layers• Use of push pull mechanism• Use of call backs


9: Decouple adjacent layers• Lower layer is not aware of higher layer • Higher layer is aware of lower layer• Changes in Layer J can ignore the presence

and identity of Layer J+1 [ Suitable for Top-up communication]

• Use of call backs


10: Design an error handling strategy• Define an efficient strategy• Handling may be expensive – errors need to

propogate


Variants

• Relaxed Layered System• Layering Through Inheritance


Benefits

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


Liabilities• Cascades of changing behaviour• Lower efficiency• Unnecessary work• Difficulty in establishing the correct granularity


Known Uses• Virtual Machines• APIs• Information Systems• Windows NT

• Find (at least 2) more popular uses and document them


LayersPattern Description




Variants Relaxed Layered SystemLayering Through Inheritance

Benefits Reuse of layersSupport for standardisationDependencies are kept localExchangeability

Liabilities Cascades of changing behaviourLower efficiencyUnnecessary workDifficulty in establishing the correct granularity


Layers Quick ReferencePattern Description




Variants Relaxed Layered SystemLayering Through Inheritance

Benefits Reuse of layersSupport for standardisationDependencies are kept localExchangeability

Liabilities Cascades of changing behaviourLower efficiencyUnnecessary workDifficulty in establishing the correct granularity

# Steps

1 Define the abstraction criteria

2 Determine the numbers of abstraction levels

3 Name the layers and assign tasks to each of them

4 Specify the services

5 Refine the layering

6 Specify an interface for each layer

7 Structure individual layers

8 Specify the communication between adjacent layers

9 Decouple adjacent layers

10

Design error handling strategy

ClassLayer JResponsibility• Provides

services user by Layer J+1

• Delegates subtasks to Layer J-1

Collaborators• Layer J-1

Layer 1

Layer N-1

Layer N

Layer 1

Layer N-1

Layer N

SS ZG653Second Semester 2012-13 1 Topic Architectural Patterns – Review of Patterns.

Documents

Transcript of SS ZG653Second Semester 2012-13 1 Topic Architectural Patterns – Review of Patterns.