Inheritance

A use case can inherit from another use case. However, use case A inheritting from use case B does not mean that use case A includes use case B. This is because use case B is not a component of use case A.

When use case A includes use case B, use case A can only specify exactly the same behavior as use case B. Use case A can, however, add behavior before o after use case B. In our earlier example, ``book flight ticket'' includes ``check flight information''. This means ``check flight information'' may include user log in before ``check flight information'' and include ``order ticket'' after ``check flight information''. Nonetheless, whatever behavior is specified in ``check flight information'' cannot be changed by ``book flight ticket''.

When use case A inherits from use case B, however, use case A can modify certain attributes of use case B, even to add new attributes and behavior. For example, ``check flight information'' may inherit from a use case called ``query flight data''. The ``query flight data'' use case is intended for experienced users who wish to use a more command-line oriented interface for efficiency. Airport code is manually entered (SFO, LAX, etc.) rather than selected from a drop-down box. The ``check flight information'' use case, on the other hand, is intended for end users who do not memorize airport codes. As a result, use case ``check flight information'' inherits everything from ``query flight data'', but it redefines some attributes and methods so it is more end user friendly.

An analogy may help to illustrate the differences between inheritance and inclusion. A fast-food meal includes a drink, an order of frys and a burger sandwitch. However, a cheeze-burger inherits from a burger sandwitch. In this case, a fast-food meal cannot change the attributes of the included burger sandwitch. However, a cheeze-burger can add a new attribute ``cheeze'' to a burger sandwitch.

Copyright © 2005-05-16 by Tak Auyeung