3.2.1 Modeling Conventions

   To promote clearer understanding of the contents of the CWM metamodels, this specification contains a number of UML representations of portions of the CWM model packages. The CWM design team has used several conventions in the construction of CWM metamodel packages and accompanying diagrams. These conventions are outlined here and apply to the remainder of the specification.

   The names of UML packages, classifiers, and associations are shown with the initial letter of their names in upper case; these names must be unique within a package. Features (attributes and operations), references, and association ends are shown with the initial letter of their names in lower case; these names must be unique within their containing classifier or association. Internal upper case letters are used in both types of names to separate words; intervening spaces, hyphens, or underscores have been avoided. Double colon delimiters (“::?) are used to connect individual names into qualified names.

   Conforming to standard UML notation, classes are represented in diagrams as rectangular boxes with three horizontal sections containing the class name, attributes, and operations, respectively, from the top. CWM itself defines no operations, but extension packages are permitted to do so.

   Classes defined in the current CWM package are shown with all their attributes and operations visible. Classes imported from UML or other CWM packages show only the class name and a notation in parentheses identifying the source package. Attributes and operations of imported classes are not displayed; refer to the package where they are defined to see their complete definition.

   In diagrams, classes defined in any CWM package are shown with lightly shaded background fill, whether imported or local. Classes imported from a UML package are shown with no background fill.

   Unless specified otherwise in the specification, attributes have a multiplicity of exactly one; attribute multiplicity is not shown in diagrams. Attributes are shown diagrammatically following standard UML notation:

    <<stereotype>> name : type = initvalue.

   Attribute stereotypes and initial values are suppressed in diagrams if they are not defined.

   Metamodel (M2) data types are placed in the most specific package possible and have a stereotype of <<primitive>>, <<datatype>> or <<enumeration>>.

   Enumerations are used infrequently within the CWM. In diagrams, the names of enumerations appear only as the types of attributes; their individual values are not displayed. The defined values for an enumeration begin with a lower case letter and can be found in the text where the enumeration is used as the type of an attribute. For example, the values of the WeekDay enumeration used as the type of an attribute named dayOfWeek would appear in the text as follows:

   dayOfWeek

   Data types required by CWM extension packages, such as the types of a programming language, are generally represented as instances of the UML DataType class or as instances of other classes that are subclasses of UML’s Classifier class. Refer to the Foundation and Data Types chapters for additional details.

   All CWM associations are named. However, to improve readability, their names usually do not appear in diagrams.

   Associations declared in UML and other CWM packages can be reused in two ways: inheritance or derivation. Inherited associations are reuses, without modification, of associations declared elsewhere in the metamodel. In contrast, derived associations are “filtered? by OCL statements so that only a subset of the source association’s instances are available in the derived association.

   Inherited associations are never renamed and are added to the diagrams only when they clarify the relationships between types appearing in the diagram. They can be identified in diagrams by leading forward slash characters (“/?) on the names of their association ends. For example, the association between a relational table and its columns can be drawn between the Table and Column classes with end names of “/owner? and “/feature,? indicating that the association is an application of the UML association between the Classifier and Feature classes.

   Derived associations are separately named and have a real presence in the metamodel. They do not have slashes on the names of association ends. One “filtering? OCL statement on at least one association end is required. (Note, however, that OCL statements that simply restrict the multiplicity of inherited association ends are not sufficient to turn them into derived associations.)

   Shared (open diamond) aggregation associations have been avoided unless there was no other way of representing the required semantics. UML association classes have been avoided because MOF 1.3 does not support them.

   All association ends are named in CWM. By default, the names of association ends are the same as the names of the classes to which they connect. Association end names are defined only within the scope of the association whose ends they name. The names of association ends appear in the diagrams only when they have some name other than the default or when their presence is required to clarify the meaning or identity of the association (as with inherited associations appearing on diagrams).

   Generally, all CWM association ends are navigable. In the diagrams, navigable association ends are marked with an arrowhead when the opposite end is non-navigable for some specific semantic reason. Such situations are considered rare, occur only when associations cross package boundaries, and are dependent on the specific semantics of each situation.

   Because it is based on the MOF, CWM distinguishes references and association ends. References appear as attributes of classes and indicate related instances of the class that is the attribute’s stated type. The names of references are preceded by forward slashes (“/?) in diagrams. Association ends, in contrast, appear as labels on the ends of lines representing associations.

   It is appropriate to think of a reference as being “implemented? by a corresponding association end of an association between the reference’s class and the class represented by the reference’s type. Reference names are generally identical to their corresponding association end’s name. However, reference names may differ from end names when doing so improves the clarity of the model.

   References may be omitted if traversal to the associated class is either not possible, as is often the case when crossing package boundaries, or not desirable for some other semantic reason. For example, references should be omitted when the association end they correspond to resides in another package or when they would interfere with federation across network metadata repositories (refer to the MOF specification for details).

    Examples of these relationships are illustrated in Figure 3-2.

   X XtoY

   pq

   XY

   xy

   Figure 3-2 References and Association Ends

   In the figure, X.a and Y.b are attributes of type String in classes X and Y, respectively.

   X.y is a reference from class X to class Y, and Y.x is a reference from Y to X. Although CWM does not specify implementation details, this pair of references can be thought of as being implemented by the XY association, with the XY.x association end implementing the reference Y.x and XY.y implementing X.y. Consequently, X.y and Y.x are mutually inverse references. Similarly, X.q is implemented by XtoY.q but has no inverse reference. Because the inverse reference is not defined, instances of X cannot be directly accessed from Y. However, related instances of X still can be found by examining the XtoY association itself. This technique is commonly used when an association crosses a package boundary, and a reference cannot be added to the class in the other package (Y, in this case).

   If traversal from Y to X were not semantically valid, the XtoY association could be so-marked with an open arrowhead at the q association end, pointing to Y (but not shown in the figure).

   Constraints are statements of “facts? assumed to be true always and are core parts of any expressive metamodel.

   CWM constraints are expressed in two ways. Some constraints are represented in the structure of the model itself. These constraints take the form of multiplicity statements for attributes and association ends, positioning of containment and inheritance relationships, and the abstractness of some metaclasses. Other constraints are, following OMG requirements, expressed as OCL statements. Within the body of a chapter, these constraints are described in text, and corresponding OCL statements are referenced by number and enclosed in square brackets. For example, a reference to the third OCL statement in a chapter would appear as “[C-3].? OCL statements within a chapter are numbered sequentially from C-1 and collected together in a section at the end of chapter. Because the Foundation chapter contains an additional layer of subsections, constraint numbers in it include the subsection number; for example, “[C2-1]? is the first constraint in the second subsection of the chapter.

   A complete description of CWM includes both structural constraints and their accompanying OCL statements. Structural constraints are used to capture general features of CWM and are generally preferred over OCL statements. OCL statements are used when capturing a constraint structurally would overly complicate or otherwise obscure the basic intent and understanding of the metamodel. OCL statements are written to capture specific situational constraints (such as uniqueness, filters for derived associations, and dependencies between attribute values) or to express relationships between instances that cannot be inferred from the metamodel itself (such as “or-ed? or “xor-ed? associations and attributes, references to superclasses, or other related instances, subsets, and implied transitivity).

   Following the ground rules of OCL, CWM does not specify the nature of actions taken when constraints fail. Rather, specification of failure actions and recognition of failure modes are left to individual implementations of CWM.

   Unless otherwise stated for a particular OCL constraint, the evaluation policy for all CWM constraints is “deferred? meaning that constraint checking should occur at the end of bulk operations, such as a load, or as part of a model validation operation.

   The specification contains examples of metamodel usage in a graphical presentation similar in appearance to UML collaboration diagrams. These instance diagrams should not, however, be confused with UML collaboration diagrams. Individual instances are represented as rectangular boxes containing the instance’s name (if any) followed by the instance’s type. Lines represent links between instance rectangles and are labeled only when required for clarity. Refer to the specification text for precise definition of the identity and semantics of individual lines. Attribute values are shown, when necessary, in separate boxes linked to their owning instance with text in the form <attribute name> = <value>.

   As much as possible, different modeling areas have been placed in different packages, and dependencies between packages have been kept to a minimum. This has been done so that CWM packages can be deployed in various combinations rather than as one enormous model.