Rubriques

Utilisation des sous-systèmes Haut de la page

Les sous-systèmes peuvent être utilisés de plusieurs manières complémentaires, pour partitionner le système en unités qui

  • peuvent être commandées, configurées ou livrées indépendamment
  • peuvent être développées indépendamment, tant que les interfaces restent inchangées
  • peuvent être déployées indépendamment, sur un ensemble de noeuds informatiques répartis
  • peuvent être modifiées indépendamment, sans altérer d'autres parties des systèmes

Ainsi, les sous-systèmes conviennent parfaitement à la modélisation des composants (les unités remplaçables du développement à base de composants) qui sont plus grands qu'une seule classe de conception.

De plus, les sous-systèmes peuvent

  • partitionner le système en unités offrant une sécurité restreinte sur les ressources clés
  • représenter les produits ou systèmes externes dans la conception.

Identification des sous-systèmes Haut de la page

Une classe d'analyse complexe est mappée à un sous-système de conception, si elle semble incarner un comportement qui n'est pas de la responsabilité d'une classe de conception agissant seule. Une classe de conception complexe peut également devenir un sous-système, si elle est susceptible d'être implémentée comme un ensemble de classes agissant en collaboration.

Les sous-systèmes sont aussi un bon moyen d'identifier les parties du système qui sont développées indépendamment par une équipe séparée. Si les éléments de conception travaillant en collaboration, peuvent être complètement contenus dans un package, avec leurs collaborations, le sous-système peut garantir une forme d'encapsulation plus forte que celle fournie par un simple package. Le contenu et les collaborations du sous-système sont complètement isolés derrière une ou plusieurs interfaces, de manière que le client du sous-système soit dépendant uniquement de l'interface. Le concepteur du sous-système est alors complètement isolé des dépendances externes ; le concepteur (ou l'équipe de conception) doit préciser la manière dont l'interface est réalisée, mais il est totalement libre de modifier la conception du sous-système, sans qu'il n'y ait aucune répercussion sur les dépendances externes. Dans les grands systèmes pourvus d'équipes de conception très indépendantes, ce niveau de découplage associé à l'application des règles architecturales provenant des interfaces formelles est un argument fort dans le choix des sous-systèmes par rapport aux simples packages.

Le sous-système de conception est utilisé pour encapsuler ces collaborations, de telle manière que les clients du sous-système peuvent ignorer la conception interne du sous-système, même lorsqu'ils utilisent ses services. Si les classes/sous-systèmes participant à la collaboration interagissent uniquement les uns avec les autres pour produire un ensemble bien défini de résultats, la collaboration et ses éléments de conception doivent être encapsulés dans le sous-système.

Cette règle s'applique aussi aux sous-ensembles de collaborations. Une collaboration peut être encapsulée ou simplifiée en totalité ou en partie, ce qui facilite la compréhension de la conception.

Conseils

Conseil

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.

Modélisation des sous-systèmes Haut de la  page

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 :

  • utilisation de classes de groupe pour définir une plus grande granularité du système
  • séparation des interfaces visibles de l'implémentation interne
  • instances d'exécution

Les considérations suivantes doivent aussi être prises en compte :

  • Vous devez attribuer à chaque sous-système de conception un nom et une brève description.
  • Les responsabilités de la classe d'analyse d'origine doivent être transférées vers le sous-système nouvellement créé, en utilisant la description du sous-système pour documenter les responsabilités.

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>>.

Sous-systèmes représentant des produits existants Haut de la  page

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 :

  • Le logiciel de communication (middleware).
  • Le support d'accès à la base de données (support SGBDR).
  • Les produits spécifiques aux applications.

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.

Restrictions de dépendance des sous-systèmes Haut de la  page

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 :

  • Un sous-système doit minimiser l'exposition de son contenu. Idéalement, aucun élément contenu dans le sous-système ne doit avoir la visibilité "publique" ; ainsi, aucun élément extérieur au sous-système ne dépend de l'existence d'un élément particulier du sous-système. Il existe néanmoins les exceptions suivantes :
    • Dans certaines technologies, les éléments externes au sous-système ne peuvent pas être modélisés comme une interface UML. Par exemple, une interface Java est modélisée comme une classe stéréotypée.
    • La conception d'un sous-système peut nécessiter l'exposition des classes, plutôt que l'exposition des interfaces UML. Par exemple, une classe "déléguée" ou une classe "d'accès" peut être utilisée pour masquer une collaboration complexe d'autres classes. Même si un package ordinaire pourrait être utilisé, un sous-système peut être utilisé pour souligner l'intention d'encapsuler le comportement et de masquer les détails internes.

  • Lorsque les éléments externes du sous-système ne sont pas des interfaces UML, il est souvent utile d'avoir un diagramme (appelé par exemple "Vue externe") qui illustre les éléments visibles du sous-système.
  • Un sous-système doit définir ses dépendances sur les interfaces du sous-système (et les éléments du sous-système publiquement visibles dans les cas de figure décrits ci-dessus). De plus, certains sous-systèmes peuvent partager un ensemble d'interfaces ou de définitions de classes communes ; dans ce cas, ces sous-systèmes "importent" le contenu des packages comportant les éléments communs. Cela se produit plus couramment avec les packages des couches inférieures de l'architecture, pour s'assurer que les définitions communes de classes qui doivent passer entre les sous-systèmes sont définies de manière cohérente.

Nous vous donnons ci-dessous un exemple des dépendances d'un sous-système et d'un package :

Diagramme décrit dans le texte d'accompagnement.

Dépendances des sous-systèmes et des packages dans le modèle de conception

Spécification et réalisation du sous-systèmeHaut de la  page

DéfinitionHaut de la page

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.

Quand et comment les utiliserHaut de la  page

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 :

  • l'état ou le comportement interne de la réalisation du sous-système est complexe, et la spécification doit être exprimée aussi simplement que possible, de manière à permettre aux clients de l'utiliser de façon efficace ;
  • le sous-système est un "composant" ré-utilisable, destiné à plusieurs systèmes (voir Concepts : Composant) ;
  • les éléments internes du système doivent être développés par une organisation séparée ;
  • de multiples implémentations du sous-système doivent être créées ;
  • le sous-système doit être remplacé par une autre version qui générera des changements internes significatifs, sans modifier le comportement externe visible.

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'../artifact/ar_projspecgls.htm -- This hyperlink in not present in this generated websiteArtefact: 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.

DépendancesHaut de la  page

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.

Relation à l'implémentationHaut de la  page

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.

Représentation UML 1.x Haut de la page

Modélisation

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 :

  • Les sous-systèmes UML 1.5 incluaient explicitement la notion de "spécification" et de "réalisation" (définie ci-dessus dans la section intitulée Spécification et réalisation du sous-système). Les composants UML 2.0 supportent la notion de spécification (sous la forme d'une ou plusieurs interfaces fournies ou requises) et de réalisation (implémentation interne comportant une ou plusieurs classes et sous-composants réalisant son comportement).
  • Les sous-systèmes UML 1.5 étaient également des packages. Les composants UML 2.0 offrent des capacités de regroupement, ce qui signifie qu'ils peuvent posséder et importer un ensemble potentiellement important d'éléments de modèles.

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 ../artifact/ar_projspecgls.htm -- This hyperlink in not present in this generated websitePrincipes 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.

Restrictions de dépendance des sous-systèmes

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 :

 

Diagramme décrit dans le texte d'accompagnement.

Dépendances des sous-systèmes et des packages dans le modèle de conception

Spécification et réalisation des sous-systèmes

Le langage UML 1.5 indique que :

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).

Informations supplémentaires

Voir Différences entre UML 1.x et UML 2.0 pour de plus amples informations.

RUP (Rational Unified Process)   2003.06.15