Unified Modeling Language (UML) : An Overview

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

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

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

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)

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

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

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
– …

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

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()

Class associations
Produt Order
name * * date
price includes
checkout()
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
Object Diagram
Unified Modeling
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.

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

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

Comparison of the Class and Object Diagrams

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

Association Classes
Denoted as a class attached to the association, and
specify properties of the association
Produt Order
name * * date
price
checkout()
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

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

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

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»

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

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

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

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

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

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

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

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

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

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 < boss.salary} Employee 0..1
salary
* boss

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

‫‪Building an Object diagram for the Case study‬‬
‫– نريد تصميم نظام للتحكم بقائمة محتويات مستودع حيث يتم تسجيل معلومات‬
‫خاصة بالمنتجات المخزنة في المستودع وبالمنتجات المشحونة منه‪ .‬بعد استالم‬
‫المنتجات المشتراة من البائعين وتخزينها في المستودع‪ ,‬يتم بيعها كما وردت أو‬
‫يتم تجميع عدة منتجات مع بعضها البعض لتباع على شكل منتج خاص‬
‫بالمستودع‬
‫‪39‬‬
Building an Object diagram for the Case study




Applying the Class diagram on the Case study

Before
After

Sequence Diagram
Unified Modeling
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

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.

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

Sequence Diagram: Example

Finding Use Case scenarios for the case study

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


From Scenario 1
Scenario 2

Thank you for your attention
Questions ?
Specification and Analysis of Information Systems Spring 2005 55

Unified Modeling Language (UML) : An Overview

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Unified Modeling Language (UML) : An Overview

Uploaded by

Copyright:

Available Formats

Unified Modeling Language (UML)

Specification and Analysis of Information Systems Spring 2005 1

– Explaining the Class diagram and illustrating its notation

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

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

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

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

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

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

- visibility: the access rights to the attribute

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

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

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

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

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

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

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

We will try to keep the visibility as minimal as possible

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

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

Name + reading direction

Object Diagrams describe the static structure of a system

Object diagrams contain the following elements:

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

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

Produt Apple Ipod : Product

buy() name = “IMac 1C”

Class Diagram Object Diagram

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

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

Why is it directional? For example, if

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

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

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

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

Reflexive association: A class has an association to its self

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

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

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

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

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

– Eliminate the details x : int

among classes repaint()

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

specialized press() paint()

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

Document Product Order Worker

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

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

are common id : long

Order Worker Product Document

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

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

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

• Composition is a stronger form of aggregation

Slider Header Panel

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

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

Whole is not solely responsible Whole is responsible and

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

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

written by written by Category