Real Time UML: Advances in the UML for Real-Time Systems (3rd Edition)

A model is an integrated set of abstractions and their internal relations. Models are expressed in a modeling language that consists of two parts: a set of abstract elements (called metaclasses), which is a syntax for representing and viewing these elements and their relations, and a semantic framework that specifies the precise meaning of these abstract elements.

A model may support any number of different views. A UML class diagram may show a number of classes interacting together to realize a use case, for example. Another class diagram may show the same class in a generalization taxonomy. Still another class diagram may show how the class fits within its domain of interest. The behavioral constraints of a class may be represented as a statechart that shows how it responds to different events in different circumstances. Source code representing the implementation of the class can be viewed as text.

None of these views is, by itself, the model. Each is a narrow, restricted view of the model, using a particular graphical syntax to represent a particular point of view. The model is, in fact, the logical conjugation of the information shown in all views of the model. A class diagram is no more (or less) a model of a system than the source code. Both are important views of the model that concentrate on different aspects. This distinction between model and view is very important, as it turns out, in system development and maintenance, as we shall explore.

An executable model is a model that is defined with a rich enough set of semantics that its execution behavior is predictable. One can argue that any model that can be represented ultimately as executable machine code is, in fact, an executable model. At least two distinct views of an executable model must be constructed. The first is the structural view. What is the information manipulated by the model and how is it logically represented? What are the relationships among these structural elements? In the UML, for example, the structural view is represented by class diagrams (for logical elements) and object, deployment, and component diagrams (for physical elements). Secondly, what are the operations permitted to be done on that information and what constraints apply to the execution of those operations? The UML provides sequence, communication, and timing diagrams to show how model elements collaborate together and statecharts and activity diagrams to show how the behavior individually. Given these two views of a model, it is possible, in every important sense, to execute the model.

MDA is an approach that separates aspects of a model that are independent of underlying technologies from those that are dependent upon those aspects. The platform-independent model (PIM) is constructed to be independent of the processor(s) on which it runs, the communication infrastructure (such as Ethernet and TCP/IP), middleware (such as COM or CORBA), and even the implementation language (such as C or Ada). From the PIM, the platform-specific model (PSM) is constructed, either by translation or by elaboration (although the literature focuses primarily on the former). The PSM incorporates these aspects of the physical realization of the system. Of course, this can be done in stages, resulting in a succession of increasingly detailed PSMs until all the physical details of the system have been completely specified. Figure 1-10 shows this process schematically.

What does this mean in practice? Different tools support MDA to different degrees. Most tools are completely nonconstructive and nongenerative, and do not execute in any way. In such tools, the user must maintain two different models, performing the translation from the PIM to the PSM manually. Constructive tools handle more or less of this translation for you. Figure 1-11 shows how the Rhapsody^® tool from I-Logix approaches MDA.

The Rhapsody tool can be thought of as consisting of several parts. The most visible to the user are the graphic editors used to perform model entry and manipulation and the report generator. Behind the scenes, however, there is an elaborate system that compiles your model and can control and monitor the execution of the model. The model compiler takes the model semantics entered by the user via the diagrams and compiles it into source code that can be fed into a standard compiler for language such as C, C++, Java, and Ada. The model-code association component maintains the model and the code "in sync," whether the user modifies the model or the source code directly, eliminating the very pervasive problem of what to do when the model and the code disagree.

The model execution aspects of Rhapsody allow you to insert events, set breakpoints, and step and run the application. The model monitoring aspects of the tool allows the user to see the execution of the system at the model level that is, see sequence diagrams drawn dynamically as the system runs, view the execution of the state machines and activity diagrams of the various objects of the system, examine the attributes, and so on. These tools allow the user to control and monitor the application execution on the user's desktop or on the actual target hardware. The Rhapsody Test Conductor^® is a scenario-based test environment built on top of that debugging infrastructure that constructs (and applies) test vectors from the requirements scenarios. Of course, all of this uses the underlying model semantics stored in the model repository.

The compiler and linker work together to compile the output of the model compiler and compile in legacy source-code components. Precompiled components, such as third-party libraries, are linked in with the compiled application to create the PSM. The PSM consists of the PIM with bindings (links) into platform-specific aspects, including the PIM, the platform-independent framework (PIF), and the RTOS Adaptor, and any linked components. This PSM sits on top of any middleware, such as COM or CORBA, the RTOS, and, of course, the target hardware.