Date post: | 16-Apr-2017 |
Category: |
Engineering |
Upload: | globallogic-ukraine |
View: | 108 times |
Download: | 1 times |
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