Re: Invariants evaluating to undefined

Re: Invariants evaluating to undefined

From: Thomas Baar ^lt;>
Date: Mon 13 Mar 2006 - 20:31:36 GMT
Message-ID: <>
D H. Akehurst wrote:

> The 'Set{undefined} = Set{} ' issue is not a "proposal".
> It was our interpretation of the information given in the standard. It 
> was the only interpretation we found to be consistent with
> "prop->isEmpty() = prop.oclIsUndefined()"
> I have just looked at the June 2005 version of the standard,

In the June05 version you find on page 32:

> The value of this expression is the set of objects on the other side 
> of the associationEndName association. If the multiplicity of
> the association-end has a maximum of one (“0..1” or “1”), then the 
> value of this expression is an object.

Thus, 'prop' is an expression of an object type. But at the end of page 
32 we learn

> Because the multiplicity of the role manager is one, self.manager is 
> an object of type Person. Such a single object can be used as
> a Set as well. It then behaves as if it is a Set containing the single 
> object.

I have interpreted both quotes as follows:
'prop' is an expression of an object type but also of a collection type.
The decision, what the actual type of 'prop' is depends on the context in
which expression 'prop' is embedded into.

In 'prop->isEmpty()' the expression 'prop' is read as a set-expression. 
It is
evaluated to true whenever there is not linked object to which 'prop' 
can navigate.

In 'prop.oclIsUndefined()' the expression 'prop' is read as an 
and NOT as a set-expression. Thus, there is no need to equate Set{} = 
despite the fact that 'prop.oclIsUndefined()' is evaluated to true under
the same circumstances under which 'prop->isEmpty()' is evaluated to true.

> in this there is explicit discussion of 'null' values, and their 
> containment in collections [section 8.2].
> I have to say that I don't know if this is the latest version of the 
> standard, just the latest I could find on OMG web site.
> I also don't really understand the new introduction of 'OclInvalid' 
> Why is this needed/different to OclUndefined ??

The authors of the standard obviously made an attempt to distinguish the 
from other kinds of undefinedness (what is doubtlessly a good thing to do).
As I see it, they renamed the old type OclVoid to OclInvalid and what is 
now called
OclVoid is a type with just one element 'null'.

Best regards,

Dr. Thomas Baar
Software Engineering Laboratory
School of Computer and Communication Sciences EPFL
INJ 337 (Bâtiment INJ)
Station 14
CH-1015 Lausanne, Switzerland
Tel +41 21 693 2580, Fax +41 21 693 5079
Do not miss MoDELS/UML 2006: see for the 9th International Conference on Model Driven Engineering Languages and Systems (formerly the UML series of conferences)
Received on Mon Mar 13 20:32:09 2006