Object Constraint Language Avatar
  1. OMG Specification

Object Constraint Language — All Issues

  • Acronym: OCL
  • Issues Count: 16
  • Description: All Issues
Closed All
All Issues

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

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