Issues for OCL 2.0 Finalization Task Force

To comment on any of these issues, send email to ocl2-ftf@omg.org. (Please include the issue number in the Subject: header, thusly: [Issue ###].) To submit a new issue, send email to issues@omg.org.

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Issue 1790: Lack of features commonly used in OCL (ocl2-ftf)

Click here for this issue's archive.
Nature: Enhancement
Severity: Significant
Summary:

Summary: The current specification for OCL lacks many of the features we commonly
 use when doing formal specification of class interfaces, e.g. the ability 
 to specify the frame condition, the ability to specify postconditions 
 case-wise, the ability to specify when exceptions are thrown, etc.
 
 To bring OCL closer to the state of the art, I would like to see these 
 considered as future extensions.

Resolution:
Revised Text: This issue needs to be resolved by the OCL 2.0 Finalization Task Force
Actions taken:
August 10, 1998: received issue
July 22, 1999: Deferred to UML 1.4/2.0.
December 2, 2004: Transferred to OCL 2.0 FTF

Discussion:

This issue needs to be resolved by the OCL 2.0 Finalization Task Force. This is an UML 1.x issue transferred to the OCL 2 FTF.
Not all the extra facilities suggested by the text of this issue have been incorporated to the
OCL2 specification. Specific facilities for specifying constraints on class interfaces could
be considered within the context of an RTF.
Disposition: Deferred

Issue 3392: OCL needs an abstract syntax, just like the UML metamode (ocl2-ftf)

Source: Klasse Objecten (Dr. Jos Warmer, j.warmer@klasse.nl)
Nature: Uncategorized Issue
Severity:
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.

Resolution:
Revised Text: Resolution: This is an OCL 1 issue transferred to the OCL 2 FTF. Section 8 of the OCL2 specification provides the metamodel. Revised text: No text change needed.
Actions taken:
March 1, 2000: received issue
December 2, 2004: Transferred to OCL 2.0 FTF
November 1, 2005: closed issue

Issue 3513: OCL: Usage of qualifiers (ocl2-ftf)

Click here for this issue's archive.
Source: Klasse Objecten (Dr. Jos Warmer, j.warmer@klasse.nl)
Nature: Uncategorized Issue
Severity:
Summary:

Qualifiers, written in brackets after the path name of a feature call,
can express two different things.

- qualifying use: A qualifier is used to give the qualifing value of 
      a qualified association (chapter 7.5.7).
- navigational use: A qualifier is used to refine the navigation to 
      association classes. While this navigational use is necessary 
      only with recursive associations, it is legal for every navigation
      to an association class (chapter 7.5.5).

There is no way to distinguish these two sorts of qualifiers. There are
even expressions where both uses of the qualifiers would be necessary at
once, but this problem is restricted to such models that contain a
recursive, qualified association that has an association class.

Example where navigational and qualifing use cannot be distinguished:

There are two classes "Bank" and "Person", with a association between
them qualified by the account number (an Integer). The association end
at the class Person is named "customers".
An additional class "Company" has an attribute "customers" of type
Integer.

Now consider the subexpression "bank.person[customers]" in the context
of Company. "bank" clearly is a navigational expression. But "customers"
could either mean the attribute of Company, since Company is the context
of the expression (that is qualifying use as defined in 7.5.7); or
"customer" could mean the name of the association end (navigational use
as defined in 7.5.5). In the first case, the result type would be
Person, in the second case Set(Person).

Resolution:
Revised Text:
Actions taken:
March 29, 2000: received issue
December 2, 2004: Transferred to OCL 2.0 FTF

Discussion:

Discussion:
This is an OCL 1 issue transferred to the OCL 2 FTF.
Deferred for timing constraints.

Issue 3800: postcondition for the operation round on the predefined OCL type (ocl2-ftf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
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))

Resolution:
Revised Text: Discussion: This is an OCL 1 issue transferred to the OCL 2 FTF. The OCL2 text has already corrected this using this definition: post: ((self - result).abs() < 0.5) or ((self - result).abs() = 0.5 and (result > self)) Revised text: No text change needed.
Actions taken:
September 1, 2000: received issue
December 2, 2004: Transferred to OCL 2.0 FTF
November 1, 2005: closed issue

Issue 3855: context declaration for OCL invariants (ocl2-ftf)

Click here for this issue's archive.
Nature: Enhancement
Severity: Minor
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.

Resolution:
Revised Text:
Actions taken:
September 13, 2000: received issue
December 2, 2004: Transferred to OCL 2.0 FTF
November 1, 2005: closed issue

Discussion:

Discussion:
This is an OCL 1 issue transferred to the OCL 2 FTF.
Asking for a language enhancement which does not fit well with object orientation style where an
invariant has a unique context object.
Disposition: Closed, no change

Issue 4112: OCL: Created and Destroyed instances (ocl2-ftf)

Click here for this issue's archive.
Nature: Enhancement
Severity: Significant
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.

Resolution:
Revised Text: Resolution: This is an OCL 1 issue transferred to the OCL 2 FTF. Resolved in OCL2 thanks to the new oclIsNew construct Revised text: No text change needed.
Actions taken:
December 8, 2000: received issue
December 2, 2004: Transferred to OCL 2.0 FTF
November 1, 2005: closed issue

Issue 4121: In 6.9 "Grammar for OCL" (Internationalization issues) (ocl2-ftf)

Click here for this issue's archive.
Source: Fujitsu (Mr. Hiroshi Miyazaki, miyazaki.hir-02@jp.fujitsu.com RHD02651@nifty.ne.jp)
Nature: Uncategorized Issue
Severity:
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    := " "|"\"|"#"|"\'"|"("|")"|"*"|"+"|","|"-"|
>                         "."|"/"|":"|";"|"<"|"="|">"|"@"|"["|"\\"|
>                         "]"|"{"|"|"|"}"

Resolution:
Revised Text: Resolution: The OCL2 defines the production rule simpleNameCS ::= <String> where <String> is left undefined to allow to use multi-byte characters for internationalisation. Revised text: No text update is needed. Disposition: Resolved
Actions taken:
December 9, 2000: received issue
December 2, 2004: Transferred to OCL 2.0 FTF
November 1, 2005: closed issue

Discussion:

already a quick fix in 1.4, further defer to 2.0. Discussion:
This is an OCL 1 issue transferred to the OCL 2 FTF.

Issue 4451: Downcast OCL collection operators (ocl2-ftf)

Click here for this issue's archive.
Source: NIST (Mr. Conrad Bock, conrad.bock@nist.gov conradb@cme.nist.gov)
Nature: Revision
Severity: Significant
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.

Resolution:
Revised Text:
Actions taken:
August 3, 2001: received issue
December 2, 2004: Transferred to OCL 2.0 FTF

Discussion:

Discussion:
This is an OCL 1 issue transferred to the OCL 2 FTF.
Deferred for timing constrains.

Issue 4691: 1. 6.2.1 "legend" on page 6-3, Internationalization issue (ocl2-ftf)

Click here for this issue's archive.
Source: Fujitsu (Mr. Hiroshi Miyazaki, miyazaki.hir-02@jp.fujitsu.com RHD02651@nifty.ne.jp)
Nature: Uncategorized Issue
Severity:
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."

Resolution:
Revised Text: Revised text: In 7.2.1, the sentence "OCL expressions are written using ASCII characters only" changed to "OCL expressions in this document are written using ASCII characters only".
Actions taken:
November 9, 2001: received issue
December 2, 2004: Transferred to OCL 2.0 FTF
November 1, 2005: closed issue

Discussion:

Resolution:
This is an OCL 1 issue transferred to the OCL 2 FTF.
The first interpretation is the right one. Adding "In this document " solves the ambiguity.

Issue 4692: 6.8.1.9 String on page 6-34 (ocl2-ftf)

Click here for this issue's archive.
Source: Fujitsu (Mr. Hiroshi Miyazaki, miyazaki.hir-02@jp.fujitsu.com RHD02651@nifty.ne.jp)
Nature: Uncategorized Issue
Severity:
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.

Resolution:
Revised Text: No text change needed.
Actions taken:
November 9, 2001: received issue
December 2, 2004: Transferred to OCL 2.0 FTF
November 1, 2005: closed issue

Discussion:

Resolution:
This is an OCL 1 issue transferred to the OCL 2 FTF.
Already resolved in OCL2: In 11.4.3 it is written: "The standard type String represents strings,
which can be both ASCII or Unicode."

Issue 4693: EBNF of the String on page6-48. (ocl2-ftf)

Click here for this issue's archive.
Source: Fujitsu (Mr. Hiroshi Miyazaki, miyazaki.hir-02@jp.fujitsu.com RHD02651@nifty.ne.jp)
Nature: Uncategorized Issue
Severity:
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.

Resolution:
Revised Text: Closed, no change
Actions taken:
November 9, 2001: received issue
December 2, 2004: Transferred to OCL 2.0 FTF
November 1, 2005: closed issue

Discussion:

This is an OCL 1 issue transferred to the OCL 2 FTF.
Obsolete issue. Refers to the old version (UML 1.4), not relevant to the OCL2 submission.

Issue 4694: inhibtedChar on page6-48, (ocl2-ftf)

Click here for this issue's archive.
Source: Fujitsu (Mr. Hiroshi Miyazaki, miyazaki.hir-02@jp.fujitsu.com RHD02651@nifty.ne.jp)
Nature: Uncategorized Issue
Severity:
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    := " " | "\"" | "#" | "\'" | "(" | ")" |
                    "*" | "+" | "," | "-" | "." | "/" |
                    ":" | ";" | "<" | "=" | ">" | "@" |
                    "[" | "\\" | "]" | "{" | "|" | "}"

Resolution:
Revised Text:
Actions taken:
November 9, 2001: received issue
December 2, 2004: Transferred to OCL 2.0 FTF
November 1, 2005: closed issue

Discussion:

This is an OCL 1 issue transferred to the OCL 2 FTF.
Obsolete issue. Refers to the old version (UML 1.4), not relevant to the OCL2 submission.

Issue 5581: Section 6.6.2 (ocl2-ftf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Section 6.6.2 

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

Resolution:
Revised Text:
Actions taken:
August 20, 2002: received issue
December 2, 2004: Transferred to OCL 2.0 FTF
November 1, 2005: closed issue

Discussion:

This is an OCL 1 issue transferred to the OCL 2 FTF.
Obsolete issue. Refers to the old version (UML 1.4), not relevant to the OCL2 submission.

Issue 5582: Section 6.6.7 (ocl2-ftf)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
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".

Resolution:
Revised Text:
Actions taken:
August 20, 2002: received issue
December 2, 2004: Transferred to OCL 2.0 FTF
November 1, 2005: closed issue

Discussion:

This is an OCL 1 issue transferred to the OCL 2 FTF.
Obsolete issue. Refers to the old version (UML 1.4), not relevant to the OCL2 submission.

Issue 5970: OCL 2: flatten (ocl2-ftf)

Click here for this issue's archive.
Source: Kestral Computing (Mr. Grahame Grieve, grahameg@gmail.com)
Nature: Uncategorized Issue
Severity:
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?

Resolution:
Revised Text:
Actions taken:
April 22, 2003: received issue

Discussion:

Deferred for timing reasons

Issue 5971: OCL 2: OrderedSet (ocl2-ftf)

Click here for this issue's archive.
Source: Kestral Computing (Mr. Grahame Grieve, grahameg@gmail.com)
Nature: Uncategorized Issue
Severity:
Summary:

OrderedSet isn't discussed in the section on semantics

Resolution:
Revised Text:
Actions taken:
April 22, 2003: received issue

Discussion:

Deferred for timing reasons

Issue 5972: OCL 2: Can collections contain void/undefined objects (ocl2-ftf)

Click here for this issue's archive.
Source: Kestral Computing (Mr. Grahame Grieve, grahameg@gmail.com)
Nature: Uncategorized Issue
Severity:
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.

Resolution:
Revised Text: Revised Text: 1) In section 8.2.2 (Well formedness Rules for the Types Package) add the following constraint:[2] A Collection cannot contain OclInvalid values. context Collection inv: self->forAll(not oclIsInvalid()) 2) In section 8.2 adds a description for the class InvalidType, with the following text: InvalidType represents a type that conforms to all types. The only instance of InvalidType is Invalid, which is further defined in the standard library. Furthermore Invalid has exactly one instance called OclInvalid. Also update figure 5 adding the InvalidType metaclass in the type inheritance: VoidType DataType Class TupleType SetTypOrderedSetType SequenceType BagType e Type CollectionType 1 * +elementType PrimitiveType InvalidType AnyType Operation Signal MessageType 0..1 * +referredOperation 0..1 * +referredSignal TypeType ElementType 3) In section 8.2.1 (Type Conformance), add the compliance rule for InvalidType with the following text: InvalidType Invalid conforms to all other types [1] context InvalidType inv: Classifier.allInstances()->forAll (c | self.conformsTo (c)) 4) In section 8.3, within the description of VoidType, replace the last sentence by: Furthermore OclVoid has exactly one instance called null - corresponding to the UML NullLiteral literal specification - and representing the absence of value. Note that in contrast with OclInvalid null is a valid value and as such can be owned by collections. 5) Change the title of section 11.2 as follows: """ The OclAny, OclVoid, OclInvalid and OclMessage types."""6) In section 11.2.3 replace "It has a single instance called OclUndefined �" by "It has a single instance called null which corresponds with the UML NullLiteral specification value." Also replace "Any propertycall applied on OclUndefined �" by "Any propertycall applied on null results in OclInvalid". And finally replace: "an instance of the metatype Classifier" by "an instance of the metatype VoidType". 7) In section 11.2 add OclInvalid description with the following text: OclInvalid The type OclInvalid is a type that conforms to all other types. It has one single instance called invalid. Any propertycall applied on invalid results in OclInvalid, except for the operations oclIsUndefined() and oclIsInvalid(). OclInvalid is itself an instance of the metatype InvalidType 8) In section 11.2.4, change the definition of oclIsUndefined() as follows: Evaluates to true if the self is equal to OclInvalid or to null. post: result = self.isTypeOf( OclVoid) or self.isTypeOf( OclInvalid ). 9) In section 11.2.4, add the definition of iclIsInvalid() as follows: Evaluates to true if the self is equal to OclInvalid. post: result = self.isTypeOf( OclInvalid). 10) Remove 11.2.5 section (definition of OclVoid::oclIsUndefined and badly placed constraint ) � since this method is already defined for AnyType. 11) Add in figure 10 (Abstract syntax metamodel for Literal expression) the metaclasses NullLiteralExp and InvalidLiteralExp. IntegerLiteralExp integerSymbol : Integer RealLiteralExp realSymbol : Real BooleanLiteralExp booleanSymbol : Boolean StringLiteralExp stringSymbol : String UnlimitedNaturalExp symbol : UnlimitedNatural LiteralExp EnumerationLiteral EnumLiteralExp 0..1 * +referredEnumLiteral +literalExp PrimitiveLiteralExp NumericLiteralExp NullLiteralExp InvalidLiteralExp Actions taken: April 22, 2003: received issue Disposition: Resolved Document ptc/2005-06-05 Page 24
Actions taken:
April 22, 2003: received issue
November 1, 2005: closed issue

Discussion:

Resolution:
The notion of OclUndefined is splitted into two notions: LiteralNull and OclInvalid to
distinguish between the situations where we have an absence of value (LiteralNull) and
an invalid events (such as division of zero). Collection can contain null values but cannot
contain Oclinvalid values.
Apart from making more flexible the usage of OCL as a query language, this resolution
aligns OCL with UML2 in which the "absence of value" is already modeled by the notion
of null literal which is not considered being an invalid value.

Issue 5973: OCL 2: what is a collection? (ocl2-ftf)

Click here for this issue's archive.
Source: Kestral Computing (Mr. Grahame Grieve, grahameg@gmail.com)
Nature: Uncategorized Issue
Severity:
Summary:

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


This question arises in 2 different ways:
- can you sub-class one of the concrete descendents in
  a UML diagram - by referring to the OCL package - and thereby
  add functionality to your own collection types


- are all parameterised classifiers collections? if you
  define a parameterised class, how does an OCL user or
  environment know whether it's a collection or not?


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

Resolution:
Revised Text:
Actions taken:
April 22, 2003: received issue

Discussion:

Deferred for timing reasons

Issue 5974: OCL 2: String operations (ocl2-ftf)

Click here for this issue's archive.
Source: Kestral Computing (Mr. Grahame Grieve, grahameg@gmail.com)
Nature: Uncategorized Issue
Severity:
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

Resolution:
Revised Text:
Actions taken:
April 22, 2003: received issue

Discussion:

Deferred for timing reasons

Issue 6012: OCL/MOF/UML alignment (ocl2-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
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.

Resolution:
Revised Text: The revised text is given for each chapter. Chapter 8 (Abstract Syntax) *********************** 0) In 8.2, in the introductory text, removes the "with the annotation (from <UML package>) and shown with". 1) In 8.2, replaces "� from the UML Infrastructure" by "�from the UML Superstructure". 2) In 8.2.1 (Type conformance), within the well-formedness rules of Classifier, replaces 'generalization.parent' by 'generalization.general'. 3) In all the text replace 'Primitive' as 'PrimitiveType', 'PropertyCall' by ''CallExp', 'ModelPropertyCallExp' by 'FeatureCallExp', 'AssociationEndCallExp' by 'PropertyExp', remove AttributeCallExp. Update figure 6 and figure 7 to take into account these changes: TypedElement Classifier TypeExp 0..1 * +referredType FeaturePropertyCall LiteralExp IfExp MessageExp IteratorExp VariableExp ParameterFeaturePropertyCall OperatioOperationCallExp n 0..1 * +referredOperation +referringExp OclExpression * 0..1 +argument {ordered} +parentCall PropertyCallExp Property * 0..1 +referredProperty +re*ferringExp NavigationCallExp * 0..1 +qualifier {o*rdered} +parentNav 0..1 * +navigationSource 4) In the well-formedness rules of TupleType, replace 'allAttributes' by 'allProperties'. 5) In 8.3.8, in Classifier subtitle, after the definition of lookupSignal add the following text: """ def: allReceptions() : Set(Reception) = self.allFeatures()->select(f | f.oclIsKindOf(Reception)) def: allProperties() : Set(Property) = self.allFeatures()->select(f | f.oclIsKindOf(Property)) def: allOperations() : Set(Property) = self.allFeatures()->select(f | f.oclIsKindOf(Operations)) The operation allFeatures() is defined in the UML semantics. """ 6) In 8.3.8, in Classifier subtitle, remove the paragraph starting with "Operations allAttributes � " and ending with "�inherited Attributes". Also remove the OCL code of allReceptions after the removed paragraph (since added in step 5 above). 7) Replace the existing chapter 13 by the new content below. The title of the chapter is Basic OCL and Essential OCL. 13 Basic OCL and Essential OCL 13.1. Introduction: BasicOCL is the package exposing the minimal OCL required to work with Core::Basic. Basic OCL depends on the Core::Basic Package. It references explicitly the following Core::Basic classes: Property, Operation, Parameter, TypedElement, Type, Class, DataType, Enumeration, PrimitiveType and EnumerationLiteral. EssentialOCL is the package exposing the minimal OCL required to work with EMOF. EssentialOcl depends on the EMOF Package. It references explicitly the EMOF classes:Property, Operation, Parameter, TypedElement, Type, Class, DataType, Enumeration, PrimitiveType and EnumerationLiteral. EssentialOCL is build from Core::Basic and BasicOcl using package merge with copy semantics � similarily as EMOF is build from Core::Basic. Structurally there is no difference between BasicOCL and EssentialOCL. For this reason we provide in this chapter a unique set of diagrams which defines the abstract syntax for both packages. For convenience, because BasicOCL (respectively EssentialOCL) is - conceptually � a subset of the complete OCL language for UML superstructure, we will not repeat or redefine here all the class descriptions and the well-formedness rules defined in the other chapters. When applicable, all these definitions are to be re-interpreted in the specific context of Core::Basic (respectively EMOF). The section "OCL adaptation for metamodelling" specific rules for the re-interpretation of the "complete" OCL, whereas the "Diagrams" section provides the complete diagrams defining the BasicOCL (respectively EssentialOCL) abstract syntax. 13.2. OCL adaptation for metamodelling We provide below a set of rules and conventions that are applied to define BasicOCL (and consequently EssentialOCL) from the OCL defined for UML superstructure � called "complete OCL" in this section. 1) The following metaclasses defined in complete OCL are not part of BasicOCL (and EssentialOCL): - MessageType - ElementType - AssociationClassCallExp - MessageExp - StateExp - UnspecifiedValueExp Any well-formedness rules defined for these classes are consequently not part of the definition of Basic OCL. The properties NavigationCallExp::qualifier and NavigationCallExp::navigationSource are suppressed since not needed in this context. 2) Core::Basic does not contain the intermediate notion of Classifier but uses instead directly the Type notion as the base class for the type system. Consequently, any reference to the Classifier class in the complete OCL specification has to be re-interpreted as a reference to the Type class. Note: It is expected that further revisions of this specification will provide explicily the complete set of well-formedness rules and additional operations that apply to Core::Basic � to replace the lazy re-interpretation statement we are using here.3) In complete OCL, TupleType has DataType as base type. In BasicOCL Tuple has also Class as base type so that the attributes of the tuple can be defined in the same way as in complete OCL � as Property instances. 4) In complete OCL, pre-defined types have pre-defined operations defined in the standard library. However, a DataType in Core::Basic cannot define such operations since it inherits from Type (and not from Class). For all data types and special types � like VoidType, InvalidType and AnyType � the following convention is used: in the standard library the instance representing the pre-defined type is accompanied with a class instance with the same name that holds the operations. An access to an operation of the predefined type implies an access to the operation of the complementary class instance. 13.3. Diagrams The diagrams below define completely the abstract syntax of BasicOCL (respectively EssentialOCL). The classes that are not imported from Core::Basic (respectively EMOF) are shown with a transparent fill color. VoidType DataType Class TupleType SetTypOrderedSetType SequenceType BagType e Type CollectionType PrimitiveType InvalidType TypeType AnyType +elementType 1 * Figure 34 : TypesTypedElement Figure 35 : The top container expression TypedElement Type TypeExp FeaturePropertyCall LiteralExp IfExp IteratorExp VariableExp Parameter IterateExp CallExp LoopExp OclExpression Variable +referredType 0..1 * +referringExp * +representedParameter 0..1 +baseExp 0..1 +appliedElement 0..1 +loopExp 0..1 +loopBodyOwner 0..1 +source 0..1 +body 1 +initExpression 0..1 +referredVariable 0..1 +variable * +iterator * +result 0..1 0..1+initializedElement 1 Figure 16 : main expression conceptsFeaturePropertyCall Operation OperationCallExp OclExpression PropertyCallExp Property NavigationCallExp +referredOperation 0..1 +referringExp * +parentCall 0..1 +argument {ordered} * +re*ferringExp +referredProperty * 0..1 Figure 37: Feature Property Call expressions OclExpression IfExp 1 0..1 +condition +ifOwner 1 0..1 +thenExpression +thenOwner 1 0..1 +elseExpression +elseOwner Figure 2 : If Expressions LetExp OclExpression 0..1 +in Variable 0..1 1 +variable 0..1 0..1 +initExpression +initializedElement Figure 38: Let expressionsLiteralExp EnumerationLiteral EnumLiteralExp 0..1 * +referredEnumLiteral +literalExp PrimitiveLiteralExp NumericLiteralExp NullLiteralExp InvalidLiteralExp Figure 39 : Literals CollectionLiteralPart CollectionLiteralExp kind : CollectionKind * 1 +part CollectionRange OclExpression 1 0..1 +first +firstOwner 1 0..1 +last +lastOwner CollectionItem 1 0..1 +item LiteralExp CollectionKind Set OrderedSet Bag Sequence <<enumeration>> TypedElement TupleLiteralExp Property TupleLiteralPart * 0..1 +part 0..1 0..1 +attribute Figure 40 : Collection and tuple literals Document ptc/2005-06-05 Page 34
Actions taken:
July 22, 2003: received issue
November 1, 2005: closed issue

Discussion:

Resolution:
The approach taken to solve the alignment problem is as follows:
- Chapters 7 to chapters 12 define the OCL for the UML superstructure language. The
OCL metamodel specification, notation and semantics is updated when needed to reflect
the changes made in the last version of the UML2 superstructure specification.
- Chapters 13 define the OCL that is required for metamodelling. More precisely, chapter
13 defines firstly the BasicOCL package extending the UML Core::Basic package to
allow the integration of OCL in languages that are built on the basis of the Infrastructure
Library. The chapter also defines the EssentialOCL package extending EMOF for OCL
integration. Conceptually, EssentialOCL is build from from BasicOCL using the same
principles used to define the EMOF package from the Core::Basic library package.
Structurally there is no difference between BasicOCL and EssentialOCL. Also, because
no new concept is introduced by BasicOCL and EssentialOCL the class descriptions are
not repeated, only the diagrams are showed.

Issue 6393: OCL 2.0/international character sets (ocl2-ftf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Bran Selic, selic@acm.org selicb@ca.ibm.com bran.selic@gmail.com)
Nature: Uncategorized Issue
Severity:
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.

Resolution:
Revised Text:
Actions taken:
October 30, 2003: received issue
November 1, 2005: closed issue

Discussion:

Resolution:
Already resolved in the OCL2 document. "Ascii or unicode" is used instead of "ascii" alone.

Issue 6528: Provide access to the sender of a message (ocl2-ftf)

Click here for this issue's archive.
Source: Ecole Polytechnique Federale de Lausanne (Mr. Alfred Strohmeier, )
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
November 10, 2003: received issue

Discussion:

Discussion:
Asking for an improvement of the language. Better solved in a RTF

Issue 6529: oclIsNew for a collection (ocl2-ftf)

Click here for this issue's archive.
Source: Ecole Polytechnique Federale de Lausanne (Mr. Alfred Strohmeier, )
Nature: Uncategorized Issue
Severity:
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())...

Resolution:
Revised Text:
Actions taken:
November 10, 2003: received issue

Discussion:

Discussion:
Asking for an improvement of the language. Better solved in a RTF

Issue 6530: status of objects and tuples (ocl2-ftf)

Click here for this issue's archive.
Source: Ecole Polytechnique Federale de Lausanne (Mr. Alfred Strohmeier, )
Nature: Uncategorized Issue
Severity:
Summary:

Description: Provide a notation for the status of an object
Rationale:
It would be convenient to have a notation for denoting the status of an object. The type of such a status is a tuple. With such a notation it would be possible to compare the status of two objects or to compare the status of an object with a tuple. If not available, comparisons have to be performed on an attribute by attribute basis. Consider e.g.
  p, p1 and p2 are Person(s)
  p1.all = p2.all  -- the 2 persons have same status, i.e.
  is nicer and less error-prone than comparing all attributes:
  p1.firstName = p2.firstName and p1.name = p2.name and ...
It would also be possible to compare with a tuple:
  p.all = Tuple = Tuple {firstName = 'Alfred', name = 'Strohmeier', ...}

Resolution:
Revised Text:
Actions taken:
November 10, 2003: received issue

Discussion:

Discussion:
Asking for an improvement of the language. Better solved in a RTF

Issue 6531: Omit predefined type OclModelElement. (ocl2-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
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.

Resolution:
Revised Text: Revised Text: 1) In section 8.2 remove the obsolete sentences: "In comparison with UML 1.4 �" and "This means that a Classifier�". 2) In all the document replace OclModelElementType by ElementType. 3) Add the TypeType metaclass and ElementType in the types diagram (Figure 5) +elementType PrimitiveType InvalidType AnyType Operation Signal MessageType 0..1 * +referredOperation 0..1 * +referredSignal TypeType ElementType 4) Add the following description for the TypeType metaclass: """A TypeType is used to represent the type of the formal parameter of specific operations that need to refer to the types at the meta-level, like the oclIsKindOf, oclIsTypeOf and oclAsType pre-defined operations. It has a unique instance named 'OclType' which complies to any type defined in the model (at the meta level). """ 6) In section 8.2, replace the description of the OclModelElementType metaclass (now renamed ElementType) with the following text: A ElementType is used to represent the type of the formal parameter of specific operations that need to refer to elements of the model such as the UML states in the predefined oclInState operation. 7) In all 11.2.4 paragraph, replace all occurrences of 'typename' by 'typespec', "statename" by "statespec" and remove all sentences "Typename may be in the format Package::subPackage::classifier" and "statename may be in the format Class::State::subState". 8) Rename title 11.3 as "Special types". Changes the sentence "This section defines �" by "This section defines several special types that are used to formalize the signature of pre-defined operations that manipulate types and elements defined in the UML model". Rename OclModelElement as OclElement and change its description with "The singleton instance of ElementType". Change the description of OclType with "The singleton instance of TypeType". Remove the OclState description.
Actions taken:
November 10, 2003: received issue
November 1, 2005: closed issue

Discussion:

This issue has been merged with issue 6610 (Enumeration approach for reflection) which
suggest dropping the enumeration approach for reflection because of multiple
implementation problems it causes. Usage of enumeration for reflection is now avoided
thanks to the introduction of TypeExp and StateExp.
The metaclass TypeType is now used to represent the type accepted by the oclIsKindOf,
oclIsTypeOf and oclAsType operations. The TypeType has a unique instance named
'OclType' , but it is anymore a enumeration but a type compliant with any type defined in
the model (metalevel).
In a similar way, the OclModelElementType � renamed ElementType � to better match
UML2 terminology (since Element replaces ModelElement as the base element in the
class hierarchy) � is retained to allow encoding explicitly the type of the parameter in the
oclInState pre-defined operation. This ElementType type has a singleton instance in the
standard library called OclElement (which is not an enumeration).
Since a usage of oclIsKindOf (resp. oclInState) is encoded as an operations call, the
arguments need to be OclExpressions: that's why the meta types are passed using
TypeExp (resp. StateExp).

Issue 6532: Consider OclType as a powertype (ocl2-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
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?).

Resolution:
Revised Text:
Actions taken:
November 10, 2003: received issue

Discussion:

Usage of powertypes as an alternative way to represent generically Ocl types is an
interesting suggestion. However, for timing reasons we prefer defer this issue to the RTF.

Issue 6533: Template return types in operation signatures (ocl2-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
November 10, 2003: received issue

Discussion:

Deferred for timing reasons

Issue 6534: Up- and Down-casts with oclAsType(). (ocl2-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
November 10, 2003: received issue

Discussion:

Deferred for timing reasons

Issue 6535: Lack of operation specifications (ocl2-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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

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

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

Resolution:
Revised Text:
Actions taken:
November 10, 2003: received issue

Discussion:

Deferred for timing reasons

Issue 6536: Additional annotations in the OCL Standard Library (ocl2-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
November 10, 2003: received issue

Discussion:

Deferred for timing reasons

Issue 6537: domain for library operations /, div (ocl2-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
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 / ?

Resolution:
Revised Text: 1) Change the description of : / (r : Real) : Real, replacing "The value of self divided by r." by " The value of self divided by r". Evaluates to OclUndefined if r is equal to zero. 2) Change the description of : / (i : Integer) : Real replacing "The value of self divided by i." by " The value of self divided by i". Evaluates to OclUndefined if i is equal to zero
Actions taken:
November 10, 2003: received issue
November 1, 2005: closed issue

Discussion:

Adding: Evaluates to OclUndefined if r(resp i) is equal to zero.

Issue 6538: Exception of strict evaluation (implies) (ocl2-ftf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Author: Thomas Baar (thomas.baar@epfl.ch)
Description: Exception from strict evaluation for IMPLIES is incomplete and contradicts set-theoretical semantics
Rationale: On page 2-10 only one exception from strict evaluation for IMPLIES  is given:
False IMPLIES x == True
However, based on the official semantics of IMPLIES given on page A-12
also x IMPLIES True == True

Resolution:
Revised Text:
Actions taken:
November 10, 2003: received issue

Discussion:

Deferred for timing reasons

Issues for OCL 2.0 Finalization Task Force

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Issue 1790: Lack of features commonly used in OCL (ocl2-ftf)

Issue 3392: OCL needs an abstract syntax, just like the UML metamode (ocl2-ftf)

Issue 3513: OCL: Usage of qualifiers (ocl2-ftf)

Issue 3800: postcondition for the operation round on the predefined OCL type (ocl2-ftf)

Issue 3855: context declaration for OCL invariants (ocl2-ftf)

Issue 4112: OCL: Created and Destroyed instances (ocl2-ftf)

Issue 4121: In 6.9 "Grammar for OCL" (Internationalization issues) (ocl2-ftf)

Issue 4451: Downcast OCL collection operators (ocl2-ftf)

Issue 4691: 1. 6.2.1 "legend" on page 6-3, Internationalization issue (ocl2-ftf)

Issue 4692: 6.8.1.9 String on page 6-34 (ocl2-ftf)

Issue 4693: EBNF of the String on page6-48. (ocl2-ftf)

Issue 4694: inhibtedChar on page6-48, (ocl2-ftf)

Issue 5581: Section 6.6.2 (ocl2-ftf)

Issue 5582: Section 6.6.7 (ocl2-ftf)

Issue 5970: OCL 2: flatten (ocl2-ftf)

Issue 5971: OCL 2: OrderedSet (ocl2-ftf)

Issue 5972: OCL 2: Can collections contain void/undefined objects (ocl2-ftf)

Issue 5973: OCL 2: what is a collection? (ocl2-ftf)

Issue 5974: OCL 2: String operations (ocl2-ftf)

Issue 6012: OCL/MOF/UML alignment (ocl2-ftf)

Issue 6393: OCL 2.0/international character sets (ocl2-ftf)

Issue 6528: Provide access to the sender of a message (ocl2-ftf)

Issue 6529: oclIsNew for a collection (ocl2-ftf)

Issue 6530: status of objects and tuples (ocl2-ftf)

Issue 6531: Omit predefined type OclModelElement. (ocl2-ftf)

Issue 6532: Consider OclType as a powertype (ocl2-ftf)

Issue 6533: Template return types in operation signatures (ocl2-ftf)

Issue 6534: Up- and Down-casts with oclAsType(). (ocl2-ftf)

Issue 6535: Lack of operation specifications (ocl2-ftf)

Issue 6536: Additional annotations in the OCL Standard Library (ocl2-ftf)

Issue 6537: domain for library operations /, div (ocl2-ftf)

Issue 6538: Exception of strict evaluation (implies) (ocl2-ftf)

Issue 6539: Exception of strict evaluation (forAll, exists)