1. CSE3308 - Software Engineering: Analysis and Design, 2003Lecture 7A.1 Software Engineering: Analysis and Design - CSE3308 Object-Oriented Design CSE3308/DMS/2003/17 Monash University School of Computer Science and Software Engineering

2. CSE3308 - Software Engineering: Analysis and Design, 2003Lecture 7A.2 Lecture Outline u What is Object-Oriented Design? u Three OO Design Key Ideas u Principles of Object-Oriented Design v Encapsulation v Connascence v Class Cohesion v Subclasses vs. Subtypes v Inheritance u Some design problems

3. CSE3308 - Software Engineering: Analysis and Design, 2003Lecture 7A.3 What is OO Design? u No clear boundary between analysis and design u Use mostly the same tools to describe design as used to describe analysis u Simply put in terms of the 3 perspectives v Conceptual - Analysis v Specification - Analysis and Design v Implementation - Design

4. CSE3308 - Software Engineering: Analysis and Design, 2003Lecture 7A.4 OO Design Key Ideas u Abstraction v 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

5. CSE3308 - Software Engineering: Analysis and Design, 2003Lecture 7A.5 OO Key Design Ideas (2) u Reduction of dependencies v A dependency exists when a change in some element of software may cause changes in another element of software v This is the major cause of maintenance problems v We aim to reduce dependencies as much as possible v Shown as dashed lines in UML (e.g. in Package Diagrams) Buttons and Lamps

6. CSE3308 - Software Engineering: Analysis and Design, 2003Lecture 7A.6 Buttons and Lamps - The Use Case and the Model Name: Turn lamp on and off Actors: ButtonPusher Type: Primary Description: When the ButtonPusher presses the button, the lamp goes on if it was off, and goes off if it was already on. Lamp Button Turn on() or Turn off()

7. CSE3308 - Software Engineering: Analysis and Design, 2003Lecture 7A.7 Coding Directly from the Model 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

8. CSE3308 - Software Engineering: Analysis and Design, 2003Lecture 7A.8 A better solution Button {abstract} Button Implementation Lamp Button Client {abstract}

9. CSE3308 - Software Engineering: Analysis and Design, 2003Lecture 7A.9 Why is it better? u Underlying abstraction is to relay an on/off gesture from a user to a target object u Has removed implementation from the abstraction  Button knows nothing about implementation of detecting the user gesture  Button knows nothing about Lamp u Highly resistant to change and high level abstractions are easily reused elsewhere u Use case requirements are still easily traceable in the design

10. CSE3308 - Software Engineering: Analysis and Design, 2003Lecture 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.h Button::Button(ButtonClient& bc) : itsClient(&bc) {} void Button::Detect() { bool buttonOn = GetState(); if (buttonOn) itsClient->TurnOn(); else itsClient->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(); };

11. CSE3308 - Software Engineering: Analysis and Design, 2003Lecture 7A.11 OO Key Design Ideas - The Open/Closed Principle u Classes should be open for extension, but closed for modification u 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 u 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 u This is normally implemented with inheritance/polymorphism in OO systems

12. CSE3308 - Software Engineering: Analysis and Design, 2003Lecture 7A.12 Encapsulation u Encapsulation is the process of compartmentalising the elements of an abstraction that constitute its structure and behaviour u Encapsulation serves to separate the contractual interface of an abstraction and its implementation u Levels v Level 0 - No encapsulation v Level 1 - Encapsulation within a procedural module v Level 2 - Encapsulation within a class v Level 3 - Encapsulation within a package (Ambiguous)

13. CSE3308 - Software Engineering: Analysis and Design, 2003Lecture 7A.13 Types of Dependency or Connascence u Static Connascence - what can be assessed from the code/structure of the classes v Connascence of name - int i; i := 7 v Connascence of type or class - both i’s must be of the same type v Connascence of meaning - e.g. different account number ranges having different meaning v Connascence of algorithm - two elements sharing the same algorithm v 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

14. CSE3308 - Software Engineering: Analysis and Design, 2003Lecture 7A.14 Dynamic Connascence u Connascence based on the execution pattern of the running code, i.e. the objects rather than the classes v Connascence of Execution - e.g. initialising a variable before using it v 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 v Connascence of Value - e.g. an arithmetic constraint: the three angles of a triangle must always equal 180 degrees v 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 v 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

15. CSE3308 - Software Engineering: Analysis and Design, 2003Lecture 7A.15 Connascence and Encapsulation u Connascence is not inherently a bad thing u Use encapsulation to manage connascence u Guidelines v Minimise overall connascence by breaking the system into encapsulated components v Minimise any connascence which crosses encapsulation boundaries v Maximise the connascence within encapsulation boundaries

16. CSE3308 - Software Engineering: Analysis and Design, 2003Lecture 7A.16 Connascence Abuses u The friend function of C++ v lets an unrelated class have access to the private/implementation aspects of a class - therefore high connascence across encapsulation boundaries v Unconstrained Inheritance v Letting sub-classes access the private/implementation aspects of the superclass v Controversial u Accidents of Implementation v 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

17. CSE3308 - Software Engineering: Analysis and Design, 2003Lecture 7A.17 Class Cohesion u Measures the interrelatedness of the methods in the external interface of a class u How well does the class hang together as an implementation of an abstraction u Low cohesion - bad! High cohesion - good! u No quantitative measure u Some people say the more overlap in methods’ use of private variables in a class the higher the cohesion v Cohesion should be visible from the outside v Private/implementation variables can change without affecting the interface, thus the measure is unstable

18. CSE3308 - Software Engineering: Analysis and Design, 2003Lecture 7A.18 Symptoms of Low Class Cohesion u 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 v In the latter case, commission-rate is irrelevant u 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

19. CSE3308 - Software Engineering: Analysis and Design, 2003Lecture 7A.19 Symptoms (2) u Mixed Domain Cohesion - where the class contains components which are not relevant to the domain of the class u Where Domain is v Application Domain - comprises classes valuable for one application v Business Domain - comprises classes valuable for one industry or company v Architectural Domain - comprises classes valuable for one implementation architecture v Foundation Domain - comprises classes valuable across all businesses and architectures » Semantic Subdomain - DATE, TIME, MONEY » Structural Subdomain - QUEUE, SET, LIST » Fundamental Subdomain - INTEGER, BOOLEAN

20. CSE3308 - Software Engineering: Analysis and Design, 2003Lecture 7A.20 Mixed Domain Cohesion (2) u Example - Class REAL contains the method arctan (takes a real number r and returns the angle whose tangent is r) u But arctan is not really an aspect of a Real Number, it is an aspect of an ANGLE class u For example, should a REAL class have a convert-temp method, because it takes a real number and converts it to another real number? u Components should be intrinsic to the class, u Ask if the class can be built without the other component class - i.e can I build REAL without ANGLE? ANGLE without REAL?

21. CSE3308 - Software Engineering: Analysis and Design, 2003Lecture 7A.21 Symptoms (3) u Mixed Role Cohesion - the class has a component which is from the same domain but is not part of the abstraction u e.g class PERSON has a method number_of_dogs_owned u But Dogs are not really part of the person abstraction, they are not an intrinsic part of the abstraction u Do we put in methods for cats, horse, budgerigars, goldfish, etc. etc. u Mixed role cohesion reduces the reusability of the class

22. CSE3308 - Software Engineering: Analysis and Design, 2003Lecture 7A.22 Subclasses and Subtypes u For class S to be a true subtype of class T, then S must conform to T u 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 u Known as the Liskov Substitutability Principle u But we can have subclasses which are not subtypes.

23. CSE3308 - Software Engineering: Analysis and Design, 2003Lecture 7A.23 Subclasses and Subtypes (2) u In a sound OO system, all subclasses should also be subtypes u This is not always possible Ellipse Circle But what happens when a circle gets a stretch_along_x_axis message? Ellipse Circle ConicSection

24. CSE3308 - Software Engineering: Analysis and Design, 2003Lecture 7A.24 Inheritance Pitfalls u Mistaken Aggregates - using inheritance where the relationship is actually aggregation Aeroplane Wing EngineFuselageTail

25. CSE3308 - Software Engineering: Analysis and Design, 2003Lecture 7A.25 Abusing Multiple Inheritance Aeroplane Wing EngineFuselageTail

26. CSE3308 - Software Engineering: Analysis and Design, 2003Lecture 7A.26 Inverted Hierarchy Board Member Manager Employee Manager Board member

27. CSE3308 - Software Engineering: Analysis and Design, 2003Lecture 7A.27 Some design problems u Roles versus Inheritance u Example vComputer Science Conference wants a registration system vConference members can be: »Organisers »Special Guests »Tutorial Presenters »Paper Presenters »Industrial Registrants »Academic Registrants »Student Registrants

28. CSE3308 - Software Engineering: Analysis and Design, 2003Lecture 7A.28 A simple solution Conference Member Paper Presenter Tutorial Presenter Special Guest Organiser IndustrialAcademicStudent Registrant

29. CSE3308 - Software Engineering: Analysis and Design, 2003Lecture 7A.29 Some problems with the solution u What happens if we have an organiser who is also giving a tutorial? u What happens if a student registrant is also giving a paper? u What happens if a conference member withdraws their paper but still attends as an academic registrant?

30. CSE3308 - Software Engineering: Analysis and Design, 2003Lecture 7A.30 A partial solution - multiple inheritance Conference Member Paper Presenter Tutorial Presenter Special Guest Organiser IndustrialAcademicStudent Registrant Student Paper Presenter Organiser Tutorial Presenter

31. CSE3308 - Software Engineering: Analysis and Design, 2003Lecture 7A.31 Another solution u In this particular case, multiple inheritance is not a particularly good solution u Roles are a much better solution as they are more flexible Conference Member Conference Role performs 1..* AcademicIndustrial Paper Presenter Tutorial Presenter Registrant Special Guest Organiser Student

32. CSE3308 - Software Engineering: Analysis and Design, 2003Lecture 7A.32 Robert Martin’s Principles u Cover several of the ideas in this lecture u Available with many other excellent articles on OO Design at: http://www.objectmentor.com/ (links can be found on Resources page of unit website)http://www.objectmentor.com/ u Editor of the C++ Report u Principles are illustrated with C++ code, but are equally applicable to any OO design Open-Closed PrincipleLiskov Substitution Principle Dependency Inversion PrincipleInterface Segregation Principle Reuse/Release Equivalency PrincipleCommon Closure Principle Common Reuse PrincipleAcyclic Dependencies Principle Stable Dependencies PrincipleStable Abstractions Principle

33. CSE3308 - Software Engineering: Analysis and Design, 2003Lecture 7A.33 References u Page-Jones, Meilir, Fundamentals of Object- Oriented Design in UML, Addison-Wesley, 2000 (Ch. 8, 9) u C++ Report articles mentioned on previous slide, and available via the unit web site