Administrivia

1
Administrivia

• Xbox 360s in WEB 130
• Right now 3, 4, 8 and 9 work.
• Others are being worked on now (but 5-7 may take
  longer to get working)
• Thursday HW4 (form a team)
• In class exercise (attendance is worth points)
• Any questions?

2
Example 1 Recycling Center

• Actor(s)?
• Use Case(s)?

Recycling Center
Swipe Card
Receipt Printer
3
Actors

• Green Person
• Recyling Engineer
• Credit Card company
• Walmart

4
Use Cases

• Use case Recycle Stuff
• Basic Steps
• Green Person swipes credit card
• System validates credit card and enables access
  and communicates success
• Green Person deposits cans and bottles into
  machine.
• System validates cans and bottles
• Green Person indicates that they are done.
• System credits the accumulated amount and prints
  a receipt and resets for the next kind soul.

5
Exceptional Conditions

• 2. If credit card is invalid then print a message
  indicating so and finish use case
• -----
• 5. If Green Person does not indicate that they
  are done within a a minute after the last item is
  deposited, we go to step 6.
• -----
• 4. If there is an invalid can or bottle we reject
  the invalid can/bottle immediately out of the
  machine and remember to print a message on the
  receipt indicating number of invalid items.

6
Lets Add A Little More

• The Use Cases presented previously are certainly
  acceptable
• Some in the Use Case community prefer this
  simplicity
• That is
• Use Case Name
• Basic Steps
• Exceptions
• Others feel that more detail is useful
• BUT!!! One should develop a model for your
  situation

7
Actors

• What information does an actor need?
• One possible document template
• Name (Identity)
• Brief Description (What is this role)
• Participates in
• A list of use cases this actor communicates with
• Goals (optional)
• Overall goals of this actor with regards to this
  system

8
Actors

• Remember this is a starting point
• You may need different/more information for your
  project.
• For homework assignments, we will choose a
  template
• Find the proper list of actors isnt easy
• Often worthwhile to just brainstorm a list, and
  start from there
• Remember that you may discover more actors as you
  work through the process
• Questions to ask to help identify actors
• What tasks does the actor want the system to
  perform?
• What information must the actor provide to the
  system?
• Are there events that the actor must tell the
  system about?
• Does actor need to be informed when something
  happens?
• Does the actor help initialize or shut down the
  system?

9
Use Cases

• What information does a Use Case need?
• Initially just start with a simple phrase for the
  Use Case, then fill out template
• One possible template
• Name (Identity), Brief Description
• Participating Actors (including Key Actors)
• Some prefer to have a single primary actor
• Pre-conditions (optional)
• Main flow of events
• significant exceptions (optional)
• Post-conditions (optional)
• Again, this a starting point
• If you are interested, search the net for Use
  Case Template

10
Example 2 ATM
FooBar ATM

• Actors
• Use Cases

11
Actors

• Card Holder
• ATM Bank
• Card Holder Bank
• ATM Maintenance Engineer
• Money bags

12
Use Cases

• Use Case ATM Bank Validates Card
• Precondition Customer provided card info and pin
• System communicates to ATM Bank with card info
  and pin.
• ATM Bank

13
(No Transcript)
14
Alistairs Basic Use Case Template - 1

• Use Case as a short active verb phrase
• __________________________________________________
  __________
• CHARACTERISTIC INFORMATION
• Goal in Context if needed
• Scope under design
• Level Subfunction
• Preconditions state of the world
• Success End Condition upon successful completion
• Failed End Condition goal abandoned
• Primary Actor actor, or description
• Trigger the use case, may be time event
• __________________________________________________
  __________

15
Alistairs Basic Use Case Template - 2

• MAIN SUCCESS SCENARIO
• to goal delivery, and any cleanup after
• __________________________________________________
  ____________
• EXTENSIONS
• referring to the step of the main scenario
• case
• case
• __________________________________________________
  ____________
• SUB-VARIATIONS
• eventual bifurcation in the scenario
• __________________________________________________
  ____________

16
Alistairs Basic Use Case Template -3

• RELATED INFORMATION (optional)
• Priority organization
• Performance Target case should take
• Frequency
• Superordinate Use Case case that includes this one
• Subordinate Use Cases tools, links to sub.use cases
• Channel to primary actor static files, database
• Secondary Actors to accomplish use case
• Channel to Secondary Actors static, file, database, timeout
• __________________________________________________
  ____________
• OPEN ISSUES (optional)
• decisions
• __________________________________________________
  ____________
• SCHEDULE
• Due Date
• ...any other schedule / staffing information you
  need...

17
ReDISS Use Case Model

• Description
• Precondition
• Basic Steps numbered list of steps
• Exceptions numbered with references to basic
  steps (after step i, before step j), condition,
  list of steps.
• Postcondition
• Note, marked in red is optional.

18
Another Example Use Case

• Register for Course (Main Scenario, Poorly
  Written Version)
• Display a blank schedule.
• Display a list of all classes in the following
  way The left window lists all the courses in the
  system in alphabetical order. The lower window
  displays the times the highlighted course is
  available. The third window shows all the courses
  currently in the schedule.
• Do
• Student clicks on a course.
• Update the lower window to show the times the
  course is available.
• Student clicks on a course time and then clicks
  on the "Add Course" button.
• Check if the Student has the necessary
  prerequisites and that the course offering is
  open.
• If the course is open and the Student has the
  necessary prerequisites, add the Student to the
  course. Display the updated schedule showing the
  new course. If no, put up a message, "You are
  missing the prerequisites. Choose another
  course."
• Mark the course offering as "enrolled" in the
  schedule.
• End do when the Student clicks on "Save
  Schedule."
• Save the schedule and return to the main
  selection screen.

Taken from What Is a Quality Use Case?, Steve
Adolph, et. al. Sample Chapter is provided
courtesy of Addison Wesley Professional. Date
Nov 22, 2002.
19
Did You Find These Errors?

• Too much user interface details
• Bad takes away design flexibility, takes time
  to write and review in the use case, makes
  requirements document longer
• Too low-level
• Typical of a use case written by a programmer
• Too long
• When it is too long, it gets boring and designers
  space out and dont read it thoroughly enough
• Complete?
• Is this complete in terms of achieving the goals?
• Sentence fragments
• Use real sentences and use the actual actor names

20
Revised Registration Use Case

• Register for Course
• Description This use case describes how a
  student will register for a set of courses.
• Basic Steps
• Student requests a new schedule.
• The system prepares a blank schedule form and
  pulls in a list of open and available courses
  from the Course Catalog System.
• Student selects primary and alternate courses
  from the available offerings.
• For each course, the system verifies that the
  Student has the necessary prerequisites and adds
  the Student to the course, marking the Student as
  "enrolled" in that course in the schedule.
• When the Student indicates the schedule is
  complete, the system saves the schedule.

21
Use Case PitfallsTop 10 Problems from Real
Projects Using Use Cases

• Problem Baseball Ticket Order System Customer
  uses a kiosk at a mall or calls on an 800
  numbers. Uses a credit card or picks up at will
  call at the stadium. Can view dates of games and
  examine seat availability to allow them to choose
  their seats.

From Susan Lilly, SRA International, Inc.,
appeared in proceedings of IEEE TOOLS 30, 1999
22
Problem 1

• Use Case Order tickets
• Basic Steps A Kiosk Customer uses the computer
  system to order tickets. Alternately, a Phone
  Customer calls the ticket business, and a Phone
  Clerk (an employee of the ticket business) uses
  the computer system to order tickets. The order
  process begins when
• What is wrong?

23
Problem 1 Confused System Boundary

• Problem Phone Customer does not really talk to
  the system, they talk to the Phone Clerk who
  talks to the system
• What they may be trying to do is model the
  business and the system which you could do,
  but you need two separate models
• Solution remove Phone Customer

24
Problem 1 Diagramming problem
25
Problem 2 - Symptoms

• Requirements engineer chose use cases named
  Process Ticket Order and Display Schedule
• Use Case Display Schedule Basic Steps The
  system searches its internal information to find
  the schedule of games for the next month. That
  schedule is then displayed.
• Use Case Fancy Display Schedule Basic Steps
  This use case EXTENDS the Display Schedule use
  case. The schedule that is displayed is in the
  form of a calendar. For each day where there is
  a game, the Kiosk Customer can mouse over that
  day and see more details about the teams that are
  playing.

26
Problem 2 Use Cases Written from the Systems
(not the Actors) point of view

• Choose names like Order Tickets and View
  Schedule
• Describes system processing without involving the
  actor, rewrite with Kiosk customer choose to
  view schedule. System
• Actor appears, but only in extension. Change
  diagram and use case so Actor involved in View
  Schedule

27
Problem 3

• Use Case x references actor Schedule
  Administrator
• Use Case y references actor Schedule Manager
• Use Case z references actor Scheduler

28
Problem 3 Actor Names are Inconsistent

• Try to discover actors first write a short
  description of the role of that actor
• Agree ahead of time on actor names and other
  terms by creating a glossary
• Include glossary with use case document

29
Problem 4
30
Problem 4 Too Many Use Cases

• Check granularity of use cases to make sure that
  they are appropriate
• Each should attain real use goals and give user
  real value
• Combine use cases that are fragments of real use
  cases
• In previous either combine into one Order Tickets
  or maybe Kiosk Order Tickets, Clerk Order
  Tickets, and Choose Tickets
• Sometimes you DO have a lot of use cases
• Solution use packages as a grouping mechanism
  (see next)

31
Package Model
other packages Defined
32
Problem 5

• What do you notice about this diagram?

33
Problem 5 Actor-to-use Case Relationships
Resemble a Spiders Web
Use Generalization
34
Problem 6 The Use Case Specifications are Too
Long

• Symptom A single use case specification goes on
  for page after page after page
• Cure Granularity may be too coarse (Use Schedule
  vs. View Schedule, Create Schedule, Modify
  Schedule)
• Cure Specification may be too fine (falling into
  implementation)

35
Problem 7 Use Case Specifications Are Confusing

• Symptom Use case lacks context
• Cure Add a Context field to the Use Case
  description
• Cure Clean up the description so the context is
  clear
• Symptom Normal flow looks like a computer
  program
• Cure Look for conditionals and put into
  alternate flow
• Cure If you are trying to describe an algorithm
  use something other than use case to do it
• Cure Again, dont talk about implementation

36
Problem 8

• Use Case Process Game Schedule
• Basic Steps The Kiosk Customer requests to see
  the game schedule for the next month. The system
  finds the schedule and displays it for the Kiosk
  Customer.
• Exception The Schedule Administrator enters the
  new game schedule into the System during the off
  season.
• Exception When a game must be rescheduled, the
  Schedule Administrator changes the date and time
  to the new date and time

37
Problem 8 The Use Case Doesnt Correctly
Describe Functional Entitlement

• Often happens when trying to think
  object-oriented create, read, update, delete
  an object
• Cure Make sure that each actor is entitled to
  perform the use case
• Solution

38
Problem 9 The Customer Doesnt Understand the
Use Cases

• They dont understand use cases
• Teach them the basics
• Write a short document on them and add to the
  overall doc
• Have a training session
• Avoid (if possible) use of and
  
• Use cases dont tell a story
• Add context section
• Add a package and package up a set of use cases
  into a story
• Include other stuff to help them see the story
• Use case organization does not match the way the
  customer thinks about the problem
• Package use cases up into groups of use cases to
  help them see
• Also, order them chronologically within the
  package

39
Problem 9 continued

• Use case is written in computerese
• Try to avoid computer slang
• Customer just hates use cases
• Give them what they want
• Consider using them to help you figure out what
  the system does
• Keep them for downstream to the
  designers/implementors, instead of upstream to
  the customer

40
Problem 10 Use Cases are Never Finished

• For each design change, you have to update/change
  the use cases
• Must have design or implementation in the use
  case
• Try to keep them loosely coupled
• Keep them high level
• There are a ton of exceptions
• Analysis paralysis you keep thinking of more
  and more options
• Shoot for covering about 80 of the cases

41
Summary on Problems

• Make sure that diagram and text match
• Study diagram for potential problems
• Develop a checklist to go through when analyzing
  each use case

42
Example 3 Video Rental Store

• Actors
• Use Cases

FooBar Videos
43
Actors
44
Use Case Diagram
45
A Couple of Use Cases
46
(No Transcript)
47
Future

• Coming Thu, Feb 25 an in-class, team quiz on use
  cases
• Will take most/all of the class
• Idea will be to write some use cases (and draw a
  diagram)
• Critique and find errors in some use cases
• Rewrite some use cases that may be confusing