====== Maintenance du logiciel : Focus sur la rétro-ingénierie ====== ((SOFTWARE MAINTENANCE : From Analysis to Implementation)) Dans la pratique les développeurs sont le plus souvent confrontés à "maintenir" des codes que ce soit pour les comprendre, les adapter, les corriger ou en intégrer de nouveau. Cette étape cruciale dans le cycle de vie du logiciel requiert différentes connaissances, dont certaines seront abordées dans ce cours. Un sondage auquel ont répondu 217 personnes a permis d'établir quelques éléments factuels relativement aux pratiques et besoins des entreprises, voir les résultats brutes [[https://docs.google.com/forms/d/1QdWKLSHfhliOv5K9gbpIoflu5BgiuBsSpxvNzrB6r6A/viewanalytics|ici]]. **Objectifs de ce cours** L'ambition de ce module est de donner aux étudiants une nouvelle vision sur le code, et de fait de leur permettre d'être de meilleurs développeurs et, en fonction des questions posées, de meilleurs chefs de projets ou architectes. Pour cela, la démarche globale du cours s'appuiera sur de l'auto-apprentissage et du partage de connaissances : - Les interventions visent à partager aux étudiants des outils et problématiques différentes de ce dont ils ont l'habitude, - les TDs visent à permettre aux étudiants de se mettre en situation de (i) se poser des questions, (ii) de mettre en place des méthodes pour répondre à ces questions, (iii) d'utiliser des outils pour répondre à ces questions avec quelquefois, des approches très différentes d'une démarche de développement. ===== Intervenants ===== ^ Nom ^ Adresse ^ | __[[blay@unice.fr|Mireille Blay-Fornarino]]__(MBF) | Bâtiment Templiers :Bureau 449 ([[https://mireilleblayfornarino.i3s.unice.fr/]]) | | [[benni@i3s.unice.fr|Benjamin Benni]] (BB) | Bâtiment Templiers Bureau XXX | | [[collet@unice.fr|Philippe Collet]] (PC) |Bâtiment Templiers : Bureau XXX | ====== Planning ====== - mar.18 déc. 2018 * //08:00 – 9:00// : {{:teaching:reverse:2018:introcoursmaintenance_-_2018-19.pdf|Cours - Introduction}} // (MBF)// * //9:00 - 10h00 // : Autonomie * //10:15 – 11:15// : TD - Choix et caractérisation du sujet d'étude //(MBF,BB,PC)// * //11:15 - 12h15 // : Autonomie * lundi 7 janv. 2019 à 15h au plus tard [[teaching:reverse:2018:evaluation|Livrable L.1]] - mar.8 janv. 2019 * //8:00 – 9:00// : Cours - Comprendre un logiciel en regardant son histoire //Xavier Blanc(XB)// (https://promyze.com/) * //9:00 – 11:00// : TD - Compléments sur le sujet en mode "coaching"//(MBF,BB,PC,XB)// * //11:00 – 12:15// : Autonomie - mar.15 janv. 2019 * //08:00 – 09:30// : Cours : Adventure in a Docker world //(BB)// * //09:45 – 12:15// : TD - Validations Métrics/KPI //(MBF, BB)// - mar.22 janv. 2019 * //08:00 – 11:00// : Oral (10mn exposé + 10mn questions) (MBF,BB) [[teaching:reverse:2018:evaluation|Exposé E.1]] - mar.29 janv. 2019 * //08:00 – 11:00// : TD - Travail sur la démarche & Métrics/KPI //à base d'articles// //(BB)// (Hypothétique) * //11:15– 12:15// : Autonomie - mar.5 févr. 2019 * //09:45 – 12:15// : Autonomie - mar.12 févr. 2019 * //08:00 – 9:00// : Intervention d'un industriel * //9:00 – 10:00// : TD - Compléments sur le sujet en mode "coaching"//(MBF,BB,PC)// - mar.19 févr. 2019 . " * Annonce de la sélection des articles utilisés pour l'examen * //08:00 – 11:00// : Autonomie - mar.26 févr. 2019 * //09:00 – 11:00// : Examen - mer. 27 févr. 2019 * [[ teaching:reverse:2018:evaluation|Livrable L.2 & Livrable L.3]] ====== Evaluation du module ====== Les étudiants forment des groupes d'au maximum 4 étudiants. Il y a maximum 10 groupes. La communication passe par Slack **[[teaching:reverse:2018:Evaluation|Livrables du module : détails]]** ===== Ecriture collaborative d'un livre sur "Apprendre du code" ===== Approche inspirée de : https://www.gitbook.com/book/delftswa/desosa2016/details [[https://uca-students-on-software-mainten.gitbook.io/project/|Le Livre en cours]] Il contient un exemple de chapitre de l'an dernier et le format attendu pour cette année. ==== Propositions de sujets d'étude ==== Vous avez la possibilité de proposer d'autres sujets d'études. Pensez cependant à bien les faire valider avant de vous lancer dans les études. Nous n'avons pas proposé de sujets que sur l'analyse des codes sans proposer de sujets portant sur la maintenance elle-même (corrective, perfective, ...). Il est cependant possible de proposer un tel sujet, mais en prenant bien en compte la complexité et la durée de la tâche relativement au temps accordé à ce module. [[https://docs.google.com/document/d/1sOF83CfzLCDqC4iwfQjpRIrnt1-wz4ft54pHUTW0B-8/edit?usp=sharing| Propositions de sujets ]] /* ===== Structure du livre ===== @todo? ===== Patron par Chapitre ===== Un chapitre par groupe. - **Problématique** - Une //question// * ex : //Evaluez la qualité d'une application en identifiant les anti-patterns;// * ex : // corriger des patterns identifiés"// - Motivations, intérêt de cette question, en quoi l'état de l'art justifie de se poser la question - Description détaillée de la question, quelles sont vos critères pour considérer que vous aurez répondu à la question ? - Les deux points suivants peuvent être abordés séparément ou itérativement sous la forme d'une suite de sous questions - **Principes** : * vous pouvez vous aider de la décomposition : extraction du modèles, transformation de codes, détection de problème, résolution, ...) par exemple, //Définir ce que sont les anti-patterns; exécuter et obtenir....; visulaisez sous la forme de courbes; de reférence aux codes; // * Descriptions d'outils/ cas d'utilisation/ Codes; Pourquoi ceux là? * Vos attentes. - **Résultats** * Résultats bruts (ex : on a identifié x problèmes dans les modules A et B; visualisation) * Analyse des résultats (ex : il s'agissait de 2 anti-patterns et de 3 faux positifs; on voit que ...) - Analyse critique, Perspectives, ... * ex : est-ce dépendant d'ANdroid? Est-ce vraiment des anti-patterns Vous devez étayer votre sous-chapitre en faisant référence ((c'est à dire expliquer ce que vous avez retenu de l'article, en quoi vous vous en différencier éventuellement, etc)) à au moins 3 des références données ci-dessous. Vous pouvez ajouter des références, évidemment, et si besoin demander à en prendre en compte d'autres non prévues, mais avec l'accord de l'enseignant. @todo donner un template dans le livre */ ====== Références ====== Voici quelques proposition d'articles. Vous pouvez proposer d'autres articles, mais dans ce cas, les faire valider par les enseignants. **[[teaching:reverse:2018:references|Références]]** ====== Outils ====== Attention, il ne s'agit pas de donner une liste exhaustive d'outils mais de donner des exemples d'outils glanés au fil des lectures. - https://github.com/mauricioaniche/repodriller - [[http://wettel.github.io/codecity-download.html|CodeCity is an integrated environment for software analysis, in which software systems are visualized as interactive, navigable 3D cities.]] - [[https://github.com/adamtornhill/code-maat| Code Maat is a command line tool used to mine and analyze data from version-control systems (VCS).]] -[[ https://d3js.org/|Pour visualiser des codes (a JavaScript library for manipulating documents based on data; get data from code using other tools)]] -[[http://reveal.inf.usi.ch/web/dambros/tools/evoradar.php#|The Evolution Radar]] is a tool for analyzing the evolution of software systems from the logical coupling perspectives. Attention nécessite de charger " HotDraw graphical framework". - [[https://github.com/jrfaller/diggit|A ruby tool to analyze Git repositories]] - [[ https://github.com/ejwa/gitinspector|Gitinspector is a statistical analysis tool for git repositories.]] - PAPRIKA is available on [[https://github.com/SOMCA/paprika or https://github.com/GeoffreyHecht/paprika|Github]]. It's just a java project so there should be no problem to compile it, however an executable jar is available in out/artifacts/Paprika_jar . You will need the android platforms (sdk) installed on your computer depending of the Android SDK of the analysed apps. You can find some of them here : https://github.com/Sable/android-platforms. You can analyse apps and detects code smells as presented in the readme. However if something is not clear or does not work properly, you can contact[[geoffrey.hecht@gmail.com|Geoffrey Hecht]] - DECOR: It would be my pleasure to give you access to our code but first you must agree that it must be used only for research purposes. If you do agree, then please have a look into http://www.ptidej.net/material/development/ and http://wiki.ptidej.net/doku.php The Git repository is available [[https://bitbucket.org/ptidejteam/ptidej-5|here]] Please do not hesitate to contact [[naouel@gmail.com|me]] or [[yann-gael.gueheneuc@polymtl.ca|Yann-Gaël Guéhéneuc]] if you have any questions/comments. - CodeScene’s analyses are completely automated, and the tool is available as an [[https://empear.com/pricing/|on-premise version]] and as a hosted [[https://codescene.io/projects|CodeScene Cloud]]. -Vos IDE fournissent également des outils directement ou sous la forme de plugins, à vous de voir. /* -http://colorbrewer2.org/ mais pas sur... */ /* ====== Exemples de codes pouvant servir à l'analyse ====== En fonction de la question que vous vous posez, vous ne regardez pas forcément les mêmes codes. Voici quelques suggestions, mais vous pouvez en proposer d'autres. Dans tous les cas, on veut pouvoir "reproduire" vos expérimentations, c'est pourquoi du code "non publique", ne pourra pas servir de tests sauf cas particulier où en complément à une étude reproductible. - [[https://github.com/bnjmn/weka/|The University of Waikato machine learning project WEKA ]] par exemple pour la recherche d'architectures - Sur Github junit-team/junit5 - [[http://source.android.com/index.html|Android]] -[[ https://github.com/hibernate/hibernate-orm|Hibernate]] -[[https://github.com/SirCmpwn/TrueCraft/blob/master/README.md|A completely clean-room implementation of Minecraft beta 1.7.3 (circa September 2011). ]] -[[http://www.nopcommerce.com/|nopCommerce is leading ASP.NET based open-source eCommerce platform. ]] à vérifier... -https://github.com/scala -Sous Github ou autre (bitbucket, sourceForge.net) au choix.. en fonction du sujet -Voir aussi dans les questions Spoon, IntelliJ, ... */ ====== Hypothèses et Limites ====== === Hypothèses === * Les DP sont connus * Les bases de la notion d'architectures logicielles sont acquises * Les étudiants savent ce qu'est un "modèle" et ont des capacités d'abstraction * Les étudiants sont des développeurs. === Sujets non traités par choix === Comme il n'est pas possible de tout analyser sur 8 semaines, voici au moins les aspects que nous avons fait le choix de ne pas traiter : * Idioms pour un code plus facilement maintenanable (pas directement en tous cas...) * Reverse for disassembled binary files * https://www.zynamics.com/bindiff.html * Reverse for illegal activities * http://securityaffairs.co/wordpress/46606/hacking/software-reverse-engineering-process-basics.html ====== ARCHIVES ====== * [[https://mireilleblayfornarino.i3s.unice.fr/doku.php?id=teaching:reverse:2017|2017-2018]] * [[https://mireilleblayfornarino.i3s.unice.fr/doku.php?id=teaching:reverse:2016|2016-2017]] * Retours d'expérience sur le module lors des journées du GDR Génie de la Programmation et du Logiciel : * {{:teaching:reverse:2017:articleciel2017.pdf|article}} et {{:teaching:reverse:2017:rimel-ciel.pdf|exposé}} * {{:teaching:reverse:2018:examrimel2018.pdf|examen en 2018}} et {{:teaching:reverse:2018:an_appropriate_use_of_metrics.pdf|article}}