Object Oriented

Analysis and Design

(OOAD)
M2I322952

Lecture 5
Class Modelling – Part 2
1
 Contents
Class diagrams (continued) :

• Generalisation – specialisation
• Abstract Classes
• Polymorphism
• Aggregation
• Composition
• Association (Link) Classes

2
 Generalisation (Inheritance)
UML@Classroom – 4.6

• Generalisation is the other form of relationship, in

class diagrams, that we’re going to look at.
• In object-oriented programming this is usually
referred to as inheritance.
• The UML refers to it as Generalisation.
• It is where one class is a specialized form of another –
sometimes referred to as a “kind of” relationship.
3
 Generalisation in “Employee” class
Employee

-employeeNo
-lastName
-firstName
-address

+getsalary()
+calculateLeaveLeft()

Salesperson Engineer Administrator

-area -qualifications -adminArea
-carregNo -project -alternative
+calculateLeaveLeft() +calculateLeaveLeft() +calculateLeaveLeft()
4
+calcSalesForMonth() +addQualification() +changeAdminArea()
Generalisation in “Employee” class
• As an illustration we could have a system for a
company with an Employee class. This is the
general class (the superclass).

• But the company may have specialist versions of

an Employee, for example a Salesman, an
Engineer, an Administrator.

• Salesperson, Engineers & Administrators are

all Employees, but specialist forms of Employee.
(the subclasses)
5
Generalisation in “Employee” class
• In object-oriented programming we would have an
Employee class as a superclass

• We would also have subclasses of Employee

called Salesperson, Engineer & Administrator.

• These subclasses would inherit all the attributes

and operations from the Employee superclass
and add to them some extra specialist attributes
and operations of their own.

6
Generalisation in “Employee” class
Looking at this diagram, we can see that if a
Salesperson object were instantiated it would have
the following attributes:

• lastname, firstname, address, employeeNumber,

• ( these are inherited from the Employee class).

• Area, carRegNo

• A Salesperson object would also have a

getSalary() operation (method) that is inherited from
the Employee class.
7
Generalisation (inheritance)-geometry
program

Shape
area
colour
getArea()

triangle circle
square
angle1
angle2 sideLength radius
angle3 getArea()
getArea()
getArea() 8
 There is a class hierarchy
• One class can be a subclass of another which is itself a subclass of
a third class.
• A subclass can also be a superclass. In the diagram below
Mammal is both a subclass of Animal and a superclass of Horse.
• There is no limit to the depth of this hierarchy.

9
From programming 1

10
From programming 1

11
 The need for Generalisation
• Its common for an application to contain a
number of classes that are closely related :

– May share a number of properties/relationships

Or
– It may seem natural to think of them as representing
different varieties of the same thing

12
 The need for Generalisation
• In object-oriented programming, inheritance is a way to
form new classes using classes that have already been
defined.

• Inheritance is intended to help reuse existing code with

little or no modification.

• The new classes, known as derived classes (or

subclasses), inherit attributes and behaviour
(operations) of the pre-existing classes, which are
referred to as base classes (or ancestor classes or
13
superclasses).
 The need for Generalisation
• The inheritance relationship of sub- and superclasses
gives rise to a hierarchy.

• One common reason to use inheritance is to create

specialisations of existing classes or objects

• It saves time and to some extent reflects the real

world

• We can make use of polymorphism

14
Abstract Superclasses
UML@Classroom – 4.7

15
 Abstract Superclasses
In a generalisation structure it may be possible for an
object to be either:
– An instance of one of the subclasses of the generalisation
– An instance of the superclass of the generalisation

However we could decide that we would never want to

instantiate an object of the superclass .
For example, in the case of the Employee structure,
whenever a person was employed by the company, they
were given a specific job role. (Salesperson / Engineers /
Administrators )
In programming terms the superclass is then known as an
16
Abstract class
 Will there ever be an instance of the
Employee class?
Employee

-employeeNo
-lastName
-firstName
-address

+getsalary()
+calculateLeaveLeft()

Salesperson Engineer Administrator

-area -qualifications -adminArea
-carregNo -project -alternative
+calculateLeaveLeft() +calculateLeaveLeft() +calculateLeaveLeft()
17
+calcSalesForMonth() +addQualification() +changeAdminArea()
 An Abstract class
 The name of an abstract class is shown in italics
 The {abstract} property in the class name compartment can also
be used to indicate that the class is abstract

Employee
{abstract}

Salesperson Engineer Administrator

The above diagram indicates that there will never be any Employee
instances, only Salespersons, Engineers and/or Administrators 18
 Polymorphism
UML@Classroom – 1.3.6 – Brief Description

19
 Polymorphism
• A number of classes with a common superclass
• Same operation on many classes
• Same meaning, different implementation

Load Passengers

20
Polymorphism - note that each class has its own version
(implementation) of the calculateLeaveLeft() method
Employee

-employeeNo
-lastName
-firstName
-address

+getsalary()
+calculateLeaveLeft()

Salesperson Engineer Administrator

-area -qualifications -adminArea
-carregNo -project -alternative
+calculateLeaveLeft() +calculateLeaveLeft() +calculateLeaveLeft()
21
+calcSalesForMonth() +addQualification() +changeAdminArea()
 Polymorphism
Suppose that the code below gives the different implementations.

Method in Employee class

public int calculateLeaveLeft() { return 0; }

Method in Salesperson class

public int calculateLeaveLeft() { return 10; }

Method in Engineer class

public int calculateLeaveLeft() { return 8; }

Method in Administrator class

public int calculateLeaveLeft() { return 4; }
22
 The code below declares 3 variables, one from each of the 3
subclasses
 It only sets firstname and address
These are then placed in an array of Employee objects
The program then outputs the holidays left for every Employee in
the array
Which version of the method will it use?
import java.io.*;
public class Company
{
public static void main(String[] args)
{
Administrator Tom = new Administrator("Tom", "Troon");
Engineer Harry = new Engineer("Harry", "Bearsden");
Salesperson Isobel = new Salesperson("Isobel", "Denniston");
Employee staff[] = {Tom, Harry, Isobel};
for (int i=0; i<3; i++) {
System.out.println("Days left for " + staff[i].getName() + " are " +
staff[i].calculateLeaveLeft());
}
} 23
}
24
 Aggregation & Composition

UML@Classroom – 4.5

• In some cases the associations between classes indicate

that objects of one class are made up or consist of
objects of another class

• UML has 2 special kinds of association that are part of

the class diagram notation to show this:
– Aggregation association
• Also known as Shared Aggregation
– Composition association
25
Aggregation Association

Also known as Shared Aggregation

UML@Classroom – 4.5.1

26
 Aggregation Association

• The general concept of aggregation is often referred to as

being a whole-part or part of relationship.

• Object(s) of one class is(are) a part of an object of

another class.

• An aggregation association is used to indicate that, as

well as having attributes of its own, an instance of one
class may consist of, or include, instances of another
class.
 
• The actual number of ‘part’ instances will depend on the
multiplicity at the part end of the association. The use of
aggregation does not override multiplicity specifications. 27
 Term ‘whole part’
• Can be used to refer to aggregation associations
• Instances of the class at one end of the association are the
wholes and they are made up of parts – instances of the class at
the other end
• Aggregation diamond is always at the whole end of the
association
• In this example, an HonoursCourse is made up of a number of
objects of the Module class.
• Also,
– one Honours Course is made up of between 6 and many Modules.
– And one module is part of one or many Honours Courses

1..*
HonoursCourse Module
6..* 28
 Aggregation Association

Home Computer
1
2 1 1 1 1
2 Speaker CPU Box Keyboard Monitor Mouse

1
1..* * 1 1 1..3 1
1
Sound Movement
Harddrive RAM DVD Graphics Button
Card sensor
Card

Is connected to 1
29
Composition Association

UML@Classroom – 4.5.2

30
 Composition Association
• Aggregation implies a whole-part structure between
two classes
• Composition is also a whole-part structure, but has a
more defined property.
• It implies a coincident lifetime – the part object only
exists while the whole object exists.
• Or, to put it another way, the part object has only one
owner object (whole object).
• In composition a part cannot exist without being
part of a whole 31
 Composition

Document

1 1..* 0..1

FrontMatter Section Index

Note that there is no need to show the multiplicity at the

Document end of the association.
This is not needed as it will always be 1 – in composition the part
object has only 1 owner

32
Association (Link) Classes

UML@Classroom – 4.4

33
 Association (Link) Classes
• Sometimes the way in which two objects are associated is
just as important as the objects themselves.
• Consider, for example, the association between Student
and Module.

• Where should our system record the student’s marks

on this course?

• The marks are really connected with a pair consisting of

both a student and a module.

Student 1 ..* 6..* Module

34
 Association (Link) Classes
• Assume 2 students (Tom and Ruth ) taking two
modules (OOAD and Prog2) – and we need to store
their marks :

Tom 60 OOAD
Ruth 65 OOAD
Tom 45 Prog2
Ruth 40 Prog2

Student 1 ..* 6..* Module

35
 Association (Link) Classes

Student 1 ..* 6..* Module

Tom 60 OOAD

65

45

Ruth 40
Prog2

Where do we store each mark ?

Cannot store in Student – e.g. Tom has two different marks ( for each module )
Cannot store in Module – e.g. OOAD has two different marks ( for each student)
36
 Association (Link) Classes
• We might want to implement an object for each such pair: the object
would record each Student’s marks on that Module

• This would avoid confusing them conceptually with any other student’s
marks on this Module, or with this student’s marks on any other Module.

• This amounts to treating the association between the classes

Student and Module as a class

• Thus, an instance of the association connects a student with a

module, and we’re now saying that we want there to be data attached to
that link.

• We probably want operations too, if only to set and get the marks.  

37
 Association (Link) Classes
The result is a thing which is both an association and a class,
which is unsurprisingly called an association class.

This is connected to the main association by a dotted line :

::Student 1..* 6..* ::Module

::Mark

Date
ActualMark

38
 Association (Link) Classes
::Student 1..* 6..* ::Module

::Mark

Date
ActualMark

Tom 60 OOAD

65

45

Ruth 40
Prog2 39
 Association (Link) Classes

Be on the lookout for association classes when

you see a multiplicity of more than one on both
ends of the association.

You don’t always need an association class on

these many-to-many associations

But it is a common place to find them – depending

on the definition of the relationship
40