6.3 The MOF Model - Metamodeling Constructs

   This sub clause introduces the MOF’s core metamodeling constructs (i.e., the MOF’s “abstract language?) for defining metamodels.

   MOF metamodeling is primarily about defining information models for metadata. The MOF uses an object modeling framework that is essentially a subset of the UML core. In a nutshell, the 4 main modeling concepts are:

1. Classes, which model MOF metaobjects.

2. Associations, which model binary relationships between metaobjects.

3. DataTypes, which model other data (e.g., primitive types, external types, etc.).

4. Packages, which modularize the models.

   Classes are type descriptions of “first class instance? MOF metaobjects. Classes defined at the M2 level logically have instances at the M1 level. These instances have object identity, state, and behavior. The state and behavior of the M1 level instances are defined by the M2 level Class in the context of the common information and computational models defined by the MOF specification.

   Instances of classes belong to class extents that impact on certain aspects of their behavior. It is possible to enumerate all instances of a class in a class extent (see 8.8.2, “Class Extents,? on page 147).

   Classes can have three kinds of features. Attributes and Operations described below and References described in “References? on page 18. Classes can also contain Exceptions, Constants, DataTypes, Constraints, and other elements.

   An Attribute defines a notional slot or value holder, typically in each instance of its Class. An Attribute has the following properties.

    The aggregation properties of an Attribute depend on the Attribute’s type; see 6.3.3, “Aggregation,? on page 17.

   Operations are “hooks? for accessing behavior associated with a Class. Operations do not actually specify the behavior or the methods that implement that behavior. Instead they simply specify the names and type signatures by which the behavior is invoked. Operations have the following properties.

   Attributes and Operations can be defined as “classifier level? or “instance level.? An instance-level Attribute has a separate value holder for each instance of a Class. By contrast, a classifier-level Attribute has a value holder that is shared by all instances of the Class in its class extent.

   Similarly, an instance-level Operation can only be invoked on an instance of a Class and will typically apply to the state of that instance. By contrast, a classifier-level Operation can be invoked independently of any instance, and can apply to any or all instances in the class extent.

   An Attribute or Parameter may be optional-valued, single-valued, or multi-valued depending on its multiplicity specification. This consists of three parts:

   1. The “lower? and “upper? fields place bounds on the number of elements in the Attribute or Parameter value. The lower bound may be zero and the upper may be “unbounded.?

   • A single-valued Attribute or Parameter has lower bound 1 and upper bound 1. An optional-valued Attribute or Parameter has lower bound 0 and upper bound 1. All other cases are called multi-valued parameters (since their upper bound is greater than 1).

   NOTE: Multiplicity bounds are typically notated as one or two numbers, with “*? used to denote unbounded. For example, a UML bounds specification of “1? translates to lower and upper bounds of 1, and “2..*? translates to a lower bound of 2 and no upper bound.

2. The “is_ordered? flag says whether the order of values in a holder has semantic significance. For example, if an Attribute is ordered, the order of the individual values in an instance of the Attribute will be preserved.

3. The “is_unique? flag says whether instances with equal value are allowed in the given Attribute or Parameter. The meaning of “equal value? depends on the base type of the Attribute or Parameter. See 8.4, “Semantics of Equality for MOF Values,? on page 140, and 9.3.3, “Value Types and Equality in the IDL Mapping,? on page 170 for additional information.

   NOTE: The bounds and uniqueness parts of a multiplicity specification can give rise to runtime “structural checks? (see 6.3.7.2, “Structural Consistency,? on page 24). By contrast, orderedness does not imply any runtime checking.

   The MOF allows Classes to inherit from one or more other Classes. Following the lead of UML, the MOF Model uses the verb “to generalize? to describe the inheritance relationship (i.e., a super-Class generalizes a sub-Class).

   The meaning of MOF Class generalization is similar to generalization in UML and to interface inheritance in CORBA IDL. The sub-Class inherits all of the contents of its super-Classes (i.e., all of the super-Classes Attributes, Operations and References, and all nested DataTypes, Exceptions, and Constants). Any explicit Constraints that apply to a super-Class and any implicit behavior for the super-Class apply equally to the sub-Class. At the M1 level, an instance of an M2level Class is type substitutable for instances of its M2-level super-Classes.

   The MOF places restrictions on generalization to ensure that it is meaningful and that it can be mapped onto a range of implementation technologies:

• A Class cannot generalize itself, either directly or indirectly.

• A Class cannot generalize another Class if the sub-Class contains a model element with the same name as a model element contained or inherited by the super-Class (i.e., no over-riding is allowed).

• When a Class has multiple super-Classes, no model elements contained or inherited by the super-Classes can have the same name. There is an exception (analogous to the “diamond rule? in CORBA IDL) that allows the super-Classes to inherit names from a common ancestor Class.

   NOTE: It is also possible to use Tags to specify that the interfaces generated for a Class inherits from pre-existing interfaces.

   A Class may be defined as “abstract.? An abstract Class is used solely for the purpose of inheritance. No metaobjects can ever exist whose most-derived type corresponds to an abstract Class.

   NOTE: The MOF uses “abstract Class? in the same sense as UML, and also Java and many other object oriented programming languages. Specifying a MOF Class as “abstract? does not say how instances are transmitted. In particular, the use of the term “abstract class? has no relationship to the IDL keyword “abstract? introduced by the Objects-by-value specification.

   A Class may be defined as a “leaf? or “root? Class. Declaring a Class as a leaf prevents the creation of any sub-Classes. Declaring a Class as a root prevents the declaration of any super-Classes.

   Associations are the MOF Model’s primary construct for expressing the relationships in a metamodel. At the M1 level, an M2 level MOF Association defines relationships (links) between pairs of instances of Classes. Conceptually, these links do not have object identity, and therefore cannot have Attributes or Operations.

   Each MOF Association contains precisely two Association Ends describing the two ends of links. The Association Ends define the following properties.

   Each Association End has a multiplicity specification. While these are conceptually similar to Attribute and Operation multiplicities, there are some important differences:

• An Association End multiplicity does not apply to the entire link set. Instead, it applies to projections of the link set for the possible values of the “other? end of a link. See Figure 6.3.

• Since duplicate links are disallowed in M1-level link sets, “is_unique? is implicitly TRUE. The check for duplicate links is based on equality of the instances that they connect; see 8.4, “Semantics of Equality for MOF Values,? on page

    140 .

   .

   left: Class A right: Class B

   Figure 6.3 - The projections of a link set

    Figure 6.3 shows a link set for an Association with an AssociationEnd named “left? whose Class is A, and a second named “right? whose Class is B. Instances of A are shown as “a1,? “a2,? and “a3? and “b1? and “b2? are instances of B. In this example with five links, the projection of “a1? is the collection {b1}, and the projection of “b1? is the collection {a1, a2, a3}. If there is another B instance (say “b3?) with no corresponding links, the projection of that b3 is an empty collection.

   The “lower? and “upper? bounds of an Association End constrain the number of instances in a projection. For example, if the “left? End of the Association has a bounds “0..3,? then the projection of the link set for any extant instance of B must contain between zero and three instances of A.

   The “is_ordered? flag for the Association End determines whether the projections from the other End have an ordering. The MOF Model only allows one of an Association’s two Association Ends to be marked as “ordered.?

   In the above example, this could say whether order of the elements of the projection of “b1? is significant (i.e., whether {a1, a2, a3} is a set or a unique list).

   In a MOF metamodel Classes and DataTypes can be related to other Classes using Associations or Attributes. In both cases, aspects of the behavior of the relationships can be described as aggregation semantics.

   The MOF supports two kinds of aggregation for relationships between instances (i.e., “composite? and “non-aggregate?). A third aggregation semantic - “shared? - is not supported in this version of the MOF specification.

   A non-aggregate relationship is a (conceptually) loose binding between instances with the following properties:

• There are no special restrictions on the multiplicity of the relationships.

• There are no special restrictions on the origin of the instances in the relationships.

• The relationships do not impact on the lifecycle semantics of related instances. In particular, deletion of an instance does not cause the deletion of related instances.

   By contrast, a composite relationship is a (conceptually) stronger binding between instances with the following properties:

• A composite relationship is asymmetrical, with one end denoting the “composite? or “whole? in the relationship and the other one denoting the “components? or “parts.?

• An instance cannot be a component of more than one composite at a time, under any composite relationship.

• An instance cannot be a component of itself, its components, its components’ components and so on under any composite relationship.

• When a “composite? instance is deleted, all of its components under any composite relationship are also deleted, and all of the components’ components are deleted and so on.

• The Composition Closure Rule: an instance cannot be a component of an instance from a different package extent (see 8.11.2, “The Composition Closure Rule,? on page 155).

   The aggregation semantics of an Association are specified explicitly using the “aggregation? Attribute of the AssociationEnds. In the case of a “composite? Association, the “aggregation? Attribute of the “composite? AssociationEnd is set to true and the “aggregation? Attribute of the “component? AssociationEnd is set to false. Also, the multiplicity for the “composite? AssociationEnd is required to be “[0..1]? or “[1..1]? in line with the rule that an instance cannot be a component of multiple composites.

   The effective aggregation semantics for an Attribute depend on the type of the Attribute. For example:

• An Attribute whose type is expressed as a DataType has “non-aggregate? semantics.

• An Attribute whose type is expressed as a Class has “composite? semantics.

   It is possible to use a DataType to encode the type of a Class. Doing this allows the metamodel to define an Attribute whose value or values are instances of a Class without incurring the overhead of “composite? semantics.

   The MOF Model provides two constructs for modeling relationships between Classes (i.e., Associations and Attributes). While MOF Associations and Attributes are similar from the information modeling standpoint, they have important differences from the standpoints of their computational models and their corresponding mapped interfaces.

   NOTE: Attributes can also model relationships between Classes and DataTypes, but that is not relevant to this point.

   Associations offer a “query-oriented? computational model. The user performs operations on an object that notionally encapsulates a collection of links:

• Advantage: The association objects allow the user to perform “global? queries over all relationships, not just those for a given object.

• Disadvantage: The client operations for accessing and updating relationships tend to be more complex.

   Attributes offer a “navigation-oriented? computational model. The user typically performs get and set operations on an attribute.

• Advantage: The get and set style of interfaces are simpler, and tend to be more natural for typical metadata oriented applications that “traverse? a metadata graph.

• Disadvantage: Performing a “global? query over a relationship expressed as an Attribute is computationally intensive.

   The MOF Model provides an additional kind of Class feature called a Reference that provides an alternative “Attribute like? view of Associations. A Reference is specified by giving the following:

• a name for the Reference in its Class,

• an “exposed? Association End in some Association whose type is this Class or a super-Class of this Class, and

• a “referenced? Association End, which is the “other? end of the same Association.

   Defining a Reference in a Class causes the resulting interface to contain operations with signatures that are identical to those for an “equivalent? Attribute. However, rather than operating on the values in an attribute slot of a Class instance, these operations access and update the Association, or more precisely a projection of the Association. This is illustrated in UML-like notation in Figure 6.4.

   Figure 6.4 - An example of a Reference

    Figure 6.4 shows a Class called My_Class_1 that is related to My_Class_2 by the Association My_Assoc. My_Class_1 has an Attribute called “attr? whose type is Integer. In addition, it has a Reference called “ref? that references “end2? of the Association. This provides an API for “ref? that allows a user to access and update a My_Class_1 instance’s link to a My_Class_2 instance using get and set operations.

   NOTE: Strictly speaking, the UML notation in the diagram shows “ref? as a derived attribute of My_Class_1 with type of My_Class_2.

   The example above shows a Reference that “exposes? an Association End with a multiplicity of “[1..1].? References can actually expose ends with any valid multiplicity specification. The resulting Reference operations are similar to those for an Attribute with the same multiplicity. However, since MOF Associations do not allow duplicates, Association Ends and therefore References must always have their multiplicity “is_unique? flag set to true.

   There are some important restrictions on References:

• When the “is_navigable? property of an Association End is false, it is not legal to define a Reference that “references? that Association End.

• An M1 instance of a Class that “references? an Association cannot be used to make a link in an instance of the Association in a different extent. This restriction is described in 8.11.1, “The Reference Closure Rule,? on page 153.

   Metamodel definitions often need to use attribute and operation parameter values that have types whose values do not have object identity. The MOF provides the metamodeling concept of a DataType to fill this need.

   DataTypes can represent two kinds of data type:

1. Primitive data types like Boolean, Integer, and String are the basic building blocks for expressing state. The MOF defines six standard data types that are suitable for technology neutral metamodeling. (Other primitive data types can be defined by specific technology mappings or as user or vendor-specific extensions. However, the core MOF specification says nothing about what they mean.)

2. Data type constructors allow the metamodeler to define more complex data types. The MOF’s standard data type constructors are enumeration types, structure types, collection types, and alias types.

   See 7.4.7, “DataType (abstract),? on page 55 and the following sub clauses for more details on how DataTypes subtypes are used to express types.

   The Package is the MOF Model construct for grouping elements into a metamodel. Packages serve two purposes.

1. At the M2 level, Packages provide a way of partitioning and modularizing the metamodel space. Packages can contain most kinds of model element (e.g., other Packages, Classes, Associations, DataTypes, Exceptions, Constants, and so on).

2. At the M1 level, Package instances act as the outermost containers for metadata. Indirectly, they also define the scope boundaries of Association link sets and of “classifier level? Attributes and Operations on Class instances (see 8.8.4, “Package Extents,? on page 147).

   The MOF Model provides four mechanisms for metamodel composition and reuse (i.e., generalization, nesting, importing, and clustering). These are described in the following sub clauses.

   Packages may be generalized by (inherit from) one or more other Packages in a way that is analogous to Class generalization described in 6.3.1.5, “Class Generalization,? on page 15. When one Package inherits from another, the inheriting (sub-) Package acquires all of the metamodel elements belonging to the (super-) Package it inherits from. Package inheritance is subject to rules that prevent name collision between inherited and locally defined metamodel elements.

   At the M1 level, a sub-Package instance has the ability to create and manage its own collections of Class instances and Links. This applies to the Classes and Associations that it defines explicitly, and to those that it acquires by inheritance.

   The relationship between instances of the super- and sub-Packages is similar to relationship between instances of super-and sub-Classes:

• A sub-Package instance is type substitutable for instances of its super-Packages (i.e., the sub-Package instance “IS_A? super-Package instance).

• A sub-Package instance does not use or depend on an instance of the super-Package (i.e., there is no “IS_PART_OF? relationship).

   Packages may be defined as “root? or “leaf? Packages (with analogous meaning to “root? and “leaf? Classes), but “abstract? Packages are not supported.

   A Package may contain other Packages, which may in turn contain other Packages. Model elements defined in nested Packages may be strongly coupled to other model elements in the same containment. For example, a Class in a nested Package have a Reference that links it via an Association in its context, or its semantics could be covered by a user-defined Constraint that applies to the enclosing Package.

   A nested Package is a component of its enclosing Package. Since, in general, the model elements in a nested Package can be inextricably tied to its context, there are some significant restrictions on how nested Packages can be composed. In particular, a nested Package may not:

• generalize or be generalized by other Packages.

• be imported or clustered by other Packages.

   Nested Packages are not directly instantiable. No factory objects or operations are defined for nested Package instances. An M1 level instance of a nested Package can only exist in conjunction with an instance of its containing Package. Conceptually, a nested Package instance is a component of an instance of its containing Package.

   NOTE: The main effect of nesting one Package inside another is to partition the concepts and the namespace of the outer Package. Nesting is not a mechanism for reuse. Indeed when a Package is nested, the options for reusing its contents are curtailed.

   In many situations, the semantics of Package nesting and generalization do not provide the best mechanism for metamodel composition. For example, the metamodeler may wish to reuse some elements of an existing metamodel and not others. The MOF provides an import mechanism to support this.

   A Package may be defined as importing one or more other Packages. When one Package imports another, the importing Package is allowed to make use of elements defined in the imported one Package. As a shorthand, we say that the elements of the imported Package are imported.

   Here are some examples of how a Package can reuse imported elements. The importing Package can declare:

• Attributes, Operations, or Exceptions using imported Classes or DataTypes,

• Operations that raise imported Exceptions,

• DataTypes and Constants using imported DataTypes or Constants,

• Classes whose supertypes are imported Classes, and

• Associations for which the types of one or both Association Ends is an imported Class.

   At the M1 level, an instance of an importing Package has no explicit relationship with any instances of the Packages that it imports. Unlike a sub-Package, an importing Package does not have the capability to create instances of imported Classes. A client must obtain any imported Class instances it needs via a separate instance of the imported Package.

   Package clustering is a stronger form of Package import that binds the importing and imported Package into a “cluster.? As with ordinary imports, a Package can cluster a number of other Packages, and can be clustered by a number of other Packages.

   An instance of a cluster Package behaves as if the clustered Packages were nested within the Package. That is, the lifecycle of a clustered Package instance is bound to the lifecycle of its cluster Package instance. In particular:

• When the user creates an instance of a cluster Package, an instance of each of its clustered Packages is created automatically.

• The instances of the clustered Packages created above all belong to the same cluster Package extent.

• Deleting a cluster Package instance automatically deletes its clustered Packaged instances, and the clustered Package instances cannot be deleted except as part of the deletion of the cluster Package instance.

   However, unlike a nested Package, it is possible to create an independent instance of a clustered Package. Also, in some situations clustered Package instances are not strictly nested.

   NOTE: It is possible to cluster or inherit from Packages that cluster other Packages. The impact of this on M1 level instance relationships is discussed in 8.8.4, “Package Extents,? on page 147.

   In summary, the relationship between the M1 level instances in a Package cluster is that each clustered Package instance is a component of the cluster Package instance. Unlike nested Packages, there is no composite relationship between the M2 level Packages.

    The properties of the four Package composition mechanisms defined by the MOF Model are summarized by Table 6.1.

   Table 6.1 - Package Composition Constructs

   The symbology of the table is based on UML; that is, a filled diamond means composition, a hollow diamond means aggregation, a hollow triangle means inheritance, and a dotted arrow means “depends on.?

   Note that P1 and P2 denote different (though related) things in different columns of the table:

• In column 2, they denote conceptual M2 level Packages in a metamodel.

• In column 3, they denote both the conceptual M2 level Packages, and the objects that represent them in a reified metamodel.

• In column 4, they denote M1 level Package instances (when underlined) or their types.

   © ISO/IEC 2005 - All rights reserved

   The MOF Model constructs described so far allow the metamodeler to define a metadata information that comprises nodes (Classes) with attached properties (Attributes / DataTypes) and relationships between nodes (Associations). While the above constructs are sufficient to define an “abstract syntax? consisting of metadata nodes and links, this syntax typically needs to be augmented with additional consistency rules.

   This sub clause describes the MOF Model’s support for consistency rules and model validation.

   The MOF Model defines an element called Constraint that can be used to attach consistency rules to other metamodel components. A Constraint comprises:

• a constraint name,

• a “language? that identifies the language used to express the consistency rules,

• an “expression? in the language that specifies a rule,

• an “evaluation policy? that determines when the rule should be enforced, and

• a set of “constrained elements.?

   A Constraint expression is an expression in some language that can be “evaluated? in the context of a metamodel to decide if it is valid. The MOF specification does not define or mandate any particular languages for Constraint expressions, or any particular evaluation mechanisms. Indeed, it is legitimate for Constraints to be expressed in informal language (e.g., English) and for validation to be implemented by ad-hoc programming. However, the Constraints that are part of the MOF Model specification itself are expressed in Object Constraint Language (OCL) as described in the UML specification.

   The evaluation policy property of a Constraint determines whether the consistency rule should be enforced immediately or at a later time. Figure 6.5 gives a simple example that will be used to illustrate the need for evaluation policies.

   b equals a * 2

   Figure 6.5 - Examples of Constraints

   In Figure 6.5, Constraint X constrains only Attribute a while Constraint B constrains both Attributes a and b.

   © ISO/IEC 2005 - All rights reserved

   It is feasible to check the first Constraint (X: “a is odd? on the Attribute “a?) at any time. It could be checked whenever a value for “a? is supplied (e.g., at instance creation and when “a? is updated). An exception would be raised if the new value for “a? was even. Alternatively, constraint checking could be deferred to a later point (e.g., when the user requests validation of a model).

   The second constraint (Y: “b equals a * 2? on both Attributes “a? and “b?) is another matter. If a server enforces Y on every update, the user would never be able to change the values of either “a? or “b.? No matter which order the user invoked the operations, the updates would raise an exception. Instead, enforcement of Y must be deferred until both “a? and “b? have been updated.

   NOTE: The Constraint construct is intended to be used for specifying consistency rules for models rather than for defining the computation behavior of (for example) Operations. It is “bad style? to specify Constraint expressions that have side-effects on the state of a model, not least because it is unspecified when Constraints are evaluated.

   As noted previously, a MOF-based metamodel defines an “abstract syntax? for metadata. Some aspects of the abstract syntax are enforced by the corresponding metadata server’s IDL. For example, the operation that creates a link for an Association has a type signature that prevents the user from creating a link with the wrong kind of Class instances. However, some aspects of the abstract syntax can only be enforced by runtime structural consistency checks. While most of the structural checks are made immediately, checks for “underflow? often need to be deferred.

   It is not practical for a metamodel to specify a priori all possible things that can go wrong in a MOF-based metadata server. It is therefore necessary to recognize that a MOF server may need to perform a variety of runtime checks that are neither defined or implied by the metamodel. These include additional metadata validation that is not specified by the metamodel, resource and access control checks, and internal error checking.

   The MOF specification provides a lot of latitude for metadata server implementations in the area of constraint checking or validation.

• Support for checking of Constraints is not mandatory. In particular, there is no requirement to support any particular language for Constraint expressions.

• The set of events (if any) that may trigger deferred checking is not specified. No general APIs are specified for initiating deferred consistency checking.

• Persistence and interchange of metadata, which is in an inconsistent state may be allowed. (Indeed, this would seem to be a prerequisite for some styles of metadata acquisition.)

• There are no specified mechanisms for ensuring that validated metadata remains valid, or that it does not change.

   The one aspect of consistency checking that is mandatory is that a metadata server must implement all structural consistency checks that are labeled as immediate.

   This sub clause describes the remaining significant elements of the MOF Model.

   The Constant model element allows the metamodeler to define simple bindings between a name and a constant value. A Constant simply maps onto a constant declaration in (for example) the IDL produced by the MOF IDL mapping.

   The Exception model element allows the metamodeler to declare the signature of an exception that can be raised by an Operation. An Exception simply maps onto (for example) an IDL exception declaration.

   The Tag model element is the basis of a mechanism that allows a “pure? MOF metamodel to be extended or modified. A Tag consists of:

• a name that can be used to denote the Tag in its container,

• a “tag id? that denotes the Tag’s kind,

• a collection of zero or more “values? associated with the Tag, and

• the set of other model elements that the Tag is “attached? to.

   The meaning of a model element is (notionally) modified by attaching a Tag to it. The Tag’s “tag id? categorizes the intended meaning of the extension or modification. The “values? then further parameterize the meaning.

   As a general rule, the definition of values and meanings for “tag id? strings is beyond the scope of the MOF specification. The specification recommends a tag id naming scheme that is designed to minimize the risk of name collision, but use of this scheme is not mandatory; see 7.4.28, “Tag,? on page 83.

   One exception to this is the MOF to IDL Mapping. This defines some standard tag ids that allow a metamodel to influence the IDL mapping; see 9.6, “Standard Tags for the IDL Mapping,? on page 194 for the complete list. For example:

• “IDL Substitute Name? provides an alternative IDL identifier for an element in a metamodel, and

• “IDL Prefix? allows the metamodeler to specify the IDL “prefix? for a top-level Package.