1. Slide 1.1 © The McGraw-Hill Companies, 2002 Object-Oriented and Classical Software Engineering Fifth Edition, WCB/McGraw-Hill, 2002 Stephen R. Schach srs@vuse.vanderbilt.edu

2. Slide 1.2 © The McGraw-Hill Companies, 2002 CHAPTER 1 SCOPE OF SOFTWARE ENGINEERING

3. Slide 1.3 © The McGraw-Hill Companies, 2002 Outline l Historical aspects l Economic aspects l Maintenance aspects l Specification and design aspects l Team programming aspects l The object-oriented paradigm l Terminology

4. Slide 1.4 © The McGraw-Hill Companies, 2002 Scope of Software Engineering l Historical Aspects –1968 NATO Conference, Garmisch –Aim: to solve the “Software Crisis” –Software is delivered »Late »Over budget »With residual faults

5. Slide 1.5 © The McGraw-Hill Companies, 2002 Scope of Software Engineering (contd) l Why cannot bridge-building techniques be used to build operating systems? –Attitude to collapse –Imperfect engineering –Complexity –Maintenance

6. Slide 1.6 © The McGraw-Hill Companies, 2002 Conclusion l Software Engineering is not “Engineering”

7. Slide 1.7 © The McGraw-Hill Companies, 2002 Economic Aspects l Economically viable techniques l Coding method CM new is 10% faster than currently used method CM old. Should it be used? –Common sense answer »Of course! –Software Engineering answer »Consider the effect of CM new on maintenance

8. Slide 1.8 © The McGraw-Hill Companies, 2002 Maintenance Aspects l Software Life Cycle –The way we produce software, including »The life-cycle model »The individuals »CASE tools

9. Slide 1.9 © The McGraw-Hill Companies, 2002 Life-cycle model 1.Requirements phase 2.Specification phase 3.Design phase 4.Implementation phase 5.Integration phase (in parallel with 4) 6.Maintenance phase 7.Retirement

10. Slide 1.10 © The McGraw-Hill Companies, 2002 Approximate Relative Cost of Each Phase l 1976–1981 data l Maintenance constitutes 67% of total cost

11. Slide 1.11 © The McGraw-Hill Companies, 2002 Comparative Relative Cost of Each Phase

12. Slide 1.12 © The McGraw-Hill Companies, 2002 Good and Bad Software l Good software is maintained—bad software is discarded l Different types of maintenance –Corrective maintenance [about 20%] –Enhancement »Perfective maintenance [about 60%] »Adaptive maintenance [about 20%] l Effect of CM new on maintenance

13. Slide 1.13 © The McGraw-Hill Companies, 2002 Specification and Maintenance Faults l 60 to 70 percent of faults are specification and design faults l Data of Kelly, Sherif, and Hops [1992] –1.9 faults per page of specification –0.9 faults per page of design –0.3 faults per page of code l Data of Bhandari et al. [1994]

14. Slide 1.14 © The McGraw-Hill Companies, 2002 Specification and Maintenance Faults (contd) l Faults at end of the design phase of the new version of the product –13% of faults from previous version of product –16% of faults in new specifications –71% of faults in new design

15. Slide 1.15 © The McGraw-Hill Companies, 2002 Cost to Detect and Correct a Fault

16. Slide 1.16 © The McGraw-Hill Companies, 2002 Team Programming Aspects l Hardware is cheap –We can build products that are too large to be written by one person in the available time l Teams –Interface problems –Meetings

17. Slide 1.17 © The McGraw-Hill Companies, 2002 The Object-Oriented Paradigm l The structured paradigm had great successes initially –It started to fail with larger products (> 50,000 LOC) l Maintenance problems (today, up to 80% of effort) l Reason: structured methods are –Action oriented (finite state machines, data flow diagrams); or –Data oriented (entity-relationship diagrams, Jackson’s method); –But not both

18. Slide 1.18 © The McGraw-Hill Companies, 2002 The Object-Oriented Paradigm (contd) l Both data and actions are of equal importance l Object: –Software component that incorporates both data and the actions that are performed on that data l Example: –Bank account »Data: account balance »Actions: deposit, withdraw, determine balance

19. Slide 1.19 © The McGraw-Hill Companies, 2002 Structured versus Object-Oriented Paradigm l Information hiding l Responsibility-driven design l Impact on maintenance, development

20. Slide 1.20 © The McGraw-Hill Companies, 2002 Key Aspects of Object-Oriented Solution l Conceptual independence –Encapsulation l Physical independence –Information hiding l Impact on development –Physical counterpart l Impact on maintenance –Independence effects

21. Slide 1.21 © The McGraw-Hill Companies, 2002 Responsibility-Driven Design l Also called “Design by Contract” l Send flowers to your aunt in Iowa City –Call 1-800-FLOWERS –Where is 1-800-FLOWERS? –Which Iowa City florist does the delivery? –Information hiding l Object-oriented paradigm –“Send a message to a method [action] of an object“

22. Slide 1.22 © The McGraw-Hill Companies, 2002 Transition From Analysis to Design l Structured paradigm: –Jolt between analysis (what) and design (how) l Object-oriented paradigm: –Objects enter from very beginning

23. Slide 1.23 © The McGraw-Hill Companies, 2002 Analysis/Design “Hump” l Systems analysis –Determine what has to be done l Design –Determine how to do it –Architectural design—determine modules –Detailed design—design each module

24. Slide 1.24 © The McGraw-Hill Companies, 2002 Removing the “Hump” l Object-oriented analysis –Determine what has to be done –Determine the objects l Object-oriented design –Determine how to do it –Design the objects

25. Slide 1.25 © The McGraw-Hill Companies, 2002 In More Detail l Objects enter here

26. Slide 1.26 © The McGraw-Hill Companies, 2002 Warning l Do not use the object-paradigm to enhance a product developed using the structured paradigm –Water and oil do not mix l Exception: if the new part is totally disjoint –Example: adding a GUI (graphical user interface)

27. Slide 1.27 © The McGraw-Hill Companies, 2002 Terminology l Quality l Program, system, product l Methodology, paradigm l Method and technique l Client, developer, user Bug  –“A bug  crept into the code” instead of –“I made a mistake”

28. Slide 1.28 © The McGraw-Hill Companies, 2002 Object-Oriented Terminology l Data component of an object –State variable –Instance variable (Java) –Field (C++) –Attribute (generic) l Action component of an object –Member function (C++) –Method (generic)

29. Slide 1.29 © The McGraw-Hill Companies, 2002 Object-Oriented Terminology (contd) l C++: A member is either an –Attribute (“field”), or a –Method (“member function”) l Java: A field is either an –Attribute (“instance variable”), or a –Method