Re: Invariants evaluating to undefined



Re: Invariants evaluating to undefined

From: Thomas Baar ^lt;thomas.baar@epfl.ch>
Date: Mon 13 Mar 2006 - 20:31:36 GMT
Message-ID: <4415D6A8.1060308@epfl.ch>
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 
object-expression
and NOT as a set-expression. Thus, there is no need to equate Set{} = 
Set{oclUndefined},
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 
'null'-value
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,
Thomas


-- 
Dr. Thomas Baar
Software Engineering Laboratory
School of Computer and Communication Sciences EPFL
EPFL IC UP-LGL
INJ 337 (Bâtiment INJ)
Station 14
CH-1015 Lausanne, Switzerland
Tel +41 21 693 2580, Fax +41 21 693 5079
mailto:thomas.baar@epfl.ch   http://lgl.epfl.ch/members/baar/
********************************************************
Do not miss MoDELS/UML 2006: see http://www.modelsconference.org 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