Re: Optional attributes



Date view Thread view Subject view Author view Attachment view

chiorean@nessie.cs.ubbcluj.ro
Date: Mon 17 May 2004 - 20:12:36 BST


Dear John,

My perception is the following:
 
 - The oclIsUndefined() is appropriate to be used in order to see if a value   
   was set or not. Consequently, let the class A with the attributes
   p1: Integer, irrespective p2 [0..1]: Integer.
 
 - This means that p1 is a mandatory attribute and p2 an optional attribute
 
 - In the A context, p1.oclIsUndefined, tell us that the p1 value was not yet
   established. Compared with programming languages, this offers a finer
   perception. In secure programming languages, in absence of initial attribute
   values, the corresponding attribute values are set to default values, so,
   the user has no the opportunity to infer how these values were defined.
  - Therefore, in my opinion, it is meaningful to write:

   context A
            inv mandatoryAttribute:
               not p1.oclIsUndefined implies p1.oclIsTypeOf(Integer)
 
 - Regarding the second invariant, my opinion is that a more expressive
   solution will be:

   inv optionalAttribute:
            not p2->isEmpty implies
                               if p2.not oclIsUnefined
                                  then p2.oclIsTypeOf(Integer)
                                  else false
                               endif
  
I am waiting to hear from you whether you agree with my point of view and 
whether I correctly understood your question.
  
Best regards,
  
Dan




Quoting John Daniels <jd@syntropy.co.uk>:

> Hi all,
> 
> I'm struggling to understand the relationship between optional
> attributes (ie attributes with [0..1] multiplicity) and the use of
> oclUndefined.
> 
> If I have a class X with an attribute p simply defined as:
> 
> p : Integer
> 
> can it ever be the case that p.oclIsUndefined()? In other words, can I
> assume that p will always have a valid integer value?
> 
> I suspect the answer to that question is "no", in which case if I want
> to ensure that p always has an Integer value I'd have to add the
> invariant:
> 
> context X
> inv: not p.oclIsUndefined()
> 
> Now, assuming I'm right about this, I don't like it much. It means
> that all my attributes are effectively "optional" unless I add a
> constraint to them. Which makes me wonder why I'd ever define p like
> this:
> 
> p [0..1] : Integer
> 
> which is what all the textbooks tell you is the correct way of
> defining an optional attribute. It would be good if
> 
> p->notEmpty() implies not p->any().oclIsUndefined()
> 
> but since, I suspect, it doesn't, I'm struggling to see why I'd ever
> bother with [0..1] as the multiplicity for an attribute. Am I missing
> something?
> 
> --John
> 
> John Daniels
> www.syntropy.co.uk
> 
> 
> 
> 
> To remove yourself from this list please mail
> puml-list-request@cs.york.ac.uk
> with a message containing the word "unsubscribe".
> 




-------------------------------------------------
This mail sent through IMP: http://horde.org/imp/
on Webmail.UBBCluj.Ro

Date view Thread view Subject view Author view Attachment view