Software Modeling with UML

U
Usecase A l i
Analysis
Use case Analysis
 Finding
g Use Cases
 With a Use Case Diagram,
 you are getting a clear picture of who uses a system, and what
they can d
th do with
ith it
it.
 You also have forced some decisions, and provided some external
structure to the system.
 The high level Use Case Diagrams
 Describing
g Use Cases
 Once you have defined the use cases at the high level, a lot of work is
necessary to open these up and define them in detail.
 From use case diagram,
d we know
k what
h the
h system presents to the h
various users (or actors),
 we need to define in fine detail the "how"
how of that interaction.
interaction
Use cases are defined as detailed sequences of behaviour.
Describing Use Cases
 define in fine detail the "how" of that interaction. Use cases
are defined
d f d as detailed
d l d sequences off behaviour.
b h
 Organize the sequences as primary and alternative paths.
 For example:
example
 The primary path for correcting a billing problem for a customer by a
customer service agent might be:
1. Enter the customer number
2. Display the customer details (name and address, etc)
3 Check the customer
3. customer'ss password,
password and click on "validated"
validated
4. Retrieve the last statement for the customer
5. Scroll to the line item the customer is querying
6. Agent decides to give a credit, so presses the "credit customer" button
7. Enter the credit amount
8 Click on the "confirm"
8. confirm button.
button
Describing Use Cases
 If we then look for alternatives p
paths to enteringg a credit amount,
where the agent is not allowed to give more than a set limit, so
an alternative might be:

 7.1 Credit amount over agent's

g ppermitted limit, so
 7.1.1 Put up a screen asking for a managers authorisation code
 7.1.2 Agent calls over manager
 7.1.3 Manager enters authorisation code
 7.1.4 Code accepted, so continue to 8.
Describing Use Cases
 Detailingg use cases at this level is essential to p
prevent vagueness
g
later in the analysis and design process.
 This level of description
p is veryy suitable ffor showingg to the users off
the system.
 Use Cases are usuallyy documented in a word p processor.
 Using a set format for the Use Cases makes the collection and
organization
g straightforward.
g f
 The following format for a Use Case Plan is suggested:
Describing Use Cases
Use Case Number: Use Case Name:
Brief Description:
Actors:
Frequency of Execution:
Scalability:
Criticality:
Primary Path:

U C
Use Cases R
Related
l t d tto P
Primary
i P
Path:
th

Alternatives:

Use Cases Related to Alternatives:

Exceptions:

Use Cases Related to Exceptions:

Notes:
Describing Use Cases
 Frequency
q y of Execution
 The frequency of execution of a use case effects the design
considerably.
 Something
S hi that
h iis used
d a th
thousand
d times
ti an h
hour hash to perform
f
efficiently.
 If something is used once a month, efficiency is less important.
 In systems development, speed of development versus
performance is often a key trade-off.
 Scalability
 How many people are likely to be using this system at the
same time?
ti ?
 This is highly relevant today with the development of Internet
pp
applications that deal directlyy with customers,, where hundreds or
thousands of people may make use of the system at any one time.
Describing Use Cases
 Criticality
y
 What happens if the use case does not fire?
 A use case in an emergency
g y service to record details of an
emergency is more important in the short term than one that provides
reports.
 Related Use Cases
 As you elaborate a use case in this way, you are going to find other
use cases that you need to call.
 Notes
 Notes are a useful place to keep comments, change records. This is
a living document that will grow, expand and change.
 Use Case Number: 99 Use Case Name: Invoice Customer

An Brief Description: This is run daily to send invoices to customers. Items that have been delivered are billed all on
the same invoice. Customers are only billed once a month.

Example
Actors: Daily batch run,
run customer (indirectly,
(indirectly through post)
Frequency of Execution: Daily
Scalability: Only one instance of this runs at any one time.
Criticality: Essential. Every days delay to printing invoices affects the bank balance considerably. Not running this
for 7 days could trigger a serious cash flow problem.
Primary Path:
The following sequence is carried out for every customer on the sales ledger who has not been billed in the last
month:
1. Get sales items from the sales ledger.
2.. Get
Ge customer
cus o e details
de s from
o thee customer
cus o e file,
e, covering
cove g billing
b g address
dd ess details.
de s.
3. Get any credits that the customer has.
4. Get discount details for customer.
5. Print the invoice header
6. Print the line items on the invoice
7 Calculate any discounts
7.
8. Apply any credits
9. Calculate and print the invoice total
10. Calculate and print the VAT
11. Mark items on sales ledger as invoiced
Use Cases Related to Primary Path:

Alternatives:
2.1 No customer details on customer file, so print an error message on a report. Do not mark the items on the sales
g as invoiced. The message
ledger g needs to detail the sales items that have been entered.
Use Cases Related to Alternatives:
Invoicing error report
Exceptions:

Use Cases Related to Exceptions:

Notes:
Describing Use Cases
 Activity
y Diagrams
g
 The behaviour of a Use Case is sometimes complicated. To
describe the behaviour graphically, you can use an Activity
Diagram
i to draw
d out the
h primary
i andd alternative
l i paths.
h
Sometimes a number of Activity Diagrams will be necessary to
describe a Use Case.
Case
 Sequence Diagrams
 The next stage in design will take us on to using Sequence
Diagrams. The scenario analysis you have done for the Use Cases
will be used directlyy in the construction of Sequence
q
Diagrams. Once you reach the Sequence Diagrams you are
beginning to move into the "how" of system behaviour, and
switching
it hi into
i t ddetailed
t il d analysis,
l i andd ultimately
lti t l design.
d i
Describing Use Cases
 Use case diagrams
g are helpful
p in three areas:
 determining features (requirements). New use cases often
generate new requirements as the system is analyzed and the design
takes shape.
 communicating with clients. Their notational simplicity makes use
case diagrams
di a goodd way for
f ddevelopers
l to communicate
i with
i h clients.
li
 generating test cases. The collection of scenarios for a use case may
suggest a suite of test cases for those scenarios.
scenarios
Summary
 The basic diagrams
g for describingg use cases are very
y simple.
p
 The complexity of use cases lies in the analysis.
 Use cases are complicated sets of flows of activity.
activity
 Later we shall be seeing how we describe these flows and link them
to objects.
objects
 Although the notion of use case is simple, they are an important
part of analysis and design,
design and we will be continually linking
other bits of information modelling to them.