These

cole Centrale de Nantes
Universit de Nantes
cole des Mines de Nantes
COLE DOCTORALE STIM SCIENCES ET TECHNOLOGIES DE LINFORMATION ET DES MATRIAUX
Anne 2009
No attribu par la bibliothque
Styles dvolution dans les architectures logicielles

tel-00459925, version 1 - 25 Feb 2010
THSE pour obtenir le grade de DOCTEUR DE LUNIVERSIT DE NANTES Discipline : INFORMATIQUE prsente et soutenue publiquement par
Olivier L E G OAER
le 9 Octobre 2009 au LINA devant le jury ci-dessous
Prsident : Rapporteurs : Examinateurs: Pr. Laurent Granvilliers Philippe Aniort, Professeur Henri Basson, Professeur Benoit Baudry, Charg de Recherche Mourad Oussalah, Professeur Abdelhak Seriai, Matre de confrences Dalila Tamzalit, Matre de confrences Universit de Nantes Universit de Pau Universit du Littoral INRIA Rennes I Universit de Nantes Universit de Montpellier Universit de Nantes
Directeur de thse : Pr. Mourad-Chabane Oussalah Encadrants de thse : Dr. Dalila Tamzalit et Dr. Abdelhak Seriai Laboratoire : Laboratoire dInformatique de Nantes Atlantique
No ED 503-060
tel-00459925, version 1 - 25 Feb 2010
STYLES DVOLUTION DANS LES ARCHITECTURES LOGICIELLES
Evolution styles within software architectures
tel-00459925, version 1 - 25 Feb 2010
Olivier Le Goaer
favet neptunus eunti
Universit de Nantes
Olivier Le Goaer Styles dvolution dans les architectures logicielles xvi+156 p.
tel-00459925, version 1 - 25 Feb 2010
A Ce document a t prpar avec L T EX2 et la classe these-IRIN version 0.92 de lassociation de jeunes chercheurs en informatique LOGIN, Universit de Nantes. La classe these-IRIN est disponible ladresse :
http://login.irin.sciences.univ-nantes.fr/
Impression : these.tex 12/11/2009 13:42 Rvision pour la classe : $Id: these-IRIN.cls,v 1.3 2000/11/19 18:30:42 fred Exp
Remerciements
Au terme de ces quatre annes de thse passes au LINA, cest avec une immense joie que jcris ces quelques lignes de remerciements. Je commencerais par remercier Mourad Oussalah, mon directeur de thse, pour mavoir donn la chance de faire une thse sous sa direction. Il a cru en mes capacits, et il ma donn les opportunits pour dvelopper et prouver mes comptences. Jai souvent eu du mal croire en mon travail, ayant toujours le sentiment que je pouvais en faire plus. Le recul me donne prsent la mesure de ce que jai pu accomplir sous sa direction. Jaimerais remercier tout aussi cordialement mes encadrant(e)s de thse, Dalila Tamzalit et Abdelhak Seriai. Ils mont apport tous les conseils et les encouragements dont a besoin un doctorant pour achever sa formation la recherche dans les meilleures conditions qui soient. Leurs conseils et leur vigilance mont accompagn tout au long de cette aventure. Jaimerais exprimer ma gratitude Messieurs Philippe Aniort et Henri Basson pour avoir consacr un temps prcieux la lecture dtaille de mes travaux, et Messieurs Benoit Baudry et Laurent Granvilliers pour mavoir fait lhonneur de participer mon jury de soutenance. Dautre part, rien naurait t possible sans leervescence intellectuelle et amicale qui anime le LINA. Cest ainsi que tout naturellement, je remercie non seulement lensemble des chercheurs seniors, des doctorants, mais aussi lensemble des personnels du laboratoire qui ont apport, directement ou indirectement, leur part de contribution ce manuscrit, par leurs comptences, leur disponibilit et leur gentillesse. Jassocie ces remerciements les membres de lIUT de Nantes pour lambiance chaleureuse et pour les nombreux changes passionns et passionnants en salle des profs . Jai trouv dans cet tablissement toutes les conditions pour mpanouir dans le mtier denseignant. Sur un plan plus personnel, je tiens remercier mes parents, pour leur soutien sans faille et leur aide. Un remerciement particulier Sophie, qui ma toujours soutenu et qui ma permis de tenir le cap jusquau bout, mme dans les moments diciles. Jai normment appris pendant ces quatre ans, tant sur le plan scientique que sur lorganisation de la vie dun chercheur, la manire dcrire une publication et de valoriser son travail. Ce manuscrit de thse marque la n dun chemin sinueux mais nest que le commencement dune route encore plus longue . . .
tel-00459925, version 1 - 25 Feb 2010
tel-00459925, version 1 - 25 Feb 2010
Sommaire
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii 1 Architecture logicielle : tat du domaine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 2 volution architecturale : analyse et synthse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 3 Modle dvolution architecturale base de style . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 4 Bibliothques pour les styles dvolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 5 Ralisations et exprimentations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .89 Conclusion et perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
tel-00459925, version 1 - 25 Feb 2010
Bibliographie. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .115 Rfrences hypertextes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 Liste des tableaux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 Table des gures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 Table des exemples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 Table des matires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 A Rfrentiels de comparaison pour lvolution base architecture . . . . . . . . . . . . . 137 B Algorithmes pour le raisonnement classicatoire . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 C Le prototype COSAStudio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
tel-00459925, version 1 - 25 Feb 2010
Introduction
Cadre de la thse
Lobjectif de larchitecture logicielle est dorir une vue densemble et un fort niveau dabstraction an dtre en mesure dapprhender un systme logiciel [GS93]. Larchitecture propose une organisation grossire du systme comme une collection de pices logicielles [PW92]. Clairement, la discipline de larchitecture logicielle a favoris la modlisation de systmes logiciels de plus en plus complexes. Cet accroissement de la complexit sest vu tout naturellement accompagn de questions cruciales sur lvolution des architectures. Lvolution constitue laspect vie dun systme. Ce dernier nest pas g dans le temps : il volue. Si on porte cette remarque sa conclusion logique, larchitecture du systme doit aussi voluer, sadapter. Lvolution traite dans ce travail vise spciquement les changements de la structure de systmes complexes lchelle de leur architecture. On parlera ainsi dvolution architecturale. Cependant, lutilisation de larchitecture logicielle dans le dveloppement dapplications "grandeur relle" a rvl rapidement des interrogations : est-il possible de faire voluer larchitecture selon des rgles ? existe-t-il des meilleures pratiques ? comment ne pas rinventer la roue chaque fois ? En eet, lorsquun architecte fait face un besoin dvolution, il est probable que des situations similaires aient t rsolues dans dautres cas. Cette vision suggre que lon peut identier des volutions rutilisables dune architecture une autre. Une telle approche de lvolution doit permettre de : identier le problme dvolution rsoudre par capitalisation et organisation dexpriences, proposer une solution possible et normalement correcte pour y rpondre, orir les moyens dexploiter cette solution dans un contexte prcis. Dans le cadre de cette thse, nous nous intressons spciquement aux architectures logicielles base de composants [GS93, BCK98]. Ces dernires reposent sur une dcomposition du systme en un ensemble de composants (units de calcul ou de stockage) qui communiquent entre eux par lintermdiaire de connecteurs (units dinteraction). Pour asseoir le dveloppement de telles architectures, il est ncessaire de disposer de notations formelles et doutils danalyse de spcications architecturales. Les langages de description darchitecture (en anglais, les ADLs : Architecture Description Languages ) constituent une bonne rponse. La communaut acadmique a propos ces dernires annes un nombre important dADLs pour dcrire et raisonner sur les architectures logicielles. Notre travail consiste explorer la notion de rutilisation pour lvolution darchitectures logicielles dcrites laide des ADLs. Le mtier darchitecte est au cur de notre problmatique puisque cest son exprience et sa comptence qui alimente le processus de rutilisation. Pour capitaliser cette exprience, nous proposons le concept de style dvolution. Un style dvolution peut tre vu comme une solution rutilisable un problme dvolution bien identi, et r-applicable direntes situations. En abordant ainsi le problme de lvolution dans les architectures base de composants travers lexploitation de lexprience passe des architectes, cette thse se place au carrefour de lingnierie du logiciel et de lingnierie de la connaissance. vii
tel-00459925, version 1 - 25 Feb 2010
viii
Introduction
Problmatique aborde
Les systmes logiciels ncessitant une volution adoptent gnralement des approches ad-hoc et spciques lapplication considre. Ces systmes devraient bncier dune approche dvolution systmatique, fonde sur des principes, et supporte par une infrastructure rutilisable [OMT98]. En dautres termes, lvolution doit tre une discipline part entire, munie de ses concepts, ses meilleurs pratiques, ses mthodologies et ses outils. Lvolution dun systme ne doit pas tre empirique mais doit suivre des prceptes dingnierie, limage de ce qui se fait dj pour la construction du systme lui-mme. Cest presque un corollaire de dire que la dicult et les cots faramineux des activits dvolution sont ds essentiellement au manque de modles et de dmarches proposs, cest--dire au manque de cadre mthodologique. Pour tenter de rpondre ces ds, lvolution est devenue un domaine de recherche part entire, aujourdhui bien accept dans lingnierie logicielle. On trouve de nombreuse confrences et ateliers ddis ce sujet. Bien que tous ces eorts de recherche se situent dans le champ de lvolution, les approches retenues pour aborder le problme de lvolution logicielle divergent. De manire gnrale, laccroissement de la complexit dans les systmes logiciels a ncessit une prise de recul face aux lments en prsence et fait apparatre un fort besoin dabstraction pour pouvoir raisonner de manire correcte, sans se noyer sous les dtails. En toute logique, lvolution logicielle devrait bncier du mme traitement an de supporter une meilleure comprhension et une meilleure communication de cette notion. Le problme fondamental est que la connaissance ncessaire pour mener terme une volution, quand elle existe, reste cantonne lunivers du mental. En eet, une meilleure comprhension des exigences et de meilleures mthodes de modlisation et de conception nous permettent de faire voluer un systme. En partant de ce constat, notre ide directrice est de proposer un formalisme capable de recueillir le rsultat de lextraction de ce type de connaissance. Lacte de formalisation est ncessaire pour pouvoir capitaliser lvolution et in-ne la rutiliser. La connaissance ainsi extraite peut tre mise disposition, pour soi ou pour dautres, en vue dacclrer et damliorer la qualit des activits dvolution logicielle. Dune part, notre approche suggre lexistence de sorte de "patterns" pour lvolution, applicables des familles de systmes logiciels partageant des caractristiques communes. En eet, nous pensons que lvolution logicielle doit se focaliser sur des familles de logiciels plutt que sur des produits logiciels individuels. Ceci requiert de penser en termes de familles dvolutions plutt quen termes dvolutions singulires. Dautre part, nous considrons que lvolution dun systme doit tre aborde un haut-niveau dabstraction. Notre vision est enracine dans largument avanc par Jazayeri Un systme logiciel est plus que du code source ; les modles et mta-modles sont importants pour lvolution logicielle [Jaz05]. Il faut bien dire que cette approche va contre courant des pratiques industrielles centres sur le code, considr comme tant le seul reprsentant able du logiciel et donc le seul artefact digne de focaliser les eorts pour lui permettre dvoluer. En ce qui nous concerne, nous sommes convaincus que les architectures logicielles base de composants orent des fondations saines pour aborder le problme de lvolution logicielle. Dans ce scnario, les responsabilits du mtier darchitecte logiciel sont largies puisque des comptences relatives lvolution sont exiges. La problmatique de cette thse consiste donc proposer aux architectes une mthode dingnierie pour lvolution architecturale. La composante principale dans une mthode dingnierie est la notion de modle ; la deuxime composante essentielle est la notion de dmarche. Un modle dvolution puissant doit orir larchitecte les lments ncessaires la modlisation de
tel-00459925, version 1 - 25 Feb 2010
Introduction
ix
sa connaissance des concepts, des rgles, des relations, etc., qui entrent en jeu dans le processus dvolution. Il doit aussi pouvoir utiliser ecacement le savoir-faire qui a t acquis et raisonner avec lui pour rsoudre des problmes dvolution et pour acqurir de nouvelles connaissances. Finalement, le modle dvolution doit tre capable dexpliquer le raisonnement suivi pour achever une tche dvolution. La dmarche doit venir en accompagnement du modle, en tant que processus grce auquel seectue le travail de modlisation. Ces deux aspects, modle et dmarche, constituent les contributions principales de cette thse, prsentes ci-aprs.
Contributions
La premire contribution que nous proposons est le modle dvolution SAEM (Style-based Architectural Evolution Model), reposant sur la modlisation base de styles pour dcrire des volutions logicielles rcurrentes. La nouveaut principale de ce modle est de proposer le concept de style dvolution, dot de qualits descriptive et prescriptive de lvolution. La premire qualit sert vhiculer des connaissances et partager un vocabulaire dvolution commun entre les architectes. La seconde qualit sert guider larchitecte dans son activit dvolution, en contraignant lespace des solutions possibles. Aussi, le modle SAEM propos supporte la rutilisabilit en augmentant lextensibilit, lvolutivit et la compositionnalit des volutions modlises base de styles. Nous proposons un formalisme de description des concepts des styles dvolution baptis "modle en Y". Ce modle a pour socle un tryptique reprsentant trois aspects importants : le domaine, lentte et la comptence. Ces aspects reprsentent successivement tout ce qui est li aux lments volutifs dune architecture, aux oprations dvolution sur ces lments et aux mthodes utilises pour achever ces oprations. La seconde contribution concerne une dmarche dlaboration de bibliothques pour les styles dvolution, avec pour objectif de remplacer les volutions que lon cherche dvelopper ex nihilo par une rutilisation de lexistant. Cette dmarche inclut dirents niveaux dintervention correspondants des acteurs distincts. Le modle MY unie les concepts du paradigme des styles dvolution en supportant trois niveaux de modlisation : mta-style dvolution, type de style dvolution, et instance de style dvolution. Ce modle amliore la rutilisation des styles dvolution en supportant une bibliothque multi-hirarchique pour les trois niveaux de modlisation. Une infrastructure de rutilisation est btie spciquement au dessus de la bibliothque de niveau type an den contrler le peuplement et linterrogation par les architectes, selon que lon se place du point de vue du fournisseur ou du consommateur dvolutions. Compte tenu de la structure hirarchique de la bibliothque, le fonctionnement de linfrastructure sappuie sur des raisonnements de nature classicatoire.
tel-00459925, version 1 - 25 Feb 2010
Organisation du document
Le corps de ce manuscrit est organis comme suit : Le chapitre 1 pose le lit de notre travail et propose un tat du domaine de larchitecture logicielle, notamment dans ses aspects ncessaires notre travail. Le chapitre dbute sur une rtrospective de larchitecture logicielle, depuis les premires intuitions des annes 70 jusqu son closion en tant que discipline dans les annes 90. Malgr le gain en popularit de larchitecture
Introduction
logicielle ces dix dernire annes, le vocabulaire est souvent mal utilis et les objectifs mal compris. Ainsi, il est utile de rappeler quelques dnitions notables de larchitecture logicielle proposes dans la littrature et de revenir sur la notion de style architectural qui a profondment inuenc notre travail. Le chapitre se poursuit avec les travaux mens sur les langages de description darchitectures logicielles (les ADLs). Le chapitre se termine par lemploi dune technique de mta-modlisation pour la description dune architecture logicielle, qui sera prendre en compte lorsque la problmatique de lvolution sera aborde. Le chapitre 2 cherche situer le contexte du travail travers notre motivation et les avantages traiter lvolution un haut-niveau dabstraction comme celui oert par les architectures logicielles. Puis, nous proposons de caractriser ce que lon peut attendre dun modle dvolution laide dune pyramide de besoins. De la base au sommet de cette pyramide, on trouve direntes proccupations dimportance dcroissante. Muni de ce cadre de comparaison, nous tudions neuf modles dvolution reprsentatifs des coles acadmiques amricaine, europenne et franaise. De cette tude nous faisons ressortir un certain nombre de limitations qui vont nous permettre de guider la proposition de notre propre modle dvolution. Le chapitre 3 dcrit notre modle dvolution en rponse aux limitations identies dans les approches tudies. Ce modle baptis SAEM a pour objectif daborder le problme de lvolution architecturale sur la base du concept de style. Les styles dvolution sont des citoyens de premire classe, pouvant ainsi tre manipuls. Ils sont comparables des patterns pour lvolution, spcis une seule fois, mais rutilisables linni sur des architectures logicielles. Le cur de SAEM est prsent sous la forme dun mta-modle dont les concepts et les mcanismes sont dtaills indpendamment de tout ADL. Nous introduisons un formalisme de reprsentation des styles dvolution baptis MY. Ce formalisme a pour socle une reprsentation triptyque formant les branches dun Y. Nous concluons ce chapitre en valuant notre propre modle dvolution SAEM travers son positionnement dans la pyramide des besoins propose au chapitre prcdent. Le chapitre 4 fait tat dune dmarche pour guider larchitecte dans son processus de modlisation de lvolution selon SAEM, ainsi que de la rutilisation des styles dvolution. Sur la base du formalisme MY, nous expliquons comment il est possible de construire des bibliothques pour les styles dvolution. Ces bibliothques stockent des lments rutilisables dirents niveaux de modlisation dans lobjectif commun dune approche pour et par la rutilisation, qui sont les deux faces dune mme pice. Nous dcrivons une infrastructure de rutilisation capable dexploiter les styles dvolution ainsi capitaliss. Le cur oprationnel de linfrastructure repose sur deux techniques de raisonnement par classication. Le chapitre 5 vise projeter SAEM spciquement sur COSA, un ADL dvelopp par notre quipe et mixant des mcanismes objets avec des concepts des architectures logicielles. COSA savre tre une structure daccueil idale pour SAEM puisque tous deux partagent des mcanismes oprationnels communs. La nalit de cette projection est dassurer limplmentation des styles dvolution sur une plateforme technologique cible. Puis, nous menons une exprimentation de COSA et de SAEM dans le cadre du projet industriel ZOOM. Ce projet vise la conception et lvolution darchitectures de systmes navals complexes. Lexprimentation se concentre sur les rseaux de tuyauterie, o un consultant expert mtier est intervenu pour nous assister.
tel-00459925, version 1 - 25 Feb 2010
Introduction
xi
Plusieurs annexes sont galement fournies en n de document. Lannexe 1 propose une tude complmentaire de trois rfrentiels issus de la littrature et ddis lvolution base architecture. Lannexe 2 prsente les algorithmes utiliss pour mettre en uvre un raisonnement classicatoire. Ces algorithmes sont simples mais mritent dtre mentionns. Lannexe 3 revient sur le dveloppement de loutil COSAStudio et donne un aperu des choix et solutions techniques retenues. Nous rsumons la structuration de la thse dans le schma 1.1.
tel-00459925, version 1 - 25 Feb 2010
Figure 1.1 Reprsentation schmatique de la structure de cette thse.
xii
Introduction
Liste des publications obtenues

Confrences internationales avec comit de lecture et Actes
Olivier Le Goaer, Dalila Tamzalit, Mourad Oussalah, and Abdelhak Seriai. Evolution Shelf : Reusing Evolution Expertise within Component-Based Software Architectures. In The 32nd Annual IEEE International Computer Software and Applications Conference , pages 311318, Turku, Finland, July 2008. Olivier Le Goaer, Mourad Oussalah, Dalila Tamzalit and Abdelhak Seriai. Evolution Shelf : Exploiting Evolution Styles within Software Architectures. In 20th International Conference on Software Engineering and Knowledge Engineering , pages 387392, San Francisco Bay, USA, July 2008.
tel-00459925, version 1 - 25 Feb 2010
Olivier Le Goaer, Mourad Oussalah, Dalila Tamzalit, and Djamel Serai. Evolution Styles in Practice - Refactoring Revisited As Evolution Style. In The Second International Conference on Software and Data Technologies, volume 3, pages 138143, Barcelona, Spain, July 2007. INSTICC Press. Mourad Oussalah, Dalila Tamzalit, Olivier Le Goaer, and Abdelhak Seriai. Updating styles challenge updating needs within component-based software architectures. In The Eighteenth International Conference on Software Engineering and Knowledge Engineering, pages 98101, San Francisco Bay, USA, July 2006. Abdelhak Seriai, Mourad Chabane Oussalah, Dalila Tamzalit, and Olivier Le Goaer. A reusedriven approach to update component-based software architectures. In The 2006 IEEE International Conference on Information Reuse and Integration, pages 313318, Waikoloa, Hawaii, USA, September 2006. Dalila Tamzalit, Mourad Oussalah, Olivier Le Goaer, and Abdelhak Seriai. Updating software architectures : A style-based approach. In The 2006 International Conference on Software Engineering Research and Practice, pages 336342, Las Vegas, Nevada, USA, June 2006. Olivier Le Goaer, Dalila Tamzalit, Mourad Oussalah, and Abdelhak Seriai. How to manage update needs within component-based software architectures. In The 32nd Euromicro Conference on Software Engineering and Advanced Applications (Work In Progress Session), pages 810, Dubrovnik, Croatia, August 2006.
Workshops Internationaux avec Comit de Lecture et Actes

Olivier Le Goaer, Dalila Tamzalit and Mourad Chabane Oussalah, and Abdelhak-Djamel Seriai. Evolution styles to the rescue of architectural evolution knowledge. In Proceedings of the 3rd international workshop on Sharing and reusing architectural knowledge, pages 3136, Leipzig, Germany, May 2008. Olivier Le Goaer and Peter Ebraert Evolution styles : change patterns for Software Evolution
Introduction
xiii
In Proceedings Third International ERCIM Workshop on Software Evolution, pages 252261, Paris, France, October 2007. Abdelkrim Amirat, Adel Smeda, and Olivier Le Goaer. Integrating Aspects in the COSA Model. In The Eighteenth International Symposium on Programming and Systems, pages 79 87, Alger, Algrie, May 2007. Universit des Sciences et de la Technologie Houari Boumediene (USTHB).
Workshops Nationaux avec Comit de Lecture sans Actes

Olivier Le Goaer, Mourad Oussalah, Dalila Tamzalit, and Seriai Djamel. Evolution dirige par les styles. In Atelier RIMEL (Rtro-Ingnierie, Maintenance et Evolution des Logiciels), Toulouse, France, March 2007.
tel-00459925, version 1 - 25 Feb 2010
tel-00459925, version 1 - 25 Feb 2010
C HAPITRE
Architecture logicielle : tat du domaine

Le travail prsent dans cette thse relve de lvolution dans les architectures logicielles. Auparavant, il est ncessaire de poser clairement le domaine et lorsque ncessaire, dclairer certains points et caractristiques que nous jugeons importants pour notre travail. Lobjectif de ce premier chapitre est de clarier la notion dArchitecture Logicielle, trs frquemment rencontre dans les travaux lis au dveloppement des systmes logiciels. Dans ce but, nous proposons un tat du domaine dune discipline dsormais majeure qui a mrie de manire signicative ces quinze dernires annes. Un grand intrt est port au domaine des architectures logicielles [CGL 03]. Cet intrt est motiv principalement par la rduction des cots et des dlais de dveloppement des systmes complexes. Larchitecture logicielle permet dexposer de manire comprhensible et synthtique la complexit dun systme logiciel et de faciliter lassemblage de pices logicielles. Elle permet en eet au concepteur de raisonner sur des proprits (fonctionnelles et non fonctionnelles) dun systme un haut niveau dabstraction. Larchitecture joue le rle essentielle de passerelle entre lexpression du besoin dun systme et ltape de codage du logiciel. Pour dcrire les architectures logicielles, plusieurs langages de description (ADL : Architecture Description Language ) ont t proposs. Les ADLs orent un niveau dabstraction lev pour la spcication et le dveloppement des systme logiciels, qui se veut indpendant des langages de programmation et de leurs plateformes dexcution. Dans ce chapitre, nous remontons dabord aux tournants idologiques fondateurs de larchitecture logicielle datant du dbut des annes 70, jusqu leur vritable mergence comme discipline de premier plan. A ce titre, nous tudions la place que prend dsormais larchitecture dans le cycle de dveloppement dun systme logiciel. La communaut acadmique a profondment inuenc cette discipline, et il nous semble utile de rpertorier les dnitions majeures de larchitecture logicielle proposes dans la littrature. Nous nous attardons sur le concept de style architectural [SG96], considr par beaucoup comme un lment cl de larchitecture logicielle. Nous abordons les langages de description darchitecture au travers de leurs principaux concepts descriptifs. Pour terminer, nous montrons que la spcication dune architecture logicielle par un ADL peut passer par plusieurs niveaux de modlisation. Il sagit l de voir larchitecture logicielle travers le prisme de la mta-modlisation.
tel-00459925, version 1 - 25 Feb 2010
1.1
Les architectures logicielles
Le domaine de linformatique est apparu travers des problmes lis la complexit, et cela depuis sa cration. Au dbut, les problmes de complexit ont t rsolus par les dveloppeurs en 1
CHAPITRE 1 Architecture logicielle : tat du domaine
choisissant les bonnes structures de donnes, en dveloppant des algorithmes, et en appliquant tacitement le concept de sparation des proccupations. Bien que le terme "architecture logicielle" est relativement nouveau pour lindustrie, les principes fondamentaux du domaine ont t appliqus sporadiquement par les pionniers de lingnierie du logiciel depuis le milieu des annes 1980. Les premires tentatives pour capturer et expliquer larchitecture logicielle dun systme furent imprcises et dsorganises souvent caractrises par un ensemble de diagrammes nonformaliss. Dans les annes 1990 il y a eu un eort commun pour tenter de dnir et de codier les aspects fondamentaux de la discipline. Des ensembles prliminaires de patrons de conception, de styles, de meilleures pratiques, de langages de description et de logiques formelles ont t labors au cours de cette priode.
1.1.1
tel-00459925, version 1 - 25 Feb 2010
mergence de larchitecture logicielle
La discipline de larchitecture logicielle concerne essentiellement les systmes large chelle, par consquent complexes. En eet, cest laccroissement de la complexit qui a amen progressivement repenser la faon de construire les systme logiciels. A lautomne 1968, lors dune confrence de lOTAN o 50 des meilleurs programmeurs de lpoque furent convis, les experts en informatique ont anticip ce qui allait devenir la fameuse crise du logiciel. Voici un extrait tir de la synthse des changes qui ont eu lieu lors de cette confrence [NR68] et qui nous semble trs important du point de vue idologique : The challenge of complexity is not only large but also growing [...]. To keep up with such demand, programmers will have to change the way that they work. You cant build skyscrapers using carpenters , Curtis quips Dans les annes 70, le secteur de lingnierie logicielle est en pleine mutation et doit rpondre de nouvelles exigences, du fait de laccroissement de la taille et de la complexit des systmes. Les moyens ne sont plus aligns sur les enjeux, et il devient ncessaire de changer lchelle laquelle le dveloppement est traditionnellement considr. Ces nouveaux ds ne pourront tre relevs que par la matrise des dirents niveaux de dtails et de raisonnement pouvant tre isols dans un systme logiciel.
1.1.1.1
Le d des systmes complexes
Dans leur article fcond intitul Programming-in-the-large versus programming-in-the-small [DK75], DeRemer et al. insistent sur le tournant qui doit tre amorc dans le dveloppement logiciel en discutant de la transition du dveloppement classique petite chelle vers un dveloppement plus grande chelle. Leur langage MIL75 est un prcurseur de la famille des langages dinterconnexion de modules (Module Interconnection Languages MILs), conus pour faire tenir ensemble des modules, cest--dire des segments de programmes. Un langage dinterconnexion de modules doit permettre didentier les modules du systme et indiquer comment ils sintgrent ensemble pour mettre en uvre les fonctionnalits du systme, mais nest pas concern par ce que le systme fait ni comment les modules implantent individuellement leurs fonctionnalits [PDN86]. Les MILs prnent donc un glissement de paradigme : celui du dveloppement base de lignes de codes vers le dveloppement base de modules. Cette rupture avec les mthodes existantes ncessite une programmation haut niveau, savoir, lassemblage dlments rutilisables dvelopps indpendamment (en C, en Ada, etc.). Ainsi, la programmation large chelle
fait intervenir des capacits dabstraction (jusqu ce quun module soit implment, il demeure une abstraction) et des capacits de gestion car la construction dabstractions ne se limite pas seulement dcrire des choses qui peuvent fonctionner mais galement grer les eorts humains qui les feront fonctionner.
Figure 1.1 Catgories darchitecture logicielle face la complexit croissante des systmes. Le constat cl est que plus un systme logiciel devient complexe, plus il devient ncessaire dexpliciter sa structure. Face laccroissement de la complexit, la vision de lingnierie des logiciels sest donc radicalement modie en passant de la perspective de dveloppement dun systme monolithique ou "monobloc" vers un systme construit comme un assemblage de morceaux logiciels. Ainsi, de nouvelles catgories darchitectures ont merges, orant chacune des units granulaires direntes pour le partitionnement dun systme (cf. gure 1.1). Les objets constituent des briques de base qui ont lavantage de trouver une correspondance directe avec les langages de programmation objet. Limage retenue est celle dun ensemble dobjets qui communiquent entre eux en schangeant des messages an de collaborer dans un objectif commun. Cependant, mme si lorient objet ore une base saine pour le dveloppement dlments rutilisables ne ou plus forte granularit [Jaz95], elle nore pas les notations adquates pour la construction plus large chelle. Les composants constituent des briques de construction plus large chelle et sont vus comme le prolongement des objets [Szy98]. Traditionnellement, les composants sont "gros grain" [SG96] car ils orent de nombreuses fonctionnalits et/ou des fonctionnalits complexes. Larchitecture base de composants vise construire un systme la manire dun puzzle, o chaque composant est une pice bien dnie et destine tre assemble une tierce pice. Lembotement des pices repose sur la correspondance entre les fonctionnalits quelles orent et celles quelles requirent. Puis, la forte complexit de certains systmes en termes dhtrognit dans les technologies utilises, et en terme de distribution travers les rseaux a fait natre les architectures base de services. Les services constituent des briques de construction trs large chelle destines construire des systmes logiciels caractriss par un environnement distribu et hautement dynamique. Ici, la mtaphore nest plus celle du puzzle, mais celle dun ensemble de fournisseurs et de consommateurs de services qui a priori ne se connaissent pas, mais qui ont vocation tre mis en relation dans un cadre contractuel. Il est important de mentionner que ces catgories darchitectures forment des couches conceptuelles successives. On peut concevoir un service (e.g., traduction de documents accessible par le Web) reposant sur des composants (e.g., moteur de traduction, ltrage, base de dnitions), eux-mmes reposant sur des objets. Chaque catgorie darchitecture ore une couche dabstraction sur la prcdente permettant de masquer progressivement les dtails pour se focaliser sur des objectifs proportionnels et sur des proccupations relatives la vue que lon a sur le systme.
tel-00459925, version 1 - 25 Feb 2010
1.1.1.2
De la ncessit de dcomposer
Lide basique est qu dfaut de rduire la complexit il faut la matriser en donnant une illusion de simplicit. Cela implique dappliquer des critres de partionnements, comme le souligne David Parnas dans [Par72]. Cest ici quintervient la notion de dcomposition an de mettre en
pratique le clbre adage Diviser pour mieux rgner. Le rle de la dcomposition est doprer un ranage rcursif jusqu obtention dlments comprhensibles. Toutefois, la notion dlment comprhensible dpend totalement du systme considr et le nombre ranages requis nest pas connu a priori. Chaque tape de ranage correspond un niveau de dcomposition hirarchique. On emploi souvent le terme de "granularit" pour se rfrer un niveau plus ou moins profond dans cette hirarchie. On parle alors de granularit forte ou ne. La dcomposition hirarchique est fondamentalement une stratgie "top-down". Dabord le systme est divis en sous-systmes de premier niveau. Puis, chaque sous-systme de premier niveau est divis en sous-systmes de second niveau, et ainsi de suite. La dcomposition hirarchique permet daller dirents niveaux de profondeurs dans les sous-systmes sans perdre la vue densemble du systme. Les sous-systmes des niveaux suprieurs contiennent tous les dtails des sous-systmes des niveaux infrieurs.
tel-00459925, version 1 - 25 Feb 2010
Figure 1.2 Inuence de la dcomposition sur la complexit dun systme. Le travers de cette activit est de rintroduire une autre forme de complexit. En eet, la dcomposition dun systme en sous-systmes implique lexistence de liaisons entre les soussystmes. Ce sont ces liaisons qui maintiennent les parties ensembles et les font collaborer pour former un tout. Par consquent, une trop forte dcomposition augmente dramatiquement le nombre de liaisons internes et les eorts ncessaires pour les grer. Nous illustrons ce principe important par la mtaphore du (cf. gure 1.2). Selon cette mtaphore, la base du dlimite le degr de dcomposition maximal acceptable an de ne pas r-augmenter la complexit du systme.
1.1.2
Reconnaissance de larchitecture logicielle
Le numro spcial de lt 2006 de lIEEE Software magazine a t ddi au domaine de larchitecture logicielle pour commmorer deux dcennies de recherche et une dcennie de pratique. On saccorde penser que larchitecture logicielle a susamment mrie pour tre aujourdhui
unanimement reconnue comme une discipline majeure [SC06, KOS06], et que la pratique de larchitecture logicielle a t leve au rang de spcialit part entire du gnie logiciel. Notamment, lintgration de larchitecture logicielle dans le cycle de dveloppement des logiciels est juge indispensable sous peine de faire chouer les projets. Cest en substance ce que dit la dnition assez originale de Eoin Woods : Software architecture is the set of design decisions which, if made incorrectly, may cause your project to be cancelled. - Eoin Woods En quelque sorte, ngliger larchitecture est un anti-pattern dans le processus de dveloppement du logiciel. On admet aujourdhui quune "bonne" architecture a une inuence positive sur la qualit du produit nal et qu linverse, une "mauvaise" architecture peut avoir des consquences dsastreuses, jusqu larrt du projet [Gar00b].
tel-00459925, version 1 - 25 Feb 2010
1.1.2.1
Larchitecture au coeur du dveloppement
Un systme est le rsultat dinnombrables dcisions individuelles des dveloppeurs, et au bout dun certain temps et dune certaine taille, on se rend compte que lon dispose dune architecture. En fait, toute implantation dun systme logiciel possde ncessairement une architecture, mais cette dernire demeure totalement implicite. Lavantage du dveloppement centr architecture est de dcrire explicitement larchitecture. Cela require de voir larchitecture logicielle comme une phase du cycle de dveloppement part entire 1 . Traditionnellement, le processus de dveloppement logiciel a t modlis sous formes dtapes incrmentales mettant en jeu le ranement, dmarrant sur une valuation du problme rsoudre et aboutissant avec limplmentation du systme. Une itration entre les tapes est prvue. Par exemple, pendant la phase dimplmentation, on peut dcouvrir des erreurs qui exigent un changement majeur dans la conception dtaille du systme. Cela ncessite un retour sur ltape de conception dtaille et une rpercution sur les tapes suivantes. Une architecture explicite et capture formellement ore un mdium pour analyser trs tt lexactitude et la compltude de la conception cense satisfaire les exigences du systmes. La Figure 1.3 illustre un modle de dveloppement reconnaissant pleinement larchitecture. Ainsi, on trouve les quatre tapes suivantes : Lanalyse des besoins vise dterminer linformation et le traitement de cette information. La conception architecturale concerne la slection des lments architecturaux, de leurs interactions, en prcisant les contraintes qui psent sur ces lments et leurs interactions. Larchitecture fournit un cadre qui satisfait aux besoins et sert de base pour la conception. La conception dtaille traite de la modularisation, de la spcication dtaille des interfaces des lments de conception, leurs algorithmes et procdures, et les types de donnes ncessaires pour soutenir larchitecture. La conception doit satisfaire les proprits spcies la fois dans larchitecture et par les besoins. Limplmentation est lie aux reprsentations des algorithmes et des types de donnes. Limplmentation doit satisfaire la conception, larchitecture, et les besoins.
1. Nanmoins, certains auteurs considrent toujours larchitecture logicielle non pas comme un phase au sens strict, mais plutt comme une discipline qui imprgne toutes les phases du cycle de dveloppement.
tel-00459925, version 1 - 25 Feb 2010
Figure 1.3 tapes dun modle de dveloppement en cascade et leurs reprsentations.
1.1.2.2
Les acteurs engags dans le dveloppement
A chaque tape du modle de dveloppement correspond un acteur, possdant des aptitudes spciques. Le dveloppement centr architecture rajoute un nouvel acteur, larchitecte, aux acteurs plus traditionnels de concepteur et de programmeur. Ainsi, larchitecte, le concepteur et le programmeur sont les trois acteurs qui participent respectivement la phase de conception architecturale, de conception dtaille et dimplmentation. Tous trois peuvent manipuler des concepts similaires, seul le niveau auquel ils sont manipuls varie. Tandis que le rle dun concepteur et dun programmeur est plutt bien tabli, larchitecte logiciel est un terme gnral qui peut faire rfrence un large ventail de rles. Il existe de nombreuses dnitions acceptes. La place dun architecte logiciel dans les projets informatique a t intensivement discut dans [Fow03] et [SS01]. Nous proposons ici nos propres dnitions : Le programmeur : il est issu de la communaut des composants logiciels. Son travail vise fournir des briques de base de qualit, rutilisables pour la production dapplications, quil met disposition travers des librairies. Laccent est mis sur la manire de dnir un composant avec les proprits voulues et bien agences. La partie relative lassemblage de ces composants est souvent assez pauvre. Le programmeur utilise le formalisme des langages de programmation dans des environnements intgrant la notion de composant (COM/DCOM, DLL, CORBA, Java Bean, OpenCom, OSGi, etc.). Le concepteur : il est issu de la communaut des composants conceptuels. Il joue un rle tampon entre le programmeur, travaillant un faible niveau dabstraction, et larchitecte, travaillant un haut niveau dabstraction. Son travail vise dnir des briques conceptuelles qui satisfont chaque problme et rutilisables pour dautres problme similaires, quil met disposition sous formes de patrons ou de frameworks. Larchitecte : il est issu de la communaut des composants architecturaux. Son travail vise lintgration de ces briques un niveau plus global pour construire des applications de qualit, maintenables. Contrairement au programmeur, la faon dobtenir les composants est secondaire, alors que les proprits de leurs interactions sont tudies en dtail. Il utilise le formalisme des ADLs. Des outils peuvent laider analyser certaines proprits de son architecture.
tel-00459925, version 1 - 25 Feb 2010
1.1.3
Dnitions notables
Le terme dArchitecture Logicielle est probablement lun des plus surexploit et des plus surcharg en gnie logiciel. Au moins deux raisons expliquent ceci. La premire est que le seul mot architecture apporte avec lui un certain nombre de signications implicites et dhypothses de par son association directe avec la construction physique de btiments. La deuxime raison qui entretient la confusion est que larchitecture logicielle nest reconnue comme un produit part entire du cycle de dveloppement logiciel que depuis quelques annes, et il aura donc fallu attendre la n des annes 80 pour que la notion darchitecture logicielle merge [Sha89]. Depuis lors, lutilisation du terme a grimp en che, trs souvent avec des acceptions direntes. Par exemple, une architecture logicielle a t diversement dnie comme un prototype excutable [RR91], une description statique dune topologie [GS93], ou encore une documentation [Kru95]. A lheure actuelle, il nexiste toujours pas de dnition prcise et normalise de larchitecture logicielle, et il en existe de nombreuses interprtations. A titre dexemple, le SEI (Software Engineering Institute ) a document et catalogu des centaines de dnitions [www 8 ]. Dans la
section suivante, nous nous contenterons de prsenter les dnitions les plus inuentes, classes par ordre chronologique.
1.1.3.1
Perry et Wolf (1992)
tel-00459925, version 1 - 25 Feb 2010
Lune des premires dnitions formelles darchitectures logicielles, de Perry et Wolf [PW92], est reste lune des plus perspicaces. Aprs avoir examin les architectures dans dautres disciplines (matriel, rseaux et btiments), Perry et Wolf dcrivent une architecture logicielle comme un ensemble dlments architecturaux qui ont une forme particulire. Les lments sont diviss en trois catgories : lments de traitement, lments de donne, et lments de connexion. tant donn que les lments de traitement et de donne ont t t largement tudis par le pass (par exemple, les fonctions et les objets), ce sont les lments de connexion qui distinguent une architecture dune autre. La forme de larchitecture est donne en numrant les proprits des dirents lments et les relations entre ces lments. Un autre lment essentiel de larchitecture est sa logique (rationale en anglais) qui englobe, entre autres, les aspects de qualit. Perry et Wolf dnissent galement un style architectural comme ce qui abstrait les lments et les aspects formels de diverses architectures spciques. En bref, un style est une architecture moins contrainte et moins complte il ny a pas de ligne de dmarcation franche. Lintrt dun style particulier rside dans le fait quil traite des choix de conception importants ds le dpart, en isolant et en mettant laccent sur certains aspects. Un style ou une architecture spcique peut tre vue de trois faons direntes, sur la base de ses lments : la vue traitement, la vue donne et la vue connexion. Les trois vues sont ncessaires la comprhension du style ou de larchitecture.
1.1.3.2
Garlan et Shaw (1993)
Un dnition trs populaire de larchitecture logicielle a t avance par Garlan et Shaw [GS93], qui est plus restrictive que la dnition de Perry et Wolf. Garlan et Shaw ont propos quune architecture logicielle pour un systme spcique soit reprsente comme un ensemble de composants de calcul - ou tout simplement de composants - accompagn dune description des interactions entre ces composants - les connecteurs. Sur la base de cette dnition, les auteurs ont utilis le terme de style architectural pour dsigner une famille de systmes (cest--dire darchitectures applicative) qui partagent un vocabulaire commun de composants et connecteurs, et qui rpondent un ensemble de contraintes pour ce style. Les contraintes peuvent porter sur une varit de choses, notamment sur la topologie des connecteurs et des composants, ou sur la smantique de leur excution.
1.1.3.3
Bass, Clements et Kazman (1998)
Dans leur dnition, Bass et al. [BCK98] insistent sur les proprits extrieurement visibles dun composant qui dnissent son comportement attendu : elles traduisent les hypothses que dautres composants peuvent faire sur ce composant (par exemple, les services quil fournit, les ressources requises, ses performances, ses mcanismes de synchronisation). Le qualiant extrieurement visible exprime le pendant des dtails que le composant encapsule. Un composant est donc une unit dabstraction dont la nature dpend de la structure considre dans le processus de conception architecturale. Ce peut tre un service, un module, une bibliothque, un processus, une procdure, un objet, une application, etc. Mais le comportement observable de
chaque composant fait partie de larchitecture puisquil dtermine ses interactions possibles avec dautres composants. La dnition propose met galement en lumire le fait quun systme peut avoir plusieurs structures correspondant chacune un point de vue, donc une nalit ou classe de problmes prcis rsoudre. En somme, comme en architecture du btiment, un logiciel est reprsent par plusieurs plans et schmas destins chacun un corps de mtier et dpendants de ltape du processus de dveloppement.
1.1.3.4
La norme AINSI/IEEE Std 1471 (2000)
tel-00459925, version 1 - 25 Feb 2010
LIEEE a dni une norme pour la description architecturale de systmes prdominance logicielle (software-intensive systems ), lIEEE 1471 2 [IEE00]. LIEEE 1471 a sciemment propos une dnition gnraliste capable denglober plusieurs interprtations. Surtout, la norme IEEE 1471 tablit un cadre conceptuel (cf. gure 1.4) et un vocabulaire pour parler des problmatiques architecturales des systmes. Elle comprend lutilisation de plusieurs vues, de modles rutilisables au sein de vues, et la relation quentretient larchitecture avec le contexte du systme (appel aussi environnement). En se basant sur ce cadre conceptuel, lide est didentier et ddicter des pratiques architecturales pertinentes, et de les incuber.
Figure 1.4 Modle conceptuel pour la description darchitecture logicielle (adapt de la norme 1471-2000). Quel que soit le bien-fond dun ADL en particulier, il ny a pas de consensus dans la communaut des utilisateurs de la norme IEEE 1471 sur les ADLs. Il ny a mme pas de consensus sur ce quun ADL devrait tre. Toutefois, il y a consensus sur le fait que les architectes doivent choisir leurs notations avec soin, documenter ces choix, et tre encourags utiliser des ADLs bien dnis. Chaque utilisateur de lIEEE 1471 peut ainsi choisir un ou plusieurs ADL, ou mme crer le sien dans le cadre prvu par lIEEE 1471, qui inclue les lments suivants : Description architecturale (Architectural Description ) : un ensemble de vues et dautres informations architecturales. Partie prenante (Stakeholder ) : un individu, un groupe ou une organisation qui a au moins une proccupation en rapport avec le systme.
2. A t galement adopte comme standard ISO en 2006 et publie en tant que ISO/IEC 42010 :2007
10
Proccupation (Concern ) : une exigence fonctionnelle ou non-fonctionnelle. Vue (View ) : un ensemble de modles reprsentant un systme selon un ensemble de proccupations connexes. Point de vue (Viewpoint ) : les conventions pour la cration, la reprsentation et lanalyse dune vue. Modle (Model ) : un diagramme ou une description construits suivant la mthode dnie dans un point de vue. Ces derniers fournissent la description spcique du systme, qui peut inclure des sous-systmes.
1.1.4
Styles architecturaux
tel-00459925, version 1 - 25 Feb 2010
En plus des structures de larchitecture logicielle, les systmes ont souvent en commun des patrons dorganisation, appels styles architecturaux [SG96]. Certains des plus rpandus qui ont t identis et dcrits sont le style client/serveur, le style tuyau&ltre, le style orient objet et le style en couches. Lun des avantages des styles architecturaux est quils possdent des attributs de qualit dtermins [BCK98] (e.g., performance, disponibilit, scurit, rutilisabilit, etc.). Cela permet un architecte de slectionner un style en fonction des exigences requises par le systme au lieu dinventer une architecture partir de zro [BCK98]. Dans la mesure o les styles architecturaux peuvent traiter dirents aspects de larchitecture logicielle, une architecture donne peut tre issue de plusieurs styles. notre avis, les patrons et les styles architecturaux sont de bon mcanismes pour encapsuler de lexpertise pour la conception. Lintroduction de la notion de rutilisation dans les architectures logicielle est un point remarquable, dont les bnces sont aujourdhui reconnus. Dune part, un style architectural partage avec la notion de patron lide que des solutions des problmes de conception courants peuvent tre rutilises. Dautre part, il est frquent de mettre en relation les styles architecturaux. Par exemple, un style hybride peut tre form en combinant plusieurs styles de base dans un style unique et bien coordonn.
1.1.4.1
Dnitions
Une architecture incarne la fois des proprits fonctionnelles et non fonctionnelles et par consquent il peut tre dicile de comparer directement les architectures de dirents types de systmes, ou bien le mme type de systme dans des environnements dirents. Les styles sont un moyen pour classer les architectures et pour dnir leurs caractristiques communes [NR99]. Perry et Wolf [PW92] dnissent le style architectural comme une abstraction des types dlment et des aspects formels de diverses architectures, pour se concentrer seulement sur certains aspects dune architecture. Un style architectural encapsule dimportants choix dlments architecturaux et met laccent sur les contraintes importantes imposes sur les lments et leurs relations. Cette dnition admet des styles qui se concentrent uniquement sur les connecteurs dune architecture, ou sur des aspects spciques des interfaces des composants. En revanche, Garlan et Shaw [GS93], Garlan et al. [GAO95], et Shaw et Clements [SC97], dnissent tous le style en terme de patron dinteraction entre des types de composants. En particulier, un style architectural dtermine le vocabulaire des composants et des connecteurs qui peuvent tre utiliss dans les instances de ce style, avec un ensemble de contraintes sur la manire dont ils peuvent tre combins [GS93]. Cette vision des styles architecturaux est le rsultat direct de leur dnition de larchitecture logicielle penser une architecture comme une description formelle, plutt
11
que comme un systme lexcution , et conduit des abstractions fondes uniquement sur les patrons partags par un ensemble de diagrammes de type bote et ligne. Abowd et al. [AAG95] vont plus loin et dnissent cela explicitement en considrant que lensemble des conventions qui sont utilises pour interprter une classe de descriptions architecturales correspond la dnition dun style.
1.1.4.2
Rutilisation de solutions
tel-00459925, version 1 - 25 Feb 2010
Certains styles architecturaux sont souvent dcrits comme des "solutions miracle" pour toutes les formes de logiciels. Toutefois, un bon architecte doit choisir un style qui corresponde aux besoins du problme particulier rsoudre [Sha95]. Choisir le bon style architectural exige une comprhension du domaine du problme ainsi quune prise de conscience de la varit des styles architecturaux et des proccupations spciques quils adressent. Les styles architecturaux ont t considrs comme des patrons darchitecture. On peut dire quun patron est architectural si il se rfre un problme du niveau architectural, cest--dire si ce patron porte sur la structure globale du systme et pas seulement quelques sous-systmes [AZ05]. Cela inclut certains patrons de conception assez "gros" pour tre considrs comme patrons architecturaux (e.g., Interpreter [GHJV94]). De son cot, Garlan et al. proposent de considrer les styles architecturaux selon deux catgories [GAO94] : 1. Les idiomes et patrons darchitectures : cette catgorie inclut les organisations structurelles globales, telles que les systmes en couches (layered ), les systmes tuyaux et ltres (pipe&lter ), les systmes client/serveur, les systmes de tableau noir (blackboard ), etc. 2. Les modles darchitectures de rfrence : cette catgorie inclut des organisations qui prescrivent des congurations spciques de composants et de connecteurs pour des domaines dapplications bien dtermins (e.g., architecture pipeline dun compilateur). Elle inclut aussi une large gamme dapproches ddies telles que lavionique ou la robotique mobile. Nous remarquons que les idiomes et patrons darchitecture sont considrs comme des abstractions fondamentales qui bncient dune large porte de rutilisation, et qui au l du temps sont intgrs dans les langages et les outils. Shaw [Sha96] ou Buschmann et al. [BMR 96] ont publi une liste non-exhaustive et empirique de tels patrons. Par essence, leur nombre tend tre limit et constant. En revanche, les modles darchitectures de rfrence permettent de dcrire de lexpertise consacre des dveloppements dapplications bien prcises, orant naturellement une moindre porte de rutilisation. Ils sont mme dexprimer des politiques spciques des compagnies direntes, motives par des proccupations de qualit, de scurit, de performance ou de maintenance. Par consquent, on sattend ce que de larges bibliothques de modles darchitectures ddis des domaines soient cres. De plus, ces modles forment un rservoir dynamique de connaissances. Ils voluent plus rapidement que les idiomes et les patrons car les exigences dun domaine dapplication subissent des changements en continue, et leur procd de validation et de publication tend tre moins rigoureux.
1.1.4.3
Relations inter-styles
Les styles peuvent tre relis les uns aux autres de direntes faons. Nous prsentons ici brivement deux des relations les plus frquemment mentionnes dans la littrature.
12
tel-00459925, version 1 - 25 Feb 2010
Une premire relation est la spcialisation. Un style peut tre un sous-style dun autre en renforant les contraintes, ou en fournissant des versions plus spcialises de quelques-uns des types dlments. Par exemple, le style pipeline pourrait spcialiser le style tuyaux&ltre en interdisant les congurations non-linaires et en spcialisant le type dlment ltre en un palier du pipeline qui possde un seul port dentre et un seul port de sortie. Autre exemple : un style client-serveur N-tiers pourrait spcialiser le style plus gnral client-serveur en limitant les interactions entre les tiers non-adjacents. Une seconde relation importante est la composition, dautant plus que la plupart des systmes exhibent un mlange de styles dans leur composition, que Garlan et Shaw dcrivent sous le terme darchitectures htrognes [GS93]. On peut combiner deux styles en prenant lunion de leur vocabulaire de conception, et en joignant leurs contraintes. Par exemple, on pourrait ajouter un composant de base de donnes un systme de type tuyau-ltre en liant un style tuyau&ltre avec un style base de donne. Dans ce cas, il peut tre ncessaire de dnir galement de nouveaux types de composants ou de connecteurs qui appartiennent plus dun style, comme un type de composant qui possde un comportement similaire un ltre mais qui peut aussi accder une base de donne. Dans les travaux acadmiques, on remarque que la spcialisation des styles architecturaux a t traite tt dans [GAO94] o Garlan et al. ont dni une relation de sous-classement entre des styles dans leur globalit (et pas uniquement entre des types pris individuellement dans le style) ou plus rcemment dans Archware ADL [Ley04]. La question de savoir quand plusieurs styles peuvent tre combins ou si ils peuvent se chevaucher dans un modle nest toujours pas rgle [CGL 03]. Par dfaut, aucune restriction nest place sur cette possibilit dans les modles de description darchitecture. Cest ainsi par exemple que Archware ADL [Ley04] permet de dnir un style par agrgation de styles existants.
1.1.5
Bilan
La dernire dcennie a vu une norme augmentation de limportance dune branche de lingnierie logicielle, connue sous le nom darchitecture logicielle. "Architectes techniques" et "architecte en chef" sont des intituls de postes qui abondent aujourdhui dans lindustrie du logiciel. Il existe mme un institut mondial des architectes logiciels [www 10 ]. Toutefois, il apparat que le terme "architecture" est lun des plus surexploits et des moins compris dans les milieux du dveloppement de logiciels professionnels. Une grande partie du travail dun architecte vise trouver une partition judicieuse dune application en un ensemble de composants inter-relis. Les direntes exigences et contraintes du projet considr dnissent le sens exact de "judicieuse" dans la phrase prcdente une architecture doit tre conue pour rpondre aux exigences et aux contraintes de lapplication laquelle elle est destine. En partitionnant lapplication, larchitecte aecte des responsabilits chaque composant. Ces responsabilits dnissent les missions quun composant doit remplir dans lapplication. De cette manire, chaque composant joue un rle spcique dans lapplication, et lensemble des composants qui forment larchitecture collaborent en vue de fournir la fonctionnalit attendue. Finalement, la conception et la validation dune architecture dun systme complexe est un exercice cratif, exigeant des connaissances, de lexprience et de la discipline. La notion de style architectural a t introduite pour capitaliser des savoir et des savoir-faire pour la conception darchitecture. De ce point de vue, ils servent de guides aux architectes et tendent amliorer la qualit globale des architectures produites.
13
1.2
Langages de description darchitectures
En accompagnement de la notion darchitecture logicielle, des formalismes sont apparus au cours des annes 90 : les ADLs (Architecture Description Languages ) ou langages de description darchitecture. Ils sont utiliss pour dcrire la structure dun systme comme un assemblage dlments logiciels. Cela est illustr par le diagramme de la Figure 1.5 o lon voit un client et un serveur relis par un appel de procdure distance (Remote Procedure Call ).
tel-00459925, version 1 - 25 Feb 2010
Figure 1.5 Assemblage dlments architecturaux pouvant tre dcrit laide dun ADL. De nombreux ADL ont t dvelopps par le milieu acadmique, comme Wright, Darwin, ACME, Unicon, Rapide, Aesop, C2 SADL, MetaH, etc. [MT00]. De manire trs gnrale, les entits manipules par ces langages sont des lments bien identis, susamment abstraits et les plus indpendants possible les uns des autres. La spcication dun assemblage de tels lments constitue leur construction fondamentale. Mme si, de ce point de vue, ils achent a priori une certaine adquation avec la conception base de composants lorsquelle vise la ralisation dun systme par assemblage de composants logiciels pr-existants (les COTS 3 ), nous rappelons quils ont t originellement motivs par la matrise de la structure de plus en plus complexe des systmes logiciels. Dans les sections suivantes, nous listons lensemble des concepts que lon trouve dans les ADLs.
1.2.1
Concepts de base
En ce qui concerne les architectures logicielles, la plupart des travaux rcents publis sont dans le domaine des langages de description darchitecture (ADL). Un ADL est, selon Taylor et Medvidovic [MT00], un langage qui ore des fonctionnalits pour la dnition explicite et la modlisation de larchitecture conceptuelle dun systme logiciel, comprenant au minimum : des composants, des interfaces, des connecteurs, et des congurations architecturales. Nous donnons dans ce qui suit une dnition plus prcise de ces concepts minimaux.
3. Component-O-The-Shelf : acronyme utilis pour dsigner des composants prt lemploi.
14
1.2.1.1
Composant
Le composant reprsente le principal lment de calcul et de stockage des donnes dans un systme. Un composant possde un ensemble dinterfaces, appels ports, qui dnissent les points dinteraction entre cet lment et son environnement. La taille et la complexit dun composant est trs variable. Un serveur, une base de donne ou une fonction mathmatique sont des exemples de composants. Les modles de composants hirarchiques acceptent le concept de composant composite, cest--dire un composant contenant son tour une conguration de composants et de connecteurs.
1.2.1.2
Connecteur
tel-00459925, version 1 - 25 Feb 2010
Le connecteur identie linteraction entre les composants. Le connecteur peut reprsenter une interaction simple comme une invocation un service, ou bien un protocole complexe, comme le contrle dun robot sur Mars par une station de contrle au sol. Un connecteur dnit un ensemble de rles qui permettent didentier les participants linteraction. Par exemple, un connecteur "pipe" (e.g., tube de communication des systmes Unix) possde un rle dcriture et un rle de lecture ; un connecteur de type diusion-abonnement (i.e., Observateur/Observ [GAO94]) peut avoir de multiples rles dobservateur et dobservs. Le connecteur peut disposer dune glu qui dnit comment les rles interagissent entre eux.
1.2.1.3
Interface
Une interface constitue le "portail" des composants, des connecteurs et des congurations vers le monde extrieur. L interface est aussi connue sous le nom de port pour les composants et les congurations, et de rle pour les connecteurs. Par exemple, si un composant implmente une API particulire, il possderait probablement une interface indiquant que dautres composants peuvent faire appel cette API sur le composant cible. Typiquement, les interfaces ont un identiant unique, une description textuelle, et une direction (un indicateur pour savoir si linterface est fournie, requise, ou les deux). On peut galement trouver une spcication de la smantique de linterface. Les interactions entre les interfaces sont dnies par des attachements et des bindings. Attachement (liaison) : reprsente la connexion dun port dun composant et un rle dun connecteur, si ces derniers ont des directions compatibles de type requis/fournis. Binding (correspondance) : les connexions entre les ports (respectivement les rles) dune conguration ou dun composant composite (respectivement dun connecteur composite) et les ports (respectivement les rles) de leurs sous-composants (respectivement sousconnecteurs) sont appeles bindings.
1.2.1.4
Conguration
Une conguration architecturale (ou simplement architecture ou systme) est un graphe qui montre la faon dont un ensemble de composants sont relis les uns aux autres par lintermdiaire de connecteurs. Le graphe est obtenu en associant les ports des composants avec les rles des connecteurs adquats, en vue de construire lapplication. Par exemple, les ports des composants de type "lter" sont associs aux rles des connecteurs de type "pipe" travers lesquels ils lisent et crivent des ux de donnes. Lanalyse dune conguration permet par exemple de dterminer
15
si une architecture est "trop profonde", ce qui peut aecter la performance due au trac de messages travers plusieurs niveaux hirarchiques, ou "trop large", ce qui peut conduire trop de dpendances entre les composants.
1.2.2
Concepts supplmentaires
Bien que les concepts prcdents soit susants pour dcrire une architecture logicielle, la majorit des ADLs y ont ajout les concepts supplmentaires suivants.
1.2.2.1
Proprits
tel-00459925, version 1 - 25 Feb 2010
En supplment des lments de haut-niveau pr-cits, la plupart des architectures associent galement des proprits leurs lments constitutifs. Par exemple, pour une architecture dont les composants sont associs des tches priodiques, les proprits pourraient dnir la priodicit, la priorit, et la consommation CPU de chaque composant. Les proprits des connecteurs pourraient inclure la latence, le dbit, la abilit, le protocole dinteraction, etc. Les proprits peuvent tre fonctionnelles ou non-fonctionnelles.
1.2.2.2
Types
Le type est au paradigme composant ce que la classe est au paradigme objet. Il permet lencapsulation de fonctionnalits et des lments internes en vu dtre rutilisables. Un type peut tre instanci plusieurs fois dans une mme architecture ou peut tre rutilis dans dautres architectures. Les instances des types ont les mme structures et comportements que celui du type. Un systme de type explicite facilite la comprhension et permet danalyser les architectures [Gar95]. On peut ainsi rutiliser des composants, des connecteurs et des congurations par le biais de types de composants, de types de connecteurs et de types de congurations. cet gard, un style architectural peut tre vu comme un type de conguration particulier.
1.2.2.3
Contraintes
Les contraintes expriment des restrictions places sur les composants, les connecteurs et les congurations. Elles sont spcies au niveau des types pour sappliquer sur les instances. Une contrainte sur un composant peut par exemple servir borner les valeurs de ses proprits. Un exemple de contrainte sur un connecteur est la restriction du nombre de composants qui interagissent travers ce dernier. Une contrainte sur une conguration peut permettre de gouverner la topologie et le nombre dinstances autorises. Les contraintes peuvent tre spcies soit dans un langage de contrainte spar, soit directement en utilisant les notations de lADL hte.
1.2.3
Rtrospective des ADLs
Ltude de Medvidovic et Tailor [MT00] a rvl quil y eu une prolifration dans les ADLs disponibles, tandis quil y avait beaucoup de similitudes entre eux. Nanmoins, ces ADLs ont direntes vocations, ce qui suggre la possibilit dutiliser plusieurs ADLs pour dcrire larchitecture dun mme systme. Plutt que de considrer chaque ADL, nous prsentons dans la Figure 1.6 une frise chronologique des dirents ADLs qui ont t proposs, en prenant soin de
16
mentionner leur origine. Cette rtrospective fait ressortir deux gnrations dADLs issus de trois coles acadmiques.
Figure 1.6 Frise chronologique des ADLs ainsi que leur origine.
tel-00459925, version 1 - 25 Feb 2010
1.2.3.1
Deux gnrations dADLs
Durant la dernire dcennie, une douzaine dADLs dirents sont apparus. Chacun deux vise dcrire une conguration architecturale, mais selon un angle de vue dirent. En outre, chacun de ces ADLs possde des rgles de syntaxe trs spciques et adaptes la description de certaines proprits de larchitecture. De nos jours, nous faisons rfrence ces notations comme des ADLs de premire gnration [DI04]. Certains des exemples les plus reprsentatifs de cette gnration sont Darwin [MK96], Wright [All97], Rapide [LV95] et C2 [MRT99]. Ltude de la premire gnration dADL a montr que, bien que dirents, ces ADLs partagent une mme base conceptuelle ou une ontologie qui dtermine un ensemble de concepts et de proccupations communes pour la description architecturale. Cela a naturellement conduit lide quil serait possible de crer un ADL gnrique, qui combinerait les proprits communes et les caractristiques bnques de la premire gnration dADL. Ces langages qui cherchent prendre du recul sur les tentatives antrieures pour la spcication darchitectures sont considrs comme des ADLs de seconde gnration [DI04]. Les exemples les plus signicatifs de la deuxime gnration sont ACME [GMW97] et xADL 2.0 [DHT01]. En acceptant lide de considrer UML 2.0 comme un ADL a part entire [ICG 04], celui-ci sinscrit dans cette seconde gnration.
1.2.3.2
Trois coles acadmiques
Lorsque lon sintresse aux origines des ADLs, on saperoit que le paysage acadmique se partage entre lcole amricaine (US), lcole europenne (EU) et lcole franaise (FR). Historiquement, MIL75 [DK75] considr comme lanctre des ADLs ft avanc par les amricains, dont les travaux sont rests trs inuents jusqu aujourdhui. La contribution de lcole amricaine est issue essentiellement de la CMU (Carnegie Mellon University ) et lUCI (University of California, Irvine ), dont les travaux sont respectivement pilots par David Garlan et al. et Richard N. Taylor et al.. Dans le mme temps, UML 2.0 est un poids lourd du domaine qui est formalis par lOMG (Object Management Group ), un consortium amricain ouvert et sans but lucratif (> 800 membres). De son cot, lcole europenne sest illustre trs tt avec la contribution de lImperial College avec Darwin, puis plus tard Koala [vOvdLKM00]. Moins connus, Conic [KM85] et BackBone [MKM06] sont galement deux ADLs issus de cette entit anglo-saxone. Quant SOFA [PBJ98], cest un ADL dvelopp par la Charles University, situe en Rpublique
17
Tchque. Une cole franaise a commenc merger ces dernires annes, avec SafArchie [BD04], Archware ADL [MKB 04] et enn COSA [Sme06, KSO05], un ADL propos par notre quipe. En dehors du cercle acadmique, on notera tout de mme la participation des industriels aux ADLs Meta-H [BEJV96] (Honeywell Inc.) et Koala (Philips).
1.2.4
Bilan
tel-00459925, version 1 - 25 Feb 2010
Jusqu prsent, un certain nombre dADLs ont t dvelopps an daider le dveloppement centr architecture. Les ADLs fournissent des notations formelles pour dcrire et analyser les systmes logiciels. Ils sont gnralement accompagns par divers outils destins analyser, simuler, et parfois gnrer le code des systmes modliss. Un certain nombre dADL ore galement un support pour modliser le comportement et les contraintes sur les proprits des composants et des connecteurs [MT00]. Ces comportements et contraintes peuvent tre exploits pour assurer la cohrence dune conguration architecturale tout au long de la vie dun systme (e.g., en dmontrant la conformit entre les services de composants interagissants). Le consensus sur les concepts fondamentaux que doit orir un langage de description darchitecture a t long atteindre. Les ADLs de seconde gnration sont ns sur la base des eorts de standardisation et dinteroprabilit entrepris auparavant. A ce titre, ACME a t un prcurseur en se positionnant ds le dpart comme un ADL pivot et susceptible de fdrer lensemble des travaux de la communaut. Par ailleurs, lmergence tardive de lcole franaise fait quelle bncie dun recul supplmentaire qui la orient vers des problmatiques traites de faon limite comme lvolution par exemple. Enn, il faut bien dire que lapproche ADL issue des milieux acadmiques ne sest pas impose dans le monde industriel. Il lui est souvent reproche dutiliser des notations diciles mettre en uvre et de fournir des outils peu exploitables. Dans la section suivante, nous nous intressons aux niveaux de modlisation qui existent lorsque lon utilise les ADLs. Cette vision de larchitecture logicielle est une particularit de notre quipe, et sera importante prendre en compte pour la suite de notre travail sur lvolution architecturale.
1.3
Architecture et mta-modlisation
A travers notre tude des ADLs, nous constatons que la spcication dune architecture peut passer par plusieurs niveaux de modlisation. Dans cette section, nous appliquons les quatre niveaux de modlisation proposs par lOMG larchitecture logicielle. En eet, la technique de mta-modlisation peut reposer sur une approche objet (comme celle de lOMG), ou bien sur une approche composant. On parlera ainsi respectivement de mta-modlisation par objet et de mta-modlisation par composant. Nous nous plaons dans le second cas de gure et le rsultat de cela est une hirarchie dirents niveaux darchitecture, dmarrant sur la dnition dune mta-mta-architecture jusqu une application.
1.3.1
Principes de la mta-modlisation
Avant dtudier ce quest un mta-modle, il semble logique de sintresser dabord ce quest un modle. Minksy propose la dnition suivante [Min68] : un objet A* est un modle dun objet A pour un observateur O dans la mesure o O peut utiliser A* pour rpondre aux questions quil
18
se pose sur A. Dans ce cas, O utilisera le modle A* comme support de raisonnement. Laction de modlisation permet donc de passer de lobjet du modle (A dans la dnition de Minsky) vers le modle (A*), travers un principe dabstraction visant simplier la reprsentation de lobjet modliser. Il est possible de poursuivre ce travail dabstraction pour crer des mta-modles. La cration dun mta-modle revient construire une reprsentation dun modle, toujours dans le but de fournir un support de raisonnement. Laction de mta-modlisation permet donc de passer du modle (A* dans la dnition de Minsky) vers le mta-modle (A**).

Figure 1.7 Activit de modlisation et de mta-modlisation dans les termes de Minsky. Comme le rsume la Figure 1.7, lobjet A** ne peut pas tre obtenu directement par modlisation de lobjet A, mais bien par la modlisation de lobjet A*. Cette relation dordre dans lactivit de modlisation fait apparatre des niveaux de modlisations distincts.
tel-00459925, version 1 - 25 Feb 2010
1.3.2
Mta-modlisation par composant
La principale notation pour la mta-modlisation par objet est le MOF (Meta Object Facility ) [Obj02]. LOMG a dni deux variantes de MOF : EMOF (MOF essentiel) et CMOF (MOF complet). Le but du MOF est de dnir un langage unique et standard pour dcrire des mtamodles. Il est constitu dun ensemble relativement restreint (bien que non minimal) de concepts "objets" permettant de modliser ce type dinformation. Par exemple, UML est lun des mtamodles dcris en utilisant le MOF 4 . Dautres notations pour la mta-modlisation objet existent. Parmi elles, on peut citer KM3 [JB06], ECORE [BMS08] ou Kermeta [MFJ05]. Trs peu de travaux ont t conduits dans la technique de mta-modlisation composant. AML (Architecture Meta-Language ) [Wil99] est une premire tentative de proposition dun socle pour fournir aux ADLs une solide base smantique. MADL (Meta Architectural description Language ) [SOK05] est une seconde tentative propose par notre quipe. MADL est lquivalent du MOF pour larchitecture logicielle. MADL inclut les concepts et les mcanismes des langages de description darchitecture, et conserve linstanciation, lhritage et la composition, issues de lorientation objet. 3 2 1 0 Niveau Niveau Niveau Niveau mta-mta-modle mta-modle modle instance Modlisation par objet MOF UML, CWM, SPEM, etc. Modles Informations Modlisation par composant MADL ACME, COSA, C2, etc. Architectures Applications
Table 1.1 Hirarchie selon une mta-modlisation par objet et par composant. En pratique, un mta-mta-modle dtermine le paradigme utilis dans les modles qui sont construits partir de lui. De ce fait, le choix dun mta-mta-modle est un choix important o la question de lobjet ou du composant comme unit de construction de base est pose.
4. UML 2.0 est parfois considr tord comme un langage de mta-modlisation car son diagramme de classes est proche du MOF.
19
En choisissant MADL, nous optons pour le composant et nous identions une hirarchie de modles architecturaux, comme le montre la table 1.1. Les quatre niveaux de modlisation dune architecture sont dtaills ci-aprs.
1.3.3
Niveaux de modlisation dune architecture
Nous identions quatre niveaux de modlisation dans les systmes : le niveau mta-mtaarchitecture, le niveau mta-architecture, le niveau architecture et le niveau application. Nous schmatisons ces niveaux sous forme dune "architecture gyptienne" prsente dans la Figure 1.8, o chaque tage de la pyramide se conforme ltage immdiatement suprieur.
tel-00459925, version 1 - 25 Feb 2010
Figure 1.8 Les quatre niveaux darchitecture que nous proposons.
Le niveau mta-mta-architecture (A3) : fournit les lments minimaux de modlisation dune architecture. Une mta-mta-architecture se conforme elle-mme (i.e., sauto dnie). Les concepts de base dun mta ADL sont reprsents ce niveau. Le niveau mta-architecture (A2) : fournit les lments de modlisation de base pour un langage de description darchitecture (ADL) : composant, connecteur, architecture, ports, rles, etc. Ces concepts de base permettent de dnir direntes architectures. Les mta-architectures se conforment aux mta-mta-architectures. Dans le cadre dune relation de conformit, chaque lment de A2 est associ un lment de A3. Le niveau architecture (A1) : ce niveau, plusieurs types de composants, de connecteurs et darchitectures sont dcrits. Les architectures se conforment aux mta-architectures (ADLs), donc chaque lment de A1 est associ un lment de A2. Le niveau application (A0) : est le niveau o les units dexcution sont localises. Une application est vue comme un ensemble de composants, de connecteurs et de congurations. Les applications sont conformes au niveau architecture. Chaque lment de A0 est associ un lment de A1.
20
1.3.4
Exemple illustratif
Pour donner une ide de lutilisation des dirents niveaux de modlisation, prenons lexemple dun systme de type client/serveur. Dune part la Figure 1.9 ne fais pas apparatre le niveau A3 (ce dernier prsentant peu dintrt pour notre travail) et dautre part, la relation de conformit entre deux niveaux de modlisation est ralise par un principe dinstanciation. Pour cet exemple, nous nous basons sur les concepts de lADL ACME, qui rie lensemble des lments architecturaux voqus dans ce chapitre et supporte une modlisation explicite des styles architecturaux appels familles. La notation graphique est celle du diagramme de composant dUML 2.0. Il est noter quavec cette notation le connecteur nexiste pas en tant que tel, mais est obtenu par un assemblage des concepts UML suivants : une interface et deux relations qui sont la ralisation et lusage.
cdefghipqrstpucvwxgtiwtqvi
tel-00459925, version 1 - 25 Feb 2010
'#&# 81)) $$Q" 2VWCV6567 XYC5
STU"#81)) $$Q"'# GP'QR '#&# 81)) $$Q" 2V665D7V@ XYC5
$$Q"'#&# àW43Y 81))
cyefghipq cvwxgtiwtqvi $$'#&# 23456781))
$$H"!bS)) %&$$0"& %( ' 1)) $$'#!# BCD81)) 81)) $$'#&# 95@A5@
cefghipq cgwptg EF' IF'
$$H"!bS)) $$%& ' % ()) # !" G#!%1H&F%(
Figure 1.9 Illustration des niveaux de modlisation de larchitecture dun systme de type client/serveur en ACME.
Le niveau mta-architecture (A2) : cest ce niveau que les lments de modlisation de lADL ACME sont dcrits. En loccurrence, ACME permet de dcrire des styles architecturaux appels familles (Family) travers la spcication de types de composants (ComponentType) et de types de connecteurs (ConnectorType) pour les relier.
21
Le niveau architecture (A1) : le style architectural client/serveur dans sa version simplie est spcie en ACME par la cration des types de composants client et server et du type de connecteur RPC (Remote Procedure Call ). Le niveau application (A0) : cest l que lon trouve lapplication proprement dite, constitue des deux composants clients Printer1 et Printer2, dun composant serveur DocSystem et des deux connecteurs RPC ncessaires leurs communications.
1.3.5
Bilan
tel-00459925, version 1 - 25 Feb 2010
On peut citer les ADLs qui distinguent les types des instances, dans lesquels chaque lment (i.e., interface, composant, connecteur) doit tre dni avant dtre instanci, et les ADLs qui permettent de dcrire directement ces lments. Selon le cas, larchitecture logicielle est dcrite sur un ou deux niveaux de modlisation. De manire gnrale, lacte de (mta)modlisation na pas imprgn les travaux de notre communaut o le terme "architecture" est surcharg, dsignant tantt le niveau A1, tantt le niveau A0. Lavantage de combiner une technique de mta-modlisation avec le domaine de larchitecture logicielle est de : aider la comprhension de la description de larchitecture logicielle ; identier des concepts ris de ceux qui ne le sont pas ; distinguer des liens entre les niveaux de modlisation. Dune part, cette vision de larchitecture logicielle est importante lorsque la problmatique de lvolution sera aborde dans le chapitre suivant. Dautre part, disposer dun rfrentiel commun comme celui schmatis par "larchitecture gyptienne" de la Figure 1.8 permet de communiquer sans ambiguts autour des architectures logicielles et de disposer dun vocabulaire partag. Par exemple, nous considrons que le terme de composant rfre au niveau A0, tandis que le terme de type de composant rfre au niveau A1. Ceci rejoint la distinction nette entre lobjet et sa classe dans la terminologie du paradigme objet.
1.4
Conclusion
Nous avons prsent dans ce chapitre le contexte global dans lequel sinscrit cette thse : le domaine des architectures logicielles base de composants. Nous avons montr comment larchitecture logicielle sest progressivement retrouve sur le devant de la scne, et quelles nouvelles pratiques dingnierie sont apparues avec elle. Pour mieux comprendre ce que recouvre larchitecture logicielle, nous avons synthtis les dnitions notables proposes dans la littrature. Nous avons galement consacr une section la notion de style architectural, que nous considrons comme un ingrdient cl du dveloppement centr architecture. Puis, nous avons abord les travaux sur les langages de description darchitectures, sur la base de leurs concepts communs. Nous avons cltur ce chapitre par la description de larchitecture logicielle travers ses dirents niveaux de modlisation. Les leons gnrales que nous tirons de ce vaste ensemble de travaux sur les architectures logicielles est que laccroissement de la complexit impose de monter en abstraction an de garder le contrle, pouvoir comprendre et communiquer autour dun systme. Par dessus tout, la capitalisation et la rutilisation des expriences passes via des solutions prouves est une
22
technique phare pour guider et amliorer les activits des architectes. Nous sommes convaincus que ces grands principes doivent tre ports au domaine de lvolution dans les architectures base de composants. En outre, nous sommes certains de la ncessit de prendre appui sur la mta-modlisation pour traiter correctement la problmatique de lvolution architecturale. Cette problmatique fait lobjet du chapitre suivant.
tel-00459925, version 1 - 25 Feb 2010
C HAPITRE
volution architecturale : analyse et synthse

tel-00459925, version 1 - 25 Feb 2010
Aprs avoir prsent dans le chapitre prcdent les dnitions des notions et concepts relatifs aux architectures logicielles, leurs langages de description ainsi qua leur mta-modlisation, nous abordons dans ce chapitre la problmatique de lvolution structurelle des architectures logicielles base de composants. Aborder la problmatique de lvolution au niveau de larchitecture permet larchitecte de raisonner un haut niveau dabstraction sur lajout, la suppression, la modication des composants et/ou des connecteurs ou encore la rorganisation de larchitecture, sans pour autant se noyer dans les dtails de limplmentation de ces lments. Clairement, les concepts et les mcanismes oerts un architecte pour spcier et grer lvolution de son architecture dpendent du modle dvolution considr. Un point de dpart vident de cette recherche consiste tudier les modles dvolution qui ont t proposs dans la littrature. Dans ce but, nous commenons par construire un cadre de comparaison pour pouvoir caractriser et comparer les dirents modles dvolution de manire indpendante les uns des autres. Ce cadre de comparaison prend la forme dune pyramide des besoins, en proposant une hirarchisation de ce que peut orir un modle dvolution. A chaque niveau de la pyramide des besoins sont associs des critres an dexhiber un certains nombre daspects que nous jugeons importants concernant lvolution. Dans certains cas, ces critres sont rans en sous-critres. Puis, nous proposons une analyse des principaux modles dvolution que lon trouve dans les travaux sur les ADLs de lcole amricaine, europenne et franaise. Nous nous appuyons sur cette analyse et sur la pyramide des besoins pour tablir un bilan rcapitulatif. Ce dernier souligne la fois les limites des modles dvolutions tudis et permet de poser les fondations dun nouveau modle dvolution qui sinscrira comme le cur de ce travail de thse.
2.1
volution architecturale
Lvolution logicielle a tendance tre progressive et incrmentale, dirige, par exemple, par les retours des utilisateurs ou dautres intervenants, sous la forme de rapports derreurs et de demandes de nouvelles fonctionnalits, ou plus gnralement, par les changements des exigences fonctionnelles ou non-fonctionnelles. La plupart des systmes logiciels sont donc exposs de nombreuses forces qui exigent leur modication. En consquence, le logiciel change continuellement. Ce phnomne invitable est appel volution logicielle [LB85], et a t soulign par 23
24
CHAPITRE 2 volution architecturale : analyse et synthse
les travaux de Lehman et al. ds les annes 70. En pratique, il ny a pas de dnition prcise et largement accepte de ce que doit tre lvolution logicielle, selon le niveau dabstraction et le niveau de granularit considr. Cependant, nous pouvons formuler trois observations majeures. Premirement, lvolution peut avoir lieu durant le dveloppement ou aprs la mise en exploitation du logiciel. Ce dernier cas est souvent assimil une activit de maintenance. Deuximement, lvolution se manifeste par des modications, trs simples ou trs complexes, jusqu la restructuration totale du logiciel. Troisimement, lvolution peut concerner les dirents artefacts produits lors du cycle de dveloppement du logiciel : code source, modle de conception, architecture, documentation, etc. Lorsque lvolution concerne spciquement larchitecture des systmes, on parle dvolution architecturale ou encore dvolution base architecture. Dans de nombreux systmes, lvolution architecturale peut fournir la capacit de modier lensemble des fonctionnalits oertes par le systme, dans un eort de personnalisation et dextensibilit attendue par les utilisateurs naux. Dans ce qui suit, nous explorons dans quelle mesure larchitecture logicielle ore une fondation saine pour aborder la problmatique de lvolution.
tel-00459925, version 1 - 25 Feb 2010
2.1.1
Motivation
Il existe direntes stratgies pour faire face lvolution. Lapproche classique en r-ingnierie consiste faire voluer les logiciels au niveau de leur code. Une approche plus rcente consiste faire voluer les logiciels au niveau de leur modle 1 . Ds lors quun systme dispose dune architecture explicite, cest--dire dun modle de son architecture, il est envisageable daborder la problmatique de son volution sur ce dernier. Nous qualions dvolution grande chelle (evolving-in-the-large ) lapproche qui consiste faire voluer un systme au niveau de son architecture plutt quau niveau de son code source. A linstar du glissement de paradigme qui sest opr pour le dveloppement des systmes complexes (cf. chapitre 1), le niveau architectural ore un niveau dabstraction et de raisonnement bien suprieur aux lignes de code, permettant larchitecte de dcider et de raliser des volutions densemble sur son systme. En outre, il est admis que le niveau architectural joue un rle bnque dans lvolution en exposant les dimensions (complexit, cots, etc.) selon lesquelles un systme peut voluer [Gar00a]. Ainsi, limportance de larchitecture logicielle pour lvolution des systmes devient de plus en plus vident.
2.1.2
Pour quels usages ?
Considrons un scnario dans lequel une socit dveloppe un logiciel innovant. Conformment aux bonnes pratiques du gnie logiciel, la socit dveloppe en premier lieu une bonne architecture pour son logiciel dans un style architectural appropri, puis modlise son architecture avec un ADL, rane ensuite larchitecture en une conception dtaille (e.g., via une mthodologie objet) et enn implmente lapplication (e.g., via une technologie objet). Le nouveau logiciel connat un succs immdiat et de nombreux exemplaires sont vendus. Motiv par ce succs, la socit entame un cycle davancements rapides, crant des "add-ons", vendant des mises jour, adaptant le logiciel direntes plateformes ou encore personnalisant lapplication pour dirents clients. Dans ce cas de gure, larchitecture volue pour reter lvolution du systme logiciel quil est cens reprsenter [MR97]. Une perte de synchronisation entre un sys1. Dans un certain sens, lvolution de modle englobe lvolution de code, au moins pour ceux qui considrent quun programme nest rien dautre quun type spcial (trs dtaill) de modle.
25
tme et son architecture appel phnomne drosion architecturale [PW92] remet en cause la valeur de larchitecture puisque cette dernire ne fourni plus une image dle du systme. Par ailleurs, les activits de maintenance logicielle ont t dplaces du niveau du code source vers le niveau de larchitecture. Le mise jour dun composant pour utiliser une toute nouvelle librairie par exemple, peut tre ralise en changeant ses connexions architecturales de faon ce quil soit li cette nouvelle librairie plutt que de changer le code source du composant. A travers le niveau dabstraction lev quils orent, les modles architecturaux sont plus faciles comprendre que les artefacts du niveau infrieur et fournissent une "vue densemble", essentielle dans la russite dune maintenance. En rgle gnrale, travailler ce niveau dabstraction est intressant si les changements impactent larchitecture du systme, comme cest souvent le cas avec de la maintenance perfective (qui reprsente prs de 65% des cots de maintenance [Som95]), mais plus rarement avec de la maintenance corrective ou adaptative.
2.1.3
tel-00459925, version 1 - 25 Feb 2010
Avantages et ds
Les architectures logicielles base de composants orent des ds intressants dans ltude de lvolution. Oreizy et al. [OT98] par exemple, mettent en avant plusieurs avantages rsultant directement de la gestion de lvolution au niveau de larchitecture : 1. Le contrle de la porte et de la politique des volutions est place entre les mains des architectes, o les dcisions peuvent ainsi tre prises sur la base dune vritable comprhension des exigences et de la smantique de lapplication. 2. Les architectes utilisent communment larchitecture logicielle pour dcrire, comprendre et raisonner de faon globale sur un systme. Valoriser la connaissance de larchitecte ce niveau dabstraction tend faciliter la gestion de lvolution. 3. Si aucune restriction particulire nest place sur la spcication interne des composants amens voluer, alors il devient possible daccueillir des composants sur tagres (COTS). 4. Les connecteurs facilitent la sparation du comportement spcique lapplication des dcisions relatives la porte et la politique des volutions, permettant ces derniers dtre modis indpendamments. Un autre point dintrt pour lvolution est le support de familles darchitectures partageant des caractristiques communes. Une faon de supporter les familles dans les ADLs est de sparer les types de composants et de connecteurs de leurs instances. Intuitivement, toutes les architectures issues de la mme famille voluent selon les mmes stratgies ou "patterns". Dautre part, il est noter que certaines familles dapplications sont amenes voluer plus facilement que dautres [Gom05]. Rcemment, on observe que lvolutivit est considr comme un attribut de qualit part entire des styles architecturaux [OMT08]. Des investigations en ce sens pourraient par exemple aboutir sur une meilleure comprhension des limitations places sur les types dvolutions acceptables par un style architectural donn.
2.2
Cadre de comparaison des modles dvolution
Une comparaison ddie lvolution dans les architectures logicielles est ncessaire an de bncier dune comprhension plus profonde de lvolution. Plusieurs classications et valuations ont t proposes dans le domaine de larchitecture logicielle [SG95, Cle96, MT00] mais le
26
travail eectu ne permet pas de comparer les architectures volutives car ils contiennent trs peu de critres relatifs lvolution. En fait, seul le travail de Medvidovic et al. [MT00] tient compte de lvolution dans son valuation. Si lon considre une taxonomie base sur lobjectif de lvolution, on peut citer les travaux de Lientz et Swanson [LS80], o ces derniers font la distinction entre la maintenance perfective, adaptative, corrective et prventive. galement, dans [CHK 01], on trouve une taxonomie de la maintenance et de lvolution divise en 12 catgories distinctes. Malheureusement, ces taxonomies dans le domaine de lvolution sont trop gnrales et manquent dinformations importantes au regard des problmatiques qui relvent du niveau architectural des systmes. An de rpondre au besoin de comparaison cibl, nous proposons un ensemble de critres bass sur les informations que nous dsirons comprendre concernant lvolution.
2.2.1
tel-00459925, version 1 - 25 Feb 2010
Pyramide des besoins
An de disposer dun outil dvaluation, nous dnissons une pyramide des besoins. La pyramide des besoins schmatise une hirarchisation dans les besoins traits par un modle dvolution. La pyramide est constitue de trois niveaux principaux (cf. gure 2.1). Un modle dvolution cherche satisfaire les besoins dun niveau donn avant de sattaquer aux besoins situs au niveau immdiatement suprieur de la pyramide. Ainsi, la base de la pyramide, on trouve lintention du modle dvolution, cest--dire les objectifs que ce dernier est en mesure dadresser. Au niveau immdiatement suprieur on trouve lexpressivit du modle dvolution. Les besoins en terme dexpressivit dterminent sa richesse smantique. Enn, le sommet de la pyramide concerne la qualit du modle dvolution, reprsentant la valeur ajoute du modle dvolution. Les besoins appartenant aux dirents niveaux sont expliqus en dtail dans les sections suivantes.
Figure 2.1 Pyramide des besoins traits par un modle dvolution. Il importe de remarquer que cette pyramide peut tre exploite pour valuer soit une problmatique dvolution, soit un modle dvolution. Dans le premier cas, la pyramide sert spcier des desideratas, en prcisant pour chaque niveau les besoins que lon souhaite associer lvolution architecturale. Dans le second cas, elle sert positionner et comparer les modles dvolutions. Pour ce travail danalyse et de synthse, nous nous situons dans le second cas.
2.2.2
Intention dun modle dvolution
Le premier niveau de la pyramide des besoins dtermine les objectifs possiblement traits par un modle dvolution. Selon Oussalah [Ous99], ces objectifs concernent la capacit (i) formuler lvolution, (ii) grer les impacts de lvolution et (ii) garder la trace entre le modle de
27
dpart (avant volution) et le modle darriv (aprs volution). Dans ce qui suit, nous donnons les dnitions thoriques que nous associons ces besoins.
2.2.2.1
Formuler lvolution
Notre vision est que toute volution dans une architecture est cause par des oprateurs dvolution qui peuvent tre appliqus sur des lments architecturaux, que nous qualions alors dlments volutifs. En outre, nous faisons une distinction entre les oprateurs simples et les oprateurs complexes. Les oprateurs complexes sont caractriss par le fait quils sont obtenus partir doprateurs plus simples. Une opration dvolution correspond la combinaison dun oprateur et dun ensemble dlments volutifs ncessaires son fonctionnement, qui jouent alors le rle doprandes. Cette vision est illustre travers la Figure 2.2.
qrstuvwxyz{x|}vwxy
tel-00459925, version 1 - 25 Feb 2010
noop defghilgmh
noop defghijkg
Figure 2.2 Trois concepts pour formuler lvolution : Opration, Oprateur et lement volutif. Nous avons rpertori dans le tableau 2.1 les types doprations dvolutions rcurrentes dans les ADLs pour formuler les changements dans une architecture logicielle. Ces types doprations sont volontairement dcrits un haut niveau dabstraction, an de rester indpendants dun ADL en particulier. On retrouve dans la partie suprieur du tableau les oprations que nous considrons comme simples, et dans la partie infrieure, les oprations considres comme complexes.
~
Table 2.1 Types doprations dvolution rcurrentes et leurs descriptions.
TYPE D'OPERATION
DESCRIPTION
28
2.2.2.2
Grer les impacts de lvolution
tel-00459925, version 1 - 25 Feb 2010
Un impact reprsente leet dun lment voluant sur un autre. Limpact peut tre pens comme la consquence dun changement. Ainsi, une volution locale peut tre reconsidre comme une volution globale, par lintermdiaire dun mcanisme de propagation dimpact. De ce point de vue, lvolution est un processus eet de bord, cest--dire que la modication dun lment entrane bien souvent de nombreuses autres modications sur dautres lments. Ainsi, identier tous les impacts dune volution revient sintresser la porte de celle-ci. La capacit de larchitecte dterminer la porte dune volution aide raisonner sur cette dernire. Limpact provoqu par une volution peut varier en importance et en type selon llment volutif concern. Un impact peut tre valu travers ses rpercussions sur un ou plusieurs aspects architecturaux. Les aspects peuvent tre structuraux (e.g., composants, connecteurs, et la topologie tel que le style architectural utilis, etc.), qualitatifs (e.g., les attributs de qualit tels que la performance ou la maintenabilit), ou bien encore conomique (les incidences en termes de cots). Basson et al. [Bas98] ont propos une typologie incluant les dimensions principales de tout impact : les impacts structurels, les impacts logiques, les impacts fonctionnels, les impacts qualitatifs, les impacts comportementaux. Dans cette thse, nous nous intressons exclusivement lvolution structurelle et donc aux impacts de type structurel. Les impacts structurels correspondent aux variations structurelles de lensemble des lments volutifs. Lvolution structurelle est dnie comme une modication de la structure dun lment volutif. Par exemple, la variation structurelle dune conguration correspond lajout ou le retrait de composants ou de connecteurs, etc. Une gestion ecace des impacts empche lintroduction dincohrences structurelles dans larchitecture. Par exemple, en labsence dun mcanisme de propagation dimpacts, la suppression dun connecteur laissera des attachements "ottants" dans larchitecture : elle nest plus cohrente. A linverse, si les attachements sont supprims par propagation, alors larchitecture demeure cohrente du point de vue structurel.
2.2.2.3
Garder la trace de lvolution
Cette troisime intention cherche garder trace de larchitecture ayant volue en conservant un enregistrement des modications architecturales tout au long de la dure de vie du systme. On parle parfois dans ce cas dvolution continue, par opposition de lvolution avec rupture [TO03]. Sont enregistres aussi bien les volutions atomiques que les volutions transactionnelles ; par exemple, une volution atomique serait laddition dun unique composant, tandis quune volution transactionnelle pourrait inclure laddition et la suppression de multiple composants et connecteurs. Ainsi, on peut voir les volutions dune architecture sous forme dun graphe orient indiquant les congurations architecturales connectes par les volutions qui les ont engendr (cf. gure 2.3). Un tel graphe peut tre dni comme un couple G = (N, E ), o N est un ensemble de noeuds reprsentant des congurations architecturales et E est un ensemble darcs unidirectionnels connectant les noeuds tel que E = {(x, y )|x, y N }. Les cycles cest--dire les chemins
29
Figure 2.3 Reprsentation schmatique des traces des volutions dans une architecture. commenant et terminant sur un mme noeud dans G sont admis an de reprsenter les volutions qui font passer un systme dans une certaine conguration existante, mais les boucles cest--dire les arcs ayant le mme noeud source et cible ne sont pas admis puisquils reprsentant des volutions qui nont dbouch sur aucun changement de conguration. Un seul et unique arc est admis entre les noeuds, car des volutions architecturales distinctes ne donnent pas lieu des congurations identiques, tandis que les arcs inverses cest--dire des arcs connectant les mme noeuds mais avec des directions opposes sont admis an de reprsenter des volutions qui ramnent le systme sa prcdente conguration.
tel-00459925, version 1 - 25 Feb 2010
2.2.3
Expressivit dun modle dvolution
Le second niveau de la pyramide des besoins traite du pouvoir expressif dun modle dvolution. Nous avons identis cinq besoins impliqus dans le pouvoir expressif : le niveau dabstraction, le mode dexpression, le domaine, le niveau de modlisation et la mcanique opratoire.
2.2.3.1
Niveau dabstraction
Le niveau dabstraction permet dexprimer les degrs de ranement dune volution, et ce depuis sa spcication, considr comme le plus haut niveau dabstraction, son implmentation reprsentant le plus bas niveau. Un ranement complet permet ainsi de reter les volutions dnies au niveau architectural vers le code source 2 . A chaque niveau dabstraction peut lui tre associ un niveau de transparence qui dnit le niveau de visibilit des dtails internes dune volution lors de sa rutilisation. Le niveau de transparence dune volution peut tre de type : Bote noire : lvolution est rutilise sans se soucier de son fonctionnement interne. Dans ce cas, il est impossible de la modier selon ses besoins. Cependant, la possibilit de remplacer une volution par une autre volution qui poursuit le mme objectif est oerte. Bote grise : il sagit dun niveau de transparence intermdiaire. Les dtails du fonctionnement dune volution peuvent tre rvls pour sa comprhension, mais ne peuvent tre sujets des modications manant de lextrieur. Bote blanche : lvolution rend transparent tous les dtails de son fonctionnement interne. Ce type dvolution a lavantage de fournir toute linformation relative sa mise en uvre, et peut tre modie selon les besoins.
2. Notons que, en ce sens, la gnration de code est simplement un cas spcial de ranement.
30
2.2.3.2
Mode dexpression
tel-00459925, version 1 - 25 Feb 2010
Le mode dexpression permet de dcrire les dirents modles de reprsentation dune volution (reprsentation textuelle, graphique, logique, code source, . . .). La description dune volution doit tre simple, comprhensible selon une smantique claire, mais pas ncessairement dnie de manire formelle. En eet, les volutions peuvent requrir dirents modes dexpression pour des usages dirents. Par exemple, une reprsentation graphique de haut-niveau dune volution peut tre utilise comme un moyen de comprhension et de communication ; une autre reprsentation formelle peut tre utilise pour analyser les interactions entre les volutions ; et encore une autre reprsentation lie une plateforme technologique cible pour pouvoir y excuter les volutions. Le mode dexpression dune volution dpend galement de sa granularit. La notion de granularit dvolution recouvre, selon les langages de reprsentation, aussi bien des oprations atomiques que de vritables oprations complexes. Du point de vue de la granularit, nous pouvons citer : les volutions dites simples ou de ne granularit : la granularit dune volution est lie une construction syntaxique de lADL, comme les primitives dajout, de suppression, dattachement et de dtachement. Dans ce cas, lassemblage des volutions est la charge de larchitecte. les volutions dites complexes ou forte granularit : lvolution sapparente une vritable tche complexe, obtenue par assemblage dvolutions existantes, elles-mmes simples ou complexes. Dans ce cas, larchitecte rutilise des volutions compltes, rduisant ainsi son travail dassemblage.
2.2.3.3
Domaine
Le domaine rete les direntes volutions structures en couches. Cette structuration permet une volution appartenant une couche particulire de ne pouvoir interagir quavec seulement les volutions de la mme couche ou de la couche adjacente. Les volutions du tout domaine constituent la couche de plus bas niveau et sont indpendant du domaine dapplication. Au niveau plus haut (domaine connexe), on trouve des volutions appartenant des domaines connexes lapplication en cours de construction. Enn, en haut de la hirarchie, les volutions de mon domaine sont spciques au domaine dapplication choisi. In ne, le domaine caractrise la porte des volutions, i.e. leur de degr de rutilisabilit. Nous pouvons recenser : Les volutions gnralistes ou indpendantes dun domaine : ce sont des volutions gnrales qui ne dpendent pas dun domaine particulier. Ce type dvolution est engendr par des rutilisations sur des architectures quelconques. Les volutions ddies ou dpendantes du domaine : ce sont des volutions rutilisables travers les applications dun mme domaine. Ce type dvolution est engendr par des rutilisations au sein dune famille darchitectures. Les volutions orientes application : ce sont des volutions spciques une application donne. Elles sont peu rutilisables. Ce type dvolution est gnralement engendr par des rutilisations ad-hoc non planies sur une architecture.
2.2.3.4
Niveau de modlisation
Comme nous lavons vu au chapitre prcdent, la description dune architecture logicielle peut se faire au travers de trois niveaux de modlisation : le niveau mta-architecture (A2), le niveau
31
tel-00459925, version 1 - 25 Feb 2010
architecture (A1) et le niveau application (A0). Le niveau architecture est le niveau de description de famille dapplications en instanciant un ou plusieurs concepts du niveau mta. Le niveau application dcrit le systme en instanciant un ou plusieurs lments du niveau architecture. Comme cela est mentionn fort justement par Medvidovic et al. [MR97], il existe des besoins dvolution au moment de la spcication et au moment de lexcution de larchitecture logicielle. Dans le cadre de la mta-modlisation, ces besoins correspondent respectivement de lvolution au niveau architecture et au niveau application. Nous pouvons ainsi identier : Lvolution au niveau A1 : en considrant que les types de composants et les types de connecteurs sont instancis chaque fois quils sont utiliss dans une architecture, leur volution peut tre vue simplement en terme de sous-typage. Par exemple, il peut tre utile de faire voluer un mme composant de plusieurs faons, travers dirents mcanismes de sous-typage. Lvolution ce niveau peut aussi prendre la forme de "refactorings" ou encore viser introduire des motifs architecturaux pour amliorer la conception de larchitecture. Lvolution au niveau A0 : la modlisation explicite des architectures est destine supporter le dveloppement et lvolution de grands systmes, ayant potentiellement une longue dure dexcution. tre capable de faire voluer de tels systmes durant leur excution peut tre souhaitable et, dans certains cas, vital. Lvolution ce niveau vise le dynamisme des architectures en permettant la rplication, linsertion, le retrait, et la reconnexion dlments architecturaux ou de sous-architectures lexcution.
2.2.3.5
Mcanique opratoire
La mcanique opratoire concerne les dispositifs oerts pour spcier et grer lvolution. On peut citer par exemple la possibilit de spcialiser, combiner ou encore instancier des volutions. Ces mcanismes, quand ils existent, sont associs un mode de raisonnement pour les faire fonctionner. Classiquement, on distingue le raisonnement dductif, inductif, abductif, classicatoire, analogique, etc. Reli ce dernier point, le cur de la mcanique opratoire peut tre centralis ou au contraire tre distribu. Nous distinguons deux types de mcanique opratoire : Une mcanique basique : les volutions proposes sont livres telles quelles avec lADL. Toute la mcanique est "cable" par avance. Une mcanique avance : les volutions doivent tre crites selon les besoins. Une mcanique est fournie dans ce but.
2.2.4
Qualit dun modle dvolution
Le troisime et dernier niveau de la pyramide des besoins traite des qualits et des caractristiques qui doivent tre raisonnablement satisfaites par un modle dvolution, soit : 1. La rutilisabilit (R) : reprsente le degr de rutilisation oert par un modle dvolution. 2. Le support (S) : exprime la facilit de supporter lvolution dune application selon un modle dvolution donn. 3. Ladaptabilit (A) : exprime laptitude contrler et permettre un modle dvolution de sadapter dynamiquement. 4. La performance (P) : exprime la vitesse dexcution dune volution implmente suivant un modle dvolution donn.
32
Supposons que R(p), S (p), A(p), P (p) reprsentent respectivement la rutilisabilit, le support, ladaptabilit et la performance en fonction du degr de paramtrage p et , , , reprsentent les poids associs respectivement R(p), S (p), A(p), P (p) pour favoriser un critre sur un autre. On peut alors noter que la qualit dun modle dvolution donn (QM E ) peut tre exprime par : QM E = R(p) + S (p) + A(p) + P (p) Par ailleurs, pour accrotre la rutilisabilit R(p) dun modle dvolution, certains critres sont prconiss comme lextensibilit, lvolutivit, la compositionalit et la remplaabilit. 1. Lextensibilit : traduit le fait, par exemple, que lajout dune volution sappliquant un lment volutif ninterfre pas avec les autres volutions de cet lment. 2. Lvolutivit : signie, par exemple, quune volution est rutilisable et son fonctionnement peut tre mise jour sans impact sur les volutions lutilisant.
tel-00459925, version 1 - 25 Feb 2010
3. La compositionalit : est obtenue, par exemple, si une volution inclut dautres volutions et dlgue sa fonctionnalit ses volutions internes. 4. La remplaabilit : est la possibilit de remplacer une volution par une autre volution qui ore la mme fonctionnalit.
2.3
tude des modles dvolution existants
Pour notre tude, nous retenons un certain nombre dapproches et leurs ADLs issus des communauts acadmiques amricaine, europenne et franaise. A travers la manire de spcier et de grer lvolution, chaque approche incarne un modle dvolution particulier. La slection de ces approches a t base sur leur notorit (i.e., les plus rfrencs dans la littrature) et/ou sur leur volont ache traiter la problmatique de lvolution dans les architectures. En outre, la rpartition des approches par cole acadmique ore une classication transversale des travaux sur lvolution architecturale. Dans les sections suivantes, pour chaque approche nous apportons : Une prsentation de lADL auquel elle est associe, au travers notamment des principaux concepts structuraux de cet ADL, Une analyse des possibilits dvolution oertes, Un positionnement vis--vis des trois niveaux de la pyramide des besoins.
2.3.1
Approches de lcole amricaine
Nous prsentons dans cette partie les approches dvolution proposes par les ADLs C2, Dynamic Wright et Dynamic ACME.
2.3.1.1
C2
Strictement parlant, C2 est le paradigme de conception architecturale, alors que le nom de lADL associ est C2-SADL (Software Architecture Description Evolution Language) [MRT99]. Par souci de brivet, nous ferons rfrence ce langage simplement comme C2. Dans C2, les composants et les connecteurs sont tous deux des citoyens de premire classe, et le passage de message est utilis pour relier les composants entre eux travers des connecteurs, sous rserve
33
de certaines restrictions. C2 supporte un mcanisme de composition hirarchique pour crer des composants composites. En outre, les connecteurs peuvent eectuer le ltrage des messages, de manire facultative. Lvolution dans C2 C2 permet de lier (souder dans le jargon C2) dynamiquement des composants avec les connecteurs, ainsi que de les dlier. Toutes les possibilits de reconguration ou de recblage dune architecture sont autorises : il est possible de dlier un composant dun autre, de le relier un autre, de le laisser dli mais persistant dans le systme, ou de le supprimer dnitivement du systme. Il est noter que la caractristique intressante de C2 est que la reconguration dynamique est accomplie en utilisant le passage de message entre composants, au mme titre que la communication ordinaire entre eux. Dautre part, un connecteur du style C2 est intrinsquement volutif du fait quil nimpose pas une interface spcique, cette dernire sadaptant en fonction des composants qui sattachent et se dtachent delle. Les recongurations sont spcies dans un (sous)langage de modication darchitecture (Architecture Modication Language AML). Il sagit dun langage de script pouvant contenir les oprations suivantes : addComponent, removeComponent, weld, et unweld. On remarque que C2 ne supporte pas explicitement lajout et le retrait de connecteurs. A la place, ces oprations sont ralises implicitement en fonction des liaisons et dliaisons. Par exemple, on considre la suppression tacite dun connecteur lorsque celui-ci ne possde plus aucune liaison avec des composants. En outre, C2 propose aussi un mcanisme de sous-typage pour lvolution des types de composants. Les auteurs dnombrent plusieurs dclinaisons de ce mcanisme, pouvant porter sur le nom, linterface, le comportement ou limplmentation. Le sous-typage htrogne est alors la combinaison de ces sous-typages par les clauses and, or et not. Enn, il est important de mentionner que C2 possde un oprateur particulier, upgrade, visant amliorer un composant. Cette opration consiste sous-typer le composant, modier le sous-type, et remplacer les anciennes instances par les instances du nouveau type. Positionnement de C2 Niveau 1 C2-SADL soccupe de formuler les volutions dans une architecture. La conservation de la trace des volutions nest pas gre dans C2. On peut considrer que C2 possde une gestion dimpacts dans le cadre de son oprateur damlioration (upgrade), qui prcise limpact de lvolution dun type sur ses instances. Niveau 2 C2-SADL adresse le niveau spcication des architectures quil dcrit, mais propose travers lenvironnement DRADEL un ranement vers du code Java. A laide dAML, larchitecte exploite au sein dun script des primitives dont il ne connat pas le fonctionnement interne. De plus, le script obtenu ne constitue pas une nouvelle volution rutilisable. C2-SADL est entirement ddi aux systmes logiciels qui emploient le style architectural C2. La plupart des GUI (Graphic User Interface ) et les applications distribues sont structurs autour du style C2 [TMA 95]. Cette dpendance au style C2 sexprime par exemple travers les primitives weld/unweld qui fonctionnent implicitement sur des ports et rles de type bottom et top dnis par le style C2. Nous lavons vu, C2 supporte lvolution au niveau des types et au niveau des instances, voire les deux simultanment via loprateur damlioration.
tel-00459925, version 1 - 25 Feb 2010
34
Niveau 3 Le modle dvolution choisi par C2 ne permet pas la rutilisatibilit ni ladaptabilit, mais la mise en uvre dans ce langage est plutt aise.
2.3.1.2
Dynamic Wright
Wright [All97] permet danalyser la fois larchitecture de systmes logiciels individuels et de familles de systmes. Wright a aussi explor la nature des abstractions architecturales en ellesmme. En particulier, le travail sur Wright sest concentr sur le concept de type de connecteur explicite, sur la validation automatique de proprits architecturales, et sur la formalisation des styles architecturaux. LADL Wright est construit autour de trois principaux concepts architecturaux : les composants, les connecteurs et les congurations. Lvolution dans Dynamic Wright Wright na pas t construit au dpart pour spcier et analyser la dynamique dune architecture logicielle. Cependant, une approche propose dans [ADG98] le permet. Le rsultat, dnomm Dynamic Wright, inclut certaines fonctionnalits pour aider dcrire le dynamisme. Dynamic Wright reprsente la structure dune architecture comme un graphe dans lequel les composants et les connecteurs sont des noeuds, et spcie le comportement et la reconguration dun systme dans une variante de lalgbre de processus. En fait, Wright a adopt une approche similaire la reconguration conditionnelle propose par lADL Rapide [LV95] : il fait la distinction entre la communication et les vnements de contrle, o ces derniers sont utiliss pour spcier des conditions sous lesquelles les changements dynamiques sont autoriss [ADG97]. Le "Congurateur" est responsable de lapplication des changements la conguration architecturale par le biais des actions de cration ou de destruction de composants et de connecteurs (new, del) et de cration ou de destruction de liaisons (attach, detach). Positionnement de Dynamic Wright Niveau 1 Dynamic Wright adresse la formulation des volutions, mais ne traite pas la gestion des impacts ni la trace de lvolution. Niveau 2 Wright peut tre utilis pour fournir une signication prcise et abstraite une spcication architecturale. Un travail important a t men an danalyser un assemblage de composants, mais les problmatiques lies la gnration de code ont t ignores. Dynamic Wright met laccent sur la spcication du comportement dynamique : cration, suppression, interconnexions qui se modient dynamiquement. Des lments de reconguration, constituant un vocabulaire de contrle, ont pour cela t ajouts au vocabulaire de base. Les rgles de reconguration dnies par larchitecte ne peuvent pas tre rutilises, et ce dernier ne peut pas connatre ni modier le fonctionnement prdni des actions de cration ou de destruction. Dans Dynamic Wright, le congurateur centralise le raisonnement en slectionnant les rgles appliquer en fonction de proprits, etc. Par ailleurs, Wright sest intress la notion de style architectural en distinguant les types des composants et des connecteurs de leurs instances. Ces types peuvent voluer par un mcanisme de composition hirarchique. Niveau 3 Le modle dvolution propos par Dynamic Wright nest ni rutilisable, ni adaptable et repose sur des notations diciles daccs pour un architecte novice.
tel-00459925, version 1 - 25 Feb 2010
35
2.3.1.3
Dynamic Acme
ACME est considr comme un ADL pivot (ou ADL dchange [GMW97]) capable dincorporer les fonctionnalits des autres ADLs, permettant ainsi aux utilisateurs dexprimer des choses quils auraient pu exprimer dans nimporte lequel des autres langages. ACME reprsente un plus petit dnominateur commun qui inclut les aspects des descriptions architecturales partags par tous les ADLs. ACME ore des constructions pour dcrire des architectures (appeles systmes) comme des graphes de composants et de connecteurs, un mcanisme de reprsentation pour la dcomposition hirarchique des composants et des connecteurs en sous-systmes, ainsi quun moyen de dcrire des familles et des types dlments sur la base de ces constructions. Pour assurer son statut de langage dchange, les lments peuvent tre annots par des proprits qui reprsentent des informations descriptives (e.g., comportement, code source) auxquelles les outils ou personnes devront donner une interprtation adquate. Lvolution dans Dynamic Acme ACME ne fournit aucun moyen de spcier de manire simple et claire la dynamique dun systme. En eet, le systme est dcrit comme un ensemble dinstances de composants relies entre elles par des connecteurs. Cependant, cette description de lassemblage reste ge. Aucun moyen nest fourni pour spcier les changements de lapplication au cours de son xcution. Dynamic ACME [Wil01a] est une extension ACME pour modliser les architectures dynamiques. Dune part, Dynamic ACME distingue deux catgories dlments architecturaux, ceux ouverts aux modications (mot cl open), et ceux qui ne le sont pas. Les lments ouverts peuvent tre sous-typs par exemple. Dautre part, Dynamic ACME introduit les notions dlments optionnels et dlments multiples, qui jouent le rle de quanticateurs sur le nombre dinstances possibles. Un outil a t propos pour assister larchitecte, nomm AcmeStudio. Malheureusement, loutil na pas suivi la progression du langage et les nouveauts de Dynamic ACME nont pas t intgres. Positionnement de Dynamic Acme Niveau 1 Dynamic Acme sintresse la formulation de lvolution uniquement. Niveau 2 En tant quADL pivot, ACME ne sintresse pas aux problmatiques de niveau code et du ranement dune architecture dcrite en ACME. Dynamic ACME est davantage conu pour matriser lvolution que pour la spcier, et se focalise sur le niveau des types de composants et de connecteurs. Dailleurs, les insusances dACME en terme de reconguration dynamique ont donn naissance des extensions comme dans [CGS 02] ou [BJC05]. Les quelques mcanismes dvolutions proposs par ACME/Dynamic ACME sont "cabls" dans lADL et ne permettent que des volutions de ne granularit. Niveau 3 Le modle dvolution de Dynamic Acme nest ni rutilisable, ni adaptable mais les constructions dvolution du langage sont simples apprhender.
tel-00459925, version 1 - 25 Feb 2010
2.3.2
Approches de lcole europenne
Nous prsentons dans cette partie les approches dvolution proposes par les ADLs Darwin, xADL 2.0 et SOFA.
36
2.3.2.1
Darwin
Darwin [MK96] supporte les composants mais pas les connecteurs en tant que citoyens de premire classe (cest--dire des connecteurs implicites). Les composants sont instancis partir de leurs types, et le sous-typage peut tre utilis pour construire des composants plus spciques partir de composants gnriques. Chaque type de composant est dcrit en termes de services quil fournit et de services dont il a besoin. Darwin permet aussi de dnir des composants composites obtenus partir de composants simples. Les services sont spcis en utilisant le -calcul, tandis que la conguration est spcie en liant les services requis par un composant aux services fournis par un autre composant, en utilisant loprateur bind. Cette liaison ne peut avoir lieu que si les types des services mis en jeu sont compatibles. Lvolution dans Darwin Darwin permet aux composants dtre instancis, et leurs services lis, soit statiquement soit lexcution. Dans ce dernier cas, deux options sont disponibles. Avec loption dinstanciation paresseuse, un lment nest pas instanci jusqu ce quun autre composant demande utiliser ses services. Toutefois, les types des composants participants et les liaisons entre eux doivent tre spcis au pralable. De cette manire, le systme peut voluer au moment de lexcution, mais la manire dont celui-ci volue est x lors de la conception. Lautre option, connue sous le nom dinstanciation dynamique directe, permet des structures dvoluer de faon arbitraire au moment de lexcution. Toutefois, si les composants instancis dynamiquement dsirent interagir, les options disponibles sont limites. Notamment, si ces lments souhaitent interagir directement, ils doivent changer les informations pertinentes (cest--dire, les rfrences aux services) travers une tierce partie, qui nappartient pas au langage en soi mais sa plateforme dexcution nomme Regis. Dans les deux cas, les liaisons sont permanentes et ne peuvent tre dfaites. En dautres termes, les architectures spcies dans Darwin peuvent grossir, mais elles ne peuvent pas diminuer 3 . Positionnement de Darwin Niveau 1 La formulation de lvolution fait partie des proccupations de Darwin, contrairement la conservation de la trace de lvolution. La dynamique dans Darwin repose sur les schmas dinstanciation dcris au pralable. On peut voir dans cette approche une forme de gestion des impacts puisque il nest pas ncessaire de spcier explicitement les connexions entre des composants nouvellement crs par exemple. A chaque instanciation dun composant, et conformment au schma dinstanciation donn, Darwin cr automatiquement les connexions ncessaires. Niveau 2 Darwin accepte un ranement des spcications vers la plateforme Rgis qui fournit un cadre crit en C++. Lvolution dans Darwin est supporte au niveau des types ou des instances. Dans les deux cas, larchitecte passe par des constructions non modiables et de ne granularit. Niveau 3 Le modle dvolution incarn par Darwin ne favorise pas la rutilisabilit, pas plus que son adaptabilit. Dautre part, lapproche par schma dinstanciation rend peu naturel la spcication et la gestion de lvolution dans larchitecture.
3. Peut tout de mme se faire au niveau langage de programmation
tel-00459925, version 1 - 25 Feb 2010
37
2.3.2.2
xADL 2.0
xArch est une reprsentation commune base sur le format XML pour la description darchitecture qui peut tre tendue dautres ADLs existants (voir les extensions ACME, C2 et Darwin proposes dans [DRM00]). Il contient les lments primitifs qui composent une description darchitecture dun point de vue structurel. xADL 2.0 est un ADL bas sur xArch qui est dni comme un ensemble de schmas XML [DHT01]. Lvolution dans xADL 2.0 Parmi les schmas proposs par xADL, le schma de conception architectural (Structure and Types Extension ) spare la description architecturale en deux blocs : les types et la structure. Le premier permet de dcrire les types (possiblement composites) de composants, de connecteurs et dinterfaces tandis que le second permet de prescrire les instances de ces types dans une architecture. Lvolution est disponible par lintermdiaire de loutil ArchStudio 4, o il est possible dajouter ou de retirer des types et des instances dlments architecturaux. Ceci se fait de manire transparente grce une API pour la manipulation de documents XML. Grce des schmas spciques, lvolution dans xADL prend galement la forme dune gestion de conguration traditionnelle, comme la spcication des options, des versions et des variantes, applique aux lments architecturaux et larchitecture elle mme. Positionnement de xADL 2.0 Niveau 1 xADL 2.0 traite de la formulation des volutions dune part, et de la conservation de la trace de lvolution dautre part. Ce dernier point repose sur les notions de versions, de variantes et doptions sur les types dlments architecturaux. Il existe par ailleurs MAE [RHMRM04], un environnement construit autour de xADL 2.0 et orant un systme complet de gestion de versions. Niveau 2 ArchStudio 4, lenvironnement de dveloppement associ xADL2.0 sappuie sur une technique de Data Binding 4 pour grer le ranement. Le Data Binding consiste produire du code orient objet (en loccurrence du code Java) partir des items XML ; ceci en drivant de faon systmatique des classes et des interfaces en correspondance avec le contenu des schmas. En soi, xADL 2.0 est un ADL gnraliste. Cependant, il est conu ds le dpart pour tre spcialis par les utilisateurs an doptimiser le langage pour des domaines particuliers (e.g., une extension a t cre par le Jet Propulsion Laboratory de la NASA). Nanmoins, les volutions pr-dnies par ArchStudio elles, restent gnralistes. Le fonctionnement de ArchStudio et travers lui des oprations dvolution est opaque et les scnarios dvolution construits de la sorte ne sont pas capitalisables pour une rutilisation ultrieure. Niveau 3 Le modle dvolution propos par xADL 2.0 ne tient pas compte de la rutilisabilit et de ladaptabilit. Toutefois, lutilisation du formalisme XML et dun outil graphique ore un bon support pour lvolution.
4. xArch/xADL 2.0 Data Binding Library
tel-00459925, version 1 - 25 Feb 2010
38
2.3.2.3
SOFA
SOFA [PBJ98] est un projet visant orir une plateforme pour les composants logiciels. Dans SOFA, les applications sont cres en assemblant des composants et des connecteurs. SOFA est un modle hirarchique, cest--dire que les composants peuvent eux-mme tre composs dautres composants ou bien ils peuvent tre des briques de base contenant directement une implmentation. Le composant ou le connecteur est dcrit par sa "frame" (vue boite noire) et son "architecture" (vue boite grise). Ces concepts sparent respectivement la notion de type de la notion dinstance. Notons au passage que le nom exact de lADL dans SOFA est CDL (Component Denition Language ), bas sur IDL (Interface Denition Language ) dni par lOMG. Lvolution dans SOFA Une application au sens SOFA contient une liste des instances des composants et des connecteurs ainsi que leurs liaisons. Mme si il est possible de remplacer un composant chaud par le bais de la plateforme dexcution DCUP, la description de lassemblage ne peut pas tre modie. Cependant, SOFA a mis laccent sur la gestion de versions. Un entrept (le template repository ) contient les implmentations des composants (binaires) et leur description abstraite (CDL). Lentrept dispose dun mcanisme de gestion de version permettant dy ranger direntes versions des composants. Ce systme est trs intressant au niveau du suivi de lvolution dune architecture logicielle. Une extension de cet entrept et de ses mcanismes est par ailleurs propose dans [MH01]. Positionnement de SOFA Niveau 1 SOFA traite de la formulation de lvolution et se focalise sur la gestion de versions pour permettre de garder une trace dune volution lie laction de larchitecte. Les impacts ne sont pas traits dans SOFA. Niveau 2 SOFA propose la spcication dune architecture adapte sa mise en oeuvre de rfrence : DCUP (uniquement en Java pour le moment). En eet, SOFA est issu dune quipe qui a beaucoup travaill dans le domaine des objets rpartis et qui sest logiquement attache orir une structure daccueil correspondant au modle de composant de SOFA. SOFA propose une approche statique de la description dune architecture logicielle comme un assemblage de composants un instant t. Ainsi, SOFA gre lvolution des types de composants et de connecteurs mais pas celui des instances. Pour faire voluer ses types, larchitecte se repose sur des volutions de type boites noires, sans possibilits de raliser des assemblages dvolutions. Dans ce cadre, la mcanique opratoire est basique. Niveau 3 Le modle dvolution promu par SOFA nest pas rutilisable ni adaptable mais lutilisation du mcanisme de gestion de version est assez simple et bien outill.
tel-00459925, version 1 - 25 Feb 2010
2.3.3
Approches de lcole franaise
Nous prsentons dans cette partie les approches dvolution proposes par Archware, SAEV et TranSAT.
39
2.3.3.1
ArchWare
Le but du projet ArchWare est de fournir un environnement de dveloppement centr architecture pour la construction de systmes volutifs. La famille de langages ArchWare ADL propose, entre autres, un langage composant-connecteur appel ArchWare C&C-ADL. Le modle de composant sous-jacent est hirarchique (i.e., distinction entre composant atomique/composite) et traite les composants et les connecteurs comme des lments de premire classe. Lvolution dans ArchWare Les architectes peuvent utiliser les capacits de ArchWare C&CADL pour reprsenter des architectures dynamiques [MKB 04]. Lvolution dune architecture ou sous-architecture est prise en compte par un lment ddi, le "chorgraphe". Ce dernier est en charge de changer la topologie en cas de besoin : changer les attachements entre lments architecturaux, crer dynamiquement de nouvelles instances, exclure des lments de larchitecture, en inclure dautres, etc. La spcication de la partie chorgraphique sajoute la spcication de la conguration initiale de larchitecture. On peut utiliser dans cette spcication les oprations new (composant et connecteur), attach et detach. En outre, ArchWare peut aussi traiter lvolution non prvue dans une architecture, en intgrant un composant spcial ddi lvolution et en sappuyant sur une machine virtuelle. Ce composant particulier nomm "evolver" peut tre sollicit par une architecture lorsquune volution doit avoir lieu, et rpond en faisant transiter des lments architecturaux comme nimporte quelle donne. Un pr-requis est que ces lments aient t dcrits dans un chier qui est alors charg dynamiquement par la machine virtuelle. ArchWare inclut un langage nomm ARL (Architecture Renement Language ) ddi au ranement darchitectures. Parmi les deux modes de ranement supports, le ranement horizontal est utilis pour inclure ou exclure des lments dune spcication dorigine. Ainsi, ARL fournit un ensemble doprations appeles actions de ranement pour lvolution darchitecture. ArchWare inclue galement ASL (Architecture Style Language ), un langage ddi la dnition de styles architecturaux en fournissant des types de composants et de connecteurs, ainsi que leurs contraintes. ASL met en place deux mcanismes dvolution sur les styles : lhritage et lagrgation. Positionnement de ArchWare Niveau 1 ArchWare soccupe de la formulation de lvolution uniquement. Niveau 2 Certes ARL supporte un ranement vertical, mais celui-ci est cantonn au niveau de la spcication de larchitecture. Lvolution des types, comme lvolution des instances est supporte dans C&C ADL. Dans ce dernier cas, lutilisation du chorgraphe repose sur une gestion centralise de lvolution. Malgr un langage consacr la dnition de styles architecturaux et donc de familles darchitectures, les volutions proposes sont de natures gnralistes. En outre, les volutions dcrites ne sont pas rutilisables dans des stratgies plus complexes, et les primitives proposes sont de type boites noires. Niveau 3 Le modle dvolution de ArchWare nore pas la rutilisabilit ni ladaptabilit. Les notations sur lesquelles repose le modle dvolution de ArchWare sont assez fastidieuses.
tel-00459925, version 1 - 25 Feb 2010
40
2.3.3.2
SAEV
SAEV est un modle dvolution gnrique, uniforme et indpendant de tout ADL, permettant la spcication et la gestion de lvolution des architectures logicielles [SH07]. Lide est dassocier des stratgies dvolution chaque lment dune architecture. Une stratgie dvolution sur un lment regroupe des rgles dvolution le concernant, cest--dire les oprations applicables ce dernier. Une rgle dvolution est dclenche lorsquun vnement prcis survient et selon certaines conditions (on parle de rgles actives). Lvolution dans SAEV Lvolution dynamique dans SAEV repose sur un ensemble de rgles dnies par larchitecte, et associes aux dirents lments architecturaux. Puisque que la dmarche de mta-modlisation est prsente dans SAEV, lvolution statique est prise en compte en r-appliquant les mmes mcanismes au niveau de modlisation suprieur. La description des rgles dans SAEV repose sur le formalisme ECA (vnement-Condition-Action). Ainsi, chaque rgle est compose dun vnement, dune condition et dune action. La partie vnement reprsente le message dinvocation pouvant tre mis par larchitecte ou par une autre rgle. La partie condition exprime ce qui doit tre ncessairement vri pour pouvoir excuter la rgle. Enn, la partie action, dcris une opration dvolution simple (ajout, modication, suppression) ou des vnements an de dclencher dautres rgles. Ainsi, le chanage avant des rgles permet de dterminer les impacts propager. Positionnement de SAEV Niveau 1 SAEV a pour objectif de formuler les volutions et de grer leurs impacts. SAEV sest concentr sur la gestion des impacts en supportant lenchanement des rgles par lintermdiaire dmissions et de rceptions dvnements de mme nature. Niveau 2 SAEV se veut indpendant dun ADL particulier et laspect implmentation a logiquement t relgue au second plan. Le fonctionnement de SAEV ncessite un moteur de rgles, appel "gestionnaire dvolution", qui centralise lensemble du raisonnement. Chaque rgle peut tre modie selon les besoins, soit dans sa partie vnement et condition, soit dans sa partie action. Les rgles peuvent concerner aussi bien des types dlments architecturaux que leurs instances. Il est noter quen plus du formalisme ECA, les auteurs ont propos une notation graphique des rgles dans lenvironnement AGG [Tae00]. Dans cet environnement, les architectures sont reprsentes par des graphes et chaque rgle est reprsente implicitement en dnissant deux morceaux de graphe : une partie gauche (LHS - Left Hand Side ) dcrivant la situation avant volution et une partie droite (RHS - Right Hand Side ) dcrivant la situation aprs volution. Niveau 3 Le modle dvolution de SAEV permet la rutilisabilit mais pas ladaptabilit. La simplicit reconnue du formalisme ECA ore un bon support pour lvolution.
tel-00459925, version 1 - 25 Feb 2010
2.3.3.3
TranSAT
TranSAT [BD04] est considr comme un canevas de conception darchitecture qui permet lintgration de nouvelles proccupations dans une architecture par transformation de cette der-
41
nire. Larchitecture de base est spcie laide de SafArchie ADL, reposant sur cinq concepts architecturaux (composant composite, composant primitif, liaison, port, opration) ainsi que sur la notion de contrat. TranSAT propose un langage ddi pour spcier les modications apporter sur larchitecture de base an dintgrer la nouvelle proccupation. Lvolution dans TranSAT Inspir par les technologies des aspects, TranSAT introduit la notion de patron darchitecture pour structurer les direntes proccupations transverses dune architecture. Ce patron comprend les lments intgrer, les transformations apporter larchitecture de base, mais aussi un ensemble de contraintes gnriques sur les lments dune architecture cible sur laquelle le patron peut tre intgr. En particulier, le langage oert pour exprimer les rgles de transformation adresse lvolution structurelle travers un ensemble de douze primitives. Il sagit doprateurs dajout, de suppression et de dplacement appliqus aux composants (primitifs ou composites) et aux liaisons, ainsi quaux ports et leurs oprations. Volontairement, aucune structure de contrle nest fournie pour combiner les rgles an de permettre une analyse statique de limpact de lintgration de la proccupation. Ces rgles sont regroupes dans un script qui sera utilis entre autres choses par un moteur de transformation nomm "tisseur" pour produire une nouvelle description darchitecture logicielle. Positionnement de TranSAT Niveau 1 TranSAT permet de formuler lvolution, mais ne gre pas les impacts, pas plus quil ne garde la trace de lvolution. Niveau 2 Clairement, TranSAT travaille au niveau de la spcication dune architecture. Les primitives la disposition de larchitecte sont fournies avec le tisseur sans quil soit possible den modier ni de comprendre le fonctionnement. Par ailleurs, les transformations ne sont pas rutilisables, cest--dire que des transformations ne peuvent pas faire appel dautres transformations. Il est important de noter que les rgles de transformation ne soccupent pas de la hirarchie des composants dans larchitecture de base, laissant au tisseur la charge de crer les bons lments aux bons endroits. En somme, le moteur de transformation centralise le raisonnement pour dterminer o appliquer les rgles, et pour les excuter. Niveau 3 Le modle dvolution propos par TranSAT ne cible pas la rutilisabilit ni ladaptabilit et son approche base daspect nest pas des plus videntes malgr de bons rsultats.
tel-00459925, version 1 - 25 Feb 2010
2.3.4
Bilan de ltude
Nous avons prsent dans les sections prcdentes les dirents modles dvolution proposs par la littrature pour tenter de faire face la problmatique de lvolution dans les architectures logicielles. Dans cette section, nous proposons de tirer le bilan des modles tudis en sappuyant sur la pyramide des besoins trois niveaux. A la lumire de ces lments, nous analyserons lexistant an den extraire les points forts et les points faibles.
42
2.3.4.1
Rcapitulatif
Les tableaux 2.2, 2.3 et 2.4 rcapitulent respectivement les approches tudies selon les niveaux croissants de la pyramide des besoins. Comme la performance dpend non seulement de la structure dun modle, mais galement dautres facteurs tels que lapplication cible ou le systme sous-jacent, nous ne lavons pas inclus dans la comparaison du niveau qualit. Une analyse de ce rcapitulatif et une discussion est propose dans la section suivante.
tel-00459925, version 1 - 25 Feb 2010
" "
NIVEAU 1 : INTENTION DU MODELE D'EVOLUTION !
Table 2.2 Positionnement des modles dvolution selon la base de la pyramide des besoins.
2.3.4.2
Analyse et discussions
Niveau 1 Tous les modles dvolution tudis soccupent de la formulation de lvolution. En revanche, peu dentre eux ont propos une gestion des impacts, ou alors celle-ci tait limite quelques cas bien dnis. Dans lensemble, les modles tudis nont pas cherch garder la trace de lvolution. Niveau 2 Par nature, les ADLs acadmiques nont pas vocation assurer le ranement des spcications vers le code source. Par consquent, peu dentre eux cherchent reter les volutions du niveau architectural sur le niveau code. Directement reli ce dernier point, les modes dexpression prennent souvent la forme de formalismes de haut-niveau. Toutes les approches tudies fournissent un moyen de spcier un assemblage de primitives dvolution. Ces spcications peuvent tre contenues lintrieur de lADL (partie orchestrateur, partie congurateur, etc.) ou lextrieur de lADL (scripts, transformations, etc.). Trs peu dADL permettent de considrer de telles spcications comme de nouvelles oprations dvolution. En dautres termes, les seules volutions quil est possible de rutiliser sont de ne granularit. A quelques exceptions prs, les volution proposes appartiennent la couche tout domaine, cest--dire utilisables sur une architecture quelconque. A premire vue, cela peut paratre satisfaisant. Pourtant, certaines familles dapplications ncessitent de prendre en compte leurs spcicits dans leurs volutions. Ces dernires ncessitent des oprations dcrites dans les termes du vocabulaire dun style architectural et qui devraient aboutir des architectures qui satisfont ce style. Par exemple, une opration pour ajouter un client dans le style client/serveur doit aussi

NIVEAU 2 : EXPRESSIVITE DU MODELE D'EVOLUTION
#$%&'( )0 '1234'53$67 S Q STS H IP R RUV WX Y `WSVa XWSba FG d H cW a eUfU ghiphqrs Y `WSVa XWSba S Q STS H IP R RUV WX Y `WSVa XWSba iyawn o H cI Y ubUSX TSX 86)& )0 &9 @ 4&22$67 ptr Y ubUSX TSX H hQdSQ Uv wVxya H c H IWvwHVxPUa QVQbW Xa aV RWPWwSVSWX SQbUbRSva da VxPaw da RWPWwUXVw de f ghe p H p p p Y QySWbUVSWX da RWPWwUXV H p WPWwSVSWX SQbUbRSva da VxPaw da H c RWPWwUXVw aV da RWXXaRVavbw de f ghe p H f geeg p Wvw VxPUa aV RWPWwSVSWX H I H SQbUbRSva da VxPaw da RWPWwUXVw aV da RWXXaRVavbw tWV RyQ tPaX p tvyVSPySRSVQ PWvb RWXVbuyab ya XWsba H dvSXwVUXRaw ÙwSva gbUSwWXXaaXV dQdvRVSTs p A6B'$7& #$%&'( )& B6)CD$2'3$67 8C5'7$E(& 6 @ C4'36$4& ÙwSva
43
d S H pWvV WU Xa
A i7 4$lm3 j k
S Q STS H IP R RUV WX Y `WSVa XWSba F A 8r i7 jq
sy d H IvbHaXwa a v yUXUa p tq Y c S TS ubU X X
H pWvV
dWUSXa
ÙwSva
A'4w$7
S Q STS H IP R RUV WX Y `WSVa XWSba d giaSws H cW a cnn S Q STS H IP R RUV WX Y `WSVa XWSba
H IRQU dvSXwVUXRSUVSWX PbQUyUsya Y ubUSX TSX T S H pbUXw WbUV WX Ubsba {tr g pbR VvdSW |s Y I ubUSX TSX
d S H pWvV WU Xa
p Wvw VxPUa aV RWPWwSVSWX ÙwSva H I H SQbUbRSva da RWPWwUXV p xXwVUXRSUVSWX dxXUSva aV PUbawwavwa H WvV p }abwSWXw fUbSUXVaw WPVSWXw U H ~ ~ ~ ~ baVbUSV da VxPaw da RWPWwUXV w aV da RWXXaRVavbw WvVYbaVbUSV da RWPWwUXV w aV p U H RWXXaRVavb p WPWwSVSWX SQbUbRSva da VxPaw da H c RWPWwUXVw uawVSWX da fabwSWX ÙwSva ÙwSva
d S H pWvV WU Xa
tel-00459925, version 1 - 25 Feb 2010
9 Ay G q jz
d H cW a eUfU ghUVU`SXdSXs Y `WSVa XWSba S Q STS H IP R RUV WX Y `WSVa XWSba d H cW a eUfU gh osY `WSVa XWSba c S Q STS H IP R RUV WX Y `WSVa XWSba d giUTTSXaaXV H cW a fabVSRUys S Q STS H IP R RUV WX Y `WSVa syUXRa
d S pd WR Y ubUSX TSX H H pWvV WU Xa
45m
'4& k
iya p r pir Y H ~ I ~ ubUSX TSX
H pWvV
dWUSXa
p QbSVUa aV UbQUVSWX da wVxyaw H UbRSVaRVvbUv p iUTTSXaaXV WbSWXVUy H Q q y cWb bUPa cWPWwUXV fW fab H H p rSsba p rSsba
ÙwSva gbUSwWXXaaXV dQdvRVSTs
r q
gpuus Y ubUSX TSX H TWbV dd de g g d ed e f ehde ffd de de d d SS SQ S d d f h e gWPWw V WX bUbR va a VxPaw a gbUSwWXXaaXV RWPWwUXVw defghe f dQdvRVSTs gheddede
iya q p Y H c ubUSX TSXHTWbV iya r Yi H I I
rSsba
pfUXRQa gbUSwWXXaaXV dQdvRVSTs
4'7 q
Table 2.3 Positionnement des modles dvolution selon le second niveau de la pyramide des besoins. connecter ce dernier un serveur. De mme, le retrait dun serveur peut transfrer ou supprimer ses clients. Les ADLs de premire gnration, notamment Wright et Darwin, ne se sont pas proccups de la problmatique de lvolution au moment de la spcication de larchitecture logicielle. Nanmoins, nous avons identi certains mcanismes oerts par ces ADLs qui permettent lvolution au niveau A1, comme le sous-typage ou la composition hirarchique de types de composants et de connecteurs. On notera au passage que la notion de sous-typage adopte par les ADLs est plus riche que celle propose par les langages de programmation. La majorit des ADLs de seconde gnration rient et considrent comme entits de premire classe tous les concepts de base dune description darchitecture logicielle : composant, connecteur, interface et conguration. Ces lments sont autant dlments susceptiblent dvoluer, aussi bien au niveau A1 que A0. Notons tout de mme que la problmatique globale de lvolution au moment de lexcution, qui inclut par exemple la question du transfert dtat des lments architecturaux, nest pas aborde
44
NIVEAU 3 : QUALITE DU MODELE D'EVOLUTION

tel-00459925, version 1 - 25 Feb 2010
Table 2.4 Positionnement des modles dvolution selon le dernier niveau de la pyramide des besoins. directement dans les ADLs, mais plutt au niveau de linfrastructure daccueil, quand elle existe (e.g., DCUP pour SOFA). Compte tenu des remarques prcdentes, on peut considrer que la mcanique opratoire oerte par les modles dvolution tudis est basique. On remarquera que plusieurs approches ont choisi une approche base de rgles pour permettre de grer lvolution dune architecture. Historiquement, Rapide [LV95] a t un des premiers ADL utiliser les rgles pour spcier le dynamisme. Ce type dapproche se retrouve rcemment dans les travaux sur les architectures auto-adaptatives, bases sur des rgles de type ObservationRponse [GT04]. Niveau 3 Les approches tudies sont avares en termes de mcanismes pour rutiliser les oprateurs dvolution (e.g., extension et composition). Spciquement, les proprits dvolutivit et de remplaabilit ne sont pas favorises. Par ailleurs, les ADLs formels reposent sur des thories mathmatiques assurant lobtention de spcications non ambigus. Ces formalismes peuvent paratre rebutants et ne sont pas aisment apprhendables par les non-initis. En outre, les approches sont souvent ad-hoc. Si les besoins changent, il faut fournir de nouveaux outils. Aucun ADL ne prvoit de mcanisme de paramtrage (template ) par exemple. Enn, la performance dpendra fortement de la plateforme technologique cible et de la catgorie du langage utilis : compil ou interprt (moins performant). Pour les quelques ADLs qui ciblent limplmentation, le langage choisi est un langage compil.
2.4
Conclusion
Nous avons abord dans ce chapitre les approches dvolution au niveau architectural des systmes logiciels au travers dun ensemble dADLs et de propositions acadmiques. Dans un premier temps, nous avons donn un clairage sur le bien-fond de lvolution base architecture. Puis, nous avons propos notre propre cadre de comparaison des modles dvolution organis autour dune pyramide des besoins trois niveaux : (1) lintention, (2) le pouvoir expressif, et
45
tel-00459925, version 1 - 25 Feb 2010
(3) la qualit du modle. Ce cadre ore un rfrentiel 5 commun et indpendant dune approche particulire. Ainsi, en se basant sur ce rfrentiel nous avons tudi un ensemble de travaux issus des coles amricaine, europenne et franaise. Concrtement, nous avons dcrit un certain nombre de modles dvolution suivant les trois niveaux de besoins que nous avons identi. Ceci nous a permis de distinguer, pour chaque modle, les aspects de lvolution qui sont traits et ceux qui ne le sont pas. Nous avons conclu cette tude en apportant notre propre valuation des modles dvolution existants. En se basant sur cette dernire, nous avons pu dresser un bilan rcapitulatif. Ce qui ressort essentiellement de ce bilan, cest que les modles dvolution existants ne proposent pas de spcier et de grer lvolution de manire explicite. Notamment, la notion de rutilisation de lvolution est trs peu aborde. Or, notre motivation pour faire face la problmatique de lvolution architecturale est entirement base sur la notion cl de rutilisation, comme cela a t mis en vidence la n du Chapitre 1. Sur ce constat, notre objectif est de proposer un modle dvolution alternatif pour sattaquer cette problmatique. Dans le chapitre suivant, nous prsentons un nouveau modle dvolution, il sagit de SAEM.
5. Le lecteur intress par ces questions de comparaison trouvera dans lAnnexe A une tude de trois autres rfrentiels proposs dans la littrature.
tel-00459925, version 1 - 25 Feb 2010
C HAPITRE
Modle dvolution architecturale base de style

tel-00459925, version 1 - 25 Feb 2010
Les deux principaux rsultats du cycle du dveloppement centr architecture sont les suivants : (i) larchitecture bien sr mais galement (ii) la connaissance de lquipe darchitectes. Nous lavons vu, un grand eort de recherche a t port sur les langages de description darchitectures (ADL), pour rendre explicite de faon formalise larchitecture des systmes logiciels. En revanche, peu de recherche a t faite sur le savoir-faire des architectes eux-mmes. Nous avons montr en section 1.1.2.2 quils requirent des aptitudes direntes de celles des concepteurs et des programmeurs, et il est clair quun "bon" architecte est quelquun de talentueux dont une grande partie des connaissances est tacite. Nanmoins, leurs bonnes pratiques dans le domaine de larchitecture peuvent tre formalises, et le travail base de patrons ou de styles (i.e., des reprsentations des faons standard de faire des choses) est trs prometteur. Ceci est particulirement ecace lorsque larchitecture nest pas innovante, mais trs similaire des cas existants. Par analogie, nous tendons penser que lvolution darchitectures, assure par des architectes comptents, peut tre formalise. De la mme faon, cette approche est particulirement protable lorsque les volutions sont rcurrentes ou similaires dune architecture une autre. Cest aussi un moyen de rentabiliser lactivit dvolution, alors mme que cette dernire constitue toujours un cot faramineux dans le budget des projets. Nous sommes convaincus que des bonnes pratiques dvolution gagneraient tre capitalises et partages par la communaut des architectes. Idalement, une solution un problme dvolution rencontr par un architecte sur un projet devrait tre immdiatement mise disposition des autres architectes concerns par des projets similaires, an de leur viter de rinventer la roue chaque fois. Dans ce chapitre nous introduisons notre proposition baptise SAEM (Style-based Architectural Evolution Model), un nouveau modle dvolution dans les architectures logicielles base de composants, reposant sur le concept cl de style dvolution. En premier lieu, nous expliquons pourquoi et comment la notion de style peut tre un instrument puissant de capitalisation de savoir et de savoir-faire pour lvolution architecturale. Puis, nous prsentons le mta-modle de SAEM et nous en dcrivons les dirents concepts. Nous prsentons galement un formalisme de reprsentation des styles dvolution baptis MY. Nous terminons ce chapitre en procdant lvaluation de notre propre modle dvolution dans la pyramide des besoins prsente au chapitre prcdent. 47
48
CHAPITRE 3 Modle dvolution architecturale base de style
3.1
Vers le concept de style dvolution
Nous avons puis notre inspiration dans la notion de style architectural que lon trouve dans le domaine des architectures logicielles. Notre objectif nest pas dencapsuler de lexpertise pour la conception, mais plutt de lexpertise pour lvolution. Cest ainsi que nous proposons le concept de style dvolution. Le terme "style" vhicule une charge smantique forte et nous discutons ci-aprs de la lgitimit dune telle notion pour aborder le problme de lvolution architecturale.
3.1.1
Thsaurisation, extraction et reprsentation de lvolution
tel-00459925, version 1 - 25 Feb 2010
Notre recherche vise thsauriser les expertises pour faciliter lvolution dans les architectures logicielles travers leur rutilisation. Pour atteindre cet objectif, il est ncessaire dextraire lvolution pour pouvoir la reprsenter dans un formalisme donn. La thsaurisation, lextraction ainsi que la reprsentation de lvolution sont les pierres angulaires de la rutilisation de lvolution.
3.1.1.1
Thsaurisation de lvolution
Lide de se constituer ses propres bibliothques dlments rutilisables nest pas nouvelle dans le monde des produits. En revanche, elle lest beaucoup moins dans le monde des processus, et tout simplement inexistante dans le domaine de lvolution logicielle. Dans ce dernier cas, lobjectif est de thsauriser les savoir et savoir-faire des personnes ayant dj fait face des volutions, en vue de les rutiliser dans des situations similaires. Pour une entreprise de dveloppement logiciel, disposer dune bibliothque dvolutions dj valides amliore la qualit du rsultat et donne un avantage concurrentiel certain. Nanmoins, cette formule exige de mettre en place une classication claire et volutive pour viter les doublons et viter le temps perdu en recherches infructueuses. En somme, lecacit de la rutilisation dpendra aussi de linfrastructure de rutilisation propose.
3.1.1.2
Extraction de lvolution
Nous considrons que tout lment architectural possde sa propre structure, ses comportements mais aussi ses possibilits dvolution dans lavenir. Or, nous observons que la composante volution est traditionnellement amalgame dans la composante comportement, entravant de ce fait la possibilit de la rutiliser. A la place, nous suggrons de dcliner le comportement en deux types : le comportement stable (steady-state behavior ) qui dcrit des services rendus et le comportement dvolution (evolution behavior ) qui porte sur la structure et/ou sur le comportement stable. Nous rappelons que nous nous intressons ici lvolution de la structure. Comme lillustre la Figure 3.1, nous prnons lextraction de lvolution en tant que composante part entire dun lment architectural. En procdant de la sorte, il devient possible danalyser et de modliser lvolution dun systme linstar de ce qui est entrepris pour le systme lui-mme. Par consquent, nous suggrons dintgrer la subdivision suivante dans un modle de dveloppement : Analyse & conception gnrale du systme : dlimiter le problme rsoudre en numrant un ensemble dexigences. Puis, dterminer les composants ou les modules ncessaires pour crer le domaine des applications. Cette tche est cone un ou plusieurs architectes dapplications.
49
Figure 3.1 Les trois composantes dun lment architectural : structure, comportement et volution. Analyse & conception de lvolution du systme : dterminer lventail des volutions possibles de chaque composant. Il sagit de prparer le systme sadapter des situations attendues ou inattendues par le biais de moyens prvus. Cette tche est cone un ou plusieurs architectes dapplications volutives.
tel-00459925, version 1 - 25 Feb 2010
3.1.1.3
Reprsentation de lvolution
La structure propose doit tre vue comme un rceptacle de connaissances, de comptences, propre prendre son compte certains choix et certaines tches dvolution. Cest ainsi que la notion de style dvolution merge et que nous suggrons de reprsenter par les lments suivants : son type : la dnition abstraite du style, son implmentation : la mise en oeuvre du style, son instance : une volution particulire est un processus excutable, instance dun type de style. La spcication dun style dvolution repose dabord et essentiellement sur son type. En eet, nous nexaminons pas une par une toutes les volutions concrtes de larchitecture mais travaillons directement sur les archtypes dvolution 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 prcision nest donne, le terme "style dvolution" fera implicitement rfrence son type.
3.1.2
Points de vue et styles pour lvolution darchitectures
Il y a plusieurs vues, tout comme il y a plusieurs structures, chacune avec ses propres objectifs et ses propres orientations dans la comprhension du systme. Ainsi, une description architecturale slectionne un ou plusieurs point de vue. Ce choix dpend des proccupations des intervenants. Nous donnons une ide de la relation entre les points de vues et les styles dans une architecture par la Figure 3.2. Nous rappelons quune vue est une reprsentation dune architecture dans la perspective dun ensemble de proccupations connexes (IEEE Std 1471, [IEE00]). Cette reprsentation comprend un ensemble dlments du systme et les relations qui leur sont associes. Les types dlments et les relations ainsi que dautres mta-informations dans les vues sont dcrites par les points de vue (IEEE Std 1471, [IEE00]) an de documenter et de communiquer sur les vues sans ambiguts. Par consquent une vue est une instance dun point de vue pour un systme particulier car
50
Figure 3.2 Vues, points de vue, et styles (inspir de [AZ05]) les lments et les relations contenus dans la vue sont des instances des types dlments et de relations correspondant contenus dans le point de vue. Un style, dun autre cot, dnit galement des types dlments et de relations qui travaillent ensemble an de rsoudre une classe de problmes dans une perspective. Un style peut tre considr comme une spcialisation dun point de vue puisque il ore des smantiques spciques aux types dlments et de relation et dtermine leur utilisation. La vue structurelle et la vue comportementale sont des exemples de vues importantes dune architecture logicielle. La premire dcrit comment un systme est structurellement dcompos en composants et connecteurs. La seconde dcrit le comportement des composants et des connecteurs et la faon dont ils interagissent ensemble. Dans la vue structurelle, nous pouvons appliquer les styles structuraux blackboard ou pipe&lter par exemple. Dans la vue comportementale, nous pouvons appliquer les styles comportementaux broadcast ou peer-to-peer par exemple 1 . A notre connaissance, la vue volutive de larchitecture na jamais t considre de faon explicite. En toute logique, nous suggrons appliquer dans cette vue des styles dvolution. Nous proposons de dnir un style dvolution comme suit : Un style dvolution capture une manire caractristique de procder lvolution de tout ou partie dune architecture logicielle. Il sert de guide pour un architecte qui doit alors se conformer au style. Cette dnition claire notre volont traiter le problme de lvolution architecturale par les styles. Dans la section suivante, nous proposons un nouveau modle dvolution, baptis SAEM, reposant sur la notion de style dvolution.
tel-00459925, version 1 - 25 Feb 2010
3.2
SAEM : Style-based Architectural Evolution Model
Nous proposons un nouveau modle dvolution base de styles (Style-based Architectural Evolution Model SAEM ). Dans ce modle, une volution est rie comme un style et attache chaque lment architectural, en tant que partie intgrante de sa description tout en tant distincte. Aprs avoir discut des bonnes pratiques pour la gense dun nouveau modle dvolution, nous prsentons SAEM travers son mta-modle en ayant pris soin dexpliquer ce choix.
1. En ce sens, la notion de style architectural tudi dans la littrature incarne trs souvent la fois un style structurel et un style comportemental.
51
3.2.1
Proprits attendues de SAEM
Dnir un modle dvolution est une partie importante de notre travail. Mais il est tout aussi important dassurer lecacit dun tel modle. Pour cela, nous y avons associ trois proprits importantes : La minimalit : lide basique derrire cette proprit est de fournir un ensemble minimal et susant de concepts dans le modle dvolution, ainsi appel "noyau". En rgle gnrale, un nombre rduit de concepts raccourcit la courbe dapprentissage. La compltude : troitement lie la minimalit, la compltude permet dtendre le noyau sans perturber la faon dont il fonctionne. Cest une sorte de principe douverture/fermeture 2 appliqu un modle dvolution. La modularit : lvolution doit venir complter lexistant. De cette faon elle nest pas intrusive, elle est pleinement rutilisable et lemphase de larchitecte peut tre porte uniquement sur lvolution.
tel-00459925, version 1 - 25 Feb 2010
En fait, ladhsion dun modle dvolution ces proprits dpend de ses fondations conceptuelles. Les fondations conceptuelles du SAEM sont dcrites par un mta-modle.
3.2.2
Pourquoi un mta-modle ?
Nous visons dnir un modle gnrique. Cela passe par la mta-modlisation. En eet, la dnition dun mta-modle permet de ne pas limiter notre approche un simple langage ou une notation de modlisation. Lapproche se place un niveau dabstraction suprieur aux langages et notations de modlisation. Nous nous intressons principalement aux concepts utiliss pour exprimer lvolution dans les architectures logicielles. Il sagit de rier ces concepts et de reprsenter explicitement leurs caractristiques et les relations qui existent entre eux. Ainsi, lapproche sabstrait de toute syntaxe et manipule les lments de modlisation comme des entits smantiques et non des entits syntaxiques. Il sut dassocier aux dites entits smantiques, soit des entits syntaxiques pour constituer un langage de description, soit des entits graphiques pour constituer une notation graphique de modlisation.
3.2.3
Le mta-modle SAEM
Les concepts de base de notre mta-modle SAEM sont dcrits travers la Figure 3.3. Nous nous appuyons sur une modlisation objet pour la description du mta-modle. Nous utiliserons prcisment le formalisme du diagramme de classes de la notation UML 2.0. Ainsi, les concepts cls de classe, dhritage, de composition et dassociation sont exploits, ainsi que les concepts de rles et de multiplicits sur les associations. Le diagramme de classe met en vidence les concepts proposs par SAEM, ainsi que les associations qui existent entre eux. Il se focalise principalement sur la manire dont sont organiss les concepts. Nous dcrivons en dtail ces concepts dans la section suivante.
2. En programmation objet, le principe douverture/fermeture stipule que les entits logicielles doivent tre ouvertes leur extension, mais fermes leur modication.
52

P A " A A 0 ' " G '
tE !
q966@r@s8 3 ' C ' 0 G 0 )) ' ' G
Q "R 0 G

HI
G 0 ))
I!
' B
( G )) D ! E F #
G 12
0 ! ( 0 )) $ " " # ' % &
34 5 6789@57
tel-00459925, version 1 - 25 Feb 2010
A B C
' G G ' iee
FD e
' 0
U U " VV D! ! Fa X$ X# b$ Qc` X$ X# db$ Qc`
U U " VV peI #AgWQ WdYB `
U U " VV FT S ! W$ X# Y X# W$ Y
U U " VV fT Fee Y` WQ Y g dh W
`B Y#`$
Figure 3.3 La structure du mta-modle noyau de SAEM.
3.3
Description des concepts de SAEM
Pour chaque concept du mta-modle SAEM, nous apportons une dnition ainsi quun exemple illustratif quand cela est ncessaire.
3.3.1
3.3.1.1
lment volutif
Dnition
La classe EvolvableElement reprsente une abstraction forte qui peut recouvrir nimporte quel lment architectural dont les instances sont susceptibles dvoluer. Nous avons introduit ce concept dans SAEM pour modliser et rier tout lment signicatif dune architecture volutive. Si un concept architectural est instance de cette classe (au sens orient objet), alors il devient possible de lui associer des styles dvolution. Aussi, cette classe particulire est le point de jonction entre le mta-modle SAEM et tout concept architectural ri.
53
3.3.1.2
Exemple
Il est ncessaire didentier quels lments architecturaux sont susceptibles dvoluer. Plus le nombre dlments ris par un ADL est important, plus les possibilits dvolution sont vastes. Pour comprendre, reconsidrons lexemple illustratif donn en n de chapitre 1 dans la section 1.3.4.
u
d dedfg t rsst
og ifpgqd
vkn
uvwxyyvu
tel-00459925, version 1 - 25 Feb 2010
hidfg jkl m n y uivwffdwgxhidfg
pdfydodvgxhidfg
pdzdz n y m v{wx wyv|}{{ m ~y ydedxpdzdz
Figure 3.4 Identication des lments architecturaux susceptibles dvoluer. A travers la Figure 3.4, le choix est fait de considrer les types de composants Client et Server comme des instances de EvolvableElement. En attachant des styles dvolution aux lments du niveau A1 dune architecture logicielle client/serveur, lvolution pourra tre gre au niveau A0. Dans notre exemple, le client peut voluer selon les styles Disconnect@Client et AddSendRequest@Client, tandis que le serveur peut voluer selon le style Remove@Server. Dautres styles peuvent bien videmment tre associs ces lments architecturaux.
3.3.2
3.3.2.1
Style dvolution
Dnition
Un style dvolution encapsule ce qui permet de dcrire et dappliquer une volution un lment architectural. La classe EvolutionStyle est une entit nomme qui est compose de deux parties complmentaires : un entte et une comptence. Lentte est obligatoire tandis que la comptence ne lest pas. Quand la comptence nest pas spcie, on dit dans ce cas que le style dvolution est abstrait. Examinons plus en dtail ce que sont lentte et la comptence : Lentte possde une description informelle du but poursuivi et publie une liste de paramtres et dassertions. Llment volutif apparat comme un paramtre implicite nomm context. Le type des paramtres sont fournis par lensemble des lments volutifs, plus les types primitifs usuels (String, int, boolean, oat, etc.)
54
La comptence dcrit une unit dimplmentation correspondant lentte. Lunit dimplmentation spcie le ot des donnes et toute la logique de contrle. Limplmentation est considre comme une ressource externe, identiable par son URI (Uniform Resource Identier ). Il est important de remarquer que nous dissocions un style dvolution de llment architectural concern. Lobjectif est que llment soit li son ou ses styles dvolution. Cest une faon dajouter la composante volution manquante dans la description des lments architecturaux, comme cela a t dfendu au dbut de ce chapitre (cf. section 3.1.1).
3.3.2.2
Exemple
tel-00459925, version 1 - 25 Feb 2010
La Figure 3.5 schmatise la reprsentation dun style selon trois compartiments : le nom du style, son entte et sa comptence. La convention de nommage utilise dans le reste de ce manuscrit suit le motif Evolution@ElementEvolutif. Le style RemoveTail@Component dcrit la suppression dun composant qui se trouve lextrmit de sa conguration dappartenance (self.context.owner). Ceci est exprim par la prcondition self.context.owner.bindings->exists(b|b.target=context), qui indique que le composant est la cible dau moins un binding de la conguration. Le compartiment de la comptence de ce style indique que pour la suppression dun tel composant, il faut, dans lordre : Supprimer les bindings auquel le composant participe. Supprimer toutes les interfaces du composant. Exclure le composant de la liste des composants de la conguration. Dtruire le composant proprement dit, par dsallocation de celui-ci.
Figure 3.5 Nom, entte et comptence dun style dvolution. Dans SAEM, toute opration dvolution est vue comme un style. Le style dvolution est en relation avec dautres styles (non montr sur la gure), pour lui permettre de les invoquer. Dans lexemple, on peut deviner les styles dvolution Unbind@Binding, Remove@Port, ExcludeComponent@Conguration et enn Free@Component. On considre ici que linvocation suit une
55
orientation objet de la forme ElementEvolutif.Evolution([paramtres ventuels]). Sur ce principe, un architecte ou un autre style dvolution pourra invoquer le style RemoveTail@Component sur un composant c1 travers linstruction c1.RemoveTail().
3.3.3
3.3.3.1
Contrainte
Dnition
tel-00459925, version 1 - 25 Feb 2010
Les contraintes ont pour objectif principal de permettre de contrler lvolution des lments dune architecture. La classe abstraite Constraint est drive en deux sous-classes : Contrainte Structurelle : reprsente une contrainte sur la structure dun lment volutif. Elle doit tre respecte tout au long du cycle de vie de llment. Assertion : reprsente des contraintes sur ltat de tout ou partie de larchitecture avant, pendant, et aprs son volution. La spcication dun style dvolution inclut une prcondition et une postcondition dans son entte. Tandis que la prcondition permet de vrier que llment volutif est dans le bon tat pour pouvoir y appliquer le style dvolution, la postcondition informe de ltat dans lequel ce dernier sera aprs y avoir appliqu le style dvolution. Lentte ne dnit pas explicitement dinvariant : celui-ci provient directement de la contrainte structurelle de llment volutif concern. En eet, la contrainte structurelle pose sur un lment volutif constitue naturellement un invariant vis--vis de son volution. Lensemble de ces lments permet dtablir un contrat lors de la rutilisation dun style dvolution.
3.3.3.2
Exemple
Pour ne pas prsupposer dun langage de contrainte en particulier, nous considrerons une syntaxe " la OCL ". Par consquent, nous disposons dun langage simple, supportant des expressions de navigation et des expressions boolennes (conjonction, disjonction, implication, quantication, etc.). Pour pouvoir exprimer plus de choses on y adjoint un moyen pour que les postconditions puissent se rfrer lancienne valeur des lments modis par la comptence (mots cl @pre et @post). Nous donnons ci-dessous un exemple de contrainte structurelle associe llment volutif Client. Cette dernire sassure quun composant de type client ne possde pas plus de quatre ports de type sendRequest. context Client inv : self.ports->select(isTypeOf(sendRequest))->size()<=4 Nous donnons ci-dessous un exemple dassertions associes au style dvolution AddSendRequest@Client. La prcondition vrie que le composant de type client possde un taux de requte strictement suprieur la valeur 10. La postcondition vrie que le composant possde bien un port de plus quavant son volution. context AddSendRequest@Client::invoke():void pre : self.context.requestRate > 10 post : self.context@post.ports->size() = self.context@pre.ports->size()+1
56
Invariablement, le style dvolution est tenu de respecter la contrainte structurelle pose sur le type de composant client. Ceci est particulirement important dans notre exemple o il y un risque dincohrence structurelle puisque le style AddSendRequest@Client pourrait faire passer le nombre de port 5.
3.3.4
3.3.4.1
Relation
Dnition
tel-00459925, version 1 - 25 Feb 2010
Dans la continuit des travaux de Roger Chan [Cha88], nous dnissons le concept de relation entre deux styles dvolution de faon gnrique par un triplet dlments relationnels, auquel nous associons un mode de communication. Selon cette stratgie, la prsence ou labsence des lments relationnels (a) de connexion, (b) dinclusion et (c) de similarit permet de dterminer la nature de la smantique porte par une relation entre deux concepts. En procdant ainsi, il devient ais de se doter de relations smantiques adaptes ses besoins, sans devoir apporter de modication au mta-modle de SAEM. En outre, chaque relation est dirige et supporte une communication par message entre le style metteur et le style receveur dont le mode peut tre synchrone ou asynchrone : Synchrone : la rception dun message est "cal" sur le moment de son mission. Ici, ce processus est bloquant, cest--dire que le style dvolution metteur doit attendre la terminaison du style receveur pour pouvoir continuer son excution. Asynchrone : la rception dun message peut tre postrieure au moment de son mission. Ici, ce processus est non-bloquant, cest--dire que le style dvolution metteur peut continuer son excution sans mme attendre la terminaison du style receveur.
3.3.4.2
Exemple
Nous instancions le concept Relation an dobtenir trois relations smantiques que nous jugeons essentielles pour notre approche : lutilisation (ou rfrence), la composition et la spcialisation. Le diagramme dobjet UML de la Figure 3.6 montre comment ces relations sont instancies depuis leur classe commune dnie dans le mta-modle de SAEM.

Figure 3.6 Instances du concept Relation de SAEM : spcialisation, composition et utilisation. Ainsi, linstar des relations inter-styles architecturaux prsentes en Section 1.1.4.3, le modle SAEM prvoit trois relations inter-styles dvolution. La spcialisation sera utilise pour crer des styles dvolution plus spciques et mieux adapts certaines classes de problmes dvolution. La composition sera utilise pour crer des styles composites, par combinaison de styles dvolution existants. Enn, lutilisation sera utilise pour faire collaborer des styles dvolution. La table 3.1 prsente des informations complmentaires sur ces trois types de relations. En premier lieu, on remarque que chacune des trois relations possde au minimum llment de connexion, qui est la quintessence du rle dune relation. Ensuite, llment dinclusion fait
CHAPITRE 3 Modle dvolution architecturale base de style Nom Spcialisation Composition Utilisation Signication est-une-sorte-de est-compos-de utilise lments relationnels {Connexion, Similarit, Inclusion} {Connexion, Inclusion} {Connexion} R T S
57
Table 3.1 lments relationnels et axiomes mathmatiques de rexivit (R), de transitivit (T) et de symtrie (S) associs aux trois relations smantiques. merger des niveaux hirarchiques entre les styles dvolution, caractristique de la relation de composition et de la relation de spcialisation. Cette caractristique est conrme par la relation dordre que ces deux relations dnissent axiomatiquement : elles sont toutes deux rexives, antisymtriques et transitives. Enn, la spcialisation se distingue par la prsence de llment de similarit, qui traduit une continuit conceptuelle entre les styles relis. La prsence ou labsence de ces trois lments relationnels dans le triplet utilis pour dnir des relations smantiques suggre quil existe un ordre entre ces dernires. Ainsi, on considre que plus (respectivement moins) une relation peut tre dcrite par des lments relationnels, plus elle ore une smantique riche (respectivement faible). Avec les trois relations essentielles de SAEM nous obtenons lordre suivant : spcialisation > composition > utilisation
tel-00459925, version 1 - 25 Feb 2010
3.3.5
Bibliothque
Une bibliothque (classe Library dans la Figure 3.3) est une unit structurante destine contenir un ensemble de styles dvolution. Le concept de bibliothque est similaire au concept dAPI (Application Programming Interface ) dans lunivers de la programmation. En ce sens, une bibliothque expose une interface, autorisant la rutilisation de tout ou partie de son contenu. Une bibliothque fournit un espace de nom spcique et contrle son interface vis--vis de lextrieur en jouant sur la visibilit des styles dvolution, qui peuvent tre privs ou publiques. Ainsi, il est possible de spcier des styles dvolution uniquement visibles et donc utilisables depuis lintrieur de la bibliothque. Par ailleurs, la bibliothque constitue le point dentre unique pour laccs aux styles dvolution et est considr comme un lment de modlisation racine. Enn, le concept de bibliothque ore un moyen de distribution bien dni des styles dvolution. De ce point de vue, les librairies peuvent tre entreposes, changes, copies, enrichies, interroges, etc. Des politiques relatives leur distribution peuvent mme leurs tre associes.
3.4
Mcanique opratoire de SAEM
Dans cette section, nous revenons sur les direntes relations de SAEM voques depuis le dbut de ce chapitre, en expliquant la mcanique opratoire associe chacune delles. Comme cela est schmatis par la Figure 3.7, les mcanismes oprationnels fournis par SAEM sont linstanciation, la spcialisation, la composition, et enn lutilisation. Ces mcanismes sinspirant largement de ceux de lorient objet, nous pouvons de ce fait reprendre notre compte les notations du diagramme de classe UML pour les illustrations suivre dans cette section.
58
tel-00459925, version 1 - 25 Feb 2010
Figure 3.7 Les styles dvolution sont relis entre eux par la spcialisation, la composition et lutilisation. Ils sont instancis sur larchitecture dun systme.
3.4.1
Linstanciation
Dune manire gnrale, linstanciation est un mcanisme qui permet de passer dun niveau de modlisation donn au niveau infrieur. Les styles dvolution peuvent tre instancis plusieurs fois dans une architecture. Linstance dun style dvolution est un processus particulier qui est cr dans le respect de la structure donne par son style. Toutes les instances dun style dvolution doivent orir exactement la mme comptence que ce dernier. Le mcanisme dinstanciation recouvre la liaison des paramtres formels des paramtres eectifs (i.e., des lments dune architecture), lvaluation de la prcondition et de la postcondition, et lexcution du corps de la comptence. Par consquent, un style dvolution abstrait ne peut pas avoir dinstances tant donn quil ne spcie aucune comptence. On peut considrer quune instance est rattache son type de style dvolution par la relation "est-un" (is-a ).

Figure 3.8 Mcanisme dinstanciation de style dvolution. Lexemple de la Figure 3.8 montre deux instanciations du mme style dvolution IncludePort@Component sur des lments particuliers dune architecture logicielle. Dans le premier cas, lvolution vise lajout du port response1 la liste des ports du composant server1 ; dans le second cas, lvolution vise lajout du port request1 la liste des ports du composant client1.
59
3.4.2
La spcialisation
Les styles dvolution peuvent tre dnis par extension dautres styles. Le mcanisme dhritage associ la relation de spcialisation est inspir du mcanisme dhritage des classes dans le paradigme objet. Avec la structure bipartite propose, dune part un sous-style peut ajouter et surcharger des lments de lentte de son super-style, et dautre part un sous-style peut rednir la comptence de son super-style. Ce mcanisme peut tre utilis pour dnir des styles dvolution concrets en tant que sous-styles de styles abstraits en fournissant la comptence manquante. De faon plus dtaille, nous avons : Surcharge dentte (Header overloading ) : les paramtres (incluant context), les assertions et les relations de composition et dutilisation dcrites dans le super-style sont autant dlments hrits par le sous-style. Larchitecte est alors libre dajouter de nouveaux paramtres et de nouvelles relations. Au besoin, larchitecte peut spcialiser les paramtres et les relations existantes, renforcer la prcondition et aaiblir la postcondition. Rednition de comptence (Competence overriding ) : la comptence dnie dans le superstyle est hrite dans le sous-style. Larchitecte est alors libre de la remplacer par une nouvelle implmentation. Lors de la rednition, on laisse la possibilit larchitecte de rutiliser la comptence du super-style si ce dernier nest pas abstrait. Le cas chant, la communication entre le sous-style et le super-style est synchrone.
tel-00459925, version 1 - 25 Feb 2010

Figure 3.9 Mcanisme de spcialisation de style dvolution.
Lhritage propos sera utilis pour crer des hirarchies conceptuelles spcialises. Les styles abstraits pourront tre utiliss comme un moyen simple pour factoriser un ensemble de styles partageant une mme stratgie dvolution. Pour ne pas introduire de conits smantiques entre sous-styles, SAEM ne propose que lhritage simple. Lexemple de la Figure 3.9 montre la spcication de deux sous-styles, par spcialisation du style abstrait Remove@Component. Chaque sous-style fournit la comptence manquante, compte tenu de la situation du composant avant volution, dtermine par une prcondition particulire. Dans cet exemple, la surcharge dentte nest pas exploite.
60
3.4.3
La composition
La composition est ncessaire pour dcrire les volutions dirents niveaux de dtails. La composition de style se rfre la structuration tout-partie entre deux styles. A chaque niveau de composition, chaque style peut tre vu comme ayant pour parties ces sous-styles qui reprsentent des tapes entrant dans sa comptence. Cette relation suggre un fort couplage entre les styles dvolution et favorise lencapsulation des comptences complexes. Le SAEM utilise le mcanisme de composition pour dnir des styles dvolution composites, de plus en plus complexes, dlguant leurs fonctionnalits aux styles composants. La composition dmarre dun ensemble de styles dvolution primitifs, dont la comptence est lmentaire. Enn, le mode de communication attribu la composition est ncessairement synchrone, car lexcution des styles composants est subordonne celle du style composite.
!!" 34" #$%&'(&) 5$6&
tel-00459925, version 1 - 25 Feb 2010
#$%&'(& ) 0$12$%'%&
Figure 3.10 Mcanisme de composition de style dvolution. Lexemple de la Figure 3.10 montre la spcication du style dvolution Remove@Component compos du style Remove@Port. Cette relation est le reet du lien de composition entre les lments volutifs eux-mmes, et savre tre un moyen dexprimer que la suppression du composant ne va pas sans la suppression du ou des ports qui le composent.
3.4.4
Lutilisation
Dans SAEM, lutilisation est une technique fondamentale dans la perception dun systme expert comme un ensemble dexpertises inter relies. Ainsi, lutilisation est une relation permettant un style de rfrencer un autre style pour en utiliser la fonctionnalit. Elle ne doit pas tre confondue avec une relation de composition, car elle a un caractre plus momentan et nimplique pas de couplage fort. Enn, le mode de communication attribu lutilisation est asynchrone, car les excutions des styles nont pas ncessairement besoin dtre concordantes.
789@AB8CD EFGHIPH Q RFSH HTSUIH Q VFWXFGIGH Y@àb@AB8CD EFGHIPH Q RFSH GIcdTWI Q eH SfGU
Figure 3.11 Mcanisme dutilisation de style dvolution. Lexemple de la Figure 3.11 montre la spcication du style dvolution Move@Port utilisant la spcication du style Rename@Port. Cela sexplique par le fait que le dplacement dun port dun composant un autre peut ncessiter son renommage pour ne pas introduire de conits avec les ports existants dans le composant destination.
61
3.5
Formalisme de reprsentation des styles dvolution
La spcication des styles dvolution doit tre aussi simple que possible, tant sur le plan des concepts manipuls que sur celui de la quantit dlments dcrire. Compte tenu des fonctionnalits oertes par SAEM, le formalisme choisi doit permettre de distinguer lentte de la comptence dun style dvolution ainsi que les lments volutifs concerns. En outre, larchitecte doit pouvoir hirarchiser les enttes, les comptences et les lments volutifs et disposer de plusieurs vues sur ses styles. Le modle en Y (MY) est un formalisme qui intgre naturellement ces fonctionnalits et qui a en outre t utilis par notre quipe pour dcrire les architectures logicielles base de composants [SOK08]. En utilisant MY comme support, un style dvolution peut tre dcrit par trois aspects (correspondant aux trois branches du Y) : domaine, entte et comptence. Ces aspects reprsentent successivement tout ce qui est li aux lments volutifs, aux oprations dvolutions et aux implmentations de ces oprations.
tel-00459925, version 1 - 25 Feb 2010
3.5.1
MY : La mta-modlisation en Y
La modlisation, la mta modlisation et les bibliothques de composants rutilisables sont des techniques prouves qui sont utilises dans lingnierie de la connaissance (Knowledge Engineering, KE). La modlisation et la mta modlisation sont des techniques utilises pour reprsenter des systmes un niveau lev qui abstrait les considrations dimplmentation et se concentre sur la comptence [Men02]. Dans le domaine de la reprsentation de connaissances, on parle de la mta-connaissance pour voquer la connaissance concernant une connaissance. Les bibliothques de composants rutilisables ont t dcrites dans direntes approches de KE [Mot00]. Aprs avoir examin ces bibliothques, nous avons constat quelles font face des problmes trs proches des ntres. En ce qui nous concerne : comment dcrire un style dvolution, ce que devrait tre le niveau de granularit dun style volution, comment structurer et classer les style dvolutions de sorte que lutilisateur puissent facilement comprendre, trouver et utiliser des styles an de transformer des architectures. Les approches classiques de KE telles que CommonKADS [Bre94], TINA [Ben95], VITAL [SMR93], MIKE [AFLS98], Protg [GMF 03], les tches gnriques [CJS92], les composants de lexpertise [Ste90], et MY [OMK02] dcrivent des systmes base de connaissance (SBC) en utilisant trois lments complmentaires : tche, mthode de rsolution de problme (Problem Solving Methods, PSMs) et domaine. La sparation des mthodes (utilises pour raliser une tche donne) de la tche et du domaine permet de dnir un SBC comme une combinaison de ces trois lments. Lapproche MY combine la mta modlisation et les bibliothques de composants rutilisables.
3.5.2
Style dvolution en Y
Comme cela vient dtre voqu, en utilisant le modle MY, un style dvolution peut tre dcrit par trois aspects : domaine, entte, comptence. le domaine reprsente la connaissance disponible/les lments volutifs, lentte reprsente les oprations ralisables sur la base de cette connaissance, la comptence reprsente la mthode choisie pour raliser lopration.
62
Ces trois concepts sont relis entre eux pour tablir un style dvolution. Ils sont dnis dans un but de rutilisation pour dcrire dirents archtypes dvolution. Par consquent, nous pouvons rutiliser un MY pour dcrire dirents styles dvolution dans dirents contextes : un domaine peut tre utilis pour dcrire les systmes client/serveur, pipe&lter, etc., un entte peut tre utilis pour dcrire la deconnexion dun client, le retrait dun serveur, lajout dun ltre, etc., une comptence peut tre utilise pour dcrire le retrait dun serveur avec transfert de ses clients ou non, etc.
3.5.2.1
Les concepts de base
tel-00459925, version 1 - 25 Feb 2010
Nous lavons vu, les deux concepts principaux de la description dun style dvolution sont lentte et la comptence. Il existe en ralit un troisime concept, non explicit jusquici, qui est le domaine. Le domaine ore un vocabulaire compos des lments volutifs et de leurs relations, typiquement sous formes de classes et dattributs dans les reprsentations par objets. Lacquisition de ce vocabulaire conceptuel de base est donc ncessaire pour exprimer la connaissance en matire dvolution sur ce domaine. Nous modlisons ces concepts en utilisant trois aspects (chacun est reprsent par une branche de la lettre Y) : aspect domaine, aspect entte, aspect comptence. Chaque branche de la lettre Y dcrit un concept du style dvolution, comme le montre la Figure 3.12. Le centre de larchitecture en Y dcrit un entte primitif li une comptence lmentaire et dcrits dans la terminologie du domaine. De plus, an de garder la description des trois concepts (domaine, entte, comptence) indpendants les uns des autres, nous explicitons deux relations : lien inter-concepts et lien intra-concepts. La relation inter dcrit le lien entre deux concepts dirents (par exemple entre un entte et une comptence), alors que la relation intra dcrit le lien entre deux concepts du mme type (par exemple entre un domaine et ses sousdomaines). Ces relations sont utilises dans le MY comme un outil dadaptation et dassemblage pour dcrire des styles dvolution.
Figure 3.12 La reprsentation des concepts du style dvolution en utilisant le modle en Y.
63
La relation intra se dcline sous les formes DomaineDomaine, EntteEntte et Comptence Comptence. La spcialisation (est-une-sorte-de), la composition (est-compos-de) et lutilisation (utilise) dnis dans SAEM sont des relations intra-concepts. A titre dexemple, la spcialisation dun style dvolution est vue comme la combinaison dune spcialisation de son domaine (soustypage de llment volutif), de son entte (surcharge) et de sa comptence (rednition). On remarquera au passage quil ny a pas forcment isomorphisme entre la relation de spcialisation au niveau du style et celle au niveau de ses trois constituants. La mme remarque peut tre faite pour les relations de composition et dutilisation. La relation inter se dcline sous les formes DomaineEntte, DomaineComptence et Entte Comptence. Des relations smantiques jusqualors implicites mergent comme des relations inter-concepts. Il sagit de la relation dexpression (est-exprim-sur) et de la relation de ralisation (implmente). La premire sert relier un entte et une comptence un domaine. La seconde sert relier une comptence son entte.
tel-00459925, version 1 - 25 Feb 2010
3.5.2.2
Multi-abstractions et multi-vues
An de capturer tous les aspects des styles dvolution et encapsuler leur complexit, MY dcrit les styles selon deux dcoupages : multi-abstractions et multi-vues. Le dcoupage multi-abstractions Le dcoupage multi-abstractions dnit direntes abstractions pour un lment donn. Aussi, un style dvolution peut tre dcrit en utilisant dirents niveaux dabstraction. Chaque niveau dabstraction est reprsent par un cercle dans le modle en Y, partir du niveau le plus lev (cercle de fort diamtre) au niveau le plus bas (cercle de faible diamtre). Les deux acceptions donnes aux cercles correspondent labstraction de composition/dcomposition et labstraction de spcialisation/gnralisation. Dautres acceptions sont possibles si de nouvelles relations smantiques et hirarchiques sont introduites dans SAEM. Par exemple, la dicult exprimer limplmentation dun style dvolution peut tre reprsente en utilisant MY et son dcoupage multi-abstraction via la spcialisation. Dans ce cas, le cercle reprsentant le niveau le plus lev dabstraction montre uniquement un domaine et un entte et nous devons dcrire le style des niveaux dabstraction infrieurs an de trouver la comptence. En rgle gnrale, pour obtenir un style dvolution simpli avec un minimum dlments, nous devons logiquement le dcrire des niveaux dabstractions plus levs. Le dcoupage multi-vues La dcoupage multi-vues permet la dnition de direntes vues pour les styles dvolution. Nous prsentons trois vues : la vue gnrique, la vue abstraite et la vue concrte. La vue gnrique dcrit un style dvolution indpendamment dun domaine. La vue abstraite dcrit un style dvolution sans fournir sa mise en oeuvre. Enn, la vue concrte dcrit un style dvolution de manire complte. Le modle en Y reprsente direntes vues en utilisant plusieurs Ys. Chaque Y reprsente une vue dun style dvolution et comment ses dirents aspects (domaine, entte et comptence) sont supports dans cette vue. Par exemple, comme cela est illustr par la Figure 3.13, les domaines sont explicitement reprsents dans la vue abstraite et la vue concrte. Cependant, dans la vue gnrique, les domaines ne sont pas reprsents (il faut noter que toutes les vues sont ici illustres pour un mme niveau dabstraction).
64
Figure 3.13 La reprsentation de vues multiples en utilisant MY.
tel-00459925, version 1 - 25 Feb 2010
3.5.3
Exemple dillustration
Dans cette section, nous traitons lexemple du style dvolution Move@Port, dont le but est simplement de dplacer un port de son composant dorigine vers un composant de destination (de mme type que le composant dorigine). Intuitivement, un dplacement (couper/coller) peut tre vu comme la combinaison dun processus "couper" et dun processus "coller". Dans les termes de SAEM, ceci signie que Move@Port peut tre dcrit comme un style composite, incluant les styles dvolution ExcludePort@Component et IncludePort@Component. Dans la Figure 3.14, nous utilisons le modle en Y pour illustrer comment ces styles dvolution peuvent tre reprsents. La convention de nommage dun entte et dune comptence utilise dans MY sinspire dune bonne pratique issue du monde de la programmation o il est conseill de prxer les classes dinterfaces par la lettre I et de suxer les classes dimplmentation par Impl. Dans lexemple, en considrant lacception de composition/dcomposition, nous avons deux niveaux dabstraction : un niveau dabstraction lev dans lequel on trouve le domaine C&C (Composant & Connecteur), lentte IMovePort et la comptence IMovePortImpl. un niveau dabstraction moins lev dans lequel on trouve le domaine C&C, les enttes IExcludePort et IIncludePort ainsi que les comptences ExcludePortImpl et IncludePortImpl. Aussi, le modle MY pour cet exemple ne possde quune seule vue : la vue concrte. Dans cette dernire, les trois aspects (domaine, entte et comptence) sont supports.
3.6
Bilan de SAEM
Nous avons illustr les dirents lments de description du modle dvolution SAEM pour spcier lvolution dune architecture logicielle. Nous avons galement propos un formalisme de reprsentation des styles dvolution. Dans cette section, nous fournissons les lments de synthse relatifs ce modle dvolution base de style et nous montrons comment ce dernier se positionne vis--vis de la pyramide des besoins introduite dans le Chapitre 2 de cette thse.
65
tel-00459925, version 1 - 25 Feb 2010
Figure 3.14 La reprsentation de deux niveaux dabstraction pour le style Move@Port.
3.6.1
lments de synthse
Lide cl de notre modle dvolution est dattacher chaque lment architectural un ensemble de styles dvolution qui sont autant de possibilits pour son volution dans le temps. Il est ais daugmenter ou de diminuer le nombre de styles disponibles pour un lment architectural. Par essence, le style dvolution "connat" llment architectural et tient compte de sa structure. Cela est caractristique dune spcication de lvolution a priori, qui se distingue des spcications a posteriori o aucune garantie nest donne sur le choix dune volution appliquer un lment architectural. Reli ce dernier point, on remarquera quun lment architectural dnit un contexte dexcution pour ses styles dvolution et quil nest pas ncessaire de rednir ces derniers pour chaque sous-lment architectural. En exploitant ainsi le polymorphisme par sous-typage des lments volutifs eux-mmes, larchitecte est amen dcouvrir quel est lensemble des styles dvolution disponibles pour chacun des lments de son architecture. A titre dexemple, un composant de type Client peut voluer par son style Disconnect@Client bien sr, et intrinsquement par son style Remove@Component, mme si ce dernier ne lui est pas explicitement attach. Au haut niveau dabstraction de SAEM, il est important de remarquer que la composition et lutilisation de styles dvolution par un autre ne prjuge daucune contrainte de prcdence dans lexcution de ces dirents styles. Elle nen prcise pas lordre dapplication et na pas vocation modliser la dynamique de lexcution. Elle nimplique pas davantage que lors dune excution particulire, les dirents styles seront systmatiquement lancs. De faon exprimer dventuelles contraintes denchanement, il est ncessaire de dnir des relations dordonnancement telles que par exemple "est prcd de", "se poursuit par", "dmarre par", etc.
3.6.2
Positionnement dans la pyramide des besoins
Le tableau 3.2 rcapitule le positionnement de SAEM par rapport aux trois niveaux de la pyramide des besoins.
66

NIVEAU 1 : INTENTION DE SAEM
uisi rs xp w s r tuvhrqwxhy
ghipqrsi r tuvhrqwxhy
isi r wis s r tuvhrqwxhy
xvsq twiwxhy
hs tsisxhy
NIVEAU 2 : EXPRESSIVITE DE SAEM

hpxys ejvevj lg fvwlk xmd kdokdefgy rnjl
xvsq s phurxwxhy
uyxqs h uiwhxis zmdgl xjdkfggl{lge odkkdefjly
defg h rdgsdsl ql ketolk h ijdgkdjlgl mdjdnol ujdgvodje mdjdnol pfql
NIVEAU 3 : QUALITE DE SAEM

|uqwxrxxrxwu wsyxxrxwu vhrqwxvxwu hp hxwxhyyrxwu |sp rxrxwu
} q hiw fg
~ wxrxwu
Table 3.2 valuation de SAEM vis--vis de la pyramide des besoins.
tel-00459925, version 1 - 25 Feb 2010
Niveau 1 : SAEM est un modle dvolution conu pour formuler lvolution sous forme de styles et galement pour propager les impacts des volutions travers les relations smantiques inter-styles. Nous pensons que la traabilit de lvolution est une problmatique part entire et qui peut venir complter SAEM si besoin, sans en changer le fonctionnement. Niveau 2 : Les styles sont dcrits un haut-niveau dabstraction, mais une stratgie pour leur projection vers du code source est propose dans le Chapitre 4. Par ailleurs, la sparation de lentte et de la comptence dans la spcication dun style reconnat le principe largement accept du masquage de linformation [Par72] et permet de jouer sur le niveau de transparence lors de la rutilisation de lvolution. Le SAEM introduit ce que lon peut appeler un "langage de styles". Un langage de styles est une collection de styles formant un vocabulaire et une dmarche pour comprendre et communiquer des ides portant sur lvolution logicielle. Il dcrit la manire avec laquelle les styles sont inter-relis et la manire avec laquelle ils se compltent dans un tout cohsif. Dans SAEM, toute volution rcurrente constitue un style dvolution et est ainsi manipule de manire uniforme, que celle-ci soit forte ou plus ne granularit. Il est utile de faire la distinction entre les volutions qui sont communes tous les systmes base de composants, de celles qui sont communes une famille particulire de systmes. Nous dsignons la premire catgorie sous le terme dvolution gnraliste tandis que nous dsignons la deuxime catgorie sous le terme dvolution ddie 3 . Nous suggrons que la plupart des volutions ddies peuvent tre vues comme des extensions des volutions gnralistes an de les personnaliser des besoins particuliers. Pour permettre de spcier des styles dvolution ayant une porte variable dans SAEM, les couches dvolution sont obtenues grce la relation de spcialisation inter-styles et son mcanisme dhritage. Lvolution peut tre gre nimporte quel niveau de modlisation dune architecture logicielle ; tout dpend de la faon dont SAEM est utilis. Dans SAEM, nous nous basons sur le principe suivant : pour pouvoir grer lvolution dune architecture logicielle dcrite sur un niveau de modlisation Ai , il faut dabord identier le niveau de modlisation suprieur Ai+1 qui a permis linstanciation de larchitecture. Tout style dvolution sera alors spci sur la base
3. Les termes anglais correspondants seraient general-purpose evolution et domain-specic evolution.
67
des lments appartenant Ai+1 pour tre excut sur les architectures instancies partir de ce niveau. Ceci est comparable la dnition des classes et des objets dans le paradigme objet, o les structures et les comportements des objets sont toujours dcrits par leurs classes mais sappliquent aux objets. On peut dire que SAEM ore une mcanique opratoire avance. Larchitecte a sa disposition les relations dinstanciation, de spcialisation, de composition et dutilisation pour pouvoir dcrire et grer lvolution selon ses besoins. En outre, en associant chaque type dlment architectural son ou ses styles dvolution, le raisonnement relatif lvolution se retrouve distribu travers les lments de larchitecture. En rgle gnrale, un raisonnement distribu facilite le passage lchelle, qui est une question importante en raison de la taille et la complexit croissantes des systmes logiciels, et qui est prne dans les dnitions rcentes de lvolution comme celles trouves dans les architectures auto-organises [GMK02]. Nous verrons dans le Chapitre 4 que le raisonnement support par SAEM est de type classicatoire.
tel-00459925, version 1 - 25 Feb 2010
Niveau 3 : SAEM seorce dorir un bon niveau de rutilisation. En eet, il favorise : 1. Lextensibilit : chaque nouvel ajout de style un lment volutif ne perturbe aucunement le fonctionnement des styles dj prsents. 2. Lvolutivit : la comptence dun style peut tre modie sans impacter la faon dont dautres styles lutilisent. 3. La compositionalit : la relation de composition fournie par SAEM permet la spcication de styles dvolution composites. 4. La remplaabilit : un style peut tout fait tre substitu un autre style, du moment quil possde la mme entte. SAEM ore un bon support pour le dveloppement darchitectures volutives, en reposant sur une description minimaliste des styles dvolution. Le formalisme du modle en Y contribue la simplicit de SAEM. Enn, ladaptabilit nest pas prise en compte pour linstant par le modle dvolution SAEM, mais a t anticipe travers la notion de vue gnrique (cf. gure 3.13).
3.7
Conclusion
Nous avons prsent dans ce chapitre le modle dvolution baptis SAEM, que nous proposons pour prendre en compte la problmatique de lvolution structurelle des architectures logicielles. Nous avons mis en avant dans SAEM la ncessit de dissocier la spcication de lvolution de la spcication de larchitecture logicielle en elle-mme. Cest ainsi que SAEM sest eorc de proposer des concepts pour la spcication et la gestion de lvolution dune architecture logicielle, indpendamment de tout ADL. Nous avons soulign au travers de SAEM, la ncessit de considrer les dirents niveaux de modlisation dune architecture logicielle, et la ncessit de grer lvolution au travers de ces dirents niveaux, de manire uniforme. Nous avons galement mis en avant limportance de la propagation des impacts pour garantir la cohrence globale de larchitecture amene voluer. Les stratgies de propagation sont vhicules par les relations smantiques qui existent entre les styles dvolution. Nous avons introduit le formalisme MY qui dcrit les concepts du styles dvolution selon trois branches : domaine, entte, comptence. Des liens intra et inter permettent de grer les
68
direntes dpendances quentretiennent les trois aspects du tryptique. En outre, MY est multivues et multi-abstractions. Ainsi, MY est utilis pour dcrire sous forme modulaire et rutilisable des styles dvolution. Jusqu prsent, nous navons propos aucune dmarche pour aider les architectes exploiter SAEM. Une dmarche est pourtant ncessaire pour assurer lecacit de notre approche de rutilisation dans le contexte de lvolution dans les architectures base de composants. Cet aspect fait lobjet du chapitre suivant.
tel-00459925, version 1 - 25 Feb 2010
C HAPITRE
Bibliothques pour les styles dvolution

Contrairement aux approches dvolution usuelles dont la ralisation dmarre partir de rien from scratch et ncessite de tout rinventer chaque fois, la rutilisation est une approche qui peut permettre de traiter lvolution dune architecture logicielle partir dlments existants stocks dans des bibliothques. De cette faon, les architectes minimisent le travail redondant. Ils augmentent la abilit de leur travail vu que chaque volution rutilise a dj t contrle et inspecte au cours de sa spcication originelle. Ainsi, le temps consacr aux activits dvolution dans une architecture est rduit de faon considrable. Lide dveloppe ici est celle de vritables styles dvolution sur tagre. Ainsi, nous suggrons de dsigner ces styles prt lemploi sous lacronyme EOTS (Evolution-O-The-Shelf ). Il nest donc pas susant de disposer dun modle dvolution riche et expressif, encore faut-il lui associer les bons mcanismes et les bonnes rgles pour pouvoir rutiliser les styles dvolution. Dans ce chapitre nous donnons les instruments ncessaires la mise en uvre dune approche par rutilisation dans le contexte de SAEM. En particulier, le modle en Y prsent dans le chapitre prcdent est dsormais dot de trois niveaux de modlisation et amliore la rutilisation des styles dvolution en supportant des bibliothques pour chaque niveau. Nous identions dirents acteurs pour intervenir dans les bibliothques et nous dveloppons un processus de construction de ces dernires pour la rutilisation et par la rutilisation . Nous mettons laccent sur la bibliothque stockant des types de styles dvolution et orons une infrastructure pour les exploiter, reposant sur une technique de raisonnement de nature classicatoire. Ce type de raisonnement se base sur les processus de classication et sapprhende comme une procdure de dduction oprant sur une hirarchie quelconque (de spcialisation, de composition, de modlisation). Notre infrastructure inclut deux types de classication, lune oprant au niveau statique, lautre au niveau dynamique. La premire concerne la classication de types de styles dvolution et repose sur linfrence de relations "est-une-sorte-de" ou "est-compos-de". Elle sera exploite pour peupler et interroger la bibliothque de types de styles. La seconde concerne la classication dinstances de styles dvolution et repose sur linfrence de relations "est-un". Elle sera exploite dans le cadre de linstanciation de types de styles an de dterminer, si cela est ncessaire, les bonnes comptences appliquer sur une architecture en cours dvolution.
tel-00459925, version 1 - 25 Feb 2010
4.1
Bibliothques pour les styles dvolution
Nous avons dot MY de trois niveaux de modlisation, supportant des bibliothques dlments rutilisables pour chaque niveau. An de clarier le fonctionnement du processus de ruti69
70
CHAPITRE 4 Bibliothques pour les styles dvolution
lisation et lintervention de dirents acteurs sur les bibliothques, nous dcrivons la construction des bibliothques.
4.1.1
Niveaux de modlisation des bibliothques
MY supporte des bibliothques dlments de dirents niveaux de modlisation, partir de la dnition du mta-modle SAEM jusquau niveau de lvolution lexcution (cf. gure 4.1). Nous pouvons distinguer trois niveaux : le niveau mta-style dvolution E2, le niveau type de style dvolution E1 et le niveau instance de style dvolution E0. Ainsi, la bibliothque de niveau mta stocke des lments mta tels que le domaine, lentte et la comptence ; la bibliothque de niveau type stocke des types dlments tels que C&C, IMovePort et MovePortImpl ; et enn la bibliothque de niveau instance stocke des lments tels que lvolution visant spciquement dplacer le port p1.
tel-00459925, version 1 - 25 Feb 2010
Figure 4.1 Les bibliothques pour les styles dvolution. Notre approche permet didentier les lments rutilisables pour chaque niveau de modlisation, de manire uniforme en utilisant un MY. Ces lments sont alors stocks dans une bibliothque lie chaque niveau de modlisation et utilise par son niveau infrieur. Par exemple, les lments rutilisables du niveau mta-style sont : domaine, entte et comptence. Ils sont stocks dans une bibliothque de niveau E2 et utiliss au niveau E1. Par ailleurs, la Figure 4.1 tend lillustrer la coexistence des trois niveaux de modlisation du paradigme des styles dvolution avec les trois (ou quatre) niveaux de modlisation des architectures logicielles qui peuvent "glisser" verticalement an de prciser sur quel niveau de modlisation une volution est opre. Par exemple, une bibliothque de niveau E1 peut contenir des types de styles dvolution qui peuvent tre spcis sur la base des lments du domaine du niveau A2 ou bien A1 dune architecture logicielle. Selon le cas, le niveau A1 ou le niveau A0
71
dune architecture peut voluer concrtement grce aux instances des styles dvolution contenues au niveau E0.
4.1.2
Acteurs relatifs aux bibliothques
tel-00459925, version 1 - 25 Feb 2010
Nous avons identi trois rles dacteurs pour le modle en Y. Chacun est associ un niveau donn (E2, E1 ou E0). En plus, un quatrime acteur est ncessaire pour grer les bibliothques. Ainsi, nous avons : Le constructeur dinfrastructure dvolution (CIE) : dnit les concepts de base sur lesquels larchitecte dapplication volutive sappuie pour tablir un ensemble de types de styles dvolution. Le CIE est concern par le niveau de modlisation E2. Larchitecte dapplication volutive (AAE) : son rle est de concevoir et de dcrire les types de styles dvolution qui seront utiliss pour le dveloppement dapplications volutives. Il le fait travers linstanciation des concepts fournis par le CIE. LAAE est concern par le niveau de modlisation E1. Le dveloppeur dapplication volutive (DAE) : son rle est de faire voluer une architecture logicielle en instanciant le niveau E1. Le DAE est concern par le niveau E0. Le bibliothcaire de lvolution (BE) : construit et gre toute les bibliothques. Le bibliothcaire de lvolution est concern par tous les niveaux de modlisation. Les bibliothques sont donc hirarchises suivant les trois niveaux de modlisation et se composent : au niveau E2 des concepts de domaine, dentte et de comptence dnis par le CIE, au niveau E1 des types de styles dvolution, crs par assemblage de types de domaines, de types denttes et de types de comptences dnis par lAAE, au niveau E0 des instances de styles dvolution dnies par le DAE, cres partir dinstances de domaines, dinstances denttes et dinstances de comptences. La Figure 4.2 prsente le diagramme de squence dun scnario possible pour les direntes oprations sur les bibliothques. Ce scnario se dcompose en deux tapes : 1. tape de dnition dun type de style dvolution : au cours de cette tape, lAAE envoie une demande des lments du niveau E2 au BE pour pouvoir dnir un type de style (phase 1). Ensuite, le BE recherche les lments dans la bibliothque du niveau E2, les rcupre (phases 2 et 3) et les lments sont fournis lAAE (phase 4). Enn, lAAE conrme la rception par un accus (phase 5). Dans le cas o ces lments ne sont pas disponibles dans la bibliothque, le BE demande au CIE de construire ces lments. 2. tape dvolution dune architecture logicielle : durant cette tape, le DAE demande au BE des types de styles pour faire voluer larchitecture (phase 6). Ensuite le BE recherche dans la bibliothque de niveau E1, rcupre ces types de styles (phases 7 et 8) et fournit ces lments au DAE (phase 9). Enn, le DAE envoie au BE un accus de rception (phase 10). Dans le cas o ces lments ne sont pas disponibles dans la bibliothque, le BE demande lAAE de les construire.
4.1.3
Construction des bibliothques
Nous lavons vu, direntes bibliothque dlments rutilisables existent pour chaque niveau de modlisation. La problmatique de rutilisation se pose alors en terme de construction de ces
72


tel-00459925, version 1 - 25 Feb 2010
Figure 4.2 Le diagramme de squence pour les oprations sur les bibliothques. bibliothques. Nous suggrons une approche de construction pour et par la rutilisation pour chaque niveau. Une telle approche applique spciquement aux bibliothques de types de styles dvolution (niveau E1) fait lobjet dune attention toute particulire pour notre travail.
4.1.3.1
Processus pour et par la rutilisation
Nous suggrons une approche permettant aux lments rutilisables de chaque niveau (E2, E1 et E0) dtre vus selon leur construction (pour la rutilisation) an de construire une bibliothque, et leur utilisation en les choisissant partir dune bibliothque (par la rutilisation) pour tablir de nouveaux lments ou pour les instancier. Cette approche concerne la description des lments rutilisables suivants deux tapes [CS99, BCO 04] : 1. Lingnierie pour la rutilisation qui permet de spcier les lments qui sont tablis pour la rutilisation de chaque niveau de modlisation. Les lments rutilisables sont identis selon leur niveau de modlisation, reprsents en utilisant un langage formel, semi-formel ou descriptif et ensuite intgrs dans une bibliothque associe en choisissant une mthode bien dnie (hirarchise par type, par taille, par contenu, par la frquence de rutilisation, etc.). 2. Lingnierie par la rutilisation qui permet de spcier les lments qui peuvent tre tablis par la rutilisation o la recherche et la slection des lments rutilisables sont faites selon les besoins, qui sont exprims par les direntes catgories dacteurs. La technique de recherche dpend fortement de lorganisation des lments dans la bibliothque aussi bien que du langage choisi durant ltape prcdente. Les lments choisis sont adapts si besoin, et utiliss dans le niveau de modlisation en cours.
73
4.1.3.2
Activits spciques la rutilisation de styles dvolution
Dans cette section, sont considres les activits spciques la mise en uvre dune approche de rutilisation de styles dvolution, stocks dans une bibliothque de niveau E1. Ces activits se rangent dans deux catgories, celles correspondant au point de vue du producteur de style dvolution (processus pour la rutilisation) et celles correspondant au point de vue du consommateur de style dvolution (processus par la rutilisation). Production de style dvolution Cette activit est essentielle dans le processus de rutilisation puisquelle a pour objectif de produire les styles dvolution rutilisables. Cest aux architectes dapplication volutive (AAE) que revient la tche didentier de manire systmatique toutes les volutions qui peuvent tre candidates la rutilisation, travers leur connaissance du domaine et leurs expriences passes. Aprs leur identication, elles doivent tre reprsente dans notre langage de style. Les styles sont alors organiss selon des liens intra-concepts (spcialisation, composition et utilisation) pour tre intgrs dans une bibliothque de niveau E1. Consommation de style dvolution Cette activit consiste rechercher dans une bibliothque un style dvolution qui rponde un besoin particulier dvolution. Dans la plupart des situation, il ny a pas un seul style candidat qui rpond au besoin, mais plusieurs. Les techniques de recherche mise en oeuvre dans ce contexte peuvent tre issues du domaine de la recherche dinformation (navigation dans une hirarchie, recherche par mot-cls). Nous distinguons deux faons de rutiliser un style dvolution : La rutilisation travers la composition et la spcialisation : un AAE rcupre un ou plusieurs styles existants dans une bibliothque an de les adapter ses besoins par composition et/ou par spcialisation. Notamment, les styles abstraits sont des super-styles dans lesquels la comptence na pas t implmente. Ainsi, un style abstrait dnit un entte standard pour tous ses styles descendants. Il forme une sorte de point dextension destin tre complt lors de sa rutilisation. La rutilisation travers linstanciation : la rutilisation devient eective si le style peut tre instanci et excut par un DAE sur son architecture en cours dvolution. Ici, la rutilisation se traduit par un processus de gnration [BR89]. Contrairement aux connaissances de type produit, il y a une forte dirence entre le style dvolution avant sa rutilisation et aprs sa rutilisation (le rsultat de lvolution sur larchitecture).
tel-00459925, version 1 - 25 Feb 2010
4.1.3.3
Approche orient problme du style dvolution
Un style dvolution respecte pleinement le principe dabstraction, jug essentiel en matire de rutilisation [CS99]. En eet, un style dvolution reconnat la distinction entre la spcication et la ralisation de lvolution, travers son entte et sa comptence. Comme lillustre la Figure 4.3 on peut considrer que lentte dun style est centr sur lexpression dun problme et que la comptence correspond sa solution. Clairement, les styles et les patrons sont deux types de propositions reprsentatives de lapproche orient problme. Nous considrons toutefois le concept de style comme une variante plus formelle du patron, notamment travers son mcanisme dinstanciation, plus rigoureux que lopration "intuitive" dimitation portant sur les patrons. En outre, la faible quantit dinformations informelles d-
74
Figure 4.3 Orientation problme dun style dvolution. crites au sein dun style permet plus quune simple utilisation manuelle. Les styles dvolution structurent les solutions sur la base dun triplet domaine-entte-comptence et, linstar des patrons, ils peuvent tre vus comme des codes de bonnes pratiques. Une bibliothque de styles dvolution doit ainsi tre perue comme un rservoir de solutions des problmes dvolution rcurrents sur les architectures logicielles, aliment par des architectes dapplications volutives et o viennent puiser dautres architectes ou dveloppeurs dapplications volutives.
tel-00459925, version 1 - 25 Feb 2010
4.2
laboration dune bibliothque de styles dvolution
Llaboration dune bibliothque de styles dvolution cible des problmes dorganisation hirarchique des styles dvolution dune part, et de dnition des besoins de recherche, daccs, dadaptation et dinstanciation des styles dvolution, dautre part. Elle produit une infrastructure pour le systme de rutilisation, en rendant oprationnelles les oprations dintgration et de recherche de styles dvolution dans la bibliothque de niveau E1. Un mme raisonnement classicatoire sur les types de styles sous-tend ces oprations. Cest pourquoi nous commenons par expliquer son fonctionnement avant de prsenter les oprations en elle-mmes.
4.2.1
Classication de styles dvolution
Tout au long de son existence, ltre humain apprend une grande quantit de connaissance quil mmorise de faon structure. Face une situation inconnue, il cherche dans sa mmoire des situations similaires dj vcues pour en tirer des conclusions. Ce raisonnement entrane donc une tape de classication dans laquelle la nouvelle connaissance est compare avec les apprentissages prcdents et classe dans la structure. Dans le domaine de lintelligence articielle, Clancey [Cla85] a montr que la plupart des systmes expert incluent des tapes de classication. La dnition du terme classication qui nous intresse ici est la classication de dnitions de styles dvolution dans la bibliothque de niveau E1, jouant ici le rle de base de connaissance. Pour mettre en pratique ce processus, nous nous appuyons sur lorganisation des styles dvolution stocks sous forme dun graphe.
75
4.2.1.1
Un double point de vue : spcialisation et composition
Nous dnissons le contenu de la bibliothque de niveau E1 comme un graphe quelconque de styles dvolution, qui peut tre ltr travers le point de vue de la spcialisation et de la composition. Ceci est possible car nous considrons explicitement la nature hirarchique des relations smantiques de spcialisation et de composition (cf. section 3.3.4). Le ltrage travers ces deux points de vues isole deux hirarchies distinctes lune de lautre. Nous schmatisons cela par la Figure 4.4. Examinons maintenant plus en dtail ces deux types de hirarchie.
tel-00459925, version 1 - 25 Feb 2010
Figure 4.4 Filtrage par points de vue sur la bibliothque de niveau E1.
Hirarchie de spcialisation Le ltrage par la relation de spcialisation produit un arbre 1 , appel hirarchie de spcialisation. Nous notons cette hirarchie Hs = (E, s , s ), o E est un ensemble ni de styles dvolution, s est la relation dordre de spcialisation entre les styles, et s est llment dunit de E suivant s . s est appele racine de la hirarchie de spcialisation et correspond un style dvolution abstrait et dentte vide, introduit articiellement par le systme, nomm Evolution. On reprsente le fait quun style dvolution B est subsum par A en traant larc BA. La prsence de cet arc signie que B est une sorte de A. Hirarchie de composition Le ltrage par la relation de spcialisation produit un graphe, appel hirarchie de composition. Nous notons cette hirarchie Hc = (E, c , c ), o E est un ensemble ni de styles dvolution, c est la relation dordre de composition entre les styles, et c est llment dunit de E suivant c . c est appele racine de la hirarchie de composition et correspond un style dvolution introduit articiellement par le systme, nomm NEV (No EVolution), dont lentte et la comptence sont vides. On reprsente le fait quun style dvolution B est subsum par A en traant larc BA. La prsence de cet arc signie que B est compos de A.
4.2.1.2
Hirarchie de subsomption
Une relation de subsomption est une relation gnrale qui dnit une structure hirarchique parmi un ensemble de concepts. Elle ne dnit pas forcment une arborescence, mais plutt un
1. Car SAEM nautorise que lhritage simple.
76
tel-00459925, version 1 - 25 Feb 2010
treillis. Un subsumant et un subsum se disent respectivement dun concept hirarchiquement suprieur et dun concept hirarchiquement infrieur, selon une relation smantique particulire. Par exemple, on peut tablir quun entier subsume un autre entier sil est un multiple de ce dernier. Un test de subsomption est une opration qui infre lexistence dun relation de subsomption entre deux concepts B et A (ce qui est not B A). Un test de subsomption est donc une fonction boolenne de signature B A Bool. Le processus de classication de styles cherche mettre en vidence les liens implicites qui existent entre les styles dvolution. Ce mode de raisonnement, appel raisonnement classicatoire ou taxinomique, permet dexploiter la connaissance capitalise dans une bibliothque, relativement la hirarchie tudie. On peut dnir les relation de spcialisation et de composition de SAEM comme deux relations de subsomption spciques. Notre stratgie est de proposer un processus capable de reproduire un raisonnement par classication, et totalement indpendant de la hirarchie considre. La caractre gnrique de ce processus permet une conomie lors de la phase de codage, dont le comportement pourra tre paramtr au besoin par : Le test de subsomption par la spcialisation (calcule la relation "est-une-sorte-de") Le test de subsomption par la composition (calcule la relation "est-compos-de")
4.2.1.3
Raisonnement classicatoire
Indpendamment du test de subsomption considr, le raisonnement par classication men sur un style dvolution x se dcompose en deux tapes, dont le lecteur trouvera le dtail en Annexe B : 1. La recherche des subsumants les plus spciques (SPS ) du style dvolution x classer. Cela revient dterminer lensemble de ses ascendants immdiats dans la hirarchie. 2. La recherche des subsums les plus gnraux (SPG) du style dvolution x classer. Cela revient dterminer lensemble de ses descendants immdiats dans la hirarchie. Un exemple du rsultat du calcul des SPS et des SPG dun style x est illustr par la Figure 4.5, soit sur une hirarchie de spcialisation, soit sur une hirarchie de composition. Lorsque lon considre une description de style dvolution x classer dans une bibliothque, celle-ci possde ncessairement au moins deux relation smantiques avec lexistant. En eet, par dfaut, toute nouvelle description est relie par spcialisation la racine Evolution 2 , et relie par composition la racine NEV. Bien sr, la nouvelle description peut parfaitement tre relie des styles situs autre part dans les hirarchies de spcialisation et de composition.
4.2.2
Opration dintgration dans une bibliothque
Larchitecte dapplication volutive (AAE) a la charge de spcier les lments qui sont tablis pour la rutilisation. Ces lments rutilisables sont identis et reprsents sous forme de styles et ensuite intgrs dans la bibliothque du niveau E1, dans le respect de sa structure hirarchique. Pour rendre eective cette intgration, nous dcrivons un processus de peuplement de la bibliothque bas sur un raisonnement classicatoire.
2. Comme dans le langage Java par exemple, o toute nouvelle classe tend par dfaut la classe racine Object.
77
tel-00459925, version 1 - 25 Feb 2010
Figure 4.5 Reprsentation schmatique du raisonnement classicatoire sur un style dvolution x dans une hirarchie de spcialisation (en haut) et dans une hirarchie de composition (en bas).
78
4.2.2.1
Objectif
tel-00459925, version 1 - 25 Feb 2010
Tout lenjeu de lintgration consiste prserver la structuration de la bibliothque de niveau E1 selon ses deux points de vues : spcialisation et composition. Puisque le contenu de la bibliothque est hirarchis, cest une condition sur toute la bibliothque. En dautres termes, chaque fois que lon fait quelque chose, comme ajouter un style dvolution, il faut rorganiser la bibliothque pour maintenir la condition globale 3 induite par les relations dordre de spcialisation et de composition. La suppression dun style dvolution de la bibliothque est soumise aux mmes rgles mais nest pas aborde dans le cadre de cette thse. Lopration dintgration est dautant plus importante dans un contexte multi-utilisateurs, o dirents architectes dapplications volutives peuvent cooprer pour augmenter le niveau global dexpertise. En eet, un AAE na souvent quune vision locale des connaissances contenues dans la bibliothque. Par consquent, disposer dune infrastructure pour la maintenance des relations smantiques entre les styles dvolution est important. A ce titre, il est utile de rappeler que ces relations prservent la cohrence des connaissances accumules, et quelles sont remises en cause chaque fois que lintgration dun nouveau style dvolution dans la bibliothque se produit. Un processus uniquement assur par lhumain peut tre trs dangereux, voire impossible, ds lors que la taille de la bibliothque atteint un certain seuil. Nous pouvons schmatiser le fonctionnement du processus dintgration dun style dvolution x dans une bibliothque E de la manire suivante : (E, , ) {x} (E x, , )
4.2.2.2
Fonctionnement
Bien que les problmatiques de classication soient direntes entre spcialisation et composition, le schma gnral dintgration dun style x dans la bibliothque est le suivant : 1. Calcul de SPS(x), lensemble des styles subsumants x dans la bibliothque. 2. Calcul de SPG(x), lensemble des styles subsums par x dans la bibliothque. 3. Ajout des relations entre x et ses SPS et SPG. 4. Suppression des relations de transitivit ventuellement cres. 5. Vrication de la conservation des proprits de la hirarchie et modication ventuelle. Les tapes 1 et 2 ont t expliques prcdemment. Les tapes 3 5 concernent linsertion proprement dite de la spcication de x dans la hirarchie considre. Le processus dinsertion peut tre amen restructurer la spcication du style x et celle de ses voisins. Pour sassurer dune intgration en une seule passe, le processus dinsertion dans la hirarchie de composition doit tre antrieur au processus dinsertion dans la hirarchie de spcialisation. De cette faon, la variation des relations de type "est-compos-de" induite par une restructuration de la spcication x est prise en compte quand vient le moment de classer x dans la hirarchie de spcialisation. Reli ce dernier point, ltape 5 concerne spciquement la hirarchie de spcialisation o il est question dliminer automatiquement la dnition de certains paramtres et assertions de lentte des spcications restructures pour viter la redondance avec celles dsormais hrites.
3. Le maintien dune condition globale est un exemple dun calcul orient but.
79
tel-00459925, version 1 - 25 Feb 2010
Figure 4.6 Schma de lopration dintgration dun style x dans une hirarchie de spcialisation (en haut) et dans une hirarchie de composition (en bas).
En reconsidrant lillustration prsente dans la section 4.2.1.3, le rsultat de linsertion du style x serait celui de la Figure 4.6. Selon le point de vue de la spcialisation, et compte tenu des SPS et SPG calculs par un raisonnement classicatoire bas sur la subsomption de spcialisation, x est une sorte de S2, et S5 et S6 sont des sortes de x. Selon le point de vue de la composition, et compte tenu des SPS et SPG calculs par un raisonnement classicatoire bas sur la subsomption de composition, x est compos de S1 et de S2 (i.e., pas de restructuration ncessaire) et S4 est maintenant compos de x et de S3. Ces restructurations en cascades naltrent pas les buts des styles stocks dans la bibliothque mais leur assurent une bonne organisation qui inuencera ncessairement leur recherche.
4.2.3
Opration de recherche dans une bibliothque
Larchitecte dapplication volutive (AAE) ou le dveloppeur dapplication volutive (DAE) ont la charge de spcier les lments qui peuvent tre tablis par la rutilisation dans la bibliothque de niveau E1. Les styles dvolution doivent tre recherchs et slectionns selon les besoins. Pour oprationnaliser cette recherche, linfrastructure ore de nouveau une technique base sur un raisonnement classicatoire.
80
4.2.3.1
Objectif
tel-00459925, version 1 - 25 Feb 2010
Lobjectif est dexplorer la bibliothque en vue de rutiliser, autant que possible, les styles dvolution qui rpondent aux besoins exprims par un AAE/DAE : sa question (ou requte). Sa question correspond un problme dvolution auquel il espre trouver une rponse par le biais de linfrastructure de rutilisation. Rpondre sa question consiste trouver dans la bibliothque le ou les style(s) dvolution qui ore(nt) la comptence demande. Une technique de recherche par mot-cls applique au nom et/ou au but des styles nest pas pertinente ici. A la place, nous suggrons dexploiter un raisonnement classicatoire pour dterminer la place dune requte dans la structure hirarchique de la bibliothque. Toutefois, cette approche ncessite de se donner la peine de reprsenter une requte comme un style dvolution q . En contrepartie, il nest pas ncessaire pour lutilisateur dapprendre un langage spcique de requte (type SQL ou autre). La requte q est reprsente sous forme dun style abstrait, cest--dire qui possde un entte, mais pas de comptence. En eet, larchitecte est capable de dcrire un problme mais nest pas en mesure de dcrire sa solution. Or, cest prcisment cette solution que larchitecte peut raisonnablement esprer obtenir dune infrastructure de rutilisation. Comme lillustre la Figure 4.7, la phase de rsolution du problme peut en gnral tre apprhende comme la complmentation dun entte par une comptence en vue dobtenir un style dvolution concret (car complet).
Figure 4.7 Vue schmatique du fonctionnement de lopration de recherche dans la bibliothque partir dun style abstrait q . Un raisonnement classicatoire peut tre employ comme mcanisme dvaluation de la requte puisque la partie entte dun style est ncessaire et susante pour le test de subsomption. Le processus dvaluation dune requte consiste ainsi situer q dans une bibliothque E et permet daller au del de simples rponses binaires - "oui" ou "non" -, notamment en prenant en considration des rponses candidates. Les rsultats de la requte, nots R, reprsentent len-
81
semble des comptences stockes dans la bibliothque et en mesure de satisfaire la requte q , directement ou travers une adaptation. Nous pouvons schmatiser le fonctionnement du processus de recherche de la manire suivante : (E, , ) {q } R
4.2.3.2
Fonctionnement
Le processus dvaluation dune requte renvoi trois valeurs possibles : succs, candidat, ou chec. Nous dtaillons les direntes situations dans la table 4.1.
valuation Raisonnement Description
Succs
tel-00459925, version 1 - 25 Feb 2010
Candidat
chec
Table 4.1 Classes de rsultats bass sur un raisonnement classicatoire par spcialisation ou composition. La technique sappuyant sur un raisonnement classicatoire supporte le couple succs/chec oert par nimporte quelle technique classique dentreposage, mais avec tout de mme la possibilit de direncier son raisonnement : spcialisation ou composition. De ce fait, linfrastructure de rutilisation rpond de deux manires direntes : votre problme dvolution est une sorte de . . . ou votre problme dvolution est compos de . . . . Le succs signie lquivalence 4 de la requte q avec un style prsent dans la bibliothque. Remarquons que lquivalence selon la spcialisation implique lquivalence selon la composition. Lchec signie que la bibliothque ne contient pas encore de solution au problme pos. Assurment, la valeur ajoute de la technique base de classication est de proposer des rponses candidates qui auraient t normalement ignores par une technique dentreposage classique. Disposer de solutions alternatives est un avantage car la probabilit dappariement strict diminue dans un contexte multi-utilisateur comme cest le cas ici. Enn, nous faisons remarquer que luniformit de lapproche propose permet un basculement rapide de lopration de recherche vers lopration dintgration. Ceci prsente un intrt dans deux cas prcis :
4. Deux styles sont quivalents si une relation de subsomption mutuelle existe entre eux, i.e. A BsiA BB A
82
Le premier cas de gure se produit lorsque des styles candidats sont destins tre rutiliss "ensembles" par larchitecte. Linstanciation de ces styles sur les bons lments architecturaux et dans le bon ordre tmoigne de la comptence de larchitecte. On en revient alors la motivation premire de cette thse, stipulant quil serait prfrable de capturer cette comptence de manire explicite pour en faire un nouveau style composite, rutilisable son tour. Le cas chant, le DAE se retrouve dans la position de lAAE. Le second cas de gure apparat lorsque les styles souhaits par le DAE ne sont pas disponibles, et auquel cas le BE peut demander lAAE de les construire (cf. section 4.1.2). Pour faciliter le travail, il est opportun de considrer la requte qui a chou comme une connaissance partielle ajouter ds prsent la bibliothque et pouvant tre ultrieurement complte lors de sa rutilisation par spcialisation, grce lintervention dun AAE comptent sur cette classe de problmes.
4.2.4
tel-00459925, version 1 - 25 Feb 2010
Discussions
Dans lapproche dcrite, la bibliothque de niveau E1 est un simple fournisseur de styles volution dont laccs est explicitement demand par lutilisateur. Ds le dpart, notre infrastructure na pas vocation fournir un support lvolution automatique darchitectures et par consquent ne cherche pas assister et/ou guider la recherche et ladaptation des styles compte tenu des besoins dun AAE/DAE. Cette constatation peut tre analyse plus nement selon les trois points suivants.
4.2.4.1
Approche statique
Lindexation et par consquent la recherche de styles dvolution nest pas base sur lutilisation de mot-cls, mais sur leur organisation hirarchique. Cette organisation a une inuence directe sur la manire dexploiter les styles dvolution. Cette organisation prescrit entirement le processus de recherche et dintgration des styles. En eet, les relations de spcialisation et de composition dnissent statiquement un chemin entre les styles dvolution.
4.2.4.2
Niveau daide apporte
Linfrastructure nintgre pas de fonctions dadaptation et dinstanciation des styles. En eet, le style dvolution rutilis est "manuellement" adapt et/ou instanci par larchitecte dans lapplication en cours dvolution. Par ailleurs, linfrastructure ne supporte pas une recherche de styles partir dun problme dvolution donn haut-niveau car la technique de recherche mise en place ncessite davoir dj une "bonne ide" du style souhait. En eet, linfrastructure oblige lutilisateur dcrire son problme sous forme dun entte, ce qui ncessite a priori une connaissance prcise du style recherch.
4.2.4.3
Niveau de rutilisation
Steven Wartik [WPD92] a propos trois niveaux de maturit pour caractriser une approche par rutilisation : (1) le niveau de rutilisation ad-hoc, (2) le niveau de rutilisation opportuniste et (3) le niveau de rutilisation systmatique. Linfrastructure que nous proposons se situe un niveau 2, cest--dire de rutilisation opportuniste. En eet, un architecte dispose dune bibliothque de styles rutilisables et de mcanismes pour intgrer et rechercher des styles. Cependant,
83
dune part le producteur de styles dvolution a la charge didentier des situations dvolution pour lesquelles la rutilisation est possible et dautre part, le consommateur de styles dvolution a la charge de choisir les styles adapts son problme.
4.3
Rutilisation travers linstanciation
Nous venons de voir quun DAE peut rechercher des styles dvolution correspondants ses besoin en vue de les instancier sur son architecture ncessitant dvoluer. Dans cette section, nous explicitons le fonctionnement de linstanciation dun type de style dvolution et le processus dvolution qui en dcoule. Dans SAEM, le processus dvolution se ralise en quatre phases : une phase dinvocation, une phase de recherche (ou dexploration), une phase dexcution et enn une phase de validation. Nous utilisons le diagramme dtats-transitions dUML pour spcier les direntes tapes de chaque phase. Le formalisme est dcrit en Figure 4.8.
tel-00459925, version 1 - 25 Feb 2010
Figure 4.8 Les quatre phases dun processus dvolution dans SAEM.
84
4.3.1
Phase dinvocation
Dans SAEM, linstanciation et linvocation dun style sont confondus. Une invocation est un message destination dune instance en vue de dclencher lexcution de la comptence implmente dans son type de style dappartenance (via le lien "est-un"). Un message peut tre synchrone ou asynchrone selon le lien smantique (spcialisation, composition ou utilisation) qui le vhicule. Le format standard dun message est le suivant : <invoke, ([paramtres]>. A titre dexemple, le message <invoke, (server1,response1)> envoy une instance du style dvolution IncludePort@Component (Figure 3.8) va excuter la comptence pour permettre dajouter le port response1 la structure du composant server1. Deux acteurs peuvent tre lorigine dune invocation : Un DAE : pour raliser une volution, larchitecte choisi llment architectural quil souhaite faire voluer ainsi que le style dvolution invoquer sur cet lment. Un style dvolution : lexcution de la partie comptence dun style peut invoquer dautres styles pour propager les impacts.
tel-00459925, version 1 - 25 Feb 2010
4.3.2
Phase de recherche
Lorsquun message est reu par une instance et si la prcondition dnie dans la partie entte de son style dappartenance est value vrai, alors ce dernier est ligible. Soit le style est concret et auquel cas lexcution de sa comptence est dclenche, soit le style est abstrait et auquel cas une recherche dynamique de comptence est lance. Une fois de plus, la recherche dynamique de comptence repose sur un raisonnement classicatoire. La classication permet ici de dterminer le style dappartenance le plus spcique de linstance considre dans la hirarchie de spcialisation. Le raisonnement est guid par la valeur des paramtres encapsuls dans le message. De ce fait, il est frquent que les instances de styles classer soit incompltes. Pour traiter ce problme, nous nous inspirons des travaux sur la reprsentation des connaissances par objet, tel que SHIRKA [ER95], dans lequel a t propose une classication tri-value, dite incertaine. En sinspirant de cette classication, lattachement dune instance un type de style dvolution peut tre quali de : Sr si linstance vrie tous les contraintes (domaines de valeur des paramtres et prcondition) du type de style. Possible si linstance ne viole aucune des contraintes mais quil sagit dune instance incomplte. Impossible si linstance en viole au moins une. Un exemple schmatique de la classication incertaine est prsent dans la Figure 4.9. Supposons linvocation oracle.S2(), avec oracle un composant de type serveur, et S2 un style dvolution abstrait. Linstance rceptrice du message <invoke, (oracle)> est virtuellement issue du style abstrait S2 ; le mcanisme de classication permet de dterminer le ou les sousstyles de S2 auxquels cette instance peut tre attache. La valeur du paramtre c (abrviation du paramtre context pour des raisons de place) tant "oracle", les styles srs sont S5, S8 et S6, car le type de leur paramtre c accepte la valeur "oracle". Toutefois, S8 est un meilleur candidat que S5 car il est plus spcique, son type de paramtre tant Server alors que celui de S5 est Component 5 . Le style impossible est S7 car son type pour c naccepte pas "oracle". Le
5. Cette technique demande de pouvoir infrer le type exact dune instance (e.g., instanceof en Java).
85
tel-00459925, version 1 - 25 Feb 2010
Figure 4.9 Reprsentation schmatique de la classication dinstance de style volution. style possible est S9, car le paramtre c ne sut pas pour y classer cette instance. Lunion des styles dvolution srs et possibles forme lensemble E des styles ligibles. Plusieurs cas de gure se prsentent alors : card(E ) > 1 : Le DAE doit intervenir pour le choix dun style dvolution invoquer. Naturellement, les styles srs sont prsents prioritairement larchitecte. card(E ) = 1 : Le style est automatiquement invoqu. card(E ) = 0 : Lvolution sarrte et le DAE est averti. An de permettre au DAE dannuler son choix, et par ailleurs de lui permettre de slectionner un autre style, lensemble des styles dvolution ligibles est mmoris jusqu ce que lvolution entame soit valide.
4.3.3
Phase dexcution
Le dclenchement dun style revient lexcution de sa partie comptence, squentiellement, instruction par instruction. Si une instruction correspond une invocation de style, un message est envoy et une nouvelle phase de recherche est lance. Le processus se ritre pour chaque style excut. Lexcution des styles est propage par lenvoi de messages travers les liens de composition et dutilisation. La spcialisation propage galement lvolution lorsque la comptence dun sous-style contient une invocation explicite son super-style. Dans ce cas, limpact "remonte" le long de la hirarchie de spcialisation. Normalement, les paramtres eectifs fournis lors de linvocation correspondent aux paramtres formels dnis dans lentte dun style dvolution. Dans le cas o il manquerait des
86
paramtres eectifs, ces derniers sont demands au DAE. Ceci est typiquement le cas dans le cadre de la classication tri-value prsente ci-avant, o les styles possibles ncessitent des paramtres qui nont pas pu tre fournis lors de linvocation. Enn, le graphe des instances des styles dvolution mmorise leurs liens ainsi que les donnes ayant servi leur excution, jusqu la validation de lvolution par le DAE. Un tel graphe peut tre stock dans la bibliothque de niveau E0 pour une rutilisation ultrieure sur une architecture lidentique.
4.3.4
Phase de validation
tel-00459925, version 1 - 25 Feb 2010
La vrication de la cohrence se fait au vu des invariants des styles dvolution, qui ne sont autres que les contraintes structurelles poses sur les lments volutifs des styles excuts. La validation dpend du type de traitement des incohrences choisi par larchitecte, et le cas chant, la vrication peut tre eectue selon deux modes. Cette phase accepte lintervention du DAE pour des actions curatives.
4.3.4.1
Type de traitement
Le type de traitement concerne la prise en compte des invariants associs un lment volutif et peut prendre trois valeurs : strict, lche ou ignor. Le type strict (par dfaut) signie que linvariant doit tre pris en compte dans lvolution. Ce type de traitement assure la cohrence dune volution dans la mesure o llment architectural volu et plus gnralement larchitecture continue de satisfaire les choix de conception dorigine. A loppos, le type ignor fait en sorte de ne pas tenir compte des invariants. Cela revient considrer lensemble des lments architecturaux comme non contraints, et que par consquent lvolution est libre. Le type lche est un traitement intermdiaire qui signie quil est possible de violer certains invariants lors dune volution. Par consquent, llment architectural volu et plus gnralement larchitecture peut diverger des choix de conception dorigine. On peut voir ces trois types de traitement comme des niveaux de svrit dirents portant sur le diagnostic des incohrences structurelles.
4.3.4.2
Mode dvaluation
Dans le cas o le type de traitement est strict ou lche, le mode dvaluation choisi entre en jeu. Cet aspect est inspir de la spcication du MOF 6 . Ce mode peut prendre deux valeurs : immdiat ou dir. Le mode immdiat signie que linvariant doit tre vri chaque modication de la structure de llment architectural contraint et plus gnralement de larchitecture. Le mode dir signie que la vrication de linvariant pourra tre dclenche nimporte quel moment, sur action de larchitecte par exemple. Pouvoir choisir entre ces deux modes nous parat important. En eet, pour certains invariants, le mode dir savre mieux adapt. Un exemple est linvariant qui valide la connexion entre deux composants. Sa vrication ne doit tre ralise que si les deux ports sont relis par un connecteur. Si aucune incohrence nest dtecte, alors lvolution est valide et larchitecture est mise jour. Dans le cas o des incohrences sont dtectes, le DAE doit intervenir an de corriger
6. Dans cette spcication, la classe Constraint possde un attribut evalutionPolicy qui explicite le mode dvaluation de la contrainte
87
le ou les problmes. La liste des invariants viols est prsente au DAE en vue de faciliter son travail. Ce dernier peut alors naviguer dans le graphe des instances des styles dvolution et peut revenir tout tat antrieur, en annulant lexcution de certains styles. Il peut aussi faire le choix dautres styles en se basant sur la liste des styles ligibles, jusqu amener larchitecture un tat de cohrence structurelle.
4.4
Conclusion
Dans ce chapitre nous avons prsent une dmarche pour guider les architectes vers la modlisation de leurs volutions avec SAEM. Cette dmarche se base sur le modle MY introduit dans le Chapitre 3 et qui dcrit les concepts du style dvolution en utilisant trois branches : domaine, entte, comptence. En outre, ce modle possde trois niveaux de modlisation et utilise des bibliothques rutilisables pour chaque niveau. La dmarche que nous proposons est consolide par les direntes catgories dacteurs que nous avons identi, chacune impliquant un degr dintervention et des responsabilits spciques. Nous avons ensuite propos une approche pour et par la rutilisation ddie la construction des bibliothques dlments rutilisables pour chaque niveau. Laccent a t mis logiquement sur la construction de la bibliothque de niveau E1, l o sont stocks les types de styles dvolution. Notre infrastructure ore une opration dintgration pour construire des hirarchies cohrentes ainsi quune opration recherche pour y trouver les rponses des problmes dvolution architecturale. Ces oprations sont ncessaires pour que les architectes puissent bncier des connaissances acquises par leurs pairs et surtout pour tablir un systme de rutilisation ecace. Pour ne pas introduire des nouvelles notions, notre infrastructure se contente dexploiter la structure hirarchise de la bibliothque travers un raisonnement classicatoire. Lorsque quun DAE dcide dinstancier le type de style dvolution de son choix sur les lments de son architecture, un processus dvolution est dclench. La recherche dynamique de comptence intervient lorsque les liens entre les instances de styles dvolution nont pas pu tre dtermins statiquement en raison de lutilisation de styles abstraits. Elle est un mcanisme dinfrence central dans notre infrastructure qui supporte un polymorphisme de comptence. La recherche dynamique de styles est un mcanisme de parcours de graphe descendant qui repose sur llment relationnel de spcialisation dni dans la section 3.4.2 et sur les conditions dattachement dune instance un type de style dvolution. Spciquement, une instance est attache un type de style si elle en vrie la description de lentte. Pour que la recherche dynamique soit un mcanisme entirement automatique, cest--dire ne ncessitant aucune intervention manuelle de la part du DAE, les instances classer doivent tre compltes. A travers la phase de validation, notre systme savre tre un outil de simulation. En eet, tant que lvolution na pas t explicitement valide, les modications de larchitecture restent articielles. Le graphe des instances des styles dvolution ore un support de raisonnement au DAE, qui peut valuer les rpercussions dune volution sur le reste de son architecture et ainsi prendre sa dcision en connaissance de cause. Dans le dernier chapitre suivre, nous procdons aux diverses ralisations et exprimentations que nous avons mises en place dans le cadre des ides dveloppes dans cette thse.
tel-00459925, version 1 - 25 Feb 2010
tel-00459925, version 1 - 25 Feb 2010
C HAPITRE
Ralisations et exprimentations
Au cours des deux chapitres prcdents, nous avons expliqu notre modle dvolution SAEM et lapproche de rutilisation qui lui est associe. Il nous reste proposer une ralisation possible et mener une exprimentation autour de ces propositions. Ce chapitre est divis en deux parties. La premire partie examine une stratgie de projection des concepts de SAEM vers ceux de lADL COSA. COSA est un reprsentant de lcole franaise puisquil a t dvelopp par notre quipe dans le cadre dune thse de doctorat [Sme06]. La projection propose a pour objectif de traduire SAEM et de le dcrire en COSA. Comme il a t dmontr quune description COSA peut tre transforme en une description UML 2.0 [KSO06], SAEM bncie indirectement du formalisme UML 2.0 en vue de cibler des plateformes objets excutables. Dans la seconde partie de ce chapitre, nous menons une exprimentation autour de SAEM et de COSA dans le cadre dun projet industriel nomm ZOOM. Ce projet cible les questions de conception et dvolution architecturale appliques la modlisation de rseaux de tuyauterie pour la construction navale. Dune part, lADL COSA est exploit pour la description de tels rseaux sous formes darchitectures logicielles. Dautre part, SAEM a vocation permettre lentreprise de capitaliser son savoir-faire dvolution et de le r-appliquer au moment o les rseaux modliss sont amens voluer. Un consultant expert mtier a t dsign pour ce projet en vue de nous faire part de ses connaissances et de son exprience dans le domaine de la tuyauterie. En tant que chercheurs et informaticiens, notre travail a consist extraire les informations pertinentes pour les formaliser en exploitant les travaux de lquipe MoDAL. Cette seconde partie reprsente une synthse des dirents livrables de MoDAL durant le projet ZOOM. Un prototype doutil CASE a galement t dvelopp.
tel-00459925, version 1 - 25 Feb 2010
5.1
Projection de SAEM vers COSA
Dans cette section est considr lalignement de la hirarchie de modlisation associe au paradigme des architectures logicielles en COSA (A2, A1, A0) avec celle associe au paradigme des styles dvolution (E2, E1, E0). Pour ce faire, nous mettons en place une projection de SAEM vers COSA. Cette activit quivaut la transformation dun PIM (Platform Independent Model ) en PSM (Platform Specic Model ) dans le monde MDA . Le choix de COSA est motiv par les raisons suivantes : COSA est un ADL qui emprunte les mcanismes oprationnels du paradigme objet, que lon retrouve galement dans SAEM. Ce nest en ralit pas un hasard si COSA se rvle tre une structure daccueil idale pour la description des styles dvolution. 89
90
CHAPITRE 5 Ralisations et exprimentations
Des stratgies sont proposes dans [Sme06] pour permettre le passage dune spcication en COSA vers dautres ADLs tels UML 2.0. UML constitue lun des ADLs les plus utiliss dans la communaut industrielle. Ainsi, une spcication en COSA peut toujours tre transforme en une spcication en UML 2.0. De ce fait, nous pouvons bncier de la gamme doutils gravitant autour dUML ainsi que des gnrateurs de code. COSA repose explicitement sur les trois niveaux de modlisation dune architecture logicielle : le niveau mta-architecture, le niveau architecture et enn le niveau application. Ceci facilitera notre tche.
5.1.1
Prsentation de COSA
tel-00459925, version 1 - 25 Feb 2010
Dans cette section, nous prsentons COSA (Component-Object Software Architecture), un ADL hybride propos par notre quipe [Sme06, KSO05]. Il se base sur la modlisation par objets et la modlisation par composants, pour la description des systmes logiciels. COSA propose une description descendante de type "top-down". La contribution principale de cet ADL est, dune part demprunter le formalisme des ADLs et de les tendre grce aux concepts et mcanismes objets, et dautre part dexpliciter les connecteurs en tant que citoyens de premire classe pour traiter les dpendances complexes entre les composants.
5.1.1.1
Mta-modle de COSA
LADL COSA dcrit les systmes en termes de classes et dinstances. Les types dlments architecturaux sont des classes qui peuvent tre instancies pour construire plusieurs applications. Les concepts de base dune architecture COSA sont : le composant, le connecteur, la conguration, linterface, les contraintes et les proprits (fonctionnelles et non-fonctionnelles). Le mta-modle COSA est dcrit en utilisant le diagramme de classe de la notation UML. Ainsi, les concepts de COSA sont reprsents sous formes de classes, leurs caractristiques sous formes dattributs et les dirents liens entre les concepts sont reprsents par des associations. Par ailleurs, des classes abstraites qui nont pas de correspondances conceptuelles sont rajoutes uniquement comme support de factorisation, telles que les classes ArchitecturalElementType et Interface. La Figure 5.1 dcrit le mta-modle COSA o certains dtails ne sont pas reprsents par soucis de clart. Cette gure montre, en autres, que COSA spare la notion de calcul (composant) de la notion dinteraction (connecteur) et distingue deux types dinterfaces : linterface dun composant appel "port", et linterface dun connecteur appel "rle". Nous dtaillons les principaux concepts de COSA dans les sections suivantes.
5.1.1.2
La conguration dans COSA
Dans COSA, la conguration est une classe qui peut tre instancie plusieurs fois et qui donnera plusieurs architectures dun systme. Une conguration peut avoir zro ou plusieurs interfaces dnissant les ports et les services de la conguration. Les ports sont des points de connexion qui seront relis aux ports des composants internes ou aux ports des autres congurations. Les services reprsentent les services requis et les services fournis par la conguration. En gnral, les congurations sont structures de manire hirarchique : les composants et les connecteurs peuvent reprsenter des sous-congurations qui disposent de leurs propres architectures.

HIyQHQPRbRXGP 6779 aGIQaRT
91
$C'14('(%3&3CD%5
$(4('(%35 @%3(2A&B(5 y`Q $4( 6778 $C%3(2A&B(5 ) 0 6779 $%&'( $5D2B( $3&2(3
$12D1(23C(5 6779
6778 $1&2(%3 6779 !"# $%&'( $DE%(2
FGPdRabXPR FGHIGPQPRSTIQ $r(3&C4
6779 6778 FGPWXYàbRXGPSTIQ $BD%%(B3D25 UV V !"# 6779 $BD'1D%(%35 $r(3&C4 6778 cdQaFGPPQeRGa $C%rC%5 6779 $C%rC%5 6779 iXPpXPY f) UV V gRRbehQHQPR cdQ $BD%%(B3D2@%3(2A&B(5 6779 UV V 0 )
tel-00459925, version 1 - 25 Feb 2010
$BD%AC2&3CD%@%3(2A&B(5 $BD'1D%(%3@%3(2A&B(5 (%'(2&3CD% FGPPQeRXGPGpQ $5%B2D%D5 $&5%B2D%D5 $BD%3C%D5 (%'(2&3CD% QaXeQSTIQ $BD''%CB&3CD% $BD%(25CD% $BDD2rC%&3CD% $A&BC4C3&3CD%
6779 6779
UV#V 0 )
vV $'Dr(s tD%%(B3CD%uDr( wQx`XaQpGaR aGXpQpGaR
QaXeQ
FGPPQeRGaQaXeQ $31(s (2CB(1(
qV $'Dr(s tD%%(B3CD%uDr(
aGXpQpQaXeQ
wQx`XaQpQaXeQ
aGXpQpwGyQ
wQx`XaQpwGyQ
Figure 5.1 Mta-modle de COSA.
5.1.1.3
Le composant dans COSA
Un composant reprsente un lment de calcul et de stockage de donnes dun systme. Chaque composant possde une ou plusieurs interfaces. Un composant peut avoir plusieurs implmentations. Un composant peut tre composite, dans ce cas il sera dcrit par une conguration interne.
5.1.1.4
Linterface dans COSA
Dans COSA, les interfaces sont des entits abstraites de premire classe. Une interface de COSA spcie les points de connexion et les services fournis et requis pour un lment architectural (conguration, composant, connecteur). Ces derniers permettent une interface dinteragir avec son environnement, y compris avec dautres lments. Le point de connexion : appel galement port pour les composants et les congurations, et rle pour les connecteurs. Peut tre soit un port fourni/rle fourni, soit un port requis/rle requis. Le service : dcrit dune part, le comportement fonctionnel de llment architectural en expliquant ce quil fait, on parlera alors de services fournis, et dautre part, les fonctionnalits dont il a besoin pour fonctionner, il sagit alors de services requis. Un service peut utiliser un ou plusieurs points de connexion pour excuter sa tche.
92
5.1.1.5
Le connecteur dans COSA
Dans COSA, les connecteurs sont dnis comme des entits de premire classe et sont utiliss pour connecter des composants, des congurations et des interfaces. COSA distingue deux catgories de connecteurs : les connecteurs utilisateur et les connecteurs de construction. Connecteur utilisateur Un connecteur utilisateur est principalement dni par une interface et une glu. La glu dcrit les fonctionnalits attendues dun connecteur. Elle peut tre un simple protocole reliant des rles ou un protocole complexe ayant plusieurs oprations telles que la conversion de format des donnes changes, leur transfert ou leur adaptation. Les connecteurs peuvent avoir leur propre architecture interne qui contient des calculs et du stockage de donnes. Dans le cas dun connecteur composite, la conguration de ses sous-connecteurs et de ses souscomposants reprsentent la glu de ce connecteur.
tel-00459925, version 1 - 25 Feb 2010
Connecteur de construction COSA distingue trois sortes de connecteurs pour relier les interfaces des dirents lments architecturaux : attachement, binding, et utilisation. Attachement : une conguration en COSA est dnie en numrant un ensemble dattachements qui lient les ports des composants ou dune conguration aux rles dun connecteur. Un port requis peut tre reli un rle fourni et un port fourni peut tre reli un rle requis. Binding : quand un composant ou un connecteur et a fortiori une conguration disposent dune description interne, une correspondance entre leurs descriptions externes et internes doit tre mise en place. Le binding dnit cette correspondance. Un binding fournit donc une association entre les ports (respectivement rles) internes et les ports (respectivement rles) externes des composants, des congurations et des connecteurs. Utilisation : le lien dutilisation relie des services aux ports des composants ou aux rles des connecteurs. Par exemple, un port fourni dun composant est associ un service fourni de ce composant et un port requis est associ un service requis.
5.1.2
Les rgles de passage des concepts de SAEM vers COSA
Nous suggrons de modliser un type de style dvolution suivant le patron de la Figure 5.2. Le patron considre deux points de vues. Le point de vue externe tout dabord, qui considre un type de style dvolution comme un type de composant fournissant un service dvolution. Le point de vue interne ensuite, qui ore un niveau de dtail plus pouss sur les lments constitutifs dun type de style dvolution. Ces lments constitutifs, nous les avons introduit avec la modlisation en Y dans le Chapitre 3. Pour rappel, il sagit dun type de domaine, dun type dentte et dun type de comptence. La relation qui unit la vue externe et la vue interne dun type de style dvolution trouve son quivalent entre un type de composant (composite) et son type de conguration interne dans COSA. An de pouvoir mettre en place ces correspondances entre SAEM et COSA, nous avons eu recours laugmentation du mta-modle COSA.
5.1.2.1
Augmentation du mta-modle COSA
COSA est un ADL "gnraliste" qui peut tre adapt SAEM travers la cration dune extension. Cette stratgie consiste ajouter de nouveaux lments de modlisations (de nouveaux

defg heij
93
o k dj nejmgj pqqo rstuvwx
pqqo k dj lgejmgj yzt {|
Figure 5.2 Patron pour la modlisation dun style dvolution. concepts) en modiant directement le mta-modle COSA. Ceci donne un nouveau langage de modlisation supportant dune faon native les concepts de SAEM. La technique consiste spcialiser les concepts de COSA pour introduire ceux exigs par SAEM et spcier formellement de nouvelles contraintes en OCL. Laugmentation du mtamodle COSA est illustre en partie par la Figure 5.3, o les concepts originels de COSA sont reprsents en griss.

tel-00459925, version 1 - 25 Feb 2010
}~~
}~~
~~ ~
~
}~ }}
Figure 5.3 Augmentation du mta-modle COSA pour introduire la smantique de SAEM. On observe principalement quun type de style dvolution est dcrit laide dun type de composant COSA. Ce dernier est composite, car il possde sa propre conguration constitue de trois types de composants particuliers correspondants aux trois branches de MY. La bibliothque de niveau E1 est quant elle dcrite laide dun type de conguration. Dans COSA, lutilisateur peut dnir ses propres types de connecteurs. Ce point fort de lADL est exploit pour dcrire les direntes dpendances entre les lments, aussi bien au niveau de la vue externe que de la vue interne. Les rgles de passage les plus importantes entre les concepts de COSA et ceux de SAEM sont dtailles dans les sections suivantes.
5.1.2.2
Le style dvolution (vue externe)
Le concept de style dvolution, dans sa vue externe, correspond au concept de type de composant. Celui-ci peut tre connect dautres styles par lintermdiaire de connecteurs de spcialisation, de composition et dutilisation. [1] Le concept de style dvolution possde les types de ports requis SourceSpecialization, Sour-
94
ceComposition et SourceUtilization, et les types de ports fournis TargetSpecialization, TargetComposition et TargetUtilization context COSA::SAEMextension::EvolutionStyle inv : self.requiredPorts->forall(oclIsKindOf("SourceSpecialization") or oclIsKindOf("SourceComposition") or oclIsKindOf("SourceUtilization")) and self.providedPorts->forall(oclIsKindOf("TargetSpecialization") or oclIsKindOf("TargetComposition") or oclIsKindOf("TargetUtilization")) [2] SEAM nautorise que lhritage simple. Ceci se fait en contrlant quil nexiste au plus quun seul port requis de type SourceSpecialization context COSA::SAEMextension::EvolutionStyle inv : self.requiredPorts->select(oclIsKindOf("SourceSpecialization"))->size()<=1
tel-00459925, version 1 - 25 Feb 2010
[3] Un style dvolution possde une vue interne dcrite par un MY context COSA::SAEMextension::EvolutionStyle inv : self.detail->oclIsKindOf("MY");
5.1.2.3
Le style dvolution (vue interne)
La vue interne dun style dvolution est dcrite par un MY, qui correspond au concept de type de conguration de COSA. MY est un graphe form de trois types de composant et de relations inter ou intra. [1] Un MY ne contient au plus quun domaine, quun entte et quune comptence, ainsi que des relations inter et intra. context COSA::SAEMextension::MY inv : self.components->forall(oclIsKindOf("Domain") or oclIsKindOf("Header") or oclIsKindOf("Competence")) and self.connectors->forall(oclIsKindOf("Inter") or oclIsKindOf("Intra")) and self.components->select(oclIsKindOf("Domain"))<=1 and self.components->select(oclIsKindOf("Header"))<=1 and self.components->select(oclIsKindOf("Competence"))<=1
5.1.2.4
Spcialisation
Le concept de relation de spcialisation correspond au concept de connecteur utilisateur dans COSA. Une relation de spcialisation sert relier deux styles dvolution. [1] Specialization hrite de UserConnector. Specialization possde strictement deux rles en mode synchrone, dont lun requis et lautre fourni. context COSA::SAEMextension::Specialization inv : self.roles->size()=2 and self.requiredRole->exists(oclIsKindOf("to")) and self.providedRole->exists(oclIsKindOf("from")) and self.roles->forall(r | r.owner->oclIsKindOf("EvolutionStyle") and r.mode = #synchronous)
95
5.1.2.5
Composition
Le concept de relation de composition correspond au concept de connecteur utilisateur dans COSA. Une relation de composition sert relier deux styles dvolution. [1] Composition hrite de UserConnector. Composition possde strictement deux rles en mode synchrone, dont lun requis et lautre fourni. context COSA::SAEMextension::Composition inv : self.roles->size()=2 and and self.requiredRole->exists(oclIsKindOf("to")) and self.providedRole->exists(oclIsKindOf("from")) and self.roles->forall(r | r.owner->oclIsKindOf("EvolutionStyle") and r.mode = #synchronous)
5.1.2.6
Utilisation
tel-00459925, version 1 - 25 Feb 2010
Le concept de relation dutilisation correspond au concept de connecteur utilisateur dans COSA. Une relation dutilisation sert relier deux styles dvolution. [1] Utilization hrite de UserConnector. Utilization possde strictement deux rles en mode asynchrone, dont lun requis et lautre fourni. context COSA::SAEMextension::Utilization inv : self.roles->size()=2 and and self.requiredRole->exists(oclIsKindOf("to")) and self.providedRole->exists(oclIsKindOf("from")) self.roles->forall(r | r.owner->oclIsKindOf("EvolutionStyle") and r.mode = #asynchronous
5.1.2.7
La bibliothque
La bibliothque de SAEM est dnie comme un type de conguration de COSA. Elle possde un seul type de port fourni. [1] Library hrite de CongurationType. Library est un graphe de styles dvolution et de relations, et a une seule interface fournie. context COSA::SAEMextension::Library inv : self.components->forall(oclIsKindOf("EvolutionStyle") and self.connectors->forall(oclIsKindOf("Relation") and self.interfaces->size()=1 and self.requiredPort->isEmpty() [2] Library possde au moins deux styles dvolution, lun tant la racine de la hirarchie de spcialisation, lautre tant la racine de la hirarchie de composition. context COSA::SAEMextension::Library inv : self.components->select(s | s.name="Evolution")->size()=1 and self.components->select(s | s.name="NEV")->size()=1 [3] Chaque style dvolution possde un nom unique dans la bibliothque context COSA::SAEMextension::Library inv : self.components->forall (s1, s2 | s1.name=s2.name implies s1=s2)
96
5.1.2.8
Exemple dillustration
Un exemple illustratif est donn par le diagramme de structure composite dUML 2.0 de la Figure 5.4, puis comment.

tel-00459925, version 1 - 25 Feb 2010
Figure 5.4 Illustration dune modlisation de styles dvolution conformment au patron. Prenons le cas du style dvolution abstrait racine Evolution, subsumant lensemble des volution ddies aux architectures base de composants. La vue interne de ce style dnote une modlisation en Y, compose du type de domaine C&C et du type dentte IEvolution. Il sagit ici dune vue abstraite du MY, car le type de comptence nest pas support. Repassons en vue externe, et intressons-nous maintenant au style dvolution Move@Port, sous-style de Evolution. Sa vue interne hrite du type de domaine C&C, et tend le type dentte hrit avec son propre type dentte IMovePort. On notera que la relation qui existe entre ces deux types denttes correspond une relation inter H/H dnie dans lextension du mta-modle COSA. Enn, la vue interne du style concret Move@Port contient le type de comptence MovePortImpl. De cette faon, une bibliothque de styles dvolution peut tre construite la manire dune architecture logicielle base de composants.
5.2
Le projet ZOOM
Le groupe STX Europe, spcialis dans la construction navale, a lanc un projet dans le cadre du programme CAP-Excellence. Ce projet a pour objectif de rpondre un besoin dintgration. Lintgration dsigne la ralisation dun systme dinformation intgr par la mise en relation (i.e., interfaage) de direntes applications existantes. Linteroprabilit, aussi bien smantique que technique, est un enjeu crucial pour STX. On peut rsumer la situation actuelle un ensemble de tches assistes par ordinateur, assures par dirents intervenants (Bureau dtude, montage, achat, atelier, etc.), utilisant direntes applications et produisant des donnes de formats dirents. Ce manque de cohrence entre les artefacts produits par les uns et les autres engendre des erreurs et ncessite une activit de synchronisation terriblement chronophage. Ds
97
lors, la problmatique se pose en terme de communication, entre les acteurs dune part, et entre les applications dautre part. Le nom donn cette ambition est la "CAO intgre" ou "CAO unie". Parmi les sous-projets que compte la CAO unie, on trouve le projet ZOOM, sur lequel lquipe MoDAL est intervenue. Ce projet se focalise sur la modlisation de systmes navals complexes.
5.2.1
Primtre de notre intervention
Le projet ZOOM se propose dexplorer les moyens oerts pour modliser les systmes navals complexes. Lintervention de MoDAL se positionne sur deux points cls : lorganisation de la modlisation de ces systmes selon plusieurs dimensions et la capitalisation du savoir-faire de lentreprise pour faire face au dpart des "sachants".
tel-00459925, version 1 - 25 Feb 2010
5.2.1.1
Des modles plusieurs vues et niveaux
A nouveau, nous exploitons le formalisme du modle en Y. Cette fois-ci, il ne sagit pas de dcrire les concepts des styles dvolution, mais ceux des architectures logicielles base de composants [SOK08]. Spciquement, nous appliquons MY pour la modlisation des rseaux. Selon ce formalisme, larchitecture logicielle dun systme complexe peut tre dcrite par trois aspects (correspondant aux trois branches du Y) : conguration, composant et connecteur. MY supporte les trois niveaux de modlisation dune architecture logicielle, savoir le niveau mtaarchitecture, le niveau architecture et enn le niveau application. La Figure 5.5 reprsente les rseaux dun systme naval travers ses trois niveaux de modlisation, plusieurs de ses vues et selon un mme niveau dabstraction (diamtre du cercle). Le cas dun systme naval ou navire est emblmatique de la ncessit de disposer de plusieurs vues complmentaires an de dcrire le systme dans son ensemble. Par exemple, les vues tuyauterie, gaine et lectricit sont ncessaires la description de lamnagement des rseaux sur un navire. Elles correspondent basiquement aux dirents corps de mtier qui interviennent bord. A ce propos, Desmond DSouza [DSo01] parle de dimension horizontale dun modle. Dautre part, il est important de faire varier le degr de nesse des informations reprsenter travers le niveau dabstraction. On peut voir les dirents niveaux dabstraction comme des ltres destins ne retenir que les informations pertinentes pour un usage donn, relguant ainsi les autres informations des niveaux infrieurs. Il est important de rappeler que la dcomposition hirarchique oerte par les architectures logicielles, permettant de masquer les dtails internes des composants notamment, est une technique dabstraction phare. A ce propos, Desmond DSouza [DSo01] parle de dimension verticale dun modle.
5.2.1.2
Capitalisation du savoir-faire
Dans le contexte de modlisation de systmes navals, il est fait tat dun besoin crucial de capitaliser lexpertise des personnes pour faire face leur dpart de lentreprise. Cest ce niveau que MoDAL suggre lemploi des styles dvolution. Nous distinguons trois grandes catgories de styles : (a) les styles gnralistes, (b) les styles mtier et (c) les styles orients projet. Ces trois catgories dtermine chacune une porte de rutilisation des volutions (cf. section 2.2.3.3).
98
tel-00459925, version 1 - 25 Feb 2010
Figure 5.5 Mta-modlisation en Y dans le cadre du projet ZOOM.
Figure 5.6 Taxinomie de styles dvolution dans ZOOM.
99
Styles gnralistes : ce sont des styles applicables pour tous les rseaux dcris base de composants et de connecteurs. Ce sont des styles fondamentaux dont le nombre est rduit et constant. Styles mtiers : ce sont des styles applicables pour une famille de rseaux. En eet, pour chaque famille (rseau lectrique, rseau de tuyauterie, rseau de gaines, etc.), on peut identier un certain nombre de convenances. Ces styles capturent le savoir-faire des "sachants" dans lentreprise et leur nombre peut tre trs important. Styles orient projet : ce sont des styles spciques un projet donn. Le nombre de ces styles nest pas forcment important et rpondent des situations ponctuelles ou exceptionnelles, cest--dire non anticipes. Grce la connaissance du consultant expert mtier, nous avons dtaill la taxinomie initiale, en dcomposant le mtier en une sous-taxinomie. Ainsi, il est possible didentier une hirarchie plus dtaille de styles mtier. Au plus haut niveau hirarchique, nous trouvons les styles mcaniques. Ce sont des styles que lon peut qualier de "bon sens" pour faire voluer un rseau de tuyauterie. Le recensement de ces styles tacites peut savrer dicile car ils sont enfouis dans la connaissance collective. Au niveau infrieur, nous trouvons les styles imposes par trois acteurs distincts : (a) les organismes de normalisation (appels classes), (b) les clients (i.e., les commanditaires) et (c) les chantiers navals. Ces trois acteurs uvrent dans la mme direction mais selon leur proccupation respective : (a) la scurit ; (b) la facilit de maintenance ou/et la cohrence par rapport la otte existante ; (c) loptimisation des cots et les ressources (humaines et matrielles) disponibles. Ainsi, chaque organisme de normalisation, chaque client et chaque chantier peut imposer son ensemble de styles dvolution.
tel-00459925, version 1 - 25 Feb 2010
5.2.2
Analyse des besoins
La phase danalyse des besoins vise valuer les attentes du projet ZOOM et leur adquation avec les travaux de lquipe MoDAL. Notre cas dtude concerne exclusivement la vue tuyauterie ( TU dans le jargon) des systmes navals complexes. Dans ce cadre, nous sommes amens changer frquemment avec un consultant expert mtier. Nous identions des besoins en terme de conception et dvolution darchitectures censes reter des rseaux de tuyauterie.
5.2.2.1
Besoins relatifs la conception darchitectures TU
Le point de dpart a t dapprcier dans quelle mesure les architectures base de composants peuvent rellement supporter la description de rseaux de tuyauterie. Dans ce contexte, il est ncessaire didentier le mapping "one-to-one" entre les lments architecturaux et les lments physiques dans les navires (voir Figure 5.7). Le domaine de la tuyauterie consiste assembler des pices manufactures de dirents types (tubes, coudes, vannes, etc.) pour lcoulement de liquides (eau potable, eaux uses, eau de mer, etc.). En modlisation darchitecture, la frontire est parfois mince entre la responsabilit dun composant et celle dun connecteur. En rgle gnral, le curseur de sparation sappuie respectivement sur la distinction entre une abstraction de calcul et une abstraction de communication. A premire vue, il semble raisonnable de modliser les tubes par des connecteurs, de par leur rle de mdiums (ici de liquide). Or, dans un contexte non-logiciel comme cest le cas ici, cette frontire est fragile et il sest avr plus cohrent de modliser les tubes comme des composants,
100
tel-00459925, version 1 - 25 Feb 2010
Figure 5.7 Reprsentation schmatique dune modlisation de tuyauterie sous forme dune architecture logicielle. connects entre eux par des lments techniques de direntes natures (soudure, collage, etc.). Un assemblage de pices manufactures via des lments techniques forme un tuyau, intgrable dans un rseau plus global. Par ailleurs, il est intressant de remarquer travers la Figure 5.7 que chacun des lments de modlisation (composant, connecteur, conguration) prsente un intrt tre porteur de proprits et donc tre ri.
5.2.2.2
Besoins relatifs lvolution darchitectures TU
Il a t fait tat par STX du besoin de faire voluer ses rseaux de tuyauterie de faon incrmentale. Ces volutions consistent principalement complter les rseaux par certains lments et procder au remplacement de certaines pices. Daprs lexpert, une action rcurrente dun oprateur CAO consiste trononner les tubes de son rseau (cf. gure 5.8). Notamment, un tube doit tre trononn lorsquil se situe cheval sur deux blocs dans le navire. Dans ce cas, le tube dun seul tenant doit tre clat en deux tubes, dont la soudure devra tre ralise bord du navire par un soudeur et non pas de manire pralable en atelier. Cette indication est porte par une proprit du type de connecteur soudure (voir proprit du connecteur de la Figure 5.7) pouvant tre Fabrication (i.e. soudure ralise en atelier) ou Montage (i.e. soudure ralise bord). Lopration de trononnage est une volution qui est actuellement ralise manuellement par loprateur CAO. Seulement, tous les oprateurs ne respectent pas la mme faon de procder et/ou des erreurs peuvent tre introduites. Bien souvent, ces erreurs ne seront dtectes que plus tard, engendrant invitablement des cots pour les corriger. A ce titre, il est impratif de rutiliser des solutions prouves pour ce genre dopration dvolution.
101
tel-00459925, version 1 - 25 Feb 2010
Figure 5.8 Besoins dvolutions dune modlisation de tuyauterie sous forme dune architecture logicielle. A travers cette analyse des besoins, nous orientons nos propositions vers COSA pour les aspects lis la conception et vers SAEM pour les aspects lis lvolution. Dans la section suivante, nous dcrivons le travail ralis dans le cadre du projet ZOOM sous forme dune exprimentation de COSA et de SAEM pour la modlisation de rseaux de tuyauterie.
5.3
Travail ralis au cours du projet ZOOM
Le d du projet ZOOM rside dans la dicult extraire les informations pertinentes suite aux discussions avec le consultant expert mtier. Dune part, un gros travail de spcication avec COSA est ncessaire avant de pouvoir aborder le problme de lvolution avec SAEM. Dautre part, les savoir et savoir-faire dvolution sont la fois diciles identier et diciles formaliser. Dans le mme temps, nous devons tre constamment force de proposition. Le travail ralis inclut en parallle le dveloppement dun prototype baptis COSAStudio et dont les principales caractristiques et fonctionnalits sont donnes en Annexe C.
5.3.1
Conception architecturale avec COSA
Cette section expose le travail qui a t ralis concernant la modlisation des rseaux de tuyauteries laide de lADL COSA. Le travail eectu au niveau A1 consiste dnir tous les types dlments architecturaux qui forment le vocabulaire mtier du domaine de la tuyauterie ainsi que les possibilits de les assembler. Cet eort peut tre apprhend comme la dnition dun style architectural pour les systmes de type TU. Le travail eectu au niveau A0 consiste instancier les types dlments architecturaux pour dcrire des rseaux de tuyauterie reprsentant le systme construire.
102
5.3.1.1
Niveau A1
Un style composant-connecteur (C&C) gnraliste a t implment au sein du projet. En effet, nous partageons un point de vue qui consiste considrer le paradigme composant-connecteur comme un style architectural [VCAO06]. Ce dernier indique que les lments de larchitecture sont soit des composants, soit des connecteurs, ce qui fournit de fait un vocabulaire spcique qui remplace la notion assez gnrique dlment architectural. Ainsi, le style architectural C&C ore le vocabulaire de conception et les contraintes structurelles fondamentales pour la construction dune architecture logicielle base de composants. Les styles architecturaux "classiques" sont ensuite dnis en extension du style C&C via la relation de spcialisation de COSA. Dans le contexte des systmes navals, on peut trouver les styles Tuyauterie (TU), Electricit, Gaine, etc. Chacun fournit un vocabulaire ddi de conception et des contraintes structurelles spciques.
$%UV%W@ @"
AA BCDEFGHIPEBC QRSTT $% 9#" @%
tel-00459925, version 1 - 25 Feb 2010
AA BXRBCSCP QRSTT
AA BCCSYPBH QRSTT $%
0c0
10'0
`2
((

`2a2b
0d
!" #
a2b
e

&
7'02
78 24
$%"&
)506('(
)5014(
)501((78
'(
')(
0'14(
0'123
Figure 5.9 Hirarchie de types dlments architecturaux en COSA. En interaction avec le consultant expert TU, nous avons recens et hirarchis plusieurs types dlments architecturaux, que nous prsentons sous forme dun diagramme de classe UML travers la Figure 5.9. La spcialisation a t principalement utilise pour classer les dirents types de pices manufactures et pour les distinguer par leur arit (unaire, binaire ou ternaire). Cette arit dpend la fois du nombre de types dinterface dirents qui ont t dnis et du nombre dinstance maximale autorise pour chaque type dinterface. Sans surprise, une large majorit des pices sont binaires et par consquent leurs lments de raccord galement. Les tubes par exemple, sont fondamentalement des pices binaires (i.e., une interface dentre et une interface de sortie), mais nous leur avons prvus des interfaces optionnelles pour y ajouter des piquages. Les piquages sont des tubes particuliers destins tre connects de manire transverse aux tubes aprs les avoir percs. Lintrt de disposer dinterfaces explicites est vident ici et sert guider le travail de loprateur CAO. Le type de connecteur jonction manchon est un exemple
103
de composite : il possde son propre type de conguration constitu dun type de composant manchon et de deux types de connecteurs jonctions. En plus des types dlments architecturaux spcis en COSA, nous leur associons un ensemble de contraintes structurelles. Dans COSA, les contraintes sont considres comme des proprits particulires et peuvent ainsi tre portes par tout type dlment architectural. A titre dexemple, la table 5.1 rpertorie certaines des contraintes dnies sur les lments de conception du style architectural C&C. La table 5.2 liste quelques-une des contraintes mtiers que nous avons associ aux lments de conception du style architectural TU.
lment Architectural Nom contrainte
fghh ipq irs fghh ipq g st uvwxwqy
Description
g t swwi vu uvwxwq xi p hh ipq irs us p wq ipq rs ur pux r wv g xih q ur g wh xir g wh q xi p ghh i wgh uvwxi
fg
g uh q iq fghh ipq irs
us xt uvwxwqy
g g g gh q g t swwi r i vi p uh q iq vi p hh ipq irs vi h h gs i xwh q is upi p g i pivu u q pww us virs pus xwh uvwq ur h w iur xi virs qy i
tel-00459925, version 1 - 25 Feb 2010
fg g h wrs uq w h
sp
sr pqrs it uvwxwqy
q is wh i w vu xips w q w gh pgh q wih q ui xv ih q grs qs i vu s is ih q uq w wh q is upi gh g g xrh y q i de f g p uh q uy uh q ef g
i g rsh wi iq p h
fg
g uh q iq fghh ipq irs
wh uqr sijh q is upi
g g g g t swwi r i vi p uh q iq vi p hh ipq irs uy uh q xi r g g g g g us p wq ipq rs i h q p ss ipq i ih q p hh ipq ur p uh q iq p ghh ipq irs wh q ish i
p g g wq i
k u wh t uvwxwqy
qq up i ih q
jh q is upi ws ipq wgh t uvwxwqy
t swwi r i vi xws ipq w p g
gh g g xi wh q isupi p hh ipq h q
g uq w vi dwh q is upi s ir wi i p hh ipq ih q rh wr i ih q ur i g rsh wi iq p h
wh q is upi fgh g wrs uq w h l vg uq wh m vi ih q t uvwxwqy fgh g wrs uq w h r vwpuq it uvwxwqy
q ipq i vi p g g uh q iq vi p ghh ipq irs r w h i gh q u p ghh ipq ur siq i xi vus p wq ipqrs i q ipq i vi v ihq u ip xi wxih q wwuh q xr vwr
Table 5.1 Exemples de contraintes structurelles dnies dans C&C.

lment Architectural Nom contrainte
n opq rst n opq rstu rvowoxy
Description
u z{o|ot pq t vt wor} ~x{ t wq opq rs t tx o |z{ otq{ rq wor} ~x{ t wq xq t tv q {r {x wrq vq
q t
n opq rst t{ trw
zxtx t o q xq t ~wt vq wt opq rst q r x q o{ t r { q x tt
x o q wq{ t
x o u rvowoxy q wq{ tu rvowoxy
u z{o|ot pq t vt o~t o w{ t x vt } } t wor} ~x{ t } o rv u z{o|ot o vr q wq{ t tx |rox t wr vr } } t } rx o~{ t wr {x pq t vt o~t r||z{ t x t
Table 5.2 Exemples de contraintes structurelles dnies dans TU.
5.3.1.2
Niveau A0
Le niveau application contient linformation "utile" la construction des rseaux de tuyauterie du navire. Pour en donner une ide, nous choisissons un exemple didactique reprsent par le schma dans la partie gauche de la Figure 5.10. On y voit un ensemble de tubes (tub1, tub2
104
et tub3) joints laide dun coude simple c1 et dun T t1. Cet assemblage forme le tuyau TU20, qui possde trois points de jonctions possibles avec le reste du rseau de tuyauterie global.
tel-00459925, version 1 - 25 Feb 2010
Figure 5.10 Reprsentation schmatique ( gauche) et reprsentation COSA ( droite) dune portion de rseau de tuyauterie. Ce mme schma peut tre traduit en une application COSA, reprsente dans la partie droite de la Figure 5.10. La notation graphique utilise pour dcrire les lments de lapplication est celle de notre outil COSAStudio. Cette notation repose sur une direnciation visuelle du composant et du connecteur et sur la reprsentation de linterface dans le style lollipop , popularis par Microsoft mais galement familier des utilisateurs dUML. Les attachements sont reprsents par des traits pleins tandis que les bindings sont reprsents par des traits pointills.
5.3.2
volution architecturale avec SAEM
Cette section expose le travail qui a t ralis concernant lvolution des rseaux de tuyauteries, en couplant SAEM COSA. Seule lvolution du niveau application A0 dune architecture logicielle prsente un intrt immdiat pour STX. Pour cette exprimentation, nous proposons un scnario faisant intervenir larchitecte dapplications volutives (AAE) et le dveloppeur dapplications volutives (DAE).
5.3.2.1
Niveau E1
Nous rappelons que pour pouvoir grer lvolution dune architecture au niveau application A0, lAAE doit spcier les styles dvolution associs chaque lment architectural dni au niveau A1 et qui a servi la description de lapplication. Ces styles dcrits ainsi au niveau architecture seront appliqus lvolution de tout lment dune application cre partir de ce niveau. Le fait davoir spar la dnition du style C&C et du style TU permet dy associer des styles dvolution ayant une porte dirente. Les premiers capturent des volutions gnralistes, cest--dire rutilisables dans nimporte quelle architecture. Les seconds capturent des volutions mtiers, cest--dire rutilisables uniquement pour une familles de systmes, en loccurrence de
105
tel-00459925, version 1 - 25 Feb 2010
tuyauterie. En outre, les styles dvolution mtiers peuvent spcialiser les styles dvolution gnralistes. Sur le mme principe, des styles orients projet peuvent tre obtenus par spcialisation des styles mtiers. Cette technique permet de crer une taxinomie de styles dvolution, trs proche de celle propose en Section 5.2.1.2. Conformment lapproche de rutilisation que nous avons dvelopp au chapitre prcdent, lAAE a la charge didentier les volutions candidates la rutilisation. Clairement, le trononnage dun tube en est une. La Figure 5.11 se concentre sur une partie du contenu de la bibliothque de niveau E1. On remarque que le DAE a intgr la bibliothque le type de style dvolution Tronconner@Tube en tant que sous style de Split@Component. En eet, le trononnage dun tube est bien une sorte de partitionnement de composant. Lentte du super-style est surcharg et sa comptence est rednie an de prendre en compte les spcicits du mtier de la TU. Ainsi, le trononnage dun tube doit produire deux tubes dont les longueurs, une fois additionnes, reprsentent la longueur du tube trononn. De plus, une soudure doit tre ncessairement ajoute. Cette dernire doit tre ralise dans la mme matire dapport que les tubes quelle connecte. La prcondition de Tronconner@Tube sassure que le tube trononner ne contient pas de piquages et que la longueur de coupe dsire est suprieure au tiers de la longueur du tube. La postcondition exige que le tube dorigine nappartienne plus, temporairement ou dnitivement, larchitecture. Cette dcision est lapprciation de larchitecte et nest donc pas prescrite par le style dvolution. Les relations de composition informent sur ce qui est jug comme lessence dun trononnage par lexpert, savoir lajout de tubes (deux, prcisment) au tuyau ainsi que lajout de soudures (une seule, prcisment) exclusivement. Ces stratgies dajout sont leur tour perues comme la composition de la cration de llment (allocation) et de son inclusion dans la structure daccueil. Les connexions et dconnexions des ports des tubes vont dpendre de la topologie des lments en prsence. A ce titre, les relations dutilisation inter-styles sont prfres. Remarquons galement lintroduction de styles abstraits Weld@TubePort et Unweld@TubePort comme lments de factorisation. Leur intrt est illustr dans la section suivante.
5.3.2.2
Niveau E0
Le DAE va consulter la bibliothque de niveau E1 pour y rcuprer un ou plusieurs styles dvolution susceptibles de rpondre son besoin. On suppose quil cherche avec un objectif de partitionnement (Splitting ) sur un lment de son architecture. Cest l tout lintrt de disposer dune classication prliminaire des volutions selon leurs stratgies (ajout, retrait, fusion, partitionnement, etc.) dans la hirarchie de spcialisation. Ces styles abstraits sont autant de racines de substitution la racine unique Evolution, qui permettent de guider ecacement la recherche. Dans lexemple, cela permet lAAE de rechercher des comptences uniquement dans la famille des volutions relatives au partitionnement plutt que dans toutes les volutions possibles. On suppose dans notre scnario que sa recherche abouti. Le DAE slectionne llment architectural faire voluer et le style instancier sur ce dernier. Il slectionne dans notre cas le tube t2 et instancie le style concret Trononner@Tube. Dans notre scnario, t2 ne possde aucun piquage et la longueur de coupe renseigne par larchitecte vaut 23,546. Les prconditions sont respectes et le style est ligible. Par consquent, sa comptence est xcute. La gure 5.12 illustre un extrait des instances de styles dvolution cres et leur liens. Le diagramme de communication 1 dUML 2.0 est utilise pour privilgier laspect spatial
1. Appel diagramme de collaboration en UML 1.0
106
tel-00459925, version 1 - 25 Feb 2010
Figure 5.11 La bibliothque de niveau E1 (Vue externe des styles dvolution).
107

!

"# $% &'()
3004#
&#0!
&'(
" $% 1#($2
5
tel-00459925, version 1 - 25 Feb 2010
0#% 6 '' #0 7
(04#
&'( 7
Figure 5.12 La bibliothque de niveau E0 (extrait). des lments du niveau E0 sur laspect temporel. La numrotation des invocations ports par les liens smantiques donne une ide du ot des donnes spci par la comptence du style. Dans lexemple, la comptence cherche dabord isoler le tube tub2 trononner en dconnectant ses deux ports tub2-in et tub2-out du reste de larchitecture. Dans le cas de tub2-in, il sagit de supprimer un attachement, tandis que dans le cas de tub2-out, il sagit de supprimer un binding. Pour ne pas prsupposer de la nature des lments supprimer, la spcication de Trononner@Tube utilise le style abstrait Unweld@TubePort, laissant au mcanisme de recherche dynamique (cf. section 4.3.2) le soin de dterminer la bonne comptence excuter. Puis, la troisime tape de la comptence cherche ajouter les deux nouveaux tubes tub2#a et tub2#b issus du trononnage du tube dorigine. Lexcution des comptences en cascade continue ainsi jusqu amener le processus dvolution terme. Le rsultat attendu est celui dcrit par la Figure 5.13. En faisant le choix dun type de traitement strict des invariants et dun mode dvaluation dir, aucune erreur ne devrait tre diagnostique vis--vis des contraintes structurelles rpertories dans les tables 5.1 et 5.2
5.4
Conclusion
Le lecteur peut stonner de trouver une chane de ranement SAEM COSA UML la place dune projection directe de SAEM UML 2.0 par lintermdiaire dun prol par exemple. Ce choix sexplique par le fait que nous ne considrons pas UML comme un vrai ADL, tandis que les ingrdients dont nous avons besoin pour dcrire les styles dvolution se trouvent dans lADL COSA. En eet, les concepts et les niveaux de modlisation de SAEM sont natifs et inhrents dans COSA. Indubitablement, lenvironnement de dveloppement UML (riche avec lensemble de ses outils) constitue le bon compromis de dveloppement tant donn que le passage de COSA a UML a dj t ralis dans notre quipe. Nanmoins, il faut envisager le recours lintervention
108
CHAPITRE 5 Conclusion et perspectives
tel-00459925, version 1 - 25 Feb 2010
Figure 5.13 Rsultat du trononnage du tube tub2. "manuelle" pour implmenter compltement les styles dvolution. En eet, le degr de gnration automatique du code atteint lheure actuelle est relativement faible. Le modle SAEM coupl COSA permet daboutir une approche pour la conception et lvolution structurelle des architectures logicielles. COSA est un ADL qui ncessite de dnir les types des lments architecturaux avant de pouvoir les dcrire en les instanciant. Aussi, ltape de spcication ralise au niveau A1 a t un pralable au travail men avec SAEM. Le cadre du projet ZOOM a fourni MoDAL un terrain dexprimentation dont la particularit lui a permis de saranchir dun contexte purement logiciel pour y trouver des correspondances tangibles avec les lments monts bord dun navire. Cela montre que larchitecture logicielle base de composants et la problmatique de son volution peuvent convenir une varit de besoins. Face la dicult extraire les connaissances relatives lvolution, moins dune dizaine de styles dvolution ont t modliss dans le cadre du projet ZOOM. En outre, ces styles encapsulent des "micro-volutions". Le problme du passage lchelle de SAEM est un d, surtout dans le cadre dun projet industriel comme cest le cas ici.
Conclusion et perspectives
Lvolution logicielle est une problmatique qui prsente une forte vitalit au sein la communaut de recherche. En tmoigne le nombre dateliers et de confrences au niveau national et international ddis ce sujet qui na fait quaugmenter ces dernires annes. Lvolution logicielle est devenue une discipline majeure du gnie logiciel, mais elle demeure complexe traiter car profondment protiforme. En eet, lvolution intervient toutes les tapes de la vie dun systme et tout niveau dabstraction et de granularit. En consquence de cela, les pistes de recherche pour aborder cette problmatique sont vastes. Face ce constat, Mens et al. [MWD 05] ont tent de lister les grands ds que doit relever la discipline de lvolution logicielle. Parmi ceux-ci, on trouve la ncessit de disposer de nouvelles abstractions pour comprendre et matriser lvolution dans les systmes complexes. Nous pensons que le travail prsent dans ce manuscrit sinscrit dans ce mouvement. Dans cette thse, nous avons circonscrit le vaste problme de lvolution logicielle au domaine prcis de lvolution structurelle dans les architectures base de composants, et bas toute notre recherche sur le postulat que la rutilisation tait possible sur ce domaine. Analysons ce qui a t fait au niveau de ces travaux.
tel-00459925, version 1 - 25 Feb 2010
Bilan
Au Chapitre 1, nous avons voqu plus de quinze ans de pratique dans le domaine des architectures logicielles et tent dclaircir certains points. Larchitecture logicielle est une discipline btie sur un principe dabstraction qui savre particulirement adapte aux systmes complexes. Le plus souvent, elle inclut une description des systmes sous formes de composants et de connecteurs gros grain, qui fournit un bon support de raisonnement. Lapproche par composants se distingue de lapproche par objets grce une modlisation plus explicite et plus riche des systmes, favorisant la rutilisation de leurs lments. Lapproche par composants est souvent perue comme une technologie "post-objet" qui ambitionne le passage de lre artisanale lre industrielle dans le domaine de lingnierie du logiciel. Ainsi, des langages spciques lapproche composant ont vus le jour, ce sont les ADLs. Nous avons prsent un vue densemble des ADLs proposs dans la littrature. Enn, nous avons considr la notion darchitecture logicielle comme concept uniant des systmes complexes, linstar de la notion de modle considre par lOMG, arguant dirents niveaux de modlisation (A3, A2, A1 et A0). Notre premire contribution est lie ltat de lart sur les modles dvolution structurelle des architectures logicielles autour des ADLs. Ainsi, nous avons propos dans le Chapitre 2 un cadre de comparaison de lvolution architecturale sous la forme dune pyramide des besoins trois niveaux : lintention du modle vis--vis des grandes classes dobjectifs pour lvolution, le pouvoir expressif du modle et enn sa qualit. Nous avons mis en vidence que tout modle dvolution ou toute problmatique dvolution peut tre positionne dans cette pyramide. Ainsi, 109
110
nous avons men une tude dtaille des travaux dans le domaine de lvolution architecturale en positionnant chaque modle dvolution rencontr dans la pyramide des besoins. Ce travail nous a permis de dgager les aspects de lvolution architecturale qui ont t largement traits, peu traits ou jamais traits. Il savre que laspect rutilisation na t que faiblement trait par les modles dvolution existants et qu ce titre, la proposition dun nouveau modle dvolution centr sur cet aspect prsente un fort intrt. Au Chapitre 3, nous avons discut de la ncessit de sparer lvolution des donnes et des traitements au sein de la description dun lment architectural. Ainsi isole, lvolution peut tre durablement capitalise et rutilise. Puis, nous avons argument la pertinence du concept de style pour remplir cet objectif. Partant de ces rexions prliminaires, nous avons introduit notre modle dvolution base de style, baptis SAEM. Lutilisation de styles pour capturer des savoir et savoir-faire pour lvolution architecturale nous semble une technique particulirement prometteuse. Elle permet la formalisation des volutions rcurrentes en fonction des buts atteindre et ncessite lexpression des relations inter-styles exprimant par exemple une dpendance dans leur utilisation. En outre, la technique de mta-modlisation en Y ore un formalisme de reprsentation simple et minimal pour le paradigme des styles dvolution. Cette proposition peut tre rapproche des travaux entrepris dans UPML [FMvH 03] (Unied Problem-solving Method description Language ) en particulier, o lobjectif reste dobtenir une application de systme base de connaissance partir de blocs rutilisables. Un des objectifs fondamentaux du gnie logiciel consiste rduire les eorts et le cots lis au dveloppement et la maintenance des systmes. Comme il est plus ecace de rependre des artefacts existants que de rinventer la roue chaque fois, le gnie logiciel a naturellement intgr ce principe sous la forme de deux motivations inter-dpendantes : le dveloppement pour et par la rutilisation. A travers le Chapitre 4, nous avons cherch rcuprer ce principe important pour lappliquer lvolution des architectures logicielles. Dans ce but, nous avons propos une dmarche pour guider larchitecte dans son processus de modlisation dvolution logicielle. Cette dmarche amliore la rutilisation des styles dvolution en supportant des bibliothques multi-abstractions et multi-vues pour les trois niveaux de modlisation du paradigme des styles dvolution (E2, E1 et E0). Une infrastructure a t btie autour des bibliothques de styles pour prendre en charge leur peuplement et leur interrogation. Le cur de ces deux fonctionnalits repose sur un raisonnement classicatoire. Nous pensons que cette infrastructure a le mrite de ne pas introduire de nouveaux concepts par dessus SAEM an de raccourcir la courbe dapprentissage de larchitecte. Le dernier chapitre a cherch poursuivre les investigations autour de SAEM ainsi qua exprimenter nos propositions. La premire partie de ce chapitre a dni la projection de SAEM vers COSA, un ADL hybride dvelopp par notre quipe. Lide de projeter les concepts de SAEM vers COSA permet denrichir ce dernier de charges smantiques propres aux styles dvolution mais aussi de proter de la traduction de COSA UML en vue de produire une implmentation. Le projet ZOOM a montr que les problmatiques de conception et dvolution architecturale existent, pour tout type de systme. Les ides dveloppes dans cette thse ont t exploites an de rpondre un besoin de capitalisation dexprience auquel fait face lentreprise STX. Reste lpineux problme du passage lchelle de SAEM. De plus amples retours dexprience nous permettront dtudier de manire concrte les limites de nos propositions. Mais ce travail nest pas clos pour autant, des approfondissements restent faire. Voyons ce quil en est.
tel-00459925, version 1 - 25 Feb 2010
111
Perspectives
Le travail de cette thse a permis la mise en place dun cadre conceptuel pour la modlisation de lvolution lchelle de larchitecture des systmes, fortement teint de rutilisation. En outre, cette thse a cherch dpasser le problme de lvolution architecturale pour le placer dans une perspective plus gnrale dingnierie des connaissances. Le travail ralis peut se prolonger vers huit perspectives de recherche, tries par chance dcroissante.
Vers un modle dvolution rexif

Lide est de rendre le SAEM rexif, cest--dire dappliquer SAEM lui mme an de le rendre volutif, adaptable et ouvert. A notre connaissance, peu de modles dvolution peuvent prtendre des qualits dauto-volution comme celles-l. Pour ce faire, il est ncessaire de considrer les concepts dnis dans le mta-modle de SAEM comme des lments volutifs.
tel-00459925, version 1 - 25 Feb 2010
Styles dordre suprieur et styles de co-volution

Premirement, la projection de SAEM vers COSA a prpar le terrain pour lmergence de styles dvolution dordre suprieur. En eet, partir du moment ou les styles sont dcrits laide dlments dun ADL, ils peuvent voluer travers des styles dvolution, au mme titre que nimporte quelle autre architecture. Ces styles dvolution appliqus eux-mmes sont appels styles dvolution dordre suprieur. A titre dexemple, lopration dintgration propose par linfrastructure de rutilisation pourrait tre spcie comme un style dordre suprieur. Deuximement, il est important de rappeler que les styles dvolution, quils ciblent le niveau architecture (A1) ou bien application (A0), sont stocks de manire uniforme dans la bibliothque de niveau E1. Une nouvelle gamme de styles peut tre obtenue par composition de styles ciblant dirents niveaux de modlisation, et appels styles de co-volution. Ces derniers doivent permettre de maintenir le lien de causalit entre les niveaux de modlisation dune architecture au cours de son volution, en propageant les impacts dune volution du niveau A1 vers le niveau A0, et vice-versa.
Propagation dimpacts dirige par la smantique

En ltat actuel, lAAE a la charge de spcier des styles dvolution ainsi que leurs relations smantiques pour grer la propagation des impacts. En eet, nous avons fait lhypothse que cela rentre dans le cadre de sa comptence. Pour automatiser la propagation, il est possible dintroduire dans larchitecture des proprits smantiques exprimant le degr de corrlation entre les lments architecturaux. Cette ide a t utilise par le pass pour la propagation du versionnement dans les objets [UO96]. Lide ici serait de gnraliser cette approche pour nimporte quel lment architectural et nimporte quel oprateur (ajout, suppression, fusion, etc.). De cette faon, leort de spcication de lAAE serait rduit, relguant une large partie du travail lexcution.
112
volution comportementale
Nous avons not au dbut du Chapitre 3 que lvolution tait une composante qui pouvait concerner aussi bien la structure que le comportement des lments architecturaux. Nous avons considr uniquement laspect structurel dans nos propositions. Nous considrons que lintgration de laspect comportemental dans notre travail actuel ne sera que complmentaire pour le modle dvolution que nous proposons.
Ranement et versionnement
Les problmes de ranement et de versionnement des styles dvolution nont pas t abords dans le cadre de cette thse. Nous suggrons un ranement slectif dans lequel seule la comptence dun style dvolution est rane chaque tape, pour la mme entte (prservant ainsi les "proprits" de lvolution dcrite). Cette technique ncessite dintroduire une nouvelle relation smantique de ranement. Dans le mme ordre dide, le versionnement peut tre adress par lintroduction dune relation smantique de drivation entre les styles. Ainsi, il sera possible de faire co-exister dans la bibliothque plusieurs versions et plusieurs ranements dun style dvolution.
tel-00459925, version 1 - 25 Feb 2010
Styles dvolution gnriques

Bien que la spcialisation, la composition et lutilisation permettent de rutiliser les spcications, cela ne permet pas de rsoudre tous les besoins de rutilisation. Ainsi, le SAEM pourrait intgrer un mcanisme de gnricit. La gnricit se rapporterait la capacit de paramtrer des styles. Les styles dvolution gnriques sinspirent des "templates" en C++ ou des types gnriques en Eiel par exemple. En eet, linstanciation ne fournit pas de services pour paramtrer des styles. Or, souvent, des structures communes dans la description des volutions dans les architectures sont amenes tre spcies plusieurs reprises. Les styles dvolution gnriques permettent de rutiliser une spcication en fournissant au compilateur la manire de substituer le nom des types dans lentte et la comptence. Ils constituent donc une description partielle des proprits et des relations dun ensemble de styles qui a lavantage dtre adaptable dautres ensembles de styles pris dans dautres situations.
Raisonnement par analogie

Une hypothse (bien prouve) est quil y a des problmes et des solutions dvolution qui apparaissent dans des domaines trs dirents mais qui se ressemblent. Dans la correspondance analogique, deux styles dvolution sont dclars similaires si ils sont deux instances dune mme structure gnrique. Le concept de style gnrique mentionn ci-avant tient ici naturellement le rle de cette structure. Or, il est possible dadapter lalgorithme de classication pour le faire fonctionner sur des styles gnriques. Le rsultat, cest un raisonnement par analogie, ayant notamment pour objectif de rutiliser des styles dvolution spcis initialement pour dautres domaines que pour le domaine o le problme dvolution sest pos.
113
Au del des rgles : les styles

Dans cette thse, les styles ont t utiliss dans le cadre de lvolution logicielle. Pourtant, il est possible de gnraliser ce travail toute approche de type prescriptive. Les styles orent un formalisme de type entte/comptence qui fait cho aux rgles exprimes classiquement sous la forme prmisse-conclusion. Les modes de raisonnement mis en jeu divergent : le style repose sur un raisonnement classicatoire tandis que la rgle repose sur un raisonnement dductif. Dautre part, les travaux intensifs mens sur les formalismes base de rgles ont montr leurs limites en termes dabstraction, de structuration et de rutilisation. Clairement, le style est dcrit plus haut-niveau dabstraction que la rgle, et bncie dune smantique plus riche. A ce titre, une rgle smantique peut tre perue comme un style "atrophi".
mulation
tel-00459925, version 1 - 25 Feb 2010
Un fait marquant est la convergence qui est apparue dans les derniers mois entre la thmatique de cette thse et le projet de David Garlan et son quipe sur les "Evolution Styles" [Gar08, CDPG 09]. Cependant, si lon reconsidre la base de la pyramide des besoins, lintention de leur modle dvolution base de style dire du ntre. En eet, tandis que notre modle dvolution sintresse la formulation de lvolution et ses impacts, leur proposition cherche garder trace de lvolution. Garlan et al. souhaitent modliser les trajectoires volutives dune architecture comme une squence dtapes, chacune dcrite par un oprateur dvolution. Une trajectoire volutive dbute et se termine sur des congurations connues a priori, et passe par une srie de congurations intermdiaires. Lapproche propose vise ainsi explorer et valuer objectivement les direntes trajectoires volutives dun systme.
tel-00459925, version 1 - 25 Feb 2010
Bibliographie
[AAG95] Abowd G. D., Allen R., Garlan D. : Formalizing style to understand descriptions of software architecture. ACM Trans. Softw. Eng. Methodol. 4, 4 (1995), 319364. Allen R., Douence R., Garlan D. : Specifying dynamism in software architectures. In In Proceedings of the Workshop on Foundations of ComponentBased Systems (1997), pp. 1122. Allen R. J., Douence R., Garlan D. : Specifying and analyzing dynamic software architectures. In Fundamental Approaches to Software Engineering (March 1998). Angele J., Fensel D., Landes D., Studer R. : Developing knowledgebased systems with mike. Automated Software Engg. 5, 4 (1998), 389418. Allen R. : A Formal Approach to Software Architecture. PhD thesis, Carnegie Mellon, School of Computer Science, January 1997. Issued as CMU Technical Report CMU-CS-97-144. Andersson J. : Dimensions of dynamism. In Proceedings of the Second Nordic Workshop on Software Architecture (NOSA99) (August 1999). Avgeriou P., Zdun U. : Architectural patterns revisited - a pattern language. In Proceedings of 10th European Conference on Pattern Languages of Programs (EuroPlop 2005) (Irsee, Germany, July 2005). Basson H. : An integrated model for impact analysis of software change. In International Conference on Software Quality Management (Amsterdam, Netherland, April 1998), Springer-Verlag Ed. Bradbury J. S., Cordy J. R., Dingel J., Wermelinger M. : A survey of self-management in dynamic software architecture specications. In WOSS 04 : Proceedings of the 1st ACM SIGSOFT workshop on Self-managed systems (New York, NY, USA, 2004), ACM, pp. 2833. Bass L., Clements P., Kazman R. : Software architecture in practice. Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA, 1998. Barbier F., Cauvet C., Oussalah M., Rieu D., Bennasri S., Souveyet C. : Concepts cls et techniques de rutilisation dans lingnierie des systmes dinformation. Revue Lobjet 10, 1 (2004), 1135. Barais O., Duchien L. : Transat : matriser lvolution dune architecture logicielle. LOBJET 10, 2-3 (2004), 103116. Binns P., Englehart M., Jackson M., Vestal S. : Domain-specic software architectures for guidance, navigation, and control. International Journal of Software Engineering and Knowledge Engineering 6, 2 (1996). Benjamins V. : Problem solving methods for diagnosis and their role in knowledge acquisition. 93120. 115 [ADG97]
[ADG98]
tel-00459925, version 1 - 25 Feb 2010
[AFLS98] [All97]
[And99] [AZ05]
[Bas98]
[BCDW04]
[BCK98] [BCO 04]
[BD04] [BEJV96]
[Ben95]
116
BIBLIOGRAPHIE
[BJC05] [BMR 96]
Batista T. V., Joolia A., Coulson G. : Managing dynamic reconguration in component-based systems. In EWSA (2005), pp. 117. Buschmann F., Meunier R., Rohnert H., Sommerlad P., Stal M. : Pattern-oriented software architecture : a system of patterns. John Wiley & Sons, Inc., New York, NY, USA, 1996. Budinsky F., Merks E., Steinberg D. : Eclipse Modeling Framework 2.0 (2nd Edition). Addison-Wesley Professional, 2008. Buckley J., Mens T., Zenger M., Rashid A., Kniesel G. : Towards a taxonomy of software change : Research articles. J. Softw. Maint. Evol. 17, 5 (2005), 309332. Biggerstaff T. J., Richter C. : Reusability framework, assessment, and directions. 117. Bradbury J. S. : Organizing denitions and formalisms for dynamic software architectures. Tech. Rep. 2004477, Queens University, 2004. Breuker V. d. v. : Common KADS Library for Expertise Modelling. IOS Press, Amsterdam, The Netherlands, The Netherlands, 1994. Chaki S., Diaz-Pace A., Garlan D., Garfunkel A., Ozkaya I. : Towards engineered architecture evolution. In Workshop on Modeling in Software Engineering 2009 (May 2009). Clements P., Garlan D., Little R., Nord R., Stafford J. : Documenting software architectures : views and beyond. In ICSE 03 : Proceedings of the 25th International Conference on Software Engineering (Washington, DC, USA, 2003), IEEE Computer Society, pp. 740741. Cheng S.-W., Garlan D., Schmerl B. R., Jo a. P. S., Spitnagel B., Steenkiste P. : Using architectural style as a basis for system self-repair. In WICSA 3 : Proceedings of the IFIP 17th World Computer Congress - TC2 Stream / 3rd IEEE/IFIP Conference on Software Architecture (Deventer, The Netherlands, The Netherlands, 2002), Kluwer, B.V., pp. 4559. Chaffin R. : The nature of semantic relations : a comparison of two approaches. 289334. Chapin N., Hale J. E., Kham K. M., Ramil J. F., Tan W.-G. : Types of software evolution and software maintenance. Journal of Software Maintenance 13, 1 (2001), 330. Chandrasekaran B., Johnson T. R., Smith J. W. : Task-structure analysis for knowledge modeling. Commun. ACM 35, 9 (1992), 124137. Clancey W. J. : Heuristic classication. Artif. Intell. 27, 3 (1985), 289350. Clements P. C. : A survey of architecture description languages. In IWSSD 96 : Proceedings of the 8th International Workshop on Software Specication and Design (Washington, DC, USA, 1996), IEEE Computer Society, p. 16. Cauvet C., Semmak F. : La rutilisation dans lingnierie des systmes dinformation : Etat de lart. In Gnie Objet : analyse et conception de lvolution dobjet. Herms, 1999.
[BMS08] [BMZ 05]
[BR89] [Bra04]
tel-00459925, version 1 - 25 Feb 2010
[Bre94] [CDPG 09]
[CGL 03]
[CGS 02]
[Cha88] [CHK 01]
[CJS92] [Cla85] [Cle96]
[CS99]
BIBLIOGRAPHIE
117
[DHT01]
Dashofy E. M., Hoek A. V. d., Taylor R. N. : A highly-extensible, xmlbased architecture description language. In WICSA 01 : Proceedings of the Working IEEE/IFIP Conference on Software Architecture (Washington, DC, USA, 2001), IEEE Computer Society, p. 103. Dimov A., Ilieva S. : System level modeling of component based software systems. In CompSysTech 04 : Proceedings of the 5th international conference on Computer systems and technologies (New York, NY, USA, 2004), ACM, pp. 16. DeRemer F., Kron H. : Programming-in-the large versus programming-inthe-small. In Proceedings of the international conference on Reliable software (New York, NY, USA, 1975), ACM, pp. 114121. Dincel E., Roshandel R., Medvidovic N. : ADL Independent Architectural Representation in XML. Tech. rep., University of Southern California, May 2000. DSouza D. : Model-driven architecture and integration. opportunities and challenges, March 2001. Euzenat J., Rechenmann F. : Shirka, 10 ans, cest tropes ? In LMO (1995), pp. 1334. Fensel D., Motta E., van Harmelen F., Benjamins V. R., Crubezy M., Decker S., Gaspari M., Groenboom R., Grosso W., Musen M., Plaza E., Schreiber G., Studer R., Wielinga B. : The unied problem-solving method development language upml. Knowl. Inf. Syst. 5, 1 (2003), 83131. Fowler M. : Who needs an architect ? IEEE Softw. 20, 5 (2003), 1113. Garlan D., Allen R., Ockerbloom J. : Exploiting style in architectural design environments. SIGSOFT Softw. Eng. Notes 19, 5 (1994), 175188. Garlan D., Allen R., Ockerbloom J. : Architectural mismatch or why its hard to build systems out of existing parts. In ICSE 95 : Proceedings of the 17th international conference on Software engineering (New York, NY, USA, 1995), ACM, pp. 179185. Garlan D. : What is style ? In Proceedings of the Dagstuhl Workshop on Software Architecture (Saarbruecken, Germany, February 1995). Garlan D. : Software architecture : a roadmap. In ICSE 00 : Proceedings of the Conference on The Future of Software Engineering (New York, NY, USA, 2000), ACM, pp. 91101. Garlan D. : Software architecture and object-oriented systems. In Proceedings of the IPSJ Object-Oriented Symposium 2000 (August 2000). Garlan D. : Evolution Styles : Formal foundations and tool support for software architecture evolution. Tech. Rep. CMU-CS-08-142, School of Computer Science, Carnegie Mellon University, June 2008. Gamma E., Helm R., Johnson R., Vlissides J. : Design Patterns : Elements of Reusable Object-Oriented Software. Addison Wesley, 1994.
[DI04]
[DK75]
[DRM00]
tel-00459925, version 1 - 25 Feb 2010
[DSo01] [ER95] [FMvH 03]
[Fow03] [GAO94] [GAO95]
[Gar95] [Gar00a]
[Gar00b] [Gar08]
[GHJV94]
118
BIBLIOGRAPHIE
[GMF 03]
Gennari J. H., Musen M. A., Fergerson R. W., Grosso W. E., Crubzy M., Eriksson H., Noy N. F., Tu S. W. : The evolution of protg : an environment for knowledge-based systems development. Int. J. Hum.-Comput. Stud. 58, 1 (2003), 89123. Georgiadis I., Magee J., Kramer J. : Self-organising software architectures for distributed systems. In WOSS 02 : Proceedings of the rst workshop on Selfhealing systems (New York, NY, USA, 2002), ACM, pp. 3338. Garlan D., Monroe R., Wile D. : Acme : an architecture description interchange language. In CASCON 97 : Proceedings of the 1997 conference of the Centre for Advanced Studies on Collaborative research (1997), IBM Press, p. 7. Gomaa H. : Architecture-centric evolution in software product lines. ECOOP-ACE 05 (Glasgow, UK, July 2005). In
[GMK02]
[GMW97]
[Gom05]
tel-00459925, version 1 - 25 Feb 2010
[GS93]
Garlan D., Shaw M. : An introduction to software architecture. In Advances in Software Engineering and Knowledge Engineering (Singapore, 1993), Ambriola V., Tortora G., (Eds.), World Scientic Publishing Company, pp. 139. Georgas J. C., Taylor R. N. : Towards a knowledge-based approach to architectural adaptation management. In WOSS 04 : Proceedings of the 1st ACM SIGSOFT workshop on Self-managed systems (New York, NY, USA, 2004), ACM, pp. 5963. Ivers J., Clements P., Garlan D., Nord R., Schmerl B., Silva J. R. O. : Documenting Component and Connector Views with UML 2.0. Tech. Rep. CMU/SEI-2004-TR-008, Carnegie Mellon Univ., 2004. IEEE Architecture Working Group : IEEE Std 1471-2000, Recommended practice for architectural description of software-intensive systems. Tech. rep., IEEE, 2000. Jazayeri M. : Component programming - a fresh look at software components. In Proceedings of the 5th European Software Engineering Conference (London, UK, 1995), Springer-Verlag, pp. 457478. Jazayeri M. : Species evolve, individuals age. In IWPSE 05 : Proceedings of the Eighth International Workshop on Principles of Software Evolution (Washington, DC, USA, 2005), IEEE Computer Society, pp. 312. Jansen A., Bosch J. : Evaluation of tool support for architectural evolution. In ASE 04 : Proceedings of the 19th IEEE international conference on Automated software engineering (Washington, DC, USA, 2004), IEEE Computer Society, pp. 375378. Jouault F., Bzivin J. : Km3 : A dsl for metamodel specication. In FMOODS (2006), pp. 171185. Jouault F., Kurtev I. : Transforming models with atl. In MoDELS Satellite Events (2005), pp. 128138. Kramer J., Magee J. : Dynamic conguration for distributed systems. IEEE Trans. Softw. Eng. 11, 4 (1985), 424436.
[GT04]
[ICG 04]
[IEE00]
[Jaz95]
[Jaz05]
[JB04]
[JB06] [JK05] [KM85]
BIBLIOGRAPHIE
119
[KOS06] [Kru95]
Kruchten P., Obbink H., Stafford J. : The past, present, and future for software architecture. IEEE Softw. 23, 2 (2006), 2230. Kruchten P. : Software architecture and iterative development process. In TRI-Ada 95 : Tutorial proceedings on TRI-Ada 91 (New York, NY, USA, 1995), ACM, pp. 491539. Khammaci T., Smeda A., Oussalah M. : Coexistence of Object-oriented Modeling and Architectural Description, vol. III of Handbook of Software Engineering and Knowledge Engineering. S. K. Chang Ed., World Scientic Publishing Co. Int, Singapore, 2005, ch. 5, pp. 119149. Khammaci T., Smeda A., Oussalah M. : Mapping cosa software architecture concepts into uml 2.0. In ICIS-COMSAR 06 : Proceedings of the 5th IEEE/ACIS International Conference on Computer and Information Science and 1st IEEE/ACIS International Workshop on Component-Based Software Engineering,Software Architecture and Reuse (Washington, DC, USA, 2006), IEEE Computer Society, pp. 109114. Lehman M., Belady L. (Eds.) : Program evolution : processes of software change. Academic Press Professional, Inc., San Diego, CA, USA, 1985. Leymonerie F. : ASL : un langage et des outils pour les styles architecturaux contribution la description darchitectures dynamiques. PhD thesis, Universit de Savoie, December 2004. Lientz B. P., Swanson E. B. : Software Maintenance Management. AddisonWesley Longman Publishing Co., Inc., Boston, MA, USA, 1980. Luckham D. C., Vera J. : An event-based architecture denition language. IEEE Trans. Softw. Eng. 21, 9 (1995), 717734. Menzies T. : SE/KE Reuse Research : Common Themes and Empirical Results, vol. 2. World Scientic Publishing Co., 2002, ch. Handbook of Software Engineering and Knowledge Engineering. Muller P.-A., Fleurey F., Jzquel J.-M. : Weaving executability into object-oriented meta-languages. In MoDELS (2005), pp. 264278. Mencl V., Hnetynka P. : Managing Evolution of Component Specication using a Federation of Repositories. Tech. Rep. 2001/2, Department of Software Engineering, Charles University, Prague, June 2001. Minsky M. : Matter, mind, and models. In Semantic Information Processing, Minsky M., (Ed.). MIT Press, 1968. Magee J., Kramer J. : Dynamic structure in software architectures. SIGSOFT Softw. Eng. Notes 21, 6 (1996), 314. Morrison R., Kirby G., Balasubramaniam D., Mickan K., Oquendo F., Cmpan S., Warboys B., Snowdon B., Greenwood R. M. : Support for evolving software architectures in the archware adl. In WICSA 04 : Proceedings of the Fourth Working IEEE/IFIP Conference on Software Architecture (Washington, DC, USA, 2004), IEEE Computer Society, p. 69. McVeigh A., Kramer J., Magee J. : Using resemblance to support component reuse and evolution. In SAVCBS 06 : Proceedings of the 2006 conference
[KSO05]
[KSO06]
tel-00459925, version 1 - 25 Feb 2010
[LB85] [Ley04]
[LS80] [LV95] [Men02]
[MFJ05] [MH01]
[Min68] [MK96] [MKB 04]
[MKM06]
120
BIBLIOGRAPHIE
on Specication and verication of component-based systems (New York, NY, USA, 2006), ACM, pp. 4956. [Mot00] Motta E. : The Knowledge Modeling Paradigm in Knowledge Engineering, vol. 1. World Scientic Publishing Co., 2000, ch. Handbook of Software Engineering and Knowledge Engineering. Medvidovic N., Rosenblum D. S. : Domains of concern in software architectures and architecture description languages. In DSL97 : Proceedings of the Conference on Domain-Specic Languages on Conference on DomainSpecic Languages (DSL), 1997 (Berkeley, CA, USA, 1997), USENIX Association, pp. 1616. Medvidovic N., Rosenblum D. S., Taylor R. N. : A language and environment for architecture-based software development and evolution. In ICSE 99 : Proceedings of the 21st international conference on Software engineering (Los Alamitos, CA, USA, 1999), IEEE Computer Society Press, pp. 4453. Medvidovic N., Taylor R. N. : A classication and comparison framework for software architecture description languages. IEEE Trans. Softw. Eng. 26, 1 (2000), 7093. Mens T., Wermelinger M., Ducasse S., Demeyer S., Hirschfeld R., Jazayeri M. : Challenges in software evolution. In IWPSE (2005), pp. 1322. Naur P., Randell B. (Eds.) : Software Engineering : Report of a conference sponsored by the NATO Science Committee. Garmisch, Germany, October 1968. Nitto E. D., Rosenblum D. : Exploiting adls to specify architectural styles induced by middleware infrastructures. In ICSE 99 : Proceedings of the 21st international conference on Software engineering (Los Alamitos, CA, USA, 1999), IEEE Computer Society Press, pp. 1322. Object Management Group (OMG) : Meta object facility (MOF) specication. formal/2002-04-03, April 2002. Oussalah M., Messaadia K., Khammaci T. : The meta modeling for reuse in kbs. In Future Trends in Articial Intelligence (New Delhi, 2002), Akerkar R., (Ed.), Allied Publishers. Oreizy P., Medvidovic N., Taylor R. N. : Architecture-based runtime software evolution. In ICSE 98 : Proceedings of the 20th international conference on Software engineering (Washington, DC, USA, 1998), IEEE Computer Society, pp. 177186. Oreizy P., Medvidovic N., Taylor R. N. : Runtime software adaptation : framework, approaches, and styles. In ICSE Companion 08 : Companion of the 30th international conference on Software engineering (New York, NY, USA, 2008), ACM, pp. 899910. Oreizy P., Taylor R. : On the role of software architectures in runtime system reconguration. In CDS 98 : Proceedings of the International Conference on Congurable Distributed Systems (Washington, DC, USA, 1998), IEEE Computer Society, p. 61.
[MR97]
[MRT99]
tel-00459925, version 1 - 25 Feb 2010
[MT00]
[MWD 05] [NR68] [NR99]
[Obj02] [OMK02]
[OMT98]
[OMT08]
[OT98]
BIBLIOGRAPHIE
121
[Ous99] [Par72] [PBJ98]
Oussalah M. : Gnie Objet : Analyse et Conception de lEvolution. Editions Herms, 1999. Parnas D. L. : On the criteria to be used in decomposing systems into modules. Commun. ACM 15, 12 (1972), 10531058. Plsil F., Blek D., Janecek R. : Sofa/dcup : Architecture for component trading and dynamic updating. In CDS 98 : Proceedings of the International Conference on Congurable Distributed Systems (Washington, DC, USA, 1998), IEEE Computer Society, p. 43. Prieto-Diaz R., Neighbors J. M. : Module interconnection languages. J. Syst. Softw. 6, 4 (1986), 307334. Perry D. E., Wolf A. L. : Foundations for the study of software architecture. SIGSOFT Softw. Eng. Notes 17, 4 (1992), 4052. Roshandel R., Hoek A. V. D., Mikic-Rakic M., Medvidovic N. : Mae a system model and environment for managing architectural evolution. ACM Trans. Softw. Eng. Methodol. 13, 2 (2004), 240276. Royce W. E., Royce W. : Software architecture : Integrating process and technology. TRW Quest 14, 1 (Summer 1991), 215. Shaw M., Clements P. C. : A eld guide to boxology : Preliminary classication of architectural styles for software systems. In COMPSAC 97 : Proceedings of the 21st International Computer Software and Applications Conference (Washington, DC, USA, 1997), IEEE Computer Society, pp. 613. Shaw M., Clements P. : The golden age of software architecture. IEEE Softw. 23, 2 (2006), 3139. Shaw M., Garlan D. : Formulations and formalisms in software architecture. In Computer Science Today. Springer-Verlag, 1995, pp. 307323. Shaw M., Garlan D. : Software architecture : perspectives on an emerging discipline. Prentice-Hall, Inc., Upper Saddle River, NJ, USA, 1996. Sadou-Harireche N. : Evolution Structurelle dans les Architecture Logicielles base de Composants. PhD thesis, Universit de Nantes, December 2007. Shaw M. : Larger scale systems require higher-level abstractions. In IWSSD 89 : Proceedings of the 5th international workshop on Software specication and design (New York, NY, USA, 1989), ACM, pp. 143146. Shaw M. : Comparing architectural design styles. IEEE Softw. 12, 6 (1995), 2741. Shaw M. : Some patterns for software architecture. In Pattern Languages of Program Design (1996), vol. 2, Addison-Wesley, pp. 255269. Smeda A. : Contribution llaboration dune mtamodlisation de description darchitecture logicielle. Thse de doctorat, Universit de Nantes, 2006. Shadbolt N., Motta E., Rouge A. : Constructing knowledge-based systems. IEEE Softw. 10, 6 (1993), 3438.
[PDN86] [PW92] [RHMRM04]
tel-00459925, version 1 - 25 Feb 2010
[RR91] [SC97]
[SC06] [SG95] [SG96] [SH07] [Sha89]
[Sha95] [Sha96] [Sme06] [SMR93]
122
BIBLIOGRAPHIE
[SOK05]
Smeda A., Oussalah M., Khammaci T. : Madl : Meta architecture description language. In SERA 05 : Proceedings of the Third ACIS Intl Conference on Software Engineering Research, Management and Applications (Washington, DC, USA, 2005), IEEE Computer Society, pp. 152159. Smeda A., Oussalah M. C., Khammaci T. : My architecture : a knowledge representation meta-model for software architecture. International Journal of Software Engineering and Knowledge Engineering 18, 7 (2008), 877894. Sommerville I. : Software engineering (5th ed.). Addison Wesley Longman Publishing Co., Inc., Redwood City, CA, USA, 1995. Sewell M. T., Sewell L. : The Software Architects Profession : An Introduction. Prentice Hall PTR, Upper Saddle River, NJ, USA, 2001. Steels L. : Components of expertise. AI Mag. 11, 2 (1990), 3049. Szyperski C. : Component software : beyond object-oriented programming. ACM Press/Addison-Wesley Publishing Co., New York, NY, USA, 1998. Taentzer G. : Agg : A tool environment for algebraic graph transformation. In AGTIVE 99 : Proceedings of the International Workshop on Applications of Graph Transformations with Industrial Relevance (London, UK, 2000), Springer-Verlag, pp. 481488. Taylor R. N., Medvidovic N., Anderson K. M., E. James Whitehead J., Robbins J. E. : A component- and message-based architectural style for gui software. In ICSE 95 : Proceedings of the 17th international conference on Software engineering (New York, NY, USA, 1995), ACM, pp. 295304. Tamzalit D., Oussalah M. : A Conceptualization of OO evolution. In Proceedings of the 9th International Conference of Object-Oriented Information Systems (OOIS03) (Geneva, Switzerland, 2003), vol. 2817 of Lecture Notes in Computer Science, Springer, pp. 274278. Urtado C., Oussalah C. : Propagation de versions dans les objets complexes. In INFORSID (1996), pp. 331349. Verjus H., Cmpan S., Alloui I., Oquendo F. : Gestion des architectures volutives dans archware. In CAL (2006), pp. 4157. van Ommering R., van der Linden F., Kramer J., Magee J. : The koala component model for consumer electronics software. Computer 33, 3 (2000), 7885. Wile D. : Aml : An architecture meta-language. In ASE 99 : Proceedings of the 14th IEEE international conference on Automated software engineering (Washington, DC, USA, 1999), IEEE Computer Society, p. 183. Wile D. : Using dynamic acme. In Working Conference on Complex and Dynamic Systems Architecture (Brisbane, Australia, December 2001). Wartik S., Prieto-Diaz R. : Criteria for comparing reuse-oriented domain analysis approaches. International Journal of Software Engineering and Knowledge Engineering 2, 3 (September 1992), 403432.
[SOK08]
[Som95] [SS01] [Ste90] [Szy98]
tel-00459925, version 1 - 25 Feb 2010
[Tae00]
[TMA 95]
[TO03]
[UO96] [VCAO06] [vOvdLKM00]
[Wil99]
[Wil01a] [WPD92]
Rfrences hypertextes
[www 5 ] Eclipse Epsilon Plugin. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . http://www.eclipse.org/gmt/epsilon/ [www 6 ] Eclipse Graphical Editing Framework (GEF). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . http://www.eclipse.org/gef/ [www 8 ] SEIs denitions of software architecture.
tel-00459925, version 1 - 25 Feb 2010
. . . . . . . . . . . . . . . . . . . . . . . . . . . . http://www.sei.cmu.edu/architecture/definitions.html [www 10 ] WorldWide Institue of Software Architects (WWISA). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . http://www.wwisa.org/
123
tel-00459925, version 1 - 25 Feb 2010
Liste des tableaux

1.1 2.1 2.2 2.3 2.4 Hirarchie selon une mta-modlisation par objet et par composant. . . . . . . . 18 27 42 43 44 57 66 81 Types doprations dvolution rcurrentes et leurs descriptions. . . . . . . . . . . Positionnement des modles dvolution selon la base de la pyramide des besoins. Positionnement des modles dvolution selon le second niveau de la pyramide des besoins. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Positionnement des modles dvolution selon le dernier niveau de la pyramide des besoins. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . lments relationnels et axiomes mathmatiques de rexivit (R), de transitivit (T) et de symtrie (S) associs aux trois relations smantiques. . . . . . . . . . . valuation de SAEM vis--vis de la pyramide des besoins. . . . . . . . . . . . . . Classes de rsultats bass sur un raisonnement classicatoire par spcialisation ou composition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
tel-00459925, version 1 - 25 Feb 2010
3.1 3.2 4.1 5.1 5.2
Exemples de contraintes structurelles dnies dans C&C. . . . . . . . . . . . . . . 103 Exemples de contraintes structurelles dnies dans TU. . . . . . . . . . . . . . . . 103
125
tel-00459925, version 1 - 25 Feb 2010
Table des gures

1.1 1.1 1.2 1.3 1.4 1.5 1.6 1.7 1.8 1.9 2.1 2.2 2.3 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 3.10 3.11 3.12 3.13 3.14 4.1 4.2 4.3 4.4 Reprsentation schmatique de la structure de cette thse. . . . . . . . . . . . . . Catgories darchitecture logicielle face la complexit croissante des systmes. . Inuence de la dcomposition sur la complexit dun systme. . . . . . . . . . . . tapes dun modle de dveloppement en cascade et leurs reprsentations. . . . . Modle conceptuel pour la description darchitecture logicielle (adapt de la norme 1471-2000). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Assemblage dlments architecturaux pouvant tre dcrit laide dun ADL. . . Frise chronologique des ADLs ainsi que leur origine. . . . . . . . . . . . . . . . . Activit de modlisation et de mta-modlisation dans les termes de Minsky. . . . Les quatre niveaux darchitecture que nous proposons. . . . . . . . . . . . . . . . Illustration des niveaux de modlisation de larchitecture dun systme de type client/serveur en ACME. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi 3 4 6 9 13 16 18 19 20
tel-00459925, version 1 - 25 Feb 2010
Pyramide des besoins traits par un modle dvolution. . . . . . . . . . . . . . . 26 Trois concepts pour formuler lvolution : Opration, Oprateur et lement volutif. 27 Reprsentation schmatique des traces des volutions dans une architecture. . . . 29 Les trois composantes dun lment architectural : structure, comportement et volution. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Vues, points de vue, et styles (inspir de [AZ05]) . . . . . . . . . . . . . . . . . . La structure du mta-modle noyau de SAEM. . . . . . . . . . . . . . . . . . . . Identication des lments architecturaux susceptibles dvoluer. . . . . . . . . . Nom, entte et comptence dun style dvolution. . . . . . . . . . . . . . . . . . Instances du concept Relation de SAEM : spcialisation, composition et utilisation. Les styles dvolution sont relis entre eux par la spcialisation, la composition et lutilisation. Ils sont instancis sur larchitecture dun systme. . . . . . . . . . . . Mcanisme dinstanciation de style dvolution. . . . . . . . . . . . . . . . . . . . Mcanisme de spcialisation de style dvolution. . . . . . . . . . . . . . . . . . . Mcanisme de composition de style dvolution. . . . . . . . . . . . . . . . . . . . Mcanisme dutilisation de style dvolution. . . . . . . . . . . . . . . . . . . . . . La reprsentation des concepts du style dvolution en utilisant le modle en Y. . La reprsentation de vues multiples en utilisant MY. . . . . . . . . . . . . . . . . La reprsentation de deux niveaux dabstraction pour le style Move@Port. . . . . Les bibliothques pour les styles dvolution. . . . . . . . . . . . . . . Le diagramme de squence pour les oprations sur les bibliothques. Orientation problme dun style dvolution. . . . . . . . . . . . . . . Filtrage par points de vue sur la bibliothque de niveau E1. . . . . . 127 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 50 52 53 54 56 58 58 59 60 60 62 64 65 70 72 74 75
128
TABLE DES FIGURES
4.5
4.6 4.7 4.8 4.9 5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8 5.9 5.10 5.11 5.12 5.13
Reprsentation schmatique du raisonnement classicatoire sur un style dvolution x dans une hirarchie de spcialisation (en haut) et dans une hirarchie de composition (en bas). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Schma de lopration dintgration dun style x dans une hirarchie de spcialisation (en haut) et dans une hirarchie de composition (en bas). . . . . . . . . . . Vue schmatique du fonctionnement de lopration de recherche dans la bibliothque partir dun style abstrait q . . . . . . . . . . . . . . . . . . . . . . . . . . Les quatre phases dun processus dvolution dans SAEM. . . . . . . . . . . . . . Reprsentation schmatique de la classication dinstance de style volution. . . . Mta-modle de COSA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Patron pour la modlisation dun style dvolution. . . . . . . . . . . . . . . . . . Augmentation du mta-modle COSA pour introduire la smantique de SAEM. . Illustration dune modlisation de styles dvolution conformment au patron. . . Mta-modlisation en Y dans le cadre du projet ZOOM. . . . . . . . . . . . . . . Taxinomie de styles dvolution dans ZOOM. . . . . . . . . . . . . . . . . . . . . Reprsentation schmatique dune modlisation de tuyauterie sous forme dune architecture logicielle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Besoins dvolutions dune modlisation de tuyauterie sous forme dune architecture logicielle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Hirarchie de types dlments architecturaux en COSA. . . . . . . . . . . . . . . Reprsentation schmatique ( gauche) et reprsentation COSA ( droite) dune portion de rseau de tuyauterie. . . . . . . . . . . . . . . . . . . . . . . . . . . . . La bibliothque de niveau E1 (Vue externe des styles dvolution). . . . . . . . . La bibliothque de niveau E0 (extrait). . . . . . . . . . . . . . . . . . . . . . . . . Rsultat du trononnage du tube tub2. . . . . . . . . . . . . . . . . . . . . . . . .
77 79 80 83 85 91 93 93 96 98 98 100 101 102 104 106 107 108
tel-00459925, version 1 - 25 Feb 2010
A.1 Repre tri-dimensionnel propos par Jesper Andersson. . . . . . . . . . . . . . . . 138 A.2 Repre tri-dimensionnel propos par Bradbury et al. . . . . . . . . . . . . . . . . 139 A.3 Repre tri-dimensionnel propos par Sadou et al. . . . . . . . . . . . . . . . . . . 140 C.1 C.2 C.3 C.4 Hirarchie des concepts de Ecore. . . . . . . . . . . . . . . . . . . . . . . . . . . . Modle dinterface utilisateur pour loutil COSAStudio. . . . . . . . . . . . . . . Vue densemble des dirents modles ncessaires COSAStudio. . . . . . . . . . Introduction dun niveau de modlisation M0 par une technique de transformation de modle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C.5 Perspective COSA sur un modle vierge. . . . . . . . . . . . . . . . . . . . . . . . C.6 Perspective C&C sur un modle vierge pour le mtier de la tuyauterie. . . . . . . C.7 Perspective SAEM sur un modle vierge. . . . . . . . . . . . . . . . . . . . . . . . 148 149 150 150 152 153 154
tel-00459925, version 1 - 25 Feb 2010
Table des exemples
129
tel-00459925, version 1 - 25 Feb 2010
Table des matires

Introduction 1 Architecture logicielle : tat du domaine 1.1 Les architectures logicielles . . . . . . . . . . . . . 1.1.1 mergence de larchitecture logicielle . . . . 1.1.2 Reconnaissance de larchitecture logicielle . 1.1.3 Dnitions notables . . . . . . . . . . . . . 1.1.4 Styles architecturaux . . . . . . . . . . . . . 1.1.5 Bilan . . . . . . . . . . . . . . . . . . . . . . 1.2 Langages de description darchitectures . . . . . . . 1.2.1 Concepts de base . . . . . . . . . . . . . . . 1.2.2 Concepts supplmentaires . . . . . . . . . . 1.2.3 Rtrospective des ADLs . . . . . . . . . . . 1.2.4 Bilan . . . . . . . . . . . . . . . . . . . . . . 1.3 Architecture et mta-modlisation . . . . . . . . . 1.3.1 Principes de la mta-modlisation . . . . . . 1.3.2 Mta-modlisation par composant . . . . . 1.3.3 Niveaux de modlisation dune architecture 1.3.4 Exemple illustratif . . . . . . . . . . . . . . 1.3.5 Bilan . . . . . . . . . . . . . . . . . . . . . . 1.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . 2 volution architecturale : analyse et synthse 2.1 volution architecturale . . . . . . . . . . . . . 2.1.1 Motivation . . . . . . . . . . . . . . . . 2.1.2 Pour quels usages ? . . . . . . . . . . . . 2.1.3 Avantages et ds . . . . . . . . . . . . . 2.2 Cadre de comparaison des modles dvolution 2.2.1 Pyramide des besoins . . . . . . . . . . 2.2.2 Intention dun modle dvolution . . . . 2.2.3 Expressivit dun modle dvolution . . 2.2.4 Qualit dun modle dvolution . . . . 2.3 tude des modles dvolution existants . . . . 2.3.1 Approches de lcole amricaine . . . . . 2.3.2 Approches de lcole europenne . . . . 2.3.3 Approches de lcole franaise . . . . . . 2.3.4 Bilan de ltude . . . . . . . . . . . . . . 2.4 Conclusion . . . . . . . . . . . . . . . . . . . . . 131 vii 1 1 2 4 7 10 12 13 13 15 15 17 17 17 18 19 20 21 21 23 23 24 24 25 25 26 26 29 31 32 32 35 38 41 44
tel-00459925, version 1 - 25 Feb 2010
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
132
TABLE DES MATIRES
tel-00459925, version 1 - 25 Feb 2010
3 Modle dvolution architecturale base de style 3.1 Vers le concept de style dvolution . . . . . . . . . . . . . . . . . 3.1.1 Thsaurisation, extraction et reprsentation de lvolution 3.1.2 Points de vue et styles pour lvolution darchitectures . . 3.2 SAEM : Style-based Architectural Evolution Model . . . . . . . . 3.2.1 Proprits attendues de SAEM . . . . . . . . . . . . . . . 3.2.2 Pourquoi un mta-modle ? . . . . . . . . . . . . . . . . . 3.2.3 Le mta-modle SAEM . . . . . . . . . . . . . . . . . . . 3.3 Description des concepts de SAEM . . . . . . . . . . . . . . . . . 3.3.1 lment volutif . . . . . . . . . . . . . . . . . . . . . . . 3.3.2 Style dvolution . . . . . . . . . . . . . . . . . . . . . . . 3.3.3 Contrainte . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.4 Relation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.5 Bibliothque . . . . . . . . . . . . . . . . . . . . . . . . . 3.4 Mcanique opratoire de SAEM . . . . . . . . . . . . . . . . . . . 3.4.1 Linstanciation . . . . . . . . . . . . . . . . . . . . . . . . 3.4.2 La spcialisation . . . . . . . . . . . . . . . . . . . . . . . 3.4.3 La composition . . . . . . . . . . . . . . . . . . . . . . . . 3.4.4 Lutilisation . . . . . . . . . . . . . . . . . . . . . . . . . . 3.5 Formalisme de reprsentation des styles dvolution . . . . . . . . 3.5.1 MY : La mta-modlisation en Y . . . . . . . . . . . . . . 3.5.2 Style dvolution en Y . . . . . . . . . . . . . . . . . . . . 3.5.3 Exemple dillustration . . . . . . . . . . . . . . . . . . . . 3.6 Bilan de SAEM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.6.1 lments de synthse . . . . . . . . . . . . . . . . . . . . . 3.6.2 Positionnement dans la pyramide des besoins . . . . . . . 3.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Bibliothques pour les styles dvolution 4.1 Bibliothques pour les styles dvolution . . . . . . . 4.1.1 Niveaux de modlisation des bibliothques . . 4.1.2 Acteurs relatifs aux bibliothques . . . . . . . 4.1.3 Construction des bibliothques . . . . . . . . 4.2 laboration dune bibliothque de styles dvolution 4.2.1 Classication de styles dvolution . . . . . . 4.2.2 Opration dintgration dans une bibliothque 4.2.3 Opration de recherche dans une bibliothque 4.2.4 Discussions . . . . . . . . . . . . . . . . . . . 4.3 Rutilisation travers linstanciation . . . . . . . . . 4.3.1 Phase dinvocation . . . . . . . . . . . . . . . 4.3.2 Phase de recherche . . . . . . . . . . . . . . . 4.3.3 Phase dexcution . . . . . . . . . . . . . . . 4.3.4 Phase de validation . . . . . . . . . . . . . . . 4.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . .
47 48 48 49 50 51 51 51 52 52 53 55 56 57 57 58 59 60 60 61 61 61 64 64 65 65 67 69 69 70 71 71 74 74 76 79 82 83 84 84 85 86 87
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
TABLE DES MATIRES
133
5 Ralisations et exprimentations 5.1 Projection de SAEM vers COSA . . . . . . . . . . . . . 5.1.1 Prsentation de COSA . . . . . . . . . . . . . . . 5.1.2 Les rgles de passage des concepts de SAEM vers 5.2 Le projet ZOOM . . . . . . . . . . . . . . . . . . . . . . 5.2.1 Primtre de notre intervention . . . . . . . . . . 5.2.2 Analyse des besoins . . . . . . . . . . . . . . . . 5.3 Travail ralis au cours du projet ZOOM . . . . . . . . . 5.3.1 Conception architecturale avec COSA . . . . . . 5.3.2 volution architecturale avec SAEM . . . . . . . 5.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . Conclusion et perspectives
. . . . . . . . COSA . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
89 89 90 92 96 97 99 101 101 104 107 109
tel-00459925, version 1 - 25 Feb 2010
Bibliographie Rfrences hypertextes Liste des tableaux Table des gures Table des exemples Table des matires A Rfrentiels de comparaison pour lvolution A.1 Rfrentiel dAndersson (1999) . . . . . . . . A.1.1 Initiation du changement . . . . . . . A.1.2 Type du changement . . . . . . . . . . A.1.3 Contrle du changement . . . . . . . . A.2 Rfrentiel de Bradbury et al. (2001) . . . . . A.2.1 Initiation du changement . . . . . . . A.2.2 Gestion du changement . . . . . . . . A.2.3 Support doprations . . . . . . . . . . A.3 Rfrentiel de Sadou et al. (2007) . . . . . . . A.3.1 Objet de lvolution . . . . . . . . . . A.3.2 Type dvolution . . . . . . . . . . . . A.3.3 Support de lvolution . . . . . . . . . A.4 Bilan . . . . . . . . . . . . . . . . . . . . . . . base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
115 123 125 127 129 131 137 137 137 137 138 138 139 139 139 140 140 140 141 141 143 143 143 144 144
B Algorithmes pour le raisonnement classicatoire B.1 Algorithme gnrique de classication . . . . . . . B.2 Algorithme de recherche des SPS . . . . . . . . . . B.3 Algorithme de recherche des SPG . . . . . . . . . . B.4 Remarques et amliorations . . . . . . . . . . . . .
134
TABLE DES MATIRES
B.4.1 B.4.2 B.4.3 B.4.4
Optimisation de la traverse . . . Hirarchies orthogonales . . . . . Mesure du degr de subsomption Traitement smantique . . . . . .
. . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
145 145 145 146 147 147 147 148 148 149 149 151 151 151 151 152
tel-00459925, version 1 - 25 Feb 2010
C Le prototype COSAStudio C.1 Prsentation gnrale de COSAStudio . . C.2 Eclipse Modelling Framework . . . . . . . C.3 lments caractristiques de COSAStudio C.3.1 Interface graphique utilisateur . . . C.3.2 Hirarchie de modlisation . . . . . C.3.3 Introduction du niveau A0 . . . . . C.4 Les perspectives dans COSAStudio . . . . C.4.1 La Perspective COSA . . . . . . . C.4.2 La Perspective C&C . . . . . . . . C.4.3 La Perspective SAEM . . . . . . . C.5 Amliorations futures . . . . . . . . . . . .
tel-00459925, version 1 - 25 Feb 2010
Annexes
tel-00459925, version 1 - 25 Feb 2010
A NNEXE
tel-00459925, version 1 - 25 Feb 2010
Rfrentiels de comparaison pour lvolution base architecture

On trouve dans la littrature dautres rfrentiels de comparaison ddis lvolution base architecture que celui que nous avons propos dans le Chapitre 2 de ce manuscrit. En particulier, notre attention a t retenue par les travaux dAndersson en 1999, ceux de Bradbury et al. en 2001 et enn ceux de Sadou et al. en 2007.
A.1
Rfrentiel dAndersson (1999)
Dans son papier Dimensions of Dynamism [And99], Jasper Andersson prsente son point de vue sur les architectures dynamiques en identiant un ensemble de proprits qui peuvent tre utilises pour dcrire les caractristiques dynamiques des architectures des applications. A cet eet, il exhibe trois dimensions du dynamisme : lInitiation, le Type, et le Contrle. Ces trois dimensions dnissent le repre de la gure A.1. Ces dimensions sont dtailles dans ce qui suit.
A.1.1
Initiation du changement
Un aspect important du dynamisme architectural concerne quand et comment les tches de modication sont inities. Il existe deux types dinitiation : externe et interne. Externe : linitiation externe est approprie pour les recongurations qui ont t planies, par exemple pour la ractualisation de certaines parties des applications migrant vers du nouveau matriel, etc. Interne : des vnements internes qui initient des recongurations peuvent tre lis lquilibrage de charge ou dautres exceptions dans lapplication ou bien des vnements extrieurs que lapplication dtecte, tels que des problmes de communication et des dfaillances matrielles.
A.1.2
Type du changement
Cette dimension est importante puisque cest ici que nous pouvons voir ce qui se passe dans une architecture au moment de son excution. 137
138
ANNEXE A
tel-00459925, version 1 - 25 Feb 2010
Figure A.1 Repre tri-dimensionnel propos par Jesper Andersson. Structurel : la structure dune conguration nest pas conserve lorsquune modication est applique une architecture, cest--dire que lensemble des composants, connecteurs et liaisons est aect. Mise jour : la conguration est prserve, cest--dire que lensemble des composants et des connecteurs ainsi que lensemble des liaisons ne change pas. Les recongurations de mise jour sont utilises quand de nouvelles versions ou variantes de composants sont introduites dans lapplication.
A.1.3
Contrle du changement
Cette dimension dtermine o le contrle est situ. Laspect contrle concerne la fois la cohrence des modications et la ralisation des modications en elles mmes. Externe : la reconguration est contrle depuis lextrieur. Par exemple, un dialogue stabli entre lapplication et un oprateur lui permettant denvoyer une squence de commandes contrlant la reconguration. Auto gr : certaines recongurations, inities en interne, sont dicilement prdictibles et planniables et certaines requirent des mesures immdiates pour satisfaire les exigences du systme. Ces cas demandent une approche dirente o le systme eectue les recongurations de lui mme, sans interventions extrieures.
A.2
Rfrentiel de Bradbury et al. (2001)
Mme si aucun rfrentiel nest directement explicit, les travaux de Bradbury et al. [BCDW04] identient certaines dimensions principales 1 que nous prsentons sous la forme du repre trois
1. Une version ane de leur travail est disponible dans [Bra04]
ANNEXE A
139
dimensions de la gure A.2. Ces dimensions concerne linitiation du changement, la gestion du changement et le support doprations oert pour raliser le changement.
tel-00459925, version 1 - 25 Feb 2010
Figure A.2 Repre tri-dimensionnel propos par Bradbury et al.
A.2.1
Initiation du changement
Linitiation du changement caractrise lendroit do est dclench le changement. Linitiation peut tre interne ou externe. Les auteurs dnissent quune architecture auto-gre est une architecture dans laquelle la globalit du processus de changement est initi en interne. Interne : linitiation interne implique gnralement des sondes qui fournissent les informations relatives lexcution sur lesquelles les dcisions sont bases. Externe : linitiation externe implique gnralement un utilisateur extrieur, ou un systme extrieur.
A.2.2
Gestion du changement
A cause de laugmentation de la taille et de la complexit des systmes, le passage lchelle est un problme important, et la gestion de la reconguration dans les architectures dynamiques est un facteur dterminant. En eet, on distingue la gestion centralise et dcentralise. Centralise : la gestion est centralise dans un lment spcique. Decentralise : la gestion est distribue travers les composants.
A.2.3
Support doprations
Les changements quun systme dynamique peut eectuer au niveau architectural sont limits par les oprations de reconguration disponibles. Par exemple, si un systme peut uniquement ajouter des connecteurs mais pas des composants, celui-ci est limit dans sa faon de traiter les
140
ANNEXE A
besoins de reconguration. Le support se caractrise par la possibilit de spcier des oprations de reconguration basiques et avances. Basique : il sagit de laddition et de la suppression de composants et de connecteurs dans larchitecture, soit quatre oprations au total. Avanc : il sagit de la combinaison des oprations basiques au sein dun bloc structurant (i.e., un groupement doprations) mais aussi des constructions utilises pour les combiner (e.g., squence, choix, et itration).
A.3
Rfrentiel de Sadou et al. (2007)
tel-00459925, version 1 - 25 Feb 2010
Les caractristiques utilises pour aborder lvolution dans [SH07] sont introduites sous formes de trois interrogations : quoi, quand et comment. Les auteurs parlent respectivement de lobjet de lvolution, du type dvolution et du support de lvolution. Le tryptique ainsi obtenu est reprsent en gure A.3. Ces dimensions sont dtailles dans ce qui suit.
Figure A.3 Repre tri-dimensionnel propos par Sadou et al.
A.3.1
Objet de lvolution
Cette dimension prcise les lments architecturaux sur lesquels porte lvolution. Lobjet de lvolution peut tre tout lment ri et considr comme citoyen de premire classe par lADL utilis dans la description de larchitecture concerne par lvolution. Ainsi, une volution peut porter sur une conguration, un composant, un connecteur, et/ou sur une interface.
A.3.2
Type dvolution
Le type dvolution indique quel moment du cycle de vie est ralise lvolution. Cela permet de distinguer lvolution statique de lvolution dynamique.
ANNEXE A
141
Statique : lvolution de larchitecture logicielle est ralise durant la phase de spcication et/ou de conception du systme quelle dcrit. Dynamique : lvolution de larchitecture logicielle est ralise durant la phase dexcution du systme quelle dcrit.
A.3.3
Support de lvolution
tel-00459925, version 1 - 25 Feb 2010
Le support dvolution reprsente le moyen (oprations et mcanismes) propos pour exprimer et grer lvolution dune architecture logicielle. Il existe trois cas de gures : Implicite : le support de lvolution est implicite si aucune opration dvolution ni mcanisme ne sont oerts pour faire voluer une architecture logicielle. Si un besoin dvolution est apparu, alors le concepteur soit, ne sera pas en mesure de rpondre ce besoin, soit devra identier dune faon ad-hoc le moyen de raliser cette volution. Prdni : le support dvolution est prdni sil est limit un ensemble doprations dvolution et/ou de mcanismes bien prcis. Il nexiste alors aucun autre moyen dexprimer une volution sur une architecture logicielle en dehors de ceux prdnis. Explicite : le support de lvolution est explicite si celui-ci ore le moyen dexprimer toute volution que lon souhaite appliquer sur larchitecture logicielle. Ceci implique que le support prcise un ensemble doprations dvolution mais aussi les mcanismes pour les rutiliser an dexprimer toute autre volution sur une architecture logicielle.
A.4
Bilan
Chacun des tryptiques prsents ci-dessus orent un angle de vue particulier sur lvolution lchelle de larchitecture des systmes logiciels. Il est noter que certains critres peuvent parfois tre recoups et quun mme vocabulaire peut recouvrir des signications direntes selon les auteurs. Nanmoins, ces trois rfrentiels orent une complmentarit dans la comprhension de dirents aspects de lvolution architecturale. Pour terminer cette tude, nous pouvons mentionner le travail de Mens et al. [BMZ 05], dans lequel les auteurs proposent un rfrentiel se focalisant sur les dtails techniques, cest--dire, le "Quand", le "O, le "Quoi" et le "Comment" des activits dvolution. Pour rpondre ces quatre interrogations, les auteurs mettent en avant quatre dimensions respectives : les proprits temporelles, lobjet du changement, les proprits systme et le support du changement. Toutefois, il faut bien dire que le repre quatre dimensions ainsi obtenu reste trs gnraliste.
tel-00459925, version 1 - 25 Feb 2010
A NNEXE
Algorithmes pour le raisonnement classicatoire

tel-00459925, version 1 - 25 Feb 2010
Au chapitre 4, nous avons montr comment un raisonnement classicatoire sur les styles dvolution pouvait tre la base des oprations dintgration et de recherche dans les bibliothques de styles dvolution. Cette annexe dtaille la partie algorithmique de ce processus.
B.1
Algorithme gnrique de classication
Notre algorithme gnrique de classication est paramtr par un test de subsomption par la spcialisation ou par la composition, en vue dtre excut sur le contenu dune bibliothque de styles dvolution (voir listing B.1). Selon la subsomption retenue, s ou c , le processus de classication dbutera respectivement sur les racines Evolution ou NEV. Au nal, lensemble des SPS (les subsumants les plus spciques) et SPG (les subsums les plus gnraux) calcul de la sorte dtermine la position dune spcication specif dans E , lensemble des styles dvolution contenus dans une bibliothque de niveau E1. Algorithm 1 Classication Require: specif, root E , est une fonction de subsomption donne 1: SP S, SP G ; 2: SP S RechercherSPS(specif , root, ) ; 3: for all entry in SP S do 4: SP G SP G RechercherSPG(specif , entry , ) 5: end for On remarquera dans le listing B.1 que le calcul des SPS sert de point dentre au calcul des SPG. Les fonctions RechercherSPS et RechercherSPG sont dtailles dans les sections qui suivent.
B.2
Algorithme de recherche des SPS
Le principe de lalgorithme du listing B.2 est de parcourir la hirarchie en profondeur en partant de la racine jusqu trouver une description de style qui ne subsume plus la description 143
144
ANNEXE B
classer x. Le squelette de cette fonction rcursive est donn ci-dessous, o current reprsente le style dvolution courant. Algorithm 2 RechercherSPS Require: x, current E , est une fonction de subsomption 1: L ; 2: if not x current then 3: return ; 4: else 5: if isLeaf(current, ) then 6: return current ; 7: else 8: L ; 9: end if 10: for all d in descendants(current, ) do 11: L L RechercherSPS(x, d, ) ; 12: end for 13: if L = then 14: return current ; 15: else 16: return L ; 17: end if 18: end if
tel-00459925, version 1 - 25 Feb 2010
B.3
Algorithme de recherche des SPG
Il sut de ne considrer que lensemble des descendants du SPS. Si un des descendants est subsum par la description du style classer x, alors il est un SPG et sa descendance est ignore, sinon leurs descendants sont tests leur tour jusqu ce quun SPG soit trouv ou quil ny ait plus aucun descendants tester. Lalgorithme correspondant est prsent dans le listing B.3.
B.4
Remarques et amliorations
Ds que les lments sont structurs hirarchiquement, la mme technique de classication peut tre employe. Cest tout lintrt de lalgorithme gnrique expos dans cette section. En revanche, la dtermination du subsumant et du subsum est fondamentalement dirente selon que lon considre la relation de spcialisation ou de composition. Le test de subsomption de spcialisation sappuie sur les paramtres et les relations de composition et dutilisation dun entte. Le test de subsomption de composition sappuie uniquement sur les relations de composition dun entte. Aussi, les tests de subsomption par la spcialisation et par la composition sont des fonctions qui utilisent les styles comme des boites noires, ignorant leurs dtails dimplmentation. La technique de classication en elle mme peut tre amliore suivant direntes directions.
ANNEXE B Algorithm 3 RechercherSPG Require: x, current E , est une fonction de subsomption 1: L ; 2: if current x then 3: return current 4: else 5: if isLeaf(current, ) then 6: return ; 7: else 8: for all d in descendants(current,) do 9: L L RechercherSPG(x, d, ) ; 10: end for 11: return L 12: end if 13: end if
145
tel-00459925, version 1 - 25 Feb 2010
B.4.1
Optimisation de la traverse
Dans le cas de la composition mais aussi dans le cas o lhritage multiple serait autoris, les hirarchies obtenues sont de type treillis. La consquence directe de cela est que certains noeuds de la hirarchie peuvent tre visits plusieurs fois lors de lexcution de lalgorithme de classication. Pour remdier cela, on peut recourir un systme de marquage an dviter de re-visiter des noeuds.
B.4.2
Hirarchies orthogonales
Dans lapproche choisie, nous disposons de deux hirarchies distinctes et bien dnies, enracines Evolution et NEV. Une autre approche consiste considrer ces deux hirarchies comme tant orthogonales lune de lautre. Le principe tant de considrer quil nexiste pas quune seule hirarchie de composition, mais plusieurs hirarchies, enracines diremment. Ainsi, chaque style dvolution est potentiellement la racine dune hirarchie de composition. Le cur de lalgorithme gnrique de classication reste inchang, mais la phase dinitialisation relative la composition est modie dans la mesure o il faut pouvoir dterminer les multiples racines. Dans ce cas de gure, il est judicieux dexplorer la hirarchie de spcialisation dabord, en considrant le style dvolution courant comme la racine potentielle dune hirarchie de composition quil convient alors dexplorer.
B.4.3
Mesure du degr de subsomption
An daner le raisonnement classicatoire, il est intressant de sappuyer sur une distance dinclusion ou degr de subsomption. Il sagit dune mesure asymtrique entre deux descriptions de styles dvolution et dont le rsultat va permettre de restreindre le nombre de SPS et de SPG. En eet, dans lapproche choisie, le test de subsomption est une fonction binaire, cest--dire soit il russi, soit il choue. Mais on peut dcider de mesurer le degr de subsomption, exprim dans lintervalle [0..1]. Au dessous dun certain seuil (x empiriquement), des SPS/SPG ne seront pas retenus lors de lexploration de la hirarchie. On trouve dans la littrature plusieurs techniques
146
ANNEXE B
destines calculer le degr dinclusion dun concept dans un autre, caractrisant la distance et ainsi la similarit entre deux concepts. Cette technique serait particulirement intressante pour lopration de recherche dans la bibliothque an de slectionner les meilleurs styles candidats la rutilisation en fonction des besoins exprims par lutilisateur.
B.4.4
Traitement smantique
tel-00459925, version 1 - 25 Feb 2010
Le raisonnement classicatoire opr ici peut parfois tre considr comme erron du point de vue smantique. Ceci est d au fait que lalgorithme de structuration taxinomique repose sur un traitement purement syntaxique. En loccurrence, ce sont les informations syntaxiques de la partie entte dun style qui entrent en jeu (i.e., paramtres et relations), tandis que les informations smantiques ne sont pas exploites (i.e., nom du style et description textuelle du but). Il est parfaitement envisageable dutiliser un thsaurus an de guider le raisonnement classicatoire. Par exemple, on pourrait infrer une relation entre deux styles dvolution si il existe une relation de synonymie entre le nom de ces derniers. La convention de nommage des styles dvolution, de la forme Evolution@ElementEvolutif facilitera ce traitement dans la mesure ou loprateur et loprande sont facile isoler.
A NNEXE
Le prototype COSAStudio
tel-00459925, version 1 - 25 Feb 2010
Cette annexe concerne le dveloppement dun outil CASE 1 baptis COSAStudio. Lobjectif du projet COSAStudio consiste proposer un prototype pour la conception et lvolution dune architecture logicielle. Face la dicult dvaluer quantitativement les propositions lies cette thse, COSAStudio permet de concrtiser un certain nombre dentre elles.
C.1
Prsentation gnrale de COSAStudio
Dans leur article [JB04], Anton Jansen et Jan Bosch concluent leur valuation sur le fait quen gnral, les outils darchitecture ne voient pas lvolution comme une partie inhrente et une dimension spare de larchitecture logicielle. En eet, dans la majorit des outils (ArchJava, ArchStudio, AcmeStudio, etc.), laccent est mis sur la dnition de larchitecture de faon correcte. Lvolution de larchitecture est souvent supervise, non implmente, et laisse la charge doutils idoines. Par consquent, loutillage pour lvolution architecturale nest actuellement ralise que partiellement. Loutil COSAStudio vise permettre aussi bien aux architectes de dcrire leurs architectures que de les faire voluer. Le dveloppement dun nouvel outil de modlisation est une tche dicile et chronophage. Pour acclrer et faciliter cette tche, COSAStudio est construit partir de lenvironnement de modlisation dEclipse, lEclipse Modelling Framework (EMF).
C.2
Eclipse Modelling Framework
EMF (Eclipse Modeling Framework) est un cadre de modlisation pour Eclipse. Le cur du framework EMF inclue un mta-mta-modle (Ecore) pour dcrire des modles et un support excutable pour les modles, intgrant un mcanisme de notication des changements, un support pour la persistance travers une srialisation XMI, et une API rexive pour manipuler des objets EMF de manire gnrique. En dautres termes, Ecore dnit la structure des mta-modles qui dnissent leur tour les modles que les dveloppeurs utilisent pour conserver les donnes de leurs applications. EMF peut tre vu comme comme une implmentation Java ecace du coeur de lAPI du MOF de lOMG. Cependant, an dviter toute confusion, le mta-mta-modle dans EMF se nomme Ecore. Dans la proposition actuelle de MOF 2.0, un sous-ensemble du MOF, appel EMOF (Essential MOF), est spar. Il y a de lgres dirences, principalement
1. Acronyme anglais pour Computer Aided Software Engineering.
147
148
ANNEXE C
de nommage, entre Ecore et EMOF. Les principaux concepts de Ecore sont prsents dans la Figure C.1.
tel-00459925, version 1 - 25 Feb 2010
Figure C.1 Hirarchie des concepts de Ecore. Du point de vue de la mta-modlisation, EMF supporte une hirarchie trois niveaux : le niveau mta-mta-modle (Ecore), le niveau mta-modle et le niveau modle. Au sommet de la hirarchie, Ecore est auto-dni, cest--dire que lon trouve dans EMF le chier ECORE.ecore. Puis, laide de ce dernier, on peut dnir par exemple le mta-modle UML 2.0 par le chier UML2.ecore. A la base de la hirarchie de modlisation, lutilisateur nal peut se crer un diagramme au choix dUML dans le chier diag1.uml. Dans EMF, lextension donne aux chiers (i.e., les modles srialiss en XMI) rete le nom du mta-modle et donc du langage qui a servi les dcrire.
C.3
lments caractristiques de COSAStudio
Cette section donne un aperu des choix et solutions techniques retenues pour COSAStudio et qui peuvent probablement tre rutilises pour la construction dautres outils de ce genre.
C.3.1
Interface graphique utilisateur
COSAStudio a fait le choix dun environnement de modlisation entirement visuel o chaque artefact possde une reprsentation graphique, mme minimaliste. On peut schmatiser son interface graphique par la Figure C.2. Sa structuration est hrite de celle dEclipse. Les direntes parties de la structure sont : Menu : donne accs toutes les actions possibles de loutil. Cette barre peut tre adapte en fonction du contexte (i.e., si aucun modle nest en cours ddition, il est inutile dacher les actions associes). Explorateur : il est ncessaire de pouvoir organiser (supprimer, dplacer, renommer, etc.) les direntes ressources produites ou consommes durant lactivit de modlisation.
ANNEXE C
149
Figure C.2 Modle dinterface utilisateur pour loutil COSAStudio.
tel-00459925, version 1 - 25 Feb 2010
Zone de modlisation : cest lditeur de modles. Il permet de visualiser et de manipuler les lments de modlisation. Par dfaut, il se charge de la cration, des modications et des suppressions de ces lments. Une reprsentation arborescente des lments est oerte par dfaut. Si Eclipse GEF (Graphical Editing Framework ) [www 6 ] est exploit, les lments bncient dune reprsentation graphique personnalise. Feuille de proprits : permet dacher et dditer les proprits des lments de modlisation. Cette feuille est accessible lorsquun lment du modle est slectionn. Palette : propose les outils permettant linteraction entre lutilisateur et lditeur. Il sagit doutils de cration dlments par "glisser-dposer", de zoom, de slection. Son apparence doit tre dnie par GEF.
C.3.2
Hirarchie de modlisation
La Figure C.3 donne une vision densemble des dirents modles intgrs dans le fonctionnement de COSAStudio, dans le cadre du framework EMF. Au niveau M2, on trouve les mta-modles de COSA, de SAEM, dUML et du langage de transformation ATL [JK05] (Atlas Transformation Language ). Au niveau M1 on trouve les modles TU.cosa et TUEvol.saem. Le premier contient la dnition des types COSA pour le domaine de la tuyauterie. Le second contient les styles dvolution associs ces types. On trouve galement un ensemble de transformations utiles. EMF naccepte que les trois niveaux de modlisation M3, M2 et M1. Or, cest au niveau M0 (ou A0 dans le paradigme des architectures) que lutilisateur nal doit dcrire son application, en loccurrence TU20.tu. Nous expliquons dans la section suivante comment introduire dans EMF le dernier niveau.
C.3.3
Introduction du niveau A0
Le framework EMF est bas sur Java, et de ce fait est enracin dans une dichotomie type instance. En eet, le langage Java naccepte que deux niveaux de modlisation eectif : les types (i.e., les classes java) et les instances (i.e., les objets java). Ceci sut supporter nativement les niveaux de modlisation M3 et M2. Pour obtenir le troisime niveau M1, EMF utilise une
150
ANNEXE C
Figure C.3 Vue densemble des dirents modles ncessaires COSAStudio.
tel-00459925, version 1 - 25 Feb 2010
technique de DataBinding (production des classes Java partir de document XMI) ou encore son API rexive. Lintroduction dun quatrime et dernier niveau M0 consiste r-appliquer ces principes par simple dcalage des niveaux de modlisations considrs. Ainsi, la transformation reprsente sur la Figure C.4 vise "remonter" le langage TU au niveau M2 an de le poser comme base dun nouvel environnement de modlisation. De ce point de vue, COSAStudio peut tre peru comme un mta-outil de modlisation.
Figure C.4 Introduction dun niveau de modlisation M0 par une technique de transformation de modle. Le mta-modle dentre de la transformation est COSA (COSA.ecore), et le mta-modle de sortie est Ecore (Ecore.ecore). La description de la transformation en ATL repose sur les correspondances entre les concepts des deux mta-modles. Selon les rgles de correspondances tablies dans COSA2ECORE.atl, le rsultat de la transformation de TU.cosa est TU.ecore.
ANNEXE C
151
C.4
Les perspectives dans COSAStudio
Dans la plate-forme Eclipse, il y a deux couches principales : la couche modle et la couche interface utilisateur. Le modle sous-jacent, connu sous le nom de Workspace, est un ensemble de ressources (projets, dossiers et chiers). Linterface utilisateur, ou Workbench, dnit la prsentation de ces ressources. Dans le Workbench, la fonctionnalit perspective est utilise pour contrler la visibilit des lments dans le modle et dans linterface utilisateur. Elle contrle ce qui est visible dans le modle (quel projet, dossier ou chiers) et ce qui est visible dans linterface utilisateur (quelles actions ou vues). Ces contrles permettent de naviguer dans le Workspace et de le modier dune manire qui corresponde aux objectifs des utilisateurs. tant construit sur la plateforme Eclipse, COSAStudio suit les mmes principes. Nous avons dnis trois perspectives direntes : COSA, C&C et SAEM.
C.4.1
tel-00459925, version 1 - 25 Feb 2010
La Perspective COSA
La perspective COSA permet larchitecte mtier de dnir ses types dlments de modlisation architecturaux en COSA. Il dnit ses vues (tuyauterie, gaine, lectricit, . . .) comme des ensembles bien dnis de types. Il a sa disposition dirents lments de modlisation : type de conguration, type de composant, type de connecteur, etc., destins tre regroups dans un lment de modlisation racine : la bibliothque de types. La modlisation se fait par instanciation des concepts contenus dans le chier COSA.ecore. Une capture dcran de la perspective COSA dans loutil COSAStudio est visible sur la Figure C.5.
C.4.2
La Perspective C&C
A premire vue, on sattend ce que les lments de modlisation de chaque mtier orent un vocabulaire et une notation graphique spcique. Mais ce rsultat ncessite une phase de personnalisation pralable, o chaque mta-modle est associ une nouvelle perspective et un nouvel aspect graphique. Pour pouvoir se passer de cette personnalisation qui reste manuelle et fastidieuse, COSAStudio ore la place une perspective minimale et commune C&C, o les lments de modlisation standard sont le composant et le connecteur. Toutefois, laspect mtier est pris en compte lors de leur intgration dans le modle, o leur vritable nature est slectionne. Par exemple, comme le montre la Figure C.6, plutt que de crer les perspectives Tuyauterie, Gaine et Electricit, la perspective C&C sut. La modlisation se fait par instanciation des concepts contenus dans le chier correspondant la vue mtier dsire (TU.ecore, Gaine.ecore, Elec.ecore, . . .). Une capture dcran de la perspective C&C dans loutil COSAStudio est visible sur la Figure C.6.
C.4.3
La Perspective SAEM
Cest dans cette perspective que sont modliss les styles dvolution. Pour ce faire, larchitecte dapplication volutive peut instancier les concepts dni dans le mta-modle SAEM.ecore et les associer aux concepts de la vue mtier dsire (TU.ecore, Gaine.ecore, Elec.ecore, . . .). Ainsi, lAAE peut construire des bibliothques de niveau E1 adaptes chaque vue mtier. Grce EMF.Edit, larchitecte dispose dun diteur arborescent pour dcrire son modle SAEM. Nous navons pas dni de notation graphique personnalise puisque ces modles sont destins tre
152
ANNEXE C
projets vers COSA et ainsi de bncier de la notation de ce dernier. Une capture dcran de la perspective SAEM dans loutil COSAStudio est visible sur la Figure C.7. Dans cette perspective, nous avons implment lopration dintgration dune nouvelle description dans la bibliothque (selon le point de vue spcialisation pour linstant). Le lien entre le code java de lalgorithme de classication et son intgration sous forme dun menu contextuel sous COSAStudio a t rendu possible par une technique de script EWL inclus dans le plugin Epsilon [www 5 ].
C.5
Amliorations futures
tel-00459925, version 1 - 25 Feb 2010
Le dveloppement du prototype COSAStudio valide le travail ralis par Smeda et al. sur lADL COSA [Sme06]. Le prototype valide galement une partie des ides proposes dans cette thse autour du paradigme des styles dvolution. Le problme est que le framework EMF facilite la manipulation dentits de type produit, mais beaucoup moins celle dentits de type processus comme cest le cas des styles. A lheure actuelle, la perspective SAEM permet un architecte dapplications volutives de modliser correctement des styles dvolution, mais il nous a t trs dicile dincorporer dans COSAStudio laspect excutable des styles dvolution. Cette fonctionnalit est une priorit pour la future version de loutil.
Figure C.5 Perspective COSA sur un modle vierge.
ANNEXE C
153
tel-00459925, version 1 - 25 Feb 2010
Figure C.6 Perspective C&C sur un modle vierge pour le mtier de la tuyauterie.
154
ANNEXE C
tel-00459925, version 1 - 25 Feb 2010
Figure C.7 Perspective SAEM sur un modle vierge.
tel-00459925, version 1 - 25 Feb 2010
Styles dvolution dans les architectures logicielles

Olivier Le Goaer
Rsum
Les architectures logicielles ont t introduites en rponse laccroissement de la complexit des systmes, en favorisant leurs descriptions un haut niveau dabstraction. Dans cette thse, nous proposons daborder la problmatique de leurs volutions avec comme objectif, de capitaliser les volutions rcurrentes et de favoriser leur rutilisation. Notre contribution se dcline en deux volets majeurs. Le premier volet concerne la proposition du modle dvolution SAEM (Stylebased Architectural Evolution Model ), permettant labstraction, la spcication et la gestion de lvolution dans les architectures logicielles au travers du concept de style dvolution. SAEM se veut un modle dvolution gnrique, uniforme et indpendant de tout langage de description darchitecture. Le formalisme propos dcrit les concepts du style dvolution selon un tryptique : domaine, entte et comptence. Le deuxime volet concerne le dveloppement dune approche de rutilisation par dessus SAEM pour tenter de rendre les activits dvolution plus rentables. Nous proposons une dmarche pour la construction de bibliothques pour les styles dvolution, orchestre par direntes catgories dintervenants. Les bibliothques sont labores selon deux types de processus complmentaires : pour la rutilisation et par la rutilisation . Nous prsentons une technique de raisonnement classicatoire pour permettre aux bibliothques dtre peuples et interroges dans le but de grer les savoir et savoir-faire relatifs lvolution architecturale. Mots-cls : Style dvolution, Patron dvolution, Rutilisation de lvolution, Bibliothque, Architecture Logicielle, Langage de Description dArchitecture.
tel-00459925, version 1 - 25 Feb 2010
Abstract
Software architectures have been introduced in response to the increasing complexity of systems, by leveraging their descriptions at a high level of abstraction. In this thesis, we propose to tackle the problem of their evolutions with the aim of capitalizing the recurrent evolution and fostering their reuse. Our contribution is divided into two major parts. The rst part concerns with proposing the evolution model SAEM (Style-based Architectural Evolution Model), allowing abstraction, specication and management of evolution in software architectures through the concept of evolution style. SAEM is a generic evolution model, consistent and independent of any architectural description language. The proposed formalism describes evolution styles concepts according to a triptych: domain, header and competence. The second part concerns with the development of a reuse-driven approach on top of SAEM to try to make evolutions more cost-eective activities. We propose an approach for the construction of libraries dedicated to evolution styles, orchestrated by several stakeholders. Libraries are developed with two complementary types of processes: for reuse and by reuse . We explain a classicationbased reasoning technique to enable libraries to be enriched and queryied in order to manage the knowledge and know-how related to architectural evolution. Keywords: Evolution Style, Evolution Pattern, Evolution Reuse, Library, Software Architecture, Architecture Description Language.

These

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

These

Uploaded by

Copyright:

Available Formats

cole Centrale de Nantes

cole des Mines de Nantes

COLE DOCTORALE STIM SCIENCES ET TECHNOLOGIES DE LINFORMATION ET DES MATRIAUX

No attribu par la bibliothque

Styles dvolution dans les architectures logicielles

tel-00459925, version 1 - 25 Feb 2010

STYLES DVOLUTION DANS LES ARCHITECTURES LOGICIELLES

Evolution styles within software architectures

tel-00459925, version 1 - 25 Feb 2010

favet neptunus eunti

Olivier Le Goaer Styles dvolution dans les architectures logicielles xvi+156 p.

tel-00459925, version 1 - 25 Feb 2010

tel-00459925, version 1 - 25 Feb 2010

tel-00459925, version 1 - 25 Feb 2010

tel-00459925, version 1 - 25 Feb 2010

tel-00459925, version 1 - 25 Feb 2010

tel-00459925, version 1 - 25 Feb 2010

tel-00459925, version 1 - 25 Feb 2010

tel-00459925, version 1 - 25 Feb 2010

tel-00459925, version 1 - 25 Feb 2010

tel-00459925, version 1 - 25 Feb 2010

Figure 1.1 Reprsentation schmatique de la structure de cette thse.

Liste des publications obtenues

tel-00459925, version 1 - 25 Feb 2010

Workshops Internationaux avec Comit de Lecture et Actes

Workshops Nationaux avec Comit de Lecture sans Actes

tel-00459925, version 1 - 25 Feb 2010

tel-00459925, version 1 - 25 Feb 2010

Architecture logicielle : tat du domaine

tel-00459925, version 1 - 25 Feb 2010

Les architectures logicielles

CHAPITRE 1 Architecture logicielle : tat du domaine

mergence de larchitecture logicielle

Le d des systmes complexes

CHAPITRE 1 Architecture logicielle : tat du domaine

tel-00459925, version 1 - 25 Feb 2010

CHAPITRE 1 Architecture logicielle : tat du domaine

tel-00459925, version 1 - 25 Feb 2010

Reconnaissance de larchitecture logicielle

CHAPITRE 1 Architecture logicielle : tat du domaine

tel-00459925, version 1 - 25 Feb 2010

Larchitecture au coeur du dveloppement

CHAPITRE 1 Architecture logicielle : tat du domaine

tel-00459925, version 1 - 25 Feb 2010

Figure 1.3 tapes dun modle de dveloppement en cascade et leurs reprsentations.

CHAPITRE 1 Architecture logicielle : tat du domaine

Les acteurs engags dans le dveloppement

tel-00459925, version 1 - 25 Feb 2010

CHAPITRE 1 Architecture logicielle : tat du domaine

Perry et Wolf (1992)

tel-00459925, version 1 - 25 Feb 2010

Garlan et Shaw (1993)

Bass, Clements et Kazman (1998)

CHAPITRE 1 Architecture logicielle : tat du domaine

La norme AINSI/IEEE Std 1471 (2000)

tel-00459925, version 1 - 25 Feb 2010

CHAPITRE 1 Architecture logicielle : tat du domaine

tel-00459925, version 1 - 25 Feb 2010

CHAPITRE 1 Architecture logicielle : tat du domaine

tel-00459925, version 1 - 25 Feb 2010

CHAPITRE 1 Architecture logicielle : tat du domaine

tel-00459925, version 1 - 25 Feb 2010

CHAPITRE 1 Architecture logicielle : tat du domaine

Langages de description darchitectures

'#&# 81)) $$Q" 2VWCV6567 XYC5

STU"#81)) $$Q"'# GP'QR '#&# 81)) $$Q" 2V665D7V@ XYC5

$$Q"'#&# `aW43Y 81))

cyefghipq cvwxgtiwtqvi $$'#&# 23456781))

cefghipq cgwptg EF' IF'

$$H"!bS)) $$%& ' % ()) # !" G#!%1H&F%(