USE CASE MODELLINGUse cases help ..Slide 3PowerPoint PresentationSlide 5Goals of use casesUse case scenariosUse case scenario - exampleSlide 9Slide 10Slide 11Slide 12Slide 13Slide 14Slide 15Slide 16Slide 17Slide 18Slide 19Slide 20Slide 21Slide 22Slide 23Slide 24Slide 25Slide 26Slide 27Slide 28Slide 29Slide 30Slide 31Slide 32Slide 33USE CASE MODELLING•A use case is a scenario that describes the use of a system by an actor to accomplish a specific goal. •An actor is a user playing a role with respect to the system. - people, other systems.•Scenario A sequence of steps that describe the interactions between an actor and the system. •The use case model consists of the collection of all actors and all use cases.Use cases help ..·Capture the system's functional requirements from the users' perspective ·Actively involve users in the requirements-gathering process ·Provide the basis for identifying major classes and their relationships ·Serve as the foundation for developing system test casesUSE CASE MODELLING-functional reqts., analysis phase- what a system does: functions represented as use cases- Actor: external agent that interacts with the system, exchanges info. with the system (user, sub-system, etc.) - a role played by userNote: a use case represents a complete functionality. –view of system behavior from an external person’s viewpoint–effective tool for validating requirements–an effective communication tool–basis for a test plan–basis for user manualDeveloping the use cases in not difficult; ensuring that you have them all is murder.•Use Case Diagrams–Actor–Line: actor communicates with or is associated with use-caseCustomer Loses a Tape•Use Case relationships:–<<uses>>: one use case always involves the steps of another–<<extends>>: under certain conditions, a use case follows a variantCustomerLoses a TapeBuy a Tape<<uses>>CustomerVIP Loses a Tape<<extends>>Goals of use cases•Interactions that provide value to actors•No implementation specific language–No assumptions about how the use case may be realized in code or user-interface–Note: use-cases drive the whole life-cycle, and they get refined – implementation specific use-cases•User-appropriate level of detail–General at requirements gathering stage•User-appropriate volume–Large systems: no more than 70-80 use cases–Small number of use cases – forces abstractionUse case scenarios•a realization of a use case.•Instance of an use case that effectively tests one path through a use case•To demonstrate whether a use case accurately reflects user needs•useful during testingExample:Use case name: Determine benefits eligibility for enrolleeSteps:1. This use case starts when the social worker enters the enrollee’s name and employment situation.2. This use case ends when the system responds with a determination of whether the enrollee is eligible for benefits and the financial extent of benefits.Alternative path:In step 1, if the enrollee has applied for benefits previously, based on the enrollee’s own disclosure, the social worker enters the enrollee’s name to search for his or her previous recordsUse case scenario - exampleExample of scenario1. The social worker asks Edward Trueman if he has applied previously for and/or received benefits. And Mr. Trueman replies that he has applied previously.2. The social worker provides Mr. Trueman’s name as search criterion3. The system provides Mr. Trueman’s previous records, which state that he applied for benefits on Dec 9th, 1997, and was determined to be ineligible on Dec 9th 1997 because of his current part-time employment status at Boeing Aerospace in the capacity of assembly line worker.Registration forspecial classClass registrationPrereq coursesnot completedStudent BillingStudentBursar’sofficeRegistrationClerkInstructor<<Extends>> <<Extends>>Use-Case DiagramExtends: extension to or variation of a use-case that exists in its own rightOrder FoodHire EmployeeReordersuppliesProducemgt. reportsTrack salesand inv. data<<uses>><<uses>>CustomerApplicantSupplierService PersonManagerUses: factors common behavior amongst multiple use-cases into a generalized use-case.Step 1: Identifying Actors and Use Cases–From context diagram, workflow diagramStep2:Construct Use Case Model–System scope and boundary in terms of use cases and actors–partitioned into sub-systemsStep 3:Use Case sequence of actionsStep4: Identifying use case dependenciesStep5: Use case alternate course of actionsStep6: Finding Potential Objects–Nouns in use caseStep7: Selecting proposed Objects•Class Diagram (Object Association Model, Object Relationship Model)•Finding the actors-Ask client and domain experts how system will be used- Who will perform the obvious tasks? Secondary tasks of maintenance and administration? Interact with other systems?-Clear and differentiated names (eg. manager vs supervisor)•Recording the use cases-For each actor, what interactions /”results” they require of the system –each is a use case•Not overly precise yet, just note them down–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 system about–Does actor need to be informed when something happens–Does actor help initialize or shut down the systemExample: video store system Actor: Customer- What tasks does the actor want the system to perform?-Find movie to rent, rent tape, return tape, reserve tape-What information must the actor provide to the system?-Name, address, membership#, film name-Are there events that the actor must tell system about?-Change of address-Does actor need to be informed when something happens?-Reserved tape is ready to be rented-Does actor help initialize or shut down the system-noExample: video store system Resulting use cases:•Customer joins and provides contact information including name, address, phone#, credit information, spouse and kids•Customer browses system looking for a tape to rent•Customer comes to store looking for a specific tape to rent•Customer rents a tape•Customer returns a tape•Customer reserves a tape•Customer is contacted when a reserved tape is readyNote: simple phrases, without much details initially.•Finding the actors-Ask client and domain experts how system will be used- Who will perform the obvious tasks? Secondary tasks of maintenance and administration?