UML WEEKEND CRASH COURSE phần 3 ppt

Saturday Morning56
Association notation
A line connecting an actor to a Use Case represents an association, as shown in Figure 5-7.
The association represents the fact that the actor communicates with the Use Case. In fact,
in earlier versions of the UML spec, this was called a Communicates With relationship. This
is the only relationship that exists between an actor and a Use Case. According to the UML
spec, you may specify a directionality arrow on either end of the association line to denote
the direction of the communication. Some associations are unidirectional (for example, the
actor specifies information to the Use Case). Most associations are bidirectional (that is, the
actor accesses the Use Case, and the Use Case provides functionality to the actor). For bidi-
rectional associations, you may either place an arrowhead on both ends of the association
line, or simply show no arrowheads at all. For simplification, most users tend to show no
arrowheads at all. Most modeling tools provide the option to turn bidirectional arrows on or
off. Just remember that the key is to identify which Use Cases the actors need to access.
These connections will form the basis for the interfaces of the system and subsequent mod-
eling efforts.
Figure 5-7 Association notation for the Use Case diagram
Stereotype notation
The stereotype notation is used throughout the UML, very commonly on Use Case depen-
dencies, classes, and packages and other elements of the UML known as classifiers. The
standard notation is to enclose the word in guillemets << >> (French quote marks), as in
the
<<include>>
notation below. Stereotypes provide a means to extend the UML without
modifying it. A stereotype functions as a qualifier on a model element, providing more
information about the role of the element without dictating its implementation.
<<include>> dependency notation
Sometimes one Use Case may need to ask for help from another Use Case. For example, Use
Cases titled Deposit Money and Withdraw Money may not actually update a bank account.
They may delegate the changes to an existing Use Case called Update Account so that
changes are controlled through a single feature that guarantees that all changes are done

correctly.
Withdraw Cash
Customer
Update Account
Withdraw Cash
with Overdraft
Protection
Protect Overdraft
114910-3 Ch05.F 5/31/02 2:04 PM Page 56
Session 5—Understanding the Use Case Model 57
When one Use Case delegates to another, the dependency is drawn as a dashed arrow
from the “using” Use Case to the “used” Use Case and labeled with the
<<include>>
stereo-
type notation, as shown in figure 5-8. This conveys that executing the “using” (or calling)
Use Case will include or incorporate the functionality of the “used” Use Case. If you have a
programming background, you see right away the correlation with subroutine or function
calls.
Delegation may occur for one of two reasons. First, another Use Case may already exist to
perform the task that is needed. Second, a number of Use Cases may need to perform the
same task. Rather than write the same logic multiple times, the common task is isolated
into its own Use Case and reused by, or included into, each Use Case that needs it.
Figure 5-8 <<include>> dependency notation for the Use Case diagram
<<extend>> dependency notation
The
<<extend>>
dependency stereotype says that one Use Case might need help from
another Use Case. In contrast, the
<<include>>
dependency stereotype says that one Use

Case will always call the other Use Case. Somewhere in the logic of the Use Case that needs
the help is an extension point, a condition test that determines whether or not the call
should be made. There is no such condition in an include dependency.
The other contrast between the two dependency stereotypes is the direction of the
dependency arrow. The
<<include>>
dependency arrow points from the main Use Case (the
one currently executing) to the one that it needs help from. The
<<extend>>
dependency
arrow points from the extension Use Case (the one providing the extra help) to the main
Use Case that it is helping (see Figure 5-9).
If you read the basic definition of a dependency, the
<<extend>>
dependency arrow
seems to be backwards. That is one reason I often put an “s” on the end of these stereo-
types. For example, the Withdraw Cash Use Case
<<includes>>
Update Account (the
Withdraw Cash Use Case will always update the account). Likewise, the Protect Overdraft
Use Case
<<extends>>
Withdraw Cash (the Protect Overdraft Use Case will sometimes be
called by the Withdraw Cash Use Case).
The extend dependency can be confusing for Java programmers who use “extends” to
achieve inheritance. These two concepts have nothing in common. The UML provides a
separate notation for inheritance (or generalization).
Withdraw Cash
Customer
<<include>>

Update Account
Withdraw Cash
with Overdraft
Protection
Protect Overdraft
114910-3 Ch05.F 5/31/02 2:04 PM Page 57
Saturday Morning58
Figure 5-9 <<extend>> dependency notation for the Use Case diagram
Generalization
Inheritance is a key concept in object-oriented programming, and OO analysis and design.
Inheritance tells us that one object has, at the time of its creation, access to all the proper-
ties of another class, besides its own class. Thus, the created object incorporates all those
properties into its own definition. In layman’s terms, we say things like, “A Ford Explorer is
a car.” A car is a well-defined general concept. When you create a Ford Explorer, rather than
redefine all the car properties, you simply “inherit” or assimilate all the existing car proper-
ties, then override and/or add any new properties to complete the definition of your new
Ford Explorer object.
The same idea, applied to actors and to Use Cases, is called generalization, and often goes
by the nickname, an “is a” relationship. A Senior Bank Teller is a Bank Teller with additional
authority and responsibilities. The “Withdraw Cash with Overdraft Protection” Use Case is a
more extensive requirement than the “Withdraw Cash” Use Case.
To model generalization, the UML uses a solid line with a hollow triangle. It looks a bit
like an arrow, but be careful not to confuse the two. The triangle is always on the end near
the item that is being inherited. In the examples mentioned earlier, the triangle would be
near “Bank Teller” and “Withdraw Cash,” as shown in Figure 5-10.
Figure 5-10 Generalization notation for the Use Case diagram
Withdraw Cash
Customer
<<include>>
<<extend>>

Update Account
Withdraw Cash
with Overdraft
Protection
Protect Overdraft
Withdraw Cash
Customer
<<include>>
<<extend>>
Update Account
Withdraw Cash
with Overdraft
Protection
Protect Overdraft
114910-3 Ch05.F 5/31/02 2:05 PM Page 58
Session 5—Understanding the Use Case Model 59
REVIEW
The Use Case model comprises a set of resources aimed at defining the goals of a system. The
concept came from the work of Ivar Jacobson on a methodology called Objectory. The pur-
pose of the model is to focus the development effort on the essential objectives of the system
without getting lost in or driven by particular implementations or practices.
¼
The Use Case model consists of three primary resources: the Use Case diagram, the
Use Case narrative, and Use Case scenarios.
¼
The Use Case diagram uses a system icon to define the boundaries of the system.
¼
Actors define entities outside the system that will use the system in some way.
¼
Associations indicate which actors will access which features (Use Cases) of the

system.
¼
Dependencies describe the nature of the relationships between Use Cases.
¼
Generalization is used to illustrate inheritance relationships between Use Cases and
between actors.
QUIZ YOURSELF
1. What is the relationship between people and roles in a Use Case diagram? (See
“Use Case actors.”)
2. Where do you use associations in a Use Case diagram? (See “Association notation.”)
3. Why would you use the dependency stereotype
<<include>>
? (See “<<include>>
dependency notation.”)
4. When would you use the
<<extends>>
dependency stereotype? (See “<<extend>>
dependency notation.”)
5. Where can you use the generalization relationship on a Use Case diagram? (See
“Generalization.”)
114910-3 Ch05.F 5/31/02 2:05 PM Page 59
114910-3 Ch05.F 5/31/02 2:05 PM Page 60
Session Checklist
✔
Understanding the steps used to build a Use Case diagram
✔
Building the Use Case diagram for the case study
S
ession 5 introduced the notation for the Use Case diagram. In this session, you find
out how to build a Use Case diagram by concentrating on the case study.

Building the Use Case Diagram for the Case Study
The following text makes up the description of the case study. I refer to this as the problem
statement. Use this problem statement as your source for the information needed to build
the Use Case diagram.
You will see the problem statement change from session to session. This is
necessary within the book because I need to tailor the problem so that you
will have an opportunity to use as many of the new concepts as possible in
each session.
Receiving: The receiving clerks receive incoming shipments by matching purchase orders
against the stock in the shipment. 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.
Stocking: The products may come from cancelled orders, returned orders, or vendor ship-
ments. The products are placed in the warehouse in predefined locations. The stock clerk looks
up the correct location for the new products, places the products in that location, and updates
the location inventory with the product quantity.
Note
SESSION
Building the Use Case Diagram
6
124910-3 Ch06.F 5/31/02 2:05 PM Page 61
Saturday Morning62
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, includ-
ing 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.
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 notifica-
tions to the Accounts Payable and Order Processing systems. The other actors will be partici-
pants 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.
Tip
124910-3 Ch06.F 5/31/02 2:05 PM Page 62
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.
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.
Figure 6-2 Human actors from the problem statement
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.
Tip
Receiving Stock Clerk Shipping OrderFulfillment
<<Actor>>
AccountsPayableSystem
<<Actor>>
OrderProcessingSystem
124910-3 Ch06.F 5/31/02 2:05 PM Page 63
Saturday Morning64
¼
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.”
124910-3 Ch06.F 5/31/02 2:05 PM Page 64
Session 6—Building the Use Case Diagram 65
¼
An association between ShipOrder and OrderProcessingSystem. “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.”
¼
An association between StockClerk and Stock Product. “The stock clerk looks up
the correct location for the new products, places the products in that location, and
updates the location inventory with the product quantity.”
¼
An association between FillOrder and OrderProcessingSystem. “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.”
¼
An association between OrderFulfillment and LocateProduct. “Other staff members
fill orders by locating the products required for the order.”
Figure 6-3 Associations from the problem statement
Step 5: Evaluate the actors and Use Cases to find opportunities for refinement
Rename, merge, and split actors and Use Cases as needed. When you build your diagrams
based on interviews with users, it is easy to fall into the trap of replicating the current
system (see Session 4). From your first draft of the descriptions of the actors and Use
Cases, start asking critical questions, especially the simple but powerful question, “Why?”
For example, ask, “Why is this actor responsible for these particular duties?” or “Why do

these tasks have to be done together, separately, in this order, or done at all?” A system
rewrite or major revision provides a great opportunity to clean house and address a lot of
the legacy problems that have accumulated over time.
Receiving
ReceiveProduct
<<Actor>>
AccountsPayableSystem
Shipping
Stock Clerk OrderFulfillment
ShipOrder
FillOrder
StockProduct LocateProduct
<<Actor>>
OrderProcessingSystem
124910-3 Ch06.F 5/31/02 2:05 PM Page 65
Saturday Morning66
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 prod-
ucts 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.
Figure 6-4 Merging two roles into one role
Step 6: Evaluate the Use Cases for <<include>> dependencies
Apply the
<<include>>
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 require-

ment, defining it once rather than three times, and calls on it from the original three
Use Cases.
Figure 6-5 <<include>> 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 prod-
ucts, analysis documents, design documents, and code make up only a short list of possible
reusable resources.
Step 7: Evaluate the Use Cases for <<extend>> 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.
Ship Order
<<include>>
<<include>> <<include>>
Stock Product Fill Order
Update
Inventory
Receiving Receiving
=+
Stock Clerk
124910-3 Ch06.F 5/31/02 2:05 PM Page 66
Session 6—Building the Use Case Diagram 67
This example does not have a reason to use the
<<extend>>
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.

Figure 6-6 An example of <<extend>> 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.
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.
Stock Product
Stock New
Product
Stock Returned
Product
Stock Cancelled
Order Product
Receive Product Update Inventory
<<extend>>
124910-3 Ch06.F 5/31/02 2:05 PM Page 67
Saturday Morning68
REVIEW
The goal of the Use Case diagram is to define the expectations of the users. Those users may
be people, systems, or devices that need to interact with the system. Their interactions may

be to provide input, to receive output, or to dialog with the system in order to cooperate in
the completion of a task. All these interactions are focused through a set of specific features
of the system called Use Cases. Each Use Case defines one specific goal that the system can
achieve.
The construction of a Use Case diagram requires the following steps:
1. Identifying the context of the system
2. Identifying the actors and their responsibilities
3. Identifying the Use Cases, the features of the system, in terms of specific goals
4. Evaluating the actors and Use Cases to find opportunities for refinement
5. Evaluating the Use Cases to find
<<include>>
type dependencies
6. Evaluating the Use Cases to find
<<extend>>
type dependency
7. Evaluating the actors and Use Cases for generalization (shared properties)
QUIZ YOURSELF
1. What is an actor? (See “Step 2: Identify the actors.”)
2. How do you identify a Use Case? (See “Step 3: Identify the Use Cases.”)
3. What is the notation for an
<<include>>
dependency? (See “Step 6: Evaluate the
Use Cases for <<include>> dependencies.”)
4. What is another name for a Use Case? (See “Step 3: Identify the Use Cases.”)
5. What does it mean when you place the
<<extend>>
stereotype on a dependency?
(See “Step 7: Evaluate the Use Cases for
<<extend>>
dependencies.”)

124910-3 Ch06.F 5/31/02 2:05 PM Page 68
Session Checklist
✔
Explaining the purpose of a Use Case narrative
✔
Explaining the elements of a typical Use Case narrative
✔
Writing a Use Case narrative for the case study
A
lthough the Use Case diagram provides a convenient view of the main features of a
system, it is too concise to completely describe what users are expecting. So, as with
most diagrams, it must be supported by a narrative, a textual description that takes
us to the next level of understanding.
There are many ways to write Use Case descriptions. Typically, each methodology will have
its own set of elements and preferences. What I offer here is a set of common elements that
you will find in most methodologies.
Elements of a Use Case Narrative
Describing a Use Case requires that you frame the context of the Use Case and describe the
communication between the Use Case and the user, which could be an actor or another Use
Case. With this in mind, most Use Case narratives include the following elements, or others
very similar in meaning:
¼
Assumptions
¼
Pre-conditions
¼
Use Case initiation
¼
Process or dialog
¼

Use Case termination
¼
Post-conditions
SESSION
Building the Use Case Narrative
7
134910-3 ch07.F 5/31/02 2:05 PM Page 69
Saturday Morning70
Much of this language is borrowed from the “programming by contract” concept, developed
and implemented by Bertrand Meyer in the creation of the Eiffel programming language. One
chief goal of the programming by contract concept is to define each unit as autonomous,
whether the unit is an object or a Use Case. Each unit should remain as independent from
others as possible, also referred to as being loosely coupled. Unit independence allows each
unit to be maintained without requiring corresponding changes in other units. This reduces
the cost of development and maintenance of the system.
Assumptions
Typically, developers think of assumptions as bad, something to be avoided. Here, I’m apply-
ing the concept in a positive way. In order for the Use Case to work properly, certain condi-
tions must be true within the system.
You agree, or you contract, never to invoke this Use Case unless you know that all the
needed conditions have been met. In other words, assumptions describe a state of the sys-
tem that must be true before you can use the Use Case. These conditions are not tested by
the Use Case (contrast this later with the pre-conditions). For example, consider the tasks
of performing authentication and authorization. A standard security check feature typically
handles these functions. Each subsequent Use Case assumes that the user could not access
the Use Case had he not made it past the security check. Consequently, you would rarely if
ever include the security check in each Use Case.
So how does this help you with the design of the system? If one Use Case can’t work and
should not even be accessed unless another Use Case has first done its job, this condition
dictates the order of execution. The assumptions give you explicit clues about the sequence

of execution for Use Cases (that is, the workflow).
Place common Use Case assumptions into a system-level document instead
of including them in every Use Case narrative.
Pre-conditions
Pre-conditions are easily confused with assumptions. Like assumptions, pre-conditions
describe a state of the system that must be true before you can use the Use Case. But unlike
assumptions, these conditions are tested by the Use Case before doing anything else. If the
conditions are not true, the actor is refused entry.
Most programmers have coded pre-conditions nearly every time they write a method or
subroutine call that has parameters. When you write code, what are the first lines of code
that you write in a function or method that has parameters? You validate the parameters.
You test to make certain that the conditions are right to proceed with the rest of the code.
Failure in these tests would mean problems for the subsequent code, so the call is refused
and turned back to the requester. You established and tested the pre-conditions for execu-
tion of your method or function.
These rules or pre-conditions need to be published along with the interface to your Use
Case. For example, a typical interface can only tell the client to provide two integer values
and a character string. It can’t tell them the rules that say that the first integer must be a
Tip
134910-3 ch07.F 5/31/02 2:05 PM Page 70
Session 7—Building the Use Case Narrative 71
value between 1 and 10, the second must be an integer greater than 100, and the character
string can only be 30 characters in length. Without publishing these pre-conditions, anyone
who wants to use your Use Case is forced into relying on trial and error to find the correct
set of values.
Notice how rapidly we bring precision to the model from the simple beginnings
of the Use Case diagram. You’ll find the analysis process akin to pulling a
thread on an old sweater. If you keep pulling, eventually you’ll unravel the
whole complex problem (while your mother yells at you for destroying a per-
fectly good sweater). Using simple checklists to remind you of the questions

to ask can expedite the process and build a successful pattern of thought for
problem solving. As you gain experience, modify the list of questions and tasks
to improve the process and to make it your own.
The goal is not to become a disciple of a particular technique, but to find a
technique that works for you.
Use Case initiation
A Use Case has to start somehow, but how? Some Use Cases start because an actor says,
“Start.” For example, you can select an option on a menu. The action tells the system to
open the application. Time can also trigger a Use Case. Most software shops have scheduling
software that kicks off programs at a preset time. Other Use Cases are implemented as objects
themselves that watch for a point in time. A Use Case may be triggered by a system event
like an error condition, a lost connection, or a signal from a device.
Use Case initiation provides a place to think through all the possible triggers that could
launch the Use Case. This is critical when you start thinking about reusing Use Cases. If five
actors and/or Use Cases plan on using the same Use Case, then you need to know how each
user plans to kick it off. If each has different expectations, then you could be creating a
problem. Multiple triggering mechanisms lead to high coupling and low independence. In
other words, every time you change one of the triggers, you need to change the correspond-
ing Use Case and make certain that you haven’t created problems with the other triggering
mechanisms. More triggers mean more complicated and costly maintenance.
Dialog
The dialog refers to a step-by-step description of the conversation between the Use Case
(the system) and the user (an actor or another Use Case). Very often, it is helpful to model
this sequence of events using an Activity diagram just as you might model a procedure for
communication between two business units.
For example, you want to withdraw money, so you access the ATM at your local bank. The
following dialog ensues:
You get past the security check Use Case, and you’re presented with a menu of options.
You choose “Withdraw.”
The system immediately asks you which account you want to withdraw the money

from.
Tip
134910-3 ch07.F 5/31/02 2:05 PM Page 71
Saturday Morning72
You reply that you want to withdraw from your primary checking account.
The system then asks you how much you want to withdraw.
You say that you want $47.
The system gives you a nasty error message saying it can’t handle that number
(because it’s not a multiple of 20) and you need to try again.
Then you say you want $4,700.
The system again complains that you can’t take that much money out in a 48-hour
period.
“Okay, okay! Give me $100,” you tell the system.
Now the system is happy and it gives you the money and a receipt.
When goals remain separate from implementation, you can evolve systems whose interface
designs remain stable while their implementations take advantage of ever-improving user
interface technologies. This conversation could just as easily have happened with any manu-
facturer’s ATM even if it held different cash denominations (10’s versus 20’s), connected
directly to a bank, or connected via a nationwide network. Also, you begin to see that some
of the steps don’t necessarily have to happen in the sequence presented here. The goal of the
dialog is to uncover just what really needs to happen and what variations could be valid.
Even ATM interface designs vary. Have you ever seen an ATM designed for blind people?
It performs the exact same conversation but with a different user interface. My home bank-
ing software accomplishes essentially the same function, too, but with still a different
design for the interface. The system asks all the questions at once and I provide all the
answers at once. Same design, different interface.
Use Case termination
Although there is usually only one triggering event to start a Use Case, there are often
many ways to end one. You can pretty much count on some kind of normal termination
where everything goes as planned and you get the result you anticipated. But things do go

wrong. This could mean shutting down the Use Case with an error message, rolling back a
transaction, or simply canceling. Each termination mechanism has to be addressed in the
dialog.
The list of termination options is a bit redundant with the dialog, but just as was the
case with pre-conditions, this redundancy provides some good checks and balances.
Post-conditions
Post-conditions describe a state of the system that must be true when the Use Case ends. You
may never know what comes after the Use Case terminates, so you must guarantee that the
system is in a stable state when it does end. In fact, some people use the term guarantee for
just this reason. You guarantee certain things to be true when this Use Case completes its
job. You might, for instance, guarantee to give the user a receipt at the end of the trans-
action, whether it succeeded or failed. You might promise to notify the user of the result
of an attempted save to the database.
134910-3 ch07.F 5/31/02 2:05 PM Page 72
Session 7—Building the Use Case Narrative 73
You may have noticed that some of the post-conditions above, such as giving the user a
receipt at the end of the transaction, were already in the Use Case dialog and seem redun-
dant. This may be true, but separating out post-conditions has proven to be an excellent
check-and-balance mechanism. The added visibility has also proven to be very helpful in
reviews with clients who want to know immediately what the system will do.
Additional narrative elements
The narrative doesn’t have to stop with just these elements. Some other common elements
include future enhancements, unresolved issues, performance constraints, security require-
ments, shareholders, maintenance logs, and notes. And I’m certain that your compatriots
can suggest more.
Workflow Requirements
A common question about Use Cases is “How do I show workflow or screen
flow?” The short answer is that you don’t. A more appropriate question would
be, “How do I use the Use Case model to determine screen flow and workflow
requirements?”

Workflow is often a difficult problem in system design. Personal opinion, per-
sonal preferences, and legacy workflows often get included as requirements.
Remember the ham story from Session 5? Just like the cooks in the ham story,
business practices are prone to faulty assumptions and unquestioned repetition.
New systems often contain the same deficiencies that old ones had because
they were not critically evaluated in the light of genuine requirements analysis.
To determine workflow requirements with Use Cases, first check out the pre-
conditions and assumptions. If Use Case A requires the user to provide data
that is obtained by Use Case B, or do something that Use Case B is responsible
for, then logically Use Case B must come first.
These clues are a tremendous help when you recognize that many workflows
were designed based on user preferences or experience. Because of this
approach, they have not been checked against the rules and constraints that
define the successful operation of the system. Here you have one means to do
this verification.
Quite often, screen flow and workflows are far more flexible than you might
think. Let the Use Case assumptions and pre-conditions tell you what the flow
options are. Then design the workflows that are possible, letting the users
decide what works best for them.
134910-3 ch07.F 5/31/02 2:05 PM Page 73
Saturday Morning74
Writing a Use Case Narrative for the Case Study
To practice writing a narrative, you will use the Use Case Fill Order in the case study Use
Case diagram from Session 6 presented in Figure 7-1. Given the description in the next
paragraph, you can draft a narrative for the FillOrder Use Case. Use the narrative elements
discussed earlier as a guide for organizing the narrative.
(From Session 6:)
FillOrder: This is basically your reason for being in business. Authorized personnel take
Product from inventory according to the order specifications. They update the order and the
inventory. If there are any items that can’t be filled, they create a backorder.

Figure 7-1 Use Case diagram from Session 6
The following section explains each of the fields of the narrative. The narrative begins in
Table 7-1 with four common audit fields to track the narrative document: the name of the
Use Case, a unique number (in case you need to change the name), the author of the narra-
tive, and the last time it was updated. You typically want to keep track of who is changing
the document, what they have changed, and when they changed it, to make certain that
everyone is aware of the latest revisions and to prevent confusion and unnecessary delays
due to misunderstandings.
Table 7-1 The Fill Order Use Case Narrative: Audit Fields
Field Name Field Description
Name Fill Order
Number 11
Author Tom Pender
Last update 12/23/01
Your diagrams and documents will go through a lot of changes. Change
control software is a very worthwhile investment.
Tip
Ship Order
<<include>>
<<include>> <<include>>
Stock Product Fill Order
Update
Inventory
134910-3 ch07.F 5/31/02 2:05 PM Page 74
Session 7—Building the Use Case Narrative 75
Assumptions in the case study narrative
The FillOrder description says that only “authorized personnel” will use this Use Case. You
could check security in this Use Case. But that approach leads to redundancy and the result-
ing high cost of maintenance. Instead you establish the assumption that security will be
handled by another function, ValidateAccess. Furthermore, you’ll trust that the security

check was done correctly (see Table 7-2).
So what does that tell you about the relationship between the FillOrder and ValidateAccess
Use Cases? It tells you the precedence. ValidateAccess must precede FillOrder in the workflow.
Table 7-2 The Fill Order Use Case Narrative: Assumptions
Field Name Field Description
Assumptions Valid user and has permission to use this feature
Pre-conditions in the case study narrative
Next, you establish the pre-conditions, the conditions that you will test to be sure that it’s
okay to proceed with the Use Case dialog. The Fill Order description said that the personnel
“take Product from inventory according to the order specifications.” That implies that they
need to tell the system the Order that they plan to fill. Refer to the Pre-conditions row in
Table 7-3. If the actor doesn’t provide a valid order number, there isn’t much you can do for
him. If you look ahead to the dialog in Table 7-5, you’ll see that the first few steps ask for
the order number, get the order number, and try to find the order. Pre-conditions are always
the first things tested in the dialog.
Table 7-3 The Fill Order Use Case Narrative: Pre-conditions
Field Name Field Description
Pre-conditions Provide a valid order number
Use Case initiation in the case study narrative
Next, referring to the Use Case initiation row in Table 7-4, you describe how the Use Case
dialog is started. In this case, the actor simply asks to start the dialog, so you say that it’s
initiated on demand.
Table 7-4 The Fill Order Use Case Narrative: Initiation
Field Name Field Description
Use Case initiation This Use Case starts on demand
134910-3 ch07.F 5/31/02 2:05 PM Page 75
Saturday Morning76
Use Case dialog in the case study narrative
Next, you describe the dialog between the actor and the Use Case (see Table 7-5). You see
each action required by the actor and each response from the system. Some responses require

a choice based on the progress so far, so you see the decision statements included in the dia-
log. This way, you know why the system gave the response it did. Other decision points are
the result of an action, like attempting to find the order using the Find Order Use Case.
Table 7-5 The Fill Order Use Case Narrative: Dialog
Field Name Field Description
Use Case dialog The system asks the user for an order number
The user provides the order number
The system asks for the order (from FindOrder Use Case).
If the Order is not found, Error, stop
Else:
The system provides the order to the user
The user chooses an item
Until the user indicates that he is done or there are no unfilled
item quantities greater than 0:
The system asks for the location of the item and
unfilled quantity (from the LocateProduct Use Case)
If the item is found (available):
The user indicates the quantity of the item filled
If there are any unfilled item quantities greater than 0:
Create a backorder (using the CreateBackorder Use Case)
Based on the Use Case dialog, see if you can find an error or something missing from the
Use Case diagram in Figure 7-1. Very often, taking a closer look at one aspect of the problem
(like the narrative) will reveal new insights to update existing diagrams. This is a normal and
desirable part of the modeling process.
134910-3 ch07.F 5/31/02 2:05 PM Page 76
Session 7—Building the Use Case Narrative 77
Did you find the error in the Use Case diagram? In Table 7-5, the dialog said, “The system
asks for the location of the item and unfilled quantity (from the LocateProduct Use Case).”
You need to add an
<<include>>

dependency from the FillOrder Use Case to the
LocateProduct Use Case.
Use Case termination in the case study narrative
In the termination row in Table 7-6, you list all the ways that this Use Case could end. Use
Cases are not good at showing concurrency and interrupts, so this is often the only place to
identify things such as a cancel event and timeouts. You’ll need to use the Activity diagram
or even the Sequence diagram a bit later to flesh out the concurrency and interrupt require-
ments. The termination section also provides you with a list of actions to consider when
writing the post-conditions.
No one diagram can show everything. This is why it is so important to under-
stand the purpose and features of each diagram. The diagrams are like tools
in a toolbox. You have to know which one to use for each task.
Most business applications like FillOrder will let you cancel the session at specific points
in the process. It is also usually wise to handle the condition where a user gets interrupted
and leaves a session open. The timeout termination could watch for a specified period of
inactivity before closing the transaction. And of course the user can actually complete the
process of filling the order or simply indicate that he is done.
Table 7-6 The Fill Order Use Case Narrative: Termination
Field Name Field Description
Use Case termination The user may cancel
The Use Case may timeout
The user can indicate that he is done
The user can fill all items on the Order
Post-conditions in the case study narrative
Finally, in the Post-conditions row in Table 7-7, you list the conditions that must be true
when the Use Case ends. These conditions are especially important in that they reveal pro-
cessing steps that may need to be added to the dialog to ensure that the system is stable
when this Use Case is completed.
Tip
134910-3 ch07.F 5/31/02 2:05 PM Page 77

Saturday Morning78
Table 7-7 The Fill Order Use Case Narrative: Post-conditions
Field Name Field Description
Post-conditions Normal termination:
The changes to the Order must be saved
(The backorder is handled by the CreateBackorder Use Case)
Cancel:
The Order must be saved unchanged
If a backorder was being created, it must be cancelled
Note that the post-conditions include some items that go a bit beyond the scope of a Use
Case, like saving the Order. A rule of thumb with Use Cases is that you include only what
the user can see, and what can be inferred by what they can see. In this case, if the user
gets a message indicating that the Order was updated, then you would include the messages
in the Use Case dialog. You would not include the actual steps for updating the Order in the
database. If your team feels that information is really needed, first make certain that users
agree that your understanding, as documented in the narrative, was correct. Then you could
take the Use Case description down a level to address the requirements you know have to be
supported by the design. This rule is a little bit gray, but it comes with the territory.
REVIEW
The Use Case narrative describes, in user-level terms, what the users expect from the Use
Case. The Use Case is a feature of the system with a beginning, a middle, and an end. As
such, it needs to be explained in terms plain enough for the users to understand and verify,
but precise enough for analysts and designers to rely on in order to build the system.
The features of a Use Case narrative aren’t standardized, but this session provides a set of
common elements in wide use:
¼
Use Case initiation describes how to start a Use Case.
¼
Assumptions define conditions that must be true, but are not tested in this Use
Case.

¼
Pre-conditions define conditions that must be true, and are tested in this Use Case.
¼
The Use Case dialog explains how the user (whether an actor or another Use Case)
interacts with the system during the execution of the Use Case.
¼
Use Case terminations define the different mechanisms that can cause the Use Case
to stop execution.
¼
Post-conditions define the state of the system that must be true when the Use Case
ends. This helps prevent Use Cases from leaving the system in an unstable condition
for other Use Cases that follow.
134910-3 ch07.F 5/31/02 2:05 PM Page 78
Session 7—Building the Use Case Narrative 79
Although these elements are valuable, they are by no means exclusive. Definitely look into
other books and online resources on Use Cases, and augment the narrative to support your
own method of development.
QUIZ YOURSELF
1. What is an assumption? (See “Assumptions.”)
2. What is a pre-condition? (See “Pre-conditions.”)
3. Who are the participants in the Use Case dialog? (See “Dialog.”)
4. What is a Use Case termination? (See “Use Case termination.”)
5. What are post-conditions? (See “Post-conditions.”)
134910-3 ch07.F 5/31/02 2:05 PM Page 79
134910-3 ch07.F 5/31/02 2:05 PM Page 80