Object Oriented System

Software Engineering

 Lily Sun K237 [email protected]

 John Byrne K244 [email protected]
 Peter Hoornaert K242 [email protected]
 Object Oriented Analysis &
Design - 1
 Everything is a class
 class is a blueprint, abstract
 object has identity, exists

 Real world models

 OO attempts to model real world
 Class diagrams
 Note - class name is singular
 Class
TREE
 identifier Species
Height
 attributes Number of branches

 methods Germinate
Grow
Shed leaves
Die
 Class diagrams
 Classes change
 iterative process
 expect change
 Classes
 Relationships between classes
 Three relationships:
 association
 aggregation
 generalization/specialization (or inheritance)
 Association

 loosest relationship
 some communication between the classes
 e.g. Student to Module

STUDENT MODULE
 Aggregation
 one class is ‘part of’ another class
 tighter than an association
 if you can answer ‘yes’ - probably aggregation
 e.g. Course to Module

COURSE MODULE
 Inheritance
(Generalization/Specialization)
 is ‘a kind of’ e.g. house is a kind of building
 one class is the child of another parent class
 the child class inherits all the attributes and methods
of the parent
 e.g bank account BANK ACCOUNT

CURRENT
ACCOUNT
 Inheritance
 may be several classes inheriting from one parent class

BANK ACCOUNT

CURRENT DEPOSIT
ACCOUNT ACCOUNT

 Ancestor classes are also referred to as base classes

 Inheritance
 Ancestor Classes
 real power and impact of inheritance becomes clearer when
we start to add attributes and methods
BUILDING

Walls
Number of rooms
first add some attributes and
Build
methods to the class BUILDING Destroy

must remember that they

must apply to all BUILDINGs
HOUSE
 Inheritance
 HOUSE now inherits all the generalized attributes and
methods from BUILDING
 then we can add the specialized attributes that make it
special
 becomes more interesting when there is more than
one class inheriting from the parent class
 Inheritance
class HOUSE has the attributes BUILDING
 Front door
Walls
 Back door Number of rooms

 Kitchen Build
Destroy
 Roof
 Garden
PLUS
HOUSE FLAT OFFICE
 Walls
 Number of rooms Front door Front door Entrance
Back door Landlord Rest room
Kitchen Kitchen
Roof
Garden Pay landlord Pay commercial rent

Pay mortgage
 UNIVERSITY
MEMBER

Name

Ancestral trees Address

Join
Leave

 class will inherit all

 attributes
STAFF STUDENT
 methods Payroll number

 from all its ancestors Employed

Works

ACADEMIC Administrative

Subject
Department

Teaches
Sets exams
Marks work
 UML and case tools

 notation used to draw the class diagrams

the Unified Modeling Language or UML
 released in January 1997, quickly established itself as an
industry standard
 Several case tools
 Rational Rose
 Select Enterprise Modeler
 Multiplicity
 can show how many of one class we can expect to find
with another
 called multiplicity
Car
 e.g. car - wheel
1

3..4

Wheel
 Multiplicity
 * character actually
Student
means ‘0 or more’
 a STUDENT will be *
associated with zero,
one or many modules,
 and a module will be *

associated with zero, Module

one or many STUDENTs
 Multiplicities
blank not determined
0 zero
1 one
* zero, one or many
1 ..* one or many
1 .. 5 one to five

other combinations as required

2 .. 6 two to six
3 .. * three to many
Relationship labels

Car Car

1 1
or
a part of comprises

3..4 3..4

Wheel Wheel
 Objects
 A class can be thought of as a recipe, a description or
declaration of something which we will create
 We can create
an individual student
an instance or instantiation of the class
give it identity, and this is an object
 Objects
Student
 class STUDENT may be
First name
Surname
Gender
Date of birth
Student number
Eye Colour
Nationality

Enrol
Submit assignment
Sit exam

 This is a declaration of what we expect every student to have

and do
 Objects
 An object created from this class might be
 an object has Student1

 identity Emma
Smith
 values Female

 and is unique
.
15 11. 79
10012345
Blue
British

Enrol
Submit assignment
Sit exam
 Constructors
 We can also say that we have constructed each object.
This is an important concept when we come to
implement the design in a programming language.

 When we constructed the objects above we gave the

attributes values which make each object different from
the next, even though they are all instances of the
same class
 Destructors
 Eventually the objects will no longer be required. (Hopefully
all students will eventually complete their course and will
cease being students.)
 When producing class diagrams this may not seem important,
but when the system is implemented this will need to be
considered.
 When we have finished with an object it should be destroyed
using a destructor. Some languages do this for you, others
expect you to do it.
 Encapsulation
 also referred to as data hiding
 need to ensure that the values of the object are
protected, so that they cannot be interfered with, and
cannot be inadvertently changed
 object is encapsulated, attributes and methods should
be carefully controlled so that access to them is only
allowed in a controlled way
 Message Passing
 class’s data or attribute values should only be
accessible through message passing
 if you want the value of an attribute then ask for it and
you will be given it, but you shouldn’t have direct
access to it
 Encapsulation/message passing
 e.g. class student
Student
doesn’t matter how
Id Number
Surname
the date is stored, First Names
Date of Birth
providing a recognizable date Age

Set Id Number
is returned when Set Surname
Set First Names
a message is passed asking for it Set date of Birth
Set Age
 Hidden methods
 Method not accessible outside class
 e.g. getDoB in numeric format
getDoB in string format
 don’t know how DoB is stored
 don’t care providing we get DoB in requested format
 method to produce it is not visible/accessible
 Cohesion
 consequence of encapsulation is that classes that are
self contained
 attributes are not readily accessible to anything outside
the class unless a method to give access is provided
 cannot make changes to anything inside the class
unless we give permission
 cohesion is HIGH
 Coupling
 one class has a high dependency on another class
 a change in one requires a change in the other
 this is high coupling
 OO wants LOW coupling
 Polymorphism
 Inheritance gives all attributes and methods of parents
 Inheritance also allows polymorphism
 poly many
 morph form
 many forms
Polymorphism

Shape
Colour
Number of angles
Draw

Circle Rectangle
radius Height
Draw Length
Draw
 Polymorphism
Circle Rectangle
Attributes: Attributes:
Colour Colour (from Shape)
Number of angles Number of angles (from Shape)
Radius Height
Length

Methods: Methods:
Draw Draw (from Shape)
Draw Draw
 Static and Dynamic Binding
 Notice: each has two Draw methods

 generalized Draw - shape

 specialized Draw - their own specific outline

 necessary to redefine the Draw method as they will need

to do something different from the ancestor class
 Static and Dynamic Binding
 Which method will be used?
 At the time of writing and compiling the program we may
not know
 Procedural programming - static binding (compile time)
 OO languages - dynamic binding (run-time)