ISOM221+Lecture+14+-+Object-Oriented+Modeling+IV+_Extended+and+Included+Use+Case_

ISOM221+Lecture+14+-+Object-Oriented+Modeling+IV+_Extended+and+Included+Use+Case_

Info iconThis preview shows page 1. Sign up to view the full content.

View Full Document Right Arrow Icon
This is the end of the preview. Sign up to access the rest of the document.

Unformatted text preview: Agenda • Elaborated use case descriptions ISOM221 Information Systems Analysis and Design Lecture 14: Object-Oriented Modeling IV (Extended and Included Use Case) – Conditional flow of events (covered in Lecture 13) – Alternative use cases (covered in Lecture 13) – Extended use case – Included use case – Generalizations 1 2 Levels of Use Cases Initial Use Case Include Include only general use case descriptions Use Case Diagram Syntax • Actor – person or system that derives benefit from and is external to the subject Base Use Case Provide a complete description of the normal set of primary interactions (flows of events) Elaborated Use Case Add alternative and conditional flows of events, if any Develop extended and included use cases, if appropriate • Use Case – Represents a major piece of system functionality • • • • Association Relationship Include Relationship* Extend Relationship* Generalization Relationship* <<includes>> <<extends>> 3 * will be covered in this lecture 4 Initial Use Case Diagram Revised Use Case Diagram <<include>> <<extend>> 5 6 Extended Use Cases • When developing a use case model, there will be time when significant behaviors will be identified, which extend the behavior of the base use cases • Extended behaviors are commonly used to model: – Future extensions to the system (it is a good development practice to include all known future extensions in the analysis model) – Extended versions of the system (e.g., “Premium”, “Professional”) – Possible extensions, which can be added or removed later Advantages of the Extend Approach • Helps represent the system’s extended behavior in the Use Case without complicating or enlarging the base flow of events • Rather, significant extensions can be drawn out and and represented separately • The Base Use Case flow does not have to be rewritten and the Use Case Model does not need to be re-drawn to reflect this new behavior – As new extensions are discovered, they can be added to the model – As extensions are discarded, they can be easily removed from the model 7 8 • These additional behaviors are documented using Extend Relationships and Extended Use Cases Use Case Diagram Notation for the Extend Relationship Extended Use Case A Example (Base Use Case is for Consumer Purchase) Process Product Insurance <<extend>> Base Base Use Case i.e., the use case being extended <<extend>> <<extend>> i.e., the use cases extending extending the original use case Application Base Use Case Process Consumer Consumer Purchase <<extend>> Extended Use Cases Process Membership Application Extended Use Case B 9 10 Concept Check • Identify some possible extended use cases <<extend>> ??? Adding Extended Use Cases • The Base Use Case is extended at specific points in its Flow of Events named “Extension Points” • The extending behaviors are executed at these points when the required conditions for extension are met • Control is returned to Base Use Case at the same point in Flow of Events where the extension was triggered 11 12 Base Use Case Order a Laptop Computer <<extend>> Extended Use Cases Examples: ??? • Upgrade Hardware • Order Software • Order Accessories • Extend Warranty Extended Flow and Extended Use Case Extended Flow in Base/Elaborated Use Case If the extending condition is met, the extended use case is executed. After the extended use case is executed, continue to execute the flow on the base/elaborated use case. Use Case Form for Extended Flow Use Case ID Use Case Actors Description Extending Use Case Extension Point Guard Conditions Flow of Events (same as the base Use Case ID, but with suffix E1, E2, etc.; e.g., UC 101-E1) (name of the extended use case) (usually same as Base Use Case’s Actors; but additional Actors may be needed in order to provide extended functionalities) (brief) (name of the base use case being extended) (step in Base Use Case where this extension occurs) (precondition in the Extended Use Case that triggers the extension) 1. 2. 3. Extended Extended Use Case Post-conditions Alternative Flows Priority Non-Functional Requirements Assumptions Source 13 14 (High, Medium or Low) (only those associated with this use case, if any) Base Use Case with Extended Flows: “Withdraw Funds” Use Case ID Use Case Actors Description Pre-conditions Flow of Events UC-100 Withdraw Funds (P) Customer (S) Customer Accounts System Customer logs in, selects withdraw funds, enters an amount and receives cash and receipt Welcome screen is on 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. Customer slides card in and out Machine prompts customer for password Customer enters password System authenticates customer System presents user with a choice menu Customer selects Withdraw Funds option System asks customer to select account Customer selects account System asks customer for amount to withdraw Customer enters amount System checks for availability of funds in Customer Accounts System System dispenses cash and prints receipt If customer wants to print bank statement, extend to UC-100-E1 System logs customer out Extended Use Case: “Print bank statement for a fee” Use Case ID Use Case Actors Description Extending Use Case Extension Point Guard Conditions Flow of Events UC-100-E1 Print bank statement for a fee (P) Customer (S) Customer Accounts System Allows customer to print a bank statement with balances and transactions in the last 30 days for a $1 fee UC-100 Withdraw Funds UC-100, flow 13 Statement printing option is implemented and enabled 1. Ask customer if he/she wants a printed bank statement 2. If customer says yes 2.1 Notify customer of a $1 charge for this service 2.2 Prompt customer to continue or cancel 2.3 If customer selects continue 2.3.1 Print statement 2.3.2 Debit $1 from customer’s account 2.3.3 Display thank you note Return to UC-100 and continue on flow 14 Low Statement must be printed within 20 seconds Post-conditions Alternative Flows Priority Non-Functional Requirements Assumptions Source Post-conditions Alternative Flows Priority Non-Functional Requirements Assumptions Source Welcome screen is back on Customer may not be authenticated; customer may not have sufficient funds; machine may not have enough cash High Cash dispensed within 10 seconds after amount is entered Customer speaks English Bank’s Operational Procedures Manual 15 Bank’s Operational Procedures Manual 16 Included Use Cases • Included Use Cases provide a way to model similar behaviors that can be used across multiple use cases • As the Use Case is elaborated, you may identify flow of events that are repeated in several Use Cases • You can extract them into generic “Included” Use Cases, and then “Include” them whenever you need them • Examples: – User logs in and gets authenticated 17 Advantages of Included Use Cases • Identify commonalities among use cases • Manage redundancy within the use case model • Facilitate change in the use case model – when things change in the Included case, you only need to make the necessary changes once • Begin to assemble Included Use Case “Libraries” of common behaviors that can be re-used in other projects 18 Use Case Diagram Notation for the Include Relationship Example (Base Use Case for ATM System) Check Customer Balance Base Use Case A <<include>> <<include>> Included Use Case 1 Withdraw Cash <<include>> Base Use Case B <<include>> <<include>> Base Use Cases <<include>> Inquire Balance <<include>> <<include>> Included Use Cases Base Use Case C <<include>> Included Use Case 2 Make a Deposit <<include>> Authenticate User 19 20 Concept Check • Identify some possible included use cases Check in Economy-Class Passenger <<include>> Using Included Use Cases • Identify all Included Use Cases with the prefix “IUC” instead of “UC” • Indicate in the Base Use Case the point in the Flow of Events where the included use case is included, i.e., insertion point • In the Included Use Case, document all Base Use Cases that use that Included Uses Case Base Use Cases Check in Business-Class Passenger Check in First-Class Passenger <<include>> ??? Included Use Cases <<include>> Examples: • Check Identity • Weigh Luggage • Issue Boarding Pass • Assign Seat* 21 22 Included Use Cases Base Use Case A Use Case Form for Included Flow Use Case ID Use Case Description Including Use Cases Pre-conditions Flow of Events 1. 2. 3. (list Use Cases that use this Included Use Case) (use IUC suffix instead of UC; e.g., IUC 001) Point where Use Case is Included Included Use Case Post-conditions Base Use Case B Alternative Flows Priority Non-Functional Requirements Assumptions Source 23 24 Base Use Case with Included Flows: “Withdraw Funds” Use Case ID Use Case Actors Description Pre-conditions Flow of Events UC-100 Withdraw Funds (P) Customer (S) Customer Accounts System Customer logs in, selects withdraw funds, enters an amount and receives cash and receipt Welcome screen is on 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. Include IUC-001 Log in and Authenticate Customer System presents user with a choice menu Customer selects Withdraw Funds option System asks customer to select account Customer selects account System asks customer for amount to withdraw Customer enters amount System checks for availability of funds in Customer Accounts System System dispenses cash and prints receipt System logs customer out Included Use Case: “Log in and Authenticate Customer” Use Case ID Use Case Description Including Use Cases Pre-conditions Flow of Events IUC-001 Log in and Authenticate Customer Customer logs, gets authenticated, card is checked against stolen reports UC-100 Withdraw Funds; UC-200 Transfer Funds; UC-300 Deposit Funds; UC-400 Inquire Balance ATM has no card in the slot Customer slides card in and out Machine prompts customer for password Customer enters password If password is incorrect 4.1 If card used was reported stolen execute IUC-001-A1 4.2 If password is incorrect 3 times 4.2.1 Retain card and notify user 4.2.1 Go to last step in the including use case 4.3 Go back to step 2 5. System authenticates customer System is back on the next flow step right after this included case was invoked High Authentication should take place within 20 seconds after password entered Customer speaks English Bank’s Operational Procedures Manual 26 1. 2. 3. 4. Post-conditions Alternative Flows Priority Non-Functional Requirements Assumptions Source Welcome screen is back on Customer may not have sufficient funds; machine may not have enough cash High Cash dispensed within 10 seconds after amount is entered Customer speaks English Bank’s Operational Procedures Manual 25 Post-conditions Alternative Flows Priority Non-Functional Requirements Assumptions Source When to Use Alternative, Extended and Included Use Cases • An exception that does not return to the point of extension – Alternative flow Concept Check • Consider which type of use case (alternative, extend, or include) should be used to model the following events in an online shopping website – Provide an option for customers to add a product to the shopping cart when they browse the product information – Ask customers to leave their contact information when a product added to the shopping cart is out of stock – Show the best-seller items when customers browse any category of product 27 28 • An addition or extension to the base flow of events and the base flow being able to be executed without the additional behavior – Extended use case • The behavior utilized in the flow of events of several use cases – Included use case Generalization Relationships • With the introduction of UML 1.3, a new relationship was introduced between use cases – Generalization, per UML, it: – “implies that the child Use Case contains [i.e., inherits] all the attributes, sequences of behavior, and extension points defined in the parent use case, and participates in all relationships of the parent use case.” Generalizations in Use Case Models Abstract Actor Use Case Parent Use Case • A generalization relationship between parent and child use cases describes: – A child use case inherits the behaviors of its parents – A child use case adds new behaviors and specializes in behaviors inherited from the parent Actor A 29 Child Use Case A Child Use Case B Actor B 30 Example of Generalizations Bank Customer Inquire Application Process Generalization Relationship in Use Case Model in Practice • Conceptually it is very powerful – Provide a powerful to develop and organize complex a use case model in a hierarchical relationships among use cases and actors Process Loan Application Business Loan Application Consumer Loan Application • However, it is not yet commonly adopted in practice – Preparing use case descriptions that reflect generalization relationships is not trivial but creates unnecessary complexity in the descriptions 31 32 Business Client Consumer Exercise #1 • Identify some possible extended/included use cases for the LMES Learning Management and Evaluation System (LMES) Submit Assignments Exercise #2 • Based on the base use case “Search for Apartments” for the Campus Housing System – Create an extended use case to allow students to send a message to the apartment owner through the system – Extract the steps for authentication using an included use case Student View Results Mark Assignments Instructor Upload Results 33 34 Use Case ID UC-100 Search for Apartments (P) Student Student logs in, selects “search for apartment”, enters the criteria, and receives a listing of matched apartments and contact information of the apartment owner 1. 2. 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. Student has registered in the system Main menu is displayed System prompts student for username and password Student enters username and password If password is incorrect Where do you insert 3.1 Go back to step 1 System authenticates student an extension point? System presents user with a choice menu Student selects “Search for Apartments” option System asks student to enter the criteria (i.e., desired location, number of bedrooms, and and price range) Student enters the criteria and press “Search” System checks the availability of apartments that match the criteria in the apartment database System displays a listing of all matched apartments Student selects an apartment and views the contact information of the apartment owner System provides an option for student to go back to the main menu Search for Apartments: Base Use Case Use Case Actors Description Pre-conditions Flow of Events Extended Use Case: “Send message to apartment owner” Use Case ID Use Case Actors Description Extending Use Case Extension Point Guard Conditions Flow of Events Post-conditions Alternative Flows Priority Non-Functional Requirements Main menu is displayed 1. 2. High The user interface is user friendly, preferably with images, buttons, and pull-down lists Student may not be authenticated The system may not have apartments that match the search criteria Post-conditions Alternative Flows Priority Non-Functional Requirements Assumptions Source 36 12. If student wants to contact apartment owner, extend to UC-100-E1 Assumptions Student should have access to a computer Source / 35 Use Case ID UC-100 Search for Apartments (P) Student Student logs in, selects “search for apartment”, enters the criteria, and receives a listing of matched apartments and contact information of the apartment owner 1. 2. 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. Student has registered in the system Main menu is displayed System prompts student for username and password Student enters username and password If password is incorrect Where is the insertion 3.1 Go back to step 1 point for the included System authenticates student System presents student with a choice menu use case? Student selects “Search for Apartments” option System asks student to enter the criteria (i.e., desired location, number of bedrooms, and and price range) Student enters the criteria and press “Search” System checks the availability of apartments that match the criteria in the apartment database System displays a listing of all matched apartments Student selects an apartment and views the contact information of the apartment owner System provides an option for student to go back to the main menu Search for Apartments: Base Use Case Use Case Actors Description Pre-conditions Flow of Events Included Use Case: “Log in and Authenticate User” Use Case ID Use Case Description Including Use Cases Pre-conditions Flow of Events Post-conditions Alternative Flows Priority Non-Functional Requirements Assumptions Source 38 Post-conditions Alternative Flows Priority Non-Functional Requirements Assumptions Source Main menu is displayed 1. 2. High The user interface is user friendly, preferably with images, buttons, and pull-down lists Student should have access to a computer / Student may not be authenticated The system may not have apartments that match the search criteria 37 Summary • After today’s class, you should – Be able to further elaborate the base use cases by incorporating extended use cases and included use use cases Next Class • Class Diagrams • Reading: – Textbook Ch. 6 39 40 ...
View Full Document

Ask a homework question - tutors are online