1 / 23

Use Cases

Use Cases. CS/SWE 421 Introduction to Software Engineering Dan Fleck (Slides adapted from Dr. Stephen Clyde with permission). Introduction. Use Case : “... a typical interaction between a user and a computer system”, Booch

elisa
Download Presentation

Use Cases

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Use Cases CS/SWE 421 Introduction to Software Engineering Dan Fleck (Slides adapted from Dr. Stephen Clyde with permission) Coming up: Introduction

  2. 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 can capture and document the user-visible functionality of a system • Use cases capture how the system will benefit the user • Each use case achieves a discrete goal for the user Coming up: Example Use Case Diagram

  3. Example Use Case Diagram Coming up: Goals

  4. Goals • Use cases help everyone come to a common understanding of what the system should do • Developers • End-users • Domain Experts • Use-cases are a communication tool for the design (not the implementation) • Use cases represent a functional requirement of your system (as a whole) Coming up: Use Case Diagrams

  5. 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 between use cases Record class grades Review Transcripts Teacher Student Authorized Staff Worker Coming up: Actors

  6. Actors • Actors are things outside the system that need to interact with the system • Actors carry out use cases • Actors are represented as stick figures • Although users are actors, not all actors are users • Actors can be external software systems • External hardware (sensors, actuators, etc.) • Actors can be people that need the functionality of the system, but may not be the ones who actually invoke the software commands Coming up: Hints for Finding Actors

  7. Hints for Finding Actors • Who or what will use the main functionality of the system? • Who or what will provide input to this system? • Who or what will use output from this system? • Who will need support from the system to do their work? • Are there any other software systems with which this one needs to interact • Are there any hardware devices used or controlled by this system? Coming up: Hints for Modeling Actors

  8. 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 Coming up: Relationships Between Actors

  9. Relationships Between Actors • Actors cam be related by generalization/specialization • Actors are classifiers (not individual users) Student Do this when very obvious Graduate Student Coming up: Use Cases

  10. Use Cases • Each use case represents something the user needs to do with the system – a goal • A use cases is given a short name and textual description • Use cases can be large or small from a conceptual perspective • Use cases can relate to each other via dependencies, such as • <<extends>> • <<includes>> • Generalization or <<refines>> (“is a”) Coming up: Use Case Relationships

  11. Use Case Relationships Includes Extends Generalization After a while you realize extends and generalization are not too different. Just know generalization and includes… forget about extends (the difference is only in intent) Coming up: Use-Case Relationships

  12. Use-Case Relationships • Includes Dependency: Defines how one use case can invoke behavior defined by another use case Alter Student Grade <<includes>> Record Grades for a Section Teacher Coming up: Use-Case Relationships

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

  14. Use-Case Relations • Generalization: Defines one use case as a generalization of another. Alter Student Grade Alter Student Grade for a Graduate Course Teacher Coming up: Hints for Finding Use Cases

  15. Hints for Finding Use Cases • Try listing actors first and then look at the activities each needs to perform and then try to express the goal that represent these activities • although this will uncover many valuable use cases, it will not find them all • Try listing external events and then look at what the system needs to do in response to each one. • This technique will find some additional use cases, but not all • Be patient, allow the use cases to unfold • Don’t over do it – Use Case Diagram should be broad-brush characterizations of user goals Coming up: Hints for Modeling Use Cases

  16. Hints for Modeling Use Cases • Establish the context of a user goal by identifying the actors • For each actor, consider the behavior that it expects or requires the system to provide • Name these common behaviors as use cases • Factor common behavior into new use cases • Relate the use cases using the extend, includes, and refines dependencies • Adorn uses cases with notes Coming up: Benefits of Use Cases

  17. 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 Coming up: In Class Exercise

  18. In Class Exercise • Lets create a use case diagram for • iPod • Television set • Elevator • ATM • Online Scrabble game • Word Processor Coming up: Use cases for CS421

  19. Use cases for CS421 Show system boundary Show Actors outside boundary Use extend, include, generalization/specialization where appropriate Typically one diagram for your project is sufficient Coming up: Use cases for CS421

  20. Use cases for CS421 Show system boundary (Warning: skip this if not supported by the tool – like Netbeans!) Coming up: Use cases for CS421

  21. Use cases for CS421 • For each use-case (oval) in your diagram include the use-description text described in the slide for Chapter 5, titled: • Use Case Description • about slide #14 Coming up: Questions

  22. 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? Coming up:

  23. Backup Slides • The following slides were removed over time. Coming up: Extends vs. Includes vs. Generalization

More Related