| Previous | UML Classes | Table of Contents | UML Packages | Next |
The following conventions are adopted for all metamodel diagrams throughout this specification:
• An association with one end marked by a navigability arrow means that:
• the association is navigable in the direction of that end,
• the marked association end is owned by the classifier, and
• the opposite (unmarked) association end is owned by the association.
Issue 8956 - explain why the notation for owned association ends was not used in the spec
(NOTE: This convention was inherited from UML 1.x and was used in the initial versions of the specification
because there was no explicit notation for indicating association end ownership. Such a notation was introduced
in revision 2.1 (see the notation subsection of the Association metaclass on page 37) but was not applied to the
diagrams in the specification due to lack of tool support. In accord with the new notation, the ownership of an
association end by the association would continue to be shown by leaving the end unmarked, but the ownership
of an end by the classifier would be shown by marking that classifier-owned end with a dot.)
• If no multiplicity is shown on an association end, it implies a multiplicity of exactly 1.
• An association with neither end marked by navigability arrows means that:
• the association is navigable in both directions, • each association end is owned by the classifier at the opposite end (i.e., neither end is owned by the association).
• Association specialization and redefinition are indicated by appropriate constraints situated in the proximity of the association ends to which they apply. Thus:
• The constraint {subsets endA} means that the association end to which this constraint is applied is a specialization of association end endA that is part of the association being specialized. • A constraint {redefines endA} means that the association end to which this constraint is applied redefines the association end endA that is part of the association being specialized.
Issue 6492 - Clarifying conventions used for unlabeled (unnamed) association ends.
• If an association end is unlabeled, the default name for that end is the name of the class to which the end is attached, modified such that the first letter is a lowercase letter. (Note that, by convention, non-navigable association ends are often left unlabeled since, in general, there is no need to refer to them explicitly either in the text or in formal constraints -although there may be needed for other purposes, such as MOF language bindings that use the metamodel.)
• An unlabeled dependency between two packages is interpreted as a package import relationship.
• Associations that are not explicitly named, are given names that are constructed according to the following production rule:
"A_" <association-end-name1> "_" <association-end-name2> where <association-end-name1> is the name of the first association end and is the name of the second association end.
Note that some of these conventions were adopted to contend with practical issues related to the mechanics of producing this
specification, such as the unavailability of conforming modeling tools at the time the specification itself was being defined.
Therefore, they should not necessarily be deemed as recommendations for general use.