Inheritance in class diagram
saad
I'm modelling a class diagram for the sales of a car, i have created a
class CAR, i have a compositon with the class CAR_FILE. I created also
a child class of the class car named CAR_FOR _SALE.
The question is : Do the child class CAR_FOR _SALE inherit from the
superclass CAR the composition relationship with CAR_FILE
Thanks
Timothy Marc
Of course they do. Navigable associations (whatever AggregationKind they
represent) result in properties of the navigable owned end at the other side
of the association. And attributes are inherited by subclasses (in case you
do not make use of VisibilityKind::private).
Timothy
> -----Ursprüngliche Nachricht-----
> Von: umlf...@googlegroups.com [mailto:umlf...@googlegroups.com]
> Im Auftrag von saad
> Gesendet: Sonntag, 11. März 2012 20:56
> An: UML Forum
> Betreff: [UML Forum] Inheritance in class diagram
> --
> You received this message because you are subscribed to the Google Groups
> "UML Forum" group.
> Public website: www.umlforum.com
> To post to this group, send email to umlf...@googlegroups.com To
> unsubscribe from this group, send email to
> umlforum+u...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/umlforum?hl=en?hl=en
H. S. Lahman
Yes, but "inherit" is probably not the best way to describe what is
going on. When you form the association with [Car], that says the
association applies to any member of the [Car] set. All members of
subclasses in a direct line of descent are members of the parent set, so
all members of any subclass of [Car] will be members of its set by
definition and, therefore, any relationship with [car] applies to them
as well.
However, I have two other concerns. One is with the class name Car_File.
That strongly suggests you are modeling a persistent data store. Such
stores are external to the application so they are usually seen only
through messages. (Even when the data store is complex, like an RDB, one
would usually isolate its access from the the rest of the problem
solution in a dedicated subsystem.) IOW, the problem solution doesn't
care whether the data store is flat files, and RDB, an OODB, or clay
tablets. There could be situations where this naming is valid, but they
are unusual enough to warrant a push-back.
The second problem is more serious. You have specified only one subclass
of [Car]. That's a no-no because of the underlying rules from set theory
as applied to OOA/D. There are three rules that are relevant to OOA/D:
(1) All members of a subclass are members of the parent class. This rule
applies to your inheritance issue. It is also the foundation of the OO
notion of is-a.
(2) The members of sibling subclasses are disjoint subsets of the parent
set (i.e., they do not share members).
(3) The union of all members of all sibling subclasses is an identity
set of the parent set (i.e., the parent set cannot have members that are
not members of some child subset).
The last rule is the problem in this case. If there is only one
subclass, then its members are identical to those of the parent set, so
it is superfluous.
There are poorly formed OOPLs, like C++, that allow one to instantiate
members of a superclass without identifying a subclass and this has led
to a lot of foot-shooting because that sort of thing can lead to serious
problems during maintenance. One can completely eliminate an entire
class of subtle errors if one follows rules (2) and (3) religiously. (If
you are curious, my book has a number of examples of how disobeying
these rules can lead to defects.)
--
Life is the only flaw in an otherwise perfect nonexistence
-- Schopenhauer
Rene Descartes went into a bar. The bartender asked if he would like a drink. Descartes said, "I think not," and disappeared.
H. S. Lahman
H.la...@verizon.net
software blog: http://pathfinderpeople.blogs.com/hslahman/index.html
Remy Fannader
distinction between actual (the car) and symbolic (car file, rent,
sale, etc) objects, as well as actual (between car and parts)and
symbolic (what a car knows of its parts and state) connectors.
On that basis it's possible to apply inheritance selectively to
instances and aspects.
http://caminao.wordpress.com/what-is-to-be-represented/
http://caminao.wordpress.com/about/objects-with-attitudes/
http://caminao.wordpress.com/about/sample-problems/sysml/
Remy.