1. Slide 1.1 © Center for Research in Electronic Commerce, Xiamen University, 2004 Object-Oriented and Classical Software Engineering Fifth Edition, McGraw-Hill, 2002

2. Slide 1.2 © Center for Research in Electronic Commerce, Xiamen University, 2004 CHAPTER 1 SCOPE OF SOFTWARE ENGINEERING

3. Slide 1.3 © Center for Research in Electronic Commerce, Xiamen University, 2004 JUST IN CASE YOU WANTED TO KNOW A well-known story tells of an executive who received a computer-generated bill for $0.00. After having a good laugh with friends about “idiot computers,” the executive tossed the bill away.A month later a similar bill arrived, this time marked 30 days. Then came the third bill. The fourth bill arrived a month later, accompanied by a message hinting at possible legal action if the bill for $0.00 was not paid at once. T he fifth bill, marked 120 days, did not hint at anything—the message was rude and forthright, threatening all manner of legal actions if the bill was not immediately paid. F earful of his organization’s credit rating in the hands of this maniacal machine, the executive called an acquaintance who was a software engineer and related the whole sorry story. T rying not to laugh, the software engineer told the executive to mail a check for $0.00. This had the desired effect, and a receipt for $0.00 was received a few days later. The executive carefully filed it away in case at some future date the computer might allege that $0.00 was still owing.

4. Slide 1.4 © Center for Research in Electronic Commerce, Xiamen University, 2004 JUST IN CASE YOU WANTED TO KNOW During the 1991 Gulf War, a Scud missile penetrated the Patriot antimissile shield and struck a barracks near Dhahran, Saudi Arabia. In all, 28 Americans were killed and 98 wounded. The software for the Patriot missile contained a cumulative timing fault. The Patriot was designed to operate for only a few hours at a time, after which the clock was reset. As a result, the fault never had a significant effect and therefore was not detected. In the GulfWar, however, the Patriot missile battery at Dhahran ran continuously for over 100 hours. This caused the accumulated time discrepancy to become large enough to render the system inaccurate. During the GulfWar, the United States shipped Patriot missiles to Israel for protection against the Scuds. Israeli forces detected the timing problem after only 8 hours and immediately reported it to the manufacturer in the United States. The manufacturer corrected the fault as quickly as it could but, the new software arrived the day after the direct hit by the Scud.

5. Slide 1.5 © Center for Research in Electronic Commerce, Xiamen University, 2004 What is software engineering Whether we are dealing with billing or air defense, much of our software is delivered late, over budget, and with residual faults. Software engineering is an attempt to solve these problems. In other words, software engineering is a discipline whose aim is the production of fault-free software, delivered on time and within budget, that satisfies the user’s needs. Furthermore, the software must be easy to modify when the user’s needs change. To achieve these goals, a software engineer has to acquire a broad range of skills, both technical and managerial. These skills have to be applied not just to programming but to every phase of software production, from requirements to maintenance.

6. Slide 1.6 © Center for Research in Electronic Commerce, Xiamen University, 2004 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

7. Slide 1.7 © Center for Research in Electronic Commerce, Xiamen University, 2004 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

8. Slide 1.8 © Center for Research in Electronic Commerce, Xiamen University, 2004 Scope of Software Engineering (contd) l Why cannot bridge-building techniques be used to build operating systems? –Attitude to collapse –Imperfect engineering –Complexity –Maintenance

9. Slide 1.9 © Center for Research in Electronic Commerce, Xiamen University, 2004 Conclusion l Software Engineering is not “Engineering”

10. Slide 1.10 © Center for Research in Electronic Commerce, Xiamen University, 2004 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

11. Slide 1.11 © Center for Research in Electronic Commerce, Xiamen University, 2004 Maintenance Aspects l Software Life Cycle –The way we produce software, including »The life-cycle model »The individuals »CASE tools

12. Slide 1.12 © Center for Research in Electronic Commerce, Xiamen University, 2004 Life-cycle model 1.Requirements phase ： 2.Specification phase ： what to do? 3.Design phase: how to do? 4.Implementation phase: Programming and testing 5.Integration phase (in parallel with 4) 6.Maintenance phase: error correction and software enhancement 7.Retirement

13. Slide 1.13 © Center for Research in Electronic Commerce, Xiamen University, 2004 Approximate Relative Cost of Each Phase l 1976–1981 data l Maintenance constitutes 67% of total cost

14. Slide 1.14 © Center for Research in Electronic Commerce, Xiamen University, 2004 Comparative Relative Cost of Each Phase

15. Slide 1.15 © Center for Research in Electronic Commerce, Xiamen University, 2004 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 –If maintenance cost is reduced about 10%,then total cost is reduced about 6~7%

16. Slide 1.16 © Center for Research in Electronic Commerce, Xiamen University, 2004 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

17. Slide 1.17 © Center for Research in Electronic Commerce, Xiamen University, 2004 Specification and Maintenance Faults (contd) l Data of Bhandari et al. [1994] ， 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

18. Slide 1.18 © Center for Research in Electronic Commerce, Xiamen University, 2004 Cost to Detect and Correct a Fault

19. Slide 1.19 © Center for Research in Electronic Commerce, Xiamen University, 2004 Q&A 1. 用于确立内燃机中所用油料最佳粘度的软件产品，在 交付产品 15 个月后发现一个问题。纠正这个错误的花 费大约 18730 美元。规格设计文档中的一个模糊语句 导致这个错误。估计一下，在规格设计阶段纠正该错 误要花费多少钱？ 2. 假设错误在实现阶段发现，纠正该错误需要花费多少 钱？ 3. 如何理解在需求阶段和规格说明阶段发现存在的错误 的重要性。在产品还没有生产之前就开始纠正错误， 是不是不近合理？

20. Slide 1.20 © Center for Research in Electronic Commerce, Xiamen University, 2004 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

21. Slide 1.21 © Center for Research in Electronic Commerce, Xiamen University, 2004 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

22. Slide 1.22 © Center for Research in Electronic Commerce, Xiamen University, 2004 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

23. Slide 1.23 © Center for Research in Electronic Commerce, Xiamen University, 2004 Structured versus Object-Oriented Paradigm l Information hiding l Responsibility-driven design l Impact on maintenance, development

24. Slide 1.24 © Center for Research in Electronic Commerce, Xiamen University, 2004 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

25. Slide 1.25 © Center for Research in Electronic Commerce, Xiamen University, 2004 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“

26. Slide 1.26 © Center for Research in Electronic Commerce, Xiamen University, 2004 Transition From Analysis to Design l Structured paradigm: –Jolt between analysis (what) and design (how) l Object-oriented paradigm: –Objects enter from very beginning

27. Slide 1.27 © Center for Research in Electronic Commerce, Xiamen University, 2004 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

28. Slide 1.28 © Center for Research in Electronic Commerce, Xiamen University, 2004 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

29. Slide 1.29 © Center for Research in Electronic Commerce, Xiamen University, 2004 In More Detail l Objects enter here

30. Slide 1.30 © Center for Research in Electronic Commerce, Xiamen University, 2004 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)

31. Slide 1.31 © Center for Research in Electronic Commerce, Xiamen University, 2004 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”

32. Slide 1.32 © Center for Research in Electronic Commerce, Xiamen University, 2004 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)

33. Slide 1.33 © Center for Research in Electronic Commerce, Xiamen University, 2004 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

34. Slide 1.34 © Center for Research in Electronic Commerce, Xiamen University, 2004 Q A &