Use Cases

1

Last week

Introduction to software engineering How is it different from traditional engineering?

Introduction to specification Operational vs descriptive Used throughout the product lifecycle

Introduction to Requirements An instance of a specification Functional versus non-functional

This week

Use cases: one way to capture requirements

Operational specifications, during the analysis/planning phase of development UML diagrams

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 capture and document the user-visible functionality of a system (functional requirements)

Each use case represents a discrete goal for the user

4

Use-Case Diagram

5

homeowner

Arms/ disarms system

Accesses system via Internet

Reconfigures sensors and related

system features

Responds toalarm event

Encounters anerror condition

system administrator

sensors

Each oval is a separate use case that has a description

Each oval is a separate use case that has a description

Each stick figure is an actor in your system

Each stick figure is an actor in your system The block is an

external system that interacts with your system. Any system you aren’t developing is external

The block is an external system that interacts with your system. Any system you aren’t developing is external

Use Case Description

Maps to a single bubble (user goal)

See the example on the course webpage:

http://www.cs.gmu.edu/~kdobolyi/cs321/UseCaseTemplate.html

6

Alternate and Exception Flows1. Basic Flow

1. User enters user name

2. User enters password

3. User submits the form

4. Password is validated as correct

5. Main menu is displayed

2. Alternate Flow 1: No password is present at step 1.41. System displays error message.

2. System continues at step 1.2

3. Alternate Flow 2: Password is incorrect at step 1.41. …

4. Exception Flow 1: Database is unreachable1. System displays an unrecoverable error and exits.

7

Includes versus Preconditions

8

Don’t forget to show this on the use case diagram as “includes”

Don’t forget to show this on the use case diagram as “includes”

Includes are steps in the use-casePre-conditions happen before the use caseItems are one or the other, not both!

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

9

AuthorizedStaff Worker

TeacherStudent

Record class grades Review Transcripts

User Goals User Goals are statements that represent what the users need to

accomplish, independent of specific software features

Examples of user goals for a Student Records Management System Ensure that a student’s records reflects courses

taken and grades received in those courses Allow only authorized faculty and staff to update

student records Ensure that students can obtain copies of their own

(and only their) records in a timely manner

10

System Interactions Represent expected interacts between users and

the computer-based system

Suggest how the system fulfills a user goal

Examples: A teacher alters a course grade for a student by

selecting a course selecting a student reviewing the previous grade entering a new grade confirming the change

A process for an administrator to create a new user A process for granting a user access rights

11

User Goals vs. System Interactions

In some cases, system interactions and user goals can be very similar

However, confusing system interactions with user goals or neglecting to identify user goals can obscure the reasons why a system

should have certain features result in lost opportunities for creativity

12

Example showing interactions: User wants to spell check document.

Basic Flow1.User clicks “Spell Check” button2.System checks each word3.New dialog box appears with results

Example showing interactions: User wants to spell check document.

Basic Flow1.User clicks “Spell Check” button2.System checks each word3.New dialog box appears with results

Example showing goals: User wants to spell check document.

Basic Flow1.User starts spell check process2.System checks each word3.System presents results to the user

Example showing goals: User wants to spell check document.

Basic Flow1.User starts spell check process2.System checks each word3.System presents results to the user

User Goals vs. System Interactions

User goals help answer “What” and “Why” questions

System interactions help answer “How” questions (from a user’s perspective)

We will model user goals with Uses Cases

Later, we will model system interactions with interaction diagrams or activity diagrams

13

Actors

Actors are people or external systems that need to interact with our system

14

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?Answer these questions to find actors for an iPodAnswer these questions to find actors for an iPod

Finding ActorsFinding Actors

Relationships Between Actors

Actors can be related by generalization/specializ- ation

Actors are classifiers (not individual users)

15

Student

Graduate Student

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

16

Use Case Relationships

17

Includes

Extends

Generalization

Use-Case Relationships

Includes Dependency: Defines how one use case can invoke behavior defined by another use case

18

Teacher

Alter Student Grade

Record Grades for a Section

<<includes>>

Use-Case Relationships

Extends dependency: defines a use-case that is a variation of another, usually for handling an abnormal situation

19

AuthorizedStaff Worker

Alter Student Grade

Alter student grade for a class taken more

than a year ago

<<extends>>

Use-Case Relations Generalization: Defines one use case as a generalization of

another. Replaces generic functionality with alternate implementation

Coming up: Documenting Use Cases

20

Teacher

Alter Student Grade

Alter Student Grade for a Graduate Course

Documenting Use Cases

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

22

In Class Exercise

Lets create a use case diagram for

iPod Television set Elevator ATM Online Scrabble game Word Processor

23

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?

24