Driving Development with Use

Cases

Jason Gorman

© Jason Gorman 2005. All rights reserved.

"I am currently working on a
team which is [in] the process
Requirements Analysis
of adopting RUP and UML
standards and practices. After Using UML (2 Days)
one of our design sessions, I
needed to lookup some Since Autumn 2003, over 180,000 Java and .NET developers have
information and came across learned the Unified Modeling Language from Parlez UML
your site. Absolutely great! (http://www.parlezum l.com) , making it one of the most popular
Most [of] the information I've UML training resources on the Internet.
had questions about is
contained within your tutorials Modeling For A Reason
and then some."
Unlike other UML courses, Requirements Analysis using UML
introduces only the elements of modeling you w ill need to get the job
done.
"Really great site... I have been
trying to grasp UML since the Learning By Doing
day I saw Visual Modeler. I
knew a few things but there By w orking through a practical mini-project, you w ill learn key
were gaps. Thanks to your site modeling notations as w ell as useful analysis techniques within a
they have shrunk simple iterative process that you will be able to apply to your ow n
considerably." projects immediately.

Beyond Use Cases

"I went on a UML training Other analysis courses start w ith functional requirements and leave
course three months ago, and out the critical element of any software project – where do those
came out with a big folder full requirements come from in the first place?
of hand-outs and no real
understanding of UML and how
to use it on my project. I spent Requirements Analysis using UML starts at the beginning w ith
a day reading the UML for business requirements and business models, and demonstrates a
.NET tutorials and it was a simple process for getting from business goals to system use cases
much easier way to learn. and beyond, giving clear traceability at all levels of your enterprise
'Here's the diagram. Now architecture
here's the code.' Simple."
www.parlezuml.com/training.htm

advertisement

© Jason Gorman 2003. All rights reserved.

 What Will I Learn?
Requirements Analysis using UML takes you on a journey from the business
goals of your project to an object oriented description of system functionality. You
will only learn what you need to know to get the job done, but enough to provide a
solid foundation for further learning.

Use Case Diagrams Object Diagrams & Filmstrips

Model the users of the Model snapshots of the running
system and the goals they system and show how actions
can achieve by using it change object state

Class Diagrams Packages &

Model types of objects Model Management
and the relationships Organise your logical and
between them. physical models with packages

Activity Diagrams User Experience Modeling

Model the flow of use cases Design user-centred systems
and single and multi- with UML
threaded code

Statechart Diagrams Enterprise Architecture

Model the lifecycle of Tracing your models
objects and event-driven through the layers of the
logic Zachman Framework

Business Modeling
Plus simple approaches to:
Apply UML to business
goals, processes, rules and
structure • Iterative & Incremental Development
• Change & Defect Management
www.parlezuml.com/training.htm • User Acceptance Testing
• Project Planning & Tracking

advertisement

© Jason Gorman 2003. All rights reserved.

In Today’s Episode…

• What is a Use Case?

• Use Case-Driven Development

• UML Use Case diagrams

© Jason Gorman 2003. All rights reserved.

What Is A Use Case?

• Describes a functional requirement of the system as a

whole from an external perspective
— Library Use Case: Borrow book

— VCR Use Case: Set Timer

— Woolworth’s Use Case: Buy cheap plastic toy

— IT Help Desk Use Case: Log issue

© Jason Gorman 2003. All rights reserved.

Actors In Use Cases

• Actors are external roles

• Actors initiate (and respond to) use cases

— Sales rep logs call

— Driver starts car

— Alarm system alerts duty officer

— Timer triggers email

© Jason Gorman 2003. All rights reserved.

More Use Case Definitions

• “A specific way of using the system by using some

part of the functionality” Jacobsen

• Are complete courses of events

• Specify all interactions

• Describable using state-transitions or other diagrams

• Basis for walk-throughs (animations)

© Jason Gorman 2003. All rights reserved.

 A Simple Use Case
USE CASE: Place order
GOAL: To submit an order and make a payment
ACTORS: Customer, Accounting
PRIMARY FLOW:
1. Customer selects ‘Place Order’
2. Customer enters name
3. Customer enters product codes for products to be ordered.
4. System supplies a description and price for each product
5. System keeps a running total of items ordered
6. Customer enters payment information
7. Customer submits order
8. System verifies information, saves order as pending, and forward information to
accounting
9. When payment is confirmed, order is marked as confirmed, and an order ID is
returned to customer © Jason Gorman 2003. All rights reserved.
 Suggested Attributes Of Use Cases
• Name * •Used use-cases

• Actors * •Flow of events (Primary Scenario) *

• Goal* •Activity diagram

• Priority •User interface
• Status •Secondary scenarios
• Preconditions
•Sequence diagrams
• Post-conditions
•Subordinate use cases
• Extension points
•Collaboration diagrams
• Unique ID
•Other requirements (eg,
performance, usability)
* Required
© Jason Gorman 2003. All rights reserved.
Use Case-Driven Development

Request cheque book

Withdraw cash
Log in

Display balance

Deposit funds

Print mini-statement
Request postal statement

© Jason Gorman 2003. All rights reserved.

Prioritise Use Cases
Log in

Withdraw cash

Display balance
importance
Print mini-statement

Deposit funds

Request cheque book

Request postal statement

© Jason Gorman 2003. All rights reserved.

Estimate Development Time
Log in 2 days

Withdraw cash
12 days

importance
Display balance
2 days

Print mini-statement
5 days
Deposit funds
10 days
Request cheque book
3 days
Request postal statement
2 days
© Jason Gorman 2003. All rights reserved.
Do Incremental Deliveries (2-3 weeks long)
Log in

Withdraw cash
Iteration #1

Display balance
importance
Print mini-statement

Iteration #2
Deposit funds

Request cheque book

Iteration #3
Request postal statement

© Jason Gorman 2003. All rights reserved.

"I am currently working on a
team which is [in] the process
of adopting RUP and UML
standards and practices. After UML for Managers (1 Day)
one of our design sessions, I
needed to lookup some The key to success in IT and business projects is effective
information and came across comm unication. Building a shared understanding requires that all
your site. Absolutely great! project stakeholders speak the same language.
Most [of] the information I've
had questions about is A Picture Is Worth 1000 Lines of Code
contained within your tutorials
and then some." Visual Languages enable project stakeholders to express complex
and subtle ideas in a w ay that is much easier to digest than wordy
written specifications. Visual Languages make communication and
understanding quicker and easier, and the effective use of Vis ual
"Really great site... I have been Models can greatly improve a project’s chances of success.
trying to grasp UML since the
day I saw Visual Modeler. I Many Problems. One Visual Language.
knew a few things but there
The industry-standard Unified Modeling Language can be used to
were gaps. Thanks to your site
they have shrunk describe many aspects of your business and the systems w ithin it.
considerably." UML can be applied at all levels, from your corporate strategy right
dow n to the design of your databases. This makes it possible to unify
different views of your business and to share and reuse knowledge
more effectively. It also helps you to learn m ore about your
"I went on a UML training business and how it could be improved.
course three months ago, and
came out with a big folder full Are You Ready to Parlez UML?
of hand-outs and no real
understanding of UML and how UML for Managers introduces business decision makers and IT
to use it on my project. I spent strategists to the key aspects of Visual Modeling using UML. It
a day reading the UML for highlights areas where Visual Modeling could be applied to your
.NET tutorials and it was a business, and helps you to build a practical and realistic roadmap for
much easier way to learn. adopting UML across your enterprise.
'Here's the diagram. Now
here's the code.' Simple."
www.parlezuml.com/training.htm

advertisement

© Jason Gorman 2003. All rights reserved.

Simplifying Complex Use Cases

• Strategy #1 : Break large/complex use cases down into

smaller and more manageable use cases

Go to work Leave house

Walk to station

Walk to office
fro m station Buy ticket

Alight fro m train Board train

© Jason Gorman 2003. All rights reserved.

Simplifying Complex Use Cases

• Strategy #2 : Break large/complex use cases down into

multiple scenarios (or test cases)

Withdraw cash : Customer

has Sufficient Funds

Withdraw cash : Customer

Withdraw cash has insufficient funds

Withdraw cash : ATM cannot

dispense specified amount

© Jason Gorman 2003. All rights reserved.

Relationships Between Use Cases

• Includes
— Eg, “Go to work” includes “board a train”

• Extends
— Eg, If the trains aren’t running, “catch a bus” may extend “go
to work”

• Generalization
— Eg, “Feed an animal” is a generalization of “Feed a cat”

© Jason Gorman 2003. All rights reserved.

 UML Use Case Diagrams relationship

ATM

check balance

withdraw cash «include»

Customer bank

withhold card

«extend»

log in

actor

Use case System

boundary
© Jason Gorman 2003. All rights reserved.
Use Case Best Practices

• Keep them simple & succinct

• Don’t write all the use cases up front - develop them
incrementally
• Revisit all use cases regularly
• Prioritise your use cases
• Ensure they have a single tangible & testable goal
• Drive UAT with use cases
• Write them from the user’s perspective, and write them in
the language of the business
• Set a clear system boundary and do not include any detail
from behind that boundary
•Use animations (walkthroughs) to illustrate use case flow.
Don’t rely on a read-through to validate a use case.
• Look carefully for alternative & exceptional flows
© Jason Gorman 2003. All rights reserved.
Common Use Case Pitfalls

1) The system boundary is undefined or inconstant.

2) The use cases are written from the system's (not the actors') point of view.
3) The actor names are inconsistent.
4) There are too many use cases.
5) The actor-to-use case relationships resemble a spider's web.
6) The use-case specifications are too long.
7) The use-case specifications are confusing.
8) The use case doesn't correctly describe functional entitlement.
9) The customer doesn't understand the use cases.
10) The use cases are never finished.

© Jason Gorman 2003. All rights reserved.

The 4+1 View Of Architecture

Logical Implementation

Use Cases

Process Deployment

© Jason Gorman 2003. All rights reserved.

www.parlezuml.com

© Jason Gorman 2005. All rights reserved.