Introduction

UML diagram is designed to let developers and customers view a software

system from a different perspective and in varying degrees of abstraction.
UML has become a standard modeling language because it is programming
language independent.
Since UML is not a methodology, it does not require any formal work products.

UML Modeling
1

Types of UML Diagrams

Types of UML Diagrams

Use Case Diagram

Describes the functional behavior of the system as seen by the user.

Class Diagram
Describes the static structure of the system.

Sequence Diagram
Describe the dynamic behavior between objects of the system.

Use Case Diagram

Example: Login System

Consists of:
o
o
o
o

User browsers the login page and enters the

username & password.
If the login is successful, the user is redirected to the
main page.
Otherwise, user has to re-enter the username and
password.

Actors
Use Cases
The boundary
The relationships between and among the actors and the use cases.

An Actor is a model for an external entity which

interacts with the system.
User
External System
Physical environment (e.g. Weather)

A Use Case represents a class of functionality

provided by the system.
It is a graphical representation of the interaction
among the elements and the system.

Hint: Consider only about the registered users.

Use Case Diagram

The main purpose of the use case diagram is to
capture the dynamic aspect of a system.
The scope of the system can be defined through
use case diagram.

Actor

Use Case

Description of the Use Case

Class Diagram
Consists of:
o Classes
o and their Relationships

A class represents a concept.

A class diagram is a static diagram.
It describes the static structure of a system.

10

Sequence Diagram
Class Name

Often built from a use case and a class diagram.

Sequence diagrams model the dynamic aspects of
a software system.
Consists of:

Attributes

Operations

o Instances of classes/ Objects

o Actors
o Messages

Relationship

11

12

Extend

Extended use case is meaningful on its own, it is independent of the

extending use case.
Extending use case typically defines optional behavior that is not
necessarily meaningful by itself.
Example
Extend relationship is shown as a dashed line with an open
arrowhead directed from the extending use case to the extended
(base) use case. The arrow is labeled with the keyword extend.
<<extend>>

Registration

GetHelpOnRegistration

Registration use case is complete and meaningful on its own.

It could be extended with optional Get Help On Registration use
case.

13

Include

Exercise
User browsers the login page and enters the username &
password.
If the login is successful, the user is redirected to the main
page.
Otherwise if the user is registered, user has to re-enter the
username and password. If the user is unregistered, user
has to register.

Use case include is a directed relationship between two use cases which is
used to show that behavior of the included use case (the addition) is inserted
into the behavior of the including (the base) use case.
The include relationship could be used:
o
o

to simplify large use case by splitting it into several use cases,

to extract common parts of the behaviors of two or more use cases.

Included use case required, not optional.

Base use case is incomplete. See below Example
Checkout use case includes several use cases - Scan Item,
Calculate Total and Tax, and Payment
<<include>>

Draw the;
1. Use Case Diagram of the system.
2. Class Diagram of the system.
3. Sequence Diagram for each use case.

ScanItem

<<include>>
Calculate Total and Tax
Checkout

14

<<include>>

Payment

15

16