Re: Optional attributes



Date view Thread view Subject view Author view Attachment view

From: Daniel Jackson (dnj@mit.edu)
Date: Thu 20 May 2004 - 02:45:21 BST


and one other thing i should point out: hehner's bunch is really a new 
algebraic structure, with its own axiomatization. alloy's sets are just 
plain old sets, no different from the sets in OCL.

/daniel


On May 19, 2004, at 7:52 PM, Joaquin Miller wrote:

> 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