Use Case Modeling. Announcement. Agenda. Lecture 3. Please read chapter 4, 6, 8, 9 & 40! Inception overview Evolutionary requirements Use cases

Transcription

1 Use Case Modeling Lecture 3 1 Announcement Please read chapter 4, 6, 8, 9 & 40! 2 Agenda Inception overview Evolutionary requirements Use cases 3 1

2 Inception Stage The initial stage of a project Questions to be asked: What is the vision and the business case for this project? Feasible? Buy and/or build? Rough estimate of cost: $10K, $100K, $1M, Should we proceed or stop? 4 Goals of Inception to do just enough investigation to form a rational, justifiable opinion of the overall purpose and feasibility of the potential new system. Envision the product scope, vision and business case Do the stakeholders have basic agreement on the vision of the project? Is it worth investigating seriously? 5 Artifacts in Inception Artifact Vision and Business Case Use-Case Model Comment Describe the high-level goals and constraints, the business case, and provides an executive summary Describes the functional requirements. During inception, the names of most use cases will be identified, and perhaps 10% of the use cases will be analyzed in detail Supplementary specification Glossary Risk List & Risk Management plan Prototypes and proof-ofconcepts Iteration Plan Other requirements Key domain terminology, and data dictionary Describes the risks (business, technical, resource, schedule) and ideas for their mitigation or response. To clarify the vision, and validate technical ideas Describes what to do in the first elaboration iteration Phase Plan & Software Development plan Development Case Low-precision guess for elaboration phase duration and effort. Tools, people, education, and other resources A description of the customized UP steps and artifacts for this project. In the UP, one always customizes it for the project. 6 2

3 7 Understanding Requirements Capabilities and conditions to which the system and project must conform [Jacobson et al., 1999] Challenges: {find, communicate, record, manage} }the requirements 8 Categorizing Requirements Functional vs. Non-Functional Behavioral features, capabilities vs. everything else Non-Functional requirements may be further divided into quality attributes and constraints Quality Attributes, or -ilities Usability, reliability, supportability, performance (nonfunctional) The quality attributes have a strong influence on the architecture of a system Constraints Hardware, interface, language, legal, 9 3

4 Document Requirements Primarily, in the use case model functional requirements and some other requirements Also, supplementary specifications other requirements Glossary noteworthy terms Vision high-level requirements Business rules requirements or policies that transcend one software project many applications in the same domain may need to conform to them 10 The Use Case Model Writing Requirements in Context Identify user goals, corresponding system functions / business processes Brief, casual, and fully-dressed format Actor System Goal 11 Stories Using a system to meet goals E.g. brief format Process Sale: A customer arrives at a checkout with items to purchase. The cashier uses the POS system to record each purchased item. The system presents a running total and dline-item it details. The customer enters payment information, which the system validates and records. The system updates inventory. The customer receives a Receipt from the system and then leaves with the items. Usually, writing the stories is more important than diagramming a use case model in UML 12 4

5 Definitions Actor: something with a behavior; person, system, organization Scenario: specific sequence of actions and interactions between actor(s) and system (= one story; success or failure) Use Case: collection of related success and failure scenarios describing the actors attempts to support a specific goal 13 Examples Handle Returns Main Success Scenario: A customer arrives at a checkout with items to return. The cashier uses the POS system to record each returned item Alternate Scenarios: If they paid by credit, and the reimbursement transaction to their credit account is rejected, inform the customer and pay them with cash. If the item identifier is not found in the system, notify the cashier and suggest manual entry of the identifier code If the system detects failure to communicate with the external accounting system (etc.) 14 Why use cases? A key attitude in use case work is to focus on the question how can using the system provide observable value to the user, or fulfill their goals? rather than merely thinking of requirements in terms of a list of features or functions Focus on business process, not technology features 15 5

6 Common use case formats Brief: one-paragraph summary, main success scenario When? During early requirements analysis Casual: multiple, informal paragraphs covering many scenarios When? Also early requirements analysis Fully-Dressed: all steps and variations written in detail with supporting sections See When? Before each elaboration starts, do it for a portion of use cases selected for the following elaboration 16 NextGen POS example Start from page 68 of textbook A fully dressed example Use case name Scope & level Primary Actor Stakeholders and Interests Preconditions Success Guarantee Main Success scenario Extensions Special Requirements Technology and Data Variations List Miscellaneous 17 Details Use case name Start with a verb Process Sale Scope The system under design NextGen POS application Level User-goal or subfunction User-goal Primary actor Calls on the system to delivery the service Cashier Stakeholders and interests Who care about this use case and what do they want? Government Tax Agencies: Want to collect tax from every sale 18 6

7 Details Preconditions What must be true on start, and worth telling the reader Cashier is identified and authenticated Success Guarantee What must be true on successful completions, and worth telling the reader Sales is saved. Tax is correctly calculated 19 Details Main Success Scenario (or Basic flow) A typical, unconditional happy path scenario of success Record steps: An interaction between actors A validation (usually by the system) A state change by the system E.g. 1. Customer arrives at a POS checkout 2. Cashiers starts a new sale 3. Cashier enters item identifier 4. System record sales line item Cashier repeats steps 3-4 until indicates done. 5. System presents total with taxes calculated Details Extensions ( or Alternate Flows ) Alternate scenarios of success or failure Scenario branches (success/failure) Longer/more complex than basic flow Branches indicated by letter following basic flow step number, e.g. 3a Two parts: condition, handling E.g. Extensions: 3a. Invalid identifier 1. System signals error and reject entry When possible write the condition as something that can be detected 5a: System can not communication with external tax calculation system 5a: External tax calculation system not working If condition can arise within a range of steps 3-6a: customer asks Cashier to remove an item from the purchase 1. Cashier enters the item identifier for removal from the sale 2. System displays updated running total. At the end of extension handling, by default the scenario merges back with the main success scenario, unless the extension indicates otherwise 21 7

8 Details Special Requirements Related non-functional requirements Touch screen UI on a large flat panel monitor Language internationalization on the text displayed Technology and Data Variation List Varying I/O methods and data formats (non-functional constraints expressed by the stakeholder) Item identifier entered by laser scanner or keyboard Credit account information entered by card reader or keyboard 22 Guidelines 1 Write in an essential UI-Free Style The narrative is expressed at the level of the user s intentions and system s responsibilities Essential Style 1. Administrator identified self. 2. System authenticates identity. 3. Concrete Style 1. Administrator enters ID and passwd in dialog box (see picture 3) 2. System authenticates Administrator. 3. System displays the edit users window (see picture 4) Guideline 2 Write Black-Box use cases Focus on what, not how Good: The system records the sale Bad: The system writes the sale to a database Worse: The system generates a SQL INSERT statement 24 8

9 Guideline 3 Take an actor and actor-goal perspective a set of use-case instances, where each instance is a sequence of actions a system performs that yields an observable result of value to a particular actor Write requirements focusing on the users or actors of a system Focus on understanding what the actor considers a valuable result. 25 How to find use cases (Guideline 4) Choose the system boundary Software, hardware, person, organization Identify the primary actors Goals fulfilled by using the system Identify goals for each actor Define use cases that satisfy goals User-goal level use cases will be one-to-one with user goals Exception: CRUD (Create, Retrieve, Update, Delete) E.g., edit user, delete user, Collapse into a single use case (e.g., Manage Users) 26 Choose the system boundary In the case study, the POS system itself is the system under design; Everything outside of it is outside the system boundary Identify what is outside would help to identify the boundary 27 9

10 Find primary actor and goals Questions to help find actors and goals Is time an actor because the system does something in response to a time event? In addition to human primary actors, are there any external software or robotic systems that call upon services of the system? Actor Cashier Goal Process sales Process rentals Handle returns Manager Start t up Shut down System Admin Sales activity System Add user Modify user Analyze sales and performance data 28 Valid or useful use cases Which of these is a valid use case? Negotiate a Supplier Contract Handle Returns Log In Insert a card in an ATM machine All are valid, but at different level; better question is what is a useful level to express use cases 29 Guideline 5: Tests for Use Cases Boss test Log in does not sounds like something that will make your boss happy The EBP test Elementary Business Process A task performed by one person in one place at one time, in response to a business event, which adds measurable business value and leaves the data in a consistent states, e.g. Approved Credit or Price Order. The size test A use case is very seldom a single action or step

11 Guideline 5 : Tests (cont ed) Applying the tests Negotiate a Supplier Contract Much broader and longer than an EBP Handle returns Ok with the boss. Seems like an EBP. Size is good Log In Not OK with the boss, no measurable business value Insert a card in an ATM machine Single step fail the size test Reasonable violations of the tests It is sometimes useful to write separate subfunction-level use cases representing subtasks or steps within a regular EBPlevel use case. 31 Applying UML: Use Case Diagram system boundary NextGen communication Cashier Process Sale Handle Returns alternate notation for a computer Payment system acto Authorization Service actor Process Rental «actor» Tax Calculator «actor» Sales Activity System System Administrator Cash In Analyze Activity Manage Security Manage Users... «actor» Accounting System «actor» HR System use case Use case diagram is an Excellent picture of the system context. It serves as a communication tool that summarizes the behavior of a system and its actors 32 Diagram notation For a use case context diagram, limit the use cases to user-goal level use cases. Show computer system acto with an alternate notation to human actors. NextGen Cashier Process Sale... «actor» Payment Authorization Service primary actors on the left supporting actors on the right 33 11

12 Alternate actor notation NextGen Process Sale... «system» Payment Payment Authorization Authorization Service Service «actor» Payment Authorization Service Some UML alternatives to illustrate external actors tha other computer systems. The class box style can be u for any actor, computer or human. Using it for compute actors provides visual distinction. 34 The include relationship Partial behavior that is common across several use cases E.g., PayByCredit occurs in several use cases: Process Sale, Process Rental, and so on Solution: represent as a separate use case Refactoring and linking text to avoid duplication (Larman) Use include when you are repeating yourself in two or more separate use cases and you want to avoid repetition (Fowler) 35 Example of include relationship UC1: Process Sale Main Success Scenario: 1. Customer arrives at a POS checkout with goods and/or services to purchase. 7. Customer pays and System handles payment Extensions: 7b. Paying by credit: Include Handle Credit Payment. 7c. Paying by check: Include Handle Check Payment UC7: Process Rental Extensions: 6b. Paying by credit: Handle Credit Payment

13 Included use case UC12: Handle Credit Payment Level: subfunction Main Success Scenario 1. Customer enters their credit account information 2. System sends payment authorization request to an external payment authorization ti service system and request payment approval Extensions: 2a. System detects failure to collaborate with external system: 1. system signals error to cashier 2. Cashier asks customer for alternate payment 37 The include relationship To decompose an overwhelmingly long use case into subunits to improve comprehension Using include with asynchronous event handling Eg. UC8: Process self-help check out Main Success Scenario 1 Extensions: a* At any time, customer selects printing help: Present Printing Help 38 Model include relationship in use case diagram NextGen POS Process Sale Some case tool (Visio) use <<uses>> instead Cashier «include» «include» «include» «actor» Accounting System Customer UML notation: the base use case points to the included use case Handle Check Payment «include» Handle Cash Handle Credit Payment Payment «include» «include» Process Rental «actor» Credit Authorization Service Handle Returns Manage Users

14 The extend relationship How to add an extension to a use case that is frozen or too complicated? Solution: use extend to relate to an addition use case Describe where and under what condition the additional use case extends the behavior of the base use case (use extension point) 40 Example of extend relationship UC1: Process Sale (the base use case) Extension Points: VIP Customer, step1. Payment, step 7. Main Success Scenario: 1. Customer arrives at a POS checkout with goods and/or services to purchase 7. Customer pays and system handles payment UC15: Handle Gift Certificate Payment (the extending use case)... Trigger: Customer wants to pay with gift certificate Extension Points: Payment in Process Sale Level: subfunction Main Success Scenario: 1. Customer gives gift certificate to Cashier 2. Cashier enters gift certificate ID 41 Extend relationship in use case diagram Process Sale Extension Points: Payment VIP Customer «extend» Payment, if Customer presents a gift certificate Handle Gift Certificate Payment UML notation: 1. The extending use case points to the base use case. 2. The condition and extension point can be shown on the line. Handle Gift Certificate payment use case could be expressed in include relationship as well Handle Gift Certificate could simply have been recorded by adding it as an extension in the Extensions section of Process Sale 42 14

15 Extend vs. include relationships Direction of the relationship For include relationship, the event triggering the target use case is described in the flow of event of the source use case (user-goal level) For extend relationships, the event triggering the source (the extending) use case is described in the source use case( sub-function level). The base use case have no knowledge of the extending use case The purpose of adding include and extend relationships is to reduce or remove redundancies from the use case model 43 Heuristics for extend and include relationship Use extend relationships for exceptional, optional or seldom-occurring behavior Use include relationship for behavior that is shared across two or more use cases Do not over structure t the use case model. A few longer use case (two pages long) are easier to understand and review than many short ones (eg. 10 lines long) Always use the include relationship between use cases, rather than a mixture of include and extend. 44 Requirements in context Traditional detailed, low-level function lists ID FEAT1.9 FEAT2.4 Feature The system shall accept entry of item identifiers The system shall log credit payments to the accounts receivable system Use case organize a set of requirements in the context of typical scenarios of using a system. Improves cohesion and comprehension to group requirement by user-oriented scenarios 45 15

16 Requirements in context High-level system feature lists are acceptable Summary of System features Sales capture Payment authorization Manage users When are detailed feature lists appropriate rather than use case Application server, database products, other middleware or back-end systems need to be primarily considered and evolved in terms of features 46 How to work with use cases in iterative methods Use case driven development Functional requirements are primarily recorded in use cases Use cases are important to iterative planning Use case realizations drive the design Use cases influence the organization of user manuals Test cases correspond to use cases Create UI shortcut for more common scenarios of important use cases 47 Thanks 48 16