Re: Optional attributes



Date view Thread view Subject view Author view Attachment view

From: Shane Sendall (sendall@acm.org)
Date: Mon 17 May 2004 - 21:27:16 BST


Hi John (and Dan),
In fact, I think John may have picked up on an unintended loophole in 
the type system of OCL. Whether this situation could ever arise in 
practice is another question.
Comments embedded below.
John Daniels wrote:

>Hi all,
>
>I'm struggling to understand the relationship between optional
>attributes (ie attributes with [0..1] multiplicity) and the use of
>oclUndefined.
>
>If I have a class X with an attribute p simply defined as:
>
>p : Integer
>
>can it ever be the case that p.oclIsUndefined()? In other words, can I
>assume that p will always have a valid integer value?
>
According to the spec, OclVoid (the type of OclUndefined) is a subtype 
of all types in OCL.This means that "undefined" is a valid value for 
Integer or any other type for that matter.
As such, in theory
p [1..1]: Integer
could have OclUndefined as its value (a collection of one element - 
OclUndefined), i.e., and still satisfy the 1..1 constraint (even though 
you couldn't treat it like a normal integer nor do anything useful with it).

IMO, the intent of the designers was that:
p [1..1] : Integer
should imply the invariant that you give below.

>I suspect the answer to that question is "no", in which case if I want
>to ensure that p always has an Integer value I'd have to add the
>invariant:
>
>context X
>inv: not p.oclIsUndefined()
>
>Now, assuming I'm right about this, I don't like it much. 
>
IMO I think this was an oversight of the designers

>It means
>that all my attributes are effectively "optional" unless I add a
>constraint to them. Which makes me wonder why I'd ever define p like
>this:
>
>p [0..1] : Integer
>
>which is what all the textbooks tell you is the correct way of
>defining an optional attribute. It would be good if
>
>p->notEmpty() implies not p->any().oclIsUndefined()
>
>but since, I suspect, it doesn't, I'm struggling to see why I'd ever
>bother with [0..1] as the multiplicity for an attribute. Am I missing
>something?
>
If I have understood the spec correctly, then your interpretation is 
correct.

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...

Any takers?

Cheers,
   Shane

Date view Thread view Subject view Author view Attachment view