The integration of bodies of knowledge to build computer-based systems is essential in order to successfully achieve the goals, set by researchers, computer scientists and clients in general. In order to develop a bridge of understanding among the dierent parts, two main approaches emerge: MDA(Model-Driven Architecture) and MDE (Model-Driven Engineering). As Favre [1] mentions, \MDE is not MDA. The MDA standard from the OMG is just a specic incarnation of the MDE approach".

1. Towards a Basic Theory to Model: Model Driven
Engineering
Priscill Orue Esquivel
September 8, 2012

2. Introduction
The integration of bodies of knowledge to build computer-based systems
is essential in order to successfully achieve the goals, set by researchers,
computer scientists and clients in general. In order to develop a bridge
of understanding among the different parts, two main approaches emerge:
MDA(Model-Driven Architecture) and MDE (Model-Driven Engineering).
As Favre [1] mentions, “MDE is not MDA. The MDA standard from the
OMG is just a specific incarnation of the MDE approach”.
This paper attempts to describe several concepts related to the MDE
approach: its core notions and how its theory is formed. The first section
enumerates several background concepts, useful to grasp the work. Then,
the theoretical foundations of MDE are explained in order to know its com-
ponents. Finally, a deeper study of MDE is performed in the last section,
with the strengths and weaknesses associated to the MDE approach. To
carry out this report, secondary online sources were consulted to offer the
most up-to-date information on the subject.
0.1 Background concepts
This section contains a set of definitions necessary to understand the con-
text of the work. It does not intend to formalize concepts, but to offer a
background on the following topic.
The first definition is about models. According to Favre [1], a model “is
a simplification of a system built with an intended goal in mind”. The main
idea is that a model should answer questions related to the actual system.
In this way, what it is stated theoretically in the paper reflects what is
going on with reality. However, Favre [1] claims that some authors restrict
their definition of models; he cites Warmer and his colleagues: “A model
is a description of a (part of ) system written in a well-defined language.”
For them, a “well-defined language” is a language including well-defined
form (syntax), and meaning (semantics), which is suitable for automated
interpretation by a computer.
Technological spaces: they refer to a working context with a set of con-
cepts related to each other, body of knowledge, tools, required skills, and
possibilities. Commonly, it is associated “to a given user community with
shared know-how, educational support, common literature and even work-
shop and conference meetings”. Moreover, it is considered a zone of “estab-
lished expertise and ongoing research”, and a repository for resources, both
1

3. abstract and concrete [2].
The previous concepts form the topic of this work: MDE. Model-Driven
Engineering is an “open and integrative approach that embraces many other
Technological Spaces (TS) in a uniform way”. Its main emphasis is placed on
technological spaces, and the integration of bodies of knowledge developed
by different research communities. In each space, the concepts of model,
metamodel and transformation have different representations. For example,
what is called a “metamodel” in Modelware corresponds to what is called a
“schema” in Documentware, to a “grammar” in Grammarware, etc [1].
0.2 Model-Driven Engineering theoretical founda-
tions
The very definition of model is unclear. According to Favre [1], “MDE
experts claim that models should be precise, but they just use plain English
and informal drawings to define what is MDE”. UML diagrams were used
at first, but then discarded due to their informality and almost uselessness.
However, the need to think about models, metamodels, transformations and
how they work together has not changed.
Whenever intuition is not enough, a basic theory of MDE is necessary.
This theory helps in reasoning not only in simple cases but when situations
become complex. The main approach to complexity is to apply simple and
elementary concepts, and combine them into regular structures. For this
reason, the idea is to go back to the roots of Computer Science: the set
theory and the language theory; then, a megamodel for MDE is going to be
explained [1].
0.2.1 Elements from the set theory: Sets, Pairs, Relations
and Functions
The concepts of interest for the megamodel are sets, pairs, relations which
are set of pairs, partial functions which are relations, and total functions
which are partial functions, represented in 1. Though Favre [1] uses UML/OCL
notation, the concepts are not related to UML. “A set is a set, irrespective
of the language it is expressed in.” Languages are used for notations, and
it is avoided to mix the megamodel concepts with the ones coming from
the language used. “For instance in the UML megamodel, the ∈ concept is
represented as standard UML association named ElementOf, not the as the
built-in − >includes OCL expression.”
2

4. UML models should be tested in order to demostrate their utility in a
given context. According to Favre [1], this is the only way to get reasonable
confidence in a MDE megamodel. A model can be considered that it satisfies
needs, until it “provides bad answers in a given situation”.
0.2.2 Elements from the language theory: Languages, Pro-
grams and Interpreters
“The definitive language theory” does not exist. However, there are some
concepts applied when dealing with programming languages. A language is
a set. For example, Java is the set of all java programs. “a”, “ab”, “abb”,
“abbb”, “abbbb”, ... is the language of the strings that start with an “a”
and then continue with some “b”. Languages are usually infinite and due
to this fact, “reasoning with these languages require to deal with models of
languages”. Grammars constitute models of languages, but, they are not
languages [1].
Programming languages are “languages of programs, that is sets of pro-
grams, where each program is an executable model of a function”. It is
important to remark that not all models of a given function are meant to be
executable. For example, the “signature of a C function int power(int a, int
b) is a model of that function, but it cannot be executed”. When a model
of a function is executable, this is called a program [1].
Interpreters are functions. “An interpreter function of a programming
Figure 1: Set Theory Package
3

5. language is a function that takes a program with an input value and that re-
turns an output value that corresponding to the result of the execution of the
program.” Interpreter functions of a programming language L that allows
to describe programs that transforms Xs into Ys are therefore characterized
by the following pattern: (LxX) →→ Y [1].
0.3 Model-Driven Engineering
In this section deeper concepts about Model-Driven Engineering (MDE) are
analyzed. These concepts form the theory of MDE that it is explained in
the last part of the section.
0.3.1 MDE Patterns
There are several patterns defined by Favre [1], to describe the performance
of MDE:
• The meta-step pattern. The metamodel concept corresponds to a role
played by a system in a MDE pattern coined meta-step.
• A pattern of model transformation. One can distinguish transfor-
mation instances (e.g. an XML file transformed into another XML
file), transformation functions (e.g. a set of somehow related pairs),
transformation models (a description of a function, also called trans-
formation program if it is executable, e.g. a XSLT file), transformation
modeling language or transformation programming language if it can
be executed (e.g. XSLT), transformation metamodel (e.g. the DTD
of XSLT)
• The interpreter pattern. A transformation program is a transforma-
tion model that can be executed.
0.3.2 Megamodel infrastructure
The infrastructure of the megamodel, shown in 2, is totally technology de-
pendent. The main package of the infrastructure includes several math-
ematical entities, as special cases of Abstract Systems. Those systems are
processed by human minds. The purpose of MDE is to build better computer
programs and better computer models. Those are called Digital Systems.
These categories are not important; they are used to demostrate that the
term “System” includes a very wide range of artifacts [1].
4

6. A system could be a complex entity, so it can be divided in many parts.
“A system can play the role of model with respect to another system, which
then plays the role of system under studies. This relation, called Represen-
tationOf (µ for short), has been identified by many authors” [1].
Figure 2: MDE infrastructure
Transformation is a key concept in MDE and it is based on the set
theory because the concept of relation is a good abstraction for transforma-
tions. Nevertheless, there is no agreement on what to call a transformation:
its meaning depends on who is using it. One example describes the pack-
age Transformation containing the concepts of TransformationInstance and
TransformationFunction, like seen in 3. The figures about MDE infras-
tructure 2 and Excerpt of Transformation 3 are related to each other “by
the fact that Pairs and Functions are AbstractSystems”. TransformationIn-
stance is the application of a transformation to a particular input. On the
other hand, TransformationFunctions are functions, and, as a result, sets of
TransformationInstances [1].
Figure 3: Excerpt of Transformation
5

7. 0.3.3 Megamodel superstructure and technological spaces
The two components of the megamodel: infrastructure and superstructure
containing TSs-dependent megamodels are related to each other. The meg-
amodel infrastructure is akin to an umbrella covering various technological
spaces (TSs). However, defining the superstructure, which is modeling the
TSs of interest, is not easy; whereas defining the mappings Infrastructure
< − > TSs appears to be a promising approach. The most important idea
is that: “showing how particular TSs could be integrated in the megamodel
is also a very good point to communicate with other research communities,
because the megamodel provides a concrete mean to establish terminology
correspondences across TSs” [1].
0.3.4 Towards a basic MDE theory
Now that all the necessary foundations are clear, the next step is to define
the theory supporting MDE. First of all, what is a Theory?. “A theory is a
way to deduce new statements about an SUS from the statements already
in some model of the SUS”. To achieve a theory, the relationship between
models and metamodels with the theory has to be described. “A model is
a set of statements about some system under study (SUS).” The model is
correct if all its statements are true for the SUS. Then, “a metamodel is a
specification model for a class of SUS where each SUS in the class is itself a
valid model expressed in a certain modeling language.” So, both terms can
be seen as part of a logical hierarchy conforming a MDE theory [3].
For Favre [1], the relationship between the megamodel and the theory for
MDE is not evident with UML, but it is much more recognizable “with the
Prolog incarnation”. The Prolog DE megamodel is an executable program.
It has the ability to deduce new facts about a particular MDE situation, like
the one modelled on the left of the figure 4. “The excerpt of the megamodel
in the center shows the translation the meta-step pattern presented before.
The power of Prolog can be used to ask questions and get answers (right of
Figure 4)”.
0.3.5 Discussion and final analysis
For Favre [1], to build a good model for MDE is a complex research issue.
Nevertheless, the approach of introducing concepts incrementally, “trying at
each step to add only truly essential concepts”, has provided good results.
At each step, there is a lot of attention on developing examples either from
computer technology or the real world to check the validity of the theory.
6

8. MDE needs refinement. One of the concepts that should be enforced is
conformance, which Techopedia [4] defines as: “the degree of adherence to
preset expectations. The degree to which a product meets its prespecified
criteria is termed as conformance in the context of software engineering.”
Including the notion of conformance requires other concepts like syntax,
semantics, etc. Another “important requirement during the design of the
megamodel is to give the ability to extend it to suit the needs of particular
technological spaces.” Moreover, the notion of platform is still in doubt,
whether to include it or not in the megamodel. For these reasons, more
research is needed [1].
Conclusion
This work has presented several concepts about the formation of the theory
of Model-Driven Enginnering (MDE). Precise modeling is an ideal goal, but
most of MDE is described with pictures and informal sketches. As seen
in the examples, UML diagrams includes most of the relevant information
about a context but they fail to give all the answers.
As Favre [1] points out, “a design which is not tested will invariably be
thrown away, sooner or later.” Complex technologies are to be added on top
of already complex technology layers. A suggestion is to learn from the past
and identify the Technological Spaces required to integrate various bodies
of knowledge. Moreover, a set of MDE concepts should be agreed upon and
let them be known to future researchers on the area. “The set theory and
language theory are parts of the lingua franca in Computer Science, so using
these concepts can greatly help in identifying bridges with existing TSs.”
The main goal of any model is to connect ideas with the real world. The
megamodel detailed in this work deals with a lot concepts, but still needs
to take into account several aspects in order to form a complete and logical
theory of MDE. A good strategy towards this goal is to set the definition
Figure 4: Automated reasoning about MDE
7

9. of core concepts, like models and megamodels, in a definite way, so future
work can be developed based on these definitions.
8

10. Bibliography
[1] Favre, J.-M. (2004) : In Workshop on Software Model Engineering,
WISME 2004, joint event with UML2004.
[2] Ivan Kurtev, Jean Bzivin, M. A. (2002) In Industrial Track, (ed.), In-
ternational Conference on Cooperative Information Systems (CoopIS), :
.
[3] Seidewitz, E. (2003) IEEE Explore 20(5), 26 – 32 Web; accedido 25-
Abr-2012.
[4] Techopedia Conformance http://www.techopedia.com/definition/
14194/conformance (2012) Sitio Web; accedido 26-Abr-2012.
9