Although the words inheritance and generalization sound abstract and
``object-oriented'', you can explain it to your client fairly easily.
To say that ``student generalizes CIS student'', it is the same as
saying ``every CIS student is also a student''. It is natural that
``a CIS student can do everything a student can''. The advantage of
having your client understand inheritance is that your client can
help you identify such relationships among actors.
With use cases, it is a little more difficult to identify inheritance.
You may need to perform the analysis without the help of your
client. On the other hand, sometimes your client may say ``to process
a store credit refund is a special case of a refund, with the
exception of ...''. This is a good clue that ``process refund''
is the generalization of ``process store credit refund''.
Since your client is unlikely to be an programmer/analyst familiar
with object-oriented programming or the UML, you need to look for
key phrases other than ``generalization'', ``specialization'',
``subclass'' and etc. Here is a short list of phrases that suggest
inheritance/generalization:
- ``A is a special case of B'': it suggests that A inherits from
B.
- ``A is similar to B, except that ...'': this is a tricky
one. It usually suggests that A inherits from B. However,
it can also indicate that both A and B are special cases of
a common source C. If the exception is that A has an additional
operation or property, A inherits from B. If the exception is
simply a difference, then A does not inherit from B, nor does
B inherit from A. It is the responsibility of the analyst to
create a common ancestor, C, that describes everything that
is common to A and B.
- ``A can do everything B can'': this suggests that A
inherits from B.
Copyright © 2005-05-16 by Tak Auyeung
