Object Constraint Language Avatar
  1. OMG Specification

Object Constraint Language — All Issues

  • Acronym: OCL
  • Issues Count: 25
  • Description: All Issues
Open Closed All
All Issues

Issues Summary

Key Issue Reported Fixed Disposition Status
OCL25-198 Inconsistent OclVoid::oclAsType return OCL 2.3.1 open
OCL25-154 Introduce a Safe Navigation Operator OCL 2.3.1 open
OCL25-197 Indaequate Issue 15836 resultion of negative CollectionRange OCL 2.3.1 open
OCL25-119 Align OCL with out/inout UML Operation Parameters OCL 2.3.1 open
OCL25-118 Align OCL bodyExpression and UML bodyCondition OCL 2.3.1 open
OCL25-46 Complete OCL document must be a Package OCL 2.3.1 open
OCL25-23 How does Set distinguish duplicate values? OCL 2.3.1 open
OCL25-5 Support zero and multiple context invariants OCL 2.3.1 open
OCL25-6 Unify @pre, ^, ^^, ? as extensibility mechanisms OCL 2.3.1 open
OCL25-2 StateSpec for oclInState() OCL 2.3.1 open
OCL25-1 oclInState instead of oclIsInState OCL 2.3.1 open
SYSML14-49 Metamodel error in 14447 and 18407 OCL 2.3.1 SysML 1.4 Resolved closed
OCL24-13 Problems with OCL definition of Package::makesVisible OCL 2.3.1 OCL 2.4 Resolved closed
OCL24-12 Introduce selectByKind and selectByType operations OCL 2.3.1 OCL 2.4 Resolved closed
OCL24-11 Collection::min/max accumulator initialized as self.first() OCL 2.3.1 OCL 2.4 Resolved closed
OCL24-10 Collection::any() violates precondition if the collection is empty OCL 2.3.1 OCL 2.4 Resolved closed
OCL24-9 Inconsistent inclusion of source in closure results OCL 2.3.1 OCL 2.4 Resolved closed
OCL24-8 Clarify invalid propgation/conformance priority OCL 2.3.1 OCL 2.4 Resolved closed
OCL24-7 OclAny::oclAsType postcondition implies type change OCL 2.3.1 OCL 2.4 Resolved closed
OCL24-6 any iteration unsuitable for null Collection content OCL 2.3.1 OCL 2.4 Resolved closed
OCL24-5 non(not(X)) should be X OCL 2.3.1 OCL 2.4 Resolved closed
OCL24-4 Navigation from Association Classes does not conform to UML 2.4.1 OCL 2.3.1 OCL 2.4 Resolved closed
OCL24-3 ISO has changed the following normative references to its documents OCL 2.3.1 OCL 2.4 Resolved closed
OCL24-2 OCL String::indexOf OCL 2.3.1 OCL 2.4 Resolved closed
OCL24-1 OCL 2.3 OclInvalid::= is vague OCL 2.3.1 OCL 2.4 Resolved closed

Issues Descriptions

Inconsistent OclVoid::oclAsType return

  • Key: OCL25-198
  • Legacy Issue Number: 19750
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    7.4.6 states: If the actual type of the object, at evaluation time, is not
    a subtype of the type to which it is re-typed, then the result of oclAsType is invalid.

    7.5.8 states: self.oclAsType(A).p1 – accesses the p1 property defined in A - this is incompatible with the no-class-change-to-A so A::p1 is not available for null.

    But the normative 11.3.2 states: oclAsType(type : Classifier) : T
    Evaluates to self.

    The OCL 2.4 contribution to 11.3.2 was a typo. It should be "evaluates to invalid".

  • Reported: OCL 2.3.1 — Tue, 21 Apr 2015 04:00 GMT
  • Updated: Wed, 5 Jan 2022 15:34 GMT

Introduce a Safe Navigation Operator

  • Key: OCL25-154
  • Legacy Issue Number: 18516
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    Languages such as Groovy have found it helpful to intrioduce the safe navigation operator ?: so that navigation over null yields null rather than a problem (invalid in OCL).

    In OCL it could be a pure syntax sugar:

    (x?.y) = (if x == null then null else x.y endif)

    or perhaps an additional PropertyCallExp operator

  • Reported: OCL 2.3.1 — Fri, 1 Mar 2013 05:00 GMT
  • Updated: Sat, 19 Jan 2019 11:40 GMT

Indaequate Issue 15836 resultion of negative CollectionRange

  • Key: OCL25-197
  • Legacy Issue Number: 19820
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    Issue 15836 suggests that a negative CollectionRanbge should be invalid even after considering the Sequence

    {1..size}

    ->forAll idiom.

    The idiom clearly requires that a negative range gives an empty range.

  • Reported: OCL 2.3.1 — Mon, 27 Jul 2015 04:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

Align OCL with out/inout UML Operation Parameters

  • Key: OCL25-119
  • Legacy Issue Number: 18255
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    OCL 9.4.5 gives no recommendation on how to handle the multiple out capability of UML.

    Suggest that the mapping of a UML operation with out or inout parameters to an OCL operation do the following:

    remove all 'out' parameters from the OCL parameter list so that the OCL parameter list contains only 'in' and 'inout' parameters with 'read-only' behavior

    change the return type to a Tuple whose part-names and types are determined by the conventional 'result' and the 'out' and 'inout' parameters.

    It is also desirable to relax the upper multiplicity bound to allow multiple bodyExpressions in Complete OCL, one bodyExpression per returning parameter.

  • Reported: OCL 2.3.1 — Fri, 9 Nov 2012 05:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

Align OCL bodyExpression and UML bodyCondition

  • Key: OCL25-118
  • Legacy Issue Number: 18254
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    OCL 12.10 awaits alignment with the UML 2.0 metamodel.

    Consequently, the relationship between a result-valued OCL bodyExpression and a Boolean-valued UML bodyCondition is unspecified. A common pragmatic resolution has been to equate the two and ignore the Boolean-valued requirement of a UML Constraint.

    In order to accommodate prevailing practice and also support UML's multiple out/inouts, suggest:

    Reinterpret the grammar

    prePostOrBodyDeclCS ::= ‘body’ (simpleNameCS)? ‘:’ OclExpressionCS

    such that

    the simpleNameCS is the name of the return parameter with 'result' as the anonymous default

    OclExpressionCS is a result-valued bodyExpression if OclExpressionCS does not reference the simpleNameCS or its defgault.
    OclExpressionCS is a Boolean-valued bodyCondition if the return parameter is referenced.

    [Allow multiple body declarations.]

    Thus

    "body: ..." is a shortform of "body result: ..." which is a shortform for "body result: result = ..."

    and

    body: ...
    body A: ...
    body B: ...

    could be the specification of a UML operation

    f(out a : A, inout b : B, in c : C) : Z

  • Reported: OCL 2.3.1 — Fri, 9 Nov 2012 05:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

Complete OCL document must be a Package

  • Key: OCL25-46
  • Legacy Issue Number: 18539
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    In order for a UML model to import some Complete OCL for use in the model's constraints, a Complete OCL document must be a (derived) Package. Any tool can therefore import Complete OCL using its conventional metamodel import syntax; just needs per-tool support.

    Complete OCL documents must not conflict. For instance if MM imports COD1 for its own purposes and then your usage imports MM (and COD1) and also COD2, the declarations in COD2 may not introduce anything that requires re-analysis of the OCL expressions in MM or COD1; the only change to MM+COD1 execution may arise through additional derived virtual functions.

    Avoiding conflicts requires some strong WFRs.

    Once conflicts are avoided, Complete OCL documents can be pre-compiled and loaded in compiled form.

  • Reported: OCL 2.3.1 — Sun, 10 Mar 2013 05:00 GMT
  • Updated: Thu, 8 Oct 2015 14:11 GMT

How does Set distinguish duplicate values?

  • Key: OCL25-23
  • Legacy Issue Number: 19020
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    In 11.6.2: "It [Set] contains elements without duplicates."

    What is a duplicate?

    In 10.2.2.13 SetTypeValue
    "All elements belonging to a set value have unique values.
    self.element->isUnique(e : Element | e.value)"

    >From 11.9.1.3 isUnique, the basis of comparison is <>:
    forAll (x, y | (x.iter <> y.iter) implies (x.value <> y.value))

    But what is the Element::value to which "<>" is applied. It is far from clear that the semantics of the Element in Section 10 which is completely unrelated to MOF::Element leads to the obvious answer.

    Suggest adding the obvious WFR.

    context Set
    inv: forAll(x | self->count = 1)

    (count is already defined using "=")

    [And chnage 11.9.1.3 isUnique to use this much more readable formulation.]

  • Reported: OCL 2.3.1 — Wed, 23 Oct 2013 04:00 GMT
  • Updated: Thu, 8 Oct 2015 14:11 GMT

Support zero and multiple context invariants

  • Key: OCL25-5
  • Legacy Issue Number: 19127
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    A.5.1.5 suggests that an invariant may be specified for many contexts. The Complete OCL syntax does not support this.

    Many users like to write grandiose truths:

    context X
    inv: X.allInstances()->...

    These do not use the context and so naively increase the complexity from O(N) to O(N*N).

    Suggest allowing such constraints to be context-less constraints provided by the Package rather than a spurious Classifier.

  • Reported: OCL 2.3.1 — Wed, 27 Nov 2013 05:00 GMT
  • Updated: Thu, 8 Oct 2015 14:11 GMT

Unify @pre, ^, ^^, ? as extensibility mechanisms

  • Key: OCL25-6
  • Legacy Issue Number: 18882
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    The OCL expression syntax is difficult to extend for other purposes. The @pre postcondition operator, and the ,^,? tokens are examples of extension of the core syntax.

    Perhaps @pre could be generalized as an instance of an @token

    {....}

    suffix which could be parsed as an AnnotationExp for tooling to ignore but support extension for.

    Can more arbitrary punctuation such as ,^,?,#,% be generalized?

  • Reported: OCL 2.3.1 — Fri, 30 Aug 2013 04:00 GMT
  • Updated: Thu, 8 Oct 2015 14:11 GMT

StateSpec for oclInState()

  • Key: OCL25-2
  • Legacy Issue Number: 19825
  • Status: open  
  • Source: Anonymous
  • Summary:

    Please add that the StateSpec may include the names of Regions.

  • Reported: OCL 2.3.1 — Wed, 5 Aug 2015 04:00 GMT
  • Updated: Thu, 8 Oct 2015 14:11 GMT

oclInState instead of oclIsInState

  • Key: OCL25-1
  • Legacy Issue Number: 19824
  • Status: open  
  • Source: Anonymous
  • Summary:

    The name of the predefined property is "oclInState" according to chapter 7.6.9. In chapter 11.3.1 the name "oclIsInState" is used.

  • Reported: OCL 2.3.1 — Wed, 5 Aug 2015 04:00 GMT
  • Updated: Thu, 8 Oct 2015 14:11 GMT

Metamodel error in 14447 and 18407

  • Key: SYSML14-49
  • Legacy Issue Number: 18987
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    In the resolution to issue 14447 and 18407 in SysML 1.4 ballot 4, the metamodel figure is out of synch with the element descriptions, in particular for the source and target properties. The resolution to 18407 doesn't have revised text explaining when sourceContext and targetContext are needed.

  • Reported: OCL 2.3.1 — Fri, 4 Oct 2013 04:00 GMT
  • Disposition: Resolved — SysML 1.4
  • Disposition Summary:

    Modify the metamodels figures to align with the element description for
    DirectedRelationshipPropertyPath, and replace references to source and target
    classifiers to source and target contexts. Explain when they are needed.

  • Updated: Fri, 6 Mar 2015 23:16 GMT

Problems with OCL definition of Package::makesVisible

  • Key: OCL24-13
  • Legacy Issue Number: 18965
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Nearly a year ago we put the UML OCL through Eclipse OCL and were able to eliminate 'all' (many hundreds of) syntactic errors and many semantic errors. Not all semantic errors, because Eclipse OCL is steadily adding stronger WFRs. Since then the authors have been using Eclipse OCL in the guise of IBM RSA and the errors have stayed away. Final checks of the UML 2.5 candidate UML.xmi identified only one semantic error.

    Your report is marginal as a semantic error; perhaps a warning would be appropriate for the useless compare. I suspect an inadequacy in the Eclipse OCL determination of the application OCLAny::= specialization.

    Realistically UML 2.5 paves the way for the start of a virtuous circle as feedback identifies the outright functional errors that occur when validating real models and the much harder inadequacies where the constraints are too weak.

  • Reported: OCL 2.3.1 — Thu, 26 Sep 2013 04:00 GMT
  • Disposition: Resolved — OCL 2.4
  • Disposition Summary:

    issue already raised in the UML 2.6 RTF

  • Updated: Fri, 6 Mar 2015 23:16 GMT

Introduce selectByKind and selectByType operations

  • Key: OCL24-12
  • Legacy Issue Number: 18829
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    A very common 'idiom' in OCL expressions is

    sources->select(oclIsKindOf(T))>collect(oclAsType(T))>asSet()

    to select the sub-set of type T.

    This involves four library calls and requires T to be typed twice.

    In practice

    sources->select(oclIsKindOf(T)).oclAsType(T)

    may save one operation call at the expense of the wrong collection type.

    Suggest introduce

    sources->selectByKind(T)
    sources->selectByType(T)

    to simplify this oclIsKindOf/oclIsTypeOf usage.

  • Reported: OCL 2.3.1 — Sun, 21 Jul 2013 04:00 GMT
  • Disposition: Resolved — OCL 2.4
  • Disposition Summary:

    This is clearly useful:
    Acceleo (but not MOFM2T) provides "filter".
    The Dresden OCL team in http://gres.uoc.edu/OCL2011/pubs/ocl2011_submission_3.pdf suggest "selectByType" and note that QVTo provides "collectselect"
    "filter" is nice and short but fails to fulfill the expectation that the argument should be some general predicate not an unmentioned type.
    oclIsKindOf and oclIsTypeOf are already there and so unless they are to be changed, additions should be compatible and re-inforce the "KindOf"/"TypeOf" distinction..
    There are two distinct algorithms: exact type and polymorphic type so
    selectByType and selectByKind are consistent.
    selectByType clearly can include/exclude OclVoid at will.
    selectByKind probably doesn't want to include null elements even though null conforms to everything, so QVTo's collectselect exclusion is worth emulating.
    There seems no need to introduce rejectByKind and rejectByType too, since there is no associated type conversion; reject will do.
    The correct declarations should be:
    selectByKind(TT)(type : Metaclass(TT)) : Collection(TT);
    selectByType(TT)(type : Metaclass(TT)) : Collection(TT);
    These use an operation template type TT to model the type relationship between the returned Collection element type and the metatype provided as the operation argument. Unfortunately we cannot use this until OCL '2.5' aligns with UML templates and introduces templated Metaclasses.

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Collection::min/max accumulator initialized as self.first()

  • Key: OCL24-11
  • Legacy Issue Number: 18515
  • Status: closed  
  • Source: Universidad Nacional del Litoral ( Roberto Javier Godoy)
  • Summary:

    The accumulator in the definition of Collection::min and Collection::max is initialized as self.first().

    post: result = self->iterate( elem; acc : T = self.first() | acc.min(elem) )

    post: result = self->iterate( elem; acc : T = self.first() | acc.max(elem) )

    The accumulator should be initialized as self.asSequence()->first(), because Collection::first() is undefined.

  • Reported: OCL 2.3.1 — Fri, 1 Mar 2013 05:00 GMT
  • Disposition: Resolved — OCL 2.4
  • Disposition Summary:

    Nearly right.
    self is of course a Collection, so needs to be self->asSequence()>first(), or just self>any(true).

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Collection::any() violates precondition if the collection is empty

  • Key: OCL24-10
  • Legacy Issue Number: 18504
  • Status: closed  
  • Source: Universidad Nacional del Litoral ( Roberto Javier Godoy)
  • Summary:

    Section 11.9.1.4 states that "there must be at least one element fulfilling body, otherwise the result of this IteratorExp is null." And defines

    source->any(iterator|body) = source->select(iterator | body)>asSequence()>first()

    However

    let seq:Sequence<T>=source->select(body)->asSequence()
    in source->any(body)=seq->at(1)

    >From section 11.7.5

    context Sequence::first() : T
    post: result = self->at(1)

    context Sequence::at(i : Integer) : T
    pre : i >= 1 and i <= self->size()

    If there is no element fulfilling body, then seq is empty and the precondition of Sequence::at does not hold because 1 > seq->size().

    Related to: Issue 18125 [OCL 2.4]

  • Reported: OCL 2.3.1 — Tue, 26 Feb 2013 05:00 GMT
  • Disposition: Resolved — OCL 2.4
  • Disposition Summary:

    The 'equivalent' OCL of
    source->select(iterator | body)>asSequence()>first()
    returns invalid if no elements are selected, rather than null as the words say.
    As identified in Issue 18125, null could also be a valid value, so the words are clearly wrong.

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Inconsistent inclusion of source in closure results

  • Key: OCL24-9
  • Legacy Issue Number: 18464
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    "The returned collection of the closure iteration is an accumulation of the source, and the collections resulting from ..."

    incorrectly includes the source. The algorithm in 11.9.1 correctly includes the source only if the source is reached by some traversal from the source.

  • Reported: OCL 2.3.1 — Wed, 20 Feb 2013 05:00 GMT
  • Disposition: Resolved — OCL 2.4
  • Disposition Summary:

    No. The algorithm in 11.9.1 only adds the source to the result if the source was not already present. Since the anonRecurse starts with an empty result all sources are accumulated.
    Just need to polish the words to avoid similar misunderstandings in the future

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Clarify invalid propgation/conformance priority

  • Key: OCL24-8
  • Legacy Issue Number: 18437
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    There is a contradiction between invalid conform to anything and invalid always propagates for e.g.

    Sequence{}->first().oclIsKindOf(Class)

    oclIsKindOf uses the invalid input to return true.

    Invalid propagation should dominate giving invalid.

    This requires OclInvalid::oclIsKindOf, oclIsTypeOf, oclType, oclAsType overloads to explicitly return invalid.

  • Reported: OCL 2.3.1 — Mon, 11 Feb 2013 05:00 GMT
  • Disposition: Resolved — OCL 2.4
  • Disposition Summary:

    (A) It is clearly correct that OclVoid/OclInvalid conform to anything so that null/invalid can be used anywhere.
    (B) It is also clearly correct for navigation on null and invalid to be invalid so that bad results propagate.
    The above are not contradictory. The contradiction arises through the introduction of the oclIsInvalid() and oclIsUndefined() operations that may be used on null or invalid, despite (B).
    It would appear that oclIsInvalid() and oclIsUndefined() must be privileged to violate the strictness of (B). If so, are oclIsKindOf, oclIsTypeOf, oclType, oclAsType etc. also privileged?
    The specification can be clarified by making all oclXXX() operations privileged so that they can be used on null and invalid and defining their OclVoid and OclInvalid overloads explicitly.
    The affected text can be clarified to eliminate the accidental omission of operation calls for null and invalid.
    The affected text covers the DataType equality issue so the resolution of Issue 14918 is included

  • Updated: Fri, 6 Mar 2015 20:57 GMT

OclAny::oclAsType postcondition implies type change

  • Key: OCL24-7
  • Legacy Issue Number: 18319
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    post: (result = self) and result.oclIsTypeOf( t )

    requires oclAsType to change the type of self.

    The constraint should be:

    post: (result = self) and result.oclIsKindOf(t)

    [Review all usage of oclIsType() since it's nearly always wrong to use oclIsType rather than oclIsKindOf.]

  • Reported: OCL 2.3.1 — Fri, 14 Dec 2012 05:00 GMT
  • Disposition: Resolved — OCL 2.4
  • Disposition Summary:

    Should indeed be oclIsKindOf and the argument should be 'type' as in the signature.
    Reviewing other oclIsTypeOf uses identifies just one clear error in 8.2.1 since CollectionType has derived SetType and other types. Other usages seem to be either ok but inelegant since the type is a leaf type, or deliberate constraints for an invariant

  • Updated: Fri, 6 Mar 2015 20:57 GMT

any iteration unsuitable for null Collection content

  • Key: OCL24-6
  • Legacy Issue Number: 18125
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    The any() iteration is specified to return null in the event that no match is found. However null could also be the return of a successful match of null. e.g

    Sequence

    {null}

    ->any(s | s = null)

    Suggest: change the match-not-found return to invalid.

  • Reported: OCL 2.3.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — OCL 2.4
  • Disposition Summary:

    The resolution of Issue 18504 solves this too.
    Disposition: See issue 18504 for disposition

  • Updated: Fri, 6 Mar 2015 20:57 GMT

non(not(X)) should be X

  • Key: OCL24-5
  • Legacy Issue Number: 17531
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    In http://www.linkedin.com/redirect?url=http%3A%2F%2Fwww%2Ebrucker%2Ech%2Fprojects%2Fhol-ocl%2FFeatherweight-OCL%2Foutline%2Epdf&urlhash=vacm&_t=tracking_anet Burkhart Wol ff argues that lopgical consistency requires that not(not(X)) is X.

    OCL 2.3.x does not satisfy this for 'null'.

    Similary null and true = null not invalid ...

  • Reported: OCL 2.3.1 — Fri, 27 Jul 2012 04:00 GMT
  • Disposition: Resolved — OCL 2.4
  • Disposition Summary:

    Issue 14197 for OCL 2.3 rationalized the vague equivalences between undefined and null/invalid.
    In OCL 2.0, it was left for the implementer to determine how "not null" and "not invalid" were computed given the specification that "not undefined = undefined".
    In OCL 2.3, we have clarity: "not null = invalid" and "not invalid = invalid". However this leads to the identified inconsistency that "not not X = X" is not true for all X (not not null = invalid).
    The clarification of "not undefined" should have partitioned the two cases for "not undefined = undefined" so that "not null = null" and "not invalid = invalid"
    Similarly other logical operations involving null but not invalid should yield null rather than invalid results. "null and true = null", "null or false = null", "null xor false = null".
    We should extend this to the forAll and exists iterations that are defined as iterated and/or. Making the exists/forAll returns clear highlights that many iterator returns are only partially specified; these need expanding.
    Introduction of null highlights a redundancy in the non-standard implies postcondition: (not self) or (self and b) rather than the standard (not self) or b. The standard gives the consistent result "null implies true = true" whereas the current non-standard postcondition gives null. The non-standard postcondition is already wrong for invalid.
    The If expression specification words omit consideration of a non-valid condition; a null or invalid condition is of course invalid.
    For arithmetic operations there is an apparently free choice between two alternate consistent logics in which "1 + null = null" or "1 + null = invalid".
    "1 + null = null" is plausible if "null" denotes "don't know"; an object/value that exists but with unspecified value.
    "1 + null = invalid" is plausible if "null" denotes "missing"; the absence of an object/value.
    However UML provides the interpretation of "null" as "missing". UML-alignment of OCL therefore requires OCL to take the "1 + null = invalid" alternative, which is what the Issue 14197 clarification specified. So no change required for arithmetic operations.

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Navigation from Association Classes does not conform to UML 2.4.1

  • Key: OCL24-4
  • Legacy Issue Number: 17463
  • Status: closed  
  • Source: computer.org ( DI Florin Ioan Chertes)
  • Summary:

    The navigation from Association Classes does not conform to UML 2.4.1 because of 7.3.4 AssociationClass on page 44 UML Superstructure Specification, v2.4.1. the kind of navigation allowed by OCL is not allowed by UML, i.e. the navigation from the association class to the ends of the association is explicitly not allowed by UML but allowed by OCL. I see here a contradiction. I checked UML 2.1.2 from 2007 and in that UML this navigation from the association class the ends of the association was still allowed. I think that OCL 2.3.1 is not compatible with UML 2.4.2 from this point of view. Please tell me if this opinion is correct. If this contradiction that I remarked really exists than what to expect from the future: OCL or UML point of view?

  • Reported: OCL 2.3.1 — Sun, 1 Jul 2012 04:00 GMT
  • Disposition: Resolved — OCL 2.4
  • Disposition Summary:

    The apparent prohibition in UML 2.4.1 is not present in UML 2.5 Beta.
    The problem is a misunderstanding. OCL expressions are resolved at 'modeling-time' against the model and so are not restricted by visibility or any practical limitations that may occur at run-time.
    Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:57 GMT

ISO has changed the following normative references to its documents

  • Key: OCL24-3
  • Legacy Issue Number: 17306
  • Status: closed  
  • Source: Object Management Group ( Ms. Linda Heaton)
  • Summary:

    ISO 639 has been replaced by a six-part series. The new reference should be: ISO 639 (all parts)
    ISO 3166 has been replaced by a three part series. The new reference should be: ISO 3166 (all parts)
    ISO 10646 is new and this reference should be: ISO 10646:2011, Information technology - Universal Coded Character Set (UCS)

  • Reported: OCL 2.3.1 — Thu, 12 Apr 2012 04:00 GMT
  • Disposition: Resolved — OCL 2.4
  • Disposition Summary:

    yes

  • Updated: Fri, 6 Mar 2015 20:57 GMT

OCL String::indexOf

  • Key: OCL24-2
  • Legacy Issue Number: 17220
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    The description of String::indexOf() states "No string is a substring of the empty string.".

    This modifies the axiom that every string is a substring of itself. It would appear that the empty string has got confused with null.

    An extension of the library with startsWith and endsWith operations would require the modified axiom to be accommodated making corner cases equivalently strange.

    This modified axiom is not observed by other String libraries such as the java.lang.String.

    Suggest: Replace the text:

    "The empty string is considered to be a substring of every string but the empty string, at index 1. No string is a substring of the empty string."

    by

    "The empty string is a substring of every string at index 1 (and also at all other indexes)."

  • Reported: OCL 2.3.1 — Fri, 9 Mar 2012 05:00 GMT
  • Disposition: Resolved — OCL 2.4
  • Disposition Summary:

    yes

  • Updated: Fri, 6 Mar 2015 20:57 GMT

OCL 2.3 OclInvalid::= is vague

  • Key: OCL24-1
  • Legacy Issue Number: 16998
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    Issue 14197 finally resolved the semantiscs of OclInvalid, but the end result was that there is no OclInvalid section in 11.3. Add an 11.3.x for OclInvalid that enumerates all relevant OclInvalid behaviors; in particular = and <> return invalid for any invalid argument.

  • Reported: OCL 2.3.1 — Sat, 14 Jan 2012 05:00 GMT
  • Disposition: Resolved — OCL 2.4
  • Disposition Summary:

    Merged with Issue 18437.
    Disposition: See issue 18437 for disposition

  • Updated: Fri, 6 Mar 2015 20:57 GMT