Software Engineering (CSE 503/Winter 2020)


Announcements


Overview

Software is becoming ever more complex and difficult to understand, at the same time as it is used ever more pervasively. It is hopeless to understand how software systems work (or why they do not work!) without automated assistance. Programmers need tool assistance during design, implementation, testing, debugging, and modification ("maintenance"). This graduate course will investigate a variety of program analysis techniques that address these software engineering tasks. Topics include static analysis (e.g., abstract interpretation), dynamic analysis (e.g., testing and debugging), and probabilistic methods. While the course focuses on the design and implementation of program analysis tools, the material will be useful to anyone who wishes to improve his or her programming or understand the state of the art.

Students will read classic and current technical papers and actively participate in discussions. The heart of this course is a team research project. Sample projects will be provided, but students are also free to propose their own, particularly ones motivated by their own problems experienced while programming. Examples include proposing and evaluating a fundamental new technique; developing and assessing new algorithms to replace currently-used ones; translating a methodology to a new problem domain; evaluation of proposed techniques (for instance, via a user study); and applying known techniques to new problem domains, such as operating systems, networks, embedded systems, security, biology, aerospace, etc.

This is not a course about how to build programs, though the information in the class may help you to do that. Rather, this is a course about research in software engineering.


Logistics

Lecture

Wed/Fri 11:30am--12:50am

Room

CSE 305 (Allen Center)

Instructor

René Just
  • rjust(at)cs.washington.edu
  • Office: CSE2 338
  • Office hours: After class and by appointment

Teaching Assistant

Martin Kellogg
  • kelloggm(at)cs.washington.edu
  • Office: CSE2 253
  • Office hours: Wednesdays, 2pm

Syllabus

Grading

Grades will be based on a research project, homeworks, and participation:
  • 60%: Research project
  • 30%: Homeworks and in-class exercises
  • 10%: Participation

Papers

CSE 503 is a graduate paper-focused course. Most class session will begin with a brief discussion and presentation of material, after (or during) which the floor will be open to rebuttals, discussion of related work, criticism, brainstorming about follow-on research, etc. We will all learn from the conversation, even the instructor. We will all have questions and confusions about the material, even the instructor. You are required to be not a passive listener to lectures but an active participant in the discussion.

To help you prepare, you will write a one-paragraph commentary and answer readings questions for most papers, and submit your write up at least the day before the class meets to discuss the paper. You will post your commentary and answers to a Canvas discussion board for viewing by the instructor and by other students. The commentary should reflect your understanding and analysis of the issues raised by the paper, and should also help direct (both your and others’) preparation for in-class discussion.

You may write the commentary in whatever style you prefer that meets the goals listed above. One good format for the commentary is to critique the paper, listing the following three points: its biggest contribution (and, briefly, why that result was not already obvious), its biggest mistake (in motivation, methodology, algorithm, data analysis, conclusions, or some other area), and the biggest question that it raises (or the most interesting and important follow-on work that it suggests). Another acceptable format is to summarize the paper, describing its thesis, approach, and conclusions, and stating why it is significant. The commentary should also list questions that you have about the paper, such as about technical points or connections to related work. For other ideas about how to critique a paper, see the following advice.

It's OK if you read the paper and there are issues you do not understand. Please ask questions about those issues — both in your summary and in class — and we will all gain by the discussion. It's best to explain why something makes no sense to you. For example, don't just say, "I didn’t understand section 2", but state where there is a logical fallacy or a conclusion that does not follow or a term that is not defined. The instructor will use these questions to help shape the lectures.

You will have access to all the other students’ write ups after posting your own. Please read them, which is a good way for you to get perspective. You can see what you missed (or what other people missed), and whether you agree with their take on the key ideas. It will help to make the class sessions more productive. We also encourage you to use the summaries to ask questions. If you have a question, it is likely that others have the same question but may be too shy (or vain, or insecure) to ask it; they will appreciate you raising the point.



Course material

Date Topic Materials Readings/Assignments

01/08 Introduction • Slides HW 1: development challenges (due 01/14)

01/10 Dynamic vs. static analysis • Slides • Static and dynamic analysis: synergy and duality
• Lessons from Building Static Analysis Tools at Google

01/15 Abstract Interpretation • Lecture notes
• Slides
• Abstract Interpretation: a semantics-based tool for program analysis (Sections 1 and 2)
Reading questions

01/17 Abstract Interpretation • Lecture notes
• Slides
• Examples
• Abstract Interpretation: a unified lattice model for static analysis of programs by construction or approximation of fixpoints
Reading questions

01/22 Abstract Interpretation • Examples • HW 1: development challenges (solutions)
Project proposal (due 01/28)

01/24 Testing • Slides • DART: Directed Automated Random Testing
Reading questions
HW 2: abstract interpretation (due 02/21)

01/29 Testing • Examples • Feedback-directed Random Test Generation
• EvoSuite: Automatic Test Suite Generation for Object-Oriented Software
Reading questions

01/31 Testing • Examples • Do Automatically Generated Unit Tests Find Real Faults? An Empirical Study of Effectiveness and Challenges
Reading questions

02/05 Delta Debugging • Slides • Simplifying and Isolating Failure-Inducing Input
Reading questions

02/07 Delta Debugging In-class exercise (instructions)

02/12 Slicing • Thin Slicing
Reading questions

02/14 Invariants • Slides • Dynamically discovering likely program invariants to support program evolution (skim sections 5-8; read the rest more carefully)
Reading questions

02/19 Program Repair • A systematic study of automated program repair: Fixing 55 out of 105 bugs for $8 each
Reading questions

02/21 Program Repair • Slides • An Analysis of Patch Plausibility and Correctness for Generate-and-Validate Patch Generation Systems
Reading questions

02/26 Empirical Research • Slides • Is computer science science?
• Should computer scientists experiment more?
Reading questions

02/28 Empirical Research • Slides • Practical Guide for Using Statistical Tests to Assess Randomized Algorithms in Software Engineering
Reading questions

03/04 ML for SE • Suggesting accurate method and class names
Reading questions

03/06 ML for SE • Examples • Code2vec: Learning distributed representations of code
Reading questions

03/11 Summary

03/13 Presentations




You can find the general course policies here.