Object-Oriented Software Construction

Transcription

1 1 Object-Oriented Software Construction Bertrand Meyer

2 Contact 2 Chair of Software Engineering: Course assistant: Joseph N. Ruskiewicz

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 Textbook 10 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.

11 Grading 11 Exam (2h): 40% 28 June 2004 Project: 60% Development of an Object-Oriented Requirements Annotator Deadline: 30 June 2004

12 Practical setup 12 Course page: Slides:

13 Practical setup (cont d) 13 Please send an To: Subject: OOSC 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

14 Practical setup (cont d) 14 If any questions / problems, contact: Joseph N. Ruskiewicz Office: RZ-J22 Phone:

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

16 Some words of warning 16 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 Some words of warning (cont d) 17 benefit_from_course is -- Make students succeed. require some_humility do all_exercises ensure OO_mastery_for_fun_and_profit end

18 Terminology 18 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 Agenda for today 19 Introduction Quality issues Lifecycle

20 The goal: Software quality 20 REUSABILITY EXTENDIBILITY RELIABILITY Correctness Robustness Integrity PORTABILITY EFFICIENCY SPECIFICATION Correctness Robustness Integrity 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.

21 The challenge of software quality 21 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 Agenda for today 22 Introduction Quality issues Lifecycle

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

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

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

26 Problems with the waterfall 26 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 Quality control? 27 Analysts Designers Implementers Testers Customers

28 Impedance mismatches 28 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 The escherfall (Spiral) 29 M.C Escher: Waterval

30 Tasks 30 Analysts Designers Implementers Testers

31 Seamless development (1) 31 Specification TRANSACTION, PLANE, CUSTOMER, ENGINE... Example classes

32 Seamless development (2) 32 Specification Design TRANSACTION, PLANE, CUSTOMER, ENGINE... STATE, USER_COMMAND... Example classes

33 Seamless development (3) 33 Specification Design Implementation TRANSACTION, PLANE, CUSTOMER, ENGINE... STATE, USER_COMMAND... HASH_TABLE, LINKED_LIST... Example classes

34 Seamless development (4) 34 Specification Design Implementation V & V TRANSACTION, PLANE, CUSTOMER, ENGINE... STATE, USER_COMMAND... HASH_TABLE, LINKED_LIST... TEST_DRIVER,... Example classes

35 Seamless development (5) Specification Design TRANSACTION, PLANE, CUSTOMER, ENGINE... STATE, USER_COMMAND... Implementation HASH_TABLE, LINKED_LIST... V&V TEST_DRIVER,... Generalization AIRCRAFT,... Example classes 35

36 Analysis classes 36 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

37 At the source of object technology 37 Kristen Nygaard (Oslo, 1967) To program is to understand

38 Reversibility 38 S D I V G

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 Generalization 41 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 The cluster model S 42 Cluster 1 Cluster 2 D I V G S D I V G Cluster n S S D D I I V V G G

43 The cluster model: extreme variants (1) 43 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

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

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

46 Cluster development 46 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 Reading assignment 47 For Monday 5 April 2004: OOSC2 chapters Chapter 1: Software quality Chapter 28: The software construction process

48 48 End of lecture 1