1. CSCI 260 – Software Design http://www.bowdoin.edu/~allen/courses/cs260/syllabus.html Instructor: Allen Tucker http://www.bowdoin.edu/~allen Background Course overview Course work Course resources References

2. Background: The Nature of Software... Software is intangible Software is easy to reproduce –Cost is in its development The industry is labor-intensive –Hard to automate Untrained people can hack something together –Quality problems are hard to notice Software is easy to modify Software does not ‘wear out;” it deteriorates over time –in ways not anticipated, thus making it complex

3. So… Much software has poor design and is getting worse Demand for software is high and rising We are in a perpetual ‘software crisis’ We have to learn to ‘engineer’ software

4. The Software Crisis: Only 9% of all software projects are delivered on time and on budget. IEEE Software (April 1998). –E.g., the Ariane 5 disaster [6] –E.g., "Software Quality Is Still a Work in Progress, Offshore and in the U.S.” Computerworld (Sept 2003) –E.g., “Why Software is so bad,” MIT Technology Review, 2002.Why Software is so bad –E.g., the Therac-25 disaster

5. The Ariane 5 Disaster [6] In 1996, the European Space Agency’s Ariane 5 launcher crashed on take-off: cost = $500 million. Cause of the crash: failure of the on-board computer system. Cause of the failure: conversion of 64-bit floating point value (called the horizontal_bias) to a 16-bit integer produced an arithmetic overflow exception. This exception was not trapped by the software (the designers had decided that it could not occur). With “design by contract,” the following line of code could have prevented the disaster: require horizontal_bias <= Max_horizontal_bias;

6. The software crisis has many contributors … 1. The nature of software itself –Pervasive –Complex 2. The software profession 3. Academia 4. Customers

7. Software is Pervasive Transportation and Aeronautics Health Care Process Control and Manufacturing Defense Electronic Commerce and Banking Energy Systems

8. Software is Complex Millions of Lines of Code (LOC) e.g., MS Word ~ 1m LOC MS NT ~ 10m LOC a pacemaker ~ 100k LOC Number of States e.g., an int has ~ 4.2m states (2 32 values) a program with 5 int variables has 5x2 32 states So what about MS Word? So traditional testing methods can sample only a small fraction of a program’s state space. Formal methods can provide a complement to testing.

9. What is Software Engineering?... The process of solving customers’ problems by the systematic development and evolution of large, high-quality software systems within cost, time and other constraints Solving customers’ problems –Sometimes the solution is to buy, not build (COTS) Systematic development –An engineering process (IEEE/ISO standardization of practices) Large, high quality software systems –Teamwork and co-ordination are required Cost, time and other constraints –The benefit must outweigh the cost –Underestimation of cost and time have caused many project failures

10. Elements of a Software Engineering Project (Steps 1-6 = the “software lifecycle”) 1.Requirements and specifications 2.Design Systems engineering: hardware / software mix Software architecture: Identifying subsystems and their interactions Detailed design of each subsystem User interface design Database design 3.Modeling Use cases Structural (static) Dynamic 4.Programming 5.Testing and verification 6.Deployment Process management

11. Types of Software Engineering Projects: 1.Most projects are evolutionary or maintenance projects, involving work on legacy systems 2.Few are ‘Green field’ projects, involving entirely new applications 3.Some projects involve building on a framework or combining existing components. –A framework is an application that is missing some important details. –Such projects Benefit from reusing reliable components. Provide some freedom to innovate as in green field projects

12. The majority view: mathematical rigor is unimportant in Software Design Lethbridge [5]: “Relatively little mathematics turns out to be important for software engineers in practice, and it tends to be forgotten.” …“If we continue to teach the amount and type of mathematics [that we now teach], we must justify it by other means than saying it is important to a software developer's work.”

13. Why Include Mathematical Rigor in Software Design? … We can design more reliable software. E.g., at Miami University [8], an elevator scheduling system was designed by 19 teams of students: –Six teams used formal methods and 13 teams used traditional design methods. –All had the same level of mathematics and computer science training. –Six sets of data were used to test the systems. –Outcomes All the formal methods teams’ solutions executed all six sets of test data correctly. only 6 of the 13 other teams' solutions did so.

14. More success stories… Six software developers [7] reported that the use of formal methods creates more reliable, efficient, and maintainable code. Two reported a 40% reduction in post-delivery failures compared with traditional methods. The use of formal methods in a system design [3] resulted in a failure rate of 0.04 defects per 1000 lines of code, far below the industry average. The use of formal methods in the design, code proof, and validation phases of a safety-critical system [4] found 140 faults.

15. So in this course, we’ll study: 1.What is software? 2.What is the traditional software design process, and how can it be improved? 3.What new tools and techniques are available for software design? UML – the “universal modeling language” Design by Contract – a process model JML – the “Java modeling language” 4. What benefits do they offer? 5. What are their drawbacks (costs)?

16. Course Content A study of the software design process, including: –tools for software modeling (UML) –Review logic and proof, and explore their use in software design –Use of formal methods (e.g., preconditions, postconditions, design by contract) for writing software specifications –Use of lab tools (e.g., Eclipse, UML, and JML) to model and implement our software specifications –A software design project to test our understanding of these ideas

17. Course Work 1.Weekly meetings –Two classes per week (10:00 TTh, Searles 223/224) 2.Written Assignments (6) –Individual 3.Tests (2) 4.Team Project 5.Resources http://www.bowdoin.edu/~allen/courses/cs260/syllabus.html –Syllabus –Assignments and Project –Powerpoint lecture notes –Tutorials and References (Java, Eclipse, UML, JML)

18. Lab Resources (Searles 224) Environments and tools (free download) –Eclipse/Java 1.4 http://www.eclipse.org/ http://www.eclipse.org/ –UML/OCL http://www.omondo.com/product.html http://www.omondo.com/product.html –JML http://www.cs.iastate.edu/~leavens/JML/index. shtml http://www.cs.iastate.edu/~leavens/JML/index. shtml Team project data

19. Team Project Course registration system Client-server architecture / on-line registration Realistic rules and regulations –Student Transcripts and Preferences –Courses –Prerequisites –Advising function Live data (~1600 students and ~300 courses) See www.bowdoin.edu/studentrecords/courseinfo/ for general background. www.bowdoin.edu/studentrecords/courseinfo/

20. Tips All work must be handed in on its due date. –hardcopy to Searles 220, and –electronic copy to allen@bowdoin.edu Team work is required for the project Individual work is required for all assignments and tests (help may be given/received on technical questions about using Eclipse/UML/JML, but not on substantive questions)

21. References 1.Lethbridge, T What Knowledge Is Important to a Software Professional? IEEE Computer (May 2000), 44-50. 2.Tucker, A. and B. Boehm. On the Balance between Theory and Practice. IEEE Software (September 2002), 94-97. 3.Leveson, N. Medical Devices: the Therac-25, short version here.Medical Devices: the Therac-25 here 4.Mann, Why Software Is So BadWhy Software Is So Bad 5.Hall, A. and R. Chapman. Correctness by Construction: Developing a Commercial Secure System. IEEE Software (Jan-Feb 2002), 18-25. 6.King, S. et al. Is Proof More Cost-Effective Than Testing? IEEE Trans on Software Engineering 26, 8 (August 2000), 675-685.

22. Elements of Software Quality Usability Efficiency Reliability Maintainability Reusability