Modélisation de l’architecture

4.2.1.1 Eléments et relations

Les motif d’architecture et participants du contrat ont besoin de désigner les éléments et relations de l’architecture. Mais surtout cette désignation doit être indépendante de l’implémentation concrète de ces derniers. Pour ce faire les éléments d’architec-ture, composants ou services, sont modélisés par une unique classe Reference. La spécialisation de celle-ci pour une architecture concrète détient la référence réelle vers l’élément d’architecture. Les attributs des éléments d’architecture, qui sont aussi des éléments d’architecture, par exemple les interfaces et les méthodes des composants, peuvent être aussi désignés par des classes Reference. Les relations entre éléments désignés par des Reference sont modélisées par des classes Relation. Ces classes

Relationreprésentent des relations aussi bien de configuration, comme des connex-ions entre interfaces de composants ou l’inclusion d’un composant dans un autre, que des relations plus statiques par rapport à l’exécution, comme le lien entre un com-posant et une de ses interfaces. Le lien avec les constituants du contrat est représenté sur la figure4.1.

FIGURE 4.1 – Liens entre contrat et architecture.

Ainsi pour appliquer le modèle de contrat à la plateforme Fractal, il faut spécialiser les classesReferenceetRelationcomme illustré dans la figure 4.2.

4.2.1.2 Chemins

LesReferenceet lesRelationpermettent de fournir au système de contrat une représen-tation générique des architectures mais ils ne permettent pas de désigner un ou plusieurs de ses éléments. Or le système de contrat nécessite un moyen d’obtenir de telles références. Pour répondre à ce besoin nous nous sommes inspirés de l’approche utilisée par XPath [106] pour désigner des noeuds dans un document XML.

XPath. XPath permet de désigner un ensemble de noeuds dans un document XML, comme étant les extrêmités d’un chemin composé d’une suite de relations parmi celles qui existent entre les noeuds d’un document XML. La sémantique de XPath repose sur une suite de sélections de noeuds : par exemple "/child : :A/child : :B/child : :C" sélectionne les noeuds enfants de la racine du document qui sont nommés "A", puis les noeuds enfants des noeuds nommés "A" et qui sont nommés "B", puis les noeuds enfants de ces derniers qui sont nommés "C", etc.... De manière plus générale il permet d’appliquer trois contraintes décrites pour chaque étape de la sélection de la manière suivante ".../axe : :nodetest[predicate]/..." :

noeuds de la sélection précédente, un axe simple est "child : :" qui sélectionne les noeuds enfants de ceux de la précédente sélection,

• "nodetest" : s’applique à la sélection courante et filtre les noeuds sélectionnés par l’axe, par défaut il est possible de remplacer "nodetest" par le nom du noeud recherché, mais il est aussi possible de placer à cet endroit un test sur le type du noeud (commentaire ...),

• "predicate" : il s’agit d’un prédicat agissant comme un filtre sur la sélection courante et contraignant les propriétés du noeud, par exemple quand la sélection courante comporte plusieurs noeuds le prédicat permet d’en extraire un en spécificant un numéro d’ordre dans la sélection,

APath. Nous avons donc défini une modélisation simplifiée des chemins répondant à notre besoin de désignation d’une référence. Cette solution comme XPath repose sur le parcours d’un chemin de relations architecturales et d’un filtrage des références obtenues à chaque étape, servant de point de départ à la suivante. Toutefois elle doit être indépendante de l’architecture tout en étant adaptable au plus grand nombre. Ainsi nous n’avons retenu que deux éléments essentiels :

• leLink: équivalent de l’axe, il permet de déduire d’une ou plusieurs références, une ou plusieurs références atteintes via une relation architecturale donnée (méth-odesresolve*Referencede la figure 4.3). Ainsi pour une relation de connexion, il retournera l’élément d’architecture connecté à un autre, pour une relation d’in-clusion il retournera les éléments d’architecture inclus dans un autre, etc,

• le Node: équivalent du prédicat, il permet de filtrer un ensemble de références pour ne conserver que celles qui satisfont à une condition donnée (méthode

architectureMatchde la figure 4.3). Basiquement il peut simplement s’agir du nom de l’élément d’architecture, comme le nom d’une interface ou d’un com-posant, ou de contraintes sur d’autres propriétés...

Les chemins de désignation sont ainsi constitués d’une suite alternée de Linket de

Node. Pour plus de généricité ces classes disposent chacune d’un ensemble, non limité, d’attributs génériques, stockés sous forme de paires nom-valeur. Ces attributs peu-vent notamment être utilisés pour stocker les paramètres de filtrage desNode(comme un nom, ou une autre caractéristique de l’élément d’architecture recherché). Ils per-mettent ainsi aux Nodeet Linkde prendre en compte des caractéristiques de filtrage variées suivant les propriétés propres à chaque type d’architecture sans modifier leurs interfaces. Les organisations du principe générique sont décrites dans la figure 4.3.

Application à Fractal

La mise en oeuvre dans le cas de Fractal des chemins est décrite dans la figure 4.4. Dans le cadre de l’architecture Fractal les différents types de relations décrivent l’ar-chitecture de la manière suivante :

• le FractalSubComponentLinklie un composite (FractalComponentNode) à un de ses sous composants (FractalComponentNode),

• leFractalBindingLinklie une interface cliente (FractalInterfaceNode) à une interface serveur (FractalInterfaceNode),

• leFractalConstitueOfLinklie une interface (FractalInterfaceNode) au com-posant qui l’expose (FractalComponentNode), ou une méthode (FractalMethodNode) à l’interface à laquelle elle appartient (FractalInterfaceNode),

Ainsi les trois types de Nodeet Link associés à Fractal suffisent à décrire complète-ment n’importe quel système bati sur ce modèle de composant. Par exemple pour obtenir une référence sur une interface, nous utiliserons un chemin du type suivant (avec une syntaxe paraphrasant celle de XPath, et en partant du noeud racine du sys-tème) :/FractalSubComponentLink::[FractalComponentNode(name="Car")] /FractalConstituteOfLink::[FractalInterfaceNode(name="sns")].