What do we need metamodels for? - Semantic Scholar

Download PDF
7 downloads 0 Views 346KB Size Report
Comment
Charles Donnelly and Richard Stallman. Bison, The yacc-compatible Parser Gen- erator. See also http://dinosaur.compilertools.net/bison/index.html. 12.
What do we need metamodels for? Ileana Ober1 and Andreas Prinz2 1

IRIT - Universit´e Paul Sabatier, Toulouse 118 Route de Narbonne, F-31062 Toulouse, France [email protected] http://www.irit.fr/∼Ileana.Ober 2 Faculty of Engineering, Agder University College Grooseveien 36, N-4876 Grimstad, Norway [email protected]

Abstract. Model-driven technologies usually rely on the use of metamodels for describing the structure of models, either explicitly or implicitly. In reality, it turns out that there are very few standardized metamodels and relying on them hinders integration. In this paper we discuss on the place and role of models and meta-models. The discussion is driven by the pragmatic goal of taking advantage of models and meta-models in order to facilitate the tool integration. As a result, we argue for doing tool integration using a meta-model based approach. Using an example, we look at the information covered in the meta-model that is really needed to bring together different models.

1

Introduction

Today’s software industry faces an increased interest in modelling and techniques aiming to raise the abstraction in software development. One of the most relevant steps in this direction is the OMG initiative in promoting modelling through MDA / MDE [20]. In order to have a fully operational model driven engineering framework lots of things remain to be done, and some of them need to be carefully studied at the theoretical level. One of the results of the MDx evolution is the increased interest in metamodels and meta-modelling techniques. While meta-modelling is definitely a needed step in an MDx approach, we feel that it is often given a more important place than it deserves, while models should be the main actor. In this paper we give a new view on the place and role of meta-models. Our view starts from the idea that the main actor in a MDx environment is the model, and the main goal of this new technology is to be able to reason at model’s level, process the information at model’s level, compose various models, etc. In this perspective, the role of meta-models should be to facilitate the use of models. One of the open areas in the MDx concerns the integration of different kinds of models in order to be able to use them jointly. The current development of computers makes them an ambient overall presence, which asks for the integration of different tools. Of course, the integration

2

task would have been much easier if we had established standards for the integration of the tools. For various reasons, these standards are largely missing. Our new view on meta-models and their role is the basis of a new methodology for integration of tools based on ad-hoc standards that can be further developed into a real standard. We use the method of meta-modelling as a base for the integration and provide specializations that allow handling of inconsistent and deviating models, coming from different sources. The paper is structured as follows: Section 2 describes our view on models and meta-models and therefore their role in abstraction. In this context, Section 3 gives our view on how the relationship between models and meta-models allows for a flexible tool integration. Section 4 illustrates our approach on an example and we conclude in Section 6.

2

Basic notions in MDA/MDE: model and meta-model

The MDA/MDE technique is based on the notion of model, which gives a representation of the system to be developed, and allows us to reason about it in a simple way. Modelling in not a new issue, it is traditionally used in science, as a means to master the complexity. The key to success here is abstraction. There is no consensual definition of a model, but there are some model properties that people agree upon, and that are sufficient to our needs. Some of the most important properties of the model, as also underlined in [5, 26], are that: – it offers a simplified view of a system, with respect to a fixed (set of) criteria; – it can be seen as a set of statements about the system; – it should be able to answer questions in place of the actual system, giving the same answers as the system itself. This is of course possible only for questions pertinent to the system and to the modelled view. The models are expressed in modelling languages. Various modelling languages exist, depending on the kind of information the model is suppose to render, on how the model is used afterwards, etc. For modelling software, one can use a modelling language dedicated to software modelling – such as UML [21], SDL[18] – or a language closer to the theory that will be applied afterwards to the model, for instance for formal verification – ASM [7], Petri nets [9], automata [16]. Obviously, the most important aspect in a modelling language is not its linguistic aspect (i.e. the way it is defined syntactically), but the kind of systems it can be applied to and the kind of information it can model. These aspects are typically stored in a meta-model. A meta-model is a description of the concepts the modelling language provides without caring on the actual syntax. A particular kind of meta-model is an abstract grammar. In the same way as an (abstract) syntax, a meta-model specifies what can be captured in valid models expressed in a certain modelling language (see also [26]). Concretely, meta-models define sets of concepts and relationships between them which can be used as an abstraction filter while modelling (see [5]).

3

For example, the UML meta-model defines how UML models look like, how they are structured and it gives some elements of how behavior can be expressed in UML. This is done by defining UML model-elements, specifying their relationships, allowed and forbidden model-element configurations and describing (textually) how to do system abstraction in UML. The exact nature of the relationship between a model and a corresponding meta-model is far from being settled. This discussion is particularly active in the UML community. Given the strong object-oriented background of this community, it was long taken as given that a model is an instanceOf a meta-model, in an object-oriented style. Furthermore, the same relationship instanceOf is said to relate the system under modelling with the model representing it. Nevertheless, the experience proved that this relationship cannot describe all the links possibly existing between a model and the meta-model it is based on, or between a system and its model. In Section 4, we discuss first order predicate calculus grammars. In this context, the model is a predicate calculus formula, while the meta-model is one predicate calculus grammar. In this case a formula is not really an instance of a grammar. Using the instanceOf relationship in this context is inappropriate. To cope with this lack of precision, several authors [4, 14, 26] propose to use a conformantTo (or conformsTo) abstract relation between a model and its corresponding meta-model. This is a generic relationship, whose actual nature depends on the technological space of the model, the meta-model and the system under study. For example, in the case of UML (in an object oriented setting) one can say that a UML model containing only a structural part (i.e. classes and relationships) is indeed an instanceOf the UML meta-model, while a predicate calculus formula is generatedBy the predicate calculus grammar. This gives us two concrete examples of the conformsTo relationship. In summary, a meta-model abstracts the representation issues from the language such that the focus can be on the important aspects disregarding their concrete representation.

3

The place of meta-models

Meta-models and meta-modelling are not new ideas. They are used since a long time in data base modelling. MDA/MDE induced a tendency to use them even more, and gave them a more central role. In this section, we describe today’s place of meta-models in software development, and we propose a new view on their role. In the previous section we defined meta-models as offering a description of the concepts the modelling language provides without showing the actual syntax. An immediate consequence of this definition is that meta-models could serve as basis for the integration of various tools based on a same modelling language. However, this is not the case in common practice.

4

Meta-models are typically used to describe part of the abstract syntax of a language. One of the most known and most used meta-models is of course UML’s standard meta-model [21]. This meta-model is a main part of the UML standard definition, whose ”primary responsibility [...] is to define a language for specifying [UML] models” [21] (Section 7.10 - Infrastructure Part). Therefore, this meta-model defines the main concepts existing in UML, as well as their mutual relationships. The practical question that comes out immediately is how this meta-model can be exploited by UML modelling tools. The practice has shown that UML tool builders get inspiration from the standard meta-model without actually using it as such, mainly due to the UML meta-model complexity, to its definition style that does not fit the needs of tool builders as well as for purely industrial political reasons. This leads us to the issue of the meta-model qualities or definition style. Indeed, the UML meta-model is defined with the concern of capturing the language constituents rather with an accent on the language (abstract) syntax than on its semantics. This does not necessarily fit the need of tools, which are often focusing on particular usages of the language (graphical editor, constraints checker, simulators, etc). Another factor, less related to the intrinsic quality of the UML meta-model, is of course the fact that the language is huge, and different tools choose different subset of the language to cover, which leads to different language subsets. As a result, although in principle all UML tools should be based on the same standard UML [21] meta-model, in fact their actual base meta-models are different. Integration of several tools and techniques using a meta-model is almost trivial if all partners agree on the definition of this meta-model, which then defines all the exchange formats and access interfaces. Users of particular tools (based on the common meta-model) may even not be able to distinguish on whether they are using a foreign model or a model of the own tool. However, this situation is highly hypothetical. Agreeing on a common metamodel may be harder to achieve than the whole integration task although tool integration would not be the only benefit of using a common meta-model. In order to come to the situation where all tool providers agree on a common meta-model, it is important to join forces for defining it. Note that in the case of the UML language, we have a standard meta-model defining the language. However, since the UML tools do not use it directly, it cannot serve the integration purpose. Moreover, during the software development, the system is typically handled by various tools. Each of these tools deals with an abstraction of the software under study from the point of view of the technique or theory it is based on. Let Tool be some tool that can be applied to the model. This tool deals with a certain technique or theory, theoryTool , and it is applied to software systems Syst. In a model – meta-model terminology, we are in a technological space defined by the theory theoryTool , thus theoryTool corresponds to the meta-model’s abstraction level. The Tool uses an abstraction of the system with respect to theoryTool – its base theory. In this case, the tool is applied to

5

theoryTool (Syst), which is the model of the system Syst used by the Tool, which conformsTo the theory – i.e. the meta-model provided by the theory. Figure 1 illustrates this, in case there is a single tool per theory.

Fig. 1. Relation between System, Model, Theory and Tool

In principle, the system model, i.e. its abstraction with respect to the considered theory should be independent of the tool that will use it. If we go back to the UML example considered above we can think of two UML modelling tools. Since they both see the system in terms of UML concepts, we could believe that a model UML(Syst) could be used by both tools. The reality is, as we have seen, different, mainly because different tools usually abstract the model differently from the system. This means that we are not in an ideal setting where we have theory(Syst), i.e. a single meta model per theory, leading to a single model from a given system, which can then be used by several tools. Instead, we can talk about theoryTool (Syst). Today, related tools are using different meta-models. In this case, the typical way to connect the tools to ensure interoperability is through model translations / transformations between models corresponding to various tools. This can happen on meta-model level but also on syntax level. This approach has some obvious drawbacks. One of the most critical is that the integration problem is solved on particular cases and it is neither extensible nor reusable. Moreover, the number of transformations to be considered is in the order of n2 for n tools. We propose a different point of view: instead of considering that we have a single meta-model corresponding to the theory, we consider that different tools actually correspond to different meta-models, which is as we have seen often the case in practice. This means that we have theoryTool1 , theoryTool2 , ... , theoryTooln as a set of related meta-models, each corresponding to an actual tool. We also consider that we have in fact a single model that corresponds to a given system. In this setting, in order to integrate different tools based on the same theory, we have to properly define the conformity relationship relating the model to the meta-models corresponding to these tools, and to find the techniques to exploit this relationship.

6

When describing the models, meta-models and their mutual relationships, the classical picture used is that of an edge-up pyramid, with meta-models on top of models, meaning that a model corresponds to a single meta-model and each meta-model may have several models conforming to its definition. This is the classical view of the model – meta-model relationship, which was already presented in the first versions of the UML standard. It occurs again in the last versions, and is discussed in more detail in [13]. We believe that this is not the only possible view of the relationship model – meta-model, and that for pragmatical reasons we need to center everything on models. Indeed, models can exist even if their corresponding meta-model(s) was (were) never defined. OCL [22] was first defined by a grammar and some text. Only recently, a meta-model of the language was standardized, and several meta-models of OCL exist, defined by different authors for various needs [25] [3]. One single OCL expression - which in the presence of an OCL meta-model corresponds to an OCL model - is therefore conforming to various meta-models. Similarly, a UML model dealt with by various tools each based on a different meta-model is in fact an instance of each of these meta-models. Figure 2 compares our model-centric view with the classical pyramid-shaped view of the tree layered (model example, model, and meta-model) architectures.

Fig. 2. Comparative view of two architectures

The good news is that there is no need to agree completely on a common meta-model, in fact it is only necessary to agree on the joint parts of the metamodel. If this is done, each tool can select the parts it can handle and run its analysis on them. The remaining parts are simply ignored. An example for this

7

is ignoring the temporal properties of a specification and just analyzing the rest of it. This situation is readily handled with meta-models. We can define the core part of the language using a meta-model, and extend this meta-model according to the needs of the individual tools. In this case, it is this core that works as a unifying layer between the two tools. In a meta-model defined modularly, different parts of the meta-model could address different needs. For instance, there could be a meta-model module corresponding to the basic concepts dealt with by the meta-model, a module corresponding to relationships and constraints between model elements that complete the structural semantics, a module with the elements needed for the dynamic semantics, etc. Depending on their own focus, tools could use one or several of these modules. Moreover, it is not necessary that the tools know about the extensions the other tool is doing, since they will anyway ignore the meta-model module dealing with this part. On the other hand, a tool handling several extensions must obviously know the complete set of extensions. Note also, that it is necessary to agree upon (e.g. through standardization) the extensions that are handled by more than one tool. In the long run, this may lead to standardizing the whole language.

4

Example: Grammars for first order predicate calculus

In order to compare different tools handling the same theory, we consider the example of grammars, mainly because they are well-understood and the existing tools handling them are known. We focus on two tools as examples: bison [11] as an example of an LR tool and ANTLR [23] as an example of an LL tool1 . Both of them have different ideas about what are good and bad grammars, but both use the concept of a grammar to express their input. Considered as such, grammars are of course on the level of a meta-model or a language. In order to really look at a concrete example, we also need a sample grammar. 4.1

Application: First Order Predicate Calculus

We have taken the first order predicate calculus (PC1) as a sample grammar. In PC1 we have constants, which are true, f alse and integer numbers. Furthermore we have the operators ∧, ∨, ⇒, ⇐⇒ , ¬. We use parentheses to indicate precedence and we have universal (∀) and existential (∃) quantification. We use variables to be bound and allow functions. This leads to the following grammar given as EBNF. formula ::= con |0 (0 formula 0 )0 | unop formula | formula binop formula | 1

LL and LR are special classes of grammars that can be used to generate tools, such as compilers. See [1] for details.

8

unop binop quant var arguments

quant var formula | name 0 (0 [ arguments ]0 )0 ::= not ::= and | or | impl | equ ::= forall | exists ::= name ::= { formula 0 ,0 } formula

Of course, we do not want to handle this on the level of syntax, but on the meta-model level as modelled in figure 3 in UML.

Fig. 3. Grammar Meta-model

The meta-classes correspond to the basic notions present in a grammar, such as Terminal, NonTerminal, ProductionRule, Repetition, TermSequence, OptionalTerm, etc. The associations highlight the main relations existing between these concepts. The grammar meta-model contains the understanding of grammars in terms of EBNF. It is best to use a high-level notation like EBNF, because the higherlevel constructs should be identified explicitly and thus allow an easy conversion into other formalisms. In general, it is easier to translate from higher level to lower level constructs than the other way round. Using this as a model of the grammar, we can dive into the tools and their understanding of the grammar. Please note that the description given above is not yet complete, we will add some more detail afterwards. 4.2

Yacc Grammar

For bison [11], the successor of yacc [19], the above grammar would not be a proper input. Still, the grammar above can be formatted according to the needs of yacc as follows.

9

%token CON NAME NOT AND OR IMPL EQU FORALL EXISTS %% formula: CON | ’(’ formula ’)’ | unop formula | formula AND formula | formula OR formula | formula IMPL formula | formula EQU formula | quant var formula | NAME ’(’ opt_arguments ’)’ ; opt_arguments: /* empty */ | arguments ; unop : NOT ; quant : FORALL | EXISTS ; var : NAME ; arguments : any_formula formula ; any_formula : /* empty */ | any_formula formula ’,’ ; Delivering this specification to bison leads to several error messages due to ambiguities (called conflicts in bison) in the grammar. For the considered grammar, there are three kinds of problems: – If more than one binary operator is used in a formula, there must be a rule stating which to apply first. This is given in terms of a precedence relationship established between these operators. – Similarly, there is a need for a precedence for the unary operator in relation to the binary operators. – Finally, there is a need for a precedence for quantification. It is straightforward how to solve these ambiguity problems. The following lines are meant to do this: %left EQU %left IMPL %left OR %left AND %nonassoc UNARY_NOT UNARY_QUANT %% formula: ... | unop formula %prec UNARY_NOT | quant var formula %prec UNARY_QUANT | ... ; After these changes, bison is able to produce a parser for the considered language without any more problems. Having looked at the way bison handles the grammar, we are also able to pinpoint the bison way of looking at grammars in a corresponding meta-model in figure 4.

10

Fig. 4. Bisons Meta-model (partial)

4.3

ANTLR Grammar

ANTLR starts also with a grammar for its representation. We will only consider the parser part of the grammar, not the lexical entities. The EBNF grammar, provided in the previous section, can be translated to ANTLR as follows. class P extends Parser; formula : formula EQU formula | formula IMPL formula | formula OR formula | formula AND formula | NOT formula | quant var formula | CON | OPEN_PAR formula CLOSE_PAR | NAME OPEN_PAR ( arguments )? CLOSE_PAR ; unop : NOT ; binop : AND | OR | IMPL | EQU ; quant : FORALL | EXISTS ; var : NAME ; arguments : formula ( COMMA formula )+ ; As you see, the description is again similar to the original presentation. However, also ANTLR reports some problems as follows. – The same precedence problems as with yacc appear also with ANTLR. – ANTLR cannot handle left recursion because it is an LL parser generator2 . So we have to include the same precedences here and also to handle the recursion. Fortunately, there are established methods how to do this, so we can just assume the following change to the ANTLR. 2

See again [1] why this is the case.

11

class P extends Parser; formula : formula0 ; formula0 : formula1 ( EQU formula1 )? ; formula1 : formula2 ( IMPL formula2 )? ; formula2 : formula3 ( OR formula3 )? ; formula3 : formula4 ( AND formula4 )? ; formula4 : NOT formula5 | quant var formula5 ; formula5 : CON | OPEN_PAR formula CLOSE_PAR | NAME OPEN_PAR ( arguments )? CLOSE_PAR ; ... Also for ANTLR, we can show the way it handles grammars in a meta-model as shown in in figure 5. In this meta-model, we refer back to the general grammar meta-model, as ANTLR uses some kind of EBNF for grammar representation.

Fig. 5. ANTLRs Meta-model (partial)

4.4

Back to the Grammar

After two tools have complained about our grammar, with respect to dealing precedence, we probably should repair the problem in the original model. This means we need a way to express precedences. We could do it like this: prec( ⇐⇒ ) < prec(⇒) < prec(∨) < prec(∧) < prec(¬) = prec(quant) Finally, we have to state the associativity of the binary operations, which is left for all of them. Of course, we also have to include the precedences in the meta-model, but these can be added easily, for example as given in figure 6. Inclusion of precedences does also show how a meta-model extension could look like.

5

Related Work

The work described here is related to several areas. Therefore, we have grouped the related work into the following categories: efforts of clarifying the relationships of concepts existing in the context of MDA/MDE and tool integration approaches.

12

Fig. 6. Extension of the Meta-model with Precedences

5.1

Study of the MDA/MDE specific concepts

The basic notions related to MDA/MDE are intensively studied by various authors. The basic notions used in this context are those of model, meta-model, model realization (or instanciation) and the relationship between these notions. These notions are of course not new, and they were not invented by the OMG. The database community is traditionally using notions such as meta data, which is an equivalent of the meta-model. The MDA/MDE have given a more important place to these concepts and have them included in a wider framework for software development. [12] defines the basic concepts of MDA/MDE (model, meta model, model transformation and their relationships) in terms of set theory. The aim of this approach is to formalize and therefore allow a better understanding of MDA/MDE concepts. [24] starts from the idea that the MDA/MDE technology still suffers from a terminology confusion, due to the presence of a lot of concepts that have no precise definition, of classical misconception (such as the four level abstraction level pyramid as also discussed in section 3). The authors give a more precise definition to these concepts and discuss on the appropriateness of the instanceOf relationship between meta-models and models. [6, 2, 27] study the relationships between various abstraction levels in the model – meta-model hierarchy, in particular with respect to the instanceOf kind of relationship. 5.2

Tool integration approaches

As we have shown in section 3, meta-models can offer a practical way to the concrete problem of tool integration. This problem is a classical and recurring issue in MDA/MDE since more and more tools are needed in the process of model based software development, an only a few of these tools are tightly related. For the rest, we need practical means of integration. The most important techniques used today for tool integration are: – Point-to-point integration: usually done while focusing on a specific tool. In order to allow a higher range of applicability, tool providers connect to other

13

tools and frameworks. Often these connections are provided on an ad-hoc basis using existing tools. The combination is made theoretically sound just as far as the combined tools are concerned. The most often used technology for these combinations are language transformations. An example in this context is the integration between SDL and ASM provided by the SDL formal semantics [17] which defines an integration between SDL and ASM. – Kernel language based integration: some tools take the challenge to provide a very general exchange format that can be mapped to / from different concrete notations. One example for this is the IF tool [8] that allows to analyze general state-transition systems. This tool was used as intermediary format for system specifications using various modelling techniques, e.g. SDL, UML, and IF itself. – Federator meta-model based integration: the idea of this approach is to integrate several languages that all dealt with the analysis of the same kind of systems, coming from very different origins. The most prominent example for a combined meta-model is without doubt the UML language [21]. Indeed, the UML language consists of several sub languages (use cases, state machines, OCL, etc.), whose integration is not fully described. In spite of its problems, the integration and agreement achieved with the definition of UML can be considered a success taking into account the variety of the languages, techniques and viewpoints taken into account.

6

Concluding Remarks

MDx technology promotes the use of models in software development, in order to abstract away as much as possible from low-level technical details and focus on the software’s model. This approach gives more weight to models in the context of software development: it asks to be able to reason at model’s level, process the information at model’s level, compose various models, etc. In this paper we present a new view on the place and role of meta-models. In this perspective, the role of meta-models should be to facilitate the use of models. This addresses precisely one of the open areas in the MDx: the integration of different kinds of models in order to be able to use them jointly. Our new view on meta-models and their role is the basis of a new methodology for integration of tools based on ad-hoc standards that can be further developed into a real standard. Note that we do not argue for an overall standard, whose definition may be an unrealistic goal. Instead, we believe ad-hoc standards of small meta-models designed for a particular purpose are a more realistic target and this can serve the goal of tool integration. We develop a technique for integrating different validation tools using a meta-modelling approach. This technique consists in meta-modelling the base theories of the various tools. A modular definition of a meta-model, structured around a core containing the key concepts of the base theory, allows for an incremental integration. Indeed, the common core concepts of all the tools related to the considered theory have to be unified, and represent the set of concepts the integration really

14

needs to agree upon. Moreover, it is only necessary to agree on the parts of the meta-model that are used by several tools. The parts of the meta-model not supported by a tool (e.g. due to features that are not implemented or to simpler models) are simply ignored. One of the main interests of our technique is to lift up the abstraction level and position the integration efforts at the level of models and meta-models. This allows to concentrate on basic concepts of the theory and their mutual relationships. Although the concepts of model and meta-model are not new, it proves that the relationship between them needs to be studied further. We believe that a pragmatic definition of this relationship helps in the tool integration. Many things remain still to be done. From our point of view, the most important next step is to work on a working platform for integration that allows experiments with real tools and languages. We have already started work using the Eclipse platform [10] and the EMF framework [15].

References 1. Alfred V. Aho, Ravi Sethi, and Jeffrey D. Ullman. Compilers – Principles, Techniques, and Tools. Prentice Hall International, 2003. uhne. The essence of multilevel metamodeling. In M. Gogolla 2. C. Atkinson and T. K¨ and C. Kobryn, editors, UML 2001, volume 2185, pages 19–33. LNCS, 2001. 3. Thomas Baar and Reiner H¨ ahnle. An integrated metamodel for OCL types. In R. France, editor, OOPSLA 2000 Workshop Refactoring the UML: In Search of the Core, Minneapolis, Minnesota, USA, October 2000. 4. Jean Bezivin. In search of a basic principle for model driven engineering. CEPIS, UPGRADE, The European Journal for the Informatics Professional, V(2):21–24, 2004. 5. Jean Bezivin and Olivier Gerbe. Towards a precise definition of the OMG/MDA framework. In Proceedings of the 16th IEEE International Conference on Automated Software Engineering (ASE’01), pages 273– 280, November 2001. 6. Jean B´ezivin and Richard Lemesle. Towards a true reflective modeling scheme. In Walter Cazzola, Robert J. Stroud, and Francesco Tisato, editors, Reflection and Software Engineering, 1st OOPSLA Workshop on Reflection and Software Engineering, Denver, CO, USA, November 1999, volume 1826 of LNCS, pages 21–38. Springer, 2000. 7. E. B¨ orger and R. Stark. Abstract State Machines - A Method for High-Level System Design and Analysis. Springer Verlag, 2003. 8. Marius Bozga, Susanne Graf, Ileana Ober, Iulian Ober, and Joseph Sifakis. The IF toolset. In SFM-04:RT 4th Int. School on Formal Methods for the Design of Computer, Communication and Software Systems: Real Time, number 3185 in LNCS, pages 237–267, 2004. 9. C. A. Petri. Kommunikation mit Automaten. Schriften des IIM Nr. 2, Bonn: Institut f¨ ur Instrumentelle Mathematik, 1962. Second Edition: New York: Griffiss Air Force Base, Technical Report RADC-TR-65–377, Vol.1, 1966, Suppl. 1, English translation. 10. Jim d’Anjou, Scott Fairbrother, Dan Kehn, John Kellermann, and Pat McCarthy. The Java Developer’s Guide to Eclipse. Addison-Wesley, 2004.

15 11. Charles Donnelly and Richard Stallman. Bison, The yacc-compatible Parser Generator. See also http://dinosaur.compilertools.net/bison/index.html. 12. Jean-Marie Favre. Towards a Basic Theory to Model Model Driven Engineering. In Workshop on Software Model Engineering, WISME 2004, joint event with UML2004, oct 2004. 13. Jean-Marie Favre. Foundations of model (driven) (reverse) engineering : Models – episode i: Stories of the fidus papyrus and of the solarus [online]. In Jean Bezivin and Reiko Heckel, editors, Language Engineering for Model-Driven Software Development, number 04101 in Dagstuhl Seminar Proceedings. Internationales Begegnungs- und Forschungszentrum (IBFI), Schloss Dagstuhl, Germany, 2005. 14. Jean-Marie Favre and Tam Nguyen. Towards a megamodel to model software evolution through transformations. ENTCS, 127(3):59–74, 2005. 15. Catherine Griffin. Using EMF, 2003. See also http://www.eclipse.org/articles/Article-Using EMF/using-emf.html. 16. John E. Hopcroft, Rajeev Motwani, and Jeffrey D. Ullman. Introduction to Automata Theory, Languages, and Computation. Addison-Wesley, 2000. 17. ITU-T. ITU-T Recommendation Z.100: Specification and Description Language (SDL) - Annex F. International Telecommunication Union, 1999. 18. ITU-T. ITU-T Recommendation Z.100: Specification and Description Language (SDL). International Telecommunication Union, August 2002. 19. Stephen C. Johnson. yacc – Yet Another Compiler-Compiler. See also http://dinosaur.compilertools.net/yacc/index.html. 20. OMG. Model Driven Architecture Guide. OMG document, Object Management Group, 2003. Available at http://www.omg.org/mda/. 21. OMG. Unified Modeling Language Specification, version 2.0. OMG document, Object Management Group, 2004. Available at http://www.omg.org/technology/documents/formal/uml.htm. 22. OMG. OCL 2.0 Specification. Object Management Group, June 2005. ptc/200506-06. 23. T. J. Parr and R. W. Quong. ANTLR: A predicated-LL(k) parser generator. In Software – Practice and Experience, number Vol. 25(7). ACM Press New York, 1995. 24. Arend Rensink. Subjects, models, languages, transformations. In Jean Bezivin and Reiko Heckel, editors, Language Engineering for Model-Driven Software Development, number 04101 in Dagstuhl Seminar Proceedings. Internationales Begegnungs- und Forschungszentrum (IBFI), Schloss Dagstuhl, Germany, 2005. 25. Mark Richters and Martin Gogolla. A metamodel for ocl. In UML’99: The Unified Modeling Language - Beyond the Standard, Second International Conference, Fort Collins, CO, USA, October 28-30, 1999, Proceedings, volume 1723 of LNCS, pages 156–171. Springer, 1999. 26. Ed Seidewitz. What models mean. IEEE Software, 20(5):26–32, 2003. 27. D´ aniel Varr´ o and Andr´ as Pataricza. Metamodeling mathematics: A precise and visual framework for describing semantics domains of uml models. In J-M J´ez´equel, H. Hußmann, and S. Cook, editors, UML 2002 - The Unified Modeling Language, 5th International Conference, Dresden, Germany, September 30 - October 4, 2002, Proceedings, volume 2460 of LNCS, pages 18–33. Springer, 2002.