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

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 aspectsat different levels of abstraction (e.g., system, subsystem, component, task,primitive element).

MDA, a specific set of standards within the OMG, defines ameans for organizing models that provides benefits of reusability andmaintainability for complex systems composed of heterogeneous technology. TheCIM defines the requirements model, which focuses on stakeholder needs. The PIMfocuses on the essential aspects of the system that must be present. The PSMmaps the PIM to a target platform by including a set of technologies and designpatterns. The PSI is the code generated from the PSM. Model translation enablesdevelopers 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 thatsystem and its environment for some purpose.” The salient aspects of a model arethe 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 fordifferent purposes. MDA uses this concept to implement a well-establishedidea—the separation of the essential aspects of the thing from how those aspectsare implemented.

MDA defines four uses for models in its context (see Figure 2.1). Thecomputation-independent model (CIM) doesn’t show the pieces within asystem that perform the necessary computation but instead focuses on therequired
functionality of the system. The platform-independent model(PIM) focuses on the essential parts of the system and their essentialbehavior but does not focus on platform-specific details such as the operatingsystem, CPU, or distribution infrastructure. The platform-specific model(PSM) includes the elided platform information and represents thesystem targeted to a specific execution environment. Theplatform-specific implementation (PSI) is the source code ofthe 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 automatedtransformations provide the most benefit.

Figure 2.1
Key models in MDA

Models are usually represented in the UML, but other modeling languages canbe used instead of, or in conjunction with, the UML model. For example, safetyanalysis is often performed using FTA or FMEA. These languages can be used alongwith UML models to supply useful views not available within the UML.

A minimalist UML model consists of three types of elements: classes (andtheir features and relations), state machines for some of the classes, andtypical and exceptional interactions of instances of those classes, usuallyshown on sequence diagrams. In addition to these basic elements, a great dealmore can be added, such as use cases, activity models, requirements and theirrelations, and so on.

It should be noted that the model content is held in the model repository andis exposed in diagrams. The diagrams are not the model but are really justuseful views into the model repository. Thinking that the diagrams are theprimary 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 modeltransformation. Figure 2.2 shows a typical set of models. TheTrackingUseCase-Model represents the functionality and QoS requirements for atracking system. It is given the stereotype «CIM» to indicate the type of modelit is. The use case model contains traceability links from textual requirementsto the model’s use cases, interactions, and state machines (and associateddiagrams). This CIM is transformed into an analysis model that represents thecomputational model that realizes the requirements.

Figure 2.2 Model transformations

The TrackingAnalysisModel has the stereotype «PIM» to indicate that it is aplatform-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. Itdoes not include the platform-specific details such as the CPU, operatingsystem, middleware, network structure, or even the specific sensor platformsused.

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 ofthe approach is realized only when this is the case. In this case, we’ve shownthree different PSMs: One is meant for mounting on an airborne platform such asa helicopter, one is meant for mounting on a water vessel (ship), and one ismeant for mounting on a satellite. The different platforms have different CPUs,operating systems, middleware, networks, and sensors, but all are derived fromthe same computational model (PIM).

Each PSM is usually implemented with a single PSI. The PSI contains all thecode, data, and configurations necessary to implement the PSM.


A metamodel is a model of a model. In English, this means that the languageused 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 domainbut also to the specification of the language that users employ to design theirsystems. The UML is based on a four-tier metamodel architecture, as shown inFigure 2.3. The bottom level, level M0, is called the instance model. This modelrepresents the elements that exist as the system runs on the real-worldplatform. The instance model is created by compiling the code generated from thelevel-M1 model, known as the user model. The CIM, PIM, and PSM are all usermodels and so are at level M1. Level M2 is the metamodel, and it defines thelanguage in which the user model is captured. UML is a language defined by itslevel-M2 metamodel. The UML metamodel itself is defined in a more basic modelinglanguage, which is the meta-metamodel (level M3). It is defined in terms of theMetaObject Facility (MOF) and is a language for defining metamodels.

As developers, we care mostly about the level-M1 model and use it to generatethe level-M0 model. However, you may care about the other levels if you do modeltransformations.

Figure 2.3 Four-level metamodel architecture


The CIM models the required functionality without identifying thesystem elements necessary to perform the computation to achieve it. That is tosay, 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 acoherent usage of the system and serves as an organizational unit forrequirements, as we will see in some detail later in Chapter 6, “AgileAnalysis.” Of course, the use case itself is just a named oval; we need far moreinformation than that! The use case is bound to requirements via «trace»dependencies and is elaborated in the model with state machines detailing thesystem states and modes related to the execution of the system usage, and(usually many) interactions shown on sequence diagrams. The set of use casediagrams is like a table of contents for a book that defines the systemrequirements.

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

Figure 2.4 CIM use case diagram


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

What is “essential” in this context? One way to think about it is that it isa structural or behavioral aspect that must be true in any acceptable designsolution. The elements must be able to perform the required functionality bycollaborating. For example, if you’re building a bank accounting system, you’llneed 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 byany bank to perform its accounting functionality. These classes also haveinherent relations (AccountHistory aggregates Transactions, Account ownsAccountHistory, Customer associates with Accounts, etc.). These elements havebehavior, as dictated by accounting practice and by law. These elements aren’treally free to vary between specific accounting systems, even though thenetworks 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 supportdifferent operational modes for the intersection.

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

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

It is common—and recommended—that there is at least one diagram depicting thecollaboration 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. Inaddition, other class diagrams may show other aspects of the PIM, such as classgeneralization taxonomies, contents of packages, internal structure of compoundclasses, and so on.

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

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

Figure 2.5 shows a portion of a PIM class model realizing the use caseIdentify 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 isthat it can generate the use case sequence diagrams when it runs thosescenarios, the PIM must be executable. No napkin drawings, no CRC cards—realsoftware that runs. The PIM won’t have all the platform-related detail, butunless you can test it, you don’t really know whether or not it is correct. Andyou can test only things that actually run.

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


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

Platforms are often chosen because they already exist in the system contextand the application must deploy onto them to fit into the operationalenvironment. However, it is often true that the developers have significantleeway to
select platform aspects. In this case, platforms should beselected because they are optimal in some sense. Similarly, design solutions areoptimizations of analysis solutions. Reusable design solutions are known asdesign patterns, so one way to think about the creation of the PSM is to applythe 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, exactlyhow the message delivery takes place isn’t an essential property of the PIM butit 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 Irecommend 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 thePIM.
b. Ensure that the PSM delivers the desired optimizations.

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

optimalDesign = max[&#x3A3DegreeOptimizedj XWeightj ]


DegreeOptimizedj is the degree of optimization (a largernumber is better)
for design criteria j

Weightj is the relative importance of the designcriteria j

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

Real-time and embedded systems care more about optimality than most. The termreal-time means “predictably fast enough,” and the primary distinguishingproperty of real-time and embedded systems is that the qualities of service arenot just desirable—they are essential for correctness. Some common designcriteria for real-time and embedded systems include:

  • Performance
  • Worst-case performance
  • Average-case performance
  • Predictability of performance
  • Schedulability (ability to reliably meet the deadlines)
  • Precision and accuracy
  • Safety
  • Reliability
  • Robustness (fault immunity)
  • Physical system properties
  • Weight
  • Heat
  • Power consumption
  • Cost
  • Recurring cost (i.e., cost per shipped item)
  • Design cost
  • Maintainability
  • Extensibility
  • Time to market
  • Certifiability (i.e., standards conformance)

In the Harmony/ESW process, the creation of the designPSM occurs at three levels of abstraction (see Figure 2.6). MDA itself focuseson the highest level, architectural design. The Harmony/ESW process identifiesfive key architectural aspects, and the PSM identifies platforms, designpatterns, and technologies in each of these. The design decisions made at thislevel are called “strategic” because they affect most or all of the system. Thearchitectural views organize the PIM collaborations into larger-scale entities.The architectural views in the Harmony/ESW process are discussed in the upcomingsection “Harmony’s Five Key Architectural Views.”

Figure 2.6 Levels of design

In addition to the architectural aspects, design patterns can be applied atthe level of collaborating classes. This is known as mechanistic design in theHarmony/ESW process. Design patterns here are below the radar of MDA per
se.Mechanistic design patterns focus on optimizing the analysis collaborations thatconstitute the PIM. Design patterns at this level focus on optimizing how theanalysis classes interact.

Detailed design concentrates on optimizing individual classes, functions, anddata elements. At this level of abstraction, the industry refers to the patternsof optimization as design idioms. Most classes are fairly simple, but there is acertain percentage in all systems, usually 3% to 5%, that require specialattention. The topics of concern during detailed design include:

  • Internal optimization of algorithms, for example:
  • Average execution time
  • Worst-case execution time
  • Reusability
  • Extensibility
  • Memory usage
  • Internal optimization of data structures
  • Memory usage
  • Read access time
  • Write access time
  • Persistence
  • Internal safety and reliability measures
  • Data redundancy
  • Data validity checks
  • Precondition and postcondition validation
  • Error- and exception-handling mechanisms
  • Optimization of state behavior through state behavioral patterns
  • Implementation of associations and other relations

Usually the PSM has many diagrams associated with it that depict differentaspects of the design.

Figure 2.7 shows a “task diagram,” which is simply a class or object diagramshowing the concurrency architecture. The tasks are shown as «active» objects inthe figure. The UML models a concurrency unit such as a task or thread as an«active» object (or class). This element is a structured element containinginternal parts (object roles met by instances of classes) that execute in thecontext for managing the event queue for the concurrency unit (typically thereis one event queue per concurrency unit) and creates and destroys the operatingsystem thread in which the internal parts execute. «active» objects are shownwith a heavy border on the sides of the element.

Figure 2.7 PSM concurrency diagram

The other elements shown in the figure are stereotyped «Resource». These arepassive elements that execute in the thread of the caller and are constrained insome way. Usually, there must be some mechanism for protecting the source fromthe mutual exclusion problems associated with simultaneous access to theresource in a multithreaded environment. This can be done in a number of ways,such as:

  • Critical regions—disable task switching while the resource is being accessed
  • Mutual exclusion semaphores—block access from competing threads while the resource is being accessed
  • Queuing requests—filter the requests through a first-in-first-out (FIFO) queue or a priority FIFO

In this case, those mechanisms aren’t shown, but they could be, if desired.Note that the selection of the tasks, the mapping of the PIM semantic elementsinto those tasks, the selection of the resources, and the mechanisms forprotecting those resources are all optimization properties; they are selectedbecause they provide the desired optimality of the system and so are part of thePSM and not the PIM.


The PSI isn’t described in the original MDA documents from the OMG but hasbeen added because it constitutes an important artifact for deployment of thefunctionality on a specific platform. The PSI isn’t a model in the same sense asthe CIM, PIM, and PSM. It refers to the code generated from a PSM thatimplements the PIM on a specific platform. It is discussed with some militaryprograms such as the Single Integrated Air Picture (SIAP) captured in theIntegrated Architecture Behavioral Model (IABM) created by the Joint SIAP SystemEngineering Organization (JSSEO) and realized in the Open Architecture TrackManager (OATM), a project with which I was involved.

Probably the most common use of MDA is the generation of the PSI from the PSM(or even the PIM, skipping the explicit creation of the PSM). In fact, some toolvendors will tell you that MDA is all about specifying actions in an actionlanguage even though the MDA specifications don’t even mention the term. Thesepeople clearly have something they’re trying to sell. Having said that, let’sexamine the concept a bit in the next part in this series..

Next in Part 3: Action languages and model transformation
To read Part 1, go to: Why model and why MDA?

Used with the permission of the publisher, Addison-Wesley, an imprint of PearsonHigher Education, this series of three articles is based on material from “RealTime Agility” by Bruce Powel Douglass .

Bruce Powell Douglass has worked as a software developerin real-time systems for over 25 years and is a well-known speaker, author, andconsultant in the area of real-time embedded systems. He is on the AdvisoryBoard of the Embedded Systems Conference where he has taught courses in softwareestimation and scheduling, project management, object-oriented analysis anddesign, communications protocols, finite state machines, design patterns, andsafety-critical systems design. He develops and teaches courses and consults inreal-time object-oriented analysis and design and project management and hasdone so for many years. He has authored articles for a many journals andperiodicals, especially in the real-time domain.

He is the Chief Evangelist forRational/IBM , a leadingproducer of tools for software and systems development. Bruce worked withvarious UML partners on the specification of the UM, both versions 1 and 2. Heis a former co-chairs of the Object Management Group's Real-Time Analysis andDesign Working Group. He is the author of several other books on software,including Doing Hard Time: Developing Real-Time Systems with UML, Objects,Frameworks and Patterns (Addison-Wesley, 1999), Real-Time Design Patterns:Robust Scalable Architecture for Real-Time Systems (Addison-Wesley, 2002),Real-Time UML 3rd Edition: Advances in the UML for Real-Time Systems(Addison-Wesley, 2004), Real-Time UML Workshop for Embedded Systems (ElsevierPress, 2006) and several others, including a short textbook on tabletennis.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.