Supporting and Applying the UML Conceptual Framework

Supporting and Applying the UML Conceptual Framework Colin Atkinson Fraunhofer Institute for Experimental Software Engineering D-67661 Kaiserslautern, Germany [email protected]

Abstract. The Unified Modelling Language (UML) ostensibly assumes a four level (meta) modelling framework, both for its definition and for the conceptual context in which its users operate. In practice, however, it is still dominated by the traditional two level (model + data) view of object modelling and neither supports nor applies the four level framework properly. This not only diminishes the clarity of the UML semantics, but also complicates the task of those users who do wish to fully embrace a multi-level approach. After outlining the characteristics of the intended conceptual framework, and the problems resulting from the UML’s current two-level bias, this paper presents three simple enhancements to the UML which provide the required expressive power for multi-level modelling. The paper then goes on to discuss issues in the application of the conceptual framework within the UML’s own definition.

1

Introduction

Although the current version of the Unified Modelling Language (UML) [1] ostensibly assumes a four level conceptual framework, in reality it is very much dominated by the traditional two-level view of object modelling (i.e. model + data). The resulting asymmetry is manifest in two ways; first by the lack of generalized multi-level modelling features, and second by the failure to properly apply the four level conceptual framework in the definition of the UML semantics. To a certain extent the second problem is a symptom of the first, because the UML is used in its own definition. In other words, the first (and probably the most important) application of the UML conceptual framework is in the definition of the UML itself. Both of these problems have consequences for users of the UML. The first problem complicates the task of users who wish to work beyond the traditional “model” and “data” levels and apply the UML framework in its full generality. Instead of being able to use a notation which recognizes and supports the fundamental symmetry between the levels, such users are forced to try to adapt features which in practice were designed to support only two levels. This results in class diagrams which are overly complicated and inconsistent in their use of object modelling principles. The second problem not only unnecessarily complicates the semantics of the UML, but also causes confusion about what really is the intended UML conceptual framework. On the one hand users are presented with a “framework” ostensibly based on four levels, but a notation which really only supports two.

Fortunately, the required expressive power can be attained with only a few minor enhancements to the existing notation. The following section provides an overview of the conceptual framework underpinning the UML. Section 3 then proposes three simple notational enhancements which significantly increase the UML’s support for this multi-level framework. Finally, Section 4 describes problems in the way the UML conceptual framework is used in its own definition.

2

The UML Conceptual Framework

The current form of the conceptual framework underpinning the UML was driven by the OMG standardization requirements, particularly the need for alignment with the jointly standardized Meta Object Facility (MOF) [2], and the desire to be compatible with prevailing industry practice [3], [4], [6]. It is no accident that the MOF and the UML share the same underlying conceptual framework, illustrated in Fig. 1. Not only did they share many of the same contributors, but the last phase in the UML and MOF development process involved an extensive “alignment” activity which aimed to bring the two proposals into agreement. (M3) Meta-meta-model (MOF) instance_of

instance_of

(M2) Meta-model (UML Meta-Model)

(M1) Model instance_of

(M0) Data

Fig. 1. UML/MOF Conceptual Framework

An issue which always arises in a discussion of this type of framework is the confusion surrounding the commonly used terminology. The problem is that the word “meta” tends to be used in both an absolute sense to indicate a model’s position in the level hierarchy, and in a relative sense to indicate a model’s relationship to another model. For example, the top level in such a four level hierarchy is typically called a “meta-meta-model”, because it is a meta-model for a meta-model. However, it can just as easily be viewed as (and hence called) a meta-model, or for that matter simply a model. The basic problem is the asymmetric use of terminology across the levels. To avoid such confusion in this paper we either use the alphanumeric labels shown on the diagram in Fig. 1, or the names “MOF” and “UML meta-model” for the top level and second level, respectively.

The basic purpose of the MOF, at the top (M3) level, is to facilitate the creation of object-oriented meta-models at the level below. Many of the concepts appearing in the MOF are thus familiar object-modelling concepts such as Class, Association and Operation etc. Fig. 2 illustrates the MOF element, Class: Class isSingleton : Boolean isVisible ()

Fig. 2. Typical M3 level element

This is actually a descendent of numerous other elements in the MOF, and has various other inherited attributes and methods not shown in Fig. 2. IsSingleton happens to be a local attribute of Class, while isVisible() is an inherited method. Since the concepts used in the creation of a model must all be defined somewhere (i.e. everything must be an instance of something), the MOF is viewed as being an instance of itself [2]. The UML meta-model, at the second (M2) level, is regarded as being an “instanceof” the MOF. Its function is to describe the abstract syntax of the modelling concepts provided by the UML. Not surprisingly, since the UML is also intended to support object modelling (among other things) the part of the UML meta-model describing the object modelling features is very similar to the MOF. For example, the Class concept also appears in the UML meta-model, although with different attributes: Class isActive : Boolean

Fig. 3. Typical M2 level element

Class diagrams are only one part of the UML, and the UML meta-model naturally has other packages describing the other areas. Fig. 4, is a typical example of the kind of element that might appear in an M1 level user model. This level is often called the “model” level, and is viewed as being an “instance_of” the UML meta-model: Person name : String birth_date : Integer address : String age() : Integer

Fig. 4. Typical M1 level element

The bottom (M0) level contains the actual entities that appear in the final objectoriented program or database. This level is often therefore referred to as the “data level”, and is viewed as being an instance of an M1 model. A typical element at this level is shown in Fig. 5. President : Person name = “Bill Clinton” age = 1952 address = “White House”

Fig. 5. Typical M0 level element

Fig. 5 also shows the UML convention for distinguishing an “instance” from a “type” (i.e. template). The same graphical symbol is used in both cases, but the names of instances are underlined. 2.1

Built-in Extension Mechanism

The part of the UML which most clearly illustrates its two level bias is the so called built-in extension mechanism. The purpose of this mechanism is to enable users to customize the UML for their specific needs by extending the set of available modelling concepts. Since it is itself an object model, the UML meta-model is already inherently extensible at the M2 level through the normal object-oriented specialization mechanism. However, the UML documentation downplays this approach to extension, and instead encourages users to define extensions indirectly at the M1 level in terms of three special “built in” extension features: stereotypes, tagged values and constraints. These essentially provide an elaborate way of simulating M2 level specializations at the M1 level. Stereotypes Stereotypes provide a way of classifying model elements in terms of a classifier that is an implicit component of the UML meta-model. A stereotype can therefore be thought of as a “virtual” or “pseudo” M2 class that is a specialization of an explicit M2 class. It follows that the names of stereotypes, which are shown in guillemets, cannot clash with the names of explicit UML meta-model elements. In principle, stereotypes can be applied to any kind of model element appearing in the UML meta-model. Fig. 6 shows an example of a stereotype «Testable_Class » applied to a class, Country. Stereotypes are never defined separately, but always in terms of their application to a stereotyped model element. The example indicates that Country is not an ordinary class, but is a special kind of class that has the stereotype «Testable_Class». This obviously is meant to designate the fact that the class can be tested, which is only true for executable classes. Some classes, like abstract classes, are not executable.

«Testable_Class » Country name : String creation_date : Integer population : Integer age() : Integer

Fig. 6. Stereotyped class

The stereotype applied to Country in Fig. 6 is user defined. Users can introduce new stereotypes at any time during their modelling work simply by assigning a stereotype name to a model element. The UML also has a predefined set of stereotypes known as standard elements. Obviously the names of user defined stereotypes cannot clash with those of predefined stereotypes. Tagged Values The UML allows arbitrary properties to be assigned to M1 level model elements at any time during the modelling process. Such properties are known as tagged values and take the form of tag/value pairs with the syntax “tag = value”. A comma-separated list of such tag names and tagged values inside a pair of braces is known as a property specification, and appears under the name of the model element possessing those properties. Fig. 7 extends the class in Fig. 6 with tagged values to indicate that the class Country has two associated properties, tested which has value 10.12.95, and known_bugs which has value 2. These are properties of the class and are not passed on to its instances. They consequently correspond to M2 level attribute values. «Testable_Class » Country {tested = 10.12.95, known_bugs = 2} name : String creation_date : Integer population : Integer age() : Integer

Fig. 7. Stereotyped class with tagged values

Tagged values are often associated with stereotypes, as in this example. When this is the case, the assignment of a particular stereotype to a model element also mandates the provision of values for the corresponding tags. Like stereotypes, there are a certain number of predefined tagged values which form part of the UML standard elements. Constraints Constraints are much like stereotypes in that they define special variants of a given type of model element. However, in contrast with stereotypes, constraints define the precise conditions that must be met by the variant. Thus, for example, “disjoint” is a

constraint that can be applied to generalization relationships to indicate that the resulting subclasses have no instances in common. A generalization subject to this constraint is still a generalization, but with the additional properties specified by the constraint. In the case of stereotypes, on the other hand, the characteristics that are implied by the stereotype (e.g. Testable_Class) are not formally specified as part of the UML model. Constraints can also be attached to stereotypes directly, in which case every model element possessing that stereotype must also adhere to the associated constraint(s). Although they can be applied to any generalizable element, in practice they tend to be most often applied to relationships. In particular, all the predefined constraints (standard elements) apply to some kind of relationship, or relationship components (e.g. link end). 2.2

Extensions versus Variants

Whenever one or more of these special “built in” extension features is used within an M1 level model, the result is called a “UML extension.” A UML extension represents a customization of the UML with modelling concepts specialized for the domain of interest (e.g. Testable_Class, tested, known_bugs etc.). The UML documentation contains two predefined UML extensions, one for business process modelling, and the other for supporting the classic Objectory process [5]. As noted above, since the UML meta-model is an instance of the MOF (i.e. an object model), it can be extended directly just like any normal class diagram. Such an extension of the UML meta-model is known as a “UML variant’. There is thus a distinction between a “UML extension”, which is based on an M1 level application of the “built in” extension features described above, and a “UML variant”, which is a direct M2 level extension of the UML meta-model. The UML documentation makes clear its preference for the former. So much so, in fact, that while it provides an elaborate set of notational features for creating UML extensions, it largely ignores the notational needs of UML variants. A clean and consistent graphical description of a UML variant, indeed of the UML meta-model itself, therefore requires the use of some minor notational enhancements of the kind described in the following section.

3

Supporting a Multi-level Modelling Framework

The UML documentation makes clear the fundamental importance of the typeinstance dichotomy in the UML (page 11 in the UML notation guide) [1]. However, problems arise if this dichotomy is not applied uniformly, and with great care, when there are more that two levels in the modelling framework. The whole point of a meta-model is to define the concepts from which models in the layer below are created. Thus, by definition, every element, in every model, at every level is an instance of something else (assuming that the top-level is an instance of itself). Moreover, it follows that every instantiatable model element (in levels M1 and above) is both a type and an instance. In terms of the examples in Sect. 2, not only is President an instance, but the M1 level element Person, the M2 level element Class,

and the M3 element Class are also instances. Moreover, apart from President, each of these elements is both an instance and a type (i.e. both an object and a class). The simple type-instance dichotomy and associated notation that worked in a twolevel framework is consequently no longer adequate for a multi-level framework. For example, a simple application of the rule that the names of instances are underlined would result in the name of every model element being underlined. Also, the current UML notation forces the features of a model element to be depicted in different ways depending on whether it is being viewed as a type or as an instance. For example, since Person is an instance of the M2 element Class, it is perfectly legal UML to treat it as an object and provide a value for its isActive attribute: Person : Class isActive = False

Fig. 8. Instance view of Person

However, in the type view of Person (Fig. 9), the only way to show the value for the attribute isActive is in the form of a tagged value: Person {isActive = False} name : String birth_date : Integer address : String age() : Integer

Fig. 9. Type view of Person

At least there is a way to show meta-attribute values in the type view of a class. However, if Person also had a method instance; that is, if Class had a method type, such as the method Example() illustrated in Fig. 10, there is no way this could be shown in the type view of Person using the current notation. Class isActive : Boolean Example() : Boolean

Fig. 10. Variant of UML metaclass, Class, with example method

The basic problem with the current version of the UML notation is that it fails to reconcile the type and instance facets of instantiatable model elements, and fails to apply the basic tenets of the type instance dichotomy uniformly across the different levels of the conceptual framework. However, this can be rectified quite easily with the three simple enhancements described in the following subsections.

3.1

Instance_Of Relationship

The first enhancement does not really require an addition to the UML notation, as such, but rather an extension of the way in which an existing feature is used. As illustrated in Fig. 5, the UML already incorporates a textual representation for the instance_of relationship in the form of the traditional “:” operator. By simply generalizing the use of this feature to all levels, as in Fig. 8, the type of any model element, at whatever level, can be uniformly identified. Thus, for example, it is possible to indicate that the M1 element Person is an instance of the M2 element Class from Fig. 3 as follows: Person : Class name : String birth_date : Integer address : String age() : Integer

Fig. 11. "Instance_of" notation

Name Underlining Clearly the convention of underlining the names of instances no longer makes sense in a multi-level framework because every model element is an instance. However, the underlining of names still has a useful role to play. The reason is that although every model element is an instance, not every model element is a type. Many model elements, including all those at the M0 level, are not instantiatable and thus do not have a type facet. It makes sense, therefore, to use the underlining of names to distinguish instantiatable elements (with both an instance and a type facet) from noninstantiatable elements (without a type facet). Obviously, to remain faithful to the intent of the current underlining rule, it is the names of the latter that are underlined. An example of a non-instantiatable model element which occupies a level above M0 is a specific stereotype instance such as Testable_Class: Testable_Class : Stereotype

Fig. 12. Stereotype instance

3.2

Class/object Duality

As mentioned above, in a multi-level modelling framework, instantiatable model elements have both an instance facet and a type facet, both of which are equally valid. A way of reconciling these two facets notationally is offered by the 3D visualization of an instantiatable model element as a cube:

Type (class) view

Instance (object) view

Fig. 13. 3D visualization of instantiatable element

The right hand face of this cube represents the instance (or object) facet of the model element, and contains the attribute values and method instances derived from the element from which it was instantiated. The left hand face represents the type view of the model element, and contains the attributes and method (types) which its instances will receive. By “flattening” this cube into two dimensions we obtain a representation of model elements capable of handling both facets of an instantiatable element. The basic convention is that “instance” related features are indented with respect to the “type” related features to convey the idea that they are on the right hand face of the cube. Name attributes attribute values method types method instances

Fig. 14. Generalized notation

This is the generalized notation for model elements in a multi-level modelling framework. It allows the type and instance facets of a model element to be shown together in a consistent, uniform way at any level. Fig. 15 shows how this notation would be used in the case of the class Person.

Person : Class name : String birth_date : Integer address : String isActive = False age() : Integer

Fig. 15. Generalized notation applied to Person

Class Scope Attributes and Methods The UML supports the concept of so called “class scope” attributes and methods, which in C++ correspond to static data members and static functions respectively. A class scope feature (i.e. method or attribute) differs from a normal feature in that only one instance exists in the final running system, regardless of the number of instances of the class. In a sense, therefore, it belongs to the class rather than to the individual instances of the class. Indeed, this is precisely how class-scope entities are represented in languages such as Smalltalk which allow classes to exist at run-time. In Smalltalk a class-scope attribute would be implemented as a class instance variable, and a class scope method as a class method. From the perspective of a multi-level modelling framework, class scope features essentially correspond to instances of meta-features. In the case of attributes, however, there is a slight difference between the dynamic properties of class scope attributes and those of meta-attribute instances. Class scope attributes as currently understood in the UML are allowed to change their values over time, which implies a run-time presence, whereas meta-attributes of the form discussed previously (e.g. IsActive) are generally assumed to be constant. In other words, they implicitly possess the UML property “{frozen}” which indicates that something has constant value. Class scope attributes, therefore, are really a more general form of meta-attribute which are amenable to change over time. Since class-scope features essentially correspond to meta-features, with more general dynamic properties in the case of attributes, the notation suggested here can be applied without difficulty. Basically, class scope features are indented with respect to normal features. The convention of underling class scope features is thus redundant, but does not clash with the indentation convention and so can be used if desired. 3.3

Level Identification

Since the generalized notation in Fig. 14 is intended to be used uniformly at all model levels, it is important to have some way of indicating which level an element occupies. A simple but effective approach is to make the level number a superscript following the element name. Thus, to indicate that the element Person inhabits the M1 model, its name would be appended with the superscript 1, as follows:

Person 1 : Class

Fig. 16. Level identification notation

The level number is tightly bound to the name it is a superscript for. Thus, if Class were to be given a level identifier in Fig. 16 it would obviously be 2, since this is the level it occupies. However, it is rarely necessary to provide level identifiers for both the instance name and the type name of an element because it is assumed that the type occupies the level above its instances. In the rare cases where this is not so, such as in the MOF, the levels of both the instance and type should be shown explicitly. Another situation where it makes sense to show both is when the instance and the type have the same name, as in the case of the M2 element Class: Class 2 : Class 3

Fig. 17. Level notation applied to both type and instance

3.4

Creating a UML Variant

These three enhancements to the UML provide all the features needed to develop models at any level in a uniform and consistent way. For example, they can be used at the M1 level as an alternative representation for the UML extension in Fig. 7: Country1 : Testable_Class name : String creation_date : Integer population : Integer tested = 10.12.95 known_bugs = 2 age() : Integer

Fig. 18. Example UML extension

Fig. 18 has exactly the same meaning and effect as Fig. 7. It basically indicates that Country is an instance of a new kind of Class, Testable_Class, and has two attribute values. Of course, the main benefit of the enhancements is that they allow UML variants as well as extensions to be fully described graphically. For example, in Fig. 19 the new model element, Testable_Class, is shown explicitly within the M2 generalization hierarchy as a specialization of Class, and defines the additional attributes which each of its instances must possess.

Class 2

Testable_Class 2 : Class tested : Date known_bugs : Integer

Fig. 19. Example UML variant

Fig. 20 summarizes the features of the generalized notation, and compares it to the way the existing UML notation has to be used to describe the two facets of a model element. Example is an imaginary M2 element. Example 2 : Class Example {isSIngleton = False}

Example : Class

+

anAttribute

isSingleton = False

aMethod ()

isVisible ()

UML1.1 Type View

UML1.1 Object View

=

anAttribute isSingleton = False aMethod () isVisible ()

Generalized UML

Fig. 20. Summary of generalized notation

An important point to note about the notational enhancements suggested here is that with one exception they represent a generalization of the existing notation rather than a change. In other words, the existing (type-oriented) UML representation of classes is a natural subset of the enhanced notation. The one exception is the representation of non-instantiatable model elements (i.e. pure objects) which typically occupy the M0 level. Strictly applying the notation suggested here would require attribute values and method instances to be indented. However, since such elements never have any type properties (i.e. attributes and method types) this requirement can be relaxed if it felt too onerous.

4

Applying the UML Conceptual Framework

The previous section introduced three notational enhancements to help the UML support its conceptual framework in a more uniform way. However, in addition to the deficiencies in its support for the multi-level framework there are also some significant problems in the way it applies the framework in its own definition. This section discusses some of the main problems.

4.1

Type and Attribute Value Specification

As mentioned in Sect. 2, every model element is an instance of some other model element, no matter where it exists in the level hierarchy. However, the UML semantics document provides no indication of the type from which any of the UML meta-model elements are instantiated. Worse still, it provides no indication of the values for the attributes defined by the type. This is a significant omission, since by definition, an instance must have values for the attributes defined by its type, even if they are default values. There is no point in defining attributes at the MOF level if none of the UML meta-model elements have values for them. Using the notation introduced in the previous section a full description of a UML meta-model element would not only specify which MOF element it is an instance of, but also provide values for its attributes as shown in Fig. 21. The UML documentation provides no value for isSingleton, so the value here is an example. Class 2 : Class 3 isActive : Boolean isSingleton = False

Fig. 21. Full specification of UML meta-model element

Note that these problems exists in the definition of the MOF as well as the UML. Since the MOF is defined to be an instance of itself, every element in the MOF must be an instance of some other element in the MOF and must thus have the corresponding attribute values. 4.2

Standard Element Location

Since the built in extension mechanism involves no actual changes to the M2 level, the information represented by an extension has to be stored in the form of stereotype instances and tag values. The part of the UML meta-model which describes how this is achieved is illustrated in Fig. 22. extendedElement

ModelElement

0..1 taggedValue *

GeneralizableElement

TaggedValue requiredTag *

stereotype

0..1

Stereotype

Fig. 22. UML meta-model segment for extension mechanisms

Applying this model to the stereotyped class County in Fig. 7 yields the following data structure. Country

Known_Bugs : TaggedValue

Tested : TaggedValue

Testable_Class : Stereotype

Fig. 23. Example data structure for a UML extension

Notice that all the model elements in Fig. 23 except Country have their names underlined, because none of them is instantiatable. The big question raised by this strategy for representing extensions is where these model elements reside. Clearly Country occupies the M1 level since it is a regular, user-defined class. This would seem to require that the other elements in Fig. 23 also exist at the M1 level otherwise the links between them would have to cross meta level boundaries. However, if these stereotype and tagged value instances are viewed as M1 level elements, then surely so must all other stereotype and tagged value instances, including those defined as standard elements. However, this contradicts the view in the UML Notation Guide (page 21) which states that “the classification hierarchy of the stereotypes themselves could be displayed on a class diagram: however, this would be a metamodel diagram and must be distinguished (by user and tool) from an ordinary model diagram”. At least the notation guide makes a statement on the issue. The semantics document does not even address the question of the location of the standard elements. Since the location of Country at the M1 level is indisputable, unless it is deemed acceptable to have links crossing meta levels, Country’s stereotype and tagged value instances must also reside at the M1 level. 4.3

Strict versus Loose Meta-modelling

The previous issue is a symptom of a more fundamental problem - the use of a “loose” meta-modelling approach in the definition of the UML semantics. This approach allows instances to coexist with their types at the same level of a metamodelling hierarchy [7 ]. In contrast, “strict” meta-modelling requires that an instance always resides at the level below its type, except at the top level where the rule can be relaxed in order to cleanly terminate the level hierarchy. The Common Behavior package (Fig. 14, page 67, UML Notation Guide) contains the most concrete examples of coexistent instances and types in the UML metamodel. The problem with a loose meta-modelling approach is that it erodes the integrity of the distinction between the levels because it is impossible to avoid links and associations crossing level boundaries. Consider the case of the model element Object, for example. In the UML meta-model, Object is an instance of the M2 level

element Class, and itself resides at the M2 level. However, other “normal” instance of Class, such as Person and Country, clearly reside at the M1 level. Therefore, if one wished to establish relationships between Object and these classes, particularly generalization, these would have to cross the boundary between M1 and M2 [6]. The effect of loose meta-modelling is therefore to blur the boundaries between the levels so that ultimately their content become arbitrary, and they essentially act like packages within a single model. The only way to cleanly separate the levels is to adopt a strict meta-modelling approach and ensure that associations and links never cross meta-level boundaries. However, this requires that the UML modelling framework explicitly recognize that a certain number of the predefined model elements exist at the M1 level within one or more predefined packages. As discussed above, the elements that would reside here include the predefined standard elements, and the generalized instances of M2 level elements such as class and association. This is consistent with the approach adopted in many object-oriented language environments such as Java and Smalltalk, where user defined classes are added to a predefined inheritance hierarchy rooted in a class typically called object (or something similar). In order to adopt a strict meta-modelling approach the UML needs to define a similar predefined “library” (i.e. package) of model elements. User concepts would then be added as specializations of the M1 class hierarchy, and as instances of the M2 model elements.

5

Conclusion

Due to the relatively late adoption of meta-modelling in the UML development process there are some shortcomings in the way the UML supports and applies its own conceptual framework. Although the framework ostensibly has four levels, in practice both the UML notation and the UML definition are still dominated by the traditional two level view of object modelling, particularly in the area of customization. The built-in extension mechanism (based on stereotypes, tagged values and constraints) has no advantage over the more fundamental M2 level approach to customization. In fact, the notational enhancements suggested in this paper can achieve precisely the same effects as the current “built in” mechanism but in a way that is more uniform and consistent with fundamental tenets of object modelling. Stereotypes and tagged values simply complicate what otherwise would be a very simple, clean and natural approach to customization. The main goal of this paper is to make potential users of the UML aware of the pitfalls arising in a multi-level modelling framework of the kind adopted by the UML, and to give them the tools needed to avoid them. The majority of UML users will probably never need to customize the UML or to work at any levels other than M1 or M0, but it is nevertheless useful for them to appreciate the wider picture. In particular, an understanding of the problems with the application of multi-level modelling concepts in the definition of the UML will not only help users gain a better understanding of its semantics, but also help them to avoid the same problems in their own work. For those users who wish to develop customizations of the UML, the enhancements put forward in this paper facilitate the complete and concise description

of UML variants, or the description of UML extensions using a more uniform and consistent notation than that available with stereotypes and tagged values.

Acknowledgements The author is grateful to Dilhar DeSilva of Platinum technology for his input into the ideas expressed in this paper, and to Mr. A. L. Atkinson for his comments on early versions of the paper.

References 1. Unified Modeling Language Documentation Set, Version 1.1. Rational Software Corp. (1997) 2. Meta Object Facility (MOF) Specification, OMG Document ad/97-08-14 (1997) 3. CDIF Framework for Modeling and Extensibility (IS-107). Electronic Industries Association (1993) 4. Object Analysis and Design Facility. OMG OA&D RFP response by Platinum Technology (1997) 5. Jacobson I.: Object-Oriented Software Engineering: A Use Case Driven Approach. Addison-Wesley, Reading, MA (1994) 6. Bezivin J. and Lemesle R.: Ontology-Based Layered Semantics for Precise OA&D Modeling. In: ECOOP’97 Workshop on Precise Semantics for Object-Oriented Modeling Techniques (1997) 7. Atkinson C.: Metamodeling for Distributed Object Environments. In: First International Enterprise Distributed Object Computing Workshop (EDOC’97). Brisbane, Australia (1997)