Rubriques

Introduction Haut de la page

Le modèle de conception peut être structuré en plus petites unités, ce qui facilite sa compréhension. En regroupant les éléments du modèle de conception en packages et en sous-systèmes, et en montrant ensuite les liens qui existent entre les regroupements, il est plus facile de comprendre la structure globale du modèle. Notez qu'un sous-système de conception est modélisé comme un composant qui réalise une ou plusieurs interfaces ; pour plus d'informations, voir Artefact : Sous-système de conception et Principes et conseils : Sous-système de conception. Les packages de conception ne sont par ailleurs destinés qu'aux regroupements.

Visibilité du contenu du package Haut de la  page

Une classe contenue dans un package peut être publique ou privée. Une classe publique peut être associée à toute autre classe. Une classe privée ne peut être associée que par les classes contenues dans le package.

Une interface de package comporte les classes publiques d'un package. L'interface du package (classes publiques) isole et implémente les dépendances sur d'autres packages. De cette manière, le développement en parallèle est simplifié, car vous pouvez dès le début établir des interfaces et seuls les changements intervenus dans les interfaces des autres packages seront mentionnés aux développeurs.

Critères de partitionnement du package Haut de la page

Certaines raisons peuvent justifier le partitionnement du modèle de conception :

  • Vous pouvez utiliser les packages et sous-systèmes comme des unités de commande, de configuration, ou de livraison, quand un système est fini.
  • L'allocation des ressources et la compétence des différentes équipes de développement peut nécessiter la division du projet parmi les différents groupes sur les différents sites. Les sous-systèmes, munis d'interfaces bien définies, permettent de diviser le travail entre les équipes, d'une manière contrôlée et coordonnée, ce qui permet de réaliser la conception et l'implémentation en parallèle.
  • Les sous-systèmes peuvent être utilisés pour structurer le modèle de conception, d'une manière qui reflète les types d'utilisateurs. De nombreuses exigences de changement émanent des utilisateurs ; les sous-systèmes assurent que les changements émanant d'un type particulier d'utilisateur n'affecteront que les parties du système qui correspondent à ce type d'utilisateur.
  • Dans certaines applications, certaines informations ne doivent être accessibles qu'à un nombre limité de personnes. Les sous-systèmes vous permettent de préserver le caractère confidentiel des informations dans les domaines où cela s'impose.
  • Si vous construisez un système de support, en utilisant les sous-systèmes et packages, vous pouvez lui donner une structure similaire à la structure du système à supporter. De cette manière, vous pouvez synchroniser les deux systèmes.
  • Les sous-systèmes sont utilisés pour représenter les produits et services existants, utilisés par le système (par exemple, les produits et bibliothèques COTS), comme cela est expliqué dans les prochaines sections.

Classes frontières du package Haut de la  page

Quand les classes frontières sont réparties dans les packages, on peut appliquer deux stratégies différentes : on optera pour l'une ou l'autre selon que les interfaces système sont susceptibles de changer radicalement dans l'avenir.

  • Si l'interface système est susceptible d'être remplacée ou de subir des changements considérables, elle doit être séparée du reste du modèle de conception. Si l'interface utilisateur est modifiée, seuls ces packages en seront affectés. Un exemple de changement majeur est le passage d'une interface orientée ligne de commande à une interface orientée fenêtre.

Diagramme décrit dans le texte d'accompagnement.

Si le but principal est de simplifier les changements majeurs de l'interface, les classes frontières doivent être placées dans un ou plusieurs packages séparés.

  • Si aucun changement majeur n'est prévu sur l'interface, les changements intervenus sur les services système doivent être le principe de base, plutôt que les changements intervenus sur l'interface. Les classes frontières doivent alors être placées avec les classes d'entité et de contrôle auxquelles elles sont liées sur le plan fonctionnel. De cette manière, il sera facile de voir quelles classes frontières sont affectées, si l'on modifie une certaine classe d'entité ou de contrôle.

Diagramme décrit dans le texte d'accompagnement.

Pour simplifier les changements des services du système, les classes frontières sont regroupées avec les classes auxquelles elles sont liées sur le plan fonctionnel.

Les classes frontières obligatoires qui ne sont pas liées à des classes d'entité ou de contrôle sur le plan fonctionnel, doivent être placées avec les classes frontières qui appartiennent à la même interface.

Si une classe frontière est liée à un service facultatif, vous devez la regrouper avec les classes qui fournissent le service, dans un sous-système séparé. Le sous-système effectuera la correspondance avec un composant facultatif, qui sera fourni au moment où la fonctionnalité facultative sera demandée.

Regroupement des classes liées fonctionnellement Haut de la  page

Un package doit être identifié pour chaque groupe de classes liées sur le plan fonctionnel. Il existe plusieurs critères pratiques qui peuvent être appliqués, quand on juge que deux classes sont liées sur le plan fonctionnel. Ces critères sont classés ci-dessous, par ordre d'importance décroissant :

  • Si les changements de comportement et/ou de structure d'une classe nécessitent des changements dans une autre classe, les deux classes sont liées sur le plan fonctionnel.

Exemple

Si un nouvel attribut est ajouté à la classe d'entité commande, il est très probable que la classe de contrôle administrateur de commande nécessite une mise à jour. Par conséquent, elles appartiennent au même package, Traitement des commandes.

  • Il est possible de voir si une classe est liée à une autre sur le plan fonctionnel, en débutant par une classe, par exemple, une classe d'entité, et en examinant ce qu'il se passe lorsqu'on la retire du système. Toute classe qui devient superflue, suite à la suppression d'une classe, est d'une manière ou d'une autre rattachée à la classe supprimée. Par "superflue", nous entendons que la classe n'est utilisée que par la classe supprimée, ou qu'elle dépend de la classe supprimée.

Exemple

Il existe un package Traitement des commandes qui comporte les deux classes de contrôle Administrateur de commande et Registre de commandes, dans le Système de traitement du dépôt. Ces deux classes de contrôle modélisent les services concernant le traitement des commandes du dépôt. Tous les attributs de commandes et relations sont stockés par la classe d'entité commande, qui n'existe que pour le traitement des commandes. Si la classe d'entité est supprimée, il ne sera plus nécessaire de faire appel à l'administrateur de commande ou au registre de commandes, parce qu'ils ne sont utiles que si la commande existe. Par conséquent, la classe d'entité commande doit être incluse dans le même package que les deux classes de contrôle.

Diagramme décrit dans le texte d'accompagnement.

L'Administrateur de commande et le registre de commandes appartiennent au même package que commande, du fait qu'ils deviennent superflus quand la commande est retirée du système.

  • Deux objets peuvent être liés sur le plan fonctionnel, s'ils interagissent avec un grand nombre de messages, ou s'ils entretiennent une intercommunication compliquée.

Exemple

La classe de contrôle Exécuteur de tâches envoie et reçoit beaucoup de messages vers et de l'interface de transport. Cela indique encore qu'elles doivent être incluses dans le même package, Traitement des tâches.

  • Une classe frontière peut être liée sur le plan fonctionnel à une classe d'entité particulière, si la fonction de la classe frontière est de présenter la classe d'entité.

Exemple

La classe frontière forme de la palette, dans le système de traitement du dépôt, présente à l'utilisateur, une instance de la classe d'entité Palette. Chaque palette est représentée par un numéro d'identification à l'écran. Si les informations liées à une palette sont modifiées, par exemple, si la palette reçoit aussi un nom, la classe frontière devra probablement être également modifiée. La forme de la palette doit donc être incluse dans le même package que la palette.

  • Deux classes peuvent être liées sur le plan fonctionnel, si elles interagissent avec, ou sont affectées par les changements intervenus sur le même acteur. Si deux classes n'impliquent pas le même acteur, elles ne doivent pas se trouver dans le même package. Pour des raisons plus importantes, la dernière règle peut évidemment être ignorée.

Exemple

Il y a un package Traitement des tâches dans le système de traitement du dépôt, qui comporte, entre autres choses, la classe de contrôle Exécuteur de tâches. C'est le seul package impliqué avec l'acteur transporteur, le transporteur physique qui peut transporter une palette dans le dépôt. L'acteur interagit avec la classe de contrôle exécuteur de tâches par l'intermédiaire de la classe frontière interface de transport. Cette classe frontière doit donc être incluse dans le package Traitement des tâches.

Diagramme décrit dans le texte d'accompagnement.

L'Interface de transport et l'Exécuteur de tâches appartiennent au même package, du fait qu'ils sont tous deux touchés par les changements intervenus dans l'acteur transporteur.

  • Deux classes peuvent être liées sur le plan fonctionnel, si elles ont des relations (associations, agrégations, et ainsi de suite). Evidemment, ce critère ne peut pas être suivi de manière irréfléchie, mais il peut être utilisé lorsque aucun critère n'est applicable.
  • Une classe peut être fonctionnellement liée à la classe qui créé ses instances.

Ces deux critères déterminent si deux classes ne doivent pas être placées ensemble dans le même package :

  • Un même package ne doit pas contenir deux classes liées à différents acteurs.
  • Un même package ne doit pas comporter une classe facultative et une classe obligatoire.

Evaluer la cohésion du package Haut de la page

Tout d'abord, tous les éléments d'un package doivent avoir le même caractère optionnel ou obligatoire : aucun élément facultatif d'un modèle ne doit se trouver dans un package obligatoire.

Exemple

La classe d'entité obligatoire Type d'article comporte, entre autres, un attribut appelé Seuil de réapprovisionnement. La fonction de réapprovisionnement du système est cependant facultative. Par conséquent, l'article doit être subdivisé en deux classes d'entité, dans lesquelles la classe facultative est rattachée à la classe obligatoire.

Un package considéré comme obligatoire peut ne pas dépendre d'un package considéré comme facultatif.

En règle générale, un seul package ne peut pas être utilisé par deux acteurs différents. La raison est qu'un changement de comportement de l'acteur ne doit pas affecter les autres acteurs. Il y a des exceptions à cette règle, telles que les packages qui constituent des services facultatifs. Les packages de ce type ne doivent pas être subdivisés, indépendamment du nombre d'acteurs les utilisant. Vous pouvez par conséquent subdiviser les packages ou classes utilisés par plusieurs acteurs, à moins que le package ne soit facultatif.

Toutes les classes d'un même package doivent être liées sur le plan fonctionnel. Si vous avez suivi les critères de la section "Identifier des packages à partir des classes fonctionnellement liées", les classes seront mutuellement liées sur le plan fonctionnel. Néanmoins, une classe particulière peut contenir "trop" de comportements ou de relations n'appartenant pas à la classe. Une partie de la classe devra alors être retirée pour devenir une classe complètement nouvelle, ou faire partie d'une autre classe qui appartiendra probablement à un autre package.

Exemple

Le comportement d'une classe de contrôle, A, appartenant à un package ne doit pas trop dépendre de la classe B appartenant à un autre package. Pour isoler le comportement spécifique à B, la classe de contrôle A doit être subdivisée en deux classes de contrôle, A' et A". Le comportement spécifique à B est placé dans la nouvelle classe de contrôle, A", qui est elle-même placée dans le même package que B. La nouvelle classe A" se voit également attribuer une relation, par exemple une généralisation, à l'objet original A'.

Diagramme décrit dans le texte d'accompagnement.

Pour isoler le comportement spécifique à B, la classe de contrôle A, qui manque d'homogénéité, est subdivisée en deux classes de contrôle, A' et A''.

Décrire les dépendances du package Haut de la page

Si une classe appartenant à un package comporte une association à une classe appartenant à un package différent, alors ces packages sont inter-dépendants. Les dépendances des packages sont modélisées, en utilisant une relation de dépendance entre les packages. Les relations de dépendance nous aident à évaluer la conséquences des changements : un package dont dépend un grand nombre de packages est plus difficile à modifier qu'un package dont ne dépend aucun package.

Du fait que plusieurs dépendances de ce type seront découvertes durant la spécification des packages, ces relations vont sûrement changer durant le travail. La description d'une relation de dépendance peut inclure des informations au sujet des classes qui ont généré la dépendance. Comme cela introduit une notion d'informations difficiles à maintenir, il ne faut l'envisager que si les informations sont pertinentes et de valeur.

Exemple

Dans le Système de traitement du dépôt, il y a une relation de dépendance du package Traitement des commandes par rapport au package Traitement des articles. Cette association se produit parce que la classe d'entité commande dans traitement des commandes présente une association avec la classe d'entité type d'article de l'autre package.

Diagramme décrit dans le texte d'accompagnement.

Le package traitement des commandes est dépendant de traitement des articles, parce qu'il existe une association entre les deux classes des packages.

Evaluer le couplage du package Haut de la page

Le couplage des packages est à la fois une bonne et une mauvaise chose : bonne parce que le couplage permet une ré-utilisation et mauvaise parce que cette action représente des dépendances qui rendent le système plus difficile à modifier et à faire évoluer. On peut suivre certains principes généraux :

  • Les packages ne doivent pas être couplés en mode transversal (c'est à dire en mode co-dépendant) ; par exemple, deux packages ne doivent pas être dépendants l'un de l'autre.

Diagramme décrit dans le texte  d'accompagnement.

Dans ces situations, les packages doivent être ré-organisés pour supprimer les dépendances en mode transversal.

  • Les packages des couches inférieures ne doivent pas être dépendants de packages des couches supérieures. Les packages doivent seulement être dépendants de packages faisant partie de la même couche ou de la couche immédiatement supérieure.

Diagramme décrit dans le texte d' accompagnement.

Dans ces situations, la fonctionnalité doit être repartitionnée. Il existe une solution qui consiste à définir les dépendances en termes d'interfaces, et à organiser les interfaces dans la couche inférieure.

  • En général, les dépendances ne doivent sauter aucune couche, à moins que le comportement dépendant soit commun à toutes les couches. L'alternative est simplement de faire transiter les opérations entre les couches.
  • Les packages ne doivent pas dépendre des sous-systèmes, mais seulement des autres packages ou interfaces.


RUP (Rational Unified Process)   2003.06.15