1 / 13

Use Case Modeling

Use Case Modeling. Use Cases are one way to capture requirements. A visual way to capture functional requirements Each bubble is a discrete user goal Actors can be people, or external systems Each bubble is mapped to a textual description. Use Case Description.

naoko
Download Presentation

Use Case Modeling

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 Case Modeling

  2. Use Cases are one way to capture requirements • A visual way to capture functional requirements • Each bubble is a discrete user goal • Actors can be people, or external systems • Each bubble is mapped to a textual description

  3. Use Case Description • See example on class schedule • Include basic and alternate/exception flows • Each alternate flow must start at a step in the basic flow, and may return to a step in the basic flow • Exception flows are analogous to exceptions in code • Includes versus preconditions • Do not use language that hints at implementation details or system interactions • Avoid click, press, type, button, etc. • Unnecessarily limits creativity

  4. Use Case Diagrams • Made up of three components • Actors (people or external systems) • Use Cases (with textual descriptions) • Relationships Record class grades Review Transcripts Teacher Student Authorized Staff Worker

  5. First, identify actors • Who or what will provide input to the system? • Who or what will need output from the system? • Exercise: identify three actors for an ATM

  6. Relationships between actors • One can be a specialization of another • Actors are classes, not individual people Student Graduate Student

  7. Next, identify user goals • User Goals are statements that represent what the users need to accomplish, independent of specific software features • “Buy a book” • “Return a book” • “View order history” • “Record a log for a transaction” • Exercise: identify five uses cases for an ATM https://commons.wikimedia.org/wiki/File:Girl_blowing_bubbles.jpg

  8. Finally, add relationships • Three types of relationships for use cases: Includes Extends Generalization

  9. Includes relationship • One use case can invoke the behavior of another • Not always, but often a precursor • I.e. the “Buy a book” use case includes the “Authenticate customer” Alter Student Grade <<includes>> Record Grades for a Section Teacher

  10. Extends Relationship • Similar to the includes, but used for handling an abnormal situation Alter Student Grade <<extends>> Alter student grade for a class taken more than a year ago Authorized Staff Worker

  11. Generalization Relationship • Replaces generic functionality with an alternate implementation Alter Student Grade Alter Student Grade for a Graduate Course Teacher

  12. Why Use Cases? • Visual representation easy to understand • Relationships are opportunities for reuse • Exercise: add one of each of the three types of relationships to your ATM example • Use case descriptions can be basis for testing • Can be the basis for planning and scheduling

  13. In-class Exercise • Examine the Quiz Game description • In your teams, come up with at least seven use cases; • At least three actors • At least one of each type of relationship • Complete a use case description for each use case • Turn in this assignment through XP-Dev • See instructions, rubric, and details on project page

More Related