Re: Optional attributes



Date view Thread view Subject view Author view Attachment view

From: Shane Sendall (sendall@acm.org)
Date: Wed 19 May 2004 - 12:13:31 BST


Hi Shashank,
My take on OclUndefined is that it is an indicator for ill-formed 
expressions, e.g., x/0, some (detectable) logic contradiction, calling 
the 'any' operation on an empty collection, etc. As static errors are 
picked up before runtime, OclUndefined is only really associated to 
runtime errors.
Now the question arises as to why one would want a value for being 
ill-formed, why not just let the runtime crash the party and throw a 
runtime exception. And the only thing that leads one in this direction 
is the case where being undefined is ok. In OCL, it is ok to be 
undefined if you are in a larger expression with an 'or' logic operator 
and 'true' as the other operand, or with an 'and' operator and 'false' 
as the other operand, etc. Outside of these cases, you want the runtime 
to throw an exception.

Cheers,
    Shane

Shashank wrote:

>Hi Shane,
>
>I am sure the mentioned problem may be refined to better design with
>more refined constraint expressions. As you have already done below.
>
>But my primary objective was to be sure that at some high level of
>model, this way of using oclUndefined() expression may be more
>expressive ? And brings out more appropriate usage of oclUndefined().
>
>
>Hash code etc. may not be really applicable for the scenario mentioned.
>But as you know by now that primary objective of this was to realize a
>scenario for applying oclUndfined(). And using undefined for elements
>whose definition is not available within the context.
>
>Another similar example could be in context of CORBA where we have type
>"Any". Any data type (defined in OMG IDL) can be "inserted" and
>"extracted" from it. So while reading data from "Any" I may compare it
>to another known types that I expect (string, structure. long, sequence
>etc.). Here again while extracting and comparing if I dont get my type
>(may be I expect array type always), for my context data coming (inside
>Any) is undefined.
>
>With these examples I wanted to clear out the meaning of oclUndefined(),
>as different from usage of multiplicity. I may represent the same using
>multiplicity 0..1. But then have to somewhere document the condition as
>well. (May be using constraints again). But using oclUndefined makes it
>more intuitive may be.
>
>Multiplicity enables to model optional element (attribute etc.) but
>should be used more to imply relationship behavior (for example  this
>case where it is defined in context of  attributes with multiplicity
>expression). While other constraints (like oclUndefined() are used to
>model more dynamic functional behavior.
>Or I missed something again?
>
>thanks for prompt reply,
>regards,
>Shashank
>
>
>Shane Sendall wrote:
>
>  
>
>>Hi Shashank,
>>Maybe I misunderstood your problem, but I can't see how you can decide
>>whether the hash code is any good or not without a comparison. From
>>this condition, you can decide what you want to assert. Here is some
>>code (note that I have simplified things by passing the serialized
>>hash code as a  parameter).
>>context MyClass::readSerialized(serializedHash: HashCode)): MyClass
>>post: if serializedHash = self.hashCode() then
>>            result = ...
>>         else
>>            result = ...
>>         endif
>>
>>I hope that helps... (I probably misunderstood though)
>>
>>Cheers,
>>    Shane
>>
>>
>>Shashank wrote:
>>
>>    
>>
>>>Hi Shane,
>>>
>>>Lets suppose I get a serialized object.
>>>
>>>Now I have a list of hash codes of objects with different states of
>>>same class).
>>>
>>>Now when I try to compare hash value of object read from serialized
>>>object, and
>>>compare that with existing hash codes it may fail, as the object may
>>>have
>>>different state!!. And if this happens then I need to take care
>>>against possible
>>>commission fault. And I want to set the state of some object to
>>>something.
>>>
>>>Now how do I model following requirement
>>>if serialized object is not valid  then set state of some object to
>>>something.
>>>
>>>Can I use OCL to model that using oclUndefined
>>>
>>>context MyClass : readSerialized() :
>>>        let hash :HashCode = self.getObject () in
>>>        if hash.oclIsUndefined() then
>>>        result = this;
>>>    else
>>>        result = that;
>>>    end if
>>>
>>>
>>>In the above scenario oclIsUndefined()  (Undefined because the hash
>>>code created
>>>doesn't matches with existing list of hash code  (Meaning object
>>>(serialized
>>>objects) definition is not available to me?)
>>>
>>>Is that correct usage of undefined? and correctly distinguishes from
>>>the context
>>>of its usage that we are discussing.
>>>
>>>Shane Sendall wrote:
>>>
>>>
>>>      
>>>
>>>>Hi Laurie,
>>>>It is interesting that you differentiate between "never been
>>>>initialized" and "uninitialized". Can you whet our appetitte
>>>>further by
>>>>giving us some examples of where you use this, i.e., some
>>>>motivating
>>>>examples?
>>>>
>>>>Thanks,
>>>>    Shane
>>>>Laurence Tratt wrote:
>>>>
>>>>
>>>>        
>>>>
>>>>> <snip>
>>>>> Most languages that I am aware of do not, at the user level,
>>>>> differentiate
>>>>> between "this value has NULL assigned to it" and "this value is
>>>>> undefined" -
>>>>> NULL is all that is given to the user. Note that I am aware of
>>>>> several
>>>>> languages which *internally* have a way of noticing that certain
>>>>> variables
>>>>> and slots have not yet been assigned to, but there's no way for
>>>>> the user to
>>>>> test for this other than causing an exception to be generated.
>>>>> Certainly, my
>>>>> own Converge language follows in these footsteps, so that I can
>>>>> detect
>>>>> people attempting to read from variables before they have been
>>>>> assigned an
>>>>> initial value. Once an initial value has been assigned (be it
>>>>> NULL or
>>>>> anything else), it is impossible for the variable to return to
>>>>> the
>>>>> "undefined" state.
>>>>>
>>>>> Yours,
>>>>>
>>>>>
>>>>> Laurie
>>>>>
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>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