1. Use Cases

2. 2 A use case... –Specifies the behavior of a system or some subset of a system. –Is a system-level function. –Does not indicative how the specified behavior is implemented, only what the behavior is. –Performs a service for some user of the system. A user of the system is known as an actor. An actor can be a person or another system. –During the analysis phase, facilitates communication between the users of the system and the developers of the system. Introduction

3. 3

4. 4 A use case... –Represents a functional requirement of the system as a whole. –Is graphically represented as an oval with the name of its functionality written inside. Functionality is always expressed as a verb or a verb phrase. An actor is most typically represented as a stick figure of a person labeled with its role name. Individual use cases can exist in relationships with other use cases much in the same way as classes maintain relationships with other classes. Introduction

5. 5 Names are used to distinguish one use case from another. Actors … –May be drawn as a stick figure, stereotyped class or a graphical image of your own design. –Are connected to use cases by associations. –May be involved in generalization relationships with other actors. –Exist outside the system boundaries. Terms and Concepts

6. 6

7. 7 Use cases and Flow of Events –A use case, by itself, does not describe the flow of events needed to carry out the use case. –Flow of events can be described using informal text, pseudocode, or activity diagrams. –Be sure to address exception handling when describing flow of events. –Use a note to attach flow of events documentation to a use case. Terms and Concepts

8. 8 Use cases and Collaborations Collaboration diagrams show which classes are involved in implementing a particular use case.

9. 9 Terms and Concepts Organizing Use Cases –Packages may be used to organize (group) use cases. –Generalization between use cases is used to extend the behavior of a parent use case. –An > relationship between use cases means that the base use case explicitly incorporates the behavior of another use case at a location specified in the base. Sometimes the stereotype is used instead of >.

10. 10 Terms and Concepts Organizing Use Cases –An > relationship between use cases means that the base use case implicitly incorporates the behavior of another use case at a location specified indirectly by the extending use case. –Extended behavior is optional behavior, while included behavior is required behavior.

11. 11 Use Case Relationships

12. 12 Use Case Relationships

13. Use Case Diagrams

14. 14 Use case diagrams … –Show a set of actors, use cases, and their relationships. –Facilitate communication between non-technical customers and developers due to their simplistic nature. –Show the functionality of the system from the prospective of each user of the system. –Model the context of the system. –Model the requirements of the system. Introduction

15. 15 Use Case Diagram

16. 16 Modeling System Requirements A requirement … –Is a design feature, property, or behavior of a system. –States what needs to be done, but not how it is to be done. –Is a contract between the customer and the developer. –Can be expressed in various forms, including use cases.

17. 17 Modeling System Requirements To model the requirements of a system … –Identify all actors (users of the system). –Identify the needs, from the system, of each individual actor. –Make each need a use case. –Identify redundant behavior within your set of use cases, and factor it into common base-class use cases. In other words, look for opportunities to use generalization. –Do the same for actors. –Show the relationships between actors and use cases.

18. 18 Modeling System Context