💻 computer science

A Multi-Agent Consensus Protocol for Stable Software Remodularization

Ce papier propose un nouveau protocole de consensus multi-agents appelé Protocole de Concession Monotone Asymétrique (AMCP) qui reformule la remodularisation logicielle comme un problème de négociation distribuée afin d'équilibrer efficacement la cohésion structurelle et la stabilité évolutive, surpassant les méthodes d'optimisation traditionnelles lorsque des contraintes de stabilité strictes sont requises.

Auteurs originaux : Ahmed F. Ibrahim

Publié 2026-05-07

📖 4 min de lecture☕ Lecture pause café

CC BY 4.0

Auteurs originaux : Ahmed F. Ibrahim

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 un système logiciel comme une immense et désordonnée bibliothèque. Avec le temps, les livres (les modules de code) sont déplacés, mal rangés ou empilés de manière qui n'a plus de sens. Cela s'appelle « l'érosion architecturale ». Pour y remédier, il faut réorganiser la bibliothèque afin que les livres apparentés soient regroupés (forte cohésion) et que les étagères ne soient pas trop interconnectées (faible couplage).

Cependant, il y a un piège : si vous réorganisez la bibliothèque de manière trop radicale, les bibliothécaires (les développeurs) sont perdus car ils ne parviennent plus à s'y retrouver dans la nouvelle disposition. Ils ont besoin que la nouvelle organisation ressemble, dans une certaine mesure, à l'ancienne (forte stabilité).

Traditionnellement, les programmes informatiques tentaient de résoudre ce problème en trouvant la seule disposition « parfaite » qui maximise l'organisation, ignorant souvent à quel point cela confondrait les bibliothécaires. Cet article propose une approche différente : au lieu d'un seul ordinateur cherchant la perfection, il utilise une négociation entre deux agents numériques.

Les Deux Agents

Imaginez le logiciel comme une pièce où deux personnes débattent de la façon d'arranger les meubles :

L'« Agent Cohésion » (L'Organisateur) : Cet agent veut que les meubles soient regroupés par fonction. « Toutes les lampes doivent être ensemble ! Toutes les chaises doivent former un cercle ! » Il se soucie de l'ordre et de la logique de la pièce.
L'« Agent Stabilité » (L'Historien) : Cet agent veut garder les meubles exactement là où ils étaient hier. « Ne déplacez pas le canapé ! Les bibliothécaires savent où il se trouve. » Il se soucie de maintenir les choses familières.

La Négociation : AMCP

L'article présente un règlement pour leur débat appelé le Protocole de Concession Monotone Asymétrique (AMCP). Voici comment cela fonctionne en termes simples :

Le Point de Départ : La pièce commence avec les meubles exactement là où ils étaient hier (la version précédente du logiciel).
La Proposition : L'« Historien » (Agent Stabilité) est le seul autorisé à suggérer de déplacer un seul meuble.
Le Compromis : L'« Organisateur » (Agent Cohésion) dit : « Si vous déplacez cette lampe, la pièce devient 10 % plus ordonnée. Mais si vous déplacez le canapé, la pièce ne devient que 1 % plus ordonnée. »
La Règle : L'Historien examine tous les déplacements possibles et choisit celui qui offre le plus grand gain d'ordre pour le moindre coût en familiarité.
Le Filet de Sécurité : L'architecte (l'humain responsable) définit un « Budget de Stabilité ». Il s'agit d'une limite stricte, comme une clôture. L'Historien ne peut jamais déplacer des meubles d'une manière qui franchirait cette clôture. Si un déplacement rendait la pièce trop étrangère, il est immédiatement rejeté.

Le « Disjoncteur »

L'article affirme que ce système agit comme un disjoncteur dans un tableau électrique.

Si l'architecte dit : « Je me fiche de la stabilité, rendez-le parfait », le système se comporte comme un optimiseur standard et réorganise tout pour une efficacité maximale.
Mais si l'architecte fixe une limite stricte (« Gardez-le à 95 % familier »), le système agit comme un interrupteur de sécurité. Si le prochain meilleur déplacement violait cette règle des 95 %, le système s'arrête immédiatement. Il ne force pas un mauvais déplacement juste pour continuer à chercher ; il dit : « Nous avons atteint la limite, et nous nous arrêtons ici pour protéger la santé mentale de l'équipe. »

Les Résultats

Les auteurs ont testé cela sur un véritable système logiciel appelé Xwork (un framework Java).

Règles Souples : Lorsqu'ils ont permis au système d'être flexible, la négociation a trouvé une solution tout aussi bonne que les meilleurs outils existants.
Règles Strictes : Lorsqu'ils ont fixé une limite de stabilité stricte, le système a refusé avec succès de faire des déplacements qui violaient cette limite, agissant comme un « disjoncteur » pour imposer les volontés de l'architecte.

Pourquoi Cela Compte

L'article soutient que les outils précédents étaient « aveugles au budget » : ils ignoraient soit la stabilité, soit tentaient de l'intégrer dans un score unique avec des mathématiques arbitraires. Cette nouvelle méthode traite la stabilité comme une contrainte stricte qui peut être négociée.

Les auteurs ont prouvé mathématiquement que :

La négociation s'achèvera toujours (elle ne tournera pas indéfiniment).
Les agents agissent rationnellement, renonçant à la moindre part de leur propre objectif pour atteindre celui de l'autre.
Le résultat final est un compromis « localement optimal » qui respecte les limites de sécurité.

En bref, cet article transforme la réorganisation logicielle d'une « recherche de perfection » en un « compromis négocié » qui respecte le besoin humain de stabilité.

Résumé technique : Un protocole de consensus multi-agent pour la remodularisation logicielle stable

Énoncé du problème
Les approches actuelles de la remodularisation logicielle automatique formulent généralement la tâche comme un problème d'optimisation mono-objectif, visant souvent à maximiser des métriques structurelles comme TurboMQ afin d'améliérer la cohésion et de réduire le couplage. Bien que les métaheuristiques récentes aient amélioré l'efficacité de la recherche, ces méthodes échouent à résoudre une contrainte pragmatique critique : la stabilité évolutive. Une décomposition qui maximise la qualité structurelle mais qui diffère considérablement de la version précédente du système impose une lourde charge cognitive aux développeurs. Les outils existants sont « aveugles au budget », soit en ignorant la stabilité, soit en la fusionnant dans une somme pondérée fixe avec des coefficients arbitraires, manquant ainsi la capacité d'imposer des contraintes de stabilité strictes ou de s'adapter aux préférences spécifiques des parties prenantes.

Méthodologie : Protocole de concession monotone asymétrique (AMCP)
Les auteurs reformulent la modularisation logicielle non pas comme un problème d'optimisation statique, mais comme un problème de consensus distribué entre agents autonomes. Le cadre proposé introduit deux agents avec des fonctions d'utilité conflictuelles :

Agent de Cohésion ( $A_{coh}$ ) : S'efforce de maximiser la densité structurelle en utilisant une métrique TurboMQ normalisée.
Agent de Stabilité ( $A_{sta}$ ) : Cherche à préserver la disposition de la version précédente ( $D_{prev}$ ) en minimisant la distance Move-plus-Join (MoJo).

Le mécanisme central est le Protocole de Concession Monotone Asymétrique (AMCP). Dans ce protocole :

Asymétrie : L'Agent de Stabilité agit comme le seul proposant, reflétant le scénario de maintenance réel où l'architecture héritée est l'état par défaut. L'Agent de Cohésion accepte implicitement les mouvements qui améliorent la cohésion sans violer le seuil de stabilité.
Logique de concession : L'Agent de Stabilité évalue les réaffectations potentielles de modules uniques et sélectionne le mouvement qui minimise le Ratio de Concession ( $R(\delta)$ ). Ce ratio représente le coût en utilité de stabilité par unité de gain en utilité de cohésion.
Seuils : Le protocole impose des seuils de survie explicites ( $\tau_{sta}$ et $\tau_{coh}$ ). Si un mouvement viole le budget de stabilité ( $\tau_{sta}$ ), il est rejeté.
Terminaison : La négociation se termine lorsqu'aucun mouvement valide n'existe pour améliorer la cohésion tout en respectant le seuil de stabilité, ou lorsque l'ensemble des mouvements valides est épuisé.

Contributions clés

Modèle mathématique formel : L'article établit un modèle formel de la remodularisation logicielle comme un problème de consensus distribué entre des agents pilotés par l'utilité.
Le protocole AMCP : Les auteurs proposent l'AMCP, qui inclut des preuves formelles pour :
- Terminaison finie : Le protocole est garanti pour se terminer en un nombre fini d'étapes (borné par $n \cdot (k_{max} - 1)$ ), car il utilise l'Utilité de Cohésion comme fonction de Lyapunov stricte.
- Rationalité (Stratégie de Zeuthen) : Le comportement du protocole correspond à la Stratégie de Zeuthen, garantissant que les agents font les concessions minimales nécessaires pour satisfaire l'adversaire, en priorisant d'abord les concessions « bon marché ».
- Satisfaction Pareto locale : La partition résultante est localement Pareto-satisfaisante au sein du voisinage des mouvements uniques, ce qui signifie qu'aucune réaffectation unique ne peut strictement améliorer la cohésion sans violer le seuil de stabilité.
Analyse de complexité : L'approche élague efficacement l'espace de recherche, évaluant $O(n \cdot k)$ candidats par étape, contrairement à l'espace d'états exponentiel des métaheuristiques basées sur les populations.

Résultats expérimentaux
Des expériences préliminaires ont été menées sur un benchmark synthétique et le framework Java Xwork (113 classes, 10 packages).

Application du budget : Le protocole a imposé avec succès des budgets de stabilité stricts. Lorsque le seuil de stabilité ( $\tau_{sta}$ ) a été défini comme une contrainte contraignante (0,95), le protocole a tronqué la recherche tôt (3 étapes), préservant une utilité de stabilité de 0,9583, nettement supérieure à celle de l'optimiseur Bunch non contraint (0,9167).
Budgets lâches : Pour des budgets plus lâches ( $\tau_{sta} \leq 0,90$ ), les résultats étaient identiques au cas non contraint, indiquant que le protocole épuise naturellement toutes les améliorations structurelles avant que la stabilité ne devienne un facteur limitant.
Comparaison : Le consensus négocié correspondait aux optimiseurs de l'état de l'art (Bunch, CC/G) lorsque les contraintes de stabilité étaient lâches, mais agissait comme un « disjoncteur » lorsque des contraintes strictes étaient appliquées.
Efficacité : Une implémentation en Python a moyenné 1,24 seconde par étape sur le système Xwork, confirmant la faisabilité de l'approche.

Signification et revendications
L'article revendique un bond qualitatif en remplaçant la fusion statique et ponctuelle des résultats de clustering par une négociation dynamique multi-agent.

Contrôle architectural : La signification principale réside dans la capacité à imposer mathématiquement un « budget de stabilité » défini par l'architecte, garantissant que la disposition du système ne se dégrade pas simplement au nom de l'optimisation structurelle.
Garanties formelles : Contrairement aux approches heuristiques, ce cadre fournit des garanties formelles concernant la terminaison et le comportement de concession rationnelle.
Portée : Les auteurs notent que, bien que les résultats préliminaires soient prometteurs, une évaluation empirique plus extensive couvrant dix systèmes supplémentaires et des comparaisons avec des algorithmes évolutionnaires multi-objectifs (par exemple, NSGA-II) est reportée à un article complet à paraître. Le travail actuel sert de preuve de concept pour le paradigme de négociation au niveau du code.