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 reconfiguration vers la notation Z.

5.1.1.1 Style architectural

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 figure 5.2, ob´eit `a un ensemble de r`egles.

Comp_i Style_Name « ArchitecturalStyleName » R1 R3 sub_Comp_i:FComp_i sub_Comp_j:FComp_j sub_Comp_n:FComp_n

[Comp_i, Comp_j, Comp_n]

R2 « ArchitecturalStyleFeature » Style_Name R5 R4 Compn Compj

dom Comp_iToComp_j6sub_Comp_i\ran Comp_iToComp_j6sub_Comp_j dom Comp_nToComp_i6sub_Comp_n\ran Comp_nToComp_i6sub_Comp_i dom Comp_nToComp_j6sub_Comp_n\ran Comp_nToComp_j6sub_Comp_j « Guards »

Contraintes OCL

Comp_iToComp_j: Comp_iļComp_j Comp_nToComp_i: Comp_iļComp_n Comp_nToComp_j: Comp_jļComp_n

Style Architectural

FIG. 5.2 – Transformation du style architectural vers la notation Z

¥R `egle1 : D ´efinition des types basiques de composants

Les types basiques de composants sont d´etermin´es `a partir des noms des types des com-posants figurant dans la partie«ArchitecturalStyleFeature».

[Compi,Compj, ...,Compn]

¥R `egle2 : D ´efinition du nom du sch ´emaZ

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 ´efinition des ensembles de composants

Chaque type de composant pr´esent´e dans la partie«ArchitecturalStyleFeature »est

tra-duit en un ensemble fini 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 ensemble de composant est pr´e-fix´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 Compj:FCompj sub Compn:FCompn

¥R `egle 4 : D ´efinition des relations

Chaque connexion pr´esent´ee dans la partie«ArchitecturalStyleFeature»est transform´ee en une relation, CompiToCompj :Compi ↔ Compj, dans la partie d´eclarative du sch´ema

Z. La source de la relation, Comp_i, porte le nom du type de composant ayant l’interface

requise et la cible de la relation, Comp_j, porte le nom du type de composant ayant l’inter-face fournie. Le nom de la relation est la clause “To” suffix´ee par la source et pr´efix´ee par la cible.

Style Name

sub Compi:FCompi sub Comp_j:FComp_j sub Compn:FCompn

CompiToCompj:Compi↔Compj Comp_nToComp_i:Comp_n↔Comp_i CompnToCompj:Compn↔Compj

¥R `egle 5 : D ´efinition des contraintes sur les relations

Pour exprimer des contraintes sur les relations, le langage Z offre les deux fonctions dom(domaine) etran(image). Domrepr´esente l’ensemble de d´epart etran repr´esente l’ensemble d’arriv´ee. Le domaine d’une relationR: T ↔ U est l’ensemble de tous les ´el´ements dansTqui sont li´es au moins `a un ´el´ement dansU. L’image de la relationRest l’ensemble de tous les ´el´ements dansUli´es au moins `a un ´el´ement dansT[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´efinit, dans la partie pr´edicative du sch´ema Z, les propri´et´es d’in-variance sur l’ensemble de d´epart (domaine) et l’ensemble d’arriv´ee (image) de chaque relation. Chaque propri´et´e exprime l’inclusion du domaine, respectivement de l’image, de la relation dans le sous-ensemble correspondant d´ej`a d´efini dans la partie d´eclarative.

Style Name

sub Compi:FCompi sub Comp_j:FComp_j sub Compn:FCompn

CompiToCompj:Compi↔Compj Comp_nToComp_i:Comp_n↔Comp_i CompnToCompj:Compn↔Compj

dom CompiToCompj⊂sub Compi∧ran CompiToCompj⊂sub Compj dom CompnToCompi⊂sub Compn∧ran CompnToCompi⊂sub Compi dom Comp_nToComp_j⊂sub Comp_n∧ran Comp_nToComp_j⊂sub Comp_j

Afin de mieux illustrer l’approche de transformation, nous revenons `a notre exemple et nous traduisons la partie graphique du style architectural du syst`eme PMS vers la notation

Z. L’application 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

dom EventServiceToPatient⊆sub EventService [R5]

∧ran EventServiceToPatient⊆sub Patient

dom EventServiceToNurse⊆sub EventService

∧ran EventServiceToNurse⊆sub Nurse

dom PatientToEventService⊆sub Patient

∧ran PatientToEventService⊆sub EventService

dom NurseToEventService⊆sub Nurse

∧ran NurseToEventService⊆sub EventService

dom PatientToNurse⊆sub Patient

∧ran PatientToNurse⊆sub Nurse

dom NurseToPatient⊆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 reconfiguration

Nous d´ecrivons les ´etapes de transformation d’une op´eration de reconfiguration vers la notation Z. Cette transformation, comme le montre la figure 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 d’op´eration Z.

OperationName

ǻStyle_Name

inst_Compi

« ReconfigurationOperationName »

« require&delete » « require&preserve » « insert »

R6 R7 R8 R9 _{inst Comp} i?8sub 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?8sub_Comp_i inst_Comp_j?8sub_Comp_j R11 R12 R13

(inst_Comp_i?, inst_Comp_n?) 8Comp_iToComp_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 Opération de Reconfiguration « Guards » R13 R14 R15 R16 R17

CompnToCompi’ = CompnToCompi*{(inst_Compi?,inst_Compn?)}

sub_Comp_i’ = sub_Comp_i

CompiToCompj’ = CompiToCompj\ {(inst_Compi?,inst_Compj?)}

R17

FIG. 5.4 – Transformation d’une op´eration de reconfiguration vers un sch´ema d’op´eration Z

¥R `egle 6 : D ´efinition du nom de l’op ´eration de reconfiguration

Cette r`egle g´en`ere le squelette du sch´ema Z. Le nom du sch´ema est d´etermin´e `a partir de

«ReconfigurationOperationName».

ReconfigurationOperationName

¥R `egle 7 : D ´efinition du changement de l’ ´etat de l’architecture

Une architecture logicielle peut ´evoluer apr`es l’ex´ecution d’une op´eration de reconfigu-ration. Cette ´evolution est exprim´ee en Z par le caract`ere∆. Le changement de l’´etat de l’architecture est pr´esent´e alors, dans la partie d´eclarative du sch´ema d’op´eration Z, par ∆suivi par le nom du style donn´e par«ArchitecturalStyleName».

ReconfigurationOperationName

∆Style Name

¥R `egle 8 : D ´efinition des param `etres d’entr ´ee

Cette r`egle d´efinit les instances de composants pr´esent´ees dans la partie « Require & Delete», «Require & Preserve » et«Insert »en tant que param`etres d’entr´ee pour le sch´ema d’op´eration Z.

Chaque instance de composant est transform´ee, dans la partie d´eclarative du sch´ema d’op´eration Z, vers le nom de l’instance de composant suffix´e par “ ?”. Le type de chaque composant est le type abstrait associ´e au composant qui lui correspond.

ReconfigurationOperationName

∆Style Name

inst Compi? :type Compi inst Comp_j? :type Comp_j inst Compn? :type Compn

¥R `egle 9 : D ´efinition des pr ´e-conditions sur l’appartenance des composants

Cette r`egle permet d’ajouter des pr´e-conditions exprimant l’appartenance des instances de composants de la partie « Require & Delete » et « Require & Preserve » `a l’en-semble des composants de l’architecture. Ces pr´e-conditions sont ajout´ees dans la par-tie pr´edicative du sch´ema d’op´eration Z sous la forme “inst Comp ∈ sub Comp”. Avec inst Comp d´esigne une instance de composant et sub Comp d´esigne l’ensemble de type de composant.

ReconfigurationOperationName

∆Style Name

inst Compi? :type Compi inst Compj? :type Compj inst Compn? :type Compn inst Compi?∈sub Compi inst Comp_j?∈sub Comp_j

¥R `egle 10 : D ´efinition des pr ´e-conditions sur la restriction des composants

Cette r`egle permet d’ajouter des pr´e-conditions exprimant la non appartenance des ins-tances de composants de la partie«Insert» `a l’ensemble des composants de l’architec-ture. Ces pr´e-conditions sont ajout´ees dans la partie pr´edicative du sch´ema d’op´eration Z sous la forme “inst Comp6∈sub Comp”.

ReconfigurationOperationName

∆Style Name

inst Compi? :type Compi inst Compj? :type Compj inst Comp_n? :type Comp_n inst Comp_i?∈sub Comp_i inst Compj?∈sub Compj inst Compn?6∈sub Compn

¥R `egle 11 : D ´efinition 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 Compi,inst Comp_j) ∈

Comp_iToComp_j”. Avec (inst Compi,inst Comp_j) est la relation entre les composants

inst Compi et inst Compj et CompiToCompj d´efinit l’ensemble des relations reliant les

composants de type Comp_i et Comp_j.

ReconfigurationOperationName

∆Style Name

inst Comp_i? :type Comp_i inst Compj? :type Compj inst Compn? :type Compn inst Compi?∈sub Compi inst Compj?∈sub Compj inst Comp_n?6∈sub Comp_n

(inst Compi?,inst Compj?)∈CompiToCompj

¥R `egle 12 : D ´efinition des post-conditions li ´ees `a l’insertion des composants

L’insertion d’un composant en Z est traduite par la r`egle suivante : “sub Comp′ =

sub Comp∪inst Comp”. Avec sub Comp′ d´ecrit l’ensemble des composants r´esultants

apr`es l’ex´ecution de l’op´eration de reconfiguration. sub Comp repr´esente l’ensemble des composants avant l’ex´ecution de l’op´eration de reconfiguration et inst Comp d´esigne une instance de composant `a ins´erer dans le syst`eme.

ReconfigurationOperationName

∆Style Name

inst Compi? :type Compi inst Compj? :type Compj inst Compn? :type Compn inst Comp_i?∈sub Comp_i inst Compj?∈sub Compj inst Compn?6∈sub Compn

(inst Comp_i?,inst Comp_j?)∈Comp_iToComp_j sub Comp′

n=sub Compn∪ {inst Compn?}

¥R `egle 13 : D ´efinition des post-conditions li ´ees `a la suppression des composants

La suppression d’un composant en Z est traduite par la r`egle suivante : “sub Comp′ =

ReconfigurationOperationName

∆Style Name

inst Compi? :type Compi inst Comp_j? :type Comp_j inst Compn? :type Compn inst Compi?∈sub Compi inst Compj?∈sub Compj inst Compn?6∈sub Compn

(inst Compi?,inst Compj?)∈CompiToCompj sub Comp′

n=sub Compn∪ {inst Compn?}

sub Comp′

j=sub Compj\ {inst Compj?}

¥R `egle 14 : D ´efinition des post-conditions li ´ees au non changement des compo-sants

Si un ensemble de composants, figurant dans l’architecture n’a subi aucun changement apr`es l’ex´ecution de l’op´eration de reconfiguration, alors ces composants seront exprim´es par la r`egle suivante : “sub Comp′ =sub Comp”.

ReconfigurationOperationName

∆Style Name

inst Comp_i? :type Comp_i inst Compj? :type Compj inst Compn? :type Compn inst Compi?∈sub Compi inst Compj?∈sub Compj inst Comp_n?6∈sub Comp_n

(inst Compi?,inst Compj?)∈CompiToCompj sub Comp′

n=sub Compn∪ {inst Compn?}

sub Comp′

j=sub Comp_j\ {inst Comp_j?}

sub Comp′

i=sub Compi

¥R `egle 15 : D ´efinition des post-conditions li ´ees `a l’insertion des connexions

L’insertion d’une connexion en Z est traduite par la r`egle suivante : “CompiToComp′

j =

Comp_iToComp_j∪(inst Compi,inst Comp_j)”. Avec Comp_iToComp′

j d´ecrit la relation qui

d´efinit l’ensemble des connexions reliant les composants de type Comp_i et Comp_j

et (inst Compi,inst Compj) d´ecrit la relation `a ins´erer entre l’instance du composant

ReconfigurationOperationName

∆Style Name

inst Compi? :type Compi inst Comp_j? :type Comp_j inst Compn? :type Compn inst Compi?∈sub Compi inst Compj?∈sub Compj inst Compn?6∈sub Compn

(inst Compi?,inst Compj?)∈CompiToCompj sub Comp′

n=sub Compn∪ {inst Compn?}

sub Comp′

j=sub Compj\ {inst Compj?}

sub Comp′

i=sub Comp_i CompnToComp′

i =CompnToCompi∪ {(inst Compn?,inst Compi?)}

¥ R `egle 16 : D ´efinition des post-conditions relatives `a la suppression des connexions

La suppression d’une relation en Z est traduite par la r`egle suivante : “Comp_iToComp′

j =

Comp_iToComp_j\(inst Compi,inst Comp_j)”. Avec(inst Compi,inst Comp_j)d´ecrit la

re-lation `a supprimer suite `a une op´eration de suppression d’une connexion. inst Compi et

inst Comp_jrepr´esentent les instances des composants que nous d´esirons d´econnecter.

ReconfigurationOperationName

∆Style Name

inst Compi? :type Compi inst Compj? :type Compj inst Comp_n? :type Comp_n inst Compi?∈sub Compi inst Comp_j?∈sub Comp_j inst Compn?6∈sub Compn

(inst Compi?,inst Compj?)∈CompiToCompj sub Comp′

n=sub Comp_n∪ {inst Comp_n?}

sub Comp′

j=sub Compj\ {inst Compj?}

sub Comp′

i=sub Compi Comp_nToComp′

i =Comp_nToComp_i∪ {(inst Comp_n?,inst Comp_i?)}

CompiToComp′

j=CompiToCompj\ {(inst Compi?,inst Compj?)}

¥ R `egle 17 : D ´efinition des post-conditions relatives au non changement des connexions

Si une connexion, figurant dans l’architecture, n’a subi aucun changement au cours de l’op´eration de reconfiguration, alors nous exprimons ce cas par la r`egle suivante : “Comp_iToComp′

j =Comp_iToComp_j”. Ce cas n’est pas trait´e dans l’exemple pr´esent´e dans

Nous revenons `a l’exemple du PMS et nous traduisons la partie graphique de l’op´eration de reconfiguration Inser Patient vers la notation Z. L’application des r`egles de transfor-mation successivement de[R6]jusqu’`a[R17]donne le sch´ema d’op´eration Z pr´esent´e dans la figure 5.5 suivante.

Insert Patient[R6] ∆PMS [R7] x? :EventService [R8] y? :Nurse z? :Patient x?∈sub EventService [R9] y?∈sub Nurse z?6∈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 l’op´eration Insert Patient vers un sch´ema d’op´eration Z

Dans le document Modélisation des applications distribuées à architecture dynamique : Conception et Validation (Page 94-103)