These Doctorat AltiAdel

Rpublique Algrienne Dmocratique et Populaire
Ministre de l'Enseignement Suprieur et de la Recherche Scientifique Universit Ferhat Abbas de Stif - UFAS (Algrie)
Thse
Prsente la Facult des Sciences Dpartement d'informatique
En vue de l'obtention du diplme de
Doctorat
Option : Informatique Par
Adel ALTI
Thme
Coexistence de la modlisation base dobjets et de la modlisation base de composants architecturaux pour la description de larchitecture logicielle
Soutenue le 22 Juin 2011 devant le jury compos de :

Prsident Pr Mohamed Ahmed-NACER Examinateurs Pr Mohamed Tayeb LASKRI Pr Nacereddine ZAROUR Dr Abdallah KHABABA Dr Allaoua REFOUFI Rapporteur Dr Abdallah BOUKERRAM Prof Prof Prof MCA MCA MCA USTHB Alger Univ Annaba Univ Constantine UFAS Stif UFAS Stif UFAS Stif
Remerciements
Je remercie chaleureusement Monsieur feu Tahar Khammaci. Matre de Confrences Nantes, davoir accept de diriger mes travaux de recherche. Tahar, jai eu la chance de travailler avec toi. Je noublierai jamais tes conseils et tes pertinentes remarques. Merci ! Et repose en paix. Que le Professeur Mourad Oussalah, trouve ici toute ma reconnaissance pour ses prcieux conseils, et ses orientations, dans la construction de cette thse. Je remercie vivement Monsieur Abdallah Boukerram, MC lUFAS, pour tous ses conseils et ses orientations dans laboutissement de cette thse. Quil soit vivement remerci. Je remercie le Pr. M. Ahmed NACER de lUSTHB d'avoir d'accept de prsider ce jury, quil trouve toute ma gratitude. Je remercie le Pr. M. Laskri de luniversit de Annaba, pour lhonneur qil me fait, en acceptant dvaluer ce travail. Que le Pr. N. Zarour, trouve galement toute ma gratitude en acceptant de faire partie de ce jury. Je tiens prsenter tous mes remerciements Dr A. Reffoufi et au Dr A. Khababa, pour le temps consentis lvaluation de cette thse. ma famille, mes frres Samir et Fouad, mes surs Hayet, Nassima et Rima, et notamment ma mre et mon pre qui je rserve bien videment dautres formes de remerciements ! Je remercie Mr A. Smeda, Doctorant Nantes, je dis : Merci Adel, pour ton support moral et ton aide, qui ont compt beaucoup pour moi. Merci encore ! Merci aussi Maiza. A, Reffad. H, L. Zitouni, M. Messai, A. Amirat, C. Khentout, L. Douidi, C. Mediani et K. Harbouche, D. Mahieddine sans oublier M. Nekkache pour leur soutien moral. Enfin, que tous les collgues du dpartement dinformatique de lUFAS, avec qui jai pass de longues annes de travail et dchange en soient remercis. sympathique quipe MODAL. Toute ma reconnaissance la
Rsum
Laspect cl de conception du systme logiciel est son architecture. La description de larchitecture logicielle est fonde sur deux techniques de modlisation : la modlisation darchitecture logicielle base de composants (composants acadmiques et composants industriels) et la modlisation oriente objet sous la houlette dUML (Unified Modeling Language). Chacun de ces deux approches prsente des points forts et des points faibles. Notre contribution se dcline en deux volets : le premier volet concerne la dfinition dun profil UML 2.0 pour COSA (Component Object-based Software Architecture) ; est une approche hybride composant-objet de description darchitectures. On utilise toutes les capacits des profils UML (mta-modle et modle), pour dfinir une spcification complte pour larchitecture logicielle. Les profils UML existants sont ddis un type dapplication (systme distribus, temps rel, etc.), alors que notre profil est indpendant et spcialis dans une activit particulire de modlisation des langages de description darchitectures. Le deuxime volet porte sur lintgration du profil UML, COSA au sein de la dmarche MDA (Model Driven Architecture). Nous proposons une stratgie de transformation directe laide du profil UML pour llaboration des modles dimplmentation objets ayant un niveau dabstraction haut et un degr de rutilisation comme celui de COSA. Les outils COSABuilder et COSAInstantiator sont galement dvelopps et implments.
Mots cls
: Architecture Logicielle, Langages de Description dArchitecture, COSA, Profil
UML, MDA, Transformation.
Abstract
A key aspect of the design of any software system is its architecture. There are at least two different techniques of describing the architecture of a software system, either by using object-oriented modelling, in particular Unified Modelling Language (UML) or by using component-oriented modelling (academic components and industrial components). Each one of these two approaches has its advantages and also its drawbacks. Our contribute is situated around two axes: the first axe concerns with building a UML 2.0 profile for COSA (Component Object-based Software Architecture) ; which is an approach for software architecture based on object oriented modelling and component based modelling. Using the capacities of UML profiles (meta-models and models), we define a complete specification for software architectures. Actually, UML profiles are particular kind of application (system distributed, real time, etc), while our profile is independent and specialized in a particular activity of modelling of the languages of description of architectures. The second axe is interested with integrating COSA UML profile within MDA (Model Driven Architecture). Also we define a strategy of direct transformation using UML profile in the generation of the object implementation models. These models have a higher level of abstraction and a degree of reuse of COSA. COSABuilder and COSAInstantiator Tools are also developed and implemented.
Keywords:
Software Architecture, Architecture Description Language, COSA, UML profile,
MDA, Mapping.
. UML ) (. . : COSA 0.2 : UML . ) UML - ( . ) ( . UML COSA .MDA .COSA COSABuilder . COSAInstantiator : COSA MDA UML.
Table des matires
vi
Table des matires
INTRODUCTION GENERALE ............................................................................................................................. 1 INTRODUCTION ........................................................................................................................................................ 1 MOTIVATIONS .......................................................................................................................................................... 2 OBJECTIFS ................................................................................................................................................................. 3 CONTRIBUTIONS ...................................................................................................................................................... 3 ORGANISATION DE LA THESE .................................................................................................................................. 4 CHAPITRE 1 : LETAT DU DOMAINE................................................................................................................ 5 1.1 INTRODUCTION .................................................................................................................................................. 5 1.2 APPROCHE DE MODELISATION PAR OBJET ......................................................................................................... 6 1.2.1 Les concepts de base de la modlisation par objet ....................................................................................... 6 1.2.2 Les langages de la modlisation par objet ................................................................................................... 7 1.3 APPROCHE DE MODELISATION PAR COMPOSANTS ............................................................................................ 8 1.3.1 Les concepts de base de modlisation par composants ................................................................................ 9 1.3.2 Les langages de modlisation par composants .......................................................................................... 17 1.4 SIMILARITE ENTRE LA MODELISATION A BASE DOBJETS ET LA MODELISATION A BASE DE COMPOSANTS ..... 17 1.4.1 Avantages et inconvnients de la modlisation base dobjets ............................................................... 18 1.4.2 Avantages et inconvnients des modles base de composants................................................................ 20 1.4.3 Similarits et diffrences en terme de concepts de base............................................................................. 21 1.5 CXISTENCE DES DEUX MODELISATIONS POUR LA DESCRIPTION DE LARCHITECTURE LOGICIELLE ............. 21 1.5.1 La modlisation base de composants utilisant la modlisation base dobjets....................................... 22 1.5.2 Slection de notations UML pour reprsenter les descriptions darchitectures ....................................... 24 1.5.3 Reprsentation des vues architecturales en UML .................................................................................... 25 1.5.4 Combinaison de la modlisation base de composants et base dobjets ................................................. 26 1.6 CONCLUSION ................................................................................................................................................... 26 CHAPITRE 2 : LES LANGAGES DE MODELISATION DARCHITECTURE : CONCEPTS ET OUTILS DE SUPPORT .......................................................................................................................................................... 28 2.1 INTRODUCTION ................................................................................................................................................ 28
Table des matires
vii
2.2 DEFINITIONS .................................................................................................................................................... 29 2.2.1 Architecture logicielle............................................................................................................................... 29 2.2.2 Composant................................................................................................................................................ 29 2.2.3 Connecteur ............................................................................................................................................... 32 2.2.4 Configuration ........................................................................................................................................... 34 2.2.5 Styles architecturaux................................................................................................................................ 35 2.3 LES LANGAGES DE DESCRIPTION DES ARCHITECTURES A BASE DE COMPOSANTS .......................................... 39 2.3.1 Description des principaux ADLs........................................................................................................... 39 2.3.2 Outils de support des ADLs ..................................................................................................................... 42 2.4 LES LANGAGES DE MODELISATION DES ARCHITECTURES A BASE DOBJET ...................................................... 44 2.4.1 Description des principaux mthodes objets............................................................................................. 44 2.4.2 UML 2.0................................................................................................................................................... 45 2.4.3 Les outils de modlisation UML............................................................................................................... 52 2.5 COMPARAISON ET SYNTHESE ........................................................................................................................... 54 2.5.1 Description darchitectures ...................................................................................................................... 54 2.5.2 Critres des ADLs .................................................................................................................................... 55 2.5.3 Le support dvolution.............................................................................................................................. 56 2.5.4 Qualits et caractristiques dun outil de support................................................................................... 56 2.6 CONCLUSION ................................................................................................................................................... 58 CHAPITRE 3 : COSA : UNE APPROCHE HYBRIDE DE DESCRIPTION DARCHITECTURE LOGICIELLE............................................................................................................................................................ 59 3.1 INTRODUCTION ................................................................................................................................................ 59 3.2 COSA : UNE APPROCHE HYBRIDE DARCHITECTURES LOGICIELLES ............................................................... 60 3.2.1 Le mtamodle de COSA .......................................................................................................................... 62 3.2.2 Le mtamodle dinstance de COSA......................................................................................................... 70 3.2.3 Les mcanismes oprationnels de COSA.................................................................................................. 70 3.3 LARCHITECTURE A TROIS NIVEAUX DE COSA ............................................................................................... 74 3.3.1 Niveaux dabstractions pour llaboration des architectures logicielles ................................................... 74 3.3.2 Exemple applicatif .................................................................................................................................... 77 3.3.3 COSA et les langages de description darchitecture................................................................................. 77 3.3.4 Les avantages et les inconvnients de COSA ........................................................................................... 78 3.4 CONCLUSION ................................................................................................................................................... 80 CHAPITRE 4 : INTEGRATION DE LARCHITECTURE LOGICIELLE COSA AU SEIN DE LA DEMARCHE MDA................................................................................................................................................. 81
Table des matires
viii
4.1 INTRODUCTION ................................................................................................................................................ 81 4.2 LA PROJECTION DE COSA EN UML 2.0 .......................................................................................................... 82 4.2.1 Pourquoi la projection de COSA en UML? ............................................................................................. 83 4.2.2 Projection dun ADL vers UML via les mcanismes dextensibilits ..................................................... 86 4.2.3 Profil UML 2.0 pour larchitecture logicielle COSA ............................................................................... 88 4.2.4 Synthse.................................................................................................................................................. 107 4.3 ARCHITECTURE LOGICIELLE ET MDA ........................................................................................................... 108 4.3.1 La dmarche MDA (Model Driven Architecture).................................................................................. 108 4.3.2 Transformation et MDA ........................................................................................................................ 108 4.3.3 MDA et UML ........................................................................................................................................ 109 4.3.4 Les tapes de la dmarche MDA............................................................................................................. 111 4.4 INTEGRATION DE LARCHITECTURE LOGICIELLE COSA AU SEIN DE MDA ................................................. 111 4.4.1 Les tapes de la dmarche MDA............................................................................................................. 111 4.4.2 Intgration des ADLs au sein de MDA.................................................................................................. 112 4.4.3 Intgration de lADL COSA au sein de MDA....................................................................................... 113 4.4.4 Approche MDA centre sur la dcision architecturale........................................................................... 117 4.4.5 Synthse.................................................................................................................................................. 120 4.5 CONCLUSION ................................................................................................................................................. 120 CHAPITRE 5 : REALISATIONS ET EXPERIMENTATIONS ...................................................................... 122 5.1 INTRODUCTION .............................................................................................................................................. 122 5.2 MISE EN UVRE DE LINTEGRATION DE COSA AU SEIN DE MDA............................................................... 123 5.2.1 Transformation COSA (PIM) en UML 2.0 (PSM) ............................................................................... 125 5.2.2 Transformation COSA-UML (PSM) en eCore (PSM).......................................................................... 127 5.2.3 Transformation COSA-UML (PSM) vers CORBA (PSM) .................................................................. 139 5.3 ETUDE DE CAS : SYSTEME CLIENT-SERVEUR ................................................................................................. 146 5.3.1 Prsentation du systme Client-Serveur ................................................................................................ 146 5.3.2 La description du systme Client-Serveur avec COSAPlugin ............................................................... 148 5.3.3 La description du systme Client-Serveur avec COSABuilder .............................................................. 148 5.3.4 Ralisation du systme Client-Serveur avec COSA2CORBA Plugin ................................................... 154 5.3.5 COSA-UML vs. COSA - CORBA ........................................................................................................ 155 5.4 ETUDE COMPARATIVE ET SYNTHESE ............................................................................................................. 157 5.4.1 Comparaison avec ACMEStudio............................................................................................................ 157 5.4.2 Comparaison avec FractalGUI ............................................................................................................... 163
Table des matires
ix
5.4.3 Synthse.................................................................................................................................................. 165 5.4.4 Amliorations futures............................................................................................................................. 166 5.5 CONCLUSION ................................................................................................................................................. 167 CONCLUSION GENERALE ET PERSPECTIVES.......................................................................................... 169 BILAN DES TRAVAUX ET APPORTS DE LA THESE .................................................................................................. 169 INTERETS DU TRAVAIL ......................................................................................................................................... 171 CONCLUSION ....................................................................................................................................................... 172 PERSPECTIVES ...................................................................................................................................................... 173 BIBLIOGRAPHIE ................................................................................................................................................. 175 LISTE DES PUBLICATIONS PERSONNELLES ............................................................................................ 188 CHAPITRES DANS DES OUVRAGES ....................................................................................................................... 188 PUBLICATIONS DANS DES REVUES INTERNATIONALES ....................................................................................... 188 COMMUNICATIONS DANS DES CONFRENCES INTERNATIONALES .................................................................... 189 COMMUNICATIONS DANS DES WORKSHOPS INTERNATIONAUX (AVEC COMIT DE LECTURE) .......................... 191 COMMUNICATIONS DANS DES CONGRS INTERNATIONAUX (AVEC COMIT DE LECTURE) ............................... 192 LISTE DES OUTILS COSA................................................................................................................................. 193 PROFIL UML 2.0 POUR LARCHITECTURE LOGICIELLE COSA, COSAPLUG-IN ................................................ 193 TRANSFORMATION DE COSA VERS CORBA, COSA2CORBAPLUG-IN .......................................................... 193 TRANSFORMATION DE COSA VERS EJB 2.0, COSA2EJBPLUG-IN .................................................................... 194 COSABUILDER ET COSAINSTANTIATOR ........................................................................................................... 194 GLOSSAIRE........................................................................................................................................................... 195 ANNEXES............................................................................................................................................................... 197 ANNEXE A : CODE ATL DE LA TRANSFORMATION COSA - ECORE .................................................................. 197 ANNEXE B : UN EXTRAIT DU CODE ATL DES TRANSFORMATIONS COSA - CORBA ET CORBA IDL......... 199 B.1. La transformation COSA vers CORBA .................................................................................................. 199 B.2. La transformation CORBA vers IDL....................................................................................................... 202 ANNEXE C : EVALUATION DES OUTILS COSA ET ETUDES DE CAS .................................................................... 204 C.1. Evaluation des outils de modlisation et dinstanciation......................................................................... 204 C.2. Etudes de cas............................................................................................................................................ 205 C.2.1. Etudes de cas 1 : Systme de contrle d'accs au parking.................................................................... 205 C.2.2. tude de cas 2: Protocole de scurisation des transactions lectroniques ............................................ 207
Table des matires
Liste des figures
Figure 1.1 Figure 1.2 Figure 1.3 Figure 2.1 Figure 2.2 Figure 2.3 Figure 2.4 Figure 3.1 Figure 3.2 Figure 3.3 Figure 3.4
Les concepts de base de lapproche objet............................................................ 7 Description architecturale des systmes base de composants...................... 9 Les trois dimensions dun composant............................................................... 15 Les concepts de base des langages de description darchitecture.................30 Architecture quatre niveaux en UML 2.0....................................................... 47 Les lments architecturaux dans le mtamodle UML 2.0........................... 48 Les profils dans UML 2.0 .................................................................................... 51 Mtamodle de larchitecture COSA................................................................. 63 Les configurations dans COSA .......................................................................... 64 Les composants dans COSA ............................................................................... 64 Les connecteurs dans COSA ............................................................................... 65
Figure 3.5 Les interfaces dans COSA .................................................................................... 67 Figure 3.6 Mtamodle dinstance de larchitecture COSA............................................... 70 Figure 3.7 Figure 3.8 Figure 3.9 Exemple dinstanciation dans COSA ................................................................ 71 Exemple dhritage dans COSA......................................................................... 72 La structure du composant Serveur .................................................................. 75
Figure 3.10 Exemple de composition dans COSA ............................................................... 75 Figure 3.11 Les trois niveaux dabstractions de larchitecture logicielle .......................... 76 Figure 3.12 Le systme Client Serveur avec larchitecture trois niveaux de COSA.. 77 Figure 4.1 Figure 4.2 Figure 4.3 Figure 4.4 Figure 4.5 Figure 4.6 Figure 4.7 Exemple dinstances pour le systme Client-Serveur..................................... 93 Le profil COSA ..................................................................................................... 94 Lapplication du profil pour le systme Client-Serveur ...............................105 Systme Client-Serveur en COSA .................................................................... 106 Exemple du systme Client-Serveur en UML 2.0 ..........................................107 Intgration de larchitecture COSA au sein de la dmarche MDA............. 115 Transformation de COSA (PIM) vers CORBA (PSM)................................... 116
Table des matires
xi
Figure 4.7 Figure 4.8 Figure 5.1 Figure 5.2 Figure 5.3 Figure 5.4 Figure 5.5 Figure 5.6 Figure 5.7 Figure 5.8
Transformation de COSA (PIM) vers CORBA (PSM)................................... 116 MDD centr sur la dcision architecturale (vue structurelle)...................... 119 Intgration dans MDA de larchitecture logicielle COSA ............................ 124 COSA Plugin sous Eclipse 3.1.......................................................................... 126 Diagramme de classe de mta-mta-modle eCore ..................................... 128 Implmentation du mta-modle COSA vers eCore.................................... 129 Les diffrentes vues dune seule architecture Client/serveur ....................135 Modle dinterface utilisateur pour loutil COSAInstantiator .................... 138 Le profil CORBA ............................................................................................... 142 Transformation COSA CORBA ..................................................................... 146
Figure 5.9 Architecture/application du systme client-serveur ....................................147 Figure 5.10 Slection du profil COSA ..................................................................................148 Figure 5.11 Validation du systme Client-Serveur en UML 2.0 avec COSAPlugin...... 149 Figure 5.12 Architecture client/serveur en utilisant COSABuilder ................................ 151 Figure 5.13 Spcialisation d'un connecteur de l'architecture client / serveur ............... 152 Figure 5.14 Modle eCore de larchitecture Client/Serveur ............................................ 152 Figure 5.15 Application Client/Serveur en utilisant le gnrateur COSAInstantiator 153 Figure 5.16 Modle CORBA du systme Client-Serveur .................................................. 155
Liste des tables
12
Liste des tables
Table 1.1 Table 2.1 Table 2.2 Table 2.3 Table 2.4 Table 3.1 Table 3.2 Table 3.4 Table 3.5 Table 4.1 Table 4.2 Table 4.3 Table 4.4 Table 4.5 Table 4.6 Table 4.7 Table 4.8 Table 4.9 Table 5.1 Table 5.2 Table 5.3 Table 5.4 Table 5.5 Table 5.6 Table 5.7 Table 5.8
Les concepts de base des deux approches ........................................................ 21 Comparaison selon les concepts architecturaux.............................................. 54 Comparaison selon les critres des ADLs......................................................... 55 Comparaison selon les supports dvolution................................................... 56 Comparaison selon les critres des qualits dun outil du support.............. 57 Les trois niveaux conceptuels objets - composants ......................................... 76 Comparaison selon les concepts architecturaux.............................................. 78 Comparaison selon les critres des ADLs......................................................... 78 Comparaison selon les supports dvolution................................................... 78 Projection de C2 vers UML 1.4 ........................................................................... 89 Projection de Wright vers UML 1.4 ...................................................................89 Projection dACME vers UML 2.0......................................................................90 Choix de Projection dACME vers UML 2.0.....................................................90 COSA vs. UML 2.0 ............................................................................................... 91 Projection de COSA vers UML 2.0..................................................................... 96 Dfinition des valeurs marques de chaque strotype ............................... 107 Correspondance COSA CORBA ................................................................... 117 CORBA vs. EJB ................................................................................................... 120 Correspondance COSA eCore ....................................................................... 130 Les contraintes OCL COSA eCore ................................................................ 131 Correspondance COSA instance eCore........................................................ 137 Transformation COSA CORBA...................................................................... 143 COSA-UML vs. COSA-CORBA ...................................................................... 156 Rsultats de comparaison entre COSABuilder et ACMEStudio. ................157 COSABuilder vs. ACMEStudio ....................................................................... 163 COSABuilder vs. FractalGUI ........................................................................... 165
Introduction gnrale
Introduction gnrale
Introduction
Cette thse sinscrit dans le domaine des architectures logicielles et plus particulirement sur laspect structurel des langages de description des architectures (Architecture Description Languages, ADL) (Medvidovic, Taylor, 2000). Actuellement, un grand intrt est port au domaine de larchitecture logicielle (Clements, 2003). Cet intrt est motiv principalement par la rduction des cots et les dlais de dveloppement des systmes logiciels. En effet, on prend moins de temps acheter (et donc rutiliser) un composant que de le concevoir, le coder, le tester, le dboguer et le documenter. Une architecture logicielle modlise un systme logiciel en termes de composants et dinteractions entre ces composants. Elle joue le rle de passerelle entre lexpression des besoins du systme logiciel et ltape de codage du logiciel. Enfin, larchitecture logicielle permet dexposer de manire comprhensible et synthtique la complexit dun systme logiciel et de faciliter lassemblage des composants logiciels. Pour dcrire larchitecture logicielle et modliser ainsi les interactions entre les composants dun systme logiciel, deux principales approches ont vu le jour depuis quelques annes : la modlisation par composants et la modlisation par objets (Garlan, 2000b ; Khammaci et al, 2005). La premire approche, qui a merg au sein de la communaut de recherche Architectures Logicielles dcrit un systme logiciel comme un ensemble de composants qui interagissent entre eux par le biais de connecteurs. Les chercheurs de ce domaine ont permis dtablir les bases intrinsques pour dvelopper de nouveaux langages de description darchitectures logicielles. Larchitecture logicielle a permis notamment de prendre en compte les descriptions de haut niveau des systmes complexes et de raisonner sur leurs proprits un haut niveau dabstraction (protocole dinteraction, conformit avec dautres architectures, etc.) La seconde approche est devenue un standard de description dun systme logiciel durant ces dernires annes. Avec lunification des mthodes de dveloppement objet
Introduction gnrale approche est largement utilise et bien apprcie dans le monde industriel.
sous le langage UML (Booch et al, 1998 ; Object Management Group, 1997), cette
Les deux approches ont plusieurs points en commun. Elles se basent sur les mmes concepts qui sont labstraction et les interactions entre les entits. En terme darchitecture logicielle en gnral, la similarit entre les deux approches est vidente. En termes dintention, les deux approches ont pour but de rduire les cots de dveloppement des logiciels et daugmenter la production des lignes de codes puisquelles permettent la rutilisation et la programmation base dobjets et/ou composants. Ainsi, en tenant compte des similarits entre ces deux approches, nous rejoignons Garlan (Garlan, 2000b ; Garlan, Cheng, Kompanek, 2002) sur le principe de la rconciliation des besoins des deux approches. Par consquent la tendance actuelle est lutilisation conjointe de ces deux approches pour dcrire les architectures logicielles. Nous voulons profiter de leur cxistence puisque toutes les deux ont en commun, le privilge de dveloppement dun systme afin que chaque paradigme tire profit de lapport de lun et de lautre.
Motivations
Le manque de rutilisabilit est lun des problmes majeurs des systmes informatiques. Il est le rsultat de lincompatibilit des principes architecturaux des composants qui interagissent entre eux. Il devient alors difficile de contrler les interactions et les interconnexions entre composants. Limplmentation peut savrer de plus en plus difficile. Labsence de quelques concepts architecturaux (connecteur, configuration, etc.), ainsi que le non-respect de larchitecture logicielle dans les platesformes dexcution sont les consquences des nouveaux problmes de maintenance et dinteroprabilit. Pour affronter ces problmes, la solution recommande est la dfinition dun profil UML pour larchitecture logicielle, et ensuite lintgration de ce profil dans la dmarche MDA (Frankel, 2003).
Introduction gnrale
Objectifs
Lobjectif de nos travaux est de valider pratiquement larchitecture abstraite COSA (Component Object-based Software Architecture) base sur la description architecturale et la modlisation par objets (Khammaci, Smeda, Oussalah, 2004 ; Smeda, Khammaci, Oussalah, 2004a). COSA est un modle hybride bas sur la modlisation par objets et la modlisation par composants, pour dcrire des systmes logiciels. Cette approche est, emprunte au formalisme des ADLs tendu, grce aux concepts et mcanismes objets. Elle explicite les connecteurs en tant quentits de premire classe pour traiter des dpendances complexes entre les composants.
Contributions
Notre approche se dcline de deux volets : le premier volet concerne la dfinition dun profil UML 2.0 pour COSA. On utilise toutes les capacits des profils UML (mtamodle et modle), pour dfinir une spcification complte pour larchitecture
logicielle. Les profils UML existants sont ddis un type dapplication (systme distribus, temps rel, etc.), alors que le profil dfini dans notre cas, est indpendant de tout systme. Il est spcialis dans une activit particulire de modlisation des langages de description darchitectures. Ce profil permet d'exprimer les concepts architecturaux en UML 2.0 et donc de dfinir de manire formelle les concepts de l'architecture logicielle COSA en utilisant un ensemble de strotypes appliqus des mtaclasses issues du mtamodle UML 2.0. Un tel profil est dfini pour favoriser la rutilisation des architectures logicielles cohrentes et compltes dcrites en COSA. Le deuxime volet porte sur lintgration du profil UML COSA au sein de la dmarche MDA (Frankel, 2003). Nous proposons une stratgie de transformation directe par lutilisation du profil UML llaboration des modles dimplmentations depuis des modles d'architectures ayant un niveau dabstraction haut et un degr de rutilisation celui de COSA.
Introduction gnrale
Organisation de la thse
La suite de cette thse est organise comme suit : Le chapitre 1 est consacr ltude des concepts de base de larchitecture logicielle, suivie dune tude comparative des diffrentes approches. Les concepts de base des langages de description darchitecture et les langages de description darchitecture les plus reprsentatifs, forment le chapitre 2. Ce chapitre, prsente galement une comparaison des principaux ADLs et UML, selon des critres lis la description architecturale. Le modle multi paradigme (COSA), bas sur la modlisation par objets et la modlisation par composants, dcrivant les systmes logiciels est dvelopp dans le troisime chapitre. Il est fait tat galement dans ce chapitre, de larchitecture trois niveaux de COSA pour guider larchitecte dans son processus de modlisation darchitectures logicielles. Le chapitre 4, prsente lintgration du profil UML COSA, dans la dmarche MDA. Le dernier chapitre de cette thse dcrit les ralisations et les exprimentations que nous avons effectues pour le profil COSA UML. La dfinition technique du profil UML 2.0 pour COSA, dvelopp dans ce travail est bien explicite. Le bilan de ce travail, nos contributions et les rsultats obtenus, composent conclusion gnrale, suivie des perspectives futures. la
CHAPITRE 1 Ltat du domaine
Chapitre 1 : Ltat du domaine
1.1 Introduction
Un grand intrt est port au domaine de larchitecture logicielle (Clements, 2003). Cet intrt est motiv principalement par la rduction des cots et les dlais de dveloppement des systmes logiciels. Larchitecture logicielle permet dexposer de manire comprhensible et synthtique la complexit dun systme logiciel et de faciliter lassemblage de pices logicielles. Elle permet en effet au concepteur de raisonner sur des proprits (fonctionnelles et non fonctionnelles) dun systme un haut niveau dabstraction. Une architecture logicielle modlise un systme logiciel en termes de composants et dinteractions entre ces composants. Elle joue le rle de passerelle entre lexpression des besoins du systme logiciel et ltape de codage du logiciel. Enfin, larchitecture logicielle permet dexposer de manire comprhensible et synthtique la complexit dun systme logiciel et de faciliter lassemblage des composants logiciels. Pour dcrire larchitecture logicielle et modliser ainsi les interactions entre les composants dun systme logiciel, deux principales approches ont vu le jour depuis quelques annes : lapproche oriente objet, dite architecture logicielle base dobjets (Jacobson et al. 1992 ; Brinkkemper et al. 1995 ; Booch, 1994 ; Martin 1996) et lapproche oriente composant, appele architecture logicielle base de composants (Garlan, Allen, Ockerbloom, 1994 ; Bass, Kazman, 2001 ; Clements, 2003). Il semble naturel de rapprocher ces deux approches, puisque toutes les deux ont en commun de privilgier le dveloppement dun systme, et ce depuis sa phase de spcification jusqu son implmentation. Bien que chacune delles porte laccent sur des aspects diffrents du dveloppement logiciel en termes de niveaux dabstraction, de granularits et de
mcanismes opratoires. Il ny a pas de frontire trs nette entre les deux. En ce sens, il
nest pas tonnant de retrouver des points communs dans ces deux approches tant au niveau des motivations, des techniques que des mthodes. Les deux approches focalisent la rduction des cots de dveloppement des applications et insistent sur la rutilisation et la performance des produits logicielles. Les dveloppeurs et les concepteurs de systme base de composants sont souvent tents dutiliser les modles objet, comme support de spcification, de conception et dimplmentation (Garlan, 2000a ; Khammaci, Smeda, Oussalah, 2005 ; Medvidovic et al. 2002). Dans ce chapitre, nous prsentons les concepts de base de ces deux approches ainsi que leurs avantages et leurs inconvnients. Nous prsentons galement les points forts des deux approches et ses points communs. Enfin, une brve discussion envers la cxistence de la description base de composants architecturaux et la description oriente objet.
1.2 Approche de modlisation par objet

Les architectures logiciels base dobjets dcrivant les systmes logiciels comme une collection de classes (les entits abstraire et lencapsulation des fonctionnalits) qui peuvent avoir des objets ou instances et communiquent entre eux, via des messages. Avec lunification des mthodes de dveloppement objet sous le langage UML (Unified Modeling Language), cette approche est largement utilise et bien apprcie dans le monde industriel.
1.2.1 Les concepts de base de la modlisation par objet

Le paradigme objet est principalement bas sur lextraction et lencapsulation des caractristiques et des fonctionnalits des classes. Une classe peut tre instancie pour obtenir des objets. Un objet (instance) a des proprits (attributs) et un comportement (mthodes). Les objets des diffrentes classes communiquent par lintermdiaire denvois de messages. La figure 1.1, montre les concepts de base de lapproche objet, que sont les classes, les objets et leurs relations. La figure montre galement quelques mcanismes tels que lhritage et la composition.

Feature Generalization
generalization child 1 1 parent
7
GeneralizableElement
*
specialization
0..1
Class 0..1
participant
association AssociationEnd
1
specification 1
*
speifiedEnd 1
1..*
Interface
1
Association
1..*
Attribute
Method
Operation
0..1
parameter
*
Figure 1.1. Les concepts de base de lapproche objet (extrait dUML 1.1 (OMG, 1997)).
1.2.2 Les langages de la modlisation par objet

La modlisation par objet (OOM : Object Oriented Modeling) est une technique systmatique utilise pour capturer, analyser et dcrire le comportement dun systme. Le comportement est dcrit en terme dobjets qui constituent le systme, sa structure et comment les uns interagissent avec les autres. Ainsi le comportement dcrit aussi bien un objet individuel, que le comportement des objets en interactions. Dans les annes 90, on distinguait trois mthodes Object-Modeling Technique (OMT) de Rumbaugh (Rumbaugh et al., 1991), Object-Oriented Analysis and Design (OOD) de Booch (Booch, 1994), Object Oriented Software Engineering (OOSE) de Jacobson
(Jacobson et al., 1992). Aujourdhui, elles ne donnent pas compltement satisfaction. En 1995, la plupart des notations orientes objets sont unifies et intgres dans le Language de modlisation unifi (UML) (Booch, Rumbaugh, Jacobson, 1998). UML est devenu un langage standard de spcification, de visualisation, de construction et de documentation des systmes logiciels. UML, reprsente une collection des meilleures
pratiques dingnierie ayant un grand succs dans la modlisation des systmes larges et complexes. UML utilise gnralement des notations graphiques pour reprsenter les aspects structurels, dynamiques et fonctionnels dun systme logiciel. Mais, la notation graphique est intrinsquement limite lors de la spcification des contraintes complexes. Donc, UML dcrit un ensemble de contraintes en langage naturel, et laide du langage OCL (Object Constraint Language (Warmer, Kleppe, 1998)). Ces contraintes peuvent tre dfinies au niveau du mta-modle comme au niveau du modle. OCL permet une conception riche et correcte. Finalement, avec lapparition de la dernire version dUML (UML 2.0 (Object
Management Group, 2004a)), UML improuve la dfinition des composants et ses interfaces par lintroduction de la notion des ports et la sparation des services fournis des services requis dun composant. Mais, UML 2.0 dfinit toujours implicitement les interactions entre les composants (les interactions en UML 2.0 sont les proprits des composants) et nintroduit pas la notion du connecteur comme entit de premire classe.
1.3 Approche de modlisation par composants

La modlisation base de composants architecturaux permet aux dveloppeurs de faire abstraction des dtails dimplmentation, de se concentrer sur des lments de plus haut niveau comme les diffrentes vues et structures des systmes complexes et de raisonner sur leurs proprits (protocole dinteraction, conformit avec dautres architectures, etc.) (Medvidovic, Taylor, 2000). Cette approche dcrit un systme comme un ensemble de composants (unit de calcul ou de stockage) qui interagissent entre eux par le biais de connecteurs (units dinteractions). Leurs objectifs consistent rduire les cots de dveloppement, amliorer des modles, faire partager des concepts communs aux utilisateurs et enfin construire des systmes htrognes base de composants rutilisables sur tagres (COTS, commercial off the shelf).
Larchitecture logicielle base de composants (composants architecturaux) (Kazman et al. 2001 ; Clements, 2003) dcrit les systmes logiciels comme un ensemble de composants (encapsulation des fonctionnalits) qui interagissant entre eux par
lintermdiaire des connecteurs (encapsulation de communication), comme indiqu dans la figure 1.2. Configuration Rle - Requis Composant Port - Fourni Connecteur
Glue
Rle - Fourni Composant Port - Fourni
Figure 1.2. Description architecturale des systmes base de composants. Pour asseoir le dveloppement des architectures base de composants, plusieurs
langages de description (ADL : Architecture Description Language) ont t proposs. Les ADLs offrent un niveau dabstraction lev pour la spcification et le dveloppement des systmes logiciels, qui se veut indpendant des langages de programmation et de leurs plateformes dexcution. Dans le dveloppement base de composants Component-Based Software Engineering (CBSE) (Hasselbring, 2002), il y a beaucoup davantages. On inclut la rutilisation des modles, le partage des concepts communs aux utilisateurs de systme et la rduction des cots de dveloppement.
1.3.1 Les concepts de base de modlisation par composants

1.3.1.1 Dfinitions notables Le concept composant, est n dans le vocabulaire informatique depuis la naissance du gnie logiciel. Il a cependant dsign dabord des fragments de code, pour englober ensuite toute unit de rutilisation (Barbier et al. 2004). A lheure actuelle, il nexiste toujours pas de dfinition 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 dfinitions.
10
Une dfinition trs populaire de larchitecture logicielle a t avance par Garlan et Shaw (Garlan et Shaw, 1993). Garlan et Shaw ont propos quune architecture logicielle pour un systme spcifique soit reprsente comme un ensemble de composants de calcul - ou tout simplement de composants - accompagn dune description des interactions entre ces composants - les connecteurs. A lorigine, lapproche par composants a t fortement inspire des composants de circuits lectroniques. Lexprience gagne dans cette discipline a largement contribu aux ides de composants et de rutilisation. Concernant les composants lectroniques, il suffit de connatre leur principe de fonctionnement et la faon dont ils communiquent avec leur environnement (tensions dentre, de sortie,) pour construire un systme complet sans pour autant dvoiler les dtails de leur implmentation. Comme le souligne Cox (Cox 86), lide de circuits logiciels intgrs conduit la notion dlments logiciels qui peuvent tre connects ou dconnects dun circuit plus complexe, remplacs et/ou configurs. Les constructeurs dapplications adoptent de plus en plus cette dmarche. Il sagit, de composer des composants logiciels de nature trs diverses pour construire une application. On ne parlera alors plus de programmation dapplications mais plutt de composition dapplications. Aujourdhui le dveloppement dapplications base de composants constitue une voie prometteuse. Pour rduire la complexit de ce dveloppement et le cot de maintenance, et accrotre le niveau de rutilisablilit, deux principes fondamentaux doivent tre respects : Acheter plutt que Construire et Raliser plutt quAcheter (Mcllroy, 1968). Le concept de rutilisation de composant logiciel a t introduit par McIlroy en 1968 (Mcllroy, 1968) dans un confrence de lOTAN consacr la crise du logiciel suite un chec patent de la part de dveloppeurs pour livrer des logiciels de qualit temps et prix comptitif. Lide est de mettre en place une industrie du logiciel pour accrotre la productivit des dveloppeurs et rduire le temps de mise sur le march (time-to-maket). Pour ce faire, les dveloppeurs construisant des applications partir de composants logiciels sur tagre (COTS, Commercial off the shelf) plutt que de crer partir de rien (from scratch). Ainsi, la construction dapplications pourrait se faire dune manire plus
11
rapide en assemblant des composants prfabriqus. La popularit croissante des technologies logicielles base de composants, linstar des technologies objets, est entrain de sinstaller et de se propager auprs de millions de programmeurs. Les nouvelles technologies logicielles adoptent de plus en plus le concept de composant comme cl de vote de la rutilisation pour construire rapidement des applications. Parmi ces technologies, nous pouvons citer : ActiveX, OLE, DCOM (Rubin, Brain, 1998), .NET de Microsoft (Grim, 1997), EJB de SUN (Roman et al. 2004), CORBA (Common Object Request Broker Architecture) de lOMG (Baker, 1997). Elles permettent dutiliser des composants et des objets forte granularit, distribus et complexes. Cependant, plusieurs questions se posent ds quon aborde la problmatique des composants. Par exemple : quelle est la dfinition dun composant ? Sa granularit ? Sa porte ?
Comment peut-on distinguer et rechercher les composants de manire rigoureuse ? Comment peut-on les manipuler ? Les assembler ? Les rutiliser ? Les installer dans des contextes matriels et logiciels variant dans le temps, Les administrer, Les faire voluer ? etc. Le but de cette section est dapporter les notions de base ncessaires la comprhension du paradigme de composants pour enfin caractriser leurs proprits. 1.3.1.2 Les concepts de la description architecturale Les concepts et les notations de lapproche de description darchitecture logicielle (composants architecturaux) sont similaires aux notations de modlisation base dobjets. Aussi il y a une diversit considrable dans les capacits des diffrentes ADLs, qui se partagent les mmes concepts de base et qui dterminent les mmes fondations des concepts pour la description darchitecture logicielle. Les concepts essentiels de cette approche sont : Les composants sont dfinis comme des units de calcul ou du stockage pour lesquelles est associe une unit d'implantation. Un composant dans une architecture peut tre aussi petit qu'une procdure simple ou aussi grande qu'une application entire. Il peut exiger ses propres donns et/ou des espaces d'excution comme il peut les partager avec d'autres composants. La plupart des systmes base de composants
12
peuvent avoir plusieurs interfaces : chaque interface dfinit un point dinteraction entre un composant et son environnement. Les connecteurs reprsentent les interactions entre les composants et les rgles qui rgissent ces interactions correspondent aux lignes dans les descriptions de type "boites-et-lignes". Ce sont des entits architecturales qui lient des composants
ensemble et agissent en tant que mdiateurs entre elles. Les exemples de connecteurs incluent des formes simples d'interaction, comme des pipes, des appels de procdure, et l'mission d'vnements. Les connecteurs peuvent galement reprsenter des
interactions complexes comme un protocole Remote Procedure Call (RPC) de clientserveur ou un lien de SQL entre contrairement aux composants. Les interfaces dun composant sont des points de communication qui lui permettent dinteragir avec son environnement ou avec dautres composants. Les proprits reprsentent les informations smantiques des composants et de leurs interactions. Les contraintes reprsentent les moyens permettant un modle darchitecture de rester valide durant toute sa dure de vie et de prendre en compte lvolution et le remplacement des composants logiciels dans cette dernire. Ces contraintes peuvent inclure des restrictions sur les valeurs permises de proprits, sur lutilisation dun service offert par un composant et garantir la validit des rsultats retourns par ce service. Les configurations architecturales reprsentent les graphes de composants et de connecteurs et la faon dont ils sont relis entre eux. Cette notion est ncessaire pour dterminer si les composants sont bien relis, si leurs interfaces saccordent, si les connecteurs correspondants permettent une communication correcte. La combinaison de leurs smantiques aboutit au comportement dsir, qui vient en appui des modles de composants et de connecteurs. Les descriptions des configurations permettent lvaluation des aspects distribus et concurrents dune architecture, comme par exemple, la possibilit de dterminer des verrous, de connatre le potentiel de une base de donnes et une application
13
performance, de fiabilit, de scuritetc. Le rle cl des configurations est de faciliter la communication entre les diffrents intervenants dans le dveloppement dun systme. Leur but est dabstraire les dtails des diffrents composants et connecteurs. Ainsi, elles dcrivent le systme un haut niveau dabstraction qui peut tre potentiellement compris par des personnes avec diffrents niveaux dexpertise et de connaissances techniques. La composition/assemblage permet de construire des applications complexes partir de composants simples. La composition ou assemblage permet de lier un composant demandant des services dautres composants offrant ces dits services. Les styles architecturaux sont des aspects intressants, mme sils ne sont prsents que dans certains systmes base de composants (Garlan, 2000b). Le choix dun style architectural permet de : 1. dterminer lensemble des vocabulaires dsignant le type des entits de base (composants et connecteurs). 2. spcifier lensemble des rgles de configuration qui dterminent les compositions et les assemblages, permis entre ces lments. 3. donner la smantique de configuration. Exemple : un systme multi -agents communiquant via un tableau de bord, signifie que ces agents des connaissances. 4. dterminer les analyses qui peuvent tre ralises sur un systme construit selon un tel style. Par exemple : vrification de la causalit dans un systme distribu bas sur la communication par vnement. 1.3.1.3 Les trois dimensions dun composant Un composant peut tre de deux natures : produit : il sagit dune entit building block autonome passive (entit logicielle ou entit conceptuelle) quil est possible dadapter. Les composants logiciels et les bibliothques de fonctions mathmatiques en font partie. processus : un composant processus correspond une suite dactions quil faut rutiliser pour obtenir un produit final. Ces actions sont souvent encapsules dans un partagent
14
processeur (unit de traitement). Un composant processus possde en gnral des fragments de dmarche. Au regard des travaux existants un composant produit ou processus doit reflter les trois dimensions qui sont le niveau dabstraction, le mode dexpression et le domaine (cf. figure 1.3) (Oussalah, Khammaci, Smeda, 2005). La premire dimension ou niveau dabstraction permet dexprimer les degrs de raffinement dun composant et ce depuis sa spcification. Elle est considre comme tant le plus haut niveau dabstraction. Son code source reprsente le plus bas niveau. Chaque niveau dabstraction peut lui tre associ un niveau de transparence qui dfinit le niveau de visibilit des dtails internes dun composant lors de sa/son (r) utilisation. Le niveau de transparence dun composant peut tre de type : bote noire : linterface du composant fait abstraction de son implmentation. Linteraction avec lextrieur se fait uniquement travers linterface utilisateur. Ce qui permet de donner la possibilit de remplacer un composant par un autre, ralise par loffre de la mme interface. bote blanche : le composant rend transparent tous les dtails de limplmentation. Linteraction avec lextrieur peut se raliser non seulement travers linterface du composant mais aussi travers son implmentation. Ce type de composant, a lavantage de fournir toute linformation relative son implmentation. bote grise : il sagit dun niveau de transparence intermdiaire entre les composants de type bote noire et bote blanche. Si les dtails dimplmentation peuvent tre
rvls pour comprendre la ralisation du composant, ils ne peuvent pas tre sujet des modifications manant de lextrieur : linteraction se fait uniquement linterface. La deuxime dimension ou mode dexpression permet de dcrire les diffrents modles de reprsentation dun composant (reprsentation textuelle, graphique, flot de donnes, implmentation). La description dun composant doit tre simple, comprhensible avec une smantique pas ncessairement dfinie de manire formelle mais au moins claire. En effet, les participants llaboration de composants (concepteurs, dveloppeurs, utilisateurs, managers) peuvent requrir diffrents modes dexpression. travers
CHAPITRE 1 Ltat du domaine Mode dexpression

Implmentation Processus
15
Flot de contrle Flot de donnes Graphique Texte
Mon domaine Domaine connexe Tout domaine
Spcification Architecture Architecture Haut-niveau dtaille
Code
Niveau dabstraction
Domaine
Figure 1.3. Les trois dimensions dun composant.
Les utilisateurs peuvent se contenter dune description graphique de haut niveau (type bote et flche). Les dveloppeurs voudront dtailler par exemple les modles de connecteurs et de composants, alors que les managers peuvent requrir une vue du processus de dveloppement. Le mode dexpression dun composant dpend galement de sa granularit. La notion de granularit de composant recouvre, selon les langages de reprsentation, aussi bien des units atomiques telles que les structures de donnes, les fonctions mathmatiques ou de vritables structures composes dlments et de liens. Du point de vue de la granularit, nous pouvons citer : les composants dits simples ou de fine granularit sont directement lis une construction syntaxique du langage de dveloppement exprime souvent laide dun langage dimplmentation comme les classes en programmation objet, les packages en programmation Ada ou des fonctions dans la programmation usuelle. les composants granularit moyenne sont les composants logiciels utiliss dans la production du logiciel ou les patrons de conception sont souvent exprims de faon textuelle ou graphique.
16
les composants dits complexes ou forte granularit, sapparentent une vritable structure complexe comme les infrastructures logicielles (frameworks), les systmes dexploitation, les serveurs ou les blackboard. La troisime dimension (domaine) reflte les diffrents domaines structurs en couches sur lesquels repose un systme donn. Cette structuration permet un composant appartenant un domaine particulier, de ne pouvoir interagir, quavec seulement les composants de la mme couche ou de la couche adjacente. Les composants du Tout Domaine constituent la couche du plus bas niveau. Ils sont indpendants du domaine dapplication, comme par exemple le cas de systmes, de compilateurs, de base de donnesetc. Au niveau plus haut Domaine connexe , on trouve des composants appartenant des domaines connexes de lapplication en cours de construction, comme par exemple les interfaces utilisateurs, les simulateurs, ...etc. Enfin en haut de la hirarchie, les composants de Mon Domaine sont spcifiques au domaine dapplication choisi, par exemple les composants de circuits intgrs. Il est clair, que le nombre de couches de domaines nest pas fig et dpend de la maturit des domaines dapplication, en gnral. Enfin, cette troisime dimension caractrise la porte des composants, soit leur degr de rutilisabilit. Nous pouvons recenser dans la littrature : Les composants gnriques ou indpendants dun domaine : ce sont des composants gnraux qui ne dpendent pas dun domaine particulier, les objets graphique, les patrons de conception de Gamma et al. (Gamma et al. 1995) et les types de donnes abstraits sont des exemples de ce type de composants, Les composants mtiers ou dpendants du domaine : le concept de composant mtier rsulte de celui dobjet mtier. Les composants mtiers sont des composants rutilisables travers les applications dun mme domaine, Les composants orients applications : ce sont des composants spcifiques une application donne. Ils ont peu rutilisables. Ce type de composants est gnralement engendr par des rutilisations ad hoc non planifies.
17
1.3.2 Les langages de modlisation par composants

Les langages de description d'architecture sont des langages formels qui peuvent tre utiliss pour reprsenter l'architecture d'un systme logiciel. L'architecture joue un rle important dans les systmes de dveloppement et d'acquisition. Dans les dernires dcades, la communaut de recherche en architecture logicielle propose plusieurs formalismes de description darchitecture que lon appelle les langages de description darchitectures (en anglais ADL : Architecture Description Language) pour spcifier la structure et le comportement des architectures logicielles. Malheureusement, il y a plusieurs ADLs et aucun signe nindique que ces ADLs convergent vers une notation standard pour spcifier leurs architectures. Les plus connus de ces langages sont : Aesop (Garlan, Allen, Ockerbloom, 1994), Rapide (Luckham et al. 1995), Unicon (Shaw, DeLine, Zelesnik, 1996), C2 (Taylor, 1996), Darwin (Magee, Karmer, 1996), Wright (Allen, Garlan, 1997 ; Allen, Douence, Garlan, 1998), ACME (Garlan, Monroe, Wile, 2000), COSA (Khammaci, Smeda, Oussalah, 2004). Les ADLs proposent des notations formelles pour dcrire les concepts de la description architecturale et permettent une analyse rigoureuse des architectures.
1.4 Similarit entre la modlisation base dobjets et la modlisation base de composants

La modlisation base dobjets et la modlisation base de composants ont plusieurs concepts en commun. Ces deux approches se basent sur les mmes concepts, qui sont labstraction et linteraction des composants. Dans les descriptions darchitectures logicielles base de composants, les composants et les connecteurs sont les concepts de base de description des systmes logiciels. Les composants sont des abstractions qui contiennent des fonctionnalits de stockage de donnes dans des blocs rutilisables alors que les connecteurs dfinissent des abstractions qui englobent les mcanismes de communication, de coordination et de conversion entre les composants (Smeda, Khammaci, Oussalah, 2004a ; Alti, Khammaci, 2005). Dautre part les descriptions darchitectures logicielles base dobjets, les classes sont des abstractions des donnes, et les fonctions serves comme des interfaces daccs ces donnes.
18
En gnral, en terme darchitecture, la similarit entre deux domaines est vidente. En terme dintention, les deux approches favorisent : la rduction des cots de dveloppement des applications, la programmation base de composants, la rutilisation (Perry, Wolf, 1992 ; Shaw, Garlan, 1996).
Les deux approches ont permis aux dveloppeurs de faire abstraction des dtails dimplmentation, afin de se concentrer sur des lments de plus haut niveau comme les diffrentes vues et structures de systmes informatiques (Medvidovic, Taylor, 2000).
1.4.1 Avantages et inconvnients de la modlisation base dobjets

Les modles base dobjets prsentent plusieurs avantages : ils sont familiers une large communaut dingnieurs et de dveloppeurs du logiciel, ils se basent sur des mthodologies bien dfinies pour dvelopper des systmes partir dun ensemble de besoins, ils sont supports par des outils commerciaux, ils fournissent plusieurs vues (structuraux et comportementaux) de description des systmes, ils prsentent le langage UML comme un standard des notations unifies de plusieurs notations des modlisations orientes objets, ils fournissent souvent une correspondance directe de la spcification limplmentation. Cependant, force est de constater que lapproche objet souffre dun certain nombre de lacunes par rapport aux systmes base de composants. Nous en donnons les plus significatives : lapproche objet a montr des limites importantes en terme de granularit et dans le passage lchelle. Le faible niveau de rutilisation des objets est d en partie au fort couplage des objets. En effet, ces derniers peuvent communiquer sans passer par leur interface, la structure des applications objets est peu lisible (un ensemble de fichiers),
19
la plupart des mcanismes objets sont grs manuellement (cration des instances, gestion des dpendances entre classes, appels explicites de mthodes,)
Par ailleurs, les approches objets : spcifient seulement les services fournis par les composants dimplmentation mais ne dfinissent en aucun cas les besoins requis par ces composants, ne fournissent pas (ou peu) de support directe pour caractriser et analyser les proprits non-fonctionnelles, proposent peu de solutions pour faciliter ladaptation et lassemblage dobjets, prennent en compte difficilement les volutions dobjets (ajout, suppression, modification, changement de mode de communication,) Il y a peu ou pas doutils pour dployer (installer) les excutables sur les diffrentes sites, Enfin, les modles objets : ne sont pas adapts la description de schmas de coordination et de communication complexes. En effet, ils ne se basent pas sur des techniques de construction dapplications qui intgrent dune certaine faon lhomognit des entits logicielles provenant de diverses sources, disposent de faibles supports pour les descriptions hirarchiques, rendant difficile la description de systmes diffrents niveaux dabstraction, permettent difficilement la dfinition de larchitecture globale de systme avant la construction complte (implmentation) de ses composants. En effet les modles objets exigent limplmentation de leurs composants avant que larchitecture ne soit compltement dfinie, ne permettent pas facilement la recherche des relations dinteractions dans une architecture (surtout de pointeurs et autres) et requirent forcment linspection de tout le systme, ne fournissent pas un support direct de dfinition des proprits non fonctionnelles danalyse et de vrification des systmes,
20
ne supportent pas la dfinition des styles architecturaux qui facilite la conception des domaines spcifiques et lanalyse des proprits des systmes.
1.4.2 Avantages et inconvnients des modles base de composants

Les modles base de composants prsentent plusieurs avantages : les interfaces sont en gnral des entits de premire classe dcrites explicitement par des ports et des rles, les interactions sont spares par des calculs (sparation de proccupations) et explicitement dfinies dans la plupart des ADLs (Medvidovic, Taylor, 2000), les connecteurs sont des entits de premire classe. Ils sont dfinis explicitement par la sparation de leurs interfaces et de leurs implmentations via les ports et les rles. En effet, les connecteurs permettent de dcrire des communications, et prennent plusieurs formes complexes comme un nouveau mcanisme dintgration des composants (Garlan 2000b ; Shaw, Garlan, 1996), les proprits non fonctionnelles sont prises en compte comme la performance, la scurit, la portabilit, la conformit aux standards et le partage, utiles lanalyse des systmes, les reprsentations hirarchiques sont smantiquement plus riches que de simples relations dhritage. Elles permettent, par exemple, les reprsentations multiples dune architecture (Garlan 2000a), Ils supportent lassociation plus de modles dtaills dans une partie individuelle dune architecture, Ils dfinissent des styles architecturaux la base dun vocabulaire de conception et de spcialisation de description des architectures spcifiques. Aussi, un
ensemble des contraintes dutilisation de ces vocabulaires, Ils permettent facilement la dfinition de larchitecture globale de systme avant la construction complte (implmentation) de ses composants. Les modles base de composants prsentent des avantages comme ils prsentent des inconvnients: ils sont connus seulement par les communauts acadmiques,
21
ils ne supportent pas plusieurs vues. En effet, ces vues sont trs importantes puisque diffrents aspects de systme (i.e. comportement envers structural) requirent diffrents besoins de description,
ils se basent sur diffrentes notations et plusieurs approches quelques fois ambigues,
ils ne fournissent pas souvent une correspondance directe, entre la spcification et limplmentation,
fournit seulement les modles niveau lev, sans expliciter comment ces modles peuvent tre relis au code source. Comme le souligne Garlan (Garlan 2000a), de telles liaisons sont importantes pour prserver lintgrit de la conception.
1.4.3 Similarits et diffrences en terme de concepts de base

Le tableau 1.1 montre les similarits et les diffrences entre la modlisation base dobjets et celle base de composants en terme de concepts de base (Khammaci, Smeda, Oussalah, 2005).
1.5 Cxistence des deux modlisations pour la description de larchitecture logicielle

A partir de la comparaison de la section prcdente, entre lapproche base dobjets et celle base de composants, on peut noter que chaque approche a ses avantages et ses inconvnients et chacun deux a ses propres caractristiques.
Concepts de base Entits dencapsulation des fonctionnalits Entits dencapsulation de communication Communication interentitis Structure du systme Interface Proprits Oriente - composant Composant Connecteur Ports et rles Systmes et reprsentation Interfaces des composants et connecteurs Fonctionnelles et non fonctionnelles Classe Mthode Envoi de messages Programme et package Interfaces des classes Attributs (non fonctionnels) Oriente - objet
Table 1.1. Les concepts de base des deux approches.
22
La question quon peut se poser est : Quelle est la meilleure manire de cxistence entre ces deux approches ? Plusieurs travaux ont t raliss sur la cxistence des deux approches (Egyed, Krutchen, 1999 ; Hofmeister, Nord, Soni, 1999 ; Selic, Rumbaugh, 2000 ; Garlan, Cheng, Kompanek, 2002 ; Kruchtan, Selic, Kozaczynski, 2001 ; Medvidovic et al. 2002 ; Smeda, Khammaci, Oussalah, 2004a). Nous prsentons dans cette section quelques perspectives pour rpondre cette question. La premire se concentre sur les aspects comportementaux des architectures (interaction et contraintes), la deuxime, sur les aspects structuraux des architectures (composants, connecteurs, etc.), la troisime sur les vues de modlisation des architectures logicielles et la dernire perspective focalise sur les mcanismes oprationnels des architectures logicielles.
1.5.1 La modlisation base de composants utilisant la modlisation base dobjets

Dans cette perspective, on se base sur la possibilit dutiliser UML (Unified Modeling Language) (Booch, Rumbaugh, Jacobson, 1998) comme un point de dpart dintgration de la description des architectures logicielles ou composantes architecturaux dans le monde industriel (Medvidovic, Taylor, 2000). Le principal but de cette tude est dexploiter la capacit dexpressivit dUML la modlisation des architectures logicielles avec les techniques des modlisations base de composants. Dans ce contexte, les auteurs ont dfini des critres dvaluation et dadaptation dUML pour reprsenter effectivement larchitecture logicielle (Medvidovic, Taylor, 2000). Ces critres sont : 1. UML doit tre bien adapt pour modliser les aspects structuraux dun systme. 2. UML doit capturer les varits stylistiques dcrites explicitement ou implicitement par les ADLs. 3. UML doit modliser tous les aspects comportementaux dun systme qui sont fournis par la plupart des ADLs. 4. UML doit tre capable de modliser les aspects des paradigmes dinteraction des composants.
23
5. UML doit tre capable de capturer les contraintes de violation de la structure, le comportement, linteraction et le style. Pour modliser des architectures logicielles, trois stratgies sont possibles: 1. Utilisation UML tel quil est . 2. Utilisation des mcanismes dextensibilit. 3. Augmentation du mta - modle UML pour supporter directement les besoins des composants architecturaux. Chaque stratgie a ses avantages et ses inconvnients. Lvaluation des trois stratgies nous permet dliminer la troisime car la nouvelle version dUML devient de plus en plus complexe. Ceci un impact sur la facilit dutilisation de ce langage : la nouvelle version dUML perd son caractre standard et devient par consquent, incompatible avec les ateliers UML existants. 1.5.1.1 UML : langage de description darchitectures Lintrt principal de lutilisation dUML, comme modlisation des architectures logicielles dcrites par les ADLs, consiste en une comprhension universelle de cette dite modlisation. De plus, une telle modlisation peut tre manipule par des ateliers UML, supportant les tapes de dveloppement suivantes: expression des besoins,
conception et implmentation. Cette stratgie consiste utiliser les notations offertes par UML pour reprsenter les concepts architecturaux des ADLs tels que composants, connecteurs, rles, ports et configurations. Pour dmontrer cette stratgie, Medvidovic et al. ont utilis la norme UML1.x pour modliser les ADLs (C2, Wright et Rapide) (Medvidovic et al. 1996; Medvidovic et al. 2002). Cependant, pour deux raisons, cette stratgie ne satisfait pas compltement tous les besoins structuraux de description darchitecture: UML ne fournit pas des notations spcifiques pour les artfacts de la
modlisation architecturelle. Les rgles dun style darchitecture donne, refltent celle dun ADLs.
24
1.5.1.2 Extensibilit dUML pour modliser la description darchitectures UML est un langage de modlisation gnrique pouvant tre adapt au domaine darchitecture logicielle grce aux mcanismes dextensibilit offerts par ce langage, tels que, les strotypes, les valeurs marques et les contraintes. Les extensions UML ciblant un domaine particulier forment des profils UML. Les mcanismes dextensibilit offerts par UML permettent dtendre UML sans modifier son mtamodle. Medvidovic et al. (Medvidovic et al. 2002), proposent dutiliser des extensions dUML (strotypes, valeurs marques, contraintes) pour incorporer les concepts de trois langages de description darchitectures (C2, Wright et Rapide). Dans (Goulao, Abreu, 2003), les auteurs tablissent un profil UML2.0 pour lADL ACME. Ils regroupent des concepts minimaux et communs tous les ADLs. Les travaux de (Roh, Kim, Jeon, 2004),
signalent quelques faiblesses lies notamment la reprsentation propose du connecteur (au sens dADL) en UML2.0 et proposent un ADL gnrique sous forme dun profil UML 2.0. Dans ce travail, on note notamment lutilisation des collaborations UML 2.0 pour reprsenter des connecteurs ADL. De plus, un autre aspect intressant se dgage : type et instance de connecteur sont modliss par deux strotypes. En effet, le type de connecteur est dfini comme un strotype base de mtaclasse Collaboration dUML 2.0. Linstance du connecteur est dfinie comme un strotype base de mtaclasse Connector dUML.
1.5.2 Slection de notations UML pour reprsenter les descriptions darchitectures

Selon Garlan et al. (Garlan, Cheng, Kompanek, 2001), une autre perspective de cxistence de la description darchitecture logicielle et de la modlisation oriente objet, est la slection de notations UML pour reprsenter des lments architecturaux. Lvaluation de chaque slection est propose ensuite. On distingue, quatre stratgies de reprsentation des principaux concepts architecturaux en UML1.x. Ces dernires se focalisent autour de la reprsentation des types de composants et des instances de composants en UML1.x. Les auteurs proposent les alternatives suivantes :
25
classes et objets : les types de composants sont reprsents par des classes UML1.x et les instances de composants par des objets.
classes et classes : les types de composants et les instances de composants sont reprsentes par des classes.
Types et instances de composants: les types de composants sont reprsents par des types de composants UML1.x et les instances de composants par des instances de composants UML1.x.
Types et instances de subsystems : les types de composants sont reprsents par des subsystems UML et les instances de composants par des instances de subsystems.
UML-RT (Selic, 1999) est une variante particulire de ces stratgies, base sur limplantation des concepts ADL vers UML-RT (Cheng, Garlan, 2001). Cette tude illustre bien que chaque slection de ces quatre est mrite. Mais, il se trouve quaucun deux nest capable de supporter les besoins darchitectures en termes de correspondance smantique, de comprhension et de compltude.
1.5.3 Reprsentation des vues architecturales en UML

Cest dans cette perspective, que les auteurs se sont orients vers la reprsentation des modles de vues des architectures logicielles. Krutchen (Kruchten, 1995) prsente le modle 4+1 vues des architectures logicielles. Les quatre principaux vues sont de type : logique, processus, dveloppement et physique. Ces vues permettent de mieux capturer larchitecture du systme logiciel. Dans (Soni, Nord, Hofmeister, 1995), les auteurs identifient les quatre catgories structurales de larchitecture logicielle, conceptuelle, module dinterconnexion, excution et code. Les diffrentes vues visent diffrents aspects dingnierie. La sparation de ces aspects aide larchitecte prendre une dcision sur la conception architecturale. Chaque vue a ses lments de description. Une vue conceptuelle dcrit des lments en termes de domaine. Une vue du modle dinteraction raffine la vue conceptuelle, elle fournit des fonctions et des couches dcompositionnelles du systme. Les vues dexcution et le code correspondent aux vues structurelles et dynamiques de Krutchen respectivement. Dans (Hofmeister, Nord, Soni, 1999). Ces auteurs concluent quUML est insuffisant la description des aspects
26
dynamiques dune architecture et des squences dactivits. Par contre, UML est mieux adapt pour dcrire une structure statique dune architecture, une variante des configurations conceptuelles et des squences dactivits spcifiques.
1.5.4 Combinaison de la modlisation base de composants et base dobjets

Dans cette perspective, nous pouvons citer les travaux sur la prise en compte de mcanismes oprationnels par les composants architecturaux. Ce travail a abouti la proposition de lapproche COSA (Component Object Software Architecture) qui combine des concepts issus des composants architecturaux et des concepts inhrents lapproche objet, et qui bnficie des qualits de chacune des deux approches (Smeda, Khammaci, Oussalah, 2004a ; Smeda, Khammaci, Oussalah, 2004b) permet de mieux dcrie larchitecture dun systme logiciel. Il dcrit un systme comme une collection des composants qui interagissent entre eux par lintermdiaire des connecteurs. Dans COSA, les composants et les connecteurs sont dfinis comme des entits de premire classe et empruntent des mcanismes oprationnels issus des systmes objets. Cette approche distingue explicitement la notion de calcul de la notion de communication. Elle spare linterface de connecteur (rle) de son comportement (glu). La glu dcrit les fonctionnalits attendues, reprsentes par les parties en interactions. La contribution principale de cette perspective est, dune part demprunter le formalisme des ADLs et de les tendre grce aux concepts et mcanismes oprationnels objets, et dautre part dexpliciter les connecteurs en tant quentits de premire classe pour traiter les dpendances complexes entre les composants.
1.6 Conclusion
Pour reprsenter, les systmes logiciels complexes de manire architecturale, des notations expressives simposent. Les notations orientes objets (UML) et les notations spcifiques des langages de descriptions darchitectures (ADLs) sont les deux approches de description des architectures logicielles des systmes complexes, quon retient. Ces deux approches de description des architectures logicielles :
27
Lapproche oriente objet base sur de construction logicielle depuis des entits encapsules dfinissant des interfaces fournit un ensemble des services.
Lapproche oriente composant, fournit les composants et les connecteurs qui comme concepts cls de description des systmes logiciels.
On peut conclure que la cxistence de qualit des deux approches est sans aucun doute profitable pour la description de larchitecture logicielle. Sa modlisation
ncessite absolument, lutilisation de langages spcifiques ddis, qui font lobjet du chapitre suivant.
CHAPITRE 2 Les langages de modlisation darchitecture
28
Chapitre 2 : Les langages de modlisation darchitecture : concepts et outils de support
2.1 Introduction
Larchitecture logicielle occupe une position centrale dans le processus de dveloppement des systmes complexes. Vu le rle important que larchitecture joue dans le dveloppement de systmes complexes, il est devenu indispensable de disposer des mthodologies formelles ou semi-formelles et de bnficier doutils de support pour valider et analyser les modles. La description de larchitecture logicielle est fonde sur deux techniques de modlisation : la modlisation darchitecture logicielle base de composants (composants architecturaux) dcrite par les ADLs (Architecture Description Languages) (Clements et al. 2002 ; Medvidovic, Taylor, 2000) et la modlisation oriente objet utilisant le langage UML (Unified Modeling Language) (Jacobson et al. 1992 ; Booch, Rumbaugh, Jacobson, 1998 ; Object Management Group, 2001). Les deux techniques de modlisation sont dites, successivement Object-Based Software Architecture (OBSA) et Component-Based Software Architecture (CBSA) (Khammaci, Smeda, Oussalah, 2005). Ces langages de modlisation darchitectures permettent la formalisation des architectures logicielles, la rduction du cot et laugmentation de la performance du systme logiciel ainsi que la comprhension des gros logiciels en les reprsentants un niveau dabstraction lev. Dans ce chapitre, nous prsentons les langages de description darchitectures les plus connus comme : Wright, Acme, Darwin, Archjava, Fractal et ses outils de support. On introduit ensuite, les langages de modlisation par objets les plus complets qui
actuellement, sont devenus un standard de facto dans le monde industriel : UML, en
29
particulier avec la version UML 2.0 (Object Management Group, 2004a ; Pilone, Pitman, 2005). On termine avec le standard XMI, qui permet de reprsenter les modles
darchitectures sous forme XML, et qui favorisent leurs changes et leurs prennits.
2.2 Dfinitions
Nous nous intressons dans cette section aux concepts darchitecture logicielle. Lobjectif nest pas de proposer une nouvelle dfinition ni de comparer les dfinitions proposes, mais plutt de sinterroger sur les concepts eux-mmes.
2.2.1 Architecture logicielle

Une architecture logicielle est dfinie comme un niveau de conception qui contient la description des composants partir desquels un systme est construit, les spcifications comportementales de ces composants, les modles et les mcanismes de leurs interactions (connecteurs) et enfin un modle dfinissant la topologie (configuration) dun systme. La figure 2.1, prsente un mtamodle montrant les concepts de base des architectures logicielles ainsi que leurs relations.
2.2.2 Composant
Un composant est une entit de calcul ou de stockage de donnes spcifiant, par contrat, ses interfaces (fournies et requises). Un composant logiciel peut tre dploy indpendamment et peut tre sujet de composition par un tiers pour la conception dapplications logicielles (Garlan, Taylor, 1997).
"A Software component is a unit of computation with contractually specified interfaces. A Software component can be deployed independently and is subject to composition by third parties".
De cette dfinition, il rsulte que : Un composant est une unit de composition spcifiant, par contrat, ses interfaces (fournies et requises),

Contrainte Style 1 1 1 compos de 1..* 1 Composant 1 0..* 1 1 1 compos de compos de 1 1 Interface 0..* Liaison 0..1 1 Port 0..1 Attachment Port-Fourni Port-Requis Rle-Fourni Rle-Requis 0..1 Rle Liaison 1 0..1 compos de compos de 1 1 1 0..* 1 1 compos de 0..* 1 Connecteur 0..* 1 Configuration 1
30
Proprit
Figure 2.1. Les concepts de base des langages de description darchitectures. Un composant logiciel peut tre dploy indpendamment (installation sur diffrentes composants), Un composant peut tre typ, et peut avoir une smantique formelle ou informelle. Il peut exporter des contraintes dutilisation et prsenter des proprits fonctionnelles ou non fonctionnelles. Un composant logiciel possde, principalement, les trois lments suivants : Linterface : est la partie visible dun composant. Linterface dun composant consiste en un ensemble de points dinteraction entre le composant et son environnement qui permettent linvocation des services. Dans les approches objets, les services sont spcifis comme des mthodes, puis comme interface de communication, construite pour encapsuler ces services. Cette interface constitue dun ensemble de ports munis dune sensibilit, attachs un service qui dfinit le comportement raliser lors de plates-formes, collaboration et coopration avec dautres
31
son invocation. Deux types de ports peuvent tre distingus : les ports services (fournis), qui exportent les services des composants et les ports besoins (requis), qui importent les services vers les composants. Les proprits: gnralement, ce sont des attributs. Elles permettent dadapter et dvoluer des composants par des modifications de certaines proprits (interface, comportement). Il existe deux types de proprits : les proprits fonctionnelles et les proprits non fonctionnelles. Les proprits fonctionnelles concernant la smantique des fonctions des composants alors que les proprits non fonctionnelles reprsentent dautres besoins tels que la scurit, la portabilit et la performance. Elle peut tre configurable en fonction du contexte dexcution. Les spcifications des proprits non fonctionnelles des composants sont ncessaires pour permettre la simulation, de leur comportement, de leur analyse, de leur traabilit depuis leur conception jusqu leur implmentation, et de laide dans la gestion de projet (par exemple, en dfinissent des conditions de performance rigoureuses). Les contraintes : proprits spcifiques qui permettent de spcifier des restrictions sur les lments architecturaux sur lesquels elles sappliquent. Elles doivent tre spcifis afin de reprsenter les utilisations prvues dun composant et dtablir les dpendances parmi ses lments internes ; contraintes qui peuvent tre, la scurit, la persistance ou les transactions, etc... Les composants sont reprsents par des classes (comme le paradigme objet) qui encapsulent, les services, les contraintes sur ces services et les paramtres ventuels du composant. Ces classes dfinissent le type du composant, cest--dire une abstraction qui permet lencapsulation de fonctionnalits dans des blocs rutilisables. Elles permettent galement linstanciation de plusieurs composants similaires. Un type de composant peut tre instanci plusieurs fois dans une mme architecture ou peut tre rutilis dans dautres architectures (Medvidovic, Taylor, 2000). Les types de composants peuvent tre paramtrs, facilitant ainsi la rutilisation (Coupaye, Bruneton, Stefani, 2002 ; Garlan, Monroe, Wile, 2000). La modlisation explicite des
types facilitent galement la comprhensibilit et lanalyse dune architecture, sachant que les proprits dun type sont partages par toutes ses instances.
32
2.2.3 Connecteur
Les connecteurs sont des entits architecturales de communication qui modlisent de manire explicite les interactions (transfert de contrle et de donnes) entre les composants. Ils contiennent des informations concernant les rgles dinteraction entre les composants. Ainsi, lobjectif des connecteurs est datteindre une meilleure rutilisabilit lors de lassemblage des composants. En effet, la raison de lexistence des connecteurs est de faciliter le dveloppement dapplications base de composants logiciels. Les composants soccupent du calcul et stockage tandis que les connecteurs soccupent composants. Les exemples de connecteurs incluent des formes simples d'interaction, comme des pipes, des appels de procdure, et l'mission d'vnements dune manire directe entre des interfaces de mme type. Les connecteurs peuvent galement reprsenter des interactions complexes, comme un protocole client-serveur ou un lien SQL entre une base de donnes et une application (Garlan, Monroe, Wile, 2000). De nouveaux connecteurs peuvent tre spcifis de la mme faon que les composants. Par exemple, on pourrait spcifier des connecteurs pour implmenter un protocole de communication spcifique. Medvidovic (Medvidovic, Taylor, 2000) a class les services dinteraction offerts par les connecteurs en quatre types. Chaque type de connecteur offre un ou plusieurs services dinteraction. Ces services sont les suivants : Le service de communication : un connecteur assure ce service sil soccupe des transmissions de donnes entre composants. Le service de coordination : supporte le transfert de contrle entre composants. Les appels de fonctions sont un exemple de cette catgorie de connecteurs. Le service de conversion : convertit les interactions inter-composant si ncessaire. Il permet aux composants htrognes dinteragir. L'inadquation d'interaction est un obstacle majeur dans la composition des grands systmes. Les services de conversion permettent aux composants qui n'ont pas t spcialement conus pour fonctionner les uns avec les autres, d'tablir et de mener des interactions. Le service de facilitation : ngocie et amliore linteraction entre composants. de grer les interactions (communication/coordination) entre les
33
Les connecteurs sont des logiciels de communication capables dadapter les besoins associs aux spcifications dinterfaces requises et fournies. De manire gnrale, les connecteurs dans les langages de description darchitectures peuvent tre classs en trois groupes : 1. les connecteurs implicites, comme ceux par exemple de Darwin (Magee et al. 1995), MethaH (Vestal, 1996), Rapide (Luckham et al. 1995), 2. les ensembles numrs de connecteurs prdfinis, comme ceux par exemple dUniCon (Shaw, DeLine, Zelesnik, 1996), C2 (Medvidovic, Rosenblum, Taylor, 1999), SOFA (Plasil, Besta, Visnovsky, 1999), 3. les connecteurs dont les smantiques sont dfinies par les utilisateurs, comme ceux par exemple de Wright (Allen, Douence, Garlan, 1998), Acme (Garlan, Monroe, Wile, 1997), SADL (Medvidovic, Taylor, Whitehead, 1996). Premier groupe : dans Darwin, les connexions entre les composants sont spcifies en termes de liaison directe (en anglais, binding) entre les ports Requis et les ports Fournis . La smantique de ces connecteurs est dfinie dans lenvironnement sousjacent et la communication entre les composants prend en compte cet environnement. Dautres langages dcrivent les connecteurs implicitement comme (Luckham et al. 1995) et MethaH (Vestal, 1996). Les bindings de Darwin, Rapide et les connexions de MeatH sont modlises en ligne et ne peuvent en aucun cas tre renomms ou rutiliss. Deuxime groupe : un connecteur dans UniCon est spcifi par un protocole (Shaw et al, 1995 ; Shaw, DeLine, Zelesnik, 1996). Un protocole est dfini par un type de connecteurs ; UniCon possde sept types de connecteurs, (FileIO, Pipe, Procedure Call, RPC, Scheduler, RT, Data Access et PL Bundler), possdent un ensemble de proprits et de rles typs qui servent comme points dinteraction avec les composants. Les connecteurs dUniCon ne peuvent pas tre instancis ni peuvent voluer et ne peuvent tre composs quuniquement de connecteurs. Troisime groupe : dans le langage Wright, les connecteurs, sont dfinis comme un ensemble de rles et une glu (Allen, Garlan, 1997). Chaque rle dfinit le comportement
34
dun participant dans linteraction. La glu dfinit, comment les rles interagissent entre eux pour aboutir une fonctionnalit bien dfinie. Les connecteurs de Wright sont dfinis par les utilisateurs et peuvent voluer via des instanciations de leurs diffrents paramtres. Ils peuvent tre composs dautres connecteurs. Les concepts caractrisant ces connecteurs sont, les interfaces, les types, les contraintes et les proprits. Linterface dun connecteur est un ensemble de points dinteraction entre lui-mme et les composants qui lui sont attachs. Les interfaces dun connecteur portent le nom de rles. On distingue deux types: le rle fourni et le rle requis. Linterface du connecteur reflte le nombre et le type des rles autoriss. Les proprits fonctionnelles concernent les fonctions des connecteurs. Les proprits non fonctionnelles dun connecteur ne sont pas forcment obtenues partir des spcifications de sa smantique. Elles spcifient les besoins du connecteur pour une implmentation correcte. Par exemple, elles peuvent concerner la performance, la scurit, la simulation de leurs comportements, leur analyse et la slection de connecteurs appropris et leurs correspondances (Medvidovic, Taylor, 2000). Des contraintes de connecteurs doivent tre spcifies afin dassurer les protocoles prvus, dtablir les dpendances intra-connecteurs et de fixer les conditions dutilisation des connecteurs. Un exemple dune contrainte simple, est la restriction du nombre de composants qui interagissent travers un connecteur donn.
2.2.4 Configuration
Une configuration est un graphe de composants et de connecteurs. Cette information est ncessaire pour dterminer si les composants sont bien relis, que leurs interfaces saccordent, que les connecteurs correspondants permettent une communication correcte et que la combinaison de leurs smantiques aboutit au comportement dsir. Elle dfinit la faon dont ils sont relis entre eux. Le rle cl des configurations est de faciliter la communication entre les diffrents intervenants dans le dveloppement dun systme. Leur but est dabstraire les dtails des diffrents composants et connecteurs. Ainsi, elles dcrivent le systme un haut niveau dabstraction qui peut tre potentiellement compris par des personnes de
35
diffrents niveaux dexpertise et de connaissances techniques. Une configuration permet la modlisation de systmes importants. Il est donc indispensable dtre capable de modliser des systmes htrognes et de permettre le lien entre plusieurs langages. Les interfaces permettent les interactions entre les configurations et permettent aux configurations de communiquer avec leurs composants. Elles sont ncessaires pour faire communiquer les lments internes de la configuration (composants) et les composants provenant dautres configurations. Celles-ci, sont principalement utilises dans les couplages de sous-systmes. Les configurations doivent tre dfinies comme des classes instanciables pour permettre la construction de diffrentes architectures dun mme systme. Ainsi, on peut dployer une architecture donne de plusieurs manires, sans rcrire le programme de configuration/dploiement. Les contraintes qui dcrivent les dpendances entre des composants et des connecteurs dans une configuration sont aussi importantes que celles spcifies au niveau des composants et des connecteurs. Certaines proprits ne sont relies ni aux connecteurs ni aux composants et doivent tre exprimes au niveau des configurations. Les proprits non fonctionnelles au niveau de configurations sont ncessaires pour choisir les composants et les connecteurs appropris, pour raliser des analyses, pour appliquer et faire respecter des contraintes de topologies, pour lier les composants architecturaux aux processeurs et pour aider dans la gestion des projets.
2.2.5 Styles architecturaux

Un style architectural caractrise une famille de systmes qui ont les mmes proprits structurelles et smantiques (exemple : Pipe-Filtre, Client-Serveur/RPC). Le but principal des styles architecturaux est de simplifier la conception des logiciels et leur rutilisation, en capturant et en exploitant la connaissance utilise pour concevoir un systme (Ratcliffe, 2005). Un style architectural fournit (Garlan, 1995) :
36
un vocabulaire dsignant le type des entits de base (composants et connecteurs) tels que pipe, filtre, client, serveur, vnement, processus, etc.
des rgles de configuration pour spcifier les compositions dlments qui sont permises ;
une interprtation smantique de configuration. Par exemple, un systme multi-agents communiquant via le tableau noir signifie que cest un partage de connaissances entre ces agents.
les analyses qui peuvent tre appliques sur les systmes construits selon un tel style. Par exemple, la vrification de la causalit dans un systme distribu base sur la communication par vnements.
Lutilisation des styles architecturaux, offre plusieurs avantages : permet la rutilisation au niveau de la configuration, et au niveau du code (Monroe et Garlan 1996), permet la normalisation une famille darchitectures, ce qui amliore la comprhension de lorganisation dun systme, permet lutilisation danalyses spcifiques au style concern (Ciancarini, Mascolo, 1996). 2.2.5.1 Langage de description darchitecture : ADL1 Il n'y a pas de dfinition officielle de ce qu'est un ADL. La dfinition admise est qu'un ADL spcifie les composants d'un systme, leurs interfaces, les connecteurs (lieux d'interaction entre les composants), et la configuration architecturale (Garlan, Shaw, 1993 ; Luckham et al. 1995 ; Shaw et al. 1995 ; Accord 2002 ; Souc, Duchien ; 2002 ; Khammaci, Oussalah, Smeda, 2003 ; Smeda, Oussalah, Khammaci, 2005a). Les langages de description d'architecture (ADLs) sont des langages formels qui peuvent tre utiliss pour reprsenter larchitecture dun systme logiciel. Comme larchitecture est devenue un thme important dans le dveloppement de systmes
Architecture Description Language
37
logiciels, les mthodes pour spcifier de faon non ambigu une architecture, deviennent indispensables. Les modifications dans une architecture peuvent tre planifies ou non planifies. Elles peuvent galement se produire avant ou pendant la phase dexcution. Les ADLs doivent supporter de tels changements grce des mcanismes oprationnels (linstanciation, lhritage et le sous-typage, la composition, la gnricit, le raffinement et la traabilit). En plus, les architectures sont prvues pour fournir aux
dveloppeurs des abstractions dont ils ont besoin pour faire face la complexit et la taille des logiciels. Cest pourquoi les ADLs doivent fournir des outils de spcification et de dveloppement pour pouvoir prendre en compte des systmes grand chelle susceptibles dvoluer. Aussi, pour amliorer lvolutivit et le passage lchelle et pour augmenter la rutilisabilit et la comprhensibilit des
architectures. Les mcanismes spciaux doivent tre pris en compte par les ADLs. Un ADL doit fournir les critres suivants (Smeda, Khammaci, Oussalah, 2004b) : Syntaxe concrte : un ADL doit fournir une syntaxe concrte quun cadre conceptuel pour caractriser des architectures (Garlan, Monroe, Wile, 1997). Le cadre conceptuel reflte les caractristiques du domaine pour lequel lADL est prvu. Il englobe aussi leurs smantiques (par exemple, les CSP (Hoare, 1995)), les rseaux de Petri (Murata, 1989) et les machines tats (Villa et al. 1997)). Spcification lisible : un ADL doit permettre la description explicite des composants, des connecteurs, de la configuration de larchitecture et bnficier doutils de support pour valider et analyser les modles. Ceci permet de dterminer si une notation particulire est un ADL ou pas. Par ailleurs, afin dinfrer la moindre information sur une architecture, il faut au minimum disposer des interfaces de composants. Sans cette information, une description architecturale nest quune collection didentificateurs interconnects entre eux. Raffinement et traabilit : un ADL doit offrir la possibilit de raffiner une configuration chaque tape du processus de dveloppement. La traabilit permet de garder la trace des changements successifs entre les diffrents niveaux dabstraction.
38
Notons que le raffinement et la traabilit sont les mcanismes les moins pris en compte par les ADLs actuels. Passage lchelle : les architectures sont prvues pour dcrire des systmes
logiciels grande chelle qui peuvent voluer dans le temps. Un ADL doit permettre de raliser des applications complexes et dynamiques, dont la taille peut devenir importante. Evolution : un ADL doit permettre lvolution de la configuration pour quelle puisse prendre en compte de nouvelles fonctionnalits. Cela se traduit essentiellement par la possibilit dajouter, de retirer ou de remplacer des composants ou des connecteurs. Rutilisation : lhritage et le sous-typage sont deux manires diffrentes de rutiliser des modles (de composant, de connecteurs ou de configurations) alors que lhritage permet la rutilisation du modle lui-mme. Le sous-typage permet la rutilisation des constituants dun modle. Lhritage dans les ADLs peut galement tre multiple, o un sous-modle hrite de plusieurs modles. Le sous-typage peut tre dfini par la rgle suivante : un type x est le sous type y si les valeurs du type x peuvent tre utilises dans nimporte quel contexte o le type y est prvu sans erreurs.
Sparation des proccupations : un ADL doit offrir des moyens de sparation des
proccupations des aspects darchitecture et des aspects dimplmentation. Cela permet de les rutiliser de faon indpendante.
Sparation des niveaux dabstractions : un ADL doit sparer clairement les aspects
architecture et application. Les composants, les connecteurs et les configurations sont des types qui doivent tre instancis plusieurs fois dans une architecture. Chaque instance peut correspondre une implmentation diffrente et doivent inclure la structure dfinie par son type.
Composition hirarchique : un ADL doit supporter le fait quune architecture entire
peut tre reprsente comme un seul composant dans une autre architecture plus large. Ainsi, il est crucial quun ADL supporte la proprit de composition hirarchique dans laquelle un composant primitif est une unit non dcomposable et un composant composite est compos de composants (composites ou primitifs). La prise en compte de la composition ou de la composition hirarchique, est cruciale. Cependant, ce mcanisme exige que les composants aient des interfaces bien dfinies puisque leurs
39
implmentations sont caches. Comme nous le verrons dans les sections suivantes, plusieurs ADLs utilisent ce mcanisme pour dfinir des configurations, o les systmes sont dfinis comme des composants composites faits de composants et de connecteurs.
Gnricit : la gnricit se rapporte la capacit de paramtrer des types.
Linstanciation ne fournit pas de services pour paramtrer des types. Souvent des structures communes dans les descriptions de systmes complexes sont amenes tre spcifies plusieurs reprises. Bien que lhritage et la composition permettent de rutiliser le code source en fournissant au compilateur la manire de substituer le nom des types dans le corps dune classe. Ceci, aide la conception et lutilisation de bibliothques de composants et de connecteurs. Ces dernires constituent dimportants outils pour le dveloppement rapide et efficace du logiciel base de composants.
Contraintes : les contraintes qui dcrivent les dpendances entre les composants et
les connecteurs dans une configuration sont aussi importantes que celles spcifies dans les composants et les connecteurs eux-mmes et viennent les complter. Le concepteur spcifie ces contraintes, ce qui revient dfinir des contraintes globales, cest--dire des contraintes qui sappliquent tous les lments dune application.
Proprits non fonctionnelles : les proprits non fonctionnelles qui ne concernent ni
les connecteurs ni les composants doivent tre spcifies au niveau de la configuration. Par consquent, un ADL doit pouvoir dfinir les contraintes lies lenvironnement dexcution au niveau de la configuration. Lensemble de ces critres permet de faire une comparaison entre les diffrents ADLs, et de choisir lADL adquat relativement la nature de lapplication et la satisfaction des besoins recherchs.
2.3 Les langages de description des architectures base de composants

2.3.1 Description des principaux ADLs
Les ADLs trouvent leurs racines dans les langages dinterconnexion de modules (Module Interconnexion Languages) des annes 70 (DeRemer, Kron, 1976). Ils sont aujourdhui dans une base de maturit. Parmi les reprsentants actuels, nous citons :
40
Darwin (Magee et al. 1995 ; Magee, Karmer, 1996), MethaH (Vestal, 1996), Aesop (Garlan, Allen, Ockerbloom, 1994), C2 (Medvidovic, Taylor, Whitehead, 1996 ;
Medvidovic, Rosenblum, Taylor, 1999), Rapide (Luckham et al. 1995), UniCon (Shaw et al., 1995 ; Shaw, DeLine, Zelesnik, 1996), Wright (Allen, Garlan, 1994 ; Allen, Garlan, 1997, Allen , Douence, Garlan, 1998), Acme (Garlan, Monroe, Wile, 1997 ; Garlan, Monroe, Wile, 2000), Olan (Balter et al. 1998), Fractal (Bruneton, 2004 ; Coupaye, Bruneton, Stefani, 2002), SOFA (Plasil, Balek, Janecek, 1998 ; Plasil, Besta, Visnovsky, 1999), ArchWare (-ADL) (Oquendo et al. 2002 ; Oquendo, 2004) et ArchJava (Aldrich, Chambers, Notkin, 2001 ; Aldrich, Chambers, Notkin, 2002 ; ArchJava, 2004). Diffrents langages de description darchitecture logicielle existent. Mme sils possdent parfois des caractristiques communes, ils diffrent sur dautres relatives aux composants, la composition de composants, leurs cycles de vie, etc. Certains
modles sont hirarchiques car ils intgrent la notion de composant composite, cest-dire un composant qui contient des sous-composants. Les modles non hirarchiques sont dits plats car ils nimpliquent que des composants primitifs. Les ADLs permettent la description et la visualisation des lments architecturaux, lanalyse darchitectures, la documentation et la gnration automatique de codes et offrent des outils spcifiques. Dans ce contexte les ADLs tudis sont : Darwin (Magee et al. 1995 ; Magee, Karmer, 1996) : il supporte lanalyse des systmes de transmission de message distribus. C2 (Medvidovic, Taylor, Whitehead, 1996 ; Medvidovic, Rosenblum, Taylor, 1999) : est un style architectural bas sur les notions de composants et de messages. Le style C2 peut tre rsum comme un rseau de composants concourants relis par un ensemble des connecteurs. La partie haute (top) dun composant peut tre relie la partie basse (bottom) dun connecteur et la partie basse dun composant peut tre relie la partie haute dun connecteur. Il ny a pas de limites sur le nombre de composants lis un connecteur. UniCon (Shaw et al., 1995 ; Shaw, DeLine, Zelesnik, 1996) : les langages avec des connecteurs prdfinis sont: Pipe, File IO, ProcedureCall, RmoteProcedureCall, DataAccess, RTScheduler, et PLBundler.
41
Rapide (Luckham et al. 1995) : permet dexprimer la dynamique dune application de manire prcise et dtaille. Son but est de vrifier la validit des architectures par des techniques de simulation de l'excution. Wright (Allen, Garlan, 1994 ; Allen, Garlan, 1997, Allen, Douence, Garlan, 1998) : il fournit un modle pour les architectures logicielles, il est largement utilis pour
lanalyse des protocoles dinteraction entre les composants architecturaux. ACME (Garlan, Monroe, Wile, 1997 ; Garlan, Monroe, Wile, 2000) : est un langage spcifique d'change qui permet de dcrire des structures architecturales travers les ADLs. ACME, est le fruit dun effort srieux prenant en considration tous les lments et les notations ncessaires pour modliser des architectures. Il dcrit des composants, des connecteurs, des ports, des rles, des reprsentations. ACME supporte aussi la dfinition des styles et permet dassurer le respect des contraintes de conception laide de ses outils. SOFA (Plasil, Balek, Janecek, 1998 ; Plasil, Besta, Visnovsky, 1999) est un projet visant fournir une plate-forme pour les composants logiciels. Dans le modle de composants de SOFA, les applications sont dfinies comme une hirarchie de composants. ArchJava (Aldrich, Chambers, Notkin, 2001; Aldrich, Chambers, Notkin, 2002 ; Aldrich et al. 2003) pour les langages combinant la modlisation et la programmation. ArchWare-ADL (Oquendo et al. 2002 ; Oquendo, 2004): ArchWare-ADL fournit les lments de base pour dcrire les architectures logicielles dynamiques. ArchWare, spcialise le -calcul pour permettre la description de comportements dynamiques. Fractal (Bruneton, 2004 ; Coupaye, Bruneton, Stefani, 2002) est un modle de
composants dvelopp par France Tlcom R&D et lINRIA. Contrairement dautres modles comme les EJB ou CCM dont les composants sont plutt de grain moyen et destins aux applications de gestion tournes vers lInternet, la granularit des composants Fractal est quelconque. Leurs caractristiques font quils conviennent aussi bien des composants de bas niveau (par exemple un pool dobjets) que de haut niveau (par exemple une IHM complte). Le but de Fractal est de dvelopper et de grer des systmes complexes comme les systmes distribus. Fractal est compos de deux
42
modles : un modle abstrait et un modle dimplantation. Fractal fournit un langage de description d'architecture (Fractal ADL) dont la caractristique principale est d'tre extensible. La motivation pour une telle extensibilit est double. D'une part, le modle de composants tant lui-mme extensible, il est possible d'associer un nombre arbitraire de contrleurs aux composants. Supposons, par exemple, qu'un contrleur de journalisation (LoggerController) soit ajout un composant, il est ncessaire que l'ADL puisse tre facilement tendu pour prendre en compte ce nouveau contrleur. C'est-dire pour que le dployeur d'application puisse spcifier, via l'ADL, le nom du systme de journalisation ainsi que son niveau (exemple : debug, warning, error). La seconde motivation rside dans le fait qu'il existe de multiples usages qui peuvent tre faits d'une dfinition ADL : dploiement, vrification, analyse, etc. Fractal ADL est constitu de deux parties : un langage bas sur XML et une usine qui permet de traiter les dfinitions faites l'aide du langage.
2.3.2 Outils de support des ADLs

Lutilit dun ADL est directement lie aux outils et aux environnements permettant la description, lanalyse et lexploitation darchitectures. Les outils de support sont principalement des : diteurs graphiques et textuels des architectures, outils de vrification structurelle, outils danalyse comportementale, utiliss pour lexcution darchitectures
(simulation et supervision), outils de production automatique des interfaces graphiques, outils de raffinement et de gnration de code excutable, outils permettant lvolution darchitectures, outils de transformation de descriptions architecturales entre diffrents ADLs. La plupart des ADLs dcrits dans la section prcdente possdent des outils ou des environnements de dveloppement permettant de dfinir et dexploiter des descriptions architecturales (ADL Toolkit, 2004). UNICON, possde un compilateur et un gnrateur de code pour les architectures crites en UNICON.
43
C2, possde un environnement de dveloppement contenant un: - diteur graphique (ArchStudio) qui permet la spcification, la visualisation, et lvolution dynamique des architectures logicielles selon le style C2. vrificateur des contraintes des volutions dynamiques des systmes logiciels
dcrits selon le style C2. RAPIDE possde : - DoMe : diteur graphique et visuel darchitectures selon RAPIDE, - gnrateur de code grant les processus temps rel, la communication, et la synchronisation des ressources, - Analyseur de fiabilit et lanalyse de sret des systmes embarqus, ACME qui possde plusieurs outils et bibliothques, parmi ceux-ci : AcmeLib : une bibliothque disponible en Java et en C++ de classes
rutilisables, - AcmeStudio : un environnement de dveloppement incluant un diteur graphique des styles et un vrificateur de rgles, - un outil de gnration de documentation au format HTML, - ACME PowerPoint Analysis Package : un outil de manipulation, danalyse et de gnration des architectures avec PowerPoint. - ACME PowerPoint Dynamic Analysis Package : simulation et supervision pour reprsenter et manipuler les architectures ACME, - ACME PowerPoint Dynamic Analysis Package : permettant la supervision et la simulation darchitectures dcrites en Dynamic ACME . ArchWare qui possde un environnement de dveloppement contenant un : diteur graphique bas sur lapproche profil UML qui permet la dfinition et la
manipulation des architectures, - compilateur et un moteur dexcution darchitectures, - simulateur graphique, - outil de vrification des proprits structurelles et dynamiques, - outils de raffinement et de gnration de code excutable, - outil de vrification des architectures bases styles architecturaux.
44
Fractal ADL fournit une palette doutils : - Fractal API : ensemble dinterfaces JAVA pour lintrospection et la
reconfiguration dynamique de composants et dassemblage de composants, - Farclet : outil dannotations des composants et des interfaces java et de
gnration de code associ aux annotations. - FractalGUI: outil de conception darchitectures Fractal et de gnration de code Fractal 2.0, - Fractal pour Eclipse : environnement de dveloppement dapplications Fractal,
2.4 Les langages de modlisation des architectures base dobjet

De nombreuses mthodes objets ont t dfinies, mais aucune na pu simposer en raison du manque de standardisation. A partir de 1997, lOMG a adopt UML (Unified Modeling Language) comme unique langage de Management Group, 1997). modlisation objet (Object
2.4.1 Description des principaux mthodes objets

Durant les annes 70 et 80, de nombreux langages de spcification darchitectures logicielles orients objet ont t dfinis. Pendant la premire moiti des annes 90, on en recensait une cinquantaine. Afin denrayer la multiplication des langages de spcification, G. Booch et J. Rumbaugh, ont dcid en 1994 dunifier leurs mthodes respectives OOD de Booch (Object-Oriented Analysis and Design with Application) (Booch, 1994) et OMT de Rumbaugh (Object Management Technique) (Rumbaugh et al. 1991) au sein de la socit Rationnal Software Corporation. La premire version de ces travaux est sortie en octobre 1995 sous le nom Unified Method 0.8. G. Booch et J. Rumbaugh nont eu de cesse dunifier sous une mme mthode toutes les mthodologies existantes. Jacobson a rejoint cette initiative vers la fin de lanne 1995 avec la mthode OOSE (Object Oriented Software Engineering). Les autres mthodes de premire gnration ont ensuite t unifies avec UML (Unified Modeling Language). Aprs 1995, un RFP (Request For Proposal) a t mis lOMG en 1996 pour la standardisation dUML. De nombreuses entreprises, telles que HP, Oracle,
45
MicroSoft et IBM, ont soumis leurs rponses cette RFP, et UML 1.0 est sorti vers la fin de lanne 1996. Des dbuts de linitiative UML jusqu la version 1.4, labore par lOMG, lobjectif fondamental tait de rsoudre les problmes de lhtrognit des spcifications architecturales indpendamment des plates-formes. Actuellement, une nouvelle version dUML est lUML 2.0 (Object Mangement Group, 2004a), devenue un standard de facto dans le monde industriel. Ce standard est un langage de spcification, de visualisation, de construction et de documentation des systmes logiciels. La grande nouveaut dUML 2.0 est le support du paradigme composant, qui permet de dfinir des patrons sur les composants. Il supporte les plates-formes composants EJB (Entreprise Java Bean) et CCM (Component CORBA Model), la dfinition des profils pour les UML
architectures logicielles et la dfinition dune DTD selon le standard XMI.
devient donc potentiellement un langage de modlisation permettant llaboration des architectures logicielles indpendamment et spcifiques des plates-formes.
2.4.2 UML 2.0

UML 2.0 a t standardis en juin 2003 et fournit quelques amliorations au-dessus dUML 1.x. Sa smantique est plus prcise que celle dUML 1.4, mme si elle demeure informelle. La notation graphique est intgralement aligne sur le mtamodle. Le standard UML 2.0 est compos de deux standards, UML 2.0 Superstructure, qui dfinit la version utilisateur et UML 2.0 Infrastructure, qui spcifie larchitecture de mta-mtamodlisation dUML ainsi que son alignement avec MOF 2.0 (Mta Object Facility). Dans cette section, nous prsentons la version 2.0 dUML, un standard orient architecture tout en explicitant ses mcanismes dextension, suivie dune section de prsentation du standard OCL 2.0 (Object Constraint Langauge). Une autre section est consacre aux modles darchitectures XML. 2.4.2.1 UML 2.0 orient architecture UML 2.0 est un standard orient architecture, ce que ntait pas le cas dUML 1.4. LUML 2.0 permet dlaborer des architectures logicielles base dobjets et de composants. UML 2.0 est plus ouvert, ce qui permet lintgration des nouveaux
46
concepts et styles architecturaux. Les objectifs les plus importants dUML 2.0, quil se doit datteindre, dans le contexte de larchitecture logicielle sont les suivants : tablir clairement une sparation entre la smantique des architectures
logicielles et la notation semi-formelle en tablissant un mapping bidirectionnel entre eux. dfinir une DTD pour UML 2.0, selon le standard XMI. XMI est considr comme le seul standard capable dassurer les changes de modles darchitectures. supporter le paradigme composant et permettre de dfinir des patrons pour les connecteurs (Alti, Djoudi, 2009). permettre la dfinition des profils pour les architectures logicielles. supporter les plates-formes composants CCM (CORBA Component Model) et EJB (Entreprise Java Bean). 2.4.2.2 Les amliorations dans UML 2.0 Les principales amliorations dUML 2.0 sont : la cration des nouveaux concepts pour dcrire la structure architecturale interne des classes, des composants et des collaborations au moyen des parts, connecteurs et ports. une meilleure encapsulation des composants par des ports complexes avec le protocole de machine tats qui peuvent commander linteraction avec lenvironnement. le pouvoir expressif concernant les aspects de spcification, de ralisation et de cblage des composants. lenrichissement des interactions avec une meilleure architecture et des concepts de commandes tels que la composition, les rfrences, les exceptions, les boucles et une vue densemble amliore avec des diagrammes de vue densemble dinteraction (Interaction Overview Diagrams). 2.4.2.3 Architecture et niveaux UML 2.0 est dfini selon larchitecture 4 couches de mta-modlisation de lOMG (mta-mtamodle, mtamodle, modle, les objets de lutilisateur) (Object Mangement
47
Group, 2004a). Chaque couche dfinit des modles pour spcifier les modles de la couche infrieure. La figure 2.2, illustre cette architecture MOF 2.0 au niveau des mtamtamodles (niveau M3) qui contient les concepts de base de dfinition des mtamodles. UML 2.0 est dfinit au niveau des mtamodles (niveau M2), et les modles UML (niveau M1) contiennent tous les concepts ncessaires la construction et lvolution des systmes logiciels (niveau M0). Les relations existantes entre les niveaux M1-M2 et M2-M3 sont quivalentes. M2 dfinit la structure de M1 et M3 dfinit la structure de M3. Le haut niveau de MOF dfinit sa propre structure. UML 2.0 considre que le niveau des modles (M1), le niveau des mtamodles (M2) et le niveau des mtamtamodles (M3) sont tous des modles.
Mtamtamodle (MOF modle)
Niveau M3
Mtamodle
Niveau M2
Mtamodle
Modle
Modle
Niveau M1
Modle
Niveau M0
Applications
Figure 2.2. Architecture quatre niveaux en UML 2.0. 2.4.2.4 Le paradigme composant La grande nouveaut dUML 2.0, est le support du paradigme composant. En plus des concepts proposs dans UML 1.4, la nouvelle version UML 2.0, propose de nouveaux concepts et raffine plusieurs autres concepts dj existants. UML 2.0 dispose dune capacit descriptive importante pour reprsenter les lments architecturaux. Cette version dUML propose cinq nouveaux lments qui sont : linterface, les ports, le classifieur structur, le composant et le connecteur (figure 2.3).

StructuredClassifier ConnectableElement StructuralFeature Class
48
EncapsulatedClassifier
+ownedPort
Port * *
+required
Interface
+required
Component
0..1 0..1
+ownedConnector
*
+provided
* * * +provided * 1 +abstraction
Feature
* Connnector
0..1 Association
+type
Classifier +realzingClassifier 1
* Realization
+realization
1
+end 2..* ConnnectorEnd
0..1
+definigEnd
Property
Figure 2.3. Les lments architecturaux dans le mtamodle UML 2.0. Interface UML 2.0 tend le concept dinterface dUML 1.4 pour inclure explicitement des interfaces de type Fournis et des interfaces de type Requis . Une interface peut inclure des attributs et augmenter sa description comportementale (appele machines dtats). Il existe trois manires diffrentes reprsentant les mmes interfaces dans UML 2.0. La premire utilise un strotype classifieur avec les compartiments. La deuxime, reprsente chaque interface qui sidentifie lutilisation, aux besoins requis ou fournis dans les listes des interfaces. Chacune des interfaces est prcde par un strotype appropri ProvidedInterface ou RequiredInterface . La troisime manire prsente les interfaces dans une forme concise et utile pour connecter les classes. Composant Un composant est une entit modulaire dune application, qui peut tre facilement remplac par un autre composant sans que cela ait impact sur son environnement. La notion dinterface de composant devient trs importante. Un composant a des interfaces offertes et des interfaces requises. Dailleurs, cest ce qui caractrise son environnement. Actuellement, un composant est une sous-classe de la classe du mtamodle UML 2.0. Un composant est aussi expressif que les classes, et il a en plus de la classe la capacit de
49
possder plus de types dlments (contraintes, cas dutilisation, objets) et la spcification de dploiement. Classifieurs structurs (Parts) UML 2.0 fournit une nouvelle faon de reprsenter la structure interne de classifieur. Un classifieur structur est dfini globalement ou partiellement, en terme de nombre dinstances que possde un classifieur structur. Ces instances sont appeles des parties. Les parties sont cres avec la cration de classifieur et sont dtruites en mme temps que le classifieur. Connecteur Le connecteur qui est un nouveau concept dans UML 2.0 reprsente le lien entre deux ou plusieurs lments connectables (ports/interfaces). Il est pourvu doprations et dattributs. UML 2.0 spcifie deux types de connecteurs : assemblage et dlgation. Un connecteur dassemblage est un lien entre une interface Fourni qui fournit des services une interface de type Requis . Un connecteur de dlgation lie le comportement externe dun composant (port) une ralisation interne de ce composant. Port Cest un nouveau concept dans UML 2.0. Il est dfini comme un point dinteraction distinct de son classifieur. Le port peut avoir des types et un classifieur peut spcifier la multiplicit dun port. Quand le classifieur est instanci, le nombre de ports est cr. Des classifieurs de mme type peuvent instancier diffrents ports de mme type. Chaque port peut sassocier plusieurs interfaces fournis et/ou requis . Comme les interfaces, les ports peuvent tre associs avec les descripteurs de type machine tats, cela permet de dfinir les contraintes dusage. Les ports peuvent tre simples (sans interfaces associes) ou associs des interfaces (fournis ou requis). 2.4.2.5 Les profils UML (UML Profile) UML permet de modliser des architectures logicielles base dobjets dont les concepts sont suffisamment gnriques pour tre utiliss dans le contexte des architectures logicielles base de composants. En effet, utiliser UML pour dcrire les
50
architectures logicielles, permet ses utilisateurs de bnficier des analyses puissantes offertes par les ADLs et aux utilisateurs dADLs pour utiliser les outils UML. Pour permettre ladaptation dUML au domaine de larchitecture logicielle ou dautres domaines, lOMG a standardis le concept du profil UML. Un profil est un ensemble de techniques et de mcanismes dextensions (strotypes, valeurs marques, contraintes) permettant dadapter UML un domaine particulier (exemple de larchitecture logicielle). Utilisation de profils existants (Object Mangement Group, 2008)
Actuellement, plusieurs profils sont standardiss par lOMG. Quelques profils sont utiliss dans la modlisation commerciale et les autres pour une technologie spcifique. Parmi ces profiles, on peut citer: UML Testing Profile, UML Profile for CORBA Specification, UML Profile for CORBA Component Model (CCM), UML Profile for Enterprise Application Integration (EAI), UML Profile for Enterprise Distributed Object Computing (EDOC), UML Profile for Modeling QoS and Fault Tolerance Characteristics and Mechanisms, UML Profile for Schedulability, Performance and Time, UML Profile for System on a Chip (SoC), UML Profile for Systems Engineering (SysML). Dfinition de nouveaux profils UML 2.0 facilite la cration des nouveaux profils, la figure 2.4 illustre la partie du mtamodle UML 2.0 qui contient les mtaclasses relatives aux profils, ncessaires la dfinition de ce dernier. Un modle instance, de ces mtaclasses correspond la dfinition dun nouveau profil. Il ny pas, lheure actuelle, de dfinition standard du profil UML. Ainsi, nous pouvons dire que les profils sont des moyens dadapter
dUML un type dapplication (systmes distribus, temps rel, etc.). Lobjectif de notre travail porte sur la dfinition du profil UML, ddi au domaine darchitecture logicielle.

Package Class Association Property
51
Extension 1
ExtensionEnd
* Profile 1 * Stereotype 1
+type
Figure 2.4. Les profils dans UML 2.0. Il est communment admis quun nouveau profil UML est une spcification conforme un ou plusieurs points : identification dun sous-ensemble du mtamodle UML. Ce sous-ensemble
peut tre le mtamodle UML entier, dfinition de rgles de bonne construction (well-formedness rules), en plus de
celles contenues dans le sous-ensemble du mtamodle UML. Le terme wellformedness rules est utilis dans la spcification norme du mtamodle. De telles rgles permettent de dcrire un ensemble de contraintes en langage naturel, et laide du langage OCL (Object Constraint Language) (Warmer, Kleppe, 1998), afin de dfinir correctement un lment du mtamodle, dfinition dlments standards (standard elements), en plus de ceux contenues
dans le sous-ensemble du mtamodle UML. Le terme standard element est utilis dans la spcification du mtamodle UML, pour dcrire une instance standard dun strotype UML ou une contrainte,
dfinition de nouvelles smantiques, exprimes en langage naturel, en plus de

celles contenues dans le sous-ensemble du mtamodle UML,
dfinition dlments communs du modle, cest dire des instances de

constructeurs UML, exprimes dans les termes du profil.
52
2.4.2.6 Le langage de contrainte objet :
OCL2
Le langage OCL (Object Constraint Language) permet dexprimer des contraintes sur tous les lments de modles darchitectures et des pr-conditions sur des services. Avant la version 2.0, OCL ntait spcifi quen langage naturel. Le concept dexpression est au cur du langage OCL. Une expression est rattache un contexte, portant sur des lments de modles darchitectures, et peut tre value et vrifie sur des restrictions relatives ses lments. Les expressions OCL 2.0 sont des modles, explicitement lies aux modles darchitectures UML. 2.4.2.7 Les modles darchitectures en XMI3 Le standard XMI (XML Metadata Interchange) offre une reprsentation concrte des modles darchitectures sous forme de documents XML. LOMG utilise les mcanismes de dfinition de structure de balises XML DTD (Document Type Definition) et XML Schema. XMI permet de dfinir des structurations de balises ncessaires la reprsentation des modles au format XML. XMI sappuie sur les documents XML et leurs structurations (modles des instances dune architecture) et ses documents DTD et leurs structurations (mtamodle dune architecture). XMI est un standard assurant linteroprabilit pour lchange des modles entre outils.
2.4.3 Les outils de modlisation UML

Les outils UML qui, notre connaissance sont les plus connus dans la communaut industriel sont : Eclipse IDE, IBM Rationnel Rose, IBM Rational Software Modeler, IBM Rational Software Architect, Entreprise Architect, Poseidon pour UML, Magic Draw UML, [UMLToolKit, 2005]. Eclipse IDE : est un environnement de dveloppement universel. La spcificit d'Eclipse vient du fait de son architecture totalement dveloppe autour de la notion de
Object Constraint Langauge XML Metadata Interchange
53
plugin toutes les fonctionnalits de cet atelier logiciel sont dveloppes en tant que plug-in. IBM Rational Rose : est un outil de modlisation UML. Il facilite la gestion des projets de dveloppements. Les concepteurs de Rational Rose ont commenc tablir un reverse engineering partir d'une application Java ou Delphi. IBM Rational Software Modeler (RSM) : est un outil de modlisation et de conception visuelle des modles UML 2.0. Il offre des facilits de production sur ces modles, la gnration de code et de documentation ainsi que la dfinition de transformations de modles et de gnrations de textes et de patterns. RSM contient Eclipse. Il propose l'approche par programmation pour raliser les oprations de transformation et de production sur les modles. IBM Rational Software Architect (RSA) : est un outil complet qui permet de construire visuellement des applications complexes base des modles. Il facilite la collaboration de plusieurs intervenants (dveloppeurs, ingnieurs, architectes, chefs de projet) sur un mme projet. RSA contient RSM. Entreprise Architect : est un outil de modlisation flexible, complet et puissant conu pour les plateformes Windows et Unix. Il couvre toutes les tapes du cycle de development des systmes logiciels de lingnierie des besoins jusqu' la gnration de code. IL gre la traabilit entre les modles. Il fournit une gamme impressionnante dengineering pour les langages C#, C++, VB.NET, XML Schma, WSDL. Poseidon pour UML : permet d'laborer des modles UML. Il propose l'approche par template (squelette de code pattern) la gnration de texte et de code. Les intervenants sont les ingnieurs de qualit, architectes et chefs de projet. Magic Draw : est un outil graphique de modlisation UML disposant de fonctions de travail collaboratif. Cet outil de dveloppement facilite l'analyse et la conception de systmes orients objets et des bases de donnes. Il fournit le meilleur mcanisme dengineering de code de lindustrie (avec un reverse complet pour les environnements J2EE, C#, C++, CORBA IDL, .NET, WSDL) ainsi que la gnration de DDL.
54
2.5 Comparaison et synthse

Cette section prsente une comparaison des principaux ADLs suivant des critres lis la description architecturale. Puisque lheure actuelle UML est considr comme un ADL (Ivers et al. 2004), nous appliquons galement cette comparaison sur UML.
2.5.1 Description darchitectures

Actuellement, il y a des ADLs qui nont pas de constructions explicites pour dfinir des configurations. Au contraire, ces ADLs dfinissent les architectures comme des composants composites. Concernant la dfinition des connecteurs, nous pouvons classifier les ADLs selon trois groupes en fonction de leur niveau de support des connecteurs, qui dfinissant les connecteurs implicitement, les langages utilisant un ensemble prdfini des connecteurs, et les langages qui dfinissent les connecteurs explicitement. Le tableau 2.1, prsente une comparaison des principaux ADLs concernant les aspects structurels des architectures logicielles.
Composants C2 ACME Composants Composants Connecteurs Connecteurs (groupe 2) Connecteurs (groupe 3) Interface Interfaces de composants Interfaces de composants et de connecteurs Interfaces de composants et de connecteurs Interfaces de composants et de connecteurs Interfaces de composants et de connecteurs Interfaces de composants et de connecteurs Interfaces de composants Interfaces de composants Interfaces de composants Structure Configuration Composants (composites) Composants (composites) Composants (composites) Composants (composites) Composants (composites) Composants (composites) Composants (composites) Composants (composites)
UniCon
Composants
Connecteurs (groupe 2)
Wright
Composants
ArchJava
Composants
Connecteurs (groupe1)
Archware Fractal Darwin UML
Composants Composants Composants Composants
Connecteurs (groupe 3) Connecteurs (groupe1) Connecteurs (groupe 1) Connecteurs (groupe1)
Table 2.1. Comparaison selon les principaux concepts architecturaux.
55
De ltude comparative des principaux ADLs et du langage UML suivant des critres lis la description architecturale, il ressort quUML prsente des insuffisances dans la reprsentation explicite des concepts darchitecture logicielle (connecteurs,
configuration, rle, gluetc.). A lexception de ACME, Archware et Wright, la plupart des ADLs ne considrent pas les connecteurs comme lments de premire classe et donc larchitecture nest pas lisible (les abstractions de calculs et abstractions de communication sont mlangs). La majorit des ADLs ne considrent pas les configurations comme lments de premire classe, donc les aspects architecture et dploiement sont mlangs.
2.5.2 Critres des ADLs

Le tableau 2.2 prsente une comparaison selon les critres des ADLs cits
prcdemment. Nous constatons que lADL Wright, malgr lavantage de vrification dynamique des applications et le mcanisme de raisonnement formel sur les architectures, ne propose pas une bibliothque des composants. Tandis que, pour Fractal, cest larchitecture qui nest pas trs visible. La plupart des ADLs ngligent laspect de communication et ne proposent pas de solutions explicites pour le faire. Pour finir, UML ne considre pas les connecteurs architecturaux comme des entits de premire classe, mais de simples liens entre les composants et ne peut pas spcifier directement les services de communication et de coordination.
C2 Spcification structurelle Sparation des proccupations Bibliothques des composants Communication Point daccs un composant Oui Oui Oui ACME Oui Non Non UniCon Oui Oui Non Wright Oui Oui Non ArchJava Archware Darwin Oui Non Non Oui Oui Non Oui Oui Oui Fractal Oui Oui Oui UML Oui Oui Non
Liens communication Liaisons Connecteur Players Non connecteur connecteur connecteur entre les travers les prdfini et rles dobjets explicite ports liaisons Interface Interface Interface Port Objet Port Interface Interface Port
Table 2.2. Comparaison selon les critres des ADLs
56
2.5.3 Le support dvolution

La conception de larchitecture dun systme est la dfinition des diffrents composants et connecteurs utiliss dans le systme ainsi que la topologie de leur interconnexion. Comme les architectures voluent pour reflter lvolution des systmes logiciels (Rosenblum, Medvedovic, 1997), les lments dans une architecture peuvent galement voluer. Les supports dvolutions qui permettent la prise en compte de lvolution dun systme sont des aspects cruciaux pour les ADLs. Lhritage, le sous-typage, la composition, la gnricit et le raffinement sont les mcanismes le plus reprsentatifs. Malgr leur importance, la plupart des ADLs tudis ne supportent quun nombre restreint de ces mcanismes, comme lillustre le tableau 2.3.
Hritage C2 ACME UniCon Wright ArchJava Fractal Darwin UML x x x x Sous-typage x x x x x Gnricit x x x Composition x Raffinement x x x x
pris en compte
x non pris en compte
Table 2.3. Comparaison selon les supports dvolution.
2.5.4 Qualits et caractristiques dun outil de support

Nous pensons que les qualits et les caractristiques qui doivent tre raisonnablement satisfaites en dfinissant un nouvel outil de composants sont:
1. La simplicit de modlisation : exprime la facilit de supporter la conception

graphique des applications selon un modle de composants donn.
2. La gnration des applications : exprime le degr dautomatisme de gnration des

instances darchitecture.
57
3. La compatibilit, exprime la comptabilit avec des outils darchitectures industriels

(Eclipse IDE, Magic Draw, Rational Modeler).
4. La gnration de code : exprime le degr de gnration de code (partielle, complet). 5. La traabilit: exprime la distance entre larchitecture et limplmentation, qui
permet entre autres dtablir une relation entre une architecture et sa mta-architecture, entre un composant et son type et entre un connecteur et son type. Le tableau 2.4 montre une comparaison des outils dADLs selon les critres prcdents.
Interface graphique Gnration des instances manuelle conteneurs automatique manuelle manuelle manuelle Gnration de code Traabilit syntaxique syntaxique syntaxique syntaxique syntaxique x Comptabilit X x
C2 Fractal ACMEStudio ArchJava ArchStudio Eclipse IDE
pris en compte
Table 2.4. Comparaison selon les critres des qualits dun outil de support. De ltude comparative des outils dADLs et UML suivant des critres lis la sparation des proccupations (architecture et application) et la traabilit smantique, on note que quelques ADLs ont t merg dans le monde industriel (Bass, Clements, Kazman, 1998 ; Van Ommering & al. 2000). Nous avons identifi les limites communes, en particulier dans le contexte de la traabilit smantique entre une architecture et ses mta-architectures, et entre une architecture et ses implmentations. La plupart des architectes conoivent ces systmes en utilisant des concepts de haut niveaux (composants, connecteurs, interfaces, configurations), les dveloppeurs implmente leurs logiciels avec des concepts de bas niveaux (classes, rfrences). Donc, ils
manquent dune stratgie pour gnrer automatiquement des instances darchitectures et manquent galement dune mthodologie pour conserver les traabilits smantiques entre une architecture et sa mta-architecture, entre un composant et son type et entre un connecteur et son type. On note que : Peu dADLs offrent des bons outils de support qui permet dintgrer certain mcanismes oprationnels (comme lhritage, linstanciation, composition, etc.) et
58
certain notions et smantique dADLs (comme les connecteurs, les configurations, les architectures, etc.) dans les techniques de modlisation architecturales proposes par lOMG notamment dans UML 2.0 et MOF. Quand loutil et lenvironnement existent, ils sont rarement compatibles avec des outils darchitectures industriels (Eclipse, Visual Studio, Magic Draw, Rational Modeler, Rational Rose). Un ADL doit avoir une interface graphique. Cest laspect cl des partenaires industriels. Un ADL doit conserver la relation smantique entre la conception et
limplmentation. Les aspects architecture et dploiement sont mlangs. Les praticiens recherchent des passerelles qui permettent dtablir des modles de correspondance entre les espaces des modles darchitectures (ADLs) et les espaces des modles technologiques (MOF). Le raffinement et la traabilit sont les mcanismes les moins pris en compte par les outils actuels.
2.6 Conclusion
Larchitecture logicielle occupe une position centrale dans le processus de dveloppement des systmes complexes. Les systmes logiciels complexes ncessitent des notations expressives et bien dfinies pour reprsenter leurs architectures logicielles. Dans ce chapitre, nous avons prsent les concepts de base des langages de description darchitectures et leurs principaux outils de supports. La prsentation du standard UML 2.0 souligne toute limportance de ce langage dans la description des architectures logicielles. Ce standard dcortiqu par le biais du profil, donne toute la dimension de flexibilit dUML 2.0. Grce aux profils, il est possible de construire un profil UML 2.0 propre au domaine de l'architecture logicielle. De cette tude
comparative des principaux ADLs et du langage UML suivant des critres lis la description architecturale, il ressort quUML prsente des insuffisances dans la reprsentation explicite des concepts darchitecture logicielle (connecteur,
configuration, glu, rle, etc.). A cet effet, une approche hybride objet-composant COSA : Component Object-based Software Architecture, qui unifie lensemble des concepts dADLs afin de dcrire larchitecture logicielle du systme, est prsente chapitre qui suit. dans le
Chapitre 3 : COSA
: Une approche hybride de
description darchitecture logicielle
3.1 Introduction
Larchitecture logicielle occupe une position centrale dans le processus de dveloppement des systmes complexes. Vu le rle important que larchitecture joue dans le dveloppement de systmes complexes, il est devenu indispensable de
disposer de mthodes formelles ou semi-formelles. La description de larchitecture logicielle est fonde sur deux techniques de modlisation : la modlisation darchitecture logicielle base de composants (composants architecturaux) dcrite par les ADLs (Architecture Description Languages) (Clements et al. 2002) et la modlisation oriente objet utilisant le langage UML (Unified Modeling Language). Les deux techniques de modlisation sont dites successivement Object-Based Software Architecture (OBSA) et Component-Based Software Architecture (CBSA) (Khammaci, Smeda, Oussalah, 2005 ; Alti, Khammaci, 2005 ; Alti, Djoudi, 2009 ; Alti, Boukerram, Smeda, Maillard, Oussalah, 2010). Ces langages de modlisation darchitectures
permettent la formalisation des architectures logicielles, la rduction du cot et laugmentation de la performance du systme logiciel ainsi que la comprhension des gros logiciels en les reprsentants un niveau dabstraction lev. Aussi, ces langages permettent la rutilisation en se basent sur ltablissement de bibliothques de composants, la construction de logiciels en fournissent un modle partiel du
dveloppement par indication des composants majeurs et de leurs connexions, lanalyse pour vrifier la conformit des contraintes imposes par un style architectural et la communication entre les diffrents intervenants dans le dveloppement du logiciel.
CHAPITRE 3 COSA : Une approche hybride de description darchitecture logicielle
60
Dans ce chapitre, nous dcrivons une approche hybride, base sur la modlisation par objets et la modlisation par composants, pour dcrire des systmes logiciels. La contribution principale de cette approche est, dune part demprunter le formalisme des ADLs et de les tendre grce aux concepts et mcanismes objets, et dautre part dcrit les systmes en termes de classes et dinstances. Les lments architecturaux (composants, connecteurs, configurations) sont des types qui peuvent tre instancies pour construire plusieurs architectures. Nous prsentons galement une architecture trois niveaux de COSA pour guider larchitecte dans son processus de modlisation darchitectures logicielles. Enfin, ce modle amliore la rutilisation des architectures logicielles en supportent une hirarchie pour les trois niveaux conceptuels.
3.2 COSA4 : une approche hybride darchitectures logicielles

COSA (Component Object-based Software Architecture) est une approche hybride base sur la modlisation base dobjets et la description architecturale. La modlisation base dobjets et la description architecturale ont plusieurs points en commun. En effet les deux approches se basent sur des concepts similaires, lesquels sont labstraction et les interactions entre les composants. Dans la description architecturale, les composants et les connecteurs sont les principaux concepts pour dcrire un systme o les composants sont les abstractions de modules et les connecteurs sont des descriptions de la communication et des interactions entre ces composants. Dans les systmes orients objets, les classes sont des abstractions de donnes et les associations permettent de dcrire les relations et les communications entre les classes et les objets. En terme darchitecture logicielle en gnral, la similarit entre les deux domaines est vidente. En terme dintention, les deux approches ont pour but de rduire les cots de dveloppement dapplications et daugmenter la production de lignes de code (Perry, Wolf, 1992 ; Shaw, Garlan, 1996) puisquelles permettent la rutilisation et la programmation base dobjets et/ou composants.
Component-Object based Software Architecture
61
A cet effet, certains travaux ont montr que ces deux approches pouvait tre utilises pour mieux dcrie larchitecture dun logiciel (Garlan, Cheng, Kompanek, 2002 ;
Medvidovic et al. 2002). Khammaci et al. (Khammaci, Smeda, Oussalah 2005), ont prsent une tude sur les travaux qui permettent de faire co-exister les deux approches. (Garlan, Cheng, Kompanek, 2002), ont slectionn des constructions UML pour reprsenter des lments architecturaux. Un compromis intressant est celui de lutilisation de quatre stratgies pour modliser les composants. Ainsi, UML-RT (Selic, 1999), est une variante particulire de ces stratgies, base sur limplantation des concepts ADL vers UML-RT (Cheng, Garlan, 2001). Dans le cadre de ce travail, Krutchen (Krutchen, 1995), prsente le modle (4+1) vues des architectures logicielles. Dans COSA les composants, les connecteurs et les configurations sont des entits architecturaux peuvent tre dcrites explicitement. COSA prend en compte la plupart des mcanismes oprationnels inhrents l'approche objet, comme linstanciation, lhritage, la gnricit ou la composition (Oussalah, Khammaci, Smeda, 2004). COSA (Component-Object based Software Architecture) est une approche hybride de description darchitecture bas sur la description architecturale et la modlisation par objets (Khammaci, Smeda, Oussalah, 2004 ; Alti, Khammaci, Smeda, 2007a ; Alti, Khammaci, Smeda, 2007b ; Alti & al. 2010). COSA dcrit larchitecture logicielle dun systme comme une collection de composants qui interagissent entre eux par lintermdiaire de connecteurs. Les composants et les connecteurs ont le mme niveau dabstraction et sont dfinis explicitement par la sparation de leurs interfaces et de leurs implmentations. COSA intgre la plupart des mcanismes oprationnels inhrents l'approche objet comme linstanciation, lhritage, la gnricit ou la composition (Oussalah, Khammaci, Smeda, 2004). Les lments de base de COSA sont : les composants, les connecteurs, les interfaces, les configurations, les contraintes et les proprits. Pour ces lments, on note quun nombre de mcanismes oprationnels, ont prouv leur efficacit dans le paradigme orient objet (Smeda, Khammaci, Oussalah, 2004b).
62
3.2.1 Le mtamodle de COSA

LADL COSA dcrit les systmes en terme de classes et dinstances. Les lments architecturaux (les composants, les connecteurs et les configurations) sont des classes qui peuvent tre instancies pour construire plusieurs architectures (Smeda, Khammaci, Oussalah, 2004b). Les concepts de base de larchitecture COSA sont les composants, les connecteurs, les configurations, les interfaces, les contraintes et les proprits (fonctionnelles et non fonctionnelles). Le mtamodle COSA sera mis en uvre dans lenvironnement dUML 2.0 et intgr au sein de MDA (Model Driven Architecture). UML 2.0 fournit une notation de modlisation qui associe chacun de ces concepts du mtamodle COSA des entits syntaxiques. La dmarche vise lautomatisation de la transformation de modle et de larchitecture vers limplmentation (Alti, Khammaci, Smeda, 2007a ; Alti, Khammaci, Smeda, 2007b ; Alti, 2008 ; Alti & al. 2010 ; Alti, Boukerram, 2010). Le mtamodle COSA est dcrit en utilisant le diagramme de classes UML. Ainsi, les concepts de COSA sont reprsents sous forme des classes, leurs caractristiques sous forme dattributs et les diffrentes sont reprsents par des associations. La classe abstraite Elment architectural regroupe toutes les informations structurales et comportementales partages par un composant, un connecteur ou une configuration et na pas donc de correspondance conceptuelle dans un ADL classique ; cette classe sert uniquement comme un support de factorisation, et elle est reprsente par une classe abstraite. Les concepts de base de larchitecture logicielle COSA sont les mmes que dans la plupart des architectures logicielles, savoir : configurations, composants et connecteurs. La figure 3.1 dcrit le mtamodle COSA. Cette figure montre entre autre, 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 de connecteur (appele rle) et que les interfaces fournissent des points de connexion entre les composants et les connecteurs. Nous dtaillons les concepts de COSA dans les sections suivantes.

Implementation +implementation s C omposed of Pr oper ty Constraint
+properties
63
0..*
0..*
0..* +elements 0..1 ArchitecturalElement +parent +ow ner +name Glue
+interfaces Inter face

0..*
+source +name +target +glue 0..1
1..* 1 1..* Connector Component +components Configur ation 1 +conne ctor +details 0..1 +details 0..1 DefinedConnector
BuiltInConnector
+bindings
Extend 0..* Binding Attachment Use +bindings 0..* +conne ctorInterface 0..* Connector Inter face +configuratio nInterfaces 0..* +componentInterfaces 0..* ComponentInterface
<<enumeration>> <<enumeration>>
ServiceType ConnectionMode +sy nchronous +communication +asy nchronous +conv ersion +continu +coordinatio n +facilitation
P or t
+mode:ConnectionMode
Service
Connector Service
+type : ServiceType
Role
+mode:ConnectionMode
RequiredPor t ProividedPor t RequiredService ProvidedService RequiredRole ProividedRole
Figure 3.1. Mtamodle de larchitecture COSA. COSA permet de dcrire une vue de larchitecture logique afin de gnrer automatiquement larchitecture physique pour toutes les instances de lapplication. Lide est base sur le raffinement et la traabilit des lments architecturaux. L'architecture physique est une image en mmoire de l'instance de l'architecture logique d'application. COSA permet de faire la distinction entre connecteurs et visualisation des connecteurs au niveau des modles architecturaux. Cette distinction entre architecture physique et architecture logique permet une bonne gestion de toutes les instances de lapplication. 3.2.1.1 Les configurations dans COSA Dans COSA, les configurations sont des entits de premire classe. Une configuration peut avoir zro ou plusieurs interfaces dfinissant les ports et les services de la configuration. Les ports sont des points de connexion qui sont relis aux ports des composants internes ou aux ports des autres configurations. Les services reprsentent les services requis et les services fournis de la configuration. En gnral, les
64
configurations sont structures de manire hirarchique : les composants et les connecteurs peuvent reprsenter des sous-configurations qui disposent de leurs propres architectures. La figure 3.2 dfinit les principales parties dune configuration COSA.
Contraintes
Configuration +nom
1 1..* Composant
0..* 1 1 0..*
Proprits
1 0..* Connecteur
0..* Interface
Figure 3.2. Les configurations dans COSA 3.2.1.2 Les composants dans COSA Les composants reprsentent les lments de calcul et de stockage de donnes dun systme logiciel. Chaque composant possde une ou plusieurs interfaces ayant plusieurs ports. Les ports sont les points de connexion entre les composants et le monde extrieur. Un composant est dfini par un ensemble de services interagissant pour remplir un rle et communiquant avec lenvironnement via deux interfaces (requise et fournie). Le comportement d'un composant est dcrit par ses services requis et fournis. Un composant peut avoir plusieurs implmentations. Un composant peut tre primitive ou composite (Smeda, Khammaci, Oussalah. 2004a).La figure 3.3 dcrit un composant dune architecture COSA.
Configuration +raliser par 0..* 1 1 1 1 1 1..* Interface 0..* 0..* Proprits Implmentation Contraintes
0..1 +compos de
1 +dfinis dans 1..*
Composant +nom
Figure 3.3. Les composants dans COSA.
65 Dans
3.2.1.3 Les connecteurs dans COSA Les connecteurs entre les composants sont des entits de premire classe.
lapproche COSA, on distingue deux types de connecteurs : les connecteurs de construction (i.e. connecteurs dassociations) et les connecteurs utilisateur. Un connecteur de construction est compos de rles reprsentant les extrmits du connecteur. Un connecteur utilisateur est principalement dfinit par une interface et une glu, comme le montre le diagramme de classes de la figure 3.4.
Configuration
0..1 +compos de 1
+raliser par 0..* 1
Implmentation Contraintes
+dfinis dans 1..*
Connecteur +nom
1 1
1 0..* 1 0..* Proprits
2..* Interface
0..1 Glu
Figure 3.4. Les connecteurs dans COSA. Le connecteur correspond un lment darchitecture qui modlise de manire explicite les interactions entre un ou plusieurs composants, ceci par la dfinition des rgles qui gouvernent ces interactions. Par exemple, un connecteur peut dcrire des interactions simples de type appel de procdure ou accs une variable partage, mais aussi des interactions complexes tels que des protocoles daccs des bases de donnes avec gestion des transactions, la diffusion dvnements asynchrones. En principe, linterface dcrit les informations ncessaires du connecteur, y compris le nombre de rles, le type de services fourni par le connecteur (communication, conversion, coordination et facilitation), le mode de connexion (synchrone et asynchrone), le mode de transfert (parallle et srie), etc. Les points dinteraction dune interface sont appels rles. Un rle est une interface dun connecteur appel tre reli une interface dun composant (un port de composants). Un rle est soit de type Besoin ou de type
66
Service . En principe, un rle est une interface gnrique dun connecteur qui sera reli une interface dun composant. Un rle Service sert comme un point dentre dans linteraction dun composant reprsent par une instance dun type de connecteur. Il est appel tre connect une interface Besoin dun composant (ou un rle Besoin dun autre connecteur). De manire similaire, un rle Besoin sert comme point de sortie de linteraction dun composant reprsent par une instance dun type de connecteur et ce rle a pour but de se connecter une interface Service dun composant (ou a un rle Service dun autre connecteur). Le nombre de rles dun connecteur reprsente le degr dun type de connecteur. Par exemple, dans un type de connecteur Client-Serveur, la reprsentation de linteraction dappels de procdures entre les entits Client et Serveur est un connecteur de degr 2. Les interactions complexes, entre au moins trois composants, sont reprsentes par des types de connecteurs de degr suprieur 2. Certains langages de description darchitectures proposent des connecteurs avec uniquement deux rles, et un connecteur ne peut tre reli qu un autre connecteur (cas des langages C2 (Medvidovic, Taylor, Whitehead, 1996)). 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 le lien, la conversion de format de donnes, le transfert ou ladaptation. En gnral, la glu dun connecteur reprsente le type de connexions de ce connecteur. Les connecteurs peuvent avoir leur propre architecture interne qui contient des calculs et du stockage de donnes. Par exemple, un connecteur peut excuter un algorithme de conversion de donnes dun format un autre. Ainsi, le service fourni par un connecteur est dfini par sa glu. Les services dun connecteur peuvent tre de type communication, conversion, coordination ou facilitation. Un connecteur composite se compose des sous-connecteurs et ses sous-composants. Ce connecteur doit tre dfini dans la glu ainsi que les liens entre les sous-connecteurs et les sous-composants. La glu peut aussi avoir ses propres proprits et ses propres contraintes en plus des proprits et des contraintes du connecteur. Les services fournis
67
dun connecteur peuvent tre de quatre types : communication, coordination, conversion ou facilitation (Perry 1997 ; Mehta, Medvidovic, Phadke, 2000). 3.2.1.4 Les interfaces dans COSA Les interfaces sont des entits abstraites de premire classe. Une interface de COSA spcifie les points de connexion et les services fournis et ceux requis pour un lment architectural (configuration, composant, connecteur). Ces derniers permettent une interface dinteragir avec son environnement, y compris avec dautres lments. De faon gnrale, les interfaces sont un support de description des composants permettant de spcifier comment ils peuvent tre assembls ou utiliss au sein dune architecture. Les interfaces de composants en COSA sont vues comme les points de connexion des composants et sont le support des invocations de services. Le point de connexion est appel port pour les composants/configurations et rle pour les connecteurs. En plus les ports et les rles, les interfaces contiennent des services fournis/requis qui expriment le comportement fonctionnel de l'lment architectural (composant, connecteur et configuration). Un service peut utiliser un ou plusieurs points de connexion pour excuter sa tche. Du point de vue conceptuel, les ports, les rles et les services sont des classes concrtes hrites de la classe abstraite interface comme le montre la figure 3.1. La figure 3.5 dcrit les interfaces dans COSA.
Interface
+Type : Type-Interface
numration Type-Interface -public -priv numration Type-Service -communication -conversion -coordination -facilitation
Interface-composant
numration Mode-connexion -synchrone -asynchrone -continu
Interface-connecteur
Service 1 Use
Bind
0..1 1 1..*
Port
+nom Attach +nom
Rle
0..1 1 1..*
Bind Use 1
Service-Connecteur +Type: Type-Service
Service-Fourni Service-Fourni
Service-Requis
Port-Fourni
Port-Requis
Rle-Fourni
Rle-Requis
Figure 3.5. Les interfaces dans COSA.
68
3.2.1.5 Les proprits (fonctionnelles et non fonctionnelles) dans COSA Selon le paradigme de sparation avance des proccupations, un systme est un ensemble de proccupations fonctionnelles et extra-fonctionnelles. Les proccupations fonctionnelles sont les fonctionnalits mtier que le systme doit assurer, alors que les proccupations extra-fonctionnelles sont des services dont le systme a besoin pour effectuer les fonctionnalits mtier. Comme exemple de proccupations extrafonctionnelles on peut citer la scurit, la gestion de la persistance, etc. Les proprits servent en gnral documenter les dtails des lments architecturaux (composant, connecteur, configuration) relevant de leur conception et de leur analyse. Elles deviennent utiles lorsquelles sont utilises par des outils des fins de manipulation, daffichage ou danalyse. Pour un composant (respectivement un connecteur ou une configuration), les proprits peuvent concerner aussi bien leur structure, leur comportement que leurs fonctionnalits et permettent de caractriser les lments architecturaux. Elles peuvent tre paramtres et configures selon un contexte dexcution particulier. Par ailleurs, il existe dautres proprits dites non-fonctionnelles qui reprsentent les services utiliss par un lment architectural (composant, connecteur, configuration) et qui ne font pas partie des services applicatifs. Ce sont des services de base fournis par larchitecture tels que la scurit, le traage et la fiabilit. Du point de vue de COSA, les proprits sont des valeurs non interprtes, c'est--dire, quelles nont aucune smantique intrinsque. Les proprits deviennent utiles quand les outils les utilisent pour lanalyse, la traduction et la manipulation. Toutes les entits architecturales de COSA peuvent tre annotes avec une liste des proprits. Chaque proprit a un nom, un type facultatif et une valeur. Dans COSA, les proprits sont simplement reprsentes en tant quattributs. COSA ne fournit donc pas de syntaxe spcifique pour dfinir les proprits, et les types de proprit sont dfinis en utilisant les types primitifs (entier, chane de caractre, boolen), et des constructeurs pour les enregistrements, les ensembles et les listes.
69
3.2.1.6 Les contraintes dans COSA Un des principaux concepts dune description architecturale est un ensemble de contraintes de conception qui dterminent comment une architecture est autorise voluer dans le temps. Les contraintes incluent des restrictions aux valeurs permises des proprits et de topologie. Par exemple, une architecture peut contraindre sa conception pour que le nombre de clients dun serveur soit infrieur une certaine valeur. Un autre exemple concerne le dbit dun connecteur qui ne dpasse pas une certaine valeur. Les contraintes peuvent galement tre considres comme un type spcial de proprit. Mais comme en gnral, elles jouent un rle cl dans la conception darchitectures base de composants, les auteurs et dveloppeurs de logiciels fournissent souvent une syntaxe spciale pour les dcrire. Dans COSA, elles sont dfinies en tant quattributs afin de simplifier la syntaxe de lapproche. 3.2.1.7 Les associations de COSA : Attachement, Binding, Use et Extend Attachement : dans COSA, la topologie dun systme est dfinie en numrant un ensemble dattachements qui lient les ports dun composant ou dune configuration aux rles dun connecteur. Dans ce cas, le port requis dun composant (configuration) est li au rle fourni dun connecteur et le port fourni dun composant (configuration) est li au rle requis dun connecteur. Bindings : Binding est une association entre les ports (respectivement rles) internes et les ports (respectivement rles) externes des composants et configurations (respectivement connecteurs). Use (utilise) : lassociation Use, relie des services aux ports (rles pour les connecteurs). Par exemple, un port fourni (ports fournis) dun composant est (sont) associ(s) au service fourni (ou aux services fournis) de ce composant. Un port requis (ports requis) est (sont) associ(s) un service requis (aux services requis). Extend (hrite) : cette association peut tre utilis pour dfinir des composants concrets (respectivement connecteurs concrets ou configurations concrtes) en tant que sous-lments de composants abstraits (connecteurs/configurations abstraites).
70
3.2.2 Le mtamodle dinstance de COSA

La figure 3.6 dcrit le mtamodle dinstance COSA (Alti & al. 2010). Dans le monde rel, les applications sont des instances de modle architectural. Les lments architecturaux COSA sont instancis pour dcrire une application complte. Les instances sont cres partir des types qui sont dfinis dans le mtamodle COSA. Les lments sont crs et assembls sous diffrentes contraintes dfinies dans les modles d'architecture COSA (Alti, Boukerram, Smeda, Maillard, Oussalah, 2010).
ElementInstance
instanceType instanceName 0..* builtInConnections
ArchitecturalElementInstance
interfacesInstances 0..*
InterfaceInstance
RequiredPortInstance ProvidedPortInstance elements 0..1
RequiredRoleInstance ProvidedRoleInstance
ConfigurationInstance
0..* detail
DetailableInstance
ComponentInstance
ConnectorInstance
Figure 3.6. Mtamodle instance de larchitecture COSA.
3.2.3 Les mcanismes oprationnels de COSA

Dfinir les composants, les connecteurs et les configurations en tant que concepts de premire classe permet de rutiliser, de les redfinir et de les faire voluer efficacement par des mcanismes oprationnels bien dfinis tels que linstanciation, lhritage ou la composition (Smeda, Khammaci, Oussalah, 2003). Les mcanismes que nous utilisons dans COSA sont inspirs des mcanismes du paradigme objet. Ces mcanismes sont : linstanciation, lhritage, la composition. 3.2.3.1 Linstanciation Linstance dun composant (dun connecteur ou dune configuration) est un objet particulier, qui est cr suivant un plan donn par sa classe gnratrice. Toutes les instances dune classe composant (connecteur ou configuration) doivent inclure la structure dfinie par la classe et se comporter exactement tel que cela est dfini dans sa classe. Larchitecture logicielle COSA distingue entre les types des composants et les types des connecteurs. Les types des composants sont des abstractions qui contiennent
71 mcanismes de
des fonctionnalits de stockage de donnes dans des blocs rutilisables alors que les connecteurs dfinissent des abstractions qui englobent les
communication, de coordination et de conversion entre les composants (Smeda, Khammaci, Oussalah, 2004a). La figure 3.7 dcrit lexemple du systme Client-Serveur en COSA. Le systme possde deux composants (Client et Serveur) et un connecteur (RPC). Les composants Client et Serveur qui communiquent par lintermdiaire du connecteur RPC constituent la configuration Client-Serveur. Le composant Client possde un port de type requis (besoin) et le composant serveur possde un port fourni (service). Le connecteur RPC reprsente un mdiateur auquel un client peut passer une requte et un serveur envoie une rponse. Il possde un rle fourni (particpateur-1) et un rle requis (participateur-2) et son service est de type communication.
Configuration Client-Serveur
Composant Client
demand-data () request
Connecteur RPC
particpateur-1
Glu GluRPC
Composant Serveur
max-clients = 2 send-data () service
communication ()
particpateur-2
exemple-architecture C1-S1
attachement
attachement
C1
S1
Lgende
Association dinstanciation Figure 3.7. Exemple dinstanciation dans COSA.
3.2.3.2 Lhritage Dans COSA, les composants (respectivement connecteurs ou configurations) peuvent tre dfinis par extension dautres composants (connecteurs ou configurations). Le mcanisme dextension est semblable au mcanisme dhritage des classes, c'est--dire un sous-lment peut ajouter et surcharger (override) des lments de son super lment. Ce mcanisme peut tre utilis pour dfinir des composants concrets
72
(respectivement connecteurs concrets ou configurations concrtes) en tant que souslments de composants abstraits (connecteurs abstraits ou configurations abstraites). Enfin, COSA ne supporte pas lhritage multiple pour viter les conflits smantiques des sous lments. Enfin, COSA ne supporte pas lhritage multiple pour viter les conflits smantiques des sous lments. La figure 3.8 montre la spcialisation de connecteur RPC par deux rles caller2 et caller3. Le connecteur RPC-1 peut tre utilis pour connecter trois clients avec le serveur via le rle request.
Configuration Client-Serveur
Composant Client
demand-data () request service caller
Connecteur RPC
callee
Composant Serveur
max-clients = 2 send-data ()
Connecteur RPC1
caller1 caller2 caller3 callee
Lgende
Connecteur dhritage Figure 3.8. Exemple dhritage en COSA.
3.2.3.3 La composition Un composant (respectivement un connecteur) peut tre compos de configurations. Il est dit composant (respectivement connecteur) composite. Dans la suite de cette thse, on appellera composant interne (respectivement connecteur interne), les composants et les connecteurs inclus dans un composant composite (respectivement connecteur composite). Les composants internes (respectivement connecteurs internes) peuvent tre assembls afin de remplir des services du composant composite (respectivement connecteur composite). Le composite dispose de ses propres interfaces et donc de ses propres points de connexion et utilise les liaisons (binding) pour faire le lien avec les points de connexion des interfaces des lments internes. Ainsi, pour les services du composite
73
rendus par les composants internes, on utilise les correspondances pour indiquer quels points de connexion dun lment interne redent les services de llment composite. COSA supporte la composition de ses lments architecturaux (composants, connecteurs). En effet, avec la dfinition explicite de ces lments, on peut composer non seulement les composants, mais galement les connecteurs et mme les configurations (une configuration est vue comme un composant composite au niveau dabstraction suprieur). Dans COSA, les composants composites et les connecteurs composites sont dfinis comme des configurations. Les connecteurs composites ne possdent pas de glu, puisque leurs services sont dfinis au niveau de leurs structures internes. Par exemple, le schma de la figure 3.10, montre la structure dun composant
composite (serveur qui possde le port provide de type fourni et le service send-data) constitu de trois composants : ConnectionManager, SecurityManager et DataBase et trois connecteurs : SQLQuery, ClearanceRequest et SecurityQuery. Le composant ConnectionManager possde deux ports fournis externalSocket et DBQueryIntf et un port requis securtiyCheck. Le composant SecurityManager possde un port fourni securityAuthorization et un port requis credentialQuery. Le composant DataBase possde un port fourni securityManagement et un port requis queryIntf. Le connecteur SQLQuery possde un rle fourni callee et un rle requis caller. Le connecteur ClearanceRequest possde un rle fourni requestor et un rle requis grantor. Le connecteur SecurityQuery possde un rle fourni securityManager et un rle requis requestor. Le composant Server utilise une configuration (Database-Manager) pour dfinir la composition.
74
La correspondance (binding) entre les composants internes et leur composant composite est ncessaire pour exporter les services des composants internes. La figure 3.9, montre la description de lexemple.
3.3 Larchitecture trois niveaux de COSA

Dans cette section, nous prsentons larchitecture trois niveaux de COSA pour guider larchitecte dans son processus de modlisation darchitectures logicielles. Cette architecture a trois niveaux dabstraction pour llaboration des modles darchitecture logicielle et leurs interrelations : niveau mta-architecture, niveau architecture et niveau application. Il prsente une spcification complte et structure de larchitecture logicielle COSA. Il amliore la rutilisation des architectures logicielles en supportant une hirarchie pour les trois niveaux conceptuels.
3.3.1 Niveaux dabstractions pour llaboration des architectures logicielles

Une hirarchie de trois niveaux dabstraction pour llaboration des architectures logicielles est illustre dans la figure 3.11. Le niveau le plus lev (M2) contient les diffrents concepts de base pour dfinir les architectures logicielles COSA, le second niveau (M1) contient les modles darchitectures et le troisime niveau (M0) contient les instances de ces modles. La relation entre M2-M1 est ncessaire pour vrifier la cohrence des modles, alors que la relation entre les niveaux M1-M0 permet de gnrer plusieurs instances darchitectures (Alti, Khammaci, Smeda, 2006; Alti, Khammaci, Smeda, 2007a). Les trois niveaux dabstraction de larchitecture logicielle sont inspirs de trois niveaux dabstraction de lOMG (MOF 2002) comme le montre le tableau 3.1. 3.3.1.1 Le niveau mta-architecture (M2) Selon OMG (Object Mangement Group, 2003), Le mtamodle dfinit la structure de tout modle UML conforme ce mtamodle. Par exemple, le mtamodle UML dfinit que les modles UML contiennent des packages, leurs packages des classes, leurs classes des attributs et des oprations, etc.
75
Server
Connection Manager Clearance Request SQL Query
Security Manager Security Query
DataBase
Figure 3.9. La structure du composant Serveur.

Composant Server + send-date () Composant DataBase-Manager
Connecteur SecurityQuery
requestor securityManagement queryIntf
Composant DataBase
Sec_Glu
secManager
cerdQuery
Composant SecurityManager
callee
Connecteur SQL_Query SQL_Glu
DBQueryIntf
Connecteur ClearanceRequest Cle_Glu
Grantor
requset
secAuthor
securityCheck extrnalSocket
provide
caller
Composant ConnectionManager
extrnalSocket
Lgende
Connecteur dassemblage Connecteur de dlgation
Figure 3.10. Exemple de composition en COSA.
76
Meta Architecture COSA
Niveau M2 (mta-architecture)
Architecture Client-Serveur
Architecture Pipe-Filter
Niveau M1 (architectures)
arch1
arch2
arch3
Niveau M0 (application)
Figure 3.11. Les trois niveaux dabstraction de larchitecture logicielle.

Modlisation par objet Le niveau mtamodle M2 Le niveau modle M1 Le niveau application M0 UML Modles Instances Modlisation par composants Acme, COSA, Fractal, Architectures Instances
Table 3.1 Les trois niveaux conceptuels dans la modlisation objets et la modlisation composants. Dans le contexte de larchitecture logicielle une mta-architecture fournit la dfinition des concepts de base dune architecture, ainsi que les proprits de leurs connexions et leurs rgles de cohrence. Par exemple, la mta-architecture COSA dfinit que les architectures COSA contient des configurations, leurs configurations des composants et des connecteurs, leurs composants des interfaces et des proprits, etc. Une mtaarchitecture fournit les lments de base pour la description darchitecture logicielle (ADL) : composant, connecteur, configuration, ports, rles, etc. Ces concepts de base permettent de dfinir diffrentes architectures. 3.3.1.2 Le niveau architecture (M1) Une architecture contient plusieurs types de composants, de connecteurs et darchitectures sont dcrits. Les architectures se conforment aux mta-architectures (ADLs), donc chaque lment de M1 associ un lment de M2. Par exemple dans le systme Client-Serveur de la figure 3.12, client et serveur sont des composants, le RPC est un connecteur et le Client-Serveur est une configuration. 3.3.1.3 Le niveau application (M0) M0 cest le lieu o les instances dexcution sont localises. Une application est vue comme un ensemble dinstances de types de composants, de connecteurs et
77
darchitectures. Les applications sont conformes aux architectures. Chaque lment dM0 est associ un lment de M1. Par exemple, dans la figure 3.11, C1 est une instance de client, S1 est une instance de serveur, et C1-S1 est une instance de RPC et le arch1 est une instance de Client-Serveur.
3.3.2 Exemple applicatif

La figure 3.12 dcrit larchitecture Client-Serveur en COSA. Les composants Client et Serveur qui communiquent par lintermdiaire du connecteur RPC constituent le systme Client-Serveur. Le connecteur RPC reprsente un mdiateur auquel un client peut passer une requte et un serveur envoie une rponse.
M1
Connecteur Composant 1..* 1 1
Configuration Configuration
0..*
M2 Client-Serveur
Conforme
Client
RPC
Serveur Conforme
M0
C-S
C1
RPC1
S1
Figure 3.12 Le systme Client Serveur dans larchitecture trois niveaux de COSA.
3.3.3 COSA et les langages de description darchitecture

COSA propose une prsentation de larchitecture partir dun ensemble de composants, de connecteurs et des configurations. Un composant propose un ensemble de services travers son interface fournie et demande un ensemble de services travers son interface requise . Un connecteur est charg dassurer la communication entre les services des composants connects et peut tre utilis pour assurer plusieurs connexions. Les mcanismes oprationnels de COSA sont inspirs des mcanismes du paradigme objet qui permettent une rutilisation croissante et un support direct des
78
volutions statiques des systmes. La prise en compte des proprits smantiques proposes dans le cadre de l'ADL COSA (Component-Object based Software Architecture) prsente un avantage par rapport aux autres ADLs. Ainsi COSA est un ADL hybride qui rie les concepts communment admis par la majorit des langages de description d'architectures logicielles. Dans COSA, les connecteurs sont dfinis comme des entits de premire classe et sont utiliss pour connecter des composants, des configurations et des interfaces. COSA distingue deux catgories de connecteurs : les connecteurs utilisateur et les connecteurs de construction. Nous reprenons les critres lis la description architecturale que nous avons applique aux diffrents ADLs (cf. chapitre 2), pour les appliquer COSA. La comparaison selon les concepts de description darchitectures illustre dans le tableau 3.2. Le tableau 3.3 rsume la comparaison selon les critres des ADLs et le tableau 3.4 illustre la comparaison selon les supports dvolution dun modle dcrit par COSA.
Composants Connecteurs Interface Interfaces de composants et interfaces des connecteurs Structure
COSA
Composants
Configuration
Table 3.2. Comparaison selon les concepts de description darchitectures

Spcification structurelle Sparation des proccupations Bibliothques des composants Communication Point daccs un composant
COSA
Oui
Oui
Oui
Connecteur
Port
Table 3.3. Comparaison selon les critres des ADLs.

Hritage COSA Sous-typage x Gnricit Composition Raffinement
pris en compte
Table 3.4. Comparaison selon les supports dvolution.
3.3.4 Les avantages et les inconvnients de COSA

3.3.4.1 Avantages COSA est un mtamodle gnrique pour la description des architectures logicielles tout en intgrant des mcanismes oprationnels inhrents l'approche objet comme
79
l'instanciation, l'hritage, la composition, la gnricit (Oussalah, Smeda, Khammaci, 2004). Les points forts de COSA vis--vis des autres ADLs sont :
1. Dploiement facile et multiforme de l'instanciation de plusieurs architectures du

mme systme. COSA tablit larchitecture par linstanciation des composants, des connecteurs et des configurations. En premier lieu, nous commenons par instancier la configuration pour tablir larchitecture. Nous pouvons avoir plusieurs instances dune configuration, nous pouvons donc tablir diffrentes architectures avec diffrentes topologies du mme systme. La dfinition des configurations comme des classes instanciables permet la construction de diffrentes architectures du mme systme.
2. Un support direct de distribution et de maintenance du systme issu des

connecteurs explicites. Obliger les composants de communiquer par lintermdiaire des connecteurs donne plusieurs avantages (Smeda, Oussalah, Khammaci, 2005): - une rutilisation croissante : le mme composant peut tre employ dans une varit denvironnements, chacun deux supportant une communication spcifique, - lamlioration de la maintenance du systme, - un support direct de rutilisation de manire transversale des organisations. En plus, plusieurs applications peuvent tre dcrites plus facilement en utilisant une approche dans laquelle les composants, les connecteurs et les configurations sont dfinis de manire uniforme et explicite.
3. COSA autorise l'volution statique d'un systme du fait l'emprunte des mcanismes
oprationnels objets par COSA et ainsi l'volution dynamique grce aux connecteurs actifs qui sont utiliss dans le modle dvolution SAEV (Sadou, Oussalah Tamzalit, 2005 ; Sadou, Tamzalit, Oussalah, 2005). Le positionnement de SAEV lui permet de grer lvolution la fois au niveau Architecture, mais aussi au niveau Application.
4. Dans COSA, les fonctionnalits des composants, des connecteurs et des

configurations sont exprimes par les services. Ils sont reprsents au niveau interface. Ceci facilite la recherche dun composant (dun connecteur ou dune configuration) dans une bibliothque donne. 3.3.4.2 Inconvnients 1. COSA est un ADL qui volue avec des objectifs acadmiques plutt quavec des objectifs industriels. COSA nest utile que si nous fournissons des outils de support.
80
2. COSA est un ADL semi formel et reste ainsi limit pour lexpression de la smantique. 3. Dans COSA, les proprits et les contraintes sont reprsentes en tant quattributs. Par consquent, COSA manque de spcifications formelles explicites pour reprsenter les proprits et les contraintes. 4. COSA ne propose pas explicitement une manire de dfinir des styles architecturaux. Les styles architecturaux permettent la rutilisabilit et lintgration des architectures htrognes en appliquant des mthodes connues de nouveaux problmes (Ratcliffe, 2005).
3.4 Conclusion
Le modle hybride COSA (Component-Object Software Architecture), permet de
dcrire les architectures logicielles base de composants de systmes informatiques. COSA est un modle hybride bas sur lapproche objet et lapproche composant. Les composants et les connecteurs ont le mme niveau dabstraction et sont dfinis explicitement et il spare la notation de calcul de la notion dinteraction. On peut conclure que les points forts de COSA par rapport aux autres ADLs sont lvolution dynamique et statique possibles grce aux mcanismes oprationnels objets (hritage, composition) et le support direct de distribution et de maintenance issue des connecteurs explicites. Cest ce qui permet de dvelopper des systmes base de composants de meilleure qualit tout en offrant un meilleur potentiel de rutilisation. Larchitecture trois niveaux, permet de dfinir une spcification complte et structure de larchitecture logicielle COSA. Le profil UML 2.0 pour COSA et lintgration de ce dernier dans la dmarche MDA fait lobjet du chapitre qui suit.
Chapitre 4 : Intgration de larchitecture logicielle COSA au sein de la dmarche MDA
4.1 Introduction
Les dveloppements rcents des systmes logiciels sont appels Component-Based Software Developement (CBSD). Ils sont bass sur lassemblage des composants prfabriqus. Le CBSD permet aux dveloppeurs de faire abstraction des dtails
dimplmentation et de faciliter la manipulation et la rutilisation des composants. Actuellement, il y a plusieurs plates-formes dexcution qui se focalisent sur le dveloppement des systmes base de composants. Les plus connus dentre eux sont CORBA, EJB, .Net et les Web Services. La communication entre les composants est complexe dans des plates-formes htrognes et la rutilisation des composants au niveau dimplmentation est limite. Les langages de description des architectures logicielles (ADLs) fournissent une reprsentation abstraite des systmes logiciels. Avoir une projection concrte dune telle reprsentation avec une sparation de larchitecture de limplmentation est un des principaux aspects de MDA (Model Driven Architecture). La dmarche MDA (Frankel, 2003) a t propose par lOMG. Lide de MDA est de proposer un modle stable indpendant de lintergiciel, partir duquel il est possible de driver diffrents outils. Lobjectif est de capitaliser et de rutiliser ce modle au lieu de migrer incessamment, de faon laborieuse dun intergiciel lautre. Par ailleurs, la dmarche MDA est trs souvent associe la notion du profil UML. Ce dernier constitue le fondement de la dmarche MDA. Les profils UML existants sont ddis un type dapplication (systme distribus, temps rel, etc.), alors que la notre
82
sera indpendant et spcialis dans la modlisation des architectures logicielles. Lintgration de larchitecture logicielle COSA au sein de MDA rentre dans le cadre des nouvelles orientations des travaux de recherche de la communaut des architectures logicielles. Nous souhaitons allier les avantages de lapproche ADL et de lapproche MDA de lOMG. De lapproche ADL, nous intgrons les notions et les mcanismes inhrents aux composants, connecteurs et architectures qui confrent aux modles objets excutables un niveau dabstraction haut et un degr de rutilisation quivalent celui dADL. Quant lapproche MDA base sur la mtamodlisation, elle prsente lavantage de pouvoir considrer les modles (architectures et mtaarchitectures) comme entit de premire classe, et de pouvoir leur appliquer diverses oprations, en particulier, les transformations permettant limplmentation du systme sur diffrentes plates-formes dexcution. Dans ce chapitre, nous prsentons une approche d'intgration de larchitecture logicielle COSA au sein de MDA par lutilisation dun nouveau profil UML ddie larchitecture logicielle COSA dont loriginalit, outre le fait quil traite le problme de mta-architecture peu tudi dans les ADLs. Il rsiderait dans la nature de sa spcialisation. Ainsi nous dfinissons une stratgie de transformation directe par lutilisation de celui-ci, pour llaboration des transformations PIM (Platform Indpendent Model) vers PSM (Platform Specific Model) et PSM vers PSM.
4.2 La projection de COSA en UML 2.0

Plusieurs travaux ont t raliss sur la modlisation des concepts des ADLs en UML. Ces travaux peuvent tre classs en deux catgories : des travaux visant des ADL particuliers comme par exemple ACME vers UML, Wright vers UML, et dautres ciblant des ADLs gnriques, c'est--dire comportant des concepts architecturaux communs plusieurs ADLs. Dans cette section nous nous concentrons principalement sur la construction dun profil UML 2.0 de COSA. Nous dfinissons un ensemble de base de strotypes en utilisant les possibilits du profil UML (mtamodle et modle) pour dfinir une spcification complte et structure des architectures logicielles (Alti, Khammaci, Smeda, 2006 ; Alti, Khammaci, Smeda, 2007a). En COSA, nous considrons
83
quune architecture est smantiquement valide si ses lments architecturaux (composants, connecteurs, configurations) sont smantiquement valides.
4.2.1 Pourquoi la projection de COSA en UML?

Durant la dernire dcade, UML est devenu un langage standard de spcification, de visualisation, de construction et de documentation des systmes logiciels. En plus des concepts proposs dans UML 1.4, la nouvelle version UML 2.0 propose de nouveaux concepts et raffine plusieurs autres concepts dj existants. Les nouveaux concepts et les modifications sur les concepts dans UML 2.0, fournissent un vocabulaire riche pour documenter une architecture logicielle et aider rsoudre la plupart des problmes dus lutilisation des prcdentes versions du langage UML. Les concepts dUML 2.0 (Object Management Group, 2004a), sont suffisamment gnriques pour tre utiliss dans la description darchitecture logicielle, y compris : 1. La dfinition des composants comme genre de Classifier, ainsi les composants
peuvent avoir des instances et avoir accs certains mcanismes tels que le sous typage par la relation de gnralisation, la description comportementale, la structure interne, les interfaces et les ports. 2. La redfinition des interfaces qui peuvent inclure non seulement des interfaces
fournies mais des interfaces requises. 3. 4. Lintroduction des ports comme des points dinteraction pour les Classifiers. Lintroduction des Structured Classifiers pour reprsenter la structure interne
(dcomposition) des Classifiers. 5. Lintroduction des connecteurs pour reprsenter une liaison entre deux ou
plusieurs instances. Nanmoins, les connecteurs dans UML 2.0 sont dfinis par une liaison simple entre deux lments. Ils ne peuvent pas tre associs une description comportementale ou aux attributs qui caractrisent la connexion. COSA supporte les composants composites et dfinit explicitement les connecteurs comme des concepts architecturaux abstraits. Donc, il est trs utile de dfinir une projection des concepts de COSA vers UML. Lintrt fondamental est denrichir UML de charges smantiques propres larchitecture logicielle COSA, mais aussi, de profiter de:
84
la varit des avantages de COSA (cf. section 3.2.4) telle que la dfinition explicite des connecteurs, le support fort de la rutilisation et les vues multiples de dploiement. niveau dabstraction haut et degr de rutilisation de COSA. smantique riche des concepts architecturaux COSA et de capitalisation architectures logicielles. rsolution des problmes dambiguts et des problmes dinteraction des services. Compar COSA, UML est une norme dominante pour lanalyse et la conception des systmes logiciels et fournit : une varit doutils qui sont mis en application pour UML, par exemple, Rational Rose, Microsoft Visual Studio, Poseidon pour UML, IBM Rational Software Modeler, Entreprise Architecte. La plupart de ces outils fournissent des services de gnration de code dans diffrents langages tels que C++, Java, C#, etc. lapproche MDA (Model Driven Architecture), qui vise fournir un cadre prcis et efficace pour la production et la maintenance du logiciel (Frankel, 2003). la varit des avantages dUML (cf. section 2.3.4) telles que les vues multiples, une smantique semi-formelle et des mcanismes dextension exprims comme des profils UML, un langage associ puissant pour exprimer des contraintes (OCL : Object Constraint Language (Warmer, Kleppe, 1998)) et un raffinement jusqu des
limplmentation. Si le nombre de modles de base (core model) disponibles est faible, il nest cependant pas fig. Le dispositif MDA est extensible par le biais de nouveaux modles, dautant que la dmarche MDA laisse en suspens de nombreux challenges. La prise en compte des applications hrites (legacy applications) de prcdents dveloppements et la gestion de linteroprabilit entre intergiciels sont des points cits frquemment par lOMG au nombre des pistes explorer. Plus concrtement, lapproche UML Profile consiste tendre le mtamodle UML en ajoutant de nouveaux concepts des ADLs. Cette opration se fonde sur lutilisation de strotypes, de valeurs marques (tagged values) et de contraintes OCL (Warmer,
85
Kleppe, 1998), Lavantage reconnu de cette approche est lutilisation des outils UML. Linconvnient majeur rside dans la difficult apprhender la sparation entre la mta-mta-architecture, la mta-architecture et larchitecture. Le terme dialecte UML est utilis pour qualifier cette situation. A lheure actuelle, lapproche profil UML est une approche populaire. Actuellement, certaines recherches menes par la communaut ADL portent sur le dveloppement de langages gnriques de seconde gnration . Lapproche ADL issue des milieux acadmiques ne sest pas impose : il lui est souvent reproch dutiliser des notations formelles difficiles mettre en uvre et de fournir des outils peu exploitables. Les recherches prennent ainsi une nouvelle orientation, en direction des travaux de lOMG. Ces deux communauts ont travaill en parallle ces dernires annes, la pauvret dUML en matire de concepts architecturaux logiciels expliquant probablement cela ou du moins en partie. Aujourdhui, lintgration de la notion de composant dans UML 2.0, peut aussi tre interprte comme un signe de cette volution et laisse entrevoir la possibilit de dfinir des architectures ( base de composants) dont le passage vers les plates-formes dexcution adaptes sera facilit. Nous souhaitons allier les avantages de lapproche ADL et de lapproche MDA de lOMG. De lapproche ADL, nous retenons les notions et mcanismes inhrents aux composants, connecteurs et architectures. Quant lapproche MDA base sur les profils UML, elle prsente lavantage de pouvoir considrer les modles (dans notre cas, architectures et mta-architectures) comme des entits de premire classe, en particulier, des transformations permettant limplantation du systme sur diffrentes plates-formes dexcution. Nous situons notre proposition dans cette dernire tendance. Concernant le point de vue technique de notre profil UML 2.0 COSA, nous avons opt pour lapproche de UML profile qui rpond explicitement aux lacunes de lapproche MDA, au regard des langages de description darchitecture savoir : labsence des concepts reprsentant les connecteurs, labsence des concepts reprsentant les
configurations, labsence des concepts reprsentant la glu, etc.
86
4.2.2 Projection dun ADL vers UML via les mcanismes dextensibilits
UML est un langage gnrique pouvant tre adapt aux langages de description des architectures logicielles grce aux mcanismes dextensibilit offerts par ce langage tels que strotypes, valeurs marques et contraintes. Les mcanismes dextensibilit offerts par UML permettent dtendre UML sans modifier le mtamodle UML. Plusieurs travaux permettent dadapter aussi bien UML 1.x que UML 2.0 aux architectures logicielles. Ces travaux peuvent tre classs en deux catgories : des travaux visant un ADL particulier comme par exemple Acme vers UML, Wright vers UML, et dautres ciblant des ADL gnriques c'est--dire comportant des concepts architecturaux communs plusieurs ADL. Dans (Medvidovic et al. 2002), les auteurs ont prsent deux approches pour exprimer les lments architecturaux avec les notations du langage UML 1.4. La premire approche utilise le langage UML tel quil est , alors que la seconde propose dutiliser des extensions dUML (strotypes, valeurs marques, contraintes) pour incorporer les concepts de trois langages de description darchitectures (C2, Wright et Rapide). La projection de C2 est prsente dans le tableau 4.1 et la projection de Wright est dans le tableau 4.2. Dans (Garlan, Cheng, Kompanek, 2002), les auteurs ont slectionn des notations UML 1.4 pour reprsenter des lments architecturaux, en prenant en considration les
avantages et les limites de chaque notation et ont constat que les aspects darchitecture logicielle base de composants sont difficilement reprsentables dans UML 1.4. Ce qui nous conduisons dire que les premires versions dUML ne sont pas suffisamment adquates pour reprsenter les concepts architecturaux tels que les composants, les connecteurs, les configurations, les interfaces (ports et rles) ou les styles architecturaux. UML 2.0 (Object Management Group, 2004a) a t enrichi par de nouveaux concepts architecturaux comme les connecteurs, les ports, classifieurs structuraux et a redfini le concept de composants qui devient une sous-classe de la classe de mta-modle UML. En outre, un composant a aussi plus de caractres expressifs que les classes (il peut avoir des interfaces et contenir d'autres composants ou classes), etc.
87
Dans (Goulo, Abreu, 2003), les auteurs tablissent un profil UML 2.0 pour ACME. Ils regroupent des concepts communs et minimaux des ADLs. Ils considrent aussi les connecteurs comme des composants strotyps sans autres interfaces, que celles qui sont dfinies par leurs rles et leurs proprits. Cependant, dcrire les connecteurs comme des composants peut encombrer la conception et rendre sa structure globale difficile comprendre et les rles de connecteurs et les ports de composants difficiles distinguer. De ce fait, ils ne profitent pas des nouvelles notations du langage UML 2.0. Le tableau 4.3 illustre la projection de dACME vers UML 2.0. Dans (Roh, Kim, Jeon, 2004), les auteurs signalent quelques faiblesses de ce travail, lies notamment la reprsentation propose du connecteur (au sens dADL) en UML 2.0 et proposent un ADL gnrique sous forme dun profil UML 2.0. Dans ce travail, on note notamment lutilisation des collaborations UML 2.0 pour reprsenter des connecteurs ADL. De plus, un autre aspect intressent se dgage : type et instance de connecteur sont modliss par deux strotypes. En effet, le type de connecteur est dfini comme strotype base de mtaclasse Collaboration dUML 2.0. Linstance de connecteur est dfinie comme un strotype base de mtaclasse Connector dUML 2.0. Mais ce travail ne traite pas les aspects comportementaux des ADLs. Dans (Ivers et al. 2004), Ivers et al. ont tudi la convenance des nouvelles notations UML 2.0 pour la projection de la vue composants et connecteurs (C&C) de larchitecture logicielle, en particulier le langage de description darchitecture ACME. Ainsi, ils ont tudi la projection de chaque concept du langage ACME li la vue C&C (composant, connecteur, ports, rles) vers UML 2.0. Ils ont choisi la correspondance smantique, la clart visuelle et le support par des outils comme critre de base pour choisir les notations dUML qui peuvent reprsenter la description architecturale. Pour chaque notation, il a t propos deux choix, sauf pour les attachements qui nont pas t considrs, comme le montre le tableau 4.4. Il a t conclu, que mme si les nouvelles notations ont amlior la description de larchitecture logicielle en utilisant UML, elles prsentent toujours des inconvnients majeurs. Dailleurs, des aspects de description architecturale continuent tre problmatiques. Par exemple, UML 2.0 manque de possibilit associer une information smantique un connecteur pour dcrire son
88
comportement. Aussi, UML 2.0 ne distingue pas, les rles qui sont les interfaces des connecteurs et les ports qui sont les interfaces des composants. Oquendo (Oquendo, 2006) a propos un profil UML 2.0 pour l'ADL formel ArchWare. Il fournit des notations visuelles pour modliser formellement les architectures logicielles statiques et dynamiques en UML 2.0 tout en utilisant un outil avec une gnration de code vers java (Alloui, Oquendo, 2004). (Graiet et al. 2006) ont propos un profil UML 2.0 pour lADL formel Wright. Il dcrit les expressions CSP de Wright par une machine abstraite tats de description de protocole (Protocol State Machine) UML 2.0 strotyps. Dailleurs, les oprations des ports et les rles sont modlises explicitement et sont exprimes plus formellement via une machine abstraite tats de description de protocole. Ce travail est diminu,par le manque partiel des moyens et des techniques de projection des composants et des connecteurs composites et styles darchitectures. Plus rcemment, (Amirat, Oussalah, 2009) ont propos un profil UML pour C3. Ce travail est diminu des techniques de projection des composants et des connecteurs architecturaux vers les plates-formes dexcution objet (CORBA, EJB, etc.).
4.2.3 Profil UML 2.0 pour larchitecture logicielle COSA

4.2.3.1 Pourquoi la dfinition dun profil UML 2.0 pour COSA ? Lintrt primordial dun profil UML 2.0 de COSA est de fournir des moyens standards pour exprimer la smantique de ses concepts en utilisant les nouvelles notations UML 2. En dautre terme, lutilisation des extensions et des standards dUML 2.0, permet prcisment de mieux capturer les concepts du modle de COSA en fournissant un ensemble de strotypes. Ainsi, nous profitons des possibilits offertes par le profil UML (mtamodle et modle) pour dfinir une spcification complte et structure de larchitecture logicielle COSA. Le tableau 4.5 rsume la diffrence entre les concepts de COSA et ceux dUML 2.0.
89
C2 Component (Type)
Connector (Type)
Port Role System
Message Interface
UML 1.4 C2Component (instances de mtaclasse Class) C2Connector (instances de mtaclasse Class) C2AttachOverComp (instances de mtaclasse Association) C2AttachUnderComp instances de mtaclasse Association) C2AttachConnConn (instances de mtaclasse Association) C2Interface (instances de mtaclasse Interface) C2Interface (instances de mtaclasse Interface) C2Architecture (instances de mtaclasse Model) C2Attach C2Operation (instances de mtaclasse Operation) C2Interface
OCL/Valeurs marqus C2Component doit implmenter exactement deux interfaces. C2Connector doit implmenter exactement deux interfaces. C2Attachments sont des associations binaires, une extrmit dattachement doit tre un C2Compoenent et lautre extrmit un C2Connector.
Larchitecture est un rseau de concepts C2. C2Operation sont tiquetes en tant que notifications ou demande et comme entrantes ou sortantes
Table 4.1 Projection de C2 vers UML 1.4.

Wright Component (Type) Connector (Type) UML 1.4 WrightComponent (instances de mtaclasse Class) OCL/Valeurs marqus WrightComponent doit implmenter au moins une WrightInterface. WrightConnector (instances de WrightConnector doit implmenter mtaclasse Class) au moins une WrightInterface. WrightGlu (instances de WrightGlu contient un mtaclasse Operation) WrightStateMachine.
Port
WrightInterface (instances de mtaclasse Interface) Role WrightInterface (instances de mtaclasse Interface) System WrightArchitecture (instances de mtaclasse Model) WrightAttachment (instances de mtaclasse Association) CSP protocol WSMTransition (instances de (state machine) mtaclasse Transition) WrightStateMachine (instances de mtaclasse StateMachine) Interface WrightInterface(instances de mtaclasse Interface)
Architecture est compose des instances de composants et de connecteurs. Toutes les transitions composes dans un WrightState doivent tre des WSMTransitions. WrightInterface sont tiquetes en tant que ports ou rles.
Table 4.2 Projection de Wright vers UML 1.4.
90
ACME Component (Type) Connector (Type) Port
UML 2.0 AcmeComponent AcmeConnector Port
Role
AcmeRole
OCL/Valeurs marqus Les composants ont seulement des interfaces dites des ports ou des proprits. Les connecteurs nont aucune autre interface que celles dfinies par leurs rles. Les ports peuvent seulement tre utiliss avec des composants dAcme et ils ont une interface fournie et une interface requise. Les rles sont lis aux connecteurs dAcme et ils ont une interface fournie et une interface requise. Les systmes reprsentent un graphe de composants qui communiquent entre eux. Tous les connecteurs de dlgation relient des ports et des rles. Un port de AcmeProperty possde une interface fournie qui doit fournir les oprations de get et de set pour la valeur et le type de la proprit. Ce strotype doit avoir un attribut numr avec deux valeurs permises : invariable et heuristique. Tous les connecteurs utiliss dans un systme de pipe-filtre doivent conformes PipeT.
System Rep-maps Properties
AcmeSystem Delegation connector AcmeProperties
Properties Style (Family)
AcmeConstraints Package
Table 4.3 Projection dACME vers UML 2.0.

ACME Component (Type) Connector (Type) Port Role Attachment Choix 1 Object (Classe) Lien Objet (Classe dAssociation) Port Port Choix 2 Composant instance (Composant) Objet (Classe) Port Port Connecteur dassemblage
Table 4.4 Projection dACME vers UML 2.0. Le langage UML 2.0 offre des moyens plus explicites pour reprsenter les ports, les proprits et les contraintes, et dautres moyens pour spcialiser et tendre les concepts UML 2.0 pour documenter des concepts architecturaux comme les composants, les connecteurs ou les configurations, en utilisant des correspondances avec les concepts dUML 2.0. Ainsi, la dfinition de strotypes appliqus sur des mtaclasses dUML 2.0 reflte mieux la smantique des caractristiques de modle COSA (Alti, Khammaci, Smeda, 2007a). Ainsi, il est ncessaire de dfinir un profil UML 2.0 dans le domaine des architectures logicielles.
91
COSA Composant
Une composant fournit des services via des ports. Ces services doivent faire parties de son interface. Un composant spcifique assurant des services de communication, de facilitation, de conversion des composants mtier. Un graphe des composants et des connecteurs. Elle considrer comme tant un type. Contenant les ports dun composant/configuration ou les rles dun connecteur. Associ un ou plusieurs services des composants ou des configurations. Associ un ou plusieurs services des connecteurs. Jouer un rle dun composant, dun connecteur ou dune configuration. Assurer la communication des composants. Un rattachement physique entre un composant et un connecteur. Un rattachement physique entre un port externe (rle externe) et un port interne (rle interne). Un rattachement physique entre un port/rle et un service. Un composant architectural peut tre hrite dune ou de plusieurs composants architecturaux de mme type.
UML 2.0
Une classe enrichie.
Connecteur
Une relation simple de communication.
configuration Interface Port Rle Service Glu Attachement Binding Use Extend
Un assemblage des composants (composants composites) Permet dassurer les mthodes requis/fourni des composants Associ une ou plusieurs interfaces. / / / Une relation dassociation entre deux composants. Une relation de dpendance entre une interface (port) externe et une interface interne (port). / Une classe peut tre hrite dune ou de plusieurs classes.
Table 4.5 COSA vs UML 2.0. Lintrt primordial de dfinition dun profil UML est de reprsenter les concepts COSA en utilisant les notations UML 2.0. Par consquent, la reprsentation et la formalisation du modle COSA, en utilisant les profils UML permettent lintgration de larchitecture logicielle COSA au sein de la dmarche MDA (Model Driven Architecture) qui unifie toutes les approches de modlisation. De mme, lutilisation des strotypes et tagged-values (valeurs marques), et les contraintes permettent de mieux capturer le smantique des concepts de COSA. Donc, nous profitons des profils UML 2.0, pour dfinir une spcification complte et structure de larchitecture logicielle COSA et la ralisation de la projection des concepts de COSA vers UML 2.0 (Alti, Khammaci, Smeda, 2007a).
92
4.2.3.2 Dfinition du profil UML 2.0 pour COSA A linstar de la plupart des autres langages de description darchitectures (Medvidovic, Taylor, 2000), le langage COSA perd tous ses atouts ds quil est projet au niveau implmentation dans la mesure o il est ne permet que de dcrire un systme informatique de manire abstraite. Comme le passage du langage UML2.0 vers des plates-formes objets est vident, une solution serait de raliser un mapping des concepts de COSA vers les concepts dUML2.0. Lintrt de cette solution est de permettre la projection de larchitecture abstraite COSA vers une architecture concrte objet et de pouvoir utiliser tous les outils UML. Les nouveaux concepts et les modifications sur les concepts dans UML 2.0 fournissent un vocabulaire riche pour documenter une architecture logicielle et aider rsoudre la plupart des problmes dus lutilisation des prcdentes versions du langage UML. Avec la version UML 2.0, il y a plusieurs manires de reprsenter tout concept architectural, ce qui conduit plusieurs stratgies de transformation qui peuvent tre utilises pour reprsenter les diffrents concepts de COSA. La projection dune architecture abstraite telle que COSA sur une autre architecture concrte comme UML 2.0, doit suivre un processus progressif qui transforme la plupart des lments architecturaux abstraits par de nouveaux lments architecturaux concrets. Nous proposons de transformer chaque concept architectural dans le modle COSA laide du profil UML 2.0. En se basant sur certains critres comme la clart, les dtails capturer et le degr de smantique pour reprsenter les diffrents concepts de COSA, nous ralisons la projection des concepts architecturaux de COSA vers les concepts UML 2.0. Nous avons besoin de supporter la dfinition explicite des connecteurs, indpendante de nimporte quel usage et de supporter, les capacits dassociation des proprits smantiques, et de trouver une meilleure reprsentation pour dcrire des interactions entre les sous composants travers des sous connecteurs. 4.2.3.2.1 Les niveaux d'abstraction Le but du profil COSA est dtendre UML 2.0 pour reprsenter les concepts architecturaux COSA. Ce profil fournit une manire pratique pour intgrer larchitecture logicielle au sein de framework MDA (Modle Driven Architecture), qui unifie toutes les approches de modlisation.
93
Pour dfinir un profil UML 2.0 de COSA, nous proposons une hirarchie trois niveaux dabstraction comme le montre la figure 4.1 (Alti, Khammaci, Smeda, 2007a) : Le plus haut niveau (M0) contient les diffrents concepts de base pour dfinir larchitecture COSA, le second niveau (M1) contient les modles darchitectures, le troisime niveau contient les instances de ces modles (A0).
La relation entre les niveaux M0-M1 est ncessaire pour vrifier la cohrence des modles, alors que la relation entre les niveaux M1-A0 permet de gnrer plusieurs instances darchitectures.
Profil COSA apply SimpleCS

instance instance
arch1
arch2
Figure 4.1 Exemple dinstances pour le systme Client-Serveur. 4.2.3.2.2 Le niveau de mtamodle (M0) Le niveau le plus lev contient les diffrents concepts de base pour dfinir larchitecture COSA Le mtamodle de COSA est dcrit comme un package UML strotyp nomm COSA. Ce package doit inclure un ensemble de strotypes : COSAComponent, COSAConnector, COSAConfiguration, etc. Ces strotypes correspondent aux mtaclasses du mtamodle UML avec toutes ses valeurs marques et ses contraintes OCL (Object Constraint Language) (Object Management Group, 2005). La figure 4.2 prsente ce mtamodle.
94
Figure 4.2 Le profil COSA. Critre de choix de projection Les conventions et rgles de transformation vers UML 2.0, ont t choisies en fonction des critres par Garlan (Garlan, Cheng, Kompanek 2002 ; Ivers et al. 2004 ; Medvidovic et al. 2002), pour comparer leurs diffrentes stratgies de reprsentations des concepts architecturaux en UML. Les deux approches comportent chacune des avantages et aussi des inconvnients, que nous rsumons ci-dessous en fonction des quatre critres suivants :
95
lutilisation des nouveaux concepts architecturaux dUML 2.0 : les rgles de transformation doivent sappuyer sur lutilisation des concepts tels que les composants ou connecteurs UML nouvellement introduits dans UML 2.0, et proposs par Garlan (Ivers et al. 2004) ; la sparation visuelle entre composant et connecteur : la volont de Garlan (Garlan, Cheng, Kompanek 2002), de bien sparer de composant logiciel de celui de connecteur logiciel, est une des consquences du critre de lisibilit visuelle. la limitation au domaine des composants logiciels : UML est dcoup en diagrammes, qui proposent pour chacun deux, un ensemble de concepts spcifiques au domaine associ. Alors, il faut choisir un type de diagramme, et par voie de consquence ses concepts associs. Les rgles de transformation sorientent donc vers le diagramme UML de composants, et permettent ainsi dobtenir une meilleure compatibilit avec les outils support. Spcification des correspondances via un profil UML La transformation du modle COSA vers celui dUML 2.0 doit suivre un processus progressif qui transforme la plupart des lments architecturaux abstraits en de
nouveaux lments architecturaux concrets. Nous proposons de transformer chaque concept architectural du modle COSA laide de profil UML 2.0. Pour cela, les choix possibles varient suivant certains critres comme la clart, les dtails capturer et le degr de smantique entre les concepts des deux types darchitectures. Le choix est port sur le composant dUML 2.0 pour la reprsentation des composants et des configurations COSA, mais ces derniers restent bien distincts grce aux strotypes quon leur associe. Les connecteurs COSA sont des types explicites et peuvent tre rutiliss, ils sont reprsents par des classes strotypes dUML 2.0. Une telle transformation des concepts Composants/Connecteurs est alors trs lisible, permet de capturer tous les dtails des concepts de COSA et reprsente fidlement la smantique associe chaque concept de COSA. Le tableau 4.6 rsume les
correspondances entre chaque concept de COSA et un concept dUML.
96
COSA Architectural-Element
UML 2.0 ArchitecturalElement (instances de mtaclasse Class)
Component (Type)
ComponentInterface
Port
Connector (Type)
ConnectorInterface
Role
Glu
OCL/Valeurs marqus Les lments architecturaux COSA ayant seulement des proprits, contraintes et implmentations COSA. COSAComponent est une spcialisation de ArchitecturalCOSAComponent Element (instances de mtaclasse COSAComponent doit avoir Component) seulement des ports ComponentInterface. Marque par le cible : Type-Interface - ComponentInterface est porte seulement par COSAComponent ou <<ComponentInterface>> COSAConfiguration - ComponentInterface doit avoir au (instances de mtaclasse moins un COSARequiredPort ou Port) COSAProvidedPort ComponentInterface est une spcialisation RequiredService ou ProvidedService Marque par le Mode : ModeCOSAPort (instances Connexion de mtaclasse Ineterface) COSAPort est port par ComponentInterface COSAConnector est une spcialisation de ArchitecturalCOSAConnector Element (instances de mtaclasse - COSAConnector doit avoir seulement Class) des rles ConnectorInterface et une seule COSAGlu. ConnectorInterface est porte seulement par les ports de ConnectorCOSA <<ConnectorInterface>> - ConnectorInterface doit avoir au (instances de mtaclasse moins un COSARequired-Role et Port) COSAProvidedRole ConnectorInterface est une spcialisation de Connector-Service Marque par le Mode : ModeCOSARole (instances Connexion de mtaclasse Ineterface) COSARole est port par ConnectorInterface seulement des COSACOSAGlu (instances de Relie RequiredRole et des COSAmtaclasse ProvidedRole. AssociationClass) COSAConfiguration (instances de mtaclasse Component) - COSAConfiguration peut avoir des ports Component-Interface. - Configuration se compose de types (composants et connecteurs), contient au moins un COSAComponent
Configuration (Type)
97
Attachment Binding Use
Assemnbly connector Delegation connector Use (instances of meta class Association) Service (instances de mtaclasses Class) Connector-Service (instances de mtaclasses Class) COSANonFuncProp (instances de mtaclasses Property) Implementation (instances de mtaclasses Class) COSAConstraint (instances de mtaclasses Constraint)
Tous les connecteurs dassemblage relient des ports et des rles. Tous les connecteurs de dlgation relient deux ports ou deux rles. Use doit relier seulement les ports et les services (ou rles et ConnecteurService) Le propritaire ComponentInterface est
Service
Connector-Service
Properties
Implementation
Marqu par un attribut numre type : Type-Service Le propritaire est ConnectorInterface COSANonFuncProp correspond un attribut dun lment architectural COSA. COSAImplementation est une classe dimplmentation dun lment de COSA. Toutes les contraintes doivent tre invariantes de COSA
Constraint
Table 4.6 Projection de COSA vers UML 2.0. Llment architectural Llment architectural est un concept qui dfinit tous les concepts architecturaux de COSA. Ce concept na pas de correspond explicite dans UML. Ainsi, le profil UML doit inclure un strotype pour le reprsenter. Nous appelons ce strotype
COSAArchitecturalElement. Il correspond la mtaclasse Class du mtamodle UML. Ce dernier introduit le nouveau concept EncapsuledClassifier, qui permet une classe, de pouvoir contenir des ports en tant que point dinteraction, associs par des interfaces Fournies et Requises . Une classe UML peut avoir des proprits et des contraintes et peut tre implmente par une autre classe. Ceci peut tre dcrite dans OCL comme suit :
context UML::InfrastructureLibrary::Core::Constructs::Class inv :self.isStereotyped(COSAArchitecturalElement) implies (self.ownedAttribute->forAll->(a|a.isStereotyped(COSAProp))) and (self.ownedRule->forAll->(r|r.isStereotyped(COSAConstraint)))and (self.clientDependency.target->forAll->(t|t.isStereotyped(COSAImp))
98
Les proprits Les proprits fonctionnelles de COSA sont quivalentes au concept dattributs dUML alors que les proprits non fonctionnelles sont reprsentes par des attributs strotyps COSANonFoncProp dans la mesure o elles sont diffrentes au sens smantique puisque les attributs en UML sont des proprits structurelles qui constituent une classe. Chaque attribut ayant un type et auquel on peut donner une valeur pour linstance de llment architectural. Les contraintes Chaque lment architectural peut avoir des contraintes, qui sont des restrictions et conditions qui doivent tre vrifis tout moment. Dans UML 2.0, lOMG dfinit formellement les contraintes OCL 2.0 (Object Constraint Language) (Object Management Group, 2005). Les contraintes UML exprimes via le standard OCL sont utilises pour documenter les contraintes de COSA. Limplmentation La classe correspondante au concept dimplmentation COSA dans UML 2.0. Une classe strotype COSAImplementation est dfinit seulement par un lment architectural COSA et ne possde pas des ports. Cette contrainte peut se dfinir dans OCL de la faon suivante :
context UML::InfrastructureLibrary::Core::Constructs::Class inv :self.isStereotyped(COSAImplementation) implies (self.ownedPort->isEmpty()) and (self.owner->forAll->o|o.isStereotyped(COSAArchitecturalElement)))
Les composants Un composant en UML 2.0 est plus expressif quune classe UML 2.0 et offre des services via les ports associs par des interfaces Fournies et Requises . Un composant est considr comme un type remplaable, possde la spcification de dploiement et il convient mieux aux composants COSA. Le type de composant de COSA est le type de composant dans UML 2.0, et les instances de composant de COSA correspondent aux instances de composant dUML 2.0. Tout composant strotyp COSAComponent doit avoir au moins un port strotyp ComponentInterface. Cette contrainte peut se dfinir dans OCL de la faon suivante :
99
context UML::InfrastructureLibrary::Core::Constructs::Component inv :self.isStereotyped(COSAComponent) implies (self.ownedPort->size()>=1) and (self.ownedPort->forAll-(r.isStereotyped(ComponentInterface)))and (self.clientDependency.target->select ->(t|t.oclIsKindOf(Interface)))->isEmpty())
Les connecteurs Les types de connecteurs COSA sont explicites et peuvent tre rutiliss. La classe UML dfinit clairement le type de connecteur dans COSA et les instances du type de connecteur correspondent aux instances dune classe UML 2.0. Toute classe strotype COSAConnector doit avoir au moins un port strotyp ConnectorInterface et possde une seule classe dassociation strotype COSAGlu. Cette contrainte peut se dfinir dans OCL de la faon suivante :
context UML::InfrastructureLibrary::Core::Constructs::Class inv :self.isStereotyped(COSAConnector) implies (self.ownedPort->size()>=1) and (self.ownedPort->forAll->r.isStereotyped(ComponentInterface))) and (self.member->select(m|m.oclIsTypeOf(AssociationClass)) ->forAll->(isStereotyped(COSAGlu)))->size()=1) and (self.clientDependency.target->select ->(t|t.oclIsKindOf(Interface)))->isEmpty())
La glu Un connecteur COSA dfinit le comportement local de chacune des parties en interactions. Ces comportements sont combins pour former une communication via le concept de glu. Dans UML, le concept de classe association strotype COSAGlu est parfaitement identique mais il reste dfinir sa smantique avec la contrainte OCL suivante:
context UML::InfrastructureLibrary::Core::Constructs::AssociationClass inv :self.isStereotyped(COSAGlu) implies (self.owner.isStereotyped(COSAConnector)) and (self.memberEnd->select-> (t|t.type.isStereotyped(COSAProvidedRole))->size ()>=1)and self.memberEnd->select-> (t|t.type.isStereotyped(COSARequiredRole))->size ()>=1)and (self.memberEnd->forAll->(m|m.lowerBound()=2)
Les configurations Un aspect important de larchitecture COSA est celui de configuration qui est un graphe de composants et de connecteurs. Comme un composant UML peut contenir des sous-
100
composants et des sous-classes, les configurations COSA sont projetes vers un graphe de composants UML avec la contrainte OCL suivante :
context UML::InfrastructureLibrary::Core::Constructs::Component inv :self.isStereotyped(COSAConfiguration) implies (self.ownedPort->forAll->(r.isStereotyped(ComponentInterface)))and (self.member->select(m|m.oclIsKindOf(Component))->forAll ->(c|c.isStereotyped(COSAComponent)))->size()>=1)and (self.member->select(m|m.oclIsTypeOf(Class))->forAll ->(c|c.isStereotyped(COSAConnector)))->size()>=1)and (self.clientDependency.target->select ->(t|t.oclIsKindOf(Interface)))->isEmpty())
Les interfaces Les ports dans le standard UML 2.0 superstructure dcrivent une vision externe dun encapsulated classifier et offre des interfaces de types fournis et requis garantissant la documentation des interfaces COSA. Nous distinguons deux types dinterfaces (composant et connecteur) et nous intgrons dans le profil deux strotypes : un strotype nomm ComponentInterface, qui sera port par les ports dun composant et un strotype nomm ConnectorInterface qui sera port par les ports dune classe. Les interfaces des composants et des configurations : Le strotype ComponentInterface possde une valeur marque porte sur les ports est nomm cible. Ces valeurs marques peuvent tre composant ou configuration et permettent de prciser le type de port construire, savoir composant ou configuration. En plus de ces valeurs marques, un port strotyp ComponentInterface est dfini seulement par un
COSAComponent ou COSAConfiguration. Elle possde un ensemble non vide de ports. Nous spcifions la restriction par la contrainte OCL suivante :
context UML::InfrastructureLibrary::Core::Constructs::Port inv :self.isStereotyped(ComponentInterface) implies (self.owner.isStereotyped(COSAComponent) or (self.owner.isStereotyped(COSAConfiguration)) and (self.required->size()>=1 or self.provided->size()>=1)and (self.required->forAll->(p|p.isStereotyped(COSARequiredPort)) and (self.provided->forAll->(p|p.isStereotyped(COSAProvidedPort)) and (self.type->size()=1) and (self.type.oclAsType(Class).general->forAll-> (g|g.isStereotyped(RequiredService) or g.isStereotyped(ProvidedService))
101
Les interfaces des connecteurs : chaque port strotype ConnectorInterface est dfini seulement par un COSAConnector et possde un ensemble non vide de rles COSA, nous spcifions la restriction par la contrainte OCL suivante :
context UML::InfrastructureLibrary::Core::Constructs::Port inv :self.isStereotyped(ConnectorInterface) implies (self.owner.isStereotyped(COSAConnector) and (self.required->size()>=1 or self.provided->size()>=1)and (self.required->forAll-> (p|p.isStereotyped(COSARequiredRole)) and (self.provided->forAll-> (p|p.isStereotyped(COSAProvidedRole)) and (self.type->size()=1) and (self.type.oclAsType(Class).general->forAll-> (g|g.isStereotyped(RequiredConnector-Service) or g.isStereotyped(ProvidedConnector-Service))
Les ports et rles

Les concepts dinterfaces Fournies et Requises de UML 2.0 permettent de documenter correctement les interfaces Fournies et Requises de COSA (les ports et les rles), mais elles restent toujours distinctes avec leurs strotypes associs. Un port strotyp COSAProvided-Port est dfini seulement par une interface ComponentInterface et possde seulement des interfaces fournies. Cette contrainte peut se dfinir dans OCL de la faon suivante :
context UML::InfrastructureLibrary::Core::Constructs::Interface inv :self.isStereotyped(COSAProvidedPort) implies (self.owner.isStereotyped(ComponentInterface))and (self.required->size()->isEmpty()) and (self.provided->size()>=1))
Un port strotyp COSARequired-Port est dfini seulement par une interface ComponentInterface et possde seulement des interfaces requises. Cette contrainte peut se dfinir dans OCL de la faon suivante :
context UML::InfrastructureLibrary::Core::Constructs::Interface inv :self.isStereotyped(COSARerquiredPort) implies (self.owner.isStereotyped(ComponentInterface))and (self.required->size()>=1) and (self.provided->size()->isEmpty())
Un port strotyp COSAProvided-Role est dfini seulement par une interface ConnectorInterface et possde seulement des interfaces fournies. Cette contrainte peut se dfinir dans OCL de la faon suivante :
CHAPITRE 3 COSA : Une approche hybride de description darchitecture logicielle context UML::InfrastructureLibrary::Core::Constructs::Interface inv :self.isStereotyped(COSAProvidedRole) implies (self.owner.isStereotyped(ConnectorInterface))and (self.required->size()->isEmpty()) and (self.provided->size()>=1))
102
Un port strotyp COSARequired-Role est dfini seulement par une interface ConnectorInterface et possde seulement des interfaces requises. Cette contrainte peut se dfinir dans OCL de la faon suivante :
context UML::InfrastructureLibrary::Core::Constructs::Interface inv :self.isStereotyped(COSARequiredRole) implies (self.owner.isStereotyped(ConnectorInterface))and (self.required->size()>=1) and (self.provided->size()->isEmpty())
Attachment Un connecteur dassemblage UML est quivalent au concept dattachement de COSA qui est dfini entre un port et un rle COSA. Le port du connecteur COSA de type fourni est reli avec le rle COSA de type requis ou le port COSA de type requis est reli avec le rle COSA de type fourni avec la contrainte OCL suivante :
context UML::InfrastructureLibrary::Core::Constructs::Connector inv :self.isStereotyped(Attachment) implies (self.kind = #assembly) and ((self.end.exists (cp|cp.role.IsCOSAProvidedPort()) and (self.end.exists (cr|cr.role.IsCOSARequiredRole()) or (self.end.exists(cp|cp.role.IsCOSARequiredPort()) and (self.end.exists (cr|cr.role.IsCOSProvidedRole())
Binding Un connecteur de dlgation UML correspond au concept de Binding COSA dfini seulement entre une interface interne et une interface externe. Binding COSA relie deux ports COSA fournis (ou requis) de deux diffrents sous composants dun mme composant COSA avec la contrainte OCL suivante :
context UML::InfrastructureLibrary::Core::Constructs::Connector inv :self.isStereotyped(Binding) implies (self.kind = #delegate) and (self.end.exists (cp1, cp2|cp1<>cp2 and ((cp1.role.IsCOSAProvidedPort()and cp2.role.IsCOSAProvidedPort()) or(cp1.role.IsCOSARequiredPort()and cp2.role.IsCOSARequiredPort())) and (cp1.owner = cp2.owner))
Binding COSA relie deux rles COSA fournis (ou requis) de deux diffrents sous connecteurs dun mme connecteur COSA avec la contrainte OCL suivante :
103
context UML::InfrastructureLibrary::Core::Constructs::Connector inv :self.isStereotyped(Binding) implies (self.kind = #delegate) and (self.end.exists (cr1, cr2|cr1<>cr2 and ((cr1.role.IsCOSAProvidedRole() and cr2.role.IsCOSAProvidedRole()) or(cr1.role.IsCOSARequiredRole() and cr2.role.IsCOSARequiredRole())) and (cr1.owner = cr2.owner))
Use Le concept dassociation correspond au concept de Use dans UML 2.0. Il reprsente le rattachement physique entre un port/rle et un service. Use COSA est dfinie entre un port COSA et Service COSA ou entre un rle COSA et un Service-Connecteur COSA avec la contrainte OCL suivante :
context UML::InfrastructureLibrary::Core::Constructs::Association inv :self.isStereotyped(Binding) implies ((self.end.exists (cp1|cp1.role.IsCOSAPort()) and (self.end.exists (cp2|cp2.role.IsService()) or (self.end.exists(cr1|cr1.role.IsCOSARole()) and (self.end.exists (cr2|cr2.role.IsService-Connector())
Attachement et Binding sont dfinies en utilisant les connecteurs dUML 2.0, le connecteur dassemblage pour lattachement et le connecteur de dlgation pour le Binding. Puisque UML 2.0 noffre pas la capacit dassocier une information smantique aux connecteurs (par exemple, une description comportementale) ou de dcrire clairement les rles de connecteur, on peut donner une smantique plus riche aux Attachment, Binding et Use en les exprimant par des associations relies au ConnecteurCOSA. Dans ce cas, Attachment, Binding et Use sont des sous-types du ConnecteurCOSA et ils peuvent avoir des rles bien dfinies. Extend Le concept dassociation dhritage correspond au concept de Extend dans UML 2.0. Il reprsente le. Extend COSA est dfinie entre un composant COSA et un autre composant COSA ou entre un connecteur COSA et un autre connecteur COSA avec la contrainte OCL suivante :
CHAPITRE 3 COSA : Une approche hybride de description darchitecture logicielle context UML::InfrastructureLibrary::Core::Constructs::Association inv :self.isStereotyped(Extend) implies (self.kind = #extend) and (self.end.exists (cr1, cr2|cr1<>cr2 and and (cr1.type = cr2.type))
104
4.2.3.3.1.1 Le niveau modle (M1) Le niveau M1 permet de dcrire un modle darchitecture spcifique (ex : systme client-serveur) avec lapplication du profil UML 2.0 de COSA. Il peut permettre de dfinir les valeurs marques des strotypes. Dans ce niveau, les contraintes OCL sont vrifies et le systme final projet doit tre conforme au profil UML, comme le montre la figure 4.3. 4.2.3.3.1.2 Le niveau application (A) Ce niveau est un ensemble dinstances des types de composant, connecteur et configuration. Ces instances sont dfinies dans M1. La figure 4.1 illustre deux instances arch1 et arch2 pour le systme Client-Serveur. 4.2.3.3.2 Un exemple de projection : cas du systme Client-Serveur Pour illustrer notre stratgie de projection, nous proposons dutiliser lexemple du systme Client-Serveur. La figure 4.4 dcrit lexemple du systme Client-Serveur en COSA et la figure 4.5 montre la reprsentation de ce mme systme aprs lapplication du profil UML propos. Les valeurs marques de chaque strotype du systme Client-Serveur permettent de prciser les caractristiques des interfaces, des ports et services de COSA, comme le montre le tableau 4.7.
CHAPITRE 3 COSA : Une approche hybride de description darchitecture logicielle COSAConfiguration Client - Serveur COSAComponent Serveur
- COSANonFuncProp password-needed =true - COSANonFuncProp data-type = format-1 + Service Send-date ()
105
COSAConfiguration
COSAConnector
SecurityQuery COSAGlu
Sec_Glu
DataBase-Manager
COSAComponent
DataBase
requestor secManager securityManagement
ComponentInterface
IDataBase
queryIntf
ConenctorInterface
ISecurityQuery
cerdQuery
COSAComponent
SecurityManager
COSAConnector
callee
SQL_Query COSAGlu
ComponentInterface
ISecurityManager
ClearanceRequest COSAGlu
Cle_Glu
DBQueryIntf
COSAConnector
Grantor
secAuthor
ConenctorInterface
ISQLQuery
caller
COSAComponent
ConnectionManager
ComponentInterface
IConnectionManager
extrnalSocket
ConenctorInterface
IClearanceRequset
requset
securityCheck
extrnalSocket extrnalSocket
COSAComponent
Client - COSANonFuncProp request-rate = 21.0 - COSANonFuncProp data-type = format-2 + Service Demand -date ()
provide
COSAConnector
RPC + Type-Service = conversion COSAGlu
GluRPC
conversion () particpateur-1
ComponentInterface
IClient
request
particpateur-2
Figure 4.3 Lapplication du profil pour le systme Client-Serveur
CHAPITRE 3 COSA : Une approche hybride de description darchitecture logicielle Class Configuration client-serveur { Class Component Serveur { Properties {password-needed = true; data-type = format-1;} Constraints {max-clients=1;} Interface { Connection-Mode : synchronous ; Ports provide{provide;} Services provide {Send-data;} Use {Send-data to provide;} } Define-Composition { Class Components { Class Component ConnectionManager { Interface { Ports provide {externalSocket; DBQueryIntf;} Ports request {securityCheck;}} Class Component SecurityManager { Interface { Ports provide {securityAuto;CerdentialQuery;}}} Class Component Database { Interface { Ports provide{queryIntf;} Ports request{securityManagement;}}} Class Connector SQLQuery { Interface { Ports provide{callee;} Ports request{caller;}} Class Connector CleranceRequest { Interface { Ports {grantor; requestor;}} Class Connector SecurityQuery { Interface { Ports provide{securityManager; requestor } } Attachments { ConnectionManager. SecurityCheck to CleranceRequest.requestor; SecurityManager. SecurityAutothorization to CleranceRequest.grantor; ConnectionManager.DBQueryIntf to SQLQuery.caller; Database. queryIntf to SQLQuery.callee; SecurityManager.cerdentialQuery to SecurityQuery.SecurityManager; Database. securityManagement to SecurityQuery. Requestor; } Bindings {ConnectionManager. ExternalSocket to server.provide; } } } Class Component Client { Properties {Request-rate = 21.0; data-type = format-2;} Interface { Connection-Mode : synchronous ; Ports request{request;} Services request {Damend-data;} Use { Damend -data to request;} } } Class Connector RPC { Interface {Roles {callee; caller}} Constraints {max-roles = 2;} Glue {Definition of service.} } Instance client-serveur arch-1 { Instances { S1: server; C1: client; C1-S1: RPC;} Attachments {C1.request to C1-S1. callee; S1.provide to C1-S1. caller; } }
106
Figure 4.4. Systme Client-Serveur dans COSA.

<< COSAConfiguration >>
107
arch1 : Client-Serveur
<<COSAConnector>>
C1-S1 : RPC
<< ConnectorInterface >>
IRPC
Particpateur2 Particpateur1
<< ComponentCOSA >>
<< ComponentCOSA >>
Service
<< ComponentInterface >>
Besoin
S1 : Serveur
C1 : Client
<< ComponentInterface >>
IServeur
IClient
Figure 4.5. Exemple du Client-Serveur en UML 2.0

Concepts UML IClient Besoin IServeur Service IRPC Cible Mode Cible Mode Mode Valeurs Marques = composant = synchrone = composant = synchrone = synchrone
Table 4.7 Dfinition des valeurs marques de chaque strotype.
4.2.4 Synthse
Nous avons prsent la projection des concepts architecturaux COSA vers ceux des concepts dUML 2.0 et ce, en prcisant la faon dont elle est prise en compte par UML. Cette prise en compte passe par lutilisation du profil UML pour COSA. Notre objectif tait de reprsenter les concepts COSA en utilisant les notations UML 2.0. Grce ce profil, il est possible dappliquer lapproche MDA des modles labors sous forme de composants UML 2.0 afin, de gnrer des modles spcifiques pour les plates-formes dexcution. Ces derniers facilitent la gnration de code. Le caractre expressif du langage UML 2.0 est le rsultat de la disponibilit du concept de composant avec les ports qui sont associs par des interfaces Requises et Fournies et du concept de connecteur de types dlgation ou dassemblage. Cependant, UML manque de support explicite pour certains concepts architecturaux tels que les configurations ou les rles. Il ne considre pas les connecteurs comme des entits de premire classe, mais de simples liens entre composants et il ne peut pas modliser directement un composant de communication. Nous avons vu lintrt du profil UML COSA pour prciser le smantique des concepts darchitecture logicielle projeter et ainsi daffiner la faon dont ils sont exploits dans UML.
108
4.3 Architecture logicielle et MDA

En vu, de prciser les notations fondamentales de cette partie de notre travail, nous dcrivons dabord la dmarche MDA, la notion de transformation dans MDA, les profils UML et MDA et ensuite les tapes de la dmarche MDA.
4.3.1 La dmarche MDA (Model Driven Architecture)

L'approche de l'architecture dirige par les modles (MDA) est une dmarche de
dveloppement propose par l'OMG (Object management Group). Les modles de base de MDA sont les entits capables dunifier et de supporter le dveloppement de systmes informatiques en assurant linteroprabilit et la portabilit. Les modles de base comme UML (Unified Modeling Language), CWM (Common Warehouse Metamodel), MOF (Meta Object Facility) reprsentent le noyau de MDA. Les intergiciels reprsentent le niveau dexcution des applications (par exemple CORBA, J2EE, .NET, etc.) et les services normaliss fournissent le support lexcution de ces applications (par exemple la scurit des transactions et des vnements). Tout cet ensemble, de technologies est utilis pour supporter diffrents domaines tels que la finance, le commerce lectronique ou la tlcommunication. Si le nombre de modles de base disponibles est faible, il n'est pas cependant fig. Le principe cl de MDA consiste en lutilisation de modles aux diffrentes phases du cycle de dveloppement dun logiciel. Plus prcisment, MDA prconise llaboration de modles dexigences (CIM), danalyse et de conception (PIM) et dimplmentation (PSM). Lobjectif primordial de MDA est llaboration des modles prennes, indpendants des dtails techniques des plates-formes (J2EE, .Net, PHP ou autres), afin de permettre la gnration automatique de limplmentation des applications et dobtenir un gain significatif de productivit.
4.3.2 Transformation et MDA

La notion de transformation est un aspect de base pour MDA (Model Driven Architecture) (MDA, 2002). Elle vise lautomatisation des transformations de modles. En outre, les profils UML peuvent tre intgrs dans le contexte MDA pour dfinir une
109
chane de transformations de modles de larchitecture vers limplmentation (Frankel 2003 ; MDA, 2002). Dans MDA, les modles sont dfinis comme des entits de
premire classe. La mise en production de MDA passe par la mise en place, de ces modles en relation et leurs transformations. MDA dfinit une transformation entre des modles dexigences (CIM), des modles indpendants des plates-formes (PIM) et des modles spcifiques (PSM). Transformation de modles CIM vers PIM : permet de construire des PIM partiels partir des informations contenues dans les CIM. Lobjectif est de sassurer que les besoins exprims dans les CIM sont retranscrits dans les PIM. Ces transformations sont essentielles la prennit des modles. Ce sont elles, qui garantissent les liens de traabilit entre les modles et les exigences exprimes par un architecte. Transformation de modles PIM vers PIM, permet de raffiner les PIM afin damliorer la prcision des informations quils contiennent. En architecture logicielle, de telles transformations peuvent tre, par exemple la cration des modles comportementaux partir des modles structuraux. Transformation de modles PIM vers PSM, permet de construire une bonne partie des modles PSM partir des modles PIM. Ces transformations sont les plus importantes dans le domaine de larchitecture logicielle, car elles garantissent la productivit des modles et leur lien avec les plates-formes dexcution. Transformation de modles PSM vers code, permet de gnrer la totalit du code. Ces transformations ne sont pas considres comme tant des transformations de modles.
4.3.3 MDA et UML

MDA propose plusieurs mtamodles core model de base, correspondant au niveau M2 de larchitecture de mta-modlisation quatre niveaux (cf. section 2.3.2.3 de chapitre 1). Ces modles sont galement appels UML profiles dans la terminologie MDA. Ils sont ddis une classe de problmes, comme par exemple, Entreprise Computing ou Real-Time Computing . Certains de ces modles sont en phase de standardisation. Ces modles sont indpendants de toute plate-forme. Leur nombre devrait crotre pour couvrir dautres besoins. Cependant, il a vocation rester
110
relativement peu important car chacun se veut gnraliste et regroupe les caractristiques communes tous les problmes de sa catgorie. UML est prconis par lapproche MDA comme tant un langage utiliser pour raliser des modles danalyse et de conception indpendamment des plates-formes dimplmentation. Une stratgie pour dfinir un mtamodle consiste utiliser le mcanisme des profils UML. MDA (Model Driven Architecture), recommande cette approche car le support industriel dUML la rend facile mettre en oeuvre. La dfinition dun profil est une spcification conforme un ou plusieurs points : identification dun mtamodle UML entier, dfinition de rgles de bonne construction ( well-formedness rules ), en plus de celles contenues dans le sous-ensemble du mtamodle UML. Le terme wellformedness rules est utilis dans la spcification normalise du mtamodle. De telles rgles permettent de dcrire un ensemble de contraintes en langage naturel, et laide du langage OCL dUML (Warmer, Kleppe, 1998), afin de dfinir un lment du mtamodle. dfinition dlments standards ( standard elements), en plus de ceux contenues dans le sous-ensemble du mtamodle UML. Le terme standard elements est utilis dans la spcification du mtamodle UML pour dcrire une instance standard dun strotype UML ou une contrainte. dfinition de nouvelles smantiques, exprimes en langage naturel, en plus de celles contenues dans le sous-ensemble du mtamodle UML. UML pour les PIM : le mtamodle UML contient tous les concepts relatifs aux sous-ensemble du mtamodle UML, qui peut tre le
modles UML. UML dfinit plusieurs diagrammes permettant de dcrire les diffrentes parties dune application. Les modles UML sont indpendants des plates-formes dexcution. En outre, le mtamodle UML constitue le mtamodle idal pour llaboration des PIM (Platform Independent Model). UML pour les PSM : les profils UML ciblent les plates-formes dexcution. Grce
aux profils UML, il est possible dutiliser UML pour laborer des PSM. MDA
111
recommande lutilisation de profils UML pour llaboration de PSM et la transformation PIM vers PSM puisque PIM et PSM sont tous deux, des modles UML.
4.3.4 Les tapes de la dmarche MDA

La premire tape du dveloppement dune application base sur MDA est la cration dun modle dapplication indpendamment de la plate-forme (PIM Platform Independent Model) par instanciation du mtamodle utilis. Dans un second temps, des spcialistes de la plate-forme cible sont chargs de la conversion de ce modle dapplication gnral vers CCM, EJB ou vers une autre plate-forme. Des transformations standards (standard mappings), en fonction du core model , permettent denvisager une automatisation partielle de la conversion. A loccasion, ils gnrent, non seulement des artefacts propres la plate-forme (en langage IDL et autres), mais aussi un modle spcifique (PSM). Ce modle est galement dcrit laide du profil UML. On parle alors de dialecte dUML, laissant apparatre, du fait de la transformation des lments lis lexcution sur la plateforme cible. Ceci permet dexprimer de faon plus riche la smantique de la solution quavec IDL ou XML. Ltape suivante est la gnration du code lui-mme. Plus le dialecte UML du PSM reflte la plate-forme cible, plus, la smantique et le comportement de lapplication peuvent tre intgrs dans le PSM, et le code gnr est plus complet peut tre. Parmi les (nombreux) avantages de la dmarche MDA, cits par lOMG, on peut signaler la facilit grer linteroprabilit entre applications laide du mme core model .
4.4 Intgration de larchitecture logicielle COSA au sein de MDA 4.4.1 Les tapes de la dmarche MDA
Larchitecture logicielle fournit un haut niveau dabstraction pour reprsenter la structure dun systme, ce qui permet de rduire sa complexit. Le non respect de larchitecture logicielle dans les plates-formes dexcution comme CORBA, J2EE, .NET, etc. sont les consquences des nouveaux problmes dambiguts et dinteroprabilit. Les intergiciels sont totalement intgrs dans les plates-formes dexcution. Quelque soit le degr dintgration de lintergiciel, il reste toujours difficile de distinguer larchitecture (structure du systme) de limplmentation (code). Cela diminue le degr
112
de rutilisation des logiciels et augmente le cot dun changement dintergiciel. Il sagit dans tous les cas de sparer les aspects darchitecture et des aspects dimplmentation. Les aspects darchitecture sont dfinis en haut niveau dabstraction en terme de composants de systmes et de leurs interconnexions sans aucune dpendance envers la technologie. Par contre, les aspects dimplmentation sont dfinis en bas niveau dabstraction en terme de composants du systme spcifiques aux technologies des plates-formes. La prise en compte de larchitecture logicielle dans les plates-formes dexcution permet de rsoudre l'htrognit et faciliter la communication et la coordination des composants distribus.
4.4.2 Intgration des ADLs au sein de MDA

Plusieurs propositions d'intgration des concepts architecturaux ont vu le jour ces dernires annes. Garlan (Garlan, 2000b), persiste dire que dans le monde de dveloppement du logiciel et dans le contexte dutilisation du logiciel les mthodes changent considrablement. Ces changements sont le rsultat de limpact majeur des manires dutiliser une architecture. Le projet ACCORD RNTL, (ACCORD RNTL Project, 2002) est un environnement ouvert et distribu, fournit une simplicit de dveloppement par lassemblage des composants. Il dfinit une correspondance semi-automatique des concepts et une transformation automatique de modle ACCORD vers Component CORBA Model (CCM). Ce travail se base sur les profils UML pour reprsenter les concepts ACCORD et les concepts CCM. Il dfinit un filtre intermdiaire pour ladaptation du processus de transformation. Ensuite lassemblage des composants est dfinis via les fichiers XML, et donc difficile de garantir la rutilisation des composants. Dans (Rodrigues, Lucena, Batista, 2004), les auteurs dfinis des rgles de projection pour transformer une description de larchitecture ACME vers une spcification CORBA IDL (Barlett, 2004). Ils focalisent la composition des systmes par lexploration des extensions ACME pour inclure les ports dentre/sortie dans la spcification ACME. Ils transforment chaque concept du langage ACME en une interface IDL, et de ce fait, ne profitent pas rellement des concepts disponibles dans CORBA IDL.
113
Dans (Manset, Verjus, McClatchey, Oquendo, 2006), les auteurs exploitent les capacits du langage de description darchitecture Archware et les plates-formes dexcution dans le processus de dveloppement ACMDD (Architecture-Centric Model Driven Developement). Ils intgrent effectivement la vision architecture au sein de MDA. Dans (Marcos, Acuna, Cuesta, 2006), les auteurs proposent une extension de lapproche MDA nomme ACMDA (Architecture-Centric Model Driven Architecture) par lintgration effective des aspects darchitecture. Cette approche considre une architecture comme une entit de premire classe et dfini des modles darchitecture dans deux niveaux dabstraction distincts; un niveau des modles darchitecture indpendant de la plate-forme PIA (Platform Independent Architecture) et un autre niveau des modles darchitecture spcifiques PSA (Platform Specific Architecture). Larchitecture logicielle est considre comme perspective qui permet une meilleure sparation des diffrents aspects (contenu, hypertexte, comportement) envers les niveaux dabstractions, et elle devient un gestionnaire des instances des modles darchitecture. Elle garantit un modle appropri lors de linstanciation du composant. Ce travail est diminu des moyens et des techniques de projection des architectures indpendantes de plate-forme vers architectures spcifiques cause de labsence des langages de description des architectures (ADLs) qui fournissent tous les concepts et les styles architecturaux. Dans (Snchez et al. 2006), les auteurs expriment des liens de traabilit et de raffinement par une transformation des aspects de besoins vers des aspects
architecturaux. Ce travail fournit une structure de framework MDA confortable, une meilleure sparation des proccupations (architecture, exigences) et de plus la prise en compte des aspects darchitecture au sein de framework MDA.
4.4.3 Intgration de lADL COSA au sein de MDA

Labsence de quelques concepts architecturaux (connecteur, configuration, etc.), dans UML 2.0 ainsi que le non respect de larchitecture logicielle dans les plates-formes dexcution comme CORBA, J2EE, .NET, etc. sont les consquences des nouveaux problmes dambiguts et dinteroprabilit. La solution recommande est la dmarche MDA qui fournit des moyens de projection rapide des concepts architecturaux COSA
114
vers UML 2.0 par une transformation de larchitecture abstraite COSA en une architecture concrte UML et des moyens de sparation des proccupations des aspects darchitecture et des aspects dimplmentation par une transformation automatique de larchitecture vers limplmentation dans les plates-formes dexcution. Lintgration des langages de description de larchitecture logicielle (ADLs) telle que COSA; au sein de lapproche MDA est une perspective qui offre aux intervenants de systme et aux plates-formes dexcutions une autre vue de gestion et de maintenance de limplmentation, par consquent limplmentation devient un rsultat de larchitecture qui permet de bnficier de la concrtisation des plans architecturales et de lvolution des architectures logicielles. Les plates-formes MDA offrent une simplicit de dveloppement par lassemblage des composants prfabriqus mais il ne supporte pas des niveaux d'abstraction levs, le concept de connecteur et composant composite. Dailleurs, COSA supporte les composants composites et dfinit explicitement les connecteurs comme des concepts architecturaux abstraits. Donc, il trs utile dfinir une transformation automatique de modle darchitecture logicielle, le PIM (Platform Independent Model) vers un modle de plate-forme dexcution le PSM (Platform Specific Model). L'intrt fondamental est la projection rapide et une meilleure intgration des concepts darchitecture logicielle vers les plates-formes MDA pour aboutir un niveau d'abstraction plus lev et aider rsoudre les problmes d'interactions entre les composants des plates-formes dexcutions. MDA prend en compte les langages de description darchitecture en intgrant leur description aux modles PIM et lors de la transformation PIM vers PSM. Lobjectif de COSA au sein de MDA est de permettre la dcomposition et lorganisation de systme en lments architecturaux comprhensible et facilement manipulables, de migrer facilement dune architecture vers une autre, et donc capitaliser lexploitation des concepts architecturaux COSA et faciliter le passage vers les plates-formes dexcution. La prise en compte des langages de description darchitecture par MDA telle que COSA; se fait sur deux niveaux, dans les PIM (Platform Independent Model) et dans les transformations PIM vers PSM (Platform Specific Model) (voir figure 4.6). Les CIMs (Computation Independent Model) ne sont pas ncessaires ni pour la dfinition des
115
concepts architecturaux COSA ni pour sa projection vers les plates-formes dexcution (Alti, Khammaci, Smeda, Bennouar, 2007c ; Alti, Smeda, 2007).
PIM
Architecture COSA au niveau PIM
PSM CORBA J2EE .NET
Architecture COSA au niveau PSM
Figure 4.6 Intgration de larchitecture COSA au sein de la dmarche MDA. larchitecture COSA au niveau PIM: le mtamodle PIM contient tous les concepts architecturaux relatifs lapproche COSA. Grce au mcanisme du profil UML, on ralise des transformations PIM vers PSM et on intgre les concepts COSA dans UML et dans les plates-formes dexcution. Tous les concepts COSA se retrouvent dans ce mtamodle (PIM). larchitecture COSA au niveau PSM: les transformations PIM vers PSM prcisent la faon dont le standard UML et les plateformes cibles (CORBA, J2EE, etc.), utilisant les modles darchitectures COSA contiennent tous les concepts architecturaux projets et disponibles lexploitation. Cette concrtisation de la transformation des PIM vers PSM prserve la sparation des proccupations. Le modle darchitecture et le modle dimplmentation se trouvent spars dans les modles PIM et PSM et le lien entre ces deux modles rside toujours dans les rgles de transformation. 4.4.3.1 Stratgie de transformation des profils Supposez-nous transformer le modle COSA (PIM) qui conforme au mtamodle COSA, vers un autre modle spcifique de la plateforme MDA (PSM) qui conforme un autre mtamodle. PIM et PSM nont pas les mmes concepts darchitecture. Cela implique que la dfinition des rgles de transformations est assez difficile. Par
consquent, nous proposons le moyen de la transformation directe des profils qui facilite llaboration rapide des rgles de transformations. Les techniques et les mcanismes dextensibilit, fournis par les profils UML sont convenables tre utiliss dans la description darchitecture logicielle. La cl pour achever la vision MDA, est les rgles de transformation de modles. Ces rgles sont dfinies au niveau des
116
mtamodles PIM (COSA) et PSM (profil UML pour COSA et profil UML pour une plate-forme MDA). Lide dlaboration des rgles de transformation de PIM vers PSM est de prendre chaque lment architectural dans le mtamodle PIM et chercher ses correspondances dans le mtamodle PSM (la mme smantique des lments UML de PIM). Chaque lment de correspondance contient une expression OCL 2.0 (OMG, 2005), permettant deffectuer la transformation entre les lments des profils UML pour COSA et la plate-forme MDA, et un filtre pour faire distinction entre eux. En plus, si les lments du profil COSA inclus les spcifications des relations de ses lments, la transformation doit inclure des oprations qui traduisent bien ses relations. 4.4.3.2 Exemple illustrative : la transformation de COSA-UML vers CORBA Pour illustrer la stratgie de transformations systmatiques de transformation de profils, nous lappliquons, de COSA-UML (PSM) vers CORBA (Object Management Group, 2002) (PSM). La figure 4.7 prsente le processus de transformation de larchitecture logicielle COSA vers la plate-forme CORBA. Nous proposons de transformer chaque concept architectural du modle COSA vers COBA laide du profil UML 1.4 pour CORBA (Object Mangement Group, 2001). Les composants COSA sont reprsents par des composants UML 2.0. A chaque composant UML 2.0 correspond une classe UML 1.4 (la classe porte le mme nom que le composant), le composant UML 2.0 COSAComponent peut tre transform vers une classe UML CORBAHome.
MMUML 2.0
PSM Profil UML2.0 pour COSA Profil UML1.4 pour CORBA
Dfinition
MMUML 1.4
PSM
MCOSA
PSM
Excution
MCORBA
PSM
Figure 4.7 Transformation de COSA-UML (PSM) vers CORBA-UML (PSM).
117
Les connecteurs COSA sont reprsents par des classes UML 2.0. Les classes UML 2.0 correspondent aux classes UML 1.4. Ainsi, la classe COSAConnector est transforme vers une classe CORBAHome. Les interfaces de composants et des connecteurs correspondent aux ports UML 2.0. Les ports correspondent aux classes UML (le nom de la classe correspond au nom du port). Ces classes ralisent les interfaces fournies du port et dpendent des interfaces requises par le port. Une classe UML (qui reprsente un composant UML 2.0) doit tre relie une autre classe (qui reprsente des ports). Chaque classe reprsentant un composant ou un connecteur (composants et connecteurs CORBAHome) doit tre rattache des associations dagrgation vers les classes des ports (qui correspondent une classe CORBAComponent). Le tableau 4.8 rsume les principales correspondances entre les concepts de COSA et les concepts de CORBA (Alti, Khammaci, Smeda, Bennouar, 2007 ; Alti, Khammaci, Smeda, 2007b).
Concepts COSA UML 2.0 COSAComponent Composant COSAConnector Classe COSAConfiguration Composant ComponentInterface Port ConnectorInterface Port Concepts CORBA UML 1.4 CORBAHome Classe CORBAModule Package CORBAComponent Classe
Table 4.8 Correspondances COSA CORBA.
4.4.4 Approche MDA centre sur la dcision architecturale

Actuellement, le dveloppement dirig par les modles (Model Driven Development (MDD)) est gnralement bas sur des modles qui sont ddis la production des architectures de qualit. Les dcisions architecturales sont inclus implicitement dans lapproche MDA ce qui conduit un manque de la traabilit des dcisions prises par le concepteur sur les architectures et ainsi un manque de la traabilit des dcisions prises par le dveloppeur sur les implmentations. Cela ncessite une dfinition explicite de cette notion et une considration de premire classe. La dfinition explicite des dcisions d'architectures vise contrler la qualit du processus de dveloppement logiciel. Nous proposons d'tendre le framework MDA en intgrant les aspects de dcisions architecturales et nous proposons aussi de modliser les dcisions architecturales comme une nouvelle dimension dans le processus de MDD.
118
Lintgration des dcisions d'architectures va permettre, dune part, de guider larchitecte pour crer des systmes de qualit et dautre part dintgrer les vritables proccupations des dcisions dans le processus MDD. Lors de l'application de la stratgie du profil UML sur un systme client-serveur on a constat que la dcision architecturale n'tait pas prise en compte. L'architecture logicielle a t conue avec un ADL arbitraire (COSA, Pi-ADL, ACME, etc.) et aussi intgre dans une plate-forme arbitraire (CORBA, EJB, .Net, etc.). Au niveau PIM, lutilisation dun ADL arbitraire la description des systmes logiciels ne rpond pas aux facteurs de qualit des ADLs tels que la rutilisabilit et l'extensibilit. Au niveau PSM, lintgration des concepts dADLs dans une plateforme donne ne rpond pas aux facteurs de qualits tels que la rutilisabilit et la portabilit. Chaque ADL ses mthodes de spcification et danalyses des proprits structurelles et
comportementales des systmes logiciels. Chaque plateforme dimplmentation ses facteurs de qualit tels que la performance et linteroprabilit. On a besoin dun modle darchitecture qui permette de dcrire clairement un systme logiciel. On a besoin galement dintgrer facilement les concepts dADLs dans une plateforme interoprable. Pour cela, nous avons tendu MDA afin de supporter les dcisions de choix des ADLs et les dcisions de choix des plateformes au sein de MDA selon les caractristiques de qualit des ADLs et les caractristiques de qualit des plateformes. 4.4.4.1 Intgration des dcisions architecturales au sein de MDA Une bonne technique pour concevoir une architecture logicielle est dintgrer les heuristiques des dcisions de conception dun modle darchitecture avec un systme donn. En se basant sur les caractristiques de qualit des ADLs (extensibilit, portabilit, rutilisabilit, etc.), les dcisions architecturales permettent de slectionner un modle darchitecture adquat qui reprsente mieux nos besoins darchitecture logicielle. Cette prise en compte passe par lintgration des facteurs dimpacts des dcisions l'tape de conception et non pas au cours du processus de transformation. De ce point de vue, nous ne pouvons pas dcrire les systmes de logiciel avec un ADL arbitraire, mais nous devons expliciter les raisons de slectionner ce dernier parmi autres. Ensuite, nous considrons les mtriques de choix des plateformes MDA (comme
119
la prise en compte de lintgration facile des concepts d'architecture logicielle) avant la phase dimplmentation. Les dcisions de conception architecturale permettent de dterminer quels sont les modles darchitectures logicielles pour chaque aspect architectural (structurel et comportemental) pour mieux dcrire une architecture logicielle d'un point de vue conceptuel et indpendamment des contraintes technologiques. Aprs quelques dcisions sur les architectures, tous les composants de description des systmes de logiciel peuvent tre implments sur plusieurs plateformes dexcution en fonction de nos besoins spcifiques, et des technologies disponibles, etc. (Alti, Smeda, 2008). 4.4.4.2 Amliorer le processus de dveloppement en utilisant MDD centr dcision Pour illustrer notre approche centre dcision, nous l'appliquons au systme Client/Serveur. La table 4.8 prsente un exemple de comparaison entre CORBA et EJB afin de slectionner la meilleure plate-forme dimplmentation pour le modle COSA. Les plateformes CORBA et EJB se basent sur diffrents concepts dimplmentations.
Architecture au niveau PIM
Modle dArchitecture avec COSA
Modle dArchitecture avec -ADL
PIM vers PSM

Architecture au niveau PSM Modle de Component avec le profil UML 2.0 COSA
PSM vers PSM Modle dimplmentation avec le profil CORBA
PIM vers PSM

Modle de Component avec le profil UML 2.0 -ADL PSM vers PSM
Modle dimplmentation avec le profil CORBA
PSM vers PSM

Modle dimplmentation avec le profil EJB
PSM vers PSM

Modle dimplmentation avec le profil EJB
Figure 4.8 MDD centr sur la dcision architecturale (vue structurelle). Dcision : Nous avons choisi le standard international CORBA qui simplifie le dveloppement par rapport aux autres plates-formes, qui masque l'htrognit par le biais du langage IDL (Interface Defintion Language) et qui facilite la communication entre des composants distribus via le bus ORB (Object Request Broker).
Dcisions Architecturales
CHAPITRE 3 COSA : Une approche hybride de description darchitecture logicielle Critres Rgles de transformation Contraintes dimplmentation Consquences La plateforme CORBA Nous devons dfinir les rgles de transformation de COSA vers CORBA. Le modle CORBA doit tre valid par le profil CORBA Le systme client / serveur dpend du profil CORBA - Rsolution des problmes d'interactions entre les composants CORBA par la projection des connecteurs COSA. - Simplicit de dveloppement. - Intgration facile des concepts COSA.
120
La plateforme EJB Nous devons dfinir les rgles de transformation de COSA vers EJB. Le modle EJB doit tre valid par le profil EJB. Le systme client / serveur dpend du profil EJB - Rsolution des problmes d'interactions des composants EJB par la projection des connecteurs COSA. - Niveau dabstraction haut celle de COSA.
Avantages
Inconvnients
La prise en charge dun nombre relativement faible des concepts dimplmentation.
Difficile de projeter des concepts darchitecture.
Table 4.9 CORBA vs. EJB.
4.4.5 Synthse
Nous avons prsent la prise en compte des concepts darchitecture logicielle COSA au sein de MDA. Cette prise en compte passe par lutilisation de profil UML. Les profils UML reprsentent tous les concepts de modle darchitecture logicielle COSA et les modles des plates-formes MDA dans le mtamodle UML. Ils facilitent llaboration des correspondances, lautomatisation des rgles de transformations et la gnration des modles instances des plates-formes MDA. Nous avons prsent brivement la transformation COSA vers CORBA. Cette transformation est une transformation PSM vers PSM. Elle permet une transformation COSA profil UML (PSM) vers CORBA profil UML (PSM). Notre objectif est uniquement de dmontrer la faisabilit de lapproche de transformation des profils.
4.5 Conclusion
COSA est un ADL hybride qui englobe les concepts communment admis par la majorit des langages de description d'architectures logicielles. Un nouveau profil UML ddi larchitecture logicielle COSA et une stratgie de projection directe des
121
concepts architecturaux COSA vers ceux des concepts dUML 2.0 laide ce profil est bien explicit. On peut conclure que les possibilits offertes par le profil UML, permet de dfinir une spcification complte et structure de larchitecture logicielle COSA en UML 2.0 et permet de mieux capturer, plus prcisment les concepts de larchitecture COSA en UML 2.0 (strotypes, valeurs marques et contraintes OCL). Lintgration de larchitecture logicielle COSA au sein de la dmarche MDA par lutilisation du profil UML offre aux plates-formes MDA un niveau dabstraction lev quivalent celui de COSA et limine les problmes dhtrognits. Crce aux profils, il est possible dappliquer lapproche MDA des modles labors sous forme de composants UML 2.0, afin de gnrer des modles spcifiques pour les plates-formes dexcution. Ils reprsentent tous les concepts de modle darchitecture logicielle
COSA et les modles des plates-formes MDA dans le mtamodle UML. Ils facilitent llaboration des correspondances, lautomatisation des rgles de transformation et la gnration automatique des modles dinstance des plates-formes dimplmentation. Tant qu la ralisation des transformations, COSA vers UML 2.0, COSA vers eCore et COSA vers CORBA, elle fera objet dans le chapitre qui suit.
CHAPITRE 5 Ralisation et Exprimentations
122
Chapitre 5 : Ralisations et exprimentations
5.1 Introduction
COSA est un ADL qui volue avec des objectifs acadmiques plutt quavec des objectifs industriels. Un ADL nest utile que si nous fournissons des outils de support. Une validation pratique de COSA peut tre effectue grce une implmentation objet. Pour ce faire, nous avons opt pour une approche de type profil UML pour bnficier des outils de modlisation UML et pour gnrer rapidement des outils graphiques pour larchitecture logicielle COSA. Elle permet ainsi de comprendre et contrler les interactions et les interconnexions entre composants. Lobjectif est la projection rapide et une meilleure intgration des concepts dADLs dans les platesformes dexcution pour accomplir un niveau d'abstraction plus lev. Dans ce
chapitre, nous exposons notre mise en uvre de MDA sur lintgration de larchitecture logicielle COSA avec lexploration de trois outils de transformations : COSAPlugin (Alti, Khammaci, Smeda, 2007a) : fournit un profil UML 2.0 pour COSA qui contient un ensemble de strotypes avec toutes ses valeurs marques et contraintes OCL 2.0 ncessaire la validation pratique de la projection COSA vers UML 2.0. COSABuilder & COSAInstantiator (Maillard & al. 2007, Alti & al. 2010) : loutil COSABuilder vise permettre aux architectes de dcrire graphiquement leurs architectures avec MOF et de valider automatiquement ses smantiques structurelles selon lapproche COSA. Laspect cl de loutil COSAInstantiator est la possibilit de gnrer automatiquement un diteur graphique pour un modle darchitecture COSA et de crer des architectures dapplications correctes. COSA2CORBAPlugin (Alti, Khammaci, Smeda, 2007b): est un outil de transformation des architectures COSA vers CORBA qui offre une simplicit de transformation des
123
modles darchitectures UML 2.0, profil COSA vers la plate-forme standard CORBA. Plus prcisment, lautomatisation de la production des modles UML des applications CORBA et la gnration de code. Nous explicitons pour cela les mises en uvre des transformations avec ses rsultats pour une application trs rpandue dans la communaut des architectures logicielles: un systme de type Client-Serveur. Nous allons dabord dcrire chacun des outils, pour les appliquer au systme Client-Serveur. Nous terminons cette tude, par une comparaison des deux transformations (COSA-UML, COSA-CORBA) suivant les critres de niveau de description, de sparation des aspects de conception et dimplmentation, de raffinement, de degr de lisibilit et de type de transformation.
5.2 Mise en uvre de lintgration de COSA au sein de MDA

Pour rpondre aux problmatiques de complexit, dvolutivit et dhtrognit des plateformes excutables objets, il semble ncessaire aujourdhui de recourir des
stratgies relativement nouvelles, fondes sur des techniques de nature gnratives organises autour de nombreux profils sappuyant sur les mtamodles standards UML. Pour illustrer lintgration de larchitecture logicielle COSA au sein de MDA laide du profil COSA UML (Alti, Khammaci, Smeda, Bennouar, 2007) et souligner les avantages concrets quelle apporte, nous allons dtailler les diffrents modles darchitectures et transformations de modles de larchitecture vers limplmentation ncessaire lintgration du modle COSA selon les principes MDA. Conformment lapproche MDA, le modle COSA reprsente le modle PIM. Ce PIM perd tous ses atouts ds quil est projet au niveau dimplmentation dans la mesure o il ne permet que la description dun systme informatique de manire abstraite. Comme le passage du langage UML2.0 vers des plates-formes objets est naturel, une solution est de raliser une transformation des concepts de COSA vers les concepts dUML2.0. Lintrt de cette solution est de permettre la projection de larchitecture abstraite COSA (PIM) vers une architecture concrte UML 2.0 (PSM) et de pouvoir utiliser tous les outils UML. Nous avons slectionn la plate-forme CORBA et la technologie eCore/MOF. Le fait davoir un langage de modlisation standard UML, une technologie standard
124
eCore/MOF et la plate-forme dexcution standard CORBA nous permet de mettre en lumire les solutions quoffre MDA pour rsoudre les problmes dambiguts, dinteroprabilit et de sparation des proccupations des aspects darchitecture, des aspects dimplmentation et des aspects dapplication. La figure 5.1 illustre les
diffrentes tapes ralises pour lintgration de larchitecture COSA au sein de MDA. La transformation COSA vers UML 2.0 (PIM vers PSM), la transformation COSA vers eCore (PSM vers PSM) et la transformation COSA vers CORBA (PSM vers PSM). Le travail reste ouvert vers dautres plates-formes : EJB (Alti, 2008) et .Net. Les outils de larchitecture logicielle COSA contribuent intgrer facilement les
concepts darchitectures logicielles (connecteurs, configuration, glu, rlesetc.) au sein des plates-formes MDA et amliorer plusieurs mtamodles standards et gnriques comme UML et MOF, visant promouvoir lapproche profil UML et apporte ainsi des solutions pragmatiques voques plus haut.
ARCHITECTURE
PIM en COSA
PSM en eCore/MOF
PSM en COSA UML
IMPLEMENTATION
PSM EJB
PSM NET PSM CORBA
Public class { }
Interface { }
Service { }
Figure 5.1 Intgration dans MDA de larchitecture logicielle COSA.
125
5.2.1 Transformation COSA (PIM) en UML 2.0 (PSM)

Nous avons ralis une projection directe de COSA vers UML par lintermdiaire du profil UML COSA. 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 architectures logicielles se trouvent dans lADL COSA (voir le chapitre prcdent). Le profil UML 2.0 pour COSA est crit en Java a t implment dans la plateforme de dveloppement logiciel dIBM Rational Software Modeler pour Eclipse 3.1. Rational Software Modeler est un environnement de modlisation et de gnration de code permettant le dveloppement dapplications et la cration doutils guids par les modles. Nous avons ralis le profil UML 2.0 pour COSA en utilisant le mcanisme de cration du profil RSM (Rational Software Modeler). Rappelons que ce profil contient les strotypes et les valeurs marques : cible, mode-connexion, type-service ncessaires la gnration des modles UML. Afin de profiter des avantages des outils graphiques dvelopps autour dUML, la plupart des concepts architecturaux sont disponibles dans le composant COSAPlugin (ex. connecteurs de construction tels que Attachement, Extends, Binding et Utilisation, connecteurs dfinis par l'utilisateur, des structures telle que la configuration des composants et des connecteurs) (Alti, Khammaci, Smeda, 2007a ; Smeda, Alti, Boukerram, Oussalah, 2009). COSAPlugin a t dvelopp selon trois niveaux (mtamodle, modle, application). Dans le niveau haut, le mtamodle COSA avec toutes les valeurs tiquetes et ses contraintes OCL 2.0, est dfini par le profil UML 2.0. Ce profil joue un rle important dans le second niveau quand il est utilis par le modle d'architecture logicielle. Une fois que nous nous assurons que le modle donn est conforme aux contraintes smantiques dfinies par le profil, un ensemble d'instances pour les types sont dfinis et valus dans ce niveau. L'objectif principal COSAPlugin est de montrer la capacit d'appliquer le profil pour des applications complexes. Le plugin offre aux architectes la possibilit de vrifier la cohrence structurelle d'un systme donn et de valider sa smantique avec l'approche COSA. La figure 5.2 prsente un aperu de loutil COSAPlugin.
126
Loutil COSAPlugin inclut les contraintes OCL 2.0, ncessaires la dfinition de la transformation COSA vers UML 2.0 et le profil COSA qui contient un ensemble de strotypes avec toutes ses valeurs marques ncessaires la spcification des correspondances. COSAPlugin offre les fonctionnalits suivantes: Performance de vrification des modles darchitecture UML, profil COSA. Simplicit de cration et rapidit de modification dune architecture logicielle par la cration du modle UML 2.0 (diagramme de composants) et ensuite, ajout des contraintes OCL, ncessaires au modle, aprs que, le modle soit valu par le profil. Validation smantique et vrification de la cohrence structurelle des modles darchitecture UML 2.0, profil COSA contre les violations des contraintes du profil. Capacit aux architectes de construire facilement des modles darchitecture UML 2.0 avec lapproche COSA. Habilit aux concepteurs de rutiliser et de partager les mmes concepts architecturaux, durant tout le cycle de vie du systme.
Profil COSA Contraintes OCL 2.0
Figure 5.2 COSAPlugin sous Eclipse 3.1
127
5.2.2 Transformation COSA-UML (PSM) en eCore (PSM)

Le mtamodle COSA fournit un niveau dabstraction haut qui permet de spcifier, danalyser et de manipuler des architectures logicielles. En plus, lapproche de lingnierie de modle (Frankel, 2003 ; Bzivin, 2005) facilite lautomatisation des modles. Donc, on a besoin dune stratgie qui permet de gnrer rapidement des outils graphiques pour la manipulation et la dfinition des concepts COSA. Plusieurs approches ont t proposes. La plupart des approches permettent le dveloppement manuel des environnements de modlisation et des interfaces graphiques, GEF (Graphical Editing Framework) (GMF, 2006). Le dveloppement manuel des environnements pour les modles darchitectures nest pas feusable. Par consquent, il est devient ncessaire dautomatiser le dveloppement de ces environnements. COSA dfinit des abstractions darchitectures, mais il lui reste supporter la distinction entre un modle darchitecture (Niveau A1) et son application (Niveau A0). Puisque notre objectif est de crer rapidement un outil dimplmentation de mtamodle COSA, nous avons opt pour lapproche profil UML . Le but est donc est dlaborer un mtamodle eCore correspondant parfaitement au mtamodle COSA laide du profil UML, qui va tre gnr par la transformation COSA-UML vers eCore. 5.2.2.1 Pourquoi choisir eCore pour la transformation ? EMF (Eclipse Modeling Framework) est un Framework Open Source qui permet de dfinir des mtamodles (i.e. UML) et de gnrer, des interfaces ddies ces mtamodles, un diteur graphique et un ensemble de classes permettant de raliser des applications partir d'un mtamodle. Le cur du framework EMF inclue un mtamta-modle (eCore). Depuis sa cration, eCore na cess daccrotre son influence dans le monde industriel. Les principaux concepts deCore sont prsents dans la Figure 5.3. Nous avons choisi eCore, puisque cest un MOF, conu pour tre comme lOMG MOF. Nous pouvons rcapituler les raisons qui nous ont fait choisir eCore dans les points suivants :
128
Figure 5.3 Diagramme de classe de mta-mta-modle eCore.

-
MOF est un modle standard bien dfini et bas sur le mta-mta-modle MOF. eCore est limplmentation de MOF.
eCore est largement utilis dans le monde industriel. eCore est apprci dans le dveloppement et la manipulation des modles (tels que MDA, transformation des modles, profils, etc.).
eCore est support par plusieurs outils qui offrent diverses facilits, notamment la gnration des API et des diteurs graphiques.
Comme eCore est limplmentation de MOF, il nest pas aussi riche quUML. Le profil UML pour COSA inclus des lments architecturaux qui ne sont pas explicitement dfinis dans eCore (composants, connecteurs, configurations, rles, glu). Cela permet de rpondre aux lacunes du modle technologique (eCore) au regard des langages de description darchitectures (ex. COSA) : 1) - absence des mta-entits reprsentant les architectures, les composants et les connecteurs, 2) - absence des relations explicites entre une architecture et son type, entre un connecteur et son type, entre un composant et son type, 3)- le profil UML pour COSA a plusieurs contraintes, il peut tre appliqu aux lments architecturaux COSA, eCore ne supporte pas directement ces contraintes.
129
5.2.2.2 Implmentation de la transformation COSA vers eCore Nous avons utilis la passerelle profil COSA UML qui jouera le rle de pivot (Alti, Khammaci, Smeda, Bennouar, 2007) pour laborer rapidement des outils graphiques pour lADL COSA. Le premier concerne un outil de modlisation graphique COSA pour lequel le modle darchitecture COSA est labor et le deuxime concerne un outil dinstanciation COSA dans lequel le modle darchitecture est instanci. Nous insistons sur la sparation des proccupations de l'architecture de l'application. Cela permet de les rutiliser de faon indpendante. Donc, on peut aussi rutiliser la reprsentation graphique afin de produire plusieurs modles dinstances pour diffrents modles darchitectures. Notre stratgie dimplmentation est ralise en six tapes (voir figure 5.4) : 1. Projection des lments du mtamodle COSA en eCore laide du profil UML 2. Gnration de loutil graphique COSABuilder 3. Modlisation et validation de larchitecture COSA en utilisant COSABuilder 4. Projection des lments des modles COSA dans eCore via le profil UML 5. Gnration de lditeur d'instances COSA-eCore 6. Slectionner et instancier les lments du modle darchitecture COSA.
Mtamodle COSA UML
Projection Modle Ecore Gnrateur EMF Editeur GEF
COSABuilder
Conformance Gnration
Editeur de modlisation COSA

Transformation cosa.ecore (ATL)
Modlisation
Projection
Modles de COSA
Modles JET Conformance
Modle Ecore Gnrateur EMF Editeur GEF
COSAInstantiator
Gnration
Editeur dinstances COSA Slection et instanciation
Modles dinstances COSA
Figure 5.4. Implmentation du mtamodle COSA vers eCore.
130
1. Les rgles de passage des concepts de COSA vers eCore

La transformation du modle COSA vers celui deCore doit suivre un processus progressif qui transforme la plupart des lments architecturaux abstraits en de
nouveaux lments architecturaux concrets. Nous proposons de transformer chaque concept architectural du modle COSA laide du profil UML 2.0. Le processus de projection est facilement achev par ladaptation de la transformation UML-eCore (Eclipse, 2007), pour projeter les contraintes smantiques du profil COSA UML, qui ne sont pas projetes parfaitement vers eCore. Les contraintes OCL propre au profil UML COSA sont projetes vers eCore comme des valeurs des attributs non conformes au mtamodle eCore. Pour cela, il est donc ncessaire de transformer toutes les contraintes OCL du profil COSA UML vers eCore afin de respecter les proprits smantiques propres au profil COSA-UML. Le choix est port sur les classes eCore pour la reprsentation des composants, des connecteurs et des configurations COSA, mais ces derniers restent bien distincts grce aux annotations quon leur associe. Le tableau 5.1 rsume la correspondance entre les concepts de COSA et ceux dUML 2.0 et le tableau 5.2 rsume les contraintes OCL de la transformation COSA vers eCore.
Concepts UML 2.0 Concepts eCore
COSAArchitecturalElement Classe Attribut COSAPropNonFunc Attribut COSAConstraint Contrainte COSAImplementation Classe COSAComponent Composant COSAConnector Classe COSAComponent Composant ComponentInterface Port ConnectorInterface Port COSAPort Interface COSARole Interface COSAGlu Classe dAssociation Service Opration Connector-Service Opration Attachement Connecteur dassemblage Binding Connecteur de dlgation Use Association
COSA__COSAArchitecturalElement Classe Attribut COSA__COSAPropNonFunc Attribut COSA__COSAConstraint Classe avec deux attributs : nom et corps de contrainte COSA__COSAImplementation Classe COSA__COSAComponent Classe COSA__COSAConnector Classe COSA__COSAComponent Classe COSA__ComponentInterface Classe COSA__ConnectorInterface Classe COSA__COSAPort Classe COSA__ COSARole Classe COSA__COSAGlu Classe COSA__Service Classe COSA__Connector-Service Classe COSA__Attachement Classe COSA__Binding Classe COSA__Use Classe
Table 5.1 Correspondance COSA eCore.
131 Contraintes OCL
Concepts COSA
Elment-Architectural Composant (type)
Un classe Ecore annot ArchitecturalElement ayant seulement des proprits et des contraintes COSA. Une classe Ecore annot COSAComponent hrite dun lment architectural COSA.
context eCore::EClass self.owner->oclIsKindOf(ArchitecturalElement) -- Specialized Element
Interface Composant
InterfaceComposant est dfinie seulement par COSAComponent ou COSAConfiguration.

context eCore::EClass self.owner->oclIsKindOf(component) or self.owner->oclIsKindOf(configuration) -- ComponentIntf
Port Connecteur (type)
Chaque port doit avoir un attribut numr Mode : Mode-connexion Un connecteur COSA contient un glu ou une configuration.
context eCore::EClass not(self.detail->notEmpty() and not self.glue.oclIsUndefined()) and self.detail->size() <= 1 -- detailOrGlue
Interface Connecteur Rle Glu Configuration (Type) Attachement
Interface connecteur dfinit seulement par un connecteur.

context eCore::EClass self.owner->oclIsKindOf(UserConnector) -- ConnectorInterface
Chaque rle doit avoir un attribut numr Mode : Mode-connexion Les ports dune configuration hritent dune InterfaceComposant. Un attachement relie un port requis (rle requis) avec un port fourni (rle fourni).
context eCore::EClass (self.source.oclIsKindOf(RequiredPort) and self.target.oclIsKindOf(ProvidedRole)) or (self.source.oclIsKindOf(ProvidedPort) and self.target.oclIsKindOf(RequiredRole)) or (self.source.oclIsKindOf(RequiredRole) and self.target.oclIsKindOf(ProvidedPort)) or (self.source.oclIsKindOf(ProvidedRole)and self.target.oclIsKindOf(RequiredPort) -- Attachment
Binding
Binding relie deux rles fournis (ou requis) de mme type.

context eCore::EClas (self.source.oclIsKindOf(RequiredPort) self.target.oclIsKindOf(RequiredPort)) (self.source.oclIsKindOf(ProvidedPort) self.target.oclIsKindOf(ProvidedPort)) (self.source.oclIsKindOf(RequiredRole) self.target.oclIsKindOf(RequiredRole)) (self.source.oclIsKindOf(ProvidedRole) self.target.oclIsKindOf(ProvidedRole)) - Binding and or and or and or and
Use
Use est une association entre un port/rle et un service.

context eCore::EClass -- use self.source.oclIsKindOf(Port)and self.target.oclIsKindOf(Service)) or(self.source.oclIsKindOf(Service)and self.target.oclIsKindOf(Port))
Proprit
Contrainte
Chaque proprit ayant un nom, type et valeur. Elle est applique seulement sur des composants architecturaux COSA (composant, connnecteur et configuration). Chaque contrainte ayant un nom et un corps.
Table 5.2 Les Contraintes OCL COSA vers eCore.
132
La dfinition des transformations en JAVA permettant la transformation dun modle COSA en un modle eCore ncessitent des expressions OCL (Object Management Group, 2005), gnres manuellement partir de la spcification des correspondances.
Elment architectural
Llment architectural est un concept qui dfinit tous les concepts architecturaux de COSA. Ce concept na pas de correspondant explicite dans eCore. Ainsi, le mtamodle COSA-eCore doit inclure une annotation pour le reprsenter. Il correspond la mtaclasse EClass du mtamodle eCore annot par COSA__COSAArchitecturalElement. Une classe eCore peut avoir des proprits et des contraintes et peut tre implmente par une autre classe.
Composant
Chaque composant UML strotyp COSAComponent correspond une classe eCore annote COSA__COSAComponent. Tout composant annot COSA__COSAComponent est une spcialisation de llment architectural COSA. Cette contrainte peut se dfinir dans OCL de la faon suivante :
context eCore::EClass inv :self.owner->oclIsKindOf(ArchitecturalElement)
Connecteur
Toute classe strotype COSAConnector correspond une classe eCore annote COSA__COSAConnector. Chaque classe eCore annote COSA__COSAConnector doit possde une seule glue ou une configuation mais pas les deux en mme temps. Cette contrainte peut se dfinir dans OCL de la faon suivante :
context eCore::EClass inv : not(self.detail->notEmpty() and not self.glue.oclIsUndefined()) and self.detail->size() <= 1
Configuration
Un aspect important de larchitecture COSA est celui de la configuration qui est un graphe de composants et de connecteurs. Comme un package eCore peut contenir des sous-classes, donc les configurations COSA sont projetes vers un package eCore
133
Port et rle
Chaque port annot COSA__ConnectorInterface est dfini seulement par un COSAConnector et possde un ensemble non vide de rles COSA. Une classe annote COSA__COSAProvidedPort (COSA__COSARequired-Port) est dfinie seulement par une classe
annote COSA__ComponentInterface.
Attachment
Une classe eCore annote COSA__Attachment est quivalent au concept connecteur dassemblage COSA qui est dfini entre un port et un rle COSA. Le port du connecteur COSA, de type fourni est reli avec le rle COSA, de type requis ou le port COSA de type requis, est reli avec le rle COSA de type fourni, avec la contrainte OCL suivante :
context eCore::EClass inv : (self.source.oclIsKindOf(RequiredPort) self.target.oclIsKindOf(ProvidedRole)) (self.source.oclIsKindOf(ProvidedPort) self.target.oclIsKindOf(RequiredRole)) (self.source.oclIsKindOf(RequiredRole) self.target.oclIsKindOf(ProvidedPort)) (self.source.oclIsKindOf(ProvidedRole) self.target.oclIsKindOf(RequiredPort) and or and or and or and
Binding
Binding COSA relie deux ports COSA fournis (ou requis) de deux diffrents sous composants dun mme composant COSA avec la contrainte OCL suivante :
context eCore::EClas inv :(self.source.oclIsKindOf(RequiredPort) and self.target.oclIsKindOf(RequiredPort)) or (self.source.oclIsKindOf(ProvidedPort) and self.target.oclIsKindOf(ProvidedPort)) or (self.source.oclIsKindOf(RequiredRole) and self.target.oclIsKindOf(RequiredRole)) or (self.source.oclIsKindOf(ProvidedRole) and self.target.oclIsKindOf(ProvidedRole))
Use
Un connecteur dassociation UML strotyp correspond au concept classe eCore, annote COSA__Use. Le concept classe correspond au concept de Use dans COSA. Il reprsente le rattachement physique entre un port/rle et un service. Use COSA est dfini entre un port COSA et un Service COSA ou entre un rle COSA et un ServiceConnecteur COSA avec la contrainte OCL suivante :
CHAPITRE 5 Ralisation et Exprimentations context eCore::EClass (self.source.oclIsKindOf(Port)and self.target.oclIsKindOf(Service))or (self.source.oclIsKindOf(Service)and self.target.oclIsKindOf(Port))
134
Proprits
Les proprits fonctionnelles de COSA sont quivalentes au concept dattributs eCore alors que les proprits non fonctionnelles sont reprsentes par des attributs annots COSA__COSANonFoncProp dans la mesure o elles sont diffrentes au sens smantique, puisque les attributs en eCore sont des proprits structurelles qui constituent une classe. Chaque attribut possde un type, auquel on peut donner une valeur pour linstance de llment architectural.
Contraintes
Les contraintes COSA-UML exprimes via le concept EClass de mtamodle eCore sont utilises pour documenter les contraintes de COSA. Chaque classe eCore contient deux attributs : nom de la contrainte et son corps OCL.
2. Gnration de loutil de modlisation graphique COSABuilder

Afin de profiter des avantages des outils graphiques dvelopps autour eCore et GMF (Graphic Modeling Framework) (GMF, 2006), nous avons dvelopp un outil graphique pour COSA, quon a baptis COSABuilder (Smeda, Alti, Oussalah, Boukerram, 2009 ; Alti, Boukerram, Smeda, Maillard, Oussalah, 2010). La plupart des concepts architecturaux sont disponibles dans COSABuilder (ex. connecteurs de construction tels que Attachement, Extends, Binding et Utilisation, connecteurs dfinis par l'utilisateur, des structures telle que configuration des composants et des connecteurs). Cet environnement permet aux architectes de dfinir graphiquement les modles darchitectures. La figure 5.5 prsente linterface graphique de COSABuilder.
135
Modle COSA du systme Client-Serveur
Modle graphique du systme Client-Serveur
Palette des concepts COSA
Proprits des composants
Reprsentation XML du systme Client-Serveur
Modle COSA du systme Client-Serveur
Figure FigureLesDifferent views of the sameseule architecture Client/serveur 5.5. 4: diffrentes vues dune COSA Client/Server Architecture.
136
3. Modlisation et validation des architectures avec COSABuilder

Dans cette phase, le diagramme de composants COSA dcrit un systme par des composants relis entre eux par des connecteurs dfinis par l'utilisateur ou par des connecteurs de construction. COSABuilder fournit un environnement de modlisation visuel o chaque artefact possde une reprsentation graphique. Par exemple, les composants composites et les connecteurs composites sont modliss en utilisant les configurations COSA. partir de ce modle, nous avons appliqu la validation structurelle des modles darchitecture COSA annot eCore, contre les violations des contraintes OCL dfinies par le mtamodle COSA-eCore. Les contraintes OCL dfinissent les relations entre les lments de modle COSA, par exemple le connecteur Binding relie deux ports COSA fournis (ou requis) de deux diffrents sous composants dun mme composant COSA.
4. Transformation des modles COSA profil UML vers eCore

eCore est limplmentation du MOF. Il peut tre utilis pour dfinir des mtamodles (UML par exemple). En principe eCore peut tre utilis pour dfinir un mtamodle dune architecture logicielle. Cependant, eCore souffre d'un certain nombre des lacunes relatives la description architecturale. En outre, le concept EClass peut tre utilis pour reprsenter le concept du composant. Il n'existe pas un concept explicite qui permet de reprsenter par exemple une instance dun composant ou une instance d'un connecteur. Par consquent, il n'y a pas de relation entre un composant et son type ou un connecteur et son type. En rsum, eCore na pas une relation qui puisse tre utilise pour indiquer que l'architecture est dfinie par une mta-architecture (c'est dire tous les lments architecturaux ne peuvent pas tre attribus leur type dans cette mta-architecture). L'ide dachever la projection des modles COSA en eCore, est de prendre chaque concept de mtamodle COSA et essayer de trouver son correspondant dans le mtamodle eCore. Il peut tre labor de deux manires diffrentes: manuelle, par la transformation COSA2eCore avec le langage JAVA, ou automatique, par la transformation COSA2eCore avec le langage Java et ATL (ATLAS, LINA, 2007). ATL
137
permet dexprimer les transformations des modles de manire plus simple. En effet, cest un langage ddi cette tche et qui offre deux volets: un volet dclaratif et un volet impratif. La partie imprative garantit le pouvoir de rsoudre tous les problmes en fournissant des constructions classiques (procdures, boucles, etc.) Mais, il est recommand de sen tenir autant que possible au volet dclaratif. Le principe de la transformation COSA vers eCore est bas sur la projection de chaque lment du modle COSA vers son correspond eCore. Le tableau 5.3, illustre la correspondance entre les concepts de modle COSA et ceux deCore, qui nous permettent dlaborer les rgles de transformation entre COSA et le modle eCore. La transformation peut tre tendue dautres modles cibles (par exemple, MOF 2,0). La dfinition des transformations en JAVA permettant la transformation dun modle COSA en un modle eCore, ncessite des expressions ATL (ATLAS group LINA, INRIA Nantes, 2007), bases sur la spcification de correspondances prsentes prcdemment. Les rgles de transformation en OCL 2.0 sont gnres manuellement partir de la spcification des correspondances (Voir Annexe A).
Concepts UML 2.0 Concepts eCore
Instance Composant COSAConfiguration
Package annot COSA__COSAConfiguration si une configuration principale sinon une instance dune classe annote COSA__ COSAConfiguration. instance dune classe COSAComponent instance dune COSAConnector Rfrence instance dune Required-Port instance dune Provided-Port instance dune Required-Role instance dune Provided-Role classe classe classe classe annote annote annote annote COSA__ COSA__ COSA__ COSA__ classe annote annote COSA__ COSA__
Instance Composant COSAComponent Instance Classe COSAConnector Connecteur de construction Instance dun port requis Instance dun port fourni Instance dun rle requis Instance dun rle fourni
Table 5.3 Correspondance COSA instance eCore.
138
5. Le gnrateur COSAInstantiator
En utilisant GMF, nous avons implment un outil complet dinstanciation des applications appel COSAInstantiator, qui se base sur le mtamodle instance COSA. Deux faons permettent de gnrer l'diteur graphique : 1) - partir d'un modle existant COSA-Ecore sous forme de fichier XMI ou 2) - partir d'une nouvelle architecture COSA en tant que fichier COSA-UML. Llment cl de COSAInstantiator est la capacit crer rapidement des architectures des applications et aussi introduire un support explicite pour prserver un lien de traabilit entre larchitecture de lapplication et son espace de modlisation. Plusieurs architectures peuvent tre instancies partir d'un modle d'architecture. Nous avons obtenu le modle eCore partir du modle d'architecture COSA-UML et le concept EAnnotation de mtamodle eCore, qui dcrit les informations sur le mta-type (tous les lments COSA d'une architecture peuvent tre attribus leurs types, dans la mta-architecture COSA en utilisant les annotations eCore).
Architecture de lapplication Client-Serveur
Zone dinstanciation Palette des lments du systme Client-Serveur
Figure 5.6. Modle dinterface utilisateur pour loutil COSAInstantiator.
139
La figure 5.6, prsente un aperu de l'diteur graphique de l'architecture client-serveur avec les diffrentes vues: Editeur dinstances COSA avec sa palette, la vue console, et la vue Proprits. Si l'on regarde la palette, nous allons dcouvrir que tous les lments du modle d'architecture client-serveur sont prsents, de la mme sorte que nous venions de faire glisser, l'lment appropri dans la zone qui contient le diagramme d'application client-serveur pour dcrire une application complte.
6. Elaboration des architectures des applications

Dans la dernire phase du processus d'instanciation, le dveloppeur a la possibilit de slectionner et d'instancier des lments visuels chaque fois quil en a besoin pour dcrire une application complte. Les instances sont cres partir de types d'lments qui sont obtenus par la projection de COSA vers eCore, lors de la phase prcdente.
5.2.3 Transformation COSA-UML (PSM) vers CORBA (PSM)

Parmi les apports de lintgration de COSA dans MDA, on distingue la sparation des aspects architecture des aspects implmentation, la sparation entre la spcification des correspondances et les rgles de transformation. Dans cette section, nous prsentons la transformation dun modle darchitecture COSA-UML (PSM) vers un autre modle dimplmentation CORBA (PSM). Ce modle contient tous les concepts CORBA correspondant aux concepts COSA du modle source. A partir de ce modle, nous appliquons la gnration des interfaces IDL pour obtenir un squelette des interfaces CORBA. Nous avons choisi le standard international CORBA qui simplifie le dveloppement de logiciels par rapport aux autres plates-formes. Il supporte l'htrognit et il facilite la communication et la coordination des composants distribus. Nous dtaillons la spcification des correspondances COSA-CORBA et nous dfinissons les rgles de transformation COSA-CORBA.
140
5.2.3.1 CORBA : Standard des platesformes dexcution CORBA5 dcrit des architectures et dfinit des spcifications pour le traitement dobjets distribus sur le rseau. CORBA est une plate-forme dexcution standard et internationale. Il fournit une simplicit de dveloppement par rapport aux autres plates-formes (EJB, .NET, etc.) par le biais des IDLs (Interface Definition Language). Le modle de composants CORBA est un modle multi-interface, multi-langage avec IDL (Interface Definition Language). Les composants CORBA sont interoprables avec les composants EJB. CORBA intgre aussi, des descripteurs pour la configuration, la dfinition de lassemblage et le dploiement des composants. Les lments de mtamodle CORBA (Object Management Group, 2002), sont les concepts utiliss pour spcifier des composants CORBA. Les concepts cls du type de composant sont les ports. Un composant peut avoir un ou plusieurs attributs qui reprsentent ses proprits configurables. Les ports dans CORBA fournissent ou utilisent des services de composants. Le port est principalement reprsent par des interfaces. Les interfaces de type Fourni ou Requis sont bass sur linterface IDL (Interface Description Language). Deux types dinterfaces fournis (requis) : une facette (rceptacle) pour les mcanismes de communication synchrone et puis dvnements (source dvnements) pour le mcanisme de communication asynchrone. Les facettes et les composants ont le mme cycle de vie. Chaque interface a sa propre rfrence de services. Les connections sont utilises pour lassemblage des composants. Une maison (Home) est un gestionnaire des instances de composants qui fournit des oprations de cration. Elle fournit aussi des oprations de recherche pour les composants CORBA existants. Une maison possde ses propres attributs et ses propres oprations.
CORBA est un nom dpos par lObject Management Group (OMG)
141
5.2.3.2 Pourquoi la transformation de COSA UML vers CORBA ? CORBA est une plate-forme dexcution standard offrant une simplicit de dveloppement par assemblage des composants prfabriqus, mais il ne supporte pas des niveaux d'abstraction levs comme les connecteurs et les composants composites. Etant donn que COSA supporte les composants composites et dfinit explicitement les connecteurs, comme des concepts architecturaux abstraits, il est utile de dfinir une transformation automatique de modles darchitectures vers limplmentation. L'intrt de cette transformation est la projection rapide et une meilleure intgration des concepts COSA dans la plate-forme CORBA afin daboutir un niveau d'abstraction plus lev et daider ainsi, rsoudre les problmes d'interactions entre les composants CORBA. La transformation du modle COSA vers celui de CORBA est un processus automatique qui produit des concepts CORBA, de ses correspondants COSA. Ce processus dfinit un modle UML conforme au mtamodle COSA, il produit un modle UML vers la plate-forme cible CORBA. Ce modle est valid par le profil UML pour CORBA (Object Management Group, 2004b). 5.2.3.3 Profil UML 1.4 pour CORBA Le but du profil UML 1.4 pour CORBA est le dveloppement des applications CORBA en utilisant des notations UML, pour faciliter la gnration de code des composants CORBA, et la spcification complte des concepts CORBA (Object Management Group, 2002). Ce profil est dcrit comme un package UML strotyp nomm CORBA comme illustr dans la figure 5.7. Ce package inclut une classe strotype CORBAComponent pour reprsenter un composant CORBA. Un composant CORBA peut avoir des attributs et des interfaces. Les facettes et les rceptacles sont reprsents respectivement par des associations de composition strotypes CORBAUses, CORBAProvides entre CORBAComponent et CORBAInetrface. En plus, une source dvnements, un puit dvnements et une publication dvnements sont
reprsentes respectivement par des associations de composition strotypes CORBAEmits, CORBAConsumes et CORBAPublishes entre CORBAComponent et CORBAEvent. Un Home est dcrit par une classe strotype CORBAHome. Ces strotypes sont documents en utilisant des valeurs marques et des contraintes OCL.
142
Figure 5.7 Le profil CORBA 5.2.3.4 Les rgles de passage des concepts COSA vers CORBA Nous proposons de transformer chaque concept architectural du modle COSA vers CORBA laide du profil UML 1.4 pour CORBA (Object Management Group, 2004b). Les composants COSA, sont reprsents par des composants UML 2.0. A chaque composant UML 2.0, correspond une classe UML 1.4 (la classe, porte le mme nom que le composant), le composant UML 2.0 COSAComponent peut tre transform vers une classe UML CORBAHome. Les connecteurs COSA sont reprsents par des classes UML 2.0. Les classes UML 2.0 correspondent aux classes UML 1.4. Ainsi, la classe COSAConnector est transforme vers une classe CORBAHome. Les interfaces de composants et des connecteurs correspondent aux ports UML 2.0. Les ports correspondent aux classes UML (le nom de la classe correspond au nom du port). Chaque classe reprsentant un composant ou un connecteur (composants et connecteurs CORBAHome) doit tre rattache des associations dagrgation vers les classes des ports (qui correspondent une classe CORBAComponent). Le tableau 5.4 montre la correspondance entre les concepts de COSA et ceux de CORBA, qui nous permet dlaborer les rgles de transformation entre COSA et la
143
Concepts CORBA UML 1.4
plate-forme CORBA (Alti, Khammaci, Smeda, 2007b).

Concepts COSA UML 2.0
COSAArchitecturalElement Classe COSAProp Attribut COSAConstraint Contrainte COSAImplementation Classe COSAComponent Composant COSAConnector Classe COSAConfiguration Composant ComponentInterface Port ConnectorInterface Port COSAPort Interface COSARole Interface COSAGlu Classe dAssociation Service Classe Attachement Connecteur dassemblage Binding Connecteur de dlgation Use Association
CORBAHome Classe IDL-Attribute attribut CORBAException CORBAImplementation CORBAHome Classe CORBAHome Package CORBAComponent Classe CORBAInterface synchrone CORBAEvent asynchrone IDL-Operation Opration CORBAEvent Classe CORBAComponent Classe
Table 5.4 Correspondance COSA CORBA La dfinition des transformations en JAVA et (ATL) Atlas Transformation Language (ATLAS group LINA, INRIA Nantes, 2007), permettant la transformation dun modle COSA profil UML vers CORBA profil UML doit tre base sur la spcification de correspondances dcrites prcdemment. Chaque lment de correspondance contient une expression OCL (Object Management Group, 2005), permettant deffectuer la transformation entre les lments des profils UML pour COSA et CORBA, et un filtre pour faire la distinction entre eux. Nous transformons le filtre dans un helper 'hasStereotype' exprim dans OCL, comme suit:
helper context UML2!Element def : hasStereotype(name:String): Boolean = self.eAnnotations->forAll(a|a.source='appliedStereotypes' implies (a.contents->exists(s|s.eClass().name = name)));
Les concepts de base tels que les proprits, les contraintes et les implmentations sont projetes dans dautre helpers (mthodes auxiliaires) comme suit:
helper context UML2!Class def: getCOSAProps():Sequence(UML2!Property)= self.ownedAttribute->select(e|e.hasStereotype(COSAProp)); helper context UML2!Class def:getCOSAConsts():Sequence(UML2!Constraint)= self.ownedRule->select(e|e.hasStereotype(COSAConstraints));
144
Helper context UML2!Class def: getCOSAImps():Sequence(UML2!Class) = self.clientDependency.target(e|e.hasStereotype(COSAImplementation));
Llment architectural COSA a t reprsent par une classe UML 2.0. Puisque, une classe UML 2.0 correspond une classe UML 1.4 identique, la classe UML 2.0 peut tre transforme vers une classe UML
COSAArchitecturalElement, CORBAHome.
Les composants COSA sont reprsents par des composants UML 2.0. Puisque, un composants UML 2.0, correspond une classe UML 1.4 (la classe porte le mme nom que le composant), le composant UML 2.0 COSAComponent peut tre transform vers une classe UML CORBAHome. Les connecteurs COSA dfinissent des abstractions qui englobent les mcanismes de communication, de coordination et de conversion entre les composants (Smeda, Khammaci, Oussalah, 2004a), qui ne sont pas dfinis explicitement dans la plate-forme CORBA. Donc, nous essayons de trouver les correspondances smantiques des concepts CORBA. Les connecteurs COSA sont reprsents par des classes UML 2.0. Les classes UML 2.0 correspondent aux classes UML 1.4, donc la classe COSAConnector est transforme vers une classe CORBAHome. Une glu est reprsente par une classe dassociation UML 2.0. La glu dcrit les fonctionnalits attendues reprsentes par les parties en interaction. Elle nest pas dfinie explicitement dans la plate-forme CORBA. Donc, nous essayons de trouver les correspondances smantiques des concepts CORBA. Puisque les classes communiquent par lenvoi de messages (opration au sens UML), la classe dassociation strotype GluCOSA est transforme par une opration UML. Les configurations sont des graphes de composants et de connecteurs. Elles ne sont pas dfinies explicitement dans la plate-forme CORBA. Donc, nous allons essayer de trouver les correspondances smantiques des concepts CORBA. Les composants COSA sont reprsents par des composants UML 2.0. Les composants UML 2.0 correspondent aux classes UML 1.4, donc le composant COSAConfiguration transform vers une classe CORBAModule.
145
Les interfaces de composants et des connecteurs correspondent aux ports UML 2.0. Les ports corresponds aux classes UML (le nom de la classe correspond au nom du port). Cette classe ralise les interfaces fournies du port. Cette classe dpend des interfaces requises par le port. Si, une classe UML, qui reprsente un composant UML 2.0, doit tre relie dautre classes, qui reprsentant des ports, alors chaque classe qui (composants et connecteurs
reprsentant un composant ou un connecteur
CORBAHome) doit tre rattache des associations dagrgation vers les classes des ports (qui correspond une classe CORBAComponent). Lannexe B.1 prsente les rgles de transformation en ATL (ATLAS group LINA, INRIA Nantes, 2007), selon la description du profil UML 2.0 pour COSA et le profil UML 1.4 pour CORBA. 5.2.3.5 Implmentation La transformation COSA vers CORBA a t implmente en Java et ATL sur la plateforme de dveloppement logiciel Eclipse. Le plugin est dvelopp en quatre tapes : 1. le mtamodle COSA (CORBA) avec tous ses tagged-values et ses contraintes OCL a t dfini par le profil UML 2.0 (UML 1.4), export vers COSA.XML (CORBA.XML). 2. la transformation COSA-CORBA est labore. Cette transformation parcourt le modle UML 2.0 source et recherche les lments strotyps selon le profil COSA. Pour chaque lment identifi du modle source, la transformation construit les lments correspondant dans le modle CORBA cible. 3. Le modle COSA est dfini par un diagramme de composant UML 2.0, complt par tous les strotypes et tagged-values ncessaires au modle de composants puis valu par son profil. 4. La transformation COSA vers CORBA configure et excute. Le modle CORBA est valu par son profil. Eclipse fournit un langage de dfinition des transformations des modles ATL (ATLAS group LINA, INRIA Nantes, 2007). Pour la dfinition de la transformation COSACORBA, nous avons utilis le langage ATL. La figure 5.8 prsente les mtamodles gauche qui sont COSA et CORBA, les rgles de transformation sont droite.
146
Les rgles de transformation COSA-CORBA
Profil CORBA UML
Profil COSA UML
Figure 5.8 Transformation COSA CORBA.
5.3 Etude de cas : Systme Client-Serveur

Dans cette section, nous prsentons un exemple pour illustrer lintgration de larchitecture logicielle COSA au sein de MDA de notre stratgie de transformation. Nous avons choisi une application trs rpandue dans la communaut des architectures logicielles : un exemple de type Client-Serveur. Enfin, nous comparons les transformations COSA eCore et COSA CORBA.
5.3.1 Prsentation du systme Client-Serveur

Le systme Client-Serveur est trs rpandu dans la communaut darchitecture logicielle. Il est trait explicitement par la plupart des ADLs. Il dcrit un systme avec deux composants (Client et Serveur) qui communiquent par lintermdiaire dun connecteur. Le composant Client possde un port requis (request) et un service requis
147
(Demand-data) et il a deux proprits non fonctionnelles (data-type et request-rate). Le composant Serveur possde un port fourni (provide) et un service fourni (Send-data). Il possde deux proprits non fonctionnelles (password-needed et data-type). Le composant Serveur est compos dune configuration et DataBase) de et de trois trois
composants (ConnectionManager,
SecurityManager
connecteurs (SQLQuery, ClearanceRequest et SecurityQuery). Pour plus de dtails sur la configuration interne, on peut se rfrer la section 3.2.2.3 du chapitre 3. Le connecteur RPC agit comme un mdiateur auquel un client peut passer une requte et un serveur envoy une rponse. Il possde un rle fourni (participateur-1) et un rle requis (participateur-2) et son type de service est Conversion (voir figure 5.9). Dans les prochaines sections, nous utilisons les outils de modlisation COSA pour reprsenter les lments suivants: Configuration client-serveur, Composant client, Composant serveur, Configuration serveur, Composant gestion de connexion, Composant gestion de scurit, Composant base de donnes, Application client-serveur.
recReq
Client
RPC
caller
ExternalSocket
callee
Serveur
Connection Manager
Model architecture A1
Client1
RPC 1
Security Manager
RPC2
DataBase
Serveu
RPC3
Client2
Application A0
Client3
Figure 5.9 Architecture/application du systme Client-Serveur.
148
5.3.2 La description du systme Client-Serveur avec COSAPlugin

5.3.2.1 Excution de la transformation COSA vers UML 2.0 Pour examiner la transformation COSA vers UML 2.0 sur le systme Client-Serveur, nous avons reprsent le PIM en COSA par un modle de composants UML 2.0 et des contraintes OCL. Ensuite, le profil COSA est appliqu travers une bote de dialogue de slection des profils, illustr dans la figure 5.10. Tous les strotypes sont disponibles, affects, et contribus avec les tagged-values. Le modle est valu pour enlever toute violation des contraintes.
Figure 5.10 Slection du profil COSA pour le systme Client-Serveur. 5.3.2.2 Validation de modle Le modle du systme Client-Serveur, est valid avec les contraintes smantiques dfinies par le profil, vu dansle chapitre prcdent. Un ensemble dinstances (ex: arch-1) sont tablies en instanciant les classes du modle et sont values. Le systme final projet est illustr dans la figure 5.11.
5.3.3 La description du systme Client-Serveur avec COSABuilder

5.3.3.1 Modlisation des architectures Pour illustrer comment les concepts et les relations de COSA peuvent tre utiliss pour dcrire un systme, nous nous appuyons sur la figure 5.12 dcrivant un systme de Client-Serveur. Nous modlisons le systme Client/serveur avec les outils de modlisation et dinstanciation COSA pour chaque type d'architecture (modle et application).
149
Larchitecture UML du systme Client/Serveur
Rsultats de Validation
Figure 5.11 Validation du systme Client-Serveur en UML 2.0 avec RSM. De nouveaux types de composants et de connecteurs peuvent tre facilement dfinis partir des lments existant sur le systme client-serveur en utilisant le mcanisme d'hritage (c.--d Connecteur dextension de COSABuilder). La figure 5.13 montre la spcialisation de connecteur RPC, selon deux rles caller2 et caller3. Le connecteur RPC-1 peut tre utilis pour connecter trois clients avec le serveur via le rle rcvReq. 5.3.3.2 Excution de la transformation de larchitecture COSA vers eCore La transformation COSA2eCore est applique au modle COSA UML (clientserver.uml) pour laborer son correspondant modle Ecore (client-server.ecore). La figure 5.14, illustre la transformation de COSA-UML vers eCore. Le modle du systme Client-Serveur valid avec les contraintes smantiques dfinies par eCore.
150
Grce cette mise en projection de COSA en eCore, nous avons gnr automatiquement le modle de composant eCore de Client-Serveur et valu de faon automatique toute la partie structurelle de lapplication Client-serveur pour larchitecture COSA-eCore en respectant les contraintes smantiques de cette architecture. Ce rsultat est intressant puisquil permet de maintenir un lien fort entre larchitecture abstraite COSA et le modle darchitecture eCore. Grce au profil UML 2.0 pour COSA, les cohrences structurelles se trouvent assures. Le modle darchitecture COSA est fortement li au modle darchitecture eCore qui reprsente mieux les concepts architecturaux de COSA. Les mcanismes dextension eCore (concept EAnnotation) du profil COSA couvrent tous les besoins de larchitecte des logiciels. 5.3.3.3 Gnration de lditeur de larchitecture client-serveur La figure 5.15, prsente un aperu de l'diteur graphique de l'architecture client-serveur selon les diffrentes vues: diteur d'instance COSA avec sa palette, la palette et la vue Proprits. Si nous regardons la "palette", nous allons dcouvrir que tous les lments du modle de l'architecture client-serveur, de la mme faon que nous avions glisser et dposer l'lment appropri dans la zone qui contient le diagramme d'application client-serveur pour dcrire une application complte. Dans la catgorie
ComponentInstance, on trouve tous les types de composants de l'architecture clientserveur. Dans la catgorie ConnectorInstance, on trouve tous les types de connecteurs dfinis par l'utilisateur de l'architecture client-serveur (par exemple : connecteur RPC), dans la catgorie ProvidedPortInstance nous trouvons tous les ports requis de l'architecture client-serveur (exemple : port externalSocket du composant serveur), dans la catgorie RequiredPortInstance, on trouve tous les ports requis de l'architecture clientserveur (exemple : port recReq du composant client) et il en est de mme pour les rles. 5.3.3.4 Exprimentation des architectures de lapplication Client-Serveur Plusieurs instances darchitecture ont t exprimentes. Une premire architecture teste est constitue d'un seul client, un seul serveur et un seul connecteur RPC. Une seconde architecture a trois clients, trois connecteurs RPC et un seul serveur. Chaque connecteur est utilis pour connecter un client au serveur (voir figure 5.15).
151
5.3.3.5 Analyse des rsultats Tous comme pour UML 2.0, grce la mise en application de lapproche profil UML et MDA, nous avons gnr automatiquement le modle eCore du systme client-serveur et son diteur graphique. Plusieurs instances darchitectures des applications de type client-serveur, ont t exprimentes. Nous constatons que tous les concepts de larchitecture logicielle COSA se retrouvent spcifis dans la transformation COSAeCore. Les concepts qui ne sont pas dfinis explicitement dans eCore (connecteur, rle, glu, configuration, etc.), sont galement spcifis. Cette transformation permet de
conserver les relations smantiques entre un composant et son type, entre un connecteur et son type et entre une configuration et son type laide des annotations eCore. Soulignons que le rsultat final obtenu est fonction de la qualit du langage de transformation des modles (ATL). Nous nous sommes restreints aux parties structurelles des architectures ; il reste encore amliorer les modles eCore pour quils supportent les parties dynamiques.
Palette doutils COSA Larchitecture Client/Serveur
Figure 5.12 Architecture Client/serveur en utilisant COSABuilder.
152
Connecteur RPC-1 tendu RPC et ajoute des nouveaux rles (caller2, caller3)
Figure 5.13. Spcialisation d'un connecteur de l'architecture client / serveur.
Cest une instance de larchitecture Client-Serveur, on peut facilement dfinie plusieurs instances darchitectures
Proprits de connecteur RPC3
Figure 5.15. Application Client-Serveur en utilisant le gnrateur COSAInstantiator.
153
Classe Serveur eCore annote COSA__Component
Classe eCore annote COSA__Configuration
Classe RPC annote COSA__Connector
Figure 5.14. Modle eCore de larchitecture Client/Serveur.
154
5.3.4 Ralisation du systme Client-Serveur avec COSA2CORBA Plugin

5.3.4.1 Excution de la transformation COSA vers UML 2.0 Afin dexaminer cette transformation, nous avons construit un modle de composants UML 2.0 du systme client-serveur, auquel nous avons ajout tous les strotypes et on a dfini ses valeurs marques par lapplication de profil UML 2.0 pour COSA. Le modle est valid par le profil UML 2.0 pour COSA. La configuration COSA vers CORBA permet de spcifier le modle source et le modle cible, (exemple :
CSSystemwithCOSA.uml2 et CSSsytemwithCORBA.ecore) et les mtamodles (Profils UML COSA et CORBA). La figure 5.16, illustre le rsultat de la transformation COSA vers CORBA pour le systme client-serveur. Nous constatons que le modle CORBA contient tous les concepts lis aux connecteurs COSA et ses configurations. Pour finir, nous avons valid automatiquement ses smantiques structurelles selon le profil CORBA. 5.3.4.2 Gnration de code partir de ce modle, nous avons appliqu la gnration de code des interfaces IDL par lapplication de la transformation de gnration de texte CORBA-IDL. Lannexe B.2 prsente un rsum de la transformation CORBA-IDL, selon la description CORBA. Nous avons gnr les squelettes de code de lapplication Client-Serveur. Ces squelettes sont complts par les codes dynamiques dans le but de terminer la ralisation de lapplication Client-Serveur dans IDL. 5.3.4.3 Analyse des rsultats Grce la mise en uvre de COSA-UML en CORBA, nous avons gnr
automatiquement les squelettes des interfaces IDL, correspondants aux composants COSA-UML de Client-Serveur. Ce rsultat montre que les principes de MDA, sont valables galement sur les langages de description darchitecture. Les concepts architecturaux COSA sont fortement lis au profil UML (PIM), et les concepts architecturaux se retrouvent dans la transformation COSA vers CORBA (PIM vers PSM). Nous avons labor nous-mme, le profil UML 1.4 pour CORBA et le profil UML
155
2.0 pour COSA ainsi que la transformation COSA-UML vers CORBA. Lapproche MDA nous a permis de gnrer une grande partie du code IDL (Voir Annexe B.3).
Excution de la transformation
Modle CORBA du systme Client-Serveur
Figure 5.16. Modle CORBA du systme Client-Serveur.
5.3.5 COSA-UML vs. COSA - CORBA

Les transformations COSA-UML, COSAeCore et COSA-CORBA, montrent quil est possible dautomatiser lintgration de larchitecture logicielle COSA au sein de MDA pour ses parties structurelles. Il reste noter les caractristiques de ces transformations : 1. La transformation COSA vers UML est indpendante du langage de programmation, par contre COSA vers CORBA est fortement lie aux implmentations CORBA. Cependant, puisque la transformation COSA vers UML projette une architecture abstraite COSA sur une autre architecture concrte UML, larchitecture, peut tre raffine dans nimporte quel langage dimplmentation. Ce nest pas le cas de la transformation COSA vers CORBA, qui est une transformation de modle darchitecture vers un autre modle dimplmentation qui dpend de CORBA.
156
2. La transformation COSA vers UML, intresse plusieurs intervenants (architectes, programmeurs, etc.), par contre COSA vers CORBA nintresse que les dveloppeurs CORBA. Pour les diffrents types dintervenants (managers, programmeurs, clients, etc.), il est prfrable davoir un ADL qui nest associ aucun langage dimplmentation. Par exemple, les managers et les clients prfrent les modles au code concret. 3. COSA vers UML est une transformation de reprsentation de larchitecture abstraite COSA vers larchitecture concrte UML, par contre COSA vers CORBA est une transformation de gnration de code de larchitecture vers limplmentation. Ceci sexplique dune part, par le fait que la transformation COSA vers UML est une transformation de reprsentation et de modlisation, dautre part, par contre la transformation COSA vers CORBA est une gnration de code. 4. Les connecteurs et les composants dans la transformation COSA vers UML sont lisiblement, trs spars par contre dans la transformation COSA vers CORBA, ils sont mlangs. Cependant, on a profit dUML et de ses capacits dexpressivit des
strotypes pour reprsenter les composants COSA et les connecteurs COSA par des classes UML, mais ils restent distincts avec le concept des strotypes profil UML. Ce nest pas le cas, de la transformation COSA vers CORBA, qui utilise le mme concept de composants CORBA pour la reprsentation des composants et des connecteurs COSA. La table 5.5, rsume cette comparaison, suivant les critres de niveau de description, de sparation des aspects, de raffinement, de degr de lisibilit et du type de transformation.
Critres Niveau de description Sparation des aspects Raffinement Lisibilit Transformation COSA vers UML Haut niveau Aucune sparation Indpendant des L.P Trs lisible Reprsentation COSA vers CORBA Bas niveau Architecture et implmentation CORBA Moins lisible Gnration de code
Table 5.5. COSA-UML vs. COSA-CORBA.
157
5.4 Etude comparative et Synthse

On compare loutil COSABuilder dvelopp dans notre travail, avec deux outils utiliss au sein des coles amricaine et europenne, qui sont ACMEStudio (ACMEStudio, 2004) et Fractal ADL (cf. le site de Fractal ADL [Fractal 2004]). ACMEStudio est bien connu dans la communaut acadmique et industrielle. COSABuilder et ACMEStudio sont deux outils de modlisation graphiques des architectures qui se basent sur les mmes concepts darchitectures. A la diffrence dACME, COSA dfinit explicitement les configurations comme une entit de premire classe. Fractal est un outil de composants dvelopp par France Tlcom R&D et lINRIA. Loutil Fractal ADL, offre des moyens de dvelopper et de grer des systmes complexes comme les systmes distribus. Les outils de COSA et Fractal sont deux outils graphiques de description architecturale qui ne se basent pas sur les mmes concepts darchitectures.
5.4.1 Comparaison avec ACMEStudio

Nous avons demand dix dveloppeurs d'utiliser ACMEStudio et dix autres dveloppeurs, d'utiliser COSABuilder. Chaque groupe a t supervis par un architecte. A la fin des expriences, soit aprs environ un mois, un questionnaire a t soumis tous les dveloppeurs de chaque groupe. L'annexe C.1, rsume les rponses du questionnaire. Pour savoir si la diffrence est significative entre les deux outils, nous avons utilis des chantillons t-test (t architecte-test). Aprs avoir utilis le logiciel R (R-software, 2008) qui est un logiciel de dveloppement de calcul de statistiques et graphiques, nous avons obtenu les rsultats suivants avec 95% de similitude et avec un niveau significatif ( = 0,05); N Moyenne de 1er groupe Moyenne de 2me groupe Tscore Degr de libert P-value 20 7.75 9,25 -3.048 19 0.005
Table 5.6 Rsultats de comparaison entre COSABuilder et ACMEStudio.
158
N: Taille de lchantillon Moyenne1 : La moyenne de 1er groupe (ACMEStudio). Moyenne 2 : La moyenne 2me groupe (COSABuilder). Tscore : Paramtre de corrlation entre COSABuilder et ACMEStudio. P-Value: La significativit de la diffrence entre COSABuilder et ACMEStudio. A partir de la table 5.6, t0.975 = cette diffrence est significative. Afin dvaluer l'efficacit de notre outil, le questionnaire a t conu pour avoir une rponse une srie de cinq questions principales: Est-ce que COSABuilder / COSAInstantiator sont faciles utiliser? Est-ce que COSABuilder/COSAInstantiator contribuent acqurir des
1,093, alors tscore p t0.975 (-3,084 p -1,093),
comptences professionnelles ? Y a t-il des problmes face l'outil COSABuilder ? Est-ce que COSABuilder/COSAInstantiator supporte la rutilisabilit/lusabilit? Est-ce quon peut utiliser l'outil dans des projets du monde rel? Est-ce que COSABuilder est facile utiliser? Le but de cette partie est d'tudier les perceptions des architectes concernant la facilit d'utilisation de notre outil par rapport ACMEStudio. Cette partie est couverte dans le questionnaire, par les questions suivantes: Q1 : Est-ce que loutil une bonne interface graphique ? Q5 : Est-ce que loutil facilite la description des architectures logicielles complexes ? Q6 : Est-ce que loutil dispose d'une bonne interoprabilit ? Q8: Est-ce quil est facile de vrifier le modle darchitecture tout moment ? L'annexe C.1 prsente les statistiques des architectes pour ces quatre questions. La plupart des architectes (environ 90%) ont prfr COSABuilder/COSAInstantiator et lont qualifi aussi facile utiliser, comparativement 60% des architectes de loutil ACMEStudio. Concernant la nature des projets traits, 80% des architectes de l'outil COSABuilder estiment que cet outil a aid faire face des architectures complexes, respectivement 70% pour ACMEStudio. En outre, tous les architectes ont apprci l'outil COSA et qualifi aussi une bonne interoprabilit, respectivement 60% pour
159
ACMEStudio. Tous les architectes de l'outil de COSA et ACMEStudio considrer ces outils comme faciles utiliser. Le rsultat de cette partie montre que 90% des architectes prfrent
COSABuilder/COSAInstantiator qualifie de facile utiliser. En comparaison avec ACMEStudio, COSABuilder a une meilleure interface graphique et offre une bonne interoprabilit. L'valuation a indiqu que les outils COSA sont beaucoup plus efficaces en termes de cot et de difficult construire des modles d'architectures. Est-ce que COSABuilder contribu acqurir des comptences professionnelles? Le but de cette partie est d'valuer le gain de comptences des architectes la suite de l'utilisation de cet outil. Cette partie est couverte dans le questionnaire par les questions suivantes: Q2: Est-ce que l'outil est utile pour acqurir des comptences professionnelles ? Q3: Est-ce que l'outil est utile d'apprendre des choses ? Q12: Est-ce que tous les concepts darchitecture sont disponibles dans l'outil ? Q15: Est-ce que l'outil m'a donn une chance de faire quelque chose d'utile pour ma communaut ? Q16: Est-ce que l'outil ma aid dfinir des contraintes sur les lments d'architecture ? L'annexe C.1 prsente les perceptions des architectes pour ces cinq questions. Les rsultats montrent que tous les architectes ont acquis un nombre de comptences professionnelles la suite de l'utilisation de l'outil COSABuilder et ACMEStudio. En outre, 90% des architectes de l'outil COSABuilder ont acquis des connaissances nouvelles (comme la dfrence entre un connecteur dfini par l'utilisateur et un connecteur de construction), comparativement 70% des architectes de lACMEStudio. Seulement 10% des architectes qui utilisent COSA ne sont pas d'accord par rapport 30% qui utilisent ACMEStudio. La plupart des architectes, 90%, montre que la majorit des concepts de modlisation sont disponibles dans COSABuilder comparativement 80% pour ACMEStudio. Tous les architectes ont montr que les deux outils permettent de vrifier leurs modles de dfinir des contraintes de leurs lments d'architecture et ont donn la dfinition des contraintes pour les lments de l'architecture.
160
Les rsultats de cette partie, montrent que les utilisateurs ont acquis des connaissances nouvelles ; la plupart des concepts de modlisation sont disponibles dans COSABuilder comme par exemple les connecteurs de construction, lattachement, lExtend, le Binding et lUse, les connecteurs dfinis par l'utilisateur et les structures comme des configurations de composants et de connecteurs). Ya-t-il des problmes, face aux outils de COSA? Le but de cette partie est de dterminer les principaux problmes que les architectes ont pu rencontrs lors de l'utilisation des outils COSA. Cette partie est couverte dans le questionnaire par les questions suivantes: Q7: La priode de temps alloue ne suffit pas pour complter la conception? Q11: Est-ce quon peut appliquer une mthode de vrification formelle lors de la conception ? Q14: Est-ce que loutil m'a donn la chance de travailler sur un projet rel ? Q17: Avez-vous d'autres recommandations qui pourraient tre utiles pour amliorer l'outil ? L'annexe C.1, prsente les perceptions des architectes pour ces cinq questions. Nous pouvons conclure que le problme est la priode de temps alloue aux projets. 30% des architectes qui ont utilis l'outil COSA, estiment que la priode n'tait pas suffisante, alors que 10% des architectes pensaient que le temps peut tre l'un des problmes, mais sans en tre certains, et 60% des architectes ont estim que le temps allou est insuffisant pour terminer un projet. Un autre problme, est la capacit crer et grer des architectures professionnelles. 60% des architectes pensent qu'ils peuvent utiliser l'outil COSA sur des projets rels par rapport 50% accorde aux ACMEStudio. 30% des architectes de l'outil COSA n'taient pas srs. Les outils COSABuilder et ACMEStudio, peuvent facilement appliquer un processus de vrification formelle, lors de la conception (tous les architectes taient convaincus). Les rsultats de cette partie soulvent un autre challenge aux concepteurs de gnie logiciel : matrise des concepts architecturaux et techniques de vrification formelle dans le COSABuilder/COSAInstantiator. ACMEStudio, manque de documentation
161
relle par rapport aux outils de COSA. Toutefois, les outils COSA, manquent de gnration automatique de parties comportementales de limplmentation du systme.
La rutilisation/ lusabilit de loutil COSABuilder ? Le but de cette partie est de dterminer si l'outil COSABuilder prend en compte la rutilisabilit, la facilit d'utilisation. Cette partie, est couverte dans le questionnaire mis en place: Q4: loutil prend-il de la rutilisation ? Q9: loutil est il facile utiliser ? Q13: le modle d'architecture, peut-il tre instanci tout moment ? L'annexe C.1 prsente les perceptions des architectes pour ces trois questions. Cette partie montre les opinions des architectes sur la facilit d'utilisation et sur la rutilisation de l'outil COSABuilder par rapport ACMEStudio. La plupart des architectes de l'outil COSA, soit environ 90%, montrent que l'outil ayant une rutilisation forte est bien COSABuilder qui intgre les mcanismes dinstanciation, dhritage et de composition, comparativement aux 70% des architectes
dACMEStudio. Pour l'instanciation automatique, tous les architectes qui utilisent l'outil COSABuilder estiment que, les architectures sont instanciables tout moment, comparativement aux 50% qui utilisent l'outil ACMEStudio. 80% des utilisateurs soulignent la facilit d'utilisation de l'outil COSA par rapport 50% des utilisateurs ACMEStudio. 40% des architectes de cet outil nont pas davis arrt. Les rsultats de cette partie montrent que le degr de rutilisation de l'outil Pour
COSABuilder/COSAInstantiator est fort par rapport loutil ACMEStudio.
dcrire diffrentes architectures, nous pouvons instancier le modle d'architecture tout moment. Pouvez-vous utiliser l'outil dans des projets du monde rel? Il sagit de dterminer si l'outil COSABuilder permet de dcrire des projets du monde rel. Les rponses aux questions suivantes sont les cls de cette problmatique: Q14: Est-ce que loutil m'a donn une chance de faire quelque chose d'utile pour ma communaut ?
162
Q15: Est-ce que loutil m'a donn la chance de travailler sur un projet rel ? Pour les services rendus par l'outil COSABuilder dans la communaut, 50% des architectes estiment que l'outil COSABuilder leur donnent une chance d'appliquer leurs connaissances pour servir leur communaut, alors que 40%, sont ports sur
ACMEStudio. 40% des architectes, pensent que l'outil de COSA peut leur donner une telle chance, sans en tre srs. On relve que seuls 10% des architectes ne sont pas d'accord avec les services quoffrent COSABuilder. Pour la nature du projet que les architectes ont dvelopp, 60% dentre eux estiment que l'outil COSABuilder, leur fourni une chance de travailler sur des projets rels. Alors que 50% des architectes pensent plutt ACMEStudio. 30% des architectes, ne sont pas srs de lapport de l'outil COSABuilder. Ces rsultats montrent bien que l'outil COSABuilder, apporte une aide aux architectes rduire les espaces entre l'industrie et la communaut acadmique dans le domaine de l'architecture logicielle. COSABuilder fournit un moyen facile pour dcrire des architectures logicielles complexes avec un diteur visuel, dutilisation aise la cration des diagrammes. Cet outil (COSABuilder) a convaincu les architectes pour son application dans les projets du monde rel, et dans le futur. Ainsi, on peut conclure que COSABuilder/COSAInstantiator est privilgi : choix fond par sa facilit d'utilisation, son efficacit et la satisfaction des prfrences, quil offre. titre d'observation gnrale sur les rsultats des groupes exprimentaux, on peut relve que: 90% des utilisateurs, ont une prfrence COSABuilder/COSAInstantiator : utilisation facile. Acquisition de nouvelles connaissances : exemple des connecteurs des utilisateurs et de construction. Rutilisation du mme modle darchitecture plusieurs fois avec les mcanismes oprationnels de COSA: hritage, composition, tracibilit, raffinement et instanciation. Instanciation des modles d'architectures tout instant. COSABuilder standard des concepts de modlisation des architectures logicielles : Connecteurs de Construction (Attachement, Extend, Use et Binding), dfinis par l'utilisateur, Configuration des composants et des connecteurs. Connecteurs
163
- Dploiement automatique dune architecture donne de plusieurs manires.
En rsum, dans la description dun domaine gnrique, il est prfrable dutiliser les outils de COSA. Par contre, pour des domaines spcifiques, il est prfrable dutiliser loutil ACMEStudio. La table 5.7 met en relief, cette comparaison, qui est effectue selon la disponibilit des concepts architecturaux, la rutilisation, la sparation des aspects, linstanciation et le raffinement.
Critres Concepts architecturaux Rutilisation Sparation des aspects Instanciation Raffinement COSABuilder/COSAInstantiator Standard des ADLs Fort Architecture et dploiement sont explicitement spars. Composants, Connecteurs, Configurations. Langage de transformation ATL ACMEStudio (-) Configuration, Extend, Use Moyen Architecture et dploiement sont mlangs. Composants, Connecteurs Patrons de transformation
Table 5.7. COSABuilder/COSAInstantiator vs. ACMEStudio
5.4.2 Comparaison avec FractalGUI

Notre choix sest port sur FractalGUI, systme Client-Serveur, implment selon loutil Fractal ADL, dcrit dans Fractal ADL [FractalGUI 2005], pour qui nous proposons une tude comparative avec loutil dvelopp, savoir COSABuilder. Tout dabord, pour une comparaison efficace, notons quelques caractristiques de FractalGUI : Loutil FractalGUI, est simple de dveloppement par lassemblage des composants. Ce qui fait, il offre une bonne sparation entre les aspects architecture et dploiement, dans la description de leurs systmes. Lassemblage des composants est dfinis via les fichiers XML, et donc, il est difficile de garantir la rutilisation des composants. En utilisant les outils COSABuilder/COSAInstantiator, on peut dployer automatiquement une architecture donne de plusieurs manires, sans rcrire le programme de configuration/dploiement. Ils fournissent une bonne sparation de l'application de l'architecture qui rend ces proccupations rutilisables. Les outils des ADLs (Fractal et COSA) fournissent des outils graphiques qui peuvent tre utiliss pour visualiser, dfinir ou modifier graphiquement et interactivement des architectures. A la diffrence de Fractal, COSABuilder, runie les concepts communment admis par la majorit des langages de description
164
d'architectures logicielles : Connecteurs de construction (Attachement, Extend, Use et Binding), Connecteurs dfinis par les utilisateurs, Configurations des composants et des connecteurs. Le concept de configuration nexiste pas dans loutil FractalGUI, puisque FractalGUI dcrit les architectures comme des composants composites. Dans COSABuilder, la dfinition des configurations comme des classes instanciables permet la construction de diffrentes architectures du mme systme. Loutil FractalGUI se limite une dfinition implicite des connecteurs en ne considrant que les composants et leurs structures ; ce qui rend l'architecture du systme pas trs visible. Les interactions entre composants nont pas suscit beaucoup dintention. En effet, dans Fractal les connecteurs sont dfinit implicitement et leur smantique enfouie au sein des composants. Les outils des ADLs (COSA et Fractal) favorisent les mcanismes dhritage et de composition. A la diffrence de COSA, seulement les composants peuvent hritier. Loutil FractalGUI fournit des avantages de rutilisation et tend offrir une composition hirarchique. Les outils des ADLs Fractal et COSA ne proposent pas explicitement, une manire de dfinir des styles architecturaux. Rcemment, Alti & al. (Alti, Boukerram, Derdour, Roose, 2010), ont propos une extension du mta-modle COSA avec la norme ISO-9126 (ISO-IEC, 2001) avec des attributs de qualit du systme et des styles architecturaux afin de supporter lvaluation mtaheuristique dune architecture base des styles architecturaux. En rsum, nous nous sommes intresss la description des systmes logiciels par leur modle, plutt que daller directement vers limplmentation, avec lutilisation des outils de COSA, que ceux de FractalGUI. La table 5.8, rcapitule cette comparaison, selon les critres de degr de lisibilit, de sparation des aspects, de sparation des concepts, de traabilit et dinstanciation.
CHAPITRE 5 Ralisation et Exprimentations Critres Lisibilit Sparation des concepts Sparation des aspects Raffinement Instanciation Gnration de code COSABuilder/COSAInstantiator Trs lisible Configurations Composants, connecteurs sont explicitement spars. Architecture et dploiement sont explicitement spars. Projection des modles Composants, Connecteurs, Configurations. Outil indpendant du langage dimplmentation FractalGUI Moins lisible Composants et connecteurs sont mlangs. Architecture et dploiement sont mlangs. Java Composants.
165
Code Fractal 2.0
Table 5.8. COSABuilder/COSAInstantiator vs. FractalGUI.
5.4.3 Synthse
Dans la majorit des outils (ArchJava, ArchStudio, AcmeStudio, FractalGUI, etc.), laccent est mis sur la validation de larchitecture de faon correcte. Ce point, concerne la validation de lADL COSA sur des cas rels. Loutil COSABuilder vise permettre aux architectes de dcrire graphiquement leurs architectures et de valider automatiquement leurs smantiques selon lapproche COSA. Laspect cl, de loutil COSAInstantiator est la possibilit de gnrer automatiquement un diteur graphique pour un modle darchitecture COSA et de crer des architectures dapplications correctes. A la diffrence des autres outils tels que ArchStduio, AcmeStudio, FractalGUI, etc. COSABuilder/COSAInstantiator, dfinit explicitement les configurations comme une entit de premire classe. COSABuilder / COSAInstantiator offre dautres avantages par rapport ces outils: un environnement de modlisation visuel permettant de modliser facilement des architectures logicielles complexes, un package complet des lments architecturaux : connecteurs de construction tels que Attachement, Extends, Binding et Utilisation, connecteurs dfinis par l'utilisateur, structures telles que la configuration des composants et des connecteurs, une bote outils et un modle standard COSA-eCore permettant de rduire le cot et la difficult de construire des modles d'architecture,
166
un support formel utilisant OCL, pour non seulement de validation dun modle, mais aussi il permet de trouver et de localiser tous les lments COSA, un processus dinstanciation automatique permettant de dfinir rapidement des applications logicielles, une sparation de l'application de l'architecture qui rend ces proccupations rutilisables, une prservation de la traabilit smantique de larchitecture COSA dans l'espace de modlisation eCore. une description plus adquate des proprits dfinies au niveau mta (concept EClass en eCore) plutt que d'utiliser un simple attribut cet effet. Les architectes qui utilisent COSABuilder peuvent faire face un certain nombre de problmes : Il n'y a pas de possibilit d'enregistrer, des parties dune architecture ou des contraintes des modles. Certains modles du systme doivent tre clarifis par l'utilisation des notes. On remarque l'absence de cette information sur le modle.
5.4.4 Amliorations futures

Le dveloppement des outils COSABuilder/COSAInstantiator, valide le travail ralis par Khammaci et al. Sur lADL COSA (Khammaci, Smeda, Oussalah, 2005). Les outils valident galement une partie des ides proposes dans cette thse autour des composants architecturaux (composants, connecteurs et configurations). Le problme est que le mtamodle eCore, facilite la manipulation dentits de type produit, mais beaucoup moins celle dentits de type architectures comme cest le cas des configurations et de connecteurs, donc, les concepts de base darchitectures logicielles. Les outils COSABuilder/COSAInstantiator ont t tests sur des systmes rels Secure Electronic Transaction System et Parking Access Control System (voir Annexe C.2). Cela dit, il reste toujours valider COSABuilder/COSAInstantiator sur des systmes complexes et larges avec des partenaires industriels.
167
5.5 Conclusion
Dans ce chapitre, nous avons prsent lintgration de larchitecture logicielle COSA au sein de MDA. Cette dernire passe par lutilisation du profil UML. En plus, nous avons prsent trois transformations : COSA (PIM) vers UML 2.0 (PSM), la transformation COSA profil UML (PSM) vers le mtamodle eCore (PSM) permet une projection de larchitecture abstraite COSA vers une architecture concrte eCore la transformation COSA profil UML (PSM) vers CORBA profil UML (PSM). Elle permet une projection de larchitecture COSA modlise avec UML vers la plate-forme CORBA. Pour chaque transformation nous avons ralis un Plug-In, implment dans la
plateforme Eclipse 3.1. Ensuite, nous avons appliqu, ces transformations au systme Client-Serveur. Les rsultats obtenus montrent que les concepts COSA sont fortement lis au profil UML (PSM) et se retrouvent spcifis dans les transformations PSM vers PSM (COSA-eCore) et (COSA-CORBA). A lheure actuelle, notre plug-in permet un architecte dapplications, de modliser correctement des architectures logicielles et de maintenir depuis une architecture, une instanciation correcte des applications. Nanmoins il reste toujours valider ces outils sur des systmes industriels complexes et larges. De cette tude comparative, de outils de COSA avec ceux des ADLs ACME et Fractal, on conclut que larchitecture abstraite COSA est entre dans une phase de concrtisation et dimplmentation au sein de MDA car les concepts architecturaux COSA se retrouvent au niveau des modles spcifiques deCore et de CORBA. Les outils de modlisation et dinstanciation COSA permettent de fournir la majorit des concepts dADLs, bass sur des implmentations de normes, UML, eCore/MOF et de CORBA et de conserver ainsi, la traabilit smantique entre larchitecture et limplmentation. Ces outils sont ouverts et extensibles, a permis dintgrer au plutt
168 Grce limplication des
les avances des volutions technologiques du monde acadmique et de la recherche, tout en les appliquant des solutions industrielles. partenaires industriels, ces outils plateforme de plus grande ampleur.
peuvent tre prenniss dans une nouvelle
Conclusion gnrale et perspectives
Bilan des travaux et apports de la thse

Les travaux dcrits dans cette thse portent sur la dfinition dun profil UML pour larchitecture logicielle et ensuite lintgration de ce profil dans la dmarche MDA. Analysons ce qui a t fait au niveau de ces travaux. Nous avons expos les approches de modlisation des architectures logicielles travers des travaux les plus significatifs dans le domaine. Les modlisations par objets, dite architectures logicielles base dobjets, et la modlisation par composants, dnomme architecture logicielle base de composants sont les deux approches qui ont merg pour dcrire les architectures logicielles. Ces deux approches sont trs semblables. En fait les deux sont bases sur les mmes concepts, qui sont labstraction et les interactions entre les entits. Cependant, chacune delles a ses avantages et galement ses dfauts. Ainsi, nous pensons quune architecture logicielle base sur les deux approches est trs prometteuse pour le futur de larchitecture logicielle et participera la rduction de la distance smantique entre la conception et limplmentation. Les objectifs de cette approche hybride consistent rduire les cots de dveloppement, amliorer la rutilisation des modles, faire partager des concepts communs aux utilisateurs de systmes et enfin construire des systmes htrognes base de composants rutilisables sur tagres (Component-Off-The-Shelf). A travers cette tude, nous avons mis en relief, les principaux objectifs de la modlisation des architectures logicielles. Par ailleurs, les langages de modlisation des architectures logicielles sont relatifs aux approches de modlisation par objets et par composants. Dans ce contexte, nous avons dcrit certains langages tout en explicitant les principaux concepts et leurs caractristiques. Les principaux concepts que doit supporter un langage de description
170 Tout en montrant, limportance de ce
darchitectures logicielles sont souligns.
mtamodle dans lapproche MDA, nous avons prsent la notion de profil qui donne sa dimension de flexibilit UML 2.0. Grce aux profils, il est possible dappliquer UML 2.0, larchitecture logicielle, autre que la modlisation dapplications ddies la prise en compte des architectures logicielles au sein de MDA. Un modle de description darchitecture et dune dmarche dlaboration dune architecture logicielle, est tudi. Une approche pour la description darchitecture logicielle baptise COSA (Component Object based Software Architecture), est prsente. COSA est une approche hybride, base sur la modlisation par objets et par composants. Pour traiter les interactions entre les composants, COSA dfini les connecteurs en tant quentits de premire classe. Par consquent, elle encourage la rutilisation non seulement des composants mais galement, celle des connecteurs, ainsi que lamlioration de la rutilisablilit et lextensibilit des lments pour soutenir les volutions dynamiques et statiques des lments architecturaux. Une solution pour rconcilier les besoins des architectures base de composants avec les notations orientes objets, rejoint les travaux de Garlan et de son quipe (Garlan 2000a ; Garlan, Cheng, Kompanek, 2001). Ltude des travaux, dans le domaine des architectures logicielles, dfini de faon explicite les concepts et les lments lis la description de larchitecture logicielle dun systme. Suite cette tude, nous avons propos une architecture trois niveaux de COSA pour guider larchitecte dans son processus de modlisation. Pour llaboration des modles darchitecture logicielle et leurs inter-relations, cette architecture sappuie sur trois niveaux dabstractions: niveau mta-architecture, niveau architecture, niveau application.
Elle prsente une spcification complte et structure de larchitecture logicielle COSA. Elle amliore la rutilisation des architectures logicielles en supportant une hirarchie pour les trois niveaux conceptuels.
171
Une proposition d'intgration de l'architecture logicielle COSA au sein de MDA, est tablie, ce qui nous a amen dfinir une stratgie de transformation directe par lutilisation du profil UML llaboration des transformations : - PIM vers PSM, COSA vers UML 2.0 - PSM vers PSM, COSA profil UML vers eCore et COSA profil UML vers CORBA. Lintrt de cette solution est de bnficier des concepts offerts par larchitecture COSA, ncessaires absolument, aux plates-formes dexcutions objets. Ils augmentent le degr de rutilisabilit des composants au niveau implmentation par lintgration explicite des connecteurs. Ils rduisent la complexit de contrle des interactions et des
interconnexions entre les composants logiciels. La projection des concepts COSA vers UML est fortement encourage en raison de la popularit dUML dans le monde industriel et elle permet de rsoudre la coordination des composants distribus dans standard international CORBA. Une solution dintgration des ADLs au sein de la dmarche MDA dont lintrt est largement reconnu, dans la communaut scientifique (Marcos, Acuna, Cuesta, 2006; Snchez et al. 2006) est propos dans ce travail. Les ralisations et les exprimentations rsultant du profil UML 2.0 pour COSA et lintgration de ce profil, dans la dmarche MDA : PIM vers PSM, COSA vers UML 2.0, PSM vers PSM, COSA profil UML vers eCore et COSA profil UML vers CORBA, valides sur une application de type Client-Serveur, laissent prsager des rsultats forts intressants. Une tude comparative entre COSABuilder et ACMEStudio et Fractal, couronne bien ce travail.
Intrts du travail
Ces intrts se rsument, comme suit : 1- Dfinition dun profil UML 2.0 pour larchitecture logicielle COSA. Lintrt primordial dun profil UML 2.0 de COSA est d'exprimer les concepts architecturaux en UML 2.0 et donc de dfinir de manire formelle les concepts de l'architecture logicielle COSA. En dautre terme, lutilisation de strotypes, de rgles et de valeurs marques permet prcisment de mieux capturer les concepts de l'architecture COSA.
172
2- Lexploitation des capacits de profil UML (modle et mtamodle) base sur un ensemble des strotypes dots des contraintes OCL dans la projection de larchitecture logicielle COSA vers UML et vers les plates-formes dexcution, permet de mieux clarifier la smantique de ce modle. 3- Lintgration du profil UML 2.0 pour COSA au sein de la dmarche MDA. Les profils UML existants sont ddis un type dapplication (systme distribu, temps rel, etc...) alors que ntre profil est indpendant et spcialis dans une activit particulire de modlisation des langages de description darchitectures. Lintgration de ce profil au sein de MDA, confre aux modles darchitectures objets, un niveau dabstraction haut et un degr de rutilisation quivalent celui de larchitecture COSA. 4- Une stratgie de transformation directe par lutilisation du profil UML llaboration des transformations PIM vers PSM, COSA vers UML 2.0 et PSM vers PSM, COSA profil UML vers CORBA. Notre objectif est dautomatiser le processus de drivation des plateformes dimplmentation depuis les concepts darchitecture logicielle.
Conclusion
Notre travail, est orient en deux axes : la dfinition et la vrification formelle des concepts de l'architecture logicielle et lintgration des concepts darchitecture logicielle au sein de MDA Le premier axe concerne la dfinition formelle des concepts de l'architecture logicielle COSA. En effet, certains concepts tels que les connecteurs, les configurations, la glu, les rles, les associations dattachements Binding, Use sont spcifis formellement. Lexploitation des capacits de profil UML (modle et mtamodle) pour la dfinition formelle de ces concepts permet de mieux clarifier la smantique de ce modle. Cela
prouve la cohrence structurelle des architectures des systmes logiciels. Le systme de type Client-Serveur, nous permet de mieux se rendre compte, des aspects darchitectures logicielles dans les systmes complexes. Le deuxime axe concerne lintgration des concepts darchitecture logicielle au sein de MDA : nous avons montr grce aux transformations COSA vers UML 2.0, COSA-UML
173
vers eCore et COSA-UML vers CORBA, quil est possible dautomatiser partiellement la prise en compte des architectures logicielles pour leurs aspects structuraux. Il reste encore la prise en compte de leurs aspects dynamiques. Il nous semble trs intressant de gnrer un sous-ensemble de la partie dynamique. Cependant, pour prendre en compte des aspects dynamiques, il faut ncessairement que larchitecture logicielle COSA gagne en compltude, pour ses aspects dynamiques.
Perspectives
Le travail de thse a permis la mise en place dun cadre conceptuel pour la modlisation des architectures logicielles. Il sagit dune dfinition dun profil UML pour larchitecture logicielle (particulirement COSA) et ensuite lintgration de ce profil dans la dmarche MDA. Cette thse peut se prolonger vers plusieurs perspectives de recherche quon peut rsumer autour de cinq points.
Styles Architecturaux
Ce premier point concerne lamlioration de lapproche COSA en dfinissant des contraintes et des rgles spciales pour supporter les styles architecturaux. Comme nous lavons vu, dans le chapitre 2, les styles architecturaux dfinissent une famille de systmes en terme de patterns dorganisation structurelle. Ils dterminent lensemble du vocabulaire dsignant le type des entits de base (composants et connecteurs) tels que pipe-filtre, client-serveur, vnement, processus, tableau noir, etc. Si nous
intgrons des styles architecturaux COSA, les architectures htrognes seront plus faciles dfinir. Nous pouvons aussi dfinir de nouvelles architectures en composant diffrents styles et de des nouvelles mtriques de qualit architecturale tels que la complexit structurelle, le couplage et la cohsion.
Mcanisme de raffinement
Il est fortement souhaitable de fournir un mcanisme de raffinement pour lapproche COSA. Ce point concernant la dfinition des patrons des connecteurs architecturaux pour le dveloppement des architectures base dUML. Lutilisation du langage OCL permet la vrification formelle des connecteurs architecturaux et lapplication
174
progressive des patrons des connecteurs permet de pallier au problme de traabilit entre larchitecture et son systme excutable.
Description formelle des modles

Il est important de formaliser les concepts du modle COSA et du mta-modle MADL (Meta Architecture Description Language) (Smeda, Oussalah, Khammaci, 2005b). Un premier effort avec une esquisse dutilisation OCL a t ralis dans le chapitre 5. Toutefois cet effort doit tre poursuivi pour la description formelle de nos deux modles, comme avec, la mthode B (Abrial, 1996 ; Abrial, 1999) ou CSP (Hoare, 1995) tel quil est utilis dans Wright (Allen, Garlan, 1997). Une telle technique permet de mieux prciser les concepts proposs dans COSA et MADL et denlever les ambiguts dans la dfinition de leurs concepts. En outre, lutilisation du la mthode B dans la projection de COSA vers UML permet de mieux clarifier la smantique ou les variantes smantiques de ces modles. Ce travail fait lobjet actuellement une suite de notre thse.
Intgration smantique des ADLs au sein de MDA par une ontologie

Lide ici serait de gnraliser notre approche dintgration des concepts
darchitectures logicielles pour nimporte quel ADL (COSA, ACME, Fractal, etc.) et pour nimporte quelle plateforme dexcution (CORBA, EJB, .NET). Si nous utilisons une ontologie architecturale, les architectures htrognes seront plus faciles intgrer.
Description contextuelle des modles

Ce point concerne lextension des concepts du COSA pour prendre en compte la
qualit dune architecture logicielle et le contexte (ressources, prfrences de lutilisateur et les contraintes).
Bibliographie
175
Bibliographie
Abrial J.R., (1996). The B-Book: Assigning Programs to Meanings, Cambridge University Press. Abrial J.R., (1999). Introducing Dynamic Constraints in B, In D. Bert (Ed.), B99: Recent Advances in the Developement and Use of the B Method, (LNCS: Springer-Verlag, 1998, pp 83-128). ADL Toolkit., (2004). http://www-2.cs.cmu.edu/~acme/adltk/tools.html Accord., (2002). Etat de lArt sur les Langages de Description sArchitecture (ADLs), Rapport technique, INRIA, France. Aldrich J., Chambers C., Notkin D., (2001). Component-Oriented Programming in ArchJava, Proceedings of the First OOPSLA Workshop on Language Mechanisms for Programming Software Components, Tampa Bay, Florida. Aldrich J., Chambers C., Notkin D., (2002). ArchJava: Connecting Software Architecture to Implementation, Proceedings of the 24th International Conference on Software Engineering (ICSE02), Orlando (USA). Aldrich J., Sazawal V., Chambers C., Notkin D., (2003). Language Support for Connector Abstractions, Proceedings of the 2003 European Conference on Object-Oriented Programming (ECOOP03), Darmstadt (Germany). Allen R., Garlan G., (1994). Formalizing Architectural Connection, Proceedings of the Sixteenth International Conference on Software Engineering (ICSE94), Sorrento (Italy). Allen R., Garlan G., (1997). A Formal Basis for Architectural Connection. ACM Transactions on Software Engineering and Methodology, Vol. 6, No. 3, pp 213-249. Allen R., Douence R., Garlan D., (1998). Specifying and Analyzing Dynamic Software Architecture, Proceedings of the Conference on Fundamental Approaches to Software Engineering, Lisbon, Portugal.
Bibliographie
176
Alloui I., Oquendo F., (2004). Describing Software-intensive Process Architectures using a UMLbased ADL. In Proceedings of the Sixth International Conference on Enterprise Information Systems (ICEIS'04), Porto (Portugal), pp 201-208. Alti A., Khammaci T., (2005). Transformation des concepts des composants architecturaux en UML 2.0. 1er Congrs International en Informatique applique (CIIA05), pp 14 -21, B.B.A Algrie, ISBN: 9947-0-1042-2, 19 -21 novembre. Alti A., Khammaci T., Smeda A., (2006). Building UML Profile for COSA Software Architecture. 2nd IEEE Conference on Information and Communication Technologies: From Theory to Applications (ICTTA06), ISBN: 0-7803-9521-2, Damascus (Syria), Vol. 2, pp 1041 -1042, 24-28 April. Alti A., Khammaci T., Smeda A., (2007a). Representing and Formally Modelling COSA Software Architecture with UML 2.0 Profile, International Review on Computers and Software, ISSN: 1828-6003, Vol. 2, No. 1, pp 30-37. Alti A., Khammaci T., Smeda A., (2007b). Towards an Automatic Transformation From COSA Software Architecture To CORBA platform, First International Conference on Digital Communications and Computer Applications (DCCA07), ISBN: 0-7803-9521-2, Just (Jordan), pp 980 989, 19 -21 Mars. Alti A., Khammaci T., Smeda A., Bennouar D., (2007). Integrating Software Architecture Concepts into the MDA Platform. The Second International Conference on Software and Data Technologie (ICSOFT07), INSTICC Press, ISBN: 978-989-8111-05-0, Barcelona (Espagne), INSTICC Press, Vol. 1, pp 30-37, 19-49 July. Alti A., Smeda A., (2007). Intgration de larchitecture logicielle COSA au sein de MDA : Retour dexpriences, Actes de 6me atelier sur les Objets, Composants et Modles dans lingnierie des Systmes dInformation, held in conjunction with INFORSID 2007, Perros-Guirec, France, pp 144-156, 22 -25 Mai. Alti A., (2008). An Automatic Transformation from COSA Software Architecture to EJB Platform. 3rd IEEE Conference on Information and Communication Technologies: From Theory to Applications (ICTTA08), ISBN: 978-1-4244-1751-3, Damascus (Syria), Vol. 3, pp 1 -6, 7-11 April. Alti A., Smeda A.,(2008). Integration of Architectural Design and Implementation Decisions into the MDA Framewrok. The Third International Conference on Software and Data
Bibliographie
177
Technologie (ICSOFT08), ISBN: 978-989-8111-52-4, INSTICC Press, Porto (Portugal), pp 366-371, July 5-8 2008. Alti A., Djoudi M., (2009). Patrons des Connecteurs Architecturaux pour le Dveloppement des Architectures base dUML, 1er Confrence Internationale des Technologies de lInformation et de la Communication (CITIC09), Stif (Algrie), pp 58, 4 -5 Mai. Alti A., Boukerram A., Smeda A., Maillard S., Oussalah M., (2010). COSABuilder and
COSAInstantiator: An Extensible Tool for Architectural Description, International Journal of Software Engineering and Knowledge Engineering, ISSN : 0218-1940, Vol. 20, No. 3, pp 423-455. Alti A., Boukerram A., Roose P,. (2010). Context-Aware Quality Model Driven Approach: A New Approach for Quality Control in Pervasive Computing Environments. The 4th European Conference on Software Architecture (ECSA 2010), LNCS 6285 Springer, ISBN 978-3-642-15113-2, Copenhagen (Denmark), pp 441-448, 23 -26 August. Atlas group LINA, INRIA Nantes, (2007) ATL: Atlas Transformation Language, ATL User Manual version 7.0. Amirat A., Oussalah M., (2009). Towards an UML Profile for the Description of Software Architecture, Proceedings of the First International Conference on Applied Informatics (ICAI'09), Bou Arrridj (Algeria), pp , 15-17, November 2009 ArchJava., (2004). Disponible sur http://archjava.fluid.cs.cmu.edu. Baker S., CORBA Distributed Objects Using Orbit, Addison Wesley, 1997. Balter R., Bellissard F., Boyer F., Riveill M., Vion-Dury J., (1998). Architecturing and Configuring Distributed Applications with Olan, Proceedings of IFIP International Conference on Distributed Systems Platforms and Open Distributed Processing (Middleware98), The Lake District, UK, pp 241-256. Barbier F., Cauvet G., Oussalah M., Rieu D., Souveyet C., (2004). Concepts Cls et Techniques de Rutilisation dans lIngnierie des Systmes dInformation. Ingnierie des Composants dans les Systmes Dinformations, M. Oussalah et D. Rieu (rd.), Hermes Science Publications.
Bibliographie
178
Service, Rapport technique, http://www-
Bartlett D., (2004). OMG Interface Definition Language, Defining the Capabilities of a Distributed
128.ibm.com/devloperworks/webservices/library/co-corbajct3.html. Bass L., Clements P., R. Kazman, (1998). Software Architecture in Practice. Addison-Wesly Publishing, Reading, Massachusetts. Bzivin J., (2005). Model Driven Engineering: An Emerging Technical Space, in Proc. Generative and Transformational Techniques in Software Eng., Braga, Portugal, pp. 36-64, July 4 -8 Booch G., (1994). Object-Oriented Analysis and Design with Applications. The
Benjamin/Cummings Publishing Company Inc., Redwood City, California. Booch G., Rumbaugh J., Jacobson I., (1998). The Unified Modeling Language User Guide. Addison-Wesly Publishing, Reading, Massachusetts. Brinkkemper S., Hang S., Bulthuis A. and van den Gor G., (1995). Object-Oriented Analysis and Design Methods: A Comparative Review. Disponible sur
http://elex.amu.edu.pl/languages/oodoc/oo.html. Bruneton E., (2004). Developing with Fractal, the ObjectWeb Consortium, disponible sur http://fractal.objectweb.org/tutoriel/2004 Clements P., Bachmann F., Bass L., Garlan D., Ivers J., Little R., Nord R., Stafford J., (2002). Documenting Software Architectures: Views and Beyond. Boston, MA: Addison-Wesley. Clements P., (2003). Documenting Software Architectures: Views and Beyond. Addison-Wesly Publishing, Reading, Massachusetts. Cheng S., Garlan D., (2001). Mapping architectural Concepts to UML-RT, Proceedings of the Parallel and Distributed Processing Techniques and Applications, USA. Ciancarini P., Mascolo C., (1996).Analyzing and Refining an Architectural Style. Coupaye D., Bruneton E. Stefani J., (2002). The Fractal Composition Framework, Proposed Final Draft of Interface Specification version 0.9, the ObjectWeb Consortium. Cox B.J., (1986). Object-Oriented-Programming-an Evolutionary Approach, Addison-Wesly ISBN: 0-201-10393-1. DeRemer F., Kron H., (1976). Programming-in-the-Large Versus Programming-in-the-Small, IEEE Transactions on Software Engineering SE-2, Vol. 2, pp 321-327.
Bibliographie
179
Eclipse,(2006).http://www.openarchitectureware.org/pub/documentation/4.3.1/html/conte/ ts/uml2ecore_reference.html Egyed A., Krutchen P., (1999). Rose/Architect: a tool to visualize architecture. Proceedings of the 32nd Annual Hawaii International Conference on Systems Sciences (HICSS99). FractalGUI., (2005).http://fractal.ow2.org/fractalgui/index.html Frankel D., (2003). Model Driven Architecture, Applying MDA to Enterprise Computing, Wiley, Indianapolis, USA. Gammma E., Helm R., Johnson R., Vlissides J., (1995). Design Patterns, Elements of Reusable Object-Oriented Software. Addison-Wesly Publishing, Reading, Tortora (rd.), World Scientific Publishing Company, Singapore, pp 1-39. Garlan D., (1995). What is Style? , Proceedings of the Dagstuhl Workshop on Software Architecture, Saarbruecken (Germany). Garlan D., (2000a). Software Architecture and Object-Oriented Systems. Proceedings of the IPSJ Object-Oriented Symposium 2000, Tokyo, Japan. Garlan D., (2000b). Software Architecture: A Roadmap, In ICSA2000, 22nd International Conference on Software Engineering, pp 91-101. Garlan D., Shaw M., (1993). An Introduction to Software Architecture, Advances in Software Engineering and Knowledge Engineering, V. Ambriola and G. Tortora (rd.), World Scientific Publishing Company, Singapore, pp 1-39. Garlan D., Allen R., Ockerbloom J., (1994). Exploiting Style in Architectural Design Environments, Proceedings of the 2nd ACM SIGSOFT Symposium on Foundations of Software Engineering, New Orleans, Louisiana, USA, pp 175 188. Garlan D., Perry D., (1995). Introduction to the Special Issue on Software Architecture. IEEE Transactions on Software Engineering, Vol. 21, No. 4. Garlan D., Monroe R., Wile D., (1997). Acme: An Architecture Description Interchange Language, Proceedings of CASCON97, Toronto, Canada. Garlan D., Monroe R., Wile D., (2000). Acme: Architectural Description of Component-Based Systems, Leavens Gary and Sitaraman Murali, Foundations of Component-Based Systems, Cambridge University Press, pp.47-68.
Bibliographie
180
Garlan D., Monroe R., Wile D., (2000). Acme: Architectural Description of Component-Based Systems. Foundations of Component-Based Systems, Leavens Gary et Sitaraman Murali (rd.) Cambridge University Press, pp 47-68. Garlan D., Chang S., Kompanek J., (2001). Reconciling the Needs of Architectural Description with Object-Modeling Notations. Science of Computer Programming Journal 44 (Elsevier Press, 2001), pp 23-49. Garlan D., Cheng S.W., Kompanek A., (2002). Reconciling the Needs of Architectural Description with Object-Modeling Notations. Science of Computer Programming Journal, Special UML, Edition 44, Elsevier Press, pp 23-49. GMF, (2006). Introduction to the Eclipse Graphical Modeling Framework, Eclipse, IBM, and Borland, Editors. EclipseCon 2006, available at http://bdn1.borland.com/devcon05/ article/1,2006,33309,00.html. Goulao M., Abreu F.B., (2003). Bridging the gap between ACME and UML 2.0 for CBS, In Proceedings Workshop of Specification and Verification of Component-Based Systems, Helsinki, Finland. Graiet M., Bhiri M.T., Dammak F., Giraudin J.P., (2006). Adaptation dUML 2.0 lADL Wright. 1re Confrence Francophone sur les Architectures Logicielles, ISSN: 7462-1577, pp 83- 96. Grim R., (1997). Professional DCOM Programming, First edition, Peer Information Inc., ISBN: 186100060X. Hasselbring W., (2002). Component-Based Software Engineering, Handbook of Software Engineering and Knowledge Engineering, 2 ed. S.K. Chang (World Scientific Publishing Company, Singapore), pp 289-49. Hoare C., (1995). Communicating Sequential Processes, Prentice Hall International, Englewood Cliffs, N.J, ISBN: 0131532718. Hofmeister C., Nord R.L., Soni D., (1999). Describing Software Architecture with UML. Proceedings of the First Working IFIP Conference on Software Architecture, San Antonio, Texas, IEEE Computer Society Press, pp 145-160. ISO-IEC, (2001). ISO/IEC 9126-1 in Software Engineering Product quality Part 1: Quality model.
Bibliographie
181
Ivers J., Clements P., Garlan D., Nord R., Schmerl B., Silva J.R., (2004). Documenting Component and Connector Views with UML 2.0. Technical Report CMU/SEI-2004-TR008, School of Computer Science, Carnegie Mellon University. Jacobson I., Chirterson M., Jonsson P., et Overgaard G., (1992). Object-Oriented Software Engineering, Addison-Wesly Publishing, Reading, Massachusetts. Kazman R., OBrien L., Verhoef C.,(2001). Architecture Reconstruction Guidelines, Technical report. Khammaci T., Oussalah M., Smeda A., (2003). Les ADLs : Une Voie Prometteuse Pour les Architectures Logicielles, Agents, Logiciels, Coopration, Apprentissage & Activit Humaine 2003 (ALCAA03), Bayonne, France. Khammaci T., Smeda A., Oussalah M., (2004). ALBACO : Une Architecture Logicielle Base de Composants et dObjets pour la Description de Systmes Complexes. Proceedings of the 8th Maghrebian Conference on Software Engineering and Artificial Intelligence (MCSEAI 2004), Sousse, Tunisie. Khammaci T., Smeda A. Oussalah M., (2005). Coexistence of Software Architecture and Object Oriented Modeling, Handbook of Software Engineering and Knowledge Engineering Volume 3: Recent Advances, S.K. Chang (rd.), World Scientific Publications Co., Singapore, ISBN : 98125627737, pp 119-150. Krutchen P.B., (1995). The 4+1 View Model of architecture. IEEE Transaction on Software Engineering, Vol. 12, No. 6, pp 42-50. Kruchtan P.B., Selic B., Kozaczynski W., (2001). Describing Software Architecture with UML. Proceedings of the 23rd International Conference on Software Engineering, pp 715-716. Luckham D., Augustin L., Kenny J., Vera J., Bryan D. et Mann W. (1995). Specification and Analysis of System Architecture using Rapide, IEEE Transactions on Software Engineering, Vol. 21, No. 4, pp 336-355. Maillard S., Smeda A., Oussalah M., (2007). COSA: An Architectural Description Meta-Model. Proceedings of the Second International Conference on Software and Data Technologies, Volume SE, Barcelona (Spain), INSTICC Press 2007, ISBN 978-989-8111-06-7, pp 445-448, July 22-25.
Bibliographie
182
Magee J., Dulay N., Eisenbach S., and Karmer J., (1996). Specifying Distributed Software Architectures. Proceedings of the Fifth European Software Engineering Conference, Barcelona (Spain), September 1995. Magee J., and Karmer J., (1996). Dynamic Structure in Software Architecture. Proceedings of ACM SIGSOFT96: Fourth Symposium Foundation of Software Engineering, San Francisco, CA, pp 3-14. Mcllroy D., (1968). Mass-produced Software Components.1st International Conference on Software Engineering, Garmish Pattenkirschen, Germany. Magee J., Dulay N., Eisenbach S., Karmer J., (1995). Specifying Distributed Software Architectures, Proceedings of the Fifth European Software Engineering Conference, Barcelona (Spain). Magee J., Karmer J., (1996). Dynamic Structure in Software Architecture, Proceedings of ACM SIGSOFT96 : Fourth Symposium Foundation of Software Engineering, San Francisco, CA, pp 3-14,. Manset D., Verjus H., McClatchey R., Oquendo F. (2006), A Formal Architecture-Centric, Model-Driven Approach for the Automatic Generation of Grid Applications, Proceedings of the 8th International Conference on Enterprise Information Systems, ICEIS, Paphos, May. Marcos E., Acua C.J., Cuesta C.E., (2006). Integrating Software Architecture into a MDA Framework. In EWSA2006, 3th European Workshop on Software Architecture. Nantes, France, pp128 -143. Martin J., (1996). Principles of Object-Oriented Analysis and Design, Prentice-Hall, Englewood Cliffs, New Jersy, CA, pp 3-14. Medvidovic N., Oreizy P., Robbins J., Taylor R., (1996). Using Object-Oriented Typing to Support Architectural Design in the C2 Style. Proceedings of ACM/IGSOFT96: Fourth Symposium on the Foundations of Software Engineering, San Francisco, CA. Medvidovic N., Taylor R., Whitehead E., (1996). Formal Modeling of Software Architecture at Multiple Levels of Abstraction, Proceedings of the 1996 California Software
Symposium, Los Angles, CA, pp 28-40.
Bibliographie
183
Medvidovic N., Rosenblum D., Taylor R., (1999). A Language and Environment for Architecture-Based Software Development and Evolution, Proceedings of 21st International Conference on Software Engineering, Los Anglos, CA, pp 44-53. Medvidovic N., Taylor R., (2000). A Classification and Comparison Framework for Software Architecture Description Languages, IEEE Transactions on Software Engineering, Vol. 26, No. 1, pp 2-57. Medvidovic N., Rosenblum D.S., Robbins J.E., Redmiles D.F., (2002). Modeling Software Architecture in the Unified Modeling Language, ACM Transactions on Software Engineering and Methodology, Vol.11, No. 1, pp 2-57. Mehta N., Medvidovic N., Phadke S., (2000). Twords a Taxonomy of Software Connectors, 22nd International Conference on Software Engineering, Limerick (Ireland). Model Driven Architecture., (2002). http://www.omg.org/mda Murata T., (1989). Petri Nets: Properties, Analysis and Applications, Proceedings of the IEEE, Vol.77, No. 4, pp 541-580. Object Management Group., (1997). UML Semantics and Appendices v1.1, disponible sur http://www.omg.org/docs/ad/97-09-07.pdf . Object Management Group., (2001). Unified Modeling Language Specification V.1.4., http://www.omg.org/docs/formal/01-09-67.pdf. Object Management Group., (2002). CORBA Components: An Adopted Specification. http://www.omg.org/docs/formal/02-06-66.pdf. Object Management Group., (2004a). UML 2.0 Superstructure Specification: Revised Final Adopted Specification. http://www.omg.org/docs/ptc /04-10-02.pdf . Object Management Group., (2004b). UML Profile for CORBA Components Specification. http://www.omg.org/docs/ptc /04-03-04.pdf Object Management Group., (2005). UML OCL 2.0 Specification: Revised Final Adopted Specification. http://www.omg.org/docs/ptc /05-06-06.pdf. Object Management Group., (2008). Catalog of UML Profile Specifications.
http://www.omg.org/technology/documents/profile_catalog.htm .
Bibliographie
184
Oquendo F., Cmpan S., Balasubramaniam D., Kirby G., Morrison R., (2002). The ArchWare ADL: Definition of the Textual Concrete Syntax, Technical Report D1.2b, ArchWare Project IST-2001-32360. Oquendo F., (2004). -ADL: an Architecture Description Language Based on the Higher Order Typed -calculus for Specifying Dynamic and Mobile Software Architectures. ACM Software Engineering Notes, ISSN: 0163-5948, Vol. 29. No. 3, pp 15-28. Oquendo F., (2006). Formally Modelling Software Architecture with the UML 2.0 Profile For ADL, ACM SIGSOFT Engineering Notes, ISSN: 0163-5948, Vol. 31, No. 1, pp 1-13. Oussalah C., Smeda A., Khammaci T., (2004). An Explicit Definition of Connectors for Component, Proceedings 11th IEEE International Conference and Workshop on the Engineering of Computer-Based Systems (ECBS 2004), pp 44-51, Brno (Czech Republic). Oussalah C., Khammaci T., Smeda A., (2005). Les composants : dfinitions et concepts de base, dans Ingnierie des composants, Editions Vuibert, ISBN 2-7117-4836-7. Perry D., (1997). Software Architecture and its Relevance to Software Engineering, Invited talk, Proceedings of the Second International Conference on Coordination Models and Languages, Berlin (Germany). Perry D., Wolf A., (1992). Foundations for Study of Software Architecture, ACM/SIGSOFT Software Engineering Notes, Vol. 17, pp 40-52. Pilone D., Pitman N., (2005). UML 2.0 in a Nutshell, OReilly & Associates, Portland, Oregon, ISBN: 0596007957. Plasil F., Balek M., Janecek R., (1998). SOFA/DUCP: Architecture for Component Trading and Dynamic Updating, Proceedings of ICCDS98, IEEE CS Press, Annapolis, Maryland, USA, 1998. Plasil F., Besta M., Visnovsky S., (1999). Bounding Component Behavior via Protocols, Proceedings of Technology of Object-Oriented Languages and Systems (TOOLS99), Santa Barbara, USA. Ratcliffe O., (2005). Approche et Environnement Fonds sur les Styles Architecturaux pour le Dveloppement de Logiciels Propres des Domaines Spcifiques, Thse de Doctorat, Universit de Savoie, Annecy.
Bibliographie
185
Rodrigues M.N., Lucena L., Batista T., (2004). From Acme to CORBA: Bridging the Gap. In EWSA2004, the 1st European Workshop on Software Architecture, pp. 103-114. Roman E., Amber S., Jewell T., Marinescu F., (2004). Mastering Entreprise JavaBeans, 3rd Edition, John Willey et Sons, Canada, ISBN 0764576828. Roh S., Kim K., Jeon T., (2004).Architecture Modeling Language based on UML 2.0, Proceedings of the 11 th Asia-Pacific Software Engineering Conference (APSEC04). Rosenblum D., Medvedovic N., (1997). Domain of Concern in Software Architectures and Architecture Description Languages, Proceedings of the USENIX Conference on Domain Specific Languages, CA. R-software., (2008). The R Project for Statistical Computing, http://www.r-project.org Rubin W., Brain M., (1998). Understanding DCOM, Prentice Hall Englewood, Cliffs, New Jersy, ISBN: 0130959669. Rumbaugh J., Blaha M., Permerlani W., Eddy F. et Lorensen W., (1991). Object-Oriented Modeling and Design, Practice-Hall, Englewood Cliffs, New Jersey, ISBN: 0136298419. Sadou N., Oussalah M., Tamzalit D., (2005). Software Architecture Evolution: Description and Management Process, Proceedings of The 2005 International Conference on Software Engineering Research and Practice (SERP05), Las Vegas, Nevada. Sadou N., Tamzalit D., Oussalah M., (2005). A Unified Approach for Software Architecture Evolution at Different Abstraction Levels, Proceedings of International Workshop on Principals of Software Evolution, Lisbon, Portugal. Snchez P., Magno J., Fuentes L., Moreira A., Arajo J., (2006). Towards MDD Transformation from AORE into AOA. In EWSA2006, Proceedings of the 3th European Workshop on Software Architecture. France, pp 159 -174. Selic B., (1999). Turing Clockwise: Using UML in the Real-Time Domain. Communication of the ACM, Vol. 42, No. 10, pp 46-54. Selic B., Rumbaugh J., (2000). Using UML for Modeling Complex Real-Time Systems, Object Time white paper, June 2000, http://www.objecttime.com
Bibliographie
186
Shaw M., DeLine R., Klein G., Ross G., Young D., Zelesnik G., (1995). Abstractions for Software Architecture and Tools to Support Them. IEEE Transaction on Software Engineering, Vol. 21, No. 4. Shaw M., DeLine R., Zelesnik G., (1996). Abstractions and Implementations for Architectural Connections. Proceedings of the 3rd International Conference on Configurable Distributed Systems, Annapolis, Maryland. Shaw M., Garlan D., (1996). Software Architecture: Perspectives on an Emerging Discipline, Prentice-Hall, Upper Saddle River, N.J., ISBN: 0131829572. Smeda A., Khammaci T., Oussalah M., (2003). Software Connectors Reuse in Component-Based Systems, Proceedings of the IEEE International Conference on Information Reuse and Integration (IRI03), Las Vegas, Nevada. Smeda A., Khammaci T., Oussalah M., (2004a). A Multi-Paradigm Approach to Describe Complex Software System, Journal of WSEAS Transactions on Computers, ISSN: 11092750, Vol. 3, No. 4, pp 936-941. Smeda A., Khammaci T., Oussalah M., (2004b). Operational Mechanisms for Component-Object Based Software Architecture. First IEEE Conference on Information and Communication Technologies: From Theory to Applications (ICTTA06), Damascus (Syria). Smeda A., Oussalah M., Khammaci T., (2005a). Mapping ADLs into UML 2.0 Using a Meta ADL, Proceedings of 5th Working IEEE/IFIP Conference on Software Architecture (WICSA05), IEEE CS. Press, ISSN: 1109-2750, Pittsburg (Pannsylvania), Vol. 3, No. 4, pp 936-941. Smeda A., Oussalah M., Khammaci T., (2005b). MADL: Meta Architecture Description Language, Proceedings of SERA 2005, IEE CS Press, Pleasant, Michigan, USA. Smeda A., Khammaci T., Oussalah M., (2005c). Les Modles de Composants Acadmiques, Ingnierie des Composants : Concepts, Techniques et Outils, M. Oussalah (rd). Vuibert Informatique, Paris, ISBN 2711748367. Smeda A., Alti A., Oussalah M., Boukerram A., (2009). COSAStudio: A Software Architecture Modeling Tool, World Congress on Science, Engineering And Technology (WCSET'09), ISSN: 1307 - 6892, No. 49, pp 263-266, 28 -30 Januray 2009.
Bibliographie
187
Soni D., Nord R.L., Hofmeister C., (1995). Software Architecture in Industrial Applications, Proceedings of the 17th International Conference on Software Engineering (ICSE17), Seattle, WA, USA (1995) pp 196-207. Souc J., Duchien L., (2002). Etat de lArt sur les Langages de Description dArchitecture (ADLs), CNAM-CEDRIC, USTL-LIFL, RNTL ACCORD. Taylor R., (1996). A Component-and Message- Based Architectural Style for GUI Software, IEEE Transactions on Software Engineering, Vol.22, No. 6. UML Toolkit., (2005). http://www.netfective.com/?cID=produits0 Van Ommering R., Van Der Linden Karmer F., J., Magee J., (2000). The Koala Component Model for Consumer Electronics Software, IEEE Computer, p. 78 -85. Vestal S., (1996). MetaH Programmers Manual 1.09, Rapport Technique, Honeywell Technology Center, Minneapolis, MN. Villa T., Kam T., Brayton R., Sagiovanni-Vincentelli A., Sangiovanni-Vincentelli A.,(1997). Synthesis of Finite State Machines : Logic Optimization, Kluwer Academic Publishers, Philip Drive/ Norwell, MA, ISBN:0792398920. Warmer J., Kleppe A., (1998). The Object Constraint Language: Precise Modeling with UML, Addison-Wesly Publishing, Reading, Massachusetts.
Liste des publications personnelle
188
Liste des publications personnelles
Chapitres dans des ouvrages

Alti A., Boukerram A., Roose P., (2010). Context-Aware Quality Model Driven Approach: A New Approach for Quality Control in Pervasive Computing Environments. In Muhammad Babar and Ian Gorton, editors, Software Architecture, Volume 6285 of Lecture Notes in Computer Science Springer, ISBN 978-3-642-15113-2, Copenhagen (Denmark), pp 441-448, August 23 26, 2010. index par ISI-JCR (Thomson Reuters).
Publications dans des revues internationales

Alti A., Khammaci T., Smeda A., (2007). Representing and Formally Modelling COSA Software Architecture with UML 2.0 Profile, International Review on Computers and Software, ISSN: 1828-6003, Vol. 2, No. 1, pp 30-37, January 2007. Alti A., Khammaci T., Smeda A., (2007). Using B Formal Method to Define Software
Architecture Behavioral Concepts, International Review on Computers and Software, ISSN: 1828-6003, Vol. 2, No. 5, pp 510-519, September 2007. Alti A., Khammaci T., Smeda A., (2007). Integrating Software Architecture Concepts into the MDA Platform with UML Profile, Journal of Computer Science, ISSN: 1549-3636, Vol. 3, No. 10, pp 793-802, October 2007. Makhlouf D., Roose P., Dalmau M., Ghoualmi-Zine N., Alti A., (2010). Vers une architecture d'adaptation automatique des applications reparties bases composants - Revue des Nouvelles Technologies de l'Information, Confrence francophone sur les Architectures Logicielles (CAL 2010), ISSN : 174 1667, pp. 1-14, March 2010. Alti A., Boukerram A., Smeda A., Maillard S., Oussalah M., (2010). COSABuilder and
COSAInstantiator: An Extensible Tool for Architectural Description, International
189
Journal of Software Engineering and Knowledge Engineering, ISSN: 0218-1940, Vol. 20, No. 3, pp 423-455, May 2010. ISI-JCR Facteur dimpact (2008):0.447. Makhlouf D., Roose P., Dalmau M., Ghoualmi Z., Alti A., (2010). UML-Profile for Multimedia Software Architectures - International Journal of Multimedia Intelligence and Security (IJMIS) Inderscience Publishers, Vol. 1, No. 3, pp. 209-231, 2010. index par ISI (Thomson Reuters). Makhlouf D., Roose P., Dalmau M., Ghoualmi-Zine N., Alti A., (2010). MMSA: Metamodel Multimedia Software Architecture - Advances In Multimedia, Hindawi Ed. ISSN : 16875680, DOI 10-1155, e-ISSN: 1687-5699, pp. 1-17, July 2010. index par ISI (Thomson Reuters). Makhlouf D., Roose P., Dalmau M., Ghoualmi-Zine N., Alti A., (2010). Une approche pour les architectures logicielles composants multimdia An International Journal on Information - Interaction Intelligence, ISSN 0249-6399, Vol. 10 N. 2, 2010.
Communications dans des confrences internationales

Alti A., Khammaci T., Smeda A., (2006). Building UML Profile for COSA Software Architecture. 2nd IEEE Conference on Information and Communication Technologies: From Theory to Applications (ICTTA06), ISBN: 0-7803-9521-2, Damascus (Syria), Vol. 2, pp 1041 -1042, April 24-28, 2006. Alti A., Khammaci T., Smeda A., (2007). Towards an Automatic Transformation From COSA Software Architecture To CORBA platform, First International Conference on Digital Communications and Computer Applications (DCCA07), ISBN: 0-7803-9521-2, Just (Jordan), pp 980 989, 19 -21 Mars, 2007. Alti A., Khammaci T., Smeda A., Bennouar D., (2007). Integrating Software Architecture
Concepts into the MDA Platform. The Second International Conference on Software and Data Technologie (ICSOFT07), ISBN: 978-989-8111-05-0, Barcelona (Espagne), INSTICC Press, Vol. 1, pp 30-37, July 19-49, 2007. Alti A., (2008). An Automatic Transformation from COSA Software Architecture to EJB Platform. 3rd IEEE Conference on Information and Communication Technologies: From Theory to Applications (ICTTA08), ISBN: 978-1-4244-1751-3, Damascus (Syria), Vol. 3, pp 1 -6, April 7-11 2008.
190
Alti A., Djoudi M., (2008). Formal Specification and Verification of Software Architecture Behavioral Concepts using UML 2.0 Profile and B. The 10th Maghrebian Conference on Information Technologies (MCSEAI08), Oran (Algeria), pp 1 -6, April 28-30 2008. Alti A., Smeda A., Djoudi M., (2008). An Automatic Transformation from COSA Software Architecture to CORBA Platform. The 8th International Conference on New Technologies in Distributed Systems (NOTERE08), ACM 978-1-59593 937 -1, Lyon (France), Vol. 1, pp 30-37, June 23-27 2008. Alti A., Smeda A.,(2008). Integration of Architectural Design and Implementation Decisions into the MDA Framewrok. The Third International Conference on Software and Data Technologie (ICSOFT08), ISBN: 978-989-8111-52-4, INSTICC Press, Porto (Portugal), pp 366-371, July 5-8 2008. Alti A., Smeda A., (2008). A Meta-ontology for Architecture Description Languages and MDA Platforms. International Conferences on Innovation in Software Engineering (ISE08), IEEE Computer Society, ISBN 978-0-7695-3514-2, Vienna (Austria), pp 118-123, 1012 December 2008. Alti A., Djoudi M., (2009). Patrons des Connecteurs Architecturaux pour le Dveloppement des Architectures base dUML, 1er Confrence Internationale des Technologies de lInformation et de la Communication (CITIC09), Stif (Algrie), pp 58, 4 -5 Mai 2009. Smeda A., Alti A., Boukerram A., (2009). A Software Architecture Modeling Tool. The 8th WSEAS International Conference on TELEcommunications and INFOrmatics (TELEINFO '09), ISSN: 1790 5117, Istanbul (Turkey), pp 68 72, 30 Mai - 1 June 2009. Alti A., Smeda A.,(2009). Architectural Styles Quality Evaluation and Selection. The 4th International Conference on Software and Data Technologie (ICSOFT09), INSTICC Press 2009, ISBN: 978-989-674-009-2, Sofia (Bulgaria), INSTICC Press, pp 74-82, July 2629 2009. Makhlouf D., Roose P., Dalmau M., Ghoualmi-Zine N., Alti A., (2010). Vers une architecture d'adaptation automatique des applications reparties bases composants - Confrence sur les Architectures Logicielles (CAL 2010) , pp. 1-14, RNTI L-5 - ISSN : 174 - 1667 - ISBN : 978-2-85128-930-5, Pau, France, 9 12 March 2010. Alti A., Boukerram A., Makhlouf D., Roose P., (2010). Context-aware Quality Model Driven Approach. The 10th International Conference on New Technologies in Distributed
191
Systems (NOTERE 2010), IEEE CFP1090J -PRT, ACM Tunisia Chapter, ISBN:978-1-42447066-2, Tozeur (Tunisia), pp 197-204, May 31 June 2, 2010. Alti A., Boukerram A., (2010). QualiStyle: A Tool for Automatic Quality Evaluation and
Selection of Architectural Styles. The 10th International Conference on New Technologies in Distributed Systems (NOTERE 2010), IEEE CFP1090J -PRT, ACM Tunisia Chapter, ISBN: 978-1-4244-7066-2, Tozeur (Tunisia), pp 243-249, May 31 June 2, 2010. Makhlouf D., Roose P., Dalmau M., Ghoualmi-Zine N., Alti A., (2010). An adaptation approach for component-based software architecture, The 34th Annual IEEE Computer Software and Application Conference (COMPSAC 2010), ISBN: 0730-315-10, pp. 179-187, Seoul (South Corea), July 19 23 2010. Alti A., Boukerram A., (2010). Semantic Mapping of ADLs into MDA Platforms Using a MetaOntology. The First International Conference on Machine and Web Intelligence (IEEE ICMWI 2010), IEEE CFP1023L6-CDR, ISBN: 978-1-4244-8610-6, Algiers (Algeria), pp 405412, October 3-5, 2010. Alti A., Boukerram A., (2010). CxQWS: ConteXt-aware Quality semantic Web Service. The First International Conference on Machine and Web Intelligence (IEEE ICMWI 2010), IEEE CFP1023L6-CDR, ISBN: 978-1-4244-8610-6, Algiers (Algeria), pp 42-49, October 3-5.
Communications dans des workshops internationaux (avec comit de lecture)

Alti A., Smeda A., (2006). Un profil UML 2.0 pour larchitecture logicielle COSA, 5me atelier sur les Objets, Composants et Modles dans lingnierie des Systmes dInformation, held in conjunction with INFORSID 2006, Hammamet (Tunisie), pp 62-73, 1-3 Juin 2006. Alti A., Smeda A., (2007). Intgration de larchitecture logicielle COSA au sein de MDA : Retour dexpriences, 5me atelier sur les Objets, Composants et Modles dans lingnierie des Systmes dInformation, held in conjunction with INFORSID 2007, Perros-Guirec (France), pp 62-73, 22 Mai 2007.
192
Communications dans des congrs internationaux (avec comit de lecture)

Alti A., Khammaci T., (2005). Transformation des concepts des composants architecturaux en UML 2.0. 1er Congrs International en Informatique applique (CIIA05), ISBN: 9947-01042-2, pp 14 -21, B.B.A (Algrie), 19 -21 novembre 2005. Smeda A., Alti A., Oussalah M., Boukerram A., (2009). COSAStudio: A Software Architecture Modeling Tool, World Congress on Science, Engineering And Technology (WCSET'09), ISSN: 1307 - 6892, No. 49, pp 263-266, 28 -30 Januray 2009.
Glossaire
193
Liste des outils COSA
Profil UML 2.0 pour larchitecture logicielle COSA, COSAPlug-In

Loutil COSAPlug-In crit en java a t implment dans la plate forme de dveloppement logiciel dIBM RSM pour Eclipse. COSAPlug-In permet dinstruire les architectes et les designers aux solutions orientes architecture selon lapproche COSA, et utilis avec succs la cration des modles darchitectures logicielles des systmes complexe. Un Plug-In qui fournit un profil UML 2.0 pour COSA contient un ensemble de strotypes avec toutes ses valeurs marques et contraintes OCL 2.0 ncessaire la validation pratique de la projection COSA vers UML 2.0. COSAPlug-In offre les fonctionnalits suivantes: - Performance de vrification des modles darchitecture UML profil COSA. - Simplicit de cration et rapidit de modification dune architecture logicielle par la cration du modle UML 2.0 (diagramme de composants) et ensuite ajout les contraintes OCL ncessaires au modle. Aprs que, le modle valu par le profil. - Validation smantique et vrification de cohrence structurelle des modles darchitecture UML 2.0 profil COSA contre les violations des contraintes smantique dfinit par le profile. - Capacit aux architectes de construire facilement des modles darchitecture UML 2.0 avec lapproche COSA. - Labilit aux concepteurs de rutilis et partag les mme concepts architecturaux durant tous le cycle de vie du systme.
Transformation de COSA vers CORBA, COSA2CORBAPlug-In

Loutil COSA2CORBAPlug-In crit en java et ATL (Atlas Transformation Language) a t implment dans la plate forme de dveloppement logiciel Eclipse. Un outil de
Glossaire
194
transformation des architectures COSA vers CORBA qui offre une simplicit de transformation des modles darchitectures UML 2.0 profil COSA vers la plate-forme standard CORBA. Plus prcisment, lautomatisation de la production des modles UML des applications CORBA et la gnration des interfaces CORBA, partir des modles COSA UML dans un contexte dingnierie des modles. On applique deux transformations successives : - COSA2CORBA qui permet la transformation de larchitecture COSA modlise avec UML 2.0 vers larchitecture CORBA modlise avec UML 1.4 et CORBA2ID qui automatise la gnration des interfaces portable depuis le modle CORBA UML.
Transformation de COSA vers EJB 2.0, COSA2EJBPlug-In

Un outil crit en java et ATL (Atlas Transformation Language) a t implment dans la plate forme de dveloppement logiciel Eclipse permet une transformation des modles darchitectures UML 2.0 profil COSA vers la plateforme EJB 2.0.
COSABuilder et COSAInstantiator
Loutil COSABuilder vise permettre aux architectes de dcrire graphiquement leurs architectures et de valider automatiquement ses smantiques selon lapproche COSA. Laspect cl de loutil COSAInstantiator est la possibilit de gnrer automatiquement un diteur graphique pour un modle darchitecture COSA et de crer des architectures dapplications correctes.
Glossaire
195
Glossaire
ACME ADL
Langage dchange darchitectures. Architecture Description Language : langage de description darchitecture. Les ADLs permettent de dcrire les architectures logicielles indpendamment de leurs implmentations. Les ADLs dcrit un systme un niveau haut dabstraction en termes des composants et des connecteurs et des liens entre eux. Correspond un ensemble des concepts de description architectural dun systme logiciel. COSA est un exemple des architectures abstraites. Correspond un ensemble des concepts des plates-formes objets et dfinie larchitecture dans le code source. UML est un exemple des architectures concrtes. Le raffinement architectural est le passage dune architecture abstraite vers une architecture plus concrte. Component-Based Software Development : approche de dveloppement de logiciel bas sur lassemblage des composants prfabriqus, permet aux dveloppeurs de faire abstraction des dtails dimplmentation et de faciliter la manipulation et la rutilisation des composants. CORBA Component Model : modle de composants logiciels pour les applications industriels de type 3-tiers dvelopp par lOMG dans le cadre de la norme CORBA. Modle dexigences. Entit modulaire dune application, packag et documente de faon tre rutilisable. Un composant peut avoir une ou plusieurs interfaces offertes/requises. Reprsente un graphe de composants et de connecteurs et dfinit la faon dont ils relis entre eux. Entit architectural qui encapsule les mcanismes dinteractions entre les composants et les rgles qui rgissent ces interactions. Les connecteurs peuvent tre implicites, des ensembles numrs ou dont la smantique est dfinie par lutilisateur. Un connecteur est caractris par des interfaces, des contraintes et des proprits. Component-Object based Software Architecture : approche hybride composant-objet pour la description darchitecture logicielle.
Architecture abstraite Architecture concrte
CBSD
CCM
CIM Composant
Configuration Connecteur
COSA
Glossaire
196 Common Object Request Broker Architecture : est une plate-forme dexcution standard et international qui dcrit des architectures et des spcifications pour le traitement dobjets rpartis, portable. Components Off-The-Shelf : composants sur tagre qui sont des briques lmentaires standard que lon peut acqurir. Ils peuvent tre dvelopps par lentreprise qui les utilise ou avoir t dvelopps par une autre. Entreprise JavaBeans : modle de composants logiciels pour les applications industrielles de type 3-tiers dvelopp par SUN dans le cadre de lenvironnement Java dition entreprise (J2EE). Interface Definition Language : langage de dfinition des interfaces dobjets et de composants logiciels, indpendant des codes spcifique dimplmentation. dfinit des services fournis et requis par un type de composant, qui lui permettent dinteragir avec son environnement, y compris avec dautres types de composants. Dfinition prcise de tous les concepts de modlisation. Mtamodle UML associe chacun de ses concepts des entits syntaxiques. Model Driven Approach: dmarche de dveloppement propose par l'OMG. Elle se base sur la transformation automatique des modles vers des applications compltement dployable et excutable. MDA supporte le dveloppement de systmes informatiques en assurant linteroprabilit et la portabilit et dfinit plusieurs niveaux des modles : CIM, PIM, PSM, code. Plateforme logicielle de Microsoft pour le dveloppement dapplications architectur autour dune machine virtuelle. Object Management Group: consortium oeuvrant pour la standardisation des modles de conception et dimplantation orients objets. Modle dapplication indpendant des plates-formes dexcution. Spcialisation dUML un domaine particuler. Un profil est compos de strotypes, de valeurs marques et de contraintes. Le profil CORBA est un support graphique des composants CORBA en UML. Modle dapplication spcifique une plate-forme dexcution.
CORBA
COTS
EJB
IDL
Interface
Mtamodle MDA
.NET OMG
PIM Profil UML
PSM
Transformation Automatisation des productions des modles. Une transformation entre des modles dexigences (CIM), des modles indpendants des plates-formes (PIM) et des modles spcifiques (PSM). Wright Langage dchange darchitectures ralis luniversit de Carnegie Mellon.
Annexe A : Code ATL de la transformation COSA eCore
197
Annexes
Annexe A : Code ATL de la transformation COSA - eCore

-- =============================================================================== -- transformation rules begin -- =============================================================================== -- This rule generates a eCoreClass from COSAConfiguration rule MainConfiguration { from IN: COSA!Configuration(IN.parent.oclIsUndefined()) to OUTpkg: MOF!EPackage( name <- IN.name, nsURI <- IN.getMetaData(nsURI), nsPrefix <- IN.getMetaData(nsPrefix), ), OUTdetails : MOF!EStringToStringMapEntry ( key <- 'className' value<-'MainConfiguration' ), OUTannotation : MOF!EAnnotation ( source <- 'meta', details<- OUTdetails ), OUTclass : MOF!EClass( name <- IN.name, eAnnotations<- Sequence {OUTannotation,IN.constraints}, eStructuralFeatures <- IN.properties, eClassifiers <- IN.elements ) do { thisModule.Result_ecorelModel <- OUTpkg; OUTpkg.eClassifiers<- OUTclass; } } -- This rule generates a eCoreClass from COSAConnector rule COSAUserConnector2MOFClass { from IN : COSA!UserConnector to OUTclass : MOF!EClass( name <- IN.parent.name+IN.name, eAnnotations<- Sequence {OUTannotation,IN.constraints}, eStructuralFeatures <- IN.properties ) , OUTref : MOF!EReference( name <- IN.name, eType<-IN, lowerBound<-0, upperBound<- -1 , containment<-true ), OUTdetails : MOF!EStringToStringMapEntry ( key <- 'className' value<-'Connector' ), OUTannotation : MOF!EAnnotation ( source <- 'meta',
Annexe A : Code ATL de la transformation COSA eCore

details<- OUTdetails ) do{ Result_ecorelModel.eClassifiers<- OUTclass; if (IN.parent.name =Result_class.name) Result_class.eStructuralFeatures<-OUTref; }
198
} -- This rule generates a eCoreClass from COSABuiltInConnector rule COSABuiltInConnector2MOFClass COSAUserConnector2MOFClass { from IN : COSA!BuiltInConnector to OUTclass : MOF!EClass( name <- IN.source.name+'_to_'+IN.target.name, eAnnotations<-OUTannotation ), OUTref: MOF!EReference( name <- IN.name, eType<-IN, LowerBound<-0, upperBound<- -1, containment<-true ), OUTdetails: MOF!EStringToStringMapEntry ( key <- 'className', value <-if (IN.oclIsKindOf(Binding))then 'Binding' else if (IN.oclIsKindOf(Attachment)) then 'Attachment' else 'Use' endif endif endif ), OUTannotation : MOF!EAnnotation ( source <- 'meta', details<- OUTdetails ) do{ let ch_par : String = '' if (not IN.parent.parent.oclIsUndefined()) ch_par=IN.parent.parent.name+IN.parent.name else ch_par=IN.parent.name; Result_ecorelModel.eClassifiers<-OUTclass; Result_parent.eStructuralFeatures<-OUTref; } } ================================================================================ -- transformation rules end -- ==============================================================================
Annexe B : Code ATL de la transformation COSA CORBA et CORBA IDL
199
Annexe B : Un Extrait du Code ATL des transformations COSA CORBA et CORBA IDL
B.1. La transformation COSA vers CORBA
/*----------------dfinit ici les differentes helpers ---------------------*/
================================================================================== -- model-specific helpers begin -- ===============================================================================
--Global varialbe to store the UML model (root) helper def: Result_UmlModel: UML14!Model = ''; --Global varialbe to store the CORBA UML Module helper def: CORBAModule: UML14!Package = '';
-- This helper returns the applied UML2!Stereotype helper context UML2!NamedElement def:hasStereotype(name:String): Boolean = self.getappliedStereotypes-> select (e| e.name =name)->notEmpty(); -- This helper returns the UML2!Property of UML2!NamedElement helper context UML2!NamedElement def: getCOSAProps():Sequence(UML2!Property) = self.ownedAttribute->select(e|e.hasStereotype('COSANonFuncProp')); -- This helper returns the UML2!Constraint of UML2!NamedElement helper context UML2!NamedElement def: getCOSAConstraints(): Sequence(UML2!Constraint)=self.ownedRule->select(e|e.hasStereotype('COSAConstraint' -- This helper returns the UML2!Dependency of UML2!NamedElement helper context UML2!NamedElement def: getCOSAImplementations(): Sequence(UML2!Dependency) =self.clientDependency->collect(cd|cd.supplier);
-- This helper returns the UML2!Dependency of UML2!Usage helper context UML2!Usage def: SupplierIsCOSAPort_COSARole(): Boolean = if (self.supplier->forAll(s|s.hasStereotype('COSARequired-Port') or s.hasStereotype('COSARequired-Role'))) then true else false endif; -- =============================================================================== -- model-specific helpers end
-- =======================================================================
-- =============================================================================== -- transformation rules begin -- =============================================================================== -- This rule generates a CORBAModule from a COSAConfiguration rule COSAConfiguration2CORBAHome { from inConfig : UML2!Component(inConfig.hasStereotype('COSAConfiguration')) to outHome:UML14!Package ( name <- inConfig.name, namespace<-thisModule.Result_UmlModel, stereotype <-ApplyStereotype ('CORBAModule'),

) do {thisModule.CORBAModule<-inConfig;} } -- This rule generates a CORBAHome from a ComponentCOSA rule COSAComponent2CORBAHome { from inComp: UML2!Component(inComp.hasStereotype('ComponentCOSA')) to outHome:UML14!Class ( name <- inComp.name, namespace<-inComp.owner, feature<-inComp.getCOSAProps(), constraint <-inComp.getCOSAConstraints(), clientDependency <-inComp.clientDependency, stereotype <- ApplyStereotype ('CORBAHome') ) }
200
-- This rule generates a CORBAComponent and CORBAManages from a ComponentInterface rule ComponentInterface2CORBAComponent{ from inItf : UML2!Port(inItf.hasStereotype('ComponentInterface')) to outComp:UML14!Class ( name<-inItf.name, namespace<-thisModule.CORBAModule, stereotype <- ApplyStereotype ('CORBAComponent') ), outManages:UML14!Dependency ( name<-'To_'+inItf.name, namespace<-thisModule.CORBAModule, supplier<-inItf, client<-inItf.owner, stereotype <- ApplyStereotype (CORBAManages) ) } -- This rule generates a CORBAInterface from a COSAPort if Mode = synchronous -CORBAEventPort from a COSAPort if Mode = asynchronous rule COSAPort2CORBAInterface{ from InPort:UML2!Interface (InPort.hasStereotype('COSAPort')) to outIntf:UML14!Interface( name <- InPort.name, namespace<-thisModule.CORBAModule, ) do{ if (InPort.hasStereotype('COSARequired-Port')) if (InPort.getPropertyObj('COSARequiredPort','Mode')=#synchronous) outIntf.stereotype<- ApplyStereotype('CORBAInterface'); else outIntf.stereotype<-ApplyStereotype ('CORBAEventPort'); else if (InPort.getPropertyObj('COSAProvidedPort','Mode')=#synchronous) outIntf.stereotype<- ApplyStereotype('CORBAInterface'); else outIntf.stereotype<-ApplyStereotype ('CORBAEventPort'); thisModule.CORBAModule.ownedMember ->including(outIntf); } } -- This rule generates a CORBAHome from a COSAConnector rule COSAConnector2CORBAHome { from inConn : UML2!Class(inConn.hasStereotype('COSAConnector')) to outHome:UML14!Class ( name <- inConn.name, namespace<-inConn.owner, feature<-inConn.getCOSAProps(), constraint <-inConn.getCOSAConstraints(), clientDependency <-inConn.clientDependency, stereotype <- ApplyStereotype ('CORBAHome') )

} -- This rule generates a CORBAComponent and CORBAManages from a COSAConnector rule ConnectorInterface2CORBAComponent{ from inItf : UML2!Port(inItf.hasStereotype('ConnectorInterface')) to outComp:UML14!Class ( name<-inItf.name, namespace<-thisModule.CORBAModule, stereotype <- ApplyStereotype ('CORBAComponent') ), outManages:UML14!Dependency ( name<-'To_'+inItf.name, namespace<-thisModule.CORBAModule, supplier<-inItf, client<-inItf.owner, stereotype <- ApplyStereotype (CORBAManages) ) }
201
-- This rule generates a Dependency between CORBAComponent and CORBAHome -- CORBAManages if CORBAInterface or CORBAConsumes if CORBAEventPort of Attachment rule COSAAttachment2CORBAComponent{ from InAss:UML2!Association (InAss.hasStereotype('Attachment')) using { connectionr: UML2!Interface=InAss.getAtt('ProvidedPort','ProvidedRole'); connectiond: UML2!Interface=InAss.getAtt('RequiredPort','RequiredRole'); } to outComponent:UML14!Class( name <- InAss.name, namespace<-thisModule.CORBAModule, stereotype <- ApplyStereotype ('CORBAComponent'), ), outHome:UML14!Class ( name<-InAss.name+'Home', namespace<-thisModule.CORBAModule, stereotype <- ApplyStereotype ('CORBAHome'), ), outManages:UML14!Dependency ( name<-'To_'+InAss.name, namespace<-thisModule.CORBAModule, supplier<-outComponent, client<-outHome, stereotype <-ApplyStereotype (CORBAManages) ), outUsesConsumes:UML14!Association ( name<-'To_'+InAss.name, namespace<-thisModule.CORBAModule, stereotype <-if thisModule.Result_UmlModel.hasCORBAInterface() then thisModule.ApplyStereotype(CORBAManages) else thisModule. ApplyStereotype(CORBAConsumes') endif ), outProvidesPublishe:UML14!Association ( name<-'For_'+InAss.name, namespace<-thisModule.CORBAModule, stereotype<- if thisModule.Result_UmlModel.hasCORBAInterface() then thisModule.ApplyStereotype(CORBAProvides') else thisModule.ApplyStereotype('CORBAPublishs') endif ) }

-- Generate IDL-Attribute from COSANonFuncProp rule COSAProperty2CORBAAttribute{ from prop:UML2!Property (prop.hasStereotype('COSANonFuncProp')) to attr:UML14!Attribute( name <- prop.name, type <- prop.getType(), owner<- prop.owner, initialValue <-prop.defaultValue, ownerScope<-#sk_classifier, stereotype <- ApplyStereotype('IDL-Attribute') ) }
202
================================================================================ -- transformation rules end -- ==============================================================================
B.2. La transformation CORBA vers IDL

-- file CORBAToIDL.atl query CORBAtoIDL = -- generation form the first instance of CORBA Module UML!Package.allInstances()->collect(e | if not e.IsCORBAModule() then true else e.generateCORBAModule().writeTo('c:/'+e.name+'.IDL') endif); --/*---------------dfinit ici les differentes helpers --------------------*/ ================================================================================== -- Stereotypes helpers begin -================================================================================= -- This helper returns all UML classes stereotyped CORBAModule helper context UML!ModelElement def: IsCORBAModule() : Boolean = self.oclIsKindOf(UML!Package) and self.stereotype->select (e| e.name ='CORBAModule')->notEmpty(); -- This helper returns all UML classes stereotyped CORBAHome helper context UML!ModelElement def: IsCORBAHome() : Boolean = self.oclIsKindOf(UML!Class) and self.stereotype->select (e| e.name ='CORBAHome')->notEmpty(); -- This helper returns all UML classes stereotyped CORBAComponent helper context UML!ModelElement def: IsCORBAComponent() : Boolean = self.oclIsKindOf(UML!Class) and self.stereotype->select (e| e.name ='CORBAComponent')->notEmpty(); -- This helper returns all UML dependencies stereotyped CORBAManages helper context UML!ModelElement def: IsIDLAttribute() : Boolean = self.oclIsKindOf(UML!Attribute) and self.stereotype->select (e| e.name ='IDL-Attribute')->notEmpty(); -- This helper returns all UML operations stereotyped IDL-Operation helper context UML!ModelElement def: IsIDLOperation() : Boolean = self.oclIsKindOf(UML!Operation) and self.stereotype->select (e| e.name ='IDL-Operation')->notEmpty(); -- This helper returns all UML interfaces stereotyped CORBAInterface helper context UML!ModelElement def: IsCORBAInterface() : Boolean = self.oclIsKindOf(UML!Interface) and self.stereotype->select(e| e.name ='CORBAInterface')->notEmpty(); -- =============================================================================== -- Stereotypes helpers end
203
-------------*/
-- =============================================================================== /*------ dfinit differentes helpers de gnration du code IDL
-- =============================================================================== -- code generation helpers begin -- =============================================================================== -- Code generation of CORBA Module and its CORBA Interfaces helper context UML!Package def: generateCORBAModule():String = '//File: '+self.name+'.idl\n' +'module '+self.name +' {\n' +'// dfintion des interfaces \n' +self.ownedElement->select(intf|intf.IsCORBAInterface()) ->iterate(intf;accMG:String=''|accMG+intf.generateCORBAInterface()+'\n') +self.ownedElement->select(mg|mg.IsCORBAManages()) ->iterate(mg;accMG:String=''|accMG+mg.generateCORBAManages()+'\n')+'};'; -- Code generation of CORBA Interface and its IDL-operations helper context UML!Interface def: generateCORBAInterface() : String = ('interface ' + self.name +' {\n' + self.ownedElement->select (f | f.IsIDLOperation())
->iterate (e; acc: String = '' | acc + e.generateIDLOperation()) +'}; \n').writeTo ('c:/'+self.name+'.IDL')
-- Code generation of CORBA manages helper context UML!Dependency def: generateCORBAManages():String = self.supplier->select(cp|cp.IsCORBAComponent()) ->iterate(cp;accCP:String=''|accCP+cp.generateCORBAComponent()) +' home '+self.client->select(h|h.IsCORBAHome()) ->iterate(h;accH:String=''|accH+h.name.toString()+' ') +'manages '+self.supplier->select(cp|cp.IsCORBAComponent()) ->iterate(cp;accCP:String=''|accCP+cp.name.toString()+' ')+' {\n' +self.client->select(h|h.IsCORBAHome()) ->iterate(h;accH:String=''|accH+h.generateCORBAHome()+' };\n\n'); -- Code generation of CORBA components helper context UML!Class def: generateCORBAComponent():String = '// description du composant '+self.name+'\n'+ ' component '+self.name +' {\n };\n'; -- Code generation of IDL-Attribute helper context UML!Feature def: generateIDLAttribute():String = ' attribute '+self.name.toString() +';\n'; -- Code generation of IDL-Attribute helper context UML!Class def : generateCORBAHome():String = self.feature->select(f|f.IsIDLAttribute()) ->iterate(f;accF:String=''|accF+f.generateIDLAttribute()); -- Code generation of CORBA operations helper context UML!Operation def : generateIDLOperation() : String = ' void '+self.name.toString()+ '()\n'; -- =============================================================================== -- code generation helpers end
-==========================================================================
Annexe C : Evaluation des outils COSA et Etudes de Cas
204

C.1. Evaluation des outils de modlisation et dinstanciation
Dear Developer, This is a questionnaire to get your opinion concerning the evaluation of our COSA Tools compared to ACMEStudio. This questionnaire is part of an academic study for research purposes, and doesnt intended for any commercial purposes. The purpose is to determine to what extend our tools are useful for software architecture. Your opinion is very important in this study, so please try to answer the questions truly. We thank you for your help, and appreciate your cooperation in supporting the scientific research.
No.
Question
Est-ce que loutil une bonne interface graphique? Est-ce que l'outil est utile pour acqurir des comptences professionnelles ? Est-ce que l'outil est utile d'apprendre des choses ? Loutil prend-il de la rutilisation ? Est-ce que loutil facilite la description des architectures logicielles complexes ? Est-ce que loutil dispose d'une bonne interoprabilit ? La priode de temps alloue ne suffit pas pour complter la conception? Est-ce quil est facile de vrifier le modle darchitecture tout moment ? Loutil est il facile utiliser ? Est-ce que loutil est flexible ? Est-ce que on peut appliquer une mthode de vrification formelle lors de la conception ? Est-ce que tous les concepts des architectures sont disponibles dans l'outil ? Le modle d'architecture peut tre instanci tout moment ? Est-ce que loutil m'a donn la chance de travailler sur un projet rel ? Est-ce que l'outil m'a donn une chance de faire quelque chose d'utile pour ma communaut Est-ce que l'outil ma aid dfinir des contraintes sur les lments d'architecture ? Avez-vous d'autres recommandations qui pourraient tre utiles pour amliorer l'outil ?
Oui
Peut tre
Non
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
205
Non 1 1 2 1 1 1 -
Rsum des rponses autour COSABuilder/COSAInstantiator

No. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
17
Oui 9 10 9 9 10 10 7 10 10 9 10 9 10 7 9 10
Peut tre 1 1 1 2 2 -
- Les outils COSABuilder manque de la gnration automatique des parties importantes dimplmentation du systme et manque de maturit. - Linstanciation automatique est le point fort des outils de COSA.
Rsum des rponses autour ACMEStudio

No. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
17
Oui 7 10 7 9 7 6 6 10 9 7 10 8 5 6 7 10
Peut tre 1 1 3 1 2 2 1 3 1 -
Non 2 3 3 1 3 1 1 4 1 2 -
- ACMEStudio manque de la documentation et de la maturit. - Ladaptation et la rutilisation sont les principaux avantages dACMEStudio
C.2. Etudes de cas C.2.1. Etudes de cas 1 : Systme de contrle d'accs au parking
Nous avons essay dans la premire tude de cas de dcrire un systme de contrle d'accs au parking en utilisant les outils COSABuilder/COSAInstantiator. Ce systme contrle la rservation d'un ensemble des places disponibles dans le parking. Un seul utilisateur ayant une identit connus et des droits d'accs corrects seront autoriss entrer dans le parking. Un contrleur contrle l'accs au parking. En plus, un contrleur ayant une console ce qui permet
206
un superviseur d'interagir avec le systme (via le port ExternalAccess). Ce superviseur permet dautres voitures de rserver dans le parking. Le contrleur affiche le nombre de places disponibles via l'cran LED.
user_access car_access Authorizer displays screen Adapter
Access
Parking
LED
Controllor Supervisor
sup_access Reserv Permission
DataBase Console Authentication

Identification
Model architecture A Level
CardReader
Light
Acces
Application hi0 Level A
Autho1
Autho2
Parking
Reserv1 Adaper1
Acces
Superv1
Screen1
Figure C.1. Larchitecture et lapplication du systme de contrle d'accs au Parking.
Figure C.2. Larchitecture du systme SCAP sous COSABuilder.
207
Figure C.3. Lapplication SCAP obenue par le gnrateur des instances COSA eCore.
C.2.2. tude de cas 2: Protocole de scurisation des transactions lectroniques

Secure Electronic Transaction (SET) est un protocole de scurisation des transactions
lectroniques est mis au point par Visa et MasterCard, et s'appuyant sur le standard SSL. Le titulaire de la carte bancaire Visa ou MasterCard (client), utilise son PC pour acheter des articles sous l'Internet. Le protocole assure une transaction lectronique scurise pour l'acheteur. Les coordonnes bancaires des clients sont transmises en toute scurit, les donnes sont cryptes par le protocole de scurit SSL (Scurit Socket Layer). SET est bas sur l'utilisation d'une signature lectronique au niveau de l'acheteur et une transaction mettant en jeu non seulement l'acheteur et le vendeur, mais aussi leurs banques respectives. Un composant Client a besoin de sept ports de communications, trois ports avec le composant Autorisation de certificat (Certificate Authority) et les autres avec le composant Acheteur (Marchant).

CardInitreq RegFrmReq Mar_CertReq CardInitresp RegFrmResp Mar_CertResp
208
Customer Model architecture A Level
Initreq PIreq Custresp Purshreq
Certification Authority Cust_Certresp

CertInitresp InitRes CertRes InqRes
CustCertReq InitRes MarRes Rcvresp PurshRes CertInitreq AuthReq MarReq SendPI Initreq Certreq Inqreq AuthRes MarRes RcvPI
Merchant
CardInitreq RegFrmReq
Payement GateWay
CardInitresp RegFrmResp
:Customer Application A0 Level

InitRes MarRes
Mar_CertReq
Initreq PIreq Custresp Purshreq
:Certification Authority Cust_Certresp

CertInitresp InitRes CertRes InqRes
Mar_CertResp
CustCertReq PurshRes CertInitreq AuthReq MarReq TransmitPI
: Merchant
AuthRes MarRes
:Payement ReceivePI GateWay
Initreq Certreq Inqreq
Figure C.4. Larchitecture et lapplication du systme SET
Figure C.5. La description de larchitecture SET sous COSABuilder.

These Doctorat AltiAdel

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

These Doctorat AltiAdel

Transféré par

Droits d'auteur :

Formats disponibles

Rpublique Algrienne Dmocratique et Populaire

En vue de l'obtention du diplme de

Soutenue le 22 Juin 2011 devant le jury compos de :

: Architecture Logicielle, Langages de Description dArchitecture, COSA, Profil

UML, MDA, Transformation.

Software Architecture, Architecture Description Language, COSA, UML profile,

Table des matires

Table des matires

Table des matires

Table des matires

Table des matires

Table des matires

Liste des figures

Table des matires

Liste des tables

Liste des tables

CHAPITRE 1 Ltat du domaine

Chapitre 1 : Ltat du domaine

CHAPITRE 1 Ltat du domaine

1.2 Approche de modlisation par objet

1.2.1 Les concepts de base de la modlisation par objet

CHAPITRE 1 Ltat du domaine

1.2.2 Les langages de la modlisation par objet

CHAPITRE 1 Ltat du domaine

1.3 Approche de modlisation par composants

CHAPITRE 1 Ltat du domaine

Rle - Fourni Composant Port - Fourni

1.3.1 Les concepts de base de modlisation par composants

CHAPITRE 1 Ltat du domaine

CHAPITRE 1 Ltat du domaine

CHAPITRE 1 Ltat du domaine

CHAPITRE 1 Ltat du domaine

CHAPITRE 1 Ltat du domaine

CHAPITRE 1 Ltat du domaine Mode dexpression

Flot de contrle Flot de donnes Graphique Texte

Mon domaine Domaine connexe Tout domaine

Spcification Architecture Architecture Haut-niveau dtaille

Figure 1.3. Les trois dimensions dun composant.

CHAPITRE 1 Ltat du domaine

CHAPITRE 1 Ltat du domaine

1.3.2 Les langages de modlisation par composants

1.4 Similarit entre la modlisation base dobjets et la modlisation base de composants

CHAPITRE 1 Ltat du domaine

1.4.1 Avantages et inconvnients de la modlisation base dobjets

CHAPITRE 1 Ltat du domaine

CHAPITRE 1 Ltat du domaine

1.4.2 Avantages et inconvnients des modles base de composants

CHAPITRE 1 Ltat du domaine

1.4.3 Similarits et diffrences en terme de concepts de base

1.5 Cxistence des deux modlisations pour la description de larchitecture logicielle

Table 1.1. Les concepts de base des deux approches.

CHAPITRE 1 Ltat du domaine

1.5.1 La modlisation base de composants utilisant la modlisation base dobjets

CHAPITRE 1 Ltat du domaine

CHAPITRE 1 Ltat du domaine

1.5.2 Slection de notations UML pour reprsenter les descriptions darchitectures

CHAPITRE 1 Ltat du domaine

1.5.3 Reprsentation des vues architecturales en UML

CHAPITRE 1 Ltat du domaine

1.5.4 Combinaison de la modlisation base de composants et base dobjets

CHAPITRE 1 Ltat du domaine

CHAPITRE 2 Les langages de modlisation darchitecture

Chapitre 2 : Les langages de modlisation darchitecture : concepts et outils de support

actuellement, sont devenus un standard de facto dans le monde industriel : UML, en