Real-Time Object-Oriented Modeling

ObjecTime CASE tool simplifies real-time software development

Kevin, a senior software designer for Nortel Canada, can be contacted at [email protected].

ObjecTime is a CASE tool that supplies a powerful graphical modeling environment for the object-oriented design and simulation of event-driven real-time systems. Using a formal object-oriented design methodology, graphical models are entered into the ObjecTime toolset, and efficient real-time C/C++ source code is generated either for a Windows NT or UNIX-based simulation environment, or for a real-time operating system platform. Figure 1 illustrates an ObjecTime workspace, with several object models and state machines under construction.

We used the ObjecTime CASE tool to design and implement a real-time control and monitoring system for a fault-tolerant high-capacity telephony timeswitch. Our timeswitch is implemented on custom hardware running the VRTX real-time operating system. Our control system is responsible for the startup, shutdown, and self-test procedures of the device. In addition, the control system recognizes hardware faults, performs corrective actions (if possible), and reports fault details to third-party monitoring agents. The system can contain at most 28 individual circuit packs, each with its own CPU, to provide maximum fault tolerance. According to a user-supplied configuration, these 28 CPUs are grouped into various resource pools, with redundant CPUs in each pool, as illustrated in Figure 2. The system was developed using ObjecTime 4.4.1, running on both HP-UX and Sun UNIX workstations, with a Microtec PowerPC VRTX target platform.

Methodology

The ObjecTime toolset uses the Real-time Object-Oriented Modeling (ROOM) methodology. This methodology is similar to other popular OO modeling methodologies such as OMT, Booch, and UML. In fact, a future ObjecTime release will support UML-RT, an extension of the standard UML notation designed to address the challenges of real-time systems. Like most OO modeling methodologies, ROOM defines object models that express the compile-time relationships between objects, state diagrams to specify object behavior, and message sequence charts to illustrate the run-time interactions between objects. (For more information about ROOM, see Real-Time Object-Oriented Modeling, by Bran Selic, John Wiley & Sons, 1994.)

Prototyping

ObjecTime supplies a proprietary language, derived from Smalltalk, that supports the rapid prototyping of high-level design models. This proprietary language is called the Rapid Prototyping Language (RPL). Like Smalltalk, RPL is object oriented, typeless, and interpreted. RPL includes the standard Smalltalk-80 collection class library. Unlike Smalltalk, RPL relies on ALGOL-style control structures (such as for/next, do/while, and so on), which are more familiar to most real-time software designers. Example 1 illustrates the RPL syntax for performing a typical task in ObjecTime: sending a message to an object, and storing the response in a local variable. RPL data types are defined in a standard language-independent format, called Abstract Syntax Notation version 1. This format allows data types to be exchanged between RPL and C++ software. ObjecTime recommends that RPL be used in the requirements analysis and high-level design phases of a project, and C++ be used during detail design and implementation. In our project, we chose to begin with C++, since our staff was more familiar with C++, and our requirements and high-level design were relatively clear.

Services

Since the ObjecTime toolset supports real-time software development, the toolset includes services that meet common real-time software development requirements. The two most important services are run-time messaging and microsecond timing.

ObjecTime's Messaging Service allows user-defined signals to be sent between objects. These messages may or may not contain a single object instance as payload, and can be delivered either synchronously or asynchronously. Payload size is limited to four KB. Messages can be assigned a priority from one (low) to five (panic). The ObjecTime event model ensures that a single event is always processed without interruption. This approach avoids the design complexity of handling every possible interruption while an event is being processed. Events, by design, must be relatively short-lived operations; this approach is typical in real-time systems.

In ObjecTime, the caller specifies whether to use asynchronous or synchronous semantics; this allows the receiver's code to support both synchronous and asynchronous invocations without any additional effort. In our timeswitch project, this feature proved very useful.

ObjecTime's Timing Service allows user-defined timers, measured in microseconds, to be established. Whenever a timer fires, the object associated with that timer is notified, via a special timeout event, that the specified time period has expired. This is useful for implementing time-critical services. For example, our timeswitch control system contains as many as 28 CPUs; if an asynchronous request originating in one CPU, destined for another CPU, does not complete within a few microseconds, the target CPU equipment is tagged as faulty, and program control must be transferred quickly to a backup CPU.

Components

In ObjecTime, every object must have a clearly defined interface. These interfaces are specified by a list of incoming and outgoing signals. Since all interfaces have the same signal-based structure, objects can easily be reused in new designs without writing a lot of interface or translation code. This strong adherence to simple, generic interfaces sets ObjecTime apart from mainstream CASE tools, such as Rational Rose, which use primitive C++ mechanisms to model class interfaces. ObjecTime's component-based facilities improve encapsulation and reuse, both of which can reduce software complexity and increase software reliability. For our development project, these tightly controlled interface specifications proved invaluable, since our design and implementation work was divided among teams in four different countries.

External Classes

You can link existing C++ classes and libraries to ObjecTime models. For example, the Rogue Wave Tools classes were linked to our ObjecTime models to supply advanced data structures when ObjecTime's own internal language-independent data structures were not appropriate. Although this is a valuable feature, externally defined classes do not appear in ObjecTime's graphical models. This means that your models do not accurately reflect the construction of the system. In general, this is the greatest flaw in the ObjecTime toolset -- many important model relationships are not illustrated graphically.

State Machines

A custom variant of Harel State Charts is at the heart of ObjecTime's method. State machines are constructed for each class, with user-defined events triggering transitions between states. ObjecTime limits these events to signals generated by external objects or external services such as timers. Once your state machines are modeled, you may optionally associate regular C++ (or RPL) code with each state (for example, as entry or as exit actions), and with each transition. Transitions may have guard conditions, expressed in C++ or in RPL, which determine, at run time, if the transition is fired. Of course, regular functions and variables can be defined for state machines. Advanced state-modeling features such as nested states, group transitions, and transitions to history are all supported. Concurrency within state machines is not supported. Instead, each state machine executes in its own thread.

The most interesting feature of ROOM (and ObjecTime) is state-machine inheritance. This allows a subclass to inherit and to extend its parent's state machine. For example, a Device object might have three states: providing service, not providing service, and providing partial service, while an AccessDevice might have an additional state -- providing degraded service, as in Figures 5(a) and 5(b). States, transitions, functions, and variables are all inherited. State-machine inheritance encourages reuse, and ensures that specialized subclasses exhibit behavior similar to their parents. In our timeswitch project, we abstracted the circuit packs and processors within the timeswitch into a rich inheritance hierarchy (Figure 3); this allowed all of the basic control commands (such as start, stop, report fault) to be implemented in a single state machine that was extended to support processor-specific control commands.

Simulation

ObjecTime can compile and execute models on UNIX workstations using a number of popular C++ compilers, including GNU g++ 2.7.2, which was used on our project. This simulation mode allows real-time software to be executed under UNIX. ObjecTime supplies a graphical debug environment that allows state-machine behavior to be debugged. For example, you can inject a message into a state machine and watch a graphical animation of how the message is handled by your state machine. Figure 4 shows an ObjecTime state-machine debug session in progress. Alternatively, you can stress-test your model by simulating failures of different objects. We found that simulation of real-time systems is useful in real-world projects for many reasons:

• Scarcity of custom hardware (some custom hardware is not even manufactured until a few months before the software ships).
• Availability of UNIX software-development tools such as excellent source-level debuggers (such as GNU's mxgdb), memory debugging tools (such as Pure-Atria's Purify), and testing tools (such as McCabe's toolset).
• Many software developers are more comfortable with the UNIX programming environment than with more primitive real-time operating systems.

After a model has been tested and debugged under a UNIX-based simulation environment, further testing and debugging must be done on the target real-time operating system. This catches any software defects related to system-level timing issues. In our experience, most of the defects in a software system are discovered during simulation.

Target Execution

The ObjecTime Run Time System (RTS) provides a virtual machine that allows ROOM models to execute on a number of Real-Time Operating Systems (RTOS), such as WindRiver Systems' VxWorks, Integrated Systems' pSOS, and Microtec's VRTX. Compiling a model on a target platform is relatively simple, since the same source code that executes in UNIX simulation can be compiled for a RTOS running the ObjecTime Virtual Machine. This is possible since ObjecTime generates C/C++ code, and supplies run-time libraries and virtual machines for a variety of RTOS.

Other Features

ObjecTime supports the usual array of popular CASE tool features, which include (among many others):

• Integration with source-code control systems such as ClearCase, SCCS, or RCS. We employed RCS and ClearCase in our development project.
• Capture and management of software requirements, and traceability of these requirements to design model elements.
• Simple documentation-generation capabilities (FrameBuilder or PostScript). In ObjecTime, these features are limited, so we constructed our own Perl-based tools to extract design information from our models, and to create FrameBuilder documents.

These features are similar to those provided by most commercial CASE tools. Clearly, ObjecTime's most distinguishing feature is its ability to immediately execute object models in simulation mode by automatically generating C++ code from object models.

Weaknesses

ObjecTime suffers from a number of weaknesses or disadvantages; some of these disadvantages are common to most CASE tools, while others are unique to ObjecTime.

Some designers experience a long learning curve with ObjecTime. This learning curve is dramatically shortened if you have substantial object-oriented CASE tool experience.

ObjecTime can limit many of your design choices; for example, ObjecTime forbids multiple inheritance even though the C++ language supports it. Of course, you can link-in external C++ classes that use multiple inheritance, since these classes are not visible within the ObjecTime modeling environment.

The ROOM notation is adequate for most tasks, but documenting a design in ROOM is a challenge since many key model relationships are not expressed graphically. For example, ROOM does not display inheritance trees graphically. Certain relationships between objects are also not shown graphically.

When compiling a software system, you must divide your classes into compilation units, called packages, which are compiled independently. This works well, except that you can't nest packages, so you end up scrolling through hundreds of packages searching for the ones you want.

Integrating ObjecTime applications with other third-party tools is challenging. For example, CORBA event loops must be integrated with ObjecTime's event loops; in current versions of ObjecTime this process is not simple. ObjecTime plans to offer native CORBA support in a future release.

Conclusion

The ObjecTime toolset includes a powerful object-oriented modeling tool with a very advanced code-generation engine. The ROOM methodology encourages good software engineering practices such as encapsulation and reuse. ObjecTime's real-time focus provided the tools that we needed to quickly design and develop our software, with acceptable memory and CPU requirements on the target platform. The NT or UNIX-based simulation environment allowed us to design and test our software before our custom hardware was manufactured. If you enjoy formal, object-oriented modeling, and don't mind living inside the sometimes-arbitrary constraints of a CASE tool, then the ObjecTime toolset is worth investigating.

For More Information

ObjecTime Limited
340 March Road
Kanata, ON
Canada K2K 2E4
613-591-3535
http://www.objectime.com/

References

Booch, G. Object-Oriented Analysis and Design with Applications. (Benjamin Cummings, 1994).

Rumbaugh, J., M. Blaha, W. Remerlani, F. Eddy, and W. Lorensen. Object-Oriented Modeling and Design. (Prentice-Hall, 1991).

Selic, B., G. Gullekson, and P. Ward. Real-Time Object-Oriented Modeling. (John Wiley & Sons, 1994).

ObjecTime web site, http://www.objectime.com/.

Rational web site, http://www.rational.com/.

DDJ