- Encadrant: Sébastien Mosser (I3S)
- AL: Architecture Logicielle
- IHM: Interaction Homme - Machine
- IAM: Informatique Ambiante et Mobile
Le laboratoire LATECE de l'Université du Québec À Montréal (UQAM) mène via les travaux de Naouel Moha une activité de recherche sur la détection d'anti-patterns. Ses travaux récents en collaboration avec le centre de recherche Inria Lille-Nord Europe portent sur la détection d'anti-patterns énergétique dans les applications Android. Par exemple, l'utilisation de méthode statiques est moins consommateur d'énergie que d'utiliser des méthodes d'instance dans la machine virtuelle java Android. On peut donc considérer comme un anti-pattern énergétique la définition d'une méthode d'instance qui aurait pu être statique. Le LATECE à développé avec Inria le logiciel PAPRIKA, un système de détection de ces anti-patterns qui propose des fixes permettant automatiquement de réparer certains anti-patterns. De son coté, l'équipe SPARKS du laboratoire I3S travaille sur des problématiques de composition logicielle. Ce projet à pour but de travailler, en collaboration avec l'UQAM, sur la composition de ces fixes quand plusieurs anti-patterns sont détecté au même endroit dans un code Android. Il pourra être poursuivi en stage en laboratoire selon les résultats du projet. Ce projet a vocation à être multi-parcours, a cheval entre AL et IAM-IHM. L'équipe idéale contient au moins 2 ALs pour la partie métaprogrammation/composition qui constitue le coeur d'application du projet.
L'équipe de recherche de Naouel Moha est spécialisée en detection d'anti-pattern logiciels, dans différents domaines (e.g., code objet, interface de service). Un anti-pattern est le reflet d'un pattern, i.e., une mauvaise pratique de développement logiciel menant à des logiciels de mauvaise qualité. Les travaux récents de cette équipe l'ont mené à définir PAPRIKA, un outil permettant d'identifier des anti-patterns énergétique (i.e., générant une surconsommation d'énergie). Parmi les anti-patterns détectés par PAPRIKA, on peut lister par exemple les 3 anti-patterns suivants :
- Internal Getters Setters (IGS) : A l'intérieur d'une classe, lire où écrire dans un attribut via son getter ou son setter est une mauvaise pratique. Les spécifications d'android recommandent d'accéder directement à l'attribut.
- Member Ignoring Method (MIM) : Invoquer une méthodes d'instance est plus gourmand qu'invoquer une méthode statique. Définir sous la forme d'une méthode d'instance une fonctionnalité ne nécessitant pas d'instance de la classe est donc une mauvaise pratique.
- HashMap Usage (HMU) : L'utilisation de la classe HashMap n'est pas recommandé, il est conseillé d'utiliser la classe ArrayMap qui est plus efficace.
Pour chacun de ces anti-patterns, il existe un fix automatisant la réparation du logiciel. Par exemple, pour IGS, il "suffit" de remplacer tous les appels aux getters par un accès à la variable, et tous les setters par une modification de la variable. En l'état actuel, ces fixes sont écrit sous la forme de processeurs Spoon qui modifient le code lorsqu'ils sont appliqués pendant la phase de réparation.
L'objectif du projet est, sur la base des données fournies par les dévelopeur de PAPRIKA lors de leurs expérimentations, de travailler sur la composition des réparations effectuées: modélisation, visualisation, opérationalisation.
Pour l'instant, chaque fix est implémenté par un processeur Spoon indépendant. Ces processeurs sont du java pur, et ne permettent pas de vérifier formellement qu'il n'existe pas d'interactions entre les fix quand on doit les appliquer au même endroit. Par exemple, si 5 anti-patterns sont détectés au même endroit dans le code d'une application, il existe 120 (n!, avec n=5) manière différente de séquencer l'application des fixes. Il est donc important de savoir si ces réparations interagissent les unes avec les autres, sont incompatibles, ... De manière empirique, les développeurs de PAPRIKA se sont rendu compte qu'il pouvait être contre-productif de résoudre tous les anti-patrons avec les fixs existants, ce qui donne en l'état dans certains cas une application plus gourmande en énergie que l'application initiale.
Le projet s'attachera donc a modéliser les différents fixs mis en place par les développeurs de PAPRIKA, afin de comprendre leur impact sur le code source lorsqu'il sont appliqués. L'étude portera sur leurs compositions, l'identification d'interférences entre différents fixs, la planification automatique de réparations et la mise en place de plans d'experiences empirique pour valider les hypothèses faites lors des compositions de réparations. Des problématiques de visualisation sont présentes pour comprendre comment l'application sera réparée.
- Capacité d'abstraction (identifier les éléments ayant de la valeur pour résoudre le problème)
- Bon niveau en programmation objet et goût pour la méta-programmation (on va écrire des programmes qui écrivent des programmes)
- Ne pas être rebuté par les maths en général (besoin de faire des stats sur les réparations) et l'algèbre en particulier (pour exprimer les algorithmes de réparation et leurs compositions).
- (pour les SI: avoir suivi le module DevOps en 4A serait une bonne idée, pour la partie "mutation" du module)
- Compréhension des résultats de PAPRIKA par l'équipe (anti-patterns détectés, fixs appliqués);
- Analyse des compositions de fixs nécessaires sur la base des jeux de données disponibles;
- Automatisation de la composition (et détection des interférences entre fixs).
- Modélisation des fixs et de leur impact sur le code source des applications mobiles Android;
- Analyse automatisées des compositions de fixs
- Application iso-fonctionelle avec les fixs existants dans PAPRIKA
- Etude empirique sur les jeux de données disponibles