Concepts : Classe structurée
Rubriques
Définition
Selon UML ([UML04]), une classe est un sous-type à la fois d'un classificateur encapsulé et d'une classe métaclasse, ce qui veut dire qu'elle a une structure interne et des ports. Un composant est défini aussi par UML comme un sous-type d'une classe. Par conséquent, dans le contexte de RUP, nous faisons référence aux composants et aux classes comme étant des classes structurées.
Partie
Une instance d'une classe structurée est composée d'un objet ou d'un ensemble d'objets qui correspondent à chaque partie. Une instance est détruite lorsque la classe structurée à laquelle elle appartient est détruite.
L'exemple ci-dessous montre deux vues possibles de la classe voiture :
Dans la figure (a), Car est montrée avec une association de composition dont le nom de rôle est rear avec la classe Wheel et une association de composition dont le nom de rôle est e avec la classe Engine.
Toutes les instances de la classe Engine peuvent être associées à un nombre arbitraire d'instances de la classe Wheel.
Dans la figure (b), on peut voir la même chose. Toutefois, dans la figure (b), il est précisé que :
-
rear et e appartiennent à la structure interne de la classe Car. Cela permet de préciser des détails seulement valables pour les instances de Wheel et de Engine
dans le contexte de la classe Car, mais non valables pour toutes les classesWheel et Engine
en général.
-
dans le contexte de la classe Car, l'instance jouent le rôle de e peut être reliée seulement à deux instances avec le rôle de rear. De plus, les instances avec les rôles de e et de rear peuvent être liées seulement si elles sont les rôles de la même instance de la classe Car.
Autrement dit, il existe des contraintes supplémentaires pour les instances des classes Wheel et Engine, lorsqu'elles jouent leur rôle respectif à l'intérieur d'une instance de la classe Car. Ces contraintes ne sont pas applicables aux instances de Wheel et de Engine en général. Il se peut que d'autres instances Wheel et Engine soient arbitrairement liées, comme indiqué dans la figure (a).

Exemple : Parties qui jouent leur rôle dans une classe structurée
Connecteur
Un connecteur est une instance de la relation entre deux parties dans une classe structurée. Il s'agit d'un lien qui permet la communication. Les connecteurs peuvent être implémentés par des associations ordinaires ou par des relations transitoires, telles que des paramètres de procédure, des variables, des valeurs globales ou d'autres mécanismes.
Le "câblage" interne d'une classe structurée est formé par des connecteurs d'assemblage et des connecteurs de délégation :
- Dans l'implémentation d'une classe structurée, les connecteurs d'assemblage
sont reliés à des ports de parties différentes. Le message envoyé à un port d'une classe structurée est reçu sur un port connecté d'une autre classe structurée. Plusieurs parties peuvent être câblées entre elles à travers leurs ports. Une partie n'a pas besoin de savoir quoi que ce soit sur les autres parties, sauf qu'elles existent et qu'elles répondent aux contraintes sur les ports connectés. La communication entre les classes structurées est modélisée par leur ports.
- Un connecteur de délégation est relié à un port externe d'une classe structurée avec un port d'une de ses parties internes. Le message reçu par un port externe est transmis sur le port de la partie interne ; un message envoyé par le port interne est transmis au port externe qui le transmet aux classes structurées auxquelles il est relié.
Port
Un port est une caractéristique structurelle d'une classe structurée. L'encapsulation peut être augmentée en forçant les communications depuis l'extérieur des classes structurées à passer par des ports obéissant aux interfaces déclarées, ce qui donne une précision supplémentaire à la spécification et à l'interconnexion de cette classe structurée.
Les interfaces requises et fournies d'un port précisent tout ce qui est nécessaire pour des interactions par le biais de ce point d'interaction. Si toutes les interactions d'une classe structurée avec son environnement sont réalisées par les ports, les éléments internes de la classe structurée sont complètement isolés de l'environnement. Ceci permet qu'une telle classe structurée soit utilisée dans tout contexte qui répond aux contraintes indiquées par ses ports.
Il n'y a pas de supposition sur la façon d'implémenter un port. Il peut être implémenté en tant qu'objet explicite, ou tout simplement il peut être un simple concept virtuel qui n'apparaît pas explicitement dans l'implémentation.
Vous trouverez ci-dessous plusieurs exemples de ports :
Exemple 1

Port d'un moteur utilisé par une voiture et par un bateau
La figure ci-dessus montre la classe Engine avec un port p
et deux interfaces :
- Une interface fournie, powertrain, qui spécifie les services que Engine offre à ce port (par exemple, les opérations et les réceptions accessibles par les communications arrivant à ce port).
- Une interface requise, power, qui spécifie les services que Engine attend de l'environnement.
Dans le port p, la classe Engine est complètement encapsulée; elle peut être spécifiée sans aucune connaissance sur l'environnement dans lequel le moteur sera installé. Au fur et à mesure que l'environnement obéit aux contraintes imposées par les interfaces fournies et requises du moteur, celui-ci fonctionnera correctement.
Pour illustrer cela, deux utilisations de la classe Engine sont représentées dans l'exemple ci-dessous :
- La classe Car connecte le port p du moteur à un ensemble (Wheel) de roues au moyen d'un essieu axle.
- La classe Boat connecte le port p du moteur à une hélice (Propeller) au moyen d'un arbre shaft.
Tant que l'interaction entre Engine et la partie reliée à son port p obéit aux contraintes spécifiées par les interfaces fournies et requises, le moteur fonctionnera comme prévu, que ce soit le moteur d'une voiture ou le moteur d'un bateau.
De plus, même si Engine a d'autres ports déclarés, comme le port f pour consommation de carburant, les roues d'une voiture et l'hélice d'un bateau accéderont toujours au moteurEngine par le port p. Le port f serait intéressant dans le cas d'un compteur de carburant, quelque soit la sorte de carburant utilisé ou la sorte de compteur de carburant que possèdent les voitures ou les bateaux.
Exemple 2
Cet exemple de ports est basé sur Java Logging API ([JAV03]), package qui fournit les classes et les interfaces des fonctionnalités de connexion de base de la plate-forme de Java 2, parmi lesquelles :
L'enregistreur automatique Logger, qui est le dispositif principal auquel les applications font des appels d'enregistrement. Il est utilisé afin d'enregistrer des messages concernant un système spécifique ou un composant d'une application.
Le niveau Level, qui donne une indication sur l'importance et l'urgence du message enregistré
Le filtre Filter, qui effectue un contrôle fin des messages enregistrés, plus poussé que le contrôle des niveaux d'enregistrement
Le gestionnaire Handler, qui prend les messages de l'enregistreur automatique et les exporte vers des destinations différentes (une mémoire, des flots de données de sortie, des consoles, des fichiers et des interfaces de connexion)
Le programme de mise en forme Formatter, qui fournit un support afin de mettre en forme les enregistrements chronologiques
Ces classes et interfaces sont concernées par deux sortes de collaborations. Certaines classes et interfaces sont utilisées pour écrire dans le journal tandis que d'autres servent à le gérer. La figure ci-dessous montre deux collaborations différentes que les clients et les administrateurs ont avec le journal, modélisées en tant que collaborations UML :
Collaboration d'écriture (Writing), où le rôle LogClient
se connecte au rôle LogWriter afin d'écrire dans le journal.
Collaboration d'Administration (Administration), où le rôle LogAdministrator
se connecte au rôle LogController afin d'accéder au journal et d'en changer les paramètres.

Différentes collaborations que les clients et administrateurs peuvent avoir avec le journal
Une représentation UML 2.0 possible pour la modélisation des services d'enregistrement et ses collaborations serait l'utilisation d'un composant avec des ports et des interfaces déclarées, comme on peut le voir sur l'illustration ci-dessous :

Le package Java Logging API implémenté en tant que composant avec des interfaces fournies regroupées dans des ports
Dans la spécification de Java Logging API, certains des services d'enregistrement ont été implémentés en tant que classes et d'autres en tant qu'interfaces. Dans cet exemple, nous avons modélisé chacun de ces services comme des interfaces fournies et qui pourraient être réalisées par des parties à l'intérieur du composant. Les deux sortes de comportement liées aux collaborations pour l'écriture et l'administration dont nous avons parlé ci-dessus pourraient être représentées par des interfaces regroupées de façon logique en ports. Nous avons donc :
Les interfaces Logger et Level regroupées dans le port LogWriter. Ces interfaces sont accessibles aux clients du journal afin d'écrire dans le journal.
Les interfaces Handler, Filter et Formatter regroupées dans le port LogController. Les administrateurs de journal accèdent à ces interfaces afin de changer les paramètres du journal.
Cette alternative de modélisation conduit à une séparation des préoccupations et regroupe les interfaces de façon logique dans des ports différents. Vous pouvez nous consulter pour d'autres précisions sur la spécification des composants et l'interconnexion avec le monde extérieur.
Modélisation
Pendant la conception, les classes et composants peuvent être décomposés en séries de parties connectées qui peuvent à leur tour être décomposées.
Un diagramme de structure composite peut servir à montrer comment une classe structurée est décomposée. La figure ci-dessous est un exemple de diagramme de structure composite pour le bureau de location dans un système de vente de billets. Cette classe se décompose en trois parties :
- Une interface vente de billets
- Un guide des performances qui recherche les performances en fonction de la date et d'autres critères
- Un ensemble de bases de données qui contiennent les informations sur des performances et des billets.
Chaque partie interagit par le biais d'une interface bien définie et déterminée par ses ports.
Le bureau entier interagit avec l'extérieur à travers un port. Les messages de ce port sont envoyés à la classe vendreBillets, mais la classe bureau de location est cachée pour les clients.

Exemple : Diagramme de structure composite pour un système de billets.
Représentation UML 1.x
Notez que la classe structurée est un nouveau concept dans UML 2.0.
Si votre outil ne prend en charge qu'UML 1.5, allez à Artefact : Capsule et dans Principes et conseils :
Capsule pour une représentation alternative.
Pour de plus amples informations, voir Différences entre UML 1.x et UML 2.0.
|