Recommendation systems for software ENGINEERING

1. Recommendationsystems for software ENGINEERING Martin P. Robillard, McGill University Robert J. Walker, University of Calgary Thomas Zimmermann, Microsoft Research Juillet/Août 2010 IEEE SOFTWARE Présenté par: Andy Hazoume Cours: Interfaces Intelligentes INF6304 Professeur: Michel Desmarais École Polytechnique de Montréal (Automne 2013)

2. Plan • Définition des Systèmes de Recommandation pour le Génie Logiciel (RSSEs*) • Quelle utilité pour les Développeurs? • Les dimensions de la conception d’un RSSE • Limites et perspectives RSSEs: (RecommendationSystems for Software Engineering)

3. Définition des RSSEs An RSSE is a software application that provides information items estimated to be valuable for a software engineering task in a given context. • Le but des RSSEs est d’aider les développeurs, les assister dans la prise de décision pendant l’exécution d’une tâche de développement logiciel. • Le contexte des RSSEs inclut une vaste gamme d’activités liées aux tâches de développement logiciel. Contrairement aux autres Systèmes de recommandations, dans lequel le contexte est établi via le profil de l’utilisateur essentiellement.

4. Définition des RSSEs • Le contexte devrait donc comprendre: • Les caractéristiques de l’utilisateur: niveau d’expertise, description du métier, travail principal, réseau social; • Le type de tâche en cours d’exécution: ajout de nouvelles fonctionnalités, débogage, ou optimisation; • Les caractéristiques spécifiques de la tâche: code modifiée, code consulté, les dépendances du code et • l’historique des actions de l’utilisateur ou des autres utilisateurs: artéfacts consultés, artéfacts explicitement recommandés. • De la qualité des informations fournies par les RSSEs: • « Originales » • « Surprenantes » • « Pertinentes »

5. Quelle utilité pour les Développeurs? • Localiser des consultants experts (Expertise Browser) • Faciliter la prise décision • sur quels exemples utiliser (Strathcona) • sur quelles séquences d’appels utiliser (ParseWeb) • Aider à se retrouver dans du code (Suade) • Proposer des suggestions sur ce qu’il faut changer (eRose) • Recommander des méthodes de remplacement afin d’adapter le code à une nouvelle version de bibliothèque (SemDiff) • Aider au débogage en trouvant du code source et des développeurs reliés à la correction d’un bug (Dhruv) • Aider à prioriser les ressources de test pour l’assurance qualité.

6. Quelle utilité pour les développeurs? Ainsi un RSSE doitposséder au moinstroisfonctionnalités: • un mécanisme de collecte de données Pour collecter des données et des artifact du processus de développementafin de les modéliser. • un moteur de recommandation Pour analyser le modèle de données et générer des recommandations. • une interface utilisateur Pour déclencher le processus de recommandation et présentersesrésultats.

7. Quelle utilité pour les développeurs? eRose: guider les changements dans le code • Plugin pour l’EDI Eclipse. • Les Développeurs qui ont changé la fonction X ont également changé la fonction Y. • Recommandations basées sur un Dépôt CVS (Gestionnaire de Version). • Les éléments changés constituent le contexte. Exécution Configuration Regroupe les éléments modifiés au même moment par le même développeur: « co-changed » Contexte Pré traitement Transactions Classes, méthodes, champs, … L’archive des versions du projet Recommandations Base de Données SQL

8. Quelle utilité pour les développeurs? Strathcona: trouver des exemples pertinents Aider le développeur à trouver des exemples de code source pertinents afin d’utiliser de manière efficace des Frameworks.

9. Quelle utilité pour les développeurs? Suade: guider la navigation à travers le code • Plugin Eclipse • Fournit des suggestions permettant au développeur de se retrouver dans du code. • L’utilisateur crée le contexte en spécifiant de façon explicite (drag and drop dans une vue du contexte) un ensemble de champs et de méthodes. • Suade se base essentiellement sur les dépendances des éléments pertinents (du contexte) et de ceux du code source du projet. • Il affiche les recommandations sous forme de liste dans une vue dédiée. • Les développeurs peuvent ajouter des éléments recommandés à la vue du contexte afin de mettre à jour de manière itérative les recommandations.

10. Les dimensions de la conception d’un RSSE • La Nature du contexte • Entrée du RSSE • Explicite, Implicite, Hybride (Explicite & Implicite) • Explicite: l’utilisateur fournit explicitement le contexte via des interactions avec l’interface utilisateur (surlignement du code dans Strathcona ou drag and drop dans Suade) • Implicite: le système suit et réagit aux actions de l’utilisateur (archives du gestionnaire de version dans eRose) ou consulte l’historique des interactions de l’utilisateur avec l’EDI. • Hybride: exemple de CodeBroker.

11. Les dimensions de la conception d’un RSSE • Le moteur de recommandation • Analyse des données (Mining Software Repositories: MSR) • Le code source du projet • L’historique des changements • Mailing lists • Signalements de bugs • Sessions de programmation • Rapports de test, … • Système de classement • Les éléments les plus pertinents pour le développeur sont placés en tête. • Basé sur un modèlede ce que le développeur trouve utile. • Le Modèle • pas parfait. • Doit représenter la tâche et le point de vue du développeur par rapport à la tâche. • Doit tenir compte du temps.

12. Les dimensions de la conception d’un RSSE • Les modes de sortie • « Pull mode » • Les recommandations sont générées après une requête du développeur (un clic par exemple). • Le développeur peut rater quelque chose d’important parce qu’il n’a pas pensé à faire la requête. • « Push mode » • Recommandations délivrées de façon continue. • Peut être gênant quand mal conçu. • « Batch mode » <> « inline mode »

13. Les dimensions de la conception d’un RSSE • Des fonctionnalités trans-dimensionnelles • Un mécanisme de retour (feedback) par le développeur sur les recommandations passées. • Le système de classement • Ajustable localement Le développeur ajuste manuellement le contexte (Suade). • Spécifiquement adaptatif L’algorithme est traité pour un individu donné en fonction de son retour implicite ou explicite (CodeBroker). • Globalement adaptatif Le retour d’un utilisateur affecte un autre. • Explications • Sans explications (ex: prédire qu’un fichier donné est sujet à un défaut sans explication) Problèmes de confiance • Avec explications détaillées (Strathcona) • Confiance accrue • Surcharge d’informations

14. Limites et perspectives • Lorsque les dépôts d’information sont de grande taille, les RSSEs subissent le syndrome du démarrage à froid à cause du manque d’information pour faire les recommandations… • Se baser sur des données similaires dans d’autres projets. • Listes de recommandations (pas très explicatives) • Représentations graphiques (Strathcona) • Trop orientés vers le code source. • Couvrir d’autres aspects du génie logiciel (la qualité, les outils, la gestion de projet…). Exemples: ExpertiseBrowser et Dhruv

15. Limites et perspectives • Des modèles capables de s’adapter aux actions du développeurs avec une réaction à leur feedback et leurs préférences spécifiées. • Recherche proactive • Au lieu d’attendre que les développeurs se rendent compte qu’ils ont besoin d’une certaine information, le système la leur délivrerait automatiquement. • Éviter de donner tant de « conseils utiles » que le développeur finisse par tous les ignorer.