MDE [8] is a software engineering discipline that considers models as first-class citizens for both forward and reverse engineering processes. This different way of
using models is opposed to the previous approaches, that limited models to a passive role (mostly documentation) during software engineering activities.
Adoption of MDE has the potential to bring many benefits to such activities. In particular, it improves the maintainability and quality of systems [9] thanks to its features that consist in a higher abstraction level representation with respect to the source code and the automation of repetitive activities in software development processes as much as possible. The former relies on the use of models, while the latter on model manipulations. In the following, we describe these two features.
The basic assumption of MDE is that models and not the classical programming code is the right representation level for managing all artifacts within a software engineering process; therefore, models are considered as the unifying concept in MDE. Models are defined according to a three-level architecture shown in Fig. 2.11. Such architecture is composed by model, metamodel and metametamodel.
conformsTo Metametamodel Metamodel Model conformsTo conformsTo Level 3 Level 2 Level 1
Figure 2.11: Three-level architecture in MDE
A model is a partial representation of a system that captures some of its char- acteristics (e.g., documentation, source code, components, etc.). The combination of different models related to the same system can be used to derive a global view of that system. Each of these models represent entities composing software arti- facts/concepts in the real world. Such concepts and their associations (i.e., seman- tics) are defined in the second modeling level, called metamodel.
A metamodel is related to a model according to a relation of conformance. Such relation is equivalent to the program - grammar relation for a given programming language; such that, programs written in one language must conform to the syntax rules of that language as well as models defined according to a metamodel must conform to the rules embedded in that metamodel.
Metamodels are in turn expressed by means of the third modeling level called metametamodel. Similar to the model/metamodel relationship, a relation of confor- mance is defined between metamodels and metametamodels; such that a metamodel is defined using concepts and associations of a given metametamodel. In addition, this relation is equivalent to the relation between the grammar of a given program- ming language and a metasyntax/language to define grammars (e.g., EBNF: Ex- tended Backus-Naur Form [43]).
This three-level representation, also known as modelware, is not so different from the grammarware (i.e., the technical space where a language is defined ac- cording to a grammar) in terms of basic definition and infrastructure [24]. Such equivalence is shown in Fig. 2.12. Therefore, the metasyntax is conceptually equiv- alent to a metametamodel, the syntax of a given language is at the same level of a metamodel, and a program (i.e., an instance of a grammar) is analogous to a model.
Metametamodel Metamodel Model Level 3 Level 2 Level 1 Metasyntax Syntax Program Grammarware Modelware conformsTo conformsTo conformsTo conformsTo conformsTo conformsTo equivalentTo equivalentTo equivalentTo
Figure 2.12: Modelware and grammarware
Finally, models, metamodels and metametamodels may be implemented accord- ing to different standards. For instance, the Object Management Group (OMG) pro- poses a standard metametamodel called Meta Object Facility (MOF) and different standard metamodels (UML: Unified Modeling Language [10], KDM: Knowledge Discovery Metamodel [11], etc.).
The second feature of MDE is represented by model transformations (shown in Fig.2.13) that, taking one or more models as input, generate one or more models as output according to mappings defined over the input and output metamodels. In particular, given a source model, the related source metamodel and a target meta- model; a model transformation is able to generate the target model that conforms to the target metamodel.
conformsTo Source metamodel Source model Metametamodel conformsTo Level 3 Level 2 Level 1 conformsTo Target metamodel Target model Transformation model Transformation metamodel conformsTo conformsTo conformsTo conformsTo receives generates
Figure 2.13: Model transformation
mation exist. If the source and target metamodels are identical, the transformation is called endogenous; while if the metamodels are different the transformation is called exogenous.
Furthermore, model transformations are aligned to the three-level architecture in MDE, therefore they are represented as models. A model transformation con- forms to its corresponding metamodel, that contains the means to specify mappings between model elements. In turn, such metamodel is defined according to the se- mantics of the metametamodel. Since a model transformation is itself a model, a model transformation can take as input one or more model transformations and producing other model transformation as output. Such kind of transformations are called Higher Order Transformation (HOT [44]).
In addition, model transformations record information about how a target model element is related to the corresponding source element that originated it (i.e., trace- ability [12]). The relation between source and target elements is called trace and it is useful to understand and track software artifacts within an MDE process (composed by a single transformation or a transformation chain). A trace can be represented by either a simple link to a given model element or a more complex encodings (e.g., identifiers, etc.).
Traceability can be modeled according to the MDE three-level representation [13]. Therefore, traceability information is stored within a model that conforms to a metamodel4. This metamodel, shown in Fig. 2.14, is composed by a class (i.e., TraceLink), that owns the links of the source and target elements (i.e., sourceEle- mentsand targetElements) involved in a given mapping (i.e., transformation rule). Such Tracelink is identified by a name, that is the name of the transformation rule originating it. AnyModelElement sourceElements targetElements TraceLink name : String
Figure 2.14: Traceability metamodel
Finally, several transformation languages are available on the market. For in- stance, ATL Transformation language [14] that is currently one of the most used transformation languages and Query/View/Transformation [15] that is the standard language proposed by OMG.