💻 computer science

What Characterizes Pairwise Modular Smells?

Cette étude caractérise les « Pairwise Modular Smells » en identifiant 19 caractéristiques de relations par paires, en entraînant des modèles d'apprentissage automatique sur plus de 6 millions de paires d'entités issues de 11 projets Java pour prédire les paires inaptes à être séparées ou colocalisées avec des améliorations significatives de l'exactitude, et en interprétant les résultats pour révéler des facteurs influents spécifiques, tels que les dépendances et la similitude sémantique, qui déterminent ces défauts architecturaux.

Auteurs originaux : Chenxing Zhong, Daniel Feitosa, Paris Avgeriou, Huang Huang, Wei Song, He Zhang

Publié 2026-06-23

📖 6 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Chenxing Zhong, Daniel Feitosa, Paris Avgeriou, Huang Huang, Wei Song, He Zhang

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

Imaginez que vous soyez le gestionnaire d'une immense et trépidante bibliothèque. L'objectif d'une bonne bibliothèque est d'organiser les livres en sections logiques : « Cuisine », « Histoire », « Science », etc. Cela permet aux gens de trouver facilement ce dont ils ont besoin et aux bibliothécaires de maintenir les choses bien rangées.

Dans le monde du logiciel, ces « sections » sont appelées modules. Un « bon » module regroupe des fichiers qui travaillent étroitement ensemble (haute cohésion) et garde séparés les fichiers qui ne se parlent pas vraiment (faible couplage).

Cependant, avec le temps, les bibliothèques peuvent devenir désordonnées. Des livres se retrouvent éparpillés dans les mauvais bacs. Dans le logiciel, ce désordre est appelé une « odeur » (Smell). Ce n'est pas une mauvaise odeur, mais un signe qu'un problème structurel existe et pourrait causer des maux de tête plus tard.

Le Problème : L'odeur de modularité par paire (PairSmell)

Dans une étude précédente, les auteurs ont introduit une nouvelle façon de trouver ces désordres appelée PairSmell. Au lieu de regarder toute la bibliothèque à la fois, ils regardent des paires de livres (fichiers).

Ils posent une question simple : « Ces deux fichiers appartiennent-ils à la même section, ou devraient-ils être dans des sections différentes ? »

Pour répondre à cela, ils utilisent un panel de « bibliothécaires experts » (outils logiciels automatisés). Si tous les experts sont d'accord pour dire que le Fichier A et le Fichier B devraient être ensemble, mais que la bibliothèque les a actuellement dans des sections différentes, c'est un problème. C'est ce qu'on appelle l'InSep (Séparation Inappropriée).

Inversement, si les experts disent qu'ils devraient être dans des sections différentes, mais que la bibliothèque les a bloqués ensemble dans la même boîte, c'est aussi un problème. C'est ce qu'on appelle l'InCol (Collocation Inappropriée).

L'Écart : L'étude précédente pouvait trouver ces problèmes, mais elle ne pouvait pas facilement expliquer pourquoi ils étaient des problèmes. C'était comme un médecin disant : « Vous avez de la fièvre », sans expliquer si c'est causé par la grippe, une infection ou simplement par le soleil. Les développeurs avaient besoin de savoir pourquoi une paire était désordonnée afin de pouvoir la corriger correctement.

La Solution : Étudier la « personnalité » des paires

Ce nouvel article demande : Quels traits spécifiques font qu'une paire de fichiers est susceptible d'être mal placée ?

Les auteurs ont traité cela comme une enquête policière. Ils ont rassemblé une liste de 19 « traits de personnalité » (caractéristiques) qui décrivent comment deux fichiers se rapportent l'un à l'autre. Ces traits incluent :

Dépendances : Avec combien d'autres fichiers ce fichier communique-t-il ?
Mots Partagés : Utilisent-ils le même vocabulaire technique ?
Taille : Quelle est la taille des fichiers ?
Complexité : À quel point sont-ils difficiles à comprendre ?

Ils ont ensuite injecté ces traits dans un « Cerveau » d'Apprentissage Automatique (un modèle informatique) entraîné sur plus de 6 millions de paires de fichiers provenant de 11 projets de logiciels open-source différents (comme Kafka, Hadoop et Druid).

Les Résultats : Qu'est-ce qui rend une paire « malodorante » ?

L'ordinateur a appris à repérer les « odeurs » avec une grande précision. Plus important encore, les auteurs ont demandé à l'ordinateur d'expliquer quels traits étaient les plus gros signaux d'alarme.

1. Pour les fichiers qui devraient être ensemble mais qui sont séparés (InSep)

Le modèle a trouvé que les fichiers séparés sont probablement « malodorants » (incorrectement séparés) si :

Ils ont trop de connexions « sortantes » : Imaginez deux personnes dans des pièces différentes qui passent leur temps à crier des instructions au même groupe de personnes dans le couloir. Si elles dépendent fortement des mêmes ressources extérieures, elles devraient probablement être dans la même pièce pour mieux se coordonner.
Ils partagent trop de mots avec le reste du système : Si les deux fichiers parlent constamment des mêmes concepts que tout le monde ailleurs dans le bâtiment, il est probable qu'ils fassent partie de la même « équipe » et ne devraient pas être isolés.
Ils sont très simples (peu de champs) : Si deux fichiers sont petits et simples mais dépendent l'un de l'autre, les séparer revient à mettre une chaussure gauche et une chaussure droite dans des boîtes différentes. Ils sont trop simples pour justifier une séparation.

2. Pour les fichiers qui sont ensemble mais qui devraient être séparés (InCol)

Le modèle a trouvé que les fichiers coincés ensemble sont probablement « malodorants » (incorrectement regroupés) si :

Ils ne parlent pas la même langue (Faible similitude sémantique) : Si un fichier traite de la « Cuisine » et l'autre de l'« Histoire », mais qu'ils sont dans la même boîte, c'est une erreur. Le modèle vérifie s'ils utilisent des termes techniques similaires ; si ce n'est pas le cas, ils ne devraient pas être ensemble.
Ils ne partagent pas beaucoup de mots entre eux : Même s'ils sont dans la même boîte, s'ils ne mentionnent jamais les mêmes choses, ils sont probablement sans lien.
Ils ont trop de connexions « entrantes » : Imaginez un bureau unique où 50 personnes de différents départements viennent régulièrement déposer du travail. Si deux fichiers au sein d'un même module sont bombardés de requêtes de partout, ce module est probablement trop encombré et doit être divisé pour gérer la charge.

Pourquoi cela importe

Les auteurs fournissent un « Manuel d'utilisation » pour les développeurs. Désormais, au lieu de simplement voir un drapeau rouge disant « Ceci est incorrect », un développeur peut voir pourquoi :

« Oh, ces deux fichiers sont séparés, mais ils dépendent tous deux des 50 autres fichiers. Je devrais les rapprocher. »
« Oh, ces deux fichiers sont ensemble, mais l'un est un outil utilitaire et l'autre est un outil de logique métier, et ils n'ont aucun vocabulaire commun. Je devrais les séparer. »

L'essentiel

Ce document prend un problème logiciel complexe — comprendre pourquoi les modules logiciels sont désordonnés — et le décompose en traits simples et compréhensibles. En utilisant une approche de « détective » avec l'apprentissage automatique, ils ont identifié les « traits de personnalité » spécifiques (comme le nombre de connexions d'un fichier ou le nombre de mots qu'il partage) qui signalent une erreur de conception. Cela aide les développeurs non seulement à trouver le désordre, mais aussi à comprendre la cause profonde afin de le nettoyer efficacement.

Résumé Technique : Quelles sont les caractéristiques des odeurs modulaires par paires ?

Énoncé du problème
L'amélioration de la structure modulaire des systèmes logiciels existants est un défi critique. Bien que les techniques de modularisation logicielle tentent de restructurer les systèmes en modules optimaux, elles s'avèrent souvent peu pratiques en raison des changements étendus et coûteux qu'elles requièrent. À l'inverse, les approches qui identifient les problèmes de conception (odeurs ou smells) comme des opportunités de refactorisation souffrent souvent d'une granularité grossière (par exemple, au niveau du module), ce qui rend difficile la détermination de stratégies de refactorisation spécifiques.

Pour répondre à cela, les travaux précédents des auteurs ont introduit la Pairwise Modular Smell (PairSmell), une odeur architecturale à grain fin définie comme l'écart entre la relation modulaire (MR) réelle d'une paire de fichiers et une MR appropriée. La MR appropriée est dérivée d'un consensus de plusieurs outils de modularisation. Si la relation réelle (colocalisée ou séparée) contredit le consensus, il s'agit d'une odeur : InSep (séparation inappropriée, où les outils s'accordent pour dire qu'ils devraient être ensemble mais sont séparés) ou InCol (colocalisation inappropriée, où les outils s'accordent pour dire qu'ils devraient être séparés mais sont ensemble).

Cependant, la définition de PairSmell repose sur la sortie "boîte noire" des outils de modularisation, ce qui rend le concept obscur et difficile à expliquer. Les développeurs manquent de compréhension sur le pourquoi une paire spécifique présente une odeur. Cette étude vise à expliquer la PairSmell en identifiant les caractéristiques de la paire spécifiques qui rendent certaines entités susceptibles de présenter ces écarts architecturaux.

Méthodologie
L'étude emploie une approche à méthodes mixtes combinant une revue rapide de la littérature, une modélisation par apprentissage automatique (ML) et une analyse qualitative :

Revue rapide de la littérature : Les auteurs ont examiné 178 études primaires sur la modularisation logicielle pour synthétiser un ensemble de caractéristiques candidates représentant les relations entre deux entités. Ce processus a produit 19 caractéristiques de paire distinctes réparties en six dimensions : liens (relatedness), distance, indépendance, complexité, cohésion et taille.
Construction du jeu de données : L'étude a utilisé un jeu de données organisé de plus de 6,1 millions de paires d'entités dérivées de 11 projets Java open-source (ex. Kafka, Hadoop, Druid). Le jeu de données comprend des paires séparées et colocalisées, avec des étiquettes de vérité terrain pour les instances InSep et InCol établies dans un travail antérieur.
Modélisation prédictive :
- Caractéristiques : Les 19 caractéristiques ont été utilisées comme variables indépendantes.
- Cible : Deux tâches de classification binaire ont été définies : prédire InSep (pour les paires séparées) et InCol (pour les paires colocalisées).
- Sélection du modèle : Plusieurs modèles (Régression Logistique, SVM, Forêt Aléatoire) ont été entraînés. Les Machines à Vecteurs de Support (SVM) ont été sélectionnées comme modèles principaux en raison de leur performance supérieure.
- Prétraitement : Pour traiter la colinéarité, les caractéristiques présentant une corrélation de rang de Spearman ( $\rho$ ) $\ge 0,7$ ont été supprimées. Le déséquilibre des classes a été traité par échantillonnage de transformation inverse (Inverse Transform Sampling).
Interprétation : Les auteurs ont utilisé l'importance des caractéristiques par permutation (Permutation Feature Importance) pour identifier les caractéristiques les plus influentes. Des graphiques de dépendance partielle (PDP) ont été générés pour visualiser comment les changements dans les valeurs de caractéristiques spécifiques affectent la probabilité qu'une paire soit classée comme une odeur.
Validation qualitative : Des exemples représentatifs du jeu de données ont été analysés manuellement pour illustrer comment les caractéristiques influentes identifiées se manifestent dans le code réel.

Contributions clés

Caractérisation systématique de la PairSmell : L'étude va au-delà de la simple détection de la PairSmell pour expliquer son émergence. Elle identifie et interprète les caractéristiques de la paire sous-jacentes qui pilotent les instances InSep et InCol.
Identification des indicateurs influents :
- Pour InSep (paires séparées qui devraient être ensemble), les indicateurs les plus influents sont les dépendances sortantes (out-going dependencies), les termes partagés avec d'autres (degree) et les champs déclarés (total-fields).
- Pour InCol (paires colocalisées qui devraient être séparées), les indicateurs les plus influents sont la similarité sémantique (tf-idf), les termes partagés entre la paire (intersection), les termes partagés avec d'autres (degree) et les dépendances entrantes.
Illustration pratique : L'article fournit des exemples concrets démontrant comment un degré de sortie élevé ou un faible nombre de termes partagés corrèle avec des types d'odeurs spécifiques, offrant des informations exploitables pour les développeurs.

Résultats

Performance prédictive : Les modèles SVM entraînés ont obtenu une amélioration de 58,6 % de l'AUC-ROC par rapport aux modèles de base pour les paires colocalisées et de 34,6 % pour les paires séparées. Les modèles ont également démontré un équilibre remarquable entre précision et rappel (améliorations de l'AUPRC de 1,57x et 2,77x par rapport aux bases).
Analyse des caractéristiques :
- InSep : Un nombre élevé de dépendances sortantes augmente initialement la probabilité d'une odeur (suggérant un couplage externe excessif), tandis qu'un très faible degré sortant suggère une indépendance fonctionnelle justifiant la séparation. Un degré élevé (termes partagés avec d'autres) indique des responsabilités chevauchantes, rendant la séparation inappropriée. Un faible nombre de champs totaux (total-fields) dans les paires dépendantes suggère des responsabilités simples et éparpillées qui gagneraient à être maintenues ensemble.
- InCol : Une faible similarité sémantique (sim-tfidf) et une faible intersection indiquent que les entités colocalisées sont sans lien, violant le principe de responsabilité unique. Un degré entrant élevé suggère que les entités ont trop de responsabilités, surchargeant potentiellement le module.
Signification statistique : Les tests Mann-Whitney U ont confirmé des différences significatives dans les distributions de caractéristiques entre les paires odorantes et non odorantes.

Signification et affirmations
L'article affirme faire progresser la compréhension de la PairSmell en déplaçant l'attention de sa prévalence et de ses conséquences vers son explicabilité. En liant des caractéristiques de paire spécifiques à l'occurrence des odeurs, l'étude :

Démystifie la PairSmell : Elle explique pourquoi certaines paires sont signalées comme des odeurs, transformant le concept d'un résultat d'outil opaque en un problème de conception compréhensible.
Guide le refactorisation : Les conclusions offrent des stratégies de remédiation spécifiques basées sur les caractéristiques (ex. : abstraire les interfaces pour réduire le degré de sortie, ou renommer les identifiants pour améliorer la similarité sémantique).
Informe la conception modulaire : L'étude suggère que les futurs outils de modularisation ne devraient pas seulement se concentrer sur la relation, mais aussi considérer l'indépendance et la taille pour produire des solutions plus rationnelles. Elle souligne que les caractéristiques souvent utilisées dans les algorithmes de modularisation peuvent être colinéaires, suggérant la nécessité d'une sélection rigoureuse des caractéristiques pour éviter une analyse redondante.

Les auteurs positionnent ce travail comme un fondement pour une inspection et une amélioration plus efficaces des structures de modules logiciels, fournissant des preuves empiriques qui soutiennent une perspective nuancée sur la conception modulaire, au-delà des découvertes antérieures focalisées uniquement sur la prévalence des odeurs.