Presentation is loading. Please wait.

Presentation is loading. Please wait.

1 CS427: Software Engineering I Darko Marinov (slides from Ralph Johnson)

Similar presentations

Presentation on theme: "1 CS427: Software Engineering I Darko Marinov (slides from Ralph Johnson)"— Presentation transcript:

1 1 CS427: Software Engineering I Darko Marinov (slides from Ralph Johnson)

2 CS42714-2 Midterm exam zYou can get graded exams from TAs yFeel free to ask if you think we made mistake zGrades almost normally distributed

3 CS42714-3 Comment on midterm exam zCOCOMO question is picking details from the reading; is it really like that? zOne correct answer, using formula E ~ size P yThis is not exponential, not E ~ P size zAnother correct answer, common sense yE(200KLOC) = 2*E(100KLOC) + E(integration) zCommon sense can lead to incorrect answers yE(200KLOC) ≤ 2*E(100KLOC)

4 CS42714-4 Project info zGroups formed (any volunteers for 10?) zGrading: You are graded on how well you follow your process (you decide XP or RUP) yYou must know it yYou must follow it yYou must prove you follow it xMake a log of what you do every day zHW2 is due next Tuesday, Oct 24 yUse cases and UML diagrams for your project

5 CS42714-5 Topics zCovered yRequirements ySome specification ySome design zToday: specification and design yChapters 9, 10, 11 of Hamlet and Maybee yFormal specs yTests as specs ySpecs vs. design

6 CS42714-6 Use formal specifications (1) zTo develop models of parts of system yFinite state machines, abstract data types zTo develop model of one aspect of system yData-flow diagram, security, architecture zTo learn how to think about problem yPre/post conditions, invariants ySet, sequence, mappings (generic ADTs)

7 CS42714-7 Use formal specifications (2) zFor particular kinds of applications yCompilers xGrammar xDenotational semantics ySafety critical

8 CS42714-8 What you should know about formal methods zChapter 10 of Hamlet and Maybee zBe familiar with the controversy zDon’t need to learn Prolog

9 CS42714-9 Tests as specifications zFormal specification (entire space) yBalance after you add money to an account will be the balance beforehand plus the amount of money you added zTest (one point in the space) yCreate account with balance of $100 yAdd $20 to account yAccount has balance of $120

10 CS42714-10 Advantages of tests as specs zConcrete, easy to understand zDon’t need new language zEasy to see if program meets the specs zMaking tests forces you to talk to customer and learn the problem zMaking tests forces you to think about design of system (classes, methods, etc.)

11 CS42714-11 Disadvantages of tests as specs zHard to test that something can’t happen yCan’t withdraw more money than you have in the system yCan’t break into the system yCan’t cause a very long transaction that hangs the system zTends to be verbose ySampling many points from the space

12 CS42714-12 JUnit zA test is a method whose name starts with “test” in a subclass of TestCase yVersion 4.0 also allows @Tets annotations zCalls methods (defined in TestCase) like yassertEqual(object1, object2) yassertTrue(boolean)

13 CS42714-13 Testing Student and Course public void testStudentCreation() { Student s = new Student("Marvin Minsky"); assertTrue(s.getName().equals("Marvin Minsky")); } or public void testStudentCreation() { Student s = new Student("Marvin Minsky"); assertEqual(s.getName(), "Marvin Minsky"); }

14 CS42714-14 Normal test zSet up “test fixture” zCall method that is being tested zAssert that result is correct

15 CS42714-15 More involved example public 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); }

16 CS42714-16 Tests as specifications zTests show how to use the system zTests need to be readable yNeed comments that describe their purpose yKeep short, delete duplication

17 CS42714-17 Design Verb zTo conceive or plan out in the mind zTo make a drawing, pattern, or sketch of

18 CS42714-18 Life-cycle zRequirements capture zSpecification zDesign zImplementation

19 CS42714-19 A good design zSatisfies requirements zEasy to implement zEasy to understand zEasy to change zEasy to check for correctness zIs beautiful (welcome [back] to Software Engineering)

20 CS42714-20 Keep It Simple (S) zEinstein: “Everything should be as simple as possible, but no simpler.” zSaint-Exupery: “A design is perfect not when there is nothing to add, but when there is nothing to take away.” zGates: “Measuring a program by the number of lines of code is like measuring an airplane by how much it weighs.”

21 CS42714-21 Keep it simple zAvoid duplication zEliminate unnecessary features/code zHide information zNo surprises (follow standards)

22 CS42714-22 Davis Design Principles (1) zDon’t reinvent the wheel ySearch the web. Read the book. Talk to experts. zExhibit uniformity and integration yMake parts as similar as possible xCoding standard xStandard names

23 CS42714-23 Davis Design Principles (2) zMinimize the intellectual distance between the software and the problem as it exists in the real world yUse same names as your customers yUse same models as your customers zStructure the design to accommodate change

24 CS42714-24 Davis zThe design should be structured to degrade gently, even when aberrant data, events, or operating conditions are encountered zThe design should be assessed for quality as it is being created, not after the fact zThe design should be reviewed to minimize conceptual errors

25 CS42714-25 Many things to design zCompany zSystem that uses program zInterface to program zInterface of module within program zProcedure zDatabase

26 CS42714-26 Design zProcess of eliminating “misfits” zFind something wrong and fix it zGood design requires being able to spot something that is wrong

27 CS42714-27 What can go wrong? zToo complex - can’t understand yUsers can’t understand yProgrammers can’t understand zToo slow zWrong features zToo hard to add new features zNot compatible

28 CS42714-28 Too hard to add new features zUsually because problem is decomposed improperly zDesign decisions should be hidden zOnly one module should know about design decision zChanging that decision requires changing only one module

29 CS42714-29 Separate user interface zSeparate user interface from program logic zUI changes frequently zIt is easier to change UI if it is separate zUI experts can be non-programmers zCan provide several UIs for one system

30 CS42714-30 Automated tests zUI hard to test zSeparate UI from program logic and write automated tests for program logic zUI first? yNo, design program logic first and write tests for it zDatabase first? yNo, design program logic first and write tests for it. Then design database and rewrite to use it

31 CS42714-31 Summary zFuzzy boundaries between yAnalysis and design yDesign and implementation zDesign is problem solving zIt helps to know a lot of solutions

32 CS42714-32 Project advice repeated zYou are graded on how well you follow your process. yYou must know it. yYou must follow it. yYou must prove you follow it. zMake a log of what you do every day.

33 CS42714-33 Next time zRead chapters 13 and 14 of Hamlet and Maybee

Download ppt "1 CS427: Software Engineering I Darko Marinov (slides from Ralph Johnson)"

Similar presentations

Ads by Google