1. Use Cases Elizabeth Bigelow CS 15-499C 9/15/2000

2. Administration Only 4 students have submitted applications for TogetherJ Accounts Please get these in no later than Sunday evening

3. Use Cases A form of dynamic modeling Very informal Tend to be unwieldy for large systems Not a bad way to start, but usually will not scale well Easy for users to understand Difficult to use for embedded systems

4. Use Case Contents Use cases (ovals) Actors Dependency, generalization and association relationships

5. Common Uses Model the context of a system Draw a “line” around the whole system and assert which actors lie outside the system and interact with it. Use case diagrams specify the actors and the meaning of their roles Model the requirements of a system Specify what the system should do independent of how the system should do it (ie, desired behavior as a “black-box”)

6. Credit Card Validation System Context

8. If you start from use cases Decide who interacts with the system (may be an external system)—these are the actors Decide what lies within the system (the system boundary Develop high level use cases, then use generalization, dependency and association to make more precise Note that in this context association is the relationship of the actors and the use cases

9. More details on use cases Extends relationship is used to show Optional behavior Behavior that is only run under certain conditions Several different flows which may be run based on actor selection

11. Scenarios A scenario is a specific instance of a use case Expressing the whole system via scenarios is tedious, and time consuming Specifying a few scenarios, however, can significantly help getting started

12. 80/20 Rule For any technique, keep the 80/20 rule in mind Don’t specify everything!