Rubriques
Les ports se trouvent aux frontières de la capsule, ils sont donc visibles aussi bien à l'intérieur qu'à l'extérieur de
la capsule. Vus de l'extérieur, tous les ports présentent la même interface objet impénétrable et ne peuvent être
différenciés, si ce n'est par leur identité et le rôle qu'ils jouent dans le protocole. Cependant, vus de
l'intérieur,on peut voir que les ports peuvent être de deux sortes : des ports de relais et des ports de
sortie. Ils se différencient par leurs connexions internes : les ports de relais sont connectés à des sous-capsules
et les ports de sortie sont connectés à la machine d'état de la capsule. En général, les ports de relais servent à
exporter de manière sélective les "interfaces" de sous-capsules internes alors que les ports de sortie sont des objets
frontière pour la machine d'état de la capsule. Les ports de relais et les ports de sortie peuvent tous deux apparaître
aux frontières de la capsule et, comme nous l'avons dit plus haut, sont indistinguables de l'extérieur.
Les ports de relais sont des ports où tous les signaux transitent. Ils fournissent une "ouverture" dans
l'interpréteur de commandes d'encapsulation d'une capsule, qui peut être utilisée par ses sous-capsules pour
communiquer avec le monde extérieur sans y être véritablement exposées (et vice-versa). Un port de relais est connecté,
à l'aide d'un connecteur, à une sous-capsule et est aussi, normalement, connecté de l'extérieur à une capsule "paire".
Les ports de relais reçoivent des signaux de chaque côté et les transmettent de l'autre côté en gardant la direction du
flux des signaux. Cela se déroule sans retard ou perte d'information, à moins qu'il n'y ait pas de connecteur connecté
de l'autre côté. Dans ce cas, le signal est perdu.
Les ports de relais permettent la transmission directe (temps système zéro) des signaux envoyés par une capsule vers
une sous-capsule, sans demander l'intervention de la machine d'état de la capsule. Les ports de relais peuvent
seulement apparaître aux frontières d'une capsule et ont donc toujours une visibilité publique.
Pour être utile, une chaîne de connecteurs doit se terminer dans un port de sortie qui communique avec une machine
d'état. Les ports de sortie sont des objets frontière pour les machines d'état des capsules (même si, comme nous le
verrons, certains servent aussi d'objets frontière pour les capsules). Les ports de sortie sont les derniers émetteurs
et récepteurs de tous les signaux envoyés par les capsules. Ces signaux sont générés par la machine d'état des
capsules. Pour envoyer un signal, une machine d'état appelle une opération d'envoi ou d'appel sur un de ses ports de
sortie. Le signal est alors transmis par les connecteurs connectés, en passant par un ou plusieurs ports de relais et
par une chaîne de connecteurs, jusqu'à ce qu'il rencontre un autre port de sortie, habituellement dans une capsule
différente. Comme la communication basée sur des signaux peut être asynchrone, un port de sortie possède une file
d'attente pour conserver les messages reçus qui n'ont pas encore été traités par la machine d'état (cela fonctionne
comme une boîte de messagerie). La réception du signal et la distribution par la machine d'état qui le reçoit sont
effectués par la machine d'état d'après la sémantique du langage UML standard.
Comme les ports de relais, les ports de sortie peuvent apparaître aux frontières d'une capsule et donc avoir une
visibilité publique. Ces ports sont appelés ports de sortie publics. Ces ports sont les objets frontière de la
machine d'état et de la capsule qui les contient. Cependant, les ports de sortie peuvent aussi apparaître complètement
à l'intérieur de la capsule comme faisant partie de sa structure d'implémentation interne. Ces ports sont utilisés par
la machine d'état pour communiquer avec ses sous-capsules ou avec des couches de prise en charge de
l'implémentation externes. Ces ports de sortie internes sont appelés ports de sortie protégés car ils ont
une visibilité protégée.
Remarquez que le type de port est entièrement déterminé par sa connectivité interne et par sa visibilité à l'extérieur
de la capsule ; les différents termes (port de relais, port de sortie public, port de sortie privé) ne sont qu'une
terminologie sténographique. Un port public connecté à l'intérieur peut devenir soit un port de relais, soit un port de
sortie, selon la manière dont il sera connecté par la suite. Il peut aussi rester non connecté et être un récepteur
pour les signaux entrants.
D'un point de vue extérieur, un port est un port ; il n'est pas possible, ni même souhaitable, d'identifier s'il s'agit
d'un port de relais ou d'un port de sortie. Toutefois, lorsque la composition de la capsule est affichée, on peut voir
l'intérieur de la capsule et la distinction entre un port de relais et un port de sortie est indiquée graphiquement
comme ci-dessous.
Notation des ports - diagramme de communication (vue interne)
Il arrive fréquemment que deux ports ou plus de la même capsule utilisent le même protocole mais soient sémantiquement
distincts. Le même signal peut aussi apparaître dans plus d'un rôle de protocole pris en charge par différents ports de
la capsule. Dans les deux cas, il peut être nécessaire d'identifier le port de sortie spécifique recevant le signal en
cours. Cela permet aux applications de traiter le même signal de façon différente selon la source et l'état de ce
signal. Nous appelons ce genre de déclencheur un déclencheur basé sur des ports. Les déclencheurs basés sur des
ports sont modélisés en langage UML en utilisant des conditions de garde qui cherchent un port source spécifique.
La spécification de la partie machine d'état d'une capsule et la spécification de séquences de protocole correctes sont
faites avec des machines d'état UML standard.
Comme on peut s'y attendre, dans la plupart des systèmes en temps réel, le temps est une préoccupation de premier
ordre. En général, deux types de situations basées sur le temps doivent être modélisées : la possibilité de déclencher
une tâche à un moment de la journée précis et la possibilité de déclencher des tâches après qu'un certain
intervalle s'est écoulé.
La plupart des systèmes en temps réel exigent une fonction temps explicite et accessible de façon directe (contrôlable)
: un service de synchronisation. Ce service, auquel on accède par un port standard (point d'accès au service),
convertit le temps en événements qui peuvent être traités de la même façon que les autres événements basés sur des
signaux. Par exemple, grâce à ce type de service, une machine d'état peut demander à être informée par un événement
"délai d'attente" lorsqu'un moment précis de la journée a été atteint ou qu'un intervalle particulier s'est écoulé.
Les capsules, en tant que concept, peuvent être utilisées de plusieurs manières. Pour montrer cela, une hiérarchie et
une taxinomie des capsules peuvent être établies afin de décrire les utilisations habituelles des capsules.
Taxinomie de la capsule indiquant la hiérarchie de généralisation
La taxinomie de base de la capsule est :
-
Capsule
Une capsule de base, sans port, structure interne ni comportement n'est pas très intéressante -elle ne sert pas
à grand chose. Ce type de capsule pourrait être utilisé pour définir une capsule à partir de laquelle d'autres
capsules seraient créées. Comme les ports, la structure et le comportement ne sont pas définis, cette capsule
peut seulement servir à définir des paramètres qui seront détaillés par la suite.
-
Type de rôle
Une capsule "type de rôle" est une définition de capsule qui crée une capsule type avec un ou plusieurs ports ;
la structure et le comportement n'y sont pas définis. Ce type de capsule est utilisé lorsque les "interfaces"
(les ports) d'un ensemble de capsules doivent être définies avec les réalisations spécifiques des interfaces
définis par les sous-types de la capsule "type de rôle".
-
Modèle de rôle
Une capsule "modèle de rôle" est une définition de capsule avec une structure interne (définie par une
collaboration de spécification) de capsules imbriquées et potentiellement interconnectées et un ou plusieurs
ports. Ce type de capsule est utilisé pour définir un "modèle" pour la structure d'un système, les détails
étant délégués aux capsules contenues. Si la capsule modèle de rôle a des ports, ces ports définissent les
interfaces de la capsule.
Le comportement du modèle de rôle n'est pas défini (il n'y a pas de machine d'état définie) ; le comportement
doit être défini par les sous-types de la capsule.
-
Réalisation de rôle
Une capsule "réalisation de rôle" définit un comportement (via une machine d'état) pour la capsule, mais pas
pour sa structure interne, ni pour ses interfaces. Elle fournit essentiellement une définition abstraite de
comportement pour toutes les capsules qui en dérivent et qui doivent à leur tour définir leur propre structure
interne et leur propre interface. La définition de comportement peut être vue comme une "assertion
conceptuelle" qui doit être remplie par toutes les capsules dérivées de la capsule "réalisation de rôle".
Il existe trois hybrides utiles de ces types de base. Ils représentent un mélange des définitions de base :
-
Réalisation d'un type de rôle
Ce type de capsule définit l'interface et le comportement d'un ensemble de capsules, mais n'impose pas la
structure interne des capsules qui en dérivent. C'est principalement la capsule "réalisation de rôle" qui
définit une interface plus en détails.
-
Modèle de type de rôle
Ce type de capsule définit l'interface et la structure d'un ensemble de capsules, mais n'impose pas le
comportement de ces capsules. Cette capsule permet de définir un modèle d'interface et de structure qui peut
être ensuite spécifié par les capsules qui en dérivent.
-
Réalisation d'un modèle de rôle
Ce type de capsule définit la structure interne pour la capsule et son environnement, mais ne définit pas
l'interface. Ce type de capsule est utile lorsque plusieurs capsules partagent un certain nombre de structure
interne et de comportement, mais ont des interfaces différentes.
Le dernier type de capsule, la réalisation d'un modèle de rôle type, qui définit la structure, l'interface et le
comportement de manière générale (pour l'interface) et de façon plus détaillé (pour la structure interne) est complexe
et peut être dur à comprendre et à implémenter correctement. On le mentionne au cas où les tests d'unité sur la capsule
auraient besoin d'être définis comme faisant partie de la capsule elle-même, et donc des deux machines d'état séparées.
Dans la plupart des cas, cette construction peut être évitée.
Notez que la représentation actuelle RUP des capsules est basée sur la notation UML 1.5. Une grande partie peut être
représentée dans UML 2.0 en utilisant le Concept : Classe
structurée.
Voir aussi Les différences entre UML 1.x et UML 2.0 pour plus d'informations.
|