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
