Using model-driven development for agile embedded apps:Part 2 – Key concepts of MDA

Bruce Powel Douglass

December 28, 2010

Bruce Powel Douglass

CIM

The CIM models the required functionality without identifying the system elements necessary to perform the computation to achieve it. That is to say, it represents a domain model, usually built by a requirements (or business) analyst or subject matter expert (SME).

The key element within the CIM is the use case. The use case represents a coherent usage of the system and serves as an organizational unit for requirements, as we will see in some detail later in Chapter 6, “Agile Analysis.” Of course, the use case itself is just a named oval; we need far more information than that! The use case is bound to requirements via «trace» dependencies and is elaborated in the model with state machines detailing the system states and modes related to the execution of the system usage, and (usually many) interactions shown on sequence diagrams. The set of use case diagrams is like a table of contents for a book that defines the system requirements.

Figure 2.4 shows a typical use case diagram from such a CIM. The named ovals on the diagram represent the use cases. The stick figures represent actors—elements in the system environment that interact with the system during the use case execution. The lines between the actors and the use cases are associations, indicating that messages (events or data) are exchanged between the system and the actor when it executes the use case.

Figure 2.4 CIM use case diagram

PIM

The PIM is a computational model that is platform-independent. In older technology, this is called the essential or analysis model. The PIM contains the essential semantic elements, modeled as classes, their essential relation, and their essential behavior.

What is “essential” in this context? One way to think about it is that it is a structural or behavioral aspect that must be true in any acceptable design solution. The elements must be able to perform the required functionality by collaborating. For example, if you’re building a bank accounting system, you’ll need classes such as the following:

• Customer
• Attributes
• Name
• Tax ID
• Address
• Account
• Attributes
• Balance
• Interest rate
• Date opened
• Date closed
• Behaviors
• Credit
• Debit
• Open
• Close
• Transaction
• Attributes
• Amount
• Source account
• Target account
• Date
• Time
• CreditTransaction (subclass of Transaction)
• DebitTransaction (subclass of Transaction)
• TransferTransaction (subclass of Transaction)
• InterestTransaction (subclass of Transaction)
• AccountHistory

And so on. This information (and, of course, a great deal more) is needed by any bank to perform its accounting functionality. These classes also have inherent relations (AccountHistory aggregates Transactions, Account owns AccountHistory, Customer associates with Accounts, etc.). These elements have behavior, as dictated by accounting practice and by law. These elements aren’t really free to vary between specific accounting systems, even though the networks that support information transfer may vary.

Similarly, a traffic-light control system has some essential structure (traffic sensors, control lights, etc.) and some required behavior to support different operational modes for the intersection.

The PIM represents these essential properties and elides the elements that can change—those will show up in the PSM. In the bank example, whether an ATM machine is connected via a wireless or a wired network is a part of the PSM and so will be detailed there.

The PIM is usually organized around the use cases but is modeled primarily as a set of class diagrams with support from interaction and behavioral diagrams.

It is common—and recommended—that there is at least one diagram depicting the collaboration of PIM classes per use case. There may be many such diagrams, depending on the nature and complexity of the system and its use cases. In addition, other class diagrams may show other aspects of the PIM, such as class generalization taxonomies, contents of packages, internal structure of compound classes, and so on.

The PIM is correct only if it supports the functionality required by the use case. It is common to have a set of sequence diagrams representing the interactions of the system with the relevant actors for each use case. So, the PIM is correct if, and only if, it can reproduce, through execution, those use case sequence diagrams. Hence, it is highly recommended that the interactions among the collaborating elements be shown in sequence diagrams so that they can be compared to the original use case sequence diagram.

Other highly useful diagrams in the PIM are state machines for various reactive or stateful classes, and activity diagrams for complex operations and functions. State machines sequence the actions (such as invocations of methods) into permitted flows based on the arrival of events of interest. Activity diagrams are like flowcharts on steroids and can depict complex algorithms in a way that is easier to comprehend than the implementation code. Activity diagrams are most commonly used to detail the behavior of class methods above a certain minimum complexity.

Figure 2.5 shows a portion of a PIM class model realizing the use case Identify Track from Figure 2.4.

Figure 2.5 PIM class diagram

It is very important—and we will discuss this concept in great detail later— that the PIM be validated for correctness. Since the measure of correctness is that it can generate the use case sequence diagrams when it runs those scenarios, the PIM must be executable. No napkin drawings, no CRC cards—real software that runs. The PIM won’t have all the platform-related detail, but unless you can test it, you don’t really know whether or not it is correct. And you can test only things that actually run.

It should be noted that while the MDA specifications talk about moving from the CIM to the PIM by model transformation, this is primarily done by expert human modelers rather than via automation. Later in this book, I will discuss a family of techniques known as “object identification strategies” to create the PIM from the CIM, but that is a human-driven, rather than an automated, process.

PSM

The PSM contains the original semantic content of the PIM but also platform, design, and technology decisions as well. The PIM contains only essential elements but omits these latter aspects. The PSM can best be thought of as a transformation of the PIM in which platforms, designs, and technologies are selected on the basis of achieving the system optimization goals.

Platforms are often chosen because they already exist in the system context and the application must deploy onto them to fit into the operational environment. However, it is often true that the developers have significant leeway to
select platform aspects. In this case, platforms should be selected because they are optimal in some sense. Similarly, design solutions are optimizations of analysis solutions. Reusable design solutions are known as design patterns, so one way to think about the creation of the PSM is to apply the design patterns to the PIM. The PIM may need to exchange messages and data, but unless the application is an Ethernet router or something similar, exactly how the message delivery takes place isn’t an essential property of the PIM but it is a property of the PSM.

There are a number of ways to create the PSM from the PIM (see the section “Common Model Transformations” later in this chapter), but the basic workflow I recommend involves the explicit identification of the optimizations involved. Starting with a high-quality PIM, the steps for creating the PSM are:

1. Identify the optimization criteria, such as worst-case performance, throughput, reliability, weight, heat, design cost, manufacturing cost, etc.
2. Rank the optimization criteria in order of criticality.
3. Identify platforms, design patterns, and technologies that optimize the most important of those criteria at the expense of the least important.
4. Apply the design solutions to the PIM—this is where the different ways of transforming the PIM occur.
5. Validation of the PSM:

a. Ensure that the PSM didn’t break the working functionality of the PIM.
b. Ensure that the PSM delivers the desired optimizations.

Thus, a good PSM (design) will maximize the weighted set of design criteria

optimalDesign = max[&#x3A3DegreeOptimized_j X Weight_j]

where

DegreeOptimized_j is the degree of optimization (a larger number is better)
for design criteria j

Weight_j is the relative importance of the design criteria j

This optimization is how we select one design approach over another; we select it because it is more optimal overall. The key point is that the PSM is the “design model,” and design is really all about optimization of the required
functionality. Transforming the PIM into the PSM is therefore mostly about optimizing the PIM: The PSM is the selection of a particular design solution that optimizes the weighted set of design criteria with respect to the relative importance of each. Secondarily, the PSM is also focused on deploying the application into different operational environments.