Inculcating Invariants in Introductory Courses David Evans and Michael Peck University of Virginia ICSE 2006 Education Track Shanghai, 24 May 2006 www.cs.virginia.edu/evans.

Slides:



Advertisements
Similar presentations
Test process essentials Riitta Viitamäki,
Advertisements

11-Jun-14 The assert statement. 2 About the assert statement The purpose of the assert statement is to give you a way to catch program errors early The.
Rigorous Software Development CSCI-GA Instructor: Thomas Wies Spring 2012 Lecture 8.
計算機概論 ( 二 ) 4 授課教師:許永真 4 上課時間:週二 16:10-18:00 週四 13:10-14:00 4 上課地點:資 107/101 4 課程網頁: – 4 課程教材: –Structure and.
Evaluating Requirements. Outline Brief Review Stakeholder Review Requirements Analysis Summary Activity 1.
Debugging Introduction to Computing Science and Programming I.
Cs2220: Engineering Software Class 1: Engineering Software? Fall 2010 University of Virginia David Evans.
An overview of JML tools and applications Lilian Burdy Gemplus Yoonsik Cheon, Gary Leavens Iowa Univ. David Cok Kodak Michael Ernst MIT Rustan Leino Microsoft.
Copyright © 2006 The McGraw-Hill Companies, Inc. Programming Languages 2nd edition Tucker and Noonan Chapter 18 Program Correctness To treat programming.
Dynamically Discovering Likely Program Invariants to Support Program Evolution Michael D. Ernst, Jake Cockrell, William G. Griswold, David Notkin Presented.
Dynamically Discovering Likely Program Invariants to Support Program Evolution Michael Ernst, Jake Cockrell, William Griswold, David Notkin Presented by.
Houdini: An Annotation Assistant for ESC/Java Cormac Flanagan and K. Rustan M. Leino Compaq Systems Research Center.
OOP #10: Correctness Fritz Henglein. Wrap-up: Types A type is a collection of objects with common behavior (operations and properties). (Abstract) types.
The C++ Tracing Tutor: Visualizing Computer Program Behavior for Beginning Programming Courses Rika Yoshii Alastair Milne Computer Science Department California.
CS 330 Programming Languages 09 / 16 / 2008 Instructor: Michael Eckmann.
Applied Software Project Management 1 Introduction Dr. Mengxia Zhu Computer Science Department Southern Illinois University Carbondale.
1CMSC 345, Version 4/04 Verification and Validation Reference: Software Engineering, Ian Sommerville, 6th edition, Chapter 19.
1 Functional Testing Motivation Example Basic Methods Timing: 30 minutes.
Computer Science 340 Software Design & Testing Design By Contract.
Verification and Validation Yonsei University 2 nd Semester, 2014 Sanghyun Park.
© Janice Regan, CMPT 128, Jan CMPT 128 Introduction to Computing Science for Engineering Students Creating a program.
Testing. What is Testing? Definition: exercising a program under controlled conditions and verifying the results Purpose is to detect program defects.
Jun 16, 2014IAT 2651 Debugging. Dialectical Materialism  Dialectical materialism is a strand of Marxism, synthesizing Hegel's dialectics, which proposes.
Software Engineering Prof. Dr. Bertrand Meyer March 2007 – June 2007 Chair of Software Engineering Static program checking and verification Slides: Based.
1 Debugging and Testing Overview Defensive Programming The goal is to prevent failures Debugging The goal is to find cause of failures and fix it Testing.
Automatically Inferring Temporal Properties for Program Evolution Jinlin Yang and David Evans 15 th IEEE International Symposium on Software Reliability.
Process Design (Requirements). Recall the Four Steps of Problem Solving * Orient Plan Execute Test These apply to any kind of problem, not just spreadsheet.
LECTURE 38: REFACTORING CSC 395 – Software Engineering.
Errors And How to Handle Them. GIGO There is a saying in computer science: “Garbage in, garbage out.” Is this true, or is it just an excuse for bad programming?
Chapter 25 Formal Methods Formal methods Specify program using math Develop program using math Prove program matches specification using.
Extended Static Checking for Java  ESC/Java finds common errors in Java programs: null dereferences, array index bounds errors, type cast errors, race.
The Daikon system for dynamic detection of likely invariants MIT Computer Science and Artificial Intelligence Lab. 16 January 2007 Presented by Chervet.
DEBUGGING. BUG A software bug is an error, flaw, failure, or fault in a computer program or system that causes it to produce an incorrect or unexpected.
Houdini, an annotation assistant for ESC/Java K. Rustan M. Leino Compaq SRC Joint work with Cormac Flanagan K. Rustan M. Leino Compaq SRC Joint work with.
Testing and Debugging Session 9 LBSC 790 / INFM 718B Building the Human-Computer Interface.
Cs2220: Engineering Software Class 6: Defensive Programming Fall 2010 University of Virginia David Evans.
(1) Unit Testing and Test Planning CS2110: SW Development Methods These slides design for use in lab. They supplement more complete slides used in lecture.
CS Data Structures I Chapter 2 Principles of Programming & Software Engineering.
Jinlin Yang and David Evans [jinlin, Department of Computer Science University of Virginia PASTE 2004 June 7 th 2004
1 Ch. 1: Software Development (Read) 5 Phases of Software Life Cycle: Problem Analysis and Specification Design Implementation (Coding) Testing, Execution.
1 CSCD 326 Data Structures I Software Design. 2 The Software Life Cycle 1. Specification 2. Design 3. Risk Analysis 4. Verification 5. Coding 6. Testing.
Hack for HHVM Converting Facebook Julien Verlaguet Software Engineer.
1 Debugging and Syntax Errors in C++. 2 Debugging – a process of finding and fixing bugs (errors or mistakes) in a computer program.
Software Development Problem Analysis and Specification Design Implementation (Coding) Testing, Execution and Debugging Maintenance.
Design - programming Cmpe 450 Fall Dynamic Analysis Software quality Design carefully from the start Simple and clean Fewer errors Finding errors.
Error messages 25-Apr-17.
David Streader Computer Science Victoria University of Wellington Copyright: David Streader, Victoria University of Wellington Debugging COMP T1.
ANU COMP2110 Software Design in 2003 Lecture 10Slide 1 COMP2110 Software Design in 2004 Lecture 12 Documenting Detailed Design How to write down detailed.
Formal Specification: a Roadmap Axel van Lamsweerde published on ICSE (International Conference on Software Engineering) Jing Ai 10/28/2003.
SWE 4743 Abstract Data Types Richard Gesick. SWE Abstract Data Types Object-oriented design is based on the theory of abstract data types Domain.
David Evans CS201j: Engineering Software University of Virginia Computer Science Lecture 9: Designing Exceptionally.
The single most important skill for a computer programmer is problem solving Problem solving means the ability to formulate problems, think creatively.
HNDIT23082 Lecture 09:Software Testing. Validations and Verification Validation and verification ( V & V ) is the name given to the checking and analysis.
Extended Static Checking for Java Cormac Flanagan Joint work with: Rustan Leino, Mark Lillibridge, Greg Nelson, Jim Saxe, and Raymie Stata Compaq Systems.
Combining Static and Dynamic Reasoning for Bug Detection Yannis Smaragdakis and Christoph Csallner Elnatan Reisner – April 17, 2008.
Exceptions Lecture 11 COMP 401, Fall /25/2014.
David Evans CS201j: Engineering Software University of Virginia Computer Science Lecture 10: Programming Exceptionally.
Week # 4 Quality Assurance Software Quality Engineering 1.
CS 5150 Software Engineering Lecture 21 Reliability 2.
CSE 374 Programming Concepts & Tools Hal Perkins Fall 2015 Lecture 17 – Specifications, error checking & assert.
Jeremy Nimmer, page 1 Automatic Generation of Program Specifications Jeremy Nimmer MIT Lab for Computer Science Joint work with.
Chapter 6 CS 3370 – C++ Functions.
Design David Evans cs205: engineering software
CSE 374 Programming Concepts & Tools
Testing and Debugging.
Accessible Formal Methods A Study of the Java Modeling Language
The Future of Software Engineering: Tools
Hoare-style program verification
Test Cases, Test Suites and Test Case management systems
Computer Science 340 Software Design & Testing
Presentation transcript:

Inculcating Invariants in Introductory Courses David Evans and Michael Peck University of Virginia ICSE 2006 Education Track Shanghai, 24 May

2Inculcating Invariants - David Evans, University of Virginia I think that it’s extraordinarily important that we in computer science keep fun in computing. When it started out, it was an awful lot of fun. Of course, the paying customer got shafted every now and then, and after a while we began to take their complaints seriously. We began to feel as if we really were responsible for the successful, error-free perfect use of these machines. I don’t think we are. I think we’re responsible for stretching them, setting them off in new directions, and keeping fun in the house… Alan Perlis (forward to Abelson & Sussman, Structure and Interpretation of Computer Programs) How does software engineering education fit into a computer science education?

3Inculcating Invariants - David Evans, University of Virginia First Computing Course Fun programs It works on my input once One programmer One friendly user A few hours work No consequences of failure “Customer Complaints” Working programs It always works on our inputs Many programmers Dumb, evil users Over many years Failure means lives and fortunes lost

4Inculcating Invariants - David Evans, University of Virginia Strategies 1.Incorporate “customer complaints” into first course: Static typing, extensive testing, exceptions, formal specification, etc. (“Brick Laying”) 2.Keep first course “fun”: Big, exciting conceptual ideas in first course, try to fix bad habits later (Jin Mao Tower) Jin Mao Tower Shanghai World Financial Center

5Inculcating Invariants - David Evans, University of Virginia

6Inculcating Invariants - David Evans, University of Virginia Shock therapy to break bad habits

7Inculcating Invariants - David Evans, University of Virginia Programmer’s Dilemma Low Confidence High Confidence Incorrect Program HarmlessDangerous Correct Program WorthlessValuable Initial goal Realistic goal

8Inculcating Invariants - David Evans, University of Virginia “Unfriendly” Testing Public test cases Secret test cases Interactive secret test cases –See when they fail, but not the tests

9Inculcating Invariants - David Evans, University of Virginia Gambling Capture the costs of defects, and value of confidence Bet up to 20 points on correctness of code – lose 2x bet if incorrect What is “correct”?

10Inculcating Invariants - David Evans, University of Virginia Philosophy “This generation of students got into [college] by doing exactly and precisely what teacher wants. If teacher is vague about what he [sic] wants, they work a lot harder to figure out what they want and whether or not it is good. The vaguer the directions, the more likely the opportunity for serendipity to happen. It drives them nuts!” Harvard Professor John Stilgoe (on 60 Minutes, 4 January 2004)

11Inculcating Invariants - David Evans, University of Virginia Correctness Code matches the specified behavior When the specification is vague or ambiguous, it matches what a rational (but unfriendly) “customer” expects –Unless student clarifies the specification Results: –8 bet 0, 2 of them correct –14 bet 2-10, 10 of them correct –3 bet 20, 1 of them correct

12Inculcating Invariants - David Evans, University of Virginia Program Analysis Tools Motivation and feedback for documenting invariants Becoming widely used in industry –Microsoft requires all Windows developers to annotate their code Detect problems that are hard to find in testing

13Inculcating Invariants - David Evans, University of Virginia ESC/Java Extended static checking tool for Java DEC/Compaq/HP SRC [Leino 2001] –ESC/Java 2 [David Cok and Joe Kiniry] Assumptions documents using syntactic comments Produces warnings for code that could produce run-time errors

14Inculcating Invariants - David Evans, University of Virginia Documenting Assumptions Functions –Pre-conditions: index < numEntries –Permitted modifications: numEntries –Post-conditions: numEntries == \old(numEntries) + 1; Objects –Invariants els.containsNull == false

15Inculcating Invariants - David Evans, University of Virginia ESC/Java Warnings AverageLength.java:7: Warning: Array index possibly too large (IndexTooBig) String filename = args[0]; ^ AverageLength.java:18: Warning: Precondition possibly not established (Pre) String name = names.getNthLowest (index); ^ Associated declaration is "./StringTable.spec", line 47, col 10: index < numEntries;

16Inculcating Invariants - David Evans, University of Virginia Real Challenge How can you make documenting assumptions useful enough (for small programs) so students do it while they are developing instead of after? –Interactive secret tests can help some, but most students still put off writing annotations until their code appears to work

17Inculcating Invariants - David Evans, University of Virginia Annotating Programs Major difficulty is getting formal syntax right –Students understand invariant and can express it informally, but can’t find right annotation Can dynamic inference tools help?

18Inculcating Invariants - David Evans, University of Virginia Dynamic Inference Tools Guess likely invariants by examining test executions –Some invariants produced are wrong –Some needed invariants will be missed Daikon [Ernst+ TSE 2001] –Can produce ESC/Java annotations Perracotta [see Jinlin Yang’s talk tomorrow] –Infers simple ordering properties

19Inculcating Invariants - David Evans, University of Virginia Experiment Based on experiment by Nimmer and Ernst [FSE 2002] Provide students with programs with Daikon-produced annotations –Two programs, two versions of each –Some correct annotations, some incorrect, some missing Students given 30 minutes per program to correct annotations Collected traces of their ESC/Java executions

20Inculcating Invariants - David Evans, University of Virginia Experiment Results Students rarely removed correct annotations (only 1 removed in entire experiment) Most students removed incorrect annotations that produced ESC/Java warnings Some added correct annotations, but most had trouble with complex ones

21Inculcating Invariants - David Evans, University of Virginia Conclusions Tool interfaces, clear feedback really matter –Eclipse front end to ESC/Java helped Writing formal specifications (even if you call them “annotations”) is still hard –Good tools can make the payoff immediate enough Dynamic inference tools might help –Side benefit: reveal weak test suites

22Inculcating Invariants - David Evans, University of Virginia Questions Should we teach software engineering in first CS courses? If not, how can we recover from the bad habits students learn in early courses? Send me your ideas for an ISCE 2007 panel.