Re[2]: Optional attributes

Date view Thread view Subject view Author view Attachment view

From: John Daniels (
Date: Tue 18 May 2004 - 12:39:30 BST

Hi Dan,

I think you are correct in what you say but you are merely confirming
what I thought. I understand in theory the difference between the
absence of a slot (i.e. p2->isEmpty()) and the value of a slot being
undefined (i.e. p1.oclIsUndefined()), but in practice both cases
amount to the same thing: the attribute doesn't have a value. I don't
like having two ways of saying the same thing, so I am seeking
guidance on when to use the two approaches.

As you will see in another of my emails, my preference is to hold the
line that p:Integer defines a mandatory attribute, and that, for such
a definition, p.oclIsUndefined() would indicate an "exception" in the
model, and not be meaningful in the context of the system being

All the best,


Original message
From: <>
Date: 17 May 2004
Subject: Optional attributes
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
I am waiting to hear from you whether you agree with my point of view and 
whether I correctly understood your question.
Best regards,

Quoting John Daniels <>:

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

This mail sent through IMP:
on Webmail.UBBCluj.Ro

Date view Thread view Subject view Author view Attachment view