Concept: Composant
Un composant est une partie encapsulée d'un système. Il s'agit idéalement d'une partie importante, presque indépendante et remplaçable, qui remplit une fonction précise dans le contexte d'une architecture clairement définie.
Relations
Description principale

Définition

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.

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.

Modélisation 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.

Instanciation de composant

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.x Représentation

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.