1. Overview of the Methodology

Over the last few years OMG has actively promoted the use of models to design software through the Model Driven Architecture (MDA) initiative [OMG03] more recently evolved into Model-Driven Engineering (MDE). MDA models are characterized by both different semantic specialization and different levels of abstraction, from a higher to a lower level of abstraction closer to implementation and execution. In the MDA approach, first a platform-independent model (PIM) is developed, which describes the business and application logic, and then a series of transformations take place to map elements in the PIM to elements in a platform-specific model (PSM) which contains details that are specific to the target platform. Model transformation may be defined by rules and may thus be automated [OMG03]. (Cf. Figure 1.1.): in ASSERT and in the HRT-UML/RCM both features apply.

Figure 1.1: The MDA approach

ASSERT follows the MDA approach and so does the HRT-UML/RCM methodology. MDA models describe the system from different points of views, which are partial representations of the unique underlying model, from the perspective of a related set of user concerns, which are of consequence to the system development. HRT-UML/RCM decomposes the model into six views: three of them characterize the PIM and the other ones specify the PSM. The designer only specifies the three views which reside in the PIM space, whereas the PSM views are all automatically generated.

Figure 1.2: PIM

The PIM views are:

The Functional View
which specifies the functional services provided by system components and expresses their sequential behaviour in terms of state machines, classes and interfaces.
The Interface View
which characterizes the provided and required services of components and declares their intended concurrent behavior. In this view, a provided service can be specified to execute, for example, as a cyclic operation.
The Deployment View
which specifies the physical architecture of the system and the way in which software application(s) are to be deployed on it.

Figure 1.3: PSM

The PSM views are:

The Concurrency View
which specifies (in actual fact, calculates) the concurrent architecture of the system needed to implement the PIM specification of it; this view is designed to be compliant with the Ravenscar Computational Model by construction.
The Analysis View
which statically determines whether the current implementation of the system is able, under worst-case conditions, to meet all commitments as specified in the interfaces of the systems components.
The Code
which currently is realized as the Ada 2005 source code representation of the system implementation, destined for execution on an RCM Virtual Machine.

Figure 1.4: Methodology overview

Once the designer has specified the PIM views, fully automatic model transformations allow the user to move from PIM to PSM, and backwards. Within HRT-UML/RCM, the transformation from the Interface View (PIM) to the Concurrency View (PSM) is also known as vertical transformation to denote its taking the system down from PIM , under user control, to PSM, supported by automated rules. (A notable feature of HRT-UML/RCM is that the PSM view is placed outside the direct control of the user.) Off-line schedulability analysis may be performed on the system model (as well as any other form of static analysis of interest), whose results are propagated from the Analysis View (PSM) back to the Interface and Deployment View (PIM) through the round-trip engineering model-transformation. Finally, the Code View is generated from the Concurrency View.

The HRT-UML/RCM methodological approach exhibits the following properties:

  • Preservation of semantic consistency across views.
  • Fully automatic PIM to PSM model transformation, with no need for the designer to directly operate on the PSM.
  • Correctness by construction (CbyC) of the whole process.
  • Round-trip engineering, whereby values measured in the PSM space are promoted to match/update the corresponding values in the PIM space in order that the designer may determine whether the system specifications are met satisfactorily or changes are required.