Issues for OCL 2.4 Revision Task Force mailing list

To comment on any of these issues, send email to ocl2-rtf@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-rtf)

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 3513: OCL: Usage of qualifiers (ocl2-rtf)

Click here for this issue's archive.
Source: OpenModeling (Mr. Jos Warmer, jos.warmer(at)openmodeling.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 5971: OCL 2: OrderedSet (ocl2-rtf)

Click here for this issue's archive.
Source: HL7 (Mr. Grahame Grieve, grahame(at)healthintersections.com.au)
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 5973: OCL 2: what is a collection? (ocl2-rtf)

Click here for this issue's archive.
Source: HL7 (Mr. Grahame Grieve, grahame(at)healthintersections.com.au)
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 6528: Provide access to the sender of a message (ocl2-rtf)

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 6530: status of objects and tuples (ocl2-rtf)

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 6533: Template return types in operation signatures (ocl2-rtf)

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-rtf)

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-rtf)

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-rtf)

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 6538: Exception of strict evaluation (implies) (ocl2-rtf)

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

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

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

Author: Thomas Baar (thomas.baar@epfl.ch)
Description: Exception of strict evaluation should be extended to forAll, exists 
Rationale: Suppose r(o1) = undef, r(o2) = false What is value of Exp =  {o1, o2}->forAll(x| r(x)) ?  One could argue, because of strict evaluation, the value of Exp is undef.  However, this would contradict the semantics of forAll als 'iterated and' given on page A.28.   Similarily, for exists. 
A note should be added on page 2-10 on evalution of expressions based on iterate.

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

Discussion:

Deferred for timing reasons

Issue 6540: Exception of strict evaluation (queries) (ocl2-rtf)

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

Author: Thomas Baar (thomas.baar@epfl.ch)
Description: Strict evaluation for queries yields to contradictions in specifications
Rationale: Queries can be specified in two ways, as invariants and in form of pre/post conditions. Suppose we specify query q(arg) as 
post:  if (arg.oclIsUndefined()) then result = true else result = false endfi
Having this, the following invariant should evaluate always to true:
self.q(arg) = true or self.q(arg) = false.
However, the invariant evaluates to undef once arg evaluates to undef thanks to strict evaluation.
There is a misconception of strict evaluation when it comes to queries.  The idea of queries is to have user-defined functions on classes. Why should the user be restricted only to such function which return undef once one of its arguments is undef? Using OCL, the user can even specify queries which can handle undefined arguments (e.g. see post specification of q(arg) ). Obviously, the post specification for q(arg) makes sense.
The rule of strict evaluations for queries should be weakened to the case where the owner of the query (the object upon the query was called) is undefined.

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

Discussion:

Deferred for timing reasons

Issue 6541: Exception of strict evaluation (=) (ocl2-rtf)

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

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

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

Discussion:

Deferred for timing reasons

Issue 6547: Incomplete and missing well-formedness rules (ocl2-rtf)

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

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

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

Discussion:

Deferred for timing reasons

Issue 6548: Satisfaction of Operation Specifications (ocl2-rtf)

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

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

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

Discussion:

Deferred for timing reasons

Issue 6549: Satisfaction of Operation Specifications (2) (ocl2-rtf)

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

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

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

Discussion:

Deferred for timing reasons

Issue 6550: Satisfaction of Operation Specifications (3) (ocl2-rtf)

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

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

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

Discussion:

Deferred for timing reasons

Issue 6551: Add select/reject/collectNested to Collection (ocl2-rtf)

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

Author: Hubert Baumeister (baumeist@informatik.uni-muenchen.de),
Rolf Hennicker (hennicke@informatik.uni-muenchen.de),
Alexander Knapp (knapp@informatik.uni-muenchen.de)
Description: Add select/reject/collectNested to Collection
Rationale:
The definition of any on Collection (page 6-16f.) uses select on Collection. However, select is not defined for Collection. Similarly, the definition of collect on Collection (page 6-17) uses collectNested on Collection, which is not defined on Collection. We therefore propose to add select and collectNested (and possibly reject) to Collection.

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

Discussion:

Deferred for timing reasons

Issue 6553: Clarify the semantics of forAll (ocl2-rtf)

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

Author: Hubert Baumeister (baumeist@informatik.uni-muenchen.de),
Rolf Hennicker (hennicke@informatik.uni-muenchen.de),
Alexander Knapp (knapp@informatik.uni-muenchen.de)
Description: Clarify the semantics of forAll
Rationale:
According to the informal explanation (page 6-16) the following Expression Set { 1 }->forAll(x | x/0 < 0) would evaluate to false. However, according to the OCL definition it evaluates to undefined. Thus we propose to omit "otherwise, result is false" in the informal explanation.

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

Discussion:

Deferred for timing reasons

Issue 6554: Clarify the UML semantics of IfExpEval (ocl2-rtf)

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

Author: Hubert Baumeister (baumeist@informatik.uni-muenchen.de),
Rolf Hennicker (hennicke@informatik.uni-muenchen.de),
Alexander Knapp (knapp@informatik.uni-muenchen.de)
Description: Clarify the UML semantics of IfExpEval
Rationale:
The specification on page 5-21 of the evaluation of if_then_else omits the case when the condition evaluates to undefined. Thus the sentence should read:
"The result value of an if expression is the result of the thenExpression if the condition is true, it is the result of the elseExpression if the condition is false, else it is undefined."

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

Discussion:

Deferred for timing reasons

Issue 6557: Introduce a "tuplejoin" operator (ocl2-rtf)

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

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

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

Discussion:

This is a request to improve the language. Should better be solved in a RTF.

Issue 6559: Issue: Virtual machine (ocl2-rtf)

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

Description: The OCL 2.0 specification should be behaviour-oriented and not implementation-oriented (see section 4.3). 
Rationale: The idea of using OCL to describe itself is interesting from the research point of view, but unfortunately OCL is not a suitable metalanguage to define the meaning of other textual languages. I think that the best thing to do is to define a virtual machine and to describe the behaviour of the virtual machine using natural language. This technique was successfully used for languages like C, C++, Java, C#, and Prolog. I see no reasons why such a technique would fail for OCL. After all, OCL is less complex than modern programming language like C++, Java, or C#.
A proper description and implementation of the OCL virtual machine will create all the conditions to have a language that is platform/tool independent.

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

Discussion:

This is a request to improve language definition. Should better be solved in a RTF.

Issue 6561: Issue: Unspecified syntax and semantics for Integer, Real, and String (ocl2-rtf)

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

Description: The specification does not describes the syntax of integer, real or string literals. Also, it does not contain the description of the allowed set of values. 
Rationale: Specifying the syntax and the semantics of basic types will increase the portability of OCL programs. In order to describe the semantics of basic types, the specification should describe the set of values, the allowed operations, and the standard used to perform the allowed operations. I think that it will be also useful to allow different types of integers and reals, like Integer(16), Integer(32), Integer(64), Real(32), and Real(64), in order to optimize the computational process.

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

Discussion:

This is a request to improve language definition and extend its expresiveness. Should better be
solved in a RTF.

Issue 6563: Issue: Comments (ocl2-rtf)

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

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

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

Discussion:

Deferred for timing reasons

Issue 6565: Issue: Grammar of OCL (ocl2-rtf)

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

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

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

Discussion:

Decision deferred to an RTF. It would imply a lot of changes.

Issue 6566: Issue: Abstract syntax tree (ocl2-rtf)

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

Description: Some of the elements presented in 3.3.10 (e.g. EnumLiteralExp, children of ModelPropertyCallExp) cannot be constructed without using semantic information (e.g. the type of the expression determines if a name denotes an attribute, an association end, or an operation). 
Rationale: Usually a parser produces an AST. The semantic analyser augments the AST by computing for each node from AST the values of the attached attributes. The semantic analysis also checks if there are static semantics errors and reports them. Using other terms in the AST and hence other non-terminals in 4.5 (e.g. dot-selection-expression, arrow-selection-expression, call-expression etc.) will solve this problem.

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

Discussion:

Decision deferred to an RTF. It would imply a lot of changes.

Issue 6571: Issue: Syntax of Operation Call, Iterator, and Iterate Expressions (ocl2-rtf)

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

Description: Syntax for the above constructions is extremely ambiguous and it might involve backtracking. 
Rationale: According to OCL specification
 * self.f(x, y)
 * Set{1,2,3}->select(x, y| x+y = 3)
 * Set{1,2,3,4,5,6}->iterate(x; acc:Integer=0 | acc + x) 
describe an operation call, an iterator, and an iterate expression.
In order to make the distinction between an iterator call and an operation call we need in this case a three token lookahead, starting from x. The problem gets even more complicated if we consider that an argument for an operation call can be an expression.
In order to solve this problem, which is a potential source of problems for the implementation (error-prone, inefficiency aso), we think that these OCL constructs should contain some extra syntax markers. There are several choices:
* change the comma marker from iterator calls to something else, maybe a semicolon
* add a syntax marker to an iterator name
* do not allow the default types 
The above choices will allow to a deterministic parser to deal with the enumerated problems more efficiently. I do not agree with textual language in which variables are given a default type according to the context in which they are used, especially if these languages are design for industrial use. The same problems were in previous versions of C standard, which allowed implicit type int for variables in constructions like
      x;
Now, the latest C standard states that variables with default type are not allowed.

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

Discussion:

Deferred for timing reasons

Issue 6572: Issue: Parsing Tuple Types and Collection Types as Arguments (ocl2-rtf)

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

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

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

Discussion:

This issue asks for an improvement of the language. Should better be solved in a RTF.

Issue 6573: Issue: OclAny operations of tuples and collections (ocl2-rtf)

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

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

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

Discussion:

This issue asks for an improvement of the language. Should better be solved in a RTF.

Issue 6574: Issue: Signature of Environment (ocl2-rtf)

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

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

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

Discussion:

Deferred for timing reasons

Issue 6600: The index seems incomplete (ocl2-rtf)

Click here for this issue's archive.
Source: Modeling Value Group (Mr. Wim Bast, wim.bast(at)modelingvalue.nl)
Nature: Uncategorized Issue
Severity:
Summary:

The index seems incomplete and leaves out interesting items (e.g., the definition of standard library functions).

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

Discussion:

Deferred for timing reasons

Issue 6601: compliance points strategies (ocl2-rtf)

Click here for this issue's archive.
Source: Modeling Value Group (Mr. Wim Bast, wim.bast(at)modelingvalue.nl)
Nature: Uncategorized Issue
Severity:
Summary:

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

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

Discussion:

Deferred for timing reasons

Issue 6609: OclUndefined / allInstances() clarification. (ocl2-rtf)

Click here for this issue's archive.
Source: Modeling Value Group (Mr. Wim Bast, wim.bast(at)modelingvalue.nl)
Nature: Uncategorized Issue
Severity:
Summary:

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

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

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

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

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

Discussion:

Deferred for timing reasons

Issue 6614: Example with TupleType (ocl2-rtf)

Click here for this issue's archive.
Source: Modeling Value Group (Mr. Wim Bast, wim.bast(at)modelingvalue.nl)
Nature: Enhancement
Severity: Minor
Summary:

Typo in an example with TupleType Section 7.5.15: In the example constraint, expression attr: Statistics : Set(TupleType(& This must be Tuple only, according to the concrete syntax.

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

Discussion:

Deferred for timing reasons

Issue 6879: The notation for testing the type of a metaclass is too verbose (ocl2-rtf)

Click here for this issue's archive.
Source: France Telecom R&D (Mr. Mariano Belaunde, mariano.belaunde(at)orange.com)
Nature: Uncategorized Issue
Severity:
Summary:

Suggestion: Use special characters to denote a call to oclIsKindOf and oclIsTypeOf. 
  For instance, use '#ActionState' instead of 'oclIsKindOf(ActionState)' 
  and use '##ActionState' instead of 'oclIsTypeOf(ActionState)'

Resolution:
Revised Text:
Actions taken:
January 7, 2004: received issue

Discussion:

This is a request to improve the language. Better solved in a RTF.

Issue 6880: The notation for selecting elements should be more intuitive (ocl2-rtf)

Click here for this issue's archive.
Source: France Telecom R&D (Mr. Mariano Belaunde, mariano.belaunde(at)orange.com)
Nature: Uncategorized Issue
Severity:
Summary:

Suggestion: Use brackets as an alternate option to denote a call to the "select" 
    function. Notation: mylist[iterator | condition] 
    Example: 
        self.ownedElement[#Class and name="MyClass"]  
               -- #Class is a shorthand for oclIsKindOf(MyClass) 
    equivalent to : 
        self.ownedElement->select(oclIsKindOf(Class) and name="MyClass")

Resolution:
Revised Text:
Actions taken:
January 7, 2004: received issue

Discussion:

This is a request to improve the language. Better solved in a RTF.

Issue 6881: notation for selecting unique element within a list should be more concise (ocl2-rtf)

Click here for this issue's archive.
Source: France Telecom R&D (Mr. Mariano Belaunde, mariano.belaunde(at)orange.com)
Nature: Uncategorized Issue
Severity:
Summary:

Suggestion: Use brackets with a "!" prefixing mark 
    Example: 
        self.ownedElement[! #Class and name="MyClass"] 
        means 
        self.ownedElement->select(oclIsKindOf(Class) and name="MyClass")->first()

Resolution:
Revised Text:
Actions taken:
January 7, 2004: received issue

Discussion:

This is a request to improve the language. Better solved in a RTF.

Issue 6882: There is no simple way to invoke an "if then else" on a collection (ocl2-rtf)

Click here for this issue's archive.
Source: France Telecom R&D (Mr. Mariano Belaunde, mariano.belaunde(at)orange.com)
Nature: Uncategorized Issue
Severity:
Summary:

Suggestion: Define an "alt" collection function, with a specific notation, as in: 
     mylist->alt(iterator | condition? thenExp, elseExp) 
     The expression elseExp is not evaluated if condition returns true

Resolution:
Revised Text:
Actions taken:
January 7, 2004: received issue

Discussion:

This is a request to improve the language. Better solved in a RTF.

Issue 6883: The notation when nesting "if then else" is too verbose (ocl2-rtf)

Click here for this issue's archive.
Source: France Telecom R&D (Mr. Mariano Belaunde, mariano.belaunde(at)orange.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
January 7, 2004: received issue

Discussion:

This is a request to improve the language. Better solved in a RTF.

Issue 6884: The notation when nesting "if then else" is too verbose (ocl2-rtf)

Click here for this issue's archive.
Source: France Telecom R&D (Mr. Mariano Belaunde, mariano.belaunde(at)orange.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
January 7, 2004: received issue

Discussion:

This is a request to improve the language. Better solved in a RTF.

Issue 6885: Improve the notation when defining local variables (ocl2-rtf)

Click here for this issue's archive.
Source: France Telecom R&D (Mr. Mariano Belaunde, mariano.belaunde(at)orange.com)
Nature: Uncategorized Issue
Severity:
Summary:

This is to avoid using the unreadable and unfriendly "let … in …" notation. 
      Suggestion: Use the result of a variable initialization as in: 
      if (let c = self.address)="" then "UNKNOWN" 
      else if c.includes(Set{"Irak","Afganifsthan"})   then "DANGEROUS" 
      else "OK" endif endif endif …

Resolution:
Revised Text:
Actions taken:
January 7, 2004: received issue

Discussion:

This is a request to improve the language. Better solved in a RTF.

Issue 6886: Allow applying iteration operations on single objects (ocl2-rtf)

Click here for this issue's archive.
Source: France Telecom R&D (Mr. Mariano Belaunde, mariano.belaunde(at)orange.com)
Nature: Uncategorized Issue
Severity:
Summary:

Use a DOT instead of an ARROW is this situation. 
      myinstance.anycollectionfunction() equivalent to 
      Set{myinstance}->anycollectionfunction(…)->first()

Resolution:
Revised Text:
Actions taken:
January 7, 2004: received issue

Discussion:

This is a request to improve the language. Better solved in a RTF.

Issue 6887: Allow implicit type casting to boolean when a boolean is expected (ocl2-rtf)

Click here for this issue's archive.
Source: France Telecom R&D (Mr. Mariano Belaunde, mariano.belaunde(at)orange.com)
Nature: Uncategorized Issue
Severity:
Summary:

Example1:   if list.select(...) then … equivalent to 
                        if list.select(...)->notEmpty() then … 
     Example2:  if item then … equivalent to 
                      if item<>OCLUndefined then ...

Resolution:
Revised Text:
Actions taken:
January 7, 2004: received issue

Discussion:

This is a request to improve the language. Better solved in a RTF.

Issue 6889: Automatic casting between strings and enumeration values (ocl2-rtf)

Click here for this issue's archive.
Source: France Telecom R&D (Mr. Mariano Belaunde, mariano.belaunde(at)orange.com)
Nature: Uncategorized Issue
Severity:
Summary:

Make optional the qualification of enumeration values. 
  Example: Be able to write 'self.aggregationKind="Composite" ' as an alternative 
  to  'self.aggregationKind=AggregationKind::Composite'.

Resolution:
Revised Text:
Actions taken:
January 7, 2004: received issue

Discussion:

This is a request to improve the language. Better solved in a RTF.

Issue 6890: Suppress the usage of an Ocl prefix in standard library operations (ocl2-rtf)

Click here for this issue's archive.
Source: France Telecom R&D (Mr. Mariano Belaunde, mariano.belaunde(at)orange.com)
Nature: Uncategorized Issue
Severity:
Summary:

When a name conflicts happen, it should be possible to resolve by qualifying the 
    names.

Resolution:
Revised Text:
Actions taken:
January 7, 2004: received issue

Discussion:

This is a request to improve the language. Better solved in a RTF.

Issue 6891: Allow defining standard library functions (ocl2-rtf)

Click here for this issue's archive.
Source: France Telecom R&D (Mr. Mariano Belaunde, mariano.belaunde(at)orange.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
January 7, 2004: received issue

Discussion:

This is a request to improve the language. Better solved in a RTF.

Issue 6892: Allow defining default values for parameters in operations (ocl2-rtf)

Click here for this issue's archive.
Source: France Telecom R&D (Mr. Mariano Belaunde, mariano.belaunde(at)orange.com)
Nature: Uncategorized Issue
Severity:
Summary:

Allow defining default values for parameters in operations

Resolution:
Revised Text:
Actions taken:
January 7, 2004: received issue

Discussion:

This is a request to improve the language. Better solved in a RTF.

Issue 6893: Provide specific notational support when testing stereotypes (ocl2-rtf)

Click here for this issue's archive.
Source: France Telecom R&D (Mr. Mariano Belaunde, mariano.belaunde(at)orange.com)
Nature: Uncategorized Issue
Severity:
Summary:

Suggestion: Use the STAR character. Quotes could be used in case of blanks 
       characters in stereotype names. 
   Example: self.ownedElement.select(kindOf(Class) and *EJBEntity) 
       returns all the classes stereotyped by the EJBEntity stereotype or a derived 
           stereotype. 
   Example: self.ownedElement.select(kindOf(Class) and **EJBEntity) 
       returns all the classes stereotyped by the EJBEntity stereotype.

Resolution:
Revised Text:
Actions taken:
January 7, 2004: received issue

Discussion:

This is a request to improve the language. Better solved in a RTF.

Issue 6894: Add a generic text formatter operator '% (ocl2-rtf)

Click here for this issue's archive.
Source: France Telecom R&D (Mr. Mariano Belaunde, mariano.belaunde(at)orange.com)
Nature: Uncategorized Issue
Severity:
Summary:

Example:  self.comment = "My name is %s" % self.firstname

Resolution:
Revised Text:
Actions taken:
January 7, 2004: received issue

Discussion:

This is a request to improve the language. Better solved in a RTF.

Issue 6895: Make usage of tuples less complex and less verbose (ocl2-rtf)

Click here for this issue's archive.
Source: France Telecom R&D (Mr. Mariano Belaunde, mariano.belaunde(at)orange.com)
Nature: Uncategorized Issue
Severity:
Summary:

Suggestions: 
     - Make type spec of internal fields optional. 
     - Make field name in tuples optional (using positional access)

Resolution:
Revised Text:
Actions taken:
January 7, 2004: received issue

Discussion:

This is a request to improve the language. Better solved in a RTF.

Issue 7455: Add an import statement to OCL files (with package - endpackage block) (ocl2-rtf)

Click here for this issue's archive.
Source: OpenModeling (Mr. Jos Warmer, jos.warmer(at)openmodeling.nl)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
June 10, 2004: received issue

Discussion:

Deferred for timing reasons

Issue 7457: Add a concrete syntax to allow OCL users to add additional IteratorExp’s (ocl2-rtf)

Click here for this issue's archive.
Source: OpenModeling (Mr. Jos Warmer, jos.warmer(at)openmodeling.nl)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
June 10, 2004: received issue

Discussion:

This is a request to improve the language. Better solved in a RTF.

Issue 7466: rewrite well-formedness (ocl2-rtf)

Click here for this issue's archive.
Source: OpenModeling (Mr. Jos Warmer, jos.warmer(at)openmodeling.nl)
Nature: Uncategorized Issue
Severity:
Summary:

We would like to be able to rewrite well-formedness rules like:
context IfExp
inv: self.condition.type.oclIsKindOf(Primitive) and
self.condition.type.name = ’Boolean’
as
context IfExp
inv: self.condition.type.oclIsKindOf(Primitive) and This is more clear that the first expression where the matching is done by name.
Because the metamodel resides on a level higher than the standard library, we need a way to get access
to the standard library elements. One solution is to define a package ’StandardLibrary’ that contains a
Classifier called ’StdLib’, that holds the following attributes:
• + Collection: CollectionType;
• + Set: SetType;
• + OrderedSet: OrderedSetType;
• + Sequence: SequenceType;
• + Bag: BagType;
• + String: Primitive;
• + OclMessage: OclMessageType;
• + OclVoid : VoidType;
Other solutions might be possible, but the above has been proven to work in the Octopus tool.

Resolution:
Revised Text:
Actions taken:
June 10, 2004: received issue

Discussion:

Discussion:
This issue will be deferred. There is a question of representing formally the standard library as an ordinary UML package, which is not going to be solved for OCL 2.1 release. 
Disposition:	Deferred

Issue 7500: context Classifier (02) (ocl2-rtf)

Click here for this issue's archive.
Source: OpenModeling (Mr. Jos Warmer, jos.warmer(at)openmodeling.nl)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
June 10, 2004: received issue

Issue 7501: context Operation (ocl2-rtf)

Click here for this issue's archive.
Source: OpenModeling (Mr. Jos Warmer, jos.warmer(at)openmodeling.nl)
Nature: Uncategorized Issue
Severity:
Summary:

def: hasMatchingSignature(paramTypes: Sequence(Classifier)) : Boolean =
-- check that operation op has a signature that matches the given parameter lists
let sigParamTypes: Sequence(Classifier) = self.allAttributes.type in
(
( sigParamTypes->size() = paramTypes->size() ) and
( Set{1..paramTypes->size()}->forAll ( i |
paramTypes->at (i).conformsTo (sigParamTypes->at (i))
)
)
)
==> ’self.allAttributes.type’ should be ’self.Parameter.type->asSequence()’

Resolution:
Revised Text:
Actions taken:
June 10, 2004: receeived issue

Issue 7502: context Parameter::asAttribute(): Attribute (ocl2-rtf)

Click here for this issue's archive.
Source: OpenModeling (Mr. Jos Warmer, jos.warmer(at)openmodeling.nl)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
June 10, 2004: received issue

Issue 7503: context State::getStateMachine() : StateMachine (ocl2-rtf)

Click here for this issue's archive.
Source: OpenModeling (Mr. Jos Warmer, jos.warmer(at)openmodeling.nl)
Nature: Uncategorized Issue
Severity:
Summary:

post: result =
if statemachine->notEmpty() then
stateMachine
else
-- must be part of a composite state
state.container.getStateMachine()
endif
context Transition::getStateMachine() : StateMachine
post: result =
if statemachine->notEmpty() then
stateMachine
else
-- state is not empty
state.getStateMachine()
endif
==> in both expressions ’statemachine’ should be stateMachine

Resolution:
Revised Text:
Actions taken:
June 10, 2004: received issue

Issue 7504: context VariableDeclaration::asAttribute() : Attribute (ocl2-rtf)

Click here for this issue's archive.
Source: OpenModeling (Mr. Jos Warmer, jos.warmer(at)openmodeling.nl)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
June 10, 2004: received issue

Issue 7505: parameters of the referredOperation (ocl2-rtf)

Click here for this issue's archive.
Source: OpenModeling (Mr. Jos Warmer, jos.warmer(at)openmodeling.nl)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
June 10, 2004: received issue

Issue 7506: parameters of the referredOperation (ocl2-rtf)

Click here for this issue's archive.
Source: OpenModeling (Mr. Jos Warmer, jos.warmer(at)openmodeling.nl)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:

Issue 7507: An additional attribute refParams lists all parameters of the referred (ocl2-rtf)

Click here for this issue's archive.
Source: OpenModeling (Mr. Jos Warmer, jos.warmer(at)openmodeling.nl)
Nature: Uncategorized Issue
Severity:
Summary:

38. -- [3] An additional attribute refParams lists all parameters of the referred
-- operation except the return and out parameter(s).
context OperationCallExp
def: refParams: Sequence(Parameter) = referredOperation.parameters-
>select (p
|
p.kind <> ParameterDirectionKind::return or
p.kind <> ParameterDirectionKind::out)
==> ’parameters’ should be ’Parameter’

Resolution:
Revised Text:
Actions taken:
June 10, 2004: received issue

Issue 7508: 1] The type of the attribute is the type of the value expression. (ocl2-rtf)

Click here for this issue's archive.
Source: OpenModeling (Mr. Jos Warmer, jos.warmer(at)openmodeling.nl)
Nature: Uncategorized Issue
Severity:
Summary:

context TupleLiteralExpPart
inv: attribute.type = value.type
==> should be removed, class does not exist

Resolution:
Revised Text:
Actions taken:
June 10, 2004: received issue

Issue 7509: context LocalSnapshot (ocl2-rtf)

Click here for this issue's archive.
Source: OpenModeling (Mr. Jos Warmer, jos.warmer(at)openmodeling.nl)
Nature: Uncategorized Issue
Severity:
Summary:

Errors found in UML-based-semantics
1. context LocalSnapshot
def: let allPredecessors() : Sequence(LocalSnapshot) =
if pred->notEmpty then
pred->union(pred.allPredecessors())
else
Sequence {}
endif
def: let allSuccessors() : Sequence(LocalSnapshot) =
if succ->notEmpty then
succ->union(succ.allSuccessors())
else
Sequence {}
==> remove ’let’ from both expressions, add ’endif’ after the second

Resolution:
Revised Text:
Actions taken:
June 10, 2004: received issue

Issue 7510: outgoingMessages results in the sequence of OclMessageValues (ocl2-rtf)

Click here for this issue's archive.
Source: OpenModeling (Mr. Jos Warmer, jos.warmer(at)openmodeling.nl)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
June 10, 2004: received issue

Issue 7511: context IfExpEval inv: (ocl2-rtf)

Click here for this issue's archive.
Source: OpenModeling (Mr. Jos Warmer, jos.warmer(at)openmodeling.nl)
Nature: Uncategorized Issue
Severity:
Summary:

resultValue = if condition then thenExpression.resultValue else
elseExpression.resultValue
==> missing ’endif’

Resolution:
Revised Text:
Actions taken:
June 10, 2004: received issue

Issue 7512: sub evaluations (in the sequence bodyEvals) (ocl2-rtf)

Click here for this issue's archive.
Source: OpenModeling (Mr. Jos Warmer, jos.warmer(at)openmodeling.nl)
Nature: Uncategorized Issue
Severity:
Summary:

4. -- [2] All sub evaluations (in the sequence bodyEvals) have a different
-- environment. The first sub evaluation will start with an environment in which
-- all iterator variables are bound to the first element of the source. Note that
-- this is an arbitrary choice, one could easily well start with the last element
-- of the source, or any other combination.
context LoopExpEval
inv: let bindings: Sequence( NameValueBindings ) =
iterators->collect( i |
NameValueBinding( i.varName, source->asSequence()->first() )
in
bodyEvals->at(1).environment = self.environment->addAll( bindings )
==> missing closing bracket before ’in’

Resolution:
Revised Text:
Actions taken:
June 10, 2004: received issue

Issue 7513: sub evaluations (in sequence bodyEvals) have different environment. (ocl2-rtf)

Click here for this issue's archive.
Source: OpenModeling (Mr. Jos Warmer, jos.warmer(at)openmodeling.nl)
Nature: Uncategorized Issue
Severity:
Summary:

5. -- [3] All sub evaluations (in the sequence bodyEvals) have a different
-- environment. The environment is the same environment as the one from the
-- previous bodyEval, where the iterator variable or variables are bound to the
-- subsequent elements of the source.
context LoopExpEval
inv:
let SS: Integer = source.value->size()
in if iterators->size() = 1 then
Sequence{2..SS}->forAll( i: Integer |
bodyEvals->at(i).environment = bodyEvals->at(i-1).environment
->replace( NameValueBinding( iterators->at(1).varName,
source.value->asSequence()->at(i) )))
else -- iterators->size() = 2
Sequence{2..SS*SS}->forAll( i: Integer |
bodyEvals->at(i).environment = bodyEvals->at(i-1).environment
->replace( NameValueBinding( iterators->at(1).varName,
source->asSequence()->at(i.div(SS) + 1) ))
->replace( NameValueBinding( iterators->at(2).varName,
source.value->asSequence()->at(i.mod(SS)) )) ) endif
==> two closing brackets before ’endif’ should be removed

Resolution:
Revised Text:
Actions taken:
June 10, 2004: received issue

Discussion:

Issue 7514: ocl message expression (ocl2-rtf)

Click here for this issue's archive.
Source: OpenModeling (Mr. Jos Warmer, jos.warmer(at)openmodeling.nl)
Nature: Uncategorized Issue
Severity:
Summary:

6. -- [2] The result value of an ocl message expression is the sequence of the
-- outgoing messages of the ‘self’ object that matches the expression. Note that
-- this may result in an empty sequence when the expression does not match to any
-- of the outgoing messages.
context OclMessageExpEval
inv: resultValue =
environment.getValueOf( ’self’ ).outgoingMessages->select( m |
m.target = target.resultValue and
m.name = self.name and
self.arguments->forAll( expArg: OclMessageArgEval |
not expArg.resultValue.oclIsUndefined() implies
m.arguments->exists( messArg | messArg.value = expArg.value ))
==> add one closing bracket after expression

Resolution:
Revised Text:
Actions taken:
June 10, 2004: received issue

Issue 7515: isSent attribute (ocl2-rtf)

Click here for this issue's archive.
Source: OpenModeling (Mr. Jos Warmer, jos.warmer(at)openmodeling.nl)
Nature: Uncategorized Issue
Severity:
Summary:

7. -- [4] The isSent attribute of the resulting ocl message value is true only if
-- the message value is in the outgoing messages of the ‘self’ object.
context OclMessageExpEval
inv:
if resultValue.oclIsUndefined()
resultValue.isSent = false
else
resultValue.isSent = true
endif
==> add ’then’ after ’oclIsUndefined()’

Resolution:
Revised Text:
Actions taken:
June 10, 2004: received issue

Issue 7516: add ’and’ between both expression parts (ocl2-rtf)

Click here for this issue's archive.
Source: OpenModeling (Mr. Jos Warmer, jos.warmer(at)openmodeling.nl)
Nature: Uncategorized Issue
Severity:
Summary:

8. -- [1] An ocl message argument evaluation has either an ocl expression
-- evaluation, or an unspecified value expression evaluation, not both.
context OclMessageArgEval inv:
expression->size() = 1 implies unspecified->size() = 0
expression->size() = 0 implies unspecified->size() = 1
==> add ’and’ between both expression parts

Resolution:
Revised Text:
Actions taken:
June 10, 2004: received issue

Issue 7517: result value of an association class call expression evaluation (ocl2-rtf)

Click here for this issue's archive.
Source: OpenModeling (Mr. Jos Warmer, jos.warmer(at)openmodeling.nl)
Nature: Uncategorized Issue
Severity:
Summary:

9. -- [2] The result value of an association class call expression evaluation that
-- has qualifiers, is determined according to the following rule. The ‘normal’
-- determination of result value is already given in section 5.3.7
-- ("Well-formedness Rules of the Evaluations package").
==> missing ’context .... inv:’
==> missing brackets and comma; the whole expression should be:
let
-- the attributes that are the formal qualifiers. Because and
association
-- class has two or
-- more association ends, we must select the qualifiers from the other
end(s),
-- not from -- the source of this expression. We allow only 2-ary associations.
formalQualifiers : Sequence(Attribute) =
self.model.referredAssociationClass.connection->any( c |
c <> self.navigationSource).qualifier.asSequence() ,
-- the attributes of the class at the qualified end. Here we already
assume
-- that an
-- AssociationEnd will be owned by a Classifier, as will most likely be
the
-- case in the
-- UML 2.0 Infrastructure.
objectAttributes: Sequence(Attribute) =
self.model.referredAssociationClass.connection->any( c |
c <> self.navigationSource).owner.feature->select( f |
f.isOclType( Attribute ))->asSequence() ,
-- the rolename of the qualified association end
qualifiedEnd: String = self.model.referredAssociationClass.connection-
>any( c
|
c <> self.navigationSource).name ,
-- the values for the qualifiers given in the ocl expression
qualifierValues : Sequence( Value ) = self.qualifiers->asSequence() ,
-- the objects from which a subset must be selected through the
qualifiers
normalResult =
source.resultValue.getCurrentValueOf(referredAssociationClass.name)
in
-- if name of attribute of object at qualified end equals name of formal
-- qualifier then
-- if value of attribute of object at qualified end equals the value
given in
-- the exp
-- then select this object and put it in the resultValue of this
expression.
qualifiers->size <> 0 implies
normalResult->select( obj |
Sequence{1..formalQualifiers->size()}->forAll( i |
objectAttributes->at(i).name = formalQualifiers->at(i).name and
obj.qualifiedEnd.getCurrentValueOf( objectAttributes->at(i).name ) =
qualifiersValues->at(i) ))

Resolution:
Revised Text:
Actions taken:
June 10, 2004: received issue

Issue 7518: value of an association end call expression evaluation (ocl2-rtf)

Click here for this issue's archive.
Source: OpenModeling (Mr. Jos Warmer, jos.warmer(at)openmodeling.nl)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
June 10, 2004: received issue

Issue 7519: missing ’inv:’ twice (ocl2-rtf)

Click here for this issue's archive.
Source: OpenModeling (Mr. Jos Warmer, jos.warmer(at)openmodeling.nl)
Nature: Uncategorized Issue
Severity:
Summary:

11. -- [1] The condition evaluation corresponds with the condition of the expression,
-- and likewise for the thenExpression and the else Expression.
context IfExpEval inv:
condition.model = model.condition
thenExpression.model = model.thenExpression
elseExpression.model = model.elseExpression
==> missing ’inv:’ twice

Resolution:
Revised Text:
Actions taken:
June 10, 2004: received issue

Issue 7520: an iterate expression evaluation (ocl2-rtf)

Click here for this issue's archive.
Source: OpenModeling (Mr. Jos Warmer, jos.warmer(at)openmodeling.nl)
Nature: Uncategorized Issue
Severity:
Summary:

12. -- [1] The model of the result of an iterate expression evaluation is equal to
-- the model of the result of the associated IterateExp.
context IterateExpEval
inv: result.model = model.result )
==> remove last bracket

Resolution:
Revised Text:
Actions taken:
June 14, 2004: received issue

Issue 7521: arguments (ocl2-rtf)

Click here for this issue's archive.
Source: OpenModeling (Mr. Jos Warmer, jos.warmer(at)openmodeling.nl)
Nature: Uncategorized Issue
Severity:
Summary:

13. -- [4] The arguments of an ocl message expression evaluation must correspond to
-- the formal input parameters of the operation, or the attributes of the signal
-- indicated in the ocl message expression.
context OclMessageExpEval
inv: model.calledOperation->size() = 1 implies
Sequence{1.. arguments->size()} ->forAll( i | arguments->at(i).variable->size() = 1 implies
model.calledOperation.operation.parameter->
select( kind = ParameterDirectionKind::In )->at(i).name =
arguments->at(i).variable
and
arguments->at(i).expression->size() = 1 implies
model.calledOperation.operation.parameter->
select( kind = ParameterDirectionKind::In )at(i).type =
arguments->at(i).expression.model
==> missing ’->’ before ’at’, and missing final closing bracket

Resolution:
Revised Text:
Actions taken:
June 10, 2004: received issue

Issue 7522: inv: model.sentSignal->size() = 1 implies (ocl2-rtf)

Click here for this issue's archive.
Source: OpenModeling (Mr. Jos Warmer, jos.warmer(at)openmodeling.nl)
Nature: Uncategorized Issue
Severity:
Summary:

Sequence{1.. arguments->size()} ->forAll( i |
arguments->at(i).variable->size() = 1 implies
model.sentSignal.signal.feature->select(
arguments->at(i).variable )->notEmpty()
and
arguments->at(i).expression->size() = 1 implies
model.sentSignal.signal.feature.oclAsType(StructuralFeature).type =
arguments->at(i).expression.model
==> missing final closing bracket

Resolution:
Revised Text:
Actions taken:
June 10, 2004: received issue

Issue 7523: arguments of the return message of an ocl message expression (ocl2-rtf)

Click here for this issue's archive.
Source: OpenModeling (Mr. Jos Warmer, jos.warmer(at)openmodeling.nl)
Nature: Uncategorized Issue
Severity:
Summary:

15. -- [5] The arguments of the return message of an ocl message expression
-- evaluation must correspond to the names given by the formal output parameters,
-- and the result type of the operation indicated in the ocl message expression.
-- Note that the Parameter type is defined in the UML 1.4 foundation package.
context OclMessageExpEval
inv: let returnArguments: Sequence{ NameValueBindings ) =
resultValue.returnMessage.arguments ,
formalParameters: Sequence{ Parameter } =
==> ’{’ should be ’(’ (twice), and ’}’ should be ’)’

Resolution:
Revised Text:
Actions taken:
June 10, 2004: received issue

Issue 7524: Only one of the attributes isPost and isPre may be true at the same time. (ocl2-rtf)

Click here for this issue's archive.
Source: OpenModeling (Mr. Jos Warmer, jos.warmer(at)openmodeling.nl)
Nature: Uncategorized Issue
Severity:
Summary:

16. -- [1] Only one of the attributes isPost and isPre may be true at the same time.
context LocalSnapshot
inv: isPost implies isPre = false
inv: ispre implies isPost = false
==> second invariant: ’ispre’ should be ’isPre’

Resolution:
Revised Text:
Actions taken:
June 10, 2004: received issue

Issue 7525: ’element’ should be ’elements’ (ocl2-rtf)

Click here for this issue's archive.
Source: OpenModeling (Mr. Jos Warmer, jos.warmer(at)openmodeling.nl)
Nature: Uncategorized Issue
Severity:
Summary:

17. -- [1] All elements belonging to a sequence value have unique index numbers.
inv: self.element->isUnique(e : Element | e.indexNr)
==> missing context statement: context SequenceTypeValue,
==> ’element’ should be ’elements’

Resolution:
Revised Text:
Actions taken:
June 10, 2004: received issue

Issue 7526: ’element’ should be ’elements’ (02) (ocl2-rtf)

Click here for this issue's archive.
Source: OpenModeling (Mr. Jos Warmer, jos.warmer(at)openmodeling.nl)
Nature: Uncategorized Issue
Severity:
Summary:

18. -- [1] All elements belonging to a set value have unique values.
inv: self.element->isUnique(e : Element | e.value)
==> missing context statement: context SetTypeValue
==> ’element’ should be ’elements’

Resolution:
Revised Text:
Actions taken:
June 10, 2004: received issue

Issue 7527: ’Element’ should be ’NameValueBinding’ (ocl2-rtf)

Click here for this issue's archive.
Source: OpenModeling (Mr. Jos Warmer, jos.warmer(at)openmodeling.nl)
Nature: Uncategorized Issue
Severity:
Summary:

19. -- [1] All elements belonging to a tuple value have unique names.inv: self.elements->isUnique(e : Element | e.name)
==> missing context statement: context TupleValue
==> ’Element’ should be ’NameValueBinding’

Resolution:
Revised Text:
Actions taken:
June 10, 2004: received issue

Issue 7528: history of an object is ordered. (ocl2-rtf)

Click here for this issue's archive.
Source: OpenModeling (Mr. Jos Warmer, jos.warmer(at)openmodeling.nl)
Nature: Uncategorized Issue
Severity:
Summary:

20. -- [1] The history of an object is ordered. The first element does not have a
-- predecessor, the last does not have a successor.
context ObjectValue
inv: history->oclIsTypeOf( Sequence(LocalSnapShot) )
inv: history->last().succ->size = 0
inv: history->first().Pre->size = 0
==> should be:
context ObjectValue
inv: history->oclIsTypeOf(
StandardLibrary::StdLib.Sequence(LocalSnapShot) )
inv: history->last().succ->size = 0
inv: history->first().Pre->size = 0

Resolution:
Revised Text:
Actions taken:
June 10, 2004: received issue

Issue 7529: The history of an object is ordered.(02) (ocl2-rtf)

Click here for this issue's archive.
Source: OpenModeling (Mr. Jos Warmer, jos.warmer(at)openmodeling.nl)
Nature: Uncategorized Issue
Severity:
Summary:

21. -- [1] The history of an object is ordered. The first element does not have a
-- predecessor, the last does not have a successor.
context ObjectValue
inv: history->oclIsTypeOf(
StandardLibrary::StdLib.Sequence(LocalSnapShot) )
inv: history->last().succ->size = 0
inv: history->first().Pre->size = 0
==> ’size’ should be ’size()’ (twice)

Resolution:
Revised Text:
Actions taken:
June 10, 2004: received issue

Issue 7530: The operation allPredecessors (ocl2-rtf)

Click here for this issue's archive.
Source: OpenModeling (Mr. Jos Warmer, jos.warmer(at)openmodeling.nl)
Nature: Uncategorized Issue
Severity:
Summary:

22. -- [1] The operation allPredecessors returns the collection of all snapshots
-- before a snapshot, allSuccessors returns the collection of all snapshots after
-- a snapshot.
context LocalSnapshot
def: allPredecessors() : Sequence(LocalSnapshot) =
if pred->notEmpty then
pred->union(pred.allPredecessors())
else
Sequence {}
endif
def: allSuccessors() : Sequence(LocalSnapshot) =
if succ->notEmpty then
succ->union(succ.allSuccessors())
else
Sequence {}
endif
==> ’notEmpty’ should be ’notEmpty()’ (twice)

Resolution:
Revised Text:
Actions taken:
June 10, 2004: received issue

Issue 7531: elements in a tuple value (ocl2-rtf)

Click here for this issue's archive.
Source: OpenModeling (Mr. Jos Warmer, jos.warmer(at)openmodeling.nl)
Nature: Uncategorized Issue
Severity:
Summary:

23. -- [1] The elements in a tuple value must have a type that conforms to the type
-- of the corresponding tuple parts.
context TupleValue inv:
elements->forAll( elem |
let correspondingPart: Attribute =
self.model.allAttributes()->select( part | part.name = elem.name ) in elem.value.model.conformsTo( correspondingPart.type ) )
==> ’Attribute’ should be ’UML14::Core::Attribute’
==> ’select’ should be ’any’

Resolution:
Revised Text:
Actions taken:
June 10, 2004: received issue

Issue 7532: value of an association class call expression (ocl2-rtf)

Click here for this issue's archive.
Source: OpenModeling (Mr. Jos Warmer, jos.warmer(at)openmodeling.nl)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
June 10, 2004: received issue

Issue 7533: result value of an association end call expression (ocl2-rtf)

Click here for this issue's archive.
Source: OpenModeling (Mr. Jos Warmer, jos.warmer(at)openmodeling.nl)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
June 10, 2004: received issue

Issue 7534: result value of an association class call expression (ocl2-rtf)

Click here for this issue's archive.
Source: OpenModeling (Mr. Jos Warmer, jos.warmer(at)openmodeling.nl)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
June 10, 2004: received issue

Issue 7535: result value of an association end call expression (ocl2-rtf)

Click here for this issue's archive.
Source: OpenModeling (Mr. Jos Warmer, jos.warmer(at)openmodeling.nl)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
June 10, 2004: received issue

Issue 7536: result value of an association end call expression (02) (ocl2-rtf)

Click here for this issue's archive.
Source: OpenModeling (Mr. Jos Warmer, jos.warmer(at)openmodeling.nl)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
June 10, 2004: received issue

Issue 7537: result value of an attribute call expression (ocl2-rtf)

Click here for this issue's archive.
Source: OpenModeling (Mr. Jos Warmer, jos.warmer(at)openmodeling.nl)
Nature: Uncategorized Issue
Severity:
Summary:

29. -- [1] The result value of an attribute call expression is the value bound to the
-- name of the attribute to which it refers.
context AttributeCallExpEval inv:
resultValue = if source.resultValue->isOclType(
OCLDomain::Values::ObjectValue) then
source.resultValue->asOclType( ObjectValue )
.getCurrentValueOf(referredAttribute.name)
else -- must be a tuple value
source.resultValue->asOclType( TupleValue )
.getValueOf(referredAttribute.name)
endif
==> ’isOclType’ should be ’oclIsTypeOf’
==> ’asOclType’ should be ’oclAsType’
==> ’name’ should be ’value’ (twice)

Resolution:
Revised Text:
Actions taken:
June 10, 2004: received issue

Issue 7538: value of a collection item (ocl2-rtf)

Click here for this issue's archive.
Source: OpenModeling (Mr. Jos Warmer, jos.warmer(at)openmodeling.nl)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
June 10, 2004: received issue

Issue 7539: result value of a collection literal expression evaluation (ocl2-rtf)

Click here for this issue's archive.
Source: OpenModeling (Mr. Jos Warmer, jos.warmer(at)openmodeling.nl)
Nature: Uncategorized Issue
Severity:
Summary:

31. -- [2] The result value of a collection literal expression evaluation is a
-- collection literal value, or one of its subtypes.
context CollectionLiteralExpEval inv:
resultValue.isOclKind( OCLDomain::Values::CollectionValue )
==> ’isOclKind’ should be ’oclIsKindOf’

Resolution:
Revised Text:
Actions taken:
June 10, 2004: received issue

Issue 7540: number of elements in the result value (ocl2-rtf)

Click here for this issue's archive.
Source: OpenModeling (Mr. Jos Warmer, jos.warmer(at)openmodeling.nl)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
June 10, 2004: received issue

Issue 7541: value of a collection range (ocl2-rtf)

Click here for this issue's archive.
Source: OpenModeling (Mr. Jos Warmer, jos.warmer(at)openmodeling.nl)
Nature: Uncategorized Issue
Severity:
Summary:

33. -- [1] The value of a collection range is the range of integer numbers between
-- the result value of its first expression and its last expression.
context CollectionRangeEval
inv: element.isOclType( Sequence(Integer) ) and
element = getRange( first->asOclType(Integer), last->asOclType(Integer)
)
==> ’asOclType’ should be ’oclAsType’ (twice)

Resolution:
Revised Text:
Actions taken:
June 10, 2004: received issue

Issue 7542: result value of an if expression (ocl2-rtf)

Click here for this issue's archive.
Source: OpenModeling (Mr. Jos Warmer, jos.warmer(at)openmodeling.nl)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
June 10, 2004: received issue

Issue 7543: elements in the result value (ocl2-rtf)

Click here for this issue's archive.
Source: OpenModeling (Mr. Jos Warmer, jos.warmer(at)openmodeling.nl)
Nature: Uncategorized Issue
Severity:
Summary:

35. -- [4] The elements in the result value are the elements in the
-- literal parts, taking into account that a collection range can result
-- elements.
context CollectionLiteralExpEval inv:
let allElements : Bag(Value) = parts->collect(
Sequence{1..allElements->size()}->forAll( i:
resultValue.elements->at(i).name = ’’ and
resultValue.elements->at(i).value = allElements->
self.kind = CollectionKind::Sequence implies
resultValue.elements->at(i).indexNr = i )
==> should be
context CollectionLiteralExpEval inv:
let allElements : Sequence(Value) = parts->collect(
in
Sequence{1..allElements->size()}->forAll( i:
resultValue->oclAsType(OCLDomain::Values::CollectionValue).
>any(x | x.indexNr = i).value
= allElements->at(i) and
self.kind = CollectionKind::Sequence implies
resultValue.elements->at(i).indexNr = i )

Resolution:
Revised Text:
Actions taken:
June 10, 2004: received issue

Issue 7544: value of a collection range (ocl2-rtf)

Click here for this issue's archive.
Source: OpenModeling (Mr. Jos Warmer, jos.warmer(at)openmodeling.nl)
Nature: Uncategorized Issue
Severity:
Summary:

36. -- [1] The value of a collection range is the range of integer numbers between
-- the result value of its first expression and its last expression.
context CollectionRangeEval
inv: element.isOclType( Sequence(Integer) ) and
element = getRange( first->oclAsType(Integer), last->oclAsType(Integer)                                        ==> ’isOclType’ should be ’oclIsTypeOf’

Resolution:
Revised Text:
Actions taken:
June 10, 2004: received issue

Issue 7545: sub evaluations (ocl2-rtf)

Click here for this issue's archive.
Source: OpenModeling (Mr. Jos Warmer, jos.warmer(at)openmodeling.nl)
Nature: Uncategorized Issue
Severity:
Summary:

37. -- [1] All sub evaluations have a different environment. The first sub evaluation
-- will start with an environment in which all iterator variables are bound to
-- the first element of the source, plus the result variable which is bound to
-- the init expression of the variable declaration in which it is defined.
context IterateExpEval
inv: let bindings: Sequence( NameValueBindings ) =
iterators->collect( i |
NameValueBinding( i.varName, source->asSequence()->first() ))
in
bodyEvals->at(1).environment = self.environment->addAll( bindings )
->add( NameValueBinding( result.name, result.initExp.resultValue ))
==> ’NameValueBindings’ should be ’NameValueBinding’

Resolution:
Revised Text:
Actions taken:
June 10, 2004: received issue

Issue 7546: sub evaluations (02) (ocl2-rtf)

Click here for this issue's archive.
Source: OpenModeling (Mr. Jos Warmer, jos.warmer(at)openmodeling.nl)
Nature: Uncategorized Issue
Severity:
Summary:

38. -- [1] All sub evaluations have a different environment. The first sub evaluation
-- will start with an environment in which all iterator variables are bound to
-- the first element of the source, plus the result variable which is bound to
-- the init expression of the variable declaration in which it is defined.
context IterateExpEval
inv: let bindings: Sequence( NameValueBinding ) =
iterators->collect( i |
NameValueBinding( i.varName, source->asSequence()->first() ))
in
bodyEvals->at(1).environment = self.environment->addAll( bindings )
->add( NameValueBinding( result.name, result.initExp.resultValue ))
==> ’varName’ should be ’value’

Resolution:
Revised Text:
Actions taken:
June 10, 2004: received issue

Issue 7722: Section: 6.5.4.3 Combining Properties (ocl2-rtf)

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

"[1] Married people are of age >= 18 context Person inv: self.wife->notEmpty() implies self.wife.age >= 18 and self.husband->notEmpty() implies self.husband.age >= 18" has to be "[1] Married people are of age >= 18 context Person inv: (self.wife->notEmpty() implies self.wife.age >= 18) and (self.husband->notEmpty() implies self.husband.age >= 18)" because of the precedence rules
 same mistake in http://www.omg.org/docs/ptc/03-10-14.pdf, "UML 2.0 OCL Final Adopted specification", chapter 7.5.3, page 18.

Resolution:
Revised Text:
Actions taken:
September 9, 2004: received issue

Issue 7972: OCL Constraints in many levels (ocl2-rtf)

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

I been using rational rose and bold for delphi in some projects. This have worked very well for me.
When adding constraints to my models i have some times whished that there whas a way to do this
on different levels. Eg. error-constraints (if persisted the object would be a dirty data) , 
 
warning-constraints these can be broken but there is high probability that the object is ill formed from the
system user perspective (example a new customer whith no billing adress) and finally a hint-contraint that
when broken indicates that the object containes strange data (example a new customer object with the 
same phone number as a existing customer)
 
My own solution to this have been to add contraints of the first type to the model. This have enabeld me
to create generic code dealing with if the user should be allowed to save a object or not. 
 
The other types of constraints have been added as coments as a way to make the model as complete as
possibel. The implementation of checking and dealing with these constraints later in the project have ben 
solved in a mutch less generic and cumbersom way.
 
I thin´k that if the standard included a way to specify different levels of ocl statements in the model this would 
benefit the model driven way to make software

Resolution:
Revised Text:
Actions taken:
December 10, 2004: received issue

Issue 8620: Section: 7.4 (ocl2-rtf)

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

I'm not certain if I should report this issue to the OCL group or to the UML Superstructure group, but... the Basic Types listed in OCL do not agree with the Primitive Types listed in the UML Superstucture. OCL lists "Real" as a primitive (basic type), UML Superstructure does not, instead listing UnlimitedNatural as a primitive type. Shouldn't the two agree?

Resolution:
Revised Text:
Actions taken:
March 23, 2005: received issue

Discussion:

Issue 8621: Section: 7.4.5 (ocl2-rtf)

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

Typo - In the 2nd para, 3rd sent., the "t" of "type conformance error" is not italicized as is the rest of the phrase. Table 4 does not address the UML 2.0 (pct/04-10-02)use of UnlimitedNaturals as a type. This type probably Conforms to/Is a subtype of Real since UnlimitedNaturals are integers equal to or greater than 0.

Resolution:
Revised Text:
Actions taken:
March 23, 2005: received issue

Issue 8622: Section: 7.5.3 (ocl2-rtf)

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

Typo - 2nd line of para under Missing AssociationEnd names, add a "s" to "tarting." Combining Properties example [2] does not show/express any combined properties; it just expresses the size property of the set employee.

Resolution:
Revised Text:
Actions taken:
March 23, 2005: received issue

Issue 8623: Section: 7.5.8 (ocl2-rtf)

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

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

Resolution:
Revised Text:
Actions taken:
March 24, 2005: received issue

Issue 8624: Section: 7.5.9 (ocl2-rtf)

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

Although the definition of oclAsType may be obvious, this is an appropriate sub-section to place a paragraph describing oclAsType. It is the only prrdefined property on All Objects that is not defined in this section.

Resolution:
Revised Text:
Actions taken:
March 24, 2005: received issue

Issue 8625: Section: 7.5.11 (ocl2-rtf)

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

The example of Set {1,2,5,88} is more of an example of an ordered set as is Set {'apple','orange','strawberry'}. The example of a Sequence {1,3,45,2,3} does not exhibit any apparent order although a Sequence is defined as an ordered Bag. It might be wise to alter these examples to: Set {1,88,5,2}, Set ['strawberry','apple','orange'} and Sequence {1,2,3,3,45}

Resolution:
Revised Text:
Actions taken:
March 24, 2005: received issue

Issue 8626: Section: 7.5.13 (ocl2-rtf)

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

The example using Bike and Car as two separate subtypes of Transport does not make any mention of Set(Car), Bag(car), or Collection(Car). Either delete reference to Car as a separate subtype of Transport or add some comments about a collection of some sort of Car conforming (and not conforming) to some other collection. I may be confused, but the statement "Note that Set(Bicycle) does not conform to Bag(Bicycle)" does not make a lot of sense to me. Wouldn't it be better to say that "Set(Bicycle) does not conform to Bag(car)?"

Resolution:
Revised Text:
Actions taken:
March 24, 2005: received issue

Issue 8627: Section: 7.6.2 (ocl2-rtf)

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

In the 2nd paragraph, shange "The value of the reject operation..." to "The value of the collect operation..."

Resolution:
Revised Text:
Actions taken:
March 24, 2005: received issue

Issue 8628: Section: 8.2 (ocl2-rtf)

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

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

Resolution:
Revised Text:
Actions taken:
March 24, 2005: received issue

Issue 8634: Section: 8.3 (ocl2-rtf)

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

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

Resolution:
Revised Text:
Actions taken:
March 25, 2005: received issue

Issue 8635: Section: 8.3.4 (ocl2-rtf)

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

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

Resolution:
Revised Text:
Actions taken:
March 25, 2005: received issue

Issue 8636: Section: 8.3.5 (ocl2-rtf)

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

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

Resolution:
Revised Text:
Actions taken:
March 25, 2005: received issue

Issue 8637: Section: 8.3.1 (ocl2-rtf)

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

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

Resolution:
Revised Text:
Actions taken:
March 25, 2005: received issue

Issue 8638: Section: 8.3.8 (ocl2-rtf)

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

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

Resolution:
Revised Text:
Actions taken:
March 28, 2005: received issue

Issue 8639: Section: 9.1 (ocl2-rtf)

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

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

Resolution:
Revised Text:
Actions taken:
March 28, 2005: received issue

Issue 8640: Section: 9.3 CollectionLiteralPartsCS (ocl2-rtf)

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

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

Resolution:
Revised Text:
Actions taken:
March 28, 2005: received issue

Issue 8641: Section: 10.1 (ocl2-rtf)

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

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

Resolution:
Revised Text:
Actions taken:
March 28, 2005: received issue

Issue 8642: Section: 10.2 (ocl2-rtf)

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

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

Resolution:
Revised Text:
Actions taken:
March 28, 2005: received issue

Issue 8643: Section: 10.2.1 Element (ocl2-rtf)

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

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

Resolution:
Revised Text:
Actions taken:
March 28, 2005: received issue

Issue 8644: Section: 10.2.1 NameValueBinding (ocl2-rtf)

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

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

Resolution:
Revised Text:
Actions taken:
March 28, 2005: received issue

Issue 8645: Section: 10.2.2 LocalSnapshot (ocl2-rtf)

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

Typos - Change "ispre" to "isPre" and reword [2] to "...postcondition snapshot does it have an associated..."

Resolution:
Revised Text:
Actions taken:
March 28, 2005: received issue

Issue 8646: Section: 10.2.3 ObjectValue (ocl2-rtf)

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

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

Resolution:
Revised Text:
Actions taken:
March 28, 2005: received issue

Issue 8647: Section: 10.3 (ocl2-rtf)

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

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

Resolution:
Revised Text:
Actions taken:
March 28, 2005: received issue

Issue 8648: Section: 10.3.1 LoopExpEval (ocl2-rtf)

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

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

Resolution:
Revised Text:
Actions taken:
March 28, 2005: received issue

Issue 8649: Section: 10.3.1 VariableExpEval (ocl2-rtf)

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

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

Resolution:
Revised Text:
Actions taken:
March 28, 2005: received issue

Issue 8650: Section: 10.3.2 AssociationEndCallExpEval (ocl2-rtf)

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

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

Resolution:
Revised Text:
Actions taken:
March 28, 2005: received issue

Issue 8651: Section: 10.3.2 OperationCallExp (ocl2-rtf)

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

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

Resolution:
Revised Text:
Actions taken:
March 28, 2005: received issue

Issue 8652: Section: 10.3.2 NavigationCallExpEval (ocl2-rtf)

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

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

Resolution:
Revised Text:
Actions taken:
March 28, 2005: received issue

Issue 8653: Section: 10.3.4 OclMessageArgEval (ocl2-rtf)

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

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

Resolution:
Revised Text:
Actions taken:
March 29, 2005: received issue

Issue 8654: Section: 10.3.4 OclMessageArgEval (ocl2-rtf)

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

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

Resolution:
Revised Text:
Actions taken:
March 29, 2005: received issue

Issue 8655: Section: 10.3.4 OclMessageExpEval (ocl2-rtf)

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

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

Resolution:
Revised Text:
Actions taken:
March 29, 2005: received issue

Issue 8656: Section: 10.3.5 (ocl2-rtf)

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

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

Resolution:
Revised Text:
Actions taken:
March 29, 2005: received issue

Issue 8657: Section: 10.4 (ocl2-rtf)

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

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

Resolution:
Revised Text:
Actions taken:
March 29, 2005: received issue

Issue 8658: Section: 10.4.3 IntegerLiteralExpEval (ocl2-rtf)

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

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

Resolution:
Revised Text:
Actions taken:
March 29, 2005: received issue

Issue 8659: Section: 11.2.1 (ocl2-rtf)

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

Last line on page is a sentence fragment

Resolution:
Revised Text:
Actions taken:
March 29, 2005: received issue

Issue 8660: Section: 11.5.1 (ocl2-rtf)

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

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

Resolution:
Revised Text:
Actions taken:
March 29, 2005: received issue

Issue 8661: Section: 11.5.4 (ocl2-rtf)

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

What is the difference in meaning between the definitions of or(b:Boolean): Boolean and xor(b:Boolean): Boolean? or(b:Boolean): Boolean says True if either self or b is true which implies "but not both" which is the ending phrase of the definition of xor(b:Boolean): Boolean.

Resolution:
Revised Text:
Actions taken:
March 29, 2005: received issue

Issue 8665: Section: 11.9.2 sortedBy (ocl2-rtf)

Click here for this issue's archive.
Source: U. S. Geological Survey (Ms. Jane Messenger, jmessenger(at)usgs.gov)
Nature: Clarification
Severity: Minor
Summary:

The restriction to sort the OrderedSet with the lowest value coming first is very restrictive. Sometimes it is beneficial to sort in reverse order. Think about a statement that would allow a > sort order.

Resolution:
Revised Text:
Actions taken:
March 30, 2005: received issue

Issue 8666: Section: 11.9.3 & 11.9.4 (ocl2-rtf)

Click here for this issue's archive.
Source: U. S. Geological Survey (Ms. Jane Messenger, jmessenger(at)usgs.gov)
Nature: Clarification
Severity: Minor
Summary:

Typo - pg 151 change "The standard iterator expression" to "The standard iterator expressions." The reject expression for both Bag and Sequence have "source->select(iterator | not body) on the left side of the equals symbol. Shouldn't the word "iterate" be used instead of "select?" The sortedBy expression is very restrictive if the sort order must always have the lowest value first. A statement that a sort order could be by a > value would be nice.

Resolution:
Revised Text:
Actions taken:
March 30, 2005: received issue

Issue 8667: Section: 1 - 13 (ocl2-rtf)

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

General comments: OCL primitive types do not agree with UML primitive types. Multiplicity symbology for "infinite" is different. UML uses "*" whereas OCL uses "n." Capitalize the word "Boolean" as it is named for the 19th Century mathematicial George Boole. In most places it is capitalized but there are several places where it is not. I hope my comments have not been too annoying. Please consider everything I know about OCL I have learned from reading this document so if my comments don't make a lot of sense, then possibly clarification in the document may be needed.

Resolution:
Revised Text:
Actions taken:
March 30, 2005: received issue

Issue 8789: The spec does not describes the syntax of integer, real or string literals (ocl2-rtf)

Click here for this issue's archive.
Source: France Telecom R&D (Mr. Mariano Belaunde, mariano.belaunde(at)orange.com)
Nature: Uncategorized Issue
Severity:
Summary:

1) The specification does not describes the syntax of integer, real or string literals. 
The specification does not describes the syntax of integer, real or string literals. 
Specifying the syntax and the semantics of basic types will increase the portability 
of OCL programs

Resolution:
Revised Text:
Actions taken:
May 18, 2005: received issue

Issue 8808: Container of additional operations (ocl2-rtf)

Click here for this issue's archive.
Source: France Telecom R&D (Mr. Mariano Belaunde, mariano.belaunde(at)orange.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
May 25, 2005: received issue

Issue 8902: Section 8.3.9 of the final Adopted Version of the OCL 2.0 Spec (ocl2-rtf)

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

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

Resolution:
Revised Text:
Actions taken:
June 7, 2005: received issue

Discussion:

The 'asSet' operation is predefined for collections but the 'atPre' is not at all a predefined operation. However fixing this issue implies re-synchronizing chapter 9 (concrete syntax) with chapter 8 (abstract syntax) which requires extra time. Deferred

Issue 10439: Recommendations re ptc/2005-06-06 (ocl2-rtf)

Click here for this issue's archive.
Source: NIST (Mr. Peter Denno, peter.denno(at)nist.gov)
Nature: Uncategorized Issue
Severity:
Summary:

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


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


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

Resolution: (AS INITIALLY VOTED, DO NOT APPLY SINCE DEFERRED) At the end of 9.2.1 A practical grammar that can be realised by an LALR(1) parser is provided in Section 9.7. Add Sections 9.7 9.7 OCL Grammars The grammars presented in this Section are suitable for implementation by an LALR(1) parser generator such as yacc, bison or LPG after minor spelling adjustments to accommodate toolspecific characteristics. This grammar does not uniquely determine a Concrete Syntax; in many cases a number of alternative Concrete Syntaxes are identified that require disambiguation in accordance with the rules for each candidate Concrete Syntax presented in Section 9.3. The definitions of the IDENTIFIER, INTEGER_LITERAL, REAL_LITERAL, and STRING_LITERAL terminals may be found in Section 9.3 under simpleNameCS, IntegerLiteralExpCS, RealLiteralExpCS and StringLiteralExpCS. 9.7.1 Essential OCL Grammar The Essential OCL grammar defines only those concepts necessary for Essential OCL. The additional concepts for Complete OCL are added by the grammar in Section 9.7.2. Reserved keywords cannot be used as names in any context, unless enclosed by underscoreprefixed single quotes. Restricted keywords can only be used as names following a package or classifier qualification, unless enclosed by underscore-prefixed single quotes. -- Reserved keywords and implies not or xor if then else endif let in false true null invalid self -- Restricted keywords Bag Collection OrderedSet Sequence Set Tuple Boolean Integer Real String UnlimitedNatural OclAny OclInvalid OclVoid -- Terminals INTEGER_LITERAL REAL_LITERAL STRING_LITERAL ----------------------------------------------------------------------- -- Names ----------------------------------------------------------------------- reservedKeyword ::= and reservedKeyword ::= else reservedKeyword ::= endif reservedKeyword ::= if reservedKeyword ::= implies reservedKeyword ::= in reservedKeyword ::= let reservedKeyword ::= not reservedKeyword ::= or reservedKeyword ::= then reservedKeyword ::= xor tupleKeywordCS ::= Tuple reservedKeywordCS ::= reservedKeyword restrictedKeywordCS ::= CollectionTypeIdentifierCS restrictedKeywordCS ::= primitiveTypeCS restrictedKeywordCS ::= oclCS restrictedKeywordCS ::= tupleKeywordCS selfKeywordCS ::= self simpleNameCS ::= IDENTIFIER unreservedSimpleNameCS ::= simpleNameCS unreservedSimpleNameCS ::= restrictedKeywordCS pathNameCS ::= simpleNameCS pathNameCS ::= pathNameCS '::' unreservedSimpleNameCS ----------------------------------------------------------------------- -- Types ----------------------------------------------------------------------- primitiveTypeCS ::= Boolean primitiveTypeCS ::= Integer primitiveTypeCS ::= Real primitiveTypeCS ::= String primitiveTypeCS ::= UnlimitedNatural oclTypeCS ::= OclAny oclTypeCS ::= OclInvalid oclTypeCS ::= OclVoid CollectionTypeIdentifierCS ::= Set CollectionTypeIdentifierCS ::= Bag CollectionTypeIdentifierCS ::= Sequence CollectionTypeIdentifierCS ::= Collection CollectionTypeIdentifierCS ::= OrderedSet typeCS ::= primitiveTypeCS typeCS ::= oclTypeCS typeCS ::= pathNameCS typeCS ::= collectionTypeCS typeCS ::= tupleTypeCS collectionTypeCS ::= CollectionTypeIdentifierCS '(' typeCS ')' tupleTypeCS ::= Tuple '(' tupleTypePartsCSopt ')' tupleTypePartsCSopt ::= $empty tupleTypePartsCSopt ::= tupleTypePartsCS tupleTypePartsCS ::= typedUninitializedVariableCS tupleTypePartsCS ::= tupleTypePartsCS ',' typedUninitializedVariableCS ----------------------------------------------------------------------- -- Declarations ----------------------------------------------------------------------- untypedUninitializedVariableCS ::= simpleNameCS typedUninitializedVariableCS ::= untypedUninitializedVariableCS ':' typeCS untypedInitializedVariableCS ::= untypedUninitializedVariableCS '=' OclExpressionCS typedInitializedVariableCS ::= typedUninitializedVariableCS '=' OclExpressionCS initializedVariableCS ::= untypedInitializedVariableCS initializedVariableCS ::= typedInitializedVariableCS uninitializedVariableCS ::= untypedUninitializedVariableCS uninitializedVariableCS ::= typedUninitializedVariableCS VariableDeclarationCS ::= untypedUninitializedVariableCS VariableDeclarationCS ::= untypedInitializedVariableCS VariableDeclarationCS ::= typedUninitializedVariableCS VariableDeclarationCS ::= typedInitializedVariableCS ----------------------------------------------------------------------- -- Literals ----------------------------------------------------------------------- -- EnumLiteralExpCS is parsed as a PropertyCallExpCS[C] -- LiteralExpCS ::= EnumLiteralExpCS LiteralExpCS ::= CollectionLiteralExpCS LiteralExpCS ::= TupleLiteralExpCS LiteralExpCS ::= PrimitiveLiteralExpCS LiteralExpCS ::= TypeLiteralExpCS CollectionLiteralExpCS ::= CollectionTypeIdentifierCS '{' CollectionLiteralPartsCSopt '}' CollectionLiteralExpCS ::= collectionTypeCS '{' CollectionLiteralPartsCSopt '}' CollectionLiteralPartsCSopt ::= $empty CollectionLiteralPartsCSopt ::= CollectionLiteralPartsCS CollectionLiteralPartsCS ::= CollectionLiteralPartCS CollectionLiteralPartsCS ::= CollectionLiteralPartsCS ',' CollectionLiteralPartCS CollectionLiteralPartCS ::= CollectionRangeCS CollectionLiteralPartCS ::= OclExpressionCS CollectionRangeCS ::= OclExpressionCS '..' OclExpressionCS PrimitiveLiteralExpCS ::= IntegerLiteralExpCS PrimitiveLiteralExpCS ::= RealLiteralExpCS PrimitiveLiteralExpCS ::= StringLiteralExpCS PrimitiveLiteralExpCS ::= BooleanLiteralExpCS PrimitiveLiteralExpCS ::= UnlimitedNaturalLiteralExpCS PrimitiveLiteralExpCS ::= InvalidLiteralExpCS PrimitiveLiteralExpCS ::= NullLiteralExpCS TupleLiteralExpCS ::= Tuple '{' TupleLiteralPartsCS '}' TupleLiteralPartsCS ::= initializedVariableCS TupleLiteralPartsCS ::= TupleLiteralPartsCS ',' initializedVariableCS IntegerLiteralExpCS ::= INTEGER_LITERAL RealLiteralExpCS ::= REAL_LITERAL StringLiteralExpCS ::= STRING_LITERAL StringLiteralExpCS ::= StringLiteralExpCS STRING_LITERAL BooleanLiteralExpCS ::= true BooleanLiteralExpCS ::= false UnlimitedNaturalLiteralExpCS ::= '*' InvalidLiteralExpCS ::= invalid NullLiteralExpCS ::= null -- unqualified pathNameCS is parsed as SimpleNameExpCS -- qualified pathNameCS is parsed as PropertyCallExpCS[C] TypeLiteralExpCS ::= primitiveTypeCS TypeLiteralExpCS ::= oclTypeCS TypeLiteralExpCS ::= collectionTypeCS TypeLiteralExpCS ::= tupleTypeCS ----------------------------------------------------------------------- -- Calls ----------------------------------------------------------------------- CallExpCS ::= FeatureCallExpCS CallExpCS ::= LoopExpCS LoopExpCS ::= IteratorExpCS LoopExpCS ::= IterateExpCS -- IteratorExpCS[A.1] is parsed as OperationCallExpCS[B] IteratorExpCS ::= -- [A.2] primaryExpCS '->' simpleNameCS '(' uninitializedVariableCS '|' OclExpressionCS ')' IteratorExpCS ::= -- [A.3.1] primaryExpCS '->' simpleNameCS '(' simpleNameCS ',' uninitializedVariableCS '|' OclExpressionCS ')' IteratorExpCS ::= -- [A.3.2] primaryExpCS '->' simpleNameCS '(' typedUninitializedVariableCS ',' uninitializedVariableCS '|' OclExpressionCS ')' -- IteratorExpCS[B] is parsed as OperationCallExpCS[C] -- IteratorExpCS[C] is parsed as AssociationClassCallExpCS[A.1] -- IteratorExpCS[D] is parsed as AssociationClassCallExpCS[A] -- IteratorExpCS[E] is parsed as AssociationClassCallExpCS[A] IterateExpCS ::= primaryExpCS '->' simpleNameCS '(' typedInitializedVariableCS '|' OclExpressionCS ')' IterateExpCS ::= primaryExpCS '->' simpleNameCS '(' uninitializedVariableCS ';' typedInitializedVariableCS '|' OclExpressionCS ')' FeatureCallExpCS ::= OperationCallExpCS FeatureCallExpCS ::= PropertyCallExpCS FeatureCallExpCS ::= NavigationCallExpCS -- OperationCallExpCS[A] is realized by the infix OclExpressionCS productions OperationCallExpCS ::= -- [B.1] primaryExpCS '->' simpleNameCS '(' ')' OperationCallExpCS ::= -- [B.2],IteratorExpCS[A.1] primaryExpCS '->' simpleNameCS '(' OclExpressionCS ')' OperationCallExpCS ::= -- [B.3.1] primaryExpCS '->' simpleNameCS '(' notNameExpressionCS ',' argumentsCS ')' OperationCallExpCS ::= -- [B.3.2] primaryExpCS '->' simpleNameCS '(' simpleNameCS ',' argumentsCS ')' OperationCallExpCS ::= -- [C],[E],IteratorExpCS[B] primaryExpCS '.' simpleNameCS isMarkedPreCSopt '(' argumentsCSopt ')' OperationCallExpCS ::= -- [D],[F],[G.1] simpleNameCS isMarkedPreCSopt '(' argumentsCSopt ')' OperationCallExpCS ::= -- [G.2] pathNameCS '::' unreservedSimpleNameCS '(' argumentsCSopt ')' -- OperationCallExpCS[H] is realized by the prefix OclExpressionCS productions OperationCallExpCS ::= -- [I],[J] primaryExpCS '.' pathNameCS '::' unreservedSimpleNameCS isMarkedPreCSopt '(' argumentsCSopt ')' -- NavigationCallExpCS ::= PropertyCallExpCS -- parsed as FeatureCallExpCS NavigationCallExpCS ::= AssociationClassCallExpCS -- PropertyCallExpCS[A] is parsed as AssociationClassCallExpCS[A.1] -- PropertyCallExpCS[B.1] is parsed as a SimpleNameExpCS -- PropertyCallExpCS[B.2] is parsed as a AssociationClassCallExpCS[B.1] PropertyCallExpCS ::= -- [C] excluding [B] pathNameCS '::' unreservedSimpleNameCS isMarkedPreCSopt PropertyCallExpCS ::= -- [D] primaryExpCS '.' pathNameCS '::' unreservedSimpleNameCS isMarkedPreCSopt AssociationClassCallExpCS ::= -- [A.1],PropertyCallExpCS[A],IteratorExpCS[C,D,E] primaryExpCS '.' simpleNameCS isMarkedPreCSopt AssociationClassCallExpCS ::= -- [A.2],IteratorExpCS[D,E] primaryExpCS '.' simpleNameCS '[' argumentsCS ']' isMarkedPreCSopt -- AssociationClassCallExpCS[B.1.1] parsed as SimpleNameExpCS -- AssociationClassCallExpCS[B.1.2] is added by Complete OCL AssociationClassCallExpCS ::= -- [B.2] simpleNameCS '[' argumentsCS ']' isMarkedPreCSopt isMarkedPreCSopt ::= $empty argumentsCSopt ::= $empty argumentsCSopt ::= argumentsCS argumentsCS ::= OclExpressionCS argumentsCS ::= argumentsCS ',' OclExpressionCS ----------------------------------------------------------------------- -- Expressions ----------------------------------------------------------------------- -- An OclExpressionCS comprising just a SimpleNameCS is kept separate as -- SimpleNameExpCS to avoid ambiguity when parsing "a->b(c,d" until the next -- letter resolves the usage as a two iterator or as a two or more argument -- OperationCallExpCS. -- An OclExpressionCS comprising one or more LetExpCS is kept separate to ensure -- that let is right associative, whereas infix operators are left associative. -- a = 64 / 16 / let b : Integer in 8 / let c : Integer in 4 -- is -- a = (64 / 16) / (let b : Integer in 8 / (let c : Integer in 4 )) OclExpressionCS ::= notNameExpressionCS OclExpressionCS ::= SimpleNameExpCS -- VariableExpCS[.1] simpleNameCS parsed as SimpleNameExpCS VariableExpCS ::= -- [.2] selfKeywordCS SimpleNameExpCS ::= -- AssociationClassCallExpCS[B.1.1], -- PropertyCallExpCS[B],VariableExpCS[.1] simpleNameCS notNameExpressionCS ::= impliesNotNameNotLetCS notNameExpressionCS ::= impliesWithLetCS impliesNotLetCS ::= impliesNotNameNotLetCS impliesNotLetCS ::= SimpleNameExpCS impliesNotNameNotLetCS ::= xorNotNameNotLetCS impliesNotNameNotLetCS ::= impliesNotLetCS implies xorNotLetCS impliesWithLetCS ::= xorWithLetCS impliesWithLetCS ::= impliesNotLetCS implies xorWithLetCS xorNotLetCS ::= xorNotNameNotLetCS xorNotLetCS ::= SimpleNameExpCS xorNotNameNotLetCS ::= orNotNameNotLetCS xorNotNameNotLetCS ::= xorNotLetCS xor orNotLetCS xorWithLetCS ::= orWithLetCS xorWithLetCS ::= xorNotLetCS xor orWithLetCS orNotLetCS ::= orNotNameNotLetCS orNotLetCS ::= SimpleNameExpCS orNotNameNotLetCS ::= andNotNameNotLetCS orNotNameNotLetCS ::= orNotLetCS or andNotLetCS orWithLetCS ::= andWithLetCS orWithLetCS ::= orNotLetCS or andWithLetCS andNotLetCS ::= andNotNameNotLetCS andNotLetCS ::= SimpleNameExpCS andNotNameNotLetCS ::= equalityNotNameNotLetCS andNotNameNotLetCS ::= andNotLetCS and equalityNotLetCS andWithLetCS ::= equalityWithLetCS andWithLetCS ::= andNotLetCS and equalityWithLetCS equalityNotLetCS ::= equalityNotNameNotLetCS equalityNotLetCS ::= SimpleNameExpCS equalityNotNameNotLetCS ::= relationalNotNameNotLetCS equalityNotNameNotLetCS ::= equalityNotLetCS '=' relationalNotLetCS equalityNotNameNotLetCS ::= equalityNotLetCS '<>' relationalNotLetCS equalityWithLetCS ::= relationalWithLetCS equalityWithLetCS ::= equalityNotLetCS '=' relationalWithLetCS equalityWithLetCS ::= equalityNotLetCS '<>' relationalWithLetCS relationalNotLetCS ::= relationalNotNameNotLetCS relationalNotLetCS ::= SimpleNameExpCS relationalNotNameNotLetCS ::= additiveNotNameNotLetCS relationalNotNameNotLetCS ::= relationalNotLetCS '>' additiveNotLetCS relationalNotNameNotLetCS ::= relationalNotLetCS '<' additiveNotLetCS relationalNotNameNotLetCS ::= relationalNotLetCS '>=' additiveNotLetCS relationalNotNameNotLetCS ::= relationalNotLetCS '<=' additiveNotLetCS relationalWithLetCS ::= additiveWithLetCS relationalWithLetCS ::= relationalNotLetCS '>' additiveWithLetCS relationalWithLetCS ::= relationalNotLetCS '<' additiveWithLetCS relationalWithLetCS ::= relationalNotLetCS '>=' additiveWithLetCS relationalWithLetCS ::= relationalNotLetCS '<=' additiveWithLetCS additiveNotLetCS ::= additiveNotNameNotLetCS additiveNotLetCS ::= SimpleNameExpCS additiveNotNameNotLetCS ::= multiplicativeNotNameNotLetCS additiveNotNameNotLetCS ::= additiveNotLetCS '+' multiplicativeNotLetCS additiveNotNameNotLetCS ::= additiveNotLetCS '-' multiplicativeNotLetCS additiveWithLetCS ::= multiplicativeWithLetCS additiveWithLetCS ::= additiveNotLetCS '+' multiplicativeWithLetCS additiveWithLetCS ::= additiveNotLetCS '-' multiplicativeWithLetCS multiplicativeNotLetCS ::= multiplicativeNotNameNotLetCS multiplicativeNotLetCS ::= SimpleNameExpCS multiplicativeNotNameNotLetCS ::= unaryNotNameNotLetCS multiplicativeNotNameNotLetCS ::= multiplicativeNotLetCS '*' unaryNotLetCS multiplicativeNotNameNotLetCS ::= multiplicativeNotLetCS '/' unaryNotLetCS multiplicativeWithLetCS ::= unaryWithLetCS multiplicativeWithLetCS ::= multiplicativeNotLetCS '*' unaryWithLetCS multiplicativeWithLetCS ::= multiplicativeNotLetCS '/' unaryWithLetCS unaryNotLetCS ::= unaryNotNameNotLetCS unaryNotLetCS ::= SimpleNameExpCS unaryNotNameNotLetCS ::= primaryNotNameCS unaryNotNameNotLetCS ::= '-' unaryNotLetCS unaryNotNameNotLetCS ::= not unaryNotLetCS unaryWithLetCS ::= LetExpCS -- OclExpressionCS[D] unaryWithLetCS ::= '-' unaryWithLetCS unaryWithLetCS ::= not unaryWithLetCS primaryExpCS ::= primaryNotNameCS primaryExpCS ::= SimpleNameExpCS primaryNotNameCS ::= CallExpCS -- OclExpressionCS[A] primaryNotNameCS ::= VariableExpCS -- OclExpressionCS[B] primaryNotNameCS ::= LiteralExpCS -- OclExpressionCS[C] -- primaryNotNameCS ::= OclMessageExpCS -- OclExpressionCS[E] is added by Complete OCL primaryNotNameCS ::= IfExpCS -- OclExpressionCS[F] primaryNotNameCS ::= '(' OclExpressionCS ')' IfExpCS ::= if OclExpressionCS then OclExpressionCS else OclExpressionCS endif LetExpCS ::= let letVariablesCS in OclExpressionCS letVariablesCS ::= typedInitializedVariableCS letVariablesCS ::= letVariablesCS ',' typedInitializedVariableCS 9.7.2 Complete OCL Grammar The Complete OCL grammar is an addition to the Essential OCL grammar. -- Reserved keywords body context def derive endpackage init inv package post pre static -- Restricted keywords OclMessage ----------------------------------------------------------------------- -- Names ----------------------------------------------------------------------- reservedKeyword ::= body reservedKeyword ::= context reservedKeyword ::= def reservedKeyword ::= derive reservedKeyword ::= endpackage reservedKeyword ::= init reservedKeyword ::= inv reservedKeyword ::= package reservedKeyword ::= post reservedKeyword ::= pre reservedKeyword ::= static unreservedSimpleNameCSopt ::= $empty unreservedSimpleNameCSopt ::= unreservedSimpleNameCS ----------------------------------------------------------------------- -- Types ----------------------------------------------------------------------- oclTypeCS ::= OclMessage typeCSopt ::= $empty typeCSopt ::= typeCS ----------------------------------------------------------------------- -- Calls ----------------------------------------------------------------------- OperationCallExpCS ::= -- [B] primaryExpCS '->' simpleNameCS isMarkedPreCS '(' argumentsCSopt ')' AssociationClassCallExpCS ::= -- [B.1],PropertyCallExpCS[B] simpleNameCS isMarkedPreCS isMarkedPreCS ::= '@' pre isMarkedPreCSopt ::= isMarkedPreCS OclMessageExpCS ::= primaryExpCS '^^' simpleNameCS '(' OclMessageArgumentsCSopt ')' OclMessageExpCS ::= primaryExpCS '^' simpleNameCS '(' OclMessageArgumentsCSopt ')' OclMessageArgumentsCSopt ::= $empty OclMessageArgumentsCSopt ::= OclMessageArgumentsCS OclMessageArgumentsCS ::= OclMessageArgCS OclMessageArgumentsCS ::= OclMessageArgumentsCS ',' OclMessageArgCS OclMessageArgCS ::= '?' OclMessageArgCS ::= '?' ':' typeCS OclMessageArgCS ::= OclExpressionCS ----------------------------------------------------------------------- -- Expressions ----------------------------------------------------------------------- primaryNotNameCS ::= OclMessageExpCS ----------------------------------------------------------------------- -- Contexts ----------------------------------------------------------------------- packageDeclarationsCS ::= packageDeclarationCS packageDeclarationsCS ::= packageDeclarationsCS packageDeclarationCS_A packageDeclarationCS ::= packageDeclarationCS_A packageDeclarationCS ::= packageDeclarationCS_B packageDeclarationCS_A ::= package pathNameCS contextDeclsCSopt endpackage packageDeclarationCS_B ::= contextDeclsCS contextDeclsCSopt ::= $empty contextDeclsCSopt ::= contextDeclsCS contextDeclsCS ::= contextDeclCS contextDeclsCS ::= contextDeclsCS contextDeclCS contextDeclCS ::= propertyContextDeclCS contextDeclCS ::= classifierContextDeclCS contextDeclCS ::= operationContextDeclCS propertyContextDeclCS ::= context pathNameCS '::' unreservedSimpleNameCS ':' typeCS initOrDerValuesCS initOrDerValuesCS ::= initOrDerValueCS initOrDerValuesCS ::= initOrDerValuesCS initOrDerValueCS initOrDerValueCS ::= init ':' OclExpressionCS initOrDerValueCS ::= derive ':' OclExpressionCS classifierContextDeclCS ::= context pathNameCS invOrDefsCS classifierContextDeclCS ::= context simpleNameCS ':' pathNameCS invOrDefsCS invOrDefsCS ::= invOrDefCS invOrDefsCS ::= invOrDefsCS invOrDefCS invOrDefCS ::= inv unreservedSimpleNameCSopt ':' OclExpressionCS invOrDefCS ::= def unreservedSimpleNameCSopt ':' defExpressionCS invOrDefCS ::= static def unreservedSimpleNameCSopt ':' defExpressionCS defExpressionCS ::= typedUninitializedVariableCS '=' OclExpressionCS defExpressionCS ::= operationCS1 '=' OclExpressionCS operationContextDeclCS ::= context operationCS2 prePostOrBodyDeclsCS prePostOrBodyDeclsCS ::= prePostOrBodyDeclCS prePostOrBodyDeclsCS ::= prePostOrBodyDeclsCS prePostOrBodyDeclCS prePostOrBodyDeclCS ::= pre unreservedSimpleNameCSopt ':' OclExpressionCS prePostOrBodyDeclCS ::= post unreservedSimpleNameCSopt ':' OclExpressionCS prePostOrBodyDeclCS ::= body unreservedSimpleNameCSopt ':' OclExpressionCS operationCS1 ::= simpleNameCS '(' parametersCSopt ')' ':' typeCSopt operationCS2 ::= pathNameCS '::' unreservedSimpleNameCS '(' parametersCSopt ')' ':' typeCSopt parametersCSopt ::= $empty parametersCSopt ::= parametersCS parametersCS ::= VariableDeclarationCS parametersCS ::= parametersCS ',' VariableDeclarationCS Disposition: Deferred NOTE: RESOLVED in Ballot 1 but DEFERRED by disposition of issue 15761
Revised Text:
Actions taken:
November 2, 2006: received issue

Discussion:

Good suggestion. Deferred since such grammar need to be defined carefully. The OCL 2.1 specification provides only a partial and ambiguous grammar some
of whose problems may be resolved by application of the disambiguating rules.
Provision of a complete unambiguous grammar requires the clear semantics for
reserved words that may be found in Issue 14583. Resolution of reserved word
semantics highlights a number of other problems.
The Essential OCL and Complete OCL grammars presented here therefore
assume adoption of the following resolutions:
Issue 12953: Collection Literals with explicit element types
Issue 14196: Integration of UnlimitedNaturalLiteralExpCS Issue 14236: Integration of InvalidLiteralExpCS and NullLiteralExpCS
Issue 14237: CollectionRangeCS separator is DotDot.
Issue 14357: Token Concrete Syntaxes: String Literals may be concatenated.
Issue 14582: Precedence and Associativity.
Issue 14583: Reserved Words.
false, invalid, null, self, true are reserved words.
Boolean, Integer, Real, String, UnlimitedNatural, OclAny, OclInvalid, OclVoid,
Bag, Collection, OrderedSet, Sequence, Set, Tuple are restricted words.
body, context, def, derive, endpackage, init, inv, package, post, pre, static are
reserved words in Complete OCL only.
OclMessage is a restricted word in Complete OCL only.
Issue 14584: TupleLiteralExp part type inference.
Issue 14585: TypeLiteralExpCS is introduced.
Issue 14586: named-self classifierContextDeclCS is supported.
Issue 14587: attrOrAssocContextCS is renamed.
Practical Grammar
The LALR(1) grammar in the revised text replaces the unrealisable
OperationCallExpCS[A] and OperationCallExpCS[H] by a clear grammar in which
precedence and associativity are explicit. Atomic terms such as () and if...endif
are primaryExpCS. The awkward let..in.. is both high and low precedence. All
infix operators are left associative.
The OCL 2.1 grammar is difficult to parse because the presentation in Section
9.3 contains
• obvious conflicts (PropertyCallExpCS is directly a FeatureCallExpCS and
indirectly a FeatureCallExpCS as a NavigationCallExpCS)
• subtle conflicts (EnumLiteralExpCS is a PropertyCallExpCS[C])
• no precedence or associativity grammar
• no identifier or string grammar • unclear reserved word policy
Once these problems are resolved the grammar remains difficult to parse without
semantic information because
• LetExpCS is both high and low precedence
• OperationCallExpCS[B] and IteratorExpCS[A] require a lookahead to the
"ß" token to resolve "c" as a VariableDeclarationCS or a VariableExpCS in
"a->b(c,dß".
These problems are resolved by expressing the infix and prefix grammar to
define precedence and associativity, while allowing use of a simpleNameCS in
the awkward overlap between OperationCallExpCS[B] and IteratorExpCS[A].

Issue 10561: inclusion of Regular Expression support (ocl2-rtf)

Click here for this issue's archive.
Source: SAIC (Mr. Jim Bonang, james.j.bonang(at)saic.com)
Nature: Enhancement
Severity: Significant
Summary:

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

Resolution:
Revised Text:
Actions taken:
January 3, 2007: received issue

Discussion:

Good suggestion. It can be done by augmenting the standard library.
Deferred for timing reasons.


Disposition:	Deferred

Issue 10786: Naming of Constraints in OCL (02) (ocl2-rtf)

Click here for this issue's archive.
Source: EMC (Mr. George Ericson, ericson_george(at)emc.com)
Nature: Uncategorized Issue
Severity:
Summary:

OCL Specification, v2.0

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

"context" <contextdeclaration> "inv" <constraintname> ":" ...
 
The document does not seem to define this capability formally and I would like to see it also applied to pre, post, body, init, and derived constraints.

Resolution:
Revised Text:
Actions taken:
February 23, 2007: received issue

Issue 10787: OCL Collections applied to Properties (ocl2-rtf)

Click here for this issue's archive.
Source: EMC (Mr. George Ericson, ericson_george(at)emc.com)
Nature: Uncategorized Issue
Severity:
Summary:

OCL Specification, v2.0
 
The specification does not make it clear how to apply collection operations to properties.
 
For instance, assume
 
class A {
    int x[];
}
 
It appears that an invariant constraint that asserts that one of the entries in A.x must be 5 might be
 
context A
inv self.x->exists( p | p=5 )
 
However, this is a guess and does not appear to be entirely justified by the text.

Resolution:
Revised Text:
Actions taken:
February 23, 2007: received issue

Issue 12452: Recursivity is not explicitly addressed with examples (ocl2-rtf)

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

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

Resolution:
Revised Text:
Actions taken:
May 14, 2008: received issue

Discussion:

Deferred for timing reasons. In order to introduce the suggested examples in Section 7 some verification will be needed.

Disposition:	Deferred

Issue 12453: Mismatch between the definition of operators in, e.g., Section 11.7.1 and i (ocl2-rtf)

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

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

Resolution:
Revised Text:
Actions taken:
May 14, 2008: received issue

Discussion:

For timing issues all issues concerning Annex A are deferred.

Disposition:	Deferred

Issue 12456: Errors in examples (ocl2-rtf)

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

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

Resolution:
Revised Text:
Actions taken:
May 14, 2008: received issue

Issue 12468: Section: A/2.5.5 Collection Operations - Table A.3 (ocl2-rtf)

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

Table A.3 has several problems in the "Semantics" column: Row 2: Besides being hard to read, the expression seems to be wrong. There is no operator between the C and capital pi (which I assume to be a Cartesian product), and the "is not an element of" seems like it couldn't be right. Maybe I'm at fault, but I can't make any sense of it. Row 4: There's no entry here. How about " C 'intersect' {v} = Ø" Row 6: The operator should be intersection, not Cartesian product, that is the capital pi should is the wrong symbol here. Rows 8 & 9: First, there shouldn't be anything in row 9's semantics column since the other columns are all blank. Are the c's supposed to be the capital C's? I can't make any sense of the expression, which could be my problem, but I don't think so.

Resolution:
Revised Text:
Actions taken:
May 14, 2008: received issue

Issue 12494: Section: A.3.2.2 Syntax and Semantics of Postconditions (02) (ocl2-rtf)

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

In the paragraph before Definition A.32 you will find, "... ppre = (spre, ßpre) describing a system state and variable assignments before the execution ...." Originally I had taken the ß's to be sets of assignments. Then I noticed that the text before this point refers to it repeatedly as an "assignment" in the singular. Now, here, and also in the middle of page 205 (which says, "ß' := ß{p1/I[[ e1 ]](r), . . . , pn /I[[ en ]](r)}.") the indication is that beta is multiple of assignments. Consistency would be very desirable.

Resolution:
Revised Text:
Actions taken:
May 15, 2008: received issue

Discussion:

Deferred for timing reasons.
Disposition:	Deferred

Issue 12495: Section: A.3.2.2 Syntax and Semantics of Postconditions (03) (ocl2-rtf)

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

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

Resolution:
Revised Text:
Actions taken:
May 15, 2008: received issue

Discussion:

Deferred for timing reasons.

Disposition:	Deferred

Issue 12496: Section: A.3.2.2 Syntax and Semantics of Postconditions (04) (ocl2-rtf)

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

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

Resolution:
Revised Text:
Actions taken:
May 15, 2008: received issue

Discussion:

Deferred for timing reasons.

Disposition:	Deferred

Issue 12562: CMOF serializations of its metamodels not published (ocl2-rtf)

Click here for this issue's archive.
Source: Zeligsoft, Inc. (Mr. Christian W. Damus, nobody)
Nature: Clarification
Severity: Significant
Summary:

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

Resolution:
Revised Text:
Actions taken:
July 5, 2008: received issue

Discussion:

Good suggestion. It cannot be treated in this ballot due to timing constraints.

Disposition:	Deferred

Issue 12581: OCL 2.0 8.2 Collection Type name distinguishability (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

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


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


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

Resolution:
Revised Text:
Actions taken:
July 19, 2008: received issue

Discussion:

Good remark. Now for the resolution we have the option to explicitly consider that the distinguishability rule does not apply for collections or follow the reporter suggestion, which could have some impact in pre-existing written OCL. I suggest to defer so that we take more time to examine the options.

Disposition:	Deferred

Issue 12795: Special Types violate UML Generalization Semantics (ocl2-rtf)

Click here for this issue's archive.
Source: Zeligsoft, Inc. (Mr. Christian W. Damus, nobody)
Nature: Clarification
Severity: Minor
Summary:

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

Resolution:
Revised Text:
Actions taken:
August 24, 2008: received issue

Discussion:

The issue requires some further analysis. Deferred for timing reasons.

Disposition:	Deferred

Issue 12854: OCL 2.0 Issue: References to Additional Attributes and Operations (ocl2-rtf)

Click here for this issue's archive.
Source: Zeligsoft, Inc. (Mr. Christian W. Damus, nobody)
Nature: Uncategorized Issue
Severity:
Summary:

Re: OCL 2.0 formal/06-05-01


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


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


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


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

Resolution:
Revised Text:
Actions taken:
September 14, 2008: received issue

Discussion:

The solution suggested by the reporter as recognized by him is not satisfactory. A more clean "conceptual" solution would be to allow OCL define modules (package) that extend the metamodels (as it works in QVT).
Some further examination is needed of this issue to find the most appropriate solution. 

Disposition:	Deferred

Issue 12952: Use of simple quotes and double quotes in strings (ocl2-rtf)

Click here for this issue's archive.
Source: France Telecom R&D (Mr. Mariano Belaunde, mariano.belaunde(at)orange.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
October 10, 2008: received issue

Discussion:

In fact simple quotes are used in OCL for introducing strings, so we guess the request is to allow use of double quotes as an option (like in Javascript). This issue requires some further analysis so I suggest to defer.

Disposition:	Deferred

Issue 13057: Section: 7.5.15 (ocl2-rtf)

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

Although it is clear that using a constructor to write an object to the system being modelled breaks the property of being side-effect free, it would be useful to return new objects as a result of the query functionality of OCL. It is possible to create a new Tuple for return from a function. For example: def: newDate1() : TupleType {day:Integer, month:Integer, year:Integer} = Tuple{day=10, month=12, year=1950}; It would be useful to have a similar way to generate a query result, but with a complex data type instead of a Tuple. For example: def: newDate2() : Date = Date{day=10, month=12, year=1950}; Rather than write this object to the model under query, it would only be returned as a query result so, under these circumstances, would not break the property of being side-effect free. This feature would be extremely useful to the HL7 GELLO project, which works with data models defined in absense of defined methods or constructors. If this feature were to only apply to classes marked in some way to guarantee they have no side-effects from construction then that would remain useful.

Resolution:
Revised Text:
Actions taken:
November 5, 2008: received issue

Discussion:

Resolution of this issue requires some extra analysis.
Disposition:	Deferred

Issue 13225: Redundant CollectionLiteralExp::kind complicates collection type extension (ocl2-rtf)

Click here for this issue's archive.
Source: Borland Software Corporation (Mr. Radek Dvorak, nobody)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
January 8, 2009: rewceived issue

Discussion:

The information CollectionLiteralExp::kind is effectively redundant since in theory it can be computed by inspecting the type information. I guess the 'kind' attribute was introduced to facilitate "very lazy" type instantiation (like not building the type associated with the tuple literal). One possible option, instead of removing the attribute, could be to state it is optional.
I suggest deferring the resolution of this issue to give more time to people to discuss on the resolution proposal.

Disposition:	Deferred

Issue 14200: OCL 2.0 Inadequate Headings and PDF index (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

The OCL 2.0 specification would be much easier to read if:


1) The PDF had a full set of titles visible in the bookmarks:


8.3.*, Annex A.2 , Annex B and Index are missing completely.


A.1 and A.3 apppear as subsections of 13.3.


2) There are a number of large sections such as 8.3.*, 9.3 and 10.4 with unnumbered headings for each AS or CS class.
[11.5 is much better in this respect.]


These are not in alphabetical order, not page aligned and not particularly distinct.


It would be helpful to


a) give them numbers so that they appear in the Bookmarks and are more distinct.
b) put them in alphabetical order.
[c) consider page aligning them.]


[It would be good if the index was much more comprehensive too.


e.g "at", "null", "any", "iterator", "UnlimitedNatural" ...]

Resolution:
Revised Text:
Actions taken:
August 22, 2009: received issue

Issue 14225: Set operations for OrderedSet (ocl2-rtf)

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

MDT OCL implementation has assumed that OrderedSet is a subtype of Set. It has become clear (11.6.3) that this assumption was erroneous. As a result, operations which are defined on Sets in the standard library (like including, excluding, intersection, union, etc.) must be undefined on OrderedSet. However, many clients (including the ones of Operational QVT) have already written code relying on this behaviour (i.e. considering that OrderedSet is a subtype of Set, they used operations like including()). It would be very helpful to define such operations on OrderedSet. It would be also important to define these counterpart operations so that they would keep the order of the elements of the initial OrderedSet, e.g:


including(object : T) : OrderedSet(T) 


The OrderedSet containing all elements of self plus object added as the last element.

post: result = self.append(object)

Resolution:
Revised Text:
Actions taken:
August 27, 2009: received issue

Issue 14237: OCL 2.0 and 2.1 Section 9.3 CollectionRangeCS incorrect operator spelling (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

The definition of the CollectionRangeCS grammar is


CollectionRangeCS ::= OclExpressionCS[1] ‘,’ OclExpressionCS[2]


but everywhere else the operator is '..'


Suggest change to


CollectionRangeCS ::= OclExpressionCS[1] ‘..’ OclExpressionCS[2]

Resolution:
Revised Text:
Actions taken:
August 29, 2009: received issue

Discussion:

Issue 14576: OCL 2.1 11.7: Clarifying Collection Well-formedness rules (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

The discussion of Issue 12953 suggests that two members of the RTF agreed that is unclear
what T in e.g Set's including(Object : T) means.


The first paragraph of Section 11.6 makes clear that the intent of the specification applies to e.g. Set(T)  and
so the well-formedness rules in 11.7 refer to e.g. Set(T)::including(Object: T), so T is the known element
type of the collection. It is therefore a static error to attempt to invoke Set(T) including for an object
incompatible with the known element type T.


It would be helpful for the Section headings in 11.7 to have a (T) appended so that the 11.6 specification
of T was clearly carried over from 11.6 to 11.7. e.g.


Replace


11.7.1 Collection


by


11.7.1 Collection(T)

Resolution:
Revised Text:
Actions taken:
October 26, 2009: received issue

Issue 14577: OCL 2.1 11.7 Inflexible Collection operation signatures (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

The Collection(T)::product(c2 : Collection(T2))


signature carefully uses T2 to distinguish self and argument element types.


The same distinction is missing from


Collection(T)::"="(c : Collection(T))
Collection(T)::"<>"(c : Collection(T))
Collection(T)::includesAll(c : Collection(T))
Collection(T)::excludesAll(c : Collection(T))
Set(T)::union(s : Set(T))
Set(T)::union(b : Bag(T))


etc etc


The current definition makes at least one of


Set{1.0}->excluding(1.0) = Set{1}->excluding(1)
Set{1}->excluding(1) = Set{1.0}->excluding(1.0)


invalid through lack of a suitable collection operation.


For some operations, such as union, a T2 conforms to T well-formedness constraint is appropriate,
but for others, such as removeAll, T2 and T can be independent.

Resolution:
Revised Text:
Actions taken:
October 26, 2009: received issue

Issue 14591: OCL 2.1 12 Definition Accessibility Semantics (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

Given the following:

context MyClass
def : isaMethod() : Boolean =
    let Collection(Operation) myOperations = oclType().oclAsType(Class).ownedOperations()
    in myOperations->exists(name = 'isaMethod')

is the value of isaMethod() true or false?

This is a more fundamental way of looking at the AST serializability problem in Issue 12854. (The suggested referredDefinition : Constraint [0..1] will not work because there may be 3 operation constraints and two property constraints.)

isaMethod() = false: OCL defininitions are not first class features and so there is no need to support their serialization.

isaMethod() = true: OCL definitions do as implied by Section 12.5 and provide reusable sub-expressions that can be used in an identical way to an atribute or operation.

It seems that an OCL evaluation needs to be defined in the following way.

Phase 1. Load MOF/UML meta-models and OCL contributions
Phase 2: Merge OCL definitions into MOF/UML meta-models
Phase 3: Execute the OCL to support queries/invariants/... on models

Phase 2 solves 12854 by requiring a merged meta-model to reify all definitions.

How the merged model is serialized is an implementation issue

Resolution:
Revised Text:
Actions taken:
October 31, 2009: received issue

Discussion:

Issue 14592: OCL 2.1 12 Definition Referencability Semantics (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

The absence of synthesized and inherited attributes in 12.2 makes it unclear how an environment is maintained and so makes it unclear whether OCL supports forward and/or backward references.

Presumably both forward and backward references are allowed, so a two phase behaviour is needed to enter all definition names in the environment(s) in phase 1 so that they are visible for lookup in phase 2.

Resolution:
Revised Text:
Actions taken:
October 31, 2009: received issue

Discussion:

Issue 14593: OCL 2.1 12 UML alignment (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

12.1, 12.2 refer to UML 1.4.

12.1.1, 12.9, 12.12 defers until UML 2.0 is defined.

12.5, 12.8 uses Attribute and AssociationEnd rather than Property

12.5.1[1], 12.6.1[1], 12.7.1[1], 12.7.3[1] make use of self.constraint.stereotype.name. Constraint has
keywords rather than stereotypes

Resolution:
Revised Text:
Actions taken:
October 31, 2009: received issue

Discussion:

Issue 14594: OCL 2.1 12 Definition uses LetExp (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

12.5 define a definition body as one or more LetExps. No example wraps the expression as a LetExp.
Is this an obsolete specification or an unobserved AST structural constraint?

12.5 defines synthesis of a variable or function, but fails to distinguish these from the equivalent property or operation

Resolution:
Revised Text:
Actions taken:
October 31, 2009: received issue

Discussion:

Issue 14595: OCL 2.1 12 Inconsistencies (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

12.12: getClassifier and getPackage in text, but findClassifier and findPackage in signatures

Resolution:
Revised Text:
Actions taken:
October 31, 2009: received issue

Issue 14596: OCL 2.1 12 Essential MOF support (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

12: Why no applicability to Essential MOF models? 

Although EMOF::Operation has no precondition feature, there is no problem in an operationContextDecl imposing a truth upon the operation.

Similarly, if Initial value and Derived values are defined as Constraints in the same way as PreConditions, then the propertyContextDecl can constrain EMOF by imposing a truth upon the Property.default : String even though String is not an Expression

Resolution:
Revised Text:
Actions taken:
October 31, 2009: received issue

Issue 14597: OCL 2.1 12 Typos (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

12.12 para 3 "OCl" for "OCL".

12.8 para 1 last sentence, 12.9 para 1 last sentence; both are unreadable.

12.12.2 No [B] rule

12.12.1/12.12.2 contextDeclCS/contextDeclarationCS

Resolution:
Revised Text:
Actions taken:
October 31, 2009: received issue

Discussion:

Issue 14598: OCL 2.1 12 Incompleteness (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

12.5.1[3], 12.6.1[2], 12.7.1[2], 12.8.1[2] are TBD.

Resolution:
Revised Text:
Actions taken:
October 31, 2009: received issue

Discussion:

Issue 14599: OCL 2.1 12 Documents (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

12.2 defines a syntax for a standalone OCL document, but provides no mechanism to assist an implementation in locating packages or to partition into multiple reusable documents.

a) Suggest addition of an ImportDeclarationCS 

ImportDeclarationCS ::= import StringLiteralExpCS

where StringLiteralExpCS is a URI whose MOF/UML model content an implementation should make visible within the root environment.

import is a new reserved word.

b) Suggest addition of an IncludeDeclarationCS 

IncludeDeclarationCS ::= include StringLiteralExpCS

where StringLiteralExpCS is a URI whose OCL document content an implementation should interpret (at most once) before proceeding.

include is a new reserved word.

c) Suggest addition of an OclDocumentCS

OclDocumentCS ::= (ImportDeclarationCS)* (IncludeDeclarationCS | PackageDeclarationCS[A])*

d) Suggest an OclPackage to own the Constraints for each Package and bypass the problem that Constriants do not have distinguishable names as required by Package content.

Resolution:
Revised Text:
Actions taken:
October 31, 2009: received issue

Discussion:

Issue 14639: OCL 2.1 Loop iterators are not ordered and other inconsistencies (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

The iterators of LoopExp and LoopExpEval are not ordered, but the well-formedness constraints on them use ->at() which is only available for ordered collection. Usage of the AST property is subject to a variety of spelling, ordering and multiplicity inconsistencies. 
Section 7.6.3 and 7.6.4 define extended variants of forAll and exists that have two iterators.

Figure 8.2 and Figure 13.3 show an unordered * multiplicity for LoopExp.iterator. The positioning of the VariableExp.referredVariable 0..1 multiplicity makes the diagram easy to mis-read.

Section 8.3.1 LoopExp defines iterator as "The iterator variables. These variables are, each in its turn, " implying an ordered collection.

Section 8.3.7 LoopExp [2] and [3] use iterator->forAll implying a collection.

Section 9.3 IteratorExpCS synthesized attributes use iterators->at(1) and at(2) requiring an ordered collection.

Section 9.3 IterateExpCS concrete syntax supports at most one iterator and one accumulator.

Section 9.3 IterateExpCS synthesized attributes use iterator.initExpression requiring a non-collection.

Figure 10.7 shows LoopExpEval.iterators as unordered 1..n.

Section 10.3.1 LoopExpEval defines iterators as "The names of the iterator variables".

Section 10.3.7 IterateExpEval [1] uses iterators->at(1) and iterators->at(2) implying an ordered collection with upper bound 2. 

Section 10.3.7 LoopExpEval [1] has a two way if = 1 else, implying the upper bound is 2. 

Section 10.3.7 LoopExpEval [3] uses iterators->at(1) and iterators->at(2) implying an ordered collection with upper bound 2.

Section 11.9.1 defines the mapping of forAll to iterate for multiple iterators, but IterateExpCS only supports a single iterator.


The above suggests that the specification should consistently treat iterators as having a 1..2 {ordered} multiplicity.

Resolution:
Revised Text:
Actions taken:
November 15, 2009: received issue

Issue 14642: OCL 2.1 13.2 Reflection in OCL meta-models (correction to Issue 1 2951) (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

13.1 states that "EssentialOCL is the package exposing the minimal OCL
required to work with EMOF. EssentialOcl depends on the
EMOF Package."


13.1 states that "For convenience, because BasicOCL (respectively
EssentialOCL) is - conceptually a subset of the complete OCL
language for UML superstructure."


MOF 06-01-01 defines EMOF and Figure 12.1 clearly shows a merge of
Reflection. Therefore EssentialOCL has reflection.


UML superstructure has almost everything, so BasicOCL has reflection.


Issue 12951 provides the following revised text for 13.2. "The EMOF
Reflection capability is not merged to the metamodel."
This contradicts the above. If this is intended, OCL needs to redefine an
EMOF as perhaps OMOF with the appropriate merges.


Issue 9171 discusses why reflection is not available at the modelling level,
but is available at the meta-modelling level.


Presumably the intent is that MOF Reflection is present in the OCL
meta-model, but is not necessarily present in the constrained models and so
is not necessarily useable in OCL expressions. The revised text for Issue
12951 should be revisited to align with Issue 9171.

Resolution:
Revised Text:
Actions taken:
November 17, 2009: received issue

Discussion:

Issue 14851: OCL 2.1 Nested Collection Iteration (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

The OCL specification does not make clear whether an iteration over a Collection of Collections should operate on the flattened or unflattened source.


The Appendix through lack of specification and explicit specification of flattening would suggest that the iterator for a Collection of Collections is a Collection.


Most of the description in Section 7.6 is neutral through use of the term element.


However In 7.6.1 "The variable v is called the iterator. When the select is evaluated, v iterates over the collection and the boolean expression-with-v is evaluated for each v. The v is a reference to the object from the collection and can be used to refer to the objects themselves from the collection." implies that the source collection is flattened; at least in OCL 2.0 where collections were not first class objects, this is a contradiction. In OCL 2.1, collections are nearly first class objects and so perhaps there is just an ambiguity.


Similarly:


In 7.6.2 "When we want to specify a collection which is derived from some other collection, but which contains
different objects from the original collection (i.e., it is not a sub-collection), we can use a collect operation."


In 7.6.3 "The forAll operation in OCL allows specifying a Boolean expression, which must hold for all objects in a collection:"


In 7.6.4 "The exists operation in OCL allows you to specify a Boolean expression that must hold for at least one object in a collection".


Suggest that the specification of iteration avoid the use of 'object', sticking only to 'element'. A clarifying paragraph at the end of 7.6.5 should state that for a 0 or 1 deep Collection source, element is a non-Collection object. For an N-deep Collection source, element is an (N-1)-deep Collection.

Resolution:
Revised Text:
Actions taken:
December 10, 2009: received issue

Issue 14861: OCL 2.1 Inadequate definition of run-time meta-model (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

OCL 2.1 currently specifies an informal run-time meta-model in which all types conform to OclAny. Contributions to this meta-model come from
- the user meta-model(s)
- the standard library and its extensions
- additional constraints

Problem 1: An OCL AST for an OperationCallExp has a referredOperation that must be able to reference an operation that may come from any of these sources. Issue 12854 raised the problem of referencing additional operations and attributes.

Problem 2: The almost trivial problem of referencing standard library features has not been raised. If an AST is to be portable between one OCL tool and another there must be a standard URI by which for instance OclAny::= is referenced. Where is this URI specified?

Problem 3: The semantics of ambiguity resolution between alternative contributions is unclear. UML appears to leave overloading as a semantic variation point, so UML compliance is not helpful. Issue 14591 suggested that a first phase execution created at least a composite UML meta-model.

Problem 4: OCL 2.1 made clear that there is no reflection at run-time, and introduced OclAny::oclType to compensate. This provides very limited capabilities, in particular there is no counterpart to Element::container().

A formal run-time model and meta-model can solve these problems. The run-time model is the OCL library model, it's meta-meta-model is the OCL library meta-model and it's meta-meta-meta-model is MOF/UML. NB The OCL library meta-model is not the OCL meta-model.

The OCL library model comprises primarily oclstdlib::Classifier instances, one of which is named OclAny. OclAny::oclType() returns its oclstdlib::Classifier (NB not a uml::Classifier).

The oclstdlib::Classifier::conformsTo property (like but not uml::Classifier::general) contributes to the reified type conformance hierarchy.
The oclstdlib::Classifier::operations property (like but not uml::Classifier::operations) unifies the three sources of available operations, and three different derivations of oclstdlib::Operation accommodate the three types of contribution.

The oclstdlib model therefore integrates the user's UML meta-model with the standard library and additional constraints and is built during the first phase of execution. The oclstdlib meta-model is much simpler than MOF; there is no need for Associations and ConformsTo is the only Relationship. The semantics of the oclstdlib model defined independently of UML ensure a clear definition of the meaning of OCL execution.

The oclstdlib model should make no pretence at being UML because it is fundamentally different. One form of oclstdlib::Operation integrates a reference to a uml::Operation into a uniform behavioural structure. oclstdlib::Classifier ::conformsTo provides the modification of the user meta-model to insert OclAny as the bottom type, without modifying the user meta-model.

With an oclstdlib metaModel, OclAny could provide reflective capabilities such as oclContainer(), oclContents(), oclGet(), oclSet() etc that provide useful reflective capabilities. self.oclType().operations can satisfactorily return a collection of operations even though the operations come from three diverse sources. self.oclType()->closure(conformsTo) will return the type conformance ancestry.

Resolution:
Revised Text:
Actions taken:
December 14, 2009: received issue

Issue 14884: wrong parameter type for addNamespace operation call (ocl2-rtf)

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

(subclause [4])
 It reads: let firstNamespace : ModelElement ... in ... 
           self.nestedEnvironment().addNamespace(firstNamespace)
 It should read:
           self.nestedEnvironment().addNamespace(firstNamespace.oclAsType(Namespace)) 
 Rationale: the signature of addNamespace is (ns: Namespace) as defined in 9.4.1 subclause [7]

Resolution:
Revised Text:
Actions taken:
December 19, 2009: received issue

Issue 14885: lookupProperty instead of lookupAttribute (ocl2-rtf)

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

It reads: lookupAttribute


It should read: lookupProperty


Rationale: on section 8.3.8 an operation lookupProperty(attName : String) : Attribute
 is added to Classifier. The operation lookupAttribute is never defined in OCL or UML infra/superstructure (v2.1.2)

Resolution:
Revised Text:
Actions taken:
December 19, 2009: received issue

Issue 14886: wrong variable name (ocl2-rtf)

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

subclause [10])


It reads:  let foundElement  ... in result = if foundAttribute ... else foundElement ...


(foundAttribute is undefined, I understand it means to "foundElement")

Resolution:
Revised Text:
Actions taken:
December 19, 2009: received issue

Issue 14887: Issue 14593 (UML alignment: Attribute) (ocl2-rtf)

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

There are references to Attribute (from Core) in sections 7.5 , 8.2, 8.3.2, 8.3.8, 8.3.9, 9.3, 9.4.1, 10.3.2, 10.4.1, 10.4.3 while the UML infrastructure defines Property instead of Attribute

Resolution:
Revised Text:
Actions taken:
December 19, 2009: received issue

Discussion:

Issue 14888: No postcondition for NamedElement::getType() when self.oclIsKindOf(Namespace) (ocl2-rtf)

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

9.4.2 NamedElement 
 
NamedElement, as defined by OCL, links to ModelElement (from Core) and has an operation getType(): Classifier


Postconditions are given when the referred modelelelement is an instance of Classifier, VariableDeclaration or State.
However, from subclause [4] of section 9.4.1 it follows that the referred modelelelement may also be an instance of Namespace.
(let firstNamespace : ModelElement = lookupLocal( names->first() ).referredElement, where lookupLocal returns an OCL NamedElement) 


In the UML Infrastructure, Namespace specializes Core::NamedElement, which does not defines a type attribute (Core::TypedElement does)
Namespace is a generalization of Classifier.


 At least, add: 
  post: referredElement.oclIsKindOf(Namespace) implies
        result = -- TBD: when aligning with UML 2.0 
 
 Should it be result.oclIsUndefined() ?

Resolution:
Revised Text:
Actions taken:
December 19, 2009: received issue

Discussion:

Issue 14918: OCL 2.1 11.2.5 Numeric = and <> operations should compare values rather than objects (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

OCLAny::=() is defined as 'True if self is the same object as object2.'


This is not overloaded for numeric types, and it is not specified that a numeric value may not have multiple instances.


The definition therefore implies that:


1 = 1


may often evaluate to false, and that


1.0 = 1


must evaluate to false even though (1.0 <= 1) and (1.0 >= 1) will evaluate true


Suggest overload {Boolean, Real, String}::{=,<>} to use values rather than objects.

Resolution:
Revised Text:
Actions taken:
January 2, 2010: received issue

Issue 14980: OCL 2.1 11.7.3 OrderedSet addition well-formedness rules (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

The OrderedSet well-formedness constraints in 11.7.3 appear to have been
copied and pasted from Sequence. They need revision to consider the Set
consequences of .


Addition operations (includes, insertAt, union, append, prepend) have a
post-condition that the size increases, which is clearly not the case if
an additional element is equal to a pre-existing element.


In the particular case of insertAt there is an ambiguity as to whether
the insert index is the pre or post index. For instance when inserting 3
at index 5 into OrderedSet{1, 2, 3, 4, 5, 6} the pre-index insertion
yields OrderedSet{1,2,4,3,5,6} whereas the post-index insertion yields
OrderedSet{1,2,4,5,3,6}. While the post-index insertion satisfies the
'post: result->at(index) = object' constraint, it is presumably not the
intent.

Resolution:
Revised Text:
Actions taken:
January 17, 2010: received issue

Issue 14981: OCL 2.1 Implicit Conversion to Collection Literal (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

The specification is very vague as to how and when a non-collection is converted to a collection.


11.2.3 states that 'If the source is the null literal, it is implicitly converted to Bag{}'.


7.5.3 states that 'Such a single object can be used as a Set as well. It then behaves as if it is a Set containing the single object. The usage as a set is done through the arrow followed by a property of Set.'


The collection type inconsistency between Bag{} and Set{x} makes compile-time type resolution difficult, since the null-ness of x cannot be known till run-time. It would be better to have either Set or Bag uniformly as the conversion collection type. Bag{} as the least useful seems more appropriate.


When a conversion is applicable is unclear.


In the example, self.manager->isEmpty() is intended to be interpreted as


if self.manager.isUndefined() then Set{} else Set{self.manager} endif->isEmpty()


so that null->isEmpty is also valid.


However is


    null->excludesAll(null)


equivalent to


    Bag{}->excludesAll(Bag{})


and so true?


A simple policy of 'wherever a collection is required and a non-collection is provided perform an implicit conversion to collection-literal' resolves this.


However are


    null = Bag{}


or


    Bag{} = null


both equivalent to


    Bag{} = Bag{}


and so true?


In this case we have a problem of asymmetric overloading.


null = Bag{} satisfies the signature for OclVoid::=(OclAny) and so returns false.


Bag{} = null could satisfy the signature for Bag::=(Bag) and so return true with the help of an implicit conversion.


Presumably an additional OclVoid::=(Collection) overload is needed to restore symmetry.

Resolution:
Revised Text:
Actions taken:
January 17, 2010: received issue

Issue 14982: OCL 2.1 11.7.3 Missing OrderedSet::flatten overload (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

Collection::flatten is overloaded for Bag, Sequence and Set but not for OrderedSet.

Resolution:
Revised Text:
Actions taken:
January 17, 2010: received issue

Issue 14983: OCL 2.1 11.7 Missing OrderedSet::excluding and including (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

excluding and including are defined for Bag, Sequence and Set but not OrderedSet or Collection.


The Collections would be more consistent with an OrderedSet::excluding and an OrderedSet::including.


With all concrete Collection types defining excluding and including, the abstract Collection could also
define Collection ::excluding and an Collection ::including supporting fully polymorphic addition and
querying of collections.

Resolution:
Revised Text:
Actions taken:
January 17, 2010: received issue

Issue 14984: OCL 2.1 11.7.3 Missing OrderedSet::- (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

The minus operation should be provided for OrderedSet as well as Set.

Resolution:
Revised Text:
Actions taken:
January 17, 2010: received issue

Issue 14985: OCL 2.1 11.2 Conflicting {OclVoid, OclInvalid}::{oclIsTypeOf, oclIsKindOf, oclAsType} semantics (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

11.2.3 states clearly that "Any property call applied on null results in OclInvalid, except for the operations oclIsUndefined() and oclIsInvalid()." This is being revised by Issue 14197 in OCL 2.3 to: "Any property call applied on OclVoid results in invalid, except for the operations oclIsUndefined(), oclIsInvalid(), =(OclAny) and <>(OclAny)."


11.2.4 states clearly that "Any property call applied on invalid results in OclInvalid, except for the operations oclIsUndefined() and oclIsInvalid()." This is being revised by Issue 14197 in OCL 2.3 to: "Any property call applied on OclInvalid results in invalid, except for the operations oclIsUndefined() and oclIsInvalid()."


Therefore invalid.oclIsTypeOf(OclInvalid) => invalid and null.oclIsTypeOf(OclVoid) => invalid.


But the above are widely used in the specification as for example:


"oclIsUndefined() : Boolean
Evaluates to true if the self is equal to OclInvalid or equal to null.
    post: result = self.isTypeOf( OclVoid ) or self.isTypeOf(OclInvalid)"


clearly expecting isTypeOf (a typo) to return true/false, not invalid sometimes.


Issue 14197 relaxed the OclVoid property list to allow = and <>. Perhaps all oclXXX operations should have an explicitly defined semantics for OclVoid and OclInvalid, supporting rather than denying reflective usage of the values as in self.isTypeOf( OclVoid ).

Resolution:
Revised Text:
Actions taken:
January 17, 2010: received issue

Discussion:

Issue 14986: OCL 2.1 Feature Overloading Semantics are not defined (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

OCL supports feature overloading and attempts to comply with UML. OCL does not define feature overloading itself. UML leaves feature overloading as a semantic variation point.


The OCL behaviour is therefore undefined. However a variety of behaviours particularly those involving null and invalid only make sense if operations are selected at run-time according to the dynamic type.


The example from an earilier pending issue:


Sequence(OclAny){3, 3.0, '3'}->count(-(-3)) = 2


wherein


UnlimitedNatural 3 widens to Integer 3 for successful comparison with Integer 3
Real 3.0 is successfully compared to Integer 3 widened to Real
String '3' widens to OclAny and fails to compare to Integer 3 widened to OclAny.


is difficult to realise if static type resolution is applicable in which case all pair-wise value comparisons would use OclAny::= rather than Real::=.


Suggest:


OCL define that features are selected dynamically at run-time.

Resolution:
Revised Text:
Actions taken:
January 18, 2010: received issue

Issue 15009: OCL 2.1 11.2.3 Navigated Implicit Conversion to Collection Literal (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

The Issue 14981 considered use of explicit null as a Collection.

11.2.3 states that 'If the source is the null literal, it is implicitly converted to Bag{}'.

Surely when the null arises as a navigation result, the isOrdered and isUnique characteristics of the navigated property should determine what CollectionKind the null result is converted to?

However meta-modelling tools and meta-modellers pay little attention to the isUnique and isOrdered characteristics of zero and unit multiplicity properties. Using this overlooked information may cause surprises.

Resolution:
Revised Text:
Actions taken:
January 29, 2010: received issue

Issue 15010: Collection::sum is not realisable for empty collection of user defined type (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

Collection::sum is defined to exploit an associative and commutative T::+(T).


However for an empty collection, the result must be a zero value of the
user defined type and there is no mechanism to determine its 0.


Suggest: require a T::zero() and provide corresponding Real::zero() and Integer::zero() and UnlimitedNatural() operations.

Resolution: deferred
Revised Text:
Actions taken:
January 31, 2010: received issue

Discussion:

Revised Text: (DO NOT APPLY REVISION SINCE FINAL DISPOSITION IS
DEFERRED)
In 11.4.1 Real add
oclZero : Real
The additive identity.
init: 0.0
oclOne : Real
The multiplicative identity.
init: 1.0
100
In 11.4.2 Integer add
oclZero : Integer
The additive identity.
init: 0
oclOne : Integer
The multiplicative identity.
init: 1
In 11.4.3 String add
oclZero : String
The additive identity.
init: ''
In 11.5.? UnlimitedNatural add
oclZero : UnlimitedNatural
The additive identity.
init: 0
oclOne : UnlimitedNatural
The multiplicative identity.
init: 1
In 11.6.1 sum() replace
Elements must be of a type supporting the + operation. … Integer and Real fulfill this condition.
post: result = self->iterate( elem; acc : T = 0 | acc + elem )
by
Elements must be of a type supporting the + operation and the oclZero property. … The oclZero property
provides the additive identity. UnlimitedNatural, Integer, Real and String fulfill this condition.
post: result = self->iterate( elem; acc : T = T::oclZero | acc + elem )
Disposition: DEFERRED
NOTE: The vote did not passed for this issue (initial disposition was
Resolved).
101
Reason :
Issue 15010 uses redefined properties with covariant types. Once the Standard
Library is
aligned with UML, this usage will not be allowed

Issue 15013: OCL 2.1 Overload resolution (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

Issue 6555 introduced the 'missing' Collection::=(Collection(T)) and Collection::=(Collection(T)).


Issue 12948 changed Collection to conform to OclAny


This means that "Set{} = 1" is no longer self-evidently invalid.


According to the inherited OclAny::=(OclAny), "Set{} = 1" should be semantically legal and evaluate to false.


But if Collection::=(Collection(T)) fully occludes OclAny::=(OclAny) ,"Set{} = 1" should be a semantic analysis failure and so invalid.


Conversely "1 = Set{}" is OclAny::=(OclAny) and unambiguously false (until a Real::=(Real) overload is introduced to accommodate value rather object identity).


OCL does not specify any policy for static or dynamic resolution of overloads.


A Java-like policy of static determination of the most derived valid signature, then dynamic dispatch on the self object would seem appropriate, but:


let c1 : OclAny = Set{1}, c2 : OclAny = Set{1} in c1 = c2


must select OclAny::=(OclAny) as the static signature. Collection::=(Collection(T)) is not a derived operation with the same signature, so evaluation should use OclAny::=(OclAny) rather than Collection::=(Collection(T)) and give erroneous results swhen the collections are compared by object identity rather than collection kind and content.


Either:
OCL must specify multi-dimensional dynamic overload resolution on source and arguments


Or:
OCL should specify Java-like single-dimension dynamic overload resolution and the signature of derived operations such as Collection::=(Collection(T)) should be changed to match their inherited signature, i.e. to Collection::=(OclAny).


[Or:
All derived functionality must be folded into the base (OclAny) operation.]

Resolution:
Revised Text:
Actions taken:
January 30, 2010: received issue

Issue 15037: OCL 2.1 Section 10 problems (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

Section 10 is suffering seriously from lack of update and review.

The old AssociationClassCall/AssociationEndCall/ModelPropertyCall spellings are in use throughout.

OrderedSetValue is omitted throughout.

UnlimitedNaturalExpValue is omitted throughout.

TypeExpEval is omitted throughout thereby avoiding tackling the irregular semantics of the oclIsKindOf argument.

'undefined' does not distinguish null and invalid and is variously undefined, void, UndefinedValue, OclVoidValue and UnspecifiedValue including a reference to UnspecifiedValueExp that does not exist. There should be just an OclVoidValue and an OclInvalidValue.

OrderedSet is not used where elements are clearly unique e.g. Sequence(LocalSnapShot).

OCL is regularly spelled ocl or Ocl as a non-word prefix.

An Element::indexNr is imposed on all Collection elements. Surely a distinct OrderedCollectionValue intermediate value should use the stronger OrderedCollectionElement.

It is not specified whether Element::indexNr indexes from 0 or 1 or indeed even monontonically.

Figure 10.4 omits many {ordered}and {unique} constraints.

Figure 10.4 omits LocalSnapShot.pred and succ.

10.2.1 Element assserts that Element is a tuple NameValueBinding.

10.2.1 OclMessageValue italicises the wrong use of 'name'.

10.2.2 LocalSnapShot[1] refers to ispre rather than isPre.

10.2.2 LocalSnapShot[2] asserts that the result of an implicit collect is a boolean (missing ->any).

10.2.2 ObjectValue omits the doubly-linked list validity constraint

10.2.2 TupleValue assserts that a NameValueBinding is an Element.

10.2.3 SequenceTypeValue omits a constraint on the sequential validity of Element.indexNr

10.2.3 LocalSnapShot uses notEmpty rather than nonEmpty()

10.3 para 2 refers to a non-existent OclEvaluation class

10.3 para 2 has erroneous figure references to 10.6,7 rather than 10.7,8

10.3.2 OperationCallExpEval relies on UML semantics, but fails to resolve UML's unspecified behavioural variation point on operator overload resolution. See Issue 15013.

10.3.2 OperationCallExpEval spells forAll as forall.

10.3.2 CollectionRangeEval uses isOclType(Sequence(Integer)). Any such use of collection types was invalid in OCL 2.0. Use of a collection type is not valid concrete syntax in OCL 2.1/2. The resolution of 10439 for OCL 2.3 provides concrete syntax support, but the semantics remains undefined although perhaps intuitively obvious.

As separately raised isOclType etc are incorrect spellings.

The x .. y syntax could be used to advantage in places such as 10.3.3 CollectionRangeEval.

The explicit iterator is unnecessary in for instance 10.2.2 TupleValue.

Figure 10.14 has layout problems.

Figure 10.14 shows instances <-> model associations for both Concrete and Abstract classes. The model for derived classes should be marked as derived.

10.4.2 BooleanLiteralExpEval has an unresolved MOF/UML alignment.

10.4.2 EvalEnvironment has a missing constraint on uniqueness of binding names.

10.4.2 IfExpEval has missing and operators

Generally: the constraints should be validated by an OCL checking tool.

Resolution:
Revised Text:
Actions taken:
February 4, 2010: received issue

Issue 15072: OCL 2.1 12 Missing specification of initial and derived value constraints (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

Sections 12.5.1, 12.6.1, 12.7.1 specify the "invariant", "precondition", "postcondition" spellings.


Sections 12.8, 12.9, 12.10, 12.11 do not specify their corresponding spellings.


Suggest: "initial", "derivation", "body", "guard" as the conventional adjective used to qualify "constraint".

Resolution:
Revised Text:
Actions taken:
February 19, 2010: received issue

Issue 15092: OCL 2.1 conformsTo definition suggestion (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

OCL allows a user to define a run-time OCL meta-model through Property and Operation definitions that is based upon a specification-time UML meta-model.


It would be useful to allow a user to also introduce inheritance/conformance polymorphisms.


Thus:


context CommonPackage::CommonObject


context CommonPackage::CommonObject::isSerializable() : Boolean = false


context OCL::String conformsTo CommonPackage::CommonObject


context MyPackage::MyObject conformsTo CommonPackage::CommonObject


context YourPackage::YourObject conformsTo CommonPackage::CommonObject


could mix-in the capabilities of CommonObject to each of MyObject and YourObject and String.


This would allow common functionality to be mixed in once and used polymorphically rather than being added in amorphously and requiring an if-tree of per-context invocations of that functionality.

Resolution:
Revised Text:
Actions taken:
February 26, 2010: received issue

Issue 15156: OCL 2.1 Parametric references (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

OCL supports access to a variety of properties such as self.a, self.b, self.c but provides no mechanism for indirection of the property selection.


Perhaps that the standard library support reflection more effectively with:


    self.oclGet(MyClass::a)

Resolution:
Revised Text:
Actions taken:
March 30, 2010: received issue

Issue 15175: OCL 2.1 Navigation of opposites (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

UML models may explicitly declare that a Property is not navigable in order to simplify the complexity of the run-time representation of that Property.


In an EMOF representation, the non-navigable Property is missing and so an OCL constraint cannot use it, even though the OCL constraint is used at compile-time rather than run-time.


In a UML direction, a Property may be unnamed in one direction and the implicit naming of such opposites may be inadequate to permit unambiguous usage.


QVT Relations 1.1 partially works around this by introducing an opposite(Property) declaration that may be used for Keys and PropertyTemplateItems.


OCL, rather than QVT, should provide an ability to navigate a Property in an opposite direction.


In the Abstract Syntax, OppositePropertyCallExp is required to capture the inverse navigation semantics of PropertyCallExp.


In the Concrete Syntax, some alternate navigation operator is required. Perhaps "a.~b" indicates that "b" is in an inverted direction.

Resolution:
Revised Text:
Actions taken:
April 13, 2010: received issue

Issue 15218: OCL 2.2 UML-alignment of redefinition (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

At the end of Section 7.4.6 OCL 2.2 says


"For example, if class Employee redefines the age() : Integer operation of
the Person class, a constraint may access the
Person definition as in
context Employee
inv: self.age() <= self.Person::age()
For clarity, the qualified form may only be used with an explicit source
expression."


and in Section 7.5.8:


"Whenever properties are redefined within a type, the property of the
supertypes can be accessed using the oclAsType()
operation. Whenever we have a class B as a subtype of class A, and a
property p1 of both A and B, we can write:"


a clarifying example follows that is actually a disambiguation not a
redefinition.


In UML redefinition replaces an old definition with something else, which is
not what the above
excerpts imply.


In the case of redefining "Person::age() : Integer". If the redefinition is
"Employee::age() : UnlimitedNatural"
the redefinition is compatible (valid UML), so perhaps self.age() being
UnlimitedNatural and self.Person::age()
being Integer just might be useful. But allowing them to invoke different
operation bodies seems to violate
UML.


Suggest that use of a path qualification may select an occluded definition
signature for static analysis,
but may not use a redefined value or body.


[This then avoids a need for the AST to persist the distinction between X::y
as an explicit feature for
static resolution or as an implicit feature for dynamic resolution. All
features in the AST are identified by
static analysis and evaluated by dynamic resolution.]

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

Issue 15219: OCL 2.2 Clarity of qualified path names (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature:
Severity:
Summary:

At the end of Section 7.4.6 OCL 2.2 says


"For clarity, the qualified form may only be used with an explicit source
expression."


thereby requiring "self.Person::age()" rather than just "Person::age()".


This 'clarity' is surely just a stylistic issue.


An organisation may advocate an OCL-style guide that discourages the use of
implicit-self.
That is a free choice made by that organisation.


It does not seem appropriate for one corner of the OCL specification to
prohibit implicit-self
where consistency would imply that it should be present.


This is not a 'clarity', it is a confusion.


Suggest allow implicit-self before qualified path names (unless there is a
different
strong technical reason.)

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

Issue 15220: OCL 2.2 7.5.4 Property-qualified association navigation has no concrete or abstract syntax (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

Section 7.5.4 describes an association navigation qualification to
accommodate
recursive associations.


e.g. self.employeeRanking[bosses]


in which "bosses" is a Property role name.


OCL 2.2 has no concrete syntax for this. Superficially it resembles an
AssociationClassCallExp, but that requires OclExpression values for its
qualifiers.


Prior to OCL 2.0 (and still present in many obstinate residual artefacts in
OCL 2.2),
there was an AssociationEndCallExp, whose syntax was identical to an
AssociationClassCallExp
and so it was removed and merged with AttributeCallExp as PropertyCallExp.


It would appear that a form of AssociationEndCallExp is required with
syntaxes


OclExpressionCS '.' pathNameCS[1] ('[' pathNameCS[2] ']')? isMarkedPreCS?
pathNameCS[1] ('[' pathNameCS[2] ']')? isMarkedPreCS?


in which pathNameCS[2] defines the NavigationCallExpCS.ast.navigationSource
that is currently completely undefined and very confusingly described in
Section 8.3.2:


"navigationSource The source denotes the association end Property at the end
of the object itself. This is used to
resolve ambiguities when the same Classifier is at more than one end (plays
more than one
role) in the same association. In other cases it can be derived."


Suggest:


Remove NavigationCallExp::navigationSource that currently has no semantics


Introduce QualifiedPropertyCallExp (and etc.) as a further NavigationCallExp
to support
the qualified navigation. It has two associations:


referredSourceProperty: Property (e.g. "bosses")
referredTargetProperty: Property (e.g. "employeeRanking").

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

Discussion:

Issue 15232: OCL 2.2 Correction to Issue 9796 for isPre (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

Issue 9796 responded to the problem with the undefined (and undefinable) withAtPre().


However the textual replacement of ".withAtPre()" by ".isPre = true" is not valid.


For instance


[D] AttributeCallExpCS.ast.source = if isMarkedPreCS->isEmpty()
then OclExpressionCS.ast
else OclExpressionCS.ast.withAtPre() endif


should be elaborated to:


[D] AttributeCallExpCS.ast.source = OclExpressionCS.ast
[D] AttributeCallExpCS.ast.isPre = isMarkedPreCS->notEmpty()

Resolution:
Revised Text:
Actions taken:
April 29, 2010: received issue

Issue 15233: OCL 2.2 Correction to Issue 9796 for AssociationEndCall (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

Issue 9796 responded to the merge of Attribute and AssociationEnd as Property in UML
by merging AttributeCallExp and AssociationEndCallExp.


This merge was not appropriate since UML made no change to the required OCL navigability.


Without AssociationEndCallExp, it is not possible to express a qualified association navigation,
since the 'replacement' PropertyCallExp does not allow for the qualifiers in:


    self.customer[123456]

Resolution:
Revised Text:
Actions taken:
April 29, 2010: reeived issue

Issue 15234: OCL 2.2 Generalisation of Issue 7341 PathNames (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

Issue 7341 changed a number of syntaxes to permit a PathNameCS rather than a SimpleNameCS,
so that scope ambiguities could be resolved.


It is not clear why this was applied uniformly to all syntaxes where a name reference is in use. As a minimum
it just gives the user the discretion to clarify a subtle statement, and it avoids the impression that pathed-names
are special. It also avoids the need for some very similar concrete syntax expositions.


More specifically in an AssociationClassCallExpCS it would allow disambiguation of Left::Link and Right::Link as
alternate AssociationClasses.


Suggest allow PathNameCS in all places where there is not a specific requirement for a SimpleNameCS.

Resolution:
Revised Text:
Actions taken:
April 29, 2010: received issue

Issue 15249: Why OCL does not have "super" reference? (ocl2-rtf)

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

I hope someone can explain to me why OCL does not have a reference to "super" (similar to the existing reference to "self"). Wouldn't you want to sometimes call the redefined version of an operation from an OCL exrpression, similar to how you can do that in Java?

From my limited knowledge of ALF (the action language), I understand it supports the "super" reference, so this tells me there is no semantic restriction there?

Resolution:
Revised Text:
Actions taken:
April 20, 2010: received issue

Discussion:

Issue 15254: the use of the keyword 'attr' (ocl2-rtf)

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

I've seen, in the version 2.0, the existence of the keyword 'attr'. But then, in fact, there isn't any reference or explanation about the use of this keyword.
I've seen that this keyword is not in the new versión 2.2. But, you use it in the page 25, ln 12.

Resolution: deferred
Revised Text:
Actions taken:
May 14, 2010: received issue

Discussion:

The 'attr' is a relic of a former (pre OCL 2.0) syntax.
The 'attr' should be omitted, and 'TupleType' should be 'Tuple'. [UML compliance,
as observed in Issue 15235, requires 'Job' rather than 'job'].
This issue is resolved as part Issue 12456.
Disposition: Deferred
NOTE: Initialdisposition: Merged with 12456. Issue is Deferred since votation did not pass.
Reason: (missing merged resolution 12456)

Issue 15257: OCL 2.2 OclState and oclIsInState (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

The oclIsInState takes an OclState argument, which is referenced extensively
in
Annex A, although the OclState type is never defined in the main text and is
not
mentioned in the grammar as a reserved word.


oclIsInState is misspelled as oclInState 7 times in Section 7.5.9 and once
in A.2.6.

Resolution:
Revised Text:
Actions taken:
May 18, 2010: received issue

Issue 15258: OCL 2.2 OclMessage types are not statically derivable (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

The intro to Section 8.2 states:


"OCL is a typed language. Each expression has a type that is either
explicitly declared or can be statically derived."


However OclMessage lacks type parameterisation and so the 7.7.2 example


context Subject::hasChanged()
post: let messages : Sequence(OclMessage) = observer^^update(? : Integer, ?
: Integer) in
        messages->notEmpty() and
        messages->exists( m | m.i > 0 and m.j >= m.i )


only works if the type analysis proceeds beyond "messages :
Sequence(OclMessage)" to
discover the initialiser with formal signature "Observer::update(i :
Integer, j : Integer)".


This will not in general be possible and so expressions such as "m.i > 0"
cannot be
statically checked, and cannot be dynamically expressed. Indeed since m is
an OclMessage,
"m.i" is not well-formed.


Suggest that OclMessage is redefined as:


OclMessage<OclOperation> or OclMessage<OclSignal>


requiring the type to be determinate or discovered by oclAsType.

Resolution:
Revised Text:
Actions taken:
May 18, 2010: received issue

Issue 15357: OCL 2.2 OclState, State, StateExp, StateExpCS, StateValue and StateExpEval (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

The use of OclState in the specification is not defined in the normative part of the specification, where it appears solely as OclAny.oclIsInState(statespec : OclState).


A corresponding StateExp exists to convey this as a referredState of type State.


Surely the OclState type is redundant and it should be OclAny.oclIsInState(statespec : State)?


The use of OclState in Annex A may be helpful, so perhaps an introduction to Annex A could explain the mappings between the names used for clarity in Annex A and those used in the normative specification.


Aren't a StateValue and StateExpEval needed to define the semantics?


Isn't a StateExpCS needed to define the abstract/concrete syntax? Perhaps this could merge with TypeExpCS, TypeLiteralExpCS as ModelElementLiteralCS.

Resolution:
Revised Text:
Actions taken:
July 8, 2010: received issue

Issue 15367: OCL 2.2 Add endlet to make grammar extensible (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

Further to Bran Selic's observation on Issue 15357 that UML-specifics should not really impact the OCL core. This is easy for State via a ModelLiteralExp, but hard for Message which has associated concrete syntax.


The expression grammar could be made extensible to accommodate custom/orthogonal infix, prefix, suffix, precedence if an expression could be parsed by the generic:


expr ::= affixed (infix affixed)*
affixed ::= prefix* suffixed
suffixed ::= atom (suffix | '(' expr ')' | '[' expr ']' | '{' expr '}' )*
atom ::= '(' expr ')'
    | name
    | 'if' expr 'then' expr 'else' expr 'endif'
    | 'let' expr 'in' expr 'endlet'


The major problem is the missing 'endlet', which makes accurate parsing difficult and complex expressions easy for humans to misinterpret too.


Suggest introduce the 'endlet' keyword.

Resolution:
Revised Text:
Actions taken:
July 9, 2010: received issue

Issue 15368: OCL 2.2: Section: 7.5.3 Clarification required for Qualifying association ends with association names (ocl2-rtf)

Click here for this issue's archive.
Source: EMC (Mr. George Ericson, ericson_george(at)emc.com)
Nature: Uncategorized Issue
Severity:
Summary:

The text in the clause titled “Qualifying association ends with association names” points out that it is possible to qualify an accessed role name with the name of the association using the ‘::’ separator.  (In the example: aC1.A1::c2.)   There is no issue with this as a means to access the associated instance.  However, in doing so, the clause misses the opportunity to also say that it is also possible to reference the same associated instance using the ‘.’ (dot) operator in place of the ‘..’ separator, (for example: aC1.A1.c2).

 

While this was also true prior to OCL 2.2, only the later technique was referenced in OCL 2.0.   

 

Clarification is needed with respect to whether or not there are any semantic differences between the uses of these two techniques.  Where the functionality overlaps, is there a preferred technique?

 

Nit: the last sentence of the example:  

“If a C1 is aC1 access, aC1.c2 will not be valid since it is ambiguous, whereas aC1.A1::c2 or aC1.A2::c2 will be valid.”  

Should probably say: 

“If aC1 isa C1, then aC1.c2 will not be valid since it is ambiguous, whereas aC1.A1::c2 or aC1.A2::c2 will be valid.”

Resolution:
Revised Text:
Actions taken:
July 9, 2010: received issue

Issue 15387: OCL 2.2: AST is an ASG (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

The AS is referred to in a number of places as an abstract syntax tree. This is a misnomer that causes confusion in some academic circles. The AS should always be referred to as a Graph.

Resolution:
Revised Text:
Actions taken:
July 29, 2010: received issue

Issue 15412: OCL Constraint violation messages (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

OCL supports definition of constraints, but it is difficult for tools to offer better error messages to a user than 'Constraint <constraint-name> violated for <constrained-element-name>'.


It would be helpful if Constraints had an additional String-valued expression to be evaluated in the context of the error, so that tools could evaluate it and present the result to the user.


Suggest add an optional argument to the (not-optional) constraint name. e.g.


inv ConstraintName('Unable to find ' + self.target.name): ...

Resolution:
Revised Text:
Actions taken:
August 11, 2010: received issue

Issue 15420: OCL Enumeration allInstances (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

UML defines Enumeration.ownedLiteral as an ordered set. Surely allInstances() should therefore return an OrderedSet for an enumeration, and perhaps an ordinal property should be added by the Standard Library.

Resolution:
Revised Text:
Actions taken:
August 18, 2010: received issue

Issue 15425: OCL Generics (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

UML supports generics/templates. OCL doesn't. This is a UML alignment failure.

Resolution:
Revised Text:
Actions taken:
August 21, 2010: received issue

Issue 15426: OCL Stereotypes (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

The OCL 2.2 specification refers to stereotypes in the UML 1.x sense. These need to be aligned with UML 2.x. Are they 'keyword' or 'Stereotype'? Is there an OCL Profile to be applied?


NB. the sterotypes are of two forms:
a) Constraint role: invaraint/precondition/...
b) UML extension: OclHelper for a Complete OCL def (see 7.4.4.)

Resolution:
Revised Text:
Actions taken:
August 23, 2010: received issue

Issue 15710: OCL 2.2 forAllAt suggestion (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

It is common in an iteration to require in iteration index.


This can be achieved rather expensively by indexOf, or less expensively by
iterating over an integer literal range.


It would be easier to define e.g.


forAllAt(index : Integer, i : T)


etc so that an implementation can supply the index efficiently.

Resolution:
Revised Text:
Actions taken:
October 8, 2010: received issue

Issue 15712: OCL 2.2 Allow optional let type (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

9.3.36 states "A variable declaration inside a let must have a declared type and an initial value."


In the case of a Tuple literal assigned to a let variable, this requires that the tuple signature be entered twice.


Suggest relaxing the requirement on a type to allow deduction from the initial value.

Resolution:
Revised Text:
Actions taken:
October 11, 2010: received issue

Issue 15780: OCL 2.2 Unlimited and Infinity (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

OCL supports a '*' value for UnlimitedNatural in order to accommodate the
full range of UML multiplicities.


UnlimitedNatural conforms to Integer and Real, so that any UnlimitedNatural
conversion must perform a run-time check in order to convert '*' to invalid.
This conversion cannot be replicated in the reverse direction.


Suggest that '*' be aligned with the conventional IEEE math notion of
infinity, so that
* and -* are valid values for Integer and Real. UnlimitedNatural is then a
simple restriction of Integer which is a simple restriction of Real.

Resolution:
Revised Text:
Actions taken:
October 25, 2010: received issue

Issue 15789: Vagueness about meaning of 0..1 multiplicity in OCL and UML (ocl2-rtf)

Click here for this issue's archive.
Source: Microsoft (Mr. Steve Cook, stcook(at)microsoft.com)
Nature: Uncategorized Issue
Severity:
Summary:

UML-alignment of OCL type signatures
--------------------------------------------------------
 
Following discussion in the "Vagueness about meaning of 0..1 multiplicity in OCL and UML" threads
of the UML2 and OCL RTFs the following problems exist in alignment of the UML and OCL type systems.
 
The OCL specification does not provide a clear description of the comparative semantics of for instance
Integer[1] and Integer[0..1].
 
The Complete OCL syntax for an Operation Context Declaration uses OCL type decalarations and so
fails to provide the same expressivity as a UML operation declaration with multiplicities.
 
Suggest:
 
a) a clear indication that 
 
An Integer[1] may have integer values, null or invalid, of which only integer values are well-formed.
 
An Integer[0..1] may have integer values, null or invalid, of which integer values and null are well-formed.
 
b) an enhancement to the type declaration syntax to allow
 
Integer[0..1] or Integer[1] to indicate a nullable/non-nullable value.
 
Set(Integer[1..7]) to capture the expressivity of a UML multiplicity

Resolution:
Revised Text:
Actions taken:
October 28, 2010: received issue

Issue 15790: OCL 2.2 Missing definition of navigation (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

Dot and arrow navigation have implied definitions in the non-normative clause 7, but nothing in the normative clauses.


Implicit collect is missing from clause 9, save for the throwaway final sentence "The mapping
is not formally defined in this document but should be obvious."


This mapping is far from obvious; if it was obvious it would be easy to define.


In particular it is important to define that a static syntax determination is made to ensure that:


anObject . feature => object navigation
anObject -> feature => implicit collection (of anObject's static ordering/uniqueness) containing a non-null anObject
aCollection -> feature (or iterator) => collection navigation
aCollection . feature (or iterator) => implicit collect = aCollection -> collect(feature or iterator)
(implicit source object implicit .) feature => object navigation
(implicit source collection implicit ->) feature (or iterator) => collection navigation


with the object/collection discrimination performed statically, so that the navigation
algorithm is statically determinate; only the dynamic dispatch on self is subject to
dynamic determination.


The conformance of a collection to OclAny must never used to allow object navigation on a collection. This avoids a syntax ambiguity for "aCollection . name" between implicit collect and object navigation of a collection feature, or between implicit collect and object navigation of an object feature.

Resolution:
Revised Text:
Actions taken:
October 31, 2010: received issue

Issue 15836: OCL 2.3 Incomplete CollectionRange well-formedness rules (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

The descriptions of CollectionRange are generally vague leaving the end inclusivities unclear.


It is only the CollectionRangeEval::getRange that provides a solid definition of well-formedness
for e.g. Sequence{1..1} as equal to Sequence{1}.


Unfortunately the specification is undecided about Sequence{2..1} since the CollectionRangeEval::getRange
recursion never terminates.


Rather than impose a well-formedness constraint that Sequence{2..1} is invalid, perhaps it should be
made useful instead, by defining .. as operating in the direction of the last wrt the first so
Sequence{2..1} = Sequence{2,1} and Set{1..2} = Set{2..1} = Set{1,2}.

Resolution:
Revised Text:
Actions taken:
November 18, 2010: received issue

Discussion:

Issue 15838: OCL 2.3 max, min iterations (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

It would be usefuil to have iterations analoguous to isUnique that compute max or min of a user-defined expression body over a collection.

Resolution:
Revised Text:
Actions taken:
November 20, 2010: received issue

Discussion:

Issue 15877: Issue on Alignment of next OCL version and references UML 2.4/ MOF 2.4 (ocl2-rtf)

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

Nature of problem:


Informal references to UML 1.4.1 and UML 1.5 are included
as part ofexplanatory text in the OCL 2.2 spec which refers
to UML 1.x to explain differences of this new version of
OCL.. The ISO/IEC 10151 (UML 1.4.1) needs to be added as
an informative reference, for use in these explanations.


UML 1.4.1 needs to remain in force, because so many UML
models in may standards throughout the world are specified
using UML 1.x notation, which is not backwards compatible
with the new notation in UML 2.x.


Given the normative content of OCL 2.3 (after RTF
completes) is aligned technically with UML 2.4 and MOF 2.4,
its normative references should be updated before
publication of the RTF output, so that the OMG spec cross
references will remain appropriate..


The references, and their uses in the OCL 2.3spec, need to
be updated to reflect these latest UML/MOF versions.


In addition, the Output of the OCL 2.3 RTF should be
labeled as OCL 2.4, to avoid clarify the technical
alignment of OMG’s latest versions of UML and MOF.


Proposed Changes:


Change version in title to OCL 2.4.


Change all self references in the text from “OCL version
2.2” to “this OMG Specification”.


Change all references from UML 2.0 and MOF 2.0 to UML 2.4
and MOF 2.4.


In Section 1  Scope Clause:


Change:
“
This specification defines the Object Constraint Language
(OCL), version 2.3. OCL version 2.3 is the version of OCL
that is aligned with UML 2.3 and MOF 2.0.
“
to
“
This specification defines the Object Constraint Language
(OCL), version 2.4. OCL version 2.4 is the version of OCL
that is aligned with UML 2.4 and MOF 2.4.
“


Section 3  Normative References


Change:
“
3 Normative References
The following normative documents contain provisions which,
through reference in this text, constitute provisions of
this specification. For dated references, subsequent
amendments to, or revisions of, any of these publications
do not apply.
• UML 2.0 Superstructure Specification
• UML 2.0 Infrastructure Specification
• MOF 2.0 Core Specification
• UNICODE 5.1 Standard:
http://www.unicode.org/versions/Unicode5.1.0/
«
To :
«
3 References
3.1 Normative References
The following normative documents contain provisions which,
through reference in this text, constitute provisions of
this specification. For dated references, subsequent
amendments to, or revisions of, any of these publications
do not apply.
• UML 2.4 Superstructure Specification <omg spec Ref URL>
• UML 2.4 Infrastructure Specification <omg spec Ref URL>
• MOF 2.4 Core Specification <omg spec Ref URL>
• UNICODE 5.1 Standard:
http://www.unicode.org/versions/Unicode5.1.0/
3.2 Informative References
The following specification is reference in explanatory
text, which describes differences between this
specification and the version of OCL included in the
existing standard. Its provisions do not constitute
provisions of this specification.
• ISO/IEC 19501:2005 Information technology -- Open
Distributed Processing -- Unified Modeling Language (UML)
Version 1.4.2 , also <omg Spec Ref URL>
“


Change all uses of the reference in the text
From
“
UML 1.x” or “UML 1.4.x”
“
To:
“
ISO/IEC 19501:2005
“


In Section 6.1 “Changes to Adopted OMG Specifications”


Replace:
“
This specification replaces the specification of OCL given
in UML 1.4.1 and UML 1.5.
“
With:
“
This specification replaces the specification of OCL given
in OCL 2.2.


The version of OCL specified in ISO/IEC 19505:2005 is
intended for use in models based on UML 1.4.1 and UML 1.5.
However, use of the OCL specified by ISO/IEC 19505:2005 is
not prescribed by this specification.

Resolution:
Revised Text:
Actions taken:
December 7, 2010: received issue

Issue 15920: OCL 2.3.TupleType semantics and AST (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

8.2 Does the lack of restriction on feature types for a TupleType extend to InvalidType and VoidType? With an InvalidType feature the tuple could only be 'well-formed' when containing an invalid value. Surely a tuple with an invalid value is itself invalid and not well-formed?


8.2.2 TupleType has some ASCII code corruptions in the OCL.


8.2.2 TupleType uses unqualified names for feature types allowing an ambiguity when package path is significant.


10.2 TupleValue surely values must not be invalid?


13 TupleLiteralExp has a TupleLiteralPart which has a Property, not accommodating the OclExpression of an initExpression provided by the concrete syntax. Surely a TupleLiteralPart is a derived VariableDeclaration adding an initExpression?

Resolution:
Revised Text:
Actions taken:
January 8, 2011: received issue

Discussion:

Issue 15922: typo in ptc/2010-11-42 and pas/2010-08-02 (ocl2-rtf)

Click here for this issue's archive.
Source: Fujitsu (Mr. Hiroshi Miyazaki, miyazaki.hir-02(at)jp.fujitsu.com)
Nature: Uncategorized Issue
Severity:
Summary:

Regarding ptc/10-11-42 and pas/10-08-02,
It seems to be typo.


In ptc/10-11-42, 11.6.5, and
in pas/10-08-02, 11.5.5


Threre is
"A Sentence is not a subtype of Bag. The common supertype of Sentence and Bags is Collection."
    ^^^^^^^ ^^^^^^^^


These two "Sentence"s seem to be typo.


Substitute "Sequence" for "Sentence".

Resolution:
Revised Text:
Actions taken:
January 10, 2011: received issue

Issue 15980: The opertion "collect" is confused with the operation "reject" (ocl2-rtf)

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

"Reject" should be replaced with "collect" in the following line:
"The value of the reject operation is the collection of the results of all the evaluations of expression-with-v."

Resolution:
Revised Text:
Actions taken:
January 24, 2011: received issue

Issue 16018: OCL 2.3 : Introduce Lambda functions (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

OCL already has an implicit form of Lambda function in the intuitive declaration of collect(). This should be formalised and made more versatile. It doesn't seem to be possible to formulate a declaration for collect() without a Lambda Function:


Sequence(T1)::collect(T2)(iterator : T1 | body : Lambda T1() : T2) : Sequence(T2)


The mandatory collect body is a parameter-less Lambda function whose context-type is the class template parameter T1 and the return-type is the operation template parameter T2.


For other iterators the declaration can be just OclExpression since the type is not exploited.

Resolution:
Revised Text:
Actions taken:
February 12, 2011: received issue

Discussion:

Issue 16019: OCL 2.3 Introduce a reserved OclSelf template parameter (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

Three library operations do not appear to be declarable without intuitive typing semantics.


Introduction of an OclSelf template parameter that is the statically determined type of self can solve the problem. OclSelf is a reserved spelling.


Classifier::allInstances(OclSelf)() : Set(OclSelf)        -- set of the derived classifier
OclAny::oclType(OclSelf)() : OclSelf                          -- my own type as statically known
OclAny::oclAsSet(OclSelf)() : Set(OclSelf)                -- set of my own and derived types, declared as the statically known type


[oclAsSet is the currently unspecified library operation used to realise implicit object-to-set conversion]


Without an OclSelf, almost any usage of these library operations must be followed by an oclAsType to the already known type.


e.g. with the OCL 2.3 type system the library function is


Classifier::allInstances() : Set(Classifier)


and so the usage is


MyType.allInstances()      -- is MyType instances as a Set(Classifier)
MyType.allInstances().oclAsType(Set(MyType))             -- necessary cast to statically known type

Resolution:
Revised Text:
Actions taken:
February 12, 2011: received issue

Discussion:

Issue 16044: OCL 2.3 Pathname syntax does not allow access to hidden names (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

If meta-models provide both 'B::x' and 'A::B::x', it is not possible to access 'B::x' from a context with 'A::B' since 9.4.1[4] searches from the current scope and so resolve 'B' in 'B::x' to 'A::B'.


Suggest adoption of the C++ '::' global prefix so that '::B::x' can be used when 'A::B' occludes.

Resolution:
Revised Text:
Actions taken:
February 27, 2011: received issue

Issue 16048: oclIsInState() (ocl2-rtf)

Click here for this issue's archive.
Source: NASA (Dr. Nicolas F. Rouquette, nicolas.f.rouquette(at)jpl.nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

Since you are working on the StateMachines chapter, it may be worth considering after the first submission adding an explanation about oclIsInState().
This query operation is unfortunately mispelled as oclInState(), see: http://www.omg.org/issues/ocl2-rtf.open.html#Issue15257
This query operation is confusingly listed as a predefined property and explained as an operation in OCL2.2, clause 7.5.9:


7.5.9 Predefined properties on All Objects 
There are several properties that apply to all objects, and are predefined in OCL. These are: 
oclIsTypeOf (t : Classifier) : Boolean 
oclIsKindOf (t : Classifier) : Boolean 
oclInState (s : OclState) : Boolean 
oclIsNew () : Boolean 
oclAsType (t : Classifier) : instance of OclType 


....
The operation oclInState(s) results in true if the object is in the state s. Possible states for the operation oclInState(s) are all states of the statemachine that defines the classifier's behavior. For nested states the statenames can be combined using the double colon “::”.

Resolution:
Revised Text:
Actions taken:
March 7, 2011: received issue

Issue 16106: OCL 2.3 - heterogeneous collections cannot be typed (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

A Collection containing both 'a', and {'b', 'c'} must be typed as a
Collection of OclAny since that is the only common type.


This is unhelpful for tree structures.


Suggest introduction of a pseudo-collection type Tree(T) to which
both T and Collection(Tree(T)) conform.


A String content tree then then be declared as a Tree(String).

Resolution:
Revised Text:
Actions taken:
April 4, 2011: received issue

Issue 16121: US PAS Ballot Comment 1 (ocl2-rtf)

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

The OMG OCL 2 Revision Task force has resolved a set of defect and clarification issues against the text in DIS 19507. (Preliminary Report http://doc.omg.org/ptc/10-12-01.pdf , Change Barred Spec http://doc.omg.org/ptc/10-11-41.pdf) It is important that the corrections resolving these defects be reflected in the published ISO/IEC Standard for OCL. The editing group for OCL 2 (DIS 19607) should consider all changes against the text of OCL 2.2, resulting from RTF defect resolutions in the latest minor revision to OCL 2, approved by the OMG PTC by the time of the ballot resolution.

Resolution:
Revised Text:
Actions taken:
April 20, 2011: received issue

Issue 16126: Issue nnnn: Japan PAS Ballot Comment 3 (ocl2-rtf) (ocl2-rtf)

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

Usage of upper/lower case letter is inconsistent with UML.
For example, “Invariant”, “Precondition”, “Postcondition”, etc, in the text should be lower case letter. However, there are UML metamodel elements, such as “Classifier”.
Especially, “collection type” in function flatten, p158, is lower case letter. If this is designated in lower case letter, it is difficult to understand the meaning of sentence. What about “collection type” L1 on 11.2.1? It is confusing whether those are metamodel elements or not.)
It is required to be consistent with convention of UML upper case letter, since this standard is a family of UML, that is, it is required to use upper case letter only for UML/OCL Metamodel element.

Resolution:
Revised Text:
Actions taken:
April 20, 2011: received issue

Discussion:

Initial Comment : It is required to be consistent with convention of UML upper case letter, since this
standard is a family of UML, that is, it is required to use upper case letter only for UML/OCL Metamodel
element.
Comment: In general metaclass names start with upper letter whereas attributes and operations with lower
letters. However within an explanatory text, to ease reading, we believe it make sense not always to use the
capitalized form to refer to a metaclass concept, specially when the term has a meaning in natural language
like “invariant”.
Anyway, a more detailed check to the spec is needed to see if this issue requires any change.
Disposition: Deferred

Issue 16127: Issue nnnn: Japan PAS Ballot Comment 4 (ocl2-rtf) (ocl2-rtf)

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

Many figures shown by UML are not unified in line color and  hatching color. Unify them.

Resolution:
Revised Text:
Actions taken:
April 20, 2011: received issue

Discussion:

Initial Comment/Suggestion: Unify them.
Comment: Figures in chapter 8 are all unified, but this is not the case for chapters 9 and 10
because they were constructed by different tools and people and not yet re-build since the FTF.
Disposition: Deferred

Issue 16128: Issue nnnn: Japan PAS Ballot Comment 5 (ocl2-rtf) (ocl2-rtf)

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

Click here for this issue's archive.
Nature: Issue from PAS Ballot comment for ISO/IEC DIS 19507
Severity:
Summary:

See comment JP 5 in “…_JISC.doc”  file in http://www.omg.org/members/cgi-bin/doc?pas/11-03-03.zip
Resolution:

Resolution:
Revised Text:
Actions taken:
April 20, 2011: received issue

Issue 16129: Issue nnnn: Japan PAS Ballot Comment 6 (ocl2-rtf) (ocl2-rtf)

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

There are same element names in both OCL and UML. Those are confusing. I wonder whether those are UML elements or OCL elements. Besides, it seems there is no clear distinction between UML/OCL (upper case letter) term and general term (lower case letter), since these are used in mixture.
- It is confusing to distinguish OCL “Constraint” from UML “Constraint” in the text. Furthermore, there are some “constraint” s (in a lower case letter). The lower case letter/upper case letters for “constraint” are mixed. 
OCL “Constraint” should be distinguishable from UML “Constrain”.

Resolution:
Revised Text:
Actions taken:
April 20, 2011: received issue

Discussion:

See comment JP 6 in “…_JISC.doc”  file in http://www.omg.org/members/cgi-bin/doc?pas/11-03-03.zip Initial Comment/Suggestion: : OCL “Constraint” should be distinguishable from UML
“Constraint”.
Comment: In fact OCL do not define the concept of Constraint since this concept is taken from UML. So
there is no need to distinguish them since they are the same concept.
A more detailed check to the spec is needed to see if this issue requires any change.
Disposition: Deferred

Issue 16132: Issue nnnn: Japan PAS Ballot Comment 9 (ocl2-rtf) Section 7.4.8 (ocl2-rtf)

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

Whereas there are some infix operator definitions in later document, this list of infix operators isn’t described sufficient. For example, there is ‘->’ definition on 7.6.1. However, ‘->’ is not included in this list. Additionally, ‘=’ is defined on 11.6.1, 11.6.2, 11.6.4, 11.6.5. However, there isn’t ‘=’ on this list. By the way. ‘=’ is not defined for Integer, and Real. Is that no problem? Furthermore, “implies” definition could not be found. Add infix operator sufficiently. And, clarify the operator definition.

Resolution:
Revised Text:
Actions taken:
April 20, 2011: received issue

Discussion:

See comment JP 9 in “…_JISC.doc”  file in http://www.omg.org/members/cgi-bin/doc?pas/11-03-03.zip

Issue 16135: Issue nnnn: Japan PAS Ballot Comment 12 (ocl2-rtf) Section 8.3.1 Fig 8.2 & FeatureCallExp in p43 (ocl2-rtf)

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

There is no attribute designation of FeatureCallExp in Fig 8.2. However, in Attribute of FeatureCallExp class description (p43), isPre is described. Add isPre to Class “FeatureCallExp” on the class diagram (Fig. 8.2)

Resolution:
Revised Text:
Actions taken:
April 20, 2011: received issue

Discussion:

See comment JP 12 in “…_JISC.doc”  file in http://www.omg.org/members/cgi-bin/doc?pas/11-03-03.zip. Initial comment/suggestion: Add isPre to Class “FeatureCallExp” on the class diagram
Comment: Normally attributes should appear in all diagrams in chapter 8 (exactly as
'stringSymbol' in Fig 8.12). Hence an update of the diagram is needed.
Revised Text:
Change Diagrams 8.8, 8.9, 13.22 and 13.23 so that FeatureCallExp has the “isPre” attribute.
Proposed Disposition: Resolved
Disposition after 1st ballot: Deferred
(Majority of YES not reached. Reason: The change should apply to Figures 8.8
and 8.9 but should not apply to figures 13.22 and 13.23 because isPre is not
part of EssentialOCL).

Issue 16137: Japan PAS Ballot Comment 14 (ocl2-rtf) - Section 8.3.2 Fig8.3 & AssociationClassCallExp (ocl2-rtf)

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

As class description, there is a AssociationClassCallExp. However, there is no Class on the class diagram in Fig.8.3.. Proposed change: Add Class “AssociationClassCallExp” on the class diagram in Fig. 8.3.

Resolution:
Revised Text:
Actions taken:
April 20, 2011: received issue

Discussion:

See comment JP 21 in “…_JISC.doc”  file in http://www.omg.org/members/cgi-bin/doc?pas/11-03-03.zip

Issue 16138: Japan PAS Ballot Comment 15 (ocl2-rtf) Section 8.3.5 Fig8.7 & following class description (p50-p51) (ocl2-rtf)

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

The class diagram on Fig8.6 & Fig8.7 and its class description is inconsistent. For example, there is TupleLIteralPart on the class diagram. However, there is no class description in p51. Additionally, as class description of CollectionLiteralPart, Associations describes “type”. Furthermore, PrimitiveLiteralExp doesn’t have any attributes on the class diagram (Fig 8.6). However, followed class description, p51, Attribute “symbol” is described. And, there is a referredEnumLiteral as class description. However, class diagram doesn’t have referredEnumLiteral on Fig. 8.6. PROPOSED RESOLUTION: Correct class diagram and its class description

Resolution:
Revised Text:
Actions taken:
April 20, 2011: received issue

Discussion:

See comment JP 21 in “…_JISC.doc”  file in http://www.omg.org/members/cgi-bin/doc?pas/11-03-03.zip

Issue 16143: Japan PAS Ballot Comment 20 Section 9.3.29 OperationCallExpCS (ocl2-rtf)

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

Synthesized attributes, [D], [F], [G]   The meaning of “and” at the end of the line is not clear and seems inconsistent with other parts. Are these logical operations? Add text to clarify this

Resolution:
Revised Text:
Actions taken:
April 20, 2011: received issue

Discussion:

See comment JP 21 in “…_JISC.doc”  file in http://www.omg.org/members/cgi-bin/doc?pas/11-03-03.zip

Issue 16144: Japan PAS Ballot Comment 21 (ocl2-rtf) Section 9.3.37 OclMessageExpCS (ocl2-rtf)

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

Synthesized attributes, [B]   TBD should not be a part of International Standard. Modify the text as appropriate

Resolution:
Revised Text:
Actions taken:
April 20, 2011: received issue

Discussion:

See comment JP 21 in “…_JISC.doc”  file in http://www.omg.org/members/cgi-bin/doc?pas/11-03-03.zip

Issue 16145: Japan PAS Ballot Comment 22 (ocl2-rtf) .4.2 NamedElement 9.4.3 Namespace, 11.2.5(p.135), 12.8.1(p.173) (ocl2-rtf)

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

Main text. TBD should not be a part of International Standard. Modify the text as appropriate.

Resolution:
Revised Text:
Actions taken:
April 20, 2011: received issue

Issue 16148: Japan PAS Ballot Comment 25 (ocl2-rtf) 10.1 Introduction, 3rd and 4th paragraphs (ocl2-rtf)

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

The term “OMG 4-layered architecture” may need to be explained or used with proper references. Modify the text as appropriate.

Resolution:
Revised Text:
Actions taken:
April 20, 2011: received issue

Discussion:

See comment JP 25 in “…_JISC.doc”  file in http://www.omg.org/members/cgi-bin/doc?pas/11-03-03.zip

Issue 16149: Japan PAS Ballot Comment 26 (ocl2-rtf) 10.2 The Values Package, 1st paragraph (ocl2-rtf)

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

UndefinedValue is explained in the text but is not included in any of the following diagrams. Add this element to the diagram.

Resolution:
Revised Text:
Actions taken:
April 20, 2011: received issue

Discussion:

See comment JP 26 in “…_JISC.doc”  file in http://www.omg.org/members/cgi-bin/doc?pas/11-03-03.zip

Issue 16152: Japan PAS Ballot Comment 29 (ocl2-rtf) 10.2.4 Overview of the Values Package (ocl2-rtf)

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

Figure 10.5 StringValue only appears here. No explanation was given before the diagram. Add definition or explanation of StringValue before this diagram

Resolution:
Revised Text:
Actions taken:
April 20, 2011: received issue

Discussion:

See comment JP 29 in “…_JISC.doc”  file in http://www.omg.org/members/cgi-bin/doc?pas/11-03-03.zip

Issue 16155: Japan PAS Ballot Comment 32 (ocl2-rtf): 10.3.1 Definitions of Concepts for the Evaluations Package, figure 10.11 (ocl2-rtf)

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

TupleLiteralExpPartEval is not included in Figure 10.11.  Is VariableDeclEval the one? Add this element to Figure 10.11.

Resolution:
Revised Text:
Actions taken:
April 20, 2011: received issue

Discussion:

See comment JP 32 in “…_JISC.doc”  file in http://www.omg.org/members/cgi-bin/doc?pas/11-03-03.zip

Issue 16161: OCL 2.3 7.5.3 Missing Association End name problems (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

The 'clarified' text in OCL 2.3 for missing association ends, is still unclear.


Problem 1: if multiple association ends acquire the same name, what happens? Suggest: they all acquire the same name and the resulting lookup up finds multiple names which should be diagnosed as an ambiguity and consequently a semantic error.


Problem 2: if a missing association end is recursive, a class acquires a property with the same name as the class. Consequently invocation of e.g X.allInstances() for class X may encounter an ambiguity while resolving X. Is it self.X or global X? Suggest: auto-generated missing names may only be invoked via a navigation operator.


Problem 3: does a derived association end get a resolution for a missing name? if OCL is used to define a number of helper properties that all return the same type, then provision of the  missing 'opposites' results in unhelpful clutter at best. Suggest: missing names are not provided for derived association ends.

Resolution:
Revised Text:
Actions taken:
April 26, 2011: received issue

Issue 16168: OCL 2.3 Enumeration::allInstances() does not return instances (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

a)  an OrderedSet would be more appropriate
b) enumeration literals are instances of EnumerationLiteral; they are not instances of an Enumeration


cf. MyClass.allInstances() dynamically overloads Classifier.allInstances() to return all known instantiations of MyClass, rather than all features of MyClass.


so why does MyEnumeration.allInstances() prevent me discovering all instantiations of MyEnumeration; Enumeration is a Classifier.


The required functionality of MyEnumeration::allInstances() is available as MyEnumeration.ownedLiteral provided reflection is consistently defined.


Suggest: remove the Enumeration.allInstances() overload.

Resolution:
Revised Text:
Actions taken:
May 6, 2011: received issue

Issue 16235: Use of the word meta (ocl2-rtf)

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

I want to signal that the use of the word "meta" is confusing. Here is an example on page 47.


*TypeExp*
A TypeExp is an expression used to refer to an existing meta type within an expression.


According to Merriam-Webster, "meta" is usually a prefix that could be added at the beginning of a word. This particle should be merged to the main word (like in metabasis) or attached using an hyphen (like meta-analysis).


In consequence, we should read "metatype" which seems to hold the correct meaning. It is coherent with metaclass, for example. By the way, "metatype" is used at many places in the document. 


In some contexts and in the familiar language, you can use "meta" as a diminutive for something when its meaning is obvious. For example, "the meta is broken" when you mean the metacarpus. In a specification document and in a context where we have to differentiate many metaconcepts, it doesn't have its place.

It is seen at many places in this document and may be other. In this one, we see "meta model" and "meta-model", while the word "metamodel" should be and is effectively used.

Resolution:
Revised Text:
Actions taken:
May 13, 2011: received issue

Issue 16260: on page 153 oclIsInState is used instead of oclInState (ocl2-rtf)

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

On page 153 oclIsInState(statespec : OclState) is used to check if an object is in a specified state. But in Section 7.5.9 on page 22 oclInState(statespec : OclState) is used for this purpose and examples are given.


There is one more occurrence of oclIsInState on page 47 of Section 8.3.1, but this is talking about the abstract syntax, therefore it could be valid. But I think definitely not for the concrete syntax of the OCL.


Strangely enough the Eclipse Interactive OCL Console implements oclIsInState() and not oclInState().


I would appreciate a clarification which statement to use very much!

Resolution:
Revised Text:
Actions taken:
May 20, 2011: received issue

Issue 16291: Confusing usage of the "precedes" symbol for generalization hierarchy (ocl2-rtf)

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

The symbol &#8826; is used in this page. According to Unicode definition, this symbol represents a mathematical symbol whose definition is "precedes". Here is the reference of that definition :
http://unicode.org/cldr/utility/character.jsp?a=227A


I'm not a mathematician and I don't know precisely what this symbol means for mathematicians, even if I searched in many books and on the Internet. However, I find very confusing to use a symbol that means "precedes" to means "is the child of". 


There is another symbol &#8827; which means 'succeeds' that would be less confusing in the sense of "C1 succeeds C2" to means that C1 is the child of C2. 

As I'm not mathematician, I may be completely wrong and I would greatly appreciate a sound reference where this symbol is defined formally.

Resolution:
Revised Text:
Actions taken:
May 28, 2011: received issue

Issue 16302: Prime symbol lacking in the explanation preceding the formula (ocl2-rtf)

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

In the 3rd item of the definition A.12 (System State), the paragraph before the formula ends by :
 "whereas the function &#61552;i(l) projects all but the ith component):"

The function is exactly the same as the first function in the same sentence. It appears that a prime symbol is missing in the function. Indeed, a prime symbol appears in the formula.

Resolution:
Revised Text:
Actions taken:
June 1, 2011: received issue

Issue 16303: Unbalanced parenthesis in the formula (ocl2-rtf)

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

The last formula in the definition A.12 has unbalanced parenthesis.
The first parenthesis after the = sign seems in excess.

Resolution:
Revised Text:
Actions taken:
June 1, 2011: received issue

Issue 16305: Comparison operators don't exist for Boolean (ocl2-rtf)

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

In the table A.1 (Schema for operations on basic types), the operations {<, >, <, >} are defined as applicable to {UnlimitedNatural, Integer, Real, String, Boolean}.
While the result is certainly Boolean, the parameters can't be Boolean in general, unless UML defined such operators for Booleans. According to section 11.5.4, there is no definition for the operators. Then Boolean should be removed in the set.

Resolution:
Revised Text:
Actions taken:
June 1, 2011: received issue

Issue 16306: The t should be subscripted next to the equal sign (ocl2-rtf)

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

At the top of the page, there is a formula to define the equal operator. The formula begins with I(=t). That t should be subscripted as we see in the sentence that precedes the formula.

Resolution:
Revised Text:
Actions taken:
June 1, 2011: received issue

Issue 16348: OCL 2.3 Collecting elemental collections (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

collect and collectNested have irregular semantics that ignore the natural (outer) collection element type when used on nested collections:


i.e Set{Set{1.0}}->collect(toString()) is Set{Set{1.0}}->collect(s : String | s.toString())


so how might an iteration over the outer collection element type be performed?


Presumably, for homegeneous collections, by explicitly specifying the iterator type as Set{Set{1.0}}->collect(s : Set(String) | s->size())


Suggest: collect, collectNested specify that the implicit iterator type is the innermost collection type, and that an explicit type may
specify a collection type that successfully iterates when all leaves of the tree are uniquely contained in a corrsponding iteration element
of the iterator type, else the iteration is invalid.


Can't see a solution for heterogeneous solutions

Resolution:
Revised Text:
Actions taken:
June 25, 2011: received issue

Issue 16370: OCL parsed OCL string literal (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

As part of the support for lambda expressions an ability to parse OCL from a string would be useful

Resolution:
Revised Text:
Actions taken:
July 14, 2011: received issue

Issue 16487: OCL 2.3 A.2.6 Collection conforms to OclAny contradiction (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

Issue 12948 "Making OclAny denote any object" was resolved to allow Collection to conform to OclAny.


A.2.6 still states "A simple set inclusion semantics for subtype relationships as described in the next sub section would not be possible due to cyclic domain definitions if OclAny
were the supertype of Set(OclAny)."


A premise for Annex A has therefore been violated requiring rework to consider at least a less simple set inclusion semantics.

Resolution:
Revised Text:
Actions taken:
August 6, 2011: received issue

Issue 16911: OCL 2.3: Message support hard to consume (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

The support for messages uniquely requires dedicated concrete syntax: ^, ^^, ?


This makes provision of Essential OCL tooling without messages and Complete OCL tooling with messages hard.


The operators are hard to remember and inconsistent with OCL where "forAll" is favoured over upside-down A.


Suggest replace ^,^^,? by OclElement::hasSent(), OclElement::messages() and Message::Unspecified (possibly just null), so that Messages can be modularized as an Standard Library extension of additional types, operations and attributes only. No concrete syntax change.

Resolution:
Revised Text:
Actions taken:
December 14, 2011: received issue

Issue 16936: need clear specification for how to write OCL that refers to the stereotypes applied to a model within a UML profile (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

Yet another query on an Eclipse newsgroup has asked how stereotypes/profiles work in a transformation language, so I've taken a brief look and it appears that UML 2.5 Section 12 appears gives the only clue as to how an OCL expression might navigate a Stereotype:


self.base_Interface.ownedAttributes->size() = 0


This is a particularly unfortunate example since it uses reflection, or at least multiple meta-levels, which are not currently supported in OCL 2.x.


Once OCL supports reflection and type literals, I would expect to see something more like


Interface.ownedAttribute->size() = 0


The constraint presumably is that the stereotype has no attributes, regardless of the class to which it is applied.


Reflective operation might do something like


self.oclType().selectFragment(Interface).ownedAttribute->size() = 0


(if selectFragment is an OCL library operation that selects a type merge contribution).


The utility of the meta-level traversing 'base_xxxx' and 'extension_xxxx' seems very suspect. Does any tool support them? I know Eclipse UML2 has at least a 'base_xxxx' name, but I doubt that it is reflective. It's sole purpose seems to be to give me trouble with validation errors.


-----------------


It seems to me that in the same way that (for base classes):


A class C (with property c) may have base classes B1 (with properties b, b1) and B2 (with property b, b2) allowing implicit access such as aC.c, aC.b1, aC.b2, but requiring qualification for aC.B1::b and allowing redundant qualification for aC.B1::b1.


then (for stereotypes):


A Class C may have stereotypes S1 (with properties s, s1) and S2 (with properties s, s2) allowing implicit access such as aC.s1, aC.s2, but requiring qualification for aC.S1::s and allowing redundant qualification for aC.S1::s1. The implicit access is only permissible when it is statically known that the Stereotype has been applied, i.e for an expression whose context is the Stereotype. In more general contexts the Stereotype qualification may need a run-time check and an invalid result if the Stereotype has not been applied. Thus:


not aC.S1::s1.oclIsInvalid() implies some-expression-when-S1::s-exists


If property overloading is forbidden, but operation overloading permitted, in the above


adding a property C::b, or S1::c or S2::b2 would be a static error since the added property overloads a property name already present in the extended class. Note that this is not in accord with the current OCL specification that motivates the introduction of qualification to support access to hidden property names, which UML prohibits.


adding any operation in a stereotype is valid; it is either a new or overloaded operation. However two stereotypes contributing the same operation signature is a static error to be detected by the attempt to apply both stereotypes.


Since the WFRs for the above belong in UML, presumably the above should be in the UML specification, and the OCL specification should just map the alternate navigation syntaxes appearing in the UML specification to appropriate Concrete and Abstract Syntax Expression elements.

Resolution:
Revised Text:
Actions taken:
December 30, 2011: received issue

Discussion:

Issue 16998: OCL 2.3 OclInvalid::= is vague (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

Issue 14197 finally resolved the semantiscs of OclInvalid, but the end result was that there is no OclInvalid section in 11.3. Add an 11.3.x for OclInvalid that enumerates all relevant OclInvalid behaviors; in particular = and <> return invalid for any invalid argument.

Resolution:
Revised Text:
Actions taken:
January 14, 2012: received issue

Issue 17220: OCL String::indexOf (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

The description of String::indexOf() states "No string is a substring of the empty string.".


This modifies the axiom that every string is a substring of itself. It would appear that the empty string has got confused with null.


An extension of the library with startsWith and endsWith operations would require the modified axiom to be accommodated making corner cases equivalently strange.


This modified axiom is not observed by other String libraries such as the java.lang.String.


Suggest: Replace the text:


"The empty string is considered to be a substring of every string but the empty string, at index 1. No string is a substring of the empty string."


by


"The empty string is a substring of every string at index 1 (and also at all other indexes)."

Resolution:
Revised Text:
Actions taken:
March 9, 2012: received issue

Issue 17306: ISO has changed the following normative references to its documents (ocl2-rtf)

Click here for this issue's archive.
Source: Object Management Group (Ms. Linda Heaton, linda(at)omg.org)
Nature: Uncategorized Issue
Severity:
Summary:

ISO 639 has been replaced by a six-part series.  The new reference should be:  ISO 639 (all parts)
ISO 3166 has been replaced by a three part series.  The new reference should be:  ISO 3166 (all parts)
ISO 10646 is new and this reference should be:  ISO 10646:2011, Information technology - Universal Coded Character Set (UCS)

Resolution:
Revised Text:
Actions taken:
April 12, 2012: received issue

Issue 17463: Navigation from Association Classes does not conform to UML 2.4.1 (ocl2-rtf)

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

The navigation from Association Classes does not conform to UML 2.4.1 because of 7.3.4 AssociationClass on page 44 UML Superstructure Specification, v2.4.1. the kind of navigation allowed by OCL is not allowed by UML, i.e. the navigation from the association class to the ends of the association is explicitly not allowed by UML but allowed by OCL. I see here a contradiction. I checked UML 2.1.2 from 2007 and in that UML this navigation from the association class the ends of the association was still allowed. I think that OCL 2.3.1 is not compatible with UML 2.4.2 from this point of view. Please tell me if this opinion is correct. If this contradiction that I remarked really exists than what to expect from the future: OCL or UML point of view?

Resolution:
Revised Text:
Actions taken:
July 1, 2012: received issue

Issue 17531: non(not(X)) should be X (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Revision
Severity: Minor
Summary:

In http://www.linkedin.com/redirect?url=http%3A%2F%2Fwww%2Ebrucker%2Ech%2Fprojects%2Fhol-ocl%2FFeatherweight-OCL%2Foutline%2Epdf&urlhash=vacm&_t=tracking_anet Burkhart Wol ff argues that lopgical consistency requires that not(not(X)) is X.


OCL 2.3.x does not satisfy this for 'null'.

Similary null and true  = null not invalid ...

Resolution:
Revised Text:
Actions taken:
July 27, 2012: received issue

Issue 18125: any iteration unsuitable for null Collection content (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Clarification
Severity: Minor
Summary:

The any() iteration is specified to return null in the event that no match is found. However null could also be the return of a successful match of null. e.g


Sequence{null}->any(s | s = null)

Suggest: change the match-not-found return to invalid.

Resolution:
Revised Text:
Actions taken:
September 27, 2012: received issue

Issue 18254: Align OCL bodyExpression and UML bodyCondition (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Clarification
Severity: Minor
Summary:

OCL 12.10 awaits alignment with the UML 2.0 metamodel.


Consequently, the relationship between a result-valued OCL bodyExpression and a Boolean-valued UML bodyCondition is unspecified. A common pragmatic resolution has been to equate the two and ignore the Boolean-valued requirement of a UML Constraint.


In order to accommodate prevailing practice and also support UML's multiple out/inouts, suggest:


Reinterpret the grammar


prePostOrBodyDeclCS ::= ‘body’ (simpleNameCS)? ‘:’ OclExpressionCS


such that


the simpleNameCS is the name of the return parameter with 'result' as the anonymous default


OclExpressionCS is a result-valued bodyExpression if OclExpressionCS does not reference the simpleNameCS or its defgault.
OclExpressionCS is a Boolean-valued bodyCondition if the return parameter is referenced.


[Allow multiple body declarations.]


Thus


"body: ..." is a shortform of "body result: ..." which is a shortform for "body result: result = ..."


and


body: ...
body A: ...
body B: ...


could be the specification of a UML operation

f(out a : A, inout b : B, in c : C) : Z

Resolution:
Revised Text:
Actions taken:
November 9, 2012: received issue

Issue 18255: Align OCL with out/inout UML Operation Parameters (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Clarification
Severity: Minor
Summary:

OCL 9.4.5 gives no recommendation on how to handle the multiple out capability of UML.


Suggest that the mapping of a UML operation with out or inout parameters to an OCL operation do the following:


remove all 'out' parameters from the OCL parameter list so that the OCL parameter list contains only 'in' and 'inout' parameters with 'read-only' behavior


change the return type to a Tuple whose part-names and types are determined by the conventional 'result' and the 'out' and 'inout' parameters.

It is also desirable to relax the upper multiplicity bound to allow multiple bodyExpressions in Complete OCL, one bodyExpression per returning parameter.

Resolution:
Revised Text:
Actions taken:
November 9, 2012: received issue

Issue 18319: OclAny::oclAsType postcondition implies type change (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Clarification
Severity: Minor
Summary:

post: (result = self) and result.oclIsTypeOf( t )


requires oclAsType to change the type of self.


The constraint should be:


post: (result = self) and result.oclIsKindOf(t)


[Review all usage of oclIsType() since it's nearly always wrong to use oclIsType rather than oclIsKindOf.]

Resolution:
Revised Text:
Actions taken:
December 14, 2012: received issue

Issue 18437: Clarify invalid propgation/conformance priority (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Clarification
Severity: Minor
Summary:

There is a contradiction between invalid conform to anything and invalid always propagates for e.g.


Sequence{}->first().oclIsKindOf(Class)


oclIsKindOf uses the invalid input to return true.


Invalid propagation should dominate giving invalid.

This requires OclInvalid::oclIsKindOf, oclIsTypeOf, oclType, oclAsType overloads to explicitly return invalid.

Resolution:
Revised Text:
Actions taken:
February 11, 2013: received issue

Issue 18464: Inconsistent inclusion of source in closure results (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Clarification
Severity: Minor
Summary:

"The returned collection of the closure iteration is an accumulation of the source, and the collections resulting from ..."

incorrectly includes the source. The algorithm in 11.9.1 correctly includes the source only if the source is reached by some traversal from the source.

Resolution:
Revised Text:
Actions taken:
February 20, 2013: received issue

Issue 18504: Collection::any() violates precondition if the collection is empty (ocl2-rtf)

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

Section 11.9.1.4 states that "there must be at least one element fulfilling body, otherwise the result of this IteratorExp is null."  And defines


source->any(iterator|body) = source->select(iterator | body)->asSequence()->first()


However 


let seq:Sequence<T>=source->select(body)->asSequence()
in source->any(body)=seq->at(1)


>From section 11.7.5


 context Sequence::first() : T 
 post: result = self->at(1)


 context Sequence::at(i : Integer) : T 
 pre : i >= 1 and i <= self->size()


If there is no element fulfilling body, then seq is empty and the precondition of Sequence::at does not hold because 1 > seq->size().

Related to: Issue 18125 [OCL 2.4]

Resolution:
Revised Text:
Actions taken:
February 26, 2013: received issue

Issue 18515: Collection::min/max accumulator initialized as self.first() (ocl2-rtf)

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

The accumulator in the definition of Collection::min and Collection::max is initialized as self.first(). 


post: result = self->iterate( elem; acc : T = self.first() | acc.min(elem) )


post: result = self->iterate( elem; acc : T = self.first() | acc.max(elem) )


The accumulator should be initialized as self.asSequence()->first(), because Collection::first() is undefined.

Resolution:
Revised Text:
Actions taken:
March 1, 2013: received issue

Issue 18516: Introduce a Safe Navigation Operator (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Clarification
Severity: Minor
Summary:

Languages such as Groovy have found it helpful to intrioduce the safe navigation operator ?: so that navigation over null yields null rather than a problem (invalid in OCL).


In OCL it could be a pure syntax sugar:


(x?.y) = (if x == null then null else x.y endif)


or perhaps an additional PropertyCallExp operator

Resolution:
Revised Text:
Actions taken:
March 1, 2013: received issue

Issue 18539: Complete OCL document must be a Package (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Clarification
Severity: Significant
Summary:

In order for a UML model to import some Complete OCL for use in the model's constraints, a Complete OCL document must be a (derived) Package. Any tool can therefore import Complete OCL using its conventional metamodel import syntax; just needs per-tool support.


Complete OCL documents must not conflict. For instance if MM imports COD1 for its own purposes and then your usage imports MM (and COD1) and also COD2, the declarations in COD2 may not introduce anything that requires re-analysis of the OCL expressions in MM or COD1; the only change to MM+COD1 execution may arise through additional derived virtual functions.


Avoiding conflicts requires some strong WFRs.


Once conflicts are avoided, Complete OCL documents can be pre-compiled and loaded in compiled form.

Resolution:
Revised Text:
Actions taken:
March 10, 2013: received issue

Issue 18829: Introduce selectByKind and selectByType operations (ocl2-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Clarification
Severity: Minor
Summary:

A very common 'idiom' in OCL expressions is


sources->select(oclIsKindOf(T))->collect(oclAsType(T))->asSet()


to select the sub-set of type T.


This involves four library calls and requires T to be typed twice.


In practice 


sources->select(oclIsKindOf(T)).oclAsType(T)


may save one operation call at the expense of the wrong collection type.


Suggest introduce


sources->selectByKind(T)
sources->selectByType(T)


to simplify this oclIsKindOf/oclIsTypeOf usage.

Resolution:
Revised Text:
Actions taken:
July 21, 2013: received issue