se_lec 08_uml use cases

2

A use case consists of a series of actions that a user

must initiate with the system to carry out some useful

work and to achieve his/her goal.

A use case is a sequence of transactions performed by a

system that produces a measurable result for a

particular actor.

Use cases specify the expected behavior [what], and

not the exact method of making it happen [how]

A good use case must represent the point of view of the

people who will use or interact with the system.

A complete set of use cases = system requirements.

3

A use case diagram enables the system designer todiscover the requirements of the target system from theuser's perspective.

If the designer uses use case diagrams in the early stageof system development, the target system is more likelyto meet the needs of the user.

From both the designer and user’s perspectives, thesystem will also be easier to understand.

Use cases are created based on identified functional

requirements but are not mapped one-to-one to

requirements.

4

A use case diagram consists of three main components:

Actors,

Use Cases, and their communications, and

some additional documentation such as use case

descriptions for elaborating use cases and problem

statements that are initially used for identifying use

cases.

In addition, a use case diagram may consist of a system

boundary.

6

Actors

Actors are the external entities that interact with the

system.

Represent roles that humans, hardware devices, or

external systems play while interacting with a given

system

They are not part of the system and are situated outside

of the system boundary

Actors may be both at input and output ends of a use case

An actor represents a role that a user can play, but not a

specific user.

7

Primary actors:

Primary actors use the system to achieve an observable user

goal.

Primary actors are completely outside the system and drive

the system requirements.

Secondary actors:

play a supporting role to facilitate the primary actors to

achieve their goals.

Secondary actors often appear to be more inside the system

than outside.

8

Define system boundary to identify actors correctly

Identify users and systems that depend on the system’s

primary and secondary functionalities

Identify hardware and software platforms with which

the system interacts

Select entities that play distinctly different roles in the

system

Identify as actors external entities with common goals

and direct interaction with the system

Denote actors as nouns

9

Use Case

A use case describes a sequence of actions a system

performs to yield an observable result or value to a

particular actor.

Naming convention = verb + noun or verb + noun phrase,

e.g. withdraw cash.

10

Lines between Actor and Use Case summarize

interactions graphically

Actors and use cases exchange information to achieve the

goal but the details of interaction are not shown

11

Describe a sequence of transactions performed by a

system that produces a measurable result (goal) for a

particular actor;

Describe the behavior expected of a system from a

user's perspective;

Enable the system analyst to understand and model a

system from a high-level business viewpoint; and

Represent the interfaces that a system makes visible to

the external entities and the interrelationships between

the actors and the system.

12

An automatic teller machine (ATM) system is typically

used by different types of users (actors).

You are given a task to develop software for such an

ATM system.

The manager of the bank explains the first requirements

of the system: The user can open and close accounts. He

or she withdraws and deposits cash. The user can view

his / her accounts, and can make cash transfer between

his / her accounts.

13

actor

communication

system boundary

use case

system name

14

We will consider a simple hotel information system for

two types of customers:

Tour Group customers and Individual customers.

Tour Group customers are those who have made

reservations through a tour operator in advance

while Individual customers make their reservations

directly with the hotel.

Both types of customers can book, cancel, check-in

and check-out of a room by phone or via the

Internet.

16

In the process of developing a use case model, we may

discover that some use cases share common behaviors.

There are also situations where some use cases are very

similar but they have some additional behaviors.

17

Use Case: Withdraw Money

Flow of Events:

1. The user inserts an ATM card. The

system prompts the user to enter a

password.

2. The user enters the password. The

system validates the user password.

....

….

….

Use Case: Deposit Money

Flow of Events:

1. The user inserts an ATM card. The

system prompts the user to enter a

password.

2. The user enters the password. The

system validates the user password.

....

….

….

Common

Behavior

18

Use Case: Withdraw Money

Flow of Events:

1. include (login)

....

….

….

Use Case: Deposit Money

Flow of Events:

1. include (login)

….

….

…..

Use Case: Login Account

Flow of Events:

1. The user inserts an ATM card. The system prompts

the user to enter a password.

2. The user enters the password. The system validates

the user password.

20

Include relationships are used when two or more use

cases share some common portion in a flow of events.

This common portion is then grouped and extracted to

form an inclusion use case for sharing among two or

more use cases.

Most use cases in the ATM system example, such as

Withdraw Money, Deposit Money or Check Balance,

share the inclusion use case Login Account.

Include relationship: Allows reuse of functionality by

multiple use cases

21

Login Account

(Included use case)

Withdraw Money

(Base use case)

22

Extend relationships are used when two use cases are

similar, but one does a bit more than the other.

For example, you may have a use case that captures the

typical case (the base use case) and use extensions to

describe variations.

A base use case may therefore conditionally invoke an

alternative use case.

24

Process Excess Amount (Extending use case)

Withdraw Money (Base use case)

If conditional guard is true, extending flow is executed.

25

Alternative flow of events

Base use case flow of events

Alternative flow does not return to the point at which it isinserted. <<extend>> relationship is for modelingalternative flow!

26

Exception flow of events

Base use case flow of events

Exception flow may or may not return to a base usecase flow. <<extend>> relationship is not formodeling exceptions.

27

Shows inheritance and specialization

One use case is simply a special kind of another

29

Base use case – invoked directly by actor to achieve an

observable goal.

Abstract use case – invoked by other use cases and is not

a complete goal from user’s perspective.

e.g. withdraw cash (concrete use case) vs login (abstract

use case)

30

Organize use cases by grouping them in packages as in

the organization of classes

Generalization

• One use case is a special case of another

Includes

• Included use case embodies common behavior

Extends

• Extending use case adds behavior

31

A use case is a description of what a system is used for,

and who uses it, without providing details of how it

performs its functions.

A use case description serves as an agreed description

between the user and the system designer on the flow of

events that would happen when a use case is invoked.

A use case description is explained and elaborated

through scenarios (a set of sequences of actions).

Each of these scenarios is simply an instance of the use

case.

33

A brief user story explaining who is using the system and

what they are trying to accomplish.

Specify behavior of use case by description, not modeling

Examples include informal structured text, formal structured

text with conditions, and pseudocode

Typically specifies:

How and when the use case starts and ends

Interaction with the actors and the exchange of objects

Flow of events:

• main / typical (success),

• alternative(success), and

• exceptional (failure) flows

34

In a human resources system, for the “Hire Employee”

use case, the following scenarios may apply:

Typical success scenario: Hire a person from outside

of the company, for example, from another company

Alternative success scenario: Hire a person from

within the same company, for instance, from another

division

Exceptional failure scenario: No qualified person

could be hired

35

Entry and Exit Conditions

Entry conditions describe the environment under

which the use case is invoked

Exit conditions reflect the impact of the use case on

the environment through its execution

Quality Requirements

Describe quality attributes in terms of a specific

functionality

For example, requires system response in < 30

seconds

36

Extract the functionality that is available to each actor

Establish specific instances and not general descriptions

Denote situations in the current and future systems

Identify:

Tasks to be performed by the user and the system

Flow of information to the user and to the system

Events that are conveyed to the user and to the system

For the events flow, name steps in active voice

37

Informal Description:

For this case study, the task is of constructing the

design elements for a system that can be used to

manage courses and classes for an organization that

specializes in providing training. The name of the

system is Courseware System. The organization offers

courses in a variety of areas such as learning

management techniques and understanding different

software languages and technologies. Each course is

made up of a set of topics.

38

Informal Description(Cont.):

Tutors in the organization are assigned courses to teach

according to the area that they specialize in and their

availability. The organization publishes and maintains a

calendar of the different courses and the assigns tutors every

year. There is a group of course administrators in the

organization who manage the courses including course

content, assigning courses to tutors, and defining the course

schedule. The training organization aims to use the

Courseware System to get a better control and visibility to

the course management and to also streamline the process of

generating and managing schedules for different courses.

39

The following terms and entities are specific to the

system:

Courses and Topics that make up courses

Tutors that teach courses

Course Administrators who manage the assignment of

courses to tutors

Calendars and Course Schedules that are generated as a

result of the work performed by the course administrators

Students who refer to Calendars and Course Schedules

todecide which courses they wish to take up for study

40

Actors: Tutor, Student, Course Administrator (main

actor)

Use Cases (primary business: secondary user)

Manage courses: View courses, Manage topics for a

course, and Manage course information

Manage tutors: View course calendar, View tutors,

Manage tutor information, and Assign courses to

tutors

43

Use Case: Manage Course Information (UC_ID1)

Participating Actors: Course Administrator

Entry Conditions: Course Administrator is logged into

Courseware

Exit Conditions: Course Administrator has received an

acknowledgement from the system that the selected

transaction is complete, or if not complete, a message

explaining the failure

Quality Requirements: (Performance) Course

Administrator receives a response from the system in less

than 3 seconds

Related Requirements: Create, Modify, and Delete Course

…

44


Typical flow of events:

1. Course Administrator selects Create New Course

– System invokes Create New Course use case

2. Course Administrator selects Modify Existing Course

– System invokes Modify Existing Course use case

45

Use Case: Create New Course (UC_ID2)


Extends: Manage Course Information (UC_ID1)

Entry Conditions: Course Administrator has selected

Create New Course option


acknowledgement from the system that a course has been

created, or if not, a message explaining the failure



than 3 seconds

Related Requirements: Create Course

…

46



1. Course Administrator enters New Course Information

a) System invokes Validate Course Information use case

b) For a valid response, system creates a new course entry and

sends an acknowledgment back to the actor

Exceptions:


b) Invalid response received, so system reports failure with a

message indicating invalid course information

47

Use Case: Modify Existing Course (UC_ID3)


Extends: Manage Course Information (UC_ID1)


Modify Existing Course option



modified, or if not, a message explaining the failure



than 3 seconds

Related Requirements: Modify and Delete Course

…

48



1. Course Administrator selects Find Existing Course option

a) System searches for a selected course and returns existing

course information

2. Course Administrator enters new course information

a) System invokes Validate Course Information use case

b) For a valid response, system updates the existing course

entry and sends an acknowledgment back to the actor

49


Alternatives:

1. Course Administrator selects Delete Existing Course option

a) System invokes Delete Existing Course use case

Exceptions:

1. Course Administrator selects Find Existing Course option

a) System searches for a selected course and returns failure

stating that the course could not be found


b) Invalid response received, so system reports failure with a

message indicating invalid course information

50

Use Case: Delete Existing Course (UC_ID4)


Extends: Modify Existing Course (UC_ID3)


Delete Existing Course option



deleted, or if not, a message explaining the failure



than 3 seconds

Related Requirements: Delete Course

…

51

Use Case: Delete Existing Course (UC_ID4)


a) System deletes a selected course and sends an

acknowledgment back to the user

Exceptions:

a) System cannot delete a selected course so it returns

failure stating that the course could not be deleted

se_lec 08_uml use cases

Software