recommendation systems for software engineering

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

Upload: tierra

Post on 24-Feb-2016

36 views

Category:

Documents


0 download

DESCRIPTION

Recommendation systems 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 - PowerPoint PPT Presentation

TRANSCRIPT

Page 1: Recommendation systems  for software ENGINEERING

RECOMMENDATION SYSTEMS FOR SOFTWARE ENGINEERINGMartin P. Robillard, McGill UniversityRobert J. Walker, University of CalgaryThomas Zimmermann, Microsoft Research

Présenté par: Andy HazoumeCours: Interfaces Intelligentes INF6304Professeur: Michel Desmarais

École Polytechnique de Montréal (Automne 2013)

IEEE SOFTWAREJuillet/Août 2010

Page 2: Recommendation systems  for software ENGINEERING

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: (Recommendation Systems for Software Engineering)

Page 3: Recommendation systems  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.

Page 4: Recommendation systems  for software ENGINEERING

4

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

Définition des RSSEs

Page 5: Recommendation systems  for software ENGINEERING

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

Page 6: Recommendation systems  for software ENGINEERING

6

Ainsi un RSSE doit posséder au moins trois fonctionnalités:

• un mécanisme de collecte de donnéesPour collecter des données et des artifact du processus de développement afin de les modéliser.

• un moteur de recommandationPour analyser le modèle de données et générer des recommandations.

• une interface utilisateurPour déclencher le processus de recommandation et présenter ses résultats.

Quelle utilité pour les développeurs?

Page 7: Recommendation systems  for software ENGINEERING

7

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.

Quelle utilité pour les développeurs?

Classes, méthodes, champs, …

Regroupe les éléments modifiés au même moment par le même développeur: « co-changed »

Pré traitement

L’archive des versions du projet

Transactions

Base de Données SQL

Configuration Exécution

Contexte

Recommandations

Page 8: Recommendation systems  for software ENGINEERING

8

Strathcona: trouver des exemples pertinentsAider le développeur à trouver des exemples de code source pertinents afin d’utiliser de manière efficace des Frameworks.

Quelle utilité pour les développeurs?

Page 9: Recommendation systems  for software ENGINEERING

9

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.

Quelle utilité pour les développeurs?

Page 10: Recommendation systems  for software ENGINEERING

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.

Page 11: Recommendation systems  for software ENGINEERING

11

• 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èle de 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.

Les dimensions de la conception d’un RSSE

Page 12: Recommendation systems  for software ENGINEERING

12

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

Les dimensions de la conception d’un RSSE

Page 13: Recommendation systems  for software ENGINEERING

13

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

Les dimensions de la conception d’un RSSE

Page 14: Recommendation systems  for software ENGINEERING

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: Expertise Browser et Dhruv

Page 15: Recommendation systems  for software ENGINEERING

15

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

Limites et perspectives

Page 16: Recommendation systems  for software ENGINEERING

16