Use Case Diagrams
Use Case Diagrams
Use Case Diagrams
Major elements of UML use case diagram - actor, use case, subject,
include and extend relationships.
Web Client actor is abstract superclass for Administrator, Editor and Customer
1
UML Association
Between Actor and Use Case
Each use case represents a unit of useful functionality that subjects provide to actors.
An association between an actor and a use case indicates that the actor and the use case
somehow interact or communicate with each other.
Only binary associations are allowed between actors and use cases.
An actor could be associated to one or several use cases.
2
Checkout use case requires Customer actor, hence
the 1 multiplicity of Customer. The use case may not need
Credit Payment Service (for example, if payment is in cash),
thus the 0..1 multiplicity.
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 the use case.
4
Web User Authentication use case is abstract use case
specialized by Login, Remember Me and Single Sign-On use cases.
Association Between Use Cases
Use cases can only be involved in binary associations.
Two use cases specifying the same subject cannot be associated since each of them
individually describes a complete usage of the system.
Use Case Extend
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.
5
Use Case Include
Use case include is a directed relationship between two use cases which is used to show
that behavior of the included use case (the addition) is inserted into the behavior of
the including (the base) use case.
The include relationship could be used:
to simplify large use case by splitting it into several use cases,
to extract common parts of the behaviors of two or more use cases.
A large use case could have some behaviors which might be detached into distinct smaller use
cases to be included back into the base use case using the UMLinclude relationship. The
purpose of this action is modularization of behaviors, making them more manageable.
Use case B is extracted from larger use case A into a separate use case.
Use cases B and C are extracted from larger use case A into separate use cases.
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 the
UML include relationship.
Use case C is extracted from use cases A and B to be reused by both use cases using UML
include relationship.
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.x defines extension points for the extend relationship, there are no
"inclusion points" to specify location or condition of inclusion for theinclude.
Including use case depends on the addition of the included use case, which is required and not
optional. It means that including use case is not complete by itself, and so it would make
sense to refer to the including use cases as abstract use cases. Neither of UML
2.x specifications up to the UML 2.5 even mentions abstract use cases. A number of other
UML sources define abstract use case as including use case, while in fact it has to be the
6
other way around: including use case is abstract use case. See discussion of the definition
of abstract use cases.
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.
7
Use case Specification
Name:
Identifier (A unique identifier for this use case, e.g. UC10)
Description (A couple of sentences or a paragraph describing the basic idea of the use case)
Goal (The business goal of the initiating actor)
Preconditions (List the state(s) the system can be in before this use case starts)
1.
Assumptions (Optional, List all assumptions that have been made)
1.
Frequency (Approximately how often this use case is realized, e.g., once a week, 500 times a
day, etc.)
Basic Course (Describe the normal processing path, aka, the Happy Path)
1. Use case begins when
2.
3. Use case ends when
Notes
List any "to dos", concerns to be addressed, important decisions made during the
development of this use case,