Produit: Capsule
Cet artefact est un pattern de conception particulier qui représente un fil de contrôle encapsulé dans le système.
Relations
Entrée versObligatoire:
  • Aucun
Facultatif: Externe:
  • Aucun
Description principale

Les capsules sont des patterns particuliers de structure et de composition de classe qui sont utiles pour la modélisation et la création de système ayant un haut niveau d'accès concurrent. Le fait d'utiliser une capsule comme une courte notation pour un pattern de conception spécifique rend la conception plus simple et moins prompte à l'erreur.

Une capsule est représentée comme une classe, stéréotypée <<capsule>>. Une capsule est un élément composite, comme le montre la figure suivante.

Diagramme décrit dans le texte d'accompagnement.

Composition de la capsule

Comme le montre le diagramme, une capsule peut avoir des ports et "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.

Propriétés
Facultatif
PlanifiéYes
Personnalisation
Options de représentationRepré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.

Diagramme d'élément composite

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.

Propriétés

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 

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).

Diagramme de capsule indiquant des ports

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.

Diagramme de classe pour les ports

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.

Les connecteurs

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 collaboration de spécification

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.

Diagramme de ports publics et de rôles de capsule

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.

Diagramme de rôle de protocole

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.

Diagramme en langage UML pour les objets multiples

Ports ayant une multiplicité supérieure à 1

La machine d'état

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. 

Plus d'informations
Listes de contrôle
Instructions