U S E C A S E M O D E L L I N G , W R I T I N G A N D

D E C O M P O S I T I O N O F U S E C A S E S

WHAT IS A USE CASE?

A use case is a list of actions or event steps, typically defining the interactions between

a role (known in the Unified Modeling Language as an actor) 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

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.

name

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:

• brief—terse one-paragraph summary, usually of the main success scenario.

• casual—informal paragraph format. Multiple paragraphs that cover various

scenarios.

• fully dressed—the 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 documents

As Diagrams

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…

• 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

student

registration

updating

grades

output

generating

faculty

NAMES

• Every use case must have a name that distinguishes it from other use cases.

• A name is a textual string.

• That name alone is known as a simple name;

• a path name is the use case name prefixed by the name of the package

in which that use case lives.

In practice, use case names are short active verb phrases naming some behavior found in the

vocabulary of the system you are modeling.

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

• 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.

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 included<<include>> updating

grades

output

generating

verifying

student id

<<include>>

<<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 extending<<extend>>

Exam copy

request

Exam-grade

appeal

<<extend>>

RELATIONSHIPS BETWEEN ACTORS

• Generalization.

student

non-graduate

student

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.

USE CASES AND FLOW OF EVENTS

• A use case describes what a system (or a subsystem, class, or

interface) does but it does not specify how it does it.

• Main flow of events:

• Exceptional flow of events:

• Main flow of events:

The use case starts when the system prompts the Customer for a PIN number.

The Customer can now enter a PIN number via the keypad. The Customer

commits the entry by pressing the Enter button. The system then checks this PIN

number to see if it is valid. If the PIN number is valid, the system acknowledges

the entry, thus ending the use case.

Exceptional flow of events:

The Customer can cancel a transaction at any time by pressing the Cancel

button, thus restarting the use case. No changes are made to the Customer's

account.

Exceptional flow of events:The Customer can clear a PIN number anytime before committing it and re-enter

a new PIN number.

Exceptional flow of events:If the Customer enters an invalid PIN number, the use case restarts. If this happens three times in a row,

the system cancels the entire transaction, preventing the Customer from interacting with the ATM for 60

seconds.

FORWARD AND REVERSE ENGINEERING

• Forward engineering is the process of transforming a model into

code through a mapping to an implementation language.

– A use case diagram can be forward engineered to form tests for the

element to which it applies

– Reverse engineering is the process of transforming code into a

model through a mapping from a specific implementation language