CSCI 260 – Software Design http:/ ...


Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

CSCI 260 – Software Design http:/ ...

  1. 1. CSCI 260 – Software Design Instructor: Allen Tucker Background Course overview Course work Course resources References
  2. 2. Background: The Nature of Software... <ul><li>Software is intangible </li></ul><ul><li>Software is easy to reproduce </li></ul><ul><ul><li>Cost is in its development </li></ul></ul><ul><li>The industry is labor-intensive </li></ul><ul><ul><li>Hard to automate </li></ul></ul><ul><li>Untrained people can hack something together </li></ul><ul><ul><li>Quality problems are hard to notice </li></ul></ul><ul><li>Software is easy to modify </li></ul><ul><li>Software does not ‘wear out;” it deteriorates over time </li></ul><ul><ul><li>in ways not anticipated, thus making it complex </li></ul></ul>
  3. 3. So… <ul><li>Much software has poor design and is getting worse </li></ul><ul><li>Demand for software is high and rising </li></ul><ul><li>We are in a perpetual ‘software crisis’ </li></ul><ul><li>We have to learn to ‘engineer’ software </li></ul>
  4. 4. The Software Crisis: <ul><li>Only 9% of all software projects are delivered on time and on budget. IEEE Software (April 1998). </li></ul><ul><ul><li>E.g., the Ariane 5 disaster [6] </li></ul></ul><ul><ul><li>E.g., &quot;Software Quality Is Still a Work in Progress, Offshore and in the U.S.” Computerworld (Sept 2003) </li></ul></ul><ul><ul><li>E.g., “ Why Software is so bad ,” MIT Technology Review, 2002. </li></ul></ul><ul><ul><li>E.g., the Therac-25 disaster </li></ul></ul>
  5. 5. The Ariane 5 Disaster [6] <ul><li>In 1996, the European Space Agency’s Ariane 5 launcher crashed on take-off: cost = $500 million. </li></ul><ul><li>Cause of the crash : failure of the on-board computer system. </li></ul><ul><li>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 . </li></ul><ul><li>This exception was not trapped by the software (the designers had decided that it could not occur). </li></ul><ul><li>With “design by contract,” the following line of code could have prevented the disaster: </li></ul><ul><li>require horizontal_bias <= Max_horizontal_bias; </li></ul>
  6. 6. The software crisis has many contributors … <ul><li>The nature of software itself </li></ul><ul><ul><li>Pervasive </li></ul></ul><ul><ul><li>Complex </li></ul></ul><ul><li>The software profession </li></ul><ul><li>Academia </li></ul><ul><li>Customers </li></ul>
  7. 7. Software is Pervasive <ul><li>Transportation and Aeronautics </li></ul><ul><li>Health Care </li></ul><ul><li>Process Control and Manufacturing </li></ul><ul><li>Defense </li></ul><ul><li>Electronic Commerce and Banking </li></ul><ul><li>Energy Systems </li></ul>
  8. 8. Software is Complex <ul><li>Millions of Lines of Code (LOC) </li></ul><ul><li>e.g., MS Word ~ 1m LOC </li></ul><ul><li> MS NT ~ 10m LOC </li></ul><ul><li> a pacemaker ~ 100k LOC </li></ul><ul><li>Number of States </li></ul><ul><li>e.g., an int has ~ 4.2m states (2 32 values) </li></ul><ul><li> a program with 5 int variables has 5x2 32 states </li></ul><ul><li> So what about MS Word? </li></ul><ul><li>So traditional testing methods can sample only a small fraction of a program’s state space. </li></ul><ul><li>Formal methods can provide a complement to testing. </li></ul>
  9. 9. What is Software Engineering?... <ul><li>The process of solving customers’ problems by the systematic development and evolution of large, high-quality software systems within cost, time and other constraints </li></ul><ul><li>Solving customers’ problems </li></ul><ul><ul><li>Sometimes the solution is to buy, not build (COTS) </li></ul></ul><ul><li>Systematic development </li></ul><ul><ul><li>An engineering process (IEEE/ISO standardization of practices) </li></ul></ul><ul><li>Large, high quality software systems </li></ul><ul><ul><li>Teamwork and co-ordination are required </li></ul></ul><ul><li>Cost, time and other constraints </li></ul><ul><ul><li>The benefit must outweigh the cost </li></ul></ul><ul><ul><li>Underestimation of cost and time have caused many project failures </li></ul></ul>
  10. 10. Elements of a Software Engineering Project (Steps 1-6 = the “software lifecycle”) <ul><li>Requirements and specifications </li></ul><ul><li>Design </li></ul><ul><ul><ul><li>Systems engineering: hardware / software mix </li></ul></ul></ul><ul><ul><ul><li>Software architecture: Identifying subsystems and their interactions </li></ul></ul></ul><ul><ul><ul><li>Detailed design of each subsystem </li></ul></ul></ul><ul><ul><ul><li>User interface design </li></ul></ul></ul><ul><ul><ul><li>Database design </li></ul></ul></ul><ul><li>Modeling </li></ul><ul><ul><ul><li>Use cases </li></ul></ul></ul><ul><ul><ul><li>Structural (static) </li></ul></ul></ul><ul><ul><ul><li>Dynamic </li></ul></ul></ul><ul><li>Programming </li></ul><ul><li>Testing and verification </li></ul><ul><li>Deployment </li></ul><ul><li>Process management </li></ul>
  11. 11. Types of Software Engineering Projects: <ul><li>Most projects are evolutionary or maintenance projects, involving work on legacy systems </li></ul><ul><li>Few are ‘Green field’ projects, involving entirely new applications </li></ul><ul><li>Some projects involve building on a framework or combining existing components. </li></ul><ul><ul><li>A framework is an application that is missing some important details . </li></ul></ul><ul><ul><li>Such projects </li></ul></ul><ul><ul><ul><li>Benefit from reusing reliable components. </li></ul></ul></ul><ul><ul><ul><li>Provide some freedom to innovate as in green field projects </li></ul></ul></ul>
  12. 12. The majority view: mathematical rigor is unimportant in Software Design <ul><li>Lethbridge [5]: “Relatively little mathematics turns out to be important for software engineers in practice, and it tends to be forgotten.” </li></ul><ul><li>…“ 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.” </li></ul>
  13. 13. Why Include Mathematical Rigor in Software Design? <ul><li>… We can design more reliable software. </li></ul><ul><li>E.g., at Miami University [8], an elevator scheduling system was designed by 19 teams of students: </li></ul><ul><ul><li>Six teams used formal methods and 13 teams used traditional design methods. </li></ul></ul><ul><ul><li>All had the same level of mathematics and computer science training. </li></ul></ul><ul><ul><li>Six sets of data were used to test the systems. </li></ul></ul><ul><ul><li>Outcomes </li></ul></ul><ul><ul><ul><li>All the formal methods teams’ solutions executed all six sets of test data correctly. </li></ul></ul></ul><ul><ul><ul><li>only 6 of the 13 other teams' solutions did so. </li></ul></ul></ul>
  14. 14. More success stories… <ul><li>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. </li></ul><ul><li>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. </li></ul><ul><li>The use of formal methods in the design, code proof, and validation phases of a safety-critical system [4] found 140 faults . </li></ul>
  15. 15. So in this course, we’ll study: <ul><li>What is software? </li></ul><ul><li>What is the traditional software design process, and how can it be improved? </li></ul><ul><li>What new tools and techniques are available for software design? </li></ul><ul><ul><li>UML – the “universal modeling language” </li></ul></ul><ul><ul><li>Design by Contract – a process model </li></ul></ul><ul><ul><li>JML – the “Java modeling language” </li></ul></ul><ul><li>What benefits do they offer? </li></ul><ul><li>What are their drawbacks (costs)? </li></ul>
  16. 16. Course Content <ul><li>A study of the software design process, including: </li></ul><ul><ul><li>tools for software modeling (UML) </li></ul></ul><ul><ul><li>Review logic and proof , and explore their use in software design </li></ul></ul><ul><ul><li>Use of formal methods (e.g., preconditions, postconditions, design by contract) for writing software specifications </li></ul></ul><ul><ul><li>Use of lab tools (e.g., Eclipse, UML, and JML) to model and implement our software specifications </li></ul></ul><ul><ul><li>A software design project to test our understanding of these ideas </li></ul></ul>
  17. 17. Course Work <ul><li>Weekly meetings </li></ul><ul><ul><li>Two classes per week (10:00 TTh, Searles 223/224) </li></ul></ul><ul><li>Written Assignments (6) </li></ul><ul><ul><li>Individual </li></ul></ul><ul><li>Tests (2) </li></ul><ul><li>Team Project </li></ul><ul><li>Resources </li></ul><ul><li> </li></ul><ul><ul><li>Syllabus </li></ul></ul><ul><ul><li>Assignments and Project </li></ul></ul><ul><ul><li>Powerpoint lecture notes </li></ul></ul><ul><ul><li>Tutorials and References (Java, Eclipse, UML, JML) </li></ul></ul>
  18. 18. Lab Resources (Searles 224) <ul><li>Environments and tools (free download) </li></ul><ul><ul><li>Eclipse/Java 1.4 </li></ul></ul><ul><ul><li>UML/OCL http://www. omondo .com/product.html </li></ul></ul><ul><ul><li>JML </li></ul></ul><ul><li>Team project data </li></ul>
  19. 19. Team Project <ul><li>Course registration system </li></ul><ul><li>Client-server architecture / on-line registration </li></ul><ul><li>Realistic rules and regulations </li></ul><ul><ul><li>Student Transcripts and Preferences </li></ul></ul><ul><ul><li>Courses </li></ul></ul><ul><ul><li>Prerequisites </li></ul></ul><ul><ul><li>Advising function </li></ul></ul><ul><li>Live data (~1600 students and ~300 courses) </li></ul><ul><li>See www. bowdoin . edu / studentrecords / courseinfo / for general background. </li></ul>
  20. 20. Tips <ul><li>All work must be handed in on its due date. </li></ul><ul><ul><li>hardcopy to Searles 220, and </li></ul></ul><ul><ul><li>electronic copy to [email_address] </li></ul></ul><ul><li>Team work is required for the project </li></ul><ul><li>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) </li></ul>
  21. 21. References <ul><li>Lethbridge, T What Knowledge Is Important to a Software Professional? IEEE Computer (May 2000), 44-50. </li></ul><ul><li>Tucker, A. and B. Boehm. On the Balance between Theory and Practice. IEEE Software (September 2002), 94-97. </li></ul><ul><li>Leveson, N. Medical Devices: the Therac -25 , short version here . </li></ul><ul><li>Mann, Why Software Is So Bad </li></ul><ul><li>Hall, A. and R. Chapman. Correctness by Construction: Developing a Commercial Secure System. IEEE Software (Jan-Feb 2002), 18-25. </li></ul><ul><li>King, S. et al. Is Proof More Cost-Effective Than Testing? IEEE Trans on Software Engineering 26, 8 (August 2000), 675-685. </li></ul>
  22. 22. Elements of Software Quality <ul><li>Usability </li></ul><ul><li>Efficiency </li></ul><ul><li>Reliability </li></ul><ul><li>Maintainability </li></ul><ul><li>Reusability </li></ul>