Use Cases

Use-cases are a scenario based technique in the UML which identify the actors in an interaction and which describe the interaction itself. A set of use cases should describe all possible interactions with the system. Sequence diagrams may be used to add detail to usecases by showing the sequence of event processing in the system. A use case diagram is an excellent way to communicate to management, customers, and other non-development people what a system will do when it is completed.

Use cases

Use Case Diagrams

Use Case diagrams show the various activities the users can perform on the system.
System is something that performs a function.

They model the dynamic aspects of the system. Provides a users perspective of the system.

Elements of use case

The system The actors The use case Relationship between them Between an actor and use case Generic Between two use cases Inclusion Extension Generalisation Between two actors Generalisation

Use Case Diagrams

A set of ACTORS : roles users can play in interacting with the system. An actor is used to represent something that uses the system. It is an external entity/ can be a data repository. Two types of actors
Active actor: responsible for triggering the functionality of the system. Place active actor on the left side of the use case. Passive actor: Interacting with the functionality of the of system for information interchange. Place passive actor on the right side of the use case.

The role of actor may change based on the functionality active may become passive and vise versa
5

Use Case Diagrams

A set of USE CASES: each describes a possible kind of interaction between an actor and the system. Uses cases are actions that a user takes on a system. Primary use case: Use cases triggered by an actor directly. Represents the main functionality/ purpose of the system. Secondary use case: Use case not triggered directly by the actor. Provides the support functionality. For 20 requirements use cases are 20-25 maximum, not 120. A number of RELATIONSHIPS between these entities (Actors and Use Cases). Relationships are simply illustrated with a line connecting actors to use cases ( association). Direction of arrowhead should not give any information about data flow.

Contents of use case

Goal Trigger Precondition Success scenario Exception Post condition

University Record System (URS)

A University record system should keep information about its students and academic staff. Records for all university members are to include their id number, surname, given name, email, address, date of birth, and telephone number.
Students and academic staff each have their own unique ID number: studN (students), acadN (academic employee), where N is an integer (N>0).

In addition to the attributes mentioned above:

Students will also have a list of subjects they are enrolled in. A student cannot be enrolled in any more than 10 subjects. Academic employees will have a salary, and a list of subjects they teach. An academic can teach no more than 3 subjects.
8

Some Actions Supported by URS

The system should be able to handle the following commands.
Add and remove university members (students, and academic staff) Add and Delete subjects Assign and Un-assign subjects to students Assign and Un-assign subjects to academic staff.

Use Case Diagram - URS System

URS

Administrator

add member

academic

del member
add subject

del subject

assg subject
unass subject

student

enrol subject

10

unenrol subject

Use Case Diagram for Student Assessment Management System

Grade system
Record grades

Student
View grades

Academic

Distribute Report cards

Create report cards

11

Administrator

Use Case Vs Scenarios

Each use case is one or more scenarios. Add Subject Use Case : Scenario 1 : Subject gets added successfully. Scenario 2 : Adding the subject fails since the subject is already in the database. Enroll Subject Use Case: Scenario 1 : Student is enrolled for the subject. Scenario 2 : Enrollment fails since the student is already enrolled in the subject Each scenario has a sequence of steps.
12

Scenarios
Each scenario has a sequence of steps. Scenario 1 : Student is enrolled for the subject. Student chooses the enroll subject action. Check the student has enrolled in less than 10 subjects. Check if the subject is valid. Assign the subject to the student.
13

Scenarios
Each scenario has a sequence of steps. Scenario 2 : Enrolling fails since the student is already enrolled in 10 subjects. Student chooses the enroll subject action. Check the student has enrolled in less than 10 subjects. Return an error message to the student.
14

Use Cases (Advanced)

Base Use Case Actor Common Use Case Base Use Case
<<extend>>

Extending Use Case Base Use Case

Special 15 Actor

<<include>> Special Actor Included Use Case

Use Case Example (self service machine)

Self service machine

Buy a product
customer

Self service machine

Collect Money
Self service machine

Collector

Restock
Supplier
16

Use Case Example (self service

machine includes relationship)
<<includes>> Open Machine Restock

<<includes>>

Close Machine

<<includes>> Open Machine Collect <<includes>>

17

Close Machine

Use Case Example (self service

machine extends relationship)
<<includes>> Open Machine Restock <<includes>> <<extends>>

Close Machine

Restock According to Sales

18

Use Case Example (self service machine generalize relationship): Actor-to-Actor relationship
generalized actor

Supplier Agent

specialized actor
Restocker
19

Collector

Use Case Example (self service machine)

Buy a product

Self Service Machine

<<includes>>

customer

Restock
<<includes> Restock according to sales >

Open Machine

Close Machine

<<includes>> Open Machine Collect

supplier
20

<<includes>>

Close Machine

From Use Case to Classes

21

CLASSES FROM USE CASE BEHAVIORAnalysis class

Boundary classes provide <<boundary>> boudary between the system and the actors. Control classes provide <<control>> control/ coordinating behavior of other classes in the system <<entity>> Entity classes represents store of information in the system

Nouns which are potential classes

A University record system should keep information about its students and academic staff. Records for all university members are to include their id number, surname, given name, email, address, date of birth, and telephone number. Students and academic staff each have their own unique ID number: studN (students), acadN (academic employee), where N is an integer (N>0). In addition to the attributes mentioned above: Students will also have a list of subjects they are enrolled in. A student cannot be enrolled in any more than 10 subjects. Academic employees will have a salary, and a list of subjects they teach. An academic can teach no more than 3 subjects.

23

Classes identified in the first pass

UniversityRecordSystem - URS Student Academic Staff UniversityMembers Subject

24

URS - High Level Class Diagram

URSDataBase

1
*

1 has

has *
Subject

UniversityMember

010

0..3

AcademicStaff
25

Student

takes teaches

Requirements of ATM

Requirements of ATM

Use cases
Identify the actor Actors are entities that interact with the system under design Customer: customers need to perform banking transactions using ATM machine Bank: The bank serving the ATM Operator

Use case: Identify the system components

Identify the use cases

Customer withdraws cash Customer deposits cash Customer repeatedly enters invalid PIN

Withdrawal Transaction Use Case

A withdrawal transaction asks the customer to choose a type of account to withdraw from (e.g. checking) from a menu of possible accounts, and to choose an amount from a menu of possible amounts. The system verifies that it has sufficient money on hand to satisfy the request before sending the transaction to the bank. (If not, the customer is informed and asked to enter a different amount.) If the transaction is approved by the bank, the appropriate amount of cash is dispensed by the machine before it issues a receipt. (The dispensing of cash is also recorded in the ATM's log.) A withdrawal transaction can be cancelled by the customer pressing the Cancel key any time prior to choosing the dollar amount

Use Case Diagram

MVC (Model , View and Control) high level Design of the System:

Class Diagram

LIBSYS viewpoint hierarchy

All VPs

Indirect

Interactor

Domain

Library manager

Finance

Ar ticle providers

Users

Library staff

UI standards

Classification sy stem

Students

Staff

External

Sy stem managers

Cataloguers

Use Case Diagram Example1 (Library)

library system
borrow

client
reserve

employee

Order title

Fine payment

supervisor

37

A Library System.

LIBSYS use cases

Issue of electronic items

Print article sequence

Library class hierarchy

Library item Catalo gue n um ber Acquisition da te Cost T pe y Status Num ber of copies Acquire () Catalo gue () Dispose () Issue () R eturn ()

Pub lished item Title Pub lisher

Recorded item Title Medium

Book A uthor Edition Pub lication da te ISB N

Magazine Y ear Issue

Film Director Date of release Distrib utor

Com puter pro gram V ersion Platfor m

User class hierarchy

Library user Name Address Phone Reg istration # Reg ister () De-reg ister ()

Reader Af filiation

Borrower Items on loan Max. loans

Staff Depar tment Depar tment phone

Student Major subject Home ad dress

Object aggregation

Thank You