1. Use Cases 1

2. Last week  Introduction to software engineering  How is it different from traditional engineering?  Introduction to specification  Operational vs descriptive  Used throughout the product lifecycle  Introduction to Requirements  An instance of a specification  Functional versus non-functional

3. This week  Use cases: one way to capture requirements  Operational specifications, during the analysis/planning phase of development  UML diagrams

4. Introduction  Use Case: “... a typical interaction between a user and a computer system” -- Booch  Here, “user” is anything that needs or invokes the functionality of the system  “Computer system” is the system being modeled  Use cases capture and document the user- visible functionality of a system (functional requirements)  Each use case represents a discrete goal for the user 4

5. Use-Case Diagram 5 Each oval is a separate use case that has a description Each stick figure is an actor in your system The block is an external system that interacts with your system. Any system you aren’t developing is external

6. Use Case Description  Maps to a single bubble (user goal)  See the example on the course webpage: http://www.cs.gmu.edu/~kdobolyi/cs321/UseCaseTemplate.html 6

7. Alternate and Exception Flows 1.Basic Flow 1.User enters user name 2.User enters password 3.User submits the form 4.Password is validated as correct 5.Main menu is displayed 2.Alternate Flow 1: No password is present at step 1.4 1.System displays error message. 2.System continues at step 1.2 3.Alternate Flow 2: Password is incorrect at step 1.4 1.… 4.Exception Flow 1: Database is unreachable 1.System displays an unrecoverable error and exits. 7

8. Includes versus Preconditions 8 Don’t forget to show this on the use case diagram as “includes” Includes are steps in the use-case Pre-conditions happen before the use case Items are one or the other, not both!

9. Use Case Diagrams  Use Case Diagrams provide a visual way to document user goals and explore possible functionality  Three primary modeling components:  Actors  Use Cases  Relationships 9 Authorized Staff Worker Teacher Student Record class gradesReview Transcripts

10. User Goals  User Goals are statements that represent what the users need to accomplish, independent of specific software features  Examples of user goals for a Student Records Management System  Ensure that a student’s records reflects courses taken and grades received in those courses  Allow only authorized faculty and staff to update student records  Ensure that students can obtain copies of their own (and only their) records in a timely manner 10

11. System Interactions  Represent expected interacts between users and the computer-based system  Suggest how the system fulfills a user goal  Examples:  A teacher alters a course grade for a student by  selecting a course  selecting a student  reviewing the previous grade  entering a new grade  confirming the change  A process for an administrator to create a new user  A process for granting a user access rights 11

12. User Goals vs. System Interactions  In some cases, system interactions and user goals can be very similar  However, confusing system interactions with user goals or neglecting to identify user goals can  obscure the reasons why a system should have certain features  result in lost opportunities for creativity 12 Example showing interactions: User wants to spell check document. Basic Flow 1.User clicks “Spell Check” button 2.System checks each word 3.New dialog box appears with results Example showing interactions: User wants to spell check document. Basic Flow 1.User clicks “Spell Check” button 2.System checks each word 3.New dialog box appears with results Example showing goals: User wants to spell check document. Basic Flow 1.User starts spell check process 2.System checks each word 3.System presents results to the user Example showing goals: User wants to spell check document. Basic Flow 1.User starts spell check process 2.System checks each word 3.System presents results to the user

13. User Goals vs. System Interactions  User goals help answer “What” and “Why” questions  System interactions help answer “How” questions (from a user’s perspective)  We will model user goals with Uses Cases  Later, we will model system interactions with interaction diagrams or activity diagrams 13

14. Actors  Actors are people or external systems that need to interact with our system 14 n Who or what will use the main functionality of the system? n Who or what will provide input to this system? n Who or what will use output from this system? n Who will need support from the system to do their work? n Are there any other software systems with which this one needs to interact n Are there any hardware devices used or controlled by this system? Answer these questions to find actors for an iPod Finding Actors

15. Relationships Between Actors  Actors can be related by generalization/specializ- ation  Actors are classifiers (not individual users) 15 Student Graduate Student

16. Hints for Modeling Actors  An actor can be a role that a user plays with respect to the system  A single person may play different roles  A single actor may perform many use cases  A use case may be performed by many actors  Show external systems as actors only when they are the ones who need a use case 16

17. Use Case Relationships 17 Includes Extends Generalization

18. Use-Case Relationships  Includes Dependency: Defines how one use case can invoke behavior defined by another use case 18 Teacher Alter Student Grade Record Grades for a Section >

19. Use-Case Relationships  Extends dependency: defines a use-case that is a variation of another, usually for handling an abnormal situation 19 Authorized Staff Worker Alter Student Grade Alter student grade for a class taken more than a year ago >

20. Use-Case Relations  Generalization: Defines one use case as a generalization of another. Replaces generic functionality with alternate implementation Coming up: Documenting Use Cases 20 Teacher Alter Student Grade Alter Student Grade for a Graduate Course

21. Documenting Use Cases

22. Benefits of Use Cases  Use cases diagrams capture user-visible functions  Identifying actors help capture who needs the system functionality  Relationships between use cases document opportunities for reuse  Use cases provide a basis planning and scheduling incremental development  Use cases can provide a basis for system testing 22

23. In Class Exercise  Lets create a use case diagram for  iPod  Television set  Elevator  ATM  Online Scrabble game  Word Processor 23

24. Questions  Who might be interested in reviewing or using use case diagrams?  When in the development life cycle should we employ use cases?  What do use cases have to do with object-orientation?  What level of use-case granularity is best?  How many use cases are enough?  Can other modeling activities help in discovering use cases?  When in the development life cycle do we stop referring to or refining the use cases?  What should the text description of use case contain? 24