Re: Optional attributes

Date view Thread view Subject view Author view Attachment view

From: Shashank (
Date: Wed 19 May 2004 - 10:06:40 BST

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,

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
>> >
>> > with a message containing the word "unsubscribe".
>> >
>> To remove yourself from this list please mail
>> with a message containing the word "unsubscribe".

Date view Thread view Subject view Author view Attachment view