UML Weekend Crash Course⢠- To Parent Directory
UML Weekend Crash Course⢠- To Parent Directory UML Weekend Crash Course⢠- To Parent Directory
Session 6—Building the Use Case Diagram 63 “They also notify the Order Processing department that the order has been filled.” “They also notify the Order Processing department that the order has shipped.” The Order Processing System needs to keep the customer informed of the status of its shipment. AccountsPayableSystem OrderProcessingSystem Figure 6-1 System-type actors from the problem statement From the problem statement, you also find four human actors (shown in Figure 6-2): “The receiving clerks receive incoming shipments by . . . .” People receive products into inventory. I refer to this role as Receiving. “The shipping folks contact the shippers to . . . .” The people who ship the product, retain shippers, pack the product, and complete the shipping documents are referred to as Shipping. “Other staff members fill orders . . . .” The people responsible for filling orders, whether for samples, customer orders, wholesale, or retail, are referred to as Order Fulfillment. “The stock clerk looks up . . . .” The people responsible for putting the products into inventory are referred to as Stock Clerk. Receiving Stock Clerk Shipping OrderFulfillment Figure 6-2 Human actors from the problem statement Tip It is no accident that the naming so closely parallels the user’s description of the system. Your abstractions should parallel the user’s vocabulary. After all, you and the user are both representing the same real-world concepts. Step 3: Identify the Use Cases Find the features or functionality that the system must provide by asking these and similar questions: What does the system produce for the actor This question helps identify work products that the system must support, known as the critical outputs.
64 Saturday Morning What does the actor help the system do This question helps us know the input facilities that the system needs to support, known as the critical inputs. What does the system help the actor(s) do This question helps identify the rules that must be applied when the actors use the system. The Use Cases identified in the problem statement text include: ReceiveProduct: “. . . receive incoming shipments . . . .” The goal is to record products into inventory, regardless of source. ShipOrder: “. . . they ship the product.” The goal is to record shipments and ensure that the products they contain have left the premises. StockProduct: “The products are placed in the warehouse in predefined locations.” The goal is to record that products have been placed into the designated locations within the inventory. FillOrder: “Other staff members fill orders . . . .” The goal is to allocate specific inventoried products exclusively to satisfy an order. LocateProduct: “The stock clerk looks up the correct location . . . .” “Other staff members fill orders by locating . . . .” The goal is to identify the location within the facility in which a specific product resides. Your definitions at this time probably won’t be final. A lot of information comes to light during the rigors of the analysis phase. But these preliminary definitions give you a lot of valuable research material to facilitate the analysis process. Step 4: Define the associations between actors and Use Cases Identify the actor(s) who need access to each Use Case/feature of the system. Each access relationship is a UML association. These associations are important because they tell you who the system stakeholders are (the people with a vested interest in the success of the system). For example, will the person at the order desk be able to do his job if he can’t see the status of an order As a stakeholder, what does he have to say about how the Use Case should work You’ll use that information in Session 7 when you write the Use Case narrative to explain what the stakeholders want the Use Case to do. Watch how the vocabulary of the problem statement helps you identify the associations (shown in Figure 6-3): An association between Receiving and ReceiveProduct. “The receiving clerks receive incoming shipments . . . .” An association between ReceiveProduct and AccountsPayableSystem. “They inform the Accounts Payable department when the purchase order items have been received. The clients want the new system to handle the notification automatically.” An association between Shipping and ShipOrder. “When the orders are filled, they are then packed and prepared for shipping. The shipping folks contact the shippers to arrange delivery. They then update inventory once they ship the product.”
- Page 36 and 37: SESSION 2 UML and Development Metho
- Page 38 and 39: Session 2—UML and Development Met
- Page 40 and 41: Session 2—UML and Development Met
- Page 42 and 43: Session 2—UML and Development Met
- Page 44 and 45: Session 2—UML and Development Met
- Page 46 and 47: SESSION 3 How to Approach the UML S
- Page 48 and 49: Session 3—How to Approach the UML
- Page 50 and 51: Session 3—How to Approach the UML
- Page 52 and 53: Session 3—How to Approach the UML
- Page 54 and 55: Session 3—How to Approach the UML
- Page 56: Session 3—How to Approach the UML
- Page 59 and 60: 36 Friday Evening Remember to pay c
- Page 61 and 62: 38 Friday Evening Constraints The s
- Page 63 and 64: 40 Friday Evening An Inventory Cont
- Page 65 and 66: 42 Friday Evening Performance How
- Page 67 and 68: 44 Friday Evening In the effort to
- Page 70 and 71: Part II — Saturday Morning Sessio
- Page 72 and 73: SESSION 5 Understanding the Use Cas
- Page 74 and 75: Session 5—Understanding the Use C
- Page 76 and 77: Session 5—Understanding the Use C
- Page 78 and 79: Session 5—Understanding the Use C
- Page 80 and 81: Session 5—Understanding the Use C
- Page 82: Session 5—Understanding the Use C
- Page 85: 62 Saturday Morning Order Fulfillme
- Page 89 and 90: 66 Saturday Morning For example, th
- Page 91 and 92: 68 Saturday Morning REVIEW The goal
- Page 93 and 94: 70 Saturday Morning Much of this la
- Page 95 and 96: 72 Saturday Morning You reply that
- Page 97 and 98: 74 Saturday Morning Writing a Use C
- Page 99 and 100: 76 Saturday Morning Use Case dialog
- Page 101 and 102: 78 Saturday Morning Table 7-7 The F
- Page 104 and 105: SESSION 8 Identifying the Use Case
- Page 106 and 107: Session 8—Identifying the Use Cas
- Page 108 and 109: Session 8—Identifying the Use Cas
- Page 110 and 111: Session 8—Identifying the Use Cas
- Page 112 and 113: Session 8—Identifying the Use Cas
- Page 114: Session 8—Identifying the Use Cas
- Page 117 and 118: 94 Saturday Morning The Class diagr
- Page 119 and 120: 96 Saturday Morning Attribute visib
- Page 121 and 122: 98 Saturday Morning In a modeling t
- Page 123 and 124: 100 Saturday Morning Table 9-2 Cont
- Page 125 and 126: 102 Saturday Morning Operation comp
- Page 128 and 129: SESSION 10 The Class Diagram: Assoc
- Page 130 and 131: Session 10—The Class Diagram: Ass
- Page 132 and 133: Session 10—The Class Diagram: Ass
- Page 134 and 135: Session 10—The Class Diagram: Ass
Session 6—Building the Use Case Diagram 63<br />
“They also notify the Order Processing department that the order has been filled.”<br />
“They also notify the Order Processing department that the order has shipped.” The<br />
Order Processing System needs to keep the customer informed of the status of its<br />
shipment.<br />
<br />
AccountsPayableSystem<br />
<br />
OrderProcessingSystem<br />
Figure 6-1 System-type actors from the problem statement<br />
From the problem statement, you also find four human actors (shown in Figure 6-2):<br />
“The receiving clerks receive incoming shipments by . . . .” People receive products<br />
into inventory. I refer to this role as Receiving.<br />
“The shipping folks contact the shippers to . . . .” The people who ship the product,<br />
retain shippers, pack the product, and complete the shipping documents are<br />
referred to as Shipping.<br />
“Other staff members fill orders . . . .” The people responsible for filling orders,<br />
whether for samples, customer orders, wholesale, or retail, are referred to as Order<br />
Fulfillment.<br />
“The stock clerk looks up . . . .” The people responsible for putting the products<br />
into inventory are referred to as Stock Clerk.<br />
Receiving Stock Clerk Shipping OrderFulfillment<br />
Figure 6-2<br />
Human actors from the problem statement<br />
Tip<br />
It is no accident that the naming so closely parallels the user’s description<br />
of the system. Your abstractions should parallel the user’s vocabulary. After<br />
all, you and the user are both representing the same real-world concepts.<br />
Step 3: Identify the Use Cases<br />
Find the features or functionality that the system must provide by asking these and similar<br />
questions:<br />
What does the system produce for the actor This question helps identify work<br />
products that the system must support, known as the critical outputs.
Change language