Models are an important kind of work product 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 Supporting Material: Visual Modeling explores some of the reasons for modeling,
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 and MDA 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
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
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, Term Definition: 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 Term Definition: UML profile 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 tasks, 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 Term Definition: analysis pattern and Term Definition: design pattern patterns in the RUP tasks Architectural Analysis and Identify Design Mechanisms .
When is the Design Model
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
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)
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
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.
An intuitive notion of a Term Definition: 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 Term Definition: 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.
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
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.
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 Task: 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
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
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
Repeated Application of the MDA Pattern
The intention of the above diagram is to show three applications of the MDA pattern, with the initial PIM becoming a
PSM dependent on platform 1, then transformed again to be dependent on platform 2 as well, then transformed again to be
dependent on platforms 1, 2 and 3.
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.
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.
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
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.
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.