Instructions: Classe d'analyse
Il y a trois stéréotypes de classe d'analyse : Frontière, Contrôle et Entité. Ces instructions expliquent leur signification et leur utilisation.
Relations
Description principale

Stéréotypes de classe d'analyse

Les classes d'analyse peuvent être stéréotypées de la façon suivante :

  • Les classes frontière
  • Les classes de contrôle
  • Les classes entité

Ce stéréotypage vous guide de manière plus précise lors de la création de classes et crée un modèle d'objet solide car les changements qui y sont apportés n'affectent en général qu'une zone spécifique. Les changements dans l'interface utilisateur, par exemple, n'affecteront que les classes frontière. Les changements dans le flux de contrôle n'affecteront que les classes de contrôle. Les changements dans les informations à long terme n'affecteront que les classes entité. Toutefois, ces stéréotypes sont aussi particulièrement utiles pour l'identification des classes lors de l'analyse et de la conception initiale. Il sera sûrement plus judicieux d'utiliser un ensemble de stéréotypes légèrement différents lors des phases de conception plus avancées pour mieux correspondre à l'implémentation de l'environnement, au type d'application et ainsi de suite.

Classe frontière icône de classe frontière

Une classe frontière est une classe utilisée pour modéliser l'interaction entre l'environnement du système et son fonctionnement interne. Une telle interaction implique la transformation et la translation d'événements et rien ne change dans la présentation du système (comme l'interface).

Les classes frontière modélisent les parties du système qui dépendent de son environnement. Les classes entité et les classes de contrôle modélisent les parties qui sont indépendantes de l'environnement du système. Changer l'interface graphique ou le protocole de communication implique donc de ne changer que les classes frontière et pas les classes entité et les classes de contrôle.

Les classes frontière facilitent aussi la compréhension du système car elles simplifient ses frontières. Elles aident à la conception en donnant un bon point de départ pour l'identification des services connexes. Par exemple, si vous identifiez l'interface imprimante tôt dans la conception, vous vous apercevrez rapidement que vous devez aussi modéliser le formatage des impressions.

Les classes frontière classiques incluent des fenêtres, des protocoles de communication, des interfaces imprimante, des détecteurs et des terminaux. Vous n'avez pas à modéliser les composants habituels de l'interface, comme les boutons, en tant que classes frontière indépendantes. En général, la fenêtre entière est l'objet frontière le plus détaillé. Les classes frontière sont aussi utiles pour enregistrer les interfaces afin d'éviter de s'opposer aux interfaces de programme d'application orientées, comme le code existant.

Vous devez modéliser les classes frontière 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 une interface utilisateur) ont des objectifs très différents. Pour la communication avec un acteur humain, la préoccupation la plus importante est la façon dont l'interface va être présentée à l'utilisateur. Pour la communication avec un autre système, la préoccupation la plus importante est le protocole de communication.

Un objet frontière (une instance de classe frontière) peut survivre à une instance de cas d'utilisation si, par exemple, il doit apparaître sur un écran entre la performance de deux cas d'utilisation. Cependant, en général, les objets frontière vivent aussi longtemps que l'instance de cas d'utilisation.

Identification des classes frontière

Une classe frontière fait l'intermédiaire entre l'interface et quelque chose en dehors du système. Les objets frontière isolent le système des changements du monde environnant (changements dans les interfaces d'autres systèmes, changements dans les conditions utilisateur, etc.), empêchant ces changements d'affecter le reste du système.

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

  • Des classes interface utilisateur - ce sont des classes qui gèrent la communication avec les utilisateurs humains du système
  • Des classes interface système - ce sont des classes qui gèrent la communication avec les autres systèmes
  • Des classes interface du périphérique - ce sont des classes qui fournissent à l'interface des périphériques (comme des détecteurs) qui détectent des informations externes.
Identification des classes interface utilisateur

Définissez une classe frontière pour chaque paire d'acteurs de chaque cas d'utilisation. Cette classe peut être vue comme ayant la responsabilité de coordonner l'interaction avec l'acteur. Vous pouvez aussi définir des classes frontière supplémentaires pour représenter des classes subsidiaires auxquelles la classe frontière primaire déléguerait certaines de ses responsabilités. Cela est particulièrement vrai pour les applications à interface graphique basées sur des fenêtres où vous modélisez un objet frontière pour chaque fenêtre ou pour chaque formulaire. Modélisez seulement les abstractions clés du système ; ne modélisez pas tous les boutons, listes et objets fenêtre dans l'interface graphique. Le but de l'analyse est de donner une bonne image de la façon dont est composé le système, pas de modéliser chaque détail. En d'autres mots, identifier des classes frontières seulement pour des phénomènes du système ou pour des choses mentionnées dans le flot d'événements de la réalisation d'analyse de cas d'utilisation.

Faites des esquisses, ou utilisez les clichés d'écran d'un prototype d'interface utilisateur, qui illustrent le comportement et l'apparence des classes frontière.

Identification des classes interface système

Une classe frontière qui communique avec un système externe doit gérer le dialogue avec ce système externe ; elle fournit l'interface à ce système pour qu'il puisse être construit.

Exemple

Dans un guichet automatique, les retraits d'argent doivent être vérifiés dans le réseau du guichet automatique, un acteur (qui à son tour vérifie le retrait auprès du système de comptes de la banque). Un objet appelé Interface du réseau des guichets automatiques peut être défini pour communiquer avec le réseau des guichets automatiques.

L'interface vers un système existant peut déjà être définie ; si elle l'est, les responsabilités dérivent directement de la définition de l'interface. Si une définition formelle de l'interface existe, on peut avoir recours à l'ingénierie inverse mais il n'est pas nécessaire de la définir ici ; remarquez seulement le fait que l'interface existante sera réutilisée pendant la conception.

Identification des classes d'interface de périphériques

Le système peut contenir des éléments qui se comportent comme s'ils étaient externes (changeant de valeur spontanément sans qu'aucun objet du système ne les affecte), comme le matériel des détecteurs. Bien qu'il soit possible de représenter ce type de périphériques externes en utilisant des acteurs, les utilisateurs du système pourraient trouver cela "déroutant", car cela à tendance à mettre les périphériques et les acteurs humains au même "niveau". Toutefois, après avoir terminé de regrouper les conditions, nous devons prendre en considération la source de tous les événements externes et s'assurer que le système a un moyen de détecter ces événements.

Si le périphérique est représenté comme un acteur dans le modèle de cas d'utilisation, c'est facile de justifier l'utilisation d'une classe frontière pour gérer la communication entre le périphérique et le système. Si le modèle de cas d'utilisation n'inclut pas ces "acteurs périphériques", c'est le moment de les ajouter en mettant à jour les descriptions supplémentaires des cas d'utilisation.

Pour chaque "acteur périphérique", créez une classe frontière pour enregistrer 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 pour vous y référer plus tard pendant la conception.

Classe de contrôle icône de classe de contrôle

Une classe de contrôle est une classe utilisée pour modéliser le contrôle de comportement spécifique à un ou quelques cas. Les objets de contrôle (des instances de classe de contrôle) contrôlent souvent d'autres objets, leur comportement est donc de type coordonnant. Les classes de contrôle encapsulent le comportement spécifique des cas d'utilisation.

Le comportement d'un objet de contrôle est étroitement lié à la réalisation d'un cas d'utilisation spécifique. On peut même dire que, dans beaucoup de scénarios, les objets de contrôle "exécutent" les réalisations d'analyse de cas d'utilisation. Toutefois, certains objets de contrôle peuvent participer à plus d'une réalisation d'analyse de cas d'utilisation si les tâches de cas d'utilisation sont fortement liées. De plus, plusieurs objets de contrôle de différentes classes de contrôle peuvent participer dans un cas d'utilisation. Tous les cas d'utilisation n'ont pas besoin d'un objet de contrôle. Par exemple, si le flux des événements dans un cas d'utilisation est lié à un objet entité, un objet frontière peut réaliser le cas d'utilisation avec l'objet entité. Vous pouvez commencer par identifier une classe de contrôle par réalisation d'analyse de cas d'utilisation, puis les détailler à mesure que plus de réalisations d'analyse de cas d'utilisation sont identifiés et de similitudes découvertes.

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

Lorsque le système exécute le cas d'utilisation, un objet de contrôle est créé. En général, les objets de contrôle meurent lorsque le cas d'utilisation leur correspondant a été réalisé.

Notez qu'une classe de contrôle ne gère pas tout ce qui est requis dans un cas d'utilisation. Elle coordonne les tâches d'autres objets qui implémentent la fonctionnalité. La classe de contrôle délègue la tâche à d'autres objets auxquels l'on a assigné la responsabilité de la fonctionnalité.

Identification des classes de contrôle

Les classes de contrôle apportent un comportement coordonnant dans le système. Le système peut exécuter quelques cas d'utilisation sans objets de contrôle (en utilisant juste des objets entité et des objets frontières), plus particulièrement dans des cas d'utilisation qui n'impliquent qu'une manipulation simple d'informations stockées.

Des cas d'utilisation plus complexes requièrent généralement au moins une classe de contrôle pour coordonner le comportement d'autres objets dans le système. Les exemples d'objets de contrôle incluent des programmes comme des gestionnaires de transaction, des coordinateurs de ressources et des gestionnaires de traitement d'erreurs.

Les classes de contrôle séparent les objets frontière des objets entité, rendant le système plus tolérant vis à vis des changement dans les frontières du système. Elles séparent aussi le comportement spécifique des cas d'utilisation des objets entité, les rendant réutilisables à travers les cas d'utilisation et les systèmes.

Les classes de contrôle apportent un comportement qui:

  • est indépendant de l'environnement (il ne change pas quand l'environnement change),
  • définit une logique de contrôle (ordre des événements) et les transactions d'un cas d'utilisation.
  • change peu si la structure interne ou le comportement de la classe d'entité change,
  • utilise ou définit le contenu de plusieurs classes entité, et a donc besoin de coordonner le comportement de ces classes entité.
  • n'est pas exécuté de la même façon à chaque fois qu'il est activé (le flux d'événements comporte plusieurs états).
Une classe de contrôle est-elle nécessaire ?

Le flux d'événements définit l'ordre dans lequel les différentes tâches sont exécutées. Commencez par chercher si le flux peut être géré par la frontière déjà identifiée et par les classes entité. Pour les flux d'événements qui entrent, extraient et affichent ou modifient des informations principalement, une classe de contrôle séparée n'est généralement pas justifiée ; les classes frontière seront responsables de la coordination du cas d'utilisation.

Le flot d'événements doit être encapsulé dans une classe de contrôle séparée lorsqu'il est complexe et constitué d'un comportement dynamique qui pourrait changer indépendamment des interfaces (classes frontière) ou de l'approvisionnement des informations (classes entité) du système. En encapsulant le flot d'événements, la même classe de contrôle peut potentiellement être réutilisée pour une variété de systèmes qui peuvent avoir des interfaces et des mémoires d'informations différentes (ou du moins 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 dans le cas d'utilisation Exécuter la tâche dans le système de gestion de dépôt. Cette classe de contrôle gère une file d'attente de tâches, en s'assurant que les tâches sont exécutées dans le bon ordre. Elle exécute la tâche suivante dans la queue dès qu'un matériel de transport adéquat est attribué. Le système peut donc exécuter plusieurs tâches en même temps.

Le comportement défini par l'objet de contrôle correspondant est plus facile à définir si vous le divisez en deux classes de contrôle, l'Exécuteur de tâche et le Gestionnaire de file d'attente. Un objet Gestionnaire de file d'attente ne s'occupera que de l'ordre de la file d'attente et de l'attribution du matériel de transport. Un objet Gestionnaire de file d'attente est nécessaire pour la file entière. Dès que le système exécute une tâche, il crée un nouvel objet Exécuteur de tâche, qui exécutera la tâche. Nous avons donc besoin d'un objet Exécuteur de tâche pour chaque tâche exécutée par le système.

les classes "trop complexes" devraient être subdivisées en classes ayant un ensemble de responsabilités cohérent et complémentaire

Les classes complexes devraient être divisées selon des lignes de responsabilités similaires

Le principal intérêt de cette division est que nous avons des responsabilités de gestion de file d'attente séparées (ce qui est le cas dans beaucoup de cas d'utilisation) des tâches spécifiques de la gestion d'activité, ce qui est spécifique à ce cas d'utilisation. Les classes sont ainsi plus faciles à comprendre et plus adaptables au fur et à mesure de l'avancement de la conception. Cela permet aussi d'équilibrer la charge du système, puisque l'on peut créer autant d'Exécuteurs de tâche que nécessaire pour gérer la charge de travail.

Encapsulement du principal flux d'événements et des flux d'événements alternés/exceptionnels

Pour simplifier les changements, encapsulez le flux d'événements principal et les flux d'événements alternés dans différentes classes de contrôle. Si les flux alternés et exceptionnels sont complètement indépendants, séparez-les aussi. Cela facilitera l'extension et la gestion du système dans le futur.

Partage de classes de contrôle où deux acteurs partagent la même classe de contrôle

Les classes de contrôle peuvent aussi avoir besoin d'être partagées lorsque plusieurs acteurs utilisent la même classe de contrôle. En faisant cela, nous isolons les changements des exigences d'un acteur du reste du système. Lorsque le coût du changement est élevé ou les conséquences graves, vous devriez identifier toutes les classes de contrôle qui sont liées à un ou plusieurs acteurs et les partager. Dans l'idéal, chaque classe de contrôle devrait interagir (via un objet frontière) avec un seul acteur ou avec aucun.

Exemple : gestion des appels

Prenez le cas d'utilisation Appel local. Nous pouvons identifier une classe de contrôle pour gérer l'appel lui-m^me.

Plusieurs acteurs impliqués dans un cas d'utilisation ont généralement besoin d'une classe de contrôle séparée

La classe de contrôle s'occupant des appels téléphoniques dans un système téléphonique peut rapidement être partagée en deux classes de contrôle, comportement A et comportement B ; une pour chaque acteur impliqué.

Dans un appel téléphonique local, il y a deux acteurs : abonné A qui émet l'appel, et abonné B qui le reçoit. L'abonné A soulève le combiné, écoute la tonalité, puis compose un nombre de chiffres, que le système stocke et analyse. Lorsque le système a reçu tous les numéros, il envoie une tonalité de retour d'appel chez l'abonné A et un signal d'appel chez l'abonné B. Lorsque l'abonné B décroche, la tonalité et le signal s'arrêtent, et la conversation entre les abonnés peut commencer. La conversation est terminée lorsque les deux abonnées raccrochent.

Deux comportements doivent être contrôlés: ce qui arrive chez l'abonné A et ce qui arrive chez l'abonné B. C'est pour cette raison que l'objet de contrôle d'origine a été partagé en deux objets de contrôle, comportement A et comportement B.

Il n'est pas nécessaire de partager une classe de contrôle si :

  • Vous êtes a peu près certain que le comportement des acteurs vis à vis des objets de la classe de contrôle ne changeront jamais, ou très peu.
  • Le comportement d'un objet de la classe de contrôle vis à vis d'un acteur est insignifiant comparé à son comportement vis à vis d'un autre acteur, un objet unique peut alors gérer le comportement. Fusionner les comportements de cette façon aura un effet négligeable sur la variabilité.

Classe entité icône de la classe entité

Une classe entité est une classe utilisée pour modéliser des informations et le comportement associé qui doit être stocké. Les objets entité (instances des classes entité) sont utilisés pour stocker et mettre à jour des informations sur certains phénomènes, comme un événement, une personne ou un objet de la vie réelle. Ils sont généralement persistants, ayant des attributs et des relations nécessaires pendant longtemps, parfois pour la durée de vie du système.

Un objet entité n'est habituellement pas propre à une réalisation d'analyse de cas d'utilisation ; parfois, un objet entité n'est pas propre au système lui-même. Les valeurs de ses attributs et des ses relations sont souvent données par un acteur. Un objet entité peut aussi être nécessaire pour aider à exécuter certaines tâches internes au système. Les objets entité peuvent avoir des comportements aussi complexes que ceux des autres stéréotypes objet. Toutefois, contrairement aux autres objets, ce comportement est fortement lié au phénomène que l'objet entité représente. Les objets entité sont indépendants vis à vis de l'environnement (les acteurs).

Les objets entité représentent les concepts clés d'un système en cours de développement. Les exemples types de classes entité dans un système bancaire sont Compte et Client. Dans un système géré en réseau, les exemples types sont Noeud et Liens.

Si le phénomène que vous voulez modéliser n'est pas utilisé par une autre classe, vous pouvez le modéliser comme un attribut d'une classe entité, ou même comme une relation entre des classes entité. En revanche, si le phénomène est utilisé par une autre classe dans le modèle de conception, vous devez le modéliser comme une classe.

Les classes entité fournissent un autre point de vue permettant de comprendre le système car elles montrent la structure logique des données, ce qui peut vous aider à comprendre ce que le système est supposé offrir à ses utilisateurs.

Identification des classes entité

Les classes entité représentent des réserves d'informations du système; elles sont généralement utilisées pour représenter les concepts clés que le système gère. Les objets entité sont fréquemment passifs et persistants. Leur principale responsabilité est de stocker et de gérer les informations dans le système.

Des sources d'inspiration fréquentes pour les classes entité sont le glossaire (développé pendant les exigences) et un modèle du domaine métier (développé pendant la modélisation métier, si une modélisation métier a été réalisée).

Restrictions d'utilisation d'association de stéréotypes

Restrictions pour les classes frontière

Les associations suivantes sont autorisées :

  • Les associations de communication entre deux classes frontière, par exemple, pour décrire la façon dont une fenêtre spécifique est liée à d'autres objets frontière.
  • Les associations de communication ou d'abonnement entre une classe frontière et une classe entité, car les objets frontières peuvent avoir besoin de garder une trace de certains objets d'entité entre les actions dans l'objet frontière, ou d'être informés des changements d'état dans l'objet entité.
  • Les associations de communications entre une classe frontière et une classe de contrôle, de façon à ce qu'un objet frontière puisse déclencher un comportement particulier.

Restrictions pour les classes de contrôle

Les associations suivantes sont autorisées :

  • Les associations de communication ou d'abonnement entre une classe de contrôle et des classes entité, car les objets de contrôle peuvent avoir besoin de garder une trace de certains objets entité entre les actions dans l'objet de contrôle, ou d'être informés des changements d'état dans l'objet entité.
  • Les associations de communication entre les classes de contrôle et les classes frontière, permettant que les résultats du comportement appelé soient communiqués.
  • Les associations de communication entre les classes de contrôle, permettant la construction de schémas de comportement plus complexes.

Restrictions pour les classes entité

Les classes entité ne devraient faire l'objet d'associations (de communication ou d'abonnement) qu'avec d'autres classes entité. Les objets de classe entité ont souvent une durée de vie courte. Au contraire, les objets des classes entité des classes frontières ont généralement une durée de vie courte. D'un point de vue architectural, il est préférable de limiter la visibilité qu'un objet entité a de son environnement. De cette façon, le système est plus facile à changer.

Récapitulatif des restrictions

De/vers
(navigabilité)

Frontière

Entité

Contrôle

Frontière

communication

communication

abonnement

communication

Entité

communication

abonnement

 

Contrôle

communication

communication

abonnement

communication

Combinaisons valides d'associations de stéréotypes

Renforcement de la cohérence

  • Lorsqu'un nouveau comportement est identifié, vérifiez si une classe existante n'a pas les mêmes responsabilités. Réutilisez-la lorsque cela est possible. Il faut attendre d'être certain qu'il n'y a pas d'objet pouvant exécuter le comportement avant de créer de nouvelles classes.
  • Une fois les classes identifiées, assurez-vous qu'elles ont des responsabilités cohérentes. Lorsque les responsabilités sont disjointes, diviser l'objet en deux ou plusieurs classes. Faites la mise à jour des diagrammes d'interaction en conséquence.
  • Si une classe est partagée car des responsabilités disjointes apparaissent, examinez les collaborations dans lesquelles la classe joue un rôle pour voir si la collaboration a besoin d'être mis à jour. Mettre la collaboration à jour si nécessaire.
  • Une classe avec une seule responsabilité n'est pas un problème en soi, mais on devrait réfléchir à son utilité. Préparez-vous à interroger et à justifier l'existence de toutes les classes.