La question n’est pas posée, mais notons qu’introduire les acteurs mènerait au diagramme suivant :
L’introduction des acteurs, fait apparaître que le cas d’utilisation Gestion commande
n’est associé à aucun acteur pour le déclencher. En réalité, ce type de cas englobant est souvent une erreur de conception. Ici, on préférera la solution suivante :
Il faut bien comprendre que les acteurs ne sont pas tout ce qui bouge. Ici, par exemple, le client n’est pas un acteur puisqu’il n’interagit pas directement pas avec la caisse : c’est le caissier qui enregistre les articles.
Les cas ne modélisent pas non plus les séquences d’action. L’ordre n’est pas représenté dans les diagrammes cas d’utilisation (mais il y aura d’autres diagrammes complémentaires pour le faire). Ainsi, le fait que l’on boucle sur les articles et qu’on sorte de là en signalant la fin n’est pas représenté explicitement, et surtout pas par des relations de type include
ou extend
. En effet, ces relations expriment des inclusions et pas des relations temporelles. Ici, l’enregistrement est modélisé simplement par un cas qui pourra se répéter, et un autre qu’on déclenchera quand le moment sera venu.
En outre, un diagramme de cas ne doit pas représenter la moindre des actions. Ici, par exemple, on définit un cas enregistrer article
qui inclut la saisie du numéro, de la quantité et l’affichage du libellé et du prix. Si ce n’est pas clair à la seule lecture du libellé du cas, rajouter une description textuelle.