Concepts : Composant
Rubriques
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.
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".
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.
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é.
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.
|