1 Architectural Patterns Yasser Ganji Saffar [email protected].

1

Architectural Patterns

Yasser Ganji [email protected]

2

What are patterns? A pattern addresses a recurring problem that

arises in specific design situations and presents a solution to it.

Patterns provide a common vocabulary and understandings for design principles

Patterns are a means of documenting software architecture

Patterns help you manage software complexity Patterns help you build on the collective

experience of skilled software engineers.

3

Patterns Categories Architectural Patterns Design Patterns Language Idioms

4

Architectural Patterns An architectural pattern expresses a

fundamental structural organization schema for software system.

It provides a set of predefined subsystems, specifies their responsibilities, and includes rules and guidelines for organizing the relationship between them.

5

Architectural Patterns Categories From mud to structure

Layers Pipes and Filters Blackboard

Interactive systems Model-View-Controller (MVC) Presentation-Abstraction-Controller (PAC)

Adaptable systems Microkernel Reflection

Distributed systems Broker

6

Pattern Specification Name Also Known As Example Context

A situation giving rise to a problem

Problem The recurring problem

arising in that context Solution

Structure Components Relationships

Dynamics Scenarios

Implementation Variants Known Uses Consequences

7

Layers Helps to structure applications that can be

decomposed into groups of subtasks in which each group of subtasks is at a particular level of abstraction

Core level

Useful System

Basic Utility

8

Layers Example:

OSI 7-Layer Model

Physical

Application

Data Link

Network

Transport

Session

Presentation

9

Layers Context:

A large system that requires decomposition Problem:

A system whose dominant characteristic is a mix of low and high level issues, where high level operations rely on lower-level ones.

10

Layers Solution

Structure your system into an appropriate number of layers and place them on top of each other

Start at the lowest level of abstraction and move up to the top level of functionality

11

Layers Structure

ClassLayer J

ResponsibilityProvides services used by Layer J+1

Delegates subtasks to Layer J-1

Collaborator

Layer J-1

12

Layers Variants

Relaxed layered system More Performance & Flexibility Less Maintainability Can be used in infrastructure systems such as X

Window System that are modified less than application systems and performance is more important than maintainability

Layering through inheritance A higher level inherits from a lower level

implementation Higher levels can modify lower layer services

13

Layers Known Uses

Information Systems 4 layer architecture:

Presentation, Application logic, Domain layer, Database

Virtual Machines e.g. JVM translates Java bytecodes to machine-

dependent codes APIs

An API is a layer that encapsulates lower layers of frequently-used functionality

e.g. C standard library on top of Unix Syscalls

14

Layers Advantages

Portability Modifiability

Late source code changes do not ripple through the system

Understandability & Maintainability Similar responsibilities are grouped

Reuse of layers Support for standardization

Clearly-defined and commonly-accepted levels of abstraction enable the development of standardized tasks and interfaces

15

Layers Disadvantages

Lower performance Difficulty of establishing the correct granularity

of layers Too few layers → Lower reusability, changeability and

portability Too many layers → Complexity and overhead in the

separation of layers

16

Pipes and Filters Provides a structure for systems that

process a stream of data Each processing step is encapsulated in a

filter component Data is passed through pipes between

adjacent filters

17

Pipes and Filters Example

CompilersScanner

Parser

Code Generator

Optimizer

Program text

Token stream

Abstract syntax tree

Assembly code

Optimized code

18

Pipes and Filters Context

Processing data streams Problem

You want to build a system that must process or transform a stream of input data

The system has to be built by several developers

The requirements are likely to change The global system task decomposes naturally

into several processing stages

19

Pipes and Filters Solution

Divides the task of a system into several sequential processing steps.

These steps are connected by the data flow through the system

Each processing step is implemented by a filter component

Data source, data sink and filters are connected by pipes

20

Pipes and Filters Structure

ClassFilter

Responsibility

• Gets input data

• Performs a function on its input data

•Supplies output data

Collaborator

Pipe

21


ClassPipe

Responsibility

• Transfers data

• Buffers data

• Synchronizes active neighbors (FIFO buffer)

Collaborators

Data Source

Data Sink

Filter

22


ClassData Source

Responsibility

• Delivers input to processing pipeline

Collaborator

Pipe

23


ClassData Sink

Responsibility

• Consumes output

Collaborator

Pipe

24

Pipes and Filters Variants

Tee and Join pipeline systems Filters with more that one input and/or more that one

output

25

Pipes and Filters Advantages

No intermediate files necessary Flexibility

By filter exchange By recombination

Reuse of filter components Rapid prototyping

Efficiency by parallel processing If each filter in a pipeline produces and consumes

data incrementally they can perform their functions in parallel

26

Pipes and Filters Disadvantages

Sharing state information is expensive or inflexible Efficiency gain by parallel processing is often an illusion

Some filters consume all their input before producing any output

Context-switching between threads or processes is generally an expensive operation on a single processor machine

Data transformation overhead For example if our pipes can only transform ASCII data

Error handling Because pipeline components do not share any global data

error handling is hard (stderr in Unix)

27

Model-View-Controller Divides an interactive application into three

components. Model contains core functionality. View displays information to the user. Controller handle user input. View and Controller together comprise the user

interface.

28

Model-View-Controller Context

Interactive applications with a flexible human-computer interface

Problem Changes to the UI must be easy Supporting different “look and feel” standards

or porting the UI should not affect code

29

Model-View-Controller Solution

Model encapsulates core data and functionality. It is independent of specific output representation or input behavior

View component obtains the data from the model and displays them to the user.

There can be multiple views of the model. Each view has an associated controller component. Controllers receive inputs (from mouse, keyboard,…)

and translates them to service requests for model or view

When a user changes the model state via the controller of one view, all other views should reflect the changes

30

Model-View-Controller Structure

ClassModel

Responsibility

• Provides functional core of the application

• Registers dependent views and controllers

• Notifies dependent components about data changes

Collaborators

View

Controller

31


ClassView

Responsibility

• Creates and initializes its associated controller

• Displays information to the user

• Implements the update procedure

• Retrieves data from the model

Collaborators

Controller

Model

32


ClassController

Responsibility

• Accepts user input as events

• Translates events to service requests for the model or display requests for the view

• Implements the update procedure if required

Collaborators

View

Model

33

Model-View-Controller

34

Model-View-Controller Variants

Document-View Relaxes the separation of view and controller Sacrifices exchangeability of controllers Document = Model in MVC

35

Model-View-Controller Known Uses

MFC in Visual C++ User interface framework in Smalltalk ET++

36

Model-View-Controller Advantages

Multiple views of the same model Synchronized views Pluggable views and controllers

UI objects can even be substituted at run-time Portability

Exchangeability of “look and feel”

37

Model-View-Controller Disadvantages

Increased complexity Not all views are interested in every change propagated

by the model Intimate connection between view and controller Close coupling of views and controllers to a model

Changes to model’s interface impact all views and controllers

Inefficiency of data access in view Difficulty of using MVC with modern UI tools

Many high level tools define their own flow of control and handle some events internally

38

Presentation-Abstraction-Control PAC defines a structure for interactive

software systems in the form of a hierarchy of cooperating agents.

Every agent is responsible for a specific aspect of the application’s functionality and consists of three components: presentation, abstraction and control.

39

Presentation-Abstraction-Control Context

Development of an interactive application with the help of agents

Problem Interactive systems can often be viewed as a

set of cooperating agents. Agents for human-computer interaction Agents that maintain the data model Agents for error handling Agents for communicating with other systems

40

Presentation-Abstraction-Control Solution

Structure the interactive application as a tree-like hierarchy of PAC agents.

Top-level PAC agent Intermediate-level PAC agents Bottom-level PAC agents

Presentation component of agents provides the visible behavior of them

Abstraction component maintains the data model Control component connects the Presentation and

Abstraction components and provides the functionality for the agent to communicate with other PAC agents

41

Presentation-Abstraction-Control

Data repository

Access to data

View coordinatorSpreadsheet

Pie chartBar chart

Intermediate-level PAC agent

Top-level PAC agent

Bottom-level PAC agent

Bottom-level PAC agent

42

Presentation-Abstraction-Control Structure

ClassTop-level Agent

Responsibility

• Provides the functional core of the system

• Controls the PAC hierarchy

Collaborators

Intermediate-level agent

Bottom-level agent

43


ClassIntermediate-level Agent

Responsibility

• Coordinates lower-level PAC agents

• Composes lower-level PAC agents to a single unit of higher abstraction

Collaborators

Top-level agent


Bottom-level agent

44


ClassBottom-level Agent

Responsibility

• Provides a specific view of the software or a system service, including its associated human-computer interaction

Collaborators

Top-level agent


45

Presentation-Abstraction-Control Variants

PAC agents as active objects By using multi-threading all the agents can be active

the same time PAC agents as processors

Agents located on different processes or on remote machines

46

Presentation-Abstraction-Control Advantages

Separation of concerns Different semantic concepts in the application

domain are represented by separate agents Support for change and extension

Changes within the presentation or abstraction components of a PAC agent do not affect other agents in the system.

Support for multi-tasking Agents can be distributed easily to different threads,

processes or machines

47

Presentation-Abstraction-Control Disadvantages

Low efficiency Overhead in agents communication

Increased system complexity Implementing every semantic concept with an agent

A sea of agents

Complex control component Its interface must be independent of internal details

48

References Buschmann F., et. al, “Pattern – Oriented

Software Architecture”, John Willey & Sons, 1996

Brown K., “Crossing Chasms: The Architectural Patterns”

Shaw M., “Patterns for software architecture”, First annual conference on the pattern languages of programming, 1994

Schmidt D., “Inside Patterns”, 2000

49

THE END

1 Architectural Patterns Yasser Ganji Saffar [email protected].

Documents

Transcript of 1 Architectural Patterns Yasser Ganji Saffar [email protected].