1 / 27

Scenarios, Use Cases and Use Case Diagrams

Scenarios, Use Cases and Use Case Diagrams . We need a few definitions. Actor: an entity that can interact with a system, invoking some behavior . Actor:. Scenario: a specific sequence of actions and interactions between actors and the system being discussed. Scenario:. Use Case: .

dreama
Download Presentation

Scenarios, Use Cases and Use Case Diagrams

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Scenarios, Use Cases and Use Case Diagrams

  2. We need a few definitions. Actor: an entity that can interact with a system, invoking some behavior Actor: Scenario: a specific sequence of actions and interactions between actors and the system being discussed Scenario: Use Case: Use Case: a collection of related success and failure scenarios

  3. Actors represent external entities that interact the system. • Stimulate vs. stimulated • Role, not an entity Actors for an ATM System?

  4. A scenario represents one possible outcome of the actor/system interactions. Card Rejected Account Holder places card in slot. System prompts user for PIN. User enters PIN. PIN is not valid for the given card. Card is rejected. Successful Withdrawal Account Holder places card in slot. System prompts Account Holder for PIN and Account Holder enters PIN. The system determines the PIN is valid for the card. The Account Holder selects a Withdrawal Transaction. The system ensures the account has enough money. The system deducts the requested amount from the account and dispenses cash to Account Holder.

  5. A use case glues together related scenarios that an actor initiates to accomplish a specific goal Use Case: Withdraw 1. Account Holder places card in slot. 2. System prompts Account Holder for PIN 3. Account Holder enters PIN. 4. System determines the PIN is valid for the card. ` 5. Account Holder selects a Withdrawal Transaction. 6. System prompts for amount to be withdrawn. 7. Account Holder enters amount to be withdrawn. 8. System determines the account has sufficient funds. 9. System deducts the requested amount from the account. 10. System dispenses cash to Account Holder. Alternative: Card rejected 4. System determines PIN is not valid for the card. 5. System rejects card. Alternative: Insufficient funds 8. System determines the account does not have sufficient funds for withdrawal. 9. System displays appropriate message and returns card.

  6. Note: This format is part of the “IST 420 Methodology” Use Case: Withdraw 1. Account Holder places card in slot. 2. System prompts Account Holder for PIN 3. Account Holder enters PIN. 4. System determines the PIN is valid for the card. ` 5. Account Holder selects a Withdrawal Transaction. 6. System prompts for amount to be withdrawn. 7. Account Holder enters amount to be withdrawn. 8. System determines the account has sufficient funds. 9. System deducts the requested amount from the account. 10. System dispenses cash to Account Holder. Alternative: Card rejected 4. System determines PIN is not valid for the card. 5. System rejects card. Alternative: Insufficient funds 8. System determines the account does not have sufficient funds for withdrawal. 9. System displays appropriate message and returns card.

  7. Other methods may capture use cases differently. From Learning UML 2.0 Use case name: Create a new Personal Wiki Related Requirements Requirement 1.A Goal In Context A new or existing author requests a new blog account from the Administrator. Preconditions The author has appropriate proof of identity. Successful End Condition A new personal Wiki is created for the author. Failed End Condition The application for a new personal Wiki is rejected. Primary Actors Administrator. Secondary ActorsAuthor Credentials Database. Trigger The Administrator asks the CMS to create a new personal Wiki. Main Flow Step Action 1 The Administrator asks the system to create a new personal Wiki. 2 The Administrator enters the author’s details. 3 The author’s details are verified using the Author Credentials Database. 5 The new personal Wiki is created. 6 A summary of the new personal Wiki;s details are emailed to the author. Extensions Step Branching Action 3.1 The Author Credentials Database does not verify the author’s details. 3.2 The author’s new personal Wiki application is rejected.

  8. Alternative scenarios are deviations from a specific step in the main scenario. Use Case: Withdraw 1. Account Holder places card in slot. 2. System prompts Account Holder for PIN 3. Account Holder enters PIN. 4. System determines the PIN is valid for the card. 5. Account Holder selects a Withdrawal Transaction. 6. System prompts for amount to be withdrawn. 7. Account Holder enters amount to be withdrawn. 8. System determines the account has sufficient funds. 9. System deducts the requested amount from the account. 10. System dispenses cash to Account Holder. Alternative: Card rejected 4. System determines PIN is not valid for the card. 5. System rejects card. Alternative: Insufficient funds 8. System determines the account does not have sufficient funds for withdrawal. 9. System displays appropriate message and returns card. The first step in the alternative replaces the step of the same number in the main scenario

  9. Alternatives may rejoin the main scenario. • Use Case: Check in for flight • User presses Begin. • System prompts user for last name. • User enters last name. • System prompts user for first name. • User enters first name. • System finds and displays related flight information. • User selects flight. • System prompts user to enter number of bags to check. • . . . • Alternative: User uses credit card • 3. User inserts credit card into slot. • 4. System reads user information from credit card. • Return to step 6 in main scenario.

  10. Use Case formats can take on any form (even graphical). • Keep it simple • Avoid alternatives to alternatives.

  11. A use case diagram visualizes the relationships among the system, actor and use cases. ATM Withdraw Account Holder

  12. A few notes on use case diagrams: • Actors can be involved with multiple use cases • Use cases can be associated with multiple actors • Use case diagrams only depict use cases, not individual scenarios

  13. Sometimes use cases will encapsulate common behavior. Use Case: Withdraw 1. Account Holder places card in slot. 2. System prompts Account Holder for PIN and Account Holder enters PIN. 3. The system determines the PIN is valid for the card. 4. The Account Holder selects a Withdrawal Transaction. . . . Use Case: Deposit 1. Account Holder places card in slot. 2. System prompts Account Holder for PIN and Account Holder enters PIN. 3. The system determines the PIN is valid for the card. 4. The Account Holder selects a Deposit Transaction. . . . Use Case: Check Balance 1. Account Holder places card in slot. 2. System prompts Account Holder for PIN and Account Holder enters PIN. 3. The system determines the PIN is valid for the card. 4. The Account Holder selects a Check Balance Transaction. . . .

  14. The include relationship lets us factor out the common behavior and then “import” it. Use Case: Validate 1. Account Holder places card in slot. 2. System prompts Account Holder for PIN and Account Holder enters PIN. 3. The system determines the PIN is valid for the card. . . . Use Case: Withdraw 1. Include Validate. 2. The Account Holder selects a Withdrawal Transaction. . . . Use Case: Deposit 1. Include Validate. 2. The Account Holder selects a Deposit Transaction. . . . Use Case: Check Balance 1. Include Validate. 2. The Account Holder selects a Check Balance Transaction. . . .

  15. Alternatives may be part of included use cases. Use Case: Validate 1. Account Holder places card in slot. 2. System prompts Account Holder for PIN 3. Account Holder enters PIN. 4. The system determines the PIN is valid for the card. Alternative: Card rejected 4. System determines PIN is not valid for the card. 5. System rejects card. Use Case: Withdraw 1. Include Validate. 2. The system determines the PIN is valid for the card. 3. The Account Holder selects a Withdrawal Transaction. 4. The system determines the account has enough money. 5. The system deducts the requested amount from the account. 6. System dispenses cash to Account Holder. Alternative: Insufficient funds 4. System determines the account does not have sufficient funds for withdrawal. 5. System displays appropriate message and returns card.

  16. The result of inclusion is the splicing together of the involved use cases. Use Case: Validate 1. Account Holder places card in slot. 2. System prompts Account Holder for PIN 3. Account Holder enters PIN. 4. The system determines the PIN is valid for the card. Alternative: Card rejected 4. System determines PIN is not valid for the card. 5. System rejects card. Use Case: Withdraw 1. Account Holder places card in slot. 2. System prompts Account Holder for PIN 3. Account Holder enters PIN. 4. The system determines the PIN is valid for the card. 5. The Account Holder selects a Withdrawal Transaction. 6. The system ensures the account has enough money. 7. The system deducts the requested amount from the account. 8. System dispenses cash to Account Holder. Alternative: Card rejected 4. System determines PIN is not valid for the card. 5. System rejects card. Alternative: Insufficient funds 6. System determines the account does not have sufficient funds for withdrawal. 7. System displays appropriate message and returns card. Use Case: Withdraw 1. Include Validate. 2. The system determines the PIN is valid for the card. 3. The Account Holder selects a Withdrawal Transaction. 4. The system ensures the account has enough money. 5. The system deducts the requested amount from the account. 6. System dispenses cash to Account Holder. Alternative: Insufficient funds 4. System determines the account does not have sufficient funds for withdrawal. 5. System displays appropriate message and returns card.

  17. The include relationship is represented in use case diagrams as a stereotyped dependency. ATM Withdraw <<include>> <<include>> Deposit Validate Check Balance <<include>> Account Holder

  18. The extend relationship provides a way to show “special case” behavior that is closely related to another use case. • Useful for complicated use cases • Requires the use of explicit extension points • Extended use cases stand on their own

  19. Example : extend Use Case: Deposit Main Scenario 1. Include Validate. 2. The Account Holder selects Deposit. 3. The system retrieves the account information and prompts Account Holder for amount to deposit. 4. The Account Holder enters the amount. 5. XP: The system starts the deposit slot mechanism. 6. The Account Holder places the deposit item into the deposit slot mechanism. 7. The system detects the deposit item and stops the deposit slot mechanism. 8. The system adds the deposit amount to the account. 9. The card is returned to the Account Holder. Alternative: Deposit Slot Mechanism Times Out 6. The Account Holder does not place the deposit item in the deposit slot mechanism within 5 seconds. 7. The system did not detect a deposit item and stops the deposit slot mechanism 8. The system displays an error message to the Account Holder. 9. The card is returned to the user. Use Case: Deposit Main Scenario 1. Include Validate. 2. The Account Holder selects Deposit. 3. The system retrieves the account information and prompts Account Holder for amount to deposit. 4. The Account Holder enters the amount. 5. The system starts the deposit slot mechanism. 6. The Account Holder places the deposit item into the deposit slot mechanism. 7. The system detects the deposit item and stops the deposit slot mechanism. 8. The system adds the deposit amount to the account. 9. The card is returned to the Account Holder. Alternative: Deposit Slot Mechanism Fails to Start 5. The system fails to start the deposit slot mechanism. 6. The system displays an error message to the Account Holder. 7. The card is returned to the Account Holder. Alternative: Deposit Slot Mechanism Times Out 6. The Account Holder does not place the deposit item in the deposit slot mechanism within 5 seconds. 7. The system did not detect a deposit item and stops the deposit slot mechanism 8. The system displays an error message to the Account Holder. 9. The card is returned to the user. Use Case: Deposit Slot Mechanism Failure Extends: Deposit Replace XP with 1. The system fails to start the deposit slot mechanism. 2. The system displays an error message to the Account Holder. 3. The card is returned to the Account Holder.

  20. Example : extend Use Case: Deposit Main Scenario 1. Include Validate. 2. The Account Holder selects Deposit. 3. The system retrieves the account information and prompts Account Holder for amount to deposit. 4. The Account Holder enters the amount. 5. XP: The system starts the deposit slot mechanism. 6. The Account Holder places the deposit item into the deposit slot mechanism. 7. The system detects the deposit item and stops the deposit slot mechanism. 8. The system adds the deposit amount to the account. 9. The card is returned to the Account Holder. Alternative: Deposit Slot Mechanism Times Out 6. The Account Holder does not place the deposit item in the deposit slot mechanism within 5 seconds. 7. The system did not detect a deposit item and stops the deposit slot mechanism 8. The system displays an error message to the Account Holder. 9. The card is returned to the user. Use Case: Deposit Main Scenario 1. Include Validate. 2. The Account Holder selects Deposit. 3. The system retrieves the account information and prompts Account Holder for amount to deposit. 4. The Account Holder enters the amount. 5. The system starts the deposit slot mechanism. 6. The Account Holder places the deposit item into the deposit slot mechanism. 7. The system detects the deposit item and stops the deposit slot mechanism. 8. The system adds the deposit amount to the account. 9. The card is returned to the Account Holder. Alternative: Deposit Slot Mechanism Fails to Start 5. The system fails to start the deposit slot mechanism. 6. The system displays an error message to the Account Holder. 7. The card is returned to the Account Holder. Alternative: Deposit Slot Mechanism Times Out 6. The Account Holder does not place the deposit item in the deposit slot mechanism within 5 seconds. 7. The system did not detect a deposit item and stops the deposit slot mechanism 8. The system displays an error message to the Account Holder. 9. The card is returned to the user. Extension may deviate at a predefined location. Use Case: Deposit Slot Mechanism Failure Extends: Deposit Replace XP with 1. The system fails to start the deposit slot mechanism. 2. The system displays an error message to the Account Holder. 3. The card is returned to the Account Holder.

  21. Use Case Diagrams – Extend Relationship ATM <<include>> Check Balance Deposit XP <<extend>>(XP) Deposit Slot Mechanism Failure Account Holder

  22. Use case specialization is like an uncontrolled extend. • No extension point • Child specializes the parent • Parent is a generalization of the child

  23. Use case specialization uses the generalization/ specialization notation.

  24. Use Cases – Generalization vs Extension Extensions represents a controlled deviation. A XP Generalizations represent uncontrolled deviation. B may only deviate from A at the point XP1. <<extend>> (XP) A B B may deviate from A in any imaginable way. In fact, it is possible that B may not look anything like A! B

  25. Discussion • Why do we need both generalization and extend? • What would be appropriate uses of each?

  26. Use Case diagrams can capture multiple use cases Use Cases Diagrams – Putting it all together ATM Withdraw <<include>> <<include>> Check Balance Validate Deposit XP <<include>> Account Holder <<extend>>XP Run Diagnositcs Deposit Slot Mechanism Failure Technician

  27. A few notes on Visio… • Visio is a generic drawing tool • You don’t need it • UML stencils are available • “Software : UML Diagrams” • Stencils are out of date • Consider using native drawing areas in documents.

More Related