University of Toronto at Scarborough © Kersti Wain-Bantin CSCC40 Use Case 1 what are use cases? “A specification of sequences of actions, including variant sequences and error sequences, that a system, subsystem or class can perform by interacting with outside actors” The UML Reference Manual. Use cases are a way of capturing requirements. You specify: actors - roles played by people or things that use the system use cases - things the actors can do with the system relationships - a meaningful relationships between actors and uses cases system boundary - a box drawn around the use cases to denote the edge or boundary of the system being modeled. Use cases are always started by an actor and are always written from the point of view of the actor. Arlow, Neustadt

University of Toronto at Scarborough © Kersti Wain-Bantin CSCC40 Use Case 2 Requirements List Use Case Model Candidate Requirements Elicit requirements Project Initiation Document Select requirements Develop use cases Requirements Analyst (and Architect) Glossary In Inception and Elaboration Phases

University of Toronto at Scarborough © Kersti Wain-Bantin CSCC40 Use Case 3 Requirements capture and modelling Requirements Team Project Initiation Document Requirements List Use Case Model Initial System Architecture Interface Prototypes Glossary Deliverables Input In Inception and Elaboration Phases

University of Toronto at Scarborough © Kersti Wain-Bantin CSCC40 Use Case 4 use cases do something of value to an actor: calculate a result generate a new object change the state of an object can be high level (e.g. process a loan) can be more specific (e.g. complete loan application) are used: to document requirements as guidelines for system testing use case diagrams contain: use cases actors relationships

University of Toronto at Scarborough © Kersti Wain-Bantin CSCC40 Use Case 5 an actor is… a coherent set of roles that the user of use cases plays when interacting with use cases human, department, hardware device, another system… not part of the system (lives outside the system) connected by association with the use case by sending and/or receiving message(s)

University of Toronto at Scarborough © Kersti Wain-Bantin CSCC40 Use Case 6 use case diagrams capture the intended behavior of a system without having to specify how that behavior is implemented model the context and requirements of a system

University of Toronto at Scarborough © Kersti Wain-Bantin CSCC40 Use Case 7 documenting use cases name of use case purpose actors stakeholders and interests description relationships to other use cases flow of events: trigger basic flow alternative flows exceptional flows pre-conditions post-conditions

University of Toronto at Scarborough © Kersti Wain-Bantin CSCC40 Use Case 8 Use case: displayShoppingBasket ID:UC11 Actors:customer Preconditions: 1.the customer is logged on the system Flow of Events: 1. the use case starts when the customer selects “display basket” 2. if there are not items in the basket 2.1 the system informs the customer there are no items in the basket yet 2.2 the use case terminates 3. the system displays a list of all items in the customer’s shopping basket giving their product id and name, quantity and item price Postconditions: Alternative flow 1: 1. at any time the customer may leave the shopping basket display screen Postconditions: Alternative flow 2: 1. at any time the customer may leave the system Postconditions: Alternative flow 3: sample use case documentation Arlow, Neustadt

University of Toronto at Scarborough © Kersti Wain-Bantin CSCC40 Use Case 9 actor generalization listProducts orderProducts acceptPayment sales system customer sales agent calculateCommission listProducts orderProducts acceptPayment sales system purchaser sales agent calculateCommission customer before  after  Arlow, Neustadt

University of Toronto at Scarborough © Kersti Wain-Bantin CSCC40 Use Case 10 bookAppointment addNewPatient clinic system patient new patient revisePatientInfo returning patient actor / use case multiplicity 1 * * * * *

University of Toronto at Scarborough © Kersti Wain-Bantin CSCC40 Use Case 11 parent use case child use cases use case generalization findProduct findBookfindCD sales system customer child use cases may: inherit features from parent use case add new features override (change inherited features) Arlow, Neustadt

University of Toronto at Scarborough © Kersti Wain-Bantin CSCC40 Use Case 12 use case generalization

University of Toronto at Scarborough © Kersti Wain-Bantin CSCC40 Use Case 13 include relationship common behavior can be a use case of it’s own

University of Toronto at Scarborough © Kersti Wain-Bantin CSCC40 Use Case 14 include relationship changeEmployeeDetails viewEmployeeDetails deleteEmployeeDetails findEmployeeDetails personnel system manager > Arlow, Neustadt

University of Toronto at Scarborough © Kersti Wain-Bantin CSCC40 Use Case 15 add optional or conditional behavior to base case extend relationship

University of Toronto at Scarborough © Kersti Wain-Bantin CSCC40 Use Case 16 conditional extension

University of Toronto at Scarborough © Kersti Wain-Bantin CSCC40 Use Case 17 showing system context

University of Toronto at Scarborough © Kersti Wain-Bantin CSCC40 Use Case 18 example

University of Toronto at Scarborough © Kersti Wain-Bantin CSCC40 Use Case 19