Metamodeling has become a major topic in software engineering research [6,7,16]. There are, however, a lot of discussions about central notions in connection with metamodels like potency or clabject where no final conceptual definition has been achieved. On the other hand, software tools for metamodeling are beginning to be developed [9,2]. Metamodeling is closely connected to multi-levels models because the instantiation of a metamodel is a model. That model, when viewed as a type model, may be instantiated again and can then be viewed as an instance model. Proceeding this way, at least three model levels arise. This paper discusses two ways to establish the connection between two levels in multi-level models. The first approach uses ordinary associations and generalizations under the assumption that the multi levels are represented in one UML and OCL model. The second approach views a middle level model both as a type model and as an instance model and introduces operations in order to navigate between the type and instance level. The paper reports on some experiments that have been carried out. The first approach joins the metamodels of several levels into one model as in our previous work [12]. Details about the first approach can be found in [13]. The second approach has not been put forward in a paper yet. Our work has links to other related or similar approaches. The tool Melanie [2] is designed as an Eclipse plug-in supporting strict multi-level metamodeling and support for general purpose as well as domain specific languages. Another tool is MetaDepth [9] allowing linguistic as well as ontological instantiation with an arbitrary number of metalevels supporting the potency concept. In [16] the authors describe an approach to flatten metalevel hierarchies and seek for a levelagnostic metamodeling style in contrast to the OMG four-layer architecture. The approach in [14] also transforms multi-level models into a two-level model and focusses on constraints. Similar to our approach employing UML and OCL, the work in [17] uses F-Logic as an implementation basis for multi-level models including constraints. A conceptual clean foundation for multi-level modeling is discussed in [8].
[4] studies model constraints and [3] discusses multi-level connections in presence of a multi-level architecture distinguishing between a linguistic and an ontologic view on modeling. The structure of the rest of the paper is as follows. Section 2 gives a small example for establishing the multi-level connection with associations and generalizations. Section 3 discusses the second approach that uses operations to connect the multi-levels. The contribution is closed with a conclusion and future work in sect. 4.
The first approach connects multi-levels with usual model elements: associations and generalizations. The example in Fig. 1 shows a substantially reduced and abstracted version of the OMG four-level metamodel architecture with modeling levels M0, M1, M2, and M3. Roughly speaking, the figure states: Ada is a Person, Person is a Class, and Class is a MetaClass. The figure does so by formally building an object diagram for a precisely defined class diagram including an OCL invariant that requires cyclefreeness when constructing instance-of connections. The distinction between MetaClass and Class is that when MetaClass is instantiated something is created that can be instantiated on two lower levels whereas for Class instantiation can only be done on one lower level. The model has been formally checked with the tool USE [11,10]. In particular, we have employed the features supporting UML generalization constraints as discussed in [1,15]. Concepts on a respective level M x are represented in a simplified way as a class M x . All classes M x are specializations of the abstract class Thing whose objects cover all objects in the classes M x . On that abstract class Thing one association Instantiation is defined that is intended to represent the instance-of connections between a higher level object and a lower level: an object of a lower level is intended to be an instance of an object on a higher level. The association Instantiation on Thing (with role names instantiater and instantiated) is employed for the definition of the associations Typing0, Typing1, and Typing2 between M x and M x+1 all having roles typer and typed. The role typer is a redefinition of instantiater, and typed is a redefinition of instantiated. The multiplicity 1 of typer narrows the multiplicity 0..1 of instantiater. Metamodeling means to construct models for several levels. The metamodels on the respective level should be described and modeled independently (e.g., as M0, M1, M2, and M3). The connection between the models should be established in a formal way by a typing association (e.g., Typing0 gives a type object from M1 to a typed object from M0). The Typing associations are introduced as redefined versions of the association Instantiation from (what we call) a multi-level superstructure. This superstructure contains the abstract class Thing which is an abstraction of all metamodel elements across all levels and additionally contains the association Instantiation and accompanying constraints. Because Instantiation is defined as union, an Instantiation link can only connect elements of adjacent levels, i.e., the Typing x links are level-conformant and strict. The aim of the devices in the superstructure is to establish the connection between metamodel levels in a formal way and to provide support for formally restricting the connections.
The second approach for connecting multi-levels is based on viewing one model both as a type model and as an instance model. In Fig. 2 an example as elaborated with USE [11,10] is shown. The object diagram on the left side is essentially equivalent to the class diagram on the right side. The displayed example can be realized in USE in this way, however, there is currently no option to connect the two equivalent representations in form of the class diagram and the object diagram. Additional features would be needed. In Fig. 4 In these examples it is assumed that there is exactly one key attribute for each class. When these parameterized features become actualized, then in this case the following invariants would be required. It is an open question whether the actualization is implicit or explicit: The actualization mechanism may be considered as being implicit for all actual features that are available in the model, or the actualization mechanism may be considered as being something the modeler has to explicitly ask for.
This paper is based on the idea to describe different metamodels in one model and to connect the metamodels either (a) with generalizations and associations employing appropriate UML and OCL constraints or (b) with special operations allowing to navigate between different multi-levels in a model. The paper does not claim to present final results, but some experiments and ideas in the context of multi-level models. Future research includes the following topics. We would like to work out for our approach formal definitions for notions like potency or strictness. The notion of powertype will be given special attention in order to explore how far this concept can be integrated. Our tool USE could be extended to deal with different metamodel levels simultaneously. So far USE deals with class and object diagram.
In essence, we think of at least a three-level USE (cubeUSE) where the middle level can be seen at the same time as an object and class diagram, as has been sketched in the second approach in this paper. Furthermore, larger examples and case studies must check the practicability of the proposal.