Co-évolution de modèles d’architectures logicielles multi-niveaux

de définir des modèles d’architectures ayant trois niveaux d’abstraction distincts, afin de représenter séparément les décisions architecturales qui interviennent dans les phases principales du processus de développement d’une application (conception, implémen-tation, déploiement). Cette séparation des niveaux d’abstraction rend possible la réuti-lisation des modèles d’architectures abstraits pour définir, par raffinement, des archi-tectures concrètes (par exemple différentes implémentations ou différents déploiements d’un même type d’architecture). Pour prolonger cette possibilité de réutiliser des modèles d’architectures dans les processus de développement, nous avons étudié des mécanismes d’évolution de modèles d’architectures [98][97][96] [95].

L’objectif est de permettre soit la maintenance corrective ou adaptative d’une archi-tecture existante, pour prévenir son obsolescence [79][80], soit la production d’une nou-velle architecture dérivant d’une architecture existante, dans une approche opportuniste de "clone-and-own" (copie et modification) [57] ou disciplinée d’ingénierie de ligne de produits [15].

Gérer l’évolution des architectures consiste en particulier à prévenir les incohérences pouvant apparaître entre les différents modèles (niveaux d’abstration) définissant une même architecture, typiquement entre les modèles conceptuels (design-time) et les mo-dèles exécutés (runtime) ou entre les momo-dèles abstraits (spécifications) et les momo-dèles plus concrets (implémentations). Ces incohérences sont classiquement appelées érosion [87] et dérive (drift) [103]. L’érosion correspond à la violation de décisions architecturales définies par les modèles abstraits dans les modèles plus concrets. La dérive correspond à l’introduction de décisions architecturales dans un modèle concret, sans violer les déci-sions architecturales définies dans les modèles plus abstraits, mais sans mise-à-jour des modèles plus abstraits.

CHAPITRE 2. SYNTHÈSE DES CONTRIBUTIONS

Pour prévenir l’érosion et la dérive, nous avons choisi, parmi les différentes solutions possibles [43], de proposer un mécanisme de co-évolution des différents modèles défi-nissant une même architecture, basé sur une analyse d’impact et une propagation des changements.

Notre mécanisme de co-évolution met en œuvre le processus suivant :

— Analyse locale de l’impact des changements. Cette étape consiste à vérifier que les changements n’invalident pas la correction du modèle d’architecture sur lequel ils sont initiés, à un niveau d’abstraction donné, indépendamment des modèles cor-respondant aux autres niveaux d’abstraction. La correction intra-niveau sur des propriétés basées sur les relations intra-niveau liant les éléments au sein d’un même modèle d’architecture (voir la section2.1.2) telles que la connexité de l’architecture, la validité des connexions entre interfaces (compatibilité des types), la satisfaction des dépendances des composants (connexion des interfaces requises).

— Restauration de la correction (locale). Lorsque les changements réalisés impactent la correction du modèle d’architecture, des modifications complémentaires sont réalisées pour rétablir les propriétés qui ne sont plus vérifiées (suppressions/ajouts de composants ou de connexions). Nous parlons alors de propagation locale des changements (les changements initiaux sont préservés mais impliquent des chan-gements supplémentaires).

— Analyse globale de l’impact des changements. Une fois la modification initiale réa-lisée et vérifiée par les deux premières étapes, nous procédons à une vérification de la cohérence globale de la définition de l’architecture, fournie par les modèles correspondant aux différents niveaux d’abstraction. La vérification de la cohérence globale repose sur des propriétés liées aux relations inter-niveaux existant entre les différents modèles d’une architecture : le modèle de configuration d’une ar-chitecture doit être une implémentation de son modèle de spécification ; un mo-dèle de déploiement doit être une instanciation de son momo-dèle de configuration. Ces relations sont elles-mêmes basées sur des relations inter-niveaux existant entre les composants définissant les différents modèles d’une architecture. Par exemple, chaque rôle du modèle de spécification doit être implémenté dans le modèle de configuration par une classe de composants dont le type spécialise le type du rôle. Autrement dit, les classes de composants du modèle de configuration doivent être liées aux rôles du modèle de spécification par des relations d’implémentation. De même, chaque classe de composants du modèle de configuration doit être instan-ciée dans le modèle de déploiement, ce qui se traduit par des relations d’instan-ciation entre les instances de composants du modèle de déploiement et les classes de composants du modèle de configuration. Les problèmes de cohérence globale (érosion ou dérive) se traduisent ainsi par la non vérification des propriétés des relations inter-niveaux qui doivent être établies entre les modèles définissant les différents niveaux d’abstraction d’une architecture (donc par extension la non véri-fication des propriétés des relations inter-niveaux qui doivent être établies entre les composants appartenant aux différents modèles).

— Restauration de la cohérence (globale). A l’instar de la restauration de la cohérence locale, lorsqu’une incohérence globale est détectée, des modifications complémen-taires sont réalisées pour rétablir les propriétés qui ne sont pas ou plus vérifiées (suppressions/ajouts de composants ou de connexions). Nous considérons ces difications comme la propagation sur l’ensemble des niveaux d’abstraction des

mo-CHAPITRE 2. SYNTHÈSE DES CONTRIBUTIONS

difications initiées sur un premier niveau d’abstraction afin de restaurer la cohé-rence globale de la définition de l’architecture.

Ce processus est outillé grâce à la formalisation du métamodèle de Dedal en langage B [4], résultant en un nouveau métamodèle que nous appelons FormalDedal. D’un point de vue pratique (voir la figure2.14), nous avons intégré FormalDedal dans DedalStudio (voir la figure2.11) grâce à des transformations de modèles depuis et vers le métamodèle de Dedal, défini en EMF. D’un point de vue conceptuel, nous ne considérons pas avoir implémenté un ADL formel mais simplement défini et implémenté une sémantique for-melle pour notre ADL Dedal.

FIGURE2.14 – Formalisation de l’ADL Dedal avec l’outillage du langage B

Disposer d’un métamodèle formel permet d’utiliser l’outillage du langage B pour faire automatiquement la vérification des propriétés de correction et de cohérence sur les dé-finitions d’architectures produites avec Dedal.

Au-delà de ce premier niveau d’assistance, nous avons montré qu’il était possible d’utiliser un solver pour calculer automatiquement les modifications permettant de res-taurer les propriétés de correction et de cohérence d’un modèle d’architecture (voir la figure2.15).

Un modèle d’architecture Dedal peut être considéré comme une machines à états et les opérations de modification du modèle comme les règles de transition gérant l’évolu-tion de l’état du modèle. Définissant les modifical’évolu-tions initiales et le respect des propriétés de correction et de cohérence comme un objectif à atteindre, le solver explore automati-quement l’espace des états possibles afin de trouver un nouvel état qui restaure au besoin les propriétés de correction et de cohérence du modèle tout en conservant les modifica-tions souhaitées. Nous avons utilisé avec succès les solvers génériques fournis par l’envi-ronnement ProB mais également implémenté notre propre solver, en utilisant les API de ProB, afin de pouvoir y intégrer des heuristiques et accélérer les calculs.

La séquence d’opérations de modification ainsi générée permet de proposer automa-tiquement un plan d’évolution. La figure2.16présente l’exemple d’un plan d’évolution généré automatiquement pour un modèle de spécification d’architecture. Ce plan d’évo-lution permet de restaurer les propriétés de la relation d’implémentation devant exister

CHAPITRE 2. SYNTHÈSE DES CONTRIBUTIONS

FIGURE2.15 – Generation automatique de plans d’évolution à l’aide d’un solver B

entre le modèle de spécification et le modèle de configuration de l’architecture. Il consiste à déconnecter le rôle HomeOrchestrator, à le supprimer puis à ajouter et à connecter le rôle Luminosity ainsi qu’une variante du rôle HomeOrchestrator.

FIGURE2.16 – Exemple de plan d’évolution généré par DedalStudio

Il s’agit d’un autre exemple, dans nos travaux, d’assistance fournie par une approche de search-based software engineering [69] (voir la section2.2.1).

Ces mécanismes de co-évolution sont en partie détaillés par l’article présenté dans la section4.2.1et inclus dans l’annexeB.

CHAPITRE 2. SYNTHÈSE DES CONTRIBUTIONS

2.2.3 Construction automatique d’annuaires ou de bibliothèques de