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.

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

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.

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

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

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.

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

Allow defining default values for parameters in operations

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

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

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’

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.

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..."

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.

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

[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.

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’

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.

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.

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

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?

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

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

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

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?".

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.

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

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

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.

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 --.

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.

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.

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.

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

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

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.

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.

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.

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.

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.

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.

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

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

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

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

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

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

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

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.

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

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.

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.

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.

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".

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

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’

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

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

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.

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.

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!

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

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

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.

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.

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.

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.

– 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{}

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’

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

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.

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

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

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’

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

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

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