1. Chair of Software Engineering OOSC - Summer Semester 2004 1 Object-Oriented Software Construction Bertrand Meyer

2. Chair of Software Engineering OOSC - Summer Semester 2004 2 Contact  Chair of Software Engineering:  http://se.inf.ethz.ch http://se.inf.ethz.ch  Course assistant:  Joseph N. Ruskiewicz  http://se.inf.ethz.ch/people/ruskiewicz http://se.inf.ethz.ch/people/r

3. Chair of Software Engineering OOSC - Summer Semester 2004 3 Lecture 1: Introduction, Quality issues, Lifecycle

4. Chair of Software Engineering OOSC - Summer Semester 2004 4 Agenda for today  Introduction  Quality issues  Lifecycle

5. Chair of Software Engineering OOSC - Summer Semester 2004 5 Agenda for today  Introduction  Quality issues  Lifecycle

6. Chair of Software Engineering OOSC - Summer Semester 2004 6 Introduction  Course objectives  Topics  Technologies  Guest lectures  Textbook  Grading  Practical setup

7. Chair of Software Engineering OOSC - Summer Semester 2004 7 Course objectives  Provide you with solid knowledge of:  Object technology principles and methods  The practice of object-oriented analysis, design and implementation  Some open issues  Some recent developments  Two specific technologies

8. Chair of Software Engineering OOSC - Summer Semester 2004 8 Topics  Quality issues  Lifecycle  Abstract Data Types  Object model choices  Inheritance techniques  Design patterns  Concurrent object-oriented computation  Language mechanisms  Persistence and O-O database  Project management  Genericity, typing issues, covariance  …

9. Chair of Software Engineering OOSC - Summer Semester 2004 9 Technologies  Eiffel .NET

10. Chair of Software Engineering OOSC - Summer Semester 2004 10 Textbook  Bertrand Meyer: Object-Oriented Software Construction, 2 nd edition. Prentice Hall, 1997.  Available from Ruth Bürkli, RZ-F8  Price: CHF 81.00  Recommended:  Erich Gamma et al.: Design Patterns. Addison- Wesley, 1995.

11. Chair of Software Engineering OOSC - Summer Semester 2004 11 Grading  Exam (2h): 40%  28 June 2004  Project: 60%  Development of an “Object-Oriented Requirements Annotator”  Deadline: 30 June 2004

12. Chair of Software Engineering OOSC - Summer Semester 2004 12 Practical setup  Course page:  http://se.inf.ethz.ch/teaching/ss2004/0250/ http://se.inf.ethz.ch/teaching/ss2004/0  Slides:  http://se.inf.ethz.ch/teaching/ss2004/0250/index.html#slides http://se.inf.ethz.ch/teaching/ss2004/0250/index.html#slides

13. Chair of Software Engineering OOSC - Summer Semester 2004 13 Practical setup (cont’d)  Please send an email:  To: oosc-course@se.inf.ethz.choosc-course@se.inf.ethz.ch  Subject: OOSC course participant  Content:  Your name  Preferred email address  Status  Diplom student (semester), Ph.D. student, other.  Taking the course for credit or not.  Attach a picture (JPEG, GIF, PNG) if you wish

14. Chair of Software Engineering OOSC - Summer Semester 2004 14 Practical setup (cont’d)  If any questions / problems, contact:  Joseph N. Ruskiewicz  http://se.inf.ethz.ch/people/ruskiewicz  Office: RZ-J22  Phone: 01 632 67 61

15. Chair of Software Engineering OOSC - Summer Semester 2004 15 Before getting started…  Please fill in the questionnaire:  Anonymous!  You have 10 minutes

16. Chair of Software Engineering OOSC - Summer Semester 2004 16 Some words of warning  Steps in reacting to O-O (from the preface to Object-Oriented Software Construction):  “(1) It’s trivial;  (2) It’s wrong;  (3) That’s how I did it all along anyway.”  Beware of the “mOOzak” phenomenon.

17. Chair of Software Engineering OOSC - Summer Semester 2004 17 Some words of warning (cont’d) benefit_from_course is -- Make students succeed. require some_humility do all_exercises ensure OO_mastery_for_fun_and_profit end

18. Chair of Software Engineering OOSC - Summer Semester 2004 18 Terminology  I will be strict about terminology:  Endless confusions in the literature and in discussions.  Basic concepts have precise definitions — no justification whatsoever for such confusions.  Object technology is (in part) about bringing rational, scientific principles to software. No excuse for sloppy terminology.  Alternative conventions will be mentioned when necessary.  CHF 5 fine for saying “object” when meaning “class” (after lecture 4)

19. Chair of Software Engineering OOSC - Summer Semester 2004 19 Agenda for today  Introduction  Quality issues  Lifecycle

20. Chair of Software Engineering OOSC - Summer Semester 2004 20 The goal: Software quality  REUSABILITY  EXTENDIBILITY  RELIABILITY  Correctness  Robustness  Integrity  PORTABILITY  EFFICIENCY  …  Correctness:  The ability of a software system to perform according to specification, in cases defined by the specification.  Robustness:  The ability of a software system to react in a reasonable manner to cases not covered by the specification.  Integrity:  The ability of a software system to react in a reasonable manner to cases of unauthorized access and modification. Robustness SPECIFICATION Correctness Integrity

21. Chair of Software Engineering OOSC - Summer Semester 2004 21 The challenge of software quality  Reliability [correctness + robustness]:  It should be easier to build software that functions properly, and easier to guarantee what it does.  Modularity [reusability + extendibility]:  We should build less software!  Software should be easier to modify.

22. Chair of Software Engineering OOSC - Summer Semester 2004 22 Agenda for today  Introduction  Quality issues  Lifecycle

23. Chair of Software Engineering OOSC - Summer Semester 2004 23 The waterfall model of the lifecycle FEASIBILITY STUDY REQUIREMENTS ANALYSIS SPECIFICATION GLOBAL DESIGN DETAILED DESIGN IMPLEMENTATION DISTRIBUTION VALIDATION & VERIFICATION PROJECT PROGRESS

24. Chair of Software Engineering OOSC - Summer Semester 2004 24 Arguments for the waterfall (After B.W. Boehm: Software engineering economics)  The activities are necessary.  (But: merging of middle activities.)  The order is the right one.

25. Chair of Software Engineering OOSC - Summer Semester 2004 25 The waterfall model of the lifecycle FEASIBILITY STUDY REQUIREMENTS ANALYSIS SPECIFICATION GLOBAL DESIGN DETAILED DESIGN IMPLEMENTATION DISTRIBUTION VALIDATION & VERIFICATION PROJECT TIME DESIGN AND IMPLEMENTATION

26. Chair of Software Engineering OOSC - Summer Semester 2004 26 Problems with the waterfall  Late appearance of actual code.  Lack of support for requirements change — and more generally for extendibility and reusability.  Lack of support for the maintenance activity (70% of software costs?).  Division of labor hampering Total Quality Management.  Impedance mismatches.  Highly synchronous model.

27. Chair of Software Engineering OOSC - Summer Semester 2004 27 Quality control? Analysts Designers Implementers Testers Customers

28. Chair of Software Engineering OOSC - Summer Semester 2004 28 Impedance mismatches As Management requested it.As the Project Leader defined it.As Systems designed it. As Programming developed it.As Operations installed it.What the user wanted. (Pre-1970 cartoon; origin unknown)

29. Chair of Software Engineering OOSC - Summer Semester 2004 29 The escherfall (Spiral) M.C Escher: Waterval

30. Chair of Software Engineering OOSC - Summer Semester 2004 30 Tasks Analysts Designers Implementers Testers

31. Chair of Software Engineering OOSC - Summer Semester 2004 31 Seamless development (1) TRANSACTION, PLANE, CUSTOMER, ENGINE... Example classes Specification

32. Chair of Software Engineering OOSC - Summer Semester 2004 32 Seamless development (2) TRANSACTION, PLANE, CUSTOMER, ENGINE... Example classes Design Specification STATE, USER_COMMAND...

33. Chair of Software Engineering OOSC - Summer Semester 2004 33 Seamless development (3) Implementation TRANSACTION, PLANE, CUSTOMER, ENGINE... Example classes Design Specification STATE, USER_COMMAND... HASH_TABLE, LINKED_LIST...

34. Chair of Software Engineering OOSC - Summer Semester 2004 34 Seamless development (4) Implementation V & V TRANSACTION, PLANE, CUSTOMER, ENGINE... TEST_DRIVER,... Example classes Design Specification STATE, USER_COMMAND... HASH_TABLE, LINKED_LIST...

35. Chair of Software Engineering OOSC - Summer Semester 2004 35 Seamless development (5) Implementation V & V TRANSACTION, PLANE, CUSTOMER, ENGINE... TEST_DRIVER,... Example classes Design Specification STATE, USER_COMMAND... HASH_TABLE, LINKED_LIST... Genera- lization AIRCRAFT,...

36. Chair of Software Engineering OOSC - Summer Semester 2004 36 deferred class VAT inherit TANK feature in_valve, out_valve: VALVE fill is -- Fill the vat. require in_valve.open out_valve.closed deferred ensure in_valve.closed out_valve.closed is_full end empty, is_full, is_empty, gauge, maximum,... [Other features]... invariant is_full = (gauge >= 0.97 * maximum) and (gauge <= 1.03 * maximum) end Analysis classes Precondition Class invariant -- i.e. specified only. -- not implemented. Postcondition

37. Chair of Software Engineering OOSC - Summer Semester 2004 37 At the source of object technology Kristen Nygaard (Oslo, 1967) To program is to understand

38. Chair of Software Engineering OOSC - Summer Semester 2004 38 Reversibility

39. Chair of Software Engineering OOSC - Summer Semester 2004 39 Seamless development  Use consistent notation from analysis to design, implementation and maintenance.  Advantages:  Smooth process. Avoids gaps (improves productivity, reliability).  Direct mapping from problem to solution, i.e. from software system to external model.  Better responsiveness to customer requests.  Consistency, ease of communication.  Better interaction between users, managers and developers.

40. Chair of Software Engineering OOSC - Summer Semester 2004 40 Single model principle  Use a single base for everything: analysis, design, implementation, documentation...  Use tools to extract the appropriate views.

41. Chair of Software Engineering OOSC - Summer Semester 2004 41 Generalization  Prepare for reuse  For example:  Remove built-in limits  Remove dependencies on specifics of project  Improve documentation, contracts...  Extract commonalities and revamp inheritance hierarchy  Few companies have the guts to provide the budget for this

42. Chair of Software Engineering OOSC - Summer Semester 2004 42 The cluster model I V D S G I V D S G I V D S G Cluster 1 Cluster 2 I V D S G Cluster n I V D S G I V D S G

43. Chair of Software Engineering OOSC - Summer Semester 2004 43 The cluster model: extreme variants (1) Feasibility study Division into clusters Specification Design Implementation V & V Generalization Specification Design Implementation V & V Generalization Specification Cluster 2Cluster 3 Specification Design Implementation V & V Generalization Specification Cluster 1 Specification Design Implementation V & V Generalization Specification Cluster 4 Specification Design Implementation V & V Generalization Specification Cluster 5 “ Clusterfall”

44. Chair of Software Engineering OOSC - Summer Semester 2004 44 The cluster model: extreme variants (2) Feasibility study Division into clusters Cluster 1 Cluster 2 Cluster n The Trickle model

45. Chair of Software Engineering OOSC - Summer Semester 2004 45 Quality goals: the Osmond curves DESIRABLE COMMON Functionality Other qualities Debugging Envisaged Early releases

46. Chair of Software Engineering OOSC - Summer Semester 2004 46 Cluster development  Bottom-up development: from the most general clusters (providing utility functions) to the most application-specific ones.  Flexible scheduling of clusters – depending on resources, team experience, customer and management demands. Waterfall is one extreme; “trickle” is the other.  Sub-lifecycle sequencing: specification, design and implementation, validation, generalization.  Relations between clusters: each cluster may be a client of lower-level ones.

47. Chair of Software Engineering OOSC - Summer Semester 2004 47 Reading assignment  For Monday 5 April 2004: OOSC2 chapters  Chapter 1: Software quality  Chapter 28: The software construction process

48. Chair of Software Engineering OOSC - Summer Semester 2004 48 End of lecture 1