On Models And Model Transformations

In his article in the ``Software and Systems Modeling'' journal Jochen Ludewig pointed that although we, humans, use models all the time, it is difficult to define what a model is. ``Endless discussions have proven that there is no consistent common understanding of models'', — he writes [86]. For the purpose of this thesis models must have one essential property, namely, the ability to be automatically processed by a computer. Thus, I will use the following definition of a model found in the book by A. Kleppe et al. [78]. The definition consists of the two parts:

For other possible definitions the reader can refer to the thesis by Elīna Kalniņa, where she has done extensive work on investigating various sources, while seeking for a model definition [75].

Thus, abstraction removes irrelevant details. The number of details is related to the notion of abstraction level. The following definitions can be found in the book by A. Kleppe et al. [78]:

Although we can continue to add other meta-s, in many cases a meta-metamodel is able to describe itself. This observation is called the three-level conjecture, where the three meta-levels are the model level (M1), the metamodel level (M2), and the meta-metamodel level (M3); the fourth level is not needed, since it equals to M3. These levels are sometimes called layers [52].

In 2002 I. Kurtev, J. Bézivin and M. Aksit have made an observation that the three-level conjecture can be applied to numerous technologies. The concept of technical space was introduced to identify such technologies [81, 52]. In a technical space, usually a fixed meta-metamodel at Level M3 provides a basis for defining metamodels at Level M2, which, in their turn, define models at Level M1. This chain can be extended by saying that models at Level M1 define objects at Level M0, which are real-world objects or runtime objects of a system being modelled. For instance, UML (Unified Modeling Language) Infrastructure is based on such Four-level Metamodel Hierarchy [#bib_uml_infrastructure, Sections 7.9--7.12]. At the same time, the border between M1 and M0 is where modelling either finishes (when M1 elements describe real objects), or changes its form (when, for example, M1 elements describe data in a database representing real world objects). In accordance with J. Bézivin and I. Kurtev, I will consider Level M0 lying outside the concept of technical space [52].

Technical spaces need to store models somewhere. The term model repository (or simply: repository) will denote a store, where models can be saved. It can be a specific data store, a simple text file, or an XML-file. Different types of repositories (even within one TS) have to be accessed differently. In some cases a repository is accessed by means of a specific parser, while in other cases — via certain API (Application Programming Interface).

Table 1 summarizes my research on technical spaces and their repositories.

Table 1: Technical spaces (TS's) and their repositories.

With a help of the ``instance of'' relation it is quite easy to demonstrate, how the need for more than three meta-levels (offered by technical spaces) arises. Douglas Hofstadter in his famous book ``Gödel, Escher, Bach'' (1979) mentions the following example [70]:

Atkinson and Kühne [46, 83, 82] noticed that actually there are two variants of the ``instance of'' relation: ``linguistic instance of'' and ``ontological instance of''. Thus, meta-levels can also be linguistic and ontological. To see the difference between these two types of meta-levels, refer to Figure 1.3. Figure 1.3(a) is an example of UML Four-level Metamodel Hierarchy [#bib_uml_infrastructure]. Although Level M0 (a level of real world objects) lies outside MOF TS, it is depicted for informative purposes. ECore is a possible meta-metamodel for Level M3 (only a small part of it is depicted in Figure 1.3(a)). Level M2 contains a UML-like metamodel described in ECore. For this example it is essential that the M2 Level metamodel is able to describe both classes and objects, see classes Class and Object. Level M1 contains a sample model, which conforms to the UML-like metamodel from Level M2.

All the three levels (M1-M3) are linguistic meta-levels, since the meta-metamodel from Level M3 can be considered a language for specifying metamodels at Level M2, and each metamodel from M2 can be considered a language for specifying models at M1. However, if we look at Level M1 more narrowly, we can see that it can be split into two levels, where UML-style objects occupy one level, and UML-style classes occupy another level (Figure 1.3(b)). The borderline is defined by the ``type'' relation from Level M2. These new levels are called ontological meta-levels. They are denoted $O_j$ and $O_{j+1}$ in Figure 1.3(b), while linguistic meta-levels (M1-M3) have been renamed to $L_i,L_{i+1},$ and $L_{i+2}\mathrm{.}$ The pivot indices $i$ and $j$ have been introduced here to be independent on any particular absolute numbering. For the purposes of this thesis, only relative arrangement of (both linguistic and ontological) meta-levels will matter.

Figure 1.3(c) adds one more ontological meta-level $O_{j+1}$ by introducing the MetaClass concept at $L_{i+1}$. However, in order to express the six-meta-level example by D. Hofstadter, we must add at least three more meta-classes at $L_{i+1}$ (in order the total number of ontological meta-levels become six). Figure 1.3(d) shows that instead of introducing meta-class(es), multiple ontological levels can be described by means of the ``type'' relation from Class to Class at $L_{i+1}$. This relation can be used as many times as needed, thus, creating a chain of ontological meta-levels as in the example by D. Hofstadter (the ``lowest'' meta-level can be linked to the chain by the ``type'' relation between Object and Class).

In Figure 1.3(d), Class can also be made a subclass of Object at $L_{i+1}$ (Atkinson and [45] introduce the term ``clabjects'' [from class+object] for such classes). In this case, the ``type'' relation between Object and Class is not needed any more, since its role is played by the ``type'' relation from Class to Class.

In some cases ontological meta-levels can be mixed. In Figure 1.3, a class Person has been added. A person can be linked to a dog by means of the ``owner'' relation defined at Level $O_{j+1}$. A person can also be linked to a breed by means of the ``favourite breed'' relation, which crosses levels $O_{j+1}$ and $O_{j+2}$. Having a particular person Peter at $O_j$, we can see that the ``owner'' link lies in the same $O_j$ level, while the ``favourite breed'' link crosses two levels $O_j$ and $O_{j+1}$.

The theory behind the ``instance of'' relation goes even further. , Kaviani, and Hatala show that the (ontological) ``instance of'' relation can be inferred from the two other relations. They suggest to treat each class as consisting of two parts: intentional and extensional [62]. Intentional part specifies common features of objects (e.g., ``has long hair'') and is used for building abstractions; the relation between elements and the intentional part is called ``conformant to''. Extensional part represents a class as a set, to which certain elements (objects) belong; the relation between elements and the extensional part is called ``element of''. For the purposes of this thesis I do not need the ``conformant to'' and ``element of'' relations. Still, I will need both variants (linguistic and ontological) of the ``instance of'' relation.

Certain RDF/OWL meta-levels can be considered either linguistic, or ontological. In Table 1, RDF can be considered as spanning three linguistic meta-levels: the RDFS level (M3), the RDF vocabulary level (M2), and the RDF individuals level (M1). Still, RDFS permits breaking this level hierarchy, since classes may be individuals at the same time. RDFS also allows meta-levels to be mixed (as in Figure 1.3). The same refers to OWL Full and OWL 2 with RDFS semantics. Thus, we can think of RDF/OWL TS as occupying only two linguistic meta-levels: $L_2$ containing RDFS/OWL Full definition, and $L_1$ containing the pool of ontological classes and instances ($L_1$ conforms to $L_2$). In this case, $L_1$ consists of two or more ontological meta-levels, which can be mixed. To deal with different interpretations of meta-levels (whether the given level is linguistic or ontological),

I call these two groups the quasi-linguistic meta-level M3 and the quasi-linguistic meta-level M, respectively. The quasi-linguistic level M3 is fixed. In most cases, it will contain the linguistic meta-metamodel of some technical space (hence, the name ``M3''). The level M will contain all other meta-levels that are variable w.r.t. to M3 (either directly, or via other meta-levels). I call these variable levels quasi-ontological meta-levels (in reality, they may be either linguistic, or ontological meta-levels; see below). Figure 1.4 illustrates the organization of quasi-meta-levels. Figure 1.4 is similar to meta-levels depicted in Figures 1.3(c) and (d) on page elsewhere. The difference is that now we have exactly two quasi-linguistic meta-levels.

A transformation that transforms a model to a model is called a model-to-model transformation (Figure 2.1). Usually, the distinction is being made between the transformation definition (a set of rules that describe how to transform a source model into a target model [78]) and the transformation execution (a process of applying the rules at runtime). While transformation definition lies at Level M2 and is described in terms of the source and target metamodels, transformation execution is performed on models (conforming to those metamodels) at Level M1.

Traditionally, it is considered that some transformation tool is needed to execute a transformation definition [78]. However, it depends on a language, in which the given transformation definition is written. For some languages, transformation definitions can be deployed as precompiled binaries. In this case an additional supporting tool is not required. Here we can see an analogy between a program and its execution, where the program can be executed either by its own, or by a supporting virtual machine or an interpreter. For short, I will use the term transformation to refer to a transformation definition. In this sense, a transformation is like a program, while the source and target metamodels are like source and target data formats.

Besides model-to-model transformations, there are also ``something-to-model'' and ``model-to-something'' transformations. Here, ``something'' can be:

Noteworthily, repositories from Table 1 perform such ``something-to-model'' and ``model-to-something'' transformations, when loading and saving models. These transformations are tailored for storing models and are not applicable for a general case.

This subsection presented only basic classification of model transformations. For a more detailed taxonomy of model transformations, refer to works by Czarnecki, Helsen, Mens, and Van Gorp [57, 90, 91].

When OMG introduced MDA in 2001, there were no specific model transformation languages in MOF TS [93, 78]. That is why in 2002 OMG issued a request-for-proposal called MOF QVT (Query/View/Transformation) to seek for MOF-compatible transformation languages [63]. The first version of the MOF QVT standard appeared only in 2008 [64]; the current version is 1.1 (appeared in 2011) [65]. Having the standard, tools that support it are also needed. Currently, MOF QVT is supported by such tools as Eclipse M2M [8] (implementing the QVT Operational and QVT Declarative languages), SmartQVT [10] (QVT Operational), and medini QVT [40] (QVT Relational).

When the MOF QVT standard was in the development stage, many independent transformation languages appeared, and they continue to appear even now. There is a wide variety of transformation languages: textual and graphical, operational and declarative, unidirectional and bidirectional. As a rule of thumb, supporting tools for the given language are developed by the institution that developed the language. Some examples are: ATL [42, 74, 13], the Epsilon family consisting of several languages for different needs [79, 18], MOLA [76, 104], the Lx family [47, 103], lQuery [85], IBM Model Transformation Framework [59], GReAT [41, 72], GreTL [71], Tefkat [84, 29], VIATRA2 [101, 33], PTL [87], BOTL[50, 30], RubyTL [56, 5], etc. Some transformation languages such as COPE [69] and Epsilon Flock [95] are tailored for the model migration task.

It is interesting that even before the MOF QVT request-for-proposal, model transformation languages already existed in non-MOF technical spaces. In 1990-ties and in the very beginning of the XX century, the Typed Attributed Graph technical space already had graph transformation languages such as AGG [99, 4], PROGRES [97], TGG/FUJABA [96, 60, 105], and VIATRA [55, 33]. In 1999, XML TS got the standard for the XSLT 1.0 language (Extensible Stylesheet Language Transformations) intended to transform XML documents (the current version is XSLT 3.0, a working draft) [37, 38]. Even stored procedures in the Relational Database technical space can be used to describe transformations on data from database tables. In this thesis by ``transformation languages'' I mean all such transformation languages from all technical spaces (not just from MOF).

Mapping languages can be considered as an abstraction of transformation languages. They can be viewed as specialized (``domain-specific'') languages for specifying model transformations. Instead of directly specifying the instructions how to transform a source model to a target model, a mapping specifies relations between these models, usually, at a higher level of abstraction than transformation definitions do. For instance, with MALA4MDSD, a graphical mapping language developed at IMCS-UL with major contribution by E. Kalniņa [75], a mapping between two UML models can be specified easily. Languages such as D2RQ [49, 14], RDB2OWL [27], R2RML [27], and D2R MAP [48] are mapping languages between two TS's — RDB TS and RDF/OWL TS.

Mappings can be interpreted directly or translated into a lower-level transformation language for execution as ordinary transformations. The latter use-case is related to high-order transformations (HOT's), which are model transformations that perform certain actions on other model transformations. For instance, a HOT can be used for transformation synthesis from mappings (see the paper by M. Tisi et al. for applications of HOT's [100]). HOT's treat model transformations they work with as models conforming to some metamodel representing some transformation language. To provide better support for HOT's, existing transformation languages can be extended, or new languages can be invented. For example, in Template MOLA, a language for defining HOT's, the constructs for what to generate and the constructs for how to generate are expressed graphically in a MOLA-like syntax. There is no need to think about MOLA metamodel and its numerous technical details in order to specify what to generate (that would be necessary, if the ordinary MOLA was used).

In many cases a language that describes a path from one model element to other element(s) is useful. Such languages are called model navigation languages. A well-known navigation language in XML TS is XPath [34]. Microsoft DSL Tools use a similar language [53].

A navigation language can be a part of another language. For instance, the OCL language (Object Constraint Language) from MOF TS has constructs to express navigation between model elements [68]. OCL itself is a constraint language, i.e., a language for expressing constraints on model elements. OCL constraints are being used in Atlas Transformation Language (ATL) [74]. Epsilon Validation Language (EVL) uses constraints that are ``quite similar to OCL constraints'' [17].

Semantic Web is a broadening research area, which is parallel to MDE, but tightly related to it. OWL ontologies and RDF graphs can be considered as models (see RDF/OWL TS in Table 1). Besides, OWL has semantic reasoners — programs that can infer certain data from ontologies. These reasoners can be considered as specialized model transformations that are executed on models from RDF/OWL TS.

Classical types of tasks performed by reasoners are [54]:

Reasoners are based on impressible Math such as description logic. There are various OWL variations, and there is a trade-off between what can be inferred and how fast that can be done (if that can be done at all). For instance, a reasoner for OWL Lite terminates in polynomial time, a reasoner for OWL DL terminates in exponential time, reasoners for certain OWL 2 variations terminate in double-exponential time, while OWL full is undecidable [24]. Examples of commercial reasoners are OntoBroker, and RacerPro. Examples of free reasoners are Pellet (with an option to obtain a commercial license), Fact++, and Hoolet.

Semantic reasoners infer data according to the open world assumption (in contrast to the closed world assumption used, for example, in Prolog). Stefano Mazzocchi explains the difference between both assumption in one sentence [89]:

The closed world is based on the ``negation as failure'' principle, while the open world is based on the ``negation as contradiction'' principle [102]. An OWL ontology can be processed by a semantic reasoner according to the closed world assumption by adding some additional OWL statements that ``close'' the world of the ontology.