Introduction to UML
Course Instructor: Aisha Azeem
Introduction
 UML stands for Unified Modeling Language.
 It is a standard language for specifying, visualizing,
constructing, and documenting the artifacts of software
systems.
Specifying
Visualizing
Business Modeling
Constructing
Documenting
Communications
UML Building Blocks
 Class:
 Class represents set of objects having similar
responsibilities.
 Use case:
 Use case represents a set of actions performed by a
system for a specific goal.
 Interaction:
 Interaction is defined as a behavior that consists of a group of
messages exchanged among elements to accomplish a specific task.
Cont . . .
 State machine:
 State machine is useful when the state of an object in its
life cycle is important.
 It defines the sequence of states an object goes through
in response to events. Events are external factors
responsible for state change.
 Note:
 A note is used to render comments, constraints etc of an UML element.
Cont . . .
 Generalization:
 Generalization can be defined as a relationship which connects a
specialized element with a generalized element. It basically describes
inheritance relationship in the world of objects.
 Aggregation:
 Whole part relationship i.e. large part “whole” contains one or more
parts. E.g. building “whole” contains rooms ”parts”
 Composition:
 Is a relationship in which if the “whole” part dies, the child has to die as
well. E.g. if building collapse , rooms no more exist
UML Models, Views,
Diagrams
 UML is a multi-diagrammatic language
 Each diagram is a view into a model
 Diagram presented from the aspect of a particular
stakeholder
 Provides a partial representation of the system
 Is semantically consistent with other views
 Example views
Models, Views, Diagrams
UML Diagrams
 UML diagrams are the ultimate output of the entire
discussion.
 All the elements, relationships are used to make a complete
UML diagram and the diagram represents a system.
 UML includes the following nine diagrams









Class diagram
Object diagram
Use case diagram
Sequence diagram
Collaboration diagram
Activity diagram
State chart diagram
Deployment diagram
Component diagram
UML Modeling Types
 Different diagrams are used for different type of UML
modeling.
 There are three important type of UML modeling :
1) Structural modeling:
 Structural modeling captures the static features of a system.
 They consist of the followings: Class diagrams , Objects
diagrams , Deployment diagrams , Component diagram etc
 Structural model represents the framework for the system and
this framework is the place where all other components exist.
 They all represent the elements and the mechanism to
assemble them.
 E.g. class written once remain same through out the execution.
Cont . . .
2)
Behavioral Modeling:
 Behavioral model describes the interaction in the system.
 It represents the interaction among the structural
diagrams.
 Behavioral modeling shows the dynamic nature of the
system
 Activity diagrams , Interaction diagrams, Use case
diagrams
 Depends upon the behavior of an object/entity object
can have more then one state, and depending upon its
state its behavior would be different.
 E.g. bank account may be working(deposit/ withdraw)
Not working(closed/ dead)
Cont . . .
3)
Dynamic Modeling:

The dynamic model is used to express and model the
behavior of the system over time.

It includes support for activity
diagrams, sequence diagrams
diagrams,
state

e.g. user login(id, password), valid tries to login , its set
of sequences will be different as compared to an
invalid user.
Use-Case Diagram
 Use Case Diagram is used to describe the functionalities
provided by a system and the users associated with that
system.
 The Use case diagram is used to identify the primary elements
and processes that form the system.
 The primary elements are termed as "actors" and the
processes are called "use cases."
 The Use case diagram shows which actors interact with each
use case.
Use-Case Diagram
 The main purpose of the use-case diagram is:
 to help development teams visualize the functional
requirements of a system
 To help identify relationship of "actors" (human beings
who will interact with the system) with essential processes
 and understand the relationships among different use
cases
Elements of a use-case
diagram
 Use-case diagrams contain the following elements:
• Actors, which represent users of a system, including human
users and other systems.
• Use Cases, which represent
provided by a system to users.
functionality
or
services
Actor
 Definition:
 The outside entity which communicates with the system:
 A Person (user)
 An external system
 Physical Environment
 An Actor has a unique name and an optional
description
 Symbol:
UML notation used to represent an
actor
Actor (Example)
 Consider the following scenario related to a “University
Management System” :
 In a university management system, a Student can submit
the assignments, the instructor marks those assignments
and then uploads the result. The Student is allowed to
view the Results.
 Now, by recalling the definition of actor, can you identify
the actors in this System?
 Student
 Instructor
Actor (Example/2)
Instructor
Student
Student
Student
is
an
external
entity
which
interacts
with the system.
Student is a user of
this
system,
as
some services are
used by it.
Instructor
Instructor is another
external
entity
which interacts with
the
university
management
system.
Use-case
 Represent functionality or services provided by a system to
users.
 It is a description of set of sequence of actions that a system
perform that produces an observable result.
 A use case represents a class of functionality provided by the
system as an event flow.
 Use cases describe the interaction between a primary actor
and the system itself
Use-case
 The use case technique is used in software and systems
engineering to capture the functional requirements of a
system.
 Each use case describes how the actor will interact with the
system to achieve a specific goal.
 One or more scenarios may be generated from each use
case, corresponding to the detail of each possible way of
achieving that goal.
 Symbol :
UML notation used to represent a usecase
Use-case (Example)
 Consider the same example again:
 In a university management system, a Student can submit
the assignments, the instructor marks those assignments
and then uploads the result. The Student is allowed to view
the Results.
 Now, by recalling the definition of use-case, can you
identify the use-cases in this System?




Submit Assignments
Mark Assignments
Upload Results
View Results
Use-case (Example/2)
 The use-cases are linked with the functional requirements of
this system. In this example :
 Student submit the assignments.
 Instructor marks the assignments.
 Instructor upload the marks.
 Student can view the marks.
 It is now clear that how actors are interacting with different
use-cases of this system.
 Now, lets combine actors and use-cases in one diagram?
Symbols in Use-Case
Diagrams
ACTOR
USE-CASE
INTERACTION:
denotes set of messages exchanged among
objects
NOTES/COMMENTS
Use-Case Diagram (University
Management System)
Submit
Assignments
Mark
Assignments
Student
Upload
Results
View Results
Instructor
Package:
System
University Management
SYSTEM
BOUNDARY
Cont . . .
 Other types of associations and relationships;




Generalization between use cases
Generalization between actors
Include relationship between use cases
Extend relationship between use cases
Generalization between Use
cases
 Represented by a line and a hollow arrow
 From child to parent
 A use case generalization shows that one use case is
simply a special kind of another.
 A child can be substituted for its parent whenever
necessary.
 Generalization appears as a line with a triangular arrow
head toward the parent use case
Child use case
Parent use case
Example
Register car
sharer
Manually
add car
sharer
CarMatch
Administrator
Example : ATM
Transfer car
sharer from
web server
Web Server
Generalization between
Actors (examples)
student
Foreign student
Local student
Include relationship
between use cases
 Some times one use case includes the functionality of
another use case.
 Include relationship is drawn as an open arrow with dashed
lines that points towards the use case that is being included
 The word include is written in << . . . . . . >>
Or
 If x is a task and y is a sub task but acting as a part of it then
use <<include >> stereotype
 Arrowhead towards the subtask
Example
Extend relationship
between use cases
 There are occasions where one use case may optionally be
extended by the functionality in another use case.
 The relationship is drawn as an open arrow with dashed line
the points towards the use case that is being extended.
 The word extend is written in <<……..>>
Or
 If x is a task and y is a sub task of x but little bit different
 Arrow head towards the main task
Example
Take turn
Driver
<<extends>>
Passenger
Turn left
Purchase Ticket
<<extends>>
<<extends>>
OutOfOrder
<<extends>>
<<extends>>
Cancel
NoChange
TimeOut
<<extends>>
Turn right
Practice
 Read the following case :
 Identify the actors
 Identify (extract ) the use cases
 Construct a proper use-case diagram (with proper
symbols & notations)
Case-Study
 Consider the Library Management System of UOW. A Student is
allowed to issue books for a period of two weeks. Student can
read newspapers/magazines in the library and can even
access the databases for e-books. The Library Staff is
responsible for maintaining the records of students and along
with the issued books. The Staff marks an entry in the register
whenever a student issue or return a book. A fine is charged on
a student if he/she fail to return the book on time. The Librarian
is there to manage the staff, check the records and prepare
reports for DG/DEAN.
Class diagrams
 Gives a graphical representation of domain model.
 It represents relationship of classes objects with object
specification in detail.
 It gives static view of the system
 Each class is represented by a rectangle subdivided into
three compartments
 Name
 Attributes
 Operations
Class Diagram: Visibilities
 Modifiers are used to indicate visibility of attributes and
operations.
 ‘+’ is used to denote Public visibility (everyone)
 ‘#’ is used to denote Protected visibility (derived)
 ‘-’ is used to denote Private visibility (no one)
 By default, attributes are hidden and operations are
visible.
 The last two compartments may be omitted to simplify
the class diagrams
An example of Class
Account_Name
- Custom_Name
- Balance
+AddFunds( )
+WithDraw( )
+Transfer( )
Name
Attributes
Operations
Other representations of
class
Boeing 737
Boeing 737
length: meter
fuelCapacity: Gal
Boeing 737
length: meter
fuelCapacity: Gal
doors: int
Boeing 737
lift()
roll()
doors: int
lift ( )
roll ( )
thrust ( )
Class Attributes (Cont’d)
Person
Attributes are usually listed in the form:
attributeName : Type
name
: String
address : Address
birthdate : Date
/ age
: Date
ssn
: Id
A derived attribute is one that can be
computed from other attributes, but
doesn’t actually exist. For example,
a Person’s age can be computed from
his birth date. A derived attribute is
designated by a preceding ‘/’ as in:
/ age : Date
Class Attributes (Cont’d)
Person
+ name
: String
# address : Address
# birthdate : Date
/ age
: Date
- ssn
: Id
Attributes can be:
+ public
# protected
- private
/ derived
Class Diagram: Association
• Associations represent relationships between instances
of classes .
• An association is a link connecting two classes.
 Bi-directional association
Associations are assumed to be bi-directional
BankAccount
Person
 Uni-directional association
e.g. Bank Account and person
BankAccount
Person
Association: Multiplicity
and Roles
teaches
Student
1..*
learns from
1..*
Instructor
Multiplicity
Symbol
Meaning
1
One and only one
0..1
Zero or one
M..N
From M to N (natural language)
*
From zero to any positive integer
0..*
From zero to any positive integer
1..*
From one to any positive integer
Note: if no multiplicity is given it is assumed to be 1
Association name: represents nature
of participants classes in a relationship.
Association Role: role played by the
participant class
Notation of Class Diagram:
Generalization
Student
Employee
Supertype
TeachingAssistant
Subtype1
Subtype2
Person
Generalization expresses
a relationship among
related classes. It is a
class that includes its
subclasses.
Student
Cont . . .
Separate target style
Vehicle
Bus
Truck
Car
Shared target style
BoeingAirplane
Boeing 737
Boeing 757
Boeing 767
Notation of Class Diagram:
Composition
COMPOSITION
•Composition: expresses a relationship
among instances of related classes.
•It is a specific kind of Whole-Part
relationship.
Whole Class
Class W
Class P1
Class P2
Part Classes
Example
Automobile
Engine
windows
•It expresses a relationship where an
instance of the Whole-class has the
responsibility to create and initialize
instances
of
each
Part-class.
Composition should also be used to express
relationship where instances of the Wholeclass have exclusive access to and
control of instances of the Part-classes.
Cont . . .
Car
1
4
Wheel
1
4, 10
Light
1
1
2, 5
1
Door
Engine
Notation of Class Diagram:
Aggregation
AGGREGATION
Container Class
Class C
Class E2
Class E1
Containee Classes
Example
Apples
Aggregation: expresses a relationship
among instances of related classes. It
is a specific kind of ContainerContainee relationship.
It expresses a relationship where an
instance of the Container-class has the
responsibility to hold and maintain
instances of each Containee-class
Aggregation is appropriate when
Container and Containees have no
special access privileges to each
other.
Bag
Milk
Cont. . .
Team
1
class
Consists Of
*
Player
Aggregation vs. Composition
• Composition is really a strong form of aggregation
•components have only one owner
•components cannot exist independent of their owner;
• both have coincident lifetimes
•components live or die with their owner
•e.g. (1)Each car has an engine that can not be share with other
car
(2) If the polygon is destroyed, so are the points.
•Aggregations may form "part of" the aggregate, but may not be
essential to it.
•They may also exist independent of the aggregate. Less rigorous
than a composition
• e.g. (1)Apples may exist independent of the bag.
(2)An order is made up of several products, but the
products are still there even if an order is cancelled.
Class Diagram example
Name
Order
Attributes
Operations
-dateReceived
-isPrepaid
-number :String
-price : Money
class
Multiplicity: mandatory
*
Customer
1
+dispatch()
+close()
Association
-name
-address
+creditRating() : String()
1
Generalization
Multiplicity:
Many value
Corporate Customer
Personal Customer
-contactName
-creditRating
-creditLimit
-creditCard#
+remind()
+billForMonth(Integer)
*
Multiplicity:
optional
0..1
Employee
*
OrderLine
-quantity: Integer
-price: Money
-isSatisfied: Boolean
*
1
Product