UML notation question...

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??

Thanks!

BTW - the above email address is dead. Please reply to the group....

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

In article <H1Zbc.6311$V%3.980@nwrdny02.gnilink.net>,
H. S. Lahman <hsl@pathfindermda.com> 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).]

You're joking right? The specification is not susceptible
to logical analysis. It has nothing to do with OO or UML
or the price of tea. There is a paradox in the assertions.

--bks

On 4 Apr 2004 06:13:21 -0700, policymodel@hotmail.com (Michael
Hartley) wrote:

>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.

OK, lets make this a bit more concrete. A B is a class that has a 'b'
method. A C is a class that has a 'c' method. A D is a class that
has a 'd' method.

A class that has a 'b' and a 'd' method is a B and therefore could be
an A. A class that has a 'c' and a 'd' method is a C and therefore
could be an A. A class that has 'b', 'c', and 'd' is a B, a C, and
could also be an A.

I think you could write this in Smalltalk, Python, or Ruby.

>Is UML expressive enough to capture fully all the above information? If so, how??

|D|
|B| ^ |C|
^ 0..1 | ^ 0..1
| +------+-----+ |
| | | |
+---|C| |B|--+
^ ^
| |
+...{or}.....+
| |
+-----+------+
|
|A|

You could try this. I think it's legal, though I'm not convinced you
can use cardinality on inheritance relationships. If not, then you
could put constrains on them like the {or} constraint.



-----
Robert C. Martin (Uncle Bob)
Object Mentor Inc.
unclebob @ objectmentor . com
800-338-6716

"Distinguishing between the author
and the writing is the essence of civilized debate."
-- Daniel Parker

In article <6pn1701sjflfnevct35b6oga7gsqhr39e9@4ax.com>,
Robert C. Martin <u.n.c.l.e.b.o.b@objectmentor.com> wrote:
>On 4 Apr 2004 06:13:21 -0700, policymodel@hotmail.com (Michael
>Hartley) wrote:
>
>>Suppose I have the following situation :

>>
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.

--bks

On 5 Apr 2004 01:11:51 -0400, bks@panix.com (Bradley K. Sherman)
wrote:

>In article <6pn1701sjflfnevct35b6oga7gsqhr39e9@4ax.com>,
>Robert C. Martin <u.n.c.l.e.b.o.b@objectmentor.com> wrote:
>>On 4 Apr 2004 06:13:21 -0700, policymodel@hotmail.com (Michael
>>Hartley) wrote:
>>
>>>Suppose I have the following situation :
>
>>>
>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.

In a statically typed language, probably so (at least it's so in all
the statically typed languages I know). In a dynamically typed
language you have a few more options.


-----
Robert C. Martin (Uncle Bob)
Object Mentor Inc.
unclebob @ objectmentor . com
800-338-6716

"Distinguishing between the author
and the writing is the essence of civilized debate."
-- Daniel Parker

In article <53j27099o3m1bsd4gd3b0ii1mbucad21e7@4ax.com>,
Robert C. Martin <u.n.c.l.e.b.o.b@objectmentor.com> wrote:
>On 5 Apr 2004 01:11:51 -0400, bks@panix.com (Bradley K. Sherman)
>wrote:
>
>>In article <6pn1701sjflfnevct35b6oga7gsqhr39e9@4ax.com>,
>>Robert C. Martin <u.n.c.l.e.b.o.b@objectmentor.com> wrote:
>>>On 4 Apr 2004 06:13:21 -0700, policymodel@hotmail.com (Michael
>>>Hartley) wrote:
>>>
>>>>Suppose I have the following situation :
>>
>>>>
>>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.
>
>In a statically typed language, probably so (at least it's so in all
>the statically typed languages I know). In a dynamically typed
>language you have a few more options.

What about in English! Give an example from the real world.

--bks

On 5 Apr 2004 09:12:09 -0400, bks@panix.com (Bradley K. Sherman)
wrote:

>In article <53j27099o3m1bsd4gd3b0ii1mbucad21e7@4ax.com>,
>Robert C. Martin <u.n.c.l.e.b.o.b@objectmentor.com> wrote:
>>On 5 Apr 2004 01:11:51 -0400, bks@panix.com (Bradley K. Sherman)
>>wrote:
>>
>>>In article <6pn1701sjflfnevct35b6oga7gsqhr39e9@4ax.com>,
>>>Robert C. Martin <u.n.c.l.e.b.o.b@objectmentor.com> wrote:
>>>>On 4 Apr 2004 06:13:21 -0700, policymodel@hotmail.com (Michael
>>>>Hartley) wrote:
>>>>
>>>>>Suppose I have the following situation :
>>>
>>>>>
>>>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.
>>
>>In a statically typed language, probably so (at least it's so in all
>>the statically typed languages I know). In a dynamically typed
>>language you have a few more options.
>
>What about in English! Give an example from the real world.

Why? Software isn't English. The English definition if ISA (sic) is
not the same as the definition of ISA in OO. Indeed, I'm not sure
that there is a good definition of ISA in OO. The best I know of is
LSP, and that's not really the same thing.

I can create LSP compliant classes that meet the OP's constraints.


-----
Robert C. Martin (Uncle Bob)
Object Mentor Inc.
unclebob @ objectmentor . com
800-338-6716

"Distinguishing between the author
and the writing is the essence of civilized debate."
-- Daniel Parker

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.
>>>
>>>In a statically typed language, probably so (at least it's so in all
>>>the statically typed languages I know). In a dynamically typed
>>>language you have a few more options.
>>
>>What about in English! Give an example from the real world.
>
>Why? Software isn't English.

It becomes apparent why software engineering is still so pathetic.

Let me try one more time: If the specs make no sense, the
software is immaterial. And certainly UML is not going to
save the day. Unless UML is illogical, which I am prepared
to accept.

--bks

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.
>>>>
>>>>In a statically typed language, probably so (at least it's so in all
>>>>the statically typed languages I know). In a dynamically typed
>>>>language you have a few more options.
>>>
>>>What about in English! Give an example from the real world.
>>
>>Why? Software isn't English.
>
> It becomes apparent why software engineering is still so pathetic.
>
> Let me try one more time: If the specs make no sense, the software is
> immaterial. And certainly UML is not going to save the day. Unless UML
> is illogical, which I am prepared to accept.
>
> --bks

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.