Résumé technique : Vers l'identification automatisée des symptômes de violation de l'érosion architecturale

1. Énoncé du problème

L'érosion de l'architecture logicielle se produit lorsque le système implémenté diverge de son architecture prévue, entraînant une dégradation de la maintenabilité, des performances et de la durabilité. Bien qu'il existe divers symptômes d'érosion (structurels, qualitatifs et évolutifs), les symptômes de violation — instances où le code viole des principes, des modèles ou des décisions de conception — sont les indicateurs les plus immédiats nécessitant une attention.

Traditionnellement, l'identification de ces violations repose sur l'analyse statique du code ou la revue manuelle d'artefacts textuels. Cependant, les outils d'analyse statique souffrent souvent d'une détection limitée des types de violations, d'un support linguistique étroit et d'une incapacité à capturer les nuances sémantiques. L'identification manuelle via les revues de code est précise mais fastidieuse, chronophage et sujette à l'erreur humaine. Malgré la richesse des informations contenues dans les commentaires de revue de code concernant les décisions architecturales, aucune étude préalable n'avait investigué l'identification automatisée des symptômes de violation spécifiquement au sein des artefacts textuels tels que les commentaires de revue de code.

2. Méthodologie

L'étude emploie une approche empirique en plusieurs phases pour évaluer la faisabilité de l'automatisation de la détection des symptômes de violation à partir des commentaires de revue de code.

2.1 Construction du jeu de données

• Source : Commentaires de revue de code provenant de quatre projets open-source : OpenStack (Nova, Neutron) et Qt (Base, Creator), collectés via l'API REST de Gerrit entre 2014 et 2020.
• Étiquetage : Un ensemble de 21 583 commentaires a été extrait. Quatre chercheurs ont étiqueté manuellement 606 commentaires comme « symptômes de violation » (classe positive) et 606 comme « non-violations » (classe négative) pour créer un ensemble d'entraînement équilibré. L'accord inter-évaluateurs (Kappa de Cohen) était de 0,857.
• Jeu de test déséquilibré : Un ensemble de test distinct de 150 commentaires (7 violations, 143 non-violations) a été construit pour simuler les conditions réelles de faible prévalence (~4,7 % de taux positif).

2.2 Phase 1 : Classification ML/DL

Les auteurs ont entraîné et évalué des classificateurs en utilisant trois techniques de plongement de mots (word embedding) pré-entraînées : word2vec, fastText et GloVe.

• Apprentissage Automatique (ML) : Cinq algorithmes ont été testés : Support Vector Machine (SVM), Régression Logistique (LR), Arbre de Décision (DT), Naive Bayes de Bernoulli (NB) et k-Plus Proches Voisins (kNN).
• Apprentissage Profond (DL) : Un modèle TextCNN a été entraîné.
• Apprentissage d'Ensemble : Une stratégie de vote majoritaire (Hard Voting) a été appliquée pour combiner les prédictions des classificateurs individuels.
• Optimisation des Hyperparamètres : Une recherche par grille (Grid search) a été utilisée pour les modèles ML. Pour le DL, les paramètres spécifiques incluaient des plongements de 200 dimensions, un taux d'apprentissage de 0,001 et un dropout de 0,25.
• Gestion du déséquilibre : Des techniques d'apprentissage sensibles au coût (ex: pondération des classes, rééchantillonnage SMOTE, matrices de coût) ont été appliquées aux données d'entraînement pour traiter le déséquilibre naturel du jeu de test.

2.3 Phase 2 : Validation

• Qualitative : Une enquête en ligne (24 réponses) et des entretiens semi-structurés (6 participants) ont été menés avec des praticiens impliqués dans les revues de code originales pour évaluer l'utilité perçue de l'approche automatisée.
• Quantitative : Une expérience contrôlée a été réalisée avec 35 développeurs (groupes Contrôle vs Expérimental). Le groupe Expérimental a reçu des indices générés par les classificateurs mettant en évidence les symptômes de violation potentiels. La métrique était la proportion de violations correctement identifiées et corrigées.

2.4 Phase 3 : Comparaison avec les LLM

Trois modèles de langage de grande taille (LLM) de pointe ont été évalués en utilisant l'ingénierie de prompt (apprentissage Zero-shot et Few-shot avec 2, 4, 6 et 10 exemples) :

• GPT-4o (propriétaire)
• Qwen-3 (poids ouverts)
• DeepSeek-R1 (MoE open-source)
  Des stratégies de prompting sensibles au coût ont été utilisées pour atténuer le biais envers la classe majoritaire dans le contexte déséquilibré.

3. Résultats Clés

3.1 Performance ML/DL (RQ1 & RQ2)

• Meilleur Classificateur : Parmi les approches ML/DL, le classificateur SVM avec les plongements word2vec a obtenu la meilleure performance sur le jeu de données équilibré (F1-score : 0,808, Précision : 0,789, Rappel : 0,828).
• Impact des Plongements : Les plongements de mots à 200 dimensions ont généralement surpassé les modèles à 100 et 300 dimensions. Les plongements fastText ont donné des résultats relativement bons pour les modèles DL (TextCNN).
• Ensemble : Les classificateurs d'ensemble utilisant le vote majoritaire ont généralement amélioré la performance par rapport aux classificateurs ML individuels (ex: améliorations du F1-score jusqu'à 13,10 %). Cependant, l'ensemble n'a pas systématiquement amélioré les classificateurs DL (TextCNN).
• Robustesse au Déséquilibre : Sous des conditions naturelles de faible prévalence, les modèles SVM sensibles au coût ont maintenu des scores Macro-F1 élevés (0,816), démontrant une efficacité dans des scénarios réalistes. L'analyse de signification statistique (test de Friedman) a confirmé que les différences de performance n'étaient pas dues à une variation aléatoire.

3.2 Performance des LLM (RQ4)

• Supériorité : Les meilleurs classificateurs basés sur les LLM ont surpassé les approches ML/DL traditionnelles.
• Meilleur Performeur : Le classificateur LLM GPT-4o en configuration 2-shot a atteint le F1-score le plus élevé (0,851) et la précision (Accuracy) la plus élevée (0,848) parmi tous les modèles évalués.
• Limites de l'Ensemble : Contrairement au ML/DL, l'assemblage de LLM (à travers les modèles ou les réglages de shots) n'a pas systématiquement amélioré les performances et a parfois dégradé les résultats, probablement en raison de la haute performance de base des LLM individuels et du potentiel d'amplification des hallucinations.

3.3 Validation Pratique (RQ3)

• Retour des Praticiens : 66,7 % des répondants à l'enquête ont convenu que les symptômes identifiés représentaient des violations architecturales potentielles. La plupart ont convenu que l'approche pourrait aider à localiser et prioriser les problèmes plus rapidement qu'une revue manuelle.
• Expérience Contrôlée : Fournir des indices de symptômes de violation a considérablement amélioré les taux de détection des développeurs. Le taux de détection et de correction correcte des violations (Catégorie 1) est passé de 13,0 % (Contrôle) à 29,4 % (Expérimental). Le taux de détection global (Catégorie 1 + 2) est passé de 25,9 % à 64,7 %, soit une amélioration relative de 150 %.

4. Principales Contributions

1. Démonstration de Faisabilité : La première étude démontrant la faisabilité de l'identification automatique des symptômes de violation d'architecture à partir des commentaires de revue de code en utilisant le ML, le DL et les LLM.
2. Comparaison Exhaustive : Une comparaison rigoureuse de 15 classificateurs ML, 4 classificateurs DL et 3 LLM à travers différentes dimensions de plongement et configurations de shots.
3. Insights Validés par les Praticiens : Preuves empiriques issues de sondages, d'entretiens et d'une expérience contrôlée confirmant que les indices automatisés améliorent significativement la performance des développeurs dans la détection de problèmes architecturaux.
4. Jeu de Données et Outils : La publication d'un jeu de données étiqueté de violations architecturales issues de revues de code et du package de réplication pour soutenir les recherches futures.

5. Signification et Revendications

L'article affirme que l'identification automatisée des symptômes de violation sert de couche complémentaire à la revue de code moderne, offrant des alertes précoces pour empêcher l'intégration de code qui dévie de l'architecture prévue.

• Pour les Praticiens : L'approche offre un outil pratique pour réduire la charge cognitive liée à l'identification des problèmes architecturaux, aidant les équipes à prioriser le refactoring et à maintenir l'intégrité architecturale.
• Pour la Recherche : L'étude souligne que, bien que les LLM (spécifiquement GPT-4o) offrent actuellement des performances supérieures, les approches ML traditionnelles (SVM avec word2vec) restent hautement efficaces et plus rentables pour des tâches spécifiques de classification de texte, surtout lorsque les ressources de calcul sont limitées.
• Méthodologique : Ce travail comble le fossé entre la vérification théorique de la conformité architecturale et les flux de travail concrets des développeurs en exploitant le riche contexte sémantique présent dans les discussions de revue de code.

Les auteurs concluent que, bien que des défis concernant les faux positifs et les coûts d'intégration subsistent, les preuves quantitatives et qualitatives soutiennent fortement l'intégration de telles techniques automatisées dans les cycles de développement logiciel afin d'améliorer la durabilité des systèmes.