Islamic Azad University

Technology of Computer Engineering

Advanced software engineering

Use-Case Model

Prepared BY: Maytham Kareem Mousa

Supervision: Sassan Alizadeh (PHD)
7 December 2021
Introduction
The key to successful iterative development is ensuring that the development
team maximizes stakeholder value and minimizes risk early in the lifecycle,
while minimizing re-work later. This imposes some constraints on how we
develop the use-case model. A t one extreme is the classical waterfall approach,
which attempts to detail all of the requirements prior to design and
implementation. This approach delays delivery of stakeholder value and risk
reduction unnecessarily. At the other extreme is beginning development prior
to understanding what the system must do. This approach results in significant,
and costly, re-work later in the life cycle .A better approach is to detail only
those requirements which will be the focus of development in the next iteration
(or two). Selection of these requirements is driven by value and risk, and thus
requires as a minimum an abstract understanding of the "big-picture".

How the Use-Case Model Evolves

The recommended approach to evolving the use-case model takes a "breadth
before depth" approach. In this approach, one identifies the actors and use cases
and outlines them quickly. Based on this knowledge, one can then perform an
initial assessment of risk and priorities and thus focus the effort of detailing the
use cases on the right areas

Identify Stakeholders
Begin by listing all the external stakeholders for the system. These individuals
will be the source of the requirements.

Identify Actors
Name and describe the primary actors. See Guideline: Find and Outline Actors
and Use Cases.
Identify Use Cases
For each actor, ask "what does this actor want to accomplish with the
system"? This will reveal the primary use cases for the system. Name and
describe each of these as you discover them.

Update the Use-Case Model

Update the use case model to capture the actor and use case names and brief
description. Capture the relationship between the actors and use cases.

Outline the Basic Flows

For those use cases that are considered high priority by the stakeholders, or high
risk by the development team, capture a step-by-step description of the Basic
Flow. Don't worry about structuring the flow at this point. Focus on capturing
the dialogue between the actor and the system and the key requirements for the
system.

Identify Alternate Flows

As you work through the Basic Flows, ask: "What can go wrong?"; "What
options are available at this point?"; etc. These types of questions will reveal
alternate flows. Capture these, giving each a name and brief description. Fight
the urge to detail these alternate flows at this time.

Refactor the Use Case Model

Based on the Basic Flows you have identified, determine if there is common
behavior that could be factored out into <<include>> use cases. Refactor the
Use Case model accordingly.

Prioritize Use Cases

Given the abstract description you now have of the requirements, work with
stakeholders to prioritize the use cases. This will be the primary input to
iteration planning.
Elaboration
The purpose of elaboration is to demonstrate the feasibilty of the solution prior
to committing additional resources. To be successful, one should demonstrate
that stakeholder value can be delivered and that the risk of continuing is
acceptable. We should strive to detail and implement ~20% of the
scenarios. These scenarios should be selected to achieve good coverage of the
architecture (for example, a vertical slice through the architecture, touching as
many components and interfaces as possible, is preferred to elaborating the GUI
only).

Detail Basic Flow

For those UC selected for the next iteration, spend the time to detail the basic
flow now. See Guideline: Detail Use Cases and Scenarios.

Detail Alternate Flow

For those alternate flows selected for the next iteration, spend the time to detail
the flows now.

Update the Use-Case Model

Update the Use-Case Model to capture any refinements made as a result of your
work. Depending upon the complexity of the system, you may want to
introduce packages to group the use cases in a logical manner to simplify
communications, iteration planning, and parallel development.

Construction
The purpose of construction is to incrementally deliver functionality (and
value). Working from the iteration plan, continue detailing the remaining
requirements. Shoot for completion of ~90 - ~95% of use cases by the end of
construction.
Detail Basic Flows
For those UC selected for the next iteration, spend the time to detail the basic
flow now. See Guideline: Detail Use Cases and Scenarios.

Detail Alternate Flows

For those alternate flows selected for the next iteration, spend the time to detail
the flows now.

Update the Use-Case Model

Update the Use-Case Model to capture any refinements made as a result of your
work.

Transition

The purpose of transition is to make the system operational in its intended

environment. Some requirements will still be uncovered at this point, but if we
have done things right they should not stress the design. The remaining ~5%
to ~10% of use cases should be detailed and implemented in this phase.

Avoiding Functional Decomposition

A common pitfall for those new to use-case models is to perform a functional
decomposition of the system. This results in many small "use cases", that on
their own do not deliver the "observable result of value" to the actor. To avoid
this, watch for the following symptoms:

• Small use cases, meaning that the description of the flow of events is only
one or a few sentences.
• Many use cases, meaning that the number of use cases is some multiple of
a hundred, rather than a multiple of ten.
• Use-case names that are constructions such as "do this operation on this
particular data" or "do this function with this particular data". For example,
"Enter Personal Identification Number in an ATM machine" should not be
modeled as a separate use case for the ATM machine, because no one would
 use the system to do just this. A use case is a complete flow of events that
results in something of value to an actor.

To avoid functional decomposition, make sure that the use-case model helps
answer these kinds of questions:

• What is the context of the system?

• Why are you building this system?
• What does the user want the system to do?
• How do the users benefit from the system?

Structuring the Use-Case Model

There are three main reasons for structuring the use-case model:

• To make the use cases easier to understand.

• To partition common behavior described within many use cases.
• To make the use-case model easier to maintain.

Structuring is not the first thing you do, however. There is no point in
structuring the use cases until you know a bit more about their behavior than a
one-sentence description. You should at least have established a step-by-step
outline for the flow of events of the use case to make sure that your decisions
are based on an accurate understanding of the behavior.

There are several advanced modeling concepts available in the literature

for structuring the use-case model, however, following the principle of "keep-
it-simple" only the most useful of these, namely the <<include>> relationship
is discussed in this process. This relationship permits one to factor out common
behavior into a separate use case that is "include" in other use
cases. See Concept: Use-Case Model for more details.

Another aspect of structuring the use-case model for easier understanding is

grouping the use cases into packages. The use-case model can be organized as
a hierarchy of use-case packages. For more information on use-case packages,
see Concept: Use-Case Model.
Relationship Between Use Cases and Actors

Running each use case includes communication with one or more actors. A use-
case instance is always started by an actor asking the system to do something.
This implies that every use case should have communicates-associations with
actors. The reason for this rule is to enforce that the system provides only the
functionality that users need and nothing else. Having use cases that no one
requests is an indication that something is wrong in the use-case model or in the
requirements.

However, there are some exceptions to this rule:

• An "included" use case might not interact with an actor if the base use case
does.
• A use case may be initiated according to a schedule (for example, once a
week or once a day), which means that the system clock is the initiator. The
system clock is internal to the system; therefore, the use case is not initiated
by an actor but by an internal system event. If no other actor interaction
occurs in the use case, it will not have any associations to actors. However,
for clarity, you can use "time" as an actor to show how the use case is
initiated in your use-case diagrams. CAUTION: if you have a lot of "time"
actors in your model, challenge them. Perhaps you missed a real actor, such
as an administrator responsible for scheduling reports, etc.

Explanation
A use-case model is a model of how different types of users interact with the
system to solve a problem. As such, it describes the goals of the users, the
interactions between the users and the system, and the required behaviour of the
system in satisfying these goals.

A use-case model consists of a number of model elements. The most important

model elements are: use cases, actors and the relationships between them.
A use-case diagram is used to graphically depict a subset of the model to
simplify communications. There will typically be several use-case diagrams
associated with a given model, each showing a subset of the model elements
relevant for a particular purpose. The same model element may be shown on
several use-case diagrams, but each instance must be consistent. If tools are
used to maintain the use-case model, this consistency constraint is automated
so that any changes to the model element (changing the name for example) will
be automatically reflected on every use-case diagram that shows that element.

The use-case model may contain packages that are used to structure the model
to simplify analysis, communications, navigation, development, maintenance
and planning.

Much of the use-case model is in fact textual, with the text captured in the Use-
Case Specifications that are associated with each use-case model
element. These specifications describe the flow of events of the use case.

The use-case model serves as a unifying thread throughout system

development. It is used as the primary specification of the functional
requirements for the system, as the basis for analysis and design, as an input to
iteration planning, as the basis of defining test cases and as the basis for user
documentation

Basic model elements

The use-case model contains, as a minimum, the following basic model
elements.

Actor
A model element representing each actor. Properties include the actors name
and brief description. See Concept: Actor for more information.

Use Case
A model element representing each use case. Properties include the use case
name and use case specification. See Artefact: Use Case and Concept:
Use Case for more information.
Associations
Associations are used to describe the relationships between actors and the use
cases they participate in. This relationship is commonly known as a
“communicates-association”.

Advanced model elements

The use-case model may also contain the following advanced model elements.

Subject

A model element that represents the boundary of the system of interest.

Use-Case Package
A model element used to structure the use case model to simplify analysis,
communications, navigation, and planning. If there are many use cases or
actors, you can use use-case packages to further structure the use-case model in
much the same manner you use folders or directories to structure the
information on your hard-disk.

You can partition a use-case model into use-case packages for several reasons,
including:

• To reflect the order, configuration, or delivery units in the finished system

thus supporting iteration planning.
• To support parallel development by dividing the problem into bite-sized
pieces.
• To simplify communication with different stakeholders by creating
packages for containing use cases and actors relevant to a particular
stakeholder.
Generalizations

A relationship between actors to support re-use of common properties.

Dependencies A number of dependency types between use cases are defined in
UML. In particular, extend and include.

<<extend>> is used to include optional behavior from an extending use case in

an extended use case.

<<include>> is used to include common behaviour from an included use case

into a base use case in order to support re-use of common behavior.

The latter is the most widely used dependency and is useful for:

• Factoring out behaviour from the base use case that is not necessary for the
understanding of the primary purpose of the use case to simplify
communications.
• Factoring out behaviour that is in common for two or more use cases to
maximize re-use, simplify maintenance and ensure consistency.

Example Use-Case Diagram

Figure 1 shows a use-case diagram from an Automated Teller Machine (ATM)
use-case model.
Figure 1: ATM Use-Case Diagram

This diagram shows the subject (atm:ATM), four actors (Bank Customer, Bank,
Cahier and Maintenance Person), five use cases (Withdraw Cash, Transfer
Funds, Deposit Funds, Refill Machine and Validate User), three includes
dependencies, and the associations between the performing actors and the use
cases .The use cases Withdraw Cash, Deposit Funds, and Transfer Funds all
need to include how the customer is identified to the system. This behavior can
be extracted to a new inclusion use case called Validate User, which the three
base use cases include. The base use cases are independent of the method used
for identification, and it is therefore encapsulated in the inclusion use case.
From the perspective of the base use cases, it does not matter whether the
method for identification is to read a magnetic bank card, or perform a retinal
scan. They only depend on the result of Validate Customer. Note that Figure 1
is only a partial view of the use-case model. The complete use-case model also
includes descriptions of each actor, descriptions of each use case, and use-case
specifications for each use case. For a more complete example of this use case
model see Example: Evolution of the Use-Case Model.