Le comportement externe d'un sous-système est principalement défini par les interfaces qu'il réalise. Lorsqu'un
sous-système réalise une interface, il s'engage à prendre en charge toutes les opérations définies par l'interface.
L'opération peut ensuite être réalisée par une opération sur un élément de conception (c'est-à-dire une classe ou un sous-système) contenu dans le sous-système ; cette opération peut
nécessiter une collaboration avec d'autres éléments de conception.
Les collaborations des éléments de modèle dans le sous-système doivent être documentées en utilisant des diagrammes de
séquence montrant comment le comportement du sous-système est réalisé. Chaque opération sur une interface réalisée par
le sous-système doit être documentée par un ou plusieurs diagrammes de séquence. Ce diagramme appartient au
sous-système et est utilisé pour concevoir le comportement interne du sous-système.
Si le comportement du sous-système dépend largement de l'état et représente un ou plusieurs fils de contrôle, les
automates à états sont généralement plus utiles pour décrire le comportement du sous-système. Dans ce contexte, les
machines d'état sont généralement utilisées conjointement avec des classes actives pour représenter une décomposition
des fils de contrôle du système (ou du sous-système en l'occurrence) ; elles sont décrites dans des diagrammes
d'état-transition, voir Instructions :
Diagramme d'état-transition. Dans les systèmes en temps réel, le comportement des Produit : Capsules sera également décrit au moyen de machines
d'état.A l'intérieur du sous-système, il peut exister des unités d'exécution
indépendantes, représentées par des classes actives.
Dans les systèmes en temps réel, des Produit :
Capsules seront utilisées pour encapsuler ces unités.
Exemple :
La collaboration des sous-systèmes pour accomplir un comportement requis du système peut être exprimée en utilisant des
diagrammes de séquence :
Ce diagramme montre comment les interfaces des sous-systèmes sont utilisées pour effectuer un scénario. En particulier,
pour le sous-système de Gestion du réseau, nous pouvons voir les interfaces spécifiques (ICoordinator dans ce cas) et
les fonctionnements que le sous-système doit prendre en charge. Nous voyons également que le sous-système Gestion du
réseau est dépendant des interfaces IBHandler et IAHandler.
En examinant le sous-système, nous voyons comment l'interface ICoordinator est réalisée :
La classe Coordinateur joue le rôle de "proxy" pour l'interface ICoordinator, en se chargeant des opérations
d'interface et en coordonnant le comportement de l'interface.
Ce diagramme de séquence "interne" montre ce que les classes apportent à l'interface, ce qui doit se produire de façon
interne pour apporter la fonctionnalité du sous-système et quelles classes envoient des messages à partir du
sous-système. Le diagramme clarifie la conception interne, et il est essentiel pour les sous-systèmes possédant des
conceptions internes complexes. Il permet aussi au comportement sous-système d'être facilement compris, ce qui peut
permettre de le réutiliser d'un contexte à l'autre.
Lors de la création de ces diagrammes de "réalisation d'interface", la création de nouvelles classes et de nouveaux
sous-systèmes peut s'avérer nécessaire pour effectuer le comportement requis. Le processus est similaire à celui qui
est défini dans l'analyse du cas d'utilisation, mais nous travaillons avec des opérations d'interface et non plus avec
des cas d'utilisation. Pour chaque opération d'interface, identifiez les classes (ou dans certains cas, lorsque le
comportement requis est complexe, un sous-système contenu) du sous-système actuel qui sont nécessaires pour effectuer
l'opération. Créez de nouvelles classes ou de nouveaux sous-systèmes lorsque les classes/ sous-systèmes existants ne
peuvent pas fournir le comportement requis (mais essayez tout d'abord de réutiliser ces éléments).
La création de nouveaux éléments de conception implique généralement de reconsidérer le contenu et les limites du
sous-système. Veillez à éviter d'avoir la même classe dans deux sous-systèmes différents. Si c'est le cas, cela
implique que les limites du système ne sont pas bien définies. Réexaminez de façon périodique la Tâche : Identification des éléments de conception pour rééquilibrer
les responsabilités du sous-système.
Il est parfois utile de créer deux modèles distincts internes du sous-système - une spécification destinée au client du
sous-système et une réalisation destinée aux implémenteurs. La spécification peut inclure des classes et des
collaborations "idéales" permettant de décrire le comportement du sous-système en terme de classes et de collaborations
idéales. La réalisation, par contre, correspond de façon plus étroite à l'implémentation et peut évoluer afin de
devenir l'implémentation. Pour plus d'informations sur la spécification et la réalisation du sous-système de
conception, voir les Instructions relatives au produit : Sous-système de conception, spécification et
réalisation du sous-système.
|