Page 219 -

204 PASTOR, MOLINA, AND IBORRA
of transformations, developers can obtain the source code of the systems defined by these models.
Developing an application in an MDA fashion basically involves creating a model of the application
that is agnostic about implementation details. MDA refers to these models as Platform-Independent
Models. A PIM can then be transformed into another model that adds details about the platform
on which the application will be developed. These are referred to as Platform-Specific Models.
Transformations can be chained so that the PSM obtained by applying a certain transformation
T becomes the PIM for the next transformation (T i + 1 ). Eventually, a PSM (or set of PSMs) will
i
be transformed into text in order to obtain the final product of the (chain of) transformation(s):
source code.
MDA proposes UML (UML, 2007) as the “standard” modeling language to define both PIMs
and PSMs, although the OMG itself acknowledges that any modeling language can be used in MDA
provided that it is defined in terms of the Meta-Object Facility MOF (MOF, 2007) language.
Since the inception of the MDA, many efforts have been devoted to addressing an aspect that
seems to be critical for the success of the approach itself: how to define and implement trans-
formations between models, and from models to text. These efforts have been rewarded by the
definition of two specifications to establish the grounds for full-fledged MDA implementations,
namely, MOF QVT (Queries/Views/Transformations) (Heaton, 2001) and MOF Model-to-Text
(Eakman, 2007).
Two aspects that are even more critical than the ability to define transformations have been
traditionally neglected: modeling languages and execution models. For a modeling language to
be used in a model-centric development approach, it must be:

• abstract enough so that models created with it are truly implementation-agnostic, thus al-
lowing developers to focus on the problem space and reify to multiple platforms;
• accurate enough so that models created with it provide a full description of the relevant
features characterizing the system; and
• precise enough so that all elements in models created with it have a well-defined semantics
with zero semantic variation points.

Any attempt to build a deterministic, repeatable process (automated or not) to transform a
conceptual model of a system into a software application that is functionally equivalent to this
model must be based on an execution model that states the runtime behavior of all the primitives
in the specification language.
In this context, two very remarkable features in the OO-Method are introduced below:

1. A precise set of conceptual primitives is provided by the method, in accordance with its
formal basis. Since a subset of UML diagrams is used as the corresponding basic repre-
sentation blocks, an adequate and efficient use of this well-known standard is proposed,
which avoids the problem of overspecification that occurs when having to use the hundreds
of modeling elements provided by the UML notation as a whole.
2. On the other hand, every conceptual construct introduced in the model has its corre-
sponding software counterpart when projected in the software product representation
through a process of model transformation. In this way, every piece of information
contained in the conceptual schema is meaningful and has a precise semantic justifica-
tion: to describe a specific part of the problem domain so that it is properly converted
into a software representation at the solution space (depending on the particular target
software technology).