1. OMG Mailing List
  2. OCL 2.5 Revision Task Force

Open Issues

  • Issues not resolved
  • Name: ocl2-rtf
  • Issues Count: 211

Issues Summary

Key Issue Reported Fixed Disposition Status
OCL25-211 OrderedSet::insertAt unclear for insert of existing element OCL 2.4 open
OCL25-15 Section: 7.5.15 OCL 2.0 open
OCL25-210 Clarify indeterminate/unknown order for asSequence/asOrderedSet/any OCL 2.4 open
OCL25-209 Are failures invalid? OCL 2.4 open
OCL25-208 Add % operator OCL 2.4 open
OCL25-207 Generalize body/precondition/postcondition as named capabilities OCL 2.4 open
OCL25-92 OCL 2.1 Feature Overloading Semantics are not defined OCL 2.1 open
OCL25-206 How is OCL used with a UML InstanceSpecification? OCL 2.4 open
OCL25-205 Support MyStereotype.allInstances() OCL 2.4 open
OCL25-204 Wrong color for abstract syntax presentation OCL 2.4 open
OCL25-203 How indeterminate are asOrderedSet/asSequence? OCL 2.4 open
OCL25-202 Provide a Map of qualified associations OCL 2.4 open
OCL25-201 Make null-free collections the default OCL 2.4 open
OCL25-200 OCL: Usage of qualifiers OCL 2.0b1 open
OCL25-197 Indaequate Issue 15836 resultion of negative CollectionRange OCL 2.3.1 open
OCL25-198 Inconsistent OclVoid::oclAsType return OCL 2.3.1 open
OCL25-199 parameters of the referredOperation OCL 2.0b2 open
OCL25-188 result value of an association class call expression evaluation OCL 2.0b2 open
OCL25-195 context Classifier (02) OCL 2.0b2 open
OCL25-189 Allow defining default values for parameters in operations OCL 2.0b2 open
OCL25-190 OclUndefined / allInstances() clarification. OCL 2.0b2 open
OCL25-196 Template return types in operation signatures OCL 2.0b2 open
OCL25-191 OCL 2: what is a collection? OCL 2.0b1 open
OCL25-194 OCL 2.1 12 Definition Accessibility Semantics OCL 2.1 open
OCL25-193 Japan PAS Ballot Comment 20 Section 9.3.29 OperationCallExpCS OCL 2.1 open
OCL25-192 Collection{} is Collection(OclVoid){} OCL 2.1 open
OCL25-185 elements in the result value OCL 2.0b2 open
OCL25-184 result value of an if expression OCL 2.0b2 open
OCL25-186 value of a collection item OCL 2.0b2 open
OCL25-187 result value of an association end call expression OCL 2.0b2 open
OCL25-180 Section: 10.2.3 ObjectValue OCL 2.0b2 open
OCL25-181 Section: 9.1 OCL 2.0b2 open
OCL25-182 Section: 8.3.8 OCL 2.0b2 open
OCL25-183 Section: 8.3.1 OCL 2.0b2 open
OCL25-168 OCL 2.1 Loop iterators are not ordered and other inconsistencies OCL 2.1 open
OCL25-169 OCL 2.1 12 Documents OCL 2.1 open
OCL25-170 OCL 2.1 12 Definition uses LetExp OCL 2.1 open
OCL25-171 OCL 2.0 Issue: References to Additional Attributes and Operations OCL 2.0 open
OCL25-172 Section: A.3.2.2 Syntax and Semantics of Postconditions (02) OCL 2.0 open
OCL25-174 OCL Collections applied to Properties OCL 2.0 open
OCL25-175 Container of additional operations OCL 2.0b2 open
OCL25-173 Section: 11.9.2 sortedBy OCL 2.0b2 open
OCL25-176 Section: 10.3.4 OclMessageArgEval OCL 2.0b2 open
OCL25-177 Section: 10.3.2 AssociationEndCallExpEval OCL 2.0b2 open
OCL25-178 Section: 10.3 OCL 2.0b2 open
OCL25-179 Section: 10.2.1 Element OCL 2.0b2 open
OCL25-167 OCL 2.1 Nested Collection Iteration OCL 2.1 open
OCL25-158 Vagueness about meaning of 0..1 multiplicity in OCL and UML OCL 2.1 open
OCL25-160 OCL 2.2 forAllAt suggestion OCL 2.1 open
OCL25-159 OCL Generics OCL 2.1 open
OCL25-161 OCL 2.2 Generalisation of Issue 7341 PathNames OCL 2.1 open
OCL25-163 OCL 2.2 Correction to Issue 9796 for isPre OCL 2.1 open
OCL25-162 OCL 2.2 7.5.4 Property-qualified association navigation has no concrete or abstract syntax OCL 2.1 open
OCL25-164 OCL 2.1 Parametric references OCL 2.1 open
OCL25-165 OCL 2.1 conformsTo definition suggestion OCL 2.1 open
OCL25-166 wrong parameter type for addNamespace operation call OCL 2.1 open
OCL25-157 OCL 2.3 Pathname syntax does not allow access to hidden names OCL 2.1 open
OCL25-147 Incomplete and missing well-formedness rules OCL 2.0b2 open
OCL25-148 Lack of operation specifications OCL 2.0b2 open
OCL25-149 Up- and Down-casts with oclAsType(). OCL 2.0b2 open
OCL25-150 Provide access to the sender of a message OCL 2.0b2 open
OCL25-151 OCL 2: OrderedSet OCL 2.0b1 open
OCL25-155 Japan PAS Ballot Comment 21 (ocl2-rtf) Section 9.3.37 OclMessageExpCS OCL 2.1 open
OCL25-156 Issue nnnn: Japan PAS Ballot Comment 12 (ocl2-rtf) Section 8.3.1 Fig 8.2 & FeatureCallExp in p43 OCL 2.1 open
OCL25-152 Append/prepend on OrderedSet does not necessarily increase the collection size OCL 2.4 open
OCL25-153 Missing Real::= overload OCL 2.4 open
OCL25-154 Introduce a Safe Navigation Operator OCL 2.3.1 open
OCL25-138 Section: 8.3.4 OCL 2.0b2 open
OCL25-139 Section: 8.2 OCL 2.0b2 open
OCL25-140 result value of an association end call expression OCL 2.0b2 open
OCL25-141 parameters of the referredOperation OCL 2.0b2 open
OCL25-142 Add an import statement to OCL files (with package - endpackage block) OCL 2.0b2 open
OCL25-143 The notation when nesting "if then else" is too verbose OCL 2.0b2 open
OCL25-144 Issue: Parsing Tuple Types and Collection Types as Arguments OCL 2.0b2 open
OCL25-145 Issue: Comments OCL 2.0b2 open
OCL25-146 Satisfaction of Operation Specifications (2) OCL 2.0b2 open
OCL25-136 Section: 10.3.4 OclMessageExpEval OCL 2.0b2 open
OCL25-137 Section: 10.3.2 NavigationCallExpEval OCL 2.0b2 open
OCL25-129 OCL 2.1 12 Incompleteness OCL 2.1 open
OCL25-128 OCL 2.1 12 Essential MOF support OCL 2.1 open
OCL25-130 Set operations for OrderedSet OCL 2.1 open
OCL25-132 Errors in examples OCL 2.0 open
OCL25-131 Recursivity is not explicitly addressed with examples OCL 2.0 open
OCL25-133 Naming of Constraints in OCL (02) OCL 2.0 open
OCL25-134 Recommendations re ptc/2005-06-06 OCL 2.0 open
OCL25-135 Section: 10.4 OCL 2.0b2 open
OCL25-126 OCL 2.1 12 Missing specification of initial and derived value constraints OCL 2.1 open
OCL25-127 OCL 2.1 11.7.3 OrderedSet addition well-formedness rules OCL 2.1 open
OCL25-123 OCL 2.2: AST is an ASG OCL 2.1 open
OCL25-124 OCL 2.2 OclMessage types are not statically derivable OCL 2.1 open
OCL25-125 Why OCL does not have "super" reference? OCL 2.1 open
OCL25-120 Japan PAS Ballot Comment 32 (ocl2-rtf): 10.3.1 Definitions of Concepts for the Evaluations Package, figure 10.11 OCL 2.1 open
OCL25-121 Japan PAS Ballot Comment 22 (ocl2-rtf) .4.2 NamedElement 9.4.3 Namespace, 11.2.5(p.135), 12.8.1(p.173) OCL 2.1 open
OCL25-122 OCL 2.3 Introduce a reserved OclSelf template parameter OCL 2.1 open
OCL25-119 Align OCL with out/inout UML Operation Parameters OCL 2.3.1 open
OCL25-108 The notation when nesting "if then else" is too verbose OCL 2.0b2 open
OCL25-109 Issue: Signature of Environment OCL 2.0b2 open
OCL25-110 Additional annotations in the OCL Standard Library OCL 2.0b2 open
OCL25-118 Align OCL bodyExpression and UML bodyCondition OCL 2.3.1 open
OCL25-113 Invalid algorithm in definitions of sortedBy OCL 2.4 open
OCL25-116 Example of collect in terms of iterate is not flattened OCL 2.4 open
OCL25-117 Conflicting String::indexOf postConditions OCL 2.4 open
OCL25-111 Support zero argument iterations OCL 2.1 open
OCL25-112 i/r typo OCL 2.4 open
OCL25-114 Add isInteger/isReal OCL 2.4 open
OCL25-115 indentified OCL 2.4 open
OCL25-105 OCL Constraints in many levels OCL 2.0b2 open
OCL25-104 number of elements in the result value OCL 2.0b2 open
OCL25-106 value of an association end call expression evaluation OCL 2.0b2 open
OCL25-107 Add a concrete syntax to allow OCL users to add additional IteratorExp’s OCL 2.0b2 open
OCL25-96 OCL 2.1 12 UML alignment OCL 2.1 open
OCL25-97 OCL 2.1 12 Definition Referencability Semantics OCL 2.1 open
OCL25-98 OCL 2.1 11.7 Inflexible Collection operation signatures OCL 2.1 open
OCL25-99 Redundant CollectionLiteralExp::kind complicates collection type extension OCL 2.0 open
OCL25-100 Provide the list of reflective MOF operations that are available OCL 2.0 open
OCL25-101 Section: 10.3.4 OclMessageArgEval OCL 2.0b2 open
OCL25-103 Section: 10.3.2 OperationCallExp OCL 2.0b2 open
OCL25-102 Section: 10.3.1 VariableExpEval OCL 2.0b2 open
OCL25-95 OCL 2.1 Inadequate definition of run-time meta-model OCL 2.1 open
OCL25-85 OCL Stereotypes OCL 2.1 open
OCL25-87 OCL 2.2: Section: 7.5.3 Clarification required for Qualifying association ends with association names OCL 2.1 open
OCL25-86 OCL 2.2 OclState, State, StateExp, StateExpCS, StateValue and StateExpEval OCL 2.1 open
OCL25-88 OCL 2.2 OclState and oclIsInState OCL 2.1 open
OCL25-89 OCL 2.2 Correction to Issue 9796 for AssociationEndCall OCL 2.1 open
OCL25-90 OCL 2.2 Clarity of qualified path names OCL 2.1 open
OCL25-91 Collection::sum is not realisable for empty collection of user defined type OCL 2.1 open
OCL25-94 OCL 2.1 11.7.3 Missing OrderedSet::- OCL 2.1 open
OCL25-93 OCL 2.1 11.7 Missing OrderedSet::excluding and including OCL 2.1 open
OCL25-83 OCL 2.3 - heterogeneous collections cannot be typed OCL 2.1 open
OCL25-84 OCL 2.3.TupleType semantics and AST OCL 2.1 open
OCL25-76 need clear specification for how to write OCL that refers to the stereotypes applied to a model within a UML profile OCL 2.1 open
OCL25-77 OCL 2.3 A.2.6 Collection conforms to OclAny contradiction OCL 2.1 open
OCL25-78 OCL parsed OCL string literal OCL 2.1 open
OCL25-79 OCL 2.3 Enumeration::allInstances() does not return instances OCL 2.1 open
OCL25-80 Japan PAS Ballot Comment 29 (ocl2-rtf) 10.2.4 Overview of the Values Package OCL 2.1 open
OCL25-81 Japan PAS Ballot Comment 15 (ocl2-rtf) Section 8.3.5 Fig8.7 & following class description (p50-p51) OCL 2.1 open
OCL25-82 Japan PAS Ballot Comment 14 (ocl2-rtf) - Section 8.3.2 Fig8.3 & AssociationClassCallExp OCL 2.1 open
OCL25-72 Error in OCL 2.4 spec OCL 2.1 open
OCL25-73 Missing/Poor definition of iterate() OCL 2.4 open
OCL25-74 Reverse CollectionRange should be empty rather than invalid OCL 2.4 open
OCL25-75 OclVoid::oclIsKindOf/oclIsTypeOf should return true/false rather than invalid OCL 2.4 open
OCL25-71 Obsolete implicit cast to Bag OCL 2.4 open
OCL25-65 value of an association class call expression OCL 2.0b2 open
OCL25-66 context Parameter::asAttribute(): Attribute OCL 2.0b2 open
OCL25-67 Allow defining standard library functions OCL 2.0b2 open
OCL25-68 compliance points strategies OCL 2.0b2 open
OCL25-70 Introduce a "tuplejoin" operator OCL 2.0b2 open
OCL25-69 Satisfaction of Operation Specifications (3) OCL 2.0b2 open
OCL25-62 Section 8.3.9 of the final Adopted Version of the OCL 2.0 Spec OCL 2.0 open
OCL25-61 Section: 10.4.3 IntegerLiteralExpEval OCL 2.0b2 open
OCL25-63 Section: 10.3.5 OCL 2.0b2 open
OCL25-64 Section: 9.3 CollectionLiteralPartsCS OCL 2.0b2 open
OCL25-54 OCL 2.1 11.7: Clarifying Collection Well-formedness rules OCL 2.1 open
OCL25-56 CMOF serializations of its metamodels not published OCL 2.0 open
OCL25-58 Section: A.3.2.2 Syntax and Semantics of Postconditions (04) OCL 2.0 open
OCL25-57 Section: A.3.2.2 Syntax and Semantics of Postconditions (03) OCL 2.0 open
OCL25-55 Mismatch between the definition of operators in, e.g., Section 11.7.1 and i OCL 2.0 open
OCL25-60 inclusion of Regular Expression support OCL 2.0 open
OCL25-59 Section: 11.5.1 OCL 2.0b2 open
OCL25-44 Satisfaction of Operation Specifications OCL 2.0b2 open
OCL25-43 Exception of strict evaluation (=) OCL 2.0b2 open
OCL25-50 OCL Enumeration allInstances OCL 2.1 open
OCL25-51 OCL 2.1 Navigation of opposites OCL 2.1 open
OCL25-52 OCL 2.1 Overload resolution OCL 2.1 open
OCL25-53 OCL 2.1 11.7.3 Missing OrderedSet::flatten overload OCL 2.1 open
OCL25-48 OCL 2.3 7.5.3 Missing Association End name problems OCL 2.1 open
OCL25-47 Japan PAS Ballot Comment 26 (ocl2-rtf) 10.2 The Values Package, 1st paragraph OCL 2.1 open
OCL25-49 Issue nnnn: Japan PAS Ballot Comment 4 (ocl2-rtf) OCL 2.1 open
OCL25-46 Complete OCL document must be a Package OCL 2.3.1 open
OCL25-45 Coolection operations do not allow invalid inputs OCL 2.4 open
OCL25-38 Section: 8.3.5 OCL 2.0b2 open
OCL25-40 Section: 8.3 OCL 2.0b2 open
OCL25-39 Section: 7.5.8 OCL 2.0b2 open
OCL25-41 result value of an association end call expression (02) OCL 2.0b2 open
OCL25-42 outgoingMessages results in the sequence of OclMessageValues OCL 2.0b2 open
OCL25-32 OCL 2.1 13.2 Reflection in OCL meta-models (correction to Issue 1 2951) OCL 2.1 open
OCL25-33 Special Types violate UML Generalization Semantics OCL 2.0 open
OCL25-34 Section: A/2.5.5 Collection Operations - Table A.3 OCL 2.0 open
OCL25-35 Section: 10.3.1 LoopExpEval OCL 2.0b2 open
OCL25-37 Section: 10.2.1 NameValueBinding OCL 2.0b2 open
OCL25-36 Section: 10.2 OCL 2.0b2 open
OCL25-30 OCL 2.2 Add endlet to make grammar extensible OCL 2.1 open
OCL25-31 Issue 14593 (UML alignment: Attribute) OCL 2.1 open
OCL25-18 result value of an association class call expression OCL 2.0b2 open
OCL25-19 context VariableDeclaration::asAttribute() : Attribute OCL 2.0b2 open
OCL25-20 context Operation OCL 2.0b2 open
OCL25-21 Issue: OclAny operations of tuples and collections OCL 2.0b2 open
OCL25-22 Issue: Grammar of OCL OCL 2.0b2 open
OCL25-17 Section: 10.1 OCL 2.0b2 open
OCL25-27 OCL 2.2 Unlimited and Infinity OCL 2.1 open
OCL25-28 OCL 2.2 Allow optional let type OCL 2.1 open
OCL25-29 OCL Constraint violation messages OCL 2.1 open
OCL25-25 Issue nnnn: Japan PAS Ballot Comment 3 (ocl2-rtf) OCL 2.1 open
OCL25-24 OCL 2.3 : Introduce Lambda functions OCL 2.1 open
OCL25-26 OCL 2.3 max, min iterations OCL 2.1 open
OCL25-23 How does Set distinguish duplicate values? OCL 2.3.1 open
OCL25-14 OCL 2.1 12 Inconsistencies OCL 2.1 open
OCL25-16 OCL 2.0 8.2 Collection Type name distinguishability OCL 2.0 open
OCL25-9 OCL 2.2 Missing definition of navigation OCL 2.1 open
OCL25-10 OCL 2.2 UML-alignment of redefinition OCL 2.1 open
OCL25-11 OCL 2.1 Section 10 problems OCL 2.1 open
OCL25-12 No postcondition for NamedElement::getType() when self.oclIsKindOf(Namespace) OCL 2.1 open
OCL25-13 lookupProperty instead of lookupAttribute OCL 2.1 open
OCL25-7 OCL 2.3: Message support hard to consume OCL 2.1 open
OCL25-8 OCL 2.3 Collecting elemental collections OCL 2.1 open
OCL25-5 Support zero and multiple context invariants OCL 2.3.1 open
OCL25-6 Unify @pre, ^, ^^, ? as extensibility mechanisms OCL 2.3.1 open
OCL25-2 StateSpec for oclInState() OCL 2.3.1 open
OCL25-1 oclInState instead of oclIsInState OCL 2.3.1 open
OCL25-3 status of objects and tuples OCL 2.0b2 open
OCL25-4 Missing mode precondition OCL 2.4 open

Issues Descriptions

OrderedSet::insertAt unclear for insert of existing element

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

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

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

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

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

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

Section: 7.5.15

  • Key: OCL25-15
  • Legacy Issue Number: 13057
  • Status: open  
  • Source: InferMed Ltd ( Craig Lucas)
  • Summary:

    Although it is clear that using a constructor to write an object to the system being modelled breaks the property of being side-effect free, it would be useful to return new objects as a result of the query functionality of OCL. It is possible to create a new Tuple for return from a function. For example: def: newDate1() : TupleType

    {day:Integer, month:Integer, year:Integer}

    = Tuple

    {day=10, month=12, year=1950}; It would be useful to have a similar way to generate a query result, but with a complex data type instead of a Tuple. For example: def: newDate2() : Date = Date{day=10, month=12, year=1950}

    ; Rather than write this object to the model under query, it would only be returned as a query result so, under these circumstances, would not break the property of being side-effect free. This feature would be extremely useful to the HL7 GELLO project, which works with data models defined in absense of defined methods or constructors. If this feature were to only apply to classes marked in some way to guarantee they have no side-effects from construction then that would remain useful.

  • Reported: OCL 2.0 — Wed, 5 Nov 2008 05:00 GMT
  • Updated: Tue, 20 Jun 2017 08:00 GMT

Clarify indeterminate/unknown order for asSequence/asOrderedSet/any

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

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

    "any" is specified as indeterminate.

    Non-determinism is a very bad language characteristic.

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

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

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

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

Are failures invalid?

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

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

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

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

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

Add % operator

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

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

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

    Suggest add Real::%

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

Generalize body/precondition/postcondition as named capabilities

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

    UML/OCL hardwire three capabilities of an Operation.

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

    Some users want frame conditions.

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

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

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

OCL 2.1 Feature Overloading Semantics are not defined

  • Key: OCL25-92
  • Legacy Issue Number: 14986
  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    OCL supports feature overloading and attempts to comply with UML. OCL does not define feature overloading itself. UML leaves feature overloading as a semantic variation point.

    The OCL behaviour is therefore undefined. However a variety of behaviours particularly those involving null and invalid only make sense if operations are selected at run-time according to the dynamic type.

    The example from an earilier pending issue:

    Sequence(OclAny)

    {3, 3.0, '3'}

    >count((-3)) = 2

    wherein

    UnlimitedNatural 3 widens to Integer 3 for successful comparison with Integer 3
    Real 3.0 is successfully compared to Integer 3 widened to Real
    String '3' widens to OclAny and fails to compare to Integer 3 widened to OclAny.

    is difficult to realise if static type resolution is applicable in which case all pair-wise value comparisons would use OclAny::= rather than Real::=.

    Suggest:

    OCL define that features are selected dynamically at run-time.

  • Reported: OCL 2.1 — Mon, 18 Jan 2010 05:00 GMT
  • Updated: Wed, 9 Mar 2016 15:48 GMT

How is OCL used with a UML InstanceSpecification?

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

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

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

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

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

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

Support MyStereotype.allInstances()

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

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

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

    Stereotype.allInstances() is equivalent to

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

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

Wrong color for abstract syntax presentation

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

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

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

How indeterminate are asOrderedSet/asSequence?

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

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

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

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

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

Provide a Map of qualified associations

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

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

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

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

Make null-free collections the default

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

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

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

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

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

OCL: Usage of qualifiers

  • Key: OCL25-200
  • Legacy Issue Number: 3513
  • Status: open  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    Qualifiers, written in brackets after the path name of a feature call,
    can express two different things.

    • qualifying use: A qualifier is used to give the qualifing value of
      a qualified association (chapter 7.5.7).
    • navigational use: A qualifier is used to refine the navigation to
      association classes. While this navigational use is necessary
      only with recursive associations, it is legal for every navigation
      to an association class (chapter 7.5.5).

    There is no way to distinguish these two sorts of qualifiers. There are
    even expressions where both uses of the qualifiers would be necessary at
    once, but this problem is restricted to such models that contain a
    recursive, qualified association that has an association class.

    Example where navigational and qualifing use cannot be distinguished:

    There are two classes "Bank" and "Person", with a association between
    them qualified by the account number (an Integer). The association end
    at the class Person is named "customers".
    An additional class "Company" has an attribute "customers" of type
    Integer.

    Now consider the subexpression "bank.person[customers]" in the context
    of Company. "bank" clearly is a navigational expression. But "customers"
    could either mean the attribute of Company, since Company is the context
    of the expression (that is qualifying use as defined in 7.5.7); or
    "customer" could mean the name of the association end (navigational use
    as defined in 7.5.5). In the first case, the result type would be
    Person, in the second case Set(Person).

  • Reported: OCL 2.0b1 — Wed, 29 Mar 2000 05:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

Indaequate Issue 15836 resultion of negative CollectionRange

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

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

    {1..size}

    ->forAll idiom.

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

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

Inconsistent OclVoid::oclAsType return

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

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

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

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

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

  • Reported: OCL 2.3.1 — Tue, 21 Apr 2015 04:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

parameters of the referredOperation

  • Key: OCL25-199
  • Legacy Issue Number: 7506
  • Status: open  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    37. – [2] The parameters of the referredOperation become attributes of the instance
    – of OclMessageType context OclMessageType
    inv: referredOperation->size() = 1 implies
    self.feature = referredOperation.Parameter->collect(p |
    p.asAttribute().oclAsType(Feature) ).asOrderedSet()
    ==> should be:
    context OclMessageType
    inv: referredOperation->size() = 1 implies
    self.feature = referredOperation.Parameter->collect(p | p.asAttribute()
    ).asOrderedSet()

  • Reported: OCL 2.0b2 — Thu, 10 Jun 2004 04:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

result value of an association class call expression evaluation

  • Key: OCL25-188
  • Legacy Issue Number: 7517
  • Status: open  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    9. – [2] The result value of an association class call expression evaluation that
    – has qualifiers, is determined according to the following rule. The ‘normal’
    – determination of result value is already given in section 5.3.7
    – ("Well-formedness Rules of the Evaluations package").
    ==> missing ’context .... inv:’
    ==> missing brackets and comma; the whole expression should be:
    let
    – the attributes that are the formal qualifiers. Because and
    association
    – class has two or
    – more association ends, we must select the qualifiers from the other
    end(s),
    – not from – the source of this expression. We allow only 2-ary associations.
    formalQualifiers : Sequence(Attribute) =
    self.model.referredAssociationClass.connection->any( c |
    c <> self.navigationSource).qualifier.asSequence() ,
    – the attributes of the class at the qualified end. Here we already
    assume
    – that an
    – AssociationEnd will be owned by a Classifier, as will most likely be
    the
    – case in the
    – UML 2.0 Infrastructure.
    objectAttributes: Sequence(Attribute) =
    self.model.referredAssociationClass.connection->any( c |
    c <> self.navigationSource).owner.feature->select( f |
    f.isOclType( Attribute ))->asSequence() ,
    – the rolename of the qualified association end
    qualifiedEnd: String = self.model.referredAssociationClass.connection-
    >any( c

    c <> self.navigationSource).name ,
    – the values for the qualifiers given in the ocl expression
    qualifierValues : Sequence( Value ) = self.qualifiers->asSequence() ,
    – the objects from which a subset must be selected through the
    qualifiers
    normalResult =
    source.resultValue.getCurrentValueOf(referredAssociationClass.name)
    in
    – if name of attribute of object at qualified end equals name of formal
    – qualifier then
    – if value of attribute of object at qualified end equals the value
    given in
    – the exp
    – then select this object and put it in the resultValue of this
    expression.
    qualifiers->size <> 0 implies
    normalResult->select( obj |
    Sequence

    {1..formalQualifiers->size()}

    ->forAll( i |
    objectAttributes->at.name = formalQualifiers->at.name and
    obj.qualifiedEnd.getCurrentValueOf( objectAttributes->at.name ) =
    qualifiersValues->at ))

  • Reported: OCL 2.0b2 — Thu, 10 Jun 2004 04:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

context Classifier (02)

  • Key: OCL25-195
  • Legacy Issue Number: 7500
  • Status: open  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    def: allReceptions() : Set(Reception) =
    self.allFeatures->select(f | f.oclIsKindOf(Reception))
    ==> should be:
    context Classifier
    def: allReceptions() : Set(UML14::CommonBehavior::Reception) =
    self.feature->select(f |
    f.oclIsKindOf(UML14::CommonBehavior::Reception))->collect(
    f | f.asReception() )
    where asReception() is defined as operation to Feature:
    + asReception() : Reception

  • Reported: OCL 2.0b2 — Thu, 10 Jun 2004 04:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

Allow defining default values for parameters in operations

  • Key: OCL25-189
  • Legacy Issue Number: 6892
  • Status: open  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    Allow defining default values for parameters in operations

  • Reported: OCL 2.0b2 — Wed, 7 Jan 2004 05:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

OclUndefined / allInstances() clarification.

  • Key: OCL25-190
  • Legacy Issue Number: 6609
  • Status: open  
  • Source: Modeling Value Group ( Wim Bast)
  • Summary:

    think the operation allInstances() is under-specified in the current version of the OCL 2.0 specification.

    It does not seem to be clear whether OclUndefined is included in the returned set or not:

    According to the 1.5 specification of allInstances(), the instances of all subtypes are included. OclVoid is a subtype of all other types, thus OclUndefined would be a part of the set.

    I assume this is not the intended behaviour. For example, the "all names must be different" expression example would always yield OclUndefined or false, but never true.

  • Reported: OCL 2.0b2 — Thu, 13 Nov 2003 05:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

Template return types in operation signatures

  • Key: OCL25-196
  • Legacy Issue Number: 6533
  • Status: open  
  • Source: Anonymous
  • Summary:

    Description: At some places, template parameter T appears in operation signatures, e.g., oclAsType(typename:OclType) : T (e.g., Sect. 6.2.1). At other places, this is denoted by "instance of OclType" or <<the return type of the invoked operation>>. It would be more meaningful when these informal return type descriptions are replaced by "OclAny". An additional constraint about the actual return type should be given when necessary.

  • Reported: OCL 2.0b2 — Mon, 10 Nov 2003 05:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

OCL 2: what is a collection?

  • Key: OCL25-191
  • Legacy Issue Number: 5973
  • Status: open  
  • Source: HL7 ( Grahame Grieve)
  • Summary:

    OCL 2 doesn't really define what a collection is. In essence,
    a particular UML construct is arbitrarily designated as
    the OCL collection, and a series of properties are assigned
    to it

    This question arises in 2 different ways:

    • can you sub-class one of the concrete descendents in
      a UML diagram - by referring to the OCL package - and thereby
      add functionality to your own collection types
    • are all parameterised classifiers collections? if you
      define a parameterised class, how does an OCL user or
      environment know whether it's a collection or not?

    perhaps a stereotype should be intrroduced to allow for
    unambiguous resolution of these issues

  • Reported: OCL 2.0b1 — Tue, 22 Apr 2003 04:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

OCL 2.1 12 Definition Accessibility Semantics

  • Key: OCL25-194
  • Legacy Issue Number: 14591
  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    Given the following:

    context MyClass
    def : isaMethod() : Boolean =
    let Collection(Operation) myOperations = oclType().oclAsType(Class).ownedOperations()
    in myOperations->exists(name = 'isaMethod')

    is the value of isaMethod() true or false?

    This is a more fundamental way of looking at the AST serializability problem in Issue 12854. (The suggested referredDefinition : Constraint [0..1] will not work because there may be 3 operation constraints and two property constraints.)

    isaMethod() = false: OCL defininitions are not first class features and so there is no need to support their serialization.

    isaMethod() = true: OCL definitions do as implied by Section 12.5 and provide reusable sub-expressions that can be used in an identical way to an atribute or operation.

    It seems that an OCL evaluation needs to be defined in the following way.

    Phase 1. Load MOF/UML meta-models and OCL contributions
    Phase 2: Merge OCL definitions into MOF/UML meta-models
    Phase 3: Execute the OCL to support queries/invariants/... on models

    Phase 2 solves 12854 by requiring a merged meta-model to reify all definitions.

    How the merged model is serialized is an implementation issue

  • Reported: OCL 2.1 — Sat, 31 Oct 2009 04:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

Japan PAS Ballot Comment 20 Section 9.3.29 OperationCallExpCS

  • Key: OCL25-193
  • Legacy Issue Number: 16143
  • Status: open  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Synthesized attributes, [D], [F], [G] The meaning of “and” at the end of the line is not clear and seems inconsistent with other parts. Are these logical operations? Add text to clarify this

  • Reported: OCL 2.1 — Wed, 20 Apr 2011 04:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

Collection{} is Collection(OclVoid){}

  • Key: OCL25-192
  • Legacy Issue Number: 19612
  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    Issue 12953 considered the problem of the element type of an empty collection and rejected OclVoid (Option 1) because Set{}->including(1) would fail.

    This rejection is appropriate when the collection is modified as in Java, but is inappropriate for OCL where a new Collection is created. There is therefore no problem in deciding that the most derived common element type of Set{} (OclVoid) and 1 (Integer) is Integer causing Set(Integer)::including(Integer) to be invoked.

  • Reported: OCL 2.1 — Mon, 22 Sep 2014 04:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

elements in the result value

  • Key: OCL25-185
  • Legacy Issue Number: 7543
  • Status: open  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    35. – [4] The elements in the result value are the elements in the
    – literal parts, taking into account that a collection range can result
    – elements.
    context CollectionLiteralExpEval inv:
    let allElements : Bag(Value) = parts->collect(
    Sequence

    {1..allElements->size()}->forAll( i:
    resultValue.elements->at.name = ’’ and
    resultValue.elements->at.value = allElements->
    self.kind = CollectionKind::Sequence implies
    resultValue.elements->at.indexNr = i )
    ==> should be
    context CollectionLiteralExpEval inv:
    let allElements : Sequence(Value) = parts->collect(
    in
    Sequence{1..allElements->size()}

    ->forAll( i:
    resultValue->oclAsType(OCLDomain::Values::CollectionValue).
    >any(x | x.indexNr = i).value
    = allElements->at and
    self.kind = CollectionKind::Sequence implies
    resultValue.elements->at.indexNr = i )

  • Reported: OCL 2.0b2 — Thu, 10 Jun 2004 04:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

result value of an if expression

  • Key: OCL25-184
  • Legacy Issue Number: 7542
  • Status: open  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    34. – [1] The result value of an if expression is the result of the thenExpression
    – if the condition is true, else it is the result of the elseExpression.
    context IfExpEval inv:
    resultValue = if condition then thenExpression.resultValue else
    elseExpression.resultValue
    endif
    ==> ’condition’ should be ’condition.resultValue->oclAsType(Boolean) = true’

  • Reported: OCL 2.0b2 — Thu, 10 Jun 2004 04:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

value of a collection item

  • Key: OCL25-186
  • Legacy Issue Number: 7538
  • Status: open  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    30. – [1] The value of a collection item is the result value of its item expression.
    – The environment of this item expression is equal to the environment of the
    – collection item evaluation.
    context CollectionItemEval
    inv: element = item.resultValue
    inv: item.environment = self.environment
    ==> an association should be added between CollectionLiteralPartEval and EvalEnvironment

  • Reported: OCL 2.0b2 — Thu, 10 Jun 2004 04:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

result value of an association end call expression

  • Key: OCL25-187
  • Legacy Issue Number: 7535
  • Status: open  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    27. – [1] The result value of an association end call expression is the value bound
    – to the name of the association end to which it refers. Note that the
    – determination of the result value when qualifiers are present is specified in – section 5.4.3 ("Well-formedness rules for the AS-Domain-Mapping.exp-eval
    – Package").
    context AssociationEndCallExpEval inv:
    qualifiers->size() = 0 implies
    resultValue =
    source.resultValue.getCurrentValueOf(referredAssociationEnd.name)
    ==> ’name’ should be ’value’

  • Reported: OCL 2.0b2 — Thu, 10 Jun 2004 04:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

Section: 10.2.3 ObjectValue

  • Key: OCL25-180
  • Legacy Issue Number: 8646
  • Status: open  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    [1] still uses the term "UndefinedValue" when I think it should be "OclVoidValue" to agree with fig. 15 and name of term being defined previously. Typo - delete the lase "endif" that is flush with the margin.

  • Reported: OCL 2.0b2 — Mon, 28 Mar 2005 05:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

Section: 9.1

  • Key: OCL25-181
  • Legacy Issue Number: 8639
  • Status: open  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    In fig. 13, the operations lookupLocal() and Lookup() appear twice with the same name. Is this proper? Grammer - Delete the words "for" and "as" in the last line on page 62. Bulletted paragraph beginning "If neither of the above..." implies only two choices so remove third bullet at top of page 63 and move line out flush with margin of bullet beginning "If not, check self..."

  • Reported: OCL 2.0b2 — Mon, 28 Mar 2005 05:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

Section: 8.3.8

  • Key: OCL25-182
  • Legacy Issue Number: 8638
  • Status: open  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    The def:lookupAssociationClass(name: String) has the same phrase after the arrow as the def:;ppli[AssociationEnd(name: String). I'm not familiar with OCL but this doesn't seem right to me. The context Operation and the context Signal each contain two equal sign separated only by a comment. I don't think this is correct either.

  • Reported: OCL 2.0b2 — Mon, 28 Mar 2005 05:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

Section: 8.3.1

  • Key: OCL25-183
  • Legacy Issue Number: 8637
  • Status: open  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    The association parentOperation nor the class OperationCallExp of OCLExpression is not shown in either fig. 6 or 9 but in fig. 7. Change the reference to fig. 7 page 44 in the association definition for parentOperation under OclExpression. Two additional associations vor VariableDeclaration are shown in fig. 6--baseExp:IterateExp and loopExpr:LoopExp. Add these to the notation or delete these associations from fig. 6.

  • Reported: OCL 2.0b2 — Fri, 25 Mar 2005 05:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

OCL 2.1 Loop iterators are not ordered and other inconsistencies

  • Key: OCL25-168
  • Legacy Issue Number: 14639
  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    The iterators of LoopExp and LoopExpEval are not ordered, but the well-formedness constraints on them use ->at() which is only available for ordered collection. Usage of the AST property is subject to a variety of spelling, ordering and multiplicity inconsistencies.
    Section 7.6.3 and 7.6.4 define extended variants of forAll and exists that have two iterators.

    Figure 8.2 and Figure 13.3 show an unordered * multiplicity for LoopExp.iterator. The positioning of the VariableExp.referredVariable 0..1 multiplicity makes the diagram easy to mis-read.

    Section 8.3.1 LoopExp defines iterator as "The iterator variables. These variables are, each in its turn, " implying an ordered collection.

    Section 8.3.7 LoopExp [2] and [3] use iterator->forAll implying a collection.

    Section 9.3 IteratorExpCS synthesized attributes use iterators->at(1) and at(2) requiring an ordered collection.

    Section 9.3 IterateExpCS concrete syntax supports at most one iterator and one accumulator.

    Section 9.3 IterateExpCS synthesized attributes use iterator.initExpression requiring a non-collection.

    Figure 10.7 shows LoopExpEval.iterators as unordered 1..n.

    Section 10.3.1 LoopExpEval defines iterators as "The names of the iterator variables".

    Section 10.3.7 IterateExpEval [1] uses iterators->at(1) and iterators->at(2) implying an ordered collection with upper bound 2.

    Section 10.3.7 LoopExpEval [1] has a two way if = 1 else, implying the upper bound is 2.

    Section 10.3.7 LoopExpEval [3] uses iterators->at(1) and iterators->at(2) implying an ordered collection with upper bound 2.

    Section 11.9.1 defines the mapping of forAll to iterate for multiple iterators, but IterateExpCS only supports a single iterator.

    The above suggests that the specification should consistently treat iterators as having a 1..2

    {ordered}

    multiplicity.

  • Reported: OCL 2.1 — Sun, 15 Nov 2009 05:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

OCL 2.1 12 Documents

  • Key: OCL25-169
  • Legacy Issue Number: 14599
  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    12.2 defines a syntax for a standalone OCL document, but provides no mechanism to assist an implementation in locating packages or to partition into multiple reusable documents.

    a) Suggest addition of an ImportDeclarationCS

    ImportDeclarationCS ::= import StringLiteralExpCS

    where StringLiteralExpCS is a URI whose MOF/UML model content an implementation should make visible within the root environment.

    import is a new reserved word.

    b) Suggest addition of an IncludeDeclarationCS

    IncludeDeclarationCS ::= include StringLiteralExpCS

    where StringLiteralExpCS is a URI whose OCL document content an implementation should interpret (at most once) before proceeding.

    include is a new reserved word.

    c) Suggest addition of an OclDocumentCS

    OclDocumentCS ::= (ImportDeclarationCS)* (IncludeDeclarationCS | PackageDeclarationCS[A])*

    d) Suggest an OclPackage to own the Constraints for each Package and bypass the problem that Constriants do not have distinguishable names as required by Package content.

  • Reported: OCL 2.1 — Sat, 31 Oct 2009 04:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

OCL 2.1 12 Definition uses LetExp

  • Key: OCL25-170
  • Legacy Issue Number: 14594
  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    12.5 define a definition body as one or more LetExps. No example wraps the expression as a LetExp.
    Is this an obsolete specification or an unobserved AST structural constraint?

    12.5 defines synthesis of a variable or function, but fails to distinguish these from the equivalent property or operation

  • Reported: OCL 2.1 — Sat, 31 Oct 2009 04:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

OCL 2.0 Issue: References to Additional Attributes and Operations

  • Key: OCL25-171
  • Legacy Issue Number: 12854
  • Status: open  
  • Source: Zeligsoft, Inc. ( Christian Damus)
  • Summary:

    Re: OCL 2.0 formal/06-05-01

    The Abstract Syntax defines expressions that navigate properties and
    call operations of Classifiers: the PropertyCallExp and
    OperationCallExp, respectively. These work well for features of
    Classifiers that are defined by the UML model that is the subject of
    the OCL constraints.

    However, OCL also provides a mechanism for defining additional
    attributes and operations on behalf of a classifier: the definition
    constraint. As these definitions are extrinsic to the UML model,
    there are no Property and Operation elements for the respective
    expressions to reference. There are only Constraints with an
    «oclHelper» stereotype and a body expression. The very purpose of
    these definitions is to assist in the formulation of OCL constraints,
    so it is necessary that the abstract syntax be able to reference them.

    I can think of an obvious approach to resolution of this problem: add
    an association "referredDefinition : Constraint" with 0..1
    multiplicity to both of the existing PropertyCallExp and
    OperationCallExp metaclasses. The 0..1 multiplicity of the existing
    referredProperty and referredOperation associations, as shown in
    Figure 8.3, appears to be in error (as the rest of the text and, in
    particular, the well-formedness rules of Section 8.3.7, assumes the
    reference to the referred features) but is required by this solution.
    Additional well-formedness rules would stipulate, for each expression,
    that exactly one of the referred feature of referred definition
    associations have a value.

    This suggestion is not entirely satisfactory, as it breaks the
    uniformity of references to features in call expressions and encodes,
    in the abstract syntax, a dependency on a feature's being an
    additional definition. However, this problem is a practical concern
    for the serialization and exchange of the OCL Abstract Syntax, as the
    current metamodel is incomplete.

  • Reported: OCL 2.0 — Sun, 14 Sep 2008 04:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

Section: A.3.2.2 Syntax and Semantics of Postconditions (02)

  • Key: OCL25-172
  • Legacy Issue Number: 12494
  • Status: open  
  • Source: Net.Orange (i.e. Net Dot Orange) ( Garr Lystad)
  • Summary:

    In the paragraph before Definition A.32 you will find, "... ppre = (spre, ßpre) describing a system state and variable assignments before the execution ...." Originally I had taken the ß's to be sets of assignments. Then I noticed that the text before this point refers to it repeatedly as an "assignment" in the singular. Now, here, and also in the middle of page 205 (which says, "ß' := ß

    {p1/I[[ e1 ]](r), . . . , pn /I[[ en ]](r)}

    .") the indication is that beta is multiple of assignments. Consistency would be very desirable.

  • Reported: OCL 2.0 — Thu, 15 May 2008 04:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

OCL Collections applied to Properties

  • Key: OCL25-174
  • Legacy Issue Number: 10787
  • Status: open  
  • Source: Dell Technologies ( George Ericson)
  • Summary:

    OCL Specification, v2.0

    The specification does not make it clear how to apply collection operations to properties.

    For instance, assume

    class A

    { int x[]; }

    It appears that an invariant constraint that asserts that one of the entries in A.x must be 5 might be

    context A
    inv self.x->exists( p | p=5 )

    However, this is a guess and does not appear to be entirely justified by the text.

  • Reported: OCL 2.0 — Fri, 23 Feb 2007 05:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

Container of additional operations

  • Key: OCL25-175
  • Legacy Issue Number: 8808
  • Status: open  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    OCL allows defining additional operations which are conceptually treated as operations of the metaclasses. However, except for special cases where the "additional operation" is effectively defined in the original metamodel, these "additional operations" are extensions to the original metamodel. No indication in the specification is given on what extension mechanism is used. This makes the exchange of OCL specifications through XMI incomplete and ill-formed.

  • Reported: OCL 2.0b2 — Wed, 25 May 2005 04:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

Section: 11.9.2 sortedBy

  • Key: OCL25-173
  • Legacy Issue Number: 8665
  • Status: open  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    The restriction to sort the OrderedSet with the lowest value coming first is very restrictive. Sometimes it is beneficial to sort in reverse order. Think about a statement that would allow a > sort order.

  • Reported: OCL 2.0b2 — Wed, 30 Mar 2005 05:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

Section: 10.3.4 OclMessageArgEval

  • Key: OCL25-176
  • Legacy Issue Number: 8654
  • Status: open  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Fig. 23 shows an additional association of unspecified as the UnspecifiedValueExpEval that represents the unspecified evaluation. If this is supposed to represent the association variable, the description and the figure do not agree in any way.

  • Reported: OCL 2.0b2 — Tue, 29 Mar 2005 05:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

Section: 10.3.2 AssociationEndCallExpEval

  • Key: OCL25-177
  • Legacy Issue Number: 8650
  • Status: open  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    The association definition says that the referredAssociationEnd is the name of the AssociationEnd to which the corresponding NavigationCallExp is a reference. Shouldn't the be to which the corresponding AssociationEndCallExp is a reference?

  • Reported: OCL 2.0b2 — Mon, 28 Mar 2005 05:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

Section: 10.3

  • Key: OCL25-178
  • Legacy Issue Number: 8647
  • Status: open  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Fig. 20 does not diagram the class OclEvaluation. Should it?

  • Reported: OCL 2.0b2 — Mon, 28 Mar 2005 05:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

Section: 10.2.1 Element

  • Key: OCL25-179
  • Legacy Issue Number: 8643
  • Status: open  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    The statement "An element represents a single component of a tuple value" is not directly diagrammed in fig. 16. Should it be?

  • Reported: OCL 2.0b2 — Mon, 28 Mar 2005 05:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

OCL 2.1 Nested Collection Iteration

  • Key: OCL25-167
  • Legacy Issue Number: 14851
  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    The OCL specification does not make clear whether an iteration over a Collection of Collections should operate on the flattened or unflattened source.

    The Appendix through lack of specification and explicit specification of flattening would suggest that the iterator for a Collection of Collections is a Collection.

    Most of the description in Section 7.6 is neutral through use of the term element.

    However In 7.6.1 "The variable v is called the iterator. When the select is evaluated, v iterates over the collection and the boolean expression-with-v is evaluated for each v. The v is a reference to the object from the collection and can be used to refer to the objects themselves from the collection." implies that the source collection is flattened; at least in OCL 2.0 where collections were not first class objects, this is a contradiction. In OCL 2.1, collections are nearly first class objects and so perhaps there is just an ambiguity.

    Similarly:

    In 7.6.2 "When we want to specify a collection which is derived from some other collection, but which contains
    different objects from the original collection (i.e., it is not a sub-collection), we can use a collect operation."

    In 7.6.3 "The forAll operation in OCL allows specifying a Boolean expression, which must hold for all objects in a collection:"

    In 7.6.4 "The exists operation in OCL allows you to specify a Boolean expression that must hold for at least one object in a collection".

    Suggest that the specification of iteration avoid the use of 'object', sticking only to 'element'. A clarifying paragraph at the end of 7.6.5 should state that for a 0 or 1 deep Collection source, element is a non-Collection object. For an N-deep Collection source, element is an (N-1)-deep Collection.

  • Reported: OCL 2.1 — Thu, 10 Dec 2009 05:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

Vagueness about meaning of 0..1 multiplicity in OCL and UML

  • Key: OCL25-158
  • Legacy Issue Number: 15789
  • Status: open  
  • Source: Model Driven Solutions ( Steve Cook)
  • Summary:

    UML-alignment of OCL type signatures
    --------------------------------------------------------

    Following discussion in the "Vagueness about meaning of 0..1 multiplicity in OCL and UML" threads
    of the UML2 and OCL RTFs the following problems exist in alignment of the UML and OCL type systems.

    The OCL specification does not provide a clear description of the comparative semantics of for instance
    Integer[1] and Integer[0..1].

    The Complete OCL syntax for an Operation Context Declaration uses OCL type decalarations and so
    fails to provide the same expressivity as a UML operation declaration with multiplicities.

    Suggest:

    a) a clear indication that

    An Integer[1] may have integer values, null or invalid, of which only integer values are well-formed.

    An Integer[0..1] may have integer values, null or invalid, of which integer values and null are well-formed.

    b) an enhancement to the type declaration syntax to allow

    Integer[0..1] or Integer[1] to indicate a nullable/non-nullable value.

    Set(Integer[1..7]) to capture the expressivity of a UML multiplicity

  • Reported: OCL 2.1 — Thu, 28 Oct 2010 04:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

OCL 2.2 forAllAt suggestion

  • Key: OCL25-160
  • Legacy Issue Number: 15710
  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    It is common in an iteration to require in iteration index.

    This can be achieved rather expensively by indexOf, or less expensively by
    iterating over an integer literal range.

    It would be easier to define e.g.

    forAllAt(index : Integer, i : T)

    etc so that an implementation can supply the index efficiently.

  • Reported: OCL 2.1 — Fri, 8 Oct 2010 04:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

OCL Generics

  • Key: OCL25-159
  • Legacy Issue Number: 15425
  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    UML supports generics/templates. OCL doesn't. This is a UML alignment failure.

  • Reported: OCL 2.1 — Sat, 21 Aug 2010 04:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

OCL 2.2 Generalisation of Issue 7341 PathNames

  • Key: OCL25-161
  • Legacy Issue Number: 15234
  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    Issue 7341 changed a number of syntaxes to permit a PathNameCS rather than a SimpleNameCS,
    so that scope ambiguities could be resolved.

    It is not clear why this was applied uniformly to all syntaxes where a name reference is in use. As a minimum
    it just gives the user the discretion to clarify a subtle statement, and it avoids the impression that pathed-names
    are special. It also avoids the need for some very similar concrete syntax expositions.

    More specifically in an AssociationClassCallExpCS it would allow disambiguation of Left::Link and Right::Link as
    alternate AssociationClasses.

    Suggest allow PathNameCS in all places where there is not a specific requirement for a SimpleNameCS.

  • Reported: OCL 2.1 — Thu, 29 Apr 2010 04:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

OCL 2.2 Correction to Issue 9796 for isPre

  • Key: OCL25-163
  • Legacy Issue Number: 15232
  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    Issue 9796 responded to the problem with the undefined (and undefinable) withAtPre().

    However the textual replacement of ".withAtPre()" by ".isPre = true" is not valid.

    For instance

    [D] AttributeCallExpCS.ast.source = if isMarkedPreCS->isEmpty()
    then OclExpressionCS.ast
    else OclExpressionCS.ast.withAtPre() endif

    should be elaborated to:

    [D] AttributeCallExpCS.ast.source = OclExpressionCS.ast
    [D] AttributeCallExpCS.ast.isPre = isMarkedPreCS->notEmpty()

  • Reported: OCL 2.1 — Thu, 29 Apr 2010 04:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

OCL 2.2 7.5.4 Property-qualified association navigation has no concrete or abstract syntax

  • Key: OCL25-162
  • Legacy Issue Number: 15220
  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    Section 7.5.4 describes an association navigation qualification to
    accommodate
    recursive associations.

    e.g. self.employeeRanking[bosses]

    in which "bosses" is a Property role name.

    OCL 2.2 has no concrete syntax for this. Superficially it resembles an
    AssociationClassCallExp, but that requires OclExpression values for its
    qualifiers.

    Prior to OCL 2.0 (and still present in many obstinate residual artefacts in
    OCL 2.2),
    there was an AssociationEndCallExp, whose syntax was identical to an
    AssociationClassCallExp
    and so it was removed and merged with AttributeCallExp as PropertyCallExp.

    It would appear that a form of AssociationEndCallExp is required with
    syntaxes

    OclExpressionCS '.' pathNameCS[1] ('[' pathNameCS[2] ']')? isMarkedPreCS?
    pathNameCS[1] ('[' pathNameCS[2] ']')? isMarkedPreCS?

    in which pathNameCS[2] defines the NavigationCallExpCS.ast.navigationSource
    that is currently completely undefined and very confusingly described in
    Section 8.3.2:

    "navigationSource The source denotes the association end Property at the end
    of the object itself. This is used to
    resolve ambiguities when the same Classifier is at more than one end (plays
    more than one
    role) in the same association. In other cases it can be derived."

    Suggest:

    Remove NavigationCallExp::navigationSource that currently has no semantics

    Introduce QualifiedPropertyCallExp (and etc.) as a further NavigationCallExp
    to support
    the qualified navigation. It has two associations:

    referredSourceProperty: Property (e.g. "bosses")
    referredTargetProperty: Property (e.g. "employeeRanking").

  • Reported: OCL 2.1 — Thu, 22 Apr 2010 04:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

OCL 2.1 Parametric references

  • Key: OCL25-164
  • Legacy Issue Number: 15156
  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    OCL supports access to a variety of properties such as self.a, self.b, self.c but provides no mechanism for indirection of the property selection.

    Perhaps that the standard library support reflection more effectively with:

    self.oclGet(MyClass::a)

  • Reported: OCL 2.1 — Tue, 30 Mar 2010 04:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

OCL 2.1 conformsTo definition suggestion

  • Key: OCL25-165
  • Legacy Issue Number: 15092
  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    OCL allows a user to define a run-time OCL meta-model through Property and Operation definitions that is based upon a specification-time UML meta-model.

    It would be useful to allow a user to also introduce inheritance/conformance polymorphisms.

    Thus:

    context CommonPackage::CommonObject

    context CommonPackage::CommonObject::isSerializable() : Boolean = false

    context OCL::String conformsTo CommonPackage::CommonObject

    context MyPackage::MyObject conformsTo CommonPackage::CommonObject

    context YourPackage::YourObject conformsTo CommonPackage::CommonObject

    could mix-in the capabilities of CommonObject to each of MyObject and YourObject and String.

    This would allow common functionality to be mixed in once and used polymorphically rather than being added in amorphously and requiring an if-tree of per-context invocations of that functionality.

  • Reported: OCL 2.1 — Fri, 26 Feb 2010 05:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

wrong parameter type for addNamespace operation call

  • Key: OCL25-166
  • Legacy Issue Number: 14884
  • Status: open  
  • Source: Universidad Nacional del Litoral ( Javier Godoy)
  • Summary:

    (subclause [4])
    It reads: let firstNamespace : ModelElement ... in ...
    self.nestedEnvironment().addNamespace(firstNamespace)
    It should read:
    self.nestedEnvironment().addNamespace(firstNamespace.oclAsType(Namespace))
    Rationale: the signature of addNamespace is (ns: Namespace) as defined in 9.4.1 subclause [7]

  • Reported: OCL 2.1 — Sat, 19 Dec 2009 05:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

OCL 2.3 Pathname syntax does not allow access to hidden names

  • Key: OCL25-157
  • Legacy Issue Number: 16044
  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    If meta-models provide both 'B::x' and 'A::B::x', it is not possible to access 'B::x' from a context with 'A::B' since 9.4.1[4] searches from the current scope and so resolve 'B' in 'B::x' to 'A::B'.

    Suggest adoption of the C++ '::' global prefix so that '::B::x' can be used when 'A::B' occludes.

  • Reported: OCL 2.1 — Sun, 27 Feb 2011 05:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

Incomplete and missing well-formedness rules

  • Key: OCL25-147
  • Legacy Issue Number: 6547
  • Status: open  
  • Source: Anonymous
  • Summary:

    Author: Sten Loecher (Sten.Loecher@inf.tu-dresden.de)
    Description: OCL specification contains incomplete/ missing well-formedness rules
    Rationale:
    The following list contains the concerned classes of the OCL metamodel and provides information about the required changes to the OCL specification.
    AssociationClassCallExp: missing rule to describe the type
    AssociationEndCallExp: missing rule to describe the type
    AttributeCallExp: multiplicity, order, and unambiguousness must be
    considered
    CollectionLiteralExp: OrderedSetType must be added
    IteratorExp: well-formedness rules needed for iterator operations one, any,
    collectNested, and sortedBy
    OclMessageExp: missing rule to describe the type
    OclExpressionWithTypeArgExp: missing rule to describe the type
    OperationCallExp: missing rule to describe the type

  • Reported: OCL 2.0b2 — Tue, 11 Nov 2003 05:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

Lack of operation specifications

  • Key: OCL25-148
  • Legacy Issue Number: 6535
  • Status: open  
  • Source: Anonymous
  • Summary:

    Author: Stephan Flake (flake@c-lab.de)
    Description: Some operation specifications are still missing (they are marked by --TBD), e.g., oclAsType(). For this operation, a proposed specification is as follows (provided that OclType is a powertype):

    1: context OclAny::oclAsType(typename:OclType) : OclAny
    2: post: if OclType.allInstances()
    3: ->select(t:OclType | self.oclIsTypeOf(t))
    4: ->exists(t:OclType | typename.conformsTo(t) or t.conformsTo(typename)) then
    5: result = self and result.oclIsTypeOf(typename)
    6: else
    7: result = OclUndefined and result.oclIsTypeOf(OclVoid)
    8: endif

    For a comparison, a complex OCL specification for ENUMERATION TYPE OclType can be found in the paper "OclType - A Type or Metatype?".

  • Reported: OCL 2.0b2 — Mon, 10 Nov 2003 05:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

Up- and Down-casts with oclAsType().

  • Key: OCL25-149
  • Legacy Issue Number: 6534
  • Status: open  
  • Source: Anonymous
  • Summary:

    Description: This is not treated consistently throughout the document. As the formal semantics already allows both up- and downcasts, this should also be allowed in Sect. 2.4.6.

  • Reported: OCL 2.0b2 — Mon, 10 Nov 2003 05:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

Provide access to the sender of a message

  • Key: OCL25-150
  • Legacy Issue Number: 6528
  • Status: open  
  • Source: Ecole Polytechnique Federale de Lausanne ( Alfred Strohmeier)
  • Summary:

    Consider the operation:
    Account::withdraw (amount: Money)
    Suppose a Person object sends the operation, and we want to state that the person has to be the owner of the account. Access to the sender of the message is needed. One might for instance imagine that the concrete syntax defines a keyword sender, and we could then write:
    context: Account::withdraw (amount: Money)
    pre: sender = self.owner

  • Reported: OCL 2.0b2 — Mon, 10 Nov 2003 05:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

OCL 2: OrderedSet

  • Key: OCL25-151
  • Legacy Issue Number: 5971
  • Status: open  
  • Source: HL7 ( Grahame Grieve)
  • Summary:

    OrderedSet isn't discussed in the section on semantics

  • Reported: OCL 2.0b1 — Tue, 22 Apr 2003 04:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

Japan PAS Ballot Comment 21 (ocl2-rtf) Section 9.3.37 OclMessageExpCS

  • Key: OCL25-155
  • Legacy Issue Number: 16144
  • Status: open  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Synthesized attributes, [B] TBD should not be a part of International Standard. Modify the text as appropriate

  • Reported: OCL 2.1 — Wed, 20 Apr 2011 04:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

Issue nnnn: Japan PAS Ballot Comment 12 (ocl2-rtf) Section 8.3.1 Fig 8.2 & FeatureCallExp in p43

  • Key: OCL25-156
  • Legacy Issue Number: 16135
  • Status: open  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    There is no attribute designation of FeatureCallExp in Fig 8.2. However, in Attribute of FeatureCallExp class description (p43), isPre is described. Add isPre to Class “FeatureCallExp” on the class diagram (Fig. 8.2)

  • Reported: OCL 2.1 — Wed, 20 Apr 2011 04:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

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

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

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

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

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

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

Missing Real::= overload

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

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

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

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

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

Introduce a Safe Navigation Operator

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

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

    In OCL it could be a pure syntax sugar:

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

    or perhaps an additional PropertyCallExp operator

  • Reported: OCL 2.3.1 — Fri, 1 Mar 2013 05:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

Section: 8.3.4

  • Key: OCL25-138
  • Legacy Issue Number: 8635
  • Status: open  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Association arguments under OclMessageExp uses "SignalArgs" as the classifier name but fig. 9 and later in this section the name is given as OclMessageArg. Change SignalArgs to OclMessageArgs. In the notation for OclMessageArg, it is stated that "OclMessageArg has either a specified or an unspecified value." Would these then be attributes to OclMessageArg? UnspecifiedValueExp shows an association of type:Classifier in fig. 9. Add this to the notation or delete the association from the fig.

  • Reported: OCL 2.0b2 — Fri, 25 Mar 2005 05:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

Section: 8.2

  • Key: OCL25-139
  • Legacy Issue Number: 8628
  • Status: open  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Typos - 1st line, 3rd para under The Types Package, delete "and" between "CollectionType" and "its." - 2nd sent., 3rd para under The Types Package, change "taken in account" to "taken into account." - 2nd sent., under OclMessageType, change "Like to the collection" to "Like collection." - Last sent. under TupleType, delete the word "to." In sub-section CollectionType, there is no mention of the fourth concrete subclass which is shown in fig. 5 as OrderedSetType. Add this to the list of concrete subclasses or change fig. 5 to indicate that OrderedSetType is not a subclass of CollectionType (possibly a subclass of SetType?). Sub-section 7.5.11 also indicates only three different collection types. In addition, CollectionTypes [1] on pg 36 ("--all instances of SetType, SequenceType, BagType conform to a CollectionType if the elementTypes conform") makes no mention of OrderedSetType.

  • Reported: OCL 2.0b2 — Thu, 24 Mar 2005 05:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

result value of an association end call expression

  • Key: OCL25-140
  • Legacy Issue Number: 7533
  • Status: open  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    25. – [1] The result value of an association end call expression is the value bound
    – to the name of the association end to which it refers. Note that the
    – determination of the result value when qualifiers are present is specified in
    – section 5.4.3 ("Well-formedness rules for the AS-Domain-Mapping.exp-eval
    – Package").
    context AssociationEndCallExpEval inv:
    qualifiers->size = 0 implies
    resultValue =
    source.resultValue.getCurrentValueOf(referredAssociationEnd.name)
    ==> ’size’ should be ’size()’
    ==> ’resultValue’ should be ’resultValue->oclAsType(OCLDomain::Values::ObjectValue)’

  • Reported: OCL 2.0b2 — Thu, 10 Jun 2004 04:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

parameters of the referredOperation

  • Key: OCL25-141
  • Legacy Issue Number: 7505
  • Status: open  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    37. – [2] The parameters of the referredOperation become attributes of the instance
    – of OclMessageType context OclMessageType
    inv: referredOperation->size() = 1 implies
    self.feature = referredOperation.Parameter->collect(p |
    p.asAttribute().oclAsType(Feature) ).asOrderedSet()
    ==> should be:
    context OclMessageType
    inv: referredOperation->size() = 1 implies
    self.feature = referredOperation.Parameter->collect(p | p.asAttribute()
    ).asOrderedSet()

  • Reported: OCL 2.0b2 — Thu, 10 Jun 2004 04:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

Add an import statement to OCL files (with package - endpackage block)

  • Key: OCL25-142
  • Legacy Issue Number: 7455
  • Status: open  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    1. Add an import statement to OCL files (with package - endpackage block). At the moment one can
    only reference a type from another package using its complete path name. It would be more convenient
    to be able to import a package or other model element in the OCL files and use the simple name
    of a type in the OCL expressions.

  • Reported: OCL 2.0b2 — Thu, 10 Jun 2004 04:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

The notation when nesting "if then else" is too verbose

  • Key: OCL25-143
  • Legacy Issue Number: 6883
  • Status: open  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    Suggestion: Define a "switch" collection function, with a sepecific notation, as in:
    mylist->switch( iterator | cond1 ? exp1, cond2 ? exp2, …, else ? expN)
    The expressions cond2 is not evaluated if cond1 returns true and so on.

  • Reported: OCL 2.0b2 — Wed, 7 Jan 2004 05:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

Issue: Parsing Tuple Types and Collection Types as Arguments

  • Key: OCL25-144
  • Legacy Issue Number: 6572
  • Status: open  
  • Source: Anonymous
  • Summary:

    Description: One issue we have discovered is about expressions of the form: expr.oclAsTypeOf( Type ) The OCL standard does not support Type as a collection or tuple type.
    Rationale: We think that the syntax should be extended to support collection and tuple types. This will make the language more symmetric and increase the expressiveness of the language.

  • Reported: OCL 2.0b2 — Tue, 11 Nov 2003 05:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

Issue: Comments

  • Key: OCL25-145
  • Legacy Issue Number: 6563
  • Status: open  
  • Source: Anonymous
  • Summary:

    Description: OCL 2.0 comments start with –
    Rationale: This means that an expression like --4 cannot be interpreted as an arithmetic expression without inserting at least one space between the first - and the second -. I think that this problem can be resolved if the OCL comments start with // instead of --.

  • Reported: OCL 2.0b2 — Tue, 11 Nov 2003 05:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

Satisfaction of Operation Specifications (2)

  • Key: OCL25-146
  • Legacy Issue Number: 6549
  • Status: open  
  • Source: Anonymous
  • Summary:

    Author: Achim D. Brucker (brucker@inf.ethz.ch),
    Burkhart Wolff (wolff@informatik.uni-freiburg.de)
    Description: Change Definition A.34 to allow the precondition to be weakened
    Rationale:
    It is commonly accepted that a program S satisfying an operation specification may weaken the precondition. This corresponds to Bertrand Meyer's view of software specifications as contracts between clients of a program and program provider. This is in accordance with the explanation following Def. A.34: "In other words, the program S accepts each environment satisfying the precondition as input and produces an environment that satisfies the postcondition." This sentence admits the possibility that S may be defined for environments not satisfying the precondition.
    However Def. A.34 requires S to be defined exactly on the environments for which the precondition holds. Therefore, we propose to replace Def. A.34 by:
    DEFINITION A.34 (SATISFACTION OF OPERATION SPECIFICATIONS)
    An operation specification with pre- and postconditions is satisfied by a specification S if the restriction of S to the domain of R (denoted S|_dom(R)) is included in R, i.e. S|_dom(R) \subseteq R.
    This is equivalent to: \forall x, y. x:dom(R) & (x,y):S --> (x,y):R.
    In particular, S may be a program, i.e. a computation function in the sense of total correctness.

  • Reported: OCL 2.0b2 — Tue, 11 Nov 2003 05:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

Section: 10.3.4 OclMessageExpEval

  • Key: OCL25-136
  • Legacy Issue Number: 8655
  • Status: open  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Fig. 23 shows an attribute for OclMessageExpEval and that the association arguments is ordered. Neither of these are mentioned in the text

  • Reported: OCL 2.0b2 — Tue, 29 Mar 2005 05:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

Section: 10.3.2 NavigationCallExpEval

  • Key: OCL25-137
  • Legacy Issue Number: 8652
  • Status: open  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Add the association "qualifiers" to OclExpEval as is shown in fig. 21

  • Reported: OCL 2.0b2 — Mon, 28 Mar 2005 05:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

OCL 2.1 12 Incompleteness

  • Key: OCL25-129
  • Legacy Issue Number: 14598
  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    12.5.1[3], 12.6.1[2], 12.7.1[2], 12.8.1[2] are TBD.

  • Reported: OCL 2.1 — Sat, 31 Oct 2009 04:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

OCL 2.1 12 Essential MOF support

  • Key: OCL25-128
  • Legacy Issue Number: 14596
  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    12: Why no applicability to Essential MOF models?

    Although EMOF::Operation has no precondition feature, there is no problem in an operationContextDecl imposing a truth upon the operation.

    Similarly, if Initial value and Derived values are defined as Constraints in the same way as PreConditions, then the propertyContextDecl can constrain EMOF by imposing a truth upon the Property.default : String even though String is not an Expression

  • Reported: OCL 2.1 — Sat, 31 Oct 2009 04:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

Set operations for OrderedSet

  • Key: OCL25-130
  • Legacy Issue Number: 14225
  • Status: open  
  • Source: Individual ( Alexander Igdalov)
  • Summary:

    MDT OCL implementation has assumed that OrderedSet is a subtype of Set. It has become clear (11.6.3) that this assumption was erroneous. As a result, operations which are defined on Sets in the standard library (like including, excluding, intersection, union, etc.) must be undefined on OrderedSet. However, many clients (including the ones of Operational QVT) have already written code relying on this behaviour (i.e. considering that OrderedSet is a subtype of Set, they used operations like including()). It would be very helpful to define such operations on OrderedSet. It would be also important to define these counterpart operations so that they would keep the order of the elements of the initial OrderedSet, e.g:

    including(object : T) : OrderedSet(T)

    The OrderedSet containing all elements of self plus object added as the last element.

    post: result = self.append(object)

  • Reported: OCL 2.1 — Thu, 27 Aug 2009 04:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

Errors in examples

  • Key: OCL25-132
  • Legacy Issue Number: 12456
  • Status: open  
  • Source: Anonymous
  • Summary:

    The examples are based on the sample model (Companies and Employees). However, as pointed out in http://www.empowertec.de/products/analyze-spec-expressions.htm there are many errors in the examples. You will find at the address http://cs.ulb.ac.be/oclnotes.pdf the slides that I use in my course in which I slighty modified the example so that all example expressions are (supposed to be) correct.

  • Reported: OCL 2.0 — Wed, 14 May 2008 04:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

Recursivity is not explicitly addressed with examples

  • Key: OCL25-131
  • Legacy Issue Number: 12452
  • Status: open  
  • Source: Anonymous
  • Summary:

    Recursivity is not explicitly addressed with examples, although it is mentioned in several places. For example, in p. 16 it is said "The right-hand-side of this definition may refer to the operation being defined (i.e., the definition may be recursive) as long as the recursion is not infinite." I my course I have put the following example (slide 19) A method that obtains the direct and indirect descendants of a person context Person::descendants(): Set body: result = self.children->union( self.children->collect(c | c.descendants()) ) But there is no way to verify whether the above definition, although conceptually correct, is OK with respect to OCL's syntax. Similarly, the same problem arises with recursive association classes, which is covered in Section 7.5.4. I have covered this in my course in slides 29-30 A person is currently married to at most one person context Person inv: self.marriage[wife]>select(m | m.ended = false)>size()=1 and self.marriage[husband]>select(m | m.ended = false)>size()=1 Operation that selects the current spouse of a person context Person::currentSpouse() : Person pre: self.isMarried = true body: if gender = Gender::male self.marriage[wife]>select(m | m.ended = false).wife else self.marriage[husband]>select(m | m.ended = false).husband end However, I suppose that the syntax for the operation currentSpouse is OK with respect to OCL's syntax, although it is not specified explicitly.

  • Reported: OCL 2.0 — Wed, 14 May 2008 04:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

Naming of Constraints in OCL (02)

  • Key: OCL25-133
  • Legacy Issue Number: 10786
  • Status: open  
  • Source: Dell Technologies ( George Ericson)
  • Summary:

    OCL Specification, v2.0

    Section "7.3.3. Invariants" provides a means to name an invariant as in:

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

    The document does not seem to define this capability formally and I would like to see it also applied to pre, post, body, init, and derived constraints.

  • Reported: OCL 2.0 — Fri, 23 Feb 2007 05:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

Recommendations re ptc/2005-06-06

  • Key: OCL25-134
  • Legacy Issue Number: 10439
  • Status: open  
  • Source: NIST ( Peter Denno)
  • Summary:

    Recommendation: The specification would be better were it to additionally
    describe a practical grammar useful to tool implementors and persons trying
    to understand what constitutes legal OCL syntax. Of course, we all know that
    even practical OCL grammars are permissive of strings that aren't meaningful
    (for example, 7->isEmpty() is typically legal) but more can be done than is
    expressed by the current description. I am not suggesting that you replace
    the current method of description, but that you add (perhaps only as an
    informative, non-normative appendix) a conventional grammar. The spec, after
    all, is supposed to serve the purposes of implementors.

    There are published papers describing practical grammars for OCL, or I can
    supply you with one, if you'd like.

    PS By "practical grammar" I mean one that limits the look-ahead to a finite
    number wherever possible. It is, of course, the use of OclExpression in the
    RHS of so many productions that runs up against the infinite look-ahead
    problem, and makes the published grammar unusable by implementors.

  • Reported: OCL 2.0 — Thu, 2 Nov 2006 05:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

Section: 10.4

  • Key: OCL25-135
  • Legacy Issue Number: 8657
  • Status: open  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    There is no caption for the figure on pg. 122. Although fig. 27 appears on pg 121 with its caption and fig. 28 is on pg. 132, use of the word "figures" on pg. 120 indicates that the fig. on pg 122 is a separate figure. Please clarify with a caption for the fig. on pg 122.

  • Reported: OCL 2.0b2 — Tue, 29 Mar 2005 05:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

OCL 2.1 12 Missing specification of initial and derived value constraints

  • Key: OCL25-126
  • Legacy Issue Number: 15072
  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    Sections 12.5.1, 12.6.1, 12.7.1 specify the "invariant", "precondition", "postcondition" spellings.

    Sections 12.8, 12.9, 12.10, 12.11 do not specify their corresponding spellings.

    Suggest: "initial", "derivation", "body", "guard" as the conventional adjective used to qualify "constraint".

  • Reported: OCL 2.1 — Fri, 19 Feb 2010 05:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

OCL 2.1 11.7.3 OrderedSet addition well-formedness rules

  • Key: OCL25-127
  • Legacy Issue Number: 14980
  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    The OrderedSet well-formedness constraints in 11.7.3 appear to have been
    copied and pasted from Sequence. They need revision to consider the Set
    consequences of .

    Addition operations (includes, insertAt, union, append, prepend) have a
    post-condition that the size increases, which is clearly not the case if
    an additional element is equal to a pre-existing element.

    In the particular case of insertAt there is an ambiguity as to whether
    the insert index is the pre or post index. For instance when inserting 3
    at index 5 into OrderedSet

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

    the pre-index insertion
    yields OrderedSet

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

    whereas the post-index insertion yields
    OrderedSet

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

    . While the post-index insertion satisfies the
    'post: result->at(index) = object' constraint, it is presumably not the
    intent.

  • Reported: OCL 2.1 — Sun, 17 Jan 2010 05:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

OCL 2.2: AST is an ASG

  • Key: OCL25-123
  • Legacy Issue Number: 15387
  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    The AS is referred to in a number of places as an abstract syntax tree. This is a misnomer that causes confusion in some academic circles. The AS should always be referred to as a Graph.

  • Reported: OCL 2.1 — Thu, 29 Jul 2010 04:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

OCL 2.2 OclMessage types are not statically derivable

  • Key: OCL25-124
  • Legacy Issue Number: 15258
  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    The intro to Section 8.2 states:

    "OCL is a typed language. Each expression has a type that is either
    explicitly declared or can be statically derived."

    However OclMessage lacks type parameterisation and so the 7.7.2 example

    context Subject::hasChanged()
    post: let messages : Sequence(OclMessage) = observer^^update(? : Integer, ?
    : Integer) in
    messages->notEmpty() and
    messages->exists( m | m.i > 0 and m.j >= m.i )

    only works if the type analysis proceeds beyond "messages :
    Sequence(OclMessage)" to
    discover the initialiser with formal signature "Observer::update(i :
    Integer, j : Integer)".

    This will not in general be possible and so expressions such as "m.i > 0"
    cannot be
    statically checked, and cannot be dynamically expressed. Indeed since m is
    an OclMessage,
    "m.i" is not well-formed.

    Suggest that OclMessage is redefined as:

    OclMessage<OclOperation> or OclMessage<OclSignal>

    requiring the type to be determinate or discovered by oclAsType.

  • Reported: OCL 2.1 — Tue, 18 May 2010 04:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

Why OCL does not have "super" reference?

  • Key: OCL25-125
  • Legacy Issue Number: 15249
  • Status: open  
  • Source: NASA ( Maged Elaasar)
  • Summary:

    I hope someone can explain to me why OCL does not have a reference to "super" (similar to the existing reference to "self"). Wouldn't you want to sometimes call the redefined version of an operation from an OCL exrpression, similar to how you can do that in Java?

    From my limited knowledge of ALF (the action language), I understand it supports the "super" reference, so this tells me there is no semantic restriction there?

  • Reported: OCL 2.1 — Tue, 20 Apr 2010 04:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

Japan PAS Ballot Comment 32 (ocl2-rtf): 10.3.1 Definitions of Concepts for the Evaluations Package, figure 10.11

  • Key: OCL25-120
  • Legacy Issue Number: 16155
  • Status: open  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    TupleLiteralExpPartEval is not included in Figure 10.11. Is VariableDeclEval the one? Add this element to Figure 10.11.

  • Reported: OCL 2.1 — Wed, 20 Apr 2011 04:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

Japan PAS Ballot Comment 22 (ocl2-rtf) .4.2 NamedElement 9.4.3 Namespace, 11.2.5(p.135), 12.8.1(p.173)

  • Key: OCL25-121
  • Legacy Issue Number: 16145
  • Status: open  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Main text. TBD should not be a part of International Standard. Modify the text as appropriate.

  • Reported: OCL 2.1 — Wed, 20 Apr 2011 04:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

OCL 2.3 Introduce a reserved OclSelf template parameter

  • Key: OCL25-122
  • Legacy Issue Number: 16019
  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    Three library operations do not appear to be declarable without intuitive typing semantics.

    Introduction of an OclSelf template parameter that is the statically determined type of self can solve the problem. OclSelf is a reserved spelling.

    Classifier::allInstances(OclSelf)() : Set(OclSelf) – set of the derived classifier
    OclAny::oclType(OclSelf)() : OclSelf – my own type as statically known
    OclAny::oclAsSet(OclSelf)() : Set(OclSelf) – set of my own and derived types, declared as the statically known type

    [oclAsSet is the currently unspecified library operation used to realise implicit object-to-set conversion]

    Without an OclSelf, almost any usage of these library operations must be followed by an oclAsType to the already known type.

    e.g. with the OCL 2.3 type system the library function is

    Classifier::allInstances() : Set(Classifier)

    and so the usage is

    MyType.allInstances() – is MyType instances as a Set(Classifier)
    MyType.allInstances().oclAsType(Set(MyType)) – necessary cast to statically known type

  • Reported: OCL 2.1 — Sat, 12 Feb 2011 05:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

Align OCL with out/inout UML Operation Parameters

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

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

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

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

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

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

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

The notation when nesting "if then else" is too verbose

  • Key: OCL25-108
  • Legacy Issue Number: 6884
  • Status: open  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    Suggestion: Define a "switch" collection function, with a sepecific notation, as in:
    mylist->switch( iterator | cond1 ? exp1, cond2 ? exp2, …, else ? expN)
    The expressions cond2 is not evaluated if cond1 returns true and so on.

  • Reported: OCL 2.0b2 — Wed, 7 Jan 2004 05:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

Issue: Signature of Environment

  • Key: OCL25-109
  • Legacy Issue Number: 6574
  • Status: open  
  • Source: Anonymous
  • Summary:

    Description: The specification (in the standard) of the Environment class is missing a few things that are used or referred to elsewhere in the standard; some are missing altogether and some are missing from the class diagram:
    The association from an environment to its parent.
    The operations lookupImplicitSourceForOperation, lookupPathName, addEnvironment
    Rationale: We show a more complete specification below. We also add a convenience method addVariableDeclaration; although not necessary as addElement can be used to add a VariableDeclaration, this operation avoids the need to construct the VariableDeclaration before adding it to the environment.
    The specification of the Environment operations uses various methods on the bridge classes; we have added these operations to the classes, as shown in the previous section about the bridge classes.

  • Reported: OCL 2.0b2 — Tue, 11 Nov 2003 05:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

Additional annotations in the OCL Standard Library

  • Key: OCL25-110
  • Legacy Issue Number: 6536
  • Status: open  
  • Source: Anonymous
  • Summary:

    Author: Stephan Flake (flake@c-lab.de)
    Description: The OCL Standard Library type system should make use of the notation offered by the official UML specification. In particular, abstract types (like OclAny, Collection(T)), datatypes (Integer, Set(T)), and enumeration types (OclState) can be denoted in italics and stereotyped, respectively.
    An ellipsis can be used to indicate that further types are imported from a referred UML user model.
    Moreover, OrderedSet(T) is missing in the OCL Standard Library Type type system.

  • Reported: OCL 2.0b2 — Mon, 10 Nov 2003 05:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

Align OCL bodyExpression and UML bodyCondition

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

    OCL 12.10 awaits alignment with the UML 2.0 metamodel.

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

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

    Reinterpret the grammar

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

    such that

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

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

    [Allow multiple body declarations.]

    Thus

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

    and

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

    could be the specification of a UML operation

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

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

Invalid algorithm in definitions of sortedBy

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

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

    Invalid algorithm:

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

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

    Inconsistent use of < and >:

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

    Typos:

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

    SOLUTION:

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

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

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

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

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

    FURTHER SUGGESTIONS:

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

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

      {2, 2, 1}

      ->sortedBy(x|x) = Sequence

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

Example of collect in terms of iterate is not flattened

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

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

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

Conflicting String::indexOf postConditions

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

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

    Replace:

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

    by

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

    and move it to the second postcondition

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

Support zero argument iterations

  • Key: OCL25-111
  • Legacy Issue Number: 19702
  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    Some iterations are needlessly verbose to use for simple cases.

    ->sortedBy(n |n) for a simple self sort could be abbreviated to ->sortedBy()

    ->forAll(n | n) for ANDall could be abbreviated to ->forAll()

    ->exists(n | n) for ORall could be abbreviated to ->exists()

    ->any(true) could be abbreviated by ->any()

  • Reported: OCL 2.1 — Tue, 6 Jan 2015 05:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

i/r typo

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

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

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

Add isInteger/isReal

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

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

    Add isBoolean/toBoolean/toString

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

indentified

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

    Change to identified

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

OCL Constraints in many levels

  • Key: OCL25-105
  • Legacy Issue Number: 7972
  • Status: open  
  • Source: Anonymous
  • Summary:

    I been using rational rose and bold for delphi in some projects. This have worked very well for me.
    When adding constraints to my models i have some times whished that there whas a way to do this
    on different levels. Eg. error-constraints (if persisted the object would be a dirty data) ,

    warning-constraints these can be broken but there is high probability that the object is ill formed from the
    system user perspective (example a new customer whith no billing adress) and finally a hint-contraint that
    when broken indicates that the object containes strange data (example a new customer object with the
    same phone number as a existing customer)

    My own solution to this have been to add contraints of the first type to the model. This have enabeld me
    to create generic code dealing with if the user should be allowed to save a object or not.

    The other types of constraints have been added as coments as a way to make the model as complete as
    possibel. The implementation of checking and dealing with these constraints later in the project have ben
    solved in a mutch less generic and cumbersom way.

    I thin´k that if the standard included a way to specify different levels of ocl statements in the model this would
    benefit the model driven way to make software

  • Reported: OCL 2.0b2 — Fri, 10 Dec 2004 05:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

number of elements in the result value

  • Key: OCL25-104
  • Legacy Issue Number: 7540
  • Status: open  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    32. – [3] The number of elements in the result value is equal to the number of
    – elements in the collection literal parts, taking into account that a
    – collection range can result in many elements.
    context CollectionLiteralExpEval inv:
    resultValue.elements->size() = parts->collect( element )>size()>sum()
    ==> ’resultValue’ should be ’resultValue->oclAsType(OCLDomain::Values::CollectionValue)’

  • Reported: OCL 2.0b2 — Thu, 10 Jun 2004 04:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

value of an association end call expression evaluation

  • Key: OCL25-106
  • Legacy Issue Number: 7518
  • Status: open  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    10. – [2] The result value of an association end call expression evaluation that has
    – qualifiers, is determined according to the following rule. The ‘normal’
    – determination of result value is already given in section 5.3.7
    – ("Well-formedness Rules of the Evaluations package").
    ==> add ’inv’, remove ’implies’, add comma. It should be:
    [2] The result value of an association end call expression evaluation that has
    – qualifiers, is determined according to the following rule. The ‘normal’
    – determination of result value is already given in section 5.3.7
    – ("Well-formedness Rules of the Evaluations package").
    inv: let
    – the attributes that are the formal qualifiers
    formalQualifiers : Sequence(Attribute) =
    self.model.referredAssociationEnd.qualifier ,
    – the attributes of the class at the qualified end
    objectAttributes: Sequence(Attribute) =
    (if self.resultValue.model.isOclKind( Collection )
    then self.resultValue.model.oclAsType( Collection ).elementType->
    collect( feature->asOclType( Attribute ) )
    else self.resultValue.model->collect( feature->asOclType( Attribute ) )
    endif).asSequence() ,
    – the values for the qualifiers given in the ocl expression
    qualifierValues : Sequence( Value ) = self.qualifiers.asSequence() ,
    – the objects from which a subset must be selected through the
    qualifiers
    normalResult =
    source.resultValue.getCurrentValueOf(referredAssociationEnd.name)
    in
    – if name of attribute of object at qualified end equals name of formal
    – qualifier then
    – if value of attribute of object at qualified end equals the value
    given in
    – the exp
    – then select this object and put it in the resultValue of this
    expression.
    qualifiers->size <> 0 implies
    normalResult->select( obj |
    Sequence

    {1..formalQualifiers->size()}

    ->forAll( i |
    objectAttributes->at.name = formalQualifiers->at.name and
    obj.getCurrentValueOf( objectAttributes->at.name ) =
    qualifiersValues->at ))

  • Reported: OCL 2.0b2 — Thu, 10 Jun 2004 04:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

Add a concrete syntax to allow OCL users to add additional IteratorExp’s

  • Key: OCL25-107
  • Legacy Issue Number: 7457
  • Status: open  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    Add a concrete syntax to allow OCL users to add additional IteratorExp’s. People using OCL have
    the need to define their own iterators and should be able to do so in a standardized way.

  • Reported: OCL 2.0b2 — Thu, 10 Jun 2004 04:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

OCL 2.1 12 UML alignment

  • Key: OCL25-96
  • Legacy Issue Number: 14593
  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    12.1, 12.2 refer to UML 1.4.

    12.1.1, 12.9, 12.12 defers until UML 2.0 is defined.

    12.5, 12.8 uses Attribute and AssociationEnd rather than Property

    12.5.1[1], 12.6.1[1], 12.7.1[1], 12.7.3[1] make use of self.constraint.stereotype.name. Constraint has
    keywords rather than stereotypes

  • Reported: OCL 2.1 — Sat, 31 Oct 2009 04:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

OCL 2.1 12 Definition Referencability Semantics

  • Key: OCL25-97
  • Legacy Issue Number: 14592
  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    The absence of synthesized and inherited attributes in 12.2 makes it unclear how an environment is maintained and so makes it unclear whether OCL supports forward and/or backward references.

    Presumably both forward and backward references are allowed, so a two phase behaviour is needed to enter all definition names in the environment(s) in phase 1 so that they are visible for lookup in phase 2.

  • Reported: OCL 2.1 — Sat, 31 Oct 2009 04:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

OCL 2.1 11.7 Inflexible Collection operation signatures

  • Key: OCL25-98
  • Legacy Issue Number: 14577
  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    The Collection(T)::product(c2 : Collection(T2))

    signature carefully uses T2 to distinguish self and argument element types.

    The same distinction is missing from

    Collection(T)::"="(c : Collection(T))
    Collection(T)::"<>"(c : Collection(T))
    Collection(T)::includesAll(c : Collection(T))
    Collection(T)::excludesAll(c : Collection(T))
    Set(T)::union(s : Set(T))
    Set(T)::union(b : Bag(T))

    etc etc

    The current definition makes at least one of

    Set

    {1.0}>excluding(1.0) = Set{1}->excluding(1)
    Set{1}
    >excluding(1) = Set{1.0}

    ->excluding(1.0)

    invalid through lack of a suitable collection operation.

    For some operations, such as union, a T2 conforms to T well-formedness constraint is appropriate,
    but for others, such as removeAll, T2 and T can be independent.

  • Reported: OCL 2.1 — Mon, 26 Oct 2009 04:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

Redundant CollectionLiteralExp::kind complicates collection type extension

  • Key: OCL25-99
  • Legacy Issue Number: 13225
  • Status: open  
  • Source: Borland Software Corporation ( Radek Dvorak)
  • Summary:

    The CollectionLiteralExp class defines the 'kind' attribute to indicate the specific collection type of the literal (8.3.5 Literal Expressions).
    This information is redundant as the collection kind can be deduced from the 'type' association inherited from the TypedElement.
    As the attribute type is CollectionKind enumeration, it restricts to the set of predefined OCL collection types.
    Other languages that extend OCL, like QVT does, may need to define custom CollectionType subclasses but can't
    reuse CollectionLiteralExp as it's impossible to provide a suitable collection kind value.

    Proposed resolution:
    Remove the CollectionLiteralExp::kind attribute, eventually consider removing the CollectionKind enumeration.

  • Reported: OCL 2.0 — Thu, 8 Jan 2009 05:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

Provide the list of reflective MOF operations that are available

  • Key: OCL25-100
  • Legacy Issue Number: 11056
  • Status: open  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    Is not very clear what are the reflective MOF operations that are available
    to QVT operational transformation writers

  • Reported: OCL 2.0 — Thu, 24 May 2007 04:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

Section: 10.3.4 OclMessageArgEval

  • Key: OCL25-101
  • Legacy Issue Number: 8653
  • Status: open  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    The association variable is not diagrammed in fig. 23. Please add it to the fig

  • Reported: OCL 2.0b2 — Tue, 29 Mar 2005 05:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

Section: 10.3.2 OperationCallExp

  • Key: OCL25-103
  • Legacy Issue Number: 8651
  • Status: open  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    The subtype name on fig. 21 is OperationCallExpEval which I believe is correct. Please change the title of this sub-section

  • Reported: OCL 2.0b2 — Mon, 28 Mar 2005 05:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

Section: 10.3.1 VariableExpEval

  • Key: OCL25-102
  • Legacy Issue Number: 8649
  • Status: open  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    The name of the association in fig. 20 is "referredVariable." Please correct either the text or the figure

  • Reported: OCL 2.0b2 — Mon, 28 Mar 2005 05:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

OCL 2.1 Inadequate definition of run-time meta-model

  • Key: OCL25-95
  • Legacy Issue Number: 14861
  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    OCL 2.1 currently specifies an informal run-time meta-model in which all types conform to OclAny. Contributions to this meta-model come from

    • the user meta-model(s)
    • the standard library and its extensions
    • additional constraints

    Problem 1: An OCL AST for an OperationCallExp has a referredOperation that must be able to reference an operation that may come from any of these sources. Issue 12854 raised the problem of referencing additional operations and attributes.

    Problem 2: The almost trivial problem of referencing standard library features has not been raised. If an AST is to be portable between one OCL tool and another there must be a standard URI by which for instance OclAny::= is referenced. Where is this URI specified?

    Problem 3: The semantics of ambiguity resolution between alternative contributions is unclear. UML appears to leave overloading as a semantic variation point, so UML compliance is not helpful. Issue 14591 suggested that a first phase execution created at least a composite UML meta-model.

    Problem 4: OCL 2.1 made clear that there is no reflection at run-time, and introduced OclAny::oclType to compensate. This provides very limited capabilities, in particular there is no counterpart to Element::container().

    A formal run-time model and meta-model can solve these problems. The run-time model is the OCL library model, it's meta-meta-model is the OCL library meta-model and it's meta-meta-meta-model is MOF/UML. NB The OCL library meta-model is not the OCL meta-model.

    The OCL library model comprises primarily oclstdlib::Classifier instances, one of which is named OclAny. OclAny::oclType() returns its oclstdlib::Classifier (NB not a uml::Classifier).

    The oclstdlib::Classifier::conformsTo property (like but not uml::Classifier::general) contributes to the reified type conformance hierarchy.
    The oclstdlib::Classifier::operations property (like but not uml::Classifier::operations) unifies the three sources of available operations, and three different derivations of oclstdlib::Operation accommodate the three types of contribution.

    The oclstdlib model therefore integrates the user's UML meta-model with the standard library and additional constraints and is built during the first phase of execution. The oclstdlib meta-model is much simpler than MOF; there is no need for Associations and ConformsTo is the only Relationship. The semantics of the oclstdlib model defined independently of UML ensure a clear definition of the meaning of OCL execution.

    The oclstdlib model should make no pretence at being UML because it is fundamentally different. One form of oclstdlib::Operation integrates a reference to a uml::Operation into a uniform behavioural structure. oclstdlib::Classifier ::conformsTo provides the modification of the user meta-model to insert OclAny as the bottom type, without modifying the user meta-model.

    With an oclstdlib metaModel, OclAny could provide reflective capabilities such as oclContainer(), oclContents(), oclGet(), oclSet() etc that provide useful reflective capabilities. self.oclType().operations can satisfactorily return a collection of operations even though the operations come from three diverse sources. self.oclType()->closure(conformsTo) will return the type conformance ancestry.

  • Reported: OCL 2.1 — Mon, 14 Dec 2009 05:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

OCL Stereotypes

  • Key: OCL25-85
  • Legacy Issue Number: 15426
  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    The OCL 2.2 specification refers to stereotypes in the UML 1.x sense. These need to be aligned with UML 2.x. Are they 'keyword' or 'Stereotype'? Is there an OCL Profile to be applied?

    NB. the sterotypes are of two forms:
    a) Constraint role: invaraint/precondition/...
    b) UML extension: OclHelper for a Complete OCL def (see 7.4.4.)

  • Reported: OCL 2.1 — Mon, 23 Aug 2010 04:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

OCL 2.2: Section: 7.5.3 Clarification required for Qualifying association ends with association names

  • Key: OCL25-87
  • Legacy Issue Number: 15368
  • Status: open  
  • Source: Dell Technologies ( George Ericson)
  • Summary:

    The text in the clause titled “Qualifying association ends with association names” points out that it is possible to qualify an accessed role name with the name of the association using the ‘::’ separator. (In the example: aC1.A1::c2.) There is no issue with this as a means to access the associated instance. However, in doing so, the clause misses the opportunity to also say that it is also possible to reference the same associated instance using the ‘.’ (dot) operator in place of the ‘..’ separator, (for example: aC1.A1.c2).

    While this was also true prior to OCL 2.2, only the later technique was referenced in OCL 2.0.

    Clarification is needed with respect to whether or not there are any semantic differences between the uses of these two techniques. Where the functionality overlaps, is there a preferred technique?

    Nit: the last sentence of the example:

    “If a C1 is aC1 access, aC1.c2 will not be valid since it is ambiguous, whereas aC1.A1::c2 or aC1.A2::c2 will be valid.”

    Should probably say:

    “If aC1 isa C1, then aC1.c2 will not be valid since it is ambiguous, whereas aC1.A1::c2 or aC1.A2::c2 will be valid.”

  • Reported: OCL 2.1 — Fri, 9 Jul 2010 04:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

OCL 2.2 OclState, State, StateExp, StateExpCS, StateValue and StateExpEval

  • Key: OCL25-86
  • Legacy Issue Number: 15357
  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    The use of OclState in the specification is not defined in the normative part of the specification, where it appears solely as OclAny.oclIsInState(statespec : OclState).

    A corresponding StateExp exists to convey this as a referredState of type State.

    Surely the OclState type is redundant and it should be OclAny.oclIsInState(statespec : State)?

    The use of OclState in Annex A may be helpful, so perhaps an introduction to Annex A could explain the mappings between the names used for clarity in Annex A and those used in the normative specification.

    Aren't a StateValue and StateExpEval needed to define the semantics?

    Isn't a StateExpCS needed to define the abstract/concrete syntax? Perhaps this could merge with TypeExpCS, TypeLiteralExpCS as ModelElementLiteralCS.

  • Reported: OCL 2.1 — Thu, 8 Jul 2010 04:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

OCL 2.2 OclState and oclIsInState

  • Key: OCL25-88
  • Legacy Issue Number: 15257
  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    The oclIsInState takes an OclState argument, which is referenced extensively
    in
    Annex A, although the OclState type is never defined in the main text and is
    not
    mentioned in the grammar as a reserved word.

    oclIsInState is misspelled as oclInState 7 times in Section 7.5.9 and once
    in A.2.6.

  • Reported: OCL 2.1 — Tue, 18 May 2010 04:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

OCL 2.2 Correction to Issue 9796 for AssociationEndCall

  • Key: OCL25-89
  • Legacy Issue Number: 15233
  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    Issue 9796 responded to the merge of Attribute and AssociationEnd as Property in UML
    by merging AttributeCallExp and AssociationEndCallExp.

    This merge was not appropriate since UML made no change to the required OCL navigability.

    Without AssociationEndCallExp, it is not possible to express a qualified association navigation,
    since the 'replacement' PropertyCallExp does not allow for the qualifiers in:

    self.customer[123456]

  • Reported: OCL 2.1 — Thu, 29 Apr 2010 04:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

OCL 2.2 Clarity of qualified path names

  • Key: OCL25-90
  • Legacy Issue Number: 15219
  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    At the end of Section 7.4.6 OCL 2.2 says

    "For clarity, the qualified form may only be used with an explicit source
    expression."

    thereby requiring "self.Person::age()" rather than just "Person::age()".

    This 'clarity' is surely just a stylistic issue.

    An organisation may advocate an OCL-style guide that discourages the use of
    implicit-self.
    That is a free choice made by that organisation.

    It does not seem appropriate for one corner of the OCL specification to
    prohibit implicit-self
    where consistency would imply that it should be present.

    This is not a 'clarity', it is a confusion.

    Suggest allow implicit-self before qualified path names (unless there is a
    different
    strong technical reason.)

  • Reported: OCL 2.1 — Thu, 22 Apr 2010 04:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

Collection::sum is not realisable for empty collection of user defined type

  • Key: OCL25-91
  • Legacy Issue Number: 15010
  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    Collection::sum is defined to exploit an associative and commutative T::+(T).

    However for an empty collection, the result must be a zero value of the
    user defined type and there is no mechanism to determine its 0.

    Suggest: require a T::zero() and provide corresponding Real::zero() and Integer::zero() and UnlimitedNatural() operations.

  • Reported: OCL 2.1 — Sun, 31 Jan 2010 05:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

OCL 2.1 11.7.3 Missing OrderedSet::-

  • Key: OCL25-94
  • Legacy Issue Number: 14984
  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    The minus operation should be provided for OrderedSet as well as Set.

  • Reported: OCL 2.1 — Sun, 17 Jan 2010 05:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

OCL 2.1 11.7 Missing OrderedSet::excluding and including

  • Key: OCL25-93
  • Legacy Issue Number: 14983
  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    excluding and including are defined for Bag, Sequence and Set but not OrderedSet or Collection.

    The Collections would be more consistent with an OrderedSet::excluding and an OrderedSet::including.

    With all concrete Collection types defining excluding and including, the abstract Collection could also
    define Collection ::excluding and an Collection ::including supporting fully polymorphic addition and
    querying of collections.

  • Reported: OCL 2.1 — Sun, 17 Jan 2010 05:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

OCL 2.3 - heterogeneous collections cannot be typed

  • Key: OCL25-83
  • Legacy Issue Number: 16106
  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    A Collection containing both 'a', and

    {'b', 'c'}

    must be typed as a
    Collection of OclAny since that is the only common type.

    This is unhelpful for tree structures.

    Suggest introduction of a pseudo-collection type Tree(T) to which
    both T and Collection(Tree(T)) conform.

    A String content tree then then be declared as a Tree(String).

  • Reported: OCL 2.1 — Mon, 4 Apr 2011 04:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

OCL 2.3.TupleType semantics and AST

  • Key: OCL25-84
  • Legacy Issue Number: 15920
  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    8.2 Does the lack of restriction on feature types for a TupleType extend to InvalidType and VoidType? With an InvalidType feature the tuple could only be 'well-formed' when containing an invalid value. Surely a tuple with an invalid value is itself invalid and not well-formed?

    8.2.2 TupleType has some ASCII code corruptions in the OCL.

    8.2.2 TupleType uses unqualified names for feature types allowing an ambiguity when package path is significant.

    10.2 TupleValue surely values must not be invalid?

    13 TupleLiteralExp has a TupleLiteralPart which has a Property, not accommodating the OclExpression of an initExpression provided by the concrete syntax. Surely a TupleLiteralPart is a derived VariableDeclaration adding an initExpression?

  • Reported: OCL 2.1 — Sat, 8 Jan 2011 05:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

need clear specification for how to write OCL that refers to the stereotypes applied to a model within a UML profile

  • Key: OCL25-76
  • Legacy Issue Number: 16936
  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    Yet another query on an Eclipse newsgroup has asked how stereotypes/profiles work in a transformation language, so I've taken a brief look and it appears that UML 2.5 Section 12 appears gives the only clue as to how an OCL expression might navigate a Stereotype:

    self.base_Interface.ownedAttributes->size() = 0

    This is a particularly unfortunate example since it uses reflection, or at least multiple meta-levels, which are not currently supported in OCL 2.x.

    Once OCL supports reflection and type literals, I would expect to see something more like

    Interface.ownedAttribute->size() = 0

    The constraint presumably is that the stereotype has no attributes, regardless of the class to which it is applied.

    Reflective operation might do something like

    self.oclType().selectFragment(Interface).ownedAttribute->size() = 0

    (if selectFragment is an OCL library operation that selects a type merge contribution).

    The utility of the meta-level traversing 'base_xxxx' and 'extension_xxxx' seems very suspect. Does any tool support them? I know Eclipse UML2 has at least a 'base_xxxx' name, but I doubt that it is reflective. It's sole purpose seems to be to give me trouble with validation errors.

    -----------------

    It seems to me that in the same way that (for base classes):

    A class C (with property c) may have base classes B1 (with properties b, b1) and B2 (with property b, b2) allowing implicit access such as aC.c, aC.b1, aC.b2, but requiring qualification for aC.B1::b and allowing redundant qualification for aC.B1::b1.

    then (for stereotypes):

    A Class C may have stereotypes S1 (with properties s, s1) and S2 (with properties s, s2) allowing implicit access such as aC.s1, aC.s2, but requiring qualification for aC.S1::s and allowing redundant qualification for aC.S1::s1. The implicit access is only permissible when it is statically known that the Stereotype has been applied, i.e for an expression whose context is the Stereotype. In more general contexts the Stereotype qualification may need a run-time check and an invalid result if the Stereotype has not been applied. Thus:

    not aC.S1::s1.oclIsInvalid() implies some-expression-when-S1::s-exists

    If property overloading is forbidden, but operation overloading permitted, in the above

    adding a property C::b, or S1::c or S2::b2 would be a static error since the added property overloads a property name already present in the extended class. Note that this is not in accord with the current OCL specification that motivates the introduction of qualification to support access to hidden property names, which UML prohibits.

    adding any operation in a stereotype is valid; it is either a new or overloaded operation. However two stereotypes contributing the same operation signature is a static error to be detected by the attempt to apply both stereotypes.

    Since the WFRs for the above belong in UML, presumably the above should be in the UML specification, and the OCL specification should just map the alternate navigation syntaxes appearing in the UML specification to appropriate Concrete and Abstract Syntax Expression elements.

  • Reported: OCL 2.1 — Fri, 30 Dec 2011 05:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

OCL 2.3 A.2.6 Collection conforms to OclAny contradiction

  • Key: OCL25-77
  • Legacy Issue Number: 16487
  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    Issue 12948 "Making OclAny denote any object" was resolved to allow Collection to conform to OclAny.

    A.2.6 still states "A simple set inclusion semantics for subtype relationships as described in the next sub section would not be possible due to cyclic domain definitions if OclAny
    were the supertype of Set(OclAny)."

    A premise for Annex A has therefore been violated requiring rework to consider at least a less simple set inclusion semantics.

  • Reported: OCL 2.1 — Sat, 6 Aug 2011 04:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

OCL parsed OCL string literal

  • Key: OCL25-78
  • Legacy Issue Number: 16370
  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    As part of the support for lambda expressions an ability to parse OCL from a string would be useful

  • Reported: OCL 2.1 — Thu, 14 Jul 2011 04:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

OCL 2.3 Enumeration::allInstances() does not return instances

  • Key: OCL25-79
  • Legacy Issue Number: 16168
  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    a) an OrderedSet would be more appropriate
    b) enumeration literals are instances of EnumerationLiteral; they are not instances of an Enumeration

    cf. MyClass.allInstances() dynamically overloads Classifier.allInstances() to return all known instantiations of MyClass, rather than all features of MyClass.

    so why does MyEnumeration.allInstances() prevent me discovering all instantiations of MyEnumeration; Enumeration is a Classifier.

    The required functionality of MyEnumeration::allInstances() is available as MyEnumeration.ownedLiteral provided reflection is consistently defined.

    Suggest: remove the Enumeration.allInstances() overload.

  • Reported: OCL 2.1 — Fri, 6 May 2011 04:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

Japan PAS Ballot Comment 29 (ocl2-rtf) 10.2.4 Overview of the Values Package

  • Key: OCL25-80
  • Legacy Issue Number: 16152
  • Status: open  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Figure 10.5 StringValue only appears here. No explanation was given before the diagram. Add definition or explanation of StringValue before this diagram

  • Reported: OCL 2.1 — Wed, 20 Apr 2011 04:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

Japan PAS Ballot Comment 15 (ocl2-rtf) Section 8.3.5 Fig8.7 & following class description (p50-p51)

  • Key: OCL25-81
  • Legacy Issue Number: 16138
  • Status: open  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    The class diagram on Fig8.6 & Fig8.7 and its class description is inconsistent. For example, there is TupleLIteralPart on the class diagram. However, there is no class description in p51. Additionally, as class description of CollectionLiteralPart, Associations describes “type”. Furthermore, PrimitiveLiteralExp doesn’t have any attributes on the class diagram (Fig 8.6). However, followed class description, p51, Attribute “symbol” is described. And, there is a referredEnumLiteral as class description. However, class diagram doesn’t have referredEnumLiteral on Fig. 8.6. PROPOSED RESOLUTION: Correct class diagram and its class description

  • Reported: OCL 2.1 — Wed, 20 Apr 2011 04:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

Japan PAS Ballot Comment 14 (ocl2-rtf) - Section 8.3.2 Fig8.3 & AssociationClassCallExp

  • Key: OCL25-82
  • Legacy Issue Number: 16137
  • Status: open  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    As class description, there is a AssociationClassCallExp. However, there is no Class on the class diagram in Fig.8.3.. Proposed change: Add Class “AssociationClassCallExp” on the class diagram in Fig. 8.3.

  • Reported: OCL 2.1 — Wed, 20 Apr 2011 04:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

Error in OCL 2.4 spec

  • Key: OCL25-72
  • Legacy Issue Number: 19460
  • Status: open  
  • Source: Anonymous
  • Summary:

    For reference: http://www.omg.org/spec/OCL/2.4/
    The concrete syntax for the rule invOrDefCS in section 12.12.6 seems to establish an infinite recursive relation without a terminal rule. Perhaps a question mark is needed, or some clarification?

  • Reported: OCL 2.1 — Wed, 11 Jun 2014 04:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

Missing/Poor definition of iterate()

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

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

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

    Suggest: Add iterate() to Section 11.

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

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

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

Reverse CollectionRange should be empty rather than invalid

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

    The clarification of Issue 15836 is too strong.

    For an empty collection it is im,portant that

    let s = Sequence{} in Sequence

    {1..s->size()}

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

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

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

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

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

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

    ? oclIsKindof true for all types except OclIsInvalid.

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

Obsolete implicit cast to Bag

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

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

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

value of an association class call expression

  • Key: OCL25-65
  • Legacy Issue Number: 7532
  • Status: open  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    24. – [1] The result value of an association class call expression is the value
    – bound to the name of the association class to which it refers. Note that the
    – determination of the result value when qualifiers are present is specified in
    – section 5.4.3 ("Well-formedness rules for the AS-Domain-Mapping.exp-eval
    – Package"). The operation getCurrentValueOf is an operation defined on
    – ObjectValue in section 5.2.3 ("Additional operations for the Values Package").
    context AssociationClassCallExpEval inv:
    qualifiers->size = 0 implies
    resultValue =
    source.resultValue.getCurrentValueOf(referredAssociationClass.name)
    ==> ’size’ should be ’size()’
    ==> ’resultValue’ should be ’resultValue->oclAsType(OCLDomain::Values::ObjectValue)’

  • Reported: OCL 2.0b2 — Thu, 10 Jun 2004 04:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

context Parameter::asAttribute(): Attribute

  • Key: OCL25-66
  • Legacy Issue Number: 7502
  • Status: open  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    34. context Parameter::asAttribute(): Attribute
    pre: – none
    post: result.name = self.name
    post: result.type = self.type
    post: result.multiplicity = 1
    post: result.targetscope = ScopeKind::instance
    post: result.ownerscope = ScopeKind::instance
    post: result.ordering = OrderingKind::unordered
    post: result.visibility = VisibilityKind::private
    post: result.stereotype.name = ’OclHelper’
    ==> ’result.multiplicity = 1’ should be ’result.multiplicity = Multiplicity::one’

  • Reported: OCL 2.0b2 — Thu, 10 Jun 2004 04:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

Allow defining standard library functions

  • Key: OCL25-67
  • Legacy Issue Number: 6891
  • Status: open  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    Allow defining standard library functions (including iteration operators) that
    have a variable number of parameters.

  • Reported: OCL 2.0b2 — Wed, 7 Jan 2004 05:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

compliance points strategies

  • Key: OCL25-68
  • Legacy Issue Number: 6601
  • Status: open  
  • Source: Modeling Value Group ( Wim Bast)
  • Summary:

    The compliance points strategies mentioned in the OCL 2.0 spec are different from the UML 2.0 infra, super and MOF 2.0 specs. We need to align the OCL spec on this

  • Reported: OCL 2.0b2 — Wed, 12 Nov 2003 05:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

Introduce a "tuplejoin" operator

  • Key: OCL25-70
  • Legacy Issue Number: 6557
  • Status: open  
  • Source: Anonymous
  • Summary:

    Author: Herman Balsters (h.balsters@bdk.rug.nl)
    Description: OCL 2.0 is not as expressive as SQL (as opposed to common belief) and needs to be extended to this end
    Rationale:
    In my paper "Modeling Database Views with Derived Classes in the UML/OCL-framework" of this years UML conference (see proc. pp. 295-309) I investigated the issue of expressibility of OCL 2.0 w.r.t. to the query langauge SQL. I have demonstrated in that paper that OCL 2.0 is not as expressive as SQL (as opposed to common belief), and that OCL needs an additional "tuplejoin" operator to achieve the desired result.
    If this issue cannot be dealt with in this phase, I propose it be retained and examined at the next stage.

  • Reported: OCL 2.0b2 — Tue, 11 Nov 2003 05:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

Satisfaction of Operation Specifications (3)

  • Key: OCL25-69
  • Legacy Issue Number: 6550
  • Status: open  
  • 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: Change Definition A.34 to allow the precondition to be weakened
    Rationale:
    It is commonly accepted that a program S satisfying an operation specification may weaken the precondition. This corresponds to Bertrand Meyer's view of software specifications as contracts between clients of a program and program provider. This is in accordance with the explanation following Def. A.34: "In other words, the program S accepts each environment satisfying the precondition as input and produces an environment that satisfies the postcondition." This sentence admits the possibility that S may be defined for environments not satisfying the precondition.
    However Def. A.34 requires S to be defined exactly on the environments for which the precondition holds. Therefore, we propose to replace Def. A.34 by:
    DEFINITION A.34 (SATISFACTION OF OPERATION SPECIFICATIONS)
    An operation specification with pre- and postconditions is satisfied by a program S in the sense of total correctness if the computation of S is a function fS such that the restriction of fS to the domain of R is a total function fS|_dom(R): dom(R) -> im(R) and graph(fS|_dom(R)) \subseteq R.

  • Reported: OCL 2.0b2 — Tue, 11 Nov 2003 05:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

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

  • Key: OCL25-62
  • Legacy Issue Number: 8902
  • Status: open  
  • 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.0 — Tue, 7 Jun 2005 04:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

Section: 10.4.3 IntegerLiteralExpEval

  • Key: OCL25-61
  • Legacy Issue Number: 8658
  • Status: open  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    To be consistent with other sub-sections, use [1] before the OCL well-formedness rule

  • Reported: OCL 2.0b2 — Tue, 29 Mar 2005 05:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

Section: 10.3.5

  • Key: OCL25-63
  • Legacy Issue Number: 8656
  • Status: open  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    None of the attributes or associations diagrammed are mentioned in the text. If there is no intention of mentioning them in their respective expression evaluations make a note of this in the opening description of the section. TupleliteralExpPartEval is not diagrammed in fig. 24 but VariableDeclEval is diagrammed and not mentioned in the text. Please correct.

  • Reported: OCL 2.0b2 — Tue, 29 Mar 2005 05:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

Section: 9.3 CollectionLiteralPartsCS

  • Key: OCL25-64
  • Legacy Issue Number: 8640
  • Status: open  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    There is inconsistency in the spelling of "CollectionLiteralPartsCS" sometimes using the "s" after "Part" and sometimes capitalizing the "S" after "Part". This becomes even more confusing when the next production is "CollectionLiteralPartCS" - notice no"s" following "Part".

  • Reported: OCL 2.0b2 — Mon, 28 Mar 2005 05:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

OCL 2.1 11.7: Clarifying Collection Well-formedness rules

  • Key: OCL25-54
  • Legacy Issue Number: 14576
  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    The discussion of Issue 12953 suggests that two members of the RTF agreed that is unclear
    what T in e.g Set's including(Object : T) means.

    The first paragraph of Section 11.6 makes clear that the intent of the specification applies to e.g. Set(T) and
    so the well-formedness rules in 11.7 refer to e.g. Set(T)::including(Object: T), so T is the known element
    type of the collection. It is therefore a static error to attempt to invoke Set(T) including for an object
    incompatible with the known element type T.

    It would be helpful for the Section headings in 11.7 to have a (T) appended so that the 11.6 specification
    of T was clearly carried over from 11.6 to 11.7. e.g.

    Replace

    11.7.1 Collection

    by

    11.7.1 Collection(T)

  • Reported: OCL 2.1 — Mon, 26 Oct 2009 04:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

CMOF serializations of its metamodels not published

  • Key: OCL25-56
  • Legacy Issue Number: 12562
  • Status: open  
  • Source: Zeligsoft, Inc. ( Christian Damus)
  • Summary:

    No CMOF models of OCL Abstract Syntax Unlike most successful specifications in the MOF and UML family, the OCL specification does not publish CMOF serializations of its metamodels. Publication of normative metamodels will greatly improve the clarity of the specification and assist tools in implementing it. XMI serializations of the following metamodels are recommended: - CompleteOCL Abstract Syntax (UML basis) - EssentialOCL Abstract Syntax (EMOF basis) Also, a separate document containing normative EBNF or RelaxNG grammars of: - CompleteOCL Concrete Syntax - EssentialOCL Concrete Syntax

  • Reported: OCL 2.0 — Sat, 5 Jul 2008 04:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

Section: A.3.2.2 Syntax and Semantics of Postconditions (04)

  • Key: OCL25-58
  • Legacy Issue Number: 12496
  • Status: open  
  • Source: Net.Orange (i.e. Net Dot Orange) ( Garr Lystad)
  • Summary:

    In the paragraph before Definition A.33 we have, "We say that a precondition P satisfies a pre-environment rpre – written as rpre |= P –....". In the explanation of Definition A.33 we have, "...the pre-environment rpre satisfies the precondition P....". One of these must be backwards. Does the environment satisfy the condition (2nd above) or does the condition satisfy the environment (1st above)?

  • Reported: OCL 2.0 — Thu, 15 May 2008 04:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

Section: A.3.2.2 Syntax and Semantics of Postconditions (03)

  • Key: OCL25-57
  • Legacy Issue Number: 12495
  • Status: open  
  • Source: Net.Orange (i.e. Net Dot Orange) ( Garr Lystad)
  • Summary:

    At the beginning of Definition A.32 you will find the sentence, "The semantics of an expression e ? Post-Exprt is a function I[[ e ]] : Env x Env ? I(t)." It doesn't seem that this can be right since the argument to I[[.]] is an element of Post-Expt-sub-t. So, similarly to Definition A.30, I would suggest that something akin to "I[[ e ]] : Post-Exprt ? (Env x Env ? I(t))" would be more appropriate.

  • Reported: OCL 2.0 — Thu, 15 May 2008 04:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

Mismatch between the definition of operators in, e.g., Section 11.7.1 and i

  • Key: OCL25-55
  • Legacy Issue Number: 12453
  • Status: open  
  • Source: Anonymous
  • Summary:

    Mismatch between the definition of operators in, e.g., Section 11.7.1 and in Table A.3: product operation is missing in the latter. By the way, there are many printing problems in this table. Similar mismatch: flatten operation is specified for Sets (p. 147) for Bags (p. 151) and for Sequences (p. 152) but are not mentioned in the corresponding tables in Annex A. By the way, whey flatten is not specified for OrderedSets? Why several methods specified for Sets and Bags (union, intersection, etc.) but not for OrderedSets?

  • Reported: OCL 2.0 — Wed, 14 May 2008 04:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

inclusion of Regular Expression support

  • Key: OCL25-60
  • Legacy Issue Number: 10561
  • Status: open  
  • Source: SAIC ( Jim Bonang)
  • Summary:

    The Object Constraint Language (OCL) is an integral part of the Unified Modeling Language (UML) and is often used separately as a general constraint specification language in software development tools. For example, OCL is incorporated in the Generic Modeling Environment (GME) developed by the Institute of Software Integrated Systems (ISIS) of Vanderbilt University (http://www.isis.vanderbilt.edu/default.asp The GME implementation extends the OCL standard to include Regular Expressions. A Regular Expression is a pattern that describes (or matches) a set of strings where the pattern is itself a string and conforms to a specific syntax. Regular Expressions are ideal for expressing format constraints on OCL String values. Moreover, Regular Expressions are widely used, familiar to many software developers and complement the OCL’s already powerful constraint specification syntax. Unfortunately, Regular Expressions are not currently supported in OCL Version 2.0. Augmenting the OCL standard with Regular Expressions will improve OCL’s constraint specification capabilities for String values with a powerful, familiar notation and would also codify existing practice as manifested in tools such as GME. Please consider the inclusion of Regular Expression support in future releases of the Object Constraint Language (OCL) specification.

  • Reported: OCL 2.0 — Wed, 3 Jan 2007 05:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

Section: 11.5.1

  • Key: OCL25-59
  • Legacy Issue Number: 8660
  • Status: open  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    If /(r:Real):Real then shouldn't a constraint be added to the definition that the value of self divided by r as long as r<>0? A number divided by 0 is not a real number.

  • Reported: OCL 2.0b2 — Tue, 29 Mar 2005 05:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

Satisfaction of Operation Specifications

  • Key: OCL25-44
  • Legacy Issue Number: 6548
  • Status: open  
  • 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: Change Definition A.34 to allow the precondition to be weakened
    Rationale:
    It is commonly accepted that a program S satisfying an operation specification may weaken the precondition. This corresponds to Bertrand Meyer's view of software specifications as contracts between clients of a program and program provider. This is in accordance with the explanation following Def. A.34: "In other words, the program S accepts each environment satisfying the precondition as input and produces an environment that satisfies the postcondition." This sentence admits the possibility that S may be defined for environments not satisfying the precondition.
    However Def. A.34 requires S to be defined exactly on the environments for which the precondition holds. Therefore, we propose to replace Def. A.34 by:
    DEFINITION A.34 (SATISFACTION OF OPERATION SPECIFICATIONS)
    An operation specification with pre- and postconditions is satisfied by a program S in the sense of total correctness if the computation of S is a function fS such that the restriction of fS to the domain of R is a total function fS|_dom(R): dom(R) -> im(R) and graph(fS|_dom(R)) \subseteq R.
    Comment by Daniel Jackson (dnj@mit.edu)
    i'd be very wary of linking any particular notion of refinement to a modelling language. different circumstances might need different notions, and there's no reason that the language should be tied to one.
    i wonder, for example, if you've considered the difference between preconditions as disclaimers and preconditions as firing conditions.
    even for the standard notion of preconditions as disclaimers, your particular definition seems too narrow to me. requiring the program to be a function will rule out many reasonable implementations that are non-deterministic – hash tables, for example.

  • Reported: OCL 2.0b2 — Tue, 11 Nov 2003 05:00 GMT
  • Updated: Thu, 8 Oct 2015 14:11 GMT

Exception of strict evaluation (=)

  • Key: OCL25-43
  • Legacy Issue Number: 6541
  • Status: open  
  • Source: Anonymous
  • Summary:

    Author: Thomas Baar (thomas.baar@epfl.ch)
    Description: contradiction for evaluation of navigation expression
    Rationale: Suppose to have two classes A, B and an association with multiplicity
    0..1 on B
    between them.
    The invariant context
    A inv: self.b = self.b
    is evaluated for an instance of A not having an associated instance of B to
    i) true, when the expression self.b has the type Set(B), because self.b is evaluated to emptyset and emptyset = emptyset is evaluated to true
    ii) undef, when the expression self.b has the type B, because self.b is evaluated to undef and undef = undef is evaluated to undef thanks to strict evaluation of '='
    This is a contradiction since the expression self.b can be both of type set(B) and B!
    The examples also shows, that x = x is not a tautology unlike in almost all other logics including classical predicates logic. This is especially confusing because OCL claims to be based on classical predical logic!

  • Reported: OCL 2.0b2 — Mon, 10 Nov 2003 05:00 GMT
  • Updated: Thu, 8 Oct 2015 14:11 GMT

OCL Enumeration allInstances

  • Key: OCL25-50
  • Legacy Issue Number: 15420
  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    UML defines Enumeration.ownedLiteral as an ordered set. Surely allInstances() should therefore return an OrderedSet for an enumeration, and perhaps an ordinal property should be added by the Standard Library.

  • Reported: OCL 2.1 — Wed, 18 Aug 2010 04:00 GMT
  • Updated: Thu, 8 Oct 2015 14:11 GMT

OCL 2.1 Navigation of opposites

  • Key: OCL25-51
  • Legacy Issue Number: 15175
  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    UML models may explicitly declare that a Property is not navigable in order to simplify the complexity of the run-time representation of that Property.

    In an EMOF representation, the non-navigable Property is missing and so an OCL constraint cannot use it, even though the OCL constraint is used at compile-time rather than run-time.

    In a UML direction, a Property may be unnamed in one direction and the implicit naming of such opposites may be inadequate to permit unambiguous usage.

    QVT Relations 1.1 partially works around this by introducing an opposite(Property) declaration that may be used for Keys and PropertyTemplateItems.

    OCL, rather than QVT, should provide an ability to navigate a Property in an opposite direction.

    In the Abstract Syntax, OppositePropertyCallExp is required to capture the inverse navigation semantics of PropertyCallExp.

    In the Concrete Syntax, some alternate navigation operator is required. Perhaps "a.~b" indicates that "b" is in an inverted direction.

  • Reported: OCL 2.1 — Tue, 13 Apr 2010 04:00 GMT
  • Updated: Thu, 8 Oct 2015 14:11 GMT

OCL 2.1 Overload resolution

  • Key: OCL25-52
  • Legacy Issue Number: 15013
  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    Issue 6555 introduced the 'missing' Collection::=(Collection(T)) and Collection::=(Collection(T)).

    Issue 12948 changed Collection to conform to OclAny

    This means that "Set{} = 1" is no longer self-evidently invalid.

    According to the inherited OclAny::=(OclAny), "Set{} = 1" should be semantically legal and evaluate to false.

    But if Collection::=(Collection(T)) fully occludes OclAny::=(OclAny) ,"Set{} = 1" should be a semantic analysis failure and so invalid.

    Conversely "1 = Set{}" is OclAny::=(OclAny) and unambiguously false (until a Real::=(Real) overload is introduced to accommodate value rather object identity).

    OCL does not specify any policy for static or dynamic resolution of overloads.

    A Java-like policy of static determination of the most derived valid signature, then dynamic dispatch on the self object would seem appropriate, but:

    let c1 : OclAny = Set

    {1}, c2 : OclAny = Set{1}

    in c1 = c2

    must select OclAny::=(OclAny) as the static signature. Collection::=(Collection(T)) is not a derived operation with the same signature, so evaluation should use OclAny::=(OclAny) rather than Collection::=(Collection(T)) and give erroneous results swhen the collections are compared by object identity rather than collection kind and content.

    Either:
    OCL must specify multi-dimensional dynamic overload resolution on source and arguments

    Or:
    OCL should specify Java-like single-dimension dynamic overload resolution and the signature of derived operations such as Collection::=(Collection(T)) should be changed to match their inherited signature, i.e. to Collection::=(OclAny).

    [Or:
    All derived functionality must be folded into the base (OclAny) operation.]

  • Reported: OCL 2.1 — Sat, 30 Jan 2010 05:00 GMT
  • Updated: Thu, 8 Oct 2015 14:11 GMT

OCL 2.1 11.7.3 Missing OrderedSet::flatten overload

  • Key: OCL25-53
  • Legacy Issue Number: 14982
  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    Collection::flatten is overloaded for Bag, Sequence and Set but not for OrderedSet.

  • Reported: OCL 2.1 — Sun, 17 Jan 2010 05:00 GMT
  • Updated: Thu, 8 Oct 2015 14:11 GMT

OCL 2.3 7.5.3 Missing Association End name problems

  • Key: OCL25-48
  • Legacy Issue Number: 16161
  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    The 'clarified' text in OCL 2.3 for missing association ends, is still unclear.

    Problem 1: if multiple association ends acquire the same name, what happens? Suggest: they all acquire the same name and the resulting lookup up finds multiple names which should be diagnosed as an ambiguity and consequently a semantic error.

    Problem 2: if a missing association end is recursive, a class acquires a property with the same name as the class. Consequently invocation of e.g X.allInstances() for class X may encounter an ambiguity while resolving X. Is it self.X or global X? Suggest: auto-generated missing names may only be invoked via a navigation operator.

    Problem 3: does a derived association end get a resolution for a missing name? if OCL is used to define a number of helper properties that all return the same type, then provision of the missing 'opposites' results in unhelpful clutter at best. Suggest: missing names are not provided for derived association ends.

  • Reported: OCL 2.1 — Tue, 26 Apr 2011 04:00 GMT
  • Updated: Thu, 8 Oct 2015 14:11 GMT

Japan PAS Ballot Comment 26 (ocl2-rtf) 10.2 The Values Package, 1st paragraph

  • Key: OCL25-47
  • Legacy Issue Number: 16149
  • Status: open  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    UndefinedValue is explained in the text but is not included in any of the following diagrams. Add this element to the diagram.

  • Reported: OCL 2.1 — Wed, 20 Apr 2011 04:00 GMT
  • Updated: Thu, 8 Oct 2015 14:11 GMT

Issue nnnn: Japan PAS Ballot Comment 4 (ocl2-rtf)

  • Key: OCL25-49
  • Legacy Issue Number: 16127
  • Status: open  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Many figures shown by UML are not unified in line color and hatching color. Unify them.

  • Reported: OCL 2.1 — Wed, 20 Apr 2011 04:00 GMT
  • Updated: Thu, 8 Oct 2015 14:11 GMT

Complete OCL document must be a Package

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

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

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

    Avoiding conflicts requires some strong WFRs.

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

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

Coolection operations do not allow invalid inputs

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

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

    e.g including(object : T)

    pre: not object.oclIsInvalid()

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

Section: 8.3.5

  • Key: OCL25-38
  • Legacy Issue Number: 8636
  • Status: open  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    CollectionItem shows an association - item:OclExpression - in the fig. 10. CollectionLiteralExp shows an association in fig. 10 - parts:CollectionLiteralPart. This is an ordered association. CollectionRange shows two associations in fig. 10 - first:OclExpression and last:OclExpression. UML 2.0 (ptc/04-10-02) doesn't recognize Real as a primitive type but does use UnlimitedNatural. Need to add UnlimitedNatural as a primitive type. The attribute symbol for PrimitiveLiteralExp is not shown in fig. 10. TuppleLiteralExp shows an association in fig. 10 - tuplePart:VariableDeclaration. The statement that TupleLiteralExp "contains a name and a value for each part of the tuple type" implies attributes but these are not shown in fig. 10 or listed as attributes in the notation. Add a notation for VariableDeclaration.

  • Reported: OCL 2.0b2 — Fri, 25 Mar 2005 05:00 GMT
  • Updated: Thu, 8 Oct 2015 14:11 GMT

Section: 8.3

  • Key: OCL25-40
  • Legacy Issue Number: 8634
  • Status: open  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Fig. 6 does not agree with fig. 12 (pg 60) in the number of subclasses that inherit from OCLExpression. Fig. 6 nor the subsequene notation have any mention of LetExp. Please add this to Chapter 8.

  • Reported: OCL 2.0b2 — Fri, 25 Mar 2005 05:00 GMT
  • Updated: Thu, 8 Oct 2015 14:11 GMT

Section: 7.5.8

  • Key: OCL25-39
  • Legacy Issue Number: 8623
  • Status: open  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    In last paragraph on page 20 change the word "dotted" to "dashed" and in Fig. 3 change the dashed line denoting Dependency as an AssociationClass to a dotted line. This will agree with Fig. 1 example of an association class as well as the Notation described for AssociationClass on pg 45 of UML Superstructure (ptc/04-10-02).

  • Reported: OCL 2.0b2 — Thu, 24 Mar 2005 05:00 GMT
  • Updated: Thu, 8 Oct 2015 14:11 GMT

result value of an association end call expression (02)

  • Key: OCL25-41
  • Legacy Issue Number: 7536
  • Status: open  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    28. – [1] The result value of an association end call expression is the value bound
    – to the name of the association end to which it refers. Note that the
    – determination of the result value when qualifiers are present is specified in
    – section 5.4.3 ("Well-formedness rules for the AS-Domain-Mapping.exp-eval
    – Package").
    context AssociationEndCallExpEval inv:
    qualifiers->size() = 0 implies
    resultValue =
    source.resultValue.getCurrentValueOf(referredAssociationEnd.name)
    ==> ’name’ should be ’value’

  • Reported: OCL 2.0b2 — Thu, 10 Jun 2004 04:00 GMT
  • Updated: Thu, 8 Oct 2015 14:11 GMT

outgoingMessages results in the sequence of OclMessageValues

  • Key: OCL25-42
  • Legacy Issue Number: 7510
  • Status: open  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    – that have been in the output queue of the object between the last
    – postcondition snapshot and its associated precondition snapshot.
    context OclExpEval::outgoingMessages() : Sequence( OclMessageValue )
    pre: – none
    post:
    let end: LocalSnapshot =
    history->last().allPredecessors()>select( isPost = true )>first() in
    let start: LocalSnapshot = end.Pre in
    let inBetween: Sequence( LocalSnapshot ) = start.allSuccessors()>excluding( end.allSuccessors())>including(
    start ) in
    result = inBetween.outputQ->iterate (
    – creating a sequence with all elements present once
    m : oclMessageValue;
    res: Sequence( OclMessageValue ) = Sequence{}

    if not res->includes( m )
    then res->append( m )
    else res
    endif )
    ==> ’pre’ should be ’Pre’
  • Reported: OCL 2.0b2 — Thu, 10 Jun 2004 04:00 GMT
  • Updated: Thu, 8 Oct 2015 14:11 GMT

OCL 2.1 13.2 Reflection in OCL meta-models (correction to Issue 1 2951)

  • Key: OCL25-32
  • Legacy Issue Number: 14642
  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    13.1 states that "EssentialOCL is the package exposing the minimal OCL
    required to work with EMOF. EssentialOcl depends on the
    EMOF Package."

    13.1 states that "For convenience, because BasicOCL (respectively
    EssentialOCL) is - conceptually a subset of the complete OCL
    language for UML superstructure."

    MOF 06-01-01 defines EMOF and Figure 12.1 clearly shows a merge of
    Reflection. Therefore EssentialOCL has reflection.

    UML superstructure has almost everything, so BasicOCL has reflection.

    Issue 12951 provides the following revised text for 13.2. "The EMOF
    Reflection capability is not merged to the metamodel."
    This contradicts the above. If this is intended, OCL needs to redefine an
    EMOF as perhaps OMOF with the appropriate merges.

    Issue 9171 discusses why reflection is not available at the modelling level,
    but is available at the meta-modelling level.

    Presumably the intent is that MOF Reflection is present in the OCL
    meta-model, but is not necessarily present in the constrained models and so
    is not necessarily useable in OCL expressions. The revised text for Issue
    12951 should be revisited to align with Issue 9171.

  • Reported: OCL 2.1 — Tue, 17 Nov 2009 05:00 GMT
  • Updated: Thu, 8 Oct 2015 14:11 GMT

Special Types violate UML Generalization Semantics

  • Key: OCL25-33
  • Legacy Issue Number: 12795
  • Status: open  
  • Source: Zeligsoft, Inc. ( Christian Damus)
  • Summary:

    Special Types violate UML Generalization Semantics The definition of OclAny as a general of all classes in the UML model and of OclVoid and OclInvalid as specializations of all classes in the UML model are in violation of the semantics of generalization. Classifiers in the UML may only specialize other classifiers of the same or a conformant metaclass. From the description of Classifier in the UML: [3] A classifier may only specialize classifiers of a valid type. self.parents()->forAll(c | self.maySpecializeType(c)) [8] The query maySpecializeType() determines whether this classifier may have a generalization relationship to classifiers of the specified type. By default a classifier may specialize classifiers of the same or a more general type. It is intended to be redefined by classifiers that have different specialization constraints. Thus, it is not valid for OclAny (an instance of the AnyType metaclass) to be the general of any other class. Likewise, OclVoid and OclInvalid may not specialize any other class at all. This could be corrected in OclVoid and OclInvalid by redefining the maySpecializeType() query. For OclAny, the solution is not so straight-forward, as I don't see that OCL can redefine maySpecializeType() on behalf of the UML metaclasses; according to Section 7.4.4, it is not permitted to attempt to define an additional operation that clashes with an intrinsic operation of the context classifier.

  • Reported: OCL 2.0 — Sun, 24 Aug 2008 04:00 GMT
  • Updated: Thu, 8 Oct 2015 14:11 GMT

Section: A/2.5.5 Collection Operations - Table A.3

  • Key: OCL25-34
  • Legacy Issue Number: 12468
  • Status: open  
  • Source: Net.Orange (i.e. Net Dot Orange) ( Garr Lystad)
  • Summary:

    Table A.3 has several problems in the "Semantics" column: Row 2: Besides being hard to read, the expression seems to be wrong. There is no operator between the C and capital pi (which I assume to be a Cartesian product), and the "is not an element of" seems like it couldn't be right. Maybe I'm at fault, but I can't make any sense of it. Row 4: There's no entry here. How about " C 'intersect'

    {v}

    = Ø" Row 6: The operator should be intersection, not Cartesian product, that is the capital pi should is the wrong symbol here. Rows 8 & 9: First, there shouldn't be anything in row 9's semantics column since the other columns are all blank. Are the c's supposed to be the capital C's? I can't make any sense of the expression, which could be my problem, but I don't think so.

  • Reported: OCL 2.0 — Wed, 14 May 2008 04:00 GMT
  • Updated: Thu, 8 Oct 2015 14:11 GMT

Section: 10.3.1 LoopExpEval

  • Key: OCL25-35
  • Legacy Issue Number: 8648
  • Status: open  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    For the association bodyEvals the name of the associated class does not agree with the class name in fig. 20

  • Reported: OCL 2.0b2 — Mon, 28 Mar 2005 05:00 GMT
  • Updated: Thu, 8 Oct 2015 14:11 GMT

Section: 10.2.1 NameValueBinding

  • Key: OCL25-37
  • Legacy Issue Number: 8644
  • Status: open  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    NameValueBinding show an attribute and an association in fig. 16 that are not mentioned in the description/definition as are other attributes and associations in other descriptions/definitions.

  • Reported: OCL 2.0b2 — Mon, 28 Mar 2005 05:00 GMT
  • Updated: Thu, 8 Oct 2015 14:11 GMT

Section: 10.2

  • Key: OCL25-36
  • Legacy Issue Number: 8642
  • Status: open  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    The last paragraph on pg 94 that describes fig. 15 does not agree in names with the value names shown in fig. 15. StaticValue equates to the daya values the paragraph mentions and OclVoidValue apparently equates to "UndefinedValue." Since "UndefinedValue" and "OclVoidValue" both have the format of a class name this could lead to confusion. OclVoidValue, as later defined, is an undefined value so please change "UndefinedValue" in the open paragraph of this section.

  • Reported: OCL 2.0b2 — Mon, 28 Mar 2005 05:00 GMT
  • Updated: Thu, 8 Oct 2015 14:11 GMT

OCL 2.2 Add endlet to make grammar extensible

  • Key: OCL25-30
  • Legacy Issue Number: 15367
  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    Further to Bran Selic's observation on Issue 15357 that UML-specifics should not really impact the OCL core. This is easy for State via a ModelLiteralExp, but hard for Message which has associated concrete syntax.

    The expression grammar could be made extensible to accommodate custom/orthogonal infix, prefix, suffix, precedence if an expression could be parsed by the generic:

    expr ::= affixed (infix affixed)*
    affixed ::= prefix* suffixed
    suffixed ::= atom (suffix | '(' expr ')' | '[' expr ']' | '

    {' expr '}

    ' )*
    atom ::= '(' expr ')'

    name
    'if' expr 'then' expr 'else' expr 'endif'
    'let' expr 'in' expr 'endlet'

    The major problem is the missing 'endlet', which makes accurate parsing difficult and complex expressions easy for humans to misinterpret too.

    Suggest introduce the 'endlet' keyword.

  • Reported: OCL 2.1 — Fri, 9 Jul 2010 04:00 GMT
  • Updated: Thu, 8 Oct 2015 14:11 GMT

Issue 14593 (UML alignment: Attribute)

  • Key: OCL25-31
  • Legacy Issue Number: 14887
  • Status: open  
  • Source: Universidad Nacional del Litoral ( Javier Godoy)
  • Summary:

    There are references to Attribute (from Core) in sections 7.5 , 8.2, 8.3.2, 8.3.8, 8.3.9, 9.3, 9.4.1, 10.3.2, 10.4.1, 10.4.3 while the UML infrastructure defines Property instead of Attribute

  • Reported: OCL 2.1 — Sat, 19 Dec 2009 05:00 GMT
  • Updated: Thu, 8 Oct 2015 14:11 GMT

result value of an association class call expression

  • Key: OCL25-18
  • Legacy Issue Number: 7534
  • Status: open  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    26. – [1] The result value of an association class call expression is the value
    – bound to the name of the association class to which it refers. Note that the
    – determination of the result value when qualifiers are present is specified in
    – section 5.4.3 ("Well-formedness rules for the AS-Domain-Mapping.exp-eval
    – Package"). The operation getCurrentValueOf is an operation defined on
    – ObjectValue in section 5.2.3 ("Additional operations for the Values Package").
    context AssociationClassCallExpEval inv:
    qualifiers->size() = 0 implies
    resultValue =
    source.resultValue.getCurrentValueOf(referredAssociationClass.name)
    ==> ’name’ should be ’value’

  • Reported: OCL 2.0b2 — Thu, 10 Jun 2004 04:00 GMT
  • Updated: Thu, 8 Oct 2015 14:11 GMT

context VariableDeclaration::asAttribute() : Attribute

  • Key: OCL25-19
  • Legacy Issue Number: 7504
  • Status: open  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    post: result.constraint.bodyExpression = self.initExpression
    ==> should be:
    post:
    result.constraint.bodyExpression.oclAsType(OCLContextualClassifier::Expre
    ssionInOcl).bodyExpression
    = self.initExpression

  • Reported: OCL 2.0b2 — Thu, 10 Jun 2004 04:00 GMT
  • Updated: Thu, 8 Oct 2015 14:11 GMT

context Operation

  • Key: OCL25-20
  • Legacy Issue Number: 7501
  • Status: open  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    def: hasMatchingSignature(paramTypes: Sequence(Classifier)) : Boolean =
    – check that operation op has a signature that matches the given parameter lists
    let sigParamTypes: Sequence(Classifier) = self.allAttributes.type in
    (
    ( sigParamTypes->size() = paramTypes->size() ) and
    ( Set

    {1..paramTypes->size()}

    ->forAll ( i |
    paramTypes->at .conformsTo (sigParamTypes->at )
    )
    )
    )
    ==> ’self.allAttributes.type’ should be ’self.Parameter.type->asSequence()’

  • Reported: OCL 2.0b2 — Thu, 10 Jun 2004 04:00 GMT
  • Updated: Thu, 8 Oct 2015 14:11 GMT

Issue: OclAny operations of tuples and collections

  • Key: OCL25-21
  • Legacy Issue Number: 6573
  • Status: open  
  • Source: Anonymous
  • Summary:

    Description: The OCL specification does not allow operations like = or <> to be performed tuple values. It also forbids operations like oclIsKindOf and oclIsTypeOf on collections.
    Rationale: Add such operations to tuple and collection types signatures directly or by inheritance, will make the language more powerfull (e.g. a set of dogs can be casted to a set of animals).

  • Reported: OCL 2.0b2 — Tue, 11 Nov 2003 05:00 GMT
  • Updated: Thu, 8 Oct 2015 14:11 GMT

Issue: Grammar of OCL

  • Key: OCL25-22
  • Legacy Issue Number: 6565
  • Status: open  
  • Source: Anonymous
  • Summary:

    Description: The grammar presented in 4.3, which is in my opinion a semantic grammar, is not suitable to describe the syntax of OCL.
    Rationale: Introducing non-terminals like primary-expression, selection-expression, and operation-call-expression will solve all the problems and will reduce the number of ambiguities. Hence, the grammar contained in the specification will suffer less changes in order to be used to design and implement a deterministic parser. This is the case of the specifications for C, C++, Java, C#, and Prolog.

  • Reported: OCL 2.0b2 — Tue, 11 Nov 2003 05:00 GMT
  • Updated: Thu, 8 Oct 2015 14:11 GMT

Section: 10.1

  • Key: OCL25-17
  • Legacy Issue Number: 8641
  • Status: open  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Typo - Fig. 14, "Ocl-AbstractSyntax" should be "OCL-AbstractSyntax" to agree with naming format shown in other two packages

  • Reported: OCL 2.0b2 — Mon, 28 Mar 2005 05:00 GMT
  • Updated: Thu, 8 Oct 2015 14:11 GMT

OCL 2.2 Unlimited and Infinity

  • Key: OCL25-27
  • Legacy Issue Number: 15780
  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    OCL supports a '*' value for UnlimitedNatural in order to accommodate the
    full range of UML multiplicities.

    UnlimitedNatural conforms to Integer and Real, so that any UnlimitedNatural
    conversion must perform a run-time check in order to convert '*' to invalid.
    This conversion cannot be replicated in the reverse direction.

    Suggest that '*' be aligned with the conventional IEEE math notion of
    infinity, so that

    • and -* are valid values for Integer and Real. UnlimitedNatural is then a
      simple restriction of Integer which is a simple restriction of Real.
  • Reported: OCL 2.1 — Mon, 25 Oct 2010 04:00 GMT
  • Updated: Thu, 8 Oct 2015 14:11 GMT

OCL 2.2 Allow optional let type

  • Key: OCL25-28
  • Legacy Issue Number: 15712
  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    9.3.36 states "A variable declaration inside a let must have a declared type and an initial value."

    In the case of a Tuple literal assigned to a let variable, this requires that the tuple signature be entered twice.

    Suggest relaxing the requirement on a type to allow deduction from the initial value.

  • Reported: OCL 2.1 — Mon, 11 Oct 2010 04:00 GMT
  • Updated: Thu, 8 Oct 2015 14:11 GMT

OCL Constraint violation messages

  • Key: OCL25-29
  • Legacy Issue Number: 15412
  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    OCL supports definition of constraints, but it is difficult for tools to offer better error messages to a user than 'Constraint <constraint-name> violated for <constrained-element-name>'.

    It would be helpful if Constraints had an additional String-valued expression to be evaluated in the context of the error, so that tools could evaluate it and present the result to the user.

    Suggest add an optional argument to the (not-optional) constraint name. e.g.

    inv ConstraintName('Unable to find ' + self.target.name): ...

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

Issue nnnn: Japan PAS Ballot Comment 3 (ocl2-rtf)

  • Key: OCL25-25
  • Legacy Issue Number: 16126
  • Status: open  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Usage of upper/lower case letter is inconsistent with UML.
    For example, “Invariant”, “Precondition”, “Postcondition”, etc, in the text should be lower case letter. However, there are UML metamodel elements, such as “Classifier”.
    Especially, “collection type” in function flatten, p158, is lower case letter. If this is designated in lower case letter, it is difficult to understand the meaning of sentence. What about “collection type” L1 on 11.2.1? It is confusing whether those are metamodel elements or not.)
    It is required to be consistent with convention of UML upper case letter, since this standard is a family of UML, that is, it is required to use upper case letter only for UML/OCL Metamodel element.

  • Reported: OCL 2.1 — Wed, 20 Apr 2011 04:00 GMT
  • Updated: Thu, 8 Oct 2015 14:11 GMT

OCL 2.3 : Introduce Lambda functions

  • Key: OCL25-24
  • Legacy Issue Number: 16018
  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    OCL already has an implicit form of Lambda function in the intuitive declaration of collect(). This should be formalised and made more versatile. It doesn't seem to be possible to formulate a declaration for collect() without a Lambda Function:

    Sequence(T1)::collect(T2)(iterator : T1 | body : Lambda T1() : T2) : Sequence(T2)

    The mandatory collect body is a parameter-less Lambda function whose context-type is the class template parameter T1 and the return-type is the operation template parameter T2.

    For other iterators the declaration can be just OclExpression since the type is not exploited.

  • Reported: OCL 2.1 — Sat, 12 Feb 2011 05:00 GMT
  • Updated: Thu, 8 Oct 2015 14:11 GMT

OCL 2.3 max, min iterations

  • Key: OCL25-26
  • Legacy Issue Number: 15838
  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    It would be usefuil to have iterations analoguous to isUnique that compute max or min of a user-defined expression body over a collection.

  • Reported: OCL 2.1 — Sat, 20 Nov 2010 05:00 GMT
  • Updated: Thu, 8 Oct 2015 14:11 GMT

How does Set distinguish duplicate values?

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

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

    What is a duplicate?

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

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

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

    Suggest adding the obvious WFR.

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

    (count is already defined using "=")

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

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

OCL 2.1 12 Inconsistencies

  • Key: OCL25-14
  • Legacy Issue Number: 14595
  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    12.12: getClassifier and getPackage in text, but findClassifier and findPackage in signatures

  • Reported: OCL 2.1 — Sat, 31 Oct 2009 04:00 GMT
  • Updated: Thu, 8 Oct 2015 14:11 GMT

OCL 2.0 8.2 Collection Type name distinguishability

  • Key: OCL25-16
  • Legacy Issue Number: 12581
  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    The name of a Set (or other Collection) is defined to use the element type name.
    This is not consistent with the UML requirement for distinguishability of namespace
    memebers. (UML Infra 9.14.2 Namespace).

    OCL should permit, and perhaps require, that the name of a Collection use
    the element type qualified name, so that two sets of distinct element type
    are not folded into indistinguishable names.

    This is a problem for model to model transformation where the same class name can
    easily occur on both input and output meta-model, and where the requirement to reify
    collection types can easily result in Set(input::name) and Set(output::name) in
    the same namespace.

  • Reported: OCL 2.0 — Sat, 19 Jul 2008 04:00 GMT
  • Updated: Thu, 8 Oct 2015 14:11 GMT

OCL 2.2 Missing definition of navigation

  • Key: OCL25-9
  • Legacy Issue Number: 15790
  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    Dot and arrow navigation have implied definitions in the non-normative clause 7, but nothing in the normative clauses.

    Implicit collect is missing from clause 9, save for the throwaway final sentence "The mapping
    is not formally defined in this document but should be obvious."

    This mapping is far from obvious; if it was obvious it would be easy to define.

    In particular it is important to define that a static syntax determination is made to ensure that:

    anObject . feature => object navigation
    anObject -> feature => implicit collection (of anObject's static ordering/uniqueness) containing a non-null anObject
    aCollection -> feature (or iterator) => collection navigation
    aCollection . feature (or iterator) => implicit collect = aCollection -> collect(feature or iterator)
    (implicit source object implicit .) feature => object navigation
    (implicit source collection implicit ->) feature (or iterator) => collection navigation

    with the object/collection discrimination performed statically, so that the navigation
    algorithm is statically determinate; only the dynamic dispatch on self is subject to
    dynamic determination.

    The conformance of a collection to OclAny must never used to allow object navigation on a collection. This avoids a syntax ambiguity for "aCollection . name" between implicit collect and object navigation of a collection feature, or between implicit collect and object navigation of an object feature.

  • Reported: OCL 2.1 — Sun, 31 Oct 2010 04:00 GMT
  • Updated: Thu, 8 Oct 2015 14:11 GMT

OCL 2.2 UML-alignment of redefinition

  • Key: OCL25-10
  • Legacy Issue Number: 15218
  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    At the end of Section 7.4.6 OCL 2.2 says

    "For example, if class Employee redefines the age() : Integer operation of
    the Person class, a constraint may access the
    Person definition as in
    context Employee
    inv: self.age() <= self.Person::age()
    For clarity, the qualified form may only be used with an explicit source
    expression."

    and in Section 7.5.8:

    "Whenever properties are redefined within a type, the property of the
    supertypes can be accessed using the oclAsType()
    operation. Whenever we have a class B as a subtype of class A, and a
    property p1 of both A and B, we can write:"

    a clarifying example follows that is actually a disambiguation not a
    redefinition.

    In UML redefinition replaces an old definition with something else, which is
    not what the above
    excerpts imply.

    In the case of redefining "Person::age() : Integer". If the redefinition is
    "Employee::age() : UnlimitedNatural"
    the redefinition is compatible (valid UML), so perhaps self.age() being
    UnlimitedNatural and self.Person::age()
    being Integer just might be useful. But allowing them to invoke different
    operation bodies seems to violate
    UML.

    Suggest that use of a path qualification may select an occluded definition
    signature for static analysis,
    but may not use a redefined value or body.

    [This then avoids a need for the AST to persist the distinction between X::y
    as an explicit feature for
    static resolution or as an implicit feature for dynamic resolution. All
    features in the AST are identified by
    static analysis and evaluated by dynamic resolution.]

  • Reported: OCL 2.1 — Thu, 22 Apr 2010 04:00 GMT
  • Updated: Thu, 8 Oct 2015 14:11 GMT

OCL 2.1 Section 10 problems

  • Key: OCL25-11
  • Legacy Issue Number: 15037
  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    Section 10 is suffering seriously from lack of update and review.

    The old AssociationClassCall/AssociationEndCall/ModelPropertyCall spellings are in use throughout.

    OrderedSetValue is omitted throughout.

    UnlimitedNaturalExpValue is omitted throughout.

    TypeExpEval is omitted throughout thereby avoiding tackling the irregular semantics of the oclIsKindOf argument.

    'undefined' does not distinguish null and invalid and is variously undefined, void, UndefinedValue, OclVoidValue and UnspecifiedValue including a reference to UnspecifiedValueExp that does not exist. There should be just an OclVoidValue and an OclInvalidValue.

    OrderedSet is not used where elements are clearly unique e.g. Sequence(LocalSnapShot).

    OCL is regularly spelled ocl or Ocl as a non-word prefix.

    An Element::indexNr is imposed on all Collection elements. Surely a distinct OrderedCollectionValue intermediate value should use the stronger OrderedCollectionElement.

    It is not specified whether Element::indexNr indexes from 0 or 1 or indeed even monontonically.

    Figure 10.4 omits many

    {ordered}

    and

    {unique}

    constraints.

    Figure 10.4 omits LocalSnapShot.pred and succ.

    10.2.1 Element assserts that Element is a tuple NameValueBinding.

    10.2.1 OclMessageValue italicises the wrong use of 'name'.

    10.2.2 LocalSnapShot[1] refers to ispre rather than isPre.

    10.2.2 LocalSnapShot[2] asserts that the result of an implicit collect is a boolean (missing ->any).

    10.2.2 ObjectValue omits the doubly-linked list validity constraint

    10.2.2 TupleValue assserts that a NameValueBinding is an Element.

    10.2.3 SequenceTypeValue omits a constraint on the sequential validity of Element.indexNr

    10.2.3 LocalSnapShot uses notEmpty rather than nonEmpty()

    10.3 para 2 refers to a non-existent OclEvaluation class

    10.3 para 2 has erroneous figure references to 10.6,7 rather than 10.7,8

    10.3.2 OperationCallExpEval relies on UML semantics, but fails to resolve UML's unspecified behavioural variation point on operator overload resolution. See Issue 15013.

    10.3.2 OperationCallExpEval spells forAll as forall.

    10.3.2 CollectionRangeEval uses isOclType(Sequence(Integer)). Any such use of collection types was invalid in OCL 2.0. Use of a collection type is not valid concrete syntax in OCL 2.1/2. The resolution of 10439 for OCL 2.3 provides concrete syntax support, but the semantics remains undefined although perhaps intuitively obvious.

    As separately raised isOclType etc are incorrect spellings.

    The x .. y syntax could be used to advantage in places such as 10.3.3 CollectionRangeEval.

    The explicit iterator is unnecessary in for instance 10.2.2 TupleValue.

    Figure 10.14 has layout problems.

    Figure 10.14 shows instances <-> model associations for both Concrete and Abstract classes. The model for derived classes should be marked as derived.

    10.4.2 BooleanLiteralExpEval has an unresolved MOF/UML alignment.

    10.4.2 EvalEnvironment has a missing constraint on uniqueness of binding names.

    10.4.2 IfExpEval has missing and operators

    Generally: the constraints should be validated by an OCL checking tool.

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

No postcondition for NamedElement::getType() when self.oclIsKindOf(Namespace)

  • Key: OCL25-12
  • Legacy Issue Number: 14888
  • Status: open  
  • Source: Universidad Nacional del Litoral ( Javier Godoy)
  • Summary:

    9.4.2 NamedElement

    NamedElement, as defined by OCL, links to ModelElement (from Core) and has an operation getType(): Classifier

    Postconditions are given when the referred modelelelement is an instance of Classifier, VariableDeclaration or State.
    However, from subclause [4] of section 9.4.1 it follows that the referred modelelelement may also be an instance of Namespace.
    (let firstNamespace : ModelElement = lookupLocal( names->first() ).referredElement, where lookupLocal returns an OCL NamedElement)

    In the UML Infrastructure, Namespace specializes Core::NamedElement, which does not defines a type attribute (Core::TypedElement does)
    Namespace is a generalization of Classifier.

    At least, add:
    post: referredElement.oclIsKindOf(Namespace) implies
    result = – TBD: when aligning with UML 2.0

    Should it be result.oclIsUndefined() ?

  • Reported: OCL 2.1 — Sat, 19 Dec 2009 05:00 GMT
  • Updated: Thu, 8 Oct 2015 14:11 GMT

lookupProperty instead of lookupAttribute

  • Key: OCL25-13
  • Legacy Issue Number: 14885
  • Status: open  
  • Source: Universidad Nacional del Litoral ( Javier Godoy)
  • Summary:

    It reads: lookupAttribute

    It should read: lookupProperty

    Rationale: on section 8.3.8 an operation lookupProperty(attName : String) : Attribute
    is added to Classifier. The operation lookupAttribute is never defined in OCL or UML infra/superstructure (v2.1.2)

  • Reported: OCL 2.1 — Sat, 19 Dec 2009 05:00 GMT
  • Updated: Thu, 8 Oct 2015 14:11 GMT

OCL 2.3: Message support hard to consume

  • Key: OCL25-7
  • Legacy Issue Number: 16911
  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    The support for messages uniquely requires dedicated concrete syntax: ^, ^^, ?

    This makes provision of Essential OCL tooling without messages and Complete OCL tooling with messages hard.

    The operators are hard to remember and inconsistent with OCL where "forAll" is favoured over upside-down A.

    Suggest replace ,^,? by OclElement::hasSent(), OclElement::messages() and Message::Unspecified (possibly just null), so that Messages can be modularized as an Standard Library extension of additional types, operations and attributes only. No concrete syntax change.

  • Reported: OCL 2.1 — Wed, 14 Dec 2011 05:00 GMT
  • Updated: Thu, 8 Oct 2015 14:11 GMT

OCL 2.3 Collecting elemental collections

  • Key: OCL25-8
  • Legacy Issue Number: 16348
  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    collect and collectNested have irregular semantics that ignore the natural (outer) collection element type when used on nested collections:

    i.e Set{Set{1.0}}>collect(toString()) is Set{Set{1.0}}>collect(s : String | s.toString())

    so how might an iteration over the outer collection element type be performed?

    Presumably, for homegeneous collections, by explicitly specifying the iterator type as Set{Set{1.0}}>collect(s : Set(String) | s>size())

    Suggest: collect, collectNested specify that the implicit iterator type is the innermost collection type, and that an explicit type may
    specify a collection type that successfully iterates when all leaves of the tree are uniquely contained in a corrsponding iteration element
    of the iterator type, else the iteration is invalid.

    Can't see a solution for heterogeneous solutions

  • Reported: OCL 2.1 — Sat, 25 Jun 2011 04:00 GMT
  • Updated: Thu, 8 Oct 2015 14:11 GMT

Support zero and multiple context invariants

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

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

    Many users like to write grandiose truths:

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

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

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

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

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

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

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

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

    {....}

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

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

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

StateSpec for oclInState()

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

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

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

oclInState instead of oclIsInState

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

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

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

status of objects and tuples

  • Key: OCL25-3
  • Legacy Issue Number: 6530
  • Status: open  
  • Source: Ecole Polytechnique Federale de Lausanne ( Alfred Strohmeier)
  • Summary:

    Description: Provide a notation for the status of an object
    Rationale:
    It would be convenient to have a notation for denoting the status of an object. The type of such a status is a tuple. With such a notation it would be possible to compare the status of two objects or to compare the status of an object with a tuple. If not available, comparisons have to be performed on an attribute by attribute basis. Consider e.g.
    p, p1 and p2 are Person(s)
    p1.all = p2.all – the 2 persons have same status, i.e.
    is nicer and less error-prone than comparing all attributes:
    p1.firstName = p2.firstName and p1.name = p2.name and ...
    It would also be possible to compare with a tuple:
    p.all = Tuple = Tuple

    {firstName = 'Alfred', name = 'Strohmeier', ...}
  • Reported: OCL 2.0b2 — Mon, 10 Nov 2003 05:00 GMT
  • Updated: Thu, 8 Oct 2015 14:11 GMT

Missing mode precondition

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

    To Integer::mod all

    pre: i <> 0

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