Transcript Recommendation systems for software

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
Professeur: Michel Desmarais
École Polytechnique de Montréal (Automne 2013)
1
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)
2
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.
Définition des RSSEs
3
• 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 »
4
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é.
Quelle utilité pour les développeurs?
5
Ainsi un RSSE doit posséder au moins trois fonctionnalités:
• un mécanisme de collecte de données
Pour collecter des données et des artifact du processus de développement
afin 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ésenter ses résultats.
Quelle utilité pour les développeurs?
6
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
Base de Données SQL
Recommandations
Quelle utilité pour les développeurs?
7
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.
Quelle utilité pour les développeurs?
8
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.
9
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.
Les dimensions de la conception d’un RSSE
10
• 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
11
• 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
12
• 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
13
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
Limites et perspectives
14
• 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.
15