Unified Process and Use Case Diagrams Lecture Notes 3

Unified Process and Use Case Diagrams 1.21 Main Success Scenario (or Basic Flow): • Customer arrives at POS checkout with goods and/or services to purchase. • Cashier starts a new sale. • Cashier enters item identifier. • System records sale line item and presents item description, price, and running total. Price calculated from a set of price rules. Cashier repeats steps 3-4 until indicates done. • System presents total with taxes calculated. • Cashier tells Customer the total, and asks for payment. • Customer pays and System handles payment. (5) System logs completed sale and sends sale and payment information to the external Accounting system (for accounting and commissions) and Inventory system (to update inventory). (6) System presents receipt. (7) Customer leaves with receipt and goods (if any). Extensions (or Alternative Flows): *a. At any time, Manager requests an override operation: 1) System enters Manager-authorized mode. 2) Manager or Cashier performs one Manager-mode operation. e.g., cash balance change, resume a suspended sale on another register, void a sale, etc. 3) System reverts to Cashier-authorized mode. *b. At any time, System fails: To support recovery and correct accounting, ensure all transaction sensitive state and events can be recovered from any step of the scenario. 1) Cashier restarts System, logs in, and requests recovery of prior state. 2) System reconstructs prior state. 2a. System detects anomalies preventing recovery: 1) System signals error to the Cashier, records the error, and enters a clean state. 2) Cashier starts a new sale. 1a. Customer or Manager indicates to resume a suspended sale. 1) Cashier performs resume operation, and enters the ID to retrieve the sale. 2) System displays the state of the resumed sale, with subtotal. 2a. Sale not found. 1.22 Object Oriented Analysis and Design 1) System signals error to the Cashier. 2) Cashier probably starts new sale and reenters all items. 3) Cashier continues with sale (probably entering more items or handling payment). 2-4 a. Customer tells Cashier they have a tax-exempt status (e.g., seniors, native peoples) 1) Cashier verifies, and then enters tax-exempt status code. 2) System records status (which it will use during tax calculations) 3a. Invalid item ID (not found in system): 1) System signals error and rejects entry. 2) Cashier responds to the error: 2a. There is a human-readable item ID (e.g., a numeric UPC): 1) Cashier manually enters the item ID. 2) System displays description and price. 2a. Invalid item ID: System signals error. Cashier tries alternate method. 2b. There is no item ID, but there is a price on the tag: 1) Cashier asks Manager to perform an override operation. 2) Managers perform override. 3) Cashier indicates manual price entry, enters price, and requests standard taxation for this amount (because there is no product information, the tax engine can‟t otherwise deduce how to tax it) 2c. Cashier performs Find Product Help to obtain true item ID and price. 2d. Otherwise, Cashier asks an employee for the true item ID or price, and does either manual ID or manual price entry (see above). 3b. There are multiple of same item category and tracking unique item identity not important (e.g., 5 packages of veggie-burgers): 1) Cashier can enter item category identifier and the quantity. 3c. Item requires manual category and price entry (such as flowers or cards with a price on them): 1) Cashier enters special manual category code, plus the price. 3-6 a: Customer asks Cashier to remove (i.e., void) an item from the purchase: This is only legal if the item value is less than the void limit for Cashiers, otherwise a Manager override is needed. 1) Cashier enters item identifier for removal from sale. 2) System removes item and displays updated running total. 2a. Item price exceeds void limit for Cashiers: 1) System signals error, and suggests Manager Override. Unified Process and Use Case Diagrams 1.23 2) Cashier requests Manager Override, gets it, and repeats operation. 3-6 b. Customer tells Cashier to cancel sale: 3-6c. Cashier suspends the sale: 1) Cashier cancels sale on System. 1) System records sale so that it is available for retrieval on any POS register. 2) System presents a “suspend receipt” that includes the line items, and a sale ID used to retrieve and resume the sale. 4a. The system supplied item price is not wanted (e.g., Customer complained about something and is offered a lower price): 1) Cashier requests approval from Manager. 2) Manager performs override operation. 3) Cashier enters manual override price. 4) System presents new price. 5a. System detects failure to communicate with external tax calculation system service: 1) System restarts the service on the POS node, and continues. 1a. System detects that the service does not restart. 1) System signals error. 2) Cashier may manually calculate and enter the tax, or cancel the sale. 5b. Customer says they are eligible for a discount (e.g., employee, preferred customer): 1) Cashier signals discount request. 2) Cashier enters Customer identification. 3) System presents discount total, based on discount rules. 5c. Customer says they have credit in their account, to apply to the sale: 1) Cashier signals credit request. 2) Cashier enters Customer identification. 3) Systems applies credit up to price=0, and reduces remaining credit. 6a. Customer says they intended to pay by cash but don‟t have enough cash: 1) Cashier asks for alternate payment method. 1a. Customer tells Cashier to cancel sale. Cashier cancels sale on System. 7a. Paying by cash: 1) Cashier enters the cash amount tendered. 2) System presents the balance due, and releases the cash drawer. 3) Cashier deposits cash tendered and returns balance in cash to Customer. 4) System records the cash payment. 1.24 Object Oriented Analysis and Design 7b. Paying by credit: 1) Customer enters their credit account information. 2) System displays their payment for verification. 3) Cashier confirms. 3a. Cashier cancels payment step: 1) System reverts to “item entry” mode. 4) System sends payment authorization request to an external Payment Authorization Service System, and requests payment approval. 4a. System detects failure to collaborate with external system: 1) System signals error to Cashier. 2) Cashier asks Customer for alternate payment. 5) System receives payment approval, signals approval to Cashier, and releases cash drawer (to insert signed credit payment receipt). 5a. System receives payment denial: 1) System signals denial to Cashier. 2) Cashier asks Customer for alternate payment. 5b. Timeout waiting for response. 1) System signals timeout to Cashier. 2) Cashier may try again, or ask Customer for alternate payment. 6) System records the credit payment, which includes the payment approval. 7) System presents credit payment signature input mechanism. 8) Cashier asks Customer for a credit payment signature. Customer enters signature. 9) If signature on paper receipt, Cashier places receipt in cash drawer and closes it. 7c) Paying by check… 7d) Paying by debit… 7e) Cashier cancels payment step: 1) System reverts to “item entry” mode. 7f) Customer presents coupons: 1) Before handling payment, Cashier records each coupon and System reduces price as appropriate. System records the used coupons for accounting reasons. 1a) Coupon entered is not for any purchased item: 1) System signals error to Cashier. 9a) There are product rebates: 1) System presents the rebate forms and rebate receipts for each item with a rebate. Unified Process and Use Case Diagrams 1.25 9b) Customer requests gift receipt (no prices visible): 1) Cashier requests gift receipt and System presents it. 9c) Printer out of paper. 1) If System can detect the fault, will signal the problem. 2) Cashier replaces paper. 3) Cashier requests another receipt. Special Requirements: • Touch screen UI on a large flat panel monitor. Text must be visible from 1 meter. • Credit authorization response within 30 seconds 90% of the time. • Somehow, we want robust recovery when access to remote services such the inventory system is failing. • Language internationalization on the text displayed. • Pluggable business rules to be insertable at steps 3 and 7. Technology and Data Variations List: *a. Manager override entered by swiping an override card through a card reader, or entering an authorization code via the keyboard. 3a. Item identifier entered by bar code laser scanner (if bar code is present) or keyboard. 3b. Item identifier may be any UPC, EAN, JAN, or SKU coding scheme. 7a. Credit account information entered by card reader or keyboard. 7b. Credit payment signature captured on paper receipt. But within two years, we predict many customers will want digital signature capture. Frequency of Occurrence: Could be nearly continuous. Open Issues: • What are the tax law variations? • Explore the remote service recovery issue. • What customization is needed for different businesses? • Must a cashier take their cash drawer when they log out? • Can the customer directly use the card reader, or does the cashier have to do it? Meaning of the sections Preface elements (1) Scope • It bounds the system under design 1.26 Object Oriented Analysis and Design • Since usecase describes use of one software it is known as system use case • Use cases describe how a business is used by its customers and partners. • The enterprises level process description is called Business Use Case, which is an example of wide applicability of use cases. (2) Level Use cases are classified as • User goal level or • Subfunction level in Cockburn‟s system User goal level The user goal level describes the scenarios to fulfill the goals of a primarily actor It corresponds to elementary Business Process (EBP) in Business Process Engineering. Subfunction level A subfunction level use case describes substeps to support a user goal. It is created to eliminate duplicate substeps shared by several regular use cases Example: Pay by credit is a subfunction use case which is shared by many regular use cases Primary Actor It calls upon system services to fulfill a goal Stakeholders and InterestList • This list is more important and practical • It suggests and bounds what the system has to do. “The system operates a contract between stake holders, with the use cases detailing the behavioral parts of that contract”. The use case, as the contract for behavior, captures all and only the behaviors related to satisfying stakeholder‟s interest. The stakeholder interest viewpoint provides a through and methodical procedure for discovering and recording all required behaviors. Stakeholders and Interests • Cashier: wants accurate, fast entry and no payment errors, as cash drawer shortages are deducted from his/her salary. Unified Process and Use Case Diagrams • Salesperson : wants sales commission updated • ……. 1.27 Preconditions and Success Guarantees (Post conditions) • Before beginning a scenario, preconditions state what must always be true. • Preconditions are assumed to be true and are not tested within use case • Example: “The system has power” Post conditions (Success Guarantees) The post condition must be true on successful completion of use case (ie, Main success scenario or some alternate path) Pre conditions: Cashier is identified and authenticated. Success Guarantee: (post condition) Sale is saved Tax is correctly calculated Accounting and inventory are updated Commissions recorded Receipt is generated Main Success Scenario and Steps (or Basic Flow) It is called “ happy path” scenario, Basic flow or typical flow. Main Success Scenario describe a typical success path that satisfies the interests of stakeholders. It does not have any conditions or branching. All conditions and branching statements can be present in Extension section. The scenario has three kinds of steps (i) An interaction between actors (ii) A validation (iii) A state change by the system (example: recording or modifying something) The actor‟s names are always written in capital letters for ease of identification. Main Success Scenario 1) Customer arrives at a POS checkout with items to purchase 2) Cashier starts a new sale 3) Cashier enters item identifier 4) ……Cashier repeats steps 3- 4 until indicates done 5) …… 1.28 Object Oriented Analysis and Design Extensions ( or Alternate Flows) • Extensions comprise the majority of text • They are more complex than Main Success Scenario section because they indicates all scenarios success and failure. • They are notated with respect to its steps 1…..N • An extensions has two parts ◦ the condition and ◦ the handling Extension handling may be in one step or includes a sequence with a range of steps 3-6 a: Customer asks Cashier to remove an item from the purchase: 1) Cashier enters item identifier for removal from the sale. 2) System displays updated running total. If the extension is not halting, the scenario merges back with the main success scenario at the end of extension handling. Some complex extension points can be had as a separate use case. Failures within the extension can also be demonstrated. 7b. Paying by credit 1) Customer enters their credit account information 2) System sends payment authorization request to an external payment Authorization Service system, and requests payment approval. 2a) System detects failure to collaborate with external system 1) System signals error to cashier 2) Cashier asks customer for alternate payment. The labels *a, *b,… can be used to describe an extension condition. Sometimes, a usecase branches to perform another use cases scenario. Example: In the Process Sale use case, we use the Find Product help. The second use case us shown with underlining. 3a. Invalid item ID (not found in system): 1) System signals error and rejects entry. 2) Cashier responds to the error: 2a. ….. 1. 2c. Cashier performs Find Product Help to obtain true item ID and price. Unified Process and Use Case Diagrams 1.29 Special Requirements • The non functional requirements • Quality attributes or • Constraints Relates specifically to use case are mentioned as special requirements The quality may be of • Performance • Reliability • Usability • Design constraints etc. • Touch screen on a large flat panel monitor • Text must be visible from 1 meter • Credit authorization response within 30 seconds 90% of the time. • Language internationalization on the text displayed • Pluggable business rules to be insertable at steps 2 and 6. Technology and Data Variations List There may be technology variations in how things are done. Example: One stakeholders says “The POS system must support credit account input using a card reader and the keyboard”. Another stakeholder may prefer some other input/output This list is the place to record such variations. Technology and Data Variations List 3a. Item identifier given by laser scanner or keyboard 3b. item identifier may be any UPC, EAN, JAN or SKU coding scheme. 7a. Credit account information entered by card reader or keyboard. 7b. Credit payment signature captured on paper receipt. After sometime it may be digital signature capture. Other format A two column or conversational format where intersections are between actors and the system. It is given by Wirfs-Brock and promoted by Constantine and Lockword. 1.30 Object Oriented Analysis and Design The same example is shown in two column format. Use Case UC 1: Process Sale Primary Actor:…. ….. as before …… Main Success Scenario: Actor Action (or intention) System Responsibility 1. Customer arrives at a POS checkout with goods and /or services to purchase 2. Cashier starts a new sale 3. Cashier enters item identifier 4. records each sale line item and presents item description and running total Cashier repeats 3-4 until indicates done. 5. Presents total with taxes 6. Cashier tells customer the total and asks for payment 7. Customer pays 8. Handles payment 9. Logs all completed sale & send information to the external accounting and inventory systems. System presents receipt Some prefer one column style and some prefer two column style. Some guidelines are followed in the styles. 1) Guidelines – Write in an Essential is to „log in‟ a) New Improved When the goal of cashier is to „log in‟. Instead of thinking of GUI, dialog box, user ID and password, use keyboards and mice with biometric readers for fingerprint. b) Essential style writing Here use cases are written in essential style The guidelines is “Keep the user interface out focus on intent” c) Contrasting Examples …… 1) Administrator identifies self Unified Process and Use Case Diagrams 1.31 2) System authenticates identity 3) …….. (i) Identification (ii) Authentication Concrete style The concrete use cases are used as aid to concrete or detailed GUI design work. The text may • Show window screen shots • Discuss window navigation • GUI widget manipulation etc Example ……. 1) Administrator enters ID and password in dialog box 2) System authenticates Administrator 3) System displays “edit users” window. 2) Guideline: Write Terse Use Cases. Terse use cases are written by deleting noise words. Example: small changes like “ System Authenticates” than “The system authenticates”. 3) Guideline: Write Black Box Use Cases Black box use cases are recommended because they do not describe internal workings of the system, its components or design. Here, in black box uses “what the system must do” (function requirement) is specified rather than “how it will do”. Black Box style The system records the sale Not The system writes the sale to a database Or The system generates a SQL INSERT statement for sale.. 4) Guideline: Take an Actor and Actor – Goal perspective 1) Write requirements that focus on users or actors of a system with their goals. 2) Focus on understanding what the actor considers a valuable result.