MDA brings a number of significant benefits to the developer, including theagile developer. Modeling, well performed, enhances visibility andunderstandability of the analysis and design.The MDA standard relies on a core set of technologies, including MOF, UML,SysML, CWM, and profiles.
The MOF forms the core basis for all modeling within the OMG family ofstandards, including the UML. MOF is a kind of universal modeling language inwhich other modeling languages may be defined; in fact, MOF can be thought of asthe language in which the UML is defined.
MOF uses the same basic syntax as UML models, so you can use UML tools tocreate MOF models. MOF is used to create other modeling languages, such as theCommon Warehouse Metamodel (CWM) and the CORBA Component Model (CCM). Mostdevelopers don’t need to directly work in MOF, but it’s there in the conceptualunderpinnings of UML if needed.
The UML is enormously successful; in fact, it is the de facto standardsoftware modeling language. I have contributed to the UML standard and so I havea keen interest in its success. It is a mostly graphical modeling languageconsisting of many different kinds of diagrams, as shown in Figure 2.12.
Figure 2.12 UML diagram types
Strictly speaking, these are not all different diagram types. Some constitutediagram uses; for example, a structure diagram is a class diagram whose purposeis to show the internal structure of a composite class, and a package diagram isa class diagram, the purpose of which is to show some aspect of the modelorganization.
The three key diagrams are the class, state, and sequence diagrams. The otherdiagrams have their place and add value, but any system can be constructed fromthese three basic diagram types.
We won’t say much about the UML per se in this book, although we will use itextensively. Interested readers are referred my books Real-Time UML forexposition and explanation of how to use the UML and Real-Time UML
Workshopfor Embedded Systems (Burlington, MA: Elsevier Press, 2006) for detailedexercises with solutions from the real-time and embedded domain.
Strictly speaking, the Systems Modeling Language (SysML) is a UML Profile;that is, it is a minor extension/elaboration/subset of the UML. I alsocontributed to the SysML standard. The SysML is an attempt to bring the power ofUML modeling to the systems engineering domain. Historically, systems engineershave rejected
the UML because it is too “software-oriented.” The SysMLstandard changed the names of key elements and is now experiencing great successwith systems engineering groups. SysML simultaneously subsets the UML (forexample, SysML does not use UML deployment diagrams but uses block—i.e.,class—diagrams) for this purpose and extends the UML by adding new semanticextensions (e.g., modeling continuous behavior), new diagram types (e.g.,parametric diagrams for showing parametric values and their relations), and somemodel libraries (e.g., SI definitions model library for standard internationaltypes).
Figure 2.13 summarizes the primary inclusions and extensions SysML makes tothe UML.
Figure 2.13 SysML diagram types
One of the good things about the MOF-based standards is that they providemodel interchange standards. This is valuable for a couple of reasons. First, itmeans that, in principle, you are not bound to a particular vendor with all yourcorporate intellectual property.
This is huge, because companies have millionsof dollars invested in their UML models. If a tool vendor goes out of business,or if another tool vendor arises that better meets the developer needs, the XMLModel Interchange (XMI) standard provides an accepted common means for bringingyour models, and the intellectual property they represent, to the new tool.
Italso means that supporting analysis tools, such as RAPID RMA from Tri-PacificSoftware (a performance and schedulability analysis tool), have a standard wayof reading user models so that they can perform specialized functions andanalysis. The current version of XMI, 2.1, has finally met the users’ request toprovide diagram interchange in addition to the interchange of semantic elements.
Unfortunately, due to varying degrees of adherence to the XMI standard, XMIinterchange is not as seamless as it should be. However, most users don’t useXMI frequently, so the pain is manageable.
The Common Warehouse Metamodel (CWM) is primarily concerned with metadatamanagement and data transformations. It actually contains a set of metamodelsfor relational databases, record structures, XML, and data transformations. Itspurpose is to enable interchange of warehouse and business intelligence metadatabetween various tools and repositories. CWM is based on UML, MOF, and XMI.
A UML Profile is a version of the UML specialized for some special purpose ordomain. A profile is a coherent set of lightweight extensions to existing UMLelements, inclusions and omissions from the UML standard, and additionalelements. A profile must be consistent with the base definition of the UML. Itis not allowed to extend the metamodel directly. It is considered an extensionat the M1 level, although we find it more useful to consider at level M1.5. Theextension mechanisms include:
- Model libraries
A stereotype is a special “kind of” metaclass. Typically, it identifies anelement that is used in a specific way, has additional associated metadata, orhas additional rules for usage.
Stereotypes are normally identified by attaching the stereotype name inguillemets, but you are also allowed to add new notations. New notations caninclude both specialized graphics symbols for the stereotyped element as well asnew diagrammatic types based on existing diagrams.
For example, Figure 2.14shows a DoDAF Operational View-2 (OV-2) diagram, which is a stereotype of aclass diagram. On it we see operational nodes and human operational nodes(stereotypes of instances) connected via needlines (stereotype of links). On theneedlines, we see information exchanges (stereotypes of UML information flows).Underneath, the elements have valid UML specifications, but the stereotypeallows you to cast the problem in the vocabulary of its domain.
Figure 2.14 DoDAF OV-2 diagram
Stereotypes often contain additional metadata, stored in tags. A tag is aname-value pair. Associating a set of tags with a stereotype means that anystereotyped element also contains those tags. For example, the same DoDAFprofile has a stereotype constraint called a PerformanceParameter used formodeling different kinds of qualities of service. Performance parameters havetags as shown in Figure 2.15.
Other profiles have other tags. The UML Profile for Schedulability,Performance, and Time (SPT) has a large set of stereotypes with associated tagsfor capturing performance and schedulability metadata. Because the underlyingmodel is UML, these can be exported in XMI to be used by performance analysistools.
Constraints are a common way to assign values to tags. A constraint is auser-defined “well-formedness” rule—a rule that defines a criterion for awell-formed model element. Tags are often associated values in constraints.These constraints are usually declarative and can be validated only by testingthe system, often on its ultimate target platform (PSM).
A model library is a set of predefined constructs, such as the SI definitionswithin the SysML profile that provide standard data types for typical measuresof length, mass, time, current, temperature, and so on; these include units suchas meters, kilograms, seconds, amperes, kelvins, and others.
Figure 2.15 Performance parameter tags
A profile is a coherent set of these extensions—stereotypes, tags,constraints, and model libraries—all tied to the underlying UML metamodel.
Common profiles in the real-time and embedded domain include:
- SysML —a profile of the UML intended to provide the modeling power of UML to systems engineers
- The UML Profile for SPT —a profile intended to provide standard ways of representing performance metadata for analysis
- Modeling and Analysis of Real-Time and Embedded Systems (MARTE) —a profile intended to replace and extend the SPT profile to cover other concerns of embedded systems beyond just performance (not yet released; currently in finalization)
- UML Profile for DoDAF and MoDAF (UPDM) —a profile intended to provide a standard means of representing DoDAF (U.S.) and Ministry of Defense Architecture Framework (UK) models in the UML (not yet released; currently in finalization)
- UML Testing Profile —a profile intended to provide ways of representing test vectors, test suites, and test fixtures to facilitate the testing of UML models and to bring the expressive power of UML to the testing domain.
In addition to the benefits of standard UML modeling, MDA provides benefits ofits own, especially portability, reusability, and isolation from technologicalchurn.
In this context, portability means the capability of moving an applicationfrom one execution environment to another. MDA clearly improves portabilitybecause the PIM provides all the functionality in an inherently reusable form.This is because the platform and technological details are missing from the PIM.Once a high-quality PIM is created, it can be put on different platforms throughmodel transformations to create PSMs for the target environments.
One of the problems with source code as a repository for intellectualproperty is that it contains essential functionality munged together withimplementation details. For most companies building real-time and embeddedsystems, their key intellectual property is not platform-related; it is in thestate or algorithmic specification of the essential behavior.
A company thatmakes flight control systems has a core interest not in network architectures,but in how flight systems work. A company that makes routers has a core interestin network architectures but not in operating systems. Each of these companieswants to be able to create its core intellectual property in such a way that itcan be used on other platforms or when the nature of the existing platformschanges.
MDA provides a clear means to achieve this goal: creating inherently reusableintellectual property within the PIM and reusing it by specifying the PSM thatincludes platform and technological details.
Isolation from Technology Churn
Another point of view on reusability comes from the fact that technologychanges, and it changes quickly. New network infrastructures, new CPUs, and newoperating systems appear all the time. The core semantics of the applicationsdon’t, for the most part, change nearly as quickly.
If you work in a domain inwhich systems must be maintained for a long period of time—such as military andaerospace—then you need isolation from the constant churn of technology. It istoo expensive to completely reengineer a system because a CPU or network becomesobsolete. Having the essential semantic intellectual property captured in thePIM makes it far easier to integrate new technological and platform solutions.
Harmony’s Five Key Architectural Views
The UML is a generic modeling language and expressly does not contain contentthat is process-dependent. Thus, it has weak notions about what should beconsidered architecture and how to go about creating it. On the other hand, theHarmony/ESW process is in the business of providing that guidance and has verystrong opinions about what constitutes an architecture and how to go aboutcreating it.
Figure 2.16 Harmony/ESW five key views ofarchitecture
As shown in Figure 2.16, Harmony/ESW centers its architectural concern aroundfive key views:
- Subsystem and component architecture
- Concurrency and resource management architecture
- Distribution architecture
- Safety and reliability architecture
- Deployment architecture
These architectural aspects are expressly identified because in my experiencethey play a key role in the efficiency and quality of the delivered system.Harmony organizes its architecture into these aspects because the computerscience literature is organized in the same way. It should also be noted thatthese aspects are a part of architecture, architecture is a part of design, anddesign optimization is part of the PSM. Thus, these concerns usually do notappear in the PIM but instead only in the PSM.
It is normal to create one or more diagrams expressing each of thesearchitectural viewpoints; thus, your models have a “subsystem diagram,” a “taskdiagram,” a “distribution diagram,” and so on. These are usually nothing morethan class diagrams with a mission to show specific aspects of the architecture;that is, they will show the model elements relevant to the architecturalviewpoint in question but not more than that.
In an incremental development process such as Harmony/ESW, not all of theseviewpoints may be present in all of the prototypes. Early prototypes may haveonly the subsystem architecture in place and only later will the otherviewpoints be added. When the various architectural aspects are added isdependent upon the schedule and iteration plans for the project.
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 Powel 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.