Principes et conseils :
|
|
Détails |
---|---|
Evaluez le caractère optionnel | Si une collaboration (ou sous-collaboration) particulière représente un comportement facultatif, vous devrez l'intégrer au sous-système. Les fonctions susceptibles d'être supprimées, mises à niveau ou remplacées doivent être considérées comme indépendantes. |
Observez l'interface utilisateur du système. | Si l'interface utilisateur est relativement indépendante des classes d'entité du système (c'est-à-dire si les deux peuvent changer et changent indépendamment), vous devez créer des sous-systèmes intégrés horizontalement : les classes frontières de l'interface utilisateur liées au groupe, réunies dans un sous-système et les classes d'entité liées au groupe, regroupées dans un autre sous-système. |
Si l'interface utilisateur et les classes d'entité qu'elle affiche sont étroitement couplées (c'est-à-dire qu'une modification de l'une déclenche la modification de l'autre), vous devez créer des sous-systèmes intégrés verticalement : intégrer les classes frontières et classes d'entité apparentées dans un système commun. | |
Observez les acteurs | Séparez la fonctionnalité utilisée par deux acteurs différents, puisque chaque acteur est susceptible de modifier indépendamment ses exigences par rapport au système. |
Créez des sous-systèmes pour encapsuler l'accès au système ou au dispositif externe. | |
Observez le couplage et la cohésion entre les éléments de conception | Les classes/sous-systèmes présentant un haut niveau de couplage ou de cohésion collaborent pour fournir un ensemble de services. Organisez-les en sous-systèmes, et séparez les éléments sur les lignes de faible couplage. Dans certains cas, un faible couplage peut être intégralement éliminé, en subdivisant les classes en plus petites classes ayant des responsabilités plus cohésives, ou en repartitionnant les sous-systèmes de manière appropriée. |
Observez la substitution | S'il existe plusieurs niveaux de services spécifiques correspondant à une capacité particulière (par exemple : disponibilité de haut, moyen ou bas niveau), vous devez représenter chaque niveau de service comme un sous-système séparé, dont chacun réalisera le même ensemble d'interfaces. En faisant cela, les sous-systèmes pourront être substitués les uns aux autres. |
Observez la répartition | Bien qu'il puisse exister de multiples instances pour un système particulier, chacune s'exécutant sur des noeuds différents, il n'est pas possible dans de nombreuses architectures, de subdiviser une seule instance sur différents noeuds. Dans le cas où le comportement d'un sous-système doit être subdivisé sur différents noeuds, nous vous recommandons de décomposer le sous-système en sous-systèmes plus petits (chacun représentant un seul composant), avec des fonctionnalités plus restreintes. Définissez la fonctionnalité qui devra résider sur chaque noeud et créez un nouveau sous-système qui sera'propriétaire' de cette fonctionnalité, en répartissant convenablement les responsabilités et éléments apparentés du sous-système d'origine. Les nouveaux sous-systèmes sont internes au sous-système d'origine. |
Une fois que la conception a été organisée en sous-systèmes, vous devez mettre à jour les réalisations de cas d'utilisation en conséquence.
Les sous-systèmes de conception sont modélisés en utilisant les composants du langage UML. Cette construction offre les capacités de modélisation suivantes :
Les considérations suivantes doivent aussi être prises en compte :
Remarque : UML 2.0 définit également un stéréotype pour le composant appelé <<sous-système>>, indiquant que l'on peut l'utiliser, par exemple, pour représenter des structures à grande échelle. Un sous-système de conception RUP peut ou non être une structure à grande échelle ; les deux sont des sous-systèmes de conception du point de vue du RUP. C'est à l'architecte logiciel de décider, par exemple s'il choisit de référencer les composants qui sont eux-mêmes constitués de composants comme <<sous-systèmes>>.
Si un produit existant est un produit qui exporte des interfaces, c'est-à-dire des opérations (et peut-être les réceptions), mais qui sinon, maintient masqués tous les détails de l'implémentation ; il peut être modélisé comme un sous-système de la vue logique. Les exemples des produits utilisés par le système que vous pouvez représenter par un sous-système incluent :
Certains produits existants, comme les collections de types et de structures de données (par exemple, les piles, les listes et les files d'attente) sont mieux représentés comme packages, car ils révèlent beaucoup plus que le comportement. C'est le contenu particulier du package et non le package proprement dit qui est simplement un conteneur, qui est important et utile.
Les fonctionnalités communes, telles que les bibliothèques mathématiques, peuvent être représentées comme des sous-systèmes, si elles exportent des interfaces. Le caractère nécessaire de cette opération ou son aspect logique dépendent du jugement du concepteur, concernant la nature de l'élément à modéliser. Les sous-systèmes sont des constructions orientées objet (puisque ce sont des composants modélisés) : un sous-système peut comporter des instances (si cela est mentionné par le concepteur). Le langage UML offre une autre manière de modéliser les groupes de variables et de procédures dans l'utilitaire, qui est un stéréotype de la classe. L'utilitaire ne comporte aucune instance.
Lorsque vous définissez le sous-système pour représenter le produit, vous devez également définir une ou plusieurs interfaces pour représenter les interfaces produit.
Les sous-systèmes de conception (modélisés comme des composants UML) diffèrent des packages en termes de sémantique : un sous-système fournit un comportement par l'intermédiaire d'une ou plusieurs interfaces. Les packages ne fournissent aucun comportement ; ce sont simplement les conteneurs des éléments qui fournissent le comportement.
La raison d'utiliser un sous-système à la place d'un package est que les sous-systèmes encapsulent leur contenu, et ne fournissent un comportement que par l'intermédiaire de leurs interfaces. L'avantage de cette opération est que, contrairement au package, le contenu et les comportements internes d'un sous-système peuvent être modifiés en toute liberté, tant que les interfaces du sous-système restent constantes. Les sous-systèmes fournissent également un élément de "conception remplaçable" : deux composants de <<réalisation>> quels qu'ils soient génèrant la même interface (ou composant de <<spécification>>) sont interchangeables.
Pour s'assurer que les sous-systèmes sont des éléments remplaçables du modèle, il faut appliquer quelques règles :
Nous vous donnons ci-dessous un exemple des dépendances d'un sous-système et d'un package :
Dépendances des sous-systèmes et des packages dans le modèle de conception
Le langage UML ([UML04]) indique :
Il existe certains stéréotypes standard UML qui s'appliquent à un composant ; la <<spécification>> et la <<réalisation>> peuvent être utilisées par exemple pour modéliser les composants, en utilisant pour la spécification et la réalisation, des définitions distinctes dans lesquelles une spécification peut comporter de multiples réalisations.
Un composant dont le stéréotype est <<spécification>> indique un domaine d'objets sans définir l'implémentation physique de ces objets. Il comportera uniquement les interfaces fournies et requises, et il n'est pas destiné à comporter des classes de réalisation et des sous-composants, comme partie de sa définition.
Un composant dont le stéréotype est <<réalisation>> indique un domaine d'objets et définit également l'implémentation physique de ces objets. Par exemple, un composant dont le stéréotype est <<réalisation>> ne comportera que des classes de réalisation et des sous-composants qui implémenteront le comportement indiqué par le composant séparé <<spécification>>.
La séparation de la spécification et de la réalisation permet essentiellement deux descriptions séparées du sous-système. La spécification sert de contrat qui définit tous les éléments nécessaires à un client pour savoir comment utiliser le sous-système. La réalisation est la conception interne détaillée, utilisée pour guider l'implémenteur. Si vous désirez supporter plusieurs réalisations, vous devez créer des sous-systèmes de "réalisation" séparés et établir une réalisation de chaque sous-système de réalisation vers le sous-système de spécification.
Si l'état et le comportement internes du système sont relativement simples, il peut s'avérer suffisant de spécifier le sous-système par ses interfaces exposées et de représenter les diagrammes décrivant le comportement et le texte de description.
Concernant les états et comportements internes plus complexes, vous pouvez utiliser les classes d'analyse pour spécifier le sous-système, de manière extrêmement abstraite. Pour les grands systèmes, la spécification d'un sous-système peut également comporter des cas d'utilisation. Voir Développer des systèmes à grande échelle avec le processus RUP.
La création d'une spécification détaillée et séparée de la réalisation peut être très utile dans les situations suivantes :
La maintenance d'une spécification séparée demande beaucoup d'efforts, car on doit s'assurer que la réalisation du sous-système est conforme à la spécification.
L'Artefact:
Principes et conseils spécifiques au projet définit les critères déterminant quand et s'il est opportun de créer une spécification séparée, des classes de réalisation et des collaborations.
Une spécification doit définir ses dépendances. Ce sont les interfaces et les éléments visibles des autres sous-systèmes et packages qui doivent être disponibles dans toutes les réalisations conformes du sous-système.
Une réalisation peut comporter des dépendances supplémentaires, introduites par le concepteur ou par l'implémenteur. Par exemple, il peut exister une opportunité d'utiliser un composant utilitaire pour simplifier l'implémentation, mais l'utilisation de ce composant utilitaire est un détail qu'il n'est pas nécessaire d'exposer aux clients. Ces dépendances supplémentaires doivent être enregistrées dans un diagramme séparé, comme une partie de la réalisation.
Une spécification totalement détaillée définit tous les éléments requis par un client pour utiliser le sous-système. Cela implique d'affiner les interfaces exposées et tout élément publiquement visible, de manière à les traiter un à un avec le code. Les classes d'analyse introduites pour indiquer le comportement du sous-système doivent rester des abstractions de haut niveau, puisqu'elles sont destinées à être indépendantes des réalisations des sous-systèmes.
Les éléments de réalisation d'un sous-système doivent s'aligner étroitement sur le code.
Voir Concepts : Correspondance entre la conception et le code pour des arguments supplémentaires à ce sujet.
Les sous-systèmes de conception peuvent être modélisés comme des composants UML 2.0 ou comme des sous-systèmes UML 1.5. Ces constructions offrent des capacités presque équivalentes, comme la modularité, l'encapsulation et les instances capables de fonctionner dans un contexte d'exécution.
Les options de modélisation intègrent les considérations supplémentaires suivantes :
Ces notations peuvent cependant être utilisées de manière interchangeable. La décision de représenter les sous-systèmes de conception comme des sous-systèmes UML 1.5 ou comme des composants UML 2.0 doit être documentée dans les Principes et conseils spécifiques au projet adaptés à votre processus/projet.
Si votre outil de modélisation supporte les packages UML 1.5 et pas les sous-systèmes UML 1.5, il est possible d'utiliser un package dont le stéréotype est <<sous-système>> pour dénoter le sous-système.
Les mêmes restrictions de dépendance et discussions mentionnées dans le chapitre intitulé Restrictions de dépendance des sous-systèmes s'appliquent aussi aux sous-systèmes de conception qui sont modélisés comme des sous-systèmes UML 1.5.
Un exemple de dépendance des sous-systèmes et packages dans UML 1.5 est illustré ci-dessous :
Dépendances des sous-systèmes et des packages dans le modèle de conception
Le contenu d'un sous-système est divisé en deux sous-ensembles : 1) éléments de
spécification et 2) éléments de réalisation. Les éléments de spécification, ainsi que les
opérations et réceptions du sous-système, sont utilisés pour donner une spécification abstraite
du comportement offert par les éléments de réalisation. La collection d'éléments de réalisation
modélise l'intérieur de l'unité de comportement du système physique.
La séparation de la spécification et de la réalisation permet d'avoir deux descriptions séparées du sous-système. La spécification sert de contrat pour définir tout ce qu'un client doit savoir pour utiliser le sous-système. La réalisation est la conception interne détaillée, utilisée pour guider l'implémenteur.
Une option de modélisation des spécifications et des réalisations, si elle n'est pas directement supportée par l'environnement de modélisation, consiste à placer deux packages, la spécification et la réalisation, à l'intérieur de chaque sous-système.
Un des buts des spécifications est de prendre en charge plusieurs réalisations. Cela n'était pas directement pris en charge dans UML 1.x. Si vous souhaitez prendre en charge plusieurs réalisations, en utilisant les sous-systèmes UML 1.5, vous devez créer des sous-systèmes de "réalisation" séparés, et concevoir une réalisation de chaque sous-système de réalisation vers le sous-système de spécification.
Fondamentalement, les mêmes considérations liées à la spécification et à la réalisation, qui s'appliquent au langage UML 2.0, s'appliquent également ici (voir Quand et comment utiliser, Dépendances, et Relation à l'implémentation pour plus de détails).
Voir Différences entre UML
1.x et UML 2.0 pour de plus amples informations.
RUP (Rational Unified Process)
|