Legacy Issue Number: 17615
Source: Object Management Group ( Andrew Watson)
UML semantics depend on "object identity", an undefined concept
The rearrangement of UML concepts in dependency order, to minimise forward references, is nicely done in this specification. It highlights how careful UML is about defining all the concepts it uses (with the exception of the primitive types in Section 21, which are explicitly imported into the language).
However, the term "object identity" is explicitly or implicitly used in a few places in the specification, but never defined. Worse, its introduction leads to undefined semantics for part of the language.
1. References to the undefined concept "object identity".
1.1 p38 "That is, no two values in the collection may be equal, where equality of objects (instances of Classes) is based on object identity ..."
1.2 p184 "A DataType is a kind of Classifier. DataType differs from Class in that instances of a DataType are identified only by their value. All instances of a DataType with the same value are considered to be equal instances."
This is an implicit reference to Class instances being identified by something other than their value (presumably their "object identity"). However, we search in vain for the corresponding text in the section on the semantics of Class to tell us how Class instances are identified.
1.3 p488 "A TestIdentityAction is an action that tests if the two values given on its InputPins are identical objects ...
If an object is classified solely as an instance of one or more Classes, then testing whether it is the "same object" as another object is based on the identity of the object ..."
2. Undefined semantics as a result
2.1 p488 "The result of a TestIdentityAction for objects that are classified by both Classes and DataTypes, or by other kinds of Classifiers, is not defined, but, in all cases the Action produces a Boolean result."
Either the specification should define "object identity" (although this would still leave TestIdentityAction undefined under some circumstances), or (preferably) this undefined, implementation-level concept should be replaced by a definition of equality grounded in the equality of Primitive Types (with equality on all other Types being recursively defined in terms of equality on Primitive types).
Reported: UML 2.5b1 — Wed, 19 Sep 2012 04:00 GMT
Updated: Fri, 6 Mar 2015 20:57 GMT