${taskforce.name} Avatar
  1. OMG Task Force

OCL 2 RTF — Closed Issues

  • Key: OCL21
  • Issues Count: 160
Open Closed All
Issues resolved by a task force and approved by Board

Issues Summary

Key Issue Reported Fixed Disposition Status
OCL21-354 Section 8.3.9 of the final Adopted Version of the OCL 2.0 Spec OCL 2.0b1 OCL 2.1 Resolved closed
OCL21-353 Section: A/2.3 Enumeration Types OCL 2.0 OCL 2.1 Resolved closed
OCL21-347 Exact type of Set{} and missing Set(MyType){} literal definitions OCL 2.0 OCL 2.1 Resolved closed
OCL21-346 Use of simple quotes and double quotes in strings OCL 2.0 OCL 2.1 Resolved closed
OCL21-339 Missing definition of of iterators for OrderedSets OCL 2.0 OCL 2.1 Resolved closed
OCL21-338 Type of a type expression OCL 2.0 OCL 2.1 Resolved closed
OCL21-345 Use of MOF reflection in EssentialOCL should be clarified OCL 2.0 OCL 2.1 Resolved closed
OCL21-344 No way to represent type parameters in the standard library OCL 2.0 OCL 2.1 Resolved closed
OCL21-336 OCL 2.0 8.2 Collection Type packaging OCL 2.0 OCL 2.1 Resolved closed
OCL21-335 Section: A.3.2.2 Syntax and Semantics of Postconditions OCL 2.0 OCL 2.1 Resolved closed
OCL21-342 Making OclAny denote any object OCL 2.0 OCL 2.1 Resolved closed
OCL21-337 OCL 2.0: CollectionType constraint for invalid elements is incorrect OCL 2.0 OCL 2.1 Resolved closed
OCL21-341 Clarify the common supertype of Bag and Sequence OCL 2.0 OCL 2.1 Resolved closed
OCL21-340 The operation asSet, asSequence, asBag and asOrderedSet missing for OrderedSets OCL 2.0 OCL 2.1 Resolved closed
OCL21-334 Section: A.3.1.2 Semantics of Expressions OCL 2.0 OCL 2.1 Resolved closed
OCL21-343 Incosistency between UnlimitedInteger and UnlimitedNatural OCL 2.0 OCL 2.1 Resolved closed
OCL21-292 Dynamic typing with allInstances() OCL 2.0 OCL 2.1 Resolved closed
OCL21-291 missing closing parethesis inthese two expressions OCL 2.0 OCL 2.1 Resolved closed
OCL21-289 Usage of initialization and derivation constraints on the same property OCL 2.0 OCL 2.1 Resolved closed
OCL21-288 Collection element type serialization OCL 2.0 OCL 2.1 Resolved closed
OCL21-294 Section 8.2 InvalidType OCL 2.0 OCL 2.1 Resolved closed
OCL21-293 Section: 7.4.7, 7.4.9, 9.3.2 OCL 2.0 OCL 2.1 Resolved closed
OCL21-287 TypeType OCL 2.0 OCL 2.1 Resolved closed
OCL21-286 ownership of association ends does not matter for traversal in OCL OCL 2.0 OCL 2.1 Resolved closed
OCL21-284 11.7.1 OCL 2.0 OCL 2.1 Resolved closed
OCL21-283 11.2.5 (02) OCL 2.0 OCL 2.1 Resolved closed
OCL21-290 8.2.2 Well-formedness Rules for the Types Package OCL 2.0 OCL 2.1 Resolved closed
OCL21-281 11.8.1 OCL 2.0 OCL 2.1 Resolved closed
OCL21-280 11.2.4 (OclInvalid) - similar criticism as 11.2.3 OCL 2.0 OCL 2.1 Resolved closed
OCL21-282 11.2.5 OCL 2.0 OCL 2.1 Resolved closed
OCL21-285 Naming of Constraints in OCL OCL 2.0 OCL 2.1 Resolved closed
OCL21-274 Section: 7.4.9 OCL 2.0 OCL 2.1 Resolved closed
OCL21-273 Using "def" OCL 2.0 OCL 2.1 Resolved closed
OCL21-275 Section: 7.8 OCL 2.0 OCL 2.1 Resolved closed
OCL21-278 Section "IteratorExpCS" OCL 2.0 OCL 2.1 Resolved closed
OCL21-277 Section 9.2.2 OCL 2.0 OCL 2.1 Resolved closed
OCL21-279 11.2.3 OCL 2.0 OCL 2.1 Resolved closed
OCL21-276 Section 7.6.3 OCL 2.0 OCL 2.1 Resolved closed
OCL21-349 The following collection operations would be useful for the HL7 GELLO project: OCL 2.0 OCL 2.1 Resolved closed
OCL21-348 The concrete syntax given is extremely difficult to implement OCL 2.0 OCL 2.1 Resolved closed
OCL21-352 have tuple fields and let variables to have the declaration of their types explicity? OCL 2.0 OCL 2.1 Resolved closed
OCL21-351 type of the iterator variable is expected or not? OCL 2.0 OCL 2.1 Resolved closed
OCL21-350 doubts about the iterator variables OCL 2.0 OCL 2.1 Resolved closed
OCL21-295 CollectionType and CollectionKind OCL 2.0 OCL 2.1 Resolved closed
OCL21-307 no explanations about how to manipulate optional and multivalued attributes OCL 2.0 OCL 2.1 Resolved closed
OCL21-306 section 7.4.6 (p. 12) OCL 2.0 OCL 2.1 Resolved closed
OCL21-297 Section: A/1.1.1 Types OCL 2.0 OCL 2.1 Resolved closed
OCL21-296 last line on page 28 OCL 2.0 OCL 2.1 Resolved closed
OCL21-304 Section: A/1.2.4 System State OCL 2.0 OCL 2.1 Resolved closed
OCL21-303 Section: A/1.2.1 Objects OCL 2.0 OCL 2.1 Resolved closed
OCL21-302 Section: A/1.1.6 Generalization - editorial issues OCL 2.0 OCL 2.1 Resolved closed
OCL21-300 Section: A/1.1.5 Associations OCL 2.0 OCL 2.1 Resolved closed
OCL21-299 Section: A/1.1.5 Associations -- missing word OCL 2.0 OCL 2.1 Resolved closed
OCL21-301 Section: A/1.1.6 Generalization OCL 2.0 OCL 2.1 Resolved closed
OCL21-298 Section: A/1.1.5 Associations OCL 2.0 OCL 2.1 Resolved closed
OCL21-305 Section: A/2.2 Common Operations on All Types OCL 2.0 OCL 2.1 Resolved closed
OCL21-333 Section: A.2.5.8 Sequence Operations OCL 2.0 OCL 2.1 Resolved closed
OCL21-332 Section: A.3.1.2 Semantics of Expressions, Definition A.30 part ii OCL 2.0 OCL 2.1 Resolved closed
OCL21-327 Section 8.2.1 Type Conformance on page 37 OCL 2.0 OCL 2.1 Resolved closed
OCL21-330 Section: A.3.1.1 Syntax of Expressions OCL 2.0 OCL 2.1 Resolved closed
OCL21-329 Section: A.2.7 Type Hierarchy OCL 2.0 OCL 2.1 Resolved closed
OCL21-326 Section: A.2.6.1 Definition A.26 (Special Types) OCL 2.0 OCL 2.1 Resolved closed
OCL21-325 Section: A.2.6 Special Types OCL 2.0 OCL 2.1 Resolved closed
OCL21-322 Section: A.3.1.1 Syntax of Expressions OCL 2.0 OCL 2.1 Resolved closed
OCL21-324 Syntax of Expressions (second sentence after Definition A..29) OCL 2.0 OCL 2.1 Resolved closed
OCL21-323 Section: A.3.1.1 Syntax of Expressions (Definition A.29) OCL 2.0 OCL 2.1 Resolved closed
OCL21-331 Section: A.3.1.2 Semantics of Expressions OCL 2.0 OCL 2.1 Resolved closed
OCL21-328 Section 8.2 page 35 InvalidType OCL 2.0 OCL 2.1 Resolved closed
OCL21-321 Section: A.3.1.1 Syntax of Expressions OCL 2.0 OCL 2.1 Resolved closed
OCL21-311 Section: A/2.3 Enumeration Types -- editorial OCL 2.0 OCL 2.1 Resolved closed
OCL21-310 The constraint [1] on the TupleLiteralPart metaclass is overconstrained OCL 2.0 OCL 2.1 Resolved closed
OCL21-313 Section: A.2.5.2 Definition A.24 (Type Expressions) OCL 2.0 OCL 2.1 Resolved closed
OCL21-312 Section: Definition A.23 (Semantics of Navigation Operations) OCL 2.0 OCL 2.1 Resolved closed
OCL21-317 There are two instances of missing and misplaced parentheses OCL 2.0 OCL 2.1 Resolved closed
OCL21-316 A.2.5.5 Collection Operations OCL 2.0 OCL 2.1 Resolved closed
OCL21-320 Section: A.2.5.8 Sequence Operations OCL 2.0 OCL 2.1 Resolved closed
OCL21-319 Section: A.2.5.6 Set Operations Table A.4 OCL 2.0 OCL 2.1 Resolved closed
OCL21-309 OrderedSet collection OCL 2.0 OCL 2.1 Resolved closed
OCL21-318 Section: A.2.5.6 Set Operations OCL 2.0 OCL 2.1 Resolved closed
OCL21-314 Section: A.2.5.5 Collection Operations OCL 2.0 OCL 2.1 Resolved closed
OCL21-315 Section: A/2.5.5 Collection Operations - just before table A.3 OCL 2.0 OCL 2.1 Resolved closed
OCL21-308 The Tuple constructor is problematic OCL 2.0 OCL 2.1 Resolved closed
OCL21-270 Section: 7.3.4 OCL 2.0 OCL 2.1 Resolved closed
OCL21-269 Wrong subtyping of PropertyCallExp and NavigationCallExp OCL 2.0 OCL 2.1 Resolved closed
OCL21-268 inability to uniquely reference association ends OCL 2.0 OCL 2.1 Resolved closed
OCL21-267 Introduction and oclType() OCL 2.0 OCL 2.1 Resolved closed
OCL21-266 Circular imports OCL 2.0 OCL 2.1 Resolved closed
OCL21-272 Section: 7.5.9 OCL 2.0 OCL 2.1 Resolved closed
OCL21-271 Section: 8.3.5 OCL 2.0 OCL 2.1 Resolved closed
OCL21-248 sub evaluations (02) OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-247 sub evaluations OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-254 Section: 7.5.11 OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-253 Section: 7.5.9 OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-246 value of a collection range OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-245 value of a collection range OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-249 Section: 6.5.4.3 Combining Properties OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-243 result value of an attribute call expression OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-251 Section: 7.4.5 OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-252 Section: 7.5.3 OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-250 Section: 7.4 OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-244 result value of a collection literal expression evaluation OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-204 Issue: Syntax of Operation Call, Iterator, and Iterate Expressions OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-203 Issue: Abstract syntax tree OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-208 The notation for selecting elements should be more intuitive OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-207 The notation for testing the type of a metaclass is too verbose OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-206 Example with TupleType OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-211 Improve the notation when defining local variables OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-210 There is no simple way to invoke an "if then else" on a collection OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-209 notation for selecting unique element within a list should be more concise OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-216 Provide specific notational support when testing stereotypes OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-215 Suppress the usage of an Ocl prefix in standard library operations OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-202 Issue: Unspecified syntax and semantics for Integer, Real, and String OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-213 Allow implicit type casting to boolean when a boolean is expected OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-212 Allow applying iteration operations on single objects OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-214 Automatic casting between strings and enumeration values OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-217 Add a generic text formatter operator '% OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-205 The index seems incomplete OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-234 arguments of the return message of an ocl message expression OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-233 inv: model.sentSignal->size() = 1 implies OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-236 ’element’ should be ’elements’ OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-235 Only one of the attributes isPost and isPre may be true at the same time. OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-242 elements in a tuple value OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-232 arguments OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-240 The history of an object is ordered.(02) OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-241 The operation allPredecessors OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-239 history of an object is ordered. OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-238 ’Element’ should be ’NameValueBinding’ OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-237 ’element’ should be ’elements’ (02) OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-198 Add select/reject/collectNested to Collection OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-197 Exception of strict evaluation (queries) OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-201 Issue: Virtual machine OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-200 Clarify the UML semantics of IfExpEval OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-195 Exception of strict evaluation (implies) OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-196 Exception of strict evaluation (forAll, exists) OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-199 Clarify the semantics of forAll OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-265 Notation for accessing class operations is inconsistent OCL 2.0 OCL 2.1 Resolved closed
OCL21-264 Navigating across non navigable associations OCL 2.0 OCL 2.1 Resolved closed
OCL21-263 allInstances OCL 2.0 OCL 2.1 Resolved closed
OCL21-261 Section: 1 - 13 OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-260 Section: 11.9.3 & 11.9.4 OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-258 Section: 11.2.1 OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-257 Section: 10.2.2 LocalSnapshot OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-255 Section: 7.5.13 OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-262 The spec does not describes the syntax of integer, real or string literals OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-259 Section: 11.5.4 OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-256 Section: 7.6.2 OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-219 rewrite well-formedness OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-218 Make usage of tuples less complex and less verbose OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-225 sub evaluations (in the sequence bodyEvals) OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-224 context IfExpEval inv: OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-228 isSent attribute OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-227 ocl message expression OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-231 an iterate expression evaluation OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-230 missing ’inv:’ twice OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-222 1] The type of the attribute is the type of the value expression. OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-221 An additional attribute refParams lists all parameters of the referred OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-226 sub evaluations (in sequence bodyEvals) have different environment. OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-229 add ’and’ between both expression parts OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-223 context LocalSnapshot OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-220 context State::getStateMachine() : StateMachine OCL 2.0b2 OCL 2.1 Resolved closed

Issues Descriptions

Section 8.3.9 of the final Adopted Version of the OCL 2.0 Spec

  • Key: OCL21-354
  • Legacy Issue Number: 8922
  • Status: closed  
  • Source: Anonymous
  • Summary:

    I refer to Section 8.3.9 of the final Adopted Version of the OCL 2.0 Spec,
    the two additional operations on the OclExpression.
    "withAtPre" and "withAsSet".
    I am wondering where the two referred operations "atPre" and "asSet"
    (not restricted to collections) are "predefined".

  • Reported: OCL 2.0b1 — Fri, 30 Jun 2000 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 13:51 GMT

Section: A/2.3 Enumeration Types

  • Key: OCL21-353
  • Legacy Issue Number: 12457
  • Status: closed  
  • Source: Anonymous
  • Summary:

    This may be simply my misunderstanding of what is intended. In the final sentence before Definition A.18 (Semantics of Enumeration Types), the word "interpreted" seems inappropriate. "Defined" is often used in such sentences is mathematics. I just wanted to draw attention to this in case it is a mistake. If not then my apologies

  • Reported: OCL 2.0 — Wed, 14 May 2008 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    issue withdrawn by submitter

  • Updated: Fri, 6 Mar 2015 22:56 GMT

Exact type of Set{} and missing Set(MyType){} literal definitions

  • Key: OCL21-347
  • Legacy Issue Number: 12953
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    Summary:
    It is not clear what is the concrete type of Set{}. Is it Set(Object), Set(Void)
    Also it seems there is no way to explicitly define an empty collection with a given
    type for the elements.

  • Reported: OCL 2.0 — Fri, 10 Oct 2008 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    Discussion of this issue suggested a number of options:
    Option 1: The type of Set{} is Set(OclVoid)
    This does not work because
    Set{}->including(1)
    is an error since "1" or indeed anything other than null or invalid does not
    conform to OclVoid.
    Option 2: The type of Set{} is Set(OclAny)
    This does not work because
    acc : Set(Integer) = Set{}->including(1)
    is an error since Set(OclAny) is not compatible with Set(Integer).
    Option 3: The type of Set{} is a new built-in type EmptySet(ET) where ET is
    determined in some way.
    This does not work because given the RHS of
    acc : Set(Integer) = Set{}>including(1.0)
    >including(Classifier)>excluding(1.0)>excluding(Classifier)
    it is difficult to see how ET could be determined more precisely than OclAny
    causing the same problem as Option 2.
    Option 4: The type of Set{} is Set(null)
    Since Set{} and Set(null) have no precise OCL 2.1 semantics there is some
    discretion in defining them, but eventually a dynamic type validation is needed for
    acc : Set(String) = Set(null)

    {getInitialValue()}

    . The impact on evaluation could be
    mitigated by synthesis of an oclAsType() in the Abstract Syntax Tree, but it is not
    18
    possible to provide a static type for the CollectionLiteralExp. This option could
    work but requires revision of abstract syntax and evaluation specifications.
    Option 5: The type of Set{} is back-propagated
    For instance in
    acc : Set(Real) = Set{}>including(1)>including(-1)
    the type of Set{} is Set(Real) since that is the eventual result type. This involves
    unusual reverse semantics.
    Option 6: The type of Set{} is Set(T) with T chosen for well-formedness of the
    expression in which the Set{} is used.
    For instance in
    acc : Set(Real) = Set{}>including(1)>including(-1)
    the type of Set{} is initially Set(T) where T <= OclVoid. Propagation of the type to
    Set(T)::including(UnlimitedNatural) requires T <= UnlimitedNatural. Propagation
    to Set(T)::including(Integer) requires T <= Integer. Finally, propagation to the
    initializer requires Real <= T. Therefore any Real <= T <= Integer is well-formed.
    The lower bound, Set(Real), is preferred since it avoids many type conversions.
    It is also the same result as Option 5.
    Option 6 involves only additional forward static semantics, has no impact on
    evaluation, no impact on parsing, and gives the intuitively correct OCL 2.1
    results.


    In order to impose a user-specified element type and so get static type checking
    of user intent, a collection element type can be specified as:
    acc : Set(Integer) = Set(Integer){}
    It is difficult to parse this in OCL 2.1 because Set is not a reserved word and so
    lookahead is required to determine whether Set(someName) is the start of a
    StringLiteralExpCS or an OperationCallExpCS, with someName perhaps being a
    complicated nested type/value ambiguity.
    Issue 14357 introduces the concept of a restricted word preventing the
    unqualified use of Set as an operation name. The extension is then
    straightforward.

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

Use of simple quotes and double quotes in strings

  • Key: OCL21-346
  • Legacy Issue Number: 12952
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    Summary: Use of simple quotes in place of double quotes should be allowed,
    Specially in situations where the string contains double quotes (to avoid explicit
    use of escaping characters).

  • Reported: OCL 2.0 — Fri, 10 Oct 2008 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    The freedom to use single or double quotes risks causing confusion for novices as well as being helpful. OCL is the basis for extended languages which may have their own usage for double quotes, so extending OCL into this syntax area seems unwise.
    Disposition: Closed, no change

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

Missing definition of of iterators for OrderedSets

  • Key: OCL21-339
  • Legacy Issue Number: 12945
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    Summary:Since the iterators are redefined for each concrete collection type
    We would expect a "11.9.5 OrderedSet" section.
    Moreover, when defining nestedCollect for OrderedSet we should expect the type
    to be a Sequence (in constrast to Set::nestedCollect which type is a Bag).

  • Reported: OCL 2.0 — Fri, 10 Oct 2008 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    The missing operations are added. Notice that the list of operations is the union of those supported by sequences and those supported by sets.

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

Type of a type expression

  • Key: OCL21-338
  • Legacy Issue Number: 12944
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    In the TypeExp definition (within section 8.3) there is no indication of what is the
    type returned by a type expression. Is it the generic object representing all types
    (oclType) or the referred type itself?
    We guess it is the referred type itself, but this need to be explicitly stated.

  • Reported: OCL 2.0 — Fri, 10 Oct 2008 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    Disposition: See issue 9171 for disposition

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

Use of MOF reflection in EssentialOCL should be clarified

  • Key: OCL21-345
  • Legacy Issue Number: 12951
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    Summary: There is no clear indication weather MOF reflection is available
    in EssentialOCL (except in the provided xmi, ecore files of essential ocl).

  • Reported: OCL 2.0 — Fri, 10 Oct 2008 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    The BasicOCL/EssentialOcl cannot merge EMOF reflection since we have conflict in metaclasses. The role of Object is played by AnyType. At M1 level, OCL has its own reflection mechanism. A clarification sentence is added.

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

No way to represent type parameters in the standard library

  • Key: OCL21-344
  • Legacy Issue Number: 12950
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    Summary: The OCL metamodel does not provide means to encode type parameters
    in operations like the generic ones that are defined by Collection type in the standad library.

  • Reported: OCL 2.0 — Fri, 10 Oct 2008 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    Adding a TemplateParameterType. This promotes the solution to this problem as found in QVT.

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

OCL 2.0 8.2 Collection Type packaging

  • Key: OCL21-336
  • Legacy Issue Number: 12582
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    [Pending a resolution of Issue 10946]

    In order to use a collection type, it is is necessary to define that
    type and provide some container for it. OCL provides no guidance on
    what that container should be, or upon what the relative semantics of
    A::Set(E) is with respect to B::Set(E).

    QVT 1.0 has defined all CollectionType(ElementType) to be the same type
    regardless of the accidental package used for their containment.

    OCL should adopt the QVT definition (even if 10946 is adopted).

  • Reported: OCL 2.0 — Sat, 19 Jul 2008 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    Resolution of issue 9171 contains an statement saying that collection instances may be in different containers and still represent the same type.

    Disposition: See issue 9171 for disposition

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

Section: A.3.2.2 Syntax and Semantics of Postconditions

  • Key: OCL21-335
  • Legacy Issue Number: 12493
  • Status: closed  
  • Source: Net.Orange (i.e. Net Dot Orange) ( Garr Lystad)
  • Summary:

    In the paragraph before Definition A.32 you will find, "An environment p = (s, ß is a pair ...." The closing paren. after ß is missing

  • Reported: OCL 2.0 — Thu, 15 May 2008 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

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

Making OclAny denote any object

  • Key: OCL21-342
  • Legacy Issue Number: 12948
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    Summary: In the actual OCL2 spec OclAny represents any object except collections.
    However this is unaligned with UML2 and MOF2 where such kind of type does not exist
    Instead in MOF we have the generic Object which represents any object including
    primitive and collection values.
    Also, looking at the list of operations defined for OclAny we see that there is no real
    justification for creating this special type. Operations like 'allInstances' and 'oclIsNew' are
    also invalid for primitive types and hence are not specifically invalid for collections.
    Making OclAny to represent any object (equivalent to MOF::Object) will simplify the stdlib
    and will be consistent with UML2 and MOF2.

  • Reported: OCL 2.0 — Fri, 10 Oct 2008 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    OclAny denotes now any object including collections. This makes the type system aligned with MOF.

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

OCL 2.0: CollectionType constraint for invalid elements is incorrect

  • Key: OCL21-337
  • Legacy Issue Number: 12943
  • Status: closed  
  • Source: Zeligsoft, Inc. ( Christian Damus)
  • Summary:

    The second constraint on CollectionType in Section 8.2.2 does not make
    sense. The instances of CollectionType are not collections, but the
    types of collections. Thus, a collection type does not have elements
    to be iterated. This constraint should be struck from Section 8.2.2:

    [1] A collection cannot contain OclInvalid values.
    context CollectionType
    inv: self->forAll(not oclIsInvalid())

    and replaced by a new invariant constraint in Section 11.7.1
    “Collection” (which currently has no well-formedness rules):

    [1] A collection cannot contain OclInvalid values.
    context Collection
    inv: self->forAll(not oclIsInvalid())

  • Reported: OCL 2.0 — Thu, 9 Oct 2008 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    As OCL does not permit the invalid value in a collection (as opposed to the null value), it should be made explicit that the evaluation of collection literals containing invalid results in invalid. The CollectionType constraint in Section 8.2.2 attempts to express this, but is incorrect because it is defined on the wrong meta-level (on CollectionType instead of Collection).

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

Clarify the common supertype of Bag and Sequence

  • Key: OCL21-341
  • Legacy Issue Number: 12947
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    Summary:
    Does an OrderedSet conforms to a Set? Does an OrderedSet conforms to a Sequence?
    It seems that there is no automatic conformance between these concrete collection
    types (hence an explicit conversion need to be done when needed)
    However, for clarification, this should be stated in the definition of the respective concrete
    collection types to avoid OCL writers making wrong assumptions.

  • Reported: OCL 2.0 — Fri, 10 Oct 2008 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    Adding clarification sentences

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

The operation asSet, asSequence, asBag and asOrderedSet missing for OrderedSets

  • Key: OCL21-340
  • Legacy Issue Number: 12946
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    The operation asSet, asSequence, asBag and asOrderedSet are not defined for
    OrderedSets in 11.7.3. Also, since these operations are available in all collections
    we would expect their definition at Collection level.

  • Reported: OCL 2.0 — Fri, 10 Oct 2008 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    Disposition: See issue 4451 for disposition

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

Section: A.3.1.2 Semantics of Expressions

  • Key: OCL21-334
  • Legacy Issue Number: 12491
  • Status: closed  
  • Source: Net.Orange (i.e. Net Dot Orange) ( Garr Lystad)
  • Summary:

    It would be nice to have a definition of ß{x / y) in association with Definition A.30. Maybe it's defined elsewhere, but I don't see it. From what's written in this section, including the explanation of iteration on page 205 and 206, I get only a vague idea. P.S. So realizing now that this is not a typo, my revision request two previous to this (if I've counted correctly) should be ignored. That was the one about part ii of Definition A.30.

  • Reported: OCL 2.0 — Thu, 15 May 2008 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    The notation "\" is the standard notation for substitution (e.g., see Winskel's book
    on formal semantics). Thus, there seems to be no need to add an explanation in
    the standard.

    Disposition: Closed, no change

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

Incosistency between UnlimitedInteger and UnlimitedNatural

  • Key: OCL21-343
  • Legacy Issue Number: 12949
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    Summary: In Figure 8.6 we have UnlimitedNatural but in other parts of the spec there is
    a UnlimitedInteger definition.

  • Reported: OCL 2.0 — Fri, 10 Oct 2008 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

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

Dynamic typing with allInstances()

  • Key: OCL21-292
  • Legacy Issue Number: 11097
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Tomas Juknevicius)
  • Summary:

    I have an issue with OclAny::allInstances() method, as described in the
    11.2.5 section of the OCL2 spec (06-05-01.pdf).

    If I understand correctly, OCL is a statically typed language (e.g. as stated
    in the beginning of 8.2 section or 8.3 section OclExpression paragraph).
    Every expression has a type and this type can be statically determined by
    analyzing the expression and its context.

    Most of the concepts in the OCL spec follows this rule, however I have
    an issue with the allInstances() method, defined on OclAny. Specifically,
    the "Returns all instances of self. Type T is equal to self." statement is problematic.

    When allInstances is used on the literal type specifier, there is no problem.
    E.g.

    context classFoo inv:
    somepackage::classBar.allInstances()->size() < self.limit

    Here, return type of the expression "somepackage::classBar.allInstances()" can be determined
    by static analysis ("at compile time") - it is Set(classBar).

    However when allInstances is invoked on variable, calculated by some expression,
    and all the staticallity of OCL crumbles and the hell breaks loose .
    And there are no restrictions, on what objects allInstances() can be invoked, the only rules are
    that the object to be classifier and the instance set be finite.

    E.g.
    (singleton rule - all the classes must have at most 1 instance)
    context Class inv:
    self.allInstances()->size() <= 1

    Now, what is the type of the self.allInstances() expression? Well, it depends on what is the self object -
    and self object is supplied at run time. If we evaluate this constraint on classFoo,
    we see that type of "self.allInstances()" must be Set(classFoo), if we evaluate this constraint on
    classBar, type of expression must be Set(classBar). Hence the type of expression can not be determined
    at "compile time", it must be determined at "run time".

    E.g. we have 2 classes classFoo and classBar; classFoo has a field someField, classBar doesn't.

    context whatever inv:
    let s:Set(Classifier) = Set

    {classFoo, classBar} in
    s->allInstances()>any(true)>any(true).someField = someValue


    Now what is the type of s->allInstances()>any(true)>any(true) expression?
    We have:
    expression |expression type |expression value
    ---------------------------------------------------------------------------------
    s |Set(Classifier) |Set{classFoo, classBar}

    s->allInstances() |Set(Set(???)) |Set

    { Set_of_instances_of_classFoo, Set_of_instances_of_classBar}

    s->allInstances()->any(true) |Set(???) |either Set_of_instances_of_classFoo or Set_of_instances_of_classBar
    s->allInstances()>any(true)>any(true) |???? |either instance of classFoo or instance of classBar

    Now the question arises: can we access someField property?
    Here we must have a runtime introspection check in the OCL evaluation code -
    if s->allInstances()>any(true)>any(true) returned instance of classFoo,
    we can access the field, if instance of classBar - we must runtime-fail here.

    Please advise. Is this a problem of the spec or I am wrong somewhere?

    Granted, we are making jumps 2 levels down in metamodel hierarchy here
    (first from metamodel to model elements-classes, then from classes to instances of those classes),
    but there is nothing in the spec, what precludes this.

  • Reported: OCL 2.0 — Mon, 11 Jun 2007 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

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

missing closing parethesis inthese two expressions

  • Key: OCL21-291
  • Legacy Issue Number: 11086
  • Status: closed  
  • Source: YMS ( Peter Klein)
  • Summary:

    missing closing parethesis inthese two expressions: [2]The parameters of the referredOperation become attributes of the instance of MessageType. context MessageType: inv: referredOperation->size()=1 implies Set

    {1..self.ownedAttribute->size()}>forAll(i | self.ownedAttribute.at.cmpSlots( referredOperation.ownedParameter.asProperty()>at) [3]The attributes of the referredSignal become attributes of the instance of MessageType. context MessageType inv: referredSignal->size() = 1 implies Set{1..self.ownedAttribute->size()}

    >forAll(i | self.ownedAttribute.asOrderedSet().at.cmpSlots( referredSignal.ownedAttribute.asOrderedSet()>at)

  • Reported: OCL 2.0 — Thu, 31 May 2007 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

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

Usage of initialization and derivation constraints on the same property

  • Key: OCL21-289
  • Legacy Issue Number: 10969
  • Status: closed  
  • Source: International Business Machines ( Andreas Maier)
  • Summary:

    The OCL 2.0 spec seems to allow usage of initialization constraints
    and derivation constraints on the same property. For example in
    7.3.7, it says "Initial and derivation expressions may be mixed
    together after one context.", which is a string indication that it is
    not precluded. Having both initialization and derivation constraints
    is an overspecification of the initial value of the property, since
    the derivation constraint must be satisfied at any time, which
    probably includes the initialization time.

    Also, the spec does not seem to contain a statement about how many
    initialization and derivation constraints are allowed on a property.
    By the nature of these constraints, it seems sensible to have at most
    one of them.

    The following clarifications are suggested to address this issue:
    (1) clarify whether "at any time" for derivation constraints
    includes the initialization. Suggestion: Derivation should include
    initialization.
    (2) clarify whether both kinds of constraints are allowed on the
    same property. Suggestion: Both are allowed but must not be
    contradictory.
    (3) clarify how many initialization and derivation constraints are
    allowed on a property. Suggestion: At most one initialization
    constraint and at most one derivation constraint.

  • Reported: OCL 2.0 — Wed, 25 Apr 2007 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

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

Collection element type serialization

  • Key: OCL21-288
  • Legacy Issue Number: 10946
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    The OCL abstract syntax for Collections has no property to persist the element type
    of the collection.

    It is therefore not possible to serialise a TypeExp.referredType referring to
    for example OrderedSet(String) without synthesising an
    OrderedSet_String and finding some artificial scope for it .. and then encountering
    ambiguities as to whether two distinct OrderedSet_String types are really distinct.

    Suggest:

    Introduce a CollectionTypeExp extending TypeExp to add
    CollectionTypeExp.referredElementType : Type[0..1]
    with the constraint that the inherited TypeExp.referredType be a collection type.

  • Reported: OCL 2.0 — Mon, 26 Mar 2007 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

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

Section 8.2 InvalidType

  • Key: OCL21-294
  • Legacy Issue Number: 12378
  • Status: closed  
  • Source: Steria Mummert Consulting AG ( Torsten Binias)
  • Summary:

    For the InvalidType it is stated that: "The only instance of InvalidType is Invalid, which is further defined in the standard library. Furthermore Invalid has exactly one runtime instance called OclInvalid." It should read: "The only instance of InvalidType is OclInvalid, which is further defined in the standard library. Furthermore OclInvalid has exactly one runtime instance called invalid." because this is in line with ch. 11.2.4, p. 138:"It [OclInvalid] has one single instance called invalid. [...] OclInvalid is itself an instance of the metatype InvalidType

  • Reported: OCL 2.0 — Mon, 14 Apr 2008 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

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

Section: 7.4.7, 7.4.9, 9.3.2

  • Key: OCL21-293
  • Legacy Issue Number: 11098
  • Status: closed  
  • Source: Jet Propulsion Laboratory / Caltech ( Nicolas F. Rouquette)
  • Summary:

    The operator precedence rules in 9.3.2 are identical to the precedence rules in 7.4.7. Both sets are incomplete in that they do not specify the precedence of the 'let' operator. For example, in a UML profile, a constraint on a 'Property' stereotype might be: not self.base_Property.allNamespaces()>exists(oclIsKindOf(Profile) or oclIsKindOf(Stereotype)) implies let prop:Property=self.base_Property in prop.defaultValue>isEmpty() To parse properly (with RSA 7.0.0.2), this constraint must instead be written as: not self.base_Property.allNamespaces()>exists(oclIsKindOf(Profile) or oclIsKindOf(Stereotype)) implies (let prop:Property=self.base_Property in prop.defaultValue>isEmpty()) This suggests that the 'let' operator has a lower precedence than that of the 'implies' operator. Of course, there is an alternative way to write this constraint that does not expose this issue: let prop:Property=self.base_Property in not prop.allNamespaces()>exists(oclIsKindOf(Profile) or oclIsKindOf(Stereotype)) implies prop.defaultValue>isEmpty() The suggestion is to revise 7.4.7 and 9.3.2 to account for all keywords in 7.4.9. The keywords defined in 7.4.9 but not accounted for in 7.4.7 or in 9.3.2 are: - attr - context - def - endpackage - in - inv - let - oper - package - post - pre The keywords referenced in 7.4.7 or in 9.3.2 that are not defined in 7.4.9 are: - @pre Nicolas F. Rouquette Principal Computer Scientist http://www.jpl.nasa.gov Jet Propulsion Laboratory, Caltech M/S 301-270 Pasadena, CA 91109, USA phone: +1-818-354-9600 fax: +1-818-393-4100 e-mail: nicolas.f.rouquette@jpl.nasa.gov

  • Reported: OCL 2.0 — Tue, 5 Jun 2007 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

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

TypeType

  • Key: OCL21-287
  • Legacy Issue Number: 10921
  • Status: closed  
  • Source: Hendryx & Associates ( Stan Hendryx)
  • Summary:

    I would like to log the following issue against OCL formal/06-05-01.

    TypeType, appearing on Fig. 8.1 (p.34), Fig. 13.1 (p.172), and section
    11.3.2 (p.140) is not defined

  • Reported: OCL 2.0 — Mon, 16 Apr 2007 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

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

ownership of association ends does not matter for traversal in OCL

  • Key: OCL21-286
  • Legacy Issue Number: 10825
  • Status: closed  
  • Source: International Business Machines ( Andreas Maier)
  • Summary:

    during work on the definition of the UML Profile for CIM (an activity
    performed jointly between OMG and DMTF), we recently found the following
    issue with OCL 2. Please record this issue officially and let me know the
    issue number for it.

    Issue: No explicit statement that ownership of association ends does not
    matter for traversal in OCL
    Nature: Clarification
    Severity: Minor
    Summary:

    The UML Superstructure spec 2.1.1 defines in section 6.5.2 "Diagram
    Format" that any meta-association has two ends, regardless of whether
    the ends are owned by the association or the associated classifiers.
    However, the Superstructure spec only describes those association
    ends that are owned by the associated classifiers. Furthermore, a
    major OCL engine (from Eclipse) does not currently support
    meta-association traversal in OCL towards ends owned by the
    meta-association.

    This may leave the impression to some readers that OCL would only
    support meta-association traversal in the direction of ends owned by
    the associated classifiers.

    I understand that the intention is in OCL to support traversal of
    meta-associations in any direction, regardless of whether the target
    end is owned by the association or the associated classifier. It
    would be helpful to state that explicitly in the OCL specification.

  • Reported: OCL 2.0 — Sat, 17 Mar 2007 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

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

11.7.1

  • Key: OCL21-284
  • Legacy Issue Number: 10438
  • Status: closed  
  • Source: NIST ( Mr. Peter Denno)
  • Summary:

    null "conforms to all other types." Thus I suppose null->isEmpty() and
    null->notEmpty() are defined. What do these methods evaluate to when applied
    to null? This should be discussed in this section.

  • Reported: OCL 2.0 — Thu, 2 Nov 2006 05:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

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

11.2.5 (02)

  • Key: OCL21-283
  • Legacy Issue Number: 10437
  • Status: closed  
  • Source: NIST ( Mr. Peter Denno)
  • Summary:

    oclAsType(typespec : OclType) : T
    "Evaluates to self, where self is of the type identified by typespec.
    post: (result = self) and result.oclIsTypeOf(typeName)

    (BTW , that ought to be "typespec" not typeName).

    This description is inadequate. The text in 7.4.6 describes the important
    condition on the use of this method ("An object can only be re-typed to one
    of its subtypes.") But chapter 7 is informative, not normative. Even with
    that text moved into 11.2.5, additional discussion is required. For example,
    referring to the properties that are only defined on the subtype, what would
    the value of those properties be, once the object is re-typed?

  • Reported: OCL 2.0 — Thu, 2 Nov 2006 05:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

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

8.2.2 Well-formedness Rules for the Types Package

  • Key: OCL21-290
  • Legacy Issue Number: 11085
  • Status: closed  
  • Source: YMS ( Peter Klein)
  • Summary:

    Thhis expression context TupleType inv: TupleType.allInstances()>forAll (t | ( t.allProperties()>forAll (tp | – make sure at least one tuplepart has the same name – (uniqueness of tuplepart names will ensure that not two – tupleparts have the same name within one tuple) self.allProperties()>exists(stp|stp.name = tp.name) and – make sure that all tupleparts with the same name conforms. self.allProperties()>forAll(stp | (stp.name = tp.name) and stp.type.conformsTo(tp.type)) ) implies self.conformsTo(t) ) ) should be context TupleType inv: TupleType.allInstances()>forAll (t | ( t.allProperties()>forAll (tp | – make sure at least one tuplepart has the same name – (uniqueness of tuplepart names will ensure that not two – tupleparts have the same name within one tuple) self.allProperties()>exists(stp|stp.name = tp.name) and – make sure that all tupleparts with the same name conforms. self.allProperties()>forAll(stp | (stp.name = tp.name) implies stp.type.conformsTo(tp.type)) ) implies self.conformsTo(t) ) ) it means "implies" instead of "and" in this part: (stp.name = tp.name) and stp.type.conformsTo(tp.type)

  • Reported: OCL 2.0 — Thu, 31 May 2007 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

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

11.8.1

  • Key: OCL21-281
  • Legacy Issue Number: 10435
  • Status: closed  
  • Source: NIST ( Mr. Peter Denno)
  • Summary:

    "When new iterator expressions are added to the standard library, there
    mapping to existing constructs should be fully defines.

    • What does that mean? It sounds like an admonition to spec writers.
    • also "defined" not "defines"
    • also "their" not "there"
  • Reported: OCL 2.0 — Thu, 2 Nov 2006 05:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

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

11.2.4 (OclInvalid) - similar criticism as 11.2.3

  • Key: OCL21-280
  • Legacy Issue Number: 10434
  • Status: closed  
  • Source: NIST ( Mr. Peter Denno)
  • Summary:

    11.2.4 (OclInvalid) - similar criticism as 11.2.3 (issue 10433)

  • Reported: OCL 2.0 — Thu, 2 Nov 2006 05:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

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

11.2.5

  • Key: OCL21-282
  • Legacy Issue Number: 10436
  • Status: closed  
  • Source: NIST ( Mr. Peter Denno)
  • Summary:

    oclIsTypeOf(typespec : OclType) : Boolean
    "Evaluates to true if the self is of the type identifid by typespec.."
    oclIsKindOf(typespec : OclType) : Boolean
    "Evaluates to true if the self conforms to the type identified by typespec"

    >From those descriptions I cannot distinguish these two. Isn't a dog "of the
    type" mammal" and wouldn't a dog "conform to the type" mammal? (Subtypes
    always conform to the supertype).

    I suspect that you intend that one of these evaluates to TRUE if and only if
    self is of type typespec and not also of a subtype of typespec . You might
    say just that.

  • Reported: OCL 2.0 — Thu, 2 Nov 2006 05:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

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

Naming of Constraints in OCL

  • Key: OCL21-285
  • Legacy Issue Number: 10782
  • Status: closed  
  • Source: Dell Technologies ( Mr. George Ericson)
  • Summary:

    I find in the OCL document section "7.3.3. Invariants" that I can name an invariant as in:

    "context" <contextdeclaration> "inv" <constraintname> ":" ...

    I haven't figured out how to parse the document well enough to be clear if this is formally defined.

    And the real question is whether this applies to pre, post, body, init, and derived constraints.

    Does it?

    If not it would be useful to add.

  • Reported: OCL 2.0 — Thu, 8 Feb 2007 05:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

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

Section: 7.4.9

  • Key: OCL21-274
  • Legacy Issue Number: 10344
  • Status: closed  
  • Source: None (Graduate from MSC Univ of Brighton UK looking for job) ( Guillaume Finance)
  • Summary:

    Hi, I'm reading through the latest OCL spec to get up to date before applying for a System Analyst job, I saw a possible minor issue in the list of the OCL keywords. Indeed, having read it so far, I would add the following ones but pls let me know if there is a reason why it wouldnt apply: body, derive, init, and self

  • Reported: OCL 2.0 — Mon, 11 Sep 2006 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

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

Using "def"

  • Key: OCL21-273
  • Legacy Issue Number: 9915
  • Status: closed  
  • Source: LIANTIS GmbH ( Constantin Szallies)
  • Summary:

    Using "def" I would like to specify static (classifier scoped) properties and operations.

  • Reported: OCL 2.0 — Tue, 11 Jul 2006 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

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

Section: 7.8

  • Key: OCL21-275
  • Legacy Issue Number: 10346
  • Status: closed  
  • Source: None (Graduate from MSC Univ of Brighton UK looking for job) ( Guillaume Finance)
  • Summary:

    Hello I recently wrote a comment about the OCL keyword list to amend if I'm correct. As I continue reading through the specification, I found that in "7.8 Resolving Properties", 2 inv contraints are specified and mentionned to have a different meaning. I specified the difference between the 2 below and was wondering if you wanted maybe to check that 1. it was correct and 2. add it to the specs so people can make sure they understand well where the difference stands, despite it is fairly straightforward from the explanation in this chapter. >From your specs: context Person inv: employer->forAll(employee->exists(p | p.lastName = name)) inv: employer->forAll(employee->exists(self.lastName = name)) Given explanation on the difference: Invariant constraint 1: Specifies that in the Company a person works for, there exists for all the employees of the company (Person instances) the value of their attribute lastName matching the value of the attibute Name in an instance of Company Invariant constraint 2: Specifies that in the Company a person works for, there exists for all the employees of the company (Person instances) the value of the person's attribute lastName matching the value of the attibute Name in an instance of Company iterator The difference is that in the invariant 1, we specify that the value of the lastName attribute for all the Person instances employed by a company must be found in an instance of the Company by matching the name attribute's value, whereas in the invariant 2, we specify that the value in the lastName attribute of a Person p working for a Company must match the value of the name's attribute in one of the Company's set of Person/employees, thus its related instance. I hope it makes sense and look forward hearing about your comments.

  • Reported: OCL 2.0 — Tue, 12 Sep 2006 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

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

Section "IteratorExpCS"

  • Key: OCL21-278
  • Legacy Issue Number: 10432
  • Status: closed  
  • Source: NIST ( Mr. Peter Denno)
  • Summary:

    There is a left-paren in rule [A] . Rules [D] and [E] are identical.

  • Reported: OCL 2.0 — Thu, 2 Nov 2006 05:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

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

Section 9.2.2

  • Key: OCL21-277
  • Legacy Issue Number: 10431
  • Status: closed  
  • Source: NIST ( Mr. Peter Denno)
  • Summary:

    "The OCL specification puts no restriction on visibility."

    I don't think this statement is true. For example, self is bound to the
    instance in context. There is a whole prior section on scoping.

  • Reported: OCL 2.0 — Thu, 2 Nov 2006 05:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

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

11.2.3

  • Key: OCL21-279
  • Legacy Issue Number: 10433
  • Status: closed  
  • Source: NIST ( Mr. Peter Denno)
  • Summary:

    "The type OclVoid is a type that conforms to all other types. It has one
    single instance called null which corresponds with the UML Null Literal value
    specification. "

    This text could be clearer. What does "called null" mean? Is it saying that
    the name "null" refers to this instance? A suggested rewrite: "It has one
    instance, identified by 'null.' The instance null corresponds to the UML Null
    Literal."

  • Reported: OCL 2.0 — Thu, 2 Nov 2006 05:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

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

Section 7.6.3

  • Key: OCL21-276
  • Legacy Issue Number: 10430
  • Status: closed  
  • Source: NIST ( Mr. Peter Denno)
  • Summary:

    "The forAll operation has an extended variant in which more than one iterator
    is used. Both iterators..."

    Which is it "more than one" (two, three...) or "Both" (two) ?

  • Reported: OCL 2.0 — Thu, 2 Nov 2006 05:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

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

The following collection operations would be useful for the HL7 GELLO project:

  • Key: OCL21-349
  • Legacy Issue Number: 13077
  • Status: closed  
  • Source: InferMed Ltd ( Craig Lucas)
  • Summary:

    The HL7 GELLO project would find it useful to have additional collection operators in OCL. A method to define these in the underlying model would be good. Alternatively, we request the addition of the following operations:

    max, min: To determine the maximum or minimum value in a collection

    firstN: Returns a sequence with the first n elements of this sequence

    lastN: Returns a sequence with the last n elements of this sequence

    reverse: Returns a sequence in reverse order

    join(namesOfCollections; namesOfProperties; booleanExpression; orderByExpression)

    Where:

    • namesOfCollections is a list of strings separated by commas, where each

    string represents the name of a collection from where data is retrieved.

    • namesOfProperties is a list of strings separated by commas, where each

    string is the full description of the properties from the objects in the

    collections we want to get in the result.

    • booleanExpression is a valid boolean expression containing the

    conditions the elements from the collections defined in listOfCollections

    must satisfy in order to be included in the result

    • booleanExpression is a valid boolean expression containing the

    conditions the elements from the collections defined in listOfCollections

    must satisfy in order to be included in the result

    average: Calculate the average value in a collection

    stdev: Calculate the standard deviation of a collection

    variance: Calculate the variance of a collection

    median: Calculate the median of a collection

    mode: Calculate the mode of a collection

  • Reported: OCL 2.0 — Mon, 10 Nov 2008 05:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

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

The concrete syntax given is extremely difficult to implement

  • Key: OCL21-348
  • Legacy Issue Number: 13076
  • Status: closed  
  • Source: InferMed Ltd ( Craig Lucas)
  • Summary:

    The concrete syntax given is extremely difficult to implement, as documented in several places, including University of Dresden http://dresden-ocl.sourceforge.net/papers/ParserDesign.pdf Many languages have a syntax specified in a machine-readable form, (e.g. lex/yacc format). A standard, working, syntax for OCL would be very useful.

  • Reported: OCL 2.0 — Mon, 10 Nov 2008 05:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    Disposition: See issue 10439 for disposition

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

have tuple fields and let variables to have the declaration of their types explicity?

  • Key: OCL21-352
  • Legacy Issue Number: 13537
  • Status: closed  
  • Source: Anonymous
  • Summary:

    have tuple fields and let variables to have the declaration of their types explicity?

  • Reported: OCL 2.0 — Fri, 20 Feb 2009 05:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

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

type of the iterator variable is expected or not?

  • Key: OCL21-351
  • Legacy Issue Number: 13536
  • Status: closed  
  • Source: Imdea Software ( Miguel Angel Garcia de Dios)
  • Summary:

    I wrote an issue similar than this one but not equal so, the body could seem equal but it is not the case. I have a few doubts about the iterator variables. Reading the specification I am not sure about, for each iterator, if the type of the iterator variable is expected or not. For example: collection->select( v : Type | boolean-expression-with-v ) collection->select( v | boolean-expression-with-v ) Looking at sections 7.6 and 11.9 my conclusion is the following: -select --> It is NOT obligatory to write the type of the iterator variable. It appears in section 7.6. -reject --> It is NOT obligatory to write the type of the iterator variable. It appears in section 7.6. -collect --> It is NOT obligatory to write the type of the iterator variable. It appears in section 7.6. -forAll --> It is NOT obligatory to write the type of the iterator variable. It appears in section 7.6. -exists --> It is NOT obligatory to write the type of the iterator variable. It appears in section 7.6. -iterate --> In section 7.6 it seems that in both, for the iterator variable and for the accumulator variable, it is obligatory to write the type. -collectNested --> It is NOT obligatory to write the type of the iterator variable. It is a similar case than the collect. -one --> It is NOT obligatory to write the type of the iterator variable. -any --> It is NOT obligatory to write the type of the iterator variable. -isUnique -->It is NOT obligatory to write the type of the iterator variable. Is my conclusion correct in everything? or in which parts am I confused? I think that both, iterator variable and accumulator variable of the iterate iterator should have their types optional. In other words, to write the type of the iterator variable or the type of the accumulator variable should not be obligatory.

  • Reported: OCL 2.0 — Fri, 20 Feb 2009 05:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    It is clear from the various examples in Section 7 that the type declaration of the iterator is optional in collection operations. By default VariableDeclarationCS is defined so that the type of the variable declared is optional.

    Disposition: Close, no change

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

doubts about the iterator variables

  • Key: OCL21-350
  • Legacy Issue Number: 13535
  • Status: closed  
  • Source: Imdea Software ( Miguel Angel Garcia de Dios)
  • Summary:

    I have a few doubts about the iterator variables. Reading the specification I am not sure about, for each iterator, how many iterator variables can have. Looking at sections 7.6 and 11.9 my conclusion in the following: -select --> It has zero or one iterator variables. (0..1) -reject --> It has zero or one iterator variables.(0..1) -collect --> It has zero or one iterator variables.(0..1) -forAll --> There is no restriction about the number of iterator variables. (0..) -exists --> Unlike forAll, in section 7.6 there is no text saying anything about the number of variables. But in section 11.9 it seems that it is the same case that forAll. (0..) -iterate --> It has one iterator variable. -collectNested --> It has zero or one iterator variables.(0..1) -one --> It has zero or one iterator variables.(0..1) -any --> It has zero or one iterator variables.(0..1) -isUnique -->It has zero or one iterator variables.(0..1) Is my conclusion correct in everything? or in wich parts am I confused? How can the most of the iterators be defined by the iterate iterator if iterate iterator can have only one variable iterator? I think the iterate iterator should not have restrictions about the number of iterator variables (0..*).

  • Reported: OCL 2.0 — Fri, 20 Feb 2009 05:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

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

CollectionType and CollectionKind

  • Key: OCL21-295
  • Legacy Issue Number: 12419
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    The abstractness of CollectionType and corresponding existence of the Collection CollectionKind is inconsistent:

    9.3 collectionTypeCS synthesized attributes, page 79, contains:

    kind = CollectionKind::Collection implies collectionTypeCS.ast.oclIsKindOf(CollectionType)

    using CollectionKind::Collection.

    8.3.5 CollectionKind, page 48, Collection is not one of the enumeration values.

    11.6.1, page 144, specifies that Collection is an instance of CollectionType
    requiring Collection to not be abstract.

    8.2 CollectionType, page 34, CollectionType is identified as an abstract class.

    An expression like the following is valid:

    context Package
    def getClasses() : Set(Class) =
    let c : Collection(Type) = self.ownedType in
    c->select(oclIsKindOf(Class))->asSet()

    and demonstrates the need for a concrete CollectionType.

    Recommendation:

    Collection should not be abstract; change Fig 8.1, 8.2 CollectionType text.
    CollectionKind requires a Collection value; change Fig 8.7, 8.3.5 CollectionKind.

  • Reported: OCL 2.0 — Sat, 19 Apr 2008 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

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

no explanations about how to manipulate optional and multivalued attributes

  • Key: OCL21-307
  • Legacy Issue Number: 12449
  • Status: closed  
  • Source: Anonymous
  • Summary:

    There are no explanations about how to manipulate optional and multivalued attributes. On the other hand optional and multivalued associations are discussed in detail. For example, while I can use context Person inv: self.job->notEmpty() implies ... to test "whether there is an object or not when navigating the association", I do not know how do a similar test for optional attributes. Is it context Person inv: self.maidenName <> `' implies ... or context Person inv: self.maidenName -> notEmpty() implies ... ?

  • Reported: OCL 2.0 — Wed, 14 May 2008 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

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

section 7.4.6 (p. 12)

  • Key: OCL21-306
  • Legacy Issue Number: 12448
  • Status: closed  
  • Source: Anonymous
  • Summary:

    In section 7.4.6 (p. 12) it is said "An object can only be re-typed to one of its subtypes; ... If the actual type of the object is not a subtype of the type to which it is re-typed, the expression is undefined" While in section 7.5.8 (p. 19) it is said Whenever we have a class B as a subtype of class A, and a property p1 of both A and B, we can write: context B inv: self.oclAsType(A).p1 – accesses the p1 property defined in A self.p1 – accesses the p1 property defined in B and thus an example is shown where an object is retyped to its supertype. Both sections 7.4.6 and 7.5.8 should be joined into one. See slide 32 in my handouts to see a possible abstract of the joined section.

  • Reported: OCL 2.0 — Wed, 14 May 2008 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    The problem is fixed by resolution of issue 7341. Casting and accessing properties from a supertype are two different things.

    Disposition: See Issue 7341 for disposition

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

Section: A/1.1.1 Types

  • Key: OCL21-297
  • Legacy Issue Number: 12439
  • Status: closed  
  • Source: Net.Orange (i.e. Net Dot Orange) ( Garr Lystad)
  • Summary:

    The following grammatically incorrect sentence is present in the document: All type domains include an undefined value that allows to operate with unknown or “null” values. This could be corrected in various ways, a couple of which would be: All type domains include an undefined value that allows one to operate with unknown or “null” values. or All type domains include an undefined value that allows operations with unknown or “null” values.

  • Reported: OCL 2.0 — Tue, 13 May 2008 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

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

last line on page 28

  • Key: OCL21-296
  • Legacy Issue Number: 12438
  • Status: closed  
  • Source: Net.Orange (i.e. Net Dot Orange) ( Garr Lystad)
  • Summary:

    The last line on page 28 is an example in Java-like code that is supposed to show the accumulation of values into a Bag. The line currently is acc = <expression-with-elem-and-acc> Since such an assignment would not add to the Bag, but more likely produce a compile error in Java, I would think use of the common method name "add" would be more appropriate: acc.add(<expression-with-elem-and-acc>);

  • Reported: OCL 2.0 — Tue, 13 May 2008 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

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

Section: A/1.2.4 System State

  • Key: OCL21-304
  • Legacy Issue Number: 12446
  • Status: closed  
  • Source: Net.Orange (i.e. Net Dot Orange) ( Garr Lystad)
  • Summary:

    Definition 1.12 (System State) ends with "(the function pi(l) projects the ith component of a tuple or list l, whereas the function pi(l) projects all but the ith component):" Obviously the same notation can't mean opposite things, but what was intended here I don't yet know. Perhaps I will as I read on, but I thought I'd report this typo now so I don't forget.

  • Reported: OCL 2.0 — Tue, 13 May 2008 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

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

Section: A/1.2.1 Objects

  • Key: OCL21-303
  • Legacy Issue Number: 12445
  • Status: closed  
  • Source: Net.Orange (i.e. Net Dot Orange) ( Garr Lystad)
  • Summary:

    In Definition A.10 Object Identifiers, part ii, you have the domain of a class c defined as: ICLASS(c') = U

    {oid(c) | c' ? CLASS ^ c' "gr<" c}

    . where I've used "gr<" for the generalization relation. I see 4 things that ought to be changed: 1. The initial c' should obviously be a c. 2. The oid(c) should be oid(c') 3. We have still another symbol for "and" 4. There's an extraneous newline before the final c.

  • Reported: OCL 2.0 — Tue, 13 May 2008 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

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

Section: A/1.1.6 Generalization - editorial issues

  • Key: OCL21-302
  • Legacy Issue Number: 12444
  • Status: closed  
  • Source: Net.Orange (i.e. Net Dot Orange) ( Garr Lystad)
  • Summary:

    In WF-1 there is an "is an element of" sign missing just before the "ATT" in the first line. In WF-2, at a minimum, the first small omega should have a t-sub-1 a bit after it so that the sameness of arguments from t-sub-1 through t-sub-n is clear for both small omegas. Also the second colon is on the wrong side of the small omega. On the other hand, I'm not sure why you don't write it in the same form as WF-1, since it's a similar statement. I hope you can interpret my attempts to get by without sub and superscripts. Since the reader has already waded through WF-1, wouldn't it be more useful like this? ? (? : tc x t1 x …x tn ? t, ?' : tc' x t1 x …x tn ? t' ? OP*c) : (? = ?' => tc = tc' ? t = t')

  • Reported: OCL 2.0 — Tue, 13 May 2008 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

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

Section: A/1.1.5 Associations

  • Key: OCL21-300
  • Legacy Issue Number: 12442
  • Status: closed  
  • Source: Net.Orange (i.e. Net Dot Orange) ( Garr Lystad)
  • Summary:

    In the definition of "navends" the symbol for "and", which was a nice looking capital lambda in previous definitions, is here a more traditional, at least in my mind, "and" sign. Consistency would be nice

  • Reported: OCL 2.0 — Tue, 13 May 2008 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

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

Section: A/1.1.5 Associations -- missing word

  • Key: OCL21-299
  • Legacy Issue Number: 12441
  • Status: closed  
  • Source: Net.Orange (i.e. Net Dot Orange) ( Garr Lystad)
  • Summary:

    Between the definitions of "participating" and "navends" is a sentence that, "The following function navends give ...." The s is missing on "gives". It should instead read, "The following function navends gives ...."

  • Reported: OCL 2.0 — Tue, 13 May 2008 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

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

Section: A/1.1.6 Generalization

  • Key: OCL21-301
  • Legacy Issue Number: 12443
  • Status: closed  
  • Source: Net.Orange (i.e. Net Dot Orange) ( Garr Lystad)
  • Summary:

    At the top of page 182 there are 3 definitions, all of which have the index domain, i.e. C' an element of parents(c), in the wrong place horizontally. In the first two it appears to be associated with the small union symbol, rather than with the large one as it should be. In the third it seems not to be associated with anything in particular. Additionally, in the first line on the page there is an extraneous underscore in the name of the object of the first definition.

  • Reported: OCL 2.0 — Tue, 13 May 2008 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

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

Section: A/1.1.5 Associations

  • Key: OCL21-298
  • Legacy Issue Number: 12440
  • Status: closed  
  • Source: Net.Orange (i.e. Net Dot Orange) ( Garr Lystad)
  • Summary:

    The next to last line of Definition A.4 begins, "that associates (sa) = <oc, c>." I think this should read instead, "that associates (sa) = <c, c>." If I am mistaken, then a note to remind the reader what "oc" means would be helpful, as would a note describing why the classes are not the same.

  • Reported: OCL 2.0 — Tue, 13 May 2008 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

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

Section: A/2.2 Common Operations on All Types

  • Key: OCL21-305
  • Legacy Issue Number: 12447
  • Status: closed  
  • Source: Net.Orange (i.e. Net Dot Orange) ( Garr Lystad)
  • Summary:

    This is another omission of the word "one", making the sentence grammatically incorrect. It is also useful to have an operation that allows to check whether an arbitrary value is well defined or undefined. should be "... allows one to ...." or "... allows the checking of whether ...."

  • Reported: OCL 2.0 — Tue, 13 May 2008 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

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

Section: A.2.5.8 Sequence Operations

  • Key: OCL21-333
  • Legacy Issue Number: 12490
  • Status: closed  
  • Source: Net.Orange (i.e. Net Dot Orange) ( Garr Lystad)
  • Summary:

    In the flattening expressions there are the expressions "C1 fg" and "Bag fg". These seem to stand for the creation of a new, empty collection and bag respectively. If these expressions are what was intended it would be nice to have a note explaining what they mean. I wasn't able to find any explanations or previous use of "fg".

  • Reported: OCL 2.0 — Thu, 15 May 2008 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    The "fg" (in both occurrences) must be replaced by "{}" (a pair of curly braces).

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

Section: A.3.1.2 Semantics of Expressions, Definition A.30 part ii

  • Key: OCL21-332
  • Legacy Issue Number: 12489
  • Status: closed  
  • Source: Net.Orange (i.e. Net Dot Orange) ( Garr Lystad)
  • Summary:

    Definition A.30, part ii says "I[[let v = e1 in e2]](r) = I[[e2]](s, ß

    {v / I[[e1]](r)}

    )." Maybe the problem is my ignorance of the meaning of the / in that expression as well as the meaning of the notation "ß

    {...}

    ". I would have expected instead something like, "... = I[[e2]](s, ß U

    {v = I[[e1]](r)}

    )."

  • Reported: OCL 2.0 — Thu, 15 May 2008 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    Disposition: See issue 12488 for disposition

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

Section 8.2.1 Type Conformance on page 37

  • Key: OCL21-327
  • Legacy Issue Number: 12484
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Section 8.2.1 Type Conformance on page 37 [1] Invalid conforms to all other types. context InvalidType inv: Classifier.allInstances()>forAll (c | self.conformsTo (c)) on page 38 [1] Void conforms to all other types. context VoidType inv: Classifier.allinstances()>forAll(c | self.conformsTo(c)) on page 37 [6] The Conforms operation on Types is anti-symmetric context Classifier inv: Classifier.allInstances()> forAll(12,t2 | t1.conformsTo(t2) and t2.conformsTo(t1) implies t1 = t2) The first invariant yields Classifier.allInstances()>forAll (c | OclInvalid.conformsTo (c)) and thus OclInvalid.conformsTo (OclVoid) The second invariant yields Classifier.allInstances()->forAll (c | OclVoid.conformsTo (c)) and thus OclVoid.conformsTo (OclInvalid) Now the third invariant implies: OclInvalid = OclVoid

  • Reported: OCL 2.0 — Thu, 15 May 2008 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

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

Section: A.3.1.1 Syntax of Expressions

  • Key: OCL21-330
  • Legacy Issue Number: 12487
  • Status: closed  
  • Source: Net.Orange (i.e. Net Dot Orange) ( Garr Lystad)
  • Summary:

    Definition A.29 (Syntax of Expressions)part iii, (b) ends, "...and e2 to en the arguments." The n in "en" should be a subscript but is not.

  • Reported: OCL 2.0 — Thu, 15 May 2008 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

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

Section: A.2.7 Type Hierarchy

  • Key: OCL21-329
  • Legacy Issue Number: 12486
  • Status: closed  
  • Source: Net.Orange (i.e. Net Dot Orange) ( Garr Lystad)
  • Summary:

    The first two sentences of Definition A.27 (Type Hierarchy) seem to have errors in them. The relation "less than or equal" seems to be represented by an underscore in the first sentence. In the second sentence 2 is used where the "is an element of" symbol was intended, 0 is used where a prime mark is intended, and c simply follows t and t0 (t prime) rather than being a subscript as intended.

  • Reported: OCL 2.0 — Thu, 15 May 2008 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    Replace the text of Section A.2.7 Type Hierarchy by the following text:

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

Section: A.2.6.1 Definition A.26 (Special Types)

  • Key: OCL21-326
  • Legacy Issue Number: 12479
  • Status: closed  
  • Source: Net.Orange (i.e. Net Dot Orange) ( Garr Lystad)
  • Summary:

    At the very end if this section it says "I(undefined) = ?." Shouldn't that be "I(undefined) = {?}."? Definition A.14 says the semantics maps each type to a set.

  • Reported: OCL 2.0 — Wed, 14 May 2008 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

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

Section: A.2.6 Special Types

  • Key: OCL21-325
  • Legacy Issue Number: 12478
  • Status: closed  
  • Source: Net.Orange (i.e. Net Dot Orange) ( Garr Lystad)
  • Summary:

    The third bullet ends, "... as ? is an instance of every type." I don't know if the ? stands for OclAny, which isn't a member of the collection classes and so unlikely, or if ? is meant rather than ?. So I think this is an error.

  • Reported: OCL 2.0 — Wed, 14 May 2008 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

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

Section: A.3.1.1 Syntax of Expressions

  • Key: OCL21-322
  • Legacy Issue Number: 12475
  • Status: closed  
  • Source: Net.Orange (i.e. Net Dot Orange) ( Garr Lystad)
  • Summary:

    Definition A.29 (Syntax of Expressions), part v, appears to have several problems: 1. The symbol used for generalization is not what has always been used previously, see the two previous symbols in Definition A.10 part ii and in section A.1.2.2 just after it. 2. the first expression after the word "then", namely "(e asType t’) ? Exprt’" lacks a comma after it to separate it from the following expression. 3. I'm puzzled by the restrictions that t and t' must be related one way on the other. The restriction isn't strong enough to keep (e asType t’) from being undefined and seems unneeded for isTypeOf and isKindOf. A note here about this might help the reader. It would sure help me.

  • Reported: OCL 2.0 — Wed, 14 May 2008 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    Disposition: See issue 12474 for disposition

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

Syntax of Expressions (second sentence after Definition A..29)

  • Key: OCL21-324
  • Legacy Issue Number: 12477
  • Status: closed  
  • Source: Net.Orange (i.e. Net Dot Orange) ( Garr Lystad)
  • Summary:

    The second sentence after Definition A.29 is "For all t’ < t: if e ? Exprt’ then e ? Exprt’ ." The last prime should be removed.

  • Reported: OCL 2.0 — Wed, 14 May 2008 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

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

Section: A.3.1.1 Syntax of Expressions (Definition A.29)

  • Key: OCL21-323
  • Legacy Issue Number: 12476
  • Status: closed  
  • Source: Net.Orange (i.e. Net Dot Orange) ( Garr Lystad)
  • Summary:

    Definition A.29 (Syntax of Expressions), part vi reads it part, "... v1 ? Vart1, v2 ? Vart2, and ...." The first comma is a subscript along with the "t1" before it, the second one, that follows the "t2" subscript, isn't. Neither should be.

  • Reported: OCL 2.0 — Wed, 14 May 2008 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

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

Section: A.3.1.2 Semantics of Expressions

  • Key: OCL21-331
  • Legacy Issue Number: 12488
  • Status: closed  
  • Source: Net.Orange (i.e. Net Dot Orange) ( Garr Lystad)
  • Summary:

    Some problems with Definition A.30: 1. In the second sentence of Definition A.30 (Semantics of Expressions) it says, "I[[ e ]] : Env ? I(t)" but it seems instead that "I[[ e ]] : Exprt ? (Env ? I(t)). 2. It appears that r, which is not defined anywhere, is really supposed to be p. p, which is defined, only appears in part iv and it appears to be r there. 3. Also, it's confusing to use w in parts iii and iv since small omega (or script w maybe) is used previously. Further clarity would be added by putting empty parenthenes after omega in part iii to emphasize the fact that there are no arguments

  • Reported: OCL 2.0 — Thu, 15 May 2008 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

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

Section 8.2 page 35 InvalidType

  • Key: OCL21-328
  • Legacy Issue Number: 12485
  • Status: closed  
  • Source: Anonymous
  • Summary:

    InvalidType represents a type that conforms to all types. The only instance of InvalidType is Invalid, which is further defined in the standard library. Furthermore Invalid has exactly one runtime instance called OclInvalid. should be replaced by InvalidType InvalidType represents a type that conforms to all types. The only instance of InvalidType is OclInvalid, which is further defined in the standard library. Furthermore OclInvalid has exactly one runtime instance called invalid. This would follow the naming conventions and be in line with the notation for VoidType, OclVoid, null.

  • Reported: OCL 2.0 — Thu, 15 May 2008 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    Disposition: See issue 12378 for disposition

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

Section: A.3.1.1 Syntax of Expressions

  • Key: OCL21-321
  • Legacy Issue Number: 12474
  • Status: closed  
  • Source: Net.Orange (i.e. Net Dot Orange) ( Garr Lystad)
  • Summary:

    Definition A.29 (Syntax of Expressions), part iii, b ends with, "and e2 to en the arguments." Here the 2 is a subscript as it should be but the "n" in "en" should also be a subscript and isn't.

  • Reported: OCL 2.0 — Wed, 14 May 2008 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

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

Section: A/2.3 Enumeration Types -- editorial

  • Key: OCL21-311
  • Legacy Issue Number: 12458
  • Status: closed  
  • Source: Net.Orange (i.e. Net Dot Orange) ( Garr Lystad)
  • Summary:

    The last sentence of the page is missing the word "one" or, alternately, proper forms of the verbs "to follow" and "to retrieve". A correct form of this sentence would be, "Navigation operations: An object may be connected to other objects via association links. A navigation expression allows one to follow these links and to retrieve connected objects."

  • Reported: OCL 2.0 — Wed, 14 May 2008 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

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

The constraint [1] on the TupleLiteralPart metaclass is overconstrained

  • Key: OCL21-310
  • Legacy Issue Number: 12454
  • Status: closed  
  • Source: Zeligsoft, Inc. ( Christian Damus)
  • Summary:

    The constraint [1] on the TupleLiteralPart metaclass is overconstrained. It requires that the type of the value of a tuple literal part be identical to the corresponding attribute of the tuple type. However, the value type should only be required to conform to the attribute type because tuple literals may optionally specify the part types (in the same fashion as variable declarations). Thus, a more appropriate formulation of this constraint would be: context TupleLiteralPart inv: attribute.type.conformsTo(value.type )

  • Reported: OCL 2.0 — Wed, 14 May 2008 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

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

Section: A.2.5.2 Definition A.24 (Type Expressions)

  • Key: OCL21-313
  • Legacy Issue Number: 12460
  • Status: closed  
  • Source: Net.Orange (i.e. Net Dot Orange) ( Garr Lystad)
  • Summary:

    This may not have been a problem with earlier versions of Adobe Acrobat/Reader but in looking at this section I see two typographical representations of "T-hat". The first two occurances are the letter T followed by a small circumflex substript. Subsequent occurances are a large circumflex followed by the letter T. It would be nice if this were fixed to be consistent, and even nicer if the circumflex could be placed over the T, as I imagine was intended.

  • Reported: OCL 2.0 — Wed, 14 May 2008 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

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

Section: Definition A.23 (Semantics of Navigation Operations)

  • Key: OCL21-312
  • Legacy Issue Number: 12459
  • Status: closed  
  • Source: Net.Orange (i.e. Net Dot Orange) ( Garr Lystad)
  • Summary:

    Maybe I misunderstand, but it seems to me that L(as)(ci), as defined, has some problems: 1. "(c1, . . . , c i, . . . , c j , . . . , c n )" is undefined in that one doesn't know what it is, and 2. c is undefined in "sCLASS(c)". It seems to me that what you want is "L(as)(ci) =

    {cj | i ? j ? (c1, . . . , ci, . . . , cj , . . . , cn ) ? I-sub-ASSOC(as)}

    " - where the characters following the c's are subscripts and each such combination should be underlined to show that it is an object, - and where I-sub-ASSOC(as) is an italic I with a subscripted "ASSOC(as)".

  • Reported: OCL 2.0 — Wed, 14 May 2008 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

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

There are two instances of missing and misplaced parentheses

  • Key: OCL21-317
  • Legacy Issue Number: 12470
  • Status: closed  
  • Source: Net.Orange (i.e. Net Dot Orange) ( Garr Lystad)
  • Summary:

    There are two instances of missing and misplaced parentheses. One is near the bottom of page 195 in the definition of I(count). The line begins, "I(count : Bag)(t) x t ? Integer)". That last closing paren does not match anything. I believe the line should instead begin "(I(count) : Bag(t) x t ? Integer) The other is at the top of page 196. It is currently "I(count : Collection)(t) x t ? Integer)(c,v)" and, I believe, should be "(I(count) : Collection(t) x t ? Integer)(c,v)"

  • Reported: OCL 2.0 — Wed, 14 May 2008 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    Disposition: See Issue 12463 for disposition

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

A.2.5.5 Collection Operations

  • Key: OCL21-316
  • Legacy Issue Number: 12469
  • Status: closed  
  • Source: Net.Orange (i.e. Net Dot Orange) ( Garr Lystad)
  • Summary:

    In the paragraph under table A.3, toward the end, it says, "... count : Set(t) _ t ! Integer ...." These are the wrong symbols, of course. The underscore should be a cross and the ! should be an arrow. Also, just below this is the definition of I(count). This contains a 2 that should be a 0.

  • Reported: OCL 2.0 — Wed, 14 May 2008 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    Disposition: See Issue 12463 for disposition

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

Section: A.2.5.8 Sequence Operations

  • Key: OCL21-320
  • Legacy Issue Number: 12473
  • Status: closed  
  • Source: Net.Orange (i.e. Net Dot Orange) ( Garr Lystad)
  • Summary:

    There is one error in Table A.6 in the semantics column for the operation "first". The index should be 1, not i.

  • Reported: OCL 2.0 — Wed, 14 May 2008 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

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

Section: A.2.5.6 Set Operations Table A.4

  • Key: OCL21-319
  • Legacy Issue Number: 12472
  • Status: closed  
  • Source: Net.Orange (i.e. Net Dot Orange) ( Garr Lystad)
  • Summary:

    Table A.4 has several rows in the Semantics column where a "union" symbol is used where an "intersection" symbol should have been used. These are rows 3, 4, 5, and 6. Table A.5 of section A.2.5.7 has the same problem in rows 3 and 4.

  • Reported: OCL 2.0 — Wed, 14 May 2008 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

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

OrderedSet collection

  • Key: OCL21-309
  • Legacy Issue Number: 12451
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The OrderedSet collection is a later adjunction with respect to previous versions of OCL. However, it has not been systematically introduced in all relevant places. As one example among many, conformance rules in Table 7.3 (p.12) do not include OrderedSet. Also, the semantics defined in Appendix A should be extended to include OrderedSet. By the way, there is no place where the difference between OrderedSet and Sequence is discussed. From my understanding, they are much like the same concept. If it is not the case, the differences must be explicitly stated.

  • Reported: OCL 2.0 — Wed, 14 May 2008 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

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

Section: A.2.5.6 Set Operations

  • Key: OCL21-318
  • Legacy Issue Number: 12471
  • Status: closed  
  • Source: Net.Orange (i.e. Net Dot Orange) ( Garr Lystad)
  • Summary:

    The second sentence of this section ends, "... B is a value of type t.". It should say "... B is a value of type Bag(t).

  • Reported: OCL 2.0 — Wed, 14 May 2008 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

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

Section: A.2.5.5 Collection Operations

  • Key: OCL21-314
  • Legacy Issue Number: 12461
  • Status: closed  
  • Source: Net.Orange (i.e. Net Dot Orange) ( Garr Lystad)
  • Summary:

    The 5th word of this section is "of" but was probably meant to be "on". Also, in Table A.3 in this section the entry in the second row, third column is pretty much unreadable because there are so many symbols written on top of each other. I checked this with Internet Explorer as well as Firefox, in case they affected Adobe Acrobat, but the entry looked equally bad in both.

  • Reported: OCL 2.0 — Wed, 14 May 2008 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

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

Section: A/2.5.5 Collection Operations - just before table A.3

  • Key: OCL21-315
  • Legacy Issue Number: 12464
  • Status: closed  
  • Source: Net.Orange (i.e. Net Dot Orange) ( Garr Lystad)
  • Summary:

    Just before Table A.3, is a sentence, "For this purpose, C, C, C2 ...." The second "C" should have a subscript "1" and the "C2" should have the 2 as a subscript.

  • Reported: OCL 2.0 — Wed, 14 May 2008 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

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

The Tuple constructor is problematic

  • Key: OCL21-308
  • Legacy Issue Number: 12450
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The Tuple constructor is problematic. It is not a first-class citizen in the specifications. It appears in many parts but it is not formally introduced.

  • Reported: OCL 2.0 — Wed, 14 May 2008 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

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

Section: 7.3.4

  • Key: OCL21-270
  • Legacy Issue Number: 9796
  • Status: closed  
  • Source: none ( Jorge Bejar)
  • Summary:

    We consider a Sequence of instances of a class called 'Example'. This class has an integer attribute called 'ex'. If we have a method specification written as follow: pre: datalist->isTypeOf(Sequence(Example)) post: Sequence

    {1..datalist->size()}

    >forAll(n | datalist>at.ex = datalist@pre->at.ex) I not sure if is correct writes the same specification with the next sentences: pre: datalist->isTypeOf(Sequence(Example)) post: datalist->forAll(n | n.ex = n@pre.ex) The generic questions is: What does the '@pre' operator mean when it is applied to iterators variables (as 'n' in the example)? Is correct the @pre use in this cases? I hope you understand my dude and sorry any gramatical error because my written english is very poor.

  • Reported: OCL 2.0 — Sat, 27 May 2006 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

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

Wrong subtyping of PropertyCallExp and NavigationCallExp

  • Key: OCL21-269
  • Legacy Issue Number: 9405
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    In section 8.3.2 of ptc/05-06-06 PropertyCall is shown as a subclass of NavigationCallExp -this seems the wrong way round: NavigationCallExp seems to be a specialization for when the Property is an AssociationEnd. To illustrate this, the description of NavigationCallExp starts with the following, which would not apply if the Property in question were an ownedAttribute of a class:
    "A NavigationCallExp is a reference to an AssociationEnd or an AssociationClass defined in a UML model."

  • Reported: OCL 2.0 — Tue, 28 Feb 2006 05:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

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

inability to uniquely reference association ends

  • Key: OCL21-268
  • Legacy Issue Number: 9404
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Section 7.5.3 of ptc/05-06-06 starts with the following: "Starting from a specific object, we can navigate an association on the class diagram to refer to other objects and their properties. To do so, we navigate the association by using the opposite association-end:"

    However, unlike in UML 1.x, in UML2 this may well be ambiguous (since names of ends owned by Associations only have to be unique within the Association and not within the context of the Class).
    OCL should therefore explicitly allow qualification using the name of the Association itself as well as the end name (it is not clear whether this is currently allowed as part of the syntax for 'associationendname' so there should be an example to show this. This would make it consistent with the metamodel which allows reference to specific Properties.

    For example we could have associations A1 and A2 both linking classes C1 and C2 and each with ends c1 and c2 owned by the respective associations.
    OCL does not then address the fact that aC1.c2 is ambiguous - unlike the case with unnamed ends it does not even say that it may be ambiguous and is hence disallowed.
    However rather than disallowing the navigation OCL should have a syntax to allow qualification by the association name
    For example aC1.A1::c2

    The same could be used for missing association end names: If A1 had unnamed ends then one could use aC1.A1::C2

  • Reported: OCL 2.0 — Tue, 28 Feb 2006 05:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

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

Introduction and oclType()

  • Key: OCL21-267
  • Legacy Issue Number: 9171
  • Status: closed  
  • Source: SAP SE ( Murray Spork)
  • Summary:

    I only recently joined the OCL rtf at the request of David Frankel (who
    is now with SAP) - I have not seen any activity on this mailing list as
    yet so I hope this is an appropriate forum to raise this question.

    First let me introduce myself - I am lead for a proof-of-concept project
    investigating the use of OCL to express integrity constraints on models.
    Hopefully I will get a chance next year to attend a f2f meeting so that
    I can meet you all.

    On to my specific question: we have noticed that some time between OCL
    1.1 and UML 1.4 "oclType", as a predefined feature, was removed. (I have
    been unable to find any versions of OCL between 1.1 and UML 1.4).

    I thought it would be best if we found out whether this removal was
    intentional before officially raising it as an issue. The reason is that
    we find a) this is a useful reflective feature to have and 2) it is
    still used in some current OMG specifications (note that it is used
    inconsistently).
    e.g.:

    • UML2 Infrastructure - (ptc/03-09-15) pg.89:
      Classifier::maySpecializeType(c : Classifier) : Boolean;
      maySpecializeType = self.oclIsKindOf(c.oclType)
    • Meta Object Facility (MOF) 2.0 Core Specification (ptc/03-10-04) -
      pg.68
      ExtentImpl::addObject(ObjectInstance o, String suppliedId
      [0..1]): String
      pre: not(self.entry.identifier includes suppliedId)
      post: oclIsNew(e) and oclType(e) = IdentifierEntry and
      e.object = o and
      self.entry includes e
      self.entry->select(ex | ex.identifier = e.identifier)->size() =
      1 – the new id is unique and
      (suppliedId <> null implies e.identifier = suppliedId)
  • Reported: OCL 2.0 — Sun, 13 Nov 2005 05:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

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

Circular imports

  • Key: OCL21-266
  • Legacy Issue Number: 8982
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Are two packages allowed to mutually import each other? I can't find
    anything preventing this in the spec, but was wondering if it causes
    some kind of "infinite" import loop.

  • Reported: OCL 2.0 — Sat, 27 Aug 2005 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

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

Section: 7.5.9

  • Key: OCL21-272
  • Legacy Issue Number: 9914
  • Status: closed  
  • Source: LIANTIS GmbH ( Constantin Szallies)
  • Summary:

    The spec states: ---- The operation oclInState(s) results in true if the object is in the state s. Values for s are the names of the states in the statemachine(s) attached to the Classifier of object. ---- How does this relate to the uml metamodell? A BehavioredClassifier may have several ownedBehaviors but only one of those behaviors may be the behavior of the classifier himself. The other behaviors may be specifications for behavioral features of the classifier. ---- Clarification: Possible states for the operation oclInState(s) are all states of the statemachine that defines the classifier's behavior (property 'classifierBehavior' of the 'BehavioredClassifier' metaclass).

  • Reported: OCL 2.0 — Tue, 11 Jul 2006 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

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

Section: 8.3.5

  • Key: OCL21-271
  • Legacy Issue Number: 9913
  • Status: closed  
  • Source: LIANTIS GmbH ( Constantin Szallies)
  • Summary:

    The abstract syntax defines the classes NullLiteralExp and InvalidLiteralExp but the concrete syntax does not define these literal values. — I would like to return 'null' in certain OCL expressions for example: context Person::foo() : Person body: if age > 10 then self else null endif Currenty the only correct way to do this is not very straight forward: context Person::foo() : Person body: if age > 10 then self else OclVoid.allInstances()->any() endif The same is true for the singelton instance of OclUndefined.

  • Reported: OCL 2.0 — Tue, 11 Jul 2006 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

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

sub evaluations (02)

  • Key: OCL21-248
  • Legacy Issue Number: 7546
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    38. – [1] All sub evaluations have a different environment. The first sub evaluation
    – will start with an environment in which all iterator variables are bound to
    – the first element of the source, plus the result variable which is bound to
    – the init expression of the variable declaration in which it is defined.
    context IterateExpEval
    inv: let bindings: Sequence( NameValueBinding ) =
    iterators->collect( i |
    NameValueBinding( i.varName, source->asSequence()->first() ))
    in
    bodyEvals->at(1).environment = self.environment->addAll( bindings )
    ->add( NameValueBinding( result.name, result.initExp.resultValue ))
    ==> ’varName’ should be ’value’

  • Reported: OCL 2.0b2 — Thu, 10 Jun 2004 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    yes

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

sub evaluations

  • Key: OCL21-247
  • Legacy Issue Number: 7545
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    37. – [1] All sub evaluations have a different environment. The first sub evaluation
    – will start with an environment in which all iterator variables are bound to
    – the first element of the source, plus the result variable which is bound to
    – the init expression of the variable declaration in which it is defined.
    context IterateExpEval
    inv: let bindings: Sequence( NameValueBindings ) =
    iterators->collect( i |
    NameValueBinding( i.varName, source->asSequence()->first() ))
    in
    bodyEvals->at(1).environment = self.environment->addAll( bindings )
    ->add( NameValueBinding( result.name, result.initExp.resultValue ))
    ==> ’NameValueBindings’ should be ’NameValueBinding’

  • Reported: OCL 2.0b2 — Thu, 10 Jun 2004 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    yes

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

Section: 7.5.11

  • Key: OCL21-254
  • Legacy Issue Number: 8625
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    The example of Set

    {1,2,5,88}

    is more of an example of an ordered set as is Set

    {'apple','orange','strawberry'}

    . The example of a Sequence

    {1,3,45,2,3}

    does not exhibit any apparent order although a Sequence is defined as an ordered Bag. It might be wise to alter these examples to: Set

    {1,88,5,2}

    , Set ['strawberry','apple','orange'} and Sequence

    {1,2,3,3,45}
  • Reported: OCL 2.0b2 — Thu, 24 Mar 2005 05:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    Yes. But reverse the sequence to clarify that the ordering may not be the obvious one. Also correct the punctuation.

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

Section: 7.5.9

  • Key: OCL21-253
  • Legacy Issue Number: 8624
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Although the definition of oclAsType may be obvious, this is an appropriate sub-section to place a paragraph describing oclAsType. It is the only prrdefined property on All Objects that is not defined in this section.

  • Reported: OCL 2.0b2 — Thu, 24 Mar 2005 05:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    yes

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

value of a collection range

  • Key: OCL21-246
  • Legacy Issue Number: 7544
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    36. – [1] The value of a collection range is the range of integer numbers between
    – the result value of its first expression and its last expression.
    context CollectionRangeEval
    inv: element.isOclType( Sequence(Integer) ) and
    element = getRange( first->oclAsType(Integer), last->oclAsType(Integer) ==> ’isOclType’ should be ’oclIsTypeOf’

  • Reported: OCL 2.0b2 — Thu, 10 Jun 2004 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    ’isOclType’ was fixed in OCL 2.3.
    Disposition: Closed, no change

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

value of a collection range

  • Key: OCL21-245
  • Legacy Issue Number: 7541
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    33. – [1] The value of a collection range is the range of integer numbers between
    – the result value of its first expression and its last expression.
    context CollectionRangeEval
    inv: element.isOclType( Sequence(Integer) ) and
    element = getRange( first->asOclType(Integer), last->asOclType(Integer)
    )
    ==> ’asOclType’ should be ’oclAsType’ (twice)

  • Reported: OCL 2.0b2 — Thu, 10 Jun 2004 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    ’asOclType’ was fixed in OCL 2.3.
    Disposition: Closed, no change

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

Section: 6.5.4.3 Combining Properties

  • Key: OCL21-249
  • Legacy Issue Number: 7722
  • Status: closed  
  • Source: BBDO InterOne ( Jasper Ullrich)
  • Summary:

    "[1] Married people are of age >= 18 context Person inv: self.wife->notEmpty() implies self.wife.age >= 18 and self.husband->notEmpty() implies self.husband.age >= 18" has to be "[1] Married people are of age >= 18 context Person inv: (self.wife->notEmpty() implies self.wife.age >= 18) and (self.husband->notEmpty() implies self.husband.age >= 18)" because of the precedence rules
    same mistake in http://www.omg.org/docs/ptc/03-10-14.pdf, "UML 2.0 OCL Final Adopted specification", chapter 7.5.3, page 18.

  • Reported: OCL 2.0b2 — Thu, 9 Sep 2004 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    yes

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

result value of an attribute call expression

  • Key: OCL21-243
  • Legacy Issue Number: 7537
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    29. – [1] The result value of an attribute call expression is the value bound to the
    – name of the attribute to which it refers.
    context AttributeCallExpEval inv:
    resultValue = if source.resultValue->isOclType(
    OCLDomain::Values::ObjectValue) then
    source.resultValue->asOclType( ObjectValue )
    .getCurrentValueOf(referredAttribute.name)
    else – must be a tuple value
    source.resultValue->asOclType( TupleValue )
    .getValueOf(referredAttribute.name)
    endif
    ==> ’isOclType’ should be ’oclIsTypeOf’
    ==> ’asOclType’ should be ’oclAsType’
    ==> ’name’ should be ’value’ (twice)

  • Reported: OCL 2.0b2 — Thu, 10 Jun 2004 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    ’isOclType’ and ’asOclType’ were fixed in OCL 2.3.
    Yes. value rather than name

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

Section: 7.4.5

  • Key: OCL21-251
  • Legacy Issue Number: 8621
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Typo - In the 2nd para, 3rd sent., the "t" of "type conformance error" is not italicized as is the rest of the phrase. Table 4 does not address the UML 2.0 (pct/04-10-02)use of UnlimitedNaturals as a type. This type probably Conforms to/Is a subtype of Real since UnlimitedNaturals are integers equal to or greater than 0.

  • Reported: OCL 2.0b2 — Wed, 23 Mar 2005 05:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    The italics are fixed in OCL 2.3.
    Subtyping is resolved by Issue 15780.
    Disposition: See issue 15780 for disposition

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

Section: 7.5.3

  • Key: OCL21-252
  • Legacy Issue Number: 8622
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Typo - 2nd line of para under Missing AssociationEnd names, add a "s" to "tarting." Combining Properties example [2] does not show/express any combined properties; it just expresses the size property of the set employee.

  • Reported: OCL 2.0b2 — Wed, 23 Mar 2005 05:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    The paragraph containing the typo was removed in OCL 2.3.
    In the context of Section 7, Operation is a property so there is a combination in the example..
    Disposition: Closed, no change

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

Section: 7.4

  • Key: OCL21-250
  • Legacy Issue Number: 8620
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    I'm not certain if I should report this issue to the OCL group or to the UML Superstructure group, but... the Basic Types listed in OCL do not agree with the Primitive Types listed in the UML Superstucture. OCL lists "Real" as a primitive (basic type), UML Superstructure does not, instead listing UnlimitedNatural as a primitive type. Shouldn't the two agree?

  • Reported: OCL 2.0b2 — Wed, 23 Mar 2005 05:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    UML 2.5 introduces Real. UnlimiteralNatural has been in UML for a long time.
    Disposition: Closed, no change

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

result value of a collection literal expression evaluation

  • Key: OCL21-244
  • Legacy Issue Number: 7539
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    31. – [2] The result value of a collection literal expression evaluation is a
    – collection literal value, or one of its subtypes.
    context CollectionLiteralExpEval inv:
    resultValue.isOclKind( OCLDomain::Values::CollectionValue )
    ==> ’isOclKind’ should be ’oclIsKindOf’

  • Reported: OCL 2.0b2 — Thu, 10 Jun 2004 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    ’isOclType’ and ’asOclType’ were fixed in OCL 2.3.
    Disposition: Closed, no change

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

Issue: Syntax of Operation Call, Iterator, and Iterate Expressions

  • Key: OCL21-204
  • Legacy Issue Number: 6571
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Description: Syntax for the above constructions is extremely ambiguous and it might involve backtracking.
    Rationale: According to OCL specification

    • self.f(x, y)
    • Set {1,2,3}

      ->select(x, y| x+y = 3)

    • Set {1,2,3,4,5,6}

      ->iterate(x; acc:Integer=0 | acc + x)
      describe an operation call, an iterator, and an iterate expression.
      In order to make the distinction between an iterator call and an operation call we need in this case a three token lookahead, starting from x. The problem gets even more complicated if we consider that an argument for an operation call can be an expression.
      In order to solve this problem, which is a potential source of problems for the implementation (error-prone, inefficiency aso), we think that these OCL constructs should contain some extra syntax markers. There are several choices:

    • change the comma marker from iterator calls to something else, maybe a semicolon
    • add a syntax marker to an iterator name
    • do not allow the default types
      The above choices will allow to a deterministic parser to deal with the enumerated problems more efficiently. I do not agree with textual language in which variables are given a default type according to the context in which they are used, especially if these languages are design for industrial use. The same problems were in previous versions of C standard, which allowed implicit type int for variables in constructions like
      x;
      Now, the latest C standard states that variables with default type are not allowed.
  • Reported: OCL 2.0b2 — Tue, 11 Nov 2003 05:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    The exposition of the OCL grammar is poor. In OCL 2.3 the status of iterator names was clarified as not-reserved words which makes the naive parsing approach outlined above more challenging. Instead it is necessary to pursue a syntactic parse and then resolve semantics in a tree walk. The 'problems' have not prevented OCL tool being built.
    Users would not be well-served by a major resyntaxing to introduce new punctuation.
    Disposition: Closed, no change

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

Issue: Abstract syntax tree

  • Key: OCL21-203
  • Legacy Issue Number: 6566
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Description: Some of the elements presented in 3.3.10 (e.g. EnumLiteralExp, children of ModelPropertyCallExp) cannot be constructed without using semantic information (e.g. the type of the expression determines if a name denotes an attribute, an association end, or an operation).
    Rationale: Usually a parser produces an AST. The semantic analyser augments the AST by computing for each node from AST the values of the attached attributes. The semantic analysis also checks if there are static semantics errors and reports them. Using other terms in the AST and hence other non-terminals in 4.5 (e.g. dot-selection-expression, arrow-selection-expression, call-expression etc.) will solve this problem.

  • Reported: OCL 2.0b2 — Tue, 11 Nov 2003 05:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    The exposition of the OCL grammar is poor, but it is possible to resolve context pursuing a left to right analysis of an expression. It is also possible to perform a syntactic parse and then resolve semantics in a tree walk.The 'problems' have not prevented OCL tool being built.
    Users would not be well-served by a major resyntaxing to introduce new operators that required the user to have greater understanding of the metamodels.
    Disposition: Closed, no change

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

The notation for selecting elements should be more intuitive

  • Key: OCL21-208
  • Legacy Issue Number: 6880
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    Suggestion: Use brackets as an alternate option to denote a call to the "select"
    function. Notation: mylist[iterator | condition]
    Example:
    self.ownedElementClass and name="MyClass"
    – #Class is a shorthand for oclIsKindOf(MyClass)
    equivalent to :
    self.ownedElement->select(oclIsKindOf(Class) and name="MyClass")

  • Reported: OCL 2.0b2 — Wed, 7 Jan 2004 05:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    The suggested syntax comes from QVTo.
    Non-trivial OCL expressions can be difficult to read. Introducing shorthand notations compromises readability. At present OCL has "." and "->" shorthands that cause significant difficulties. Introducing more does not seem appropriate for the standard language.
    It is not clear that introduction of another [..] syntax can avoid conflicts with the already challenging conflicts for association qualifiers and array indexes.
    Disposition: Closed, no change

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

The notation for testing the type of a metaclass is too verbose

  • Key: OCL21-207
  • Legacy Issue Number: 6879
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    Suggestion: Use special characters to denote a call to oclIsKindOf and oclIsTypeOf.
    For instance, use '#ActionState' instead of 'oclIsKindOf(ActionState)'
    and use '##ActionState' instead of 'oclIsTypeOf(ActionState)'

  • Reported: OCL 2.0b2 — Wed, 7 Jan 2004 05:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    The suggested syntax comes from QVTo.
    Non-trivial OCL expressions can be difficult to read. Introducing shorthand notations compromises readability. At present OCL has "." and "->" shorthands that cause significant difficulties. Introducing more does not seem appropriate for the standard language.
    oclIsKindOf and oclIsTypeOf are already a source of confusion; oclIsTypeOf should rarely be used but is the more obvious name to new users, so providing a shorthand for oclIsTypeOf is unnecessary.
    The # syntax has no terminator so the shorthand needs an ambiguity resolution for a.#B.c()
    The suggested usage seems to conflict with the intuition of those familiar with unary prefixes of assembler languages or even OCL 1.x enumeration literals.
    If an improvement is to be made, something like
    (a as B).c()
    would contribute to rather than hamper readibility.
    Disposition: Closed, no change

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

Example with TupleType

  • Key: OCL21-206
  • Legacy Issue Number: 6614
  • Status: closed  
  • Source: Modeling Value Group ( Wim Bast)
  • Summary:

    Typo in an example with TupleType Section 7.5.15: In the example constraint, expression attr: Statistics : Set(TupleType(& This must be Tuple only, according to the concrete syntax.

  • Reported: OCL 2.0b2 — Thu, 13 Nov 2003 05:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    The typos are corrected in the overlapping Issue 15254.
    Disposition: See issue 15254 for disposition

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

Improve the notation when defining local variables

  • Key: OCL21-211
  • Legacy Issue Number: 6885
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    This is to avoid using the unreadable and unfriendly "let … in …" notation.
    Suggestion: Use the result of a variable initialization as in:
    if (let c = self.address)="" then "UNKNOWN"
    else if c.includes(Set

    {"Irak","Afganifsthan"}

    ) then "DANGEROUS"
    else "OK" endif endif endif …

  • Reported: OCL 2.0b2 — Wed, 7 Jan 2004 05:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    OCL 2.3 relaxed a VariableDeclarationCS to permit the typeCS to be omitted and deduced from the initializer.
    Disposition: Closed, no change

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

There is no simple way to invoke an "if then else" on a collection

  • Key: OCL21-210
  • Legacy Issue Number: 6882
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    Suggestion: Define an "alt" collection function, with a specific notation, as in:
    mylist->alt(iterator | condition? thenExp, elseExp)
    The expression elseExp is not evaluated if condition returns true

  • Reported: OCL 2.0b2 — Wed, 7 Jan 2004 05:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    It is not true that there is no way:
    mylist->collect(iterator | if condition then thenExp else elseExp endif)
    which has two more tokens than the suggestion but avoids introducing a "?" syntax irregularity.
    Disposition: Closed, no change

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

notation for selecting unique element within a list should be more concise

  • Key: OCL21-209
  • Legacy Issue Number: 6881
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    Suggestion: Use brackets with a "!" prefixing mark
    Example:
    self.ownedElement! #Class and name="MyClass"
    means
    self.ownedElement->select(oclIsKindOf(Class) and name="MyClass")->first()

  • Reported: OCL 2.0b2 — Wed, 7 Jan 2004 05:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    The suggested syntax comes from QVTo.
    Non-trivial OCL expressions can be difficult to read. Introducing shorthand notations compromises readability. At present OCL has "." and "->" shorthands that cause significant difficulties. Introducing more does not seem appropriate for the standard language.
    Disposition: Closed, no change

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

Provide specific notational support when testing stereotypes

  • Key: OCL21-216
  • Legacy Issue Number: 6893
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    Suggestion: Use the STAR character. Quotes could be used in case of blanks
    characters in stereotype names.
    Example: self.ownedElement.select(kindOf(Class) and *EJBEntity)
    returns all the classes stereotyped by the EJBEntity stereotype or a derived
    stereotype.
    Example: self.ownedElement.select(kindOf(Class) and **EJBEntity)
    returns all the classes stereotyped by the EJBEntity stereotype.

  • Reported: OCL 2.0b2 — Wed, 7 Jan 2004 05:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    Stereotype support is certainly required, but I think much of the trouble is inadequate tooling. The examples can be realised by:
    self.ownedElement->select(oclIsKindOf(Class)).oclAsType(Class) ->select(extension_EJBEntity <> null)
    self.ownedElement->select(oclIsKindOf(Class)).oclAsType(Class) ->select(extension_EJBEntity.oclIsTypeOf(EJBEntity))
    The clumsy ->select(oclIsKindOf(Class)).oclAsType(Class) 'idiom' is resolved by the selectByKind library operation from Issue 18829 to give
    self.ownedElement->selectByKind(Class)->select(extension_EJBEntity <> null)
    self.ownedElement->selectByKind(Class)->select(extension_EJBEntity.oclIsTypeOf(EJBEntity))
    Given that UML specified the magic "extension_" and "base_" prefixes, it seems best to encourage rather than obscure them.
    Disposition: Closed, no change

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

Suppress the usage of an Ocl prefix in standard library operations

  • Key: OCL21-215
  • Legacy Issue Number: 6890
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    When a name conflicts happen, it should be possible to resolve by qualifying the
    names.

  • Reported: OCL 2.0b2 — Wed, 7 Jan 2004 05:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    It is not really clear what this is issue is about.
    Perhaps the suggestion is to allow users to write x.isKindOf(Y) rather than x.oclIsKindOf(Y).
    There is a small benefit but also a confusion between alternate syntaxes and a need to change syntaxes to avoid confusion occasionally. Confusion is best avoided.
    Disposition: Closed, no change

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

Issue: Unspecified syntax and semantics for Integer, Real, and String

  • Key: OCL21-202
  • Legacy Issue Number: 6561
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Description: The specification does not describes the syntax of integer, real or string literals. Also, it does not contain the description of the allowed set of values.
    Rationale: Specifying the syntax and the semantics of basic types will increase the portability of OCL programs. In order to describe the semantics of basic types, the specification should describe the set of values, the allowed operations, and the standard used to perform the allowed operations. I think that it will be also useful to allow different types of integers and reals, like Integer(16), Integer(32), Integer(64), Real(32), and Real(64), in order to optimize the computational process.

  • Reported: OCL 2.0b2 — Tue, 11 Nov 2003 05:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    OCL 2.3 introduced concrete syntax specifications for integer, real or string literals.
    In regard to specific sets of values, the issue seems to indicate a misunderstanding of OCL; OCL is a specification language that may be evaluated. Integers and Reals are unlimited. If a particular implementation chooses to use a restricted value set, then it is for that implementation to prove that its reduced range is appropriate.
    Users can of course define their own DataTypes with whatever characteristics they find suitable.
    Disposition: Closed, no change

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

Allow implicit type casting to boolean when a boolean is expected

  • Key: OCL21-213
  • Legacy Issue Number: 6887
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    Example1: if list.select(...) then … equivalent to
    if list.select(...)->notEmpty() then …
    Example2: if item then … equivalent to
    if item<>OCLUndefined then ...

  • Reported: OCL 2.0b2 — Wed, 7 Jan 2004 05:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    The suggestion introduces a confusion for Boolean variables that may be null. For these variables <> null is required while for non-Boolean variables it can be omitted.
    This seems to be a significant degradation in type safety. Not even Java permits this freedom.
    Disposition: Closed, no change

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

Allow applying iteration operations on single objects

  • Key: OCL21-212
  • Legacy Issue Number: 6886
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    Use a DOT instead of an ARROW is this situation.
    myinstance.anycollectionfunction() equivalent to
    Set

    {myinstance}

    ->anycollectionfunction(…)->first()

  • Reported: OCL 2.0b2 — Wed, 7 Jan 2004 05:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    The usage of "." and "-"> in OCL is already confusing for many users. However there is a rationale.
    Introduction of a freedom to use "." will undermine user understanding in exchange for a minor convenience in a rare use case..
    Disposition: Closed, no change

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

Automatic casting between strings and enumeration values

  • Key: OCL21-214
  • Legacy Issue Number: 6889
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    Make optional the qualification of enumeration values.
    Example: Be able to write 'self.aggregationKind="Composite" ' as an alternative
    to 'self.aggregationKind=AggregationKind::Composite'.

  • Reported: OCL 2.0b2 — Wed, 7 Jan 2004 05:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    This seems like a harmless simplification (using OCL's single quotes rather than a Java-like double quotes), but creating a confusion between Strings and EnumerationLiterals may cause confusion when selecting operation overloads.
    Disposition: Closed, no change

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

Add a generic text formatter operator '%

  • Key: OCL21-217
  • Legacy Issue Number: 6894
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    Example: self.comment = "My name is %s" % self.firstname

  • Reported: OCL 2.0b2 — Wed, 7 Jan 2004 05:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    Presumably the suggestion is to build C's printf into OCL.
    However experience with printf has shown that it has significant type safety issues.
    I think a better solution requiring no change to the OCL language would be a String::printf() Standard Library operation.
    'My name is %s'.printf(self.firstname)
    Disposition: Closed, no change

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

The index seems incomplete

  • Key: OCL21-205
  • Legacy Issue Number: 6600
  • Status: closed  
  • Source: Modeling Value Group ( Wim Bast)
  • Summary:

    The index seems incomplete and leaves out interesting items (e.g., the definition of standard library functions).

  • Reported: OCL 2.0b2 — Wed, 12 Nov 2003 05:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    Inaccurate manually maintained indexes are discouraged in OMG specifications.
    The Index was accidentally omitted in OCL 2.3. It will not be re-instated.
    Disposition: Closed, no change

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

arguments of the return message of an ocl message expression

  • Key: OCL21-234
  • Legacy Issue Number: 7523
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    15. – [5] The arguments of the return message of an ocl message expression
    – evaluation must correspond to the names given by the formal output parameters,
    – and the result type of the operation indicated in the ocl message expression.
    – Note that the Parameter type is defined in the UML 1.4 foundation package.
    context OclMessageExpEval
    inv: let returnArguments: Sequence{ NameValueBindings ) =
    resultValue.returnMessage.arguments ,
    formalParameters: Sequence

    { Parameter }

    =
    ==> ’

    {’ should be ’(’ (twice), and ’}

    ’ should be ’)’

  • Reported: OCL 2.0b2 — Thu, 10 Jun 2004 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    yes

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

inv: model.sentSignal->size() = 1 implies

  • Key: OCL21-233
  • Legacy Issue Number: 7522
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    Sequence

    {1.. arguments->size()}

    ->forAll( i |
    arguments->at.variable->size() = 1 implies
    model.sentSignal.signal.feature->select(
    arguments->at.variable )->notEmpty()
    and
    arguments->at.expression->size() = 1 implies
    model.sentSignal.signal.feature.oclAsType(StructuralFeature).type =
    arguments->at.expression.model
    ==> missing final closing bracket

  • Reported: OCL 2.0b2 — Thu, 10 Jun 2004 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    yes

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

’element’ should be ’elements’

  • Key: OCL21-236
  • Legacy Issue Number: 7525
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    17. – [1] All elements belonging to a sequence value have unique index numbers.
    inv: self.element->isUnique(e : Element | e.indexNr)
    ==> missing context statement: context SequenceTypeValue,
    ==> ’element’ should be ’elements’

  • Reported: OCL 2.0b2 — Thu, 10 Jun 2004 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    yes

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

Only one of the attributes isPost and isPre may be true at the same time.

  • Key: OCL21-235
  • Legacy Issue Number: 7524
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    16. – [1] Only one of the attributes isPost and isPre may be true at the same time.
    context LocalSnapshot
    inv: isPost implies isPre = false
    inv: ispre implies isPost = false
    ==> second invariant: ’ispre’ should be ’isPre’

  • Reported: OCL 2.0b2 — Thu, 10 Jun 2004 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    yes

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

elements in a tuple value

  • Key: OCL21-242
  • Legacy Issue Number: 7531
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    23. – [1] The elements in a tuple value must have a type that conforms to the type
    – of the corresponding tuple parts.
    context TupleValue inv:
    elements->forAll( elem |
    let correspondingPart: Attribute =
    self.model.allAttributes()->select( part | part.name = elem.name ) in elem.value.model.conformsTo( correspondingPart.type ) )
    ==> ’Attribute’ should be ’UML14::Core::Attribute’
    ==> ’select’ should be ’any’

  • Reported: OCL 2.0b2 — Thu, 10 Jun 2004 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No: OCL 2.4 does not yet have a UML-aligned type system so the UML14::Core:: is a solution for one particular tool. The prefix certainly shouldn't be UML14. It is likely that the UML aligned solution will not require a prefix at all legitimizing the original exposition.
    Yes: any rather than select

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

arguments

  • Key: OCL21-232
  • Legacy Issue Number: 7521
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    13. – [4] The arguments of an ocl message expression evaluation must correspond to
    – the formal input parameters of the operation, or the attributes of the signal
    – indicated in the ocl message expression.
    context OclMessageExpEval
    inv: model.calledOperation->size() = 1 implies
    Sequence

    {1.. arguments->size()}

    >forAll( i | arguments>at.variable->size() = 1 implies
    model.calledOperation.operation.parameter->
    select( kind = ParameterDirectionKind::In )->at.name =
    arguments->at.variable
    and
    arguments->at.expression->size() = 1 implies
    model.calledOperation.operation.parameter->
    select( kind = ParameterDirectionKind::In )at.type =
    arguments->at.expression.model
    ==> missing ’->’ before ’at’, and missing final closing bracket

  • Reported: OCL 2.0b2 — Thu, 10 Jun 2004 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    yes

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

The history of an object is ordered.(02)

  • Key: OCL21-240
  • Legacy Issue Number: 7529
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    21. – [1] The history of an object is ordered. The first element does not have a
    – predecessor, the last does not have a successor.
    context ObjectValue
    inv: history->oclIsTypeOf(
    StandardLibrary::StdLib.Sequence(LocalSnapShot) )
    inv: history->last().succ->size = 0
    inv: history->first().Pre->size = 0
    ==> ’size’ should be ’size()’ (twice)

  • Reported: OCL 2.0b2 — Thu, 10 Jun 2004 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    Yes, although the affected text changed slightly in OCL 2.2.

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

The operation allPredecessors

  • Key: OCL21-241
  • Legacy Issue Number: 7530
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    22. – [1] The operation allPredecessors returns the collection of all snapshots
    – before a snapshot, allSuccessors returns the collection of all snapshots after
    – a snapshot.
    context LocalSnapshot
    def: allPredecessors() : Sequence(LocalSnapshot) =
    if pred->notEmpty then
    pred->union(pred.allPredecessors())
    else
    Sequence {}
    endif
    def: allSuccessors() : Sequence(LocalSnapshot) =
    if succ->notEmpty then
    succ->union(succ.allSuccessors())
    else
    Sequence {}
    endif
    ==> ’notEmpty’ should be ’notEmpty()’ (twice)

  • Reported: OCL 2.0b2 — Thu, 10 Jun 2004 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    yes

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

history of an object is ordered.

  • Key: OCL21-239
  • Legacy Issue Number: 7528
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    20. – [1] The history of an object is ordered. The first element does not have a
    – predecessor, the last does not have a successor.
    context ObjectValue
    inv: history->oclIsTypeOf( Sequence(LocalSnapShot) )
    inv: history->last().succ->size = 0
    inv: history->first().Pre->size = 0
    ==> should be:
    context ObjectValue
    inv: history->oclIsTypeOf(
    StandardLibrary::StdLib.Sequence(LocalSnapShot) )
    inv: history->last().succ->size = 0
    inv: history->first().Pre->size = 0

  • Reported: OCL 2.0b2 — Thu, 10 Jun 2004 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    This issue seems to have been corrupted and reentered as Issue 7529..
    Disposition: Closed, no change

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

’Element’ should be ’NameValueBinding’

  • Key: OCL21-238
  • Legacy Issue Number: 7527
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    19. – [1] All elements belonging to a tuple value have unique names.inv: self.elements->isUnique(e : Element | e.name)
    ==> missing context statement: context TupleValue
    ==> ’Element’ should be ’NameValueBinding’

  • Reported: OCL 2.0b2 — Thu, 10 Jun 2004 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    yes

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

’element’ should be ’elements’ (02)

  • Key: OCL21-237
  • Legacy Issue Number: 7526
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    18. – [1] All elements belonging to a set value have unique values.
    inv: self.element->isUnique(e : Element | e.value)
    ==> missing context statement: context SetTypeValue
    ==> ’element’ should be ’elements’

  • Reported: OCL 2.0b2 — Thu, 10 Jun 2004 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    yes

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

Add select/reject/collectNested to Collection

  • Key: OCL21-198
  • Legacy Issue Number: 6551
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Author: Hubert Baumeister (baumeist@informatik.uni-muenchen.de),
    Rolf Hennicker (hennicke@informatik.uni-muenchen.de),
    Alexander Knapp (knapp@informatik.uni-muenchen.de)
    Description: Add select/reject/collectNested to Collection
    Rationale:
    The definition of any on Collection (page 6-16f.) uses select on Collection. However, select is not defined for Collection. Similarly, the definition of collect on Collection (page 6-17) uses collectNested on Collection, which is not defined on Collection. We therefore propose to add select and collectNested (and possibly reject) to Collection.

  • Reported: OCL 2.0b2 — Tue, 11 Nov 2003 05:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

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

Exception of strict evaluation (queries)

  • Key: OCL21-197
  • Legacy Issue Number: 6540
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Author: Thomas Baar (thomas.baar@epfl.ch)
    Description: Strict evaluation for queries yields to contradictions in specifications
    Rationale: Queries can be specified in two ways, as invariants and in form of pre/post conditions. Suppose we specify query q(arg) as
    post: if (arg.oclIsUndefined()) then result = true else result = false endfi
    Having this, the following invariant should evaluate always to true:
    self.q(arg) = true or self.q(arg) = false.
    However, the invariant evaluates to undef once arg evaluates to undef thanks to strict evaluation.
    There is a misconception of strict evaluation when it comes to queries. The idea of queries is to have user-defined functions on classes. Why should the user be restricted only to such function which return undef once one of its arguments is undef? Using OCL, the user can even specify queries which can handle undefined arguments (e.g. see post specification of q(arg) ). Obviously, the post specification for q(arg) makes sense.
    The rule of strict evaluations for queries should be weakened to the case where the owner of the query (the object upon the query was called) is undefined.

  • Reported: OCL 2.0b2 — Mon, 10 Nov 2003 05:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    This issue was raised before undefined was clarified as null and invalid. It is now permissible to pass null values to queries. Only invalid values cannot be passed.
    Disposition: Closed, no change

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

Issue: Virtual machine

  • Key: OCL21-201
  • Legacy Issue Number: 6559
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Description: The OCL 2.0 specification should be behaviour-oriented and not implementation-oriented (see section 4.3).
    Rationale: The idea of using OCL to describe itself is interesting from the research point of view, but unfortunately OCL is not a suitable metalanguage to define the meaning of other textual languages. I think that the best thing to do is to define a virtual machine and to describe the behaviour of the virtual machine using natural language. This technique was successfully used for languages like C, C+, Java, C#, and Prolog. I see no reasons why such a technique would fail for OCL. After all, OCL is less complex than modern programming language like C+, Java, or C#.
    A proper description and implementation of the OCL virtual machine will create all the conditions to have a language that is platform/tool independent.

  • Reported: OCL 2.0b2 — Tue, 11 Nov 2003 05:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    The specification can no doubt be improved. Most criticisms concern inconsistency and lack of formaility. Moving to "natural language" seems a retrograde approach. Work in progress attempts to remove inconsistency from auto-generation from models, and to improve formality by using an exposition of the semantics that can be checked by Isabelle.
    Disposition: Closed, no change

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

Clarify the UML semantics of IfExpEval

  • Key: OCL21-200
  • Legacy Issue Number: 6554
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Author: Hubert Baumeister (baumeist@informatik.uni-muenchen.de),
    Rolf Hennicker (hennicke@informatik.uni-muenchen.de),
    Alexander Knapp (knapp@informatik.uni-muenchen.de)
    Description: Clarify the UML semantics of IfExpEval
    Rationale:
    The specification on page 5-21 of the evaluation of if_then_else omits the case when the condition evaluates to undefined. Thus the sentence should read:
    "The result value of an if expression is the result of the thenExpression if the condition is true, it is the result of the elseExpression if the condition is false, else it is undefined."

  • Reported: OCL 2.0b2 — Tue, 11 Nov 2003 05:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    The resolution for this becomes more complex with null/invalid rather than undefined. The resolution is in 17531.
    Disposition: See issue 17531 for disposition

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

Exception of strict evaluation (implies)

  • Key: OCL21-195
  • Legacy Issue Number: 6538
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Author: Thomas Baar (thomas.baar@epfl.ch)
    Description: Exception from strict evaluation for IMPLIES is incomplete and contradicts set-theoretical semantics
    Rationale: On page 2-10 only one exception from strict evaluation for IMPLIES is given:
    False IMPLIES x == True
    However, based on the official semantics of IMPLIES given on page A-12
    also x IMPLIES True == True

  • Reported: OCL 2.0b2 — Mon, 10 Nov 2003 05:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    The requested change actually occurred in OCL 2.2. However the clarification of null and invalid for Issue 17531 conflicts with the resolution, so this issue is therefore merged.
    Disposition: See issue 17531 for disposition

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

Exception of strict evaluation (forAll, exists)

  • Key: OCL21-196
  • Legacy Issue Number: 6539
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Author: Thomas Baar (thomas.baar@epfl.ch)
    Description: Exception of strict evaluation should be extended to forAll, exists
    Rationale: Suppose r(o1) = undef, r(o2) = false What is value of Exp =

    {o1, o2}

    ->forAll(x| r) ? One could argue, because of strict evaluation, the value of Exp is undef. However, this would contradict the semantics of forAll als 'iterated and' given on page A.28. Similarily, for exists.
    A note should be added on page 2-10 on evalution of expressions based on iterate.

  • Reported: OCL 2.0b2 — Mon, 10 Nov 2003 05:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    The resolution for this becomes more complex with null/invalid rather than undefined. The resolution is in 17531.
    Disposition: See issue 17531 for disposition

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

Clarify the semantics of forAll

  • Key: OCL21-199
  • Legacy Issue Number: 6553
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Author: Hubert Baumeister (baumeist@informatik.uni-muenchen.de),
    Rolf Hennicker (hennicke@informatik.uni-muenchen.de),
    Alexander Knapp (knapp@informatik.uni-muenchen.de)
    Description: Clarify the semantics of forAll
    Rationale:
    According to the informal explanation (page 6-16) the following Expression Set

    { 1 }

    ->forAll(x | x/0 < 0) would evaluate to false. However, according to the OCL definition it evaluates to undefined. Thus we propose to omit "otherwise, result is false" in the informal explanation.

  • Reported: OCL 2.0b2 — Tue, 11 Nov 2003 05:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    The resolution for this becomes more complex with null/invalid rather than undefined. The resolution is in 17531.
    Disposition: See issue 17531 for disposition

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

Notation for accessing class operations is inconsistent

  • Key: OCL21-265
  • Legacy Issue Number: 8937
  • Status: closed  
  • Source: International Business Machines ( Dr. Tracy Gardner)
  • Summary:

    The OCL 2.0 spec is inconsistent on whether class operations, including predefined operations, should be accessed using '.' or '::' notation.
    E.g. should it be Person.allInstances() or Person::allInstances()

    The spec uses Person.allInstances() in the text, but the concrete syntax specifies '::'.

    It seems that most tools have adopted the '.' notation used in the examples which is also backwards compatible with previous versions of OCL.
    There has also been some adoption of the '::' notation, for example in Warmer and Kleppe's OCL book, see: http://www.klasse.nl/english/boeken/ocl-book-errata.pdf

    Note: This issue was originally pointed out by Anthony Shuttleworth of Paranor.

    Proposed solution:

    The '.' notation is widely used and backwards compatible with previous versions of OCL. It should not be made invalid in OCL 2.0.
    It may be appropriate to also support the '::' notation if this has been widely adopted.

  • Reported: OCL 2.0 — Thu, 21 Jul 2005 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

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

Navigating across non navigable associations

  • Key: OCL21-264
  • Legacy Issue Number: 8918
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The spec ptc/03-10-14 lists navigating across non navigable associations as a compliance point. However, all text describing the rules for doing so have been removed from this version. The rules need to be defined more clearly in the OCL syntax.

    The following rules for navigation using non-navigable associations extend the text in sections 7.5.4 Navigation to Association Classes, and sections 7.5.5 Navigation from Association classes,

    When a non-navigable association is between different classes, following the association to an opposite end class is specified by:
    ("self" | <class name>) "." <association class name>["[" < opposite role name> "]"]"." <role name>

    Note the optional component is redundant, but is allowed, but not recommended.

    When a non-navigable association is between the same classes, following the association to an opposite end class is specified by:
    ("self" | <class name>) "." <association class name>"[" < opposite role name> "]." <role name>

  • Reported: OCL 2.0 — Fri, 8 Jul 2005 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

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

allInstances

  • Key: OCL21-263
  • Legacy Issue Number: 8917
  • Status: closed  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    It is not entirely clear from the OCL 2.0 specification whether the allInstances operation returns instances of subclasses of the designated type. In other words, it isn't 100% clear whether t.allInstances( ) returns instances of subclasses of t.

    Recommendation:

    The best solution would be to have two operations, one which returns instances of subclasses and one which does not.

    A second-best solution would be to make it clear that allInstances returns instances of subclasses. In this case, an OCL programmer could use the oclIsTypeOf( ) operation as a filter to write a derived operation that does not return instances of subclasses. If allInstances does not return instances of subclasses, it would not be nearly as straightforward to write a derived operation that does return instances of subclasses.

  • Reported: OCL 2.0 — Tue, 12 Jul 2005 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

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

Section: 1 - 13

  • Key: OCL21-261
  • Legacy Issue Number: 8667
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    General comments: OCL primitive types do not agree with UML primitive types. Multiplicity symbology for "infinite" is different. UML uses "*" whereas OCL uses "n." Capitalize the word "Boolean" as it is named for the 19th Century mathematicial George Boole. In most places it is capitalized but there are several places where it is not. I hope my comments have not been too annoying. Please consider everything I know about OCL I have learned from reading this document so if my comments don't make a lot of sense, then possibly clarification in the document may be needed.

  • Reported: OCL 2.0b2 — Wed, 30 Mar 2005 05:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    OCL primitive types now align, since UML has introduced Real.
    */n multiplicity is a drawing tool artefact. It may be resolved when redrawn for an autogenerated OCL 2.5.
    boolean in non-technical contexts can be corrected.

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

Section: 11.9.3 & 11.9.4

  • Key: OCL21-260
  • Legacy Issue Number: 8666
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Typo - pg 151 change "The standard iterator expression" to "The standard iterator expressions." The reject expression for both Bag and Sequence have "source->select(iterator | not body) on the left side of the equals symbol. Shouldn't the word "iterate" be used instead of "select?" The sortedBy expression is very restrictive if the sort order must always have the lowest value first. A statement that a sort order could be by a > value would be nice.

  • Reported: OCL 2.0b2 — Wed, 30 Mar 2005 05:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    The typo is actually for Set.
    The wording for reject is correct; reject is defined as select with a not body.
    The sortedBy issue is a repeat of Issue 8665, which remains unresolved. (Maybe we need a sort(i, j | body) iteration so that body can return pairwise comparison which could be in reverse order.)

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

Section: 11.2.1

  • Key: OCL21-258
  • Legacy Issue Number: 8659
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Last line on page is a sentence fragment

  • Reported: OCL 2.0b2 — Tue, 29 Mar 2005 05:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    redundant line

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

Section: 10.2.2 LocalSnapshot

  • Key: OCL21-257
  • Legacy Issue Number: 8645
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Typos - Change "ispre" to "isPre" and reword [2] to "...postcondition snapshot does it have an associated..."

  • Reported: OCL 2.0b2 — Mon, 28 Mar 2005 05:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    The typo is corrected in Issue 7524.

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

Section: 7.5.13

  • Key: OCL21-255
  • Legacy Issue Number: 8626
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    The example using Bike and Car as two separate subtypes of Transport does not make any mention of Set(Car), Bag(car), or Collection(Car). Either delete reference to Car as a separate subtype of Transport or add some comments about a collection of some sort of Car conforming (and not conforming) to some other collection. I may be confused, but the statement "Note that Set(Bicycle) does not conform to Bag(Bicycle)" does not make a lot of sense to me. Wouldn't it be better to say that "Set(Bicycle) does not conform to Bag(car)?"

  • Reported: OCL 2.0b2 — Thu, 24 Mar 2005 05:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    Yes the words can be a little clearer

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

The spec does not describes the syntax of integer, real or string literals

  • Key: OCL21-262
  • Legacy Issue Number: 8789
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    1) The specification does not describes the syntax of integer, real or string literals.
    The specification does not describes the syntax of integer, real or string literals.
    Specifying the syntax and the semantics of basic types will increase the portability
    of OCL programs

  • Reported: OCL 2.0b2 — Wed, 18 May 2005 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    These specifications were introduced in OCL 2.3
    Disposition: Closed, no change

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

Section: 11.5.4

  • Key: OCL21-259
  • Legacy Issue Number: 8661
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    What is the difference in meaning between the definitions of or(b:Boolean): Boolean and xor(b:Boolean): Boolean? or(b:Boolean): Boolean says True if either self or b is true which implies "but not both" which is the ending phrase of the definition of xor(b:Boolean): Boolean.

  • Reported: OCL 2.0b2 — Tue, 29 Mar 2005 05:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    The resolution of Issue 17531 rephrased this.
    Disposition: See issue 17531 for disposition

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

Section: 7.6.2

  • Key: OCL21-256
  • Legacy Issue Number: 8627
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    In the 2nd paragraph, shange "The value of the reject operation..." to "The value of the collect operation..."

  • Reported: OCL 2.0b2 — Thu, 24 Mar 2005 05:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    The typo is corrected in Issue 15980.
    Disposition: See issue 15980 for disposition

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

rewrite well-formedness

  • Key: OCL21-219
  • Legacy Issue Number: 7466
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    We would like to be able to rewrite well-formedness rules like:
    context IfExp
    inv: self.condition.type.oclIsKindOf(Primitive) and
    self.condition.type.name = ’Boolean’
    as
    context IfExp
    inv: self.condition.type.oclIsKindOf(Primitive) and This is more clear that the first expression where the matching is done by name.
    Because the metamodel resides on a level higher than the standard library, we need a way to get access
    to the standard library elements. One solution is to define a package ’StandardLibrary’ that contains a
    Classifier called ’StdLib’, that holds the following attributes:
    • + Collection: CollectionType;
    • + Set: SetType;
    • + OrderedSet: OrderedSetType;
    • + Sequence: SequenceType;
    • + Bag: BagType;
    • + String: Primitive;
    • + OclMessage: OclMessageType;
    • + OclVoid : VoidType;
    Other solutions might be possible, but the above has been proven to work in the Octopus tool.

  • Reported: OCL 2.0b2 — Thu, 10 Jun 2004 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    Unfortunately the 'better' example is missing from the above text. Presumably it should read:
    context IfExp
    inv: self.condition.type.oclIsKindOf(Primitive) and self.condition.type = StdLib::Boolean
    OCL supports type literal as in a.oclIsKindOf(Boolean) so the 1.x practice of comparing types by string-valued name was a misunderstanding. It is possible to write
    inv: self.condition.type.oclIsKindOf(Primitive) and self.condition.type = Boolean
    Disposition: Closed, no change

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

Make usage of tuples less complex and less verbose

  • Key: OCL21-218
  • Legacy Issue Number: 6895
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    Suggestions:

    • Make type spec of internal fields optional.
    • Make field name in tuples optional (using positional access)
  • Reported: OCL 2.0b2 — Wed, 7 Jan 2004 05:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    OCL 2.3 relaxed VariableDeclarationCS to allow inference of an omitted type from an initializer.
    Allowing field names to be omitted and resolved positionally reduces type safety of programs when first written and makes them vulnerable to meta-model evolution thereafter.
    Disposition: Closed, no change

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

sub evaluations (in the sequence bodyEvals)

  • Key: OCL21-225
  • Legacy Issue Number: 7512
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    4. – [2] All sub evaluations (in the sequence bodyEvals) have a different
    – environment. The first sub evaluation will start with an environment in which
    – all iterator variables are bound to the first element of the source. Note that
    – this is an arbitrary choice, one could easily well start with the last element
    – of the source, or any other combination.
    context LoopExpEval
    inv: let bindings: Sequence( NameValueBindings ) =
    iterators->collect( i |
    NameValueBinding( i.varName, source->asSequence()->first() )
    in
    bodyEvals->at(1).environment = self.environment->addAll( bindings )
    ==> missing closing bracket before ’in’

  • Reported: OCL 2.0b2 — Thu, 10 Jun 2004 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    yes

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

context IfExpEval inv:

  • Key: OCL21-224
  • Legacy Issue Number: 7511
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    resultValue = if condition then thenExpression.resultValue else
    elseExpression.resultValue
    ==> missing ’endif’

  • Reported: OCL 2.0b2 — Thu, 10 Jun 2004 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

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

isSent attribute

  • Key: OCL21-228
  • Legacy Issue Number: 7515
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    7. – [4] The isSent attribute of the resulting ocl message value is true only if
    – the message value is in the outgoing messages of the ‘self’ object.
    context OclMessageExpEval
    inv:
    if resultValue.oclIsUndefined()
    resultValue.isSent = false
    else
    resultValue.isSent = true
    endif
    ==> add ’then’ after ’oclIsUndefined()’

  • Reported: OCL 2.0b2 — Thu, 10 Jun 2004 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    yes

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

ocl message expression

  • Key: OCL21-227
  • Legacy Issue Number: 7514
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    6. – [2] The result value of an ocl message expression is the sequence of the
    – outgoing messages of the ‘self’ object that matches the expression. Note that
    – this may result in an empty sequence when the expression does not match to any
    – of the outgoing messages.
    context OclMessageExpEval
    inv: resultValue =
    environment.getValueOf( ’self’ ).outgoingMessages->select( m |
    m.target = target.resultValue and
    m.name = self.name and
    self.arguments->forAll( expArg: OclMessageArgEval |
    not expArg.resultValue.oclIsUndefined() implies
    m.arguments->exists( messArg | messArg.value = expArg.value ))
    ==> add one closing bracket after expression

  • Reported: OCL 2.0b2 — Thu, 10 Jun 2004 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    yes

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

an iterate expression evaluation

  • Key: OCL21-231
  • Legacy Issue Number: 7520
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    12. – [1] The model of the result of an iterate expression evaluation is equal to
    – the model of the result of the associated IterateExp.
    context IterateExpEval
    inv: result.model = model.result )
    ==> remove last bracket

  • Reported: OCL 2.0b2 — Mon, 14 Jun 2004 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    yes

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

missing ’inv:’ twice

  • Key: OCL21-230
  • Legacy Issue Number: 7519
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    11. – [1] The condition evaluation corresponds with the condition of the expression,
    – and likewise for the thenExpression and the else Expression.
    context IfExpEval inv:
    condition.model = model.condition
    thenExpression.model = model.thenExpression
    elseExpression.model = model.elseExpression
    ==> missing ’inv:’ twice

  • Reported: OCL 2.0b2 — Thu, 10 Jun 2004 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    yes

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

1] The type of the attribute is the type of the value expression.

  • Key: OCL21-222
  • Legacy Issue Number: 7508
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    context TupleLiteralExpPart
    inv: attribute.type = value.type
    ==> should be removed, class does not exist

  • Reported: OCL 2.0b2 — Thu, 10 Jun 2004 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    The offending text was removed in OCL 2.2.
    Disposition: Closed, no change

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

An additional attribute refParams lists all parameters of the referred

  • Key: OCL21-221
  • Legacy Issue Number: 7507
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    38. – [3] An additional attribute refParams lists all parameters of the referred
    – operation except the return and out parameter(s).
    context OperationCallExp
    def: refParams: Sequence(Parameter) = referredOperation.parameters-
    >select (p

    p.kind <> ParameterDirectionKind::return or
    p.kind <> ParameterDirectionKind::out)
    ==> ’parameters’ should be ’Parameter’

  • Reported: OCL 2.0b2 — Thu, 10 Jun 2004 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    The offending parameters waschanged to ownedParameter-in OCL 2.2.
    Disposition: Closed, no change

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

sub evaluations (in sequence bodyEvals) have different environment.

  • Key: OCL21-226
  • Legacy Issue Number: 7513
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    5. – [3] All sub evaluations (in the sequence bodyEvals) have a different
    – environment. The environment is the same environment as the one from the
    – previous bodyEval, where the iterator variable or variables are bound to the
    – subsequent elements of the source.
    context LoopExpEval
    inv:
    let SS: Integer = source.value->size()
    in if iterators->size() = 1 then
    Sequence

    {2..SS}

    ->forAll( i: Integer |
    bodyEvals->at.environment = bodyEvals->at(i-1).environment
    >replace( NameValueBinding( iterators>at(1).varName,
    source.value->asSequence()->at )))
    else – iterators->size() = 2
    Sequence

    {2..SS*SS}

    ->forAll( i: Integer |
    bodyEvals->at.environment = bodyEvals->at(i-1).environment
    >replace( NameValueBinding( iterators>at(1).varName,
    source->asSequence()->at(i.div(SS) + 1) ))
    >replace( NameValueBinding( iterators>at(2).varName,
    source.value->asSequence()->at(i.mod(SS)) )) ) endif
    ==> two closing brackets before ’endif’ should be removed

  • Reported: OCL 2.0b2 — Thu, 10 Jun 2004 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    yes

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

add ’and’ between both expression parts

  • Key: OCL21-229
  • Legacy Issue Number: 7516
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    8. – [1] An ocl message argument evaluation has either an ocl expression
    – evaluation, or an unspecified value expression evaluation, not both.
    context OclMessageArgEval inv:
    expression->size() = 1 implies unspecified->size() = 0
    expression->size() = 0 implies unspecified->size() = 1
    ==> add ’and’ between both expression parts

  • Reported: OCL 2.0b2 — Thu, 10 Jun 2004 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    Yes. But I cannot check the precedence without reading the spec so use a more obvious exposition

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

context LocalSnapshot

  • Key: OCL21-223
  • Legacy Issue Number: 7509
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    Errors found in UML-based-semantics
    1. context LocalSnapshot
    def: let allPredecessors() : Sequence(LocalSnapshot) =
    if pred->notEmpty then
    pred->union(pred.allPredecessors())
    else
    Sequence {}
    endif
    def: let allSuccessors() : Sequence(LocalSnapshot) =
    if succ->notEmpty then
    succ->union(succ.allSuccessors())
    else
    Sequence {}
    ==> remove ’let’ from both expressions, add ’endif’ after the second

  • Reported: OCL 2.0b2 — Thu, 10 Jun 2004 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    Yes, except final endif is there (but was wrong font in OCL 2.0).

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

context State::getStateMachine() : StateMachine

  • Key: OCL21-220
  • Legacy Issue Number: 7503
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    post: result =
    if statemachine->notEmpty() then
    stateMachine
    else
    – must be part of a composite state
    state.container.getStateMachine()
    endif
    context Transition::getStateMachine() : StateMachine
    post: result =
    if statemachine->notEmpty() then
    stateMachine
    else
    – state is not empty
    state.getStateMachine()
    endif
    ==> in both expressions ’statemachine’ should be stateMachine

  • Reported: OCL 2.0b2 — Thu, 10 Jun 2004 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    The offending expressions were rewritten in OCL 2.2 without similar typos.
    Disposition: Closed, no change

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