Object Constraint Language Avatar
  1. OMG Specification

Object Constraint Language — All Issues

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

Issues Summary

Key Issue Reported Fixed Disposition Status
OCL25-33 Special Types violate UML Generalization Semantics OCL 2.0 open
OCL25-173 Section: 11.9.2 sortedBy OCL 2.0b2 open
OCL25-15 Section: 7.5.15 OCL 2.0 open
OCL25-200 OCL: Usage of qualifiers OCL 2.0b1 open
OCL25-199 parameters of the referredOperation OCL 2.0b2 open
OCL25-196 Template return types in operation signatures OCL 2.0b2 open
OCL25-191 OCL 2: what is a collection? OCL 2.0b1 open
OCL25-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-171 OCL 2.0 Issue: References to Additional Attributes and Operations OCL 2.0 open
OCL25-172 Section: A.3.2.2 Syntax and Semantics of Postconditions (02) OCL 2.0 open
OCL25-174 OCL Collections applied to Properties OCL 2.0 open
OCL25-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-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-132 Errors in examples OCL 2.0 open
OCL25-131 Recursivity is not explicitly addressed with examples OCL 2.0 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-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-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-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-44 Satisfaction of Operation Specifications OCL 2.0b2 open
OCL25-43 Exception of strict evaluation (=) OCL 2.0b2 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-34 Section: A/2.5.5 Collection Operations - Table A.3 OCL 2.0 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-21 Issue: OclAny operations of tuples and collections OCL 2.0b2 open
OCL25-22 Issue: Grammar of OCL OCL 2.0b2 open
OCL25-17 Section: 10.1 OCL 2.0b2 open
OCL25-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-16 OCL 2.0 8.2 Collection Type name distinguishability OCL 2.0 open
OCL25-3 status of objects and tuples OCL 2.0b2 open
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
OCL2-16 OCL needs an abstract syntax, just like the UML metamode OCL 2.0b1 OCL 2.0b2 Resolved closed
OCL2-13 6.8.1.9 String on page 6-34 OCL 2.0b1 OCL 2.0b2 Resolved closed
OCL2-12 1. 6.2.1 "legend" on page 6-3, Internationalization issue OCL 2.0b1 OCL 2.0b2 Resolved closed
OCL2-15 inhibtedChar on page6-48, OCL 2.0b1 OCL 2.0b2 Resolved closed
OCL2-14 EBNF of the String on page6-48. OCL 2.0b1 OCL 2.0b2 Resolved closed
OCL2-11 Downcast OCL collection operators OCL 2.0b1 OCL 2.0b2 Resolved closed
OCL2-10 In 6.9 "Grammar for OCL" (Internationalization issues) OCL 2.0b1 OCL 2.0b2 Resolved closed
OCL2-9 OCL: Created and Destroyed instances OCL 2.0b1 OCL 2.0b2 Resolved closed
OCL2-8 context declaration for OCL invariants OCL 2.0b1 OCL 2.0b2 Resolved closed
OCL2-7 postcondition for the operation round on the predefined OCL type OCL 2.0b1 OCL 2.0b2 Resolved closed
OCL2_-92 The property 'unspecified' can be removed from the metamodel OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-94 Instanciation of collection types OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-93 The metaclass 'OclMessageArg' can be removed from the metamodel OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-91 The composition associations in figure 9 are missing OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-90 The superclass of UnspecifiedValueExp is not ModelElement OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-89 Reusing TypedElement for UnspecifiedValueExp OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-88 An UnlimitedNaturalExp should be added in the metamodel OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-87 The Ocl prefix should be avoided as much as possible in metaclass names OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-86 Should avoid using the OclHelper stereotype OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-85 Inconsistency in the way to represent Tuple literal part OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-84 The naming of the parts properties in literals is not consistent OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-83 The set of possible values of CollectionKind is missing OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-82 Use a uniform convention to name multivalued properties OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-79 make link explicit OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-78 The container for self and return variables is missing OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-81 Inherited or non navigable properties should not appear in class descriptio OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-80 Should compare the value of the slots and not the objects itself OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-77 VariableDeclaration should be renamed Variable OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-76 Specific inheritance links at M1 level should be removed OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-75 OclAny cannot be an instance of Classifier OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-74 Section: 11.9.2 reject OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-73 Section: 11.9.1 exists OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-72 Section: 11.7.2 OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-71 ’StringValue.iterators OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-70 context Classifier OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-69 context TTupleType::... OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-68 referredOperation OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-67 "Bag" OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-66 context TTupleType::make(atts : sequence(Attribute) ) : TTupleType OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-65 type of a TupleLiteralExp OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-62 type of a TupleLiteralExp OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-64 The type of the attribute is the type of the value expression. OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-63 tuple literal expression OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-61 message is a send action, OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-60 message is a call action, OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-59 ’parameter’ should be ’Parameter’ OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-58 the property ’refParams’ is not present in OperationCallExp OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-57 forall’ should be ’forAll’ OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-54 attributes of the signal. OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-53 parameters of the operation. OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-56 5] The target of an OCL message cannot be a collection. OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-55 ’sentMessage’ should be ’sentSignal’ OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-48 The type of the condition of an if expression must be Boolean. OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-50 result type OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-49 iterator OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-52 type of each iterator var. must be type of the elements of source collectio OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-51 1] The type of the source expression must be a collection. OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-47 collection literal expression OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-46 7. context AttrubuteCallExp OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-45 context TupleType::make(atts : sequence(Attribute) ) : TupleType OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-44 In section 3.3.9 OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-43 context Operation OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-42 If message is a send action, arguments must conform to attributes of signal OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-41 The type of body expression must conform to declared type of result variabl OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-40 Errors in the abstract syntax chapter 1. -- [1] Integer conforms to real. OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-39 The classifier name TupleType is also a reserved word OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-38 change rollnames OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-37 OclMessageArg metaclass that is currently defined, could be removed. OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-36 tostring operation for Integer, Real and Boolean OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-35 plus (infix) operator (’+’) OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-34 flatten operation OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-30 result of applying the collect operation to a Sequence OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-29 Remove the composition symbol at the end of PropertyCallExp OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-33 There should be an OclTypeLiteralExp metaclass OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-32 There should be an OclTypeLiteralExp metaclass OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-31 There should be an OclUndefinedLiteralExp metaclass OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-28 section 7.4.6 (Re-typing or casting) on p.13 OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-27 Use the "null" keyword instead of verbose "OclUndefined". OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-26 What's a collection? OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-25 Keywords "attr" and "oper"? OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-24 Formal Semantics of OCL 2.0 in Appendix A OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-23 OclUndefined = OclUndefine ? OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-22 Enumeration approach for reflection OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-21 Issue: OclModelElement OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-20 Issue: OclType OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-19 Issue: oclIUndefined() versus isEmpty() OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-18 Issue: Attributes and Association Ends versus Properties OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-17 Issue: Operator precedence OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-16 Issue: Keywords OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-15 Issue: Set of characters OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-14 Issue: General section to define OCL concepts OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-13 Reintroduce allAttributes operator OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-12 Missing equality and inequality operations on collection types OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-11 Clarify definition of collectNested for Set, Bag, and Sequence OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-10 Undefined values, isEmpty() and Collections OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-7 Flagging recursive definitions OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-9 Attributes and Association Ends versus Properties OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-8 Operator precedence OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-4 Consider OclType as a powertype OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-6 Flagging insecure cast from Set to Sequence OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-5 domain for library operations /, div OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-3 Omit predefined type OclModelElement. OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-2 oclIsNew for a collection OCL 2.0b2 OCL 2.0 Resolved closed
OCL2_-1 OCL 2.0/international character sets OCL 2.0b2 OCL 2.0 Resolved closed
OCL21-353 Section: A/2.3 Enumeration Types OCL 2.0 OCL 2.1 Resolved closed
OCL21-347 Exact type of Set{} and missing Set(MyType){} literal definitions OCL 2.0 OCL 2.1 Resolved closed
OCL21-346 Use of simple quotes and double quotes in strings OCL 2.0 OCL 2.1 Resolved closed
OCL21-339 Missing definition of of iterators for OrderedSets OCL 2.0 OCL 2.1 Resolved closed
OCL21-338 Type of a type expression OCL 2.0 OCL 2.1 Resolved closed
OCL21-345 Use of MOF reflection in EssentialOCL should be clarified OCL 2.0 OCL 2.1 Resolved closed
OCL21-344 No way to represent type parameters in the standard library OCL 2.0 OCL 2.1 Resolved closed
OCL21-336 OCL 2.0 8.2 Collection Type packaging OCL 2.0 OCL 2.1 Resolved closed
OCL21-335 Section: A.3.2.2 Syntax and Semantics of Postconditions OCL 2.0 OCL 2.1 Resolved closed
OCL21-342 Making OclAny denote any object OCL 2.0 OCL 2.1 Resolved closed
OCL21-337 OCL 2.0: CollectionType constraint for invalid elements is incorrect OCL 2.0 OCL 2.1 Resolved closed
OCL21-341 Clarify the common supertype of Bag and Sequence OCL 2.0 OCL 2.1 Resolved closed
OCL21-340 The operation asSet, asSequence, asBag and asOrderedSet missing for OrderedSets OCL 2.0 OCL 2.1 Resolved closed
OCL21-334 Section: A.3.1.2 Semantics of Expressions OCL 2.0 OCL 2.1 Resolved closed
OCL21-343 Incosistency between UnlimitedInteger and UnlimitedNatural OCL 2.0 OCL 2.1 Resolved closed
OCL21-292 Dynamic typing with allInstances() OCL 2.0 OCL 2.1 Resolved closed
OCL21-291 missing closing parethesis inthese two expressions OCL 2.0 OCL 2.1 Resolved closed
OCL21-289 Usage of initialization and derivation constraints on the same property OCL 2.0 OCL 2.1 Resolved closed
OCL21-288 Collection element type serialization OCL 2.0 OCL 2.1 Resolved closed
OCL21-294 Section 8.2 InvalidType OCL 2.0 OCL 2.1 Resolved closed
OCL21-293 Section: 7.4.7, 7.4.9, 9.3.2 OCL 2.0 OCL 2.1 Resolved closed
OCL21-287 TypeType OCL 2.0 OCL 2.1 Resolved closed
OCL21-286 ownership of association ends does not matter for traversal in OCL OCL 2.0 OCL 2.1 Resolved closed
OCL21-284 11.7.1 OCL 2.0 OCL 2.1 Resolved closed
OCL21-283 11.2.5 (02) OCL 2.0 OCL 2.1 Resolved closed
OCL21-290 8.2.2 Well-formedness Rules for the Types Package OCL 2.0 OCL 2.1 Resolved closed
OCL21-281 11.8.1 OCL 2.0 OCL 2.1 Resolved closed
OCL21-280 11.2.4 (OclInvalid) - similar criticism as 11.2.3 OCL 2.0 OCL 2.1 Resolved closed
OCL21-282 11.2.5 OCL 2.0 OCL 2.1 Resolved closed
OCL21-285 Naming of Constraints in OCL OCL 2.0 OCL 2.1 Resolved closed
OCL21-274 Section: 7.4.9 OCL 2.0 OCL 2.1 Resolved closed
OCL21-273 Using "def" OCL 2.0 OCL 2.1 Resolved closed
OCL21-275 Section: 7.8 OCL 2.0 OCL 2.1 Resolved closed
OCL21-278 Section "IteratorExpCS" OCL 2.0 OCL 2.1 Resolved closed
OCL21-277 Section 9.2.2 OCL 2.0 OCL 2.1 Resolved closed
OCL21-279 11.2.3 OCL 2.0 OCL 2.1 Resolved closed
OCL21-276 Section 7.6.3 OCL 2.0 OCL 2.1 Resolved closed
OCL21-349 The following collection operations would be useful for the HL7 GELLO project: OCL 2.0 OCL 2.1 Resolved closed
OCL21-348 The concrete syntax given is extremely difficult to implement OCL 2.0 OCL 2.1 Resolved closed
OCL21-352 have tuple fields and let variables to have the declaration of their types explicity? OCL 2.0 OCL 2.1 Resolved closed
OCL21-351 type of the iterator variable is expected or not? OCL 2.0 OCL 2.1 Resolved closed
OCL21-350 doubts about the iterator variables OCL 2.0 OCL 2.1 Resolved closed
OCL21-295 CollectionType and CollectionKind OCL 2.0 OCL 2.1 Resolved closed
OCL21-307 no explanations about how to manipulate optional and multivalued attributes OCL 2.0 OCL 2.1 Resolved closed
OCL21-306 section 7.4.6 (p. 12) OCL 2.0 OCL 2.1 Resolved closed
OCL21-297 Section: A/1.1.1 Types OCL 2.0 OCL 2.1 Resolved closed
OCL21-296 last line on page 28 OCL 2.0 OCL 2.1 Resolved closed
OCL21-304 Section: A/1.2.4 System State OCL 2.0 OCL 2.1 Resolved closed
OCL21-303 Section: A/1.2.1 Objects OCL 2.0 OCL 2.1 Resolved closed
OCL21-302 Section: A/1.1.6 Generalization - editorial issues OCL 2.0 OCL 2.1 Resolved closed
OCL21-300 Section: A/1.1.5 Associations OCL 2.0 OCL 2.1 Resolved closed
OCL21-299 Section: A/1.1.5 Associations -- missing word OCL 2.0 OCL 2.1 Resolved closed
OCL21-301 Section: A/1.1.6 Generalization OCL 2.0 OCL 2.1 Resolved closed
OCL21-298 Section: A/1.1.5 Associations OCL 2.0 OCL 2.1 Resolved closed
OCL21-305 Section: A/2.2 Common Operations on All Types OCL 2.0 OCL 2.1 Resolved closed
OCL21-333 Section: A.2.5.8 Sequence Operations OCL 2.0 OCL 2.1 Resolved closed
OCL21-332 Section: A.3.1.2 Semantics of Expressions, Definition A.30 part ii OCL 2.0 OCL 2.1 Resolved closed
OCL21-327 Section 8.2.1 Type Conformance on page 37 OCL 2.0 OCL 2.1 Resolved closed
OCL21-330 Section: A.3.1.1 Syntax of Expressions OCL 2.0 OCL 2.1 Resolved closed
OCL21-329 Section: A.2.7 Type Hierarchy OCL 2.0 OCL 2.1 Resolved closed
OCL21-326 Section: A.2.6.1 Definition A.26 (Special Types) OCL 2.0 OCL 2.1 Resolved closed
OCL21-325 Section: A.2.6 Special Types OCL 2.0 OCL 2.1 Resolved closed
OCL21-322 Section: A.3.1.1 Syntax of Expressions OCL 2.0 OCL 2.1 Resolved closed
OCL21-324 Syntax of Expressions (second sentence after Definition A..29) OCL 2.0 OCL 2.1 Resolved closed
OCL21-323 Section: A.3.1.1 Syntax of Expressions (Definition A.29) OCL 2.0 OCL 2.1 Resolved closed
OCL21-331 Section: A.3.1.2 Semantics of Expressions OCL 2.0 OCL 2.1 Resolved closed
OCL21-328 Section 8.2 page 35 InvalidType OCL 2.0 OCL 2.1 Resolved closed
OCL21-321 Section: A.3.1.1 Syntax of Expressions OCL 2.0 OCL 2.1 Resolved closed
OCL21-311 Section: A/2.3 Enumeration Types -- editorial OCL 2.0 OCL 2.1 Resolved closed
OCL21-310 The constraint [1] on the TupleLiteralPart metaclass is overconstrained OCL 2.0 OCL 2.1 Resolved closed
OCL21-313 Section: A.2.5.2 Definition A.24 (Type Expressions) OCL 2.0 OCL 2.1 Resolved closed
OCL21-312 Section: Definition A.23 (Semantics of Navigation Operations) OCL 2.0 OCL 2.1 Resolved closed
OCL21-317 There are two instances of missing and misplaced parentheses OCL 2.0 OCL 2.1 Resolved closed
OCL21-316 A.2.5.5 Collection Operations OCL 2.0 OCL 2.1 Resolved closed
OCL21-320 Section: A.2.5.8 Sequence Operations OCL 2.0 OCL 2.1 Resolved closed
OCL21-319 Section: A.2.5.6 Set Operations Table A.4 OCL 2.0 OCL 2.1 Resolved closed
OCL21-309 OrderedSet collection OCL 2.0 OCL 2.1 Resolved closed
OCL21-318 Section: A.2.5.6 Set Operations OCL 2.0 OCL 2.1 Resolved closed
OCL21-314 Section: A.2.5.5 Collection Operations OCL 2.0 OCL 2.1 Resolved closed
OCL21-315 Section: A/2.5.5 Collection Operations - just before table A.3 OCL 2.0 OCL 2.1 Resolved closed
OCL21-308 The Tuple constructor is problematic OCL 2.0 OCL 2.1 Resolved closed
OCL2-5 OCL/MOF/UML alignment OCL 2.0b1 OCL 2.0b2 Resolved closed
OCL2-4 OCL 2: String operations OCL 2.0b1 OCL 2.0b2 Resolved closed
OCL2-3 OCL 2: Can collections contain void/undefined objects OCL 2.0b1 OCL 2.0b2 Resolved closed
OCL2-2 OCL 2: flatten OCL 2.0b1 OCL 2.0b2 Resolved closed
OCL21-270 Section: 7.3.4 OCL 2.0 OCL 2.1 Resolved closed
OCL21-269 Wrong subtyping of PropertyCallExp and NavigationCallExp OCL 2.0 OCL 2.1 Resolved closed
OCL21-268 inability to uniquely reference association ends OCL 2.0 OCL 2.1 Resolved closed
OCL21-267 Introduction and oclType() OCL 2.0 OCL 2.1 Resolved closed
OCL21-266 Circular imports OCL 2.0 OCL 2.1 Resolved closed
OCL21-272 Section: 7.5.9 OCL 2.0 OCL 2.1 Resolved closed
OCL21-271 Section: 8.3.5 OCL 2.0 OCL 2.1 Resolved closed
OCL21-248 sub evaluations (02) OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-247 sub evaluations OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-254 Section: 7.5.11 OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-253 Section: 7.5.9 OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-246 value of a collection range OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-245 value of a collection range OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-249 Section: 6.5.4.3 Combining Properties OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-243 result value of an attribute call expression OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-251 Section: 7.4.5 OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-252 Section: 7.5.3 OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-250 Section: 7.4 OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-244 result value of a collection literal expression evaluation OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-204 Issue: Syntax of Operation Call, Iterator, and Iterate Expressions OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-203 Issue: Abstract syntax tree OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-208 The notation for selecting elements should be more intuitive OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-207 The notation for testing the type of a metaclass is too verbose OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-206 Example with TupleType OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-211 Improve the notation when defining local variables OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-210 There is no simple way to invoke an "if then else" on a collection OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-209 notation for selecting unique element within a list should be more concise OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-216 Provide specific notational support when testing stereotypes OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-215 Suppress the usage of an Ocl prefix in standard library operations OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-202 Issue: Unspecified syntax and semantics for Integer, Real, and String OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-213 Allow implicit type casting to boolean when a boolean is expected OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-212 Allow applying iteration operations on single objects OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-214 Automatic casting between strings and enumeration values OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-217 Add a generic text formatter operator '% OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-205 The index seems incomplete OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-234 arguments of the return message of an ocl message expression OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-233 inv: model.sentSignal->size() = 1 implies OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-236 ’element’ should be ’elements’ OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-235 Only one of the attributes isPost and isPre may be true at the same time. OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-242 elements in a tuple value OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-232 arguments OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-240 The history of an object is ordered.(02) OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-241 The operation allPredecessors OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-239 history of an object is ordered. OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-238 ’Element’ should be ’NameValueBinding’ OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-237 ’element’ should be ’elements’ (02) OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-198 Add select/reject/collectNested to Collection OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-197 Exception of strict evaluation (queries) OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-201 Issue: Virtual machine OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-200 Clarify the UML semantics of IfExpEval OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-195 Exception of strict evaluation (implies) OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-196 Exception of strict evaluation (forAll, exists) OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-199 Clarify the semantics of forAll OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-265 Notation for accessing class operations is inconsistent OCL 2.0 OCL 2.1 Resolved closed
OCL21-264 Navigating across non navigable associations OCL 2.0 OCL 2.1 Resolved closed
OCL21-263 allInstances OCL 2.0 OCL 2.1 Resolved closed
OCL21-261 Section: 1 - 13 OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-260 Section: 11.9.3 & 11.9.4 OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-258 Section: 11.2.1 OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-257 Section: 10.2.2 LocalSnapshot OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-255 Section: 7.5.13 OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-262 The spec does not describes the syntax of integer, real or string literals OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-259 Section: 11.5.4 OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-256 Section: 7.6.2 OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-219 rewrite well-formedness OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-218 Make usage of tuples less complex and less verbose OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-225 sub evaluations (in the sequence bodyEvals) OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-224 context IfExpEval inv: OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-228 isSent attribute OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-227 ocl message expression OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-231 an iterate expression evaluation OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-230 missing ’inv:’ twice OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-222 1] The type of the attribute is the type of the value expression. OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-221 An additional attribute refParams lists all parameters of the referred OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-226 sub evaluations (in sequence bodyEvals) have different environment. OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-229 add ’and’ between both expression parts OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-223 context LocalSnapshot OCL 2.0b2 OCL 2.1 Resolved closed
OCL21-220 context State::getStateMachine() : StateMachine OCL 2.0b2 OCL 2.1 Resolved closed

Issues Descriptions

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

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

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

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

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

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.0 Issue: References to Additional Attributes and Operations

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

    Re: OCL 2.0 formal/06-05-01

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

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

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

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

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

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

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

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

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

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

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

OCL Collections applied to Properties

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

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

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

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

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

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

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

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

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

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

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

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

Issue: OclAny operations of tuples and collections

  • Key: OCL25-21
  • Legacy Issue Number: 6573
  • Status: open  
  • Source: Anonymous
  • Summary:

    Description: The OCL specification does not allow operations like = or <> to be performed tuple values. It also forbids operations like oclIsKindOf and oclIsTypeOf on collections.
    Rationale: Add such operations to tuple and collection types signatures directly or by inheritance, will make the language more powerfull (e.g. a set of dogs can be casted to a set of animals).

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

Issue: Grammar of OCL

  • Key: OCL25-22
  • Legacy Issue Number: 6565
  • Status: open  
  • Source: Anonymous
  • Summary:

    Description: The grammar presented in 4.3, which is in my opinion a semantic grammar, is not suitable to describe the syntax of OCL.
    Rationale: Introducing non-terminals like primary-expression, selection-expression, and operation-call-expression will solve all the problems and will reduce the number of ambiguities. Hence, the grammar contained in the specification will suffer less changes in order to be used to design and implement a deterministic parser. This is the case of the specifications for C, C++, Java, C#, and Prolog.

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

Section: 10.1

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

    Typo - Fig. 14, "Ocl-AbstractSyntax" should be "OCL-AbstractSyntax" to agree with naming format shown in other two packages

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

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

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

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

OCL needs an abstract syntax, just like the UML metamode

  • Key: OCL2-16
  • Legacy Issue Number: 3392
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    OCL needs an abstract syntax, just like the UML metamodel. This
    will clarify many issues about the exact semantics of OCL.
    This request has been made by multiple sources.

  • Reported: OCL 2.0b1 — Wed, 1 Mar 2000 05:00 GMT
  • Disposition: Resolved — OCL 2.0b2
  • Disposition Summary:

    No Data Available

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

6.8.1.9 String on page 6-34

  • Key: OCL2-13
  • Legacy Issue Number: 4692
  • Status: closed  
  • Source: Architecture Technology Institute ( Hiroshi Miyazaki)
  • Summary:

    In the String explanation,
    There is a descrition that
    "The OCL type String represents ASCII strings."
    I think this cannot apply to multi-byte code.

    Could you change this sentence to
    "The OCL type String represents strings consisting
    of ASCII characters and/or multi-byte characters.

  • Reported: OCL 2.0b1 — Fri, 9 Nov 2001 05:00 GMT
  • Disposition: Resolved — OCL 2.0b2
  • Disposition Summary:

    No Data Available

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

1. 6.2.1 "legend" on page 6-3, Internationalization issue

  • Key: OCL2-12
  • Legacy Issue Number: 4691
  • Status: closed  
  • Source: Architecture Technology Institute ( Hiroshi Miyazaki)
  • Summary:

    1. 6.2.1 "legend" on page 6-3,
    There is a following description.
    "OCL expression are written using ASCII characters only"
    This sentence can be interpreted in this context as
    a) OCL expressions are written using only
    ASCII characters as examples in this document,
    b) the OCL expression must be written by only
    ASCII characters in general usage?

    Could you change this to
    "OCL expressions in this document are
    written using ASCII character only."

  • Reported: OCL 2.0b1 — Fri, 9 Nov 2001 05:00 GMT
  • Disposition: Resolved — OCL 2.0b2
  • Disposition Summary:

    No Data Available

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

inhibtedChar on page6-48,

  • Key: OCL2-15
  • Legacy Issue Number: 4694
  • Status: closed  
  • Source: Architecture Technology Institute ( Hiroshi Miyazaki)
  • Summary:

    4.Regarding inhibtedChar on page6-48,
    its definition is following.

    inhibitedChar :=
    "|"\"|"#"|"\'"|"("|")"|"*"|"+"|","|
    "|"."|"/"|":"|";"|"<"|"="|">"|"@"|
    ["|"\\"|"]"|"

    {"|"|"|"}

    "

    But, this definition is slightly different from one which we
    have provided previously.
    (Top two characters of each line are dropped)

    inhibitedChar := " " | "\"" | "#" | "\'" | "(" | ")" |
    "*" | "+" | "," | "-" | "." | "/" |
    ":" | ";" | "<" | "=" | ">" | "@" |
    "[" | "\\" | "]" | "

    {" | "|" | "}

    "

  • Reported: OCL 2.0b1 — Fri, 9 Nov 2001 05:00 GMT
  • Disposition: Resolved — OCL 2.0b2
  • Disposition Summary:

    No Data Available

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

EBNF of the String on page6-48.

  • Key: OCL2-14
  • Legacy Issue Number: 4693
  • Status: closed  
  • Source: Architecture Technology Institute ( Hiroshi Miyazaki)
  • Summary:

    Relating this, in the EBNF of the String on page6-48.
    There is a "~" symbol after double brackets.
    Does this means negation?
    If it is negation, there is no modification of String
    definition on the EBNF even though the body of string
    explanation is changed.
    But, I cannot find a "~" definition in the EBNF.
    In the unaryOperater definition of the EBNF on page6-48
    There is a "-".
    I think this is a "~" symbol.

  • Reported: OCL 2.0b1 — Fri, 9 Nov 2001 05:00 GMT
  • Disposition: Resolved — OCL 2.0b2
  • Disposition Summary:

    No Data Available

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

Downcast OCL collection operators

  • Key: OCL2-11
  • Legacy Issue Number: 4451
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    It is sometimes useful to downcast an OCL collection, for example
    when a generic function returns an OCL Collection, but a particular
    usage requires a Sequence. Unfortunately, the OCL operators
    asSet(), asSequence() and asBag(), are defined only for the
    concrete types, and not for their abstract common supertype
    Collection.

  • Reported: OCL 2.0b1 — Fri, 3 Aug 2001 04:00 GMT
  • Disposition: Resolved — OCL 2.0b2
  • Disposition Summary:

    No Data Available

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

In 6.9 "Grammar for OCL" (Internationalization issues)

  • Key: OCL2-10
  • Legacy Issue Number: 4121
  • Status: closed  
  • Source: Architecture Technology Institute ( Hiroshi Miyazaki)
  • Summary:

    > In 6.9 "Grammar for OCL",
    > According to the current BNF grammar, we cannot use
    > multi-byte characters in class nor attribute names, because
    > name and string are composed of alpha-numeric letters only.
    > I think the definition of OCL should be modified for us
    > to be able to use multi-byte characters.
    > I show a draft of modification which will be proposed by
    > ISO/Japan National Body.(This will be discussed in UML1.3 PAS
    > at the next OMG/ISO Orlando meeting)
    >
    > typeName :=charForNameTop charForName*
    > name :=charForNameTop charForName*
    > charForNameTop := /* Characters except inhibitedChar
    > and ["0"-"9"]; the available
    > characters shall be determined by
    > the tool implementers ultimately.*/
    > charForName := /* Characters except inhibitedChar; the
    > available characters shall be determined
    > by the tool implementers ultimately.*/
    > inhibitedChar := " "|"\"|"#"|"\'"|"("|")"|"*"|"+"|","|"-"|
    > "."|"/"|":"|";"|"<"|"="|">"|"@"|"["|"
    "|
    > "]"|"

    {"|"|"|"}

    "

  • Reported: OCL 2.0b1 — Sat, 9 Dec 2000 05:00 GMT
  • Disposition: Resolved — OCL 2.0b2
  • Disposition Summary:

    No Data Available

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

OCL: Created and Destroyed instances

  • Key: OCL2-9
  • Legacy Issue Number: 4112
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Usually, the behaviour of an operation is described by pre and
    postconditions, and then shown in a collaboration diagram. In turn, in a
    collaboration diagram one can model (via the standard stereotypes create and
    destroy) the creation and destroying of instances, but this is not in the
    case in OCL. It would be useful to be able to explicitly model in a
    postcondition that an instance ocurring in the expression was created during
    the execution of the operation being specified. Since introducing a command
    is not possible, this feature could be achieved by just 'declaring' in the
    postcondition that the instance 'was created'.

    For example:

    context X::operation()
    post: self.attr = self.attr@pre->including(created p)

    this declares that p was created during the execution of operation, and it
    was not taken from elsewhere.

  • Reported: OCL 2.0b1 — Fri, 8 Dec 2000 05:00 GMT
  • Disposition: Resolved — OCL 2.0b2
  • Disposition Summary:

    No Data Available

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

context declaration for OCL invariants

  • Key: OCL2-8
  • Legacy Issue Number: 3855
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The second form of the context declaration for OCL invariants should be extended from

    context c : Class inv:

    to

    context c1,..,cn : Class inv:

    In similar situations, like the forAll and Exists operators, multiple iterators are allowed. So the above suggestion would increase uniformity. It also leads in some cases to simplified OCL expressions, e.g.

    context C inv C.allInstances->forAll(c1,c2 | c1.id = c2.id implies c1=c2)

    could be written as

    context c1,c2 : C inv c1.id = c2.id implies c1=c2

    Crossreference to issue #3139.

  • Reported: OCL 2.0b1 — Wed, 13 Sep 2000 04:00 GMT
  • Disposition: Resolved — OCL 2.0b2
  • Disposition Summary:

    No Data Available

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

postcondition for the operation round on the predefined OCL type

  • Key: OCL2-7
  • Legacy Issue Number: 3800
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The postcondition for the operation round on the predefined OCL type real reads

    ((r - result) < r).abs < 0.5) or ((r - result).abs = 0.5 and (result > r))

    This is incorrect and should be replaced by

    ((r - result).abs < 0.5) or ((r - result).abs = 0.5 and (result > r))

  • Reported: OCL 2.0b1 — Fri, 1 Sep 2000 04:00 GMT
  • Disposition: Resolved — OCL 2.0b2
  • Disposition Summary:

    No Data Available

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

The property 'unspecified' can be removed from the metamodel

  • Key: OCL2_-92
  • Legacy Issue Number: 8821
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    Because UnspecifiedValueExp is a special kind of OclExpression, it is not necessary to define an explicit unspecified property. One can check the type of the OclExpression to see whether we are in the unspecified situation. This also make useless the need to define a specific getType() helper operation for OclMessageArg since the type can direcly be obtained.

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

    No Data Available

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

Instanciation of collection types

  • Key: OCL2_-94
  • Legacy Issue Number: 8823
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    In 8.2 the sentence "Users will never instanciate these types explicitly" is not entirely true. When a OCL writer defines a helper operation that returns a set, he explicitly declares the Set to be returned. Also, according to the OCL metamodel, an expression always has a type (OclExpression::type has multiplicity equal to 1). So when using the metamodel to exchange OCL specifications (XMI exchange) this implies that all used types, including expressions yielding to collection types have to be instanciated for the XMI to be well-formed.

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

    No Data Available

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

The metaclass 'OclMessageArg' can be removed from the metamodel

  • Key: OCL2_-93
  • Legacy Issue Number: 8822
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    A OclMessageExp can directly represent the arguments without the need of an intermediate class, just as OperationCallExp refer to its arguments

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

    No Data Available

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

The composition associations in figure 9 are missing

  • Key: OCL2_-91
  • Legacy Issue Number: 8820
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    The composition associations in figure 9 are missing. In particular, a message
    expression (OclMessageExp) should contain its arguments, its target expression, are –probably – specified call action. Otherwise the model cannot be properly instanciated

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

    No Data Available

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

The superclass of UnspecifiedValueExp is not ModelElement

  • Key: OCL2_-90
  • Legacy Issue Number: 8819
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    According to figure 9, the UnspecifiedValueExp does not inherits from OclExpression. However this is contradictory with the text description of the metaclass (and it own name).

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

    No Data Available

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

Reusing TypedElement for UnspecifiedValueExp

  • Key: OCL2_-89
  • Legacy Issue Number: 8818
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    The type property of UnspecifiedValueExp can be obtained from a superclass (for instance TypedElement or OclExpression

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

    No Data Available

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

An UnlimitedNaturalExp should be added in the metamodel

  • Key: OCL2_-88
  • Legacy Issue Number: 8817
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    An UnlimitedNaturalExp should be added in the metamodel to be used to access upper bound values in multiplicity specifications. This will be conformant with UML2 primitive literals

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

    No Data Available

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

The Ocl prefix should be avoided as much as possible in metaclass names

  • Key: OCL2_-87
  • Legacy Issue Number: 8816
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    Except for the abstract OclExpression metaclass which differentiates from the UML class Expression, the other metaclasses OclMessageType, OclMessageExp and OclMessageArg should better be renamed MessageType, MessageExp and MessageArg to improve uniformity and readability of the metamodel.

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

    No Data Available

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

Should avoid using the OclHelper stereotype

  • Key: OCL2_-86
  • Legacy Issue Number: 8815
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    Referring to the OclHelper stereotype in the well-formedness rules should be avoided since not strictly necessary. It should be possible yo use OCL in UML without using stereotypes

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

    No Data Available

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

Inconsistency in the way to represent Tuple literal part

  • Key: OCL2_-85
  • Legacy Issue Number: 8814
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    In the well-formedness rules there is a class named TupleLiteralExpPart but in the diagram VariableDeclaration is strangely used to represent the literal tuple parts.

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

    No Data Available

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

The naming of the parts properties in literals is not consistent

  • Key: OCL2_-84
  • Legacy Issue Number: 8813
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    The naming to refer to the parts of tuple literals and collection literals should be uniformized. For tuples it is called 'tuplePart' and for collection literals it is called 'parts'. Also the CollectionLiteralExp::parts and TupleLiteralExp::tuplePart properties is only depicted in the diagrams (missing in the class descriptions)

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

    No Data Available

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

The set of possible values of CollectionKind is missing

  • Key: OCL2_-83
  • Legacy Issue Number: 8812
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    The description of the CollectionKind should indicate the list of possible values

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

    No Data Available

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

Use a uniform convention to name multivalued properties

  • Key: OCL2_-82
  • Legacy Issue Number: 8811
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    In particular the properties NavigationCallExp::qualifiers, OperationCallEXp::arguments should be renamed NavigationCallExp::qualifier and OperationCallEXp::argument.

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

    No Data Available

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

make link explicit

  • Key: OCL2_-79
  • Legacy Issue Number: 8794
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    The link between a variable representing a parameter and the parameter should be made explicit.

    The link between a variable and a parameter is currently not explicitly modelled in the OCL abstract syntax. It depends on name comparison. This adds unnecessary complexity to implementers.

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

    No Data Available

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

The container for self and return variables is missing

  • Key: OCL2_-78
  • Legacy Issue Number: 8793
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    The OCL spec does not define who is the container of the 'self', the 'result' and other variables bound to the parameters of an operation. This makes the OCL instanciation incomplete and invalid.

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

    No Data Available

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

Inherited or non navigable properties should not appear in class descriptio

  • Key: OCL2_-81
  • Legacy Issue Number: 8810
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    In the association list of the OclExpression metaclass description, the 'appliedProperty', 'parentOperation' and 'initializedVariable' are non navigable and should be removed. In addition the 'type' property should be inherited from the UML2 metaclass TypedElement.

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

    No Data Available

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

Should compare the value of the slots and not the objects itself

  • Key: OCL2_-80
  • Legacy Issue Number: 8809
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    In the well-formedness rules of OclMessageType (section 8.2.2), the self.feature cannot be equal to the result of the asParameter() operation. The rule need to be rewritten so that the value of the slots are compared (the 'name' and 'type' instead of comparing the object themselves).

    A similar problem occurs in the well-formedness rule [2] of OclMessageType (section 8.2.2), the self.feature cannot be equal to the result of the 'referredSignal.feature' since in that case the referred features will be contained twice.

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

    No Data Available

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

VariableDeclaration should be renamed Variable

  • Key: OCL2_-77
  • Legacy Issue Number: 8792
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    The concept representing a parameter declaration is not called ParameterDeclaration but Parameter. Similarily, the concept corresponding to variable declaration should be called Variable. Also this concept already exists in UML2 and the name chosen for the metaclass is Variable.

    Also the name property of the variable can be taken from the super class NamedElement instead of having a specific varName attribute.

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

    No Data Available

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

Specific inheritance links at M1 level should be removed

  • Key: OCL2_-76
  • Legacy Issue Number: 8791
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    Figure 28 defines specific inheritance links between M1 types that are
    not inferred from M2 types. This links should be suppressed since it brings
    confusion and unnecessary complexity to the standard library
    definition. The particular compliance rules of OclVoid and OclAny can be defined independently of the "inheritance" formalism.

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

    No Data Available

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

OclAny cannot be an instance of Classifier

  • Key: OCL2_-75
  • Legacy Issue Number: 8790
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    Classifier is an abstract class. It is then not possible to define the OclAny of the standard library as a direct instance of classifier.

    Suggestion: Define a AnyType metatype

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

    No Data Available

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

Section: 11.9.2 reject

  • Key: OCL2_-74
  • Legacy Issue Number: 8664
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    On the left side of the equals symbol is the word "select" correct or should it be "iterate?"

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

    No Data Available

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

Section: 11.9.1 exists

  • Key: OCL2_-73
  • Legacy Issue Number: 8663
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    Now it is too early in the morning because the statement "Results in true if body evaluates to true for at least one element in the source collection" does not make sense with the OCL notation on the right side of the equals symbol "source->iterate(iterators; result:Boolean = false | result or body)." One says true, the other says false.

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

    No Data Available

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

Section: 11.7.2

  • Key: OCL2_-72
  • Legacy Issue Number: 8662
  • Status: closed  
  • Source: U. S. Geological Survey ( Jane Messenger)
  • Summary:

    It's late in the day but I do not see that the OCL definition for union(s:Set(T)): Set(T) is totally accurate because it does not mention that self and s cannot contain the same element or the union of self and s would be a bag not a set. I am also confused by the last post for bothe asSequenced(): Sequence(T) and asBag(): Bag(T) where the result->count(elem)=1. Should this be result->count(elem)>=1 in both cases because you're writing about sequences and bags?

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

    No Data Available

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

’StringValue.iterators

  • Key: OCL2_-71
  • Legacy Issue Number: 7547
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    39. The association between ’StringValue.iterators’ and ’LoopExpEval’ should be ordered on the side
    of ’StringValue.iterators’.

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

    No Data Available

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

context Classifier

  • Key: OCL2_-70
  • Legacy Issue Number: 7499
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    def: lookupAttribute(attName : String) : Attribute =
    self.allAttributes->any(me | me.name = attName)
    def: lookupAssociationEnd(name : String) : AssociationEnd =
    self.allAssociationEnds->any (ae | ae.name = name)
    def: lookupAssociationClass(name : String) : AssociationClass =
    self.allAssociationClasses->any (ae | ae.name = name)
    def: lookupOperation (name: String, paramTypes: Sequence(Classifier)):
    Operation =
    self.allOperations->any (op | op.name = name and
    op.hasMatchingSignature(paramTypes))
    def: lookupSignal (sigName: String, paramTypes: Sequence(Classifier)):
    Operation =
    self.allReceptions.signal->any (sig | sig.name = sigName and
    sig.hasMatchingSignature(paramTypes))
    ==> all references to operations like allAttributes are missing brackets, and the returnType of lookup-
    Signal should be Signal. The whole expression should be:
    context Classifier
    def: lookupAttribute(attName : String) : Attribute =
    self.allAttributes()->any(me | me.name = attName)
    def: lookupAssociationEnd(name : String) : AssociationEnd =
    self.allAssociationEnds()->any (ae | ae.name = name)
    def: lookupAssociationClass(name : String) : AssociationClass =
    self.allAssociationClasses()->any (ae | ae.name = name)
    def: lookupOperation (name: String, paramTypes: Sequence(Classifier)):
    Operation =
    self.allOperations()->any (op | op.name = name and
    op.hasMatchingSignature(paramTypes))
    def: lookupSignal (sigName: String, paramTypes: Sequence(Classifier)):
    Signal =
    self.allReceptions().signal->any (sig | sig.name = sigName and
    sig.hasMatchingSignature(paramTypes))

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

    No Data Available

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

context TTupleType::...

  • Key: OCL2_-69
  • Legacy Issue Number: 7498
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    30. context TTupleType::make(atts : Sequence(UML14::Core::Attribute) ) : TTupleType
    post: result.features = atts
    post: result.stereotype.name = ’OclHelper’
    ==> should be: context TTupleType::make(atts : OrderedSet(UML14::Core::Attribute) ) :
    TTupleType
    post: result.feature = atts
    post: result.stereotype.name = ’OclHelper’

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

    No Data Available

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

referredOperation

  • Key: OCL2_-68
  • Legacy Issue Number: 7497
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

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

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

    No Data Available

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

"Bag"

  • Key: OCL2_-67
  • Legacy Issue Number: 7496
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    28. – [1] The name of a bag type is "Bag" followed by the element type’s name in
    – parentheses.
    context BagType
    inv: self.name = ’Bag(’ + self.elementType.name + ’)’
    [1] The name of a collection type is "Collection" followed by the element
    – type’s name in parentheses.
    context CollectionType
    inv: self.name = ’Collection(’ + self.elementType.name + ’)’
    [1] The name of a set type is "OrderedSet" followed by the element type’s name
    – in parentheses.
    context OrderedSetType
    inv: self.name = ’OrderedSet(’ + self.elementType.name + ’)’
    [1] The name of a sequence type is "Sequence" followed by the element type’s
    – name in parentheses.
    context SequenceType
    inv: self.name = ’Sequence(’ + self.elementType.name + ’)’
    [1] The name of a set type is "Set" followed by the element type’s name in
    – parentheses. context SetType
    inv: self.name = ’Set(’ + self.elementType.name + ’)’
    ==> ’’ should be replaced by ’concat’ or ’’ should be allowed as concrete syntax for the String concat
    operation.
    inv: self.name = ’Bag(’.concat( self.elementType.name).concat(’)’)
    inv: self.name = ’Collection(’.concat(
    self.elementType.name).concat(’)’)
    inv: self.name = ’OrderedSet(’.concat(
    self.elementType.name).concat(’)’)
    inv: self.name = ’Sequence(’.concat( self.elementType.name).concat(’)’)
    inv: self.name = ’Set(’.concat( self.elementType.name).concat(’)’)

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

    No Data Available

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

context TTupleType::make(atts : sequence(Attribute) ) : TTupleType

  • Key: OCL2_-66
  • Legacy Issue Number: 7495
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    27. context TTupleType::make(atts : sequence(Attribute) ) : TTupleType
    post: result.features = atts
    post: result.stereotype.name = ’OclHelper’ ==> ’sequence(Attribute)’ should be ’Sequence(UML14::Core::Attribute)’

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

    No Data Available

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

type of a TupleLiteralExp

  • Key: OCL2_-65
  • Legacy Issue Number: 7494
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    26. – [1] The type of a TupleLiteralExp is a TupleType with the specified parts.
    context TupleLiteralExp
    inv: type.oclIsKindOf (OclAbstractSyntax::Types::TTupleType)
    and
    tuplePart->forAll (tlep |
    type.allAttributes()->exists (tp | tlep.attribute = tp))
    and
    tuplePart->size() = type.allAttributes()->size()
    ==> should be
    context TupleLiteralExp
    inv: type.oclIsKindOf (OclAbstractSyntax::Types::TTupleType)
    and
    tuplePart->forAll (tlep |
    type.allAttributes()->exists (tp | tlep.asAttribute().name = tp.name and
    tlep.asAttribute().type = tp.type and
    tlep.asAttribute().initExpression = tp.initExpression))
    and
    tuplePart->size() = type.allAttributes()->size()

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

    No Data Available

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

type of a TupleLiteralExp

  • Key: OCL2_-62
  • Legacy Issue Number: 7491
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    23. – [1] The type of a TupleLiteralExp is a TupleType with the specified parts.
    context TupleLiteralExp
    inv: type.oclIsKindOf (TupleType) and
    tuplePart->forAll (tlep |
    type.oclAsType (TupleType).allAttributes()->exists (tp | tlep.attribute
    = tp))
    and
    tuplePart->size() = type.oclAsType (TupleType).allAttributes()->size()
    ==> should be:
    context TupleLiteralExp
    inv: type.oclIsKindOf (OclAbstractSyntax::Types::TTupleType)
    and
    tuplePart->forAll (tlep |
    type.allAttributes()->exists (tp | tlep.asAttribute().name = tp.name and
    tlep.asAttribute().type = tp.type and
    tlep.asAttribute().initExpression = tp.initExpression))
    and
    tuplePart->size() = type.allAttributes()->size()

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

    No Data Available

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

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

  • Key: OCL2_-64
  • Legacy Issue Number: 7493
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    25. – [1] The type of the attribute is the type of the value expression.
    context TupleLiteralExpPart
    inv: attribute.type = value.type
    ==> should be removed, the type ’TupleLiteralExpPart’ does not exist.

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

    No Data Available

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

tuple literal expression

  • Key: OCL2_-63
  • Legacy Issue Number: 7492
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    24. – [2] All tuple literal expression parts of one tuple literal expression have
    – unique names.
    context TupleLiteralExp
    inv: tuplePart->isUnique (attribute.name)
    ==> should be:
    context TupleLiteralExp
    inv: tuplePart->isUnique (name)

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

    No Data Available

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

message is a send action,

  • Key: OCL2_-61
  • Legacy Issue Number: 7490
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    22. – [2] If the message is a send action, the arguments must conform to the
    – attributes of the signal.
    context OclMessageExp
    inv: sentSignal->notEmpty() implies
    arguments->forAll (a | a.getType().conformsTo
    (self.sentSignal.signal.feature.oclAsType(StructuralFeature)
    >at (arguments>indexOf (a)).type))
    ==> should be:
    context OclMessageExp
    inv: sentSignal->notEmpty() implies
    arguments->forAll (a | a.getType().conformsTo
    (self.sentSignal.signal.feature
    >at (arguments>indexOf
    (a)).oclAsType(UML14::Core::StructuralFeature).type) )

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

    Discussion:
    This well-formed rule is correct in the current OCL 2.0 specification. It is a duplicate of the issue 7471.
    Disposition: See Issue 7471 for disposition

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

message is a call action,

  • Key: OCL2_-60
  • Legacy Issue Number: 7489
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    21. – [1] If the message is a call action, the arguments must conform to the
    – parameters of the operation.
    context OclMessageExp
    inv: calledOperation->notEmpty() implies
    arguments->forAll (a | a.getType().conformsTo
    (self.calledOperation.operation.Parameter->
    select( kind = UML14::Core::ParameterDirectionKind::In )
    >at (arguments>indexOf (a)).type))

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

    No Data Available

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

’parameter’ should be ’Parameter’

  • Key: OCL2_-59
  • Legacy Issue Number: 7488
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    20. – [1] If the message is a call action, the arguments must conform to the
    – parameters of the operation.
    context OclMessageExp
    inv: calledOperation->notEmpty() implies
    arguments->forAll (a | a.getType().conformsTo
    (self.calledOperation.operation.parameter->
    select( kind = ParameterDirectionKind::In )
    >at (arguments>indexOf (a)).type))
    ==> ’parameter’ should be ’Parameter’

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

    No Data Available

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

the property ’refParams’ is not present in OperationCallExp

  • Key: OCL2_-58
  • Legacy Issue Number: 7487
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    ==> add the following:
    context OperationCallExp
    def: refParams: Sequence(UML14::Core::Parameter) =
    self.referredOperation.Parameter->asSequence()
    ==> see also number 21.

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

    No Data Available

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

forall’ should be ’forAll’

  • Key: OCL2_-57
  • Legacy Issue Number: 7486
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    18. – [1] All the arguments must conform to the parameters of the referred operation
    context OperationCallExp
    inv: arguments->forall (a | a.type.conformsTo
    (self.refParams->at (arguments->indexOf (a)).type))
    ==> ’forall’ should be ’forAll’

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

    No Data Available

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

attributes of the signal.

  • Key: OCL2_-54
  • Legacy Issue Number: 7483
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    15. – [2] If the message is a send action, the arguments must conform to the
    – attributes of the signal.
    context OclMessageExp
    inv: sentSignal->notEmpty() implies
    arguments->forall (a | a.getType().conformsTo
    (self.sentSignal.signal.feature.oclAsType(StructuralFeature)
    >at (arguments>indexOf (a)).type))
    ==> ’forall’ should be ’forAll’

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

    No Data Available

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

parameters of the operation.

  • Key: OCL2_-53
  • Legacy Issue Number: 7482
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    14. – [1] If the message is a call action, the arguments must conform to the
    – parameters of the operation.
    context OclMessageExp
    inv: calledOperation->notEmpty() implies
    arguments->forall (a | a.getType().conformsTo
    (self.calledOperation.operation.parameter->
    select( kind = ParameterDirectionKind::In )
    >at (arguments>indexOf (a)).type))
    ==> ’forall’ should be ’forAll’

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

    No Data Available

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

5] The target of an OCL message cannot be a collection.

  • Key: OCL2_-56
  • Legacy Issue Number: 7485
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    context OclMessageExp
    inv: not target.type.oclIsKindOf (CollectionType)
    ==> ’CollectionType should be ’OclAbstractSyntax::Types::CollectionType’

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

    No Data Available

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

’sentMessage’ should be ’sentSignal’

  • Key: OCL2_-55
  • Legacy Issue Number: 7484
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    16. – [4] An OCL message has either a called operation or a sent signal.
    context OclMessageExp
    inv: calledOperation->size() + sentMessage->size() = 1
    ==> ’sentMessage’ should be ’sentSignal’

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

    No Data Available

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

The type of the condition of an if expression must be Boolean.

  • Key: OCL2_-48
  • Legacy Issue Number: 7477
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    context IfExp
    inv: self.condition.type.oclIsKindOf(Primitive) and
    self.condition.type.name =
    ’Boolean’
    ==> ’Primitive’ should be ’UML14::Core::Primitive’

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

    No Data Available

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

result type

  • Key: OCL2_-50
  • Legacy Issue Number: 7479
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    [2] The result type of the collect operation on a sequence type is a sequence,
    – the result type of ’collect’ on any other collection type is a Bag. The type
    – of the body is always the type of the elements in the return collection.
    context IteratorExp
    inv: name = ’collect’ implies
    if source.type.oclIsKindOf(SequenceType) then
    type =
    expression.type.collectionType->select(oclIsTypeOf(SequenceType))-
    >first()
    else
    type = expression.type.collectionType->select(oclIsTypeOf(BagType))-
    >first()
    endif
    ==> should be
    context IteratorExp
    inv: name = ’collect’ implies if source.type.oclIsKindOf(OclAbstractSyntax::Types::SequenceType) then
    self.type = StandardLibrary::StdLib::Sequence
    and
    self.Body.type = Body.type
    else
    self.type = StandardLibrary::StdLib::Bag
    and
    self.Body.type = Body.type
    endif

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

    No Data Available

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

iterator

  • Key: OCL2_-49
  • Legacy Issue Number: 7478
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    [1] If the iterator is ’forAll’, ’isUnique’, or ’exists’ the type of the
    – iterator must be Boolean.
    context IteratorExp
    inv: name = ’exists’ or name = ’forAll’ or name = ’isUnique’
    implies type.oclIsKindOf(Primitive) and type.name = ’Boolean’
    ==> ’Primitive’ should be ’UML14::Core::Primitive’

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

    No Data Available

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

type of each iterator var. must be type of the elements of source collectio

  • Key: OCL2_-52
  • Legacy Issue Number: 7481
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    context IteratorExp
    inv: self.iterators->forAll(type = source.type.oclAsType
    (CollectionType).elementType)
    ==> ’CollectionType should be ’OclAbstractSyntax::Types::CollectionType’

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

    No Data Available

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

1] The type of the source expression must be a collection.

  • Key: OCL2_-51
  • Legacy Issue Number: 7480
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    context LoopExp
    inv: source.type.oclIsKindOf (CollectionType)
    ==> ’CollectionType should be ’OclAbstractSyntax::Types::CollectionType’

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

    No Data Available

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

collection literal expression

  • Key: OCL2_-47
  • Legacy Issue Number: 7476
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    [2] The type of a collection literal expression is determined by the
    – collection kind selection and the common supertype of all elements. Note that
    – the definition below implicitly states that empty collections have OclVoid as
    – their elementType.
    context CollectionLiteralExp
    inv: kind = CollectionKind::Set implies type.oclIsKindOf (SetType )
    inv: kind = CollectionKind::Sequence implies type.oclIsKindOf (SequenceType)
    inv: kind = CollectionKind::Bag implies type.oclIsKindOf (BagType )
    inv: type.oclAsType (CollectionType).elementType = parts->iterate (p; c
    :
    Classifier = OclVoid | c.commonSuperType (p.type))
    ==> should be
    context CollectionLiteralExp
    inv: kind = CollectionKind::Set implies type =
    StandardLibrary::StdLib::Set
    inv: kind = CollectionKind::OrderedSet implies type =
    StandardLibrary::StdLib::OrderedSet
    inv: kind = CollectionKind::Sequence implies type =
    StandardLibrary::StdLib::Sequence
    inv: kind = CollectionKind::Bag implies type =
    StandardLibrary::StdLib::Bag
    inv: type.oclAsType
    (OclAbstractSyntax::Types::CollectionType).elementType =
    parts->iterate (p; c :
    Classifier = StandardLibrary::StdLib::OclVoid | c.commonSuperType
    (p.type))

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

    No Data Available

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

7. context AttrubuteCallExp

  • Key: OCL2_-46
  • Legacy Issue Number: 7475
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    inv: type = referredAttribute.type
    ==> ’AttrubuteCallExp’ should be ’AttributeCallExp’

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

    No Data Available

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

context TupleType::make(atts : sequence(Attribute) ) : TupleType

  • Key: OCL2_-45
  • Legacy Issue Number: 7474
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    post: result.features = atts
    post: result.stereotype.name = ’OclHelper’
    ==> ’sequence’ should be ’OrderedSet’

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

    No Data Available

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

In section 3.3.9

  • Key: OCL2_-44
  • Legacy Issue Number: 7473
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    5. In section 3.3.9 the operations "OclExpression::withAtPre() : OperationCallExp" and "OclExpression::
    withAsSet() : OperationCallExp" should be prefixed with the keyword ’context’.

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

    No Data Available

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

context Operation

  • Key: OCL2_-43
  • Legacy Issue Number: 7472
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    context Operation
    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 )
    )
    )
    )
    ==> remove the ’=’ after Boolean
    ==> same error occurs in "context Signal def: hasMatchingSignature...."

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

    No Data Available

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

If message is a send action, arguments must conform to attributes of signal

  • Key: OCL2_-42
  • Legacy Issue Number: 7471
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    context OclMessageExp
    inv: sentSignal->notEmpty() implies
    arguments->forall (a | a.getType().conformsTo
    (self.sentSignal.signal.feature.oclAsType(StructuralFeature) )
    >at (arguments>indexOf (a)).type))
    ==> should be:
    context OclMessageExp
    inv: sentSignal->notEmpty() implies
    arguments->forAll (a | a.getType().conformsTo
    (self.sentSignal.signal.feature
    >at (arguments>indexOf
    (a)).oclAsType(UML14::Core::StructuralFeature).type) )

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

    No Data Available

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

The type of body expression must conform to declared type of result variabl

  • Key: OCL2_-41
  • Legacy Issue Number: 7470
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    context IterateExp
    Body.type.conformsTo(result.type)
    ==> missing ’inv:’

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

    This typo has already been corrected in the last OCL 2.0 release.

    Disposition: Close, no change

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

Errors in the abstract syntax chapter 1. -- [1] Integer conforms to real.

  • Key: OCL2_-40
  • Legacy Issue Number: 7469
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    context Primitive
    inv: (self.name = ’Integer’) implies
    Primitive.allInstances()->forAll (p | (p.name = ’Real’) implies
    (self.conformsTo(p))))
    ==> one closing bracket ’)’ too many

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

    No Data Available

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

The classifier name TupleType is also a reserved word

  • Key: OCL2_-39
  • Legacy Issue Number: 7468
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    The classifier name TupleType is also a reserved word. In order to check the constraints we have
    changed it into TTupleType.

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

    No Data Available

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

change rollnames

  • Key: OCL2_-38
  • Legacy Issue Number: 7467
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    1. The keywords ’pre’, ’body’, ’in’ and ’context’ are being used in the OCL expressions themselves to
    indicate role names. Actually this is an error. These can be avoided by changing the following
    rolenames:
    • - ’body’ of AbstractSyntax::Expression::LoopExp
    • - ’pre’ of OclDomain::Values::LocalSnapshot
    • - ’context’ of OclDomain::Evaluations::OclExpEval
    • - ’in’ of AbstractSyntax::Expression::LetExp
    • - ’in’of UML14::Core::ParameterDirectionKind
    To check the expressions we have changed the above names into the same word beginning with an
    upperclass character.

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

    No Data Available

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

OclMessageArg metaclass that is currently defined, could be removed.

  • Key: OCL2_-37
  • Legacy Issue Number: 7465
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    11. The OclMessageArg metaclass that is currently defined, could be removed. We propose the configuration
    depicted in figure 1, together with the following constraints. Note that a similar set of constraint
    must be added to chapter "The Use of Ocl Expressions in UML Models", depending on the
    exact alignment with the UML metamodel. Also note that both the first and second constraint of
    OclMessageExp on page 54 of the final adopted spec need to be changed: "arguments->forAll( a |
    a.getType() ...." should be "arguments->forAll( a | a.type ....".
    – an unspecified value expression may not have an applied property
    context UnspecifiedValueExp
    10 June 2004,
    page 2 of 22
    Klasse Objecten
    © Copyright Klasse Objecten
    inv: self.appliedProperty->isEmpty()
    – an unspecified value expression may not be used anywhere but as
    – argument to an OclMessageExp
    context OclExpression
    inv: not appliedProperty.oclIsTypeOf(UnspecifiedValueExp)
    context LoopExp
    inv: not body.oclIsTypeOf(UnspecifiedValueExp)
    context VariableDeclaration
    inv: not initExpression.oclIsTypeOf(UnspecifiedValueExp)
    context LoopExp
    inv: iterators->forAll(i | not i.oclIsTypeOf(UnspecifiedValueExp))
    context IterateExp
    inv: not result.oclIsTypeOf(UnspecifiedValueExp)
    context OperationCallExp
    inv: arguments->forAll( i | not i.oclIsTypeOf(UnspecifiedValueExp))
    context NavigationCallExp
    inv: qualifiers->forAll( i | not i.oclIsTypeOf(UnspecifiedValueExp))
    context IfExp
    inv: not thenExpression.oclIsTypeOf(UnspecifiedValueExp)
    context IfExp
    inv: not elseExpression.oclIsTypeOf(UnspecifiedValueExp)
    context IfExp
    inv: not condition.oclIsTypeOf(UnspecifiedValueExp)
    context LetExp
    inv: not in.oclIsTypeOf(UnspecifiedValueExp)

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

    No Data Available

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

tostring operation for Integer, Real and Boolean

  • Key: OCL2_-36
  • Legacy Issue Number: 7464
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    It would be convenient to have a tostring operation for Integer, Real and Boolean.

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

    No Data Available

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

plus (infix) operator (’+’)

  • Key: OCL2_-35
  • Legacy Issue Number: 7463
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    9. It would be very convenient to allow the plus (infix) operator (’+’) as concrete syntax for the String
    concat.

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

    No Data Available

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

flatten operation

  • Key: OCL2_-34
  • Legacy Issue Number: 7462
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    It is not clear from the specification whether the flatten operation is meant to be a deep or a shallow
    flatten. We prefer a deep flatten, but perhaps both options should be available.

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

    No Data Available

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

result of applying the collect operation to a Sequence

  • Key: OCL2_-30
  • Legacy Issue Number: 7458
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    The result of applying the collect operation to a Sequence should be a Sequence, not a Bag. Likewise,
    the result of applying the collect operation to an OrderedSet should be a Sequence, not a Bag.

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

    No Data Available

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

Remove the composition symbol at the end of PropertyCallExp

  • Key: OCL2_-29
  • Legacy Issue Number: 7456
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    Remove the composition symbol at the end of PropertyCallExp in the association between Property-
    CallExp (rolename appliedProperty) and OclExpression (rolename source). This should be a normal
    association.
    Composition implies lifetime dependency, therefore this use of composition is incorrect. An OclExpression
    exists independent of its (optional) applied property and they have no lifetime dependency.

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

    No Data Available

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

There should be an OclTypeLiteralExp metaclass

  • Key: OCL2_-33
  • Legacy Issue Number: 7461
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    There should be an OclTypeLiteralExp metaclass, subtype of LiteralExp. It should have an association
    with UML::Classifier.

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

    No Data Available

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

There should be an OclTypeLiteralExp metaclass

  • Key: OCL2_-32
  • Legacy Issue Number: 7460
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    There should be an OclStateLiteralExp metaclass, subtype of LiteralExp. It should have an association
    with UML::State.

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

    No Data Available

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

There should be an OclUndefinedLiteralExp metaclass

  • Key: OCL2_-31
  • Legacy Issue Number: 7459
  • Status: closed  
  • Source: OpenModeling ( Jos Warmer)
  • Summary:

    There should be an OclUndefinedLiteralExp metaclass, subtype of PrimitiveLiteralExp. The type of
    its instances should always be OclVoid.

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

    No Data Available

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

section 7.4.6 (Re-typing or casting) on p.13

  • Key: OCL2_-28
  • Legacy Issue Number: 7341
  • Status: closed  
  • Source: Missouri University of Science and Technology ( Thomas Weigert)
  • Summary:

    In section 7.4.6 (Re-typing or casting) on p.13, it is stated that "An object can only be re-typed to one of its subtypes". In other words, in the expression object.oclAsType(A), A must be a subtype of the type of the object. However, in section 7.5.8 (Accessing overridden properties of supertypes) on p.20 an example is given of object.oclAsType(A), where A is a supertype of object. This contradicts the assertion made earlier. In section 11.2.4 there are no constraints given on oclAsType that would rule out the usage shown in the second paragraph. However, in the semantics section on p.A-25 it is only stated that for oclAsType, the the target type must be a subtype of the source type or vice versa, supporting again the usage in the second paragraph. Judging from these, I assume that the restriction given on p.13 is incorrect.

  • Reported: OCL 2.0b2 — Sun, 16 May 2004 04:00 GMT
  • Disposition: Resolved — OCL 2.0
  • Disposition Summary:

    Type-casting is more general than the set of known subtypes and supertypes. If the OCL type system can be considered as open (meaning that OCL expressions may be applied to objects of types not known in the context in which it was defined), then it must be permitted to attempt a cast to any other type. UML implements multiple inheritance, so that given any two types, it is always a possibility that an object could be classified by both, even if they do not apparently have any relationship. This is particularly important for constraints defined in type libraries.

    Because OCL provides type tests oclIsKindOf() and oclIsTypeOf(), it is reasonable that failure to cast result in invalid to indicate an error condition. Note that a type-testing expression such as self.oclAsType(SomeType).oclIsInvalid() is correct, though it may be considered as poor style.

    The effect of casting is only a parse-time re-typing to provide visibility of features not defined for the original type, and a run-time assertion of the required type of an object. It cannot change the type of an object or coerce an object to an instance of a different type, nor can it provide access to hidden or overidden features of a supertype. For this, a new syntax is required that statically indicates the definition of a feature by the classifier that defines it.

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

Use the "null" keyword instead of verbose "OclUndefined".

  • Key: OCL2_-27
  • Legacy Issue Number: 6888
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    Use the "null" keyword instead of verbose "OclUndefined".

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

    No Data Available

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

What's a collection?

  • Key: OCL2_-26
  • Legacy Issue Number: 6633
  • Status: closed  
  • Source: HL7 ( Mr. Grahame Grieve)
  • Summary:

    OCL 2 does not clarify what makes a type a collection. It's clear that
    any multiple attributes and associations are collections. And from
    section 3.2, it's clear that parameterised classes may be treated as
    OCL collections. However not all parameterised classes can be treated
    as collections

    This needs further clarification

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

    No Data Available

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

Keywords "attr" and "oper"?

  • Key: OCL2_-25
  • Legacy Issue Number: 6615
  • Status: closed  
  • Source: Modeling Value Group ( Wim Bast)
  • Summary:

    Keywords "attr" and "oper" still necessary? Keywords attr and oper are defined in the keywords list, but are not included in the concrete grammar. Are they maybe superfluous? If "attr" is really a keyword, then the well-formedness rule on page 140 that uses a local variable attr must use another variable name.

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

    No Data Available

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

Formal Semantics of OCL 2.0 in Appendix A

  • Key: OCL2_-24
  • Legacy Issue Number: 6612
  • Status: closed  
  • Source: Modeling Value Group ( Wim Bast)
  • Summary:

    Maybe the completion of the formal semantics of OCL is an issue that is too extensive as part of the finalization process of OCL 2.0. Therefore, I suggest to just add a note in Appendix A concerning the currently still missing parts of the formal semantics, i.e., in particular OCL Messages, Ordered Set, and def-clauses. If you want you can refer to my paper about the Formal Semantics of OCL Messages, presented at the OCL Workshop at UML 2003. It can currently be found at http://i11www.ira.uka.de/~baar/oclworkshopUml03/papers/05_formal_semantics_ocl_messages.pdf

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

    No Data Available

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

OclUndefined = OclUndefine ?

  • Key: OCL2_-23
  • Legacy Issue Number: 6611
  • Status: closed  
  • Source: Modeling Value Group ( Wim Bast)
  • Summary:

    Perhaps it makes sense to explicitly mention whether OclUndefined = OclUndefined results in OclUndefined (or true)? The SQL equivalent seems to cause a lot of confusion, especially since in C "NULL == NULL" resturns true. For example, the above expression would not work with excluding(OclUndefined), given (OclUndefined=OclUndefined).isOclUndefined().....

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

    Technically, no change is necessary because the OclAny definition of the = operation, together with the definition of the singleton values null and invalid, is sufficient. However, being more explicit is helpful, especially as the there is no oclIsXyz() operation testing for void but not invalid.

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

Enumeration approach for reflection

  • Key: OCL2_-22
  • Legacy Issue Number: 6610
  • Status: closed  
  • Source: Modeling Value Group ( Wim Bast)
  • Summary:
    • I think the enumeration approach to reflection leads to a dead end. Why not leave that out for now and add full access to the user model in OCL2.1, when the other UML parts have stabilized. I think it would be quite straightforward to simply copy the relevant properties and operations from Classifier/Class to OclType.
  • Reported: OCL 2.0b2 — Thu, 13 Nov 2003 05:00 GMT
  • Disposition: Resolved — OCL 2.0
  • Disposition Summary:

    No Data Available

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

Issue: OclModelElement

  • Key: OCL2_-21
  • Legacy Issue Number: 6570
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Description: The object OclModelElement object should be removed from the standard library, while OclModelElementType should remain in OCL type hierarchy.
    Rationale: It implies a useless level of wrapping for the model objects.

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

    No Data Available

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

Issue: OclType

  • Key: OCL2_-20
  • Legacy Issue Number: 6569
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Description: OclType should disappear from the OCL type hierarchy.
    Rationale: OclType should be only present in the standard library to support values for the type expression used in functions like oclAsType(), oclIsKindOf(), and oclIsTypeOf().

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

    No Data Available

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

Issue: oclIUndefined() versus isEmpty()

  • Key: OCL2_-19
  • Legacy Issue Number: 6568
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Description: OCL offers two choices to test if a value is undefined or not: isEmpty and oclIsUndefined.
    Rationale: Most of the modern programming languages contain null values. The best OCL mapping for null value is the undefined value. Using isEmpty to test if a value is null/undefined is some how confusing:

    • the result of property->isEmpty() must be true if the value of the property is null/undefined
    • the result of Set {1/0}

      ->isEmpty() must be false
      because the expression property->isEmpty() is converted according to the OCL specification to Set

      {property}

      ->empty()
      These situations are a source of errors and confusion at the implementation level. I think that isEmpty() should be used only to test if a collection is empty or not; the null/undefined values should be tested using ocIslUndefined. This operation should be also valid on collections. This approach will also work nice and clear for nested collections. On the other hand I don't think that () should not be optional if the called operation has no arguments. This is feature specific to old languages like TAL and Pascal, while in modern languages like C, C++ the meaning of f and f() is different.

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

    No Data Available

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

Issue: Attributes and Association Ends versus Properties

  • Key: OCL2_-18
  • Legacy Issue Number: 6567
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Description: The submission uses the terms of Attributes and Association Ends, which are no longer used in UML 2.0.
    Rationale: In order to align OCL 2.0 and UML 2.0 specifications I think that the expression package should look like: I also think that the OCL grammar should be rewritten accordingly

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

    No Data Available

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

Issue: Operator precedence

  • Key: OCL2_-17
  • Legacy Issue Number: 6564
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Description: Section 4.3.2 does not specify precedence for operators like div, mod, ^^, or ^.
    Rationale: The operator precedence must be as precise as possible in order to provide a platform-independent implementation. I think that logical operators should be organized on different levels of precedence:
    'not'
    'and'
    'or'
    'xor'
    'implies'

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

    See issue 6544 for disposition

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

Issue: Keywords

  • Key: OCL2_-16
  • Legacy Issue Number: 6562
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Description: OCL 2.0 uses keywords (e.g. and, or, xor, implies etc.) that cannot be used elsewhere.
    Rationale: This means that these names cannot be used to identify properties, classes or packages. There are two options to solve this problem: either UML 2.0 specifies the names that cannot be used or the OCL concept of keywords has to be revised.

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

    No Data Available

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

Issue: Set of characters

  • Key: OCL2_-15
  • Legacy Issue Number: 6560
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Description: The OCL 2.0 specification should describe the set of characters allowed in the OCL constructions (e.g. Unicode or ASCII).
    Rationale: This will help implementers to solve another ambiguity and to produce portable implementations. Unicode will be in my opinion the best choice.

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

    No Data Available

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

Issue: General section to define OCL concepts

  • Key: OCL2_-14
  • Legacy Issue Number: 6558
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Description: The specification should contain an introductory section containing definitions of the terms used in the specification and other notations that are used (e.g. well-formed expression, ill-formed expression, behaviour, undefined-behaviour etc.).
    Rationale: This will avoid ambiguities and provide a better specification of the OCL (see specifications for C++, Java, and C#).

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

    No Data Available

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

Reintroduce allAttributes operator

  • Key: OCL2_-13
  • Legacy Issue Number: 6556
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Author: Herman Balsters (h.balsters@bdk.rug.nl)
    Description: Reintroduce allAttributes operator
    Rationale:
    In pre-OCL 2.0 versions, there was an operator called "allAttributes": this operator (to be applied to class objects) returns the set of attributes of that object. (This operator should also be applicable to tuples as well, by the way.) Now the strange thing has happened that this most useful operator has vanished in OCL 2.0 I propose that it be re-introduced.

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

    No Data Available

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

Missing equality and inequality operations on collection types

  • Key: OCL2_-12
  • Legacy Issue Number: 6555
  • 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: Missing equality and inequality operations on collection types
    Rationale:
    The collection types Set, Sequence, and Bag show a predefined = operation. However, this operation is not defined for the abstract type Collection.
    Moreover, the operation <> is missing for all collection types.

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

    No Data Available

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

Clarify definition of collectNested for Set, Bag, and Sequence

  • Key: OCL2_-11
  • Legacy Issue Number: 6552
  • 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 definition of collectNested for Set, Bag, and Sequence
    Rationale:
    For Set, Bag, and Sequence the definition of collectNested (page 6-17ff.) actually defines collect which should read collectNested.
    As a minor detail, the definition of collectNested seems to be the only one using iterators as iterator variable. This should be aligned with select, reject, etc.

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

    No Data Available

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

Undefined values, isEmpty() and Collections

  • Key: OCL2_-10
  • Legacy Issue Number: 6546
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Author: Octavian Patrascoiu (O.Patrascoiu@kent.ac.uk)
    Description: Most of the modern OO languages support null values, but OCL does not. In order to map null values into OCL concepts we used the undefined value. Unfortunately, OCL offers two choices to test if a value is undefined or not: isEmpty and oclIsUndefined. Using isEmpty for such a purpose is some how confusing:
    the result of property->isEmpty() must be true if the value of the property null/undefined
    the result of Set

    {1/0, 1/0}

    ->isEmpty() must be false
    These situations are a source of errors and confusion at the implementation level. I think that isEmpty() should be used only to test if a collection is empty or not; the undefined values should be tested using ocIslUndefined. This operation should be also valid on collections. This approach will also work nice and clear for nested collections.

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

    The submitter’s assertion about appropriate usage of oclIsUndefined() and isEmpty() is a matter of style. OCL does support null values, even in collections, so that a collection containing a single element that is null is not empty. The isEmpty() operation applied to scalar values that are null is an inevitable consequence of the coercion of scalars to sets. It is reasonable that a scalar null is coerced to an empty set while a non-null scalar is coerced to a non-empty set. Moreover, oclIsUndefined() is true not only for null, but also for invalid, which is not permitted in collections.

    Disposition: Closed, no change

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

Flagging recursive definitions

  • Key: OCL2_-7
  • Legacy Issue Number: 6543
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Author: Jörn Guy Süß (jgsuess@cs.tu-berlin.de)
    Description: Interpreter to warn of recursive definitions
    Rationale:
    While recursive definitions are necessary to express certain constructs, they may lack a fixpoint. Specification should require implementations to provide either an occurs check or structured time-out/stack-trace to handle these situations.

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

    No Data Available

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

Attributes and Association Ends versus Properties

  • Key: OCL2_-9
  • Legacy Issue Number: 6545
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Author: Octavian Patrascoiu (O.Patrascoiu@kent.ac.uk)
    Description: The submission uses the terms of Attributes and Association Ends, which are no longer used in UML 2.0. In order to align OCL 2.0 and UML 2.0 specifications I think that the expression package should look like:

    I also think that the OCL grammar should be rewritten accordingly.

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

    No Data Available

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

Operator precedence

  • Key: OCL2_-8
  • Legacy Issue Number: 6544
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Author: Octavian Patrascoiu (O.Patrascoiu@kent.ac.uk)
    Description: Logical operators 'and', 'or', and 'xor' have the same precedence, which in my opinion is not natural. I think that the precedence of these operators should be from highest to lowest as follows:

    'and'
    'or'
    'xor'

    Also, the precedence of some useful operators like 'div', 'mod', '', and '^', is not specified in section 4.3.2.

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

    No Data Available

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

Consider OclType as a powertype

  • Key: OCL2_-4
  • Legacy Issue Number: 6532
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Description: OclType is currently a subtype of OclAny and seen as an enumeration type. This leads to some drawbacks w.r.t. the specification of operations like oclAsType(), oclIsKindOf(), and oclIsTypeOf(), that need to reason about type conformance. As this cannot be done without accessing the metalevel, OclType should rather be considered as a powertype (cf. OCL Workshop paper at UML 2003: S.Flake, OclType - A Type or Metatype?).

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

    No Data Available

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

Flagging insecure cast from Set to Sequence

  • Key: OCL2_-6
  • Legacy Issue Number: 6542
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Author: Jörn Guy Süß (jgsuess@cs.tu-berlin.de)
    Description: Interpreter to warn of nondeterministic cast
    Rationale:
    If an OCL expression contains a cast from Set to Sequence types, nondeterminism is introduced through the order of the new sequence. Either such casts should be disallowed, or the specification should require that implementations give feedback that nondeterministic behavior is to be expected

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

    No Data Available

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

domain for library operations /, div

  • Key: OCL2_-5
  • Legacy Issue Number: 6537
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Author: Thomas Baar (thomas.baar@epfl.ch)
    Description: clarify, whether x/0 is undefined
    Rationale: On page 6/6, 6-7 the semantics of operation / is decribed informally as 'The value of self divided by r (respective i).' It remains unclear what self / 0 evaluates to.
    On page 6/7 the div-operation is specified in terms of /-operation, however with a pre-condition pre: i <> 0.
    Why is div handled differently from / ?

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

    No Data Available

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

Omit predefined type OclModelElement.

  • Key: OCL2_-3
  • Legacy Issue Number: 6531
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Description: OclModelElement is currently defined in the OCL Standard Library. It can simply be omitted, as it is actually never used. OclModelElementType, however, must remain in the metamodel, e.g., for the mapping of OclState.

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

    No Data Available

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

oclIsNew for a collection

  • Key: OCL2_-2
  • Legacy Issue Number: 6529
  • Status: closed  
  • Source: Ecole Polytechnique Federale de Lausanne ( Alfred Strohmeier)
  • Summary:

    Description: Provide an operation for creating a collection of new objects
    Rationale:
    Consider the case where you want to create a new smartcard for a set of persons. Any solution is currently longwinded. It would be nice to be able to have an operation oclIsNew that applies to a collection (or perhaps only to a Set), and states the number of objects to be created, e.g.:
    let: s: Set(SmartCards) in s.oclIsNew(self.person->size())...

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

    closed no change

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

OCL 2.0/international character sets

  • Key: OCL2_-1
  • Legacy Issue Number: 6393
  • Status: closed  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    The OCL 2.0 FAS makes several references to ASCII (pg. 22), lowercase and uppercase characters (pg. 33-34) that violate the requirement for allowing international character sets to be used with UML. This is unacceptable since it limits the use of UML.

  • Reported: OCL 2.0b2 — Thu, 30 Oct 2003 05:00 GMT
  • Disposition: Resolved — OCL 2.0
  • Disposition Summary:

    No Data Available

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

Section: A/2.3 Enumeration Types

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

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

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

    issue withdrawn by submitter

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

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

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

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

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

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

    {getInitialValue()}

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


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

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

Use of simple quotes and double quotes in strings

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

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

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

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

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

Missing definition of of iterators for OrderedSets

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

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

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

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

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

Type of a type expression

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

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

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

    Disposition: See issue 9171 for disposition

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

Use of MOF reflection in EssentialOCL should be clarified

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

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

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

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

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

No way to represent type parameters in the standard library

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

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

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

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

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

OCL 2.0 8.2 Collection Type packaging

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

    [Pending a resolution of Issue 10946]

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

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

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

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

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

    Disposition: See issue 9171 for disposition

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

Section: A.3.2.2 Syntax and Semantics of Postconditions

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

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

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

    No Data Available

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

Making OclAny denote any object

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

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

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

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

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

OCL 2.0: CollectionType constraint for invalid elements is incorrect

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

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

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

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

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

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

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

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

Clarify the common supertype of Bag and Sequence

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

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

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

    Adding clarification sentences

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

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

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

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

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

    Disposition: See issue 4451 for disposition

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

Section: A.3.1.2 Semantics of Expressions

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

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

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

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

    Disposition: Closed, no change

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

Incosistency between UnlimitedInteger and UnlimitedNatural

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

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

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

    No Data Available

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

Dynamic typing with allInstances()

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

    { Set_of_instances_of_classFoo, Set_of_instances_of_classBar}

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

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

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

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

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

    No Data Available

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

missing closing parethesis inthese two expressions

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

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

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

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

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

    No Data Available

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

Usage of initialization and derivation constraints on the same property

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

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

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

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

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

    No Data Available

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

Collection element type serialization

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

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

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

    Suggest:

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

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

    No Data Available

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

Section 8.2 InvalidType

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

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

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

    No Data Available

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

Section: 7.4.7, 7.4.9, 9.3.2

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

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

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

    No Data Available

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

TypeType

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

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

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

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

    No Data Available

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

ownership of association ends does not matter for traversal in OCL

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

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

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

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

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

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

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

    No Data Available

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

11.7.1

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

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

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

    No Data Available

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

11.2.5 (02)

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

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

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

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

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

    No Data Available

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

8.2.2 Well-formedness Rules for the Types Package

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

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

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

    No Data Available

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

11.8.1

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

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

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

    No Data Available

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

11.2.4 (OclInvalid) - similar criticism as 11.2.3

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

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

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

    No Data Available

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

11.2.5

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

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

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

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

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

    No Data Available

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

Naming of Constraints in OCL

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

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

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

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

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

    Does it?

    If not it would be useful to add.

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

    No Data Available

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

Section: 7.4.9

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

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

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

    No Data Available

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

Using "def"

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

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

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

    No Data Available

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

Section: 7.8

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

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

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

    No Data Available

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

Section "IteratorExpCS"

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

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

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

    No Data Available

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

Section 9.2.2

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

    "The OCL specification puts no restriction on visibility."

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

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

    No Data Available

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

11.2.3

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

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

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

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

    No Data Available

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

Section 7.6.3

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

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

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

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

    No Data Available

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

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

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

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

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

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

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

    reverse: Returns a sequence in reverse order

    join(namesOfCollections; namesOfProperties; booleanExpression; orderByExpression)

    Where:

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

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

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

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

    collections we want to get in the result.

    • booleanExpression is a valid boolean expression containing the

    conditions the elements from the collections defined in listOfCollections

    must satisfy in order to be included in the result

    • booleanExpression is a valid boolean expression containing the

    conditions the elements from the collections defined in listOfCollections

    must satisfy in order to be included in the result

    average: Calculate the average value in a collection

    stdev: Calculate the standard deviation of a collection

    variance: Calculate the variance of a collection

    median: Calculate the median of a collection

    mode: Calculate the mode of a collection

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

    No Data Available

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

The concrete syntax given is extremely difficult to implement

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

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

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

    Disposition: See issue 10439 for disposition

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

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

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

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

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

    No Data Available

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

type of the iterator variable is expected or not?

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

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

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

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

    Disposition: Close, no change

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

doubts about the iterator variables

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

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

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

    No Data Available

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

CollectionType and CollectionKind

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

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

    9.3 collectionTypeCS synthesized attributes, page 79, contains:

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

    using CollectionKind::Collection.

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

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

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

    An expression like the following is valid:

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

    and demonstrates the need for a concrete CollectionType.

    Recommendation:

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

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

    No Data Available

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

no explanations about how to manipulate optional and multivalued attributes

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

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

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

    No Data Available

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

section 7.4.6 (p. 12)

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

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

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

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

    Disposition: See Issue 7341 for disposition

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

Section: A/1.1.1 Types

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

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

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

    No Data Available

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

last line on page 28

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

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

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

    No Data Available

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

Section: A/1.2.4 System State

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

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

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

    No Data Available

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

Section: A/1.2.1 Objects

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

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

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

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

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

    No Data Available

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

Section: A/1.1.6 Generalization - editorial issues

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

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

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

    No Data Available

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

Section: A/1.1.5 Associations

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

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

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

    No Data Available

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

Section: A/1.1.5 Associations -- missing word

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

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

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

    No Data Available

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

Section: A/1.1.6 Generalization

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

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

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

    No Data Available

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

Section: A/1.1.5 Associations

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

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

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

    No Data Available

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

Section: A/2.2 Common Operations on All Types

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

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

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

    No Data Available

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

Section: A.2.5.8 Sequence Operations

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

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

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

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

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

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

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

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

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

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

    {...}

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

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

    )."

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

    Disposition: See issue 12488 for disposition

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

Section 8.2.1 Type Conformance on page 37

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

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

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

    No Data Available

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

Section: A.3.1.1 Syntax of Expressions

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

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

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

    No Data Available

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

Section: A.2.7 Type Hierarchy

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

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

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

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

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

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

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

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

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

    No Data Available

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

Section: A.2.6 Special Types

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

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

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

    No Data Available

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

Section: A.3.1.1 Syntax of Expressions

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

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

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

    Disposition: See issue 12474 for disposition

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

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

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

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

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

    No Data Available

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

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

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

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

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

    No Data Available

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

Section: A.3.1.2 Semantics of Expressions

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

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

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

    No Data Available

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

Section 8.2 page 35 InvalidType

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

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

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

    Disposition: See issue 12378 for disposition

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

Section: A.3.1.1 Syntax of Expressions

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

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

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

    No Data Available

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

Section: A/2.3 Enumeration Types -- editorial

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

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

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

    No Data Available

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

The constraint [1] on the TupleLiteralPart metaclass is overconstrained

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

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

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

    No Data Available

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

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

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

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

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

    No Data Available

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

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

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

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

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

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

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

    No Data Available

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

There are two instances of missing and misplaced parentheses

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

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

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

    Disposition: See Issue 12463 for disposition

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

A.2.5.5 Collection Operations

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

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

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

    Disposition: See Issue 12463 for disposition

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

Section: A.2.5.8 Sequence Operations

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

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

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

    No Data Available

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

Section: A.2.5.6 Set Operations Table A.4

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

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

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

    No Data Available

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

OrderedSet collection

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

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

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

    No Data Available

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

Section: A.2.5.6 Set Operations

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

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

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

    No Data Available

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

Section: A.2.5.5 Collection Operations

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

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

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

    No Data Available

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

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

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

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

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

    No Data Available

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

The Tuple constructor is problematic

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

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

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

    No Data Available

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

OCL/MOF/UML alignment

  • Key: OCL2-5
  • Legacy Issue Number: 6012
  • Status: closed  
  • Source: Modeling Value Group ( Wim Bast)
  • Summary:

    Document ad/2003-05-01 contains directions along which the OCL
    metamodel and the UML Infrastructure metamodel can be integrated to form one
    single language. The OCL has originally been conceived as part of the UML
    language, and has never been intended to be used separately. A tight
    connection between the two metamodels is nessesary for all modelers that
    want to use either UML, OCL, MOF, or a combination of these. Within the OMG
    the OCL is heavily used for specifyingconstraints on metamodels in the
    varous OMG standards. OCL is also used extensively in many of the proposals
    for the MOF 2.0 QVT RfP, as the solution for a query language, and as part
    of a transformation definition language. In all these cases, the OCL is used
    at the metamodel level, i.e. at the MOF level. Formally this is incorrect,
    because OCL isn't part of the MOF. Within the UML/MOF/OCL 2.0 framework, the
    UML and the MOF share a common core. The MOF 2.0 proposal reuses the UML 2.0
    Infrastucture. By integrating the OCL into the reused part of the UML 2.0
    infrastructure, the OCL metamodel is integrated with the MOF 2.0 as well.
    The definition of OCL at the MOF level is then achieved. Some aspects of the
    coupling of the OCL metamodel with the UML Superstructure metamodel are
    addressed in document ad/2003-05-01 as well.

  • Reported: OCL 2.0b1 — Tue, 22 Jul 2003 04:00 GMT
  • Disposition: Resolved — OCL 2.0b2
  • Disposition Summary:

    No Data Available

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

OCL 2: String operations

  • Key: OCL2-4
  • Legacy Issue Number: 5974
  • Status: closed  
  • Source: HL7 ( Mr. Grahame Grieve)
  • Summary:

    the routines on String are too sparse to support real world usage.
    In particular, most users would require:

    • uppercase and lowercase routines
    • the ability to ask if String1 is found in String2
    • case insensitive compare would be useful but can
      be built using the uppercase or lowercase routines
  • Reported: OCL 2.0b1 — Tue, 22 Apr 2003 04:00 GMT
  • Disposition: Resolved — OCL 2.0b2
  • Disposition Summary:

    No Data Available

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

OCL 2: Can collections contain void/undefined objects

  • Key: OCL2-3
  • Legacy Issue Number: 5972
  • Status: closed  
  • Source: HL7 ( Mr. Grahame Grieve)
  • Summary:

    Is it possible for collections to contain void (= undefined objects)?

    Conceptually, this would appear to be required so that you
    can specify whether an item in a collection can be null in
    an actual implementation. The use of void and undefined() is
    advised in exactly the same situation in a non-collection
    context.

    However, this quote from Section 2.4.11: "In general, an expression
    where one of the parts is undefined will itself be undefined", along
    with the rest of the section, shows that you can't use void as
    a parameter to the collection calls, and in the context of OCL as a
    language, this makes sense.

    So I thank that this constraint:

    context Collection
    inv: self->forAll(not OclIsUndefined())

    is required, and this should be stated to clear up uncertainties.

    This leaves the problem of how to say whether an "item in a collection
    can be null in an actual implementation" is inresolvable in OCL 2.

  • Reported: OCL 2.0b1 — Tue, 22 Apr 2003 04:00 GMT
  • Disposition: Resolved — OCL 2.0b2
  • Disposition Summary:

    No Data Available

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

OCL 2: flatten

  • Key: OCL2-2
  • Legacy Issue Number: 5970
  • Status: closed  
  • Source: HL7 ( Mr. Grahame Grieve)
  • Summary:

    quotes from ad/2003-01-07 (v1.6 of OCL 2 proposal):

    Section 1.5.1 says, "the flatten operation is a deep flatten, it
    completely flattens a nested collection of any depth". However the
    formal definition is :

    post: result = if self.type.elementType.oclIsKindOf(CollectionType) then
    self->iterate(c; acc : Set() = Set{} |
    acc->union(c->asSet() ) )
    else
    self
    endif

    From Section 6.5.1 (definition of Set.Flatten). The formal declaration does
    not show that the flatten operation is deep. This discussion is extended in
    Appendix A, which presents an analogous postcondition, but explains that this
    is for a single level only.

    It would seem that the post-condition(s) in section 6.5.1 are wrong?

  • Reported: OCL 2.0b1 — Tue, 22 Apr 2003 04:00 GMT
  • Disposition: Resolved — OCL 2.0b2
  • 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