This paper discusses two ways to establish the connection between two levels in a multi-level model. The first approach uses normal 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 to navigate between the type and instance level. The paper reports on some experiments that have been carried out.
Metamodeling has become a major topic in software engineering research [
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 [
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. 2
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 [
Concepts on a respective level Mx are represented in a simplified way as a class Mx. All classes Mx are specializations of the abstract class Thing whose objects cover all objects in the classes Mx. 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 Mx and Mx+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.
Fig. 1. Ada, Person, Class, MetaClass within Single Object Diagram. In the abstract class Thing the transitive closure instantiatedPlus() of instantiated is defined by means of OCL. Analogously, instantiaterPlus() is defined for instantiater. The closure operations are needed to define an invariant in class Thing requiring Instantiation links to be acyclic. The class diagram from the left side of Fig. 1 is made concrete with an object diagram on the right side. The fact that the three associations Typing0, Typing1, and Typing2 are all redefinitions of association Instantiation is reflected in the object diagram by the three dashed links for association Instantiation with common role names instantiater and instantiated (dashed links in contrast to continuous links for ordinary links). Viewing Instantiation as a generalization (in terms of redefinition) of all Typingx associations allows to use the closure operations from class Thing on objects from classes M0, M1, M2 or M3. Thus the displayed OCL expressions and their results reflect the following facts: object Person is a (direct resp. indirect) instantiation of objects Class and MetaClass; objects Ada and Person are (direct resp. indirect) instantiations of object Class.
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 Typingx 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. 3
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 [
In Fig. 4 such a connection is indicated with (a) one operation accessing a model element through its String-valued name $_$ : String -> ModelElement and (b) one operation returning the String-valued name of a model element #_# : ModelElement -> String.
Apart from the two new operations dollar $ and sharp # some new modeling features for UML and OCL would be needed as well: (a) OCL clauses (for elements such as invariants or pre- and postconditions) should allow parameters that represent variables for model elements and (b) the new operations dollar and sharp should be allowed in expressions for model elements in clauses (e.g., for a class or an attribute). The following examples try to give an impression of the aimed functionality. parameter[rs:RelSchema] let relSchemaClass = $rs.name$ in -- in this example: $rs.name$=rs let keyAttr = $rs.attr->any(a|a.isKey=true).name$ in context relSchemaClass inv keyAttrUnique: relSchemaClass.allInstances->forAll(x,y |
x<>y implies x.keyAttr<>y.keyAttr) parameter[rs:RelSchema] let relSchemaClass = $rs.name$ in let keyAttr = $rs.attr->any(a|a.isKey=true).name$ in context x,y:relSchemaClass inv ’keyAttrUniqueIn’ + #rs#: x<>y implies x.keyAttr<>y.keyAttr 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. context Town inv keyAttrUnique:
Town.allInstances->forAll(x,y | x<>y implies x.name<>y.name) context Country inv keyAttrUnique:
Country.allInstances->forAll(x,y | x<>y implies x.name<>y.name) context x,y:Town inv keyAttrUniqueInTown:
x<>y implies x.name<>y.name context x,y:Country inv keyAttrUniqueInCountry: x<>y implies x.name<>y.name
Fig. 2. Example for Multiple Representations of Middle Level Model.
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.
12. Gogolla, M., Favre, J.M., Bu¨ttner, F.: On Squeezing M0, M1, M2, and M3 into a
Single Object Diagram. In et al., T.B., ed.: Proc. MoDELS’2005 Workshop Tool
Support for OCL and Related Formalisms, EPFL (Switzerland),
LGL-REPORT2005-001 (2005)
13. Gogolla, M., Sedlmeier, M., Hamann, L., Hilken, F.: On Metamodel
Superstructures Employing UML Generalization Features. In Atkinson, C., Grossmann,
G., Ku¨hne, T., de Lara, J., eds.: Proc. Int. Workshop on Multi-Level
Modelling (MULTI’2014), http://ceur-ws.org/Vol-1286/, CEUR Proceedings, Vol. 1286
(2014) 13–22
14. Guerra, E., de Lara, J.: Towards Automating the Analysis of Integrity Constraints
in Multi-Level Models. [