Bruce Douglass - Realtime Design Patterns 2

8/2/2019 Bruce Douglass - Realtime Design Patterns 2

1/104

1 Telelogic AB Page 1

Bruce Powel Douglass, PhD

Telelogic, Inc.

www.ilogix.com

Real-Time Design Patterns

UML is a trademark or registered trademark of Object Management Group, Inc. in the U.S. and other countries.


2/104

2 Telelogic AB

Agenda

Design Process Where does architecture fit in?

What is a design pattern?

Architectural design patterns Execution Control Structure

Resource Management

Safety and Reliability


3/104

3 Telelogic AB

Analysis in ROPES

RequirementsAnalysis

Systems Engineering

Object Analysis

Analysis

ArchitecturalDesign

MechanisticDesign

DetailedDesign

Design

TranslationTesting

Party!

IntegrationTesting

ValidationTesting

Coding

UnitTesting

IterativePrototypes


4/104

4 Telelogic AB

Analysis

Analysis is theidentification of therequired properties

of all possibleacceptable solutions


5/104

5 Telelogic AB

Design in ROPES

RequirementsAnalysis

Systems Engineering

Object Analysis

Analysis

ArchitecturalDesign

MechanisticDesign

DetailedDesign

Design

TranslationTesting

Party!

IntegrationTesting

ValidationTesting

Coding

UnitTesting

IterativePrototypes


6/104

6 Telelogic AB

Design

Design is the selectionof one particular solutionwhich optimizes the set

of design criteria withrespect to the relative

importance of each


7/104

7 Telelogic AB

Common Design Criteria

Performance Average

Worst-case

Predictability

Resource usage Robustness

Thread safety

Minimization of resources (space)

Minimization of resources (time) Safety

Reliability

Reusability

Extensibility & evolvability Maintainability

Time-to-market

Standard conformance

Quality of Service (QoS)always drives your design


8/104

8 Telelogic AB

Analysis

What, not How Identify all properties that must exist in all acceptable solutions Requirements Analysis

Identify black box functionality Use case and context views

Object Analysis Identify essential object model

Class, state and scenario views


9/104

9 Telelogic AB

Design

Howanalysis model will be implemented Identify and refine the properties of one particular solution Two approaches

Elaborative Design

Refine analysis model by adding more detail

Translative Design

Build a translator that embodies design decisions


10/104

10 Telelogic AB

Creative Design

Internalization

Pattern Matching

Sequential Analysis


11/104

11 Telelogic AB

(Physical) Architectural Design

(Harmony) Architectural Design consists of 5 interrelated model views: Concurrency and Resource View

Deployment View

Distribution View

Safety and Reliability View

Subsystem and Component View

Each Architectural View will have its own design patterns.

The complete system architecture is the set of design patterns

used in of the aspects of physical architecture.


12/104

12 Telelogic AB

Aspects of Architecture

Subsystem and

Component View

Concurren

cyand

Resource

View

Distributi

onView

Sa

fety

and

Reliabi

lityV

iew

Deploym

ent

View


13/104

13 Telelogic AB

Example of Pattern Selection

0

10

20

30

40

50

60

70

80

Worst Case Perf

Worst Case PerfSafety

Reliability

Memory Usage

Portability

Time to Market

Architectural Patterns:

Static priority Pattern Fixed Block Memory AllocationPattern Channel Pattern Triple Modular RedundancyPattern

Design Criteria ranked by criticality

SafetyReliability

MemoryPortability

TTM


14/104

14 Telelogic AB

Example of Pattern Selection (2)

0

10

20

30

40

50

60

70

80

90

Time to Market

Time to Market

Reusability

Simplicity

Performance

Reliability

Safety

Architectural Patterns:

Recursive Containment Pattern Cyclic Executive Pattern Dynamic Memory Pattern Container-Iterator PatternDesign Criteria ranked by criticality

ReusabilitySimplicity

PerformanceReliability

Safety


15/104

15 Telelogic AB

Mechanistic Design

Addition and refinement of objects to implement analysis modelsAddition of glue objects

Containers and Collections

Interfaces Medium-level policies

Optimized rendezvous among threads

Aid reuse by enforcing

Good abstraction

Good encapsulation


16/104

16 Telelogic AB

Detailed Design

Refinement of details within objects themselves Visibility

Internal decomposition of services

Internal data structuring and typing

Internal safety and reliability means

Data redundancy

Internal implementation policy of associations and object messaging


17/104

17 Telelogic AB

Design Patterns

Design patterns are generalized solutions to recurring optimization problems

reified structures of object collaboration that reappear in a variety of

contexts

Parameterized collaborations of objects, where the object roles are the

formal parameters and the objects that play those roles are the actual

parameters when the pattern is instantiated

UML has introduced a notation to explicitly capture design patterns. Shown as a dotted ellipse with dotted lines to the collaborating objects

or classes


18/104

18 Telelogic AB

Example Analysis Model Collaboration


19/104

19 Telelogic AB

Design Pattern: Observer Pattern Specification


20/104

20 Telelogic AB

Design Pattern: Observer Pattern Instantiation


21/104

21 Telelogic AB

Why Use Design Patterns?

Reuse effective design solutions Provide a more powerful vocabulary of design concepts to developers Develop optimal designs for specific design criteria Develop more understandable designs


22/104

22 Telelogic AB

How do I Apply Design Patterns???

1. Construct the initial model2. Identify the design criteria3. Rank the design criteria in order of importance4. Identify design patterns that optimize the system (architectural) or

collaboration (mechanistic) for the critical design criteria at the

expense of the lesser important ones

1. Architectural patterns apply system-wide

2. Mechanistic patterns apply collaboration-wide

3. State behavioral patterns apply object state machine-wide


23/104

23 Telelogic AB

Architectural Design Patterns


24/104

24 Telelogic AB

Channel Pattern

Problem Efficient execution of a system in which data is successively transformed in a series of steps

Want to organize and manage a hi-reliability, hi-availability, or safety-critical system that must

provide redundancy of end-to-end behaviors

Solution Construct the system as a channel, a large scale subsystem which handles data from acquisition

all the way through dependent actuation. Provide as many independent channels as necessary.

Consequences

A simple organizational pattern that permits redundancy to be easily added.

May use additional memory since channels are designed to be independent, requiring replication

(redundancy)


25/104

25 Telelogic AB

Channel Pattern

Input Filter Output Filter AbstractTransformation

Output

Sink

channel

datum

[raw]

datum

[cooked]

datum

[partially cooked]

"Object in State" notationin the UML. State is insquare brackets.

Concrete

Transformation

transformacquire issue


26/104

26 Telelogic AB

Channel Pattern Example


27/104

27 Telelogic AB

Concurrency Architecture Patterns


28/104

28 Telelogic AB

Message Queuing Pattern

Problem A simple way to request services be performed across thread boundaries in a thread-robust way

Solution Queue incoming services in the receiving thread until that thread runs then dequeue and service

the requests

Consequences This approach is simple and supported by most operating systems

Service responses are delayed until the target thread actually runs, so response may not be timely

No mutual exclusion problem because requests are serialized


29/104

29 Telelogic AB

Message Queuing Pattern

Thread

myQ

targetQ

1

1

*

1

Mutex

lock()release()

Queue

insert()remove()


30/104

30 Telelogic AB

Guarded Call Pattern

Problem Need timely response to service requests across multiple threads, and the synchronization

across thread boundaries must handle mutual exclusion issues for thread-safe rendezvous

Solution Permit calls to methods of object across thread boundaries, but protect those calls with a mutual

exclusion semaphore, 1 semaphore per shared object

Consequences

A simple solution supported by most operating systems

Can lead to blockingwhen the target object is currently locked

Can lead to unbounded priority inversion unless a priority inversion control pattern is also applied

(e.g. Highest Locker or Priority Inheritance)


31/104

31 Telelogic AB

Guarded Call Pattern

mutex

BoundaryObjectclient

Client Thread Server Thread

Server

1

1

*

1 Shared

Resource

*

*

* *


32/104

32 Telelogic AB

Rendezvous Pattern

Problem Need a collaboration structure that allows any arbitrary set of preconditional invariants to be

met for thread synchronization, independent of task phasings, scheduling policies, and

priorities.

Solution Reify the rendezvous policy as a class that mediates how the threads collaborate

Consequences

An easy-to-implement pattern that can implement an arbitrarily complex set of thread

rendezvous preconditions

Thread Barrier Pattern is a common instantiation of this pattern


33/104

33 Telelogic AB

Rendezvous Pattern

Rendezvous

Client Thread

*

1reset(void): void

register(callback:address)

release(void): void

Callback

2..*

1{ mapped }

Synch Po licy

1

1

notify(void): void


34/104

34 Telelogic AB

Thread Barrier Pattern Statechart

Synch Policy

Ready

Counting

start synch/

count = 0;

[count>=ExpCount-1]

[else]/

myRendezvous->GEN(evReleaseAll)

/ExpCount = ExpectedCount

evSynch/++count


35/104

35 Telelogic AB

Memory Patterns

Pooled Allocation Pattern Fixed Sized Buffer Allocation Pattern Smart Pointer Pattern

Pooled Allocation Pattern


36/104

36 Telelogic AB


Problem In a situation that cannot use dynamic allocation during run time, we

need to use many small objects but we cannot statically allocate their

ownership in the worst case, even though we CAN handle all worst

cases Solution

Preallocate pools of small shared objects, giving them to the clients as

necessary, who return them when done

Consequences No memory fragmentation

No unpredictable memory allocation

Handles more complex situations than the Static Allocation Pattern



37/104

37 Telelogic AB


Client 1

Generic Pool Manager

initiailize

allocate

release

*

Object

Server

bind

pooledClass,

BufferSize: int

Resource Pool Manager

ResourceClass, size

pooledClass*

1freeObject

Fixed Sized Buffer Pattern


38/104

38 Telelogic AB

Fixed-Sized Buffer Pattern

Problem In situations complex enough to require dynamic memory allocation,

sometimes we cannot live with memory fragmentation

Solution

Allocate memory dynamically in fixed sized chunks which are

predetermined to allow us to always satisfy a memory request if any

memory is available

Consequences Eliminates memory fragmentation

Requires static (design) analysis to determine optimal block sizes and

number of sized heaps

Wastes memory since it is always allocated in fixed sized blocks

Fi d Si d B ff P tt


39/104

39 Telelogic AB

Fixed-Sized Buffer Pattern

Memory Segment

Heap Manager Sized Heap

Allocated B lock

Free Block

Object Factory

Client

1

*

*

1

1

1

1

*

1

*

*

*

{ allocated and free

blocks in the same

mem ory segment shall

be all the sam e size }

free List

Smart Pointer Pattern


40/104

40 Telelogic AB


Problem Pointers are very powerful but induce many kinds of errors. This is because

they do not have a means to ensure pre- and post-conditional invariants

Solution

Reify the pointers as a class so that access to the pointer behavior can be

controlled via operations that ensure correct behavior

Consequences Stops most common pointer errors dangling pointer, memory leaks,

pointer arithmetic

Doesnt work well with cyclic data structures



41/104

41 Telelogic AB


* 1TargetSmart Pointer

Client

*

rawPtr: Target*

Smart Pointer()

Smart Pointer(tAdd: address)

~Smart Pointer()

access()

referenceCount: int

Target Wrapper

Distribution Patterns


42/104

42 Telelogic AB

Distribution Patterns

Observer Pattern Data Bus Pattern Proxy Pattern Broker Pattern

Observer Pattern


43/104

43 Telelogic AB

Observer Pattern

Problem How to efficiently give up-to-date data to clients in a timely way

Solution Have clients subscribe to the server. When new data is available, the

server walks the client list and sends them the new data

Consequences Works well with minimal complexity

Observer Pattern


44/104

44 Telelogic AB

Observer Pattern

Concrete Subject

Abstract Subject

Notification Handle

Abstract Client

subscribe(*Abstract Client)

unsubscribe(*Abstract Client)

notify()

* 1 1

*

Concrete Client

void accept(data)

Data

value: type

1

1 1

1

{ may refer to the sameinstance (pass by

reference) or a copy of

the original (pass by

value) }

Observer Pattern Example


45/104

45 Telelogic AB


Wheel Sensor

Cruise Control

Speedometer

AntiSpin

Controller

CallbackList

Callback

*

1

1

Speed

1

Speed Client

void accept(s: Speed)

Speed

1

concrete subjectabstract client

concrete client

concrete client

concrete client

datadata

notification handle

*

1

Proxy Pattern


46/104

46 Telelogic AB

Proxy Pattern

Problem Use an observer pattern across multiple address spaces with a variety of

different servers and clients, isolating away the knowledge of the

infrastructure of the means to communicate

Solution Similar to a observer pattern but with client and server proxies to isolate the

required infrastructure

Consequences A simple adaptation of the observer pattern

Good isolation of subject from communications

Optimizes bus traffic

Proxy Pattern


47/104

47 Telelogic AB

Proxy Pattern

Abstract Proxy

Client-side Proxy

Notification

HandleAbstract Client

*

1

Concrete Client

void accept(data)

Data

value: type

1

1

1

Concrete Server

1

*

1

server dataclient data

*

client proxy server proxyServer-side Proxy

1

*

Abstract Server



notify()

Local Notification

Handle

Remote Notification

Handle

send()

Proxy Pattern Example


48/104

48 Telelogic AB

Proxy Pattern Example

concrete server

concrete client

Safety

Monitor

Safety Processor

Medical Delivery Processor User Control Processor

Gas Mixer Processor

O2 Flow

Sensor

Inspiration

Controller

O2 FlowServer Proxy

server-side proxy

P2: O2 Flow

Client Proxy

P3: O2 Flow

Client Proxy

P1: O2 Flow

Client Proxy

HistogramView

Drug Vaporizer Callback

Callback

Callback

Object ID

concrete client

concrete client

local notification

handle

local notification

handle

local notification

handle

remote notification

handle

client-side proxy

client-side proxy

client-side proxy

*

*

*

*

CommunicationsB

us

concrete client

O2 Flow

data

Broker Pattern


49/104

49 Telelogic AB

Broker Pattern

Problem Support a symmetric distribution architecture (as for dynamic load

balancing), and allow objects to find each other without knowing their

locations a priori

Solution Add a broker as an object repository, such that when servers run, they

register with the broker; when clients need to access a server, they request

the location of the server from the broker

Consequences Good support for symmetric architectures

Good commercial support with CORBA

Broker Pattern


50/104

50 Telelogic AB

Abstract Proxy

Client-side Proxy

Notification

HandleAbstract Client

*

1

Concrete Client

void accept(data)

Data

value: type

1

1

1

Concrete Server

1

*

1

server dataclient data

*

client proxy server proxyServer-side Proxy

1

*

Abstract Server



notify()

Local Notification

Handle

Remote Notification

Handle

Broker

Remote Notification

Handle

*

{ may be mediated entirely by

the Broker }

Broker Pattern Example


51/104

51 Telelogic AB

p

Broker Pattern Example


52/104

52 Telelogic AB

p

ORBFurnaceInterface

Furnace

ThermometerInterface

Thermometer

Temperature

Controller

Controller

Interface

concrete server concrete server

brokerserver-side proxy server-side proxy

client-side proxy

client proxy

Safety and Reliability Patterns


53/104

53 Telelogic AB

Protected Single Channel Pattern Homogeneous Redundancy Pattern Heterogeneous Redundancy Pattern Triple Modular Redundancy Pattern

Monitor-Actuator Pattern

Safety and Reliability


54/104

54 Telelogic AB

Reliability is measured by MTBF MTBF = probability of fault

Safety is measured by risk risk = severity * likelihood

Fault is nonconformant behavior Error a design or implementation flaw

Failure breakage of something that was previously correct

Safety vs Reliability


55/104

55 Telelogic AB

SafetyReliability

Systems without a

fail-safe state

Systems wiitha fail-safe

state

Systems without

safety impact

Protected Single Channel Pattern


56/104

56 Telelogic AB

Problem Provide protection against errors (design flaws) in a cost effective way

Solution A variant of the Channel pattern the uses light-weight redundancy to

provide identification of errors

Consequences Low design cost

Low recurring cost

Not able to continue in the presence of faults

Protected Single Channel Pattern


57/104

57 Telelogic AB

Input

Processing

Data

Transformation Output

ProcessingInput

Sensor

Actuator

Data Validation

control

signal

channel

* * * *

*

*

*

1

1

*

* *

1

0,1

successortransformationpredecessor

transformation

Protected Single Channel Pattern Example


58/104

58 Telelogic AB

Speed Sensor

Motor

Thermometer

Motor

Rate

ProtectedCRC

CRC

setCRC()getCRC()

checkCRC()

setRateI()emergencyStop

FilteredSpeed

ProtectedOnesComp

value: intonesCompvalue: int

setValue()getValue()

MotorController

ControlRatemeasuredRate

runDuration

setControlRateI()setMeasuredRate()

setRunDuration()

Speed SafetyMonitor

output processing

input processing

input processing

data transformation

data validation

input sensor

input sensor

actuator

shutdownRate

Temperature Controller

MeasuredTemperature

ShutdownTemperature

Motor Control Channel

channel

Homogeneous Redundancy Pattern


59/104

59 Telelogic AB

Problem Provide the ability to continue in the presence of a fault Solution

Provide redundancy in the large by replicating channels

Consequences Low design-time cost

High recurring cost

Able to continue in the presence of a failure Does not recover from errors

Homogeneous Redundancy Pattern


60/104

60 Telelogic AB

InputProcessing

OutputProcessing

PrimaryInput

Sensor

Data Validaton

Primary Actuation Channel

Actuation

Validation

Primary

Actuator

DataTransformation

Output

Processing

Data ValidationActuation

Validation

SecondaryActuator

Input

ProcessingSecondary

InputSensor

Data

Transformation

Secondary Actuation Channel

1

0,1

successortransformation

predecessortransformation

10,1

successor

transformation

predecessor

transformation

Homogeneous Redundancy Pattern Example

Main Flow Contr ol Channeld t t f tiPrimary Ac t ation Channel


61/104

61 Telelogic AB

O2 Senso rDriver

Gas Flow

Controller

Gas FlowDriver

PrimaryO2

SensorO2 Monitor

Gas FlowMonitor

PrimaryGas

Mixer

Flow SensorDriver

PrimaryFlow

Sensor O2 Flow Rate

O2 Sens or

Driver

Gas Flow

Controller

Gas FlowDriverBackup

O2Sensor

O2 MonitorGas Flow

Monitor

Backup

GasMixer

Flow Sensor

DriverBackup

Flow

Sensor

O2 Flow Rate

Backup Flow Contr ol Channel


predecessor

transformation

predecessor

transformation


input processing

input processing

input processing

input processing

data validation

data validation

data transformation

data transformation

outputprocessing

outputprocessing

actuation validation

actuation validation

Primary Ac tuation Channel

Secondary Actuation Channel data transformation


data transformation

Built In Tes t

Built In Tes t

Triple Modular Redundancy Pattern


62/104

62 Telelogic AB

Problem Want to provide protection against single point failures and be able tocontinue

Solution

Replicate the channel three times, run all three in parallel

If one channel breaks, then the other two will concur

Consequences A common solution to redundancy

Low design cost

Very high recurring cost

Good support for failures but not for errors

Triple Modular Redundancy Pattern


63/104

63 Telelogic AB

inputprocessing

datatransformation

outputprocessing

inputsensor

Actuator

input

processing

data

transformation

output

processing

inputprocessing

datatransformation

outputprocessing

comparator

Actuation Channel 3

0,1successor

transformation


1

0,1successor

transformation

predecessor

transformation

1

0,1successor

transformation


1

Actuation Channel 2

Actuation Channel 1

Triple Modular Redundancy Pattern Example


64/104

64 Telelogic AB

wheel

sensor

device driver

data

preprocessing

EngineController

comparator

1

Channel 1

optical

wheel

speedsensor Raw Data Filtered Data

Kalman Filter

1

**

Train Speed Computation Subsystem

wheel

sensor

device driver

data

preprocessing

1

Channel 2

optical

wheel

speed

sensor Raw Data Filtered Data

Kalman Filter

1

* *

wheelsensor

device driver

datapreprocessing

1

Channel 3

opticalwheel

speed

sensor Raw Data Filtered Data

Kalman Filter

1* *

Mechanistic Design Patterns


65/104

65 Telelogic AB

Fundamental Concepts


66/104

66 Telelogic AB

Mechanistic patterns all start with First, create an object that

The vast majority of design patterns use a combination of two veryfundamental concepts:

Delegation

Interface

The Singleton design patternis an exception to this rule.

Delegation


67/104

67 Telelogic AB

Delegation is a way to extend the functionality of a class by usingan extra class to provide additional functionality. It is not always necessary to use Inheritance to extend

functionality, often Delegation is more preferable.

With DelegationWithout Delegation

Interface


68/104

68 Telelogic AB

This is really what most Design Patterns are based upon. The ideais to keep the things that change, separate from the things thatdont change.

Pure Virtual

operations

Categories of Mechanistic Design Patterns


69/104

69 Telelogic AB

Creational Control the instantiation or creation process

Structural Concerned with how classes and objects work together to form larger

collaborations Behavioral

Concerned with algorithms and roles objects play within collaborations

The selection and categorization of patterns used here isbased largely on the book Design Patterns: Elements ofReusable Object-Oriented Softwareby Gamma et. al, 1995

Creational Patterns

F


70/104

70 Telelogic AB

Factory Factory Method Prototype Singleton

Factory Pattern

P bl


71/104

71 Telelogic AB

Problem

Provide an interface for creating families of related or dependent objects

Applicability

When you want to enforce independence of the system structure from how it is

instantiated

When a system is to be run on different platforms parts that vary among the

platforms

When a set of objects are meant to be used together

Solution

Create an abstract factory that knows how to create all the related parts; subclasses

of the factory know of to create the parts for a specific platform

Consequences

It makes it easy to create platform-specific families of related classes

It promotes consistency among the product families

It aids understanding the common ground between families

It is easy to add new platforms for a set of objects

Factory Pattern


72/104

72 Telelogic AB

Factory Pattern Example


73/104

73 Telelogic AB

Factory Pattern Example


74/104

74 Telelogic AB

NT OS Family

VxWorks OS Family

Structural Patterns

Adapter


75/104

75 Telelogic AB

Adapter Bridge Composite Decorator

Flyweight

Adapter Pattern

Problem


76/104

76 Telelogic AB

Problem

You want to adapt the interface of a class to meet a client need

Applicability

(Class) When you have an existing class that meets the semanticneed but has an

incompatible interface

(Class) When you want to reuse an existing class in as-yet-determined

circumstances

(Object)

Solution

Create a class subclasses both the expected and actual interfaces and does the

impedance matching, or

Create an object that refactors and forwards the requests

Consequences

Class adapters work with only the specific class not subclasses

Object adapters work with class and subclasses

Class adapters introduce only a single object

Adapter Pattern (Class)


77/104

77 Telelogic AB

Adapter Pattern (Object)


78/104

78 Telelogic AB

Adapter Pattern Example (Class)


79/104

79 Telelogic AB

Adapter Pattern Example (Object)


80/104

80 Telelogic AB

Composite Pattern

Problem


81/104

81 Telelogic AB

Want to represent the grouping of smaller primitive semantic objects into larger assemblies

Applicability

When you want to represent whole-part hierarchies

When you want to assign creation-destruction responsibilities

When the whole is at a higher level of abstraction than the parts

E.g. System contains subsystems contains sub-subsystems

Solution

Use the Composite Class of UML 2.0/Rhapsody

Consequences

Very effective way to represent hierarchies at possibly many levels

Very straightforward way of assigning create-destroy responsibilities

Specific creation-destruction sequences must be added to the structured class behaviors, if

needed

Composite is responsible, in general, to orchestrate its parts to deliver services

The Port Pattern provides explicit delegation w/o Composite delegation

Composite Pattern


82/104

82 Telelogic AB

Composite Pattern Example


83/104

83 Telelogic AB

Behavioral Patterns

Chain of Responsibility


84/104

84 Telelogic AB

Command Interpreter Container-Iterator

Mediator Memento Observer State Strategy Specializable (Template) Method

Chain of Responsibility Pattern

Problem


85/104

85 Telelogic AB

You want to avoid coupling of a request to a specific receiver by giving more than

one object a chance to fulfill the request

Applicability

When the best place to handle a request isnt always known at design time When you want to have multi-level response

When you want the request handlers to be specified dynamically

Solution

Create a chain of objects and pass the request from object-to-object until the

request is fulfilled or until all objects have had a chance to act

Consequences

Reduced design-time coupling of classes

Ability to add request processing dynamically

There is no guarantee that a request will be handled because there is no grand

oversight

Chain of Responsibility Pattern


86/104

86 Telelogic AB

Chain of Responsibility Pattern Example


87/104

87 Telelogic AB

Container-Iterator Pattern

Problem


88/104

88 Telelogic AB

You want to efficiently manage collections and hide the implementation of the collection

Applicability

When containment is independent of object semantics

When you want to support multiple clients of the same collection

When you want to supply a consistent interface for collection navigation

Solution

Reify the collection as an object and provide implementation-free interface for the kind of collection

Usually implemented as a parameterized class (template)

Add iterators to support multiple-client navigation over the collection

Consequences

Allows extensibility in navigation of collections

Allows easy changes to types of collections

Iterators simplify the navigation over the collections

Multiple clients can simultaneously navigate over the collection

Note: Rhapsody provides this pattern automatically

Container-Iterator Pattern


89/104

89 Telelogic AB

Container-Iterator Pattern Example


90/104

90 Telelogic AB

Container-Iterator Pattern Example


91/104

91 Telelogic AB

Mediator Pattern

Problem

You want to coordinate a complex interaction among a set of objects


92/104

92 Telelogic AB

You want to coordinate a complex interaction among a set of objects

Applicability

When a set of objects must coordinate in a well-defined but complex manner

When reusing an object is difficult because it has interactions with a large number otherobjects

When interactive behavior arising from a group of objects should be done without a lot of

subclassing

Solution Reify the interaction as a class that coordinates the interaction with the objects

The architectural Rendezvous Pattern is a large scale example of this pattern applied to

thread interaction

Consequences

Limits subclassing

Decouples classes within the interacting set

Abstracts and simplifies object interaction protocols

Mediator Pattern


93/104

93 Telelogic AB

Mediator Pattern Example


94/104

94 Telelogic AB

Observer Pattern

ProblemYou want to efficiently notify a set of clients that relevant data has changed


95/104

95 Telelogic AB

You want to efficiently notify a set of clients that relevant data has changed

Applicability When you want to efficiently notify a set of objects about a value or state

change When you want to dynamically add or remove objects to be notified

When the server should have no knowledge of the client(s)

Solution

Create a Subject class that provides subscribe() and unsubscribe

operations

When data changes, notify all subscribed objects

Consequences Easy to dynamically add or remove observers

Supports broadcast of state information

Observer Pattern


96/104

96 Telelogic AB



97/104

97 Telelogic AB

Strategy Pattern

Problem

You want to apply a family of algorithms and make them interchangeable even


98/104

98 Telelogic AB

You want to apply a family of algorithms and make them interchangeable, even

dynamically so

Applicability

When you want to apply an algorithm to different classes

When you need algorithmic variants

When you need to vary a strategy or algorithm at run-time

Solution

Reify the strategy(ies) as objects and attach them to the appropriate context objects

Consequences

Easy management and application of related algorithms

Alternative to subclassing the context Eliminates conditional statements in algorithms

Allows selection of an optimalalgorithmic strategy depending on circumstances

Some overhead for collaboration between context and strategy

Strategy Pattern


99/104

99 Telelogic AB

Strategy Pattern Example


100/104

100 Telelogic AB

Specializable Method Pattern

Problem You want to define a skeleton of an algorithm and allow specialized steps


101/104

101 Telelogic AB

g p p

to be subclassed

Applicability When the algorithm has a static structure but some steps may differ

depending on the need

When the algorithm is linearly factorable

Solution

Define a context class for the algorithm structure and allow subclasses tomodify the steps that may vary

Aka Template Method

Consequences Good algorithmic reuse

Useful for class libraries

Specializable Method Pattern


102/104

102 Telelogic AB

Specializable Pattern Example


103/104

103 Telelogic AB

Real-Time Pattern References

White papers on real-time, objects, and the UML at www.ilogix.com


104/104

104 Telelogic AB

Documents

Bruce Douglass - Realtime Design Patterns 2