Le diagramme de d´ eploiement

Ce diagramme est issu du diagramme de classe UML. Nous n’avons pas utilis´e de diagramme de composant car nous ne pouvons pas faire figurer de cardinalit´e sur ce dernier diagramme. Nous nous servons de 3 concepts UML dans ce diagramme : les classes, les associations et les cardinalit´es.

Les classes

Chaque classe repr´esente une partie de l’application patrimoniale `a administrer. Au niveau SR, chaque instance de classe sera repr´esent´ee par un composant Fractal et au niveau patrimonial, chaque instance de classe repr´esentera un tier de l’application. Dans chaque classe des attributs sont d´efinis. Une partie des attributs est pr´ed´efinie

6.3. LES DIAGRAMMES 55 et l’utilisateur doit en donner les valeurs, une autre partie est aussi pr´ed´efinie mais TUNe affecte les valeurs et enfin une partie est `a la discr´etion de l’utilisateur. Les attributs pr´ed´efinis `a remplir par l’utilisateur sont les suivants :

– wrapper [ OBLIGATOIRE ]. Cet attribut doit avoir comme valeur par d´efaut le nom du fichier WDL qui d´efinit les actions applicables `a ce type de composant, – legacyFile [ OPTIONNEL ]. Cet attribut doit avoir comme valeur par d´efaut le nom du fichier tgz3 qui contient l’application patrimoniale `a d´eployer pour ce type de composant,

– host-family [ OBLIGATOIRE ]. Cet attribut permet de d´eclarer sur quelle famille de noeud les composants de ce type doivent ˆetre d´eploy´es. Ces noms correspondent aux noms des classes du diagramme de noeud,

– initial [ OPTIONNEL ]. Cet attribut permet de sp´ecifier combien de compo- sant de ce type doivent ˆetre initialement d´eploy´es. Si il n’est pas d´efini, TUNe en d´eploiera un par d´efaut.

Les attributs pr´ed´efinis et remplis par TUNe sont les suivants :

– dirLocal. Cet attribut contient le r´epertoire de d´eploiement du logiciel patri- monial sur son noeud de d´eploiement. Nous voyons dans la partie implantation que cet attribut est une recopie de l’attribut dirLocal du noeud sur lequel le logiciel patrimonial est d´eploy´e,

– nodeName. Cet attribut contient le nom du noeud sur lequel le logiciel patri- monial a ´et´e d´eploy´e. Le noeud est allou´e par un allocateur de noeud (voir section6.3.2)

– tubeAddr. Cet attribut contient le nom d’un tube nomm´e qui permet d’envoyer des notifications `a TUNe (voir section 6.5.1),

– srname. Cet attribut contient le nom unique du composant au sein du SR. D’autres attributs peuvent ˆetre d´efinis par l’utilisateur pour pouvoir param´etrer plus finement les composants. Ces attributs peuvent ˆetre lus et ´ecrits depuis les diagrammes de reconfiguration. Lors de la phase de cr´eation de l’architecture Fractal, ces attributs deviennent des attributs Fractal lisibles par le contrˆoleur d’attribut AttributeController.

Les associations

Les associations UML entre les classes sont implant´ees au niveau du SR par des liaisons Fractal qui peuvent ˆetre parcourues grˆace aux contrˆoleurs de liaison Binding- Controller. Pour chaque association, deux liaisons sont cr´ees entre les composants Fractal comme d´ecrit figure6.6.

Le diagramme UML en haut de la figure donne l’architecture Fractal pr´esent´ee en bas de la figure. On voit que deux liaisons relient C1 et C2. Cette double liaison cr´e´ee en Fractal permet la navigation de C1 vers C2 et de C2 vers C1. Ces associations

6.3. LES DIAGRAMMES 56

Fig. 6.6 – Une association UML transform´ee en double liaison Fractal permettent de naviguer dans l’architecture Fractal et permettent d’aller r´ecup´erer des valeurs d’attributs d’un composant depuis un autre composant. Ainsi si les classes Apache et Tomcat sont reli´ees, un composant Apache sera reli´e `a un composant Tomcat (en fonction des cardinalit´es) et chacun des deux composants pourra par exemple connaˆıtre l’adresse du noeud de l’autre grˆace `a l’attribut nodeName. Ce parcours est rendu possible par la syntaxe du WDL que nous d´ecrivons section

6.4.1. Les associations peuvent ˆetre nomm´ees pour faciliter la navigation dans le WDL (voir section 6.4.1).

Les cardinalit´es

Les cardinalit´es permettent `a TUNe de maintenir coh´erente l’architecture lors du d´eploiement et lors des reconfigurations avec le diagramme de d´eploiement. Uti- lis´ees avec l’attribut initial, elles permettent de valider au d´eploiement la coh´erence de l’architecture. Utilis´ees avec le nombre courant de composant, elles permettent de valider les architectures issues des reconfigurations. Pour d´eterminer l’utilit´e de chaque cardinalit´e, nous nous appuyons sur la figure 6.7.

Fig. 6.7 – Deux composants et leurs cardinalit´es associ´ees

6.3. LES DIAGRAMMES 57 – i composants C1 et k composants C2 seront d´eploy´es initialement,

– il faudra au minimum n composant(s) C2 reli´es `a C1, – il faudra au maximum m composant(s) C2 reli´es `a C1, – il faudra au minimum o composant(s) C1 reli´es `a C2, – il faudra au maximum p composant(s) C1 reli´es `a C2.

Dans le cas o`u une seule cardinalit´e figure sur le diagramme pour un composant (comme `a la figure 6.1), le nombre minimum et maximum de composant reli´es sont les mˆemes et sont ´egaux `a la cardinalit´e sp´ecifi´ee. La figure6.8 sera donc un sch´ema de d´eploiement invalide. En effet, on d´eploie initialement 2 composants C2 et 1

Fig. 6.8 – Sch´ema de d´eploiement incoh´erent

composant C1. Mais chaque composant C2 doit ˆetre reli´e `a au moins deux composant C1 et au plus deux composants C1. Le d´eploiement ne peut pas se faire. La figure

6.9 permet elle de faire un d´eploiement valide.

Fig. 6.9 – Sch´ema de d´eploiement coh´erent