Section: Scientific Foundations
Genesis
In the 80's the dominant scheme was object technology leading to class-based languages. The main concepts were classes and instances with the associated instantiation and inheritance relations. This produced an efficient implementation technology that has become mainstream today with such languages as Java and C#. The main associated paradigm is object composition that has progressively replaced procedural refinement used in previous technologies. Several extensions to object technology have proposed to use various component-based architecture schemes.
As an alternative to these proposals, MDE offers multiple schemes, not only object-based but also relation-based, event-based, rule-based, function-based, etc. Each of the schemes may be represented by a given metamodel. Correspondences between them may be explicitly stated, for example by a class to relational transformation. MDE can thus be seen as a generalization and abstraction of object technology allowing to map more abstract organizations on class-based implementations. This is the essence of the EMF (Eclipse Modeling Framework). The AmmA platform generalizes the EMF principles by proposing a more regular model-based organization. Similarly to EMF, AmmA may be efficiently implemented on top of Java or C#-based platforms.
In MDE, models are considered as the unifying concept [39] . Traditionally, models have often been used as initial design sketches mainly aimed for communicating ideas among developers. On the contrary MDE promotes models to primary and precise artifacts that drive the whole development process. The notion of model goes beyond the narrow view of semi-formal diagram thus requiring much more precise definitions and implementations that allow partial or full automation.
The MDE community has been using the concepts of terminal model, metamodel, and metametamodel for quite some time [12] . A terminal model is a representation of a system. It captures some characteristics of the system and provides knowledge about it. In MDE we are interested in terminal models expressed in precise languages. The abstract syntax of a modeling language, when expressed as a model, is called a metamodel. A language definition is given by an abstract syntax (a metamodel), one or more concrete syntaxes, a definition of its semantics, etc. The relation between a model expressed in a language and the metamodel of this language is the conformance relation (conformsTo ). This should not be confused with the representation relation (repOf ) holding between a terminal model and the system it represents. Metamodels are in turn expressed in a modeling language called metamodeling language. Its conceptual foundation is captured in a model called metametamodel. Terminal models, metamodels, and metametamodel form a three-level architecture with levels respectively named M1, M2, and M3. A formal definition of these concepts is provided in [4] and [40] . MDE promotes unification by models like object technology proposed in the eighties unification by objects [36] . The principles of MDE may be implemented in several standards. For example, OMG proposes a standard metametamodel called Meta Object Facility (MOF). An example of a metamodel in the context of OMG standards is the UML metamodel.
In our view the main way to automate MDE is by providing transformation facilities. One of the first papers to discuss metamodel-based transformation was [46] . The production of model Mb from model Ma by a transformation Mt is called a model transformation. When the source and target metamodels are identical (MMa = MMb ), we say that the transformation is endogenous. When this is not the case (MMa
MMb ) we say the transformation is exogenous. An example of an endogenous transformation is a UML refactoring that transforms public class attributes into private attributes while adding accessors for each such transformed attribute. Another important idea is the fact that a model transformation is itself a model [1] . This means that the transformation program Mt may be considered as a model and as such conforms to a metamodel MMt . The consequences are quite important since this allows for example uniformly storing and retrieving different kinds of terminal models including transformations. Besides storage and retrieval, many other common operations may also be applied to such different kinds of models. The property of a transformation being a model allows also to deal easily with Higher-Order Transformations (HOTs), i.e. transformations taking other transformations as input or/and producing other transformations as output.
Transformations may thus be considered as models. But many other operations may be considered as transformations as well. For example verifications or measurements on a model can be expressed as transformations [41] . One can see then why large libraries of reusable modeling artifacts (mainly metamodels and transformations) will be needed.
As MDE developed, it became apparent that this was a branch of language engineering [38] dealing more specifically with DSLs. DSLs are programming or modeling languages that are tailored to solving specific kinds of problem by opposition to General Purpose Languages (GPLs) that aim to handle any kind of problem. Java is a programming GPL and UML is a modeling GPL. DSLs are already widely used for certain kinds of programming; probably the best-known of these is SQL, the language for manipulating relational data in databases. DSLs allow everybody to write programs using the concepts that actually make sense to their domain or to the problem they are trying to solve (for instance Matlab has matrices and lets the user express operations on them, Excel has cells, relations between cells, and formulas and allows to express simple computation in a visual declarative style, etc.). As well as making domain code programmers more productive, DSLs also tend to offer greater optimization opportunities. Programs written with these DSLs may be independent of the specific hardware they will eventually run on. MDE offers an improved way to the development of DSLs by allowing easier expression of abstract syntaxes (with KM3 for example [4] ) and easier transformation on domain code – the equivalent of program or terminal models – (with ATL for example [3] ).
