Students are expected to select and complete a substantial course project during the semester on a topic related to the class.
The main goal of the project is allow you to dive deep into an area of program analysis of interest.
The final project is in part a class-wide effort and an individual effort. As a class, we will build an analysis infrastructure for a language on which we agree. Individually, you will undertake an analysis project that you define. The intent is that we will cooperate on fundamental infrastructure to leverage each other's efforts and to undertake ambitious projects. Because we could spend more than a semester building ever more expansive infrastructure, the focus of the infrastructure effort should be on creating the necessary pieces to serve your analysis projects.
Project Components and Dates
- Project proposal (TBA)
- Major status update (TBA)
- Project presentations (Dec 8 and Dec 10)
- Project paper (Dec 16)
- Peer reviews (Dec 17)
The purpose of the proposals and updates is help you get feedback from me (e.g., on its feasibility, possible directions). But come see me whenever you feel stuck.
The final project is a mini-research project in program analysis, though I do not expect each project to result in novel results. I do hope some of you will get so excited by your projects that you will come see me about taking it further to, say, publication!
I do expect a consistent effort on the project. Notably, "one long weekend" will not suffice. I can tell. Trust me.
You may undertake the analysis part individually or in small groups (e.g., pairs), but the number of group members should depend on the size of the project. Note that the grading for a two-person project will actually require "twice as much work" rather than the standard "1.5-times as much work". You should be able to split up the project paper (e.g., "I did section 1, Grace Hopper did section 2, and we shared section 3"), and I should be able to compare your part of the project to individual projects.
The final deliverables are a presentation and a paper describing your mini-research project, as well as your code contributions to the class-built analysis infrastructure.
The presentation and paper should be a research-style talk and manuscript. In particular, you should make sure to do the following: (1) define the problem that you tackle; (2) explain why the problem is important, interesting, and challenging; (3) convey your key idea or observation; and (4) detail any results that demonstrate your idea or observation. There are many resources on developing research skills; here's one that I highly recommend.
The presentation should be short and should describe what the problem was, what the difficulties were, and what was accomplished or learned. You will find it much easier to prepare the talk using slides (perhaps 8 to 10 slides, depending on your speed).
While preparing the talk keep in mind who your audience is. You will be presenting to colleagues who are eager to find out (1) about new exciting analyses and (2) how much fun you had. Plan to motivate the project (i.e., why is this important?) and to describe what you learned from it. Keep in mind that your colleagues have not read all the papers that you have read to do the project.
Project presentations will be held on Tuesday, April 30, 2013 and Thursday, May 2, 2013. Students presenting on April 30 will receive a small amount of extra credit to make up for presenting earlier.
Your write up at the end of the semester should be in the form of a short research paper. The project paper should have an abstract and an introduction describing the tackled problem, its motivation, and a very brief summary of the accomplishment. Then you continue with the body of the paper describing the technical aspects of your project. The paper should end with a related work section in which you compare the work with previous research results and a conclusion putting in perspective the accomplishment of the project and mentioning the open problems.
You might view your project paper as if you were submitting it to, for example, PLDI or POPL. You might want to browse the papers from PLDI 2014 or POPL 2014. Aside from giving you a number of data points for how the paper should look graphically, reading the electronic editions might trigger some ideas.
Your project paper should be concise but clearly convey what you have done. There is no length "minimum," but I suspect papers will be about 5-8 pages in length. You will want to use the LaTeX class file or Word template produced by SIGPLAN.
Paper Reviews. You will have the opportunity to write reviews of your peers' project papers for extra credit.
Evaluation. I will evaluate the content of your mini-research project primarily through the paper (though I will want to be able to run your analyzers).
The Infrastructure and the Analyzer Implementation
All of your implementation effort, benchmarks, test cases, documentation, and so forth should be checked into the class subversion repository.
You should have some documentation and tests that allows others to leverage your efforts. While I do not want this component to be overly burdensome, we do want your efforts to live on.
Evaluation. To evaluate your contribution to the infrastructure effort, you will complete a form rating yourself and your peers essentially on whether or not you "pulled your weight."
All labs should be completed individually. You may discuss the problems with others, but you must turn in your own work. If you discuss the problems with someone, you must cite them (following the collaboration policy).
Homework solutions should be submitted on the course moodle by 11:55 p.m. on the due date.
Part 1 Due Monday, September 15, 2014
Part 2 Due Monday, September 22, 2014
Part 3 Due Monday, September 29, 2014
It is important to attend class and read the readings.
Class participation includes in-class participation, as well as participation in the discussion on the Piazza. All enrolled students are required to post at least 1 substantive comment, question, or answer on each lecture and reading set. Initial comments, questions, or answers for each lecture must be posted the night before the next meeting. The goal is to identify concepts that need reviewing in the subsequent class.
You may and are encouraged to post comments or questions about the reading before the class where we will cover it. Posting early will help focus our discussion.
Here are some examples of good comments:
- Questions about the reading or the class discussion.
- Thoughtful answers to other people's questions.
- Clarification of some point discussed in class.
- What you think is the main point or key idea in the reading set.
- An idea of how some work could be improved from the reading or class discussion.
- Comments on a web resource related to a reading or class discussion (e.g., you happened upon an interesting blog post related to our discussion).
The intent of the post is definitely not to have you perform extra reading or web searching but rather to take a moment to reflect upon the day's reading or class discussion. Note that these posts are in lieu of more detailed (and time-consuming) paper summaries.