cse3308 - software engineering: analysis and design, 2003lecture 7a.1 software engineering: analysis...
Post on 21-Dec-2015
224 views
TRANSCRIPT
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
CSE3308 - Software Engineering: Analysis and Design, 2003 Lecture 7A.2
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
CSE3308 - Software Engineering: Analysis and Design, 2003 Lecture 7A.3
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
CSE3308 - Software Engineering: Analysis and Design, 2003 Lecture 7A.4
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
CSE3308 - Software Engineering: Analysis and Design, 2003 Lecture 7A.5
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
CSE3308 - Software Engineering: Analysis and Design, 2003 Lecture 7A.6
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()
CSE3308 - Software Engineering: Analysis and Design, 2003 Lecture 7A.7
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
CSE3308 - Software Engineering: Analysis and Design, 2003 Lecture 7A.8
A better solution
Button{abstract}
ButtonImplementation Lamp
ButtonClient
{abstract}
CSE3308 - Software Engineering: Analysis and Design, 2003 Lecture 7A.9
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
CSE3308 - Software Engineering: Analysis and Design, 2003 Lecture 7A.10
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();
};
CSE3308 - Software Engineering: Analysis and Design, 2003 Lecture 7A.11
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
CSE3308 - Software Engineering: Analysis and Design, 2003 Lecture 7A.12
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)
CSE3308 - Software Engineering: Analysis and Design, 2003 Lecture 7A.13
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
CSE3308 - Software Engineering: Analysis and Design, 2003 Lecture 7A.14
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
CSE3308 - Software Engineering: Analysis and Design, 2003 Lecture 7A.15
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
CSE3308 - Software Engineering: Analysis and Design, 2003 Lecture 7A.16
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
CSE3308 - Software Engineering: Analysis and Design, 2003 Lecture 7A.17
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
CSE3308 - Software Engineering: Analysis and Design, 2003 Lecture 7A.18
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
CSE3308 - Software Engineering: Analysis and Design, 2003 Lecture 7A.19
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
CSE3308 - Software Engineering: Analysis and Design, 2003 Lecture 7A.20
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?
CSE3308 - Software Engineering: Analysis and Design, 2003 Lecture 7A.21
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
CSE3308 - Software Engineering: Analysis and Design, 2003 Lecture 7A.22
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.
CSE3308 - Software Engineering: Analysis and Design, 2003 Lecture 7A.23
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
CSE3308 - Software Engineering: Analysis and Design, 2003 Lecture 7A.24
Inheritance Pitfalls Mistaken Aggregates - using inheritance where the
relationship is actually aggregation
Aeroplane
Wing EngineFuselageTail
CSE3308 - Software Engineering: Analysis and Design, 2003 Lecture 7A.25
Abusing Multiple Inheritance
Aeroplane
Wing EngineFuselageTail
CSE3308 - Software Engineering: Analysis and Design, 2003 Lecture 7A.26
Inverted Hierarchy
Board Member
Manager
Employee
Employee
Manager
Boardmember
CSE3308 - Software Engineering: Analysis and Design, 2003 Lecture 7A.27
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
CSE3308 - Software Engineering: Analysis and Design, 2003 Lecture 7A.28
A simple solutionConferenceMember
PaperPresenter
TutorialPresenter
SpecialGuest
Organiser
Industrial Academic Student
Registrant
CSE3308 - Software Engineering: Analysis and Design, 2003 Lecture 7A.29
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?
CSE3308 - Software Engineering: Analysis and Design, 2003 Lecture 7A.30
A partial solution - multiple inheritanceConferenceMember
PaperPresenter
TutorialPresenter
SpecialGuest
Organiser
Industrial Academic Student
Registrant
StudentPaperPresenter
OrganiserTutorialPresenter
CSE3308 - Software Engineering: Analysis and Design, 2003 Lecture 7A.31
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
CSE3308 - Software Engineering: Analysis and Design, 2003 Lecture 7A.32
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