Unified Modeling Language (UML)

an overview

Specification and Analysis of Information Systems Spring 2005 1

Objectives

– Explaining the Class diagram and illustrating its notation

– Explaining the purpose and notation of the Object diagram
– Comparing the Object and Class diagrams
– Defining the purpose of the Sequence diagram
– Illustrating the Sequence diagram notation

Unified Modeling Language (UML): an overview, Session 3 2

 Class Diagram

Unified Modeling
Specification Language
and Analysis (UML): an overview,
of Information Systems Session 3 Spring 2005 3
The Class Diagram
• The Class diagram is the primary diagram for code generation and
for reverse engineering
• The Class diagram shows the structure of data, the relationships
between data and the operations applied on data (behavior)
• Diagram creation often reveals:
– Missing data
– Missing relationships
– Conflicting data or relationships
– Incorrect relationships
– Poor partitioning of data
– Faulty assumptions
– Redundant information
– Ways data can become corrupted

Unified Modeling Language (UML): an overview, Session 3 4

 Classes and Packages
Produt
Class Name
- serialNumber
- name
# price Attributes
+ buy()
+ display()
- swap(x:int,y: int) Operations

Package diagram

A"
em
st
sy
-To simplify complex class diagrams, we can group classes

ub
"S
ed
into Packages

m
na
- Packages appear as rectangles with small tabs at the top

ge
a
-The package name is on the tab or inside the rectangles

ck
pa
-The dotted arrows are dependencies

L
UM

Unified Modeling Language (UML): an overview, Session 3 5

Attributes
Produt

- serialNumber
- name
# price

+ buy()
• An attribute is a property of a class + display()
- swap(x:int,y: int)

• In the example above, we are told that a Product has a

serial number, name and price
• It is generally understood that when implementing the
class, operations are provided to set and retrieve the
information stored in attributes
• The signature describes everything needed to use the
operation

Unified Modeling Language (UML): an overview, Session 3 6

Attributes - Signature

[visibility] name [[multiplicity]] [: type] [=initial value] [{property}]

- visibility: the access rights to the attribute

- multiplicity: how many instances of the attribute are they:
- middleName [0..1] : String, phoneNumber [1..10]: Integer
- Type: the type of the attribute (integer, String, Person,
Course)
- initial value: a default value of the attribute
- salary : Real = 10000
- property: predefined properties of the attribute
- Changeable, readOnly, frozen (C++: const, Java: final)

Unified Modeling Language (UML): an overview, Session 3 7

Attributes - Examples
+ isLightOn : boolean = false
- numOfPeople : integer
# passengers : Customer[0..10]
~ id : long {readOnly}

Public (+) allows access to objects of all other classes

Private (-) limits access within the class itself
Protected (#) allows access by subclasses
Package(~) allows access to other objects in the same package

Unified Modeling Language (UML): an overview, Session 3 8

Class operations
• An operation is the implementation of a service that can
be requested from any object
• Used to manipulate the attributes or to perform other
actions
• Operations are normally called functions but they are
inside a class and can be applied only to objects of that
class
• The signature describes everything needed to use the
operation

Unified Modeling Language (UML): an overview, Session 3 9

Class operations - Signature

[visibility] name [(parameter-list)] [: return-type] [{property}]

• An operation can have zero or more parameters, each has

the syntax:
– [direction] name : type [=default-value]
– Direction can be: in (input paremter - can’t be modified), out (output
parameter - may be modified), inout (both, may be modified)
• Property:
– {abstract} – cannot be called directly
– …

Unified Modeling Language (UML): an overview, Session 3 10

Class operations - Examples
+ isLightOn() : boolean
~ addColor(newColor : Color) : void
# convertToPoint(x : int, y : int) : Point
- changeItem([in] key : string, [out] newItem :
Item) : int

We will try to keep the visibility as minimal as possible

Unified Modeling Language (UML): an overview, Session 3 11

Class associations
• Associations are structural relationships where
instances (objects) of one class are connected to
instances (objects) of another class

Produt Order

serialNumber orderID
name * * date
price includes
checkout()
buy() addProduct(Product p)
display() clearAll()

Unified Modeling Language (UML): an overview, Session 3 12

Class associations
Produt Order

serialNumber orderID
name * * date
price includes
checkout()
buy() addProduct(Product p)
display() clearAll()

Name + reading direction

Multiplicity
 Objects on both sides of the Indicates cardinality
• – 1:1default
association can find each other •3 – exactly 3 object
•* (or n) - unbounded
 Multiplicity defines the number of •1..* - 1 to eternity
objects with an instance of the •3..9 – 3 to 9
association
Unified Modeling Language (UML): an overview, Session 3 13
 Object Diagram

Unified Modeling
Specification Language
and Analysis (UML): an overview,
of Information Systems Session 3 Spring 2005 14
Object diagrams

Object Diagrams describe the static structure of a system

at a particular time.
time Whereas a class model describes
all possible situations, an object model describes a
particular situation

Object diagrams contain the following elements:

• Objects, which represent particular entities. These are
instances of classes.
• Links, which represent particular relationships between
objects. These are instances of associations.

Unified Modeling Language (UML): an overview, Session 3 15

Object diagrams
• The Object diagram is used to analyze the objects in the problem domain in
order to determine the class definition requirements
• After the Class diagram has been developed, the Object diagram is used to
test the Class diagram
• Objects are identified with a name in the form object-name: class-name.
The object name can be left off to indicate an anonymous object
• The object icon consists of two compartments, one for the name and one
for the attributes. Attributes are described with a name and the current value
• Operations are not defined on objects because every object of the same
class would have identical operations
• Objects are connected using links. Classes are connected using
associations. Links are defined with a name and optional roles. Multiplicity is
not relevant with a link

Unified Modeling Language (UML): an overview, Session 3 16

Object Diagrams
• In an Object Diagram, class instances can be
modeled

Produt Apple Ipod : Product

serialNumber
name
price In runtime Apple IMac : Product

buy() name = “IMac 1C”

display() price = 1456 $
Sony Vaio : Product serialNumber = 184934
name = “Vaio Portable”
price = 2999 $
serialNumber = 113234

Class Diagram Object Diagram

Unified Modeling Language (UML): an overview, Session 3 17

Comparison of the Class and Object Diagrams

Unified Modeling Language (UML): an overview, Session 3 18

Class associations
Navigation
Folder File

Why is it directional? For example, if

we want to know the files of each
folder. However, we do not have a
requirement for knowing the folder of
each file.

• If an association is directed, messages can pass only on that

direction
• If the association does not have directions, then it’s defined as
a bidirectional association, and messages can pass in both
directions

Unified Modeling Language (UML): an overview, Session 3 19

 Association Classes
Denoted as a class attached to the association, and
specify properties of the association

Produt Order

serialNumber orderID
name * * date
price
checkout()
buy() addProduct(Product p)
display() clearAll()

OrderItem
According to the
An association class is requirements, each
a “normal” class, and numberOfProducts : int
giftWrap : boolean product can appear is
may include relations, several orders, and each
addAnother()
inheritance etc. removeOne() order may include
several products

Unified Modeling Language (UML): an overview, Session 3 20

Association Class - Objects

Links should be
verified, according
to the association
multiplicity
For each link, an
association class
instance should be
declared

Unified Modeling Language (UML): an overview, Session 3 21

Role Names
• Names may be added at each end of the association
• Provide better understanding of the association meaning
• Especially helpful in self-associated classes

Worker * 1..* *
Person Company
employee employer
employs
0..1
Manages Manager

Reflexive association: A class has an association to its self

Unified Modeling Language (UML): an overview, Session 3 22

Dependency
• Dependencies are the most abstract type of
relations
• Properties:
– Dependencies are always directed (If a given class depends
on another, it does not mean the other way around).
– Dependencies do not have cardinality
• Types:
– «calls»
– «creates»
– «modifies»

Unified Modeling Language (UML): an overview, Session 3 23

Dependency
• Notated by a dotted line
• The most general relation between classes
• Indicates that an object affects another object

Accounting
SecurityControl
System

<<creates>> <<modifies>>
AccountingSystem
creates a Receipt
object Reciept Order

Unified Modeling Language (UML): an overview, Session 3 24

Generalization characteristics
• A generalization/specialization relationship, in which
objects of the specialized element (child) are
substitutable for objects of the generalized element
(parent)
– Superclass” the generalization of another class, the child
– Subclass” the specilization of another class, the parent
• Identify common features concerning behavior and
knowledge. Define these common features on a
higher level in the inheritance hierarchy
• The aim is at behavior more than knowledge when
combining classes

Unified Modeling Language (UML): an overview, Session 3 25

Generalization – Definitions
• Super Class (Base class)
– Provides common functionality and
data members Super Class
• Subclass (Derived class)
– Inherits public and protected
members from the super class
…
– Can extend or change behavior of
super class by overriding methods
• Overriding
– a subclass or child class to provide a Subclass
specific implementation of a method
that is already provided by one of its
super classes or parent classes

Unified Modeling Language (UML): an overview, Session 3 26

 Generalization – advantages
• Modularity GraphicComponent

– Eliminate the details x : int

y : int
– Find common characteristics paint()

among classes repaint()

– Define hierarchies
• Reuse Button Image

– Allow state and behavior to be caption : String picture : File

specialized press() paint()

ImageButton

Overriding
Multiple clickImage()

Inheritance

Unified Modeling Language (UML): an overview, Session 3 27

 Generalization Guidelines
• Look carefully for similar properties between
objects, sometimes they are not so obvious
User Interface

updateName(...)
What’s the updateDesc(...)

problem
here?

Document Product Order Worker

id : long id : long * id : long id : long

*| includes
name : String name : String name : String name : String
desc : String desc : String desc : String desc : String
subject : Subject availability : int date : Date Salary : Float
workYears : int
getCategory() : getCategory() :
*
Category Category
Done by } *
*
*
*
*

Category

name : String
importance : int

Unified Modeling Language (UML): an overview, Session 3 28

 Generalization

Resource
ID and name User Interface

are common id : long

name : String updateName(...)
updateDesc(...)
to all classes desc : String

Order Worker Product Document

date : Date Salary : Float availability : int subject : String

Done by } workYears : int date : Date
* *

includes }
* *

CategorizedResource Category
* *
getCategory() : name : String
Category importance : int

Unified Modeling Language (UML): an overview, Session 3 29

Aggregation
• “Whole-part” relationship between classes
• Assemble a class from other classes
– Combined with “many” - assemble a class from a couple of
instances of that class

Word Processing
Document

Author
fileName
Permission
*
*
* Picture

Folder

name

Unified Modeling Language (UML): an overview, Session 3 30

Composition

• Composition is a stronger form of aggregation

• Contained objects that live and die with the container
• Container creates and destroys the contained objects

Window
Operating
System
close()
move()

0..2 1

Slider Header Panel

Unified Modeling Language (UML): an overview, Session 3 31

Composition vs. Aggregation
Aggregation Composition

Part can be shared by several Part is always a part of a single

wholes whole
0..4 * *
category document Book Chapter
Parts can live independently Parts exist only as part of the
(i.e., whole cardinality can be whole. When the whole is
0..*) destroyed, they are destroyed

Whole is not solely responsible Whole is responsible and

for the object should create/destroy the
objects

Unified Modeling Language (UML): an overview, Session 3 32

Constraints
• Constrains are simple properties of associations,
classes and many other things in UML
• Specify limitations that implementers need to satisfy
• The only use is that we put them inside braces {}
Window
length {0.8 length/width1.5}
width
memberOf *
Committee
* {subset}
0..1 chairOf
*
{salary < [Link]} Employee 0..1
salary
* boss

Unified Modeling Language (UML): an overview, Session 3 33

Class Diagram Guidelines
• A naïve model may have a
Book bad problem of coupling:
systemNumber : long – Data is inter-related
title : String
author : String – It is difficult to manage data
orderOfAuthor : int
category : String[]
items individually
copyNumber : long
holderName : String
• Normalization:
returnDate : Date
location : String
– A collection of design
courseId : String strategies
courseName : String
– Ensures loosely coupled
design
Naïve Model • Origin: relational database
– But, we do not have primary
keys in Class diagram

34
 Class Diagram Guidelines
All properties must have a final number of values

Book
Book
systemNumber : long
title : String systemNumber : long
author : String title : String
orderOfAuthor : int author : String * Category
*
category : String[] orderOfAuthor : int categorized
copyNumber : long copyNumber : int name : String
holderName : String holderName : String
returnDate : Date returnDate : Date
location : String location : String
courseId : String courseId : String
courseName : String courseName : String

The number of
categories for a
book is unbounded

35
Class Diagram Guidelines
All properties must depend on the whole
class essence, and not just a part of it
Order
Author
orderOfAuthor : int 1..*
Book name : String

systemNumber : long
title : String written by
author : String * Category
*
orderOfAuthor : int categorized * Category
copyNumber : int Book name : String *
holderName : String categorized name : String
systemNumber : long *
returnDate : Date title : String
location : String courseId : String
courseId : String courseName : String
courseName : String location : String
1..*
Has Copy

copyNumber : int
holderName : String
returnDate : Date
location : String

36
Class Diagram Guidelines
All properties must depend only on the class’s
essence
Order Order
Author Author
orderOfAuthor : int orderOfAuthor : int
1..* 1..*
name : String name : String

written by written by Category

*
* *
Category name : String
Book Book
* categorized
*
name : String
systemNumber : long * categorized
systemNumber : long 1..*
Copy
title : String title : String
courseId : String location : String Has copyNumber : int
courseName : String holderName : String
1..*
location : String returnDate : Date
1..*
Has Copy
Textbook of
copyNumber : int
Course
holderName : String
returnDate : Date courseId : String
location : String courseName : String

37
Applying the Class diagram on the Case study

Unified Modeling Language (UML): an overview, Session 3 38

‫‪Building an Object diagram for the Case study‬‬

‫– نريد تصميم نظام للتحكم بقائمة محتويات مستودع حيث يتم تسجيل معلومات‬
‫خاصة بالمنتجات المخزنة في المستودع وبالمنتجات المشحونة منه‪ .‬بعد استالم‬
‫المنتجات المشتراة من البائعين وتخزينها في المستودع‪ ,‬يتم بيعها كما وردت أو‬
‫يتم تجميع عدة منتجات مع بعضها البعض لتباع على شكل منتج خاص‬
‫بالمستودع‬

‫‪39‬‬
Building an Object diagram for the Case study

Unified Modeling Language (UML): an overview, Session 3 40

Building an Object diagram for the Case study

Unified Modeling Language (UML): an overview, Session 3 41

Building an Object diagram for the Case study

Unified Modeling Language (UML): an overview, Session 3 42

Building an Object diagram for the Case study

Unified Modeling Language (UML): an overview, Session 3 43

Applying the Class diagram on the Case study

Unified Modeling Language (UML): an overview, Session 3 44

 Building an Object diagram for the Case study

Before

After

Unified Modeling Language (UML): an overview, Session 3 45

 Sequence Diagram

Unified Modeling
Specification Language
and Analysis (UML): an overview,
of Information Systems Session 3 Spring 2005 46
Diagrams in UML
A Diagram is the graphical presentation of a set of elements.
UML includes 9 principal diagrams:
1. Class and object diagrams are static model
1. Class Diagram views. Interaction diagrams are dynamic.
2. Object Diagram They describe how objects collaborate.

3. Component Diagram 2. A sequence diagram is an interaction

diagram that details how operations are
4. Deployment Diagram carried out– what messages are sent and
when
5. Use Case Diagram
6. Activity Diagram
7. State Chart Diagram
8. Sequence Diagram
9. Collaboration Diagram

Unified Modeling Language (UML): an overview, Session 3 47

Sequence diagrams
• The Sequence diagrams specifically show how objects talk to one another
to accomplish a goal of the system, one scenario in a Use Case, or one
operation
• The Sequence diagram is built around three fundamental elements: the
objects, messages, and the object lifeline.
• The objects represent the participants.
• The messages represent the communication that they send to one another.
• The object lifelines allow us to arrange the messages in the proper relative
sequence.
• An object usually becomes active because it has been asked to do
something. It becomes inactive when it is finished with the current task.
• When an object is deleted or destroyed, the timeline ends and an X marks
the termination.

Unified Modeling Language (UML): an overview, Session 3 48

Sequence diagrams

• Sequence diagrams are organized according to time. The time

progresses as we go down the page

• The sequence diagram lists objects horizontally, and the time

vertically and models the exchanged messages over time

• The sequence diagrams are often utilized to understand complex

interactions between objects

Unified Modeling Language (UML): an overview, Session 3 49

Sequence Diagram: Example

Unified Modeling Language (UML): an overview, Session 3 50

Finding Use Case scenarios for the case study

Unified Modeling Language (UML): an overview, Session 3 51

Building a Sequence diagram for the Case Study (Sc.1)

Unified Modeling Language (UML): an overview, Session 3 52

Building a Sequence diagram for the Case Study (Sc.1)

Unified Modeling Language (UML): an overview, Session 3 53

Building a Sequence diagram for the Case Study (Sc.2)

From Scenario 1

Scenario 2

Unified Modeling Language (UML): an overview, Session 3 54

 Thank you for your attention

Questions ?

Specification and Analysis of Information Systems Spring 2005 55