Using UML in the Development of Object-Oriented Real-Time Systems

This article examines the relevance of the Unified Modeling Language (UML) to the development of object-oriented (OO) real-time systems. The basic structure of this article is similar to A UML Primer in that it considers development life-cycle activities of requirements definition and design. However, whereas the primer described the basic notation of UML, this article discusses how developers can apply UML in the real-time domain. A UML Primer emphasizes some key points

• UML is a language, not a process
  UML simply provides a notational and semantic framework to capture, explore, and document aspects of OO software development. To maximize the benefit of using UML, you should apply the language within the context of a development process in which the concept of iterative, elaborative development is prominent.
  
  
• UML covers both requirements and design
  UML provides mechanisms for describing requirements and OO solutions to those requirements. The language also, through Use Cases, facilitates the move from requirements into design providing some degree of traceability between the two.

This article will reiterate these two points as we seek to illustrate how to use UML in the development of an OO real-time system. As well as showing where UML can be of benefit, we will also identify those aspects of system development, specific to real-time systems, that UML does not support very well.

Many designers start with the actors—external entities for which the system provides functionality, and that often provide the stimulus to trigger that functionality. For real-time systems, the search for the source of events in the system's environment can yield the actors and the stimuli the actors may provide. In addition, the source of events may also provide an indication of the resulting sequences of activity that specifies the primary use cases for the system.

What UML does not explicitly identify is some form of context diagram. Such a diagram can provide very useful information for developers, both at this point in system development and later in the design stage. The Context Diagram in Figure 1 uses the processing-container example application described in A UML Primer.

This diagram is constructed from system-architecture information and shows the physical subsystems and devices through which the actors interact with the system. The context diagram also shows the events, in the form of signals from and to those devices, that the system needs to detect and transmit. This diagram provides the vocabulary for the sequence of I/O activity that constitutes an initial use-case description. For example, the Operator pressing a button to generate a 'system_start' signal initiates the Start Up Plant use case. This event causes the Plant Control System to send the set of 'self_test' signals to the various devices and handle the subsequent reporting of test results via the Lamps on the Front Panel. You can represent his initial description by a sequence diagram. However, instead of showing software, the 'objects' represent the devices shown on the context diagram and the messages represent the signals passing between the control system and these devices. You can easily annotate this type of diagram with information to specify timing constraints.

We thus describe the I/O activity for the primary use cases that we can see resulting from a consideration of actor stimuli. It then becomes easier to identify extensions to the main use cases to handle exception conditions (modeled by the «extend» relationship). Following this task, the common 'Context Diagram' vocabulary facilitates the identification and modeling (using the «include» relationship) of activity sequences common to more than one use case.

One final aspect of requirements modeling that can be helpful is to use a UML state chart to describe the operational modes of the control system. This is similar to a conventional system state diagram, except that it serves primarily to relate the events shown on the context diagram to the primary use cases on the use-case diagram, rather than showing the details of system activity. An example modes diagram for the container processing system is shown in Figure 2.

Figure 2:  System-Modes Diagram for the container-processing system

The initial development of object interaction diagrams (sequence diagrams and collaboration diagrams) provides much of the information required to develop an initial class diagram. Messages received by an object require you to define corresponding operations in the object's class. Parameters or return data involved in the message imply a requirement for attributes; interaction between two objects implies some form of relationship between their classes. A UML Primer covered much of the notation and semantics of object interaction and class modeling, which will not be repeated here.

As more use cases are examined, and more information about objects and their relationships is uncovered, this information is added to the class diagram. It is important to stress at this point the iterative and elaborative nature of such activity. Design with UML is not a linear sequence of activities, where each activity has to be completed in order to feed into its successor. Instead, UML is an approach that uses a set of related diagrams to uncover greater detail of the required design and to update the diagrams accordingly. This is well illustrated in the use of state diagrams, which may be produced initially with little more than textual descriptions of the behavior of their parent class. As the design evolves, and particularly where the intention is to generate code from the designs, we may see these state diagrams use a more formalized language to describe class behavior (Figure 3). One other important aspect of the use of UML modeling for object design is consistency.

Figure 3:  Consistency between diagrams is shown with these fragments of three different diagrams: class diagram, an object sequence diagram for the 'Shut Down System' use case, and a state diagram for the cPCS class

From the sequence diagram in Figure 3, we see that the use case starts with the arrival of the 'systemStop' message at the cPCS object and continues with the subsequent sending of the 'setMode' and 'stopBelt' messages to the cPanelDriver and cBelt objects. We see this activity again as part of the behavior of the cPCS class (there is only one object instance for this class). The transition coming into the 'Shutting_Down' state is triggered by the receipt of the 'systemStop' message—the cPCS subsequently sends the 'setMode' and 'stopBelt' to named instances of the cPanelDriver and cBelt classes. These instance names ('thePanelDriver', 'theBelt') are the role names from the associations between cPCS and the other two classes you can see on the class diagram. You also see the operations shown on the sequence and state diagrams ('systemStop', 'setMode', 'stopBelt', 'isStarted') as public operations in the class interfaces on the class diagram.

The UML concept of providing differing views of the object design, with a centralized data dictionary, facilitates this type of modeling consistency.

Implementation Design
In a single-threaded application, producing a detailed object design similar to that illustrated by Figure 3, may be all you need before code generation or production can begin. In many real-time systems, however, the application needs to be multi-threaded (we will use the term 'task' rather than 'thread', defining a task as a sequential thread of execution). For the designers of such systems, an object design alone is not enough. Identifying an appropriate set of tasks, handling their synchronization and communication, and protecting resources shared between the tasks, are major design issues.

UML recognizes the concept of a thread and defines an 'active' object as an object that "owns a thread of control and may initiate control activity," but there are no diagrams specifically for modeling tasks and task interaction. What can be done is to use the collaboration diagram, and to model each task as an active object. To model task interaction via an RTOS, it is best to use a library of RTOS classes, together with their relevant operations and attributes. This library would contain, for example, a message-queue class, with operations that would allow data to be written into the queue and read from it. Such a library may already be provided by your RTOS. If not, you can construct a library where the classes act as 'wrappers' to the RTOS function calls. You can then model RTOS calls from task code as messages from the active (task) object to an appropriate RTOS class instance. Although UML recognizes the need to indicate that such messages may be blocked or time-out, it states that such requirements are extensions to the core UML. Because the use of an RTOS is such a significant feature of real-time systems, it can be very useful to indicate this behavior using special stereotypes. Figure 4 is a stereotyped collaboration diagram, which shows an iconic representation of some useful RTOS stereotypes.

Figure 4:  A stereotyped collaboration diagram of the container-processing system shows the interaction between various parts of the system

Modeling task interaction has an additional benefit for any real-time system where timing constraints form part of the systems' non-functional requirements. It is possible to construct a sequence diagram for all, or part, of the use case where the timing constraint applies, and to annotate the diagram (Figure 5) with actual or worst-case timing data.

You can analyze this timing data to provide an early indication of possible timing problems either manually or automatically with a modeling tool.

In a multi-processor system, you may want to indicate which tasks are to run on which processor. To model this in UML you would have to use a deployment diagram. A deployment diagram is a simple diagram that shows processing 'Nodes' (represented by 3D boxes) and 'Components' (represented by rectangles with two smaller rectangles protruding from their sides) that reside on the Nodes. As discussed in A UML Primer, it is in this area of implementation modeling that UML is at its weakest, and where the language most strongly reveals its essentially business-oriented background. It is almost impossible, using UML deployment diagrams, to adequately model the level of architectural detail required by software engineers for many real-time systems. The specification of board-level interfacing, memory map, port addresses, or interrupt data (Figure 6) requires a modeling capability that is not present in current UML.

Figure 6:  The inadequacy of UML diagrams for modeling system architectural detail points out the need for a board-level I/O diagram to specify interfacing, memory mapping, port addressing, and interrupt data

The application of UML to the development of OO real-time systems can be very beneficial in many areas. Some of the benefits of using a UML for OO development include a clearer understanding of system requirements; a straightforward transition from requirements into design activity; and consistency, through different diagram views, for the object design. However, there are deficiencies in UML for many real-time, embedded systems. Among these deficiencies are limited support for task interaction modeling, and that it is almost impossible to do detailed system-architecture modeling using only UML. An important requirement for the successful use of UML is an approach, within and between life-cycle stages, that encourages iterative and elaborative development, rather than a set of sequential activities.

UML is a dynamic entity. Under the auspices of the Object Management Group (OMG), the language is continuously undergoing development and change. The good news for the real-time community is that within the OMG, the Real-time Analysis and Design group is formulating some much-needed real-time extensions. We should see at least some of the outcome of work in the near future.

About the Author Alan Moore is the Vice President for Product Strategy at Artisan Software. Alan has 15 years of experience in the development of real-time and object-oriented methodologies and their applications in a variety of problem domains. He has been actively involved in product development, training, and consulting related to OOAD and structured development tools during that time. Alan has co-authored a book on GUI design, published several papers, and has lectured on a wide variety of analysis and design issues. Alan is responsible for the specification, planning, and management of the ARTiSAN product strategy. He is the author of ARTiSAN "Real-time Perspective," a pragmatic approach to the development of real-time systems, and is an active participant in the Real-time Analysis and Design Group (RTAD) of the Object Management Group (OMG).