UML Weekend Crash Course™ - To Parent Directory

Session 5—Understanding the Use Case Model 57
When one Use Case delegates to another, the dependency is drawn as a dashed arrow
from the “using” Use Case to the “used” Use Case and labeled with the stereotype
notation, as shown in figure 5-8. This conveys that executing the “using” (or calling)
Use Case will include or incorporate the functionality of the “used” Use Case. If you have a
programming background, you see right away the correlation with subroutine or function
calls.
Delegation may occur for one of two reasons. First, another Use Case may already exist to
perform the task that is needed. Second, a number of Use Cases may need to perform the
same task. Rather than write the same logic multiple times, the common task is isolated
into its own Use Case and reused by, or included into, each Use Case that needs it.
Customer
Withdraw Cash
Update Account
Withdraw Cash
with Overdraft
Protection
Protect Overdraft
Figure 5-8
dependency notation for the Use Case diagram
dependency notation
The dependency stereotype says that one Use Case might need help from
another Use Case. In contrast, the dependency stereotype says that one Use
Case will always call the other Use Case. Somewhere in the logic of the Use Case that needs
the help is an extension point, a condition test that determines whether or not the call
should be made. There is no such condition in an include dependency.
The other contrast between the two dependency stereotypes is the direction of the
dependency arrow. The dependency arrow points from the main Use Case (the
one currently executing) to the one that it needs help from. The dependency
arrow points from the extension Use Case (the one providing the extra help) to the main
Use Case that it is helping (see Figure 5-9).
If you read the basic definition of a dependency, the dependency arrow
seems to be backwards. That is one reason I often put an “s” on the end of these stereotypes.
For example, the Withdraw Cash Use Case Update Account (the
Withdraw Cash Use Case will always update the account). Likewise, the Protect Overdraft
Use Case Withdraw Cash (the Protect Overdraft Use Case will sometimes be
called by the Withdraw Cash Use Case).
The extend dependency can be confusing for Java programmers who use “extends” to
achieve inheritance. These two concepts have nothing in common. The UML provides a
separate notation for inheritance (or generalization).