Object Constraint Language Avatar
  1. OMG Specification

Object Constraint Language — Closed Issues

  • Acronym: OCL
  • Issues Count: 110
  • Description: Issues resolved by a task force and approved by Board
Closed All
Issues resolved by a task force and approved by Board

Issues Summary

Key Issue Reported Fixed Disposition Status
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
OCL2-6 Section 6.6.2 UML 1.4 OCL 2.0b2 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
OCL2-1 Section 6.6.7 UML 1.4 OCL 2.0b2 Resolved closed

Issues Descriptions

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 6.6.2

  • Key: OCL2-6
  • Legacy Issue Number: 5581
  • Status: closed  
  • Source: Capital One Bank (Europe) plc ( Matt Staples)
  • Summary:

    Section 6.6.2

    In the paragraph after the OCL sample should the word "reject" be "collect" instead?

  • Reported: UML 1.4 — Tue, 20 Aug 2002 04:00 GMT
  • Disposition: Resolved — OCL 2.0b2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:40 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 6.6.7

  • Key: OCL2-1
  • Legacy Issue Number: 5582
  • Status: closed  
  • Source: Capital One Bank (Europe) plc ( Matt Staples)
  • Summary:

    Section 6.6.7

    In the second bullet point:

    • shouldn't the italics refer to "employee" throughout? (In one case it says "employer"). - "unambiguous" should be "ambiguous".
  • Reported: UML 1.4 — Tue, 20 Aug 2002 04:00 GMT
  • Disposition: Resolved — OCL 2.0b2
  • Disposition Summary:

    No Data Available

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