ESOFT Metro Campus - Diploma in Software Engineering - (Module III) OOAD Using UML (Template - Virtusa Corporate) Contents: Object Oriented Programming Object and Class Object Oriented Programming Concepts Unified Modeling Language Class Diagrams Use Case Diagrams Activity Diagrams Interaction Diagrams Sequence Diagrams Collaboration Diagrams State Diagrams Component Diagrams Deployment Diagrams UML Software Tools

1. Diploma in Software Engineering
Module III: OOAD Using UML
Rasan Samarasinghe
ESOFT Computer Studies (pvt) Ltd.
No 68/1, Main Street, Pallegama, Embilipitiya.

2. Contents
1. Object Oriented Programming
2. Object and Class
3. Object Oriented Programming Concepts
4. Unified Modeling Language
5. Class Diagrams
6. Use Case Diagrams
7. Activity Diagrams
8. Interaction Diagrams
9. Sequence Diagrams
10. Collaboration Diagrams
11. State Diagrams
12. Component Diagrams
13. Deployment Diagrams
14. UML Software Tools

3. Object Oriented Programming
• Object-oriented programming (OOP) is a
programming language model organized
around objects rather than actions and data
rather than logic.
• Object oriented programming becoming more
popular as a designing technique, because it
has an ability to represent complex
relationships, data and data processing with
suitable notations.

4. Object Oriented Programming
Male Female
Son
Father Mother Daughter
Family system
Objects

5. Object and Class
An object is person,
place or thing which
consist of data and
behaviors. The data of
an object is its
properties (attributes)
and behavior
represent how an
object acts and reacts.
A class is simply a
representation of a
type of object. It is the
blueprint / template
that describe the
details of an object.
Class is composed of
three things: a name,
attributes, and
operations.

6. Object Instance
Object instance is uniquely identified
occurrences of an object
Book
Book_id
Title
Author
Lending
Reservation
Reading
Book
001 – A
Science
Peter
Lending
Reservation
Reading
Object instance

7. Object Oriented Programming Concepts
 Abstraction
 Inheritance
 Polymorphism
 Encapsulation
 Generalization
 Specialization

8. Abstraction
• Abstraction is a mechanism that enables the
designer to focus on the essential details of a
program component without regard to
irrelevant low level details.
• As we move through the design process, the
level of abstraction is reduced. Finally, the
lowest level of abstraction is reached when
source code is generated.

9. Inheritance
Inheritance is sharing of attributes and operations
among classes based on a hierarchical relationship.
Vehicle
v-no
Model
color
Drive
Stop
Bus
v-no
Model
color
Drive
Stop
Car
v-no
Model
color
Drive
Stop
Super class
operations and
attributes are
inherited to the
sub classes

10. Polymorphism
• Polymorphism is simply the ability for an
object behaves differently depending on its
type.
• Ex: both cat and dog are animals which has
the same method called makeNoise(). But
they are making noise in a different way.

11. Polymorphism

12. Encapsulation
• According to encapsulation attributes and
operations are encapsulated (hidden) within
the object.
• The outside world know what the object can
do but don’t know how it does or where data
is stored. These features are hidden from the
user.

13. Generalization / Specialization
Generalization and specialization both refer to
inheritance but the approach in which they
are implemented are different.
If many similar existing
classes are combined
to form a super class
to do common job of
its subclass, then it is
known as
Generalization.
If some new
subclasses are created
from an existing super
class to do specific job
of the super class,
then it is known as
Specialization.

14. Generalization / Specialization
Vehicle
v-no
Model
Color
Drive
Stop
Motorbike
v-no
Model
color
Drive
Stop
Car
v-no
Model
Color
Airbag
Drive
Stop
Reverse
Specialization
Generalization
Car and Motorbike specialize Vehicle to their
own sub-type.
Vehicle Generalize what is
common between Car and
Motorbike

15. Unified Modeling Language (UML)
• UML can be described as a general purpose
visual modeling language to visualize, specify
and document software systems.
• The most important goal for developing UML
is to define some general purpose modeling
language which all modelers can use and
simple to understand and use.

16. Unified Modeling Language (UML)
1. Class Diagrams
2. Use Case Diagrams
3. Activity Diagrams
4. Interaction Diagrams
1. Sequence Diagrams
2. Collaboration Diagrams
5. State Diagrams
6. Component Diagrams
7. Deployment Diagrams

17. Class Diagrams
• A class diagram shows the static structure of
an object oriented model.
• Also it shows object classed and their internal
structures (attributes and operations) and
their relationships.

18. Class Diagrams
Structure of a Class
Student
Name
Address
Phone
Display
Add
Edit
Delete
Class Name
Attributes
Operations

19. Relationships
• Association
• Aggregation
• Composition
• Generalization

20. Association
• An association is a relationship among classes
or objects.
• Ex: Student follows Course, Lecturer teaches
Student, Manager manages company.
manager company

21. Aggregation
• When an object has an another object, then
you have got an aggregation between them.
• Ex: Library has Students
Student Library

22. Composition
• When an object contains the other object, if
the contained object cannot exist without the
existence of container object, then it is called
composition.
• Ex: University consist from Buildings, Shirt
consist from Collar, buttons, etc.

23. Generalization
Person
Employer Customer

24. Multiplicity
Multiplicity indicates the number of instance
of one class linked to instance of another
class.
One to One One to Many
Many to Many
1 1 1 *
* *

25. Multiplicity
Multiplicity Meaning
1 Only One instance can be linked
* Many instances can be linked
0..* Zero or many instance can be linked
0..1 Zero or one instance can be linked
1..* One or many instance can be linked
5..9 Between 5 and 9 instance can be linked
3,4,5 Only 3,4 or 5 instance can be linked

26. Class Diagrams
A sample class diagram

27. Purpose of the class diagrams
Describing the static view of the system.
Describing the functionalities performed by
the system.
Construction of software applications using
object oriented languages.

28. Use Case Diagrams
• A use case diagram is a graphical
representation of a user's interaction with the
system.
• The purpose of use case diagram is to capture
the dynamic aspect of a system.

29. Use Case Diagrams

30. Use Case Diagrams

31. Purpose of use case diagrams
Used to gather requirements of a system.
Used to get an outside view of a system.
Model the context of a system.
Understand the project scope.

32. Activity Diagrams
• Activity diagram is basically a flow chart to
represent the flow from one activity to
another activity.
• The activity can be described as an operation
of the system.

33. Activity Diagrams

34. Activity Diagrams

35. Purpose of activity diagrams
Modeling business requirements.
High level understanding of the system's
functionalities.
Draw the activity flow of a system.
Describe the parallel, branched and
concurrent flow of the system.

36. Interaction Diagrams
• Interaction diagrams are used to describe
some type of interactions among the different
elements in the model.
• This interactive behavior is represented in
UML by two diagrams known as:
1. Sequence diagrams
2. Collaboration diagrams

37. Sequence Diagrams
Sequence diagram emphasizes on time
sequence of messages

38. Sequence Diagrams

39. Collaboration Diagrams (Communication)
Diagrams)
Collaboration diagram emphasizes on the
structural organization of the objects that
send and receive messages.

40. Collaboration Diagrams (Communication)

41. Collaboration Diagrams (Communication)

42. Purpose of interaction diagrams
 To capture dynamic behavior of a system.
 To describe the message flow in the system.
 To describe structural organization of the
objects.
 To describe interaction among objects.

43. State Diagrams
• State diagrams used to model dynamic nature
of a system.
• It describes different states of an object during
its lifetime. And these states are changed by
events.

44. State Diagrams
Vacancy Opened Updated Vacancy
Closed
/ Create / Update
[isOpen] / Close
Deleted
/ Delete
/ Delete

45. State Diagrams
Job Seeker Inserted Updated Info
Deleted
/ Create / Update
/ Delete
/ Delete

46. Purpose of State diagrams
To model dynamic aspect of a system.
To identify events responsible for state
changes.
To describe different states of an object during
its life time.

47. Component Diagrams
• Component diagrams are used to model
physical aspects of a system.
• These physical aspects are the elements like
executables, libraries, files, documents etc
which resides in a node.

48. Component Diagrams
Customer.java Order.java
SpecialOrder.javaNormalOrder.java

49. Purpose of component diagrams
Visualize the components of a system.
Model executables of an application.
Model system's source code.
Describe the organization and relationships of
the components.

50. Deployment Diagrams
Deployment diagrams are used to visualize the
topology of the physical components
(hardware) of a system where the software
components are deployed.

51. Deployment Diagrams

52. Purpose of Deployment diagrams
To model the hardware topology of a system.
Describe runtime processing nodes.
Describe the hardware components used to
deploy software components.

53. UML Software Tools
• Microsoft Office Visio
• IBM Rational Rose
• Creately

54. The End
http://twitter.com/rasansmn