1 Object orientation. 2 What benefits does OO give? Primarily –Encapsulation (Associates data & operations) –Types & specialisation –Software re-use.

1

Object orientation

2

What benefits does OO give?

• Primarily– Encapsulation (Associates data & operations)– Types & specialisation– Software re-use

3

“Manage the seams”

• Define major interfaces between components

• And design so that there aren’t too many major interfaces

4

Thinking about objects

• How to discover classes?

• What kinds of relationships?

• How to design for reuse?

• How to capture design?

• How to correct the design when you realise it’s wrong? (!)

5

Analysis & Design

• OO Analysis. A method of analysis in which requirements are examined from the perspective of the classes and objects found in the vocabulary of the problem domain.

• OO Design. A method of design encompassing the process of object-oriented decomposition and a notation for depicting both logical and physical as well as static and dynamic models of the system under design; specifically, the notation includes class diagrams, object diagrams, module diagrams and process diagrams.

(BOOCH)

6

2 perspectives on OOA & OOD

• OO Analysis is a kind of design– traceability of objects from analysis to design

(Jacobsen)

• Design features tend to creep into analysis– and this is bad

(Embley et al)

7

Discovering classes (Quatrani)

• Entity– Information + behaviour that is generally long-lived. Look

for nouns and noun-phrases describing responsibility

• Boundary– Communication between system surroundings & inside

of system, e.g. interface to user or to another system

• Control– Behaviour specific to one or more use cases (scenarios).

‘Runs’ that particular use case

8

Identifying relationships

• ‘Kind-of’ (subclassing) different from ‘Part-of’ (collaboration — or, more precisely, aggregation)

• So don’t make SteeringWheel subclass of Car just so it can access all the car information!

9

OO modelling for biology

• So should Vicia faba be modelled as a subclass of Vicia?

• Or as a part of Vicia?

• NEITHER – at the design phase we’re modelling programming objects

• So a suitable class might be Taxon (debatable whether we should have a hierarchy – depends on intended use)

10

Two kinds of ‘standard’ reuse

• Reuse by inheritance

• Reuse by composition

11

What is inheritance for?

• A means of indicating relationships

• A means of programming-by-difference

12

Refactoring

• Your first design is probably wrong!• So look for ways of refactoring• Particularly expensive to refactor major

objects, so try to get that bit right early• The ‘innards’ can be refactored much more

readily (e.g. could change wrapper architecture without altering the way clients interface with wrappers)

13

Modelling

14

Introduction

The UML was devised with the aims:– To be a standard (now adopted by the OMG)– To model aspects generally regarded as

important:• static

• dynamic

• functional

– To be extensible

15

Background

• Designed by 3 major players in OOA/OOD (Booch, Rumbaugh & Jacobsen)

• Intended to provide a universal means of communicating design

• A design has a relevance outside the particular process by which it was created

16

Kinds of diagram

Nine kinds of diagram (some related):– Class and Object diagrams– Use Case diagrams– Sequence diagrams– Collaboration diagrams– Statechart diagrams– Activity diagrams– Component and Deployment diagrams

• CRC cards are also often used for informal modelling (brainstorming)

17

Use Cases: Motivation

• Capturing scenarios in which a system is to be used

• Describing the details of how a particular scenario will be acted out

18

Benefits

Help us both in:

• determining what kinds of classes are appropriate, and

• determining the processes that the code to be written will implement

19

What comprises a Use Case?

• The Use Case itself (names a particular scenario)

• The actors and their associations with each Use Case

• Documentation

20

Example

Borrower

Reservebook

Borrow copyof book

Return copyof book

ExtendLoan

UpdateCatalogue

Librarian

Check forReservation

RefuseLoan

<<includes>

>

<<includes>>

<<extend>>

21

Name: Reserve Book

Description: Allow a borrower to reserve a book

Preconditions: Member of library, no loans overdue, ...

Postconditions: The borrower will be placed on the waiting list for the book

22

Basic Course of Action1. Borrower wants to reserve a book2. Borrower submits details of book to be reserved3. System determines whether borrower is eligible to

reserve4. Reservation stored5. Confirmation of reservation given to borrower6. Use Case EndsAlternative Course A: borrower ineligibleA.3 Inform borrower (s)he’s ineligibleA.4 Use Case ends

23

We can start suggesting classes ...

• Borrower

• LibrarySystem

• Book

• Reservation

• ...

24

Class & Object Diagrams

• Central to any genuinely object-oriented design is the relationship of objects — and of their classes — to each other

25

Static models - class diagrams

…

Shape{abstract}

centre: Point

draw()

Triangle

draw()

Circle

draw()

26

Static models - class diagrams

Shape{abstract}

Drawing1 *

Triangle Circle

27

Example (Class Diagram)

• Note how this avoids the need for dynamic relationships or roles (both of which are supported by UML)

Person Company

Employment

period:dateRange

1 * * 1

0..1*

28

Aggregation

• Captures the ‘part-of’ relationship. Diamond at the ‘whole’ end

Car

Wheel

Headlamp

29

Object diagrams

a Measurementamount: 80unit: 'bpm'

Billy: Patient a Measurementamount: 5unit: 'ft'

a Measurementamount: 74unit: 'bpm'

John: Patient a Measurementamount: 6unit: 'ft'

pulseRate:PhenomenonType

height:PhenomenonType

• Relationship between specific objects

30

Object diagrams (ctd.)

a Measurementamount: 80unit: 'bpm'

Billy: Patient a Measurementamount: 5unit: 'ft'

a Measurementamount: 74unit: 'bpm'

John: Patient a Measurementamount: 6unit: 'ft'

pulseRate:PhenomenonType

height:PhenomenonType

Patient

Measurementamount: integerunit: string

PhenomenonType

<<instanceOf>>

1

*

*

1

• Can show relationship between classes and instances (use label <<instanceOf>>)

31

Summary

• Remember that the fundamental OO modelling technique is class modelling

• But class diagrams only allow us to name operations, rather than describe processes by which change occurs

• The UML also allows us to model dynamic and functional aspects of a system using other kinds of diagrams