Dimensions and Dichotomy in Metamodeling

Metamodeling is playing an increasingly important role in object-oriented software engineering. However, most approaches use metamodels in a very pragmatic way and important conceptual questions are left open. In this paper, an object-oriented metamodeling methodology based on a formal metalan-guage is introduced. The methodology allows for the description of all relevant properties of a metamodel, i. e. abstract syntax, static and dynamic semantics. Di(cid:11)erent kinds of in-stantiation relations are identi(cid:12)ed and a dichotomy for the classi(cid:12)cation of metaentities is developed. The re(cid:13)ection of the instantiation relations by the metalanguage is shown.


Introduction
Metamodeling is used as a general technique for integrating and de ning models from different domains. Common aspects of these di erent views can be identi ed and shared. The metamodeling technique consequently can be applied in quite di erent application domains, especially for standardization purposes. Metamodels should therefore be rigorously de ned as well as being intuitive and well-structured. Many general methodological aspects of modeling are also valid for metamodeling, however, further issues need to be considered in detail.
In this paper we present a metamodeling methodology based on a formal metalanguage. This methodology allows for the description of all relevant aspects of the entities of the metamodel. We are particularly interested in the description of dynamic semantics because this aspect has been neglected in common metamodeling approaches. The metamodel level, as well as the model level, are described. We provide a dichotomy for the classi cation of metaentities into intensional and extensional entities. Two kinds of instantiation relations are identi ed: inter-level instantiation and intra-level instantiation. The compatibility of these relations is proved.
The examination of behavior of intensional as well as extensional enities within a single approach m a y lead to an integration of process aspects of software engineering with the used modeling techniques.

Metamodels for the De nition of Multiple View Languages
A widely used and generally accepted technique in modern software engineering is the combination of di erent models or views for the description of software systems. The primary bene t of this approach is the modeling of related aspects like structure or behavior. For this principle, called Separation of Concern, di erent specialized techniques, mostly of diagrammatic nature, have been developed. The use of di erent models clari es di erent important aspects of the system, but it has to betaken into consideration that these models are dependent on each other and are semantically overlapping. Therefore, it is necessary to state how these models are related. The di erent views on a system have to be semantically compatible and there are several constraints between them.
Metamodeling is a very promising technique for the de nition of multiple view languages like the Uni ed M o deling Language UML97 . Using a metamodel, it is possible to determine how these models constitute the whole system. We would like to point out that while we are using an object-oriented approach to metamodeling, we are in no way restricted to the integration of object-oriented modeling techniques. Within our ongoing work, we h a ve applied this approach to object-oriented modeling techniques MK98 , as well as to the integration of speci cation techniques Gei98 .

Outline
In Section 2, we sketch the commonly accepted four level approach to metamodeling that serves as the basis for our methodology. We introduce the dichotomy of intensional and extensional metaentities and discuss the general structuring mechanisms used in our methodology. A running example is used in Section 3 in order to demonstrate the application of the methodology. Key-concepts of metamodeling, such a s instantiation, metaclasses, abstract syntax, and static dynamic semantics are explained and exempli ed. The crucial Intensional Extensional Dichotomy is the subject of Section 4. We explain the di erent kinds of instantiation relations in detail and then show compatibility properties of the metalanguage with respect to these instantiation relations, e. g. that instantiation is re ected over di erent levels. Finally, in Section 5, we evaluate our approach using some common criteria for the evaluation of metamodels. We summarize the bene ts of our approach and compare it to other existing approaches.

The Metamodeling Technique
We present a methodology for the de nition of metamodels. The methodology is based on the four-level approach, see Section 2.1. The presented approach allows not only for the description of structural relations between the entities of a metamodel, but also for a formal de nition of structural constraints and dynamic behavior of the entities. The entities of the metamodel are classi ed and the di erent kinds of instantiation relations are developed in a systematic way.

The four-level Approach
A metamodel is a model for the information that can be expressed during software modeling. Basically, a metamodel is a model of models. It consists of entities de ning the model elements and thereby the modeling language. The main purpose of a metamodel is to relate these model elements. The di erent levels of abstraction are illustrated in Fig. 1 Ode95 .
On the data-and process-level, the entities are run-time objects, i.e. instances of classes  Figure 1: Di erent Levels of Abstraction and processes running on a concrete system. On the level of models, we have di erent models describing the underlying physical system, e.g. Employee and Employer are classes of a structure diagram. The next abstraction, the metamodel level, describes the model in which, for example, the entities are classes and objects. Following the example given in Fig. 1, we consider Employer as an instance of Class of the metamodel. In order to express these concepts, we need a further level, de ning the used language for the metamodel. This level is called meta-metamodel level. The integration of di erent models using the metamodel is depicted in Fig. 2. 1 First, the elements of each model are interpreted in the metamodel. This interpretation, depicted as dashed lines, is usually done implicitly by the de nition of the modeling language itself. Within the metamodel the modeling entities themselves, as well as the relationships between these entities are described, e.g. an Association consists of AssociationEnds. Furthermore, entities of di erent models might be also related. Consider for example the association between Class and Behavior which establishes the relation between structural Class and behavioral elements StateMachine. This exempli es also the need for further constraints in order to exclude that a StateMachine is also related to another StateMachine. Generally, such constraints are very important in order to state the relationship between di erent e n tities of the metamodel.
According to Atk97 , we distinguish two metamodeling approaches. The loose approach permits that an instance of a metaentity e.g. metaentity Object occurs on the same level as its template e.g. metaentity Class. In a strict approach a template is located on a higher level than its instance. In the following, we will concentrate on loose metamodeling.
It is also possible to consider more than four levels. A crucial question is how to terminate  Figure 2: Using the Metamodel for the Integration of Di erent Models the hierarchy. One technique is that the top-level model is an instance of itself. This solution gives rise to self-referencing problems. To a void this, we propose the use of an independentlyde ned metalanguage. Overall, our approach is not only applicable for the de nition of a metamodel but also to higher levels, e.g. the meta-metamodel level.

Intensional and Extensional Entities
An important contribution of this paper is the distinction between intensional and extensional metaentities. Intensional entities have a counterpart in the concrete syntax of the modeling language, such as Class or Association. In contrast, extensional entities, such as Object or Link, are used to store necessary run-time information. Extensional entities are usually closely coupled to an intensional entity i n a w ay that the structure of the extensional entity i s described by a n i n tensional entity for example, the structure of an Object is given by a Class. One of the major advantages of metamodels is the ability to de ne the relation of intensional and extensional entities within one level. In this way, the semantics" of an intensional entity can be explained as the set of all corresponding extensional entities ful lling the requirements. A remarkable feature of metamodeling loose approach is that the semantics of a metaentity can be de ned within its own level.

Structuring Metamodels
A major focus of our work is the attempt to develop well-structured metamodels. For this purpose we use structuring techniques that are well-known from software engineering. First of all, we decompose a metamodel in di erent metaclasses. Within a metaclass, we are able to express all aspects relevant to a metaentity: Abstract Syntax: An abstract description of the entities that form a model of the respective language. Static Semantics context conditions, constraints : Well-formedness conditions between the syntactic entities, such as absence of circular inheritance. Dynamic Semantics denotation: The operational behavior of the entities of the speci cation, such as I O, reaction to stimuli, e ect of executing an operation, etc.
The description of dynamic semantics in a metamodel, in particular, is not treated precisely in other approaches. The dimensions of metamodeling are depicted in Figure 3. Here, the concepts of intensional and extensional entities and its relation to abstract syntax, static and dynamic semantics is summarized.

Intensional Entities
Extensional Entities abstract Syntax s t a t i c S e m a n t i c s dynamic Semantics A metaentity has an internal state that is protected by object-oriented encapsulation principles. This ensures that each metaentity has its own meaning, as independent as possible from other metaentities. We call this principle, localization principle see Ove98 . In classical approaches for the de nition of semantics of languages, e.g. Mey88 , this localization is not ensured. The advantages are twofold: rst, we achieve a better understandability and readability. Second, and maybe more important, we achieve an increased exibility with respect to extensions and changes. This has proved very important for the development of metamodels.
In general, a metaclass might be related to other metaclasses by an association relationship. An extensional entity is connected to its intensional entity by a special instantiation association. The division between intensional and extensional entities partitions the metamodel in two parts that are only connected by these special associations. In Section 4.2 we formulate guidelines concerning these associations. The generalization-specialization relationship is important for de ning abstract metaclasses as interfaces for metaentities. These interfaces have to be ful lled by the specialized metaentities. In Section 3, we illustrate the structuring techniques as well as the methodological aspects of our approach.
In Figure 4, the di erent roles of abstract syntax, static and dynamic semantics for intensional and extensional objects are summarized. The most remarkable di erence is observable in the dynamic semantics. While dynamic semantics on the extensional level means run-time behavior, dynamic semantics on intensional level describes system evolution in the development process.

Intensional
Extensional Abstract Syntax speci cation in the modeling languages state of a program at run-time Static Semantics well-formed speci cation possible consistent system states of a program Dynamic Semantics evolution of the speci cation during the modeling process dynamic behavior of the program at run-time

The Metalanguage
It is commonly accepted that modeling languages require a formal semantics in order to be unambiguous. Since we use a metamodel for the de nition of modeling languages, the metalanguage necessarily must have a formal semantics. According to 2.3, the metalanguage should support the following concepts: Objects: encapsulation of an object's internal state. An object de nes an entity that may only be accessed in a controlled way. Object Identity: the notion of a persistent identity for an object. Therefore, object identities should be re ected in the semantics of the metalanguage. Object Behavior: the possibility of objects evolving in a pre-de ned way. According to the localization principle, w e propose the use of method de nitions for the de nition of object behavior. Classes: the ability to describe the common aspects of objects and encapsulate them in a class structure. Objects should then beinstances of a type corresponding to the class. The features of an object should be accessible via methods. Compositionality associations: the ability to declare a structural connection between classes so that a class can access services of the associated class. multiple Inheritance: de ning a class as an extension of one or more existing classes. Polymorphism: the ability to de ne operations that act upon several distinct classes. Constraints: the ability to describe constraints between objects or pre-and postconditions of object operations in some kind of predicate logic. There are several formal languages ful lling the above requirements of the metalanguage. In the following, we have chosen Object-Z DRS94 as the formal metalanguage. Object-Z ful lls all requirements stated above and provides additional concepts e.g. parameterization that can be used in a sensible way. Furthermore, the structure of an Object-Z speci cation can be illustrated by a class diagram preserving the classical representation of metamodels.

Illustrating the Technique
In this section, we show h o w our approach can be used for the de nition of modeling languages. Using a running example, we discuss concepts employed in our work.

The Running Example
We demonstrate our methodology by de ning a metamodel for the integration of a simple non-deterministic automaton with a toy programming language. In Figure 5, the entities of the metamodel are shown using the UML notation. We rst give a brief informal explanation of the semantic entities. In the following, we will demonstrate our method by describing the entities of the metamodel in our framework.

Automata
An Automaton consists of a set of states, an initial state and a set of transitions. A Transition has a source and a target state. It is labeled with a condition -a boolean expression -and an action -a statement. Executing a transition causes the action to beexecuted method Execute.
The semantics of an automaton is given by the associated class Con guration. During run-time, an automaton resides in exactly one state actualState. The dynamic semantics of an automaton is given by the method ExecuteStep that chooses an enabled transition i. e. the transition's source state is the actual state and its condition is evaluated true and executes it. Our programming language basically consists of variable declarations VarDecl, Types, Statements and Expressions. A VarDecl introduces a name and a type for a variable. A Type has a name further details of Type are omitted. A Statement's dynamic semantics is de ned by the method Execute describing the e ect of executing the statement. The only statement considered here is the Assignment statement, consisting of a Variable and an Expression that is to be bound to the variable. An Expression has a type and it can be evaluated using the method Eval that is returning an Instance. The only kind of expression we have in our example is a CompoundExpression, consisting of an Operator and a list of operands. 2 An Operator has a signature argtype, restype and a semantics, determined by the attribute outrel, specifying how operands are mapped to the result.
A Variable has a declaration and is bound to an Instance at run-time. An Instance has a type. In our example, the only instances covered are DataValues, carrying a value. We distinguish BooleanValues and IntegerValues.

Di erent Instantiation Relations
We can now begin with the de nition of meta entities in the metalanguage Object-Z. A good introduction to Object-Z can be found in DRS94 .
There are di erent instantiation relations. In our example, we w ould like to state that an Instance knows its Type 3 . This is given by the association type in the class diagram or by the attribute type of the class Instance.
Type name : Name Instance type : Type A completely di erent relationship is the instantiation of metamodel entities. For example, we w ould like to de ne the built-in types int and bool: int; bool : Type int:name = Integer^bool:name = Boolean Note that Integer and Boolean are prede ned names. With the above de nition, we have crossed the border from metamodel level to model level compare Figure 1 by instantiating a concept Type from the metamodel level. This shows that the instantiation relation between the di erent levels is mapped naturally to the instantiation mechanism provided by the metalanguage Object-Z.

Structuring of the Metamodel
The metalanguage provides several structuring mechanisms e. g. parameterization, inheritance, which are also very useful for structuring the metamodel. The metaclass DataValue T inherits properties of Instance, i.e. a DataValue is an Instance. We de ne DataValue as a generic class over some internal datatype T. DataValues of a programming language, in contrast to Objects that have a unique identity, share the characteristic of extensional equality.
We w ould like t o i n troduce BooleanValues and IntegerValues. The instances of the classes BooleanValue and IntegerValue constitute the carrier sets for the built-in types int and bool. We use the internal data types B and Z provided by the metalanguage for this purpose. BooleanValue By the inherited constraint of extensional equality, it is assured that there are exactly two instances of BooleanValue, namely tt and .

Abstract Metaclasses
An abstract metaclass is a metaclass that cannot beinstantiated. It is only possible to instantiate subclasses of an abstract metaclass. Abstract metaclasses are used for the de nition of interfaces within the metamodel. Expression is an abstract metaclass as required by the constraint Expression = 0. It provides an interface that has to be realized by all expressions, namely that every expression has a type and can beevaluated. This is expressed by the attribute type and the de nition of the virtual" method Eval that results in an Instance. The declaration val! : Instance means that the variable val is polymorphic, e.g. it is of type Instance or of any class type derived from Instance by inheritance.

Abstract Responsibilities of Metaclasses
One of the main purposes of metamodeling is to provide a complete and abstract description of the entities. We propose using structuring techniques for this purpose. Therefore, we propose de ning a general metaclass Operator and instantiating this class in order to obtain the pre-de ned operators. The signature of an Operator is de ned by a sequence of argument types argType and a result type resType. For example the lessOperator see below takes two int expressions and results in a bool expression. The meaning of an Operator is de ned by a partial function outRel. The constraints in the class Operator state that an Operator can only be applied to Instances of its argument t ypes. The method Eval takes a sequence of instances and delivers the instance that is yielded by applying the outrel relation to them. lessOperator  Based on Operator, we can now de ne a CompoundExpression, which is an Expression that consists of an Operator applied to its operands. The abstract Eval-operation has to be implemented: the operands are evaluated and the operator is applied to the results.

Intensional and Extensional Entities
The di erence between intensional and extensional entities is demonstrated by the following example: A variable declaration is an intensional object, i.e. variable declarations are part of the modeling language. A v ariable declaration's state remains constant during computation time. The corresponding extensional entity is a Variable. It is linked to an intensional object, its declaration. It is storing run-time information over the variable, i.e. the value the variable currently holds. The dynamic semantics of variables is given by the method Attach that allows the changing of the value of a variable. It is typical for extensional objects that they provide methods with lists that serve to alter their state. A Transition consists of a source and a target state and is labelled with a boolean expression, denoting whether it can be executed or not. Its dynamic semantics is given by the operation Execute, executing its action an arbitrary statement. An Automaton represents an intensional object, i.e. the states, transitions and its initial state must be described in an appropriate modeling language. A Con guration is an extensional object that is linked to an intensional object, its automaton. It consists of an attribute actualState, which holds the state the automata is residing in. Its dynamic semantics is given by the methods SetActualState and ExecuteStep, which describe the behavior of the automaton.

Modifying the Model
The distinction between intensional and extensional entities becomes apparent if one considers the behavior of the metaentities. While the dynamic semantics of extensional entities de nes the system dynamics, the dynamic semantics of intensional entities describes how the structure of the system might evolve. This feature is especially useful for describing the consistent modi cation of the model in the sense of system evolution.
Let us consider the following simple example of model modi cation: the renaming of a type. Using the operation Rename, it is possible to change the name of the type. The problem is that the model becomes inconsistent, since further model elements refer to the modi ed type by its old name. It is therefore necessary to change further modeling elements.
In our example, we h a ve to rename the type name of the a ected variable declarations: VarDeclRen VarDecl Rename typeName newName? : Name typeName 0 = newName?
A consistent t ype renaming renames the type itself, as well as all references to it: TypeRen2 Type Rename b = name newName? : Name j name 0 = newName? o 9 v : VarDeclRen j v:typeName = name v:Rename Again, we take advantage of the reference semantics, seeing as we do not need to change further modeling elements, like Variable or Expression. Due to the persistent object identity, the changes are local. Since our model identi es the same concepts that are used in di erent models, the side-e ects are minimal.  From a software engineering point of view, it is very important to consider how design patterns could be introduced within existing software designs. We believe that our metamodel based approach could serve as a foundation for the de nition of such modi cations of the system.

The Intensional Extensional Dichotomy
The terms Intension and Extension are de ned in CN93 as follows: A term an element of a proposition may be viewed in two ways, either as a class of objects which may have only one member, or as a set of attributes or characteristics which determine the objects. The rst phase or aspect is called the denotation or extension of the term, while the second is called the connotation or intension. The extension of the term 'philosopher' is 'Socrates', 'Plato', 'Thales', and the like; its intension is 'lover of wisdom', 'intelligent', and so on. In our metamodel, we distinguish between objects that have a counterpart in the syntax intensional objects and those that are of purely semantical nature, i.e. that carry run-time information extensional objects. Extensional objects are linked via a special instantiation association with intensional objects. In our example, a Variable is an instantiation of a VariableDeclaration, and a Con guration is an instantiation of an Automaton. The role of updating methods is di erent for these kinds of objects. Updating changing the state of an intensional object means manipulating the model, whereas updating the state of an extensional object contributes to the dynamic semantics of one particular model.

Di erent Instantiation Relations
We provide two di erent kinds of instantiation relations in our metamodel approach. On one hand, we have special instantiation associations between the entities of one level of the metamodel. Such a relation connects an intensional object with an extensional object. Note that this is not characterized by a special syntactic construct of the metalanguage. Nevertheless, it is important to identify these associations properly. We call this kind of instantiation intra-level instantiation. Second, we have the instantiation mechanism of the metalanguage i.e. lessOperator : Operator. This instantiation, called inter-level instantiation, causes a transition between levels. It represents the instantiation arrow b e t ween metamodel level and model level, see Figure 1. This instantiation preserves the characteristics of extensionality and intensionality, i.e. the instantiation of an intensional object on the metamodel level is an intensional object on the model level.
In Figure 7, the di erent instantiation relations are depicted. There are several views on a semantic entity: It can be viewed as an extension of some intensional object from its upper level. It can be instantiated by some object on its lower level, thus being viewed as an intensional object. Within its own level, a semantic object is either intensional, if it is directly re ected in the syntax of the modeling language, or it is an extension of an intensional object, representing information about the history of a computation.

Implications of the Dichotomy
In the following, we formulate some guidelines for the construction and evaluation of metamodels. We do not consider these guidelines obligatory. However, non-conformity of the metamodel with these guidelines should be carefully justi ed.
Classi cation of metaentities: The entities of the metamodel should be divided into intensional and extensional entities. The intra-level instantiations instance of associations should bedistinguished. Normally, their cardinality should be1 : n from intensional to extensional. Every intensional and every extensional entity should participate in, at the most, one intra-level instantiation. In our running example see Fig. 5, the entities on the left side are intensional entities while the entities on the right are extensional. Unambiguity of intra-level instantiation: An extensional entity is connected to exactly one intensional entity by the instance of association. In statically typed languages, the instantiated association link, once established, remains constant, i. e. an object cannot change its type. Preservation of dichotomy by inheritance: The partition in intensional and extensional entities is preserved by the inheritance relationship. There exists no concrete metaentity that is super-type of an extensional and an intensional entity. Furthermore, no intensional entity is a super-type of an extensional entity and vice versa.
Re ection of associations between intensional entities via intra-level instantiation: If two intensional entities are connected by an association, then this association is re ected by a corresponding association on the extensional level such that the traversal along the associations is compatible, i.e. the diagram commutes in a certain sense. This property is important since the instance of relationship is re ected on the model-level by the inter-level instantiation.

Properties of the Metalanguage
We will now state some properties of the metalanguage that are useful for the understanding of the intensional extensional dichotomy. In GKP98 , we h a ve de ned the semantic entities and functions formally. In this paper, we give just a short overview: The semantics of a class is the set of all possible valuations that might be assigned to an object of the class. It is de ned by the function classSem that assigns each class declaration the set of all possible bindings. The semantics of an instance declaration of the form c : C is de ned by the function objSem that assigns to each instance declaration an object reference. The value of an object is de ned by the function objectMap assigning the valuation for each object. The function type delivers for an instance declaration its type and represents the inter-level instantiation. The functions asso CD , asso CS , asso OD and deref are describing the intra-level instantiation on the level of class syntax, class semantics, object syntax and object semantics.  In Figure 8, an example of an intensional Type and a related extensional entity Instance on the metamodel level is depicted. These are instantiated on the model level to the objects bool and true. Accordingly, true is an extension of bool on the model level. The properties apply, of course, to all pairs of intensional and extensional objects. Again, the proofs can be found in GKP98 .
The semantics of an object is compatible with the semantics of the object's class. Every association between classes is re ected by a compatible relation between valuations on the semantical level. The instantiation relation between an extensional and an intensional object on the metamodel level is re ected by a compatible relation between corresponding extensional and intensional objects on the model level, i.e. the intra-level instantiation is also instantiated by a n i n ter-level instantiation. Associations between semantics objects on the model level are compatible with the class semantics of the participating objects.
Note that most other metamodeling approaches e.g. UML97, MOF97, Atk97 do not consider inter-level instantiation. Thus the relation between metamodel level and model level is not precisely de ned in these approaches.

Discussion
In the previous sections we have discussed our metamodeling technique. The major contributions of this work are the following: We advocate the usage of a formal metalanguage and we elaborate the concepts the metalanguage should provide. Based on these facilities of the metalanguage, we show h o w the these techniques can be successfully applied in the de nition of metamodels. Here, one of the major aspects is the distinction between intensional and extensional entities. Both kinds of entities and their instantiations have been investigated in detail in Section 4. In contrast to existing metamodels, we also consider the dynamic semantics of a metamodel.

Bene ts of the presented approach
One bene t of our approach is the suitability for the precise de nition of multiple view languages. In addition, our approach can beuseful for several other areas in software engineering. Using the proposed technique we are able to de ne a complete model of the system that comprises not only the intensional parts but also the extensional ones. Transformation of models is naturally expressed by intensional-object-manipulating methods. I. e. adding a transition to an automaton would be described by a method AddTransition which manipulates the attribute transitions. Furthermore, context conditions for model transformation can be expressed, e. g. the impact of a change request in one model on other models can be speci ed. As we h a ve shown in Section 3, this enables us to de ne system evolution as well as the evolution of objects. The dependencies, the impact of changes and the system evolution invariants can be expressed. Semantic preserving model transformations are also in the scope of the presented approach. Using our technique, we are able to de ne the conditions under which a model transformation is semantically correct.
Methodological rules or style guides can be incorporated into the metamodel. This means that even if a model is syntactically and semantically correct, it might not be conform to some further conventions e. g. naming conventions, or it might include some unwanted nondeterminism, some methods might be partially de ned and cannot be called in every state of an object etc. This important information can be expressed using our approach.
Tracing through di erent development phases can be expressed by storing the history of a model element. In this way, the evolution of a modeling object might be traced from analysis down to implementation.

Comparison to other Approaches
The Uni ed M o deling Language is a set of object-oriented modeling languages UML97 . The relationship between the modeling languages is described by a metamodel USE97 . Technically, the abstract syntax of UML is given by means of class diagrams, the consistency constraints are de ned by OCL OCL97 formulas, and the dynamic semantics is explained in natural language. We believe that the UML is very important progress towards a precise understanding of object-oriented modeling techniques. In particular, our work MK98 is based on it. In contrast to the UML, we use a single formal metalanguage for the de nition of object-oriented modeling languages. In this way, we avoid self-referencing problems and achieve a precise semantics.
The Meta Object Facility MOF MOF97 is a meta-metamodel a model for the de nition of metamodels. Its key goal is to provide means for extensionality and self-discovery in systems. It addresses the manipulation of meta-data, e.g. the creation and retrieval of metaentities. MOF is described by a combination of UML notations, CORBA interfaces, explanatory text and constraints given in OCL. Our approach is also applicable for the definition of a meta-metalanguage, like MOF. Basically, the advantage of our approach is the utilization of a formal language for the de nition of two l a yers, as well as the precise de nition of dynamic semantics. Atkinson Atk97 describes a metamodeling framework. He also identi es the problem of an entity being viewed as both instance and template 4 and therefore introduces the concept of clabject. A clabject is comprised of an intensional and its extensional entity. The instantiation of clabject is not covered. As an additional di erence to our work, Atkinson claims that operations and methods are unimportant for metamodeling in practice, while we advocate their bene t for the description of system dynamics and evolution. The strictness of layers is re ected in our approach by the strict separation of the intensional and extensional objects in every level of abstraction.
In PBF98 , a conceptual model representing the information acquired during objectoriented analysis and design is presented. This conceptual model integrates entities and metaentities into a single conceptual framework based on Dynamic Logic. The authors propose a transformation method consisting of a set of rules for systematically creating a single integrated dynamic logic model from the separate elements that constitute a description of an object-oriented system expressed in the Uni ed Modeling Language. The intended semantics for this conceptual model is a set of states with a set of transition relations on states. The domain for states is an algebra whose elements are both entities and metaentities. The set of transition relations is partitioned into two disjoint sets: a set of transition representing modi cations on the speci cation of the system i. e. evolution of metaentities, and a set of transition representing modi cations on the system at run time i. e. evolution of entities.
The PUML group EFLR98 aims at a precise semantic model for UML class diagrams. This semantics model shall be used as a basis for the de nition of semantic preserving transformation rules. It is argued that a metamodel cannot serve a s a precise description of the meaning of UML constructs, but rather as a precise desription of the UML notation. The authors describe abstract syntax, semantic domain and a mapping from syntax to semantics in the speci cation language Z. The similarities between their approach and the one presented in this paper are thus the identi cation of a dichotomy and a single-language approach. Interlevel instantiation could be also expressed in the PUML approach, though it is not explicitly formulated. The major di erence between the two approaches is that no dynamic semantics is described in EFLR98 , and that we apply a meta language that supports a reference semantics, while in the PUML approach, the meta language supports value semantics only.

Metamodeling and Denotational Semantics
We believe that there is a strong relation between metamodeling and denotational semantics. In both disciplines, the concepts of abstract syntax, static and dynamic semantics play a central role. 5 In the denotational semantics area, the abstract syntax is de ned by abstract grammars, the static semantics is de ned by validity functions, checking the well-formedness of the syntactic constructs of the abstract grammar. The dynamic semantics denotation is de ned by assigning mathematical objects from the semantics domain usually sets and functions to the syntactic constructs. It is remarkable that the signature of the semantic functions usually comprises an explicit state and delivers a state. This is necessary because, in set theory, there is no explicit notion of state.  In the presented approach, the abstract syntax of a language is re ected by the attributes and associations of the extensional objects. The static semantics is given by additional secondary attributes and constraints on the attributes of the class. The dynamic semantics is given by methods manipulating the extensional objects. The extensional objects are the correspondents to the state in the denotation functions. A comparison between our approach t o metamodeling and denotational semantics is given in Figure 9.
We believe that these parallels have not become apparent so far because of the neglect of dynamic semantics in metamodeling. In our opinion, the presented approach o ers essential advantages to the denotational semantics approach because it provides the full power of object-orientation, instead of simple set theory, for the description of the semantic domain.