Advanced Topics in Object Technology

Transcription

1 1 Advanced Topics in Object Technology Bertrand Meyer

2 Contact 2 : Course assistant: Karine Arnout

3 3 Lecture 1: Introduction, Quality issues, Lifecycle

4 Agenda for today 4 Introduction Quality issues Lifecycle

5 Agenda for today 5 Introduction Quality issues Lifecycle

6 Introduction 6 Course objectives Topics Technologies Guest lectures Textbook Grading Practical setup

7 Course objectives 7 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 Topics 8 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 Technologies 9 Eiffel.NET

10 Guest lectures (tentative) 10 Philippe Lahire, University of Nice (France): Aspect-Oriented Programming (16 April 2003) ETH assistants Karine Arnout

11 Textbook 11 Bertrand Meyer: Object-Oriented Software Construction, 2 nd edition. Prentice Hall, Available from Ruth Bürkli, RZ-F8 Price: CHF Recommended: Erich Gamma et al.: Design Patterns. Addison- Wesley, 1995.

12 Grading 12 Exam (2h): 40% 2 July 2003 Project: 60% Development of a Pattern Wizard Deadline: 18 June 2003

13 Practical setup 13 Course page: Slides:

14 Practical setup (cont d) 14 Please send an To: Subject: ATOT course participant Content: Your name Preferred 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

15 Practical setup (cont d) 15 If any questions / problems, contact: Karine Arnout Office: RZ-F7 Phone:

16 Before getting started 16 Please fill in the questionnaire: Anonymous! You have 10 minutes

17 Some words of warning 17 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.

18 Some words of warning (cont d) 18 benefit_from_course is -- Make students succeed. require some_humility do all_exercises ensure OO_mastery_for_fun_and_profit end

19 Terminology 19 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)

20 Agenda for today 20 Introduction Quality issues Lifecycle

21 The goal: Software quality 21 REUSABILITY EXTENDIBILITY RELIABILITY (Correctness + Robustness) PORTABILITY EFFICIENCY INTEGRITY SPECIFICATION Correctness Robustness 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.

22 The challenge of software quality 22 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.

23 Agenda for today 23 Introduction Quality issues Lifecycle

24 The waterfall model of the lifecycle 24 FEASIBILITY STUDY REQUIREMENTS ANALYSIS SPECIFICATION GLOBAL DESIGN DETAILED DESIGN IMPLEMENTATION VALIDATION & VERIFICATION PROJECT PROGRESS DISTRIBUTION

25 Arguments for the waterfall 25 (After B.W. Boehm: Software engineering economics) The activities are necessary. (But: merging of middle activities.) The order is the right one.

26 The waterfall model of the lifecycle 26 FEASIBILITY STUDY REQUIREMENTS ANALYSIS SPECIFICATION DESIGN AND IMPLEMENTATION GLOBAL DESIGN DETAILED DESIGN IMPLEMENTATION VALIDATION & VERIFICATION PROJECT TIME DISTRIBUTION

27 Problems with the waterfall 27 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.

28 Quality control? 28 Analysts Designers Implementers Testers Customers

29 Impedance mismatches 29 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)

30 The escherfall (Spiral) 30 M.C Escher: Waterval

31 Tasks 31 Analysts Designers Implementers Testers

32 Seamless development 32 Specification TRANSACTION, PLANE, CUSTOMER, Example classes

33 Seamless development 33 Specification Design TRANSACTION, PLANE, CUSTOMER, STATE, USER_COMMAND, Example classes

34 Seamless development 34 Specification Design Implementation TRANSACTION, PLANE, CUSTOMER, STATE, USER, HASH_TABLE, LINKED_LIST Example classes

35 Seamless development 35 Specification Design Implementation V & V TRANSACTION, PLANE, CUSTOMER, STATE, USER, HASH_TABLE, LINKED_LIST TEST_DRIVER, Example classes

36 Seamless development 36 Specification Design Implementation V & V TRANSACTION, PLANE, CUSTOMER, STATE, USER, HASH_TABLE, LINKED_LIST TEST_DRIVER, Generalization Example classes

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

38 Reversibility 38 Specification Design Implementation V & V Generalization

39 Seamless development 39 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 Single model principle 40 Use a single base for everything: analysis, design, implementation, documentation... Use tools to extract the appropriate views.

41 The cluster model 41 Feasibility study Division into clusters Cluster 1 Specification Design Implementation Cluster 2 Specification V & V Generalization Design Implementation V & V Generalization Cluster n Specification Design Implementation V & V Generalization PROJECT TIME

42 The cluster model: extreme variants (1) 42 Feasibility study Division into clusters Cluster 1 Cluster 2 Cluster 3 Cluster 4 Cluster 5 Specification Specification Specification Specification Specification Design Design Design Design Design Implementation Implementation Implementation Implementation Implementation V & V V & V V & V V & V V & V Generalization Generalization Generalization Generalization Generalization Clusterfall

43 The cluster model: extreme variants (2) 43 Feasibility study Division into clusters Cluster 1 Cluster 2 Cluster n The Trickle model

44 Quality goals: the Osmond curves 44 Other qualities DESIRABLE Debugging COMMON Functionality Envisaged Early releases

45 Cluster development 45 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.

46 Reading assignment 46 For Monday 7 April 2003: OOSC2 chapters Chapter 1: Software quality Chapter 28: The software construction process

47 47 End of lecture 1