To Meta or not to Meta - That is the Question
Colin Atkinson†, Thomas Kühne† and Brian Henderson-Sellers‡
†
University of Kaiserslautern
{atkinson, kuehne@informatik.uni-kl.de}
‡
University of Technology, Sydney
{brian@socs.uts.edu.au}
INTRODUCTION
Metamodels and Metamodeling have for a long time been
regarded as the exclusive preserve of tool vendors and
academics rather than a part of mainstream software
development.
End users were rarely expected to
understand, let alone manipulate, metamodels and could
perfectly well use data-oriented technologies (e.g. CASE
tools) without knowledge of the underlying metamodel.
However, this situation is changing with the growth in the
popularity of general-purpose, visual modeling languages
such as the UML [1] and its variant, OML [2]. Since they
are general purpose, users are encouraged to tailor them to
their own needs by effectively extending the language
metamodel in some way. Moreover, the UML is just one
part in the OMG's bigger picture of standards, and has its
metamodel defined using the same "meta-meta model" (the
MOF in OMG terminology) as other standards such as for
the DataWareHouse .
In all the excitement surrounding metamodeling, however,
people have started to use it in ways for which it is not
well suited and where more traditional concepts of object
modeling would be better employed. The inheritance
mechanism, in particular, has been overlooked as a
mechanism that can more appropriately support many
cases where metamodeling is currently being used. In this
column we compare and contrast the mechanisms of
inheritance and metamodeling, and provide some guideline
for choosing between them. We also discuss how "light"
metamodeling mechanisms (e.g. stereotypes) fit into the
picture.
CLASSES AND OBJECTS
The core concepts of object-based modeling are the class
and the object. An object is viewed as being an instance-of
a class, and is automatically created with the properties
defined by its class. Thus, a class serves as a template from
which multiple, structurally identical objects can be
instantiated.
As illustrated in Figure 1 (a), properties generally
associated with classes are its attributes and operations,
which, following OMG terminology, we will collectively
refer to as features in the following. Thus the class in
Figure 1 (a) defines the features of employee objects, each
of which has a birthDate attribute, a startDate attribute, a
salary attribute, and the operations age() and
yearsService(). Each instance of the Employee class has
values for each of these attributes, as illustrated in Figure 1
(b) which we read as “Bill Bloggs is an employee”
Employee
birthDate
startDate
salary
age()
yearsService()
(a) Employee Class
BillBloggs:Employee
birthDate = 14/1/52
startDate = 1/1/72
salary = $35,000
(b) Employee Object
Figure 1
This UML model captures the fact that the object
BillBloggs is an instance-of the class Employee, and has
specific values for its attributes. Note: in this and the
following examples our focus is not on providing the
optimal representation of every logical concept, such as,
for example whether age should be an attribute or a
method, or whether role modeling should be used in place
of inheritance [3], but rather to illustrate the different
effects of the meta-modeling and inheritance mechanisms
on model elements.
INHERITANCE
The inheritance mechanism forms one of the foundations
of object technology, and is the primary feature that, at the
language level, distinguishes object-oriented development
from object-based development. From a modeling
perspective, inheritance is used to capture the situation in
which one kind of abstraction is "like" another kind of
abstraction, but with some additional properties. Thus,
instead of defining all features of employee objects
directly in the class Employee, it is also possible to use
inheritance to define some of them in a superclass of
Employee, as illustrated in Figure 2 (a). We might then say
in describing Figure 2 (a), “an employee is a person”.
The class Employee in Figure 2 (a) has exactly the same
set of features as that in Figure 1 (a) - the only difference
is that some are inherited. Employee is said to be a
subclass of Person. An object “BillBloggs” created from
the class Employee in Figure 2 (a) is identical to one
created from the class Employee in Figure 1 (a).
Establishing an inheritance relationship between two
classes also establishes a subset relationship between
instances of the classes. Thus, as illustrated in Figure 2 (b),
instances of the subclass Employee are assumed to form a
subset of the instances of the superclass Person. In other
words, the object “BillBloggs” can be regarded as an
instance of class Person as well as of class Employee[4].
Hence, it is possible to interpret an instance as being of a
type somewhere along an inheritance chain between the
class which generated it and the root (“ultimate ancestor”)
of that chain (e.g., often “Object”).
at the model level by instantiating the metaclass Person
instead of metaclass Class (Figure 3 (a)). We might read
Figure 3 (a) as “an employee is a person”.
However, there is a problem here in that the attributes of
the metaclass Person (here birthDate and age()) become
class-level attributes of Employee – all employees would
have the same birthdates! Thus all attributes which need
to be instance-specific (the usual case) need to be declared
in the Employee class and cannot be obtained, through the
instance-of relationship, from Person.
Person
birthDate
age()
Person Instances
Employee
startDate
salary
Person
Employee Instances
birthDate
BillBlogs
Person
(a) Inheritance
(b) Object Subsets
birthDate
Figure 2
age()
Employee
startDate
salary
« instanceOf »
In most object-oriented languages, inheritance has
additional semantics associated with the typing and
operation binding mechanisms of the system. Establishing
a subclass relationship between two classes may also
establish a subtype relationship between them (as long as
specialization inheritance and not implementation
inheritance is being used), allowing instances of the
subclass to assume the role of instances of the supertype
(inclusion polymorphism). If subclasses are allowed to
override method realizations, as is usually the case, this
substitutability also gives rise to a dynamic binding
mechanism in which the operation realization chosen to
fulfill a service is determined by the exact type of the
objects fulfilling the role at run-time.
age()
Metamodel level
yearsService()
startDate
salary
yearsService()
Model level
Employee
yearsService()
bonus
totalRenumeration()
(a) Instance-of Relationship
METAMODELING
The basic idea behind object-oriented metamodeling is to
model the elements of an object model in a higher level
object-model. The elements of an object-model can then be
viewed as instances-of the elements in the higher level
model (the meta-model). In short, the model is an instance
of the metamodel and the elements of that model are
instances of the corresponding elements in the metamodel.
In principle, this hierarchy could be carried on indefinitely,
i.e., the metamodel is regarded as an instance of a metameta-model, and so on. In practice, however, only four
levels are commonly used.
SalesPerson
(b) Three levels of
Inheritance
« Person »
Employee
(c) “is-a” expressed with a stereotype
Figure 3
THE MANY MEANINGS OF “IS A”
Superficially, Figure 2 (a) and Figure 3 (a), would appear
to be very similar (both could be read as “an employee is a
person”), and if they are only given superficial
consideration, then important differences may go
unnoticed. This is because people have a tendency to
broadly associate the phrase “is a” both to metamodeling
(Figure 3 (a)) and to specialization inheritance (Figure 2
(a)) or subtyping ([5,6]). If one thinks about the real-life
entities which the modeling elements represent, it would
be perfectly reasonable, though not very precise, to say
that BillBloggs "is a"(n) Employee and that Employee
"is a" Person. This is really knowledge representation, not
subtyping, and is known as specification inheritance [5].
Moreover, people would state that Employee “is a” class,
which is also a reasonable, though imprecise, statement, if
one assumes that metaclass Person inherits from metaclass
Class (subtyping again). The subtyping, knowledge
representation and instance-of relationships, therefore,
may all – through a process of careless generalization – be
referred to as "is a" relationships.
In order to apply this concept to the example in the
previous section, we postulate Person to be at the
metamodel (M2) level rather than at the model (M1) level.
For the purpose of this discussion the absolute level of
Person is actually not important, only its relative level with
respect to Employee is important. Moreover, it is irrelevant
that the standard metamodel does not contain a class,
Person, but instead contains metaclasses such as Class and
Association, etc. We are just assuming that the metamodel
has been extended with a metaclass Person (e.g., through a
so-called heavyweight extension or by the introduction and
application of a “Person” stereotype, see section
LIGHTWEIGHT EXTENSION MECHANISMS). So,
assuming we now have, by whatever means, a metaclass
Person in the M2 model, an Employee class is then created
2
Unfortunately, the use of sloppy languages (i.e., the use of
the “is a” phrase) is entirely unjustified in the context of
comparing inheritance to metamodeling. There are in fact
quite significant differences between the inheritance and
instantiation mechanisms (i.e. between Figure 2 (a) and
Figure 3 (a)), but in certain circumstances, which we will
describe later, these differences are all too easily
overlooked. The basic difference between the two stems
from the presence or absence of transitivity. More
specifically -
are still available to the instances, but class-level
features need not be
Another way to express this phenomenon is to characterize
inheritance as cumulative. In other words, features are
accumulated down the inheritance hierarchy, whereas
instantiation transforms features into class-level features
which are thereby eliminated in further instantiation steps.
It is important to note that the non-transitivity of
instantiation, as shown above, applies to a class’s
associations as well as to its features. If, in Figure 3 (b),
the class Person had an association, the class SalesPerson
would also have such an association thanks to the
transitive properties of inheritance. However, if the same
situation were to occur in the metamodeling analogue, that
is, if the meta-metaclass Person, in Figure 3 (a), had an
association, an assumed SalesPerson class would not have
such an association. This is because at the level of the
metaclass Employee, this association would have become
a link. On instantiating metaclass Employee to a
SalesPerson class, this link becomes a class attribute of
SalesPerson and is, hence, lost for instances of
SalesPerson.
 the inheritance relationship is transitive
 the instance-of relationship is not transitive
Figure 3 (b) illustrates the essence of the difference. Here,
SalesPerson is defined as a subclass of Employee, which in
turn is a subclass of Person. Since inheritance is used, this
means that SalesPerson inherits all the properties of the
class Employee and all the properties of the class Person the relationship is transitive. Furthermore, a SalesPerson
instance can also be regarded as both an Employee and a
Person instance.
However, if the inheritance relationships in Figure 3 (b)
were replaced by instance-of relationships, so that
SalesPerson was an instance-of Employee and Employee
an instance of Person, this would not be the case. Note,
again, we are assuming that SalesPerson is a class and
hence, Employee would be a metaclass and Person a metametaclass. The fact that this has nothing to do with
metaclasses and pre-defined meta-metaclasses in the UML
is again irrelevant as we are only discussing the principle
of instantiation. In this hypothetical – and if taken literally
– absurd example, the class SalesPerson would not receive
the features of the metametaclass Person (at least not in the
normal way in which instances of class SalesPerson would
receive their individual copy of SalesPerson attributes).
When made explicit in the form shown above, the
differences between the instance-of and subclass-of
relationship are fairly clear. The problem that arises in
practical modeling work, however, is that the instance-of
relationship is rarely made explicit, but instead UML
encourages users to perform their metamodeling work
using a third mechanism based on the concept of
stereotypes.
LIGHTWEIGHT EXTENSION MECHANISMS
The idea behind the so-called "built-in" extension
mechanism of the UML is to allow users to achieve the
effects of meta-modeling without having to directly
manipulate the meta-model. It achieves this by means of
stereotypes, which can be used to "further classify
modeling elements", tagged values, which can be used to
attach descriptive information to classes, and constraints,
which can be used to defines rules on the use of model
elements.
The reason for this is, as we have noted, that when a
metaclass is instantiated, its attributes become class-level
attributes of the class (its instance). In other words, they
become attributes of the class (viewed as an instance of the
metaclass, i.e., viewed from an object perspective), rather
than attributes that instances of the class would receive. In
C++ and Java features with a similar quality are referred to
as static1. However, there are important differences
between static features in a programming language and
class-level features in modeling:

static features are not created by instantiating a class
from a metaclass, but are defined and owned by a
single class

static features are visible from ordinary features. This
is not necessarily the case with class-level features

when creating an instance of a class, its static features
Unfortunately, the nature of the built-in UML extension
mechanism complicates the problem of distinguishing and
choosing between inheritance and metamodeling in
practical development work. The first problem is that the
semantics of the mechanism are rather vague and do not
faithfully reproduce the full effects of direct metamodeling
[7]. While it is possible to define class-level attributes (and
their values) in the form of tagged values, there is no way
of describing class-level methods or links (i.e. instances of
associations between metaclasses).
The second problem is that the notation for stereotypes
bears no resemblance to the notation for either inheritance
or instance-of (although it is intended to convey the
meaning of the latter). As illustrated in Figure 3 (c),
therefore, there is no visual clue to users of the intended
semantics of the notation. Since the semantics are vague in
any case, and the stereotype concept relatively new to the
1
In Java and C++ instances of a class with a static feature can access this
feature. All instances share one copy of this class feature. However, this
does not have to be so. From a modeling perspective the class-level
features of a class need not have any relationship to the instance-level
features.
3
developer community, the practical result is that many
users apply the stereotype mechanism without fully
understanding the implications with respect to the
inheritance/metamodeling distinction identified above. In
particular, many users assume that the stereotype
mechanism has the transitive property of inheritance, and
thus expect an instance of the class Employee in Figure 3
(c) to automatically gain the features defined for the
(virtual) metaclass Person. This is compounded in many
cases, as here, by the ease with which it is possible to
forget that the stereotype («Person») is in fact at the
metalevel and does not refer to the model of a Person in
the business world. In effect, the stereotype mechanism
essentially represents a third opportunity to misuse the
"is a" phrase.
presence or absence of transitivity in the derivation of
properties.
Inheritance-based
approaches
feature
transitivity, whereas metamodeling approaches, whether
explicit metamodeling at the M2 level, or implicit
metamodeling in terms of stereotypes, are not transitive.
This means that properties defined for meta-classes, or for
stereotyped classes in the form of tagged values, are not
attained by their instances, but properties defined for
classes are attained by their subclasses. This distinction is
of particular importance in the definition of profiles, where
it is likely that a mix of meta-elements (either stereotypes
or meta-classes) and regular M1-level elements, to act as
superclasses, is likely to provide the optimal balance.
REFERENCES
1. OMG, 1999, OMG Unified Modeling Language
Specification, Version 1.3, OMG document ad/99-0609
PREDEFINED MODELING ELEMENTS
An important example of the confusion between
inheritance and metamodeling that can arise in the
application of the UML is in the definition of predefined
modeling elements. The purpose of predefined modeling
elements is to define the environment in which new user
model elements are defined, and thus the predefined
properties that these elements can attain. In the current
version of the UML, these predefined constructs are
known as standard elements, and take the form of
stereotyped model elements (mostly classes). However, if
the only mechanism used to predefine modeling elements
is (lightweight) meta-modeling then none of the properties
defined for the predefined elements can be attained by
instances of user-defined classes, because of the lack of
transitivity in the instance-of relationship. These properties
are "lost" to user data.
If some of the standard modeling elements had been
defined as normal classes, and the subclass relationship
used instead of instance-of as the means for relating
standard elements to user-defined elements, the latter
could transitively inherit the properties of the former, and
these would be attained by instances. Populating the M 1
level with predefined entities, rather than providing
predefined meta-entities, is not a new invention but a
common technique in object-oriented programming
languages. A predefined class "Object" is typically defined
(at the M1 level) from which new user defined classes
explicitly or implicitly inherit.
The reason for this avoidance of inheritance in the current
version of the UML seems to be an over reliance on
stereotypes for the definition of standard elements. Even
the proposed new extension mechanism (profiles [8]) still
seems to neglect the role of inheritance in the definition of
predefined standard elements.
CONCLUSIONS
The important message for practical users of the UML
from the preceding discussion is to be aware that one could
carelessly utilize one phrase "is a" in order to refer to
relationships between elements established by three
distinct mechanisms in the UML. One has, consequently,
to be sure to select the one which provides the desired
effects. As discussed above, the essential difference is the
4
2.
Henderson-Sellers, B., Atkinson, C. and Firesmith,
D.G., 1999, Viewing the OML as a variant of the
UML, <<UML>>'99 - The Unified Modeling
Language. Beyond the Standard (eds. R. France and
B. Rumpe), Lecture Notes in Computer Science 1723,
Springer-Verlag, Berlin, 49-66
3.
Henderson-Sellers, B. and Firesmith, D.G., 1998,
Upgrading OML to version 1.1: Part 2 – additional
concepts and notation, JOOP, 11(5), 61-67
4.
Henderson-Sellers, B. and Graham, I., 1999,
Metalevel relationship cardinalities, JOOP, 12(1), 5158
5.
Yap, L.-M. and Henderson-Sellers, B., 1993, A
semantic model for inheritance in object-oriented
systems, Procs. ASWEC’93, IREE, Sydney, 28-35
6.
LaLonde W. and Pugh J., 1991, Subclassing 
Subtyping  Is-a, JOOP, 5(3), 57-62
7.
Atkinson C., 1999, “Supporting and Applying the
UML Conceptual Framework,” in The Unified
Modeling Language. <<UML>>’98: Beyond the
Notation (eds. J. Bézivin and P.-A. Muller), LNCS
1618 Springer, 21-36
8.
Desfray P., editor, 1999, “White Paper on the profile
mechanism”, OMG Document ad/99-04-07.