Use case diagram
Use case diagram is a diagram that describes the functional requirements of the system. It models the the external users of the system (actors) and the way the systems is used (use cases) – an actor of a system is not necessary a human being, it could be just another system.
The requirements of a software system describe what the user expects from the system – in
other words, what the system will do for the user. When modeling a system both functional and nonfunctional requirements need to be considered.
In the use case modeling approach, functional requirements are described in terms
of actors, which are users of the system, and use cases. A use case defines a sequence
of interactions between one or more actors and the system. The system is treated
as a black box – that is, dealing with what the system does in response to the actor’s
inputs, not the internals of how it does it.
A use case always starts with input from an actor. A use case typically consists
of a sequence of interactions between the actor and the system.
Use case actors
An actor represents a role played in the application domain, typically by a human
user. A user is an individual, whereas an actor represents the role played by all users
of the same type.
Primary and Secondary Actors
A primary actor initiates a use case. Thus, the use case starts with an input from
the primary actor to which the system has to respond. Other actors, referred to as
secondary actors, can participate in the use case
IDENTIFYING USE CASES
To determine the use cases in the system, it is useful to start by considering the actors
and the interactions they have with the system. Each use case describes a sequence of interactions between the actor and the system.
DOCUMENTING USE CASES IN THE USE CASE MODEL
Each use case in the use case model is documented in a use case description, as
- Use case name: Each use case is given a name.
- Summary: A brief description of the use case, typically one or two sentences.
Dependency: This optional section describes whether the use case depends
on other use cases – that is, whether it includes or extends another use
- Actors: This section names the actors in the use case. There is always a primary
actor that initiates the use case. In addition, there may be secondary
actors that also participate in the use case. For example in the Withdraw
Funds use case, the ATM Customer is the only actor.
- Preconditions: One or more conditions that must be true at the start of use
case, from the perspective of this use case; for example, the ATM machine
is idle, displaying a “Welcome” message.
- Description of main sequence: The bulk of the use case is a narrative
description of the main sequence of the use case, which is the most usual
sequence of interactions between the actor and the system. The description
is in the form of the input from the actor, followed by the response of the
- Description of alternative sequences: Narrative description of alternative
branches off the main sequence. There may be several alternative branches
from the main sequence. For example, if the customer’s account has insufficient
funds, display apology and eject card. The step in the use case at which
the alternative sequence branches off from the main sequence is identified
as well as a description of the alternative.
- Nonfunctional requirements: Narrative description of nonfunctional
requirements, such as performance and security requirements.
Postcondition: Condition that is always true at the end of the use case (from
the perspective of this use case) if the main sequence has been followed; for
example, customer’s funds have been withdrawn.
- Outstanding questions: During development, questions about the use case
are documented for discussions with users.
Use case relationships
When use cases get too complex, dependencies between use cases can be defined
by using the include and extend relationships.
Inclusion use case :
a common sequence of interactions can
be extracted from several of the original use cases and made into a new use case,
which is called an inclusion use case.
EXTEND RELATIONSHIP :
In certain situations, a use case can get very complex, with many alternative
branches. The extend relationship is used to model alternative paths that a use
case might take. A use case can become too complex if it has too many alternative,
optional, and exceptional sequences of interactions. A solution to this problem
is to split off an alternative or optional sequence of interactions into a separate use
case. The purpose of this new use case is to extend the old use case, if the appropriate
condition holds. The use case that is extended is referred to as the base use case,
and the use case that does the extending is referred to as the extension use case.
Use case diagram ELEMENTS
Use case diagram modeling example.
Now we will try to model, our well know WordPress CMS.