In section 11.5 "Operations and Well-formedness Rules" for the five standard PrimitiveTypes Boolean, Integer, Real, String, and UnlimitedNatural, we have specifications for logical comparison operators <, >, <=, >= but no specification for the equality operator.

It seems to me that if these operators must be explicitly implemented by tools, they must also implement a method for equality which should be specified. In C++, this is of course necessary. The operation String::equalsIgnoreCase(), for example, depends on it directly:

"Queries whether s and self are equivalent under case-insensitive collation.
post: result = (self.toUpperCase() = s.toUpperCase())"

Issue 12948 "Making OclAny denote any object" was resolved to allow Collection to conform to OclAny.

A.2.6 still states "A simple set inclusion semantics for subtype relationships as described in the next sub section would not be possible due to cyclic domain definitions if OclAny
were the supertype of Set(OclAny)."

A premise for Annex A has therefore been violated requiring rework to consider at least a less simple set inclusion semantics.

According to section 9.3.49, there are two forms of comments, line comments (-- this is a comment) and paragraph comments (/* this is a comment */):

It is possible to include comments anywhere in a text composed according to the above concrete syntax. There will be no
mapping of any comments to the abstract syntax. Comments are simply skipped when the text is being parsed. There are
two forms of comments, a line comment, and a paragraph comment. The line comment starts with the string ‘--’ and ends
with the next newline. The paragraph comment starts with the string ‘/’ and ends with the string ‘/.’ Paragraph
comments may be nested.

In section 7.4.12, only the syntax for line comments is described:

Comments in OCL are written following two successive dashes (minus signs). Everything immediately following the two
dashes up to and including the end of line is part of the comment.

For example:
– this is a comment

The two possibilities should be mentioned in 7.4.12.

Fig 10.2 presents some classes that to the best of my knowledge have never been used in an OCL implementation. The LocalSnapshot is a possible way of reconciling the need for two distinct system states when evaluating @pre or oclIsNew. It is however perhaps no more than some draft thoughts. Some much more promising work has evolved as 'Filmstrip's in conjunction with the USE tool. A Filmstrip supports OCL expressions that apply across time.

The LocalSnapshot and associated support are absolutely not a normative part of an OCL implementation.

OCL25-80 comment 1 identifies that the xxxValue classes are misleading and could be trivially rephrased as "xxx value semantics".

Similarly the xxxEval classes are unhelpful and could be triially rephrased as "xxx evaluation semantics".

Simple or efficient implementations of OCL have no need to reify each evaluation as an instance, the execution can just return the appropriate result. Only an implementation with rigorous tracing for debugging or incremental execution need reify the execution and the implementation should be free to choose its own implementation details.

There is absolutely no need for a normative existence of xxxEval classes. Only the semantics is normative.

Figure 10.5 StringValue only appears here. No explanation was given before the diagram. Add definition or explanation of StringValue before this diagram

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

7.4.6 states: If the actual type of the object, at evaluation time, is not
a subtype of the type to which it is re-typed, then the result of oclAsType is invalid.

7.5.8 states: self.oclAsType(A).p1 – accesses the p1 property defined in A - this is incompatible with the no-class-change-to-A so A::p1 is not available for null.

But the normative 11.3.2 states: oclAsType(type : Classifier) : T
Evaluates to self.

The OCL 2.4 contribution to 11.3.2 was a typo. It should be "evaluates to invalid".

Section 8.3.8 neglects to specify what it means for allInstances to be invoked for a Classifier that does not have a finite number of instances.

The Real/Integer/UnlimitedNatural/String PrimitiveTypes, CollectionType, TupleType, DataType, ,,, overloads could reasonably return invalid or an empty Set. Just need the specification to say which by specifying each of the overloads in Section 8 / 11.

Overloading Classifier::allInstances() with a crash (invalid) seems unkind, so suggest the empty set to avoid users needing to exclude many metatypes in a many-classifiers loop..

The flawed resolution of issue 8937 introduced Section 7.5.10 in which it is suggested that :: is an operator that can be contrasted with the . object navigation operator.

It isn't. It is a name qualification operator allowing e.g. A::B::C::d to clearly locate a feature with respect to any prolematic name clashes.

If :: is an invocable operator, which of the :: in A::B::C::d are to be executed, and how?

As a qualification operator the referredOperation/referredProperty field in an OperationCallExp/PropertyCallExp is assigned at compile-time to the unambiguous resolution of the qualified reference. No extra execution for the qualification.

The flawed resolution of issue 8937 introduced Section 7.5.10 and the Employee::id() example that invokes the static Employee::uniqueID() to initialize each Employee instance with a presumably distinct unique id.

This can only work if uniqueID() returns a distinct value from each call. It is therefore not a query and not side-effect-free. It cannot be invoked from OCL.

Unless the execution semantics introduces some new magic static-time between load-time and run-time in which a side-effecting static semantics is defined and supported, this is impossible. No idea how this could be made deterministic on a multi-processor execution engine.

Rather we need to be declarative and do everything at once, rather than one at a time imperatively.

context Employee
static def: allEmployees : Sequence(Employee)
= Employee.allInstances()->asSequence()
def: id : String
= 'ID' + allEmployees->indexOf(self).toString()

The quadratic cost of indexOf can be avoided if we have maps and co-iterators:

context Employee
static def: employee2index : Map(Employee,Integer)
= Employee.allInstances()->collectByValue(key with value | key)
def: id : String
= 'ID' + employee2index->at(self).toString()

An optimized execution engine could recognize the idiom and optimize away the single use static Map.

toString() is a familiar debug facility that OCL currently provides ony for logical / numeric usage. This is unfriendly.

Better to provide toString() for all values including null and invalid, with a carefully designed formatting to ensure that a monotonic forward/reverse round trip is possible.

(OCL25-75 vaguely suggests toString()).

The Isabelle evolution for Annex A highlight two errors in the OCL 2.4 clarifications.

OclVoid::oclIsKindOf/oclIsTypeOf should return true/false rather than invalid.

? oclIsKindof true for all types except OclIsInvalid.

There seems to be some confusion in ptc-13-08-13 regarding the relation of OclAny to other OCL types. Sections 8.2 and 11
state that it is a supertype of all other OCL types, including collection and tuple types, but Annex A excludes collection/tuple types from inclusion in OclAny.

The new OCL for UML 2.5.1 seems not to have been checked by any tool; shame on you. There are two syntax errors:

OpaqueExpression-only_in_or_return_parameters-specification makes use of ParameterDirectionKind::in but 'in' is a reserved word and so it must be escaped as in other similar constraints. Change to ParameterDirectionKind::'in'

Lifeline-interaction_uses_share_lifeline-_specification has a Bag rather than Boolean argument for the final implies. Perhaps the select(...) should be followed by a ->notEmpty() or the select(...) could be an exists(...)

in UML the rules for distinguishable names are:

• Have different Names
• Same Names but different Types
  metaclasses are different
  Neither is a (direct or indirect) generalization/specialization of the other
  (e.g. Operations distinguished by signature)

so we can have a class Person and a DataType Person... each could have an association to it... so the association end implicit name is the same... and would need to be differentiated by its Type... this is not currently supported in OCL

A Collection containing both 'a', and

must be typed as a
Collection of OclAny since that is the only common type.

This is unhelpful for tree structures.

Suggest introduction of a pseudo-collection type Tree(T) to which
both T and Collection(Tree(T)) conform.

A String content tree then then be declared as a Tree(String).

12: Why no applicability to Essential MOF models?

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

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

Sections 12.5.1, 12.6.1, 12.7.1 specify the "invariant", "precondition", "postcondition" spellings.

Sections 12.8, 12.9, 12.10, 12.11 do not specify their corresponding spellings.

Suggest: "initial", "derivation", "body", "guard" as the conventional adjective used to qualify "constraint".

Languages such as Groovy have found it helpful to intrioduce the safe navigation operator ?: so that navigation over null yields null rather than a problem (invalid in OCL).

In OCL it could be a pure syntax sugar:

(x?.y) = (if x == null then null else x.y endif)

or perhaps an additional PropertyCallExp operator

Issue 12953 made changes to the CollectionLiteralExpCS grammar and these appear in OCL 2.3 but not in OCL 2.4.

It would appear that some major editorial snafu occurred while reconstructing a FrameMaker base for OCL 2.4 after the OCL 2.3.1 corruptions.

Application of OCL 2.2, 2.3, 2,3.1, 2.4 changes need to be checked to understand the snafu.

Typo in sentence "If the constraint is shown in a diagram, with the proper stereotype and the dashed lines to connect it to its contextual
element, there is no need for an explicit context declaration in the test of the constraint."

test should be text

The sortedBy iteration provides an elegant solution to a sort problem in which the sort metric is a projection of the sorted object. Thus sortedBy(p|p.name) or just sortedBy(name) is short and avoids the opportunities for typos from a more conventional exposition involving comparison of two objects. The natural solution may well be an efficient one for large collections with non-trivial metrics.

However the sortedBy solution is unfamiliar and so confusing for newcomers and unsuitable for multi-key sorting for which an artificial compound single key may need to be constructed.

One solution might be to provide a more conventional iterator such as sort(p1, p2 | comparison-expression) allowing a two key sort:

sort(p1, p2 | let diff1 = p1.key1.compareTo(p2.key1) in
if diff1 <> 0 the diff 1 else p1.key2.compareTo(p2.key2) endif)

However this has poor readability and ample opportunities for typos.

Alternatively sortedBy with a Tuple-valued metric might support multiple keys as:

sortedBy(Tuple

)

(The alphabetical order of the Tuple part names determines the priority.)

(Since sortedBy is declaratively clear and compact, inefficient small/trivial implementations can be optimized to their sort() equivalents.)

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.

The following problems are common to all definitions of sortedBy in 11.9:

Invalid algorithm:

• When the current element is not the first one, but is the
  greatest one so far, for example 2 in
  Sequence {1,2}

  ->sortedBy(x|x),
  then
  result->select (item | body (item) > body (iterator))
  is empty and calling ->first on it would result in invalid.

Inconsistent use of < and >:

• The text descriptions mention using < operation on the elements,
  but the algorithm uses > operator.

Typos:

• The accumulator initialization incorrectly uses : instead of =.
• The source for the iterate expression is missing.
• The closing parenthesis for the iterate expression is missing.
• The operations append and insertAt are called by . operator.

SOLUTION:

• Introduce a new local variable upperBounds, containing elements from the
  accumulator that are greater than the current element.
• Swap body (iterator) and body (item).
• Fix typos.

Corrected algorithm for Set (11.9.2) and OrderedSet (11.9.5):

****************************************
source->sortedBy(iterator | body) =
source->iterate( iterator ; result : OrderedSet(T) = OrderedSet {} |
let upperBounds : OrderedSet(T) =
result->select (item | body (iterator) < body (item) )
in
if upperBounds->isEmpty() then
result->append(iterator)
else
let position : Integer = result->indexOf ( upperBounds->first() )
in
result->insertAt(position, iterator)
endif
)
****************************************

Corrected algorithm for Sequence (11.9.4) and Bag (11.9.3):

****************************************
source->sortedBy(iterator | body) =
source->iterate( iterator ; result : Sequence(T) = Sequence {} |
let upperBounds : Sequence(T) =
result->select (item | body (iterator) < body (item) )
in
if upperBounds->isEmpty() then
result->append(iterator)
else
let position : Integer = result->indexOf ( upperBounds->first() )
in
result->insertAt(position, iterator)
endif
)
****************************************

FURTHER SUGGESTIONS:

• The presented algorithm works only under assumption that indexOf(obj:T)
  on Sequence(T) returns the first occurence. This is not mentioned in the
  definition of indexOf. If indexOf can return any index, for example:
  Sequence {2, 2}

  ->indexOf(2) = 2,
  then the above algorithm could insert the element at the wrong place,
  for example:
  Sequence

  {2, 2, 1}

  ->sortedBy(x|x) = Sequence

  {2, 1, 2}
• The algorithm is stable for Sequence and OrderedSet, this fact could be
  mentioned in the description, to make it clear that successive
  sortedBy iterations can be used to sort by multiple criteria.

OCL supports a '*' value for UnlimitedNatural in order to accommodate the
full range of UML multiplicities.

UnlimitedNatural conforms to Integer and Real, so that any UnlimitedNatural
conversion must perform a run-time check in order to convert '*' to invalid.
This conversion cannot be replicated in the reverse direction.

Suggest that '*' be aligned with the conventional IEEE math notion of
infinity, so that

• and -* are valid values for Integer and Real. UnlimitedNatural is then a
  simple restriction of Integer which is a simple restriction of Real.

Consider: my general purpose library provides:

mylib::Aggregate<T>

My subsystems exploit this by drawing:

mysub1::Aggregate<T -> String>
mysub2::Aggregate<T -> String>

and my application integrates the subsystems by drawing

myapp::Aggregate<T -> String>

Since each of the three Aggregates of String have different packages, oops, it would seem that they are different types and so cannot be passed interchangeably between subsystems.

The above arises from the natural encoding of a graphical representation in which Aggregate<String> is drawn once per diagram/package and referenced many times. The package owns and so appropriates the shared type.

In contrast, textual representations, in the absence of a typedef, elaborate Aggregate<String> for each reference. Each reference 'owns' the shared type, which is not appropriated by a prevailing package.

(This has been a major problem for attempts to provide UML-aligned XMI serialization for OCL since e.g. there is obviously only one Set(String) but who owns it, who persists it, and how is it referenced? Eclipse OCL has prototyped a solution whereby a shared orphanage package is responsible for owning the singletons, but everyone persists their singletons. This incurs unpleasant costs in creating local orphanages during a serialization and destroying them again during loading. Struggling with this finally made me see that there is a fundamental UML limitation.)

In similar scenarios where there is an ownership/reference dilemma, UML provides e.g. TemplateParameter::parameteredElement/ownedParameteredElement. Surely there should be a TypedElement::type/ownedType so that a TypedElement::ownedType can introduce a package-less type that is consequently shared by all similar introductions? Bloat could be avoided by one TypedElement::type referencing another TypedElement::ownedType. Alternatively a Package::sharedElements could contain local copies that are logically shared globally. (This could also solve the problem of everyone wanting their own Boolean PrimitiveType.)

The pseudocode for OrderedSet::insertAt assumes that the inserted element is not already contained.

Presumably insertion of an existing element does not increase the OrderedSet size.

Design choice. Is the old element retained or is the old element removed and the new element inserted? The latter might preserve the postcondition that the element at the index is the inserted object, but what if the removed element was earlier so that everything moved along first?

Surely the only predictable behavior is that the old element is retained?

Although it is clear that using a constructor to write an object to the system being modelled breaks the property of being side-effect free, it would be useful to return new objects as a result of the query functionality of OCL. It is possible to create a new Tuple for return from a function. For example: def: newDate1() : TupleType

= Tuple

; Rather than write this object to the model under query, it would only be returned as a query result so, under these circumstances, would not break the property of being side-effect free. This feature would be extremely useful to the HL7 GELLO project, which works with data models defined in absense of defined methods or constructors. If this feature were to only apply to classes marked in some way to guarantee they have no side-effects from construction then that would remain useful.

"asSequence" and "asOrderedSet" are specified as returning an unknown ordering. How deterministic is this? repeatable with the same tool version, the same tool, the same CPU, the same number of CPUs, any OCL tool?

"any" is specified as indeterminate.

Non-determinism is a very bad language characteristic.

Surely "any" should be the earliest element in asSequence()?

If a tool avoids anarchic sets, perhaps keeping a list and set for each 'set', the resulting behavior can be deterministic. But is specifying deterministic set evaluation algorithms appropriate for the OCL specification?

Suggest the specification should just require that a re-execution with:

• the same tool version
• the same Operating System etc
• the same single CPU
• the same command line options
  shall give the same result (unknown but deterministic).

OCL is an executable specification language that uses "invalid" as its exception handling mechanism for untoward execution, which clearly includes deterministic internal program control faults:

• divide by zero
• null-navigation
• ordered collection index out of bounds
  Does this behavior also include non-deterministic external problems:
• network/disk access failure
• stack overflow
• tooling malfunction

Without an answer to this question, it i impossible to know whether e.g. "aSequence->includes->last()" can be optimized to "x" or not. Is it necessary to fully evaluate aSequence, perhaps run out of memory, in order to incur an external issue that influences an evaluation?

The % (modulo/remainder) operator is realtively standard operator in many langages. It is missing from the OCL Standard Library. There is only Integer::mod().

QVTo 1,3 8.4.4 4 implies that there is a % modulo operator even though there isn't. See QVT14-44.

Suggest add Real::%

UML/OCL hardwire three capabilities of an Operation.

"body" is very useful
"precondition", "postcondition" are sometimes useful
anything else is unsupported.

Some users want frame conditions.

Code generation/analysis wants other forms of meta-evaluation.

Rather than expand the hardwired options, allow an Operation to have an extensible set of named capabilities.Some names such as "body", "precondition", "postcondition" can be standardized. Others could be reserved in anticipation.

OCL supports feature overloading and attempts to comply with UML. OCL does not define feature overloading itself. UML leaves feature overloading as a semantic variation point.

The OCL behaviour is therefore undefined. However a variety of behaviours particularly those involving null and invalid only make sense if operations are selected at run-time according to the dynamic type.

The example from an earilier pending issue:

Sequence(OclAny)

>count((-3)) = 2

wherein

UnlimitedNatural 3 widens to Integer 3 for successful comparison with Integer 3
Real 3.0 is successfully compared to Integer 3 widened to Real
String '3' widens to OclAny and fails to compare to Integer 3 widened to OclAny.

is difficult to realise if static type resolution is applicable in which case all pair-wise value comparisons would use OclAny::= rather than Real::=.

Suggest:

OCL define that features are selected dynamically at run-time.

A UML InstanceSpecification introduces classification within the M1 level. OCL is normally applicable to inter level typing. M0/M1 or M1/M2.

Does anInstanceSpecification.oclIsKindOf(XXX) use a same-level or meta XXX?

Does anInstanceSpecification.YYY use the YYY feature of the InstanceSpecification metaclass or any one of the anInstanceSpecification.classifier?

Is a new navigation operator needed to distinguish the two cases?

Practical evaluation of stereotypes requires OCL to reify the Stereotype instances. These instances should be accessible by Stereotype.allInstances().

e.g. if an ElementExtension is the Stereotype instance and Element.extensions are the applied stereotypes.

Stereotype.allInstances() is equivalent to

Element.allInstances().extensions->selectByKind(MyStereotype)

The last sentence of the first paragraph on page 37 says "All metaclasses defined as part of the OCL abstract syntax are shown with a light gray background.", but subsequent abstract syntaxs show OLC defined metaclasses in yellow

asOrderedSet() : OrderedSet(T)
Redefines the Collection operation. An OrderedSet that contains all the elements from self, in undefined order.

If asOrderedSet() is invoked more than once on the same Set, then presumably the subsequent calls have a defined order; the order previously used.

When used by QVTo the lack of determinism of Set ordering is a significant debugging nuisance. Suggest that there is a repeatable but unspecified underlying order determined perhaps by object creation order.

object.assoc[qualifier] returns a particular element from a qualified association.

With Map already suggested/prototyped for OCL, let object.assoc[] return a Map<qualifier,element> that avoids the loss of information from object.assoc that returns Collection<element>

null-in-Collections was added by the OCL 2.0 FTF in Issue 5972 in the unanalyzed hope that it would be useful.

https://ocl2015.lri.fr/OCL_2015_paper_0921_1400.pdf examines the null safety of OCL nad concludes that an ability to declare null-free collections is essential.

Since almost all collections in practical OCL are null-free, suggest that the OCL default should be for null-free collections, with an option to have null-full collections when really needed.

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

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

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

Example where navigational and qualifing use cannot be distinguished:

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

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

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

Issue 15836 suggests that a negative CollectionRanbge should be invalid even after considering the Sequence

->forAll idiom.

The idiom clearly requires that a negative range gives an empty range.

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.

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

This question arises in 2 different ways:

• can you sub-class one of the concrete descendents in
  a UML diagram - by referring to the OCL package - and thereby
  add functionality to your own collection types

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

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

Synthesized attributes, [D], [F], [G] The meaning of “and” at the end of the line is not clear and seems inconsistent with other parts. Are these logical operations? Add text to clarify this

Issue 12953 considered the problem of the element type of an empty collection and rejected OclVoid (Option 1) because Set{}->including(1) would fail.

This rejection is appropriate when the collection is modified as in Java, but is inappropriate for OCL where a new Collection is created. There is therefore no problem in deciding that the most derived common element type of Set{} (OclVoid) and 1 (Integer) is Integer causing Set(Integer)::including(Integer) to be invoked.

Given the following:

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

is the value of isaMethod() true or false?

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

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

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

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

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

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

How the merged model is serialized is an implementation issue

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?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

multiplicity.

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

a) Suggest addition of an ImportDeclarationCS

ImportDeclarationCS ::= import StringLiteralExpCS

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

import is a new reserved word.

b) Suggest addition of an IncludeDeclarationCS

IncludeDeclarationCS ::= include StringLiteralExpCS

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

include is a new reserved word.

c) Suggest addition of an OclDocumentCS

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

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

Re: OCL 2.0 formal/06-05-01

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

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

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

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

In the paragraph before Definition A.32 you will find, "... ppre = (spre, ßpre) describing a system state and variable assignments before the execution ...." Originally I had taken the ß's to be sets of assignments. Then I noticed that the text before this point refers to it repeatedly as an "assignment" in the singular. Now, here, and also in the middle of page 205 (which says, "ß' := ß

.") the indication is that beta is multiple of assignments. Consistency would be very desirable.

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

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

OCL Specification, v2.0

The specification does not make it clear how to apply collection operations to properties.

For instance, assume

class A

It appears that an invariant constraint that asserts that one of the entries in A.x must be 5 might be

context A
inv self.x->exists( p | p=5 )

However, this is a guess and does not appear to be entirely justified by the text.

UML-alignment of OCL type signatures
--------------------------------------------------------

Following discussion in the "Vagueness about meaning of 0..1 multiplicity in OCL and UML" threads
of the UML2 and OCL RTFs the following problems exist in alignment of the UML and OCL type systems.

The OCL specification does not provide a clear description of the comparative semantics of for instance
Integer[1] and Integer[0..1].

The Complete OCL syntax for an Operation Context Declaration uses OCL type decalarations and so
fails to provide the same expressivity as a UML operation declaration with multiplicities.

Suggest:

a) a clear indication that

An Integer[1] may have integer values, null or invalid, of which only integer values are well-formed.

An Integer[0..1] may have integer values, null or invalid, of which integer values and null are well-formed.

b) an enhancement to the type declaration syntax to allow

Integer[0..1] or Integer[1] to indicate a nullable/non-nullable value.

Set(Integer[1..7]) to capture the expressivity of a UML multiplicity

If meta-models provide both 'B::x' and 'A::B::x', it is not possible to access 'B::x' from a context with 'A::B' since 9.4.1[4] searches from the current scope and so resolve 'B' in 'B::x' to 'A::B'.

Suggest adoption of the C++ '::' global prefix so that '::B::x' can be used when 'A::B' occludes.

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

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

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

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

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

Similarly:

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

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

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

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

OCL supports access to a variety of properties such as self.a, self.b, self.c but provides no mechanism for indirection of the property selection.

Perhaps that the standard library support reflection more effectively with:

self.oclGet(MyClass::a)

OCL allows a user to define a run-time OCL meta-model through Property and Operation definitions that is based upon a specification-time UML meta-model.

It would be useful to allow a user to also introduce inheritance/conformance polymorphisms.

Thus:

context CommonPackage::CommonObject

context CommonPackage::CommonObject::isSerializable() : Boolean = false

context OCL::String conformsTo CommonPackage::CommonObject

context MyPackage::MyObject conformsTo CommonPackage::CommonObject

context YourPackage::YourObject conformsTo CommonPackage::CommonObject

could mix-in the capabilities of CommonObject to each of MyObject and YourObject and String.

This would allow common functionality to be mixed in once and used polymorphically rather than being added in amorphously and requiring an if-tree of per-context invocations of that functionality.

Issue 9796 responded to the problem with the undefined (and undefinable) withAtPre().

However the textual replacement of ".withAtPre()" by ".isPre = true" is not valid.

For instance

[D] AttributeCallExpCS.ast.source = if isMarkedPreCS->isEmpty()
then OclExpressionCS.ast
else OclExpressionCS.ast.withAtPre() endif

should be elaborated to:

[D] AttributeCallExpCS.ast.source = OclExpressionCS.ast
[D] AttributeCallExpCS.ast.isPre = isMarkedPreCS->notEmpty()

Section 7.5.4 describes an association navigation qualification to
accommodate
recursive associations.

e.g. self.employeeRanking[bosses]

in which "bosses" is a Property role name.

OCL 2.2 has no concrete syntax for this. Superficially it resembles an
AssociationClassCallExp, but that requires OclExpression values for its
qualifiers.

Prior to OCL 2.0 (and still present in many obstinate residual artefacts in
OCL 2.2),
there was an AssociationEndCallExp, whose syntax was identical to an
AssociationClassCallExp
and so it was removed and merged with AttributeCallExp as PropertyCallExp.

It would appear that a form of AssociationEndCallExp is required with
syntaxes

OclExpressionCS '.' pathNameCS[1] ('[' pathNameCS[2] ']')? isMarkedPreCS?
pathNameCS[1] ('[' pathNameCS[2] ']')? isMarkedPreCS?

in which pathNameCS[2] defines the NavigationCallExpCS.ast.navigationSource
that is currently completely undefined and very confusingly described in
Section 8.3.2:

"navigationSource The source denotes the association end Property at the end
of the object itself. This is used to
resolve ambiguities when the same Classifier is at more than one end (plays
more than one
role) in the same association. In other cases it can be derived."

Suggest:

Remove NavigationCallExp::navigationSource that currently has no semantics

Introduce QualifiedPropertyCallExp (and etc.) as a further NavigationCallExp
to support
the qualified navigation. It has two associations:

referredSourceProperty: Property (e.g. "bosses")
referredTargetProperty: Property (e.g. "employeeRanking").

Issue 7341 changed a number of syntaxes to permit a PathNameCS rather than a SimpleNameCS,
so that scope ambiguities could be resolved.

It is not clear why this was applied uniformly to all syntaxes where a name reference is in use. As a minimum
it just gives the user the discretion to clarify a subtle statement, and it avoids the impression that pathed-names
are special. It also avoids the need for some very similar concrete syntax expositions.

More specifically in an AssociationClassCallExpCS it would allow disambiguation of Left::Link and Right::Link as
alternate AssociationClasses.

Suggest allow PathNameCS in all places where there is not a specific requirement for a SimpleNameCS.

It is common in an iteration to require in iteration index.

This can be achieved rather expensively by indexOf, or less expensively by
iterating over an integer literal range.

It would be easier to define e.g.

forAllAt(index : Integer, i : T)

etc so that an implementation can supply the index efficiently.

UML supports generics/templates. OCL doesn't. This is a UML alignment failure.

Issue 14918 went most of the way to clarifying '=' behaviour.

But the Real::'=' and Real::'<>' overloads were omitted.

Consequently the fix to ensure that 1.0 = 1
evaluates to true when (1.0 <= 1) and (1.0 >= 1) will evaluate true is missing.

The spec defines the following postcondition for the append/prepend operations on OrderedSet:

result->size() = self->size() + 1

However, if self does already contain the added element, the size does not increase by one since the elements are unique.

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.

OrderedSet isn't discussed in the section on semantics

Synthesized attributes, [B] TBD should not be a part of International Standard. Modify the text as appropriate

There is no attribute designation of FeatureCallExp in Fig 8.2. However, in Attribute of FeatureCallExp class description (p43), isPre is described. Add isPre to Class “FeatureCallExp” on the class diagram (Fig. 8.2)

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.

OCL Specification, v2.0

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

"context" <contextdeclaration> "inv" <constraintname> ":" ...

The document does not seem to define this capability formally and I would like to see it also applied to pre, post, body, init, and derived constraints.

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

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

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

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.

The OrderedSet well-formedness constraints in 11.7.3 appear to have been
copied and pasted from Sequence. They need revision to consider the Set
consequences of .

Addition operations (includes, insertAt, union, append, prepend) have a
post-condition that the size increases, which is clearly not the case if
an additional element is equal to a pre-existing element.

In the particular case of insertAt there is an ambiguity as to whether
the insert index is the pre or post index. For instance when inserting 3
at index 5 into OrderedSet

the pre-index insertion
yields OrderedSet

whereas the post-index insertion yields
OrderedSet

. While the post-index insertion satisfies the
'post: result->at(index) = object' constraint, it is presumably not the
intent.

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

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

including(object : T) : OrderedSet(T)

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

post: result = self.append(object)

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

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

OCL 9.4.5 gives no recommendation on how to handle the multiple out capability of UML.

Suggest that the mapping of a UML operation with out or inout parameters to an OCL operation do the following:

remove all 'out' parameters from the OCL parameter list so that the OCL parameter list contains only 'in' and 'inout' parameters with 'read-only' behavior

change the return type to a Tuple whose part-names and types are determined by the conventional 'result' and the 'out' and 'inout' parameters.

It is also desirable to relax the upper multiplicity bound to allow multiple bodyExpressions in Complete OCL, one bodyExpression per returning parameter.

TupleLiteralExpPartEval is not included in Figure 10.11. Is VariableDeclEval the one? Add this element to Figure 10.11.

Three library operations do not appear to be declarable without intuitive typing semantics.

Introduction of an OclSelf template parameter that is the statically determined type of self can solve the problem. OclSelf is a reserved spelling.

Classifier::allInstances(OclSelf)() : Set(OclSelf) – set of the derived classifier
OclAny::oclType(OclSelf)() : OclSelf – my own type as statically known
OclAny::oclAsSet(OclSelf)() : Set(OclSelf) – set of my own and derived types, declared as the statically known type

[oclAsSet is the currently unspecified library operation used to realise implicit object-to-set conversion]

Without an OclSelf, almost any usage of these library operations must be followed by an oclAsType to the already known type.

e.g. with the OCL 2.3 type system the library function is

Classifier::allInstances() : Set(Classifier)

and so the usage is

MyType.allInstances() – is MyType instances as a Set(Classifier)
MyType.allInstances().oclAsType(Set(MyType)) – necessary cast to statically known type

Main text. TBD should not be a part of International Standard. Modify the text as appropriate.

The AS is referred to in a number of places as an abstract syntax tree. This is a misnomer that causes confusion in some academic circles. The AS should always be referred to as a Graph.

The intro to Section 8.2 states:

"OCL is a typed language. Each expression has a type that is either
explicitly declared or can be statically derived."

However OclMessage lacks type parameterisation and so the 7.7.2 example

context Subject::hasChanged()
post: let messages : Sequence(OclMessage) = observer^^update(? : Integer, ?
: Integer) in
messages->notEmpty() and
messages->exists( m | m.i > 0 and m.j >= m.i )

only works if the type analysis proceeds beyond "messages :
Sequence(OclMessage)" to
discover the initialiser with formal signature "Observer::update(i :
Integer, j : Integer)".

This will not in general be possible and so expressions such as "m.i > 0"
cannot be
statically checked, and cannot be dynamically expressed. Indeed since m is
an OclMessage,
"m.i" is not well-formed.

Suggest that OclMessage is redefined as:

OclMessage<OclOperation> or OclMessage<OclSignal>

requiring the type to be determinate or discovered by oclAsType.

I hope someone can explain to me why OCL does not have a reference to "super" (similar to the existing reference to "self"). Wouldn't you want to sometimes call the redefined version of an operation from an OCL exrpression, similar to how you can do that in Java?

From my limited knowledge of ALF (the action language), I understand it supports the "super" reference, so this tells me there is no semantic restriction there?

OCL 12.10 awaits alignment with the UML 2.0 metamodel.

Consequently, the relationship between a result-valued OCL bodyExpression and a Boolean-valued UML bodyCondition is unspecified. A common pragmatic resolution has been to equate the two and ignore the Boolean-valued requirement of a UML Constraint.

In order to accommodate prevailing practice and also support UML's multiple out/inouts, suggest:

Reinterpret the grammar

prePostOrBodyDeclCS ::= ‘body’ (simpleNameCS)? ‘:’ OclExpressionCS

such that

the simpleNameCS is the name of the return parameter with 'result' as the anonymous default

OclExpressionCS is a result-valued bodyExpression if OclExpressionCS does not reference the simpleNameCS or its defgault.
OclExpressionCS is a Boolean-valued bodyCondition if the return parameter is referenced.

[Allow multiple body declarations.]

Thus

"body: ..." is a shortform of "body result: ..." which is a shortform for "body result: result = ..."

and

body: ...
body A: ...
body B: ...

could be the specification of a UML operation

f(out a : A, inout b : B, in c : C) : Z

The Issue 17220 clarification that the empty string is a substring at index 1 failed to revise the postcondition that the index of of any string in the empty string is at index 0.

Replace:

post: self.size() = 0 implies result = 0

by

post: self.size() = 0 and s.size() > 0 implies result = 0

and move it to the second postcondition

The example of collect in terms of iterate given in section section 7.6.6 is not flattened. Actually it is a copy of the definition of collectNested in section 11.9.2.