« October 2018 »
October
MoTuWeThFrSaSu
1234567
891011121314
15161718192021
22232425262728
293031
Uni-Logo
You are here: Home Teaching Winter Term 2018/19 Program Analysis (Seminar)
Document Actions

Program Analysis

Program analysis is the research area that studies the automatic analysis of computer programs. The methods that are developed in this research area, e.g., help programmers to understand complex programs, allow compilers to optimize their code, and enable computers to check the correctness of programs. In this seminar each student will study a research paper and give a talk in which he/she presents a summary of the paper.

Course type Seminar
Instructors Alexander Nutz (contact person for organisational matters),
Prof. Dr. Andreas Podelski, Dr. Daniel Dietsch, Dr. Matthias Heizmann, Dr. Jochen Hoenicke, Marius Greitschus, Vincent Langenfeld, Tanja Schindler
Kick-off meeting
Thu, October 18, 13:00 s.t., building 052, room 00-016
Presentation language
English
Credits
4
Course Catalog Program Analysis
 Talk dates:
tbd
 Room for the talks:
tbd

News and announcements

 (18.10.2018): If you want to participate, please send an E-mail to Alexander Nutz until next Thursday (25.10.2018). The e-mail should contain

    • Your preferred topics. Please give at least three. You may give priorities.
    • Your preferred time slots for the weekly seminar. Choices are Tuesday 16-18 and Wednesday 12-14. Could you attend at both? One of them? Neither?
    • Your preferences on when you would like you talk to be, if you have any, like "right at the start" or "as late as possible" -- we will try to accomodate them.

      After we have received you wishes, we will assign the topics and set the dates for all the deadlines and talks. All of this will be announced on this website. If you have questions or wishes, please write us an e-mail. 

      Descriptions of all available topics should be online on this site from Saturday (20.10.) on.

    • We fixed the kick-off meeting appointment (see above).

    Process of the seminar

    • You participate in the kick-off meeting, where we present the available topics. Feel free to hand in your favorite topic in advance.
    • You contact the instructors to obtain a topic. You may suggest a topic by yourself, pick one of the suggested topics, or find a topic suitable for you in a discussion with your supervisor.
    • You have a meeting with your supervisor in which we discuss relevant literature and develop a very coarse sketch of your talk (deadline: four weeks before your talk).
    • You write a proposal in which you explain what you are going to present in your talk, together with an abstract of your talk. You submit your abstract and your proposal via email to your supervisor (deadline: three weeks before your talk).
    • Your proposal is reviewed by your supervisor and two other participants.
    • You write two reviews about other participants' proposals and send them via email to the supervisor (deadline: one week after you received the proposal).
    • You receive reviews for your proposal (deadline: two weeks before your talk).
    • You submit your slides via email to your supervisor (deadline: one week before your talk).
    • You have a meeting with your supervisor in which you get feedback for your slides.
    • You give a talk of 30 minutes.
    • You attend the talks of all other participants.

    Proposals of the talk

    The proposal should consist of around five pages in which you explain what you are going to present in your talk. The proposal may contain for instance:

    • short overview for the reviewers (the reviewers will probably not know your topic)
    • structure of your talk
    • aspects of the topic that you present (why?) and ignore (why?)
    • examples occurring in the talk (why these examples? Is there a running example that can be used for demonstration?)
    • which definitions are presented formally? (why?), which definitions are just mentioned informally? (why?)
    • which notation is used? (why?)
    • which theorems are presented, which of them will be proven (why?), which proofs will be omitted (why?), will you use motivating examples in the proof?

    Abstract of the talk

    • one paragraph that summarizes what you present in the talk
    • We will send an invitation for the seminar to all students and members of our chair. This invitation contains the abstracts of all talks.

    The talk

    • The goal of your talk is that the audience (master students, familiar with computer science in general, probably no experts in the topic) has the possibility to learn something new about an interesting topic. How well you achieved this goal will determine the grade of your talk.
    • In a seminar you have to show that you are able to present some topic to other people. You do not have to show how well you understood the topic for yourself. How well you understood the topic has no direct influence on your grade, but only how well you presented the topic to the audience.
    • You may use and copy any source of information (but do not forget to cite it). If you think your talk is just a "remix" of existing talks tailored to your audience, you might have done a great job. But do not let yourself be fooled by well-structured and fancy talks found in the web, each talk was tailored to a specific audience.
    • If you agree we put your slides on this website. Keep in mind that if you have copied images in your slides this might not be possible anymore (copyright restrictions). Of course, it will not have any effect on your grade whether we may publish your slides or not.

    Review of the proposal

    • Give a short summary of the talk based on the proposal (to detect misunderstandings right at the start).
    • Be generous with your criticism. It is very unlikely that a student will get a bad grade because you revealed some problems in his/her proposal. However, it is very likely that a student will get a better grade if he/she was able to resolve a problem in his/her talk, thanks to your review.
    • Give reasons for your criticism (e.g., "It is not possible to understand Lemma 2 because term foo was not explained.").  You are also allowed to give your personal opinions, if you do so mark them as such (e.g., "Theorem 1 is very difficult to understand, in my opinion you should give an example first.").
    • The following questions might be helpful to write your review
    Is the proposal sufficiently well written to be readable?
    Is the appearance and structure of the proposal appropriate?
    Is the comprehensibility of the talk supported by relevant examples and figures?
    Is the proposed structure of the talk sensible and balanced?
    Are all propositions made by the author correct?
    Is the line of reasoning concerning the presentation complete and accurate?
    Has the author argued his/her case effectively?
    Does the author use the common notation and terminology? Where would you suggest something different?
    Is the schedule of the author sensible? Do you think the talk will fit into the 30 min time slot?

    Grade

    Your overall grade will be composed according to the following proportion.

    • 10% grade of your proposal
    • 20% grade of your reviews
    • 70% grade of your talk

    Topics

    There is not a one-to-one correspondence between seminar talks and topics. Several students may give talks on the same topic, but present different aspects. The suggested literature should give you a first impression of the topics. We assign the exact literature in cooperation with you after you stated your preferences for the topic. More literature does not mean more reading, just more options. The order of appearance roughly represents the order in which it would make sense to present the topics.

    If requested, some topics may also be presented in groups of two.

    Some of the papers are only available via the network of our university (e.g., via vpn). If you have some problem accessing the papers, please ask us.

     

    Checking Verification Conditions

    When the program is annotated with (suitable) loop invariants, the verification problem can be reduced to passing verification conditions to a (first-order) theorem prover. There are better and wose ways to do this.

    Abstract Interpretation

    Introductory talk to a technique that has inspired hundreds of papers. An abstraction is a class of logical formulas that abstracts away from some properties of the program. An abstract interpretation of a program describes the behaviour of a program in terms such an abstraction.

    www.cs.tau.ac.il/~msagiv/courses/asv/absint-1.pdf

    Automata-Based Model Checking

    Using (finite) automata to decompose software model checking problems into smaller problems. Approach used in Ultimate Automizer.

    Software Model Checking for People who love Automata

    Bounded Model Checking

    Programs with loops typically have an unbounded number of paths from the initial location to the error location because a loop may be unrolled indefinitely. Bounded model checking fixes a bound for the unrolling and check all verification conditions up to that bound.

     Bounded Model Checking (Lecture)

    Predicate Abstraction

    Abstraction is a technique that omits details from program behaviour in order to reduce the state space that one must reason about in order to verify the program. An abstraction can be characterized by logical predicates (formulas).

    Interpolation

    One major difficulty in program verification is coming up with suitable loop invariants. Craig interpolation is a technique that can provide good candidate formulas by analyzing why a given abstraction of the program is too coarse.

       citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.84.4733&rep=rep1...pdf

     Conditional Verifiers

    Often, verifiers are specialists, i.e., they are good in verifying one class of programs but not another one. Conditional verifiers allow partial verification tasks to be passed between verifiers.

    Loop Shrinking

    Loops that contain arrays are particulary hard to verify. Sometimes, not all array updates must be taken into consideration for verification. Loop shrinking attempts to reduce the loop iterations dramatically by only updating representative array cells.

    Property Checking Array Programs Using Loop Shrinking

     

    Schedule

    Each topic/talk will have a slot letter (A, B, C, D) assigned.

    Each seminar student has to write reviews for two other students as assigned above.

    The following table contains the deadlines for the groups. Please note that "Review" stands for the review deadline for the specific group's proposals. For example if you are reviewing someone in group B, you should receive the proposal on (tbd) and send back your review on (tbd) (at the latest, the earlier the better for your reviewee) -- regardless of which group your own topic is in.

     
    Date Proposal Review Slides Talk
    tbd

     
     

    Additional Material

    Here you find the introductory talk from a past semester. [slides] [video]

     
    Personal tools