UML

Use Case Diagrams

1
 UML Background
"The Unified Modelling Language (UML) is a graphical
language for visualizing, specifying, constructing, and
documenting the artifacts of a software-intensive system.
The UML offers a standard way to write a systems blueprints,
including conceptual things like business processes and system
functions as well as concrete things such asprogramming
language statements, database schemas, andreusable software
components."

Grady Booch, Ivar Jacobsen, Jim Rumbaugh

Rational Software

[OMG Unified Modelling Language Specification, Version 1.3,

March 2000]
 2.1 Brief UML History
• Around 1980
– first OO modelling languages
– other techniques, e.g. SA/SD
• Around 1990
– "OO method wars"
– many modelling languages
• End of 90's
– UML appears as combination of best practices
 Why UML?
• Physicists know formal graphical modelling
– Mathematics to describe nature
– Feynman graphs to calculate particle reaction rates
• We need a common language
– discuss software systems at a black- (white-) board
– document software systems
– UML is an important part of that language
– UML provides the "words and grammar"
 Introduction
• Getting started is the most difficulty part of any new
process.
• In software modelling, the first thing you need to do is
understand what are you going to model and ultimately
develop.
• Creating a highest form details about a system--use case
diagram--is an almost natural point of origin for the
software design.
• 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.

5
 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.

6
 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.

7
 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 user’s perspective of the system.

8
Use Case Diagram - URS System
URS
add member

del member
system
user add subject academic

del subject

assg subject

unass subject

enrol subject

student
unenrol subject
9
10
 Use Case Diagrams
• A set of ACTORS : roles users can play in interacting with
the system.
– An actor is used to represent something that users our system.
• 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
• A number of RELATIONSHIPS between these entities
(Actors and Use Cases).
– Relationships are simply illustrated with a line connecting actors
to use cases.

11
 Use Case Diagrams - Actors
• An actor is a user of the system playing a
particular role.
• Actor is shown with a stick figure.

employer employee client

12
 Use Case Diagrams – Use Cases
• Use case is a particular activity a user can do on
the system.
• Is represented by an ellipse.
• Following are two use cases for a library system.

Borrow Reserve

13
Use Case Diagram – Example1 (Library)
library system

borrow

client employee
reserve

Order title

Fine payment
supervisor

A Library System. 14
Use Case Diagram for Student Assessment
Management System
Grade system

Record
grades

Student
View grades

Teacher Distribute
Report cards

Create report
cards
Printing administrator

15
 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.

16
 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.

17
 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.

18
Major Area View Diagram Main Concept
Structural Static View Class diagram Class,association,genera
lization,dependency,rea
lization,interface
Use Case View Use case diagram Use case, actor,
association , extend,I
nclude, use case
generalization.
Implementation, Component, Component,interface,de
deployment View deployment pendency,realization
diagram
Node,component,depen
dency,location
Dynamic State machine view Statechart State,event,transition,a
diagram ction
Activity view Activity diagram State,activity,completio
n transition,fork,join

Interaction view Sequence,collabo Interaction, object,

ration diagram message, activation
 Collaboration Collaboration,
diagram interaction,
collaboration role,
message.
Model Model Class diagram Package, subsystem,
Management management model
view
Extensibility All All Constraint,
stereotype.

20
Use Case Diagrams - Relationships
• Inclusion
– Inclusion enables to reuse one use case's steps inside another use
case.
• Extension
– Allows creating a new use case by adding steps to existing use
cases
• Generalization
– Allows child use cases to inherit behavior from parent use cases

21
Use Case – Example (self service machine)

Self service machine

Buy a product
Self service machine
customer
Collect Money

Collector
Self service machine

Restock

Supplier

22
Use Case – Example (self service machine
– includes relationship)
<<includes>>
Open Machine
Restock

<<includes>> Close Machine

<<includes>>
Open Machine
Collect

<<includes>>
Close Machine
23
Use Case – Example (self service machine
– extends relationship)
<<includes>>
Open Machine
Restock

<<includes>>
Close Machine
<<extends>>

Restock According
to Sales

24
 Use Case – Example (self service machine – generalize
relationship): Actor-to-Actor relationship

generalized actor

Supplier Agent

specialized
actor

Restocker Collector
25
 Use Case – Example (self service machine – generalize
relationship): Actor-to-Actor relationship – example 2

generalized actor

Cook

specialized
actor

Mom Cook Father Cook

26
 Use Case – Example (self service machine)
Buy a
product Self Service Machine

<<includes>>
customer Open Machine
Restock

<<includes>> Close Machine

Restock according to sales
<<includes>>
Open Machine
Collect

<<includes>>
supplier Close Machine
27
From Use Case to Classes

28
 Identify Classes (Extract Nouns)
– 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.

29
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.

30
Classes identified in the first pass
– UniversityRecordSystem - URS
– Student
– Academic Staff
– UniversityMembers
– Subject

31
 URS - High Level Class Diagram

URSDataBase

1 1 has

has
* *

UniversityMember Subject

0…10
0..3

* takes
AcademicStaff Student

1 teaches
32