3.5.2.3 Evaluation
xArch part du même constat qu’ACME, c’est-à-dire le manque d’un environnement unificateur pour intégrer différentes préoccupations des ADL. Néanmoins, il propose une autre solution basée sur un nou-vel ADL minimaliste et extensible. Cette proposition consiste en un langage basé sur XML qui regroupe des constructions de base pour décrire des assemblages de composants et suggère l’utilisation des sché-mas XML pour procéder à des extensions. xADL est une extension de xArch pour décrire l’architecture des familles de produits.
Comparé aux ADL présentés dans les sections précédentes, xArch ne définit pas de modèle de com-posants. De par sa définition, xArch est compatible avec d’autres modèles de composants et permet potentiellement d’en utiliser plusieurs au sein d’une même architecture. De plus, l’extensibilité du lan-gage nous semble capable de répondre à tout type de préoccupations que l’on pourrait avoir dans un processus de conception à base de composants. En conséquence, xArch nous semble fournir un véritable environnement unificateur pour les ADL et modèles de composants existants.
Néanmoins, le support pour xArch reste ad hoc. En effet, aucune architecture d’outillage n’est dé-finie pour supporter les extensions du langage. En conséquence, cette proposition ne va pas plus loin qu’ACME en dehors de l’utilisation des schémas XML pour aider les concepteurs à vérifier certaines propriétés des descriptions. De plus, xArch propose d’unifier tous types de préoccupations dans un même langage à base de XML. Cette obligation de décrire dans un seul langage des architectures ayant diffé-rentes préoccupations nous semble une limitation importante ; nous pensons que l’utilisation de langages spécifiques aux domaines (DSL) constitue une solution bien plus confortable pour exprimer certaines informations de type protocolaire ou comportementale.
3.6 Approches basées sur des modèles
Bien qu’il ne soit en relation directe avec la conception de systèmes à partir de descriptions d’archi-tecture, nous dédions cette section à une présentation brève des approches de conception de systèmes logiciels à l’aide des modèles pour enrichir cet état de l’art avec des références aux travaux connexes. Il s’agit des approches d’ingénierie dirigées par des modèles [Sch06] (MDE pour Model Driven
Enginee-ring) ou d’architectures dirigées par des modèles [BG01] (MDA pour Model Driven Architecture)3.
3.6.1 Vision de l’Object Management Group
L’auteur de plusieurs standards connus comme CORBA [OMG01b] et UML [UML04], l’OMG a défini en 2001, une nouvelle approche pour la conception des systèmes. Cette approche est appelé l’ar-chitecture dirigée par des modèles ou MDA [MDA]. Au cœur de cette approche se trouve l’idée de faire de la conception, qui est plutôt perçu comme un processus de développement, le produit centrale du développement de logiciel [MW]. Ainsi, une fois le modèle d’un logiciel à mettre en œuvre est spécifié par les concepteurs, des outils de support de type CASE4pourront êtres utilisées pour analyser, vérifier, déployer et tester le modèle spécifié sur une plate-forme d’implantation donnée.
L’approche MDA favorise la séparation des préoccupations dans le sens de la définition de diffé-rentes vues abstraites d’un même système logiciel afin de permettre aux concepteurs de se concentrer uniquement sur les aspects qui les intéressent. Les deux grandes classes de modèles sont définies dans cette objectif sont :
– les modèles indépendants de plate-forme (PIM pour Platform Independent Model) qui sont uti-lisés pour modéliser de manière non-ambigue et sans détails liés à la plate-forme d’implantation
3MDA est une marque déposée par l’Object Management Group [dmddl] alors que l’acronyme MDE ne l’est pas. Par
conséquent, ce dernier est utilisé par une communauté plus large de recherche.
les fonctions métier d’un système logiciel.
– et les modèles spécifiques aux plates-formes (PSM pour Platform Specific Mode) qui corres-pondent à l’application d’un modèle PIM à des plates-formes d’implantation données (e.g. CORBA, EJB, J2EE, etc.).
L’abstraction des modèles misent en œuvre par les concepteurs des détailles liées à des plates-formes d’implantation est motivé par la réutilisation d’une même conception de système (i.e. d’un PIM) pour l’implanter sur des plates-formes différentes (i.e. plusieurs PSM). Idéalement, MDA suggère la mise en œuvre des modèles exécutables et des spécifications détaillées des plates-formes d’exécution de manière à pouvoir automatiser la migration de ces derniers à l’aide des outils de type CASE. Pour ce faire, diffé-rents moyens de modélisation et de méta-modélisation sont spécifiés, parmi lesquelles nous présentons par la suite UML, MOF et XMI.
Unified Modeling Language (UML) [UML04] constitue un formalisme de référence pour la mo-délisation des systèmes logiciels. UML est originellement conçu par l’OMG pour la momo-délisation des programmes à base d’objets mais intègre depuis sa version 2.0 [UML04] des extensions permettant la modélisation des logiciels à base de composants. La spécification d’UML propose un formalisme très riche couvrant un large spectre de préoccupations, allant de la qualité de service au temps-réel. Il permet de même la spécification des modèles exécutables, c’est-à-dire des modèles portant une sémantique suf-fisamment détaillée pour être exécuté sur une machine abstraite [RFBLO01]. L’approche MDA propose d’utiliser UML comme le langage de spécification des modèles PIM et PSM.
Meta Object Facility (MOF) [CDI+97, MOF00] est un outil de méta-modélisation défini par l’OMG
dans le but de standardiser un langage abstrait pour la spécification des langages de modélisation tels que UML, ou CWM [CWMa, CWMb]. L’apport principale de MOF se trouve dans son accentuation des concepts manipulés de manière à permettre l’utilisation de plusieurs syntaxes pour écrire des méta-modèles. MOF peut ainsi être utilisé comme un environnement pivot pour supporter l’interopérabilité ou la translation entre des modèles écrits dans différentes langages de modélisation.
XML Metadata Interchange (XMI) [XMI02] constitue l’application du standard MOF sur la syn-taxe XML. Est décrite dans le standard XMI, la manière dont des méta-modèles écrits en MOF peuvent être transformés en des DTD, pour permettre aux concepteurs (ou aux outils) de mettre en œuvre des descriptions MOF en XML. Ainsi, les méta-modèles MOF peuvent être diffusés sous une forme sériali-sée, pour assurer l’interopérabilité entre des systèmes répartis hétérogènes basés sur des méta-modèles distincts.
De nombreux outils académiques et commerciaux sont actuellement disponibles pour supporter le processus de développement à la MDA. Parmi ces outils, nous pouvons citer des outils d’édition et de manipulation de modèles (e.g. NetBeans Metadata Rhapsody [Rha], ModFact [Mod], Eclipse Modeling Framework [EMF]), des outils de génération de code (e.g. Rational Rose [Rat], EclipseUML [Ecl], Po-seidon [Pos] et ArgoUML [Arg]), des outils de vérification basés sur des contraintes [Ham06] et des outils de translation de modèles (e.g. UMT-QVT [UMT], ArcStyler [Arc]). Enfin, l’ensemble des outils suscités répondant uniquement à une phase donnée du développement de logiciel, certains outils comme ModelBus [BGS04] et FrameKit [Frac] proposent des environnements d’intégration dans l’objectif de permettre aux concepteurs de composer des chaînes de traitements dédiées en fonction de leurs besoins. 3.6.2 MDE/MDA et ADL
La conception de systèmes à l’aide des ADL peut être considéré comme une approche de conception à la MDA où les structures des systèmes logiciels sont modélisés sous la forme de descriptions d’architec-ture. Comme expliqué dans les sections précédentes, ces modèles sont utilisés à des fins de vérification, de génération de code où de déploiement. Il serait alors judicieux de constater que la conception de sys-tèmes à l’aide des ADL s’intègre tout à fait dans la vision MDA présentée par l’OMG, mais se restreint
3.7. Synthèse
dans le cadre de la structuration des programmes à base de composants.
Enfin, notons que les travaux présentés dans [Mar02] soulignent l’intérêt de conjuguer ces deux approches, et illustrent comment des outils MDA peuvent être utilisés pour la méta-modélisation des langages de description d’architectures afin d’assurer l’intéropérabilité entre des descriptions écrites en des ADL différents.
3.7 Synthèse
Nous avons présenté et analysé dans ce chapitre divers langages de description d’architectures qui ont été proposés dans les milieux académiques et industriels. Nous avons regroupé ces travaux sous l’angle de leurs contextes d’utilisation. Sans avoir cherché à être exhaustif, nous avons présenté différents axes d’utilisation : la modélisation et la validation de systèmes complexes, l’assemblage de composants à l’aide de générateurs de code pour créer des configurations logicielles spécialisées et, enfin, le déploie-ment et l’administration de systèmes répartis.
La synthèse des caractéristiques des travaux présentés illustre la diversité des préoccupations liées à l’architecture logicielle et nous permet de dégager des éléments de considérations différents en fonction des contextes d’utilisations.
– Les environnements de validation comme Rapide et Wright utilisent les composants comme des éléments d’encapsulation de comportements et se préoccupent de fournir des éléments de modé-lisations protocolaire ou comportementale. Dans Wright, les connecteurs sont reconnus comme des éléments architecturaux de premier niveau qui peuvent modéliser des sémantiques de commu-nication complexes. La sémantique associée aux interfaces est soit faible, soit concentrée sur le sens des données échangées (entrée/sortie). Enfin, notons que Rapide et Wright définissent leur propre modèle de composants. En conséquence, ils ne peuvent pas directement être utilisés pour modéliser des architectures réalisées à l’aide d’autres modèles.
– Les environnements de déploiement ont des considérations architecturales qui sont proches de celles des environnements de validation, mais ils se concentrent sur la description de l’organisation structurelle des systèmes répartis. Les composants sont des unités d’encapsulation de comporte-ments et de données qui interagissent uniquement par le biais de leurs interfaces. En revanche, il n’existe quasiment pas de moyen pour spécifier le comportement des composants. La sémantique associée aux interfaces est plutôt fonction du sens d’invocation (client/serveur ou exporté/importé). Les connecteurs sont en général des éléments de premier niveau qui sont utilisés pour implanter des protocoles de communication complexes correspondant aux besoins spécifiques des systèmes répartis. Dans ce cadre, certains travaux comme Olan, ou CIDL de Corba présentés dans le cha-pitre précédent fournissent la génération automatique des adaptateurs de communication entre des composants hétérogènes. Même si certains travaux proposent des solutions, la prise en compte de l’évolution dynamique de l’architecture doit être renforcée. Enfin, les outils sont en général associés à des modèles de programmation qui doivent être respectés lors de l’implantation des composants.
– Les environnements de configuration se préoccupent de réutiliser des modules logiciels afin d’as-sembler des systèmes spécialisés. Les exemples comme Knit de OSKit ou CDL de eCos illustrent bien le fait que l’architecture logicielle est une préoccupation secondaire. Le but principal est de donner suffisamment d’informations de haut niveau qui permettent d’assembler des modules en satisfaisant leurs dépendances. Les composants sont des unités d’encapsulation à gros grain qui remplissent des fonctions bien identifiées. Les notions d’interface et de connecteurs ne sont qua-siment pas présentes. Enfin dans certains cas, comme dans Knit, le langage de description prend réellement la forme d’un éditeur de liens sophistiqué qui assure l’assemblage des composants écrits en langage C.
Certains travaux comme ACME ou xADL constatent la diversité des langages de description d’ar-chitecture et de leurs préoccupations, ce qui les amènent à proposer des solutions fédératrices ou inté-gratrices. Les deux argumentent sur le fait qu’un langage unificateur est impossible à mettre en œuvre car même si on arrivait à prendre en compte l’ensemble des préoccupations mentionnées ci-dessus, il y aurait toujours de nouvelles préoccupations à prendre en considération dans le futur. Pour cette raison, ils proposent des langages d’« intersection » extensibles. Ceux-ci fixent la représentation d’un minimum d’éléments se trouvant en commun dans la plupart des langages, et laissent les concepteurs étendre le langage pour introduire des concepts spécifiques à leurs besoins. Néanmoins, ces propositions ne four-nissent pas de solution pour le support des langages définis. Ils échouent en particulier sur l’identification des éléments nécessaires au sein des outils associés pour la prise en compte des extensions introduites au niveau langage.
Notre analyse nous permet de faire les constats suivants.
– Les langages de description d’architectures prennent en considération de multiples éléments qui comprennent des éléments de structure organisationnelle (composants, interfaces, liaisons), et des éléments d’implantation (comportements, protocoles, déploiement, compilations, etc.). Il est en effet impossible de définir un langage standard, ou unificateur qui prendrait en compte l’en-semble de ces éléments. Dans ce cadre, les langages extensibles constituent une piste promet-teuse. Néanmoins, nous ne croyons pas qu’un seul langage extensible puisse satisfaire les concep-teurs pour décrire l’ensemble des aspects qui les préoccupent. Nous pensons que l’utilisation des langages spécifiques aux domaines (DSL) permettra d’exprimer de manière modulaire et confortable les différents éléments des architectures logicielles, que nous qualifions dorénavant d’hétérogènes.
– Chacun des travaux présentés remplit de manière isolée une fonction intéressante qui pourrait être intégrée dans un processus de développement complet. Les propositions de fédération restent au niveau de langages extensibles et ne spécifient pas comment les extensions pourraient être prises en compte pour concevoir des outils intégrés. Dans ce cadre, il y a un besoin crucial en termes d’outils extensibles qui pourraient intégrer l’ensemble des informations architecturales à supporter, et ce de manière évolutive en prenant en compte les extensions apportées au niveau du langage.
– Enfin, il existe de multiples domaines de l’ingénierie logicielle, allant des systèmes embarqués aux serveurs d’entreprises autonomes, qui bénéficient du développement basé sur l’architecture. Ceci crée une hétérogénéité en ce qui concerne les résultats attendus des outils. Citons par exemple la génération de code dans des langages de programmation variés ou le déploiement sur des plates-formes d’exécution hétérogènes. Pour cette raison, un support idéal devrait produire plu-sieurs types de résultats, et en particulier devrait être « reciblable » , afin d’être adapté à des contextes d’utilisation différents.
Chapitre 4
Le modèle de composants FRACTAL et les outils associés
Sommaire
4.1 Le modèle de composants FRACTAL . . . 68
4.1.1 Composants, composition hiérarchique et partage . . . 68 4.1.2 Séparation des préoccupations . . . 69 4.1.3 Liaisons flexibles . . . 70 4.1.4 Système de types . . . 70