Modèle d’évolution architecturale à base de
3.1 Vers le concept de style d’évolution
Nous avons puisé notre inspiration dans la notion de style architectural que l’on trouve dans le domaine des architectures logicielles. Notre objectif n’est pas d’encapsuler de l’expertise pour la conception, mais plutôt de l’expertise pour l’évolution. C’est ainsi que nous proposons le concept de style d’évolution. Le terme "style" véhicule une charge sémantique forte et nous discutons ci-après de la légitimité d’une telle notion pour aborder le problème de l’évolution architecturale.
3.1.1
Thésaurisation, extraction et représentation de l’évolution
Notre recherche vise à thésauriser les expertises pour faciliter l’évolution dans les architec- tures logicielles à travers leur réutilisation. Pour atteindre cet objectif, il est nécessaire d’extraire l’évolution pour pouvoir la représenter dans un formalisme donné. La thésaurisation, l’extrac- tion ainsi que la représentation de l’évolution sont les pierres angulaires de la réutilisation de l’évolution.
3.1.1.1 Thésaurisation de l’évolution
L’idée de se constituer ses propres bibliothèques d’éléments réutilisables n’est pas nouvelle dans le monde des produits. En revanche, elle l’est beaucoup moins dans le monde des proces- sus, et tout simplement inexistante dans le domaine de l’évolution logicielle. Dans ce dernier cas, l’objectif est de thésauriser les savoir et savoir-faire des personnes ayant déjà fait face à des évolutions, en vue de les réutiliser dans des situations similaires. Pour une entreprise de développement logiciel, disposer d’une bibliothèque d’évolutions déjà validées améliore la qua- lité du résultat et donne un avantage concurrentiel certain. Néanmoins, cette formule exige de mettre en place une classification claire et évolutive pour éviter les doublons et éviter le temps perdu en recherches infructueuses. En somme, l’efficacité de la réutilisation dépendra aussi de l’infrastructure de réutilisation proposée.
3.1.1.2 Extraction de l’évolution
Nous considérons que tout élément architectural possède sa propre structure, ses comporte- ments mais aussi ses possibilités d’évolution dans l’avenir. Or, nous observons que la composante évolution est traditionnellement amalgamée dans la composante comportement, entravant de ce fait la possibilité de la réutiliser. A la place, nous suggérons de décliner le comportement en deux types : le comportement stable (steady-state behavior) qui décrit des services rendus et le comportement d’évolution (evolution behavior) qui porte sur la structure et/ou sur le comporte- ment stable. Nous rappelons que nous nous intéressons ici à l’évolution de la structure. Comme l’illustre la Figure 3.1, nous prônons l’extraction de l’évolution en tant que composante à part entière d’un élément architectural.
En procédant de la sorte, il devient possible d’analyser et de modéliser l’évolution d’un sys- tème à l’instar de ce qui est entrepris pour le système lui-même. Par conséquent, nous suggérons d’intégrer la subdivision suivante dans un modèle de développement :
– Analyse & conception générale du système : délimiter le problème à résoudre en énumérant un ensemble d’exigences. Puis, déterminer les composants ou les modules nécessaires pour créer le domaine des applications. Cette tâche est confiée à un ou plusieurs architectes d’applications.
ÍÎÏÐÑÒÓÏÒÔÎÕÖ×ÖÓØÓÙÒ
ÚÒÎÔÏÒÔÎÓ ÛÓÐÕÜÑÝÎ ×ÜÝÖÔÒÑÝÙ
Figure 3.1 – Les trois composantes d’un élément architectural : structure, comportement et évolution.
– Analyse & conception de l’évolution du système : déterminer l’éventail des évolutions pos- sibles de chaque composant. Il s’agit de préparer le système à s’adapter à des situations attendues ou inattendues par le biais de moyens prévus. Cette tâche est confiée à un ou plusieurs architectes d’applications évolutives.
3.1.1.3 Représentation de l’évolution
La structure proposée doit être vue comme un réceptacle de connaissances, de compétences, propre à prendre à son compte certains choix et certaines tâches d’évolution. C’est ainsi que la notion de style d’évolution émerge et que nous suggérons de représenter par les éléments suivants :
– son type : la définition abstraite du style,
– son implémentation : la mise en oeuvre du style,
– son instance : une évolution particulière est un processus exécutable, instance d’un type de style.
La spécification d’un style d’évolution repose d’abord et essentiellement sur son type. En effet, nous n’examinons pas une par une toutes les évolutions concrètes de l’architecture mais travaillons directement sur les archétypes d’évolution qui tiennent lieu de toutes les évolutions possibles. Nous raisonnons ainsi sur des intentions et non des extensions. Dans le reste de ce manuscrit, si aucune précision n’est donnée, le terme "style d’évolution" fera implicitement référence à son type.
3.1.2
Points de vue et styles pour l’évolution d’architectures
Il y a plusieurs vues, tout comme il y a plusieurs structures, chacune avec ses propres ob- jectifs et ses propres orientations dans la compréhension du système. Ainsi, une description architecturale sélectionne un ou plusieurs point de vue. Ce choix dépend des préoccupations des intervenants. Nous donnons une idée de la relation entre les points de vues et les styles dans une architecture par la Figure 3.2.
Nous rappelons qu’une vue est une représentation d’une architecture dans la perspective d’un ensemble de préoccupations connexes (IEEE Std 1471, [IEE00]). Cette représentation comprend un ensemble d’éléments du système et les relations qui leur sont associées. Les types d’éléments et les relations ainsi que d’autres méta-informations dans les vues sont décrites par les points de vue (IEEE Std 1471, [IEE00]) afin de documenter et de communiquer sur les vues sans ambiguïtés. Par conséquent une vue est une instance d’un point de vue pour un système particulier car
Þßàá âãäåæä çâèéä
êæä çâèéäëìíé î
Figure 3.2 – Vues, points de vue, et styles (inspiré de [AZ05])
les éléments et les relations contenus dans la vue sont des instances des types d’éléments et de relations correspondant contenus dans le point de vue. Un style, d’un autre coté, définit également des types d’éléments et de relations qui travaillent ensemble afin de résoudre une classe de problèmes dans une perspective. Un style peut être considéré comme une spécialisation d’un point de vue puisque il offre des sémantiques spécifiques aux types d’éléments et de relation et détermine leur utilisation.
La vue structurelle et la vue comportementale sont des exemples de vues importantes d’une architecture logicielle. La première décrit comment un système est structurellement décomposé en composants et connecteurs. La seconde décrit le comportement des composants et des connecteurs et la façon dont ils interagissent ensemble. Dans la vue structurelle, nous pouvons appliquer les styles structuraux blackboard ou pipe&filter par exemple. Dans la vue comportementale, nous pouvons appliquer les styles comportementaux broadcast ou peer-to-peer par exemple1. A notre
connaissance, la vue évolutive de l’architecture n’a jamais été considérée de façon explicite. En toute logique, nous suggérons appliquer dans cette vue des styles d’évolution. Nous proposons de définir un style d’évolution comme suit :
Un style d’évolution capture une manière caractéristique de procéder à l’évolution de tout ou partie d’une architecture logicielle. Il sert de guide pour un architecte qui doit alors se conformer au style.
Cette définition éclaire notre volonté à traiter le problème de l’évolution architecturale par les styles. Dans la section suivante, nous proposons un nouveau modèle d’évolution, baptisé SAEM, reposant sur la notion de style d’évolution.