CSE3308 - Software Engineering: Analysis and Design, 2003Lecture 7A.1 Software Engineering: Analysis...

CSE3308 - Software Engineering: Analysis and Design, 2003 Lecture 7A.1

Software Engineering: Analysis and Design - CSE3308

Object-Oriented Design

CSE3308/DMS/2003/17

Monash University School of Computer Science and Software Engineering


Lecture Outline

What is Object-Oriented Design? Three OO Design Key Ideas Principles of Object-Oriented Design

Encapsulation Connascence Class Cohesion Subclasses vs. Subtypes Inheritance

Some design problems


What is OO Design?

No clear boundary between analysis and design

Use mostly the same tools to describe design as used to describe analysis

Simply put in terms of the 3 perspectives

Conceptual - Analysis

Specification - Analysis and Design

Implementation - Design


OO Design Key Ideas

Abstraction An abstraction denotes the essential characteristics of an

object that distinguish it from all other kinds of objects and thus provide crisply defined conceptual boundaries, relative to the perspective of the viewer


OO Key Design Ideas (2)

Reduction of dependencies A dependency exists when a change in some element of

software may cause changes in another element of software

This is the major cause of maintenance problems We aim to reduce dependencies as much as possible Shown as dashed lines in UML (e.g. in Package Diagrams)

Buttons and Lamps


Buttons and Lamps - The Use Case and the Model

Name: Turn lamp on and offActors: ButtonPusherType: PrimaryDescription: When the ButtonPusher presses the button, the

lamp goes on if it was off, and goes off if it wasalready on.

LampButton

Turn on() or Turn off()


Coding Directly from the Model--------------lamp.h----------------class Lamp{public:void TurnOn();void TurnOff();};-------------button.h---------------class Lamp;class Button{public:Button(Lamp& l) : itsLamp(&l) {}void Detect();private:Lamp* itsLamp;};-------------button.cc--------------#include “button.h”#include “lamp.h”void Button::Detect(){bool buttonOn = GetPhysicalState();if (buttonOn)itsLamp->TurnOn();elseitsLamp->TurnOff();

Problems:

Any change to Lamp will require a corresponding change to (or at least a recompilation of) Button

It is very difficult to reuse either component alone, for example a button to start a motor and not to turn on a lamp


A better solution

Button{abstract}

ButtonImplementation Lamp

ButtonClient

{abstract}


Why is it better? Underlying abstraction is to relay an on/off

gesture from a user to a target object Has removed implementation from the

abstraction Button knows nothing about implementation

of detecting the user gesture Button knows nothing about Lamp Highly resistant to change and high level

abstractions are easily reused elsewhere Use case requirements are still easily

traceable in the design


Code Solution----buttonClient.h-----class ButtonClient {public:virtual void TurnOn() = 0;virtual void TurnOff()= 0;

};

-------button.h--------class ButtonClient;class Button {public:Button(ButtonClient&);void Detect();virtual bool GetState() = 0;

private:ButtonClient* itsClient;

};

---------button.cc----------------#include button.h#include buttonClient.hButton::Button(ButtonClient& bc): itsClient(&bc) {}void Button::Detect() {bool buttonOn = GetState();if (buttonOn)itsClient->TurnOn();

elseitsClient->TurnOff();

}

-----------lamp.h----------------class Lamp : public ButtonClient {public:virtual void TurnOn();virtual void TurnOff();

};---------buttonImp.h-------------class ButtonImplementation : public Button {public:ButtonImplementaton(ButtonClient&);virtual bool GetState();

};


OO Key Design Ideas - The Open/Closed Principle

Classes should be open for extension, but closed for modification

A class is open for extension if we can add functionality to it: e.g. expand the set of operations or add fields to its data structures

A class is closed for modification if it is available for use by other classes: i.e. it has a stable and well-defined interface

This is normally implemented with inheritance/polymorphism in OO systems


Encapsulation

Encapsulation is the process of compartmentalising the elements of an abstraction that constitute its structure and behaviour

Encapsulation serves to separate the contractual interface of an abstraction and its implementation

Levels Level 0 - No encapsulation Level 1 - Encapsulation within a procedural module Level 2 - Encapsulation within a class Level 3 - Encapsulation within a package (Ambiguous)


Types of Dependency or Connascence

Static Connascence - what can be assessed from the code/structure of the classes

Connascence of name - int i; i := 7 Connascence of type or class - both i’s must be of the same

type Connascence of meaning - e.g. different account number

ranges having different meaning Connascence of algorithm - two elements sharing the same

algorithm Connascence of position

» Sequential - must appear in the correct order

» Adjacent - must appear next to each other

» e.g. actual arguments must be in same order as formal arguments


Dynamic Connascence Connascence based on the execution pattern of

the running code, i.e. the objects rather than the classes

Connascence of Execution - e.g. initialising a variable before using it

Connascence of Timing - e.g. an instruction to turn off an X-Ray machine must occur within 50 milliseconds of an instruction to turn it on

Connascence of Value - e.g. an arithmetic constraint: the three angles of a triangle must always equal 180 degrees

Connascence of Identity - e.g. two objects (O1 and O2) each of which has a pointer to another object must always point to the same object O3

Contranascence - Connascence of difference e.g. if a class C inherits from class A and B, then the methods of A and B can’t have the same names


Connascence and Encapsulation

Connascence is not inherently a bad thing Use encapsulation to manage connascence Guidelines

Minimise overall connascence by breaking the system into encapsulated components

Minimise any connascence which crosses encapsulation boundaries

Maximise the connascence within encapsulation boundaries


Connascence Abuses

The friend function of C++ lets an unrelated class have access to the

private/implementation aspects of a class - therefore high connascence across encapsulation boundaries

Unconstrained Inheritance Letting sub-classes access the private/implementation

aspects of the superclass Controversial

Accidents of Implementation Using accidental properties - e.g. a SET class which

retrieves items from the set in the same order as which they were put in, but this is undocumented - if used will cause connascence of algorithm


Class Cohesion

Measures the interrelatedness of the methods in the external interface of a class

How well does the class hang together as an implementation of an abstraction

Low cohesion - bad! High cohesion - good! No quantitative measure Some people say the more overlap in methods’

use of private variables in a class the higher the cohesion

Cohesion should be visible from the outside Private/implementation variables can change without

affecting the interface, thus the measure is unstable


Symptoms of Low Class Cohesion

Mixed Instance Cohesion - the class has some components which are undefined for some objects of the class

e.g class Salesperson has an attribute called commission-rate, but a Salesperson may either be commissioned or non-commissioned

In the latter case, commission-rate is irrelevant

Solution to Mixed Instance Cohesion is usually to break the class down into sub-classes

Salesperson breaks down into Commissioned Salesperson and Non-Commissioned Salesperson


Symptoms (2) Mixed Domain Cohesion - where the class contains

components which are not relevant to the domain of the class

Where Domain is Application Domain - comprises classes valuable for one

application Business Domain - comprises classes valuable for one industry or

company Architectural Domain - comprises classes valuable for one

implementation architecture Foundation Domain - comprises classes valuable across all

businesses and architectures

» Semantic Subdomain - DATE, TIME, MONEY

» Structural Subdomain - QUEUE, SET, LIST

» Fundamental Subdomain - INTEGER, BOOLEAN


Mixed Domain Cohesion (2) Example - Class REAL contains the method arctan

(takes a real number r and returns the angle whose tangent is r)

But arctan is not really an aspect of a Real Number, it is an aspect of an ANGLE class

For example, should a REAL class have a convert-temp method, because it takes a real number and converts it to another real number?

Components should be intrinsic to the class, Ask if the class can be built without the other

component class - i.e can I build REAL without ANGLE? ANGLE without REAL?


Symptoms (3) Mixed Role Cohesion - the class has a

component which is from the same domain but is not part of the abstraction

e.g class PERSON has a method number_of_dogs_owned

But Dogs are not really part of the person abstraction, they are not an intrinsic part of the abstraction

Do we put in methods for cats, horse, budgerigars, goldfish, etc. etc.

Mixed role cohesion reduces the reusability of the class


Subclasses and Subtypes

For class S to be a true subtype of class T, then S must conform to T

A class S conforms to class T, if an object of class S can be provided in any context where an object of class T is expected and correctness is still preserved when any accessor method is executed

Known as the Liskov Substitutability Principle But we can have subclasses which are not

subtypes.


Subclasses and Subtypes (2) In a sound OO system, all subclasses should also

be subtypes This is not always possible

Ellipse

Circle

But what happens when a circle gets a stretch_along_x_axismessage?

Ellipse Circle

ConicSection


Inheritance Pitfalls Mistaken Aggregates - using inheritance where the

relationship is actually aggregation

Aeroplane

Wing EngineFuselageTail


Abusing Multiple Inheritance

Aeroplane

Wing EngineFuselageTail


Inverted Hierarchy

Board Member

Manager

Employee

Employee

Manager

Boardmember


Some design problems

Roles versus Inheritance Example

Computer Science Conference wants a registration system

Conference members can be:

» Organisers

» Special Guests

» Tutorial Presenters

» Paper Presenters

» Industrial Registrants

» Academic Registrants

» Student Registrants


A simple solutionConferenceMember

PaperPresenter

TutorialPresenter

SpecialGuest

Organiser

Industrial Academic Student

Registrant


Some problems with the solution

What happens if we have an organiser who is also giving a tutorial?

What happens if a student registrant is also giving a paper?

What happens if a conference member withdraws their paper but still attends as an academic registrant?


A partial solution - multiple inheritanceConferenceMember

PaperPresenter

TutorialPresenter

SpecialGuest

Organiser

Industrial Academic Student

Registrant

StudentPaperPresenter

OrganiserTutorialPresenter


Another solution In this particular case, multiple inheritance is not a

particularly good solution Roles are a much better solution as they are more

flexible

ConferenceMember

ConferenceRole

performs 1..*

AcademicIndustrial

PaperPresenter

TutorialPresenterRegistrant

SpecialGuest

Organiser

Student


Robert Martin’s Principles

Cover several of the ideas in this lecture Available with many other excellent articles

on OO Design at: http://www.objectmentor.com/(links can

be found on Resources page of unit website)

Editor of the C++ Report Principles are illustrated with C++ code, but

are equally applicable to any OO design

Open-Closed Principle Liskov Substitution PrincipleDependency Inversion Principle Interface Segregation PrincipleReuse/Release Equivalency Principle Common Closure PrincipleCommon Reuse Principle Acyclic Dependencies PrincipleStable Dependencies Principle Stable Abstractions Principle


References Page-Jones, Meilir, Fundamentals of Object-

Oriented Design in UML, Addison-Wesley, 2000 (Ch. 8, 9)

C++ Report articles mentioned on previous slide, and available via the unit web site

CSE3308 - Software Engineering: Analysis and Design, 2003Lecture 7A.1 Software Engineering: Analysis...

Documents

Transcript of CSE3308 - Software Engineering: Analysis and Design, 2003Lecture 7A.1 Software Engineering: Analysis...