• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
CSCI 260 – Software Design http:/www.bowdoin.edu/~allen ...
 

CSCI 260 – Software Design http:/www.bowdoin.edu/~allen ...

on

  • 475 views

 

Statistics

Views

Total Views
475
Views on SlideShare
475
Embed Views
0

Actions

Likes
0
Downloads
4
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    CSCI 260 – Software Design http:/www.bowdoin.edu/~allen ... CSCI 260 – Software Design http:/www.bowdoin.edu/~allen ... Presentation Transcript

    • 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
    • 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 …
      • The nature of software itself
        • Pervasive
        • Complex
      • The software profession
      • Academia
      • Customers
    • 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 ~ 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.
    • 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”)
      • Requirements and specifications
      • Design
          • Systems engineering: hardware / software mix
          • Software architecture: Identifying subsystems and their interactions
          • Detailed design of each subsystem
          • User interface design
          • Database design
      • Modeling
          • Use cases
          • Structural (static)
          • Dynamic
      • Programming
      • Testing and verification
      • Deployment
      • Process management
    • Types of Software Engineering Projects:
      • 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:
      • What is software?
      • What is the traditional software design process, and how can it be improved?
      • 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”
      • 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
      • Weekly meetings
        • Two classes per week (10:00 TTh, Searles 223/224)
      • Written Assignments (6)
        • Individual
      • Tests (2)
      • Team Project
      • Resources
      • http://www.bowdoin.edu/~allen/courses/cs260/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 [email_address]
      • 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
      • 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