CS427: Software Engineering IMidterm examComment on midterm examProject infoTopicsUse formal specifications (1)Use formal specifications (2)What you should know about formal methodsTests as specificationsAdvantages of tests as specsDisadvantages of tests as specsJUnitTesting Student and CourseNormal testMore involved exampleSlide 16DesignLife-cycleA good designKeep It Simple (S)Keep it simpleDavis Design Principles (1)Davis Design Principles (2)DavisMany things to designSlide 26What can go wrong?Too hard to add new featuresSeparate user interfaceAutomated testsSummaryProject advice repeatedNext time1CS427:Software Engineering IDarko Marinov(slides from Ralph Johnson)CS427 14-2Midterm examYou can get graded exams from TAsFeel free to ask if you think we made mistakeGrades almost normally distributedCS427 14-3Comment on midterm examCOCOMO question is picking details from the reading; is it really like that?One correct answer, using formula E ~ sizePThis is not exponential, not E ~ PsizeAnother correct answer, common senseE(200KLOC) = 2*E(100KLOC) + E(integration)Common sense can lead to incorrect answersE(200KLOC) ≤ 2*E(100KLOC)CS427 14-4Project infoGroups formed (any volunteers for 10?)Grading: You are graded on how well you follow your process (you decide XP or RUP)You must know itYou must follow itYou must prove you follow itMake a log of what you do every dayHW2 is due next Tuesday, Oct 24Use cases and UML diagrams for your projectCS427 14-5TopicsCoveredRequirementsSome specificationSome designToday: specification and designChapters 9, 10, 11 of Hamlet and MaybeeFormal specsTests as specsSpecs vs. designCS427 14-6Use formal specifications (1)To develop models of parts of systemFinite state machines, abstract data typesTo develop model of one aspect of systemData-flow diagram, security, architectureTo learn how to think about problemPre/post conditions, invariantsSet, sequence, mappings (generic ADTs)CS427 14-7Use formal specifications (2)For particular kinds of applicationsCompilersGrammarDenotational semanticsSafety criticalCS427 14-8What you should know about formal methodsChapter 10 of Hamlet and MaybeeBe familiar with the controversyDon’t need to learn PrologCS427 14-9Tests as specificationsFormal specification (entire space)Balance after you add money to an account will be the balance beforehand plus the amount of money you addedTest (one point in the space)Create account with balance of $100Add $20 to accountAccount has balance of $120CS427 14-10Advantages of tests as specsConcrete, easy to understandDon’t need new languageEasy to see if program meets the specsMaking tests forces you to talk to customer and learn the problemMaking tests forces you to think about design of system (classes, methods, etc.)CS427 14-11Disadvantages of tests as specsHard to test that something can’t happenCan’t withdraw more money than you have in the systemCan’t break into the systemCan’t cause a very long transaction that hangs the systemTends to be verboseSampling many points from the spaceCS427 14-12JUnitwww.junit.orgA test is a method whose name starts with “test” in a subclass of TestCaseVersion 4.0 also allows @Tets annotationsCalls methods (defined in TestCase) likeassertEqual(object1, object2)assertTrue(boolean)CS427 14-13Testing 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-14Normal testSet up “test fixture”Call method that is being testedAssert that result is correctCS427 14-15More involved examplepublic void testAddingStudent() { Course c = new Course("Tourism 101"); Student s = new Student("Donald Knuth"); c.addStudent(s); assertEquals(c.students().size(), 1); assertEquals(c.students().elementAt(0), s); }CS427 14-16Tests as specificationsTests show how to use the systemTests need to be readableNeed comments that describe their purposeKeep short, delete duplicationCS427 14-17DesignVerbTo conceive or plan out in the mindTo make a drawing, pattern, or sketch ofCS427 14-18Life-cycleRequirements captureSpecificationDesignImplementationCS427 14-19A good designSatisfies requirementsEasy to implementEasy to understandEasy to changeEasy to check for correctnessIs beautiful (welcome [back] to Software Engineering)CS427 14-20Keep It Simple (S)Einstein: “Everything should be as simple as possible, but no simpler.”Saint-Exupery: “A design is perfect not when there is nothing to add, but when there is nothing to take away.”Gates: “Measuring a program by the number of lines of code is like measuring an airplane by how much it weighs.”CS427 14-21Keep it simpleAvoid duplicationEliminate unnecessary features/codeHide informationNo surprises (follow standards)CS427 14-22Davis Design Principles (1)Don’t reinvent the wheelSearch the web. Read the book. Talk to experts. Exhibit uniformity and integrationMake parts as similar as possibleCoding standardStandard namesCS427 14-23Davis Design Principles (2)Minimize the intellectual distance between the software and the problem as it exists in the real worldUse same names as your customersUse same models as your customersStructure the design to accommodate changeCS427 14-24DavisThe design should be structured to degrade gently, even when aberrant data, events, or operating conditions are encounteredThe design should be assessed for quality as it is being created, not after the factThe design should be reviewed to minimize conceptual errorsCS427 14-25Many things to designCompanySystem that uses programInterface to programInterface of module within programProcedureDatabaseCS427 14-26DesignProcess of eliminating “misfits”Find something wrong and fix itGood design requires being able to spot something that is wrongCS427 14-27What can go wrong?Too complex - can’t understandUsers can’t understandProgrammers can’t understandToo slowWrong featuresToo hard to add new featuresNot compatibleCS427 14-28Too hard to add new
View Full Document