Use Case Modeling

Requirements

The input to the analysis phase of our development process is a list of system requirements captured from client interviews and other sources. There are two types of requirements: functional and non-functional. A functional requirement describes some function the system must perform. Non-functional requirements describe system constraints such as size, performance, platform, cost, schedule, etc. Here are some examples of non-functional requirements:

The server must handle up to 1000 transactions per minute without significant degradation in response time.

The server must run on the Sun OS platform and must be able to communicate with clients over any network with a TCP layer.

The server must be able to recover from system crashes without losing data.

The mean time between server failures should be no less than 6 months.

The server must be developed in less than one year and for no more than $100,000.

 Notice that none of these requirements actually say what the server does.

Use Case Elements

A use case represents a functional requirement of a system, subsystem, or class, without specifying its implementation. A use case communicates with one or more <<actor>> classes (humans or external systems).

In some cases a use case is initiated by an actor. In other cases a use case is initiated by another use case.

Attributes and Operations

Like a class, a use case can have attributes (e.g. execution state, priority, risk), operations (e.g. message handlers, private functions), and instances.

Use Case Theory

Mathematically, a use case is a function, F, that maps strings of actor messages into strings of system action-responses. For example, assume A, B, and C are actor messages (e.g., A = "select text", B = "select Edit/Copy", C = "select Edit/Paste"). Assume x, y, z are system actions (e.g., y = "copy selected text onto clip board", Z = "copy complete" dialog or prompt.), then:

F(ABC) = xXyYzZ // x, y, z are actions, X, Y, Z are responses A use case instance is an exchange of messages between actors and system according to some protocol.

Here are some useful analogies:

use case instance is to use case as
class instance (i.e., object) is to class as
function call is to function declaration. Note that actor messages can be parameterized. For example, if we type 5 into a dialog box of a calculator, then press the calculator's "cube" button, this sends the message "cube 5" to the system. We can think of "cube" as the message and 5 as the parameter. A scenario is a parameterized family of use case instances.

Relationships

Use cases are related to <<actor>> classes by <<communication>> associations.

Use cases are related to other use cases through generalization, <<include>> dependencies, or <<extend>> dependencies.

Use case A includes use case B, roughly means that B, viewed as a function, is called by A. B extends A means that B is conditionally called by A. In these two cases A may be actor initiated, but normally, B would not be actor initiated. A generalizes B means that B is a special case of A that may be actor-initiated. In this case B inherits all of the dependencies, properties, operations, and actor associations of A.

A use case diagram shows use case icons connected to actors and other use cases. Ideally, a system boundary is also shown. Here's a use case diagram for an on-line trading system:

Use Case Elaboration

We can elaborate use cases by using scripts, code, state diagrams, or activity diagrams.

State Diagrams

Activity Diagrams

Realization

Use cases are realized (i.e., implemented) by collaborations.

Collaborations

Structure (class diagrams)

A collaboration is a combination of objects that work together in some standard way to achieve a common goal. (Forget about roles.)

Behavior (interaction diagrams)

Sequence Diagrams

Collaboration Diagrams

Meta Model

Use Case Examples
Terminology