Loading...
Reload document 
Open in new tab On Metamodel Superstructures Employing
UML Generalization Features
Martin Gogolla, Matthias Sedlmeier, Lars Hamann, Frank Hilken
Database Systems Group, University of Bremen, Germany
{gogolla|ms|lhamann|fhilken}@informatik.uni-bremen.de
Abstract. We employ UML generalization features in order to describe
multi-level metamodels and their connections. The basic idea is to repre-
sent several metamodel levels in one UML and OCL model and to connect
the metamodels with (what we call) a superstructure. The advantage of
having various levels in one model lies in the uniform handling of all levels
and in the availability of OCL for constraining models and navigating be-
tween them. We establish the connection between the metamodel levels
by typing links that represent the instance-of relationship. These typing
links are derived from associations that are defined on an abstraction of
the metamodel classes and that are restricted by redefines and union
constraints in order to achieve level-conformant typing. The abstraction
of the metamodel classes together with the connecting associations and
generalizations constitutes the superstructure.
Keywords. UML, OCL, Model, Metamodel, Metamodel constraint,
Generalization, Redefines constraint, Union constraint.
1
Introduction
Software engineering research activities and results indicate that metamodeling
is becoming more and more important [3, 4, 9]. However, there are a lot of discus-
sions about 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 [5, 2].
Here, we propose to join the metamodels of several levels into one model (as
in our previous work [7] without the use of redefines constraints) and to
connect the levels with associations and generalizations. Typing conformance
and strictness can be achieved through particular UML and OCL generalization
constraints. General restrictions between the metamodel levels can be specified
through the power of OCL. Restrictions can be built on metamodels and on
the metamodel architecture. The metamodel architecture is the connection be-
tween (what we call) the metamodel superstructure and the contributing meta-
models.
Our work has links to other metamodeling 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 [5] allowing linguistic as well as ontological instantiation with
an arbitrary number of metalevels supporting the potency concept. In [9] the
authors describe an approach to flatten metalevel hierarchies and seek for a level-
agnostic metamodeling style in contrast to the OMG four-layer architecture.
The structure of the rest of the paper is as follows. Section 2 gives a first, smaller
example for a metamodel superstructure. Section 3 discusses a larger example.
Section 4 shows other metamodel superstructures. The contribution is closed
with a conclusion and future work in sect. 5.
2 Superstructure Example with Ada, Person, Class, and
MetaClass
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 dis-
tinction 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 [6]. In particular, we have employed the
features supporting UML generalization constraints as discussed in [1, 8].
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 connec-
tions 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.
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.
abstract class Thing
operations
instantiatedPlus():Set(Thing)=
self.instantiated->closure(t|t.instantiated)
instantiaterPlus():Set(Thing)= …
Fig. 1. Ada, Person, Class, MetaClass within Single Object Diagram.
constraints
end
inv acyclicInstantiation: self.instantiatedPlus()->excludes(self)
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.
Summary: Metamodeling means to construct models for several levels. The
metamodels on the respective level should be described and modeled indepen-
dently (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 lev-
els 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 Superstructure Example for Relational Database
Model
In Fig. 2 we show two metamodels, one for the syntax and one for the seman-
tics part of the relational database model. The upper part catches the syntax,
i.e., relational database schemas, relational schemas, attributes, and data types.
With regard to the class names, please recall that in the database field a re-
lational database schema consists of possibly many relational schemas.1 The
lower part deals with the semantics (or runtime interpretation), i.e., database
states, tuples, attribute mappings (for short attribute maps), and values. One
also identifies two collections of invariant names, one collection for the syntax,
1 A relational schema is called a table in SQL.
Fig. 2. Metamodels for Relational Database Schemas and States.