Re: Optional attributes



Date view Thread view Subject view Author view Attachment view

From: Joaquin Miller (jm-miller-at@sbcglobal.net)
Date: Thu 20 May 2004 - 00:52:00 BST


For those interested, there is a theoretical foundation for Daniel's 
approach, worked out by Hehner.  See chapter 2 of 
http://www.cs.toronto.edu/~hehner/aPToP/aPToPtrans2.pdf

(In this pleasant theory, 'null' is the name of an item (the name of a 
value, if you like), to wit: the empty bunch.  Clean as a whistle.  And 
uniform, a quality much to be desired.)


Daniel Jackson wrote:
>john,
>
>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 ideas.
>
>see, for example, the now rather dated alloy overview at:
>
>         http://alloy.mit.edu/reference-manual.pdf
>
>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.
>
>/daniel
>
>
>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 <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
>>
>>
>>
>>
>>To remove yourself from this list please mail puml-list-request@cs.york.ac.uk
>>with a message containing the word "unsubscribe".
>
>
>
>
>To remove yourself from this list please mail puml-list-request@cs.york.ac.uk
>with a message containing the word "unsubscribe".

Date view Thread view Subject view Author view Attachment view