D'autres, comme les auteurs de [WHS02], situent l'utilisation des composants à la fin des années 70 comme une réponse à la deuxième crise du logiciel provoquée par l'introduction à grande échelle des micro-processeurs. Il a fallu alors produire des logiciels de meilleure qualité et de façon plus rapide et moins coûteuse. À cette époque, une nouvelle discipline du génie logiciel émerge : le CBSE (Component-Based Software Engineering). Elle est portée notamment par un centre de recherche créé par le gouvernement fédéral américain et exclusivement dédié au génie logiciel : le SEI (Software Engineering Institute).
Il est indéniable que la tendance vers le développement à base de composants s'est imposée depuis une quinzaine d'années, au moins en ce qui concerne les composants techniques disponibles commercialement dans les domaines tels que la gestion de l'information (systèmes de gestion de bases de données, systèmes géographiques, systèmes de gestion de données techniques) et les intergiciels (moniteurs transactionnels, systèmes répartis à objets, messageries inter-applications).
Les bénéfices attendus de l'utilisation de composants logiciels sont a priori clairs et trouvent une analogie souvent utilisée dans l'industrie automobile. Il s'agit essentiellement de réduire les coûts de production des logiciels, mais aussi d'en réduire les coûts de maintenance et d'en favoriser la réutilisation. Cette démarche est résumée par Fred Brooks [WHS02], de la société IBM : "buy before build" et "reuse before buy".
Néanmoins, cette démarche n'est pas toujours facile à suivre dans la pratique. En effet, l'assemblage des "pièces" logicielles pour constituer une application efficace et facile à utiliser nécessite un travail qui peut s'avérer fastidieux car il met en cause deux parties, dans ce contexte, dissociées : les producteurs et les consommateurs des composants logiciels. De plus, les composants, et plus particulièrement les composants commerciaux, sont souvent complexes (même les experts n'en connaissent pas toutes les capacités fonctionnelles) et instables (ajout fréquent de nouvelles fonctions au composant pour qu'il reste compétitif par rapport à la concurrence).
Par ailleurs, selon [WHS02], il existe également un écart indéniable entre théorie et pratique dans les méthodes de conception de systèmes fondés sur les composants. En effet, la plupart des théories s'appuient sur des techniques de spécification de composants logiciels alors que, la plupart du temps, les composants existent déjà. Il semble donc apparaître une contradiction entre d une part une conception architecturale qui permettrait de déterminer précisément comment le système est partitionné en composants, quelles fonctions sont offertes par chaque composant et comment les composants coordonnent leurs activités, et d autre part l'utilisation de composants préexistants qui induirait une perte de contrôle sur ces décisions de conception fondamentales. En réalité, deux classes de problèmes de conception doivent co-exister : les décisions de sélection d'un composant préexistant et les décisions d'optimisation del'architecture lorsqu'il est possible d'intervenir sur les interfaces des composants. C'est l'articulation entre ces deux points de vue qu'il faut bien maîtriser.
Le présent document a été réalisé dans le cadre du projet ACCORD (Assemblage de Composants par Contrats en environnement Ouvert et Réparti). Il est constitué de deux parties correspondant respectivement à un état de l'art et à un état de la standardisation dans le domaine de l'assemblage de composants logiciels par contrats.
La première partie présente les principaux concepts manipulés dans le cadre du projet ACCORD - composant, contrat et assemblage successivement dans cet ordre même s'il est, en réalité, difficile de dissocier ces trois notions.
La deuxième partie décrit la prise en compte des concepts présentés dans la première partie dans les standards de spécification et de structures d accueil pour composants et assemblages de composants. Ces deux aspects sont importants pour le projet ACCORD qui s intéresse particulièrement aux aspects de spécification mais vise également à faciliter la mise en oeuvre opérationnelle sur des plates-formes EJB et CCM.
La conclusion contient une synthèse ainsi que les choix de concepts et de standards effectués dans le projet ACCORD.
Pour mieux contrôler la complexité du logiciel, il est nécessaire d avoir un niveau d abstraction élevé et de disposer de modèles qui s approchent du modèle mental du développeur. Une réponse possible est la définition d une architecture du système. Une architecture logicielle à base de composants décrit l ensemble des composants qui la composent, donne la définition de leur assemblage et prend en compte les structures d accueil nécessaires pour le déploiement et l exploitation du système résultant. On peut dire que la définition de l architecture d un système correspond à l établissement du plan de construction du logiciel. Elle permet la conception d applications en se détachant de détails techniques propres à l environnement et en respectant les conditions fixées par les futurs utilisateurs. En maîtrisant l architecture conceptuelle, il est alors plus facile de gérer ses éventuelles évolutions. En effet la modification d un plan est plus simple que la modification d un système complet.
Les architectures logicielles dites explicites ont pour origine, à la fois les difficultés rencontrées par les concepteurs de gros logiciels, les caractéristiques de la programmation à grande échelle et également les besoins de réutilisation de logiciel. La plupart du temps, l architecture logicielle d un système est spécifiée de manière informelle et intuitive par un diagramme de type Box-and-line sans sémantique associée. Ce manque de définition rigoureuse vient essentiellement du fait que peu de démarches de conception intègrent cette étape, soit parce que la structure du logiciel est simple, soit parce qu au travers de l analyse, les différentes structures du logiciel ont été appréhendées. Cependant, avec l apparition de systèmes répartis, cette étape de définition d architecture devient incontournable.
Par cette notion de plan de logiciel, la complexité est prise en compte, les possibilités de réutilisation sont augmentées, et il est possible d utiliser des outils formels sur certaines parties précises de l architecture et de générer des parties de code automatiquement.
Des langages de description d architecture (ou ADL pour Architecture Description Language) répondent en partie à cette problématique en permettant la définition d un vocabulaire précis et commun pour les acteurs devant travailler autour la spécification liée à l architecture (architectes, concepteurs, développeurs, intégrateurs et testeurs). Ils spécifient les composants de l architecture de manière abstraite sans entrer dans des détails d implantation, définissent de manière explicite les interactions entre composants d un système et fournissent un support de modélisation pour aider les concepteurs à structurer et composer les différents éléments. En fait, les ADLs sont un support pour la description de la structure de l application. Ils offrent des facilités de réutilisation des composants et des moyens de description de la composition par description des dépendances entre composants et des règles de communication à respecter.
Dans ce document, dans la partie 2, nous allons décrire les concepts de base proposés par les langages de description d architecture. Dans la partie 3, nous décrirons succinctement différents langages de description d architectures. Dans la partie 4 nous donnerons des éléments de comparaison entre ces langages. Finalement nous conclurons ce travail en donnant les éléments à retenir pour le projet ACCORD.
Dans le domaine de développement de logiciels, le paradigme de coordination offre une façon prometteuse pour alléger les problèmes et adresser quelques solutions liées au développement de systèmes parallèles et distribués complexes. La programmation d un système parallèle ou réparti peut être vue comme une combinaison de deux activités distinctes : la partie calcul comprenant un nombre de processus impliqués dans la manipulation des données et la partie coordination responsable de la partie communication et coopération entre les processus. Ceci rend les modules ou les composants plus indépendant, permet l évolution d applications en modifiant seulement les éléments concernés et non en intervenant sur toute l application, et permet de réutiliser les objets sans la façon dont ils sont coordonnés et les entités de coordination sans les objets à coordonner.
De ce fait, l exploitation de tout le potentiel des systèmes massivement parallèles exige des modèles de programmation qui ont affaire explicitement avec la concurrence de la coopération parmi un grand nombre d entités actives que comprend une seule application. Ceci a conduit à la conception et l implantation d un grand nombre de modèles de coordination et leur langage de programmation associé. Presque la plupart de ces modèles partagent le même but, notamment de fournir un cadre qui mette en valeur la modularité, la réutilisation de composants déjà existants, la potabilité et l interopérabilité de langages. Cependant, ils diffèrent sur plusieurs aspects : comment précisément la notion de coordination est définie, ce qui sera exactement coordonné, comment la coordination est accomplie et quelles métaphores sont utilisées.
Dans ce qui suit, la section 2 présente les différentes définitions de la coordination, les modèles et les langages de coordination. La section 3 présente différents modèles et langages de coordination divisés en trois familles : orientés données, orientés événement et l approche par composant. Enfin, nous concluons en donnant une synthèse des approches présentées.
Les modèles à objets ont progressivement montré leurs limites. Certains industriels, comme Microsoft, Sun et l'OMG, ont fait évoluer leurs modèles vers les composants, dans le but de simplifier le développement d'applications. La réponse de l'OMG est le "CORBA Component Model" (CCM) modèle de base du futur standard CORBA 3. Dans un but de compatibilité ascendante, l'OMG a défini son modèle de composants comme une extension du modèle objet de CORBA 2. Les composants CORBA représentent donc une spécialisation des objets CORBA tels que nous les connaissons aujourd'hui. La spécification de ce standard n'est pas encore achevée; cependant, le chapitre sur le modèle de composants a été finalisé à l'OMG en janvier 2002. C'est donc l'un des plus jeunes modèles de composants mais aussi l'un des plus riches en comparaison avec d'autres modèles.
La spécification du CCM, qui représente plus de 1000 pages, est découpée en quatre modèles et un méta-modèle. Ce document décrit~:
Le Model Driven Architecture (MDA) est une méthode de développement proposée par l'OMG (Object Management Group). Elle permet de séparer les spécifications fonctionnelles d'un système des spécifications de son implémentation sur une plate-forme donnée. A cette fin, le MDA définit une architecture de spécifications structurée en modèles indépendants des plates-formes (PIM) et modèles spécifiques (PSM).
L'approche MDA permet de réaliser le même modèle sur plusieurs plates-formes grâce à des "mappings" standards. Elle permet aux applications d'interopérer en reliant leurs modèles et supporte l'évolution des plates-formes et des technologies. La mise en oeuvre du MDA est entièrement basée sur les modèles et leurs transformations.
Ce document présente, dans un premier temps, les motivations de l'OMG. Il aborde ensuite les différentes étapes de sa mise en oeuvre suivie par la présentation des bases techniques sur lesquelles repose le MDA. Enfin la dernière section résume où en est le travail de l'OMG dans cette démarche.