Unified Process and Use Case Diagrams Lecture Notes 4

1.32 Object Oriented Analysis and Design 5) Guideline: How to find Use Cases The procedure is 1) Choose the system boundary (software or hardware application) 2) Identify primary actors 3) Identify goals for each primary actor 4) Define use cases that satisfy user goals Step 1: Choose system boundary The boundary of the system. The external primary actors and supporting actors. Step 2 and 3: Find Primary Actors and Goals. • The following are some questions to find the Actors and Goals. 1) Who starts and stops the system? 2) Who does system administration? 3) Who evaluates system activity or performance? 4) Who evaluates log? Etc • Organise Actors and Goals There are two approaches 1) After getting results, draw them in use case diagram, naming the goals as use cases. 2) Write actor goal list, review and refine it then draw use case diagram Sales Activity System Actor Goal Actor Cashier Process sales Process rentals handle returns cash in cash out • Goals Manager startup shutdown Ask about Actor Goals rather than use cases. Finding actors and their goals helps us to identify use cases. Its better to ask. “What are your goals whose results have measurable value?” that to ask “What do you do?” • Event Analysis – Another way to find Actors and Goals Identifying external events helps to find use cases. Example External Event From Actor Goal/ Use Case Enter sale line item Cashier Process a sale Enter payment Cashier or Customer Process a sale Unified Process and Use Case Diagrams 1.33 Step 4: Define use cases • Define one use case for each user goal • Start the name of use cases with a verb. Example: Goal – Process a sale Use case – Process a sale Another way CRUD – Create, Retrieve, Update delete separate goals into on CRUD use case Manage Users – Edit user Delete User etc. (6) Guideline: Tests that help to find useful use cases: 1) BOSS test 2) EBP test 3) The size test BOSS test The use cases that fail in BOSS test are at some low goal level. It is not the desirable level of focus for requirements analysis. Example: BOSS asks “ what have you been doing all day?” Reply “ Logging in!” If the boss is not happy then the use case fails in BOSS test. BOSS test failing usecases need not be ignored. User authentication may fail boss test but it is important and difficult. EBP Test Elementary business process. It is defined as “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 consistence state”. Example: Approve credit or price order. The EBP takes five or ten steps i.e., a task done during a single session. The size test A use case is not always a single step. For example: „Enter an item ID‟ 1.34 Object Oriented Analysis and Design Use case seem to be single line but consists of a series of steps. Example: Applying tests 1) Negotiate a supplier contract Broader and longer than EBP. Can be modeled as business use case than system use case. 2) Handle returns Ok with boss test Seems like EBP Size is good ◦ ◦ Log In Boss not happy so fails boss teat. Move price on game board Single step. So fails size test. Applying UML: Use case Diagrams • The names of use cases and actors • The relationship between them are shown by UML diagrams. A use case diagram shows an excellent picture of system context. Figure 1.14 Partial Use case context diagram Unified Process and Use Case Diagrams 1.35 The context diagram in UML shows the boundary of a system that lies outside it. The use case diagram is a communication tool that summarizes the behavior of a system and its actors. Guidelines (1) The notation for actors Human actors – stick figures Computer system actors – actor box with single character bracket. Example: Figure 1.15 a) Notation of actor Some prefer external computer system actors like. Figure 1.16 b) Actor Notation (2) Guide line Keep the diagram short and simple. An organization cannot spend too much time on writing use case. Applying UML: Activity Diagrams The UML has an activity diagram. It is used to visualize work flows and business processes. It also describes complex work flows and concurrent actions. 1.36 Object Oriented Analysis and Design Benefits of Use cases • Use cases are simple and widely understood. • Use cases focus on key actors, their goals and common tasks. Example: Another example is “Monopoly Game”. The typical use case in monopoly game is “Play Monopoly Game”. Figure 1.17 Monopoly Game The Use case Text is given by Use case UC1 : Play Monopoly Game Scope : Monopoly application Level : User goal Primary actor : Observer Stakeholders and interest : Observer : Wants to easily observe the output of the game simulation. Main success scenario: 1) Observer requests new game initialization, enters number of players. 2) Observer starts play 3) System displays game trace for next player move. Repeat step 3 until a winner or observer cancels. Extensions: *a. At any time, system fails: 1) Observer restarts system 2) System detects prior failure, reconstruct state and prompts to continue 3) Observer chooses to continue Special requirements Provide both graphical and text trace modes. Unified Process and Use Case Diagrams 1.37 Additional Examples for use cases: Figure 1.18 Use Case Diagram of a HelpDesk This use case diagram shows the relationship among actors and use cases within a system. Process: How to work with use cases in Iterative methods? The use cases driven development includes • Functional Requirements • Use cases are part of iterative planning • Design is driven by use cases • Organization manuals influence use cases • Functional or system testing deals with scenarios of use cases • UI or shortcuts are created for common tasks. Use Cases in Inception During inception all the use cases are not written in fully dressed format. Some of the use cases are identified according to magnitude, complexities. Use Cases in Elaboration In elaboration user goals are refined and 80 - 90% of use cases are written details. Use case relationship Links exist between actors and use cases. Several relationships exists between use cases like: 1) Include 2) Use case generalization 3) Extend 1.38 Object Oriented Analysis and Design Include When we have a chunk of behavior that is similar across more than one use case and we don‟t want to copy the description of the behavior. Example: Both analyze Risk and Price require to value the deal. Instead of having a fair chunk of writing and copying it again, we can write a separate value deal use case and refer it from the original use cases. Use case generalization When we have one use case that is similar to another use cases but does a bit more then we use, case generalization. Example: The basic use case is capture deal. One special case is when the limit is exceeded i.e., the maximum amount the trading organization has established for a particular customer. Extend The third relationship called as extend is similar to generalization but with more rules to it. The extending use case may add behavior to the use case, but it must declare certain “extension points” and the extending use case may add additional behavior only at those extension points. Extend relationship A use case may have many extension points and an extending use case may extend one or more of these extension points. Apply the following rules Use include when you are repeating yourself in two or more separate use cases and you want to avoid repetition. Use generalization when you are describing a variation on normal behavior and you wish to describe it casually. Unified Process and Use Case Diagrams 1.39 Use extend when you are describing a variation on normal behavior and you wish to use the more controlled form, declaring your extension points in your base use case. Business and system Use cases Two different use cases are there. They are • System Use Case • Business Use Case A system use case is dealing with the interaction with the software. Business use case discusses how a business responds to a customer or event. Useage of Use Case Most of the use case will be generate during the phase of the project but they will be uncovered as we proceed the project. Every use case is a potential requirement and, we can plan it only after we capture a requirement. Use cases represent an external view of the system. 1.7 RELATING USE CASES Use cases can be related to each other. Example: Regular use cases like Process Sale. Process Rental can have subfunctions use case like HandleCredit Payment. Relationship among use cases • Improves communication and comprehension of use cases • Reduces duplication of text • Improves management of use case document Writing the use case text is highly essential. This improves comprehension and reduces duplication. Relationships The common relationships present are (i) include relationship (ii) extend relationship and (iii) generalize relationship 1.40 Object Oriented Analysis and Design 1.7.1 Include Relationship • It is the common and important relationship • The partial behavior is used in common among several use cases Example Paying by credit occurs in several use cases like Process Sale, Process Rental, Contribute to Lay-away Plan etc. Instead of duplicating the text, separate it into its own subfunction use case and indicate its inclusion. Guideline to use include relationship – Fowler “Use include when you are repeating yourself in two or more separate use cases and you want to avoid repetition” Longer use cases can be decomposed into subunits to improve comprehension. They include relationship is used when • They are duplicated in other use cases • A use case is very complex and long, and separating it into subunits aid comprehension. Example: UC1 : Process Sale ….. Main …… Success Scenario Customer arrives at a POS Checkout with goods and/or services to purchase 6b. Paying by Credit : Include handle Credit Payment ……. …… The underlined functions are the include functions for highlighting The Customer pays and system handles payment subfunction “Handle Credit Payment” can be expanded as follows. .……. Extensions: 7b. Paying by credit : Include Handle Credit Payment 7c. Paying by check : Include Handle Check Payment UC7: Process Rental Unified Process and Use Case Diagrams 1.41 UC12 : Handle Credit Payment ……. like. Level : Subfunction Main Success Scenario 1) Customer enters their credit account information 2) System send payment authorization request to an external Payment Authorization Service System and request payment approval. 3) System receives payment approval and signals approval to Cashier. 4) …… 2a. System detects failure to collaborate with external system. 1) System signals error to cashier 2) Cashier asks customer for alternate payment Another use of the include relationship is to describe the handling of asynchronous event • When user is able to select/branch to a particular function, window or webpage within a range of steps. Notations of include ◦ Basic notations use a*, b*,… style labels in the Extensions section. ◦ A range label such as 3 – 9 can be used for asynchronous event within relatively large range if use case steps. UC1: Process FooBars Main Success Scenarios: 1…… Extensions: a* Customer can edit personal information, at any time Edit Personal Information. b* Customer selects printing help, at any time, Present Printing Help. 2 – 11, Customer cancels : Cancel Transaction Confirmation …….. Technologies 1) Concrete use case ◦ It is initiated by an actor ◦ It performs the entire behavior desired by actor Example: Process sale 1.42 Object Oriented Analysis and Design 2) Abstract use case It is never instantiated by itself It is a subfunction use case that is part of another use case Example: Handle credit payment It does not stand on its own. Part of process sale 3) Base use case A use case that includes another use case. It is extended or specialized by another use case. Base use case are usually concrete. Example: Process sale is a base use case with represent to handle credit payment subfunction. 4) Additional use case The use case that is an Inclusion Extension Specialization Is called additional use case Example: Handle credit payment is addition use case in include relationship to process sale. Additional use cases are abstract. 1.7.2 The Extend Relationship The extends relationship is used when an use case is similar to another use case but does a bit more. Here for an use case – create an extending or addition use case and within it, describe where and where and under what condition it extends the behavior of some basic use case. Example: UC 1: Process sale (Base use case) … Extension points: VIP customer, step1.Payment, step 7 Main Success Scenario: Unified Process and Use Case Diagrams 1.43 1. Customer arrives at POS checkout with goods and/or services to purchase …. 7. Customer pays and system handles payment The base use case can be extended as UC 15: Handle Gift certificate payment (the extending use case) … Trigger : customer wants to pay with gift certificate Extension points: Payment in Process Sale Leve l : Subfunction Main Success Scenario: 2. customer gives gift certificate to cashier 3. cashier enters gift certificate ID. The use of extension point is that extending use case is triggered by some condition. The extension points are labels in base use case. The extending use case references as point of extension. Some extension point may be “At any point in use case X”. Example: In asynchronous events like word processor. ◦ Do a spell check now. ◦ Do a the saurus now. The „include‟ relationship can also have been used but since „The process sale‟ use case should not be modified, it is better to go with „extends‟ relationship. Instead of creating complex use case relationships, updating “extensions” can be done. 1.7.3 The Generailze Relationship Generalization is the relationship between a more general class and a more specific class. Example: The vehicle class behaves as a generalized class that has sub class like Bus, Truck can. Figure 1.20 Generalize relationship 1.44 Object Oriented Analysis and Design Figure 1.21 Use case diagram for Next Gen POS Figure 1.22 The extend Relationship notation Unified Process and Use Case Diagrams Additional example Figure 1.23 Use case diagram for interlibrary loan The use case diagram above depicts the • Extends • includes Relationships The interlibrary loan is a special case of checking out books. Entering into the systems is common for • getting into the system is common for So all are included So all are included 1.8 WHEN TO USE: USE CASES DIAGRAMS • Use cases are used in almost every project. • They are helpful in exposing requirements and planning the project. • During the initial stage of a project most use cases should be defined. 1.45 1.46 Object Oriented Analysis and Design