Concepts: Model-Driven Development (MDD)
and Model Driven Architecture® (MDA®)
Topics
Introduction
RUP characterizes many of its artifacts as models
, which it defines as abstractions or descriptions of systems from particular
perspectives; the construction of models - in particular visual models
- is also highlighted as a best practice in RUP (see
Best
Practice: Model Visually (UML)
). However, although the RUP identifies many models and describes how, as inputs
and outputs, they mediate between activities, it does not prescribe the precise
form of the models (except notationally) nor require a particular way of transforming
one model into another. Thus, it is possible to instantiate and deploy RUP for
software development in such a way that, while models are produced, they serve
only as discovery, documentation and communication mechanisms and affect the
developed code only through the human developer intermediaries.
Model-Driven Development (MDD) raises the level of abstraction, although requiring
rigor in the model descriptions, and views models not simply as intermediate
development artifacts, rather as precise descriptions from which operational
systems can be generated. MDD obviously relies on more advanced tooling to succeed,
with a spectrum of possible capabilities, ranging from template production through
to complete code generation.
Model Driven Architecture® (MDA®) is an Object Management Group (OMG)
initiative to describe a complete framework for the enactment of MDD. It introduces
specific terminology and ideas, while relying on previous standardization work,
such as the Unified Modeling Language and the Meta Object Facility, to define
a rigorous transformational approach to software development and a basis for
automation through tooling.
Model-Driven
Development (MDD)
Models and Modeling 
Models are an important kind of artifact in the Rational Unified Process and
are typically expressed (in RUP) using the Unified Modeling Language (UML),
in a tool and environment-neutral way, so that RUP may be deployed and enacted
with many toolsets in many environments. The RUP Best Practice: Model Visually
explores some of the reasons for modeling, for example:
- To aid in the understanding of complex systems
- To explore and compare design alternatives at a low cost
- As a foundation for implementation
- To capture requirements precisely
- To communicate decisions unambiguously
Models are seen as a way to reason about system behavior (both desired and
realized) and structure, and communicate the results of these deliberations
to interested stakeholders. MDD goes on to emphasize the role of models as foundational
elements for implementation, in the expectation that they will be more than
blueprints based on which human developers will write code, but are themselves
enactable or executable to a degree depending on the capability of the supporting
toolset. This follows a trend, begun a long time ago, of increasing the level
of abstraction at which the human developer works. This shifts the spotlight
from code as we know it, to models expressed in a yet higher, perhaps graphical,
language.
RUP, by identifying certain artifacts as models rather than documents (capturing
requirements and design, for example) containing pictures of models,
implicitly supports this possibility.
Viewpoints and Views 
A viewpoint, as its name implies, is a notional position from which some aspects
or concerns about the system (or the set of models representing the system)
are made visible, implying the application of a set of concepts and rules to
form a conceptual filter. The term "perspective" is used similarly,
to describe a way of viewing and understanding models that best serves the many
different orientations and concerns of the diverse stakeholders.
Views are projections of models, which show entities that are relevant from
a particular viewpoint or perspective.
In MDD, viewpoints and views are used to separate concerns, for example, to
deal with the logical structure independently of the physical structure and
independently of the process structure. The closer the models are to the problem
domain, the more strongly the viewpoints or perspectives map to the business
concerns of the stakeholders; as the models are developed closer to executable
form, the more computational concerns intrude. In either case, the aim is not
simply to produce passive illustrations, but models that are, at least potentially,
generative of implementations that satisfy these separate concerns.
Elaboration and Translation (Transformation)
These terms are often used informally to distinguish between model changes
done by hand (elaboration) and model changes done by a tool (translation). In
RUP, elaboration has a quite different formal meaning - it is the name
of a life-cycle phase - but in this section, we are using it informally
to illustrate apparently differing approaches to the evolution of models.
There is also a sense of different step size in translation and elaboration
- a sense that a model is elaborated in several small steps until there
is sufficient detail (including language, infrastructure or operating system
detail) to generate code from it, either by a tool or manually. By manually,
we mean that a human can look at the model and write Java, C++, or other languages,
possibly elaborating further in the process. In contrast, in translation, the
model, still at a level of abstraction unsullied by language, infrastructure
or operating system concerns, is converted into something that executes and
produces the desired result with little or no further elaboration. Note that
the desired result includes performance and other non-functional characteristics.
Therefore, implicit in this approach, is that such cross-cutting architectural
concerns are addressed in the way the model is constructed and the way in which
it describes resource requirements.
Another word,
transformation, has come into currency, to describe the process of generating a target model
from a source model by following a set of rules and working according to a set
of parameters. Note that we use the term "model" here in the same
way as RUP, so the target model could be the implementation elements, for
example, code or text. Of course, transformation can be done by hand, which
makes successive transformations (adding detail) equivalent to elaboration,
and the rules may be very complex and rooted in deep experience of the available
technology and the domain. The default meaning however, is that transformation
is done automatically, which is examined again in the next section on Model
Driven Architecture®.
Note that the idea of transformation simply involves a source model and a target
model. The usual case is that the target model is less abstract than the source
model, that is, that the target is somehow more specific than the source, but
this is not implicit in the idea of transformation. Note that transformation
can also add detail to a model, producing a target model that is more refined,
while remaining broadly at the same level of abstraction, in that no information
relevant to another domain is introduced. Contrast this with a transformation
that produces code from a UML model, much is introduced into this target model
that is of no concern to the business stakeholder, provided required behavior
and nonfunctional characteristics are maintained.
The ability to realize the translation ideal depends on the capabilities of
the tool and our ability to codify, capture and reuse the knowledge employed
by an experienced human. The amount of knowledge that must be captured and codified
depends on the level of abstraction from which we make our translation step
- the higher the level, the more knowledge and the more domain dependence,
typically.
In MDD, we strive to raise the level of abstraction from which we can automatically
generate an operational system. A model is elaborated to the point where it
can be used to generate something. Then the strong preference is that the output
does not have to be elaborated further to execute. Further, our ambition is
to make the preceding elaboration, as far as possible, through successive automated
transformations. Thus, the two approaches converge: translation is realized
by successive transformation steps, automated as far as possible. The final
transformation to executing system occurs with the model description still at
a high level of abstraction, and with the technology, infrastructure, and target
language selections encoded in the transformation engine, and the rules and
data supplied to it.
An additional benefit of MDD is that we hope to be able to reuse transformations,
by having them codify platform and domain knowledge and best practices through
creation by experts in the corresponding domains. In this way, we facilitate
reuse by less skilled developers and avoid re-creation from scratch with each
new application.
What is a High Level of
Abstraction? 
There are a few ways to look at this. One is along the spectrum of language,
and we are seeing the emergence of forms of executable UML, for example. Another
is from the perspective of domain engineering, where the language and modeling
concepts may be specialized for the domain. For example, UML is a general-purpose
language, so, along this dimension you find the use of
UML Profiles
to specialize the use of UML. Yet another way is the felt need to avoid
vendor-specific, infrastructure-specific models so as to remain open to new
technology.
In terms of expression of the detailed dynamics, the work done on UML
Action Semantics
has made executable forms of UML a possibility, but the concrete syntax and
notation are not standardized and the level of the Action Semantics is akin
to other OO languages. Therefore, UML plus Action Semantics is probably not
the final answer, but it is an indication of where things are headed.
We conclude that a model expressed in UML, or using a UML profile, that contains
no vendor-dependent elements, is not dependent on a particular infrastructure
platform, such as J2EE or Microsoft® .NET, and is semantically complete
in structure and behavior without recourse to a particular procedural language
(Java, C#, ...) is at a high level of abstraction by this definition, although
the issue of the level of the Action Semantics remains.
From a problem-domain perspective, that is, the user or business customer viewpoint,
a possible and attractive solution is the formulation of domain-specific modeling
languages. These are languages that are abstract, in the sense that they are
couched in terms and concepts familiar to workers in the particular domain,
yet are complete in their ability to express model dynamics, while still being
UML based.
How does this relate to RUP? 
The relationship of the RUP Analysis, Design and Implementation Models illustrates
these ideas: the Analysis Model
represents an early view of how the behavior expressed in use cases will be
realized; it is naturally skewed descriptively towards the domain of the problem
being addressed, and the
Analysis
Classes
it contains are regarded as conceptual groupings of the required responsibilities
and behavior. The Analysis Model is not usually complete enough to execute,
except perhaps in a thought experiment by a human reading the model and filling
in the gaps, because too much is left unsaid. Instead, the Analysis Model has
to go through a process of refinement, adding detail and precision, resulting
in the
Design
Model.
RUP allows a project to maintain a separate Analysis Model or to regard
the Analysis Model as something that evolves into the Design Model. The process
of refinement is described at some length in RUP's activities, with the default
interpretation that humans playing the roles of Software Architect and Designer
will accomplish this evolution, probably with considerable tool assistance.
Note that this refinement can be regarded as a sequence of model transformations,
some of which may potentially be automated, for example, in the application
of
analysis
and design
patterns in the RUP activities Architectural
Analysis and Identify Design Mechanisms
.
When is the Design Model Complete?
The Design Model evolves throughout the life of the project, through several
iterations; therefore, when is the Design Model (or some portion of it) able
to be turned into code, that is, when can we start to produce
Implementation Elements and integrate
them into interesting Builds
of the system? RUP offers some guidance on
Mapping
from Design to Code
but fundamentally there are no hard and fast answers. You move to implementation
when, through review for example, you judge that you can, and that point can
vary considerably between organizations and projects. RUP offers a number of
ways to proceed from design to code, two of which we discuss here to illustrate
how decisions about design completeness are made:
1. Sketch and Code
RUP says: "One common approach to design is to sketch out the design
at a fairly abstract level, and then move directly to code. Maintenance of the
design model is manual."
To be successful with this approach requires that the developer is able to
bridge the abstraction gap between the design and implementation levels. Often
maintenance of the design model is a secondary concern and the code becomes
the focus!
2. Round-Trip Engineering (RTE) with Single Evolving Design Model
RUP says: "In this approach, there is a single Design Model. Initial
sketches of design elements evolve to the point where they can be synchronized
with code."
Here the developers close the abstraction gap with a sequence of modeling steps.
The difference between this approach and "sketch and code" is that
the intermediate steps are manifest and, at the end, the abstract version of
the design model has disappeared.
In both cases, the potential value of an abstract design model is lost: in
"sketch and code" because the abstract design model is typically not
maintained and, over time, loses touch with the code and in "single evolving
design model" because the abstract version disappears. Even if an initial
version is kept, it usually suffers the same fate as the sketch and code design
model. Note that the end point for the design model with RTE is really code
visualization, and a similar visualization could be reverse-engineered from
code produced in sketch and code with appropriate tooling. In RUP, we mitigate
the loss of the abstract design model, to some extent, by capturing significant
architectural views and design rationale, at critical points, in the Software
Architecture Document.
MDD offers the hope that the abstract design model will become foundational
to code generation and have longevity. It becomes the primary basis for maintenance
and, in fact, may be the only basis for maintenance. It also offers a clear
definition of the end point for design, that is, that point at which, as far
as the transformation engine is concerned, the model is complete, consistent
and unambiguous and able to be turned into an executable system. How abstract
the model can be depends on the available technology and toolset (for an example
see
Tour: Rational Software Architect Overview) and may also be domain dependent.
Note that as far as MDD is concerned, this is simply another transformation
(design to code) but an important one that jumps across abstraction levels.
The next section describes an emerging framework standard for MDD, an initiative
of the Object Management Group (OMG) called Model Driven Architecture® (MDA®).
Model Driven Architecture (MDA)
Motivation 
MDA is an initiative of the OMG, an industry consortium of some 800 members
with a mission to establish standard guidelines and specifications to provide
a common vendor-neutral framework for application development and encourage
interoperability across major hardware and software infrastructure platforms.
The Unified Modeling Language is a product of the OMG. The OMG now promotes
MDA as its flagship specification and with the OMG's stance as the promulgator
of practical standards intended to be supported by industry IC, practice, products
and tools, and noting the success of UML, MDA is worthy of study. There is a
wealth of information on MDA, including the most recent MDA Guide [OMG03],
on the OMG's
Web site
.
There are also several books available such as [FRA03],
[KLE03], and [MEL04] and many articles, such as "An MDA Manifesto" by Grady Booch, Alan
Brown, Sridhar Iyengar, James Rumbaugh and Bran Selic in The MDA Journal, May
2004.
MDA's Core Ideas

MDA introduces some specific concepts and terminology that distinguish it from
more general approaches to MDD, and these are defined and discussed in the following
sections.
Building on Existing Standards
MDA is underpinned by existing OMG standards, including:
- The Meta-Object Facility (MOF) - In addition to defining a language
for the construction of metamodels, for example, UML and
CWM, the MOF defines a framework for implementing repositories for models and
metamodels, allowing a consistent approach to manipulation of these models
when using MDA. The MOF is thus an essential technology for MDA.
- The Unified Modeling Language (UML) - The
PIMs,
PMs and the PSM
s are defined in UML, which is the foundational notation for MDA.
- XML Metadata Interchange (XMI) - XMI defines a UML model interchange
format based on XML.
-
The Common Warehouse Metamodel (CWM) - As UML is to application modeling,
so the CWM is to data modeling.
Platform Independence 
An intuitive notion of a platform
is that it supports a higher architectural layer through provision of services
with a well-defined set of interfaces that hide the implementation details.
The OMG definition (in the MDA Guide) of platform is:
"A set of subsystems/technologies that provide a coherent set of functionality
through interfaces and specified usage patterns that any subsystem that depends
on the platform can use without concern for the details of how the functionality
provided by the platform is implemented."
This is similar to the concept of a
layer
as it is used in RUP.
The idea of platform independence is slightly slippery: it is a quality
or characteristic of a model, for example, one might say a model is independent
of a particular platform when it does not contain any references to services
or capability provided by that platform. However, the statement is relative
because it is difficult to envisage an absolute form of platform independence.
The MDA Guide acknowledges this and also admits the possibility of degrees of
platform independence with respect to a particular platform where, for example,
a model uses a generalized form of a feature in a particular platform.
The achievement of platform independence has been assisted by the evolution
of platforms such as J2EE, .NET and WebSphere, to increasing levels of abstraction
in terms of what is exposed to applications. This makes the identification of
platform-neutral constructs much more tractable and the platform-specific transformations
that convert them much simpler and easier to write.
Platform Independent Model (PIM)
It follows that we can say a model is a PIM with respect to a particular platform
when it is not bound to usage of that platform and could be used with any platform
of that type. In a previous section, we discussed the idea of a high level of
abstraction and concluded that a model expressed in UML (or using a UML profile)
that contains no vendor-dependent elements, is not dependent on a particular
infrastructure platform, and is semantically complete in structure and behavior
without recourse to a particular procedural language was at least notionally
executable and at a high level of abstraction. Is such a model platform independent?
Yes and no. No, with respect to a perhaps imaginary UML Virtual Machine, and
yes, with respect to a whole class of platforms on which such a virtual machine
would depend.
Platform Model 
The platform model is that set of concepts (representing parts and services),
specifications, interface definitions, constraint definitions and any other
requirements that an application needs to use a particular platform. In MDA,
the platform models are detailed and formalized in UML, for example, and available
in a MOF-compliant repository. For example, platform models could be built for
J2EE or .NET, among others.
Platform Specific Model (PSM) 
A PIM is transformed into one or more PSMs by the addition of information that
makes it specific to a particular platform or platforms. The PIM and the PSM
still specify the same system, but the PSM is constrained to particular technology
and may contain platform-specific elements. Note that there is no implication
that a transformation step (PIM to PSM, or its associated platform) is large
or small. A transformation involving the application of a small set of patterns
refines the model and, in some sense makes it more specific; this emphasizes
the relativity of the terms PIM and PSM.
Viewpoints and View 
These terms are used in the same way in MDA as we described for MDD:
- A viewpoint, as its name implies, is a notional position from which some
aspects or concerns about the system are made visible, implying the application
of a set of concepts and rules to form a conceptual filter. Given that some
information about the system is suppressed, it is a form of abstraction. The
term perspective is used similarly.
- From a viewpoint, you can see views, which are projections of models,
showing entities that are relevant from that viewpoint.
MDA specifies three viewpoints on a system: a computation independent viewpoint,
a platform independent viewpoint, and a platform specific viewpoint.
Computation Independent Viewpoint
From the computation independent viewpoint, you are concerned about the context
for the system, the requirements and constraints under which it must operate,
and the things in the environment with which it must interact. From this viewpoint,
you do not see details of system structure or behavior.
The Computation Independent Model (CIM) is a view
of the system or system-to-be from the computation independent viewpoint. The
CIM is similar in concept to a combination of the Domain Model in RUP, which
is the set of artifacts, including Business Glossary and Business Analysis Model,
that is output from the Workflow Detail: Develop a Domain Model (in Business
Modeling), and the Use-Case Model, which is the computationally-independent
description of the behavior of the system. The CIM, which is couched in the
language of the subject-matter or domain experts, is an important link in the
identification, during Analysis and Design, of key abstractions in the system-to-be.
Platform Independent Viewpoint
The platform independent viewpoint is relative to a particular platform. From
that viewpoint you can see the structure and behavior of a system without the
details of that platform. The PIM is a view of the system from the platform
independent viewpoint.
Platform Specific Viewpoint 
From the platform specific viewpoint, also relative to a specific platform,
you can see what was visible from the platform independent viewpoint but now
with the platform usage details revealed. The PSM is a view of the system from
a platform specific viewpoint.
Automation of Transformation 
The idea of transformation is fundamental to MDA and model transformation is
defined simply as "the process of converting one model to another model
of the same system". MDA also defines a little pattern to visualize
the conversion and to illustrate use of some of the terminology we have seen:
The MDA Pattern
The intention of the diagram is to show that the transformation is a first-class
thing: the transformation takes the PIM and other information and combines them
to produce the PSM.
Model transformation can, of course, be done manually. This is little different
than the way software design has always proceeded. Even here, MDA is useful
in delineating and formalizing the idea of transformation, the process, and
the additional information to be used. MDA also suggests that a record of the
transformation be produced; this provides strong traceability from the PIM to
the PSM because it should include a map from the elements of the PIM to the
elements of the PSM. Most leverage comes from being able to automate transformations,
even if only partially, yielding the same advantages that came from the replacement
of assembler programming with high-level languages.
How is Transformation Performed?
MDA does not prescribe a single way to do transformation: a mapping, driven
by the choice of a platform, is prepared to give a specification of how to transform
a PIM into a PSM for that platform; this mapping results in a transformation
definition (perhaps expressed as a set of transformation rules), possibly with
transformation parameters, written in a transformation definition language.
Note that the OMG issued an RFP (MOF 2.0 Query/Views/Transformations RFP) in
the expectation of standardizing (for the MOF) languages for creating model
views, querying a model and writing transformation definitions. The MDA Guide
describes several approaches to transformation, including:
- Metamodel Transformation - This approach assumes there is a PIM-level
MOF metamodel in the language of which the PIM is built. Equally, for the
chosen platform, there is a PSM-level metamodel in the language of which a
PSM may be constructed. A mapping between the two metamodels can be used to
construct a transformation definition; this is then used to transform PIM
into PSM.
- Marking - A mapping for the chosen platform is prepared. This mapping
is used to construct a transformation definition, which includes a set of
marks that are used to mark elements of the PIM, yielding a 'marked PIM',
and a definition of what to do with elements so marked. The marked PIM is
then further transformed to produce the PSM. The marking is typically a manual
process, but the subsequent transformation may be automated.
- Model Transformation - The PIM is built using platform-independent
types, also specified in a model, where the elements in the PIM are subtypes
of the platform-independent types. A particular platform is chosen, which
is associated with a set of platform-specific types. A mapping is made between
the two type sets, yielding a transformation definition, which is applied
to the PIM, producing a PSM expressed in subtypes of the platform-specific
types. This approach is somewhat similar to metamodel transformation except
that the transformation is restricted to types in a model rather than concepts
from a MOF metamodel.
- Pattern Application - The PIM is built using a set of types and abstract
patterns that are platform independent. For the chosen platform, a set of
platform-specific types and patterns exists. A mapping is made between the
two type and pattern sets, giving a transformation definition to be applied
to the PIM. This produces a PSM where the abstract patterns have been made
platform specific.
For more detail, the reader is referred to the MDA Guide [OMG03].
How is Transformation Applied? 
The simplest scenario for the application of MDA is:
- Prepare a PIM
- Select a platform
- Prepare a mapping if one does not already exist
- Apply the transformation to produce a PSM
- Turn the PSM into code. If the PSM needs no further refinement and can be
directly implemented, it is an implementation, as defined in the next section
PSMs for other platforms can be generated in the same way.
Repeated Application of the MDA Pattern
However, the MDA pattern is amenable to repeated application: a generated PSM
at one level becomes the PIM for the next, that is, for the next, increasingly
specialized, platform choice. Note that in MDD, as we describe it in RUP and
support it with the IBM Rational toolset, our preference is to minimize the
number of refinement steps, that is, to proceed from a representation that is
close to the customer's problem statement to an executable form as directly
as possible.

Repeated Application of the MDA Pattern
General Model-to-Model Transformation
The same concepts can be applied to a general transformation, that is, any
model to any model. If, for example, there exist two metamodels whose languages
are used to express the models, then, in principle, a mapping can be made, yielding
a transformation definition. This is applied in the way we have already seen
for PIM to PSM transformation.
Implementation 
The MDA Guide uses "implementation" in a similar way to RUP's
Implementation Model. It is a specification of all the
Implementation Elements
needed to construct, deploy, install and operate the system.
A PSM may itself be an implementation or may require further refinement before
it can be turned into code. Note that the production of an implementation PSM
can skip the step of manifesting the PSM and go straight to code. In this case,
the more abstract PIM is able to be turned directly into code by the transformation
engine. A visualization of the code may still be provided to the developer to
help understanding, but this can be reverse engineered from the code.
Putative Benefits 
Portability and Interoperability
MDA offers the hope of controlling the expense and perturbation of technology
churn by allowing a relatively stable set of PIMs to be retargeted to whatever
new technology is required. The expectation is that, with increasing acceptance
of MDA, the developers of new technology will also deliver mappings so that
transformations can be done quickly.
By extending the PIM-PSM mappings for two platforms, MDA suggests that 'bridges'
can be built between the two PSMs, and ultimately between the two implementations,
so that a PIM can be distributed across platforms. Most companies are faced
with the reality of developing for heterogeneous environments with a mix of
new and old technologies, so this ability to realize interoperability is potentially
of great benefit.
Reduced Lifecycle Cost

Productivity 
The focus of development with MDA becomes the more abstract PIM. With a powerful
toolset to generate a PSM (or code), such an environment should be more productive
in much the same way that working in a high-level language is more productive
then working in assembler, particularly given that a PIM, or something like
it, is often developed anyway, for example, serving as the Design Model in RUP.
The productivity gain depends critically on how much manual intervention is
needed in the transformation process.
Quality 
Ideally, in MDA, the target of maintenance is the PIM. Consequently, with the
proviso that the PIM is well-architected, there should be fewer defects in the
life of the product because there are fewer opportunities for a human to inject
them, and the defects that are discovered should be less costly to fix, through
the benefit of automated transformation. The concentration on the PIM is also
more closely aligned with domain concerns, so there should be a higher probability
of satisfying the users' needs.
| |
|