Because UnspecifiedValueExp is a special kind of OclExpression, it is not necessary to define an explicit unspecified property. One can check the type of the OclExpression to see whether we are in the unspecified situation. This also make useless the need to define a specific getType() helper operation for OclMessageArg since the type can direcly be obtained.

No Data Available

In 8.2 the sentence "Users will never instanciate these types explicitly" is not entirely true. When a OCL writer defines a helper operation that returns a set, he explicitly declares the Set to be returned. Also, according to the OCL metamodel, an expression always has a type (OclExpression::type has multiplicity equal to 1). So when using the metamodel to exchange OCL specifications (XMI exchange) this implies that all used types, including expressions yielding to collection types have to be instanciated for the XMI to be well-formed.

No Data Available

A OclMessageExp can directly represent the arguments without the need of an intermediate class, just as OperationCallExp refer to its arguments

No Data Available

The composition associations in figure 9 are missing. In particular, a message
expression (OclMessageExp) should contain its arguments, its target expression, are –probably – specified call action. Otherwise the model cannot be properly instanciated

No Data Available

According to figure 9, the UnspecifiedValueExp does not inherits from OclExpression. However this is contradictory with the text description of the metaclass (and it own name).

No Data Available

The type property of UnspecifiedValueExp can be obtained from a superclass (for instance TypedElement or OclExpression

No Data Available

An UnlimitedNaturalExp should be added in the metamodel to be used to access upper bound values in multiplicity specifications. This will be conformant with UML2 primitive literals

No Data Available

Except for the abstract OclExpression metaclass which differentiates from the UML class Expression, the other metaclasses OclMessageType, OclMessageExp and OclMessageArg should better be renamed MessageType, MessageExp and MessageArg to improve uniformity and readability of the metamodel.

No Data Available

Referring to the OclHelper stereotype in the well-formedness rules should be avoided since not strictly necessary. It should be possible yo use OCL in UML without using stereotypes

No Data Available

In the well-formedness rules there is a class named TupleLiteralExpPart but in the diagram VariableDeclaration is strangely used to represent the literal tuple parts.

No Data Available

The naming to refer to the parts of tuple literals and collection literals should be uniformized. For tuples it is called 'tuplePart' and for collection literals it is called 'parts'. Also the CollectionLiteralExp::parts and TupleLiteralExp::tuplePart properties is only depicted in the diagrams (missing in the class descriptions)

No Data Available

The description of the CollectionKind should indicate the list of possible values

No Data Available

In particular the properties NavigationCallExp::qualifiers, OperationCallEXp::arguments should be renamed NavigationCallExp::qualifier and OperationCallEXp::argument.

No Data Available

The link between a variable representing a parameter and the parameter should be made explicit.

The link between a variable and a parameter is currently not explicitly modelled in the OCL abstract syntax. It depends on name comparison. This adds unnecessary complexity to implementers.

No Data Available

The OCL spec does not define who is the container of the 'self', the 'result' and other variables bound to the parameters of an operation. This makes the OCL instanciation incomplete and invalid.

No Data Available

In the association list of the OclExpression metaclass description, the 'appliedProperty', 'parentOperation' and 'initializedVariable' are non navigable and should be removed. In addition the 'type' property should be inherited from the UML2 metaclass TypedElement.

No Data Available

In the well-formedness rules of OclMessageType (section 8.2.2), the self.feature cannot be equal to the result of the asParameter() operation. The rule need to be rewritten so that the value of the slots are compared (the 'name' and 'type' instead of comparing the object themselves).

A similar problem occurs in the well-formedness rule [2] of OclMessageType (section 8.2.2), the self.feature cannot be equal to the result of the 'referredSignal.feature' since in that case the referred features will be contained twice.

No Data Available

The concept representing a parameter declaration is not called ParameterDeclaration but Parameter. Similarily, the concept corresponding to variable declaration should be called Variable. Also this concept already exists in UML2 and the name chosen for the metaclass is Variable.

Also the name property of the variable can be taken from the super class NamedElement instead of having a specific varName attribute.

No Data Available

Figure 28 defines specific inheritance links between M1 types that are
not inferred from M2 types. This links should be suppressed since it brings
confusion and unnecessary complexity to the standard library
definition. The particular compliance rules of OclVoid and OclAny can be defined independently of the "inheritance" formalism.

No Data Available

Classifier is an abstract class. It is then not possible to define the OclAny of the standard library as a direct instance of classifier.

Suggestion: Define a AnyType metatype

No Data Available

On the left side of the equals symbol is the word "select" correct or should it be "iterate?"

No Data Available

Now it is too early in the morning because the statement "Results in true if body evaluates to true for at least one element in the source collection" does not make sense with the OCL notation on the right side of the equals symbol "source->iterate(iterators; result:Boolean = false | result or body)." One says true, the other says false.

No Data Available

It's late in the day but I do not see that the OCL definition for union(s:Set(T)): Set(T) is totally accurate because it does not mention that self and s cannot contain the same element or the union of self and s would be a bag not a set. I am also confused by the last post for bothe asSequenced(): Sequence(T) and asBag(): Bag(T) where the result->count(elem)=1. Should this be result->count(elem)>=1 in both cases because you're writing about sequences and bags?

No Data Available

39. The association between ’StringValue.iterators’ and ’LoopExpEval’ should be ordered on the side
of ’StringValue.iterators’.

No Data Available

def: lookupAttribute(attName : String) : Attribute =
self.allAttributes->any(me | me.name = attName)
def: lookupAssociationEnd(name : String) : AssociationEnd =
self.allAssociationEnds->any (ae | ae.name = name)
def: lookupAssociationClass(name : String) : AssociationClass =
self.allAssociationClasses->any (ae | ae.name = name)
def: lookupOperation (name: String, paramTypes: Sequence(Classifier)):
Operation =
self.allOperations->any (op | op.name = name and
op.hasMatchingSignature(paramTypes))
def: lookupSignal (sigName: String, paramTypes: Sequence(Classifier)):
Operation =
self.allReceptions.signal->any (sig | sig.name = sigName and
sig.hasMatchingSignature(paramTypes))
==> all references to operations like allAttributes are missing brackets, and the returnType of lookup-
Signal should be Signal. The whole expression should be:
context Classifier
def: lookupAttribute(attName : String) : Attribute =
self.allAttributes()->any(me | me.name = attName)
def: lookupAssociationEnd(name : String) : AssociationEnd =
self.allAssociationEnds()->any (ae | ae.name = name)
def: lookupAssociationClass(name : String) : AssociationClass =
self.allAssociationClasses()->any (ae | ae.name = name)
def: lookupOperation (name: String, paramTypes: Sequence(Classifier)):
Operation =
self.allOperations()->any (op | op.name = name and
op.hasMatchingSignature(paramTypes))
def: lookupSignal (sigName: String, paramTypes: Sequence(Classifier)):
Signal =
self.allReceptions().signal->any (sig | sig.name = sigName and
sig.hasMatchingSignature(paramTypes))

No Data Available

30. context TTupleType::make(atts : Sequence(UML14::Core::Attribute) ) : TTupleType
post: result.features = atts
post: result.stereotype.name = ’OclHelper’
==> should be: context TTupleType::make(atts : OrderedSet(UML14::Core::Attribute) ) :
TTupleType
post: result.feature = atts
post: result.stereotype.name = ’OclHelper’

No Data Available

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

No Data Available

28. – [1] The name of a bag type is "Bag" followed by the element type’s name in
– parentheses.
context BagType
inv: self.name = ’Bag(’ + self.elementType.name + ’)’
– [1] The name of a collection type is "Collection" followed by the element
– type’s name in parentheses.
context CollectionType
inv: self.name = ’Collection(’ + self.elementType.name + ’)’
– [1] The name of a set type is "OrderedSet" followed by the element type’s name
– in parentheses.
context OrderedSetType
inv: self.name = ’OrderedSet(’ + self.elementType.name + ’)’
– [1] The name of a sequence type is "Sequence" followed by the element type’s
– name in parentheses.
context SequenceType
inv: self.name = ’Sequence(’ + self.elementType.name + ’)’
– [1] The name of a set type is "Set" followed by the element type’s name in
– parentheses. context SetType
inv: self.name = ’Set(’ + self.elementType.name + ’)’
==> ’’ should be replaced by ’concat’ or ’’ should be allowed as concrete syntax for the String concat
operation.
inv: self.name = ’Bag(’.concat( self.elementType.name).concat(’)’)
inv: self.name = ’Collection(’.concat(
self.elementType.name).concat(’)’)
inv: self.name = ’OrderedSet(’.concat(
self.elementType.name).concat(’)’)
inv: self.name = ’Sequence(’.concat( self.elementType.name).concat(’)’)
inv: self.name = ’Set(’.concat( self.elementType.name).concat(’)’)

No Data Available

27. context TTupleType::make(atts : sequence(Attribute) ) : TTupleType
post: result.features = atts
post: result.stereotype.name = ’OclHelper’ ==> ’sequence(Attribute)’ should be ’Sequence(UML14::Core::Attribute)’

No Data Available

26. – [1] The type of a TupleLiteralExp is a TupleType with the specified parts.
context TupleLiteralExp
inv: type.oclIsKindOf (OclAbstractSyntax::Types::TTupleType)
and
tuplePart->forAll (tlep |
type.allAttributes()->exists (tp | tlep.attribute = tp))
and
tuplePart->size() = type.allAttributes()->size()
==> should be
context TupleLiteralExp
inv: type.oclIsKindOf (OclAbstractSyntax::Types::TTupleType)
and
tuplePart->forAll (tlep |
type.allAttributes()->exists (tp | tlep.asAttribute().name = tp.name and
tlep.asAttribute().type = tp.type and
tlep.asAttribute().initExpression = tp.initExpression))
and
tuplePart->size() = type.allAttributes()->size()

No Data Available

23. – [1] The type of a TupleLiteralExp is a TupleType with the specified parts.
context TupleLiteralExp
inv: type.oclIsKindOf (TupleType) and
tuplePart->forAll (tlep |
type.oclAsType (TupleType).allAttributes()->exists (tp | tlep.attribute
= tp))
and
tuplePart->size() = type.oclAsType (TupleType).allAttributes()->size()
==> should be:
context TupleLiteralExp
inv: type.oclIsKindOf (OclAbstractSyntax::Types::TTupleType)
and
tuplePart->forAll (tlep |
type.allAttributes()->exists (tp | tlep.asAttribute().name = tp.name and
tlep.asAttribute().type = tp.type and
tlep.asAttribute().initExpression = tp.initExpression))
and
tuplePart->size() = type.allAttributes()->size()

No Data Available

25. – [1] The type of the attribute is the type of the value expression.
context TupleLiteralExpPart
inv: attribute.type = value.type
==> should be removed, the type ’TupleLiteralExpPart’ does not exist.

No Data Available

24. – [2] All tuple literal expression parts of one tuple literal expression have
– unique names.
context TupleLiteralExp
inv: tuplePart->isUnique (attribute.name)
==> should be:
context TupleLiteralExp
inv: tuplePart->isUnique (name)

No Data Available

22. – [2] If the message is a send action, the arguments must conform to the
– attributes of the signal.
context OclMessageExp
inv: sentSignal->notEmpty() implies
arguments->forAll (a | a.getType().conformsTo
(self.sentSignal.signal.feature.oclAsType(StructuralFeature)
>at (arguments>indexOf (a)).type))
==> should be:
context OclMessageExp
inv: sentSignal->notEmpty() implies
arguments->forAll (a | a.getType().conformsTo
(self.sentSignal.signal.feature
>at (arguments>indexOf
(a)).oclAsType(UML14::Core::StructuralFeature).type) )

Discussion:
This well-formed rule is correct in the current OCL 2.0 specification. It is a duplicate of the issue 7471.
Disposition: See Issue 7471 for disposition

21. – [1] If the message is a call action, the arguments must conform to the
– parameters of the operation.
context OclMessageExp
inv: calledOperation->notEmpty() implies
arguments->forAll (a | a.getType().conformsTo
(self.calledOperation.operation.Parameter->
select( kind = UML14::Core::ParameterDirectionKind::In )
>at (arguments>indexOf (a)).type))

No Data Available

20. – [1] If the message is a call action, the arguments must conform to the
– parameters of the operation.
context OclMessageExp
inv: calledOperation->notEmpty() implies
arguments->forAll (a | a.getType().conformsTo
(self.calledOperation.operation.parameter->
select( kind = ParameterDirectionKind::In )
>at (arguments>indexOf (a)).type))
==> ’parameter’ should be ’Parameter’

No Data Available

==> add the following:
context OperationCallExp
def: refParams: Sequence(UML14::Core::Parameter) =
self.referredOperation.Parameter->asSequence()
==> see also number 21.

No Data Available

18. – [1] All the arguments must conform to the parameters of the referred operation
context OperationCallExp
inv: arguments->forall (a | a.type.conformsTo
(self.refParams->at (arguments->indexOf (a)).type))
==> ’forall’ should be ’forAll’

No Data Available

15. – [2] If the message is a send action, the arguments must conform to the
– attributes of the signal.
context OclMessageExp
inv: sentSignal->notEmpty() implies
arguments->forall (a | a.getType().conformsTo
(self.sentSignal.signal.feature.oclAsType(StructuralFeature)
>at (arguments>indexOf (a)).type))
==> ’forall’ should be ’forAll’

No Data Available

14. – [1] If the message is a call action, the arguments must conform to the
– parameters of the operation.
context OclMessageExp
inv: calledOperation->notEmpty() implies
arguments->forall (a | a.getType().conformsTo
(self.calledOperation.operation.parameter->
select( kind = ParameterDirectionKind::In )
>at (arguments>indexOf (a)).type))
==> ’forall’ should be ’forAll’

No Data Available

context OclMessageExp
inv: not target.type.oclIsKindOf (CollectionType)
==> ’CollectionType should be ’OclAbstractSyntax::Types::CollectionType’

No Data Available

16. – [4] An OCL message has either a called operation or a sent signal.
context OclMessageExp
inv: calledOperation->size() + sentMessage->size() = 1
==> ’sentMessage’ should be ’sentSignal’

No Data Available

context IfExp
inv: self.condition.type.oclIsKindOf(Primitive) and
self.condition.type.name =
’Boolean’
==> ’Primitive’ should be ’UML14::Core::Primitive’

No Data Available

[2] The result type of the collect operation on a sequence type is a sequence,
– the result type of ’collect’ on any other collection type is a Bag. The type
– of the body is always the type of the elements in the return collection.
context IteratorExp
inv: name = ’collect’ implies
if source.type.oclIsKindOf(SequenceType) then
type =
expression.type.collectionType->select(oclIsTypeOf(SequenceType))-
>first()
else
type = expression.type.collectionType->select(oclIsTypeOf(BagType))-
>first()
endif
==> should be
context IteratorExp
inv: name = ’collect’ implies if source.type.oclIsKindOf(OclAbstractSyntax::Types::SequenceType) then
self.type = StandardLibrary::StdLib::Sequence
and
self.Body.type = Body.type
else
self.type = StandardLibrary::StdLib::Bag
and
self.Body.type = Body.type
endif

No Data Available

[1] If the iterator is ’forAll’, ’isUnique’, or ’exists’ the type of the
– iterator must be Boolean.
context IteratorExp
inv: name = ’exists’ or name = ’forAll’ or name = ’isUnique’
implies type.oclIsKindOf(Primitive) and type.name = ’Boolean’
==> ’Primitive’ should be ’UML14::Core::Primitive’

No Data Available

context IteratorExp
inv: self.iterators->forAll(type = source.type.oclAsType
(CollectionType).elementType)
==> ’CollectionType should be ’OclAbstractSyntax::Types::CollectionType’

No Data Available

context LoopExp
inv: source.type.oclIsKindOf (CollectionType)
==> ’CollectionType should be ’OclAbstractSyntax::Types::CollectionType’

No Data Available

– [2] The type of a collection literal expression is determined by the
– collection kind selection and the common supertype of all elements. Note that
– the definition below implicitly states that empty collections have OclVoid as
– their elementType.
context CollectionLiteralExp
inv: kind = CollectionKind::Set implies type.oclIsKindOf (SetType )
inv: kind = CollectionKind::Sequence implies type.oclIsKindOf (SequenceType)
inv: kind = CollectionKind::Bag implies type.oclIsKindOf (BagType )
inv: type.oclAsType (CollectionType).elementType = parts->iterate (p; c
:
Classifier = OclVoid | c.commonSuperType (p.type))
==> should be
context CollectionLiteralExp
inv: kind = CollectionKind::Set implies type =
StandardLibrary::StdLib::Set
inv: kind = CollectionKind::OrderedSet implies type =
StandardLibrary::StdLib::OrderedSet
inv: kind = CollectionKind::Sequence implies type =
StandardLibrary::StdLib::Sequence
inv: kind = CollectionKind::Bag implies type =
StandardLibrary::StdLib::Bag
inv: type.oclAsType
(OclAbstractSyntax::Types::CollectionType).elementType =
parts->iterate (p; c :
Classifier = StandardLibrary::StdLib::OclVoid | c.commonSuperType
(p.type))

No Data Available

inv: type = referredAttribute.type
==> ’AttrubuteCallExp’ should be ’AttributeCallExp’

No Data Available

post: result.features = atts
post: result.stereotype.name = ’OclHelper’
==> ’sequence’ should be ’OrderedSet’

No Data Available

5. In section 3.3.9 the operations "OclExpression::withAtPre() : OperationCallExp" and "OclExpression::
withAsSet() : OperationCallExp" should be prefixed with the keyword ’context’.

No Data Available

context Operation
def: hasMatchingSignature(paramTypes: Sequence(Classifier)) : Boolean =
– check that operation op has a signature that matches the given
parameter lists
= let sigParamTypes: Sequence(Classifier) = self.allAttributes.type in
(
( sigParamTypes->size() = paramTypes->size() ) and
( Set

->forAll ( i |
paramTypes->at .conformsTo (sigParamTypes->at )
)
)
)
==> remove the ’=’ after Boolean
==> same error occurs in "context Signal def: hasMatchingSignature...."

No Data Available

context OclMessageExp
inv: sentSignal->notEmpty() implies
arguments->forall (a | a.getType().conformsTo
(self.sentSignal.signal.feature.oclAsType(StructuralFeature) )
>at (arguments>indexOf (a)).type))
==> should be:
context OclMessageExp
inv: sentSignal->notEmpty() implies
arguments->forAll (a | a.getType().conformsTo
(self.sentSignal.signal.feature
>at (arguments>indexOf
(a)).oclAsType(UML14::Core::StructuralFeature).type) )

No Data Available

context IterateExp
Body.type.conformsTo(result.type)
==> missing ’inv:’

This typo has already been corrected in the last OCL 2.0 release.

Disposition: Close, no change

context Primitive
inv: (self.name = ’Integer’) implies
Primitive.allInstances()->forAll (p | (p.name = ’Real’) implies
(self.conformsTo(p))))
==> one closing bracket ’)’ too many

No Data Available

The classifier name TupleType is also a reserved word. In order to check the constraints we have
changed it into TTupleType.

No Data Available

1. The keywords ’pre’, ’body’, ’in’ and ’context’ are being used in the OCL expressions themselves to
indicate role names. Actually this is an error. These can be avoided by changing the following
rolenames:
• - ’body’ of AbstractSyntax::Expression::LoopExp
• - ’pre’ of OclDomain::Values::LocalSnapshot
• - ’context’ of OclDomain::Evaluations::OclExpEval
• - ’in’ of AbstractSyntax::Expression::LetExp
• - ’in’of UML14::Core::ParameterDirectionKind
To check the expressions we have changed the above names into the same word beginning with an
upperclass character.

No Data Available

11. The OclMessageArg metaclass that is currently defined, could be removed. We propose the configuration
depicted in figure 1, together with the following constraints. Note that a similar set of constraint
must be added to chapter "The Use of Ocl Expressions in UML Models", depending on the
exact alignment with the UML metamodel. Also note that both the first and second constraint of
OclMessageExp on page 54 of the final adopted spec need to be changed: "arguments->forAll( a |
a.getType() ...." should be "arguments->forAll( a | a.type ....".
– an unspecified value expression may not have an applied property
context UnspecifiedValueExp
10 June 2004,
page 2 of 22
Klasse Objecten
© Copyright Klasse Objecten
inv: self.appliedProperty->isEmpty()
– an unspecified value expression may not be used anywhere but as
– argument to an OclMessageExp
context OclExpression
inv: not appliedProperty.oclIsTypeOf(UnspecifiedValueExp)
context LoopExp
inv: not body.oclIsTypeOf(UnspecifiedValueExp)
context VariableDeclaration
inv: not initExpression.oclIsTypeOf(UnspecifiedValueExp)
context LoopExp
inv: iterators->forAll(i | not i.oclIsTypeOf(UnspecifiedValueExp))
context IterateExp
inv: not result.oclIsTypeOf(UnspecifiedValueExp)
context OperationCallExp
inv: arguments->forAll( i | not i.oclIsTypeOf(UnspecifiedValueExp))
context NavigationCallExp
inv: qualifiers->forAll( i | not i.oclIsTypeOf(UnspecifiedValueExp))
context IfExp
inv: not thenExpression.oclIsTypeOf(UnspecifiedValueExp)
context IfExp
inv: not elseExpression.oclIsTypeOf(UnspecifiedValueExp)
context IfExp
inv: not condition.oclIsTypeOf(UnspecifiedValueExp)
context LetExp
inv: not in.oclIsTypeOf(UnspecifiedValueExp)

No Data Available

It would be convenient to have a tostring operation for Integer, Real and Boolean.

No Data Available

9. It would be very convenient to allow the plus (infix) operator (’+’) as concrete syntax for the String
concat.

No Data Available

It is not clear from the specification whether the flatten operation is meant to be a deep or a shallow
flatten. We prefer a deep flatten, but perhaps both options should be available.

No Data Available

The result of applying the collect operation to a Sequence should be a Sequence, not a Bag. Likewise,
the result of applying the collect operation to an OrderedSet should be a Sequence, not a Bag.

No Data Available

Remove the composition symbol at the end of PropertyCallExp in the association between Property-
CallExp (rolename appliedProperty) and OclExpression (rolename source). This should be a normal
association.
Composition implies lifetime dependency, therefore this use of composition is incorrect. An OclExpression
exists independent of its (optional) applied property and they have no lifetime dependency.

No Data Available

There should be an OclTypeLiteralExp metaclass, subtype of LiteralExp. It should have an association
with UML::Classifier.

No Data Available

There should be an OclStateLiteralExp metaclass, subtype of LiteralExp. It should have an association
with UML::State.

No Data Available

There should be an OclUndefinedLiteralExp metaclass, subtype of PrimitiveLiteralExp. The type of
its instances should always be OclVoid.

No Data Available

In section 7.4.6 (Re-typing or casting) on p.13, it is stated that "An object can only be re-typed to one of its subtypes". In other words, in the expression object.oclAsType(A), A must be a subtype of the type of the object. However, in section 7.5.8 (Accessing overridden properties of supertypes) on p.20 an example is given of object.oclAsType(A), where A is a supertype of object. This contradicts the assertion made earlier. In section 11.2.4 there are no constraints given on oclAsType that would rule out the usage shown in the second paragraph. However, in the semantics section on p.A-25 it is only stated that for oclAsType, the the target type must be a subtype of the source type or vice versa, supporting again the usage in the second paragraph. Judging from these, I assume that the restriction given on p.13 is incorrect.

Type-casting is more general than the set of known subtypes and supertypes. If the OCL type system can be considered as open (meaning that OCL expressions may be applied to objects of types not known in the context in which it was defined), then it must be permitted to attempt a cast to any other type. UML implements multiple inheritance, so that given any two types, it is always a possibility that an object could be classified by both, even if they do not apparently have any relationship. This is particularly important for constraints defined in type libraries.

Because OCL provides type tests oclIsKindOf() and oclIsTypeOf(), it is reasonable that failure to cast result in invalid to indicate an error condition. Note that a type-testing expression such as self.oclAsType(SomeType).oclIsInvalid() is correct, though it may be considered as poor style.

The effect of casting is only a parse-time re-typing to provide visibility of features not defined for the original type, and a run-time assertion of the required type of an object. It cannot change the type of an object or coerce an object to an instance of a different type, nor can it provide access to hidden or overidden features of a supertype. For this, a new syntax is required that statically indicates the definition of a feature by the classifier that defines it.

Use the "null" keyword instead of verbose "OclUndefined".

No Data Available

OCL 2 does not clarify what makes a type a collection. It's clear that
any multiple attributes and associations are collections. And from
section 3.2, it's clear that parameterised classes may be treated as
OCL collections. However not all parameterised classes can be treated
as collections

This needs further clarification

No Data Available

Keywords "attr" and "oper" still necessary? Keywords attr and oper are defined in the keywords list, but are not included in the concrete grammar. Are they maybe superfluous? If "attr" is really a keyword, then the well-formedness rule on page 140 that uses a local variable attr must use another variable name.

No Data Available

Maybe the completion of the formal semantics of OCL is an issue that is too extensive as part of the finalization process of OCL 2.0. Therefore, I suggest to just add a note in Appendix A concerning the currently still missing parts of the formal semantics, i.e., in particular OCL Messages, Ordered Set, and def-clauses. If you want you can refer to my paper about the Formal Semantics of OCL Messages, presented at the OCL Workshop at UML 2003. It can currently be found at http://i11www.ira.uka.de/~baar/oclworkshopUml03/papers/05_formal_semantics_ocl_messages.pdf

No Data Available

Perhaps it makes sense to explicitly mention whether OclUndefined = OclUndefined results in OclUndefined (or true)? The SQL equivalent seems to cause a lot of confusion, especially since in C "NULL == NULL" resturns true. For example, the above expression would not work with excluding(OclUndefined), given (OclUndefined=OclUndefined).isOclUndefined().....

Technically, no change is necessary because the OclAny definition of the = operation, together with the definition of the singleton values null and invalid, is sufficient. However, being more explicit is helpful, especially as the there is no oclIsXyz() operation testing for void but not invalid.

• I think the enumeration approach to reflection leads to a dead end. Why not leave that out for now and add full access to the user model in OCL2.1, when the other UML parts have stabilized. I think it would be quite straightforward to simply copy the relevant properties and operations from Classifier/Class to OclType.

No Data Available

Description: The object OclModelElement object should be removed from the standard library, while OclModelElementType should remain in OCL type hierarchy.
Rationale: It implies a useless level of wrapping for the model objects.

No Data Available

Description: OclType should disappear from the OCL type hierarchy.
Rationale: OclType should be only present in the standard library to support values for the type expression used in functions like oclAsType(), oclIsKindOf(), and oclIsTypeOf().

No Data Available

Description: OCL offers two choices to test if a value is undefined or not: isEmpty and oclIsUndefined.
Rationale: Most of the modern programming languages contain null values. The best OCL mapping for null value is the undefined value. Using isEmpty to test if a value is null/undefined is some how confusing:

• the result of property->isEmpty() must be true if the value of the property is null/undefined
• the result of Set {1/0}

  ->isEmpty() must be false
  because the expression property->isEmpty() is converted according to the OCL specification to Set

  {property}

  ->empty()
  These situations are a source of errors and confusion at the implementation level. I think that isEmpty() should be used only to test if a collection is empty or not; the null/undefined values should be tested using ocIslUndefined. This operation should be also valid on collections. This approach will also work nice and clear for nested collections. On the other hand I don't think that () should not be optional if the called operation has no arguments. This is feature specific to old languages like TAL and Pascal, while in modern languages like C, C++ the meaning of f and f() is different.

No Data Available

Description: The submission uses the terms of Attributes and Association Ends, which are no longer used in UML 2.0.
Rationale: In order to align OCL 2.0 and UML 2.0 specifications I think that the expression package should look like: I also think that the OCL grammar should be rewritten accordingly

No Data Available

Description: Section 4.3.2 does not specify precedence for operators like div, mod, ^^, or ^.
Rationale: The operator precedence must be as precise as possible in order to provide a platform-independent implementation. I think that logical operators should be organized on different levels of precedence:
'not'
'and'
'or'
'xor'
'implies'

See issue 6544 for disposition

Description: OCL 2.0 uses keywords (e.g. and, or, xor, implies etc.) that cannot be used elsewhere.
Rationale: This means that these names cannot be used to identify properties, classes or packages. There are two options to solve this problem: either UML 2.0 specifies the names that cannot be used or the OCL concept of keywords has to be revised.

No Data Available

Description: The OCL 2.0 specification should describe the set of characters allowed in the OCL constructions (e.g. Unicode or ASCII).
Rationale: This will help implementers to solve another ambiguity and to produce portable implementations. Unicode will be in my opinion the best choice.

No Data Available

Description: The specification should contain an introductory section containing definitions of the terms used in the specification and other notations that are used (e.g. well-formed expression, ill-formed expression, behaviour, undefined-behaviour etc.).
Rationale: This will avoid ambiguities and provide a better specification of the OCL (see specifications for C++, Java, and C#).

No Data Available

Author: Herman Balsters (h.balsters@bdk.rug.nl)
Description: Reintroduce allAttributes operator
Rationale:
In pre-OCL 2.0 versions, there was an operator called "allAttributes": this operator (to be applied to class objects) returns the set of attributes of that object. (This operator should also be applicable to tuples as well, by the way.) Now the strange thing has happened that this most useful operator has vanished in OCL 2.0 I propose that it be re-introduced.

No Data Available

Author: Hubert Baumeister (baumeist@informatik.uni-muenchen.de),
Rolf Hennicker (hennicke@informatik.uni-muenchen.de),
Alexander Knapp (knapp@informatik.uni-muenchen.de)
Description: Missing equality and inequality operations on collection types
Rationale:
The collection types Set, Sequence, and Bag show a predefined = operation. However, this operation is not defined for the abstract type Collection.
Moreover, the operation <> is missing for all collection types.

No Data Available

Author: Hubert Baumeister (baumeist@informatik.uni-muenchen.de),
Rolf Hennicker (hennicke@informatik.uni-muenchen.de),
Alexander Knapp (knapp@informatik.uni-muenchen.de)
Description: Clarify definition of collectNested for Set, Bag, and Sequence
Rationale:
For Set, Bag, and Sequence the definition of collectNested (page 6-17ff.) actually defines collect which should read collectNested.
As a minor detail, the definition of collectNested seems to be the only one using iterators as iterator variable. This should be aligned with select, reject, etc.

No Data Available

Author: Octavian Patrascoiu (O.Patrascoiu@kent.ac.uk)
Description: Most of the modern OO languages support null values, but OCL does not. In order to map null values into OCL concepts we used the undefined value. Unfortunately, OCL offers two choices to test if a value is undefined or not: isEmpty and oclIsUndefined. Using isEmpty for such a purpose is some how confusing:
the result of property->isEmpty() must be true if the value of the property null/undefined
the result of Set

->isEmpty() must be false
These situations are a source of errors and confusion at the implementation level. I think that isEmpty() should be used only to test if a collection is empty or not; the undefined values should be tested using ocIslUndefined. This operation should be also valid on collections. This approach will also work nice and clear for nested collections.

The submitter’s assertion about appropriate usage of oclIsUndefined() and isEmpty() is a matter of style. OCL does support null values, even in collections, so that a collection containing a single element that is null is not empty. The isEmpty() operation applied to scalar values that are null is an inevitable consequence of the coercion of scalars to sets. It is reasonable that a scalar null is coerced to an empty set while a non-null scalar is coerced to a non-empty set. Moreover, oclIsUndefined() is true not only for null, but also for invalid, which is not permitted in collections.

Disposition: Closed, no change

Author: Jörn Guy Süß (jgsuess@cs.tu-berlin.de)
Description: Interpreter to warn of recursive definitions
Rationale:
While recursive definitions are necessary to express certain constructs, they may lack a fixpoint. Specification should require implementations to provide either an occurs check or structured time-out/stack-trace to handle these situations.

No Data Available

Author: Octavian Patrascoiu (O.Patrascoiu@kent.ac.uk)
Description: The submission uses the terms of Attributes and Association Ends, which are no longer used in UML 2.0. In order to align OCL 2.0 and UML 2.0 specifications I think that the expression package should look like:

I also think that the OCL grammar should be rewritten accordingly.

No Data Available

Author: Octavian Patrascoiu (O.Patrascoiu@kent.ac.uk)
Description: Logical operators 'and', 'or', and 'xor' have the same precedence, which in my opinion is not natural. I think that the precedence of these operators should be from highest to lowest as follows:

'and'
'or'
'xor'

Also, the precedence of some useful operators like 'div', 'mod', '^{', and '}^', is not specified in section 4.3.2.

No Data Available

Description: OclType is currently a subtype of OclAny and seen as an enumeration type. This leads to some drawbacks w.r.t. the specification of operations like oclAsType(), oclIsKindOf(), and oclIsTypeOf(), that need to reason about type conformance. As this cannot be done without accessing the metalevel, OclType should rather be considered as a powertype (cf. OCL Workshop paper at UML 2003: S.Flake, OclType - A Type or Metatype?).

No Data Available

Author: Jörn Guy Süß (jgsuess@cs.tu-berlin.de)
Description: Interpreter to warn of nondeterministic cast
Rationale:
If an OCL expression contains a cast from Set to Sequence types, nondeterminism is introduced through the order of the new sequence. Either such casts should be disallowed, or the specification should require that implementations give feedback that nondeterministic behavior is to be expected

No Data Available

Author: Thomas Baar (thomas.baar@epfl.ch)
Description: clarify, whether x/0 is undefined
Rationale: On page 6/6, 6-7 the semantics of operation / is decribed informally as 'The value of self divided by r (respective i).' It remains unclear what self / 0 evaluates to.
On page 6/7 the div-operation is specified in terms of /-operation, however with a pre-condition pre: i <> 0.
Why is div handled differently from / ?

No Data Available

Description: OclModelElement is currently defined in the OCL Standard Library. It can simply be omitted, as it is actually never used. OclModelElementType, however, must remain in the metamodel, e.g., for the mapping of OclState.

No Data Available

Description: Provide an operation for creating a collection of new objects
Rationale:
Consider the case where you want to create a new smartcard for a set of persons. Any solution is currently longwinded. It would be nice to be able to have an operation oclIsNew that applies to a collection (or perhaps only to a Set), and states the number of objects to be created, e.g.:
let: s: Set(SmartCards) in s.oclIsNew(self.person->size())...

closed no change

The OCL 2.0 FAS makes several references to ASCII (pg. 22), lowercase and uppercase characters (pg. 33-34) that violate the requirement for allowing international character sets to be used with UML. This is unacceptable since it limits the use of UML.

No Data Available

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’

yes

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’

yes

The example of Set

is more of an example of an ordered set as is Set

. The example of a Sequence

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

, Set ['strawberry','apple','orange'} and Sequence

Yes. But reverse the sequence to clarify that the ordering may not be the obvious one. Also correct the punctuation.

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.

yes

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’

’isOclType’ was fixed in OCL 2.3.
Disposition: Closed, no change

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)

’asOclType’ was fixed in OCL 2.3.
Disposition: Closed, no change

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

yes

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)

’isOclType’ and ’asOclType’ were fixed in OCL 2.3.
Yes. value rather than name

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.

The italics are fixed in OCL 2.3.
Subtyping is resolved by Issue 15780.
Disposition: See issue 15780 for disposition

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.

The paragraph containing the typo was removed in OCL 2.3.
In the context of Section 7, Operation is a property so there is a combination in the example..
Disposition: Closed, no change

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?

UML 2.5 introduces Real. UnlimiteralNatural has been in UML for a long time.
Disposition: Closed, no change

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’

’isOclType’ and ’asOclType’ were fixed in OCL 2.3.
Disposition: Closed, no change

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.

The exposition of the OCL grammar is poor. In OCL 2.3 the status of iterator names was clarified as not-reserved words which makes the naive parsing approach outlined above more challenging. Instead it is necessary to pursue a syntactic parse and then resolve semantics in a tree walk. The 'problems' have not prevented OCL tool being built.
Users would not be well-served by a major resyntaxing to introduce new punctuation.
Disposition: Closed, no change

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.

The exposition of the OCL grammar is poor, but it is possible to resolve context pursuing a left to right analysis of an expression. It is also possible to perform a syntactic parse and then resolve semantics in a tree walk.The 'problems' have not prevented OCL tool being built.
Users would not be well-served by a major resyntaxing to introduce new operators that required the user to have greater understanding of the metamodels.
Disposition: Closed, no change

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

The suggested syntax comes from QVTo.
Non-trivial OCL expressions can be difficult to read. Introducing shorthand notations compromises readability. At present OCL has "." and "->" shorthands that cause significant difficulties. Introducing more does not seem appropriate for the standard language.
It is not clear that introduction of another [..] syntax can avoid conflicts with the already challenging conflicts for association qualifiers and array indexes.
Disposition: Closed, no change

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

The suggested syntax comes from QVTo.
Non-trivial OCL expressions can be difficult to read. Introducing shorthand notations compromises readability. At present OCL has "." and "->" shorthands that cause significant difficulties. Introducing more does not seem appropriate for the standard language.
oclIsKindOf and oclIsTypeOf are already a source of confusion; oclIsTypeOf should rarely be used but is the more obvious name to new users, so providing a shorthand for oclIsTypeOf is unnecessary.
The # syntax has no terminator so the shorthand needs an ambiguity resolution for a.#B.c()
The suggested usage seems to conflict with the intuition of those familiar with unary prefixes of assembler languages or even OCL 1.x enumeration literals.
If an improvement is to be made, something like
(a as B).c()
would contribute to rather than hamper readibility.
Disposition: Closed, no change

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.