ch-9_oosd_the_object-oriented_design_process_and_design_axioms.pdf

ooad

1. THE OBJECT-ORIENTED DESIGN
PROCESS AND DESIGN AXIOMS
(CH -9)
By:
Mr.PrachetBhuyan
Assistant Professor,
School of Computer Engineering,
KIIT University

2. Topics to be Discussed
9.1 INTRODUCTION
9.2 THE O-O DESIGN PROCESS
9.3 O-O DESIGN AXIOMS
9.4 COROLLARIES 9.4 COROLLARIES
9.4.1 Corollary 1: Uncoupled Design with Less
Information Content
9.4.2 Corollary 2: Single Purpose
9.4.3 Corollary 3: Large Number of Simpler Classes,
Reusability
School of Computer Engineering, KIIT
University
2

3. Topics to be Discussed contd..
9.4.4 Corollary 4: Strong Mapping
9.4.5 Corollary 5: Standardization
9.4.6 Corollary 6: Designing with Inheritance
9.5 DESIGN PATTERNS 9.5 DESIGN PATTERNS
School of Computer Engineering, KIIT
University
3

4. 9.1 INTRODUCTION
•OOAphaseofsoftwaredevelopmentwason
“whatneedstobedone”.
•Theobjectsdiscovered during analysis can
serveastheframeworkfordesign.
•The class’s attributes, methods and
associationsidentifiedduringanalysismustbe
designedforasadatatypeexpressedinthe
implementationlanguage.
•New classes can be introduced to store
intermediateresultduringprogramexecution.
School of Computer Engineering, KIIT
University
4

5. 9.1 INTRODUCTION contd..
•During design phase we elevate the various
object models (individuals, organizations,
machines, etc) intological entities, some of
whichmightrelatemoretothecomputer whichmightrelatemoretothecomputer
domain(suchasUIsoraccesslayer).
•Good design simplifies the implementation
andmaintenanceofaproject.
•The design model does not look terribly
differentfromtheanalysismodel.
School of Computer Engineering, KIIT
University
5

6. 9.1 INTRODUCTION contd..
•ThedifferencebetweenOOA&OODisthat,at
OODlevel,wefocusontheviewandaccess
classes,suchas:
–Howtomaintaininformationor –Howtomaintaininformationor
–Thebestwaytointeractwiththeauseror
–Presentinformation
•Howeverthetimespentondesignhasagreat
impactontheoverallsuccessofthesoftware
developmentproject.
School of Computer Engineering, KIIT
University
6

7. 9.1 INTRODUCTION contd..
•Herewelook attheO-Odesignprocessand
axioms.
•Thebasicgoalofaxiomaticprocessis:
–Toformalizethedesignprocess –Toformalizethedesignprocess
–Assistinestablishingascientificfoundationforthe
O-Odesignprocess
–To provide a fundamental basis for creation of
systems.
School of Computer Engineering, KIIT
University
7

8. 9.2 THE O-O DESIGN PROCESS
OOD Design Process in UA
Continue Testing
School of Computer Engineering, KIIT
University
8

9. 9.2 THE O-O DESIGN PROCESS
TheO-Odesignprocessconsistsofthefollowing
activities:
1. Applydesignaxiomstodesignclasses,their
attributes,methods,associations,structures attributes,methods,associations,structures
&protocols.
i. Refine and complete the static UML class
diagram by adding details to the UML class
diagram.Thisstepsconsistsof:
a) Refineattributes
School of Computer Engineering, KIIT
University
9

10. 9.2 THE O-O DESIGN PROCESS contd..
b) Design methods & Protocols by utilizing a UML
activitydiagramtorepresentthemethod’salgorithm.
c) Refineassociationsbetweenclasses(ifrequired)
d) Refine class hierarchy & design with inheritance (if
required) required)
ii. Iterateandrefineagain.
2. Designtheaccesslayer(CH-11)
i. Create mirror classes. For every business class
identifiedandcreated,createoneaccessclass.
ii. Identifyaccesslayerclassrelationships.
School of Computer Engineering, KIIT University 10

11. 9.2 THE O-O DESIGN PROCESS contd..
iii. Simplifyclassesandtheirrelationships.Eliminate
redundantclasses&structures.
a) Redundant classes: Do not keep two classes that
performsimilartranslaterequestandtranslateresults
activities.Simplyselectoneandeliminatetheother. activities.Simplyselectoneandeliminatetheother.
b) Method classes: Revisit the classes consisting of only
oneortwomethodstoseeiftheycanbeeliminated
orcombinedwithexistingclases.
iv. Iterateandrefineagain.
3. Designtheviewlayerclasses(CH-12)
School of Computer Engineering, KIIT University 11

12. 9.2 THE O-O DESIGN PROCESS contd..
i. Designthemacroleveluserinterface,identifying
viewlayerobjects.
ii. Designthemicroleveluserinterface,consistsof:
a)Designtheviewlayerobjectsbyapplyingthedesign
axiomsandcorollaries.
b) Buildaprototypeoftheviewlayerinterface.
iii. Testusability&usersatisfaction
iv. Iterate&refine.
4. Iterate&refinethewholedesign.
School of Computer Engineering, KIIT
University
12

13. 9.3 O-O DESIGN AXIOMS
•Anaxiomisafundamentaltruththatalwaysis
observedtobevalidandforwhichthereisno
counterexampleorexception.
•Atheoremisapropositionthatmaynotbeself- •Atheoremisapropositionthatmaynotbeself-
evident but can be proven from accepted
axioms.(henceequivalenttoalaworprinciple)
•Acorollaryisapropositionthatfollowsfroman
axiom or another proposition that has been
proven.
School of Computer Engineering, KIIT
University
13

14. 9.3 O-O DESIGN AXIOMS contd..
Suh’sdesignaxiomsappliedtoO-Odesign:
•AXIOM1:Theindependenceaxiom.Maintainthe
independenceofcomponents.
–Axiom1dealswithrelationshipsbetweensystem –Axiom1dealswithrelationshipsbetweensystem
components ( such as classes, requirements and
softwarecomponents)
•AXIOM2:Theinformationaxiom.Minimizethe
informationcontentofthedesign.
–Axiom2dealswiththecomplexityofdesign.
School of Computer Engineering, KIIT
University
14

15. 9.3 O-O DESIGN AXIOMS contd..
•Axiom2isconcernedwithsimplicity.Occam’srazor
ruleofsimplicityintermsofO-O:
–Thebestdesignsusuallyinvolvestheleastcomplexcode
but not necessarily the fewest number of classes or
methods. methods.
–Minimizingcomplexityshouldbethegoal,becausethat
produces the most easily maintained and enhanced
application.
–Inano-osystem,thebestwaytominimizecomplexityis
touseinheritanceandthesystem’sbuilt-inclassesand
toaddaslittleaspossibletowhatalreadyisthere.
School of Computer Engineering, KIIT
University
15

16. 9.3 O-O DESIGN AXIOMS contd..
•OCCAM’S RAZOR Says..
•“Thebesttheoryexplainstheknown •“Thebesttheoryexplainstheknown
facts with aminimum amount of
complexityandmaximumsimplicityand
straightforwardness.”
School of Computer Engineering, KIIT
University
16

17. 9.4 COROLLARIES
•Fromthetwodesignaxioms,manycorollaries
maybederived.
•These corollaries may be more useful in
makingspecificdesigndecisions,thanthe makingspecificdesigndecisions,thanthe
originalaxiomsinactualsituations.
•Theymayevenbecalleddesignrulesderived
fromtwobasicaxioms.
School of Computer Engineering, KIIT
University
17

18. 9.4 COROLLARIES contd..
•The Origin of Corollaries:
COROLLARY 4
School of Computer Engineering, KIIT
University
18
AXIOM 1
AXIOM 2
COROLLARY 1
COROLLARY 2
COROLLARY 3
COROLLARY 5COROLLARY 6

19. 9.4 COROLLARIES contd..
•Corollary 1:Uncoupled Design with Less
InformationContent.
–Highly cohesive objects can improve coupling
becauseonlyaminimalamountofessential becauseonlyaminimalamountofessential
informationneedbepassedbetweenobjects.
•Corollary2:SinglePurpose.
–Each class must have a single,clearly defined
purposewhichcanbedescribeinfewsentences.
School of Computer Engineering, KIIT
University
19

20. 9.4 COROLLARIES contd..
•Corollary3:LargeNumberofSimpleClasses.
–Keepingtheclassessimpleallowsreusability.
•Corollary 4: Strong Mapping.
–There must be strong association between the
physicalsystem(analysis’sobject)&logicaldesign
(design’sobject)
School of Computer Engineering, KIIT
University
20

21. 9.4 COROLLARIES contd..
•Corollary5:Standardization.(Promoteit.)
–Bydesigninginterchangeablecomponents&
–Byreusingexistingclasses&components.
•Corollary6:DesignwithInheritance. •Corollary6:DesignwithInheritance.
–Commonbehavior (methods)mustbemovedto
superclasses.
–The superclass-sub class structure must make
logicalsense.
School of Computer Engineering, KIIT
University
21

22. 9.4.1 Corollary 1: Uncoupled Design with
Less Information Content
•Themaingoalhereis:
–To maximize objects cohesiveness among objects &
softwarecomponentstoimprovecoupling.
•9.4.1.1COUPLING:Couplingisameasureofthe •9.4.1.1COUPLING:Couplingisameasureofthe
strength of associationestablished by a
connection from one object or software
componenttoanother.
–Couplingisa
binaryrelationship:AiscoupledwithB
–Strongcouplingamongobjectscomplicatesasystem.
School of Computer Engineering, KIIT
University
22

23. 9.4.1 Corollary 1: Uncoupled Design with
Less Information Content
contd..
•Thedegreeofcouplingisafunctionof:
1. Howcomplicatedtheconnectionis.
2. Whether the connection refers to the object
itselforsomethinginsideit. itselforsomethinginsideit.
3. Whatisbeingsentorreceived.
•Thedegreeorstrengthofcouplingbetween
twocomponentsismeasuredbytheamount
& complexity of information transmitted
betweenthem.
School of Computer Engineering, KIIT
University
23

24. 9.4.1 Corollary 1: Uncoupled Design with
Less Information Content
contd..
•StrongCoupling:Couplingincreases(becomes
stronger) with increasing complexity or
obscurityoftheinterface.
•LoworWeakCoupling:Couplingdecreases •LoworWeakCoupling:Couplingdecreases
(becomes lower) when the connection is to
the component interface rather than to an
internalcomponent.
–Coupling also is lower for data connections than
forcontrolconnections.
School of Computer Engineering, KIIT
University
24

25. üO-ODesignhasTWOtypesofCoupling:
1. InteractionCoupling:Involvestheamountand
complexityofmessagesbetweencomponents.
–GeneralGuideline:istokeepthemessagesassimple
9.4.1 Corollary 1: Uncoupled Design with
Less Information Content
contd..
–GeneralGuideline:istokeepthemessagesassimple
&infrequentaspossible.
–Ex:Ifamessageconnectioninvolvesmorethanthree
parameters(eg: in Method(X,Y,Z) where X,Y,Z are
parameters and any change in one will have ripple
effectofchangesinother.HenceTIGHTLYCOUPLED.
School of Computer Engineering, KIIT
University
25

26. •Eis a Tightly Coupled Object:
9.4.1 Corollary 1: Uncoupled Design with
Less Information Content
contd..
A B C
School of Computer Engineering, KIIT
University
26
D E F
IHG

27. •Types of Interaction Coupling are:
9.4.1 Corollary 1: Uncoupled Design with
Less Information Content
contd..
DEGREE OF
COUPLING
NAME OF COUPLING DESCRIPTION
VERY HIGH CONTENT COUPLING The connection involves direct reference to
attributes or methods of another object.
HIGH COMMON COUPLING The connection involves two objects accessing
School of Computer Engineering, KIIT
University
27
HIGH COMMON COUPLING The connection involves two objects accessing
a global data space for both to read & write.
MEDIUM CONTROL COUPLING The connection involvesexplic it control of the
processing logic of one object by another.
LOW STAMP COUPLING Involves passing an aggregate data structure to
another object, using partial of it.
VERY LOW DATA COUPLING (Should
be the goal of
Architectural Design)
Involves either simple data items or aggregate
structures all of whose elements are used by
the receiving object.

28. 2. InheritanceCoupling:Itisaformofcoupling
betweensuperandsubclasses.
–Asubclassiscoupledtoitssuperclassintermsofattributesandmethods.
9.4.1 Corollary 1: Uncoupled Design with
Less Information Content
contd..
attributesandmethods.
–Unlike interaction coupling, high inheritance
couplingisdesirable.
School of Computer Engineering, KIIT
University
28

29. •9.4.1.2COHESION: There is a need to
considerinteractionswithinasingleobjector
softwarecomponent,calledcohesion.
–Itreflectsthe“single-purposeness”ofanobject.
9.4.1 Corollary 1: Uncoupled Design with
Less Information Content
contd..
–Itreflectsthe“single-purposeness”ofanobject.
–Highlycohesivecomponentscanlowercouplingas
a minimum information of essential information
needbepassesbetweencomponents.
–Ithelpstodesignclasseswhichhaveveryspecific
purpose.
School of Computer Engineering, KIIT
University
29

30. •TypesofCohesionare:
–Method Cohesion: Like function cohesion, means
thatmethodshouldcarryonlyonefunction.
–ClassCohesion:Itmeansthatalltheclass’smethods
9.4.1 Corollary 1: Uncoupled Design with
Less Information Content
contd..
–ClassCohesion:Itmeansthatalltheclass’smethods
and attributes must be highly cohesive, (used by
internalmethodsorderivedclasses’methods).
–InheritanceCohesion:-Concernedwith:
•Howinterrelatedaretheclasses?
•Does specialization really portray specializationor it isjust
somethingarbitrary?
School of Computer Engineering, KIIT
University
30

31. •Everyclassshouldbeclearlydefined.
•Itisnecessarytoachievethesystem’sgoal.
•Duringdocumentationwe should be able to
explainthepurposeofaclassinoneortwo
9.4.2 Corollary 2: Single Purpose
explainthepurposeofaclassinoneortwo
sentences.
•Ifnot,thenrethinktheclassandtrytosubdivide
theclassintomoreindependentpieces.
•Keep it simple. (Each method to provide one
service.)
School of Computer Engineering, KIIT
University
31

32. 9.4.3 Corollary 3: Large Number of Simpler
Classes, Reusability
•Simplerclassesisbeneficial.
•Itisdifficulttoforeseeallfuturescenariosofthe
classtobereused.
•Thelessspecializedtheclassesare,more •Thelessspecializedtheclassesare,more
problemscanbesolvedbycombiningthemwith
lesssubclasses.GUIDELINE:
•“Thesmallerareyourclasses,thebetterareyour
chancesofreusingtheminotherprojects.Large
and complex classes are too specialized to be
reused” School of Computer Engineering, KIIT
University
32

33. •Coad&YourdondescribesFOURreasonswhy
people arenot utilizing reusability concept
more:
1.Softwareengineeringtextbooksteachnew
9.4.3 Corollary 3: Large Number of Simpler
Classes, Reusability
contd..
1.Softwareengineeringtextbooksteachnew
practitioners to build systems from “first
principle”;reusability is not promoted or even
discussed.
School of Computer Engineering, KIIT
University
33

34. 2. The“not invented here” syndromeand the
intellectual challenge of solving problem an
interesting problem in one’s own unique way
mitigatesagainstreusingsomeoneelse’ssoftware
component.
9.4.3 Corollary 3: Large Number of Simpler
Classes, Reusability
contd..
component.
3. Unsuccessfulexperienceswithsoftwarereusability
inthepasthaveconvincedmanypractitionersand
development managers that the concept is not
practical.
School of Computer Engineering, KIIT
University
34

35. 4. Mostorganizationprovidenorewardforreusability;
sometimesproductivityismeasuredintermsofnew
linesofcodeswrittenplusadiscountedcredit(e.g.,
50%lesscredit)forreusedlinesofcode.
9.4.3 Corollary 3: Large Number of Simpler
Classes, Reusability
contd..
•BenefitsofSoftwareReusability:
ØHigherproductivity
ØThesoftwaredevelopmentteamthatachieves80%
reusability isfour times as productiveas the team
thatachievesonly20%reusability.
School of Computer Engineering, KIIT
University
35

36. ØUsingsuccessfuldesignpatternswecanrecreate.
ØO-O design encourages reusable libraries
supportedbyOOPlanguages.
ØO-Odesignemphasizesonreusingconceptslike:
9.4.3 Corollary 3: Large Number of Simpler
Classes, Reusability
contd..
ØO-Odesignemphasizesonreusingconceptslike:
i. Encapsulation
ii. Modularization(e.g.,classstructure)
iii. Polymorphism
School of Computer Engineering, KIIT
University
36

37. 9.4.4 Corollary 4: Strong Mapping
•OOA&OODarebasedonsameUMLmodel.
•Eg;Duringanalysiswemightidentifyaclass
EMPLOYEE.Duringthedesignphase,weneed
todesignthisclass: todesignthisclass:
–Designitsmethods
–Designitsassociationwithotherobjects
–Designitsview&accessclasses
School of Computer Engineering, KIIT
University
37

38. •Astrong mapping links classesidentified
during analysis and classes designed during
thedesignphase.
•AccordingtoMartin&Odell:
9.4.4 Corollary 4: Strong Mapping contd..
•AccordingtoMartin&Odell:
–With O-O technique thesame paradigmis used
foranalysis,design&implementation.
–Theanalystidentifiesobjects’types&inheritance
&thinkabouttheeventsthatchangethestateof
object.
School of Computer Engineering, KIIT
University
38

39. –Thedesigneradds details to this model perhaps
designing screens, user interaction, and client-
serverinteraction.
–Thethoughtprocessflowssonaturallyfrom
9.4.4 Corollary 4: Strong Mapping contd..
analyst to design that it may be difficult to tell
whereanalysisendsanddesignbegins.
School of Computer Engineering, KIIT
University
39

40. 9.4.5 Corollary 5: Standardization
•Toreuseoneshouldhavegoodunderstandingof
classesinOOPenvironment.
•Most OOP such as Smalltalk, Java, C++, or
PowerBuildercomewithbuilt-inclasslibraries. PowerBuildercomewithbuilt-inclasslibraries.
•O-O systems grow as you create new
applications.
•Theknowledgeofexistingclasswillhelpinreuse
byinheritingfromtheexistingclasslibraries.
School of Computer Engineering, KIIT
University
40

41. Someshortfall:
•However class libraries are not always well
documentedandupdated.
•Classlibrariesshouldbeeasilysearchedbased
9.4.5 Corollary 5: Standardization contd..
•Classlibrariesshouldbeeasilysearchedbased
onuser’scriteria.
Solution:
•Making a repository ofDesign Patternscan
givesomesolutionstoalltheseproblems.
School of Computer Engineering, KIIT
University
41

42. 9.4.6 Corollary 6: Designing with
Inheritance
•When you implement a class you have to
determineitsancestor,alongwith:
–Whatattributesitwillhave&
–Whatmessagesitwillunderstand. –Whatmessagesitwillunderstand.
•Thenitsmethods&protocolsareconstructed.
•Ideally you will choose inheritance to
minimizetheamountofprograminstructions.
School of Computer Engineering, KIIT
University
42

43. •Issueherewillbe:
–Achieving Multiple Inheritance in a Single
InheritanceSystem.
–AvoidingInheritingInappropriateBehaviors.
9.4.6 Corollary 6: Designing with
Inheritance
contd..
–AvoidingInheritingInappropriateBehaviors.
•Eg: Developing an application for the
government that manages the licensing
procedureforavarietyofregulatedentities:
•Like: License,Motor Vehicle, Private Vehicle,
CommercialVehicle, Restaurant,FoodTruck.
School of Computer Engineering, KIIT
University
43

44. •The Initial Inheritance Design
9.4.6 Corollary 6: Designing with
Inheritance
contd..
School of Computer Engineering, KIIT
University
44

45. •The Single Inheritance Design Modified to
AllowLicensingFoodTrucks.
9.4.6 Corollary 6: Designing with
Inheritance
contd..
School of Computer Engineering, KIIT
University
45

46. •Alternately you can Modify the Single
Inheritance Design to Allow Licensing Food
Truck.
9.4.6 Corollary 6: Designing with
Inheritance
contd..
School of Computer Engineering, KIIT
University
46

47. •Multiple InheritanceDesign of the System
Structure
9.4.6 Corollary 6: Designing with
Inheritance
contd..
School of Computer Engineering, KIIT
University
47

48. •DesignPatternsaredevices:
–that allows systems to share knowledge about
theirdesign,
–bydescribingcommonlyrecurringstructuresof
9.5 DESIGN PATTERNS (Eg:)
–bydescribingcommonlyrecurringstructuresof
communicatingcomponents
–that solve a general design problem within a
particularcontext.
•Documentingpatternsisonewaythatallows
reuse&sharinginformationofbestpractices.
School of Computer Engineering, KIIT
University
48

49. DesignPatternexamplecreatedbyKutotsuchi
•PatternName:Facade
•Rational&Motivation:Thispatterncanmake
thetaskofaccessingalargenumberof
9.5 DESIGN PATTERNS (Eg:) contd..
thetaskofaccessingalargenumberof
modules much simpler by providing an
additionalinterfacelayer.
–This is done by creating a small collection of
classes that have a single class that is used to
accessthem,the
FACADE.
School of Computer Engineering, KIIT
University
49

50. •Classes:Therecanbeanynumberofclasses
involvedinthis“facade”system,but
–At least
four or moreclasses are required:One
client,thefacade,&theclassesunderneaththe
9.5 DESIGN PATTERNS (Eg:) contd..
client,thefacade,&theclassesunderneaththe
facade.
–Afacadewouldbehavinglimitedcodingmostof
thetimemakingcallstolowerlayers.
•Advantages:Using the facade to make the
interfacingbetweenmanymodulesorclasses.
School of Computer Engineering, KIIT
University
50

51. •Disadvantages:We may loose some
functionality contained in the lower level of
classes,butthisdependsonhowthefacade
wasdesigned.
9.5 DESIGN PATTERNS (Eg:) contd..
wasdesigned.
•Example:Imaginethereisa needtowritea
programthatneedstorepresentabuildingas
rooms that can be manipulated to interact
withobjects(windows,screens,projector,etc)
intheroomtochangetheirstate.
School of Computer Engineering, KIIT
University
51

52. •UsingaDesignPatternFAÇADEEliminatestheneedfor
theclientclasstodealwithalargenumberofclasses.
9.5 DESIGN PATTERNS (Eg:) contd..
School of Computer Engineering, KIIT
University
52

53. •END of CHAPTER 9
•USE DESIGN PATTERNS IN YOUR O-O •USE DESIGN PATTERNS IN YOUR O-O
SOFTWARE DESIGN
School of Computer Engineering, KIIT
University
53