INTRODUCTION TO

OBJECT-ORIENTED
PROGRAMMING AND
UML
1
OBJECTIVES
At the end of the lesson, you should be able to:
1. Name the basic components of object-
oriented programming
2. Differentiate classes and objects.
3. Differentiate class and instance methods.
4. Differentiate class and instance data values.
5. Draw program diagrams using icons for
classes and objects

2
CLASSES AND OBJECTS
 Object-oriented programs use objects.
 An object is a thing, both tangible and
intangible. Account, Vehicle, Employee, etc.
 To create an object inside the computer
program, we must provide a definition for
objects—how they behave and what kinds of
information they maintain —called a class.
 An object is called an instance of a class.

3
GRAPHICAL
REPRESENTATION OF A
CLASS
<Class Name> We
Weuseuseaarectangle
rectangletoto
represent a class with
represent a class with
its
itsname
nameappearing
appearing
inside
inside therectangle.
the rectangle.

Example: Account Motorcycle

The notation we used here is based on the industry

standard notation called UML, which stands for 4
Unified Modeling Language.
GRAPHICAL
REPRESENTATION OF AN
OBJECT We
Weuse
useaarectangle
rectangleto to
represent an object
represent an object
and
andplace
placethe
the
<Object Name>
underlined
underlinedname
nameof of
the object inside the
the object inside the
rectangle.
rectangle.

Example:

This
Thisisisan
anobject
object
SV198 named SV198.
named SV198.

5
AN OBJECT WITH THE
CLASS NAME
This
Thisnotation
notation
indicates
indicatesthe
theclass
class
<Object Name> : <Class
which
which the objectisisan
the object an
Name>
instance.
instance.

Example:

This
Thistells
tellsan
anobject
object
SV198 is an instance
SV198 is an instance
SV198 : BankAccount
of
ofthe
theBankAccount
BankAccount
class.
class.

6
MESSAGES AND METHODS
 To instruct a class or an object to perform a task, we
send a message to it.
 You can send a message only to the classes and
objects that understand the message you sent to
them.
 A class or an object must possess a matching
method to be able to handle the received message.
 A method defined for a class is called a class
method, and a method defined for an object is
called an instance method.
 A value we pass to an object when sending a
message is called an argument of the message.
7
SENDING A MESSAGE
Message
Messagedeposit
depositwith
with
the argument 250.00
the argument 250.00
isissent
sentto
toaa
BankAccount
BankAccountobject
object
SV198.
SV198.

deposit 250.00
SV198 : BankAccount

8
SENDING A MESSAGE AND
GETTING AN ANSWER
Ask
Askfor
forthe
thecurrent
current
balance of this
balance of this
particular
particularaccount.
account.

getCurrentBalance()
SV198 : BankAccount

current balance

The
Thecurrent
currentbalance
balanceof
of
SV198 is returned.
SV198 is returned.
9
CALLING A CLASS METHOD
Ask
Askfor
forthe
themaximum
maximum
possible
possible speedfor
speed forall
all
MobileRobot
MobileRobot objectsisis
objects
returned.
returned.

MobileRobot
getMaximumSpeed()

maximum speed

10
CLASS AND INSTANCE DATA
VALUES
 An object is comprised of data values and
methods.
 An instance data value is used to maintain
information specific to individual instances. For
example, each BankAccount object maintains its
balance.
 A class data value is used to maintain
information shared by all instances or aggregate
information about the instances.
 For example, minimum balance is the information
shared by all Account objects, whereas the
average balance of all BankAccount objects is an
aggregate information.
11
SAMPLE INSTANCE DATA
VALUE
SV129 : SV098 : SV211 :
BankAccount BankAccount BankAccount

current balance current balance current balance

908.55 1304.98 354.00

All
Allthree
threeBankAccount
BankAccount The
Theactual
actualdollar
dollar
objects
objects possessthe
possess the amounts
amounts are,of
are, of
same instance data
same instance data course, different.
course, different.
value
valuecurrent
currentbalance.
balance.

12
SAMPLE CLASS DATA VALUE
BankAccount
There
Thereisisone
onecopy
copyofof
minimum balance minimum balance
minimum balance
100.00 for
forthe
thewhole
wholeclass
class
and
and shared byall
shared by all
instances.
instances.

This
Thisline
lineisis
an
aninstance-
instance-
of
of
relationship.
relationship.

SV129 : SV098 : SV211 :

BankAccount BankAccount BankAccount

current balance current balance current balance

908.55 1304.98 354.00
OBJECT ICON WITH CLASS
DATA VALUE
SV129 :
BankAccount
minimum balance When
Whenthetheclass
classicon
iconisis
100.00 not
notshown,
shown,weweinclude
include
the
the class data valuein
class data value in
current balance the object icon itself.
the object icon itself.
908.55
THE FOUR PILLARS OF
OBJECT-ORIENTED
PROGRAMMING
1. Abstraction
2. Encapsulation
3. Inheritance
4. Polymorphism

15
MAIN OOP CONCEPTS

16
ABSTRACTION
Abstract Classes
 An abstract class is a superclass (parent class)
that cannot be instantiated.
 You need to instantiate one of its child classes if
you want to create a new object.
 Abstract classes can have both abstract and
concrete methods.
 Abstract methods contain only the method
signature, while concrete methods declare a
method body as well.
 Abstract classes are defined with the abstract
keyword.
17
ABSTRACTION

18
ABSTRACTION

ClassName Animal

attributes

+label()
operations +move()
+eat()

Abstract Class Notations

19
A
B
S
T
R
A
C
T
I
O
N 20
A
B
S
T
R
A
C
T
I
O
N 21
ABSTRACTION

22
ABSTRACTION
Interfaces
 An interface is a 100% abstract class.
 It can have only static, final, and public fields
and abstract methods.
 It’s frequently referred to as a blueprint of a
class as well.
 Java interfaces allow us to implement multiple
inheritance in our code, as a class can
implement any number of interfaces.
 Classes can access an interface using the
implements keyword.

23
ABSTRACTION

24
ABSTRACTION

<<interface> <<interface>
> >
Animal Bird
+numberOflegs
+outerCovering:
String
+eat() +fly()
+sound()

Interface Class Notations

25
ABSTRACTION

26
ABSTRACTION

27
ABSTRACTION

28
MAIN OOP CONCEPTS

29
E
N
C
A
P
S
U
L
A
T
I
O
N
30
E
N
C
A
P
S
U
L
A
T
I
O
N
31
ENCAPSULATION
Animal

-name: String
-averageWeight
-numberOflegs

+getname(): String
+getAverageWeight
+getNumberOfLegs
+setName()
+setAverageWeight(
)
+setNumberOfLegs(
)
Class Notations 32
ENCAPSULATION

33
ENCAPSULATION

34
MAIN OOP CONCEPTS

35
INHERITANCE
 Inheritance allows us to extend a class with
child classes that inherit the fields and methods
of the parent class.
 It’s an excellent way to achieve code reusability.
 In Java, we need to use the extends keyword to
create a child class.

36
INHERITANCE

37
INHERITANCE

38
 Bird
INHERITANCE
+reproduction: String
+outerCovering:
String
+flyUp()
+flyDown

Eagle
+name: String
+lifespan

Class Notations 39
INHERITANCE

40
INHERITANCE

41
MAIN OOP CONCEPTS

42
POLYMORPHISM
 Polymorphism makes it possible to use the
same entity in different forms.
 In Java, this means that you can declare several
methods with the same name until they are
different in certain characteristics.
 Java provides us with two ways to implement
polymorphism: method overloading and method
overriding.

43
POLYMORPHISM
Static Polymorphism
 Method overloading means that you can have
several methods with the same name within a
class. However, the number, names, or types of
their parameters need to be different.

44
POLYMORPHISM

45
POLYMORPHISM

46
POLYMORPHISM

47
POLYMORPHISM
Dynamic Polymorphism
 By using the method overriding feature of Java,
you can override the methods of a parent class
from its child class.

48
POLYMORPHISM

49
POLYMORPHISM

50
POLYMORPHISM

51
RELATIONSHIPS
 Relationships in UML are used to represent
a connection between structural, behavioral,
or grouping things.
 It is also called a link that describes how two
or more things can relate to each other during
the execution of a system.

52
RELATIONSHIPS
Types of UML relationships:
1. Dependencies
2. Generalizations
3. Associations
4. Realization

53
RELATIONSHIPS
Types of UML relationships:
Dependencies
 Dependency is the most general relationship
between two packages, classes, or objects,
which is shown by a dashed arrow.
 In a dependency relationship, as the name
suggests, two or more elements are
dependent on each other.
 In this kind of a relationship, if we make a
change to a particular element, then it is
likely possible that all the other elements will
also get affected by the change.

54
RELATIONSHIPS
Types of UML relationships:
Dependencies

The CustomerView class may have a method

called display that expects a Customer object
as input:

55
RELATIONSHIPS
Types of UML relationships:
Generalizations
 It is a relationship between a general entity and
a unique entity which is present inside the
system.
 In a generalization relationship, the object-
oriented concept called inheritance can be
implemented.
 A generalization relationship exists between two
objects, also called as entities or things.
 In a generalization relationship, one entity is a
parent, and another is said to be as a child.
These entities can be represented using
inheritance.
56
RELATIONSHIPS
Types of UML relationships:
Generalizations

57
RELATIONSHIPS
Types of UML relationships:
Generalizations

58
RELATIONSHIPS
Types of UML relationships:
Associations
 Association and generalization are special
types of dependencies.
 Association specifies a "has-a" or
"whole/part" relationship between two
classes.
 In an association relationship, an object of the
whole class has objects of part class as
instance data.
 In a class diagram, an association relationship
is rendered as a directed solid line.
59
RELATIONSHIPS
Types of UML relationships:
Associations (Unidirectional)
 In a unidirectional association, two classes
are related, but only one class knows that the
relationship exists.
 A unidirectional association is drawn as a solid
line with an open arrowhead pointing to the
known class.

60
RELATIONSHIPS
Types of UML relationships:
Associations (Bidirectional or Standard)
 An association is a linkage between two
classes.
 Associations are always assumed to be bi-
directional; this means that both classes are
aware of each other and their relationship,
unless you qualify the association as some
other type.
 A bi-directional association is indicated by a
solid line between the two classes.

61
RELATIONSHIPS
Types of UML relationships:
Associations
 Associations represent relationships
between the objects of one class and the
objects of another.
 For example, the relationship:
Teacher X teaches Student Y

62
RELATIONSHIPS
Types of UML relationships:
Associations

63
RELATIONSHIPS
Types of UML relationships:
Associations
 Besides an optional name, an association has
two endpoints: end1 and end2.
 An endpoint has six major properties:
end1.name
end1.visibility
end1.isNavigable
end1.aggregation
end1.multiplicity
end1.participant
64
RELATIONSHIPS
Types of UML relationships:
Associations
 In addition, several minor properties can also
be specified:
end1.ordering
end1.targetScope
end1.changability
end1.qualifiers

65
RELATIONSHIPS
Types of UML relationships:
Associations
 In the teaches association, end1 might be the
end connected to the Teacher class and end2
the end connected to the Student class.
Therefore:
end1.participant = Teacher
end2.participant = Student

66
RELATIONSHIPS
Types of UML relationships:
Associations

67
RELATIONSHIPS
Types of UML relationships:
Multiplicity
 Multiplicity notations are placed near the ends
of an association.
 These symbols indicate the number of
instances of one class linked to one instance
of the other class.
 For example, one company will have one or
more employees, but each employee works
for one company only.

68
RELATIONSHIPS
Types of UML relationships:
Multiplicity

69
RELATIONSHIPS
Types of UML relationships:
Multiplicity

70
RELATIONSHIPS
Types of UML relationships:
Multiplicity

71
RELATIONSHIPS
Types of UML relationships:
Multiplicity

72
RELATIONSHIPS
Types of UML relationships:
Navigability (From previous example)
 Does a teacher need to know the identity of
his students? Do students need to know the
identity of their teachers?
 More specifically, given an object representing
a teacher in some database, should we be
able to generate a list of all of that teacher's
students?
 Given an object representing a student,
should we be able to generate a list of that
student's teachers?
 If a teacher needs to know his students, for
example to generate a grade roster, then the 73
RELATIONSHIPS
Types of UML relationships:
Navigability
 Graphically, this is shown by a barbed
arrowhead:

74
RELATIONSHIPS
Types of UML relationships:
Self Association
 Self Association also called reflexive
association, that is, A single object may be
associated with itself if the same class
appears more than once in an association.
 If the same class appears twice in an
association, the two instances do not have to
be the same object, and usually they are not.

75
RELATIONSHIPS
Types of UML relationships:
Self Association

76
RELATIONSHIPS
Types of UML relationships:
Links
 Just as objects are instances of classes, links
are instances of associations:

77
RELATIONSHIPS
Types of UML relationships:
Implementing Associations
 Assume some application needs to associate
a home and business phone to each person in
a database.
 Here's one way to represent this in UML:

78
RELATIONSHIPS
Types of UML relationships:
Implementing Associations
 In this case we would provide Person with an
array of two phones:
class Person
{
private Phone[] phones = new
Phone[2];
// etc.
}
 But which one is business and which one is
home? 79
RELATIONSHIPS
Types of UML relationships:
Implementing Associations
 We can solve this problem using two
associations:

80
RELATIONSHIPS
Types of UML relationships:
Implementing Associations
 Here's the implementation:
class Person
{
private Phone home;
private Phone office;
// etc.
}

81
RELATIONSHIPS
Types of UML relationships:
Realization
 A realization is a relationship between two
things where one thing (an interface) specifies
a contract that another thing (a class)
guarantees to carry out by implementing the
operations specified in that contract.
 In a class diagram, realization relationship is
rendered as a dashed directed line with an
open arrowhead pointing to the interface.

82
RELATIONSHIPS
Types of UML relationships:
Realization

 In the example, the printing preferences that

are set using the printer setup interface are
being implemented by the printer.

83
RELATIONSHIPS
Other UML relationships:
Aggregation
 An aggregation is a subtype of an
association relationship in UML.
 Aggregation and composition are both
types of association relationship in UML.
 An aggregation relationship can be
described in simple words as "an object of
one class can own or access the objects of
another class."

84
RELATIONSHIPS
Other UML relationships:
Aggregation (Example)
 Let us consider an example of a car and a
wheel.
 A car needs a wheel to function correctly, but
a wheel doesn't always need a car. It can also
be used with the bike, bicycle, or any other
vehicles but not a particular car.
 Here, the wheel object is meaningful even
without the car object. Such type of
relationship is called UML Aggregation
relation.

85
RELATIONSHIPS
Other UML relationships:
Aggregation (Example)

86
RELATIONSHIPS
Other UML relationships:
Composition
 The composition relationship is very similar to
the aggregation relationship. with the only
difference being its key purpose of
emphasizing the dependence of the contained
class to the life cycle of the container class.
 That is, the contained class will be obliterated
when the container class is destroyed.
 For example, a shoulder bag’s side pocket will
also cease to exist once the shoulder bag is
destroyed.

87
RELATIONSHIPS
Other UML relationships:
Composition
 To show a composition relationship in a UML
diagram, use a directional line connecting the
two classes, with a filled diamond shape
adjacent to the container class and the
directional arrow to the contained class.

88
RELATIONSHIPS
Association vs Aggregation vs Composition
 Aggregation and Composition are subsets
of Association meaning they are specific
cases of association.
 In both aggregation and composition, object
of one class "owns" object of another class.
But there is a subtle difference:
o Aggregation implies a relationship where
the child can exist independently of the
parent.
o Composition implies a relationship where
the child cannot exist independent of the
parent.
89