Issue 15037: OCL 2.1 Section 10 problems (ocl2-rtf) Source: Model Driven Solutions (Dr. Edward Willink, ed(at)willink.me.uk) Nature: Uncategorized Issue Severity: Summary: Section 10 is suffering seriously from lack of update and review. The old AssociationClassCall/AssociationEndCall/ModelPropertyCall spellings are in use throughout. OrderedSetValue is omitted throughout. UnlimitedNaturalExpValue is omitted throughout. TypeExpEval is omitted throughout thereby avoiding tackling the irregular semantics of the oclIsKindOf argument. 'undefined' does not distinguish null and invalid and is variously undefined, void, UndefinedValue, OclVoidValue and UnspecifiedValue including a reference to UnspecifiedValueExp that does not exist. There should be just an OclVoidValue and an OclInvalidValue. OrderedSet is not used where elements are clearly unique e.g. Sequence(LocalSnapShot). OCL is regularly spelled ocl or Ocl as a non-word prefix. An Element::indexNr is imposed on all Collection elements. Surely a distinct OrderedCollectionValue intermediate value should use the stronger OrderedCollectionElement. It is not specified whether Element::indexNr indexes from 0 or 1 or indeed even monontonically. Figure 10.4 omits many {ordered}and {unique} constraints. Figure 10.4 omits LocalSnapShot.pred and succ. 10.2.1 Element assserts that Element is a tuple NameValueBinding. 10.2.1 OclMessageValue italicises the wrong use of 'name'. 10.2.2 LocalSnapShot[1] refers to ispre rather than isPre. 10.2.2 LocalSnapShot[2] asserts that the result of an implicit collect is a boolean (missing ->any). 10.2.2 ObjectValue omits the doubly-linked list validity constraint 10.2.2 TupleValue assserts that a NameValueBinding is an Element. 10.2.3 SequenceTypeValue omits a constraint on the sequential validity of Element.indexNr 10.2.3 LocalSnapShot uses notEmpty rather than nonEmpty() 10.3 para 2 refers to a non-existent OclEvaluation class 10.3 para 2 has erroneous figure references to 10.6,7 rather than 10.7,8 10.3.2 OperationCallExpEval relies on UML semantics, but fails to resolve UML's unspecified behavioural variation point on operator overload resolution. See Issue 15013. 10.3.2 OperationCallExpEval spells forAll as forall. 10.3.2 CollectionRangeEval uses isOclType(Sequence(Integer)). Any such use of collection types was invalid in OCL 2.0. Use of a collection type is not valid concrete syntax in OCL 2.1/2. The resolution of 10439 for OCL 2.3 provides concrete syntax support, but the semantics remains undefined although perhaps intuitively obvious. As separately raised isOclType etc are incorrect spellings. The x .. y syntax could be used to advantage in places such as 10.3.3 CollectionRangeEval. The explicit iterator is unnecessary in for instance 10.2.2 TupleValue. Figure 10.14 has layout problems. Figure 10.14 shows instances <-> model associations for both Concrete and Abstract classes. The model for derived classes should be marked as derived. 10.4.2 BooleanLiteralExpEval has an unresolved MOF/UML alignment. 10.4.2 EvalEnvironment has a missing constraint on uniqueness of binding names. 10.4.2 IfExpEval has missing and operators Generally: the constraints should be validated by an OCL checking tool. Resolution: Revised Text: Actions taken: February 4, 2010: received issue Discussion: End of Annotations:===== ronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEACCXaktUXeby/2dsb2JhbADYT4RMBA Date: Thu, 04 Feb 2010 17:45:27 +0000 From: Ed Willink User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 To: issues@omg.org Subject: OCL 2.1 Section 10 problems X-Plusnet-Relay: f52aa9a8338eff71c98568b4837e6707 Hi Juergen: in principle each of the problems below is a separate issue, some perhaps already reported. I think the jumbo issue can be dealt with by a jumbo resolution, so please just one Issue. Section 10 is suffering seriously from lack of update and review. The old AssociationClassCall/AssociationEndCall/ModelPropertyCall spellings are in use throughout. OrderedSetValue is omitted throughout. UnlimitedNaturalExpValue is omitted throughout. TypeExpEval is omitted throughout thereby avoiding tackling the irregular semantics of the oclIsKindOf argument. 'undefined' does not distinguish null and invalid and is variously undefined, void, UndefinedValue, OclVoidValue and UnspecifiedValue including a reference to UnspecifiedValueExp that does not exist. There should be just an OclVoidValue and an OclInvalidValue. OrderedSet is not used where elements are clearly unique e.g. Sequence(LocalSnapShot). OCL is regularly spelled ocl or Ocl as a non-word prefix. An Element::indexNr is imposed on all Collection elements. Surely a distinct OrderedCollectionValue intermediate value should use the stronger OrderedCollectionElement. It is not specified whether Element::indexNr indexes from 0 or 1 or indeed even monontonically. Figure 10.4 omits many {ordered}and {unique} constraints. Figure 10.4 omits LocalSnapShot.pred and succ. 10.2.1 Element assserts that Element is a tuple NameValueBinding. 10.2.1 OclMessageValue italicises the wrong use of 'name'. 10.2.2 LocalSnapShot[1] refers to ispre rather than isPre. 10.2.2 LocalSnapShot[2] asserts that the result of an implicit collect is a boolean (missing ->any). 10.2.2 ObjectValue omits the doubly-linked list validity constraint 10.2.2 TupleValue assserts that a NameValueBinding is an Element. 10.2.3 SequenceTypeValue omits a constraint on the sequential validity of Element.indexNr 10.2.3 LocalSnapShot uses notEmpty rather than nonEmpty() 10.3 para 2 refers to a non-existent OclEvaluation class 10.3 para 2 has erroneous figure references to 10.6,7 rather than 10.7,8 10.3.2 OperationCallExpEval relies on UML semantics, but fails to resolve UML's unspecified behavioural variation point on operator overload resolution. See Issue 15013. 10.3.2 OperationCallExpEval spells forAll as forall. 10.3.2 CollectionRangeEval uses isOclType(Sequence(Integer)). Any such use of collection types was invalid in OCL 2.0. Use of a collection type is not valid concrete syntax in OCL 2.1/2. The resolution of 10439 for OCL 2.3 provides concrete syntax support, but the semantics remains undefined although perhaps intuitively obvious. As separately raised isOclType etc are incorrect spellings. The x .. y syntax could be used to advantage in places such as 10.3.3 CollectionRangeEval. The explicit iterator is unnecessary in for instance 10.2.2 TupleValue. Figure 10.14 has layout problems. Figure 10.14 shows instances <-> model associations for both Concrete and Abstract classes. The model for derived classes should be marked as derived. 10.4.2 BooleanLiteralExpEval has an unresolved MOF/UML alignment. 10.4.2 EvalEnvironment has a missing constraint on uniqueness of binding names. 10.4.2 IfExpEval has missing and operators Generally: the constraints should be validated by an OCL checking tool. Regards Ed Willink