Object Constraint Language Avatar
  1. OMG Specification

Object Constraint Language — Open Issues

  • Acronym: OCL
  • Issues Count: 38
  • Description: Issues not resolved
Open Closed All
Issues not resolved

Issues Summary

Key Issue Reported Fixed Disposition Status
OCL25-227 Missing specification of equality operators for PrimitiveTypes OCL 2.4 open
OCL25-225 Possibility for paragraph comments /* ... */ not mentioned in 7.4.12 OCL 2.4 open
OCL25-224 Clarify LocalSnapshot / History OCL 2.4 open
OCL25-223 Clarify xxxEval classes OCL 2.4 open
OCL25-222 How does bad allInstances() execute? OCL 2.4 open
OCL25-221 :: is not an invocable operator OCL 2.4 open
OCL25-220 Illegal side-effecting example OCL 2.4 open
OCL25-219 Add OclAny::toString() OCL 2.4 open
OCL25-75 OclVoid::oclIsKindOf/oclIsTypeOf should return true/false rather than invalid OCL 2.4 open
OCL25-218 Inconsistencies regarding OclAny OCL 2.4b1 open
OCL25-216 Missing Association Names not correct OCL 2.4 open
OCL25-215 OCL 2.4 reverts OCL 2.3's Issue 12953 resolution OCL 2.4 open
OCL25-214 Suspected typo OCL 2.4 open
OCL25-213 Multi-dimensional sortedBy OCL 2.4 open
OCL25-113 Invalid algorithm in definitions of sortedBy OCL 2.4 open
OCL25-211 OrderedSet::insertAt unclear for insert of existing element OCL 2.4 open
OCL25-210 Clarify indeterminate/unknown order for asSequence/asOrderedSet/any OCL 2.4 open
OCL25-209 Are failures invalid? OCL 2.4 open
OCL25-208 Add % operator OCL 2.4 open
OCL25-207 Generalize body/precondition/postcondition as named capabilities OCL 2.4 open
OCL25-206 How is OCL used with a UML InstanceSpecification? OCL 2.4 open
OCL25-205 Support MyStereotype.allInstances() OCL 2.4 open
OCL25-204 Wrong color for abstract syntax presentation OCL 2.4 open
OCL25-203 How indeterminate are asOrderedSet/asSequence? OCL 2.4 open
OCL25-202 Provide a Map of qualified associations OCL 2.4 open
OCL25-201 Make null-free collections the default OCL 2.4 open
OCL25-153 Missing Real::= overload OCL 2.4 open
OCL25-152 Append/prepend on OrderedSet does not necessarily increase the collection size OCL 2.4 open
OCL25-117 Conflicting String::indexOf postConditions OCL 2.4 open
OCL25-116 Example of collect in terms of iterate is not flattened OCL 2.4 open
OCL25-115 indentified OCL 2.4 open
OCL25-114 Add isInteger/isReal OCL 2.4 open
OCL25-112 i/r typo OCL 2.4 open
OCL25-73 Missing/Poor definition of iterate() OCL 2.4 open
OCL25-74 Reverse CollectionRange should be empty rather than invalid OCL 2.4 open
OCL25-71 Obsolete implicit cast to Bag OCL 2.4 open
OCL25-45 Coolection operations do not allow invalid inputs OCL 2.4 open
OCL25-4 Missing mode precondition OCL 2.4 open

Issues Descriptions

Missing specification of equality operators for PrimitiveTypes

  • Key: OCL25-227
  • Status: open  
  • Source: N/A ( Robert Hairgrove)
  • Summary:

    In section 11.5 "Operations and Well-formedness Rules" for the five standard PrimitiveTypes Boolean, Integer, Real, String, and UnlimitedNatural, we have specifications for logical comparison operators <, >, <=, >= but no specification for the equality operator.

    It seems to me that if these operators must be explicitly implemented by tools, they must also implement a method for equality which should be specified. In C++, this is of course necessary. The operation String::equalsIgnoreCase(), for example, depends on it directly:

    "Queries whether s and self are equivalent under case-insensitive collation.
    post: result = (self.toUpperCase() = s.toUpperCase())"

  • Reported: OCL 2.4 — Sat, 29 Jun 2024 13:57 GMT
  • Updated: Mon, 1 Jul 2024 15:50 GMT

Possibility for paragraph comments /* ... */ not mentioned in 7.4.12

  • Key: OCL25-225
  • Status: open  
  • Source: Danish Agency for Data Supply and Infrastructure ( Heidi Vanparys)
  • Summary:

    According to section 9.3.49, there are two forms of comments, line comments (-- this is a comment) and paragraph comments (/* this is a comment */):

    It is possible to include comments anywhere in a text composed according to the above concrete syntax. There will be no
    mapping of any comments to the abstract syntax. Comments are simply skipped when the text is being parsed. There are
    two forms of comments, a line comment, and a paragraph comment. The line comment starts with the string ‘--’ and ends
    with the next newline. The paragraph comment starts with the string ‘/’ and ends with the string ‘/.’ Paragraph
    comments may be nested.

    In section 7.4.12, only the syntax for line comments is described:

    Comments in OCL are written following two successive dashes (minus signs). Everything immediately following the two
    dashes up to and including the end of line is part of the comment.

    For example:
    – this is a comment

    The two possibilities should be mentioned in 7.4.12.

  • Reported: OCL 2.4 — Fri, 2 Dec 2022 10:03 GMT
  • Updated: Thu, 22 Dec 2022 06:16 GMT

Clarify LocalSnapshot / History

  • Key: OCL25-224
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    Fig 10.2 presents some classes that to the best of my knowledge have never been used in an OCL implementation. The LocalSnapshot is a possible way of reconciling the need for two distinct system states when evaluating @pre or oclIsNew. It is however perhaps no more than some draft thoughts. Some much more promising work has evolved as 'Filmstrip's in conjunction with the USE tool. A Filmstrip supports OCL expressions that apply across time.

    The LocalSnapshot and associated support are absolutely not a normative part of an OCL implementation.

  • Reported: OCL 2.4 — Sun, 10 Jul 2022 07:13 GMT
  • Updated: Sun, 10 Jul 2022 07:13 GMT

Clarify xxxEval classes

  • Key: OCL25-223
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    OCL25-80 comment 1 identifies that the xxxValue classes are misleading and could be trivially rephrased as "xxx value semantics".

    Similarly the xxxEval classes are unhelpful and could be triially rephrased as "xxx evaluation semantics".

    Simple or efficient implementations of OCL have no need to reify each evaluation as an instance, the execution can just return the appropriate result. Only an implementation with rigorous tracing for debugging or incremental execution need reify the execution and the implementation should be free to choose its own implementation details.

    There is absolutely no need for a normative existence of xxxEval classes. Only the semantics is normative.

  • Reported: OCL 2.4 — Sun, 10 Jul 2022 06:59 GMT
  • Updated: Sun, 10 Jul 2022 06:59 GMT

How does bad allInstances() execute?

  • Key: OCL25-222
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    Section 8.3.8 neglects to specify what it means for allInstances to be invoked for a Classifier that does not have a finite number of instances.

    The Real/Integer/UnlimitedNatural/String PrimitiveTypes, CollectionType, TupleType, DataType, ,,, overloads could reasonably return invalid or an empty Set. Just need the specification to say which by specifying each of the overloads in Section 8 / 11.

    Overloading Classifier::allInstances() with a crash (invalid) seems unkind, so suggest the empty set to avoid users needing to exclude many metatypes in a many-classifiers loop..

  • Reported: OCL 2.4 — Sun, 19 Dec 2021 15:50 GMT
  • Updated: Sun, 19 Dec 2021 15:50 GMT

:: is not an invocable operator

  • Key: OCL25-221
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    The flawed resolution of issue 8937 introduced Section 7.5.10 in which it is suggested that :: is an operator that can be contrasted with the . object navigation operator.

    It isn't. It is a name qualification operator allowing e.g. A::B::C::d to clearly locate a feature with respect to any prolematic name clashes.

    If :: is an invocable operator, which of the :: in A::B::C::d are to be executed, and how?

    As a qualification operator the referredOperation/referredProperty field in an OperationCallExp/PropertyCallExp is assigned at compile-time to the unambiguous resolution of the qualified reference. No extra execution for the qualification.

  • Reported: OCL 2.4 — Sat, 18 Dec 2021 15:13 GMT
  • Updated: Sat, 18 Dec 2021 15:46 GMT

Illegal side-effecting example

  • Key: OCL25-220
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    The flawed resolution of issue 8937 introduced Section 7.5.10 and the Employee::id() example that invokes the static Employee::uniqueID() to initialize each Employee instance with a presumably distinct unique id.

    This can only work if uniqueID() returns a distinct value from each call. It is therefore not a query and not side-effect-free. It cannot be invoked from OCL.

    Unless the execution semantics introduces some new magic static-time between load-time and run-time in which a side-effecting static semantics is defined and supported, this is impossible. No idea how this could be made deterministic on a multi-processor execution engine.

    Rather we need to be declarative and do everything at once, rather than one at a time imperatively.

    context Employee
    static def: allEmployees : Sequence(Employee)
    = Employee.allInstances()->asSequence()
    def: id : String
    = 'ID' + allEmployees->indexOf(self).toString()

    The quadratic cost of indexOf can be avoided if we have maps and co-iterators:

    context Employee
    static def: employee2index : Map(Employee,Integer)
    = Employee.allInstances()->collectByValue(key with value | key)
    def: id : String
    = 'ID' + employee2index->at(self).toString()

    An optimized execution engine could recognize the idiom and optimize away the single use static Map.

  • Reported: OCL 2.4 — Sat, 18 Dec 2021 15:00 GMT
  • Updated: Sat, 18 Dec 2021 15:00 GMT

Add OclAny::toString()

  • Key: OCL25-219
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    toString() is a familiar debug facility that OCL currently provides ony for logical / numeric usage. This is unfriendly.

    Better to provide toString() for all values including null and invalid, with a carefully designed formatting to ensure that a monotonic forward/reverse round trip is possible.

    (OCL25-75 vaguely suggests toString()).

  • Reported: OCL 2.4 — Thu, 18 Nov 2021 15:07 GMT
  • Updated: Thu, 18 Nov 2021 15:07 GMT

OclVoid::oclIsKindOf/oclIsTypeOf should return true/false rather than invalid

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

    The Isabelle evolution for Annex A highlight two errors in the OCL 2.4 clarifications.

    OclVoid::oclIsKindOf/oclIsTypeOf should return true/false rather than invalid.

    ? oclIsKindof true for all types except OclIsInvalid.

  • Reported: OCL 2.4 — Mon, 30 Sep 2013 04:00 GMT
  • Updated: Wed, 10 Nov 2021 10:19 GMT

Inconsistencies regarding OclAny

  • Key: OCL25-218
  • Status: open  
  • Source: King's College London ( Kevin Lano)
  • Summary:

    There seems to be some confusion in ptc-13-08-13 regarding the relation of OclAny to other OCL types. Sections 8.2 and 11
    state that it is a supertype of all other OCL types, including collection and tuple types, but Annex A excludes collection/tuple types from inclusion in OclAny.

  • Reported: OCL 2.4b1 — Thu, 29 Oct 2020 11:17 GMT
  • Updated: Tue, 17 Nov 2020 16:26 GMT

Missing Association Names not correct

  • Key: OCL25-216
  • Status: open  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    in UML the rules for distinguishable names are:

    • Have different Names
    • Same Names but different Types
      metaclasses are different
      Neither is a (direct or indirect) generalization/specialization of the other
      (e.g. Operations distinguished by signature)

    so we can have a class Person and a DataType Person... each could have an association to it... so the association end implicit name is the same... and would need to be differentiated by its Type... this is not currently supported in OCL

  • Reported: OCL 2.4 — Sat, 15 Feb 2020 17:32 GMT
  • Updated: Tue, 18 Feb 2020 19:20 GMT

OCL 2.4 reverts OCL 2.3's Issue 12953 resolution

  • Key: OCL25-215
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    Issue 12953 made changes to the CollectionLiteralExpCS grammar and these appear in OCL 2.3 but not in OCL 2.4.

    It would appear that some major editorial snafu occurred while reconstructing a FrameMaker base for OCL 2.4 after the OCL 2.3.1 corruptions.

    Application of OCL 2.2, 2.3, 2,3.1, 2.4 changes need to be checked to understand the snafu.

  • Reported: OCL 2.4 — Tue, 2 Oct 2018 07:47 GMT
  • Updated: Thu, 4 Oct 2018 19:26 GMT

Suspected typo

  • Key: OCL25-214
  • Status: open  
  • Source: Lockheed Martin ( Mr. Geoffrey Shuebrook)
  • Summary:

    Typo in sentence "If the constraint is shown in a diagram, with the proper stereotype and the dashed lines to connect it to its contextual
    element, there is no need for an explicit context declaration in the test of the constraint."

    test should be text

  • Reported: OCL 2.4 — Thu, 23 Aug 2018 12:26 GMT
  • Updated: Wed, 29 Aug 2018 20:12 GMT

Multi-dimensional sortedBy

  • Key: OCL25-213
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    The sortedBy iteration provides an elegant solution to a sort problem in which the sort metric is a projection of the sorted object. Thus sortedBy(p|p.name) or just sortedBy(name) is short and avoids the opportunities for typos from a more conventional exposition involving comparison of two objects. The natural solution may well be an efficient one for large collections with non-trivial metrics.

    However the sortedBy solution is unfamiliar and so confusing for newcomers and unsuitable for multi-key sorting for which an artificial compound single key may need to be constructed.

    One solution might be to provide a more conventional iterator such as sort(p1, p2 | comparison-expression) allowing a two key sort:

    sort(p1, p2 | let diff1 = p1.key1.compareTo(p2.key1) in
    if diff1 <> 0 the diff 1 else p1.key2.compareTo(p2.key2) endif)

    However this has poor readability and ample opportunities for typos.

    Alternatively sortedBy with a Tuple-valued metric might support multiple keys as:

    sortedBy(Tuple

    {first=key1,second=key2}

    )

    (The alphabetical order of the Tuple part names determines the priority.)

    (Since sortedBy is declaratively clear and compact, inefficient small/trivial implementations can be optimized to their sort() equivalents.)

  • Reported: OCL 2.4 — Sat, 20 Jan 2018 09:53 GMT
  • Updated: Sat, 20 Jan 2018 09:53 GMT

Invalid algorithm in definitions of sortedBy

  • Key: OCL25-113
  • Legacy Issue Number: 19510
  • Status: open  
  • Source: seznam.cz ( Vlastimil Dort)
  • Summary:

    The following problems are common to all definitions of sortedBy in 11.9:

    Invalid algorithm:

    • When the current element is not the first one, but is the
      greatest one so far, for example 2 in
      Sequence {1,2}

      ->sortedBy(x|x),
      then
      result->select (item | body (item) > body (iterator))
      is empty and calling ->first on it would result in invalid.

    Inconsistent use of < and >:

    • The text descriptions mention using < operation on the elements,
      but the algorithm uses > operator.

    Typos:

    • The accumulator initialization incorrectly uses : instead of =.
    • The source for the iterate expression is missing.
    • The closing parenthesis for the iterate expression is missing.
    • The operations append and insertAt are called by . operator.

    SOLUTION:

    • Introduce a new local variable upperBounds, containing elements from the
      accumulator that are greater than the current element.
    • Swap body (iterator) and body (item).
    • Fix typos.

    Corrected algorithm for Set (11.9.2) and OrderedSet (11.9.5):

    ****************************************
    source->sortedBy(iterator | body) =
    source->iterate( iterator ; result : OrderedSet(T) = OrderedSet {} |
    let upperBounds : OrderedSet(T) =
    result->select (item | body (iterator) < body (item) )
    in
    if upperBounds->isEmpty() then
    result->append(iterator)
    else
    let position : Integer = result->indexOf ( upperBounds->first() )
    in
    result->insertAt(position, iterator)
    endif
    )
    ****************************************

    Corrected algorithm for Sequence (11.9.4) and Bag (11.9.3):

    ****************************************
    source->sortedBy(iterator | body) =
    source->iterate( iterator ; result : Sequence(T) = Sequence {} |
    let upperBounds : Sequence(T) =
    result->select (item | body (iterator) < body (item) )
    in
    if upperBounds->isEmpty() then
    result->append(iterator)
    else
    let position : Integer = result->indexOf ( upperBounds->first() )
    in
    result->insertAt(position, iterator)
    endif
    )
    ****************************************

    FURTHER SUGGESTIONS:

    • The presented algorithm works only under assumption that indexOf(obj:T)
      on Sequence(T) returns the first occurence. This is not mentioned in the
      definition of indexOf. If indexOf can return any index, for example:
      Sequence {2, 2}

      ->indexOf(2) = 2,
      then the above algorithm could insert the element at the wrong place,
      for example:
      Sequence

      {2, 2, 1}

      ->sortedBy(x|x) = Sequence

      {2, 1, 2}
    • The algorithm is stable for Sequence and OrderedSet, this fact could be
      mentioned in the description, to make it clear that successive
      sortedBy iterations can be used to sort by multiple criteria.
  • Reported: OCL 2.4 — Fri, 4 Jul 2014 04:00 GMT
  • Updated: Sat, 20 Jan 2018 09:25 GMT

OrderedSet::insertAt unclear for insert of existing element

  • Key: OCL25-211
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    The pseudocode for OrderedSet::insertAt assumes that the inserted element is not already contained.

    Presumably insertion of an existing element does not increase the OrderedSet size.

    Design choice. Is the old element retained or is the old element removed and the new element inserted? The latter might preserve the postcondition that the element at the index is the inserted object, but what if the removed element was earlier so that everything moved along first?

    Surely the only predictable behavior is that the old element is retained?

  • Reported: OCL 2.4 — Fri, 7 Jul 2017 08:29 GMT
  • Updated: Fri, 7 Jul 2017 09:38 GMT

Clarify indeterminate/unknown order for asSequence/asOrderedSet/any

  • Key: OCL25-210
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    "asSequence" and "asOrderedSet" are specified as returning an unknown ordering. How deterministic is this? repeatable with the same tool version, the same tool, the same CPU, the same number of CPUs, any OCL tool?

    "any" is specified as indeterminate.

    Non-determinism is a very bad language characteristic.

    Surely "any" should be the earliest element in asSequence()?

    If a tool avoids anarchic sets, perhaps keeping a list and set for each 'set', the resulting behavior can be deterministic. But is specifying deterministic set evaluation algorithms appropriate for the OCL specification?

    Suggest the specification should just require that a re-execution with:

    • the same tool version
    • the same Operating System etc
    • the same single CPU
    • the same command line options
      shall give the same result (unknown but deterministic).
  • Reported: OCL 2.4 — Tue, 27 Dec 2016 17:36 GMT
  • Updated: Sat, 31 Dec 2016 08:54 GMT

Are failures invalid?

  • Key: OCL25-209
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    OCL is an executable specification language that uses "invalid" as its exception handling mechanism for untoward execution, which clearly includes deterministic internal program control faults:

    • divide by zero
    • null-navigation
    • ordered collection index out of bounds
      Does this behavior also include non-deterministic external problems:
    • network/disk access failure
    • stack overflow
    • tooling malfunction

    Without an answer to this question, it i impossible to know whether e.g. "aSequence->includes->last()" can be optimized to "x" or not. Is it necessary to fully evaluate aSequence, perhaps run out of memory, in order to incur an external issue that influences an evaluation?

  • Reported: OCL 2.4 — Mon, 26 Dec 2016 09:45 GMT
  • Updated: Wed, 28 Dec 2016 15:46 GMT

Add % operator

  • Key: OCL25-208
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    The % (modulo/remainder) operator is realtively standard operator in many langages. It is missing from the OCL Standard Library. There is only Integer::mod().

    QVTo 1,3 8.4.4 4 implies that there is a % modulo operator even though there isn't. See QVT14-44.

    Suggest add Real::%

  • Reported: OCL 2.4 — Mon, 19 Dec 2016 10:09 GMT
  • Updated: Mon, 19 Dec 2016 10:09 GMT

Generalize body/precondition/postcondition as named capabilities

  • Key: OCL25-207
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    UML/OCL hardwire three capabilities of an Operation.

    "body" is very useful
    "precondition", "postcondition" are sometimes useful
    anything else is unsupported.

    Some users want frame conditions.

    Code generation/analysis wants other forms of meta-evaluation.

    Rather than expand the hardwired options, allow an Operation to have an extensible set of named capabilities.Some names such as "body", "precondition", "postcondition" can be standardized. Others could be reserved in anticipation.

  • Reported: OCL 2.4 — Wed, 14 Dec 2016 15:38 GMT
  • Updated: Wed, 14 Dec 2016 15:38 GMT

How is OCL used with a UML InstanceSpecification?

  • Key: OCL25-206
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    A UML InstanceSpecification introduces classification within the M1 level. OCL is normally applicable to inter level typing. M0/M1 or M1/M2.

    Does anInstanceSpecification.oclIsKindOf(XXX) use a same-level or meta XXX?

    Does anInstanceSpecification.YYY use the YYY feature of the InstanceSpecification metaclass or any one of the anInstanceSpecification.classifier?

    Is a new navigation operator needed to distinguish the two cases?

  • Reported: OCL 2.4 — Sun, 14 Feb 2016 21:43 GMT
  • Updated: Thu, 18 Feb 2016 13:49 GMT

Support MyStereotype.allInstances()

  • Key: OCL25-205
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    Practical evaluation of stereotypes requires OCL to reify the Stereotype instances. These instances should be accessible by Stereotype.allInstances().

    e.g. if an ElementExtension is the Stereotype instance and Element.extensions are the applied stereotypes.

    Stereotype.allInstances() is equivalent to

    Element.allInstances().extensions->selectByKind(MyStereotype)

  • Reported: OCL 2.4 — Mon, 4 Jan 2016 09:55 GMT
  • Updated: Mon, 4 Jan 2016 09:55 GMT

Wrong color for abstract syntax presentation

  • Key: OCL25-204
  • Legacy Issue Number: 19865
  • Status: open  
  • Source: neusoft.com ( Jingang Zhou)
  • Summary:

    The last sentence of the first paragraph on page 37 says "All metaclasses defined as part of the OCL abstract syntax are shown with a light gray background.", but subsequent abstract syntaxs show OLC defined metaclasses in yellow

  • Reported: OCL 2.4 — Thu, 3 Dec 2015 05:00 GMT
  • Updated: Fri, 4 Dec 2015 17:03 GMT

How indeterminate are asOrderedSet/asSequence?

  • Key: OCL25-203
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    asOrderedSet() : OrderedSet(T)
    Redefines the Collection operation. An OrderedSet that contains all the elements from self, in undefined order.

    If asOrderedSet() is invoked more than once on the same Set, then presumably the subsequent calls have a defined order; the order previously used.

    When used by QVTo the lack of determinism of Set ordering is a significant debugging nuisance. Suggest that there is a repeatable but unspecified underlying order determined perhaps by object creation order.

  • Reported: OCL 2.4 — Wed, 11 Nov 2015 06:52 GMT
  • Updated: Wed, 11 Nov 2015 06:52 GMT

Provide a Map of qualified associations

  • Key: OCL25-202
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    object.assoc[qualifier] returns a particular element from a qualified association.

    With Map already suggested/prototyped for OCL, let object.assoc[] return a Map<qualifier,element> that avoids the loss of information from object.assoc that returns Collection<element>

  • Reported: OCL 2.4 — Mon, 19 Oct 2015 06:14 GMT
  • Updated: Mon, 19 Oct 2015 08:01 GMT

Make null-free collections the default

  • Key: OCL25-201
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    null-in-Collections was added by the OCL 2.0 FTF in Issue 5972 in the unanalyzed hope that it would be useful.

    https://ocl2015.lri.fr/OCL_2015_paper_0921_1400.pdf examines the null safety of OCL nad concludes that an ability to declare null-free collections is essential.

    Since almost all collections in practical OCL are null-free, suggest that the OCL default should be for null-free collections, with an option to have null-full collections when really needed.

  • Reported: OCL 2.4 — Thu, 8 Oct 2015 15:11 GMT
  • Updated: Thu, 8 Oct 2015 15:11 GMT

Missing Real::= overload

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

    Issue 14918 went most of the way to clarifying '=' behaviour.

    But the Real::'=' and Real::'<>' overloads were omitted.

    Consequently the fix to ensure that 1.0 = 1
    evaluates to true when (1.0 <= 1) and (1.0 >= 1) will evaluate true is missing.

  • Reported: OCL 2.4 — Sun, 15 Sep 2013 04:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

Append/prepend on OrderedSet does not necessarily increase the collection size

  • Key: OCL25-152
  • Legacy Issue Number: 19210
  • Status: open  
  • Source: Heinz Nixdorf Institute, University of Paderborn ( Christopher Gerking)
  • Summary:

    The spec defines the following postcondition for the append/prepend operations on OrderedSet:

    result->size() = self->size() + 1

    However, if self does already contain the added element, the size does not increase by one since the elements are unique.

  • Reported: OCL 2.4 — Tue, 11 Feb 2014 05:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

Conflicting String::indexOf postConditions

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

    The Issue 17220 clarification that the empty string is a substring at index 1 failed to revise the postcondition that the index of of any string in the empty string is at index 0.

    Replace:

    post: self.size() = 0 implies result = 0

    by

    post: self.size() = 0 and s.size() > 0 implies result = 0

    and move it to the second postcondition

  • Reported: OCL 2.4 — Sat, 24 Aug 2013 04:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

Example of collect in terms of iterate is not flattened

  • Key: OCL25-116
  • Legacy Issue Number: 19434
  • Status: open  
  • Source: rjgodoy.com.ar ( Javier Godoy)
  • Summary:

    The example of collect in terms of iterate given in section section 7.6.6 is not flattened. Actually it is a copy of the definition of collectNested in section 11.9.2.

  • Reported: OCL 2.4 — Mon, 26 May 2014 04:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

indentified

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

    Change to identified

  • Reported: OCL 2.4 — Tue, 22 Jul 2014 04:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

Add isInteger/isReal

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

    Add isInteger/isReal predicates to avoid need to test invlaid on toInteger/toReal

    Add isBoolean/toBoolean/toString

  • Reported: OCL 2.4 — Tue, 22 Jul 2014 04:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

i/r typo

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

    In Integer::/ change "r is equal" to "i is equal"

  • Reported: OCL 2.4 — Tue, 22 Jul 2014 04:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

Missing/Poor definition of iterate()

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

    The non-normative text defines iterate() and suggests that all iterators may be defined in terms of iterate() and notes that the use of iterate() on Bag/Set is indeterminate.

    The normative text omits iterate() and states that all iterators are defined in terms of iterate().

    Suggest: Add iterate() to Section 11.

    Suggest: explicitly asSequence() all unordered iterate() inputs.

    Suggest: retract availability of iterate() on Bag/Set forcing an explicit asSequence().

  • Reported: OCL 2.4 — Sat, 18 Jan 2014 05:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

Reverse CollectionRange should be empty rather than invalid

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

    The clarification of Issue 15836 is too strong.

    For an empty collection it is im,portant that

    let s = Sequence{} in Sequence

    {1..s->size()}

    is Sequence{}, i.e. the valid indexes of an empty Sequence are empty not invalid.

  • Reported: OCL 2.4 — Thu, 3 Oct 2013 04:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

Obsolete implicit cast to Bag

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

    Descriptions of Collection::InEmpty(), notEmpty() refer to the implicit cast to Bag rather than use of oclAsSet().

  • Reported: OCL 2.4 — Tue, 22 Jul 2014 04:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

Coolection operations do not allow invalid inputs

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

    Add not oclIsInvalid() precondition on all non-Collection inputs.

    e.g including(object : T)

    pre: not object.oclIsInvalid()

  • Reported: OCL 2.4 — Tue, 22 Jul 2014 04:00 GMT
  • Updated: Thu, 8 Oct 2015 14:11 GMT

Missing mode precondition

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

    To Integer::mod all

    pre: i <> 0

  • Reported: OCL 2.4 — Tue, 22 Jul 2014 04:00 GMT
  • Updated: Thu, 8 Oct 2015 14:11 GMT