Rubriques

Stéréotypes des classes d'analyse Haut de la page

Les classes d'analyse peuvent être stéréotypées de la manière suivante :

  • Classes frontière
  • Classes de contrôle
  • Classes d'entité

Outre le fait de vous donner des conseils plus spécifiques sur les processus lors de l'identification des classes, ce stéréotype mène à un modèle d'objet solide car les modifications intervenues sur le modèle n'affectent généralement qu'un secteur particulier. Les changements dans l'interface utilisateur, par exemple, n'affecteront que les classes frontière. Les changements au niveau du flux de contrôle n'affecteront que les classes de contrôle. Les changements sur les informations à long terme n'affecteront que les classes d'entité. Néanmoins, ces stéréotypes sont tout particulièrement utiles pour vous aider à identifier les classes durant l'analyse et au tout début de la conception Il vous faudra tout de même penser à utiliser un ensemble de stéréotypes légèrement différents dans les phases ultérieures de la conception afin d'assurer une meilleure relation avec l'environnement d'implémentation, le type d'application et ainsi de suite.

Classe frontière Icône de la classe frontière Haut de la page

Une classe frontière est une classe utilisée pour modéliser les interactions entre l'environnement du système et ses modes de fonctionnement internes. Une telle interaction implique une transformation et une traduction des événements et la consignation des changements apportés à la présentation du système (comme l'interface).

Les classes frontière modélisent les parties du système qui dépendent de leur environnement. Les classes d'entité ainsi que les classes de contrôle modélisent les parties qui sont indépendantes de l'environnement des systèmes. Ainsi, si l'on change l'interface graphique ou bien le protocole de communication, seules les classes frontière seront modifiées et les classes d'entité et de contrôle, elles, ne le seront pas.

Les classes frontière facilitent également la compréhension du système car elles clarifient les frontières du système. Elles sont une aide dans la conception car elles fournissent un bon point de départ concernant l'identification des services qui leurs sont associés. Par exemple, si vous identifiez une interface d'imprimante au tout début de la conception, vous constaterez rapidement que vous devez aussi modéliser la mise en forme des impressions.

Les classes frontière communes incluent les fenêtres, les protocoles de communication, les interfaces d'imprimante, les capteurs et les terminaux. Il n'est pas nécessaire de modéliser les éléments d'interface courants, comme les boutons, en tant que classes frontière séparées. En général, la fenêtre entière est l'objet frontière le plus fin. Les classes frontière sont également utiles pour l'enregistrement d'interfaces vers des interfaces de programmation d'application (API) qui ne seraient pas orientées objets, telles que le code existant.

Les classes frontière doivent être modélisées selon le type de frontière qu'elles représentent. La communication avec un autre système et la communication avec un acteur humain (à travers l'interface utilisateur) présentent des objectifs différents. Pour la communication avec un acteur humain, l'aspect le plus important est la forme dans laquelle l'interface est présentée à l'utilisateur. Pour la communication avec un autre système, c'est le protocole de communication qui est essentiel.

Un objet frontière (une instance de la classe frontière) peut survivre à une instance de cas d'utilisation, s'il doit par exemple apparaître à l'écran entre l'exécution de deux cas d'utilisation. Néanmoins, normalement les objets frontière ont une durée de vie aussi longue que les instances de cas d'utilisation.

Identification des classes frontière

Une classe frontière représente l'intermédiaire entre l'interface et un élément externe au système. Les objets frontière isolent le système des changements de l'environnement (changements au niveau des interfaces vers d'autres systèmes, changements dans les exigences des utilisateurs, etc.), ce qui empêche le reste du système d'être affecté par ces changements.

Un système peut comporter plusieurs types de classes frontière :

  • Les classes d'interface utilisateur - ce sont des classes qui permettent la communication entre les utilisateurs du système
  • Les classes d'interface système - ce sont des classes qui permettent la communication avec d'autres systèmes
  • Les classes d'interface périphériques - ce sont des classes qui fournissent l'interface aux périphériques (tels que les capteurs), qui détectent des événements externes.
Identification des classes d'interface utilisateur

Vous devez définir une classe frontière pour chaque paire "cas d'utilisation - acteur". Cette classe peut être vue comme étant celle qui assure la coordination de l'interaction avec l'acteur. Vous pouvez également définir des classes frontière supplémentaires pour représenter les classes secondaires auxquelles les classes frontière délèguent certaines de leurs responsabilités. Ceci est particulièrement vrai pour les applications à base de fenêtres, dans lesquelles vous définissez un objet frontière pour chaque fenêtre ou un objet pour chaque formulaire. Ne définissez que les abstractions clés du système ; ne modélisez pas chaque bouton, liste et objet de l'interface. Le but de l'analyse est de créer une bonne image du contenu du système, et non de représenter chacun de ses détails. En d'autres termes, vous devez exclusivement identifier les classes frontière pour les événements liés au système, ou pour les éléments mentionnés dans le flot des événements de la réalisation du cas d'utilisation d'analyse.

Réalisez des diagrammes ou utilisez des copies d'écran à partir du prototype de l'interface utilisateur, qui illustreront le comportement et l'aspect des classes frontière.

Identification des classes d'interface système

Une classe frontière qui communique avec un système externe est en charge de la gestion du dialogue avec celui-ci ; elle procure à ce système l'interface requise pour le système en construction.

Exemple

Les retraits d'argent à partir d'un Distributeur Automatique de Billets doivent être vérifiés via le réseau DAB (ATM), un acteur qui vérifie ensuite le retrait par rapport au système comptable de la banque. Un objet nommé interface réseau DAB (ATM) fournit les communications avec le réseau DAB (ATM).

Il est probable que l'interface vers un système existant soit déjà définie ; si tel est le cas, les responsabilités devront être dérivées directement à partir de la définition d'interface. S'il existe une définition d'interface formelle, un processus de génération de code pourra être utilisé et il ne sera donc pas nécessaire de la définir de manière formelle ; notez simplement que l'interface existante sera réutilisée durant la conception.

Identification des classes d'interface

Le système peut contenir des éléments qui agissent comme s'ils étaient des éléments externes (modifiant spontanément la valeur sans qu'aucun objet du système ne les affecte), comme les capteurs. Bien qu'il soit possible de représenter ce type d'équipement externe en utilisant des acteurs, les utilisateurs du système peuvent trouver cette méthode "compliquée", compte tenu qu'elle tend à mettre les périphériques et acteurs humains au même "niveau". Une fois le recueil des exigences terminé, il faut néanmoins considérer la source de l'ensemble des événements externes et s'assurer que l'on dispose d'une solution de détection d'événements pour le système.

Si le périphérique est représenté comme un acteur dans le modèle de cas d'utilisation, il est alors facile de justifier l'utilisation d'une classe frontière pour assurer la communication entre le périphérique et le système. Si le modèle de cas d'utilisation n'inclut pas ces paires "périphérique-acteurs", c'est le moment de les ajouter, en mettant à jour, le cas échéant, les descriptions supplémentaires liées aux cas d'utilisation.

Pour chaque paire "périphérique-acteur", créez une classe frontière pour spécifier les responsabilités du périphérique ou du capteur. S'il existe déjà une interface bien définie pour le périphérique, prenez en note afin de vous y référer ultérieurement durant la conception.

Classe de contrôle Icône de la classe de contrôle Haut de la page

Une classe de contrôle est une classe utilisée pour modéliser un comportement de contrôle spécifique à un cas d'utilisation ou plus. Les objets de contrôle (instances des classes de contrôle) commandent souvent d'autres objets, par conséquent leur comportement est de l'ordre de la coordination. Les classes de contrôle intègrent des comportements spécifiques aux cas d'utilisation.

Le comportement d'un objet de contrôle est intimement lié à la réalisation du cas d'utilisation. Dans de nombreux scénarios, on pourrait même dire que les objets de contrôle "procèdent" à la réalisation des cas d'utilisation d'analyse. Cependant, certains objets de contrôle peuvent participer à plusieurs réalisations de cas d'utilisation d'analyse, si les tâches liées au cas d'utilisation sont intimement liées. De plus, plusieurs objets de contrôle de différentes classes de contrôle peuvent intervenir au sein d'un seul cas d'utilisation. Tous les cas d'utilisation ne requièrent pas un objet de contrôle. Par exemple, si le flot des événements d'un cas d'utilisation est lié à un objet d'entité, il est probable qu'un objet frontière exécute un cas d'utilisation en coopération avec l'objet d'entité. Vous pouvez débuter en identifiant une classe de contrôle par cas d'utilisation d'analyse, et ensuite affiner cela au fur et à mesure de l'identification de nouvelles réalisations de cas d'utilisation et de la mise en évidence de parties communes.

Les classes de contrôle peuvent contribuer à la compréhension du système car elles représentent la dynamique du système, en gérant les tâches et flots de contrôle majeurs.

Lorsque le système exécute un cas d'utilisation, un objet de contrôle est créé. Les objets de contrôle meurent généralement lorsque les cas d'utilisation leur correspondant sont terminés.

Veuillez noter qu'une classe de contrôle ne manipule pas tous les éléments nécessaires à un cas d'utilisation. Au lieu de cela, elle coordonne les activités des autres objets qui implémentent la fonctionnalité. La classe de contrôle délègue le travail aux objets auxquels on a affecté la responsabilité de la fonctionnalité.

Identification des classes de contrôle

Les classes de contrôle assurent la coordination du système. Le système peut réaliser certains cas d'utilisation sans aucun objet de contrôle (en utilisant uniquement des objets d'entité et frontière), en particulier les cas d'utilisation qui induisent seulement la manipulation des informations stockeés en mémoire.

Les cas d'utilisation plus complexes requièrent une classe de contrôle au minimum pour coordonner le comportement des autres objets du système. Exemples d'objets de contrôle : programmes de type gestionnaire de transactions, coordinateur de ressources et gestionnaire d'erreurs.

Les classes de contrôle dissocient les objets frontière et les objets d'entité, rendant ainsi le système plus tolérant aux changements intervenus au sein du système. Elles dissocient également le comportement spécifique aux cas d'utilisation des objets d'entité, les rendant ainsi plus réutilisables pour d'autres cas d'utilisation et systèmes.

Les classes de contrôle produisent un comportement qui :

  • est indépendant des environnements (qui n'implique aucun changement même en cas de changement des environnements),
  • définit la logique de contrôle (ordre des événements) et les transactions à l'intérieur d'un cas d'utilisation.
  • change peu dans le cas où la structure interne ou le comportement des classes d'entité se modifie,
  • utilise ou définit le contenu de plusieurs classes d'entité et qui doit ainsi coordonner le comportement de ces classes d'entité.
  • n'est pas réalisé de manière identique à chaque fois qu'il est activé (le flot des événements présente plusieurs états).
Déterminer si la présence d'une classe de contrôle est requise

Le flot des événements d'un cas d'utilisation définit l'ordre dans lequel les différentes tâches sont exécutées. Commencez par déterminer si le flot peut être géré par les classes frontière et d'entité déjà identifiées. Les flots d'événements simples qui se contentent d'entrer, d'extraire, d'afficher ou de modifier des informations, ne justifient pas l'utilisation dune classe de contrôle séparée ; les classes frontière coordonneront le cas d'utilisation.

Les flots d'événements doivent être intégrés dans une classe de contrôle séparée s'ils sont complexes et comprennent un comportement dynamique, susceptible de changer indépendamment des interfaces (classes frontière) ou des mémoires d'informations du système (classes d'entité). En intégrant les flots d'événements, une même classe de contrôle peut potentiellement être réutilisée pour divers systèmes qui peuvent comporter différentes interfaces et différentes mémoires d'informations (ou au minimum les structures de données sous-jacentes).

Exemple : gestion d'une file d'attente de tâches

Vous pouvez identifier une classe de contrôle à partir du cas d'utilisation Exécuter une tâche dans le système de gestion des stocks. Cette classe de contrôle gère une file d'attente de tâches, garantissant ainsi l'exécution des tâches dans le bon ordre. Elle exécute la prochaine tâche de la file d'attente dès que le dispositif de transport approprié est alloué. Le système peut ainsi exécuter plusieurs tâches simultanément.

Le comportement défini par l'objet de contrôle correspondant est plus facile à décrire si vous le divisez en deux classes de contrôle : un module d'exécution des tâches et un gestionnaire de file d'attente. Un objet de gestion de file d'attente ne s'occupe que de l'ordre de la file d'attente et de l'allocation du dispositif de transport. Un seul objet de gestion de file d'attente est requis pour l'ensemble de la file d'attente. Dès que le système exécute une tâche, il crée un nouvel objet d'exécution des tâches qui se charge de l'exécution de la tâche. On a donc besoin d'un objet d'exécution des tâches pour chacune des tâches exécutées par le système.

Les classes "trop complexes" doivent être divisées en classes ayant un ensemble de responsabilités cohérent

Les classes complexes doivent être divisées selon des axes de responsabilités similaires.

Le principal bénéfice de cette division est que l'on a séparé les responsabilités de gestion de file d'attente (élément générique des cas d'utilisation) des activités spécifiques de gestion des tâches, qui sont propresà ce cas d'utilisation. Cela rend la compréhension des classes plus aisée ainsi que leur adaptation tandis que la conception continue à évoluer. Cela présente aussi des avantages dans l'équilibre de la charge du système, compte tenu qu'autant de modules d'exécution de tâches que nécessaire peuvent être créés pour gérer la charge de travail.

Intégrer le flot principal d'événements et les flots alternatifs/exceptionnels d'événements dans des classes de contrôle séparées.

Pour simplifier les changements, intégrez le flot principal d'événements et les flots alternatifs d'événements dans différentes classes de contrôle. Si les flux alternatifs et exceptionnels d'événements sont tout à fait indépendants, il faudra également les séparer. Vous pourrez plus facilement étendre le système et mieux le maintenir dans le temps.

Diviser les classes de contrôle lorsque deux acteurs partagent la même classe de contrôle

Les classes de contrôle peuvent également exiger d'être divisées lorsque plusieurs acteurs utilisent la même classe de contrôle. En faisant cela, nous isolons les changements demandés par un acteur du reste du système. Dans les cas où de tels changements engendrent des coûts élevés ou des conséquences importantes, vous devez identifier toutes les classes de contrôle qui sont liées à un ou plusieurs acteur(s) et les diviser. Dans l'idéal, chaque classe de contrôle doit interagir (via un objet frontière) avec un seul acteur ou bien aucun.

Exemple : gestion d'appels

Imaginons le cas d'utilisation Appel local. Initialement, on peut identifier une classe de contrôle pour gérer l'appel proprement dit.

Les différents acteurs impliqués dans un cas d'utilisation nécessitent des classes de contrôle séparées

La classe de contrôle gérant les appels téléphoniques en mode local dans un système téléphonique peut être facilement divisée en deux classes de contrôle, Comportement A et Comportement B, avec une classe pour chaque acteur.

Dans le cadre d'un appel téléphonique local, il y a deux acteurs : l'Abonné A qui émet l'appel, et l'Abonné B qui reçoit l'appel. L'Abonné A décroche le combiné, entend la tonalité et compose une série de chiffres, stockés et analysés par le système. Une fois que le système a reçu tous les chiffres, il émet une tonalité vers l'Abonné A, ainsi qu'un signal d'appel vers l'Abonné B. Au moment où l'Abonné B répond, la tonalité et le signal s'interrompent et la conversation entre les deux abonnés peut commencer. L'appel se termine lorsque les deux abonnés raccrochent.

Deux comportements doivent rester sous contrôle : Que se passe-t-il pour l'abonné A et que se passe-t-il pour l'abonné B ? C'est pour cette raison que l'objet de contrôle d'origine a été divisé en deux objets de contrôle, Comportement A et Comportement B.

Il n'est pas nécessaire de diviser une classe de contrôle dans les cas suivants :

  • Si vous pouvez raisonnablement penser que le comportement des acteurs liés aux objets de la classe de contrôle ne changera jamais, ou seulement de manière mineure.
  • Le comportement d'un objet de la classe de contrôle vis-à-vis d'un acteur est insignifiant en comparaison avec son comportement vis-à-vis de l'autre acteur ; un seul objet peut contenir l'ensemble du comportement. Le fait de combiner plusieurs comportements de cette manière n'aura que très peu d'effets sur la capacité potentielle de changement.

Classe d'entité Icône de classe d'entité Haut de la page

Une classe d'entité est une classe utilisée pour modéliser des informations et leurs comportements associés qui doivent être stockés. Les objets d'entité (instances des classes d'entité) sont utilisés pour contenir et mettre à jour les informations concernant un phénomène, par exemple un événement, une personne ou bien un objet réel. Ils sont généralement persistants, avec des attributs et relations durables, qui ont parfois une durée de vie égale à celle du système.

Un objet d'entité n'est habituellement pas spécifique à un cas d'utilisation d'analyse ; il arrive même parfois qu'un objet d'entité ne soit même pas spécifique au système lui-même. Les valeurs de ses attributs et relations sont souvent définies par un acteur. Un objet d'entité peut également s'avérer nécessaire pour aider l'exécution de tâches internes au système. Les objets d'entité peuvent avoir des comportements aussi compliqués que ceux d'autres stéréotypes d'objets. Néanmoins, à l'inverse des autres objets, ce comportement est fortement lié au phénomène représenté par l'objet d'entité. Les objets d'entité sont indépendants de l'environnement (les acteurs).

Les objets d'entité représentent les concepts clés du système en cours de développement. Dans un système bancaire, des exemples typiques de classes d'entité sont Compte et Client. Dans un système de gestion de réseau, vous pouvez définir les classes Noeud et Liaison.

Si le phénomène que vous souhaitez modéliser n'est utilisé par aucune autre classe, vous pouvez le créer comme étant l'attribut d'une classe d'entité, ou même comme une relation entre des classes d'entité. En revanche, si le phénomène est utilisé par une autre classe du modèle de conception, vous devez le créer en tant que classe.

Les classes d'entité fournissent une information supplémentaire à partir de laquelle on peut comprendre le système. Elles indiquent la structure logique des données, qui peut vous aider à comprendre ce que le système est supposé offrir à ses utilisateurs.

Identification des classes d'entité

Les classes d'entité représentent les mémoires d'informations du système ; elles sont typiquement utilisées pour représenter les concepts clés gérés par le système. Les objets d'entité sont fréquemment passifs et persistants. Leurs principales responsabilités consistent à stocker et à gérer les informations présentes dans le système.

Une source fréquente d'inspiration pour les classes d'entité est le glossaire (développé durant la phase de recueil des exigences) ou un modèle de domaine métier (développé durant la phase de modélisation métier, si elle a été réalisée).

Restrictions d'usage des stéréotypes d'association Haut de la page

Restrictions des classes frontière Haut de la page

Les associations suivantes sont autorisées :

  • Les associations de communication entre deux classes frontière, par exemple pour décrire la manière dont une fenêtre spécifique est liée à d'autres objets frontière.
  • Les associations de communication ou de souscription entre une classe frontière et une classe d'entité, du fait que les objets frontière peuvent être amenés à suivre certains objets d'entité au fur et à mesure des actions intervenues dans l'objet frontière, ou à être informés des modifications d'état dans l'objet d'entité.
  • Les associations de communication d'une classe frontière à une classe de contrôle, de telle manière qu'un objet frontière puisse déclencher un comportement particulier.

Restrictions des classes de contrôle Haut de la page

Les associations suivantes sont autorisées :

  • Les associations de communication ou de souscription entre une classe frontière et une classe d'entité, du fait que les objets de contrôle peuvent être amenés à suivre certains objets d'entité au fur et à mesure des actions intervenues dans l'objet de contrôle, ou à être informés des modifications d'état dans l'objet d'entité.
  • Les associations de communication entre les classes de contrôle et les classes frontière, permettant la communication à l'environnement des résultats de comportement.
  • Les associations de communication entre les classes de contrôle, permettant la construction de modèles de comportement plus complexes.

Restrictions des classes d'entité Haut de la page

Seules des classes d'entité peuvent être à la source des associations (communication ou souscription) avec d'autres classes d'entité. Les objets des classes d'entité ont généralement une longue durée de vie ; les objets des classes de contrôle et des classes frontière ont eux une durée de vie plus courte. Il semble cohérent d'un point de vue architectural de limiter la visibilité qu'a un objet d'entité de son environnement ; de cette manière, le système est plus favorable au changement.

Résumé des restrictions Haut de la page

De\Vers
(navigabilité)

Frontière

Entité

Contrôle

Frontière

communication

communication

souscription

communication

Entité

communication

souscription

 

Contrôle

communication

communication

souscription

communication

Combinaisons valables de stéréotypes d'associations

Application de la cohérence Haut de la page

  • Lorsqu'un nouveau comportement est identifié, vérifiez qu'il existe déjà une classe qui présente des responsabilités similaires, en réutilisant les classes lorsque cela est possible. Si vous êtes absolument sûr(e) qu'il n'existe aucun objet susceptible d'exécuter le comportement, vous pouvez créer de nouvelles classes.
  • Lorsque les classes sont identifiées, examinez-les pour vous assurer que leurs responsabilités sont cohérentes. Si les responsabilités des classes sont disjointes, divisez l'objet en deux classes au minimum. Mettez à jour les diagrammes d'interaction en conséquence.
  • Si la classe est divisée du fait qu'il existe des responsabilités disjointes, examinez les collaborations dans lesquelles la classe joue un rôle pour voir si la collaboration nécessite une mise à jour. Mettez à jour la collaboration le cas échéant.
  • Une classe avec une seule responsabilité ne constitue pas un problème, mais on devrait s'interroger sur le caractère obligatoire de cet élément. Soyez préparé à mettre en question et à justifier l'existence de toutes les classes.


RUP (Rational Unified Process)   2003.06.15