Use case Diagram
- 1. UML Diagrams- Use CaseUML Diagrams- Use Case Preeti Mishra Course Incharge
- 2. Course will cover.. • What is a use-case – Use-case versus user interaction • Use-Case diagrams – The constructs in the use-case diagrams • Capturing the use-case – High-level use-case – Extended use-case – Difference between use case and scenario
- 3. What is a Use Case – A use-case captures some user visible function – simplest is a representation of a user's interaction with the system and depicting the specifications of a use case. – A use case diagram can portray the different types of users of a system and the various ways that they interact with the system – help provide a higher-level view of the system.
- 4. An Example • Consider the following when formatting a document • Define a style • Change a style • Copy a style from one document to the next – versus • Format a document • Ensure consistent formatting of two documents • The latter is a user goal – Something the user wants to achieve • The former are user interactions – Things the user does to the system to achieve the goal
- 5. 5 05-Use-Cases Goals and Interactions • There is a place for both goals and interactions • Understand what the system shall do – Capture the user goals • Understand how the user will achieve the goals – Capture user interactions – Sequences of user interactions • Thus, start with the user goals and then refine the user goals into several (many) user interactions
- 6. 6 Actors – An actor represents a set of roles that users of use case play when interacting with these use cases. – Actors can be human or automated systems. – Actors are entities which require help from the system to perform their task or are needed to execute the system’s functions. – Actors are not part of the system. name
- 7. 7 Use Cases and Actors – From the perspective of a given actor, a use case does something that is of value to the actor, such as calculate a result or change the state of an object. – The Actors define the environments in which the system lives Work
- 10. 10 Relationships between Use Cases – Generalization - use cases that are specialized versions of other use cases. – Include - use cases that are included as parts of other use cases. Enable to factor common behavior. – Extend - use cases that extend the behavior of other core use cases. Enable to factor variants.
- 11. 11 Generalization – The child use case inherits the behavior and meaning of the parent use case. – The child may add to or override the behavior of its parent. parent child
- 13. 13 Include – The base use case explicitly incorporates the behavior of another use case at a location specified in the base. – The included use case never stands alone. It only occurs as a part of some larger base that includes it. base included<<include>>
- 14. 14 More about Include – Enables to avoid describing the same flow of events several times by putting the common behavior in a use case of its own. updating grades output generating verifying student id <<include>> <<include>>
- 15. 15 Extend • The base use case implicitly incorporates the behavior of another use case at certain points called extension points. • The base use case may stand alone, but under certain conditions its behavior may be extended by the behavior of another use case. base extending<<extend>>
- 16. 16 More about Extend • Enables to model optional behavior or branching under conditions. Exam copy request Exam-grade appeal <<extend>>
- 18. 18 Relationships between Use Cases and Actors – Actors may be connected to use cases by associations, indicating that the actor and the use case communicate with one another using messages. updating grades faculty
- 20. 20 Update Items Bookshop Worker Ship Order Bookshop Manager Update Staff Details Register Details Customer 1 System Login Update Customer Details Add Items to ShoppingCart Handle Order <<include>> <<extend>> <<include>> Make Order <<include>> A More Complicate Example
- 21. 21 Each use case may include all or part of: Title or Reference Name - meaningful name of the UC Author/Date - the author and creation date Modification/Date - last modification and its date Purpose - specifies the goal to be achieved Overview - short description of the processes Cross References - requirements references Actors - agents participating Pre Conditions - must be true to allow execution Post Conditions - will be set when completes normally Normal flow of events - regular flow of activities Alternative flow of events - other flow of activities Exceptional flow of events - unusual situations Implementation issues - foreseen implementation problems Use Case Description
- 22. 22 Example- Money Withdraw (cont.) • Actors: Customer • Pre Condition: – The ATM must be in a state ready to accept transactions – The ATM must have at least some cash on hand that it can dispense – The ATM must have enough paper to print a receipt for at least one transaction • Post Condition: – The current amount of cash in the user account is the amount before the withdraw minus the withdraw amount – A receipt was printed on the withdraw amount – The withdraw transaction was audit in the System log file
- 23. 23 Example- Money Withdraw (cont.) Typical Course of events: Actor ActionsActor Actions System ActionsSystem Actions 1. Begins when a Customer arrives at ATM1. Begins when a Customer arrives at ATM 2. Customer inserts a Credit card into ATM2. Customer inserts a Credit card into ATM 3. System verifies the customer ID and status3. System verifies the customer ID and status 5. Customer chooses “Withdraw” operation5. Customer chooses “Withdraw” operation 4. System asks for an operation type4. System asks for an operation type 7. Customer enters the cash amount7. Customer enters the cash amount 6. System asks for the withdraw amount6. System asks for the withdraw amount 8. System checks if withdraw amount is legal8. System checks if withdraw amount is legal 9. System dispenses the cash9. System dispenses the cash 10. System deduces the withdraw amount from10. System deduces the withdraw amount from accountaccount 11. System prints a receipt11. System prints a receipt 13. Customer takes the cash and the receipt13. Customer takes the cash and the receipt 12. System ejects the cash card12. System ejects the cash card
- 24. 24 Example- Money Withdraw (cont.) • Alternative flow of events: – Step 3: Customer authorization failed. Display an error message, cancel the transaction and eject the card. – Step 8: Customer has insufficient funds in its account. Display an error message, and go to step 6. – Step 8: Customer exceeds its legal amount. Display an error message, and go to step 6. • Exceptional flow of events: – Power failure in the process of the transaction before step 9, cancel the transaction and eject the card
- 25. 25 Example- Money Withdraw (cont.) One method to identify use cases is actor-based: - Identify the actors related to a system or organization. - For each actor, identify the processes they initiate or participate in. A second method to identify use cases is event-based: - Identify the external events that a system must respond to. - Relate the events to actors and use cases. The following questions may be used to help identify the use cases for a system: - What are tasks of each actor ? - Will any actor create, store, change, remove, or read information in the system ? - What use cases will create, store, change, remove, or read this information ? - Will any actor need to inform the system about sudden, external changes ? - Does any actor need to be informed about certain occurrences in the system ? - Can all functional requirements be performed by the use cases ?