Représentation UML : Classe, stéréotypée comme une <<capsule>>. Remarquez que cette représentation est basée
sur une notation UML 1.5. Une grande partie de cette représentation peut aussi être représentée en UML 2.0 à l'aide du Concept : Classe structurée. Pour plus d'informations, consultez l'article Différences entre UML 1.x et UML 2.0 .
Une capsule est un élément composite, comme le montre la figure suivante.
Composition de la capsule
Une capsule peut avoir des ports et peut "contenir" des classes passives et/ou des sous-capsules. Elle peut aussi avoir
une machine d'état décrivant intégralement son comportement. Une taxinomie propre aux capsules ainsi que les différents
moyens de les utiliser sont traitées dans les Instructions :
Capsules.
Une capsule encapsule un fil de contrôle. Une capsule est un fil de contrôle indépendant dans le système ; c'est
l'unité primaire d'accès concurrent du système. On peut procéder à un isolement supplémentaire des fils de contrôle en
utilisant les processus et les unités d'exécution du système d'exploitation, c'est-à-dire en mappant les capsules à
certains processus et à certaines unités d'exécution du système d'exploitation. Les messages arrivent à la capsule par
un port et sont traités les uns après les autres. Si l'instance de la capsule est occupée, les messages sont placés
dans une file d'attente. Les capsules renforcent les sémantiques d'exécution de façon à ce que lorsqu'un événement est
reçu, il soit traité sans tenir compte du nombre de priorités ou d'autres événements arrivants.
Une capsule interagit avec son environnement grâce à des ports. Un port est un objet frontière à base de
signaux ; il gère les interactions de la capsule avec le monde extérieur. Un port implémente une interface
spécifique et peut aussi en dépendre. Une capsule ne peut pas avoir d'opérations de parties publiques autres que des
ports ; ces derniers sont les seuls moyens qu'elle a de communiquer avec le monde extérieur.
Chaque port joue un rôle particulier dans une collaboration. La collaboration décrit la façon dont la capsule
interagit avec les autres objets. Pour enregistrer les sémantiques complexes de ces interactions, les ports sont
associés à un protocole qui définit le flux d'informations valide (les signaux) entre les ports connectés des
capsules. Le protocole enregistre les obligations contractuelles existant entre les capsules. En obligeant les capsules
à ne communiquer qu'au travers des ports, il est possible d'entièrement découpler les implémentations internes de la
capsule à partir de l'environnement entourant la capsule. Cela rend la capsule très réutilisable.
Une fonctionnalité simple de la capsule est réalisée directement dans la machine d'état de la capsule. Les
capsules plus complexes associent la machine d'état à un réseau interne de sous-capsules collaborant et
jointes par des connecteurs. Ces sous-capsules sont des capsules à part entière pouvant elles aussi être décomposées en
sous-capsules. Ce type de décomposition peut être réalisée autant de fois que nécessaire, permettant la modélisation de
structures arbitrairement complexes à l'aide d'un ensemble basique de constructions de modélisation. La machine d'état
(qui est optionnelle pour les capsules composites), les sous-capsules et leur réseau de connexion font partie de
l'implémentation de la capsule et sont cachées vis-à-vis des observateurs externes.
Une capsule peut être un élément composite. Les capsules peuvent être composées d'autres capsules et de classes
passives. Les capsules et les classes passives sont reliées par des connecteurs ou par d'autres liens dans une
collaboration ; cette collaboration définit la "structure" de la capsule et est donc appelée "collaboration de
spécification". Une capsule peut avoir une machine d'état qui envoie et reçoit des signaux via les ports de sortie de
la capsule et qui contrôle certains éléments de la structure interne. On peut donc considérer que cette machine d'état
implémente une comportement réfléchissant, c'est-à-dire un comportement qui contrôle l'opération de la capsule
elle-même.
Les ports sont des objets dont le but est de jouer le rôle d'objets frontière pour l'instance d'une capsule. Ils
"appartiennent" à l'instance de la capsule dans le sens où ils sont créés et détruits en même temps que la capsule.
Chaque port à sa propre identité et son propre état qui diffèrent de l'identité et de l'état de l'instance de la
capsule à laquelle il appartient (de la même façon que chaque partie est distincte de son contenant).
Bien que les ports soient des objets frontière qui jouent le rôle d'interfaces, ils ne se mappent pas directement aux
interfaces UML. Une interface UML est un élément seulement comportemental, elle ne possède pas de structure
d'implémentation. Un port comporte lui une structure et un comportement. C'est une partie composite de la structure
d'une capsule et pas seulement une contrainte concernant son comportement. Il réalise un pattern d'architecture que
l'on peut appeler une "interface manifeste".
En langage UML, un port est modélisé comme une classe avec le stéréotype <<port>>. Comme nous
l'avons vu auparavant, le type de port est défini par le rôle de protocole joué par le port. Les rôles de protocole
sont des classes abstraites, la classe réelle correspondant à cette instance implémente le rôle de protocole
associé au port. En langage UML, la relation entre le port et le rôle de protocole est appelée une relation de
réalisation. La notation pour cet élément est une ligne tiretée avec une pointe de flèche triangulaire en trait
plein sur la fin de la spécification. C'est une forme de généralisation dans laquelle l'élément source, à savoir le
port, hérite seulement de la spécification du comportement de la cible, à savoir du rôle de protocole, mais pas de sa
structure.
Une capsule est une relation de composition avec ses ports. Si la multiplicité de la fin de la cible de cette relation
est supérieure à 1, cela signifie que plusieurs instances du port existent au moment de l'exécution, chacune
participant à une instance séparée du protocole. Si la multiplicité est un ensemble de valeurs, cela signifie que le
nombre de ports peut changer au moment de l'exécution et que des ports peuvent être créés et détruits de manière
dynamique (en entraînant parfois des contraintes).
Ports, protocoles et rôles de protocole.
La figure ci-dessus illustre un exemple de port unique appelé b et appartenant à la capsule CapsuleClassA. Ce port joue
le rôle le plus important du protocole défini par la classe de protocole ProtocolA. Remarquez que la vraie classe du
port, la ClassePortX, étant une classe d'implémentation pouvant varier d'une implémentation à l'autre, elle ne présente
pas d'intérêt pour le modélisateur jusqu'à l'étape d'implémentation. En revanche, l'information intéressante est
le rôle de protocole que ce port implémente. Pour cette raison, mais aussi pour faciliter la notation, la notation
utilisée dans la Figure 1 n'est normalement pas utilisée et remplacée par une forme plus compacte décrite dans la
section suivante.
Notation
Dans les diagrammes de classe, les ports d'une capsule sont énumérés dans un compartiment de liste spécifique comme le
montre le schéma. Le compartiment de liste des ports se trouve normalement après les compartiments des
listes de l'attribut et de l'opérateur. Cette notation tire partie de la fonction UML permettant l'ajout de
compartiments nommés spécifiques.
Notation de port - représentation de diagramme de classes
Tous les ports externes (les ports relais et les ports de sortie publics) ont une visibilité publique tandis que les
ports internes ont une visibilité protégée (comme le port b2). Le rôle de protocole (type) d'un port est normalement
identifié par un nom de chemin car les noms de rôles de protocole sont uniques seulement dans la portée d'un protocole
donné. Par exemple, le port b joue le rôle le plus important défini dans la classe de protocole appelé ProtocolA. Pour
les cas très fréquents de protocoles binaires, une convention de notation plus simple est utilisée : un tilde entre
guillemets ("~") est utilisé pour identifier le rôle du protocole conjugué (comme le port b2) et le nom du rôle de base
est implicite et ne comporte pas d'annotation particulière (comme le port b1). Pour les ports dont la multiplicité
n'est pas de 1, le facteur de multiplicité apparaît entre crochets. Par exemple, le port b1[3] a une multiplicité de 3
exactement, tandis qu'un port désigné par b5[0..2] a un nombre variable d'instances ne dépassant pas 2.
Un connecteur est un canal de communication fournissant les fonctions de transmission pour prendre en charge un
protocole à base de signaux spécifiques. Une des fonctions clés des connecteurs est qu'ils ne peuvent se connecter qu'à
des ports qui jouent des rôles complémentaires dans le protocole associé au connecteur. En principe, les rôles de
protocole ne doivent pas forcément appartenir au même protocole, mais ils doivent alors être compatibles avec le
protocole du connecteur.
Les connecteurs sont des vues abstraites de canaux de communication à base de signaux qui ont des connexions avec deux
ports ou plus. Les ports associés par une connexion doivent jouer des rôles complémentaires mais compatibles dans un
protocole. Dans les diagrammes de collaboration, ils sont représentés par des rôles d'association qui connectent les
ports appropriés. Si nous enlevons les ports de cette image, les connecteurs enregistrent réellement les relations de
communication clés entre les capsules. Ces relations sont importantes d'un point de vue architecturale car elles
identifient les capsules pouvant affecter d'autre capsules par le biais d'une communication directe. Les ports sont
inclus pour permettre l'encapsulation de capsules d'après les principes de dissimulation des informations et de
séparation des problèmes.
Les similitudes entre les connecteurs et les protocoles peuvent suggérer que ces deux concepts sont identiques.
Pourtant, ce n'est pas le cas car les protocoles sont des spécifications abstraites du comportement désiré, tandis que
les connecteurs sont des objets physiques dont la fonction est simplement de transmettre les signaux d'un port à
l'autre. De manière générale, les connecteurs eux-mêmes sont des conduits passifs. (En pratique, les connecteurs
physiques peuvent parfois provenir du comportement spécifié. Par exemple, à cause d'un incident interne, un connecteur
peut perdre, réorganiser ou dupliquer des messages. Ce type d'incident est courant dans les canaux de communication
répartis.)
Un connecteur est modélisé par une association existant entre deux ports ou plus des classes de la capsule
correspondante. (Pour les applications avancées dans lesquelles le connecteur a des propriétés physiques, une
classe d'association peut être utilisée car le connecteur est réellement un objet avec un état et une identité.
Comme avec les ports, la classe réelle utilisée pour réaliser un connecteur est une question d'implémentation.) La
relation avec l'outil pris en charge est implicite à travers les ports connectés. Les extensions UML ne sont donc pas
nécessaires pour représenter les connecteurs.
La structure interne complète d'une capsule est représentée par une collaboration de spécification. Cette
collaboration inclut une spécification de tous ses ports, ses connecteurs et ses sous-capsules. Tout comme les ports,
les sous-capsules et les connecteurs appartiennent à la capsule et ne peuvent pas exister indépendamment de la
capsule. Ils sont créés et détruits en même temps que la capsule.
Certaines sous-capsules de la structure peuvent ne pas être créées au même moment que la capsule qui les contient.
Elles sont parfois créées après, si nécessaire, par la machine d'état de la capsule. La machine d'état peut aussi
détruire ces capsules quand elle le souhaite. Tout cela est fait dans le respect des règles UML de composition.
La structure d'une capsule peut contenir ce que l'on appelle des rôles plug-in. Ces derniers sont, en effet, des
signets pour les sous-capsules remplies de manière dynamique. Cela est utile car on ne sait pas toujours
d'avance les objets spécifiques qui joueront ces rôles au moment de l'exécution. Une fois que ces informations sont
disponibles, l'instance de capsule appropriée (qui appartient à une autre capsule composite) peut être "pluggée" dans
ce type de connecteur et les connecteurs qui joignent ses ports aux autres capsules dans la collaboration sont
automatiquement établis. Lorsque la relation dynamique n'est plus nécessaire, la capsule est "retirée" de la fente du
plug-in et ses connecteurs sont supprimés.
Les sous-capsules et les plug-ins créés de manière dynamique permettent la modélisation des structures changeant de
manière dynamique, tout en s'assurant que les relations de communication et de confinement entre les capsules sont
explicitement spécifiées. C'est le moyen clé pour assurer l'intégrité architecturale dans un système en temps réel
complexe.
Les ports peuvent aussi être décrits dans des diagrammes de collaboration de spécification. Dans ces diagrammes, les
objets sont représentés par les rôles discriminants appropriés, à savoir les sous-capsules par des rôles de capsule
et les ports par des rôles de port. Pour réduire l'encombrement visuel, les rôles des ports sont généralement
indiqués par des icônes, sous forme de petits carrés noirs ou blancs. Les ports publics sont représentés par les icônes
des rôles de port qui traversent la frontière des rôles de la capsule correspondants, comme l'indique la figure
précédente. Cette notation abrégée leur permet d'être connectés à l'intérieur et à l'extérieur de la capsule sans
croisement de lignes inutiles et les identifie aussi clairement comme des objets frontière.
Notation de port - diagramme de collaboration de spécification
Remarquez que les intitulés sont des commentaires sur les rôles de port et ne doivent pas être confondus avec les noms
des fins d'association du connecteur. Les ports étant identifiés seulement par leur nom, il est possible, pour
simplifier les graphiques, de placer les rôles du port public autour du périmètre de la case de la sous-capsule, dans
n'importe quel ordre. Cela peut aider à réduire les liaisons entre les lignes de connexion.
Dans le cas des protocoles binaires, une icône stéréotypée supplémentaire peut être utilisée : le port jouant le rôle
conjugué est indiqué par un carré blanc (opposé au carré noir). Dans ce cas, le nom du protocole et le suffixe tildé
suffisent à identifier le rôle du protocole comme étant le rôle conjugué ; le nom de rôle du protocole est redondant et
doit être omis. De la même façon, l'utilisation d'un nom de protocole sur un carré noir indique le rôle de base du
protocole. Par exemple, si le rôle "principal" dans le protocole ProtQ est identifié comme étant la base, les
diagrammes dans la figure ci-dessus et ci-dessous sont alors équivalentes. Cette convention permet de voir facilement
lorsque les rôles de protocoles complémentaires sont connectés.
Conventions de notation pour les protocoles binaires
Les ports dont la multiplicité est supérieure à 1 peuvent aussi être représentés graphiquement à l'aide de la notation
standard multi-objet UML comme l'indique la figure suivante. Cela n'est pas obligatoire (la chaîne de multiplicité est
suffisante) mais souligne que le port peut avoir plusieurs instances.
Ports ayant une multiplicité supérieure à 1
La machine d'état associée à une capsule n'est qu'une autre partie de l'implémentation de la capsule. Cependant, elle a
des propriétés particulières qui la distinguent des autres composants de la capsule :
-
elle ne peut pas être décomposée en plusieurs sous-capsules. Elle indique le comportement directement. Toutefois,
les machines d'état peuvent être décomposées en hiérarchies de machines d'état plus simples à l'aide de fonctions
UML standard.
-
Il peut y avoir une machine d'état maximum par capsule (bien que les sous-capsules puissent avoir leur propre
machine d'état). Les capsules n'ayant pas de machine d'état sont de simples conteneurs pour les sous-capsules.
-
Elle gère les signaux arrivant sur les ports de sortie de la capsule et peut envoyer des signaux à travers ces
ports.
-
Seule l'entité peut accéder aux parties internes protégées de sa capsule. Cela signifie qu'elle joue le rôle de
contrôleur de toutes les autres sous-capsules. Elle peut donc créer et détruire ces sous-capsules
identifiées comme dynamiques et peut ajouter ou supprimer des sous-capsules externes selon les besoins.
Les sous-capsules créées de manière dynamique sont simplement indiquées par un facteur de multiplicité variable. Comme
les connecteurs du plug-in, ces sous-capsules peuvent aussi être spécifiées par un type d'interface pur. Cela signifie
qu'au moment de l'instanciation, toutes les classes d'implémentation prenant en charge cette interface peuvent être
instanciées. Cela assure le caractère général des spécifications structurelles.
Malgré ces restrictions supplémentaires, la machine d'état associée à une capsule est modélisée par le lien standard
entre un discriminant UML et une machine d'état. L'implémentation et la décomposition d'une capsule sont modélisées par
un élément de collaboration en langage UML standard pouvant être associé à un discriminant.
|