Specification and DesignUse formal specificationUse formal specificationsWhat you should know about formal methodsTests as specificationAdvantages of tests as specificationsDisadvantages of tests as specificationJUnitTesting Student and CourseNormal testSlide 11Tests as specificationsDesignLife-cycleA good designKeep It Simple (S)Keep it SimpleDavis Design PrinciplesSlide 19DavisMany things to designSlide 22What can go wrong?Too hard to add new featuresSeparate User InterfaceAutomated testsSummaryProject adviceNext time1Specification and DesignChapters 9,10,11CS427 14-2Use formal specificationTo develop models of parts of systemFinite state machines, abstract data typesTo develop model of one aspect of systemData-flow diagram, security, architectureTo learn how to think about problempre/post conditionsset,sequence,mappings (generic ADTs)CS427 14-3Use formal specificationsFor particular kinds of applicationscompilersgrammardenotational semanticssafety criticalCS427 14-4What you should know about formal methodsWhat is in the book – chapter 10Be familiar with the controversyDon’t need to learn PrologCS427 14-5Tests as specificationFormal specificationBalance after you add money to an account will be the balance beforehand plus the amount of money you addedTestCreate account with balance of $100Add $20 to accountAccount has balance of $120CS427 14-6Advantages of tests as specificationsConcrete, easy to understandDon’t need new languageEasy to see if program meets the specificationsMaking tests forces you to talk to customer and learn the problemMaking tests forces you to think about design of system (classes, methods, etc.)CS427 14-7Disadvantages of tests as specificationHard to test that something can’t happenCan’t withdraw more money than you have in the systemCan’t break into the systemCan’t cause a very long transaction that hangs the systemTends to be verboseCS427 14-8JUnitwww.junit.orgA test is a method in a subclass of TestCase.Calls methods (defined in TestCase) likeassertEqual(object1, object2)assertTrue(boolean)CS427 14-9Testing Student and Coursepublic void testStudentCreation() {Student s = new Student("Marvin Minsky");assertTrue(s.getName().equals("Marvin Minsky"));}orpublic void testStudentCreation() {Student s = new Student("Marvin Minsky");assertEqual(s.getName(), "Marvin Minsky");}CS427 14-10Normal testSet up “test fixture”Call method that is being testedAssert that result is correctCS427 14-11public void testAddingStudent(){ Course c; Student s; c = new Course("Tourism 101"); s = new Student("Donald Knuth"); c.addStudent(s); assertEquals(c.students().size(), 1); assertEquals(c.students().elementAt(0), s);CS427 14-12Tests as specificationsTests show how to use the systemTests need to be readableneed comments that describe their purposekeep short, delete duplicationCS427 14-13DesignVerbTo conceive or plan out in the mind.To make a drawing, pattern, or sketch of.CS427 14-14Life-cycleRequirements captureSpecificationDesignImplementationCS427 14-15A good designSatisfies requirementsEasy to implementEasy to understandEasy to changeEasy to check for correctnessIs beautifulCS427 14-16Keep It Simple (S)Everything should be as simple as possible, but no simpler. (Einstein)A design is finished not when there is nothing to add, but when there is nothing to take away. (Saint-Exupery)Measuring a program by the number of lines of code in it is like measuring an airplane by how much it weighs. (Gates)CS427 14-17Keep it SimpleAvoid duplicationEliminate unnecessary features/codeHide informationNo surprises (follow standards)CS427 14-18Davis Design PrinciplesDon’t reinvent the wheel.Search the web. Read the book. Talk to experts. Exhibit uniformity and integration.Make parts as similar as possibleCoding standardStandard namesCS427 14-19Davis Design PrinciplesMinimize the intellectual distance between the software and the problem as it exists in the real world.Use same names as your customersUse same models as your customersStructure the design to accommodate change.CS427 14-20DavisThe design should be structured to degrade gently, even when aberrant data, events, or operating conditions are encountered.The design should be assessed for quality as it is being created, not after the fact.The design should be reviewed to minimize conceptual errors.CS427 14-21Many things to designCompanySystem that uses programInterface to programInterface of module within programProcedureDatabaseCS427 14-22DesignProcess of eliminating “misfits”Find something wrong and fix itGood design requires being able to spot something that is wrongCS427 14-23What can go wrong?Too complex - can’t understandUsers can’t understandProgrammers can’t understandToo slowWrong featuresToo hard to add new featuresNot compatibleCS427 14-24Too hard to add new featuresUsually because problem is decomposed improperlyDesign decisions should be hiddenOnly one module should know about design decisionChanging that decision requires changing only one moduleCS427 14-25Separate User InterfaceSeparate user interface from program logicUI changes frequentlyIt is easier to change UI if it is separateUI experts can be non-programmersCan provide several UIs for one systemCS427 14-26Automated testsUI hard to testSeparate UI from program logic and write automated tests for program logic.UI first?No, design program logic first and write tests for it.Database first?No, design program logic first and write tests for it. Then design database and rewrite to use itCS427 14-27SummaryFuzzy boundaries between analysis and design design and implementationDesign is problem solvingIt helps to know a lot of solutionsCS427 14-28Project adviceYou are graded on how well you follow your process.You must know it.You must follow it.You must prove you follow it.Make a log of what you do every day.CS427 14-29Next timeRead chapter 13 and 14 of Hamlet and