5.2 V´erification
5.2.2 Pr´eservation du style architectural
Afin de prouver que l’´evolution de l’architecture pr´eserve toujours le style architectural, il faudrait v´erifier pour chaque op´eration de reconfiguration que les contraintes (invariants)
d´efinies dans le style architectural sont pr´eserv´ees `a la fin de leur application.
Dans cette ´etape, les op´erations de reconfiguration sont sp´ecifi´ees formellement. Chaque op´eration de reconfiguration est sp´ecifi´ee par un sch´ema d’op´eration Z, qui d´efinit les param`etres d’entr´ee (ci?) et les pr´e- et post-conditions. Ces conditions sont essentielles pour v´erifier que l’´evolution de l’architecture pr´eserve les invariants. Les op´erations de reconfiguration sont ex´ecut´ees seulement si leurs conditions pr´ealables sont satisfaites. Dans le sch´ema d’op´eration ci-dessous, PreCondi et PostCondi d´enotent une pr´e- et une post-condition de l’op´eration de reconfiguration Operationi.
Operationi △System ci? :Componenti . . . PreCondi, . . . ,PreCondn PostCondi, . . . ,PostCondn
FIG. 5.15 – Template de sch´ema d’op´eration Z
Apr`es avoir sp´ecifi´e les op´erations de reconfiguration formellement, ces op´erations doivent ˆetre v´erifi´ees. Pour ´evaluer l’impact d’une op´eration de reconfiguration sur une contrainte, nous d´efinissons 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 l’ex´ecution de l’op´eration et v´erifient que l’ex´ecution de l’op´eration de reconfiguration pr´eserve le style architectural.
Theorem PreCondTheorem
∀System∧c? :Componenti
|preConditions¦pre Operationi
Illustrons maintenant l’approche de sp´ecification des op´erations de reconfiguration en uti-lisant l’exemple de PMS. Nous avons sp´ecifi´e formellement les op´erations de reconfigu-ration telles que l’insertion et la suppression d’un service d’´ev´enement, d’un patient et d’une infirmi`ere. Pour l’illustration, le sch´ema suivant indique l’op´eration de reconfigura-tion InsertPatient. Le sch´ema Z de l’op´erareconfigura-tion d´eclare qu’il faut au moins une infirmi`ere y
appartenant au service en question x pour pouvoir s’occuper 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 l’infirmi`ere en question y est strictement inf´erieur `a 3. Afin de valider l’op´eration d’insertion d’un nouveau patient, nous utilisons l’outil Z/EVES pour prouver le th´eor`eme PreInsertPatient, qui assure que l’insertion d’un patient est conforme aux contraintes du syst`eme d´ecrites dans le sch´ema du syst`eme PMS.
Theorem Pre Insert Patient
∀PMS,x? :EventService,y? :Nurse,z? :Patient
|y?∈sub Nurse ∧x?∈EventService ∧x?∈sub EventService ∧z?6∈sub Patient ∧(x?,y?)∈EventServiceToNurse ∧(y?,x?)∈NurseToEventService ∧#(EventServiceToNurse(| {x?} |))>0 ∧#(EventServiceToPatient(| {x?} |))<15 ∧#(NurseToPatient(| {y?} |))<3
∧(∀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} |)6={})¦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?6∈sub Patient ∧(x?,y?)∈Event ServiceToNurse ∧(y?,x?)∈NurseToEvent Service ∧#(Event ServiceToNurse(| {x?} |))>0 ∧#(Event ServiceToPatient(| {x?} |))<15 ∧#(NurseToPatient(| {y?} |))<3
∧(∀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} |)6={})
⇒(∃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′:PEvent Service ; sub Nurse′:PNurse ;
sub Patient′:PPatient¦Insert Patient)
5.3 Conclusion
Dans ce chapitre, nous avons propos´e une approche de v´erification bas´ee sur la transfor-mation des mod`eles semi-formels vers des sp´ecifications formelles. Ce chapitre s’articule 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 reconfiguration 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 paspas-serelle est compos´ee d’un ensemble de r`egles de passage qui d´efinissent 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´erification [84]. Nous avons v´erifi´e la consistance du style architectural et nous avons prouv´e que l’´evolution de l’architecture est toujours conforme `a son style architectural. Ces th´eor`emes ont ´et´e prouv´es en utilisant le syst`eme de preuve de l’outil Z/EVES.
Comme perspective `a ce chapitre, nous pr´evoyons d’am´eliorer l’approche de v´erification en y ajoutant d’autres propri´et´es. Pour la partie protocole de reconfiguration, nous pr´evoyons d’achever la partie transformation permettant de traduire la description XML g´en´er´ee vers un langage formel. Nous pr´evoyons d’utiliser les r´eseaux de p´etri pour v´erifier le non blocage des diff´erentes op´erations de reconfiguration et que chaque op´eration de reconfiguration 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 Profil UML, pour la validation des mod`eles r´esultants et pour la v´erification et la preuve de la consistance du style ar-chitectural et de la conformit´e de l’´evolution de l’architecture par rapport `a son style. Il reste cependant `a d´efinir une d´emarche entre ces diff´erentes ´etapes et de capitaliser des r`egles permettant de guider et d’assister les architectes `a mod´eliser l’architecture d’une application dynamique tout en suivant le profil 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 l’architecture lo-gicielle (Style architectural, Op´eration de reconfiguration et Protocole de reconfiguration) et de d´efinir les diff´erentes r`egles de passage d’un mod`ele `a un autre. Elle automatise le processus de validation et assiste l’utilisateur pour v´erifier des propri´et´es architecturales. La d´emarche que nous proposons est inspir´ee de l’approche MDA [10, 67] (Model Dri-ven Architecture) et 2TUP [127] (2 Tracks Unified Process) du processus UP (Unified Process). Notre d´emarche est subdivis´ee en deux parties : une partie PIM (Platform Inde-pendant Model) et une partie PSM (Platform Specific Model). La premi`ere, mod´elise l’ar-chitecture logicielle sans se soucier des technologies sous-jacentes. La seconde, mod´elise l’implementation 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 l’architecture et incr´ementale.6.1 Description de la d´emarche X
La d´emarche
X
que nous proposons est bas´ee sur l’approche 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 l’adaptation et la correction de telles architectures. Comme le montre la figure 6.1, la d´emarche que nous proposons est bas´ee sur quatre branches et a la forme deX
.« Guards »
«ArchitecturalStyleFeature » «ArchitecturalStyleName » Branche Style Architectural
Branche Opération de Reconfiguration
Règles de Transformation Règles de Validation « Guards » «Reconfiguration OperationName »
«require & delete» «require & preserve » « insert »
«require & delete» « insert » «ReconfigurationOperationName »
« Guards »
«require & preserve »
Règles de Transformation «ReconfigurationProtocolName » «ReconfigurationProtocolFeature » ReOpNa2 Règles de Validation
Branche Protocole de Reconfiguration
Z/ EVES Vérification Vérification Branche Fonctionnelle