#14 let defined property cannot be navigated

[Jörn Guy Süß]

From UML 1.4.2, adapted for the fact that MOCL cannot
handle def, and infers to broad a collection type:

package Foundation::Core

context GeneralizableElement

inv:

let parent : Set(GeneralizableElement) =
self.generalization.parent->asSet()

let allParents: Set(GeneralizableElement) = self.parent-
>union(self.parent.allParents)

endpackage

Yields a type error:

The property allParents is undefined on the type Set
(Core::GeneralizableElement)

However, parent is a property equivalent to navigation.
Thus if Core::GeneralizableElement.allParents is defined,
Set(Core::GeneralizableElement).allParents , Bag
(Core::GeneralizableElement).allParents and Sequence
(Core::GeneralizableElement).allParents are also defined.

[Fadi Chabarek]

Logged In: YES
user_id=450963

OCL (although part of UML) does not define that and how let
attributes can be used recursivley (although UML wfr make
use of this feature). Thus allParents is also undefined on
the parent of a GeneralizableElement beeing evaluated in
terms of OCL. The respective implicit collect called on
respective collections therefore results (correctly) in a
type error.

I will add a new tracker regarding Implementation issues
like improvements, conformance to the standard etc. and add
this topic. But as you know I do not have the ressources to
change this (in the near future!?!). You are invited to help
and to report this issue to the OMG.

[Jörn Guy Süß]

Logged In: YES
user_id=557658

Regarding definitions, as an extension of let for reuse
UML, Version 1.4.2 363 states:

"variables and operations defined in the definition constraint
are known in the same context as where any property of the
Classifier can be used. In essence, such variables and
operations are psuedo-attributes and psuedo-operations of
the classifier. They are used in an OCL expression in exactly
the same way as attributes or operations are used."

It is reasonable to assume that plain let expressions should be
interpreted in the same fashion. Apart from that, this is also
the behavior defined in the formal (and verbally in the oo-
based) language description in OCL 2.0. Although the formal
language description is non-normative, I see this as
supporting the assumption laid out above.

As mentioned before, the differing opinion should be made
explicit, as not to invite false assumptions.

[Fadi Chabarek]

Logged In: YES
user_id=450963

In essence it is correct that an attribute should be useable
recursively in a def let expression, but the problem is that
OCL does not state how the recursion is terminated. IMO
every attribute called in the fashion above results in an
infinite loop (and therefore has not been implemented). One
could argue that let attributes are not called on empty
sets, but I haven't found a hint in any passage of the standard.

I'm not that familiar with OCL 2.0. Could you give me a more
precise location, where the recursion is defined? How does
it terminate?

If it was intedended to allow resursive attributes in def
statements (and there is a hint how the termination must be
implemented) you would be right that mocl should support the
recursive attribute feature.

[Jörn Guy Süß]

Logged In: YES
user_id=557658

Here is Baumeisters first post on the topic:

http://www.cs.york.ac.uk/puml/puml-list-archive/0013.html

And Alexander Knapps formal treatment of recursion for OCL
1.4
http://www.pst.informatik.uni-
muenchen.de/veroeffentlichungen/cengarle-knapp:2001a.pdf

That document is more detailed than the UML 2.0 formal
spec. But the 2.0 has been grown from this. Also, it exactly
treats the version you are using.