Re: Optional attributes

Date view Thread view Subject view Author view Attachment view

From: Daniel Jackson (
Date: Wed 19 May 2004 - 23:06:49 BST


we've done quite a lot of work on this in the context of Alloy, an 
object modelling language very similar to OCL. Alloy takes a more 
minimalist approach than OCL, and it's not as expressive in some 
respects, so it may be that Alloy's solution won't work for you. but 
you may want to look at what we've done as it may give you some useful 

see, for example, the now rather dated alloy overview at:

in short, Alloy has no null or undefined value, and treats an optional 
attribute as one that either has an empty value, or a set containing a 
single element. this has nice syntactic and semantic consequences, and 
seems to be easier for people to understand than 3 valued logics or 
special values.


On May 18, 2004, at 7:29 AM, John Daniels wrote:

> 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 <>
> 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
> To remove yourself from this list please mail 
> with a message containing the word "unsubscribe".

Date view Thread view Subject view Author view Attachment view