> The <<uses>> and <<extends>> relationships possible between use cases have
> confused myself and some colleagues. We have tried to come up with a
> relatively simple explanation we can give to people and have arrived at the
> Think of <<uses>> as a delegation relationship. One use case must delegate
> work (use the services of) another use case to get its work done. Both use
> cases are still modular separate complete uses cases (describe a set of
> unique transactions between the use and the actor and has value to the
> actor) but one will delegate work to the other to accomplish its goals.
> e.g. "Place Order" will delegate work to "Order Product " and "Arrange
> Payment" to get its work done.
> The use case needs another use case to be fully functional and complete its
> task. It is saying that use case A will use use case B in the course of
> doing its work. <<Uses>> serves to modularize use cases and help pull out
> (dissect) it into smaller but real sets of useful transactions. By doing
> this you MAY derive reusable use cases that can be "used" by many other use
Dead right! You have a good technical description, but it may not be
accessable in that form to every beginner. I add a couple of other ideas
when I teach this stuff.
The fundamental difference between uses and extends is that the "using"
use case knows of the "used" use case, and decides when it wants it to
be followed. So if in a use case you can say "do this (other use case)
now", then the first uses the other.
Uses relationships generally are found by abstracting common behaviour
from use cases. For instance, in a teller machine you could model
Deposit and Withdraw use cases. After your first pass you will see that
both have stuff at the beginning about inserting the card and entering
the PIN. So you take the common stuff out and put it in a "Start
Transaction" use case that Deposit and Withdraw use to deliver a
valuable outcome to the Card Holder (actor). Deposit and Withdraw can't
work without Start Transaction, and as far as they are concerned Start
Transaction is a subroutine. (Flame Disclaimer: Please don't get hung up
on the validity of this model, it's just for illustration :)
Quote:> <<Extends>> is a "IS-A" relationship. It is specialization. The use case
> "return Video Late" IS-A "Return Video" - it is just a specialization of
> it. It would still inherit all the functionality from "Return Video" (it
> may add to and override the functionality) but it is a subclass of the
> generalized used case. The general rules of subclassing still apply here
> however. It must be a significant and complete use case to justify the
> specialization. Not all "if" and "when" situations that arise in the course
> of a use case will lead to specialized subclasses. Some may:
> a) Make no change to the flow at all (think of just a change in an
> algorithm) e.g. if you rent 4 videos you get the fifth free.
> b) May make a minor alternate flow (e.g. put up a dialog box for an error
> and abort).
> c) May really require a specialized subclass ("return Video Late") if we
> assume the flow is greatly changed if late.
Think about my idea of "uses" in terms of object inheritance - it sounds
like generalization but it is fundamentally different. Many people try
to explain relationships between use cases in terms of inheritance, but
the analogy doesn't hold. If it was that simple, Jacobson would have
done it that way in the first place. Use cases are not objects, they
don't have knowledge and behaviour, they just describes the behaviour of
the system where it meets the actors.
Please forget about explaining extension in terms of inheritance, and
try this - if a use case (A) is required to take control from another
(B), in other words A is looking over B's shoulder for the event that it
exists to handle, then A extends B. The crucial thing is that B doesn't
know that A exists, and has no idea that A can step in and take over.
For the teller machine, you need a Cancel use case that takes over from
Deposit, Withdraw, or Start Transaction, whenever the Card Holder
indicates that they don't want to proceed. As far as Deposit, etc. are
concerned, Cancel is like an interupt.
I further restrict my use of extends to situations in which you can't
predict when the triggering event will occur. The teller machine Cancel
conforms to this - you can't predict when the Card Holder will bail out.
I wouldn't extend Return Video to handle late returns because I know
exactly when, in the flow of Return Video, to apply a test to determine
if the return is late. I would describe that right there in the flow of
Return Video - "if late, charge the Renter for each day overdue". Use an
alternate flow if you have a lot of things to do when a return is late.
Quote:> Question 1: Does this make sense, does it explain the concepts of <<uses>>
> and <<extends>>, is it understandable?
Summary: Your description of <<uses>> is fine, but try thinking of
<<uses>> like subroutines - the user knows the used and when to use it.
Don't confuse people with descriptions of extension in terms of
inheritance - it is nothing like inheritance. Extension works like
interupts - the extender know which use cases to extend, and the event
that triggers its intervention.
Quote:> Question 2: So why does UML show both as generalization?
I wouldn't lose any sleep over this. UML does a lot of things by
stereotyping general mechanisms; that's its strength. I guess it just
made sense to reuse that arrow.
_--_|\ Alan Williams
NB: My "reply-to" is invalid to foil junk-mailers.
Use the above address.