During the early 1990s, many individuals and organizations experimented with object-oriented concepts, notations, methods, and languages. This created a wide and varied proliferation of techniques used to build applications with this new technology. The "method wars" looked like they might stall the adoption of these improved engineering practices through simple confusion. In an effort to consolidate the industry, a number of key methodologists (Grady Booch, James Rumbaugh and Ivar Jacobson) got together to form a coalition to produce a Unified Method. Over the course of the past couple of years, others joined in this effort including the Object Management Group (OMG) and we now have an industry standard Unified Modeling Language (UML), writes Alan Moore.

With the industry adoption of the UML, developers using object-oriented approaches now have a common, high-level modeling notation for defining and designing their systems. This is the good news. The not-so-good news is that UML is insufficient in certain areas critical to the proper development of real-time, embedded systems. Specifically, timing, concurrency, and hardware/software interfaces are critical to the correct development of a real-time embedded system. This article will briefly explore a few of the real-time design extensions to UML that are available from ARTiSAN Software Tools' Real-time Studio.

Example of a Real-time System, an Asynchronous Modem
To illustrate our proposed extensions, we will use as an example an asynchronous external modem. A modem was chosen due to its widespread use and familiarity, as well as being a good representative of both a real-time and an embedded system. A typical modem consists of a single or multiple processors, along with a number of other subsystems.

System Architecture Representation
To ensure that the application meets functional requirements and can be deployed into the proper environment, the developer must have a thorough understanding and representation of the software/hardware interfaces and the system boundaries. A deployment diagram is included in the UML for capturing this kind of representation. However, due to the complexities of designing embedded systems, the physical architecture incorporates more than just simple placement of software on connected nodes. The real-time studio system architecture diagram shown in Figure 1 depicts the software/hardware interface in far more detail. Using this diagram, the system's architecture is defined using a simple set of building blocks, supporting the system and hardware engineer's view of the solution. The system architecture is made up of processing nodes (or boards), storage nodes (or disks), interface devices, connections (both point-to-point and multi-drop), and aggregations of the previous items, called subsystems.

Figure 1 shows the system architecture of our modem, consisting of a controller and a DSP connected to each via a local bus, and to other devices using point-to-point connections. The specific implementation characteristics of these components such as memory size, location, speed, bandwidth, and quantity are also modeled in the System Architecture view.

Figure 1. System Architecture.

Multi-Tasking Systems
Typically, embedded systems are multi-tasking solutions to real-world problems. They primarily focus on the interface and control of multiple external devices. The multiple parts of this real-time system usually run at varying priorities and with varying run-time characteristics. It is common for multiple tasks or threads to be simultaneously active in the system. Many real-time systems are deployed on a set of microprocessors in a distributed architecture.

A system level task design that captures the system details is required to model the architecture for the multiple threads of execution that are supported in the application. It is also important to model task interaction allowing data access, throughput, and synchronization issues to be easily understood. Representing this view of the solution is difficult using the standard UML, and so ARTiSAN Software Tool's extensions are badly needed by designing a real-time, multi-tasking system.

Concurrency Diagram
ARTiSAN's concurrency diagram is an extension to UML that assists in dealing with the multi-tasking design for a real-time system. The concurrency diagram depicts several useful aspects of the system. First, by limiting this specialized view to the multi-tasking issues, we can model the overall task structure of the solution as well as the communication mechanisms between tasks. This view of the system is essential when we come to map the logical object architecture into a multi-tasking solution. Secondly we can help specify the inter-task communications (currently not supported by the UML). The run-time environment usually handles these either by constructing communication objects in the application (e.g., semaphores and queues) or by using primitives in the underlying executive. In either case, by modeling the actual interaction in a concurrency diagram, the subsequent elaboration of these artifacts is straightforward. In Figure 2, the concurrency diagram shows the tasks identified for our modem inside the modem controller card. These include AT commands, Data Compression and Error Manager tasks. They communicate using various mechanisms such as queues, signals and semaphores.

Figure 2. Concurreny Diagram.

Dealing With Time
A real-time system is, by definition, a system limited by some aspect of time. The right answer late is often wrong. Timing considerations are often one of the primary requirements that drive system development. Therefore, it is critical to capture this timing information while modeling the system. In an object-oriented solution, there are a number of objects collaborating by sending messages to each other. There are two main categories of timing information that can be modeled; latency and duration. The amount of time it takes for two objects to collaborate (i.e., communicate) can be described as the message latency. The amount of time required for an object to perform its task once it has received a message is described as the operation duration. Through a combination of latency and duration specifications, we identify general timing constraints for a set of operations. These constraints map back on to specific Use Cases and the original requirements.

Sequence Diagram
The sequence diagram captures timing information while modeling the system. The timing requirements associated with a particular Use Case or Scenario are mapped through the sequence diagram on to specific messages and operations on the classes that define the objects. The UML allows notes to be added to any diagram. However, by making timing information an attribute of the representations on the sequence diagram, the timing notes are mapped directly on to the appropriate events and object operations. The message information is then usable in other views of the system (e.g., class design).

In our example, it would take the "AT\N5" command about 608 microseconds at 115200 bits-per-second (BPS) to travel from the terminal to the AT command processor. Also, once the message arrives at its destination, it may take the AT command processor 200 milliseconds to process the request. Both these can be specified by the systems engineer and then added on to the OSD. Furthermore, the vertical axis on the on the diagram can be viewed as the time axis, with time moving from top to bottom.

Therefore, we can also show the round-trip time for replying to an AT command, a combination of many operations, as a vertical line of <1-second duration.

Conclusion
Given the popularity and notational robustness of the current version of UML, real-time developers can reasonably begin exploiting OO technology in their design efforts. However, it is important to realize that certain characteristics of real-time systems may be difficult, if not impossible, to capture in most modeling tools available today. ARTiSAN Real-time Studio from ARTiSAN Software Tools is a multi-user suite of development tools that delivers the power of object technology specifically for real-time systems. While providing excellent support for UML-based modeling, Real-time Studio adds specific capabilities for designing real-time, embedded systems. In addition to the core UML modeling diagrams (e.g. Use Case, Sequence, Class, Collaboration, and State), Real-time Studio provides the following real-time extensions:

explicit modeling of the physical architecture of the embedded system in the system architecture diagram
explicit modeling of system level concurrent task design in the concurrency diagram
explicit timing information captured in sequence diagrams for message latency and operation duration>

There are so many unique development requirements that come into play when designing embedded or real-time systems that it makes sense that real-time designers require additional UML notations. The UML extensions for real-time systems described in this article allow real-time designers to reap the benefits of OO technology today.