LECTURE 14: USE CASE BASICS CSC 212 – Data Structures

Why Should We Care? Without requirements or design, programming is the art of adding bugs to an empty text file. --Louis Srygley

Helping Local Economy  Write code for JackBot2000  Shuffles & deals cards for games of blackjack  Accepts and pays out on all bets  Allows dealers to chat up guests  Should boost blackjack profits greatly  Vital that software work correctly  Regulators promise large fines for any errors

Helping Local Economy  Write code for JackBot2000  Shuffles & deals cards for games of blackjack  Accepts and pays out on all bets  Dealers chat up betters & keep happy  Concept should boost profits greatly  Vital that software work correctly  Regulators promise large fines for any errors

Where to Begin?  Use industry standard for starting large project Use Cases

How To Do This?  Stories are your hammer  Unrelated technical details limited  Interaction specified & nailed down  Creates easy testing script for end  Clearly fixes actions and the results  Provides insight into client’s goals  Reasons behind result documented  People stories  Document stories at multiple levels  Visual, explanatory, outline are all important

 Must be of some real value  Serious requirements documented only  Important system uses from user’s perspective  Needs to define clear starting & stopping events  What event starts this use of the system?  What happens to let user know it’s over?  Actor/External initiator triggers start  User  Fluffy  Gravitational wave Use Case Basics

Deal First Card Use Case  Dealer presses the Deal button  Place card, face up, before each player & dealer

Deal Second Card Use Case  Deal one card, face up, to each player  Deal one card, face down, to the dealer Where is the external initiator? What event starts this use case? Why should the user care?

Deal Cards Use Case  Dealer presses the Deal button  Place card, face up, before each player & dealer  Place card, face up, before each player  Place card, face down, before dealer What if someone has blackjack? When should we check?

Play Hand Use Case  Dealer presses the Deal button  Place card, face up, before each player & dealer  Place card, face up, before each player  Place card, face down, before dealer  Check if dealer has blackjack  Remember that we are telling a story  2 behaviors possible, but still need to tell a story

Off the Beaten Path  Main path shows simplest case to follow  What else might happen shown in alternate paths  Showing the possibilities is part of use cases value  Client walks through what happens  Opportunity to ask what if questions & check solution  All details should be made as clear as possible  Easy test generation given this walk through  Good way to check problem understood

 Dealer presses the Deal button  Place card, face up, before each player & dealer  Place card, face up, before each player  Face-down card placed before dealer 4.1 Dealer’s cards total 21 (he has blackjack) ‏ 4.2 Mark all players lost and take their money Player hits blackjack & the dealer does not Mark player won and pay out at 1.5 times bet Play Hand Use Case Is this use case complete? Have the users finished with this interaction? Have we reached a clear end point?

For Next Lecture  Week #5 homework available on web/Angel  As with all weekly assignments, due next Tuesday  Reading for Monday is available on web  How to represent relationships between use cases?  How do we turn use cases into programs?  Can we generate test cases directly from use cases?