UML Weekend Crash Course™ - To Parent Directory

Session 5—Understanding the Use Case Model 51
Figure 5-2 Focus on the target, the goal of the process.
For example, in the case study, the Accounts Payable Department needs to be notified
when products have been received. For years this has meant that the paperwork for the
shipment was delivered to the warehouse supervisor who in turn delivered it to the
Accounts Payable Department. If you document this process as a requirement, you miss
the opportunity to automate the process and remove the physical problems and limitations
of hand delivering documents.
The Resources of the Use Case Model
The Use Case Model takes advantage of three different viewpoints to fully describe each
requirement. The first and simplest resource is the Use Case diagram. The Use Case narrative
and Use Case scenarios make up the remainder of the model.
Use Case diagram
The Use Case diagram consists of five very simple graphics that represent the system, actors,
Use Cases, associations, and dependencies of the project. The goal of the diagram is to provide
a high-level explanation of the relationship between the system and the outside world. It is a
very flat diagram (that is, it provides only a surface level, or black-box, view of the system).
The view represented by a Use Case diagram for an ATM application, for example, would
correspond to the main screen of an ATM and the menu options available at that level. The
ATM system offers the user a set of options such as withdraw, deposit, inquire on balance,
and transfer funds. Each option can be represented by a separate Use Case. The customer
(outside the system) is associated with each of the Use Cases (within the system) that he
plans to use.
Use Case narrative
On the Use Case diagram, a Use Case is simply an ellipse with a simple label like “Receive
Product.” Although this label may provide a meaningful interface, it doesn’t explain what
you can expect from this system feature. For that, you need a textual description. The Use
Case narrative provides a fairly standard (yet user-defined) set of information that is
required to guide the analysis, design, and coding of the feature.