Dans le domaine des logiciels, le terme "composant" fait référence à beaucoup de choses différentes. Il est souvent
utilisé au sens large de "constituant". Il est aussi régulièrement utilisé dans un sens plus restreint pour définir des
caractéristiques spécifiques qui permettent d'effectuer des remplacements ou des assemblages dans des systèmes plus
larges.
Dans le RUP, on utilise le terme "composant" pour une partie encapsulée d'un système, idéalement une partie importante,
presque indépendante et remplaçable qui remplit une fonction précise dans le contexte d'une architecture clairement
définie. Cela inclut :
-
composant de conception - partie encapsulée significative du concept qui comprend les sous-systèmes de conception
et parfois même les packages significatifs de conception et de classes de conception.
-
composant d'implémentation - partie encapsulée significative de l'implémentation, généralement un code qui
implémente un composant de conception.
La conception reflète l'implémentation ce qui permet de se référer uniquement aux composants, chaque composant
comprenant une conception et une implémentation.
Le langage UML ([UML04]) donne
la définition suivante du terme "composant" :
Partie modulaire d'un système qui encapsule son contenu et qui est remplaçable dans son environnement. Un composant
définit son comportement en fonction des interfaces fournies et requises. Il est utilisé en tant que type dont la
conformité est définie par ces interfaces fournies et requises (englobant à la fois leur sémantique statique et
dynamique).
Un composant est défini comme un sous-type de classe structurée qui prévoit qu'un composant ait des attributs et des
opérations, puisse participer à des associations et des généralisations, et dispose d'une structure et de ports
internes. Voir Concept : Classe
structurée pour plus de détails.
Il existe un certains nombre de stéréotypes standard du langage UML qui s'appliquent à composant, par
exemple<<sous-système>>, pour modéliser des composants importants et <<spécification>> et
<<réalisation>>, pour modéliser des composants ayant des définitions de spécification et de réalisation
distinctes, où une spécification peut avoir plusieurs réalisations.
RUP fait un usage plus large du terme composant. Plutôt que de définir les composants comme étant modulaires,
déployables et remplaçables, nous préconisons pour ces caractéristiques la définition de caractéristiques souhaitables
des composants. Voir la section ci-dessous sur le Remplacement de composants.
Dans la terminologie RUP et UML, les composants doivent être remplaçables. Cependant, cela peut simplement vouloir dire
que le composant présente un ensemble d'interfaces qui masquent une implémentation sous-jacente.
Il existe d'autres types de remplacements plus frappants. Ils sont détaillés ci-dessous.
Remplacement dans le fichier source
Si deux classes sont implémentées dans un seul fichier code source, chaque classe ne peut généralement pas être
versionnée et contrôlée séparément.
Cependant, si un ensemble de fichiers implémente entièrement un seul et unique composant, ce dernier est alors
remplaçable dans le fichier source. Cette caractéristique permet à un code source de composant d'être commandé par une
version, référencé et réutilisé plus facilement.
Remplacement lors du déploiement
Si deux classes sont déployées dans un seul élément exécutable, chaque classe n'est pas remplaçable séparément dans un
système déployé.
Une caractéristique souhaitable pour les composants ayant un niveau de granularité plus élevé est d'être "remplaçable
lors du déploiement", permettant ainsi que les nouvelles versions du composant soient déployées sans qu'il faille
reconstruire les autres composants. Cela veut généralement dire qu'un fichier ou un ensemble de fichiers déploie le
composant et lui seul.
Remplacement dans la phase d'exécution
Si un composant peut être redéployé dans un système en cours d'exécution, on dit qu'il est "remplaçable dans la phase
d'exécution". Cela permet que le logiciel soit mis à jour sans perte de disponibilité.
Localisation transparente
On parle de "localisation transparente" pour les composants ayant des interfaces adressables sur le réseau. Cela permet
de translater les composants vers d'autres serveurs, de les dupliquer sur plusieurs serveurs, que les composants
supportent une tolérance aux fautes, un équilibrage de charge etc. On parle souvent de composants "distribués" ou
"distribuables" pour ce type de composants.
Un composant UML est un élément de modélisation possédant les capacités suivantes :
-
peut regrouper des classes pour définir une partie d'un système avec un niveau de granularité plus élevé
-
peut séparer les interfaces visibles de l'implémentation interne
-
peut avoir des instances qui s'exécutent lors de l'exécution
Un composant possède un nombre d'interfaces fournies et requises qui forment la base servant à câbler les composants
entre eux. Une interface fournie est soit implémentée directement par le composant ou par l'une de ses classes ou l'un
de ses sous-composants de réalisation, soit c'est un type de port fourni du composant. Une interface requise est soit
désignée par une dépendance d'utilisation du composant ou de l'une de ses classes ou de l'un de ses sous-composants de
réalisation, soit c'est un type de port requis.
Un composant comporte une vue externe (ou boîte noire) grâce à ses propriétés publiques visibles et ses opérations. Un
comportement tel qu'une machine d'état du protocole peut être rattaché à une interface, un port ou au composant
lui-même, pour définir la vue externe de manière plus précise en rendant explicites les contraintes dynamiques dans la
séquence d'appels d'opération. Le câblage entre composants dans un système ou dans un autre contexte peut se définir
structurellement à l'aide des dépendances entre les interfaces du composant (généralement sur les diagrammes du
composant).
Une spécification plus détaillée de la collaboration structurelle peut se faire à l'aide des parties et des connecteurs
dans les structures composites, pour spécifier le rôle ou le niveau d'instance de la collaboration entre les
composants. Il s'agit ici de la vue interne du composant (ou boîte blanche) obtenue par le biais de ses propriétés
privées et de ses classes ou sous-composants de réalisation. Cette vue interne montre comment le comportement externe
est réalisé en interne. Le mappage entre les vues externe et interne se fait par le biais des dépendances (sur les
diagrammes des composants) ou des connecteurs de délégation aux partie internes (sur les diagrammes de structure
composite).
RUP préconise d'utiliser les composants en tant que représentation des sous-systèmes de conception. Voir Produit : sous-système de conception, Tâche : sous-système de conception, et Instructions : sous-système de conception pour plus de détails. Voir aussi les
définitions dans Concept: Classe
structurée.
Un composant peut être ou ne pas être instancié directement lors de l'exécution.
Un composant instancié indirectement est implémenté ou réalisé par un ensemble de classes, de sous-composants ou de
parties. Le composant lui-même n'apparaît pas dans l'implémentation. Il sert en tant que conception que doit suivre une
implémentation. L'ensemble des classes de réalisation, des sous-composants ou des parties doit couvrir l'ensemble total
des opérations spécifiées dans l'interface fournie du composant. L'implémenteur est responsable de la manière dont le
composant sera implémenté.
Un composant implémenté directement spécifie sa propre implémentation encapsulée. Il est instancié en tant qu'objet
adressable, ce qui veut dire qu'il existe un élément correspondant au composant de conception dans le langage
d'implémentation, permettant ainsi de le référencer explicitement.
UML 1.5 a donné comme définition de "composant" :
Partie modulaire, déployable et remplaçable d'un système qui encapsule une implémentation et expose un jeu
d'interfaces. Un composant est généralement spécifié par une ou plusieurs classes ou sous-composants qui se
trouvent dans le composant et il peut être implémenté par un ou plusieurs artefacts (par exemple des fichiers
binaires, exécutables ou des fichiers de script)
Notez que dans UML 1.3 et dans les versions précédentes du langage UML, la notation "composant" faisait référence aux
fichiers dans l'implémentation. Ce n'est plus le cas dans les dernières définitions données. Néanmoins, beaucoup
d'outils et de profil UML utilisent encore cette notation. Voir Instructions : élément d'implémentation pour une description plus détaillée sur la
représentation des fichiers dans le langage UML.
Du point de vue de la modélisation, les composants ont été comparés aux sous-systèmes d'UML dans UML 1.5, car ils
fournissaient une modularité, une encapsulation et des instances capables de s'exécuter lors de l'exécution. RUP
considère l'élément de modélisation du composant dans UML 1.5 comme une notation alternative à sous-systèmes de
conception.. Voir Produit : sous-système de conception et Instructions : sous-système de conception pour plus de détails.
Voir Différences entre UML 1.x et UML 2.0 pour plus d'informations.
|