Activité :
|
Objet
|
|
Rôle : Concepteur | |
Fréquence : Une fois pour chaque sous-système de conception | |
Etapes | |
Artefacts d'entrée : | Artefacts de sortie : |
Guides d'utilisation de l'outil : | |
Plus d'informations : | |
Détails de l'enchaînement des activités : |
Objet | Définir le comportement interne du sous-système Identifier les nouvelles classes de conception ou les nouveaux sous-systèmes de conception nécessaires pour satisfaire les exigences comportementales du sous-système. |
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 automates à états sont généralement utilisés en conjonction avec des classes actives afin de représenter la décomposition des unités de contrôle du système (ou sous-système dans ce cas) et sont décrits dans des diagrammes d'état-transition, voir Principes et conseils : Diagrammes d'état-transition.
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.
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éalisations d'interface", la création de nouvelles classes et sous-systèmes peut s'avérer nécessaire afin d'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 Activité : Identifier les é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" pour 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 de sous-système de conception, voir Principes et conseils : Sous-système de conception, spécification du sous-système et réalisation du sous-système.
Objet | Documenter la structure interne du sous-système. |
Pour documenter la structure interne du sous-système, créez un ou plusieurs diagrammes montrant les éléments contenus par le sous-système, et comment ils sont associés les uns aux autres. Un diagramme de classe devrait suffire, mais plusieurs peuvent être utilisés pour réduire la complexité et améliorer la lisibilité.
Vous trouverez ci-dessous un exemple de diagramme de classe :
Exemple de diagramme de classe pour un système d'entrée de commande.
Modélisé en tant que composant, le contenu interne d'un sous-système peut être représenté de façon alternative dans le cadre du rectangle de composant d'un diagramme de composants. Cette représentation nous permet également d'inclure les points d'interaction de ce sous-système avec d'autres parties du système, ce qui est fait par le biais de ses interfaces.
Vous trouverez ci-dessous un exemple de diagramme de composants décrivant le sous-système Classement, son contenu interne, ainsi que ses interfaces fournies et requises.
Exemple de diagramme de composants pour le sous-système Classement
Dans la mesure où un composant est une classe structurée, il peut être étroitement encapsulé en forçant les communications extérieures à passer par des ports obéissant à des interfaces déclarées, ce qui apporte plus de précisions dans la spécification et l'interconnexion de ce composant. Cette représentation nous permet de "câbler" les instances des parties par des connecteurs pour qu'elles jouent un rôle spécifique dans l'implémentation de composant (voir Concepts :
Classe structurée pour plus d'informations).
Exemple de diagramme de structure composite pour le sous-système Classement
De plus, un diagramme d'état-transition peut s'avérer nécessaire pour documenter les états potentiels que le système peut adopter, voir Principes et conseils : Diagramme d'état-transition.La description des classes contenues dans le sous-système lui-même est traitée dans Activité : Conception de classe.
Objet | Documenter les interfaces dont dépend le sous-système. |
Lorsqu'un élément contenu dans un sous-système utilise un comportement d'un élément contenu dans un autre sous-système, une dépendance est créée entre les deux sous-systèmes. Pour améliorer la réutilisation et réduire les dépendances de maintenance, nous souhaitons exprimer ceci en termes de dépendance à une interface particulière du sous-système et non au sous-système lui-même ou à l'élément contenu dans le sous-système.
La raison de ce choix est double :
Lorsque vous créez des dépendances, assurez-vous qu'il n'y a pas de dépendances ou d'associations directes entre les éléments de modèles contenus dans le sous-système et les éléments de modèles contenus dans d'autres sous-systèmes. Assurez-vous également qu'il n'existe pas de dépendance circulaire entre les sous-systèmes et les interfaces ; un sous-système ne peut pas à la fois réaliser une interface et dépendre d'elle.
Les dépendances entre les sous-systèmes et entre les sous-systèmes et les packages peuvent être exprimées comme ci-dessous. Représentée ainsi, la dépendance montre qu'un sous-système (Gestion des factures, par exemple) dépend directement d'un autre sous-système (Gestion de la planification du paiement).
Exemple d'une organisation des sous-systèmes en couches en utilisant des dépendances directes
Lorsqu'il est possible de substituer un sous-système à un autre (lorsqu'ils ont les mêmes interfaces), la dépendance peut être reliée à une interface réalisée par le sous-système, plutôt qu'au sous-système lui-même. Cela permet d'utiliser tout autre élément de modèle (sous-système ou classe) réalisant la même interface. L'utilisation de dépendances d'interfaces permet de concevoir des cadres d'application flexibles en utilisant des éléments de conception remplaçables.
Exemple d'une organisation des sous-systèmes en couches en utilisant des dépendances directes.
Exemple d'une organisation des sous-systèmes en couches en utilisant des dépendances directes
Exemple d'une organisation des sous-systèmes en couches en utilisant des dépendances d'interface
Voir Différences entre UML 1.x et UML 2.0 pour plus d'informations .
RUP (Rational Unified Process)
|