Use Case Diagram The purpose is to communicate the

system’s functionality and behaviour to the customer or end user.

Mainly used for capturing user requirements

Work like a contract between end user and software developers

What it Does? Models the system’s intended

functions (use cases) and its surroundings (actors).

Defines the outside (actors) and inside (use case) of the system’s behaviour.

The same use case diagram is used in requirement analysis, design, implementation and testing.

Elements Actor

Represents anything that interacts with the system

Use case A sequence of actions a system

performs that yields an observable result of value to a particular actor

Use Case Diagram (core components)

Actors: A role that a user plays with respect to the system,including human users and other systems. e.g.,inanimate physical objects (e.g. robot);

an external system that needs some information from the current system.

Use case: A set of scenarios that describing an interaction between a user

and a system, including alternatives.

System boundary: rectangle diagram representing the boundary between the actors and the system.

Actor Actors are not part of the system.

The represent roles a user or the system can play.

An actor may actively interchange information with the system.

An actor may be a passive recipient of information.

An actor can represent a human, a machine or another system.

An actor represents a category or a type of a user rather than a physical user.

Student

Finding Actors Who is interested in certain requirement? Where in the organisation is the system used? Who will supply the system with this information,

use this information, remove this information? Who will use this function? Who will support and maintain the system? Does the system use an external resource? What actors do the use case need? Does one actor play several different roles? Do

several actors play the same role?

Use Case A use case models a dialogue

between actors and the system. A use case is initiated by an

actor to invoke a certain functionality in the system.

A use case is a complete and meaningful flow of events.

Taken together, all use cases constitute all possible ways of using the system.

Place order

Finding Use Cases What are the tasks of this actor? Will the actor create, store, change, remove or read information

in the system? What use case will create, store, change, remove or read this

information? Will the actor need to inform the system about sudden, external

changes? Does the actor need to be informed about certain occurrences in

the system? Does the system supply the business with the correct behaviour? What use cases will support and maintain the system? Can all functional requirements be performed by the use cases?

Sources of Information for Use Cases System specification/problem

statement Domain relevant literature Interviews with domain expert Personal knowledge of the domain Legacy systems

Use Case Diagram

CustomerConduct Bank Transactions

ATM Maintenance

Maintain ATM Machine

Run Reports

Bank

Use Case Relationship Association: communication between

an actor and a use case; Represented by a solid line.

Generalization: relationship between one general use case and a special use case (used for defining special alternatives); Represented by a line with a triangular arrow head toward the parent use case.

Use Case Relationship … Include: a dotted line labeled <<include>>

beginning at base use case and ending with an arrows pointing to the include use case. The include relationship occurs when a chunk of behavior is similar across more than one use case. Use “include” in stead of copying the description of that behavior

Extend: a dotted line labeled <<extend>> with an arrow toward the base case. The extending use case may add behavior to the base use case. The base class declares “extension points”.

Use Case Diagram

Diagram Explanation Pay Bill is a parent use case and Bill Insurance

is the child use case (generalization). Both Make Appointment and Request

Medication include Check Patient Record as a subtask (include).

The extension point is written inside the base case Pay bill; the extending class Defer payment adds the behavior of this extension point (extend).

Use Case Documentation Use cases are documented in

A brief description• The purpose of the use case in a few lines

Detailed flow of events• Description of the primary and alternate flow of

events that occur when the use case is initiated

Both documents are written using the terms that the customer understands.

Flow of Events Each use case

Has one normal, basic sequence of transactions.

May have several alternative sequences of transactions.

Usually has several exceptional sequences of transactions handling erroneous situations.

May also have well defined pre- and post-conditions.

Flow of Events … Describe only the events that belong to

the use case. Avoid vague terminologies. Should describe

How and when the use case starts and ends When the use case interacts with the actors What information is exchanged between an actor and the use

case• Do not describe the details of the user interface

The basic flow of events Any alternate flow of events

Use Case Documentation is for … Customers – approve what the system should do. Users – gain system understanding. System developers – document system behaviour. Reviewers – examine the flow of events. System analysts – provide the basis for analysis

and design System tester – used as a base for test cases. Project leader – provide input to project planning. Technical writer – basis for writing the user

manual.

Course Registration Example

Maintain course infoMaintain lecturer info

Maintain student info

Registrar

Generate catalogue

Billing System

Student

Register for courses

Request course roster

Lecturer

Select courses to teach

Scenarios A scenario is an instance of a use case

It is one flow through a use case Each use case will have a web of

scenarios Primary scenarios (happy day scenarios) Secondary scenarios (rainy day

scenarios)

Register for Courses Use Case Scenario John enters the student ID number 369 52 3449

and the system validates the number. The system asks which semester. John indicates the current semester and chooses to create a new schedule.

From a list of available courses, John selects the primary courses English 101, Geology 110, World History 200 and College Algebra 110. He then selects the alternate courses Music Theory 110 and Introduction to Java Programming 180.

Register for Courses Use Case Scenario … The system determines that John has all the

necessary prerequisites and adds him to the course rosters.

The system indicates that the activity is complete. The system prints the student schedule and sends billing information for four courses to the billing system for processing.

Secondary Scenario Some possible secondary scenarios

are: Student does not select 4 primary courses Primary course is not available Primary and secondary courses are not

available Cannot add student to the course roster Cannot create the student schedule

How many scenarios? As many as needed to understand

the system . Rule of thumb:

80% of the primary scenarios Few of the interesting and high risk

secondary scenarios