UML Weekend Crash Course™ - To Parent Directory

62
Saturday Morning
Order Fulfillment: Other staff members fill orders by locating the products required for
the order. As they fill the order they update inventory to reflect the fact that they have
taken the products. They also notify the Order Processing department that the order has
been filled. The clients want the new system to handle the notification to Order Processing.
Shipping: 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 after
they ship the product. They also notify the Order Processing department that the order has
shipped. The clients want the new system to handle the notification to Order Processing.
I don’t for a second want to give the impression that this is the only way to build Use
Case diagrams. But to get you started, I’m offering these steps as a guide. When you become
comfortable with the Use Case concepts, you’ll undoubtedly develop your own preferences
and write me a wonderful letter full of ideas on how I can improve this book. I thank you in
advance. For now, this should give you a solid start.
Step 1: Set the context of the target system
Context always comes first. Context provides the frame of reference for the information
you’re evaluating. Context defines the placement of the system within the business, including
the work processes, business plans and objectives, other systems, people and their job
duties, and constraints imposed by external entities like government and contractual
agreements.
According to the problem statement, the participants:
“. . . inform the Accounts Payable department”
“. . . notify the Order Processing department”
“. . . contact the shippers”
The context places the system within the warehouse operations, working closely with
Order Processing and Accounts Payable, and with shippers.
Tip
You can see also how establishing the context begs questions about the
scope (for example, where exactly is the boundary of responsibility between
Accounts Payable and Inventory Control).
Step 2: Identify the actors
Find the people, systems, or devices that communicate with the system. The system-type
actors are often easiest to spot as interfaces and external communication, such as notifications
to the Accounts Payable and Order Processing systems. The other actors will be participants
in the operation of the Inventory Control system. All these users will become your
sources for finding and validating the required features of the system (that is, Use Cases).
The problem statement referred to two system-type actors, shown in Figure 6-1:
“They inform the Accounts Payable department when the purchase order items have
been received.” The Accounts Payable System must know when the company has
incurred a liability for a shipment.