Using Patterns to Implement Real-Time Behavior in a UML Specification

This article looks at some of the abstractions in a new profile of UML, the RT-Profile, which particularly affects software design for real-time use. Included in the paper are a set of patterns that designers can use to evolve a design model, expressed using these abstractions, into an implementation model suitable for implementation in C++, using a class from an example system to illustrate the evolution.

The article first introduces and describes the relevant abstractions. Most of the rest of the article is then dedicated to describing the patterns in more detail, and to showing the effect of their application on a selected class in an example system.

The RT Profile of UML features a number of abstractions of run-time concepts that need to be understood before any implementation is essayed. This section of the paper provides a brief description of the meaning of the various abstractions. The following class features are addressed:

• Deferred Operations—from the RT Profile "A kind of service instance that is deferred until the receiving object is willing to receive it explicitly." Deferred operations have no analog in C++ and have to be implemented using queuing mechanisms.
  
  
• Exclusive Operations—from the RT Profile "A... service instance associated with a protected resource that can only be accessed if the appropriate resource broker approves." Guarded operations have no analog in C++ and have to be implemented using brokering mechanisms such as mutual exclusion primitives.
  
  
• Concurrency—from the RT Profile "A kind of ...instance that is capable of executing a single scenario concurrently with other concurrent units. This scenario corresponds to the so-called 'main' method associated with the ... type." The C++ language does not feature the concept of concurrency, and so this implementation will depend on the underlying target environment.
  
  
• Timeouts—from the RT Profile "A kind of timed stimulus generated by a running timer."

Recent work on the semantics of UML actions has moved UML towards a more consistent scheme for describing events and operations; the RT Profile builds on this scheme. This provides a more consistent and orthogonal set of concepts for discussion.

Operation Reception
Irrespective of the type of operation, it can be characterized by whether the object deals with occurrences of the event as they are raised (immediately), or adds them to a set of "to be handled" occurrences and deals with them later (deferred).

Call Actions
The other characteristic that needs to be taken into account is whether an operation (which results in a call event) is invoked synchronously or asynchronously by the caller. During a synchronous invocation, the caller will wait for a response, whereas in an asynchronous invocation, the caller continues immediately.

This article provides solutions for the Operation Reception side, although you can extend the patterns to deal with the different calling mechanisms.

The implementation presented here consists of a framework with a set of implemented patterns, providing support for the UML design abstractions previously described. Patterns first came to prominence through; they describe a particular configuration of classes that can be used to provide some required behavior. This concept is a powerful vehicle for describing the type of transformations required to move from a design model to a C++ implementation model, and is well aligned with the notion of MDA. In this article, pattern implementations are represented as parameterized packages where the formal parameters provide a mechanism for plugging in a local context to a general solution.

The application of the various patterns is shown using an example, the Waste Control System. The following description is part of its requirements statement:

"The plant handles containers of toxic waste, which are fed into a processing plant along a conveyor belt. Once detected and identified by an attached bar code, a container is scanned for faults before routing. If a container is badly damaged, then it is routed off the belt by a robot arm for special handling. If not badly damaged, then it reaches the end of the belt where it is caged and sent off for normal processing. The status of the containers and plant equipment is reported via a remote operator's console. The plant is normally controlled through the operator's console, although manual override buttons are available."

Figure 1 shows an artist's impression of the system.

Figure 1:  Artist's impression of the waste system

This article uses a class from the plant-control domain of the example system and follows it through the application of patterns that refine the original design abstractions with additional implementation constructs that are much closer to C++ semantics. The actual transformation of this resulting model into C++ is not covered in this paper; most UML modeling tools will perform this transformation automatically.

Figure 2 shows the classes that constitute the control system for the plant. There are several types of equipment, modeled by specialization of 'cEquipment'. The 'cBelt' class (on which this article focuses) tracks containers on the belt and alerts equipment to a container's approach. The 'cBelt' class is in many ways the center of the system.

This article will look at how to take the UML abstraction of this class and, by applying a set of patterns, produce C++-like constructs that implement it according to its design. The implementation is explored in two sections: implementation of operations, and implementation of concurrency.

As discussed earlier, operations may have different real-time characteristics and an engineer may need to apply a number of patterns to the 'cBelt' class in order to provide a complete implementation. The three patterns described in this section deal with deferred operations, timed operations, and exclusive operations.

Figure 3 shows the operations defined on 'cBelt' and the callers of those operations.

Figure 3:  cBelt and its Clients

Queuing Proxy Pattern
In order to handle the deferred operations, an object needs additional functionality. Figure 4 shows a pattern that can be used to add an incoming event queue and a dispatcher that will de-queue and initiate the handling of deferred operations; the pattern is based on the Active Object pattern in Schmidt et al.

Figure 4:  The queuing proxy pattern

The two basic procedures embodied in this pattern are:

• The 'eventProxy' method, which queues asynchronously received events using 'put' on 'Queue'.
  
  
• The 'dispatch' method which, when called, will de-queue (using 'get' on 'Queue') an event and invoke its 'call' method, which, in turn, will call the 'eventHandler' in the 'EventReceiver'.

Table 1 describes the combinations of sender and receiver that the pattern will handle:

		SENDER
		Synchronous	Asynchronous
R E C E I V E R	Synchronous	The asynchronous event handler passes this combination, which is analogous to a procedure call, through for the original client ('EventReceiver') to handle.	The pattern does not support this, which normally requires a separate thread to be created to handle the event while the sender continues.
	Asynchronous	The pattern doesn't handle this, but could be extended so that the sender waits on an event flag until the receiver has de-queued and handled the event.	The sender continues while the receiver queues the event.

Table 1:  Asynchronous event handler pattern capabilities

Timed Operations
Timed operations need to be handled using a timer; Figure 5 describes a candidate timer pattern. The important features of the pattern are:

• A subclass of 'TimedEvent' (the class '') is provided for each type of time event
  
  
• Each 'TimedEvent' creates a 'Timer' and passes it a reference to itself (as a 'TimerTarget')
  
  
• When the 'Timer' ticks, it calls the 'Timeout' function which, in turn, invokes the appropriate event handler on the ', where '' is the class with the timed event.

Figure 5:  Timed event pattern

Exclusive Operation Handling
If an operation is marked as 'exclusive', then the handling of the resulting event will need some form of mutual exclusion to ensure the correct semantics. The most obvious implementation of this is to provide a 'Mutex' (or semaphore) that is locked by the operation (which waits if necessary) before proceeding, and then is unlocked by the operation once it has finished.

Implementation of cBelt Operations
In order to apply the patterns described above, the engineer needs to characterize the behavior of the set of incoming events. This can be done using the stereotypes in the RT Profile.

Figure 6:  cBelt class with appropriate characterizations

The 'Queued Operation' pattern will need to provide proxies for all operations marked as «CRdeferred».

The timer pattern will need to be applied for each operation marked with the «RTtimeout» stereotype- in this case there is only one: 'BeltStopTime'. If a timed operation is asynchronous, then the combination of both timer and asynchronous event handler patterns will work together, albeit somewhat redundantly, to queue the timed event as it is received.

A mutex needs to be added to support those operations that need to be handled exclusively («GRMexclusive»).

There are a number of abstractions that apply to the whole class, and hence to the objects of that class—one of the most significant is concurrency.

Concurrency
In order to implement an active class (in other words, one that will create active objects) you need a new pattern, shown in Figure 7.

Figure 7:  The concurrent object pattern

This simple pattern merely provides an abstract main method that will execute on a separate thread, which needs to be overridden in a concrete subclass. When this is applied along with the Queuing Proxy pattern, the normal expectation is that the main method of the 'Active Object', in this case the Proxy class, will repeatedly call its 'dispatch' operation in order to consume the object's event queue. Figure 8 shows this scenario.

Figure 8:  The main thread for a combination of active object and event handler

If the Concurrent Object pattern is used on its own, then the designer will write their own main method to perform whatever activity they have in mind for the active component of the object. This might include polling devices, waiting on event flags, or some other processing which does not fit one of the standard UML abstractions.

Figure 9 describes the complete class model surrounding 'cBelt' once all the patterns have been applied. You can see that there is an impressive amount of additional functionality required for implementing a UML class with a rich set of characteristics.

Note that the implementation model here assumes that new classes are introduced to handle activeness, asynchronous inputs, and so on. It is possible to add all the functionality to the (in this case) 'cBelt' class, which will simplify the model somewhat (and potentially result in less code) at the expense of adding a large number of attributes and operations to 'cBelt' itself. Supporting the latter approach to applying a pattern is likely to be fraught without automated support, particularly when it comes to maintenance.

This article has described the semantics of some design abstractions introduced into the RT Profile of UML, and discussed a set of patterns that you can apply to implement an annotated UML class in C++. You can see in the "full" model for 'cBelt' that the design abstractions can result in a significant addition of functionality to the final application. An understanding of the implications of using these abstractions is therefore important background knowledge when creating a design using UML.