Hadj Kacem Mohammed

TH
`
ESE
En vue de lobtention du
DOCTORAT DE LUNIVERSIT
E DE TOULOUSE ET DE
LUNIVERSIT
E DE SFAX
D elivr e par lUniversit e Toulouse III - Paul Sabatier
et la Facult e des Sciences

Economiques et de Gestion - Sfax
Discipline : Informatique
Pr esent ee et soutenue par
Mohamed HADJ KACEM
Le Jeudi 13 Novembre 2008
Mod elisation des applications distribu ees ` a architecture
dynamique : Conception et Validation
JURY
Rapporteurs
M. Rak BOUAZIZ Professeur ` a la FSEG-Sfax, Tunisie
M. Flavio OQUENDO Professeur ` a lUniversit e de Bretagne-Sud
Examinateur
Me. Michelle SIBILLA Professeur ` a lUniversit e Paul Sabatier, Toulouse III
Directeurs de th` ese
M. Khalil DRIRA Charg e de Recherche au LAAS-CNRS
M. Mohamed JMAIEL Professeur ` a lENIS, Sfax, Tunisie
Invit e
M. Ahmed HADJ KACEM Professeur ` a la FSEG-Sfax, Tunisie
Laboratoire dArchitecture et dAnalyse des
Syst` emes
**
LAAS-CNRS
Unit e de Recherche en d eveloppement et contr ole
dapplications distribu ees
***
ReDCAD
R esum e
Nos travaux de recherche consistent ` a apporter des solutions de mod elisation
conform ement ` a lapproche MDA. Nos recherches consistent ` a fournir des solutions per-
mettant de guider et dassister les activit es de mod elisation des architectures logicielles. Il
sagit principalement de proposer une d emarche de conception orient ee mod` ele permettant
de d ecrire larchitecture logicielle en tenant compte de trois aspects : le style architectural,
les op erations de reconguration et le protocole de reconguration.
Nous proposons des notations visuelles permettant de d ecrire de facon compatible avec
UML 2.0 larchitecture logicielle. La technique de description que nous adoptons est
orient ee r` egles, bas ee sur les th eories de transformation de graphe, permettant, ainsi, de
d ecrire la dynamique structurelle.
Nous proposons une extension dUML 2.0 par un nouveau prol form e de trois
m eta-mod` eles. Nous proposons aussi une approche de validation bas ee sur des r` egles
intra-mod` ele et des r` egles inter-mod` eles. Nous adoptons egalement une approche de
v erication. Cette approche permet, dans une premi` ere etape, une transformation auto-
matique du style architectural et de chaque op eration de reconguration vers le langage Z.
Elle permet dans une deuxi` eme etape, de v erier la consistance du style architectural et
la conformit e de l evolution dune architecture vis-` a-vis de son style architectural. Nous
utilisons le syst` eme de preuve Z/EVES. Finalement, nous proposons une d emarche de
mod elisation des architectures logicielles dynamiques, appel ee X, permettant de d ecrire
les diff erentes etapes pour mod eliser larchitecture logicielle. La d emarche propos ee est
inspir ee de la m ethode MDA et 2TUP.
Le prol et la d emarche X que nous avons propos es ont fait lobjet dune
impl ementation et dune int egration, sous forme de plug-in java, dans latelier
daide ` a la conception FUJABA. Le plug-in impl ement e est disponible sur lURL :
http ://www.laas.fr/khalil/TOOLS/X.zip.
Mots-cl es : Adaptabilit e architecturale, Architecture Dynamique, Prol UML, Validation,
V erication formelle, D emarche de mod elisation
Abstract
Title : Modeling of distributed applications in dynamic architecture : Design and Valida-
tion
Abstract : The Adaptability of networked service-oriented systems is necessary to guaran-
tee the continuity of services under changing infrastructure constraints and evolving user
requirements. The architectural and the behavioural dynamic recongurations constitute
the two acting categories allowing adaptability of such software systems to be managed.
We propose to support the architectural reconguration-based adaptation and we propose a
UML-based approach for describing, validating and checking dynamic software architec-
tures. We elaborate a new UML prole associated with three meta-models that we dene
in order to describe (i) different architectural styles, (ii) their dynamic instances together
with the associated reconguration operations, and (iii) their reconguration protocol. Our
approach supports describing the architectural constraints that should be preserved during
architecture evolving. The proposed approach supports automatic validation through a set
of rules we dene and implement for ensuring the correctness of the models w.r.t. the meta-
models. These models are automatically transformed into Z specications. This allows
designers to prove, by elaborating Z theorems, the consistency of the dened architectural
styles and the conformity of the associated instances and their transformation rules. We
dene a Design Process, called X, allowing guiding and assisting the architects to model
the dynamic software architectures. The X Design Process is partially based on the MDA
approach and 2TUP Process. Our design process is based on PIM and PSM parts. The
proposed design process uses an iterative and incremental development approach and it is
architecture-centric.
A software environment supporting the different features of this approach has been deve-
loped and integrated as a plug-in in the open-source FUJABA tool. The plug-in is available
at URL : http ://www.laas.fr/khalil/TOOLS/X.zip.
Keywords : Architectural adaptation, Dynamic architecture, UML Prole, Validation,
Formal verication, Design process
A mes parents pour leur patience et leur amour.
A mon epouse Imen.
A toute ma famille.
A vous tous !
Remerciements
Mes remerciements vont avant tout aux membres de jury qui ont accept e d evaluer ce
travail de th` ese.
Je remercie vivement et particuli` erement : M. Rak BOUAZIZ, professeur ` a la FSEG
Sfax-Tunisie et M. Flavio OQUENDO, professeur ` a lUniversit e de Bretagne Sud-France,
qui ont accept e de juger ce travail et den etre les rapporteurs.
Je remercie egalement Me. Brigitte PRADIN-CHEZALVIEL, professeur ` a lUniversit e
Paul Sabatier de Toulouse-France et Me. Michelle SIBILLA, professeur ` a lUniversit e
Paul Sabatier de Toulouse-France pour lhonneur quelles mont fait de participer ` a
ce jury de th` ese en tant quexaminateurs. Je remercie particuli` erement Me. Brigitte
PRADIN-CHEZALVIEL pour lhonneur quelle ma fait en pr esidant mon jury de th` ese.
Je tiens ` a exprimer ma profonde reconnaissance ` a M. Khalil DRIRA, directeur de ma
th` ese cot e Toulouse-France, charg e de recherche au LAAS-CNRS pour ses qualit es
tant scientiques quhumaines. La rigueur scientique, la tr` es grande comp etence, ses
encouragements et sa gentillesse, ont et e d eterminants pour les r esultats obtenus.
De m eme, je remercie M. Mohamed JMAIEL, directeur de ma th` ese cot e Sfax-Tunisie,
professeur ` a l
Ecole Nationale dIng enieurs de Sfax et directeur de lunit e de recherche

en D eveloppement et Contr ole des Applications Distribu ees (ReDCAD) pour la conance
quil ma t emoign ee tout au long de ce travail. Ce travail a grandement prot e de son
encadrement, de ses pr ecieux conseils et de ses qualit es humaines.
Je suis tr` es reconnaissant ` a M. Ahmed HADJ KACEM, professeur ` a la Facult e des
Sciences

Economiques et de Gestion de Sfax-Tunisie pour sa contribution dans le co-
encadrement de ce travail. Ses conseils dordre m ethodologique, technique et r edactionnel
ont grandement contribu e ` a la qualit e de ce m emoire. Je le remercie egalement pour
lhonneur quil ma fait en participant au jury.
Je tiens ` a remercier les etudiants de mast` ere qui, au cours de leurs projets, se sont
int eress es ` a ma probl ematique de th` ese et mont apport e du sang neuf et des id ees
nouvelles. Je cite notamment Achraf BOUKHRIS et Mohamed Nadhmi MILADI.
Mes remerciements vont egalement vers les membres de lunit e de recherche LARIS,
Sfax-Tunisie, dont jai fait partie ainsi que les membres de lunit e de recherche ReDCAD,
Sfax-Tunisie, dont je suis actuellement membre.
Je remercie egalement les membres du groupe OLC du LAAS-CNRS, Toulouse-France,
dont je suis egalement membre, pour laccueil chaleureux, pour les discussions scienti-
ques et lamiti e cultiv ee au sein de ce groupe.
Je remercie, mes coll` egues ` a lInstitut Sup erieur dInformatique et de Math ematiques
ISIM Monastir-Tunisie, mes coll` eges ` a lInstitut Sup erieur dInformatique et de Multi-
media ISIM Sfax-Tunisie et mes coll` egues ` a la Facult e des Sciences

Economiques et de
Gestion FSEG Sfax-Tunisie pour les encouragements et laide qui mont permis de nir
cette th` ese et surtout ceux qui mont fait proter de leur grande exp erience et avec qui jai
eu de nombreuses discussions enrichissantes.
Mes plus vifs remerciements sadressent, plus particuli` erement, ` a Walid HADJ KACEM,
Riadh BEN HALIMA, Slim KALLEL et Imen LOULOU pour les discussions enrichis-
santes que nous avons eues et les informations que nous avons echang ees.
Un immense Merci ` a mes parents pour leur soutien sans faille, ` a toute ma famille, ` a tous
mes amis proches ou eloign es, pour leurs encouragements et leurs marques daffection.
Bien que je ne les liste pas ici, je suis certain que chacun sy reconnatra.
Table des mati` eres
Introduction G en erale 1
1 Architectures logicielles 5
1.1 MDA : Model Driven Architecture . . . . . . . . . . . . . . . . . . . . . 5
1.1.1 Architecture ` a quatre niveaux . . . . . . . . . . . . . . . . . . . 6
1.1.2 MOF : Meta Object Facility . . . . . . . . . . . . . . . . . . . . 7
1.1.3 UML : Unied Modeling Language . . . . . . . . . . . . . . . . 8
1.1.4 Prol UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.1.5 OCL : Object Constraint Language . . . . . . . . . . . . . . . . 10
1.1.6 XMI : Xml Metadata Interchange . . . . . . . . . . . . . . . . . 10
1.2 Architecture logicielle . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.2.1 Composant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.2.2 Connecteur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.2.3 Port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.2.4 Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.2.5 Conguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.3 Style architectural . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.3.1 Style client-serveur . . . . . . . . . . . . . . . . . . . . . . . . 14
1.3.2 Style publier-souscrire . . . . . . . . . . . . . . . . . . . . . . 15
1.3.3 Style pipes and lters . . . . . . . . . . . . . . . . . . . . . . 15
1.3.4 Avantages des styles architecturaux . . . . . . . . . . . . . . . . 16
1.4 Architecture dynamique . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.4.1 D enition et motivation de la dynamique des architectures . . . . 16
1.4.2 Raison derri` ere la dynamique des architectures . . . . . . . . . . 17
1.4.3 Types darchitectures dynamiques . . . . . . . . . . . . . . . . . 17
1.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2 Description des architectures logicielles :

Etat de lart 21
2.1 Langages de description darchitecture (ADL) . . . . . . . . . . . . . . . 22
2.1.1 Darwin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.1.1.1 Aspect dynamique et comportemental . . . . . . . . . 23
2.1.1.2 Style architectural . . . . . . . . . . . . . . . . . . . . 25
2.1.2 Rapide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.1.3 Wright . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.1.4 -Space . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.1.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.2 Langage UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.2.1 UML et larchitecture logicielle . . . . . . . . . . . . . . . . . . 32
2.2.2 UML en tant que langage pour la description des architectures . . 33
2.2.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.3 Techniques formelles . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.3.1 Techniques bas ees sur les graphes . . . . . . . . . . . . . . . . . 36
2.3.2 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
2.4 Multi-Formalismes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
2.4.1 Z et la transformation de graphe . . . . . . . . . . . . . . . . . . 38
2.4.2 UML et les techniques formelles . . . . . . . . . . . . . . . . . . 38
2.4.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
2.5 Synth` ese . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
2.6 Pr esentation des m ethodes agiles . . . . . . . . . . . . . . . . . . . . . . 40
2.6.1 UP - Unied Process . . . . . . . . . . . . . . . . . . . . . . . . 41
2.6.2 RUP - Rational Unied Process . . . . . . . . . . . . . . . . . . 41
2.6.3 2TUP - 2 Tracks Unied Process . . . . . . . . . . . . . . . . . . 42
2.6.4 MDA : Model Driven Architecture . . . . . . . . . . . . . . . . . 43
2.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3 Prol UML pour d ecrire la dynamique des architectures logicielles 45
3.1 Style architectural . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.1.1 M eta-mod` ele . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.1.2 Mod` ele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.2 Op eration de reconguration . . . . . . . . . . . . . . . . . . . . . . . . 49
3.2.1 M eta-mod` ele . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.2.2 Mod` ele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.3 Protocole de reconguration . . . . . . . . . . . . . . . . . . . . . . . . 51
3.3.1 M eta-mod` ele . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.3.2 Mod` ele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.4 Illustration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
3.4.1 Mod elisation du style architectural . . . . . . . . . . . . . . . . . 54
3.4.2 Mod elisation des op erations de reconguration . . . . . . . . . . 55
3.4.2.1 Insertion dun service d ev enement . . . . . . . . . . . 55
3.4.2.2 Insertion dun patient . . . . . . . . . . . . . . . . . . 56
3.4.2.3 Insertion dune inrmi` ere . . . . . . . . . . . . . . . . 57
3.4.2.4 Transfert dun patient . . . . . . . . . . . . . . . . . . 58
3.4.2.5 Transfert dune inrmi` ere . . . . . . . . . . . . . . . . 59
3.4.3 Mod elisation du protocole de reconguration . . . . . . . . . . . 60
3.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4 Approche de Validation 63
4.1 Intra-Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.1.1 R` egles pour le style architectural . . . . . . . . . . . . . . . . . . 64
4.1.2 R` egles pour lop eration de reconguration . . . . . . . . . . . . . 67
4.1.3 R` egles pour le protocole de reconguration . . . . . . . . . . . . 69
4.1.4 Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
4.2 Inter-Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
4.2.1 Style architectural vers operation de reconguration . . . . . . . 72
4.2.2 Operation de reconguration vers protocole de reconguration . . 73
4.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
5 Approche de V erication 75
5.1 Transformation vers Z . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
5.1.1 Transformation de la partie graphique vers Z . . . . . . . . . . . 77
5.1.1.2 Op eration de reconguration . . . . . . . . . . . . . . 80
5.1.2 Transformation des contraintes OCL vers Z . . . . . . . . . . . . 86
5.1.2.1 Grammaire OCL
. . . . . . . . . . . . . . . . . . . . 87
5.1.2.2 Grammaire Z
. . . . . . . . . . . . . . . . . . . . . . 88
5.1.2.3 Grammaire de la passerelle . . . . . . . . . . . . . . . 88
5.1.2.4 Exemple de transformation . . . . . . . . . . . . . . . 89
5.2 V erication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
5.2.1 Consistance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
5.2.2 Pr eservation du style architectural . . . . . . . . . . . . . . . . . 94
5.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
6 D emarche de mod elisation 99
6.1 Description de la d emarche X . . . . . . . . . . . . . . . . . . . . . . . 100
6.1.1 Branche style architectural . . . . . . . . . . . . . . . . . . . . . 100
6.1.2 Branche op eration de reconguration . . . . . . . . . . . . . . . 101
6.1.3 Branche protocole de reconguration . . . . . . . . . . . . . . . 102
6.1.4 Branche fonctionnelle . . . . . . . . . . . . . . . . . . . . . . . 103
6.2 Caract eristiques de la d emarche X . . . . . . . . . . . . . . . . . . . . . 104
6.2.1 X produit des mod` eles r eutilisables . . . . . . . . . . . . . . . . 104
6.2.2 D emarche it erative . . . . . . . . . . . . . . . . . . . . . . . . . 105
6.2.3 D emarche incr ementale . . . . . . . . . . . . . . . . . . . . . . 106
6.2.4 D emarche de mod elisation ` a base dUML . . . . . . . . . . . . . 107
6.2.5 D emarche centr ee sur larchitecture . . . . . . . . . . . . . . . . 107
6.2.6 D emarche orient ee vers les composants . . . . . . . . . . . . . . 107
6.3 Environnement de mod elisation . . . . . . . . . . . . . . . . . . . . . . 108
6.3.1 Mod elisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
6.3.2 Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
6.3.3 Transformation vers Z . . . . . . . . . . . . . . . . . . . . . . . 113
6.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Conclusion 119
Bilan des contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
Publications de lauteur 123
Bibliographie 125
A Annexe : Les XML sch emas 137
A.1 XML sch ema : style architectural . . . . . . . . . . . . . . . . . . . . . . 138
A.2 XML sch ema : op eration de reconguration . . . . . . . . . . . . . . . . 141
A.3 XML sch ema : protocole de reconguration . . . . . . . . . . . . . . . . 144
B Annexe : Les R` egles de transformation 147
Table des gures
1.1 Architecture ` a quatre niveaux . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2 Les el ements dune architecture logicielle . . . . . . . . . . . . . . . . . 11
1.3 Mod elisation graphique dun composant . . . . . . . . . . . . . . . . . . 13
1.4 Le style client-serveur . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.5 Le style publier-souscrire . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.6 Le style pipes and lters . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.7 Exemple de changement dimpl ementation . . . . . . . . . . . . . . . . . 18
1.8 Exemple de changement dinterface . . . . . . . . . . . . . . . . . . . . 18
1.9 Exemple de changement g eom etrique . . . . . . . . . . . . . . . . . . . 19
1.10 Exemple de changement de structure . . . . . . . . . . . . . . . . . . . . 19
2.1 Formalismes de description darchitectures logicielles . . . . . . . . . . . 21
2.2 Les langages de description darchitecture . . . . . . . . . . . . . . . . . 22
2.3 Les concepts des ADLs . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.4 Exemple de l edition coop erative des documents . . . . . . . . . . . . . . 23
2.5 Exemple dinstanciation paresseuse selon Darwin . . . . . . . . . . . . . 24
2.6 Exemple dinstanciation dynamique selon Darwin . . . . . . . . . . . . . 24
2.7 Liaison conditionnelle entre un ecrivain et un fragment . . . . . . . . . . 25
2.8 Conguration selon Wright . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.9 Sp ecication dynamique selon Wright : tol erance au fautes . . . . . . . . 28
2.10 Sp ecication dynamique selon -Space . . . . . . . . . . . . . . . . . . 29
2.11 Changement de la topologie selon -Space . . . . . . . . . . . . . . . . . 30
2.12 Diagrammes de structure . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.13 Diagrammes de comportement . . . . . . . . . . . . . . . . . . . . . . . 32
2.14 Types de connecteur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.15 Le langage UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.16 Les techniques formelles . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.17 Les Multi-Formalismes . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
2.18 La notation mixte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
2.19 M ethodes agiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
2.20 Le processus 2TUP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.1 Le prol de larchitecture dynamique . . . . . . . . . . . . . . . . . . . . 46
3.2 Le m eta-mod` ele du style architectural . . . . . . . . . . . . . . . . . . . 47
3.3 Le mod` ele du style architectural . . . . . . . . . . . . . . . . . . . . . . 48
3.4 Le m eta-mod` ele des op erations de reconguration . . . . . . . . . . . . . 49
3.5 Le mod` ele dune op eration de reconguration . . . . . . . . . . . . . . . 50
3.6 La correspondance entre la notation et la notation propos ee . . . . . . 51
3.7 Le m eta-mod` ele de protocole de reconguration . . . . . . . . . . . . . . 52
3.8 Le mod` ele de protocole de reconguration . . . . . . . . . . . . . . . . . 53
3.9 Le style architectural du PMS . . . . . . . . . . . . . . . . . . . . . . . . 54
3.10 Une conguration possible du syst` eme PMS . . . . . . . . . . . . . . . . 55
3.11 Insertion dun EventService . . . . . . . . . . . . . . . . . . . . . . . . . 56
3.12 Une conguration possible apr` es linsertion dun EventService . . . . . . 56
3.13 Insertion dun Patient . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
3.14 Une conguration possible apr` es linsertion dun Patient . . . . . . . . . 57
3.15 Insertion dune Inrmi` ere . . . . . . . . . . . . . . . . . . . . . . . . . . 58
3.16 Une conguration possible apr` es linsertion dune Inrmi` ere . . . . . . . 58
3.17 Transfert dun Patient . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
3.18 Transfert dune Inrmi` ere . . . . . . . . . . . . . . . . . . . . . . . . . . 59
3.19 Le protocole de reconguration du syst` eme PMS . . . . . . . . . . . . . 60
4.1 Approche de validation . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.2 Validation de la description XML (a) par rapport ` a son XML Sch ema (b) . 72
5.1 Approche de transformation et de v erication . . . . . . . . . . . . . . . 76
5.2 Transformation du style architectural vers la notation Z . . . . . . . . . . 78
5.3 Transformation du style architectural vers un sch ema Z . . . . . . . . . . 80
5.4 Transformation dune op eration de reconguration vers un sch ema
dop eration Z . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
5.5 Transformation de lop eration Insert Patient vers un sch ema dop eration Z 86
5.6 Grammaire OCL
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
5.7 Grammaire Z
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
5.8 Grammaire de la passerelle . . . . . . . . . . . . . . . . . . . . . . . . . 89
5.9 D ecomposition de lexpression OCL . . . . . . . . . . . . . . . . . . . . 90
5.10 Transformation de lexpression OCL vers Z . . . . . . . . . . . . . . . . 90
5.11 Transformation du style architectural de lexemple PMS vers la notation Z 91
5.12 Transformation de lop eration Insert Patient vers la notation Z . . . . . . 92
5.13 Sch ema dinitialisation . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
5.14 Une conguration possible du syst` eme PMS . . . . . . . . . . . . . . . . 94
5.15 Template de sch ema dop eration Z . . . . . . . . . . . . . . . . . . . . . 95
6.1 La d emarche propos ee . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
6.2 La branche style architectural . . . . . . . . . . . . . . . . . . . . . . . . 101
6.3 La branche op eration de reconguration . . . . . . . . . . . . . . . . . . 102
6.4 La branche protocole de reconguration . . . . . . . . . . . . . . . . . . 103
6.5 La branche fonctionnelle . . . . . . . . . . . . . . . . . . . . . . . . . . 103
6.6 Transformation dun mod` ele PIM vers diff erentes plateformes . . . . . . 104
6.7 Diff erentes op erations de transformation sur les mod` eles MDA . . . . . . 104
6.8 R eutilisation du mod` ele PIM . . . . . . . . . . . . . . . . . . . . . . . . 105
6.9 Un exemple dincr ementation . . . . . . . . . . . . . . . . . . . . . . . . 106
6.10 Extension de loutil FUJABA . . . . . . . . . . . . . . . . . . . . . . . . 108
6.11 Interface pour la mod elisation du style architectural . . . . . . . . . . . . 109
6.12 Interface pour la mod elisation des op erations de reconguration . . . . . 109
6.13 Interface pour la mod elisation du protocole de reconguration . . . . . . 109
6.14 Transformation des mod` eles UML vers des descriptions XML . . . . . . 110
6.15 Validation des mod` eles XML par rapport ` a leur XML sch ema . . . . . . . 112
6.16 Linterface UML to Z . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
6.17 Transformation du style architectural vers le langage Z . . . . . . . . . . 116
6.18 V erication et preuve avec Z/EVES . . . . . . . . . . . . . . . . . . . . 116
A.1 Le diagramme XSD du style architectural . . . . . . . . . . . . . . . . . 138
A.2 Le diagramme XSD des op erations de reconguration . . . . . . . . . . . 141
A.3 Le diagramme XSD du protocole de reconguration . . . . . . . . . . . . 144
Liste des tableaux
2.1 Comparaison entre les diff erentes techniques de description des architec-
tures logicielles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.1 Tableau de correspondance entre la notation et la notation propos ee . . 51
Introduction G en erale
Les applications emergentes r ecentes sont de plus en plus distribu ees, ouvertes et ` a ar-
chitecture complexe. De telles applications sont compos ees dun nombre, g en eralement
important, dentit es logicielles dispers ees sur le r eseau coop erant pour fournir ` a leurs uti-
lisateurs les services quils requi` erent. Cette complexit e est li ee, par exemple, ` a lextension
des r eseaux de communication, ` a lh et erog en eit e mat erielle et logicielle, au fort degr e din-
teraction et aux exigences d evolutions n ecessaires et permanentes. Le but etant doffrir
des services de plus en plus performants, robustes et s urs, et qui sadaptent aux diff erents
besoins des clients. Ladaptation ou la reconguration logicielle constitue lun des enjeux
et d es techniques les plus importants. En effet, ladaptabilit e dune application est deve-
nue imp erative dans un contexte de syst` emes fortement distribu es et contenant un grand
nombre de composants. Dans ce cas, une reconguration ad-hoc nest pas envisageable.
Ladaptabilit e dans les applications logicielles peut etre class ee en deux cat egories. La
premi` ere concerne ladaptation comportementale. Elle traite la modication du compor-
tement de lapplication et de ses composants et impliquerait, par exemple, la red enition
dune m ethode dans linterface dun composant. La deuxi` eme cat egorie, dans laquelle
nous pouvons classer nos travaux, concerne ladaptation structurelle et implique une re-
conguration au niveau architectural. Ce type de reconguration porte sur lorganisation
de larchitecture et consiste, par exemple, ` a remplacer un composant d efaillant par un autre
composant qui poss` ede les m emes fonctionnalit es ou rediriger un lien (une connexion)
dun composant d efaillant vers un composant susceptible doffrir de meilleures fonction-
nalit es.
An de faire face ` a cette complexit e, lOMG (Object Management Group) a propos e
lapproche dirig ee par les mod` eles (MDA : Model Driven Architecture). Dans cette ap-
proche, les mod` eles constituent la couche n ecessaire pour fournir le niveau dabstraction
demand e. Lapproche MDA pr econise lutilisation dUML (Unied Modeling Language)
pour l elaboration des mod` eles. En effet, UML, et gr ace ` a sa version 2.0, est devenu
un standard pour la conception et la mod elisation des architectures des applications dis-
tribu ees ` a base de composants.
Cependant, m eme avec cette intention d etre g en eral, UML ne peut pas couvrir tous les
contextes et offre ainsi un m ecanisme dextensibilit e bas e sur les prols. Un prol UML
permet la personnalisation et lajustement dUML pour prendre en charge des domaines
sp eciques qui ne peuvent pas etre repr esent es avec UML dans son etat original.
2 Introduction g en erale
Nos travaux de recherche entrent dans ce contexte et traitent les applications distribu ees ` a
base de composants. Dans nos travaux de th` ese, nous nous concentrons sur la mod elisation
de la dynamique de larchitecture logicielle au niveau conceptuel (design time). Nous trai-
tons essentiellement le probl` eme de l evolution des exigences repr esentant un changement
dans lactivit e soutenue par le syst` eme mod elis e. Nous associons des op erations de recon-
guration architecturales ` a ces situations pour adapter le syst` eme ` a ces changements. Nos
travaux consistent ` a apporter des solutions de mod elisation conformes ` a lapproche MDA.
Ainsi, nous proposons des solutions de mod elisation permettant de guider et dassister les
activit es de conception des applications distribu ees ` a architecture dynamique. Nous pro-
posons une d emarche de conception orient ee-mod` ele permettant de mod eliser, de valider,
de v erier et dimpl ementer une architecture logicielle dynamique.
Le prol UML, que nous d enissons dans ce manuscrit, couvre plusieurs maillons de la
chane de description architecturale. Il offre trois m eta-mod` eles permettant de d ecrire le
style architectural, les op erations de reconguration et le protocole de reconguration. Le
premier m eta-mod` ele d ecrit le style architectural. Il d ecrit les types de composants consti-
tuants larchitecture, les connexions qui les associent ainsi que les contraintes et les pro-
pri et es architecturales. Le deuxi` eme est bas e sur des techniques orient ees-r` egles pour la
reconguration architecturale dynamique. Ainsi chaque etape el ementaire de l evolution
de larchitecture est d ecrite par une combinaison dop erations de reconguration permet-
tant sa transformation dun etat vers un autre. Chacune de ces op erations sp ecie les
actions de transformation el ementaires relatives, par exemple, aux composants logiciels
quil faut introduire ou supprimer, ou aux connexions (entre composants) ` a introduire ou
` a supprimer. Le troisi` eme d ecrit le protocole de reconguration. Il sp ecie lorganisation
et lenchanement entre les diff erentes op erations de reconguration d ecrites au niveau
dynamique.
La mod elisation de larchitecture logicielle g en` ere des mod` eles en se basant sur le prol
UML propos e. Ces mod` eles doivent etre valides par rapport ` a leur m eta-mod` ele. Lap-
proche de validation que nous proposons est bas ee sur des r` egles intra-mod` ele et des
r` egles inter-mod` eles. Les r` egles intra-mod` ele permettent de contr oler la coh erence dun
mod` ele par rapport ` a son m eta-mod` ele et les r` egles inter-mod` eles permettent de contr oler
le passage dun mod` ele ` a un autre. Cette validation assure la validit e des mod` eles et leur
conformit e par rapport ` a leur m eta-mod` ele.
An dattribuer une s emantique formelle, nous proposons egalement une approche de
v erication. Cette approche offre, dans une premi` ere etape, une transformation automa-
tique du style architectural et de chaque op eration de reconguration vers le langage
Z. Elle adopte, dans une deuxi` eme etape, un processus de v erication. Ce processus
d evelopp e au sein de notre unit e de recherche ReDCAD, permet de v erier la consistance
du style architectural et la conformit e de l evolution dune architecture vis-` a-vis de son
style architectural. Nous utilisons le syst` eme de preuve Z/EVES. Finalement, nous propo-
sons une d emarche intitul ee X, inspir ee de lapproche MDA et 2TUP (2 Tracks Unied
Process) du processus UP (Unied Process), permettant de guider et dassister, etape par
etape, les architectes an de mod eliser larchitecture dune application dynamique tout en
suivant le prol propos e.
Introduction g en erale 3
Dans des travaux ant erieurs, nous avons prouv e notre approche par diff erents cas d etude.
Nous lavons appliqu ee ` a des applications coop eratives telles que l edition coop erative et
la revue coop erative. Nous lavons aussi appliqu ee ` a un cas d etude relatif aux op erations
dintervention durgence. Dans ce manuscrit, nous traitons de mani` ere d etaill ee un cas
d etude relatif ` a la gestion des patients dans une clinique (Patient Monitoring System).
Le prol que nous avons propos e, lapproche de validation et de v erication ainsi que
la d emarche X propos ees ont fait lobjet dune impl ementation et dune int egration,
sous forme de plug-in java, dans latelier daide ` a la conception FUJABA. Le plug-in
impl ement e est disponible sur lURL : www.laas.fr/khalil/TOOLS/X.zip
Ce rapport est organis e comme suit :
Le chapitre 1 pr esente une etude sur les architectures logicielles. Il introduit lapproche
MDA et ses diff erentes recommandations. Une section est r eserv ee ` a lintroduction et ` a
l etude de quelques styles architecturaux. Une derni` ere section est consacr ee ` a l etude des
architectures dynamiques et ses diff erents types.
Le chapitre 2 pr esente une etude de synth` ese sur les techniques de description des archi-
tectures logicielles. Une etude sur les langages de description des architectures (ADLs :
Architecture Description Language) est pr esent ee. Une section particuli` ere est consacr ee
` a UML en tant que langage de description des architectures. Les techniques formelles
sont aussi etudi es pour voir leur possibilit e de d ecrire larchitecture logicielle et plus
particuli` erement la dynamique architecturale. Une derni` ere section est consacr ee ` a la
pr esentation des m ethodes agiles.
Le chapitre 3 propose un prol UML pour d ecrire la dynamique des architectures logi-
cielles. Le prol est form e par trois m eta-mod` eles. Le premier etend le diagramme de
composants et permet de d ecrire les el ements de base de larchitecture et les connexions
qui les associent (m eta-mod` ele style architectural). Le deuxi` eme etend le premier et per-
met de d ecrire les op erations de reconguration de larchitecture en termes dajout et/ou
de suppression de composants et/ou de connexions (m eta-mod` ele op eration de recongu-
ration). Les op erations de reconguration permettant de d ecrire la dynamique de larchi-
tecture sont d enies en se basant sur la technique de r e ecriture de graphes. Le troisi` eme
etend le diagramme dactivit e et permet de d ecrire le protocole de reconguration entre
les diff erentes op erations de reconguration (m eta-mod` ele protocole de reconguration).
Le chapitre 4 propose une approche de validation. Cette validation offre deux sc enarios.
Le premier, appel e intra-validation, est bas e sur des r` egles de validation intra-mod` ele per-
mettant de v erier la coh erence et la conformit e entre le mod` ele et son m eta-mod` ele.
Ces r` egles sont utilis ees pour faciliter lidentication des eventuelles incoh erences et pour
d etecter et corriger des erreurs de sp ecication. Le second, appel e inter-validation, est
bas e sur des r` egles de validation inter-mod` eles permettant dassister et de guider le pas-
sage dun mod` ele ` a un autre. Ces r` egles permettent de r eduire les erreurs et dassurer la
coh erence entre les mod` eles. La validation que nous proposons est bas ee sur la technologie
XML (Extensible Markup Language).
Le chapitre 5 est compos e de deux parties. Nous proposons, dans la premi` ere, une
4 Introduction g en erale
approche assurant une transformation automatique du style architectural et de chaque
op eration de reconguration vers le langage Z. Dans la deuxi` eme partie, nous adoptons
une approche de v erication. Cette approche est d evelopp ee, dans notre unit e de re-
cherche ReDCAD, dans le cadre des travaux de la th` ese de Me. Imen LOULOU [84]. Nous
v erions la consistance du style architectural et la conformit e de l evolution dune archi-
tecture vis-` a-vis de son style architectural. Nous utilisons le syst` eme de preuve Z/EVES.
Le chapitre 6 d ecrit une d emarche X, inspir ee de lapproche MDA et 2TUP du processus
UP. La d emarche que nous proposons guide et assiste, etape par etape, les architectes an
de mod eliser larchitecture dune application dynamique tout en suivant le prol propos e.
La d emarche que nous proposons est it erative, centr ee sur larchitecture et incr ementale.
Ce manuscrit se termine par un ensemble de conclusions g en erales et de perspectives des
travaux en cours et ` a venir.
1
Architectures logicielles
Dans le monde des sciences exactes, les d enitions sont dot ees dune pr ecision
irr eprochable. Par contre, dans le monde du g enie logiciel dune mani` ere g en erale, les
d enitions et les concepts ne sont pas aussi pr ecis. S. THOMASON [25] a afrm e : vous
pouvez trouver autant de d enitions dun concept quil y a de lecteurs dun article.
Larchitecture logicielle est une discipline r ecente du g enie logiciel focalisant sur la struc-
ture, le comportement et les propri et es globales dun syst` eme et sadresse plus parti-
culi` erement ` a la conception de syst` emes de grande taille. Lobjectif de la formalisation
des architectures est de promouvoir la r eutilisation et la compr ehension. Pour aller plus
loin et capturer lexpertise de conception pour un domaine particulier, la notion de style
architectural est mise en avant. Un style cadre la conception architecturale ` a travers un
ensemble de contraintes et de propri et es. Ainsi, il est possible d etre averti lorsque larchi-
tecture ne respecte pas les propri et es exig ees.
Dans ce premier chapitre, nous dressons une etude sur lapproche MDA et ses diff erentes
recommandations. Nous pr esentons les diff erents concepts relatifs au domaine de lar-
chitecture logicielle et nous etudions quelques styles architecturaux. Nous pr esentons
egalement une etude sur les architectures dynamiques et ses diff erents types.
1.1 MDA : Model Driven Architecture
En novembre 2000, lOMG (Object Management Group), consortium de plus de 1000
entreprises, initie lapproche MDA (Model Driven Architecture) [107]. Cette approche a
pour but dapporter une nouvelle vision uni ee de concevoir des applications en s eparant
6 Architectures logicielles
la logique m etier de lentreprise, de toute plateforme technique. En effet, la logique m etier
est stable et subit peu de modications au cours du temps, contrairement ` a larchitec-
ture technique. Il est donc evident de s eparer les deux pour faire face ` a la complexit e
des syst` emes dinformation et aux co uts excessifs de migration technologique. Cette
s eparation autorise alors la capitalisation du savoir logiciel et du savoir-faire de lentre-
prise. A ce niveau, lapproche objet et lapproche composant nont pas pu tenir leurs
promesses. Il devenait de plus en plus difcile de d evelopper des logiciels bas es sur ces
technologies. Le recours ` a des proc ed es suppl ementaires, comme le patron de conception
ou la programmation orient ee aspect, etait alors n ecessaire. Lapproche MDA entre dans
ce contexte et offre la possibilit e darr eter lempilement des technologies qui n ecessite
une conservation des comp etences particuli` eres pour faire cohabiter des syst` emes divers
et vari es. Ceci est permis gr ace au passage dune approche interpr etative ` a une approche
transformationnelle, o` u lindividu a un r ole simpli e et amoindri gr ace ` a la construction
automatis ee.
MDA nest pas une solution qui va r esoudre tous les probl` emes, mais elle parat la seule
aujourdhui capable de fournir des r eponses satisfaisantes ` a toutes ces nouvelles exigences
[82]. Dans lapproche MDA, tout est consid er e comme mod` ele, aussi bien les sch emas
que le code source ou binaire. Le mod` ele ind ependant de plateforme (PIM) et le mod` ele
d ependant de plateforme (PSM) constituent les principaux types de mod` eles dans le cadre
de MDA. Les PIM sont des mod` eles qui nont pas de d ependance avec les plateformes
technologiques (ils sont donc ind ependants de CORBA, EJB, Services Web, .NET, etc.).
Les PSM sont des mod` eles d ependants des plateformes technologiques et servent de base
` a la g en eration de code ex ecutable.
De plus, nous pouvons mentionner quune approche dirig ee par les mod` eles oblige les
architectes et les d eveloppeurs ` a focaliser leurs travaux sur larchitecture et le mod` ele
du syst` eme. MDA fournit une approche de lutilisation de mod` eles pour diriger la
compr ehension, la conception, la construction, le d eploiement, lop eration, la maintenance
et la modication de syst` emes [107, 20].
La proposition de lOMG recommande lutilisation dUML (Unied Modeling Lan-
guage), MOF (Meta Object Facility) et XMI (XML Metadata Interchange). Le MOF est
le m eta-m eta-mod` ele standard unique. XMI est le format qui va permettre l echange de
mod` eles et de m eta-mod` eles. Il est bas e sur XML (Extensible Markup Language). Enn,
UML est lun des premiers m eta-mod` eles bas e sur le MOF adopt e par lOMG [29].
1.1.1 Architecture ` a quatre niveaux
La mod elisation logicielle a radicalement evolu e au cours de ces derni` eres ann ees. Ces
changements majeurs sont principalement support es par lOMG. Il y a aujourdhui un
consensus autour dune architecture ` a quatre niveaux adopt e principalement par lOMG et
lUML [20].
Comme le montre la gure 1.1, quatre niveaux caract erisent ce standard de m eta-
1.1 MDA : Model Driven Architecture 7
mod elisation. Le niveau M
0
qui est le niveau des donn ees r eelles, compos e des informa-
tions que lon souhaite mod eliser. Ce niveau est souvent consid er e comme etant le monde
r eel. Lorsquon veut d ecrire les informations contenues dans le niveau M
0
, cette activit e
donne naissance ` a un mod` ele appartenant au niveau M
1
. Un mod` ele UML appartient au
niveau M
1
. Le niveau M
2
est compos e des langages de d enition des mod` eles dinforma-
tion, appel es aussi m eta-mod` eles. Un m eta-mod` ele d enit la structure dun mod` ele. Le
niveau M
3
est le niveau le plus abstrait parmi les quatre niveaux dans cette architecture.
Il d enit la structure de tous les m eta-mod` eles du niveau M
2
ainsi que lui-m eme. Il est
compos e dune unique entit e qui sappelle le MOF.
Le MM
CWM
Autre
modle UML
m
Un modle
UML m
Le MMM MOF
Le MM
UML
Le MM UPM
(SPEM)
Des
informations
relles
Mta-modle
Modle
Le monde rel
Mta-mta-
modle
Le MOF
Le mta-modle UML et
autres MMs
Des modles UML et
d'autres formalismes
Diffrentes
utilisations de ces
modles
Niveau
M
3
Niveau
M
2
Niveau
M
1
Niveau
M
0
FIG. 1.1 Architecture ` a quatre niveaux
Dans larchitecture ` a quatre niveaux, la validation dun mod` ele se fait avec le mod` ele du
niveau suivant. Ce concept de m eta-mod` ele nous semble fondamental. Il aide non seule-
ment ` a r eduire les ambigut es et les incoh erences de la notation, mais il constitue aussi un
pr ecieux atout pour les concepteurs, dans le cadre dune automatisation du processus de
d eveloppement logiciel. Linconv enient majeur de MOF par rapport ` a nos objectifs cest
quil noffre pas des techniques de validation et des r` egles de passage dun niveau ` a un
autre.
Dans notre approche, on sint eresse uniquement aux trois premiers niveaux. M
0
pour
d ecrire lexistant. M
1
pour sp ecier lexistant avec UML et M
2
pour sp ecier le m eta-
mod` ele de M
1
.
1.1.2 MOF : Meta Object Facility
MOF pour (Meta-Object Facility) [106] est un ensemble dinterfaces permettant de d enir
la syntaxe et la s emantique dun langage de mod elisation. Il a et e cr e e par lOMG an de
d enir des m eta-mod` eles et leurs mod` eles correspondants [10].
Il fait partie des standards d enis par lOMG et il peut etre vu comme un sous-ensemble
dUML. Le MOF et lUML constituent le cur de lapproche MDA car ces deux standards
permettent de cr eer des mod` eles technologiquement neutres. Le MOF sp ecie la structure
et la syntaxe de tous les m eta-mod` eles comme UML, CWM (Common Warehouse Meta-
model) et SPEM (Software Process Engineering Meta-model). Ils ont le m eme forma-
lisme. Le MOF sp ecie aussi des m ecanismes dinterop erabilit e entre ces m eta-mod` eles.
Il est donc possible de les comparer et de les relier. Gr ace ` a ces m ecanismes d echanges,
le MOF peut faire cohabiter plusieurs m eta-mod` eles diff erents [10].
MOF 2.0 a et e d evelopp e en prenant en compte la nouvelle infrastructure dUML 2.0,
permettant ainsi ` a UML 2.0 d etre utilis e an de repr esenter des m eta-mod` eles de MOF
2.0. MOF 2.0 introduit une importante nouveaut e, cest la norme de QVT (Query View
Transformation) qui est un langage de requ etes et de transformation de mod` eles. Le QVT
est le r esultat dun effort de normalisation des m ecanismes, des techniques et des notations
n ecessaires ` a la transformation de mod` eles sources en mod` eles cibles. Lobjectif du QVT
est de d enir et d etablir une mani` ere standard pour interroger les mod` eles du MOF, pour
cr eer des vues et pour d enir les transformations de mod` eles [98].
1.1.3 UML : Unied Modeling Language
Depuis que le groupe OMG a adopt e le langage de mod elisation uni e en 1997, UML
(Unied Modeling Language) sest rapidement etabli comme etant le standard pour la
mod elisation des syst` emes logiciels [48]. UML a et e concu pour unier diff erentes nota-
tions graphiques de mod elisation, etre le plus g en eral possible et etre extensible an de
prendre en charge des contextes non pr evus. La premi` ere version dUML a et e publi ee en
1997 par lOMG. Depuis, UML est devenu la r ef erence pour la conception de logiciels. La
sp ecication dUML d enit une notation graphique pour visualiser, sp ecier et construire
des applications orient ees objets [109].
La version 2.0 [126, 116, 19, 48] vise ` a faire entrer ce langage dans une nouvelle ` ere de
sorte que les mod` eles UML soient au centre de MDA. Cela revient ` a rendre les mod` eles
UML stables et productifs et ` a leur permettre de prendre en compte les plateformes
dex ecution. UML 2.0 a introduit de nouvelles constructions qui le rendent plus adapt e
au d eveloppement ` a base de composants et ` a la sp ecication des descriptions architectu-
rales.
La notation UML est d ecrite sous forme dun ensemble de diagrammes. La premi` ere
g en eration dUML (UML 1.x), d enit neuf diagrammes pour la sp ecication des ap-
plications. Dans UML 2.0, quatre nouveaux diagrammes ont et e ajout es : il sagit des
diagrammes de structure composite (Composite structure diagrams), les diagrammes de
paquetages (Packages diagrams), les diagrammes de vue densemble dinteraction (In-
teraction overview diagrams) et les diagrammes de synchronisation (Timing diagrams)
[101, 48]. Les diagrammes UML sont regroup es dans deux classes principales [144] :
Les diagrammes statiques : regroupent les diagrammes de classes, les diagrammes
dobjets, les diagrammes de structure composite, les diagrammes de composants, les
diagrammes de d eploiement, et les diagrammes de paquetages.
1.1 MDA : Model Driven Architecture 9
Les diagrammes dynamiques : regroupent les diagrammes de s equence, les dia-
grammes de communication (nouvelle appellation des diagrammes de collaboration
dUML 1.x), les diagrammes dactivit es, les machines ` a etats, les diagrammes de vue
densemble dinteraction, et les diagrammes de synchronisation.
UML est concu pour prendre en charge une grande vari et e de contextes. Cependant, m eme
avec cette intention d etre g en eral, UML ne peut pas couvrir tous les contextes et offre
ainsi un m ecanisme dextensibilit e bas e sur les prols. Un prol permet la personnali-
sation dUML pour prendre en charge des domaines sp eciques qui ne peuvent pas etre
repr esent es avec UML dans son etat original. Lapproche MDA pr econise fortement luti-
lisation dUML pour l elaboration de PIMs et de la plupart des PSMs. Les sp ecicit es de
chaque plateforme peuvent etre mod elis ees avec un prol.
En fait, nous pouvons d enir pour chaque syst` eme un prol qui regroupe les el ements
n ecessaires ` a ses caract eristiques [107].
1.1.4 Prol UML
Un prol UML est une adaptation du langage UML ` a un domaine particulier [20, 82]. Il est
constitu e de st er eotypes, de contraintes et de valeurs marqu ees [102]. Un st er eotype d enit
une sous-classe dun ou de plusieurs el ements du m eta-mod` ele UML. Cette sous classe a
la m eme structure que ses el ements de base, mais le st er eotype sp ecie des contraintes
et des propri et es suppl ementaires. Les contraintes peuvent etre sp eci ees non formelle-
ment, mais lutilisation dOCL (Object Constraint Language) est pr ef erable pour cr eer les
contraintes de facon formelle et standardis ee.
MDA propose lutilisation de prols UML. LOMG a standardis e certains prols. Nous
citons dans ce qui suit quelques uns :
Le prol EDOC (Enterprise Distributed Object Computing) vise ` a faciliter le
d eveloppement de mod` eles dentreprises, de syst` emes ou dorganisations en utilisant
une approche de collaboration r ecursive utilisable ` a diff erents niveaux de granularit e et
pour diff erents degr es de couplages. La gestion de ling enierie des processus m etier est
support ee par lassemblage de services en visant la stabilit e de larchitecture globale
dans le cas de modications locales [67].
Le prol EAI (Enterprise Application Integration) simplie lint egration dapplications
en normalisant les echanges et la traduction des m eta-donn ees.
Le prol CORBA(Common Object Request Broker Architecture) permet de repr esenter
` a laide dUML le mod` ele de composants CORBA.
Le prol mod elisation temps r eel (Schedulability Performance and Time) pour
mod eliser des applications en temps r eels.
Le prol Test permet la sp ecication de tests pour les aspects structurels (statiques)
ainsi que pour les aspects comportementaux (dynamiques) des mod` eles UML.
Le prol QoS (Quality of Service) repr esente la qualit e de service et de tol erance aux
erreurs.
Le prol SPEM (Software Process Engineering Metamodel) est d eni ` a la fois comme
un prol UML et comme un m eta-mod` ele MOF. SPEM d enit les facons dutiliser
UML dans les projets logiciels et permet la cr eation de mod` eles de processus (pour les
PIM exclusivement).
1.1.5 OCL : Object Constraint Language
En utilisant uniquement UML, il nest pas possible dexprimer toutes les contraintes sou-
hait ees. Fort de ce constat, lOMG a d eni formellement le langage textuel de contraintes
OCL, qui permet de d enir nimporte quelle contrainte sur des mod` eles UML [20] : le
langage OCL (Object Constraint Language) qui est un langage dexpression permettant
de d ecrire des contraintes sur des mod` eles. Une contrainte est une restriction sur une ou
plusieurs valeurs dun mod` ele non repr esentable en UML.
Une contrainte OCL est une expression dont l evaluation doit retourner vrai ou faux.
L evaluation dune contrainte permet de savoir si la contrainte est respect ee ou non.
OCL donne des descriptions pr ecises et non ambigu es du comportement du logiciel en
compl etant les diagrammes. Il d enit des pr e-conditions, des post-conditions et des inva-
riants pour une op eration. Il permet aussi la d enition des expressions de navigation et
des expressions bool eennes. Cest un langage de haut niveau dabstraction, parfaitement
int egr e ` a UML, qui permet de trouver des erreurs beaucoup plus t ot dans le cycle de vie de
lapplication. Cette v erication derreurs est rendue possible gr ace ` a la simulation du com-
portement du mod` ele [108, 12, 110, 6] en utilisant des outils tels que USE (UML-based
Specication Environment) [55] et Octopus (OCL Tool for Precise UML Specications)
[44].
1.1.6 XMI : Xml Metadata Interchange
XMI est le langage d echange entre le monde des mod` eles et le monde XML (eXten-
sible Markup Language). Cest le format d echange standard entre les outils compatibles
MDA. XMI d ecrit comment utiliser les balises XML pour repr esenter un mod` ele UML
en XML. Cette repr esentation facilite les echanges de donn ees entre les diff erents outils
ou plateformes de mod elisation. En effet, XMI d enit des r` egles permettant de construire
des DTD (Document Type Denition) et des sch emas XML ` a partir de m eta-mod` eles, et
1.2 Architecture logicielle 11
inversement. Ainsi, il est possible dencoder un m eta-mod` ele dans un document XML,
mais aussi, ` a partir dun document XML il est possible de reconstruire des m eta-mod` eles.
XMI a lavantage de regrouper les m eta-donn ees et les instances dans un m eme document
ce qui permet ` a une application de comprendre les instances gr ace ` a leurs m eta-donn ees.
Ceci facilite les echanges entre applications et certains outils pourront automatiser ces
echanges en utilisant un moteur de transformation du type XSLT (Extensible Stylesheet
Language Transformation) [20].
1.2 Architecture logicielle
Larchitecture logicielle, comme le montre la gure 1.2, se d enit comme une sp ecication
abstraite dun syst` eme en termes de composants logiciels ou modules qui le constituent,
des interactions entre ces composants (connecteurs) et dun ensemble de r` egles qui gou-
vernent cette interaction [21, 38, 50, 64, 87]. Les composants encapsulent typiquement
linformation ou la fonctionnalit e. Tandis que les connecteurs assurent la communication
entre les composants. Cette architecture poss` ede, g en eralement, un ensemble de propri et es
dordre topologique ou fonctionnelle quelle doit respecter tout au long de son evolution.
Connecteur
Composant 2 Composant 1
Interface requise Interface fournie
Port
FIG. 1.2 Les el ements dune architecture logicielle
1.2.1 Composant
La notion de composant logiciel est introduite comme une suite ` a la notion dobjet.
Le composant offre une meilleure structuration de lapplication et permet de construire
un syst` eme par assemblage de briques el ementaires en favorisant la r eutilisation de ces
briques [132].
La notion de composant a pris de nombreuses formes dans les diff erentes approches de
larchitecture logicielle [135]. La d enition suivante, globalement accept ee, illustre bien
ces propri et es : Un composant est une unit e de calcul ou de stockage. Il peut etre primitif
ou compos e. On parle dans ce dernier cas de composite. Sa taille peut aller de la fonction
math ematique ` a une application compl` ete. Deux parties d enissent un composant. Une
premi` ere partie, dite externe, comprend la description des interfaces fournies et requises
par le composant. Elle d enit les interactions du composant avec son environnement. La
seconde partie correspond ` a son contenu et permet la description du fonctionnement in-
terne du composant [105].
En effet, le terme composant logiciel est utilis e depuis la phase de conception jusqu` a la
phase dex ecution dune application, il prend donc plusieurs formes. Dans ce document,
nous parlerons de type de composant et instance de composant.
Type de composant : un type de composant est la d enition abstraite dune entit e logi-
cielle. Nous utilisons le type de composant pour la description du style architectural.
Instance de composant : une instance de composant est au m eme titre quune instance
dobjet, une entit e existante et sex ecutant dans un syst` eme. Elle est caract eris ee par une
r ef erence unique, un type de composant et une implantation de ce type. Nous utilisons
linstance de composant pour la description des op erations de reconguration.
1.2.2 Connecteur
Le connecteur (appel e connexion selon notre terminologie) correspond ` a un el ement dar-
chitecture qui mod elise les interactions entre deux ou plusieurs composants en d enissant
les r` egles qui gouvernent ces interactions [30, 105].
1.2.3 Port
Un composant interagit avec son environnement par linterm ediaire de points dinterac-
tions appel es ports. Les ports (et par cons equent les interfaces) peuvent etre fournis ou
requis. Un port repr esente un point dacc` es ` a certains services du composant [30]. Le
comportement interne du composant ne doit etre ni visible, ni accessible autrement que
par ses ports.
1.2.4 Interface
Cest le point de communication qui permet dinteragir avec lenvironnement. On la re-
trouve donc associ ee aux composants et aux connecteurs. Elle sp ecie des ports dans le
cas des composants et des r oles dans le cas des connexions. [105].
Pour un composant, il existe deux types dinterfaces :
Les interfaces fournies d ecrivent les services propos es par le composant (gure 1.3).
Les interfaces requises d ecrivent les services que les autres composants doivent fournir
pour le bon fonctionnement du composant dans un environnement particulier (gure
1.3).
1.3 Style architectural 13
Ces interfaces sont eventuellement exprim ees par linterm ediaire des ports (gure 1.3).
Nom composant
Port
Interface requise
Interface fournie
FIG. 1.3 Mod elisation graphique dun composant
1.2.5 Conguration
Composants et connecteurs peuvent etre assembl es ` a partir de leurs interfaces pour former
une conguration. Celle ci d ecrit lensemble des composants logiciels n ecessaires pour le
fonctionnement dune application, ainsi que leurs connexions. On parle aussi de topologie.
Une conguration repr esente en fait une instance possible dun style architectural. Plus
pr ecis ement, une conguration d ecrit les instances de composants intervenants et les rela-
tions quelles entretiennent entre elles [88].
La conception dune architecture logicielle, a une importance capitale pour la r eussite dun
projet informatique. Elle est souvent li ee au savoir-faire de larchitecte. Une architecture
logicielle doit tenir compte des contraintes suivantes :
La r eutilisabilit e : est la capacit e ` a rendre g en erique des composants et ` a concevoir
et construire des boites noires susceptibles de fonctionner avec des langages et des
environnements vari es.
La maintenabilit e : est la capacit e de modier et dadapter une application an de la
maintenir sur une p eriode de vie assez longue. Une architecture bien sp eci ee doit etre
maintenue tout au long de son cycle de vie. La pr evision de lint egration des extensions
` a larchitecture et la correction des erreurs sont n ecessaires d` es la phase de conception.
La performance : cest loptimisation du temps mis par une application pour r epondre
` a une requ ete donn ee. La performance dune application d epend de larchitecture
logicielle choisie, de son environnement dex ecution, de son impl ementation et de la
puissance des infra-structures utilis ees (e.g. d ebit du r eseau utilis e).
1.3 Style architectural
Dans nimporte quelle activit e relative au domaine du g enie logiciel, une question qui
revient souvent est : comment b en ecier des exp eriences ant erieures pour produire
des syst` emes plus performants ? Dans le domaine des architectures logicielles, une des
mani` eres, selon [104], est de classer les architectures par cat egories et de d enir leurs ca-
ract eristiques communes. En effet, un style architectural d enit une famille darchitectures
logicielles qui sont caract eris ees par des propri et es structurelles et s emantiques communes
[99].
Les styles darchitecture [54, 47, 79] sont des sch emas darchitectures logicielles qui sont
caract eris es par :
Un ensemble de types de composants.
Un ensemble de connecteurs.
Une r epartition topologique de ces composants indiquant leurs relations.
Un ensemble de contraintes s emantiques.
Un style nest pas une architecture mais une aide g en erique ` a l elaboration de struc-
tures architecturales [39]. Un style architectural inclut une sp ecication statique et une
sp ecication dynamique. La partie statique englobe lensemble des el ements (compo-
sants et connecteurs) et des contraintes sur ces el ements. La partie dynamique d ecrit
l evolution possible dune architecture en r eaction ` a des changements pr evus ou impr evus
de lenvironnement. Un style architectural est pr ecis ement d eni par un ensemble de ca-
ract eristiques telles que : le vocabulaire utilis e (les types de composants et de connexions),
les contraintes de conguration (contraintes topologiques appel ees aussi patrons struc-
turels), les invariants du style, les exemples communs dutilisation, les avantages et in-
conv enients dutilisation de ce style et les sp ecialisations communes du style. Un style ar-
chitectural sp ecie aussi les types danalyse que lon peut faire sur ses instances (syst` emes
construits conform ement ` a ce style) [51].
Parmi les principaux styles architecturaux, nous citons le style client-serveur, le style
publier-souscrire et le style pipe and ltre.
1.3.1 Style client-serveur
Il est sans doute le style le plus connu de tous [18, 137]. Comme le montre la gure 1.4, il
se base sur deux types de composants : un composant de type serveur, offrant un ensemble
de services, ecoute des demandes sur ses services. Un composant de type client, d esirant
quun service soit assur e, envoie une demande (requ ete) au serveur par linterm ediaire
dun connecteur. Le serveur rejette ou ex ecute la demande et envoie une r eponse de nou-
veau au client. La contrainte qui simpose dans ce type est quun composant ne peut
etre quun fournisseur de services ou un demandeur de services. Le style client-serveur
consiste alors ` a structurer un syst` eme en terme dentit es serveurs et dentit es clientes qui
communiquent par linterm ediaire dun protocole de communication ` a travers un r eseau
informatique.
Client Serveur
Requte
Rponse
FIG. 1.4 Le style client-serveur
1.3.2 Style publier-souscrire
Ce style, comme le montre la gure 1.5, se base sur trois composants. Un composant
producteur qui va produire des informations. Un composant consommateur qui va les
consommer et un composant service d ev enement qui va assurer l echange dinformations
entre les producteurs et les consommateurs. Ces derniers ne communiquent donc pas di-
rectement et ne gardent m eme pas les r ef erences des uns et des autres. De plus, les produc-
teurs et les consommateurs nont pas besoin de participer activement ` a linteraction selon
un mode synchrone. Le producteur peut publier des ev enements pendant que le consom-
mateur est d econnect e, et r eciproquement, le consommateur peut etre noti e ` a propos dun
ev enement pendant que le producteur, source de cet ev enement, est d econnect e.
Consommateur
Notifier
Producteur
Publier Service
dvnement
Consommateur
Notifier
Consommateur
Notifier
FIG. 1.5 Le style publier-souscrire
1.3.3 Style pipes and lters
Dans ce style, comme le montre la gure 1.6, un composant recoit un ensemble de donn ees
en entr ee et produit un ensemble de donn ees en sortie. Le composant, appel e ltre, lit
continuellement les entr ees sur lesquelles il ex ecute un traitement ou une sorte de ltrage
pour produire les sorties [51]. Les sp ecications des ltres peuvent contraindre les entr ees
et les sorties. Un connecteur, quant ` a lui, est appel e pipe puisquil repr esente une sorte
de conduite qui permet de v ehiculer les sorties dun ltre vers les entr ees dun autre. Le
style pipes and lters exige que les ltres soient des entit es ind ependantes et quils ne
connaissent pas lidentit e des autres ltres. De plus, la validit e dun syst` eme conforme ` a
ce style ne doit pas d ependre de lordre dans lequel les ltres ex ecutent leur traitement.
Filtre 1 Filtre 2
Canal 2 Canal 1 Canal 3
FIG. 1.6 Le style pipes and lters
1.3.4 Avantages des styles architecturaux
Lutilisation des styles architecturaux a un certain nombre davantages signicatifs.
Dabord, elle favorise la r eutilisation de la conception. En effet, des applications
mod elis ees selon un style et des propri et es architecturales bien d enies peuvent etre
r eappliqu ees ` a des nouvelles applications. Elle facilite, pour les autres, la compr ehension
de lorganisation de larchitecture de lapplication si les structures conventionnelles sont
bien appliqu ees et utilis ees. Par exemple, concevoir une application selon le style Client-
Serveur peut donner une id ee claire sur le type de composants utilis es et les interactions
entre les diff erents composants. Finalement, lutilisation des styles architecturaux peut
mener ` a la r eutilisation signicative du code : souvent les aspects invariants dun style
architectural se pr etendent ` a des impl ementations partag ees.
1.4 Architecture dynamique
Les architectures logicielles, comme nous lavons pr esent e pr ec edemment, peuvent etre
d ecrites comme etant un ensemble de composants et de connecteurs dans un cadre com-
mun. Toutefois, cette approche est une approche statique. En effet, la structure du syst` eme,
une fois son architecture d enie, n evolue pas dans le temps. Ce type darchitecture com-
mence ` a perdre de lampleur et c eder la place au concept darchitecture dynamique suite
` a de nombreuses raisons d etaill ees plus tard. Dans la suite, nous pr esentons une d enition
et quelques motivations qui sont derri` ere la naissance de ce concept.
1.4.1 D enition et motivation de la dynamique des architectures
Depuis quelques ann ees, la dynamique des architectures est devenue une activit e qui com-
mence ` a prendre de lampleur. Les architectures des syst` emes logiciels tendent ` a devenir
de plus en plus dynamiques. En effet, durant son cycle de vie, ce type dapplications
peut etre amen e ` a evoluer de diff erentes mani` eres : evolution de larchitecture, ajout de
fonctions, remplacements de certains composants par de nouveaux d evelopp es selon de
nouvelles technologies de programmation ou de communication, etc.
1.4 Architecture dynamique 17
1.4.2 Raison derri` ere la dynamique des architectures
La dynamique des architectures peut etre r ealis ee pour diff erentes raisons. Ces raisons
peuvent etre class ees en quatre cat egories [70] :
Dynamique correctionnelle : dans certains cas, on remarque que lapplication en cours
dex ecution ne se comporte pas correctement comme pr evu. La solution est didentier
le composant de lapplication qui pose probl` eme et le remplacer par une nouvelle
version suppos ee correcte. Cette nouvelle version fournit la m eme fonctionnalit e que
lancienne, elle se contente simplement de corriger ses d efauts.
Dynamique adaptative : m eme si lapplication sex ecute correctement, parfois len-
vironnement dex ecution, comme le syst` eme dexploitation, les composants mat eriels
ou dautres applications ou donn ees dont elle d epend, changent. Larchitecture doit
donc sadapter et evoluer soit en ajoutant des nouveaux composants/connexions soit en
remplacant des composants/connexions par dautres.
Dynamique evolutive : au moment du d eveloppement de lapplication, certaines
fonctionnalit es ne sont pas prises en compte. Avec l evolution des besoins de lutilisa-
teur, lapplication doit etre etendue avec de nouvelles fonctionnalit es. Cette extension
peut etre r ealis ee en ajoutant un ou plusieurs composants/connexions pour assurer les
nouvelles fonctionnalit es ou m eme en gardant la m eme architecture de lapplication et
etendre simplement les composants existants.
Dynamique perfective : lobjectif de ce type dadaptation est dam eliorer les perfor-
mances du syst` eme. A titre dexemple, on se rend compte que limpl ementation dun
composant nest pas optimis ee. On d ecide alors de remplacer limpl ementation du
composant en question. Un autre exemple peut etre celui dun composant qui recoit
beaucoup de requ etes et qui narrive pas ` a les satisfaire. Pour eviter la d egradation des
performances de lapplication, on diminue la charge de ce composant en installant un
autre qui lui partage sa t ache.
Le souci majeur des techniques de conception des syst` emes logiciels est donc de pouvoir
sadapter ` a ces variations et de supporter la dynamicit e. Ces variations sont de diff erents
types [112].
1.4.3 Types darchitectures dynamiques
Pour soutenir le d eveloppement des architectures dynamiques, plusieurs chercheurs se
sont concentr es sur le d eveloppement dapproches et de formalismes fournissant des
syst` emes darchitecture dynamique.
Suite ` a ces recherches, diff erents types de dynamiques sont apparus. Parmi ces types nous
trouvons :
Dynamique dimpl ementation : ce type de dynamique permet de modier la mise
en uvre dun composant, cest-` a-dire la mani` ere avec laquelle un composant a et e
d evelopp e (le code du composant) sans changer ni les interfaces ni les connexions. Ce
type de changement permet de faire evoluer un composant dune version ` a une autre
(voir gure 1.7).
C1
C1
C2
C2
C3
C3
C1
C1
C2
C2
C3
C3
Version 1 Version 2
FIG. 1.7 Exemple de changement dimpl ementation
Dynamique dinterfaces : comme nous lavons d etaill e pr ec edemment, un composant
fournit ses services ` a travers des interfaces. La dynamique dinterfaces consiste ` a mo-
dier les services fournis par un composant au biais de ses interfaces. Ceci, se traduit
soit par la modication de lensemble des services fournis soit par la modication de la
signature dun service (voir gure 1.8).
C1
C1
C2
C2
S1
S1
C1
C1
C2
C2
S1
S1
P(a, b)
C1
C1
C2
C2
S1
S1
P(a, b, c)
C1
C1
C2
C2
S1
S1
C3
C3
Cas 2
Cas 1
P(a, b)
P(a, b)
P(a, b)
P(a, b)
P(a, b)
P(a, b)
Q(a)
FIG. 1.8 Exemple de changement dinterface
Dynamique de g eom etrie : elle est appel ee aussi dynamique de localisation ou encore
de migration. La dynamique de g eom etrie modie la distribution g eographique dune
application. En effet, ce type de dynamique alt` ere uniquement lemplacement des com-
posants. Ainsi, un composant peut changer de localisation en migrant dun site vers un
autre. Comme le montre la gure 1.9, le composant C4 est d eplac e du site 2 vers le site
3.
1.5 Conclusion 19
C1
C1
C2
C2
C3
C3
C4
C4
C5
C5
C6
C6
Site1
Site2
C1
C1
C2
C2
C3
C3
C4
C4
Site1
Site3
C5
C5
C6
C6
Site2
FIG. 1.9 Exemple de changement g eom etrique
Dynamique de structure : elle modie la topologie de lapplication. Cest-` a-dire dans
ce type de dynamique on sint eresse uniquement au changement de la structure de lap-
plication en termes de composants et de connexions. Cette dynamique se r ealise ` a laide
de quatre op erations de base [140] : ajout dun composant, suppression dun composant,
ajout dune connexion et suppression dune connexion. Comme le montre la gure 1.10,
La connexion T1 est redirig ee vers le composant S1.
C1
C1
C2
C2
C3
C3
C4
C4
C1
C1
C2
C2
S1
S1
C3
C3
C4
C4
S2
S2
S1
S1
S2
S2
T1
T1
FIG. 1.10 Exemple de changement de structure
1.5 Conclusion
Dans ce qui pr ec` ede, nous avons mis notre travail dans son contexte. Notre etude se base
essentiellement sur les architectures logicielles. Ces architectures se basent sur la notion
de composant. Les architectures ` a base de composants peuvent changer de structure suite
` a la variation des exigences des utilisateurs ou ` a la variation du contexte de lapplication.
Dans ce travail, nous nous concentrons sur la mod elisation de la dynamique de larchitec-
ture logicielle au niveau conceptuel (design time). Nous remarquons dans ce contexte que
larchitecture est ` a la base de la structure et de l evolution dynamique des syst` emes logi-
ciels. Le d eveloppement de ces syst` emes exige des approches bien etablies garantissant
la robustesse de la structure de lapplication. En plus, la dynamique de larchitecture doit
etre contr ol ee selon son style architectural an de pr eserver des propri et es architecturales
du syst` eme pendant son evolution et pour ne pas aboutir ` a des congurations qui risquent
de nuire au bon fonctionnement du syst` eme.
Avant dentamer la pr esentation de notre proposition, nous pr esentons, dans ce qui suit,
un apercu sur les principaux travaux r ealis es dans le domaine de larchitecture logicielle.
2
Description des architectures logicielles :
Etat de lart
Ce chapitre est organis e en deux parties. Dans une premi` ere etape, nous pr esentons les
recherches r ealis ees pour la description des architectures logicielles. Les contributions
existantes li ees ` a ce domaine peuvent etre class ees principalement, comme le montre la
gure 2.1, en quatre axes de recherches. Nous citons les Langages de Description dArchi-
tecture (ADL), le Langage de Mod elisation Uni e (UML), les Techniques Formelles (TF)
et les Multi-Formalismes (MF). Nous pr esentons, dans ce qui suit, une etude de chaque
approche et nous pr esentons leurs avantages et leurs limites.
Dans une deuxi` eme etape, nous pr esentons, comme le montre la gure 2.1, les principaux
travaux r ealis es dont le but de proposer des m ethodes de conception pour les architectures
logicielles.
Formalismes de description
darchitectures
@
@
@
@
@
P
P
P
P
P
P
P
P
P
P
P
P
P
P P
ADLs UML Techniques Formelles Multi-Formalismes
FIG. 2.1 Formalismes de description darchitectures logicielles

Etat de lart
2.1 Langages de description darchitecture (ADL)
Les premiers travaux r ealis es pour d ecrire les architectures logicielles ont et e men es d` es
le d ebut des ann ees 90. Ces recherches ont donn e naissance aux langages de description
darchitectures (gure 2.2).
ADLs
H
H
H
H
H
X
X
X
X
X
X
X
X
X
Darwin
[89]
Wright
[9] [8]
Rapide
[86]
-Space
[32] [33]
Suite
Suite
H
H
H
H
H
H
X
X
X
X
X
X
X
X
X
X
X
ArchWare
[111] [100]
C2
[92] [91]
Olan
[16]
ArchJava
[7]
Acme
[53]
FIG. 2.2 Les langages de description darchitecture
Il faut pr eciser quil existe plusieurs d enitions, mais en g en eral nous adoptons la
d enition propos ee par MEDVIDOVIC et al. [94] Les ADLs (Architecture Description
Language) [57, 94, 92, 91, 53] emergent comme des solutions ` a base dune notation tex-
tuelle ou graphique, formelle ou semi formelle permettant de sp ecier des architectures
logicielles. Ils permettent la d enition dun vocabulaire pr ecis et commun pour les ac-
teurs devant travailler autour de la sp ecication li ee ` a larchitecture. Ils sp ecient les com-
posants de larchitecture de mani` ere abstraite sans entrer dans les d etails dimplantation.
Ils d enissent de mani` ere explicite les interactions entre les composants dun syst` eme et
fournissent des outils pour aider les concepteurs ` a d ecrire laspect structurel dun syst` eme.
Les ADLs offrent une grande diversit e de notations. N eanmoins, comme le montre la
gure 2.3, les concepts de composant, de connecteur et de conguration sont g en eralement
consid er es comme essentiels [45]. Les ADLs les plus connus et que nous etudions dans ce
rapport sont Darwin [89, 88], Rapid [86], Wright [8], -Space [32, 33].
Composant 2 Composant 1
Connecteur
Interface requise Interface fournie
Port
FIG. 2.3 Les concepts des ADLs
2.1 Langages de description darchitecture (ADL) 23
An dillustrer laspect dynamique et laspect comportemental dans les diff erents ADLs
etudi es, nous pr esentons lexemple de l edition coop erative des documents [118, 56].
Comme le montre la gure 2.4, il sagit dun syst` eme permettant ` a un ensemble dutilisa-
teurs (user) de coop erer ` a la r edaction (write) et ` a la lecture (read) dun m eme document.
Le document ` a editer est organis e en fragments (fragment) num erot ees de 0 ` a N. Un auteur
(writer) doit avant d ecrire dans une zone, ensemble de fragments cons ecutifs, la r eserver.
Une fois que lauteur a r eserv e un fragment alors il sera verrouill e jusqu` a la n de la
r edaction. Apr` es la modication, lauteur peut lib erer la zone quil a auparavant r eserv ee.
Ainsi, chaque fragment du document ne peut se trouver que dans lun des deux cas de
gures suivants : libre ou r eserv e.
f : fragment
d : document
u : user
r : reader
w : writer
read
write
read
FIG. 2.4 Exemple de l edition coop erative des documents
2.1.1 Darwin
Le langage Darwin [89, 88] a et e d evelopp e par Distributed Software Engineering Group
de lImperial College. Darwin propose un mod` ele de composants pour la construction
dapplications distribu ees. Ce langage se centre sur la description de la conguration et
sur lexpression du comportement dune application plut ot que sur la description struc-
turelle de larchitecture dun syst` eme [4]. La particularit e de Darwin est de permettre
la sp ecication dune partie de la dynamique dune application en terme de sch ema de
cr eation de composants logiciels avant ou pendant son ex ecution.
Comme la plupart des ADLs, Darwin reprend les trois concepts de base ` a savoir le compo-
sant, le connecteur et la conguration, mais seul le composant est exprim e explicitement.
2.1.1.1 Aspect dynamique et comportemental
Darwin permet de sp ecier des composants dynamiques. Il permet de cr eer des compo-
sants en cours dex ecution du syst` eme. Le syst` eme nest plus consid er e comme un en-
semble de composants g es lors de la phase de conception, mais il est possible de sp ecier
les instants et les emplacements de cr eation dynamique de composants. Darwin fournit
deux m ecanismes pour d ecrire la cr eation dynamique : linstanciation paresseuse et lins-
tanciation dynamique.

Etat de lart
Linstanciation paresseuse permet de d eclarer, comme le montre la gure 2.5, des com-
posants qui ne seront pas instanci es imm ediatement. Le composant sera instanci e au
moment o` u un autre composant souhaite acc eder ` a ce service [13, 4].
component Edition{
inst
writer : Writer ;
fragment : dyn Fragment ;
bind
writer.reserve fragment.protect ;
FIG. 2.5 Exemple dinstanciation paresseuse selon Darwin
Linstance writer est cr e ee ` a linstanciation du composant Edition. Linstance
fragment, quant ` a elle, est d eclar ee dynamique avec la clause (fragment : dyn
Fragment) et ne sera cr e ee que lorsque le writer la sollicitera. Linstanciation pa-
resseuse permet donc de d ecrire la conguration potentielle ` a lex ecution en d eclarant
des instances potentiellement n ecessaires. Ce m ecanisme ne permet dinstancier quun
seul composant par clause dinterconnexion [13].
Linstanciation dynamique en opposition ` a linstanciation paresseuse, de multiples ins-
tances peuvent etre cr e ees dynamiquement ` a partir dune seule clause dinterconnexion.
Linstanciation dynamique permet ` a un composant dinstancier un ou plusieurs autres
composants [13, 80].
component Edition{
inst
writer : Writer ;
bind
writer.reserve dyn Fragment ;
FIG. 2.6 Exemple dinstanciation dynamique selon Darwin
Dans lexemple de la gure 2.6, linstance writer est cr e ee ` a linstanciation du com-
posant composite Edition. Le fragment nest pas d eclar e, mais un des services du
writer est reli e ` a la cr eation dynamique dun Fragment (writer.reserve --
dyn Fragment). Ainsi, le composant writer peut d eclencher la cr eation dun ou de
plusieurs fragments. Les instances cr e ees ne sont pas r ef erenc ees et les composants
dynamiques ne sont pas accessibles par les autres composants. En dautres termes, les
composants qui sont cr e es statiquement ne peuvent pas d eclencher une communication
avec ceux qui sont instanci es dynamiquement, seul linverse est possible [80].
Il est ` a noter que linstanciation dynamique permet de multiples instanciations au moyen
dune seule clause puisque le lien est sp eci e pour le type du composant ` a instancier
(Fragment) plut ot que pour une instance de ce type [123].
2.1.1.2 Style architectural
Linconv enient majeur de Darwin cest quil ne pr esente pas de m ecanisme propre ` a la
formalisation des styles architecturaux [80].
2.1.2 Rapide
Rapide [27, 85, 120] est un langage de description darchitecture dont le but principal
est de v erier, par simulation, la validit e dune architecture logicielle. Il fut propos e ` a
lorigine au projet ARPA (Advanced Research Projects Agency) en 1990. Il est bas e sur
des ev enements concurrents. Il est concu essentiellement pour prototyper des architectures
dans des syst` emes distribu es.
Le langage Rapide ne fournit pas doutils de g en eration de code, il permet cependant la
description du comportement dynamique et il offre des m ethodes de validation (simula-
tion) des architectures quil d ecrit. Il permet aussi de v erier certaines propri et es comme
linterblocage lors de lex ecution de lapplication. Les concepts de base de Rapide sont le
composant, l ev enement et larchitecture.
Rapide est capable de mod eliser larchitecture des syst` emes dynamiques dans lesquels
le nombre de composants peut varier quand le syst` eme est ex ecut e. Pour d ecrire la dy-
namique, Rapide introduit deux types de variables particuli` eres : les placeholder
et les iterator auxquelles sont associ ees des r` egles de cr eation. Le nom dune va-
riable placeholder commence toujours par ?. Cette variable d esigne un objet qui
est susceptible d etre pr esent. Le nom dune variable iterator commence toujours par
!. Cette variable d esigne une conjonction dinstances dun certain type. Les r` egles de
cr eation d enissent quand les composants doivent etre cr e es ou d etruits lors de lex ecution
[80].
architecture Edition is
?w : Writer ;
!f : Fragment ;
?service : Service ;
...
connect
?w.request( ?service) !f.reply( ?service) ;
end Edition ;
FIG. 2.7 Liaison conditionnelle entre un ecrivain et un fragment

Etat de lart
Dans lexemple de l edition coop erative, comme le montre la gure 2.7, ?w : Writer
est une variable placeholder et fait r ef erence ` a une instance de type Writer. !f :
Fragment est une variable iterator et d esigne toutes les instances de type
Fragment pr esentes dans lapplication. Ces d eclarations de variables d enissent un type
dobjet ou un ensemble de types dobjets devant etre pr esents dans larchitecture. Il nest
pas n ecessaire de d enir les instances de composants pr esents, car cela peut se faire dyna-
miquement au fur et ` a mesure de lex ecution. La partie connexion contient les r` egles de
connexion et les r` egles de cr eation. Les r` egles de cr eation d enissent les conditions sur les
ev enements qui guident la cr eation de nouveaux composants. Dans lexemple, la r` egle de
cr eation sp ecie lexistence dun writer?w qui emet avec nimporte quelle donn ee de
type Service, alors que la partie droite de la r` egle est ex ecut ee. Celle-ci sp ecie que tous
les fragment!f du syst` eme recoivent la m eme donn ee ?service. Ces r` egles peuvent
etre conditionn ees par une clause where.
Rapide supporte uniquement des manipulations dynamiques o` u tous les changements
dex ecutions doivent etre connus a priori. Il permet donc de cr eer des composants dy-
namiques et poss` ede des m ecanismes permettant leur gestion. Cependant, Rapide ne sup-
porte aucun op erateur de cr eation, suppression, migration de composants ou modication
dinterconnexions. En plus, dans le mod` ele, le concept de connecteur napparat que de
mani` ere implicite. Ceci limite la r eutilisation [119].
Comme Darwin, linconv enient majeur de Rapide cest quil ne pr esente pas de
m ecanisme propre ` a la formalisation des styles architecturaux.
2.1.3 Wright
Wright est un langage de description darchitecture cr e e par ALLEN et GARLAN il four-
nit des bases formelles pour sp ecier les interactions entre les composants (via des connec-
teurs). Wright est un langage de description orient e plus vers la v erication des protocoles
entre les composants, que vers la correction fonctionnelle de larchitecture globale. Il per-
met de d ecrire formellement une architecture ` a laide de lalg` ebre de processus CSP [9].
Comme les autres ADLs, Wright reprend les trois concepts de larchitecture logicielle ` a
savoir le composant, le connecteur et la conguration.
La premi` ere version de ce langage permettait de d ecrire uniquement des architectures sta-
tiques [9]. En 1998, Wright a et e etendu par Dynamic Wright [8] pour supporter les chan-
gements dynamiques de la topologie dune architecture. Cette extension consiste ` a intro-
duire un programme de conguration (Congurator) d ecrivant les diff erentes evolutions
possibles de larchitecture.
Pour mettre en evidence les propri et es dynamiques de Dynamic Wright, nous revenons ` a
notre exemple et nous consid erons une conguration dans laquelle deux serveurs g` erent
lacc` es en lecture et en ecriture ` a des documents . Le syst` eme est constitu e dun client
et dun serveur (Primary) interconnect es via un connecteur. Ce serveur peut tomber en
panne ` a tout moment. Lid ee consiste ` a faire transiter le syst` eme dune conguration ` a
une autre et ` a mettre ` a la disposition des utilisateurs un autre serveur (Secondary) qui
peut remplacer le premier jusqu` a ce que ce dernier soit pr et ` a fonctionner de nouveau. Il
existe donc deux congurations possibles comme le montre la gure 2.8 : le client est soit
attach e au serveur principal soit au serveur secondaire [8]. Le serveur primaire signale sa
panne ` a laide de l ev enement de contr ole control.down et son r etablissement avec
control.up.
L
Primary
f:fragment
d:document
u : user
r : reader
w : writer
Primary
f:fragment
d:document
Secondary
L
FIG. 2.8 Conguration selon Wright
Dans lexemple, comme le montre la gure 2.9, le congurateur attend le d eclenchement
dun ev enement de contr ole. Comme d ecrit dans la partie WaitForDown, deux situations
possibles sont sp eci ees : le syst` eme peut fonctionner correctement et se terminer avec
succ` es ($), ou une erreur peut apparatre avant la terminaison de lapplication (r eception de
l ev enement de contr ole serverDown de linstance Primary). Si le serveur primaire
est d etach e du connecteur detach.Primary.reply.from.L.request et que le
second est attach e ` a sa place attach.Secondary.reply.from.L.request, la
nouvelle conguration est alors etablie. Au r etablissement du primaire, WaitForUp sera
activ e, modiant de nouveau la conguration de mani` ere similaire. Les r oles entre les deux
serveurs sont alors invers es.
Dynamic Wright propose aussi des actions de reconguration new, del, attach,
et detach permettant de d ecrire les changements de larchitecture en terme de cr eation
et de suppression de composants et de connecteurs de mani` ere dynamique. Ces actions
sont d enies par le programme de conguration.

Etat de lart
Congurator Edition
new.U : User
new.Primary : FlakyServer
new.Secondary : SlowServer
new.L : FaultTolerantLink
attach.U.request.to.L.reply
attach.Primary.reply.to.L.request WaitForDown
where
WaitForDown = Primary.control.serverDown
detach.Primary.reply.from.L.request
attach.Secondary.reply.from.L.request
WaitForUP
$
WaitForUp = Primary.control.serverUp
detach.Secondary.reply.from.L.request
attach.Primary.reply.from.L.request
WaitForDown
$
FIG. 2.9 Sp ecication dynamique selon Wright : tol erance au fautes
Wright permet au concepteur de d ecrire et danalyser des styles architecturaux. Un style
en Wright est compos e de deux parties : le vocabulaire et les contraintes sur des congu-
rations. Le vocabulaire d enit des types de composant et de connecteur. Les contraintes
d enissent les pr edicats qui doivent etre v eri es pour nimporte quelle conguration sui-
vant le style. Un style est instanci e par une conguration, dont la d enition est simpli ee
car elle h erite des d enitions du style [80].
Wright sint eresse uniquement aux syst` emes ayant un nombre ni de congurations qui
sont connues a priori (Wright [8]). Ainsi, il nest pas possible deffectuer des op erations
de reconguration arbitraires durant lex ecution de lapplication et en particulier ceux qui
sont externes (non pr evues davance).
2.1.4 -Space
-Space [33, 31] est un ADL pour la description des architectures dynamiques ` a base
de composants. Il est formellement fond e sur le -calcul pour d ecrire les syst` emes dyna-
miques. Ce langage est etendu par -Space [81] pour la description des styles architec-
turaux.
Les architectures sont repr esent ees par des congurations de composites, de composants
et de connecteurs. Un composite est un el ement compos e permettant de d enir une con-
guration. Les composants et les connecteurs sont compos es dun ensemble de ports, dun
comportement et dun ensemble dop erations (pour les composants) [80].
-Space permet de formaliser la dynamique dune architecture. Lors dune description,
nous pouvons d enir quels el ements sont dynamiques. Leurs noms sont alors sufx es du
caract` ere [80].
Dans cet exemple, comme le montre la gure 2.10, le type client est d eclar e comme dy-
namique. Cela signie que plusieurs occurrences de type client peuvent etre cr e ees dy-
namiquement. La clause whenever permet de sp ecier des r eactions ` a des ev enements.
Dans lexemple, il est sp eci e que lorsquune nouvelle instance client est cr e ee, celle-ci
est attach e au connecteur.
De m eme, -Space permet de d enir des r` egles de dynamique permettant de d ecrire
les changements topologiques dus ` a la cr eation dynamique dun nouvel el ement. La
dynamique peut etre d eclench ee par un composant. Pour cela, des ports sp eciques
permettant d evoquer des recongurations attachementEvolutionPort,
ComponentEvolutionPort et EvolutionPort sont d enis. Ces ports sont
sollicit es via le mot-cl e evolvable.
compose Simple
C :Client
L :Link
S :Server
where
attach S@p@reply to L@s@sRequest,
attach S@p@request to L@s@sReply,
whenever
new C new L@c,
new L@c attach C@p@request to L@c@cReply,
new L@c attach C@p@reply to L@c@cRequest ;
FIG. 2.10 Sp ecication dynamique selon -Space
Lexemple de la gure 2.11 d enit le comportement dun composant. Ce comportement
engage un port (pC) qui permet de faire evoluer la topologie. Il permet le d eclenchement
dun ev enement pour une evolution via le port changementAttachement.
Le comportement commence par la r eception dun message via le port pC, puis continue

Etat de lart
par le d eclenchement dun ev enement pour une evolution via le port changementAttache-
ment.
dene behaviour component type ExempleTopologie
[pC :PortReception [canalReception :[ ] ] ,
changementAttachement :AttachmentEvolutionPort]
{
ExempleTopologie[changementAttachement] =
(pC@canalReception ()
evolvable(changementAttachement)
Boucle[pC] ),
Boucle[pC] = ( ( pC@ canalReception () Boucle[pC] ) + $)
}
FIG. 2.11 Changement de la topologie selon -Space
-Space [81] etend -Space avec des concepts sp eciques aux styles. Dans -Space,
un style permet de contraindre un type d el ement. Un style peut etre d eni pour des com-
posites, des composants, des connecteurs, des ports, des comportements et des op erations.
La d enition dun style permet de d ecrire un ensemble de contraintes qui repr esentent les
caract eristiques dune famille de types topologiques.
Un style contient une liste d el ements de construction. Ces el ements poss` edent des noms
g en eriques qui sont sp ecialis es lorsquune occurrence de l el ement est utilis ee dans une ar-
chitecture. Ces el ements peuvent etre associ es ` a une cardinalit e d enissant une contrainte
sur le nombre doccurrences dans larchitecture.
Dans -Space, il est possible dindiquer, dans un style, avec le symbole quun el ement
peut etre dynamique. En plus, il est possible de d enir des r` egles de conguration dans un
style de composite, en d ecrivant les attachements possibles. Le mot in style permet de
sp ecier quun type doit satisfaire un style. Le type doit alors respecter les contraintes im-
pos ees par le style et il ne peut utiliser dans sa description que les el ements de construction
fournis par le style [80].
2.1.5 Conclusion
Les ADLs fournissent une base formelle pour sp ecier les architectures logicielles en
mod elisant les composants, les connecteurs, et les congurations. Ces ADLs permettent
de sp ecier la vue structurelle dune architecture logicielle. Selon l etude que nous avons
men ee [57], nous avons identi e certaines lacunes. Les points faibles rencontr es dans les
ADLs sont de plusieurs ordres. La majorit e des ADLs proposent une notation sp ecique,
2.2 Langage UML 31
ce qui n ecessite un effort de plus pour comprendre le langage. La dynamique structu-
relle de larchitecture nest pas bien support ee par les ADLs bien quil existe un certain
nombre de propositions int eressantes, connues sous le nom de langages de description
darchitecture dynamiques (DADLs), mais pas toujours sufsantes (Darwin [90], Dyna-
mic Wright[8] et Rapide [85]). En effet, ces ADLs permettent difcilement de prendre
en compte lextension et l evolution des besoins. Peu de langages permettent dintroduire
des strat egies de reconguration et les solutions fournies ne sappliquent qu` a une des-
cription statique de lapplication. Les ADLs sint eressent uniquement aux syst` emes ayant
un nombre ni de congurations qui sont connues a priori (Wright [8]). Ainsi, il nest pas
possible deffectuer des op erations de reconguration ` a limproviste durant lex ecution de
lapplication et en particulier ceux qui sont externes (non pr evues davance). En outre, las-
pect comportemental est quasi absent dans la majorit e des ADLs ` a lexception de quelques
uns tel que (Rapide [85]). Cependant, cette description exprime seulement des ev enements
communicants et ne consid` ere pas des op erations de reconguration.
La plupart des ADLs ne sont pas satisfaisants pour la description des styles. Ils introduisent
eux-m emes des suppositions sp eciques sur les architectures. Ces suppositions peuvent
etre incoh erentes ou conictuelles avec celles sous-jacentes au syst` eme. Certains ADLs
sont sp eciques ` a un domaine et ` a un style particulier tel que MetaH [17] qui est un ADL
sp ecique aux architectures des syst` emes multi-processeurs temps r eel pour laviation.
Acme [53] et -Space [81, 31] ne sont pas sp eciques ` a un domaine, leur style propre
est plus g en erique [80].
Pour l etude des ADLs, nous nous sommes bas es, dans nos recherches, sur la premi` ere
g en eration. Cependant, il y a des nouvelles g en erations des ADLs tels que Prisma [114],
Plastik [66] et Pilar [40] qui traitent dune facon plus appropri ee laspect dynamique.
2.2 Langage UML
UML [48, 101] est un langage qui offre une notation graphique uni ee connue par la
majorit e des architectes et apportant une solution pour d ecrire larchitecture logicielle et
ce, tout particuli` erement avec lintroduction dans le standard UML 2.0 de la notion de
composant comme el ement de structuration des mod` eles.
A lheure actuelle UML est dans sa version 2.0 et il comporte 13 diagrammes. 6 dia-
grammes d ecrivent la structure du syst` eme (gure 2.12 : diagramme de classes, dia-
gramme de structure composite, diagramme de composants, diagramme de d eploiement,
diagramme dobjets et diagramme de paquetage). Les 7 autres diagrammes permettent
de d ecrire le comportement du syst` eme (gure 2.13 : les diagrammes dinteractions (dia-
gramme de s equence, diagramme de vue densemble des interactions, diagramme de com-
munication et diagramme de temps), diagramme dactivit e, diagramme de machine ` a etats
et diagramme de cas dutilisation).

Etat de lart
Vue statique
Di d Di Di d Di d Diagramme de
classes
Diagramme
de composants
Diagramme de
dploiement
Diagramme de
paquetage
Diagramme de
Diagramme
structure
composite
Diagramme
dobjets
FIG. 2.12 Diagrammes de structure
Vue
Comportementale
Diagramme
dactivit
Diagramme de
communication
Diagrammes
dinteractions
Diagramme de
cas dutilisation
Diagramme de
temps
Diagramme
de machine
tats
Diagramme de
vue densemble
des interactions
Diagramme de
squence
FIG. 2.13 Diagrammes de comporte-
ment
2.2.1 UML et larchitecture logicielle
UML 2.0 apporte des am eliorations pour repr esenter les architectures logicielles. Le dia-
gramme de composants a et e r evis e et le concept de classicateur structur e (structured
classier) a et e int egr e. Les classes, les collaborations et les composants sont des classi-
cateurs structur es. UML 2.0 introduit la notion de composant (component) ainsi que la
notion de connecteur (connector : assembly connector et delegation connector). Lintro-
duction de ces concepts, ainsi que ceux de port ou encore la distinction entre interfaces
offertes et requises fournissent une palette d el ements de notation int eressante pour la
mod elisation de larchitecture logicielle.
Un composant peut avoir son propre comportement et d etermine un contrat entre ses
services fournis et ses services requis, au travers de la d enition de ports. Il est ainsi
remplacable par un autre el ement dont la d enition des ports est similaire [26].
Un connecteur exprime une relation entre les composants. Il sagit de liens (une instance
dassociation) qui permet la communication entre deux ou plusieurs instances.
Un port repr esente les points dacc` es par lesquels les messages sont emis et recus par un
classicateur structur e. Les ports ont un type fourni sous la forme dun ensemble dinter-
faces. Ce qui est nouveau en UML 2.0, cest la possibilit e de doter une interface dattri-
buts et de pouvoir d enir des associations entre interfaces. Ainsi par rapport aux interfaces
dUML 1.5, un port peut impl ementer (to implement) ou utiliser (to require) ou fournir (to
provide) une interface. Quand il sagit dune interface fournie, elle caract erise le compor-
tement du composant fourni. Quand il sagit dune interface requise, elle caract erise le
comportement attendu [26].
UML 2.0 etend les diagrammes de composants dUML 1.5 dune simple repr esentation
physique vers la prise en compte des composants logiques. Ainsi, deux vues
compl ementaires sont possibles pour mod eliser les composants :
2.2 Langage UML 33
Une vue externe (bote noire). Lattention est port ee sur les contrats entre le composant
et son environnement.
Une vue interne (bote blanche). Lattention est port ee sur lorganisation interne du
composant en termes de component, sub-component, connector, etc.
Comme le montre la gure 2.14, deux types de connecteurs ont et e d enis. Les connec-
teurs dassemblage (assembly connector) relient une interface requise ` a une interface four-
nie. Les connecteurs de d el egation (delegation connector) relient un port ` a linterface
(compatible, et de m eme type requise/fournie) dune partie interne. Une ` eche indique
le sens de la d el egation [26].
Connecteur dassemblage
Connecteurs de dlgation
FIG. 2.14 Types de connecteur
2.2.2 UML en tant que langage pour la description des architectures
UML
H
H
H
H
H
H
H
H
H
H
H
As-Is
H
H
H
H
Statique
[93] [126] [76]
Dynamique
[76] [15] [37]
Extension
H
H
H
H
H
H
H
LightWeight
(Model)
H
H
H
H
Statique
[129] [93] [68]
[142] [23]
Dynamique
[68] [23]
HeavyWeight
(Meta-Model)
H
H
H
H
Statique
[122] [42] [115]
[116] [23] [36]
Dynamique
[122] [115] [23]
FIG. 2.15 Le langage UML
La diversit e des ADLs propos es ont conduit certains travaux de recherche ` a consid erer

Etat de lart
UML en tant que langage de description darchitecture ou de mapper vers la notation
UML [126, 139, 116, 52, 50, 69, 63]. Les travaux men es dans ce domaine, comme le
montre la gure 2.15, peuvent etre divis es principalement en deux approches. La premi` ere
est appel ee As-Is et consiste ` a utiliser la notation existante dUML sans aucune exten-
sion pour repr esenter larchitecture logicielle. La deuxi` eme, consiste ` a etendre la syntaxe
et la s emantique de la notation UML an de d ecrire larchitecture logicielle. Cette ex-
tension peut etre divis ee en heavyweight et lightweight. Lextension heavyweight
[116, 115, 69] ajoute de nouveaux mod` eles ou remplace la s emantique existante en mo-
diant le m eta-mod` ele dUML. Lextension lightweight [129, 93] d enit de nouveaux
el ements permettant d etendre la notation UML sans modication du m eta-mod` ele.
Parmi ces travaux, nous citons les recherches de MEDVIDIVOC et al. [93] qui visent
une adaptation dUML. Leurs travaux cherchent ` a repr esenter le style darchitecture
C2. Dans une premi` ere etape, ils proposent lutilisation dUML 1.4 tel quil est (As-Is)
sans consid erer ses m ecanismes dextension. Ils utilisent le diagramme de classes pour
repr esenter la structure du syst` eme. Ce diagramme illustre les classes issues de lappli-
cation, leurs relations dh eritage et leurs associations. Dans une deuxi` eme etape, MED-
VIDIVOC et al. cherchent ` a etendre et ` a adapter le m eta-mod` ele UML en y ajoutant
des st er eotypes n ecessaires ` a la description des architectures tels que les interfaces et les
connecteurs. Les traits avec le rond repr esentent la r ealisation des interfaces par les classes,
alors que les traits en pointill es avec des ` eches orient ees vers les ronds repr esentent des
relations de d ependance dune classe avec linterface impliqu ee. Les diagrammes de col-
laboration sont aussi utilis es pour la repr esentation des interactions entre les instances de
classes [93].
Nous citons aussi les travaux de MARTINEZ et al. qui repr esentent un exemple des exten-
sions lourdes dUML 1.4 (heavyweight) [116]. Ils proposent un style architectural appel e
C3 bas e sur le style C2. Le m eta-mod` ele propos e permet la description syntaxique des
architectures logicielle. Les nouveaux constructeurs sont rajout es au m eta-mod` ele comme
sous-classes de la m eta-classe ModelElement qui est une sous-classe de Element (la m eta-
classe racine). Les constructeurs Constraint, Attribute et Parameter d enis dans le paquet
Core, et les types Boolean et ProcedureExpression d enis dans le paquet Data Types sont
utilis es. Pour etendre le m eta-mod` ele UML, C3 suit les consignes suivantes :
Aucun m eta-constructeur (m eta-classe du m eta-mod` ele UML) nest supprim e ni mo-
di e dans sa syntaxe ou s emantique.
Les nouveaux m eta-constructeurs doivent avoir un minimum de relations avec les m eta-
constructeurs existants, cest-` a-dire ils doivent etre auto-contenus [115, 96].
2.2.3 Conclusion
Une etude bas ee sur etudes de cas [60, 58, 97], nous a permis de constater que UML 1.x,
en tant que langage pour les architectures logicielles, ne satisfait pas compl` etement les be-
soins structuraux n ecessaires pour la description des architectures logicielles. Il ne permet
de d ecrire convenablement ni larchitecture logicielle ni la dynamique structurelle [96].
De ce fait, nous avons fait recours ` a UML 2.0. Celui-ci offre en effet des am eliorations
2.3 Techniques formelles 35
signicatives en ce qui concerne les concepts propres utilis es pour mod eliser les architec-
tures logicielles. Lajout des concepts de port, de connecteur et de diagrammes darchitec-
tures (classes, composants, structure composite) enrichit grandement le pouvoir expressif
dUML 2.0 et le rend plus adapt e ` a supporter la mod elisation des architectures logicielles.
Lapport majeur dUML 2.0 par rapport ` a UML 1.x est quil offre un langage mieux d eni
et plus ouvert. Une etude, bas ee sur des etudes de cas [97] a montr e que UML 2.0 permet
la mod elisation de larchitecture logicielle et de d ecrire le comportement interne de lap-
plication. Cependant, et malgr e les diff erents diagrammes propos es, il ne permet pas de
d ecrire la dynamique structurelle dune architecture logicielle en termes dajout et/ou de
suppression de composants et/ou de connexions.
2.3 Techniques formelles
Le troisi` eme axe de recherche dans le domaine des architectures logicielles consiste ` a tirer
prot des avantages des techniques formelles existantes en les appliquant ` a la conception
architecturale. Lobjectif est de pouvoir offrir aux d eveloppeurs la possibilit e de raisonner,
analyser et v erier larchitecture dun syst` eme logiciel.
Techniques Formelles
H
H
H
H
H
H
H
H
H
H
H
H
H
H
H
H
H
H
H
Logic based Algebraic based
@
@
@
P
P
P
P
P
P
P P
CSP
[62]
CCS
[136]
Calcul
[128]
LOTOS
[46] [34]
Graph based
H
H
H
H H
Static
(Via GG)
[15] [78] [61] [145]
Dynamic
(Via TG)
[15] [78] [145]
Logic based
H
H
H
H
H
H
H
H
H
Static
H
H
H
H
H
H
H
Z
[83]
Zcl
[113] [121]
Temporal logic
[5]
Dynamic
H
H
H
H
H
H
Z
[83]
Zcl
[113]
Temporal logic
[5] [125]
FIG. 2.16 Les techniques formelles

Etat de lart
Les techniques formelles peuvent etre class es principalement en trois cat egories (gure
2.16) : les techniques bas ees sur les graphes [78, 61, 145], les techniques bas ees sur les
alg` ebres de processus [62, 128] et les techniques bas ees sur la logique [113, 125].
Les travaux formels elabor es dans le domaine de larchitecture logicielle ne poss` edent
pas les m emes visions. N eanmoins, ils cherchent tous ` a pouvoir offrir aux d eveloppeurs la
possibilit e de raisonner et danalyser une architecture. Cette pr esentation portera essentiel-
lement sur les techniques bas ees sur les graphes et plus particuli` erement les grammaires
de graphe.
2.3.1 Techniques bas ees sur les graphes
Pour sp ecier les architectures logicielles et le style architectural, il est possible dutiliser
les grammaires de graphe.
Les grammaires de graphe, ` a contexte libre, offrent la possibilit e de d enir larchitec-
ture logicielle dun syst` eme en terme de graphe. Ainsi, les nuds du graphe repr esentent
les entit es logicielles constituant larchitecture (composant) et les arcs correspondent aux
liens de communication entre ces entit es (connexion) [78]. Lavantage principal des gram-
maires de graphe est quelles permettent de d ecrire, en plus de laspect statique, laspect
dynamique dune architecture logicielle. En effet, pour d ecrire laspect dynamique, il faut
utiliser les r` egles de r e ecriture de graphe. Un syst` eme de r e ecriture de graphe est sp eci e
par un ensemble de r` egles de r e ecriture o` u le r ole de chaque r` egle est de remplacer un sous
graphe. Ces r` egles permettent de d ecrire clairement les changements de la topologie dune
architecture en termes dajout et/ou de suppression de composants et/ou de connexions.
Nous citons principalement les travaux de M
ETAYER qui constituent probablement les

premiers travaux de description bas ees sur les graphes [78]. Le mod` ele d ecrit est structur e
en deux niveaux. Le premier d ecrit larchitecture sous la forme dun graphe et le second
d ecrit les styles architecturaux par une grammaire de graphes. L evolution de larchitec-
ture est d ecrite par des r` egles de transformation de graphes. Le mod` ele d enit une ap-
proche formelle bas ee sur un algorithme de v erication permettant de v erier a priori et de
mani` ere statique la consistance des r` egles de l evolution de larchitecture. Cette approche
permet de prouver que les contraintes consid er ees par la description de larchitecture sont
pr eserv ees par ces r` egles [96].
Dans HIRSCH et al. [41], les auteurs reprennent le m eme mod` ele pour la description de
larchitecture et de son evolution dynamique. Ils d ecomposent la description de larchitec-
ture en trois parties. La premi` ere sp ecie les r` egles de la construction de la conguration
initiale. La deuxi` eme partie sp ecie les r` egles r egissant l evolution dynamique de lar-
chitecture. La troisi` eme partie sp ecie les r` egles r egissant la communication. Ces travaux
abordent aussi la probl ematique de la consistance du point de vue de la communication
et des etats de composants. Le cycle de vie des composants (comprenant par exemple
leur activation et leur d esactivation) est simul e en affectant des labels (correspondant ` a
l etat courant des composants) aux nuds des graphes et des r` egles de r e ecriture. La par-
tie d ecrivant la communication est sp eci ee via lintroduction d ev enements (en notation
2.4 Multi-Formalismes 37
CSP, Hoare) et leur prise en compte en etiquetant les arcs des graphes repr esentant les
connexions entre composants [96].
2.3.2 Conclusion
La plupart des techniques formelles offrent les bases n ecessaires pour v erier et valider
la sp ecication dune architecture logicielle [8, 14, 145]. Certains travaux sont certes tr` es
int eressants [83, 78], dans le sens o` u ils ont pu mettre en uvre un syst` eme de preuve qui
v erie que toute op eration de reconguration pr eserve la consistance dune architecture
vis-` a-vis de son style architectural.
Cependant, les grammaires de graphe, comme toute technique formelle, sont bas ees sur
des notations math ematiques qui exigent des connaissances et des expertises assez impor-
tantes. Les grammaires de graphe ` a contexte libre pr esentent quelques limites. Elles ne
permettent pas par exemple de d ecrire des propri et es quantitatives concernant le nombre
maximal dentit es devant exister dans le syst` eme. En plus, il nest pas possible de d ecrire
des propri et es fonctionnelles.
2.4 Multi-Formalismes
Plusieurs travaux de recherche [45, 61, 83, 145] visent ` a combiner diff erents formalismes
(gure 2.17). Lobjectif est de minimiser les inconv enients et daugmenter le pouvoir ex-
pressif en fusionnant les avantages an de d ecrire la dynamique de larchitecture logicielle.
Multi-Formalismes
H
H
H
H
H
H
H
H
H
Z+TG
H
H H
Static
[83]
Dynamic
[83]
UML+ADL
[69] [124] [126]
UML+TF
UML+TF
H
H
H
H
H
H
H
H
H
H
H
H
H
UML+Z
H
H
H
Static
[131] [49]
Dynamic
UML+RdP
H
H
H
Static
[22] [117]
Dynamic
[22] [117]
UML+TG
H
H
H
H
Static
[15] [77] [143]
[61] [145]
Dynamic
[73] [15] [143]
[61] [145] [45]
FIG. 2.17 Les Multi-Formalismes

Etat de lart
2.4.1 Z et la transformation de graphe
Lapproche de LOULOU et al. [83] est bas ee sur une notation mixte. Cette notation a pour
int er et dam eliorer la lisibilit e, de r eduire la complexit e de la description et de prendre
en charge egalement la dynamique du syst` eme. En effet, lapproche utilise la notation
Z [3] pour d ecrire laspect statique de larchitecture et une notation mixte int egrant les
grammaires de graphe et la notation Z pour d ecrire la dynamique structurelle. La nota-
tion mixte, comme le montre la gure 2.18, int` egre une composante graphique et une
composante fonctionnelle. La partie graphique est exprim ee par la notation (grammaire
de graphe). Quant ` a la partie fonctionnelle, elle est li ee aux pr e-conditions impos ees aux
r` egles. Ces pr e-conditions sont exprim ees par la notation Z.
Rtraction Insertion
Contexte
requis
Restriction
Nom_Opration (par
1
, par
2
, , par
n
)
Garde
Partie structurelle
Partie fonctionnelle
Pr-conditions dapplication
FIG. 2.18 La notation mixte
N eanmoins, cette approche ne manque pas de limites. En effet, elle ne prend pas en
consid eration laspect coordination des diff erentes op erations de reconguration. En plus,
la v erication des r` egles se fait manuellement. Aucun outil nest propos e. En plus, comme
toute technique formelle, elle exige une certaine connaissance math ematique.
2.4.2 UML et les techniques formelles
Nous nous int eressons dans cette section aux travaux qui cherchent ` a fusionner les r` egles
de transformation de graphe avec la notation UML.
Dans [15, 77], la notation UML et les r` egles de transformation de graphe sont int egr ees
pour sp ecier laspect statique et laspect dynamique dune architecture logicielle. Les
diagrammes de classes et les diagrammes dobjets sont utilis es pour d ecrire laspect struc-
turel du syst` eme. Les r` egles de transformation de graphe sont utilis ees pour d ecrire la
2.5 Synth` ese 39
dynamique. Cette approche propose aussi la v erication des mod` eles an de prouver la
conformit e dune sp ecication par rapport ` a son style architectural.
Lavantage principal de ces travaux est la combinaison de plusieurs formalismes an
daugmenter le pouvoir expressif des langages. Cependant, les notations propos ees, qui
sont bas ees sur des notations math ematiques difciles ` a appr ehender, noffrent pas des
outils permettant la validation et la v erication de leurs sp ecications. Une telle approche
n ecessite une connaissance approfondie de la notation math ematique.
2.4.3 Conclusion
Ces travaux permettent la combinaison de plusieurs formalismes an d elargir la cou-
verture des diff erents aspects de larchitecture. Cependant, les notations propos ees sont
g en eralement tr` es li ees aux transformations de graphe. La plupart de ces travaux noffrent
pas des outils permettant la validation et la v erication de leurs sp ecications.
2.5 Synth` ese
TAB. 2.1 Comparaison entre les diff erentes techniques de description des architectures
logicielles.
ADL Transformation de graphe Multi-Formalismes UML
A - Premiers travaux qui - Notation tr` es puissante - Combine souvent - Notation tr` es populaire.
v traitent de larchitecture pour d ecrire la dynamique les avantages de - Standard.
a logicielle. structurelle. deux ou plusieurs - Fournit les bases
n - Langages proposant - Notation bas ee sur une notations. n ecessaires pour d ecrire
t des solutions coh erentes approche math ematique. larchitecture logicielle.
a pour d ecrire laspect
g structurel.
e
s
- Plusieurs notations et - Absence de standards. - Les notations propos ees - La dynamique structurelle
L langages. - Exige un certain niveau sont tr` es li ees aux nest pas support ee.
i - Absence de standards. daptitude math ematique. transformations de graphe. - Pas de validation.
m - Aspect dynamique - Exige un certain niveau - Pas doutils sp eciques.
i nest pas bien support e. daptitude math ematique.
t - Quasi absence - Validation manuelle. - Absence doutillages.
e doutillages. - Quasi absence doutils. - Laspect coordination
s nest pas support e.
Selon l etude men ee, nous avons not e (tableau 2.1) que les ADLs souffrent de plusieurs in-
sufsances pour mod eliser larchitecture logicielle. Plusieurs travaux cherchent ` a surmon-
ter ces probl` emes par la d enition dune notation visuelle et uni ee, inspir ee de la notation

Etat de lart
UML. Dautres travaux cherchent ` a utiliser la notation UML mais ces travaux sint eressent
essentiellement ` a laspect structurel alors que laspect dynamique est g en eralement quasi
absent.
Les techniques formelles et plus pr ecis ement les travaux men es sur les transformations
de graphe permettent de d ecrire laspect dynamique dune architecture logicielle mais ces
travaux exigent toujours un certain niveau daptitude math ematique.
Dautres travaux cherchent ` a surmonter les probl` emes des ADLs et de la notation UML
en les combinant avec les transformations de graphe. Cependant, ces travaux ne manquent
pas de probl` emes. Les notations propos ees sont tr` es li ees aux transformations de graphe,
difciles ` a appr ehender alors que laspect coordination est toujours absent.
Nous avons not e egalement que peu de travaux pr esentent un processus clair, un environ-
nement complet et convivial fait d efaut m eme si des prototypes existent.
2.6 Pr esentation des m ethodes agiles
Cr eer des applications r epondant aux attentes des utilisateurs est un des enjeux de la
conception des architectures logicielles. Ces architectures doivent etre analys ees, concues,
mises en uvre et doivent etre exibles et ais ement maintenables au rythme des change-
ments des besoins. Une description visuelle commune de larchitecture aide egalement
les analystes, les architectes et les d eveloppeurs ` a rester align es lors dune activit e de
r eutilisation ou de reconguration. Les m ethodes agiles [103] sont des m ethodes de
gestion de projets informatiques et de d eveloppement qui entrent dans ce contexte et
cherchent ` a proposer des solutions de mod elisation. Elles ont pour priorit e la satisfac-
tion r eelle du besoin du client, et non dun contrat etabli pr ealablement. Elles rendent
le travail de d eveloppement plus facile et portent principalement leur attention sur les
ressources humaines [103]. Les m ethodes agiles connaissent un int er et croissant depuis
quelques ann ees car elles apportent des solutions it eratives, incr ementales et bas ees sur
laccepation du changement.
Comme le montre la gure 2.19, il existe une vari et e de m ethodes agiles. Les principales
m ethodes sont : Dynamic Software Development Method (DSDM) [134], Rapid Appli-
cation Development (RAD), eXtreme Programming (XP) [71, 43, 35], Rational Uni-
ed Process (RUP) [74, 75], Two Tracks Unied Process (2TUP) [127]. Ces m ethodes
sont globalement similaires et la plupart des techniques quelles pr econisent sont com-
munes. Une etude des principes propos es r ev` ele un tronc commun issu des racines du
RAD. Seules des techniques compl ementaires les unes aux autres ou mieux adapt ees ` a
des typologies et ` a des tailles de projets sp eciques les diff erencient. Nous pr esentons
dans cette section les m ethodes les plus r ecentes et les plus utilis ees.
2.6 Pr esentation des m ethodes agiles 41
M ethodes agiles
H
H
H
H
H
X
X
X
X
X
X
X
X
X
X
DSDM
[134]
RAD
[131] [49]
XP
[71] [43] [35]
RUP
[74] [75]
2TUP
[127]
FIG. 2.19 M ethodes agiles
2.6.1 UP - Unied Process
Le processus uni e UP (Unied Process) est un processus de d eveloppement logi-
ciel construit sur UML pour la description de larchitecture logicielle. Il est it eratif et
incr emental, centr e sur larchitecture, conduit par les cas dutilisation et orient e vers la
diminution des risques. Cest un patron de processus pouvant etre adapt e ` a une large
classe de syst` emes logiciels et ` a diff erents domaines dapplication [65]. La gestion dun
tel processus est organis ee suivant quatre phases : pr e- etude (inception), elaboration,
construction et transition. Ses activit es de d eveloppement sont d enies par cinq disci-
plines fondamentales qui d ecrivent la sp ecication des besoins, lanalyse et la conception,
limpl ementation, le test et le d eploiement [127]. Un processus UP doit etre :
It eratif et incr emental.
Pilot e par les risques.
Construit autour de la cr eation et de la maintenance dun mod` ele, plut ot que de la pro-
duction massive de documents.
Orient e composant.
Orient e utilisateur.
Il existe plusieurs travaux qui adaptent le processus uni e comme d emarche de
d eveloppement. Parmi les plus connues, nous citons RUP et 2TUP.
2.6.2 RUP - Rational Unied Process
RUP (Rational Unied Process) est un processus de d eveloppement par it erations, promu
par la soci et e Rational Software. Il se caract erise par une approche globale nomm ee Vue
4+1. Les cinq composants de cette vue sont : la vue des cas dutilisation, la vue logique,
la vue dimpl ementation, la vue de processus et la vue de d eploiement [74]. RUP offre un
processus it eratif, incr emental et tient compte des besoins des utilisateurs. Il peut etre vu
comme une impl ementation de la d emarche g en erique UP, compl et ee par une s erie dou-
tils informatiques ainsi quune documentation des processus d ecrivant ces outils. Mais
ce processus reste tr` es proc edural et li e ` a des outils bien particuliers qui ont tendance ` a
lalourdir [138].

Etat de lart
2.6.3 2TUP - 2 Tracks Unied Process
2TUP (2 Tracks Unied Process) est un processus UP, d edi e ` a la mod elisation des
syst` emes dinformation. Il apporte une r eponse aux contraintes de changement continuel
impos e aux syst` emes dinformation. En ce sens, il renforce le contr ole sur les capacit es
d evolution et de correction de tels syst` emes. Il int` egre egalement la notion de composant
selon diff erentes granularit es : composants m etier, composants logiciels, etc. [127, 130].
Laxiome fondateur de ce processus est de diviser la d emarche en deux branches : fonc-
tionnelle (approche par les fonctionnalit es) et technique ( etude de leur mise en uvre).
Le b en ece attendu est de pouvoir r eutiliser laspect fonctionnel en cas de changement
darchitecture technique, et de pouvoir r eutiliser laspect technique en cas d evolution
du fonctionnel (ou tout simplement pour d evelopper une autre application pr esentant les
m emes contraintes darchitecture).
Capture des besoins
fonctionnels
Analyse
Capture des besoins
techniques
Conception gnrique
Conception prliminaire
Conception dtaille
Codage et tests
Recette
Contraintes
fonctionnelles
Contraintes
techniques
Branche
fonctionnelle
Branche
technique
Prototype
FIG. 2.20 Le processus 2TUP
A lissue des evolutions du mod` ele fonctionnel et de larchitecture technique, la r ealisation
du syst` eme consiste ` a fusionner les r esultats des deux branches. Cette fusion conduit ` a
lobtention dun processus de d eveloppement en forme de Y qui dissocie les aspects tech-
niques des aspects fonctionnels. Illustr e par la gure 2.20, le processus en Y sarticule
autour de 3 phases : technique, fonctionnelle et de r ealisation.
2TUP est construit sur UML. Il est it eratif, centr e sur larchitecture et conduit par les cas
dutilisation.
2.7 Conclusion 43
2.6.4 MDA : Model Driven Architecture
MDA [67] tend ` a produire une approche standard de lutilisation dUML en tant que lan-
gage de mod elisation. Le standard MDA fait partie des travaux de lOMG au m eme titre
que CORBA (Common Object Request Broker Architecture) et UML et a fait lobjet,
ces deux derni` ere ann ees, dune forte activit e dinnovation. Lobjectif de MDA est donc
de d enir une plateforme capable dex ecuter un mod` ele UML, assorti de r` egles OCL et
daspects, et ainsi rendu ex ecutable. MDA propose une architecture en trois sous-mod` eles
qui sont le CIM (Computation Independent Model), le PIM (Platform Independant Mo-
del) et le PSM (Platform Specic Model). Le premier permet de mod eliser les exigences
du client sans entrer dans les d etails de r ealisation de lapplication ni sur les traitements.
Le deuxi` eme permet de mod eliser un comportement cible sans se soucier des technolo-
gies sous-jacentes et particuli` erement de loutil MDA utilis e an de garantir ` a terme un
premier niveau dinterop erabilit e entre les outils. Le troisi` eme mod` ele est facultativement
d ecrit en UML, car il repr esente limpl ementation des directives de conception vis-` a-vis de
la plateforme vis ee. Suivant la strat egie adopt ee par l editeur de loutil MDA, le PSM peut
g en erer du code interm ediaire ou bien rendre le mod` ele directement ex ecutable au travers
de moteurs dinterpr etation. Le courant MDA repr esente un potentiel de d eveloppement
important pour UML, car il apporte ` a ce dernier une valorisation encore plus signica-
tive aux projets informatiques. Cest pourquoi UML 2.0 apporte un soutien particulier ` a
ce projet en renforcant la formalisation du m eta-mod` ele et du langage de description de
r` egles OCL [127].
2.7 Conclusion
Nous avons pr esent e, dans ce chapitre, l etat de lart des travaux relatifs aux diff erentes ap-
proches permettant la description des architectures logicielles. Nous avons pr esent e leurs
avantages ainsi que leurs limites. An de combler ce manque, nous proposerons, dans le
chapitre qui suit, notre approche qui consiste ` a apporter des solutions pour la mod elisation
de la dynamique des architectures logicielles.

Etat de lart
3
Prol UML pour d ecrire la dynamique des
architectures logicielles
Apr` es l etude des diff erentes techniques utilis ees pour d ecrire larchitecture logicielle,
nous pr esentons dans ce qui suit, notre approche qui cherche ` a combiner plusieurs for-
malismes en protant de leurs avantages et en essayant dapporter des solutions ` a leurs
limites. Notre approche est inspir ee des ADLs qui constituent la base de tout travail sur
larchitecture logicielle. Elle tire prot de la puissance des grammaires de graphe pour
d ecrire la dynamique structurelle et elle offre une notation uni ee graphique bas ee sur la
notation UML 2.0.
Dans nos travaux de th` ese, nous nous concentrons sur la mod elisation de la dynamique
de larchitecture logicielle au niveau conceptuel (design time). Nous traitons essentielle-
ment le probl` eme de l evolution des exigences repr esentant un changement dans lactivit e
soutenue par le syst` eme mod elis e. Nous associons des op erations de reconguration ar-
chitecturale ` a ces situations pour adapter le syst` eme ` a ces changements.
Notre approche, bas ee sur un prol UML [59, 60], permet de d ecrire la dynamique des
architectures logicielles. Elle est bas ee sur trois m eta-mod` eles, comme le montre la gure
3.1. Le premier (Quadrillage en pointill e avec couleur rouge) permet de d ecrire le style ar-
chitectural dune architecture logicielle. Il d ecrit lensemble des types de composants qui
constituent le syst` eme, les types de connexions entre eux, ainsi que les contraintes dordre
architectural. Le deuxi` eme (Rayures verticales avec couleur vert) permet de d ecrire la
dynamique et l evolution de larchitecture en termes dop erations de reconguration que
peuvent avoir une architecture tout au long de son cycle de vie. Dans notre approche, nous
nous int eressons uniquement ` a la dynamique structurelle (ajout et/ou suppression de com-
posants et/ou de connexions). Le troisi` eme m eta-mod` ele (Briques diagonales avec couleur
46 Prol UML pour d ecrire la dynamique des architectures logicielles
bleu) permet de d ecrire la coordination. Il d ecrit lenchanement et lordre dex ecution des
diff erentes op erations de reconguration.
Dynamic Architecture Profile
OCL
1
expressed
stereotype
metaclass
Constraint
+precondition
stereotype 1 C t Ki d
Delegation
enumeration
Assembly
1
1..*
2..*
metaclass
Component
stereotype
Guards
stereotype
Require & Delete
stereotype
Insert
stereotype
1
1
1
metaclass
Connector
1..*
ConnectorKind
h
a
s
0..*
1..*
0..*
1
1
metaclass
Port
metaclass
1..*
+/required +/provided
0..* 0..*
stereotype
ReconfigurationOperationFeature
Require & Preserve
1
stereotype
ArchitecturalStyleFeature
stereotype
ArchitecturalStyle 2
stereotype
ArchitecturalStyleName
metaclass
Interface
stereotype
Architecture
stereotype
stereotype
ReconfigurationOperation
1
ArchitecturalStyle
1
1..* 1
2
stereotype
ReconfigurationProtocolName
t t
1
stereotype
ReconfigurationProtocol
1
1
ReconfigurationOperationName
1
stereotype
ReconfigurationOperationNode
1..*
stereotype
ReconfigurationProtocolFeature
1..* 1..*
metaclass
Link
metaclass
ControlNode
1 1
metaclass
DecisionNode
metaclass
InitialNode
metaclass
FinalNode
1 1..* 1..*
metaclass
SynchronousNode
1..*
FIG. 3.1 Le prol de larchitecture dynamique
3.1 Style architectural
La prise en compte de la complexit e croissante des syst` emes distribu es, dynamiques et
evolutifs et les contraintes inh erentes de ces syst` emes font quil est n ecessaire de pouvoir
disposer dun support permettant une matrise ne du processus de d eveloppement et une
gestion s ure des diff erents el ements utilis es par le syst` eme. Pour cela, nous proposons un
style architectural, ` a base de composants, pour la d enition des types de composants pou-
vant intervenir dans le syst` eme et des connexions entre ces composants. Il d enit aussi
lensemble des propri et es architecturales qui doivent etre satisfaites par toutes les congu-
rations appartenant ` a ce style. Le m eta-mod` ele du style architectural etend le diagramme
de composants dUML 2.0. Il est d ecrit par un ensemble de concepts caract erisant la struc-
ture dune architecture logicielle.
3.1.1 M eta-mod` ele
La structure du m eta-mod` ele de style architectural est d ecrite par la gure 3.2.
OCL
stereotype stereotype
stereotype
1
1
metaclass
Constraint
expressed
+precondition
1..*
yp
Guards
yp
ArchitecturalStyle
1 stereotype
2..*
metaclass
C t
metaclass
Connector
metaclass
Port
1..*
1..*
ConnectorKind
Component
h
a
s
0..*
1
metaclass
Interface
0..* 0..*
Delegation
enumeration
Assembly
Thse
2
FIG. 3.2 Le m eta-mod` ele du style architectural
Le st er eotype ArchitecturalStyle est compos e de trois st er eotypes ArchitecturalSty-
leName, Guards et ArchitecturalStyleFeature. Le st er eotype ArchitecturalStyle-
Name d ecrit le nom du syst` eme ` a sp ecier. Le st er eotype Guards d ecrit les contraintes
de larchitecture que le syst` eme doit respecter durant son evolution. Ces contraintes sont
exprim ees avec le langage OCL (Object Constraint Language). Le st er eotype Archi-
tecturalStyleFeature est compos e par les m eta-classes Component et Connector. Il
sp ecie lensemble des types de composants et de connecteurs qui constituent le style ar-
chitectural dun syst` eme. Cette sp ecication est d ecrite en utilisant la notation UML 2.0.
La m eta-classe Component, eventuellement compos ee de plusieurs composants,
repr esente une partie modulaire dun syst` eme. Chaque Component a une ou plusieurs
interfaces fournies et/ou requises expos ees par linterm ediaire de ports. La m eta-classe
Port repr esente le point dinteraction pour un composant. La cardinalit e [1..*] entre
Component et Port exprime quun composant peut avoir un ou plusieurs ports. La
m eta-classe Interface repr esente linterface dun composant. Une interface peut etre
soit de type fourni +/provided ou requis +/required. La m eta-classe Connector d enit
un lien qui rend possible la communication entre deux ou plusieurs composants. La
m eta-classe ConnectorKind sp ecie deux types de connecteurs. Les connecteurs de
d el egation Delegation Connector et les connecteurs dassemblage Assembly Connec-
tor. Un connecteur de type Delegation exprime un lien entre deux composants partant
dune interface requise vers une interface requise ou dune interface fournie vers une in-
terface fournie. Un connecteur de type Assembly exprime un lien entre deux composants
partant dune interface requise vers une interface fournie.
3.1.2 Mod` ele
Pour d ecrire le style architectural, nous proposons une nouvelle notation graphique d ecrite
dans la gure 3.3. Cette notation sera d etaill ee avec un exemple dans la section 3.4.1.
Le nom du systme
spcifier
Le symbole du style
Extension du diagramme de composants : les nuds
Guards
Contraintes d'ordre architectural exprimes en OCL
reprsentent les types des composants logiciels et les
connecteurs reprsentent le lien entre les types de composants
Thse
Extension du diagramme de composants avec les nuds
reprsentent des composants logiciels et les connecteurs
reprsentent le lien entre ces composants
FIG. 3.3 Le mod` ele du style architectural
Cette notation est compos ee de trois parties :
ArchitecturalStyleName : pour indiquer le nom du syst` eme ` a sp ecier.
ArchitecturalStyleFeature : pour d ecrire le style architectural. Nous sp ecions len-
semble des types de composants et des connecteurs entre ces types. La sp ecication est
faite en utilisant la notation UML 2.0.
Guards : pour pr eciser les contraintes dordre architectural que le syst` eme doit respecter
durant son evolution. Ces contraintes sont exprim ees dans le langage OCL.
3.2 Op eration de reconguration 49
3.2 Op eration de reconguration
Tout au long de son cycle de vie, larchitecture logicielle peut evoluer en ex ecutant des
op erations de reconguration. Ces op erations font evoluer larchitecture dune congu-
ration ` a une autre. L evolution de larchitecture doit etre r ealis ee sans perturber le fonc-
tionnement du syst` eme. Pour cela, nous proposons un deuxi` eme m eta-mod` ele permet-
tant de d ecrire les diff erentes op erations de reconguration assurant l evolution de lar-
chitecture dune application en termes dajout et/ou de suppression de composants et/ou
de connexions. Ce m eta-mod` ele qui etend le m eta-mod` ele du style architectural, est ca-
ract eris e par un ensemble de concepts permettant de d ecrire la dynamique structurelle
dune architecture logicielle.
Les concepts d ecrits dans le m eta-mod` ele du style architectural sont pris en consid eration
dans le m eta-mod` ele op eration de reconguration. Dans ce dernier, nous ajoutons dautres
st er eotypes permettant de d ecrire la dynamique structurelle. La structure du m eta-mod` ele
op eration de reconguration est d ecrite par la gure 3.4.
stereotype
stereotype
R fi ti O ti
OCL
expressed
stereotype
G d
metaclass
Constraint
1..*
1
1
+precondition
stereotype
ReconfigurationOperationFeature
stereotype
Require & Delete
stereotype
Insert
ReconfigurationOperation Guards
1
1
1
stereotype
Require & Preserve
1
0 *
metaclass
Component
1..*
0..*
metaclass
Port
0..
1..*
0..* 0..*
Component
metaclass
Connector
ConnectorKind
enumeration
h
a
s
1
metaclass
Interface
0..
Delegation
enumeration
Assembly
Thse
2
FIG. 3.4 Le m eta-mod` ele des op erations de reconguration
Le st er eotype RecongurationOperation d ecrit les diff erentes op erations de recon-
guration. Il est compos e des st er eotypes RecongurationOperationName, Recongu-
rationOperationFeature et Guards. Le st er eotype RecongurationOperationName
d ecrit le nom de lop eration de reconguration ` a sp ecier. Le st er eotype Guards
d ecrit les contraintes de larchitecture que le syst` eme doit respecter durant lex ecution
de lop eration de reconguration. Ces contraintes sont exprim ees avec le langage OCL.
Le st er eotype RecongurationOperationFeature est compos e de trois st er eotypes :
Le st er eotype require & preserve d ecrit la partie non modi ee durant lop eration
de reconguration.
Le st er eotype Insert d ecrit la partie ` a ajouter dans le syst` eme durant lop eration de
reconguration.
Le st er eotype require & delete d ecrit la partie ` a supprimer durant lop eration de
reconguration.
3.2.2 Mod` ele
Pour d ecrire laspect dynamique, nous proposons, comme le montre la gure 3.5, une
nouvelle notation. Cette notation sera pr esent ee avec plus de d etail dans la section 3.4.2.
require & delete require & preserve insert
Le nom de lopration
de reconfiguration
Le symbole de lopration
de Reconfiguration
La partie du systme La partie du systme La partie du systme
Guards
La partie du systme
non modifiable
La partie du systme
supprimer
La partie du systme
insrer
Contraintes d'ordre architectural exprimes en OCL
Thse
FIG. 3.5 Le mod` ele dune op eration de reconguration
Cette notation est compos ee de cinq parties :
RecongurationOperationName : pour enoncer le nom de lop eration de recongu-
ration ` a ex ecuter.
Require & delete : pour pr eciser la partie du syst` eme ` a supprimer durant lop eration
de reconguration.
3.3 Protocole de reconguration 51
Insert : pour pr eciser la partie ` a ajouter dans le syst` eme durant lop eration de
reconguration.
Require & preserve : pour pr eciser la partie non modi ee durant lop eration de
reconguration.
Guards : pour caract eriser les contraintes architecturales que le syst` eme doit respec-
ter durant son evolution. Ces contraintes sont exprim ees dans le langage OCL.
La repr esentation dynamique que nous avons propos ee est inspir ee des transformations de
graphe et plus pr ecis ement de la notation . La gure 3.6 et le tableau 3.1 pr esente une
correspondance entre les deux notations.
Guards
Thse
Rtraction Insertion
Contexte requis
Restriction
Garde
Nom de lopration de reconfiguration
FIG. 3.6 La correspondance entre la notation et la notation propos ee
TAB. 3.1 Tableau de correspondance entre la notation et la notation propos ee
Notation Notre notation
Nom de lop eration de reconguration RecongurationOperationName
R etraction Require & delete
Contexte requis Require & preserve
Insertion Insert
Restriction + Garde Guards
3.3 Protocole de reconguration
La description du style architectural et des op erations de reconguration est n ecessaire
mais insufsante pour sp ecier l evolution dune architecture logicielle. Pour cela, nous
ajoutons le protocole de reconguration an de d ecrire lorganisation et lenchanement
entre les diff erentes op erations de reconguration d ecrites au niveau dynamique. Ce prol
est bas e sur la notation UML 2.0 et etend le diagramme dactivit es.
La structure du protocole de reconguration est d ecrite par la gure 3.7.
stereotype
stereotype
1
stereotype
ReconfigurationProtocol
1
stereotype
ReconfigurationOperationNode
1..*
metaclass
ControlNode
1..* 1..*
metaclass
Link
1 1
metaclass
DecisionNode
metaclass
InitialNode
metaclass
FinalNode
1 1..* 1..*
metaclass
SynchronousNode
1..*
Thse
FIG. 3.7 Le m eta-mod` ele de protocole de reconguration
Le st er eotype RecongurationProtocol est compos e des st er eotypes Reconguration-
ProtocolName et RecongurationProtocolFeature. Le st er eotype Reconguration-
ProtocolName d ecrit le nom du syst` eme ` a sp ecier. Le st er eotype Reconguration-
ProtocolFeature est compos e par le st er eotype RecongurationOperationNode et les
deux m eta-classes ControlNode et Link. La m eta-classe ControlNode est utilis ee
pour coordonner les ots entre les diff erentes op erations de reconguration. Nous utili-
sons quatre nuds : InitialNode, DecisionNode, SynchronousNode et FinalNode.
La m eta-classe Link etablit le lien entre ControlNode et RecongurationOperation-
Node.
3.3.2 Mod` ele
Pour d ecrire le protocole de reconguration, nous proposons une nouvelle notation telle
que pr esent ee dans la gure 3.8. Cette notation permet de d ecrire lenchanement entre
les op erations de reconguration. Les nuds de contr ole ControlNode sont utilis es pour
synchroniser entre les diff erentes op erations de reconguration RecongurationOpera-
tionNode et les liens Link permettent d etablir le lien entre les op erations de recon-
3.4 Illustration 53
guration et les nuds de contr ole. Cette notation sera d etaill ee avec un exemple dans la
section 3.4.3.
Le nom de protocole de
reconfiguration
Le symbole de protocole
de Reconfiguration
Le diagramme d'activits spcifie le plan d'excution de
l'ensemble des oprations de reconfiguration
Thse
FIG. 3.8 Le mod` ele de protocole de reconguration
3.4 Illustration
An dillustrer notre travail, nous avons choisi un exemple qui a egalement servi pour
illustrer les formalismes propos es dans [78] et [83]. Il sagit dun syst` eme logiciel de
contr ole de patients PMS (Patient Monitoring System) permettant aux inrmi` eres de
contr oler leurs patients ` a distance au sein dune clinique. A chaque patient, un contr oleur
doit etre attach e ` a son lit permettant de prendre des mesures. Gr ace ` a ce contr oleur, chaque
inrmi` ere peut v erier l etat de ses patients en demandant ` a distance les informations
concernant la tension, la temp erature, etc. En contre partie, lorsque l etat dun patient de-
vient anormal, cest ` a dire quand lune des donn ees sort de sa limite, le contr oleur de
lit envoie un signal dalarme ` a linrmi` ere responsable. Apr` es avoir expliqu e le prin-
cipe sous-jacent de ce syst` eme, nous donnons maintenant la description informelle de
son architecture. A chaque service de la clinique (p ediatrie, cardiologie, maternit e, etc.)
est associ e un service d ev enement (EventService) pour g erer les communications entre
les inrmi` eres (Nurses) et les contr oleurs de lit (Patients) rattach es au service en ques-
tion. Chaque inrmi` ere demande des informations relatives ` a ses patients en envoyant une
requ ete au service d ev enement auquel elle est li ee. Ce service prend en charge cette de-
mande et la transmet aux patients concern es ou plut ot ` a leur contr oleur de lit. Lorsque
l etat dun patient devient anormal, son contr oleur de lit envoie un signal dalarme au ser-
vice d ev enement auquel il est rattach e. Ce service transmet par cons equent ce signal ` a
linrmi` ere responsable.
Le PMS est un syst` eme evolutif poss edant les propri et es architecturales suivantes :
Le nombre maximal de services est de 3.
Un service contient au maximum 5 inrmi` eres.
Un service contient au maximum 15 patients.
Un patient doit etre toujours affect e ` a un service unique.
Le service auquel est affect e le patient doit contenir au moins une inrmi` ere.
Une inrmi` ere doit etre attach ee ` a un seul service.
Dans ce qui suit, nous pr esentons une mod elisation possible de ce syst` eme selon le prol
que nous avons propos e. Les contraintes OCL que nous pr esentons, dans les diff erents
exemples, sont ecrites et valid ees avec loutil USE [55].
3.4.1 Mod elisation du style architectural
En se basant sur la notation propos ee pour d ecrire le style architectural, nous pr esentons
dans la gure 3.9 le style architectural du syst` eme PMS. Le nom du style Architec-
turalStyleName est PMS. Dans la partie ArchitecturalStyleFeature et selon la nota-
tion UML 2.0, notre syst` eme contient trois types de composants (EventService, Patient et
Nurse).
ArchitecturalStyleName PMS
EventService
Patient Nurse
ve Se v ce
Guards
context EventService
inv NbEventService:
EventService.allInstances size <= 3 and EventService.allInstances size >0
inv NbEventServiceNurse:
EventService.allInstances forAll(es:EventService | ((es.nurse size <=5) and
(es.patient size <=15)))
context Patient
inv NbPatientEventService:
Patient.allInstances forAll(p:Patient | ((p.eventService size =1) and (p.nurse size =1)))
context Nurse
inv NbNurseEventService:
Nurse allInstances forAll(n: Nurse | ((n eventService size =1) and (n patient size <=3))) Nurse.allInstances forAll(n: Nurse | ((n.eventService size =1) and (n.patient size <=3)))
inv ExNurseEventService:
EventService.allInstances forAll(es | es.patient notEmpty implies es.nurse notEmpty)
FIG. 3.9 Le style architectural du PMS
Chaque type de composant contient quatre interfaces : deux fournies et deux requises. Le
type Patient et le type Nurse communiquent ` a travers le type EventService.
Dans la partie Guards nous sp ecions avec le langage OCL les propri et es architectu-
rales. Le syst` eme peut contenir au maximum trois instances de type EventService. Chaque
instance de EventService peut contenir entre z ero et cinq instances de type Nurse et peut
3.4 Illustration 55
inclure entre z ero et quinze instances de type Patient. Une instance de type Nurse peut
soccuper au plus de trois instances de type Patient.
La gure 3.10 d ecrit une conguration possible de larchitecture PMS. Cette congura-
tion contient une instance de composant de type EventService, une instance de composant
de type Patient et une instance de composant de type Nurse. Ces instances sont intercon-
nect ees par des instances de type connecteur.
z:Patient y:Nurse
x:EventService
FIG. 3.10 Une conguration possible du syst` eme PMS
3.4.2 Mod elisation des op erations de reconguration
En se basant sur la notation propos ee pour d ecrire le mod` ele dynamique, nous pr esentons,
dans cette section, la sp ecication des diff erentes op erations de reconguration permettant
de faire evoluer notre syst` eme PMS tout en tenant compte des propri et es d ecrites dans le
style architectural.
3.4.2.1 Insertion dun service d ev enement
Cette op eration de reconguration permet dins erer une instance de composant de type
EventService. La mod elisation de cette op eration de reconguration, avec notre nouvelle
notation, est donn ee par la gure 3.11.
Le nom de lop eration de reconguration RecongurationOperationName est
Insert EventService(x)
Dans la partie insert nous pr esentons linstance de EventService ` a ajouter dans le
syst` eme. Dans cette op eration nous navons rien ` a supprimer, cest pourquoi la partie
require & delete est vide. En plus, pour linsertion de cette instance de composant nous
navons besoin daucune instance de composant dans la partie require & preserve.
Pour ex ecuter correctement linsertion dun EventService, il faut v erier la contrainte
OCL : EventService.allInstances size < 3 donn ee dans la partie
Guards qui traduit que le nombre dinstance de type EventService doit etre strictement
inf erieur ` a 3.
ReconfigurationOperationName Insert_EventService(x)
x:EventService
Guards
context EventService::InsertEventService(x : EventService) : Boolean
pre InsertES: EventService allInstances size < 3 pre InsertES: EventService.allInstances size < 3
FIG. 3.11 Insertion dun EventService
La gure 3.12 d ecrit une conguration possible de larchitecture PMS apr` es lex ecution
de lop eration de reconguration Insert EventService.
z:Patient y:Nurse
x:EventService e:EventService
FIG. 3.12 Une conguration possible apr` es linsertion dun EventService
3.4.2.2 Insertion dun patient
Patient et de la lier ` a une instance de composant de type EventService. Pour ex ecuter cette
op eration, il faut mettre une instance de type Patient dans la partie insert. Linsertion
dun patient n ecessite lexistence dune instance de type Nurse connect ee ` a une instance
de type EventService. Ces instances doivent etre repr esent ees dans la partie require &
preserve.
Lex ecution de cette op eration est conditionn ee par trois conditions pr esent ees dans la
partie Guards : il faudrait dabord quil y ait au moins une inrmi` ere appartenant ` a ce
service pour pouvoir soccuper du nouveau patient : x.nurse size > 0 . En
3.4 Illustration 57
plus, il faudrait v erier que le service en question ne contient pas d ej` a quinze patients :
x.patient size < 15 et que le nombre de patient pour linrmi` ere en ques-
tion est strictement inf erieur ` a 3 : y.patient size < 3 .
ReconfigurationOperationName Insert_Patient(x,y,z)
x:EventService
y:Nurse z:Patient
Guards
y:Nurse z:Patient
context Patient::InsertPatient(x : EventService, y : Nurse, z : Patient) : Boolean
pre InsertP: x.nurse size > 0 and x.patient size < 15 and y.patient size < 3
FIG. 3.13 Insertion dun Patient
de lop eration de reconguration Insert Patient.
z:Patient y:Nurse
x:EventService
p:Patient
e:EventService
FIG. 3.14 Une conguration possible apr` es linsertion dun Patient
3.4.2.3 Insertion dune inrmi` ere
Nurse et de la lier ` a une instance de composant de type EventService quelconque (devant
exister dans le syst` eme) comme pr ecis e dans la partie Guards. Pour appliquer cette
r` egle, on doit v erier que linstance de composant EventService en question ne contient
pas d ej` a cinq instances de Nurse : x.nurse size < 5 .
ReconfigurationOperationName Insert_Nurse(x,y)
x:EventService
y:Nurse
Guards
context Nurse::InsertNurse(x : EventService, y : Nurse) : Boolean
pre InsertN: EventService.allInstances size > 0 and x.nurse size < 5
FIG. 3.15 Insertion dune Inrmi` ere
de lop eration de reconguration Insert Nurse.
z:Patient y:Nurse
x:EventService
p:Patient n:Nurse
e:EventService
FIG. 3.16 Une conguration possible apr` es linsertion dune Inrmi` ere
3.4.2.4 Transfert dun patient
Un patient peut quitter un service vers un autre (sans pour autant etre supprim e du
syst` eme). Cette op eration de reconguration permet de transf erer une instance de com-
posant de type Patient vers une instance de composant de type EventService. Pour ce
faire, nous supprimons une connexion repr esent ee dans la partie require & delete et
nous ajoutons une nouvelle connexion dans la partie insert.
Le transfert dune instance de type Patient est ex ecut e seulement sil y a une instance
Nurse dans le nouveau EventService ( y :Nurse ) dont le nombre dinstance de type
Patient en charge est strictement inf erieur ` a trois : y.patient size < 3 .
En plus, il faut v erier que le nombre dinstance de type Patient connect e au nou-
veau EventService est strictement inf erieur ` a 15 : w.patient size < 15 . La
repr esentation de cette op eration de reconguration est donn ee par la gure 3.17.
3.4 Illustration 59
ReconfigurationOperationName Transfert_Patient(x,w,z,y)
z:patient
y:Nurse
E tS i
w:EventService
Guards
context Patient::TransfertPatient(x : EventService, w: EventService, z : Patient, y : Nurse) : Boolean
pre TransfertP: w.patient size < 15 and w.nurse size > 0 and y.patient size < 3
x:EventService
FIG. 3.17 Transfert dun Patient
3.4.2.5 Transfert dune inrmi` ere
ReconfigurationOperationName Transfert_Nurse(y,x,w)
y:Nurse
x:EventService
Guards
context Nurse::TransfertNurse(x : EventService w: EventService y : Nurse) :
w:EventService
context Nurse::TransfertNurse(x : EventService, w: EventService, y : Nurse) :
Boolean pre TransfertN: y.patient size = 0 and w.nurse size < 5
FIG. 3.18 Transfert dune Inrmi` ere
Une inrmi` ere peut quitter un service vers un autre (sans pour autant etre supprim ee
du syst` eme). Comme le montre la gure 3.18, cette op eration de reconguration per-
met de transf erer une instance de composant de type Nurse vers une instance de compo-
sant de type EventService seulement si elle na pas une instance Patient en occupation
y.patient size = 0 et que la nouvelle instance de EventService contient
moins de cinq instances de type Nurse : w.nurse size < 5 .
3.4.3 Mod elisation du protocole de reconguration
En se basant sur la notation propos ee pour d ecrire le protocole de reconguration, nous
d ecrivons, comme le montre la gure 3.19, un cas possible de lenchanement et de lordre
dex ecution des diff erentes op erations de reconguration.
ReconfigurationProtocolName PMS
Insert_EventService
Insert_Patient
Insert_Nurse
Transfert_Nurse
Transfert_Patient
FIG. 3.19 Le protocole de reconguration du syst` eme PMS
En effet, et selon lexemple du PMS, la premi` ere op eration de reconguration ` a ex ecuter
3.5 Conclusion 61
est Insert EventService. Lop eration de reconguration Insert Patient ne peut etre
ex ecut ee que si lop eration de reconguration Insert Nurse ` a et e d ej` a ex ecut ee.
Lex ecution de lop eration Transfert Patient ne peut etre ex ecut ee que si lop eration
Insert Patient ` a et e d ej` a ex ecut ee. Lex ecution de lop eration Transfert Nurse est
ex ecut ee apr` es son insertion. Ces op erations de reconguration peuvent etre ex ecut ees
une ou plusieurs fois tant que les contraintes OCL mentionn ees dans le style architectural
et dans les op erations de reconguration sont v eri ees.
3.5 Conclusion
Nous avons propos e, dans ce chapitre, une approche de mod elisation bas ee sur un prol
UML. Notre approche traite la mod elisation de la dynamique de larchitecture logicielle
au niveau conceptuel (design time). Nous avons trait e essentiellement l evolution des exi-
gences repr esentant un changement dans lactivit e du syst` eme mod elis e. Nous avons as-
soci e des op erations de reconguration architecturales ` a ces situations pour adapter le
syst` eme ` a ces changements.
Le prol, que nous avons propos e, comporte trois m eta-mod` eles. Le premier etend le
diagramme de composants et d ecrit la structure de larchitecture en termes de type de
composants et de connexions. Le deuxi` eme etend le premier m eta-mod` ele et d ecrit la
dynamique structurelle de larchitecture en termes dop erations de reconguration. Le
troisi` eme m eta-mod` ele etend le diagramme dactivit es et permet de d ecrire lenchanement
et lordre dex ecution des op erations de reconguration.
Notre approche a et e valid ee par plusieurs etudes de cas. Nous avons d etaill e dans cette
th` ese le cas du syst` eme logiciel de contr ole de patients PMS (Patient Monitoring System).
Les contraintes OCL que nous avons pr esent e, dans les diff erents exemples, ont et e ecrites
et valid ees avec loutil USE.
Durant la phase de mod elisation, le concepteur peut tomber facilement dans lerreur. Lob-
jectif du chapitre suivant est de proposer une approche de validation bas ee sur deux parties.
La premi` ere, appel ee intra-validation, permet de v erier la coh erence entre chaque m eta-
mod` ele et son mod` ele. La deuxi` eme, appel ee inter-validation, permet de v erier le passage
dun mod` ele vers un autre. Ces deux validations sont utilis ees pour faciliter lidentication
des eventuelles incoh erences et pour d etecter toute utilisation incorrecte des concepts de
notre prol.
4
Approche de Validation
Vu la complexit e et le co ut croissant de d eveloppement des architectures logicielles,
une nouvelle orientation des travaux de recherches consiste ` a ex ecuter des t aches de
v erication et de validation des mod` eles conceptuels avant davancer profond ement dans
le processus de d eveloppement [24, 11]. En effet, toute erreur dans la mod elisation de
larchitecture logicielle peut nuire au bon fonctionnement du syst` eme. Ainsi, la valida-
tion consiste essentiellement ` a contr oler si la mod elisation de larchitecture logicielle est
exempte derreurs.
Dans notre approche [60, 59], la mod elisation de larchitecture est guid ee par un prol
UML bas e sur trois m eta-mod` eles et trois mod` eles utilis es pour d ecrire larchitecture lo-
gicielle. La question qui se pose est donc : les sp ecications g en er ees ` a partir des mod` eles
sont-elles conformes ` a leurs m eta-mod` eles ?
Pour r epondre ` a cette question, nous proposons une approche de validation. Cette vali-
dation offre deux sc enarios. Le premier, appel e intra-validation, est bas e sur des r` egles
de validation permettant de v erier la coh erence et la conformit e entre le mod` ele et son
m eta-mod` ele. Ces r` egles sont utilis ees pour faciliter lidentication des eventuelles in-
coh erences et pour d etecter et corriger des erreurs de sp ecication. Le second, appel e
inter-validation, est bas e sur des r` egles de validation inter-mod` eles permettant dassister
et de guider le passage dun mod` ele ` a un autre. Ces r` egles permettent de r eduire les erreurs
et dassurer la coh erence entre les mod` eles.
64 Approche de Validation
XML File XML File XML File
Model
Meta-Model
M
1
M
2
Reconfiguration Operations
Meta-Model
Reconfiguration Protocol
Meta-Model
Architectural Style
Model
Reconfiguration Protocol
Model
Architectural Style
Meta-Model
XML Schema XML Schema XML Schema
Reconfiguration Operation
Models
Model Rules
Meta-Model Rules
intra-
validation
intra-
validation
intra-
validation
inter-
validation
inter-
validation
inter-
validation
inter-
validation
XML File
Thse
FIG. 4.1 Approche de validation
4.1 Intra-Validation
Lintra-validation consiste ` a contr oler la conformit e et la coh erence entre le mod` ele
(le niveau M
1
) et son m eta-mod` ele correspondant (le niveau M
2
). Comme il est d ecrit
dans la gure 4.1, au niveau M
1
, nous d enissons nos trois mod` eles : Style Architectu-
ral, Op erations de Reconguration et Protocol de Reconguration. Pour chaque mod` ele,
nous d enissons un ensemble de r` egles (r` egles selon le mod` ele). Au niveau M
2
, nous
d enissons notre prol exprim e par les trois m eta-mod` eles. Pour chaque m eta-mod` ele,
nous d enissons un ensemble de r` egles (r` egles selon le m eta-mod` ele). Les mod` eles sont
d ecrits dans des descriptions XML et les m eta-mod` eles sont d ecrits dans des descriptions
XML sch ema (XSD). En se basant sur la technologie XML nous validons les descriptions
XML par rapport ` a leurs XML sch emas.
Nous d enissons pour chaque mod` ele et chaque m eta-mod` ele lensemble de ses r` egles.
Celles-ci sont exprim ees avec le langage XML.
4.1.1 R` egles pour le style architectural
Le m eta-mod` ele du style architectural, ArchitecturalStyleM-M est compos e dun
ArchitecturalStyleName, dune ArchitecturalStyleFeature et dun Guards.
4.1 Intra-Validation 65
1 <xs:element name="ArchitecturalStyleM-M">
2 <xs:complexType>
3 <xs:sequence>
4 <xs:element ref="ArchitecturalStyleName"/>
5 <xs:element ref="ArchitecturalStyleFeature"/>
6 <xs:element ref="Guards"/>
7 </xs:sequence>
8 </xs:complexType>
9 </xs:element>
Un ArchitecturalStyleName permet didentier le style architectural.
1 <xs:element name="ArchitecturalStyleName">
2 <xs:complexType>
3 <xs:attribute name="ArchitecturalStyleName" type="xs:ID" use="required"/>
4 </xs:complexType>
5 </xs:element>
Une ArchitecturalStyleFeature est compos ee de deux ou plusieurs Components et
dun ou de plusieurs Connectors.
1 <xs:element name="ArchitecturalStyleFeature">
2 <xs:complexType>
3 <xs:sequence>
4 <xs:element ref="Component" minOccurs="2" maxOccurs="unbounded"/>
5 <xs:element ref="Connector" maxOccurs="unbounded"/>
6 </xs:sequence>
7 </xs:complexType>
8 </xs:element>
Un Component est identi e par un nom unique (ligne 11). Il contient un ou plusieurs
Ports.
1 <xs:element name="Component">
2 <xs:complexType>
3 <xs:sequence>
4 <xs:element ref="NameComponent"/>
5 <xs:element ref="Port" maxOccurs="unbounded"/>
6 </xs:sequence>
7 </xs:complexType>
8 </xs:element>
9 <xs:element name="NameComponent">
10 <xs:complexType>
11 <xs:attribute name="NameComponent" type="xs:ID" use="required"/>
12 </xs:complexType>
13 </xs:element>
Un Port est identi e par un nom unique, au sein du m eme composant (ligne 11). Il
poss` ede une Interface.
1 <xs:element name="Port">
2 <xs:complexType>
3 <xs:sequence>
4 <xs:element ref="NamePort"/>
5 <xs:element ref="Interface"/>
6 </xs:sequence>
7 </xs:complexType>
8 </xs:element>
9 <xs:element name="NamePort">
10 <xs:complexType>
11 <xs:attribute name="NamePort" type="xs:ID" use="required"/>
13 </xs:element>
Une Interface est identi ee par un nom unique, au sein du m eme composant (ligne 3).
Une Interface peut etre de type Required (ligne 14) et/ou de type Provided
(ligne 15).
1 <xs:element name="NameInterface">
2 <xs:complexType>
3 <xs:attribute name="NameInterface" type="xs:ID" use="required"/>
4 </xs:complexType>
5 </xs:element>
6 <xs:element name="Interface">
7 <xs:complexType>
8 <xs:sequence>
9 <xs:element ref="NameInterface"/>
10 </xs:sequence>
11 <xs:attribute name="Type" use="required">
12 <xs:simpleType>
13 <xs:restriction base="xs:NMTOKEN">
14 <xs:enumeration value="Required"/>
15 <xs:enumeration value="Provided"/>
16 </xs:restriction>
17 </xs:simpleType>
18 </xs:attribute>
20 </xs:element>
Un Connector est identi e par un nom unique (ligne 3). Il peut etre de type Assembly
(ligne 13) ou de type Delegation (ligne 14).
1 <xs:element name=NameConnector>
2 <xs:complexType>
3 <xs:attribute name=NameConnector type=xs:ID use=required/>
4 </xs:complexType>
5 </xs:element><xs:element name=Connector>
6 <xs:complexType>
7 <xs:sequence>
8 <xs:element ref=NameConnector/>
9 </xs:sequence>
10 <xs:attribute name=Type use=required>
11 <xs:simpleType>
12 <xs:restriction base=xs:NMTOKEN>
13 <xs:enumeration value=Assembly/>
14 <xs:enumeration value=Delegation/>
16 </xs:simpleType>
17 </xs:attribute>
19 </xs:element>
Un Guards est compos e par un ou plusieurs contraintes. Ces contraintes seront
exprim ees avec le langage OCL lors de la mod elisation.
1 <xs:element name=Guards>
2 <xs:complexType>
3 <xs:sequence>
4 <xs:element name=Constraint type=xs:string maxOccurs=unbounded/>
5 </xs:sequence>
6 </xs:complexType>
7 </xs:element>
8 <xs:element name=Constraint type=xs:string/>
4.1.2 R` egles pour lop eration de reconguration
Le m eta-mod` ele RecongurationOperationM-M est compos e dun
RecongurationOperationName, dune RecongurationOperationFeature et
dun Guards.
1 <xs:element name=RecongurationOperationMM>
2 <xs:complexType>
3 <xs:sequence>
4 <xs:element ref=RecongurationOperationName/>
5 <xs:element ref=RecongurationOperationFeature/>
6 <xs:element ref=Guards/>
7 </xs:sequence>
8 </xs:complexType>
9 </xs:element>
Un RecongurationOperationName permet didentier une op eration de recongura-
tion.
1 <xs:element name=RecongurationOperationName>
2 <xs:complexType>
3 <xs:attribute name=Name type=xs:ID use=required/>
4 </xs:complexType>
5 </xs:element>
Une RecongurationOperationFeature est compos ee des trois parties
Require&Delete, Require&Preserve et Insert.
1 <xs:element name=RecongurationOperationFeature>
2 <xs:complexType>
3 <xs:sequence>
4 <xs:element ref=Require Delete/>
5 <xs:element ref=Require Preserve/>
6 <xs:element ref=Insert/>
7 </xs:sequence>
8 </xs:complexType>
9 </xs:element>
Chacune des trois parties Require&Delete, Require&Preserve et Insert est
compos ee de z ero ou plusieurs instances de Components (ligne 4) et de z ero ou
plusieurs instances de Connectors (ligne 5).
1 <xs:element name=Require Delete>
2 <xs:complexType>
3 <xs:sequence>
4 <xs:element ref=Component minOccurs=0 maxOccurs=unbounded/>
5 <xs:element ref=Connector minOccurs=0 maxOccurs=unbounded/>
6 </xs:sequence>
7 </xs:complexType>
8 </xs:element>
9 ...
Une instance de composant est identi ee par un nom unique (ligne 11). Elle contient un
ou plusieurs Ports. Un port est identi e par un nom unique au sein du m eme composant
(ligne 22) et il poss` ede une Interface. Egalement, une interface est identi ee par un
nom unique, au sein du m eme port. Une interface peut etre de type Required (ligne 27)
ou de type Provided (ligne 28).
1 <xs:element name=Component>
2 <xs:complexType>
3 <xs:sequence>
4 <xs:element ref=NameComponent/>
5 <xs:element ref=Port maxOccurs=unbounded/>
6 </xs:sequence>
7 </xs:complexType>
8 </xs:element>
9 <xs:element name=NameComponent>
10 <xs:simpleType>
11 <xs:restriction base=xs:ID/>
12 </xs:simpleType>
13 </xs:element>
14 <xs:element name=Port>
15 <xs:complexType>
16 <xs:sequence>
17 <xs:element ref=NamePort/>
18 <xs:element ref=Interface/>
19 </xs:sequence>
21 </xs:element>
22 <xs:element name=NamePort type=xs:ID/>
23 ...
24 <xs:element name=TypeInterface>
25 <xs:simpleType>
26 <xs:restriction base=xs:string>
27 <xs:enumeration value=Required/>
28 <xs:enumeration value=Provided/>
30 </xs:simpleType>
31 </xs:element>
Un Connector est identi e par un nom unique (ligne 9). Il peut etre de type Assembly
(ligne 13) ou de type Delegation (ligne 14).
1 <xs:element name=Connector>
2 <xs:complexType>
3 <xs:sequence>
4 <xs:element ref=NameConnector/>
5 <xs:element ref=TypeConnector/>
6 </xs:sequence>
7 </xs:complexType>
8 </xs:element>
9 <xs:element name=NameConnector type=xs:ID/>
10 <xs:element name=TypeConnector>
11 <xs:simpleType>
13 <xs:enumeration value=Assembly/>
14 <xs:enumeration value=Delegation/>
16 </xs:simpleType>
17 </xs:element>
Un Guards est compos e par un ou plusieurs contraintes. Ces contraintes seront
exprim ees par le langage OCL.
1 <xs:element name=Guards>
2 <xs:complexType>
3 <xs:sequence>
4 <xs:element name=Constraint type=xs:string maxOccurs=unbounded/>
5 </xs:sequence>
6 </xs:complexType>
7 </xs:element>
8 <xs:element name=Constraint type=xs:string/>
4.1.3 R` egles pour le protocole de reconguration
Le m eta-mod` ele RecongurationProtocolM-M est compos e dun
RecongurationProtocolName et dune RecongurationProtocolFeature.
1 <xs:element name=RecongurationProtocolMM>
2 <xs:complexType>
3 <xs:sequence>
4 <xs:element ref=RecongurationProtocolName/>
5 <xs:element ref=RecongurationProtocolFeature/>
6 </xs:sequence>
7 </xs:complexType>
8 </xs:element>
Un RecongurationProtocolName permet didentier le protocole de reconguration.
1 <xs:element name=RecongurationProtocolName>
2 <xs:complexType>
3 <xs:attribute name=RecongurationProtocolName type=xs:ID use=required/>
4 </xs:complexType>
5 </xs:element>
Une RecongurationProtocolFeature est compos ee dun ou de plusieurs
RecongurationOperationNode et dun ou de plusieurs ControlNode.
1 <xs:element name=Collection>
2 <xs:complexType>
3 <xs:sequence>
4 <xs:element ref=RecongurationOperationNode maxOccurs=unbounded/>
5 <xs:element ref=ControlNode maxOccurs=unbounded/>
6 </xs:sequence>
7 </xs:complexType>
8 </xs:element>
Un RecongurationOperationNode est identi e par un nom unique (ligne 11) et
compos e dun ou de plusieurs Link.
1 <xs:element name=RecongurationOperationNode>
2 <xs:complexType>
3 <xs:sequence>
4 <xs:element ref=RecongurationOpertionName/>
5 <xs:element ref=Link maxOccurs=unbounded/>
6 </xs:sequence>
7 </xs:complexType>
8 </xs:element>
9 <xs:element name=RecongurationOpertionName>
10 <xs:complexType>
11 <xs:attribute name=RecongurationOpertionName type=xs:ID use=required/>
13 </xs:element>
Un ControlNode poss` ede un nom ControlNodeName, un type ControlNodeType
et un ou plusieurs Link. Un ControlNodeType peut avoir un type parmi ces
quatre (de la ligne 24 jusqu` a la ligne 27) : InitialNode, DecisionNode,
SynchronousNode et FinalNode.
1 <xs:element name=ControlNode>
2 <xs:complexType>
3 <xs:sequence>
4 <xs:element ref=ControlNodeName/>
5 <xs:element ref=ControlNodeType/>
6 <xs:element ref=Link maxOccurs=unbounded/>
7 </xs:sequence>
8 </xs:complexType>
9 </xs:element>
10 <xs:element name=ControlNodeName>
11 <xs:complexType>
12 <xs:attribute name=ControlNodeName use=required>
13 <xs:simpleType>
14 <xs:restriction base=xs:string/>
15 </xs:simpleType>
16 </xs:attribute>
18 </xs:element>
19 <xs:element name=ControlNodeType>
20 <xs:complexType>
21 <xs:attribute name=ControlNodeType use=required>
22 <xs:simpleType>
24 <xs:enumeration value=InitialNode/>
25 <xs:enumeration value=DecisionNode/>
26 <xs:enumeration value=SynchronousNode/>
27 <xs:enumeration value=FinalNode/>
29 </xs:simpleType>
30 </xs:attribute>
32 </xs:element>
Un Link poss` ede un type Type et une d esignation Designation. Un
Link peut avoir un type parmi ces quatre (de la ligne 23 jusqu` a la ligne 26) :
LinkToFinalNode, LinkToDecisionNode, LinkToOperationNode
et LinkToSynchronousNode.
1 <xs:element name=Link>
2 <xs:complexType>
3 <xs:sequence>
4 <xs:element ref=Type/>
5 <xs:element ref=Designation/>
6 </xs:sequence>
7 </xs:complexType>
8 </xs:element>
9 <xs:element name=Designation>
10 <xs:complexType>
11 <xs:attribute name=Designation use=required>
12 <xs:simpleType>
13 <xs:restriction base=xs:string/>
14 </xs:simpleType>
15 </xs:attribute>
17 </xs:element>
18 <xs:element name=Type>
19 <xs:complexType>
20 <xs:attribute name=Type use=required>
21 <xs:simpleType>
23 <xs:enumeration value=LinkToFinalNode/>
24 <xs:enumeration value=LinkToDecisionNode/>
25 <xs:enumeration value=LinkToOperationNode/>
26 <xs:enumeration value=LinkSynchronousNode/>
28 </xs:simpleType>
29 </xs:attribute>
31 </xs:element>
4.1.4 Validation
Pour lintra-validation, nous avons utilis e, comme illustr e dans la gure 4.1, lapproche de
validation propos ee par MOF (Meta-Object Facility). Cette approche est utilis ee an de
valider les mod` eles par rapport ` a leurs m eta-mod` eles. Le niveau M
2
est compos e de trois
m eta-mod` eles d enissant la structure de chaque mod` ele. Le niveau M
1
est compos e par
les trois mod` eles r esultants. Dans le MOF, la validation dun mod` ele se fait avec le mod` ele
du niveau sup erieur. Le niveau M
1
est donc valid e par le niveau M
2
.
Les r` egles que nous avons d enies sont mod elis ees et impl ement ees dans des descrip-
tions XML sch emas (niveau M
2
). La mod elisation de l evolution dun syst` eme est r ealis e
avec notre prol et les mod` eles r esultants sont automatiquement transform es vers des des-
criptions XML (niveau M
1
). La validation des descriptions XML se fait ` a laide de la
description XML sch ema correspondante en utilisant des outils XML tel que XMLSpy de
Altova.
La validation consiste ` a contr oler que la description XML est bien form ee et quelle est une
instance du son XML Sch ema. La gure 4.2 repr esente la validation du style architectural.
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified">
<xs:import namespace="http://www.w3.org/XML/1998/namespace"/>
<xs:element name="ArchitecturalStyleM-M">
<xs:complexType>
<xs:sequence>
<xs:element ref="ArchitecturalStyleName"/>
<xs:element ref="ArchitecturalStyleFeature"/>
<xs:element ref="Guards"/>
<ArchitecturalStyleM xmlns:xsi="http://www.w3.org/"
xsi:noNamespaceSchemaLocation="ArchitecturalStyleMM.xsd">
<ArchitecturalStyleName ArchitecturalStyleName=EO"/>
<ArchitecturalStyleFeature>
<xs:element ref Guards />
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="ArchitecturalStyleName">
l T
<Component>
<NameComponent NameComponent=Manager"/>
<Port>
<NamePort NamePort=" Manager .P1"/>
<Interface Type="Provided">
<xs:complexType>
<xs:attribute name="ArchitecturalStyleName" type="xs:ID" use="required"/>
</xs:complexType>
</xs:element>
<xs:element name="ArchitecturalStyleFeature">
<Interface Type= Provided >
<NameInterface NameInterface=" Manager.P1.I1"/>
</Interface>
</Port>
<Port>
Validation xs:element name ArchitecturalStyleFeature
<xs:complexType>
<xs:sequence>
<xs:element ref="Component" minOccurs="2" maxOccurs="unbounded"/>
<xs:element ref="Connector" maxOccurs="unbounded"/>
</ >
<NamePort NamePort=" Manager.P2"/>
<Interface Type=Required">
</Interface>
</Port>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="Component">
<xs:complexType>
</Port>
<Port>
<NamePort NamePort=" Manager.P3"/>
<Interface Type="Provided">
/I t f
p yp
<xs:sequence>
<xs:element ref="NameComponent"/>
<xs:element ref="Port" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</Interface>
</Port>
(a)
</xs:complexType>
</xs:element>
<xs:element name="NameComponent">
<xs:complexType>
<xs:attribute name="NameComponent" type="xs:ID" use="required"/> p yp q
</xs:complexType>
</xs:element>
(b)
FIG. 4.2 Validation de la description XML (a) par rapport ` a son XML Sch ema (b)
4.2 Inter-Validation
De m eme, nous d enissons des r` egles de validation inter-mod` eles. Ces r` egles, comme
lillustre la gure 4.1, permettent de guider et de valider le passage dun mod` ele vers un
autre.
Nous d enissons deux types de validation. Le premier permet de guider le passage du style
architectural vers la mod elisation des op erations de reconguration. Le deuxi` eme permet
de guider le passage des op erations de reconguration vers la mod elisation du protocole
de reconguration. Ces r` egles sont impl ement ees avec le langage Java.
4.2.1 Style architectural vers operation de reconguration
Les r` egles suivantes permettent de guider le passage du style architectural vers la
mod elisation des op erations de reconguration.
4.3 Conclusion 73
Chaque instance Component dans la partie RecongurationOperationFeature lui cor-
respond un Component dans la partie ArchitecturalStyleFeature.
Chaque instance Connector dans la partie RecongurationOperationFeature lui corres-
pond un Connector dans la partie ArchitecturalStyleFeature.
Chaque instance Port dans la partie RecongurationOperationFeature lui correspond
un Port dans la partie ArchitecturalStyleFeature.
Chaque instance Interface dans la partie RecongurationOperationFeature lui corres-
pond une Interface dans la partie ArchitecturalStyleFeature.
4.2.2 Operation de reconguration vers protocole de reconguration
Les r` egles suivantes permettent de guider le passage des op erations de reconguration
vers la mod elisation du protocole de reconguration.
Chaque RecongurationOperationNode dans la partie RecongurationProtocolFeature
lui correspond une RecongurationOperation dans la partie
RecongurationOperationFeature apr` es elimination des noms des param` etres.
Chaque RecongurationControlNode dans la partie RecongurationProtocolFeature
doit regrouper une ou plusieurs contraintes OCL de la partie Guards de
RecongurationOperationFeature.
4.3 Conclusion
Nous avons propos e dans ce chapitre une approche de validation ` a base de r` egles. Ces
r` egles permettent didentier les eventuelles incoh erences et de d etecter toute utilisation
incorrecte du prol propos e. La validation propos ee permet de contr oler que les mod` eles
g en er es, repr esent es dans des descriptions XML, sont conformes ` a leurs m eta-mod` eles,
repr esent es dans des descriptions XML sch ema. La validation que nous avons propos ee
est structurelle et ` a base du langage XML. Cependant, cette approche souffre de quelques
limites. Elle ne permet pas de v erier si le style architectural est consistant ou non et elle
ne permet pas de v erier si lex ecution dune op eration de reconguration pr eserve le
style architectural d ej` a d eni. Dans le chapitre suivant, nous proposons une approche de
v erication qui apporte des solutions ` a ces limites.
5
Approche de V erication
Le prol que nous avons propos e est bas e essentiellement sur le langage semi-formel
UML. Les mod` eles g en er es ` a partir du prol peuvent etre ambigus et peu pr ecis. Cette
g en eration informelle est un frein ` a la r eutilisation et plus largement ` a la qualit e de lar-
chitecture logicielle produite du point de vue de sa correction ou encore de son evolution.
Ceci est d u ` a labsence dune s emantique formelle pr ecise pour UML, qui noffre pas des
outils rigoureux de v erication et de preuve. Toute erreur ou mauvaise conception de lar-
chitecture logicielle dune application peut causer des probl` emes graves qui peuvent avoir
de mauvaises r epercussions. Ainsi, assurer une abilit e et une coh erence de larchitecture
reste un objectif ambitieux du g enie logiciel. Ceci permet d eviter des erreurs potentielles
dans le fonctionnement de lapplication.
An de pallier ` a ces inconv enients, nous faisons recours aux techniques formelles pour
analyser et v erier larchitecture logicielle. En effet, les techniques formelles ont et e
elabor ees an dassurer un certain niveau de pr ecision et de coh erence. Nous adoptons
une approche bas ee sur la transformation des mod` eles semi-formels vers des sp ecications
formelles. Lint er et majeur de cette approche est de surmonter le manque de pr ecision du
langage UML.
Lapproche de v erication, d ecrite dans la gure 5.1, est compos ee de deux parties. Nous
proposons, dans la premi` ere partie, une approche assurant une transformation automa-
tique du style architectural et de chaque op eration de reconguration vers le langage for-
mel Z [133, 141]. Nous adoptons, dans la deuxi` eme partie, une approche de v erication.
Cette approche est d evelopp ee, dans notre unit e de recherche ReDCAD, dans le cadre des
travaux de la th` ese de Me. Imen LOULOU [84]. Nous v erions la consistance du style
architectural et la conformit e de l evolution dune architecture par rapport ` a son style
architectural. Nous utilisons le syst` eme de preuve Z/EVES [95] pour v erier ces deux
76 Approche de V erication
propri et es.
R
i
R
j
C
i
4 V ifi ti
R
k
Guards
Contraintes OCL
C
j
C
n
Style Architectural
Rgles de
Transformation
Outils
3. Transformation
4. Vrification
cc
Style_Nam
e
sub_C
i
: F C
i
sub_C
j
: F C
j
sub_C
n
: F C
n
[C
i
, C
j
, C
n
]
Style_Name
x?: C
i
y?: C
j
z?: C
ReconfOpName1
Style_Name
x?: C
ReconfOpName2
y:C
j
x:C
i
z:C
n
require&delete require&preserve insert
Guards
R
m
R
n
z?: C
n
x?: C
i
y?: C
j
z?: C
n
2. Intra- et inter-validation Opration de Reconfiguration

Contraintes OCL
1. Modlisation de larchitecture
Z/ EVES
5. Preuve
FIG. 5.1 Approche de transformation et de v erication
5.1 Transformation vers Z
La transformation de la notation UML vers un langage formel nest pas nouvelle. Cepen-
dant, il y a peu de travaux qui ont cherch e ` a v erier la conformit e du style architectural
apr` es lex ecution dune op eration de reconguration. Ainsi, pour combler cette lacune et
pour mener des raisonnements rigoureux sur larchitecture, nous proposons une approche
qui transforme dune facon automatique le style architectural et chaque op eration de re-
conguration vers des sp ecications formelles en Z. Les sp ecications r esultantes sont
utilis ees an de mener des raisonnements et des preuves formelles.
Cette transformation est r ealis ee en deux etapes et bas ee sur des r` egles de transformation.
La premi` ere etape est bas ee sur des r` egles permettant la transformation des notations gra-
phiques du style architectural et de chaque op eration de reconguration vers la notation
Z. La deuxi` eme etape est bas ee sur des r` egles permettant la transformation des contraintes
architecturales exprim ees avec le langage OCL vers la notation Z.
Lapproche de transformation que nous proposons est inspir ee des travaux de recherche
de [50, 1, 2]. En effet, la notation Z se pr esente comme un formalisme pouvant d ecrire les
5.1 Transformation vers Z 77
composants du syst` eme et les interconnexions entre eux ainsi que les propri et es architec-
turales. Un style architectural est d ecrit par le sch ema Z suivant :
Nom Style
Type de composants
Type de connexions
proprietes architecturales
Une architecture logicielle peut evoluer en modiant la structure de son architecture. La
conguration r esultante repr esente une instance du style architectural pr esent ee par un
sch ema dop eration Z exprimant les pr e- et les post-conditions.
RecongurationOperation
Nom Style
Par
1
?, Par
2
?, ..., Par
n
?
Pre Conditions
Post Conditions
Avec :
Nom Style indique que lop eration de reconguration peut changer l etat du syst` eme.
Par
1
?, Par
2
?, ..., Par
n
? repr esentent les param` etres dentr ee de lop eration de recon-
guration.
Les pr e-conditions et les post-conditions traduisent des conditions exprim ees textuelle-
ment et qui doivent etre evalu ees en vrai pour que la production ait lieu. Ces conditions
d enissent des contraintes sur les valeurs des attributs, le nombre dinstances dun com-
posant, etc.
5.1.1 Transformation de la partie graphique vers Z
Dans ce qui suit, nous introduisons les r` egles de transformation du style architectural et
des op erations de reconguration vers la notation Z.
La transformation du style architectural vers la notation Z cherche ` a pr eserver les
types de composants, les types de connexions et les contraintes architecturales. Cette
transformation, comme le montre la gure 5.2, ob eit ` a un ensemble de r` egles.
Comp
i
Style_Name
R1
R3
sub_Comp
i
: F Comp
i
sub_Comp
j
: F Comp
j
sub_Comp
n
: F Comp
n
[Comp
i
, Comp
j
, Comp
n
]
R2 ArchitecturalStyleFeature
Style_Name
R5
R4
Comp
n
Comp
j
dom Comp
i
ToComp
j
sub_Comp
i
ran Comp
i
ToComp
j
sub_Comp
j
dom Comp
n
ToComp
i
sub_Comp
n
ran Comp
n
ToComp
i
sub_Comp
i
dom Comp
n
ToComp
j
sub_Comp
n
ran Comp
n
ToComp
j
sub_Comp
j
Guards
Contraintes OCL
Comp
i
ToComp
j
: Comp
i
Comp
j
Comp
n
ToComp
i
: Comp
i
Comp
n
Comp
n
ToComp
j
: Comp
j
Comp
n
Style Architectural
Fin
FIG. 5.2 Transformation du style architectural vers la notation Z
R` egle1 : D enition des types basiques de composants
Les types basiques de composants sont d etermin es ` a partir des noms des types des com-
posants gurant dans la partie ArchitecturalStyleFeature .
[Comp
i
, Comp
j
, ..., Comp
n
]
R` egle2 : D enition du nom du sch ema Z
Cette r` egle g en` ere le squelette du sch ema Z. Le nom du sch ema est d etermin e ` a partir du
nom du style donn e par la partie ArchitecturalStyleName .
Style Name
R` egle 3 : D enition des ensembles de composants
Chaque type de composant pr esent e dans la partie ArchitecturalStyleFeature est tra-
duit en un ensemble ni F de composants. Le type de chaque ensemble de composant
g en er e correspond ` a un type basic d etermin e ` a partir de la r` egle 1. Le nom de chaque en-
semble de composant est pr e-x e par sub
suivi par le nom de type de composant. Ces

ensembles sont d eclar es dans la partie d eclarative du sch ema Z.
Style Name
sub Comp
i
: FComp
i
sub Comp
j
: FComp
j
sub Comp
n
: FComp
n
R` egle 4 : D enition des relations
Chaque connexion pr esent ee dans la partie ArchitecturalStyleFeature est transform ee
en une relation, Comp
i
ToComp
j
: Comp
i
Comp
j
, dans la partie d eclarative du sch ema
Z. La source de la relation, Comp
i
, porte le nom du type de composant ayant linterface
requise et la cible de la relation, Comp
j
, porte le nom du type de composant ayant linter-
face fournie. Le nom de la relation est la clause To sufx ee par la source et pr ex ee par
la cible.
Style Name
sub Comp
i
: FComp
i
sub Comp
j
: FComp
j
sub Comp
n
: FComp
n
Comp
i
ToComp
j
: Comp
i
Comp
j
Comp
n
ToComp
i
: Comp
n
Comp
i
Comp
n
ToComp
j
: Comp
n
Comp
j
R` egle 5 : D enition des contraintes sur les relations
Pour exprimer des contraintes sur les relations, le langage Z offre les deux fonctions
dom (domaine) et ran (image). Dom repr esente lensemble de d epart et ran repr esente
lensemble darriv ee. Le domaine dune relation R : T U est lensemble de tous les
el ements dans T qui sont li es au moins ` a un el ement dans U. Limage de la relation R est
lensemble de tous les el ements dans U li es au moins ` a un el ement dans T [141].
Chaque relation a un domaine et une image [141]. En se basant sur la troisi` eme et la qua-
tri` eme r` egle, cette r` egle d enit, dans la partie pr edicative du sch ema Z, les propri et es din-
variance sur lensemble de d epart (domaine) et lensemble darriv ee (image) de chaque
relation. Chaque propri et e exprime linclusion du domaine, respectivement de limage, de
la relation dans le sous-ensemble correspondant d ej` a d eni dans la partie d eclarative.
Style Name
sub Comp
i
: FComp
i
sub Comp
j
: FComp
j
sub Comp
n
: FComp
n
Comp
i
ToComp
j
: Comp
i
Comp
j
Comp
n
ToComp
i
: Comp
n
Comp
i
Comp
n
ToComp
j
: Comp
n
Comp
j
dom Comp
i
ToComp
j
sub Comp
i
ran Comp
i
ToComp
j
sub Comp
j
dom Comp
n
ToComp
i
sub Comp
n
ran Comp
n
ToComp
i
sub Comp
i
dom Comp
n
ToComp
j
sub Comp
n
ran Comp
n
ToComp
j
sub Comp
j
An de mieux illustrer lapproche de transformation, nous revenons ` a notre exemple et
nous traduisons la partie graphique du style architectural du syst` eme PMS vers la notation
Z. Lapplication des r` egles de transformation de [R1] jusqu` a [R5] donne le sch ema Z
suivant.
[EventService, Patient, Nurse] [R1]
PMS[R2]
sub EventService : FEventService [R3]
sub Patient : FPatient
sub Nurse : FNurse
EventServiceToPatient : EventService Patient [R4]
EventServiceToNurse : EventService Nurse
PatientToEventService : Patient EventService
NurseToEventService : Nurse EventService
PatientToNurse : Patient Nurse
NurseToPatient : Nurse Patient
domEventServiceToPatient sub EventService [R5]
ran EventServiceToPatient sub Patient
domEventServiceToNurse sub EventService
ran EventServiceToNurse sub Nurse
domPatientToEventService sub Patient
ran PatientToEventService sub EventService
domNurseToEventService sub Nurse
ran NurseToEventService sub EventService
domPatientToNurse sub Patient
ran PatientToNurse sub Nurse
domNurseToPatient sub Nurse
ran NurseToPatient sub Patient
FIG. 5.3 Transformation du style architectural vers un sch ema Z
5.1.1.2 Op eration de reconguration
Nous d ecrivons les etapes de transformation dune op eration de reconguration vers la
notation Z. Cette transformation, comme le montre la gure 5.4, est bas ee sur un ensemble
de r` egles de [R6] jusqu` a [R17] permettant de g en erer automatiquement un sch ema
dop eration Z.
OperationName
Style_Name
inst_Comp
i
require&delete require&preserve insert
R6
R7
R8
R9
inst Comp
i
? sub Comp
i
OperationName
inst_Comp
i
?: C
i
inst_Comp
j
?: C
j
inst_Comp
n
?: C
n
inst_Comp
j
inst_Comp
n
inst_Comp
i
? sub_Comp
i
inst_Comp
j
? sub_Comp
j
R11
R12
R13
(inst_Comp
i
?, inst_Comp
n
?) Comp
i
ToComp
j
sub_Comp
n
= sub_Comp
n
{inst_Comp
n
?}
R10
inst_Comp
n
? sub_Comp
n
sub_Comp
j
= sub_Comp
j
\ {inst_comp
j
?}
b C b C
Opration de Reconfiguration
Guards
R13
R14
R15
R16
R17
Comp
n
ToComp
i
= Comp
n
ToComp
i
{(inst_Comp
i
?,inst_Comp
n
?)}
sub_Comp
i
= sub_Comp
i
Comp
i
ToComp
j
= Comp
i
ToComp
j
\ {(inst_Comp
i
?,inst_Comp
j
?)}
R17
Fin
FIG. 5.4 Transformation dune op eration de reconguration vers un sch ema dop eration
Z
R` egle 6 : D enition du nom de lop eration de reconguration
Cette r` egle g en` ere le squelette du sch ema Z. Le nom du sch ema est d etermin e ` a partir de
RecongurationOperationName .
RecongurationOperationName
R` egle 7 : D enition du changement de l etat de larchitecture
Une architecture logicielle peut evoluer apr` es lex ecution dune op eration de recongu-
ration. Cette evolution est exprim ee en Z par le caract` ere . Le changement de l etat de
larchitecture est pr esent e alors, dans la partie d eclarative du sch ema dop eration Z, par
suivi par le nom du style donn e par ArchitecturalStyleName .
Style Name
R` egle 8 : D enition des param` etres dentr ee
Cette r` egle d enit les instances de composants pr esent ees dans la partie Require &
Delete , Require & Preserve et Insert en tant que param` etres dentr ee pour le
sch ema dop eration Z.
Chaque instance de composant est transform ee, dans la partie d eclarative du sch ema
dop eration Z, vers le nom de linstance de composant sufx e par ?. Le type de chaque
composant est le type abstrait associ e au composant qui lui correspond.
Style Name
inst Comp
i
? : type Comp
i
inst Comp
j
? : type Comp
j
inst Comp
n
? : type Comp
n
R` egle 9 : D enition des pr e-conditions sur lappartenance des composants
Cette r` egle permet dajouter des pr e-conditions exprimant lappartenance des instances
de composants de la partie Require & Delete et Require & Preserve ` a len-
semble des composants de larchitecture. Ces pr e-conditions sont ajout ees dans la par-
tie pr edicative du sch ema dop eration Z sous la forme inst Comp sub Comp. Avec
inst Comp d esigne une instance de composant et sub Comp d esigne lensemble de type
de composant.
Style Name
inst Comp
i
? : type Comp
i
inst Comp
j
? : type Comp
j
inst Comp
n
? : type Comp
n
inst Comp
i
? sub Comp
i
inst Comp
j
? sub Comp
j
R` egle 10 : D enition des pr e-conditions sur la restriction des composants
Cette r` egle permet dajouter des pr e-conditions exprimant la non appartenance des ins-
tances de composants de la partie Insert ` a lensemble des composants de larchitec-
ture. Ces pr e-conditions sont ajout ees dans la partie pr edicative du sch ema dop eration Z
sous la forme inst Comp sub Comp.
Style Name
inst Comp
i
? : type Comp
i
inst Comp
j
? : type Comp
j
inst Comp
n
? : type Comp
n
inst Comp
i
? sub Comp
i
inst Comp
j
? sub Comp
j
inst Comp
n
? sub Comp
n
R` egle 11 : D enition des pr e-conditions sur les relations
Cette r` egle permet de transformer les connexions existantes entre la partie Require &
Delete et Require & Preserve vers des relations exprim ees avec la notation Z. Ces
relations sont repr esent ees en Z sous la forme suivante : (inst Comp
i
, inst Comp
j
)
Comp
i
ToComp
j
. Avec (inst Comp
i
, inst Comp
j
) est la relation entre les composants
inst Comp
i
et inst Comp
j
et Comp
i
ToComp
j
d enit lensemble des relations reliant les
composants de type Comp
i
et Comp
j
.
Style Name
inst Comp
i
? : type Comp
i
inst Comp
j
? : type Comp
j
inst Comp
n
? : type Comp
n
inst Comp
i
? sub Comp
i
inst Comp
j
? sub Comp
j
inst Comp
n
? sub Comp
n
(inst Comp
i
?, inst Comp
j
?) Comp
i
ToComp
j
R` egle 12 : D enition des post-conditions li ees ` a linsertion des composants
Linsertion dun composant en Z est traduite par la r` egle suivante : sub Comp
=
sub Comp inst Comp. Avec sub Comp
d ecrit lensemble des composants r esultants

apr` es lex ecution de lop eration de reconguration. sub Comp repr esente lensemble des
composants avant lex ecution de lop eration de reconguration et inst Comp d esigne une
instance de composant ` a ins erer dans le syst` eme.
Style Name
inst Comp
i
? : type Comp
i
inst Comp
j
? : type Comp
j
inst Comp
n
? : type Comp
n
inst Comp
i
? sub Comp
i
inst Comp
j
? sub Comp
j
inst Comp
n
? sub Comp
n
(inst Comp
i
?, inst Comp
j
?) Comp
i
ToComp
j
sub Comp
n
= sub Comp
n
{inst Comp
n
?}
R` egle 13 : D enition des post-conditions li ees ` a la suppression des composants
La suppression dun composant en Z est traduite par la r` egle suivante : sub Comp
=
sub Comp \ inst Comp o` u inst Comp d esigne une instance de composant ` a supprimer.
Style Name
inst Comp
i
? : type Comp
i
inst Comp
j
? : type Comp
j
inst Comp
n
? : type Comp
n
inst Comp
i
? sub Comp
i
inst Comp
j
? sub Comp
j
inst Comp
n
? sub Comp
n
(inst Comp
i
?, inst Comp
j
?) Comp
i
ToComp
j
sub Comp
n
= sub Comp
n
{inst Comp
n
?}
sub Comp
j
= sub Comp
j
\ {inst Comp
j
?}
R` egle 14 : D enition des post-conditions li ees au non changement des compo-
sants
Si un ensemble de composants, gurant dans larchitecture na subi aucun changement
apr` es lex ecution de lop eration de reconguration, alors ces composants seront exprim es
par la r` egle suivante : sub Comp
= sub Comp.
Style Name
inst Comp
i
? : type Comp
i
inst Comp
j
? : type Comp
j
inst Comp
n
? : type Comp
n
inst Comp
i
? sub Comp
i
inst Comp
j
? sub Comp
j
inst Comp
n
? sub Comp
n
(inst Comp
i
?, inst Comp
j
?) Comp
i
ToComp
j
sub Comp
n
= sub Comp
n
{inst Comp
n
?}
sub Comp
j
= sub Comp
j
\ {inst Comp
j
?}
sub Comp
i
= sub Comp
i
R` egle 15 : D enition des post-conditions li ees ` a linsertion des connexions
Linsertion dune connexion en Z est traduite par la r` egle suivante : Comp
i
ToComp
j
=
Comp
i
ToComp
j
(inst Comp
i
, inst Comp
j
). Avec Comp
i
ToComp
j
d ecrit la relation qui
d enit lensemble des connexions reliant les composants de type Comp
i
et Comp
j
et (inst Comp
i
, inst Comp
j
) d ecrit la relation ` a ins erer entre linstance du composant
inst Comp
i
et inst Comp
j
.
Style Name
inst Comp
i
? : type Comp
i
inst Comp
j
? : type Comp
j
inst Comp
n
? : type Comp
n
inst Comp
i
? sub Comp
i
inst Comp
j
? sub Comp
j
inst Comp
n
? sub Comp
n
(inst Comp
i
?, inst Comp
j
?) Comp
i
ToComp
j
sub Comp
n
= sub Comp
n
{inst Comp
n
?}
sub Comp
j
= sub Comp
j
\ {inst Comp
j
?}
sub Comp
i
= sub Comp
i
Comp
n
ToComp
i
= Comp
n
ToComp
i
{(inst Comp
n
?, inst Comp
i
?)}
R` egle 16 : D enition des post-conditions relatives ` a la suppression des
connexions
La suppression dune relation en Z est traduite par la r` egle suivante : Comp
i
ToComp
j
=
Comp
i
ToComp
j
\ (inst Comp
i
, inst Comp
j
). Avec (inst Comp
i
, inst Comp
j
) d ecrit la re-
lation ` a supprimer suite ` a une op eration de suppression dune connexion. inst Comp
i
et
inst Comp
j
repr esentent les instances des composants que nous d esirons d econnecter.
Style Name
inst Comp
i
? : type Comp
i
inst Comp
j
? : type Comp
j
inst Comp
n
? : type Comp
n
inst Comp
i
? sub Comp
i
inst Comp
j
? sub Comp
j
inst Comp
n
? sub Comp
n
(inst Comp
i
?, inst Comp
j
?) Comp
i
ToComp
j
sub Comp
n
= sub Comp
n
{inst Comp
n
?}
sub Comp
j
= sub Comp
j
\ {inst Comp
j
?}
sub Comp
i
= sub Comp
i
Comp
n
ToComp
i
= Comp
n
ToComp
i
{(inst Comp
n
?, inst Comp
i
?)}
Comp
i
ToComp
j
= Comp
i
ToComp
j
\ {(inst Comp
i
?, inst Comp
j
?)}
R` egle 17 : D enition des post-conditions relatives au non changement des
connexions
Si une connexion, gurant dans larchitecture, na subi aucun changement au cours
de lop eration de reconguration, alors nous exprimons ce cas par la r` egle suivante :
Comp
i
ToComp
j
= Comp
i
ToComp
j
. Ce cas nest pas trait e dans lexemple pr esent e dans
la gure 5.4. Nous navons pas des connexions qui nont pas subi des modications.
Nous revenons ` a lexemple du PMS et nous traduisons la partie graphique de lop eration de
reconguration Inser Patient vers la notation Z. Lapplication des r` egles de transformation
successivement de [R6] jusqu` a [R17] donne le sch ema dop eration Z pr esent e dans la
gure 5.5 suivante.
Insert Patient[R6]
PMS [R7]
x? : EventService [R8]
y? : Nurse
z? : Patient
x? sub EventService [R9]
y? sub Nurse
z? sub Patient [R10]
(x?, y?) EventServiceToNurse [R11]
(y?, x?) NurseToEventService
sub Patient
= sub Patient {z?} [R12]

sub EventService
= sub EventService [R14]

sub Nurse
= sub Nurse
EventServiceToPatient
= EventServiceToPatient {(x?, z?)} [R15]

PatientToEventService
= PatientToEventService {(z?, x?)}

NurseToPatient
= NurseToPatient {(y?, z?)}

PatientToNurse
= PatientToNurse {(z?, y?)}

NurseToEventService
= NurseToEventService [R17]
EventServiceToNurse
= EventServiceToNurse
FIG. 5.5 Transformation de lop eration Insert Patient vers un sch ema dop eration Z
5.1.2 Transformation des contraintes OCL vers Z
Outre la transformation des notations graphiques, exprim ees avec la notation UML, vers la
notation Z, nous proposons egalement une transformation des contraintes OCL, exprim ees
dans les parties Guards , vers des pr edicats Z.
Dans cette perspective, nous d enissons une passerelle entre OCL et Z. La passerelle que
nous proposons impl emente un ensemble de r` egles de passage. Cette passerelle correspond
` a une compilation des termes OCL en termes exprim es en Z. Ainsi, une description pr ecise
de la syntaxe de OCL et de Z est n ecessaire an daccomplir cette compilation. Avant de
d ecrire la passerelle, nous pr esentons donc la grammaire du langage OCL et celle du
langage Z. Les deux grammaires ne repr esentent pas tous les concepts utilis es dans les
deux langages. Elles repr esentent seulement les concepts que nous avons int egr es dans
notre prol.
Typiquement, la transformation dune expression OCL se fait en trois etapes. La premi` ere
sert ` a segmenter lexpression OCL en diff erents segments selon la grammaire OCL d enie
(gure 5.6). Cette segmentation permet didentier les types de composants, les types de
connexions, les noms des instances, les fonctions, les constantes et les op erateurs logiques
et relationnels. La deuxi` eme etape sert ` a traduire les segments g en er es en des pr edicats
Z selon la grammaire Z d enie (gure 5.7). Cette transformation est faite selon le type
des segments. La troisi` eme etape consiste ` a faire le passage entre OCL et Z en utilisant la
passerelle (gure 5.8).
Pour les grammaires que nous proposons, nous utilisons les conventions suivantes :
Les choix sont s epar es par des barres verticales : |
Une partie optionnelle est limit ee par deux crochets : [ ]
Le symbole * indique la r ep etition z ero ou plusieurs fois du fragment concern e.
Les symboles en majuscule indiquent les symboles non-terminaux, repr esentent les
mots cl es.
Les symboles en minuscule indiquent les symboles terminaux.
Un ensemble de r` egles de production, qui sont des paires form ees dun non-terminal et
dune suite de terminaux et de non-terminaux.
5.1.2.1 Grammaire OCL
Les r` egles suivantes repr esentent la grammaire du langage OCL. Ces r` egles constituent un
sous-ensemble de la syntaxe de OCL que nous avons utilis ee pour la d enition des r` egles
de transformation de OCL vers Z.
EXPOCL := [CONTEXT EXP] [Fixe] EXPRESSION OCL
EXPRESSION OCL := RELATION EXP | RELATION EXP [OPLOG OCL
RELATION EXP]
RELATION EXP := ADDIDITIVE EXP OPREL OCL CONST | "(" ADDIDITIVE EXP
OPREL OCL ( Const | ADDIDITIVE EXP ) ")" | ADDIDITIVE EXP
[RELATION EXP]
ADDIDITIVE EXP := FONCT APPEL POSTFIX ( FONCT | CONTIF OCL

ADDIDITIVE EXP ) |
OPLOG OCL := "and" | "or" | "implies" | "not"
OPREL OCL := "=" | "<" | ">" | "<=" | ">=" | "<>"
CONST := "0"-"9" | ("0"-"9")
POSTFIX := ""
FONCT APPEL := NOM TYPE"."NOM TYPE | Nom"."NOM TYPE | NOM TYPE
CONTIF OCL := "forAll" | "exists"
FONCT := "size()" | "isEmpty()" | "notEmpty()" | "includes(NOM)" |
"excludes(NOM)"
CONTEXT EXP := "Context" CONTEXT DEC ":" TYPE RETOUR
CONTEXT DEC := NOM TYPE "::" NOM REOP "("PARAMETRE LISTE")"
PARAMETRE LISTE := PARAMETRE ["," PARAMETRE]
PARAMETRE := NOM
TYPE RETOUR := "Boolean"
FIXE := "Pre" | "Post"
NOM := ["a"-"z"] | ["A"-"Z"] (["a"-"z"] | ["0"-"9"] | ["A"-"Z"])
NOM TYPE := ["a"-"z"] | ["A"-"Z"] (["a"-"z"] | ["0"-"9"] |

["A"-"Z"])
NOM REOP := ["a"-"z"] | ["A"-"Z"] (["a"-"z"] | ["0"-"9"] |

["A"-"Z"])
FIG. 5.6 Grammaire OCL
5.1.2.2 Grammaire Z
Les r` egles suivantes repr esentent la grammaire du langage Z. Ces r` egles constituent un
sous-ensemble de la syntaxe de Z que nous avons utilis ee pour la d enition des r` egles de
passage.
EXP Z := EXPRESSION Z [OPLOG Z EXPRESSION Z]
EXPRESSION Z := EXPRESSION1 | EXPRESSION2 | EXPRESSION3

EXPRESSION1 := Card NomType OPREL Z Const
EXPRESSION2 := PARTIE1 "" PARTIE2 OPREL Z Const
EXPRESSION3 := PARTIE1 "" PARTIE3
PARTIE1 := CONTIF Z NOM "" NomType
PARTIE2 := Card "(" NomConnexion "(|" "{" NOM "}" "|)" ")"
PARTIE3 := EXP OPLOG Z EXP
EXP := NOM CONNEXION "(|" "{" NOM "}" "|)" OPREL Z Const
NOM CONNEXION := NOM TYPE "To" NOM TYPE
CARD := "#"
CONTIF Z := "" | ""
OPLOG Z := "" | "" | "" | ""
OPREL Z := "=" | "<" | ">" | "" | "" | "="
CONST := "0"-"9" | ("0"-"9")
NOM := ["a"-"z"] | ["A"-"Z"] (["a"-"z"] | ["0"-"9"] | ["A"-"Z"])
NOM TYPE := ["a"-"z"] | ["A"-"Z"] (["a"-"z"] | ["0"-"9"] |

["A"-"Z"])
FIG. 5.7 Grammaire Z
5.1.2.3 Grammaire de la passerelle

Dans cette section, nous d ecrivons une grammaire pour d ecrire les r` egles de transformation
de OCL vers Z. La partie gauche dune r` egle repr esente un symbole de la grammaire OCL
qui se traduit par sa partie droite dans le langage Z.
EXP OCL := Exp Z
EXPRESSION OCL := EXPRESSION Z
RELATION EXP := EXPRESSION1 | EXPRESSION2 | EXPRESSION3
ADDIDITIVE EXP := PARTIE1 | PARTIE2 | PARTIE3
OPLOG OCL := OPLOG Z
OPREL OCL := OPREL Z
CONTIF OCL := CONTIF Z
CONST := CONST
NOM := NOM
NOMTYPE := NOMTYPE
FIG. 5.8 Grammaire de la passerelle
5.1.2.4 Exemple de transformation
Pour mieux illustrer la transformation dune expression OCL vers un pr edicat Z nous
d etaillons dans ce qui suit lexemple suivant.
EventServicesize() 3 and EventServicesize() > 0
Cette expression OCL exprime que le syst` eme peut contenir entre z ero et trois instances
de composants de type EventService.
Cette expression est d ecompos ee en diff erents segments selon la grammaire OCL d enie.
EXP OCL := EXPRESSION OCL
EXPRESSION OCL := RELATION EXP1 OPLOG OCL RELATION EXP2
RELATION EXP1 := ADDIDITIVE EXP OPREL OCL CONST
ADDIDITIVE EXP := FONCT APPEL POSTFIX FONCT
FONCT APPEL := NOM TYPE
NOM TYPE := "EventService"
POSTFIX := ""
FONCT := "Size()"
OPREL OCL := "<="
CONST := "3"
OPLOG OCL := "And"
RELATION EXP2 := ADDIDITIVE EXP OPREL OCL CONST
ADDIDITIVE EXP := FONCT APPEL POSTFIX FONCT
FONCT APPEL := NOM TYPE
NOM TYPE := "EventService"
POST FIX := ""
FONCT := "Size()"
OPREL OCL := ">"
CONST := "0"
FIG. 5.9 D ecomposition de lexpression OCL
La transformation de lexpression pr ec edente vers Z g en` ere le pr edicat suivant :
# sub EventService 3 # sub EventService > 0
Ce pr edicat est d ecompos e en diff erents segments selon la grammaire Z d enie.
ExpZ := ExpressionZ1 OpLogZ ExpressionZ2
ExpressionZ1 := Expression1
ExpressionZ2 := Expression1
Expression1 := Card NomType OpRelZ Const
Card := "#"
NomType := "EventService"
OpRelZ := ""
Const := "3"
OpLogZ := ""
Card := "#"
NomType := "EventService"
OpRelZ := ">"
Const := "0"
FIG. 5.10 Transformation de lexpression OCL vers Z
Nous revenons ` a notre exemple et nous traduisons la partie graphique et la partie guards
du style architectural du syst` eme PMS vers la notation Z. Lapplication des r` egles de
transformation de [R1] jusqu` a [R5] et lutilisation des grammaires de transformation
donnent le sch ema Z suivant (gure 5.11).
[EventService, Patient, Nurse]
PMS
sub EventService : FEventService
sub Patient : FPatient
sub Nurse : FNurse
EventServiceToPatient : EventService Patient
domEventServiceToPatient sub EventService
ran EventServiceToPatient sub Patient
domEventServiceToNurse sub EventService
ran EventServiceToNurse sub Nurse
domPatientToEventService sub Patient
ran PatientToEventService sub EventService
domNurseToEventService sub Nurse
ran NurseToEventService sub EventService
domPatientToNurse sub Patient
ran PatientToNurse sub Nurse
domNurseToPatient sub Nurse
ran NurseToPatient sub Patient#sub EventService 3 #sub EventService > 0
x : sub EventService #(EventServiceToNurse(| {x} |)) 5
x : sub EventService #(EventServiceToPatient(| {x} |)) 15
x : sub Patient #(PatientToEventService(| {x} |)) = 1
x : sub Patient #(PatientToNurse(| {x} |)) = 1
x : sub Nurse #(NurseToEventService(| {x} |)) = 1
x : sub Nurse #(NurseToPatient(| {x} |)) 3
x : sub EventService EventServiceToPatient(| {x} |) = EventServiceToNurse(| {x} |) =
FIG. 5.11 Transformation du style architectural de lexemple PMS vers la notation Z
De m eme, nous traduisons la partie graphique et la partie guards de lop eration de re-
conguration Inser Patient vers la notation Z. Lapplication des r` egles de transformation
successivement de [R6] jusqu` a [R17] et lutilisation des grammaires de transformation
donnent le sch ema dop eration Z pr esent e dans la gure 5.12 suivante.
Insert Patient
PMS
x? : EventService
y? : Nurse
z? : Patient
x? sub EventService
y? sub Nurse
z? sub Patient
(x?, y?) EventServiceToNurse
sub Patient
= sub Patient {z?}

sub EventService
= sub EventService
sub Nurse
= sub Nurse
EventServiceToPatient
= EventServiceToPatient {(x?, z?)}

PatientToEventService
= PatientToEventService {(z?, x?)}

NurseToPatient
= NurseToPatient {(y?, z?)}

PatientToNurse
= PatientToNurse {(z?, y?)}

NurseToEventService
= NurseToEventService
EventServiceToNurse
= EventServiceToNurse
#(EventServiceToNurse(| {x?} |)) > 0
#(EventServiceToPatient(| {x?} |)) < 15
#(NurseToPatient(| {y?} |)) < 3
FIG. 5.12 Transformation de lop eration Insert Patient vers la notation Z
5.2 V erication
Lobjectif de ce chapitre nest pas la transformation en elle-m eme mais plut ot la
v erication et le raisonnement formel. En effet, la transformation vers Z nest quune
phase interm ediaire avant dentamer la partie v erication et preuve de th eor` emes. La
d enition de cette s emantique formelle offre deux avantages.
Elle permet de v erier et de conrmer, sans ambigut e, la consistance de tout style
architectural.
Elle permet de v erier la pr eservation du style architectural apr` es lex ecution dune
op eration de reconguration.
Pour v erier la consistance et la conformit e de larchitecture par rapport ` a son style archi-
tectural, nous adoptons lapproche propos ee par Me. Imen LOULOU et al. [84].
5.2 V erication 93
5.2.1 Consistance
Un sch ema Z est consid er e comme inconsistant ou incoh erent sil contient un pr edicat
non satisfaisant et/ou une contradiction entre les pr edicats. Si ce sch ema d ecrit un syst` eme
alors, dans ce cas, le syst` eme est dit non r ealisable [141].
V erier la consistance dune sp ecication revient ` a prouver quau moins une instance
valide existe [141]. Dans Z, si nous traitons un sch ema qui d ecrit l etat du syst` eme, il
sagirait alors de fournir un sch ema qui linstancierait. Dans notre contexte, un sch ema
d ecrit un style architectural. Il sagit donc de prouver lexistence dune conguration ( etat
initial) qui appartient au style en question.
En Z, la sp ecication dun syst` eme est d enie par un ensemble de composants, de relations
et des contraintes architecturales. Dans lexemple du sch ema InitSystem, comme le montre
la gure 5.13, component
i
repr esente un type de composant, c
i
repr esente une instance de
composant, la relation
ij
repr esente une relation entre le composant c
i
et le composant c
j
et
contrainte
i
repr esente une contrainte architecturale.
InitSystem
ArchitectureStyle
component
i
= {c
i
}
relation
ij
= {(c
i
, c
j
)}
contrainte
i
. . .
FIG. 5.13 Sch ema dinitialisation
Supposons que ArchitectureStyle repr esente le sch ema du syst` eme et que InitSystem
repr esente un sch ema Z qui d ecrit l etat initial du syst` eme. Si nous prouvons le th eor` eme
suivant :
TheoremConsistentTheorem
ArchitectureStyle InitSystem
alors nous avons montr e quun etat initial existe, et donc les exigences demand ees sur le
syst` eme sont consistantes. Ce r esultat est appel e le th eor` eme dinitialisation [141].
Nous revenons ` a notre exemple et nous v erions la consistance du sch ema du syst` eme
PMS. Comme le montre la gure 5.14, pour v erier le th eor` eme de la consistance, nous
d enissons un etat initial PMS Init. L etat initial se compose dune instance EventService
ES, dune instance Patient P et dune instance Nurse N inter-reli ees ensemble ((P, ES),
(N, P), (N, ES)...). La preuve du th eor` eme ConsistentPMS v erie que la sp ecication du
syst` eme est consistante et elle ne contient aucune contradiction. La sp ecication est d ecrite
comme suit :
PMS Init
PMS
sub EventService = {ES}
sub Patient = {P}
sub Nurse = {N}
PatientToEventService = {(P, ES)}
NurseToPatient = {(N, P)}
NurseToEventService = {(N, ES)}
PatientToNurse = {(P, N)}
EventServiceToPatient = {(ES, P)}
EventServiceToNurse = {(ES, N)}
FIG. 5.14 Une conguration possible du syst` eme PMS
Le th eor` eme dinitialisation que nous avons prouv e avec le syst` eme de preuve de loutil
Z/EVES est par cons equent le suivant :
TheoremConsistentPMS
PMS PMS Init
En choisissant la commande prove by reduce, Z/EVES vient ` a bout de la d emonstration et
afche true.
5.2.2 Pr eservation du style architectural
An de prouver que l evolution de larchitecture pr eserve toujours le style architectural, il
faudrait v erier pour chaque op eration de reconguration que les contraintes (invariants)
5.2 V erication 95
d enies dans le style architectural sont pr eserv ees ` a la n de leur application.
Dans cette etape, les op erations de reconguration sont sp eci ees formellement. Chaque
op eration de reconguration est sp eci ee par un sch ema dop eration Z, qui d enit les
param` etres dentr ee (c
i
?) et les pr e- et post-conditions. Ces conditions sont essentielles
pour v erier que l evolution de larchitecture pr eserve les invariants. Les op erations de
reconguration sont ex ecut ees seulement si leurs conditions pr ealables sont satisfaites.
Dans le sch ema dop eration ci-dessous, PreCond
i
et PostCond
i
d enotent une pr e- et une
post-condition de lop eration de reconguration Operation
i
.
Operation
i
System
c
i
? : Component
i
. . .
PreCond
i
, . . . , PreCond
n
PostCond
i
, . . . , PostCond
n
FIG. 5.15 Template de sch ema dop eration Z
Apr` es avoir sp eci e les op erations de reconguration formellement, ces op erations doivent
etre v eri ees. Pour evaluer limpact dune op eration de reconguration sur une contrainte,
nous d enissons et nous prouvons le th eor` eme PreCondTheorem. Ce th eor` eme enonce les
pre-conditions qui doivent etre satisfaites pour garantir que les contraintes sont pr eserv ees
apr` es lex ecution de lop eration et v erient que lex ecution de lop eration de recongura-
tion pr eserve le style architectural.
TheoremPreCondTheorem
System c? : Component
i
| preConditions pre Operation
i
Illustrons maintenant lapproche de sp ecication des op erations de reconguration en uti-
lisant lexemple de PMS. Nous avons sp eci e formellement les op erations de recongu-
ration telles que linsertion et la suppression dun service d ev enement, dun patient et
dune inrmi` ere. Pour lillustration, le sch ema suivant indique lop eration de recongura-
tion InsertPatient. Le sch ema Z de lop eration d eclare quil faut au moins une inrmi` ere y
appartenant au service en question x pour pouvoir soccuper du nouveau patient z. En plus,
il faut que le service en question ne contient pas d ej` a quinze patients et que le nombre
de patients pour linrmi` ere en question y est strictement inf erieur ` a 3. An de valider
lop eration dinsertion dun nouveau patient, nous utilisons loutil Z/EVES pour prouver
le th eor` eme PreInsertPatient, qui assure que linsertion dun patient est conforme aux
contraintes du syst` eme d ecrites dans le sch ema du syst` eme PMS.
TheoremPre Insert Patient
PMS, x? : EventService, y? : Nurse, z? : Patient
| y? sub Nurse
x? EventService
x? sub EventService
z? sub Patient
(x?, y?) EventServiceToNurse
#(EventServiceToNurse(| {x?} |)) > 0
#(EventServiceToPatient(| {x?} |)) < 15
( x : sub EventService #(EventServiceToPatient {(x?, z?)}(| {x} |)) 15)
( x : sub Patient {z?} #(PatientToEventService {(z?, x?)}(| {x} |)) = 1)
( x : sub Patient {z?} #(PatientToNurse {(z?, y?)}(| {x} |)) = 1)
( x : sub Nurse #(NurseToPatient {(y?, z?)}(| {x} |)) 3)
( x : sub EventService EventServiceToNurse(| {x} |) = {}) pre Insert Patient
Z/Eves r eussit ` a d emontrer ce th eor` eme si on lui sugg` ere la commande prove by reduce.
On obtient le pr edicat suivant ` a prouver.
PMS
x? Event Service
y? Nurse
z? Patient
y? sub Nurse
x? sub Event Service
z? sub Patient
(x?, y?) Event ServiceToNurse
(y?, x?) NurseToEvent Service
#(Event ServiceToNurse(| {x?} |)) > 0
#(Event ServiceToPatient(| {x?} |)) < 15
5.3 Conclusion 97
( x : sub Event Service #(Event ServiceToPatient {(x?, z?)}(| {x} |)) 15)
( x 0 : sub Patient {z?}
#(PatientToEvent Service {(z?, x?)}(| {x 0} |)) = 1)
( x 1 : sub Patient {z?}
#(PatientToNurse {(z?, y?)}(| {x 1} |)) = 1)
( x 2 : sub Nurse
#(NurseToPatient {(y?, z?)}(| {x 2} |)) 3)
( x 3 : sub Event Service Event ServiceToNurse(| {x 3} |) = {})
( Event ServiceToNurse
: P (Event Service Nurse) ;

Event ServiceToPatient
: P (Event Service Patient) ;

NurseToEvent Service
: P (Nurse Event Service) ;

NurseToPatient
: P (Nurse Patient) ;
PatientToEvent Service
: P (Patient Event Service) ;

PatientToNurse
: P (Patient Nurse) ;
sub Event Service
: P Event Service ;
sub Nurse
: P Nurse ;
sub Patient
: P Patient Insert Patient)

5.3 Conclusion
Dans ce chapitre, nous avons propos e une approche de v erication bas ee sur la transfor-
mation des mod` eles semi-formels vers des sp ecications formelles. Ce chapitre sarticule
autour de deux parties. Dans la premi` ere, nous avons propos e une approche de trans-
formation permettant de transformer un style architectural vers un sch ema Z et chaque
op eration de reconguration vers un pr edicat Z. Nous avons egalement pr esent e une pas-
serelle permettant de transformer une expression OCL vers un pr edicat Z. La passerelle
est compos ee dun ensemble de r` egles de passage qui d enissent l equivalent de chaque
el ement du langage OCL dans le langage Z.
Dans la deuxi` eme partie, nous avons adopt e une approche de v erication [84]. Nous avons
v eri e la consistance du style architectural et nous avons prouv e que l evolution de lar-
chitecture est toujours conforme ` a son style architectural. Ces th eor` emes ont et e prouv es
en utilisant le syst` eme de preuve de loutil Z/EVES.
Comme perspective ` a ce chapitre, nous pr evoyons dam eliorer lapproche de v erication
en y ajoutant dautres propri et es.
Pour la partie protocole de reconguration, nous pr evoyons dachever la partie trans-
formation permettant de traduire la description XML g en er ee vers un langage formel.
Nous pr evoyons dutiliser les r eseaux de p etri pour v erier le non blocage des diff erentes
op erations de reconguration et que chaque op eration de reconguration sera ex ecut ee au
moins une fois.
6
D emarche de mod elisation
Jusqu` a maintenant, nous avons pr esent e les etapes n ecessaires pour la mod elisation de
la dynamique des architectures logicielles en utilisant le Prol UML, pour la validation
des mod` eles r esultants et pour la v erication et la preuve de la consistance du style ar-
chitectural et de la conformit e de l evolution de larchitecture par rapport ` a son style. Il
reste cependant ` a d enir une d emarche entre ces diff erentes etapes et de capitaliser des
r` egles permettant de guider et dassister les architectes ` a mod eliser larchitecture dune
application dynamique tout en suivant le prol propos e.
La d emarche X (d emarche de mod elisation des architectures logicielles dynamiques), que
nous proposons permet de d ecrire les diff erentes etapes pour mod eliser larchitecture lo-
gicielle (Style architectural, Op eration de reconguration et Protocole de reconguration)
et de d enir les diff erentes r` egles de passage dun mod` ele ` a un autre. Elle automatise le
processus de validation et assiste lutilisateur pour v erier des propri et es architecturales.
La d emarche que nous proposons est inspir ee de lapproche MDA [10, 67] (Model Dri-
ven Architecture) et 2TUP [127] (2 Tracks Unied Process) du processus UP (Unied
Process). Notre d emarche est subdivis ee en deux parties : une partie PIM (Platform Inde-
pendant Model) et une partie PSM (Platform Specic Model). La premi` ere, mod elise lar-
chitecture logicielle sans se soucier des technologies sous-jacentes. La seconde, mod elise
limplementation des directives de conception vis-` a-vis de la plateforme vis ee (Java/EJB,
C #/.Net, etc.). La d emarche que nous pr esentons est it erative, centr ee sur larchitecture et
incr ementale.
100 D emarche de mod elisation
6.1 Description de la d emarche X
La d emarche X que nous proposons est bas ee sur lapproche MDA et le processus UP et
apporte une r eponse aux contraintes de changement continuel impos ees aux architectures
logicielles dynamiques. Elle renforce le contr ole de ladaptation et la correction de telles
architectures. Comme le montre la gure 6.1, la d emarche que nous proposons est bas ee
sur quatre branches et a la forme de X.
Guards
Branche Style Architectural
Branche Opration de Reconfiguration
Rgles de
Transformation
Rgles de
Validation
Guards
Reconfiguration OperationName
require & delete insert
Guards
require & preserve
Rgles de
Transformation
ReOpNa
2
Rgles de
Validation
Branche Protocole de Reconfiguration
Z/ EVES
Vrification
Vrification
Branche Fonctionnelle
PSM
PIM
Transformation
de Model
Implmentation
Dploiement
Simulation
Style_Name
x?: C
i
y?: C
j
z?: C
n
ReconfOpName2
Rgles de
Validation
sub_Ci : F Ci
sub_Cj : F Cj
sub_Cn: F Cn
..
Style_Name
ReOpNa
1
FIG. 6.1 La d emarche propos ee
6.1.1 Branche style architectural
La capture des besoins architecturaux est la premi` ere etape de la d emarche X. Elle forma-
lise et d etaille les besoins du niveau statique. Cette etape, comme le montre la gure 6.2,
produit, par it eration, un style architectural valide et consistant.
6.1 Description de la d emarche X 101
1. Identifier les types
de composants
2. Identifier les
connexions
3. Identifier les
contraintes arch
4. Concevoir le
style architectural
5. Valider et
consolider
6. Vrifier la
consistance
FIG. 6.2 La branche style architectural
La branche style architectural se fait ` a travers les etapes suivantes :
La premi` ere etape consiste ` a identier les types de composants. Pour chaque composant,
il faut identier la liste de ses ports et de ses interfaces.
La deuxi` eme etape consiste ` a identier la liste des connexions. Pour chaque connexion,
il faut identier le type de composant source et le type de composant destinataire.
La troisi` eme etape consiste ` a d enir la liste des contraintes architecturales, exprim ees
avec le langage OCL, que le syst` eme doit respecter.
La quatri` eme etape consiste ` a mod eliser le style architectural en utilisant les r esultats
des trois etapes pr ec edentes.
La cinqui` eme etape consiste ` a valider le mod` ele du style architectural r esultant par
rapport ` a son m eta-mod` ele. Cette validation consiste donc ` a transformer dune facon
automatique le mod` ele du style architectural vers une description XML qui sera elle
m eme valid ee par rapport ` a son m eta-mod` ele repr esent e par une description XSD (XML
Sch ema). La traduction du mod` ele UML vers XML et la phase de validation sont auto-
matiques gr ace au plug-in FUJABA que nous avons d evelopp e.
La sixi` eme etape consiste ` a v erier la consistance. La description XML du style ar-
chitectural est transform ee, en utilisant des r` egles de transformation, dune facon au-
tomatique, gr ace au plug-in FUJABA vers le langage Z. La sp ecication r esultante est
analys ee et le th eor` eme de consistance est v eri e avec loutil Z/EVES.
Les r esultats de cette branche appartiennent ` a la partie PIM. Ils ne d ependent daucune
technologie particuli` ere.
6.1.2 Branche op eration de reconguration
Cette branche inclue la capture des besoins adaptatifs, qui recense toutes les evolutions
possibles de larchitecture. Elle consiste, comme le montre la gure 6.3, ` a identier pour
chaque op eration de reconguration les etapes suivantes :
La premi` ere etape consiste ` a identier la liste des composants et des connexions ` a ajou-
ter dans la partie Insert.
La deuxi` eme etape consiste ` a identier la liste des composants et des connexions ` a
supprimer dans la partie require & delete.
La troisi` eme etape consiste ` a identier la liste des composants et des connexions non
modiables dans la partie require & preserve.
1. Identifier la
partie insrer
2. Identifier la
partie prserver
3. Identifier la
partie supprimer
4. Identifier les pre-
conditions
5. Concevoir lopration
de reconfiguration
6. Valider et
consolider
7. Vrifier la
conformit
FIG. 6.3 La branche op eration de reconguration
La quatri` eme etape consiste ` a identier la liste des pr e-conditions, exprim ees avec le
langage OCL, pour chaque op eration de reconguration.
La cinqui` eme etape consiste ` a mod eliser lop eration de reconguration en utilisant les
r esultats des quatre etapes pr ec edentes.
La sixi` eme etape consiste ` a valider le mod` ele UML r esultant de chaque op eration de
reconguration par rapport ` a son m eta-mod` ele. Chaque mod` ele est transform e vers une
description XML qui sera elle m eme valid ee par rapport ` a son m eta-mod` ele repr esent e
par une description XSD (XML schema). La traduction du mod` ele UML vers XML
et la phase de validation sont automatiques gr ace au plug-in FUJABA que nous avons
d evelopp e.
La septi` eme etape consiste ` a v erier la conformit e de l evolution dune architecture
apr` es lex ecution dune op eration de reconguration vis-` a-vis de son style architectural.
La description XML est transform ee dune facon automatique, gr ace ` a des r` egles de
transformation impl ement ee et int egr ee dans le plug-in FUJABA, vers le langage Z. La
sp ecication r esultante est analys ee et le th eor` eme de conformit e est v eri e avec loutil
Z/EVES.
De m eme, les r esultats de cette branche appartiennent ` a la partie PIM. Ils ne d ependent
daucune technologie particuli` ere.
6.1.3 Branche protocole de reconguration
Cette branche, comme le montre la gure 6.4, recense lenchanement et lordre
dex ecution des diff erentes op erations de reconguration. Les etapes se d eroulent comme
suit :
La premi` ere etape consiste ` a identier les diff erentes op erations de reconguration.
La deuxi` eme etape consiste ` a identier les diff erents nuds de contr ole an de synchro-
niser les diff erentes op erations de reconguration.
La troisi` eme etape consiste ` a identier les diff erents liens de coordination an de relier
les diff erentes op erations de reconguration.
La quatri` eme etape consiste ` a mod eliser lenchanement de lex ecution des op erations
de reconguration en utilisant les r esultats des trois etapes pr ec edentes.
6.1 Description de la d emarche X 103
1. Identifier les
ReconfigurationOperation Nodes
2. Identifier les
ControlNodes
3. Identifier les Links
4. Concevoir le Protocol
de reconfiguration
5. Valider et
consolider
FIG. 6.4 La branche protocole de reconguration
La cinqui` eme etape consiste ` a valider le mod` ele UML r esultant du protocole de re-
conguration par rapport ` a son m eta-mod` ele. Chaque mod` ele est transform e vers une
description XML qui sera valid ee par rapport ` a son m eta-mod` ele repr esent e par une
description XSD (XML schema). La traduction du mod` ele UML vers XML et la phase
de validation sont automatiques gr ace au plug-in FUJABA que nous avons d evelopp e.
Les r esultats de cette branche appartiennent ` a la partie PIM. Ils ne d ependent daucune
technologie particuli` ere.
6.1.4 Branche fonctionnelle
1. Choisir le modle
de composant
2. Gnrer le code
3. Valider et
consolider
4. Assembler le
code
5. Simulation
FIG. 6.5 La branche fonctionnelle
La nalit e de cette branche, comme le montre la gure 6.5, est de transformer les mod` eles
PIM mod elis es vers un mod` ele PSM choisi. La transformation de mod` eles comporte es-
sentiellement deux etapes. La premi` ere consist ` a sp ecier les r` egles de transformation
exprimant la correspondance entre les concepts du m eta-mod` ele qui d ecrit le mod` ele
source et les concepts du m eta-mod` ele qui d ecrit le mod` ele cible. La deuxi` eme a pour
but dappliquer ces r` egles au mod` ele source pour produire le mod` ele cible. Nous pouvons
ainsi, par transformation de mod` eles, g en erer plusieurs PSM sp eciques ` a des plateformes
diff erentes ` a partir dun PIM unique (gure 6.6) [67].
Au cours des phases de d eveloppement dun syst` eme dans larchitecture MDA, la plupart
de ces transformations, comme le montre la gure 6.7, ont souvent besoin d etre r eit er ees
pour afner les divers mod` eles obtenus avant de passer ` a la g en eration de code.
La branche fonctionnelle inclut les etapes suivantes :
Modle PIM
PSM Plateforme
Serveur Java/EJB
PSM Plateforme
Serveur WebServices
PSM Plateforme
Serveur .Net
PSM Plateforme
Serveur Corba
Implmentation
Corba
Implmentation
EJB
Implmentation
XML/SOAP
Implmentation
.NET
Rgles de transformation
FIG. 6.6 Transformation dun mod` ele PIM vers diff erentes plateformes
PIM PSM Code
FIG. 6.7 Diff erentes op erations de transformation sur les mod` eles MDA
La premi` ere etape consiste ` a choisir le mod` ele de composant. Nous tracons donc la car-
tographie des composants du syst` eme ` a d evelopper et nous etudions ensuite comment
r ealiser chaque composant.
La deuxi` eme etape consiste ` a faire le codage, qui produit les composants en y int egrant
laspect m etier et teste au fur et ` a mesure les unit es de code r ealis ees.
La troisi` eme etape consiste ` a valider les fonctions de chaque composant d evelopp e.
La quatri` eme etape consiste ` a assembler les composants d evelopp e au sein dune m eme
application.
La cinqui` eme etape cest l etape nale qui consiste ` a simuler le fonctionnement global
du syst` eme d evelopp e.
Pour la branche fonctionnelle, nous avons fait quelques r eexions et nous avons pr esent e
quelques el ements de base. Des travaux plus avanc es sont en cours de d eveloppement au
sein de notre unit e de recherche ReDCAD.
6.2 Caract eristiques de la d emarche X
6.2.1 X produit des mod` eles r eutilisables
Les trois branches de la partie PIM capitalisent la description de la dynamique de larchi-
tecture logicielle de lapplication ` a d evelopper. Elle constitue g en eralement un investisse-
ment pour le moyen et le long terme. Larchitecture du syst` eme dinformation est en effet
ind ependante des technologies utilis ees.
Comme le montre la gure 6.8, les diff erents mod` eles produits de la partie PIM sont
6.2 Caract eristiques de la d emarche X 105
les m emes pour les diff erentes technologies de la partie PSM. Il suft de greffer une
nouvelle architecture technique pour mettre ` a jour un syst` eme existant.
Implmentation
Corba
Modle
darchitecture
Modle
darchitecture
(rutilis)
Configuration 1 Configuration 2
PIM
PSM
PIM
PSM
Implmentation
Java (EJB)
FIG. 6.8 R eutilisation du mod` ele PIM
6.2.2 D emarche it erative
Une it eration est une s equence distincte dactivit es, destin ee ` a etre ex ecut ee plusieurs fois
et autant de fois quon peut en avoir besoin. Elle permet de faire evoluer le syst` eme
dune conguration ` a une autre en produisant un changement du niveau architectural.
Le contenu dune it eration est porteur de corrections, dam eliorations et d evolutions du
syst` eme [127].
Dans notre d emarche nous proposons deux types dit erations : it eration sp ecique et
it eration g en erale. Lit eration sp ecique consiste ` a afner et ` a am eliorer un mod` ele dune
branche donn ee. Lit eration g en erale est corrective et consiste ` a retourner et ` a corriger les
erreurs d etect ees dun mod` ele.
Nous pr esentons les diff erentes etapes dune it eration possible.
La premi` ere it eration concoit le style architectural de lapplication ` a d evelopper.
La deuxi` eme it eration valide le style architectural et v erie sa consistance. Elle com-
mence la mod elisation des op erations de reconguration.
La troisi` eme it eration valide chaque op eration de reconguration et v erie sa confor-
mit e par rapport au style architectural. Elle commence ` a concevoir le protocole de re-
conguration.
La quatri` eme it eration valide le protocole de reconguration. Elle avance dans le choix
du mod` ele de composant et la g en eration de codes de mani` ere ` a pr esenter une premi` ere
version de d eploiement pour les utilisateurs. Elle permet entre-temps de corriger et
dam eliorer les it erations pr ec edentes.
La cinqui` eme it eration avance dans la r ealisation des fonctions jusqu` a lobtention
compl` ete du syst` eme initialement envisag e.
Chaque it eration passe en revue toutes les activit es de la d emarche X. Il est evident que
leffort consacr e ` a chaque activit e nest pas identique suivant la phase de d eveloppement
du projet. En cas derreurs, le retour est possible pour apporter les corrections n ecessaires.
6.2.3 D emarche incr ementale
Un incr ement est la diff erence entre deux evolutions produites ` a la n de deux
it erations successives. Une ou plusieurs it erations sinscrivent dans chacune des phases de
mod elisation du syst` eme et servent en cons equence ` a r ealiser lobjectif propre ` a chaque
phase [127].
Style
Architectural
OpR
1
S
Style
Architectural
S
OpRk OpRn OpR1
Style
Architectural
PSM PSM
PSM
PIM
Incrmentation 2
PIM
Incrmentation 1 Incrmentation 3
PIM
ProtocoleRec.
OpR
k
OpR
n
OpR
1
OpR
k
OpR
n
OpR
1
Style
Architectural
Style
Architectural
PSM PSM
PIM PIM
ProtocoleRec. ProtocoleRec.
Branche Fonctionnelle Branche Fonctionnelle
Incrmentation 4 Incrmentation 5
Final thse
FIG. 6.9 Un exemple dincr ementation
Comme le montre la gure 6.9, le syst` eme evolue par incr ement. A chaque it eration, de
nouvelles fonctionnalit es sont ajout ees et ce jusqu` a ce que toutes les fonctionnalit es de-
mand ees soient pr esentes. Le retour en arri` ere et tr` es co uteux, cest pourquoi le style ar-
chitectural doit etre bien pens e d` es la premi` ere phase.
Une ou plusieurs it erations sinscrivent dans chacune des phases de gestion de projet et
servent en cons equence ` a r ealiser lobjectif propre ` a chaque phase.
En phase de mod elisation du style architectural, les it erations servent ` a bien d enir les
types des composants et la liste des connexions ainsi que la d enition des contraintes
OCL. Par rafnement, cette phase sert ` a livrer le style architectural le mieux appropri e
aux besoins des utilisateurs.
En phase de mod elisation des op erations de reconguration, les it erations servent ` a bien
d enir et pour chaque op eration, la liste des composants et des connexions ` a ajouter, ` a
supprimer et non modiable ainsi que la d enition des contraintes OCL. Elles servent
6.2 Caract eristiques de la d emarche X 107
aussi ` a conrmer lad equation de chaque op eration de reconguration au style architec-
tural.
En phase de mod elisation du protocole de reconguration, les it erations servent ` a d enir
le s equencement et les diff erents enchanements possibles entre les op erations de recon-
guration.
En phase fonctionnelle, les it erations servent ` a impl ementer, tester et livrer progressive-
ment toutes les fonctionnalit es du syst` eme.
La d emarche de d eveloppement en X se reproduit ` a diff erents niveaux davancement en
se terminant sur la livraison dune nouvelle version. Elle offre la possibilit e de revenir sur
une ou plusieurs phases an de corriger et de faire evoluer le syst` eme.
6.2.4 D emarche de mod elisation ` a base dUML
La d emarche en X que nous proposons est bas ee sur UML. La majorit e des concepts et
des notations que nous avons pr esent es dans ce manuscrit sont bas es sur le prol UML
d ej` a d eni. En plus, les concepts de mod` ele et de m eta-mod` ele est inspir e du langage
UML.
6.2.5 D emarche centr ee sur larchitecture
Une d emarche centr ee sur larchitecture impose le respect du style architectural ` a chaque
etape de construction du syst` eme [127]. Le choix et la mod elisation du style architectural
est une etape fondamentale et la condition qui pr eside les autres etapes de conception et
de d eveloppement dun syst` eme. Elle permet la structuration (style architectural), le suivi
(op eration de reconguration) et la coh erence (protocole de reconguration).
Lutilisation dun style architectural coh erent permet d etablir des op erations pr ecises de
reconguration. Larchitecte utilise le style architectural pour faire evoluer son syst` eme
en mod elisant et en ex ecutant des op erations de reconguration. Il contr ole et coordonne
lex ecution de ces op erations en utilisant le protocole de reconguration. La d emarche
centr ee sur larchitecture permet donc dorganiser et de contr oler la mod elisation et
l evolution de larchitecture.
6.2.6 D emarche orient ee vers les composants
La d emarche que nous proposons manipule les composants, au sens UML du terme et au
sens architectural du terme. En effet, elle mod elise larchitecture logicielle en utilisant les
composants et les connexions.
Une fois que larchitecture de lapplication est mod elis ee, nous pouvons nous int eresser
aux fonctionnalit es propres du syst` eme. Le choix dun style architectural inuence la facon
dont seront organis es et d eploy es les composants du syst` eme. Un composant logiciel est
une partie du syst` eme logiciel qui doit etre connue, install ee, d eclar ee et manipul ee par
les exploitants du syst` eme. Les composants logiciels sont les el ements que lon d eploie
pour installer le syst` eme complet. Les composants sont des sous-parties du logiciel, de
sorte que chaque composant correspond ` a un sous-syst` eme de conguration logicielle.
Un composant doit etre interchangeable entre diff erentes versions et peut etre arr et e ou
d emarr e s epar ement. Il assume des fonctions bien identi ees dans le syst` eme, de sorte
quen cas de dysfonctionnement, le composant d efaillant est facilement rep erable [127].
6.3 Environnement de mod elisation
Pour que notre approche soit exp eriment ee, elle doit offrir aux utilisateurs les moyens pour
la manipuler. Pour cela, nous avons travaill e sur lextension de loutil FUJABA [28, 72]
an quil supporte notre approche. Nous avons ajout e deux Plug-ins Java. Le premier
offre des outils pour la mod elisation et la validation de la dynamique de larchitecture. Le
deuxi` eme offre des outils pour la transformation des mod` eles UML vers le langage Z et la
v erication. La v erication et la preuve des th eor` emes sont r ealis ees avec loutil Z/EVES.
FUJABA est un atelier qui a retenu notre attention en raison de son approche int eressante.
Cest un logiciel gratuit qui offre la possibilit e de modier le code source et dy ajouter des
plug-ins permettant ainsi dint egrer notre prol, de valider et de v erier nos sp ecications.
FUJABA
M dli ti UML
Transformation Gnrateur
Modlisation UML
Transformation
de Graphe
Gnrateur
de Code
Extension du Plug-in
Architectural
Diagrammes
Standard
de UML
Plug-in de
Modlisation
Plug-in de
Validation
Plug-in de
Transformation
Z
r
a
l
nnnn
t
y
l
e

A
r
c
h
i
t
e
c
t
u
r
O
p
r
a
t
i
o
n
s

d
e
R
e
c
o
n
f
i
g
u
r
a
t
i
o
n
P
r
o
t
o
c
o
l
e

d
e

R
e
c
o
n
f
i
g
u
r
a
t
i
o
n
I
n
t
r
a
-
V
a
l
i
d
a
t
i
o
n
I
n
t
e
r
-
V
a
l
i
d
a
t
i
o
n
S
t
thse thse
FIG. 6.10 Extension de loutil FUJABA
Lextension que nous avons propos ee, comme le montre la gure 6.10, offre essentielle-
ment trois fonctionnalit es. La premi` ere permet de mod eliser la dynamique de larchitec-
ture logicielle. La deuxi` eme permet de transformer les mod` eles UML vers le langage XML
6.3 Environnement de mod elisation 109
et de les valider par rapport ` a leurs m eta-mod` eles correspondants. La troisi` eme permet de
transformer les descriptions XML vers le langage Z an de v erier certaines propri et es.
6.3.1 Mod elisation
Le prol propos e a fait lobjet dune impl ementation et dune int egration dans latelier
daide ` a la conception FUJABA. Lextension que nos avons r ealis ee, sous forme dun
Plug-in java, permet dans un premier temps la mod elisation de la dynamique de larchi-
tecture logicielle. Pour ce faire, le plug-in offre trois interfaces, equip ee chacune par une
barre ` a outil, permettant de mod eliser le style architectural (gure 6.11), les op erations de
reconguration (gure 6.12) et le protocole de reconguration (gure 6.13).
PMS
ArchitecturalStyle Diagram_1
ArchitecturalStyle
t
i
l
s
PMS
EventService
B
a
r
r
e

O
u
t
Patient
Nurse
inv NbEventService:
EventService.allInstances size <= 3 and EventService.allInstances size >0
Guards
EventService.allInstances size 3 and EventService.allInstances size 0
inv NbEventServiceNurse:
EventService.allInstances forAll(es:EventService | ((es.nurse size <=5) and
(es.patient size <=15)))
context Patient
inv NbPatientEventService:
Patient.allInstances forAll(p:Patient | ((p.eventService size =1) and (p.nurse size =1)))
context Nurse
inv NbNurseEventService:
Nurse allInstances forAll(n: Nurse | ((n eventService size =1) and (n patient size <=3))) Nurse.allInstances forAll(n: Nurse | ((n.eventService size =1) and (n.patient size <=3)))
EventServicesize() <= 3 and EventServicesize()>0
EventServiceforAll(EventService.nursesize() <=5 and EventService.patientsize() <=15)
PatientforAll(Patient.EventServicesize()=1)
PatientforAll(Patient.nursesize()=1)
NurseforAll(Nurse.EventServicesize()=1)
NurseforAll(Nurse.patientsize()<=3)
EventServiceforAll(EventService.patientnotEmpty() implies
EventService.nursenotEmpty()) p y())
FIG. 6.11 Interface pour la mod elisation
du style architectural
ReconfigurationOperationName g p
Insert_Nurse(x, y)
Require&Delete Require&Preserve Insert
B
a
r
r
e

O
u
t
i
l
s
y:Nurse
X:EventService
Guards
context Nurse::InsertNurse(x : EventService, y : Nurse) : Boolean
pre InsertN:
EventService.allInstances size > 0 and x.nurse size < 5
FIG. 6.12 Interface pour la mod elisation
des op erations de reconguration
Insert_Nurse(x,y)
Insert_Patient(x,y,z)
Insert_EventService(x)
B
a
r
r
e

O
u
t
i
l
s
FIG. 6.13 Interface pour la mod elisation du protocole de reconguration
6.3.2 Validation
Le plug-in impl ement e permet la transformation automatique des mod` eles UML vers le
langage XML. Cette transformation est assur ee en cliquant sur le bouton Export To XML
(gure 6.14).
FIG. 6.14 Transformation des mod` eles UML vers des descriptions XML
Nous pr esentons ici la description XML g en er ee automatiquement ` a partir de notre plug-
in. Le script XML ci-dessous est relatif ` a l etude de cas PMS et d ecrit le style architectural
que nous avons pr esent e dans la section 3.4.1.
1 <?xml version="1.0" encoding="UTF-8"?>
2 <ArchitecturalStyleM-M
3 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
4 xsi:noNamespaceSchemaLocation="ArchitecturalStyleMM.xsd">
5 <ArchitecturalStyleName ArchitecturalStyleName="PMS"/>
6 <ArchitecturalStyleFeature>
7 <Component>
8 <NameComponent NameComponent="EventService"/>
9 <Port>
10 <NamePort NamePort="EventService.P1"/>
11 <Interface Type="Provided">
12 <NameInterface NameInterface="EventService.P1.I1"/>
13 </Interface>
14 </Port>
15 <Port>
19 </Interface>
20 </Port>
21 <Port>
23 <Interface Type="Required">
25 </Interface>
26 </Port>
27 <Port>
31 </Interface>
32 </Port>
33 </Component>
34 <Component>
35 <NameComponent NameComponent="Patient"/>
36 <Port>
37 <NamePort NamePort="Patient.P1"/>
39 <NameInterface NameInterface="Patient.P1.I1"/>
40 </Interface>
41 </Port>
42 <Port>
46 </Interface>
47 </Port>
48 <Port>
52 </Interface>
53 </Port>
54 <Port>
58 </Interface>
59 </Port>
60 </Component>
61 <Component>
62 <NameComponent NameComponent="Nurse"/>
63 <Port>
64 <NamePort NamePort="Nurse.P1"/>
66 <NameInterface NameInterface="Nurse.P1.I1"/>
67 </Interface>
68 </Port>
69 <Port>
73 </Interface>
74 </Port>
75 <Port>
79 </Interface>
80 </Port>
81 <Port>
85 </Interface>
86 </Port>
87 </Component>
88 <Connector Type="Assembly">
89 <NameConnector NameConnector="EventService.P1.I1_TO"/>
90 </Connector>
92 <NameConnector NameConnector="Patient.P1_TO_EventService.P1"/>
93 </Connector>
95 <NameConnector NameConnector="Nurse.P1_TO_EventService.P2"/>
96 </Connector>
98 <NameConnector NameConnector="Patient.P3_TO_Nurse.P3"/>
99 </Connector>
101 <NameConnector NameConnector="EventService.P3_TO_Patient.P2"/>
102 </Connector>
104 <NameConnector NameConnector="EventService.P4_TO_Nurse.P2"/>
105 </Connector>
106 </ArchitecturalStyleFeature>
107 <Guards>
108 <Constraint>context EventService
109 inv NbEventService:
110 EventService.allInstances->size <= 3 and EventService.allInstances->size >0
111 </Constraint>
113 inv NbEventServiceNurse:
114 EventService.allInstances->forAll(es:EventService | ((es.nurse?size <=5) and
115 (es.patient->size <=15)))
116 </Constraint>
117 <Constraint>context Patient
118 inv NbPatientEventService:
119 Patient.allInstances->forAll(p:Patient | ((p.eventService->size =1) and
120 (p.nurse->size =1)))
121 </Constraint>
122 <Constraint>context Nurse
123 inv NbNurseEventService:
124 Nurse.allInstances->forAll(n: Nurse | ((n.eventService->size =1) and
125 (n.patient->size<=3)))
126 </Constraint>
128 inv ExNurseEventService:
129 EventService.allInstances->forAll(es | es.patient->notEmpty implies
130 es.nurse->notEmpty)
131 </Constraint>
132 </Guards>
133 </ArchitecturalStyleM-M>
Apr` es la transformation vers XML, nous passons ` a la phase de validation. Celle-ci consiste
` a tester que les mod` eles g en er es (description XML) sont conformes ` a leurs m eta-mod` ele
(XML sch ema).
FIG. 6.15 Validation des mod` eles XML par rapport ` a leur XML sch ema
Les descriptions XML sch ema (XSD) sont enregistr ees dans un dossier de loutil FU-
JABA. Pour montrer la validit e dune description XML par rapport ` a son XML sch ema,
nous utilisons des outils XML an de v erier la bonne formation de la description XML et
pour montrer la conformit e du mod` ele (description XML) par rapport ` a son m eta-mod` ele
(description XML sch ema). Il faut v erier que la description XML est une instance de son
XML sch ema correspondant.
Dans lent ete de chaque description XML g en er e, le chemin permettant dacc eder
au chier XSD correspondant est ajout e dune facon automatique dans lattribut
xsi :noNamespaceSchemaLocation (ligne 3).
1 <?xml version="1.0" encoding="UTF-8"?> <ArchitecturalStyleM-M
2 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
3 xsi:noNamespaceSchemaLocation="ArchitecturalStyleMM.xsd">
4 ...
Le plug-in, gr ace ` a des modules Java, permet aussi de v erier les r` egles intra-mod` ele tels
que lunicit e des noms des composants, des noms des connecteurs, des noms des ports,
etc. Il automatise aussi les r` egles inter-mod` eles permettant le passage dun mod` ele ` a un
autre.
6.3.3 Transformation vers Z
Apr` es la validation, nous passons ` a la phase de transformation des mod` eles XML vers le
langage Z. Cette transformation est r ealis ee dune facon automatique gr ace ` a notre plug-in
en cliquant sur le bouton UML to Z.
An dimpl ementer le module UML to Z et de lint egrer dans loutil FUJABA, nous avons
suivi les etapes suivantes :
D eveloppement des chiers n ecessaires : programmes java et classes daction : plug-
in.xml et stable.xml.
Le chier plug-in.xml contient des informations g en erales sur le plug-in tels que son
nom et sa version. Le chier stable.xml d enit les el ements ` a ajouter dans linterface
graphique de loutil FUJABA.
D eploiement des chiers d evelopp es et cr eation du chier JAR qui encapsule les classes
JAVA, ainsi que les classes daction.
Installation du plug-in.
Nous pr esentons ici, le chier stable.xml. Il permet de d enir la barre des menus, les
sous-menu, les menus ottants ainsi que les actions ` a ex ecuter.
1
2 <UserInterface>
3 
4 <Action id="MyPlugin.newMyDiagram" class="de.upb.myplugin.actions.
5 NewArchitecturalDiagramAction" enabled="true">
6 <Name>New Architectural Diagram</Name>
7 <Mnemonic>w</Mnemonic>
8 <ToolTip>Create a new Architectural Diagram</ToolTip>
9 <Icon>de/upb/myplugin/images/none.gif</Icon>
10 </Action>
11 <Action id="MyPlugin.newMyComponent" class="de.upb.myplugin.actions.
12 NewMyComponentAction" enabled="true">
13 <Name>Create a new Component</Name>
14 <Mnemonic>C</Mnemonic>
15 <ToolTip>Create a new Component</ToolTip>
16 <Icon>de/upb/myplugin/images/compo.gif</Icon>
17 </Action>
18 <Action id="MyPlugin.newMyConnection" class="de.upb.myplugin.actions.
19 NewMyConnectionAction" enabled="true">
20 <Name>Create an Assembly Connector</Name>
21 <Mnemonic>O</Mnemonic>
22 <ToolTip>Create an Assembly Connector</ToolTip>
23 <Icon>de/upb/myplugin/images/assembly.gif</Icon>
24 </Action>
25 <Action id="MyPlugin.newMyDelegation" class="de.upb.myplugin.actions.
26 NewMyDelegationAction" enabled="true">
27 <Name>Create a Delegation Connector</Name>
28 <Mnemonic>g</Mnemonic>
29 <ToolTip>Create a Delegation Connector</ToolTip>
30 <Icon>de/upb/myplugin/images/delegation.gif</Icon>
31 </Action>
32 ...
33 <Action id="umltoz_id" class="de.upb.umltoz.actions.ShowUMLTOZDialog"
34 enabled="true">
35 <Name>UML to Z</Name>
36 <Mnemonic>m</Mnemonic>
37 <ToolTip>UML to Z</ToolTip>
38 </Action>
39 
40 <MenuBar id="mainMenuBar">
41 <MenuSection id="diagramsMenuSection">
42 <Menu id="diagramsMenu">
43 <MenuSection id="newDiagramSection">
44 <MenuItem actionId="MyPlugin.newMyDiagram"/>
45 </MenuSection>
46 </Menu>
47 </MenuSection>
48 <MenuSection id="diagramSpecificSection">
49 <Menu id="MyPlugin.myDiagramMenu" visible="false">
50 <Name>Architectural Diagram</Name>
51 <Mnemonic>M</Mnemonic>
52 <MenuSection id="MyPlugin.myDiagramMenu.newSection">
53 <MenuItem actionId="MyPlugin.newMyComponent"/>
54 <MenuItem actionId="MyPlugin.newMyConnection"/>
55 <MenuItem actionId="MyPlugin.newMyDelegation"/>
56 ...
57 </MenuSection>
58 </Menu>
59 <MenuSection id="diagramSpecificSection">
60 <Menu id="Ztools_id" visible="true">
61 <Name>Z tools</Name>
62 <Mnemonic>z</Mnemonic>
63 <MenuSection id="Ztools_id.umltoz">
64 <MenuItem actionId="umltoz_id"/>
65 </MenuSection>
66 </Menu>
67 </MenuSection>
68 </MenuBar>
69 
70 <PopupMenu class="de.upb.myplugin.metamodel.MyComponent">
71 <MenuSection id="de.upb.myplugin.menusection">
72 <MenuItem actionId="MyPlugin.newMyComponent"/>
73 <MenuItem actionId="MyPlugin.newMyPort"/>
74 <MenuItem actionId="MyPlugin.newMyConstraint"/>
75 <MenuItem actionId="MyPlugin.EditComponent"/>
76 </MenuSection>
77 </PopupMenu>
78 <PopupMenu class="de.upb.myplugin.metamodel.MyConnection">
79 <MenuSection id="de.upb.myplugin.bendmenusection">
80 <MenuItem actionId="MyPlugin.newBend"/>
81 <MenuItem actionId="MyPlugin.AddToInsert"/>
82 <MenuItem actionId="MyPlugin.AddToDelete"/>
83 <MenuItem actionId="deleteBend"/>
84 </MenuSection>
85 </PopupMenu>
86 ...
87 
88 <ToolBar id="MyPlugin.myDiagramToolBar" rolloverButtons="true" visible="false">
89 <ToolBarSection id="MyPlugin.myDiagramToolBar.newSection">
90 <Button actionId="MyPlugin.newMyComponent"/>
91 <Button actionId="MyPlugin.newMyPort"/>
92 <Button actionId="MyPlugin.newMyInterfaceRequired"/>
93 <Button actionId="MyPlugin.newMyInterfaceProvided"/>
94 <Button actionId="MyPlugin.newMyConnection"/>
95 <Button actionId="MyPlugin.newMyDelegation"/>
96 <Button actionId="exportoXML"/>
97 ...
98 </ToolBarSection>
99 </ToolBar>
100 </UserInterface>
FIG. 6.16 Linterface UML to Z
En cliquant sur le sous-menu UML to Z, linterface UML To Z est afch ee (gure 6.16).
Cette fen etre permet dajouter les descriptions XML (le style architectural et les diff erentes
op erations de reconguration) an de les transformer vers le langage Z.
Le module transformation vers Z recoit en entr ee une description XML. Il la transforme
selon les r` egles de transformation et les grammaires d enies pour g en erer un chier L
A
T
E
X
(.tex) selon une structure bien d etermin ee.
Nous avons choisi L
A
T
E
X comme format de sortie car il est support e par loutil de
v erication Z/EVES. La gure 6.17 d ecrit la transformation du style architectural vers
le langage Z.
sub_EventService : EventService
sub_Patient : Patient
sub_Nurse : Nurse
PMS
EventServiceToPatient : EventService Patient
dom NurseToEventService sub_Nurse ran NurseToEventService sub_EventService
dom NurseToPatient sub_Nurse ran NurseToPatient sub_Patient
dom PatientToEventService sub_Patient ran PatientToEventService sub_EventService
dom PatientToNurse sub Patient ran PatientToNurse sub Nurse
28-02\VersionFinale\ArchitecturalStyleMM.xml
dom PatientToNurse sub_Patient ran PatientToNurse sub_Nurse
dom EventServiceToNurse sub_EventService ran EventServiceToNurse sub_Nurse
dom EventServiceToPatient sub_EventService ran EventServiceToPatient sub_Patient
#sub_EventService 3 #sub_EventService > 0
x : sub_EventService #(EventServiceToNurse(x)) 5
x : sub_EventService #(EventServiceToPatient(x)) 15
x : sub_Patient #(PatientToEventService(x)) = 1
x : sub_Patient #(PatientToNurse(x)) = 1
x : sub_Nurse #(NurseToEventService(x)) = 1
x : sub_Nurse #(NurseToPatient(x)) 3
x : sub_EventService EventServiceToPatient(x) EventServiceToNurse(x)
FIG. 6.17 Transformation du style architectural vers le langage Z
FIG. 6.18 V erication et preuve avec Z/EVES
6.4 Conclusion 117
Apr` es la g en eration, les chiers L
A
T
E
X seront reproduits pour y ajouter les th eor` emes an
de les prouver en utilisant loutil Z/EVES (gure 6.18).
6.4 Conclusion
Nous avons pr esent e dans ce chapitre, une d emarche de mod elisation des architectures
logicielles dynamiques. Cette d emarche appel ee X permet de d ecrire les diff erentes etapes
pour mod eliser larchitecture logicielle. Elle propose des r` egles de passage dun mod` ele ` a
un autre. Elle automatise le processus de validation et assiste lutilisateur pour v erier la
consistance du style architectural et la conformit e de l evolution de larchitecture vis-` a-vis
de son style architectural. La d emarche propos ee est inspir ee de lapproche MDA et 2TUP
du processus UP.
Pour que notre approche soit exploit ee, elle doit offrir aux utilisateurs les moyens pour
la manipuler. En effet, le prol propos e, lapproche de validation et de v erication ainsi
que la d emarche X ont fait lobjet dune impl ementation et dune int egration, sous forme
de plug-ins java, dans latelier daide ` a la conception FUJABA. Les plug-ins impl ement es
sont disponibles sur lURL : http ://www.laas.fr/khalil/TOOLS/X.zip
118 Conclusion
Conclusion
Bilan des contributions
Dans ce m emoire, nous avons pr esent e lensemble des travaux r ealis es dans le cadre de
cette th` ese. Nous avons pass e en revue l etat de lart et nous avons etudi e la litt erature
concernant les domaines de recherche abord es. Nous avons introduit les concepts relatifs
aux architectures dynamiques en nous basant sur les standards et les travaux de recherche.
Nous avons pr esent e les langages de description des architectures les plus utilis es et les
plus publi es. Nous avons mis laccent sur les m ecanismes de sp ecication d enis, an de
mettre en relief les avantages et les limites de ces diff erents langages. Nous avons pr esent e
egalement les travaux sur la reconguration des architectures, au moyen dUML et des
techniques de r e ecriture de graphes. Enn, nous avons pr esent e un bilan des travaux qui
proposent des approches diverses et combin ees.
Grace ` a cette etude et an de r eduire les limites des autres approches et an de pro-
poser une solution en vue de g erer l evolution dynamique des architectures logicielles,
conformes ` a lapproche guid ee par les mod` eles, nous avons propos e une approche qui
etend la notation UML 2.0. Cest une approche de description orient ee r` egles, bas ee sur
la transformation de graphe, permettant, ainsi, de d ecrire la dynamique structurelle sous
forme dop erations de reconguration.
Le Prol UML propos e apporte plusieurs solutions aux diff erentes limites identi ees pour
le traitement des architectures dynamiques. Ce prol, offre trois m eta-mod` eles et utilise
une notation uni ee et graphique bas ee sur la notation UML 2.0. Ce Prol utilise les
grammaires de graphes offrant ainsi la possibilit e de d ecrire laspect dynamique. Le pre-
mier m eta-mod` ele etend le diagramme de composants et d ecrit la structure de larchitec-
ture en termes de composants et de connexions entre les composants. Le deuxi` eme etend
le premier m eta-mod` ele et d ecrit la dynamique structurelle de larchitecture en termes
dop erations de reconguration. Dans notre approche, nous nous sommes int eress es uni-
quement ` a la dynamique structurelle (ajout et/ou suppression de composants et/ou de
connexions). Le troisi` eme m eta-mod` ele etend le diagramme dactivit es et permet de
d ecrire lenchanement et lordre dex ecution des op erations de reconguration.
An de valider les mod` eles construits nous avons propos e une approche de validation
` a base de r` egles intra-mod` ele et de r` egles inter-mod` eles. Ces r` egles sont utilis ees pour
faciliter lidentication des eventuelles incoh erences an de d etecter toute utilisation in-
120 Conclusion
correcte du prol propos e. La validation que nous avons propos ee est structurelle et ` a base
du langage XML.
De m eme, nous avons elabor e une technique de v erication. Elle assure, dans une premi` ere
etape, la transformation dune sp ecication, ` a partir du m eta-mod` ele Style Architectural
et Op eration de Reconguration, au langage Z. Les sp ecications Z g en er ees permettent,
dans une deuxi` eme etape, de v erier la consistance et la conformit e de larchitecture.
Nous avons propos e egalement une d emarche de mod elisation permettant de d ecrire les
diff erentes etapes pour mod eliser la dynamique de larchitecture logicielle. Elle propose
des r` egles de passage dun mod` ele ` a un autre, elle automatise le processus de validation et
assiste lutilisateur pour v erier certaines propri et es architecturales.
Le prol, lapproche de validation et de v erication ainsi que la d emarche X propos es ont
fait lobjet dune impl ementation et dune int egration, sous forme de plug-in java, dans
latelier daide ` a la conception FUJABA. Les plug-ins impl ement es sont disponibles sur
lURL : http ://www.laas.fr/khalil/TOOLS/X.zip.
Perspectives
Les perspectives des travaux pr esent es dans ce m emoire suivent diff erents axes de
r eexion et se situent dans les diff erents contextes de recherche.
A court terme, nous pr evoyons dam eliorer lapproche de v erication en ajoutant dautres
propri et es ` a v erier autres que la consistance et la conformit e des op erations de recon-
guration par rapport au style architectural.
Pour la partie protocole de reconguration, nous pr evoyons dachever la partie transfor-
mation permettant de traduire la description XML g en er ee vers un langage formel. Nous
pr evoyons dutiliser les r eseaux de p etri pour v erier la vivacit e des diff erentes op erations
de reconguration et que chaque op eration de reconguration sera ex ecut ee au moins une
fois.
Nous pr evoyons de travailler sur la branche fonctionnelle de la d emarche X, an de
g en erer par rafnement un code source conform ement ` a un mod` ele de composant choisi.
Lapplication sera d eploy ee pour tester et g erer l evolution de larchitecture dune facon
dynamique.
A moyen terme, nous pr evoyons dutiliser les politiques dadaptation. Notre approche sera
guid ee par un mod` ele de contexte et des politiques dadaptation (pour d ecrire les r` egles
de reconguration). Ces politiques seront d ecrites sous la forme E-C-A (on Ev enement if
Condition then Action) et en utilisant un ensemble dop erations de reconguration (ajout
et suppression de composants et ajout et suppression de connexions). Ces politiques seront
d ecrites dans une description XML s epar ee de lapplication, ce qui permet sa modication
dynamique (m eme pendant lex ecution de lapplication). Les plans de reconguration se-
ront exprim es avec un langage formel an de garantir leurs validit es, leurs consistances et
leurs coh erences.
Conclusion 121
An de rester dans un cadre compatible avec la r eutilisation des notations UML, nous
pr evoyons de confronter le prol propos e par lutilisation du paquetage Proles des ver-
sions r ecentes dUML.
A long terme, nous pr evoyons dint egrer notre approche avec les autres travaux r ealis es
au sein de notre unit e de recherche ReDCAD de Sfax et les autres travaux r ealis es au
sein de l equipe OLC de LAAS-CNRS. Cette int egration permettra davoir une approche
compl` ete assurant la mod elisation, la validation, la v erication, la g en eration de code
ex ecutable, le d eploiement de lapplication et le contr ole (monitoring) dans le but das-
surer lauto-r eparation.
122 Publications de lauteur
Publications de lauteur
[1] Mohamed Hadj Kacem, Mohamed Jmaiel, and khalil Drira. Vers un environnement
dadministration des applications coop eratives distribu ees. In GEI02 : Proceedings des
2
eme
Journ ees Scientiques des Jeunes Chercheurs en G enie Electrique et Informatique,
page 4p, Hammamet, Tunisia, 2002.
[2] Mohamed Hadj Kacem, Mohamed Jmaiel, Ahmed Hadj Kacem, and khalil Drira.
Environnement pour ladministration des applications distribu ees ` a base de composants.
In JSF03 : Proceedings des Journ ees Scientiques Francophones, Tozeur, Tunisia, 2003.
[3] Mohamed Hadj Kacem, Mohamed Jmaiel, Ahmed hadj Kacem, and khalil Drira.
Evaluation and comparison of adl based approaches for the description of dynamic
software architectures. In ICEIS05 : Proceedings of the 7
th
International Conference on
Enterprise Information Systems, pages 189195, Miami, USA, 2005. INSTICC Press.
Using UML2.0 and GG for describing the dynamic of software architectures. In
ICITA05 : Proceedings of the Third International Conference on Information Technology
and Applications, pages 4651, Sydney, Australia, 2005. IEEE Computer Society.
[5] Mohamed Hadj Kacem, Mohamed Nadhmi Miladi, Mohamed Jmaiel, Ahmed Hadj
Kacem, and khalil Drira. Towards a UML prole for the description of dynamic
software architectures. In COEA05 : Proceedings of the International Conference on
Component-Oriented Enterprise Applications, volume 70 of Lecture Notes in Informatics,
pages 2539, Erfurt, Germany, 2005.
Describing dynamic software architectures using an extended UML model. In SAC06 :
Proceedings of the 21
st
Annual Symposium on Applied Computing, Track-Model Trans-
formation, pages 2327, Dijon, France, 2006. ACM.
[7] Mohamed Hadj Kacem, Mohamed Jmaiel, , Ahmed Hadj Kacem, and khalil Drira. An
124 Publications de lauteur
UML-based approach for validation of software architecture descriptions. In TEAA06 :
nd
International Conference on Trends in Enterprise Application
Architecture, volume 4473 of Lecture Notes in Computer Science, pages 158171, Berlin,
Germany, 2007. Springer.
[8] Mohamed Nadhmi Miladi, Mohamed Jmaiel, and Mohamed Hadj Kacem. A UML
prole and a FUJABA plugin for modelling dynamic software architectures. In MoD-
SE07 : Proceedings of the Workshop on Model-Driven Software Evolution, pages 2023,
Amsterdam, Netherlands, 2007. IEEE Computer Society.
[9] Mohamed Nadhmi Miladi, Mohamed Hadj Kacem, Achraf Bouchriss, Mohamed
Jmaiel, and khalil Drira. A UML rule-based approach for describing and checking dy-
namic software architectures. In AICCSA08 : Proceedings of the 6
th
ACS/IEEE Inter-
national Conference on Computer Systems and Applications, Doha, Qatar, 2008. IEEE
Computer Society.
Bibliographie
[1] Gregory Abowd, Robert Allen, and David Garlan. Using + style to understand des-
criptions of software architecture. SIGSOFT Software Engineering Notes, 18(5) :9
20, 1993.
[2] Gregory Abowd, Robert Allen, and David Garlan. Formalizing style to understand
descriptions of software architecture. ACM Transactions on Software Engineering
and Methodology, 4(4) :319364, 1995.
[3] Jean-Raymond Abrial. Programming as a mathematical exercise. In Charles An-
tony Richard Hoare and John C. Shepherdson, editors, Mathematical Logic and
Programming Languages, pages 113137. Prentice-Hall International, 1985.
[4] Accord. Assemblage de composants par contrats en environnement ouvert et
r eparti, etat de lart sur les langages de description darchitecture (ADLs). Pro-
jet ACCORD, Technical Report Livrable 1.1-2, RNTL, France, Juin 2002.
[5] Nazareno Aguirre and Tom Maibaum. A temporal logic approach to the specica-
tion of recongurable component-based systems. In ASE02 : Proceedings of the
17
th
IEEE international conference on Automated software engineering, 23-27 Sep-
tember 2002, Edinburgh, Scotland, UK, pages 271274, Edinburgh, Scotland, UK,
September 2002.
[6] David Akehurst and Octavian Patrascoiu. OCL 2.0 - implementing the standard for
multiple metamodels. UML 2003 preliminary version, technical report, Computing
Laboratory, University of Kent, Canterbury, UK, Janvier 2003.
[7] Jonathan Aldrich, Craig Chambers, and David Notkin. Architectural reasoning in
archjava. In ECOOP02 : Proceedings of the 16
th
European Conference on Object-
Oriented Programming, pages 334367, London, UK, 2002. Springer.
[8] Robert Allen, Remi Douence, and David Garlan. Specifying and analyzing dyna-
mic software architectures. In FASE98 : Proceedings of the 1998 Conference on
Fundamental Approaches to Software Engineering, pages 2137, Lisbon, Portugal,
March 1998.
[9] Robert Allen and David Garlan. A formal basis for architectural connection. ACM
Transactions on Software Engineering and Methodology, 6(3) :213249, 1997.
[10] Sylvain Andre. MDA (model driven architecture) principes et etats de lart. Tech-
nical report, CNAM, 05 Novembre 2004.
126 BIBLIOGRAPHIE
[11] Egidio Astesiano and Gianna Reggio. Towards a well-founded UML-based de-
velopment method. pages 102115, Brisbane, Australia, 2003. IEEE Computer
Society.
[12] Thomas Baar. OCL and graph-transformations - a symbiotic alliance to alleviate
the frame problem. In MoDELS Satellite Events, volume 3844 of Lecture Notes in
Computer Science, pages 2031. Springer, 2005.
[13] Olivier Barais. Approche statique, dynamique et globale de larchitecture dappli-
cations r eparties. Master report, Ecole Mine de Douai, Laboratoire dInformatique
fondamentale de Lille, Juillet 2002.
[14] Luciano Baresi, Reiko Heckel, Sebastian Th&#246 ;ne, and D&#225 ;niel
Varr&#243 ;. Modeling and validation of service-oriented architectures : applica-
tion vs. style. In ESEC/FSE-11 : Proceedings of the 9
th
European software engi-
neering conference held jointly with 11th ACM SIGSOFT international symposium
on Foundations of software engineering, pages 6877, New York, NY, USA, 2003.
ACM Press.
[15] Luciano Baresi, Reiko Heckel, Sebastian Thone, and Daniel Varro. Style-based
renement of dynamic software architectures. In WICSA04 : Proceedings of the
4
th
Working International IEEE/IFIP Conference on Software Architecture, pages
155164, Oslo, Norway, 2004. IEEE Computer Society.
[16] Luc Bellissard, Slim Ben Atallah, Alain Kerbrat, and Michel Riveill. Component-
based programming and application management with Olan. In OBPDC95 :
Object-Based Parallel and Distributed Computation, pages 290309, 1995.
[17] Pam Binns, Matt Englehart, Mike Jackson, and Steve Vestal. Domain-specic soft-
ware architectures for guidance, navigation and control. International Journal of
Software Engineering and Knowledge Engineering, 6(2) :201227, 1996.
[18] Andrew D. Birrell and Bruce Jay Nelson. Implementing remote procedure call.
ACM Transactions on Computer Systems, 2(1) :3959, February 1984.
[19] Morgan Bj orkander and Cris Kobryn. Architecting systems with UML 2.0. IEEE
Software, 20(4) :5761, 2003.
[20] Xavier Blanc. MDA en action : Ing enierie logicielle guid ee par les mod` eles. Ey-
rolles, 2005.
[21] Maarten Boasson. The artistry of software architecture. IEEE Software, 12(6) :13
16, 1995.
[22] Behzad Bordbar, Luisa Giacomini, and D.J. Holding. UML and petri nets for design
and analysis of distributed systems. In Proceedings of the 2000 IEEE International
Conference on Control Applications, pages 610615, Alaska, USA, 2000.
[23] Lopez Pere Botella, Franch-Guti errez Xavier, and Josep M. Rib o-Balust. Software
process modelling languages based on UML. The European Journal for the Infor-
matics Professional, 5(5) :3439, 2004.
[24] Thouraya Bouabana-Tebibel and Mounira Belmesk. Formalization of UML object
dynamics and behavior. In SMC05 : Proceedings of the IEEE International Confe-
rence on Systems, Netherlands, 10-13 October, pages 49714976. IEEE, 2004.
BIBLIOGRAPHIE 127
[25] Pearl Brereton and David Budgen. Component-based systems : A classication of
issues. IEEE Computer, 33(11) :5462, 2000.
[26] Jean-Michel Bruel. UML et Mod elisation de la Composition Logicielle. Habilita-
tion ` a diriger des recherches, Universit e de Pau et des Pays de lAdour, Universit e
de Pau et des Pays de lAdour, D ecembre 2006.
[27] Doug Bryan. Using rapide to model and specify inter-object behavior. In OOPS-
LA94 : Proceedings of the Workshop on Precise Behavioral Specications in OO
Information Modeling, volume 29 de SIGPLAN Notices, pages 579595. ACM
Press, Mai 1994.
[28] Sven Burmester, Holger Giese, Martin Hirsch, Daniela Schilling, and Matthias Ti-
chy. The fujaba real-time tool suite : Model-driven development of safety-critical,
real-time systems. In ICSE05 : Proceedings of the 27
th
International Conference
on Software Engineering , St. Louis, Missouri, USA, pages 670671. ACM Press,
May 2005.
[29] Jean B ezivin, Jean-Paul Bouchet, and Erwan Breton. Correspondance structurelle
entre produits et proc ed es : un pattern classique, analys e avec des m eta-mod` eles
explicites. In Journ ee GRACQ : Mod` eles, Objets et composants., pages 122, Juin
1999.
[30] Cyril Carrez. Contrats Comportementaux pour Composants. Phd thesis, l ecole Na-
tionale Sup erieure des T el ecommunications, Sp ecialit e : Informatique et R eseaux,
D ecembre 2003.
[31] Christelle Chaudet. P-Space : Langage et outils pour la description darchitectures
evolutives ` a composants dynamiques. Formalisation darchitectures logicielles et
industrielles. Phd thesis, Universit e de Savoie, D ecembre 2002.
[32] Christelle Chaudet and Flavio Oquendo. P-space : A formal architecture descrip-
tion language based on process algebra for evolving software systems. In ASE00 :
th
IEEE international conference on Automated software en-
gineering, pages 245248, Washington, DC, USA, 2000. IEEE Computer Society.
[33] Christelle Chaudet and Flavio Oquendo. P-space : Modeling evolvable distributed
software architectures. In PDPTA01 : Proceedings of International Conference
on Parallel and Distributed Processing Techniques and Applications, Monte Carlo
Resort, Las Vegas, Juin 2001.
[34] B. Chen and S. Sadaoui. Lotos : Theories and tools. Technical report, Department
of Computer Science, U. of Regina, November 2003.
[35] Giulio Concas, Ernesto Damiani, Marco Scotto, and Giancarlo Succi, editors. Agile
Processes in Software Engineering and Extreme Programming, volume 4536 of
Lecture Notes in Computer Science, Italy, June 2007. Springer.
[36] Steve Cook. The UML family : Proles, prefaces and packages. In UML00 : Pro-
ceedings of the 3
rd
International Conference on The Unied Modeling Language.
Advancing the Standard, volume 1939 of Lecture Notes in Computer Science, pages
255264, York, UK, 2000. Springer.
128 BIBLIOGRAPHIE
[37] V. Cortellessa, A. Di Marco, P. Inverardi, H. Muccini, and P. Pelliccione. Using uml
for sa-based modeling and analysis. In Proceedings of the Modeling Languages
and Applications, UML Satellite Activities, Lecture Notes in Computer Science,
page 15. Springer, 2005.
[38] Thierry Coupaye, Romain Lenglet, Mikael Beauvois, Eric Bruneton, and Pas-
cal D echamboux. Composants et composition dans larchitecture des syst` emes
r epartis. Octobre 2001.
[39] Jo elle Coutaz and Laurence Nigay. Architecture logicielle conceptuelle des
syst` emes interactifs. Analyse et conception de lIHM. Herm es, chapitre 7 :207
246, 2001.
[40] Carlos E. Cuesta, Pablo de la Fuente, Manuel Barrio-Sol orzano, and M. Encar-
naci on Beato. Coordination in a reective architecture description language. In CO-
ORDINATION02 : Proceedings of the 5
th
International Conference on Coordina-
tion Models and Languages, pages 141148, London, UK, 2002. Springer-Verlag.
[41] Hirsch Dan, Inverardi Paola, and Montanari Ugo. Modeling software architectures
and styles with graph grammars and constraint solving. In WICSA99 : Proceedings
of the 1
st
Working IFIP Conference on Software Architecture, pages 127142, San
Antonio, Texas, February 1999. Kluwer Academic Publishers.
[42] Desmond DSouza, Aamond Sane, and Alan Birchenough. First-class extensibility
for UML-proles, stereotypes, patterns. volume 1723 of Lecture Notes in Computer
Science, pages 265277, Fort Collins, CO, USA, 28-30 October 1999. Springer.
[43] Yael Dubinsky. Teaching extreme programming in a project-based capstone course.
In XP03 : Proceedings of the 4
th
International Conference on Extreme Program-
ming and Agile Processes in Software Engineering, volume 2675 of Lecture Notes
in Computer Science, pages 435436. Springer, 2003.
[44] Domiczi Endre. OctoGuide - a graphical aid for navigating among octopus/UML
artifacts. In Proceedings of the ECOOP98 : Workshop on Object-Oriented Tech-
nology, page 560, London, UK, 1998. Springer-Verlag.
[45] Claudia Ermel, Roswitha Bardohl, and Julia Padberg. Visual design of software ar-
chitecture and evolution based on graph transformation. Electronic Notes in Theo-
retical Computer Science, 44(4), 2001.
[46] Cl ever R. Guareis De Farias, Luis Ferreira Pires, Wanderley Lopes de Souza, and
C elio Estevan Moron. Specication and validation of a real-time parallel kernel
using LOTOS. In MASCOTS 01 : Proceedings of the 9
th
International Sympo-
sium in Modeling, Analysis and Simulation of Computer and Telecommunication
Systems, pages 714, Washington, DC, USA, 2001. IEEE Computer Society.
[47] Roy T. Fielding. Software architectural styles for network-based applications.
Phase ii survey paper, draft 1.1, University of California, Irvine, July 15 1999.
[48] Martin Fowler. UML 2.0. CompusPress, Paris, 1
ere
edition, 5
eme
tirage edition,
2004.
[49] Robert B. France, Jean-Michel Bruel, Maria M. Larrondo-Petrie, and Malcom
Shroff. Exploring the semantics of UML type structures with Z. In FMOODS97 :
BIBLIOGRAPHIE 129
Proceedings of the International workshop on Formal methods for open object-
based distributed systems, pages 247257, London, UK, 1997. Chapman and Hall,
Ltd.
[50] David Garlan. Software architecture : a roadmap. In ICSE00 : Proceedings of
the Conference on The Future of Software Engineering, pages 91101, New York,
USA, 2000. ACM Press.
[51] David Garlan, Robert Allen, and John Ockerbloom. Exploiting style in architectural
design environments. In SIGSOFT94 : Proceedings of the 2
nd
ACM SIGSOFT
symposium on Foundations of software engineering, pages 175188, New York,
NY, USA, 1994. ACM Press.
[52] David Garlan, Shang-Wen Cheng, and AndrewJ. Kompanek. Reconciling the needs
of architectural description with object-modeling notations. Science of Computer
Programming, 44(1) :2349, 2002.
[53] David Garlan, Robert T. Monroe, and David Wile. Acme : architectural description
of component-based systems. pages 4767, 2000.
[54] David Garlan and Mary Shaw. An introduction to software architecture. In V. Am-
briola and G. Tortora, editors, Advances in Software Engineering and Knowledge
Engineering, pages 139, Singapore, 1993. World Scientic Publishing Company.
[55] Martin Gogolla, Fabian B uttner, and Mark Richters. USE : A UML-based speci-
cation environment for validating UML and OCL. Science of Computer Program-
ming, 1(69) :2734, 2007.
[56] Karin Guennoun, Khalil Drira, and Michel Diaz. Une approche orient ee mod` ele
pour la gestion des architectures logicielles distribu ees dynamiques. Information
Sciences for Decision Making, 1(19) :5058, 2005.
[57] Mohamed Hadj Kacem, Mohamed Jmaiel, Ahmed Hadj Kacem, and Khalil Drira.
Evaluation and comparison of ADL based approaches for the description of dyna-
mic of software architectures. In ICEIS05 : Proceedings of the 7
th
International
Conference on Enterprise Information Systems., pages 189195, Miami, USA, May
2005. INSTICC Press.
Using UML2.0 and GG for describing the dynamic of software architectures. In
ICITA05 : Proceedings of the 3
rd
International Conference on Information Tech-
nology and Applications, volume 2, pages 4651, Washington, DC, USA, 2005.
IEEE Computer Society.
Describing dynamic software architectures using an extended UML model. In
SAC06 : Proceedings of the 21
st
Annual Symposium on Applied Computing, Track
- Model Transformation, volume 2, pages 12451249, Dijon, France, April 2006.
ACM SIG Proceedings.
[60] Mohamed Hadj Kacem, Mohamed Nadhmi Miladi, Mohamed Jmaiel, Ahmed Hadj
Kacem, and Khalil Drira. Towards a UML prole for the description of dynamic
software architectures. In COEA05 : Proceedings of the International Conference
130 BIBLIOGRAPHIE
on Component-Oriented Enterprise Applications, pages 2539, Erfurt, Germany,
September 2005. Lecture Notes in Computer.
[61] Reiko Heckel, Alexey Cherchago, and Marc Lohmann. A formal approach to ser-
vice specication and matching based on graph transformation. Electronic Notes in
Theoretical Computer Science, 105 :3749, 2004.
[62] Gerald H. Hilderink. Graphical modelling language for specifying concurrency
based on CSP. IEE Proceedings - Software, 150(2) :108120, 2003.
[63] Christine Hofmeister and Robert L. Nord. From software architecture to implemen-
tation with UML. In COMPSAC 01 : Proceedings of the 25
th
Annual International
Computer Software and Applications Conference on Invigorating Software Deve-
lopment, pages 113114, Washington, DC, USA, October 2001. IEEE Computer
Society.
[64] Vladimir Issarny, Luc Bellissard, Michel Riveill, and Apostolos Zarras.
Component-based programming of distributed applications. Journal of Distribu-
ted Systems, 1752/2000 :327353, 2000.
[65] Ivar Jacobson, Grady Booch, and James Rumbaugh. Le processus uni e de
d eveloppement logiciel. 1` ere edition edition, juin 2000.
[66] Ackbar Joolia, Thais Batista, Geoff Coulson, and Antonio Tadeu A. Gomes. Map-
ping ADL specications to an efcient and recongurable runtime component plat-
form. In WICSA05 : Proceedings of the 5
th
Working IEEE/IFIP Conference on
Software Architecture, pages 131140, Washington, DC, USA, 2005. IEEE Com-
puter Society.
[67] Hubert Kadima. MDA Conception orient ee objet guid ee par les mod` eles. Dunod
edition, Mars 2005.
[68] Mohamed Mancona Kand e, Valentin Crettaz, Alfred Strohmeier, and Shane Sen-
dall. Bridging the gap between IEEE 1471, an architecture description language,
and UML. Software and System Modeling, 1(2) :113129, 2002.
[69] Mohamed Mancona Kand e and Alfred Strohmeier. Towards a UML prole for
software architecture descriptions. In UML00 : Proceedings of the 3
rd
International
Conference on Unied Modeling Language. Advancing the Standard, York, UK,
volume 1939 of LNCS, pages 513527. Springer, 2000.
[70] Abdelmadjid Ket, Noureddine Belkhatir, and Pierre-Yves Cunin. Adaptation dy-
namique concepts et exp erimentations. In ICSSEA02 : Proceedings of the 15
th
International Conference Software, Systems and their Applications, CNAM Paris,
France, D ecembre 2002.
[71] Jeremy Kivi, Darlene Haydon, Jason Hayes, Ryan Schneider, and Giancarlo Succie.
Extreme programming : A university team design experience. In Proceedings of the
Canadian Conference on Electrical and Computer Engineering, volume 2, pages
816820, 2000.
[72] Hans J. Kohler, Ulrich Nickel, Jorg Niere, and Albert Zundorf. Integrating UML
diagrams for production control systems. In ICSE00 : Proceedings of the 22
nd
international conference on Software engineering, pages 241251, New York, NY,
USA, 2000. ACM Press.
BIBLIOGRAPHIE 131
[73] Jun Kong, Kang Zhang, Jing Dong, and Guanglei Song. A graph grammar ap-
proach to software architecture verication and transformation. In COMPSAC03 :
th
Annual International Computer Software and Applications
Conference, pages 492497. IEEE Computer Society, 2003.
[74] Pierre Kroll and Philippe Kruchten. Guide pratique du RUP. CampusPress, 2003.
[75] Philippe Kruchten. The Rational Unied Process : An Introduction. Addison-
Wesley, Boston, USA, second edition edition, 2000.
[76] Phipippe Kruchten, Bran Selic, Grant Larsen, and Alan Brown. Describing soft-
ware architecture with UML. In ICSE01 : Proceedings of the 23
rd
Internatio-
nal Conference on Software Engineering, pages 715716, Washington, DC, USA,
2001. IEEE Computer Society.
[77] Sabine Kuske, Martin Gogolla, Ralf Kollmann, and Hans-Jorg Kreowski. An inte-
grated semantics for UML class, object and state diagrams based on graph transfor-
mation. In IFM02 : Proceedings of the 3
rd
International Conference on Integra-
ted Formal Methods, pages 1128, London, UK, 2002. Lecture Notes in Computer
Science, Springer-Verlag.
[78] Daniel LeM etayer. Describing software architecture styles using graph grammars.
IEEE Transactions on Software Engineering, 24(7) :521533, 1998.
[79] Bass Len, Clements Paul, and Kazman Rick. Software Architecture in Practice.
Addison-Wesley, second edition edition, April 2003.
[80] Fabien Leymonerie. ASL : un langage et des outils pour les styles architecturaux.
Contribution ` a la description darchitectures dynamiques. Phd thesis, Universit e
de Savoie, D ecembre 2004.
[81] Fabien Leymonerie, Sorana Cimpan, and Flavio Oquendo. Extension dun langage
de description architecturale pour la prise en compte des styles architecturaux : Ap-
plication ` a j2ee. In ICSSEA01 : Proceedings of the 14
th
International Conference
on Software and Software Engineering and their Applications, Paris, D ecembre
2001.
[82] Denivaldo Cicero Pavao Lopes. Etude et applications de lapproche MDA pour des
plates-formes de Services Web. Phd thesis, Universit e de Nantes, Ecole doctorale
sciences et technologies de linformation et des mat eriaux, 2005.
[83] Imen Loulou, Ahmed Hadj Kacem, Mohamed Jmaiel, and Khalil Drira. Towards
a unied graph-based framework for dynamic component-based architectures des-
cription in z. In ICPS04 : Proceedings of the IEEE/ACS International Conference
on Pervasive Services, pages 227234. IEEE Computer Society, 2004.
[84] Imen Loulou, Ahmed Hadj Kacem, Mohamed Jmaiel, and Khalil Drira. Formal
design of structural and dynamic features of publish/subscribe architectural styles.
In ECSA07 : Proceedings of the 1
st
European Conference on Software Architec-
ture, Aranjuez, Spain, September 24-26, volume 4758 of Lecture Notes in Computer
Science, pages 4459. Springer, 2007.
[85] David C Luckham. Rapide : A language and toolset for simulation of distributed
systems by partial orderings of events. IEEE Transactions on Software Engineering,
1996.
132 BIBLIOGRAPHIE
[86] David C. Luckham and James Vera. An event-based architecture denition lan-
guage. IEEE Transactions on Software Engineering, 21(9) :717734, September
1995.
[87] David C. Luckham, James Vera, and Sigurd Meldal. Three concepts of system
architecture. Technical Report CSL-TR-95-674, Stanford, CA, USA, 1995.
[88] Jeff Magee, Naranker Dulay, and Jeff Kramer. A constructive development envi-
ronment for parallel and distributed programs. In IWCCS94 : Proceedings of the
IEEE Workshop on Congurable Distributed Systems, North Falmouth, Massachu-
setts, USA, Mars 1994.
[89] Jeff Magee, Naranker Dulay, and Jeffrey Kramer. Structuring parallel and distribu-
ted programs. IEEE Software Engineering Journal, 8(2) :7382, Mars 1993.
[90] Jeff Magee and Jeff Kramer. Dynamic structure in software architectures. SIGSOFT
Software Engineering Notes, 21(6) :314, 1996.
[91] Nenad Medvidovic. ADLs and dynamic architecture changes. In ISAW96 : Procee-
dings of the 2
nd
International software Architecture Workshop, pages 2427, New
York, USA, 1996. ACM Press.
[92] Nenad Medvidovic, Peyman Oreizy, and Richard N. Taylor. Reuse of off-the-
shelf components in C2-style architectures. SIGSOFT Software Engineering Notes,
22(3) :190198, 1997.
[93] Nenad Medvidovic, David S. Rosenblum, David F. Redmiles, and Jason E. Rob-
bins. Modeling software architectures in the unied modeling language. ACM
Transactions on Software Engineering and Methodology, 11(1) :257, 2002.
[94] Nenad Medvidovic and Richard Taylor. A classication and comparison framework
for software architecture description languages. IEEE Transactions on Software
Engineering, 26(1) :7093, Janvier 2000.
[95] Irwin Meisels and Mark Saaltink. The Z/EVES Reference Manual (for Version
1.5). Reference manual, ORA Canada, 1997.
[96] Francisco Jos e MOO MENA. Modelisation Des Architectures Logicielles Dyna-
miques, Application ` a la gestion de la qualit e de service des applications ` a base de
services Web. Phd thesis, Institut National Polytechnique de Toulouse, Avril 2007.
[97] Mohamed Nadhmi Miladi. Prol UML pour la mod` elisation des architectures lo-
gicielles ` a base de composants. Master report, Universit e de Sfax, Ecole Nationale
dIng enieurs de Sfax, Juillet 2005.
[98] Moda-Tel. (Deliverable 3.3), MDA modelling and application prin-
ciples. MODA-TEL, en ligne edition, Mai 2004. Disponible
sur :http ://www.modatel.org/ Modatel/pub/deliverables/D3.3-nal.pdf.
[99] Robert T. Monroe, Andrew Kompanek, Ralph Melton, and David Garlan. Archi-
tectural styles, design patterns, and objects. IEEE Transactions on Software Engi-
neering, 14(1) :4352, 1997.
[100] Ronald Morrison, Graham N. C. Kirby, Dharini Balasubramaniam, Kath Mickan,
Flavio Oquendo, Sorana Cimpan, Brian Warboys, Bob Snowdon, and R. Mark
BIBLIOGRAPHIE 133
Greenwood. Support for evolving software architectures in the archware adl. In
WICSA04 : Proceedings of the 4
th
Working IEEE/IFIP Conference on Software
Architecture (WICSA04), pages 6978, Washington, DC, USA, 2004. IEEE Com-
puter Society.
[101] Pierre-Alain Muller and Nathalie Gaertner. Mod elisation objet avec UML. Eyrolles,
Paris, 2
eme
edition, 5
eme
tirage edition, 2004.
[102] Mahmoud Nassar. Analyse/conception par points de vue : le prol VUML. Phd
thesis, Institut national polytechnique de Toulouse, ecole doctorale : Informatique
et T el ecommunications, Septembre 2005.
[103] Sylvain NICLOT. Alternative ` a RUP : dX. Technical report, Conservatoire National
des Arts et M etiers Centre Enseignement Principal de Tours, 2005.
[104] Elisabetta Di Nitto and David Rosenblum. Exploiting ADLs to specify architectural
styles induced by middleware infrastructures. In ICSE99 : Proceedings of the 21
st
international conference on Software engineering, pages 1322, Los Alamitos, CA,
USA, 1999. IEEE Computer Society Press.
[105] Goaer Olivier. De ladaptation des composants logiciels vers leur evolution. Mas-
tersthesis, Laboratoire dInformatique de Nantes Atlantique, 7 septembre 2005.
[106] OMG. Meta object facility (MOF) specication (version 1.3). OMG document, Ob-
ject Management Group, ftp ://ftp.omg.org/pub/docs/formal/00-04-03.pdf, March
2000.
[107] OMG. MDA guide version 1.0.1, document number : omg/2003-06-01. OMG
document, June 2003.
[108] OMG. UML 2.0 OCL specication. OMG document, url : http ://www.omg.org,
Octobre 2003.
[109] OMG. UML 2.0 superstructure specication, nal adopted specication. Omg
document, August 2003.
[110] OMG. The unied modelling language 2.0 - object constraint language 2.0 propo-
sal. OMG document, url : http ://www.omg.org, 2003.
[111] Flavio Oquendo, Brian Warboys, Ronald Morrison, Regis Dindeleux, Ferdinando
Gallo, Hubert Garavel, and Carmen Occhipinti. Archware : Architecting evolvable
software. In EWSA04 : Proceedings of 1
st
European Workshop Software Architec-
ture, volume 3047 of Lecture Notes in Computer Science, pages 257271. Springer,
2004.
[112] Noel De Palma, Philippe Laumay, and Luc Bellissard. Ensuring dynamic recon-
guration consistency. In WCOP01 : Proceedings of the 6
th
International Workshop
on Component-Oriented Programming, ECOOP related Workshop, Udapest - Hun-
gary, Juin 2001.
[113] Virginia C. Carneiro De Paula, George R. Ribeiro-Justo, and P. R. F. Cunha. Speci-
fying and verifying recongurable software architectures. In PDSE, pages 2131,
2000.
134 BIBLIOGRAPHIE
[114] Jennifer P erez, Nour Ali, Jos e A. Cars, and Isidro Ramos. Dynamic evolution in
aspect-oriented architectural models. In EWSA05 : Proceedings of the 2
nd
Euro-
pean Workshop Software Architecture, Pisa, Italy, June 13-14, 2005, volume 3527
of Lecture Notes in Computer Science, pages 5976. Springer, 2005.
[115] Jorge Enrique P erez-Martinez. Heavyweight extensions to the UML metamodel
to describe the C3 architectural style. SIGSOFT Software Engineering Notes,
28(3) :55, 2003.
[116] Jorge Enrique P erez-Martnez and Almudena Sierra-Alonso. UML 1.4 versus UML
2.0 as languages to describe software architectures. In EWSA04 : Proceedings of
1
st
European Workshop Software Architecture, EWSA 2004, St Andrews, UK, May
21-22, volume 3047 of Lecture Notes in Computer Science, pages 88102. Springer,
2004.
[117] Robert G. Pettit and Hassan Gomaa. Improving the reliability of concurrent object-
oriented software designs. In WORDS03 : Proceedings of the 9
th
IEEE Internatio-
nal Workshop on Object-Oriented Real-Time Dependable Systems, pages 262269,
Italy, 2003. IEEE Computer Society.
[118] Manuele Kirsch Pinheiro, Tiago Lopes Telecken, Carlos Mario Dal Col Zeve,
Jos e Valdeni de Lima, and Nina Edelweiss. A cooperative environment for e-
learning authoring. In Document num erique, volume 5 of 4, pages 89114, 2001.
[119] Vivien Quema. Conguration dun middleware dirig ee par les applications. Master
report, Universit e Joseph Fourier, Institut National Polytechnique de Grenoble, Juin
2002.
[120] Rapide. Guide to the rapide 1.0 language reference manuals. Technical report,
Group Computer Systems Lab Stanford University, Juillet 1997.
[121] George R. Ribeiro-Justo, Virginia C. Carneiro de Paula, and Paulo Roberto Freire
Cunha. Formal specication of evolving distributed software architectures. In
DEXA98 : Proceedings of the 9
th
International Workshop on Database and Expert
Systems Applications, pages 548553, Washington, DC, USA, 1998. IEEE Compu-
ter Society.
[122] Josep M. Ribo and Xavier Franch. A two-tiered methodology to extend the UML
metamodel. Research report, Universitat Politecnica de Cataluna, Departament de
Llenguatges i Sistemes Inform` atics, 2002.
[123] Michel Riveill and Aline Senart. Aspects dynamiques des langages de description
darchitecture logicielle. LObjet RTSI - Lobjet. Coop eration et syst` emes ` a objets,
8(3), 2002.
[124] Jason E. Robbins, Nenad Medvidovic, David F. Redmiles, and David S. Rosenblum.
Integrating architecture description languages with a standard design method. In
ICSE98 : Proceedings of the 20
th
international conference on Software enginee-
ring, pages 209218, Washington, DC, USA, 1998. IEEE Computer Society.
[125] Etienne Roblet, Khalil Drira, and Michel Diaz. Formal design and development of
a corba-based application for cooperative HTML group editing support. Journal of
Systems and Software, 60(2) :113127, 2002.
BIBLIOGRAPHIE 135
[126] Sunghwan Roh, Kyungrae Kim, and Taewoong Jeon. Architecture modeling lan-
guage based on UML2.0. In APSEC04 : Proceedings of the 11
th
Asia-Pacic Soft-
ware Engineering Conference, pages 663669. IEEE Computer Society, 2004.
[127] Pascal Roques and Franck Vall ee. UML 2 en action : De lanalyse des besoins ` a la
conception J2EE. Eyrolles, Juin 2004.
[128] Gwen Salaun, Michel Allemand, and Christian Attiogbe. A method to combine any
process algebra with an algebraic specication language : the p-calculus example.
In COMPSAC02 : Proceedings of the 26
th
International Computer Software and
Applications Conference on Prolonging Software Life : Development and Redeve-
lopment, pages 385392, Washington, DC, USA, 2002. IEEE Computer Society.
[129] Petri Selonen and Jianli Xu. Validating uml models against architectural proles. In
ESEC/FSE-11 : Proceedings of the 9
th
European software engineering conference
held jointly with 11th ACM SIGSOFT international symposium on Foundations of
software engineering, pages 5867, New York, NY, USA, 2003. ACM Press.
[130] Fr ed erick Seyler. UGATZE : M eta-mod elisation pour la r eutilisation de compo-
sants h et erog` enes distribues. Phd thesis, LUniversit e de Pau et des pays de lAdour,
D ecembre 2004.
[131] Malcolm Shroff and Robert B. France. Towards a formalization of UML class
structures in Z. In COMPSAC97 : Proceedings of the 21
st
International Compu-
ter Software and Applications Conference, pages 646651, Washington, DC, USA,
1997. IEEE Computer Society.
[132] Adel Smeda, Mourad Oussalah, and Tahar Khammaci. A multi-paradigm ap-
proach to describe complex software system. WSEAS Transactions on Computers,
3(4) :936941, October 2003.
[133] Mike Spivey. The z notation (second edition). Prentice Hall International, 1992.
[134] Jennifer Stapleton. DSDM : Dynamic systems development method. In
TOOLS99 : Proceedings of the Technology of Object-Oriented Languages and Sys-
tems, pages 406406, Washington, DC, USA, 1999. IEEE Computer Society.
[135] Clemens Szyperski. Component Software - Beyond Object-Oriented Programming.
Addison-Wesley, Novembre 2002.
[136] Kenji Taguchi and Keijiro Araki. The state-based CCS semantics for concurrent Z
specication. In ICFEM97 : Proceedings of the 1
st
International Conference on
Formal Engineering Methods, pages 283292, Washington, DC, USA, 1997. IEEE
Computer Society.
[137] Amjad Umar. Object-oriented client/server Internet environments. Prentice Hall
Press, Upper Saddle River, NJ, USA, 1997.
[138] Jean-Pierre Vickoff. Agilit e et performance en conduite de projet. Dossier
M ethodes, 2(4) :1824, Avril 2006.
[139] Thomas Weigert, David Garlan, John Knapman, Birger Moller-Pedersen, and Bran
Selic. Modeling of architectures with UML (Panel). In UML00 : Proceedings
of the 3
rd
International Conference on Unied Modeling Language. Advancing the
136 BIBLIOGRAPHIE
Standard, York, UK, volume 1939 of Lecture Notes in Computer Science, pages
556569. Springer, 2000.
[140] Michel Wermelinger. Specication of software architecture reconguration. Phd
thesis, Universit e Nova de Lisbon, Juin 1999.
[141] Jim Woodcock and Jim Davies. Using Z Specication, Renement, and Proof.
University of Oxford, 1995.
[142] Apostolos Zarras, Val erie Issarny, Christos Kloukinas, and Viet Khoi Nguyen. To-
wards a base uml prole for architecture description. In ICSE01 : Proceedings of
the 23
rd
International Conference on Software Engineering, pages 2226, Washing-
ton, DC, USA, 2001. IEEE Computer Society.
[143] Yu Zhao, Yushun Fan, Xinxin Bai, Yuan Wang, Hong Cai, and Wei Ding. To-
wards formal verication of UML diagrams based on graph transformation. In
CEC-East04 : Proceedings of the IEEE International Conference on E-Commerce
Technology for Dynamic E-Business, September, Beijing, China, pages 180187,
China, 2004. IEEE Press.
[144] Tewk ZIADI. Manipulation de Lignes de Produits en UML. Phd thesis, Universit e
de Rennes 1, D ecembre 2004.
[145] Paul Ziemann, Karsten H olscher, and Martin Gogolla. From UML models to
graph transformation systems. Electronic Notes in Theoretical Computer Science,
127(4) :1733, 2005.
A
Annexe : Les XML sch emas
Dans le quatri` eme chapitre, nous avons pr esent e un extrait des XML sch ema, des trois
m eta-mod` eles, que nous avons propos es an de d ecrire les r` egles de validation. Nous
pr esentons, dans ce qui suit, les diff erents diagrammes et les descriptions correspondantes.
138 Annexe : Les XML sch emas
A.1 XML sch ema : style architectural
A
r
c
h
i
t
e
c
t
u
r
a
l
S
t
y
l
e
M
-
M
A
r
c
h
i
t
e
c
t
u
r
a
l
S
t
y
l
e
N
a
m
e
a
t
t
r
ib
u
t
e
s
A
r
c
h
i
t
e
c
t
u
r
a
l
S
t
y
l
e
N
a
m
e
t
y
p
e
x
s
:
I
D
u
s
e
r
e
q
u
ir
e
d
A
r
c
h
i
t
e
c
t
u
r
a
l
S
t
y
l
e
F
e
a
t
u
r
e
C
o
m
p
o
n
e
n
t
2
.
.
N
a
m
e
C
o
m
p
o
n
e
n
t
a
t
t
r
ib
u
t
e
s
N
a
m
e
C
o
m
p
o
n
e
n
t
t
y
p
e
x
s
:
I
D
u
s
e
r
e
q
u
ir
e
d
P
o
r
t 1
.
.
N
a
m
e
P
o
r
t
a
t
t
r
ib
u
t
e
s
N
a
m
e
P
o
r
t
t
y
p
e
x
s
:
I
D
u
s
e
r
e
q
u
ir
e
d
I
n
t
e
r
f
a
c
e
a
t
t
r
ib
u
t
e
s
T
y
p
e
t
y
p
e
x
s
:
N
M
T
O
K
.
.
.
u
s
e
r
e
q
u
ir
e
d
N
a
m
e
I
n
t
e
r
f
a
c
e
a
t
t
r
ib
u
t
e
s
N
a
m
e
I
n
t
e
r
f
a
c
e
t
y
p
e
x
s
:
I
D
u
s
e
r
e
q
u
ir
e
d
C
o
n
n
e
c
t
o
r
1
.
.
a
t
t
r
ib
u
t
e
s
N
a
m
e
C
o
n
n
e
c
t
o
r
a
t
t
r
ib
u
t
e
s
N
a
m
e
C
o
n
n
e
c
t
o
r
t
y
p
e
x
s
:
I
D
u
s
e
r
e
q
u
ir
e
d
G
u
a
r
d
s
C
o
n
s
t
r
a
i
n
t
1
.
.
t
y
p
e
x
s
:
s
t
r
i
n
g
FIG. A.1 Le diagramme XSD du style architectural
20 xmlns:xs="http://www.w3.org/2001/XMLSchema">
A.1 XML sch ema : style architectural 139
21 <xs:element name="ArchitecturalStyleM-M">
22 <xs:complexType>
23 <xs:sequence>
24 <xs:element ref="ArchitecturalStyleName"/>
25 <xs:element ref="ArchitecturalStyleFeature"/>
27 </xs:sequence>
29 </xs:element>
30 <xs:element name="ArchitecturalStyleName">
31 <xs:complexType>
32 <xs:attribute name="ArchitecturalStyleName" type="xs:ID" use="required"/>
34 </xs:element>
35 <xs:element name="ArchitecturalStyleFeature">
36 <xs:complexType>
37 <xs:sequence>
39 <xs:element ref="Connector" maxOccurs="unbounded"/>
40 </xs:sequence>
42 </xs:element>
44 <xs:complexType>
45 <xs:sequence>
46 <xs:sequence>
49 </xs:sequence>
50 </xs:sequence>
52 </xs:element>
54 <xs:complexType>
55 <xs:attribute name="NameComponent" type="xs:ID" use="required"/>
57 </xs:element>
59 <xs:complexType>
60 <xs:sequence>
63 </xs:sequence>
65 </xs:element>
66 <xs:element name="NamePort">
67 <xs:complexType>
68 <xs:attribute name="NamePort" type="xs:ID" use="required"/>
70 </xs:element>
71 <xs:element name="NameInterface">
72 <xs:complexType>
73 <xs:attribute name="NameInterface" type="xs:ID" use="required"/>
75 </xs:element>
77 <xs:complexType>
78 <xs:sequence>
80 </xs:sequence>
82 <xs:simpleType>
87 </xs:simpleType>
88 </xs:attribute>
90 </xs:element>
91 <xs:element name="Connector">
92 <xs:complexType>
93 <xs:sequence>
94 <xs:element ref="NameConnector"/>
95 </xs:sequence>
97 <xs:simpleType>
99 <xs:enumeration value="Delegation"/>
100 <xs:enumeration value="Assembly"/>
102 </xs:simpleType>
103 </xs:attribute>
105 </xs:element>
106 <xs:element name="NameConnector">
107 <xs:complexType>
108 <xs:attribute name="NameConnector" type="xs:ID" use="required"/>
110 </xs:element>
111 <xs:element name="Guards">
113 <xs:sequence>
114 <xs:element name="Constraint" type="xs:string" maxOccurs="unbounded"/>
115 </xs:sequence>
117 </xs:element>
118 <xs:element name="Constraint" type="xs:string"/>
119 </xs:schema>
Listing A.1 La description XSD du style architectural
A.2 XML sch ema : op eration de reconguration 141
A.2 XML sch ema : op eration de reconguration
R
e
c
o
n
f
ig
u
r
a
ti
o
n
O
p
e
r
a
t
io
n
M
-
M
R
e
c
o
n
f
ig
u
r
a
ti
o
n
O
p
e
r
a
t
io
n
N
a
m
e
a
ttr
ib
u
te
s
N
a
m
e
ty
p
e
x
s
:ID
u
s
e
r
e
q
u
ir
e
d
R
e
c
o
n
f
ig
u
r
a
ti
o
n
O
p
e
r
a
t
io
n
F
e
a
t
u
r
e
R
e
q
u
ir
e
_
D
e
le
t
e
C
o
m
p
o
n
e
n
t
0
..
N
a
m
e
C
o
m
p
o
n
e
n
t
ty
p
e
x
s
:ID
d
e
r
iv
e
d
B
y
r
e
s
tr
ic
tio
n
P
o
r
t 1
..
N
a
m
e
P
o
r
t
ty
p
e
x
s
:ID
In
te
r
fa
c
e
N
a
m
e
In
te
r
fa
c
e
ty
p
e
x
s
:ID
T
y
p
e
In
te
r
f
a
c
e
ty
p
e
x
s
:s
trin
g
d
e
r
iv
e
d
B
y
r
e
s
tr
ic
tio
n
C
o
n
n
e
c
t
o
r
0
..
N
a
m
e
C
o
n
n
e
c
to
r
ty
p
e
x
s
:ID
T
y
p
e
C
o
n
n
e
c
t
o
r
ty
p
e
x
s
:s
trin
g
d
e
r
iv
e
d
B
y
r
e
s
tr
ic
tio
n
R
e
q
u
ir
e
_
P
r
e
s
e
r
v
e
C
o
m
p
o
n
e
n
t
0
..
N
a
m
e
C
o
m
p
o
n
e
n
t
ty
p
e
x
s
:ID
d
e
r
iv
e
d
B
y
r
e
s
tr
ic
tio
n
P
o
r
t 1
..
N
a
m
e
P
o
r
t
ty
p
e
x
s
:ID
In
te
r
fa
c
e
N
a
m
e
In
te
r
fa
c
e
ty
p
e
x
s
:ID
T
y
p
e
In
te
r
f
a
c
e
ty
p
e
x
s
:s
trin
g
d
e
r
iv
e
d
B
y
r
e
s
tr
ic
tio
n
C
o
n
n
e
c
t
o
r
0
..
N
a
m
e
C
o
n
n
e
c
to
r
ty
p
e
x
s
:ID
T
y
p
e
C
o
n
n
e
c
t
o
r
ty
p
e
x
s
:s
trin
g
d
e
r
iv
e
d
B
y
r
e
s
tr
ic
tio
n
In
s
e
r
t
C
o
m
p
o
n
e
n
t
0
..
N
a
m
e
C
o
m
p
o
n
e
n
t
ty
p
e
x
s
:ID
d
e
r
iv
e
d
B
y
r
e
s
tr
ic
tio
n
P
o
r
t 1
..
N
a
m
e
P
o
r
t
ty
p
e
x
s
:ID
In
te
r
fa
c
e
N
a
m
e
In
te
r
fa
c
e
ty
p
e
x
s
:ID
T
y
p
e
In
te
r
f
a
c
e
ty
p
e
x
s
:s
trin
g
d
e
r
iv
e
d
B
y
r
e
s
tr
ic
tio
n
C
o
n
n
e
c
t
o
r
0
..
N
a
m
e
C
o
n
n
e
c
to
r
ty
p
e
x
s
:ID
T
y
p
e
C
o
n
n
e
c
t
o
r
ty
p
e
x
s
:s
trin
g
d
e
r
iv
e
d
B
y
r
e
s
tr
ic
tio
n
G
u
a
r
d
s
C
o
n
s
t
r
a
in
t
1
..
ty
p
e
x
s
:s
trin
g
FIG. A.2 Le diagramme XSD des op erations de reconguration
1 <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
2 <xs:element name="ReconfigurationOperationM-M">
3 <xs:complexType>
4 <xs:sequence>
5 <xs:element ref="ReconfigurationOperationName"/>
6 <xs:element ref="ReconfigurationOperationFeature"/>
8 </xs:sequence>
9 </xs:complexType>
10 </xs:element>
11 <xs:element name="ReconfigurationOperationName">
12 <xs:complexType>
13 <xs:attribute name="Name" type="xs:ID" use="required"/>
15 </xs:element>
16 <xs:element name="ReconfigurationOperationFeature">
17 <xs:complexType>
18 <xs:sequence>
19 <xs:element ref="Require_Delete"/>
20 <xs:element ref="Require_Preserve"/>
21 <xs:element ref="Insert"/>
22 </xs:sequence>
24 </xs:element>
25 <xs:element name="Require_Delete">
26 <xs:complexType>
27 <xs:sequence>
29 <xs:element ref="Connector" minOccurs="0" maxOccurs="unbounded"/>
30 </xs:sequence>
32 </xs:element>
33 <xs:element name="Require_Preserve">
34 <xs:complexType>
35 <xs:sequence>
38 </xs:sequence>
40 </xs:element>
41 <xs:element name="Insert">
42 <xs:complexType>
43 <xs:sequence>
46 </xs:sequence>
48 </xs:element>
50 <xs:complexType>
51 <xs:sequence>
54 </xs:sequence>
56 </xs:element>
58 <xs:simpleType>
59 <xs:restriction base="xs:ID"/>
60 </xs:simpleType>
61 </xs:element>
63 <xs:complexType>
64 <xs:sequence>
67 </xs:sequence>
A.2 XML sch ema : op eration de reconguration 143
69 </xs:element>
70 <xs:element name="NamePort" type="xs:ID"/>
72 <xs:complexType>
73 <xs:sequence>
75 <xs:element ref="TypeInterface"/>
76 </xs:sequence>
78 </xs:element>
79 <xs:element name="NameInterface" type="xs:ID"/>
80 <xs:element name="TypeInterface">
81 <xs:simpleType>
82 <xs:restriction base="xs:string">
86 </xs:simpleType>
87 </xs:element>
88 <xs:element name="Connector">
89 <xs:complexType>
90 <xs:sequence>
91 <xs:element ref="NameConnector"/>
92 <xs:element ref="TypeConnector"/>
93 </xs:sequence>
95 </xs:element>
96 <xs:element name="NameConnector" type="xs:ID"/>
97 <xs:element name="TypeConnector">
98 <xs:simpleType>
100 <xs:enumeration value="Assembly"/>
101 <xs:enumeration value="Delegation"/>
104 </xs:element>
105 <xs:element name="Guards">
107 <xs:sequence>
108 <xs:element name="Constraint" type="xs:string" maxOccurs="unbounded"/>
109 </xs:sequence>
111 </xs:element>
112 <xs:element name="Constraint" type="xs:string"/>
113 </xs:schema>
Listing A.2 La description XSD de lop eration de reconguration
A.3 XML sch ema : protocole de reconguration
R
e
c
o
n
f
i
g
u
r
a
t
i
o
n
P
r
o
t
o
c
o
l
M
-
M
R
e
c
o
n
f
i
g
u
r
a
t
i
o
n
P
r
o
t
o
c
o
l
N
a
m
e
a
t
t
r
ib
u
t
e
s
R
e
c
o
n
f
i
g
u
r
a
t
i
o
n
P
r
o
t
o
c
o
l
N
a
m
e
t
y
p
e
x
s
:
I
D
u
s
e
r
e
q
u
ir
e
d
R
e
c
o
n
f
i
g
u
r
a
t
i
o
n
P
r
o
t
o
c
o
l
F
e
a
t
u
r
e
C
o
l
l
e
c
t
i
o
n
R
e
c
o
n
f
i
g
u
r
a
t
i
o
n
O
p
e
r
a
t
i
o
n
N
o
d
e 1
.
.
R
e
c
o
n
f
i
g
u
r
a
t
i
o
n
O
p
e
r
t
i
o
n
N
a
m
e
a
t
t
r
ib
u
t
e
s
R
e
c
o
n
f
i
g
u
r
a
t
i
o
n
O
p
e
r
t
i
o
n
N
a
m
e
t
y
p
e
x
s
:
s
t
r
i
n
g
u
s
e
r
e
q
u
ir
e
d
L
i
n
k 1
.
.
T
y
p
e
a
t
t
r
ib
u
t
e
s
T
y
p
e
t
y
p
e
x
s
:
s
t
r
i
n
g
u
s
e
r
e
q
u
ir
e
d
D
e
s
i
g
n
a
t
i
o
n
a
t
t
r
ib
u
t
e
s
D
e
s
i
g
n
a
t
i
o
n
t
y
p
e
x
s
:
s
t
r
i
n
g
u
s
e
r
e
q
u
ir
e
d
C
o
n
t
r
o
l
N
o
d
e
1
.
.
C
o
n
t
r
o
l
N
o
d
e
N
a
m
e
a
t
t
r
ib
u
t
e
s
C
o
n
t
r
o
l
N
o
d
e
N
a
m
e
t
y
p
e
x
s
:
s
t
r
i
n
g
u
s
e
r
e
q
u
ir
e
d
C
o
n
t
r
o
l
N
o
d
e
T
y
p
e
a
t
t
r
ib
u
t
e
s
C
o
n
t
r
o
l
N
o
d
e
T
y
p
e
t
y
p
e
x
s
:
s
t
r
i
n
g
u
s
e
r
e
q
u
ir
e
d
L
i
n
k 1
.
.
T
y
p
e
a
t
t
r
ib
u
t
e
s
T
y
p
e
t
y
p
e
x
s
:
s
t
r
i
n
g
u
s
e
r
e
q
u
ir
e
d
D
e
s
i
g
n
a
t
i
o
n
a
t
t
r
ib
u
t
e
s
D
e
s
i
g
n
a
t
i
o
n
t
y
p
e
x
s
:
s
t
r
i
n
g
u
s
e
r
e
q
u
ir
e
d
FIG. A.3 Le diagramme XSD du protocole de reconguration
A.3 XML sch ema : protocole de reconguration 145
1 <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
2 <xs:element name="ReconfigurationProtocolM-M">
3 <xs:complexType>
4 <xs:sequence>
5 <xs:element ref="ReconfigurationProtocolName"/>
6 <xs:element ref="ReconfigurationProtocolFeature"/>
7 </xs:sequence>
8 </xs:complexType>
9 </xs:element>
10 <xs:element name="ReconfigurationProtocolName">
11 <xs:complexType>
12 <xs:attribute name="ReconfigurationProtocolName" type="xs:ID" use="required"/>
14 </xs:element>
15 <xs:element name="ReconfigurationProtocolFeature">
16 <xs:complexType>
17 <xs:sequence>
18 <xs:element ref="Collection"/>
19 </xs:sequence>
21 </xs:element>
22 <xs:element name="Collection">
23 <xs:complexType>
24 <xs:sequence>
25 <xs:element ref="ReconfigurationOperationNode" maxOccurs="unbounded"/>
26 <xs:element ref="ControlNode" maxOccurs="unbounded"/>
27 </xs:sequence>
29 </xs:element>
30 <xs:element name="ReconfigurationOperationNode">
31 <xs:complexType>
32 <xs:sequence>
33 <xs:element ref="ReconfigurationOpertionName"/>
34 <xs:element ref="Link" maxOccurs="unbounded"/>
35 </xs:sequence>
37 </xs:element>
38 <xs:element name="ControlNode">
39 <xs:complexType>
40 <xs:sequence>
41 <xs:element ref="ControlNodeName"/>
42 <xs:element ref="ControlNodeType"/>
43 <xs:element ref="Link" maxOccurs="unbounded"/>
44 </xs:sequence>
46 </xs:element>
47 <xs:element name="ReconfigurationOpertionName">
48 <xs:complexType>
49 <xs:attribute name="ReconfigurationOpertionName" type="xs:string" use="required"/>
51 </xs:element>
52 <xs:element name="Link">
53 <xs:complexType>
54 <xs:sequence>
55 <xs:element ref="Type"/>
56 <xs:element ref="Designation"/>
57 </xs:sequence>
59 </xs:element>
60 <xs:element name="Type">
61 <xs:complexType>
63 <xs:simpleType>
65 <xs:enumeration value="LinkToFinalNode"/>
66 <xs:enumeration value="LinkToDecisionNode"/>
67 <xs:enumeration value="LinkToOperationNode"/>
68 <xs:enumeration value="LinkToSynchronousNode"/>
70 </xs:simpleType>
71 </xs:attribute>
73 </xs:element>
74 <xs:element name="Designation">
75 <xs:complexType>
76 <xs:attribute name="Designation" use="required">
77 <xs:simpleType>
78 <xs:restriction base="xs:string"/>
79 </xs:simpleType>
80 </xs:attribute>
82 </xs:element>
83 <xs:element name="ControlNodeName">
84 <xs:complexType>
85 <xs:attribute name="ControlNodeName" use="required">
86 <xs:simpleType>
87 <xs:restriction base="xs:string"/>
88 </xs:simpleType>
89 </xs:attribute>
91 </xs:element>
92 <xs:element name="ControlNodeType">
93 <xs:complexType>
94 <xs:attribute name="ControlNodeType" use="required">
95 <xs:simpleType>
97 <xs:enumeration value="FinalNode"/>
98 <xs:enumeration value="DecisionNode"/>
99 <xs:enumeration value="InitialNode"/>
100 <xs:enumeration value="SynchronousNode"/>
103 </xs:attribute>
105 </xs:element>
106 <xs:element name="ProjectName">
108 <xs:sequence minOccurs="0">
109 <xs:element ref="ProjectName"/>
110 <xs:element ref="ReconfigurationProtocolM-M"/>
111 </xs:sequence>
112 <xs:attribute name="ProjectName">
113 <xs:simpleType>
115 <xs:enumeration value="PMS"/>
118 </xs:attribute>
120 </xs:element>
121 </xs:schema>
Listing A.3 La description XSD du protocole de reconguration
B
Annexe : Les R` egles de transformation
Dans le cinqui` eme chapitre, nous avons pr esent e les r` egles de transformation dune des-
cription XML vers le langage Z. Nous pr esentons dans ce qui suit ces r` egles.
120 version="1.0" encoding="UTF-8"?> 
121 <TranslateFunction>
122 <function name="size" type="np">
123 <cas sign="l(obj:typeName)r()">
124 <translate>\# [sub:l1] </translate>
125 </cas>
126 
129 <cas sign="l(con:typeName,typeName)r()">
130 <translate>\#( [con:l1,l2] \limg \{ [dec:l1] \}\rimg )</translate>
131 </cas>
132 <cas sign="l(con:name,typeName)r()">
133 <translate>\#( [con:$l1,l2] \limg \{ [obj:l1] \}\rimg )</translate>
134 </cas>
135 </function>
136 <function name="isEmpty" type="np">
138 <translate> [sub:l1] =\emptyset</translate>
139 </cas>
141 <translate>( [con:l1,l2] \limg \{ [dec:l1] \}\rimg )=\emptyset</translate>
142 </cas>
144 <translate>( [con:$l1,l2] \limg \{ [obj:l1] \}\rimg )=\emptyset</translate>
145 </cas>
146 </function>
147 <function name="notEmpty" type="np">
149 <translate> [sub:l1] \neq\emptyset</translate>
150 </cas>
152 <translate>( [con:l1,l2] \limg \{ [dec:l1] \}\rimg )\neq\emptyset</translate>
153 </cas>
148 Annexe : Les R` egles de transformation
155 <translate>( [con:$l1,l2] \limg \{ [obj:l1] \}\rimg )\neq\emptyset</translate>
156 </cas>
157 </function>
158 <function name="includes" type="wp">
159 <cas sign="l(obj:typeName)r(dec:name,typeName)">
160 <translate> [r1] \in [obj:l1] </translate>
161 </cas>
162 <cas sign="l(con:typeName,typeName)r(name.name)">
163 <translate>( [obj:r1] , [obj:r2] )\in(\{ [obj:r1] \}\dres [con:l1,l2] )</translate>
164 </cas>
165 </function>
166 <function name="excludes" type="wp">
167 <cas sign="l(obj:typeName)r(dec:name,typeName)">
168 <translate> [r1] \notin [obj:l1] </translate>
169 </cas>
170 <cas sign="l(con:typeName,typeName)r(name.name)">
171 <translate>( [obj:r1] , [obj:r2] )\notin(\{ [obj:r1] \}\dres [con:l1,l2] )</translate>
172 </cas>
173 </function>
174 <function name="including" type="wp">
175 <cas sign="l(obj:typeName)r(obj:name)">
176 <translate> [sub:l1]= [sub:l1] \cup\{ [obj:r1]\}</translate>
177 </cas>
178 <cas sign="l(con:typeName,typeName)r(con:name,name)">
179 <translate> [con:l1,l2]= [con:l1,l2] \cup\{( [obj:r1], [obj:r2])\}</translate>
180 </cas>
181 </function>
182 <function name="excluding" type="wp">
183 <cas sign="l(obj:typeName)r(obj:name)">
184 <translate> [sub:l1]= [sub:l1] \setminus\{ [obj:r1]\}</translate>
185 </cas>
186 <cas sign="l(con:typeName,typeName)r(con:name,name)">
187 <translate> [con:l1,l2]= [con:l1,l2] \setminus\{( [obj:r1], [obj:r2])\}</translate>
188 </cas>
189 </function>
190 <function name="includesAll" type="wp">
191 <cas sign="l(obj:typeName)r(obj:typeName)">
192 <translate> [sub:r2] \subset [sub:l1] </translate>
193 </cas>
194 <cas sign="l(con:typeName,typeName)r(con:typeName,typeName)">
195 <translate> [con:r1,r2] \subset [con:l1,l2] </translate>
196 </cas>
197 </function>
198 <function name="excludesAll" type="wp">
199 <cas sign="l(obj:typeName)r(obj:typeName)">
200 <translate>\disjoint\langle [sub:l1] , [sub:l2] \rangle</translate>
201 </cas>
202 <cas sign="l(con:typeName,typeName)r(con:typeName,typeName)">
203 <translate>\disjoint< [con:l1,l2] , [con:r1,r2] ></translate>
204 </cas>
205 </function>
206 <function name="forAll" type="wp">
207 <cas sign="l(obj:typeName)r(exp)">
208 <translate>\forall [dec:l1] @ [tra:r1] </translate>
209 </cas>
210 <cas sign="l(con:typeName,typeName)r(exp)">
211 <translate>\forall [dec:l1,l2] @ [tra:r1] </translate>
212 </cas>
213 </function>
214 <function name="exists" type="wp">
216 <translate>\exists [dec:l1] @ [tra:r1] </translate>
217 </cas>
219 <translate>\exists [dec:l1,l2] @ [tra:r1] </translate>
220 </cas>
221 </function>
222 <function name="one" type="wp">
149
224 <translate>\exists_1 [dec:l1] @ [tra:r1] </translate>
225 </cas>
227 <translate>\exists_1 [dec:l1,l2] @ [tra:r1] </translate>
228 </cas>
229 </function>
230 <function name="select" type="wp">
232 <translate>\{ [dec:l1] @ [tra:r1] \}</translate>
233 </cas>
235 <translate>\{ [dec:l1,l2] @ [tra:r1] \}</translate>
236 </cas>
237 </function>
238 </TranslateFunction>
Listing B.1 R` egles de transformation dune description XML vers Z

Hadj Kacem Mohammed

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Hadj Kacem Mohammed

Uploaded by

Copyright:

Available Formats

TH

Ecole Nationale dIng enieurs de Sfax et directeur de lunit e de recherche

ETAYER qui constituent probablement les

2. Intra- et inter-validation Opration de Reconfiguration

suivi par le nom de type de composant. Ces

d ecrit lensemble des composants r esultants

= sub Patient {z?} [R12]

= sub EventService [R14]

= EventServiceToPatient {(x?, z?)} [R15]

= PatientToEventService {(z?, x?)}

= NurseToPatient {(y?, z?)}

= PatientToNurse {(z?, y?)}

ADDIDITIVE EXP := FONCT APPEL POSTFIX ( FONCT | CONTIF OCL

NOM TYPE := ["a"-"z"] | ["A"-"Z"] (["a"-"z"] | ["0"-"9"] |

NOM REOP := ["a"-"z"] | ["A"-"Z"] (["a"-"z"] | ["0"-"9"] |

FIG. 5.6 Grammaire OCL

EXPRESSION Z := EXPRESSION1 | EXPRESSION2 | EXPRESSION3

NOM := ["a"-"z"] | ["A"-"Z"] (["a"-"z"] | ["0"-"9"] | ["A"-"Z"])

NOM TYPE := ["a"-"z"] | ["A"-"Z"] (["a"-"z"] | ["0"-"9"] |

FIG. 5.7 Grammaire Z

5.1.2.3 Grammaire de la passerelle

= sub Patient {z?}

= EventServiceToPatient {(x?, z?)}

= PatientToEventService {(z?, x?)}

= NurseToPatient {(y?, z?)}

= PatientToNurse {(z?, y?)}

: P (Event Service Nurse) ;

: P (Event Service Patient) ;

: P (Nurse Event Service) ;

: P (Patient Event Service) ;

: P Patient Insert Patient)

You might also like