UML notation question...

In article <pan.2004.04.08.00.54.26.41111@acm.org>,
Donald Roby <droby@acm.org> wrote:
>On Tue, 06 Apr 2004 09:57:43 -0400, Bradley K. Sherman wrote:
>
>> In article <rhg470lnigsfu7911qglmkomnevap41bno@4ax.com>, Robert C.
>> Martin <u.n.c.l.e.b.o.b@objectmentor.com> wrote:
>>>>>>1) A must be either a B or a C
>>>>>>2) a B might be a C
>>>>>>
>>>>>>And if A is a B which is a C, then (1) is violated.
>
>It appears from this conversation that you interpret "either ... or" as
>meaning XOR. It also appears others have interpreted it differently.
>
>This is why we don't code in English.

We specify in English. Statement (1) is XOR because of the
word 'either'. That's why I only hire *fluent* speakers
of English.

If you think it is ambiguous -- which it is not -- then you should
ask for clarification before coding or using UML. Why people
choose this latter path is a complete mystery to me and this
thread just confirms my suspicions.

--bks

On Wed, 07 Apr 2004 22:00:10 -0400, Bradley K. Sherman wrote:

> In article <pan.2004.04.08.00.54.26.41111@acm.org>, Donald Roby
> <droby@acm.org> wrote:
>>On Tue, 06 Apr 2004 09:57:43 -0400, Bradley K. Sherman wrote:
>>
>>> In article <rhg470lnigsfu7911qglmkomnevap41bno@4ax.com>, Robert C.
>>> Martin <u.n.c.l.e.b.o.b@objectmentor.com> wrote:
>>>>>>>1) A must be either a B or a C
>>>>>>>2) a B might be a C
>>>>>>>
>>>>>>>And if A is a B which is a C, then (1) is violated.
>>
>>It appears from this conversation that you interpret "either ... or" as
>>meaning XOR. It also appears others have interpreted it differently.
>>
>>This is why we don't code in English.
>
> We specify in English. Statement (1) is XOR because of the word
> 'either'. That's why I only hire *fluent* speakers of English.
>
> If you think it is ambiguous -- which it is not -- then you should ask
> for clarification before coding or using UML. Why people choose this
> latter path is a complete mystery to me and this thread just confirms my
> suspicions.
>
>
"When I use a word," Humpty Dumpty said, in a rather scornful tone, "it
means just what I choose it to mean, neither more nor less."

I quite agree that the sentence ought to mean XOR. But the intent is
ambiguous because of common usage.

English is ambiguous (among other reasons) because people misuse it. If
you can control the precision with which all the people with whom you
communicate speak you have an immense power. I don't hire the people who
write all the stuff I have to read, so I don't have such control, and have
to try to understand what they really intend.

In the situation above, I read from the second sentence that maybe the
original poster didn't really mean that "either", and yes, I would ask for
clarification before proceeding to a diagram or code. Or maybe I'd draw
a Venn diagram and inquire as to whether it matched his intent.

Since I have heard this particular phrase used with different real intent
quite frequently, I tend to like the redundancy of adding "and not both".
And if I really mean the non-exclusive disjunction I might say "Every A
must be a B or a C or both". And if you want to specify in English with
certainty of avoiding ambiguity, I'd recommend this approach.

But English has plenty of other ambiguities, and if you really want an
unambiguous specification, English isn't the right language. You should
look for people who speak mathematics fluently.

In article <pan.2004.04.09.00.10.03.788129@acm.org>,
Donald Roby <droby@acm.org> wrote:

>>>>>>>>1) A must be either a B or a C
>>>>>>>>2) a B might be a C
>>>>>>>>
>>>>>>>>And if A is a B which is a C, then (1) is violated.

>I quite agree that the sentence ought to mean XOR. But the intent is
>ambiguous because of common usage.

Could you give me an example of common usage where (1) and (2)
are not contradictory? A pretty weak constraint, just replace
A,B,C with English nouns.

--bks

bks@panix.com (Bradley K. Sherman) wrote in message news:<c52bna$567$1@panix3.panix.com>...
> In article <pan.2004.04.08.00.54.26.41111@acm.org>,
> Donald Roby <droby@acm.org> wrote:
> >On Tue, 06 Apr 2004 09:57:43 -0400, Bradley K. Sherman wrote:
> >
> >> In article <rhg470lnigsfu7911qglmkomnevap41bno@4ax.com>, Robert C.
> >> Martin <u.n.c.l.e.b.o.b@objectmentor.com> wrote:
> >>>>>>1) A must be either a B or a C
> >>>>>>2) a B might be a C
> >>>>>>
> >>>>>>And if A is a B which is a C, then (1) is violated.
> >
> >It appears from this conversation that you interpret "either ... or" as
> >meaning XOR. It also appears others have interpreted it differently.
> >
> >This is why we don't code in English.
>
> We specify in English. Statement (1) is XOR because of the
> word 'either'. That's why I only hire *fluent* speakers
> of English.
>
> If you think it is ambiguous -- which it is not -- then you should
> ask for clarification before coding or using UML. Why people
> choose this latter path is a complete mystery to me and this
> thread just confirms my suspicions.
>
> --bks

Just to clarify a few things - I was aware of the ambiguity in the
ENglish "Is a" when I posed the question. And I was also aware that I
was (unfortunately) using it in two different senses...

Let me add some clarifications to the matter :

The context here is requirements analysis. Therefore, we are not
talking about software classes, but elements of the domain model.

As for a real example, that would certainly clarify things. The
following example is isomorphic to the one I am trying to deal with :

Suppose a company has Employees (D), which include union members (B),
and confirmed employess (C) (and other types). Of course, union
members may be confirmed employees (and vice versa), but not
necessarily. They wish to set up a Staff club. Staff Club Members (A)
must be either Union Members or Confirmed Employees (of course they
may be both, if the employee happens to be a union member)

By the way, I am a native speaker of English... :-)

Thanks for bringing to my attention the {or} notation.... I'll almost
certainly use it...

- Mike H....

In article <cfcb68e.0404081829.13a6a9d@posting.google.com>,
Michael Hartley <policymodel@hotmail.com> wrote:
>> >>>>>>1) A must be either a B or a C
>> >>>>>>2) a B might be a C
>> >>>>>>
>> >>>>>>And if A is a B which is a C, then (1) is violated.

>Suppose a company has Employees (D), which include union members (B),
>and confirmed employess (C) (and other types). Of course, union
>members may be confirmed employees (and vice versa), but not
>necessarily. They wish to set up a Staff club. Staff Club Members (A)
>must be either Union Members or Confirmed Employees (of course they
>may be both, if the employee happens to be a union member)

Okay, then:
(1b)Staff Club Members must be either Union Members or Confirmed Employees.
(2b)A Union Member might be a Confirmed employee.

Hmmm, better would be

(1c)Staff Club Member may be either Union Members or Confirmed Employees
or
(1d)Staff Club Members must be either Union Members or Confirmed
Employees or both.

However, if we add either semantic gloss, statement (2b) is superfluous.
or at least we need to add
(3) a C might be a B
or equivalent.

I accept your clarification, but I think we are beginning to
understand that an hour at the whiteboard can save a week
in the cubicle, no?

--bks

On Thu, 08 Apr 2004 21:27:38 -0400, Bradley K. Sherman wrote:

> In article <pan.2004.04.09.00.10.03.788129@acm.org>,
> Donald Roby <droby@acm.org> wrote:
>
>>>>>>>>>1) A must be either a B or a C
>>>>>>>>>2) a B might be a C
>>>>>>>>>
>>>>>>>>>And if A is a B which is a C, then (1) is violated.
>
>>I quite agree that the sentence ought to mean XOR. But the intent is
>>ambiguous because of common usage.
>
> Could you give me an example of common usage where (1) and (2)
> are not contradictory? A pretty weak constraint, just replace
> A,B,C with English nouns.
>
> --bks
I believe we're in the middle of a conversation where what the poster
intended to say is not what he actually said.

In another branch of this thread he has put nouns in and clarified his
intent, and it's clear he wasn't thinking of xor and thus shouldn't have
used the word "either".

However, (1) and (2) above are NOT in fact contradictory even in your
interpretation.

Draw a Venn diagram with B and C overlapping and A contained in the union
but not overlapping the intersection. I'd draw the picture, but I'm not
very good at ascii art.

bks@panix.com (Bradley K. Sherman) wrote in message news:<c552r5$65d$1@panix3.panix.com>...
> In article <cfcb68e.0404081829.13a6a9d@posting.google.com>,
> Michael Hartley <policymodel@hotmail.com> wrote:
> >> >>>>>>1) A must be either a B or a C
> >> >>>>>>2) a B might be a C
> >> >>>>>>
> >> >>>>>>And if A is a B which is a C, then (1) is violated.
>
> >Suppose a company has Employees (D), which include union members (B),
> >and confirmed employess (C) (and other types). Of course, union
> >members may be confirmed employees (and vice versa), but not
> >necessarily. They wish to set up a Staff club. Staff Club Members (A)
> >must be either Union Members or Confirmed Employees (of course they
> >may be both, if the employee happens to be a union member)
>
> Okay, then:
> (1b)Staff Club Members must be either Union Members or Confirmed Employees.
> (2b)A Union Member might be a Confirmed employee.
>
> Hmmm, better would be
>
> (1c)Staff Club Member may be either Union Members or Confirmed Employees
> or
> (1d)Staff Club Members must be either Union Members or Confirmed
> Employees or both.
>
> However, if we add either semantic gloss, statement (2b) is superfluous.
> or at least we need to add
> (3) a C might be a B
> or equivalent.
>
> I accept your clarification, but I think we are beginning to
> understand that an hour at the whiteboard can save a week
> in the cubicle, no?

*grin* That's a nice quote. I'm an educator. May I use it??


>
> --bks

How much should the identification of classes (different roles of employee is
identified as different classes here) be blamed for these un-resolved complexity in
relationship?

regards,
Shashank

"H. S. Lahman" wrote:

> Responding to Hartley...
>
> > Suppose I have the following situation :
> >
> > an A must be either a B or a C
> > a B might be a C (or vice-versa), but might not.
> > However, B's and C's are all D's.
> >
> > Is UML expressive enough to capture fully all the above information? If so, how??
>
> You can't get there from here, but the problem lies in the way the OO
> is-a relation is defined, not with UML. The problem is your second
> specification line.
>
> An OO is-a relation is essentially a Venn Diagram in tree form.
> Subclasses represent complete subsets of the superset. OO
> classification defines set participation based upon the collection of
> properties for those sets. So
>
> [A]
> A
> |
> +---------+-----------+
> | |
> [b] [C]
>
> is just fine for your first specification. The problem is that an OO
> superclass also represents the intersection of shared properties for all
> set members. That means [b] and [C] describe disjoint sets of
> properties. Therefore a B is always an A and a C is always an A but a B
> can never be a C.
>
> Similarly, your last specification could be described as:
>
> [A]
> A
> |
> +-------------+
> |
> [D]
> A
> |
> +--------+---------+
> | |
> [b] [C]
>
> Now all Bs and Cs are Ds and they are also As. The problem here is that
> [D] is superfluous. Because the union of subsets must be a complete set
> of [A] and there is no other direct subset of [A] than [D], that makes
> the [D] set identical to the [A] set.
>
> However, you can get close to what you want for the first and last
> specification using multiple is-a relations /IF/ the common properties
> reflect different sets of properties for [A] and [D]. Then one can have:
>
> +-- [b] --+
> | |
> | |
> [A] <|------+ +-----|> [D]
> | |
> | |
> +-- [C] --+
>
> where both [b] and [C] each belong to two different is-a relations, one
> for [A] and one for [D]. However, a B is still precluded from ever
> being a C.
>
> [Even this fails as indicated unless [A] and [D] are joint sets for the
> participants. That's because if both [A] and [D] have exactly the same
> subsets, there is no reason to separate them for reasons similar to
> those I used above for [D] inheriting from [A]. There is an excellent
> discussion of such exotica in Leon Starr's "Executable UML: How to Build
> Class Models", which IMO is the best book available on practical OO
> class modeling by a large margin.]
>
> So one can't express exactly what you want in traditional is-a
> relations. However, your second specification is actually fairly common
> with the most obvious example being roles. That is, an object has
> different behaviors in different execution contexts. This can be
> handled indirectly without [b] and [C] participating in the same is-a
> relation by separating the concerns of the role from the object itself.
> The best example of this is the GoF design pattern called State.
>
> [GoF refers to the Gang Of Four who wrote the classic "Design Patterns"
> book (Gamnma, Helm, Johnson, and Vlissides).]
>
> *************
> There is nothing wrong with me that could
> not be cured by a capful of Drano.
>
> H. S. Lahman
> hsl@pathfindermda.com
> Pathfinder Solutions -- Put MDA to Work
> http://www.pathfindermda.com
> (888)-OOA-PATH

How much should the identification of classes (different roles of employee is
identified as different classes here) be blamed for these un-resolved complexity in
relationship?

regards,
Shashank

"H. S. Lahman" wrote:

> Responding to Hartley...
>
> > Suppose I have the following situation :
> >
> > an A must be either a B or a C
> > a B might be a C (or vice-versa), but might not.
> > However, B's and C's are all D's.
> >
> > Is UML expressive enough to capture fully all the above information? If so, how??
>
> You can't get there from here, but the problem lies in the way the OO
> is-a relation is defined, not with UML. The problem is your second
> specification line.
>
> An OO is-a relation is essentially a Venn Diagram in tree form.
> Subclasses represent complete subsets of the superset. OO
> classification defines set participation based upon the collection of
> properties for those sets. So
>
> [A]
> A
> |
> +---------+-----------+
> | |
> [b] [C]
>
> is just fine for your first specification. The problem is that an OO
> superclass also represents the intersection of shared properties for all
> set members. That means [b] and [C] describe disjoint sets of
> properties. Therefore a B is always an A and a C is always an A but a B
> can never be a C.
>
> Similarly, your last specification could be described as:
>
> [A]
> A
> |
> +-------------+
> |
> [D]
> A
> |
> +--------+---------+
> | |
> [b] [C]
>
> Now all Bs and Cs are Ds and they are also As. The problem here is that
> [D] is superfluous. Because the union of subsets must be a complete set
> of [A] and there is no other direct subset of [A] than [D], that makes
> the [D] set identical to the [A] set.
>
> However, you can get close to what you want for the first and last
> specification using multiple is-a relations /IF/ the common properties
> reflect different sets of properties for [A] and [D]. Then one can have:
>
> +-- [b] --+
> | |
> | |
> [A] <|------+ +-----|> [D]
> | |
> | |
> +-- [C] --+
>
> where both [b] and [C] each belong to two different is-a relations, one
> for [A] and one for [D]. However, a B is still precluded from ever
> being a C.
>
> [Even this fails as indicated unless [A] and [D] are joint sets for the
> participants. That's because if both [A] and [D] have exactly the same
> subsets, there is no reason to separate them for reasons similar to
> those I used above for [D] inheriting from [A]. There is an excellent
> discussion of such exotica in Leon Starr's "Executable UML: How to Build
> Class Models", which IMO is the best book available on practical OO
> class modeling by a large margin.]
>
> So one can't express exactly what you want in traditional is-a
> relations. However, your second specification is actually fairly common
> with the most obvious example being roles. That is, an object has
> different behaviors in different execution contexts. This can be
> handled indirectly without [b] and [C] participating in the same is-a
> relation by separating the concerns of the role from the object itself.
> The best example of this is the GoF design pattern called State.
>
> [GoF refers to the Gang Of Four who wrote the classic "Design Patterns"
> book (Gamnma, Helm, Johnson, and Vlissides).]
>
> *************
> There is nothing wrong with me that could
> not be cured by a capful of Drano.
>
> H. S. Lahman
> hsl@pathfindermda.com
> Pathfinder Solutions -- Put MDA to Work
> http://www.pathfindermda.com
> (888)-OOA-PATH

Responding to Shashank...

> How much should the identification of classes (different roles of employee is
> identified as different classes here) be blamed for these un-resolved complexity in
> relationship?

You will have to put more words around this question. I can argue
either way: it is all about identifying classes properly or identifying
classes has nothing to do with it... B-)

>>>Suppose I have the following situation :
>>>
>>>an A must be either a B or a C
>>>a B might be a C (or vice-versa), but might not.
>>>However, B's and C's are all D's.

What is described here is multiple inheritance:

+----- [b] -------+
| |
[A] <|----+ +----|> [D]
| |
+----- [C] -------+

which is fine except for the specification that a [b] can sometimes be a
[C]. That's a no-no in OO subclassing because the members of the
subclasses must be disjoint sets of their superclass (in this case,
disjoint subsets of both [A] and [D]).

It is also a no-no simply because OO classes are defined around sets of
properties. So all members of a class /must/ have exactly the set of
properties defined for the class. Therefore it is impossible for only
some members of [b] to have particular properties that othre memebrs of
[b] do not have (unless there are additional levels of subclassing of
[b]). [Any intersecting subsets of properties common to both [b] and
[C] would be normalized into the superclass ([A] or [D]) and would,
therefore, be common to all members of both [b] and [C].]

So in the sense that the property sets for the classes have been
improperly extracted from a particular problem space, the problem is all
about identifying classes. In the sense it is about the way the OO
subclassing relation is defined, it doesn't have anything to do with
extracting specific classes from the problem space (i.e., one can't
describe the desired configuration directly in OO).


*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions -- Put MDA to Work
http://www.pathfindermda.com
(888)-OOA-PATH