CMSC 132: Object-Oriented Programming IIProblem Specification & DesignDepartment of Computer ScienceUniversity of Maryland, College ParkOverviewProblem specificationObstaclesProgram designHow to divide workInterface & conditionsProblem SpecificationGoalCreate complete, accurate, and unambiguous statement of problem to be solvedProblemsDescription may not be accurateDescription may change over timeDifficult to specify behavior for all inputsNatural language description is impreciseFormal specification languages limited and difficult to understandProblem SpecificationExampleSpecification of input & output for programProblem Specification ProblemsDescription may not be accurateProblem not understood by customerDescription may change over timeCustomer changes their mindDifficult to specify behavior for all inputsUsually only covers common casesHard to consider all inputs (may be impossible)ExampleMost UNIX utilities crash with random inputsProblem Specification ProblemsDescription may be ambiguousNatural language description is impreciseWhy lawyers use legalese for contracts Formal specification languages are limited and may be difficult to understandExamplesFind sum of all values in N-element list L between 1 and 100∑∑∑∑ Li∋∋∋∋ (Li≥≥≥≥ 1) ∧∧∧∧ (Li≤≤≤≤ 100)Difficult to write specifications that are both readable and precisei = 0N-1Program DesignGoalBreak software into integrated set of componentsthat work together to solve problem specificationProblemsMethods for decomposing problemHow to divide workWhat work to divideHow components work togetherDesign – How To Divide WorkDecomposing problemBreak large problem into many smaller problemsCannot solve large problems directlyDivide and conquer1.Break problem up into simpler sub-problems2.Repeat for each sub-problem3.Stop when sub-problem can be solved easilyDesign – How To Divide WorkFunctional approachTreat problem as a collection of functionsTechniquesTop-down designSuccessively split problem into smaller problemsBottom-up designStart from small tasks and combineDesign – Decomposition ExampleTop-down design of banking simulatorDesign – How To Divide WorkObject-oriented approachTreat problem as a collection of data objectsObjects Entities that exist in problemContain dataPerform actions associated with dataDesign – Comparison ExampleBank simulationFunctional programmingArrivals, departures, transactionsObject-oriented programmingCustomers, lines, tellers, transactionsDesign – Comparing ApproachesFunctional approachTreat problem as a collection of functionsFunctions perform actionsThink of functions as verbsObject-oriented approachTreat problem as a collection of data objectsObjects are entities that exist in problemThink of objects as nounsDesign – Comparing ApproachesAdvantages to object-oriented approachHelps to abstract problemSimpler high-level viewHelps to encapsulate dataHides details of internals of objectsCentralizes and protects all accesses to dataSeems to scale better for larger projectsIn practiceTend to use a combination of all approachesDesign – ComponentsComponents must work together easilyEach component requiresInterfaceSpecifies how component is accessed & usedSpecifies what functions (methods) are available Pre-conditionsWhat conditions must be true before invocationPost-conditionsWhat conditions will be true after invocationPre & post conditions represent a contractbetween designer & programmerDesign – Interface & ConditionsFunction positivePower()Calculate xnfor positive values of x & nInterfacepublic static float positivePower(float x, int n)Pre-conditionsx has positive floating point value > 0.0n has positive integer value ≥≥≥≥ 0Post-conditionsReturns xnif preconditions are metReturns –1.0
View Full Document
Unlocking...