Issue 15789: Vagueness about meaning of 0..1 multiplicity in OCL and UML (ocl2-rtf) Source: Model Driven Solutions (Mr. Steve Cook, steve-c(at)modeldriven.org) Nature: Uncategorized Issue Severity: Summary: UML-alignment of OCL type signatures -------------------------------------------------------- Following discussion in the "Vagueness about meaning of 0..1 multiplicity in OCL and UML" threads of the UML2 and OCL RTFs the following problems exist in alignment of the UML and OCL type systems. The OCL specification does not provide a clear description of the comparative semantics of for instance Integer[1] and Integer[0..1]. The Complete OCL syntax for an Operation Context Declaration uses OCL type decalarations and so fails to provide the same expressivity as a UML operation declaration with multiplicities. Suggest: a) a clear indication that An Integer[1] may have integer values, null or invalid, of which only integer values are well-formed. An Integer[0..1] may have integer values, null or invalid, of which integer values and null are well-formed. b) an enhancement to the type declaration syntax to allow Integer[0..1] or Integer[1] to indicate a nullable/non-nullable value. Set(Integer[1..7]) to capture the expressivity of a UML multiplicity Resolution: Revised Text: Actions taken: October 28, 2010: received issue Discussion: End of Annotations:===== m: Steve Cook To: "uml2-rtf@omg.org" , "ocl2-rtf@omg.org" CC: "issues@omg.org" Subject: Vagueness about meaning of 0..1 multiplicity in OCL and UML Thread-Topic: Vagueness about meaning of 0..1 multiplicity in OCL and UML Thread-Index: Act2nWG9nHt7ZdhnR6ep7Ws1giycVg== Date: Thu, 28 Oct 2010 12:42:58 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.20.35] In the UML spec especially around the area of MultiplicityElement and ValueSpecification there are numerous types for operation results declared as [Integer] etc. These are freely interpreted as being both sets and integers, both in the way they are used: lowerBound = if lowerValue->isEmpty() then 1 else lowerValue.integerValue() endif and in the way they are constructed: integerValue = Set{} This notation [Integer] appears to be a shorthand for either Set(Integer) or Integer[0..1]. In C# I would call this type Nullable or just int?; but I don.t believe that such a type formally exists in OCL. OCL has the value OclVoid, which is supposed to conform to all types. Is OclVoid semantically equivalent to Set{}? If OclVoid conforms to all types, is there any difference semantically between an attribute declared as multiplicity [1] and one declared as multiplicity [0..1]? If there is no difference, this seriously contradicts my expectations of what multiplicity means. -- Steve Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Date: Thu, 28 Oct 2010 09:47:33 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Vagueness about meaning of 0..1 multiplicity in OCL and UML Thread-Index: Act2nWG9nHt7ZdhnR6ep7Ws1giycVgABdsJA From: "Ed Seidewitz" To: "Steve Cook" , , Cc: Steve . In the OCL 2.2 spec, Subclause 7.5.3, under .Navigation over Associations with Multiplicity Zero or One., it says: .Because the multiplicity of the role manager is one, self.manager is an object of type Person. Such a single object can be used as a Set as well. It then behaves as if it is a Set containing the single object. The usage as a set is done through the arrow followed by a property of Set.. While it doesn.t seem to say anything explicitly in the spec about non-association end properties with multiplicity 0..1, presumably the semantics are the same. That is, in the OCL type system, the type of such an association end is not explicit a collection, but a value of the association end may be treated in an expression as being a set with at most one member (so one can, e.g., check for emptiness using self.manager->isEmpty()), which is consistent with UML semantics. In OCL 2.2 Subclause 8.2, under .VoidType. it says: .VoidType represents a type that conforms to all types. The only instance of VoidType is OclVoid, which is further defined in the standard library. Furthermore OclVoid has exactly one instance called null - corresponding to the UML NullLiteral [sic] literal specification - and representing the absence of value. Note that in contrast with OclInvalid null is a valid value and as such can be owned by collections.. In the UML 2.3 spec, Subclause 7.3.28, it simply says that .A literal null specifies the lack of a value,. which is the vague semantics that is echoed above in the OCL spec. However, to OCL 2.2 spec further elaborates on OclVoid in Subclause 11.2.3, where it notes that: .However, by virtue of the implicit conversion to a collection literal, an expression evaluating to null can be used as source of collection operations (such as .isEmpty.). If the source is the null literal, it is implicitly converted to Bag{}.. Thus, the OclVoid instance .null. is a distinguished value in OCL semantics, it is effectively equivalent to Bag{} in usage. This seems consistent with the phrase .lack of a value. used in the UML spec, though OclVoid is itself only defined in the OCL spec (as are all OCL collection types, too, for that matter). Note also that, in fUML, a value specification action with a null literal produces a null token . a token that holds no values . when it fires, which is the activity semantics equivalent of the empty set or .lack of a value.. In Alf, the notation .null. is considered equivalent to .any[]{}., that is, an untyped empty sequence, which, as a sequence construction expression, has a special mapping to a value specification with a null literal, giving it the fUML semantics (as would be expected for Alf). Isn.t it nice that now that we are all looking closely at UML semantics we have so many to choose from? -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, October 28, 2010 8:43 AM To: uml2-rtf@omg.org; ocl2-rtf@omg.org Cc: issues@omg.org Subject: Vagueness about meaning of 0..1 multiplicity in OCL and UML In the UML spec especially around the area of MultiplicityElement and ValueSpecification there are numerous types for operation results declared as [Integer] etc. These are freely interpreted as being both sets and integers, both in the way they are used: lowerBound = if lowerValue->isEmpty() then 1 else lowerValue.integerValue() endif and in the way they are constructed: integerValue = Set{} This notation [Integer] appears to be a shorthand for either Set(Integer) or Integer[0..1]. In C# I would call this type Nullable or just int?; but I don.t believe that such a type formally exists in OCL. OCL has the value OclVoid, which is supposed to conform to all types. Is OclVoid semantically equivalent to Set{}? If OclVoid conforms to all types, is there any difference semantically between an attribute declared as multiplicity [1] and one declared as multiplicity [0..1]? If there is no difference, this seriously contradicts my expectations of what multiplicity means. -- Steve Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Date: Thu, 28 Oct 2010 15:57:50 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Vagueness about meaning of 0..1 multiplicity in OCL and UML Thread-Index: Act2nWG9nHt7ZdhnR6ep7Ws1giycVgABrZ6A From: To: , , Cc: X-OriginalArrivalTime: 28 Oct 2010 13:57:47.0432 (UTC) FILETIME=[1A146A80:01CB76A8] >>> These are freely interpreted as being both sets and integers Obviously there is a bug. lowerBound cannot be an Integer and a Set{} at the same time (unless we are working with a Quantic OCL or Schrodinger OCL which I never heard about yet) I believe the bug is in definition: integerValue = Set{} is a non sense. Should be: integerValue: Integer >>> This notation [Integer] appears to be a shorthand for either Set(Integer) or Integer[0..1]. As far as I know this notation is not defined in OCL specification and I do not see the rational for using it. In our case the signature of lowerBound operation should be: MultiplicityElement::lowerBound() : Integer; >>> Is OclVoid semantically equivalent to Set{}? No, it is not. Of course multiplicities [1] and [0..1] mean different things. -- Mariano -------------------------------------------------------------------------------- De : Steve Cook [mailto:Steve.Cook@microsoft.com] Envoyé jeudi 28 octobre 2010 14:43 À: uml2-rtf@omg.org; ocl2-rtf@omg.org Cc : issues@omg.org Objet : Vagueness about meaning of 0..1 multiplicity in OCL and UML In the UML spec especially around the area of MultiplicityElement and ValueSpecification there are numerous types for operation results declared as [Integer] etc. These are freely interpreted as being both sets and integers, both in the way they are used: lowerBound = if lowerValue->isEmpty() then 1 else lowerValue.integerValue() endif and in the way they are constructed: integerValue = Set{} This notation [Integer] appears to be a shorthand for either Set(Integer) or Integer[0..1]. In C# I would call this type Nullable or just int?; but I don.t believe that such a type formally exists in OCL. OCL has the value OclVoid, which is supposed to conform to all types. Is OclVoid semantically equivalent to Set{}? If OclVoid conforms to all types, is there any difference semantically between an attribute declared as multiplicity [1] and one declared as multiplicity [0..1]? If there is no difference, this seriously contradicts my expectations of what multiplicity means. -- Steve From: Steve Cook To: Ed Seidewitz , "uml2-rtf@omg.org" , "ocl2-rtf@omg.org" CC: "issues@omg.org" Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Thread-Topic: Vagueness about meaning of 0..1 multiplicity in OCL and UML Thread-Index: Act2nWG9nHt7ZdhnR6ep7Ws1giycVgABdsJAAAECqsA= Date: Thu, 28 Oct 2010 13:59:02 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.20.35] Ed >Isn.t it nice that now that we are all looking closely at UML semantics we have so many to choose from? Yes. Great. If OclVoid conforms to all types, so null is a valid member of any type, is there any difference between a UML property typed as Integer[1] and one typed as Integer[0..1]? Or do you see this as an explicit divergence between UML semantics and OCL semantics, where UML allows null to be a valid member of Integer[0..1] but not Integer[1]? If the latter, it.s a bit of a joke using OCL to define UML operations and constraints. -- Steve From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 28 October 2010 14:48 To: Steve Cook; uml2-rtf@omg.org; ocl2-rtf@omg.org Cc: issues@omg.org Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Steve . In the OCL 2.2 spec, Subclause 7.5.3, under .Navigation over Associations with Multiplicity Zero or One., it says: .Because the multiplicity of the role manager is one, self.manager is an object of type Person. Such a single object can be used as a Set as well. It then behaves as if it is a Set containing the single object. The usage as a set is done through the arrow followed by a property of Set.. While it doesn.t seem to say anything explicitly in the spec about non-association end properties with multiplicity 0..1, presumably the semantics are the same. That is, in the OCL type system, the type of such an association end is not explicit a collection, but a value of the association end may be treated in an expression as being a set with at most one member (so one can, e.g., check for emptiness using self.manager->isEmpty()), which is consistent with UML semantics. In OCL 2.2 Subclause 8.2, under .VoidType. it says: .VoidType represents a type that conforms to all types. The only instance of VoidType is OclVoid, which is further defined in the standard library. Furthermore OclVoid has exactly one instance called null - corresponding to the UML NullLiteral [sic] literal specification - and representing the absence of value. Note that in contrast with OclInvalid null is a valid value and as such can be owned by collections.. In the UML 2.3 spec, Subclause 7.3.28, it simply says that .A literal null specifies the lack of a value,. which is the vague semantics that is echoed above in the OCL spec. However, to OCL 2.2 spec further elaborates on OclVoid in Subclause 11.2.3, where it notes that: .However, by virtue of the implicit conversion to a collection literal, an expression evaluating to null can be used as source of collection operations (such as .isEmpty.). If the source is the null literal, it is implicitly converted to Bag{}.. Thus, the OclVoid instance .null. is a distinguished value in OCL semantics, it is effectively equivalent to Bag{} in usage. This seems consistent with the phrase .lack of a value. used in the UML spec, though OclVoid is itself only defined in the OCL spec (as are all OCL collection types, too, for that matter). Note also that, in fUML, a value specification action with a null literal produces a null token . a token that holds no values . when it fires, which is the activity semantics equivalent of the empty set or .lack of a value.. In Alf, the notation .null. is considered equivalent to .any[]{}., that is, an untyped empty sequence, which, as a sequence construction expression, has a special mapping to a value specification with a null literal, giving it the fUML semantics (as would be expected for Alf). Isn.t it nice that now that we are all looking closely at UML semantics we have so many to choose from? -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, October 28, 2010 8:43 AM To: uml2-rtf@omg.org; ocl2-rtf@omg.org Cc: issues@omg.org Subject: Vagueness about meaning of 0..1 multiplicity in OCL and UML In the UML spec especially around the area of MultiplicityElement and ValueSpecification there are numerous types for operation results declared as [Integer] etc. These are freely interpreted as being both sets and integers, both in the way they are used: lowerBound = if lowerValue->isEmpty() then 1 else lowerValue.integerValue() endif and in the way they are constructed: integerValue = Set{} This notation [Integer] appears to be a shorthand for either Set(Integer) or Integer[0..1]. In C# I would call this type Nullable or just int?; but I don.t believe that such a type formally exists in OCL. OCL has the value OclVoid, which is supposed to conform to all types. Is OclVoid semantically equivalent to Set{}? If OclVoid conforms to all types, is there any difference semantically between an attribute declared as multiplicity [1] and one declared as multiplicity [0..1]? If there is no difference, this seriously contradicts my expectations of what multiplicity means. -- Steve Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Date: Thu, 28 Oct 2010 16:16:37 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Vagueness about meaning of 0..1 multiplicity in OCL and UML Thread-Index: Act2nWG9nHt7ZdhnR6ep7Ws1giycVgABdsJAAAECqsAAAIKyAA== From: To: , , , Cc: X-OriginalArrivalTime: 28 Oct 2010 14:16:28.0008 (UTC) FILETIME=[B5FEBE80:01CB76AA] Steve, >>> is there any difference between a UML property typed as Integer[1] and one typed as Integer[0..1]? Yes there is an important difference. In the first case the attribute need to have a value, and this value need to be a Integer (null is not a valid value) In the second case it is valid not to provide a value for the attribute. In OCL navigating a attribute that has no assigned value results in a 'null' value, but this does not mean that the value of the attribute is null (the navigation expression is null, not the attribute value, which is simply not specified) . Regarding the exact meaning of statement "OclVoid conforms to all types", maybe this needs some clarification or revision. Mariano -------------------------------------------------------------------------------- De : Steve Cook [mailto:Steve.Cook@microsoft.com] Envoyé jeudi 28 octobre 2010 15:59 À: Ed Seidewitz; uml2-rtf@omg.org; ocl2-rtf@omg.org Cc : issues@omg.org Objet : RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Ed >Isn.t it nice that now that we are all looking closely at UML semantics we have so many to choose from? Yes. Great. If OclVoid conforms to all types, so null is a valid member of any type, is there any difference between a UML property typed as Integer[1] and one typed as Integer[0..1]? Or do you see this as an explicit divergence between UML semantics and OCL semantics, where UML allows null to be a valid member of Integer[0..1] but not Integer[1]? If the latter, it.s a bit of a joke using OCL to define UML operations and constraints. -- Steve From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 28 October 2010 14:48 To: Steve Cook; uml2-rtf@omg.org; ocl2-rtf@omg.org Cc: issues@omg.org Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Steve . In the OCL 2.2 spec, Subclause 7.5.3, under .Navigation over Associations with Multiplicity Zero or One., it says: .Because the multiplicity of the role manager is one, self.manager is an object of type Person. Such a single object can be used as a Set as well. It then behaves as if it is a Set containing the single object. The usage as a set is done through the arrow followed by a property of Set.. While it doesn.t seem to say anything explicitly in the spec about non-association end properties with multiplicity 0..1, presumably the semantics are the same. That is, in the OCL type system, the type of such an association end is not explicit a collection, but a value of the association end may be treated in an expression as being a set with at most one member (so one can, e.g., check for emptiness using self.manager->isEmpty()), which is consistent with UML semantics. In OCL 2.2 Subclause 8.2, under .VoidType. it says: .VoidType represents a type that conforms to all types. The only instance of VoidType is OclVoid, which is further defined in the standard library. Furthermore OclVoid has exactly one instance called null - corresponding to the UML NullLiteral [sic] literal specification - and representing the absence of value. Note that in contrast with OclInvalid null is a valid value and as such can be owned by collections.. In the UML 2.3 spec, Subclause 7.3.28, it simply says that .A literal null specifies the lack of a value,. which is the vague semantics that is echoed above in the OCL spec. However, to OCL 2.2 spec further elaborates on OclVoid in Subclause 11.2.3, where it notes that: .However, by virtue of the implicit conversion to a collection literal, an expression evaluating to null can be used as source of collection operations (such as .isEmpty.). If the source is the null literal, it is implicitly converted to Bag{}.. Thus, the OclVoid instance .null. is a distinguished value in OCL semantics, it is effectively equivalent to Bag{} in usage. This seems consistent with the phrase .lack of a value. used in the UML spec, though OclVoid is itself only defined in the OCL spec (as are all OCL collection types, too, for that matter). Note also that, in fUML, a value specification action with a null literal produces a null token . a token that holds no values . when it fires, which is the activity semantics equivalent of the empty set or .lack of a value.. In Alf, the notation .null. is considered equivalent to .any[]{}., that is, an untyped empty sequence, which, as a sequence construction expression, has a special mapping to a value specification with a null literal, giving it the fUML semantics (as would be expected for Alf). Isn.t it nice that now that we are all looking closely at UML semantics we have so many to choose from? -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, October 28, 2010 8:43 AM To: uml2-rtf@omg.org; ocl2-rtf@omg.org Cc: issues@omg.org Subject: Vagueness about meaning of 0..1 multiplicity in OCL and UML In the UML spec especially around the area of MultiplicityElement and ValueSpecification there are numerous types for operation results declared as [Integer] etc. These are freely interpreted as being both sets and integers, both in the way they are used: lowerBound = if lowerValue->isEmpty() then 1 else lowerValue.integerValue() endif and in the way they are constructed: integerValue = Set{} This notation [Integer] appears to be a shorthand for either Set(Integer) or Integer[0..1]. In C# I would call this type Nullable or just int?; but I don.t believe that such a type formally exists in OCL. OCL has the value OclVoid, which is supposed to conform to all types. Is OclVoid semantically equivalent to Set{}? If OclVoid conforms to all types, is there any difference semantically between an attribute declared as multiplicity [1] and one declared as multiplicity [0..1]? If there is no difference, this seriously contradicts my expectations of what multiplicity means. -- Steve From: Steve Cook To: "mariano.belaunde@orange-ftgroup.com" , "ed-s@modeldriven.com" , "uml2-rtf@omg.org" , "ocl2-rtf@omg.org" CC: "issues@omg.org" Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Thread-Topic: Vagueness about meaning of 0..1 multiplicity in OCL and UML Thread-Index: Act2nWG9nHt7ZdhnR6ep7Ws1giycVgABdsJAAAECqsAAAIKyAAAAaaGw Date: Thu, 28 Oct 2010 14:22:49 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.20.35] Mariano, thanks. Are you asserting that Integer[1] and Integer[0..1] are distinct types in OCL? -- Steve From: mariano.belaunde@orange-ftgroup.com [mailto:mariano.belaunde@orange-ftgroup.com] Sent: 28 October 2010 15:17 To: Steve Cook; ed-s@modeldriven.com; uml2-rtf@omg.org; ocl2-rtf@omg.org Cc: issues@omg.org Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Steve, >>> is there any difference between a UML property typed as Integer[1] and one typed as Integer[0..1]? Yes there is an important difference. In the first case the attribute need to have a value, and this value need to be a Integer (null is not a valid value) In the second case it is valid not to provide a value for the attribute. In OCL navigating a attribute that has no assigned value results in a 'null' value, but this does not mean that the value of the attribute is null (the navigation expression is null, not the attribute value, which is simply not specified) . Regarding the exact meaning of statement "OclVoid conforms to all types", maybe this needs some clarification or revision. Mariano -------------------------------------------------------------------------------- De : Steve Cook [mailto:Steve.Cook@microsoft.com] Envoyé jeudi 28 octobre 2010 15:59 À: Ed Seidewitz; uml2-rtf@omg.org; ocl2-rtf@omg.org Cc : issues@omg.org Objet : RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Ed >Isn.t it nice that now that we are all looking closely at UML semantics we have so many to choose from? Yes. Great. If OclVoid conforms to all types, so null is a valid member of any type, is there any difference between a UML property typed as Integer[1] and one typed as Integer[0..1]? Or do you see this as an explicit divergence between UML semantics and OCL semantics, where UML allows null to be a valid member of Integer[0..1] but not Integer[1]? If the latter, it.s a bit of a joke using OCL to define UML operations and constraints. -- Steve From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 28 October 2010 14:48 To: Steve Cook; uml2-rtf@omg.org; ocl2-rtf@omg.org Cc: issues@omg.org Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Steve . In the OCL 2.2 spec, Subclause 7.5.3, under .Navigation over Associations with Multiplicity Zero or One., it says: .Because the multiplicity of the role manager is one, self.manager is an object of type Person. Such a single object can be used as a Set as well. It then behaves as if it is a Set containing the single object. The usage as a set is done through the arrow followed by a property of Set.. While it doesn.t seem to say anything explicitly in the spec about non-association end properties with multiplicity 0..1, presumably the semantics are the same. That is, in the OCL type system, the type of such an association end is not explicit a collection, but a value of the association end may be treated in an expression as being a set with at most one member (so one can, e.g., check for emptiness using self.manager->isEmpty()), which is consistent with UML semantics. In OCL 2.2 Subclause 8.2, under .VoidType. it says: .VoidType represents a type that conforms to all types. The only instance of VoidType is OclVoid, which is further defined in the standard library. Furthermore OclVoid has exactly one instance called null - corresponding to the UML NullLiteral [sic] literal specification - and representing the absence of value. Note that in contrast with OclInvalid null is a valid value and as such can be owned by collections.. In the UML 2.3 spec, Subclause 7.3.28, it simply says that .A literal null specifies the lack of a value,. which is the vague semantics that is echoed above in the OCL spec. However, to OCL 2.2 spec further elaborates on OclVoid in Subclause 11.2.3, where it notes that: .However, by virtue of the implicit conversion to a collection literal, an expression evaluating to null can be used as source of collection operations (such as .isEmpty.). If the source is the null literal, it is implicitly converted to Bag{}.. Thus, the OclVoid instance .null. is a distinguished value in OCL semantics, it is effectively equivalent to Bag{} in usage. This seems consistent with the phrase .lack of a value. used in the UML spec, though OclVoid is itself only defined in the OCL spec (as are all OCL collection types, too, for that matter). Note also that, in fUML, a value specification action with a null literal produces a null token . a token that holds no values . when it fires, which is the activity semantics equivalent of the empty set or .lack of a value.. In Alf, the notation .null. is considered equivalent to .any[]{}., that is, an untyped empty sequence, which, as a sequence construction expression, has a special mapping to a value specification with a null literal, giving it the fUML semantics (as would be expected for Alf). Isn.t it nice that now that we are all looking closely at UML semantics we have so many to choose from? -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, October 28, 2010 8:43 AM To: uml2-rtf@omg.org; ocl2-rtf@omg.org Cc: issues@omg.org Subject: Vagueness about meaning of 0..1 multiplicity in OCL and UML In the UML spec especially around the area of MultiplicityElement and ValueSpecification there are numerous types for operation results declared as [Integer] etc. These are freely interpreted as being both sets and integers, both in the way they are used: lowerBound = if lowerValue->isEmpty() then 1 else lowerValue.integerValue() endif and in the way they are constructed: integerValue = Set{} This notation [Integer] appears to be a shorthand for either Set(Integer) or Integer[0..1]. In C# I would call this type Nullable or just int?; but I don.t believe that such a type formally exists in OCL. OCL has the value OclVoid, which is supposed to conform to all types. Is OclVoid semantically equivalent to Set{}? If OclVoid conforms to all types, is there any difference semantically between an attribute declared as multiplicity [1] and one declared as multiplicity [0..1]? If there is no difference, this seriously contradicts my expectations of what multiplicity means. -- Steve Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Date: Thu, 28 Oct 2010 10:24:24 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Vagueness about meaning of 0..1 multiplicity in OCL and UML Thread-Index: Act2nWG9nHt7ZdhnR6ep7Ws1giycVgABdsJAAAECqsAAAHiYsA== From: "Ed Seidewitz" To: "Steve Cook" , , Cc: Steve . In UML, multiplicity is not actually part of the type. It is a separate constraint on cardinality of values. The real vagueness in UML semantics in this area is when this constraint actually has to hold. Now, OCL does not formally use the concept of multiplicity as such at all, but uses collections instead. In OCL 2.2 Subclause 7.5.1 it says .Whenever the multiplicity of an attribute is greater than 1, the result type is collection of values. (and there is a similar statement elsewhere about association ends). As I quoted previously, when the multiplicity upper bound is 1, the OCL type is not a collection, but a single value can always be treated as if it was a set of 1 member in OCL. As far as I understand the OCL semantics on this (though I have not tried to trace through to the formal semantics to confirm it), since single values can always be treated as sets of 1 member, OCL expressions can always be effectively thought of as operating on collections. Thus, declaring something to be Integer within an OCL expression (say in a .let. expression) is, indeed, equivalent to Integer[0..1] in UML. And an OCL expression of type Integer could end up returning an empty value in some cases. However, if an OCL expression of type Integer is used to compute the result of, say, an operation with return type and multiplicity Integer[1], then there is a UML constraint that a call to the operation must always return exactly one Integer value. Thus, whatever the OCL expression is, there is also an effective additional (UML imposed) constraint that .result->notEmpty().. If the given OCL expression for the result can possibly be empty, then the specification of the operation is just logically inconsistent, though syntactically correct in OCL. The real issue, I think, comes up in the context clause for an operation defined in a UML model, in which OCL types are used for the operation signature, but the real operation is as given in the UML model. The problem is that OCL cannot notate all UML multiplicities . collections always have an effective multiplicity of 0..* and non-collection types have an effective multiplicity of 0..1. Thus, there may be additional multiplicity constraints in the model that are not shown in the OCL text. (Alf, by the way, allows full UML multiplicity notation in operation signatures.) -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, October 28, 2010 9:59 AM To: Ed Seidewitz; uml2-rtf@omg.org; ocl2-rtf@omg.org Cc: issues@omg.org Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Ed >Isn.t it nice that now that we are all looking closely at UML semantics we have so many to choose from? Yes. Great. If OclVoid conforms to all types, so null is a valid member of any type, is there any difference between a UML property typed as Integer[1] and one typed as Integer[0..1]? Or do you see this as an explicit divergence between UML semantics and OCL semantics, where UML allows null to be a valid member of Integer[0..1] but not Integer[1]? If the latter, it.s a bit of a joke using OCL to define UML operations and constraints. -- Steve From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 28 October 2010 14:48 To: Steve Cook; uml2-rtf@omg.org; ocl2-rtf@omg.org Cc: issues@omg.org Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Steve . In the OCL 2.2 spec, Subclause 7.5.3, under .Navigation over Associations with Multiplicity Zero or One., it says: .Because the multiplicity of the role manager is one, self.manager is an object of type Person. Such a single object can be used as a Set as well. It then behaves as if it is a Set containing the single object. The usage as a set is done through the arrow followed by a property of Set.. While it doesn.t seem to say anything explicitly in the spec about non-association end properties with multiplicity 0..1, presumably the semantics are the same. That is, in the OCL type system, the type of such an association end is not explicit a collection, but a value of the association end may be treated in an expression as being a set with at most one member (so one can, e.g., check for emptiness using self.manager->isEmpty()), which is consistent with UML semantics. In OCL 2.2 Subclause 8.2, under .VoidType. it says: .VoidType represents a type that conforms to all types. The only instance of VoidType is OclVoid, which is further defined in the standard library. Furthermore OclVoid has exactly one instance called null - corresponding to the UML NullLiteral [sic] literal specification - and representing the absence of value. Note that in contrast with OclInvalid null is a valid value and as such can be owned by collections.. In the UML 2.3 spec, Subclause 7.3.28, it simply says that .A literal null specifies the lack of a value,. which is the vague semantics that is echoed above in the OCL spec. However, to OCL 2.2 spec further elaborates on OclVoid in Subclause 11.2.3, where it notes that: .However, by virtue of the implicit conversion to a collection literal, an expression evaluating to null can be used as source of collection operations (such as .isEmpty.). If the source is the null literal, it is implicitly converted to Bag{}.. Thus, the OclVoid instance .null. is a distinguished value in OCL semantics, it is effectively equivalent to Bag{} in usage. This seems consistent with the phrase .lack of a value. used in the UML spec, though OclVoid is itself only defined in the OCL spec (as are all OCL collection types, too, for that matter). Note also that, in fUML, a value specification action with a null literal produces a null token . a token that holds no values . when it fires, which is the activity semantics equivalent of the empty set or .lack of a value.. In Alf, the notation .null. is considered equivalent to .any[]{}., that is, an untyped empty sequence, which, as a sequence construction expression, has a special mapping to a value specification with a null literal, giving it the fUML semantics (as would be expected for Alf). Isn.t it nice that now that we are all looking closely at UML semantics we have so many to choose from? -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, October 28, 2010 8:43 AM To: uml2-rtf@omg.org; ocl2-rtf@omg.org Cc: issues@omg.org Subject: Vagueness about meaning of 0..1 multiplicity in OCL and UML In the UML spec especially around the area of MultiplicityElement and ValueSpecification there are numerous types for operation results declared as [Integer] etc. These are freely interpreted as being both sets and integers, both in the way they are used: lowerBound = if lowerValue->isEmpty() then 1 else lowerValue.integerValue() endif and in the way they are constructed: integerValue = Set{} This notation [Integer] appears to be a shorthand for either Set(Integer) or Integer[0..1]. In C# I would call this type Nullable or just int?; but I don.t believe that such a type formally exists in OCL. OCL has the value OclVoid, which is supposed to conform to all types. Is OclVoid semantically equivalent to Set{}? If OclVoid conforms to all types, is there any difference semantically between an attribute declared as multiplicity [1] and one declared as multiplicity [0..1]? If there is no difference, this seriously contradicts my expectations of what multiplicity means. -- Steve From: "Willink, Ed" To: "'Steve Cook'" , Ed Seidewitz , uml2-rtf@omg.org, ocl2-rtf@omg.org Cc: issues@omg.org Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Date: Thu, 28 Oct 2010 15:29:24 +0100 X-Mailer: Internet Mail Service (5.5.2657.72) Hi In OCL I think, An Integer[1] may have integer values, null or invalid, of which only integer values are well-formed. An Integer[0..1] may have integer values, null or invalid, of which integer values and null are well-formed. A validation too may therefore enforce no-null for Integer[1]. [There is no Integer[0..1] in OCL, this is just what OCL obtains from a meta-model, whose tooling MOF/Ecore may reify it as object or collection.] --- "Because the multiplicity of the role manager is one, self.manager is an object of type Person. Such a single object can be used as a Set as well. It then behaves as if it is a Set containing the single object. The usage as a set is done through the arrow followed by a property of Set." There are outstanding OCL issues here, some of contradiction more of underspecification. I see the underlying (statically analyzed) semantics for anObject -> feature as creation of a collection of anObject followed by navigation involving a collection feature (or iteration). If anObject is null, the collection is empty. The exact kind of the collection is a problem; the OCL 2.2 specification variously specifies a Set or a Bag. Set is more useful since it has more operations, perhaps Bag is more logical. But from a UML perspective the singleton object has an associated ordering and uniqueness so this could/should define the collection kind. Unfortunately existing tools, particularly Ecore, give surprising defaults for singletons which noone has ever worried about, so if OCL suddenly gave them significance, users would be surprised that many existing models behave strangely. Regards Ed Willink -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: 28 October 2010 14:59 To: Ed Seidewitz; uml2-rtf@omg.org; ocl2-rtf@omg.org Cc: issues@omg.org Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Ed >Isn't it nice that now that we are all looking closely at UML semantics we have so many to choose from? Yes. Great. If OclVoid conforms to all types, so null is a valid member of any type, is there any difference between a UML property typed as Integer[1] and one typed as Integer[0..1]? Or do you see this as an explicit divergence between UML semantics and OCL semantics, where UML allows null to be a valid member of Integer[0..1] but not Integer[1]? If the latter, it's a bit of a joke using OCL to define UML operations and constraints. -- Steve From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 28 October 2010 14:48 To: Steve Cook; uml2-rtf@omg.org; ocl2-rtf@omg.org Cc: issues@omg.org Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Steve - In the OCL 2.2 spec, Subclause 7.5.3, under "Navigation over Associations with Multiplicity Zero or One", it says: "Because the multiplicity of the role manager is one, self.manager is an object of type Person. Such a single object can be used as a Set as well. It then behaves as if it is a Set containing the single object. The usage as a set is done through the arrow followed by a property of Set." While it doesn't seem to say anything explicitly in the spec about non-association end properties with multiplicity 0..1, presumably the semantics are the same. That is, in the OCL type system, the type of such an association end is not explicit a collection, but a value of the association end may be treated in an expression as being a set with at most one member (so one can, e.g., check for emptiness using self.manager->isEmpty()), which is consistent with UML semantics. In OCL 2.2 Subclause 8.2, under "VoidType" it says: "VoidType represents a type that conforms to all types. The only instance of VoidType is OclVoid, which is further defined in the standard library. Furthermore OclVoid has exactly one instance called null - corresponding to the UML NullLiteral [sic] literal specification - and representing the absence of value. Note that in contrast with OclInvalid null is a valid value and as such can be owned by collections." In the UML 2.3 spec, Subclause 7.3.28, it simply says that "A literal null specifies the lack of a value," which is the vague semantics that is echoed above in the OCL spec. However, to OCL 2.2 spec further elaborates on OclVoid in Subclause 11.2.3, where it notes that: "However, by virtue of the implicit conversion to a collection literal, an expression evaluating to null can be used as source of collection operations (such as 'isEmpty'). If the source is the null literal, it is implicitly converted to Bag{}." Thus, the OclVoid instance "null" is a distinguished value in OCL semantics, it is effectively equivalent to Bag{} in usage. This seems consistent with the phrase "lack of a value" used in the UML spec, though OclVoid is itself only defined in the OCL spec (as are all OCL collection types, too, for that matter). Note also that, in fUML, a value specification action with a null literal produces a null token - a token that holds no values - when it fires, which is the activity semantics equivalent of the empty set or "lack of a value". In Alf, the notation "null" is considered equivalent to "any[]{}", that is, an untyped empty sequence, which, as a sequence construction expression, has a special mapping to a value specification with a null literal, giving it the fUML semantics (as would be expected for Alf). Isn't it nice that now that we are all looking closely at UML semantics we have so many to choose from? -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, October 28, 2010 8:43 AM To: uml2-rtf@omg.org; ocl2-rtf@omg.org Cc: issues@omg.org Subject: Vagueness about meaning of 0..1 multiplicity in OCL and UML In the UML spec especially around the area of MultiplicityElement and ValueSpecification there are numerous types for operation results declared as [Integer] etc. These are freely interpreted as being both sets and integers, both in the way they are used: lowerBound = if lowerValue->isEmpty() then 1 else lowerValue.integerValue() endif and in the way they are constructed: integerValue = Set{} This notation [Integer] appears to be a shorthand for either Set(Integer) or Integer[0..1]. In C# I would call this type Nullable or just int?; but I don't believe that such a type formally exists in OCL. OCL has the value OclVoid, which is supposed to conform to all types. Is OclVoid semantically equivalent to Set{}? If OclVoid conforms to all types, is there any difference semantically between an attribute declared as multiplicity [1] and one declared as multiplicity [0..1]? If there is no difference, this seriously contradicts my expectations of what multiplicity means. -- Steve Please consider the environment before printing a hard copy of this e-mail. The information contained in this e-mail is confidential. It is intended only for the stated addressee(s) and access to it by any other person is unauthorised. If you are not an addressee, you must not disclose, copy, circulate or in any other way use or rely on the information contained in this e-mail. Such unauthorised use may be unlawful. If you have received this e-mail in error, please inform us immediately on +44 (0)118 986 8601 and delete it and all copies from your system. Thales Research and Technology (UK) Limited. A company registered in England and Wales. Registered Office: 2 Dashwood Lang Road, The Bourne Business Park, Addlestone, Weybridge, Surrey KT15 2NX. Registered Number: 774298 Thales UK Limited. A company registered in England and Wales. Registered Office: 2 Dashwood Lang Road, The Bourne Business Park, Addlestone, Weybridge, Surrey KT15 2NX. Registered Number: 868273 From: Steve Cook To: Ed Seidewitz , "uml2-rtf@omg.org" , "ocl2-rtf@omg.org" CC: "issues@omg.org" Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Thread-Topic: Vagueness about meaning of 0..1 multiplicity in OCL and UML Thread-Index: Act2nWG9nHt7ZdhnR6ep7Ws1giycVgABdsJAAAECqsAAAHiYsAAAwygw Date: Thu, 28 Oct 2010 14:35:13 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.20.35] Ed So if I understand correctly, you are saying: 1. All operations in UML should be defined with a signature that uses multiplicities, not Set(x) notation. 2. OCL itself does not distinguish between T[1] and T[0..1] 3. There should be an extra level of semantic checking when defining a UML operation in OCL, to both check that it is well-typed from an OCL point of view, and then check that the result is additionally well-typed with respect to the expected multiplicity of its value. That might work, but it seems like a hack. If OCL explicitly introduced nullable and non-nullable types, we could do a much cleaner match. -- Steve From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 28 October 2010 15:24 To: Steve Cook; uml2-rtf@omg.org; ocl2-rtf@omg.org Cc: issues@omg.org Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Steve . In UML, multiplicity is not actually part of the type. It is a separate constraint on cardinality of values. The real vagueness in UML semantics in this area is when this constraint actually has to hold. Now, OCL does not formally use the concept of multiplicity as such at all, but uses collections instead. In OCL 2.2 Subclause 7.5.1 it says .Whenever the multiplicity of an attribute is greater than 1, the result type is collection of values. (and there is a similar statement elsewhere about association ends). As I quoted previously, when the multiplicity upper bound is 1, the OCL type is not a collection, but a single value can always be treated as if it was a set of 1 member in OCL. As far as I understand the OCL semantics on this (though I have not tried to trace through to the formal semantics to confirm it), since single values can always be treated as sets of 1 member, OCL expressions can always be effectively thought of as operating on collections. Thus, declaring something to be Integer within an OCL expression (say in a .let. expression) is, indeed, equivalent to Integer[0..1] in UML. And an OCL expression of type Integer could end up returning an empty value in some cases. However, if an OCL expression of type Integer is used to compute the result of, say, an operation with return type and multiplicity Integer[1], then there is a UML constraint that a call to the operation must always return exactly one Integer value. Thus, whatever the OCL expression is, there is also an effective additional (UML imposed) constraint that .result->notEmpty().. If the given OCL expression for the result can possibly be empty, then the specification of the operation is just logically inconsistent, though syntactically correct in OCL. The real issue, I think, comes up in the context clause for an operation defined in a UML model, in which OCL types are used for the operation signature, but the real operation is as given in the UML model. The problem is that OCL cannot notate all UML multiplicities . collections always have an effective multiplicity of 0..* and non-collection types have an effective multiplicity of 0..1. Thus, there may be additional multiplicity constraints in the model that are not shown in the OCL text. (Alf, by the way, allows full UML multiplicity notation in operation signatures.) -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, October 28, 2010 9:59 AM To: Ed Seidewitz; uml2-rtf@omg.org; ocl2-rtf@omg.org Cc: issues@omg.org Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Ed >Isn.t it nice that now that we are all looking closely at UML semantics we have so many to choose from? Yes. Great. If OclVoid conforms to all types, so null is a valid member of any type, is there any difference between a UML property typed as Integer[1] and one typed as Integer[0..1]? Or do you see this as an explicit divergence between UML semantics and OCL semantics, where UML allows null to be a valid member of Integer[0..1] but not Integer[1]? If the latter, it.s a bit of a joke using OCL to define UML operations and constraints. -- Steve From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 28 October 2010 14:48 To: Steve Cook; uml2-rtf@omg.org; ocl2-rtf@omg.org Cc: issues@omg.org Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Steve . In the OCL 2.2 spec, Subclause 7.5.3, under .Navigation over Associations with Multiplicity Zero or One., it says: .Because the multiplicity of the role manager is one, self.manager is an object of type Person. Such a single object can be used as a Set as well. It then behaves as if it is a Set containing the single object. The usage as a set is done through the arrow followed by a property of Set.. While it doesn.t seem to say anything explicitly in the spec about non-association end properties with multiplicity 0..1, presumably the semantics are the same. That is, in the OCL type system, the type of such an association end is not explicit a collection, but a value of the association end may be treated in an expression as being a set with at most one member (so one can, e.g., check for emptiness using self.manager->isEmpty()), which is consistent with UML semantics. In OCL 2.2 Subclause 8.2, under .VoidType. it says: .VoidType represents a type that conforms to all types. The only instance of VoidType is OclVoid, which is further defined in the standard library. Furthermore OclVoid has exactly one instance called null - corresponding to the UML NullLiteral [sic] literal specification - and representing the absence of value. Note that in contrast with OclInvalid null is a valid value and as such can be owned by collections.. In the UML 2.3 spec, Subclause 7.3.28, it simply says that .A literal null specifies the lack of a value,. which is the vague semantics that is echoed above in the OCL spec. However, to OCL 2.2 spec further elaborates on OclVoid in Subclause 11.2.3, where it notes that: .However, by virtue of the implicit conversion to a collection literal, an expression evaluating to null can be used as source of collection operations (such as .isEmpty.). If the source is the null literal, it is implicitly converted to Bag{}.. Thus, the OclVoid instance .null. is a distinguished value in OCL semantics, it is effectively equivalent to Bag{} in usage. This seems consistent with the phrase .lack of a value. used in the UML spec, though OclVoid is itself only defined in the OCL spec (as are all OCL collection types, too, for that matter). Note also that, in fUML, a value specification action with a null literal produces a null token . a token that holds no values . when it fires, which is the activity semantics equivalent of the empty set or .lack of a value.. In Alf, the notation .null. is considered equivalent to .any[]{}., that is, an untyped empty sequence, which, as a sequence construction expression, has a special mapping to a value specification with a null literal, giving it the fUML semantics (as would be expected for Alf). Isn.t it nice that now that we are all looking closely at UML semantics we have so many to choose from? -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, October 28, 2010 8:43 AM To: uml2-rtf@omg.org; ocl2-rtf@omg.org Cc: issues@omg.org Subject: Vagueness about meaning of 0..1 multiplicity in OCL and UML In the UML spec especially around the area of MultiplicityElement and ValueSpecification there are numerous types for operation results declared as [Integer] etc. These are freely interpreted as being both sets and integers, both in the way they are used: lowerBound = if lowerValue->isEmpty() then 1 else lowerValue.integerValue() endif and in the way they are constructed: integerValue = Set{} This notation [Integer] appears to be a shorthand for either Set(Integer) or Integer[0..1]. In C# I would call this type Nullable or just int?; but I don.t believe that such a type formally exists in OCL. OCL has the value OclVoid, which is supposed to conform to all types. Is OclVoid semantically equivalent to Set{}? If OclVoid conforms to all types, is there any difference semantically between an attribute declared as multiplicity [1] and one declared as multiplicity [0..1]? If there is no difference, this seriously contradicts my expectations of what multiplicity means. -- Steve Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Date: Thu, 28 Oct 2010 10:36:07 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Vagueness about meaning of 0..1 multiplicity in OCL and UML Thread-Index: Act2nWG9nHt7ZdhnR6ep7Ws1giycVgABdsJAAAECqsAAAIKyAAAAaaGwAAA8CYA= From: "Ed Seidewitz" To: "Steve Cook" , , , Cc: Steve, Mariano . First of all, as noted in my previous message (which leapfrogged Mariano.s last one), neither .Integer[1]. not .Integer[0..1]. are actually types in either UML or OCL. In UML, multiplicity is not formally part of the type . it is an additional cardinality constraint given on multiplicity elements, and there are typed elements in UML that are not multiplicity elements (such as object nodes other than pins in activities). Multiplicity is not part of the OCL type system at all. In OCL, Integer and Set(Integer) are formally separate types. However, an expression of type Integer in OCL can be treated as a set of at most one member, so it.s effective type is essentially a constrained Set(Integer), equivalent to a type/multiplicity of Integer[0..1] in UML. However, as Mariano notes, having a multiplicity of 1 on an attribute places an additional constraint on that attribute . it must have a value. In an OCL expression of the form .x.a = y., where the attribute .a. has multiplicity 1, the OCL subexpression y may evaluate to a null value . but x.a can simply never equal such a value, since the UML model requires .a. it to have a value. Thus, in any well-formed instance of the UML model, the OCL equality must be false. Finally, I think the statement .OclVoid conforms to all types. is fine, within the context of OCL semantics. It is consistent with any OCL expression of any type effectively having, in UML terms, a multiplicity lower bound of 0 and the implicit conversion of a .null. value to .Bag{}.. -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, October 28, 2010 10:23 AM To: mariano.belaunde@orange-ftgroup.com; Ed Seidewitz; uml2-rtf@omg.org; ocl2-rtf@omg.org Cc: issues@omg.org Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Mariano, thanks. Are you asserting that Integer[1] and Integer[0..1] are distinct types in OCL? -- Steve From: mariano.belaunde@orange-ftgroup.com [mailto:mariano.belaunde@orange-ftgroup.com] Sent: 28 October 2010 15:17 To: Steve Cook; ed-s@modeldriven.com; uml2-rtf@omg.org; ocl2-rtf@omg.org Cc: issues@omg.org Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Steve, >>> is there any difference between a UML property typed as Integer[1] and one typed as Integer[0..1]? Yes there is an important difference. In the first case the attribute need to have a value, and this value need to be a Integer (null is not a valid value) In the second case it is valid not to provide a value for the attribute. In OCL navigating a attribute that has no assigned value results in a 'null' value, but this does not mean that the value of the attribute is null (the navigation expression is null, not the attribute value, which is simply not specified) . Regarding the exact meaning of statement "OclVoid conforms to all types", maybe this needs some clarification or revision. Mariano -------------------------------------------------------------------------------- De : Steve Cook [mailto:Steve.Cook@microsoft.com] Envoyé jeudi 28 octobre 2010 15:59 À: Ed Seidewitz; uml2-rtf@omg.org; ocl2-rtf@omg.org Cc : issues@omg.org Objet : RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Ed >Isn.t it nice that now that we are all looking closely at UML semantics we have so many to choose from? Yes. Great. If OclVoid conforms to all types, so null is a valid member of any type, is there any difference between a UML property typed as Integer[1] and one typed as Integer[0..1]? Or do you see this as an explicit divergence between UML semantics and OCL semantics, where UML allows null to be a valid member of Integer[0..1] but not Integer[1]? If the latter, it.s a bit of a joke using OCL to define UML operations and constraints. -- Steve From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 28 October 2010 14:48 To: Steve Cook; uml2-rtf@omg.org; ocl2-rtf@omg.org Cc: issues@omg.org Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Steve . In the OCL 2.2 spec, Subclause 7.5.3, under .Navigation over Associations with Multiplicity Zero or One., it says: .Because the multiplicity of the role manager is one, self.manager is an object of type Person. Such a single object can be used as a Set as well. It then behaves as if it is a Set containing the single object. The usage as a set is done through the arrow followed by a property of Set.. While it doesn.t seem to say anything explicitly in the spec about non-association end properties with multiplicity 0..1, presumably the semantics are the same. That is, in the OCL type system, the type of such an association end is not explicit a collection, but a value of the association end may be treated in an expression as being a set with at most one member (so one can, e.g., check for emptiness using self.manager->isEmpty()), which is consistent with UML semantics. In OCL 2.2 Subclause 8.2, under .VoidType. it says: .VoidType represents a type that conforms to all types. The only instance of VoidType is OclVoid, which is further defined in the standard library. Furthermore OclVoid has exactly one instance called null - corresponding to the UML NullLiteral [sic] literal specification - and representing the absence of value. Note that in contrast with OclInvalid null is a valid value and as such can be owned by collections.. In the UML 2.3 spec, Subclause 7.3.28, it simply says that .A literal null specifies the lack of a value,. which is the vague semantics that is echoed above in the OCL spec. However, to OCL 2.2 spec further elaborates on OclVoid in Subclause 11.2.3, where it notes that: .However, by virtue of the implicit conversion to a collection literal, an expression evaluating to null can be used as source of collection operations (such as .isEmpty.). If the source is the null literal, it is implicitly converted to Bag{}.. Thus, the OclVoid instance .null. is a distinguished value in OCL semantics, it is effectively equivalent to Bag{} in usage. This seems consistent with the phrase .lack of a value. used in the UML spec, though OclVoid is itself only defined in the OCL spec (as are all OCL collection types, too, for that matter). Note also that, in fUML, a value specification action with a null literal produces a null token . a token that holds no values . when it fires, which is the activity semantics equivalent of the empty set or .lack of a value.. In Alf, the notation .null. is considered equivalent to .any[]{}., that is, an untyped empty sequence, which, as a sequence construction expression, has a special mapping to a value specification with a null literal, giving it the fUML semantics (as would be expected for Alf). Isn.t it nice that now that we are all looking closely at UML semantics we have so many to choose from? -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, October 28, 2010 8:43 AM To: uml2-rtf@omg.org; ocl2-rtf@omg.org Cc: issues@omg.org Subject: Vagueness about meaning of 0..1 multiplicity in OCL and UML In the UML spec especially around the area of MultiplicityElement and ValueSpecification there are numerous types for operation results declared as [Integer] etc. These are freely interpreted as being both sets and integers, both in the way they are used: lowerBound = if lowerValue->isEmpty() then 1 else lowerValue.integerValue() endif and in the way they are constructed: integerValue = Set{} This notation [Integer] appears to be a shorthand for either Set(Integer) or Integer[0..1]. In C# I would call this type Nullable or just int?; but I don.t believe that such a type formally exists in OCL. OCL has the value OclVoid, which is supposed to conform to all types. Is OclVoid semantically equivalent to Set{}? If OclVoid conforms to all types, is there any difference semantically between an attribute declared as multiplicity [1] and one declared as multiplicity [0..1]? If there is no difference, this seriously contradicts my expectations of what multiplicity means. -- Steve Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Date: Thu, 28 Oct 2010 10:40:59 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Vagueness about meaning of 0..1 multiplicity in OCL and UML Thread-Index: Act2rReW0BxyHNkUQ0mTIxRoecpLlwAALgMQ From: "Ed Seidewitz" To: "Willink, Ed" Cc: , , Ed . Yes, I think this is consistent with what I was trying to say about OCL semantics in this regard. But the first part of your message states it more precisely. -- Ed -------------------------------------------------------------------------------- From: Willink, Ed [mailto:Ed.Willink@thalesgroup.com] Sent: Thursday, October 28, 2010 10:29 AM To: 'Steve Cook'; Ed Seidewitz; uml2-rtf@omg.org; ocl2-rtf@omg.org Cc: issues@omg.org Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Hi In OCL I think, An Integer[1] may have integer values, null or invalid, of which only integer values are well-formed. An Integer[0..1] may have integer values, null or invalid, of which integer values and null are well-formed. A validation too may therefore enforce no-null for Integer[1]. [There is no Integer[0..1] in OCL, this is just what OCL obtains from a meta-model, whose tooling MOF/Ecore may reify it as object or collection.] --- "Because the multiplicity of the role manager is one, self.manager is an object of type Person. Such a single object can be used as a Set as well. It then behaves as if it is a Set containing the single object. The usage as a set is done through the arrow followed by a property of Set." There are outstanding OCL issues here, some of contradiction more of underspecification. I see theunderlying (statically analyzed) semantics for anObject -> feature as creation of a collection of anObject followed by navigation involving a collection feature (or iteration). If anObject is null, the collection is empty. The exact kind of the collection is a problem; the OCL 2.2 specification variously specifies a Set or a Bag. Set is more useful since it has more operations, perhaps Bag is more logical. But from a UML perspective the singleton object has an associated ordering and uniqueness so this could/should define the collection kind. Unfortunately existing tools, particularly Ecore, give surprising defaults for singletons which noone has ever worried about, so if OCL suddenly gave them significance, users would be surprised that many existing models behave strangely. Regards Ed Willink -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: 28 October 2010 14:59 To: Ed Seidewitz; uml2-rtf@omg.org; ocl2-rtf@omg.org Cc: issues@omg.org Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Ed >Isn't it nice that now that we are all looking closely at UML semantics we have so many to choose from? Yes. Great. If OclVoid conforms to all types, so null is a valid member of any type, is there any difference between a UML property typed as Integer[1] and one typed as Integer[0..1]? Or do you see this as an explicit divergence between UML semantics and OCL semantics, where UML allows null to be a valid member of Integer[0..1] but not Integer[1]? If the latter, it's a bit of a joke using OCL to define UML operations and constraints. -- Steve From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 28 October 2010 14:48 To: Steve Cook; uml2-rtf@omg.org; ocl2-rtf@omg.org Cc: issues@omg.org Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Steve - In the OCL 2.2 spec, Subclause 7.5.3, under "Navigation over Associations with Multiplicity Zero or One", it says: "Because the multiplicity of the role manager is one, self.manager is an object of type Person. Such a single object can be used as a Set as well. It then behaves as if it is a Set containing the single object. The usage as a set is done through the arrow followed by a property of Set." While it doesn't seem to say anything explicitly in the spec about non-association end properties with multiplicity 0..1, presumably the semantics are the same. That is, in the OCL type system, the type of such an association end is not explicit a collection, but a value of the association end may be treated in an expression as being a set with at most one member (so one can, e.g., check for emptiness using self.manager->isEmpty()), which is consistent with UML semantics. In OCL 2.2 Subclause 8.2, under "VoidType" it says: "VoidType represents a type that conforms to all types. The only instance of VoidType is OclVoid, which is further defined in the standard library. Furthermore OclVoid has exactly one instance called null - corresponding to the UML NullLiteral [sic] literal specification - and representing the absence of value. Note that in contrast with OclInvalid null is a valid value and as such can be owned by collections." In the UML 2.3 spec, Subclause 7.3.28, it simply says that "A literal null specifies the lack of a value," which is the vague semantics that is echoed above in the OCL spec. However, to OCL 2.2 spec further elaborates on OclVoid in Subclause 11.2.3, where it notes that: "However, by virtue of the implicit conversion to a collection literal, an expression evaluating to null can be used as source of collection operations (such as 'isEmpty'). If the source is the null literal, it is implicitly converted to Bag{}." Thus, the OclVoid instance "null" is a distinguished value in OCL semantics, it is effectively equivalent to Bag{} in usage. This seems consistent with the phrase "lack of a value" used in the UML spec, though OclVoid is itself only defined in the OCL spec (as are all OCL collection types, too, for that matter). Note also that, in fUML, a value specification action with a null literal produces a null token - a token that holds no values - when it fires, which is the activity semantics equivalent of the empty set or "lack of a value". In Alf, the notation "null" is considered equivalent to "any[]{}", that is, an untyped empty sequence, which, as a sequence construction expression, has a special mapping to a value specification with a null literal, giving it the fUML semantics (as would be expected for Alf). Isn't it nice that now that we are all looking closely at UML semantics we have so many to choose from? -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, October 28, 2010 8:43 AM To: uml2-rtf@omg.org; ocl2-rtf@omg.org Cc: issues@omg.org Subject: Vagueness about meaning of 0..1 multiplicity in OCL and UML In the UML spec especially around the area of MultiplicityElement and ValueSpecification there are numerous types for operation results declared as [Integer] etc. These are freely interpreted as being both sets and integers, both in the way they are used: lowerBound = if lowerValue->isEmpty() then 1 else lowerValue.integerValue() endif and in the way they are constructed: integerValue = Set{} This notation [Integer] appears to be a shorthand for either Set(Integer) or Integer[0..1]. In C# I would call this type Nullable or just int?; but I don't believe that such a type formally exists in OCL. OCL has the value OclVoid, which is supposed to conform to all types. Is OclVoid semantically equivalent to Set{}? If OclVoid conforms to all types, is there any difference semantically between an attribute declared as multiplicity [1] and one declared as multiplicity [0..1]? If there is no difference, this seriously contradicts my expectations of what multiplicity means. -- Steve Please consider the environment before printing a hard copy of this e-mail. The information contained in this e-mail is confidential. It is intended only for the stated addressee(s) and access to it by any other person is unauthorised. If you are not an addressee, you must not disclose, copy, circulate or in any other way use or rely on the information contained in this e-mail. Such unauthorised use may be unlawful. If you have received this e-mail in error, please inform us immediately on +44 (0)118 986 8601 and delete it and all copies from your system. Thales Research and Technology (UK) Limited. A company registered in England and Wales. Registered Office: 2 Dashwood Lang Road, The Bourne Business Park, Addlestone, Weybridge, Surrey KT15 2NX. Registered Number: 774298 Thales UK Limited. A company registered in England and Wales. Registered Office: 2 Dashwood Lang Road, The Bourne Business Park, Addlestone, Weybridge, Surrey KT15 2NX. Registered Number: 868273 Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML [Issue 15789] Date: Thu, 28 Oct 2010 10:46:09 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Vagueness about meaning of 0..1 multiplicity in OCL and UML [Issue 15789] Thread-Index: Act2nWG9nHt7ZdhnR6ep7Ws1giycVgABdsJAAAECqsAAAHiYsAAAwygwAAB9HgA= From: "Ed Seidewitz" To: "Steve Cook" Cc: , , Steve . Yes, that summarizes what I was saying. Note that .Set(x). is not actually UML notation, so it is not clear that it can be used as a type within a UML model, anyway. However, in an OCL context clause you have to use OCL notation, which does not include UML multiplicities, as far as I know. I agree that this whole thing is a bit of a hack, and it is unfortunate that the OCL type system was not better integrated with the UML type system from the beginning. Of course, a big problem was the lack of formality and clarity in the specification of the type system and semantics on the UML side. I know that Ed Willink, among others, is working on better integration on the OCL side. But, for now, we are where we are. -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, October 28, 2010 10:35 AM To: Ed Seidewitz; uml2-rtf@omg.org; ocl2-rtf@omg.org Cc: issues@omg.org Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Ed So if I understand correctly, you are saying: 1. All operations in UML should be defined with a signature that uses multiplicities, not Set(x) notation. 2. OCL itself does not distinguish between T[1] and T[0..1] 3. There should be an extra level of semantic checking when defining a UML operation in OCL, to both check that it is well-typed from an OCL point of view, and then check that the result is additionally well-typed with respect to the expected multiplicity of its value. That might work, but it seems like a hack. If OCL explicitly introduced nullable and non-nullable types, we could do a much cleaner match. -- Steve From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 28 October 2010 15:24 To: Steve Cook; uml2-rtf@omg.org; ocl2-rtf@omg.org Cc: issues@omg.org Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Steve . In UML, multiplicity is not actually part of the type. It is a separate constraint on cardinality of values. The real vagueness in UML semantics in this area is when this constraint actually has to hold. Now, OCL does not formally use the concept of multiplicity as such at all, but uses collections instead. In OCL 2.2 Subclause 7.5.1 it says .Whenever the multiplicity of an attribute is greater than 1, the result type is collection of values. (and there is a similar statement elsewhere about association ends). As I quoted previously, when the multiplicity upper bound is 1, the OCL type is not a collection, but a single value can always be treated as if it was a set of 1 member in OCL. As far as I understand the OCL semantics on this (though I have not tried to trace through to the formal semantics to confirm it), since single values can always be treated as sets of 1 member, OCL expressions can always be effectively thought of as operating on collections. Thus, declaring something to be Integer within an OCL expression (say in a .let. expression) is, indeed, equivalent to Integer[0..1] in UML. And an OCL expression of type Integer could end up returning an empty value in some cases. However, if an OCL expression of type Integer is used to compute the result of, say, an operation with return type and multiplicity Integer[1], then there is a UML constraint that a call to the operation must always return exactly one Integer value. Thus, whatever the OCL expression is, there is also an effective additional (UML imposed) constraint that .result->notEmpty().. If the given OCL expression for the result can possibly be empty, then the specification of the operation is just logically inconsistent, though syntactically correct in OCL. The real issue, I think, comes up in the context clause for an operation defined in a UML model, in which OCL types are used for the operation signature, but the real operation is as given in the UML model. The problem is that OCL cannot notate all UML multiplicities . collections always have an effective multiplicity of 0..* and non-collection types have an effective multiplicity of 0..1. Thus, there may be additional multiplicity constraints in the model that are not shown in the OCL text. (Alf, by the way, allows full UML multiplicity notation in operation signatures.) -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, October 28, 2010 9:59 AM To: Ed Seidewitz; uml2-rtf@omg.org; ocl2-rtf@omg.org Cc: issues@omg.org Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Ed >Isn.t it nice that now that we are all looking closely at UML semantics we have so many to choose from? Yes. Great. If OclVoid conforms to all types, so null is a valid member of any type, is there any difference between a UML property typed as Integer[1] and one typed as Integer[0..1]? Or do you see this as an explicit divergence between UML semantics and OCL semantics, where UML allows null to be a valid member of Integer[0..1] but not Integer[1]? If the latter, it.s a bit of a joke using OCL to define UML operations and constraints. -- Steve From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 28 October 2010 14:48 To: Steve Cook; uml2-rtf@omg.org; ocl2-rtf@omg.org Cc: issues@omg.org Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Steve . In the OCL 2.2 spec, Subclause 7.5.3, under .Navigation over Associations with Multiplicity Zero or One., it says: .Because the multiplicity of the role manager is one, self.manager is an object of type Person. Such a single object can be used as a Set as well. It then behaves as if it is a Set containing the single object. The usage as a set is done through the arrow followed by a property of Set.. While it doesn.t seem to say anything explicitly in the spec about non-association end properties with multiplicity 0..1, presumably the semantics are the same. That is, in the OCL type system, the type of such an association end is not explicit a collection, but a value of the association end may be treated in an expression as being a set with at most one member (so one can, e.g., check for emptiness using self.manager->isEmpty()), which is consistent with UML semantics. In OCL 2.2 Subclause 8.2, under .VoidType. it says: .VoidType represents a type that conforms to all types. The only instance of VoidType is OclVoid, which is further defined in the standard library. Furthermore OclVoid has exactly one instance called null - corresponding to the UML NullLiteral [sic] literal specification - and representing the absence of value. Note that in contrast with OclInvalid null is a valid value and as such can be owned by collections.. In the UML 2.3 spec, Subclause 7.3.28, it simply says that .A literal null specifies the lack of a value,. which is the vague semantics that is echoed above in the OCL spec. However, to OCL 2.2 spec further elaborates on OclVoid in Subclause 11.2.3, where it notes that: .However, by virtue of the implicit conversion to a collection literal, an expression evaluating to null can be used as source of collection operations (such as .isEmpty.). If the source is the null literal, it is implicitly converted to Bag{}.. Thus, the OclVoid instance .null. is a distinguished value in OCL semantics, it is effectively equivalent to Bag{} in usage. This seems consistent with the phrase .lack of a value. used in the UML spec, though OclVoid is itself only defined in the OCL spec (as are all OCL collection types, too, for that matter). Note also that, in fUML, a value specification action with a null literal produces a null token . a token that holds no values . when it fires, which is the activity semantics equivalent of the empty set or .lack of a value.. In Alf, the notation .null. is considered equivalent to .any[]{}., that is, an untyped empty sequence, which, as a sequence construction expression, has a special mapping to a value specification with a null literal, giving it the fUML semantics (as would be expected for Alf). Isn.t it nice that now that we are all looking closely at UML semantics we have so many to choose from? -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, October 28, 2010 8:43 AM To: uml2-rtf@omg.org; ocl2-rtf@omg.org Cc: issues@omg.org Subject: Vagueness about meaning of 0..1 multiplicity in OCL and UML In the UML spec especially around the area of MultiplicityElement and ValueSpecification there are numerous types for operation results declared as [Integer] etc. These are freely interpreted as being both sets and integers, both in the way they are used: lowerBound = if lowerValue->isEmpty() then 1 else lowerValue.integerValue() endif and in the way they are constructed: integerValue = Set{} This notation [Integer] appears to be a shorthand for either Set(Integer) or Integer[0..1]. In C# I would call this type Nullable or just int?; but I don.t believe that such a type formally exists in OCL. OCL has the value OclVoid, which is supposed to conform to all types. Is OclVoid semantically equivalent to Set{}? If OclVoid conforms to all types, is there any difference semantically between an attribute declared as multiplicity [1] and one declared as multiplicity [0..1]? If there is no difference, this seriously contradicts my expectations of what multiplicity means. -- Steve Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Date: Thu, 28 Oct 2010 16:46:11 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Vagueness about meaning of 0..1 multiplicity in OCL and UML Thread-Index: Act2nWG9nHt7ZdhnR6ep7Ws1giycVgABdsJAAAECqsAAAIKyAAAAaaGwAAA8CYAAAHoEwA== From: To: , , , Cc: X-OriginalArrivalTime: 28 Oct 2010 14:46:02.0358 (UTC) FILETIME=[D7971160:01CB76AE] Ed, I agree with your summary. -- Mariano -------------------------------------------------------------------------------- De : Ed Seidewitz [mailto:ed-s@modeldriven.com] Envoyé jeudi 28 octobre 2010 16:36 À: Steve Cook; BELAUNDE Mariano RD-MAPS-LAN; uml2-rtf@omg.org; ocl2-rtf@omg.org Cc : issues@omg.org Objet : RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Steve, Mariano . First of all, as noted in my previous message (which leapfrogged Mariano.s last one), neither .Integer[1]. not .Integer[0..1]. are actually types in either UML or OCL. In UML, multiplicity is not formally part of the type . it is an additional cardinality constraint given on multiplicity elements, and there are typed elements in UML that are not multiplicity elements (such as object nodes other than pins in activities). Multiplicity is not part of the OCL type system at all. In OCL, Integer and Set(Integer) are formally separate types. However, an expression of type Integer in OCL can be treated as a set of at most one member, so it.s effective type is essentially a constrained Set(Integer), equivalent to a type/multiplicity of Integer[0..1] in UML. However, as Mariano notes, having a multiplicity of 1 on an attribute places an additional constraint on that attribute . it must have a value. In an OCL expression of the form .x.a = y., where the attribute .a. has multiplicity 1, the OCL subexpression y may evaluate to a null value . but x.a can simply never equal such a value, since the UML model requires .a. it to have a value. Thus, in any well-formed instance of the UML model, the OCL equality must be false. Finally, I think the statement .OclVoid conforms to all types. is fine, within the context of OCL semantics. It is consistent with any OCL expression of any type effectively having, in UML terms, a multiplicity lower bound of 0 and the implicit conversion of a .null. value to .Bag{}.. -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, October 28, 2010 10:23 AM To: mariano.belaunde@orange-ftgroup.com; Ed Seidewitz; uml2-rtf@omg.org; ocl2-rtf@omg.org Cc: issues@omg.org Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Mariano, thanks. Are you asserting that Integer[1] and Integer[0..1] are distinct types in OCL? -- Steve From: mariano.belaunde@orange-ftgroup.com [mailto:mariano.belaunde@orange-ftgroup.com] Sent: 28 October 2010 15:17 To: Steve Cook; ed-s@modeldriven.com; uml2-rtf@omg.org; ocl2-rtf@omg.org Cc: issues@omg.org Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Steve, >>> is there any difference between a UML property typed as Integer[1] and one typed as Integer[0..1]? Yes there is an important difference. In the first case the attribute need to have a value, and this value need to be a Integer (null is not a valid value) In the second case it is valid not to provide a value for the attribute. In OCL navigating a attribute that has no assigned value results in a 'null' value, but this does not mean that the value of the attribute is null (the navigation expression is null, not the attribute value, which is simply not specified) . Regarding the exact meaning of statement "OclVoid conforms to all types", maybe this needs some clarification or revision. Mariano -------------------------------------------------------------------------------- De : Steve Cook [mailto:Steve.Cook@microsoft.com] Envoyé jeudi 28 octobre 2010 15:59 À: Ed Seidewitz; uml2-rtf@omg.org; ocl2-rtf@omg.org Cc : issues@omg.org Objet : RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Ed >Isn.t it nice that now that we are all looking closely at UML semantics we have so many to choose from? Yes. Great. If OclVoid conforms to all types, so null is a valid member of any type, is there any difference between a UML property typed as Integer[1] and one typed as Integer[0..1]? Or do you see this as an explicit divergence between UML semantics and OCL semantics, where UML allows null to be a valid member of Integer[0..1] but not Integer[1]? If the latter, it.s a bit of a joke using OCL to define UML operations and constraints. -- Steve From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 28 October 2010 14:48 To: Steve Cook; uml2-rtf@omg.org; ocl2-rtf@omg.org Cc: issues@omg.org Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Steve . In the OCL 2.2 spec, Subclause 7.5.3, under .Navigation over Associations with Multiplicity Zero or One., it says: .Because the multiplicity of the role manager is one, self.manager is an object of type Person. Such a single object can be used as a Set as well. It then behaves as if it is a Set containing the single object. The usage as a set is done through the arrow followed by a property of Set.. While it doesn.t seem to say anything explicitly in the spec about non-association end properties with multiplicity 0..1, presumably the semantics are the same. That is, in the OCL type system, the type of such an association end is not explicit a collection, but a value of the association end may be treated in an expression as being a set with at most one member (so one can, e.g., check for emptiness using self.manager->isEmpty()), which is consistent with UML semantics. In OCL 2.2 Subclause 8.2, under .VoidType. it says: .VoidType represents a type that conforms to all types. The only instance of VoidType is OclVoid, which is further defined in the standard library. Furthermore OclVoid has exactly one instance called null - corresponding to the UML NullLiteral [sic] literal specification - and representing the absence of value. Note that in contrast with OclInvalid null is a valid value and as such can be owned by collections.. In the UML 2.3 spec, Subclause 7.3.28, it simply says that .A literal null specifies the lack of a value,. which is the vague semantics that is echoed above in the OCL spec. However, to OCL 2.2 spec further elaborates on OclVoid in Subclause 11.2.3, where it notes that: .However, by virtue of the implicit conversion to a collection literal, an expression evaluating to null can be used as source of collection operations (such as .isEmpty.). If the source is the null literal, it is implicitly converted to Bag{}.. Thus, the OclVoid instance .null. is a distinguished value in OCL semantics, it is effectively equivalent to Bag{} in usage. This seems consistent with the phrase .lack of a value. used in the UML spec, though OclVoid is itself only defined in the OCL spec (as are all OCL collection types, too, for that matter). Note also that, in fUML, a value specification action with a null literal produces a null token . a token that holds no values . when it fires, which is the activity semantics equivalent of the empty set or .lack of a value.. In Alf, the notation .null. is considered equivalent to .any[]{}., that is, an untyped empty sequence, which, as a sequence construction expression, has a special mapping to a value specification with a null literal, giving it the fUML semantics (as would be expected for Alf). Isn.t it nice that now that we are all looking closely at UML semantics we have so many to choose from? -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, October 28, 2010 8:43 AM To: uml2-rtf@omg.org; ocl2-rtf@omg.org Cc: issues@omg.org Subject: Vagueness about meaning of 0..1 multiplicity in OCL and UML In the UML spec especially around the area of MultiplicityElement and ValueSpecification there are numerous types for operation results declared as [Integer] etc. These are freely interpreted as being both sets and integers, both in the way they are used: lowerBound = if lowerValue->isEmpty() then 1 else lowerValue.integerValue() endif and in the way they are constructed: integerValue = Set{} This notation [Integer] appears to be a shorthand for either Set(Integer) or Integer[0..1]. In C# I would call this type Nullable or just int?; but I don.t believe that such a type formally exists in OCL. OCL has the value OclVoid, which is supposed to conform to all types. Is OclVoid semantically equivalent to Set{}? If OclVoid conforms to all types, is there any difference semantically between an attribute declared as multiplicity [1] and one declared as multiplicity [0..1]? If there is no difference, this seriously contradicts my expectations of what multiplicity means. -- Steve From: "Willink, Ed" To: "'Steve Cook'" , Ed Seidewitz , uml2-rtf@omg.org, ocl2-rtf@omg.org Cc: issues@omg.org Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Date: Thu, 28 Oct 2010 15:55:02 +0100 X-Mailer: Internet Mail Service (5.5.2657.72) Hi Steve That all types (except OclInvalid) are nullable is pretty fundamental to OCL. I think a change here would be unwise. However this [0..1] discussion is very interesting. In a meta-model/signature clearly Integer[1] and Integer[0..1] clearly have precisely this non-nullable/nullable characteristic. So why doesn't OCL allow let x : Integer[1] in ... or let x : Integer[0..1] in ... [or some equivalent syntax] -- I've just been having exactly this problem with MOFM2T's [let] variable. And why is the Complete OCL Operation Context Declaration signature so different to UML in this respect? Perhaps OCL should further elaborate the original Set{1,2,3} which is evolving to allow Set(Integer){1,2,3} to also allow Set(Integer[3..3]){1,2,3} [I know the above example is redundant but it demonstrates the syntax enhancement]. Regards Ed Willink -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: 28 October 2010 15:35 To: Ed Seidewitz; uml2-rtf@omg.org; ocl2-rtf@omg.org Cc: issues@omg.org Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Ed So if I understand correctly, you are saying: 1. All operations in UML should be defined with a signature that uses multiplicities, not Set(x) notation. 2. OCL itself does not distinguish between T[1] and T[0..1] 3. There should be an extra level of semantic checking when defining a UML operation in OCL, to both check that it is well-typed from an OCL point of view, and then check that the result is additionally well-typed with respect to the expected multiplicity of its value. That might work, but it seems like a hack. If OCL explicitly introduced nullable and non-nullable types, we could do a much cleaner match. -- Steve From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 28 October 2010 15:24 To: Steve Cook; uml2-rtf@omg.org; ocl2-rtf@omg.org Cc: issues@omg.org Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Steve - In UML, multiplicity is not actually part of the type. It is a separate constraint on cardinality of values. The real vagueness in UML semantics in this area is when this constraint actually has to hold. Now, OCL does not formally use the concept of multiplicity as such at all, but uses collections instead. In OCL 2.2 Subclause 7.5.1 it says "Whenever the multiplicity of an attribute is greater than 1, the result type is collection of values" (and there is a similar statement elsewhere about association ends). As I quoted previously, when the multiplicity upper bound is 1, the OCL type is not a collection, but a single value can always be treated as if it was a set of 1 member in OCL. As far as I understand the OCL semantics on this (though I have not tried to trace through to the formal semantics to confirm it), since single values can always be treated as sets of 1 member, OCL expressions can always be effectively thought of as operating on collections. Thus, declaring something to be Integer within an OCL expression (say in a "let" expression) is, indeed, equivalent to Integer[0..1] in UML. And an OCL expression of type Integer could end up returning an empty value in some cases. However, if an OCL expression of type Integer is used to compute the result of, say, an operation with return type and multiplicity Integer[1], then there is a UML constraint that a call to the operation must always return exactly one Integer value. Thus, whatever the OCL expression is, there is also an effective additional (UML imposed) constraint that "result->notEmpty()". If the given OCL expression for the result can possibly be empty, then the specification of the operation is just logically inconsistent, though syntactically correct in OCL. The real issue, I think, comes up in the context clause for an operation defined in a UML model, in which OCL types are used for the operation signature, but the real operation is as given in the UML model. The problem is that OCL cannot notate all UML multiplicities - collections always have an effective multiplicity of 0..* and non-collection types have an effective multiplicity of 0..1. Thus, there may be additional multiplicity constraints in the model that are not shown in the OCL text. (Alf, by the way, allows full UML multiplicity notation in operation signatures.) -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, October 28, 2010 9:59 AM To: Ed Seidewitz; uml2-rtf@omg.org; ocl2-rtf@omg.org Cc: issues@omg.org Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Ed >Isn't it nice that now that we are all looking closely at UML semantics we have so many to choose from? Yes. Great. If OclVoid conforms to all types, so null is a valid member of any type, is there any difference between a UML property typed as Integer[1] and one typed as Integer[0..1]? Or do you see this as an explicit divergence between UML semantics and OCL semantics, where UML allows null to be a valid member of Integer[0..1] but not Integer[1]? If the latter, it's a bit of a joke using OCL to define UML operations and constraints. -- Steve From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 28 October 2010 14:48 To: Steve Cook; uml2-rtf@omg.org; ocl2-rtf@omg.org Cc: issues@omg.org Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Steve - In the OCL 2.2 spec, Subclause 7.5.3, under "Navigation over Associations with Multiplicity Zero or One", it says: "Because the multiplicity of the role manager is one, self.manager is an object of type Person. Such a single object can be used as a Set as well. It then behaves as if it is a Set containing the single object. The usage as a set is done through the arrow followed by a property of Set." While it doesn't seem to say anything explicitly in the spec about non-association end properties with multiplicity 0..1, presumably the semantics are the same. That is, in the OCL type system, the type of such an association end is not explicit a collection, but a value of the association end may be treated in an expression as being a set with at most one member (so one can, e.g., check for emptiness using self.manager->isEmpty()), which is consistent with UML semantics. In OCL 2.2 Subclause 8.2, under "VoidType" it says: "VoidType represents a type that conforms to all types. The only instance of VoidType is OclVoid, which is further defined in the standard library. Furthermore OclVoid has exactly one instance called null - corresponding to the UML NullLiteral [sic] literal specification - and representing the absence of value. Note that in contrast with OclInvalid null is a valid value and as such can be owned by collections." In the UML 2.3 spec, Subclause 7.3.28, it simply says that "A literal null specifies the lack of a value," which is the vague semantics that is echoed above in the OCL spec. However, to OCL 2.2 spec further elaborates on OclVoid in Subclause 11.2.3, where it notes that: "However, by virtue of the implicit conversion to a collection literal, an expression evaluating to null can be used as source of collection operations (such as 'isEmpty'). If the source is the null literal, it is implicitly converted to Bag{}." Thus, the OclVoid instance "null" is a distinguished value in OCL semantics, it is effectively equivalent to Bag{} in usage. This seems consistent with the phrase "lack of a value" used in the UML spec, though OclVoid is itself only defined in the OCL spec (as are all OCL collection types, too, for that matter). Note also that, in fUML, a value specification action with a null literal produces a null token - a token that holds no values - when it fires, which is the activity semantics equivalent of the empty set or "lack of a value". In Alf, the notation "null" is considered equivalent to "any[]{}", that is, an untyped empty sequence, which, as a sequence construction expression, has a special mapping to a value specification with a null literal, giving it the fUML semantics (as would be expected for Alf). Isn't it nice that now that we are all looking closely at UML semantics we have so many to choose from? -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, October 28, 2010 8:43 AM To: uml2-rtf@omg.org; ocl2-rtf@omg.org Cc: issues@omg.org Subject: Vagueness about meaning of 0..1 multiplicity in OCL and UML In the UML spec especially around the area of MultiplicityElement and ValueSpecification there are numerous types for operation results declared as [Integer] etc. These are freely interpreted as being both sets and integers, both in the way they are used: lowerBound = if lowerValue->isEmpty() then 1 else lowerValue.integerValue() endif and in the way they are constructed: integerValue = Set{} This notation [Integer] appears to be a shorthand for either Set(Integer) or Integer[0..1]. In C# I would call this type Nullable or just int?; but I don't believe that such a type formally exists in OCL. OCL has the value OclVoid, which is supposed to conform to all types. Is OclVoid semantically equivalent to Set{}? If OclVoid conforms to all types, is there any difference semantically between an attribute declared as multiplicity [1] and one declared as multiplicity [0..1]? If there is no difference, this seriously contradicts my expectations of what multiplicity means. -- Steve Please consider the environment before printing a hard copy of this e-mail. The information contained in this e-mail is confidential. It is intended only for the stated addressee(s) and access to it by any other person is unauthorised. If you are not an addressee, you must not disclose, copy, circulate or in any other way use or rely on the information contained in this e-mail. Such unauthorised use may be unlawful. If you have received this e-mail in error, please inform us immediately on +44 (0)118 986 8601 and delete it and all copies from your system. Thales Research and Technology (UK) Limited. A company registered in England and Wales. Registered Office: 2 Dashwood Lang Road, The Bourne Business Park, Addlestone, Weybridge, Surrey KT15 2NX. Registered Number: 774298 Thales UK Limited. A company registered in England and Wales. Registered Office: 2 Dashwood Lang Road, The Bourne Business Park, Addlestone, Weybridge, Surrey KT15 2NX. Registered Number: 868273 From: "Willink, Ed" To: "'Steve Cook'" , Ed Seidewitz , uml2-rtf@omg.org, ocl2-rtf@omg.org Cc: issues@omg.org Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Date: Thu, 28 Oct 2010 15:55:02 +0100 X-Mailer: Internet Mail Service (5.5.2657.72) Hi Steve That all types (except OclInvalid) are nullable is pretty fundamental to OCL. I think a change here would be unwise. However this [0..1] discussion is very interesting. In a meta-model/signature clearly Integer[1] and Integer[0..1] clearly have precisely this non-nullable/nullable characteristic. So why doesn't OCL allow let x : Integer[1] in ... or let x : Integer[0..1] in ... [or some equivalent syntax] -- I've just been having exactly this problem with MOFM2T's [let] variable. And why is the Complete OCL Operation Context Declaration signature so different to UML in this respect? Perhaps OCL should further elaborate the original Set{1,2,3} which is evolving to allow Set(Integer){1,2,3} to also allow Set(Integer[3..3]){1,2,3} [I know the above example is redundant but it demonstrates the syntax enhancement]. Regards Ed Willink -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: 28 October 2010 15:35 To: Ed Seidewitz; uml2-rtf@omg.org; ocl2-rtf@omg.org Cc: issues@omg.org Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Ed So if I understand correctly, you are saying: 1. All operations in UML should be defined with a signature that uses multiplicities, not Set(x) notation. 2. OCL itself does not distinguish between T[1] and T[0..1] 3. There should be an extra level of semantic checking when defining a UML operation in OCL, to both check that it is well-typed from an OCL point of view, and then check that the result is additionally well-typed with respect to the expected multiplicity of its value. That might work, but it seems like a hack. If OCL explicitly introduced nullable and non-nullable types, we could do a much cleaner match. -- Steve From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 28 October 2010 15:24 To: Steve Cook; uml2-rtf@omg.org; ocl2-rtf@omg.org Cc: issues@omg.org Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Steve - In UML, multiplicity is not actually part of the type. It is a separate constraint on cardinality of values. The real vagueness in UML semantics in this area is when this constraint actually has to hold. Now, OCL does not formally use the concept of multiplicity as such at all, but uses collections instead. In OCL 2.2 Subclause 7.5.1 it says "Whenever the multiplicity of an attribute is greater than 1, the result type is collection of values" (and there is a similar statement elsewhere about association ends). As I quoted previously, when the multiplicity upper bound is 1, the OCL type is not a collection, but a single value can always be treated as if it was a set of 1 member in OCL. As far as I understand the OCL semantics on this (though I have not tried to trace through to the formal semantics to confirm it), since single values can always be treated as sets of 1 member, OCL expressions can always be effectively thought of as operating on collections. Thus, declaring something to be Integer within an OCL expression (say in a "let" expression) is, indeed, equivalent to Integer[0..1] in UML. And an OCL expression of type Integer could end up returning an empty value in some cases. However, if an OCL expression of type Integer is used to compute the result of, say, an operation with return type and multiplicity Integer[1], then there is a UML constraint that a call to the operation must always return exactly one Integer value. Thus, whatever the OCL expression is, there is also an effective additional (UML imposed) constraint that "result->notEmpty()". If the given OCL expression for the result can possibly be empty, then the specification of the operation is just logically inconsistent, though syntactically correct in OCL. The real issue, I think, comes up in the context clause for an operation defined in a UML model, in which OCL types are used for the operation signature, but the real operation is as given in the UML model. The problem is that OCL cannot notate all UML multiplicities - collections always have an effective multiplicity of 0..* and non-collection types have an effective multiplicity of 0..1. Thus, there may be additional multiplicity constraints in the model that are not shown in the OCL text. (Alf, by the way, allows full UML multiplicity notation in operation signatures.) -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, October 28, 2010 9:59 AM To: Ed Seidewitz; uml2-rtf@omg.org; ocl2-rtf@omg.org Cc: issues@omg.org Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Ed >Isn't it nice that now that we are all looking closely at UML semantics we have so many to choose from? Yes. Great. If OclVoid conforms to all types, so null is a valid member of any type, is there any difference between a UML property typed as Integer[1] and one typed as Integer[0..1]? Or do you see this as an explicit divergence between UML semantics and OCL semantics, where UML allows null to be a valid member of Integer[0..1] but not Integer[1]? If the latter, it's a bit of a joke using OCL to define UML operations and constraints. -- Steve From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 28 October 2010 14:48 To: Steve Cook; uml2-rtf@omg.org; ocl2-rtf@omg.org Cc: issues@omg.org Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Steve - In the OCL 2.2 spec, Subclause 7.5.3, under "Navigation over Associations with Multiplicity Zero or One", it says: "Because the multiplicity of the role manager is one, self.manager is an object of type Person. Such a single object can be used as a Set as well. It then behaves as if it is a Set containing the single object. The usage as a set is done through the arrow followed by a property of Set." While it doesn't seem to say anything explicitly in the spec about non-association end properties with multiplicity 0..1, presumably the semantics are the same. That is, in the OCL type system, the type of such an association end is not explicit a collection, but a value of the association end may be treated in an expression as being a set with at most one member (so one can, e.g., check for emptiness using self.manager->isEmpty()), which is consistent with UML semantics. In OCL 2.2 Subclause 8.2, under "VoidType" it says: "VoidType represents a type that conforms to all types. The only instance of VoidType is OclVoid, which is further defined in the standard library. Furthermore OclVoid has exactly one instance called null - corresponding to the UML NullLiteral [sic] literal specification - and representing the absence of value. Note that in contrast with OclInvalid null is a valid value and as such can be owned by collections." In the UML 2.3 spec, Subclause 7.3.28, it simply says that "A literal null specifies the lack of a value," which is the vague semantics that is echoed above in the OCL spec. However, to OCL 2.2 spec further elaborates on OclVoid in Subclause 11.2.3, where it notes that: "However, by virtue of the implicit conversion to a collection literal, an expression evaluating to null can be used as source of collection operations (such as 'isEmpty'). If the source is the null literal, it is implicitly converted to Bag{}." Thus, the OclVoid instance "null" is a distinguished value in OCL semantics, it is effectively equivalent to Bag{} in usage. This seems consistent with the phrase "lack of a value" used in the UML spec, though OclVoid is itself only defined in the OCL spec (as are all OCL collection types, too, for that matter). Note also that, in fUML, a value specification action with a null literal produces a null token - a token that holds no values - when it fires, which is the activity semantics equivalent of the empty set or "lack of a value". In Alf, the notation "null" is considered equivalent to "any[]{}", that is, an untyped empty sequence, which, as a sequence construction expression, has a special mapping to a value specification with a null literal, giving it the fUML semantics (as would be expected for Alf). Isn't it nice that now that we are all looking closely at UML semantics we have so many to choose from? -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, October 28, 2010 8:43 AM To: uml2-rtf@omg.org; ocl2-rtf@omg.org Cc: issues@omg.org Subject: Vagueness about meaning of 0..1 multiplicity in OCL and UML In the UML spec especially around the area of MultiplicityElement and ValueSpecification there are numerous types for operation results declared as [Integer] etc. These are freely interpreted as being both sets and integers, both in the way they are used: lowerBound = if lowerValue->isEmpty() then 1 else lowerValue.integerValue() endif and in the way they are constructed: integerValue = Set{} This notation [Integer] appears to be a shorthand for either Set(Integer) or Integer[0..1]. In C# I would call this type Nullable or just int?; but I don't believe that such a type formally exists in OCL. OCL has the value OclVoid, which is supposed to conform to all types. Is OclVoid semantically equivalent to Set{}? If OclVoid conforms to all types, is there any difference semantically between an attribute declared as multiplicity [1] and one declared as multiplicity [0..1]? If there is no difference, this seriously contradicts my expectations of what multiplicity means. -- Steve Please consider the environment before printing a hard copy of this e-mail. The information contained in this e-mail is confidential. It is intended only for the stated addressee(s) and access to it by any other person is unauthorised. If you are not an addressee, you must not disclose, copy, circulate or in any other way use or rely on the information contained in this e-mail. Such unauthorised use may be unlawful. If you have received this e-mail in error, please inform us immediately on +44 (0)118 986 8601 and delete it and all copies from your system. Thales Research and Technology (UK) Limited. A company registered in England and Wales. Registered Office: 2 Dashwood Lang Road, The Bourne Business Park, Addlestone, Weybridge, Surrey KT15 2NX. Registered Number: 774298 Thales UK Limited. A company registered in England and Wales. Registered Office: 2 Dashwood Lang Road, The Bourne Business Park, Addlestone, Weybridge, Surrey KT15 2NX. Registered Number: 868273 From: Steve Cook To: "Willink, Ed" , Ed Seidewitz , "uml2-rtf@omg.org" , "ocl2-rtf@omg.org" CC: "issues@omg.org" Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Thread-Topic: Vagueness about meaning of 0..1 multiplicity in OCL and UML Thread-Index: AQHLdrAZnHt7ZdhnR6ep7Ws1giycVpNWc2mw Date: Thu, 28 Oct 2010 14:58:33 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.20.35] Hi Ed Exactly! -- Steve From: Willink, Ed [mailto:Ed.Willink@thalesgroup.com] Sent: 28 October 2010 15:55 To: Steve Cook; Ed Seidewitz; uml2-rtf@omg.org; ocl2-rtf@omg.org Cc: issues@omg.org Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Hi Steve That all types (except OclInvalid) are nullable is pretty fundamental to OCL. I think a change here would be unwise. However this [0..1] discussion is very interesting. In a meta-model/signature clearly Integer[1] and Integer[0..1] clearly have precisely this non-nullable/nullable characteristic. So why doesn't OCL allow let x : Integer[1] in ... or let x : Integer[0..1] in ... [or some equivalent syntax] -- I've just been having exactly this problem with MOFM2T's [let] variable. And why is the Complete OCL Operation Context Declaration signature so different to UML in this respect? Perhaps OCL should further elaborate the original Set{1,2,3} which is evolving to allow Set(Integer){1,2,3} to also allow Set(Integer[3..3]){1,2,3} [I know the above example is redundant but it demonstrates the syntax enhancement]. Regards Ed Willink -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: 28 October 2010 15:35 To: Ed Seidewitz; uml2-rtf@omg.org; ocl2-rtf@omg.org Cc: issues@omg.org Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Ed So if I understand correctly, you are saying: 1. All operations in UML should be defined with a signature that uses multiplicities, not Set(x) notation. 2. OCL itself does not distinguish between T[1] and T[0..1] 3. There should be an extra level of semantic checking when defining a UML operation in OCL, to both check that it is well-typed from an OCL point of view, and then check that the result is additionally well-typed with respect to the expected multiplicity of its value. That might work, but it seems like a hack. If OCL explicitly introduced nullable and non-nullable types, we could do a much cleaner match. -- Steve From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 28 October 2010 15:24 To: Steve Cook; uml2-rtf@omg.org; ocl2-rtf@omg.org Cc: issues@omg.org Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Steve - In UML, multiplicity is not actually part of the type. It is a separate constraint on cardinality of values. The real vagueness in UML semantics in this area is when this constraint actually has to hold. Now, OCL does not formally use the concept of multiplicity as such at all, but uses collections instead. In OCL 2.2 Subclause 7.5.1 it says "Whenever the multiplicity of an attribute is greater than 1, the result type is collection of values" (and there is a similar statement elsewhere about association ends). As I quoted previously, when the multiplicity upper bound is 1, the OCL type is not a collection, but a single value can always be treated as if it was a set of 1 member in OCL. As far as I understand the OCL semantics on this (though I have not tried to trace through to the formal semantics to confirm it), since single values can always be treated as sets of 1 member, OCL expressions can always be effectively thought of as operating on collections. Thus, declaring something to be Integer within an OCL expression (say in a "let" expression) is, indeed, equivalent to Integer[0..1] in UML. And an OCL expression of type Integer could end up returning an empty value in some cases. However, if an OCL expression of type Integer is used to compute the result of, say, an operation with return type and multiplicity Integer[1], then there is a UML constraint that a call to the operation must always return exactly one Integer value. Thus, whatever the OCL expression is, there is also an effective additional (UML imposed) constraint that "result->notEmpty()". If the given OCL expression for the result can possibly be empty, then the specification of the operation is just logically inconsistent, though syntactically correct in OCL. The real issue, I think, comes up in the context clause for an operation defined in a UML model, in which OCL types are used for the operation signature, but the real operation is as given in the UML model. The problem is that OCL cannot notate all UML multiplicities - collections always have an effective multiplicity of 0..* and non-collection types have an effective multiplicity of 0..1. Thus, there may be additional multiplicity constraints in the model that are not shown in the OCL text. (Alf, by the way, allows full UML multiplicity notation in operation signatures.) -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, October 28, 2010 9:59 AM To: Ed Seidewitz; uml2-rtf@omg.org; ocl2-rtf@omg.org Cc: issues@omg.org Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Ed >Isn't it nice that now that we are all looking closely at UML semantics we have so many to choose from? Yes. Great. If OclVoid conforms to all types, so null is a valid member of any type, is there any difference between a UML property typed as Integer[1] and one typed as Integer[0..1]? Or do you see this as an explicit divergence between UML semantics and OCL semantics, where UML allows null to be a valid member of Integer[0..1] but not Integer[1]? If the latter, it's a bit of a joke using OCL to define UML operations and constraints. -- Steve From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 28 October 2010 14:48 To: Steve Cook; uml2-rtf@omg.org; ocl2-rtf@omg.org Cc: issues@omg.org Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Steve - In the OCL 2.2 spec, Subclause 7.5.3, under "Navigation over Associations with Multiplicity Zero or One", it says: "Because the multiplicity of the role manager is one, self.manager is an object of type Person. Such a single object can be used as a Set as well. It then behaves as if it is a Set containing the single object. The usage as a set is done through the arrow followed by a property of Set." While it doesn't seem to say anything explicitly in the spec about non-association end properties with multiplicity 0..1, presumably the semantics are the same. That is, in the OCL type system, the type of such an association end is not explicit a collection, but a value of the association end may be treated in an expression as being a set with at most one member (so one can, e.g., check for emptiness using self.manager->isEmpty()), which is consistent with UML semantics. In OCL 2.2 Subclause 8.2, under "VoidType" it says: "VoidType represents a type that conforms to all types. The only instance of VoidType is OclVoid, which is further defined in the standard library. Furthermore OclVoid has exactly one instance called null - corresponding to the UML NullLiteral [sic] literal specification - and representing the absence of value. Note that in contrast with OclInvalid null is a valid value and as such can be owned by collections." In the UML 2.3 spec, Subclause 7.3.28, it simply says that "A literal null specifies the lack of a value," which is the vague semantics that is echoed above in the OCL spec. However, to OCL 2.2 spec further elaborates on OclVoid in Subclause 11.2.3, where it notes that: "However, by virtue of the implicit conversion to a collection literal, an expression evaluating to null can be used as source of collection operations (such as 'isEmpty'). If the source is the null literal, it is implicitly converted to Bag{}." Thus, the OclVoid instance "null" is a distinguished value in OCL semantics, it is effectively equivalent to Bag{} in usage. This seems consistent with the phrase "lack of a value" used in the UML spec, though OclVoid is itself only defined in the OCL spec (as are all OCL collection types, too, for that matter). Note also that, in fUML, a value specification action with a null literal produces a null token - a token that holds no values - when it fires, which is the activity semantics equivalent of the empty set or "lack of a value". In Alf, the notation "null" is considered equivalent to "any[]{}", that is, an untyped empty sequence, which, as a sequence construction expression, has a special mapping to a value specification with a null literal, giving it the fUML semantics (as would be expected for Alf). Isn't it nice that now that we are all looking closely at UML semantics we have so many to choose from? -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, October 28, 2010 8:43 AM To: uml2-rtf@omg.org; ocl2-rtf@omg.org Cc: issues@omg.org Subject: Vagueness about meaning of 0..1 multiplicity in OCL and UML In the UML spec especially around the area of MultiplicityElement and ValueSpecification there are numerous types for operation results declared as [Integer] etc. These are freely interpreted as being both sets and integers, both in the way they are used: lowerBound = if lowerValue->isEmpty() then 1 else lowerValue.integerValue() endif and in the way they are constructed: integerValue = Set{} This notation [Integer] appears to be a shorthand for either Set(Integer) or Integer[0..1]. In C# I would call this type Nullable or just int?; but I don't believe that such a type formally exists in OCL. OCL has the value OclVoid, which is supposed to conform to all types. Is OclVoid semantically equivalent to Set{}? If OclVoid conforms to all types, is there any difference semantically between an attribute declared as multiplicity [1] and one declared as multiplicity [0..1]? If there is no difference, this seriously contradicts my expectations of what multiplicity means. -- Steve Please consider the environment before printing a hard copy of this e-mail. The information contained in this e-mail is confidential. It is intended only for the stated addressee(s) and access to it by any other person is unauthorised. If you are not an addressee, you must not disclose, copy, circulate or in any other way use or rely on the information contained in this e-mail. Such unauthorised use may be unlawful. If you have received this e-mail in error, please inform us immediately on +44 (0)118 986 8601 and delete it and all copies from your system. Thales Research and Technology (UK) Limited. A company registered in England and Wales. Registered Office: 2 Dashwood Lang Road, The Bourne Business Park, Addlestone, Weybridge, Surrey KT15 2NX. Registered Number: 774298 Thales UK Limited. A company registered in England and Wales. Registered Office: 2 Dashwood Lang Road, The Bourne Business Park, Addlestone, Weybridge, Surrey KT15 2NX. Registered Number: 868273 From: "Willink, Ed" To: "'Juergen Boldt'" , issues@omg.org, ocl2-rtf@omg.org Cc: uml2-rtf@omg.org Subject: RE: issue 15789 -- OCL 2 RTF issue Date: Thu, 28 Oct 2010 16:07:32 +0100 X-Mailer: Internet Mail Service (5.5.2657.72) Hi Juergen There is definitely an OCL issue. Please use the following as the formal summary of Issue 15789 ---------------------------------------- UML-alignment of OCL type signatures -------------------------------------------------------- Following discussion in the "Vagueness about meaning of 0..1 multiplicity in OCL and UML" threads of the UML2 and OCL RTFs the following problems exist in alignment of the UML and OCL type systems. The OCL specification does not provide a clear description of the comparative semantics of for instance Integer[1] and Integer[0..1]. The Complete OCL syntax for an Operation Context Declaration uses OCL type decalarations and so fails to provide the same expressivity as a UML operation declaration with multiplicities. Suggest: a) a clear indication that An Integer[1] may have integer values, null or invalid, of which only integer values are well-formed. An Integer[0..1] may have integer values, null or invalid, of which integer values and null are well-formed. b) an enhancement to the type declaration syntax to allow Integer[0..1] or Integer[1] to indicate a nullable/non-nullable value. Set(Integer[1..7]) to capture the expressivity of a UML multiplicity. Ed -------------------------------------------------------------------------------- From: Juergen Boldt [mailto:juergen@omg.org] Sent: 28 October 2010 15:34 To: issues@omg.org; ocl2-rtf@omg.org Cc: uml2-rtf@omg.org Subject: issue 15789 -- OCL 2 RTF issue From: Steve Cook To: "uml2-rtf@omg.org" , "ocl2-rtf@omg.org" CC: "issues@omg.org" Subject: Vagueness about meaning of 0..1 multiplicity in OCL and UML Thread-Topic: Vagueness about meaning of 0..1 multiplicity in OCL and UML Thread-Index: Act2nWG9nHt7ZdhnR6ep7Ws1giycVg== Date: Thu, 28 Oct 2010 12:42:58 +0000 Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.20.35] In the UML spec especially around the area of MultiplicityElement and ValueSpecification there are numerous types for operation results declared as [Integer] etc. These are freely interpreted as being both sets and integers, both in the way they are used: lowerBound = if lowerValue->isEmpty() then 1 else lowerValue.integerValue() endif and in the way they are constructed: integerValue = Set{} This notation [Integer] appears to be a shorthand for either Set(Integer) or Integer[0..1]. In C# I would call this type Nullable or just int?; but I don't believe that such a type formally exists in OCL. OCL has the value OclVoid, which is supposed to conform to all types. Is OclVoid semantically equivalent to Set{}? If OclVoid conforms to all types, is there any difference semantically between an attribute declared as multiplicity [1] and one declared as multiplicity [0..1]? If there is no difference, this seriously contradicts my expectations of what multiplicity means. -- Steve Juergen Boldt Director, Member Services Object Management Group 140 Kendrick St Building A Suite 300 Needham, MA 02494 USA tel: +1 781 444 0404 x 132 fax: +1 781 444 0320 email: juergen@omg.org www.omg.org Please consider the environment before printing a hard copy of this e-mail. The information contained in this e-mail is confidential. It is intended only for the stated addressee(s) and access to it by any other person is unauthorised. If you are not an addressee, you must not disclose, copy, circulate or in any other way use or rely on the information contained in this e-mail. Such unauthorised use may be unlawful. If you have received this e-mail in error, please inform us immediately on +44 (0)118 986 8601 and delete it and all copies from your system. Thales Research and Technology (UK) Limited. A company registered in England and Wales. Registered Office: 2 Dashwood Lang Road, The Bourne Business Park, Addlestone, Weybridge, Surrey KT15 2NX. Registered Number: 774298 Thales UK Limited. A company registered in England and Wales. Registered Office: 2 Dashwood Lang Road, The Bourne Business Park, Addlestone, Weybridge, Surrey KT15 2NX. Registered Number: 868273 Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Date: Thu, 28 Oct 2010 11:10:15 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Vagueness about meaning of 0..1 multiplicity in OCL and UML Thread-Index: Act2sCjIBzW2ItqbTs69DTnIJBgTegAAICFw From: "Ed Seidewitz" To: "Willink, Ed" , "Steve Cook" , , Cc: Ed . The question is, where would such multiplicity constraints be enforced? Since OCL is an expression language, you are always, e.g., combining one set with another, not changing a set value in place. So what does it mean to construct a set in OCL with multiplicity bounds, other than what are already given by the number of explicitly listed values? Further, in a let clause, you always have to give an expression for each of the variables. So something like let x: Integer[1] = e in . would simply be a declaration that e cannot be null. I suppose that if, when evaluated, e did turn out to be null, then x would get an invalid value. Allowing such a declaration in a let expression might be useful, but probably only marginally so, in my opinion. So, again, the real issue is the boundary between the OCL type system and the UML type system, which basically comes down to the typing of parameters and properties. The multiplicities for these in the UML model then have a fairly clear semantics . they are extra constraints on the cardinality of the values that can be held by those variables. Since one must be cognizant of such multiplicity constraints when writing further related conditions in OCL, I think it would be very useful to allow full UML multiplicity notation for them OCL context clauses, with the appropriate implicit constraint semantics for them then carried into OCL. Given this additional information at the boundary of OCL and UML, it might actually be possible in some cases to statically detect potential multiplicity conformance errors in OCL expressions that reference parameters and properties. Though, of course, this would not always be statically determinable. -- Ed -------------------------------------------------------------------------------- From: Willink, Ed [mailto:Ed.Willink@thalesgroup.com] Sent: Thursday, October 28, 2010 10:55 AM To: 'Steve Cook'; Ed Seidewitz; uml2-rtf@omg.org; ocl2-rtf@omg.org Cc: issues@omg.org Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Hi Steve That all types (except OclInvalid) are nullable is pretty fundamental to OCL. I think a change here would be unwise. However this [0..1] discussion is very interesting. In a meta-model/signature clearly Integer[1] and Integer[0..1] clearly have precisely this non-nullable/nullable characteristic. So why doesn't OCL allow let x : Integer[1] in ... or let x : Integer[0..1] in ... [or some equivalent syntax] -- I've just been having exactly this problem with MOFM2T's [let] variable. And why is the Complete OCL Operation Context Declaration signature so different to UML in this respect? Perhaps OCL should further elaborate the original Set{1,2,3} which is evolving to allow Set(Integer){1,2,3} to also allow Set(Integer[3..3]){1,2,3} [I know the above example is redundant but it demonstrates the syntax enhancement]. Regards Ed Willink -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: 28 October 2010 15:35 To: Ed Seidewitz; uml2-rtf@omg.org; ocl2-rtf@omg.org Cc: issues@omg.org Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Ed So if I understand correctly, you are saying: 1. All operations in UML should be defined with a signature that uses multiplicities, not Set(x) notation. 2. OCL itself does not distinguish between T[1] and T[0..1] 3. There should be an extra level of semantic checking when defining a UML operation in OCL, to both check that it is well-typed from an OCL point of view, and then check that the result is additionally well-typed with respect to the expected multiplicity of its value. That might work, but it seems like a hack. If OCL explicitly introduced nullable and non-nullable types, we could do a much cleaner match. -- Steve From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 28 October 2010 15:24 To: Steve Cook; uml2-rtf@omg.org; ocl2-rtf@omg.org Cc: issues@omg.org Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Steve - In UML, multiplicity is not actually part of the type. It is a separate constraint on cardinality of values. The real vagueness in UML semantics in this area is when this constraint actually has to hold. Now, OCL does not formally use the concept of multiplicity as such at all, but uses collections instead. In OCL 2.2 Subclause 7.5.1 it says "Whenever the multiplicity of an attribute is greater than 1, the result type is collection of values" (and there is a similar statement elsewhere about association ends). As I quoted previously, when the multiplicity upper bound is 1, the OCL type is not a collection, but a single value can always be treated as if it was a set of 1 member in OCL. As far as I understand the OCL semantics on this (though I have not tried to trace through to the formal semantics to confirm it), since single values can always be treated as sets of 1 member, OCL expressions can always be effectively thought of as operating on collections. Thus, declaring something to be Integer within an OCL expression (say in a "let" expression) is, indeed, equivalent to Integer[0..1] in UML. And an OCL expression of type Integer could end up returning an empty value in some cases. However, if an OCL expression of type Integer is used to compute the result of, say, an operation with return type and multiplicity Integer[1], then there is a UML constraint that a call to the operation must always return exactly one Integer value. Thus, whatever the OCL expression is, there is also an effective additional (UML imposed) constraint that "result->notEmpty()". If the given OCL expression for the result can possibly be empty, then the specification of the operation is just logically inconsistent, though syntactically correct in OCL. The real issue, I think, comes up in the context clause for an operation defined in a UML model, in which OCL types are used for the operation signature, but the real operation is as given in the UML model. The problem is that OCL cannot notate all UML multiplicities - collections always have an effective multiplicity of 0..* and non-collection types have an effective multiplicity of 0..1. Thus, there may be additional multiplicity constraints in the model that are not shown in the OCL text. (Alf, by the way, allows full UML multiplicity notation in operation signatures.) -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, October 28, 2010 9:59 AM To: Ed Seidewitz; uml2-rtf@omg.org; ocl2-rtf@omg.org Cc: issues@omg.org Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Ed >Isn't it nice that now that we are all looking closely at UML semantics we have so many to choose from? Yes. Great. If OclVoid conforms to all types, so null is a valid member of any type, is there any difference between a UML property typed as Integer[1] and one typed as Integer[0..1]? Or do you see this as an explicit divergence between UML semantics and OCL semantics, where UML allows null to be a valid member of Integer[0..1] but not Integer[1]? If the latter, it's a bit of a joke using OCL to define UML operations and constraints. -- Steve From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 28 October 2010 14:48 To: Steve Cook; uml2-rtf@omg.org; ocl2-rtf@omg.org Cc: issues@omg.org Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Steve - In the OCL 2.2 spec, Subclause 7.5.3, under "Navigation over Associations with Multiplicity Zero or One", it says: "Because the multiplicity of the role manager is one, self.manager is an object of type Person. Such a single object can be used as a Set as well. It then behaves as if it is a Set containing the single object. The usage as a set is done through the arrow followed by a property of Set." While it doesn't seem to say anything explicitly in the spec about non-association end properties with multiplicity 0..1, presumably the semantics are the same. That is, in the OCL type system, the type of such an association end is not explicit a collection, but a value of the association end may be treated in an expression as being a set with at most one member (so one can, e.g., check for emptiness using self.manager->isEmpty()), which is consistent with UML semantics. In OCL 2.2 Subclause 8.2, under "VoidType" it says: "VoidType represents a type that conforms to all types. The only instance of VoidType is OclVoid, which is further defined in the standard library. Furthermore OclVoid has exactly one instance called null - corresponding to the UML NullLiteral [sic] literal specification - and representing the absence of value. Note that in contrast with OclInvalid null is a valid value and as such can be owned by collections." In the UML 2.3 spec, Subclause 7.3.28, it simply says that "A literal null specifies the lack of a value," which is the vague semantics that is echoed above in the OCL spec. However, to OCL 2.2 spec further elaborates on OclVoid in Subclause 11.2.3, where it notes that: "However, by virtue of the implicit conversion to a collection literal, an expression evaluating to null can be used as source of collection operations (such as 'isEmpty'). If the source is the null literal, it is implicitly converted to Bag{}." Thus, the OclVoid instance "null" is a distinguished value in OCL semantics, it is effectively equivalent to Bag{} in usage. This seems consistent with the phrase "lack of a value" used in the UML spec, though OclVoid is itself only defined in the OCL spec (as are all OCL collection types, too, for that matter). Note also that, in fUML, a value specification action with a null literal produces a null token - a token that holds no values - when it fires, which is the activity semantics equivalent of the empty set or "lack of a value". In Alf, the notation "null" is considered equivalent to "any[]{}", that is, an untyped empty sequence, which, as a sequence construction expression, has a special mapping to a value specification with a null literal, giving it the fUML semantics (as would be expected for Alf). Isn't it nice that now that we are all looking closely at UML semantics we have so many to choose from? -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, October 28, 2010 8:43 AM To: uml2-rtf@omg.org; ocl2-rtf@omg.org Cc: issues@omg.org Subject: Vagueness about meaning of 0..1 multiplicity in OCL and UML In the UML spec especially around the area of MultiplicityElement and ValueSpecification there are numerous types for operation results declared as [Integer] etc. These are freely interpreted as being both sets and integers, both in the way they are used: lowerBound = if lowerValue->isEmpty() then 1 else lowerValue.integerValue() endif and in the way they are constructed: integerValue = Set{} This notation [Integer] appears to be a shorthand for either Set(Integer) or Integer[0..1]. In C# I would call this type Nullable or just int?; but I don't believe that such a type formally exists in OCL. OCL has the value OclVoid, which is supposed to conform to all types. Is OclVoid semantically equivalent to Set{}? If OclVoid conforms to all types, is there any difference semantically between an attribute declared as multiplicity [1] and one declared as multiplicity [0..1]? If there is no difference, this seriously contradicts my expectations of what multiplicity means. -- Steve Please consider the environment before printing a hard copy of this e-mail. The information contained in this e-mail is confidential. It is intended only for the stated addressee(s) and access to it by any other person is unauthorised. If you are not an addressee, you must not disclose, copy, circulate or in any other way use or rely on the information contained in this e-mail. Such unauthorised use may be unlawful. If you have received this e-mail in error, please inform us immediately on +44 (0)118 986 8601 and delete it and all copies from your system. Thales Research and Technology (UK) Limited. A company registered in England and Wales. Registered Office: 2 Dashwood Lang Road, The Bourne Business Park, Addlestone, Weybridge, Surrey KT15 2NX. Registered Number: 774298 Thales UK Limited. A company registered in England and Wales. Registered Office: 2 Dashwood Lang Road, The Bourne Business Park, Addlestone, Weybridge, Surrey KT15 2NX. Registered Number: 868273 Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Date: Thu, 28 Oct 2010 16:55:08 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Vagueness about meaning of 0..1 multiplicity in OCL and UML Thread-Index: Act2nWG9nHt7ZdhnR6ep7Ws1giycVgABdsJAAAECqsAAAHiYsAAAwygwAACzIsA= From: To: , , , Cc: X-OriginalArrivalTime: 28 Oct 2010 14:54:58.0502 (UTC) FILETIME=[17282660:01CB76B0] >>> If OCL explicitly introduced nullable and non-nullable types, we could do a much cleaner match I think the decision to interpret multiplicity as part of the type information (rather than as a complementary information) need to be taken first in UML/MOF specs. If this is done, the OCL spec will follow, I guess. Mariano -------------------------------------------------------------------------------- De : Steve Cook [mailto:Steve.Cook@microsoft.com] Envoyé jeudi 28 octobre 2010 16:35 À: Ed Seidewitz; uml2-rtf@omg.org; ocl2-rtf@omg.org Cc : issues@omg.org Objet : RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Ed So if I understand correctly, you are saying: 1. All operations in UML should be defined with a signature that uses multiplicities, not Set(x) notation. 2. OCL itself does not distinguish between T[1] and T[0..1] 3. There should be an extra level of semantic checking when defining a UML operation in OCL, to both check that it is well-typed from an OCL point of view, and then check that the result is additionally well-typed with respect to the expected multiplicity of its value. That might work, but it seems like a hack. If OCL explicitly introduced nullable and non-nullable types, we could do a much cleaner match. -- Steve From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 28 October 2010 15:24 To: Steve Cook; uml2-rtf@omg.org; ocl2-rtf@omg.org Cc: issues@omg.org Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Steve . In UML, multiplicity is not actually part of the type. It is a separate constraint on cardinality of values. The real vagueness in UML semantics in this area is when this constraint actually has to hold. Now, OCL does not formally use the concept of multiplicity as such at all, but uses collections instead. In OCL 2.2 Subclause 7.5.1 it says .Whenever the multiplicity of an attribute is greater than 1, the result type is collection of values. (and there is a similar statement elsewhere about association ends). As I quoted previously, when the multiplicity upper bound is 1, the OCL type is not a collection, but a single value can always be treated as if it was a set of 1 member in OCL. As far as I understand the OCL semantics on this (though I have not tried to trace through to the formal semantics to confirm it), since single values can always be treated as sets of 1 member, OCL expressions can always be effectively thought of as operating on collections. Thus, declaring something to be Integer within an OCL expression (say in a .let. expression) is, indeed, equivalent to Integer[0..1] in UML. And an OCL expression of type Integer could end up returning an empty value in some cases. However, if an OCL expression of type Integer is used to compute the result of, say, an operation with return type and multiplicity Integer[1], then there is a UML constraint that a call to the operation must always return exactly one Integer value. Thus, whatever the OCL expression is, there is also an effective additional (UML imposed) constraint that .result->notEmpty().. If the given OCL expression for the result can possibly be empty, then the specification of the operation is just logically inconsistent, though syntactically correct in OCL. The real issue, I think, comes up in the context clause for an operation defined in a UML model, in which OCL types are used for the operation signature, but the real operation is as given in the UML model. The problem is that OCL cannot notate all UML multiplicities . collections always have an effective multiplicity of 0..* and non-collection types have an effective multiplicity of 0..1. Thus, there may be additional multiplicity constraints in the model that are not shown in the OCL text. (Alf, by the way, allows full UML multiplicity notation in operation signatures.) -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, October 28, 2010 9:59 AM To: Ed Seidewitz; uml2-rtf@omg.org; ocl2-rtf@omg.org Cc: issues@omg.org Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Ed >Isn.t it nice that now that we are all looking closely at UML semantics we have so many to choose from? Yes. Great. If OclVoid conforms to all types, so null is a valid member of any type, is there any difference between a UML property typed as Integer[1] and one typed as Integer[0..1]? Or do you see this as an explicit divergence between UML semantics and OCL semantics, where UML allows null to be a valid member of Integer[0..1] but not Integer[1]? If the latter, it.s a bit of a joke using OCL to define UML operations and constraints. -- Steve From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 28 October 2010 14:48 To: Steve Cook; uml2-rtf@omg.org; ocl2-rtf@omg.org Cc: issues@omg.org Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Steve . In the OCL 2.2 spec, Subclause 7.5.3, under .Navigation over Associations with Multiplicity Zero or One., it says: .Because the multiplicity of the role manager is one, self.manager is an object of type Person. Such a single object can be used as a Set as well. It then behaves as if it is a Set containing the single object. The usage as a set is done through the arrow followed by a property of Set.. While it doesn.t seem to say anything explicitly in the spec about non-association end properties with multiplicity 0..1, presumably the semantics are the same. That is, in the OCL type system, the type of such an association end is not explicit a collection, but a value of the association end may be treated in an expression as being a set with at most one member (so one can, e.g., check for emptiness using self.manager->isEmpty()), which is consistent with UML semantics. In OCL 2.2 Subclause 8.2, under .VoidType. it says: .VoidType represents a type that conforms to all types. The only instance of VoidType is OclVoid, which is further defined in the standard library. Furthermore OclVoid has exactly one instance called null - corresponding to the UML NullLiteral [sic] literal specification - and representing the absence of value. Note that in contrast with OclInvalid null is a valid value and as such can be owned by collections.. In the UML 2.3 spec, Subclause 7.3.28, it simply says that .A literal null specifies the lack of a value,. which is the vague semantics that is echoed above in the OCL spec. However, to OCL 2.2 spec further elaborates on OclVoid in Subclause 11.2.3, where it notes that: .However, by virtue of the implicit conversion to a collection literal, an expression evaluating to null can be used as source of collection operations (such as .isEmpty.). If the source is the null literal, it is implicitly converted to Bag{}.. Thus, the OclVoid instance .null. is a distinguished value in OCL semantics, it is effectively equivalent to Bag{} in usage. This seems consistent with the phrase .lack of a value. used in the UML spec, though OclVoid is itself only defined in the OCL spec (as are all OCL collection types, too, for that matter). Note also that, in fUML, a value specification action with a null literal produces a null token . a token that holds no values . when it fires, which is the activity semantics equivalent of the empty set or .lack of a value.. In Alf, the notation .null. is considered equivalent to .any[]{}., that is, an untyped empty sequence, which, as a sequence construction expression, has a special mapping to a value specification with a null literal, giving it the fUML semantics (as would be expected for Alf). Isn.t it nice that now that we are all looking closely at UML semantics we have so many to choose from? -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, October 28, 2010 8:43 AM To: uml2-rtf@omg.org; ocl2-rtf@omg.org Cc: issues@omg.org Subject: Vagueness about meaning of 0..1 multiplicity in OCL and UML In the UML spec especially around the area of MultiplicityElement and ValueSpecification there are numerous types for operation results declared as [Integer] etc. These are freely interpreted as being both sets and integers, both in the way they are used: lowerBound = if lowerValue->isEmpty() then 1 else lowerValue.integerValue() endif and in the way they are constructed: integerValue = Set{} This notation [Integer] appears to be a shorthand for either Set(Integer) or Integer[0..1]. In C# I would call this type Nullable or just int?; but I don.t believe that such a type formally exists in OCL. OCL has the value OclVoid, which is supposed to conform to all types. Is OclVoid semantically equivalent to Set{}? If OclVoid conforms to all types, is there any difference semantically between an attribute declared as multiplicity [1] and one declared as multiplicity [0..1]? If there is no difference, this seriously contradicts my expectations of what multiplicity means. -- Steve From: "Willink, Ed" To: "'Ed Seidewitz'" , "Willink, Ed" , Steve Cook , uml2-rtf@omg.org, ocl2-rtf@omg.org Cc: issues@omg.org Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Date: Thu, 28 Oct 2010 16:24:32 +0100 X-Mailer: Internet Mail Service (5.5.2657.72) Hi Ed The benefit of a let x:Integer[1] syntax is perhaps most evident where in MOFM2T's [let/] which is [1] rather than [0..1] by default. Allowing [0..1] in MOFM2T would be useful. When attempting to code generate for OCL, the ability to do a tight null/invalid analysis is very important since it allows null/invalid tests to be hoisted from every operation to the execution interface. So every promise of nice values is useful. In the case of let x: Integer[1] = e, the test for null e can be done once rather than on each use. Similarly semi-redundant collection signatures may assist code generation although they are not really needed for specifcation purposes. Regards Ed Willink -------------------------------------------------------------------------------- From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 28 October 2010 16:10 To: Willink, Ed; Steve Cook; uml2-rtf@omg.org; ocl2-rtf@omg.org Cc: issues@omg.org Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Ed - The question is, where would such multiplicity constraints be enforced? Since OCL is an expression language, you are always, e.g., combining one set with another, not changing a set value in place. So what does it mean to construct a set in OCL with multiplicity bounds, other than what are already given by the number of explicitly listed values? Further, in a let clause, you always have to give an expression for each of the variables. So something like let x: Integer[1] = e in ... would simply be a declaration that e cannot be null. I suppose that if, when evaluated, e did turn out to be null, then x would get an invalid value. Allowing such a declaration in a let expression might be useful, but probably only marginally so, in my opinion. So, again, the real issue is the boundary between the OCL type system and the UML type system, which basically comes down to the typing of parameters and properties. The multiplicities for these in the UML model then have a fairly clear semantics - they are extra constraints on the cardinality of the values that can be held by those variables. Since one must be cognizant of such multiplicity constraints when writing further related conditions in OCL, I think it would be very useful to allow full UML multiplicity notation for them OCL context clauses, with the appropriate implicit constraint semantics for them then carried into OCL. Given this additional information at the boundary of OCL and UML, it might actually be possible in some cases to statically detect potential multiplicity conformance errors in OCL expressions that reference parameters and properties. Though, of course, this would not always be statically determinable. -- Ed -------------------------------------------------------------------------------- From: Willink, Ed [mailto:Ed.Willink@thalesgroup.com] Sent: Thursday, October 28, 2010 10:55 AM To: 'Steve Cook'; Ed Seidewitz; uml2-rtf@omg.org; ocl2-rtf@omg.org Cc: issues@omg.org Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Hi Steve That all types (except OclInvalid) are nullable is pretty fundamental to OCL. I think a change here would be unwise. However this [0..1] discussion is very interesting. In a meta-model/signature clearly Integer[1] and Integer[0..1] clearly have precisely this non-nullable/nullable characteristic. So why doesn't OCL allow let x : Integer[1] in ... or let x : Integer[0..1] in ... [or some equivalent syntax] -- I've just been having exactly this problem with MOFM2T's [let] variable. And why is the Complete OCL Operation Context Declaration signature so different to UML in this respect? Perhaps OCL should further elaborate the original Set{1,2,3} which is evolving to allow Set(Integer){1,2,3} to also allow Set(Integer[3..3]){1,2,3} [I know the above example is redundant but it demonstrates the syntax enhancement]. Regards Ed Willink -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: 28 October 2010 15:35 To: Ed Seidewitz; uml2-rtf@omg.org; ocl2-rtf@omg.org Cc: issues@omg.org Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Ed So if I understand correctly, you are saying: 1. All operations in UML should be defined with a signature that uses multiplicities, not Set(x) notation. 2. OCL itself does not distinguish between T[1] and T[0..1] 3. There should be an extra level of semantic checking when defining a UML operation in OCL, to both check that it is well-typed from an OCL point of view, and then check that the result is additionally well-typed with respect to the expected multiplicity of its value. That might work, but it seems like a hack. If OCL explicitly introduced nullable and non-nullable types, we could do a much cleaner match. -- Steve From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 28 October 2010 15:24 To: Steve Cook; uml2-rtf@omg.org; ocl2-rtf@omg.org Cc: issues@omg.org Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Steve - In UML, multiplicity is not actually part of the type. It is a separate constraint on cardinality of values. The real vagueness in UML semantics in this area is when this constraint actually has to hold. Now, OCL does not formally use the concept of multiplicity as such at all, but uses collections instead. In OCL 2.2 Subclause 7.5.1 it says "Whenever the multiplicity of an attribute is greater than 1, the result type is collection of values" (and there is a similar statement elsewhere about association ends). As I quoted previously, when the multiplicity upper bound is 1, the OCL type is not a collection, but a single value can always be treated as if it was a set of 1 member in OCL. As far as I understand the OCL semantics on this (though I have not tried to trace through to the formal semantics to confirm it), since single values can always be treated as sets of 1 member, OCL expressions can always be effectively thought of as operating on collections. Thus, declaring something to be Integer within an OCL expression (say in a "let" expression) is, indeed, equivalent to Integer[0..1] in UML. And an OCL expression of type Integer could end up returning an empty value in some cases. However, if an OCL expression of type Integer is used to compute the result of, say, an operation with return type and multiplicity Integer[1], then there is a UML constraint that a call to the operation must always return exactly one Integer value. Thus, whatever the OCL expression is, there is also an effective additional (UML imposed) constraint that "result->notEmpty()". If the given OCL expression for the result can possibly be empty, then the specification of the operation is just logically inconsistent, though syntactically correct in OCL. The real issue, I think, comes up in the context clause for an operation defined in a UML model, in which OCL types are used for the operation signature, but the real operation is as given in the UML model. The problem is that OCL cannot notate all UML multiplicities - collections always have an effective multiplicity of 0..* and non-collection types have an effective multiplicity of 0..1. Thus, there may be additional multiplicity constraints in the model that are not shown in the OCL text. (Alf, by the way, allows full UML multiplicity notation in operation signatures.) -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, October 28, 2010 9:59 AM To: Ed Seidewitz; uml2-rtf@omg.org; ocl2-rtf@omg.org Cc: issues@omg.org Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Ed >Isn't it nice that now that we are all looking closely at UML semantics we have so many to choose from? Yes. Great. If OclVoid conforms to all types, so null is a valid member of any type, is there any difference between a UML property typed as Integer[1] and one typed as Integer[0..1]? Or do you see this as an explicit divergence between UML semantics and OCL semantics, where UML allows null to be a valid member of Integer[0..1] but not Integer[1]? If the latter, it's a bit of a joke using OCL to define UML operations and constraints. -- Steve From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 28 October 2010 14:48 To: Steve Cook; uml2-rtf@omg.org; ocl2-rtf@omg.org Cc: issues@omg.org Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Steve - In the OCL 2.2 spec, Subclause 7.5.3, under "Navigation over Associations with Multiplicity Zero or One", it says: "Because the multiplicity of the role manager is one, self.manager is an object of type Person. Such a single object can be used as a Set as well. It then behaves as if it is a Set containing the single object. The usage as a set is done through the arrow followed by a property of Set." While it doesn't seem to say anything explicitly in the spec about non-association end properties with multiplicity 0..1, presumably the semantics are the same. That is, in the OCL type system, the type of such an association end is not explicit a collection, but a value of the association end may be treated in an expression as being a set with at most one member (so one can, e.g., check for emptiness using self.manager->isEmpty()), which is consistent with UML semantics. In OCL 2.2 Subclause 8.2, under "VoidType" it says: "VoidType represents a type that conforms to all types. The only instance of VoidType is OclVoid, which is further defined in the standard library. Furthermore OclVoid has exactly one instance called null - corresponding to the UML NullLiteral [sic] literal specification - and representing the absence of value. Note that in contrast with OclInvalid null is a valid value and as such can be owned by collections." In the UML 2.3 spec, Subclause 7.3.28, it simply says that "A literal null specifies the lack of a value," which is the vague semantics that is echoed above in the OCL spec. However, to OCL 2.2 spec further elaborates on OclVoid in Subclause 11.2.3, where it notes that: "However, by virtue of the implicit conversion to a collection literal, an expression evaluating to null can be used as source of collection operations (such as 'isEmpty'). If the source is the null literal, it is implicitly converted to Bag{}." Thus, the OclVoid instance "null" is a distinguished value in OCL semantics, it is effectively equivalent to Bag{} in usage. This seems consistent with the phrase "lack of a value" used in the UML spec, though OclVoid is itself only defined in the OCL spec (as are all OCL collection types, too, for that matter). Note also that, in fUML, a value specification action with a null literal produces a null token - a token that holds no values - when it fires, which is the activity semantics equivalent of the empty set or "lack of a value". In Alf, the notation "null" is considered equivalent to "any[]{}", that is, an untyped empty sequence, which, as a sequence construction expression, has a special mapping to a value specification with a null literal, giving it the fUML semantics (as would be expected for Alf). Isn't it nice that now that we are all looking closely at UML semantics we have so many to choose from? -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, October 28, 2010 8:43 AM To: uml2-rtf@omg.org; ocl2-rtf@omg.org Cc: issues@omg.org Subject: Vagueness about meaning of 0..1 multiplicity in OCL and UML In the UML spec especially around the area of MultiplicityElement and ValueSpecification there are numerous types for operation results declared as [Integer] etc. These are freely interpreted as being both sets and integers, both in the way they are used: lowerBound = if lowerValue->isEmpty() then 1 else lowerValue.integerValue() endif and in the way they are constructed: integerValue = Set{} This notation [Integer] appears to be a shorthand for either Set(Integer) or Integer[0..1]. In C# I would call this type Nullable or just int?; but I don't believe that such a type formally exists in OCL. OCL has the value OclVoid, which is supposed to conform to all types. Is OclVoid semantically equivalent to Set{}? If OclVoid conforms to all types, is there any difference semantically between an attribute declared as multiplicity [1] and one declared as multiplicity [0..1]? If there is no difference, this seriously contradicts my expectations of what multiplicity means. -- Steve Please consider the environment before printing a hard copy of this e-mail. The information contained in this e-mail is confidential. It is intended only for the stated addressee(s) and access to it by any other person is unauthorised. If you are not an addressee, you must not disclose, copy, circulate or in any other way use or rely on the information contained in this e-mail. Such unauthorised use may be unlawful. If you have received this e-mail in error, please inform us immediately on +44 (0)118 986 8601 and delete it and all copies from your system. Thales Research and Technology (UK) Limited. A company registered in England and Wales. Registered Office: 2 Dashwood Lang Road, The Bourne Business Park, Addlestone, Weybridge, Surrey KT15 2NX. Registered Number: 774298 Thales UK Limited. A company registered in England and Wales. Registered Office: 2 Dashwood Lang Road, The Bourne Business Park, Addlestone, Weybridge, Surrey KT15 2NX. Registered Number: 868273 From: "Bock, Conrad" To: "uml2-rtf@omg.org" , "ocl2-rtf@omg.org" CC: "issues@omg.org" Date: Thu, 28 Oct 2010 14:38:53 -0400 Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Thread-Topic: Vagueness about meaning of 0..1 multiplicity in OCL and UML Thread-Index: Act2nWG9nHt7ZdhnR6ep7Ws1giycVgABdsJAAAECqsAAAHiYsAAAwygwAACzIsAAB/I40A== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: conrad.bock@nist.gov Mariano, > I think the decision to interpret multiplicity as part of the type > information (rather than as a complementary information) need to be > taken first in UML/MOF specs. If this is done, the OCL spec will > follow, I guess. I disagree, type is about each value, while multiplicity is about the number of values, regardless of type. This is a critical difference you can see in reasoners that operate on models like these. Conrad X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAExpyUxUXebj/2dsb2JhbAChUHG/O4VIBA Date: Thu, 28 Oct 2010 20:15:47 +0100 From: Ed Willink User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5 To: "Bock, Conrad" CC: "uml2-rtf@omg.org" , "ocl2-rtf@omg.org" , "issues@omg.org" Subject: Re: Vagueness about meaning of 0..1 multiplicity in OCL and UML Hi Conrad Agreed. The complementary idea of extending OCL type signatures to include multiplicities solves a further problem with nested collections. The following becomes useful: Sequence(Sequence(Integer[5])[5])[5] - a 5x5x5 matrix. Perhaps UML needs to support the same. Regards Ed Willink On 28/10/2010 19:38, Bock, Conrad wrote: Mariano, > I think the decision to interpret multiplicity as part of the type > information (rather than as a complementary information) need to be > taken first in UML/MOF specs. If this is done, the OCL spec will > follow, I guess. I disagree, type is about each value, while multiplicity is about the number of values, regardless of type. This is a critical difference you can see in reasoners that operate on models like these. Conrad ----- No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1153 / Virus Database: 424/3224 - Release Date: 10/28/10 From: "Wartik, Steven P \"Steve\"" To: "'Ed Seidewitz'" , Steve Cook , "mariano.belaunde@orange-ftgroup.com" , "uml2-rtf@omg.org" , "ocl2-rtf@omg.org" CC: "issues@omg.org" Date: Thu, 28 Oct 2010 15:53:15 -0400 Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Thread-Topic: Vagueness about meaning of 0..1 multiplicity in OCL and UML Thread-Index: Act2nWG9nHt7ZdhnR6ep7Ws1giycVgABdsJAAAECqsAAAIKyAAAAaaGwAAA8CYAAC1wdEA== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Ed, Steve, Mariano, Pardon an obtuse question, but where is it written that a UML model is not well formed if an attribute has multiplicity 1 and a null value? I have made cursory searches for this constraint in the past and have never located it. Steve Wartik From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Thursday, October 28, 2010 10:36 AM To: Steve Cook; mariano.belaunde@orange-ftgroup.com; uml2-rtf@omg.org; ocl2-rtf@omg.org Cc: issues@omg.org Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Steve, Mariano . First of all, as noted in my previous message (which leapfrogged Mariano.s last one), neither .Integer[1]. not .Integer[0..1]. are actually types in either UML or OCL. In UML, multiplicity is not formally part of the type . it is an additional cardinality constraint given on multiplicity elements, and there are typed elements in UML that are not multiplicity elements (such as object nodes other than pins in activities). Multiplicity is not part of the OCL type system at all. In OCL, Integer and Set(Integer) are formally separate types. However, an expression of type Integer in OCL can be treated as a set of at most one member, so it.s effective type is essentially a constrained Set(Integer), equivalent to a type/multiplicity of Integer[0..1] in UML. However, as Mariano notes, having a multiplicity of 1 on an attribute places an additional constraint on that attribute . it must have a value. In an OCL expression of the form .x.a = y., where the attribute .a. has multiplicity 1, the OCL subexpression y may evaluate to a null value . but x.a can simply never equal such a value, since the UML model requires .a. it to have a value. Thus, in any well-formed instance of the UML model, the OCL equality must be false. Finally, I think the statement .OclVoid conforms to all types. is fine, within the context of OCL semantics. It is consistent with any OCL expression of any type effectively having, in UML terms, a multiplicity lower bound of 0 and the implicit conversion of a .null. value to .Bag{}.. -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, October 28, 2010 10:23 AM To: mariano.belaunde@orange-ftgroup.com; Ed Seidewitz; uml2-rtf@omg.org; ocl2-rtf@omg.org Cc: issues@omg.org Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Mariano, thanks. Are you asserting that Integer[1] and Integer[0..1] are distinct types in OCL? -- Steve From: mariano.belaunde@orange-ftgroup.com [mailto:mariano.belaunde@orange-ftgroup.com] Sent: 28 October 2010 15:17 To: Steve Cook; ed-s@modeldriven.com; uml2-rtf@omg.org; ocl2-rtf@omg.org Cc: issues@omg.org Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Steve, >>> is there any difference between a UML property typed as Integer[1] and one typed as Integer[0..1]? Yes there is an important difference. In the first case the attribute need to have a value, and this value need to be a Integer (null is not a valid value) In the second case it is valid not to provide a value for the attribute. In OCL navigating a attribute that has no assigned value results in a 'null' value, but this does not mean that the value of the attribute is null (the navigation expression is null, not the attribute value, which is simply not specified) . Regarding the exact meaning of statement "OclVoid conforms to all types", maybe this needs some clarification or revision. Mariano -------------------------------------------------------------------------------- De : Steve Cook [mailto:Steve.Cook@microsoft.com] Envoyé jeudi 28 octobre 2010 15:59 À: Ed Seidewitz; uml2-rtf@omg.org; ocl2-rtf@omg.org Cc : issues@omg.org Objet : RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Ed >Isn.t it nice that now that we are all looking closely at UML semantics we have so many to choose from? Yes. Great. If OclVoid conforms to all types, so null is a valid member of any type, is there any difference between a UML property typed as Integer[1] and one typed as Integer[0..1]? Or do you see this as an explicit divergence between UML semantics and OCL semantics, where UML allows null to be a valid member of Integer[0..1] but not Integer[1]? If the latter, it.s a bit of a joke using OCL to define UML operations and constraints. -- Steve From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 28 October 2010 14:48 To: Steve Cook; uml2-rtf@omg.org; ocl2-rtf@omg.org Cc: issues@omg.org Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Steve . In the OCL 2.2 spec, Subclause 7.5.3, under .Navigation over Associations with Multiplicity Zero or One., it says: .Because the multiplicity of the role manager is one, self.manager is an object of type Person. Such a single object can be used as a Set as well. It then behaves as if it is a Set containing the single object. The usage as a set is done through the arrow followed by a property of Set.. While it doesn.t seem to say anything explicitly in the spec about non-association end properties with multiplicity 0..1, presumably the semantics are the same. That is, in the OCL type system, the type of such an association end is not explicit a collection, but a value of the association end may be treated in an expression as being a set with at most one member (so one can, e.g., check for emptiness using self.manager->isEmpty()), which is consistent with UML semantics. In OCL 2.2 Subclause 8.2, under .VoidType. it says: .VoidType represents a type that conforms to all types. The only instance of VoidType is OclVoid, which is further defined in the standard library. Furthermore OclVoid has exactly one instance called null - corresponding to the UML NullLiteral [sic] literal specification - and representing the absence of value. Note that in contrast with OclInvalid null is a valid value and as such can be owned by collections.. In the UML 2.3 spec, Subclause 7.3.28, it simply says that .A literal null specifies the lack of a value,. which is the vague semantics that is echoed above in the OCL spec. However, to OCL 2.2 spec further elaborates on OclVoid in Subclause 11.2.3, where it notes that: .However, by virtue of the implicit conversion to a collection literal, an expression evaluating to null can be used as source of collection operations (such as .isEmpty.). If the source is the null literal, it is implicitly converted to Bag{}.. Thus, the OclVoid instance .null. is a distinguished value in OCL semantics, it is effectively equivalent to Bag{} in usage. This seems consistent with the phrase .lack of a value. used in the UML spec, though OclVoid is itself only defined in the OCL spec (as are all OCL collection types, too, for that matter). Note also that, in fUML, a value specification action with a null literal produces a null token . a token that holds no values . when it fires, which is the activity semantics equivalent of the empty set or .lack of a value.. In Alf, the notation .null. is considered equivalent to .any[]{}., that is, an untyped empty sequence, which, as a sequence construction expression, has a special mapping to a value specification with a null literal, giving it the fUML semantics (as would be expected for Alf). Isn.t it nice that now that we are all looking closely at UML semantics we have so many to choose from? -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, October 28, 2010 8:43 AM To: uml2-rtf@omg.org; ocl2-rtf@omg.org Cc: issues@omg.org Subject: Vagueness about meaning of 0..1 multiplicity in OCL and UML In the UML spec especially around the area of MultiplicityElement and ValueSpecification there are numerous types for operation results declared as [Integer] etc. These are freely interpreted as being both sets and integers, both in the way they are used: lowerBound = if lowerValue->isEmpty() then 1 else lowerValue.integerValue() endif and in the way they are constructed: integerValue = Set{} This notation [Integer] appears to be a shorthand for either Set(Integer) or Integer[0..1]. In C# I would call this type Nullable or just int?; but I don.t believe that such a type formally exists in OCL. OCL has the value OclVoid, which is supposed to conform to all types. Is OclVoid semantically equivalent to Set{}? If OclVoid conforms to all types, is there any difference semantically between an attribute declared as multiplicity [1] and one declared as multiplicity [0..1]? If there is no difference, this seriously contradicts my expectations of what multiplicity means. -- Steve From: "Wartik, Steven P \"Steve\"" To: "'Ed Seidewitz'" , Steve Cook , "mariano.belaunde@orange-ftgroup.com" , "uml2-rtf@omg.org" , "ocl2-rtf@omg.org" CC: "issues@omg.org" Date: Thu, 28 Oct 2010 15:53:15 -0400 Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Thread-Topic: Vagueness about meaning of 0..1 multiplicity in OCL and UML Thread-Index: Act2nWG9nHt7ZdhnR6ep7Ws1giycVgABdsJAAAECqsAAAIKyAAAAaaGwAAA8CYAAC1wdEA== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Ed, Steve, Mariano, Pardon an obtuse question, but where is it written that a UML model is not well formed if an attribute has multiplicity 1 and a null value? I have made cursory searches for this constraint in the past and have never located it. Steve Wartik From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Thursday, October 28, 2010 10:36 AM To: Steve Cook; mariano.belaunde@orange-ftgroup.com; uml2-rtf@omg.org; ocl2-rtf@omg.org Cc: issues@omg.org Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Steve, Mariano . First of all, as noted in my previous message (which leapfrogged Mariano.s last one), neither .Integer[1]. not .Integer[0..1]. are actually types in either UML or OCL. In UML, multiplicity is not formally part of the type . it is an additional cardinality constraint given on multiplicity elements, and there are typed elements in UML that are not multiplicity elements (such as object nodes other than pins in activities). Multiplicity is not part of the OCL type system at all. In OCL, Integer and Set(Integer) are formally separate types. However, an expression of type Integer in OCL can be treated as a set of at most one member, so it.s effective type is essentially a constrained Set(Integer), equivalent to a type/multiplicity of Integer[0..1] in UML. However, as Mariano notes, having a multiplicity of 1 on an attribute places an additional constraint on that attribute . it must have a value. In an OCL expression of the form .x.a = y., where the attribute .a. has multiplicity 1, the OCL subexpression y may evaluate to a null value . but x.a can simply never equal such a value, since the UML model requires .a. it to have a value. Thus, in any well-formed instance of the UML model, the OCL equality must be false. Finally, I think the statement .OclVoid conforms to all types. is fine, within the context of OCL semantics. It is consistent with any OCL expression of any type effectively having, in UML terms, a multiplicity lower bound of 0 and the implicit conversion of a .null. value to .Bag{}.. -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, October 28, 2010 10:23 AM To: mariano.belaunde@orange-ftgroup.com; Ed Seidewitz; uml2-rtf@omg.org; ocl2-rtf@omg.org Cc: issues@omg.org Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Mariano, thanks. Are you asserting that Integer[1] and Integer[0..1] are distinct types in OCL? -- Steve From: mariano.belaunde@orange-ftgroup.com [mailto:mariano.belaunde@orange-ftgroup.com] Sent: 28 October 2010 15:17 To: Steve Cook; ed-s@modeldriven.com; uml2-rtf@omg.org; ocl2-rtf@omg.org Cc: issues@omg.org Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Steve, >>> is there any difference between a UML property typed as Integer[1] and one typed as Integer[0..1]? Yes there is an important difference. In the first case the attribute need to have a value, and this value need to be a Integer (null is not a valid value) In the second case it is valid not to provide a value for the attribute. In OCL navigating a attribute that has no assigned value results in a 'null' value, but this does not mean that the value of the attribute is null (the navigation expression is null, not the attribute value, which is simply not specified) . Regarding the exact meaning of statement "OclVoid conforms to all types", maybe this needs some clarification or revision. Mariano -------------------------------------------------------------------------------- De : Steve Cook [mailto:Steve.Cook@microsoft.com] Envoyé jeudi 28 octobre 2010 15:59 À: Ed Seidewitz; uml2-rtf@omg.org; ocl2-rtf@omg.org Cc : issues@omg.org Objet : RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Ed >Isn.t it nice that now that we are all looking closely at UML semantics we have so many to choose from? Yes. Great. If OclVoid conforms to all types, so null is a valid member of any type, is there any difference between a UML property typed as Integer[1] and one typed as Integer[0..1]? Or do you see this as an explicit divergence between UML semantics and OCL semantics, where UML allows null to be a valid member of Integer[0..1] but not Integer[1]? If the latter, it.s a bit of a joke using OCL to define UML operations and constraints. -- Steve From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 28 October 2010 14:48 To: Steve Cook; uml2-rtf@omg.org; ocl2-rtf@omg.org Cc: issues@omg.org Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Steve . In the OCL 2.2 spec, Subclause 7.5.3, under .Navigation over Associations with Multiplicity Zero or One., it says: .Because the multiplicity of the role manager is one, self.manager is an object of type Person. Such a single object can be used as a Set as well. It then behaves as if it is a Set containing the single object. The usage as a set is done through the arrow followed by a property of Set.. While it doesn.t seem to say anything explicitly in the spec about non-association end properties with multiplicity 0..1, presumably the semantics are the same. That is, in the OCL type system, the type of such an association end is not explicit a collection, but a value of the association end may be treated in an expression as being a set with at most one member (so one can, e.g., check for emptiness using self.manager->isEmpty()), which is consistent with UML semantics. In OCL 2.2 Subclause 8.2, under .VoidType. it says: .VoidType represents a type that conforms to all types. The only instance of VoidType is OclVoid, which is further defined in the standard library. Furthermore OclVoid has exactly one instance called null - corresponding to the UML NullLiteral [sic] literal specification - and representing the absence of value. Note that in contrast with OclInvalid null is a valid value and as such can be owned by collections.. In the UML 2.3 spec, Subclause 7.3.28, it simply says that .A literal null specifies the lack of a value,. which is the vague semantics that is echoed above in the OCL spec. However, to OCL 2.2 spec further elaborates on OclVoid in Subclause 11.2.3, where it notes that: .However, by virtue of the implicit conversion to a collection literal, an expression evaluating to null can be used as source of collection operations (such as .isEmpty.). If the source is the null literal, it is implicitly converted to Bag{}.. Thus, the OclVoid instance .null. is a distinguished value in OCL semantics, it is effectively equivalent to Bag{} in usage. This seems consistent with the phrase .lack of a value. used in the UML spec, though OclVoid is itself only defined in the OCL spec (as are all OCL collection types, too, for that matter). Note also that, in fUML, a value specification action with a null literal produces a null token . a token that holds no values . when it fires, which is the activity semantics equivalent of the empty set or .lack of a value.. In Alf, the notation .null. is considered equivalent to .any[]{}., that is, an untyped empty sequence, which, as a sequence construction expression, has a special mapping to a value specification with a null literal, giving it the fUML semantics (as would be expected for Alf). Isn.t it nice that now that we are all looking closely at UML semantics we have so many to choose from? -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, October 28, 2010 8:43 AM To: uml2-rtf@omg.org; ocl2-rtf@omg.org Cc: issues@omg.org Subject: Vagueness about meaning of 0..1 multiplicity in OCL and UML In the UML spec especially around the area of MultiplicityElement and ValueSpecification there are numerous types for operation results declared as [Integer] etc. These are freely interpreted as being both sets and integers, both in the way they are used: lowerBound = if lowerValue->isEmpty() then 1 else lowerValue.integerValue() endif and in the way they are constructed: integerValue = Set{} This notation [Integer] appears to be a shorthand for either Set(Integer) or Integer[0..1]. In C# I would call this type Nullable or just int?; but I don.t believe that such a type formally exists in OCL. OCL has the value OclVoid, which is supposed to conform to all types. Is OclVoid semantically equivalent to Set{}? If OclVoid conforms to all types, is there any difference semantically between an attribute declared as multiplicity [1] and one declared as multiplicity [0..1]? If there is no difference, this seriously contradicts my expectations of what multiplicity means. -- Steve From: "Wartik, Steven P \"Steve\"" To: "'Ed Seidewitz'" , Steve Cook , "mariano.belaunde@orange-ftgroup.com" , "uml2-rtf@omg.org" , "ocl2-rtf@omg.org" CC: "issues@omg.org" Date: Thu, 28 Oct 2010 15:53:15 -0400 Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Thread-Topic: Vagueness about meaning of 0..1 multiplicity in OCL and UML Thread-Index: Act2nWG9nHt7ZdhnR6ep7Ws1giycVgABdsJAAAECqsAAAIKyAAAAaaGwAAA8CYAAC1wdEA== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Ed, Steve, Mariano, Pardon an obtuse question, but where is it written that a UML model is not well formed if an attribute has multiplicity 1 and a null value? I have made cursory searches for this constraint in the past and have never located it. Steve Wartik From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Thursday, October 28, 2010 10:36 AM To: Steve Cook; mariano.belaunde@orange-ftgroup.com; uml2-rtf@omg.org; ocl2-rtf@omg.org Cc: issues@omg.org Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Steve, Mariano . First of all, as noted in my previous message (which leapfrogged Mariano.s last one), neither .Integer[1]. not .Integer[0..1]. are actually types in either UML or OCL. In UML, multiplicity is not formally part of the type . it is an additional cardinality constraint given on multiplicity elements, and there are typed elements in UML that are not multiplicity elements (such as object nodes other than pins in activities). Multiplicity is not part of the OCL type system at all. In OCL, Integer and Set(Integer) are formally separate types. However, an expression of type Integer in OCL can be treated as a set of at most one member, so it.s effective type is essentially a constrained Set(Integer), equivalent to a type/multiplicity of Integer[0..1] in UML. However, as Mariano notes, having a multiplicity of 1 on an attribute places an additional constraint on that attribute . it must have a value. In an OCL expression of the form .x.a = y., where the attribute .a. has multiplicity 1, the OCL subexpression y may evaluate to a null value . but x.a can simply never equal such a value, since the UML model requires .a. it to have a value. Thus, in any well-formed instance of the UML model, the OCL equality must be false. Finally, I think the statement .OclVoid conforms to all types. is fine, within the context of OCL semantics. It is consistent with any OCL expression of any type effectively having, in UML terms, a multiplicity lower bound of 0 and the implicit conversion of a .null. value to .Bag{}.. -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, October 28, 2010 10:23 AM To: mariano.belaunde@orange-ftgroup.com; Ed Seidewitz; uml2-rtf@omg.org; ocl2-rtf@omg.org Cc: issues@omg.org Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Mariano, thanks. Are you asserting that Integer[1] and Integer[0..1] are distinct types in OCL? -- Steve From: mariano.belaunde@orange-ftgroup.com [mailto:mariano.belaunde@orange-ftgroup.com] Sent: 28 October 2010 15:17 To: Steve Cook; ed-s@modeldriven.com; uml2-rtf@omg.org; ocl2-rtf@omg.org Cc: issues@omg.org Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Steve, >>> is there any difference between a UML property typed as Integer[1] and one typed as Integer[0..1]? Yes there is an important difference. In the first case the attribute need to have a value, and this value need to be a Integer (null is not a valid value) In the second case it is valid not to provide a value for the attribute. In OCL navigating a attribute that has no assigned value results in a 'null' value, but this does not mean that the value of the attribute is null (the navigation expression is null, not the attribute value, which is simply not specified) . Regarding the exact meaning of statement "OclVoid conforms to all types", maybe this needs some clarification or revision. Mariano -------------------------------------------------------------------------------- De : Steve Cook [mailto:Steve.Cook@microsoft.com] Envoyé jeudi 28 octobre 2010 15:59 À: Ed Seidewitz; uml2-rtf@omg.org; ocl2-rtf@omg.org Cc : issues@omg.org Objet : RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Ed >Isn.t it nice that now that we are all looking closely at UML semantics we have so many to choose from? Yes. Great. If OclVoid conforms to all types, so null is a valid member of any type, is there any difference between a UML property typed as Integer[1] and one typed as Integer[0..1]? Or do you see this as an explicit divergence between UML semantics and OCL semantics, where UML allows null to be a valid member of Integer[0..1] but not Integer[1]? If the latter, it.s a bit of a joke using OCL to define UML operations and constraints. -- Steve From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 28 October 2010 14:48 To: Steve Cook; uml2-rtf@omg.org; ocl2-rtf@omg.org Cc: issues@omg.org Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Steve . In the OCL 2.2 spec, Subclause 7.5.3, under .Navigation over Associations with Multiplicity Zero or One., it says: .Because the multiplicity of the role manager is one, self.manager is an object of type Person. Such a single object can be used as a Set as well. It then behaves as if it is a Set containing the single object. The usage as a set is done through the arrow followed by a property of Set.. While it doesn.t seem to say anything explicitly in the spec about non-association end properties with multiplicity 0..1, presumably the semantics are the same. That is, in the OCL type system, the type of such an association end is not explicit a collection, but a value of the association end may be treated in an expression as being a set with at most one member (so one can, e.g., check for emptiness using self.manager->isEmpty()), which is consistent with UML semantics. In OCL 2.2 Subclause 8.2, under .VoidType. it says: .VoidType represents a type that conforms to all types. The only instance of VoidType is OclVoid, which is further defined in the standard library. Furthermore OclVoid has exactly one instance called null - corresponding to the UML NullLiteral [sic] literal specification - and representing the absence of value. Note that in contrast with OclInvalid null is a valid value and as such can be owned by collections.. In the UML 2.3 spec, Subclause 7.3.28, it simply says that .A literal null specifies the lack of a value,. which is the vague semantics that is echoed above in the OCL spec. However, to OCL 2.2 spec further elaborates on OclVoid in Subclause 11.2.3, where it notes that: .However, by virtue of the implicit conversion to a collection literal, an expression evaluating to null can be used as source of collection operations (such as .isEmpty.). If the source is the null literal, it is implicitly converted to Bag{}.. Thus, the OclVoid instance .null. is a distinguished value in OCL semantics, it is effectively equivalent to Bag{} in usage. This seems consistent with the phrase .lack of a value. used in the UML spec, though OclVoid is itself only defined in the OCL spec (as are all OCL collection types, too, for that matter). Note also that, in fUML, a value specification action with a null literal produces a null token . a token that holds no values . when it fires, which is the activity semantics equivalent of the empty set or .lack of a value.. In Alf, the notation .null. is considered equivalent to .any[]{}., that is, an untyped empty sequence, which, as a sequence construction expression, has a special mapping to a value specification with a null literal, giving it the fUML semantics (as would be expected for Alf). Isn.t it nice that now that we are all looking closely at UML semantics we have so many to choose from? -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, October 28, 2010 8:43 AM To: uml2-rtf@omg.org; ocl2-rtf@omg.org Cc: issues@omg.org Subject: Vagueness about meaning of 0..1 multiplicity in OCL and UML In the UML spec especially around the area of MultiplicityElement and ValueSpecification there are numerous types for operation results declared as [Integer] etc. These are freely interpreted as being both sets and integers, both in the way they are used: lowerBound = if lowerValue->isEmpty() then 1 else lowerValue.integerValue() endif and in the way they are constructed: integerValue = Set{} This notation [Integer] appears to be a shorthand for either Set(Integer) or Integer[0..1]. In C# I would call this type Nullable or just int?; but I don.t believe that such a type formally exists in OCL. OCL has the value OclVoid, which is supposed to conform to all types. Is OclVoid semantically equivalent to Set{}? If OclVoid conforms to all types, is there any difference semantically between an attribute declared as multiplicity [1] and one declared as multiplicity [0..1]? If there is no difference, this seriously contradicts my expectations of what multiplicity means. -- Steve Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Date: Thu, 28 Oct 2010 16:06:16 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Vagueness about meaning of 0..1 multiplicity in OCL and UML Thread-Index: Act2nWG9nHt7ZdhnR6ep7Ws1giycVgABdsJAAAECqsAAAIKyAAAAaaGwAAA8CYAAC1wdEAAAgAhQ From: "Ed Seidewitz" To: "Wartik, Steven P \"Steve\"" Cc: , Steve . In the UML 2.3 spec, Subclause 7.3.32 MultiplicityElement, it says: .If a MultiplicityElement specifies a multivalued multiplicity, then an instantiation of this element has a collection of values. The multiplicity is a constraint on the number of values that may validly occur in that set.. So, if a multiplicity element has a number of values that violates the multiplicity constraint, that is invalid. -- Ed -------------------------------------------------------------------------------- From: Wartik, Steven P "Steve" [mailto:swartik@ida.org] Sent: Thursday, October 28, 2010 3:53 PM To: Ed Seidewitz; Steve Cook; mariano.belaunde@orange-ftgroup.com; uml2-rtf@omg.org; ocl2-rtf@omg.org Cc: issues@omg.org Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Ed, Steve, Mariano, Pardon an obtuse question, but where is it written that a UML model is not well formed if an attribute has multiplicity 1 and a null value? I have made cursory searches for this constraint in the past and have never located it. Steve Wartik From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Thursday, October 28, 2010 10:36 AM To: Steve Cook; mariano.belaunde@orange-ftgroup.com; uml2-rtf@omg.org; ocl2-rtf@omg.org Cc: issues@omg.org Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Steve, Mariano . First of all, as noted in my previous message (which leapfrogged Mariano.s last one), neither .Integer[1]. not .Integer[0..1]. are actually types in either UML or OCL. In UML, multiplicity is not formally part of the type . it is an additional cardinality constraint given on multiplicity elements, and there are typed elements in UML that are not multiplicity elements (such as object nodes other than pins in activities). Multiplicity is not part of the OCL type system at all. In OCL, Integer and Set(Integer) are formally separate types. However, an expression of type Integer in OCL can be treated as a set of at most one member, so it.s effective type is essentially a constrained Set(Integer), equivalent to a type/multiplicity of Integer[0..1] in UML. However, as Mariano notes, having a multiplicity of 1 on an attribute places an additional constraint on that attribute . it must have a value. In an OCL expression of the form .x.a = y., where the attribute .a. has multiplicity 1, the OCL subexpression y may evaluate to a null value . but x.a can simply never equal such a value, since the UML model requires .a. it to have a value. Thus, in any well-formed instance of the UML model, the OCL equality must be false. Finally, I think the statement .OclVoid conforms to all types. is fine, within the context of OCL semantics. It is consistent with any OCL expression of any type effectively having, in UML terms, a multiplicity lower bound of 0 and the implicit conversion of a .null. value to .Bag{}.. -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, October 28, 2010 10:23 AM To: mariano.belaunde@orange-ftgroup.com; Ed Seidewitz; uml2-rtf@omg.org; ocl2-rtf@omg.org Cc: issues@omg.org Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Mariano, thanks. Are you asserting that Integer[1] and Integer[0..1] are distinct types in OCL? -- Steve From: mariano.belaunde@orange-ftgroup.com [mailto:mariano.belaunde@orange-ftgroup.com] Sent: 28 October 2010 15:17 To: Steve Cook; ed-s@modeldriven.com; uml2-rtf@omg.org; ocl2-rtf@omg.org Cc: issues@omg.org Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Steve, >>> is there any difference between a UML property typed as Integer[1] and one typed as Integer[0..1]? Yes there is an important difference. In the first case the attribute need to have a value, and this value need to be a Integer (null is not a valid value) In the second case it is valid not to provide a value for the attribute. In OCL navigating a attribute that has no assigned value results in a 'null' value, but this does not mean that the value of the attribute is null (the navigation expression is null, not the attribute value, which is simply not specified) . Regarding the exact meaning of statement "OclVoid conforms to all types", maybe this needs some clarification or revision. Mariano -------------------------------------------------------------------------------- De : Steve Cook [mailto:Steve.Cook@microsoft.com] Envoyé jeudi 28 octobre 2010 15:59 À: Ed Seidewitz; uml2-rtf@omg.org; ocl2-rtf@omg.org Cc : issues@omg.org Objet : RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Ed >Isn.t it nice that now that we are all looking closely at UML semantics we have so many to choose from? Yes. Great. If OclVoid conforms to all types, so null is a valid member of any type, is there any difference between a UML property typed as Integer[1] and one typed as Integer[0..1]? Or do you see this as an explicit divergence between UML semantics and OCL semantics, where UML allows null to be a valid member of Integer[0..1] but not Integer[1]? If the latter, it.s a bit of a joke using OCL to define UML operations and constraints. -- Steve From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 28 October 2010 14:48 To: Steve Cook; uml2-rtf@omg.org; ocl2-rtf@omg.org Cc: issues@omg.org Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Steve . In the OCL 2.2 spec, Subclause 7.5.3, under .Navigation over Associations with Multiplicity Zero or One., it says: .Because the multiplicity of the role manager is one, self.manager is an object of type Person. Such a single object can be used as a Set as well. It then behaves as if it is a Set containing the single object. The usage as a set is done through the arrow followed by a property of Set.. While it doesn.t seem to say anything explicitly in the spec about non-association end properties with multiplicity 0..1, presumably the semantics are the same. That is, in the OCL type system, the type of such an association end is not explicit a collection, but a value of the association end may be treated in an expression as being a set with at most one member (so one can, e.g., check for emptiness using self.manager->isEmpty()), which is consistent with UML semantics. In OCL 2.2 Subclause 8.2, under .VoidType. it says: .VoidType represents a type that conforms to all types. The only instance of VoidType is OclVoid, which is further defined in the standard library. Furthermore OclVoid has exactly one instance called null - corresponding to the UML NullLiteral [sic] literal specification - and representing the absence of value. Note that in contrast with OclInvalid null is a valid value and as such can be owned by collections.. In the UML 2.3 spec, Subclause 7.3.28, it simply says that .A literal null specifies the lack of a value,. which is the vague semantics that is echoed above in the OCL spec. However, to OCL 2.2 spec further elaborates on OclVoid in Subclause 11.2.3, where it notes that: .However, by virtue of the implicit conversion to a collection literal, an expression evaluating to null can be used as source of collection operations (such as .isEmpty.). If the source is the null literal, it is implicitly converted to Bag{}.. Thus, the OclVoid instance .null. is a distinguished value in OCL semantics, it is effectively equivalent to Bag{} in usage. This seems consistent with the phrase .lack of a value. used in the UML spec, though OclVoid is itself only defined in the OCL spec (as are all OCL collection types, too, for that matter). Note also that, in fUML, a value specification action with a null literal produces a null token . a token that holds no values . when it fires, which is the activity semantics equivalent of the empty set or .lack of a value.. In Alf, the notation .null. is considered equivalent to .any[]{}., that is, an untyped empty sequence, which, as a sequence construction expression, has a special mapping to a value specification with a null literal, giving it the fUML semantics (as would be expected for Alf). Isn.t it nice that now that we are all looking closely at UML semantics we have so many to choose from? -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, October 28, 2010 8:43 AM To: uml2-rtf@omg.org; ocl2-rtf@omg.org Cc: issues@omg.org Subject: Vagueness about meaning of 0..1 multiplicity in OCL and UML In the UML spec especially around the area of MultiplicityElement and ValueSpecification there are numerous types for operation results declared as [Integer] etc. These are freely interpreted as being both sets and integers, both in the way they are used: lowerBound = if lowerValue->isEmpty() then 1 else lowerValue.integerValue() endif and in the way they are constructed: integerValue = Set{} This notation [Integer] appears to be a shorthand for either Set(Integer) or Integer[0..1]. In C# I would call this type Nullable or just int?; but I don.t believe that such a type formally exists in OCL. OCL has the value OclVoid, which is supposed to conform to all types. Is OclVoid semantically equivalent to Set{}? If OclVoid conforms to all types, is there any difference semantically between an attribute declared as multiplicity [1] and one declared as multiplicity [0..1]? If there is no difference, this seriously contradicts my expectations of what multiplicity means. -- Steve From: "Wartik, Steven P \"Steve\"" To: "'Ed Seidewitz'" CC: "uml2-rtf@omg.org" , "ocl2-rtf@omg.org" Date: Thu, 28 Oct 2010 16:10:20 -0400 Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Thread-Topic: Vagueness about meaning of 0..1 multiplicity in OCL and UML Thread-Index: Act2nWG9nHt7ZdhnR6ep7Ws1giycVgABdsJAAAECqsAAAIKyAAAAaaGwAAA8CYAAC1wdEAAAgAhQAAAfM9A= Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Ed, Yes, but what if I explicitly assign a null value to an attribute? Then it has a value, just not one that common sense would say is appropriate to the type. Steve From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Thursday, October 28, 2010 4:06 PM To: Wartik, Steven P "Steve" Cc: uml2-rtf@omg.org; ocl2-rtf@omg.org Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Steve . In the UML 2.3 spec, Subclause 7.3.32 MultiplicityElement, it says: .If a MultiplicityElement specifies a multivalued multiplicity, then an instantiation of this element has a collection of values. The multiplicity is a constraint on the number of values that may validly occur in that set.. So, if a multiplicity element has a number of values that violates the multiplicity constraint, that is invalid. -- Ed -------------------------------------------------------------------------------- From: Wartik, Steven P "Steve" [mailto:swartik@ida.org] Sent: Thursday, October 28, 2010 3:53 PM To: Ed Seidewitz; Steve Cook; mariano.belaunde@orange-ftgroup.com; uml2-rtf@omg.org; ocl2-rtf@omg.org Cc: issues@omg.org Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Ed, Steve, Mariano, Pardon an obtuse question, but where is it written that a UML model is not well formed if an attribute has multiplicity 1 and a null value? I have made cursory searches for this constraint in the past and have never located it. Steve Wartik From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Thursday, October 28, 2010 10:36 AM To: Steve Cook; mariano.belaunde@orange-ftgroup.com; uml2-rtf@omg.org; ocl2-rtf@omg.org Cc: issues@omg.org Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Steve, Mariano . First of all, as noted in my previous message (which leapfrogged Mariano.s last one), neither .Integer[1]. not .Integer[0..1]. are actually types in either UML or OCL. In UML, multiplicity is not formally part of the type . it is an additional cardinality constraint given on multiplicity elements, and there are typed elements in UML that are not multiplicity elements (such as object nodes other than pins in activities). Multiplicity is not part of the OCL type system at all. In OCL, Integer and Set(Integer) are formally separate types. However, an expression of type Integer in OCL can be treated as a set of at most one member, so it.s effective type is essentially a constrained Set(Integer), equivalent to a type/multiplicity of Integer[0..1] in UML. However, as Mariano notes, having a multiplicity of 1 on an attribute places an additional constraint on that attribute . it must have a value. In an OCL expression of the form .x.a = y., where the attribute .a. has multiplicity 1, the OCL subexpression y may evaluate to a null value . but x.a can simply never equal such a value, since the UML model requires .a. it to have a value. Thus, in any well-formed instance of the UML model, the OCL equality must be false. Finally, I think the statement .OclVoid conforms to all types. is fine, within the context of OCL semantics. It is consistent with any OCL expression of any type effectively having, in UML terms, a multiplicity lower bound of 0 and the implicit conversion of a .null. value to .Bag{}.. -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, October 28, 2010 10:23 AM To: mariano.belaunde@orange-ftgroup.com; Ed Seidewitz; uml2-rtf@omg.org; ocl2-rtf@omg.org Cc: issues@omg.org Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Mariano, thanks. Are you asserting that Integer[1] and Integer[0..1] are distinct types in OCL? -- Steve From: mariano.belaunde@orange-ftgroup.com [mailto:mariano.belaunde@orange-ftgroup.com] Sent: 28 October 2010 15:17 To: Steve Cook; ed-s@modeldriven.com; uml2-rtf@omg.org; ocl2-rtf@omg.org Cc: issues@omg.org Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Steve, >>> is there any difference between a UML property typed as Integer[1] and one typed as Integer[0..1]? Yes there is an important difference. In the first case the attribute need to have a value, and this value need to be a Integer (null is not a valid value) In the second case it is valid not to provide a value for the attribute. In OCL navigating a attribute that has no assigned value results in a 'null' value, but this does not mean that the value of the attribute is null (the navigation expression is null, not the attribute value, which is simply not specified) . Regarding the exact meaning of statement "OclVoid conforms to all types", maybe this needs some clarification or revision. Mariano -------------------------------------------------------------------------------- De : Steve Cook [mailto:Steve.Cook@microsoft.com] Envoyé jeudi 28 octobre 2010 15:59 À: Ed Seidewitz; uml2-rtf@omg.org; ocl2-rtf@omg.org Cc : issues@omg.org Objet : RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Ed >Isn.t it nice that now that we are all looking closely at UML semantics we have so many to choose from? Yes. Great. If OclVoid conforms to all types, so null is a valid member of any type, is there any difference between a UML property typed as Integer[1] and one typed as Integer[0..1]? Or do you see this as an explicit divergence between UML semantics and OCL semantics, where UML allows null to be a valid member of Integer[0..1] but not Integer[1]? If the latter, it.s a bit of a joke using OCL to define UML operations and constraints. -- Steve From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 28 October 2010 14:48 To: Steve Cook; uml2-rtf@omg.org; ocl2-rtf@omg.org Cc: issues@omg.org Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Steve . In the OCL 2.2 spec, Subclause 7.5.3, under .Navigation over Associations with Multiplicity Zero or One., it says: .Because the multiplicity of the role manager is one, self.manager is an object of type Person. Such a single object can be used as a Set as well. It then behaves as if it is a Set containing the single object. The usage as a set is done through the arrow followed by a property of Set.. While it doesn.t seem to say anything explicitly in the spec about non-association end properties with multiplicity 0..1, presumably the semantics are the same. That is, in the OCL type system, the type of such an association end is not explicit a collection, but a value of the association end may be treated in an expression as being a set with at most one member (so one can, e.g., check for emptiness using self.manager->isEmpty()), which is consistent with UML semantics. In OCL 2.2 Subclause 8.2, under .VoidType. it says: .VoidType represents a type that conforms to all types. The only instance of VoidType is OclVoid, which is further defined in the standard library. Furthermore OclVoid has exactly one instance called null - corresponding to the UML NullLiteral [sic] literal specification - and representing the absence of value. Note that in contrast with OclInvalid null is a valid value and as such can be owned by collections.. In the UML 2.3 spec, Subclause 7.3.28, it simply says that .A literal null specifies the lack of a value,. which is the vague semantics that is echoed above in the OCL spec. However, to OCL 2.2 spec further elaborates on OclVoid in Subclause 11.2.3, where it notes that: .However, by virtue of the implicit conversion to a collection literal, an expression evaluating to null can be used as source of collection operations (such as .isEmpty.). If the source is the null literal, it is implicitly converted to Bag{}.. Thus, the OclVoid instance .null. is a distinguished value in OCL semantics, it is effectively equivalent to Bag{} in usage. This seems consistent with the phrase .lack of a value. used in the UML spec, though OclVoid is itself only defined in the OCL spec (as are all OCL collection types, too, for that matter). Note also that, in fUML, a value specification action with a null literal produces a null token . a token that holds no values . when it fires, which is the activity semantics equivalent of the empty set or .lack of a value.. In Alf, the notation .null. is considered equivalent to .any[]{}., that is, an untyped empty sequence, which, as a sequence construction expression, has a special mapping to a value specification with a null literal, giving it the fUML semantics (as would be expected for Alf). Isn.t it nice that now that we are all looking closely at UML semantics we have so many to choose from? -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, October 28, 2010 8:43 AM To: uml2-rtf@omg.org; ocl2-rtf@omg.org Cc: issues@omg.org Subject: Vagueness about meaning of 0..1 multiplicity in OCL and UML In the UML spec especially around the area of MultiplicityElement and ValueSpecification there are numerous types for operation results declared as [Integer] etc. These are freely interpreted as being both sets and integers, both in the way they are used: lowerBound = if lowerValue->isEmpty() then 1 else lowerValue.integerValue() endif and in the way they are constructed: integerValue = Set{} This notation [Integer] appears to be a shorthand for either Set(Integer) or Integer[0..1]. In C# I would call this type Nullable or just int?; but I don.t believe that such a type formally exists in OCL. OCL has the value OclVoid, which is supposed to conform to all types. Is OclVoid semantically equivalent to Set{}? If OclVoid conforms to all types, is there any difference semantically between an attribute declared as multiplicity [1] and one declared as multiplicity [0..1]? If there is no difference, this seriously contradicts my expectations of what multiplicity means. -- Steve From: "Wartik, Steven P \"Steve\"" To: "'Ed Seidewitz'" CC: "uml2-rtf@omg.org" , "ocl2-rtf@omg.org" Date: Thu, 28 Oct 2010 16:10:20 -0400 Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Thread-Topic: Vagueness about meaning of 0..1 multiplicity in OCL and UML Thread-Index: Act2nWG9nHt7ZdhnR6ep7Ws1giycVgABdsJAAAECqsAAAIKyAAAAaaGwAAA8CYAAC1wdEAAAgAhQAAAfM9A= Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Ed, Yes, but what if I explicitly assign a null value to an attribute? Then it has a value, just not one that common sense would say is appropriate to the type. Steve From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Thursday, October 28, 2010 4:06 PM To: Wartik, Steven P "Steve" Cc: uml2-rtf@omg.org; ocl2-rtf@omg.org Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Steve . In the UML 2.3 spec, Subclause 7.3.32 MultiplicityElement, it says: .If a MultiplicityElement specifies a multivalued multiplicity, then an instantiation of this element has a collection of values. The multiplicity is a constraint on the number of values that may validly occur in that set.. So, if a multiplicity element has a number of values that violates the multiplicity constraint, that is invalid. -- Ed -------------------------------------------------------------------------------- From: Wartik, Steven P "Steve" [mailto:swartik@ida.org] Sent: Thursday, October 28, 2010 3:53 PM To: Ed Seidewitz; Steve Cook; mariano.belaunde@orange-ftgroup.com; uml2-rtf@omg.org; ocl2-rtf@omg.org Cc: issues@omg.org Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Ed, Steve, Mariano, Pardon an obtuse question, but where is it written that a UML model is not well formed if an attribute has multiplicity 1 and a null value? I have made cursory searches for this constraint in the past and have never located it. Steve Wartik From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Thursday, October 28, 2010 10:36 AM To: Steve Cook; mariano.belaunde@orange-ftgroup.com; uml2-rtf@omg.org; ocl2-rtf@omg.org Cc: issues@omg.org Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Steve, Mariano . First of all, as noted in my previous message (which leapfrogged Mariano.s last one), neither .Integer[1]. not .Integer[0..1]. are actually types in either UML or OCL. In UML, multiplicity is not formally part of the type . it is an additional cardinality constraint given on multiplicity elements, and there are typed elements in UML that are not multiplicity elements (such as object nodes other than pins in activities). Multiplicity is not part of the OCL type system at all. In OCL, Integer and Set(Integer) are formally separate types. However, an expression of type Integer in OCL can be treated as a set of at most one member, so it.s effective type is essentially a constrained Set(Integer), equivalent to a type/multiplicity of Integer[0..1] in UML. However, as Mariano notes, having a multiplicity of 1 on an attribute places an additional constraint on that attribute . it must have a value. In an OCL expression of the form .x.a = y., where the attribute .a. has multiplicity 1, the OCL subexpression y may evaluate to a null value . but x.a can simply never equal such a value, since the UML model requires .a. it to have a value. Thus, in any well-formed instance of the UML model, the OCL equality must be false. Finally, I think the statement .OclVoid conforms to all types. is fine, within the context of OCL semantics. It is consistent with any OCL expression of any type effectively having, in UML terms, a multiplicity lower bound of 0 and the implicit conversion of a .null. value to .Bag{}.. -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, October 28, 2010 10:23 AM To: mariano.belaunde@orange-ftgroup.com; Ed Seidewitz; uml2-rtf@omg.org; ocl2-rtf@omg.org Cc: issues@omg.org Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Mariano, thanks. Are you asserting that Integer[1] and Integer[0..1] are distinct types in OCL? -- Steve From: mariano.belaunde@orange-ftgroup.com [mailto:mariano.belaunde@orange-ftgroup.com] Sent: 28 October 2010 15:17 To: Steve Cook; ed-s@modeldriven.com; uml2-rtf@omg.org; ocl2-rtf@omg.org Cc: issues@omg.org Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Steve, >>> is there any difference between a UML property typed as Integer[1] and one typed as Integer[0..1]? Yes there is an important difference. In the first case the attribute need to have a value, and this value need to be a Integer (null is not a valid value) In the second case it is valid not to provide a value for the attribute. In OCL navigating a attribute that has no assigned value results in a 'null' value, but this does not mean that the value of the attribute is null (the navigation expression is null, not the attribute value, which is simply not specified) . Regarding the exact meaning of statement "OclVoid conforms to all types", maybe this needs some clarification or revision. Mariano -------------------------------------------------------------------------------- De : Steve Cook [mailto:Steve.Cook@microsoft.com] Envoyé jeudi 28 octobre 2010 15:59 À: Ed Seidewitz; uml2-rtf@omg.org; ocl2-rtf@omg.org Cc : issues@omg.org Objet : RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Ed >Isn.t it nice that now that we are all looking closely at UML semantics we have so many to choose from? Yes. Great. If OclVoid conforms to all types, so null is a valid member of any type, is there any difference between a UML property typed as Integer[1] and one typed as Integer[0..1]? Or do you see this as an explicit divergence between UML semantics and OCL semantics, where UML allows null to be a valid member of Integer[0..1] but not Integer[1]? If the latter, it.s a bit of a joke using OCL to define UML operations and constraints. -- Steve From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 28 October 2010 14:48 To: Steve Cook; uml2-rtf@omg.org; ocl2-rtf@omg.org Cc: issues@omg.org Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Steve . In the OCL 2.2 spec, Subclause 7.5.3, under .Navigation over Associations with Multiplicity Zero or One., it says: .Because the multiplicity of the role manager is one, self.manager is an object of type Person. Such a single object can be used as a Set as well. It then behaves as if it is a Set containing the single object. The usage as a set is done through the arrow followed by a property of Set.. While it doesn.t seem to say anything explicitly in the spec about non-association end properties with multiplicity 0..1, presumably the semantics are the same. That is, in the OCL type system, the type of such an association end is not explicit a collection, but a value of the association end may be treated in an expression as being a set with at most one member (so one can, e.g., check for emptiness using self.manager->isEmpty()), which is consistent with UML semantics. In OCL 2.2 Subclause 8.2, under .VoidType. it says: .VoidType represents a type that conforms to all types. The only instance of VoidType is OclVoid, which is further defined in the standard library. Furthermore OclVoid has exactly one instance called null - corresponding to the UML NullLiteral [sic] literal specification - and representing the absence of value. Note that in contrast with OclInvalid null is a valid value and as such can be owned by collections.. In the UML 2.3 spec, Subclause 7.3.28, it simply says that .A literal null specifies the lack of a value,. which is the vague semantics that is echoed above in the OCL spec. However, to OCL 2.2 spec further elaborates on OclVoid in Subclause 11.2.3, where it notes that: .However, by virtue of the implicit conversion to a collection literal, an expression evaluating to null can be used as source of collection operations (such as .isEmpty.). If the source is the null literal, it is implicitly converted to Bag{}.. Thus, the OclVoid instance .null. is a distinguished value in OCL semantics, it is effectively equivalent to Bag{} in usage. This seems consistent with the phrase .lack of a value. used in the UML spec, though OclVoid is itself only defined in the OCL spec (as are all OCL collection types, too, for that matter). Note also that, in fUML, a value specification action with a null literal produces a null token . a token that holds no values . when it fires, which is the activity semantics equivalent of the empty set or .lack of a value.. In Alf, the notation .null. is considered equivalent to .any[]{}., that is, an untyped empty sequence, which, as a sequence construction expression, has a special mapping to a value specification with a null literal, giving it the fUML semantics (as would be expected for Alf). Isn.t it nice that now that we are all looking closely at UML semantics we have so many to choose from? -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, October 28, 2010 8:43 AM To: uml2-rtf@omg.org; ocl2-rtf@omg.org Cc: issues@omg.org Subject: Vagueness about meaning of 0..1 multiplicity in OCL and UML In the UML spec especially around the area of MultiplicityElement and ValueSpecification there are numerous types for operation results declared as [Integer] etc. These are freely interpreted as being both sets and integers, both in the way they are used: lowerBound = if lowerValue->isEmpty() then 1 else lowerValue.integerValue() endif and in the way they are constructed: integerValue = Set{} This notation [Integer] appears to be a shorthand for either Set(Integer) or Integer[0..1]. In C# I would call this type Nullable or just int?; but I don.t believe that such a type formally exists in OCL. OCL has the value OclVoid, which is supposed to conform to all types. Is OclVoid semantically equivalent to Set{}? If OclVoid conforms to all types, is there any difference semantically between an attribute declared as multiplicity [1] and one declared as multiplicity [0..1]? If there is no difference, this seriously contradicts my expectations of what multiplicity means. -- Steve Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Date: Thu, 28 Oct 2010 16:38:59 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Vagueness about meaning of 0..1 multiplicity in OCL and UML Thread-Index: Act2nWG9nHt7ZdhnR6ep7Ws1giycVgABdsJAAAECqsAAAIKyAAAAaaGwAAA8CYAAC1wdEAAAgAhQAAAfM9AAAHeawA== From: "Ed Seidewitz" To: "Wartik, Steven P \"Steve\"" Cc: , Steve . An instantiation of an attribute with multiplicity 1..1 and no value is invalid, not impossible. Instantiations of model elements can exist but be invalid, just like model elements themselves can exist and be ill formed (i.e., violate one of the constraints given in the spec). This is not just a matter of .common sense., though; it is a clear violation of an explicit constraint given in the model. However, UML semantics are loose in general on when and how constraints in a model are actually enforced. For example, a create object action always creates an object with empty attributes, whatever their multiplicity. However, if the object is created as part of a constructor operation, then mandatory attributes can be filled in before the end of that operation, so that all multiplicity constraints are satisfied when the new object is returned by the operation. But this is not explicitly .required. by the UML semantics . it is effectively a modeler obligation to be self-consistent with the constraints the modeler puts into the model. So, there is a clear definition of what it means for multiplicity, or any other constraint, to be violated at any point in time in an instantiation of a UML model. However, such in instantiation is simply no longer a valid interpretation of the model. But, in terms of execution semantics, there are currently no run-time .consequences. for such constraint violations. A model execution tool could certainly provide a capability to indicate when multiplicity (or other constraint) violations have occurred, but it is not currently obligated to in order to conform to the foundational UML execution semantics. -- Ed -------------------------------------------------------------------------------- From: Wartik, Steven P "Steve" [mailto:swartik@ida.org] Sent: Thursday, October 28, 2010 4:10 PM To: Ed Seidewitz Cc: uml2-rtf@omg.org; ocl2-rtf@omg.org Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Ed, Yes, but what if I explicitly assign a null value to an attribute? Then it has a value, just not one that common sense would say is appropriate to the type. Steve From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Thursday, October 28, 2010 4:06 PM To: Wartik, Steven P "Steve" Cc: uml2-rtf@omg.org; ocl2-rtf@omg.org Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Steve . In the UML 2.3 spec, Subclause 7.3.32 MultiplicityElement, it says: .If a MultiplicityElement specifies a multivalued multiplicity, then an instantiation of this element has a collection of values. The multiplicity is a constraint on the number of values that may validly occur in that set.. So, if a multiplicity element has a number of values that violates the multiplicity constraint, that is invalid. -- Ed -------------------------------------------------------------------------------- From: Wartik, Steven P "Steve" [mailto:swartik@ida.org] Sent: Thursday, October 28, 2010 3:53 PM To: Ed Seidewitz; Steve Cook; mariano.belaunde@orange-ftgroup.com; uml2-rtf@omg.org; ocl2-rtf@omg.org Cc: issues@omg.org Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Ed, Steve, Mariano, Pardon an obtuse question, but where is it written that a UML model is not well formed if an attribute has multiplicity 1 and a null value? I have made cursory searches for this constraint in the past and have never located it. Steve Wartik From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Thursday, October 28, 2010 10:36 AM To: Steve Cook; mariano.belaunde@orange-ftgroup.com; uml2-rtf@omg.org; ocl2-rtf@omg.org Cc: issues@omg.org Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Steve, Mariano . First of all, as noted in my previous message (which leapfrogged Mariano.s last one), neither .Integer[1]. not .Integer[0..1]. are actually types in either UML or OCL. In UML, multiplicity is not formally part of the type . it is an additional cardinality constraint given on multiplicity elements, and there are typed elements in UML that are not multiplicity elements (such as object nodes other than pins in activities). Multiplicity is not part of the OCL type system at all. In OCL, Integer and Set(Integer) are formally separate types. However, an expression of type Integer in OCL can be treated as a set of at most one member, so it.s effective type is essentially a constrained Set(Integer), equivalent to a type/multiplicity of Integer[0..1] in UML. However, as Mariano notes, having a multiplicity of 1 on an attribute places an additional constraint on that attribute . it must have a value. In an OCL expression of the form .x.a = y., where the attribute .a. has multiplicity 1, the OCL subexpression y may evaluate to a null value . but x.a can simply never equal such a value, since the UML model requires .a. it to have a value. Thus, in any well-formed instance of the UML model, the OCL equality must be false. Finally, I think the statement .OclVoid conforms to all types. is fine, within the context of OCL semantics. It is consistent with any OCL expression of any type effectively having, in UML terms, a multiplicity lower bound of 0 and the implicit conversion of a .null. value to .Bag{}.. -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, October 28, 2010 10:23 AM To: mariano.belaunde@orange-ftgroup.com; Ed Seidewitz; uml2-rtf@omg.org; ocl2-rtf@omg.org Cc: issues@omg.org Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Mariano, thanks. Are you asserting that Integer[1] and Integer[0..1] are distinct types in OCL? -- Steve From: mariano.belaunde@orange-ftgroup.com [mailto:mariano.belaunde@orange-ftgroup.com] Sent: 28 October 2010 15:17 To: Steve Cook; ed-s@modeldriven.com; uml2-rtf@omg.org; ocl2-rtf@omg.org Cc: issues@omg.org Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Steve, >>> is there any difference between a UML property typed as Integer[1] and one typed as Integer[0..1]? Yes there is an important difference. In the first case the attribute need to have a value, and this value need to be a Integer (null is not a valid value) In the second case it is valid not to provide a value for the attribute. In OCL navigating a attribute that has no assigned value results in a 'null' value, but this does not mean that the value of the attribute is null (the navigation expression is null, not the attribute value, which is simply not specified) . Regarding the exact meaning of statement "OclVoid conforms to all types", maybe this needs some clarification or revision. Mariano -------------------------------------------------------------------------------- De : Steve Cook [mailto:Steve.Cook@microsoft.com] Envoyé jeudi 28 octobre 2010 15:59 À: Ed Seidewitz; uml2-rtf@omg.org; ocl2-rtf@omg.org Cc : issues@omg.org Objet : RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Ed >Isn.t it nice that now that we are all looking closely at UML semantics we have so many to choose from? Yes. Great. If OclVoid conforms to all types, so null is a valid member of any type, is there any difference between a UML property typed as Integer[1] and one typed as Integer[0..1]? Or do you see this as an explicit divergence between UML semantics and OCL semantics, where UML allows null to be a valid member of Integer[0..1] but not Integer[1]? If the latter, it.s a bit of a joke using OCL to define UML operations and constraints. -- Steve From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 28 October 2010 14:48 To: Steve Cook; uml2-rtf@omg.org; ocl2-rtf@omg.org Cc: issues@omg.org Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Steve . In the OCL 2.2 spec, Subclause 7.5.3, under .Navigation over Associations with Multiplicity Zero or One., it says: .Because the multiplicity of the role manager is one, self.manager is an object of type Person. Such a single object can be used as a Set as well. It then behaves as if it is a Set containing the single object. The usage as a set is done through the arrow followed by a property of Set.. While it doesn.t seem to say anything explicitly in the spec about non-association end properties with multiplicity 0..1, presumably the semantics are the same. That is, in the OCL type system, the type of such an association end is not explicit a collection, but a value of the association end may be treated in an expression as being a set with at most one member (so one can, e.g., check for emptiness using self.manager->isEmpty()), which is consistent with UML semantics. In OCL 2.2 Subclause 8.2, under .VoidType. it says: .VoidType represents a type that conforms to all types. The only instance of VoidType is OclVoid, which is further defined in the standard library. Furthermore OclVoid has exactly one instance called null - corresponding to the UML NullLiteral [sic] literal specification - and representing the absence of value. Note that in contrast with OclInvalid null is a valid value and as such can be owned by collections.. In the UML 2.3 spec, Subclause 7.3.28, it simply says that .A literal null specifies the lack of a value,. which is the vague semantics that is echoed above in the OCL spec. However, to OCL 2.2 spec further elaborates on OclVoid in Subclause 11.2.3, where it notes that: .However, by virtue of the implicit conversion to a collection literal, an expression evaluating to null can be used as source of collection operations (such as .isEmpty.). If the source is the null literal, it is implicitly converted to Bag{}.. Thus, the OclVoid instance .null. is a distinguished value in OCL semantics, it is effectively equivalent to Bag{} in usage. This seems consistent with the phrase .lack of a value. used in the UML spec, though OclVoid is itself only defined in the OCL spec (as are all OCL collection types, too, for that matter). Note also that, in fUML, a value specification action with a null literal produces a null token . a token that holds no values . when it fires, which is the activity semantics equivalent of the empty set or .lack of a value.. In Alf, the notation .null. is considered equivalent to .any[]{}., that is, an untyped empty sequence, which, as a sequence construction expression, has a special mapping to a value specification with a null literal, giving it the fUML semantics (as would be expected for Alf). Isn.t it nice that now that we are all looking closely at UML semantics we have so many to choose from? -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, October 28, 2010 8:43 AM To: uml2-rtf@omg.org; ocl2-rtf@omg.org Cc: issues@omg.org Subject: Vagueness about meaning of 0..1 multiplicity in OCL and UML In the UML spec especially around the area of MultiplicityElement and ValueSpecification there are numerous types for operation results declared as [Integer] etc. These are freely interpreted as being both sets and integers, both in the way they are used: lowerBound = if lowerValue->isEmpty() then 1 else lowerValue.integerValue() endif and in the way they are constructed: integerValue = Set{} This notation [Integer] appears to be a shorthand for either Set(Integer) or Integer[0..1]. In C# I would call this type Nullable or just int?; but I don.t believe that such a type formally exists in OCL. OCL has the value OclVoid, which is supposed to conform to all types. Is OclVoid semantically equivalent to Set{}? If OclVoid conforms to all types, is there any difference semantically between an attribute declared as multiplicity [1] and one declared as multiplicity [0..1]? If there is no difference, this seriously contradicts my expectations of what multiplicity means. -- Steve Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Date: Thu, 28 Oct 2010 15:25:06 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Vagueness about meaning of 0..1 multiplicity in OCL and UML Thread-Index: Act2nWG9nHt7ZdhnR6ep7Ws1giycVgABdsJAAAECqsAAAIKyAAAAaaGwAAA8CYAAC1wdEAAAgAhQAAAfM9AAAHeawAADmiNg From: "Pete Rivett" To: "Ed Seidewitz" , "Wartik, Steven P \"Steve\"" Cc: , Ø For example, a create object action always creates an object with empty attributes, whatever their multiplicity Not for the attributes that have default values. But you didn.t address Steve.s question about whether Null is counted as a value to satisfy the multiplicity constraint. I.d say .no. since LiteralNull is defined as .the lack of a value.. And, a related question of my own, is there any difference between unset() and assigning the value Null to an attribute? Again I.d say .no.. Furthermore I.d say that .null. and .empty. are interchangeable. However ValueSpecification::isNull needs a bit more explanation: we have in the Semantics that .A value specification yields zero or more values.. But the definition of the isNull() operation is not explicit that it equates to zero values. And we have other sloppy sentences such as in 11.3.2 which includes ..the result is a null value if a change event occurrence or a call event occurrence is accepted.. Which is a contradiction in terms if we take the definition that null is the absence of a value! And 11.3.33 has .Note that, if there are no matching links, then the action produces a single null token on its output pin.. (presumably this is a token with no associated value but this should be clearer) Likewise 11.3.37. 12.3.4 later clarifies this with: .A data token with no value in is called the null token... Which is OK but is inconsistent with .a null token. used earlier: is there a single unique null token or many? Based on the following sentences I think the word .the. should be replaced. But several later sections use .the null token.. Pete From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Thursday, October 28, 2010 1:39 PM To: Wartik, Steven P "Steve" Cc: uml2-rtf@omg.org; ocl2-rtf@omg.org Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Steve . An instantiation of an attribute with multiplicity 1..1 and no value is invalid, not impossible. Instantiations of model elements can exist but be invalid, just like model elements themselves can exist and be ill formed (i.e., violate one of the constraints given in the spec). This is not just a matter of .common sense., though; it is a clear violation of an explicit constraint given in the model. However, UML semantics are loose in general on when and how constraints in a model are actually enforced. For example, a create object action always creates an object with empty attributes, whatever their multiplicity. However, if the object is created as part of a constructor operation, then mandatory attributes can be filled in before the end of that operation, so that all multiplicity constraints are satisfied when the new object is returned by the operation. But this is not explicitly .required. by the UML semantics . it is effectively a modeler obligation to be self-consistent with the constraints the modeler puts into the model. So, there is a clear definition of what it means for multiplicity, or any other constraint, to be violated at any point in time in an instantiation of a UML model. However, such in instantiation is simply no longer a valid interpretation of the model. But, in terms of execution semantics, there are currently no run-time .consequences. for such constraint violations. A model execution tool could certainly provide a capability to indicate when multiplicity (or other constraint) violations have occurred, but it is not currently obligated to in order to conform to the foundational UML execution semantics. -- Ed -------------------------------------------------------------------------------- From: Wartik, Steven P "Steve" [mailto:swartik@ida.org] Sent: Thursday, October 28, 2010 4:10 PM To: Ed Seidewitz Cc: uml2-rtf@omg.org; ocl2-rtf@omg.org Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Ed, Yes, but what if I explicitly assign a null value to an attribute? Then it has a value, just not one that common sense would say is appropriate to the type. Steve From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Thursday, October 28, 2010 4:06 PM To: Wartik, Steven P "Steve" Cc: uml2-rtf@omg.org; ocl2-rtf@omg.org Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Steve . In the UML 2.3 spec, Subclause 7.3.32 MultiplicityElement, it says: .If a MultiplicityElement specifies a multivalued multiplicity, then an instantiation of this element has a collection of values. The multiplicity is a constraint on the number of values that may validly occur in that set.. So, if a multiplicity element has a number of values that violates the multiplicity constraint, that is invalid. -- Ed -------------------------------------------------------------------------------- From: Wartik, Steven P "Steve" [mailto:swartik@ida.org] Sent: Thursday, October 28, 2010 3:53 PM To: Ed Seidewitz; Steve Cook; mariano.belaunde@orange-ftgroup.com; uml2-rtf@omg.org; ocl2-rtf@omg.org Cc: issues@omg.org Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Ed, Steve, Mariano, Pardon an obtuse question, but where is it written that a UML model is not well formed if an attribute has multiplicity 1 and a null value? I have made cursory searches for this constraint in the past and have never located it. Steve Wartik From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: Thursday, October 28, 2010 10:36 AM To: Steve Cook; mariano.belaunde@orange-ftgroup.com; uml2-rtf@omg.org; ocl2-rtf@omg.org Cc: issues@omg.org Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Steve, Mariano . First of all, as noted in my previous message (which leapfrogged Mariano.s last one), neither .Integer[1]. not .Integer[0..1]. are actually types in either UML or OCL. In UML, multiplicity is not formally part of the type . it is an additional cardinality constraint given on multiplicity elements, and there are typed elements in UML that are not multiplicity elements (such as object nodes other than pins in activities). Multiplicity is not part of the OCL type system at all. In OCL, Integer and Set(Integer) are formally separate types. However, an expression of type Integer in OCL can be treated as a set of at most one member, so it.s effective type is essentially a constrained Set(Integer), equivalent to a type/multiplicity of Integer[0..1] in UML. However, as Mariano notes, having a multiplicity of 1 on an attribute places an additional constraint on that attribute . it must have a value. In an OCL expression of the form .x.a = y., where the attribute .a. has multiplicity 1, the OCL subexpression y may evaluate to a null value . but x.a can simply never equal such a value, since the UML model requires .a. it to have a value. Thus, in any well-formed instance of the UML model, the OCL equality must be false. Finally, I think the statement .OclVoid conforms to all types. is fine, within the context of OCL semantics. It is consistent with any OCL expression of any type effectively having, in UML terms, a multiplicity lower bound of 0 and the implicit conversion of a .null. value to .Bag{}.. -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, October 28, 2010 10:23 AM To: mariano.belaunde@orange-ftgroup.com; Ed Seidewitz; uml2-rtf@omg.org; ocl2-rtf@omg.org Cc: issues@omg.org Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Mariano, thanks. Are you asserting that Integer[1] and Integer[0..1] are distinct types in OCL? -- Steve From: mariano.belaunde@orange-ftgroup.com [mailto:mariano.belaunde@orange-ftgroup.com] Sent: 28 October 2010 15:17 To: Steve Cook; ed-s@modeldriven.com; uml2-rtf@omg.org; ocl2-rtf@omg.org Cc: issues@omg.org Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Steve, >>> is there any difference between a UML property typed as Integer[1] and one typed as Integer[0..1]? Yes there is an important difference. In the first case the attribute need to have a value, and this value need to be a Integer (null is not a valid value) In the second case it is valid not to provide a value for the attribute. In OCL navigating a attribute that has no assigned value results in a 'null' value, but this does not mean that the value of the attribute is null (the navigation expression is null, not the attribute value, which is simply not specified) . Regarding the exact meaning of statement "OclVoid conforms to all types", maybe this needs some clarification or revision. Mariano -------------------------------------------------------------------------------- De : Steve Cook [mailto:Steve.Cook@microsoft.com] Envoyé jeudi 28 octobre 2010 15:59 À: Ed Seidewitz; uml2-rtf@omg.org; ocl2-rtf@omg.org Cc : issues@omg.org Objet : RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Ed >Isn.t it nice that now that we are all looking closely at UML semantics we have so many to choose from? Yes. Great. If OclVoid conforms to all types, so null is a valid member of any type, is there any difference between a UML property typed as Integer[1] and one typed as Integer[0..1]? Or do you see this as an explicit divergence between UML semantics and OCL semantics, where UML allows null to be a valid member of Integer[0..1] but not Integer[1]? If the latter, it.s a bit of a joke using OCL to define UML operations and constraints. -- Steve From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 28 October 2010 14:48 To: Steve Cook; uml2-rtf@omg.org; ocl2-rtf@omg.org Cc: issues@omg.org Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Steve . In the OCL 2.2 spec, Subclause 7.5.3, under .Navigation over Associations with Multiplicity Zero or One., it says: .Because the multiplicity of the role manager is one, self.manager is an object of type Person. Such a single object can be used as a Set as well. It then behaves as if it is a Set containing the single object. The usage as a set is done through the arrow followed by a property of Set.. While it doesn.t seem to say anything explicitly in the spec about non-association end properties with multiplicity 0..1, presumably the semantics are the same. That is, in the OCL type system, the type of such an association end is not explicit a collection, but a value of the association end may be treated in an expression as being a set with at most one member (so one can, e.g., check for emptiness using self.manager->isEmpty()), which is consistent with UML semantics. In OCL 2.2 Subclause 8.2, under .VoidType. it says: .VoidType represents a type that conforms to all types. The only instance of VoidType is OclVoid, which is further defined in the standard library. Furthermore OclVoid has exactly one instance called null - corresponding to the UML NullLiteral [sic] literal specification - and representing the absence of value. Note that in contrast with OclInvalid null is a valid value and as such can be owned by collections.. In the UML 2.3 spec, Subclause 7.3.28, it simply says that .A literal null specifies the lack of a value,. which is the vague semantics that is echoed above in the OCL spec. However, to OCL 2.2 spec further elaborates on OclVoid in Subclause 11.2.3, where it notes that: .However, by virtue of the implicit conversion to a collection literal, an expression evaluating to null can be used as source of collection operations (such as .isEmpty.). If the source is the null literal, it is implicitly converted to Bag{}.. Thus, the OclVoid instance .null. is a distinguished value in OCL semantics, it is effectively equivalent to Bag{} in usage. This seems consistent with the phrase .lack of a value. used in the UML spec, though OclVoid is itself only defined in the OCL spec (as are all OCL collection types, too, for that matter). Note also that, in fUML, a value specification action with a null literal produces a null token . a token that holds no values . when it fires, which is the activity semantics equivalent of the empty set or .lack of a value.. In Alf, the notation .null. is considered equivalent to .any[]{}., that is, an untyped empty sequence, which, as a sequence construction expression, has a special mapping to a value specification with a null literal, giving it the fUML semantics (as would be expected for Alf). Isn.t it nice that now that we are all looking closely at UML semantics we have so many to choose from? -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, October 28, 2010 8:43 AM To: uml2-rtf@omg.org; ocl2-rtf@omg.org Cc: issues@omg.org Subject: Vagueness about meaning of 0..1 multiplicity in OCL and UML In the UML spec especially around the area of MultiplicityElement and ValueSpecification there are numerous types for operation results declared as [Integer] etc. These are freely interpreted as being both sets and integers, both in the way they are used: lowerBound = if lowerValue->isEmpty() then 1 else lowerValue.integerValue() endif and in the way they are constructed: integerValue = Set{} This notation [Integer] appears to be a shorthand for either Set(Integer) or Integer[0..1]. In C# I would call this type Nullable or just int?; but I don.t believe that such a type formally exists in OCL. OCL has the value OclVoid, which is supposed to conform to all types. Is OclVoid semantically equivalent to Set{}? If OclVoid conforms to all types, is there any difference semantically between an attribute declared as multiplicity [1] and one declared as multiplicity [0..1]? If there is no difference, this seriously contradicts my expectations of what multiplicity means. -- Steve Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Date: Thu, 28 Oct 2010 23:27:02 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Vagueness about meaning of 0..1 multiplicity in OCL and UML Thread-Index: Act2nWG9nHt7ZdhnR6ep7Ws1giycVgABdsJAAAECqsAAAIKyAAAAaaGwAAA8CYAAC1wdEAAAgAhQAAAfM9AAAHeawAADmiNgAArO+hA= From: "Ed Seidewitz" To: "Pete Rivett - Adaptive" Cc: , , "Wartik, Steven P \"Steve\"" Pete . See below. -------------------------------------------------------------------------------- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Thursday, October 28, 2010 6:25 PM To: Ed Seidewitz; Wartik, Steven P "Steve" Cc: uml2-rtf@omg.org; ocl2-rtf@omg.org Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Ø For example, a create object action always creates an object with empty attributes, whatever their multiplicity Not for the attributes that have default values. [EVS] Actually, in UML 2.3 Subclause 11.3.16 Create Object Action it says: .The new object is created, and the classifier of the object is set to the given classifier. The new object is returned as the value of the action. The action has no other effect. In particular, no behaviors are executed, no initial expressions are evaluated, and no state machine transitions are triggered. The new object has no structural feature values and participates in no links.. Default value (.initial.) expressions are not evaluated and the new object has .no structural feature [attribute] values.. It is again a modeler (or tool) responsibility to ensure that higher-level default value semantics are realized in terms of lower-level action semantics. It was an explicit decision in the semantics of create object action (for better or for worse) that it only creates the object, nothing else, and that anything further required by the class specification (such as setting attributes or starting a classifier behavior) must be represented explicitly by additional actions (e.g., add structural feature value or start object behavior actions). But you didn.t address Steve.s question about whether Null is counted as a value to satisfy the multiplicity constraint. I.d say .no. since LiteralNull is defined as .the lack of a value.. [EVS] I did imply this in my original response to Steve.s message. .null. is not a value in UML semantics, it is an empty set of values. Any further sloppiness in the spec on this can hopefully be cleaned up in UML 2.5. And, a related question of my own, is there any difference between unset() and assigning the value Null to an attribute? Again I.d say .no.. Furthermore I.d say that .null. and .empty. are interchangeable. However ValueSpecification::isNull needs a bit more explanation: we have in the Semantics that .A value specification yields zero or more values.. But the definition of the isNull() operation is not explicit that it equates to zero values. And we have other sloppy sentences such as in 11.3.2 which includes ..the result is a null value if a change event occurrence or a call event occurrence is accepted.. Which is a contradiction in terms if we take the definition that null is the absence of a value! And 11.3.33 has .Note that, if there are no matching links, then the action produces a single null token on its output pin.. (presumably this is a token with no associated value but this should be clearer) Likewise 11.3.37. 12.3.4 later clarifies this with: .A data token with no value in is called the null token... Which is OK but is inconsistent with .a null token. used earlier: is there a single unique null token or many? Based on the following sentences I think the word .the. should be replaced. But several later sections use .the null token.. Pete X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkEHAC8IykxUXebr/2dsb2JhbACBQ585WHG8XAKDC4I7BA Date: Fri, 29 Oct 2010 07:36:37 +0100 From: Ed Willink User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5 To: "Willink, Ed" CC: "'Steve Cook'" , Ed Seidewitz , uml2-rtf@omg.org, ocl2-rtf@omg.org, issues@omg.org Subject: Collection kind deduction [was Vagueness about meaning of 0..1 multiplicity in OCL and UML] Hi The practical problems of resolving the collection kind in anObject -> feature may vanish once the OrderedSet operations are fully aligned with Set, perhaps by allocating operations to abstract intermediate OrderedCollection, UnOrderedCollection, UniqueCollection and NonUniqueCollection classes. The practical problems are that UML defaults are [1..1] {unique}, but Ecore defaults are [0..1] {ordered, unique}. Therefore for UML, a collection of anObject is a Set by default, but for Ecore it is an OrderedSet. Once OrderedSet has all reasonable Set operations, users of Ecore meta-models should not be inconvenienced if OCL specifies that the collection kind is determined by the singleton object's ordering and uniqueness. Regards Ed Willink On 28/10/2010 15:29, Willink, Ed wrote: Hi In OCL I think, An Integer[1] may have integer values, null or invalid, of which only integer values are well-formed. An Integer[0..1] may have integer values, null or invalid, of which integer values and null are well-formed. A validation too may therefore enforce no-null for Integer[1]. [There is no Integer[0..1] in OCL, this is just what OCL obtains from a meta-model, whose tooling MOF/Ecore may reify it as object or collection.] --- "Because the multiplicity of the role manager is one, self.manager is an object of type Person. Such a single object can be used as a Set as well. It then behaves as if it is a Set containing the single object. The usage as a set is done through the arrow followed by a property of Set." There are outstanding OCL issues here, some of contradiction more of underspecification. I see the underlying (statically analyzed) semantics for anObject -> feature as creation of a collection of anObject followed by navigation involving a collection feature (or iteration). If anObject is null, the collection is empty. The exact kind of the collection is a problem; the OCL 2.2 specification variously specifies a Set or a Bag. Set is more useful since it has more operations, perhaps Bag is more logical. But from a UML perspective the singleton object has an associated ordering and uniqueness so this could/should define the collection kind. Unfortunately existing tools, particularly Ecore, give surprising defaults for singletons which noone has ever worried about, so if OCL suddenly gave them significance, users would be surprised that many existing models behave strangely. Regards Ed Willink -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: 28 October 2010 14:59 To: Ed Seidewitz; uml2-rtf@omg.org; ocl2-rtf@omg.org Cc: issues@omg.org Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Ed >Isn't it nice that now that we are all looking closely at UML semantics we have so many to choose from? Yes. Great. If OclVoid conforms to all types, so null is a valid member of any type, is there any difference between a UML property typed as Integer[1] and one typed as Integer[0..1]? Or do you see this as an explicit divergence between UML semantics and OCL semantics, where UML allows null to be a valid member of Integer[0..1] but not Integer[1]? If the latter, it's a bit of a joke using OCL to define UML operations and constraints. -- Steve From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: 28 October 2010 14:48 To: Steve Cook; uml2-rtf@omg.org; ocl2-rtf@omg.org Cc: issues@omg.org Subject: RE: Vagueness about meaning of 0..1 multiplicity in OCL and UML Steve - In the OCL 2.2 spec, Subclause 7.5.3, under "Navigation over Associations with Multiplicity Zero or One", it says: "Because the multiplicity of the role manager is one, self.manager is an object of type Person. Such a single object can be used as a Set as well. It then behaves as if it is a Set containing the single object. The usage as a set is done through the arrow followed by a property of Set." While it doesn't seem to say anything explicitly in the spec about non-association end properties with multiplicity 0..1, presumably the semantics are the same. That is, in the OCL type system, the type of such an association end is not explicit a collection, but a value of the association end may be treated in an expression as being a set with at most one member (so one can, e.g., check for emptiness using self.manager->isEmpty()), which is consistent with UML semantics. In OCL 2.2 Subclause 8.2, under "VoidType" it says: "VoidType represents a type that conforms to all types. The only instance of VoidType is OclVoid, which is further defined in the standard library. Furthermore OclVoid has exactly one instance called null - corresponding to the UML NullLiteral [sic] literal specification - and representing the absence of value. Note that in contrast with OclInvalid null is a valid value and as such can be owned by collections." In the UML 2.3 spec, Subclause 7.3.28, it simply says that "A literal null specifies the lack of a value," which is the vague semantics that is echoed above in the OCL spec. However, to OCL 2.2 spec further elaborates on OclVoid in Subclause 11.2.3, where it notes that: "However, by virtue of the implicit conversion to a collection literal, an expression evaluating to null can be used as source of collection operations (such as 'isEmpty'). If the source is the null literal, it is implicitly converted to Bag{}." Thus, the OclVoid instance "null" is a distinguished value in OCL semantics, it is effectively equivalent to Bag{} in usage. This seems consistent with the phrase "lack of a value" used in the UML spec, though OclVoid is itself only defined in the OCL spec (as are all OCL collection types, too, for that matter). Note also that, in fUML, a value specification action with a null literal produces a null token - a token that holds no values - when it fires, which is the activity semantics equivalent of the empty set or "lack of a value". In Alf, the notation "null" is considered equivalent to "any[]{}", that is, an untyped empty sequence, which, as a sequence construction expression, has a special mapping to a value specification with a null literal, giving it the fUML semantics (as would be expected for Alf). Isn't it nice that now that we are all looking closely at UML semantics we have so many to choose from? -- Ed -------------------------------------------------------------------------------- From: Steve Cook [mailto:Steve.Cook@microsoft.com] Sent: Thursday, October 28, 2010 8:43 AM To: uml2-rtf@omg.org; ocl2-rtf@omg.org Cc: issues@omg.org Subject: Vagueness about meaning of 0..1 multiplicity in OCL and UML In the UML spec especially around the area of MultiplicityElement and ValueSpecification there are numerous types for operation results declared as [Integer] etc. These are freely interpreted as being both sets and integers, both in the way they are used: lowerBound = if lowerValue->isEmpty() then 1 else lowerValue.integerValue() endif and in the way they are constructed: integerValue = Set{} This notation [Integer] appears to be a shorthand for either Set(Integer) or Integer[0..1]. In C# I would call this type Nullable or just int?; but I don't believe that such a type formally exists in OCL. OCL has the value OclVoid, which is supposed to conform to all types. Is OclVoid semantically equivalent to Set{}? If OclVoid conforms to all types, is there any difference semantically between an attribute declared as multiplicity [1] and one declared as multiplicity [0..1]? If there is no difference, this seriously contradicts my expectations of what multiplicity means. -- Steve Please consider the environment before printing a hard copy of this e-mail. The information contained in this e-mail is confidential. It is intended only for the stated addressee(s) and access to it by any other person is unauthorised. If you are not an addressee, you must not disclose, copy, circulate or in any other way use or rely on the information contained in this e-mail. Such unauthorised use may be unlawful. If you have received this e-mail in error, please inform us immediately on +44 (0)118 986 8601 and delete it and all copies from your system. Thales Research and Technology (UK) Limited. A company registered in England and Wales. Registered Office: 2 Dashwood Lang Road, The Bourne Business Park, Addlestone, Weybridge, Surrey KT15 2NX. Registered Number: 774298 Thales UK Limited. A company registered in England and Wales. Registered Office: 2 Dashwood Lang Road, The Bourne Business Park, Addlestone, Weybridge, Surrey KT15 2NX. Registered Number: 868273 -------------------------------------------------------------------------------- No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1153 / Virus Database: 424/3223 - Release Date: 10/27/10