USE CASE MODELLING,

WRITING AND
DECOMPOSITION OF
USE CASES
BY
MOHIT ARORA

WHAT IS A USE CASE?

Ause caseis a list of actions or event steps, typically defining the
interactions between a role (known in theUnified Modeling Languageas
anactor) and a system, to achieve a goal.
They are used to visualize, specify, construct, and document the (intended)
behavior of the system, during requirements capture and analysis.
Provide a way for developers, domain experts and end-users to Communicate.
Use cases are text documents, not diagrams, and use-case modeling is
primarily an act of writing text, not drawing. However, the UML defines a
use case diagram to illustrate the names of use cases and actors, and
their relationships.

ACTOR
name
An actor is something with behavior, such as a person (identified by role),
computer system, or organization.
An actor represents a set of roles that users of use case play when
interacting with these use cases.
Actors are not part of the system.

TYPES OF ACTORS
Primary actor - has user goals fulfilled through using services of the system
under discussion (SuD). For example, ATM user in ATM system.
Supporting actor - provides a service (for example, information) to the SuD.
For example, Bank server in ATM system.
Offstage actor - has an interest in the behavior of the use case, but is not
primary or supporting; for example, a government tax agency.

SCENARIO
A scenario is a specific sequence of actions and interactions between
actors and the system under discussion; it is also called a use case
instance.
For example, the scenario of successfully purchasing items with cash.
A use case is a collection of related success and failure scenarios that
describe actors using a system to support a goal.

USE CASE TYPES AND FORMATS

Black-box use cases are the most common and recommended kind; they
do not describe the internal workings of the system, its components, or
design. Rather, the system is described as having responsibilities.
Example:

FORMALITY TYPES
Use cases are written in different formats, depending on need. In addition to the
black-box versus white-box visibility type, use cases are written in varying
degrees of formality:
briefterse one-paragraph summary, usually of the main success scenario.
casualinformal paragraph format. Multiple paragraphs that cover various
scenarios.
fully dressedthe most elaborate. All steps and variations are written in
detail, and there are supporting sections, such as preconditions and success
guarantees

USE
CASES
As Text
docume
nts

As
Diagram
s

USE CASE AS TEXT DOCUMENTS

We will take an example of Process Sale and fully dressed use case formality
type.

STEPS OF WRITING USE CASE.

1. Primary Actor: The principal actor that calls upon system services to fulfill a goal.
2. Stakeholders and Interests:
3. Preconditions: state what must always be true before beginning a scenario in the
use case.
4. Success Guarantee (Post conditions): state what must be true on successful
completion of the use case - either the main success scenario or some alternate path.
5. Main Success Scenario (or Basic Flow): This has also been called the "happy
path" scenario. It describes the typical success path that satisfies the interests of the
stakeholders.
6. Extensions (or Alternative Flows): They indicate all the other scenarios, say
exceptions
7. Special Requirements: If a non-functional requirement, quality attribute, or
constraint relates specifically to a use case, record it with the use case
8. Technology and Data Variations List: how something must be done, but not what,
and it is noteworthy to record this in the use case
9. Frequency of Occurrence:
10. Open Issues

USE CASE UC1: PROCESS SALE

Primary Actor: Cashier
Stakeholders and Interests: Cashier, Customer, Company, Government
Tax Agencies, Payment Authorization Service.
Preconditions: Cashier is identified and authenticated.
Success Guarantee (Post conditions): Sale is saved. Tax is correctly
calculated. Accounting and Inventory are updated. Commissions recorded.
Receipt is generated. Payment authorization approvals are recorded.
Main Success Scenario (or Basic Flow):
1.

Customer arrives at POS checkout with goods and/or services to

purchase.

2.

Cashier starts a new sale.

3.

Cashier enters item identifier.

4.

System records sale line item and presents item description, price, and
running total. Price calculated from a set of price rules.and
likewise

 Extensions (or Alternative Flows):

1.

At any time, System fails, Cashier restarts System.

2.

System reconstructs prior state.

3.

Invalid identifier.

4.

Customer tells Cashier to cancel sale etc.( Refer P. No. 65 of book)

. Special Requirements: Touch screen Ul, Credit authorization response within

30 seconds 90% of the time, Language internationalization etc
. Technology and Data Variations List: Item identifier entered by bar code
laser scanner, Credit payment signature captured on paper receipt. But within
two years, we predict many customers will want digital signature capture.
. Frequency of Occurrence: Could be nearly continuous.
. Open Issues:
1.

What are the tax law variations?

2.

What customization is needed for different businesses?

3.

Must a cashier take their cash drawer when they log out?

EXAMPLE OF USE CASE DIAGRAM

registration

student

updating
grades

output
generating

faculty

RELATIONSHIPS BETWEEN USE CASES

1. Generalization - use cases that are specialized versions of other use cases.
2. Include - use cases that are included as parts of other use cases. Enable to
factor common behavior.
3. Extend - use cases that extend the behavior of other core use cases.
Enable to factor variants.

1. GENERALIZATION
parent
The child use case inherits the
behavior and meaning of the
parent use case.
The child may add to or
override the behavior of its parent.

child

2. INCLUDE
The base use case explicitly incorporates the behavior of another use case
at a location specified in the base.
The included use case never stands alone. It only occurs as a part of some
larger base that includes it.

base

<<include>>

included

updating
grades

<<include>>
verifying
student id

output
generating

<<include>>

3. EXTENDS
The base use case implicitly incorporates the behavior of another use case
at certain points called extension points.
The base use case may stand alone, but under certain conditions its
behavior may be extended by the behavior of another use case.

base

<<extend>>

extending

Exam copy
request

<<extend>>

Exam-grade
appeal

RELATIONSHIPS BETWEEN ACTORS

Generalization.
student

graduate
student

non-graduate
student

RELATIONSHIPS BETWEEN USE CASES

AND ACTORS
Actors may be connected to use cases by associations, indicating that the
actor and the use case communicate with one another using messages.

Updating
grades
faculty

USE CASE EXAMPLE: ATM

Demonstration through MAGIC DRAW.