User Tools

Site Tools


teaching:reverse:2017:start

This is an old revision of the document!


Maintenance du logiciel : Focus sur la rétro-ingénierie

1)

Introduction

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

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 :

  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.

Intervenants

Nom Adresse
Mireille Blay-Fornarino(MBF) Bâtiment Templiers :Bureau 449 (https://mireilleblayfornarino.i3s.unice.fr/)
Sébastien Mosser (SM) Bâtiment Templiers Bureau XXX
Philippe Collet (SL) Bâtiment Templiers : Bureau XXX

Planning

  1. mar.19 déc. 2017
    • 08:00 – 10:00 : Cours - Introduction (MBF)
    • 10:00 - 11h00 : Autonomie
    • 11:15 – 12:15 : TD - Choix et caractérisation du sujet d'étude (MBF,SM,PC)
    • lundi 8 janv. 2018 à 15h au plus tard Livrable L.1
  2. mar.9 janv. 2018
    • 8:00 – 9:00 : TD - Compléments sur le sujet en mode “coaching” (MBF,SM,PC)
    • 9:00 – 10:00 : TD - Compléments sur le sujet en mode “coaching” (MBF)
    • 10:00 – 12:15 : Autonomie
  3. mar.16 janv. 2018
    • 08:00 – 09:30 : Cours - Comprendre un logiciel en regardant son histoire Xavier Blanc(XB)
    • 09:45 – 12:15 : TD - Validations Métrics/KPI (MBF,XB)
  4. mar.23 janv. 2018
    • 08:00 – 11:00 : Oral (10mn exposé + 10mn questions) (MBF,PC) Exposé E.1
  5. mar.30 janv. 2018
    • Remise des articles à avoir lu pour l'examen
    • 09:45 – 12:15 : Autonomie Livrable L.3
  6. mar.6 févr. 2018
    • 08:00 – 10:00 : TD - Travail sur les choix d'articles, démarche & Métrics/KPI (SM,PC)
    • 09:45 – 12:15 : Autonomie Livrable L.2 & L.4
  7. mar.13 févr. 2018
    • 08:00 – 9:00 : Intervention d'un industriel
  8. mar.20 févr. 2018
    • 08:00 – 11:00 : Autonomie
  9. mar.27 févr. 2018
    • 08:00 – 11:00 : Examen Livrable L.5 & Livrable 6

Evaluation du module

Les étudiants forment des groupes d'au maximum 4 étudiants.

Il y a maximum 10 groupes.

La communication passe par Slack

Livrables du module

    • Objectifs de ce livrable : Vérifier que vous avez identifié votre sujet et les questions associées.
    • Il comprend sous la forme qui vous convient :
      1. la question générale & pourquoi vous la trouvez intéressante
        1. la décomposition en sous-questions et les métriques/KPI/outils **envisagés** pour y répondre
        2. la démarche prévue
        3. les 2 articles au moins sur lesquels vous pensez vous baser pour répondre à la question. Un doit se trouver dans la rubrique généralité, un autre dans la rubrique études. Vous pouvez avoir vous-même suggéré des articles dans ces 2 rubriques. Dans ce cas, ils doivent être validés par les enseignants.
        • Il ne faut hésiter à évoquer plusieurs pistes si les choix ne sont pas faits.
      2. Chaque groupe a créé un chapitre dans le livre précisant les auteurs, et chaque auteur est bien "associé" au livre
    • date limite : 8/01 à 15h. Le rendu se fait sur Slack.
    • Objectifs de ce livrable : Evaluer l'avancement des projets et préparer la phase en autonomie
      1. 10mn d'exposé, 10mn de questions par groupe : 20mn par groupe.
      2. Date : 23 janvier de 8h à 12h00
      3. Utilisation de Slack pour partager les questions du groupe aux différents sous-projets
    • @todo a revoir
    • 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 : 27 février à 23h59
    • Livrable en fonction des artefacts utilisés, l'objectif est de rendre l'expérimentation reproductible.
    • Date limite : 27 février à 23h59
    • Date : 27 février @todo forme à préiciser

Ecriture collaborative d'un livre sur "Apprendre du code"

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

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.

Propositions de sujet

Références

Voici quelques proposition d'articles. Vous pouvez proposer d'autres articles, mais dans ce cas, les faire valider par les enseignants.

Références

Généralités

Articles généraux présentant les principes de RIMEL

    • Auteurs Alain Abran, James W Moore, Pierre Bourque, Robert Dupuis, Leonard L Tripp
    • Date de publication 2004
    • Guide to the software engineering body of knowledge: 2004 version SWEBOK (chapitre sofware Maintenance)
  1. IEEE Std. 14764-2006 (a.k.a. ISO/IEC 14764:2006) Standard for Software Engineering—Software Life Cycle Processes—Maintenance, IEEE, 2006.
  2. Demeyer S, Ducasse S, Nierstrasz O (2002) Object Oriented Reengineering Patterns. Morgan Kaufmann Publishers Inc., San Francisco, CA, USA

Etudes

Sélection d'articles présentant des études de rétro-ingénierie

    • Authors : Georgios Digkas, Mircea Lungu, Alexander Chatzigeorgiou, Paris Avgeriou
    • Publication date : 2017/9/11
    • Conference European Conference on Software Architecture
    • Pages 51-66
    • Description :
      • Software systems must evolve over time or become increasingly irrelevant says one of Lehman's laws of software evolution. Many studies have been presented in the literature that investigate the evolution of software systems but few have focused on the evolution of technical debt. In this paper we study sixty-six Java open-source software projects from the Apache ecosystem focusing on the evolution of technical debt. We analyze the evolution of these systems over the past five years at the temporal granularity level of weekly …
    • Authors : Andrea Caracciolo, Mircea Lungu, Oskar Truffer, Kirill Levitin, Oscar Nierstrasz
    • Publication date : 2016/3/13
    • Conference Empirical Software Engineering in Practice (IWESEP), 2016 7th International Workshop on
    • Pages 41-44
    • Description
      • Architectural rules are often defined but rarely tested. Current tools offer limited functionality and often require significant effort to be configured, automated and integrated within existing platforms. We propose a platform that is aimed at reducing the overall cost of setting up and maintaining an architectural conformance monitoring environment by decoupling the conceptual representation of a user-defined rule from its technical specification prescribed by the underlying analysis tools. The user is no longer expected …
    • Authors : Yangyang Zhao, Alexander Serebrenik, Yuming Zhou, Vladimir Filkov, Bogdan Vasilescu
    • Date de publication 2017
    • Conférence ASE
    • Description
      • Continuous Integration (CI) has become a disruptive innovation in software development: with proper tool support and adoption, positive effects have been demonstrated for pull request throughput and scaling up of project sizes. As any other innovation, adopting CI implies adapting existing practices in order to take full advantage of its potential, and“ best practices” to that end have been proposed. Here we study the adaptation and evolution of code writing and submission, issue and pull request closing …
    • Auteurs : Matheus Paixao, Jens Krinke, DongGyun Han, Chaiyong Ragkhitwetsagul, Mark Harman
    • Date de publication 2017/10/30
    • Conférence Proceedings of the 32nd IEEE/ACM International Conference on Automated Software Engineering
    • Pages 95-105
    • Description :
      • Although considered one of the most important decisions in a software development lifecycle, empirical evidence on how developers perform and perceive architectural changes is still scarce. Given the large implications of architectural decisions, we do not know whether developers are aware of their changes' impact on the software's architecture, whether awareness leads to better changes, and whether automatically making developers aware would prevent degradation. Therefore, we use code review data of 4 …
    • Auteurs : Yun Lin, Guozhu Meng, Yinxing Xue, Zhenchang Xing, Jun Sun, Xin Peng, Yang Liu, Wenyun Zhao, Jinsong Dong
    • Date de publication : 2017/10
    • Conférence The 32nd IEEE/ACM International Conference on Automated Software Engineering
    • Pages 394–404
    • Description
      • In this paper, we propose an approach to detecting project-specific recurring designs in code base and abstracting them into design templates as reuse opportunities. The mined templates allow programmers to make further customization for generating new code. The generated code involves the code skeleton of recurring design as well as the semi-implemented code bodies annotated with comments to remind programmers of necessary modification. We implemented our approach as an Eclipse plugin called …
    • Auteurs Vincent Blondeau, Anne Etien, Nicolas Anquetil, Sylvain Cresson, Pascal Croisy, Stéphane Ducasse
    • Date de publication 2016
    • Revue Software Quality Journal
    • Pages 1-35
    • Description :
      • Automatic testing constitutes an important part of everyday development practice. Worldline, a major IT company, is creating more and more tests to ensure the good behavior of its applications and gains in efficiency and quality. But running all these tests may take hours. This is especially true for large systems involving, for example, the deployment of a web server or communication with a database. For this reason, tests are not launched as often as they should be and are mostly run at night. The company wishes to improve its …
    • Auteurs: Regina Hebig, Truong Ho Quang, Michel RV Chaudron, Gregorio Robles, Miguel Angel Fernandez
    • Date de publication : 2016/10/2
    • Conférence Proceedings of the ACM/IEEE 19th International Conference on Model Driven Engineering Languages and Systems
    • Pages 173-183
    • Description
      • Context: While industrial use of UML was studied intensely, little is known about UML use in Free/Open Source Software (FOSS) projects. Goal: We aim at systematically mining GitHub projects to answer the question when models, if used, are created and updated throughout the whole project's life-span. Method: We present a semi-automated approach to collect UML stored in images,. xmi, and. uml files and scanned ten percent of all GitHub projects (1.24 million). Our focus was on number and role of contributors that …
    • Auteurs Guilherme Avelino, Leonardo Passos, Andre Hora, Marco Tulio Valente
    • Date de publication 2017/5/22
    • Conférence IFIP International Conference on Open Source Systems
    • Pages 151-163
    • Description
      • Code authorship is a key information in large-scale open-source systems. Among others, it allows maintainers to assess division of work and identify key collaborators. Interestingly, open-source communities lack guidelines on how to manage authorship. This could be mitigated by setting to build an empirical body of knowledge on how authorship-related measures evolve in successful open-source communities. Towards that direction, we perform a case study on the Linux kernel. Our results show that:(a) only a small portion of …
    • Auteurs Andrew Meneely, Laurie Williams
    • Date de publication 2009/11/9
    • Conférence Proceedings of the 16th ACM conference on Computer and communications security
    • Pages 453-462
    • Description : Open source software is often considered to be secure. One factor in this confidence in the security of open source software lies in leveraging large developer communities to find vulnerabilities in the code. Eric Raymond declares Linus' Law“ Given enough eyeballs, all bugs are shallow.” Does Linus' Law hold up ad infinitum? Or, can the multitude of developers become“ too many cooks in the kitchen”, causing the system's security to suffer as a result? In this study, we examine the security of an open source …
    • Auteurs : Sarra Habchi, Geoffrey Hecht, Romain Rouvoy, Naouel Moha
    • Date de publication : 2017/5/20
    • Conférence : Proceedings of the 4th International Conference on Mobile Software Engineering and Systems
    • Pages : 110-121
    • Description
      • With billions of app downloads, the Apple App Store and Google Play Store succeeded to conquer mobile devices. However, this success also challenges app developers to publish high-quality apps to keep attracting and satisfying end-users. In particular, taming the ever-growing complexity of mobile apps to cope with maintenance and evolution tasks under such a pressure may lead to bad development choices. While these bad choices, aka code smells, are widely studied in object-oriented software, their study …
  1. (Non disponible en ligne…) Code review analysis of software system using machine learning techniques
    • Auteurs Harsh Lal, Gaurav Pahwa
    • Date de publication 2017/1/5
    • Conférence Intelligent Systems and Control (ISCO), 2017 11th International Conference on
    • Pages 8-13
    • Description
      • Code review is systematic examination of a software system's source code. It is intended to find mistakes overlooked in the initial development phase, improving the overall quality of software and reducing the risk of bugs among other benefits. Reviews are done in various forms such as pair programming, informal walk-through, and formal inspections. Code review has been found to accelerate and streamline the process of software development like very few other practices in software development can. In this paper we …
  2. Beaucoup d'articles proviennent de ASE 2017, d'autres peuvent être intéressants en fonction de vos sujets d'études.

Autres études

Autres articles

    • Date 2009
    • Description :
      • More than twelve years have elapsed since the first public release of WEKA. In that time, the software has been rewritten entirely from scratch, evolved substantially and now accompanies a text on data mining [35]. These days, WEKA enjoys widespread acceptance in both academia and business, has an active community, and has been downloaded more than 1.4 million times since being placed on Source-Forge in April 2000. This paper provides an introduction to the WEKA workbench, reviews the history of the project, and …
  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
    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. 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)
  3. Hassan AE (2009) Predicting faults using the complexity of code changes. Proc. - Int. Conf. Softw. Eng. pp 78–88
  4. 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
  5. 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
  6. 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
  7. 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
  8. 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.
  9. 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
  10. 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
  11. Benomar O, Sahraoui H, Poulin P (2013) Visualizing software dynamicities with heat maps. Softw. Vis. (VISSOFT), 2013 First IEEE Work. Conf. pp 1–10

Autres

  1. Unbundling Pokémon Go et la masse de documentations sur le reverse de Pokemon Go… A utiliser avec “responsabilité”

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.

  1. 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”.
  2. 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
  3. 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.
  4. Vos IDE fournissent également des outils directement ou sous la forme de plugins, à vous de voir.

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.

  1. The University of Waikato machine learning project WEKA par exemple pour la recherche d'architectures
  2. Sur Github junit-team/junit5
  3. Sous Github ou autre (bitbucket, sourceForge.net) au choix.. en fonction du sujet
  4. 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 :

ARCHIVES

1)
SOFTWARE MAINTENANCE : From Analysis to Implementation
teaching/reverse/2017/start.1513514548.txt.gz · Last modified: 2017/12/17 13:42 by blay