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

All Issues

  • All Issues
  • Name: ocl2-rtf
  • Issues Count: 477

Issues Summary

Key Issue Reported Fixed Disposition Status
OCL25-227 Missing specification of equality operators for PrimitiveTypes OCL 2.4 open
OCL25-77 OCL 2.3 A.2.6 Collection conforms to OclAny contradiction OCL 2.1 open
OCL25-225 Possibility for paragraph comments /* ... */ not mentioned in 7.4.12 OCL 2.4 open
OCL25-224 Clarify LocalSnapshot / History OCL 2.4 open
OCL25-223 Clarify xxxEval classes OCL 2.4 open
OCL25-80 Japan PAS Ballot Comment 29 (ocl2-rtf) 10.2.4 Overview of the Values Package OCL 2.1 open
OCL25-33 Special Types violate UML Generalization Semantics OCL 2.0 open
OCL25-198 Inconsistent OclVoid::oclAsType return OCL 2.3.1 open
OCL25-222 How does bad allInstances() execute? OCL 2.4 open
OCL25-221 :: is not an invocable operator OCL 2.4 open
OCL25-220 Illegal side-effecting example OCL 2.4 open
OCL25-219 Add OclAny::toString() OCL 2.4 open
OCL25-75 OclVoid::oclIsKindOf/oclIsTypeOf should return true/false rather than invalid OCL 2.4 open
OCL25-218 Inconsistencies regarding OclAny OCL 2.4b1 open
OCL25-217 UML 2.5.1 embedded OCL syntax errors UML 2.5.1 open
OCL25-216 Missing Association Names not correct OCL 2.4 open
OCL25-83 OCL 2.3 - heterogeneous collections cannot be typed OCL 2.1 open
OCL25-128 OCL 2.1 12 Essential MOF support OCL 2.1 open
OCL25-126 OCL 2.1 12 Missing specification of initial and derived value constraints OCL 2.1 open
OCL25-154 Introduce a Safe Navigation Operator OCL 2.3.1 open
OCL25-215 OCL 2.4 reverts OCL 2.3's Issue 12953 resolution OCL 2.4 open
OCL25-214 Suspected typo OCL 2.4 open
OCL25-213 Multi-dimensional sortedBy OCL 2.4 open
OCL25-173 Section: 11.9.2 sortedBy OCL 2.0b2 open
OCL25-113 Invalid algorithm in definitions of sortedBy OCL 2.4 open
OCL25-27 OCL 2.2 Unlimited and Infinity OCL 2.1 open
UMLR-741 Are two identical bound templates the same? UML 2.5 open
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-199 parameters of the referredOperation OCL 2.0b2 open
OCL25-197 Indaequate Issue 15836 resultion of negative CollectionRange OCL 2.3.1 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-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-194 OCL 2.1 12 Definition Accessibility Semantics OCL 2.1 open
OCL25-188 result value of an association class call expression evaluation OCL 2.0b2 open
OCL25-190 OclUndefined / allInstances() clarification. 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-185 elements in the result value OCL 2.0b2 open
OCL25-184 result value of an if expression OCL 2.0b2 open
OCL25-183 Section: 8.3.1 OCL 2.0b2 open
OCL25-181 Section: 9.1 OCL 2.0b2 open
OCL25-182 Section: 8.3.8 OCL 2.0b2 open
OCL25-186 value of a collection item OCL 2.0b2 open
OCL25-180 Section: 10.2.3 ObjectValue OCL 2.0b2 open
OCL25-187 result value of an association end call expression OCL 2.0b2 open
OCL25-176 Section: 10.3.4 OclMessageArgEval OCL 2.0b2 open
OCL25-175 Container of additional operations OCL 2.0b2 open
OCL25-178 Section: 10.3 OCL 2.0b2 open
OCL25-177 Section: 10.3.2 AssociationEndCallExpEval OCL 2.0b2 open
OCL25-179 Section: 10.2.1 Element 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-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-170 OCL 2.1 12 Definition uses LetExp OCL 2.1 open
OCL25-174 OCL Collections applied to Properties OCL 2.0 open
OCL25-158 Vagueness about meaning of 0..1 multiplicity in OCL and UML OCL 2.1 open
OCL25-157 OCL 2.3 Pathname syntax does not allow access to hidden names OCL 2.1 open
OCL25-166 wrong parameter type for addNamespace operation call OCL 2.1 open
OCL25-167 OCL 2.1 Nested Collection Iteration 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-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-161 OCL 2.2 Generalisation of Issue 7341 PathNames OCL 2.1 open
OCL25-160 OCL 2.2 forAllAt suggestion OCL 2.1 open
OCL25-159 OCL Generics OCL 2.1 open
OCL25-153 Missing Real::= overload OCL 2.4 open
OCL25-152 Append/prepend on OrderedSet does not necessarily increase the collection size OCL 2.4 open
OCL25-147 Incomplete and missing well-formedness rules OCL 2.0b2 open
OCL25-150 Provide access to the sender of a message 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-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-136 Section: 10.3.4 OclMessageExpEval OCL 2.0b2 open
OCL25-137 Section: 10.3.2 NavigationCallExpEval OCL 2.0b2 open
OCL25-146 Satisfaction of Operation Specifications (2) OCL 2.0b2 open
OCL25-145 Issue: Comments OCL 2.0b2 open
OCL25-144 Issue: Parsing Tuple Types and Collection Types as Arguments OCL 2.0b2 open
OCL25-139 Section: 8.2 OCL 2.0b2 open
OCL25-138 Section: 8.3.4 OCL 2.0b2 open
OCL25-141 parameters of the referredOperation OCL 2.0b2 open
OCL25-140 result value of an association end call expression OCL 2.0b2 open
OCL25-143 The notation when nesting "if then else" is too verbose OCL 2.0b2 open
OCL25-142 Add an import statement to OCL files (with package - endpackage block) OCL 2.0b2 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-127 OCL 2.1 11.7.3 OrderedSet addition well-formedness rules OCL 2.1 open
OCL25-129 OCL 2.1 12 Incompleteness 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-119 Align OCL with out/inout UML Operation Parameters OCL 2.3.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-122 OCL 2.3 Introduce a reserved OclSelf template parameter 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-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-118 Align OCL bodyExpression and UML bodyCondition OCL 2.3.1 open
OCL25-117 Conflicting String::indexOf postConditions OCL 2.4 open
OCL25-116 Example of collect in terms of iterate is not flattened OCL 2.4 open
OCL25-110 Additional annotations in the OCL Standard Library OCL 2.0b2 open
OCL25-109 Issue: Signature of Environment OCL 2.0b2 open
OCL25-115 indentified OCL 2.4 open
OCL25-111 Support zero argument iterations OCL 2.1 open
OCL25-114 Add isInteger/isReal OCL 2.4 open
OCL25-112 i/r typo OCL 2.4 open
OCL25-108 The notation when nesting "if then else" is too verbose OCL 2.0b2 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-105 OCL Constraints in many levels OCL 2.0b2 open
OCL25-104 number of elements in the result value OCL 2.0b2 open
OCL25-99 Redundant CollectionLiteralExp::kind complicates collection type extension OCL 2.0 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-96 OCL 2.1 12 UML alignment OCL 2.1 open
OCL25-100 Provide the list of reflective MOF operations that are available OCL 2.0 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-84 OCL 2.3.TupleType semantics and AST OCL 2.1 open
OCL25-95 OCL 2.1 Inadequate definition of run-time meta-model 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-87 OCL 2.2: Section: 7.5.3 Clarification required for Qualifying association ends with association names OCL 2.1 open
OCL25-90 OCL 2.2 Clarity of qualified path names OCL 2.1 open
OCL25-86 OCL 2.2 OclState, State, StateExp, StateExpCS, StateValue and StateExpEval OCL 2.1 open
OCL25-89 OCL 2.2 Correction to Issue 9796 for AssociationEndCall OCL 2.1 open
OCL25-85 OCL Stereotypes OCL 2.1 open
OCL25-88 OCL 2.2 OclState and oclIsInState 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-78 OCL parsed OCL string literal 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-72 Error in OCL 2.4 spec OCL 2.1 open
OCL25-79 OCL 2.3 Enumeration::allInstances() does not return instances 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-71 Obsolete implicit cast to Bag OCL 2.4 open
OCL25-61 Section: 10.4.3 IntegerLiteralExpEval OCL 2.0b2 open
OCL25-63 Section: 10.3.5 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-70 Introduce a "tuplejoin" operator OCL 2.0b2 open
OCL25-69 Satisfaction of Operation Specifications (3) OCL 2.0b2 open
OCL25-64 Section: 9.3 CollectionLiteralPartsCS OCL 2.0b2 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-68 compliance points strategies OCL 2.0b2 open
OCL25-67 Allow defining standard library functions OCL 2.0b2 open
OCL25-60 inclusion of Regular Expression support OCL 2.0 open
OCL25-59 Section: 11.5.1 OCL 2.0b2 open
OCL25-55 Mismatch between the definition of operators in, e.g., Section 11.7.1 and i OCL 2.0 open
OCL25-57 Section: A.3.2.2 Syntax and Semantics of Postconditions (03) OCL 2.0 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-54 OCL 2.1 11.7: Clarifying Collection Well-formedness rules OCL 2.1 open
OCL25-46 Complete OCL document must be a Package OCL 2.3.1 open
OCL25-44 Satisfaction of Operation Specifications OCL 2.0b2 open
OCL25-43 Exception of strict evaluation (=) OCL 2.0b2 open
OCL25-48 OCL 2.3 7.5.3 Missing Association End name problems OCL 2.1 open
OCL25-49 Issue nnnn: Japan PAS Ballot Comment 4 (ocl2-rtf) 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-52 OCL 2.1 Overload resolution OCL 2.1 open
OCL25-51 OCL 2.1 Navigation of opposites OCL 2.1 open
OCL25-53 OCL 2.1 11.7.3 Missing OrderedSet::flatten overload OCL 2.1 open
OCL25-45 Coolection operations do not allow invalid inputs OCL 2.4 open
OCL25-50 OCL Enumeration allInstances OCL 2.1 open
OCL25-35 Section: 10.3.1 LoopExpEval OCL 2.0b2 open
OCL25-39 Section: 7.5.8 OCL 2.0b2 open
OCL25-38 Section: 8.3.5 OCL 2.0b2 open
OCL25-40 Section: 8.3 OCL 2.0b2 open
OCL25-36 Section: 10.2 OCL 2.0b2 open
OCL25-37 Section: 10.2.1 NameValueBinding 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-31 Issue 14593 (UML alignment: Attribute) OCL 2.1 open
OCL25-34 Section: A/2.5.5 Collection Operations - Table A.3 OCL 2.0 open
OCL25-30 OCL 2.2 Add endlet to make grammar extensible OCL 2.1 open
OCL25-42 outgoingMessages results in the sequence of OclMessageValues OCL 2.0b2 open
OCL25-41 result value of an association end call expression (02) OCL 2.0b2 open
OCL25-23 How does Set distinguish duplicate values? OCL 2.3.1 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-24 OCL 2.3 : Introduce Lambda functions OCL 2.1 open
OCL25-25 Issue nnnn: Japan PAS Ballot Comment 3 (ocl2-rtf) OCL 2.1 open
OCL25-26 OCL 2.3 max, min iterations OCL 2.1 open
OCL25-17 Section: 10.1 OCL 2.0b2 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-19 context VariableDeclaration::asAttribute() : Attribute OCL 2.0b2 open
OCL25-18 result value of an association class call expression OCL 2.0b2 open
OCL25-20 context Operation OCL 2.0b2 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-9 OCL 2.2 Missing definition of navigation 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-16 OCL 2.0 8.2 Collection Type name distinguishability OCL 2.0 open
OCL25-14 OCL 2.1 12 Inconsistencies OCL 2.1 open
OCL25-10 OCL 2.2 UML-alignment of redefinition OCL 2.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
OCL231-38 Lack of features commonly used in OCL UML 1.1 OCL 2.3.1 Resolved closed
OCL231-37 Issue nnnn: Japan PAS Ballot Comment 13 (ocl2-rtf) - Section 8.3.1 OclExpression (l16, p44) OCL 2.3 OCL 2.3.1 Resolved closed
OCL23-40 toLowerCase referred to as toLower (similarly for toUpperCase) OCL 2.2 OCL 2.3 Resolved closed
OCL21-354 Section 8.3.9 of the final Adopted Version of the OCL 2.0 Spec OCL 2.0b1 OCL 2.1 Resolved closed
OCL23-39 Role 'collectionTypes' should be 'collectionType' OCL 2.1 OCL 2.2 Resolved closed
OCL24-13 Problems with OCL definition of Package::makesVisible OCL 2.3.1 OCL 2.4 Resolved closed
OCL21-353 Section: A/2.3 Enumeration Types OCL 2.0 OCL 2.1 Resolved closed
OCL23-19 OCL 2.1 12 Typos OCL 2.1 OCL 2.3 Resolved closed
OCL23-18 OCL 2.1 12.2.3 Incomplete resolution of Issue 9796 for attrOrAssocContextCS OCL 2.1 OCL 2.3 Resolved closed
OCL23-26 OCL 2.1 11.2 Conflicting {OclVoid, OclInvalid}::{oclIsTypeOf, oclIsKindOf, oclAsType} semantics OCL 2.2 OCL 2.3 Resolved closed
OCL23-25 OCL 2.1 Implicit Conversion to Collection Literal OCL 2.2 OCL 2.3 Resolved closed
OCL23-29 String.equalsIgnoreCase(String) should result in Boolean OCL 2.2 OCL 2.3 Resolved closed
OCL23-28 OCL 2.1 11.2.3 Navigated Implicit Conversion to Collection Literal OCL 2.2 OCL 2.3 Resolved closed
OCL23-24 OCL 2.1 11.2.5 Numeric = and <> operations should compare values rather than objects OCL 2.2 OCL 2.3 Resolved closed
OCL23-27 OCL 2.1 8.3.8 OclInvalid::allInstances OCL 2.2 OCL 2.3 Resolved closed
OCL23-23 wrong variable name OCL 2.1 OCL 2.3 Resolved closed
OCL23-22 Undefined operation tail() on p 130 OCL 2.1 OCL 2.3 Resolved closed
OCL23-17 OCL 2.1 12.2.5 named-self classifierContextDeclCS OCL 2.1 OCL 2.3 Resolved closed
OCL23-21 Undefined operation tail() OCL 2.1 OCL 2.3 Resolved closed
OCL23-20 Undefined operation tail() OCL 2.1 OCL 2.3 Resolved closed
OCL231-36 The t should be subscripted next to the equal sign OCL 2.3 OCL 2.3.1 Resolved closed
OCL231-35 Comparison operators don't exist for Boolean OCL 2.3 OCL 2.3.1 Resolved closed
OCL231-14 Issue nnnn: Japan PAS Ballot Comment 9 (ocl2-rtf) Section 7.4.8 OCL 2.3 OCL 2.3.1 Resolved closed
OCL231-13 Issue nnnn: Japan PAS Ballot Comment 8 (ocl2-rtf) Section 10.3.2 OperationCallExpEval P127 OCL 2.3 OCL 2.3.1 Resolved closed
OCL231-22 Japan PAS Ballot Comment 24 (ocl2-rtf) 10.1 Introduction OCL 2.3 OCL 2.3.1 Resolved closed
OCL231-21 Japan PAS Ballot Comment 23 (ocl2-rtf) 10 Semantics Described Using UML OCL 2.3 OCL 2.3.1 Resolved closed
OCL231-19 Japan PAS Ballot Comment 18 (ocl2-rtf) OCL 2.3 OCL 2.3.1 Resolved closed
OCL231-18 Japan PAS Ballot Comment 17 (ocl2-rtf) Section 9.3.4 simpleNameCS OCL 2.3 OCL 2.3.1 Resolved closed
OCL231-12 Issue nnnn: Japan PAS Ballot Comment 7 (ocl2-rtf) Section 7.4.5 table 7.3 OCL 2.3 OCL 2.3.1 Resolved closed
OCL231-11 Issue nnnn: Japan PAS Ballot Comment 6 (ocl2-rtf) OCL 2.3 OCL 2.3.1 Resolved closed
OCL231-20 Issue from PAS Ballot comment for ISO/IEC DIS 19507 Section 9.3.29 OperationCallExpCS OCL 2.3 OCL 2.3.1 Resolved closed
OCL231-15 Issue nnnn: Japan PAS Ballot Comment 10 (ocl2-rtf) Section 7.4.9 list of keywords OCL 2.3 OCL 2.3.1 Resolved closed
OCL231-17 Japan PAS Ballot Comment 16 (ocl2-rtf) - Section 9.3.3 VariableExpCS OCL 2.3 OCL 2.3.1 Resolved closed
OCL231-16 Issue nnnn: Japan PAS Ballot Comment 11 (ocl2-rtf) p 35 line 1 OCL 2.3 OCL 2.3.1 Resolved closed
OCL23-5 OCL 2.0, 2.1 Loop iterators are not ordered and other inconsistencies OCL 2.1 OCL 2.3 Resolved closed
OCL23-4 OCL 2.0, 2.1 inconsistent definition of null and invalid OCL 2.1 OCL 2.3 Resolved closed
OCL23-13 OCL 2.1 7.4.7 Inconsistent Operator Associativity and Precedence OCL 2.1 OCL 2.3 Resolved closed
OCL23-12 OCL 2.1 Resolution of missing Concrete Syntaxes and Reserved Words OCL 2.1 OCL 2.3 Resolved closed
OCL23-3 Missing specification of UnlimitedNatural OCL 2.1 OCL 2.3 Resolved closed
OCL23-2 Erroneous operation names 'isOclType' and 'asOclType' OCL 2.1 OCL 2.3 Resolved closed
OCL23-1 [OCL-2.1 RTF] Transitive closure operator OCL 2.1 OCL 2.3 Resolved closed
OCL23-14 OCL 2.1 7.4.9 true, self, Bag and String are not reserved words OCL 2.1 OCL 2.3 Resolved closed
OCL23-9 Inconsistent lookup for underscored symbols OCL 2.1 OCL 2.3 Resolved closed
OCL23-8 OCL 2.1 Inconsistent implementation of Issue 6532 and contradictory resolution of Issues 7341 and 10437 OCL 2.1 OCL 2.3 Resolved closed
OCL23-16 OCL 2.1 9.3 Missing TypeLiteralExpCS OCL 2.1 OCL 2.3 Resolved closed
OCL23-15 OCL 2.1 9.3 Inferred TupleLiteralExp part type OCL 2.1 OCL 2.3 Resolved closed
OCL23-11 OCL 2.0 and 2.1 Section 9.3 CollectionRangeCS incorrect operator spelling OCL 2.1 OCL 2.3 Resolved closed
OCL23-10 OCL 2.1 Incomplete resolution 9913 InvalidLiteralExpCS and NullLiteralExpCS OCL 2.1 OCL 2.3 Resolved closed
OCL23-7 OCL 2.0 Inadequate Headings and PDF index OCL 2.1 OCL 2.3 Resolved closed
OCL23-6 OCL 2.0, 2.1 Inaccurate well-formedness constraints for IteratorExp OCL 2.1 OCL 2.3 Resolved closed
OCL231-33 Prime symbol lacking in the explanation preceding the formula OCL 2.3 OCL 2.3.1 Resolved closed
OCL231-32 Confusing usage of the "precedes" symbol for generalization hierarchy OCL 2.3 OCL 2.3.1 Resolved closed
OCL231-29 Japan PAS Ballot Comment 34 (ocl2-rtf) 13.3 Diagrams figure 13.8 OCL 2.3 OCL 2.3.1 Resolved closed
OCL231-28 Japan PAS Ballot Comment 33 (ocl2-rtf) 13.3.3 String page 144 OCL 2.3 OCL 2.3.1 Resolved closed
OCL231-25 Japan PAS Ballot Comment 28 (ocl2-rtf) 10.2.3 Additional Operations for the Values Package OCL 2.3 OCL 2.3.1 Resolved closed
OCL231-24 Japan PAS Ballot Comment 27 (ocl2-rtf) Section 10.2.1 Definitions of Concepts for the Values Package OCL 2.3 OCL 2.3.1 Resolved closed
OCL231-30 Use of the word meta OCL 2.3 OCL 2.3.1 Resolved closed
OCL231-26 Japan PAS Ballot Comment 30 (ocl2-rtf) 10.3 The Evaluations Package, 2nd paragraph OCL 2.3 OCL 2.3.1 Resolved closed
OCL231-31 on page 153 oclIsInState is used instead of oclInState OCL 2.3 OCL 2.3.1 Resolved closed
OCL231-23 Japan PAS Ballot Comment 25 (ocl2-rtf) 10.1 Introduction, 3rd and 4th paragraphs OCL 2.3 OCL 2.3.1 Resolved closed
OCL231-27 Japan PAS Ballot Comment 31 (ocl2-rtf): 10.3.1 Definitions of Concepts for the Evaluations Package OCL 2.3 OCL 2.3.1 Resolved closed
OCL231-34 Unbalanced parenthesis in the formula OCL 2.3 OCL 2.3.1 Resolved closed
OCL23-33 OCL 2.2 UML Alignment of association names OCL 2.2 OCL 2.3 Resolved closed
OCL23-32 OCL 2.2 11.5.3 What is a locale? OCL 2.2 OCL 2.3 Resolved closed
OCL23-31 OCL 2.2 11.7.1 Why must + be commutative for Collection::sum() OCL 2.2 OCL 2.3 Resolved closed
OCL23-30 OCL 2.2 11.7.1 Why must + be associative for Collection::sum() OCL 2.2 OCL 2.3 Resolved closed
OCL23-37 OCL 2.3 Ballotted: Retracting resolutions for Issue 10439/13076 OCL 2.2 OCL 2.3 Resolved closed
OCL23-36 toLowerCase() declared as returning Integer OCL 2.2 OCL 2.3 Resolved closed
OCL23-34 the use of the keyword 'attr' OCL 2.2 OCL 2.3 Resolved closed
OCL23-38 The opertion "collect" is confused with the operation "reject" OCL 2.2 OCL 2.3 Resolved closed
OCL23-35 Definition for symmetric difference is wrong OCL 2.2 OCL 2.3 Resolved closed
OCL231-7 US PAS Ballot Comment 3 (ocl2-rtf) paragraph 1 OCL 2.3 OCL 2.3.1 Resolved closed
OCL231-6 US PAS Ballot Comment 2 (ocl2-rtf) References OCL 2.3 OCL 2.3.1 Resolved closed
OCL231-2 Issue on Alignment of next OCL version and references UML 2.4/ MOF 2.4 OCL 2.3 OCL 2.3.1 Resolved closed
OCL231-5 US PAS Ballot Comment 1 OCL 2.3 OCL 2.3.1 Resolved closed
OCL231-4 oclIsInState() OCL 2.3 OCL 2.3.1 Resolved closed
OCL231-1 OCL 2.3 Incomplete CollectionRange well-formedness rules OCL 2.3 OCL 2.3.1 Resolved closed
OCL231-10 Issue nnnn: Japan PAS Ballot Comment 5 (ocl2-rtf) OCL 2.3 OCL 2.3.1 Resolved closed
OCL231-9 Issue nnnn: Japan PAS Ballot Comment 2 (ocl2-rtf) OCL 2.3 OCL 2.3.1 Resolved closed
OCL231-3 typo in ptc/2010-11-42 and pas/2010-08-02 OCL 2.3 OCL 2.3.1 Resolved closed
OCL231-8 Japan PAS Ballot Comment 1 (ocl2-rtf) OCL 2.3 OCL 2.3.1 Resolved closed
OCL21-347 Exact type of Set{} and missing Set(MyType){} literal definitions OCL 2.0 OCL 2.1 Resolved closed
OCL21-346 Use of simple quotes and double quotes in strings OCL 2.0 OCL 2.1 Resolved closed
OCL21-339 Missing definition of of iterators for OrderedSets OCL 2.0 OCL 2.1 Resolved closed
OCL21-338 Type of a type expression OCL 2.0 OCL 2.1 Resolved closed
OCL21-345 Use of MOF reflection in EssentialOCL should be clarified OCL 2.0 OCL 2.1 Resolved closed
OCL21-344 No way to represent type parameters in the standard library OCL 2.0 OCL 2.1 Resolved closed
OCL21-336 OCL 2.0 8.2 Collection Type packaging OCL 2.0 OCL 2.1 Resolved closed
OCL21-335 Section: A.3.2.2 Syntax and Semantics of Postconditions OCL 2.0 OCL 2.1 Resolved closed
OCL21-342 Making OclAny denote any object OCL 2.0 OCL 2.1 Resolved closed
OCL21-337 OCL 2.0: CollectionType constraint for invalid elements is incorrect OCL 2.0 OCL 2.1 Resolved closed
OCL21-341 Clarify the common supertype of Bag and Sequence OCL 2.0 OCL 2.1 Resolved closed
OCL21-340 The operation asSet, asSequence, asBag and asOrderedSet missing for OrderedSets OCL 2.0 OCL 2.1 Resolved closed
OCL21-334 Section: A.3.1.2 Semantics of Expressions OCL 2.0 OCL 2.1 Resolved closed
OCL21-343 Incosistency between UnlimitedInteger and UnlimitedNatural OCL 2.0 OCL 2.1 Resolved closed
OCL21-292 Dynamic typing with allInstances() OCL 2.0 OCL 2.1 Resolved closed
OCL21-291 missing closing parethesis inthese two expressions OCL 2.0 OCL 2.1 Resolved closed
OCL21-289 Usage of initialization and derivation constraints on the same property OCL 2.0 OCL 2.1 Resolved closed
OCL21-288 Collection element type serialization OCL 2.0 OCL 2.1 Resolved closed
OCL21-294 Section 8.2 InvalidType OCL 2.0 OCL 2.1 Resolved closed
OCL21-293 Section: 7.4.7, 7.4.9, 9.3.2 OCL 2.0 OCL 2.1 Resolved closed
OCL21-287 TypeType OCL 2.0 OCL 2.1 Resolved closed
OCL21-286 ownership of association ends does not matter for traversal in OCL OCL 2.0 OCL 2.1 Resolved closed
OCL21-284 11.7.1 OCL 2.0 OCL 2.1 Resolved closed
OCL21-283 11.2.5 (02) OCL 2.0 OCL 2.1 Resolved closed
OCL21-290 8.2.2 Well-formedness Rules for the Types Package OCL 2.0 OCL 2.1 Resolved closed
OCL21-281 11.8.1 OCL 2.0 OCL 2.1 Resolved closed
OCL21-280 11.2.4 (OclInvalid) - similar criticism as 11.2.3 OCL 2.0 OCL 2.1 Resolved closed
OCL21-282 11.2.5 OCL 2.0 OCL 2.1 Resolved closed
OCL21-285 Naming of Constraints in OCL OCL 2.0 OCL 2.1 Resolved closed
OCL21-274 Section: 7.4.9 OCL 2.0 OCL 2.1 Resolved closed
OCL21-273 Using "def" OCL 2.0 OCL 2.1 Resolved closed
OCL21-275 Section: 7.8 OCL 2.0 OCL 2.1 Resolved closed
OCL21-278 Section "IteratorExpCS" OCL 2.0 OCL 2.1 Resolved closed
OCL21-277 Section 9.2.2 OCL 2.0 OCL 2.1 Resolved closed
OCL21-279 11.2.3 OCL 2.0 OCL 2.1 Resolved closed
OCL21-276 Section 7.6.3 OCL 2.0 OCL 2.1 Resolved closed
OCL21-349 The following collection operations would be useful for the HL7 GELLO project: OCL 2.0 OCL 2.1 Resolved closed
OCL21-348 The concrete syntax given is extremely difficult to implement OCL 2.0 OCL 2.1 Resolved closed
OCL21-352 have tuple fields and let variables to have the declaration of their types explicity? OCL 2.0 OCL 2.1 Resolved closed
OCL21-351 type of the iterator variable is expected or not? OCL 2.0 OCL 2.1 Resolved closed
OCL21-350 doubts about the iterator variables OCL 2.0 OCL 2.1 Resolved closed
OCL21-295 CollectionType and CollectionKind OCL 2.0 OCL 2.1 Resolved closed
OCL21-307 no explanations about how to manipulate optional and multivalued attributes OCL 2.0 OCL 2.1 Resolved closed
OCL21-306 section 7.4.6 (p. 12) OCL 2.0 OCL 2.1 Resolved closed
OCL21-297 Section: A/1.1.1 Types OCL 2.0 OCL 2.1 Resolved closed
OCL21-296 last line on page 28 OCL 2.0 OCL 2.1 Resolved closed
OCL21-304 Section: A/1.2.4 System State OCL 2.0 OCL 2.1 Resolved closed
OCL21-303 Section: A/1.2.1 Objects OCL 2.0 OCL 2.1 Resolved closed
OCL21-302 Section: A/1.1.6 Generalization - editorial issues OCL 2.0 OCL 2.1 Resolved closed
OCL21-300 Section: A/1.1.5 Associations OCL 2.0 OCL 2.1 Resolved closed
OCL21-299 Section: A/1.1.5 Associations -- missing word OCL 2.0 OCL 2.1 Resolved closed
OCL21-301 Section: A/1.1.6 Generalization OCL 2.0 OCL 2.1 Resolved closed
OCL21-298 Section: A/1.1.5 Associations OCL 2.0 OCL 2.1 Resolved closed
OCL21-305 Section: A/2.2 Common Operations on All Types OCL 2.0 OCL 2.1 Resolved closed
OCL21-333 Section: A.2.5.8 Sequence Operations OCL 2.0 OCL 2.1 Resolved closed
OCL21-332 Section: A.3.1.2 Semantics of Expressions, Definition A.30 part ii OCL 2.0 OCL 2.1 Resolved closed
OCL21-327 Section 8.2.1 Type Conformance on page 37 OCL 2.0 OCL 2.1 Resolved closed
OCL21-330 Section: A.3.1.1 Syntax of Expressions OCL 2.0 OCL 2.1 Resolved closed
OCL21-329 Section: A.2.7 Type Hierarchy OCL 2.0 OCL 2.1 Resolved closed
OCL21-326 Section: A.2.6.1 Definition A.26 (Special Types) OCL 2.0 OCL 2.1 Resolved closed
OCL21-325 Section: A.2.6 Special Types OCL 2.0 OCL 2.1 Resolved closed
OCL21-322 Section: A.3.1.1 Syntax of Expressions OCL 2.0 OCL 2.1 Resolved closed
OCL21-324 Syntax of Expressions (second sentence after Definition A..29) OCL 2.0 OCL 2.1 Resolved closed
OCL21-323 Section: A.3.1.1 Syntax of Expressions (Definition A.29) OCL 2.0 OCL 2.1 Resolved closed
OCL21-331 Section: A.3.1.2 Semantics of Expressions OCL 2.0 OCL 2.1 Resolved closed
OCL21-328 Section 8.2 page 35 InvalidType OCL 2.0 OCL 2.1 Resolved closed
OCL21-321 Section: A.3.1.1 Syntax of Expressions OCL 2.0 OCL 2.1 Resolved closed
OCL21-311 Section: A/2.3 Enumeration Types -- editorial OCL 2.0 OCL 2.1 Resolved closed
OCL21-310 The constraint [1] on the TupleLiteralPart metaclass is overconstrained OCL 2.0 OCL 2.1 Resolved closed
OCL21-313 Section: A.2.5.2 Definition A.24 (Type Expressions) OCL 2.0 OCL 2.1 Resolved closed
OCL21-312 Section: Definition A.23 (Semantics of Navigation Operations) OCL 2.0 OCL 2.1 Resolved closed
OCL21-317 There are two instances of missing and misplaced parentheses OCL 2.0 OCL 2.1 Resolved closed
OCL21-316 A.2.5.5 Collection Operations OCL 2.0 OCL 2.1 Resolved closed
OCL21-320 Section: A.2.5.8 Sequence Operations OCL 2.0 OCL 2.1 Resolved closed
OCL21-319 Section: A.2.5.6 Set Operations Table A.4 OCL 2.0 OCL 2.1 Resolved closed
OCL21-309 OrderedSet collection OCL 2.0 OCL 2.1 Resolved closed
OCL21-318 Section: A.2.5.6 Set Operations OCL 2.0 OCL 2.1 Resolved closed
OCL21-314 Section: A.2.5.5 Collection Operations OCL 2.0 OCL 2.1 Resolved closed
OCL21-315 Section: A/2.5.5 Collection Operations - just before table A.3 OCL 2.0 OCL 2.1 Resolved closed
OCL21-308 The Tuple constructor is problematic OCL 2.0 OCL 2.1 Resolved closed
OCL21-270 Section: 7.3.4 OCL 2.0 OCL 2.1 Resolved closed
OCL21-269 Wrong subtyping of PropertyCallExp and NavigationCallExp OCL 2.0 OCL 2.1 Resolved closed
OCL21-268 inability to uniquely reference association ends OCL 2.0 OCL 2.1 Resolved closed
OCL21-267 Introduction and oclType() OCL 2.0 OCL 2.1 Resolved closed
OCL21-266 Circular imports OCL 2.0 OCL 2.1 Resolved closed
OCL21-272 Section: 7.5.9 OCL 2.0 OCL 2.1 Resolved closed
OCL21-271 Section: 8.3.5 OCL 2.0 OCL 2.1 Resolved closed
OCL21-248 sub evaluations (02) OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-247 sub evaluations OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-254 Section: 7.5.11 OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-253 Section: 7.5.9 OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-246 value of a collection range OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-245 value of a collection range OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-249 Section: 6.5.4.3 Combining Properties OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-243 result value of an attribute call expression OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-251 Section: 7.4.5 OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-252 Section: 7.5.3 OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-250 Section: 7.4 OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-244 result value of a collection literal expression evaluation OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-204 Issue: Syntax of Operation Call, Iterator, and Iterate Expressions OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-203 Issue: Abstract syntax tree OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-208 The notation for selecting elements should be more intuitive OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-207 The notation for testing the type of a metaclass is too verbose OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-206 Example with TupleType OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-211 Improve the notation when defining local variables OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-210 There is no simple way to invoke an "if then else" on a collection OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-209 notation for selecting unique element within a list should be more concise OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-216 Provide specific notational support when testing stereotypes OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-215 Suppress the usage of an Ocl prefix in standard library operations OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-202 Issue: Unspecified syntax and semantics for Integer, Real, and String OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-213 Allow implicit type casting to boolean when a boolean is expected OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-212 Allow applying iteration operations on single objects OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-214 Automatic casting between strings and enumeration values OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-217 Add a generic text formatter operator '% OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-205 The index seems incomplete OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-234 arguments of the return message of an ocl message expression OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-233 inv: model.sentSignal->size() = 1 implies OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-236 ’element’ should be ’elements’ OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-235 Only one of the attributes isPost and isPre may be true at the same time. OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-242 elements in a tuple value OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-232 arguments OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-240 The history of an object is ordered.(02) OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-241 The operation allPredecessors OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-239 history of an object is ordered. OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-238 ’Element’ should be ’NameValueBinding’ OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-237 ’element’ should be ’elements’ (02) OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-198 Add select/reject/collectNested to Collection OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-197 Exception of strict evaluation (queries) OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-201 Issue: Virtual machine OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-200 Clarify the UML semantics of IfExpEval OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-195 Exception of strict evaluation (implies) OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-196 Exception of strict evaluation (forAll, exists) OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-199 Clarify the semantics of forAll OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-265 Notation for accessing class operations is inconsistent OCL 2.0 OCL 2.1 Resolved closed
OCL21-264 Navigating across non navigable associations OCL 2.0 OCL 2.1 Resolved closed
OCL21-263 allInstances OCL 2.0 OCL 2.1 Resolved closed
OCL21-261 Section: 1 - 13 OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-260 Section: 11.9.3 & 11.9.4 OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-258 Section: 11.2.1 OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-257 Section: 10.2.2 LocalSnapshot OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-255 Section: 7.5.13 OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-262 The spec does not describes the syntax of integer, real or string literals OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-259 Section: 11.5.4 OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-256 Section: 7.6.2 OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-219 rewrite well-formedness OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-218 Make usage of tuples less complex and less verbose OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-225 sub evaluations (in the sequence bodyEvals) OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-224 context IfExpEval inv: OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-228 isSent attribute OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-227 ocl message expression OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-231 an iterate expression evaluation OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-230 missing ’inv:’ twice OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-222 1] The type of the attribute is the type of the value expression. OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-221 An additional attribute refParams lists all parameters of the referred OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-226 sub evaluations (in sequence bodyEvals) have different environment. OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-229 add ’and’ between both expression parts OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-223 context LocalSnapshot OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-220 context State::getStateMachine() : StateMachine OCL 2.0b2 OCL 2.1 Resolved closed
OCL24-12 Introduce selectByKind and selectByType operations OCL 2.3.1 OCL 2.4 Resolved closed
OCL24-11 Collection::min/max accumulator initialized as self.first() OCL 2.3.1 OCL 2.4 Resolved closed
OCL24-10 Collection::any() violates precondition if the collection is empty OCL 2.3.1 OCL 2.4 Resolved closed
OCL24-9 Inconsistent inclusion of source in closure results OCL 2.3.1 OCL 2.4 Resolved closed
OCL24-8 Clarify invalid propgation/conformance priority OCL 2.3.1 OCL 2.4 Resolved closed
OCL24-7 OclAny::oclAsType postcondition implies type change OCL 2.3.1 OCL 2.4 Resolved closed
OCL24-6 any iteration unsuitable for null Collection content OCL 2.3.1 OCL 2.4 Resolved closed
OCL24-5 non(not(X)) should be X OCL 2.3.1 OCL 2.4 Resolved closed
OCL24-4 Navigation from Association Classes does not conform to UML 2.4.1 OCL 2.3.1 OCL 2.4 Resolved closed
OCL24-3 ISO has changed the following normative references to its documents OCL 2.3.1 OCL 2.4 Resolved closed
OCL24-2 OCL String::indexOf OCL 2.3.1 OCL 2.4 Resolved closed
OCL24-1 OCL 2.3 OclInvalid::= is vague OCL 2.3.1 OCL 2.4 Resolved closed

Issues Descriptions

Missing specification of equality operators for PrimitiveTypes

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

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

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

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

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

OCL 2.3 A.2.6 Collection conforms to OclAny contradiction

  • Key: OCL25-77
  • Legacy Issue Number: 16487
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward 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: Tue, 10 Jan 2023 07:06 GMT

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

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

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

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

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

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

    For example:
    – this is a comment

    The two possibilities should be mentioned in 7.4.12.

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

Clarify LocalSnapshot / History

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

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

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

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

Clarify xxxEval classes

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

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

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

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

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

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

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: Sun, 10 Jul 2022 06:44 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: Sun, 9 Jan 2022 09:41 GMT

Inconsistent OclVoid::oclAsType return

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

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

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

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

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

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

How does bad allInstances() execute?

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

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

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

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

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

:: is not an invocable operator

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

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

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

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

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

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

Illegal side-effecting example

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

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

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

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

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

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

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

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

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

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

Add OclAny::toString()

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

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

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

    (OCL25-75 vaguely suggests toString()).

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

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

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

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

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

    ? oclIsKindof true for all types except OclIsInvalid.

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

Inconsistencies regarding OclAny

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

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

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

UML 2.5.1 embedded OCL syntax errors

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

    The new OCL for UML 2.5.1 seems not to have been checked by any tool; shame on you. There are two syntax errors:

    OpaqueExpression-only_in_or_return_parameters-specification makes use of ParameterDirectionKind::in but 'in' is a reserved word and so it must be escaped as in other similar constraints. Change to ParameterDirectionKind::'in'

    Lifeline-interaction_uses_share_lifeline-_specification has a Bag rather than Boolean argument for the final implies. Perhaps the select(...) should be followed by a ->notEmpty() or the select(...) could be an exists(...)

  • Reported: UML 2.5.1 — Tue, 5 May 2020 16:55 GMT
  • Updated: Tue, 5 May 2020 16:55 GMT

Missing Association Names not correct

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

    in UML the rules for distinguishable names are:

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

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

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

OCL 2.3 - heterogeneous collections cannot be typed

  • Key: OCL25-83
  • Legacy Issue Number: 16106
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward 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: Sat, 16 Feb 2019 20:02 GMT

OCL 2.1 12 Essential MOF support

  • Key: OCL25-128
  • Legacy Issue Number: 14596
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward 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: Sat, 19 Jan 2019 15:46 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 ( Dr. Edward 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: Sat, 19 Jan 2019 15:45 GMT

Introduce a Safe Navigation Operator

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

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

    In OCL it could be a pure syntax sugar:

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

    or perhaps an additional PropertyCallExp operator

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

OCL 2.4 reverts OCL 2.3's Issue 12953 resolution

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

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

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

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

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

Suspected typo

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

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

    test should be text

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

Multi-dimensional sortedBy

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

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

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

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

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

    However this has poor readability and ample opportunities for typos.

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

    sortedBy(Tuple

    {first=key1,second=key2}

    )

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

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

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

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: Sat, 20 Jan 2018 09:30 GMT

Invalid algorithm in definitions of sortedBy

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

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

    Invalid algorithm:

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

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

    Inconsistent use of < and >:

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

    Typos:

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

    SOLUTION:

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

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

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

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

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

    FURTHER SUGGESTIONS:

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

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

      {2, 2, 1}

      ->sortedBy(x|x) = Sequence

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

OCL 2.2 Unlimited and Infinity

  • Key: OCL25-27
  • Legacy Issue Number: 15780
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward 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, 7 Dec 2017 10:44 GMT

Are two identical bound templates the same?

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

    Consider: my general purpose library provides:

    mylib::Aggregate<T>

    My subsystems exploit this by drawing:

    mysub1::Aggregate<T -> String>
    mysub2::Aggregate<T -> String>

    and my application integrates the subsystems by drawing

    myapp::Aggregate<T -> String>

    Since each of the three Aggregates of String have different packages, oops, it would seem that they are different types and so cannot be passed interchangeably between subsystems.

    The above arises from the natural encoding of a graphical representation in which Aggregate<String> is drawn once per diagram/package and referenced many times. The package owns and so appropriates the shared type.

    In contrast, textual representations, in the absence of a typedef, elaborate Aggregate<String> for each reference. Each reference 'owns' the shared type, which is not appropriated by a prevailing package.

    (This has been a major problem for attempts to provide UML-aligned XMI serialization for OCL since e.g. there is obviously only one Set(String) but who owns it, who persists it, and how is it referenced? Eclipse OCL has prototyped a solution whereby a shared orphanage package is responsible for owning the singletons, but everyone persists their singletons. This incurs unpleasant costs in creating local orphanages during a serialization and destroying them again during loading. Struggling with this finally made me see that there is a fundamental UML limitation.)

    In similar scenarios where there is an ownership/reference dilemma, UML provides e.g. TemplateParameter::parameteredElement/ownedParameteredElement. Surely there should be a TypedElement::type/ownedType so that a TypedElement::ownedType can introduce a package-less type that is consequently shared by all similar introductions? Bloat could be avoided by one TypedElement::type referencing another TypedElement::ownedType. Alternatively a Package::sharedElements could contain local copies that are logically shared globally. (This could also solve the problem of everyone wanting their own Boolean PrimitiveType.)

  • Reported: UML 2.5 — Mon, 14 Aug 2017 07:31 GMT
  • Updated: Mon, 14 Aug 2017 10:52 GMT

OrderedSet::insertAt unclear for insert of existing element

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

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

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

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

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

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

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 ( Dr. Edward Willink)
  • Summary:

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

    "any" is specified as indeterminate.

    Non-determinism is a very bad language characteristic.

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

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

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

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

Are failures invalid?

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

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

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

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

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

Add % operator

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

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

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

    Suggest add Real::%

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

Generalize body/precondition/postcondition as named capabilities

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

    UML/OCL hardwire three capabilities of an Operation.

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

    Some users want frame conditions.

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

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

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

OCL 2.1 Feature Overloading Semantics are not defined

  • Key: OCL25-92
  • Legacy Issue Number: 14986
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward 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 ( Dr. Edward Willink)
  • Summary:

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

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

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

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

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

Support MyStereotype.allInstances()

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

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

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

    Stereotype.allInstances() is equivalent to

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

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

Wrong color for abstract syntax presentation

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

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

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

How indeterminate are asOrderedSet/asSequence?

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

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

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

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

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

Provide a Map of qualified associations

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

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

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

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

Make null-free collections the default

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

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

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

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

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

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

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

Indaequate Issue 15836 resultion of negative CollectionRange

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

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

    {1..size}

    ->forAll idiom.

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

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

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 ( Mr. 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

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 ( Dr. Edward 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

OCL 2.1 12 Definition Accessibility Semantics

  • Key: OCL25-194
  • Legacy Issue Number: 14591
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward 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

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

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

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

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

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

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

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

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

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.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

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: 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.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.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 Loop iterators are not ordered and other inconsistencies

  • Key: OCL25-168
  • Legacy Issue Number: 14639
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward 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 ( Dr. Edward 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.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 2.1 12 Definition uses LetExp

  • Key: OCL25-170
  • Legacy Issue Number: 14594
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward 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 Collections applied to Properties

  • Key: OCL25-174
  • Legacy Issue Number: 10787
  • Status: open  
  • Source: Dell Technologies ( Mr. 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

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

  • Key: OCL25-158
  • Legacy Issue Number: 15789
  • Status: open  
  • Source: Model Driven Solutions ( Mr. 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.3 Pathname syntax does not allow access to hidden names

  • Key: OCL25-157
  • Legacy Issue Number: 16044
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward 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

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.1 Nested Collection Iteration

  • Key: OCL25-167
  • Legacy Issue Number: 14851
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward 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

OCL 2.1 Parametric references

  • Key: OCL25-164
  • Legacy Issue Number: 15156
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward 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 ( Dr. Edward 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

OCL 2.2 Correction to Issue 9796 for isPre

  • Key: OCL25-163
  • Legacy Issue Number: 15232
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward 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 ( Dr. Edward 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.2 Generalisation of Issue 7341 PathNames

  • Key: OCL25-161
  • Legacy Issue Number: 15234
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward 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 forAllAt suggestion

  • Key: OCL25-160
  • Legacy Issue Number: 15710
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward 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 ( Dr. Edward 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

Missing Real::= overload

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

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

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

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

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

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

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

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

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

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

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

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

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

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

OCL 2: OrderedSet

  • Key: OCL25-151
  • Legacy Issue Number: 5971
  • Status: open  
  • Source: HL7 ( Mr. 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

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

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

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

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

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

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

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

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

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

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

Naming of Constraints in OCL (02)

  • Key: OCL25-133
  • Legacy Issue Number: 10786
  • Status: open  
  • Source: Dell Technologies ( Mr. 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 ( Mr. 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 11.7.3 OrderedSet addition well-formedness rules

  • Key: OCL25-127
  • Legacy Issue Number: 14980
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward 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.1 12 Incompleteness

  • Key: OCL25-129
  • Legacy Issue Number: 14598
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward 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

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

Align OCL with out/inout UML Operation Parameters

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

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

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

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

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

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

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

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

OCL 2.3 Introduce a reserved OclSelf template parameter

  • Key: OCL25-122
  • Legacy Issue Number: 16019
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward 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

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.2: AST is an ASG

  • Key: OCL25-123
  • Legacy Issue Number: 15387
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward 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 ( Dr. Edward 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 ( Dr. 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

Align OCL bodyExpression and UML bodyCondition

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

    OCL 12.10 awaits alignment with the UML 2.0 metamodel.

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

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

    Reinterpret the grammar

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

    such that

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

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

    [Allow multiple body declarations.]

    Thus

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

    and

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

    could be the specification of a UML operation

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

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

Conflicting String::indexOf postConditions

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

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

    Replace:

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

    by

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

    and move it to the second postcondition

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

Example of collect in terms of iterate is not flattened

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

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

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

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

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

indentified

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

    Change to identified

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

Support zero argument iterations

  • Key: OCL25-111
  • Legacy Issue Number: 19702
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward 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

Add isInteger/isReal

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

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

    Add isBoolean/toBoolean/toString

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

i/r typo

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

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

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

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

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 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

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

OCL 2.1 12 Definition Referencability Semantics

  • Key: OCL25-97
  • Legacy Issue Number: 14592
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward 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 ( Dr. Edward 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

OCL 2.1 12 UML alignment

  • Key: OCL25-96
  • Legacy Issue Number: 14593
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward 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

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

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.3.TupleType semantics and AST

  • Key: OCL25-84
  • Legacy Issue Number: 15920
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward 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

OCL 2.1 Inadequate definition of run-time meta-model

  • Key: OCL25-95
  • Legacy Issue Number: 14861
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward 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

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 ( Dr. Edward 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 ( Dr. Edward 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 ( Dr. Edward 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.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 ( Mr. 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 Clarity of qualified path names

  • Key: OCL25-90
  • Legacy Issue Number: 15219
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward 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

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

  • Key: OCL25-86
  • Legacy Issue Number: 15357
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward 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 Correction to Issue 9796 for AssociationEndCall

  • Key: OCL25-89
  • Legacy Issue Number: 15233
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward 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 Stereotypes

  • Key: OCL25-85
  • Legacy Issue Number: 15426
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward 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 OclState and oclIsInState

  • Key: OCL25-88
  • Legacy Issue Number: 15257
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward 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

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 ( Dr. Edward 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 parsed OCL string literal

  • Key: OCL25-78
  • Legacy Issue Number: 16370
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward 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

Missing/Poor definition of iterate()

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

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

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

    Suggest: Add iterate() to Section 11.

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

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

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

Reverse CollectionRange should be empty rather than invalid

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

    The clarification of Issue 15836 is too strong.

    For an empty collection it is im,portant that

    let s = Sequence{} in Sequence

    {1..s->size()}

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

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

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

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

  • Key: OCL25-79
  • Legacy Issue Number: 16168
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward 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 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

Obsolete implicit cast to Bag

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

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

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

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 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

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: 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

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

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

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

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

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

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

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

OCL 2.1 11.7: Clarifying Collection Well-formedness rules

  • Key: OCL25-54
  • Legacy Issue Number: 14576
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward 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

Complete OCL document must be a Package

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

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

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

    Avoiding conflicts requires some strong WFRs.

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

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

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 2.3 7.5.3 Missing Association End name problems

  • Key: OCL25-48
  • Legacy Issue Number: 16161
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward 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

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

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

OCL 2.1 Overload resolution

  • Key: OCL25-52
  • Legacy Issue Number: 15013
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward 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 Navigation of opposites

  • Key: OCL25-51
  • Legacy Issue Number: 15175
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward 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 11.7.3 Missing OrderedSet::flatten overload

  • Key: OCL25-53
  • Legacy Issue Number: 14982
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward 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

Coolection operations do not allow invalid inputs

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

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

    e.g including(object : T)

    pre: not object.oclIsInvalid()

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

OCL Enumeration allInstances

  • Key: OCL25-50
  • Legacy Issue Number: 15420
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward 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

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: 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

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: 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

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

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 ( Dr. Edward 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

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

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

OCL 2.2 Add endlet to make grammar extensible

  • Key: OCL25-30
  • Legacy Issue Number: 15367
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward 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

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

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

How does Set distinguish duplicate values?

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

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

    What is a duplicate?

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

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

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

    Suggest adding the obvious WFR.

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

    (count is already defined using "=")

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

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

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

OCL 2.3 : Introduce Lambda functions

  • Key: OCL25-24
  • Legacy Issue Number: 16018
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward 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

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 max, min iterations

  • Key: OCL25-26
  • Legacy Issue Number: 15838
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward 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

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 Allow optional let type

  • Key: OCL25-28
  • Legacy Issue Number: 15712
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward 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 ( Dr. Edward 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

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

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 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

OCL 2.3: Message support hard to consume

  • Key: OCL25-7
  • Legacy Issue Number: 16911
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward 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 ( Dr. Edward 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 ( Dr. Edward Willink)
  • Summary:

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

    Many users like to write grandiose truths:

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

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

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

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

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

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

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

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

    {....}

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

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

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

OCL 2.2 Missing definition of navigation

  • Key: OCL25-9
  • Legacy Issue Number: 15790
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward 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.1 Section 10 problems

  • Key: OCL25-11
  • Legacy Issue Number: 15037
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward 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.0 8.2 Collection Type name distinguishability

  • Key: OCL25-16
  • Legacy Issue Number: 12581
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward 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.1 12 Inconsistencies

  • Key: OCL25-14
  • Legacy Issue Number: 14595
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward 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.2 UML-alignment of redefinition

  • Key: OCL25-10
  • Legacy Issue Number: 15218
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward 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

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 ( Dr. Edward Willink)
  • Summary:

    To Integer::mod all

    pre: i <> 0

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

Lack of features commonly used in OCL

  • Key: OCL231-38
  • Legacy Issue Number: 1790
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The current specification for OCL lacks many of the features we commonly
    use when doing formal specification of class interfaces, e.g. the ability
    to specify the frame condition, the ability to specify postconditions
    case-wise, the ability to specify when exceptions are thrown, etc.

    To bring OCL closer to the state of the art, I would like to see these
    considered as future extensions.

  • Reported: UML 1.1 — Mon, 10 Aug 1998 04:00 GMT
  • Disposition: Resolved — OCL 2.3.1
  • Disposition Summary:

    This issue was forked off from UML 1.x 15 years ago. It doesn't seem to have anything to do with OCL at all. But rather than throw the issue back to UML, let's address it anyway.
    One could imagine a UML extension that introduced a Frame class and an Operation.ownedFrameCondition to host it. OCL expressions could then impose the semantics.
    However a Frame would be specific to a particular implementation approach, and so it would seem more appropriate to use stereotypes to model the implementation characteristics. Perhaps one of the standard UML profiles already provides this capability.
    Disposition: Closed, no change

  • Updated: Sun, 8 Mar 2015 18:23 GMT

Issue nnnn: Japan PAS Ballot Comment 13 (ocl2-rtf) - Section 8.3.1 OclExpression (l16, p44)

  • Key: OCL231-37
  • Legacy Issue Number: 16136
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Typo. contaxt, change to context

  • Reported: OCL 2.3 — Wed, 20 Apr 2011 04:00 GMT
  • Disposition: Resolved — OCL 2.3.1
  • Disposition Summary:

    Initial Comment: contaxt->context
    Comment: Close as Fixed by OCL 2.3
    Disposition: Closed

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

toLowerCase referred to as toLower (similarly for toUpperCase)

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

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

    Also toUpperCase is referred to as toUpper in the same places

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

    No Data Available

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

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

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

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

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

    No Data Available

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

Role 'collectionTypes' should be 'collectionType'

  • Key: OCL23-39
  • Legacy Issue Number: 13915
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    In Section 8.2.2, in Classifier well-formedness rules, 'collectionTypes' is used instead
    of 'collectionType'. This is not correct since in OCL, by convention, when not provided explicitly
    the name of an opposite role takes the name of the target class with first letter lowerized.

  • Reported: OCL 2.1 — Tue, 5 May 2009 04:00 GMT
  • Disposition: Resolved — OCL 2.2
  • Disposition Summary:

    No Data Available

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

Problems with OCL definition of Package::makesVisible

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

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

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

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

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

    issue already raised in the UML 2.6 RTF

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

Section: A/2.3 Enumeration Types

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

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

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

    issue withdrawn by submitter

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

OCL 2.1 12 Typos

  • Key: OCL23-19
  • Legacy Issue Number: 14597
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    12.12 para 3 "OCl" for "OCL".

    12.8 para 1 last sentence, 12.9 para 1 last sentence; both are unreadable.

    12.12.2 No [B] rule

    12.12.1/12.12.2 contextDeclCS/contextDeclarationCS

  • Reported: OCL 2.1 — Sat, 31 Oct 2009 04:00 GMT
  • Disposition: Resolved — OCL 2.3
  • Disposition Summary:

    The OCl typo is fixed in OCL 2.3.
    The grammar typos are easily fixed.
    While making the multiplicity statements readable, we can make one small step towards aligning OCL with UML 2.x properties.

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

OCL 2.1 12.2.3 Incomplete resolution of Issue 9796 for attrOrAssocContextCS

  • Key: OCL23-18
  • Legacy Issue Number: 14587
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    When Issue 9796 updated terminology to use PropertyCallExpCS, attrOrAssocContextCS should have been updated to propertyContextCS.

  • Reported: OCL 2.1 — Wed, 28 Oct 2009 04:00 GMT
  • Disposition: Resolved — OCL 2.3
  • Disposition Summary:

    In 12.12.2 contextDeclarationCS replace
    [A] contextDeclarationCS ::= attrOrAssocContextCS
    by
    [A] contextDeclarationCS ::= propertyContextDeclCS
    Replace
    12.12.3 attrOrAssocContextCS
    This production rule represents a context declaration for expressions that can be coupled to an attribute or
    association end. The path name refers to the “owner” of the attribute or association end, the simple name
    refers to its name, the type states its type.
    attrOrAssocContextCS ::= ‘context’ pathNameCS ‘::’ simpleName’:’ typeCS initOrDerValueCS
    by
    12.12.3 propertyContextDeclCS
    This production rule represents a context declaration for expressions that can be coupled to a property. The
    path name refers to the “owner” of the property, the simple name refers to its name, the type states its type.
    propertyContextDeclCS ::= ‘context’ pathNameCS ‘::’ simpleName’:’ typeCS initOrDerValueCS

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

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

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

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

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

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

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

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

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

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

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

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

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

OCL 2.1 Implicit Conversion to Collection Literal

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

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

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

    7.5.3 states that 'Such a single object can be used as a Set as well. It then behaves as if it is a Set containing the single object. The usage as a set is done through the arrow followed by a property of Set.'

    The collection type inconsistency between Bag{} and Set

    {x}

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

    When a conversion is applicable is unclear.

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

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

    {self.manager}

    endif->isEmpty()

    so that null->isEmpty is also valid.

    However is

    null->excludesAll(null)

    equivalent to

    Bag{}->excludesAll(Bag{})

    and so true?

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

    However are

    null = Bag{}

    or

    Bag{} = null

    both equivalent to

    Bag{} = Bag{}

    and so true?

    In this case we have a problem of asymmetric overloading.

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

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

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

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

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

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

String.equalsIgnoreCase(String) should result in Boolean

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

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

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

    No Data Available

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

OCL 2.1 11.2.3 Navigated Implicit Conversion to Collection Literal

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

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

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

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

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

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

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

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

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

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

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

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

    The definition therefore implies that:

    1 = 1

    may often evaluate to false, and that

    1.0 = 1

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

    Suggest overload

    {Boolean, Real, String}

    ::

    {=,<>}

    to use values rather than objects.

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

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

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

OCL 2.1 8.3.8 OclInvalid::allInstances

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

    8.3.8 states that in regard to allInstances

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

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

    {invalid}

    is not well-formed.

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

    Suggest:

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

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

    No Data Available

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

wrong variable name

  • Key: OCL23-23
  • Legacy Issue Number: 14886
  • Status: closed  
  • Source: Universidad Nacional del Litoral ( Javier Godoy)
  • Summary:

    subclause [10])

    It reads: let foundElement ... in result = if foundAttribute ... else foundElement ...

    (foundAttribute is undefined, I understand it means to "foundElement")

  • Reported: OCL 2.1 — Sat, 19 Dec 2009 05:00 GMT
  • Disposition: Resolved — OCL 2.3
  • Disposition Summary:

    simple typo

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

Undefined operation tail() on p 130

  • Key: OCL23-22
  • Legacy Issue Number: 14883
  • Status: closed  
  • Source: Universidad Nacional del Litoral ( Javier Godoy)
  • Summary:

    Related to Issue 7539)

    It reads: isOclKind

    It should read: oclIsKindOf

    Rationale: per section 7.5.9 the operation name is "oclIsKindOf"

  • Reported: OCL 2.1 — Sat, 19 Dec 2009 05:00 GMT
  • Disposition: Resolved — OCL 2.3
  • Disposition Summary:

    This typo is addressed by Issue 14882
    Disposition: Merged

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

OCL 2.1 12.2.5 named-self classifierContextDeclCS

  • Key: OCL23-17
  • Legacy Issue Number: 14586
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    The second half of 7.3.3 uses a named-self syntax that is missing from 12.2.5.

    context c : Company inv:
    c.numberOfEmployees > 50

  • Reported: OCL 2.1 — Wed, 28 Oct 2009 04:00 GMT
  • Disposition: Resolved — OCL 2.3
  • Disposition Summary:

    In 12.12.2 classifierContextDeclCS replace
    This production rule represents a context declaration for expressions that can be coupled to classifiers.
    classifierContextDeclCS ::= ‘context’ pathNameCS invOrDefCS
    by
    This production rule represents a context declaration for expressions that can be coupled to classifiers. The
    variable declaration to the classifier context is 'self' for the A form and explicitly specified for the B form.
    [A] classifierContextDeclCS ::= ‘context’ pathNameCS invOrDefCS
    [B] classifierContextDeclCS ::= ‘context’ simpleNameCS ':' pathNameCS invOrDefCS

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

Undefined operation tail()

  • Key: OCL23-21
  • Legacy Issue Number: 14882
  • Status: closed  
  • Source: Universidad Nacional del Litoral ( Javier Godoy)
  • Summary:

    (Related to Issue 7539)

    It reads: isOclKind

    It should read: oclIsKindOf

    Rationale: per section 7.5.9 the operation name is "oclIsKindOf"

  • Reported: OCL 2.1 — Sat, 19 Dec 2009 05:00 GMT
  • Disposition: Resolved — OCL 2.3
  • Disposition Summary:

    No Data Available

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

Undefined operation tail()

  • Key: OCL23-20
  • Legacy Issue Number: 14881
  • Status: closed  
  • Source: Universidad Nacional del Litoral ( Javier Godoy)
  • Summary:

    subclause [4]

    It reads: names->tail()

    It should read:
    names->subSequence(2, names.size())

    Rationale: tail() is not an operation of Sequence

  • Reported: OCL 2.1 — Sat, 19 Dec 2009 05:00 GMT
  • Disposition: Resolved — OCL 2.3
  • Disposition Summary:

    No Data Available

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

The t should be subscripted next to the equal sign

  • Key: OCL231-36
  • Legacy Issue Number: 16306
  • Status: closed  
  • Source: CumuloCogitus Inc. ( Dominic Roy)
  • Summary:

    At the top of the page, there is a formula to define the equal operator. The formula begins with I(=t). That t should be subscripted as we see in the sentence that precedes the formula.

  • Reported: OCL 2.3 — Wed, 1 Jun 2011 04:00 GMT
  • Disposition: Resolved — OCL 2.3.1
  • Disposition Summary:

    The original report against OCL 2.3 A.2.2 has migrated to A.4.2 in OCL 2.3.1.

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

Comparison operators don't exist for Boolean

  • Key: OCL231-35
  • Legacy Issue Number: 16305
  • Status: closed  
  • Source: CumuloCogitus Inc. ( Dominic Roy)
  • Summary:

    In the table A.1 (Schema for operations on basic types), the operations

    {<, >, <, >}

    are defined as applicable to

    {UnlimitedNatural, Integer, Real, String, Boolean}

    .
    While the result is certainly Boolean, the parameters can't be Boolean in general, unless UML defined such operators for Booleans. According to section 11.5.4, there is no definition for the operators. Then Boolean should be removed in the set.

  • Reported: OCL 2.3 — Wed, 1 Jun 2011 04:00 GMT
  • Disposition: Resolved — OCL 2.3.1
  • Disposition Summary:

    No Data Available

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

Issue nnnn: Japan PAS Ballot Comment 9 (ocl2-rtf) Section 7.4.8

  • Key: OCL231-14
  • Legacy Issue Number: 16132
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Whereas there are some infix operator definitions in later document, this list of infix operators isn’t described sufficient. For example, there is ‘>’ definition on 7.6.1. However, ‘>’ is not included in this list. Additionally, ‘=’ is defined on 11.6.1, 11.6.2, 11.6.4, 11.6.5. However, there isn’t ‘=’ on this list. By the way. ‘=’ is not defined for Integer, and Real. Is that no problem? Furthermore, “implies” definition could not be found. Add infix operator sufficiently. And, clarify the operator definition.

  • Reported: OCL 2.3 — Wed, 20 Apr 2011 04:00 GMT
  • Disposition: Resolved — OCL 2.3.1
  • Disposition Summary:

    Not much of a title.
    Section 7.5.8 is not normative so it is not necessary to enumerate every infix operator.
    None of the logical operators, and, or, xor, implies are listed.
    The "->" and "." tokens occur between their arguments and so could be regarded as infix, however navigation operators are not normally regarded as infix operators and so listing them would be more confusing than omitting them.
    In most languages, "=" is not an infix operator, however in OCL it is, so omitting it when all other operators with punctuation spelling are listed is indeed a bit confusing.
    (The punctuation of the list is dreadful.)
    Issue 15009 introduces a missing section on "->" and "." operators.
    Issue 14918 revises the definition of OclAny::= to be sensible for DataTypes.
    implies is defined in 11.5.4

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

Issue nnnn: Japan PAS Ballot Comment 8 (ocl2-rtf) Section 10.3.2 OperationCallExpEval P127

  • Key: OCL231-13
  • Legacy Issue Number: 16131
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    It is difficult to understand which “latter” indicates. Make clear which “latter” implies.

  • Reported: OCL 2.3 — Wed, 20 Apr 2011 04:00 GMT
  • Disposition: Resolved — OCL 2.3.1
  • Disposition Summary:

    Initial Comment: Make clear which “latter” implies.

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

Japan PAS Ballot Comment 24 (ocl2-rtf) 10.1 Introduction

  • Key: OCL231-22
  • Legacy Issue Number: 16147
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    1st paragraph: Single quote does not close in two places:
    ’The Expressions Package
    ’The Types Package
    Complete the quote like the following.
    ’The Expressions Package’
    ’The Types Package’

  • Reported: OCL 2.3 — Wed, 20 Apr 2011 04:00 GMT
  • Disposition: Resolved — OCL 2.3.1
  • Disposition Summary:

    Initial Comment:
    Complete the quote like the following.
    ’The Expressions Package’
    ’The Types Package’
    Comment: Close as Fixed by OCL 2.3
    Disposition: Closed

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

Japan PAS Ballot Comment 23 (ocl2-rtf) 10 Semantics Described Using UML

  • Key: OCL231-21
  • Legacy Issue Number: 16146
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Main text. References like [Kleppe2001] and [Clark2000] are not appropriate in the main text of International Standards. Modify the text as appropriate

  • Reported: OCL 2.3 — Wed, 20 Apr 2011 04:00 GMT
  • Disposition: Resolved — OCL 2.3.1
  • Disposition Summary:

    Initial Comment/Suggestion: Modify the text as appropriate.
    Comment: The explicit academic referenced may remain in the informative bibliography but
    should not remain in the core document of the specification

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

Japan PAS Ballot Comment 18 (ocl2-rtf)

  • Key: OCL231-19
  • Legacy Issue Number: 16141
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Section 9.3.18 BooleanLiteralExpCS, 9.3.19 CallExpCS, 9.3.24 TypeCS,, 9.3.37 OclMessageExpCS, 9.3.39 For instance in case of 9.3.18, numbered list are shown like below.
    [2] [A] BooleanLiteralExpCS ::= ‘true’
    [3] [B] BooleanLiteralExpCS ::= ‘false’”
    The numbering are not consistent with others.
    PROPOSED RESOLUTION: For instance, replace
    [2] [A] BooleanLiteralExpCS ::= ‘true’
    [3] [B] BooleanLiteralExpCS ::= ‘false’”
    with
    [A] BooleanLiteralExpCS ::= ‘true’
    [B] BooleanLiteralExpCS ::= ‘false’”.
    Apply the same type of modifications to all identified clauses.

  • Reported: OCL 2.3 — Wed, 20 Apr 2011 04:00 GMT
  • Disposition: Resolved — OCL 2.3.1
  • Disposition Summary:

    Initial Comment:
    For instance, replace
    [2] [A] BooleanLiteralExpCS ::= ‘true’
    [3] [B] BooleanLiteralExpCS ::= ‘false’”
    with
    [A] BooleanLiteralExpCS ::= ‘true’
    [B] BooleanLiteralExpCS ::= ‘false’”.
    Apply the same type of modifications to all identified clauses.
    Comment: Close as Fixed by OCL 2.3

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

Japan PAS Ballot Comment 17 (ocl2-rtf) Section 9.3.4 simpleNameCS

  • Key: OCL231-18
  • Legacy Issue Number: 16140
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Abstract syntax mapping and Synthesized attributes
    (two places)
    Reference” simpleNameGr” is incorrect, Replace this with simpleNameCS

  • Reported: OCL 2.3 — Wed, 20 Apr 2011 04:00 GMT
  • Disposition: Resolved — OCL 2.3.1
  • Disposition Summary:

    Initial comment: Replace this with simpleNameCS.
    Comment: Close as Fixed by OCL 2.3
    Disposition: Closed

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

Issue nnnn: Japan PAS Ballot Comment 7 (ocl2-rtf) Section 7.4.5 table 7.3

  • Key: OCL231-12
  • Legacy Issue Number: 16130
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Table 7.3 doesn’t understand easily, because “condition” column doesn’t give sufficient explanation. Write more explicit explanation

  • Reported: OCL 2.3 — Wed, 20 Apr 2011 04:00 GMT
  • Disposition: Resolved — OCL 2.3.1
  • Disposition Summary:

    The condition is an extra rule which must be satisfied in order to say that the type in the first
    column conforms to the type in the second column. An extra sentence to explain that will be
    provided. Besides, the UnlimitedNatural condition looks like an explanation rather than a
    condition. So this explanation will be rather located below the table.

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

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

  • Key: OCL231-11
  • Legacy Issue Number: 16129
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    There are same element names in both OCL and UML. Those are confusing. I wonder whether those are UML elements or OCL elements. Besides, it seems there is no clear distinction between UML/OCL (upper case letter) term and general term (lower case letter), since these are used in mixture.

    • It is confusing to distinguish OCL “Constraint” from UML “Constraint” in the text. Furthermore, there are some “constraint” s (in a lower case letter). The lower case letter/upper case letters for “constraint” are mixed.
      OCL “Constraint” should be distinguishable from UML “Constrain”.
  • Reported: OCL 2.3 — Wed, 20 Apr 2011 04:00 GMT
  • Disposition: Resolved — OCL 2.3.1
  • Disposition Summary:

    Not much of a title.
    There are many element names that are the reused in UML; presumably class names were meant. I think that these are all distinct and not confusing to me. No convincing example is given. The example of a Constraint is where UML and OCL overlap so it is obviously the same class.
    Spelling is separately raised as Issue 16126 so there is no need to address it here as well.
    Disposition: Closed, no change

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

Issue from PAS Ballot comment for ISO/IEC DIS 19507 Section 9.3.29 OperationCallExpCS

  • Key: OCL231-20
  • Legacy Issue Number: 16142
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Synthesized attributes, [B] The if-then-else-endif indentation of “The referred operation” part is not appropriate. Replace that part with the list below this table (Listing#1).

  • Reported: OCL 2.3 — Wed, 20 Apr 2011 04:00 GMT
  • Disposition: Resolved — OCL 2.3.1
  • Disposition Summary:

    Initial Comment/Suggestion: Replace that part with the list below this table (Listing#1).

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

Issue nnnn: Japan PAS Ballot Comment 10 (ocl2-rtf) Section 7.4.9 list of keywords

  • Key: OCL231-15
  • Legacy Issue Number: 16133
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    As keywords, it is necessary to include “forAll”, “exists”, “any”, “one”, collect”, “select”, “reject” etc., since there are definitions for these on p161 and other clause. This key word list is insufficient. Add “forAll”, “exists”, “any”, “one”, “collect”, “select”, “reject”.

  • Reported: OCL 2.3 — Wed, 20 Apr 2011 04:00 GMT
  • Disposition: Resolved — OCL 2.3.1
  • Disposition Summary:

    No Data Available

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

Japan PAS Ballot Comment 16 (ocl2-rtf) - Section 9.3.3 VariableExpCS

  • Key: OCL231-17
  • Legacy Issue Number: 16139
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Disambiguating rules. [1] [1] is redundant. Replace this with [1].

  • Reported: OCL 2.3 — Wed, 20 Apr 2011 04:00 GMT
  • Disposition: Resolved — OCL 2.3.1
  • Disposition Summary:

    Initial comment: Replace this with [1].
    Comment: Close as Fixed by OCL 2.3
    Disposition: Closed

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

Issue nnnn: Japan PAS Ballot Comment 11 (ocl2-rtf) p 35 line 1

  • Key: OCL231-16
  • Legacy Issue Number: 16134
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Typo. "This clause describes teh abstract syntax ...""This clause describes the abstract syntax ..."

  • Reported: OCL 2.3 — Wed, 20 Apr 2011 04:00 GMT
  • Disposition: Resolved — OCL 2.3.1
  • Disposition Summary:

    Closed as Fixed by OCL 2.3
    Disposition: Closed

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

OCL 2.0, 2.1 Loop iterators are not ordered and other inconsistencies

  • Key: OCL23-5
  • Legacy Issue Number: 14198
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward 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.

  • Reported: OCL 2.1 — Sat, 22 Aug 2009 04:00 GMT
  • Disposition: Resolved — OCL 2.3
  • Disposition Summary:

    Revised Text:
    In Figure 8.2 and Figure 13.3 change LoopExp.iterator from 0..1 to 1..2

    {ordered}.
    In Figure 8.2 and Figure 13.3 reposition the VariableExp.referredVariable multiplicity to avoid confusion.

    In Figure 10.7 change LoopExpEval.iterators from 1..n to 1..2 {ordered}

    .

    In Section 8.3.1 LoopExp iterator replace
    The iterator variables
    by
    The ordered set of one or two iterator variables.

    In Section 9.3 IteratorExpCS replace
    IteratorExpCS.ast.iterators->size() = 1
    else
    IteratorExpCS.ast.iterators->at(2).name = VariableDeclarationCS[2].ast.name
    and
    IteratorExpCS.ast.iterators->at(2).type =
    ...
    [A] IteratorExpCS.ast.iterators->forAll(initExpression->isEmpty())
    ...
    [C, D] IteratorExpCS.ast.iterator.type =
    ...
    body.source.oclAsType (VariableExp).referredVariable = IteratorExpCS.ast.iterator
    by
    IteratorExpCS.ast.iterator->size() = 1
    else
    IteratorExpCS.ast.iterator->at(2).name = VariableDeclarationCS[2].ast.name
    and
    IteratorExpCS.ast.iterator->at(2).type =
    ...
    [A] IteratorExpCS.ast.iterator->forAll(initExpression->isEmpty())
    ...
    [C, D] IteratorExpCS.ast.iterator->at(1).type =
    ...
    body.source.oclAsType (VariableExp).referredVariable = IteratorExpCS.ast.iterator->at(1)

    In Section 9.3 IterateExpCS replace
    IterateExpCS.ast.iterator.name = if VariableDeclarationCS[1]->isEmpty() then ‘’
    ...
    IterateExpCS.ast.iterator.type =
    ...
    IterateExpCS.ast.iterator.initExpression->isEmpty()
    by
    IterateExpCS.ast.iterator->at(1).name = if VariableDeclarationCS[1]->isEmpty() then ‘’
    ...
    IterateExpCS.ast.iterator->at(1).type =
    ...
    IterateExpCS.ast.iterator->at(1).initExpression->isEmpty()

    In Section 10.3.1 LoopExpEval iterators replace
    The names of the iterator variables in the loop expression
    by
    The ordered set of names of the one or two iterator variables in the loop expression.

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

OCL 2.0, 2.1 inconsistent definition of null and invalid

  • Key: OCL23-4
  • Legacy Issue Number: 14197
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    The attached surprisingly large set of revised text recommendations endeavours to resolve every inconsistent use of invalid and null/void types and the failure to update the specification when undefined was split into null and invalid. The recommendations also correct many conversion errors that crept in when Word Processor formats were changed. Once these changes are incorporated, a very careful proof read against at least Annex A of 03-01-07 should be performed.

    The initial discussion identifies that the approved resolutions of Issues: 6611, 10433, 10434, 12349, 12378, 12484 and 12485 are at best deficient

  • Reported: OCL 2.1 — Sat, 22 Aug 2009 04:00 GMT
  • Disposition: Resolved — OCL 2.3
  • Disposition Summary:

    No Data Available

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

OCL 2.1 7.4.7 Inconsistent Operator Associativity and Precedence

  • Key: OCL23-13
  • Legacy Issue Number: 14582
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    Issue 11098 resolved the missing precedence of let-in as lowest. This requires "2 * let a:Integer=1 in a + 1" to be interpreted as "(2 * (let a:Integer=1 in a)) + 1" making use of a non-trivial let body surprising and needlessly complicated. The problem with the open-ended right hand side can be resolved by assigning let-in the highest atomic expression precedence and defining its resolution as right-associative. The above example then has the obvious meaning "2 * (let a:Integer=1 in (a + 1))".

    Issue 6544 introduces ^ and ^^ at higher precedence than . and ->. However since these operators can only return left hand arguments for each other, there is no need to assign these to different levels.

    if-then-else-endif has an intermediate precedence in OCL 2.1. Since this term has keywords at start and end, the term is equivalent to an atomic expression. In so far as precedence is meaningful it is a high precedence.

    Parentheses should be bulletted at high precedence.

    Non commutative operators such as / have no defined order of evaluation leaving the value of "8 / 4 / 2" undefined. Binary operators should be specified as left-associative; i.e "(8 / 4) / 2".

    Section 9.3.2 duplicates 7.4.7.

  • Reported: OCL 2.1 — Tue, 27 Oct 2009 04:00 GMT
  • Disposition: Resolved — OCL 2.3
  • Disposition Summary:

    No Data Available

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

OCL 2.1 Resolution of missing Concrete Syntaxes and Reserved Words

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

    Define the concrete syntax of a simpleNameCS to avoid punctuation collisions, support Unicode characters, and add a double quoted form with escape sequences for awkward names.

    Define the concrete syntax of a StringLiteralExpCS to support escape sequences for awkward characters.

    Define the concrete syntax of RealLiteralExpCS and IntegerLiteralExpCS.

    Define a variety of effectively reserved words such as true, self, Bag, String as reserved.

  • Reported: OCL 2.1 — Thu, 10 Sep 2009 04:00 GMT
  • Disposition: Resolved — OCL 2.3
  • Disposition Summary:

    No Data Available

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

Missing specification of UnlimitedNatural

  • Key: OCL23-3
  • Legacy Issue Number: 14196
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    The specification of the UnlimitedNatural type is largely missing and often trivially inconsistent.

  • Reported: OCL 2.1 — Sat, 22 Aug 2009 04:00 GMT
  • Disposition: Resolved — OCL 2.3
  • Disposition Summary:

    see pages 24 - 35 of OMG document ptc/2010-12-01

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

Erroneous operation names 'isOclType' and 'asOclType'

  • Key: OCL23-2
  • Legacy Issue Number: 14094
  • Status: closed  
  • Source: Open Canarias, SL ( Victor Sanchez)
  • Summary:

    Erroneous operation names 'isOclType' and 'asOclType'. The operation 'isOclType' appears four times throughout the document. I presume it refers to 'oclIsTypeOf'. The operation 'asOclType' appears six times throughout the document. I presume it refers to 'oclAsType'.

  • Reported: OCL 2.1 — Sat, 25 Jul 2009 04:00 GMT
  • Disposition: Resolved — OCL 2.3
  • Disposition Summary:

    No Data Available

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

[OCL-2.1 RTF] Transitive closure operator


OCL 2.1 7.4.9 true, self, Bag and String are not reserved words

  • Key: OCL23-14
  • Legacy Issue Number: 14583
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    [Splitting a major issue off from a number of minor issues in 14357, so that the resolutions do not get confused.]

    Define a variety of effectively reserved words such as true, self, Bag, String as reserved.

    Define which Complete OCL reserved words are Essential OCL reserved words.

  • Reported: OCL 2.1 — Tue, 27 Oct 2009 04:00 GMT
  • Disposition: Resolved — OCL 2.3
  • Disposition Summary:

    No Data Available

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

Inconsistent lookup for underscored symbols

  • Key: OCL23-9
  • Legacy Issue Number: 14224
  • Status: closed  
  • Source: Individual ( Alexander Igdalov)
  • Summary:

    Description:

    9.3 Concrete Syntax
    As a convention to the concrete syntax, conflicting properties or conflicting class names can be aliased using the «» (underscore) prefix. Inside an OCL expression that is written with the concrete syntax, when a property name or a class name is found to start with a «›, firstly the symbol is lookup in the metamodel. If not found, the same symbol with the «_» skipped is tried.

    Should be

    As a convention to the concrete syntax, conflicting properties or conflicting class names can be aliased using the «» (underscore) prefix. Inside an OCL expression that is written with the concrete syntax, when a property name or a class name is found to start with a «», the symbol with the «_» skipped is looked up in the metamodel.

    Explanation: Consider that some class in the metamodel has two properties called '_self' and 'self' correspondingly. With the resolution rule defined in 9.3 one can never access 'self' property. On one hand, you cannot refer to it directly because it clashed the keyword self. One the other hand, '_self' would refer to '_self' property according to 9.3. Thus, both variants 'aClass.self' and 'aClass._self' are not helpful here.

  • Reported: OCL 2.1 — Thu, 27 Aug 2009 04:00 GMT
  • Disposition: Resolved — OCL 2.3
  • Disposition Summary:

    Discussion:
    Issue 14357 introduces a new underscore-prefix string syntax (_'self') to access awkward
    spellings. This solves the problem of accessing either _'self' or _'_self'.

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

OCL 2.1 Inconsistent implementation of Issue 6532 and contradictory resolution of Issues 7341 and 10437

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

    Issue 7341 resolved that a bad oclAsType in 7.4.6 should return invalid.

    Issue 10437 resolved that the revised text for bad oclAsType in 11.2.5 should return null.

    Issue 6532 resolved that oclAsType in 7.5.9. return a Classifier. The changed specification has OclType.

  • Reported: OCL 2.1 — Wed, 26 Aug 2009 04:00 GMT
  • Disposition: Resolved — OCL 2.3
  • Disposition Summary:

    Issue 7341 is correct.; invalid should be returned by oclAsType when the type
    does not conform. Issue 10437 is wrong. The 10437 revised text also incorrectly
    uses t rather than T.
    Issue 6532 specified an 'instance of Classifier' return for oclAsType. The
    convenience document has not been updated.

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

OCL 2.1 9.3 Missing TypeLiteralExpCS

  • Key: OCL23-16
  • Legacy Issue Number: 14585
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    The expression

    'a'.oclAsType(String)

    is not well-formed since the invocation of oclAsType is an OperationCallExpCS[E] for which String must be an OclExpressionCS.

    String is intended to be a literal expression with a Classifier value, but there is no well-formed OclExpressionCS that can represent such a value.

    Syntactically:

    String could be a VariableExpCS but is not the name of a visible VariableDeclaration.

    String could be a PropertyCallExpCS[B or C] or AssociationClassCallExpCS[B] but is not the name of a property.

    A TypeLiteralExpCS is required to allow use of at least typeCS[A] and more flexibly any typeCS.

  • Reported: OCL 2.1 — Wed, 28 Oct 2009 04:00 GMT
  • Disposition: Resolved — OCL 2.3
  • Disposition Summary:

    In 9.3 LiteralExpCS add
    [E] LiteralExpCS ::= TypeLiteralExpCS
    and
    [E] LiteralExpCS.ast = TypeLiteralExpCS.ast
    and
    [E] TypeLiteralExpCS.env = LiteralExpCS.env
    In 9.3 add
    TypeLiteralExpCS
    This production rule references a type name.
    Abstract syntax mapping
    TypeLiteralExpCS ::= typeCS
    Synthesized attributes
    TypeLiteralExpCS.ast = typeCS.ast
    Inherited attributes
    typeCS.env = TypeLiteralExpCS.env
    Disambiguating rules
    – none

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

OCL 2.1 9.3 Inferred TupleLiteralExp part type

  • Key: OCL23-15
  • Legacy Issue Number: 14584
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    Disambiguating rule 1 for TupleLiteralExp requires each VariableDeclaration to have a type and initExpression.

    However some examples in 7.5.15 omit the type, which is easily inferred from the initializer.

    However neither 8.3.7 nor 9.3 specifies this inference.

    Presumably the type is optional and to be inferred when omitted.

  • Reported: OCL 2.1 — Tue, 27 Oct 2009 04:00 GMT
  • Disposition: Resolved — OCL 2.3
  • Disposition Summary:

    The synthesized attributes for VariableDeclarationCS should infer when possible.

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

OCL 2.0 and 2.1 Section 9.3 CollectionRangeCS incorrect operator spelling

  • Key: OCL23-11
  • Legacy Issue Number: 14237
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    The definition of the CollectionRangeCS grammar is

    CollectionRangeCS ::= OclExpressionCS[1] ‘,’ OclExpressionCS[2]

    but everywhere else the operator is '..'

    Suggest change to

    CollectionRangeCS ::= OclExpressionCS[1] ‘..’ OclExpressionCS[2]

  • Reported: OCL 2.1 — Sat, 29 Aug 2009 04:00 GMT
  • Disposition: Resolved — OCL 2.3
  • Disposition Summary:

    simple typo

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

OCL 2.1 Incomplete resolution 9913 InvalidLiteralExpCS and NullLiteralExpCS

  • Key: OCL23-10
  • Legacy Issue Number: 14236
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    Issue 9913 defines the missing InvalidLiteralExpCS and NullLiteralExpCS, but they are never referenced in the grammar.

    Suggest:

    Add to PrimitiveLiteralExpCS

    [E] PrimitiveLiteralExpCS ::= NullLiteralExpCS
    [F] PrimitiveLiteralExpCS ::= InvalidLiteralExpCS

    and

    [E] PrimitiveLiteralExpCS.ast = NullLiteralExpCS.ast
    [F] PrimitiveLiteralExpCS.ast = InvalidLiteralExpCS.ast

    (not forgetting UnlimitedNaturalLiteralExpCS

  • Reported: OCL 2.1 — Sat, 29 Aug 2009 04:00 GMT
  • Disposition: Resolved — OCL 2.3
  • Disposition Summary:

    Yes; resolution 9913 is incomplete

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

OCL 2.0 Inadequate Headings and PDF index

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

    The OCL 2.0 specification would be much easier to read if:

    1) The PDF had a full set of titles visible in the bookmarks:

    8.3.*, Annex A.2 , Annex B and Index are missing completely.

    A.1 and A.3 apppear as subsections of 13.3.

    2) There are a number of large sections such as 8.3.*, 9.3 and 10.4 with unnumbered headings for each AS or CS class.
    [11.5 is much better in this respect.]

    These are not in alphabetical order, not page aligned and not particularly distinct.

    It would be helpful to

    a) give them numbers so that they appear in the Bookmarks and are more distinct.
    b) put them in alphabetical order.
    [c) consider page aligning them.]

    [It would be good if the index was much more comprehensive too.

    e.g "at", "null", "any", "iterator", "UnlimitedNatural" ...]

  • Reported: OCL 2.1 — Sat, 22 Aug 2009 04:00 GMT
  • Disposition: Resolved — OCL 2.3
  • Disposition Summary:

    PDF bookmarks were fixed in OCL 2.3.
    Alphabeticizing must wait until autogenerated in OCL 2.5.
    Provision of a manually maintained index in OMG specifications is strongly discouraged.
    Disposition: Closed, no change

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

OCL 2.0, 2.1 Inaccurate well-formedness constraints for IteratorExp

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

    The well-formedness constraints for IteratorExp are confusing, incomplete and sometimes wrong.

  • Reported: OCL 2.1 — Sat, 22 Aug 2009 04:00 GMT
  • Disposition: Resolved — OCL 2.3
  • Disposition Summary:

    The revised text below resolves these issues

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

Prime symbol lacking in the explanation preceding the formula

  • Key: OCL231-33
  • Legacy Issue Number: 16302
  • Status: closed  
  • Source: CumuloCogitus Inc. ( Dominic Roy)
  • Summary:

    In the 3rd item of the definition A.12 (System State), the paragraph before the formula ends by :
    "whereas the function i(l) projects all but the ith component):"

    The function is exactly the same as the first function in the same sentence. It appears that a prime symbol is missing in the function. Indeed, a prime symbol appears in the formula.

  • Reported: OCL 2.3 — Wed, 1 Jun 2011 04:00 GMT
  • Disposition: Resolved — OCL 2.3.1
  • Disposition Summary:

    The overline operator got lost when the Latex was FrameMakered

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

Confusing usage of the "precedes" symbol for generalization hierarchy

  • Key: OCL231-32
  • Legacy Issue Number: 16291
  • Status: closed  
  • Source: CumuloCogitus Inc. ( Dominic Roy)
  • Summary:

    The symbol ≺ is used in this page. According to Unicode definition, this symbol represents a mathematical symbol whose definition is "precedes". Here is the reference of that definition :
    http://unicode.org/cldr/utility/character.jsp?a=227A

    I'm not a mathematician and I don't know precisely what this symbol means for mathematicians, even if I searched in many books and on the Internet. However, I find very confusing to use a symbol that means "precedes" to means "is the child of".

    There is another symbol ≻ which means 'succeeds' that would be less confusing in the sense of "C1 succeeds C2" to means that C1 is the child of C2.

    As I'm not mathematician, I may be completely wrong and I would greatly appreciate a sound reference where this symbol is defined formally.

  • Reported: OCL 2.3 — Sat, 28 May 2011 04:00 GMT
  • Disposition: Resolved — OCL 2.3.1
  • Disposition Summary:

    The current operator has not been significantly changed by the Latex to FrameMaker conversion and so corresponds to an informed academic choice.
    The requested change is less-informed and subjective.
    Disposition: Closed, no change

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

Japan PAS Ballot Comment 34 (ocl2-rtf) 13.3 Diagrams figure 13.8

  • Key: OCL231-29
  • Legacy Issue Number: 16157
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Same diagrams are duplicated. Remove either. The referred operation:
    OperationCallExpCS.ast.referredOperation =
    if OclExpressionCS.ast.type.oclIsKindOf(CollectionType)
    then – this is a collection operation called on a collection
    OclExpressionCS.ast.type.lookupOperation(simpleNameCS.ast,
    if (argumentsCS->notEmpty())
    then argumentsCS.ast->collect(type)
    else Sequence{} endif )
    else – this is a set operation called on an object => implicit Set with one element
    SetType.allInstances()->any(st|st.elementType = OclExpressionCS.ast.type).lookupOperation(simpleNameCS.ast,
    if (argumentsCS->notEmpty())
    then argumentsCS.ast->collect(type)
    else Sequence{} endif )
    endif

  • Reported: OCL 2.3 — Wed, 20 Apr 2011 04:00 GMT
  • Disposition: Resolved — OCL 2.3.1
  • Disposition Summary:

    The unique difference, that the first diagram misses the CollectionKind.Collection
    Enumeration literal. Remove the first diagram.

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

Japan PAS Ballot Comment 33 (ocl2-rtf) 13.3.3 String page 144

  • Key: OCL231-28
  • Legacy Issue Number: 16156
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    “ASCII or Unicode” is confusing. Use the same UML description

  • Reported: OCL 2.3 — Wed, 20 Apr 2011 04:00 GMT
  • Disposition: Resolved — OCL 2.3.1
  • Disposition Summary:

    Initial Comment/Suggestion: Use the same UML description
    Comment : Resolved by using uml infrastructure 13.2.4 definition for string type:

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

Japan PAS Ballot Comment 28 (ocl2-rtf) 10.2.3 Additional Operations for the Values Package

  • Key: OCL231-25
  • Legacy Issue Number: 16151
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    ObjectValue [1] The text refers to name parameter of snapshot, but LocalSnapshot in Figure 10.2 does not have “name: String” Add name parameter to LocalSnapshot in Figure 10.2.

  • Reported: OCL 2.3 — Wed, 20 Apr 2011 04:00 GMT
  • Disposition: Resolved — OCL 2.3.1
  • Disposition Summary:

    “The value that is bound to the name parameter in the latest snapshot” implies the use of
    the LocalSnapshot's bindings (NameValueBinding). Perhaps, including the word
    “bindings” may avoid confusions

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

Japan PAS Ballot Comment 27 (ocl2-rtf) Section 10.2.1 Definitions of Concepts for the Values Package

  • Key: OCL231-24
  • Legacy Issue Number: 16150
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Figure 10.3 Explanation of TupleValue (page 107) describes its association with element, but this association is not included in Figure 10.3. Add this association to Figure 10.3

  • Reported: OCL 2.3 — Wed, 20 Apr 2011 04:00 GMT
  • Disposition: Resolved — OCL 2.3.1
  • Disposition Summary:

    IIn section 10.2.1, the TupleValue description states the following:
    “In the metamodel, this is shown as an association from TupleValue to NameValueBinding.”
    Therefore the text, diagram and association description are consistent.
    Disposition: Closed

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

Use of the word meta

  • Key: OCL231-30
  • Legacy Issue Number: 16235
  • Status: closed  
  • Source: CumuloCogitus Inc. ( Dominic Roy)
  • Summary:

    I want to signal that the use of the word "meta" is confusing. Here is an example on page 47.

    TypeExp
    A TypeExp is an expression used to refer to an existing meta type within an expression.

    According to Merriam-Webster, "meta" is usually a prefix that could be added at the beginning of a word. This particle should be merged to the main word (like in metabasis) or attached using an hyphen (like meta-analysis).

    In consequence, we should read "metatype" which seems to hold the correct meaning. It is coherent with metaclass, for example. By the way, "metatype" is used at many places in the document.

    In some contexts and in the familiar language, you can use "meta" as a diminutive for something when its meaning is obvious. For example, "the meta is broken" when you mean the metacarpus. In a specification document and in a context where we have to differentiate many metaconcepts, it doesn't have its place.

    It is seen at many places in this document and may be other. In this one, we see "meta model" and "meta-model", while the word "metamodel" should be and is effectively used.

  • Reported: OCL 2.3 — Fri, 13 May 2011 04:00 GMT
  • Disposition: Resolved — OCL 2.3.1
  • Disposition Summary:

    yes

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

Japan PAS Ballot Comment 30 (ocl2-rtf) 10.3 The Evaluations Package, 2nd paragraph

  • Key: OCL231-26
  • Legacy Issue Number: 16153
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    This paragraph is confusing. It starts with Figure 10.6 but talks about elements not included in Figure 10.6. In addition it talks about “OclEvaluation” twice, which do not appear in any of the following diagrams.Split the paragraph into two. Fist one should be just about summary of Figure 10.6, and the second one should introduce Figure 10.7with associated elements

  • Reported: OCL 2.3 — Wed, 20 Apr 2011 04:00 GMT
  • Disposition: Resolved — OCL 2.3.1
  • Disposition Summary:

    Initial suggestion:
    Split the paragraph into two. Fist one should be just about summary of Figure 10.6, and the second one
    should introduce Figure 10.7with associated elements.

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

on page 153 oclIsInState is used instead of oclInState

  • Key: OCL231-31
  • Legacy Issue Number: 16260
  • Status: closed  
  • Source: Vienna University of Economics and Business ( Bernhard Hoisl)
  • Summary:

    On page 153 oclIsInState(statespec : OclState) is used to check if an object is in a specified state. But in Section 7.5.9 on page 22 oclInState(statespec : OclState) is used for this purpose and examples are given.

    There is one more occurrence of oclIsInState on page 47 of Section 8.3.1, but this is talking about the abstract syntax, therefore it could be valid. But I think definitely not for the concrete syntax of the OCL.

    Strangely enough the Eclipse Interactive OCL Console implements oclIsInState() and not oclInState().

    I would appreciate a clarification which statement to use very much!

  • Reported: OCL 2.3 — Fri, 20 May 2011 04:00 GMT
  • Disposition: Resolved — OCL 2.3.1
  • Disposition Summary:

    If it was a popularity contest, oclInState would win because there are many occurences in Clause 7, but Clause 7 is not normative.
    Excluding clause 7, oclIsInState has two occurences to oclInState's one. More importantly, the definition in 11.3.1 is oclIsInState.
    Stylistically, all other ocl-prefixed methods returning boolean are oclIs...
    Let's go for oclIsInState

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

Japan PAS Ballot Comment 25 (ocl2-rtf) 10.1 Introduction, 3rd and 4th paragraphs

  • Key: OCL231-23
  • Legacy Issue Number: 16148
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    The term “OMG 4-layered architecture” may need to be explained or used with proper references. Modify the text as appropriate.

  • Reported: OCL 2.3 — Wed, 20 Apr 2011 04:00 GMT
  • Disposition: Resolved — OCL 2.3.1
  • Disposition Summary:

    Not much of a title.
    Anyone familiar with modeling should really know who the OMG is and what a 4-layered architecture is.
    However it is surprisingly difficult to find any primary OMG references. MOF for instance refers to "a ‘Four layered metamodel architecture’ which is referred to in various OMG specifications" so maybe MOF will get some adverse comments from PAS too.

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

Japan PAS Ballot Comment 31 (ocl2-rtf): 10.3.1 Definitions of Concepts for the Evaluations Package

  • Key: OCL231-27
  • Legacy Issue Number: 16154
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    OperationCallExp. This heading should read “OperationCallExpEval.”. Modify the heading as appropriate.

  • Reported: OCL 2.3 — Wed, 20 Apr 2011 04:00 GMT
  • Disposition: Resolved — OCL 2.3.1
  • Disposition Summary:

    Suggested action: Modify the heading as appropriate.

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

Unbalanced parenthesis in the formula

  • Key: OCL231-34
  • Legacy Issue Number: 16303
  • Status: closed  
  • Source: CumuloCogitus Inc. ( Dominic Roy)
  • Summary:

    The last formula in the definition A.12 has unbalanced parenthesis.
    The first parenthesis after the = sign seems in excess.

  • Reported: OCL 2.3 — Wed, 1 Jun 2011 04:00 GMT
  • Disposition: Resolved — OCL 2.3.1
  • Disposition Summary:

    No Data Available

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

OCL 2.2 UML Alignment of association names

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

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

    The problem with OCL 2.2, Fig 7.1 are:

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

    and

    The OCL examples for Figure 7.2, currently:

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

    should be fixed to:

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

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

    and

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

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

    context Person inv: self.job

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

    to:

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

    context Person inv: self.Job

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

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

    No Data Available

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

OCL 2.2 11.5.3 What is a locale?

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

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

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

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

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

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

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

    No Data Available

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

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

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

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

    Associativity is necessary for predictable results.

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

    Suggest: remove the requirement for commutativity.

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

    No Data Available

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

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

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

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

    Associativity is necessary for predictable results.

    However what if it isn't?

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

    • probably not possible.

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

    • difficult to ensure implementation portability

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

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

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

    No Data Available

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

OCL 2.3 Ballotted: Retracting resolutions for Issue 10439/13076

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

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

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

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

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

    No Data Available

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

toLowerCase() declared as returning Integer

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

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

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

    No Data Available

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

the use of the keyword 'attr'

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

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

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

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

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

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

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

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

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

    yes

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

Definition for symmetric difference is wrong

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

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

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

    No Data Available

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

US PAS Ballot Comment 3 (ocl2-rtf) paragraph 1

  • Key: OCL231-7
  • Legacy Issue Number: 16123
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    The nature of the relationship between this specification and the OCL in UML 1.4 should be clarified in an informative manner.
    UML 1.4.1 needs to remain in force, because many UML models in many standards throughout the world are specified using UML 1.x notation, which is not backwards compatible with the notation in UML 2.x.
    Replace:

    This specification replaces the specification of OCL given in UML 1.4.1 and UML 1.5.

    With:

    This specification replaces the specification of OCL given in OCL 2.0.
    The version of OCL specified in ISO/IEC 19501:2005 is intended for use in models based on UML 1.4.1 and UML 1.5. However, use of the OCL specified by ISO/IEC 19501:2005 is not prescribed by this specification.
    The version of OCL specified in this International Standard is not directly applicable to models based on ISO/IEC 19501:2005. ”

  • Reported: OCL 2.3 — Wed, 20 Apr 2011 04:00 GMT
  • Disposition: Resolved — OCL 2.3.1
  • Disposition Summary:

    No Data Available

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

US PAS Ballot Comment 2 (ocl2-rtf) References

  • Key: OCL231-6
  • Legacy Issue Number: 16122
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    The references need to include links to the formal OMG published specifications.

    The Scope clause refers to UML 2.2, however the reference is UML 2.0

    Informal references to UML 1.4.1 and UML 1.5 are included as part of explanatory text in the OCL 2.2 spec which refers to UML 1.x to explain differences of this new version of OCL.. The ISO/IEC 10151 (UML 1.4.1) needs to be added as an informative reference, for use in these explanations.
    Change:

    3 Normative References
    The following referenced documents are indispensable for the application of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.
    • UML 2.0 Superstructure Specification
    • UML 2.0 Infrastructure Specification
    • MOF 2.0 Core Specification
    • UNICODE 5.1 Standard: http://www.unicode.org/versions/Unicode5.1.0/
    «
    To :
    «
    3 References
    3.1 Normative References
    The following referenced documents are indispensable for the application of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.
    • UML 2.2 Superstructure Specification <omg spec Ref URL>
    • UML 2.2 Infrastructure Specification <omg spec Ref URL>
    • MOF 2.0 Core Specification <omg spec Ref URL>
    • UNICODE 5.1 Standard: http://www.unicode.org/versions/Unicode5.1.0/
    3.2 Informative References
    The following specifications are referenced in informative text:
    • ISO/IEC 19501:2005 Information technology – Open Distributed Processing – Unified Modeling Language (UML) Version 1.4.2 , also <omg Spec Ref URL>

    Change all uses of the informal UML 1.x references in the text From:

    UML 1.x” or “UML 1.4.x”

    To:

    ISO/IEC 19501:2005

  • Reported: OCL 2.3 — Wed, 20 Apr 2011 04:00 GMT
  • Disposition: Resolved — OCL 2.3.1
  • Disposition Summary:

    No Data Available

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

Issue on Alignment of next OCL version and references UML 2.4/ MOF 2.4

  • Key: OCL231-2
  • Legacy Issue Number: 15877
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Nature of problem:

    Informal references to UML 1.4.1 and UML 1.5 are included
    as part ofexplanatory text in the OCL 2.2 spec which refers
    to UML 1.x to explain differences of this new version of
    OCL.. The ISO/IEC 10151 (UML 1.4.1) needs to be added as
    an informative reference, for use in these explanations.

    UML 1.4.1 needs to remain in force, because so many UML
    models in may standards throughout the world are specified
    using UML 1.x notation, which is not backwards compatible
    with the new notation in UML 2.x.

    Given the normative content of OCL 2.3 (after RTF
    completes) is aligned technically with UML 2.4 and MOF 2.4,
    its normative references should be updated before
    publication of the RTF output, so that the OMG spec cross
    references will remain appropriate..

    The references, and their uses in the OCL 2.3spec, need to
    be updated to reflect these latest UML/MOF versions.

    In addition, the Output of the OCL 2.3 RTF should be
    labeled as OCL 2.4, to avoid clarify the technical
    alignment of OMG’s latest versions of UML and MOF.

    Proposed Changes:

    Change version in title to OCL 2.4.

    Change all self references in the text from “OCL version
    2.2” to “this OMG Specification”.

    Change all references from UML 2.0 and MOF 2.0 to UML 2.4
    and MOF 2.4.

    In Section 1 ­ Scope Clause:

    Change:

    This specification defines the Object Constraint Language
    (OCL), version 2.3. OCL version 2.3 is the version of OCL
    that is aligned with UML 2.3 and MOF 2.0.

    to

    This specification defines the Object Constraint Language
    (OCL), version 2.4. OCL version 2.4 is the version of OCL
    that is aligned with UML 2.4 and MOF 2.4.

    Section 3 ­ Normative References

    Change:

    3 Normative References
    The following normative documents contain provisions which,
    through reference in this text, constitute provisions of
    this specification. For dated references, subsequent
    amendments to, or revisions of, any of these publications
    do not apply.
    • UML 2.0 Superstructure Specification
    • UML 2.0 Infrastructure Specification
    • MOF 2.0 Core Specification
    • UNICODE 5.1 Standard:
    http://www.unicode.org/versions/Unicode5.1.0/
    «
    To :
    «
    3 References
    3.1 Normative References
    The following normative documents contain provisions which,
    through reference in this text, constitute provisions of
    this specification. For dated references, subsequent
    amendments to, or revisions of, any of these publications
    do not apply.
    • UML 2.4 Superstructure Specification <omg spec Ref URL>
    • UML 2.4 Infrastructure Specification <omg spec Ref URL>
    • MOF 2.4 Core Specification <omg spec Ref URL>
    • UNICODE 5.1 Standard:
    http://www.unicode.org/versions/Unicode5.1.0/
    3.2 Informative References
    The following specification is reference in explanatory
    text, which describes differences between this
    specification and the version of OCL included in the
    existing standard. Its provisions do not constitute
    provisions of this specification.
    • ISO/IEC 19501:2005 Information technology – Open
    Distributed Processing – Unified Modeling Language (UML)
    Version 1.4.2 , also <omg Spec Ref URL>

    Change all uses of the reference in the text
    From

    UML 1.x” or “UML 1.4.x”

    To:

    ISO/IEC 19501:2005

    In Section 6.1 “Changes to Adopted OMG Specifications”

    Replace:

    This specification replaces the specification of OCL given
    in UML 1.4.1 and UML 1.5.

    With:

    This specification replaces the specification of OCL given
    in OCL 2.2.

    The version of OCL specified in ISO/IEC 19505:2005 is
    intended for use in models based on UML 1.4.1 and UML 1.5.
    However, use of the OCL specified by ISO/IEC 19505:2005 is
    not prescribed by this specification.

  • Reported: OCL 2.3 — Tue, 7 Dec 2010 05:00 GMT
  • Disposition: Resolved — OCL 2.3.1
  • Disposition Summary:

    Although this issue was raised in conjunction with the First OCL 2.4 RTF that led to OCL 2.3.1, it seems appropriate to use this issue resolve all the 'boilerplate' changes for OCL 2.4.
    Some of the changes outlined above occurred in OCL 2.3.1 and so need only a refresh for OCL 2.4.
    The change of all OCL 2.2 references to this specification is not applicable since all references to OCL 2.2 and 2.3 intentionally refer to transitions in specified functionality.
    MOF 2.0 references occur only in the boilerplate and so have been enumerated.
    There are many UML 2.0 references associated with the TBD alignment with the UML 2.0 metamodel. These are very unfortunate but deserve to stay as the TBDs that they remain.

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

US PAS Ballot Comment 1

  • Key: OCL231-5
  • Legacy Issue Number: 16121
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    The OMG OCL 2 Revision Task force has resolved a set of defect and clarification issues against the text in DIS 19507. (Preliminary Report http://doc.omg.org/ptc/10-12-01.pdf , Change Barred Spec http://doc.omg.org/ptc/10-11-41.pdf) It is important that the corrections resolving these defects be reflected in the published ISO/IEC Standard for OCL. The editing group for OCL 2 (DIS 19607) should consider all changes against the text of OCL 2.2, resulting from RTF defect resolutions in the latest minor revision to OCL 2, approved by the OMG PTC by the time of the ballot resolution.

  • Reported: OCL 2.3 — Wed, 20 Apr 2011 04:00 GMT
  • Disposition: Resolved — OCL 2.3.1
  • Disposition Summary:

    This is a philosophical statement without any identifiable issues. Many related issues were raised so presumably no action is necessary here.
    Disposition: Closed, no change

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

oclIsInState()

  • Key: OCL231-4
  • Legacy Issue Number: 16048
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    Since you are working on the StateMachines chapter, it may be worth considering after the first submission adding an explanation about oclIsInState().
    This query operation is unfortunately mispelled as oclInState(), see: http://www.omg.org/issues/ocl2-rtf.open.html#Issue15257
    This query operation is confusingly listed as a predefined property and explained as an operation in OCL2.2, clause 7.5.9:

    7.5.9 Predefined properties on All Objects
    There are several properties that apply to all objects, and are predefined in OCL. These are:
    oclIsTypeOf (t : Classifier) : Boolean
    oclIsKindOf (t : Classifier) : Boolean
    oclInState (s : OclState) : Boolean
    oclIsNew () : Boolean
    oclAsType (t : Classifier) : instance of OclType

    ....
    The operation oclInState(s) results in true if the object is in the state s. Possible states for the operation oclInState(s) are all states of the statemachine that defines the classifier's behavior. For nested states the statenames can be combined using the double colon “::”.

  • Reported: OCL 2.3 — Mon, 7 Mar 2011 05:00 GMT
  • Disposition: Resolved — OCL 2.3.1
  • Disposition Summary:

    I'm not sure that this correspondence on the UML RTF was really intended to be an OCL issue.
    The specific oclIsInState typo is resolved by Issue 16260.
    The more general discussion is appropriate for UML.
    Disposition: See issue 16260 for disposition

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

OCL 2.3 Incomplete CollectionRange well-formedness rules

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

    The descriptions of CollectionRange are generally vague leaving the end inclusivities unclear.

    It is only the CollectionRangeEval::getRange that provides a solid definition of well-formedness
    for e.g. Sequence

    {1..1}

    as equal to Sequence

    {1}

    .

    Unfortunately the specification is undecided about Sequence

    {2..1} since the CollectionRangeEval::getRange
    recursion never terminates.


    Rather than impose a well-formedness constraint that Sequence{2..1}

    is invalid, perhaps it should be
    made useful instead, by defining .. as operating in the direction of the last wrt the first so
    Sequence

    {2..1} = Sequence{2,1} and Set{1..2} = Set{2..1}

    = Set

    {1,2}

    .

  • Reported: OCL 2.3 — Thu, 18 Nov 2010 05:00 GMT
  • Disposition: Resolved — OCL 2.3.1
  • Disposition Summary:

    The generalization to allow down-counts can lead to nasty surprises for e.g. Sequence

    {1..x->size()}

    when x is empty. So just make it clear that Sequence

    {2..1}

    is invalid

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

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

  • Key: OCL231-10
  • Legacy Issue Number: 16128
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Click here for this issue's archive.
    Nature: Issue from PAS Ballot comment for ISO/IEC DIS 19507
    Severity:
    Summary:

    See comment JP 5 in “…_JISC.doc” file in http://www.omg.org/members/cgi-bin/doc?pas/11-03-03.zip
    Resolution:

  • Reported: OCL 2.3 — Wed, 20 Apr 2011 04:00 GMT
  • Disposition: Resolved — OCL 2.3.1
  • Disposition Summary:

    Not much of a title.
    Not much of a summary.
    The referenced document jumps straight from JP4 to JP6, so no action possible.
    Even if JP6 was meant rather than JP5 then we can dismiss as a duplicate of Issue 16129.
    Disposition: Closed, no change

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

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

  • Key: OCL231-9
  • Legacy Issue Number: 16125
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    The format of normative references doesn't meet ISO format.ISO/IEC 19505-1:2011 Information technology — OMG Unified Modeling Language (OMG UML) Version 2.1.2 Part 1: Infrastructure
    ISO/IEC 19505-2:2011 Information technology — OMG Unified Modeling Language (OMG UML) Version 2.1.2 Part 2: Superstructure
    ISO/IEC 19502:2005 Information technology – Meta Object Facility (MOF)
    ISO/IEC 10646:2003 Information technology – Universal Multiple-Octet Coded Character Set (UCS)
    If you want to refer OMG’s documents, see directive.

  • Reported: OCL 2.3 — Wed, 20 Apr 2011 04:00 GMT
  • Disposition: Resolved — OCL 2.3.1
  • Disposition Summary:

    Resolved as Issue 16122. See US 1, Added 10646 as ref for Unicode. Will Fix at BRM to
    most appropriate formal references, either ISO or OMG spec refs
    Disposition: See issue 16122 for disposition

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

typo in ptc/2010-11-42 and pas/2010-08-02

  • Key: OCL231-3
  • Legacy Issue Number: 15922
  • Status: closed  
  • Source: Architecture Technology Institute ( Hiroshi Miyazaki)
  • Summary:

    Regarding ptc/10-11-42 and pas/10-08-02,
    It seems to be typo.

    In ptc/10-11-42, 11.6.5, and
    in pas/10-08-02, 11.5.5

    Threre is
    "A Sentence is not a subtype of Bag. The common supertype of Sentence and Bags is Collection."
    ^^^^^^^ ^^^^^^^^

    These two "Sentence"s seem to be typo.

    Substitute "Sequence" for "Sentence".

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

    Yes. Bags is also a typo and the English can be improved

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

Japan PAS Ballot Comment 1 (ocl2-rtf)

  • Key: OCL231-8
  • Legacy Issue Number: 16124
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Because the content of table 2.1 is empty, this table is meaningless. Fill the table.

  • Reported: OCL 2.3 — Wed, 20 Apr 2011 04:00 GMT
  • Disposition: Resolved — OCL 2.3.1
  • Disposition Summary:

    As the text above the table 2.1 explains, said template table is intended to be filled by OCL Tool
    implementors.
    Disposition: Closed

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

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

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

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

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

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

    {getInitialValue()}

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


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

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

Use of simple quotes and double quotes in strings

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

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

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

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

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

Missing definition of of iterators for OrderedSets

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

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

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

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

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

Type of a type expression

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

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

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

    Disposition: See issue 9171 for disposition

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

Use of MOF reflection in EssentialOCL should be clarified

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

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

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

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

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

No way to represent type parameters in the standard library

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

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

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

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

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

OCL 2.0 8.2 Collection Type packaging

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

    [Pending a resolution of Issue 10946]

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

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

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

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

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

    Disposition: See issue 9171 for disposition

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

Section: A.3.2.2 Syntax and Semantics of Postconditions

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

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

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

    No Data Available

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

Making OclAny denote any object

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

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

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

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

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

OCL 2.0: CollectionType constraint for invalid elements is incorrect

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

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

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

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

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

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

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

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

Clarify the common supertype of Bag and Sequence

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

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

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

    Adding clarification sentences

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

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

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

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

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

    Disposition: See issue 4451 for disposition

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

Section: A.3.1.2 Semantics of Expressions

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

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

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

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

    Disposition: Closed, no change

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

Incosistency between UnlimitedInteger and UnlimitedNatural

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

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

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

    No Data Available

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

Dynamic typing with allInstances()

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

    { Set_of_instances_of_classFoo, Set_of_instances_of_classBar}

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

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

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

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

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

    No Data Available

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

missing closing parethesis inthese two expressions

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

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

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

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

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

    No Data Available

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

Usage of initialization and derivation constraints on the same property

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

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

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

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

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

    No Data Available

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

Collection element type serialization

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

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

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

    Suggest:

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

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

    No Data Available

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

Section 8.2 InvalidType

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

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

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

    No Data Available

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

Section: 7.4.7, 7.4.9, 9.3.2

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

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

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

    No Data Available

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

TypeType

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

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

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

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

    No Data Available

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

ownership of association ends does not matter for traversal in OCL

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

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

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

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

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

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

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

    No Data Available

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

11.7.1

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

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

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

    No Data Available

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

11.2.5 (02)

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

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

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

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

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

    No Data Available

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

8.2.2 Well-formedness Rules for the Types Package

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

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

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

    No Data Available

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

11.8.1

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

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

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

    No Data Available

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

11.2.4 (OclInvalid) - similar criticism as 11.2.3

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

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

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

    No Data Available

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

11.2.5

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

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

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

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

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

    No Data Available

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

Naming of Constraints in OCL

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

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

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

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

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

    Does it?

    If not it would be useful to add.

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

    No Data Available

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

Section: 7.4.9

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

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

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

    No Data Available

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

Using "def"

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

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

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

    No Data Available

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

Section: 7.8

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

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

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

    No Data Available

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

Section "IteratorExpCS"

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

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

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

    No Data Available

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

Section 9.2.2

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

    "The OCL specification puts no restriction on visibility."

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

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

    No Data Available

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

11.2.3

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

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

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

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

    No Data Available

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

Section 7.6.3

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

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

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

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

    No Data Available

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

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

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

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

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

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

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

    reverse: Returns a sequence in reverse order

    join(namesOfCollections; namesOfProperties; booleanExpression; orderByExpression)

    Where:

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

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

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

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

    collections we want to get in the result.

    • booleanExpression is a valid boolean expression containing the

    conditions the elements from the collections defined in listOfCollections

    must satisfy in order to be included in the result

    • booleanExpression is a valid boolean expression containing the

    conditions the elements from the collections defined in listOfCollections

    must satisfy in order to be included in the result

    average: Calculate the average value in a collection

    stdev: Calculate the standard deviation of a collection

    variance: Calculate the variance of a collection

    median: Calculate the median of a collection

    mode: Calculate the mode of a collection

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

    No Data Available

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

The concrete syntax given is extremely difficult to implement

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

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

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

    Disposition: See issue 10439 for disposition

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

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

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

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

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

    No Data Available

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

type of the iterator variable is expected or not?

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

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

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

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

    Disposition: Close, no change

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

doubts about the iterator variables

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

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

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

    No Data Available

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

CollectionType and CollectionKind

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

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

    9.3 collectionTypeCS synthesized attributes, page 79, contains:

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

    using CollectionKind::Collection.

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

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

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

    An expression like the following is valid:

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

    and demonstrates the need for a concrete CollectionType.

    Recommendation:

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

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

    No Data Available

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

no explanations about how to manipulate optional and multivalued attributes

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

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

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

    No Data Available

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

section 7.4.6 (p. 12)

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

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

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

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

    Disposition: See Issue 7341 for disposition

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

Section: A/1.1.1 Types

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

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

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

    No Data Available

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

last line on page 28

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

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

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

    No Data Available

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

Section: A/1.2.4 System State

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

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

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

    No Data Available

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

Section: A/1.2.1 Objects

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

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

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

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

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

    No Data Available

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

Section: A/1.1.6 Generalization - editorial issues

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

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

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

    No Data Available

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

Section: A/1.1.5 Associations

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

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

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

    No Data Available

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

Section: A/1.1.5 Associations -- missing word

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

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

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

    No Data Available

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

Section: A/1.1.6 Generalization

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

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

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

    No Data Available

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

Section: A/1.1.5 Associations

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

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

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

    No Data Available

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

Section: A/2.2 Common Operations on All Types

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

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

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

    No Data Available

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

Section: A.2.5.8 Sequence Operations

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

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

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

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

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

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

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

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

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

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

    {...}

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

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

    )."

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

    Disposition: See issue 12488 for disposition

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

Section 8.2.1 Type Conformance on page 37

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

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

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

    No Data Available

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

Section: A.3.1.1 Syntax of Expressions

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

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

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

    No Data Available

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

Section: A.2.7 Type Hierarchy

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

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

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

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

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

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

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

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

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

    No Data Available

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

Section: A.2.6 Special Types

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

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

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

    No Data Available

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

Section: A.3.1.1 Syntax of Expressions

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

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

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

    Disposition: See issue 12474 for disposition

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

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

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

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

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

    No Data Available

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

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

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

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

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

    No Data Available

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

Section: A.3.1.2 Semantics of Expressions

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

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

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

    No Data Available

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

Section 8.2 page 35 InvalidType

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

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

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

    Disposition: See issue 12378 for disposition

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

Section: A.3.1.1 Syntax of Expressions

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

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

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

    No Data Available

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

Section: A/2.3 Enumeration Types -- editorial

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

    The last sentence of the page is missing the word "one" or, alternately, proper forms of the verbs "to follow" and "to retrieve". A correct form of this sentence would be, "Navigation operations: An object may be connected to other objects via association links. A navigation expression allows one to follow these links and to retrieve connected objects."

  • Reported: OCL 2.0 — Wed, 14 May 2008 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

The constraint [1] on the TupleLiteralPart metaclass is overconstrained

  • Key: OCL21-310
  • Legacy Issue Number: 12454
  • Status: closed  
  • Source: Zeligsoft, Inc. ( Christian Damus)
  • Summary:

    The constraint [1] on the TupleLiteralPart metaclass is overconstrained. It requires that the type of the value of a tuple literal part be identical to the corresponding attribute of the tuple type. However, the value type should only be required to conform to the attribute type because tuple literals may optionally specify the part types (in the same fashion as variable declarations). Thus, a more appropriate formulation of this constraint would be: context TupleLiteralPart inv: attribute.type.conformsTo(value.type )

  • Reported: OCL 2.0 — Wed, 14 May 2008 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: A.2.5.2 Definition A.24 (Type Expressions)

  • Key: OCL21-313
  • Legacy Issue Number: 12460
  • Status: closed  
  • Source: Net.Orange (i.e. Net Dot Orange) ( Garr Lystad)
  • Summary:

    This may not have been a problem with earlier versions of Adobe Acrobat/Reader but in looking at this section I see two typographical representations of "T-hat". The first two occurances are the letter T followed by a small circumflex substript. Subsequent occurances are a large circumflex followed by the letter T. It would be nice if this were fixed to be consistent, and even nicer if the circumflex could be placed over the T, as I imagine was intended.

  • Reported: OCL 2.0 — Wed, 14 May 2008 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: Definition A.23 (Semantics of Navigation Operations)

  • Key: OCL21-312
  • Legacy Issue Number: 12459
  • Status: closed  
  • Source: Net.Orange (i.e. Net Dot Orange) ( Garr Lystad)
  • Summary:

    Maybe I misunderstand, but it seems to me that L(as)(ci), as defined, has some problems: 1. "(c1, . . . , c i, . . . , c j , . . . , c n )" is undefined in that one doesn't know what it is, and 2. c is undefined in "sCLASS(c)". It seems to me that what you want is "L(as)(ci) =

    {cj | i ? j ? (c1, . . . , ci, . . . , cj , . . . , cn ) ? I-sub-ASSOC(as)}

    " - where the characters following the c's are subscripts and each such combination should be underlined to show that it is an object, - and where I-sub-ASSOC(as) is an italic I with a subscripted "ASSOC(as)".

  • Reported: OCL 2.0 — Wed, 14 May 2008 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

There are two instances of missing and misplaced parentheses

  • Key: OCL21-317
  • Legacy Issue Number: 12470
  • Status: closed  
  • Source: Net.Orange (i.e. Net Dot Orange) ( Garr Lystad)
  • Summary:

    There are two instances of missing and misplaced parentheses. One is near the bottom of page 195 in the definition of I(count). The line begins, "I(count : Bag)(t) x t ? Integer)". That last closing paren does not match anything. I believe the line should instead begin "(I(count) : Bag(t) x t ? Integer) The other is at the top of page 196. It is currently "I(count : Collection)(t) x t ? Integer)(c,v)" and, I believe, should be "(I(count) : Collection(t) x t ? Integer)(c,v)"

  • Reported: OCL 2.0 — Wed, 14 May 2008 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    Disposition: See Issue 12463 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

A.2.5.5 Collection Operations

  • Key: OCL21-316
  • Legacy Issue Number: 12469
  • Status: closed  
  • Source: Net.Orange (i.e. Net Dot Orange) ( Garr Lystad)
  • Summary:

    In the paragraph under table A.3, toward the end, it says, "... count : Set(t) _ t ! Integer ...." These are the wrong symbols, of course. The underscore should be a cross and the ! should be an arrow. Also, just below this is the definition of I(count). This contains a 2 that should be a 0.

  • Reported: OCL 2.0 — Wed, 14 May 2008 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    Disposition: See Issue 12463 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: A.2.5.8 Sequence Operations

  • Key: OCL21-320
  • Legacy Issue Number: 12473
  • Status: closed  
  • Source: Net.Orange (i.e. Net Dot Orange) ( Garr Lystad)
  • Summary:

    There is one error in Table A.6 in the semantics column for the operation "first". The index should be 1, not i.

  • Reported: OCL 2.0 — Wed, 14 May 2008 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: A.2.5.6 Set Operations Table A.4

  • Key: OCL21-319
  • Legacy Issue Number: 12472
  • Status: closed  
  • Source: Net.Orange (i.e. Net Dot Orange) ( Garr Lystad)
  • Summary:

    Table A.4 has several rows in the Semantics column where a "union" symbol is used where an "intersection" symbol should have been used. These are rows 3, 4, 5, and 6. Table A.5 of section A.2.5.7 has the same problem in rows 3 and 4.

  • Reported: OCL 2.0 — Wed, 14 May 2008 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

OrderedSet collection

  • Key: OCL21-309
  • Legacy Issue Number: 12451
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The OrderedSet collection is a later adjunction with respect to previous versions of OCL. However, it has not been systematically introduced in all relevant places. As one example among many, conformance rules in Table 7.3 (p.12) do not include OrderedSet. Also, the semantics defined in Appendix A should be extended to include OrderedSet. By the way, there is no place where the difference between OrderedSet and Sequence is discussed. From my understanding, they are much like the same concept. If it is not the case, the differences must be explicitly stated.

  • Reported: OCL 2.0 — Wed, 14 May 2008 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: A.2.5.6 Set Operations

  • Key: OCL21-318
  • Legacy Issue Number: 12471
  • Status: closed  
  • Source: Net.Orange (i.e. Net Dot Orange) ( Garr Lystad)
  • Summary:

    The second sentence of this section ends, "... B is a value of type t.". It should say "... B is a value of type Bag(t).

  • Reported: OCL 2.0 — Wed, 14 May 2008 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: A.2.5.5 Collection Operations

  • Key: OCL21-314
  • Legacy Issue Number: 12461
  • Status: closed  
  • Source: Net.Orange (i.e. Net Dot Orange) ( Garr Lystad)
  • Summary:

    The 5th word of this section is "of" but was probably meant to be "on". Also, in Table A.3 in this section the entry in the second row, third column is pretty much unreadable because there are so many symbols written on top of each other. I checked this with Internet Explorer as well as Firefox, in case they affected Adobe Acrobat, but the entry looked equally bad in both.

  • Reported: OCL 2.0 — Wed, 14 May 2008 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: A/2.5.5 Collection Operations - just before table A.3

  • Key: OCL21-315
  • Legacy Issue Number: 12464
  • Status: closed  
  • Source: Net.Orange (i.e. Net Dot Orange) ( Garr Lystad)
  • Summary:

    Just before Table A.3, is a sentence, "For this purpose, C, C, C2 ...." The second "C" should have a subscript "1" and the "C2" should have the 2 as a subscript.

  • Reported: OCL 2.0 — Wed, 14 May 2008 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

The Tuple constructor is problematic

  • Key: OCL21-308
  • Legacy Issue Number: 12450
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The Tuple constructor is problematic. It is not a first-class citizen in the specifications. It appears in many parts but it is not formally introduced.

  • Reported: OCL 2.0 — Wed, 14 May 2008 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 7.3.4

  • Key: OCL21-270
  • Legacy Issue Number: 9796
  • Status: closed  
  • Source: none ( Jorge Bejar)
  • Summary:

    We consider a Sequence of instances of a class called 'Example'. This class has an integer attribute called 'ex'. If we have a method specification written as follow: pre: datalist->isTypeOf(Sequence(Example)) post: Sequence

    {1..datalist->size()}

    >forAll(n | datalist>at.ex = datalist@pre->at.ex) I not sure if is correct writes the same specification with the next sentences: pre: datalist->isTypeOf(Sequence(Example)) post: datalist->forAll(n | n.ex = n@pre.ex) The generic questions is: What does the '@pre' operator mean when it is applied to iterators variables (as 'n' in the example)? Is correct the @pre use in this cases? I hope you understand my dude and sorry any gramatical error because my written english is very poor.

  • Reported: OCL 2.0 — Sat, 27 May 2006 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Wrong subtyping of PropertyCallExp and NavigationCallExp

  • Key: OCL21-269
  • Legacy Issue Number: 9405
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    In section 8.3.2 of ptc/05-06-06 PropertyCall is shown as a subclass of NavigationCallExp -this seems the wrong way round: NavigationCallExp seems to be a specialization for when the Property is an AssociationEnd. To illustrate this, the description of NavigationCallExp starts with the following, which would not apply if the Property in question were an ownedAttribute of a class:
    "A NavigationCallExp is a reference to an AssociationEnd or an AssociationClass defined in a UML model."

  • Reported: OCL 2.0 — Tue, 28 Feb 2006 05:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

inability to uniquely reference association ends

  • Key: OCL21-268
  • Legacy Issue Number: 9404
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Section 7.5.3 of ptc/05-06-06 starts with the following: "Starting from a specific object, we can navigate an association on the class diagram to refer to other objects and their properties. To do so, we navigate the association by using the opposite association-end:"

    However, unlike in UML 1.x, in UML2 this may well be ambiguous (since names of ends owned by Associations only have to be unique within the Association and not within the context of the Class).
    OCL should therefore explicitly allow qualification using the name of the Association itself as well as the end name (it is not clear whether this is currently allowed as part of the syntax for 'associationendname' so there should be an example to show this. This would make it consistent with the metamodel which allows reference to specific Properties.

    For example we could have associations A1 and A2 both linking classes C1 and C2 and each with ends c1 and c2 owned by the respective associations.
    OCL does not then address the fact that aC1.c2 is ambiguous - unlike the case with unnamed ends it does not even say that it may be ambiguous and is hence disallowed.
    However rather than disallowing the navigation OCL should have a syntax to allow qualification by the association name
    For example aC1.A1::c2

    The same could be used for missing association end names: If A1 had unnamed ends then one could use aC1.A1::C2

  • Reported: OCL 2.0 — Tue, 28 Feb 2006 05:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Introduction and oclType()

  • Key: OCL21-267
  • Legacy Issue Number: 9171
  • Status: closed  
  • Source: SAP SE ( Murray Spork)
  • Summary:

    I only recently joined the OCL rtf at the request of David Frankel (who
    is now with SAP) - I have not seen any activity on this mailing list as
    yet so I hope this is an appropriate forum to raise this question.

    First let me introduce myself - I am lead for a proof-of-concept project
    investigating the use of OCL to express integrity constraints on models.
    Hopefully I will get a chance next year to attend a f2f meeting so that
    I can meet you all.

    On to my specific question: we have noticed that some time between OCL
    1.1 and UML 1.4 "oclType", as a predefined feature, was removed. (I have
    been unable to find any versions of OCL between 1.1 and UML 1.4).

    I thought it would be best if we found out whether this removal was
    intentional before officially raising it as an issue. The reason is that
    we find a) this is a useful reflective feature to have and 2) it is
    still used in some current OMG specifications (note that it is used
    inconsistently).
    e.g.:

    • UML2 Infrastructure - (ptc/03-09-15) pg.89:
      Classifier::maySpecializeType(c : Classifier) : Boolean;
      maySpecializeType = self.oclIsKindOf(c.oclType)
    • Meta Object Facility (MOF) 2.0 Core Specification (ptc/03-10-04) -
      pg.68
      ExtentImpl::addObject(ObjectInstance o, String suppliedId
      [0..1]): String
      pre: not(self.entry.identifier includes suppliedId)
      post: oclIsNew(e) and oclType(e) = IdentifierEntry and
      e.object = o and
      self.entry includes e
      self.entry->select(ex | ex.identifier = e.identifier)->size() =
      1 – the new id is unique and
      (suppliedId <> null implies e.identifier = suppliedId)
  • Reported: OCL 2.0 — Sun, 13 Nov 2005 05:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Circular imports

  • Key: OCL21-266
  • Legacy Issue Number: 8982
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Are two packages allowed to mutually import each other? I can't find
    anything preventing this in the spec, but was wondering if it causes
    some kind of "infinite" import loop.

  • Reported: OCL 2.0 — Sat, 27 Aug 2005 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 7.5.9

  • Key: OCL21-272
  • Legacy Issue Number: 9914
  • Status: closed  
  • Source: LIANTIS GmbH ( Constantin Szallies)
  • Summary:

    The spec states: ---- The operation oclInState(s) results in true if the object is in the state s. Values for s are the names of the states in the statemachine(s) attached to the Classifier of object. ---- How does this relate to the uml metamodell? A BehavioredClassifier may have several ownedBehaviors but only one of those behaviors may be the behavior of the classifier himself. The other behaviors may be specifications for behavioral features of the classifier. ---- Clarification: Possible states for the operation oclInState(s) are all states of the statemachine that defines the classifier's behavior (property 'classifierBehavior' of the 'BehavioredClassifier' metaclass).

  • Reported: OCL 2.0 — Tue, 11 Jul 2006 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 8.3.5

  • Key: OCL21-271
  • Legacy Issue Number: 9913
  • Status: closed  
  • Source: LIANTIS GmbH ( Constantin Szallies)
  • Summary:

    The abstract syntax defines the classes NullLiteralExp and InvalidLiteralExp but the concrete syntax does not define these literal values. — I would like to return 'null' in certain OCL expressions for example: context Person::foo() : Person body: if age > 10 then self else null endif Currenty the only correct way to do this is not very straight forward: context Person::foo() : Person body: if age > 10 then self else OclVoid.allInstances()->any() endif The same is true for the singelton instance of OclUndefined.

  • Reported: OCL 2.0 — Tue, 11 Jul 2006 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

sub evaluations (02)

  • Key: OCL21-248
  • Legacy Issue Number: 7546
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    38. – [1] All sub evaluations have a different environment. The first sub evaluation
    – will start with an environment in which all iterator variables are bound to
    – the first element of the source, plus the result variable which is bound to
    – the init expression of the variable declaration in which it is defined.
    context IterateExpEval
    inv: let bindings: Sequence( NameValueBinding ) =
    iterators->collect( i |
    NameValueBinding( i.varName, source->asSequence()->first() ))
    in
    bodyEvals->at(1).environment = self.environment->addAll( bindings )
    ->add( NameValueBinding( result.name, result.initExp.resultValue ))
    ==> ’varName’ should be ’value’

  • Reported: OCL 2.0b2 — Thu, 10 Jun 2004 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    yes

  • Updated: Fri, 6 Mar 2015 20:58 GMT

sub evaluations

  • Key: OCL21-247
  • Legacy Issue Number: 7545
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    37. – [1] All sub evaluations have a different environment. The first sub evaluation
    – will start with an environment in which all iterator variables are bound to
    – the first element of the source, plus the result variable which is bound to
    – the init expression of the variable declaration in which it is defined.
    context IterateExpEval
    inv: let bindings: Sequence( NameValueBindings ) =
    iterators->collect( i |
    NameValueBinding( i.varName, source->asSequence()->first() ))
    in
    bodyEvals->at(1).environment = self.environment->addAll( bindings )
    ->add( NameValueBinding( result.name, result.initExp.resultValue ))
    ==> ’NameValueBindings’ should be ’NameValueBinding’

  • Reported: OCL 2.0b2 — Thu, 10 Jun 2004 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    yes

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 7.5.11

  • Key: OCL21-254
  • Legacy Issue Number: 8625
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    The example of Set

    {1,2,5,88}

    is more of an example of an ordered set as is Set

    {'apple','orange','strawberry'}

    . The example of a Sequence

    {1,3,45,2,3}

    does not exhibit any apparent order although a Sequence is defined as an ordered Bag. It might be wise to alter these examples to: Set

    {1,88,5,2}

    , Set ['strawberry','apple','orange'} and Sequence

    {1,2,3,3,45}
  • Reported: OCL 2.0b2 — Thu, 24 Mar 2005 05:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    Yes. But reverse the sequence to clarify that the ordering may not be the obvious one. Also correct the punctuation.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 7.5.9

  • Key: OCL21-253
  • Legacy Issue Number: 8624
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Although the definition of oclAsType may be obvious, this is an appropriate sub-section to place a paragraph describing oclAsType. It is the only prrdefined property on All Objects that is not defined in this section.

  • Reported: OCL 2.0b2 — Thu, 24 Mar 2005 05:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    yes

  • Updated: Fri, 6 Mar 2015 20:58 GMT

value of a collection range

  • Key: OCL21-246
  • Legacy Issue Number: 7544
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    36. – [1] The value of a collection range is the range of integer numbers between
    – the result value of its first expression and its last expression.
    context CollectionRangeEval
    inv: element.isOclType( Sequence(Integer) ) and
    element = getRange( first->oclAsType(Integer), last->oclAsType(Integer) ==> ’isOclType’ should be ’oclIsTypeOf’

  • Reported: OCL 2.0b2 — Thu, 10 Jun 2004 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    ’isOclType’ was fixed in OCL 2.3.
    Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

value of a collection range

  • Key: OCL21-245
  • Legacy Issue Number: 7541
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    33. – [1] The value of a collection range is the range of integer numbers between
    – the result value of its first expression and its last expression.
    context CollectionRangeEval
    inv: element.isOclType( Sequence(Integer) ) and
    element = getRange( first->asOclType(Integer), last->asOclType(Integer)
    )
    ==> ’asOclType’ should be ’oclAsType’ (twice)

  • Reported: OCL 2.0b2 — Thu, 10 Jun 2004 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    ’asOclType’ was fixed in OCL 2.3.
    Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 6.5.4.3 Combining Properties

  • Key: OCL21-249
  • Legacy Issue Number: 7722
  • Status: closed  
  • Source: BBDO InterOne ( Jasper Ullrich)
  • Summary:

    "[1] Married people are of age >= 18 context Person inv: self.wife->notEmpty() implies self.wife.age >= 18 and self.husband->notEmpty() implies self.husband.age >= 18" has to be "[1] Married people are of age >= 18 context Person inv: (self.wife->notEmpty() implies self.wife.age >= 18) and (self.husband->notEmpty() implies self.husband.age >= 18)" because of the precedence rules
    same mistake in http://www.omg.org/docs/ptc/03-10-14.pdf, "UML 2.0 OCL Final Adopted specification", chapter 7.5.3, page 18.

  • Reported: OCL 2.0b2 — Thu, 9 Sep 2004 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    yes

  • Updated: Fri, 6 Mar 2015 20:58 GMT

result value of an attribute call expression

  • Key: OCL21-243
  • Legacy Issue Number: 7537
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    29. – [1] The result value of an attribute call expression is the value bound to the
    – name of the attribute to which it refers.
    context AttributeCallExpEval inv:
    resultValue = if source.resultValue->isOclType(
    OCLDomain::Values::ObjectValue) then
    source.resultValue->asOclType( ObjectValue )
    .getCurrentValueOf(referredAttribute.name)
    else – must be a tuple value
    source.resultValue->asOclType( TupleValue )
    .getValueOf(referredAttribute.name)
    endif
    ==> ’isOclType’ should be ’oclIsTypeOf’
    ==> ’asOclType’ should be ’oclAsType’
    ==> ’name’ should be ’value’ (twice)

  • Reported: OCL 2.0b2 — Thu, 10 Jun 2004 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    ’isOclType’ and ’asOclType’ were fixed in OCL 2.3.
    Yes. value rather than name

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 7.4.5

  • Key: OCL21-251
  • Legacy Issue Number: 8621
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Typo - In the 2nd para, 3rd sent., the "t" of "type conformance error" is not italicized as is the rest of the phrase. Table 4 does not address the UML 2.0 (pct/04-10-02)use of UnlimitedNaturals as a type. This type probably Conforms to/Is a subtype of Real since UnlimitedNaturals are integers equal to or greater than 0.

  • Reported: OCL 2.0b2 — Wed, 23 Mar 2005 05:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    The italics are fixed in OCL 2.3.
    Subtyping is resolved by Issue 15780.
    Disposition: See issue 15780 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 7.5.3

  • Key: OCL21-252
  • Legacy Issue Number: 8622
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Typo - 2nd line of para under Missing AssociationEnd names, add a "s" to "tarting." Combining Properties example [2] does not show/express any combined properties; it just expresses the size property of the set employee.

  • Reported: OCL 2.0b2 — Wed, 23 Mar 2005 05:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    The paragraph containing the typo was removed in OCL 2.3.
    In the context of Section 7, Operation is a property so there is a combination in the example..
    Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 7.4

  • Key: OCL21-250
  • Legacy Issue Number: 8620
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    I'm not certain if I should report this issue to the OCL group or to the UML Superstructure group, but... the Basic Types listed in OCL do not agree with the Primitive Types listed in the UML Superstucture. OCL lists "Real" as a primitive (basic type), UML Superstructure does not, instead listing UnlimitedNatural as a primitive type. Shouldn't the two agree?

  • Reported: OCL 2.0b2 — Wed, 23 Mar 2005 05:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    UML 2.5 introduces Real. UnlimiteralNatural has been in UML for a long time.
    Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

result value of a collection literal expression evaluation

  • Key: OCL21-244
  • Legacy Issue Number: 7539
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    31. – [2] The result value of a collection literal expression evaluation is a
    – collection literal value, or one of its subtypes.
    context CollectionLiteralExpEval inv:
    resultValue.isOclKind( OCLDomain::Values::CollectionValue )
    ==> ’isOclKind’ should be ’oclIsKindOf’

  • Reported: OCL 2.0b2 — Thu, 10 Jun 2004 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    ’isOclType’ and ’asOclType’ were fixed in OCL 2.3.
    Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Issue: Syntax of Operation Call, Iterator, and Iterate Expressions

  • Key: OCL21-204
  • Legacy Issue Number: 6571
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Description: Syntax for the above constructions is extremely ambiguous and it might involve backtracking.
    Rationale: According to OCL specification

    • self.f(x, y)
    • Set {1,2,3}

      ->select(x, y| x+y = 3)

    • Set {1,2,3,4,5,6}

      ->iterate(x; acc:Integer=0 | acc + x)
      describe an operation call, an iterator, and an iterate expression.
      In order to make the distinction between an iterator call and an operation call we need in this case a three token lookahead, starting from x. The problem gets even more complicated if we consider that an argument for an operation call can be an expression.
      In order to solve this problem, which is a potential source of problems for the implementation (error-prone, inefficiency aso), we think that these OCL constructs should contain some extra syntax markers. There are several choices:

    • change the comma marker from iterator calls to something else, maybe a semicolon
    • add a syntax marker to an iterator name
    • do not allow the default types
      The above choices will allow to a deterministic parser to deal with the enumerated problems more efficiently. I do not agree with textual language in which variables are given a default type according to the context in which they are used, especially if these languages are design for industrial use. The same problems were in previous versions of C standard, which allowed implicit type int for variables in constructions like
      x;
      Now, the latest C standard states that variables with default type are not allowed.
  • Reported: OCL 2.0b2 — Tue, 11 Nov 2003 05:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    The exposition of the OCL grammar is poor. In OCL 2.3 the status of iterator names was clarified as not-reserved words which makes the naive parsing approach outlined above more challenging. Instead it is necessary to pursue a syntactic parse and then resolve semantics in a tree walk. The 'problems' have not prevented OCL tool being built.
    Users would not be well-served by a major resyntaxing to introduce new punctuation.
    Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Issue: Abstract syntax tree

  • Key: OCL21-203
  • Legacy Issue Number: 6566
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Description: Some of the elements presented in 3.3.10 (e.g. EnumLiteralExp, children of ModelPropertyCallExp) cannot be constructed without using semantic information (e.g. the type of the expression determines if a name denotes an attribute, an association end, or an operation).
    Rationale: Usually a parser produces an AST. The semantic analyser augments the AST by computing for each node from AST the values of the attached attributes. The semantic analysis also checks if there are static semantics errors and reports them. Using other terms in the AST and hence other non-terminals in 4.5 (e.g. dot-selection-expression, arrow-selection-expression, call-expression etc.) will solve this problem.

  • Reported: OCL 2.0b2 — Tue, 11 Nov 2003 05:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    The exposition of the OCL grammar is poor, but it is possible to resolve context pursuing a left to right analysis of an expression. It is also possible to perform a syntactic parse and then resolve semantics in a tree walk.The 'problems' have not prevented OCL tool being built.
    Users would not be well-served by a major resyntaxing to introduce new operators that required the user to have greater understanding of the metamodels.
    Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

The notation for selecting elements should be more intuitive

  • Key: OCL21-208
  • Legacy Issue Number: 6880
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    Suggestion: Use brackets as an alternate option to denote a call to the "select"
    function. Notation: mylist[iterator | condition]
    Example:
    self.ownedElementClass and name="MyClass"
    – #Class is a shorthand for oclIsKindOf(MyClass)
    equivalent to :
    self.ownedElement->select(oclIsKindOf(Class) and name="MyClass")

  • Reported: OCL 2.0b2 — Wed, 7 Jan 2004 05:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    The suggested syntax comes from QVTo.
    Non-trivial OCL expressions can be difficult to read. Introducing shorthand notations compromises readability. At present OCL has "." and "->" shorthands that cause significant difficulties. Introducing more does not seem appropriate for the standard language.
    It is not clear that introduction of another [..] syntax can avoid conflicts with the already challenging conflicts for association qualifiers and array indexes.
    Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

The notation for testing the type of a metaclass is too verbose

  • Key: OCL21-207
  • Legacy Issue Number: 6879
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    Suggestion: Use special characters to denote a call to oclIsKindOf and oclIsTypeOf.
    For instance, use '#ActionState' instead of 'oclIsKindOf(ActionState)'
    and use '##ActionState' instead of 'oclIsTypeOf(ActionState)'

  • Reported: OCL 2.0b2 — Wed, 7 Jan 2004 05:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    The suggested syntax comes from QVTo.
    Non-trivial OCL expressions can be difficult to read. Introducing shorthand notations compromises readability. At present OCL has "." and "->" shorthands that cause significant difficulties. Introducing more does not seem appropriate for the standard language.
    oclIsKindOf and oclIsTypeOf are already a source of confusion; oclIsTypeOf should rarely be used but is the more obvious name to new users, so providing a shorthand for oclIsTypeOf is unnecessary.
    The # syntax has no terminator so the shorthand needs an ambiguity resolution for a.#B.c()
    The suggested usage seems to conflict with the intuition of those familiar with unary prefixes of assembler languages or even OCL 1.x enumeration literals.
    If an improvement is to be made, something like
    (a as B).c()
    would contribute to rather than hamper readibility.
    Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Example with TupleType

  • Key: OCL21-206
  • Legacy Issue Number: 6614
  • Status: closed  
  • Source: Modeling Value Group ( Wim Bast)
  • Summary:

    Typo in an example with TupleType Section 7.5.15: In the example constraint, expression attr: Statistics : Set(TupleType(& This must be Tuple only, according to the concrete syntax.

  • Reported: OCL 2.0b2 — Thu, 13 Nov 2003 05:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    The typos are corrected in the overlapping Issue 15254.
    Disposition: See issue 15254 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Improve the notation when defining local variables

  • Key: OCL21-211
  • Legacy Issue Number: 6885
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    This is to avoid using the unreadable and unfriendly "let … in …" notation.
    Suggestion: Use the result of a variable initialization as in:
    if (let c = self.address)="" then "UNKNOWN"
    else if c.includes(Set

    {"Irak","Afganifsthan"}

    ) then "DANGEROUS"
    else "OK" endif endif endif …

  • Reported: OCL 2.0b2 — Wed, 7 Jan 2004 05:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    OCL 2.3 relaxed a VariableDeclarationCS to permit the typeCS to be omitted and deduced from the initializer.
    Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

There is no simple way to invoke an "if then else" on a collection

  • Key: OCL21-210
  • Legacy Issue Number: 6882
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    Suggestion: Define an "alt" collection function, with a specific notation, as in:
    mylist->alt(iterator | condition? thenExp, elseExp)
    The expression elseExp is not evaluated if condition returns true

  • Reported: OCL 2.0b2 — Wed, 7 Jan 2004 05:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    It is not true that there is no way:
    mylist->collect(iterator | if condition then thenExp else elseExp endif)
    which has two more tokens than the suggestion but avoids introducing a "?" syntax irregularity.
    Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

notation for selecting unique element within a list should be more concise

  • Key: OCL21-209
  • Legacy Issue Number: 6881
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    Suggestion: Use brackets with a "!" prefixing mark
    Example:
    self.ownedElement! #Class and name="MyClass"
    means
    self.ownedElement->select(oclIsKindOf(Class) and name="MyClass")->first()

  • Reported: OCL 2.0b2 — Wed, 7 Jan 2004 05:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    The suggested syntax comes from QVTo.
    Non-trivial OCL expressions can be difficult to read. Introducing shorthand notations compromises readability. At present OCL has "." and "->" shorthands that cause significant difficulties. Introducing more does not seem appropriate for the standard language.
    Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Provide specific notational support when testing stereotypes

  • Key: OCL21-216
  • Legacy Issue Number: 6893
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    Suggestion: Use the STAR character. Quotes could be used in case of blanks
    characters in stereotype names.
    Example: self.ownedElement.select(kindOf(Class) and *EJBEntity)
    returns all the classes stereotyped by the EJBEntity stereotype or a derived
    stereotype.
    Example: self.ownedElement.select(kindOf(Class) and **EJBEntity)
    returns all the classes stereotyped by the EJBEntity stereotype.

  • Reported: OCL 2.0b2 — Wed, 7 Jan 2004 05:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    Stereotype support is certainly required, but I think much of the trouble is inadequate tooling. The examples can be realised by:
    self.ownedElement->select(oclIsKindOf(Class)).oclAsType(Class) ->select(extension_EJBEntity <> null)
    self.ownedElement->select(oclIsKindOf(Class)).oclAsType(Class) ->select(extension_EJBEntity.oclIsTypeOf(EJBEntity))
    The clumsy ->select(oclIsKindOf(Class)).oclAsType(Class) 'idiom' is resolved by the selectByKind library operation from Issue 18829 to give
    self.ownedElement->selectByKind(Class)->select(extension_EJBEntity <> null)
    self.ownedElement->selectByKind(Class)->select(extension_EJBEntity.oclIsTypeOf(EJBEntity))
    Given that UML specified the magic "extension_" and "base_" prefixes, it seems best to encourage rather than obscure them.
    Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Suppress the usage of an Ocl prefix in standard library operations

  • Key: OCL21-215
  • Legacy Issue Number: 6890
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    When a name conflicts happen, it should be possible to resolve by qualifying the
    names.

  • Reported: OCL 2.0b2 — Wed, 7 Jan 2004 05:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    It is not really clear what this is issue is about.
    Perhaps the suggestion is to allow users to write x.isKindOf(Y) rather than x.oclIsKindOf(Y).
    There is a small benefit but also a confusion between alternate syntaxes and a need to change syntaxes to avoid confusion occasionally. Confusion is best avoided.
    Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Issue: Unspecified syntax and semantics for Integer, Real, and String

  • Key: OCL21-202
  • Legacy Issue Number: 6561
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Description: The specification does not describes the syntax of integer, real or string literals. Also, it does not contain the description of the allowed set of values.
    Rationale: Specifying the syntax and the semantics of basic types will increase the portability of OCL programs. In order to describe the semantics of basic types, the specification should describe the set of values, the allowed operations, and the standard used to perform the allowed operations. I think that it will be also useful to allow different types of integers and reals, like Integer(16), Integer(32), Integer(64), Real(32), and Real(64), in order to optimize the computational process.

  • Reported: OCL 2.0b2 — Tue, 11 Nov 2003 05:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    OCL 2.3 introduced concrete syntax specifications for integer, real or string literals.
    In regard to specific sets of values, the issue seems to indicate a misunderstanding of OCL; OCL is a specification language that may be evaluated. Integers and Reals are unlimited. If a particular implementation chooses to use a restricted value set, then it is for that implementation to prove that its reduced range is appropriate.
    Users can of course define their own DataTypes with whatever characteristics they find suitable.
    Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Allow implicit type casting to boolean when a boolean is expected

  • Key: OCL21-213
  • Legacy Issue Number: 6887
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    Example1: if list.select(...) then … equivalent to
    if list.select(...)->notEmpty() then …
    Example2: if item then … equivalent to
    if item<>OCLUndefined then ...

  • Reported: OCL 2.0b2 — Wed, 7 Jan 2004 05:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    The suggestion introduces a confusion for Boolean variables that may be null. For these variables <> null is required while for non-Boolean variables it can be omitted.
    This seems to be a significant degradation in type safety. Not even Java permits this freedom.
    Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Allow applying iteration operations on single objects

  • Key: OCL21-212
  • Legacy Issue Number: 6886
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    Use a DOT instead of an ARROW is this situation.
    myinstance.anycollectionfunction() equivalent to
    Set

    {myinstance}

    ->anycollectionfunction(…)->first()

  • Reported: OCL 2.0b2 — Wed, 7 Jan 2004 05:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    The usage of "." and "-"> in OCL is already confusing for many users. However there is a rationale.
    Introduction of a freedom to use "." will undermine user understanding in exchange for a minor convenience in a rare use case..
    Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Automatic casting between strings and enumeration values

  • Key: OCL21-214
  • Legacy Issue Number: 6889
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    Make optional the qualification of enumeration values.
    Example: Be able to write 'self.aggregationKind="Composite" ' as an alternative
    to 'self.aggregationKind=AggregationKind::Composite'.

  • Reported: OCL 2.0b2 — Wed, 7 Jan 2004 05:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    This seems like a harmless simplification (using OCL's single quotes rather than a Java-like double quotes), but creating a confusion between Strings and EnumerationLiterals may cause confusion when selecting operation overloads.
    Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Add a generic text formatter operator '%

  • Key: OCL21-217
  • Legacy Issue Number: 6894
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    Example: self.comment = "My name is %s" % self.firstname

  • Reported: OCL 2.0b2 — Wed, 7 Jan 2004 05:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    Presumably the suggestion is to build C's printf into OCL.
    However experience with printf has shown that it has significant type safety issues.
    I think a better solution requiring no change to the OCL language would be a String::printf() Standard Library operation.
    'My name is %s'.printf(self.firstname)
    Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

The index seems incomplete

  • Key: OCL21-205
  • Legacy Issue Number: 6600
  • Status: closed  
  • Source: Modeling Value Group ( Wim Bast)
  • Summary:

    The index seems incomplete and leaves out interesting items (e.g., the definition of standard library functions).

  • Reported: OCL 2.0b2 — Wed, 12 Nov 2003 05:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    Inaccurate manually maintained indexes are discouraged in OMG specifications.
    The Index was accidentally omitted in OCL 2.3. It will not be re-instated.
    Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

arguments of the return message of an ocl message expression

  • Key: OCL21-234
  • Legacy Issue Number: 7523
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    15. – [5] The arguments of the return message of an ocl message expression
    – evaluation must correspond to the names given by the formal output parameters,
    – and the result type of the operation indicated in the ocl message expression.
    – Note that the Parameter type is defined in the UML 1.4 foundation package.
    context OclMessageExpEval
    inv: let returnArguments: Sequence{ NameValueBindings ) =
    resultValue.returnMessage.arguments ,
    formalParameters: Sequence

    { Parameter }

    =
    ==> ’

    {’ should be ’(’ (twice), and ’}

    ’ should be ’)’

  • Reported: OCL 2.0b2 — Thu, 10 Jun 2004 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    yes

  • Updated: Fri, 6 Mar 2015 20:58 GMT

inv: model.sentSignal->size() = 1 implies

  • Key: OCL21-233
  • Legacy Issue Number: 7522
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    Sequence

    {1.. arguments->size()}

    ->forAll( i |
    arguments->at.variable->size() = 1 implies
    model.sentSignal.signal.feature->select(
    arguments->at.variable )->notEmpty()
    and
    arguments->at.expression->size() = 1 implies
    model.sentSignal.signal.feature.oclAsType(StructuralFeature).type =
    arguments->at.expression.model
    ==> missing final closing bracket

  • Reported: OCL 2.0b2 — Thu, 10 Jun 2004 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    yes

  • Updated: Fri, 6 Mar 2015 20:58 GMT

’element’ should be ’elements’

  • Key: OCL21-236
  • Legacy Issue Number: 7525
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    17. – [1] All elements belonging to a sequence value have unique index numbers.
    inv: self.element->isUnique(e : Element | e.indexNr)
    ==> missing context statement: context SequenceTypeValue,
    ==> ’element’ should be ’elements’

  • Reported: OCL 2.0b2 — Thu, 10 Jun 2004 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    yes

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Only one of the attributes isPost and isPre may be true at the same time.

  • Key: OCL21-235
  • Legacy Issue Number: 7524
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    16. – [1] Only one of the attributes isPost and isPre may be true at the same time.
    context LocalSnapshot
    inv: isPost implies isPre = false
    inv: ispre implies isPost = false
    ==> second invariant: ’ispre’ should be ’isPre’

  • Reported: OCL 2.0b2 — Thu, 10 Jun 2004 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    yes

  • Updated: Fri, 6 Mar 2015 20:58 GMT

elements in a tuple value

  • Key: OCL21-242
  • Legacy Issue Number: 7531
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    23. – [1] The elements in a tuple value must have a type that conforms to the type
    – of the corresponding tuple parts.
    context TupleValue inv:
    elements->forAll( elem |
    let correspondingPart: Attribute =
    self.model.allAttributes()->select( part | part.name = elem.name ) in elem.value.model.conformsTo( correspondingPart.type ) )
    ==> ’Attribute’ should be ’UML14::Core::Attribute’
    ==> ’select’ should be ’any’

  • Reported: OCL 2.0b2 — Thu, 10 Jun 2004 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No: OCL 2.4 does not yet have a UML-aligned type system so the UML14::Core:: is a solution for one particular tool. The prefix certainly shouldn't be UML14. It is likely that the UML aligned solution will not require a prefix at all legitimizing the original exposition.
    Yes: any rather than select

  • Updated: Fri, 6 Mar 2015 20:58 GMT

arguments

  • Key: OCL21-232
  • Legacy Issue Number: 7521
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    13. – [4] The arguments of an ocl message expression evaluation must correspond to
    – the formal input parameters of the operation, or the attributes of the signal
    – indicated in the ocl message expression.
    context OclMessageExpEval
    inv: model.calledOperation->size() = 1 implies
    Sequence

    {1.. arguments->size()}

    >forAll( i | arguments>at.variable->size() = 1 implies
    model.calledOperation.operation.parameter->
    select( kind = ParameterDirectionKind::In )->at.name =
    arguments->at.variable
    and
    arguments->at.expression->size() = 1 implies
    model.calledOperation.operation.parameter->
    select( kind = ParameterDirectionKind::In )at.type =
    arguments->at.expression.model
    ==> missing ’->’ before ’at’, and missing final closing bracket

  • Reported: OCL 2.0b2 — Thu, 10 Jun 2004 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    yes

  • Updated: Fri, 6 Mar 2015 20:58 GMT

The history of an object is ordered.(02)

  • Key: OCL21-240
  • Legacy Issue Number: 7529
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    21. – [1] The history of an object is ordered. The first element does not have a
    – predecessor, the last does not have a successor.
    context ObjectValue
    inv: history->oclIsTypeOf(
    StandardLibrary::StdLib.Sequence(LocalSnapShot) )
    inv: history->last().succ->size = 0
    inv: history->first().Pre->size = 0
    ==> ’size’ should be ’size()’ (twice)

  • Reported: OCL 2.0b2 — Thu, 10 Jun 2004 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    Yes, although the affected text changed slightly in OCL 2.2.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

The operation allPredecessors

  • Key: OCL21-241
  • Legacy Issue Number: 7530
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    22. – [1] The operation allPredecessors returns the collection of all snapshots
    – before a snapshot, allSuccessors returns the collection of all snapshots after
    – a snapshot.
    context LocalSnapshot
    def: allPredecessors() : Sequence(LocalSnapshot) =
    if pred->notEmpty then
    pred->union(pred.allPredecessors())
    else
    Sequence {}
    endif
    def: allSuccessors() : Sequence(LocalSnapshot) =
    if succ->notEmpty then
    succ->union(succ.allSuccessors())
    else
    Sequence {}
    endif
    ==> ’notEmpty’ should be ’notEmpty()’ (twice)

  • Reported: OCL 2.0b2 — Thu, 10 Jun 2004 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    yes

  • Updated: Fri, 6 Mar 2015 20:58 GMT

history of an object is ordered.

  • Key: OCL21-239
  • Legacy Issue Number: 7528
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    20. – [1] The history of an object is ordered. The first element does not have a
    – predecessor, the last does not have a successor.
    context ObjectValue
    inv: history->oclIsTypeOf( Sequence(LocalSnapShot) )
    inv: history->last().succ->size = 0
    inv: history->first().Pre->size = 0
    ==> should be:
    context ObjectValue
    inv: history->oclIsTypeOf(
    StandardLibrary::StdLib.Sequence(LocalSnapShot) )
    inv: history->last().succ->size = 0
    inv: history->first().Pre->size = 0

  • Reported: OCL 2.0b2 — Thu, 10 Jun 2004 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    This issue seems to have been corrupted and reentered as Issue 7529..
    Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

’Element’ should be ’NameValueBinding’

  • Key: OCL21-238
  • Legacy Issue Number: 7527
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    19. – [1] All elements belonging to a tuple value have unique names.inv: self.elements->isUnique(e : Element | e.name)
    ==> missing context statement: context TupleValue
    ==> ’Element’ should be ’NameValueBinding’

  • Reported: OCL 2.0b2 — Thu, 10 Jun 2004 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    yes

  • Updated: Fri, 6 Mar 2015 20:58 GMT

’element’ should be ’elements’ (02)

  • Key: OCL21-237
  • Legacy Issue Number: 7526
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    18. – [1] All elements belonging to a set value have unique values.
    inv: self.element->isUnique(e : Element | e.value)
    ==> missing context statement: context SetTypeValue
    ==> ’element’ should be ’elements’

  • Reported: OCL 2.0b2 — Thu, 10 Jun 2004 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    yes

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Add select/reject/collectNested to Collection

  • Key: OCL21-198
  • Legacy Issue Number: 6551
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Author: Hubert Baumeister (baumeist@informatik.uni-muenchen.de),
    Rolf Hennicker (hennicke@informatik.uni-muenchen.de),
    Alexander Knapp (knapp@informatik.uni-muenchen.de)
    Description: Add select/reject/collectNested to Collection
    Rationale:
    The definition of any on Collection (page 6-16f.) uses select on Collection. However, select is not defined for Collection. Similarly, the definition of collect on Collection (page 6-17) uses collectNested on Collection, which is not defined on Collection. We therefore propose to add select and collectNested (and possibly reject) to Collection.

  • Reported: OCL 2.0b2 — Tue, 11 Nov 2003 05:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Exception of strict evaluation (queries)

  • Key: OCL21-197
  • Legacy Issue Number: 6540
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Author: Thomas Baar (thomas.baar@epfl.ch)
    Description: Strict evaluation for queries yields to contradictions in specifications
    Rationale: Queries can be specified in two ways, as invariants and in form of pre/post conditions. Suppose we specify query q(arg) as
    post: if (arg.oclIsUndefined()) then result = true else result = false endfi
    Having this, the following invariant should evaluate always to true:
    self.q(arg) = true or self.q(arg) = false.
    However, the invariant evaluates to undef once arg evaluates to undef thanks to strict evaluation.
    There is a misconception of strict evaluation when it comes to queries. The idea of queries is to have user-defined functions on classes. Why should the user be restricted only to such function which return undef once one of its arguments is undef? Using OCL, the user can even specify queries which can handle undefined arguments (e.g. see post specification of q(arg) ). Obviously, the post specification for q(arg) makes sense.
    The rule of strict evaluations for queries should be weakened to the case where the owner of the query (the object upon the query was called) is undefined.

  • Reported: OCL 2.0b2 — Mon, 10 Nov 2003 05:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    This issue was raised before undefined was clarified as null and invalid. It is now permissible to pass null values to queries. Only invalid values cannot be passed.
    Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Issue: Virtual machine

  • Key: OCL21-201
  • Legacy Issue Number: 6559
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Description: The OCL 2.0 specification should be behaviour-oriented and not implementation-oriented (see section 4.3).
    Rationale: The idea of using OCL to describe itself is interesting from the research point of view, but unfortunately OCL is not a suitable metalanguage to define the meaning of other textual languages. I think that the best thing to do is to define a virtual machine and to describe the behaviour of the virtual machine using natural language. This technique was successfully used for languages like C, C+, Java, C#, and Prolog. I see no reasons why such a technique would fail for OCL. After all, OCL is less complex than modern programming language like C+, Java, or C#.
    A proper description and implementation of the OCL virtual machine will create all the conditions to have a language that is platform/tool independent.

  • Reported: OCL 2.0b2 — Tue, 11 Nov 2003 05:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    The specification can no doubt be improved. Most criticisms concern inconsistency and lack of formaility. Moving to "natural language" seems a retrograde approach. Work in progress attempts to remove inconsistency from auto-generation from models, and to improve formality by using an exposition of the semantics that can be checked by Isabelle.
    Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Clarify the UML semantics of IfExpEval

  • Key: OCL21-200
  • Legacy Issue Number: 6554
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Author: Hubert Baumeister (baumeist@informatik.uni-muenchen.de),
    Rolf Hennicker (hennicke@informatik.uni-muenchen.de),
    Alexander Knapp (knapp@informatik.uni-muenchen.de)
    Description: Clarify the UML semantics of IfExpEval
    Rationale:
    The specification on page 5-21 of the evaluation of if_then_else omits the case when the condition evaluates to undefined. Thus the sentence should read:
    "The result value of an if expression is the result of the thenExpression if the condition is true, it is the result of the elseExpression if the condition is false, else it is undefined."

  • Reported: OCL 2.0b2 — Tue, 11 Nov 2003 05:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    The resolution for this becomes more complex with null/invalid rather than undefined. The resolution is in 17531.
    Disposition: See issue 17531 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Exception of strict evaluation (implies)

  • Key: OCL21-195
  • Legacy Issue Number: 6538
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Author: Thomas Baar (thomas.baar@epfl.ch)
    Description: Exception from strict evaluation for IMPLIES is incomplete and contradicts set-theoretical semantics
    Rationale: On page 2-10 only one exception from strict evaluation for IMPLIES is given:
    False IMPLIES x == True
    However, based on the official semantics of IMPLIES given on page A-12
    also x IMPLIES True == True

  • Reported: OCL 2.0b2 — Mon, 10 Nov 2003 05:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    The requested change actually occurred in OCL 2.2. However the clarification of null and invalid for Issue 17531 conflicts with the resolution, so this issue is therefore merged.
    Disposition: See issue 17531 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Exception of strict evaluation (forAll, exists)

  • Key: OCL21-196
  • Legacy Issue Number: 6539
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Author: Thomas Baar (thomas.baar@epfl.ch)
    Description: Exception of strict evaluation should be extended to forAll, exists
    Rationale: Suppose r(o1) = undef, r(o2) = false What is value of Exp =

    {o1, o2}

    ->forAll(x| r) ? One could argue, because of strict evaluation, the value of Exp is undef. However, this would contradict the semantics of forAll als 'iterated and' given on page A.28. Similarily, for exists.
    A note should be added on page 2-10 on evalution of expressions based on iterate.

  • Reported: OCL 2.0b2 — Mon, 10 Nov 2003 05:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    The resolution for this becomes more complex with null/invalid rather than undefined. The resolution is in 17531.
    Disposition: See issue 17531 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Clarify the semantics of forAll

  • Key: OCL21-199
  • Legacy Issue Number: 6553
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Author: Hubert Baumeister (baumeist@informatik.uni-muenchen.de),
    Rolf Hennicker (hennicke@informatik.uni-muenchen.de),
    Alexander Knapp (knapp@informatik.uni-muenchen.de)
    Description: Clarify the semantics of forAll
    Rationale:
    According to the informal explanation (page 6-16) the following Expression Set

    { 1 }

    ->forAll(x | x/0 < 0) would evaluate to false. However, according to the OCL definition it evaluates to undefined. Thus we propose to omit "otherwise, result is false" in the informal explanation.

  • Reported: OCL 2.0b2 — Tue, 11 Nov 2003 05:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    The resolution for this becomes more complex with null/invalid rather than undefined. The resolution is in 17531.
    Disposition: See issue 17531 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Notation for accessing class operations is inconsistent

  • Key: OCL21-265
  • Legacy Issue Number: 8937
  • Status: closed  
  • Source: International Business Machines ( Dr. Tracy Gardner)
  • Summary:

    The OCL 2.0 spec is inconsistent on whether class operations, including predefined operations, should be accessed using '.' or '::' notation.
    E.g. should it be Person.allInstances() or Person::allInstances()

    The spec uses Person.allInstances() in the text, but the concrete syntax specifies '::'.

    It seems that most tools have adopted the '.' notation used in the examples which is also backwards compatible with previous versions of OCL.
    There has also been some adoption of the '::' notation, for example in Warmer and Kleppe's OCL book, see: http://www.klasse.nl/english/boeken/ocl-book-errata.pdf

    Note: This issue was originally pointed out by Anthony Shuttleworth of Paranor.

    Proposed solution:

    The '.' notation is widely used and backwards compatible with previous versions of OCL. It should not be made invalid in OCL 2.0.
    It may be appropriate to also support the '::' notation if this has been widely adopted.

  • Reported: OCL 2.0 — Thu, 21 Jul 2005 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Navigating across non navigable associations

  • Key: OCL21-264
  • Legacy Issue Number: 8918
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The spec ptc/03-10-14 lists navigating across non navigable associations as a compliance point. However, all text describing the rules for doing so have been removed from this version. The rules need to be defined more clearly in the OCL syntax.

    The following rules for navigation using non-navigable associations extend the text in sections 7.5.4 Navigation to Association Classes, and sections 7.5.5 Navigation from Association classes,

    When a non-navigable association is between different classes, following the association to an opposite end class is specified by:
    ("self" | <class name>) "." <association class name>["[" < opposite role name> "]"]"." <role name>

    Note the optional component is redundant, but is allowed, but not recommended.

    When a non-navigable association is between the same classes, following the association to an opposite end class is specified by:
    ("self" | <class name>) "." <association class name>"[" < opposite role name> "]." <role name>

  • Reported: OCL 2.0 — Fri, 8 Jul 2005 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

allInstances

  • Key: OCL21-263
  • Legacy Issue Number: 8917
  • Status: closed  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    It is not entirely clear from the OCL 2.0 specification whether the allInstances operation returns instances of subclasses of the designated type. In other words, it isn't 100% clear whether t.allInstances( ) returns instances of subclasses of t.

    Recommendation:

    The best solution would be to have two operations, one which returns instances of subclasses and one which does not.

    A second-best solution would be to make it clear that allInstances returns instances of subclasses. In this case, an OCL programmer could use the oclIsTypeOf( ) operation as a filter to write a derived operation that does not return instances of subclasses. If allInstances does not return instances of subclasses, it would not be nearly as straightforward to write a derived operation that does return instances of subclasses.

  • Reported: OCL 2.0 — Tue, 12 Jul 2005 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 1 - 13

  • Key: OCL21-261
  • Legacy Issue Number: 8667
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    General comments: OCL primitive types do not agree with UML primitive types. Multiplicity symbology for "infinite" is different. UML uses "*" whereas OCL uses "n." Capitalize the word "Boolean" as it is named for the 19th Century mathematicial George Boole. In most places it is capitalized but there are several places where it is not. I hope my comments have not been too annoying. Please consider everything I know about OCL I have learned from reading this document so if my comments don't make a lot of sense, then possibly clarification in the document may be needed.

  • Reported: OCL 2.0b2 — Wed, 30 Mar 2005 05:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    OCL primitive types now align, since UML has introduced Real.
    */n multiplicity is a drawing tool artefact. It may be resolved when redrawn for an autogenerated OCL 2.5.
    boolean in non-technical contexts can be corrected.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.9.3 & 11.9.4

  • Key: OCL21-260
  • Legacy Issue Number: 8666
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Typo - pg 151 change "The standard iterator expression" to "The standard iterator expressions." The reject expression for both Bag and Sequence have "source->select(iterator | not body) on the left side of the equals symbol. Shouldn't the word "iterate" be used instead of "select?" The sortedBy expression is very restrictive if the sort order must always have the lowest value first. A statement that a sort order could be by a > value would be nice.

  • Reported: OCL 2.0b2 — Wed, 30 Mar 2005 05:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    The typo is actually for Set.
    The wording for reject is correct; reject is defined as select with a not body.
    The sortedBy issue is a repeat of Issue 8665, which remains unresolved. (Maybe we need a sort(i, j | body) iteration so that body can return pairwise comparison which could be in reverse order.)

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.2.1

  • Key: OCL21-258
  • Legacy Issue Number: 8659
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Last line on page is a sentence fragment

  • Reported: OCL 2.0b2 — Tue, 29 Mar 2005 05:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    redundant line

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 10.2.2 LocalSnapshot

  • Key: OCL21-257
  • Legacy Issue Number: 8645
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Typos - Change "ispre" to "isPre" and reword [2] to "...postcondition snapshot does it have an associated..."

  • Reported: OCL 2.0b2 — Mon, 28 Mar 2005 05:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    The typo is corrected in Issue 7524.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 7.5.13

  • Key: OCL21-255
  • Legacy Issue Number: 8626
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    The example using Bike and Car as two separate subtypes of Transport does not make any mention of Set(Car), Bag(car), or Collection(Car). Either delete reference to Car as a separate subtype of Transport or add some comments about a collection of some sort of Car conforming (and not conforming) to some other collection. I may be confused, but the statement "Note that Set(Bicycle) does not conform to Bag(Bicycle)" does not make a lot of sense to me. Wouldn't it be better to say that "Set(Bicycle) does not conform to Bag(car)?"

  • Reported: OCL 2.0b2 — Thu, 24 Mar 2005 05:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    Yes the words can be a little clearer

  • Updated: Fri, 6 Mar 2015 20:58 GMT

The spec does not describes the syntax of integer, real or string literals

  • Key: OCL21-262
  • Legacy Issue Number: 8789
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    1) The specification does not describes the syntax of integer, real or string literals.
    The specification does not describes the syntax of integer, real or string literals.
    Specifying the syntax and the semantics of basic types will increase the portability
    of OCL programs

  • Reported: OCL 2.0b2 — Wed, 18 May 2005 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    These specifications were introduced in OCL 2.3
    Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 11.5.4

  • Key: OCL21-259
  • Legacy Issue Number: 8661
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    What is the difference in meaning between the definitions of or(b:Boolean): Boolean and xor(b:Boolean): Boolean? or(b:Boolean): Boolean says True if either self or b is true which implies "but not both" which is the ending phrase of the definition of xor(b:Boolean): Boolean.

  • Reported: OCL 2.0b2 — Tue, 29 Mar 2005 05:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    The resolution of Issue 17531 rephrased this.
    Disposition: See issue 17531 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 7.6.2

  • Key: OCL21-256
  • Legacy Issue Number: 8627
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    In the 2nd paragraph, shange "The value of the reject operation..." to "The value of the collect operation..."

  • Reported: OCL 2.0b2 — Thu, 24 Mar 2005 05:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    The typo is corrected in Issue 15980.
    Disposition: See issue 15980 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

rewrite well-formedness

  • Key: OCL21-219
  • Legacy Issue Number: 7466
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    We would like to be able to rewrite well-formedness rules like:
    context IfExp
    inv: self.condition.type.oclIsKindOf(Primitive) and
    self.condition.type.name = ’Boolean’
    as
    context IfExp
    inv: self.condition.type.oclIsKindOf(Primitive) and This is more clear that the first expression where the matching is done by name.
    Because the metamodel resides on a level higher than the standard library, we need a way to get access
    to the standard library elements. One solution is to define a package ’StandardLibrary’ that contains a
    Classifier called ’StdLib’, that holds the following attributes:
    • + Collection: CollectionType;
    • + Set: SetType;
    • + OrderedSet: OrderedSetType;
    • + Sequence: SequenceType;
    • + Bag: BagType;
    • + String: Primitive;
    • + OclMessage: OclMessageType;
    • + OclVoid : VoidType;
    Other solutions might be possible, but the above has been proven to work in the Octopus tool.

  • Reported: OCL 2.0b2 — Thu, 10 Jun 2004 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    Unfortunately the 'better' example is missing from the above text. Presumably it should read:
    context IfExp
    inv: self.condition.type.oclIsKindOf(Primitive) and self.condition.type = StdLib::Boolean
    OCL supports type literal as in a.oclIsKindOf(Boolean) so the 1.x practice of comparing types by string-valued name was a misunderstanding. It is possible to write
    inv: self.condition.type.oclIsKindOf(Primitive) and self.condition.type = Boolean
    Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Make usage of tuples less complex and less verbose

  • Key: OCL21-218
  • Legacy Issue Number: 6895
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    Suggestions:

    • Make type spec of internal fields optional.
    • Make field name in tuples optional (using positional access)
  • Reported: OCL 2.0b2 — Wed, 7 Jan 2004 05:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    OCL 2.3 relaxed VariableDeclarationCS to allow inference of an omitted type from an initializer.
    Allowing field names to be omitted and resolved positionally reduces type safety of programs when first written and makes them vulnerable to meta-model evolution thereafter.
    Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

sub evaluations (in the sequence bodyEvals)

  • Key: OCL21-225
  • Legacy Issue Number: 7512
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    4. – [2] All sub evaluations (in the sequence bodyEvals) have a different
    – environment. The first sub evaluation will start with an environment in which
    – all iterator variables are bound to the first element of the source. Note that
    – this is an arbitrary choice, one could easily well start with the last element
    – of the source, or any other combination.
    context LoopExpEval
    inv: let bindings: Sequence( NameValueBindings ) =
    iterators->collect( i |
    NameValueBinding( i.varName, source->asSequence()->first() )
    in
    bodyEvals->at(1).environment = self.environment->addAll( bindings )
    ==> missing closing bracket before ’in’

  • Reported: OCL 2.0b2 — Thu, 10 Jun 2004 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    yes

  • Updated: Fri, 6 Mar 2015 20:58 GMT

context IfExpEval inv:

  • Key: OCL21-224
  • Legacy Issue Number: 7511
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    resultValue = if condition then thenExpression.resultValue else
    elseExpression.resultValue
    ==> missing ’endif’

  • Reported: OCL 2.0b2 — Thu, 10 Jun 2004 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

isSent attribute

  • Key: OCL21-228
  • Legacy Issue Number: 7515
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    7. – [4] The isSent attribute of the resulting ocl message value is true only if
    – the message value is in the outgoing messages of the ‘self’ object.
    context OclMessageExpEval
    inv:
    if resultValue.oclIsUndefined()
    resultValue.isSent = false
    else
    resultValue.isSent = true
    endif
    ==> add ’then’ after ’oclIsUndefined()’

  • Reported: OCL 2.0b2 — Thu, 10 Jun 2004 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    yes

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ocl message expression

  • Key: OCL21-227
  • Legacy Issue Number: 7514
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    6. – [2] The result value of an ocl message expression is the sequence of the
    – outgoing messages of the ‘self’ object that matches the expression. Note that
    – this may result in an empty sequence when the expression does not match to any
    – of the outgoing messages.
    context OclMessageExpEval
    inv: resultValue =
    environment.getValueOf( ’self’ ).outgoingMessages->select( m |
    m.target = target.resultValue and
    m.name = self.name and
    self.arguments->forAll( expArg: OclMessageArgEval |
    not expArg.resultValue.oclIsUndefined() implies
    m.arguments->exists( messArg | messArg.value = expArg.value ))
    ==> add one closing bracket after expression

  • Reported: OCL 2.0b2 — Thu, 10 Jun 2004 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    yes

  • Updated: Fri, 6 Mar 2015 20:58 GMT

an iterate expression evaluation

  • Key: OCL21-231
  • Legacy Issue Number: 7520
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    12. – [1] The model of the result of an iterate expression evaluation is equal to
    – the model of the result of the associated IterateExp.
    context IterateExpEval
    inv: result.model = model.result )
    ==> remove last bracket

  • Reported: OCL 2.0b2 — Mon, 14 Jun 2004 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    yes

  • Updated: Fri, 6 Mar 2015 20:58 GMT

missing ’inv:’ twice

  • Key: OCL21-230
  • Legacy Issue Number: 7519
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    11. – [1] The condition evaluation corresponds with the condition of the expression,
    – and likewise for the thenExpression and the else Expression.
    context IfExpEval inv:
    condition.model = model.condition
    thenExpression.model = model.thenExpression
    elseExpression.model = model.elseExpression
    ==> missing ’inv:’ twice

  • Reported: OCL 2.0b2 — Thu, 10 Jun 2004 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    yes

  • Updated: Fri, 6 Mar 2015 20:58 GMT

1] The type of the attribute is the type of the value expression.

  • Key: OCL21-222
  • Legacy Issue Number: 7508
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    context TupleLiteralExpPart
    inv: attribute.type = value.type
    ==> should be removed, class does not exist

  • Reported: OCL 2.0b2 — Thu, 10 Jun 2004 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    The offending text was removed in OCL 2.2.
    Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

An additional attribute refParams lists all parameters of the referred

  • Key: OCL21-221
  • Legacy Issue Number: 7507
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    38. – [3] An additional attribute refParams lists all parameters of the referred
    – operation except the return and out parameter(s).
    context OperationCallExp
    def: refParams: Sequence(Parameter) = referredOperation.parameters-
    >select (p

    p.kind <> ParameterDirectionKind::return or
    p.kind <> ParameterDirectionKind::out)
    ==> ’parameters’ should be ’Parameter’

  • Reported: OCL 2.0b2 — Thu, 10 Jun 2004 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    The offending parameters waschanged to ownedParameter-in OCL 2.2.
    Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

sub evaluations (in sequence bodyEvals) have different environment.

  • Key: OCL21-226
  • Legacy Issue Number: 7513
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    5. – [3] All sub evaluations (in the sequence bodyEvals) have a different
    – environment. The environment is the same environment as the one from the
    – previous bodyEval, where the iterator variable or variables are bound to the
    – subsequent elements of the source.
    context LoopExpEval
    inv:
    let SS: Integer = source.value->size()
    in if iterators->size() = 1 then
    Sequence

    {2..SS}

    ->forAll( i: Integer |
    bodyEvals->at.environment = bodyEvals->at(i-1).environment
    >replace( NameValueBinding( iterators>at(1).varName,
    source.value->asSequence()->at )))
    else – iterators->size() = 2
    Sequence

    {2..SS*SS}

    ->forAll( i: Integer |
    bodyEvals->at.environment = bodyEvals->at(i-1).environment
    >replace( NameValueBinding( iterators>at(1).varName,
    source->asSequence()->at(i.div(SS) + 1) ))
    >replace( NameValueBinding( iterators>at(2).varName,
    source.value->asSequence()->at(i.mod(SS)) )) ) endif
    ==> two closing brackets before ’endif’ should be removed

  • Reported: OCL 2.0b2 — Thu, 10 Jun 2004 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    yes

  • Updated: Fri, 6 Mar 2015 20:58 GMT

add ’and’ between both expression parts

  • Key: OCL21-229
  • Legacy Issue Number: 7516
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    8. – [1] An ocl message argument evaluation has either an ocl expression
    – evaluation, or an unspecified value expression evaluation, not both.
    context OclMessageArgEval inv:
    expression->size() = 1 implies unspecified->size() = 0
    expression->size() = 0 implies unspecified->size() = 1
    ==> add ’and’ between both expression parts

  • Reported: OCL 2.0b2 — Thu, 10 Jun 2004 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    Yes. But I cannot check the precedence without reading the spec so use a more obvious exposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

context LocalSnapshot

  • Key: OCL21-223
  • Legacy Issue Number: 7509
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    Errors found in UML-based-semantics
    1. context LocalSnapshot
    def: let allPredecessors() : Sequence(LocalSnapshot) =
    if pred->notEmpty then
    pred->union(pred.allPredecessors())
    else
    Sequence {}
    endif
    def: let allSuccessors() : Sequence(LocalSnapshot) =
    if succ->notEmpty then
    succ->union(succ.allSuccessors())
    else
    Sequence {}
    ==> remove ’let’ from both expressions, add ’endif’ after the second

  • Reported: OCL 2.0b2 — Thu, 10 Jun 2004 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    Yes, except final endif is there (but was wrong font in OCL 2.0).

  • Updated: Fri, 6 Mar 2015 20:58 GMT

context State::getStateMachine() : StateMachine

  • Key: OCL21-220
  • Legacy Issue Number: 7503
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    post: result =
    if statemachine->notEmpty() then
    stateMachine
    else
    – must be part of a composite state
    state.container.getStateMachine()
    endif
    context Transition::getStateMachine() : StateMachine
    post: result =
    if statemachine->notEmpty() then
    stateMachine
    else
    – state is not empty
    state.getStateMachine()
    endif
    ==> in both expressions ’statemachine’ should be stateMachine

  • Reported: OCL 2.0b2 — Thu, 10 Jun 2004 04:00 GMT
  • Disposition: Resolved — OCL 2.1
  • Disposition Summary:

    The offending expressions were rewritten in OCL 2.2 without similar typos.
    Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Introduce selectByKind and selectByType operations

  • Key: OCL24-12
  • Legacy Issue Number: 18829
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    A very common 'idiom' in OCL expressions is

    sources->select(oclIsKindOf(T))>collect(oclAsType(T))>asSet()

    to select the sub-set of type T.

    This involves four library calls and requires T to be typed twice.

    In practice

    sources->select(oclIsKindOf(T)).oclAsType(T)

    may save one operation call at the expense of the wrong collection type.

    Suggest introduce

    sources->selectByKind(T)
    sources->selectByType(T)

    to simplify this oclIsKindOf/oclIsTypeOf usage.

  • Reported: OCL 2.3.1 — Sun, 21 Jul 2013 04:00 GMT
  • Disposition: Resolved — OCL 2.4
  • Disposition Summary:

    This is clearly useful:
    Acceleo (but not MOFM2T) provides "filter".
    The Dresden OCL team in http://gres.uoc.edu/OCL2011/pubs/ocl2011_submission_3.pdf suggest "selectByType" and note that QVTo provides "collectselect"
    "filter" is nice and short but fails to fulfill the expectation that the argument should be some general predicate not an unmentioned type.
    oclIsKindOf and oclIsTypeOf are already there and so unless they are to be changed, additions should be compatible and re-inforce the "KindOf"/"TypeOf" distinction..
    There are two distinct algorithms: exact type and polymorphic type so
    selectByType and selectByKind are consistent.
    selectByType clearly can include/exclude OclVoid at will.
    selectByKind probably doesn't want to include null elements even though null conforms to everything, so QVTo's collectselect exclusion is worth emulating.
    There seems no need to introduce rejectByKind and rejectByType too, since there is no associated type conversion; reject will do.
    The correct declarations should be:
    selectByKind(TT)(type : Metaclass(TT)) : Collection(TT);
    selectByType(TT)(type : Metaclass(TT)) : Collection(TT);
    These use an operation template type TT to model the type relationship between the returned Collection element type and the metatype provided as the operation argument. Unfortunately we cannot use this until OCL '2.5' aligns with UML templates and introduces templated Metaclasses.

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Collection::min/max accumulator initialized as self.first()

  • Key: OCL24-11
  • Legacy Issue Number: 18515
  • Status: closed  
  • Source: Universidad Nacional del Litoral ( Roberto Javier Godoy)
  • Summary:

    The accumulator in the definition of Collection::min and Collection::max is initialized as self.first().

    post: result = self->iterate( elem; acc : T = self.first() | acc.min(elem) )

    post: result = self->iterate( elem; acc : T = self.first() | acc.max(elem) )

    The accumulator should be initialized as self.asSequence()->first(), because Collection::first() is undefined.

  • Reported: OCL 2.3.1 — Fri, 1 Mar 2013 05:00 GMT
  • Disposition: Resolved — OCL 2.4
  • Disposition Summary:

    Nearly right.
    self is of course a Collection, so needs to be self->asSequence()>first(), or just self>any(true).

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Collection::any() violates precondition if the collection is empty

  • Key: OCL24-10
  • Legacy Issue Number: 18504
  • Status: closed  
  • Source: Universidad Nacional del Litoral ( Roberto Javier Godoy)
  • Summary:

    Section 11.9.1.4 states that "there must be at least one element fulfilling body, otherwise the result of this IteratorExp is null." And defines

    source->any(iterator|body) = source->select(iterator | body)>asSequence()>first()

    However

    let seq:Sequence<T>=source->select(body)->asSequence()
    in source->any(body)=seq->at(1)

    >From section 11.7.5

    context Sequence::first() : T
    post: result = self->at(1)

    context Sequence::at(i : Integer) : T
    pre : i >= 1 and i <= self->size()

    If there is no element fulfilling body, then seq is empty and the precondition of Sequence::at does not hold because 1 > seq->size().

    Related to: Issue 18125 [OCL 2.4]

  • Reported: OCL 2.3.1 — Tue, 26 Feb 2013 05:00 GMT
  • Disposition: Resolved — OCL 2.4
  • Disposition Summary:

    The 'equivalent' OCL of
    source->select(iterator | body)>asSequence()>first()
    returns invalid if no elements are selected, rather than null as the words say.
    As identified in Issue 18125, null could also be a valid value, so the words are clearly wrong.

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Inconsistent inclusion of source in closure results

  • Key: OCL24-9
  • Legacy Issue Number: 18464
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    "The returned collection of the closure iteration is an accumulation of the source, and the collections resulting from ..."

    incorrectly includes the source. The algorithm in 11.9.1 correctly includes the source only if the source is reached by some traversal from the source.

  • Reported: OCL 2.3.1 — Wed, 20 Feb 2013 05:00 GMT
  • Disposition: Resolved — OCL 2.4
  • Disposition Summary:

    No. The algorithm in 11.9.1 only adds the source to the result if the source was not already present. Since the anonRecurse starts with an empty result all sources are accumulated.
    Just need to polish the words to avoid similar misunderstandings in the future

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Clarify invalid propgation/conformance priority

  • Key: OCL24-8
  • Legacy Issue Number: 18437
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    There is a contradiction between invalid conform to anything and invalid always propagates for e.g.

    Sequence{}->first().oclIsKindOf(Class)

    oclIsKindOf uses the invalid input to return true.

    Invalid propagation should dominate giving invalid.

    This requires OclInvalid::oclIsKindOf, oclIsTypeOf, oclType, oclAsType overloads to explicitly return invalid.

  • Reported: OCL 2.3.1 — Mon, 11 Feb 2013 05:00 GMT
  • Disposition: Resolved — OCL 2.4
  • Disposition Summary:

    (A) It is clearly correct that OclVoid/OclInvalid conform to anything so that null/invalid can be used anywhere.
    (B) It is also clearly correct for navigation on null and invalid to be invalid so that bad results propagate.
    The above are not contradictory. The contradiction arises through the introduction of the oclIsInvalid() and oclIsUndefined() operations that may be used on null or invalid, despite (B).
    It would appear that oclIsInvalid() and oclIsUndefined() must be privileged to violate the strictness of (B). If so, are oclIsKindOf, oclIsTypeOf, oclType, oclAsType etc. also privileged?
    The specification can be clarified by making all oclXXX() operations privileged so that they can be used on null and invalid and defining their OclVoid and OclInvalid overloads explicitly.
    The affected text can be clarified to eliminate the accidental omission of operation calls for null and invalid.
    The affected text covers the DataType equality issue so the resolution of Issue 14918 is included

  • Updated: Fri, 6 Mar 2015 20:57 GMT

OclAny::oclAsType postcondition implies type change

  • Key: OCL24-7
  • Legacy Issue Number: 18319
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    post: (result = self) and result.oclIsTypeOf( t )

    requires oclAsType to change the type of self.

    The constraint should be:

    post: (result = self) and result.oclIsKindOf(t)

    [Review all usage of oclIsType() since it's nearly always wrong to use oclIsType rather than oclIsKindOf.]

  • Reported: OCL 2.3.1 — Fri, 14 Dec 2012 05:00 GMT
  • Disposition: Resolved — OCL 2.4
  • Disposition Summary:

    Should indeed be oclIsKindOf and the argument should be 'type' as in the signature.
    Reviewing other oclIsTypeOf uses identifies just one clear error in 8.2.1 since CollectionType has derived SetType and other types. Other usages seem to be either ok but inelegant since the type is a leaf type, or deliberate constraints for an invariant

  • Updated: Fri, 6 Mar 2015 20:57 GMT

any iteration unsuitable for null Collection content

  • Key: OCL24-6
  • Legacy Issue Number: 18125
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    The any() iteration is specified to return null in the event that no match is found. However null could also be the return of a successful match of null. e.g

    Sequence

    {null}

    ->any(s | s = null)

    Suggest: change the match-not-found return to invalid.

  • Reported: OCL 2.3.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — OCL 2.4
  • Disposition Summary:

    The resolution of Issue 18504 solves this too.
    Disposition: See issue 18504 for disposition

  • Updated: Fri, 6 Mar 2015 20:57 GMT

non(not(X)) should be X

  • Key: OCL24-5
  • Legacy Issue Number: 17531
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    In http://www.linkedin.com/redirect?url=http%3A%2F%2Fwww%2Ebrucker%2Ech%2Fprojects%2Fhol-ocl%2FFeatherweight-OCL%2Foutline%2Epdf&urlhash=vacm&_t=tracking_anet Burkhart Wol ff argues that lopgical consistency requires that not(not(X)) is X.

    OCL 2.3.x does not satisfy this for 'null'.

    Similary null and true = null not invalid ...

  • Reported: OCL 2.3.1 — Fri, 27 Jul 2012 04:00 GMT
  • Disposition: Resolved — OCL 2.4
  • Disposition Summary:

    Issue 14197 for OCL 2.3 rationalized the vague equivalences between undefined and null/invalid.
    In OCL 2.0, it was left for the implementer to determine how "not null" and "not invalid" were computed given the specification that "not undefined = undefined".
    In OCL 2.3, we have clarity: "not null = invalid" and "not invalid = invalid". However this leads to the identified inconsistency that "not not X = X" is not true for all X (not not null = invalid).
    The clarification of "not undefined" should have partitioned the two cases for "not undefined = undefined" so that "not null = null" and "not invalid = invalid"
    Similarly other logical operations involving null but not invalid should yield null rather than invalid results. "null and true = null", "null or false = null", "null xor false = null".
    We should extend this to the forAll and exists iterations that are defined as iterated and/or. Making the exists/forAll returns clear highlights that many iterator returns are only partially specified; these need expanding.
    Introduction of null highlights a redundancy in the non-standard implies postcondition: (not self) or (self and b) rather than the standard (not self) or b. The standard gives the consistent result "null implies true = true" whereas the current non-standard postcondition gives null. The non-standard postcondition is already wrong for invalid.
    The If expression specification words omit consideration of a non-valid condition; a null or invalid condition is of course invalid.
    For arithmetic operations there is an apparently free choice between two alternate consistent logics in which "1 + null = null" or "1 + null = invalid".
    "1 + null = null" is plausible if "null" denotes "don't know"; an object/value that exists but with unspecified value.
    "1 + null = invalid" is plausible if "null" denotes "missing"; the absence of an object/value.
    However UML provides the interpretation of "null" as "missing". UML-alignment of OCL therefore requires OCL to take the "1 + null = invalid" alternative, which is what the Issue 14197 clarification specified. So no change required for arithmetic operations.

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Navigation from Association Classes does not conform to UML 2.4.1

  • Key: OCL24-4
  • Legacy Issue Number: 17463
  • Status: closed  
  • Source: computer.org ( DI Florin Ioan Chertes)
  • Summary:

    The navigation from Association Classes does not conform to UML 2.4.1 because of 7.3.4 AssociationClass on page 44 UML Superstructure Specification, v2.4.1. the kind of navigation allowed by OCL is not allowed by UML, i.e. the navigation from the association class to the ends of the association is explicitly not allowed by UML but allowed by OCL. I see here a contradiction. I checked UML 2.1.2 from 2007 and in that UML this navigation from the association class the ends of the association was still allowed. I think that OCL 2.3.1 is not compatible with UML 2.4.2 from this point of view. Please tell me if this opinion is correct. If this contradiction that I remarked really exists than what to expect from the future: OCL or UML point of view?

  • Reported: OCL 2.3.1 — Sun, 1 Jul 2012 04:00 GMT
  • Disposition: Resolved — OCL 2.4
  • Disposition Summary:

    The apparent prohibition in UML 2.4.1 is not present in UML 2.5 Beta.
    The problem is a misunderstanding. OCL expressions are resolved at 'modeling-time' against the model and so are not restricted by visibility or any practical limitations that may occur at run-time.
    Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:57 GMT

ISO has changed the following normative references to its documents

  • Key: OCL24-3
  • Legacy Issue Number: 17306
  • Status: closed  
  • Source: Object Management Group ( Ms. Linda Heaton)
  • Summary:

    ISO 639 has been replaced by a six-part series. The new reference should be: ISO 639 (all parts)
    ISO 3166 has been replaced by a three part series. The new reference should be: ISO 3166 (all parts)
    ISO 10646 is new and this reference should be: ISO 10646:2011, Information technology - Universal Coded Character Set (UCS)

  • Reported: OCL 2.3.1 — Thu, 12 Apr 2012 04:00 GMT
  • Disposition: Resolved — OCL 2.4
  • Disposition Summary:

    yes

  • Updated: Fri, 6 Mar 2015 20:57 GMT

OCL String::indexOf

  • Key: OCL24-2
  • Legacy Issue Number: 17220
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    The description of String::indexOf() states "No string is a substring of the empty string.".

    This modifies the axiom that every string is a substring of itself. It would appear that the empty string has got confused with null.

    An extension of the library with startsWith and endsWith operations would require the modified axiom to be accommodated making corner cases equivalently strange.

    This modified axiom is not observed by other String libraries such as the java.lang.String.

    Suggest: Replace the text:

    "The empty string is considered to be a substring of every string but the empty string, at index 1. No string is a substring of the empty string."

    by

    "The empty string is a substring of every string at index 1 (and also at all other indexes)."

  • Reported: OCL 2.3.1 — Fri, 9 Mar 2012 05:00 GMT
  • Disposition: Resolved — OCL 2.4
  • Disposition Summary:

    yes

  • Updated: Fri, 6 Mar 2015 20:57 GMT

OCL 2.3 OclInvalid::= is vague

  • Key: OCL24-1
  • Legacy Issue Number: 16998
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    Issue 14197 finally resolved the semantiscs of OclInvalid, but the end result was that there is no OclInvalid section in 11.3. Add an 11.3.x for OclInvalid that enumerates all relevant OclInvalid behaviors; in particular = and <> return invalid for any invalid argument.

  • Reported: OCL 2.3.1 — Sat, 14 Jan 2012 05:00 GMT
  • Disposition: Resolved — OCL 2.4
  • Disposition Summary:

    Merged with Issue 18437.
    Disposition: See issue 18437 for disposition

  • Updated: Fri, 6 Mar 2015 20:57 GMT