Use Case Diagrams

Damian Gordon Click to edit Master subtitle style

6/25/12

People in Design

Why do we care about people in design?

Because we build software systems for other people, so we have to give as much thought about how these people (the users) will experience the system, as we do in the building on the internal logic of the system.

6/25/12

People in Design

Lets take an example, users of facebook:

6/25/12

6/25/12

Non-Registered Users
View publicly available profiles

Register to join facebook

6/25/12

Registered Users

View publicly available profiles Log in

Look at friends updates Update own profile Post on walls Add an app Log out

6/25/12

Users

Register to join facebook View publicly available profiles Log in

Look at friends updates Update own profile Post on walls Add an app Log out

Registe red Users

NonRegistered Users

People in Design

Lets take another example, e-mail:

6/25/12

e-Mail

Log in

Read new messages Reread old messages Delete messages Send new messages Create mailing list Log out

6/25/12

Registe red Users

e-Mail

Log in

Read new message s Reread old message s Delete message s Send new message s Create mailing list Log out

Registe red Users

e-Mail

Log in

Read new message s Reread old message s Delete message s Send new message s Create mailing list Log out

Registe red Users

Administr ator

e-Mail

Log in

Read new message s Reread old message s Delete message s Send new message s Create mailing list Log out

Registe red Users

Administr ator

e-Mail

Log in Create new email account

Delete email account

Read new message s Reread old message s Delete message s Send new message s Create mailing list Log out

Registe red Users

Administr ator

Using Use Case Diagrams

Use case diagrams are used to visualize, specify, construct, and document the (intended) behavior of the system, during requirements capture and analysis. Provide a way for developers, domain experts and end-users to Communicate. Serve as basis for testing. Use case diagrams contain use cases, actors, and their relationships.
6/25/12

Use Case

Use cases specify desired behavior. A use case is a description of a set of sequences of actions, including variants, a system performs to yield an observable result of value to an actor. Each sequence represent an interaction of actors with the system.
6/25/12

Specifying the Behavior of a Use Case

Describing the flow of events within the use case. Can be done in natural language, formal language or pseudo-code. Includes: how and when the use case starts and ends; when the use case interacts with actors and what objects are exchanged; the basic flow and alternative flows of the behavior.
6/25/12

Actors
name

6/25/12

An actor represents a set of roles that users of use case play when interacting with these use cases. Actors can be human or automated systems. Actors are entities which require help from the system to perform their task or are needed to execute the systems functions. Actors are not part of the system.

Use Cases and Actors

From the perspective of a given actor, a use case does something that is of value to the actor, such as calculate a result or change the state of an object. The Actors define the environments in which the system lives

6/25/12

Example of Use Case Diagram

studen t

facult y

Relationships between Use Cases

1. Generalization

The child use case inherits the behavior and meaning of the parent use case.
parent

The child may add to or

child

override the behavior of its parent.

6/25/12

More about Generalization

non-graduate registration

graduate registration

6/25/12

2. Include
base

The base use case explicitly incorporates the behavior of another use case at a location specified in the base. The included use case never stands alone. It only occurs as a part of some larger base that includes it.
6/25/12

<<include >>

included

More about Include

Enables to avoid describing the same flow of events several times by putting the common behavior in a use case of its own.
updatin g grades output generatin g
6/25/12

<<include >> <<include >>

verifying student id

3. Extend
base

The base use case implicitly incorporates the behavior of another use case at certain points called extension points. The base use case may stand alone, but under certain conditions its behavior may be extended by the behavior of another use case.
6/25/12

<<extend >>

extending

More about Extend

Enables to model optional behavior or branching under conditions.

Exam copy request

<<exten d>>

Examgrade appeal

6/25/12

Relationships between Actors

Generalization.

stude nt

graduate student
6/25/12

nongraduate student

Actors may be connected to use cases by associations, indicating that the actor and the use case communicate with one another using messages.
updati ng grades
6/25/12

Relationships between Use Cases and Actors

facul ty

Example
place phone call phone network

<<exten d>> <<exten d>>

place conference call receive additional call

receive phone call

user

use scheduler

Mobile Telephone
6/25/12

A More Complicate Example

Update Staff Details Customer 1 Bookshop Manager

Register Details <<include>> <<extend>> Handle Order <<include>> System Login

<<inc lude>>

Update Customer Details

Make Order

Add Items to ShoppingCart

6/25/12

Example

The system is started up when the operator turns the operator switch to the "on" position. The operator will be asked to enter the amount of money currently in the cash dispenser, and a connection to the bank will be established. Then the servicing of customers can begin. The system is shut down when the operator makes sure that no 6/25/12

Example

A session is started when a customer inserts an ATM card into the card reader slot of the machine. The ATM pulls the card into the machine and reads it. (If the reader cannot read the card due to improper insertion or a damaged stripe, the card is ejected, an error screen is displayed, and the session is aborted.) The customer is asked to enter his/her 6/25/12 PIN, and is then allowed to perform

6/25/12