Le modèle XML d‟agrégation

Pour faciliter l‟implémentation des patrons d‟agrégation proposés, une représentation à l‟aide d‟un langage indépendant des plateformes technologiques s‟impose. Nous avons choisi le langage XML pour représenter de façon structurée les différents modèles d‟agrégations. Avec ce format, les développeurs intégrateurs peuvent utiliser le langage de programmation approprié à leur plateforme technologique pour transformer la composition de l‟agrégat et ses interactions en appel de méthode dans le langage hôte choisi.

Il est important de rappeler que nous n‟implantons pas ce modèle XML, étant donné que l‟implantation des agrégats est hors portée dans cette thèse. Nous le discutons ici pour montrer que les patrons que nous proposons ne sont pas uniquement des modèles conceptuels, mais ils peuvent être utilisés pour une implémentation réelle suite à une transformation XML à partir du modèle des composants représenté en UML 2.0. Le résultat de la transformation est un document XML qui décrit la composition d‟un agrégat ainsi que les interactions entre les composants agrégés. Le modèle suivant concrétise un exemple d‟un document XML d‟un agrégat logiciel.

Nouveau composant agrégat

Composant 2: Client/Serveur

Composant 3: Client/Serveur

Figure 3.16 Exemple d‟un document XML d‟un agrégat de composants

3.7 Conclusion

La proposition des métadonnées SOCOM est une classification des composants logiciels qui facilite la recherche, la sélection des composants ainsi que l‟analyse de faisabilité de leur

<services>

<provided-services>

<provided-service id=> service P1 </provided-service> <provided-service> service P2 </provided-service>

</provided-services> <required-services>

< required-service> service R1 </ required-service> </ required-services> </services> </component> <component> <component-name>Component 2</component-name> <services> <provided-services>

<provided-service> service P3 </provided- service>

<provided-service> service P4 </provided- service>

</provided-services> <required-services>

<required-service> service R2 </required- service> </required-services> </services> </component> </components> <components-interactions> <interaction name=’’Interaction 1’’> <source> <service-flow>

<service refid=> component service 1</service> <service> component service 2</service>

</service-flow> </interaction>

<interaction name=’’Interaction 2’’> <service-flow>

<service> component service 1</service> <service> component service 2</service> </service-flow>

</interaction>

</components-interactions> </AggregateComponent>

agrégation. La mise en équation de quelques attributs d‟agrégation de SOCOM a permis de définir quatre classes d‟agrégation des composants. Ces classifications permettent d‟assister un architecte durant la phase d‟analyse d‟un processus de développement logiciel à base de composants. En effet, après l‟identification des composants à agréger, la classification de l‟agrégation de ces composants facilite la phase de conception et d‟implantation. En appliquant les équations des quatre classes d‟agrégation, l‟architecte décide laquelle des classes d‟agrégation convient le mieux à son contexte, pour pouvoir ensuite appliquer un des patrons associés. Les choix de la classe d‟agrégation et du patron associé offrent à l‟architecte une manière de structurer les composants à agréger et leur interaction selon un modèle prédéfini par le patron. Ceci représente un gain en temps et en productivité dans une perspective de développement par la réutilisation.

Il est important de rappeler qu‟avec ces classes d‟agrégation et les modèles des patrons associés, nous avons défini un ensemble de modèles pour renforcer le volet « modélisation » du processus d‟agrégation cible dirigé par les métadonnées et les modèles. Ce processus est présenté en détail dans les deux chapitres suivants.

Le tableau suivant décrit l‟apport des classifications des agrégats, comme résultat de recherche, aux phases d‟un processus de développement à base de composants.

Tableau 3.7 Matrice des apports de la classification des agrégats aux phases du processus de développement à base de composants

Résultats de la thèse Description des contributions des résultats par phase

Classification des

agrégats

Phase de recherche :

- La classification ajoute une nouvelle option de recherche. L‟architecte peut rechercher les agrégats d‟une même classe ou, connaissant les composants participants du nouvel agrégat, il peut rechercher toutes les agrégations contenant un de ses composants participants. Les métadonnées des composants agrégats trouvées peuvent aider l‟architecte dans le processus de développement du nouvel agrégat.

Phase d’adaptation:

- En sélectionnant une classe d‟agrégation, le modèle de la classification oriente l‟architecte dans la conception du composant agrégat et dans l‟adaptation des composants participants.

Phase d’intégration:

- En sélectionnant une classe d‟agrégation, le modèle de la classification oriente l‟architecte sur la manière de coder l‟agrégation.

Patrons d’agrégat Phase d’adaptation:

- Les patrons proposent à l‟intégrateur une structure sur les interactions du composant agrégat avec les composants participants. L‟intégrateur peut l‟utiliser pour adapter ses composants au contexte de l‟agrégation.

Phase d’intégration:

- Le choix du patron durant la phase d‟adaptation aide l‟intégrateur dans l‟implémentation de l‟agrégat. Il peut réutiliser un patron de code ou en développer un nouveau qui pourrait être réutilisable ultérieurement. (composant logique vs composant physique, fusion totale vs fusion en partie, coordination fédérée vs coordination répartie).