UML Weekend Crash Course™ - To Parent Directory

Session 6—Building the Use Case Diagram 67
This example does not have a reason to use the stereotype. But suppose
that the users want the flexibility to add a product into inventory right off the truck,
without placing it into one of the predefined locations. In essence, they would bypass the
StockProduct Use Case. This bypass would only be used with manager-level authority. In this
situation, ReceiveProduct would only call the Update Inventory extension if the manager
approval were provided to do so. Figure 6-6 models the extend relationship.
Receive Product
Update Inventory
Figure 6-6 An example of dependency
Watch out for the direction of the arrows; it is easy to get them reversed. Read the
dependency in Figure 6-6 as “UpdateInventory extend(s) (is used with) ReceiveProduct if
the extension point condition is met in ReceiveProduct.”
Step 8: Evaluate the actors and Use Cases for generalization
In Session 5, you saw that generalization is a tool for organizing similarities and differences
among a set of objects (like actors or Use Cases) that share the same purpose. Review the
diagram for opportunities to apply the generalization concept.
The problem statement told us that, “The products may come from cancelled orders,
returned orders, or vendor shipments.” If the stocking rules are significantly different for
the various types of incoming stock, you could use generalization on the StockProduct Use
Case, as shown in Figure 6-7.
Stock Product
Stock New
Product
Stock Returned
Product
Stock Cancelled
Order Product
Figure 6-7 Using generalization to identify differences within a type of Use Case
Figure 6-7 shows that StockNewProduct inherits all the rules from StockProduct and
then adds some variations unique to stocking new products. The same is true for
StockReturnedProduct and StockCancelledOrderProduct.