dimensions and dichotomy in metamodeling
TRANSCRIPT
Dimensions and Dichotomyin MetamodelingRobert Geisler, Marcus Klar, Claudia PonsBericht-Nr. 98-5
Dimensions and Dichotomy in MetamodelingRobert Geisler�, Marcus Klar�� and Claudia Pons���� Technische Universit�at Berlin, Institut f�ur Kommunikations- und SoftwaretechnikFranklinstr. 28/29, 10587 Berlin, E-Mail: [email protected]�� Fraunhofer Institut f�ur Software- und Systemtechnik ISSTMollstra�e 1, 10178 Berlin, E-Mail: [email protected]��� Li�a, Univ. de La Plata,E-Mail: [email protected] is playing an increasingly important role in object-oriented software en-gineering. However, most approaches are using metamodels in a very pragmatic way andimportant 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 propertiesof a metamodel, i.e. abstract syntax, static and dynamic semantics. Di�erent kinds of in-stantiation relations are identi�ed and a dichotomy for the classi�cation of metaentities inintensional and extensional entities is developed. The re ection of the instantiation relationsby the metalanguage is shown.1 IntroductionMetamodeling is used as a general technique for integrating and de�ning models from dif-ferent domains. Common aspects of these di�erent views can be identi�ed and shared. Themetamodeling technique consequently can be applied in quite di�erent application domainsespecially for standardization purposes. Metamodels should therefore be rigorously de�ned aswell as being intuitive and well-structured. Many general methodological aspects of modelingare also valid for metamodeling; however, there are further issues 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 themetamodel. We are particularly interested in the description of dynamic semantics, becausethis aspect has been neglected in common metamodeling approaches. The metamodel levelas well as the model level are described. We provide a dichotomy for the classi�cation ofmetaentities into intensional and extensional entities. Two kinds of instantiation relationsare identi�ed: inter-level instantiation and intra-level instantiation. The compatibility ofthese relations is proved.The examination of behavior of intensional as well as extensional enities within a singleapproach may lead to an integration of process aspects of software engineering with the usedmodeling techniques.1
1.1 Metamodels for the De�nition of Multiple View LanguagesA widely used and generally accepted technique in modern software engineering is the com-bination of di�erent models (or views) for the description of software systems. The primarybene�t of this approach is to model only related aspects (like structure or behavior). For thisprinciple, called Separation of Concern, di�erent specialized techniques mostly of diagram-matic nature have been developed. Using di�erent models clari�es di�erent important aspectsof the system, but it has to be taken into consideration that these models are dependent oneach other and they are semantically overlapping. Therefore, it is necessary to state howthese models are related.
...
}
...
Sequence Diagram
Programming Language
class C : B {
private boolean attr;
private void m() {
boolean attr
C
B
Class diagram
itsBA
Statechart
m()/body
m()
}
a:A b:B c:C
itsA
Figure 1: Di�erent Models of a SystemThe di�erent views on a system (see Fig. 1) have to be semantically compatible and thereare several constraints between them (indicated by arrows). For example, a statechart isrelated to a class, therefore only features of the class might be used within the statechart.Within a sequence diagram, a method call is related to the method declaration in the classdiagram. Furthermore, statecharts and sequence diagrams provide means for modeling be-havior and they have to be compatible. Naturally, all these models have an impact on theimplementation given in some implementation language.Metamodeling is a very promising technique for the de�nition of multiple view languageslike the Uni�ed Modeling Language [UML97]. Using a metamodel, it is possible to determinehow these models constitute the whole system. We would like to point out that while weare using an object-oriented approach to metamodeling, we are in no way restricted to theintegration of object oriented modeling techniques. We have applied this approach to object-oriented modeling techniques [KG98, MK98] as well as to the integration of speci�cation2
techniques [GK98].1.2 OutlineIn Section 2, we sketch the commonly accepted four level approach to metamodeling thatserves as the basis for our methodology. We introduce the dichotomy of intensional andextensional metaentities and discuss the general structuring mechanisms used in our method-ology. A running example is used in Section 3 in order to demonstrate the application ofthe methodology. Key-concepts of metamodeling, such as instantiation, metaclasses, abstractsyntax, and static/dynamic semantics are explained and exempli�ed. The crucial Inten-sional/Extensional Dichotomy is subject to Section 4. We explain the di�erent kinds ofinstantiation relations in detail and then prove compatibility properties of the metalanguagewith respect to these instantiation relations, e.g. that instantiation is re ected over di�erentlevels. Finally, in Section 5, we evaluate our approach using some common criteria for theevaluation of metamodels. We summarize the bene�ts of our approach and compare it toexisting approaches.2 The Metamodeling TechniqueWe present a methodology for the de�nition of metamodels. The methodology is based onthe four-level approach, see Section 2.1. The presented approach allows not only for thedescription of structural relations between the entities of a metamodel, but also for a formalde�nition of structural constraints and dynamic behavior of the entities. The entities of themetamodel are classi�ed and the di�erent kinds of instantiation relations are developed in asystematic way.2.1 The four-level Approach...
......
...
Meta Language
Classship
Relation-Object
Employee Employer
Robert Chris David
Instance
Meta-Metamodel Level
Model Level
Data & Process Level
Metamodel Level
Language
Concept
Concept
InstanceFigure 2: Di�erent Levels of Abstraction3
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 elementsand therefore the modeling language. The main purpose of a metamodel is to relate thesemodel elements. The di�erent levels of abstraction are illustrated in Fig. 2 [Ode95].On the data- and process-level, the entities are run-time objects, i.e. instances of classesand processes running on a concrete system. On the level of models, we have di�erentmodels describing the underlying physical system, e.g. Employee and Employer are classesof a structure diagram. The next abstraction, the metamodel level, describes the model inwhich, for example, the entities are classes and objects. Following the example given in Fig.2, we consider Employer as an instance of Class of the metamodel. In order to express theseconcepts, we need a further level, de�ning the used language for the metamodel. This levelis called meta-metamodel level.Association
StateMachine
ModelElement
...
State
Meta-Model
Statechart
BA
C
Class Diagram
A BitsBitsA
Different Models
AssociationEnd Class
behavior
Figure 3: Using the Metamodel for the Integration of Di�erent ModelsThe integration of di�erent models using the metamodel is depicted in Fig. 3.1 First,the elements of each model are interpreted in the metamodel. This interpretation, depictedas dashed lines, is usually done implicitly by the de�nition of the modeling language itself.Within the metamodel the modeling entities itself but also the relationships between theseentities are described, e.g. an Association consists of AssociationEnds. Furthermore, entitiesof di�erent models might be also related. Consider for example the association betweenClass and Behavior which establishes the relation between structural (Class) and behavioralelements (StateMachine). This exempli�es also the need for further constraints in orderto exclude that a StateMachine is also related to another StateMachine. Generally, suchconstraints are very important in order to state the relationship between di�erent entities of1This example is taken from the UML. 4
the metamodel.According to [Atk97], we distinguish two metamodeling approaches. The loose approachpermits that an instance of a metaentity (e.g. metaentity Object) occurs on the same levelas its template (e.g. metaentity Class). In a strict approach a template is located on a higherlevel 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 terminatethe hierarchy. One technique is that the top-level model is an instance of itself. This solutionarises self-referencing problems. To avoid this, we propose to use an independently de�nedmetalanguage. Overall, our approach is not only applicable for the de�nition of a metamodelbut also to higher levels, e.g. the meta-metamodel level.2.2 Levels of IntegrityThe primary bene�t of a metamodel-based integration is that general consistency constraintscan be expressed on metamodel level (see Figure 4). The metamodel de�nes the modelingelements, the integrity constraints and { as we will see later { the dynamic behavior of themodeling elements. Since a concrete model is an instance of the metamodel, the constraintsand the behavior are preserved. Therefore, general consistency constraints as well as thebehavior of the modeling elements can be de�ned and understood on metamodel level. Theseconstraints have to be stated only once, holding for all possible models.Integrity
Behavior
Integrity
Behavior
Integrity
Behavior
prescribes
ensures
prescribes
ensures
Data and ProcessLevel
Model Level
Metamodel Level
Figure 4: Levels of IntegrityWe distinguish between static integrity constraints and dynamic integrity constraints.Static integrity constraints de�ne the set of possible states of a concrete model, while dynamicconstraints restrict the behavior of model entities.2.3 Intensional and Extensional EntitiesAn important contribution of this paper is the distinction between intensional and extensionalmetaentities. Intensional entities have a counterpart in the concrete syntax of the modelinglanguage, such as Class or Association. In contrast, extensional entities are used to storenecessary run-time information, such as Object or Link. Extensional entities are usuallyclosely coupled to an intensional entity in a way that the structure of the extensional entity isdescribed by an intensional 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 intensionaland extensional entities within one level. In this way, the \semantics" of an intensional entity5
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 metaentitycan be de�ned within its own level.IntensionalEntity
instance_of ExtensionalEntityFigure 5: Intensional and Extensional Entities2.4 Structuring MetamodelsOne major e�ort of our work is to develop well-structured metamodels. For this purposewe are using structuring techniques that are well-known from software engineering. First ofall, we decompose a metamodel in di�erent metaclasses. Within a metaclass, we are able toexpress all aspects relevant to a metaentity:� Abstract Syntax: An abstract description of the entities that form a model of therespective language.� Static Semantics (context conditions, constraints) : Well-formedness conditions betweenthe syntactic entities, such as absence of circular inheritance.� Dynamic Semantics (denotation): The (operational) behavior of the entities of thespeci�cation, such as I/O, reaction to stimuli, e�ect of executing an operation, etc.Especially the description of dynamic semantics in a metamodel is not treated in a preciseway in other approaches. The dimensions of metamodeling are depicted in Figure 6. Here,the concepts of intensional and extensional entities and its relation to abstract syntax, staticand dynamic semantics is summarized.
Extensional Entities
Abstract Syntax
Static Semantics
Dynamic Semantics
Intensional Entities
Figure 6: The Dimensions of MetamodelingA metaentity has an internal state that is protected by object-oriented encapsulationprinciples. This ensures that each metaentity has its own meaning, as independent as possible6
from other metaentities. We call this principle, localization principle (see [ �Ove98]). In classicalapproaches for the de�nition of semantics of languages, e.g. [May88], this localization isnot ensured. The advantages are twofold: �rst, we achieve a better understandability andreadability. Second, and maybe more important, we achieve an increased exibility withrespect to extensions and changes. This has proved very important for the development ofmetamodels.In general, a metaclass might be related to other metaclasses by an association relation-ship. An extensional entity is connected to its intensional entity by a special instantiationassociation (see �gure 5). The division between intensional and extensional entities partitionsthe metamodel in two parts that are only connected by these special associations. In Section4.2 we formulate guidelines concerning these associations. Further properties are investigatedin Section 4.5. The generalization-specialization relationship is important for de�ning ab-stract metaclasses as interfaces for metaentities. These interfaces have to be ful�lled by thespecialized metaentities. In Section 3, we illustrate the structuring techniques as well as themethodological aspects of our approach.In Figure 7 the di�erent roles of abstract syntax, static and dynamic semantics for inten-sional and extensional objects is summarized. The most remarkable di�erence is observablefor the dynamic semantics. While dynamic semantics on the extensional level means run-timebehavior, dynamic semantics on intensional level describes system evolution in the develop-ment process. Intensional ExtensionalAbstract Syntax speci�cation in the modelinglanguage(s) state of a program at run-timeStatic Semantics well-formed speci�cation possible/consistent systemstates of a programDynamic Semantics evolution of the speci�cationduring the modeling process dynamic behavior of the pro-gram at run-timeFigure 7: Intensional vs. Extensional Entities2.5 The MetalanguageIt is commonly accepted that modeling languages require a formal semantics in order tobe unambiguous. Since we use a metamodel for the de�nition of modeling languages, themetalanguage necessarily must have a formal semantics. According to 2.4, the metalanguageshould support the following concepts:� Objects: encapsulation of an object's internal state. An object de�nes an entity thatmight be only accessed in a controlled way.� Object Identity: the notion of a persistent identity for an object. Therefore, objectidentities should be re ected in the semantics of the metalanguage.� Object Behavior: the possibility of objects to evolve in a pre-de�ned way. According tothe localization principle, we propose the use of method de�nitions for the de�nition ofobject behavior. 7
� Classes: the ability to describe the common aspects of objects and encapsulate themin a class structure. Objects should then be instances of a type corresponding to theclass. The features of an object should be accessible via methods.� Compositionality (associations): the ability to declare a structural connection betweenclasses so that an 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 post-conditions of objects operations in some kind of predicate logic.There are several formal languages ful�lling the above requirements on the metalanguage.In the following, we have chosen Object-Z [DRS94] as formal metalanguage. Object-Z ful�llsall requirements stated above and provides additional concepts (e.g. parameterization) thatcan be used in a sensible way. Furthermore, the structure of an Object-Z speci�cation can bevisualized by a class diagram preserving the classical representation of metamodels.Object-Z is a state based speci�cation language that supports object oriented featuressuch as objects and object identities, classes, inheritance and polymorphism. Its referencesemantics (in contrast to a value semantics) provides an adequate means to express aggrega-tion and sharing of objects and encapsulation, i.e. the idea that the state of an object of aparticular class may be altered only by operations de�ned in that class.Objects have an external view which is a persistent identity. If C is a class, the declarationc : C declares c to be a variable whose value is a reference to (i.e. the identity of) an objectof class C . Distinct references identify distinct objects. This is the major di�erence to theZ-semantics, where objects with the same value are automatically identi�ed.For the internal view, the semantics of an Object-Z class comprises a set of attributebindings consistent with their types and the class invariant, a set of initial bindings, and, forthe operations a set of relations on attribute bindings with input/output parameters.The term c:att denotes the value of attribute att of the object referenced by c. Theterm c:Op denotes an operation which transforms the object referenced by c according to thede�nition of C 's Op. Operations provide the only mechanism for transforming the internalview of objects.3 Illustrating the TechniqueIn this section, we show how our approach can be used for the de�nition of modeling languages.Using a running example, we discuss many concepts of our work.3.1 The Running ExampleWe demonstrate our methodology by de�ning a metamodel for the integration of a simplenon-deterministic automaton with a toy programming language. In Figure 8 the entities ofthe metamodel are shown using the UML notation. We �rst give a brief informal explanationof the semantic entities. In the following, we will demonstrate our method by describing theentities of the metamodel in our framework.8
3.1.1 AutomataAn Automaton consists of a set of states, an initial state and a set of transitions. A Transitionhas a source and a target state. It is labeled with a condition { a boolean expression { andan action { a statement. Executing a transition causes the action to be executed (methodExecute).The semantics of an automaton is given by the associated class Con�guration. Duringrun-time, an automaton resides in exactly one state (actualState). The dynamic semantics ofan automaton is given by the method ExecuteStep that chooses an enabled transition, i.e. itssource state is the actual state and its condition is evaluated to true, and executes it.
BooleanValue
DataValuevalue : T
IntegerValue
+declaration
1
+value1
+resType1
+argtype*
+{ordered}
+type1
VarDeclvarName : NametypeName : Name
+type1Instance
+operator
1 Operatoroutrelopname()
+lhs1
Variable
1
1+type1
Type
1*
11
CompoundExpression1
+operand
*+{orderd}
+rhs1
Assignment
1
+cond1
ExpressionEval() : Instance
1
*
1
+action
1
StatementExecute()
+transitions*
Transitiontarget : Statesource : StateExecute()
1
1
+automaton
1
Automatonstates : set(State)initialState : State
*
ConfigurationactualState : StateSetActualState()ExecuteStep()
1
Figure 8: The Running Example3.1.2 Programming LanguageOur programming language basically consists of variable declarations (VarDecl), Types, State-ments and Expressions. A VarDecl introduces a name and a type for a variable, a Type has aname, further details of Type are omitted. A Statement 's dynamic semantics is de�ned by themethod Execute describing the e�ect of executing the statement. The only statement consid-ered here is the Assignment statement, consisting of a Variable and an Expression that is tobe bound to the variable. An Expression has a type and it can be evaluated using the methodEval that is returning an Instance. The only kind of expression we have in our example is a9
CompoundExpression, consisting of an Operator and a list of operands.2 An Operator has asignature (argtype, restype) and a semantics, determined by the attribute outrel , specifyinghow operands are mapped to the result.A Variable has a declaration and is bound to an Instance at run-time. An Instance hasa type. In our example, the only instances covered are DataValues, carrying a value. Wedistinguish BooleanValues and IntegerValues.3.2 Di�erent Instantiation RelationsNow we start with the de�nition of meta entities in our metalanguage Object-Z. A shortintroduction to Object-Z can be found in Section 2.5, for further reading we recommend[DRS94].There are di�erent instantiation relations. In our example, we would like to state that anInstance knows its Type3. This is given by the association type in the class diagram or bythe attribute type of the class Instance.Typename : Name Instancetype : TypeA completely di�erent relationship is the instantiation of metamodel entities. For example,we would like to de�ne the built-in types int and bool :int ; bool : Typeint :name = Integer ^ bool :name = BooleanNote that Integer and Boolean are prede�ned names.With the above de�nition, we have crossed the border from metamodel level to modellevel (compare Figure 2) by instantiating a concept (Type) from the metamodel level. Thisshows that the instantiation relation between the di�erent levels is mapped naturally to theinstantiation mechanism provided by the metalanguage Object-Z.Alternatively, we could also de�ne the instantiation in the following way.int2Typename = Integer#int2 = 1The second de�nition, uses the inheritance concept provided by the metalanguage. Bythe second constraint (#int2 = 1), we require that there exists exactly one instance of int2.We can not refer to this instance by its name, as we could refer to int , but by existentialquanti�cation or by introducing a constant. This instantiation concept is more Smalltalk-like[GR83]. In this paper, we prefer the �rst instantiation concept since it is more explicit. Froma semantical point of view, both instantiations are equivalent.2Atomic expressions are those consisting of a constant operator and an empty operand.3Here, we do not consider the internal structure of Type.10
3.3 Structuring of the MetamodelThe metalanguage provides several structuring mechanisms (e.g. parameterization, inheri-tance) that are also very useful for structuring the metamodel.DataValue[T ]Instancevalue : T8 e1; e2 : DataValue[T ] � e1 = e2 , e1:value = e2:valueThe metaclass DataValue[T ] inherits properties of Instance, i.e. a DataValue is an In-stance. We de�ne DataValue as a generic class over some internal datatype T. DataValuesof a programming language, in contrast to Objects that have a unique identity, share thecharacteristic of extensional equality.We want to introduce BooleanValues and IntegerValues. The instances of the classesBooleanValue and IntegerValue are constituting the carrier sets for the built-in types int andbool . We use the internal data types (B and Z) provided by the metalanguage for this purpose.BooleanValueDataValue[B ]type = bool IntegerValueDataValue[Z]type = intBy the inherited constraint of extensional equality, it is assured, that there are exactlytwo instances of BooleanValue, namely tt and � .tt ;� : BooleanValuett :value ^ : � :value3.4 Abstract MetaclassesAn abstract metaclass is a metaclass that can not be instantiated. It is only allowed to in-stantiate subclasses of an abstract metaclass. Abstract metaclasses are used for the de�nitionof interfaces within the metamodel.Expressiontype : Type#Expression = 0Eval b= [ val ! : #Instance ]Expression is an abstract metaclass as required by the constraint #Expression = 0. Itprovides an interface that has to be realized by all expressions, namely that every expressionhas a type and can be evaluated. This is expressed by the attribute type and the de�nitionof the \virtual" method Eval that results to an Instance. The declaration val ! : #Instancemeans that the variable val is polymorphic, e.g. it is of type Instance or of any class typederived from Instance by inheritance. 11
3.5 Abstract Responsibilities of MetaclassesOne of the main purposes of metamodeling is to provide a complete and abstract descriptionof the entities. We propose to use structuring techniques for this purpose. Consider thefollowing example:PlusExpressionExpressione1; e2 : #Expressione1:type = int ^ e2:type = intEval b= [ inst ! : #Instance ] �[ v ; v1; v2 : IntegerValue j v :value = v1:value + v2:value ^ inst ! = v ] �e1:Eval [inst !=v1] ^ e2:Eval [inst !=v2]Obviously, this is not a good way for the de�nition of the PlusExpression since we needto de�ne for each operator an own metaclass. Therefore, we propose to de�ne a generalmetaclass Operator and instantiate this class in order to obtain the pre-de�ned operators.OperatorargType : seqTyperesType : TypeoutRel : (seq #Instance) 7! (#Instance)8 s : dom outRel � #argType = #s8 i : 1 : :#argType; s : dom outRel � argType(i) = (s(i)):type8 i : ran outRel � resType = i :typeEvalargs? : seq #Instanceinst ! : #Instanceargs? 2 dom outRelinst ! = outRel(args?)The signature of an Operator is de�ned by a sequence of argument types argType and aresult type resType. For example the lessOperator (see below) takes two int expressions andresults to a bool expression. The meaning of an Operator is de�ned by a partial functionoutRel . The constraints in the class Operator state that an Operator can only be applied toInstances of its argument types. The method Eval takes a sequence of instances and deliversthe instance that is yielded by applying the outrel relation to them.lessOperator : OperatorlessOperator :argType = hint ; intilessOperator :resType = bool8 i1; i2 : IntegerValue; b : BooleanValue �(b = lessOperator :outRel(hi1; i2i) ^b:value , (i1:value < i2:value))plusOperator : OperatorplusOperator :argType = hint ; intiplusOperator :resType = int8 i ; i1; i2 : #IntegerValue �(i = plusOperator :outRel(hi1; i2i) ^i :value = (i1:value + i1:value))12
Based on Operator we can now de�ne a CompoundExpression which is an Expressionthat consists of an Operator applied to its operands. The abstract Eval-operation has to beimplemented: the operands are evaluated and the operator is applied to the results.CompoundExpressionExpressionoperand : seq #Expressionoperator : Operator#(operator :argType) = #operandtype = operator :resTypeEval b= [ inst ! : #Instance ] �([ args : seq #Instance ] � (o9 i : 1 : :#operand �[ e : #Expression; inst : #Instance j e = operand(i) ^ inst = args(i) ] �e:Eval [inst=inst !])o9operator :Eval [args?=args])Let us consider a second example for an interface metaentity:Statement#Statement = 0Execute b= [ true ] AssignmentStatementlhs : Variablerhs : Expressionlhs:declaration:type = rhs:typeExecute b= rhs:Eval o9 lhs:AttachAgain, Statement is an abstract metaclass that provides the interface for all kind ofstatements. All concrete Statements, like e.g. Assignment , will inherit from this class. Thedynamic semantics of an Assignment is given by the realization of the \virtual" methodExecute. It states that in order to execute an assignment, the right-hand-side is evaluatedand the resulting value is attached to the variable (see below for the de�nition of Variable)on the left-hand-side.3.6 Intensional and Extensional EntitiesThe di�erence between intensional and extensional entities is demonstrated by the followingexample:A variable declaration is an intensional object, i.e. variable declarations are part of themodeling language. A variable declaration's state remains constant during computation time.The corresponding extensional entity is a Variable. It is linked to an intensional object, itsdeclaration. It is storing run-time information over the variable, i.e. the value the variablecurrently holds. The dynamic semantics of variables is given by the method Attach thatallows to change the value of a variable. It is typical for extensional objects that they providemethods with � lists that serve for altering their state.13
VarDeclvarName : NametypeName : Name�type : Typetype:name = typeNameVariableExpressiondeclaration : VarDeclvalue : #Instance�type : Typetype = declaration:type = value:typeAttach�(value)val? : #Instancevalue 0 = val?Eval b= [ inst ! : #Instance j inst ! = value ]3.7 Integration of di�erent Modeling LanguagesNow consider the class Automaton from Figure 8. Its transitions are labeled with conditionsand actions:Transitionsource; target : Statecond : #Expressionaction : #Statementcond :type = boolExecute b= action:ExecuteA Transition consists of a source and a target state and is labelled with a boolean expres-sion, denoting whether it is can be executed or not. Its dynamic semantics is given by theoperation Execute, executing its action, an arbitrary statement.Automatonstates : F Statetransitions : F TransitioninitialState : State8 t : transitions �ft :source; t :targetg � statesinitialState 2 statesCon�gurationautomaton : AutomatonactualState : StateactualState 2 automaton:statesINITactualState = automaton:initialStateSetActualState�(actualState)newState? : StateactualState 0 = newState?ExecuteStep b= : : :14
An Automaton represents an intensional object, i.e. the states, transitions and its initialstate must be described in an appropriate modeling language. A Con�guration is an exten-sional object that is linked to an intensional object, its automaton. It consists of an attributeactualState holding the state state the automata is residing in. Its dynamic semantics is givenby the methods SetActualState and ExecuteStep describing the behavior of the automaton.3.8 Abstract SemanticsIt might be useful to de�ne semantic objects, such as system states or traces in order todescribe the semantics on a more abstract level. The integration of such objects is straight-forward. Consider a trace of computation for the automata. The elements of the trace wouldbe system states, objects that carry the relevant information about the components of thesystem at one point in time. The relevant information would contain values of variables,automaton states, the chosen transitions, etc. A trace would then consist of a list of systemstates that is updated in every system step. The abstract semantic objects SystemState andTrace can be used to integrate further languages, i.e. it would be straightforward to formulatea temporal logic on basis of traces, enabling us to express abstract behavioral constraints.3.9 Modifying the ModelThe distinction between intensional and extensional entities is apparent if one considers thebehavior of the metaentities. While the dynamic semantics of extensional entities de�nes thesystem dynamics, the dynamic semantics of intensional entities describes, how the structureof the system might evolve. This feature is especially useful in order to describe consistentmodi�cation of the model in the sense of system evolution.Let us consider the following simple example of model modi�cation: the renaming of atype. TypeRenTypeRename�(name)newName? : Namename 0 = newName?Using the operation Rename it is possible to change the name of the class. The problem isthat the model becomes inconsistent since further model elements refer to the modi�ed typeby its old name. Therefore it is necessary to change further modeling elements.In our example, we have to rename the type name of the a�ected variable declarations:VarDeclRenVarDeclRename�(typeName)newName? : NametypeName 0 = newName? 15
A consistent type renaming renames the type itself, as well as all references to it:TypeRen2TypeRename b= [�(name) newName? : Name j name 0 = newName? ] �o9 v : VarDeclRen j v :typeName = name � v :RenameAgain, we take advantage of the reference semantics since we do not need to changefurther 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�erentmodels, the side-e�ects are minimal.ClassTypeattributes : F Attributemethod : F MethodaddMethod b= : : :removeMethod b= : : :GeneralizationsubClass; superClass : Class
Consider for example the deletion of model elements. An element that occurs in di�erentparts of the model must be deleted in all parts. This might cause some more modi�cation. Iffor example a class is deleted from the model, all associations from and to this class must bealso deleted.SystemModelclasses : PClassgeneralizations : PGeneralization: : :RemoveClass�(classes; generalizations)className? : Nameclasses 0 = classes n fc : classes j c:name = className?ggeneralizations 0 = generalizations n fg : generalizationsjg :subClass:name = className? _ g :superClass:name = className?gLiftOperation b= [ class? : Class; method? : Method ; g : Generalizationjmethod 2 class?:method ^ g :subClass = class? ] �(g :superClass):addMethod o9 (g :subClass):removeMethod: : :The (intensional) metaclass SystemModel is used for storing the classes and relationshipsbetween the classes. Using the operation RemoveClass, it is possible to delete a class fromthe system. In this case, it is necessary also to remove the generalization relationships.The second method (LiftOperation) illustrates a typical scenario during software develop-ment: the software engineer recognizes that an operation should be moved from a subclass16
into its superclass. A more sophisticated version of this operation would also consider theimplementation of the operation, such that further attributes and operations used in theimplementation, would be also lifted to the superclass. For a precise de�nition of such anoperation it is necessary to have a complete metamodel that includes also the programminglanguage [KG98].An even more complex situation is the introduction of a design pattern in a softwaredesign. Consider for example the introduction of the bridge pattern (see [GHJV95] for adiscussion of the pattern).Class
operation()
operation()
Abstractor
Class ConcreteImp1
Implementorimp
operationImp()
operationImp()Figure 9: Introducing the Bridge PatternFrom a software engineering point of view, it is very important to consider how designpatterns could be introduced within existing software designs. We believe that our metamodelbased approach could serve as a foundation for the de�nition of such modi�cations of thesystem.4 The Intensional/Extensional DichotomyIn 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-timeinformation (extensional objects). Extensional objects are linked via a special instantiationassociation with intensional objects. In our example, a Variable is an instantiation of aVariableDeclaration, and a Con�guration is an instantiation of an Automaton. The role ofupdating methods is di�erent for these kind of objects. Updating (changing the state) of anintensional object means to manipulate the model, while updating the state of an extensionalobject contributes to the dynamic semantics of one particular model.4.1 Di�erent Instantiation RelationsWe provide two di�erent kinds of instantiation relations in our metamodel approach. On onehand, we have special instantiation associations between the entities of one level of the meta-model. Such a relation is connecting an intensional object with an extensional object. Notethat this is not characterized by a special syntactic construct of the meta language. Neverthe-less it is important to identify these associations properly. We call this kind of instantiationintra-level instantiation. Second, we have the instantiation mechanism of the metalanguage(i.e. lessOperator : Operator). This instantiation, called inter-level instantiation, causes atransition between levels. It represents the instantiation arrow between metamodel level andmodel level, see Figure 2. This instantiation preserves the characteristics of extensionality17
and intensionality, i.e. the instantiation of an intensional object on the metamodel level is anintensional object on the model level.In Figure 10, the di�erent instantiation relations are depicted. There are several views ona 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 inten-sional object.� Within its own level, a semantic object is either intensional, if it is directly re ectedin the syntax of the modeling language, or it is an extension of an intensional object,representing information about the history of a computation.EXTENSIONAL EXTENSIONAL
EXTENSIONAL EXTENSIONAL
instance_of
instance_of
Metamodel Level
Model Level
EXTENSIONAL
EXTENSIONAL
instantiation
instantiationINTENSIONAL
INTENSIO
NAL
INTENSIO
NAL
INTENSIONAL INTENSIO
NAL
INTENSIO
NAL
Figure 10: Instantiation Relations4.2 Implications of the DichotomyIn the following we formulate some guidelines for the construction and evaluation of meta-models. We do not consider these guidelines as obligatory. However, non-conformity of themetamodel with these guidelines should be carefully justi�ed.� Classi�cation of metaentities:The entities of the metamodel should be divided into intensional and extensional enti-ties. The intra-level instantiations (instance of associations) should be distinguished.Normally, their cardinality should be 1 : n from intensional to extensional. Everyintensional and every extensional entity should participate in at most one intra-levelinstantiation. In our running example (see Fig. 8) the entities on the left side areintensional 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 of18
IntensionalA
IntensionalB
ExtensionalA
ExtensionalB
MetamodelLevel
instance_of
instance_of
int_association ext_association -
Figure 11: Compatibility between Intensional and Extensional Entitiesassociation. In statically typed languages the instantiated association (link) once estab-lished remains constant, i.e. an object can not change its type.� Preservation of dichotomy by inheritance:The partition in intensional and extensional entities is preserved by the inheritancerelationship. There exists no (concrete) metaentity that is super-type of an extensionaland an intensional entity. Furthermore, no intensional entity is a super-type of anextensional entity and vice versa.� Re ection of associations between intensional entities via intra-level instantiation:Consider Figure 11: if two intensional entities are connected by an association (int asso-ciation), then this association is re ected by a corresponding association on the exten-sional level (ext association) such that the traversal along the associations is compati-ble, i.e. the diagram commutes in a certain sense. This property is important since theinstance of relationship is re ected on the model-level by the inter-level instantiation(see property 3).4.3 Syntax of the MetalanguageIn this Section, we will give a formal de�nition of (the relevant parts of) the syntax of ourmetalanguage. We will introduce class and object declarations and describe associations onclass and object level.De�nition 1 (Names) Let AttributeName be a set of attribute names and TypeName a setof type names and ObjectName a set of object names:[AttributeName;TypeName;ObjectName]These sets are pairwise disjoint.De�nition 2 (Class Declaration) Let ClassDecl be a set of class declarations:[ClassDecl ]The function name assigns a unique name to each class declaration. The attribute namesof a class declaration are referred by the function attributes . The function getClass deliversfor a type name its corresponding class declaration. The function typeOfAttributes determinesfor each class declaration the type information for its attributes.19
className : ClassDecl � TypeNamegetClass : TypeName 7! ClassDeclattributes : ClassDecl ! PAttributeNametypeOfAttributes : ClassDecl ! (AttributeName 7! TypeName)8 c : ClassDecl � dom(typeOfAttributes(c)) = attributes(c)getClass = className�The classes of a metamodel can be divided strictly into Intensional and Extensional meta-classes. Intensional ;Extensional : PClassDeclIntensional \ Extensional = ?Intensional [ Extensional = ClassDeclDe�nition 3 (Instance Declaration) Let InstDecl be the set of instance declarations.[InstDecl ]An instance declaration consists of an object name and a class declaration. Thus, we havethe two projection functions:instName : InstDecl � ObjectNametype : InstDecl ! ClassDeclDe�nition 4 (Association of Class Declarations) Using the function assoCD , we canselect for an attribute name and a class declaration the class declaration that is associatedwith the �rst class via the attribute name:assoCD : AttributeName ! (ClassDecl 7! ClassDecl)8 a : AttributeName � dom(assoCD (a)) = fcl : ClassDecl j a 2 attributes(cl)g8 a : AttributeName � 8 cr : dom(assoCD (a)) �(assoCD (a))(cr) = getClass(typeOfAttributes(cr)(a))De�nition 5 (Instantiation Relations) We distinguish a special kind of class association,namely those between extensional and intensional class declarations. These are the intra-levelinstantiation relations on the metamodel level.instCD : P assoCD8 a : AttributeName; int ; ext : ClassDecl j (ext 7! int) 2 assoCD (a) �(ext 2 Extensional ^ int 2 Intensional) ,(ext 7! int) 2 instCD(a)8 a : AttributeName �8 ext1; ext2 : dom(instCD (a)) �instCD(a)(ext1) = instCD (a)(ext2)) ext1 = ext2The second constraint states that there is for every intensional class at most one associatedextensional class. 20
De�nition 6 (Association of Object Declarations) Using the function assoOD , we canselect for an attribute name and an instance declaration the set of instance declarations thatare associated with the instance via the attribute name:assoOD : AttributeName ! (InstDecl 7! P InstDecl)8 a : AttributeName �assoOD (a) = fir : InstDecl ; pil : P InstDecl j a 2 attributes(type(ir)) ^pil = fil : InstDecl j assoCD (a)(type(ir)) = type(il)g � (ir ; pil)gAn important semantical property of assoOD is given in De�nition 15.4.4 Semantics of the MetalanguageIn this section, we describe the (relevant parts of) the semantics of our metalanguage, dealingwith the semantics of classes as well as with objects and their mapping to according valuesand semantic relations between objects. The de�nitions in this section are similar to those inthe semantics of Object-Z as given in [Gri96].De�nition 7 (Semantic Domain) The semantic domain is given by the set O of all objectreferences.[O ]Note that we do not distinguish between primitive values and object values, but for reasonsof simplicity regard all values as objects.De�nition 8 (Valuation) A variable valuation is an assignment of semantic values to at-tribute names. A valuation de�nes a state of an object.Valuation == AttributeName 7! ODe�nition 9 (Object Semantics) The semantics of an instance declaration is de�ned bythe function objSem that assigns to each instance declaration an object (reference). It ispossible to determine the corresponding class declaration of each object using the functionclassOfObject .objSem : InstDecl ! OclassOfObject : O ! ClassDeclclassOfObject � objSem = typeDe�nition 10 (Semantics of a Class) The semantics of a class is the set of all possiblevaluations that might be assigned to an object of the class. The semantics of a class is de�nedby the function classSem that assigns each class declaration the set of all possible bindings.The possible valuations have to be compatible with the class declaration.Note, that the set of valuations is usually restricted by class constraints.classSem : ClassDecl ! PValuation8 cs : ClassDecl ; v : Valuation j v 2 classSem(cs) �dom v = attributes(cs) ^(8 a : dom v � classOfObject(v(a)) = getClass(typeOfAttributes(cs)(a)))21
De�nition 11 (Object Map) The value of an object is de�ned by the function objectMapassigning the valuation for each object. Note, that the function objectMap evolves duringexecution time. Furthermore it is possible that two di�erent objects have the same value, i.e.we have a reference semantics.objectMap : O ! Valuation8 o : dom objectMap � (dom(objectMap(o))) = attributes(classOfObject(o))8 o : dom objectMap � objectMap(o) 2 classSem(classOfObject(o))The �rst constraint states that the Valuation of an object has to be compatible with thestructure as de�ned in the class. This means that for all attributes of the class declaration,there exists a value on instance level.The second constraint ensures that the state of an object is compatible with the semanticsof its class. Practically, this means that the object's behavior respects the class invariants.De�nition 12 (Static Connection between Extensional and Intensional Entities)The value of an instantiation relation between an intensional class and an extensional classmust be constant.8 a : AttributeName; o : O jclassOfObject(o) 2 (dom(instCD (a))) �8 v1; v2 : ran objectMap � v1(a) = v2(a)De�nition 13 (Value of an Attribute) Given an attribute name and an object, it is pos-sible to determine the value of an attribute. This corresponds to de-referencing an object.The function deref is de�ned as follows:deref : AttributeName ! (O 7! O)8 a : AttributeName; o : O � deref (a)(o) = objectMap(o)(a)De�nition 14 (Associations on Class Semantics Level) The function assoCS deliversfor an attribute name and a valuation the valuation of the object that is actually assigned tothe attribute name:assoCS : AttributeName ! (Valuation 7! Valuation)8 a : AttributeName �dom(assoCS (a)) = fv : Valuation j a 2 dom vg ^(8 v : dom(assoCS (a)) � assoCS (a)(v) = objectMap(v(a)))De�nition 15 (Unambiguity of assoOD) Given an association relation assoOD betweenan intensional and an extensional object. The intensional object declarations delivered byassoOD refer to the same semantical object:8 a : AttributeName �(8 ir : dom(assoOD (a)) �8 il1; il2 : assoOD (a)(ir) � objSem(il1) = objSem(il2))22
Model Level
LevelMetamodel
Semantics of Metalanguage
Syntax of Metalanguage
: : :g: : :g
true : InstanceassoCD (type)name : Name
bool : Typeotrueobool
Type Instancetype : Typevalue : Vtrue:type = boolassoOD (type)
ff(type 7! obool); (value 7! o� )g;f(type 7! obool); (value 7! ott)g;
type typederef (type)classSem classSem
objectMap objectMapobjSem objSemclassOfObject classOfObject
assoCS (type) f(type 7! onat); (value 7! o0)g;
bool:name = Bool
ff(name 7! oBool)g;f(name 7! oNat )g;
Figure 12: Example4.5 Properties of the MetalanguageBased on the formal de�nitions in the previous sections, we will now prove some propertiesof the metalanguage that are useful for the understanding of the intensional/extensionaldichotomy.In Figure 4.5 an example of an intensional (Type) and a related extensional entity (In-stance) on the metamodel level is depicted. These are instantiated on the model level tothe objects bool and true. Accordingly, true is an extension of bool on the model level. Theproperties proved in this section hold of course for all pairs of intensional and extensionalobjects.Property 1 (Compatibility of Instance and Class) Every state an object can reside inis well-de�ned w.r.t. the object's class semantics:8 i : InstDecl � objectMap(objSem(i)) 2 classSem(type(i))Proof:8 i : InstDecl �(objectMap(objSem(i)) 2 classSem(type(i))), (by Def. 14)(objectMap(objSem(i)) 2 classSem(classOfObject(objSem(i)))), (by Def. 11 )(objSem(i) 2 dom objectMap), (objectMapis a total function)true 23
Property 2 (Compatibility of Associations) The association relation on the syntacticlevel is preserved by the semantics.8 cd : ClassDecl ; a : AttributeName j a 2 attributes(cd) �8 v : classSem(cd) �assoCS (a)(v) 2 classSem(assoCD (a)(cd))Proof:8 cd : ClassDecl ; a : AttributeName j a 2 attributes(cd) �8 v : classSem(cd) �assoCS (a)(v) 2 classSem(assoCD (a)(cd)), (by Def. 14)objectMap(v(a)) 2 classSem(assoCD (a)(cd)), (by Def. 4)objectMap(v(a)) 2 classSem(getClass((typeOfAttributes(cd))(a))), (by Def. 10)objectMap(v(a)) 2 classSem(classOfObject(v(a))), (by Def. 11)v(a) 2 dom objectMapProperty 3 (Re ection of Associations on Object Level) An association speci�ed onclass level is re ected by a relation between objects on object semantics level:8 a : AttributeName � assoCD (a) � classOfObject = classOfObject � deref (a)8 a : AttributeName; o : O �assoCD (a)(classOfObject (o)) = classOfObject(deref (a)(o)), (by Def. 13)assoCD (a)(classOfObject (o)) = classOfObject(objectMap(o)(a)), (by Def. 4)getClass(typeOfAttributes(classOfObject(o))(a)) = classOfObject(objectMap(o)(a)), (by Def. 10)classOfObject(objectMap(o)(a)) = classOfObject(objectMap(o)(a)), (by Def. 10)objectMap(o) 2 classSem(classOfObject(o)), (by Def. 11)trueProperty 4 (Compatibility of Object Associations with Class Semantics)Associations on class semantics level are compatible with associations on object semanticslevel: 8 a : AttributeName �assoCS (a) � objectMap = objectMap � deref (a)24
Proof:8 a : AttributeName; o : O �assoCS (a)(objectMap(o)) = objectMap(deref (a)(o)), (by Def. 13)assoCS (a)(objectMap(o)) = objectMap(objectMap(o)(a)), (by Def. 14)objectMap(objectMap(o)(a)) = objectMap(objectMap(o)(a))In summary, we have proved the following properties of our metalanguage:1 The semantics of an object is compatible with the semantics of the object's class.2 Every association between classes is re ected by a compatible relation between valua-tions on the semantical level.3 The instantiation relation between an extensional and an intensional object on the meta-model level is re ected by a compatible relation between corresponding extensional andintensional objects on the model level, i.e. the intra-level instantiation is also instanti-ated by an inter-level instantiation.4 Associations between semantics objects on the model level are compatible with the classsemantics of the participating objects.In this subsection we have not de�ned the syntax and semantics of a concrete meta-language but we have rather formulated the requirements on a metalanguage to �t in ourapproach. Object-Z, for example, ful�lls all these requirements. Note, that most other meta-modeling 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 theseapproaches.5 DiscussionIn the previous sections we discussed our metamodeling technique. The major contributionsof this work are the following: We advocate the usage a of a formal metalanguage andwe elaborate the concepts the metalanguage should provide. Based on these facilities of themetalanguage, we show how the these techniques can be successfully applied for the de�nitionof metamodels. Here, one of the major aspects is the distinction between intensional andextensional entities. Both kinds of entities and their instantiations have been investigated indetail in Section 4. In contrast to existing metamodels, we are also considering the dynamicsemantics of a metamodel.5.1 Evaluation of the Metamodeling TechniqueIn this subsection, we will evaluate how the proposed techniques contribute to the developmentof \good" metamodels. Therefore, we discuss how generally accepted quality criterias are met:� Structuring/Modularity: Can the metamodel be decomposed into separate parts thatcan be analyzed and understood separately? Does a change in the metamodel remain25
local to one or at most a few entities or is the whole architecture of the metamodelconcerned?The localization principle supports the structuring of the metamodel, since all relevantaspects of a metaentity can be described using a single concept. Generally, we propose aloose coupling of the metaentities realized by encapsulation and associations. Based onthis technique we de�ne interfaces using abstract metaclasses and de�ne the semanticsof external entities. The facade pattern [GHJV95] can be applied successfully for high-level structuring of the metamodel. Not only static but also dynamic responsibilitiescan be de�ned.� Extensibility: Is there a well-de�ned way of extending the metamodel? Is it possible toextend the metamodel by arbitrary concepts?The object-oriented structuring principle supports the extension of a metamodel. Theextension can be achieved systematically by applying the methodological considerationsdescribed in this paper. Since we propose to de�ne the metamodel formally we achievea precise semantics of the modeling concepts such that extension points (hot spots) areprecisely de�ned.� Description language(s): How many di�erent description languages are used for thede�nition of the metamodel. Are those languages well integrated?Even though we are using both, class diagrams and a formal metalanguage for thede�nition of the metamodel, class diagrams serve only for illustrating purposes andthe semantics of the metamodel is completely determined by the formal metalanguage.This means, we have a single-language approach which is powerful enough to cover allaspects of a metamodel. Consequently the integration problem of di�erent metalan-guages, in contrast to the UML metamodel, does not exist. The correlation betweenabstract syntax, static and dynamic semantics is already clear from the de�nition of themetalanguage. Furthermore our approach avoids self-referencing problems.� Quality of de�nitions: Are all aspects of interest covered by the metamodel (complete-ness)? For instance, is it possible to describe the behavior of a semantic entity? Arethe de�nitions formal, e.g. written down in a formal language (in contrast to naturallanguage)? Is the coupling between the semantic entities minimal, e.g. is it possible toreplace parts of the metamodel without changing the rest of the metamodel?All relevant aspects can be covered by the metamodel. We have used the formal, math-ematical description language Object-Z. The coupling between the semantic entities isrealized by class interfaces and associations between classes, abstracting from the in-ternal structure of a class. This enables us to replace parts of the metamodel in awell-de�ned way without changing the rest of the metamodel.� Correctness: What kind of validation support exists for the metamodel?Formal techniques, in contrast to informal ones, enable us to think about correctnessand consistency. Some of the consistency checks of the metamodel can be done auto-matically (type checking) and interesting properties that follow from the de�nitions ofthe metamodel can be proved formally. The main advantage of a formal metalanguageis that it serves as a tool for the precise de�nition of the metaentities.26
� Comprehensibility: Can the metamodel be understood by people who are not expertsin the metalanguage?We believe that especially the graphical representation of the metamodel using classdiagrams can be very helpful in order to get an overview of the metamodel. This shouldenable also non-experts in formal speci�cation techniques to understand the metamodel.In order to get an insight into the details, it is nevertheless necessary to have an ideaabout the logic used in the metalanguage.� Model-Metamodel-Relationship: What models can be expressed in terms of the meta-model? Is there a systematic way, method or guideline describing how an arbitrarymodel can be expressed in the metamodel? In how far must the original model bechanged in order to �t in the metamodel?We believe that the presented methodology is applicable to all kinds of models followinga layered approach, i.e. di�erent levels and instantiation relations between these levels.It provides a systematic and formal way for the classi�cation and description of modelentities on one level and for the instantiation relation between levels. The original modelmust not be changed, but it has to be viewed in an object-oriented way.� Strictness of layers: are templates and their instances allowed to coexist at the samelevel?We have distinguished two kind of instantiations. Intensional and extensional entitiesare indeed allowed to coexist at the same level, while by instantiating a concept weswitch to a lower level, i.e. coexistence on the same level is not possible in this case. InSection 4 we have elaborated this aspect in detail. The conceptual distinction betweenintensional and extensional entities with respect to the instantiation relationship enablesus to de�ne the relationship between intensional and extensional entities.5.2 Bene�ts of the presented approachOne bene�t of our approach is the suitability for the precise de�nition of multiple viewlanguages. Besides this, our approach can be useful for several other areas in software engi-neering. Using the proposed technique we are able to de�ne a complete model of the systemthat comprises not only the intensional parts but also the extensional ones. Transformationof models is naturally expressed by intensional-object-manipulating methods. I.e. adding atransition to an automaton would be described by a method AddTransition, manipulatingthe attribute transitions. Furthermore, context conditions for model transformation can beexpressed, e.g. the impact of a change request in one model on other models can be speci�ed.As we have shown in Section 3 this enables us to de�ne system evolution as well as the evolu-tion of objects. The dependencies, the impact of changes and the system evolution invariantscan be expressed. Semantic preserving model transformations are also in the scope of thepresented approach. Using our technique we are able to de�ne the conditions under which amodel transformation is semantically correct.Methodological rules or style guides can be incorporated into the metamodel. Thismeans even if a model is syntactically and semantically correct, it might be not conformto some further conventions (e.g. naming conventions), or it might include some unwantednon-determinism, some methods might be partially de�ned and can not be called in everystate of an object etc. These important information can be expressed using our approach.27
Tracing through di�erent development phases can be expressed by storing the history of amodel element. In this way, the evolution of a modeling object might be traced from analysisdown to implementation.5.3 Comparison to other ApproachesThe Uni�ed Modeling Language is a set of object-oriented modeling languages [UML97]. Therelationship between the modeling languages is described by a metamodel [USE97]. Tech-nically, the abstract syntax of UML is given by means of class diagrams, the consistencyconstraints are de�ned by OCL formulas [OCL97], and the dynamic semantics is explainedin natural language. We believe that the UML is a very important progress towards a preciseunderstanding of object-oriented modeling techniques. In particular our work [KG98, MK98]is based on it. In contrast to the UML, we are using a single formal metalanguage for thede�nition of object-oriented modeling languages. In this way, we are avoiding self-referencingproblems and achieve a precise semantics.The Meta Object Facility (MOF) [MOF97] is a meta-metamodel (a model for the de�ni-tion of metamodels). Its key-goal is to provide means for extensionality and self-discoveryin systems. It addresses the manipulation of meta-data, e.g. the creation and retrieval ofmetaentities. MOF is described by a combination of UML notations, CORBA interfaces,explanatory text and constraints given in OCL. Our approach is as well applicable for thede�nition of a meta-metalanguage, like MOF. Basically the advantage of our approach is theutilization of a formal language for the de�nition of two layers and also the precise de�nitionof dynamic semantics.Atkinson [Atk97] describes a metamodeling framework. He also identi�es the problem ofan entity being viewed as both, instance and template4 and therefore introduces the conceptof clabject. A clabject comprises an intensional and its extensional entity. The instantiationof clabject is not covered. As an additional di�erence to our work, Atkinson claims thatoperations and methods are unimportant for metamodeling in practice, while we advocatetheir bene�t for the description of system dynamics and evolution. The strictness of layers isre ected in our approach by the strict separation of the intensional and extensional objectsin every level of abstraction.5.4 Metamodeling and Denotational SemanticsWe 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 acentral role.5In 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 thesyntactic constructs of the abstract grammar. The dynamic semantics (denotation) is de�nedby assigning mathematical objects from the semantics domain (usually sets and functions) tothe syntactic constructs. It is remarkable, that the signature of the semantic functions usuallycomprises an explicit state and delivers a state. This is necessary, because in set theory, thereis no explicit notion of state.4Template and Instance correspond to intensional and extensional objects in our work.5We would like to point out that the presented approach is not a transformational one, i.e. we do not aim attranslating models in di�erent languages into one single language (the metalanguage), but we are identifyingthe concepts common to the di�erent languages and express them in the metalanguage.28
In the presented approach, the abstract syntax of a language is re ected by the attributesand associations of the extensional objects. The static semantics is given by additional sec-ondary attributes and constraints on the attributes of the class. The dynamic semantics isgiven by methods manipulating the extensional objects. The extensional objects are the cor-respondents to the state in the denotation functions. A comparison between our approach tometamodeling and denotational semantics is given in Figure 13.Abstract Syntax Static Semantics Dynamic SemanticsMetamodeling Class diagrams Object-Z state invariants & Object-Z methodsObject-Z classes & secondary attributes &attributes axiomatic de�nitionsDenotational Abstract Grammars Validity conditions for Meaning FunctionsSemantics constructs of the from constructs ofabstract grammar abstract grammarinto semantic domainFigure 13: Metamodeling and Denotational SemanticsWe believe that these parallels have not become apparent so far because of the neglect ofdynamic semantics in metamodeling. In our opinion, the presented approach o�ers essentialadvantages to the denotational semantics approach, because it provides the full power ofobject-orientation for the description of the semantic domain, rather than simple set theory.References[Atk97] Colin Atkinson. Meta-modeling for distributed object environments. In First InternationalEnterprise Distributed Object Computing Workshop, EDOC'97. IEEE Computer SocietyPress, 1997.[CDI+97] Stephen Crawley, Scott Davis, Jaga Indulska, Simon McBride, and Kerry Raymond. Meta-meta is better-better! In Workshop on Distributed Applications and Interoperable Systems(DAIS), Cottbus, Germany, September 1997.[Don96] Jin Song Dong. Formal Object Modelling Techniques and Denotational Semantics Studies.PhD thesis, Department of Computer Science, University of Queensland, May 1996.[DRS94] Roger Duke, Gordon Rose, and Graeme Smith. Object-z: a speci�cation language ad-vocated for the description of standards. Technical Report 94-45, Software Veri�cationResearch Centre, Department of Computer Science, The University of Queensland, St.Lucia, QLD 4072, Australia, December 1994.[GHJV95] E. Gamma, R. Helm, R. Johnson, and J. Vlissides. Design Patterns. Elements of ReusableObject-Oriented Software. Addison Wesley, 1995.[GK98] R. Geisler and M. Klar. A Semantic Foundation for the Integration of Statecharts and Z.Technical Report (to appear), TU Berlin, Fachbereich Informatik, 1998.[GR83] A. Goldberg and D. Robson. Smalltalk-80 - The language and its implementation. Addison-Wesley, 1983.[Gri96] A. Gri�ths. A semantics for a simple sub-language of Object-Z. Technical Report 96-33,Software Veri�cation Research Centre, Department of Computer Science, The Universityof Queensland, 1996. 29
[KG98] M. Klar and R. Geisler. A Meta-Model for Object-oriented Systems. Technical Report (toappear), TU Berlin, Fachbereich Informatik, 1998.[May88] B. Mayer. Introduction to the Theory of Programming Languages. Prentice-Hall, 1988.[MK98] S. Mann and M. Klar. A metamodel for object-oriented statecharts. In The Second Work-shop on Rigorous Object Oriented Methods, ROOM 2 (to appear), May 1998.[MOF97] Meta Object Facility (MOF) Speci�cation, October 1997. Joint revised submission to theObject Management Group (OMG), http:/www.omg.org.[OCL97] The Object Constraint Language { Version 1.1, September 1997. Part of [UML97].[Ode95] James Odell. Meta-modeling. In OOPSLA'95 Workshop on Metamodeling in OO, October1995.[ �Ove98] Gunnar �Overgaard. A formal approach to relationships in the uni�ed modeling language. InPSMT { Workshop on Precise Semantics for Software Modeling Techniques in conjunctionwith ICSE 98, Kyoto, Japan, 1998.[UML97] The Uni�ed Modeling Language (UML) Speci�cation { Version 1.1, September 1997. Jointsubmisstion to the Object Management Group (OMG), http://www.rational.com/uml/.[USE97] UML Semantics { Version 1.1, September 1997. Part of [UML97].
30