1

Real Time Design Patterns

Oleh MedvedyevManager, Engineering29 March 2017

2

1. Design Pattern Basics2. Subsystem and Component Architecture

Patterns3. Concurrency Patterns 4. Memory Patterns5. Safety and Reliability Patterns

Agenda

3

Lucius Annaeus Seneca

The way is long if one follows precepts, but short... if one follows patterns.

4

Design Pattern Basics

5

“Design pattern is a general reusable solution to a commonly occurring problem within a given context in software design.””Design pattern is a written document that describes a general solution to a design problem that recurs repeatedly in many projects.””Design pattern is a repeatable solution to a software engineering problem.”

Patterns are not just software reuse but rather a kind of concept reuse.

Design Pattern Basics

6

• Design is always an optimization of an analysis model.• Design patterns are always a general concept for

how to optimize an analysis model in a particular way with particular effects.

• Optimization always entails improving some aspect of the system at the expense of others.

• To be a pattern, the problem must recur often enough to be usefully generalizable.

• The solution must also be general enough to be applied in a wide set of application domains.

Design Pattern Basics

7

Design Pattern BasicsPattern

HatchingPattern Mining

8

UML Basics

9

Subsystem and Component Architecture Patterns

10

• For many small- to medium-scale systems, a similar organization of the logical architecture permits developers to quickly and easily understand the organization of a new system

• Simple organizational pattern, allows portability of the application to other platforms and OS’s

Five-Layer Architecture PatternCollaboration Roles • Application• User Interface• Communication

- Middleware - Data transport

• Abstract OS• Abstract Hardware

11

• The basic concept of the Recursive Containment Pattern is that the way to construct a very complex system is to think of it as a set of interrelated parts at a number of levels of successive detail, something like a microscope with multiple levels of magnification.

Recursive Containment PatternCollaboration Roles Element - has two basic features. First, it provides a set of services through one or more opaque interfaces. Second, internally, it provides these services largely by delegation and coordination of smaller parts.

12

• The Hierarchical Control Pattern uses two types of interfaces: control interfaces that monitor and control how the behaviors are achieved and functional interfaces, which provide the services controlled by the other set of interfaces.

Hierarchical Control PatternCollaboration Roles • Control Interface - provides

services to manage how the functional services are performed—for example, switching to a different algorithm or providing a different quality of service

• Controller - provides two kinds of opaque interfaces to its clients: control interface and functional interfaces

• Functional Interface - provides the normal semantic services of the Controller.

• Leaf Element - class of any kind other than a Controller

13

Concurrency Patterns

14

• The Message Queuing Pattern uses asynchronous communications, implemented via queued messages, to synchronize and share information among tasks.

• Any information shared among threads is passed by value to the separate thread.

• Relatively heavyweight approach

Message Queuing Pattern

Collaboration Roles • Thread - it is the root of an operating system thread, task, or process.

It can both create messages to send to other Threads and receive and process messages when it runs.

• Queue - container that can hold a number of messages. • Mutex - provides protection from multiple access to the Queue

contents

15

• Sometimes asynchronous communication schemes, such as the Message Queuing Pattern, do not provide timely responses across a thread boundary. An alternative is to synchronously invoke a method of an object, nominally running in another thread. Care must be taken to ensure data integrity and to avoid synchronization and deadlock problems.

Guarded Call Pattern

Collaboration Roles • Server Thread - share the

Shared Resource and protect them with the Mutex.

• Client Thread – caller• Boundary Object - provides

the protected interface to the Server objects

• Mutex - permits only a single caller through at a time

• Server - uses the Shared Resource object, and second, it may provide a service useable to a Client across the thread boundary that may use the Shared Resource

• Shared Resource - any object that provides data or a service

16

• As each thread becomes ready to rendezvous, it registers with the Rendezvous class and then blocks until the Rendezvous class releases it to run. Once the set of preconditions is met, then the registered tasks are released to run using whatever scheduling policy is currently in force.

Rendezvous Pattern

Collaboration Roles • Callback - holds the address of

the Client Thread. • Client Threads – when they

reach their synchronization point, they register with the Rendezvous object and pass their callback

• Rendezvous - manages the Thread Synchronization. It has a register(callback:address) operation that the Client Threads invoke to indicate that they have reached their synchronization point.

• Synch Policy - reifies the set of preconditions into a single concept

17

Memory Patterns

18

• The application of this pattern means that all objects are allocated during system initialization. Provided that the memory loading can be known at design time and the worst-case loading can be allocated entirely in memory, the system will take a bit longer to initialize, but it will operate well during execution.

Static Allocation PatternCollaboration Roles • Allocation Plan - identifies

the order in which the largest system composite objects should be allocated

• Composite Object – is responsible for the creation of all objects that it owns via composition

• Primitive Object - does not allocate any other objects

• Part Object - superclass of Composite Object and Primitive Object

• System Object - structurally the same as a Composite Object, except that it may own an Allocation Plan and creates and initializes the highest level Composite Objects

19

• In many applications clients may need to create data objects or message objects as the system operates in a complex, changing environment. In this case, it makes sense to have pools of these objects—created but not necessarily initialized and available upon request. Clients can request them as necessary and release them back to the pool when they're done with them.

Pool Allocation Pattern

Collaboration Roles • Client - object that has a need

to use one or more objects of class resourceClassClient

• Generic Pool Manager – parameterized (template) class specifies the class of the objects pooled and the number of them to create

• PooledClass - formal parameter to the Generic Pool Manager. Most often, they are simple, small classes used by a variety of clients.

• Resource Pool Manager - instantiated Generic Pool Manager, in which a specific class (ResourceClass) and a specific number of objects (size) are passed as actual parameters.

20

• Some systems are complex enough to require dynamic random allocation of memory but they cannot tolerate one of the major problems associated with dynamic allocation: fragmentation. For such systems, the Fixed Sized Buffer Pattern offers a viable solution: fragmentation-free dynamic memory allocation at the cost of some loss of memory usage optimality.

Fixed Sized Buffer Pattern

• Object Factory - allocates an appropriately sized block of memory from one of the Sized Heaps and maps the newly created object's data members into it

• Sized Heap - manages the free and allocated blocks from a single Memory Segment

Collaboration Roles • Client - the user of the objects

allocated from the fixed sized heaps

• Free Block List – list of the unallocated blocks of memory within a single Memory Segment

• Heap Manager - s manages the sized heaps

• Memory Segment - a block of memory divided into equal-sized blocks, which may be allocated or unallocated

21

Safety and Reliability Patterns

22

• Safety may be defined as freedom from accident or losses.• Reliability refers to the probability that a system will continue to

function for a specified period of time.• A safe system may fail frequently as long as it does not cause accidents,

while the reliability of a system does not refer at all to the consequences of failure if it should occur.

• Both require redundancy of some kind in the design of systems. • Faults come in two flavors: systematic and random.• Failsafe state - condition of existence known to be safe• Not all systems have a fail-safe state.• Reliable systems rely on system self-tests, either on power up (called Power

On Self Test, or POST) or during execution (called Built In Test, or BIT)

Safety and Reliability

23

Safety Versus Reliability

24

• For high-safety and reliability systems, it is common to provide redundant channels to enable the system to identify faults and to continue safe and reliable operation in the presence of faults.

• Homogeneous Redundancy Pattern • Triple Modular Redundancy Pattern • Heterogeneous Redundancy Pattern

Redundancy Patterns

25

Heterogeneous Redundancy Pattern Collaboration

Roles • (Primary or

Secondary) Actuation Validation

• (Primary or Secondary) Actuator

• (Primary or Secondary) Data Transformation

• (Primary or Secondary) Data Validation

• (Primary or Secondary) Input Processing

• (Primary or Secondary) Input Sensor

• (Primary or Secondary) Output Processing

• (Primary or Secondary) Actuation channel

26

Monitor-Actuator PatternCollaboration Roles • Actuation Channel• Actuation Data Source• Actuator • Actuator Monitor Sensor• Data Integrity Checks• Data Transformation• Monitor • Monitoring Channel• Monitoring Input Processing• Output Processing• Sensor Input Processing• Set Point Source

27

Sanity Check PatternCollaboration Roles • Actuation Channel• Actuation Data Source• Actuator • Actuator Monitor Sensor• Data Integrity Checks• Data Transformation• Monitor • Monitoring Input Channel• Output Processing• Sanity Check Channel• Sensor Input Processing• Set Point Source

28

Watchdog PatternCollaboration Roles • Actuation Channel• Actuation Data Source• Actuator • Data Transformation• Integrity Checks• Output Processing• Sensor Input Processing• Timebase• Watchdog

29

Questions and Answers

30

• Buschmann, F., R. Meunier, H. Rohnert, P. Sommerlad, and M. Stal. A System of Patterns: Pattern Oriented Software Architecture, New York: Wiley and Sons, 1996.

• Gamma, E., R. Helm, R. Johnson, and J. Vlissides. Design Patterns: Elements of Reusable Object Oriented Software, Reading, MA: Addison-Wesley, 1995.

• Douglass, Bruce Powel. Real-Time Design Patterns: Robust Scalable Architecture for Real-Time Systems, Addison-Wesley, 2002.

• Douglass, Bruce Powel. Real-Time UML, 2nd Edition: Developing Efficient Objects for Embedded Systems, Boston, MA: Addison-Wesley, 2000.

• Douglass, Bruce Powel. Doing Hard Time: Developing Real-Time Systems with UML, Objects, Frameworks and Patterns, Reading, MA: Addison-Wesley, 1999.

• Zalewski, Janusz. Real-Time Software Architecture and Design Patterns: Fundamental Concepts and Their Consequences. Annual Reviews in Control, Vol. 25, No. 1, pp. 133–146, July 2001.

• Vlissides, John. Pattern Hatching: Design Patterns Applied, Reading, MA: Addison-Wesley, 1998

References

31

Thank you

Oleh MedvedyevManager, Engineeringoleh.medvedyev@globallogic.com+380322448347x3504