Object Constraint Language Avatar
  1. OMG Specification

Object Constraint Language — Open Issues

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

Issues Summary

Key Issue Reported Fixed Disposition Status
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-188 result value of an association class call expression evaluation OCL 2.0b2 open
OCL25-195 context Classifier (02) OCL 2.0b2 open
OCL25-189 Allow defining default values for parameters in operations OCL 2.0b2 open
OCL25-190 OclUndefined / allInstances() clarification. OCL 2.0b2 open
OCL25-196 Template return types in operation signatures OCL 2.0b2 open
OCL25-191 OCL 2: what is a collection? OCL 2.0b1 open
OCL25-185 elements in the result value OCL 2.0b2 open
OCL25-184 result value of an if expression OCL 2.0b2 open
OCL25-186 value of a collection item OCL 2.0b2 open
OCL25-187 result value of an association end call expression OCL 2.0b2 open
OCL25-180 Section: 10.2.3 ObjectValue OCL 2.0b2 open
OCL25-181 Section: 9.1 OCL 2.0b2 open
OCL25-182 Section: 8.3.8 OCL 2.0b2 open
OCL25-183 Section: 8.3.1 OCL 2.0b2 open
OCL25-171 OCL 2.0 Issue: References to Additional Attributes and Operations OCL 2.0 open
OCL25-172 Section: A.3.2.2 Syntax and Semantics of Postconditions (02) OCL 2.0 open
OCL25-174 OCL Collections applied to Properties OCL 2.0 open
OCL25-175 Container of additional operations OCL 2.0b2 open
OCL25-176 Section: 10.3.4 OclMessageArgEval OCL 2.0b2 open
OCL25-177 Section: 10.3.2 AssociationEndCallExpEval OCL 2.0b2 open
OCL25-178 Section: 10.3 OCL 2.0b2 open
OCL25-179 Section: 10.2.1 Element OCL 2.0b2 open
OCL25-147 Incomplete and missing well-formedness rules OCL 2.0b2 open
OCL25-148 Lack of operation specifications OCL 2.0b2 open
OCL25-149 Up- and Down-casts with oclAsType(). OCL 2.0b2 open
OCL25-150 Provide access to the sender of a message OCL 2.0b2 open
OCL25-151 OCL 2: OrderedSet OCL 2.0b1 open
OCL25-138 Section: 8.3.4 OCL 2.0b2 open
OCL25-139 Section: 8.2 OCL 2.0b2 open
OCL25-140 result value of an association end call expression OCL 2.0b2 open
OCL25-141 parameters of the referredOperation OCL 2.0b2 open
OCL25-142 Add an import statement to OCL files (with package - endpackage block) OCL 2.0b2 open
OCL25-143 The notation when nesting "if then else" is too verbose OCL 2.0b2 open
OCL25-144 Issue: Parsing Tuple Types and Collection Types as Arguments OCL 2.0b2 open
OCL25-145 Issue: Comments OCL 2.0b2 open
OCL25-146 Satisfaction of Operation Specifications (2) OCL 2.0b2 open
OCL25-136 Section: 10.3.4 OclMessageExpEval OCL 2.0b2 open
OCL25-137 Section: 10.3.2 NavigationCallExpEval OCL 2.0b2 open
OCL25-132 Errors in examples OCL 2.0 open
OCL25-131 Recursivity is not explicitly addressed with examples OCL 2.0 open
OCL25-133 Naming of Constraints in OCL (02) OCL 2.0 open
OCL25-134 Recommendations re ptc/2005-06-06 OCL 2.0 open
OCL25-135 Section: 10.4 OCL 2.0b2 open
OCL25-108 The notation when nesting "if then else" is too verbose OCL 2.0b2 open
OCL25-109 Issue: Signature of Environment OCL 2.0b2 open
OCL25-110 Additional annotations in the OCL Standard Library OCL 2.0b2 open
OCL25-105 OCL Constraints in many levels OCL 2.0b2 open
OCL25-104 number of elements in the result value OCL 2.0b2 open
OCL25-106 value of an association end call expression evaluation OCL 2.0b2 open
OCL25-107 Add a concrete syntax to allow OCL users to add additional IteratorExp’s OCL 2.0b2 open
OCL25-99 Redundant CollectionLiteralExp::kind complicates collection type extension OCL 2.0 open
OCL25-100 Provide the list of reflective MOF operations that are available OCL 2.0 open
OCL25-101 Section: 10.3.4 OclMessageArgEval OCL 2.0b2 open
OCL25-103 Section: 10.3.2 OperationCallExp OCL 2.0b2 open
OCL25-102 Section: 10.3.1 VariableExpEval OCL 2.0b2 open
OCL25-65 value of an association class call expression OCL 2.0b2 open
OCL25-66 context Parameter::asAttribute(): Attribute OCL 2.0b2 open
OCL25-67 Allow defining standard library functions OCL 2.0b2 open
OCL25-68 compliance points strategies OCL 2.0b2 open
OCL25-70 Introduce a "tuplejoin" operator OCL 2.0b2 open
OCL25-69 Satisfaction of Operation Specifications (3) OCL 2.0b2 open
OCL25-62 Section 8.3.9 of the final Adopted Version of the OCL 2.0 Spec OCL 2.0 open
OCL25-61 Section: 10.4.3 IntegerLiteralExpEval OCL 2.0b2 open
OCL25-63 Section: 10.3.5 OCL 2.0b2 open
OCL25-64 Section: 9.3 CollectionLiteralPartsCS OCL 2.0b2 open
OCL25-56 CMOF serializations of its metamodels not published OCL 2.0 open
OCL25-58 Section: A.3.2.2 Syntax and Semantics of Postconditions (04) OCL 2.0 open
OCL25-57 Section: A.3.2.2 Syntax and Semantics of Postconditions (03) OCL 2.0 open
OCL25-55 Mismatch between the definition of operators in, e.g., Section 11.7.1 and i OCL 2.0 open
OCL25-60 inclusion of Regular Expression support OCL 2.0 open
OCL25-59 Section: 11.5.1 OCL 2.0b2 open
OCL25-44 Satisfaction of Operation Specifications OCL 2.0b2 open
OCL25-43 Exception of strict evaluation (=) OCL 2.0b2 open
OCL25-38 Section: 8.3.5 OCL 2.0b2 open
OCL25-40 Section: 8.3 OCL 2.0b2 open
OCL25-39 Section: 7.5.8 OCL 2.0b2 open
OCL25-41 result value of an association end call expression (02) OCL 2.0b2 open
OCL25-42 outgoingMessages results in the sequence of OclMessageValues OCL 2.0b2 open
OCL25-33 Special Types violate UML Generalization Semantics OCL 2.0 open
OCL25-34 Section: A/2.5.5 Collection Operations - Table A.3 OCL 2.0 open
OCL25-35 Section: 10.3.1 LoopExpEval OCL 2.0b2 open
OCL25-37 Section: 10.2.1 NameValueBinding OCL 2.0b2 open
OCL25-36 Section: 10.2 OCL 2.0b2 open
OCL25-18 result value of an association class call expression OCL 2.0b2 open
OCL25-19 context VariableDeclaration::asAttribute() : Attribute OCL 2.0b2 open
OCL25-20 context Operation OCL 2.0b2 open
OCL25-21 Issue: OclAny operations of tuples and collections OCL 2.0b2 open
OCL25-22 Issue: Grammar of OCL OCL 2.0b2 open
OCL25-17 Section: 10.1 OCL 2.0b2 open
OCL25-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

Issues Descriptions

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

result value of an association class call expression evaluation

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

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

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

    {1..formalQualifiers->size()}

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

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

context Classifier (02)

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

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

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

Allow defining default values for parameters in operations

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

    Allow defining default values for parameters in operations

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

OclUndefined / allInstances() clarification.

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

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

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

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

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

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

Template return types in operation signatures

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

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

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

OCL 2: what is a collection?

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

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

    This question arises in 2 different ways:

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

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

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

elements in the result value

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

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

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

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

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

result value of an if expression

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

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

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

value of a collection item

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

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

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

result value of an association end call expression

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

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

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

Section: 10.2.3 ObjectValue

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

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

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

Section: 9.1

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

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

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

Section: 8.3.8

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

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

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

Section: 8.3.1

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

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

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

OCL 2.0 Issue: References to Additional Attributes and Operations

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

    Re: OCL 2.0 formal/06-05-01

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

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

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

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

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

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

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

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

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

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

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

OCL Collections applied to Properties

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

    OCL Specification, v2.0

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

    For instance, assume

    class A

    { int x[]; }

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

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

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

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

Container of additional operations

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

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

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

Section: 10.3.4 OclMessageArgEval

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

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

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

Section: 10.3.2 AssociationEndCallExpEval

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

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

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

Section: 10.3

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

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

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

Section: 10.2.1 Element

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

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

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

Incomplete and missing well-formedness rules

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

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

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

Lack of operation specifications

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

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

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

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

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

Up- and Down-casts with oclAsType().

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

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

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

Provide access to the sender of a message

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

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

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

OCL 2: OrderedSet

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

    OrderedSet isn't discussed in the section on semantics

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

Section: 8.3.4

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

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

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

Section: 8.2

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

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

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

result value of an association end call expression

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

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

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

parameters of the referredOperation

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

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

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

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

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

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

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

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

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

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

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

Issue: Parsing Tuple Types and Collection Types as Arguments

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

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

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

Issue: Comments

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

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

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

Satisfaction of Operation Specifications (2)

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

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

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

Section: 10.3.4 OclMessageExpEval

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

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

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

Section: 10.3.2 NavigationCallExpEval

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

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

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

Errors in examples

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

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

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

Recursivity is not explicitly addressed with examples

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

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

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

Naming of Constraints in OCL (02)

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

    OCL Specification, v2.0

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

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

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

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

Recommendations re ptc/2005-06-06

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

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

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

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

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

Section: 10.4

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

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

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

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

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

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

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

Issue: Signature of Environment

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

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

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

Additional annotations in the OCL Standard Library

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

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

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

OCL Constraints in many levels

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

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

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

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

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

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

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

number of elements in the result value

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

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

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

value of an association end call expression evaluation

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

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

    {1..formalQualifiers->size()}

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

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

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

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

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

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

Redundant CollectionLiteralExp::kind complicates collection type extension

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

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

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

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

Provide the list of reflective MOF operations that are available

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

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

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

Section: 10.3.4 OclMessageArgEval

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

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

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

Section: 10.3.2 OperationCallExp

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

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

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

Section: 10.3.1 VariableExpEval

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

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

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

value of an association class call expression

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

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

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

context Parameter::asAttribute(): Attribute

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

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

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

Allow defining standard library functions

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

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

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

compliance points strategies

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

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

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

Introduce a "tuplejoin" operator

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

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

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

Satisfaction of Operation Specifications (3)

  • Key: OCL25-69
  • Legacy Issue Number: 6550
  • Status: open  
  • Source: Anonymous
  • Summary:

    Author: Hubert Baumeister (baumeist@informatik.uni-muenchen.de),
    Rolf Hennicker (hennicke@informatik.uni-muenchen.de),
    Alexander Knapp (knapp@informatik.uni-muenchen.de)
    Description: Change Definition A.34 to allow the precondition to be weakened
    Rationale:
    It is commonly accepted that a program S satisfying an operation specification may weaken the precondition. This corresponds to Bertrand Meyer's view of software specifications as contracts between clients of a program and program provider. This is in accordance with the explanation following Def. A.34: "In other words, the program S accepts each environment satisfying the precondition as input and produces an environment that satisfies the postcondition." This sentence admits the possibility that S may be defined for environments not satisfying the precondition.
    However Def. A.34 requires S to be defined exactly on the environments for which the precondition holds. Therefore, we propose to replace Def. A.34 by:
    DEFINITION A.34 (SATISFACTION OF OPERATION SPECIFICATIONS)
    An operation specification with pre- and postconditions is satisfied by a program S in the sense of total correctness if the computation of S is a function fS such that the restriction of fS to the domain of R is a total function fS|_dom(R): dom(R) -> im(R) and graph(fS|_dom(R)) \subseteq R.

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

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

  • Key: OCL25-62
  • Legacy Issue Number: 8902
  • Status: open  
  • Source: Anonymous
  • Summary:

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

  • Reported: OCL 2.0 — Tue, 7 Jun 2005 04:00 GMT
  • Updated: Thu, 8 Oct 2015 14:12 GMT

Section: 10.4.3 IntegerLiteralExpEval

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

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

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

Section: 10.3.5

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

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

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

Section: 9.3 CollectionLiteralPartsCS

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

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

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

CMOF serializations of its metamodels not published

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

inclusion of Regular Expression support

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

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

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

Section: 11.5.1

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

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

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

Satisfaction of Operation Specifications

  • Key: OCL25-44
  • Legacy Issue Number: 6548
  • Status: open  
  • Source: Anonymous
  • Summary:

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

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

Exception of strict evaluation (=)

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

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

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

Section: 8.3.5

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

    CollectionItem shows an association - item:OclExpression - in the fig. 10. CollectionLiteralExp shows an association in fig. 10 - parts:CollectionLiteralPart. This is an ordered association. CollectionRange shows two associations in fig. 10 - first:OclExpression and last:OclExpression. UML 2.0 (ptc/04-10-02) doesn't recognize Real as a primitive type but does use UnlimitedNatural. Need to add UnlimitedNatural as a primitive type. The attribute symbol for PrimitiveLiteralExp is not shown in fig. 10. TuppleLiteralExp shows an association in fig. 10 - tuplePart:VariableDeclaration. The statement that TupleLiteralExp "contains a name and a value for each part of the tuple type" implies attributes but these are not shown in fig. 10 or listed as attributes in the notation. Add a notation for VariableDeclaration.

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

Section: 8.3

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

    Fig. 6 does not agree with fig. 12 (pg 60) in the number of subclasses that inherit from OCLExpression. Fig. 6 nor the subsequene notation have any mention of LetExp. Please add this to Chapter 8.

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

Section: 7.5.8

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

    In last paragraph on page 20 change the word "dotted" to "dashed" and in Fig. 3 change the dashed line denoting Dependency as an AssociationClass to a dotted line. This will agree with Fig. 1 example of an association class as well as the Notation described for AssociationClass on pg 45 of UML Superstructure (ptc/04-10-02).

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

result value of an association end call expression (02)

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

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

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

outgoingMessages results in the sequence of OclMessageValues

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

    – that have been in the output queue of the object between the last
    – postcondition snapshot and its associated precondition snapshot.
    context OclExpEval::outgoingMessages() : Sequence( OclMessageValue )
    pre: – none
    post:
    let end: LocalSnapshot =
    history->last().allPredecessors()>select( isPost = true )>first() in
    let start: LocalSnapshot = end.Pre in
    let inBetween: Sequence( LocalSnapshot ) = start.allSuccessors()>excluding( end.allSuccessors())>including(
    start ) in
    result = inBetween.outputQ->iterate (
    – creating a sequence with all elements present once
    m : oclMessageValue;
    res: Sequence( OclMessageValue ) = Sequence{}

    if not res->includes( m )
    then res->append( m )
    else res
    endif )
    ==> ’pre’ should be ’Pre’
  • Reported: OCL 2.0b2 — Thu, 10 Jun 2004 04:00 GMT
  • Updated: Thu, 8 Oct 2015 14:11 GMT

Special Types violate UML Generalization Semantics

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

    Special Types violate UML Generalization Semantics The definition of OclAny as a general of all classes in the UML model and of OclVoid and OclInvalid as specializations of all classes in the UML model are in violation of the semantics of generalization. Classifiers in the UML may only specialize other classifiers of the same or a conformant metaclass. From the description of Classifier in the UML: [3] A classifier may only specialize classifiers of a valid type. self.parents()->forAll(c | self.maySpecializeType(c)) [8] The query maySpecializeType() determines whether this classifier may have a generalization relationship to classifiers of the specified type. By default a classifier may specialize classifiers of the same or a more general type. It is intended to be redefined by classifiers that have different specialization constraints. Thus, it is not valid for OclAny (an instance of the AnyType metaclass) to be the general of any other class. Likewise, OclVoid and OclInvalid may not specialize any other class at all. This could be corrected in OclVoid and OclInvalid by redefining the maySpecializeType() query. For OclAny, the solution is not so straight-forward, as I don't see that OCL can redefine maySpecializeType() on behalf of the UML metaclasses; according to Section 7.4.4, it is not permitted to attempt to define an additional operation that clashes with an intrinsic operation of the context classifier.

  • Reported: OCL 2.0 — Sun, 24 Aug 2008 04:00 GMT
  • Updated: Thu, 8 Oct 2015 14:11 GMT

Section: A/2.5.5 Collection Operations - Table A.3

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

    Table A.3 has several problems in the "Semantics" column: Row 2: Besides being hard to read, the expression seems to be wrong. There is no operator between the C and capital pi (which I assume to be a Cartesian product), and the "is not an element of" seems like it couldn't be right. Maybe I'm at fault, but I can't make any sense of it. Row 4: There's no entry here. How about " C 'intersect'

    {v}

    = Ø" Row 6: The operator should be intersection, not Cartesian product, that is the capital pi should is the wrong symbol here. Rows 8 & 9: First, there shouldn't be anything in row 9's semantics column since the other columns are all blank. Are the c's supposed to be the capital C's? I can't make any sense of the expression, which could be my problem, but I don't think so.

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

Section: 10.3.1 LoopExpEval

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

    For the association bodyEvals the name of the associated class does not agree with the class name in fig. 20

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

Section: 10.2.1 NameValueBinding

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

    NameValueBinding show an attribute and an association in fig. 16 that are not mentioned in the description/definition as are other attributes and associations in other descriptions/definitions.

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

Section: 10.2

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

    The last paragraph on pg 94 that describes fig. 15 does not agree in names with the value names shown in fig. 15. StaticValue equates to the daya values the paragraph mentions and OclVoidValue apparently equates to "UndefinedValue." Since "UndefinedValue" and "OclVoidValue" both have the format of a class name this could lead to confusion. OclVoidValue, as later defined, is an undefined value so please change "UndefinedValue" in the open paragraph of this section.

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

result value of an association class call expression

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

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

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

context VariableDeclaration::asAttribute() : Attribute

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

    post: result.constraint.bodyExpression = self.initExpression
    ==> should be:
    post:
    result.constraint.bodyExpression.oclAsType(OCLContextualClassifier::Expre
    ssionInOcl).bodyExpression
    = self.initExpression

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

context Operation

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

    def: hasMatchingSignature(paramTypes: Sequence(Classifier)) : Boolean =
    – check that operation op has a signature that matches the given parameter lists
    let sigParamTypes: Sequence(Classifier) = self.allAttributes.type in
    (
    ( sigParamTypes->size() = paramTypes->size() ) and
    ( Set

    {1..paramTypes->size()}

    ->forAll ( i |
    paramTypes->at .conformsTo (sigParamTypes->at )
    )
    )
    )
    ==> ’self.allAttributes.type’ should be ’self.Parameter.type->asSequence()’

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

Issue: OclAny operations of tuples and collections

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

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

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

Issue: Grammar of OCL

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

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

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

Section: 10.1

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

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

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

OCL 2.0 8.2 Collection Type name distinguishability

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

    The name of a Set (or other Collection) is defined to use the element type name.
    This is not consistent with the UML requirement for distinguishability of namespace
    memebers. (UML Infra 9.14.2 Namespace).

    OCL should permit, and perhaps require, that the name of a Collection use
    the element type qualified name, so that two sets of distinct element type
    are not folded into indistinguishable names.

    This is a problem for model to model transformation where the same class name can
    easily occur on both input and output meta-model, and where the requirement to reify
    collection types can easily result in Set(input::name) and Set(output::name) in
    the same namespace.

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

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