| Témoignage |
 Écrivez à AILES ! |
 Retour vers programmation |
Retour vers les questions Langage |
Retour vers les questions Composant |
|
« À la recherche de la réutilisabilité ultime »... tel pourrait être le but suprême qui se cache derrière cette "nouvelle" approche. "Nouvelle" car il y a 14 ans, en 1988, Bertrand Meyer parlait déjà ([OOSC]) de "composabilité modulaire", décrivant ce critère de composabilité comme le "reflet d'un vieux rêve : transformer le processus de conception logiciel en un jeu de construction, où des programmes seraient construits à partir d'éléments standard existants." ... Ben on en n'est pas encore arrivé là! Mais en attendant, voici où nous en sommes avec le "composant", dans ses grandes lignes. |
Sens commun d'un composant :
Toutes les définitions impliquent un ensemble cohérent de données informatique (le plus souvent des fichiers). Il s'agit donc à la base d'une encapsulation.
Ainsi, on trouvera comme ensemble cohérent de fichier des sources, exécutables, scripts et documentation concernant :
- une application IHM (donc un "composant applicatif") ;
- un "composant technique transverse", typiquement un framework sur lequel on viendra se brancher;
- un "composant technique layer", typiquement un connecteur entre un système middle-office et back-office.
- un "composant métier distribué", donc qui expose ses services (sur un bus, un middleware, etc...)
Bref, il s'agit du composant générique évoqué dans les caractéristique de base de l'Architecture et déjà introduit dans la définition même de l'Architecture.
En résumé, comme le rappelle [BAF99], « Components are software assets written in a given language. Architectures organize component in a logical way »... à ceci prêt que plusieurs langages peuvent intervenir au sein d'un même composant.
Dans les caractéristique de base de l'Architecture, j'évoque 3 fonctions associées à ces composants génériques :
- des données ("DataComponent"),
- des éléments qui transforment ces données ("ProcessingComponent"),
- des éléments qui assurent une connexion entre eux ("ConnectionComponent").
Enfin, le domaine de l'Architecture de Développement qui manipule des composants au sens "générique" du terme est la gestion de configuration, en charge de gérer les changements et évolutions appliqués à un ensemble cohérent de fichier durant l'ensemble du cycle de développement. La granularité d'un composant prend alors une importance cruciale en prod' (mise en production) : il est difficile de corriger rapidement un bug parmi 5000 sources et documentations... mieux vaut que chaque composant soit dimensionné dès le départ pour une mise en production efficace et modulaire!
Paradigme de développement "orienté-composant"
Si l'on se considère le composant à un niveau de granularité peu élevé - à savoir l'objet (encore plus bas dans la granularité, on trouve le fichier évoqué dans la réponse précédente), [BMwU00] précise que le développement orienté-composant a déjà - presque - remplacé le développement orienté objet. A ce niveau, en effet, il existe des modèles de composants tels que Microsoft COM+, Sun Enterprise JavaBeans et CORBA. Les Web services viennent récemment compléter le tableau.
Toujours à ce niveau de granularité, le développement orienté-composant est la réponse au problème de réutilisation d'objet au niveau du code : cette réutilisation était bien trop compliquée, car elle suppose que l'élément réutilisé le soit dans un code "compatible" avec la nouvelle application.
[BCF00] résume alors la situation : d'un point de vue "réutilisation", un programme écrit en langage orienté-objet (par exemple en C++) est vu par un autre programme (même orienté-objet comme le Java) comme une application toute aussi monolithique que si ce premier programme avait été écrit en COBOL!
Les composants évoqués s'appuient d'abord sur la notion d'interface : il est plus facile de se mettre d'accord sur une interface commune (qui peut être une simple liste textuelle de caractéristiques - attributs et méthodes -) que sur un langage commun, avec des règles syntaxiques complexes...
Vu sous l'angle de l'interface, [BMwU00] cite la définition suivante du composant :
"An executable unit of code that provides physical black-box encapsulation of related services. Its services can only been accessed through a consistent, published interface that include an interaction standard".
Si l'aspect "distribution" n'est pas explicitement mentionné, il saute aux yeux qu'un tel composant se prête parfaitement à la programmation distribué. Cela est abordé dans la réponse suivante.
Si l'on considère le point de vue de l'Architecture Technique, on retrouve le composant utilisé dans le diagramme de composant pour représenter le point de vue de configuration physique (ou logiciel). C'est un composant technique.
[UML-UG] définit alors un composant comme "a physical and replaceable part of a system that conform to and provides the realization of a set of interfaces.". Concrètement, un composant représente physiquement une librairie, un exécutable ou même des fichiers, comme un cpp et un header - 2 composants associés à une classe logique - : ce composant technique physique reste bien compatible avec la définition précédente de [BMwU00], sans pour autant définir nécessairement un "composant distribué" : un cpp et un .h peuvent implémenter n'importe quel type d'objet...
L'objectif de ces 2 premières questions ("Sens commun" et "Paradigme") a donc été de montrer que l'on pouvait parler de composant sans nécessairement parler "composant distribué" (aspect qui vient trop souvent à l'esprit en cette période "Internet").
Le composant a d'abord été vu comme une encapsulation, un ensemble cohérent - par exemple, de fichier -, puis comme un moyen d'implémenter et publier une interface. En allant plus loin dans ses possibilités, on tombe sur le composant distribué.
Caractéristique majeure d'un composant :
La caractéristique qui suscite le plus d'intérêt concernant les composant en ce moment (2002-2003) reste l'aspect "distribution".
Or, les objets aussi peuvent être distribués, mais [BCF00] considère les composants distribués comme au-dessus des systèmes distribués qui eux sont constitués d'objets distribués.
En fait, en terme de distribution, il faut penser "granularité" : quelle est la taille de ce l'on distribue ? Cela peut prendre la forme de :
- un simple objet, un "composant distribué" au sens COM, CORBA, etc...;
- un application constituée de composants distribués sur différents tiers (chaque tier étant une unité logique de distribution : un tier pour les ressources comme les bases de données, un tier pour l'utilisateur avec son IHM, etc... tous ces tiers peuvent se retrouver sur un même tier physique, à savoir un même ordinateur!), donc un "composant métier",
-un système constitué de plusieurs composants métiers, donc un "système de composants métiers".
- plusieurs systèmes collaborant entre eux, donc une "fédération de systèmes de composants métiers".
[BCF00] donne alors la définition d'un "composant distribué" :
"A component is a self-contained piece of software that can be independently deployed and plugged into an environment that provides a compatible socket.
It has well-defined and network addressable run-time interfaces and can cooperate out-of-the-box with other components".
L'aspect interface est ici précisé afin d'en faire une interface distribuée "network addressable run-time interfaces".
Jusque là, il peut s'agit d'un simple objet CORBA.
[BCF00] privilégie la granularité supérieure, au travers du composant métier, constitué de un ou plusieurs composant distribué, et défini comme :
"a software implementation of an autonomous business concept or business process. It consists of all the software artifacts necessary to represent, implement and deploy a given business concept as an autonomous reusable element of a larger distributed information system".
L'aspect "ensemble cohérent de fichiers" se retrouve dans le "all the software artifacts", ensemble capable d'évoluer au travers du cycle de développement, emmenant avec lui aussi bien du code, de la document et un ou des exécutables.
Interface distribué + ensemble cohérent de fichiers représentant, implémentant et déployant un concept métier défini... voilà le digne successeur de l'objet dans le cadre d'une "vraie" programmation orientée-composant.
Problème ? On n'a pas atteint encore ce niveau de granularité... on reste encore au niveau objet, donc au niveau des "simples" composants distribués à la mode CORBA...
Décollage ! | Présentation du site web "AILES" |
Infos générales | articles "Informatique"