Synthèse des éléments de code logiciel

Les principaux travaux liés à la synthèse des éléments de code logiciel sont présentés chronologiquement, allant des premières contributions jusqu’aux plus récentes. Parmi les pionniers en synthèse de code source, Professeure Murphy (1996) a proposé deux techniques pour synthétiser le code source. La première technique permet de synthétiser les informations structurelles dans un contexte d’un modèle de haut niveau. La deuxième technique soutient le processus de synthèse en facilitant la numérisation et l’analyse des sources d’informations d’un système, spécifiquement pour l’information structurelle difficile à extraire. Jusqu’en 2007, la synthèse automatique du texte en langage naturel a été largement étudiée et de nombreuses approches ont été proposées, elles reposent principalement sur la récupération de texte, l’apprentissage machine et les techniques de traitement du langage naturel (Jones, 2007). Puis, les auteurs Carenini et al. (2007) ont proposé un cadre pour la synthèse des courriels échangés entre développeurs.

Par l’utilisation d’un graphe de fragments pour essayer de détecter une conversation par courriel et en considérant des mots-clés spécifiques, afin de mesurer l’importance des phrases dans la synthèse des courriels. Ils présentent une comparaison de cette approche avec diverses méthodes existantes. Une reproduction du concept de synthèse automatique s’est vue appliquer à la documentation formelle dans les recherches menées par les auteurs Haiduc et al. (2010), afin de faciliter sa compréhension aux développeurs, où ils ont proposé une solution qui obtient des descriptions textuelles. Ces descriptions illustrent les éléments de code logiciel sans avoir à lire les détails. Les auteurs ont considéré le code source comme étant une des sources d’informations utilisées pour la synthèse. D’autre part, la synthèse automatique de la documentation informelle a fait principalement son apparition à travers l’étude des chercheurs Rastkar et al. (2010), où les auteurs ont considéré la synthèse par l’analyse des rapports de bogues. Ils ont comparé les générateurs basés sur les conversations avec les générateurs aléatoires et ont prouvé qu’un générateur formé spécifiquement sur les rapports de bogues peut être statistiquement meilleur que les générateurs de conversation existants.

Les résultats prometteurs de cette étude sont une des motivations qui nous a mené à considérer les rapports de bogues dans notre présente étude. Autres travaux menés par la chercheuse Rastkar (2010) qui est l’étude d’un cadre pour synthétiser les problèmes liés aux logiciels afin d’augmenter le niveau d’abstraction et d’améliorer la productivité des développeurs logiciel. Les commentaires du code source ont aussi été traités comme documentation informelle.

Les auteurs Sridhara et al. (2010) ont considéré l’information textuelle contenue dans les sources d’informations logiciel, en synthétisant par le traitement des commentaires du code source. Entre autres, les auteurs ont présenté une nouvelle technique pour générer automatiquement des commentaires récapitulatifs pour les méthodes Java. Par la suite, les auteurs Moreno & Aponte (2012) ont prouvé l’importance de la synthèse des sources d’informations logiciel dans le domaine de l’ingénierie logicielle. Pour cela, ils ont mené une étude empirique où ils ont analysé la synthèse de code source. La synthèse a été produite manuellement par un groupe de développeurs Java, afin d’évaluer certaines techniques de synthèse basées sur la récupération de texte. Les auteurs ont décrit les caractéristiques prin7 cipales de la synthèse, quel type d’informations devrait être inclus et la qualité atteinte par certaines méthodes automatiques. Les auteurs Moreno et al. (2013a) ont présenté une approche pour générer automatiquement une synthèse compréhensible pour les classes Java, en supposant qu’aucune documentation n’existe.

Les synthèses permettent aux développeurs de comprendre l’objectif principal et la structure de la classe. Cette synthèse est axée sur le contenu et les responsabilités des classes, plutôt que sur leurs relations avec d’autres classes. L’outil de synthèse détermine les stéréotypes des classes et des méthodes et les utilise conjointement avec des heuristiques, pour sélectionner les informations à inclure dans la synthèse. En ce qui concerne l’importance du contexte lors de la synthèse des éléments de code, nous retrouvons dans la thèse du professeure Guerrouj (2013) l’importance des informations contextuelles pour la normalisation du vocabulaire du code source. En comparant les résultats obtenus de deux expérimentations, qui traitent l’implication du contexte lors de la normalisation du vocabulaire. D’où l’idée d’utiliser le contexte au cours de notre expérimentation. Au cours de la même année, les auteurs Rastkar & Murphy (2013) ont proposé l’utilisation de techniques de synthèse multi-documents pour générer une description concise en langage naturel qui explique pourquoi le code a changé afin qu’un développeur puisse choisir le bon plan d’action. Entre autres, les auteurs Moreno et al. (2013b) ont proposé un plug-in Eclipse pour générer automatiquement des synthèses de langages naturels de classes Java. La synthèse est basée sur le stéréotype de la classe. L’outil utilise un ensemble d’heuristiques prédéfinies pour déterminer quelles informations seront utiles à la synthèse et il utilise des techniques de traitement et de génération de langage naturel pour former la synthèse.

Les synthèses générées peuvent être utilisées pour ré-documenter le code et pour aider les développeurs à comprendre plus facilement les classes complexes.

Travaux menés sur les APIs Dans cette section, les principaux travaux liés à la synthèse, la documentation et les informations menées sur les APIs sont présentés chronologiquement, allant des premières contributions jusqu’aux plus récentes. Nous mettons l’emphase sur les APIs, car nos éléments de code consistent en des classes et méthodes d’APIs. Les chercheurs Zibran et al. (2011) ont identifié les problèmes d’utilisabilité des APIs qui se reflètent dans les messages de bogues des utilisateurs et distinguent la signification relative des facteurs d’utilisabilité. De plus, ils ont pu identifier les problèmes d’utilisabilité de l’API les plus fréquents. Par la suite, les auteurs Duala-Ekoko & Robillard (2012) ont identifié vingt différents types de questions que les programmeurs demandent lorsqu’ils travaillent avec des APIs et fournissent de nouvelles idées sur la cause des difficultés rencontrées par les programmeurs lorsqu’ils répondent à des questions sur l’utilisation des APIs afin d’améliorer l’apprentissage et à identifier les domaines du processus d’apprentissage des APIs. En parallèle, les auteurs Dagenais & Robillard (2012) ont proposé une technique qui identifie les termes de type code dans les documents et relient ces termes à des éléments de code spécifiques des APIs. P

Plusieurs travaux ont été menés sur la documentation des APIs. Par exemple, les auteurs Subramanian et al. (2014) qui ont décrit une méthode itérative et déductive de liaison de code source à la documentation de l’API. Les auteurs ont proposé une implémentation de cette méthode, qui prend en charge les langages de programmation Java et JavaScript. Ils ont prouvé que cette implémentation améliore la documentation des APIs traditionnelles avec du code source mis à jour ; elle peut également être utilisée pour incorporer des liens vers la documentation des APIs dans les extraits de code source. Les auteurs Uddin & Robillard (2015) ont étudié comment 10 problèmes communs de documentation se sont manifestés dans la pratique. Les résultats sont basés sur deux sondages sur un total de 323 développeurs logiciel professionnels et une 10 analyse de 179 unités de documentation API. Les trois problèmes majeurs étaient l’ambiguïté, l’incomplétude et l’inexactitude du contenu. Les répondants ont souvent mentionné six des 10 problèmes qui les obligeaient à utiliser une autre API.

Les auteurs Robillard & Chhetri (2015) ont proposé de détecter et de recommander des fragments de documentation API potentiellement importants pour un programmeur qui a déjà décidé d’utiliser un certain élément API. Ils classifient les fragments de texte dans la documentation de l’API en fonction de l’information indispensable.

Ils extraient des modèles de mots et utilisent ces modèles pour trouver automatiquement de nouveaux fragments. Plus récemment, les auteurs Treude&Robillard (2016) ont combiné la documentation des APIs avec les informations contenues dans le Stack Overflow. Les auteurs présentent une approche pour améliorer automatiquement la documentation des APIs à partir de phrases tirées du Stack Overflow et liées à un type de code particulier et qui fournissent un aperçu non contenu dans la documentation de l’API. Les auteurs ont pu montrer que les méta-données disponibles sur le Stack Overflow peuvent améliorer considérablement les approches d’extraction d’informations lorsqu’elles sont appliquées aux données contenues dans le Stack Overflow. D’autres chercheurs ont considéré le Stack Overflow dans l’extraction d’informations sur les APIs, tels que les auteurs Venkatesh et al. (2016) qui ont su extraire des informations sur les APIs à partir de forums de développeurs et du Stack Overflow. En prenant en considération un certain nombre de codes discutés dans le Stack Overflow ainsi que dans les discussions de forums dédiés aux développeurs.

Le rapport de stage ou le pfe est un document d’analyse, de synthèse et d’évaluation de votre apprentissage, c’est pour cela chatpfe.com propose le téléchargement des modèles complet de projet de fin d’étude, rapport de stage, mémoire, pfe, thèse, pour connaître la méthodologie à avoir et savoir comment construire les parties d’un projet de fin d’étude.

Table des matières

CHAPITRE 1 REVUE DE LA LITTÉRATURE
1.1 Synthèse des éléments de code logiciel
1.2 Travaux menés sur les APIs
CHAPITRE 2 DÉFINITION ET PLANIFICATION DE L’EXPÉRIMENTATION CONTRÔLÉE
2.1 Définition de l’expérimentation contrôlée
2.1.1 Questions de recherche et formulation des hypothèses
2.1.2 Variables de recherche
2.2 Planification de l’expérimentation contrôlée
2.2.1 Méthodes et classes
2.2.2 Tâches expérimentales
2.2.3 Design de l’expérimentation contrôlée
2.2.4 Questionnaire expérimental
2.2.5 Pré-questionnaire
2.2.6 Post-questionnaire
2.3 Méthodes d’analyse
2.3.1 Construction de l’Oracle
2.3.2 Mesures des performances
2.3.3 Diagramme en boîte à moustaches
2.3.4 Test statistique : Test de Wilcoxon
2.3.5 Test de multiples corrections des p-values : Correction d’Holm
2.3.6 Mesure de l’effect-size : Cliff delta (d)
CHAPITRE 3 RÉSULTATS ET DISCUSSIONS
3.1 QR1 : Quelle est la performance des développeurs professionnels lors des tâches de synthèse des éléments de code quand ils utilisent différents types de sources d’informations ?
3.1.1 Performances des développeurs professionnels avec l’utilisation du code source
3.1.2 Performances des développeurs professionnels avec l’utilisation du Stack Overflow
3.1.3 Performances des développeurs professionnels avec l’utilisation les rapports de bogues
3.1.4 Performances des développeurs professionnels avec l’utilisation de la combinaison des sources d’informations logiciel
3.2 QR2 : Dans quelle mesure l’utilisation de différentes sources d’informations a-t-elle un impact sur la performance des développeurs professionnels lors de la tâche de synthèse des éléments de code ?
3.2.1 QR21 QR22 QR23 Comparaison des performances obtenues du code source versus autres sources d’informations
3.2.2 QR21 QR24 QR25 Comparaison des performances obtenues du Stack Overflow versus autres sources d’informations
3.2.3 QR22 QR24 QR26 Comparaison des performances obtenues des rapports des bogues versus autres sources d’informations
3.2.4 QR23 QR25 QR26 Comparaison des performances obtenues de la combinaison des sources d’informations versus le code source, les rapports de bogues et le Stack Overflow
3.2.5 QR27 Existe-t-il une différence entre le temps moyen consacré par les développeurs professionnels lors des tâches de synthèse des éléments de code en utilisant les différents types de sources d’informations ?
3.3 Obstacles à la validité
3.3.1 Validité externe
3.3.2 Validité interne
3.3.3 Validité de construction
3.3.4 Validité de conclusion
3.4 Limites de l’approche
CHAPITRE 4 CONCLUSION
ANNEXE I LIENS VERS LES 24 QUESTIONNAIRES
ANNEXE II QUESTIONNAIRES PRÉSENTÉS AUX PARTICIPANTS
ANNEXE III PERFORMANCES DES DÉVELOPPEURS PROFESSIONNELS
PAR L’UTILISATION DES DIFFÉRENTS TYPES DE SOURCES
D’INFORMATIONS
BIBLIOGRAPHIE