Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Use Case Model

5,083 views

Published on

Published in: Education, Business, Technology
  • Be the first to comment

Use Case Model

  1. 1. Use Cases and Use Case Diagram
  2. 2. A Use Case <ul><li>Represents the functionality from the user’s point of view </li></ul><ul><ul><li>Some sort of functionality interface to the users </li></ul></ul><ul><ul><li>Answer the question: How can the system provide observable value to the users, or to fulfill their goals? </li></ul></ul><ul><li>Represents the functional requirements </li></ul><ul><li>Defines the boundaries of the system </li></ul><ul><li>Written in natural language </li></ul><ul><ul><li>Advantages? </li></ul></ul><ul><ul><li>Disadvantages? </li></ul></ul>
  3. 3. Description of a Use Case <ul><li>Name </li></ul><ul><li>Participating actors </li></ul><ul><li>Flow of events </li></ul><ul><li>Entry condition </li></ul><ul><li>Exit condition </li></ul><ul><li>Quality requirement </li></ul>
  4. 4. Example <ul><li>Name: withdraw </li></ul><ul><li>Participate actor: customer </li></ul><ul><li>Flow of event: 1. Customer selects withdraw button 2. The system displays the withdraw screen, and initializes the input amount use case … </li></ul><ul><li>… </li></ul><ul><li>Quality requirement: at any point during the flow of events, this use case can include the cancel transaction use case. The cancel transaction use case is initialized when the cancel button is selected. </li></ul>
  5. 5. Organizing Flow of Events <ul><li>Basic course of actions/major scenario </li></ul><ul><li>Alternative course of actions </li></ul><ul><ul><li>Use to describe the branching </li></ul></ul><ul><li>Benefits of using such organization? </li></ul>
  6. 6. Scenario vs. Use Case <ul><li>Scenario </li></ul><ul><ul><li>An instance of a use case </li></ul></ul><ul><ul><li>Description of a concrete set of actions </li></ul></ul><ul><ul><li>Like an execution trace of a program </li></ul></ul><ul><ul><li>No branching, no entry condition, no exit conditions (why?) </li></ul></ul><ul><ul><li>The focus is the understandability </li></ul></ul><ul><li>Use case </li></ul><ul><ul><li>An abstraction that describe all possible scenarios involved in certain functionality </li></ul></ul><ul><ul><li>Like an algorithm </li></ul></ul><ul><ul><li>The focus is the completeness </li></ul></ul>
  7. 7. Separation of Concerns <ul><li>Decomposing use cases </li></ul><ul><ul><li>Separating the common cases from the exceptions and errors handling </li></ul></ul><ul><ul><li>Separating common functionality to avoid redundancy </li></ul></ul><ul><li>To make decomposition work, relationships among the use cases needs to be described </li></ul><ul><ul><li>Include </li></ul></ul><ul><ul><li>Extend </li></ul></ul><ul><ul><li>Inheritance </li></ul></ul>
  8. 8. Use-Case Diagram <ul><li>A UML diagram that represents the relationship between actors and use cases, and among the use cases </li></ul><ul><li>Represents an “architectural” view of the requirements </li></ul>
  9. 9. Major Components <ul><li>Actors </li></ul><ul><ul><li>External entities (e.g., user role, another system) </li></ul></ul><ul><li>Relationship between actors and use cases </li></ul><ul><ul><li>Initiation </li></ul></ul><ul><ul><li>Communication </li></ul></ul><ul><li>Relationship among different use cases </li></ul><ul><ul><li>Enables the decomposition of complex use cases into smaller ones </li></ul></ul>
  10. 10. Use Case Diagram for E-homework management system E-homework distribution TA Students E-homework submission E-homework grading
  11. 11. Include Relationship <ul><li>Use case A includes use case B if the flow of events for A contains the flow of events for B </li></ul><ul><li>A whole-part relationship </li></ul><ul><li>Allow use case A to access another common use case B </li></ul>
  12. 12. Representation <ul><li>In use case description </li></ul><ul><ul><li>At a particular point during the flow of events </li></ul></ul><ul><ul><ul><li>Mention the inclusion at that point </li></ul></ul></ul><ul><ul><li>At any point in the flow of events </li></ul></ul><ul><ul><ul><li>Mention the inclusion in the quality requirement </li></ul></ul></ul><ul><li>In the use case diagram </li></ul><<include>>
  13. 13. Example <<include>> withdraw Input amount Cancel transaction <<include>> customer
  14. 14. When to Refactor Using Include Relation <ul><li>When a particular flow of events is repeatedly described in more than on use cases </li></ul><ul><ul><li>Purpose of refactoring: reduce redundancy </li></ul></ul><ul><li>When a particular flow of events corresponds to a concept in the problem domain </li></ul><ul><ul><li>Purpose of refactoring: improving the understandability </li></ul></ul><ul><li>When the description of a use case is too long </li></ul><ul><ul><li>Purpose of refactoring: improving the understandability </li></ul></ul>
  15. 15. Example from “Patterns for Effective Use Cases”
  16. 19. Extension Relation <ul><li>A use case A extends a use case B if the flow of events in A can occur amid the flow of events in B when certain condition is true </li></ul><ul><li>It is like an “interrupt” </li></ul><ul><li>It is used to separate the exceptional behavior from the normal behavior </li></ul><ul><ul><li>Advantage? </li></ul></ul>
  17. 20. Representation <ul><li>Use case description </li></ul><ul><ul><li>Mentioned extension in the entry condition in the extending use case </li></ul></ul><ul><ul><li>Specifying the condition that would trigger the extending use case </li></ul></ul><ul><li>Use case diagram </li></ul><<extend>>
  18. 21. Example Connection down Deposit withdraw <<extend>> <<extend>> Name: connection down … Entry condition: This use case extends the Deposit and withdraw use case. It is initialized by the system whenever the connection between the customer and the central sever is lost.
  19. 22. Comparing include and extend <ul><li>Similarity </li></ul><ul><ul><li>They are equivalent: both are mechanisms for composing two use cases to describe a functionality </li></ul></ul><ul><li>Difference </li></ul><ul><ul><li>The major difference is the location of the triggering conditions </li></ul></ul><ul><ul><ul><li>Suppose that A and B together describe a functionality </li></ul></ul></ul><ul><ul><ul><ul><li>A includes B when A has the triggering condition for B: in this case, A has to know about B </li></ul></ul></ul></ul><ul><ul><ul><ul><li>B extends A when B has the triggering condition for B: in this case, A does not need to know about B </li></ul></ul></ul></ul>
  20. 23. Include vs. Extend <<include> A B <<extend>> A B Move triggering condition for B from A to B Move triggering condition for B from B to A Guideline: judge to see whether the triggering condition for B is an integral part of A or an integral part for B.
  21. 24. Example: Why extend is better than include here? Connection down Deposit withdraw <<extend>> <<extend>> Name: connection down … Entry condition: This use case extends the Deposit and withdraw use case. It is initialized by the system whenever the connection between the customer and the central sever is lost.
  22. 25. Inheritance Relationship <ul><li>It represent specialization or conceptual classification </li></ul><ul><li>A specialized use case can inherit the participating actor, entry and exit conditions, and some courses of actions from the base use case </li></ul><ul><ul><li>Enable polymorphism from the client’s perspective </li></ul></ul><ul><li>Inheritance can be used to simplify the use case diagram </li></ul>
  23. 26. Representation <ul><li>Description </li></ul><ul><ul><li>Mention the inheritance of various descriptions from another use case </li></ul></ul><ul><ul><ul><li>Participating actor </li></ul></ul></ul><ul><ul><ul><li>Entry/exit conditions </li></ul></ul></ul><ul><ul><ul><li>Different courses of actions </li></ul></ul></ul><ul><li>Diagram </li></ul>Authenticate with finger print Authenticate with passwd Authenticate
  24. 27. Example Name: Authenticate with password Participating actor: Inherited from Authenticate use case Flow of events: … . Entry condition: Inherited from Authenticate use case Exit condition: Inherited from Authenticate use case
  25. 28. What we’ve learned <ul><li>Use cases and use case diagrams </li></ul><ul><li>Factoring and organizing use cases using “include”, “extend”, and “inheritance” relationships </li></ul><ul><li>Question: </li></ul><ul><ul><li>Are these relationships enough for organizing the use cases? </li></ul></ul>

×