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