Use Case

A use case is a methodology used in system analysis to identify, clarify, and organize system requirements. The use case is made up of a set of possible sequences of interactions between systems and users in a particular environment and related to a particular goal. It consists of a group of elements (for example, classes and interfaces) that can be used together in a way that will have an effect larger than the sum of the separate elements combined. The use case should contain all system activities that have significance to the users. A use case can be thought of as a collection of possible scenarios related to a particular goal, indeed, the use case and goal are sometimes considered to be synonymous.

The Primary Use Case Notations

Actors

A use case defines the interactions between external actors and the system under consideration to accomplish a goal. Actors must be able to make decisions, but need not be human: "An actor might be a person, a company or organization, a computer program, or a computer system — hardware, software, or both."Actors are always stakeholders, but many stakeholders are not actors, since they "never interact directly with the system, even though they have the right to care how the system behaves." For example, "the owners of the system, the company's board of directors, and regulatory bodies such as the Internal Revenue Service and the Department of Insurance" could all be stakeholders but are unlikely to be actors. Actors are often working on behalf of someone else.

All actors must have names according to the assumed role. Examples of actor names (user roles):

• Customer
• Web Client
• Student
• Passenger
• Payment System

Standard UML notation for actor is "stick man" icon with the name of the actor above or below of the icon. Actor names should follow the capitalization and punctuation guidelines for classes. The names of abstract actors should be shown in italics.

Student actor

An actor may also be shown as a class rectangle with the standard keyword «actor», having usual notation for class compartments, if needed.

Customer actor as Class

Relationships Between Actors

We can define abstract or concrete actors and specialize them using generalization relationship.
Generalization between actors is rendered as a solid directed line with a large arrowhead (same as for generalization between classes).

Web Client actor is abstract superclass for Administrator, Editor and Customer

Associations Between Actors and Use Cases

Each use case specifies a unit of useful functionality that the subject provides to actors. This functionality should be initiated by an actor. Actors may be connected to use cases only by binary association relationship.
An association between an actor and a use case indicates that the actor and the use case communicate with each other.
An actor could be associated to one or several use cases.

Actor Customer associated with two use cases

When an actor has an association to a use case with a multiplicity that is greater than one at the use case end, it means that a given actor can be involved in multiple use cases of that type. The specific nature of this multiple involvement depends on the case on hand and is not defined in the UML 2.4 specification.

Thus, use case multiplicity could mean that an actor initiates multiple use cases:

•     in parallel (concurrently), or
•     at different points in time, or
•     mutually exclusive in time.

Actor Bank is involved in multiple Use cases Transfer Funds.

When a use case has an association to an actor with a multiplicity that is greater than one at the actor end, it means that more than one actor instance is involved in initiating the use case. The manner in which multiple actors participate in the use case depends on the specific situation on hand and is not defined in the UML 2.4 specification.

For instance, actor's multiplicity could mean that:

•     a particular use case might require simultaneous (concurrent) action by two separate actors (e.g., in launching a nuclear missile), or
•     it might require complementary and successive actions by the actors (e.g., one actor starting something and the other one stopping it).

Two or more Player Actors are required to initiate Play Game Use case.

Use cases have no standard keywords or stereotypes. Use case could be shown with a custom stereotype above the name. As a classifier, use case has properties. A list of use case properties - operations and attributes - could be shown in a compartment within the use case oval below the use case name.

Use Case User Sign-In stereotyped as «authentication»

Use case with extension points may be listed in a compartment of the use case with the heading extension points.

Registration Use Case with extension points Registration Help and User Agreement

A use case can also be shown using the standard rectangle notation for classifiers with an ellipse icon in the upper right-hand corner of the rectangle and with optional separate list compartments for its features.

Registration Use Case shown using the standard rectangle notation for classifiers

The detailed behavior of a use case can be described by any means and techniques intended to define behaviors, in a separate diagram or textual document such as

•     interactions,
•     activities,
•     state machines,
•     pre- and post-conditions
•     natural language text

Abstract Use Case

UML 2.4 does not mention, define or explain abstract use cases. UML 1.x specification mentioned that "the name of an abstract use case may be shown in italics" but since UML 2.0 this sentence was removed from UML specifications without any explanations. One reason that the sentence was removed could be that because use case is a classifier, and any classifier could be abstract (with the name shown in italics), it is obvious that it should be applicable to the use cases as well. An abstract use case is intended to be used by other use cases, e.g., as a target of generalization relationship.

Bank ATM Transaction use case becomes abstract use case
as a result of including Customer Authentication use case.

Relationships Between Use Cases

Use cases could be organized using following relationships:

•     generalization
•     association
•     extend
•     include

Extend Relationship

Extend is a directed relationship that specifies how and when the behavior defined in usually supplementary (optional) extending use case can be inserted into the behavior defined in the extended use case.

Extended use case is meaningful on its own, it is independent of the extending use case. Extending use case typically defines optional behavior that is not necessarily meaningful by itself. The extend relationship is owned by the extending use case. The same extending use case can extend more than one use case, and extending use case may itself be extended.

The extension takes place at one or more extension points defined in the extended use case.

Extend relationship is shown as a dashed line with an open arrowhead directed from the extending use case to the extended (base) use case. The arrow is labeled with the keyword «extend».

 
Registration use case is meaningful on its own.
It could be extended with optional Get Help On Registration use case

The condition of the extend relationship as well as the references to the extension points are optionally shown in a comment note attached to the corresponding extend relationship.

Registration use case is conditionally extended by Get Help On Registration
use case in extension point Registration Help

Extension Point

An extension point is a feature of a use case which identifies (references) a point in the behavior of the use case where that behavior can be extended by some other (extending) use case, as specified by extend relationship.

Extension points may be shown in a compartment of the use case oval symbol under the heading extension points. Each extension point must have a name, unique within a use case. Extension points are shown as a text string according to the syntax:

extension point ::= name [: explanation ]

The optional explanation is some description usually given as informal text. It could be in other forms, such as the name of a state in a state machine, an activity in an activity diagram, some precondition or postcondition.

Registration use case with extension points
Registration Help and User Agreement

Extension points may be shown in a compartment of the use case rectangle with ellipse icon under the heading extension points.

Extension points of the Registration use case,
shown using the rectangle notation

Include Relationship

An include relationship is a directed relationship between two use cases when required, not optional behavior of the included use case is inserted into the behavior of the including (base) use case. Including use case depends on the addition of the included use case.

Including use cases are usually not complete by themselves and require the included use cases. For whatever reasons, UML 2.4 does not refer to those as abstract use cases which seems very appropriate. Many other sources define abstract use case as including use case, while in fact it has to be expressed the other way around: including use case is abstract use case. See discussion of the definition of abstract use cases.

The include relationship could be used:

•     when there are common parts of the behavior of two or more use cases,
•     to simplify large use case by splitting it into several use cases.

Included use cases are required, not optional for the inclusion. Execution of the included use case is analogous to a subroutine call or macro command in programming. All of the behavior of the included use case is executed at a single location in the including use case before execution of the including use case is resumed.

Note, while UML 2.4 defines extension points for the extend relationship, there are no "inclusion points" to specify location or condition of inclusion for the include.

Include relationship between use cases is shown by a dashed arrow with an open arrowhead from the including (base) use case to the included (common part) use case. The arrow is labeled with the keyword «include».

When two or more use cases have some common behavior, this common part could be extracted into a separate use case to be included back by the use cases with include.

Both Deposit Funds and Withdraw Cash use cases

require (include) Customer Authentication use case.

Use Case Relationships Compared

In the Unified Modeling Language, the relationships between all (or a set of) the use cases and actors are represented in a Use Case Diagram or diagrams, originally based upon Ivar Jacobson's Objectory notation.

Benefits of Use Case Analysis

1. It helps manage very complex projects by breaking them down into different facets of development, thus focusing developers.
2. It allows developers to visualize outcomes before the documentation process, avoiding issues early on.
3. Allows for earlier testing.
4. allows problem modules to be removed or altered as needed without disrupting the overall project
5. It allows for input from all sides of the equation, from user-end on up.
6. Ultimately controls cost overruns.
7, Is standardized so it has wider implications and uses
8. It leaves documentation for later analysis
9. Flexibility- it can be as simple or complex as needed for its purpose.
10. It is reusable project-wide.

References: UML-diagram

www(dot) uml-diagrams(dot) org/use-case-diagrams-examples.html