UML Use Cases uses vs. extends

UML Use Cases uses vs. extends

Post by Gerald Turnquis » Fri, 07 Feb 1997 04:00:00



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
following:

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
cases.

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

Question 1: Does this make sense, does it explain the concepts of <<uses>>
and <<extends>>, is it understandable?
Question 2: So why does UML show both as generalization?

Thanks for any comments.
Gerald Turnquist

 
 
 

UML Use Cases uses vs. extends

Post by Alan William » Sun, 09 Feb 1997 04:00:00



> 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
> following:

> 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
> cases.

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        
 /      \                          

       v                          
             NB: My "reply-to" is invalid to foil junk-mailers.
                 Use the above address.

 
 
 

UML Use Cases uses vs. extends

Post by martin.fowle » Wed, 12 Feb 1997 04:00:00




Quote:> 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
> [snip]

In my view, this is making use-cases a little too structured. They are not
a design approach, but a way of thinking about requirements.

Firstly if you don't find the uses/extends ideas useful then don't use
them. I've seen projects just collect use-cases, without these
relationships and they do fine.

If you do want to use them, I look at them in the following way.

Use <<uses>> when you find yourself writing the same piece of text in
several use cases. Its just a way of saying these use cases all do similar
things here.

Use <<extends>> when you want to show variation on a general theme,
typically in showing error conditions, or other special cases. That way you
can write the base use case without that clutter and still capture the
clutter in your requirements.

Use other relationships if you find them handy, but remember use cases are
an *external* view of the system, and the way you structure the software
does not need to have any relationship to the way you might structure the
use cases.

--
Martin Fowler
Independent Consultant

 
 
 

1. UML Stereotypes <<uses>> vs. <<creates>>

Hi, NG.

I am currently facing the problem in which case to use uml stereotype
<<uses>> or <<creates>>?
As explained in some literature resource, <<uses>> expresses that a class
uses another one in an implicit
manner, which means it does not necessarily creates that object e.g.
container classes. but instead only use
it.

<<creates>> should be used in cases where a class A creates an object of
class B explicitly? So do i have
to use the <<creates>> type in any cases where an instance is requested from
a Class A? Are there any cases
where the usage of  <<uses>> cover the instantiation without to express it
with <<creates>>. Summerized, what is
the exact semantic of the Stereotypes <<creates>> and <<uses>> ? I' m
appreciating any hints on this topic, thx.

best regards,

Binh Doan

2. Using SelectClipRgn with Windows Metafiles

3. UML association vs. <<using>> dependency

4. Replication and versioning

5. Use Case - Include vs. Extend

6. CyberChat // CyberChat // CyberChat // CyberChat // CyberChat

7. "own" vs "uses" vs "contains" vs "is a"

8. [reminder] pointer to Plan 9 FAQ

9. Using the Heap vs. Using VirtualAlloc

10. "using namespace std" vs. "using std::ostream" (FAQ 19.05)

11. using namespace std vs using std::...

12. Classes used in size vs. used in name only

13. What if a use case both includes and is extended by another use case?