22. Sample Use Case Diagrams

Telephone

Sometimes it's useful to distinguish between actor/use case associations that are initiated by the actor (arrow from actor to use case) and those initiated by the system (arrow from use case to actor).

Make Call Scenarios

A scenario (also called interaction or use case instance) is an exchange of messages between actors and system according to some protocol.

Here are some useful analogies:

scenario is to use case as
object is to class as
function call is to function declaration. Here are some make call scenarios: connected, busy, no answer, invalid number A scenario may be described using a script. Here's a script for the connected scenario of make call: subscriber: dial number
telephone: send number to C.O.
central office: ring
telephone: play ring tone
central office: connect
telephone: connect
subscriber: talk
subscriber: hangup
telephone: disconnect A sequence diagram is a slightly more formal way to describe a scenario:



VCR



Document Editor

The document editor use case model highlights the distinction between includes, extends, and specializes (i.e., generalizes). It's useful to distinguish between actor initiated and use case initiated use cases. Save As specializes Save because it's actor-initiated, whereas First Save extends Save because it can only be initiated by the Save use case. Like First Save, Get Path is also use case initiated, but Get Path is always initiated by First Save, Save As, and Open, while First Save is only conditionally initiated by Save (i.e., if it's the first time the document is being saved).

Note: Dependency arrows are broken in Rose.

Menus and menu items often make good use cases. Often menu item use cases are generalized by their parent menu use case. Buttons and boxes also make good use cases. When the user activates a text or list box, a message is sent to the system. In this case we may regard the text or list selection as a message parameter.

Order Processing System

View Catalog extends Place Order because it is only initiated if the Customer doesn't know what he wants to order.
 
 

Credit Card Payment System

It's also possible to show relationships (associations and generalizations) between actors in a use case diagram. (Remember, Actor is just a class stereotype with a special icon. Also remember that when UML talks about actors, what they really mean are roles.) Showing relationships between actors is mostly useful for modeling business processes.



Stack Calculator

Apply Function, Apply Trig Function, and Apply Arithmetic Function are abstract use cases:

Other Examples

Sketch use case diagrams for the following systems:

Point of Sale Terminal (POST)

Inventory Control System

Payroll System

Streaming Media Player

Electronic Business

Web Browser

Web Server

Computer

Car

TV

PBX

Call Center

Chat Room

Statistics/Probability Calculator

Financial Calculator

Graphing/Geometry Calculator

Physics Calculator

Integrated Development Environment

Electronic Auction

Patient Monitoring System

ATM

Battlefield Management System

Manufacturing Control System

Embedded flight Control System

Database Management System

Solitaire

Use Case Theory

Regular Languages

Definitions:

string = the set of all strings
const string nil = ""; // the empty string
const string err = "error"; // the error string
empty = { } // the empty language. Assume A and B are subsets of string (subsets of string are called languages): class A: public string { ... };
class B: public string { ... }; then A * B = {x + y | x in A && y in B} // concatenation
A + B = {z | z in A || z in B} // union
A0 = { nil }
A1 = A
A2 = A * A
A3 = A * A * A
etc.
A* = A0 + A1 + A2 + A3 + ... // iteration The set of all regular languages, REG, is the smallest set of languages containing the finite languages, FIN, and closed under concatenation, union, and iteration.

Use Cases

CMMD = all actor commands // menu selections, button clicks, etc.
CMMD* = all strings of actor commands (including nil)
RESP = all system responses to commands // prompts, echos, etc.
ACT = all system actions (update data, etc.)
(ACT * RESP)* = all strings of system action-responses A use case is a function of the form: F: CMMD* -> (ACT * RESP)* + { err } For example, if s is a string of actor commands, then F(s) is a sequence of system action-responses to these commands (or the error string).

For a use case F, let

LF = {s in CMMD* | F(s) != err } Use Case Relationships

Let A, B, and C be languages (subsets of CMMD*), then:

Informally

Assume F, G, and H are functions. Assume F calls G, and F conditionally calls H, then: