Bruce Douglass - Realtime Design Patterns 2
Transcript of 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.
-
8/2/2019 Bruce Douglass - Realtime Design Patterns 2
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
-
8/2/2019 Bruce Douglass - Realtime Design Patterns 2
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
-
8/2/2019 Bruce Douglass - Realtime Design Patterns 2
4/104
4 Telelogic AB
Analysis
Analysis is theidentification of therequired properties
of all possibleacceptable solutions
-
8/2/2019 Bruce Douglass - Realtime Design Patterns 2
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
-
8/2/2019 Bruce Douglass - Realtime Design Patterns 2
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
-
8/2/2019 Bruce Douglass - Realtime Design Patterns 2
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/2/2019 Bruce Douglass - Realtime Design Patterns 2
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
-
8/2/2019 Bruce Douglass - Realtime Design Patterns 2
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
-
8/2/2019 Bruce Douglass - Realtime Design Patterns 2
10/104
10 Telelogic AB
Creative Design
Internalization
Pattern Matching
Sequential Analysis
-
8/2/2019 Bruce Douglass - Realtime Design Patterns 2
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.
-
8/2/2019 Bruce Douglass - Realtime Design Patterns 2
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
-
8/2/2019 Bruce Douglass - Realtime Design Patterns 2
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
-
8/2/2019 Bruce Douglass - Realtime Design Patterns 2
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
-
8/2/2019 Bruce Douglass - Realtime Design Patterns 2
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
-
8/2/2019 Bruce Douglass - Realtime Design Patterns 2
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
-
8/2/2019 Bruce Douglass - Realtime Design Patterns 2
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
-
8/2/2019 Bruce Douglass - Realtime Design Patterns 2
18/104
18 Telelogic AB
Example Analysis Model Collaboration
-
8/2/2019 Bruce Douglass - Realtime Design Patterns 2
19/104
19 Telelogic AB
Design Pattern: Observer Pattern Specification
-
8/2/2019 Bruce Douglass - Realtime Design Patterns 2
20/104
20 Telelogic AB
Design Pattern: Observer Pattern Instantiation
-
8/2/2019 Bruce Douglass - Realtime Design Patterns 2
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
-
8/2/2019 Bruce Douglass - Realtime Design Patterns 2
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
-
8/2/2019 Bruce Douglass - Realtime Design Patterns 2
23/104
23 Telelogic AB
Architectural Design Patterns
-
8/2/2019 Bruce Douglass - Realtime Design Patterns 2
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)
-
8/2/2019 Bruce Douglass - Realtime Design Patterns 2
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
-
8/2/2019 Bruce Douglass - Realtime Design Patterns 2
26/104
26 Telelogic AB
Channel Pattern Example
-
8/2/2019 Bruce Douglass - Realtime Design Patterns 2
27/104
27 Telelogic AB
Concurrency Architecture Patterns
-
8/2/2019 Bruce Douglass - Realtime Design Patterns 2
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
-
8/2/2019 Bruce Douglass - Realtime Design Patterns 2
29/104
29 Telelogic AB
Message Queuing Pattern
Thread
myQ
targetQ
1
1
*
1
Mutex
lock()release()
Queue
insert()remove()
-
8/2/2019 Bruce Douglass - Realtime Design Patterns 2
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)
-
8/2/2019 Bruce Douglass - Realtime Design Patterns 2
31/104
31 Telelogic AB
Guarded Call Pattern
mutex
BoundaryObjectclient
Client Thread Server Thread
Server
1
1
*
1 Shared
Resource
*
*
* *
-
8/2/2019 Bruce Douglass - Realtime Design Patterns 2
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
-
8/2/2019 Bruce Douglass - Realtime Design Patterns 2
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
-
8/2/2019 Bruce Douglass - Realtime Design Patterns 2
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
-
8/2/2019 Bruce Douglass - Realtime Design Patterns 2
35/104
35 Telelogic AB
Memory Patterns
Pooled Allocation Pattern Fixed Sized Buffer Allocation Pattern Smart Pointer Pattern
Pooled Allocation Pattern
-
8/2/2019 Bruce Douglass - Realtime Design Patterns 2
36/104
36 Telelogic AB
Pooled Allocation Pattern
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
Pooled Allocation Pattern
-
8/2/2019 Bruce Douglass - Realtime Design Patterns 2
37/104
37 Telelogic AB
Pooled Allocation Pattern
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
-
8/2/2019 Bruce Douglass - Realtime Design Patterns 2
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
-
8/2/2019 Bruce Douglass - Realtime Design Patterns 2
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
-
8/2/2019 Bruce Douglass - Realtime Design Patterns 2
40/104
40 Telelogic AB
Smart Pointer Pattern
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
Smart Pointer Pattern
-
8/2/2019 Bruce Douglass - Realtime Design Patterns 2
41/104
41 Telelogic AB
Smart Pointer Pattern
* 1TargetSmart Pointer
Client
*
rawPtr: Target*
Smart Pointer()
Smart Pointer(tAdd: address)
~Smart Pointer()
access()
referenceCount: int
Target Wrapper
Distribution Patterns
-
8/2/2019 Bruce Douglass - Realtime Design Patterns 2
42/104
42 Telelogic AB
Distribution Patterns
Observer Pattern Data Bus Pattern Proxy Pattern Broker Pattern
Observer Pattern
-
8/2/2019 Bruce Douglass - Realtime Design Patterns 2
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
-
8/2/2019 Bruce Douglass - Realtime Design Patterns 2
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
-
8/2/2019 Bruce Douglass - Realtime Design Patterns 2
45/104
45 Telelogic AB
Observer Pattern Example
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
-
8/2/2019 Bruce Douglass - Realtime Design Patterns 2
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
-
8/2/2019 Bruce Douglass - Realtime Design Patterns 2
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
subscribe(*Abstract Client)
unsubscribe(*Abstract Client)
notify()
Local Notification
Handle
Remote Notification
Handle
send()
Proxy Pattern Example
-
8/2/2019 Bruce Douglass - Realtime Design Patterns 2
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
-
8/2/2019 Bruce Douglass - Realtime Design Patterns 2
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
-
8/2/2019 Bruce Douglass - Realtime Design Patterns 2
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
subscribe(*Abstract Client)
unsubscribe(*Abstract Client)
notify()
Local Notification
Handle
Remote Notification
Handle
Broker
Remote Notification
Handle
*
{ may be mediated entirely by
the Broker }
Broker Pattern Example
-
8/2/2019 Bruce Douglass - Realtime Design Patterns 2
51/104
51 Telelogic AB
p
Broker Pattern Example
-
8/2/2019 Bruce Douglass - Realtime Design Patterns 2
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
-
8/2/2019 Bruce Douglass - Realtime Design Patterns 2
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
-
8/2/2019 Bruce Douglass - Realtime Design Patterns 2
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
-
8/2/2019 Bruce Douglass - Realtime Design Patterns 2
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
-
8/2/2019 Bruce Douglass - Realtime Design Patterns 2
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
-
8/2/2019 Bruce Douglass - Realtime Design Patterns 2
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
-
8/2/2019 Bruce Douglass - Realtime Design Patterns 2
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
-
8/2/2019 Bruce Douglass - Realtime Design Patterns 2
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
-
8/2/2019 Bruce Douglass - Realtime Design Patterns 2
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
-
8/2/2019 Bruce Douglass - Realtime Design Patterns 2
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
successortransformation
predecessor
transformation
predecessor
transformation
successortransformation
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
successortransformation
data transformation
Built In Tes t
Built In Tes t
Triple Modular Redundancy Pattern
-
8/2/2019 Bruce Douglass - Realtime Design Patterns 2
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
-
8/2/2019 Bruce Douglass - Realtime Design Patterns 2
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
predecessortransformation
1
0,1successor
transformation
predecessor
transformation
1
0,1successor
transformation
predecessortransformation
1
Actuation Channel 2
Actuation Channel 1
Triple Modular Redundancy Pattern Example
-
8/2/2019 Bruce Douglass - Realtime Design Patterns 2
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
-
8/2/2019 Bruce Douglass - Realtime Design Patterns 2
65/104
65 Telelogic AB
Fundamental Concepts
-
8/2/2019 Bruce Douglass - Realtime Design Patterns 2
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
-
8/2/2019 Bruce Douglass - Realtime Design Patterns 2
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
-
8/2/2019 Bruce Douglass - Realtime Design Patterns 2
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
-
8/2/2019 Bruce Douglass - Realtime Design Patterns 2
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
-
8/2/2019 Bruce Douglass - Realtime Design Patterns 2
70/104
70 Telelogic AB
Factory Factory Method Prototype Singleton
Factory Pattern
P bl
-
8/2/2019 Bruce Douglass - Realtime Design Patterns 2
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
-
8/2/2019 Bruce Douglass - Realtime Design Patterns 2
72/104
72 Telelogic AB
Factory Pattern Example
-
8/2/2019 Bruce Douglass - Realtime Design Patterns 2
73/104
73 Telelogic AB
Factory Pattern Example
-
8/2/2019 Bruce Douglass - Realtime Design Patterns 2
74/104
74 Telelogic AB
NT OS Family
VxWorks OS Family
Structural Patterns
Adapter
-
8/2/2019 Bruce Douglass - Realtime Design Patterns 2
75/104
75 Telelogic AB
Adapter Bridge Composite Decorator
Flyweight
Adapter Pattern
Problem
-
8/2/2019 Bruce Douglass - Realtime Design Patterns 2
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)
-
8/2/2019 Bruce Douglass - Realtime Design Patterns 2
77/104
77 Telelogic AB
Adapter Pattern (Object)
-
8/2/2019 Bruce Douglass - Realtime Design Patterns 2
78/104
78 Telelogic AB
Adapter Pattern Example (Class)
-
8/2/2019 Bruce Douglass - Realtime Design Patterns 2
79/104
79 Telelogic AB
Adapter Pattern Example (Object)
-
8/2/2019 Bruce Douglass - Realtime Design Patterns 2
80/104
80 Telelogic AB
Composite Pattern
Problem
-
8/2/2019 Bruce Douglass - Realtime Design Patterns 2
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
-
8/2/2019 Bruce Douglass - Realtime Design Patterns 2
82/104
82 Telelogic AB
Composite Pattern Example
-
8/2/2019 Bruce Douglass - Realtime Design Patterns 2
83/104
83 Telelogic AB
Behavioral Patterns
Chain of Responsibility
-
8/2/2019 Bruce Douglass - Realtime Design Patterns 2
84/104
84 Telelogic AB
Command Interpreter Container-Iterator
Mediator Memento Observer State Strategy Specializable (Template) Method
Chain of Responsibility Pattern
Problem
-
8/2/2019 Bruce Douglass - Realtime Design Patterns 2
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
-
8/2/2019 Bruce Douglass - Realtime Design Patterns 2
86/104
86 Telelogic AB
Chain of Responsibility Pattern Example
-
8/2/2019 Bruce Douglass - Realtime Design Patterns 2
87/104
87 Telelogic AB
Container-Iterator Pattern
Problem
-
8/2/2019 Bruce Douglass - Realtime Design Patterns 2
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
-
8/2/2019 Bruce Douglass - Realtime Design Patterns 2
89/104
89 Telelogic AB
Container-Iterator Pattern Example
-
8/2/2019 Bruce Douglass - Realtime Design Patterns 2
90/104
90 Telelogic AB
Container-Iterator Pattern Example
-
8/2/2019 Bruce Douglass - Realtime Design Patterns 2
91/104
91 Telelogic AB
Mediator Pattern
Problem
You want to coordinate a complex interaction among a set of objects
-
8/2/2019 Bruce Douglass - Realtime Design Patterns 2
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
-
8/2/2019 Bruce Douglass - Realtime Design Patterns 2
93/104
93 Telelogic AB
Mediator Pattern Example
-
8/2/2019 Bruce Douglass - Realtime Design Patterns 2
94/104
94 Telelogic AB
Observer Pattern
ProblemYou want to efficiently notify a set of clients that relevant data has changed
-
8/2/2019 Bruce Douglass - Realtime Design Patterns 2
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
-
8/2/2019 Bruce Douglass - Realtime Design Patterns 2
96/104
96 Telelogic AB
Observer Pattern Example
-
8/2/2019 Bruce Douglass - Realtime Design Patterns 2
97/104
97 Telelogic AB
Strategy Pattern
Problem
You want to apply a family of algorithms and make them interchangeable even
-
8/2/2019 Bruce Douglass - Realtime Design Patterns 2
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
-
8/2/2019 Bruce Douglass - Realtime Design Patterns 2
99/104
99 Telelogic AB
Strategy Pattern Example
-
8/2/2019 Bruce Douglass - Realtime Design Patterns 2
100/104
100 Telelogic AB
Specializable Method Pattern
Problem You want to define a skeleton of an algorithm and allow specialized steps
-
8/2/2019 Bruce Douglass - Realtime Design Patterns 2
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
-
8/2/2019 Bruce Douglass - Realtime Design Patterns 2
102/104
102 Telelogic AB
Specializable Pattern Example
-
8/2/2019 Bruce Douglass - Realtime Design Patterns 2
103/104
103 Telelogic AB
Real-Time Pattern References
White papers on real-time, objects, and the UML at www.ilogix.com
-
8/2/2019 Bruce Douglass - Realtime Design Patterns 2
104/104
104 Telelogic AB