Use Cases and Use Case Diagram

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