Discussion :

[dpochet]

Rebonjour.

Je me réfère à un exemple apparemment souvent utilisé en tutoriels de modélisation UML : l'ascenseur.

A l'évidence l'acteur principal est l'utilisateur de l'ascenseur.
Le use case principal est "changer d'étage" (mis à part les use case d'exception que pourraient être pour un gamin de dix ans : "appuyer sur les boutons d'appel pour faire ch.. le monde", ou pour un de vingt : "bloquer l'ascenseur entre deux étages avec la voisine de palier").

Or il est évident qu'un acteur "normal" dispose de moyens d'interaction avec le système, différents en fonction de la situation qu'il occupe à un moment donné.
Quand il est dans le couloir, il peut appeler l'ascenseur (en montée ou bien en descente pour les + sophistiqués), ou simplement attendre qu'il s'arrête à son étage (plus improbable sauf pour les bi-manchots au nez court*), et ensuite monter dans la cabine.
Quand il est dans la cabine, il peut par contre sélectionner un étage de destination, ou plusieurs (étourdi), ou même ne rien faire (cfr *; j'écarte volontairement l'usage du bouton "stop").

Ma question est : l'acteur dans le couloir doit-il, au niveau du diagramme use case, être représenté distinctement de celui dans la cabine (étant entendu bien sûr qu'il peut y avoir plusieurs acteurs en cabine et hors cabine, simultanément) ?
Si non :
- Va-t'on dans le usecase simplement associer l'acteur quelle que soit sa situation "géographique" (son état), à chaque action du système ou propre à lui, qu'il va devoir éventuellement mener pour changer d'étage (à savoir appeler la cabine, entrer dans l'habitacle, sélectionner l'étage de destination, attendre l'ouverture des portes au bon étage, sortir de l'habitacle) ?
- Dans quel diagramme UML va-t'on retrouver ces possibilités d'interaction distinctes avec le système, en fonction de l'état de l'utilisateur (dans ou hors cabine) ?

Merci pour vos lumières.

[bruno_pages]

bonjour,

même si c'est possible faire deux acteur distincts me semble un peu trop artificiels

je verrais plutôt un acteur tout en indiquant dans les pré requis des UCs si l'acteur est dans ou hors de l'ascenseur.

Un UC ne se limite pas à son dessin dans un diagramme d'UC, un UC est toujours accompagné d'un texte explicatif, et des rubriques comme pre/post conditions, exceptions etc sont classiques

[hegros]

Bonsoir

En fait tu peux toujours définir une hierarchie d'acteur. A priori qu'une personne soit à l'intérieur ou l'extérieur d'une cabine n'en fais pas moins un utilisateur du système en question.


A mon sens un seul acteur utilisateur suffirait en mettre 2 qui seraient des "spécialités" comme <utilisateur_cabine>,<utilisateur_couloir> me semble trop sophistisqué et marque peu d'interet à priori.

Un diagramme d'activité peut montrer ce qui se passe dans la cabine et en dehors. Avec une super-activité dedans et une superactivité dehors puis dans chaque super tu définis les activités possibles.

Cependant dans la description textuelle de l'UC tu peux fixer les pré-conditions : utilisateur dedans ou dehors ce reste étrange car à moins d'avoir le bras long comment appuyer sur un bouton d'un étage situé dans la cabine lorsqu'on se trouve dans le couloir