Fwd: 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 - 02:29:21 BST


Sorry, either see:

http://www.cs.toronto.edu/~hehner/aPToP/aPToPtrans2.pdf

Or, if you like some text with your formulas, see chapter 2 of:

http://www.cs.toronto.edu/~hehner/aPToP/

which is in the file:

http://www.cs.toronto.edu/~hehner/aPToP/aPToP-B.pdf

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