Use Case Diagrams (PowerPoint)

Document Sample
Use Case Diagrams (PowerPoint) Powered By Docstoc
					Use Cases
Use Cases are useful for understanding the behavior being modeled. The most important part of a use case is the text description, not the diagram.

Use Cases
Help analyze or determine software requirements.  Describe an interaction between an Actor and the system.  Achieve a goal for the actor.  Describe a complete behavior.

Example: A Hotel Reservation System Good Use Case: Reserve A Room Bad Use Case: Specify Number of Guests Bad Use Case: Reserving A Room (not a complete activity/behavior)

Use Cases Identify Functionality
By identifying actors and their goals, we can identify functionality the system should possess.  Actors have goals and responsibilities.  Use cases describe behavior in terms of:  action  interaction Example:

1) Client enters start/end dates of reservation, room type, and number of people (interaction) 2) System verifies start/end dates (action) 3) System verifies availability of requested room type (action) 4) User confirms reservation (interaction)

Use Cases Help Identify Objects
Nouns in the Use Case may be objects or classes  Verbs can be behavior that the objects possess.

Hotel Reservation System
A Use Case Diagram shows relationships between actors, use cases, and systems. The use case description is more important than the diagram.

Hotel Reservation System (2)
Use-case Name: Reserve A Room Description: The Potential Guest (actor) contacts the Hotel Reservation System, and reserves a room with the features he requests, and for the day(s) he requests. Preconditions: none Postconditions: upon successful completion the actor's room reservation information is available in the Hotel Reservation System. continued on next slide...

Hotel Reservation System (3)
Details: 1. Potential Guest (PG) contacts Hotel Reservation System (HRS) 1.1 HRS prompts for start date, end date, room type, and number of rooms desired. 2. PG identifies type of room, start/end dates, and number of rooms. 2.1 HRS verifies the inputs 2.2 HRS verifies availability of rooms. 2.3 HRS determines room cost(s) for given room type and dates 2.4 HRS displays the room costs and availability 2.5 HRS prompts the PG to select/confirm reservation 3. The PG selects the reservation info (type, dates, price, #guests). 3.1 HRS prompts for PG's name and credit card information. ...

Other Information
Use Case Descriptions may include other information such as:  Importance: high, medium, low  Frequency (how often expected to occur)  Trigger: what action or event caused this use case to be entered?  Comments  References to business rules or other specifications  Non-human actors can be represented as a box with the stereotype <<Actor>>:
<<Actor>> Credit Card Authorization System

Hotel Reservation System

<<Actor>> Credit Card Authorization System

Use Case Scenarios

Variations on a use case sequence.

Alternate Scenario 1: Precondition: At Step 2 the actor inputs an invalid date range. Details: 2.1 HRS verifies the inputs and finds that the start/end date range is invalid. 2.2 HRS informs the user that the date(s) are invalid, with a reason for invalidity. 2.3 The system returns to step 1.1. Comment: Invalid date(s) include (a) end date on or before start date, (b) start or end date is in the past, (c) start date is more than 6 months in the future (hotel only always 6 month advance booking), (d) length of date span is more than 30 days.

Use Case Alternate Template
Some references use this template:
Name: the name of the use case Goal: the goal of the use case in context of the scope and level Scope: the scope that the use case is covering Level: level that the use case is written to (primary, sub-function, summary) Preconditions: any prerequisites before the use case can be started Success Condition: what is considered a successful end to the use case Failure Condition: what is considered a failed end to the use case Trigger: what external event happens that triggers the start of the use case Notes: Misc. notes regarding performance issues, frequency of use and other issues.

Medical Clinic: «include» and «extend»

Source: Borland's UML Tutorial

Library Model

<<include>> for common behavior

<<extend>> for special cases

Notes on Use Cases
Use Cases are for analysis, not design. Avoid putting design information in a Use Case -- that makes use cases subject to change and harder to maintain or verify.  A use case should model one complete behavior that has a discernable outcome.

A Calculator with Variables/Fcns

Use Case Name: Enter An Expression Description: user enters an algebraic expression Precondition: Expression in not null or blank Importance: High Details: 1. User enters an algebraic expression 2. Calculator reads the expression 2.1 Calculator verifies and evaluates the expression according to the grammar rules for the Calculator 2.2 Calculator displays the result

A Calculator with Variables/Fcns
Use Case Name: Enter An Assignment Description: user enters an assignment statement Precondition: Input is of the form "variable = expression" Importance: High Details: 1. User enters an assignment statement 2. Calculator reads the input 2.1 Calculator saves variable name and removes it and "=" from the input. 2.2 Calculator performs "Enter An Expression" use case 2.3 Upon successful completion, calculator saves the expression value as the value of the variable. 2.4 Calculator displays the result

Calculator Class Diagram

Sequence Diagram

Jacobson, Ivar et al. Object-Oriented Software Engineering: A Use-Case Driven Approach, 1992  Use cases were introduced by I. Jacobsen, one of the fathers of the Unified Software Development Process.  Alistair Cockburn, Structuring Use Cases With Goals, ngucswithgoals.htm  His famous book: Writing Effective Use Cases  Larman, Applying UML and Patterns: An Introduction to OO Analysis and Design, 3rd Ed.  Books about UML 2 and the Unified Software Development Process (my resources page)

Shared By: