Object Oriented System Software Engineering

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 identifier

attributes

methods

TREE

Species Height Number of branches

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

one class ‘is part of’ another class

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 accountBANK ACCOUNT

CURRENT ACCOUNT

Inheritance

may be several classes inheriting from one parent class

Ancestor classes are also referred to as base classes

BANK ACCOUNT

CURRENT ACCOUNT

DEPOSIT ACCOUNT

Inheritance

Ancestor Classes

real power and impact of inheritance becomes clearer when

we start to add attributes and methods

first add some attributes and

methods to the class BUILDING

must remember that they

must apply to all BUILDINGs

BUILDING

WallsNumber of rooms

BuildDestroy

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

Front door

Back door

Kitchen

Roof

Garden

PLUS

Walls

Number of rooms

BUILDING

WallsNumber of rooms

BuildDestroy

HOUSE

Front doorBack doorKitchenRoofGarden

Pay mortgage

OFFICE

EntranceRest room

Pay commercial rent

FLAT

Front doorLandlordKitchen

Pay landlord

Ancestral trees

class will inherit all attributes

methods

from all its ancestors

UNIVERSITY MEMBER

NameAddress

JoinLeave

STAFF

Payroll number

EmployedWorks

STUDENT

ACADEMIC

SubjectDepartment

TeachesSets examsMarks work

Administrative

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

e.g. car - wheelCar

Wheel

3..4

1

Multiplicity

* character actually

means ‘0 or more’

a STUDENT will be

associated with zero,

one or many modules,

and a module will be

associated with zero,

one or many STUDENTs

Student

Module

*

*

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

Wheel

3..4

1

a part of

Car

Wheel

3..4

1

comprises

or

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

class STUDENT may be

This is a declaration of what we expect every student to

have and do

Student

First nameSurnameGenderDate of birthStudent numberEye ColourNationality

EnrolSubmit assignmentSit exam

Objects

An object created from this class might be

an object has identity

values

and is unique

Student1

Emma SmithFemale

15. 11. 7910012345BlueBritish

EnrolSubmit assignmentSit 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 accidentally 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

doesn’t matter how

the date is stored,

providing a recognizable date

is returned when

a message is passed asking for it

Student

Id NumberSurnameFirst NamesDate of BirthAge

Set Id NumberSet SurnameSet First NamesSet date of BirthSet 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

ColourNumber of anglesDraw

Circle

radiusDraw

Rectangle

HeightLengthDraw

Polymorphism

Circle RectangleAttributes: Attributes:Colour Colour (from Shape)

Number of angles Number of angles (from Shape)

Radius HeightLength

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)