Thèse - LISIC · 2013-06-06 · Ahmad, Mahmoud, Ali, Mokhtar. La liste est longue, et je demande pardon par avance à tous ceux que j’aurais oubliés. Qu’ils trouvent ici le

Université du Littoral Côte d’Opale

Laboratoire d’Informatique du Littoral

Thèse

pour l’obtention du titre de

Docteur de l’Université du Littoral Côte d’Opale

spécialité : Informatique

Contribution à l’analyse d’impact des

modifications des architectures

logicielles

Thèse soutenue le 15 Décembre 2009

par

MOHAMED OUSSAMA HASSAN

devant le jury composé de :

M. Noureddine BELKHATIR Université de Grenoble II (Examinateur)M. Nouredine MELAB Université de Lille I (Examinateur)M. Claude GODART Université Henri Poincaré, Nancy (Rapporteur)M. Jean-Paul BAHSOUN Université Paul Sabatier, Toulouse (Rapporteur)M. Henri BASSON Université du Littoral Côte d’Opale, Calais (Directeur)M. Laurent DERUELLE Université du Littoral Côte d’Opale, Calais (Co-directeur)

À mon père,à ma mère,

à mon oncle Fouad,à la mémoire de mon beau-père,

tous les quatre m’ont mis sur le bon chemin.À mes soeurs.

À la femme de ma vie quim’a accompagé et a motivé mes pas !

Remerciements

Mes remerciements vont avant tout aux membres de jury qui ont accepté d’évaluerce travail de thèse.

Je remercie vivement et particulièrement : M. Claude GODART, professeur à l’Uni-versité Henri Poincaré-Nancy et M. Jean-Paul BAHSOUN, professeur à l’UniversitéPaul Sabatier-Toulouse, qui ont accepté de juger ce travail et d’en être les rapporteurs.

Je tiens à exprimer ma reconnaissance à M. Noureddine BELKHATIR, professeur àl’Université Pierre Mendès France - Grenoble, et à M. Nouredine MELAB, professeurà l’Université de Lille I, pour avoir accepté de faire partie du jury.

Je tiens aussi à remercier M. Henri BASSON, directeur du laboratoire d’Informatiquedu Littoral, pour avoir dirigé mes travaux durant ces années de thèse et l’année deDEA ainsi que pour l’ensemble des conseils qu’il m’a prodigués. Son experience m’aété grandement profitable.

Je remercie Laurent DERUELLE pour son soutien de tous les jours qui m’a permisde mener à terme ces travaux. Je tiens tout particulièrement à lui exprimer ma plusprofonde gratitude pour avoir co-dirigé ces travaux et m’avoir soutenu dans cetteétude. La pertinence de ses remarques sur mes travaux de recherche et ses relecturesminutieuses m’ont beaucoup appris. Ses grandes compétences scientifiques et sapatience m’ont beaucoup appris. Je le remercie pour son extrême gentillesse et sadisponibilité de tous les instants.

Je remercie mes collègues au Laboratoire d’Informatique du Littoral pour les encou-ragements et l’aide qui m’ont permis de finir cette thèse et surtout ceux qui m’ontfait profiter de leur grande expérience et avec qui j’ai eu de nombreuses discussionsenrichissantes. Un merci particulier à Mourad.

Je souhaite aussi remercier toute la « B125 », mes compagnons de labeur qui ont sucontribuer à rendre ces années agréables en y maintenant une ambiance chaleureuse.

Je remercie du fond du cœur Ridha KERKENI, pour ses encouragements, ses conseilset sa gentillesse.

Je remercie mon père qui, dès mon enfance, m’a donné une force magique etimmense me conduisant à la réussite. Son soutien qui a commencé par mon enca-drement à l’écode et a fini par l’élaboration de ma thèse en passant par ses conseils,ses aides financières et morales, je ne saurais trouver l’expression requise pour leremercier. Tout ce que j’ai à te dire cher Père, c’est que ton rêve est réalisé.

v

Une seule ligne ne saurait transcrire ma gratitude envers ma mère, mes sœurs quim’ont offert leur amour et leur soutien pendant toutes ces années d’études.

Je remercie mon oncle Fouad qui a su toujours m’apporter du soutien quand j’enavais besoin.

Il est évident que je n’aurais pas pu terminer cette thèse sans l’appui indéfectible dema fiancé Hanaa. Je l’en remercie, pour son amour sans faille, du fond de mon cœuret je lui souhaite du bon courage pour sa thèse !

Je n’oublie pas non plus mes amis Libanais, grâce à qui le mal du pays a étéconsidérablement amoindri durant neuf années passées en France. Je remercie par-ticulièrement Rawad, Jari, Mhamad, Bob, Bilal, Ali, Hassan, Dani, Khalil, Bassem,Ahmad, Mahmoud, Ali, Mokhtar. La liste est longue, et je demande pardon paravance à tous ceux que j’aurais oubliés.

Qu’ils trouvent ici le témoignage de ma reconnaissance.

Calais, le 30 novembre 2009.

vi

Table des matières

Table des matières vii

1 Introduction 11.1 Cadre de la thèse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2 Contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.3 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.4 Organisation du document . . . . . . . . . . . . . . . . . . . . . . . . . 5

2 Architecture Logicielle 72.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.2 Architecture logicielle : de multiples définitions . . . . . . . . . . 9

2.3 Rôles des architectures logicielles . . . . . . . . . . . . . . . . . . . 10

2.4 Les Langages de Description d’Architecture : ADL . . . . . . . . . . 12

2.4.1 Présentation des ADLs . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.4.2 Concepts de base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.4.3 Les principaux ADLs . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.5 AADL : Architecture Analysis & Design Language . . . . . . . . . . 21

2.5.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.5.2 Modèles et spécifications de systèmes AADL . . . . . . . . . . . . . . 21

2.5.3 Types et implémentations . . . . . . . . . . . . . . . . . . . . . . . . 21

2.5.4 Catégories des composants . . . . . . . . . . . . . . . . . . . . . . . . 23

2.5.5 Les sous-composants . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2.5.6 Interactions entre les composants . . . . . . . . . . . . . . . . . . . . 24

2.5.7 Les flux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

2.5.8 Les modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

2.5.9 Les propriétés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

2.5.10 Les annexes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

2.5.11 Paquetage (Espace de noms) . . . . . . . . . . . . . . . . . . . . . . . 28

2.5.12 Ensembles de propriétés . . . . . . . . . . . . . . . . . . . . . . . . . 28

2.5.13 Exemple AADL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

2.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3 Problématique de l’évolution du logiciel 333.1 Maintenance du logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . 35

3.1.1 Approches pour l’évolution du logiciel . . . . . . . . . . . . . . . . . 36

3.1.2 Synthèse sur les approches pour l’évolution . . . . . . . . . . . . . . . 40

3.2 Evolution logicielle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

3.3 Dimensions de l’évolution logicielle . . . . . . . . . . . . . . . . . . 41

3.3.1 Portée de l’évolution . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

3.3.2 Jalons de l’évolution . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

vii

3.3.3 Initiateur de l’évolution . . . . . . . . . . . . . . . . . . . . . . . . . 42

3.4 Evolution des architectures logicielles . . . . . . . . . . . . . . . . 43

3.5 Analyse d’impact de changements . . . . . . . . . . . . . . . . . . . . . 44

3.5.1 Processus de conduite du changement . . . . . . . . . . . . . . . . . 45

3.5.2 Travaux sur l’analyse d’impact . . . . . . . . . . . . . . . . . . . . . . 46

3.5.3 Bénéfices de l’analyse d’impact . . . . . . . . . . . . . . . . . . . . . 49

3.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

4 Modélisation pour l’évolution des architectures logicielles 514.1 Critères d’évaluation des travaux existants . . . . . . . . . . . . . . 53

4.1.1 ArchStudio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

4.1.2 Mae . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

4.1.3 Archware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

4.1.4 SAEV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

4.1.5 Bilan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

4.2 SCSM : Software Component Structural Model . . . . . . . . . . . . 58

4.3 Modélisation à base de graphes . . . . . . . . . . . . . . . . . . . . . . 62

4.3.1 Représentation basée sur les graphes . . . . . . . . . . . . . . . . . . 62

4.3.2 Définitions formelles . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

4.4 Description des architectures à l’aide de graphes . . . . . . . . . . 63

4.5 Formalisation du modèle ASCM . . . . . . . . . . . . . . . . . . . . . . 63

4.5.1 Description du graphe de l’architecture . . . . . . . . . . . . . . . . . 65

4.5.2 Correspondances entre les éléments de ASCM et le graphe associé . . 67

4.5.3 Opérations pour la manipulation du graphe d’architecture . . . . . . 69

4.6 Mapping entre ASCM et SCSM . . . . . . . . . . . . . . . . . . . . . . . 71

4.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

5 Evolution et propagation d’impact de modification dans une

architecture logicielle 775.1 L’évolution des architectures logicielles . . . . . . . . . . . . . . . 79

5.2 Typologie des opérations de modifications architecturales . . . . 81

5.2.1 Ajout d’une interface d’un composant . . . . . . . . . . . . . . . . . . 81

5.2.2 Ajout d’une implémentation à un composant . . . . . . . . . . . . . . 82

5.2.3 Ajout d’un connecteur . . . . . . . . . . . . . . . . . . . . . . . . . . 83

5.2.4 Suppression d’un connecteur . . . . . . . . . . . . . . . . . . . . . . 84

5.2.5 Suppression d’une interface d’un composant . . . . . . . . . . . . . . 85

5.2.6 Suppression d’une implémentation d’un composant . . . . . . . . . . 87

5.2.7 Modification d’un connecteur . . . . . . . . . . . . . . . . . . . . . . 88

5.2.8 Changements d’interface . . . . . . . . . . . . . . . . . . . . . . . . . 90

5.2.9 Ajout d’une propriété . . . . . . . . . . . . . . . . . . . . . . . . . . 91

5.2.10 Suppression d’une propriété . . . . . . . . . . . . . . . . . . . . . . . 92

5.2.11 Changement de la valeur d’une propriété . . . . . . . . . . . . . . . . 93

5.2.12 Ajout d’un sous-composant . . . . . . . . . . . . . . . . . . . . . . . 94

5.2.13 Suppression d’un sous-composant . . . . . . . . . . . . . . . . . . . . 95

5.2.14 Changement du type de port de connexion . . . . . . . . . . . . . . . 96

5.3 Processus de propagation d’impact . . . . . . . . . . . . . . . . . . . . 97

5.3.1 Approches algorithmiques pour la propagation d’impact . . . . . . . 97

5.3.2 Approches basées sur les règles . . . . . . . . . . . . . . . . . . . . . 98

5.3.3 Définition d’un système expert (SE) . . . . . . . . . . . . . . . . . . . 98

5.3.4 Règles de propagation d’impact . . . . . . . . . . . . . . . . . . . . . 100

viii

5.3.5 Propagation d’impact de l’architecture vers le code source . . . . . . . 103

5.3.6 Illustration du processus de propagation d’impact . . . . . . . . . . . 104

5.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

6 Implémentation 1096.1 Présentation de la plate-forme Eclipse . . . . . . . . . . . . . . . . . 111

6.2 Architecture du système . . . . . . . . . . . . . . . . . . . . . . . . . . 112

6.2.1 L’analyseur de codes sources et de descriptions d’architectures multi-langages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

6.2.2 Le modeleur logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

6.2.3 Le système expert DROOLS . . . . . . . . . . . . . . . . . . . . . . . 114

6.2.4 Interface utilisateur . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

6.3 Scénario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

6.4 Analyse d’impact inter-modèles . . . . . . . . . . . . . . . . . . . . . . 129

6.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

7 Conclusion et perspectives 1357.1 Résumé des contributions . . . . . . . . . . . . . . . . . . . . . . . . . . 137

7.2 Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139

Liste des figures 141

Liste des tableaux 143

Bibliographie 145

ix

1Introduction

Sommaire

1.1 Cadre de la thèse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2 Contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.3 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.4 Organisation du document . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.1. Cadre de la thèse 3

1.1 Cadre de la thèse

Les travaux menés dans cette thèse ont été effectués au sein de l’équipe Multi Mo-délisation et Évolution du Logiciel (ModEL) du Laboratoire d’Informatique du

Littoral (LIL).Les travaux de l’équipe ModEL s’articulent autour du contrôle de l’évolution du lo-giciel. Ils ont pour principal objectif l’amélioration des processus de développementet d’évolution des logiciels ainsi que leur assurance qualité. De nombreux travaux,effectués au sein de l’équipe couvrant cette thématique, ont proposé des solutions derétro-ingénierie et d’analyse de l’impact de modification d’un logiciel (outils d’aideà la compréhension de programme, à l’analyse d’impact, etc.) en se basant sur unereprésentation des composants logiciels (au sein d’un modèle intégré) issus de plu-sieurs phases du cycle de vie ainsi que de leurs caractéristiques qualitatives et fonc-tionnelles [DBMB01, BMOB04, HDB+

05, Maw07].Le processus de développement et surtout d’évolution du logiciel étant central

pour l’équipe ModEL, néanmoins les travaux de l’équipe restent à leur début quandil s’agit de l’évolution de l’architecture logicielle. C’est dans ce contexte et pour mieuxaborder cette problématique que nous proposons, dans ce mémoire, les résultats dece travail de recherche.

1.2 Contexte

Le travail de recherche présenté dans ce mémoire se situe à l’intersection de deuxdisciplines :

– la première concerne les architectures logicielles,– la deuxième porte sur l’évolution et l’analyse d’impact de modifications du

logiciel.L’évolution et l’analyse d’impact de modifications des architectures logicielles sontles premiers objectifs de notre travail.Nous évoquons d’abord le contexte général adressé par la thèse.

Nous assistons au cours de ces deux dernières décennies au développement d’ap-plications à grande échelle, réparties et hétérogènes. En effet, la révolution informa-tique en matière de réseaux, de télécommunications ainsi que l’augmentation descapacités de traitement et de stockage ont engendré le développement des systèmesd’informations de plus en plus complexes et de croissance exponentielle. Dans cesens, l’approche par objets [Mey00], fondée sur les notions d’encapsulation, d’héri-tage et de polymorphisme a apporté une contribution majeure dans la manière deconcevoir et de programmer une application. Cependant, les objets n’ont que par-tiellement résolu les problèmes de réutilisation et de structuration des logiciels degrande taille. L’approche à base de composants (Component Based Software Engi-neering) [HC01] vise à combler les lacunes laissées par l’approche par objets en per-

4 1.3. Contributions

mettant une meilleure réutilisation et une expression simple de dépendances entremodules logiciels.

Avec l’approche par composant, une application est vue comme étant un assem-blage de composants. Ceux-ci sont interconnectés afin de répondre aux besoins fonc-tionnels du système. Ces deux informations (composants et connexions) sont au cœurde l’approche par composants et constituent les éléments de base de l’architecture lo-gicielle.

Les premiers travaux pour décrire les architectures logicielles ont fait naître leslangages de description d’architecture (ADL) qui ont offert un vocabulaire com-mun entre les différents acteurs d’un projet informatique. Pour illustrer ces concepts,de nombreux langages sont apparus tels que Rapide [LKA+

95], Unicon [SDK+95],

Wright [All97], Acme [GMW97], AADL [FLV03]. Chacun de ces ADLs dispose de sesspécificités, ses avantages et ses inconvénients [MT00].

Il est inévitable qu’un logiciel subisse des changements durant son cycle de vie,autrement il devient progressivement déphasé par rapport à l’évolution des besoinset des plate-formes. L’architecture logicielle peut être amenée à évoluer pour diversesraisons : ajout de fonctions, intégration de nouvelles technologies de programmationou de communication, modification de l’environnement d’exécution, etc. Le change-ment d’un composant logiciel affecte souvent les autres composants du système. Si ceprocessus n’est pas contrôlé, les changements peuvent avoir des effets inattendus etsurtout négatifs sur le comportement du système. La principale difficulté pour faireévoluer des architectures logicielles est d’être capable de tenir compte de l’impact duchangement appliqué à un composant.

1.3 Contributions

Notre objectif est de fournir un support au processus de l’évolution des archi-tectures logicielles. Nous proposons, dans ce cadre, le modèle ASCM (ArchitecturalSoftware Components Model) afin de représenter les architectures logicielles, indépen-damment du choix d’un langage de description architecturale. Nous représentonscette description architecturale à l’aide du formalisme de graphes en se basant surce modèle. Nous définissons ensuite un certain nombre d’opérations de modifica-tions pouvant survenir sur l’architecture. Ces opérations sont décrites par le biaisd’assertions dont le but est d’identifier l’impact d’une modification. Un processusde propagation de l’impact d’une modification à base de système expert est proposéensuite afin d’analyser cet impact. Cette propagation s’appuie sur le déclenchementde règles d’évolution. Enfin, nous proposons un couplage entre le modèle SCSM(Software Component Structural Model), présenté par L. Deruelle dans le cadre de sestravaux de thèse [Der01] et le modèle ASCM afin d’étudier l’impact des modificationsentre le niveau architectural et celui du code source (représenté dans SCSM).

1.4. Organisation du document 5

1.4 Organisation du document

Le document est organisé en trois parties. La première, incluant les chapitres 2 et3, porte sur la problématique abordée dans la thèse ainsi que sur l’état de l’art.

Dans la deuxième partie (Chapitre 4 et 5), nous présentons la solution proposée :la définition d’un modèle pour la représentation des descriptions architecturales etpour l’étude de l’évolution et de la propagation d’impact de modification.

La troisième partie décrit l’implémentation et la validation de la solution proposéeet elle est présentée dans le chapitre 6.

Pour conclure, nous effectuons un bilan des travaux effectués au cours de cettethèse et nous proposons des perspectives de travaux futurs.

Ci-après le contenu détaillé des chapitres :– Le chapitre 2 introduit la problématique des architectures logicielles. Il rappelle

les grands principes des Langages de Descriptions d’Architecture (ADLs) etdresse un bilan sur quelques ADLs présents dans la littérature. Un ADL serachoisi et servira d’exemple tout au long de cette thèse afin d’illustrer notreapproche.

– Le chapitre 3 présente la problématique de l’évolution logicielle ainsi que l’ana-lyse d’impact de modifications. Nous donnons un bilan sur les travaux effectuésdans le domaine de l’analyse d’impact afin de situer nos travaux et montrer leurapports.

– Le chapitre 4 est consacré à la description de notre modèle formel pour lareprésentation des architectures logicielles issue des langages de descriptionarchitecturale. Notre modèle s’appuie sur une formalisation à base de graphe.Celle-ci permettra la définition des règles associées à l’analyse d’impact. Nousutilisons le formalisme d’assertions pour décrire les opérations de manipulationdu graphe d’architecture.

– Le chapitre 5 est consacré à la description des opérations de modifications ar-chitecturales. Ces opérations seront formalisées par les assertions. Nous défi-nissons, dans ce chapitre, notre processus de propagation d’impact à base d’unsystème expert. Dans ce processus, nous définissons des règles génériques pourla réalisation des opérations de modification et pour la propagation d’impact.

– Le chapitre 6 décrit l’implémentation d’une plate-forme pour l’analyse de l’im-pact d’une modification opérée sur l’architecture d’un logiciel. Notre plate-forme s’appuie sur l’environnement de développement intégré Eclipse quenous avons étendu à l’aide de plusieurs plugins. Ceux-ci permettent l’analyselexicale et syntaxique de descriptions architecturales indépendamment des lan-gages utilisés afin de les représenter à l’aide du modèle ASCM. Ces représenta-tions sont insérées sous forme de connaissances dans un système expert. Cetteconnaissance est ensuite manipulée par des règles du système expert pour ana-lyser a priori l’impact d’une modification.

6 1.4. Organisation du document

– Le chapitre 7 décrit les contributions de cette thèse et les perspectives de re-cherche associées.

2Architecture Logicielle

Sommaire

2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.2 Architecture logicielle : de multiples définitions . . . . . . . . . . 9

2.3 Rôles des architectures logicielles . . . . . . . . . . . . . . . . . . . . . 10

2.4 Les Langages de Description d’Architecture : ADL . . . . . . . . . . 12

2.4.1 Présentation des ADLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.4.2 Concepts de base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.4.3 Les principaux ADLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.5 AADL : Architecture Analysis & Design Language . . . . . . . . . . 21

2.5.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.5.2 Modèles et spécifications de systèmes AADL . . . . . . . . . . . . . . . 21

2.5.3 Types et implémentations . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.5.4 Catégories des composants . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.5.5 Les sous-composants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2.5.6 Interactions entre les composants . . . . . . . . . . . . . . . . . . . . . . 24

2.5.7 Les flux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

2.5.8 Les modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

2.5.9 Les propriétés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

2.5.10 Les annexes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

2.5.11 Paquetage (Espace de noms) . . . . . . . . . . . . . . . . . . . . . . . . 28

2.5.12 Ensembles de propriétés . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

2.5.13 Exemple AADL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

2.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

2.1. Introduction 9

Avec la révolution informatique, les logiciels sont devenus de plus en plus com-plexes et évolutifs. Leur évolution exige un plus grand effort et un coût élevé.

En effet, les besoins des utilisateurs deviennent de plus en plus spécifiques, avec desexigences qualitatives plus importantes en sûreté de fonctionnement, services renduset en respect des coûts et des délais. Une conséquence directe est que l’organisationdes éléments qui composent le système logiciel ou l’architecture logicielle est devenueun enjeu primordial dans la conception et la construction de tout système logiciel.

Dans ce chapitre, nous définissons les concepts essentiels de l’architecture logi-cielle. Une introduction sur les langages de description d’architecture ADL (Archi-tecture Description Language) sera présentée afin de mettre en avant les concepts d’unhaut niveau d’abstraction communs aux différents ADLs. Ces concepts seront la basede notre modélisation des architectures logicielles et permettront leur représentationindépendamment des ADLs utilisés.

2.1 Introduction

Un problème critique dans la conception et la construction de tout système lo-giciel complexe est son architecture, c’est-à-dire l’organisation des éléments qui lecomposent.Une bonne architecture peut aider à mieux garantir que le système va satisfaire lesbesoins qualitatifs majeurs tels que la sûreté de fonctionnement, la fiabilité, la sécu-rité, la maintenabilité, la portabilité et l’interopérabilité. Garlan et al. montrent dansleurs travaux qu’une architecture mal conçue peut avoir des conséquences désas-treuses sur le système informatique [Gar00]. C’est pourquoi, au cours de la dernièredécennie, de nombreux travaux ont porté sur les architectures logicielles. Le rôle cri-tique des logiciels dans le bon fonctionnement des systèmes contribue à accentuercet intérêt.

2.2 Architecture logicielle : de multiples définitions

Il est largement admis qu’une architecture logicielle relève de la structure trèsabstraite d’un système et de l’organisation de logiciels. Cependant, il n’existe pas dedéfinition universellement acceptée pour ce terme. La littérature sur le sujet renvoieà de multiples acceptions. Nous en citons quelques unes :

– L’architecture logicielle implique la structure et l’organisation par lesquellesdes composants interagissent pour créer de nouvelles applications, possédantla propriété de pouvoir être les mieux conçues et analysées au niveau système[KOS06].

– Une architecture logicielle est l’organisation fondamentale d’un système incar-née, d’une part, par ses composants, leurs interactions et leurs relations, etd’autre part, par les principes guidant sa conception et son évolution [Gro00].

10 2.3. Rôles des architectures logicielles

– Une architecture logicielle est une vue du système qui inclut les composantsmajeurs du système, le fonctionnement de ces composants tel qu’il est vu par lereste du système et la manière dont les composants interagissent et collaborentafin d’accomplir la mission du système [CMC96].

– L’architecture logicielle est un niveau de conception qui implique la descrip-tion des éléments à partir desquels les systèmes sont construits, les interactionsentre ces éléments, les patrons (patterns) qui guident leur composition et lescontraintes sur ces patrons [GS93].

– L’architecture logicielle comprend la structure des composants d’un logi-ciel/système, les relations entre eux et les principes directifs régissant leurconception et évoluant au cours du temps [MG92b].

Enfin Perry et Wolf [Per92] souhaitent donner une directive fondamentale pour larecherche sur les architectures logicielles et proposent la définition des architectureslogicielles par le biais du modèle suivant :

Architecture logicielle = <Eléments, Forme, Raisonnement>

Ce triplet définit une architecture logicielle comme un ensemble d’éléments archi-tecturaux de trois types : les éléments de traitement, les éléments de données et leséléments de connexion. La forme représente des propriétés et des relations associéesà des poids. Les propriétés sont utilisées dans les contraintes associées aux éléments.Les relations sont utilisées pour contraindre la manière dont les éléments archi-tecturaux interagissent et sont organisés les uns par rapport aux autres. Le poidsindique l’importance de la propriété ou de la relation. Le raisonnement représente lamotivation pour choisir les styles architecturaux, les éléments et la forme. Un stylearchitectural permet de caractériser une famille de systèmes qui ont les mêmes pro-priétés structurelles et sémantiques [AAG93] (exemples : pipe-filter, client-serveur).

Toutes ces définitions se joignent sur le fait qu’une architecture logicielle est dé-finie par un ensemble de composants (ex : objets, bases de données, serveurs, etc.),ainsi que par la description de leurs supports respectifs de communication appelésdes connecteurs (ex : appels de procédures, envoi de message, émission d’événe-ments, des requêtes, etc.) et enfin par les principales directives et contraintes gouver-nant leurs conceptions et leurs futures évolutions.

2.3 Rôles des architectures logicielles

Les architectures logicielles jouent un rôle fondamental dans de nombreux aspectsdu développement logiciel [Gar00]. Il nous semble fort utile de résumer les enjeuxclassiquement mis en avant pour motiver l’émergence d’une approche architecturale :

2.3. Rôles des architectures logicielles 11

– L’architecture logicielle permet de rendre explicite les décisions concernant laconstruction et l’organisation des éléments de l’architecture et les raisons justi-fiant ces décisions. Ceci simplifie considérablement la compréhension du fonc-tionnement des systèmes complexes en les représentant à un haut niveau d’abs-traction.

– L’architecture offre un support pour la prise en considération de la réutilisa-tion des systèmes logiciels à de multiples niveaux (niveau des composants,niveau de la structure des composants, etc.). Des travaux existants dans des do-maines spécifiques tels que le DSSA (Domain-Specific Software Architecture), ontdéjà commencé à mettre en évidence ce fait [MG92a].

– La description précise de l’architecture est un facteur clé dans la réussite d’unprocessus de développement logiciel. Elle offre une base pour l’estimationdes coûts et la gestion de projet. L’évaluation de l’architecture implique unemeilleure compréhension des besoins, des stratégies d’implémentation et desrisques potentiels [BBHL95].

– La description architecturale fournit un plan partiel pour le développement enprécisant les composants principaux ainsi que leurs interdépendances.

– L’architecture permet de spécifier et de raisonner sur les propriétés qualitativesglobales du système (sécurité, performances, etc.). En outre, elle permet deréaliser des vérifications sur le respect de certaines contraintes de style et desvérifications de la consistance des systèmes [LKA+

95] et de conformité auxcontraintes imposées par les propriétés non fonctionnelles [Gro00].

Ces arguments font apparaître clairement le rôle joué par la description de l’ar-chitecture au sein d’un processus de développement d’un système logiciel. Cettedescription de l’architecture constitue une spécification abstraite du système qui està concevoir ou offre une partie de la description détaillée du système opérationnel.

Les architectures des systèmes logiciels ont pour longtemps été spécifiées infor-mellement, par le biais de diagrammes représentant les composants logiciels pardes « boîtes » et leurs interactions par des flèches. Or, cette description utilisantces simples diagrammes peut présenter des difficultés quant à leur interprétationsémantique, ce qui produit une ambiguïté dans la compréhension de l’architecturedes systèmes [AAG95]. Les systèmes devenant de plus en plus complexes, le fait dedéterminer si leur implémentation satisfait bien leur description architecturale estdevenue une tâche de plus en plus compliquée. Afin de définir précisément et demieux comprendre l’architecture des systèmes logiciels, de nombreux travaux pro-posent d’utiliser une structure permettant d’associer des sémantiques formelles auxdiagrammes architecturaux. C’est dans cet objectif que les langages de descriptiond’architecture ADLs (Architecture Description Language) ont été proposés. Dans la sec-tion suivante, nous définissons les langages de description d’architecture.

12 2.4. Les Langages de Description d’Architecture : ADL

2.4 Les Langages de Description d’Architecture : ADL

Les premiers travaux effectués pour la description des architectures logiciellesont abouti à l’avènement des langages de description d’architecture (ADL). L’idéede base de ces ADLs est de fournir une syntaxe et une sémantique formelle pourmodéliser l’architecture logicielle.

Dans cette section, nous présentons les concepts fondamentaux des différentsADLs. Nous dressons ensuite un bilan sur les principaux ADLs proposés par les tra-vaux de recherche en architecture logicielle afin de ressortir leurs concepts communsqui représenteront les éléments de notre modèle. Nous présentons ensuite séparé-ment et en détail l’ADL qui illustrera notre approche.

2.4.1 Présentation des ADLs

La communauté de l’ingénierie du logiciel a proposé des techniques pour la des-cription de l’architecture des systèmes pour répondre aux besoins en terme de réuti-lisation, aux problèmes rencontrés par les concepteurs de logiciels de grandes tailleset aux problèmes issus de la spécification informelle et intuitive des architectureslogicielles. Ces techniques se sont alors concrétisées par des langages de descriptiond’architecture (ADL) et par un outillage associé [MT00].Ces langages permettent de spécifier, avec une meilleure précision, l’architecture dessystèmes et définissent un vocabulaire précis et commun pour les acteurs (architectes,concepteurs, développeurs, intégrateurs et testeurs) devant travailler autour de laspécification liée à l’architecture. Les composants de l’architecture sont spécifiés demanière abstraite sans entrer dans des détails d’implémentation, tout en définissantde manière explicite les interactions entre les composants d’un système. Ceci offreun support de modélisation pour aider les concepteurs à composer les différentséléments de l’architecture. Les ADLs peuvent être vus comme un support pour ladescription de la structure de l’application. Ils offrent des facilités de construction etde déploiement ou encore de gestion de configuration, c’est-à-dire la façon dont lescomposants interagissent afin d’accomplir la mission du système. En plus, ils amé-liorent la compréhension des systèmes complexes et favorisent leur évolution et leurréutilisation.Les ADLs sont en général graphico-textuels et possèdent des outils associés.

2.4.2 Concepts de base

Les concepts de base qui forment une description architecturale sont commu-nément appelés les 4C : le Composant, le Connecteur, la Configuration et lesContraintes. La figure 2.1 montre un exemple d’une représentation architecturale réa-lisée à l’aide d’un ADL, dans laquelle deux composants communiquent à l’aide d’unconnecteur, au sein d’une configuration. Les contraintes n’apparaissent pas sur la

2.4. Les Langages de Description d’Architecture : ADL 13

Fig. 2.1 – Exemple d’architecture avec un ADL

figure du fait qu’elles peuvent être exprimées au niveau des composants, du connec-teurs et/ou de la configuration.

Medvidovic et Taylor [MT00] ont défini un cadre de comparaison pour la plu-part des ADLs existants dans lequel ils proposent un ensemble de caractéristiquesglobales pour chaque élément. Ces caractéristiques sont également un moyen pourl’évaluation des ADLs et sont considérées comme un ensemble de critères que doitprendre en compte un langage afin qu’il soit considéré comme étant un langage dedescription d’architecture. Nous explicitons, dans ce qui suit, les définitions et lescaractéristiques sous-jacentes à la description d’une architecture et qui doivent faireparties d’un ADL.

2.4.2.1 Le composant

Un composant est une entité logicielle qui permet le traitement ou le stockage dedonnées. C’est une entité dynamique dont l’état évolue dans le temps, en fonction dessollicitations qu’elle reçoit. Un composant peut être simple ou composé. Sa fonction-nalité peut aller de la simple procédure à une application complète. Les différentescaractéristiques globales d’un composant sont :

– La composition du composant offre la possibilité de le modéliser à différentsniveaux de détails. Ainsi, le composant composite (ex : une application) peutêtre constitué d’autres composants, jusqu’au composant primitif ou non dé-composable (ex : une procédure simple).

– L’interface d’un composant constitue l’ensemble de ses points d’interactionsavec les autres composants du système. Les points d’interaction peuvent être,par exemple, des ports de communications ou de paramètres passés à l’appeld’un sous-programme. L’interface regroupe l’ensemble des services offerts etrequis par le composant (ex : messages, opérations) et exprime des contraintesquant à son utilisation. Tous les ADLs supportent la spécification des interfacesbien qu’elles diffèrent dans leur terminologie.

– Le type d’un composant fournit un moyen de décrire explicitement les proprié-tés communes à un ensemble d’instances d’un même composant. La notion de


type représente des abstractions des fonctionnalités en vue de leur réutilisationsoit dans une même architecture, soit dans des architectures différentes. Cettenotion peut être comparée à la notion de classe que l’on trouve dans le modèleorienté objet.

– La sémantique d’un composant permet de l’exprimer en spécifiant son com-portement d’une manière plus complète. Elle s’apparente à la notion de typedans le modèle orienté objet.

– Les contraintes définissent les limites d’utilisation du composant. Il s’agit desassertions ou des propriétés physiques qui ne doivent pas être violées. Lors-qu’une contrainte est violée, le système est considéré alors dans un état inco-hérent. Un exemple de contraintes, est la charge maximale d’un composant.Celle-ci définit le nombre maximal de relation d’appel qu’un composant peutsupporter.

– L’évolution d’un composant doit être simple. Elle peut se traduire par un chan-gement opéré au niveau de ses caractéristiques tels que son interface, son com-portement ou son implémentation. Ces changements doivent être effectués sansperturber l’intégration du composant dans son environnement.

– Les propriétés non fonctionnelles représentent des exigences qui découlent dela spécification du comportement. Ces propriétés incluent, par exemple, la ro-bustesse, la performance, la sûreté de fonctionnement, la fiabilité et la disponi-bilité.

2.4.2.2 Le connecteur

Le connecteur modélise les interactions entre les composants et les lois qui ré-gissent ces interactions. Il permet de vérifier l’intégrité de la communication, c’est-à-dire assurer que les composants puissent interagir. En outre, un connecteur peutdécrire des interactions simples de type appel de procédure ou accès à une variablepartagée, mais aussi des interactions complexes telles que des protocoles d’accès àdes bases de données.Les caractéristiques associées aux connecteurs sont les mêmes que celles définiespour les composants [MT00] :

– L’interface définit l’ensemble des points d’interactions entre connecteurs etcomposants. Cependant, elle ne décrit pas de services fonctionnels comme ceuxdu composant, mais s’attache à décrire des mécanismes de connexion entre lescomposants. Dans certains ADLs, les points d’interaction des connecteurs sontnommés des rôles.

– Le type d’un connecteur correspond à sa définition abstraite qui reprend lesmécanismes de communication entre les composants ou les mécanismes decoordination et de médiation. Il permet de décrire la description d’interactions


simples ou complexes de manière générique. Par exemple, un connecteur peuttransporter des données, des événements ou les deux.

– La sémantique est, comme pour les composants, définie par un modèle de hautniveau décrivant le comportement du connecteur. Contrairement à la séman-tique des composants qui doit exprimer les fonctionnalités déduites des butsou des besoins de l’application, la sémantique du connecteur doit spécifier leprotocole d’interactions.

– Les contraintes permettent de définir les limites d’utilisation des connecteurset d’établir les dépendances entre les connecteurs.

– Les connecteurs sont susceptibles d’évoluer continuellement, ceci sans pertur-ber leur utilisation et intégration dans des applications existantes.

– La spécification des propriétés non fonctionnelles telles que la fiabilité, la dispo-nibilité, ou la performance peut s’avérer indispensable dans le but de garantirla qualité de service du connecteur.

2.4.2.3 La configuration

La configuration d’architecture décrit la structure et le comportement de l’ar-chitecture formée de composants et de connecteurs, c’est une sorte de graphe deconnexion qui les relie ensemble.Un ADL doit fournir les possibilités de configuration suivantes [MT00] :

– Une configuration doit être compréhensible, c’est-à-dire elle doit fournir unesyntaxe simple et une sémantique claire permettant de faciliter la communica-tion entre les différents acteurs du projet.

– La composition, ou plus précisément la possibilité de décrire les architecturesà différents niveaux de détails de composition. Il s’agit d’une composition hié-rarchique, dans laquelle le composant primitif est une unité non décomposableet le composant composite est constitué de composants (primitifs ou non).

– La configuration est un moyen pour le raffinement de l’application d’un niveauabstrait de description vers un niveau de description plus détaillé. Il est aussipossible de garder des traces de ce qui a été fait en amont et de créer desliens entre les différents niveaux de description de l’application. Ceci permetle rapprochement entre les modèles de haut niveau et le code source d’uneapplication.

– La définition de la configuration d’une application doit permettre de spéci-fier une architecture indépendamment du langage de programmation et dusystème d’exploitation. Un ADL doit permettre le développement de grandssystèmes avec des composants et des connecteurs ayant des caractéristiquesdifférentes.

– L’évolution des technologies et des besoins font qu’un système sera amené à


évoluer. La configuration doit être capable d’évoluer pour intégrer de nouvellesfonctionnalités ou une mise à jour de celles-ci. Elle doit permettre l’ajout, leremplacement, la suppression et la reconnexion des composants et des connec-teurs. Or, les ADLs ne fournissent pas ou peu d’outils pour le contrôle del’évolution.

– L’aspect dynamique de l’application implique que sa configuration doit per-mettre la mise en œuvre d’une modification pendant l’exécution des systèmesnécessitant des temps d’exécution longs ou pouvant être difficilement arrêtés,tels que les applications de gestion de trafic aérien ou les systèmes d’informa-tions publics. En effet, l’arrêt de tels systèmes critiques à des fins de mise à jourpeut conduire à des retards inacceptables et par conséquent à des situationstrès coûteuses.

– Les contraintes liées à la configuration complètent celles définies pour chaquecomposant et chaque connecteur. Généralement, elles décrivent les dépen-dances entres les composants et les connecteurs et concernent des caractéris-tiques liées à l’assemblage de composants. Les contraintes de configurationsont dites globales, et peuvent s’appliquer à tous les éléments de l’application.

– Les propriétés non fonctionnelles associées à la configuration peuvent être in-dispensables pour la sélection des composants et des connecteurs appropriés,pour l’analyse et l’évaluation de la qualité de service ou pour la gestion duprojet.

2.4.3 Les principaux ADLs

La majorité des ADLs qui ont émergé ces dernières décennies partagent les troisconcepts essentiels à la modélisation architecturale [MT00]. Cependant, chacun s’in-téresse à une famille d’architecture particulière ou à un domaine donné et de ce fait, ilreprésente une approche particulière de spécification. Par exemple, le langage AADLest conçu principalement pour les systèmes embarqués temps-réels.Ils existent plusieurs familles de langages de description d’architecture [DF06], nouscitons parmi lesquelles les deux familles les plus proches de nos besoins :

Les ADLs formels : ils permettent de décrire formellement une architecture. Ils sup-portent les notions de composant et de connecteur de manière abstraite sansindiquer leurs correspondances/projections dans le système. Parmi ces ADLs,nous trouvons Wright [All97], Rapide [LKA+

95] et ACME [GMW97].

Les ADLs concrets : ils reflètent davantage la réalité que les langages formels. Ilsspécifient la notion de composant en introduisant plusieurs catégories cor-respondant chacune à des entités logicielles ou matérielles. Parmi les ADLsconcrets, nous citons UniCon [SDK+

95] et AADL [FLV03].

Ces deux familles regroupent les aspects nécessaires pour notre approche : l’as-pect formel et primordial pour la modélisation des architectures et leur vérification,


l’aspect concret permettant à partir d’une description d’architecture de générer lecode source correspondant puis de collecter des mesures qualitatives quant à leurfonctionnement sur une architecture physique.

Nous présentons, dans ce qui suit, les ADLs de ces deux familles afin de dégagerles concepts communs à adopter dans notre modèle.

2.4.3.1 Wright

Le langage Wright [All97] a été développé à l’Université Carnegie Mellon en 1997.Il repose sur les concepts de composant, connecteur, configuration et de style pourformaliser une architecture logicielle.

Le composant Wright : Il est une unité de traitement abstraite localisée et indépen-dante. Il est décrit en deux parties : la première, l’interface, contient la des-cription des ports, c’est-à-dire les interactions auxquelles le composant peutparticiper, la deuxième correspond à la partie calcul qui consiste à décrire lecomportement du composant en indiquant la façon dont celui-ci utilise lesports. Une description formelle basée sur le langage CSP (Communicating Se-quential Processes) [BHR84] est associée à chaque port et permet de spécifier soncomportement par rapport à l’environnement.

Le connecteur Wright : Il représente une interaction entre un ensemble de compo-sants. De la même façon qu’un composant est défini, un type de connecteur estdécrit en deux parties :

1. Dans la première, un ensemble de rôles est défini pour décrire le compor-tement d’un composant qui participe à l’interaction. La spécification desrôles est exprimée en CSP.

2. Dans la seconde, la spécification d’assemblage est représentée pour décrirela coordination des activités des rôles.

La configuration Wright : Elle offre un moyen pour décrire l’architecture complèted’un système en regroupant des instances de composants et des instances deconnecteurs. La description d’une configuration est composée de trois parties :(1) la déclaration des composants et des connecteurs, (2) la déclaration desinstances de composants et de connecteurs, et enfin (3) les descriptions desliens entre les instances de composants par les connecteurs.Le langage Wright permet la composition hiérarchique. De cette manière, uncomposant (connecteur) peut être composé d’un ensemble d’autres composants(connecteurs).

Le style : Le style d’une architecture permet de décrire un ensemble de propriétéscommunes à une famille de systèmes comme, par exemple, les systèmes tempsréels ou les systèmes de gestion financière. Ainsi, Wright a la capacité de définirde nouveaux types de connecteurs et de composants pour une famille d’archi-tecture.


Wright n’offre aucun environnement pour la génération de code, ni de plate-forme permettant de simuler l’application.

2.4.3.2 RAPIDE

RAPIDE [LKA+95] est un langage de description d’architecture qui a pour but

initial de vérifier, par la simulation, la validité d’une architecture logicielle donnée.La construction d’une application avec RAPIDE s’effectue à partir des modules ou decomposants qui communiquent par l’intermédiaire de messages ou d’événements.“Événement, Composant et Architecture” représentent les concepts de base du lan-gage RAPIDE. L’événement est une information transmise entre les composants. Ilpermet de construire des expressions appelées événement type (event patterns) quicaractérisent les événements émis entre composants.Le composant ou le module est caractérisé par une interface qui définit l’ensembledes services fournis ou requis par le module et contient également la description ducomportement du module. Cette dernière correspond au fonctionnement du compo-sant, comme par exemple, l’ordonnancement des événements ou des appels aux ser-vices. La communication entre les composants peut être synchrone ou asynchrone.L’architecture contient la déclaration des instances de composants et les règles deconnexions entre ces instances. Toutes les instances sont déclarées sous forme de va-riables. Des contraintes peuvent être associées à la description de l’architecture afinde restreindre son comportement.RAPIDE fournit un environnement d’exécution composé d’un simulateur permettantde vérifier la validité de l’architecture. Ceci permet d’exprimer la dynamicité d’uneapplication avec, par exemple, la création ou la suppression du schéma d’instancia-tion du composant.

2.4.3.3 ACME

ACME [GMW97] est un langage de description d’architecture qui a pour but prin-cipal de fournir un langage pivot, facilitant ainsi les échanges entre différents ADLs.Il fournit une structure générique extensible pour la représentation, la génération etl’analyse de descriptions d’architecture.ACME se base sur sept types d’entités pour décrire une architecture : les composants,les connecteurs, les systèmes, les ports, les rôles, les représentations et les cartes dereprésentations (representation map) :

1. Le composant représente l’unité de traitement d’une application. Il est composéd’une interface constituée de ports.

2. Les ports représentent les points d’interaction entre différents composants. Ilpeut s’agir, par exemple, d’une simple signature d’une méthode ou d’une col-lection de procédures devant être appelées dans un ordre précis.


3. Le connecteur représente l’interaction entre deux composants. Il correspond àun médiateur de communication qui coordonne les interactions entre les com-posants. Les connecteurs peuvent être, par exemple, un protocole d’appel deprocédures à distance RPC(Remote Procedure Call)1 ou un bus ORB (Object Re-quest Broker) [GGM97]. Un connecteur est composé d’un ensemble de types derôles tels que le rôle client et le rôle serveur.

4. Le rôle définit un participant à la connexion. Par exemple, pour un connecteurpermettant la transmission de messages, les rôles “sender” et “receiver” peuventêtre définis pour indiquer respectivement l’émetteur et le récepteur du messageenvoyé.

5. Le système représente la configuration d’une application, c’est-à-dire l’assem-blage structurel entre les composants et les connecteurs.

6. Les composants et les connecteurs peuvent être décrits d’un niveau général à unniveau plus détaillé et peuvent donc être raffinés. Chaque nouvelle descriptiond’un élément est appelée une représentation.

7. La carte de représentation spécifie la correspondance entre un élément de l’ar-chitecture et ses représentations. La représentation et la carte de représentationpermettent à ACME de supporter la description hiérarchique d’une architec-ture.

2.4.3.4 UniCon

UniCon (Universal Connector Support) [SDK+95] est un langage de description

d’architecture élaboré à l’Université de Carnegie Mellon. Il se base sur deux typesd’éléments : le composant et le connecteur. Ces deux concepts ont les mêmes pro-priétés à l’exception que les connecteurs ne sont pas composites tandis que les com-posants peuvent l’être.Dans Unicon, un composant est une entité d’encapsulation des fonctions d’un mo-dule logiciel ou des données. Son interface définit les services requis et fournis parle composant. L’implémentation d’un composant permet de décrire le lien entre l’in-terface du composant et sa mise en œuvre physique (code source ou binaire). Lescomposants sont associés à des types permettant de leurs imposer des restrictionsd’accès. Un composant peut être de type Process si tout ce qu’il encapsule est contenudans un processus particulier à l’exécution. Il peut être de type SeqFile s’il représenteun fichier.Le connecteur permet de spécifier les règles d’interconnexion de composants. Il estcaractérisé par un type de connecteur et une implémentation. La définition d’unconnecteur ressemble à celle d’un composant. Chaque connecteur est spécifié par unprotocole qui définit les points de branchements autorisés pour les composants ; cespoints d’entrées ou de sorties sont définis par des rôles décrits par un nom, un type et

1http ://www.javvin.com/protocolRPC.html


d’autres attributs tels qu’une spécification fonctionnelle ou des contraintes d’utilisa-tion. Un protocole est défini par un type qui décrit le moyen d’accès aux informationscontenues dans les composants.

2.4.3.5 Synthèse sur les ADLs par rapport à l’évolution

Les ADLs n’utilisent pas les mêmes terminologies. Cependant, ils permettent despécifier un composant, son interface et son type et ses interactions avec les autrescomposants d’une architecture. L’approche proposée par la plupart des ADLs est plu-tôt statique ; le comportement dynamique de l’application n’est pas, ou peu, exprimé.

Ces langages de description ne permettent pas de faire évoluer une architecturevers une nouvelle configuration non définie au moment de la création de l’applica-tion correspondante. C’est pourquoi nous proposons, dans le chapitre 4, un modèlequi prend en compte les concepts communs de ces différents ADLs et propose uneapproche pour la gestion de l’évolution et l’analyse d’impact de modifications.

2.4.3.6 Illustration de l’évolution des architectures

Les ADLs ont pendant longtemps souffert de leur approche très académique,peu utilisée par le milieu industriel. Ce manque d’utilisation s’explique par l’absencependant longtemps de langage standardisé. Récemment, la prise en compte duconcept de composant dans le langage UML (Unified Modelling Language) [RJB05]de l’OMG (Object Management Group) pour la conception d’application par objetset l’avènement du langage AADL (Architecture Analysis & Design Language) défini parla SAE 2 (Society of Automative Engineer), organisme de standardisation mondialedans le domaine du transport, ont montré le besoin pour les industriels de disposerd’un langage de description d’architecture standardisé.

Pour illustrer notre approche tout au long de ce manuscrit, nous avons choisid’utiliser le langage AADL. Un des atouts d’AADL réside dans sa prise en comptede plusieurs sémantiques du composant, entre autres, la description des élémentsmatériels qui sont peu définis dans les autres ADLs. De plus, il permet de spécifierl’architecture d’une application de manière assez détaillée. Il permet aussi par le biaisde la notion de “propriété” d’enrichir les descriptions par des aspects fonctionnelstels que spécifier un code source pour implémenter un composant et non fonctionnelscomme la période ou le temps d’attente. Ceci nous permet d’exprimer à la fois lesexigences de l’utilisateur et les paramètres de déploiement et de configuration dusystème.

AADL assure déjà une large satisfaction auprès des industriels, et particulière-ment dans le domaine du transport.

2http ://www.sae.org/

2.5. AADL : Architecture Analysis & Design Language 21

Par ailleurs, des travaux récents ont été effectués permettant la spécification et lagénération automatique des systèmes à partir d’une description architecturale avecAADL [Ver06]. Nos travaux visent à exploiter ce point dans le cadre de la gestionde la propagation d’impact de modification entre le niveau architectural et le niveaucode source.

Dans la section suivante, nous présentons le langage standard AADL.

2.5 AADL : Architecture Analysis & Design Language

AADL est un langage de description d’architecture destiné principalement auxsystèmes distribués temps-réel qui découle de MetaH [Ves98]. AADL est un standardinternational publié par la SAE. Il joue un rôle principal dans plusieurs projets telsque COTRE [FBB+

03], Topcased [PF05] ou ASSERT 3.

2.5.1 Description

AADL est un langage d’analyse et de conception d’architecture. Il a pour objectifprincipal la description du logiciel ainsi que sa plate-forme d’exécution, autrementdit, la description de l’architecture globale du système au niveau matériel et logiciel.AADL est à l’origine défini par différents partenaires du domaine de l’avionique,d’où son appellation d’origine qui était Avionics Architecture Description Language. Enpratique, AADL s’adresse à tous les systèmes embarqués temps réel et n’est plusrestreint aux systèmes avioniques.La description d’une architecture en AADL consiste en la description de ses compo-sants et leur organisation sous forme d’une arborescence. L’architecture est la com-position récursive des composants et de leurs sous-composants.

2.5.2 Modèles et spécifications de systèmes AADL

Une spécification AADL et ses déclarations peuvent être exprimées textuellement,graphiquement ou bien en XML (eXtensible Markup Language). Les notations gra-phique et textuelle de AADL sont définies par le standard SAE AADL et ses exten-sions [FLV04]. La forme XML est définie dans eXtensible Markup Language (XML)1.0 (Troisième édition) [W3C04]. La figure 2.2 montre la représentation d’une spécifi-cation AADL selon les points de vue textuel, graphique et XML.

2.5.3 Types et implémentations

La description d’un composant AADL s’effectue en deux phases. La premièrephase définit le type qui correspond à l’interface fonctionnelle du composant. Lesports d’un composant sont définis dans son interface. La seconde, l’implémentation,

3Assert website, http ://www.assert-online.net

22 2.5. AADL : Architecture Analysis & Design Language

Fig. 2.2 – Description d’une représentation AADL

décrit le contenu du composant. L’implémentation d’un composant spécifie sa struc-ture interne en terme de sous-composants, des interactions (appels et connexions)entre ses sous-composants, des modes qui représentent ses états opérationnels et en-fin des propriétés. À une interface peuvent être associées, zéro, une ou plusieursimplémentations. Toutes les implémentations d’un composant réalisent la même in-terface.L’intérêt de scinder une description d’un composant en type et implémentation estde séparer deux points de vue. Le premier point consiste à offrir une vue orientéeservice aux autres composants en décrivant le type qui correspond à la spécifica-tion de l’interface du composant. En revanche, l’implémentation représente une vueinterne du composant non visible par les autres composants. Dans la pratique, ladescription du type et de l’implémentation pourront être faites par des personnesdifférentes, chacune ayant en charge une étape dans le raffinement de la descriptionde l’architecture, du plus haut niveau jusqu’aux moindres détails.Il est possible de décrire les composants AADL en fonction d’autres composants déjàexistants. Le langage offre deux mécanismes pour réaliser cette tâche :

1. L’extension : un type de composant étend un autre type de composant et ac-quiert ainsi tous ses éléments d’interfaces, ses flux et ses propriétés. Ce méca-nisme ressemble à l’héritage entre classes dans une description orientée-objet.Une implémentation d’un composant étend soit une autre implémentation dumême composant, soit une implémentation d’un composant parent. Dans lesdeux cas, elle acquiert l’ensemble de la structure interne de l’implémentationétendue (sous-composants, appels de sous-programmes, connexions, proprié-tés, etc.).

2. Le raffinement : un composant qui étend un autre, a la possibilité de raffinerles entités (éléments d’interface, sous-composants, etc.) dont il vient d’hériter.


Fig. 2.3 – Extension des composants AADL

La figure 2.3 illustre ces mécanismes entre les composants AADL. Le type de com-posant “Composant2” étend le type de composant “Composant1” et par conséquenthérite ses fonctionnalités. Les deux implémentations “Composant2 Implémentation1”et “Composant2 Implémentation2” correspondent à l’implémentation du même type decomposant “Composant2”. “Composant2 Implémentation1” étend également une implé-mentation de son parent (Composant1 Implémentation).

2.5.4 Catégories des composants

En plus d’être typé, chaque composant AADL appartient à une catégorie prédéfi-nie. Ces catégories représentent la nature des éléments manipulés. Elles sont prédé-finies et se décomposent en trois grandes familles :

– les composants logiciels qui définissent les éléments applicatifs de l’architec-ture ;

– les composants de la plate-forme d’exécution qui modélisent les éléments ma-tériels ;

– les systèmes qui permettent de regrouper différents composants (matériels oulogiciels).

Dans notre travail, nous ne tiendrons pas compte de la catégorie matérielle, du faitque nous nous focalisons sur l’évolution structurelle d’une architecture logicielle.

2.5.4.1 Composants logiciels

Il existe cinq catégories de composants logiciels :– les processus (process) ;– les fils d’exécution (thread) ;– les groupes de threads (thread group) ;– les données (data) ;– les sous-programmes (subprogram).

Les processus représentent des espaces mémoires pour l’exécution des threads. Lesthreads représentent les éléments logiciels actifs. Ils représentent les unités d’exécu-tions pouvant s’exécuter en parallèle. Les groupes de threads permettent de regrouper


un ensemble de threads partageant des mêmes propriétés. Ils servent également à in-troduire une hiérarchie entre les threads. Les données représentent les structures dedonnées qui peuvent être stockées ou échangées entre les composants. Un composantde ce type est atomique, c’est à dire il ne peut pas contenir d’autres composants. En-fin, les sous-programmes représentent le code exécutable, comme les procédures dansles langages impératifs de programmation. Un sous-programme peut être appelé de-puis un autre sous-programme ou un thread, et il est atomique.Les threads et les sous-programmes correspondent à la partie logicielle d’une ar-chitecture. Les sous-programmes représentent des éléments réactifs, pilotés par lesthreads. Un processus doit contenir un thread et parallèlement un thread doit êtrecontenu dans un processus.

2.5.4.2 Systèmes

Les systèmes AADL permettent de rassembler différents composants pour formerdes blocs permettant la structuration de l’architecture. Contrairement aux autres ca-tégories de composants, la sémantique des systèmes n’est pas associée à des élémentsprécis.

2.5.5 Les sous-composants

Un sous-composant représente une instance d’un composant contenue dans unautre composant, c’est-à-dire déclaré dans la définition de l’implémentation d’uncomposant. De cette façon, on obtient une description d’architecture AADL hiérar-chisée : une modélisation AADL est une arborescence de composants interconnectés.Un sous-composant doit être associé à une catégorie, un type ou une implémentationde composant, ce qui permet d’apporter plus de précision dans la description archi-tecturale. La définition des sous-composants dans les composants doit respecter desrègles de composition spécifiées par AADL qui ne doivent pas être violées :

– Les données peuvent avoir des sous-composants de type données.– Les threads peuvent avoir des sous-composants de type données.– Les groupes de threads peuvent avoir les threads, les groupes de threads et les

données comme sous-composants.– Les processus ont les threads, les groupes de threads et les données comme

sous-composants.– Les systèmes peuvent avoir les données, les processus et les systèmes comme

sous-composants.

2.5.6 Interactions entre les composants

Les interactions entre les composants sont définies à travers les connexions entreles éléments de l’interface. Ces connexions établissent l’une des interactions sui-vantes :


1. Les connexions de ports correspondent à la manière principale de décrire lestransmissions d’informations entre les composants. Un port représente une in-terface de communication pour l’échange directionnel, de données, d’événe-ments ou bien des deux, entre les composants. Dans AADL, les ports sontdéclarés comme étant des “features” dans la déclaration de type de composant.Ils sont directionnels et déclarés en entrée, en sortie ou en entrée/sortie :– les ports d’événements (event port) représentent l’interface de communication

des événements évoqués par les sous-programmes et les threads. Ils sontsemblables aux signaux des systèmes d’exploitation et peuvent déclencherl’exécution de threads ;

– les ports de données (data port) représentent les interfaces de transmissionde données entre les composants. La connexion entre les ports de donnéespeut être immédiate ou avec délai (delayed). Contrairement aux ports d’évé-nements, ils ne déclenchent aucune action à leur réception ;

– les ports d’événements et de données (event data port) représentent l’interfacepour la transmission de message (signaux transportant des données) : ilspermettent de transporter des données tout en générant un événement à laréception.

2. Les appels de sous-programmes sont déclarés dans la définition d’un threadou de l’implémentation d’un sous-programme. Ils peuvent être comparés auxappels de procédures dans les langages de programmation impératifs.

3. Les connexions de paramètres représentent les transmissions d’informationsentre les sous-programmes ou bien entre les threads et les sous-programmes.Un paramètre représente un argument d’un sous-programme.

Le Listing 2.1 montre une partie de la description de l’architecture du modèle Pro-ducteur/Consommateur dans le langage AADL. Elle décrit la production des don-nées par le producteur et la réception des données par le consommateur. Cet exempledéfinit un processus processusA.impl qui contient deux threads : Producer de typeProd.impl désignant le producteur, et Result_Consumer de type Cons.Impl qui re-présente le consommateur. Le paramètre en sortie Data_Source de l’instance de sous-programme P_Spg est connecté au port d’entrée Data_Source_out du thread Producerqui transmet le résultat au port en sortie AlphaA du processus ProcessusA.Impl.Ce dernier envoie les données moyennant son port d’entrée BetaA au port d’entréeData_Sink_in du thread Result_Consumer qui appelle l’instance de sous-programmeQ_Spg par le biais de son paramètre d’entrée Data_Sink. La figure 2.4 montre lareprésentation graphique associée à cet exemple.

Listing 2.1 – Connexion entre composants AADL� �subprogram Produce_Spgfeatures

Data_Source : out parameter Alpha_Type;end Produce_Spg;


thread Prodfeatures

Data_Source_out : out data port Alpha_Type;end Prod;thread implementation Prod.Implcalls {

P_Spg : subprogram Produce_Spg;};connections

C1 : parameter P_Spg.Data_Source −> Data_Source_out;end Prod.Impl;subprogram Consume_Spgfeatures

Data_Sink : in parameter Alpha_Type;end Consume_Spg;thread Consfeatures

Data_Sink_in : in data port Alpha_Type;end Cons;thread implementation Cons.Implcalls {

Q_Spg : subprogram Consume_Spg;};connections

C2 : parameter Data_Sink_in −> Q_Spg.Data_Sink;end Cons.Impl;process processusAfeatures

AlphaA : out data port Alpha_Type;;BetaA : in data port Alpha_Type;;

end processusA;process implementation processusA.Implsubcomponents

Producer : thread Prod.Impl;Result_Consumer : thread Cons.Impl;

connectionsC3 : data port Producer.Data_Source_out −> AlphaA;C4 : data port BetaA −> Result_Consumer.Data_Sink_in;

end processusA.Impl;� �2.5.7 Les flux

Les flux AADL correspondent à un moyen de représenter le cheminement descommunications à travers l’architecture afin de faciliter les analyses sur le système.En effet, ceci permet de vérifier la cohérence de la topologie de l’application. Les fluxsont décrits dans la partie FLOWS d’un type ou d’une implémentation de composant.

Fig. 2.4 – Représentation graphique du listing 2.1


2.5.8 Les modes

Ils représentent les états des composants AADL. Ils sont définis dans l’implé-mentation des composants et correspondent à des configurations de fonctionnement.AADL permet de décrire la transition d’un mode à un autre. Cette transition se faitdynamiquement au cours de l’exécution de l’application répartie et est déclenchéepar la réception d’un événement (transmis par un port d’événement).

2.5.9 Les propriétés

AADL introduit la notion de propriété qui constitue un de ses aspects fon-damentaux. Les propriétés sont des caractéristiques associées à différentes entités(composants, connecteurs ou éléments d’interface). Elles permettent de décrire descontraintes s’appliquant à l’architecture telles que la période d’une tâche (thread) oule temps d’exécution d’un sous-programme. Un ensemble de propriétés standards estdéfini dans le langage AADL. Cependant, de nouvelles propriétés peuvent égalementêtre définies par l’architecte et être associées à des catégories de composants.

Listing 2.2 – Un modèle AADL enrichi par les propriétés� �subprogram Produce_Spgfeatures

Data_Source : out parameter Alpha_Type;properties

Source_Language => Ada95;Source_Name => "Repository.Send_Message";

end Produce_Spg;thread Prodfeatures

Data_Source_out : out data port Alpha_Type;end Prod;thread implementation Prod.Implcalls {


C1 : parameter P_Spg.Data_Source −> Data_Source_out;properties

Dispatch_Protocol => Periodic;Period => 200 Ms;

end Prod.Impl;� �Le Listing 2.2 montre quelques composants du modèle Producteur/Consommateurenrichis par des propriétés. Le thread P.impl est périodique et le temps minimal entredeux déclenchements successifs de ce composant est de 200 ms. Le sous-programmeProduce_Spg est implémenté en Ada. Le fichier contenant son code source est Reposi-tory dans lequel le nom de l’entité (par exemple, la procédure) contenant son implé-mentation est Send_Message.

2.5.10 Les annexes

Les annexes dans les modèles AADL permettent d’associer des informations auxéléments d’une description. Contrairement aux propriétés, elles ne peuvent être as-


sociées qu’aux déclarations de composants et permettent d’ajouter des informationssur un élément de l’architecture.L’utilisation des annexes permet donc d’étendre la syntaxe standard AADL afin despécifier le comportement des composants [SAE06b] ou introduire une spécificationde la gestion des erreurs [SAE06a, RKK06].

2.5.11 Paquetage (Espace de noms)

La notion de paquetage (package) a été introduite afin d’organiser efficacement lesdéclarations dans une description AADL en les regroupant par ensembles logiques.Ce concept est le même que celui des langages de programmation comme les paque-tages Java ou les espaces de noms C++.

2.5.12 Ensembles de propriétés

Le standard AADL définit deux ensembles de propriétés :– le premier, “AADL_Properties”, contient les déclarations des propriétés stan-

dard ; ces propriétés ne peuvent pas être modifiées. Dans cet ensemble, lespropriétés sont définies et associées à certaines catégories de composants. Parexemple, la définition “Period : inherit Time applies to (thread, thread group, process,system, device)” indique qu’il existe une propriété nommée “Period” qui est detype “time” pouvant être associée à l’un des composants mentionnés entre lesparenthèses. Cette propriété ne peut pas être changée.

– Le second, “AADL_Project”, contient les propriétés du projet. Ces dernièressont initialisées et peuvent être adaptées selon les besoins de l’architecte. Parexemple, nous pouvons modifier la propriété “Size_Units : type units (Bits, B =>Bits * 8, KB => B * 1000, MB => KB * 1000, GB => MB * 1000) ;” en lui ajoutant“TB => GB ∗ 1000”.

2.5.13 Exemple AADL

Afin d’illustrer les opérations de modifications présentées dans le chapitre 5 et devalider notre approche dans le chapitre 6, nous utilisons un exemple d’architecturedécrivant le modèle Producteur/Consommateur. Le listing 2.3 montre la descriptiontextuelle de l’architecture de ce modèle exprimée avec le langage AADL. Cette archi-tecture est composé d’un système “PC_Simple.Native” qui contient deux processus.Le premier processus “pr_A”, de type “processusA.Impl”, a été décrit dans la section2.5.6 et illustré dans la figure 2.4. Le deuxième processus “pr_B”, de type “pro-cessusB.Impl”, est équivalent au premier. Chacun de ces deux processus contientun thread périodique qui émet des données et un autre qui reçoit des données. Leproducteur de l’un est connecté au consommateur de l’autre. La figure 2.5 montre ladescription graphique de l’architecture de ce modèle.


Listing 2.3 – Description de l’architecture de Producteur/Consommateur avec AADL� �data Alpha_Typeend Alpha_Type;

subprogram Produce_Spgfeatures

Data_Source : out parameter Alpha_Type;properties

source_language => Ada95;source_name => "Producer_Consumer.Produce_Spg";

end Produce_Spg;

thread Prodfeatures

Data_Source_out : out data port Alpha_Type;end Prod;

thread implementation Prod.Implcalls {


PC1 : parameter P_Spg.Data_Source −> Data_Source_out;properties


end Prod.Impl;

subprogram Consume_Spgfeatures

Data_Sink : in parameter Alpha_Type;properties

source_language => Ada95;source_name => "Producer_Consumer.Consume_Spg";

end Consume_Spg;

thread Consfeatures

Data_Sink_in : in data port Alpha_Type;end Cons;

thread implementation Cons.Implcalls {

Q_Spg : subprogram Consume_Spg;};connections

PC2 : parameter Data_Sink_in −> Q_Spg.Data_Sink;properties


end Cons.Impl;

process processusAfeatures

AlphaA : out data port Alpha_Type;BetaA : in data port Alpha_Type;

end processusA;

process implementation processusA.Implsubcomponents

Producer : thread Prod.Impl;Result_Consumer : thread Cons.Impl;

connectionsPC3 : data port Producer.Data_Source_out −> AlphaA;PC4 : data port BetaA −> Result_Consumer.Data_Sink_in;

end processusA.Impl;


process processusBfeatures

AlphaB : out data port Alpha_Type;BetaB : in data port Alpha_Type;

end processusB;

process implementation processusB.Implsubcomponents

Consumer : thread Cons.Impl;Result_Producer : thread Prod.Impl;

connectionsPC5 : data port BetaB −> Consumer.Data_Sink_in;PC6 : data port Result_Producer.Data_Source_out −> AlphaB;

end processusB.Impl;

system PC_Simpleend PC_Simple;

system implementation PC_Simple.Nativesubcomponents

pr_A : process processusA.processusAImpl;pr_B : process processusB.processusBImpl;

connectionsPC7 : data port pr_A.AlphaA −> pr_B.BetaBPC8 : data port pr_B.AlphaB −> pr_A.BetaA

end PC_Simple.Native;� �

Fig. 2.5 – Représentation graphique du listing 2.3

2.6. Conclusion 31

2.6 Conclusion

Nous avons présenté, dans ce chapitre, un état de l’art sur les architectureslogicielles. Ces dernières jouent un rôle fondamental dans de nombreux aspectsdu développement logiciel. Notamment, en matière de spécification abstraite dusystème à concevoir indépendamment des détails d’implémentation du code source.Les langages de description d’architecture (ADLs) permettent de spécifier et destructurer une architecture logicielle. Ces langages possèdent des caractéristiquescommunes telles que le composant, le connecteur, l’interface et les contraintes, quiforment les concepts de base de notre modélisation des architectures logicielles.Nous avons présenté quelques uns des principaux ADLs et nous avons constaté queces langages ne permettent pas, ou partiellement, la prise en compte de l’aspectévolutif des architectures. À ce titre, des travaux sont menés afin d’élaborer deslangages pour décrire des architectures logicielles pouvant évoluer.Nous avons donné un descriptif détaillé du langage de description d’architectureAADL. Ce dernier est l’ADL que nous utiliserons tout au long de cette thèse pourillustrer notre approche.

Le chapitre suivant sera consacré à l’étude des approches pour l’évolution desarchitectures logicielles et l’analyse d’impact de modifications. Nous présenterons unbilan sur les travaux effectués dans ce cadre afin de situer nos travaux et de montrerleur apports.

3Problématique de l’évolution du

logiciel

Sommaire

3.1 Maintenance du logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

3.1.1 Approches pour l’évolution du logiciel . . . . . . . . . . . . . . . . . . 36

3.1.2 Synthèse sur les approches pour l’évolution . . . . . . . . . . . . . . . 40

3.2 Evolution logicielle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

3.3 Dimensions de l’évolution logicielle . . . . . . . . . . . . . . . . . . . . 41

3.3.1 Portée de l’évolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

3.3.2 Jalons de l’évolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

3.3.3 Initiateur de l’évolution . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

3.4 Evolution des architectures logicielles . . . . . . . . . . . . . . . . . 43

3.5 Analyse d’impact de changements . . . . . . . . . . . . . . . . . . . . . . 44

3.5.1 Processus de conduite du changement . . . . . . . . . . . . . . . . . . . 45

3.5.2 Travaux sur l’analyse d’impact . . . . . . . . . . . . . . . . . . . . . . . 46

3.5.3 Bénéfices de l’analyse d’impact . . . . . . . . . . . . . . . . . . . . . . . 49

3.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

3.1. Maintenance du logiciel 35

Selon Lehman, un logiciel subit des évolutions tout au long de sa vie, faute de quoiil devient progressivement inutile [LB85]. La maintenance est reconnue comme

la phase la plus difficile et la plus coûteuse dans le cycle de vie d’un logiciel [LH95].Les coûts alloués à la maintenance augmentent de plus en plus malgré les effortsréalisés dans le domaine du génie logiciel. Estimée dans les années 80 à 90 à environ60 % [LS81, McK84] des coûts associés aux logiciels, des études récentes évaluentles coûts de maintenance désormais entre 80 et 90 % [Erl00, SPL03]. La plupart deces coûts peuvent être attribués au processus de l’évolution du logiciel [LS81], enparticulier, à l’ajout de nouveaux besoins fonctionnels, à la modification des besoinsinitiaux ou à leur suppression. Ces évolutions sont généralement nécessaires en vuede corriger des erreurs, de s’adapter à des changements liés au métier ou à l’orga-nisation d’une entreprise ou visant à améliorer les fonctionnalités ou le niveau dequalité du logiciel.

Actuellement, des importantes différences existent entre ce qui est mis en œuvreau niveau de l’implémentation des logiciels par rapport à ce qui est exprimé dansles modèles de conception. Combler cet écart est un des nouveaux défis de la com-munauté du génie logiciel. Notamment l’architecture d’un logiciel comprenant sastructure, son organisation, sa technicité et son déploiement est au cœur de ces défis.Les architectures logicielles dynamiques et adaptatives doivent prendre en comptedes capacités d’abstraction et d’analyse des modèles de conception [AF03]. Cetteprise en charge doit permettre d’intégrer l’évolution des besoins, de modéliser leurévolution, de maîtriser et d’analyser celle-ci au niveau conceptuel, c’est-à-dire lorsde la spécification de l’architecture du logiciel.

Ce chapitre décrit les concepts de base de l’évolution du logiciel et introduit ceuxde l’analyse d’impact d’une modification. Nous nous focaliserons sur le processusd’évolution au niveau de l’architecture logicielle en décrivant les travaux et les ap-proches effectués dans ce domaine.

3.1 Maintenance du logiciel

La maintenance du logiciel est définie comme un ensemble d’activités consistant àgérer les modifications apportées à un système logiciel après sa mise en exploitation.Swanson [Swa76] a proposé une taxonomie introduisant les termes “Maintenancecorrective”, “Maintenance adaptative” et “Maintenance perfective”. D’autres termesont été introduits par la suite comme “Maintenance évolutive” et “Maintenance pré-ventive”. Nous définissons ci-dessous ces termes :

1. la maintenance corrective est l’ensemble des activités déclenchées par la détectiond’une erreur.

2. la maintenance adaptative représente les opérations effectuées dans le but d’adap-ter le logiciel à de nouveaux environnements.

36 3.1. Maintenance du logiciel

3. la maintenance perfective représente la maintenance visant à améliorer un ouplusieurs indicateurs de la qualité du logiciel.

4. la maintenance évolutive est l’ensemble des activités de maintenance déclenchéespar la modification des besoins des utilisateurs.

5. la maintenance préventive est l’ensemble des activités de maintenance permettantde faciliter la maintenance des logiciels. Cette définition précise que les activitésde maintenance préventive se déroulent durant la phase de maintenance. Or,la définition proposée par [RPTU84] désigne l’ensemble de toutes les activitésmenées tout au long du cycle de vie pour faciliter la maintenance.

Des définitions contradictoires sont utilisées concernant ces termes de mainte-nance. Par exemple, dans [Dar92], la maintenance préventive correspond à la main-tenance perfective, la maintenance adaptative regroupe la maintenance évolutive etla maintenance adaptative. Dans [RPTU84], la maintenance préventive n’est pas unsous-ensemble de la phase de maintenance.

Dans les systèmes, ayant un nombre important de modules ou composantsen interaction, la modification et ensuite la validation d’un logiciel peut s’avérercomplexe : l’analyse, le test et le débogage peuvent être nécessaires pour chaquemodule individuel, puis globalement pour les interactions entre ces modules. Cettecomplexité s’accroît du moment où les chargés de la maintenance n’ont pas accèsaux spécifications de la conception du système mais uniquement au code source. Latâche de maintenir un logiciel devient ainsi plus complexe et plus coûteuse. À cettecomplexité s’ajoute le fait que la maintenance des logiciels n’est souvent pas prise encompte dans les phases antérieures à leur mise en exploitation.

Les recherches sur les activités de maintenance logicielle ont abouti à de nom-breux résultats. Ces résultats s’accordent et indiquent clairement que la réductiondes coûts de la maintenance peut être atteinte plus efficacement en contrôlant le pro-cessus de conception ainsi qu’en effectuant davantage de tests plus tôt dans le cyclede vie du logiciel.

3.1.1 Approches pour l’évolution du logiciel

Les activités de maintenance et en particulier celles liées à l’évolution du logi-ciel ont donné lieu à plusieurs approches. Nous décrivons les principales approchesvisant à réutiliser des parties du logiciel, à anticiper l’évolution et à améliorer unlogiciel existant.

3.1.1.1 La réutilisation

La réutilisation peut être définie comme étant l’utilisation à nouveau de compo-sants logiciels déjà produits lors de projets antérieurs ou concurrents [DPR91]. Ceconcept de la réutilisation a été introduit dans le domaine du génie logiciel pour la


première fois par McIlroy en 1967 [McI68] lors de la conférence devant le NATO surle genie logiciel. Dès cette époque, il proposait l’idée d’un catalogue contenant descomposants logiciels modulaires. Ces composants peuvent être assemblés commedes composants matériels et peuvent être utilisés et réutilisés dans de nouveauxlogiciels.Selon plusieurs travaux, la réutilisation est un moyen pour améliorer la qualité et laproductivité relatives au développement et à la maintenance des systèmes d’infor-mations [BS83, BP89, CB91].

Beaucoup d’études ont souligné le potentiel de la réutilisation. Une étude, réa-lisée par Kapur [Jon84] dans le domaine des applications bancaires et d’assurances,montre que plus de 75% des fonctions sont communes et répétées à l’intérieur desprogrammes d’applications. Une autre étude montrait que 85% des composantslogiciels d’une application sont communs et potentiellement réutilisables, tandis que15% sont nouveaux et concernent des applications particulières [Jon84].

En résumé, pour obtenir des composants réutilisables, il est primordial de pou-voir décrire, stocker et indexer les composants au sein d’un référentiel. Un aspectremarquable de la réutilisation consiste à pouvoir mutualiser l’évolution d’un com-posant. À ce titre, un composant modifié qui est réutilisé au sein de plusieurs projetspermettra de diminuer les coûts de maintenance et de réduire le facteur de risque liéà la réalisation de son évolution. Il est aussi indispensable de maîtriser la gestion desmodifications. Ces aspects font parties de nos travaux et nous montrerons la manièredont nous parvenons à les satisfaire.

3.1.1.2 La ré-ingénierie du logiciel

La ré-ingénierie est l’une des activités principales pour aider à résoudre les pro-blèmes de maintenance de logiciels.Tandis que l’ingénierie consiste à trouver une solution à un problème existant, la ré-ingénierie cherche à améliorer une certaine solution existante.Nous adoptons la définition proposée par Arnold [Arn93] pour la ré-ingénierie :La ré-ingénierie est l’ensemble des activités permettant (1) l’amélioration de la compréhensionque l’on a d’un logiciel, ou (2) l’amélioration du logiciel lui-même en ajoutant de nouvellesfonctionnalités afin de développer complètement un nouveau système sur la base de l’original.D’après cette définition, la ré-ingénierie est présentée comme étant un but et non pasun procédé ou une technique.Comme le montre la figure 3.1, la ré-ingénierie englobe plusieurs points de vues :

– La rétro-ingénierie (reverse engineering), dont l’origine provient des technolo-gies matérielles [Rek85] et consiste à développer les spécifications de systèmesmatériels complexes. Désormais, nous trouvons cette approche dans le génielogiciel, mais dans le but de retrouver les spécifications du logiciel.

38 3.1. Maintenance du logiciel

Fig. 3.1 – Processus de base de la ré-ingénierie

La définition proposée par Chikofsky et Cross [CI90] est la plus communémentadmise :“La rétro-ingénierie est le processus d’analyse d’un système pour identifier ses com-posants et leurs relations afin de créer des représentations du système dans une autreforme à un plus haut niveau d’abstraction.”

– La restructuration (refactoring) consiste à transformer une représentation en uneautre sémantiquement équivalente et au même niveau d’abstraction. Elle estgénéralement utilisée pour améliorer la structure d’un système. En fait, la re-structuration de logiciels permet d’ajouter de nouvelles propriétés à un systèmeexistant ou d’améliorer sa réutilisabilité.

– L’ingénierie “directe” permet, à partir d’une conception d’un haut niveaud’abstraction, de générer de squelettes de programmes d’implémentation. Unexemple utilisant cette technique est le développement rapide des applicationsRAD (Rapid Application Development) [Mar91] qui est une méthode de conduitede projet permettant de développer rapidement des applications de qualité.

3.1.1.3 La gestion des versions et des configurations du logiciel

La mise en œuvre de l’évolution se réfère à la notion de version. Il s’agit de main-tenir des relations entre les différentes versions d’un même composant. La construc-tion du logiciel consiste en une combinaison cohérente de différentes versions dechacun de ses composants.La gestion des versions assure le stockage et l’identification de plusieurs versionsd’un même élément logiciel.La gestion des configurations permet de définir, d’identifier et de contrôler les chan-


gements dans des systèmes complexes et de grandes tailles. Elle doit assurer unprocessus de modification systématique dont on peut garder des traces. Il est impor-tant de pouvoir connaître à chaque instant, l’état du système afin de le comparer àses spécifications.La gestion des versions et des configurations concerne l’ensemble des composantsdéveloppés durant le cycle de vie du logiciel [WC01]. Elle permet de contrôler lesévolutions de versions des applications et de manière plus globale du système d’in-formations. De plus, elle permet d’assurer que les corrections ou améliorations fonc-tionnelles attendues par les utilisateurs sont intégrées et validées dans une versiondu logiciel.Comme la plupart des approches dédiées à l’assistance de l’évolution du logiciel,les travaux sur la gestion des versions et des configurations soulignent l’importancede disposer d’un référentiel permettant de décrire l’organisation des composantsd’applications et du système d’informations. Ce référentiel décrit à l’aide de "méta-données" les objets gérés et les processus. Il stocke les versions successives des objets,les modifications entre deux versions successives, l’auteur ainsi que la date de cesmodifications.

3.1.1.4 L’anticipation du changement

Un logiciel est soumis continuellement à des changements. L’anticipation duchangement a pour but l’utilisation de paradigmes de développement et des mo-dèles de composants qui assument la réutilisation de l’existant pour mieux répondreà des évolutions des besoins des utilisateurs ou à de nouvelles configurations logi-cielles ou matérielles.La prise en compte de l’aspect évolutif d’une application et la maîtrise de l’impactde changement sont des propriétés requises pour anticiper l’évolution.Plusieurs types de changements peuvent avoir lieu : les évolutions internes de la struc-ture de l’application et les évolutions externes qui peuvent être liées à des correctionsdes anomalies. Ce dernier type d’évolution est, d’une manière plus générale, lié àl’évolution des besoins des utilisateurs.La mise en œuvre de l’anticipation du changement est basée sur une conception mo-dulaire d’un logiciel, en appliquant les principes d’extension et de polymorphismedans les langages orientés objets. Ceci implique une forte cohésion interne descomposants et un faible couplage entre eux. L’utilisation des patrons de conception(design patterns) est un moyen de concevoir un logiciel en considérant sa future ex-tension afin d’anticiper son évolution. Ils sont largement utilisés dans la conceptionpar objets et permettent de résoudre les problèmes récurrents dans la conceptionde systèmes [GHJV95]. Certains patrons de conception permettent de limiter lecouplage entre les éléments constitutifs d’une application afin de limiter l’impactd’un changement.

40 3.2. Evolution logicielle

L’anticipation du changement est l’un des principes de conception le moins prisen compte lors de la construction d’applications. La prise en compte, dès les pre-mières phases de conception du caractère évolutif d’une application, est un critèreessentiel et permet d’assurer une meilleure pérennité de celle-ci. Ceci nous mène àprendre en considération ce mécanisme dès la phase de conception architecturalede l’application en donnant à l’utilisateur la possibilité de spécifier et de cadrer leschangements possibles.

3.1.2 Synthèse sur les approches pour l’évolution

Comme nous l’avons souligné au début de ce chapitre, la majeure partie dubudget d’un logiciel est dédiée à la maintenance. Il est ainsi primordial de pouvoirmieux contrôler ce processus. La non satisfaction des besoins et les changementsdans les besoins des utilisateurs constituent un autre coût indirect de ce processus.Souvent, les utilisateurs éprouvent des difficultés pour comprendre la raison de ladurée, souvent longue, pour réaliser une évolution.

Pour permettre une maintenance efficace, il est vital de contrôler les effets del’évolution. La gestion des changements et l’analyse d’impact constituent les deuxpremières étapes du processus de maintenance logiciel. Ce processus peut être op-timisé si nous disposons des informations précises et non ambiguës sur le potentield’effets d’ondes (ripple effects) d’un changement sur le système. Les effets d’ondessont définis comme étant le phénomène par lequel des changements apportés à unepartie d’un programme ont des effets sur d’autres parties de ce programme [YCM78].Ces effets peuvent être classés en plusieurs catégories :

– les effets logiciels : les fonctionnalités d’un logiciel peuvent changer suite à unemodification,

– les effets de performance : une modification effectuée dans un logiciel peutdégrader sa qualité de service rendu,

– les effets de compréhension : la modification du logiciel peut mettre les déve-loppeurs chargés de la maintenance dans une situation confuse ; ils peuventtrouver des difficultés à tracer les effets d’une modification.

Dans les sections suivantes, nous allons décrire l’évolution logicielle et ses di-mensions. Nous décrivons également les approches liées à l’analyse d’impact duchangement.

3.2 Evolution logicielle

L’évolution logicielle est l’ensemble des activités ayant pour but de permettreau logiciel de continuer à répondre à ses objectifs, d’une manière efficace, suite àune modification. L’évolution est un processus complexe et critique, qui nécessite

3.3. Dimensions de l’évolution logicielle 41

l’utilisation de divers outils d’assistance au service des chargés de l’évolution. Gé-néralement, ceux-ci réalisent “une cartographie complète des applications devantévoluer, en précisant les liens précis entre ses composants”. Cette cartographie doitêtre présentée par un modèle standard qui assure l’interopérabilité pour la mo-délisation et l’échange des différents artefacts utilisés par les outils de gestion del’évolution [Sac09].

La mise en œuvre effective de l’évolution se manifeste par diverses modificationsou améliorations appliquées au système. De nombreuses raisons peuvent favoriserle processus d’évolution : la correction des erreurs, l’adaptation à un nouvel environ-nement, l’ajout de nouvelles fonctionnalités ou l’amélioration de l’efficacité [HM93].Ces modifications peuvent être petites comme la suppression d’une variable, ou plusimportantes comme la suppression d’une fonction, et allant jusqu’à la restructurationtotale du logiciel.

Andrade et Fiadeiro [AF03] expliquent que les changements les plus fréquentsdans un système ne concernent pas les opérations basiques de calcul effectuées parses composants, mais plutôt la façon dont ses composants communiquent. En effet, lefonctionnement global d’un système émerge des opérations effectuées par ses compo-sants ainsi que de la topologie de leurs connexions. Le système ne peut pas être utilesans la collaboration établie entre ses composants. C’est pourquoi, les changementsles plus fréquents sont souvent réalisés au niveau de la structure et de l’organisationdes composants, c’est-à-dire son architecture.

3.3 Dimensions de l’évolution logicielle

Une évolution peut être initiée de différentes façons et peut porter sur des élé-ments variés d’une application. Nous appelons “dimensions”, les critères permettantde caractériser une évolution logicielle. Ces dimensions permettent de décrire la na-ture et la fonction d’une évolution logicielle. Plusieurs dimensions se dégagent, parmilesquelles nous allons répondre dans cette section à certaines questions :

– Quelle est la portée de l’évolution, c’est-à-dire sur quels éléments de l’applica-tion peut porter une évolution ?

– Quels sont les jalons de l’évolution, c’est-à-dire quand une application peut-elleévoluer ?

– Qui est l’initiateur de l’évolution, autrement dit qui décide de faire évoluer uneapplication ?

3.3.1 Portée de l’évolution

Partant du principe que “un système logiciel est une architecture composée d’unensemble de composants reliés entre eux”, une évolution peut porter sur un compo-

42 3.3. Dimensions de l’évolution logicielle

sant, sur une liaison entre deux composants ou bien sur l’architecture entière.L’évolution d’un composant peut aller d’un simple changement de paramètres à unetransformation complète. La modification d’une liaison peut être la modification desa nature (par exemple, un lien de délégation à la place d’un lien d’héritage), oude l’appliquer sur un autre couple de composants. L’évolution d’une architecture lo-gique d’un système consiste à ajouter, supprimer ou remplacer un composant ou uneliaison. L’évolution de l’architecture physique consiste, en général, à faire migrer lescomposants d’un système vers un site différent.

3.3.2 Jalons de l’évolution

Les systèmes peuvent changer à plusieurs périodes de leur cycle de vie. La modi-fication peut, tout d’abord, surgir avant le démarrage du système (évolution statique),c’est-à-dire pendant les phases d’analyse, de conception et de développement. Ellepeut également survenir pendant la phase de déploiement de l’application (évolutionsemi-dynamique). Dans ce cas, nous nous intéressons à la dynamicité du processusde déploiement de l’application. Les systèmes peuvent évoluer après la phase de dé-ploiement de l’application, c’est-à-dire pendant la production de celle-ci (évolutiondynamique).

3.3.3 Initiateur de l’évolution

Les étapes d’une évolution nécessitent l’intervention de plusieurs acteurs, qu’ilssoient humains ou logiciels. En effet, l’évolution d’une application n’est pas forcé-ment la responsabilité de l’administrateur de cette application. En particulier, si unconcepteur l’a anticipé, l’application peut initier son changement automatiquementsans intervention humaine.

Les principaux acteurs du cycle de vie d’un logiciel sont le concepteur, le dé-veloppeur et l’administrateur (hormis l’utilisateur du logiciel). Comme le besoind’évolution peut émerger à tout moment, chaque acteur du génie logiciel peut êtrepotentiellement l’initiateur d’une opération d’évolution.

Nous distinguons aussi des systèmes qui peuvent évoluer automatiquement,appelés également systèmes auto-adaptatifs. En effet, des entités logicielles (parexemple, des composants) peuvent également jouer le rôle d’initiateur. Par exemple,dans certains types d’applications dites sensibles, des adaptations peuvent êtredéclenchées par des capteurs physiques ou logiciels mesurant, par exemple, latempérature ambiante ou la position géographique [DAS01b]. L’adaptation joueun rôle également prépondérant dans les systèmes autonomes ou auto-adaptatifs[KC03, NCCR05]. Bien souvent ces systèmes sont directement inspirés des SystèmesMulti-Agents (SMAs), ils se composent de différentes entités logicielles dont le fonc-

3.4. Evolution des architectures logicielles 43

tionnement dépend presque exclusivement des autres entités afin de minimiser lesinterventions humaines.

3.4 Evolution des architectures logicielles

L’arrivée du paradigme de composant (Component Based Software Engineering)[Szy98, HC01] et sa prise en compte à tous les niveaux du cycle de développementpermettent une meilleure réutilisation et une expression simple des dépendancesentre modules logiciels.

La création d’une architecture durable nécessite une grande capacité d’anticipa-tion de certains types de changement qui vont probablement se produire. En s’as-surant que l’architecture est capable de faire face à ces types de changements, ellerestera assez solide face aux évolutions futures.

L’évolution des architectures logicielles peut se diviser en deux aspects princi-paux : permettre aux architectures d’évoluer, et superviser et mesurer leur évolution.

Concernant l’aspect évolutif des architectures, Zenger [Zen02] montre que l’ex-tensibilité est un besoin à respecter pour permettre l’évolution des architectures. Ilfournit une liste de conseils à suivre dans le développement des composants d’unearchitecture pour s’assurer que celle-ci sera extensible et évolutive. Cette approches’inscrit dans le cadre de l’anticipation à l’évolution.

La supervision de l’évolution consiste à garantir la cohérence de l’architectureaprès son évolution. La plupart des travaux concernent la supervision des architec-tures et non celle de leurs évolutions. Ainsi, Balzer [Bal97] présente une méthodepour superviser les architectures par le moyen de l’animation. Cette technique per-met la supervision du comportement des architectures par l’instrumentation de leursconnecteurs.

Même si la supervision de l’évolution n’est pas assez traitée, des travauxont abouti au développement d’outils dédiés à l’analyse d’architectures [LKA+

95,SDK+

95, NACO97]. Ces outils constituent une base pour superviser les architecturesen fournissant des informations sur leur structure et leurs propriétés. Par exemple,une technique semi-formelle a été développée pour comparer des descriptions ar-chitecturales dans le but de mettre en évidence leurs différences et leurs similarités[IW95]. Une telle technique peut être exploitée pour superviser l’évolution des archi-tectures par comparaison de leurs versions successives. Ainsi, Jazayeri [Jaz02] a utilisédes métriques et des outils pour analyser rétrospectivement les versions successivesd’architectures afin de déterminer la manière dont elles évoluent.

La supervision est souvent combinée au contrôle de l’évolution de l’architecturequi implique la possibilité de modifier, d’ajouter ou de supprimer des éléments quila composent. Pour contrôler efficacement les opérations de modification, l’analysed’impact peut s’avérer nécessaire. À titre d’exemple, Jass et al. [SRW93, SRW97] pro-

44 3.5. Analyse d’impact de changements

posent une technique de chaînage qui génère une matrice de dépendance permettantl’analyse de l’impact d’une modification architecturale.

D’autres approches consistent à étudier l’évolution dans les langages de des-cription d’architectures ADLs [Boh02]. La description de l’évolution est réalisée parl’ADL qui a servi à la spécification de l’architecture. Ainsi, la mise en œuvre del’évolution est incluse dans la spécification de l’architecture et par conséquent, ilapparaît plus difficile de distinguer la description de l’architecture de celle décrivantson évolution. Certains ADLs actuels tels que AADL et Rapide, permettent la descrip-tion d’architectures évoluant dynamiquement. AADL propose par l’intermédiaire desmodes de prévoir l’ensemble des configurations possibles pour le système. Ce méca-nisme peut se révéler rapidement inefficace si l’architecture du système peut évoluertrès fréquemment. Rapide utilise des règles de création qui définissent les momentsde création ou de destruction des composants pendant l’exécution. Ces changementsdoivent être connus a priori : cette tâche s’avère difficile avec les applications com-plexes. Notre étude sur les ADLs a mis en évidence les lacunes concernant la gestionde l’évolution des architectures.

3.5 Analyse d’impact de changements

Un impact est l’effet que peut avoir une opération d’évolution sur une entité telleque, le composant ou le connecteur. L’analyse d’impact est utilisée pour déterminerl’étendue des effets de changements. Ceci offre une vision précise sur les efforts hu-mains et matériels à employer et sur la gestion du plan de travail pour mettre enœuvre l’opération de modification ainsi que la confirmation du rapport coûts/béné-fices.

L’analyse d’impact est une activité nécessaire et efficace pour la maintenance etl’évolution d’un système logiciel. Toutefois, lorsqu’elle est réalisée de manière ex-haustive et précise, cette approche peut s’avérer complexe et très coûteuse en temps.

Dans la littérature du domaine, il n’existe pas un consensus universel sur la défi-nition de l’analyse d’impact [AB93]. Pfleeger et Bohner [PB90] la définissent commeétant “l’évaluation des divers risques associés au changement, incluant les estima-tions des effets sur les ressources, sur les efforts et sur la planification”. Turver etMurno [TM94] la définit comme étant "l’évaluation d’un changement, effectué surle code source d’un module, sur les autres modules du système. Elle détermine laportée de ce changement et fournit des mesures sur sa complexité". Law [Law03]la définit comme étant une collection de techniques pour déterminer les effets de lamodification d’un code source.

Dans la plupart des systèmes complexes, l’analyse d’impact est un travail labo-rieux et souvent un processus manuel. Ce processus est exécuté en dernier recoursquand il devient absolument nécessaire de le faire dans le but de réduire les coûts et

3.5. Analyse d’impact de changements 45

Fig. 3.2 – Processus de changement

de limiter la détérioration de la qualité et de la consistance du système logiciel [LS98].

Nous pouvons distinguer deux catégories d’analyse d’impact :– l’analyse d’impact a priori permettant de simuler des modifications sur un lo-

giciel (avant sa mise en œuvre) et d’étudier les éventuelles étendues de cesmodifications.

– L’analyse d’impact a posteriori permettant d’effectuer des opérations de modifi-cations et d’observer les impacts réels à l’issue de ces modifications.

Les travaux réalisés dans cette thèse traitent l’analyse d’impact a priori. En effet, nousallons proposer des opérations de modification à appliquer sur une architecturelogicielle et simuler leurs effets.

Lorsqu’une opération de maintenance logicielle est à déclencher, il est impor-tant de bien comprendre les besoins du changement et de maîtriser tous ses effets[BBE+

95] . Un changement minime peut avoir des impacts involontaires sur l’en-semble du système. En conséquence, les mécanismes permettant de comprendre lafaçon dont un changement va affecter le reste du système, font l’objet de nombreuxtravaux scientifiques.

3.5.1 Processus de conduite du changement

Pour mieux cerner le problème de l’analyse d’impact, nous devrons d’abord com-prendre le processus de changement. Il convient de noter que plusieurs acteurs etnormes ont proposés des classifications différentes pour ce processus. On trouveradans [CHK+

01] une discussion sur ces divergences. Le processus de changementreprésenté dans la figure 3.2 est le plus couramment admis. Dans ce processus, Laréception d’une demande de changement constitue le point de départ de toute actionde maintenance. Cette demande émane, soit d’un client, soit d’un acteur interne à


l’entreprise. Généralement, elle fait suite à la constatation d’une anomalie de fonc-tionnement (il s’agit alors d’une maintenance corrective), au souhait de faire migrerl’application vers un nouvel environnement matériel ou logiciel (maintenance adap-tative), au désir de modifier les caractéristiques fonctionnelles ou non fonctionnellesde l’application (maintenance perfective) ou d’améliorer à titre préventif sa mainte-nabilité et sa robustesse (maintenance préventive).Cette demande de changement est ensuite évaluée pour déterminer son niveau d’op-portunité. Plusieurs facteurs peuvent influencer la mise en œuvre ou non de ce chan-gement tels que des considérations stratégiques, d’impacts et de coûts. Si la demandeest acceptée, nous entamons alors une phase de compréhension de l’architecture del’application afin d’acquérir une connaissance suffisante de sa structure et de soncomportement. Plusieurs stratégies de modification peuvent être identifiées. À partirde ces dernières, une seule sera adoptée selon plusieurs critères tels que les coûts, lesdélais, le niveau de qualité garanti ou de compétence exigée. La stratégie retenue seraensuite mise en œuvre par une modification effective du code et des documentationsassociées. Une fois la modification est effectuée, il faut vérifier que celle-ci n’a pas,d’une part, altéré les besoins initiaux non sujets à l’évolution, et d’autre part, queles propriétés et fonctionnalités souhaitées sont correctement mises en œuvre et opé-rationnelles dans le logiciel. Une fois la vérification est réalisée, la nouvelle versionpeut être archivée, diffusée puis installée.

Les types de changement [AT02] définissent le contexte dans lequel les change-ments seront accomplis. Dans le processus de développement logiciel, un programmepeut être modifié hors ligne [CKR06], c’est-à-dire en dehors de son exploitation. Cetype de changement est considéré comme statique. Dans ce cas, les modificationssont apportées afin d’adapter un programme existant à des besoins spécifiques. Unprogramme peut aussi être changé pendant qu’il est en cours d’exécution [CJH01].Ce type de changement est nécessaire lorsque le logiciel est critique et qu’il ne peutêtre interrompu.

3.5.2 Travaux sur l’analyse d’impact

De nombreux modèles sont proposés dans la littérature pour analyser et repré-senter la propagation des modifications dans un logiciel. S. Ajila [Aji95] proposeune approche d’analyse d’impact d’un changement servant à mesurer l’impact desmodifications du code source Ada et de la conception associée exprimée avec laméthode HOOD [Age89]. Il se base pour cet objectif, sur l’identification de relationsinters-composants du code et de la conception et d’une correspondance entre les élé-ments de la conception et ceux du codage. Ce modèle a été validé avec un prototypelimité à deux étapes de cycle de vie, la conception et le code. Ce travail met l’accentsur la gestion de l’impact en spécifiant tous les composants de la conception ou ducodage concernés par toute modification du code source Ada ou de la conception

3.5. Analyse d’impact de changements 47

Fig. 3.3 – Processus d’évolution de Rajlich

HOOD correspondante.

S. Barros présente une approche générique de l’analyse d’impact a priori desmodifications réalisées sur un système logiciel [Bar97]. Cette approche est basée surune propagation automatique, contrôlée par des règles, d’événements sur un graphede dépendances modélisant le système. Cette analyse permet de prévoir ce qu’ilconvient de faire pour éviter l’introduction de nouvelles erreurs avant la mise enœuvre de toute modification. Ceci permet d’effectuer une évaluation qualitative etquantitative des interventions de maintenance et donc de les planifier et d’en estimerle coût financier et temporel. L’approche de S. Barros est semi-automatique, du faitd’une association des techniques automatiques d’analyse d’impact à la précision desrésultats des analyses d’impact manuelles. L’utilisation de ces techniques est articu-lée autour d’un graphe de dépendance modélisant les relations entre les artefacts dusystème logiciel et d’un modèle de propagation des impacts. Barros a implémentécette approche par un outil qui a été mis en œuvre sur plusieurs applications opéra-tionnelles (C et Hood) développées par la société Matra Marconi Space 1.

Dans ses travaux, V. Rajlich [Raj97a] définit un modèle formel pour la propaga-tion des modifications d’un logiciel. Il considère qu’un logiciel passe par cinq phasesdans sa vie (figure 3.3) : le développement initial, l’évolution, le service, la fin devie et l’arrêt de l’exploitation du logiciel. Ces phases révèlent que plus on avancedans la vie d’un logiciel, plus celui-ci devient difficile à maintenir du fait, d’une part,de la dégradation de son architecture, et d’autre part, d’une perte progressive del’expertise le concernant. Dans son modèle, un système est représenté par un graphede dépendances entre ses composants. Ces dépendances représentent la structuredu logiciel en terme de relations inter-composants (appel de fonctions, héritage,

1Société de construction de satellites et d’engins spatiaux, de terminaux laser inter satellites pourapplications multimédia, http ://www.matra-marconi-space.com/


etc.). Il utilise également la notion de “consistance” des dépendances. En effet, lamodification d’un nœud d’un graphe peut rendre inconsistants ses voisins. Rajlichimpose un algorithme, appelé change-and-fix, qui consiste à opérer le changement surun nœud ou un arc et ensuite à propager l’impact aux voisins immédiats. Les voisinsaffectés par la modification sont visités et corrigés par le chargé de l’évolution. Leprogramme retrouvera sa consistance quand le chargé de l’évolution aura visité tousles composants affectés par un changement. En effet, c’est le chargé de l’évolutionqui décidera, pour chaque voisin, de corriger les effets de l’impact et d’arrêter ou decontinuer à propager l’impact aux composants voisins et ainsi de suite. Dans le casd’applications de grandes tailles, ce procédé manuel est difficile à mettre en œuvre.

Dans [RRST05], les auteurs proposent une approche pour l’analyse d’impact desprogrammes Java, basée sur les graphes d’appel. Les auteurs présument qu’il existeune suite de tests T associée à un programme Java et appliquée à deux versions d’unmême programme, représentant celui-ci respectivement avant et après la modifica-tion. Cette approche consiste à :

1. analyser un changement dans un code source afin d’obtenir un ensemble Ade changements atomiques interdépendants au niveau de granularité moyenne(méthode).

2. Ensuite, construire un graphe d’appel pour chaque test T.

3. L’analyse déterminera un sous-ensemble T′

de T potentiellement affecté par leschangements. Ceci est obtenu en corrélant les changements dans T par rap-port aux différents graphes d’appel des tests dans T de la version originale duprogramme.

4. Enfin, pour chaque test ti ∈ T′, l’analyse déterminera un sous-ensemble A

′de

A qui contient tous les changements qui peuvent avoir affectés le comporte-ment de ti. Ceci est accompli en construisant un graphe d’appel pour ti dansla version modifiée du programme et en corrélant ce graphe d’appel avec leschangements dans A.

Les travaux concernant l’analyse d’impact sont pour la plupart mono-languageet se limitent principalement au code source. En effet, ces approches étudient lesimpacts d’un changement pour un langage particulier (Ada, C/C++ ou Java). Lesrelations considérées sont souvent limitées aux quelques relations de dépendance oula relation d’appel. Ceci ne permet pas d’affiner le raisonnement sur la conductivitéde l’impact pour les différents types de relations. La conductivité consiste à analyser,pour chaque type d’opération appliquée à un composant et pour chaque relationexistante avec ses voisins, la manière dont l’impact les a affecté [Bas].

Notre objectif est de traiter les évolutions au niveau architectural ainsi que d’étu-dier la propagations d’impacts entre le niveau architectural et celui du code source.

3.6. Conclusion 49

3.5.3 Bénéfices de l’analyse d’impact

L’identification des impacts potentiels, avant la réalisation effective d’un change-ment, permet de réduire considérablement les risques d’un changement coûteux touten conservant le niveau de qualité du logiciel. En effet, le coût des effets inattenduss’accroît généralement avec le temps requis pour les découvrir.

L’analyse d’impact rend visible les effets des changements avant que ces derniersne soient implémentés [LOA00]. Ceci permet d’effectuer les changements d’une ma-nière plus précise et d’identifier les conséquences ou les effets d’ondes des change-ments proposés durant les phases de développement et de maintenance.

Souvent, plusieurs changements peuvent résoudre un même problème ou satis-faire les mêmes besoins. L’estimation de l’impact complet de chaque changement estnécessaire afin de choisir celui qui sera appliqué [Lee98]. L’analyse d’impact permetaux chargés de l’évolution d’évaluer la pertinence des modifications proposées. Unchangement proposé peut nécessiter un examen plus détaillé si celui-ci a un impactlarge. Dans ce cas, le changement peut être soit remplacé par un autre soit abandonnécomplètement.

L’analyse d’impact peut être employée pour limiter la couverture de tests de ré-gression, c’est-à-dire la détermination des parties d’un programme qui doivent êtrere-testées après la mise en œuvre du changement. Le fait de cibler les tests sur unnombre restreint d’éléments minimisera les coûts ainsi que les délais.

3.6 Conclusion

Ce chapitre présente un état de l’art des travaux relatifs à la gestion de l’évolu-tion d’un logiciel, en particulier à l’étude de l’analyse d’impact d’une modification.Le bilan, loin d’être complet, focalise sur une partie des travaux du domaine et viseà éclaircir certaines lacunes relatives à l’évolution des architectures logicielles. Nouspensons que les grandes lignes de l’état de l’art ont été traversées afin de situer lesobjectifs de nos travaux et de montrer leur contribution.Les principaux travaux visant à améliorer la gestion de l’évolution de logiciel du-rant la phase de maintenance se divisent en quatre catégories : la réutilisation, laré-ingénierie, l’anticipation du changement et la gestion des versions et des configu-rations. Celles-ci visent principalement à réduire les coûts liés à la maintenance, enrendant le logiciel capable de s’adapter aux évolutions.Du point de vue architectural, la gestion de l’évolution consiste à fournir des méca-nismes permettant son extensibilité, mais également visant à superviser et à mesurerle résultat de l’évolution. Plusieurs approches proposent d’intégrer ces mécanismesdirectement dans les langages de description des architectures (ADLs). Toutefois,les ADLs ont de profondes lacunes quant à la mise en œuvre des mécanismes degestion de l’évolution. Notamment, l’étude de l’impact d’une modification opéréesur l’architecture n’est quasiment pas traitée dans les ADLs. Cet aspect crucial dans

50 3.6. Conclusion

l’évolution du logiciel, que nous avons tenté de mettre en exergue, s’appuie sur unprocessus de conductivité du changement et sur différentes techniques. Nous avonsconstaté que les travaux menés sur celles-ci sont principalement destinés à la gestionde l’évolution des codes sources et parfois des documents conceptuels d’un logiciel.Le caractère architectural d’une application est bien souvent absent des travaux surl’analyse de l’impact d’une modification.Nous définissons deux catégories d’analyse d’impact : l’analyse d’impact a poste-riori et l’analyse d’impact a priori. La première consiste à réaliser l’opération puis deconstater ses effets tandis que la seconde vise à simuler l’opération pour étudier seseffets sur l’architecture d’un logiciel.Dans la suite de ce mémoire, nous tentons d’apporter des éléments de réponses àces lacunes constatées à travers une modélisation des architectures logicielles et uneexhaustivité de l’analyse d’impact a priori des modifications.

4Modélisation pour l’évolution

des architectures logicielles

Sommaire

4.1 Critères d’évaluation des travaux existants . . . . . . . . . . . . . . . 53

4.1.1 ArchStudio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

4.1.2 Mae . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

4.1.3 Archware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

4.1.4 SAEV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

4.1.5 Bilan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

4.2 SCSM : Software Component Structural Model . . . . . . . . . . . . 58

4.3 Modélisation à base de graphes . . . . . . . . . . . . . . . . . . . . . . . . 62

4.3.1 Représentation basée sur les graphes . . . . . . . . . . . . . . . . . . . 62

4.3.2 Définitions formelles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

4.4 Description des architectures à l’aide de graphes . . . . . . . . . . . 63

4.5 Formalisation du modèle ASCM . . . . . . . . . . . . . . . . . . . . . . . 63

4.5.1 Description du graphe de l’architecture . . . . . . . . . . . . . . . . . . 65

4.5.2 Correspondances entre les éléments de ASCM et le graphe associé . . 67

4.5.3 Opérations pour la manipulation du graphe d’architecture . . . . . . . 69

4.6 Mapping entre ASCM et SCSM . . . . . . . . . . . . . . . . . . . . . . . . . 71

4.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

4.1. Critères d’évaluation des travaux existants 53

Ces dernières années, de nombreuses applications informatiques ont été conçuesautour d’une architecture logicielle. Celle-ci offre un haut niveau d’abstraction

nécessaire pour modéliser les systèmes complexes durant leur développement, leurdéploiement et leur évolution. L’architecture est souvent décrite selon un langagepermettant de spécifier les composants applicatifs et leurs interactions. Pour évaluerl’impact d’une modification réalisée au niveau d’un élément de l’architecture, il estnécessaire d’extraire une description des composants et de leurs interactions. Ceux-cisont souvent issus de descriptions architecturales pouvant être exprimées dans diffé-rents langages. Notre approche pour la modélisation des descriptions architecturalesse base sur l’établissement de plusieurs critères visant à évaluer les travaux et lesoutils dédiés à l’évolution des architectures logicielles.Dans ce chapitre, nous présentons le modèle ASCM (Architectural Software ComponentsModel) pour la représentation des langages de description architecturale (ADLs).ASCM est un modèle permettant, d’une part, la formalisation des informations is-sues de différents langages de description architecturale, et d’autre part, l’expressiondes contraintes d’évolution. Nous définissons un couplage entre ASCM et un modèlepour la représentation des codes sources logiciels, appelé SCSM. Nous montronsl’utilité de ce couplage pour l’analyse d’impact d’une modification de l’architecturevers le code source du logiciel.

4.1 Critères d’évaluation des travaux existants

La définition de notre modèle repose sur le résultat de l’étude de plusieurs mo-dèles existants. Notre état de l’art se focalise sur les travaux proposant des modèlespour l’évolution des architectures logicielles.Pour classer et comparer ces travaux, nous tentons de répondre à un ensemble dequestions que nous catégorisons sous forme de deux critères :

1. l’expressivité qui représente la richesse du modèle en considérant les caracté-ristiques suivantes :– Langage de configuration : Quel langage est utilisé pour la spécification des

architectures des systèmes ?– Éléments d’architecture du modèle : Quels sont les éléments d’architecture

logicielle manipulés par le modèle de composants ?– Hiérarchie du modèle : Le modèle supporte-il la composition des composants

pour la représentation d’architectures complexes ?– Extensibilité du modèle : Le modèle permet-il d’ajouter de nouveaux élé-

ments d’architecture ?

2. le support à l’évolution qui détermine les objectifs traités par un modèle concer-nant :– la spécification de l’évolution : Comment l’évolution de l’architecture est-elle

spécifiée ?

54 4.1. Critères d’évaluation des travaux existants

– La gestion des impacts de l’évolution : Les impacts des modifications affec-tant l’architecture et le code source correspondant sont-ils pris en comptedans le modèle ?

Nous proposons d’étudier ces critères sur les principaux modèles et outils afin dedresser un bilan.

4.1.1 ArchStudio

ArchStudio1 est un environnement de développement d’architectures logiciellespermettant de décrire et d’analyser une architecture logicielle et de la faire évo-luer pendant son exécution. ArchStudio est basé sur le modèle de composants C2

[TMA+95]. Les architectures C2 sont vues comme un réseau de composants indé-

pendants et concurrents reliés entre eux par des connecteurs. Dans ce modèle, unconnecteur peut être connecté à un nombre quelconque de composants, mais égale-ment à d’autres connecteurs.Les architectures sont décrites en xADL 2.0 [Das01a], un ADL extensible possédantune syntaxe basée sur XML. Un système est ainsi instancié à partir de la descriptionde son architecture grâce à un mapping existant entre le langage xADL 2.0 et, parexemple, des classes developpés dans le langage Java. Les changements d’architec-tures sont exprimés sous forme d’une différence architecturale (diff ) qui décrit les dif-férences entre deux spécifications d’architecture. Ces différences sont exprimées dansune extension du langage xADL 2.0 et permettent simplement de spécifier l’ajout oule retrait d’éléments de l’architecture tels que des composants, des connecteurs ou destypes. Un changement à l’intérieur d’un élément est donc traité comme un rempla-cement, en procédant à sa suppression puis à son ajout. L’outil ArchDiff prend ainsideux définitions d’architecture respectivement avant et après la modification, pouridentifier les différences correspondantes. Celles-ci sont principalement déterminéespar la présence de nouveaux éléments ou par l’absence d’éléments appartenant àl’ancienne version de la spécification.Un outil complémentaire, ArchMerge, permet d’appliquer un changement sur unearchitecture initiale afin de la transformer. Ainsi, il est possible d’appliquer un “patcharchitectural” à une architecture pour la faire évoluer. Un patch architectural repré-sente l’ensemble des reconfigurations à apporter aux systèmes. Cependant, l’appli-cation d’un patch ne conduit pas toujours à une architecture valide, des connecteurspeuvent, par exemple, à l’issue de la modification être déconnectés.

4.1.2 Mae

Mae [RHMRM04] est un environnement de gestion de l’évolution des architec-tures logicielles qui associe des techniques des domaines de l’architecture logicielle

1ArchStudio, An Architecture-based Development Environment,http ://www.isr.uci.edu/projects/archstudio


et de la gestion de configurations.Le modèle d’architecture dans Mae est un modèle théorique qui repose sur lesconcepts communs que l’on retrouve dans les ADLs existants [MT00] : composants,interfaces et connecteurs. Il permet la description des architectures hiérarchiques etpropose une séparation entre types et instances. Les types de composants sont com-posés de l’ensemble des types de ses interfaces et du contenu architectural des com-posants constitué d’une hiérarchie de composants et de connecteurs. La spécificationdes contraintes et du comportement des composants restreint l’accès à leur interface.Ce modèle est implémenté sous forme d’une extension du langage xADL 2.0Des notions concernant l’optionalité, la variabilité et l’évolution ont été introduitesdans le modèle d’architecture de Mae. L’optionalité permet de préciser si la présenced’un élément est obligatoire ou non dans une architecture. La variabilité désignel’existence de plusieurs versions d’un même élément architectural. L’évolution del’architecture est obtenue grâce à l’utilisation du versionnement et de sous-typage.Le versionnement est utilisé pour identifier des différences existantes entre un mêmeélément ; le sous-typage est utilisé pour annoter chaque changement afin d’indiquersa nature.L’environnement d’évolution des architectures définit la procédure de création etd’évolution des architectures. Il est composé de quatre parties. La partie centralede cet environnement est la bibliothèque pour la manipulation de documents XMLdécrivant des architectures dans le langage xADL 2.0. Les trois autres modules per-mettent la conception, la sélection et l’analyse des éléments d’architecture. Le modulede conception associe des fonctionnalités pour la représentation et la manipulationd’une architecture à celles du versionnement de ses éléments. Le module de sélec-tion permet de sélectionner une configuration spécifique. Cette sélection s’effectueen deux phases : (1) l’architecte sélectionne un point de départ en choisissant uneversion particulière d’une architecture, ensuite (2) il précise un ensemble de pro-priétés spécifiées sous forme de paires attribut-valeur. Le module d’analyse permetde détecter des incohérences dans les configurations architecturales en fonction descontraintes et des comportements spécifiés.

4.1.3 Archware

Le projet Archware [arc01] fournit un environnement de développement inté-gré centré architecture pour la construction de systèmes évolutifs. L’environnementArchware comprend :

– le noyau de l’environnement qui fournit un compilateur ainsi qu’un supportpour l’exécution de l’architecture à travers une machine virtuelle ;

– les modèles de méta-processus qui fournissent le support pour la constructionet l’évolution des applications logicielles ;

– les composants de l’environnement qui comportent les outils de support pourla description, l’analyse et le raffinement des architectures.

56 4.1. Critères d’évaluation des travaux existants

Archware fournit un mécanisme d’extension pour la construction de langages deplus en plus spécifique. Celui-ci est basé sur la notion de style architectural. Le lan-gage Archware ASL (Architecture Style Language) permet la définition de styles archi-tecturaux. La famille de langages Archware ADL propose un langage composant-connecteur Archware C&C-ADL [Ley04]. Le modèle de composant sous-jacent esthiérarchique. Les composants ainsi que les connecteurs peuvent être soit atomiquessoit composés d’autres composants et connecteurs.L’utilisation des capacités de ArchWare C&C-ADL permet la représentation des ar-chitectures dynamiques [MKB+

04]. L’évolution dans ArchWare est prise en comptepar un élément architectural dédié, appelé “chorégraphe”. Ce dernier est en chargede changer la topologie en cas de besoin, par exemple, pour changer les liaisonsentre des éléments architecturaux, créer dynamiquement de nouvelles instances, ex-clure des éléments de l’architecture ou en inclure d’autres. Archware permet aussi detraiter les évolutions non prévues dans une architecture en intégrant un composantparticulier, appelé “evolver”, dédié à l’évolution et s’appuyant sur une machine vir-tuelle. ArchWare inclut un langage ARL (Architectural Refinement Language) [Oqu03]dédié au raffinement d’architectures logicielles avec, d’une part, la prise en comptedu raffinement des données, des comportements, des connexions et des structures, etd’autre part, la préservation des propriétés architecturales à travers le processus deraffinement. ARL fournit un ensemble d’opérations appelées actions de raffinementpour la transformation d’architectures.

4.1.4 SAEV

SAEV (Software Architecture EVolution Model) [STO06] est un modèle d’évolutiondes architectures logicielles qui se veut générique et indépendant de tout ADL.Les opérations d’évolution représentent toutes opérations pouvant être exécutées surun élément de l’architecture afin de le faire évoluer ou de faire évoluer l’architec-ture qui le contient. L’exécution des opérations d’évolution est assurée à travers dela sélection et du déclenchement des règles d’évolution appropriées décrites selon leformalisme ECA (Évenement - Condition - Action). L’événement représente le mes-sage d’invocation reçu de l’environnement vers l’élément à faire évoluer. Afin quela règle soit déclenchée, une ou plusieurs conditions doivent être satisfaites toute enrespectant les invariants de l’élément à faire évoluer. Les invariants garantissent queles propriétés et les contraintes de l’architecture seront respectées. La partie actionpeut être soit une opération simple à exécuter telle que l’ajout, la modification ou lasuppression, soit la transmission d’un événement visant à déclencher d’autres règles.Une stratégie d’évolution est associée à chaque élément architectural regroupant l’en-semble des règles le concernant.Le processus d’évolution dans SAEV est déclenché automatiquement à la réceptiond’un événement. Le chargé d’évolution d’une architecture donnée exécute séquen-tiellement les étapes suivantes :


– il intercepte chaque événement émis vers l’élément architectural soit par leconcepteur, soit par une règle d’évolution ;

– il sélectionne la stratégie d’évolution associée à l’élément architectural sur le-quel l’événement est invoqué ;

– il sélectionne ensuite, dans cette stratégie, l’ensemble des règles d’évolutioncorrespondantes à l’événement et dont la partie “condition” est satisfaite ;

– il déclenche la partie action de la règle sélectionnée.Il est à noter qu’en plus du formalisme ECA, les auteurs du modèle ont proposéune notation graphique des règles dans l’environnement AGG [Tae00]. Dans celui-ci, les architectures sont représentées par des graphes et chaque règle est spécifiéeen définissant deux parties de graphes : une partie gauche (LHS - Left Hand Side)décrivant la situation avant l’évolution et une partie droite (RHS - Right Hand Side)la décrivant après l’évolution.

4.1.5 Bilan

Langage de configuration Éléments d’architecture Modèle hiérarchique Modèle ouvertArchStudio xADL 2.0 composants et connecteurs Non OuiMae xADL 2.0 composants et connecteurs Oui OuiArchWare Archware ADL composant et connecteur Oui NonSAEV Libre composant, connecteur et interface Oui Oui

Tab. 4.1 – Tableau comparatif des modèles de composants logiciels : Expressivité des modèles

Spécification de l’évolution Impacts architecturaux Impacts Architecture - code sourceArchStudio diff xADL 2.0 Non NonMae Versionnement et sous-typage Non NonArchWare Règle, ASL, ARL Non NonSAEV Règle ECA, règle LHS/RHS Oui Non

Tab. 4.2 – Tableau comparatif des modèles d’évolutions : support à l’évolution

Nous proposons, dans les tableaux 4.1 et 4.2, une synthèse concernant les critèresd’expressivité des modèles et de support à l’évolution. Cette synthèse s’appuie surune comparaison des différents concepts liés aux modèles et outils étudiés préalable-ment. Le résultat de celle-ci est de cerner les différences et les points communs entreles modèles d’évolution étudiés.

Parmi les modèles présentés, seul SAEV se veut indépendant d’un langage deconfiguration particulier. Les autres modèles reposent sur un ADL particulier.À l’exception de ArchStudio, les autres modèles permettent une hiérarchisationdans la composition de l’architecture. Un composant peut être de type atomique oucomposite.Mae, Archware et SAEV sont des modèles supportant l’extensibilité. Ils sont géné-riques et ouverts, permettant ainsi de décrire l’évolution à un niveau d’abstractionélevé et de faciliter leur réutilisation et leur extension.La formulation de l’évolution est proposée par tous les modèles. Cependant, seulSAEV propose des mécanismes pour la gestion des impacts de modifications en

58 4.2. SCSM : Software Component Structural Model

supportant l’enchaînement des règles d’évolution par l’intermédiaire d’émissions etde réceptions d’événements de même nature.Les modèles présentés ne supportent pas les évolutions du niveau architecturalsur le niveau code source (et vice versa). Or, notre objectif est la faculté à pouvoirexprimer les impacts de modifications du niveau architectural au niveau code sourceet inversement. Sur ce constat, notre objectif est de proposer un modèle extensible(1) pour la représentation des architectures logicielles indépendamment d’un ADLparticulier et (2) pour exprimer les évolutions architecturales et gérer leurs impactssur l’architecture et sur le code source correspondant.

L’équipe ModEL du LIL [Der01] a proposé le modèle SCSM (Software ComponentStructural Model) qui est utilisé pour représenter et manipuler différents types d’ar-tefacts logiciels issus du code source d’un logiciel. Ce modèle est une base pourle processus de propagation d’impact d’une modification. Il sera couplé avec notremodèle de représentation architecturale dans le but d’étudier l’impact entre une ar-chitecture et son code source correspondant. La section suivante sera consacrée à ladescription de ce modèle.

4.2 SCSM : Software Component Structural Model

Dans son mémoire d’habilitation à diriger des recherches, H. Basson [Bas] a pré-senté le Modèle Structurel Générique de Développement des Logiciels (MSGDL). Cemodèle offre une description couvrant l’ensemble des composants des différentesphases du développement d’applications. Il englobe, dans une même descriptionqualitative et structurelle, les constituants communs de différents modèles existantsutilisés dans le développement du logiciel. Les caractéristiques qualitatives des com-posants ainsi que leur description sont définies par l’intermédiaire de deux modèlesenglobés par le MSGDL : (1) le Modèle Structurel de Composants Logiciels (MSCL)permettant la représentation structurelle des composants, et (2) le Modèle Qualita-tif de Composants Logiciels (MQCL) pour spécifier les caractéristiques qualitativesassociées à ces composants.

Le modèle MSCL est d’un niveau très abstrait pour la représentation du codesource. Celui-ci a été raffiné par le modèle SCSM pour représenter de façon exhaus-tive la structure des composants et leurs relations extraites à partir des codes sourcesdu logiciel. Par rapport à d’autres modèles existants [CNR90, Raj97a], ce derniera l’avantage d’être multi-langages (par exemple Ada, C, C++, perl, python, php etJava). Il représente, de manière uniforme, les composants logiciels et leurs interac-tions indépendamment des langages de programmation utilisés.

SCSM inclut deux types d’éléments : les composants logiciels et leurs relations.Les composants logiciels sont catégorisés selon trois niveaux de granularité. Le

premier est celui des composants logiciels appartenant au niveau de grosse granu-

4.2. SCSM : Software Component Structural Model 59

Fig. 4.1 – Représentation des composants logiciels de grosse granularité

Fig. 4.2 – Représentation des composants logiciels de granularité moyenne

larité (figure 4.1). Les composants de ce niveau peuvent être des applications, desfichiers, des bibliothèques, des paquetages, des modules ou des processus. Entre lescomposants de ce type, des relations d’importation ou bien des relations de compo-sition peuvent être définies entre une application et les fichiers qui la constituent.

La deuxième catégorie de composants est celle de granularité moyenne présentéedans la figure 4.2. Les composants de cette catégorie sont, par exemple, les attributs

60 4.2. SCSM : Software Component Structural Model

Fig. 4.3 – Représentation des composants logiciels de granularité fine

et les méthodes d’une classe. Nous pouvons trouver deux types de composants à ceniveau :

1. les composants de type déclaration, qui représentent les déclarations des struc-tures, de classes ou type de variables.

2. les composants de type traitements, désignant les opérations définies dans desfonctions ou des méthodes associées aux classes. Ces dernières sont définiespar leur signature et leur corps. La signature d’une méthode indique le type dela valeur de retour, le nom de la méthode et la liste des arguments. Le corps estune suite d’instructions représentée dans la troisième catégorie de granularitéfine.

La troisième catégorie concerne les composants logiciels appartenant à un niveaude granularité fine (figure 4.3). Ils caractérisent les instructions et les structures decontrôle du programme. À ce niveau, les composants sont souvent regroupés enblocs. En effet, une instruction caractérise une succession de symboles qui repré-sentent des appels de méthodes ou de fonctions ou des affectations. Le composant“structure de contrôle” représente l’ensemble des structures de contrôle existantesdans les langages procéduraux et orientés-objet. Les composants, appartenant àce niveau de granularité, peuvent être liés à des composants du même niveau degranularité ou d’un niveau de granularité moyenne. La liaison s’effectue par des

4.2. SCSM : Software Component Structural Model 61

relations telles que la relation d’appel ou la relation d’utilisation.

Le modèle SCSM offre une représentation fine du logiciel basée sur l’ensemble deses codes sources, indépendamment de son architecture. Il ne traite pas le logiciel enun niveau d’abstraction plus élevé, à savoir, son architecture. Afin de pouvoir offrirune représentation de l’architecture, nous pouvons procéder selon deux approches :

1. La première approche consiste à spécifier les critères de recouvrement d’ar-chitecture à partir de la représentation du code source exprimé à l’aide dumodèle SCSM ; Le recouvrement d’architecture entre dans le cadre des activi-tés de rétro-ingénierie. De nombreux travaux ont été effectué dans ce domaine[CI90, FEB06, Maw07] et présentent de nombreux défis :

(a) la multiplicité des sources de données en entrée (code source, bytecode,binaires, librairies, etc.) implique une grande complexité dans la tâche derecouvrement d’architecture. Cette complexité s’accroît dans les cas de sys-tèmes distribués déployés sur des sites géographiquement distants.

(b) la multiplicité de vues à produire en sortie est également un défi pourles outils de la rétro-ingénierie. En effet, il peut avoir plusieurs points devues d’un logiciel en fonction du métier et des compétences des différentsintervenants [Gro00].

(c) la plupart des outils de rétro-ingénierie n’offrent que très peu de sou-plesse. Ils ne couvrent généralement que certaines fonctionnalités, d’où ladifficulté de trouver une manière de couvrir tous les besoins du projet.

2. la seconde approche consiste à (1) fournir un modèle représentant des archi-tectures logicielles indépendamment des codes sources du logiciel qui sontmodélisés à l’aide du modèle SCSM puis (2) de lier notre modèle au modèleSCSM par un couplage faible. Cette approche, simple à mettre en œuvre,nous permettra de faire évoluer les deux modèles indépendamment l’un del’autre. Nous pouvons ainsi étudier l’impact des modifications au niveau codesource, au niveau architectural ou sur les deux niveaux. Nous utiliserons cetteapproche pour la réalisation de nos travaux.

Nous proposons dans le cadre de cette thèse le modèle ASCM (ArchitecturalSoftware Components Model) pour représenter l’architecture d’un logiciel à un hautniveau d’abstraction. ASCM se veut indépendant d’un ADL particulier. Nous expri-mons, dans ce modèle, les concepts clés qui existent dans la plupart des ADLs. Nousillustrerons l’utilisation de notre modèle ASCM, par le biais d’exemples décrits dansle langage AADL.

Les objectifs du modèle ASCM sont les suivants :

1. fournir une représentation formelle des langages de description d’architecture,

62 4.3. Modélisation à base de graphes

quelque soit l’ADL utilisé. Cette représentation devra bien se prêter à l’analysede l’impact de modifications de l’architecture d’une application.

2. Coupler SCSM et ASCM, pour exprimer des liens entre les éléments des codessources de l’application et ceux de son architecture. Ceci permettra d’étudierl’impact d’une modification du code source vers l’architecture et inversement.

De nombreux travaux ont mis l’accent sur l’utilité des méthodes formelles pourla conception des architectures logicielles [AG94, IW95]. Cette formalisation accroîtleur niveau de réutilisation et permet de plus des analyses rigoureuses en enlevanttoute source d’ambiguïté. L’une des exigences majeures de la description architectu-rale est son abilité à spécifier l’architecture d’une manière simple. Une descriptionarchitecturale basée sur les graphes présente, en outre l’aspect formel, l’avantage defournir une description visuelle, simple et facilement compréhensible dans la mesureoù elle ne nécessite aucun pré-requis concernant les langages formels [M9́8, Gue07].Dans le cadre de nos travaux, nous utiliserons le formalisme des graphes pour lareprésentation de la description architecturale issus des ADLs ainsi que pour la ges-tion de la propagation d’impact du changement. En effet, nous associons à chaquedescription architecturale un graphe qui représente les différents éléments de cettedescription, à savoir, les composants constituant cette architecture, les interactionsentre ces composants et les caractéristiques associées à ces éléments. Les graphes ob-tenus représentent des instances de notre modèle. Ils permettent de manipuler lesdifférentes représentations logicielles issues du code source et de son architecture.

4.3 Modélisation à base de graphes

Les modèles SCSM et ASCM sont formalisés à l’aide de graphes. Dans cettesection, nous proposons quelques définitions concernant la notion de graphes, quipermettront d’appréhender la modélisation des codes sources du logiciel et de sonarchitecture ainsi que notre approche de propagation d’impact d’une modification.

4.3.1 Représentation basée sur les graphes

Les graphes présentent l’avantage d’offrir un formalisme simple et facilementcompréhensible permettant de décrire un large panel de structures. Ils permettentune modélisation très riche de la structure des composants logiciels. En effet, cescomposants logiciels sont des objets complexes et fortement interdépendants. Ainsi,un logiciel peut être vu comme étant un ensemble de nœuds (les composants) et unensemble d’arcs (les relations entre ces composants).Les composants et les relations peuvent être attribués, c’est-à-dire qu’il est possibled’associer un ou plusieurs attributs ou propriétés sur chaque nœud et chaque arc afinde différencier les types de composants et les types de relations. Leur forte expres-sivité fait que les graphes sont utilisés dans de nombreux domaines. De nombreux

4.4. Description des architectures à l’aide de graphes 63

travaux concernant la gestion des changements logiciels utilisent les graphes commemoyen de représentation et de formalisation [KGH+

94, Raj97a, CKKL02, HB08].

4.3.2 Définitions formelles

Le formalisme de base définit un graphe par l’ensemble de ses nœuds et l’en-semble de ses arcs. Ces graphes basiques sont décrits par un couple G=(N,A) où Nest l’ensemble des nœuds constituant le graphe. A est l’ensemble des arcs du grapheoù chaque arc est défini par un couple de deux éléments correspondant aux nœudsqu’il relie.

Il existe différents types de graphes permettant une représentation plus ou moinsprécise des logiciels. Nous retrouverons, les graphes orientés où les arcs possèdentun nœud de départ et un nœud d’arrivée. Dans ce cas, les arcs sont spécifiés parun couple de nœuds où le premier élément décrit le nœud de départ et le secondcorrespond au nœud d’arrivée.

Dans le cas où le système comprend plusieurs types de relations entre les nœuds,nous introduisons une fonction associant à chaque arc un poids ou une valeur. Legraphe est défini par un quadruplet G=(N,A,Etiq,E) où N et A gardent la même sé-mantique que dans les cas précédents. E est l’ensemble des attributs possibles desarcs et Etiq : A –> E est la fonction permettant de donner les valuations des arcs.

4.4 Description des architectures à l’aide de graphes

D’une manière générale, dans le cas de la description des architectures logicielles,les nœuds décrivent des composants logiciels alors que les arcs correspondent auxdifférentes relations entre ces composants. Ces relations peuvent correspondre, parexemple, à des canaux de communication ou à des liens de contrôle ou de composi-tion.Une approche de formalisation des architectures basée sur les graphes est encoreplus pertinente dans le cas de la gestion de leur évolution. D’une part, les aspectsdéclaratifs correspondants à la définition de toutes les instances correctes de l’archi-tecture peuvent être rigoureusement décrits par les grammaires des graphes. D’autrepart, les aspects opérationnels correspondant à l’évolution de l’architecture peuventêtre spécifiés par des systèmes à base de transformation de graphes.

Nous présentons, dans la section suivante, notre modèle ASCM pour la repré-sentation des architectures logicielles ainsi que les opérations pouvant lui être appli-quées.

4.5 Formalisation du modèle ASCM

ASCM est un modèle formel pour représenter la description des architectureslogicielles indépendamment des ADLs. Dans notre modèle, comme le décrit la fi-

64 4.5. Formalisation du modèle ASCM

Fig. 4.4 – ASCM : représentation UML des éléments existants dans les ADLs

gure 4.4, les éléments, existants dans la plupart des ADLs, sont interconnectés dela manière suivante : Un composant est représenté par une interface qui permet despécifier ses ports. Certains langages (Unicon, AADL) définissent les composants endeux parties : l’interface et l’implémentation. Cette séparation dans la définition decomposants n’existe pas dans les langages Rapide, WRIGHT et Acme. Par consé-quent, dans notre modèle, il est possible de n’associer aucune implémentation à uneinterface d’un composant. Par contre, la description de l’interface est toujours obliga-toire. Nous raffinons l’interface et l’implémentation en proposant de les représenter àl’aide d’une version. Ceci permettra de faire co-habiter plusieurs versions d’un mêmecomposant au sein d’une architecture. L’interface d’un composant possède au moinsun port lui permettant d’interagir avec les autres composants via les connecteurs.Un port peut participer à plusieurs connexions. À un composant peuvent être asso-ciées plusieurs propriétés non fonctionnelles décrites dans son interface ou dans sonimplémentation. L’interface et l’implémentation d’un composant peuvent être instan-ciés plusieurs fois dans une description architecturale. Elles peuvent également avoirdes sous-composants qui représentent des instances d’une autre interface ou implé-mentation d’un composant. L’instance d’un composant est déployé sur un site pourfournir une infrastructure logicielle et matérielle pour son exploitation. Ce point nesera pas traité en détail dans notre manuscrit. Nous estimons qu’il rentre dans lecadre matériel de configuration des applications que nous n’abordons pas dans lestravaux de cette thèse.

Une caractéristique majeure de notre modèle est son extensibilité afin de per-mettre d’étendre la description des éléments le constituant. À titre d’exemple, cer-

4.5. Formalisation du modèle ASCM 65

Fig. 4.5 – Extension de l’élément “Interface du Composant“ du modèle ASCM pour le langage AADL

tains ADLs définissent plusieurs catégories de composants. Les règles de composi-tion de ces catégories de composant sont généralement spécifiées dans la grammairedu langage concerné. En effet, chaque instance de notre modèle s’appuie sur la gram-maire de chaque ADL, dans laquelle nous donnons les règles d’utilisation du langage.Ce point, traitant de l’instanciation du modèle selon un ADL particulier, sera détaillédans le chapitre 6.

La figure 4.5 montre la façon dont le mécanisme d’extension est effectué avecASCM dans le cas du langage AADL qui identifie les catégories de composant sui-vantes : système, processus, thread, sous-programme ou données. Nous pouvons ainsiétendre la représentation des composants en utilisant le mécanisme d’héritage.Concernant les autres ADLs, il est aussi possible d’étendre notre modèle en spéci-fiant de nouvelles catégories de composants.

Nous décrirons, dans ce qui suit, la spécification du cadre formel pour la descrip-tion des architectures logicielles. Une architecture est décrite par un graphe enrichipermettant d’intégrer les différents paramètres de ses composants et leurs interdé-pendances.

4.5.1 Description du graphe de l’architecture

Dans nos travaux, nous avons adopté un graphe ordonné pour la formalisationdes architectures logicielles [HB08]. Ce graphe est défini par le quintuplet G = <N, E,T, A, R> où :

– N = {n1, n2, ..., nn} est un ensemble de nœuds représentant les éléments de l’ar-chitecture. Le nombre de nœuds de N est n (n > 1), ainsi |N|= n.

– E = {e1, e2, ..., em} est un ensemble d’arcs qui indiquent la nature de la relationexistante entre les deux nœuds qui lui sont associés. Les arcs permettent la pro-pagation d’impact d’une modification survenue sur un nœud du graphe. Pourpermettre la différenciation entre ces relations, les arcs du graphe possèdent unlabel. Le nombre d’éléments de E est m (m >= 1), ainsi |E| = m.


– T correspond au type de chaque nœud ou arc. Le type de nœud permet dedéfinir les opérations de modification qui peuvent être effectuées sur ce nœudtandis que le type de l’arc conduit l’impact de modification vers les nœudsdestinataires ou sources.

– A représente l’ensemble des attributs associés à un nœud. Par exemple,les nœuds de type propriété disposent d’un premier attribut name =nom_de_la_propriété et un second value = valeur_de_la_propriété.

– R indique les nœuds source et destination associés à chaque arc e ∈ E.Nous étendons cette représentation et utilisons dans ce manuscrit un graphe ordonnédéfini par le sextuplet G = <N, E, T, A, R, ET> où ET représente l’état de chaque nœudou arc du graphe. Lors de la création des éléments du graphe, ceux-ci sont dans unétat initial (créé). Cet état changera selon les opérations exécutées sur ces éléments.En particulier, un état précisera si un nœud ou un arc est affecté par une modification.

Nous présentons ci-après quelques définitions utiles pour la compréhension et lamanipulation du graphe.

Ordre du graphe : on appelle ordre d’un graphe, le nombre de nœuds de ce graphe.Ce paramètre est utile dans le cadre d’une étude qualitative des effets d’une modifica-tion. Par exemple, la métrique “pourcentage des nœuds affectés par la modification“se calcule comme suit :

PNAM =nombre de noeuds a f f ectes par la modi f ication

ordre du graphe

Chemin : un chemin dans un graphe G est une séquence d’arcs de G de la forme(e1, e2, ..., ek−1, ek) telles que les extrémités de ei soient ni−1 et ni, i = 1, .., k. Cette in-formation peut donner un aperçu sur le chemin possible des propagations d’impactsà partir d’un nœud modifié.

Adjacence d’un nœud : deux nœuds a et b sont adjacents si l’ensemble E contientl’arc e = (a, b). Les nœuds adjacents sont souvent qualifiés de voisins. À partir decette information, nous pouvons savoir si un nœud b sera directement affecté par lamodification d’un nœud a.

Voisinage extérieur d’un nœud : il est défini par la fonction τ+(x) = {y ∈ N|e =(x, y) ∈ E}. Il est l’ensemble de tous les nœuds adjacents à x, ayant x comme sourcede l’arc e. Ceci permettra de déterminer les nœuds en relation avec x ayant x commesource de la relation et qui peuvent être affectés par la modification de x.

Voisinage intérieur d’un nœud : il est défini par la fonction τ−(x) = {y ∈ N|e =(y, x) ∈ E}. Il est l’ensemble de tous les nœuds adjacents à x, ayant x comme des-tination de l’arc e. Ceci permettra de déterminer l’ensemble des nœuds en relationavec x ayant x comme destination de la relation et qui peuvent être affectés par la


modification de x.

Voisinage d’un nœud : il est défini par la fonction τ(x) = τ−(x)∪ τ+(x). Il est consti-tué de l’ensemble de tous les nœuds adjacents à x. Il permet de déterminer tous lesnœuds voisins à x qui peuvent être affectés par la modification de x.

Listing 4.1 – Exemple d’une représentation AADL� �1 subprogram Produce_Spg2 features3 Data_Source : out parameter ;4 end Produce_Spg;5

6 thread Prod7 features8 Data_Source_out : out data port;9 end Prod;

10

11 thread implementation Prod.Impl12 calls {13 P_Spg : subprogram Produce_Spg;14 };15 connections16 PC1 : parameter P_Spg.Data_Source −> Data_Source_out;17 properties18 Dispatch_Protocol => Periodic;19 Period => 200 Ms;20 end Prod.Impl;21

22 process processusA23 features24 AlphaA : out data port Alpha_Type;25 BetaA : in data port Alpha_Type;26 end processusA;27

28 process implementation processusA.Impl29 subcomponents30 Producer : thread Prod.Impl;31 Result_Consumer : thread Cons.Impl;32 connections33 PC3 : data port Producer.Data_Source_out −> AlphaA;34 PC4 : data port BetaA −> Result_Consumer.Data_Sink_in;35 end processusA.Impl;� �

4.5.2 Correspondances entre les éléments de ASCM et le graphe associé

Nous proposons d’établir les correspondances entre les éléments du modèleASCM et le graphe d’architecture obtenu à partir d’une description architecturale.Les éléments “Interface du composant”, “Implémentation du composant”, “Port”,“Connexion”, “Instance” et “Propriété” dans ASCM sont représentés par des nœudsdans le graphe d’architecture correspondant tandis que les relations entre “Interface”ou “Implémentation” du Composant et “Propriété”, “Interface” et “Implémentation”,“Interface” ou “Implémentation” et “Instance”, “Interface du composant” et “Port”,“Implémentation” ou “Interface” et “Connexions” et enfin “Connexion” et “Port”,sont représentées par des arcs dans le graphe correspondant.Ces correspondances couvrent les éléments communs à la plupart des ADLs. La


Élément AADL Élément du modèle ASCM Élément du graphe

Définition de l’interface du composant (system,process, thread, subprogram, data)

Interface nœud de type SYS (System), PR (Pro-cess), TH (Thread), SUB (Subprogram)ou DATA

Définition de l’implémentation du composant(system implementation, process implementa-tion, thread implementation, subprogram im-plementation)

Implémentation nœud de type SYS_IMP, PR_IMP,TH_IMP, ou SUB_IMP

Déclaration des sous-composants (system sub-component, process subcomponent, thread sub-component)

Instance nœud de type SYS_SUB, PR_SUB ouTH_SUB

Instance de sous-programme (subprogram call) Instance nœud de type SUB_CALL

Port (data port, event port, event data port) Port nœud de type DP, EP, ou EDP

Paramètres de sous-programmes (parameter) Port nœud de type PARAM

Connexion (data connection, event connection,event data connection, parameter connection)

Connexions nœud de type DC, EP, EDP, ou PC

Propriété (properties) Propriété nœud de type PR

Lien entre un sous-composant et sa définition(ex : ligne 30 ou 31 du listing 4.1)

Relation “aType” entre “In-terface” ou “Implémenta-tion” et “Instance”

Arc labélisé hasType, par exemple, entreles nœuds de type “TH” et “TH_SUB”

Lien entre l’interface d’un composant et son im-plémentation (ex : lignes 6 et 11 ou 22 et 28 dulisting 4.1)

Relation entre “Interface”et “Implémentation”

Arc labélisé impFor, par exemple, entreles nœuds de type “PR” et “PR_IMP”

Lien entre l’interface d’un composant et sesports (ex : lignes 6 et 8 ou 22 et 24 du listing 4.1)

Relation “possède” entre“Interface” et “Port”

Arc labélisé hasDP, hasEP, ou hasEDP,par exemple, entre les nœuds de type“SYS” et “DP”

Lien entre l’implémentation d’un composant etses connexions (ex : lignes 11 et 16 ou 28 et 33 dulisting 4.1)

Relation entre “Implémen-tation” et “Connexions”

Arc labélisé hasDC, hasEC, ou hasEDC,par exemple, entre les nœuds de type“TH_IMP” et “DC”

Lien entre l’implémentation d’un composant etses sous-composants (ex : lignes 28 et 30 du listing4.1)

Relation entre “Implémen-tation” et “Instance”

Arc labélisé hasSysSubComp,hasPrSubComp , ou hasThSubComp,par exemple, entre les nœuds de type“PR_IMP” et “TH_SUB”

Lien entre une connexion et ses ports source etdestination (ex : lignes 16 ou 33 du listing 4.1)

Relation “estRelié” entre“Port” et “Connexions”

Arc labélisé usePortSrc et usePortDest,par exemple, entre les nœuds de type“DC” et “DP”

Lien entre l’interface ou l’implémentation et sespropriétés (ex : lignes 11 et 18 ou 11 et 19 du listing4.1)

Relation “associe” entre“Interface” ou “Implémen-tation” et “Propriété”

Arc labélisé hasProperty, par exemple,entre les nœuds de type “PR” ou“PR_IMP” et “PROP”

Lien d’appel entre une implémentation d’unThread et l’instance d’un sous-programme (ex :lignes 11 et 13 du listing 4.1)

Relation entre “Implémen-tation” et “Instance”

Arc labelisé call entre les nœuds de type“TH_IMP” et “SUB_CALL”

Tab. 4.3 – Récapitulatif détaillé des éléments du langage AADL et leur correspondance dans le graphed’architecture

construction d’une description d’architecture propre à chaque ADL est définie par sagrammaire et est représentée par des attributs dans notre modèle ainsi que par desétiquettes (labels) dans le graphe correspondant. Dans le tableau 4.3, nous illustronsà l’aide du langage AADL l’ensemble des éléments de ce langage avec le résultatcorrespondant à un graphe d’architecture. Dans la première colonne, nous donnonsl’élément du langage AADL en spécifiant le mot réservé associé à cet élément définidans sa grammaire. Dans la deuxième colonne nous indiquons les éléments du mo-dèle ASCM se rapportant à ceux du langage AADL. Enfin, nous précisons dans ladernière colonne le résultat associé à cet élément de AADL dans le graphe corres-


pondant à la description architecturale.Ce tableau montre le processus de modélisation d’une architecture en partant de lagrammaire du langage AADL et en indiquant les correspondances vers notre modèleASCM. Ce dernier est formalisé sous forme de graphe sur lequel nous appliquonsdes opérations de modification.

4.5.3 Opérations pour la manipulation du graphe d’architecture

Les opérations de base pour manipuler le graphe d’architecture sont exprimées enun ensemble de propositions nommées “assertions” comprenant des pré-conditionsdevant être vérifiées au déclenchement de l’opération, des post-conditions vérifiantle résultat de l’opération et des invariants restant validés avant et après l’exécutionde l’opération. Plusieurs raisons nous ont amené à choisir le formalisme d’assertionscomme moyen pour décrire nos opérations. Les assertions sont largement utiliséesdans la communauté du logiciel comme un moyen formel pour spécifier le compor-tement des programmes [Men01].

Les tableaux 4.4, 4.5 représentent les assertions qui peuvent être vérifiées sur ungraphe comprenant des éléments ASCM. L’assertion est donnée dans la première co-lonne du tableau et sa signification dans la seconde. Les assertions préfixées par unsigne “+” expriment le fait que notre proposition doit être vérifiée selon la théorie degraphes. Celles préfixées par un signe “-” indiquent que les éléments de la proposi-tion sont absents dans le graphe. Les assertions précédées d’un point d’interrogation( ?) peuvent être considérées comme étant une proposition vérifiant l’existence d’unélément du graphe. Par exemple, l’assertion ?laSource(e) est une proposition dontl’objectif est de vérifier l’existence de l’arc e dans le graphe et d’indiquer le nœudsource de celui-ci.

Certaines assertions peuvent être composites (tableau 4.5), c’est-à-dire qu’ellessont construites à partir de plusieurs assertions simples (tableau 4.4). Par exemple,l’assertion +Arc(e, a, b) désigne le fait qu’il existe un arc e ayant le nœud a commesource et le nœud b comme destination. Cette assertion est construite par la compo-sition des deux assertions +source(e, a) et +dest(e, b).

À partir des assertions définies dans les deux tableaux 4.4 et 4.5, nous exprimonsles opérations de base permettant la manipulation d’un graphe. Nous les présentonsdans le tableau 4.6 et elles serviront pour déclencher le processus de propagationd’impact, présenté dans le chapitre suivant.Dans un souci de clarté, nous expliquons quelques opérations de ce tableau. L’opé-ration AjouterNoeud(n, t) permet d’ajouter au graphe un nœud n de type t. La pré-condition indique que n n’existe pas dans l’architecture. Le résultat de cette opérationest l’intégration d’un nouveau nœud n de type t dans le graphe. Aucun arc entrantou sortant ne doit être lié à n avant et après la réalisation de l’opération.L’opération AjouterArc(e, a, b, t) permet d’ajouter un arc e de type t entre les nœuds


Notation Signification+Id Existe un nœud ou un arc dans le graphe ayant l’identifiant Id+source(e, n) L’arc e doit avoir le nœud n comme nœud source+source(e, ∗) Existe un nœud n ∈ N avec n est la source de l’arc e ∈ E+source(∗, n) Existe un arc e ∈ E ayant le nœud n ∈ N comme nœud source+dest(e, n) L’arc e doit avoir le nœud n comme nœud destination+dest(e, ∗) Existe un nœud n ∈ N avec n est la destination de l’arc e ∈ E+dest(∗, n) Existe un arc e ∈ E ayant le nœud n comme nœud destination+type(Id, T) Le type du nœud ou arc ayant l’identifiant Id est T+type(Id, ∗) Existe t ∈ T avec ?leType(Id) = t+etat(Id, et) Le nœud ou arc Id est dans l’état et+etat(Id, ∗) Existe et ∈ ET avec ?etat(Id) = et+attribut(n, a, v) Le nœud n a un attribut a ayant la valeur v+sousComp(Id, Id2) Le nœud Id est un sous-composant du nœud Id2+sousComp(∗, Id) Le nœud Id dispose d’un ou plusieurs sous-composants+impl(cimp, c) Le nœud cimp représente une implémentation du nœud c+conn(cn, p) Le nœud p est un port attaché au nœud (connecteur) cn+connSousComp(cn, c) Le nœud cn (connecteur) utilise un port associé au sous-composant c+valeurProp(p, v) La valeur de la propriété p est v?laSource(e) Donne la source de l’arc e?laDest(e) Donne la destination de l’arc e?leType(Id) Donne le type du nœud ou arc Id?etat(Id) Donne l’état du nœud ou arc Id

Tab. 4.4 – Liste des assertions simples pour la manipulation du graphe d’architecture

Notation Signification+source(t∗, n) Existe un arc e ∈ E ayant le nœud n comme nœud source et le type de e est t.+source(−t∗, n) Existe un arc e ∈ E ayant le nœud n comme nœud source et le type de e est

différent de t.+source(t1, t2, ..., tn∗, n) Existe un arc e ∈ E ayant le nœud n comme nœud source et le type de e est t1,

ou t2, ... ou tn.+source(−t1, t2, ..., tn∗, n) Existe un arc e ∈ E ayant le nœud n comme nœud source et le type de e est

différent de t1, et t2, ... et tn.+dest(t∗, n) Existe un arc e ∈ E ayant le nœud n comme nœud destination et le type de e

est t.+dest(−t∗, n) Existe un arc e ∈ E ayant le nœud n comme destination et le type de e est

différent de t.+dest(t1, t2, ..., tn∗, n) Existe un arc e ∈ E ayant le nœud n comme nœud destination et le type de e

est t1, ou t2, ... ou tn.+dest(−t1, t2, ..., tn∗, n) Existe un arc e ∈ E ayant le nœud n comme nœud destination et le type de e

est différent de t1, et t2, ... et tn.+arc(e, a, b) L’arc e doit avoir le nœud a comme nœud source et le nœud b comme destina-

tion+arc(∗, a, b) existe un ou plusieurs arcs entre le nœud source a et le nœud destination b+arc(t∗, a, b) existe un ou plusieurs arcs de type t entre le nœud source a et le nœud desti-

nation b+arc(∗, n) existe un ou plusieurs arcs ayant le nœud n comme source ou destination

Tab. 4.5 – Liste des assertions composites pour la manipulation du graphe d’architecture

4.6. Mapping entre ASCM et SCSM 71

a et b. La pré-condition stipule que l’arc n’existe pas dans l’architecture. Le résultatde cette opération est l’intégration d’un nouveau arc e de type t dans le graphe. Cetarc relie les nœuds a et b. L’existence des nœuds a et b doit être vérifiée avant et aprèsla réalisation de l’opération.

Opération Pré-condition Post-condition InvariantAjouterNoeud(n, t) −n +n

+type(n, t)−arc(∗, n)

AjouterArc(e, a, b, t) −e +e+type(e, t)+arc(e, a, b)

+a+b

SupprimerNoeud(n) +n −n −arc(∗, n)SupprimerArc(e, a, b) +e

+arc(e, a, b)−e−arc(e, a, b)

+a+b

AjouterAttribut(n, a, val) +v +attribut(n, a, val) +nChangerTypeNoeud(n, t) +n +type(n, t) +nChangerEtat(n, et) +n +etat(n, et) +n

Tab. 4.6 – Liste des opérations de base s’appliquant sur un graphe

Dans la section suivante, nous proposons un couplage entre le modèle SCSM,représentant les codes sources d’un logiciel et le modèle ASCM qui représente sonarchitecture. L’objectif de ce couplage entre SCSM et ASCM est de propager l’impactd’une modification de l’architecture vers son code source et inversement.

4.6 Mapping entre ASCM et SCSM

L’ensemble des éléments constituants les codes sources d’un logiciel sont repré-sentés par le modèle SCSM. Dans les travaux de L. Deruelle [Der01], une approchepour la propagation d’impacts a été proposée sur la base de ce modèle. Cependant,cette approche ne tient pas compte de l’aspect architectural d’une application. Le cou-plage du modèle SCSM et du modèle ASCM consiste à formaliser les liens pouvantexister entre les éléments de ces deux modèles. Les relations entre modèles serontutilisées pour propager l’impact d’une modification réalisée sur la description archi-tecturale vers son code source correspondant et inversement. Les figures 4.6 et 4.7montrent les relations établies entre les éléments des deux modèles.

Un composant ASCM est défini par son interface et son implémentation. Au ni-veau grosse granularité, ceux-ci se projettent dans le code source d’un logiciel sous laforme de fichiers, contenant l’ensemble des instructions réalisant les éléments de l’ar-chitecture. Ces instructions sont structurées généralement sous la forme de fonctionsou méthodes (qui est un cas particulier d’une fonction définie dans une classe). Nousconsidérons que les classes, les interfaces, les structures, les méthodes et les fonctionsreflètent l’interface et l’implémentation des composants ASCM. Nous modélisons celien à l’aide d’une relation appelée “Projection”. Tous les éléments de notre modèleASCM peuvent être projeté vers SCSM. Pour des raisons de clarté, nous ne montrons

72 4.6. Mapping entre ASCM et SCSM

Fig. 4.6 – Mapping entre ASCM et SCSM : niveau grosse granularité

Fig. 4.7 – Mapping entre ASCM et SCSM : niveau moyenne granularité

que les projections des éléments “interface du composant” et “implémentation ducomposant” sur les niveaux de grosse et moyenne granularité. Notre mapping s’ap-plique également sur les autres éléments de ASCM tels que le port qui est projeté enun paramètre dans le modèle SCSM et la propriété qui est projetée en une variableou une suite d’instructions dans le niveau de granularité fine.

Les langages de description d’architecture fournissent généralement une syntaxe

4.6. Mapping entre ASCM et SCSM 73

Fig. 4.8 – Exemple de mapping entre ASCM et SCSM

permettant de spécifier le nom de l’implémentation d’un composant en terme decodes sources. Dans le cas où le langage ne dispose pas d’une syntaxe particulièrepour spécifier l’implémentation, une analyse de code source sera nécessaire pour éta-blir le lien de projection entre les composants ASCM et leur implémentation en codesource. Une approche classique, permettant d’établir ces liens, consiste à fournir desannotations dans le code source. Chaque annotation précise le type de composantASCM et peut comporter des attributs. Ceux-ci sont un moyen pour enlever touteambiguïté lorsque plusieurs composants de même type existent dans l’architecture.À titre d’exemple, une annotation “@Port(name =′ portA′, param =′ paramM′) peutêtre définie, au niveau d’une méthode, afin d’indiquer que le paramètre ”paramM“de la méthode est associé au port ASCM ayant le nom portA.

SCSM et ASCM permettent de propager l’impact d’une modification, effectuéesoit au niveau de l’architecture (ASCM), soit au niveau du code source (SCSM), res-pectivement sur le code source et l’architecture. Les modèles ASCM et SCSM sontcouplés faiblement, à l’aide de la relation de projection, et peuvent être utilisés indé-pendamment. La modélisation de l’architecture d’un logiciel et son évolution peuventêtre étudiées sans les codes sources du logiciel. Lorsque ceux-ci existent, la modéli-sation du logiciel est plus précise et l’analyse d’impact d’une modification s’effectuesur le niveau architectural et sur les composants du code source.

La figure 4.8 illustre un exemple de mapping entre ASCM et SCSM. La partie(A) de la figure correspond à la description architecturale exprimée en AADL. Lapartie (B) représente le graphe associé à (A). La partie (C) correspond au code source

74 4.7. Conclusion

du sous-programme spécifié dans l’architecture et enfin la partie (D) correspond augraphe associé à (C). Le sous-programme Produce_Spg possède deux propriétés :la première, source_language, indique que ce sous-programme est exprimé dans lelangage Ada dans le code source ; la deuxième, source_name, indique que le fichiercontenant le code source est Producer_Consumer et que la fonction ou la procédureassociée au sous-programme est Produce_Spg. Les liens entre les deux représenta-tions sont établis à l’aide de la relation de projection.

4.7 Conclusion

Ce chapitre est consacré à l’étude de plusieurs modèles et outils dédiés à l’évo-lution des architectures logicielles. Afin de positionner nos travaux de modélisation,nous avons défini des critères pour les évaluer.Sur la base de ces critères, un premier bilan a été établi montrant une certainelacune dans l’analyse de l’impact d’une modification du niveau architectural versle code source correspondant. De nombreuses approches traitent de la propagationd’impact de modifications au niveau du code source. Le modèle SCSM, proposé parL. Deruelle, est l’un des modèles permettant la représentation des codes sourcesmulti-langages selon plusieurs niveaux de granularité. Ce modèle est formalisé àl’aide de graphes, dans lequel les nœuds représentent les composants et les arcs lesrelations entre eux.La représentation du logiciel à l’aide de graphes fait partie des techniques les pluscouramment utilisées dans le domaine de l’analyse d’impact. À l’aide de ce for-malisme, nous avons proposé un modèle, appelé ASCM, permettant de représenterles éléments existants dans la plupart des langages de description d’architectures(ADLs). Ce modèle est extensible et offre un cadre pour la représentation des archi-tectures logicielles pouvant être décrites à l’aide d’un ADL quelconque.Nous avons couplé faiblement les modèles SCSM et ASCM en définissant une re-lation de projection. Cette relation bidirectionnelle permet, pour tout élément dumodèle ASCM de l’associer à un ou plusieurs éléments du modèle SCSM. Ce cou-plage offre un moyen simple de propager l’impact d’une modification du niveauarchitectural vers le code source et inversement.Nous avons tenté de définir un ensemble d’assertions permettant de vérifier certainespropriétés du graphe d’architecture issu de notre modèle ASCM. Ces assertions ontété un préambule nécessaire pour formaliser les opérations de manipulation dugraphe. Ces dernières sont essentielles afin de déclencher le processus de propaga-tion d’impact d’une modification, lorsqu’elles sont appliquées sur le graphe.

Nous proposons, dans le chapitre suivant, de définir notre processus de propaga-tion d’impact, basé sur les opérations de manipulation du graphe. Nous étudierons,

4.7. Conclusion 75

dans un premier temps, l’impact que peut avoir chaque opération, puis nous défini-rons un ensemble de règles formelles exprimant la propagation.

5Evolution et propagation

d’impact de modification dans

une architecture logicielle

Sommaire

5.1 L’évolution des architectures logicielles . . . . . . . . . . . . . . . . 79

5.2 Typologie des opérations de modifications architecturales . . . . 81

5.2.1 Ajout d’une interface d’un composant . . . . . . . . . . . . . . . . . . . 81

5.2.2 Ajout d’une implémentation à un composant . . . . . . . . . . . . . . . 82

5.2.3 Ajout d’un connecteur . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

5.2.4 Suppression d’un connecteur . . . . . . . . . . . . . . . . . . . . . . . . 84

5.2.5 Suppression d’une interface d’un composant . . . . . . . . . . . . . . . 85

5.2.6 Suppression d’une implémentation d’un composant . . . . . . . . . . 87

5.2.7 Modification d’un connecteur . . . . . . . . . . . . . . . . . . . . . . . . 88

5.2.8 Changements d’interface . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

5.2.9 Ajout d’une propriété . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

5.2.10 Suppression d’une propriété . . . . . . . . . . . . . . . . . . . . . . . . 92

5.2.11 Changement de la valeur d’une propriété . . . . . . . . . . . . . . . . . 93

5.2.12 Ajout d’un sous-composant . . . . . . . . . . . . . . . . . . . . . . . . . 94

5.2.13 Suppression d’un sous-composant . . . . . . . . . . . . . . . . . . . . . 95

5.2.14 Changement du type de port de connexion . . . . . . . . . . . . . . . . 96

5.3 Processus de propagation d’impact . . . . . . . . . . . . . . . . . . . . . . 97

5.3.1 Approches algorithmiques pour la propagation d’impact . . . . . . . . 97

5.3.2 Approches basées sur les règles . . . . . . . . . . . . . . . . . . . . . . . 98

5.3.3 Définition d’un système expert (SE) . . . . . . . . . . . . . . . . . . . . 98

5.3.4 Règles de propagation d’impact . . . . . . . . . . . . . . . . . . . . . . 100

5.3.5 Propagation d’impact de l’architecture vers le code source . . . . . . . 103

5.3.6 Illustration du processus de propagation d’impact . . . . . . . . . . . . 104

5.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

5.1. L’évolution des architectures logicielles 79

Les applications informatiques sont en constante évolution afin de s’adapter auchangement de technologie, d’environnement d’exécution et des besoins des uti-

lisateurs. Ces évolutions imposent des modifications successives de l’architecture del’application visant à ajouter, modifier ou retirer des fonctionnalités du logiciel. Parexemple, des composants peuvent être remplacés par de nouvelles versions, leurssites d’exécution peuvent être modifiés, un composant client peut utiliser un compo-sant serveur différent afin d’intégrer de nouvelles fonctions.

Le changement dans une architecture logicielle peut générer des effets inatten-dus sur le fonctionnement du système. En effet, un changement survenu sur uncomposant de l’architecture du logiciel peut avoir un impact sur la globalité de l’ar-chitecture, du fait de l’interdépendance de ses constituants. Afin d’étudier ces effetsinattendus, il est nécessaire de disposer d’un processus de contrôle de l’impact dela modification d’une architecture logicielle. Ce processus contribue à l’identificationdes parties affectées par la modification.

Dans ce chapitre nous présentons les différents types d’évolutions architecturales.Nous définissons ensuite le processus de propagation d’impacts.

5.1 L’évolution des architectures logicielles

L’évolution d’une architecture peut être vue comme un ou plusieurs change-ments effectués sur un ou plusieurs constituants de l’architecture. Ces modificationsimpliqueront des effets de bords sur le reste de l’architecture de part leur forteinterdépendance. Il est primordial de procéder à un examen exhaustif de l’impactde la modification d’un élément de l’architecture en déterminant tous les élémentspouvant être affectés par la modification.Nous pouvons identifier deux catégories d’impact suite à des modifications archi-tecturales. La première concerne les effets de la modification sur la structure del’architecture, tandis que la seconde porte sur les effets comportementaux, c’est-à-dire pendant l’exécution du logiciel. Notre travail se focalise sur l’étude des effetsd’une modification sur la structure de l’architecture. La modification d’un élémentarchitectural représenté à l’aide du modèle ASCM peut avoir plusieurs effets sur lesautres éléments de ce modèle. Nous identifierons les éléments du modèle affectéspar cette modification. Certains impacts comportementaux seront traités sur le codesource correspondant à l’architecture.

Dans un premier temps, nous formalisons l’ensemble des opérations de modi-fication pouvant affecter chaque élément du modèle ASCM. Pour la réalisation deces opérations, nous supposons qu’une étape préliminaire a précédée l’opération etpermettant ainsi le respect de ses invariants. Prenons, par exemple, l’opération desuppression d’une implémentation d’un composant “cimp”. Avant de procéder à sasuppression, il faut vérifier et supprimer ses connecteurs, ses sous-composants et les

80 5.1. L’évolution des architectures logicielles

sous-composants instanciés à partir de “cimp”, autrement dit que “cimp” devientisolé du reste de l’architecture afin de pouvoir ensuite le supprimer. Dans ce cas defigure, il n’y a aucun impact sur le reste de l’architecture. Si ces vérifications ne sont

Libellé Opération Pré-condition Post-condition InvariantAjout d’une inter-face d’un compo-sant

ajouter_int_comp(c, t) −c+t

+c −arc(∗, c)

Ajout d’une im-plémentation d’uncomposant

ajouter_imp_comp(cimp, c) −cimp +cimp+arc(∗, c, cimp)

+c

Ajout d’un connec-teur

ajouter_conn(r, c, a, p1, b, p2) −r +r+arc(hasConn∗, c, r)+arc(usePortDst∗, r, p2)+arc(usePortSrc∗, r, p1)

+c+a+b+p1+p2+arc(hasPort∗, a, p1)+arc(hasPort∗, b, p2)

Suppression d’unconnecteur

supp_conn(cn, c, a, b) +cn+arc(hasConn∗, c, r)+arc(usePortSrc∗, cn, a)+arc(usePortDst∗, cn, b)

−cn−arc(∗, cn)

+a+b+c

Suppression d’uneinterface d’un com-posant

supp_comp_int(a) +a −a−impl(∗, a)−arc(∗, a)

−sousComp(∗, a)(−sousComp(∗, ai),+ impl(ai, a))

Suppression d’uneimplémentationd’un composant

supp_comp_imp(c, cimp) +cimp −cimp−arc(∗, cimp)

+c−sousComp(∗, cimp)−source(hasSubComp∗,

cimp)Modification de lasource d’un connec-teur

mod_src_conn(c, p, p1) +arc(e, c, p)+type(e, usePortSrc)

−arc(∗, c, p)+arc(e1, c, p1)+type(e1, usePortSrc)

+c+type(c, connecteur)+p+type(p, port)+p1+type(p1, port)

Modification de ladestination d’unconnecteur

mod_dest_conn(c, p, p1) +arc(e, c, p)+type(e, usePortDst)

−arc(∗, c, p)+arc(e1, c, p1)+type(e1, usePortDst)

+c+type(c, connecteur)+p+type(p, port)+p1+type(p1, port)

Ajout d’un port ajouter_port(a, p) −p +p+type(p, port)+arc(hasPort∗, a, p)

+a

Suppression d’unport

supp_port(a, p) +p+type(p, port)+arc(e, a, p)

−p−arc(∗, p)

+a−dest(usePortSrc∗, p)−dest(usePortDst∗, p)

Ajout d’une pro-priété

ajouter_prop(a, p) −p ∨(+p ∧ −arc(∗, a, p))

+p+arc(e, a, p)+type(e, hasProp)

+a

Suppression d’unepropriété

supp_prop(a, p) +p+arc(e, a, p)+type(e, hasProp)

−p−arc(∗, p)

+a

Changement d’unepropriété

changer_prop(a, p, v) +p +valeurProp(p, v) +a

Ajout d’un sous-composant

ajouter_sous_comp(a, s, t) −s ∨(+s ∧ −arc(e, a, s))

+s+arc(e, a, s)+type(e, hasSubComp)

+a+t

Suppression d’unsous-composant

supp_sous_comp(a, s) +s+arc(hasSubComp∗, a, s)

−s−arc(∗, s)

+a−connSousComp(∗, s)

Changement dutype de port

changer_type_port(a, p, t) +type(p, t) +a+p+arc(hasPort∗, a, p)−source(usePortSrc∗, p)−source(usePortDst∗, p)

Tab. 5.1 – Liste des opérations de modification affectant l’architecture

5.2. Typologie des opérations de modifications architecturales 81

pas effectuées avant la suppression du sous-composant, c’est-à-dire que les invariantssont violés, nous simulons l’exécution de l’opération en marquant les nœuds et lesarcs affectés par sa réalisation. Cette simulation permet de ressortir les vérificationsqui devaient être effectuées préalablement à l’exécution de l’opération.Dans un second temps, nous définissons le processus de propagation d’impacts gé-nérique déclenché lors de l’application des opérations de modification.

5.2 Typologie des opérations de modifications architectu-rales

L’ensemble des opérations de modification est présenté dans le tableau 5.1 en uti-lisant le formalisme d’assertions présenté dans le chapitre précédent. Ces opérationssont formalisées selon une pré-condition devant être vérifiée afin que l’opération soitexécutée. La post-condition indique le résultat de l’opération. L’invariant représenteles propositions à vérifier avant et après l’exécution de l’opération. Chaque opérationest illustrée par un exemple issu d’une description architecturale spécifiée dans lelangage AADL. L’opération de modification est appliquée sur cet exemple et est re-présentée par un rectangle noir. Un graphe ASCM, représentant l’exemple, est donnéavant et après la réalisation de l’opération afin de clarifier son résultat. L’opérationde modification est représentée sur le graphe comme un événement représentant lemessage d’invocation responsable du déclenchement automatique du processus depropagation d’impact. Cet événement peut être associé à un élément particulier dugraphe ou bien à la configuration générale de l’architecture. Dans les exemples illus-trant chaque opération de modification, les nœuds et les arcs en pointillé représententles éléments modifiés suite à sa réalisation.

5.2.1 Ajout d’une interface d’un composant

Fig. 5.1 – Ajouter une interface d’un composant

82 5.2. Typologie des opérations de modifications architecturales

L’opération “ajouter_int_comp(c, t)” consiste à ajouter une interface d’un compo-sant ASCM “c” de type “t” à l’architecture existante. Afin que cette opération soitpossible, deux pré-conditions doivent être vérifiées. La première, notée “−c”, stipuleque le composant ajouté n’existe pas dans l’architecture. La deuxième, notée “+t”,stipule que le type associé au composant créé doit être défini dans la grammaire dulangage de description architectural utilisé. Le résultat de cette opération est l’intégra-tion d’une nouvelle interface de composant ASCM à l’architecture et par conséquentun nouveau nœud typé dans le graphe d’architecture. Aucun arc ne doit être lié à“c” avant et après la réalisation de l’opération.

La figure 5.1 illustre l’opération d’ajout d’une interface d’un composant “Q”de type “thread” à l’architecture existante. Cette modification doit être suivie pard’autres opérations afin de compléter l’interface de ce nouveau composant (ex : ajoutde ports de connexion, ajout d’une implémentation du composant).

Cette opération n’entraîne aucun impact structurel sur le reste de l’architecturedu fait qu’il est isolé des autres éléments. Cependant, celle-ci nécessitera l’ajout d’uneméthode ou d’une fonction associée à ce composant dans le code source correspon-dant à l’architecture .

5.2.2 Ajout d’une implémentation à un composant

Fig. 5.2 – Ajouter une implémentation à un composant

L’opération “ajouter_imp_comp(cimp, c)” consiste à ajouter une implémentation“cimp” à une interface d’un composant ASCM “c”. Afin que cette opération soit pos-sible, il faut vérifier que l’implémentation du composant ajouté n’existe pas dans l’ar-chitecture. Le résultat de cette opération est l’intégration d’un nouvel élément ASCMà l’architecture et par conséquent un nouveau nœud typé dans le graphe d’archi-tecture. Un arc reliant l’interface du composant “c” à son implémentation “cimp”est ajouté dans le graphe d’architecture suite à la réalisation de l’opération. L’exis-tence de l’interface du composant “c” doit être vérifiée avant et après la réalisationde l’opération.


La figure 5.2 illustre l’opération d’ajout d’une implémentation “Q.Impl” associéeau composant “Q”. Cette opération peut être suivie par d’autres opérations afin decompléter la définition de “Q.Impl” (ex : ajout de sous-composants, ajout de connec-teurs).

Cette opération n’entraîne aucun impact structurel sur le reste de l’architecturetandis que sur le code source correspondant, ceci se traduit par l’ajout d’une méthodeou d’une fonction correspondante à ce composant.

5.2.3 Ajout d’un connecteur

Fig. 5.3 – Ajouter un connecteur

L’opération “ajouter_conn(r,c,a,p1,b,p2)” consiste à ajouter une relation “r” aucomposant “c” entre les ports “p1” du composant “a” et “p2” du composant “b”. Lapré-condition “−r”, indiquant que le connecteur ajouté n’existe pas dans l’architec-ture, doit être vérifiée. Le résultat de cette opération est l’intégration d’une nouvelle


connexion ASCM à l’architecture à laquelle correspond un nœud dans le graphe.Trois arcs reliant ce connecteur à ses deux ports (source et destination) et à son com-posant sont également ajoutés au graphe. Plusieurs invariants sont à vérifier avant etaprès l’exécution de cette opération :

– les composants “a”, “b” et “c” doivent exister dans l’architecture. Ces troiscomposants sont représentés par trois nœuds dans le graphe d’architecture ;

– les ports “p1” du composant “a” et “p2” du composant “b” doivent être pré-sents dans l’architecture et par conséquent, deux nœuds correspondants dansle graphe ainsi que deux arcs les reliants aux nœuds correspondant à “a” et“b”.

La figure 5.3 illustre l’opération d’ajout d’un connecteur “C” entre les ports“Data_Source” du thread “P” et “Alpha”. Dans ce cas, l’événement invoquant l’opé-ration est envoyé sur le nœud “A.Impl” du graphe d’architecture (partie 2 de lafigure). Le graphe obtenu suite à cette opération intègre un nouveau nœud “C” ainsique trois arcs reliant ce nœud à son composant et à ses ports source et destination(partie 3 de la figure)

L’ajout d’un connecteur entre deux composants ne conduit à aucun impact struc-turel sur le reste de l’architecture. Ceci se traduit, dans le code source correspondant,par l’ajout d’une nouvelle relation d’appel ou d’utilisation entre la méthode ou lafonction associée au composant (dans l’exemple, “A.Impl”) et celle associée au typedu sous-composant (dans l’exemple, “P.Impl”).

5.2.4 Suppression d’un connecteur

L’opération “supp_conn(cn,c,a,b)” consiste à supprimer un connecteur ASCM“cn” défini dans le composant “c” et reliant les ports “a” et “b”. La première pré-condition indique qu’un connecteur doit être présent dans l’architecture et représentépar un nœud dans le graphe. La seconde pré-condition, notée +arc(hasConn∗, c, r),précise qu’il existe un arc, de type “hasConn” reliant le connecteur ”r“ à son com-posant “c”. La troisième pré-condition, notée +arc(usePortSrc∗, cn, a), stipule qu’ildoit exister un arc de type “usePortSrc” reliant “r” à son port source “a”. Un der-nier arc de type “usePortDst” doit exister entre “cn” et son port destination “b”.Le résultat de cette opération est la suppression du connecteur de l’architecture etpar la suite son nœud correspondant sera marqué comme étant supprimé a priori dugraphe d’architecture. Les arcs en destination ou en source de ce connecteur serontaussi marqués comme supprimés a priori du graphe d’architecture. L’existence desports “a” et “b” et du composant “c” doit être vérifiée avant et après l’exécution del’opération. Le marquage a priori des nœuds et des arcs du graphe permet d’iden-tifier les éléments affectés par une modification. Ceci déclenchera le processus depropagation d’impact.

La figure 5.4 montre un exemple d’une opération de suppression d’un connec-teur “C”. L’événement est envoyé sur le nœud correspondant dans le graphe d’ar-


Fig. 5.4 – Supprimer un connecteur

chitecture. Cette suppression entraîne un impact au niveau de l’architecture, qui estreprésenté par le marquage a priori de ce nœud ainsi que des trois arcs le reliant à soncomposant et à ses ports source et destination. Un impact a priori sur le code sourceconcerne la suppression des instructions réalisant la transmission du message entreles composants concernés par le connecteur.

5.2.5 Suppression d’une interface d’un composant

L’opération “supp_comp_int(a)” consiste à supprimer une interface d’un compo-sant “a” de l’architecture existante. Afin que l’opération soit réalisable, ce composantdoit exister dans l’architecture et par conséquent un nœud correspondant doit êtreprésent dans le graphe. Les invariants stipulent qu’aucun sous-composant ayant letype “a” ne doit être défini dans l’architecture (−sousComp(∗, a)) et qu’il n’existeaucun sous-composant ayant le type “ai” qui représente l’implémentation associée à


Fig. 5.5 – Supprimer un composant

“a”. Le résultat de cette opération est la suppression de l’interface du composant, deses implémentation et de tous ses arcs entrants et sortants. En effet, la suppressiond’une interface d’un composant “C” peut être considérée comme une opérationcomposite englobant les opérations suivantes : (1) supprimer les ports de “C”, (2)supprimer les propriétés de “C”, (3) supprimer les implémentations de “C” et enfin(4) supprimer l’interface du composant “C”.La figure 5.5 montre un exemple de suppression de l’interface d’un composant “Q”de l’architecture. Dans notre modèle ASCM et en prenant l’exemple du langageAADL, le composant est défini en deux parties : l’interface et l’implémentation. Lasuppression de l’interface d’un composant implique que son implémentation avecses sous-composants seront supprimés. L’exemple présenté montre que l’interfacedu composant n’est relié à aucun autre élément du graphe (à l’exception de ses portset son implémentation). En général, les composants sont instanciés plusieurs foisdans une architecture.

La suppression d’une interface d’un composant n’a aucun effet sur l’architecturedans le cas où celle-ci n’est pas instanciée dans l’architecture. Sur le code source, cecise traduit par la suppression de la fonction ou la méthode associée à ce composant.Dans le cas le plus fréquent, à savoir une interface d’un composant qui est instanciéeau moins une fois dans l’architecture, la suppression de l’interface “ai” d’un com-posant entraîne le marquage a priori des nœuds représentant les sous-composantsayant pour type “ai” ainsi que tous les arcs les reliant à “ai”. Si une implémenta-tion “aimp” est associée à “ai”, cette opération aura comme effet de marquer a prioriles sous-composants de type “aimp”. Ceci sera abordé lors de la spécification duprocessus générique pour la propagation d’impact.


5.2.6 Suppression d’une implémentation d’un composant

Fig. 5.6 – Supprimer une implémentation d’un composant

L’opération “supp_comp_imp(c,cimp)” consiste à supprimer l’implémentation“cimp” associée à l’interface du composant “c” de l’architecture existante. Afin quel’opération soit réalisable, l’implémentation du composant doit exister dans l’archi-tecture et par conséquent, un nœud correspondant doit être présent dans le graphe.L’invariant stipule que l’existence de l’interface du composant “c” doit toujours êtrevérifiée avant et après la réalisation de l’opération. Aucune instance de “cimp” nedoit être définie dans l’architecture (−sousComp(∗, cimp)). “cimp” ne doit conteniraucun sous-composant dans sa définition (−source(hasSubComp∗, cimp)). Le résultatde cette opération est la suppression de l’implémentation du composant ainsi que del’ensemble de ses arcs entrants et sortants.La figure 5.6 montre un exemple de suppression de l’implémentation “Q.Imp”associée à “Q”. L’exemple montre que l’implémentation ne contient aucun sous-composant et que par la suite aucun connecteur n’est défini dans cette implémen-tation. Or, généralement nous trouvons un ou plusieurs sous-composants dans laspécification de l’implémentation d’un composant.La suppression de l’implémentation d’un composant n’aura aucun effet sur l’archi-tecture dans le cas où celle-ci n’est pas instanciée dans l’architecture et ne contientaucun sous-composant. Sur le code source, ceci se traduit par la suppression de lafonction ou la méthode associée à cette implémentation du composant. Lorsque l’im-plémentation d’un composant contient un ou plusieurs sous-composants, ceci en-traîne le marquage a priori de ces sous-composants ainsi que des connecteurs utilisantleurs ports. S’il existe des sous-composants ayant le type “implémentation du compo-sant” supprimé, ceci entraîne également le marquage a priori de ces sous-composants.En effet, lorsque les invariants d’une opération ne sont pas respectées, ceux-ci dé-


Fig. 5.7 – Modifier la source d’un connecteur

clenchent le processus de propagation d’impact de modification et par conséquent,le marquage des nœuds et des arcs affectés par l’opération.

5.2.7 Modification d’un connecteur

Les modifications notées “mod_src_conn(c,p,p1)” et “mod_dst_conn(c,p,p1)”consistent à changer la source et la destination d’un connecteur. La modificationd’un connecteur est une opération composite définie par (1) la suppression duconnecteur existant puis par (2) l’ajout d’un nouveau connecteur selon de nouvellescontraintes.Considérons l’opération qui consiste à modifier la source “p” du connecteur “c” en


Fig. 5.8 – Modifier la destination d’un connecteur

lui attribuant la nouvelle source “p1”. Cette opération nécessite la vérification d’unepré-condition indiquant l’existence d’un arc “e” reliant “c” à “p” et que le type decet arc montre l’utilisation d’un port en tant que source de connecteur, noté “use-PortSrc”. Cette opération entraîne la suppression de l’arc “e” du graphe représentantl’architecture, puis l’ajout d’un nouvel arc “e1” reliant “c” à sa nouvelle source “p1”.Le type de ce nouvel arc conserve la valeur de l’arc supprimé, à savoir “usePortSrc”.L’existence de la connexion ASCM “c” et des ports “p” et “p1”, par conséquent detrois nœuds correspondants dans le graphe d’architecture, doit être vérifiée avant etaprès l’exécution de l’opération.La figure 5.7 illustre l’opération de modification de la source d’un connecteur enattribuant au connecteur “C” la nouvelle source “Data_Sink”. L’arc qui reliait “C” à


“Data_Source” est supprimé du graphe et un nouvel arc est ajouté entre “C” et sanouvelle source “Data_Sink”.La modification de la source d’un connecteur se traduit tout d’abord par une sup-pression de ce connecteur. Ceci entraîne un impact structurel sur l’architecture quiconsiste à marquer a priori le composant dans lequel le connecteur est défini. La re-création du connecteur avec sa nouvelle source va rétablir l’architecture et entraînele dé-marquage du composant marqué. Au niveau du code source, ceci entraîne lemarquage puis le dé-marquage de la méthode ou la fonction associée au composantdans lequel est défini le connecteur.

Considérons la deuxième opération visant à modifier la destination du connec-teur. Celle-ci est similaire à la première en distinguant le type de l’arc par “use-PortDst” au lieu de “usePortSrc”. Dans la figure 5.8, la destination du connecteur“C” est devenue le port “Beta” au lieu de “Alpha”. Par conséquent, l’arc qui reliait“C” à “Alpha” est supprimé du graphe et un nouvel arc entre “C” et “Beta” est ajouté.

L’impact de la modification de la destination d’un connecteur est identique à celuide la modification de sa source.

5.2.8 Changements d’interface

Fig. 5.9 – Ajouter un port à un composant

Les changements d’interface permettent d’ajouter ou de supprimer des portsd’un composant. La première opération, notée “ajouter_port(a,p)” consiste à ajouterun port “p” à un composant “a”. La non existence du port “p” dans l’architecturedoit être vérifiée afin d’exécuter l’opération. La réalisation de cette opération aboutità la création d’un nouveau port dans l’architecture et par conséquent d’un nouveaunœud typé dans son graphe. Un arc reliant le composant “a” à ce port est ajouté augraphe d’architecture. L’existence du composant “a” doit être vérifiée avant et aprèsla réalisation de l’opération.La figure 5.9 montre un exemple d’ajout d’un port de connexion “Beta” au com-posant “A”. Cette opération n’a aucun impact sur l’architecture. Sur le code sourcecorrespondant, cette opération peut être traduite par l’ajout d’un paramètre à la


méthode ou la fonction associée au composant concerné par l’opération.

La deuxième opération, notée “supp_port(a,p) consiste à supprimer un port “p”d’un composant “a”. L’existence du port “p”, représenté par un nœud dans le graphed’architecture ainsi que l’arc reliant ce port à “a” sont les pré-conditions à vérifier afind’exécuter l’opération. L’invariant de l’opération indique que la présence du compo-sant “a” avant et après l’opération est à vérifier et qu’il ne doit pas exister d’arcs detype “usePortSrc” ou “usePortDst” en destination de ce port. Le résultat de cette opé-ration est la suppression du port “p” et de son nœud correspondant dans le graphe.L’arc reliant le composant “a” à “p” est également supprimé.

Fig. 5.10 – Supprimer un port d’un composant

La figure 5.10 illustre l’opération de suppression du port “Beta”. Dans cet exemple,ce port n’est utilisé par aucune connexion. Ceci implique que la réalisation de cetteopération n’a aucun impact sur le reste de l’architecture. Dans le cas où ce dernierest utilisé par un ou plusieurs connecteurs, ceci se traduit par un marquage a prioride ces connecteurs.Au niveau du code source, ceci se traduit par la suppression d’un paramètre de lafonction ou la méthode associée au composant concerné par l’opération, en l’occur-rence ici, le composant “A”.

5.2.9 Ajout d’une propriété

L’opération “ajout_prop(a, p)” consiste à ajouter une propriété ASCM “p” à uncomposant “a”. La pré-condition de cette opération stipule que soit la propriétén’existe pas dans l’architecture ; soit la propriété existe mais est attribuée à un autrecomposant que “a”. En effet, une même propriété peut être attribuée à plusieurs com-posants. Dans ce cas, un nœud correspondant est créé autant de fois que la propriétéest attribuée aux composants. Le résultat de cette opération est l’intégration d’unenouvelle propriété ASCM “p” représentée sur le graphe par un nœud et un arc detype “hasProp” le reliant au composant “a”. L’existence du composant “a” doit êtrevérifiée avant et après l’exécution de l’opération.

La figure 5.11 illustre l’opération d’ajout d’une propriété “Period=200 Ms” attri-buée à “P.Impl”. Afin que l’exécution de cette opération soit possible, il faut que lapropriété ajoutée soit compatible avec le type de composant. Cette vérification est


Fig. 5.11 – Ajouter une propriété à un composant

faite dans la grammaire du langage architectural utilisé. Par exemple, la propriété“dispatch_protocol” qui indique la politique de déclenchement pour les composantsde type threads ne peut pas être associée aux composants de type processus, systèmes,sous-programmes ou données. Le résultat obtenu suite à l’ajout de cette opération estl’intégration d’un nouveau nœud Period = 200Ms correspondant à la propriété ainsiqu’un nouvel arc reliant ce nœud à “P.Impl”.

L’ajout d’une propriété n’a aucun impact sur le reste de l’architecture tandis quesur le code source ceci se traduit par l’ajout d’une variable ou d’une suite d’instruc-tions correspondante à la propriété.

5.2.10 Suppression d’une propriété

Fig. 5.12 – Supprimer une propriété d’un composant

L’opération “supp_prop(a,p)” permet de supprimer une propriété “p” associéeà un composant (interface ou implémentation) “a”. Les pré-conditions à vérifierstipulent que (1) la propriété “p” doit être présente dans l’architecture et doncreprésentée dans le graphe par un nœud, (2) cette propriété doit être attribuée aucomposant “a” et donc un arc existe dans le graphe reliant le nœud correspondant


à la propriété à celui correspondant au composant. Le résultat de cette opération estla suppression de la propriété dans l’architecture et par la suite, de son nœud cor-respondant dans le graphe. L’arc reliant la propriété à son composant est égalementsupprimé. L’existence du composant “a” doit être vérifiée avant et après l’exécutionde l’opération.La figure 5.12 montre la suppression d’une propriété “Dispatch_Protocol => Periodic”associée à “P.Impl”. Le nœud correspondant à cette propriété dans le graphe serasupprimé ainsi que l’arc le reliant à “P.Impl”.

La suppression d’une propriété n’a aucun effet sur l’architecture tandis que sur lecode source, elle a comme impact de supprimer la variable ou la suite d’instructionsassociée à la propriété.

5.2.11 Changement de la valeur d’une propriété

Fig. 5.13 – Modifier une propriété d’un composant

L’opération “changer_prop(a,p,v)” permet d’attribuer une nouvelle valeur “v” àla propriété “p” du composant (interface ou implémentation) “a”. Cette opérationpeut être décrite comme étant une suppression de la propriété pour ensuite la créeren lui assignant la nouvelle valeur. Afin que l’exécution de cette opération soitpossible, le composant “a” doit exister avant et après l’exécution de l’opération. Lapropriété “p” doit être aussi présente dans l’architecture avant et après l’opération.Cependant, après l’exécution de l’opération la propriété existe mais avec la nouvellevaleur “v”. Cette nouvelle valeur doit être compatible avec les types de valeurs quepeut avoir la propriété. Par exemple, la propriété “Dispatch_protocol” peut prendreune valeur parmi l’ensemble suivant : Periodic, Aperiodic, Sporadic ou Background.L’ensemble des valeurs est défini dans la grammaire du langage de descriptionarchitectural utilisé.La figure 5.13 illustre le résultat obtenu suite à la réalisation de l’opération du chan-gement de la valeur de la propriété “Dispatch_Protocol” en lui attribuant la valeur


“Aperiodic” au lieu de “Periodic”. En effet, l’étape intermédiaire consiste à supprimerla propriété et par conséquent son nœud correspondant ainsi que l’arc le reliantau nœud correspondant à“P.Impl”. Un nouveau nœud associé à la propriété “Dis-patch_Protocol” est ajouté avec un arc le reliant au nœud correspondant à “P.Impl”.

Cette opération n’a aucun impact sur l’architecture tandis que sur le code source,l’impact de cette opération est la modification de la variable ou la suite d’instructionsqui correspond à la propriété.

5.2.12 Ajout d’un sous-composant

Fig. 5.14 – Ajouter un sous-composant à un composant

L’opération “ajouter_sous_comp(a,s,t)” consiste à ajouter un sous-composant “s”de type “t” à un composant “a”. La pré-condition de cette opération stipule quesoit le sous-composant n’existe pas dans l’architecture ; soit le sous-composant existemais est attribué à un autre composant que “a” (+s ∧−arc(e, a, s)). Les invariants decette opération indiquent que l’existence des composants “a” et “t” doit être vérifiéeavant et après l’exécution de l’opération. Le résultat de cette opération est l’ajoutd’un nouveau sous-composant et par conséquent l’ajout d’un nœud correspondant


dans le graphe représentant l’architecture. Un arc reliant ce nœud à celui associé aucomposant “a” est également ajouté. Cet arc est de type “hasSubComp” désignantune relation de composition.La figure 5.14 illustre cette opération. Elle consiste à ajouter à “A.Impl” le sous-composant “Producer” de type “P.Impl”. Ceci se traduit sur le graphe par l’ajoutd’un nœud correspondant à ce sous-composant ainsi qu’un premier arc le reliantau nœud associé à “A.Impl” et un deuxième, le reliant au nœud représentant soncomposant type “P.Impl”.L’ajout des sous-composants à un composant doit être suivi par l’ajout d’un ou deplusieurs connecteurs afin de définir les relations entre ces sous-composants.

Afin que cette opération soit possible, il est indispensable de respecter lesrègles de composition spécifiées pour chaque ADL. Par exemple, dans AADL uncomposant de type “processus” ne peut pas contenir d’autres composants de mêmetype ; il peut contenir des sous-composants de type “thread” ou “groupe de threads”.

L’ajout d’un sous-composant n’a aucun effet sur l’architecture étant donné qu’au-cune connexion utilise les ports de ce sous-composant. Sur le code source, cette mo-dification a comme effet l’ajout d’une nouvelle relation d’appel entre la méthodeou la fonction associée au composant (dans l’exemple “A.Impl”) et celle associée aucomposant type du sous-composant ajouté (en l’occurrence “P.Impl“).

5.2.13 Suppression d’un sous-composant

Fig. 5.15 – Supprimer un sous-composant

L’opération ”supp_sous_comp(a,s)“ permet de supprimer un sous-composant ”s“d’un composant ”a“. Afin que cette opération soit réalisable, les pré-conditions sti-


pulent que l’existence de ce sous-composant doit être vérifiée et qu’un arc dési-gnant une relation de composition ”hasSubComp“ relie le nœud associé à ce sous-composant à celui associé au composant ”a“. Les invariants de cette opération, à vé-rifier avant et après l’opération, indiquent l’existence du composant ”a“ et qu’aucunconnecteur n’utilise les ports définis dans ce sous-composant (−connSousComp(∗, s)).Le résultat de cette opération est la suppression du sous-composant et par conséquentdu nœud associé dans le graphe représentant l’architecture ainsi que la suppressionde ses arcs entrants et sortants.

La figure 5.15 illustre la suppression du sous-composant “Producer” définie dans“A.Impl”. Elle se traduit sur le graphe par la suppression du nœud correspondantainsi que des arcs le reliant aux nœuds “P.Impl” et “A.Impl”.

La suppression d’un sous-composant n’a pas d’effet sur le reste de l’architecturedans le cas où celui-ci n’est utilisé par aucun connecteur. Dans le cas où il est utilisépar un ou plusieurs connecteurs ces derniers sont affectés par cette suppression. Surle code source correspondant à l’architecture, cette suppression implique la suppres-sion de la relation d’appel entre la méthode ou la fonction associée au composant(dans l’exemple, “A.Impl”) et celle associée au type du sous-composant supprimé(dans l’exemple, “P.Impl”).

5.2.14 Changement du type de port de connexion

Fig. 5.16 – Changer le type d’un port de connexion

Les ADLs définissent des types pour les ports de connexion. À titre d’exemple, lelangage AADL propose trois types de ports : data (pour la transmission de donnéesentre les composants), event (pour la communication des événements entre les com-posants) ou event data (pour la transmission de messages, c’est-à-dire des signauxtransportant des données).L’opération “changer_type_port(a,p,t)” a pour but de modifier le type d’un port “p”du composant “a” en lui attribuant le nouveau type “t”. Les invariants à vérifier pourpermettre la réalisation de cette opération sont : (1) l’existence du composant “a” etdu port “p” et par conséquent de deux nœuds correspondants, (2) l’existence d’unarc de type “hasPort” entre “a” et son port “p” et enfin (3) aucun arc de type “use-PortSrc” ou de type “usePortDst” ne doit utiliser le port “p” c’est-à-dire qu’il n’existe

5.3. Processus de propagation d’impact 97

aucun connecteur utilisant le port “p”. Le résultat de cette opération consiste à attri-buer le nouveau type “t” au port “p”. En d’autres termes, cette opération consiste àsupprimer le port existant et à le créer de nouveau avec le nouveau type “t”.

La figure 5.16 illustre l’opération de modification du type du port “Beta”. Cedernier aura le type “event data” suite à la réalisation de cette opération. Dans lapartie (3) de la figure, nous montrons le résultat de cette opération. En effet, dansune étape intermédiaire, le nœud associé au port “Beta” est supprimé ainsi que l’arcle reliant au nœud associé au composant “A”. Par la suite, un nouveau nœud associéà ce port (avec le nouveau type) ainsi qu’un arc le reliant au nœud associé à “A” sontajoutés dans le graphe.

La modification du type d’un port de connexion n’a aucun effet sur le reste del’architecture dans le cas où ce dernier n’est utilisé par aucune connexion. Cette mo-dification affectera le code source correspondant en changeant le type du paramètreassocié au port modifié. Si un port est utilisé par une ou plusieurs connexions, cesdernières seront marquées a priori ainsi que les arcs les reliant au port modifié.

Nous avons défini ci-dessus les opérations de modification applicables sur la des-cription architecturale. Celles-ci peuvent présenter un impact sur les autres consti-tuants de l’architecture ainsi que sur le code source qui les implémente. Nous propo-sons, dans ce qui suit, un processus de propagation d’impact basé sur cette topologied’opérations de modifications.

5.3 Processus de propagation d’impact

L’évolution d’une architecture est explicitement traduite par des changementsréalisés au niveau des différents éléments du modèle ASCM et par conséquent sur legraphe d’architecture associé.Lorsqu’un changement affecte l’architecture, le modèle architectural original doitêtre mis à jour afin de prendre en considération les modifications apportées. Eneffet, une dégénération architecturale peut conduire à de nombreux écarts entre laconception d’origine et la qualité des services actuellement fournis par l’application.Cette situation peut mettre les développeurs dans une situation confuse et conduit àun effort important de réorganisation ou au retrait anticipé du système [HL05].

Les approches pour la propagation d’impact se divisent en deux catégories : lesapproches algorithmiques et celles à base de règles.

5.3.1 Approches algorithmiques pour la propagation d’impact

Des approches algorithmiques pour l’analyse de l’impact de modification ont étéproposées dans la littérature [LO96, Raj97b]. La plupart de ces approches se basentsur la ré-écriture de graphes afin de déterminer les effets de bord d’une modifica-

98 5.3. Processus de propagation d’impact

tion. Ces approches effectuent une analyse locale de l’impact de chaque composant,puis propagent l’impact à travers les relations vers les autres composants d’une ap-plication. Nous avons recensé plusieurs problèmes qui découlent de ces approchesalgorithmiques :

– Les nœuds du graphe peuvent être visités plusieurs fois provoquant une récur-sivité infinie dans le cas où des cycles sont présents dans le graphe.

– Il n’est pas possible d’effectuer une analyse partielle de l’impact de modifica-tions. Ce type d’analyse est utilisé pour étudier les effets d’une modificationsur un ensemble partiel de nœuds et d’arcs du graphe.

– Le mainteneur est le seul à pouvoir choisir les nœuds à visiter. En effet, l’impactdu changement d’un nœud est propagé à tous ses voisins et seul le mainteneurest capable de décider quels nœuds sont réellement affectés.

5.3.2 Approches basées sur les règles

Sadou et al. présentent dans [STO06] une approche basée sur des règles pourl’évolution des architectures logicielles en utilisant le formalisme ECA (Évenement- Condition - Action). Une règle d’évolution décrit l’exécution d’une opérationd’évolution en précisant son événement déclencheur, les conditions à satisfaire, leschangements à réaliser sur l’élément architectural concerné ainsi que la propagationd’impacts.

Notre approche s’appuie sur le formalisme ECA, en particulier pour déclencherles règles de propagation d’impact [HDB09]. Elle consiste à analyser l’impact auniveau architectural en définissant des règles génériques pouvant s’appliquer indé-pendamment des langages de description d’architecture puis de propager l’impactde la modification du niveau architectural vers son code source correspondant.L’intérêt d’utiliser une approche à base de règles réside dans la séparation de la partiefonctionnelle d’une application de celle gérant son évolution. Les règles d’évolutionet le code applicatif sont spécifiés séparément. Ces règles sont rédigées par des ex-perts du domaine et peuvent être modifiées pendant le processus de propagationd’impact. Pour répondre aux problèmes posés par les approches algorithmiques, lesrègles sont manipulées par un système expert.

5.3.3 Définition d’un système expert (SE)

Les recherches en intelligence artificielle découlent du besoin de développer desprogrammes capables de résoudre des problèmes d’une manière considérée commeintelligente, c’est-à-dire de manière semblable à celle utilisée par les hommes. Ledéveloppement des systèmes experts correspond à une des premières applicationsopérationnelles du domaine d’intelligence artificielle. Ce champ de l’intelligenceartificielle se concentre sur la construction des systèmes capables de reproduire le


comportement de l’être humain dans ses activités de raisonnement. Un SE peut êtredéfini de la manière suivante [Bul90] :Un système expert est un système logiciel informatique qui est capable de donnersur un sujet particulier un conseil égal en qualité à celui qui pourrait être donnépar un expert humain reconnu.

Les SE ont la capacité d’explication et de justification de solutions ou des recom-mandations qui aident l’utilisateur à juger si son raisonnement est correct [Jac98].

Généralement, les SE sont appliqués de deux façons différentes :– pour l’aide à la décision, en fournissant des informations ou options à un utili-

sateur expérimenté.– Pour la prise de décision, en permettant à une personne non qualifiée de

prendre une décision au-delà de son niveau de formation ou d’expertise.

Notre approche basée sur l’utilisation d’un système expert est utilisée pour l’aideà la décision. En effet, les règles de propagation permettront à l’utilisateur de déter-miner les endroits affectés par la modification et par conséquent, de pouvoir estimerl’effort nécessaire à la réalisation de la modification.

Notre système expert est constitué de trois composants principaux : la base defaits, la base de règles et le moteur d’inférence. La base de faits constitue la mé-moire de travail du système à base de connaissances. Elle contient l’ensemble desfaits permettant de déclencher les règles d’analyse d’impact. Il s’agit de la partie dy-namique de la base de connaissances. Les faits représentent les nœuds et les arcs dugraphe associés aux éléments architecturaux représentés par le modèle ASCM. Ceux-ci sont ajoutés à la base de faits lors de la construction du graphe d’architecture et ilspeuvent êtres modifiés au fur et à mesure par le moteur d’inférence en déclenchantdes règles sur ces faits. Les règles permettent l’ajout, la modification ou le retrait d’unou plusieurs faits. Au niveau du graphe d’architecture, les règles se traduisent par :

– L’ajout des nœuds ou des arcs pouvant être effectué dans le cadre de l’évolutionde l’architecture, par exemple, des règles peuvent ajouter un composant, unconnecteur ou un port. Ces règles sont également utilisées afin de compléterla construction du graphe d’architecture en déduisant certaines relations tellesque la relation entre un connecteur et les ports qu’il utilise ou bien la relationentre une interface d’un composant et son implémentation.

– La suppression des nœuds ou des arcs dans le but de faire évoluer l’archi-tecture, par exemple, une règle peut supprimer une propriété ou un sous-composant.

– La modification des attributs des nœuds survient suite à des opérations d’évo-lution effectuées sur les éléments architecturaux tels que la modification dutype d’un connecteur ou la modification de la valeur d’une propriété.


De manière simplifié, le moteur d’inférence applique à la base de faits toutes lesrègles non marquées. Une règle peut être marquée comme ayant été déclenchée ounon ; Initialement, toutes les règles sont non marquées. L’application des règles per-met d’obtenir une nouvelle base de faits mise à jour avec les nouvelles contraintesintroduites. Les règles non marquées et déclenchées par le moteur d’inférence, pourmodifier effectivement la base de faits, deviennent ainsi marquées.

5.3.4 Règles de propagation d’impact

Ces règles décrivent l’exécution des opérations d’évolution sur les éléments archi-tecturaux du modèle ASCM. Elles permettent de modifier la base de faits en exécu-tant les opérations de modifications sur ces éléments. Le déclenchement du processusde propagation se traduit par l’insertion d’un événement (ex : ajouter un composant,supprimer un port). Des règles de modification sont associées à chaque opération demodification. La prémisse de la règle représente une liste de faits devant être vérifiéeafin d’exécuter la règle associée à l’opération de modification. Un exemple de faitsà vérifier dans le cas de la suppression d’un composant “C” est l’absence de toutsous-composant ayant le type “C”. Cette prémisse est donnée sous la forme d’unepré-condition et d’un invariant à respecter avant l’opération. Le résultat de la règleest une liste d’actions à opérer. Celle-ci est donnée sous la forme d’une post-conditionet d’un invariant. Le non respect de la prémisse de la règle implique que l’opérationdécrite par la règle ne peut pas être exécutée. Plusieurs cas de figures se présentent :

1. si la pré-condition et l’invariant sont vérifiés alors l’opération sera exécutée sansengendrer une propagation d’impact sur le reste de l’architecture.

2. Si la pré-condition n’est pas vérifiée, l’opération n’est pas réalisée et il n’y a pasd’impacts sur le graphe. Cela correspond à des opérations interdites commevouloir ajouter un composant qui existe déjà.

3. Si la pré-condition est vérifiée mais au moins un des invariants ne l’est pas alorsl’opération est exécutée et il y a un processus de propagation d’impact. En effet,l’invariant de la règle peut à son tour déclencher le marquage des élémentsconcernés. Ce cas est le plus répandu et le plus intéressant pour le processusde propagation d’impact. Supprimer un composant qui a des sous-composantsou supprimer un port utilisé par un connecteur sont des exemples illustrant cecas de figure.

Dans ce qui suit, nous explicitons la façon dont les invariants d’une opération“Op” peuvent engendrer un impact sur le reste de l’architecture. Ces invariants sontdivisés en deux catégories :

1. la première catégorie regroupe les invariants vérifiant l’existence d’un élémentdans l’architecture et par conséquent un nœud ou un arc dans le graphe, notée+invariant.


2. La seconde catégorie concerne les invariants vérifiant la non existence d’unnœud ou d’un arc dans le graphe, notée −invariant. Ces invariants déclenchentle marquage des éléments qu’ils utilisent. Citons, par exemple, l’invariant“−sousComposant(∗, cimp)” de l’opération de suppression d’une implémenta-tion d’un composant “cimp”. Celui-ci va déclencher le marquage de tous lessous-composants de “cimp”.

Le marquage des éléments affectés par la modification dépend de la nature de larelation qui les relie. Il consiste à indiquer que l’élément marqué est affecté par l’opé-ration de modification réalisée. Une modification apportée sur un élément de l’archi-tecture est répercutée sur son graphe selon un processus de propagation. La propa-gation d’impact entre un nœud du graphe et son voisinage dépend de la nature desrelations entrantes et sortantes de ce nœud ainsi que de l’opération appliquée sur lenœud. Nous définissons l’assertion conductrice indiquant qu’une relation e : A −→ Best conductrice d’impact pour une opération op. L’assertion +conductrice(op, e, A, B)indique que l’arc ou la relation e est conductrice d’impact de A vers B après la réalisa-tion de l’opération op. Citons, par exemple, la relation “hasSubComp” entre un com-posant “A” et un sous-composant “B” qui propage l’impact de modification dans lesdeux sens de la relation après l’exécution d’une opération de suppression : si “A” estsupprimé, “B” sera affecté par cette suppression et inversement. La relation “hasSub-Comp” est dite conductrice de l’impact dans les deux sens de la relation pour l’opé-ration de suppression. Tandis que pour la même relation, l’exécution d’une opérationde modification telle que l’ajout d’un port à “A” n’affecte pas le sous-composant “B”.

Assertion Significationmarquer(el) ∀el ∈ E ∨ el ∈ N, etat(el) =affectémarquer(v, op) ∀e ∈ E, v1 ∈ N : ((+arc(e, v, v1) ∨ +arc(e, v1v)) ∧ +conductrice(op, e, v, v1))

−→ marquer(e) ∧ marquer(v1)marquer(source(t∗, v), op) ∀e ∈ E, v1 ∈ N : (type(e) = t ∧ +arc(e, v, v1) ∧ +conductrice(op, e, v, v1))

−→ marquer(e) ∧ marquer(v1)marquer(destination(t∗, v), op) ∀e ∈ E, v1 ∈ N : (type(e) = t ∧ +arc(e, v1, v) ∧ +conductrice(op, e, v, v1))

−→ marquer(e) ∧ marquer(v1)

Tab. 5.2 – Liste des assertions

L’assertion marquer(el), définie dans le tableau 5.2, consiste à marquer un nœudou un arc comme étant affecté par une opération de modification.L’assertion marquer(v, op) précise que suite à la modification de v par une opérationop, les arcs entrants et sortants de v seront marqués et propagent l’impact vers leurcomposant source et destination selon la nature de relation que l’arc représente et lesens de la conductivité d’impact pour l’opération exécutée.L’assertion marquer(source(t∗, v, op)) consiste, suite à la modification de v par l’opé-ration op, à marquer toute relation e de type t ayant le nœud v comme nœud sourceainsi qu’à marquer le nœud destination de cette relation si celle-ci est conductrice


d’impact pour l’opération réalisée.L’assertion marquer(destination(t∗, v)) consiste, suite à la modification de v parl’opération op, à marquer toute relation e de type t ayant le nœud v comme nœuddestination ainsi qu’à marquer le nœud source de cette relation si celle-ci est conduc-trice d’impact pour l’opération réalisée.

Le processus de marquage des nœuds et de propagation s’arrête lorsque toutesles règles ont été déclenchées et qu’il n’existe plus aucun fait candidat. Après avoirdéfini dans la section 5.2, les opérations de modification architecturale pouvants’appliquer sur les différents éléments du modèle ASCM, nous définissons troisrègles génériques pour la réalisation de ces opérations de modification et pour lapropagation d’impact.

Regle_Declencher_Operation(Op, el){TRUE(Op.Pre− Condition) ∧ TRUE(Op.Invariant)−→ Op.Post− Condition

}

Regle_Impact_Operation(Op, el){TRUE(Op.Pre− Condition) ∧ FALSE(Op.Invariant)−→ marquer(el)

}

Regle_Propager_Impact(Op, el){+ etat(el,′affecté′)−→ marquer(el, op)

}

La première règle consiste à déclencher une opération de modification op sur unélément architectural el dans le cas où les pré-conditions et les invariants de l’opé-ration sont vérifiés. Par conséquent, les propositions données dans la post-conditionde l’opération sont exécutées. Dans ce cas, il n’y a pas de processus de propagationd’impact.Dans le cas où la pré-condition est vérifiée tandis qu’au moins un invariant est violé,la deuxième règle est déclenchée et celle-ci considère que l’élément el du modèleASCM passe dans un état affecté.La troisième règle déclenche la propagation d’impact dans le cas où un élément elest affecté par une opération de modification ayant violé des invariants. Cette règles’applique à l’ensemble des nœuds, dans l’état affecté, de la base de connaissances.Pour chaque nœud, l’assertion de marquage consistera à visiter chaque relationsource et destination, conductrice d’impact, afin de la marquer comme étant affectéepar l’opération. La base de connaissances est alors à nouveau modifiée, déclenchant


ainsi la règle jusqu’à ce que toutes les relations conductrices d’impact soient traitées.

Les règles, précédemment définies, sont génériques et s’appliquent, sans au-cune contrainte, sur toutes les relations du modèle ASCM. Or, dans certains cas,les chargés de maintenance cherchent à obtenir l’impact d’une modification en neconsidérant qu’un certain type de relation ou de composant. Ces règles peuvent êtrespécialisées permettant ainsi de ne prendre en compte que certaines relations tellesque la relation “aSousComp”, définie entre un composant et une instance d’un autrecomposant ou bien la relation “possèdePort”, définie entre une interface d’un com-posant et ses ports. Il est également possible d’étudier l’impact d’une modificationuniquement sur certains éléments du modèle tels que les instances des composantsou les connexions.Les règles spécialisées permettent également d’ajouter des conditions particulièresliées à un ADL particulier.

Nous proposons un algorithme appelé Architectural Change Propagation Process,permettant d’appliquer une opération de modification sur un nœud d’un graphed’architecture G. L’algorithme déclenche les opérations de modification présentéesci-dessus et si besoin, propage l’impact de la modification et par conséquent marqueles nœuds et les arcs du graphe affectés par la modification. L’algorithme Architectu-ral Change Propagation Process est le suivant :

Soit un graphe G d’une description architecturale A//Choix d’un nœud du graphe

sélectionner v ∈ N//Appliquer sur v une opération de modification parmi la liste des opérations définies OP

sélectionner op ∈ OP//Déclencher la règle de propagation associée à l’opération et au nœud modifié

Regle_Impact_Operation(op, v)

L’algorithme Architectural Change Propagation Process apporte une solution auxproblèmes de récursivité infinie puisque la règle de propagation ne peut pas êtredéclenchée plus d’une fois pour le même ensemble de faits. Il est également possibled’effectuer une analyse d’impact partielle du graphe d’architecture. Ceci est possiblepar le biais des règles spécialisées qui permettent d’étudier les effets d’une modifica-tion sur un ensemble partiel de nœuds et d’arcs du graphe.

5.3.5 Propagation d’impact de l’architecture vers le code source

Les modèles ASCM et SCSM sont formalisés par des graphes dont les types derelations diffèrent. Les règles de propagation d’impact sont différentes selon qu’elles


sont destinées à l’architecture ou au code source. Chaque élément du modèle ASCMest projeté vers un ou plusieurs éléments du modèle SCSM. La relation de projectionétablie entre les deux modèles permet de propager l’impact entre le niveau architec-tural et le code source du logiciel et inversement.À titre d’exemple, une opération de modification réalisée sur un nœud du graphereprésentant l’architecture est propagée sur les autres nœuds de l’architecture lors-qu’une relation existe entre eux mais également vers les éléments du code sourcelorsqu’une relation de projection existe. Dans ce cas, le moteur d’inférence propagel’impact sur l’élément cible de la relation de projection. Le nœud du modèle SCSMest alors marqué selon la règle de propagation d’impact. Ce marquage permet dedéclencher des règles génériques et spécifiques sur les éléments du code source dulogiciel afin de propager l’impact.

5.3.6 Illustration du processus de propagation d’impact

Listing 5.1 – Exemple d’une représentation AADL� �1 thread P2 features3 Data_Source : out data port Alpha_Type;4 end P;5 thread implementation P.Impl6 calls {7 P_Spg : subprogram Produce_Spg;8 };9 connections

10 C : parameter P_Spg.Data_Source −> Data_Source;11 properties12 Dispatch_Protocol => Periodic;13 Period => 200 Ms;14 end P.Impl;15 subprogram Produce_Spg16 features17 Data_Source : out parameter Alpha_Type;18 properties19 source_language => Ada95;20 source_name => "Producer_Consumer.Produce_Spg";21 end Produce_Spg;� �

Nous proposons d’éclaircir le fonctionnement du processus de propagation d’impactsur un exemple. Le listing 5.1 montre une partie de la description architecturaled’une application “Producteur - Consommateur” spécifiée avec le langage AADL.Cette description définit un thread “P” ayant un port “Data_Source”. Une implémen-tation, “P.Impl”, est définie pour ce thread. Cette implémentation appelle “P_Spg”qui est une instance du sous-programme “Produce_Spg”. Une connexion est définiepermettant d’établir cette relation d’appel. Le sous-programme “Produce_Spg” pos-sède un paramètre “Data_Source” (l’équivalent d’un port pour un thread).

La figure 5.17 montre le graphe correspondant à cette description avantla réalisation d’une opération de modification (partie A de la figure) et celuiaprès l’exécution de l’opération (partie B de la figure). Nous appliquons l’opé-


Fig. 5.17 – Exemple de processus de propagation d’impact en appliquant notre algorithme

ration supp_comp_int(Produce_Spg) qui consiste à supprimer l’interface du sous-programme “Produce_Spg”. Le déclenchement des règles appropriées suite à l’exé-cution de l’opération se déroule de la manière suivante :

1. la Pré-condition, notée +a, est respectée : le sous-programme à supprimer,Produce_Spg, existe dans le graphe.

2. L’invariant −sousComp(∗, a) n’est pas respecté : il existe une instanceP_Spg de type Produce_Spg, définie dans P.Impl. Par conséquent, la règleRegle_Impact_Operation est déclenchée.

3. Le déclenchement de cette règle marque le nœud associé à Produce_Spg commeétant dans un état affecté.

4. Lorsque le moteur d’inférence rencontre l’état affecté pour un nœud faisant par-tie de la base de faits, il déclenche la règle Regle_Propager_Impact pour mar-quer les nœuds voisins à Produce_Spg selon le type des relations qui les relient.Par conséquent et en considérant le voisinage proche de Produce_Spg :– la relation aProp est conductrice d’impact de Produce_Spg vers source_name

et source_language pour l’opération de suppression : les nœudssource_language et source_name sont marqués ainsi que les arcs les reliant àProduce_Spg,

– la relation aType est conductrice d’impact de Produce_Spg vers P_Spg pourl’opération de suppression : le nœud P_Spg et l’arc le reliant à Produce_Spgsont marqués,


– la relation possedePort est conductrice d’impact de Produce_Spg versData_Source : le nœud Data_Source et l’arc le reliant à Produce_Spg sontmarqués.

La base de connaissances a évolué suite au déclenchement successifs de la règleRegle_Propager_Impact : de nouveaux arcs et nœuds sont marqués dans unétat affecté. Ceci a pour conséquence de déclencher à nouveau la règle pour cenouvel ensemble de faits. Le moteur d’inférence propage l’impact de la modi-fication en marquant les arcs et les nœuds liés aux faits modifiés de la manièresuivante :– la relation d’appel est conductrice d’impact de P_Spg vers P.Impl : le nœud

P.Impl ainsi que l’arc le reliant à P_Spg sont marqués,– la relation PortDst est conductrice d’impact de Data_Source vers C, ainsi le

nœud C et l’arc le reliant à Data_Source sont marqués.

Le processus est réitéré pour ce nouvel ensemble de faits.

La figure 5.18 montre le graphe incluant la description architecturale ainsique son code source correspondant. Nous montrons l’impact de l’opérationsupp_comp_int(Produce_Spg) sur le code source correspondant à la descriptionarchitecturale. Le processus de propagation d’impact a été déclenché sur le niveauarchitectural suite à l’application de l’opération. Une relation de projection établit lelien entre ce niveau et le code source. Grâce à cette relation, le moteur d’inférencepropage l’impact vers l’élément du code source Procedure. Celui-ci est ainsi marquépar l’opération. Ce marquage permet de déclencher les règles propres au modèleSCSM afin de propager l’impact sur ce niveau de représentation. Par conséquent eten considérant le voisinage proche de Procedure :

– la relation aSignature est conductrice d’impact de Procedure vers le nœudsSignature pour l’opération de suppression : ce nœud est marqué ainsi que l’arcle reliant à Procedure.

– la relation aCorps est conductrice d’impact de Procedure vers le nœud Corpspour l’opération de suppression : ce nœud est marqué ainsi que l’arc le reliantà Procedure.

– La base de connaissances a changé suite au déclenchement successifs de la règleRegle_Propager_Impact. Ceci a pour conséquence de déclencher à nouveau larègle pour ce nouvel ensemble de faits. Le moteur d’inférence propage l’impactde la modification en marquant les arcs et les nœuds liés aux faits modifiés dela manière suivante :– la relation aParamètre est conductrice d’impact de Signature vers Paramètre

Data_Source : ce nœud ainsi que l’arc le reliant à Signature sont marqués,– la relation aInstructions est conductrice d’impact de Corps vers les nœuds

représentant les instructions Inst1 et InstN, par conséquent ces nœuds ainsi

5.4. Conclusion 107

que les arcs les reliant à Corps sont marqués.

– Le processus est ensuite réitéré pour ce nouvel ensemble de faits.

Fig. 5.18 – Intégration du code source dans le processus de propagation d’impact

5.4 Conclusion

Nous avons présenté, dans ce chapitre, une classification des opérations de mo-dification de graphes appliquées sur les architectures logicielles. Nous avons définices opérations à l’aide du formalisme d’assertion en spécifiant des pré-conditions,des post-conditions et des invariants. Nous avons illustré chacune de ces opérationspar un exemple issu d’une description architecturale spécifiée avec le langage AADL.Nous avons également étudié l’impact de ces opérations sur la description architec-turale et sur le code source correspondant.La réalisation d’une opération de modification sur un élément d’une description ar-chitecturale peut présenter un impact sur le reste de l’architecture et sur le codesource correspondant, dans le cas où au moins un des invariants de cette opérationest violé. Sur ce constat, nous avons proposé un processus de propagation d’impact,basé sur la topologie d’opérations préalablement présentées.

108 5.4. Conclusion

De nombreuses approches algorithmiques sont proposées dans la littérature pour lapropagation d’impact. Cependant, certaines lacunes découlent de ces approches, no-tamment en matière de récursivité et de rigidité. Sur ce constat, nous avons proposéun processus de propagation d’impact à base de connaissances. La mise en œuvred’un tel processus offre une meilleure extensibilité à notre approche et évite les pro-blèmes de récursivité trouvés dans les approches algorithmiques pour la propagationd’impact.

Nous avons défini trois règles génériques dans notre processus de propagationd’impact. La première règle consiste à valider l’opération de modification dans lecas où ses post-conditions et ses invariants sont respectés. La seconde est déclenchéelorsque l’un des invariants de l’opération est violé et consiste à changer l’état del’élément, sur lequel l’opération de modification est effectuée. Ce changement d’étatdéclenchera la troisième règle qui consiste à marquer les nœuds et les arcs affectéspar cette modification selon leur relation avec l’élément affecté.

Nous avons également montré la manière dont se propage l’impact de l’archi-tecture vers le code source. En effet, lorsqu’une relation de projection existe entreun élément du modèle ASCM et un autre du modèle SCSM, le moteur d’inférencepropage l’impact sur l’élément du modèle SCSM. Cet élément devient alors marquéet par conséquent les règles, définies sur les éléments du code source du logiciel,sont déclenchées afin de propager l’impact sur ce niveau de représentation.

Dans le chapitre suivant, nous présentons l’architecture du système que nousavons mis en œuvre pour valider notre approche pour la représentation des archi-tectures logicielles, la gestion de son évolution et de la propagation de l’impact demodification.

6Implémentation

Sommaire

6.1 Présentation de la plate-forme Eclipse . . . . . . . . . . . . . . . . . . 111

6.2 Architecture du système . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

6.2.1 L’analyseur de codes sources et de descriptions d’architectures multi-langages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

6.2.2 Le modeleur logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

6.2.3 Le système expert DROOLS . . . . . . . . . . . . . . . . . . . . . . . . . 114

6.2.4 Interface utilisateur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

6.3 Scénario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

6.4 Analyse d’impact inter-modèles . . . . . . . . . . . . . . . . . . . . . . . . 129

6.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

6.1. Présentation de la plate-forme Eclipse 111

Dans ce chapitre, nous présentons l’architecture du système qui implémente lesmodèles SCSM et ASCM ainsi que le processus de propagation d’impact des

modifications. Nous proposons une implémentation basée sur l’environnement dedéveloppement intégré Eclipse en fournissant des plugins permettant l’extensionde ses fonctionnalités. Dans l’environnement Eclipse, les modèles ASCM et SCSMfournissent une représentation sous forme de graphes de chaque fichier d’un projetEclipse, concernant respectivement son architecture et ses codes sources. Ces graphespermettent une représentation des relations existantes entre les composants archi-tecturaux qui sont projetés vers un code source qui implémente la description ar-chitecturale. Ces relations permettent la propagation des impacts de modificationseffectuées sur les éléments du graphe. Le processus de propagation est déclenchélors de l’application d’une modification sur un élément du graphe puis par l’exécu-tion des règles formelles définies dans un système expert. Une interface graphiquepermet la visualisation des graphes, l’exécution des opérations de modification et lavisualisation de leurs impacts.

6.1 Présentation de la plate-forme Eclipse

Le projet Eclipse1 a été conçu à la fin des années 1990 par IBM2 avec l’objectifd’uniformiser les plates-formes de développement utilisées au sein de la compagnie.En 2001, IBM a ouvert le code source de la plate-forme, qui est aujourd’hui dispo-nible en open source et est géré par la Fondation Eclipse, créée en 2004. Le but initialdu projet Eclipse était de fournir un socle, écrit en Java, pour la création d’environ-nements de développement. Depuis, cet objectif a été étendu pour pouvoir créer toustypes d’applications à partir du cœur de la plate-forme.

Eclipse est un Environnement de Développement Intégré (IDE) extensible dansle sens où il a été conçu avec l’objectif de pouvoir être facilement étendu par desoutils tiers. Eclipse propose un mécanisme d’extension basé sur le développement deplugins pour permettre de lui injecter de nouvelles fonctionnalités.

Parmi les environnements existants, plusieurs éléments nous ont amené à choisirla plate-forme Eclipse. Eclipse est une plate-forme open source extensible, basée surune architecture d’intégration puissante et très intéressante. Cette plate-forme est enplein essor et connaît un succès considérable dans la communauté des développeurs[Got05]. Du fait qu’Eclipse est très répandue et largement utilisé, nous avons à notredisposition un public potentiel d’utilisateurs susceptibles de mettre à l’épreuve notreapproche dans le cadre de projets réels.

De nombreuses contributions de l’équipe ModEL se sont intégrés dans la plate-forme Eclipse tendant, d’une part, à fournir un support global et évolutif à la co-opération dans les activités de développement logiciel [Lew06], et d’autre part, à

1Le projet Eclipse, http ://www.eclipse.org2IBM, International Business Machines Corp., http ://www.ibm.com

112 6.2. Architecture du système

représenter les codes sources des logiciels multi-languages ainsi que leurs évolutions[Der01]. Le système IFSEM (Integrated Framework for Software Evolution and Mainte-nance), proposé par L. Deruelle [Der01], implémente le modèle SCSM et permet lareprésentation des codes sources des logiciels multi-langages et multi bases de don-nées. IFSEM est réalisé sous la forme de plusieurs plugins intégrés à l’environnementEclipse. L’implémentation de nos travaux consiste à étendre les plugins du systèmeIFSEM pour intégrer le modèle ASCM [HDB09] et de le coupler avec le modèle SCSMafin de disposer d’une représentation exhaustive du logiciel.

6.2 Architecture du système

Fig. 6.1 – Architecture globale du système basé sur l’environnement de développement Eclipse

La figure 6.1 montre l’architecture globale de notre plate-forme basée sur Eclipseet étendue pour l’analyse d’impacts. Eclipse permet de développer des logiciels, gé-rés sous la forme de projets. Un projet Eclipse regroupe un ensemble de ressourcesqui peuvent être des fichiers de codes sources, des librairies ou des fichiers de des-cription d’architecture. L’ensemble des ressources d’un projet doit être analysé pourêtre représenté selon nos modèles SCSM et ASCM. Chaque modèle est instancié sousla forme d’un graphe sur lequel il est possible d’exécuter des opérations de modifi-cations. L’impact de ces opérations est calculé et propagé lors du déclenchement derègles introduites dans un système expert.Les extensions de la plate-forme Eclipse sont réparties selon quatre composants prin-cipaux [HDB09] :

6.2. Architecture du système 113

– l’analyseur multi-langages permet d’analyser les codes sources et les descrip-tions architecturales d’un logiciel,

– le modeleur logiciel permet de représenter les informations issues de la phased’analyse sous forme de graphes correspondants aux instanciations de nos mo-dèles ASCM et SCSM,

– le moteur du système expert permet, d’une part, d’enrichir le graphe obtenuen ajoutant des relations qui sont difficiles à extraire par une analyse lexicale etsyntaxique, et d’autre part, d’implémenter le processus de propagation d’im-pact de modifications proposé dans le chapitre précédent,

– l’interface utilisateur permettant au chargé d’évolution d’effectuer la gestion del’évolution et la maintenance d’un système logiciel de façon interactive.

6.2.1 L’analyseur de codes sources et de descriptions d’architectures multi-langages

La première extension de la plate-forme Eclipse a pour objectif d’analyser les fi-chiers d’un projet pour fournir une représentation uniforme et homogène de ceux-ci.Ces fichiers peuvent être des codes sources développés dans différents langages, desdéfinitions de schémas de bases de données ou des descriptions d’architectures.L’analyse est basée sur la grammaire de chaque langage ayant servi à l’écriture dufichier. La grammaire comporte des actions sémantiques qui permettent lors de laconstruction de l’arbre syntaxique abstrait AST (Abstract Syntax Tree) de produireune représentation XML. Celle-ci décrit de manière uniforme et homogène la struc-ture des codes sources et des descriptions d’architectures multi-langages. La struc-ture décrite en XML est définie selon les modèles SCSM et ASCM, permettant pourchaque composant et relation de les représenter de la même manière à l’aide d’unensemble de balises.

L’analyseur multi-langages est un plugin Eclipse permettant de déclencher desparseurs selon le langage utilisé lors du développement de chaque fichier du projet.Les parseurs sont générés à l’aide de l’outil JavaCC (Java Compiler Compiler) 3 selonun référentiel de grammaires décrivant chaque langage. Le plugin est extensible afinde considérer de nouveaux langages de programmation ou de description d’archi-tecture. Ceci est réalisé par l’ajout d’une grammaire le décrivant et comportant lesactions sémantiques nécessaires à l’extraction des composants et des relations selonles modèles SCSM et ASCM. Les actions sémantiques permettent de traduire un élé-ment du langage dans une balise XML représentant un composant ou une relation.

JavaCC est un compilateur de compilateurs (comme Yacc en UNIX) et un géné-rateur d’analyseur lexical et syntaxique (comme le fait Lex en UNIX) entièrementécrit dans le langage Java et intégrable à la plate-forme Eclipse. Il produit un analy-seur lexical et syntaxique reconnaissant une grammaire à partir de ses spécifications.Les analyseurs générés par JavaCC sont capables de construire des représentations

3S. Microsystems - https ://javacc.dev.java.net/, 1999


partielles d’un fichier source en ne déclenchant qu’un sous-ensemble de règles deproduction. Ce mécanisme fournit l’avantage de pouvoir analyser partiellement lesimpacts des modifications, uniquement aux parties de codes sources ou de descrip-tions d’architecture ayant subie une modification.

Le résultat de l’analyse multi-langages consiste à produire des descriptions XMLservant à la construction du graphe effectué par le deuxième plugin, appelé le mo-deleur logiciel.

6.2.2 Le modeleur logiciel

Les représentations XML, obtenues par l’analyseur multi-langages, permettent dereprésenter les composants et les relations issus des codes sources et des descriptionsd’architectures. Le modeleur logiciel est la deuxième extension d’Eclipse comportantl’implémentation des modèles SCSM et ASCM ainsi qu’un analyseur de flux XML.Ce dernier permet d’instancier les éléments des modèles pour chaque composantou relation décrit dans le fichier XML. Les modèles sont instanciés sous la formede graphe dont les nœuds représentent les composants et les arcs leurs relations.Le modeleur logiciel fournit un ensemble de services basiques pour la création ettransformation de graphes basés sur des représentations XML.Le modeleur logiciel analyse les graphes construits, afin de déduire de nouvellesrelations non décrites dans les flux XML telles que la surcharge d’une méthode,le polymorphisme d’objets, les relations d’utilisation des ports par des connecteurset les relations de projections des éléments architecturaux vers le code source. Lemodeleur logiciel effectue les assertions des faits dans le moteur de règles afin deconstruire une base de connaissances du logiciel. Cette base de connaissances est leconstituant central de notre implémentation et permet la propagation de l’impactd’une modification.

6.2.3 Le système expert DROOLS

DROOLS (ou Jboss Rules) est un système expert, basé sur l’algorithme Rete[For82]. Il supporte le développement de systèmes experts basés sur des règlesintégrées à une application Java. Nous pouvons intégrer du code Java ou appeler desméthodes d’objet dans les actions à exécuter dans les règles DROOLS. Nous pouvonségalement faire appel à des fonctions propres DROOLS, comme par exemple, la fonc-tion update qui met à jour le nouvel état de l’objet passé en paramètre. Un éditeur derègles pour DROOLS existe sous la forme d’un plugin intégrable à l’environnementEclipse.

Le système expert DROOLS est le troisième plugin Eclipse dont l’objectif estd’implémenter le processus de propagation d’impact. Notre système expert estconstitué d’une base de faits comportant l’ensemble des composants et des relationsissus des modèles SCSM et ASCM. La base de faits est renseignée au fur et à mesure


de la construction des graphes réalisée par le modeleur logiciel. Ces faits sont lesdéclencheurs des règles de propagation d’impact lorsqu’une modification est réalisée.

Deux catégories de règles sont définies dans notre système expert :– les règles de construction du graphe d’architecture : lors de l’analyse d’un pro-

jet, certains liens sont difficiles à extraire des codes sources et des descriptionsd’architectures. Cependant, l’analyse permet de remplir la base de connais-sances du système expert, à partir de laquelle il est possible d’exprimer desrègles pour déduire des relations et compléter le graphe SCSM et ASCM. Lesrelations déduites sont, par exemple, hasType, établie entre un sous-composantsc et un composant c et indiquant que sc est une instance de c, ou la relationusePortSrc établie entre un connecteur cn et un port p pour indiquer que cn acomme port source p ;

– les règles implémentant le processus de propagation d’impact décrit dansle chapitre précédent. Le système expert DROOLS exploite les informationscontenues dans le graphe et insérées sous forme de faits dans la base deconnaissances. Lorsqu’un composant ou une relation est affecté par une opéra-tion de modification, le fait correspondant est également modifié pour refléterson état. Ce fait modifié permet le déclenchement des règles de propagationd’impact et de marquer les arcs et les nœuds du graphe affectés par cetteopération.

Listing 6.1 – Description de l’architecture de Producteur - Consommateur avec AADL� �1 data Alpha_Type2 end Alpha_Type;3

4 subprogram Produce_Spg5 features6 Data_Source : out parameter Alpha_Type;7 properties8 source_language => Ada95;9 source_name => "Producer_Consumer.Produce_Spg";

10 end Produce_Spg;11

12 thread Prod13 features14 Data_Source_out : out data port Alpha_Type;15 end Prod;16

17 thread implementation Prod.Impl18 calls {19 P_Spg : subprogram Produce_Spg;20 };21 connections22 PC1 : parameter P_Spg.Data_Source −> Data_Source_out;23 properties24 Dispatch_Protocol => Periodic;25 Period => 200 Ms;26 end Prod.Impl;27

28 subprogram Consume_Spg29 features30 Data_Sink : in parameter Alpha_Type;


31 properties32 source_language => Ada95;33 source_name => "Producer_Consumer.Consume_Spg";34 end Consume_Spg;35

36 thread Cons37 features38 Data_Sink_in : in data port Alpha_Type;39 end Cons;40

41 thread implementation Cons.Impl42 calls {43 Q_Spg : subprogram Consume_Spg;44 };45 connections46 PC2 : parameter Data_Sink_in −> Q_Spg.Data_Sink;47 properties48 Dispatch_Protocol => Periodic;49 Period => 100 Ms;50 end Cons.Impl;51

52 process processusA53 features54 AlphaA : out data port Alpha_Type;55 BetaA : in data port Alpha_Type;56 end processusA;57

58 process implementation processusA.Impl59 subcomponents60 Producer : thread Prod.Impl;61 Result_Consumer : thread Cons.Impl;62 connections63 PC3 : data port Producer.Data_Source_out −> AlphaA;64 PC4 : data port BetaA −> Result_Consumer.Data_Sink_in;65 end processusA.Impl;66

67 process processusB68 features69 AlphaB : out data port Alpha_Type;70 BetaB : in data port Alpha_Type;71 end processusB;72

73 process implementation processusB.Impl74 subcomponents75 Consumer : thread Cons.Impl;76 Result_Producer : thread Prod.Impl;77 connections78 PC5 : data port BetaB −> Consumer.Data_Sink_in;79 PC6 : data port Result_Producer.Data_Source_out −> AlphaB;80 end processusB.Impl;81

82 system PC_Simple83 end PC_Simple;84

85 system implementation PC_Simple.Native86 subcomponents87 pr_A : process processusA.processusAImpl;88 pr_B : process processusB.processusBImpl;89 connections90 PC7 : data port pr_A.AlphaA −> pr_B.BetaB91 PC8 : data port pr_B.AlphaB −> pr_A.BetaA92 end PC_Simple.Native;� �


Fig. 6.2 – Exemple d’un graphe partiel d’une représentation architecturale

6.2.3.1 Règles de construction du graphe d’architecture

L’analyse de la description architecturale et des codes sources génère un graphepouvant être partiel. La figure 6.2 illustre un exemple de graphe obtenu suite à l’ana-lyse d’une description d’architecture AADL, correspondante à l’exemple donné dansle chapitre 2. Nous rappelons cette description dans le listing 6.1. De nombreuses re-lations sont manquantes dans le graphe et il est relativement difficile de les extraired’une description architecturale par une analyse lexicale et syntaxique.

Règle pour la déduction de la relation entre un connecteur et ses ports

Les nœuds de type “EDC” pour Event Data Connection, “EC” pour Event Connection et“DC” pour Data Connection relient deux ports. Dans le graphe initial issu de l’analyselexicale et syntaxique, il n’existe pas de relations reliant la connexion à ces deux ports.Dans la figure 6.2, les arcs partants du nœud V31 vers V26 et V18 ne sont pas déduits.


Le listing 6.2 montre la règle qui effectue l’ajout de la relation entre un connecteur etson port source et par conséquent, un arc entre les nœuds correspondants est ajoutédans le graphe. La ligne 3 vérifie qu’il existe un fait, nPort, correspondant à un nœudqui possède un nom et de type EDP, DP ou EP. Dans la base de connaissances du SE,les faits sont des ArchitectNode et des ArchitectEdge pour représenter respectivementdes nœuds et des arcs.La règle vérifie qu’il existe un fait nConnect de type EDC, EC ou DC. Lorsque cesdeux faits existent dans la base de connaissances, la règle vérifie la dernière conditionqui consiste à vérifier si le fait nConnect possède un attribut src contenant le nomdu port de nPort. La règle est déclenchée lorsque cet ensemble de conditions estvérifié. La partie action consiste à ajouter un arc labélisé usePortSrc partant du nœudnConnect et à destination de nPort.

Trois autres règles, similaires à celle décrite dans le listing 6.2, sont définies afinde relier un connecteur à (1) son port destination, (2) son paramètre source et (3) sonparamètre destination.

Listing 6.2 – Règle DROOLS pour ajouter les relations entre les connecteurs et les ports� �1 rule "ConnectConnecToItsPortSrc"2 when3 nPort : ArchitectNode ( portName : name)4 eval (nPort.getTypeNode().equalsIgnoreCase("EDP") ||

nPort.getTypeNode().equalsIgnoreCase("EP") ||nPort.getTypeNode().equalsIgnoreCase("DP")

)5 nConnect : ArchitectNode( )6 eval (nConnect.getTypeNode().equalsIgnoreCase("EDC") ||

nConnect.getTypeNode().equalsIgnoreCase("EC") ||nConnect.getTypeNode().equalsIgnoreCase("DC")

)7 eval(nConnect.getAttributes("src "). equalsIgnoreCase(portName))8 then9 nConnect.getArchitectGraph().addEdge("usePortSrc",nPort,nConnect);10 end� �Règle pour la déduction de la relation entre un sous-composant et son type

Les nœuds de type “TH_SUB” pour les sous-composants Thread, “PR_SUB” pourles sous-composants Process et “SYS_SUB” pour les sous-composants System sontinstanciés à partir des déclarations des composants (interface ou implémentation). Unarc définissant la relation d’instanciation doit exister pour relier un sous-composantà son type. La figure 6.2 montre que le sous-composant représenté par le nœud V29n’a pas d’arc vers son type représenté par le nœud V19.La règle DROOLS permettant d’ajouter cette relation est donnée dans le listing 6.3.Elle considère deux faits appelés, nComp et nCompSub, tels que nComp est un nœudde type TH, TH_IMP, PR, PR_IMP, SYS ou SYS_IMP et nCompSub est un nœudde type TH_SUB, PR_SUB ou SYS_SUB. La règle vérifie que le nœud nCompSub estde type nComp. Dans ce cas, un arc est, labélisé hasType, est ajouté entre nCompSubet nComp.


Listing 6.3 – Règle DROOLS pour ajouter les relations d’instanciation entre les sous-composants etleur type� �1 rule "ConnectSubCompToItsComp"2 when3 nComp : ArchitectNode ( nCompName : name)4 eval (nComp.getTypeNode().equalsIgnoreCase("TH") ||

nComp.getTypeNode().equalsIgnoreCase("TH_IMP") ||nComp.getTypeNode().equalsIgnoreCase("PR") ||nComp.getTypeNode().equalsIgnoreCase("PR_IMP") ||nComp.getTypeNode().equalsIgnoreCase("SYS") ||nComp.getTypeNode().equalsIgnoreCase("SYS_IMP")

)5 nCompSub : ArchitectNode ()6 eval (nCompSub.getTypeNode().equalsIgnoreCase("TH_SUB") ||

nCompSub.getTypeNode().equalsIgnoreCase("PR_SUB") ||nCompSub.getTypeNode().equalsIgnoreCase("SYS_SUB")

)7 eval(nCompSub.getAttributes("hasType").equalsIgnoreCase(nCompName))8 then9 nCompSub.getArchitectGraph().addEdge("hasType", nComp, nCompSub);10 end� �Règle pour la déduction de la relation entre une implémentation d’un composantet son interface

Les nœuds de type “TH_IMP” pour l’implémentation d’un composant de typeThread, “PR_IMP” pour l’implémentation d’un composant de type Process et“SYS_IMP” pour l’implémentation d’un composant de type System sont associés àune interface d’un composant. Chaque interface d’un composant peut posséder zéro,une ou plusieurs implémentations. Dans le graphe initial, les relations reliant l’im-plémentation d’un composant à la description de son interface n’existent pas. Dans lafigure 6.2, les nœuds V19, V12 et V27 n’ont respectivement pas d’arcs vers les nœudsV17, V10 et V24.La règle qui se charge d’ajouter ces liens est donnée dans le listing 6.4. Elle permetd’ajouter la relation entre la déclaration de l’implémentation d’un composant et soninterface. Elle considère deux faits appelés, nComp et nCompImp, tels que nCompest un nœud de type TH, PR ou SYS et nCompImp est un nœud de type Th_IMP,PR_IMP ou SYS_IMP. La règle vérifie que le nœud nCompImp possède un attributimpFor qui correspond au nom, nCompName, de nComp. Dans ce cas, un arc labéliséimpFor est ajouté, partant du nœud nCompImp et à destination du nœud nComp.

Listing 6.4 – Règle DROOLS pour ajouter un lien entre la déclaration de l’implémentation d’uncomposant et celle de son interface� �1 rule "ConnectCompImpToItsCompType"2 when3 nComp : ArchitectNode ( nCompName : name)4 eval (nComp.getTypeNode().equalsIgnoreCase("TH") ||

nComp.getTypeNode().equalsIgnoreCase("PR") ||nComp.getTypeNode().equalsIgnoreCase("SYS")

)5 nCompImp : ArchitectNode ()6 eval (nCompImp.getTypeNode().equalsIgnoreCase("TH_IMP") ||

nCompImp.getTypeNode().equalsIgnoreCase("PR_IMP") ||


nCompImp.getTypeNode().equalsIgnoreCase("SYS_IMP"))

7 eval(nCompImp.getAttributes("impFor").equalsIgnoreCase(nCompName))8 then9 nCompImp.getArchitectGraph().addEdge("impFor", nComp, nCompImp);10 end� �Règle pour la déduction de la relation entre un port ou un paramètre et son typede données

Les nœuds de type “EDP” pour Event Data Port, “DP” pour Data port et “PARAM”pour Parameter peuvent posséder un type spécifique défini par l’utilisateur ou l’ar-chitecte. Le graphe initial ne comporte pas de relations reliant un port à son type dedonnées. La figure 6.2 montre que les nœuds V3, V7, V11, V18, V25 et V26 n’ont pasd’arcs les reliant au nœud V1 qui représente leur type de données.Le listing 6.5 montre la règle permettant d’ajouter la relation entre un port et sontype de données. La règle considère deux faits représentant un nœud, nDataType,de type DATA et un autre, nPort, de type DP ou EDP. La règle vérifie si le nœudnPort possède un attribut égale au nom nDataName du nœud nDataType. Lorsquecet ensemble de conditions est vérifié, un arc, labélisé hasDataType, est ajouté dansle graphe, partant du nœud nPort et à destination de nDataType.

Listing 6.5 – Règle DROOLS pour ajouter les relations entre un port et son type� �1 rule "ConnectPortToItsType"2 when3 nDataType : ArchitectNode ( nDataName : name, typeNode=="DATA")4 nPort : ArchitectNode ()5 eval (nPort.getTypeNode().equalsIgnoreCase("DP") ||

nPort.getTypeNode().equalsIgnoreCase("EDP"))

6 eval(nPort. getAttributes ("datatype").equalsIgnoreCase(nDataName))7 then8 nPort.getArchitectGraph().addEdge("hasDataType", nDataType, nPort);9 end� �Règle pour la déduction de la relation entre une instance d’un sous-programme etun thread

Les nœuds de type “SUB_CALL” pour l’appel de sous-programme sont appelés parles nœuds de type “TH_IMP”. Chaque sous-programme appelé est instancié à partird’une déclaration d’un sous-programme (interface ou implémentation). La relationreliant un nœud de type “SUB_CALL” à son type de sous-programme n’apparaît pasdans le graphe initial. La figure 6.2 montre que les nœuds V13 et V20 ne sont pasreliés à leur sous-programme type représenté respectivement par les nœuds V2 etV6.La règle qui permet d’ajouter la relation entre une instance d’un sous-programme etson type est donnée dans le listing 6.6. Elle considère un fait appelé, nSubProgram detype SUBPROGRAM ou SUB_IMP, et un deuxième nSubCall de type SUB_CALL.


La règle vérifie que le nœud nSubCall possède un attribut hasType qui correspond aunom du nœud nSubProgram. Lorsque cet ensemble de conditions est vérifié, un arc,labélisé hasType, est ajouté dans le graphe en partant de nSubCall et à destination denSubProgram.

Listing 6.6 – Règle DROOLS pour ajouter les relations entre un appel d’un sous-programme et sontype� �1 rule "ConnectSubProgrammCallToItsType"2 when3 nSubProgram : ArchitectNode ( nSubProgName : name)4 eval (nSubProgram.getTypeNode().equalsIgnoreCase("SUBPROGRAM") ||

nSubProgram.getTypeNode().equalsIgnoreCase("SUB_IMP"))

4 nSubCall : ArchitectNode (typeNode=="SUB_CALL")5 eval(nSubCall.getAttributes("hasType").equalsIgnoreCase(nSubProgName))6 then7 nSubCall.getArchitectGraph().addEdge("hasType", nSubProgram, nSubCall);8 end� �

Les règles définies sont intégrées dans notre base de règles afin de compléter laconstruction du graphe d’architecture. Ces règles sont déclenchées par le systèmeexpert lorsqu’il existe des faits candidats les vérifiant. Le système expert déduit,à l’aide de sa base de connaissances et des règles, les relations entre deux nœudslorsque ceux-ci sont présents sous forme de faits et que la relation n’existe pas dansle graphe. Nous montrons, dans la figure 6.3, le graphe complet obtenu après le dé-clenchement des règles. Dans ce graphe, les arcs ajoutés après le déclenchement desrègles concernent :

– la relation entre les sous-composants et leur type, par exemple, entre les nœudsV29 et V19, V28 et V12, V43 et V35 ;

– la relation entre les sous-programmes appelés et leur type, par exemple, entreles nœuds V13 et V2, V20 et V6 ;

– la relation entre les ports ou paramètres et leur type, par exemple, entre lesnœuds V3 et V1, V25 et V1, V34 et V1 ;

– la relation entre les connecteurs et leur port ou paramètre source : entre lesnœuds V14 et V11, V21 et V18, V45 et V33 ;

– la relation entre les connecteurs et leur port ou paramètre destination : entreles nœuds V14 et V3, V21 et V7, V45 et V26 ;

– la relation entre l’implémentation d’un composant et son interface : entre lesnœuds V19 et V17, V27 et V24, V41 et V40.

6.2.3.2 Règles de propagation d’impact de modifications

Les règles de propagation d’impact calculent l’effet de bord d’une modificationsur un composant, puis propage l’impact aux autres composants du graphe d’ar-chitecture en relation avec celui-ci. Le calcul de l’impact est réalisé par la règleRegle_Impact_Operation définie dans le chapitre précédent. Celle-ci effectue le mar-quage du composant modifié si au moins un invariant de l’opération exécutée n’est


Fig. 6.3 – Exemple d’un graphe complet après l’application des règles pour compléter la constructiondu graphe

pas respecté. Le marquage du nœud modifie l’état du composant ou de la relation etpar conséquent son fait dans la base de connaissances. Ceci provoque le déclenche-ment d’une règle de propagation Regle_Propager_Impact qui marque, selon l’opé-ration et la conductivité de la relation, (1) l’ensemble des nœuds destinations desrelations sortantes du nœud marqué et (2) les nœuds sources des relations entrantesvers le nœud marqué.La règle de propagation d’impact dépend de l’opération, du type de nœud et de laconductivité de chaque type de relation reliant le nœud affecté aux autres nœuds


du graphe. La règle de calcul d’impact est basée sur le principe de violation desinvariants d’une opération.

Listing 6.7 – Exemple de règle d’évolution DROOLS� �1 rule "ImpactDeletePort"2 when3 n : ArchitectNode (stateNode==ArchitectStateNode.STATE_DELETED, typeNode=="EDP")4 n1 : ArchitectNode( )5 e : ArchitectEdge()6 eval((e.getNodeDest()==n && e.getNodeSrc()==n1)||7 (e.getNodeSrc()==n && e.getNodeDest()==n1))8 then9 n.setLabel("DELETED "+n.getLabel());

10 n.setStateNode(ArchitectStateNode.STATE_IMPACTED);11 end12

13 rule "PropagerImpactDeletePort"14 when15 n : ArchitectNode (stateNode==ArchitectStateNode.STATE_IMPACTED, typeNode=="EDP")16 n1 : ArchitectNode( )17 e : ArchitectEdge()18 eval((e.getNodeDest()==n && e.getNodeSrc()==n1)||19 (e.getNodeSrc()==n && e.getNodeDest()==n1))20 then21 e.setState(ArchitectStateEdge.STATE_IMPACTED);22 n1.setStateNode(ArchitectStateNode.STATE_IMPACTED);23 end� �

Nous montrons, dans le listing 6.7, un exemple de règle de calcul de l’impact pour lasuppression d’un nœud de type EDP.Nous représentons, dans nos règles, un composant par un fait appelé “ArchitectNo-de” et un arc par un fait appelé “ArchitectEdge”. L’opération de suppression d’uncomposant ou d’une relation est réalisée au niveau de l’environnement de dévelop-pement Eclipse, par conséquent en dehors de la base de connaissances du systèmeexpert.Cette opération modifie l’état du composant afin d’indiquer qu’il est en cours desuppression (ArchitectStateNode.STATE_DELETED). Cet état est représenté dans lesystème expert afin de permettre le déclenchement de la règle de calcul d’impact.Lorsque les conditions de la règle sont vérifiées, le moteur de règles déclenche lapartie action de la première règle pour :

1. changer le label du nœud supprimé (ligne 9),

2. indiquer que le composant est affecté par l’opération de suppression, en modi-fiant son état (ligne 10),

La deuxième règle se charge de propager l’impact lorsqu’un fait de la base deconnaissances est dans l’état affecté (ArchitectStateNode.STATE_IMPACTED). Celle-ci :

1. change l’état de chaque arc sortant et arc entrant en STATE_IMPACTED (ligne21). Ceci signifie que ces arcs sont affectés par l’opération de suppression,

2. marque tous les nœuds connectés à n, via la relation e comme étant affectés parla modification (STATE_IMPACTED) (ligne 22).


Le résultat de cette règle consiste à marquer chaque nœud et arc affectés par lamodification. Le marquage modifie l’état des composants et des relations permettantd’obtenir de nouveaux faits candidats qui vont à leur tour déclencher d’autres règles.

Nous avons défini une règle pour chaque type d’opération de modification etselon chaque type de composant. Lorsque les résultats d’une opération sur plusieurscomposants sont similaires, nous avons généralisé et regroupé ces règles en une seule(listings 6.8 et 6.9).

Listing 6.8 – Exemple de plusieurs règles exécutant la même action sur plusieurs types de composant� �1 rule "PropagerImpactDeleteEDPort"2 when3 n : ArchitectNode (stateNode==ArchitectStateNode.STATE_DELETED, typeNode=="EDP")4 n1 : ArchitectNode( )5 e : ArchitectEdge()6 eval((e.getNodeDest()==n && e.getNodeSrc()==n1)||7 (e.getNodeSrc()==n && e.getNodeDest()==n1))8 then9 n.setLabel("DELETED "+n.getLabel());

10 n.setStateNode(ArchitectStateNode.STATE_IMPACTED);11 end12

13 rule "PropagerImpactDeleteDPort"14 when15 n : ArchitectNode (stateNode==ArchitectStateNode.STATE_DELETED, typeNode=="DP")16 n1 : ArchitectNode( )17 e : ArchitectEdge()18 eval((e.getNodeDest()==n && e.getNodeSrc()==n1)||19 (e.getNodeSrc()==n && e.getNodeDest()==n1))20 then21 n.setLabel("DELETED "+n.getLabel());22 n.setStateNode(ArchitectStateNode.STATE_IMPACTED);23 end24

25 rule "PropagerImpactDeleteEPort"26 when27 n : ArchitectNode (stateNode==ArchitectStateNode.STATE_DELETED, typeNode=="EP")28 n1 : ArchitectNode( )29 e : ArchitectEdge()30 eval((e.getNodeDest()==n && e.getNodeSrc()==n1)||31 (e.getNodeSrc()==n && e.getNodeDest()==n1))32 then33 n.setLabel("DELETED "+n.getLabel());34 n.setStateNode(ArchitectStateNode.STATE_IMPACTED);35 end� �

Dans le listing 6.8, nous définissons les règles décrivant l’opération qui consiste àsupprimer un port. L’invariant de cette opération qui consiste à vérifier qu’il n’existeaucun arc, de type usePortSrc ou usePortDst, à destination du port supprimé, estidentique pour les trois types de ports DP, EDP et EP. Le résultat du déclenchementde la règle de propagation consiste à marquer les nœuds n. Par conséquent, nousavons procédé à un regroupement de ces règles (listing 6.9).

Listing 6.9 – Règle obtenue en combinant les différentes règles du listing 6.8� �1 rule "PropagerImpactDeletePort"2 when3 n : ArchitectNode (stateNode==ArchitectStateNode.STATE_DELETED)


4 eval(n.getTypeNode().equalsIgnoreCase("DP") ||5 n.getTypeNode().equalsIgnoreCase("EP") ||6 n.getTypeNode().equalsIgnoreCase("EDP")7 )8 n1 : ArchitectNode( )9 e : ArchitectEdge()

10 eval((e.getNodeDest()==n && e.getNodeSrc()==n1)||11 (e.getNodeSrc()==n && e.getNodeDest()==n1))12 then13 n.setLabel("DELETED "+n.getLabel());14 n.setStateNode(ArchitectStateNode.STATE_IMPACTED);15 end� �

6.2.4 Interface utilisateur

L’interface utilisateur est le quatrième plugin Eclipse permettant la visualisationdu graphe obtenu et l’application des opérations de modification sur ce graphe.

La visualisation est le processus qui transforme l’information sous un formatvisuel permettant aux utilisateurs de l’observer et de la manipuler. Le résultat d’affi-chage visuel permet, au scientifique ou à l’ingénieur, de percevoir les caractéristiquesvisuelles qui sont cachées dans les données mais qui sont utiles pour leur explorationet leur analyse [BMR+

94].L’interface utilisateur de notre plate-forme permet la visualisation du graphe du lo-giciel et offre au chargé d’évolution un moyen simple et efficace pour la gestion del’évolution de l’architecture ou du code source d’une façon interactive. L’interface estdéveloppée en Java, en utilisant la librairie JUNG4 supportant de nombreuses repré-sentations de graphes telles que les graphes orientés ou non, les sous-graphes et leshypergraphes.

Fig. 6.4 – Exemple de menu déroulant associé à un nœud du graphe

Notre plate-forme offre une vision globale des composants de l’architecture d’unsystème ainsi que de leurs attributs, mais également les composants du code sourceliés à ceux de l’architecture par une relation de projection. L’interface de visualisa-tion des graphes permet de déclencher les opérations de modification d’un nœudsélectionné par l’intermédiaire d’un menu déroulant (figure 6.4). Les actions propo-sées pour la modification d’un nœud dépendent du type de nœud sélectionné. Parexemple, en sélectionnant un nœud de type DP, EP ou EDP, les actions suivantessont proposées par notre système : (1) modifier le nom du nœud, (2) modifier le typedu nœud (le changer de DP à EP, par exemple) et (3) supprimer le nœud.L’exécution de ces opérations de modification conduit à une propagation d’impact

4http ://jung.sourceforge.net/

126 6.3. Scénario

Fig. 6.5 – Exemple de graphe avec une surcharge d’informations encombrant sa compréhension et samanipulation

sur les autres nœuds du graphe lorsque les invariants de l’opération sont violés. Lesnœuds et les arcs affectés par la modification sont désignés par un changement delabel et un changement de couleur, dans le graphe .

La représentation sous forme de graphes du logiciel souffre de quelques pro-blèmes lorsque ceux-ci sont de grandes tailles. La représentation devient peu com-préhensible du fait de la surcharge d’informations. La figure 6.5 illustre ce problème.Le chargé d’évolution a certaines difficultés dans la compréhension du graphe etpar conséquent, la visualisation des impacts de modification s’avère une tâche assezdifficile.

Nous présentons, dans ce qui suit, un scénario complet pour la propagation d’im-pact de modifications. Nous considérons la description architecturale du modèle Pro-ducteur/Consommateur fournie dans le chapitre 2.

6.3 Scénario

À partir de la description du listing 6.1, nous construisons le graphe ASCM mon-tré dans la figure 6.3. Nous proposons une liste d’opérations de modification dé-pendant du type du nœud sélectionné. Les opérations appliquées sur les nœuds dugraphe sont considérés comme des faits qui s’insèrent dans la base de connaissances.

6.3. Scénario 127

Lorsqu’une opération est invoquée sur un élément du graphe, le système expert exé-cute la partie post-condition de l’opération si les pré-conditions et les invariants sontrespectés. Considérons l’exemple de suppression du sous-programme Produce_Spg,défini des lignes 4 à 10 du listing 6.1. Ce sous-programme est instancié à la ligne19 de ce listing, ce qui signifie que l’un des invariants n’est pas respecté. Le systèmeexpert change l’état du nœud V2 : SUBPROGRAM name = Produce_Spg en insérantun nouveau fait correspondant dans la base de faits. Ce changement d’état déclenchele processus de propagation d’impact et par conséquent, le marquage des nœudset des arcs affectés par cette opération. L’insertion d’un nouveau fait dans la base defaits déclenchera les règles de modification et de propagation d’impacts décrites dansle système expert. La règle ImpactDeletingNode, définie dans le listing 6.10, est dé-clenchée lorsque le système expert détecte un changement dans l’état d’un nœud dugraphe qui devient égale à STATE_DELETED (correspondant à une action de sup-pression effectuée sur un nœud du graphe). La partie action de cette règle consiste àchanger le label du nœud supprimé en lui ajoutant “DELETED”. L’état de ce nœuddevient également affecté (STATE_IMPACTED).

Listing 6.10 – Règle pour le changement du label et d’état d’un nœud supprimé� �1 rule "ImpactDeletingNode"2 when3 n : ArchitectNode (stateNode==ArchitectStateNode.STATE_DELETED)4 then5 if (! n.getLabel().contains("DELETED"))6 n.setLabel("DELETED "+n.getLabel());7

8 n.setStateNode(ArchitectStateNode.STATE_IMPACTED);9 end� �

Listing 6.11 – Règles de propagation d’impacts suite à la suppression d’un composant� �1 // Impacts en considérant les arc sortants du composant supprimé2 rule "DeleteComponentDef_ConsequenceOnOutputEdges"3 when4 n : ArchitectNode (stateNode==ArchitectStateNode.STATE_IMPACTED)5 eval( n.getTypeNode().equalsIgnoreCase("TH") || n.getTypeNode().equalsIgnoreCase("PR") ||6 n.getTypeNode().equalsIgnoreCase("SYS") || n.getTypeNode().equalsIgnoreCase("SUBPROGRAM") )7 n1 : ArchitectNode( )8 e : ArchitectEdge(nodeSrc ==n, nodeDest ==n1)9 then

10 e.setState(ArchitectStateEdge.STATE_IMPACTED);11 n1.setStateNode(ArchitectStateNode.STATE_IMPACTED);12 end13

14 // Impacts en considérant les arcs entrants vers les composant supprimé15 rule "DeleteComponentDef_ConsequenceOnInputEdges"16 when17 n : ArchitectNode (stateNode==ArchitectStateNode.STATE_IMPACTED)18 eval( n.getTypeNode().equalsIgnoreCase("TH") || n.getTypeNode().equalsIgnoreCase("PR") ||19 n.getTypeNode().equalsIgnoreCase("SYS") || n.getTypeNode().equalsIgnoreCase("SUBPROGRAM") )20 n1 : ArchitectNode( )21 e : ArchitectEdge(nodeDest ==n, nodeSrc ==n1)22 then23 e.setState(ArchitectStateEdge.STATE_IMPACTED);24 if (e.getLabel().equalsIgnoreCase("impFor") || e.getLabel().equalsIgnoreCase("hasType"))25 n1.setStateNode(ArchitectStateNode.STATE_IMPACTED);26 end� �

128 6.3. Scénario

Fig. 6.6 – Le graphe après l’exécution de l’opération de modification

Les règles, présentées dans le listing 6.11, montrent les impacts de la suppressiond’un composant sur ses nœuds voisins. Ces règles sont les mêmes pour les compo-sants de type TH, PR ou SYS. La première règle de ce listing propage l’impact versles nœuds voisins en considérant les arcs sortants du composant supprimé. Tous lesarcs sortants de ce composant seront marqués a priori ainsi que leurs nœuds desti-nations. Sur le graphe, le marquage est effectué sur les nœuds V3 de type PARAM,V4 et V5 de type PROP ainsi que sur les arcs reliant ces nœuds au nœud V2 repré-

6.4. Analyse d’impact inter-modèles 129

sentant le sous-programme supprimé. Le fait que le nœud V3 soit marqué a prioricause un effet sur la connexion qui utilise ce paramètre (ligne 22 du listing 6.1). Parconséquent, cette connexion, représentée par le nœud V14, est marquée comme af-fecté. L’arc qui relie V3 à V1, représentant que le type de données du paramètre“Data_source” est “Alpha_Type”, est également marqué a priori.La deuxième règle de ce listing concerne les arcs entrants dans V2. L’arc reliant V2à V0 est marqué. Le nœud V13, qui représente une instance du sous-programme“Produce_Spg” (ligne 19 du listing 6.1) est marqué, ainsi que son arc le reliant à V2.Le nœud V12, qui représente l’implémentation du thread “Prod”, effectue un appelà l’instance P_Spg. Par conséquent, l’arc reliant V13 à V12 est marqué.

La figure 6.6 montre le graphe obtenu suite à la simulation de l’opération desuppression du sous-programme “Produce_Spg” du listing 6.1. Les nœuds affectéspar cette opération sont entourés. Un trait vertical ou horizontal indique que l’arc estaffecté.

6.4 Analyse d’impact inter-modèles

Nous avons établi, dans le chapitre 4, la relation de projection pouvant existerentre les composants du modèle ASCM et ceux du modèle SCSM. Le listing 6.12

représente le code source ada associé aux sous-programmes définis dans le listing6.1. Il définit les procédures Produce_Spg et Consume_Spg respectivement appeléspar Produce_Spg et Consume_Spg dans la description de l’architecture.

Listing 6.12 – Code source Ada associé aux sous-programmes de l’architecture AADL du modèleProducteur - Consommateur� �

1 with Ada.Text_IO; use Ada.Text_IO;2 package body Producer_Consumer is3 The_Data : Alpha_Type := 1;4 function Get_Node return String;5 function Get_Node return String is6 begin7 return Node_Type’Image (My_Node);8 end Get_Node;9 procedure Produce_Spg (Data_Source : out Alpha_Type) is

10 begin11 Data_Source := The_Data;12 The_Data := The_Data + 1;13

14 Put_Line (Normal, Get_Node15 & ": produced "16 & Alpha_Type’Image (Data_Source));17 end Produce_Spg;18 procedure Consume_Spg (Data_Sink : Alpha_Type) is19 begin20 Put_Line (Normal, Get_Node21 & " : consumed "22 & Alpha_Type’Image (Data_Sink));23 end Consume_Spg;24 end Producer_Consumer;� �

La figure 6.7 illustre le graphe obtenu en intégrant le code source Ada. La par-tie encadrée dans la figure représente les informations extraites à partir du modèle

130 6.4. Analyse d’impact inter-modèles

SCSM. Les liens entre les nœuds du graphe instanciant le modèle ASCM et ceux ins-tanciant le modèle SCSM sont établis à l’aide des relations de projection, représentéessur le graphe par les arcs labélisés “hasCodeSource”. Ces arcs relient les nœuds V2à V37 et V6 à V39. La règle, permettant d’établir le lien entre les deux niveaux dereprésentation, est donnée dans le listing 6.13.

Fig. 6.7 – Le graphe avec intégration du code source

L’opération de suppression exécutée sur le nœud V2 propage l’impact de modi-fication entre les deux représentations par le biais de la relation de projection, notéehasCodeSource. Nous montrons, dans le listing 6.14, la règle qui se charge de propager

6.5. Conclusion 131

l’impact entre ASCM et SCSM. Cette règle est déclenchée suite à la suppression dusous-programme. Au niveau de l’architecture, la suppression du sous-programmemarque le nœud qui lui correspond. Ce marquage propage l’impact sur le niveaucode source pour marquer l’arc hasCodeSource reliant le sous-programme à la procé-dure Ada correspondante comme étant également affecté. Le nœud V51, destinatairede cet arc, est également marqué. Le marquage de ce nœud propage l’impact vers sesarcs sortants à l’aide des règles définies pour le langage Ada.

Listing 6.13 – Règle pour établir le lien entre les deux niveaux de représentation� �1 rule "connectSubprogramToItsCodeSourceNode"2 when3 n1 : ArchitectNode( SubProgramName : name, typeNode=="SUBPROGRAM")4 n2 : ArchitectNode( PropertyName1 : name, typeNode=="PROP" )5 e1 : ArchitectEdge(nodeSrc==n1, nodeDest ==n2)6 n4 : ArchitectNode( PropertyName2 : name, typeNode=="PROP" )7 e2 : ArchitectEdge(nodeSrc==n1, nodeDest ==n4)8 n3 : ArchitectNode( ApplicationFileName : name)9 n5 : ArchitectNode( procedureName : name, typeNode=="PROCEDURE")

10 e3 : ArchitectEdge(nodeSrc==n3, nodeDest ==n5)11 eval(PropertyName1.equalsIgnoreCase("source_name"));12 eval(PropertyName2.equalsIgnoreCase("source_language"));13 eval (procedureName.equalsIgnoreCase(n2.getAttributes("procedure")));14 eval (n4.getAttributes ("source_language").equalsIgnoreCase(n3.getAttributes("source_language")));15 eval (n2.getAttributes ("source_name").equalsIgnoreCase(n3.getAttributes("filename")));16 then17 n1.getArchitectGraph().addEdge("hasCodeSource",n5, n1);18 end� �

Listing 6.14 – Règle pour la propagation de l’impact de modification entre les deux niveaux de repré-sentation� �

1 rule "DeleteSubProgramImpactOnADA"2 when3 subprogram : ArchitectNode (typeNode =="SUBPROGRAM", stateNode ==ArchitectStateNode.STATE_DELETED)4 procedure : ArchitectNode( typeNode=="PROCEDURE" )5 hasCode : ArchitectEdge(nodeSrc ==subprogram, nodeDest ==procedure, label=="hasCodeSource")6 then7 hasCode.setState(ArchitectStateEdge.STATE_IMPACTED);8 procedure.setStateNode(ArchitectStateNode.STATE_IMPACTED);9 end� �

La figure 6.8 montre l’impact de la suppression du sous-programme sur le niveaucode source ainsi que sur les liens entre les deux niveaux de représentation.

6.5 Conclusion

Ce chapitre a présenté l’implémentation des modèles et des techniques d’analysede l’impact d’une modification développés dans les chapitres précédents.Cette implémentation a été motivé par les principes de portabilité et d’extensibilité.Un objectif majeur de notre implémentation a été d’intégrer à la plate-forme Eclipseun ensemble d’outils et de modèles. Ceux-ci offrent à Eclipse des capacités pour lagestion de l’évolution des architectures logicielles, indépendamment des langages dedescription d’architecture (ADLs).

132 6.5. Conclusion

Fig. 6.8 – Le graphe incluant les représentations ASCM et SCSM après l’exécution de l’opération desuppression

L’architecture de notre plate-forme pour l’analyse d’impact est conçue autourd’un ensemble d’extensions (plugins) pour Eclipse permettant (1) l’analyse lexicaleet syntaxique des descriptions d’architectures et des codes sources multi-langages,(2) la représentation de ceux-ci de manière uniforme et homogène sous forme degraphes, (3) la propagation d’impact à l’aide du système expert DROOLS, (4) la vi-sualisation des graphes par le biais d’une interface graphique, (5) le déclenchementdes opérations et (6) l’obtention du résultat de l’analyse d’impacts.La représentation, sous forme de graphe, d’une application est obtenue suite à l’ana-lyse des fichiers de descriptions d’architecture et de codes sources. Ils représentent

6.5. Conclusion 133

les instances de nos modèles ASCM et SCSM. Ces graphes sont insérés sous formede faits dans la base de connaissances du système expert, lequel est capable d’inférerdes règles pour le calcul de l’impact de leur propagation.

Nous avons présenté un exemple d’application basé sur le modèle Producteur/Con-sommateur, décrit par une description d’architecture AADL et implémenté par uncode source Ada. Sur la base de cet exemple, nous avons défini un scénario pour va-lider notre approche et illustrer l’utilisation de notre plate-forme. Ce scénario effectuela suppression d’un composant de l’architecture et montre la propagation d’impactau niveau de l’architecture mais également vers le code source de l’application.

7Conclusion et perspectives

Sommaire

7.1 Résumé des contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

7.2 Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139

7.1. Résumé des contributions 137

7.1 Résumé des contributions

Nous nous sommes intéressés dans ce travail de thèse aux problèmes du contrôledes évolutions dans les architectures logicielles ainsi qu’à l’étude de l’impact desmodifications sur ces dernières et sur les codes sources correspondants. Nous noussommes intéressés tout d’abord aux travaux liés à la problématique de l’évolution dulogiciel en général, pour ensuite considérer ceux menés sur la gestion de l’évolutiondes architectures logicielles. Cela nous a conduit à étudier les différents langages dedescription d’architecture (ADLs) du point de vue de l’analyse d’impact. En effet, sicertains ADLs offrent un support basique pour l’évolution, ils ne proposent pas demécanismes pour l’analyse de l’impact de modifications. Ces mécanismes en dépitde leur importance n’appartiennent pas aux objectifs définis dans les ADLs.Après un examen et une synthèse des travaux relatifs à cette problématique, nousavons constaté que le problème de l’analyse de l’impact des modifications est peutraité et aucun mécanisme n’est proposé pour effectuer une analyse d’impact entrele niveau de description architecturale et celui du code source. L’ensemble de cesconclusions a constitué le point de départ de nos travaux.Dans ce travail, la majeure partie de nos efforts se situe sur la formalisation d’un mo-dèle permettant d’extraire les informations issues des descriptions d’architectures lo-gicielles, en considérant les différents éléments architecturaux communs à la plupartdes ADLs. Le modèle proposé se veut extensible afin de pouvoir intégrer d’autreséléments architecturaux selon la spécificité des différents ADLs. Cet effort était né-cessaire pour définir un référentiel, sur lequel a reposé un ensemble d’opérations debase réalisant l’évolution des architectures logicielles et pour proposer un mécanismepour l’étude de l’impact des modifications à l’issue de l’application de ces opérations.

Le modèle ASCM, proposé dans cette thèse, définit les concepts fondamentauxmis en avant par la plupart des ADLs ainsi que les relations entre ces éléments.Nous pouvons parler dans ce cas d’un méta-modèle permettant la représentationdes différents ADLs avec des raffinements possibles selon la spécificité de chaquelangage de description. Notre modèle peut être étendu pour intégrer d’autres caté-gories d’éléments architecturaux.

Une architecture est modélisée selon ASCM, par une configuration d’éléments ar-chitecturaux appartenant au modèle. Nous avons considéré une architecture ASCMsous la forme d’un graphe orienté dont les nœuds et les arcs sont typés. Les nœudsde ce graphe sont attribués et représentent les différents éléments de la descriptionarchitecturale. Les arcs représentent les relations entre ces éléments. Un grapheobtenu représente une instance de notre modèle sur lequel des opérations de mo-difications peuvent être appliquées. Nous avons spécifié un ensemble d’opérationsatomiques de manipulation et de modification du graphe.Afin d’élaborer des opérations plus complexes, nous avons exprimé ces opérationsselon des assertions. Ce formalisme nous a guidé pour la spécification du processus

138 7.1. Résumé des contributions

d’analyse d’impacts, basé sur un ensemble de règles formelles. Ces règles s’appuientsur les pré-conditions, les invariants et les post-conditions des différentes assertions.En particulier, lors du déclenchement d’une opération dont un invariant est violé,l’impact est propagé aux nœuds du graphe qui sont liés avec celui ayant subi l’opé-ration. L’étude de la violation d’un invariant d’une opération pour la propagation del’impact nous a amené à caractériser la conductivité de chaque relation. Le résultatde cette étude nous a conduit à considérer la conductivité comme étant particulièrepour chaque opération et chaque type de relation. Le processus de propagationd’impact est basé sur un système à base de connaissances, constitué d’une basede faits représentant les nœuds et les arcs du graphe et d’une base de règles pourcalculer et propager l’impact.Le choix d’un système à base de connaissances a été guidé par notre volonté dedisposer d’un système extensible. Il est en effet nettement plus aisé d’ajouter desrègles déclaratives à un système que d’ajouter des algorithmes.

Le référentiel nous a facilité la tâche pour répondre à un objectif majeur de notretravail, concernant la propagation d’impact de l’architecture vers les codes sourcesd’un logiciel et vice versa. À ce titre, nous avons couplé le modèle ASCM avec lemodèle SCSM, proposé par L. Deruelle, au sein de notre référentiel. Ce couplage estbasé sur la définition d’une relation de projection entre les éléments de ASCM etceux de SCSM. La relation de projection, conductrice de l’impact d’une modification,est intégrée à notre base de connaissances par le biais de règles de propagationinter-modèles.

Les travaux de cette thèse ont donné naissance à une plate-forme, réalisée sousla forme de plusieurs extensions intégrés à l’environnement Eclipse. Ces extensionsoffrent à Eclipse des outils pour l’analyse de descriptions d’architectures et de codessources indépendamment des langages de développement, la construction d’unréférentiel contenant les graphes issus de l’analyse et instanciant nos modèles, et unebase de connaissances implémentée sous la forme d’un système expert par laquellenous étudions le processus de propagation d’impact.Cet ensemble d’outils est piloté par une interface graphique, combinant la visuali-sation des graphes, le déclenchement des opérations de modification pour aboutir àl’obtention du résultat de l’analyse d’impacts.

Pour valider notre approche et illustrer le fonctionnement de notre plate-forme,nous avons défini un scénario. Celui-ci est basé sur une description d’architecturedans le langage AADL d’une application Producteur/Consommateur. Ce scénariomontre qu’une simple opération de suppression d’un composant de l’architecture sepropage au niveau des autres composants de celle-ci, puis vers les composants ducode source qui l’implémentent. Bien que cette application soit académique, nous

7.2. Perspectives 139

sommes en cours d’expérimentation de notre approche sur une application indus-trielle distribuée. Les premiers résultats semblent encourageants concernant l’ana-lyse d’impact et la faculté de définir des règles spécifiques pour certaines catégoriesde langages. Toutefois, sur une application de grande taille, nous atteignons très ra-pidement les limites induites par notre système de visualisation de graphes. Pourremédier à cette limite, nous développons une extension Eclipse pour afficher les im-pacts directement au niveau des fichiers de l’application en utilisant le mécanismede gestion d’erreurs inhérent à Eclipse. De cette manière, les impacts seront donnésau niveau de l’élément du code source. Par conséquent, la visualisation du graphene sera plus visible pour le chargé de l’évolution.

7.2 Perspectives

Notre travail constitue une première étape pour répondre au problème decontrôle de l’évolution des architectures logicielles. Cette étape, loin d’être termi-née, nécessite une validation des applications industrielles de grande taille, afin decompléter le référentiel et d’enrichir la base de règles génériques et spécifiques. Lesétapes suivantes de ce travail définissent des perspectives multiples que nous allonsénumérer selon un critère de complexité croissante.

Dans un premier temps, au niveau de la plate-forme, l’interface graphique devisualisation et de manipulation de graphes sera remplacée au profit de l’éditeurEclipse. Celui-ci sera étendu pour permettre de simuler une opération de modifi-cation directement sur un élément textuel du code à l’aide d’un menu contextuel.Les impacts seront directement indiqués en soulignant les éléments textuels du codeaffectés par la modification.Cette deuxième étape, permettra de rendre transparente l’intégration de nos outilsdans Eclipse, en augmentant ses capacités de raisonnement quant à l’analyse desimpacts d’une modification, sans changer la façon de travailler des utilisateurs.

Dans un second temps, nous souhaitons étudier le processus de propagationd’impact au niveau des différentes configurations de l’architecture. Notre travails’est attaché à considérer uniquement le point de vue structurel d’une architecturelogicielle. La troisième étape serait de fournir des mécanismes pour simuler l’impactdes modifications pendant l’exécution des composants de l’architecture en considé-rant une configuration particulière de ceux-ci. Plusieurs points de vue peuvent alorsêtre étudiés, tels que l’aspect comportemental d’un composant et l’aspect qualitatif.À titre d’exemple, l’analyse d’impact a priori d’une modification d’un composantpourrait s’intéresser à sa performance ou à sa tolérance aux pannes. Des techniquesd’instrumentation, de tests et des modèles de qualité du logiciel (par exemple, un

140 7.2. Perspectives

modèle de métriques) pourraient être spécifiés puis intégrés à notre plate-forme.

Nous avons également commencé un travail concernant le caractère distribué desapplications évolutives. En effet, celles-ci se caractérisent par une dissémination descomposants hétérogènes à travers un réseau et communiquent par le biais de diversprotocoles. Bien souvent, le développement de telles applications est réalisé de ma-nière coopérative par une équipe d’architectes et de développeurs, qui produisent descodes et des spécifications partagés dans un gestionnaire de versions et de configura-tions. Dans de nombreux cas, lors de l’intégration des différentes parties de l’appli-cation pour disposer d’une application distribuée exécutable, de nombreuses erreursde compilations et de dysfonctionnement apparaissent. Nous pensons qu’en faisantcollaborer les environnements Eclipse, il serait envisageable de réduire ces erreurs.Cette collaboration serait basée sur une distribution de la base de connaissances etsur la communication d’agents “intelligents” pour distribuer le processus d’analysed’impact entre les différents environnements de développement. Les agents auraientla charge de communiquer les modifications apportées aux composants ainsi queleurs impacts aux autres agents, qui à leur tour pourraient effectuer une analysed’impact et avertir les agents ainsi que leurs utilisateurs respectifs.

Liste des figures

2.1 Exemple d’architecture avec un ADL . . . . . . . . . . . . . . . . . . . . . 13

2.2 Description d’une représentation AADL . . . . . . . . . . . . . . . . . . . 22

2.3 Extension des composants AADL . . . . . . . . . . . . . . . . . . . . . . . 23

2.4 Représentation graphique du listing 2.1 . . . . . . . . . . . . . . . . . . . 26

2.5 Représentation graphique du listing 2.3 . . . . . . . . . . . . . . . . . . . 30

3.1 Processus de base de la ré-ingénierie . . . . . . . . . . . . . . . . . . . . . 38

3.2 Processus de changement . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

3.3 Processus d’évolution de Rajlich . . . . . . . . . . . . . . . . . . . . . . . 47

4.1 Représentation des composants logiciels de grosse granularité . . . . . . 59

4.2 Représentation des composants logiciels de granularité moyenne . . . . 59

4.3 Représentation des composants logiciels de granularité fine . . . . . . . 60

4.4 ASCM : représentation UML des éléments existants dans les ADLs . . . 64

4.5 Extension de l’élément “Interface du Composant“ du modèle ASCMpour le langage AADL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

4.6 Mapping entre ASCM et SCSM : niveau grosse granularité . . . . . . . . 72

4.7 Mapping entre ASCM et SCSM : niveau moyenne granularité . . . . . . 72

4.8 Exemple de mapping entre ASCM et SCSM . . . . . . . . . . . . . . . . . 73

5.1 Ajouter une interface d’un composant . . . . . . . . . . . . . . . . . . . . 81

5.2 Ajouter une implémentation à un composant . . . . . . . . . . . . . . . . 82

5.3 Ajouter un connecteur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

5.4 Supprimer un connecteur . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

5.5 Supprimer un composant . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

5.6 Supprimer une implémentation d’un composant . . . . . . . . . . . . . . 87

5.7 Modifier la source d’un connecteur . . . . . . . . . . . . . . . . . . . . . . 88

5.8 Modifier la destination d’un connecteur . . . . . . . . . . . . . . . . . . . 89

5.9 Ajouter un port à un composant . . . . . . . . . . . . . . . . . . . . . . . 90

5.10 Supprimer un port d’un composant . . . . . . . . . . . . . . . . . . . . . 91

5.11 Ajouter une propriété à un composant . . . . . . . . . . . . . . . . . . . . 92

5.12 Supprimer une propriété d’un composant . . . . . . . . . . . . . . . . . . 92

5.13 Modifier une propriété d’un composant . . . . . . . . . . . . . . . . . . . 93

5.14 Ajouter un sous-composant à un composant . . . . . . . . . . . . . . . . 94

141

142 Liste des figures

5.15 Supprimer un sous-composant . . . . . . . . . . . . . . . . . . . . . . . . 95

5.16 Changer le type d’un port de connexion . . . . . . . . . . . . . . . . . . . 96

5.17 Exemple de processus de propagation d’impact en appliquant notrealgorithme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

5.18 Intégration du code source dans le processus de propagation d’impact . 107

6.1 Architecture globale du système basé sur l’environnement de dévelop-pement Eclipse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

6.2 Exemple d’un graphe partiel d’une représentation architecturale . . . . 117

6.3 Exemple d’un graphe complet après l’application des règles pour com-pléter la construction du graphe . . . . . . . . . . . . . . . . . . . . . . . 122

6.4 Exemple de menu déroulant associé à un nœud du graphe . . . . . . . . 125

6.5 Exemple de graphe avec une surcharge d’informations encombrant sacompréhension et sa manipulation . . . . . . . . . . . . . . . . . . . . . . 126

6.6 Le graphe après l’exécution de l’opération de modification . . . . . . . . 128

6.7 Le graphe avec intégration du code source . . . . . . . . . . . . . . . . . 130

6.8 Le graphe incluant les représentations ASCM et SCSM après l’exécu-tion de l’opération de suppression . . . . . . . . . . . . . . . . . . . . . . 132

Liste des tableaux

4.1 Tableau comparatif des modèles de composants logiciels : Expressivité des mo-dèles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

4.2 Tableau comparatif des modèles d’évolutions : support à l’évolution . . . . . . 57

4.3 Récapitulatif détaillé des éléments du langage AADL et leur correspondancedans le graphe d’architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

4.4 Liste des assertions simples pour la manipulation du graphe d’architecture . . 70

4.5 Liste des assertions composites pour la manipulation du graphe d’architecture . 70

4.6 Liste des opérations de base s’appliquant sur un graphe . . . . . . . . . . . . . 71

5.1 Liste des opérations de modification affectant l’architecture . . . . . . . . . . . 80

5.2 Liste des assertions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

143

Bibliographie

[AAG93] G. Abowd, R. Allen, and D. Garlan. Using style to understand descrip-tions of software architecture. In Proceedings of SIGSOFT’93 : Founda-tions of Software Engineering, pages 9–20. ACM, 1993. (Cité page 10.)

[AAG95] G. Abowd, R. Allen, and D. Garlan. Formalizing style to understanddescriptions of software architecture. ACM Transactions on Software En-gineering and Methodology, 4(4) :319–364, 1995. (Cité page 11.)

[AB93] R. S. Arnold and S. A. Bohner. Impact analysis - towards a frameworkfor comparison. In ICSM ’93 : Proceedings of the Conference on SoftwareMaintenance, pages 292–301, Washington, DC, USA, 1993. IEEE Com-puter Society. (Cité page 44.)

[AF03] L. F. Andrade and J. L. Fiadeiro. Architecture based evolution of soft-ware systems. In 3rd International School on Formal Methods for the Designof Computer, Communication and Software Systems : Software Architecture,pages 148–181. Springer, 2003. (Cité pages 35 et 41.)

[AG94] R. Allen and D. Garlan. Formalizing architectural connection. In ICSE’94 : Proceedings of the 16th international conference on Software engineering,pages 71–80. IEEE Computer Society Press, 1994. (Cité page 62.)

[Age89] HOOD Working Group European Space Agency. HOOD Reference Ma-nual. September 1989. (Cité page 46.)

[Aji95] S. Ajila. Analyse de l’impact de la modification de logiciel : Problèmes et miseen oeuvre. PhD thesis, Université Henri Poincaré, 1995. (Cité page 46.)

[All97] R. J. Allen. A Formal Approach to Software Architecture. PhD thesis,School of Computer Science, Carnegie Mellon University, Pittsburgh,1997. (Cité pages 4, 16 et 17.)

[arc01] Archware consortium - the eu funded archware - architecting evolvablesoftware project, 2001. (Cité page 55.)

[Arn93] R. S. Arnold. Software Reengineering. IEEE Computer Society Press,1993. (Cité page 37.)

145

146 Bibliographie

[AT02] S. A. Ajila and P. J. Tierney. The foom method - modeling softwareproduct line in industrial settings. In International Conference on SoftwreEngineering Research and Practice (SERP’02), Las Vegas, Nevada, USA,2002. (Cité page 46.)

[Bal97] R. Balzer. Instrumenting, monitoring, debugging software architec-tures, 1997. (Cité page 43.)

[Bar97] S. Barros. Analyse a priori des conséquences de la modification de la modifica-tion de systèmes logiciels : de la théorie à la pratique. PhD thesis, UniversitéPaul Sabatier, Toulouse, 1997. (Cité page 47.)

[Bas] H. Basson. Contôle de l’évolution des logiciels : modélisation pourl’analyse d’impact des modifications - document hdr. (Cité pages 48

et 58.)

[BBE+95] S. Barros, T. Bodhuin, A. Escudie, J. P. Queille, and J. F. Voidrot. Sup-

porting impact analysis : a semi-automated technique and associatedtool. In ICSM ’95 : Proceedings of the International Conference on SoftwareMaintenance, page 42, Washington, DC, USA, 1995. IEEE Computer So-ciety. (Cité page 45.)

[BBHL95] B. W. Boehm, P. K. Bose, E. Horowitz, and M. J. Lee. Software requi-rements negotiation and renegotiation aids : A theory-w based spiralapproach. In ICSE, pages 243–253, 1995. (Cité page 11.)

[BHR84] S. D. Brookes, C. A. Hoare, and A. W. Roscoe. A theory of communica-ting sequential processes. J. ACM, 31(3) :560–599, 1984. (Cité page 17.)

[BMOB04] M. Bouneffa, Y. Maweed, P. M. Oumoumsack, and H. Basson. An archi-tecture recovery process based on graphs and xml. (1) :123–148, 2004.(Cité page 3.)

[BMR+94] C. Bushell, J. D. Mackinlay, W. A. Ruh, A. Spoerri, and J. Tesler. In-

formation visualization : the next frontier. In SIGGRAPH ’94 : Pro-ceedings of the 21st annual conference on Computer graphics and interac-tive techniques, pages 485–486, New York, NY, USA, 1994. ACM. (Citépage 125.)

[Boh02] S. A. Bohner. Extending software change impact analysis into cotscomponents. In SEW ’02 : Proceedings of the 27th Annual NASA GoddardSoftware Engineering Workshop (SEW-27’02), pages 175–182, Washington,DC, USA, 2002. IEEE Computer Society. (Cité page 44.)

[BP89] T. J. Biggerstaff and A. J. Perlis. Software reusability : vol. 1, concepts andmodels. ACM, New York, NY, USA, 1989. (Cité page 37.)

Bibliographie 147

[BS83] B. W. Boehm and T. A. Standish. Software technology in the 1990’s :Using an evolutionary paradigm. 16(11) :30–37, 1983. (Cité page 37.)

[Bul90] F. R. Bull. Intelligence artificielle et bon sens. Masson, Paris, 1990. (Citépage 99.)

[CB91] G. Caldiera and V. R. Basili. Identifying and qualifying reusable soft-ware components. 24(2) :61–70, 1991. (Cité page 37.)

[CHK+01] N. Chapin, J. E. Hale, K. Md. Kham, J. F. Ramil, and W-G. Tan. Types

of software evolution and software maintenance. Journal of SoftwareMaintenance and Evolution : Research and Practice, 13(1) :3–30, 2001. (Citépage 45.)

[CI90] E. J. Chikofsky and J. H. Cross II. Reverse engineering and designrecovery : A taxonomy. IEEE Softw., 7(1) :13–17, 1990. (Cité pages 38

et 61.)

[CJH01] S. Cook, H. Je, and R. Harrison. Dynamic and static views of softwareevolution. In Proceedings of IEEE International Conference on SoftwareMaintenance (ICSM’01), pages 592–601. IEEE Computer Society Press,2001. (Cité page 46.)

[CKKL02] M. A. Chaumun, H. Kabaili, R. K. Keller, and F. Lustman. A changeimpact model for changeability assessment in object-oriented softwaresystems. Sci. Comput. Program., 45(2-3) :155–174, 2002. (Cité page 63.)

[CKR06] S. H. Chang, S. D. Kim, and S. Y. Rhew. A variability-centric approachto instantiating core assets in product line engineering. In JürgenMünch and Matias Vierimaa, editors, PROFES, volume 4034 of LectureNotes in Computer Science, pages 334–347. Springer, 2006. (Cité page 46.)

[CMC96] P. Clements, T. R. Miller, and Lt Col. Coming attractions in software ar-chitecture. Technical report, Software Engineering Institute, 1996. (Citépage 10.)

[CNR90] Y-F. Chen, M. Y. Nishimoto, and C. V. Ramamoorthy. The c infor-mation abstraction system. IEEE Transactions on Software Engineering,16(3) :325–334, 1990. (Cité page 58.)

[Dar92] S. A. Dart. The past, present, and future of configuration manage-ment. In Proceedings of the IFIP 12th World Computer Congress on Algo-rithms, Software, Architecture - Information Processing ’92, Volume 1, pages244–251, Amsterdam, The Netherlands, The Netherlands, 1992. North-Holland Publishing Co. (Cité page 36.)

148 Bibliographie

[Das01a] E. M. Dashofy. A highly-extensible, xml-based architecture descriptionlanguage. In Proceedings of the Working IEEE/IFIP Conference on SoftwareArchitecture, pages 103–112, 2001. (Cité page 54.)

[DAS01b] A. Dey, G. D. Abowd, and D. Salber. A conceptual framework and atoolkit for supporting the rapid prototyping of context-aware applica-tion. Human Computer Interaction, 16 :229–241, 2001. (Cité page 42.)

[DBMB01] L. Deruelle, M. Bouneffa, N. Melab, and H. Basson. An expert system-based change propagation process for web sites maintenance. Ingénieriedes Systèmes d’Information, 6(1) :123–148, 2001. (Cité page 3.)

[Der01] L. Deruelle. Analyse d’impact de l’évolution des applications distribuéesmulti-langages et à bases de données hétérogènes. PhD thesis, Université duLittoral Côte d’Opale, Décembre 2001. (Cité pages 4, 58, 71 et 112.)

[DF06] A-M. Déplanche and S. Faucou. Systèmes temps réel 1 : Techniques de des-cription et de vérification (Chapitre Description d’architectures pour le tempsréel : l’approche AADL). Hermes, Lavoisier, 2006. (Cité page 16.)

[DPR91] A. Dubuque, J-M. Proulx, and S. Rolland. Le projet mobilisateur « lemacroscope informatique» et le génie logiciel, 1991. (Cité page 36.)

[Erl00] L. Erlikh. Leveraging legacy system dollars for e-business. IT Professio-nal, 2(3) :17–23, 2000. (Cité page 35.)

[FBB+03] J-M. Farines, B. Berthomieu, J-P. Bodeveix, , P. Dissaux, P. Farail, M. Fi-

lali, P. Gaufillet, H. Hafidi, J-L. Lambert, P. Michel, and F. Vernadat.The Cotre Project : Rigorous Software Development for Real Time Systems inAvionics. COLNARIC, ADAMSKI, WEGRZYN, novembre 2003. (Citépage 21.)

[FEB06] J. M. Favre, J. Estublier, and M. Blay. L’ingénierie Dirigée par les Modèles :au-delà du MDA. Hermès - Lavoisier, 2006. (Cité page 61.)

[FLV03] H. Feiler, B. Lewis, and S. Vestal. The SAE Avionics ArchitectureDescription Language (AADL) Standard : A Basis for Model-BasedArchitecture-Driven Embedded Systems Engineering. In Proceedingsof the RTAS 2003 Workshop on Model-Driven Embedded Systems, Washing-ton, D.C., May 2003. (Cité pages 4 et 16.)

[FLV04] P. H. Feiler, B. A. Lewis, and S. Vestal. AADL standard SAE Architec-ture Analysis and Description Language. Technical report, Society ofAutomotive Engineers (SAE), November 2004. (Cité page 21.)

[For82] C. Forgy. Rete : A fast algorithm for the many pattern/many objectpattern match problem. Artificial Intelligences, 19(1) :17–37, 1982. (Citépage 114.)

Bibliographie 149

[Gar00] D. Garlan. Software architecture : a roadmap. International Conferenceon Software Engineering, pages 91–101, 2000. (Cité pages 9 et 10.)

[GGM97] J-M. Geib, C. Gransart, and P. Merle. Corba. Des concepts à la pratique.Masson, 1997. (Cité page 19.)

[GHJV95] E. Gamma, R. Helm, R. Johnson, and J. Vlisside. Design Patterns : Ele-ments of Reusable Object-Oriented Software. Addison Wesley, 1995. (Citépage 39.)

[GMW97] D. Garlan, R. Monroe, and D. Wile. Acme : An architecture descriptioninterchange language. In in Proceedings of CASCON’97, pages 169–183,1997. (Cité pages 4, 16 et 18.)

[Got05] G. Goth. Beware the march of this ide : Eclipse is overshadowing othertool technologies. IEEE Software, 22(4) :108–111, August 2005. (Citépage 111.)

[Gro00] IEEE Architecture Working Group. Ieee std 1471-2000, recommen-ded practice for architectural description of software-intensive systems.Technical report, IEEE, 2000. (Cité pages 9, 11 et 61.)

[GS93] D. Garlan and M. Shaw. An introduction to software architecture. InAdvances in Software Engineering and Knowledge Engineering. River Edge,NJ : World Scientific Publishing Company, 1993. (Cité page 10.)

[Gue07] M. K. Guennoun. Architectures Dynamiques dans le Contexte des Appli-cations à Base de Composants et Orientés Services. PhD thesis, UniversitéToulouse III - Paul Sabatier, Mars 2007. (Cité page 62.)

[HB08] M. O. Hassan and H. Basson. Tracing software architecture changeusing graph formalisms in distributed systems. In ICTTA 2008 : 3rd In-ternational Conference on Information & Communication Technologies : FromTheory to Applications, pages 1–6, April 2008. (Cité pages 63 et 65.)

[HC01] G. T. Heineman and W. T. Council. Component-Based Software Enginee-ring : Putting the Pieces Together. Addison-Westley, 2001. (Cité pages 3

et 43.)

[HDB+05] J. Hattat, L. Deruelle, H. Basson, P. Flament, and S. Breuzard. Toward

an algorithm understanding approach for legacy systems renovation.In Proceedings of the 18 th International Conference on Computer Applica-tions in Industry and Engineering (CAINE-2005), pages 67–72, Honolulu,Hawaii, USA., 2005. (Cité page 3.)

[HDB09] M. O. Hassan, L. Deruelle, and H. Basson. Towards a change propa-gation process in software architecture. In 18th International Conference

150 Bibliographie

on Software Engineering and Data Engineering (SEDE-2009), pages 85–90,Las Vegas, Nevada, USA, June 2009. (Cité pages 98 et 112.)

[HL05] L. Hochstein and M. Lindvall. Combating architectural degeneration :a survey. Information and Software Technology, 47(10) :643–656, July 2005.(Cité page 97.)

[HM93] M. J. Harrold and B. Malloy. A unified interprocedural program re-presentation for a maintenance environment. IEEE Trans. Softw. Eng.,19(6) :584–593, 1993. (Cité page 41.)

[IW95] P. Inverardi and A. L. Wolf. Formal specification and analysis of soft-ware architectures using the chemical abstract machine model. IEEETransactions on Software Engineering, 21(4) :373–386, 1995. (Cité pages 43

et 62.)

[Jac98] P. Jackson. Introduction to Expert Systems. Addison-Wesley LongmanPublishing Co., Inc., Boston, MA, USA, 1998. (Cité page 99.)

[Jaz02] M. Jazayeri. On architectural stability and evolution. In Ada-Europe’02 : Proceedings of the 7th Ada-Europe International Conference on ReliableSoftware Technologies, pages 13–23, London, UK, 2002. Springer-Verlag.(Cité page 43.)

[Jon84] T. C. Jones. Reusability in programming : A survey of the state of theart. IEEE Transactions on Software Engineering, 10(5) :488–494, September1984. (Cité page 37.)

[KC03] J. O. Kephart and D. M. Chess. The vision of autonomic computing.Computer, 36(1) :41–50, 2003. (Cité page 42.)

[KGH+94] D. Kung, J. Gao, P. Hsia, F. Wen, Y. Toyoshima, and C. Chen. Change

impact identification in object oriented software maintenance. pages202–211, 1994. (Cité page 63.)

[KOS06] P. Kruchten, H. Obbink, and J. A. Stafford. The past, present, and futurefor software architecture. IEEE Softw., 23(2) :22–30, 2006. (Cité page 9.)

[Law03] J. Law. Whole program path-based dynamic impact analysis. In InProceedings of the International Conference on Software Engineering, pages308–318, 2003. (Cité page 44.)

[LB85] M. M. Lehman and L. A. Belady, editors. Program evolution : processesof software change. Academic Press Professional, Inc., San Diego, CA,USA, 1985. (Cité page 35.)

Bibliographie 151

[Lee98] M. L. Lee. CHANGE IMPACT ANALYSIS OF OBJECT-ORIENTEDSOFTWARE. PhD thesis, George Mason University, Fairfax, Virginia,1998. (Cité page 49.)

[Lew06] A. Lewandowski. Vers de meilleurs supports aux activités coopérativesen accord avec la co-évolution. PhD thesis, Université du Littoral Côted’Opale, Décembre 2006. (Cité page 111.)

[Ley04] F. Leymonrie. ASL language et outils pour les styles architecturaux. Contri-bution a la description d’architectures dynamique. PhD thesis, Universitéde Savoie, Décembre 2004. (Cité page 56.)

[LH95] W. Li and S. Henry. An empirical study of maintenance activities in twoobject-oriented systems. Journal of Software Maintenance, 7(2) :131–147,1995. (Cité page 35.)

[LKA+95] D. C. Luckham, J. J. Kenney, L. M. Augustin, J. Vera, D. Bryan, and

W. Mann. Specification and analysis of system architecture using ra-pide. IEEE Transactions on Software Engineering, 21(4) :336–355, 1995.(Cité pages 4, 11, 16, 18 et 43.)

[LO96] L. Li and A. J. Offutt. Algorithmic analysis of the impacts of changes toobject-oriented software. In In Proceedings of the International Conferenceon Software Maintenance, pages 171–184. IEEE, 1996. (Cité page 97.)

[LOA00] M. Lee, A. J. Offutt, and R. T. Alexander. Algorithmic analysis of theimpacts of changes to object-oriented software. In TOOLS ’00 : Procee-dings of the Technology of Object-Oriented Languages and Systems (TOOLS34’00), page 61, Washington, DC, USA, 2000. IEEE Computer Society.(Cité page 49.)

[LS81] B. P. Lientz and E. B. Swanson. Problems in application software main-tenance. Commun. ACM, 24(11) :763–769, 1981. (Cité page 35.)

[LS98] M. Lindvall and K. Sandahl. How well do experienced software develo-pers predict software change ? Journal of Systems and Software, 43(1) :19–27, 1998. (Cité page 45.)

[M9́8] D. Le Métayer. Describing software architecture styles using graphgrammars. IEEE Trans. Softw. Eng., 24(7) :521–533, 1998. (Cité page 62.)

[Mar91] J. Martin. Rapid application development. Macmillan Publishing Co., Inc.,Indianapolis, IN, USA, 1991. (Cité page 38.)

[Maw07] Y. Maweed. Modélisation architecturale pour la gestion de l’évolution desapplications distribuées. PhD thesis, Université du Littoral Côte d’Opale,Juin 2007. (Cité pages 3 et 61.)

152 Bibliographie

[McI68] M. D. McIlroy. Mass-produced software components. Proc. NATO Conf.on Software Engineering, Garmisch, Germany, pages 88–98, 1968. (Citépage 37.)

[McK84] J. R. McKee. Maintenance as a function of design. In AFIPS ’84 : Pro-ceedings of the July 9-12, 1984, national computer conference and exposition,pages 187–193, New York, NY, USA, 1984. ACM. (Cité page 35.)

[Men01] T. Mens. Transformational software evolution by assertions. Workshopon Formal Foundations of Software Evolution, CSRM 2001, 2001. (Citépage 69.)

[Mey00] B. Meyer. Conception et programmation orientées objet. EYROLLES, Juillet2000. (Cité page 3.)

[MG92a] E. Mettala and M. H. Graham. The domain-specific software archi-tecture program - cmu/sei-92-sr-9. Technical report, Carnegie MellonSoftware Engineering Institute, Juin 1992. (Cité page 11.)

[MG92b] E. Mettala and M. H. Graham. “The Domain-Specific Software Ar-chitecture Program”. In Proceedings of the DARPA Software TechnologyConference Defense Advance Research Projects Agency, 1992. (Cité page 10.)

[MKB+04] R. Morrison, G. Kirby, D. Balasubramaniam, K. Mickan, F. Oquendo,

S. Cîmpan, B. Warboys, B. Snowdon, and R. M. Greenwood. Supportfor evolving software architectures in the archware adl. In WICSA ’04 :Proceedings of the Fourth Working IEEE/IFIP Conference on Software Archi-tecture, pages 69–78. IEEE Computer Society, 2004. (Cité page 56.)

[MT00] N. Medvidovic and R. N. Taylor. A classification and comparison fra-mework for software architecture description languages. IEEE TRAN-SACTIONS ON SOFTWARE ENGINEERING, 26(1) :70–93, 2000. (Citépages 4, 12, 13, 14, 15, 16 et 55.)

[NACO97] G. Naumovich, G. S. Avrunin, L. A. Clarke, and L. J. Osterweil. Ap-plying static analysis to software architectures. In In Proceedings of theSixth European Software Engineering Conference, pages 77–93. Springer-Verlag, 1997. (Cité page 43.)

[NCCR05] J. Nagaoraveen, T. Coupaye, C. Collet, and N. Riviere. Des règles ac-tives au sein d’une infrastructure logicielle autonomique. RENPAR’16/ CFSE’4 / SympAAA’2005 / Journées Composants 2005, (1), 2005. (Citépage 42.)

[Oqu03] F. Oquendo. The archware architecture refinement language - delive-rable d6.1b - archware european rtd project, 2003. (Cité page 56.)

Bibliographie 153

[PB90] S. L. Pfleeger and S. A. Bohner. A framework for software mainte-nance metrics. In Proceedings of the International Conference on SoftwareMaintenance, pages 320–327, November 1990. (Cité page 44.)

[Per92] D. E. Perry. Foundations for the study of software architecture. ACMSIGSOFT Software Engineering Notes, 17 :40–52, 1992. (Cité page 10.)

[PF05] P. Gaufillet P. Farail. Topcased — un environnement de développementopen source pour les systèmes embarqués, Mai 2005. (Cité page 21.)

[Raj97a] V. Rajlich. A model for change propagation based on graph rewri-ting. In ICSM ’97 : Proceedings of the International Conference on SoftwareMaintenance, pages 84–91. IEEE Computer Society, Octobre 1997. (Citépages 47, 58 et 63.)

[Raj97b] V. Rajlich. Propagation of change in object oriented programs, 1997.(Cité page 97.)

[Rek85] M. Rekoff. On reverse engineering. IEEE Transactions on Systems, Manand Cybernetics, 3/4 :244–252, 1985. (Cité page 37.)

[RHMRM04] R. Roshandel, A. Van Der Hoek, M. Mikic-Rakic, and N. Medvidovic.Mae - a system model and environment for managing architecturalevolution, 2004. (Cité page 54.)

[RJB05] J. Rumbaugh, I. Jacobson, and G. Booch. The unified modeling languagereference manual. Addison-Wesley, 2005. (Cité page 20.)

[RKK06] A. E. Rugina, K Kanoun, and M Kaâniche. AADL-based DependabilityModelling. Technical report, LAAS - CNRS, Avril 2006. (Cité page 28.)

[RPTU84] C. V. Ramamoorthy, A. Prakash, W-T. Tsai, and Y. Usuda. Softwareengineering : Problems and perspectives. Computer, 17(10) :191–209,1984. (Cité page 36.)

[RRST05] X. Ren, B. G. Ryder, M. Stoerzer, and F. Tip. Chianti : a change impactanalysis tool for java programs. In ICSE ’05 : Proceedings of the 27th in-ternational conference on Software engineering, pages 664–665, New York,NY, USA, 2005. ACM. (Cité page 48.)

[Sac09] Pierre Marie Oum Oum Sack. Contribution à l’étude de la qualité du lo-giciel : Approche à base d’apprentissage automatique de transformation demodèles. PhD thesis, Université du Littoral Côte d’Opale, Janvier 2009.(Cité page 41.)

[SAE06a] Architecture Analysis and Design Language (AADL), Annex Volume1, Annex E : Error Model Annex, 2006. (Cité page 28.)

154 Bibliographie

[SAE06b] SAE Architecture Analysis and Design Language (AADL) Annex D :Language Compliance and Application Program Interface, 2006. (Citépage 28.)

[SDK+95] M. Shaw, R. DeLine, D. V. Klein, T. L. Ross, D. M. Young, and G. Zeles-

nik. Abstractions for software architecture and tools to support them.IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, 21 :314–335,1995. (Cité pages 4, 16, 19 et 43.)

[SPL03] R. C. Seacord, D. Plakosh, and G. A. Lewis. Modernizing Legacy Sys-tems : Software Technologies, Engineering Process and Business Practices.Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA,2003. (Cité page 35.)

[SRW93] J. A. Stafford, D. J. Richardson, and A. L. Wolf. Aladdin : A tool forarchitecture-level dependence analysis of software. Technical report cu-cs-858-98, University of Colorado at Boulder, Avril 1993. (Cité page 43.)

[SRW97] J. A. Stafford, D. J. Richardson, and A. L. Wolf. Chaining : A softwarearchitecture dependence analysis technique, 1997. (Cité page 43.)

[STO06] N. Sadou, D. Tamzalit, and M. Oussalah. Saev, une solution à l’évolu-tion structurelle dans les architectures logicielles, 2006. (Cité pages 56

et 98.)

[Swa76] E. B. Swanson. The dimensions of maintenance. In ICSE ’76 : Pro-ceedings of the 2nd international conference on Software engineering, pages492–497. IEEE Computer Society Press, 1976. (Cité page 35.)

[Szy98] C. Szyperski. Component Software : Beyond Object-Oriented Programming.Addison-Wesley Longman Publishing Co., Inc., New York, NY, 1998.(Cité page 43.)

[Tae00] G. Taentzer. Agg : A tool environment for algebraic graph transforma-tion. In in AGTIVE, ser. Lecture Notes in Computer Science, pages 481–488.Springer, 2000. (Cité page 57.)

[TM94] R. J. Turver and M. Munro. An early impact analysis technique forsoftware maintenance. Journal of Software Maintenance : Research andPractice, 6 :35–52, 1994. (Cité page 44.)

[TMA+95] R. N. Taylor, N. Medvidovic, M. K. Anderson, J. E. Whitehead, and J. E.

Robbins. A component- and message-based architectural style for guisoftware. In ICSE ’95 : Proceedings of the 17th international conference onSoftware engineering, pages 295–304, New York, NY, USA, 1995. ACM.(Cité page 54.)

Bibliographie 155

[Ver06] T. Vergnaud. Modélisation des systèmes temps-réel répartis embarqués pourla génération automatique d’applications formellement vérifiées. PhD the-sis, Ecole Nationale Supérieure des Télécommunications de Paris, Dé-cembre 2006. (Cité page 21.)

[Ves98] S. Vestal. Software programmer’s manual for the honeywell aerospacecompiled kernel (metah language reference manual). Technical report,Honeywell Technology Center, Minneapolis, USA, 1998. (Cité page 21.)

[W3C04] World wide web consortium (w3c). extensible markup language (xml)1.0 (third edition), 2004. (Cité page 21.)

[WC01] B. Westfechtel and R. Conradi. Software architecture and softwareconfiguration management. In Bernhard Westfechtel and Andrévan der Hoek, editors, SCM, volume 2649 of Lecture Notes in Compu-ter Science, pages 24–39. Springer, 2001. (Cité page 39.)

[YCM78] S. S. Yau, J. S. Colofello, and T. M. McGrogor. Ripple effect analysis forsofotware maintenance. Computer Software and Applications Conference,COMPSAC ’78., pages 60–65, 1978. (Cité page 40.)

[Zen02] M. Zenger. Extensibility in the large. First Doctoral Workshop on GlobalComputing, Juin 2002. (Cité page 43.)

Contribution à l’analyse d’impact des modifications des architectureslogicielles

Résumé Le travail développé dans cette thèse fait partie des travaux consacrés à lagestion de l’évolution des architectures logicielles, à l’analyse d’impact a priori surl’architecture ainsi que sur le code source correspondant à la description architectu-rale. Nous avons proposé dans ce travail un modèle pour la représentation des in-formations communes à la plupart des langages de description d’architecture. Nousavons également établi des liens entre le niveau de représentation architecturale etcelui du code source. Notre modélisation repose sur une formalisation à base degraphe typé et attribué, dont les nœuds et les arcs représentent respectivement leséléments extraits du logiciel et les relations entre eux. Nous avons défini des opé-rations de modifications exprimées d’une manière assertionnelle. L’exécution de cesopérations de modification ainsi que la propagation de leurs impacts sont assuréespar un système à base de connaissances. Les fonctionnalités que l’on vient de décriresont supportées par une plate-forme réalisée sous la forme de plusieurs extensionsintégrés à l’environnement Eclipse et entièrement développée en Java. Elle fournitune interface utilisateur permettant la visualisation des représentations logiciellesainsi que de la propagation de leurs impacts de modification. Les règles du systèmeexpert sont exprimées moyennant le système de gestion de règles métier DROOLS.

Mots-clés Architecture logicielle, Evolution, Analyse d’impact de modification,Modélisation du logiciel, Théorie des graphes, Système expert.

Contribution to change impact analysis of software architecture

Abstract The work developed in this thesis deals with software architecture evo-lution, the architectural impact analysis and the impact analysis on the source codecorresponding to the architectural description. We proposed in this work a model forrepresenting common elements for the most of architecture description languages.We estabilished links between architectural and source code representation. Our mo-delisation is based on the use of the graph formalism where nodes and arcs representrespectively the software elements and their links. We proposed a set of modificationoperations that are expressed by assertions. A knowledge based system implementsthe change operations and their impacts. These features are implemented in a plat-form entirely developed in Java and integrated as plugins into Eclipse. This platformprovides a user interface for the graph visualisation and for browsing the changeimpact propagation. Expert system rules are developed using the business rule ma-nagement system DROOLS.

Keywords Software architecture, Evolution, Impact Analysis, Software modelisa-tion, Graph theory, Expert system.

Documents

Thèse - LISIC · 2013-06-06 · Ahmad, Mahmoud, Ali, Mokhtar. La liste est longue, et je demande pardon par avance à tous ceux que j’aurais oubliés. Qu’ils trouvent ici le