UML notation question...

[Shashank]

This is what I meant by identifying wrong classes as explained in the last few lines by
you. What I meant was that, if ever we get into situation like explained by you, wherein
we cannot capture exact relationship (in this case B and C are both A, but if B is also C
) it should be considered as modeling error which I consider yet not very much defined/
explored concept in UML.

And only way of correcting it may be identify the classes from domain again.

Or I missed something again?

regards,
Shashank


"H. S. Lahman" wrote:

> 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

[H. S. Lahman]

Responding to Shashank...

> This is what I meant by identifying wrong classes as explained in the last few lines by
> you. What I meant was that, if ever we get into situation like explained by you, wherein
> we cannot capture exact relationship (in this case B and C are both A, but if B is also C
> ) it should be considered as modeling error which I consider yet not very much defined/
> explored concept in UML.
>
> And only way of correcting it may be identify the classes from domain again.
>
> Or I missed something again?

No that's basically it; the problem space will have to be abstracted
differently.

One has a similar problem with basic OO object abstraction. One can't
directly abstract a characteristic like 'purpose' for an entity; instead
one must find some way of expressing it in terms of knowledge and/or
behavior characteristics. Such compromises are part of the price of
overlaying precise, unambiguous semantic models on problem spaces that
are defined with natural language and subjective perceptions.


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