GeneralizableElement

NamespaceModelElement

namevisibilityisSpecification

Classifier

isRoot

Constraint

Body

Use Cases

CS/SWE 421

Introduction to Software Engineering

Dan Fleck(Slides adapted from Dr. Stephen Clyde with permission)

1Coming up: Introduction

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)

Use cases capture how the system will benefit the user

Each use case represents a discrete goal for the user

2

Coming up: Example Use Case Diagram

Example Use Case Diagram

Coming up: Use Case Diagrams

3

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

AuthorizedStaff Worker

TeacherStudent

Record class grades

– Relationships between use cases

Review Transcripts

4

Coming up: Actors

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

5

Coming up: System Interactions

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 semester• 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 6

Coming up: User Goals vs. System Interactions

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

7

Coming up: User Goals vs. System Interactions

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

8

Coming up: Actors

Actors Actors are people or external

systems that need to interact with our system

9

Coming up: Relationships Between 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?

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/specialization Actors are classifiers (not

individual users)

Student

Graduate Student

10

Coming up: Use Case Relationships

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

11

End of presentation

Use Case Relationships

Includes

Extends

Generalization

12

Coming up: Use-Case Relationships

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)

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)

Extends vs. Includes vs. Generalization Extends, includes, and generalization may

appear similar, but differ in intent– Extend dependencies model variations from

normal workflows– Specializations are refinements of a general use

cases– “Include” uses case (or sub-use cases), unlike

specializations, can represent different goals or processes

– Include dependencies are a form of aggregation– The actors for a general use case are also actors

for the use cases that specialize it– Often there are no actors for sub-use cases

13

Coming up: User Goals

Use-Case Relationships

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

Teacher

Alter Student Grade

Record Grades for a Section

<<includes>>

14

Coming up: Use-Case Relationships

Use-Case Relationships

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

AuthorizedStaff Worker

Alter Student Grade

Alter student grade for a class taken more

than a year ago

<<extends>>

15

Coming up: Use-Case Relations

Use-Case Relations

Generalization: Defines one use case as a generalization of another. Replaces generic functionality with alternate implementation

Teacher

Alter Student Grade

Alter Student Grade for a Graduate Course

16

Coming up: Documenting Use Cases

Documenting Use Cases

Coming up: Benefits of Use Cases

17

List Actors

List Actors

List External Events

List External Events

Determine expected behavior

Determine expected behavior

Name behaviors as use cases

Name behaviors as use cases

Add relations (includes, extends,

generalization)

Add relations (includes, extends,

generalization)

Document use case (basic flow,

alternate, exception)

Document use case (basic flow,

alternate, exception)

What is system response to external event? What is the user’s goal?

What is system response to external event? What is the user’s goal?

Be Patient… let them unfoldBe Patient… let them unfold

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 testing18

Coming up: In Class Exercise

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 boundaryShow system boundary

Show Actors outside boundary

Show Actors outside boundary

Use extend, include, generalization/specialization where appropriate

Use extend, include, generalization/specialization where appropriate

Typically one diagram for your project is sufficient

Typically one diagram for your project is sufficient20

Coming up: Use cases for CS421

Use cases for CS421

For each use-case (oval) in your diagram include the use-case description text described in the slide for Chapter 5, titled:

Use Case Description–about slide #17

21

Coming up: Questions

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? 22

Coming up: