Re: UML "OR" Composition Question

From: H. S. Lahman (h.lahman_at_verizon.net)
Date: 05/22/04 

Date: Fri, 21 May 2004 22:42:17 GMT

Responding to Rauscher...

>>> One X may be a Y or a Z or even a X.
>>
>>
>>
>> That implies that one can instantiate an X without specifying a
>> subclass. Though some misguided OOPLs like C++ allow that, it is a
>> no-no from an OOA/D viewpoint. One can only instantiate leaf subclass
>
>
> Do you have sources for this?

"Executable UML" by Mellor and Balcer in referring to the following (gp 97):

                        [Product]
                            A
                            |
           +----------------+---------------------+
           | | |
      [BookProduct] [SoftwareProduct] [RecordingProduct]

says, on pg. 98, "Each instance of a superclass must one and only one of
its superclasses, and each instance of a subclass must be an instance of
the superclass...Each Product must be one or the other of the subclasses."

 From "Executable UML: How to Build Class Models" by Leon Starr,
referring to the diagram on pg. 185:

                           [D]
                            A
                            |
               +------------+-----------+
               | | |
              [A] [B] [C]

on pg. 186, "Each superclass instance in D must have exactly one
corresponding instance in ONE of the subclasses (A, B, or C)." [BTW,
Starr's book is unquestionably the most comprehensive book of building
Class Diagrams available. Because he uses translation it is only about
OOA modeling, but it is still the best available.]

However, sources really aren't necessary. It is demonstrable directly
from the fact that the union of subclass members must be a complete set
of the superclass members.

If one can instantiate a superclass object alone it becomes what is
known in data modeling as a 'direct instance' of the superclass. The
definition of a direct instance is that it is not a member of any of the
subclasses. If it is not a member of any subclass, then the union of
subclass members is not a complete set of the superclass members. QED.

BTW, there are some older OO methodologies, such as OMT and Booch, that
did support direct instances of superclasses (i.e., did not require that
the union of subclasses form a complete set). The reason this has gone
out of favor is that it leads to an untenable problem for resolving
properties.

Suppose in the first diagram above there are direct instances of
Product. How does one identify that particular subset of Product
instances? The only way to define that subset is that it does NOT
contain members of BookProduct OR SoftwareProduct OR RecordingProduct.
IOW, the set definition is defined by a negative of other subset membership.

That presents two practical problems. One is the negative definition
that depends on other subset definitions, which will lead to convoluted
code (e.g., using dynamic_cast to test that it is none of the
subclasses). More important, though, is that it makes for fragile code.
  If one adds another subclass during maintenance that eats into the
original subset of direct instances, how does that affect existing
clients? That is, do they want NOT /any/ subclass or do they want just
NOT the original subclasses? IOW, the negative definition is now
ambiguous for any client of the original direct instances.

This can be manifested in a variety of ways, such as...

>
>> instances from a subclassing relation. That is, each instance must
>> completely resolve the entire tree; otherwise the properties of the
>> instance would be ambiguous.
>
>
> Not "otherwise". The ambiguity would be a result of the claim that each
> instance must completely resolve the entire tree. Otherwise :-) there
> aren't any ambiguities.

            1 hungers for 1
[Predator] --------------------- [Prey]
                                  + attacked()
                                     A
                                     |
                    +----------------+------------------+
                    | | |
               [Antelope] [Ostrich] [Brontosaurus]
               + run() + headInSand() + stomp()

Now in OOA/D there is a separation of message and method. So in UML one
can map the distinct run, headInSand, and stomp behaviors to the
attacked message. Which one do I get if only a Prey is instantiated and
it is sent an attacked message? At the OOA/D level that is indeterminate.

In OOPL land to remove the ambiguity a language like C++ must provide
its own additional rules, such as Prey must provide a concrete behavior
for attacked(). If Prey defines multiple properties, it has to provide
concrete implementations for all of them.

So, in effect, one is defining a complete, unique leaf subclass
implementation when one goes to the trouble of making Prey instantiable.
  Even the direct instance members form a disjoint subset from the other
subset members! And the union of that subset's members and the formal
subsets' members forms a complete set of the superclass members! IOW,
one has fully defined the subclass but has disguised it as a Prey while
complicating navigation to it.

If you have to do all that anyway, why not skip the obfuscation and just
create the subclass while avoiding the potential foot-shooting in the
NOT definition for direct instance subset membership?

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

Relevant Pages

  • Re: Help with design please
    ... entities from the problem space that are cohesive. ... disconnects in how the solution is viewed by different team members. ... >>relationships with the arrow on the superclass end. ... >>relationship the union of subclass members must be a complete set of the ...
    (comp.object)
  • Re: [General]acces of members of subclass
    ... public class Sub extends Super ... This has no difficulty - perfectly legal, with public members and all. ... variables can access only superclass members. ... member to overridden subclass functionality is a separate matter. ...
    (comp.lang.java.help)
  • Re: A hopefully interesting design question ...
    ... I will definitely look into the State Pattern ... AnswerBox: ... That is, members of OO ... it becomes obvious if one explicitly defines a subclass ...
    (comp.object)
  • Re: A hopefully interesting design question ...
    ... void RequestImputable; // from EditedAnswerBox ... AnswerBox: ... That is, members of OO ... it becomes obvious if one explicitly defines a subclass ...
    (comp.object)
  • Re: Some questions about inheritance
    ... This form of inheritance could be called "convenience inheritance". ... The subclass "is not a" superclass, but can use some of its implementation. ... Delegation is a technique for managing complexity by subdividing a class abstraction into multiple class abstractions that are related through associations of some sort. ...
    (comp.object)