OCL 2.5 RTF Avatar
  1. OMG Issue

OCL25 — OCL 2.1 Section 10 problems

  • Key: OCL25-11
  • Legacy Issue Number: 15037
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • 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.

  • Reported: OCL 2.1 — Thu, 4 Feb 2010 05:00 GMT
  • Updated: Thu, 8 Oct 2015 14:11 GMT