¹⁾

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 ici.

Objectifs de ce cours

Cette année, 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.

Par exemple,

• Comprendre que le code est le résultat d'une gestion de projets, d'une organisation;
• Savoir rechercher des “patterns” dans des codes et découvrir la puissance des approches “méta”;
• Mieux appréhender les difficultés liées à la maintenance des codes;
• Savoir utiliser des outils pour “voir” les codes.

Pour cela, la démarche globale du cours s'appuiera sur de l'auto-apprentissage et du partage de connaissances :

1. Les interventions visent à partager aux étudiants des outils et problématiques différentes de ce dont ils ont l'habitude,
2. 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.

1. 06 décembre
   • Introduction (Problématique, Organisation du Module, Choix des sujets)
   • Découverte des sujets proposés (Discussions)
2. 13 décembre
   • Détection d'“anti-patrons” et impacts sur les performances par Naouel Moha UQAM
     • Supports de cours :
       • Anti-Patrons
       • Détection et analyse de l’impact des défauts de code dans les applications mobiles
   • Travail sur les sujets proposés : rendu L.1.
3. 03 janvier
   • Spoon par Sébastien Mosser (Slides)
   • Analyse de codes
4. 10 janvier
   • Comprendre un logiciel en regardant son "histoire" par Xavier Blanc
   • Analyse de codes rendu L.2.
5. 17 janvier
   • de 8h à 10h la séance sera utilisée pour que chaque groupe avance.
   • Présentation étudiants de 10h15 à 12h15
     • Exposé E.1.
6. 24 janvier
   • A la recherche des failles de sécurités : de la la réalité à la théorie (Yves Roudier)
7. 31 janvier
8. 07 février : Examen

1. 06 décembre
   • Découverte des sujets proposés (Discussions)
     1. Formation des équipes de travail
     2. Choix d'un chapitre
     3. Choix d'un sous-chapitre dans les grandes lignes
     4. Préparation de la suite.
2. 13 décembre
   • Analyse du sujet de sous-chapitre choisi
     1. A quelle(s) question(s) voulez-vous répondre?
     2. Quelle(s) étude(s) de cas allez-vous regarder? (Il peut s'agir d'un seul projet sous Git par exemple ou au contraire de comparer plusieurs projets)
     3. Quelle(s) méthode(s) allez-vous suivre a priori ?
     4. Sur quelles références allez-vous a priori vous appuyez?
     5. Quel(s) outil(s) a priori pour supporter votre analyse ?
     6. Quelle répartition du travail dans l'équipe?
     • Rendu L.1.: “Voici mon sujet”
3. 03 janvier
   • Tests des outils choisis ou envisagés
     • comment prévoyez-vous de l'utiliser? A quels questions devrait-il répondre?
     • Quid de l'Installation ?
     • Qualité des retours
     • Difficultés
4. 10 janvier
   • Tests de dgit avec Xavier Blanc.
     • rendu L.2.
5. 17 janvier
   • Présentation & critiques des étudiants : *
     • Exposé E.1. : Partage d'expérience et entre-aide
6. 24 janvier et 31 janvier
   • Analyses de logiciels
   • Rédaction du livre
7. 07 février : Exposé E.2.

Approche inspirée de : https://www.gitbook.com/book/delftswa/desosa2016/details

Le Livre en cours

Forum pour discuter

Les sous-chapitres sont des propositions, mais les étudiants sont invités à en faire d'autres.

1. Introduction
   1. Quelques définitions (Forward Engineering, Reverse Engineering, Reengineering …)
   2. Principes (a priori je fais le choix de ne pas élaborer un plan basé sur ces principes pour favoriser les nouvelles approches)
2. Abstraire
   1. e.g. : Extraire l'architecture/l'organisation d'un logiciel, par exemple Spoon
   2. e.g. : Des versions de produits à une ligne de produits peut -être surhttps://github.com/JetBrains/intellij-communityIntelliJ
3. Fouiller
   1. e.g. : Quelles sont les modifications les plus fréquentes ? Vérifie-t-on dans github par exemple les résultats du sondage?
   2. e.g. : Quelles histoires pour les tests? Quelle est la stabilité des tests? Dépend-elle de la nature des tests?
4. e.g. : Est-ce que les évolutions de codes (ajout de fonctionnalités) sont dirigées par des demandes d'utilisateurs?
   1. e.g. : Comment peut-on analyser la complexité des issues a posteriori ? (attention à bien préciser les questions que l'on se pose).
   2. etc.
5. Evaluer :
   1. e.g. : Oups mon code est-il “secure”?
   2. e.g. : Tel pattern est-il bien respecté?
   3. e.g. : Impacts d'une modification d'API
   4. e.g. : Performance
   5. e.g. : Energy Usage
   6. e.g : What do game developers test in their products?
6. Conclusion 2016-2017

Toute partie du livre comprend ses auteurs.

Exemple de chapitre : Fouiller

1. Introduction :
   1. objectifs globaux : Pourquoi est-on amené en général à fouiller des codes ?
   2. inclus le plan du chapitre composé de toutes les sous-parties et si possible d'une présentation logique de ces sous-parties.
2. Sous-Chapitre
3. Conclusion
   1. les points forts de l'approche
   2. les difficultés
4. Index des outils et références communes

Tous les étudiants participant à un chapitre doivent compléter ces différentes parties

1. Problématique
   1. Une question
      • ex : Evaluez la qualité d'une application en identifiant les anti-patterns;
        • ex : corriger des patterns identifiés“
   2. Motivations, intérêt de cette question, en quoi l'état de l'art justifie de se poser la question
   3. Description détaillée de la question, quelles sont vos critères pour considérer que vous aurez répondu à la question ?
2. Les deux points suivants peuvent être abordés séparément ou itérativement sous la forme d'une suite de sous questions
   1. 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.
   2. 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 …)
3. 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 ²⁾ à 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.

• Rendu L.1.: “Voici mon sujet”
  • Objectifs de ce livrable : Vérifiez que vous avez bien compris votre sujet.
  • Il comprend sous la forme qui vous convient :
    • la question générale
    • pourquoi vous la trouvez intéressante
    • les métriques/outils/… envisagées pour valider ou non la question
    • les articles sur lesquels vous pensez vous baser pour répondre à la question
    • les codes ou les pistes de codes que vous pensez utiliser pour valider votre étude.
  • Il ne faut hésiter à évoquer plusieurs pistes si les choix ne sont pas faits.
  • date limite : 19/12 à 23h59 (mais un rendu avant le 16/12 est tout à fait acceptable). Le rendu se fait via le livre en complétant le chapitre avec ces informations.
• Rendu L.2. : Retour d'expériences sur les outils,
  • Objectifs de ce livrable : Vérifiez que votre démarche est cohérente et que vous savez utiliser des outils.
  • il reprend les différents points évoqués dans les 2 séances précédentes.
  • date limite : 15/1 à 23h59 dans le livre dans le folder Documents/Background on tools
  • Le rendu explicite :
    • les questions auxquelles vous voulez répondre et votre utilisation des outils en cours et prévue
    • les premiers résultats obtenus
    • les difficultés rencontrées
• Exposé E.1. : Partage d'expérience et entre-aide
  • Objectifs de cet exposé : Poser les bases des chapitres et sous-chapitres en alignant les vocabulaires, principes, etc.
  • Chaque groupe a droit à 3 transparents maximum pour 5mn d'exposés, à rendre par mail le 16/1, à 21h au plus tard.
    1. la question qu'il se pose
    2. les outils et la méthode qu'il a choisis pour y répondre
    3. les difficultés rencontrées et les résultats si vous en avez
  • le 17/1 chaque groupe a 5mn d'exposé sur la base des transparents envoyés la veille au plus tard, et la salle a 5mn de questions par exposés, pour poser des questions et demander des éclaircissements.
    • L'exposé est évalué.
  • Chaque groupe élabore un ensemble de questions à destination de chaque autre sous-groupe, qu'il envoie par mail.
    • Ces questions seront évaluées.
    • Elles seront ensuite postées sur Piazza.
• Exposé E.2 : Bilan de compétences.
  1. Exposé organisé à la convenance des Chapitres
  2. Ouvert à un pannel d'experts précisés ultérieurement
  3. 10mn d'exposé, 10mn de questions par groupe : 20mn par groupe.
  4. Date : 7 février de 8 à 10h30
• Rendu L.3.1 : Contenu du livre
  • Evaluation par plusieurs relecteurs extérieurs
  • Critères d'évaluation :
    • Méthode suivie et argumentaire
    • Rédaction
    • Résultats
      • Recul et Pertinence des remarques
      • Date limite : 14 février à 23h59
• Rendu L.3.2 : Codes/Resultats Brutes/
  • Livrable en fonction des artefacts utilisés, l'objectif est de rendre l'expérimentation reproductible.
  • Date limite : 14 février à 23h59

Pour 2018 ⇒ beaucoup d'articles dans ASE 2016

Les rubriques sont données à titre indicatif, mais plusieurs des articles peuvent être utilisés dans plusieurs rubriques. Certaines références sont encore partielles (manque auteur, date etc.), cela sera fait ultérieurement.

Si les articles ne sont pas “cliquables” me les demander. Dans vos recherches vous serez surement conduits à regarder d'autres articles. Bien sûr vous y faîtes référence dans votre chapitre.

Les rubriques sont là pour vous aider mais un article par exemple en visualisation peut très bien être tout à fait pertinent en fouille de données.

1. “Généralités”
   1. Demeyer S, Ducasse S, Nierstrasz O (2002) Object Oriented Reengineering Patterns. Morgan Kaufmann Publishers Inc., San Francisco, CA, USA
   2. SWEBOK, Chap 5 Maintenance
   3. IEEE Std. 14764-2006 (a.k.a. ISO/IEC 14764:2006) Standard for Software Engineering—Software Life Cycle Processes—Maintenance, IEEE, 2006.
   4. Herraiz I, Rodriguez D, Robles G, Gonzalez-Barahona JM (2013) The Evolution of the Laws of Software Evolution: A Discussion Based on a Systematic Literature Review. ACM Comput Surv 46:28:1--28:28. Excellent !
   5. |Evolving Sofware Vous pouvez vous baser uniquement sur certains articles, mais plus qu'un.
   6. Preliminary Guidelines for Empirical Research in Software Engineering Pour ceux qui se posent des questions sur la méthode d'analyse et si besoin kitchenham2008.pdf
   7. Challenges in Software Evolution

1. Abstraire
   1. Martinez J, Ziadi T, Bissyandé T, Klein J, Le Traon Y (2015) Automating the Extraction of Model-based Software Product Lines from Model Variants. 30th ACM/IEEE Int. Conf. Autom. Softw. Eng. - ASE. ACM/IEEE, Lincoln, Nebraska, United States
2. Fouiller
   1. Khatoon S, Li G, Mahmood A (2013) Comparison and Evaluation of Source Code Mining Tools and Techniques: A Qualitative Approach. Intell Data Anal 17:459–484. doi: 10.3233/IDA-130589
   2. Blondeau V, Etien A, Anquetil N, Sylvain Cresson, Croisy P, Ducasse S (2016) Test Case Selection in Industry: an Analysis of Issues Related to Static Approaches. Softw Qual J. doi: 10.1007/s11219-016-9328-4
   3. Ouni A, Kessentini M, Sahraoui H, Inoue K, Hamdi MS (2015) Improving Multi-objective Code-smells Correction Using Development History. J Syst Softw 105:18–39. doi: 10.1016/j.jss.2015.03.040 (63 pages)
   4. Hebig R, Quang TH, Chaudron MR V, Robles G, Fernandez MA (2016) The Quest for Open Source Projects That Use UML: Mining GitHub. Proc. ACM/IEEE 19th Int. Conf. Model Driven Eng. Lang. Syst. ACM, New York, NY, USA, pp 173–183
   5. Kalenkova AA, van der Aalst WMP, Lomazova IA, Rubin VA (2016) Process Mining Using BPMN: Relating Event Logs and Process Models. Proc. ACM/IEEE 19th Int. Conf. Model Driven Eng. Lang. Syst. ACM, New York, NY, USA, p 123
   6. Hassan AE (2009) Predicting faults using the complexity of code changes. Proc. - Int. Conf. Softw. Eng. pp 78–88
   7. Keisuke Hotta, Yui Sasaki, Yukiko Sano, Yoshiki Higo, and Shinji Kusumoto, “An Empirical Study on the Impact of Duplicate Code,” Advances in Software Engineering, vol. 2012, Article ID 938296, 22 pages, 2012. doi:10.1155/2012/938296
   8. A survey and taxonomy of approaches for mining software repositories in the context of software evolution
   9. Nachiappan Nagappan, Thomas Ball, and Andreas Zeller. 2006. Mining metrics to predict component failures. In Proceedings of the 28th international conference on Software engineering (ICSE '06). ACM, New York, NY, USA, 452-461. DOI=http://dx.doi.org/10.1145/1134285.1134349
   10. Don't touch my code!: examining the effects of ownership on software quality C Bird, N Nagappan, B Murphy, H Gall, P Devanbu - Proceedings of the 19th ACM SIGSOFT symposium …, 2011
3. Evaluer
   1. Foucault M, Palyart M, Blanc X, Murphy GC, Falleri J-R (2015) Impact of Developer Turnover on Quality in Open-source Software. Proc. 2015 10th Jt. Meet. Found. Softw. Eng. ACM, New York, NY, USA, pp 829–841
      • Référence à des outils
   2. Hora A, Robbes R, Anquetil N, Etien A, Ducasse S, Valente MT (2015) How do developers react to API evolution? the Pharo ecosystem case. 2015 IEEE 31st Int. Conf. Softw. Maint. Evol. ICSME 2015 - Proc. Institute of Electrical and Electronics Engineers Inc., pp 251–260
   3. Silva LL, Valente MT, Maia M, Anquetil N (2015) Developers’ Perception of Co-Change Patterns: An Empirical Study. Proc. 31st IEEE Int. Conf. Softw. Maint.
   4. Geoffrey Hecht, Naouel Moha, Romain Rouvoy: An empirical study of the performance impacts of Android code smells. MOBILESoft 2016: 59-69
   5. Hecht G, Benomar O, Rouvoy R, Moha N, Duchien L (2016) Tracking the software quality of android applications along their evolution. Proc. - 2015 30th IEEE/ACM Int. Conf. Autom. Softw. Eng. ASE 2015. Institute of Electrical and Electronics Engineers Inc., pp 236–247
   6. Karina Sokolova, Marc Lemercier, Ludovic Garcia,Android Passive MVC: a novel architecture model for the Android application development, in The Fifth International Conferences on Pervasive Patterns and Applications (PATTERNS 2013), May 27 - June 1, 2013 - Valencia, Spain, vol. , pp. 7
   7. Secure Open Source Collaboration: An Empirical Study of Linus’ Law
   8. Software evolution in open source projects—a large-scale investigation| (Evaluer les Lois de l'évolution)
   9. featuresEmpirical-based recovery and maintenance of input error-correction
4. Visualisation
   1. Benomar O, Sahraoui H, Poulin P (2013) Visualizing software dynamicities with heat maps. Softw. Vis. (VISSOFT), 2013 First IEEE Work. Conf. pp 1–10
   2. http://vissoft16.ysu.edu/program.html (au choix, à discuter, si je peux les avoir)
   3. A Unified Framework for the Comprehension of Software’s Time Dimension
5. Autre
   1. Unbundling Pokémon Go et la masse de documentations sur le reverse de Pokemon Go… A utiliser avec “responsabilité”
   2. Eldad Eilam Reversing - Secrets of Reverse Engineering, Wiley, 2005.

- Avelino G, Passos LT, Hora AC, Valente MT (2017) Assessing Code Authorship: The Case of the Linux Kernel. CoRR abs/1703.0:

- Lal H, Pahwa G (2017) Code review analysis of software system using machine learning techniques. 2017 11th Int. Conf. Intell. Syst. Control. pp 8–13

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.

1. CodeCity is an integrated environment for software analysis, in which software systems are visualized as interactive, navigable 3D cities.
2. Code Maat is a command line tool used to mine and analyze data from version-control systems (VCS).
3. Pour visualiser des codes (a JavaScript library for manipulating documents based on data; get data from code using other tools)
4. 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“.
5. A ruby tool to analyze Git repositories
6. Gitinspector is a statistical analysis tool for git repositories.
7. PAPRIKA is available on 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 contactGeoffrey Hecht
8. 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 here Please do not hesitate to contact me or Yann-Gaël Guéhéneuc if you have any questions/comments.
9. Vos IDE fournissent également des outils directement ou sous la forme de plugins, à vous de voir.

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.

1. The University of Waikato machine learning project WEKA par exemple pour la recherche d'architectures
2. Sur Github junit-team/junit5
3. Android
4. Hibernate
5. A completely clean-room implementation of Minecraft beta 1.7.3 (circa September 2011).
6. nopCommerce is leading ASP.NET based open-source eCommerce platform. à vérifier…
7. https://github.com/scala
8. Sous Github ou autre (bitbucket, sourceForge.net) au choix.. en fonction du sujet
9. Voir aussi dans les questions Spoon, IntelliJ, …

• 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.

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