Re[2]: Optional attributes



Date view Thread view Subject view Author view Attachment view

From: John Daniels (jd@syntropy.co.uk)
Date: Tue 18 May 2004 - 12:29:17 BST


Hi Shane,

I'm pleased you agree with my analysis, but I don't really agree with
your assessment that this is not a severe problem. Ok, so it's not
earth shattering, but I do think it has an impact on all UML users.

My bet is that pretty much everyone who uses UML and defines an
attribute as:

Class X
p : Integer

thinks they are saying "whenever the system [or business, or whatever]
is in a quiescent stable state all instances of X will have a valid
Integer value in their p slot." It's clear that, as things stand, that
may not be true.

It might be that all we need to do is make it clear that if a slot
ever had the value OclUndefined that would imply that the model was
badly formed - in other words, OclUndefined can never correspond to a
valid value in the system being modelled. It indicates a sort of model
exception. So, with this interpretation, it would be very unusual to
assert that an attribute had that value. Unless there's some other use
for OclUndefined that I haven't grasped? I understand how it works,
but what exactly is OclUndefined supposed to be *for*?

Cheers,

--John

====
Original message
From: Shane Sendall <sendall@acm.org>
Date: 18 May 2004
Subject: Optional attributes
----
Hi,
Comments embedded below.
John Daniels wrote:

>Hi Shane,
>  
>
>>HOWEVER, the question arises as to when this situation could arise,
>>because (as far as I know) OclUndefined can never really be "assigned" 
>>to anything (it is not the same as null or nil in programming 
>>languages): it simply makes the overall expression undefined (except for 
>>some special cases of lazy evaluation).
>>So if you could say p is initialized to some expression that is 
>>undefined then you would run across this problem. However, I do not 
>>think that this is possible in OCL (for the reason given above).
>>So I guess my question is whether my statement about OclUndefined is 
>>correct. If it is correct, then maybe there is really no (practical) 
>>problem after all...
>>    
>>
>
>I realise that OclUndefined can't be "assigned" to anything, but it's
>trivial to imply that it has been:
>
>p : Integer
>q : Boolean
>
>inv: q implies p = OclUndefined
>
The intention of OCL is that you use oclIsUndefined(), i.e.,
inv: q implies p.oclIsUndefined()
After checking out the definition of oclIsUndefined(), it looks like you 
are still correct (pp. 149 of spec):
  oclIsUndefined() : Boolean
  Evaluates to true if the self is equal to OclUndefined.
  post: result = self.isTypeOf( OclVoid )

Looks to me like we have one for the OCL revision laundry list...
Clearly this is not a severe problem, but nevertheless one worth fixing IMO.

Cheers,
    Shane

Date view Thread view Subject view Author view Attachment view