Model / Meta-Model / MOF

This section defines the terms model and meta-model and relates them to the MDA ap- proach defined by the OMG.

Model Models play the central role in MDSD. Despite their importance, no established

definition in the context of MDSD could be found. A definition, which best fits the under- standing of a model in this thesis, has been published on the ModelWare website. This definition is used in the remainder of this thesis.

Definition: Model (ModelWare,2007) ”A formal representation of entities and relationships

in the real world (abstraction) with a certain correspondence (isomorphism) for a certain purpose (pragmatics).”

Uhl (2007a) gives a similar definition in German in the ”Handbuch der Software-

Architektur” (Reussner and Hasselbring, 2006). He uses classical characteristics of a model identified byStachowiak(1973) and transfers these concepts to software models. As these characteristics are similar to the characteristics in the given definition, the fol- lowing discusses the three characteristics available in ModelWare’s definition.

According to this definition, models have three main characteristics: abstraction, iso- morphism, and pragmatism. Abstraction is the property of a model to remove details of the modelled object. It is a representation of the object which is abstracted with respect

to certain attributes. The selection of the model’s attributes is guided by the aim of the model (cf. with the pragmatism aspect).

A model can be seen as the result of a projection (in a mathematical sense). The real world object is projected onto its model representative by removing the unconsidered attributes. This projection is an isomorphism if the projection of the real world entities on the model entities still allows conclusions to be drawn from the model entity onto the real world entity with respect to the aim of the model. The term refers to the equivalence (iso = equal, morph = shape) between the model and the real world entity.

A projection is pragmatic if its definition is done based on a well defined aim. Common aims include easing the understanding of complex structures or deriving properties based on some reasoning theory.

Example To give an example, the following discusses a software model with respect

to the given characteristics. An interface protocol model based on finite state machines (FSM) fulfils the characteristics. FSM based interface models allow describing the set of valid call sequences which can be processed by an interface. Transitions represent service calls, states the time between service calls. The set of words accepted by this FSM is equivalent to the call sequences accepted by the interface.

This model is an abstraction of the real world object as it reduces an interface to the set of accepted call sequences. For example, technical details, concurrency aspects, or extra-functional properties are disregarded. It is an isomorphism because the set of call sequences accepted is the same for the model entity as for the real interface. Sometimes, FSM’s might not be powerful enough to model the set of valid sequences in a way which can be translated to the real world object (for example, a stack’s protocol can not be mod- elled by a FSM). This would violate the isomorphism characteristic. The FSM protocol model is pragmatic if it is combined with protocol interoperability tests for example. In- teroperability checking can be performed using FSMs in an efficient way. Hence, FSMs are a pragmatic model for the task of performing protocol interoperability checks (cf.

Becker et al.(2004)).

Meta-Model The website metamodel.com (metamodel.com, 2007), defines a meta-

model as follows:

Definition: Meta-Model (metamodel.com,2007) A metamodel is a precise definition of the

constructs and rules needed for creating semantic models.

Definition: Meta-Model (Uhl, 2007a) A meta-model is a model defining a set of models which are called instances of the meta-model.

Common understanding of the definitions is that a meta-model somehow charac- terises a set of models which are instances of the meta-model. In the context of the first definition, an instance would be a model which has been built using the constructs de- fined in the meta-model and is not violating the rules associated with these concepts.

Conforming to the conceptual models introduced byV ¨olter and Stahl(2006), a meta- model defines at least rules for the concepts depicted in figure2.4.

Meta-Model

Syntax

Static

Semantics SemanticsDynamic Abstract

Syntax Concrete Syntax

* 1

*

Semantics

Figure 2.4: The parts of a meta-model

According to figure 2.4, rules describing a meta-model instance are either syntactic or semantic rules. Syntactical rules can be split further into rules on concrete syntaxes and rules for the abstract syntax of the model instance. The abstract syntax of a model represents model instances in the concepts of the meta-model independent of concrete machine or encoding specifics. Consequently, a concrete syntax is a set of rules which specifies the encoding of the abstract concepts. These terms are commonly used in com- piler construction: The concrete syntax of programming languages is often defined as text files built according to certain structuring rules given as grammar. The abstract syntax of a programming language is usually represented in abstract syntax trees.

The static and the dynamic semantics form the parts of the semantics of a meta-model. Static semantic is defined as rules which further constraint the set of syntactical valid model instances. For example, if the model syntax allows to have an arbitrary amount of wheels for a car object then a static semantic rule could constrain the amount to five wheels (4 normal and one spare). The static attribute refers to the fact that the constraints can be checked without ”executing” the model, i.e., without knowing its intention. Dy- namic semantics finally specifies the intention of the model concepts, i.e., how to interpret the model instances in a given context. For programming languages, static semantics con-

tain for example type checks done by the compiler while dynamic semantics define what the program does during its execution.

However, the borderline between the different types of rules is not always strict. Con- sider again the example with the car and its wheels. It would have been also possible to specify the constraint as part of the syntactical rules by only allowing cars with five wheels for syntactic valid model instances.

Another major issue is the specification of the dynamic semantics of a meta-model. For programming languages, formal calculi like the lambda- or pi-calculus are applied. But for domain specific languages (DSLs), which are of central interest in the OMG’s MDA approach, the semantics of elements of the DSL have to be described which in many cases lack a formal definition. For example, in an insurance DSL, terms like insurance contract are defined by laws and not formal calculi. Hence, natural language based definitions are used despite their inherent imprecision.

Technical Foundation In the MDA approach published by the Object Management

Group (OMG)(2006c) a set of technical foundations is defined. Specifications are avail-

able for many of the technologies needed to implement a tool chain for specifying meta- models, modelling, and transforming the resulting model instances. The standardisation efforts are directed mainly at allowing interoperability on the model level between tools developed by different vendors. As it is assumed that most of these technologies are applied in a model-driven development process the essential standards are introduced briefly and existing implementations are referenced.

The Meta Object Facility (MOF) The Meta Object Facility (MOF) (Object Management

Group (OMG),2006d) is a meta-meta-model which allows the definition of meta-models

and forms the central element in the OMGs MDA approach. Initially, the MOF emerged in the context of the Unified Modelling Language (Object Management Group (OMG),

2005c) in which it has been applied to model the UML. Its core concepts are similar to

the concepts available in UML class diagrams, but as they are on different meta-levels the concepts are different. Based on its roots in UML class diagrams, concepts like classes, associations, and multiple inheritance are available. MOF also uses a similar concrete syntax as UML class diagrams, which can sometimes lead to confusion. In order to avoid this kind of confusion, meta-models are explicitly marked in their figure captions in the remainder of this thesis.

The following discusses briefly the difference between EMOF and CMOF introduced in recent MOF versions. This helps to understand the meta-model presented in section3

MOF, which are needed for the prototypical realisation of this thesis’ concepts, are intro- duced, i.e., XMI, JMI, or OCL.

Currently, a new version of the MOF standard is being finalised (MOF 2.0). In MOF 2.0, the MOF is split into two parts: Essential MOF (EMOF) and Complete MOF (CMOF). EMOF is ”[..] the subset of MOF that closely corresponds to the facilities found in OOPLs and XML” (see Object Management Group (OMG) (2006d, p. 43)). The idea of EMOF has been introduced in the MOF specification by IBM based on the experience gained in implementing the MOF 1.x standard. In the course of implementing MOF, the devel- oper team in charge realised that implementing the full MOF standard would lead to performance drawbacks. Hence, the team focused on the concepts they considered as required frequently. The resulting implementation is the Eclipse Modelling Framework (EMF) (Eclipse Foundation,2006) and its meta-model ECORE (see figure2.5). The subset of MOF found to be ”essential” for EMF has been proposed for standardisation as EMOF. As a consequence, the EMF developers announced to deliver a EMOF compatible im- plementation soon after the final MOF2.0 specification will be available. In contrast, the CMOF contains the a revision of the model elements available in MOF 1.x. A remarkable difference between EMOF and CMOF is the availability of first-class associations which is only true for CMOF.

0..n EModelElement ENamedElement EAnnotation EFactory EClassifier ETypedElement EPackage EClass EDataType EEnumLiteral 0..n EOperation EParameter EEnum EStructualFeature EReference EAttribute 1 1 0..n 0..n 0..1 0..n 0..n 0..n 0..n 0..n 0..1 0..n 0..n 0..n

Figure 2.5: The ECORE meta-model

models between different tools, a machine readable concrete syntax is needed. For this, the MOF XML Metadata Interchange (XMI) mapping specificationObject Management Group

(OMG) (2006b) defines a mapping of model instances to a XML serialisation and vice

versa.

The Java Metadata Interface (JMI) specification contains a mapping of MOF instances to Java interfaces which can be used to create and manipulate model instances of a MOF- based meta-model. MOF-based code-generators generate Java classes based on MOF in- stances to store model instances as object graphs. The EMF code generator (Eclipse Foun-

dation, 2006) used to implement the meta-model presented in this thesis is an example

for a JMI implementation.

The Object Constraint Language (OCL) (Object Management Group (OMG), 2006e) serves as a mean to further restrict the set of valid UML as well as MOF model instances. In the later case the available OCL elements include only a subset of the whole OCL spec- ification (the one which is based on the common core between UML and MOF). Designers of meta-models frequently use OCL to define the static semantics of their meta-models. The expressive power of OCL is that of a three-level Kleene logic with equality according

toBrucker and Wolff(2002). Support for OCL in tool implementations is still immature.

The Eclipse Technology project has developed a plugin (Eclipse Foundation, 2007a) to add OCL support to the Eclipse UML2 plugin. Support for OCL expressions in EMF can be added manually by enhancing EMF’s code generator.