CSCI 260 Software Design http www bowdoin

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

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

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

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. – E. g. , the Therac-25 disaster

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;

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

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

Software is Complex • Millions of Lines of Code (LOC) e. g. , MS Word ~ 1 m LOC MS NT ~ 10 m LOC a pacemaker ~ 100 k LOC • Number of States e. g. , an int has ~ 4. 2 m states (232 values) a program with 5 int variables has 5 x 232 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.

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

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

Types of Software Engineering Projects: 1. 2. 3. Most projects are evolutionary or maintenance projects, involving work on legacy systems Few are ‘Green field’ projects, involving entirely new applications 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

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. ”

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.

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.

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. 5. What benefits do they offer? What are their drawbacks (costs)?

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

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/cs 260/syllabus. html – Syllabus – Assignments and Project – Powerpoint lecture notes – Tutorials and References (Java, Eclipse, UML, JML)

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

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.

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)

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

Elements of Software Quality • • • Usability Efficiency Reliability Maintainability Reusability