The Software Design ProcessOutlineChallenges in DesignSlide 4Slide 5Levels of DesignKey Design ConceptsGood Design CharacteristicsSlide 9Slide 10Slide 11Slide 12Slide 13Slide 14Slide 15Slide 16Slide 17Slide 18Design HeuristicsFind Real-World ObjectsForm Consistent AbstractionsInheritanceInformation HidingMore on Information HidingIdentify Areas Likely to ChangeKeep Coupling LooseKinds of CouplingExamples of Semantic CouplingDesign PatternsMore on Design PatternsOther HeuristicsMore HeuristicsSlide 33Design Practices (we may return to these)The Software Design ProcessCPSC 315 – Programming StudioSpring 2009OutlineChallenges in DesignDesign ConceptsHeuristicsPracticesChallenges in DesignA problem that can only be defined by solving itOnly after “solving” it do you understand what the needs actually aree.g. Tacoma Narrows bridge design“Plan to throw one away”Challenges in DesignProcess is SloppyMistakesWrong, dead-end pathsStop when “good enough”Tradeoffs and PrioritiesDetermine whether design is goodPriorities can changeChallenges in DesignRestrictions are necessaryConstraints improve the resultNondeterministic processNot one “right” solutionA Heuristic processRules of thumb vs. fixed processEmergentEvolve and improve during design, codingLevels of DesignSoftware system as a wholeDivision into subsystems/packagesClasses within packagesData and routines within classesInternal routine designWork at one level can affect those below and above.Design can be iterated at each levelKey Design ConceptsMost Important: Manage ComplexitySoftware already involves conceptual hierarchies, abstractionGoal: minimize how much of a program you have to think about at onceShould completely understand the impact of code changes in one area on other areasGood Design CharacteristicsMinimal complexityFavor “simple” over “clever”Good Design CharacteristicsMinimal complexityEase of maintenanceImagine what maintainer of code will want to knowBe self-explanatoryGood Design CharacteristicsMinimal complexityEase of maintenanceLoose couplingKeep connections between parts of programs minimizedAvoid n2 interactions!Abstraction, encapsulation, information hidingGood Design CharacteristicsMinimal complexityEase of maintenanceLoose couplingExtensibilityShould be able to add to one part of system without affecting othersGood Design CharacteristicsMinimal complexityEase of maintenanceLoose couplingExtensibilityReusabilityDesign so code could be “lifted” into a different systemGood design, even if never reusedGood Design CharacteristicsMinimal complexityEase of maintenanceLoose couplingExtensibilityReusabilityHigh fan-inFor a given class, have it used by many othersIndicates good capture of underlying functionsGood Design CharacteristicsMinimal complexityEase of maintenanceLoose couplingExtensibilityReusabilityHigh fan-inLow-to-medium fan-outDon’t use too many other classesComplexity managementGood Design CharacteristicsMinimal complexityEase of maintenanceLoose couplingExtensibilityReusabilityHigh fan-inLow-to-medium fan-outPortabilityConsider what will happen if moved to another environmentGood Design CharacteristicsMinimal complexityEase of maintenanceLoose couplingExtensibilityReusabilityHigh fan-inLow-to-medium fan-outPortabilityLeannessDon’t add extra partsExtra code will need to be tested, reviewed in future changesGood Design CharacteristicsMinimal complexityEase of maintenanceLoose couplingExtensibilityReusabilityHigh fan-inLow-to-medium fan-outPortabilityLeannessStratificationDesign so that you don’t have to consider beyond the current layerGood Design CharacteristicsMinimal complexityEase of maintenanceLoose couplingExtensibilityReusabilityHigh fan-inLow-to-medium fan-outPortabilityLeannessStratificationStandard TechniquesUse of common approaches make it easier to follow code laterAvoid unneeded exotic approachesDesign HeuristicsRules-of-thumb“Trials in Trial-and-Error”Understand the ProblemDevise a PlanCarry Out the PlanLook Back and IterateFind Real-World ObjectsStandard Object-Oriented approachIdentify objects and their attributesDetermine what can be done to each objectDetermine what each object is allowed to do to other objectsDetermine the parts of each object that will be visible to other objects (public/private)Define each object’s public interfaceForm Consistent AbstractionsView concepts in the aggregate“Car” rather than “engine, body, wheels, etc.”Identify common attributesForm base classFocus on interface rather than implementationForm abstractions at all levelsCar, Engine, PistonInheritanceInherit when helpfulWhen there are common featuresInformation HidingInterface should reveal little about inner workingsExample: Assign ID numbersAssignment algorithm could be hiddenID number could be typedEncapsulate Implementation DetailsDon’t set interface based on what’s easiest to useTends to expose too much of interiorThink about “What needs to be hidden”More on Information HidingTwo main advantagesEasier to comprehend complexityLocalized effects allow local changesIssues:Circular dependenciesA->B->AGlobal data (or too-large classes)Performance penaltiesValid, but less important, at least at firstIdentify Areas Likely to ChangeAnticipate ChangeIdentify items that seem likely to changeSeparate these items into their own classLimit connections to that class, or create interface that’s unlikely to changeExamples of main potential problems:Business Rules, Hardware Dependencies, Input/Output, Nonstandard language features, status variables, difficult design/coding areasKeep Coupling LooseRelations to other classes/routinesSmall SizeFewer parameters, methodsVisibleAvoid interactions via global variablesFlexibleDon’t add unnecessary dependenciese.g. using method that’s not unique to the class it belongs toKinds of CouplingData-parameter (good)Data passed through parameter listsPrimitive data typesSimple-object (good)Module instantiates that objectObject-parameter (so-so)Object 1 requires Object 2 to pass an Object 3Semantic (bad)One object makes use of semantic information about the inner workings of anotherExamples of Semantic CouplingModule 1 passes control flag to Module 2Can be OK if control flag is typedModule 2 uses global data that Module 1 modifiesModule 2 relies on knowledge that Module 1 calls initialize