Object-Oriented Analysis and Design

02.UML and OO Fundamentals.4

Chun-Han Lin (林均翰)

CSIE, NTNU
 Key Points 4

• Inheritance Usage

• Inherit from Airplane in Java

• Polymorphism: Many Forms

• Encapsulation

• Example of Encapsulation

Prof. Chun-Han Lin, CSIE, NTNU

2
 Inheritance Usage

• Inheritance lets you build a

class based on another class
and avoid duplicating code.

• Here, Jet builds off the basics

that Airplane provides.

Prof. Chun-Han Lin, CSIE, NTNU

3
 Inherit from Airplane in Java

• extends keyword
indicates inheritance.
• super() and super
keyword is used to refer
to the superclass.
• No need to define
getSpeed() method
because it’s inherited!
• setSpeed() method
overrides behavior of
setSpeed() in Airplane.

Prof. Chun-Han Lin, CSIE, NTNU

4
 Polymorphism: Many Forms

• Being able to refer to different derivations of a class in

the same way, …
• Implication: both statements are legal.
Airplane plane = new Airplane();
Airplane plane = new Jet();
• …, but getting the behavior appropriate to the derived
class being referred to
• When I invoke setSpeed() in the second variable, I
will get Jet’s method, not Airplane’s method.
plane.setSpeed();

Prof. Chun-Han Lin, CSIE, NTNU

5
 Encapsulation

• Encapsulation lets you …

• Hide data and algorithms in one class from the rest
of your application

• Limit the ability for other parts of your code to

access that information

• Protect information in your objects from being used

incorrectly

Prof. Chun-Han Lin, CSIE, NTNU

6
 Example of Encapsulation

• The speed instance

variable is private in
Airplane. This means that
Jet doesn’t have direct
access to it.
• Nor does any client of
Airplane or Jet objects
• Imagining if we changed
speed’s visibility to public,
the encapsulation of Jet’s
setSpeed() method would
be destroyed.
Prof. Chun-Han Lin, CSIE, NTNU
7
 Review 4

• Inheritance Usage

• Inherit from Airplane in Java

• Polymorphism: Many Forms

• Encapsulation

• Example of Encapsulation

Prof. Chun-Han Lin, CSIE, NTNU

8
Object-Oriented Analysis and Design
02.UML and OO Fundamentals.5

Chun-Han Lin (林均翰)

CSIE, NTNU
 Key Points 5

• Reminder of Abstraction

• Illustration of the Difference

• Association

• Roles

• Labels and Multiplicity

Prof. Chun-Han Lin, CSIE, NTNU

10
 Reminder of Abstraction

• Abstraction is distinct from encapsulation.

• It answers the questions.
• What features does a class provide to its users?
• What services can it perform?
• Abstraction is the most important concern in analysis
and design!
• The choices you make in defining abstractions of your
system will live with you for a long time.

Prof. Chun-Han Lin, CSIE, NTNU

11
 Illustration of the Difference

• getSpeed() and setSpeed()

methods represent
Airplane’s abstraction.
• Of all possible things about
airplanes, we choose to
model speed.
• Making the speed data
private is encapsulation.
• If we choose to use a linked
list to track the history of the
airplane’s speed, we are free
to do so.

Prof. Chun-Han Lin, CSIE, NTNU

12
 Association

• One class can reference another (a.k.a. association).

• UML notation is a straight line.

• The notation is a graphical shorthand that each class

contains a data whose type is the other class.

Prof. Chun-Han Lin, CSIE, NTNU

13
 Roles

• A role can be assigned to a class that takes part in an

association.

• Here, a simplified model of a lawsuit might have a

lawsuit object that has relationships to two people,
defendant and plaintiff.
• Typically, this is implemented via plaintiff and
defendant instance variables in Lawsuit class.

Prof. Chun-Han Lin, CSIE, NTNU

14
 Labels and Multiplicity

• Associations can be labelled to convey semantic

meaning to readers.

• Multiplicity indicates how many instances of a class

participate in an association.
• An association with no markings is one to one.
• An association can indicate directionality.
• If so, it indicates that knowledge of the relationship
is not bidirectional.

Prof. Chun-Han Lin, CSIE, NTNU

15
 Review 5

• Reminder of Abstraction

• Illustration of the Difference

• Association

• Roles

• Labels and Multiplicity

Prof. Chun-Han Lin, CSIE, NTNU

16
Object-Oriented Analysis and Design
02.UML and OO Fundamentals.6

Chun-Han Lin (林均翰)

CSIE, NTNU
 Key Points 6

• 1st Example of Multiplicity

• 2nd Example of Multiplicity

• Self Association

Prof. Chun-Han Lin, CSIE, NTNU

18
 1st Example of Multiplicity

Prof. Chun-Han Lin, CSIE, NTNU

19
 2nd Example of Multiplicity

Prof. Chun-Han Lin, CSIE, NTNU

20
 Self Association

Prof. Chun-Han Lin, CSIE, NTNU

21
 Review 6

• 1st Example of Multiplicity

• 2nd Example of Multiplicity

• Self Association

Prof. Chun-Han Lin, CSIE, NTNU

22
Object-Oriented Analysis and Design
02.UML and OO Fundamentals.7

Chun-Han Lin (林均翰)

CSIE, NTNU
 Key Points 7

• Whole-part

• Semantics of Aggregation

• Example of Whole-part Relationships

• Qualification

• Example of Qualification

Prof. Chun-Han Lin, CSIE, NTNU

24
 Whole-part

• An association can also convey semantic information

about itself.
• In particular, an aggregation indicates that one object
contains a set of other objects.
• Think it as a whole-part relationship between …
• A class representing a group of components
• A class representing the components
• UML notation
• An aggregation is indicated with a white diamond
attached to a class playing a container role.
Prof. Chun-Han Lin, CSIE, NTNU
25
 Semantics of Aggregation

• Aggregation relationships are transitive.

• If A contains B and B contains C, then A contains C.
• Aggregation relationships are asymmetric.
• If A contains B, then B does not contain A.
• A variant of aggregation is composition which adds a
property of existence dependency.
• If A composes B, then if A is deleted, B is deleted.
• UML notation
• A composition relationship is shown with a black
diamond attached to a composing class.

Prof. Chun-Han Lin, CSIE, NTNU

26
 Example of Whole-part Relationships

• Note that multiplicity

annotations for
aggregation/composition is
tricky.
• Some authors assume “one to
many” when the diamond is
present.
• Others assume “one to one”
and then add multiplicity
indicators to the other end.

Prof. Chun-Han Lin, CSIE, NTNU

27
 Qualification

• An association can be qualified with information that

indicates how objects are found.
• This allows a designer to indicate that the association
requires a query mechanism.
• E.g., an association between a phonebook and its
entries might be qualified with a name.
• UML notation
• A qualification is indicated with a rectangle
attached to the end of an association indicating a
data used in the query.
Prof. Chun-Han Lin, CSIE, NTNU
28
 Example of Qualification

Prof. Chun-Han Lin, CSIE, NTNU

29
 Review 7

• Whole-part

• Semantics of Aggregation

• Example of Whole-part Relationships

• Qualification

• Example of Qualification

Prof. Chun-Han Lin, CSIE, NTNU

30
Object-Oriented Analysis and Design
02.UML and OO Fundamentals.8

Chun-Han Lin (林均翰)

CSIE, NTNU
 Key Points 8

• Interface

• Example of Interface

• Summary of Classes

• Sequence Diagram

Prof. Chun-Han Lin, CSIE, NTNU

32
 Interface

• A class can indicate that it implements an interface.

• An interface is a class definition in which only
method signatures are defined.
• A class implementing an interface provides method
bodies for each defined method signature in the
interface.
• This allows a class to play different roles, with each
role providing different services.
• A role is then independent of the class’s inheritance
relationships.
Prof. Chun-Han Lin, CSIE, NTNU
33
 Example of Interface

Prof. Chun-Han Lin, CSIE, NTNU

34
 Summary of Classes

• A class is a blueprint used to create objects.

• A class can participate in multiple types of

relationships.
• Inheritance
• Association (with multiplicity)
• Aggregation/composition
• Qualification
• Interface

Prof. Chun-Han Lin, CSIE, NTNU

35
 Sequence Diagram (1/2)

• Objects are shown at the top.

• Objects at the top existed when a scenario begins.
• Other objects are created during the scenario.

• Each object has a vertical dashed line known as its

lifeline.
• When an object is active, its lifeline is a rectangle.
• If an object dies, its lifeline terminates with an “X”.

Prof. Chun-Han Lin, CSIE, NTNU

36
 Sequence Diagram (2/2)

• A message between objects is shown with a line

pointing at an object receiving the message.
• The line is labeled with a called method and
(optionally) its parameters.

• All UML diagrams can be annotated with notes.

• A sequence diagram can be useful, but it is also labor

intensive!

Prof. Chun-Han Lin, CSIE, NTNU

37
Prof. Chun-Han Lin, CSIE, NTNU
38
 Review 8

• Interface

• Example of Interface

• Summary of Classes

• Sequence Diagram

Prof. Chun-Han Lin, CSIE, NTNU

39
Object-Oriented Analysis and Design
02.UML and OO Fundamentals.9

Chun-Han Lin (林均翰)

CSIE, NTNU
 Key Points 9

• Overview of OO Fundamentals

• Delegation

• UML for GroceryList with Delegation

Prof. Chun-Han Lin, CSIE, NTNU

41
 Overview of OO Fundamentals

• Delegation
• HAS-A
• More on inheritance
• IS-A
• More on polymorphism
• Message passing
• Polymorphic arguments and return types
• Interface
• Abstract class
• Object identity
Prof. Chun-Han Lin, CSIE, NTNU
42
 Delegation (1/4)

• When designing a class, there are four ways to handle

an incoming message.
• Handle message by implementing code in a method

• Let the class’s superclass handle the request via

inheritance.

• Pass the request to another object (delegation)

• Some combination of the previous three

Prof. Chun-Han Lin, CSIE, NTNU

43
 Delegation (2/4)

• Delegation is used when some other class already exists

to handle a request that sent to a class being designed.

• A host class simply creates a private instance of a

helper class, and sends a message when appropriate.

• As such, delegation is often referred to as a “HAS-A”

relationship.
• A Car object HAS-A Engine object.

Prof. Chun-Han Lin, CSIE, NTNU

44
 GroceryList delegates
all work to Java’s
LinkedList class (which
it accesses via List
interface).

Prof. Chun-Han Lin, CSIE, NTNU

45
Prof. Chun-Han Lin, CSIE, NTNU
46
 UML for GroceryList with Delegation

Prof. Chun-Han Lin, CSIE, NTNU

47
 Review 9

• Overview of OO Fundamentals

• Delegation

• UML for GroceryList with Delegation

Prof. Chun-Han Lin, CSIE, NTNU

48
Object-Oriented Analysis and Design
02.UML and OO Fundamentals.10

Chun-Han Lin (林均翰)

CSIE, NTNU
 Key Points 10

• UML for GroceryList without Delegation

• UML for GroceryList with Inheritance

• Delegation Summary

Prof. Chun-Han Lin, CSIE, NTNU

50
Prof. Chun-Han Lin, CSIE, NTNU
51
 UML for GroceryList without Delegation

Prof. Chun-Han Lin, CSIE, NTNU

52
 Delegation (3/4)

• Now, the two programs (with and without delegation)

produce exactly the same output.
• So, do we care which method we use?
• Yes!
• Advantages
• Better abstraction
• Less code in classes we write ourselves
• We can change delegation relationships at runtime!
• Unlike inheritance relationship
• Imagine if we created GroceryList as a subclass of
LinkedList (*shudder*)
• Why? Because GroceryList IS-NOT-A LinkedList

Prof. Chun-Han Lin, CSIE, NTNU

53
 UML for GroceryList with Inheritance

Prof. Chun-Han Lin, CSIE, NTNU

54
 Delegation (4/4)

• Change delegation relationships at run-time

• A class can use a set at run-time.
Set<String> items = new HashSet<String>();
• If the class suddenly needs to be sorted, it can do
this.
items = new TreeSet<String>(items);
• We changed the delegation to a new object at run-time
and now the items are sorted.
• In both cases, the type of items is Set<String> and
we get the correct behavior via polymorphism.
Prof. Chun-Han Lin, CSIE, NTNU
55
 Delegation Summary

• Don’t re-invent the wheel … delegate!

• Delegation is dynamic (not static).

• Delegation relationships can change at run-time.

• Not tied to inheritance

• Indeed, delegation relationships are considered
much more flexible.
• In languages that support only single inheritance,
this is important!

Prof. Chun-Han Lin, CSIE, NTNU

56
 Review 10

• UML for GroceryList without Delegation

• UML for GroceryList with Inheritance

• Delegation Summary

Prof. Chun-Han Lin, CSIE, NTNU

57