Cette page présente les ressources du cours de M. Monperrus à la promotion 2015-2016 du master IAGL de l'Université de Lille.
Informations Pratiques
Prérequis: bonne connaissance de la programmation et bases du génie logiciel (test, design).
Horaires des cours: cf Calendrier numérique
Page Moodle: http://moodle.univ-lille1.fr/course/view.php?id=932
Contact: martin.monperrus@univ-lille1.fr
Objectifs du cours
Ce cours a pour objectif l'étude du génie logiciel automatisé, défini comme l'art d'inventer, de designer, d'implémenter et de valider des outils logiciels pour améliorer et/ou automatiser l'ingénierie du logiciel. Au delà de l'objectif technique, ce cours a d'abord pour objectif de vous faire travailler votre méthodologie, votre sens critique, votre créativité, votre écrit, votre oral.
Le cours est organisé autour de 3 thèmes. Chaque thème donne lieu à un projet.
Modalités d'évaluation
Il y aura 3 ou 4 rendus de projets, Chaque projet est un prototypage et une évaluation d'une technique existante ou un développement libre dans le cadre du thème.
Dates des rendus:
11 octobre 2016, 1h du matin
15 novembre 2016, 1h du matin
4 janvier 2017, 1h du matin
13 février 2017, 1h du matin
Le sujet du projet final est libre, sous la seule contrainte de rentrer dans le périmètre du « génie logiciel automatisé ».
Les projets sont notés de la manière suivante:
Excellent travail (20/20)
Très bon travail (17/20)
Bon travail (14/20)
Passable (11/20)
Mauvais (8/20)
Nul (4/20)
Consignes pour les rapports: http://www.monperrus.net/martin/regles-rapport-technique
Les rendus doivent être:
Ou un fichier ZIP (pas de TAR.GZ, RAR ou 7Z) avec le rapport à la racine du ZIP, et le code d'expérimentation. Ils doivent pointer vers un repo Github.
Ou un repo Github. Le README est le rapport.
Rattrapage: Le rattrapage est organisé comme suit. L'étudiant retravaille sur un rendu qui a été noté en dessous de la moyenne, l'étudiant choisit celui à rattraper. Si la moyenne est trop basse, il peut y avoir besoin de rendre 2 nouveaux travaux. Une nouvelle évaluation est faite (et une seule) sur le nouveau code et le nouveau rapport produit, et ce avec le même niveau d'exigence que pendant l'année. La rapport doit commencer par lister le delta avec le précédent rendu: ce qui a été ajouté, enlevé, modifié. Les rendus de rattrapage sont à rendre par email un mois après la fin des cours, c'est à dire le 31 mars 2017, 23:59 cette année. Aucun rendu de rattrapage en retard ne sera considéré.
Première séance
Lire cette page
S'inscrire au cours Moodle http://moodle.univ-lille1.fr/course/view.php?id=932
Lire http://www.monperrus.net/martin/regles-rapport-technique
Lire le rapport d'un des rendus mis à l'honneur en 2014 ou 2015
Executer leur code
Préparer une présentation de 5 minutes à ce sujet (slides dans les slides collectifs – cf Moodle)
Topics 2016-2017
Topic 1: Pull Request Engineering
What is pull-based development? What is a pull request? What is a good pull request? What has to be done to get good pull requests? What tool can help the creation of good pull requests? how to evaluate those tools? How are pull requests used in practice?
Warmup:
Reviewer Recommender of Pull-Requests in GitHub long version demo
Continuous integration in a social-coding world: Empirical evidence from Github
Synthesis of How to write the perfect pull request?, 10 tips for better Pull Requests, Effective pull requests and other good practices for teams using github
Prepare a demo of Github + hooks on PR, eg to count the number of changed files in the PR.
Projects:
An empirical study on Pull Requests (using Ghtorrent or new dataset)
Implement a tool to improve pull request engineering:
Shows diffs using an AST tree diff (instead of a line diff) (eg using gumtree)
Lists all facts of a PR by priority (interface change, new public classes/methods, removed public classes methods, no documentation, non-updated documentation, empty catch blocks)
Creates a PR on the PR to fix Jenkins / PMD / Checkstyle rules
Clone of an existing pull request tool, eg. Quantified Code, ReviewNinja, others.hacksboard
your idea on this topic
Topic 2: Crash Analysis
What is a crash? How to detect it? How to collect it? How to analyze crashes? What to put in crash report? What are the issues related to privacy and law? What is a bucket? What is a stack trace? What are the technical limitations and tradeoffs or crash analysis? Which crash to fix first?
Resources:
Quickly Finding Known Software Problems via Automated Symptom Matching
ReBucket: a method for clustering duplicate crash reports based on call stack similarity
The Unreasonable Effectiveness of Traditional Information Retrieval in Crash Report Deduplication
Topics:
Competition: design and implement the best possible system for crash-to-bucket assignment. Your system trains on "foo-training" and has to predict the bucket ID of each element in "foo-testing". [dataset 1] [dataset 2] [dataset 3]
Development: design and implement a crash crawler for Mozilla crashes. Goal: collect at least 20000 crashes for the two recent consecutive versions of Firefox. The crawler would use the Crash SuperSearch API. Example REST queries: [the list of crash identifiers for a given crashing function], [a specific crash]
Your own idea
Topic 3: Automatic Diagnosis and Repair
What is a bug? What is an oracle? What is automatic repair? What are automatic repair techniques? What is a regression? This year, we will study automatic repair with cause-effect chain analysis and with multi-version execution.
A team will be composed of people with: 1) communication / collaboration skills, 2) implementation skills, 3) reading / writing skills, 4) rigor and testing skills.
Introduction courte http://www.monperrus.net/martin/introduction-to-automatic-software-repair.pdf
Repair with analysis of cause-effect chains. Reference: Isolating Cause-Effect Chains from Computer Programs [core example in Python] The goal is to implement state delta-debugging for Java (using Spoon is a reasonable option). The implementation must have a statement coverage of at least 80% and continuous integration. Competition: to win the competition, each team provides between 1 and 5 example programs and their associated cause-effect chains (see Sec 3.4 of the paper). For each correct trace produced on the other team's example programs, one wins one point. The team with the highest number of points wins. The evaluation section contains at least an analysis of 2 handled cases and 2 unhandled cases and the corresponding explanation. Interfaces: on github
Repair with multi-version execution. Reference: Safe Software Updates via Multi-version Execution, Object level recombination of commodity applications, Coderewinder (IAGL 2015). The goal is to write an application that embeds the history of a software application at runtime (using Spoon is a reasonable option). The implementation must have a statement coverage of at least 80% and continuous integration. The evaluation section is an analysis of how it works on a real Github repository.
Topic 4: You choose it
Projet 1 (pull request engineering)
Sélection de travaux remarquables:
Projet 2 (Crash)
Sélection de travaux remarquables:
Projet 3 (Delta Debugging)
Sélection de travaux remarquables:
Projet libre
Sélection de travaux remarquables:
Tableau d'honneur
Tableau 2014: http://www.monperrus.net/martin/iagl2014
Tableau 2015: http://www.monperrus.net/martin/iagl2015