Rubriques

Définition Haut de la page

L'industrie et la documentation logicielles utilisent le terme "composant" pour faire référence à différentes choses. Il est souvent utilisé au sens large pour signifier "une partie constituante". Il est également fréquemment utilisé dans un sens plus étroit pour désigner des caractéristiques spécifiques qui permettent le remplacement et l'assemblage en systèmes plus grands.

Dans le processus RUP, le terme "composant" désigne une partie encapsulée d'un système, idéalement une partie complexe, remplaçable, presque indépendante, d'un système qui remplit une fonction claire dans le contexte d'une architecture bien définie. Cela inclut :

  • un composant de conception : une importante partie encapsulée de la conception et qui de ce fait inclut des sous-systèmes de conception et parfois d'importantes classes et packages de conception ;
  • un composant d'implémentation : une importante partie encapsulée de l'implémentation, généralement du code qui implémente un composant de conception.

Idéalement, la conception reflète l'implémentation. Il est donc possible de faire référence uniquement aux composants, chaque composant ayant une conception et une implémentation.

Le langage UML ([UML04]) définit un composant comme

une partie modulaire d'un système qui encapsule son contenu et dont la manifestation est remplaçable au sein de son environnement. Un composant définit son comportement en termes d'interfaces fournies et requises. Comme tel, un composant sert de type, dont la conformité est définie par les interfaces fournies et requises (englobant à la fois leur sémantique statique et leur sémantique dynamique).

Un composant est défini comme un sous-type de classe structurée, fourni pour un composant ayant des attributs et des opérations, capables de participer à des associations et des généralisations et ayant des ports et une structure interne. Pour plus de détails, voir Concepts : classe structurée.

Un certain nombre de stéréotypes UML standard existe qui s'applique à un composant, c'est-à-dire un <<sous-système>> pour modéliser des composants à large échelle et des <<spécifications>> et <<réalisations>> pour modéliser des composants avec des définitions de spécification et de réalisation distinctes dans lesquelles une spécification peut avoir plusieurs réalisations.

L'utilisation RUP du terme "composant" est plus large que la définition UML. Plutôt que de définir des composants comme ayant des caractéristiques, telles que la modularité, la capacité de déploiement et celle de remplacement, nous les recommandons comme caractéristiques souhaitables des composants. Voir la section suivante sur la capacité de remplacement des composants.

Capacité de remplacement des composantsHaut de la page

Dans la terminologie RUP et UML, des composants doivent être remplaçables. Cependant, cela peut signifier uniquement que le composant expose un ensemble d'interfaces qui masquent une implémentation sous-jacente.

Il existe d'autres sortes de capacités de remplacement plus fortes, listées ci-dessous.

Capacité de remplacement de fichier source

Si les deux classes sont implémentées dans un seul fichier de code source, dans ce cas chacune des classes ne peut généralement pas être versionnée et contrôlée séparément.

Cependant, si un ensemble de fichiers implémente totalement un seul composant et aucun autre, le composant est alors un fichier source remplaçable. Cette caractéristique permet au code source du composant d'être contrôlé au niveau de la version, identifié et réutilisé.

Capacité de remplacement par déploiement

Si deux classes sont déployées dans un seul exécutable, chaque classe n'est pas remplaçable de manière indépendante dans un système déployé.

Une caractéristique souhaitable des composants de granularité plus forte est d'être "remplaçable par déploiement", permettant à de nouvelles versions du composant d'être déployées sans devoir reconstituer les autres composants. Ceci signifie généralement qu'un fichier ou un ensemble de fichiers déploie le composant et aucun autre.

Capacité de remplacement pendant l'exécution

Si un composant peut être redéployé dans un système en cours d'exécution, il est référé en tant que composant "d'exécution remplaçable". Ceci permet au logiciel d'être mis à niveau sans perte de disponibilité.

Transparence d'emplacement

Des composants dotés d'interfaces adressables sur le réseau sont référés comme présentant une "transparence d'emplacement". Ceci permet aux composants d'être relocalisés sur d'autres serveurs, ou d'être répliqués sur plusieurs serveurs pour prendre en charge la tolérance aux pannes, l'équilibre de la charge, etc. Ces types de composants sont référés en tant que composants "distribués" ou "distribuables".

Modélisation des composantsHaut de la page

Le composant UML est une construction de modélisation qui offre les capacités suivantes :

  • regroupement des classes permettant de définir une partie de granularité plus forte d'un système ;
  • séparation des interfaces visibles de l'implémentation interne ;
  • instances pouvant s'exécuter dans un contexte d'exécution.

Un composant dispose d'un certain nombre d'interfaces fournies et requises qui constituent la base du câblage des composants entre eux. Une interface fournie est celle qui est implémentée directement par le composant ou par l'une des classes ou sous-composants de réalisation ou il s'agit du type d'un port du composant fourni. Une interface requise est celle conçue par une dépendance d'usage du composant ou de ses classes ou sous-composants de réalisation ou il s'agit du type de port requis.

Un composant dispose d'une vue externe (ou vue fonctionnelle) par le biais de ses propriétés et opérations publiquement visibles. Eventuellement, un comportement, tel que celui d'un automate à états de protocole, peut être lié à une interface, un port et au composant lui-même, pour définir plus précisément la vue externe en réalisant des contraintes dynamiques dans la séquence d'appels d'opérations explicites. Le câblage entre les composants d'un système ou d'un autre contexte peut être structurellement défini à l'aide de dépendances entre les interfaces de composant (généralement sur les diagrammes de composants).

En option, une spécification plus détaillée de la collaboration structurelle peut être réalisée à l'aide de pièces et de connecteurs en structures composites, pour spécifier le niveau de collaboration du rôle ou de l'instance entre composants. Il s'agit de la vue interne (ou vue structurelle) du composant, constituée par ses propriétés privées et les classes ou sous-composants de réalisation. Cette vue montre comment le composant externe est réalisé en interne. Le mappage entre la vue externe et la vue interne est réalisé au moyen de dépendances (sur des diagrammes de composants), ou des connecteurs de délégation aux parties internes (sur des diagrammes de structure composite).

RUP recommande l'utilisation des composants en tant que représentation des sous-systèmes de conception. Pour plus de détails, voir Artefact : sous-système de conception, Activité : conception de sous-système et Principes et conseils : sous-système de conception. De plus, voir les définitions dans Concepts : classe structurée.

Instanciation de composantsHaut de la page

Un composant peut ou ne peut pas être directement instancié lors de l'exécution.

Un composant indirectement instancié 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 de conception qu'une implémentation doit suivre. L'ensemble de classes, de sous-composants ou de parties de réalisation doit couvrir la totalité des opérations dans l'interface du composant fournie. La manière d'implémenter le composant relève de la responsabilité de l'implémenteur.

Un composant directement instancié spécifie sa propre implémentation encapsulée, il est instancié en tant qu'objet adressable. Cela signifie qu'un composant de conception présente une construction correspondante dans le langage d'implémentation, aussi peut-il être explicitement référencé.

Représentation UML 1.xHaut de la page

UML 1.5 définit un composant en tant que

partie modulaire, déployable et remplaçable d'un système qui encapsule l'implémentation et expose un ensemble d'interfaces. Un composant est généralement spécifié par un ou plusieurs classes ou sous-composants qui résident dessus et peut être implémenté par un ou plusieurs artefacts (c'est-à-dire, fichiers binaires, exécutables ou script).

Notez que dans UML 1.3 et les versions antérieures d'UML, la notation "composant" était utilisée pour représenter des fichiers de l'implémentation. Les fichiers ne sont plus considérés comme des "composants" dans les définitions UML récentes. Cependant, de nombreux outils et profils UML utilisent encore la notation composant pour représenter des fichiers. Pour plus de détails sur la représentation des fichiers dans UML, voir Principes et conseils : élément d'implémentation.

Du point de vue de la modélisation, les composants ont été comparés aux sous-systèmes UML dans UML 1.5, comme ils fournissent la modularité, l'encapsulation et des instances capables de s'exécuter lors de la phase d'exécution. RUP considère la construction de modélisation du composant UML 1.5 comme une autre notation permettant de représenter des sous-systèmes de conception. Pour plus de détails, voir Artefact : sous-système de conception et Principes et conseils : sous-système de conception.

Pour plus d'informations, voir Différences entre UML 1.x et UML 2.0.

RUP (Rational Unified Process)   2003.06.15