Re: Optional attributes



Date view Thread view Subject view Author view Attachment view

From: Shane Sendall (sendall@acm.org)
Date: Tue 18 May 2004 - 14:59:51 BST


Hi John,
My understanding is that OclUndefined is used in OCL to represent both 
ill-formed expressions and "null" values. This double role is bound to 
be problematic; and you give an example of where we don't want "null" to 
be classed as a value, but clearly OclUndefined playing the role of 
"null"is a value.
I think you in fact point out the usefulness of OclUndefined in your 
discussion below: OclUndefined means your expression is ill-formed.
We could simplify things (alot) by dropping back to a two-value logic, 
i.e., drop OclUndefined. The only limitation of this is that we would 
lose those rules for the logic operators, e.g., true OR anything (even 
something undefined) is true.
So assuming we don't drop back to a two-value logic, we could make 
OclUndefined just mean that the expression is ill-formed and an 
expression that contains it is simply ill-formed, except those one I 
mentioned for the logic operators.
With this approach, "null" values can still be represented for entities 
with a [0..1] multiplicity constraint. In this case, we could have an 
operation "oclIsNull", which returns true if the result is empty, and 
false otherwise, making use of OCL's double interpretation 
(object/collection) of navigation to entities with [0..1].

Seems a far enough sort of proposal, if I have expanded on what you 
meant you correctly. And it seems to address the issue raised without 
any major changes needed to the spec. In fact, it would require simply a 
clarification in the specification as to what OclUndefined means and the 
addition of an operator something like oclIsNull.

Does anyone have any problems with this or better proposals?

Cheers,
    Shane

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

Date view Thread view Subject view Author view Attachment view