3.4 METAMODELLING FOR MODEL TRANSFORMATION

Recent years have seen the rise of another application area for metamodelling in software engineering. Initiated by OMG in terms of their Model-Driven Architecture (MDA) vision [21,27], it has broader application in what might be called “model-driven engineering” (MDE), “model-driven development” (MDD) or “model transformation”. We will use here MDE, the most generic of these various acronyms.

The vision is that high-level models will be created by humans and then transformed by machines, in several steps, until source code is reached; with the consequence that software developers will spend their time using transformation tools and writing transformation rules rather than writing code.

The underpinning idea of MDE is that we should move the focus of software development from coding to model building. Just as no-one (or almost no-one) codes in assembler languages these days but rather uses a high-level, language that is automatically transformed into object code, the future (it is said) should be that of models that are automatically compiled to object code with no manual interference. The automatic transformation of models, via a number of machine (not manual) steps, into object code requires significant formality. This formality, it is argued within the MDE community, can be supplied in the form of metamodels [20].

Metamodels underpin each element of the MDE strategy. Typically, it is envisaged that a series of models will be applied to an increasingly concrete platform (Figure 3.12). Initially, the model should be a computationally independent model (CIM), which is then transformed into the software engineering regime as a platform independent model (PIM). This is then converted to a platform specific model (PSM), which is readily translated into code.

Figure 3.12: An example MDE software development lifecycle (using OMG's MDA approach) (after [21])

Source: Kleppe, Warmer and Bast, 2003, copyright Pearson Education Ltd. Reproduced with permission

At each stage, the model needs to be documented using a specific language, such as UML, Petri Nets or Java, each of which requires a definitional metamodel. It is vital that these languages, if different, must be compatible. Compatibility can be achieved at the metamodel level (or, perhaps, the metametamodel level).

Transformations between models thus require (automatic) rules for transformations across the suite of languages and hence metamodels (although it is possible that the source and target language might be the same in some situations). These collections of transformation rules are applied to the source model in order to create the target model automatically at each stage – the tools used to do this are necessarily generic.

Figure 3.13: MDA interoperability using bridges (after [21])

Source: Kleppe, Warmer and Bast, 2003, copyright Pearson Education Ltd. Reproduced with permission

Typically, a single PIM will be transformed into several PSMs (Figure 3.13). Since these have been generated from the same model (PIM), they are necessarily inter-compatible, such that “bridges” between the various models are possible. Thus the various applications (for different platforms) are interoperable [20].

At each stage, therefore, it is vital that the languages (and metamodels) used are comprehensive for the specific transformational requirements. For example, the original versions of UML were found to be deficient for use as a modelling language for code generation (PIM to PSM transformation), leading to attempts to create special versions of UML [22; 31].

Not only do the various modelling languages need explicit metamodels but so do the transformation rules. One such metamodel to support mappings and transformations is given in Figure 3.14, which shows a Transformation taking a Model as input and outputting a target model. In order to undertake such a transformation, a model mapping is required that “maps types and relationships in one or more sources on to types and relationships in one or more target metamodels” [12]. The Model Mapping, as can be seen, is specified by a Model Mapping Specification with its subset of RuleSet, typically expressed in IF/THEN format. These mapping rules can be implemented using languages such as Prolog or XQuery or even with a procedural programming language. These and other implementation details are explored in [12].

Figure 3.14: A metamodel for mappings and transformations (after [12])

Source: Greenfield and Short, 2004, copyright John Wiley & Sons Limited. Reproduced with permission