Le motif architectural ( ArchitecturalPatternInstance )

Tout comme les spécifications, la validité d’une architecture gagne à être exprimée et établie de manière modulaire. Il est intéressant de considérer l’architecture non pas prise dans son ensemble (et pour toutes ses spécifications), mais via des sous ensem-bles d’éléments interconnectés. Limiter la portée architecturale des contrats (tant en étendue que dans la nature des relations contraintes) permet :

• en cas d’une modification locale de l’architecture, de ne re-valider qu’un contrat local, et non pas un contrat global remettant en cause tout le système,

• d’évaluer la validité de sous ensembles pertinents et lisibles de l’architecture, comme par exemple des design patterns ou des styles architecturaux,

• de limiter la portion d’architecture remise en cause par la violation du contrat, et donc potentiellement de laisser le reste de l’architecture s’exécuter,

Un cas de figure typique est celui des systèmes à composants hiérarchiques : certaines parties d’une architecture ne sont pas toujours visibles depuis d’autres, et on peut donc déjà distinguer les contrats qui vont s’appliquer entre les composants qui se voient mutuellement car ils sont indépendants de ceux qu’ils ne voient pas.

Ainsi dans le cadre d’une architecture, il faut pouvoir distinguer les éléments d’archi-tecture qui vont être des participants du contrat. Il faut aussi distingeur les relations que ce dernier va contraindre car elles vont guider la production des clauses et de l’accord, en permettant d’identifier les échanges à considérer. Ceci est l’objet du motif d’architecture qui définit de manière générique un ensemble d’éléments d’architec-tures et de relations les connectant à l’aide d’un ensemble de conditions portant sur

les premiers et les seconds. Chaque ensemble d’éléments et relations d’un système sat-isfaisant à un motif d’architecture est nommé "instance" du motif d’architecture. Un exemple de motif d’architecture est donné sur la figure 3.12.

FIGURE 3.12 – Un motif d’architecture et son instance

Un exemple de motif d’architecture basique (ne contenant qu’une seule relation) est celui du client serveur pour les composants :

• relation : une relation de connexion d’interface entre deux composants, • composants : les composants client et serveur liés par cette relation,

Un autre exemple de motif basique est celui du design pattern "sujet - observateur", qui désigne seulement la connexion d’une unique interface à plusieurs autres. Dans le cadre de notre exemple, d’autres éléments que le moteur pourraient être intéressés par les décisions du <CruiseCtrl>. Ce dernier leur donne donc la possibilité de s’enreg-istrer comme "écouteurs" de ses actions dont il les notifie alors, comme illustré sur la figure 3.13 qui montre une instance du motif "sujet observateur".

Les interfaces serveur SubjectObserver des écouteurs viennent se connecter à l’u-nique interface clienteObserverduCruiseCtrlpour former une instance de ce motif d’architecture. Il est défini de manière générique par un ensemble de relations de con-nexion liant une unique interface cliente,Observer, à un ensemble d’interfaces serveur

Subject-Observer. L’application d’un contrat à ce motif permettra d’exprimer et vérifier des propriétés d’interaction qui lui sont propres comme par exemple que chaque notifica-tion est effectuée une seule fois, que chaque message est bien reçu, etc...

3.4.3.1 Principe

Un motif d’architecture (ArchitecturalPattern) est la description générique, c’est à dire indépendante d’une instance architecturale particulière, des relations sur lesquelles porte le contrat. La description de ce motif repose sur trois types de propriétés :

FIGURE 3.13 – instance du motif d’architecture sujet observateur

• sa géométrie : composée d’un ensemble de relations, dont on peut décrire

l’organ-isation de manière simple à l’aide d’expressions du type : début(relation1)=fin(relation2), • les propriétés des relations qu’il accepte. Par exemple, on peut avoir pour

"rela-tion1" une relation d’inclusion, pour "relation2" une relation de connexion, • les propriétés des entités qu’il accepte aux extrêmités des relations, par exemple :

debut(relation1)=composant composite,

FIGURE 3.14 – illustration du motif d’architecture sujet observateur

Par exemple le motif architectural "sujet-observateur" dont nous avons donné un ex-emple d’instance précédemment pourra se définir de la manière suivante (illustrée par la figure 3.14) :

• géométrie : début(relationi)=début(relationj) quelques soient i et j,

• propriété des relations : relationi sont des relations de connexion d’interfaces, • extrêmités des relations : quelque soit i : debut(relationi)=interface clientObserver,

Au sein du motif d’architecture les positions peuvent occuper les éléments d’architec-ture, extrêmités des relations, peuvent être associées à des noms. Ces noms définissent des rôles au sein du motif d’architecture. Il faut noter que dans le cadre d’un motif d’artchitecture donné : un rôle peut s’appliquer à plusieurs positions mais qu’une po-sition ne possède qu’un seul rôle. Par exemple dans le cas d’un contrat d’interface, une entité à l’extrêmité de la relation de connexion sera à la place du "serveur", l’entité à l’autre extrêmité sera à la place du "client". Dans le cas du motif sujet observateur, le porteur de l’interfaceObserver(interface offerte aux observateurs) sera le "sujet", les autres composants sont les "observateur"s.

Par ailleurs le motif d’architecture ne traverse jamais une frontière de visibilité dans l’architecture à laquelle il s’applique. Nous nommons porteur du contrat, le plus pe-tit élément d’architecture englobant les relations sur lesquelles porte le contrat. Nous disons alors que le contrat s’applique dans la portée de cet élément. Ainsi par exem-ple dans le cas d’un système d’éléments d’architecture hiérarchiques, le porteur d’un contrat est toujours un composite (éventuellement la racine de l’architecture). En effet le plus petit englobant de toute relation dans ce type d’architecture, est le composant contenant les composants qui sont reliés.

3.4.3.2 Fonctionnement

Une instance de motif d’architecture, ou ArchitecturalPatternInstance, désigne un en-semble de relations architecturales entre des entités qui occupent des rôles. Pour savoir quelle relation peut entrer dans une instance de motif d’architecture, l’Architectural-Pattern fonctionne de la manière suivante :

• pour chaque relation architecturale qu’on lui soumet, définie par deux éléments d’architecture et la description de leur lien, il retourne si elle peut faire partie d’une de ses instances,

• si une relation soumise peut faire partie d’une instance, l’ArchitecturalPattern retourne en plus le(s) couple(s) de rôles que peuvent occuper ses extrêmités, Une fois que le couple de rôles acceptable pour une relation est connu, il faut soumet-tre cette relation, pour ces rôles, aux instances existantes du motif d’architecture qui ne sont pas complètes. Si une instance accepte la relation, alors elle lui est ajoutée et le processus se termine pour cette relation. Si aucune instance de motif d’architecture n’accepte, pour ces rôles, la relation alors il faut en créer une nouvelle instance qui contiendra la relation, dont les extrêmités auront les rôles déterminés par l’Architec-turalPattern. La figure 3.15 illustre ce processus.

Les règles concernant le placement d’une relation architecturale dans une instance de motif d’architecture sont simples, et évitent la problématique complexe du "pattern

matching" :

• 1) une entité, extrêmité d’une relation architecturale, ne peut occuper qu’une seule position au sein d’un ArchitecturalPatternInstance, par extension une entité ne peut avoir qu’un seul rôle dans une instance donnée de motif d’architecture, • 2) deux entités différentes, extrêmités de deux relations architecturales, ne

FIGURE 3.15 – Processus de création des instances de motif architectural

• 3) une relation ne peut voir ses deux extrêmités avoir les mêmes rôles dans deux instances d’un même motif d’architecture. Ainsi une relation peut appartenir à plusieurs instance d’un motif d’architecture mais de sorte qu’une au moins de ses extrêmités occupent des rôles différents.

Ces règles permettent de produire les ArchitecturalPatternInstance mécaniquement sur la base de l’énumération des relations et de leur soumission à l’ArchitecturalPat-tern pris en compte. En effet, en considérant la construction incrémentale des instances d’un motif d’architecture par ajout de nouvelles relations, pour chaque nouvelle rela-tion, soit :

• il existe une instance dans laquelle un couple de rôles acceptables pour la nou-velle relation définit une position libre, on ajoute alors la relation à cette instance pour ces rôles. La définition de liberté d’une position étant donnée par les règles 1 et 2.

• il n’existe pas d’instance dans laquelle un couple de rôles acceptables pour la nouvelle relation définit une position libre, on crée une instance de motif d’ar-chitecture à laquelle on ajoute la relation pour un des couples de rôles que ses extrêmités peuvent occuper,

Finalement, la règle 3 permet de stopper le processus de création des instances de mo-tifs d’architecture pour une relation donnée et un motif d’architecture donné. Par con-tre elle contraint fortement la couverture de l’architecture par les motifs architecturaux. En effet deux instances d’un même motif architectural ne peuvent en leur sein donner la même position à une relation de l’architecture. Toutefois cette limitation ne nous a pas semblé un problème majeur face au vaste problème de détermination de la couver-ture d’un graphe par un autre plus petit.