190 likes | 214 Views
what are use cases?. Arlow, Neustadt. “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.
E N D
what are use cases? Arlow, Neustadt “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.
In Inception and Elaboration Phases Requirements Analyst (and Architect) Project Initiation Document Elicit requirements Glossary Candidate Requirements Select requirements Requirements List Develop use cases Use Case Model
Deliverables In Inception and Elaboration Phases Use Case Model Requirements Team Requirements List Input Project Initiation Document Requirements capture and modelling Interface Prototypes Initial System Architecture Glossary
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) use case diagrams • contain: • use cases • actors • relationships • are used: • to document requirements • as guidelines for system testing
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)
use case diagrams model the context and requirements of a system capture the intended behavior of a system without having to specify how that behavior is implemented
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
sample use case documentation Arlow, Neustadt • Use case:displayShoppingBasket • ID: UC11 • Actors: customer • Preconditions: • 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:
actor generalization Arlow, Neustadt sales system listProducts orderProducts customer acceptPayment sales agent calculateCommission sales system listProducts orderProducts purchaser acceptPayment before after calculateCommission customer sales agent
actor / use case multiplicity clinic system * * bookAppointment patient 1 * addNewPatient returning patient new patient revisePatientInfo * *
use case generalization Arlow, Neustadt sales system parent use case findProduct customer findBook findCD child use cases • child use cases may: • inherit features from parent use case • add new features • override (change inherited features)
include relationship common behavior can be a use case of it’s own
include relationship Arlow, Neustadt personnel system changeEmployeeDetails <<include>> viewEmployeeDetails <<include>> findEmployeeDetails manager <<include>> deleteEmployeeDetails
extend relationship add optional or conditional behavior to base case