1. 1 Object-Oriented Modeling Using UML CS 3331 Section 2.4 Modeling Requirements with Use Cases

2. 2 Outline  Intro. to UML  Use cases and use case diagrams  Use case scenarios  Case study

3. 3 Unified Modeling Language (UML)  Notation for object-oriented modeling  Standardized by Object Management Group (OMG)  Consists of 12+ different diagrams Use case diagram Class diagram State machine diagram Sequence diagram Activity diagram Deployment diagram … Q: Why so many different diagrams?

4. 4 Modeling Requirements  What’re requirements? Requirements vs. design  How to describe requirements?

5. 5 Describing Requirements  One way to describe a system is to create a “story”, the interaction between a user and the system.  This story should be just one path through the system, start to finish, that a user will want to take.  E.g., ATM

6. 6 Use Cases  A use case defines a sequence of actions performed by a system that yields an observable result of value to a user (called an actor).  Characteristics A use case is typically initiated by an actor. A use case provides value to an actor. A use case is complete.

7. Documenting Use Cases  Use case diagrams, consisting of: system actors use cases 7 Student Check grades system boundary use case actor Goldmine

8. 8 Elements of Use Case Diagram  Actor: Represents a role played by external entities that interact with the system  Use case: Describes what the system does (i.e., functionality) Interaction between an actor and the system  Relationship: Extension (or generalization) among actors Association between actors and use cases Dependency among use cases: include, extend, and generalization

9. 9 Example: Goldmine > UserStudentInstructor Enter gradesValidate userCheck gradesView rosterCheck schedule > User Student Instructor Goldmine

10. 10 Relationships between Use Cases  Include dependency Always initiated (idea similar to method call) Explicitly stated in including use case  Extend dependency Conditionally initiated (similar to callback or exception handling) Implicitly (or not) stated in extended use case  Generalization Similar to subclassing (generalization/specialization) Register student Register international student

11. 11 Guidelines 1. Identify actors Roles played by external entities that interact with the system (humans, machines or other systems) Importance: define the boundary of the system 2. Identify uses cases by asking for each actor Tasks, data, events, etc. it wants to perform, … 3. Identify relationships between/among: Actors and use cases Use cases Actors

12. 12 Exercise (5 minutes)  Form a group (of three or four)  Draw a use case diagram for the Battleship game by identifying Actors System boundary Use cases

13. 13 Use Cases Revisited  How to describe a use case itself?  A scenario is a sequence of steps describing an interaction between a user and a system. The customer browses the catalog and adds desired items to the shopping basket. When the customer wishes to pay, the customer describes the shipping and credit card information and confirms the sale. The system checks the authorization on the credit card and confirms the sale both immediately and with a follow-up email. What if the credit card authorization fail? A separate scenario!

14. 14 Use Cases (Cont.)  A use case is a set of scenarios tied together by a common user goal (e.g., success and failure together, and other alternative paths).  A use case can be documented by describing all its scenarios.

15. 15 Use Case Scenarios Use Case: Check Grades Description: View the grades of a specific year and semester Actors: Student Precondition: The student is already registered Main success scenario: User System 1. The student requests to show his/her grades. 4. The user provides the year and semester, e.g., Fall 2015. 2. The system carries out “Validate user”, e.g., for user “miner” with password “allAs”. 3. The system prompts for the year and semester. 5. The system displays the grades of the courses taken in the given semester, i.e., Fall 2015. Alternative: The student enters “All” for the year and semester, and the system displays grades of all courses taken so far. Exceptional: The “Validate User” use case fails; the system repeats the validation use case.

16. 16 Guidelines 1. Identify a main success scenario (MSS) Assume that every thing goes well, i.e., no exceptions and no errors. Write each step of the scenario, from start to end. 2. Check each step of the MSS to identify Alternatives, exceptions, and error cases If significant, introduce new (secondary) scenarios for them. 3. Merge the MSS and alternatives/exceptions into a single coherent description. * Avoid design/implementation dependent terms, e.g., menu selection or menu selection.

17. 17 Style Guidelines (Ambler, 2005)  Use case names begin with strong verbs.  While use cases do not imply timing, order cases from top to bottom to imply timing (improves readability).  The primary actors should appear in the top left.  Actors are associated with one or more use cases.  Do not use arrows on the actor-use case relationship.  Do not show actors interacting with each other.  Apply > when you know exactly when to invoke the use case. These should rarely nest more than 2 deep.  Avoid using >.

18. 18 Case Study: E-book Store Identify the main actors and the key use cases for an e-bookstore, and draw a use case diagram. Describe the use case scenario for the most important use case. The core requirements of the e-bookstore are to allow its customers to browse and order books, music CDs, and computer software through the Internet. The main functionalities of the system are to provide information about the titles it carries to help customers make purchasing decisions; handle customer registration, order processing, and shipping; and support management of the system, such as adding, deleting, and updating titles and customer information.

19. 19 Sample Solution > Customer System administrator > Catalog manager Inventory manager Register Manage Catalog Manage Account Process Order ShopLogon

20. 20 Sample Solution (Cont.) Use Case: Shop Description: Browse the catalog and place an order Actors: Customer Precondition: The customer is already registered Main scenario: User System Repeat the following until done: Search and browse titles Select a title to buy Done with shopping and check out Confirm order and payment method Carry out “Logon” Show info about the titles Add the title to the shopping cart Display shopping cart contents and shipping and billing address Validate payment method Process order; issue e-receipt and notify warehouse for shipping Alternative: The customer saves the shopping cart without checking out. Exceptional: Customer authentication fails: repeat the logon procedure. Payment validation fails: prompt the customer for new payment information.

21. 21 Exercise  Form a group (of three or four).  Document the use cases of the Battleship game by identifying and defining their use case scenarios.