Welcome to CIS 068 !

1. Welcome to CIS 068 ! Lesson 2: Software Engineering or Why not only code it ? CIS 068

2. CIS 068

3. Why not only code it ? • Which event happens more frequently ? • Which is deadlier ? CIS 068

4. Why not only code it ? • Famous Software Failures • Therac-25 (1985-1987) • Six people were overexposed during radiation treatments for cancer by Canada's Therac-25 radiation therapy machine.  Three patients believed to have died from the overdoses.  • London Ambulance System (1992) • A succession of software engineering failures, especially in project management, caused 2 failures of London's (England) Ambulance dispatch system.  The repair cost was estimated at £9m, but it is believed that people died who would not have died if ambulances had reached them as promptly as they would have done without the failures. • AT&T long distance service fails for nine hours(Wrong BREAK statement in C-Code, 1990) • Shooting Down of Airbus 320 (1988) • US Vicennes shot down Airbus 320 mistaken for an F-14, 290 people dead. • Software bug: cryptic and misleading output displayed by the tracking software CIS 068

5. Why not only code it ? • Famous Software Failures cont’d: • Mars Climate Orbiter (September 23rd, 1999) • The 125 million dollar Mars Climate Orbiter is assumed lost by officials at NASA. The failure responsible for loss of the orbiter is attributed to a failure of NASA’s system engineer process. The process did not specify the system of measurement to be used on the project. As a result, one of the development teams used Imperial measurement while the other used the metric system of measurement. When parameters from one module were passed to another during orbit navigation correct, no conversion was performed, resulting in the loss of the craft. • Hi-tech toilet swallows woman (2001) • [Source: Article by Lester Haines, 17 Apr 2001] A 51-year-old woman was subjected to a harrowing two-hour ordeal when she was imprisoned in a hi-tech public convenience. She was captured by the toilet, which boasts state-of-the-art electronic auto-flush and door sensors, which steadfastly refused to release it’s victim, and further resisted attempts by passers-by to force the door. Finally the fire brigade ripped the roof off the cantankerous crapper. • E-mail buffer overflow (1998) • Several E-mail systems suffer from a "buffer overflow error", when extremely long e-mail addresses are received.  The internal buffers receiving the addresses do not check for length and allow their buffers to overflow causing the applications to crash.  Hostile hackers use this fault to trick the computer into running a malicious program in its place. CIS 068

6. Why not only code it ? • Software is • a critically important infrastructure component • a key enabler • militaryly • economically • scientifically • culturally • But usually • expensive • of poor quality CIS 068

7. Common Software Problems • Software can cost hundreds or thousands of dollars per line • Lifetime maintenance costs are higher still • Software is late or fails • Software is not performant (too slow) • Software is incomprehensible • Software is more trouble to use than it is worth CIS 068

8. Past Approaches to Solutions • Create more chaos • Bad programs can be written in any language • (who finds the error in • reasoning in here ?) • Are you designing the • right program ? • but they change ! • …to do what ? • Use more people • Create better programming languages • Write software tools to help create software • Design before writing • Start by baselining requirements • Train people better CIS 068

9. The Software Crisis Summary: Millions are spent for an incomprehensible tool that comes late just to cause trouble, and we don’t have answers or: THE SOFTWARE CRISIS (1968) CIS 068

10. History 1968: NATO Software Engineering Conference in Garmisch (Germany): Why cannot bridge-building techniques be used to build operating systems (‘engineering’) ? CIS 068

11. The Nature of Software • • It is a component of a larger system that “fits” with hardware, people, mechanical devices • • It transforms data using computers • • It has a complex structure • • It is usually very large, expensive, and lengthy to build CIS 068

12. The Nature of Software • Software is extremely malleable – we can modify the product all too easily • • Software construction is human-intensive, there are no real costs of materials • • Software is intangible: no laws of physics are applicable • • Software is not detectable by any of the five human senses • • Software application horizons expand too fast--with human demands/imagination • • Software problems are unprecedentedly complex (a machine with millions of moving parts) • • Software solutions require unusual rigor • • Software has a discontinuous operational nature CIS 068

13. The Nature of Software But: The are characteristics analogue to physical engineering processes Studying such analogs can be useful: • Help us learn about computer software • Find points of similarity • Suggest successful approaches to be emulated • Avoid known mistakes CIS 068

14. Engineering Example • Building a house: • Land and finances • garden, garage, you are used to age wine, enjoy to sit by the fireplace, lots of storage, don’t like bauhaus • Architect will define number of floors and rooms, orientation of the driveway, size of the garage … • type of bricks, colour of the walls,… • Construction • Entering • Living in the house • Fixing minor problems, leaking in the roof … System Feasibility Software Plans and Requirements Product Design Detailed Design Code Integration (Product Verification) Integration (System Test) Operations and Maintenance CIS 068

15. The Waterfall Model System Feasibility Validation Plans + Requirements Validation Product Design Verification Detailed Design Verification Code Unit Test Integration Product Verification Integration System Test Didn’t we forget something ? Operation + Maintenance Revalidation CIS 068

16. The Waterfall Model System Feasibility Validation Plans + Requirements Validation Product Design Verification Detailed Design Verification Code Unit Test Integration Product Verification Integration System Test Operation + Maintenance Revalidation CIS 068

17. The Human Factor Programmer User SOFTWARE Customer Designer CIS 068

18. The Human Factor • Programmer‘s view: • Some (holy) lines of code • A technical challenge • A pet • ... Programmer User SOFTWARE Customer Designer CIS 068

19. The Human Factor • User‘s view: • A miracle • A wonderful tool making things easier • An incombprehensible tool • unnecessarilly complicating life • Something that simply should work ! Programmer User SOFTWARE Customer Designer CIS 068

20. The Human Factor Programmer User SOFTWARE Customer Designer • Customer‘s view: • A hopefully affordable tool to enhance profit. CIS 068

21. The Human Factor Programmer User SOFTWARE Customer Designer • Designer‘s view: • A reasonably complicated • tool to fulfill the needs • A technical challenge CIS 068

22. The Human Factor • Usually one person plays multiple roles • Separation of different roles needs discipline ! CIS 068

23. Review of Waterfall Model • Weaknesses: • Usually requirements change, are incomplete or even not known • Communication ! (…see Mars Orbiter…) • Result: ‘That’s not what I meant !’ ( go back to last step ) • WF-Model reacts very statically: • Each stage must be completed before next one starts CIS 068

24. Total Feedback System Feasibility Validation • Too expensive • Doesn’t force to discipline • Don’t show this to your boss ! Plans + Requirements Validation Product Design Verification Detailed Design Verification Code Unit Test Integration Product Verification Integration System Test Operation + Maintenance Revalidation CIS 068

25. The Unified Model • A tradeoff, unifying different models • Shows the basic message of different approaches CIS 068

26. The Unified Model Time Customer User Designer Programmer Activities CIS 068

27. Models: Review • There are a lot of models, each with it’s strong- and weaknesses • Keep in mind: • There is a necessity to manage the workflow • There are different views of software • Smaller projects can be managed by the waterfall model • Review your programming process, check which phase you are in • Play different roles by yourself • And NEVER forget the testing ! CIS 068

28. Software Life Cycle Activities Independent of how they are organized, the following activities are involved in the development of software: CIS 068

29. Example: The Phone Directory • Example will show activities: • Requirements • Analysis • Design • Implementation CIS 068

30. Phone Directory: Requirements • Phone Directory: • Interactive Program containing collection of names and phone-numbers • Insert new entries • Retrieve entries • Change Entries CIS 068

31. Phone Directory: Detailed Req’s • Import existing data ? • Read from file or enter interactively • If file: file-type ? • If text-file: comma separated ? • Final directory: filetype spec’s ? • Limited namelength ? • Numbers as string ? • Order alphabetically ? • Printout required ? • Double entries possible ? • … CIS 068

32. Phone Directory: Analysis • Requirement – related: • Cluster requirements to different levels of detail • Understand ALL requirements • Explore EVERY uncertainty CIS 068

33. Phone Directory: Analysis • Implementation-strategy: • Use commercial software ? • Design specific or reusable software ? • Outsource different tasks (if specified) ? • Which language ? • Impact on existing software-packages ? • … CIS 068

34. Phone Directory: Analysis • High level design: • Again: make sure you understand the problem ! • Different methodologies: • Top Down Design • Object Oriented Approach CIS 068

35. Analysis: Top Down Design • Stepwise Refinement, • Divide and Conquer • Start at top level • Divide into subproblems • For each subproblem: • Divide into subproblems, solving the higher level problem CIS 068

36. Analysis: Top Down Design Structure chart, indicating the relationship CIS 068

37. Analysis: Top Down Design Refinement CIS 068

38. Analysis: Top Down Design Refinement CIS 068

39. Analysis: Top Down Design Question: When should we stop the refinement ? Answer: Each subproblem should be RESPONSIBLE for exactly ONE activity (…in it’s description, there’s no AND) CIS 068

40. How to go on ? • What happens if proceeding with refinement, e.g. going down to flowchart ? • the problem description then will focus on PROCEDURES • Definition of data structures ? • This is a major problem in procedural driven design ! • Alternative: Object Oriented Design CIS 068

41. Object Oriented Design • Identify objects participating in the system • Look at nouns in the problem statement to identify objects: • …create phone directory …containing entries… read from/write to file… interact with user … • Objects: • Directory • Entry • File • User CIS 068

42. Object Oriented Design • 2.Identify INTERACTIONS between objects • Messages between objects • Look at verbs in the problem statement to identify interactions: • …create phone directory …containing entries… read from/write to file… interact with user … • Messages must be processed by object’s methods CIS 068

43. Object Oriented Design Class Diagram for Phone BookExample: Defined by UML (Unified Modeling Language) CIS 068

44. Object Oriented Design Class Diagram for Phone BookExample: Defined by UML (Unified Modeling Language) Actor Class Aggregation (“part of”) Navigability: Source Target CIS 068

45. Use Cases Definition: Use Case = Closed loop interaction with the user The refinement process of the top down approach is replaced by listing all use cases, or: “write down everything the system is supposed to do” CIS 068

46. Use Cases • Use Cases for phone book example: • The program must be able to: • load initial directory from file • insert new entry or change existing one • retrieve and display entry • save modified directory back to file • exit CIS 068

47. Use Cases Detailed Description ( 1 of 5): CIS 068

48. Use Cases Detailed Description ( 2 of 5): CIS 068

49. Use Cases Detailed Description ( 3 of 5): CIS 068

50. Use Cases Detailed Description ( 4 of 5): CIS 068