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.

This issue was forked off from UML 1.x 15 years ago. It doesn't seem to have anything to do with OCL at all. But rather than throw the issue back to UML, let's address it anyway.
One could imagine a UML extension that introduced a Frame class and an Operation.ownedFrameCondition to host it. OCL expressions could then impose the semantics.
However a Frame would be specific to a particular implementation approach, and so it would seem more appropriate to use stereotypes to model the implementation characteristics. Perhaps one of the standard UML profiles already provides this capability.
Disposition: Closed, no change

Typo. contaxt, change to context

Initial Comment: contaxt->context
Comment: Close as Fixed by OCL 2.3
Disposition: Closed

In A.2.1.2 Operations on p193, toLowerCase is referred to as toLower "case translations are possible with toUpper and toLower" and again in Table A.1

Also toUpperCase is referred to as toUpper in the same places

No Data Available

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

No Data Available

OCL needs an abstract syntax, just like the UML metamodel. This
will clarify many issues about the exact semantics of OCL.
This request has been made by multiple sources.

No Data Available

In the String explanation,
There is a descrition that
"The OCL type String represents ASCII strings."
I think this cannot apply to multi-byte code.

Could you change this sentence to
"The OCL type String represents strings consisting
of ASCII characters and/or multi-byte characters.

No Data Available

1. 6.2.1 "legend" on page 6-3,
There is a following description.
"OCL expression are written using ASCII characters only"
This sentence can be interpreted in this context as
a) OCL expressions are written using only
ASCII characters as examples in this document,
b) the OCL expression must be written by only
ASCII characters in general usage?

Could you change this to
"OCL expressions in this document are
written using ASCII character only."

No Data Available

4.Regarding inhibtedChar on page6-48,
its definition is following.

inhibitedChar :=
"|"\"|"#"|"\'"|"("|")"|"*"|"+"|","|
"|"."|"/"|":"|";"|"<"|"="|">"|"@"|
["|"\\"|"]"|"

"

But, this definition is slightly different from one which we
have provided previously.
(Top two characters of each line are dropped)

inhibitedChar := " " | "\"" | "#" | "\'" | "(" | ")" |
"*" | "+" | "," | "-" | "." | "/" |
":" | ";" | "<" | "=" | ">" | "@" |
"[" | "\\" | "]" | "

"

No Data Available

Relating this, in the EBNF of the String on page6-48.
There is a "~" symbol after double brackets.
Does this means negation?
If it is negation, there is no modification of String
definition on the EBNF even though the body of string
explanation is changed.
But, I cannot find a "~" definition in the EBNF.
In the unaryOperater definition of the EBNF on page6-48
There is a "-".
I think this is a "~" symbol.

No Data Available

It is sometimes useful to downcast an OCL collection, for example
when a generic function returns an OCL Collection, but a particular
usage requires a Sequence. Unfortunately, the OCL operators
asSet(), asSequence() and asBag(), are defined only for the
concrete types, and not for their abstract common supertype
Collection.

No Data Available

> In 6.9 "Grammar for OCL",
> According to the current BNF grammar, we cannot use
> multi-byte characters in class nor attribute names, because
> name and string are composed of alpha-numeric letters only.
> I think the definition of OCL should be modified for us
> to be able to use multi-byte characters.
> I show a draft of modification which will be proposed by
> ISO/Japan National Body.(This will be discussed in UML1.3 PAS
> at the next OMG/ISO Orlando meeting)
>
> typeName :=charForNameTop charForName*
> name :=charForNameTop charForName*
> charForNameTop := /* Characters except inhibitedChar
> and ["0"-"9"]; the available
> characters shall be determined by
> the tool implementers ultimately.*/
> charForName := /* Characters except inhibitedChar; the
> available characters shall be determined
> by the tool implementers ultimately.*/
> inhibitedChar := " "|"\"|"#"|"\'"|"("|")"|"*"|"+"|","|"-"|
> "."|"/"|":"|";"|"<"|"="|">"|"@"|"["|"
"|
> "]"|"

"

No Data Available

Usually, the behaviour of an operation is described by pre and
postconditions, and then shown in a collaboration diagram. In turn, in a
collaboration diagram one can model (via the standard stereotypes create and
destroy) the creation and destroying of instances, but this is not in the
case in OCL. It would be useful to be able to explicitly model in a
postcondition that an instance ocurring in the expression was created during
the execution of the operation being specified. Since introducing a command
is not possible, this feature could be achieved by just 'declaring' in the
postcondition that the instance 'was created'.

For example:

context X::operation()
post: self.attr = self.attr@pre->including(created p)

this declares that p was created during the execution of operation, and it
was not taken from elsewhere.

No Data Available

The second form of the context declaration for OCL invariants should be extended from

context c : Class inv:

to

context c1,..,cn : Class inv:

In similar situations, like the forAll and Exists operators, multiple iterators are allowed. So the above suggestion would increase uniformity. It also leads in some cases to simplified OCL expressions, e.g.

context C inv C.allInstances->forAll(c1,c2 | c1.id = c2.id implies c1=c2)

could be written as

context c1,c2 : C inv c1.id = c2.id implies c1=c2

Crossreference to issue #3139.

No Data Available

The postcondition for the operation round on the predefined OCL type real reads

((r - result) < r).abs < 0.5) or ((r - result).abs = 0.5 and (result > r))

This is incorrect and should be replaced by

((r - result).abs < 0.5) or ((r - result).abs = 0.5 and (result > r))

No Data Available

In Section 8.2.2, in Classifier well-formedness rules, 'collectionTypes' is used instead
of 'collectionType'. This is not correct since in OCL, by convention, when not provided explicitly
the name of an opposite role takes the name of the target class with first letter lowerized.

No Data Available

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’