Object Constraint Language Avatar
  1. OMG Specification

Object Constraint Language — All Issues

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

Issues Summary

Key Issue Reported Fixed Disposition Status
OCL23-40 toLowerCase referred to as toLower (similarly for toUpperCase) OCL 2.2 OCL 2.3 Resolved closed
OCL23-38 The opertion "collect" is confused with the operation "reject" OCL 2.2 OCL 2.3 Resolved closed
OCL23-37 OCL 2.3 Ballotted: Retracting resolutions for Issue 10439/13076 OCL 2.2 OCL 2.3 Resolved closed
OCL23-36 toLowerCase() declared as returning Integer OCL 2.2 OCL 2.3 Resolved closed
OCL23-35 Definition for symmetric difference is wrong OCL 2.2 OCL 2.3 Resolved closed
OCL23-34 the use of the keyword 'attr' OCL 2.2 OCL 2.3 Resolved closed
OCL23-33 OCL 2.2 UML Alignment of association names OCL 2.2 OCL 2.3 Resolved closed
OCL23-32 OCL 2.2 11.5.3 What is a locale? OCL 2.2 OCL 2.3 Resolved closed
OCL23-31 OCL 2.2 11.7.1 Why must + be commutative for Collection::sum() OCL 2.2 OCL 2.3 Resolved closed
OCL23-30 OCL 2.2 11.7.1 Why must + be associative for Collection::sum() OCL 2.2 OCL 2.3 Resolved closed
OCL23-29 String.equalsIgnoreCase(String) should result in Boolean OCL 2.2 OCL 2.3 Resolved closed
OCL23-28 OCL 2.1 11.2.3 Navigated Implicit Conversion to Collection Literal OCL 2.2 OCL 2.3 Resolved closed
OCL23-27 OCL 2.1 8.3.8 OclInvalid::allInstances OCL 2.2 OCL 2.3 Resolved closed
OCL23-26 OCL 2.1 11.2 Conflicting {OclVoid, OclInvalid}::{oclIsTypeOf, oclIsKindOf, oclAsType} semantics OCL 2.2 OCL 2.3 Resolved closed
OCL23-25 OCL 2.1 Implicit Conversion to Collection Literal OCL 2.2 OCL 2.3 Resolved closed
OCL23-24 OCL 2.1 11.2.5 Numeric = and <> operations should compare values rather than objects OCL 2.2 OCL 2.3 Resolved closed

Issues Descriptions

toLowerCase referred to as toLower (similarly for toUpperCase)

  • Key: OCL23-40
  • Legacy Issue Number: 15527
  • Status: closed  
  • Source: yahoo.com ( Scott Forbes)
  • Summary:

    In A.2.1.2 Operations on p193, toLowerCase is referred to as toLower "case translations are possible with toUpper and toLower" and again in Table A.1

    Also toUpperCase is referred to as toUpper in the same places

  • Reported: OCL 2.2 — Tue, 14 Sep 2010 04:00 GMT
  • Disposition: Resolved — OCL 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 17:59 GMT

The opertion "collect" is confused with the operation "reject"

  • Key: OCL23-38
  • Legacy Issue Number: 15980
  • Status: closed  
  • Source: gmail.com ( Fedor Ermishin)
  • Summary:

    "Reject" should be replaced with "collect" in the following line:
    "The value of the reject operation is the collection of the results of all the evaluations of expression-with-v."

  • Reported: OCL 2.2 — Mon, 24 Jan 2011 05:00 GMT
  • Disposition: Resolved — OCL 2.3
  • Disposition Summary:

    yes

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

OCL 2.3 Ballotted: Retracting resolutions for Issue 10439/13076

  • Key: OCL23-37
  • Legacy Issue Number: 15761
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    I am no longer happy with my resolution of 10439/13076 which provides a
    very high resolution LALR grammar. This is inefficient to emulate with
    LL and cannot provide the flexibility of configurable precedence. It
    will also be very difficult to accommodate a template parameter parse
    with similarly high precision. I now favour a low precision syntactic
    parse augmented by high precision disambiguation/semantic checks.

    If the high precision LALR grammar may need retraction, it seems
    undesirable to put it into 2.3 only to remove it in 2.4.

    Suggest retract the resolutions for OCL 2.3 and rewrite for OCL 2.4 once
    UML-alignment of templates has been accommodated

  • Reported: OCL 2.2 — Sat, 9 Oct 2010 04:00 GMT
  • Disposition: Resolved — OCL 2.3
  • Disposition Summary:

    No Data Available

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

toLowerCase() declared as returning Integer

  • Key: OCL23-36
  • Legacy Issue Number: 15528
  • Status: closed  
  • Source: yahoo.com ( Scott Forbes)
  • Summary:

    In section "11.4.3 String" on p145 toLowerCase() is declared as returning Integer, correct type is String

  • Reported: OCL 2.2 — Tue, 14 Sep 2010 04:00 GMT
  • Disposition: Resolved — OCL 2.3
  • Disposition Summary:

    No Data Available

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

Definition for symmetric difference is wrong

  • Key: OCL23-35
  • Legacy Issue Number: 15270
  • Status: closed  
  • Source: gmail.com ( Gustav Munkby)
  • Summary:

    symmetricDifference: is defined as (S1 u S2) - (S1 u S2), but this always yields the empty set. I believe the intended writing is (S1 u S2) - (S1 n S2).

  • Reported: OCL 2.2 — Tue, 1 Jun 2010 04:00 GMT
  • Disposition: Resolved — OCL 2.3
  • Disposition Summary:

    No Data Available

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

the use of the keyword 'attr'

  • Key: OCL23-34
  • Legacy Issue Number: 15254
  • Status: closed  
  • Source: UPCT ( Pedro Alcover)
  • Summary:

    I've seen, in the version 2.0, the existence of the keyword 'attr'. But then, in fact, there isn't any reference or explanation about the use of this keyword.
    I've seen that this keyword is not in the new versiĆ³n 2.2. But, you use it in the page 25, ln 12.

  • Reported: OCL 2.2 — Fri, 14 May 2010 04:00 GMT
  • Disposition: Resolved — OCL 2.3
  • Disposition Summary:

    The 'attr' is a relic of a former (pre OCL 2.0) syntax.
    The 'attr' should be omitted, and 'TupleType' should be 'Tuple'.

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

OCL 2.2 UML Alignment of association names

  • Key: OCL23-33
  • Legacy Issue Number: 15235
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    In accordance with Nicolas Rouquette's observations in the discussion on "15233 – OCL 2.2 Correction to Issue 9796 for AssociationEndCall":

    The problem with OCL 2.2, Fig 7.1 are:

    • give a name to the association end near Bank, e.g. 'bankAccount'
    • fix the multiplicity of: Person::bankAccount from 0..1 to * – i.e., a person can have zero or more bank accounts!
    • fix the multiplicity of Bank::customer from 0..* to 0..1 – i.e., there is zero or one customer for a given 'accountNumber' value.
    • give a name to the association itself, e.g., BankAccount, or, if you want to use the UML notation convention, A_customer_bankAccount

    and

    The OCL examples for Figure 7.2, currently:

    context Person inv: self.employeeRanking[bosses]->sum() > 0
    context Person inv: self.employeeRanking[employees]->sum() > 0
    context Person inv: self.employeeRanking->sum() > 0 – INVALID!
    context Person inv: self.job[employer]

    should be fixed to:

    context Person inv: self.EmployeeRanking[bosses]->sum() > 0
    context Person inv: self.EmployeeRanking[employees]->sum() > 0
    context Person inv: self.EmployeeRanking->sum() > 0 – INVALID!
    context Person inv: self.Job[employer]

    That is, 'EmployeeRanking' is the name of the association shown in Fig 7.2
    That figure does not have anything called 'employeeRanking' and it is misleading to suggest that in OCL the name of the association could be written with a lowercase initial letter when the name of the association itself has an initial capital letter. Since lexical names are case-sensitive in both UML and OCL, case-sensitivity should be respected to avoid creating confusion and potential ambiguity with other names that are lexically different only by their upper/lower case letter.

    and

    In particular, the text in clause 7.5.4 about using the name of an association class with a lowercase initial letter should be removed.
    That is, change the following, currently:

    To specify navigation to association classes (Job and Marriage in the example), OCL uses a dot and the name of the association class starting with a lowercase character:

    context Person inv: self.job

    The sub-expression self.job evaluates to a Set of all the jobs a person has with the companies that are his/her employer. In the case of an association class, there is no explicit rolename in the class diagram. The name job used in this navigation is the name of the association class starting with a lowercase character, similar to the way described in the sub clause “Missing AssociationEnd names” above.

    to:

    To specify navigation to association classes (Job and Marriage in the example), OCL uses a dot and the name of the association class:

    context Person inv: self.Job

    The sub-expression self.Job evaluates to a Set of all the jobs a person has with the companies that are his/her employer. In the case of an association class, there is no explicit rolename in the class diagram. The name Job used in this navigation is the name of the association class.

  • Reported: OCL 2.2 — Fri, 30 Apr 2010 04:00 GMT
  • Disposition: Resolved — OCL 2.3
  • Disposition Summary:

    No Data Available

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

OCL 2.2 11.5.3 What is a locale?

  • Key: OCL23-32
  • Legacy Issue Number: 15224
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    The new toUpperCase, toLowerCase and equalsIgnoreCase refer to case conversion if appropriate to the locale without ever defining what a locale is or defining the preconditions for appropriateness.

    These methods closely resemble Java Library methods, perhaps they should reference rather than duplicate the Java specification.

    The Java toUpperCase method provides locale-dependent and local-independent variants.

    Is it right for OCL to make it difficult to achieve predictable results under a Turkish locale?

    It seems that the OCL standard library must provide access to the Locale and provide both Java's toUpperCase variants.

  • Reported: OCL 2.2 — Fri, 23 Apr 2010 04:00 GMT
  • Disposition: Resolved — OCL 2.3
  • Disposition Summary:

    No Data Available

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

OCL 2.2 11.7.1 Why must + be commutative for Collection::sum()

  • Key: OCL23-31
  • Legacy Issue Number: 15223
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    Collection::sum() requires that its T::+() is commutative and associative.

    Associativity is necessary for predictable results.

    Commutativity is not necessary, most trivially for String::+ for which sum() could usefully
    concatenate an OrderedSet.

    Suggest: remove the requirement for commutativity.

  • Reported: OCL 2.2 — Fri, 23 Apr 2010 04:00 GMT
  • Disposition: Resolved — OCL 2.3
  • Disposition Summary:

    No Data Available

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

OCL 2.2 11.7.1 Why must + be associative for Collection::sum()

  • Key: OCL23-30
  • Legacy Issue Number: 15222
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    Collection::sum() requires that its T::+() is commutative and associative.

    Associativity is necessary for predictable results.

    However what if it isn't?

    Is there an obligation on the OCL runtime to detect non-associativity and return invalid?

    • probably not possible.

    Is there a permission on the OCL runtime to detect non-associativity and return invalid?

    • difficult to ensure implementation portability

    Is there just an informal caution to users that non-associativity may lead to unpredictable results?

    Suggest: reword to permit an implementation to return invalid and caution users about unpredictable results.

  • Reported: OCL 2.2 — Fri, 23 Apr 2010 04:00 GMT
  • Disposition: Resolved — OCL 2.3
  • Disposition Summary:

    No Data Available

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

String.equalsIgnoreCase(String) should result in Boolean

  • Key: OCL23-29
  • Legacy Issue Number: 15134
  • Status: closed  
  • Source: Microsoft ( Len Charest)
  • Summary:

    OCL 2.2 defines equalsIgnoreCase as returning an Integer. Given that the operation determines equivalence of two Strings, I would expect it to return Boolean: either the strings are equivalent (true) or they are not (false).

  • Reported: OCL 2.2 — Wed, 17 Mar 2010 04:00 GMT
  • Disposition: Resolved — OCL 2.3
  • Disposition Summary:

    No Data Available

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

OCL 2.1 11.2.3 Navigated Implicit Conversion to Collection Literal

  • Key: OCL23-28
  • Legacy Issue Number: 15009
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    The Issue 14981 considered use of explicit null as a Collection.

    11.2.3 states that 'If the source is the null literal, it is implicitly converted to Bag{}'.

    Surely when the null arises as a navigation result, the isOrdered and isUnique characteristics of the navigated property should determine what CollectionKind the null result is converted to?

    However meta-modelling tools and meta-modellers pay little attention to the isUnique and isOrdered characteristics of zero and unit multiplicity properties. Using this overlooked information may cause surprises.

  • Reported: OCL 2.2 — Fri, 29 Jan 2010 05:00 GMT
  • Disposition: Resolved — OCL 2.3
  • Disposition Summary:

    7.6.3 Navigation over Associations with Multiplicity Zero or One suggests non-collection are converted to Sets. Similarly 7.6.5, 9.7. So there is a contradiction in the normative conversion to Set or Bag. Set seems more sensible and what the non-normative clauses suggest.
    Using the accidental ordered/unique attributes of non-collections would lead to horrible surprises for existing usage, so it must be conversion to a set.
    Since the conversion of null yields an empty set, whereas any other object yields a single element set, the Set size is data dependent and so must be determined at run-time and cannot be expressed as a CollectionLiteralExp. Rather, evaluation of PropertyCallExp and OperationCallExp must detect a mismatch between a non-collection source type and a collection-type referredOperation class.
    Delayed resolution is inconsistent with OCL's static typing, so let us make it explicit by defining OclAny::oclAsSet() for the static analysis to invoke and perform the conversion. The conversion is represented as a regular OperationCallExp in the AST and only type-dependent run-time decisions need to be made.
    Note that the revisions below do not address the deficiencies in the normative Clause 9 text raised by Issue 15790. We continue to rely on the final sentence of 9.7: "The mapping is not formally defined in this document but should be obvious."

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

OCL 2.1 8.3.8 OclInvalid::allInstances

  • Key: OCL23-27
  • Legacy Issue Number: 15005
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    8.3.8 states that in regard to allInstances

    "returns all instances of the classifier and the classifiers specializing it. May only be used for classifiers that have a finite
    number of instances. This is the case, for example, for user defined classes because instances need to be created explicitly,
    and for enumerations, the standard Boolean type, and other special types such as OclVoid and OclInvalid."

    While it is true that OclInvalid has exactly one instance, the corresponding return of Set

    {invalid}

    is not well-formed.

    Therefore the invocation OclInvalid.allInstances() must return invalid.

    Suggest:

    Replace "and OclInvalid" by ". But not for OclInvalid, for which the return is invalid"

  • Reported: OCL 2.2 — Mon, 25 Jan 2010 05:00 GMT
  • Disposition: Resolved — OCL 2.3
  • Disposition Summary:

    No Data Available

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

OCL 2.1 11.2 Conflicting {OclVoid, OclInvalid}::{oclIsTypeOf, oclIsKindOf, oclAsType} semantics

  • Key: OCL23-26
  • Legacy Issue Number: 14985
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    11.2.3 states clearly that "Any property call applied on null results in OclInvalid, except for the operations oclIsUndefined() and oclIsInvalid()." This is being revised by Issue 14197 in OCL 2.3 to: "Any property call applied on OclVoid results in invalid, except for the operations oclIsUndefined(), oclIsInvalid(), =(OclAny) and <>(OclAny)."

    11.2.4 states clearly that "Any property call applied on invalid results in OclInvalid, except for the operations oclIsUndefined() and oclIsInvalid()." This is being revised by Issue 14197 in OCL 2.3 to: "Any property call applied on OclInvalid results in invalid, except for the operations oclIsUndefined() and oclIsInvalid()."

    Therefore invalid.oclIsTypeOf(OclInvalid) => invalid and null.oclIsTypeOf(OclVoid) => invalid.

    But the above are widely used in the specification as for example:

    "oclIsUndefined() : Boolean
    Evaluates to true if the self is equal to OclInvalid or equal to null.
    post: result = self.isTypeOf( OclVoid ) or self.isTypeOf(OclInvalid)"

    clearly expecting isTypeOf (a typo) to return true/false, not invalid sometimes.

    Issue 14197 relaxed the OclVoid property list to allow = and <>. Perhaps all oclXXX operations should have an explicitly defined semantics for OclVoid and OclInvalid, supporting rather than denying reflective usage of the values as in self.isTypeOf( OclVoid ).

  • Reported: OCL 2.2 — Sun, 17 Jan 2010 05:00 GMT
  • Disposition: Resolved — OCL 2.3
  • Disposition Summary:

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

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

OCL 2.1 Implicit Conversion to Collection Literal

  • Key: OCL23-25
  • Legacy Issue Number: 14981
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    The specification is very vague as to how and when a non-collection is converted to a collection.

    11.2.3 states that 'If the source is the null literal, it is implicitly converted to Bag{}'.

    7.5.3 states that '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.'

    The collection type inconsistency between Bag{} and Set

    {x}

    makes compile-time type resolution difficult, since the null-ness of x cannot be known till run-time. It would be better to have either Set or Bag uniformly as the conversion collection type. Bag{} as the least useful seems more appropriate.

    When a conversion is applicable is unclear.

    In the example, self.manager->isEmpty() is intended to be interpreted as

    if self.manager.isUndefined() then Set{} else Set

    {self.manager}

    endif->isEmpty()

    so that null->isEmpty is also valid.

    However is

    null->excludesAll(null)

    equivalent to

    Bag{}->excludesAll(Bag{})

    and so true?

    A simple policy of 'wherever a collection is required and a non-collection is provided perform an implicit conversion to collection-literal' resolves this.

    However are

    null = Bag{}

    or

    Bag{} = null

    both equivalent to

    Bag{} = Bag{}

    and so true?

    In this case we have a problem of asymmetric overloading.

    null = Bag{} satisfies the signature for OclVoid::=(OclAny) and so returns false.

    Bag{} = null could satisfy the signature for Bag::=(Bag) and so return true with the help of an implicit conversion.

    Presumably an additional OclVoid::=(Collection) overload is needed to restore symmetry.

  • Reported: OCL 2.2 — Sun, 17 Jan 2010 05:00 GMT
  • Disposition: Resolved — OCL 2.3
  • Disposition Summary:

    Resolved by Issue 15009, where the explicit synthesis of oclAsSet() avoids the troublesome conversions above.
    Disposition: See issue 15009 for disposition

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

OCL 2.1 11.2.5 Numeric = and <> operations should compare values rather than objects

  • Key: OCL23-24
  • Legacy Issue Number: 14918
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    OCLAny::=() is defined as 'True if self is the same object as object2.'

    This is not overloaded for numeric types, and it is not specified that a numeric value may not have multiple instances.

    The definition therefore implies that:

    1 = 1

    may often evaluate to false, and that

    1.0 = 1

    must evaluate to false even though (1.0 <= 1) and (1.0 >= 1) will evaluate true

    Suggest overload

    {Boolean, Real, String}

    ::

    {=,<>}

    to use values rather than objects.

  • Reported: OCL 2.2 — Sat, 2 Jan 2010 05:00 GMT
  • Disposition: Resolved — OCL 2.3
  • Disposition Summary:

    The use of object should be clarified so that
    Class instances are compared by object identity.
    DataType instances are compared by value.
    This resolution overlaps with null/invalid clarification and so the change below includes changes for Issue 18437.

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