02242: Program Analysis

Feedback §2.1

This course is still in its infancy, feedback is therefore crucial to make it better for generations to come. You are welcome to send suggestions to chrg@dtu.dk or anonymously on this Google Form.

Teaching Philosophy §2.2

Personally, I have always thought we teach material backwards; first we give students all the information in a lecture, and then afterward we ask them to solve exercises. This is problematic as the student does not know what to do with the information, and when they figure out what they need to do, they have no way of getting the information.

So my teaching philosophy is a best summarized by the phrase:

You only learn from your mistakes.

Essentially, no matter what you, the student, is presented with, it will not be absorbed, unless it is needed by you to fill gabs in your understanding. And you only realize that there are gabs, if you fail at doing a task. My teaching style is therefore practical and hands on.

We know this form of teaching is taxing, and can feel frustrating, so please reach out if you need help, because it is the only way to learn.

Didactic Contract §2.3

During the course you will spend most of your time implementing different program analyses. It is therefore expected (and required) that you have a good level of programming experience. DTU sets the expected workload of one ETCS point to 28 hours. Since this is a 7.5 ETCS point course over 13 weeks + 1 week exam, one should expect to use 14 hours on this course a week, only 4 of which are in class.

Participation in the class or doing the assignments are not mandatory. However, they are the primary way we convey the material of the class. It will be very hard to pass the course without engaging with the material.

In return, I will teach you program analysis by presenting you with challenges to overcome, make the lectures relevant, help you to learn when you fail, and support you, so you do not give up.

The Challenge §2.4

Because of my Teaching Philosophy (§2.2), I will make sure you have the activity before the lectures. The goal of the course is very simply to do as well as possible on a benchmark suite called JPAMB. In short, the benchmark suite is a collection of java programs, which you will build multiple analyses for. You will try to build an analysis which is as good as possible.

In the end of the course you will be evaluated on how well you did at this task.

The rules are available in the README of the project.

You can upload the results of running the evaluation to Autolab, use the access code 7FNKZO.

Questions §2.5

At every lecture, I will ask 2-4 questions which can guide you to investigate different different aspects of program analysis.

Groups §2.6

To solve the challenges, we are going to have two kinds of groups:

• The Feedback Group is a group of ~8 random students. The goal of this groups is to have a place to hear about alternative solutions to your current problems. In the start of every class, you'll sit at these groups, as well as answer the Questions (§2.5) together.

• The Project Group is a group of 4 - 6 students. The goal of this group is do the final project and defend it together orally. The groups are due when handing in the proposal, and the groups cannot overlap with your feedback groups.

Lecture Structure §2.7

To foster an atmosphere of collaboration and give you a change to get peer-feedback on your ideas, we start every lecture with 30 minutes of feedback revolving around the questions given in class. Every lecture (except the first) is structure like so:

• 13:00 Peer-feedback. In the beginning of the lecture you should sit with you feedback groups. Together with them you'll discuss your progress over the last week: what was easy and what was hard, as well as the questions from the previous lecture.

• 13:20 Communal Feedback. We'll then summarize the feedback in class, hopefully resolving the biggest questions from the last week.

• 13:30 Lecture. Then we'll have an interactive lecture about the problem of the day. Here we can cover any problems and questions that have come up during the Getting started section.

• 15:00 Lab-work, with TA's.

Schedule §2.8

The lectures are on Mondays at 13:00 to 17:00. This is a tentative list of topics and might change. As I update the lecture notes, the links to the old lecture notes will disappear.

Choosing a Project §3.1

The first thing you should do is find an interesting topic. The topic should be centered around program analysis, and should demonstrate your understanding of the course. The normal case is to choose one more benchmark cases which you want to explore building a faster or more precise analysis for.

It is possible to choose your own custom project. Talk to the teacher, if you are interested.

Proposal §3.2

Before starting on the project, you have to hand in a project proposal. The project proposal is 1 - 2 pages and correspond roughly to the introduction of your final paper. It should formatted using the ACM small format, and will be evaluated according to the CGIE model, and graded 0-4:

• Context: what is the problem?

• Gap: why does the current techniques not work?

• Innovation: what is your proposed solution?

• Evaluation: when have you solved the problem?

• Plan: what is the plan?

• Presentation: is it presented nicely?

You need to score at least 12 points and none of the parameters can be 0. If your proposal are rejected you have to resubmit (even after the deadline). The proposals are graded as you submit them, so you do not have to wait to the last day.

Written Answers §4.1

In the end of the course, your feedback group must hand in a single PDF, with written answers to of all the Questions (§2.5) asked in class. The answers will be graded on correctness, and account for no more than 10% of the final grade.

Technical Contributions §4.2

Additionally to the Paper (§4.3), your project group also must hand in a single A4 page, containing the name, student number and images of each of the students in the group, and table summarizing the technical contributions of each of the group members.

The table, should have a row for each technical contribution. They should contain the contribution, the points it is worth, and how the points should be distributed between the students.

See 🗒 Technical Contributions.

Finally, the numbers are tallied up and used to calculate a maximal grade, each student can get. The grades are calculated from this table (subject to change):

Paper §4.3

The paper should be at most 10 pages, excluding references. It must be formatted using the ACM format in acmsmall mode. To be sure to adhere to the format.

Before you continue writing the paper, consider the advice in this lecture, by Simon Peyton Jones.

The final paper should contain the following sections (approximate page numbers in parentheses):

• An abstract, describing the paper.

• An introduction (1-2 pages), with

  • a good motivation and description of the problem you are trying to solve (consider using examples),

  • the problem stated as a research question,

  • a short description of your solution, and

  • a list of contributions with forward references, described in the lecture by Simon P. Jones.

• An example illustrating your approach (1-2 pages).

• An approach and theory section: high level description of the technique used to analyze (2-3 pages), with

  • a formal description of the approach;

  • a walkthrough of the theory needed to understand the technique; and

  • any theoretical guarantees of the approach.

• An evaluation section, describing the evaluation and the results (2-3 pages), with

  • an empirical evaluation of the approach,

  • compared against at least one other technique (or variations (optimizations) of your technique),

  • an analysis of the results, and

  • a discussion of the threats to validity.

• A related work section, discussion of the technique, and alternatives techniques to solve the same problem (1 - 2 pages), with

  • an explanation why other techniques from the lectures (and potentially the literature) were not used.

• A conclusion (0 - 1/2 page), which is

  • A short recap of the paper.

Video Presentation §4.4

The day before the first exam your group has to hand in a video presentation of your project. It should highlight the project you have done and help start a conversation about your project. It can be no longer than 5 min.

Oral Defence §4.5

Finally, the projects are defended orally in a group exam.

The presentation plan is still being worked out. But expect ~30 minutes per group starting with the 5 minutes video presentation, and ending in individual questioning

The questions are to your technical contributions in the project as well as the course material in general, especially the Questions (§2.5).

Proceedings §4.6

After the exams, we will collect the papers on a voluntary basis in a proceedings, which is shared among the participating students and with the students of the classes years to come. Furthermore, every semester, we will assign a paper the best paper award, which will be indicated in the proceedings.

You can find the proceedings from last year on Learn.