Modèle de diagramme de cas d'utilisation UML
Deux acteurs, une frontière du système et quatre cas d'utilisation avec un include et un extend correctement tracés - le diagramme de périmètre dont un dossier d'exigences a besoin.
Notation: UML 2.5.1Diagramme: Diagramme de cas d'utilisation
Ouvrir ce modèle dans Archyno
Il s'ouvre comme un modèle modifiable, pas comme une image. Modifiez-le dans le navigateur, puis exportez en PNG, SVG, Mermaid, XMI ou fichier Sparx .qea.
Ouvrir ce modèleCe que contient ce diagramme
- Frontière du système
- Le rectangle. Tout ce qui est dedans est à construire.
- Customer
- L'acteur principal - celui qui a un but. À renommer selon le vôtre.
- Administrator
- Un acteur secondaire. Supprimez-le si un seul rôle compte.
- Place order
- Le cas au niveau du but. Un par chose que l'acteur veut faire.
- «include»
- Comportement toujours exécuté, sorti du cas de base.
- «extend»
- Comportement conditionnel. La flèche vise le cas qu'il étend.
Comment se l'approprier
- Nommez chaque cas par un verbe, du côté de l'acteur : « Passer commande », pas « Traitement des commandes ».
- Tracez la frontière autour de ce que vous construisez, et laissez chaque acteur dehors.
- La flèche include part du cas de base ; la flèche extend pointe vers lui.
- Supprimez tout cas qui est une étape et non un but - se connecter en est rarement un.
- Arrêtez-vous vers huit ovales. Un diagramme de cas d'utilisation est une table des matières.
Questions fréquentes
Quelle différence entre include et extend ?
Include est un comportement que le cas de base exécute toujours, sorti pour que deux cas le partagent, et sa flèche va du cas de base vers le cas inclus. Extend est un comportement qui ne s'exécute que sous condition, et sa flèche va du cas étendant vers le cas de base.
Les acteurs vont-ils dans la frontière du système ?
Non. La frontière entoure ce que vous êtes chargé de construire, et un acteur est par définition dehors : une personne, un autre système, ou une horloge. Mettre un acteur dedans est l'erreur la plus fréquente sur ces diagrammes, car cela affirme en silence que vous construisez l'utilisateur.
Quel niveau de détail pour un diagramme de cas d'utilisation ?
Très faible. Il sert à nommer les buts et à montrer qui les porte ; le détail appartient au texte des cas d'utilisation en dessous. Huit ovales font un diagramme sain ; trente font un diagramme que personne ne lit et un périmètre que personne n'a validé.
Lire la notation
Diagrammes de cas d'utilisation
Comment lire et dessiner un diagramme de cas d'utilisation UML : acteurs, frontière du système, associations, et les relations include et extend que l'on inverse le plus souvent.
Qu'est-ce que UML ?
UML en pratique : les quatorze types de diagrammes, la séparation entre structure et comportement, et comment choisir le bon diagramme pour la question que vous posez vraiment.
Diagrammes d'activité
Comment lire et dessiner un diagramme d'activité UML : actions, décisions et fusions, bifurcations et jointures, gardes, couloirs, et la différence entre un branchement et un vrai parallélisme.