Architectures logicielles Dynamiques Caractérisation de quatre styles de base

Le problème Les architectures logicielles des ces dernières années ne cessent de croître en taille et en complexité => lémergence de la programmation orientée composants permettant ladaptabilité et la réutilisabilité. Adaptabilité et réutilisabilité dans les architectures logicielles impliquent de pouvoir faire évoluer larchitecture : Pendant létape de configuration : faire évoluer lapplication (à cause dun nouvel environnement ou de nouveaux besoins applicatifs). Pendant les étapes de déploiement et dexploitation en réponse à un événement produit par lenvironnement ou par un utilisateur).

Techniques pour Architectures dynamiques Description Domaines dapplication Vérification Analyse ADLs DarwinWright Extensions pour la dynamicité non suffisantes Autres formalismes Styles darchitectures de services adaptables Adaptabilité intracomposant Adaptabilité intercomposant à 2 niveaux Adaptabilité intercomposant à 1 niveau TFMobilité Gestion de charge Preuve de conformité de la spécification de la reconfiguration dynamique à une certaine notion de la consistance de larchitecture Vérification de larchitecture par rapport aux propriétés requises (Safety, deadlock …) Tracer des scénarios dexécution Descendre dun niveau de description haut à un niveau plus bas Réflexion sur les techniques pour les architectures dynamiques

Une approche basée sur les graphes pour la description des architectures dynamiques Les graphes représentent un moyen simple et naturel pour décrire les architectures ( intuitivement, un composant = une boîte et une connexion = une ligne) : Un composant sera modélisé par un nœud. Une connexion par un arc. Par extension : Les lois qui gouvernent lévolution dynamique seront modélisées par des règles de transformation de graphe. Les styles darchitectures seront modélisés par des grammaires de graphe. Cet approche nous fournit : Une technique générale et indépendante de tout langage dimplémentation Une base formelle que sont les grammaires de graphes => vérification de la consistance de lévolution dynamique.

Abstract Component Graph (ACG): notre modèle pour les architectures logicielles dynamiques Larchitecture est modélisée par une structure sous forme de graphe quon appellera le graphe de larchitecture, où: Les noeuds décrivent les composants logiciels. Les arcs décrivent les interdépendances entre composants (liens de communication ou de contrôle, et lien de composition). Les lois régissant lévolution dynamique sont modélisées par des règles de transformation du graphe darchitecture selon un protocole de coordination. Une règle de transformation est décrite par un graphe partitionné quon appellera le graphe de la règle. La partition du graphe de la règle spécifie : Quand une évolution est possible ou pas : Exigeant la présence ou l absence dun Pattern dans le graphe de larchitecture Et comment lévolution est réalisée : Transformation du graphe de larchitecture par lajout et la suppression de Pattern. Génération des actions basiques pour la modification de larchitecture.

Exemple dune règle transformation Règle r1 = supprimer les serveur possédant au moins un producteur mais pas de consommateurs Match nodes S1, P, C2, S2; edges P -> S1, S2 -> C2; Absent nodes C; edges S1 -> C; Add nodes none; edges P -> S2; Delete nodes S1; edges P -> S1, S1 -> C; P S1 S2 C Add Abs Inv Del C2 Preconditio n Restriction postconditio n

P S1 S2 C1 Abs Inv Del C2 prod2 serv2 prod1 serv1 cons1 P S1 S2C2 P S1 S2C2 ABSENT Add cons2 PreconditionRestrictionPostcondition C1 Exemple : Application de la règle Graphe de l architecture Partition du graphe de la regle

Le protocol de coordination Associe à chaque type dévénements les règles de transformation. Instancie les règles avant leur application sur le graphe de l architecture Peut introduire des événements spéciaux permettant la vérification, pendant lexécution et continuellement, des propriétés de correction (Safety, completeness, de niveau applicatif).

Home Interface R3 R2 R1 R4 R5 Broadcaster Unify(G,r1)=OK C(p2) Unbind(C(p2),C(s2)) Del(C(s2)) Bind(C(p2),C(s2)) Current Graph G …… Coordination protocol Rewriting Rules C(s2) C(s1) C(p1) C(c1) C(c2) Unbind(C(p2),C(s2)) Del(C(s2)) Bind(C(p2),C(s2)) Unbind(C(p2),C(s2)) Del(C(s2)) Bind(C(p2),C(s2)) Instantiated Rule r1 P s1 C2 S1 C1 move _to(C(s1).ref) s2 p1s1 c1 p2 c2p1s1 c1 p2 c2 Unbind(C(p2),C(s2)) Del(C(s2)) Bind(C(p2),C(s2))

Besoin de la gestion de la dynamicité : La consistance Lévolution dynamique dune architecture peut engendrer une configuration inconsistante. Objectifs : La gestion et le control de la dynamicité. La vérification des propriétés de correction de larchitecture. La vérification et la preuve du modèle de lévolution dynamique. Writer2 Doc1 Doc2 Writer1 INCONSISTANCE

Styles darchitecture Les styles darchitecture sont définit par LIEEE comme une classe darchitectures possédant un modèle commun. Dans notre approche, les styles darchitecture sont utilisés comme moyen pour décrire les architectures admissibles ou consistantes dune application pouvant évoluer dynamiquement. Le problème quon cherche à résoudre, est lappartenance dune architecture, tout au long de son évolution, à son style darchitecture => Étant donnés le protocole de coordination, larchitecture ne pourra jamais se retrouver, suite à lapplication dune règle de transformation, hors de son style darchitecture.

Représentation des Styles darchitecture Description de larchitecture sous forme de graphe => description des styles darchitecture sous forme de grammaire de graphe. On a enrichi les productions usuelles des grammaires de graphe sous format, par lintroduction dun champ I. Une production sera donc décrite par un triplet de Pattern de la forme. On a aussi étendu notre modèle, par lintroduction de nœuds non terminaux (équivalent à la notion de non terminal dans les grammaires classiques), et darcs non terminaux (un arc non terminal est un arc donc lune des extrémités est un non terminal). Une grammaire de graphe est définie par le quadruplet, où AX est laxiome de la grammaire. NT, lensemble des nœuds non terminaux. T, lensemble des nœuds terminaux. P, lensemble des productions de la grammaire. Une architecture A appartient à un style darchitecture S ssi A peut- être obtenue à partir de laxiome par les productions de la grammaire de graphe décrivant S.

Exemple Le style darchitecture du producteur, serveur, consommateur peut-être décrite par le quadruplet :, Où prod est lensemble des productions suivantes : I - II - III - IV - V - VI - VII- VIII - IX - Ax I ARCHI CSP CSP C CSP C P III V IV CSP C P II Ax ARCHI S S

Vérification de la consistance de lévolution dynamique de larchitecture. Compatibilité entre règles de transformation et style darchitecture On a opté pour une vérification à priori et statique de la consistance des règles de transformation. Une approche pour faire la preuve de cette compatibilité est proposée et une preuve de lapproche elle-même a aussi été réalisée.

Techniques pour Architectures dynamiques Description Domaines dapplication Vérification Analyse ADLs DarwinWright Extensions pour la dynamicité non suffisantes Autres formalismes Styles darchitectures de services adaptables Adaptabilité intracomposant Adaptabilité intercomposant à 2 niveaux Adaptabilité intercomposant à 1 niveau TFMobilité Gestion de charge Preuve de conformité de la spécification de la reconfiguration dynamique à une certaine notion de la consistance de larchitecture Vérification de larchitecture par rapport aux propriétés requises (Safety, deadlock …) Tracer des scénarios dexécution Descendre dun niveau de description haut à un niveau plus bas Réflexion sur les techniques pour les architectures dynamiques

Caractérisation de Styles de base Plusieurs niveaux de dynamicité considérés selon que : Lévolution de larchitecture correspond à lajout et à la suppression de composants et de connections. La dynamicité se situe au niveau de la coordination entre composant (composants contenant la partie métier restant stables et évolution dynamique concerne les contrats qui les lient). La dynamicité se situe au niveau composant qui peut décider de dégrader, augmenter, introduire, ou cacher des services.

Patterns élémentaires Client C Provider P Interaction Link Client C Provider P Medium M Interaction Links Composition Link Component n Composite Comp Component 1 Composite and primitive Components provided n Provider P provided 1 Provided Services Providing Link required n Client C required 1 Required Services Requiring Link

High-level interaction Links P1M1C1 P2 M2 C2 P3M3C3 P4 M4 C4 CC1 CC2 CC3 CC4 P1C1 P2 C2 P3C3 P4 C4 CC1 CC2 CC3 CC4 CC1CC2CC3CC4CC5 C1C2 P2 P3 C3 P6 CC6 P4 C4 C5 P5 CC1CC2CC3CC4CC5 C1C2 M2 P3 M3 C3 P6 CC6 P4 M4 C4 M5 P5 CC1 C1 P1C2C3P2 P3 P4P5P6 CC2 CC3 CC4CC5CC6CC7 Exemples de sous styles spécialisés conformes à des styles de base