Using model-driven development for agile embedded apps:Part 2 – Key concepts of MDA
As discussed in Part 1 in this series, models play an important role in agile programming because they provide the ability to view different aspects of a system (e.g., functional, structural, behavioral, and interactive) and examine those aspects at different levels of abstraction (e.g., system, subsystem, component, task, primitive element).
MDA, a specific set of standards within the OMG, defines a means for organizing models that provides benefits of reusability and maintainability for complex systems composed of heterogeneous technology. The CIM defines the requirements model, which focuses on stakeholder needs. The PIM focuses on the essential aspects of the system that must be present. The PSM maps the PIM to a target platform by including a set of technologies and design patterns. The PSI is the code generated from the PSM. Model translation enables developers to move quickly and confidently from one model to the next.
OMG's Definition of Model
The OMG defines the term model to be “a description or specification of that system and its environment for some purpose.” The salient aspects of a model are the following:
- A model is a simplification of the thing that it models
- A model has a purpose or intent
- The model focuses on the aspects relevant to its purpose
That is, it is common to have different models of the same thing for different purposes. MDA uses this concept to implement a well-established idea—the separation of the essential aspects of the thing from how those aspects are implemented.
MDA defines four uses for models in its context (see Figure 2.1). The
computation-independent model (CIM) doesn’t show the pieces within a
system that perform the necessary computation but instead focuses on the
required
functionality of the system. The platform-independent model
(PIM) focuses on the essential parts of the system and their essential
behavior but does not focus on platform-specific details such as the operating
system, CPU, or distribution infrastructure. The platform-specific model
(PSM) includes the elided platform information and represents the
system targeted to a specific execution environment. The
platform-specific implementation (PSI) is the source code of
the PSM and may be generated from the PSM automatically. Of these key models,
the PIM and the PSM get most of the attention because it is there that automated
transformations provide the most benefit.
Figure 2.1 Key models in MDA
Models are usually represented in the UML, but other modeling languages can be used instead of, or in conjunction with, the UML model. For example, safety analysis is often performed using FTA or FMEA. These languages can be used along with UML models to supply useful views not available within the UML.
A minimalist UML model consists of three types of elements: classes (and their features and relations), state machines for some of the classes, and typical and exceptional interactions of instances of those classes, usually shown on sequence diagrams. In addition to these basic elements, a great deal more can be added, such as use cases, activity models, requirements and their relations, and so on.
It should be noted that the model content is held in the model repository and is exposed in diagrams. The diagrams are not the model but are really just useful views into the model repository. Thinking that the diagrams are the primary aspect is a mistake many new to UML make. It’s not about the diagrams; it’s about what’s on the diagrams!
The models are created in sequence through a process known as model transformation. Figure 2.2 shows a typical set of models. The TrackingUseCase-Model represents the functionality and QoS requirements for a tracking system. It is given the stereotype «CIM» to indicate the type of model it is. The use case model contains traceability links from textual requirements to the model’s use cases, interactions, and state machines (and associated diagrams). This CIM is transformed into an analysis model that represents the computational model that realizes the requirements.
Figure 2.2 Model transformations
The TrackingAnalysisModel has the stereotype «PIM» to indicate that it is a
platform-independent model. The PIM contains essential structural elements
(classes, types, and relations), interactions, algorithms, and state machines to
realize the computations necessary to perform the tracking requirements. It
does not include the platform-specific details such as the CPU, operating
system, middleware, network structure, or even the specific sensor platforms
used.
Normally, there is a single PIM realizing a given CIM. It is not uncommon, however, for multiple PSMs to realize a given PIM. Indeed, much of the value of the approach is realized only when this is the case. In this case, we’ve shown three different PSMs: One is meant for mounting on an airborne platform such as a helicopter, one is meant for mounting on a water vessel (ship), and one is meant for mounting on a satellite. The different platforms have different CPUs, operating systems, middleware, networks, and sensors, but all are derived from the same computational model (PIM).
Each PSM is usually implemented with a single PSI. The PSI contains all the code, data, and configurations necessary to implement the PSM.
Metamodel
A metamodel is a model of a model. In English, this means that the language used to define the system (UML) is itself defined by a formal semantic model. This brings the expressive power of modeling not only to the application domain but also to the specification of the language that users employ to design their systems. The UML is based on a four-tier metamodel architecture, as shown in Figure 2.3. The bottom level, level M0, is called the instance model. This model represents the elements that exist as the system runs on the real-world platform. The instance model is created by compiling the code generated from the level-M1 model, known as the user model. The CIM, PIM, and PSM are all user models and so are at level M1. Level M2 is the metamodel, and it defines the language in which the user model is captured. UML is a language defined by its level-M2 metamodel. The UML metamodel itself is defined in a more basic modeling language, which is the meta-metamodel (level M3). It is defined in terms of the MetaObject Facility (MOF) and is a language for defining metamodels.
As developers, we care mostly about the level-M1 model and use it to generate the level-M0 model. However, you may care about the other levels if you do model transformations.
Figure 2.3 Four-level metamodel architecture
Loading comments... Write a comment