CHAPITRE 01 : LANGAGES DE DESCRIPTION D’ARCHITECTURE ET INGENIERIE DIRIGEE PAR
2. C3 (Component Connector Configuration)
C3 propose un connecteur de première classe qui supporte la construction sémantique et hiérarchique des architectures logicielles [AMI09]. C3 est une approche centrée sur les architectures logicielles. Elle permet de décrire une vue de l’architecture logique afin de générer automatiquement l’architecture physique pour toutes les instances de l’application. L’idée est basée sur le raffinement et la traçabilité des éléments architecturaux.
Par conséquent, pour décrire l’architecture logique, trois types de connecteurs sont définis : le connecteur de connexion (CC) utilisé pour connecter des composants et/ou des configurations, le connecteur de décomposition/composition(CDC) qui représente un lien structurel entre une configuration et ses constituants (composants, connecteurs), et le connecteur de compression/expansion (ECC) qui établit un lien de service entre une configuration et ses éléments internes. Chaque type a sa propre sémantique et sa propre forme.
Figure 1.18. Types de connecteurs dans C3
L'architecture physique est une image en mémoire de l'instance de l'architecture logique d'application. Cette image est construite sous forme d'un graphe dont les nœuds sont des instances. Les nœuds de ce graphe sont reliés par des arcs dont les types correspondent à des types spécifiques de connecteurs. Le mécanisme de typage présenté dans C3 permet de faire la distinction entre connecteurs et visualisation des connecteurs au niveau des modèles architecturaux. Cette distinction entre architecture physique et architecture logique permet une bonne gestion de toutes les instances de l’application. En revanche, les connecteurs proposés n’assurent pas la connexion des composants hétérogènes et ne prennent pas en considération la sémantique des configurations et des liens de communication entre composants.
Synthèse
Dans la littérature, plusieurs modèles de composants ont été proposés. Ces modèles offrent différentes façons de concevoir une application. Dans ce chapitre, nous avons présenté des exemples de modèles. Il
Page 59
existe d’autres modèles tels que: .Net, Darwin, OSGi, UniCon, Wright, etc. Cependant, ces modèles se caractérisent par le fait qu’ils sont trop proches de la mise en œuvre et imposent des choix de conception dès les premières phases du développement. Or, nous pensons qu’il est préférable d’introduire ces contraintes progressivement.
Les langages de description d’architecture (ADL) que nous venons de présenter ont tous pour vocation la formalisation, la vérification et la validation d’architectures. Leur but est de raisonner à un niveau plus abstrait que l’implémentation. Cette abstraction permet au concepteur de mieux appréhender la complexité de l’application et de mieux concevoir le fonctionnement et le découpage de celle-ci ainsi que les connexions entre ses différents éléments. La définition de l’architecture d’un système revient donc à la définition des différents composants et connecteurs utilisés dans le système ainsi que de la topologie de leur interconnexion, à l’exception de Rapide où les connexions sont seulement spécifiées dans les composants comme des comportements de communication. Fractal a la particularité d’être introspectable et autorise le partage de composants. Alors que Kmelia présente l’avantage de mettre en avant la notion de service ce qui procure un pont relativement naturel avec les architectures orientées services. Le comportement (dynamique) d’un service est caractérisé par un automate qui précise les enchaînements d’actions autorisés. Ces actions sont des calculs, des communications (émissions, réceptions de messages), des invocations ou des retours de services. SCA propose la notion de liaison pour l'assemblage et de modules pour la création des hiérarchies de composants. SCA n'impose pas une forme prédéterminée de liaison, mais autorise l'utilisation de différentes technologies, comme SOAP, JMS(Java Message Service) ou IIOP pour mettre en œuvre ces liaisons. De même, Fractal autorise différents types de liaisons et n'impose pas de technologie particulière.
Bien qu’ils aient beaucoup de points en commun, les buts recherchés par les ADL ne sont pas toujours les mêmes. Par exemple, certains s’intéressent plus particulièrement à la sémantique des composants et des connecteurs alors que d’autres s’attachent plutôt à définir les interconnexions entre composants et connecteurs. Chaque ADL possède alors ses atouts et le choix de l’un plutôt qu’un autre est guidé essentiellement par les besoins et les attentes du concepteur du système.
Le tableau 1.8 synthétise les critères des ADL cités précédemment :
Rapide Fractal SCA Kmelia COSA Reconfiguration
dynamique Non Oui Non Non Non
Reconfiguration
statique Non Oui Non Non Oui
Spécification
dynamique Oui Non Non Oui Non
Spécification
Page 60
Séparation des
préoccupations Non Oui Non Non Oui Constructions
récurrentes Non Oui Non Non Non
Point d’accès à
un composant Service requiers Interface fonctionnel Service Service Port Partage de
composant Non Oui Non Non Non
Bibliothèques de
composants Non Oui Non Non Non
Communication
échange de messages ou d’évènements
communication à
travers les liaisons Non explicite
liens entre
services Connecteur
TABLE 1.8. EVALUATION PAR RAPPORT AUX CRITERES DES ADL
Dans le tableau 1.8 nous pouvons voir que l’ADL Rapide, malgré l’avantage de vérification dynamique des applications et le mécanisme de raisonnement formel sur les architectures, ne permet pas de générer une application. Tandis que pour fractal c’est l’architecture qui n’est pas très visible. Nous voyons aussi que la plupart des ADL négligent l’aspect de communication et ne proposent pas de solutions explicites pour le faire.
Le tableau 1.9 résume les principaux concepts des architectures logicielles tels que : composant, connecteur, configuration, etc.
Concepts ADL
Composant Connecteur Service Configuration Interface Rôle Port Attachement Variable de Contrôleur
Rapide
Oui Non Oui Non Oui Non Non Oui OuiFractal
Oui Non Non Non Oui Non Non Oui OuiSCA
Oui Non Oui Oui Oui Non Non Oui OuiKmelia
Oui Non Oui Oui Oui Non Oui Oui OuiCOSA
Oui Oui Oui Oui Oui Oui Oui Oui NonTABLE 1.9. CONCEPTS ARCHITECTUREAUX
Le tableau 1.9 montre que la plupart des ADL ne considèrent pas les connecteurs comme éléments de première classe, à l’exception de COSA qui est parmi les rares langages qui prennent en considération tous les concepts des ADL et qui font la différence entre composant et connecteur par l’utilisation du concept de port et de rôle.
Le tableau 1.10 donne les définitions des principaux concepts pour chaque ADL.
Rapide
Fractal
SCA
Kmelia
COSA
C om p o san t Constitué d’une interface de services (Provides, Requiers, Actions).
Découpé en: Contenu & Membrane
Deux types : composites, primitifs Un ensemble de services et de références Abstrait, Indépendant de l’environnement Non exécutable. Un ensemble de ports et de services (fournis/requis).
Page 61 C on ne ct eu r Connecteur non explicite, connexion par flux causal ou par appel de fonction
Connecteur non explicite Connecteur non explicite Connecteur non explicite Connecteur explicite
In te rf ac e Constituée d’un ensemble de services fournis et requis, et contient une description du comportement Point d’accès à un composant, Interfaces fonctionnelles et interfaces contrôleurs Services offerts Services requis (références) Services offerts Composé de services et de ports \ rôles de communication. L iai son
Lien entre services requiers et provides.
Lien entre une interface client d’un composant et une interface serveur d’un autre composant.
Lien entre un service et une référence ou un autre composant Non-SCA.
Les services requis par certains composants sont liés aux services offerts par d’autres composants. Etablissement de canaux implicites pour les communications.
Deux types de lien : Attachement : un lien entre un port et un rôle. Binding : un lien intra- composant. C on tr ô le ur Contraintes sur le comportement des composants Permettent l’introspection et la configuration dynamique d’un composant. Prennent en charge les propriétés non fonctionnelles,
Ensemble de propriétés contiennent des valeurs sur l’application, l’environnement et l’état du composant. Consultable par le composant.
Correction au niveau des services (propriétés fonctionnelles) et des assemblages du point de vue des données (propriétés d’assemblage). Règles à prendre en compte lors de la conception. C on figu ra tion Remplacée par le concept d’architecture qui utilise une spécification textuelle explicite Composant composite Assemblage de composants, services, références, propriétés et des liens qui existent entre ces éléments
Assemblage de composants
Composition de composants, de
connecteurs et d’interfaces
TABLE 1.10. DEFINITION DES PRINCIPAUX CONCEPTS ARCHITECTURAUX
L'intérêt de Rapide par rapport aux autres langages étudiés est de fournir des réponses au problème de la description de la dynamique d'une application en termes de schéma de création des composants logiciels, de désignation dynamique des participants à une interconnexion. Ceci est permis par l'utilisation de règles d'interconnexion qui sont "déclenchées" par le comportement des composants logiciels, que ce soit lors d'un changement d'état ou d’une demande de communication avec d'autres composants.
A l’issue de ces comparaisons, on peut dire que les architectures orientées service se rapprochent du monde des composants logiciels. Un exemple est la spécification SCA (Service Component Architecture) qui propose un modèle de programmation pour la construction d’applications à base de composants. SCA intègre les orchestrations WS-BPEL comme des composants qui peuvent être assemblés avec d'autres composants SCA.
A travers les avantages et inconvénients présentés précédemment, les qualités et caractéristiques principales [OUS05] devant être satisfaites dans un modèle de composants sont la réutilisabilité et l’adaptabilité. Par la réutilisabilité, on désigne le degré de réutilisation permis par un modèle de composants. L’adaptabilité quant à elle, exprime l’aptitude à contrôler et permettre à un modèle de composants d’évoluer dynamiquement. Pour accroître la réutilisabilité d’un modèle de composants, certains critères sont préconisés comme :
Page 62
• L’extensibilité : traduit le fait que l’ajout de nouveaux services ne doit pas perturber ceux déjà existants.
• L’évolutivité : signifie que la mise à jour de l’implémentation d’un composant ne doit pas avoir d’impact sur les composants utilisant ses services.
• La compositionalité : est obtenue par exemple si un composant inclut d’autres composants et délègue ses services d’interfaces aux interfaces de ses composants internes.
• La remplaçabilité : la possibilité de remplacer un composant par un autre qui offre la même interface.
L’objectif principal d’une configuration et d’un assemblage de composants est la coopération et/ou la coordination afin de satisfaire un besoin ou un service. Cette connexion des composants est réalisée en utilisant des mécanismes et des protocoles de communication. Cette communication est représentée par des échanges de flux de données qui sont généralement variés (image, texte, son et vidéo), ce qui nécessite une vérification de cette extension lors de la configuration des composants afin de pouvoir traité le problème d’hétérogénéité engendré par l’échange de données multimédia. Malgré les avantages présentés des différents ADL, cette propriété de communication n’était pas prise en compte dans tous les ADL, ce qui nous a donné l’idée de proposé un métamodèle qui permet la représentation et la prise en compte des échanges entre composants.
Contrairement aux ADL présentés, nous considérons les connecteurs comme des unités d'interaction dotés de comportements dynamiques qui leur permettent de prendre en compte des préoccupations non- fonctionnels. Dans le chapitre suivant, nous allons présenter notre modèle de composants (MMSA) pour les applications multimédia. Il fournit des descriptions dans lesquelles les connecteurs et les services sont les principales entités.
Malgré les nouvelles constructions offertes par UML2.0 [OMG, 2003a] [OMG, 2003b] liées à la description des architectures logicielles, le monde UML continue à sous-estimer l’importance de l’«architecture logicielle» pour l’obtention de logiciels de qualité c’est-à-dire de logiciels corrects, extensibles et réutilisables. Pour faire face à cette situation, nous préconisons une adaptation d’UML2.0 à un métamodèle qui prend en considération les concepts liées au flux multimédia et à l’adaptation de l’architecture logicielle en fonction de l’hétérogénéité comportementale des composants. En outre, UML 2.0 fournit des mécanismes de base pour la définition de profils UML dans le domaine des architectures logicielles.