UML Weekend Crash Course™ - To Parent Directory

66
Saturday Morning
For example, the problem statement tells you that the receiving and stocking jobs are
independent. Years ago they were, but now the staff unloads the trucks and places the products
into inventory right away. Although the tasks may remain distinct, there is no longer a
real distinction in the roles of the people doing the work. Perhaps the actor definitions
should be merged, as illustrated in Figure 6-4.
Receiving
Stock Clerk
Receiving
+
=
Figure 6-4
Merging two roles into one role
Step 6: Evaluate the Use Cases for dependencies
Apply the dependency stereotype between Use Cases when one Use Case
always calls on another Use Case to help it with a task that the calling Use Case cannot
handle. The included Use Case may already exist or it may recur in a number of Use Cases
and need to be isolated. For example, updating inventory is one of the requirements for
ShipOrder, StockProduct, and FillOrder. Figure 6-5 isolates the UpdateInventory requirement,
defining it once rather than three times, and calls on it from the original three
Use Cases.
Ship Order
Update
Inventory
Stock Product
Fill Order
Figure 6-5 dependencies from the problem statement
You can see right away that we place a high priority on reuse. Everything in a project
has the potential for reuse. Use Cases, classes, work flows, analysis procedures, work products,
analysis documents, design documents, and code make up only a short list of possible
reusable resources.
Step 7: Evaluate the Use Cases for dependencies
One Use Case may or may not use another Use Case depending upon a stated condition.
When the condition is met, the call is made to the other Use Case. When the condition is
not met, the call is not made.