Ejemplos de diagramas de casos de uso
Dos diagramas de casos de uso de sistemas que todo el mundo entiende, más uno dibujado mal a propósito, porque el error que arruina la mayoría de estos diagramas se reconoce más fácil de lo que se define.
8 min de lecturaUML 2.5.112 de 35
01Example 1: a library system
The library is the standard first example for a reason: everybody already knows the domain, so the only thing left to look at is the notation. Two actors, five use cases, and a boundary that says which of them the software is responsible for.
Notice what the ellipses are. Borrow book is a goal - a member wants to leave with a book - and it stays a goal whether the counter is a person, a self-service kiosk or an app. That independence from mechanism is the test for a use case: if replacing the interface would change the label, the label is a step.
Two relationships are doing real work. Check membership is included by Borrow book, meaning it always happens as part of it and the arrow points from the borrower to the included behaviour. It has no actor of its own, and that is correct - nobody arrives at the library wanting their membership checked. Pay overdue fine extends Return book: it happens only sometimes, and the arrow points the other way, from the optional behaviour into the base.
02Example 2: an online store, with an external system
The second example adds the piece most first diagrams leave out: a system you depend on and do not control.
The Payment gateway is a secondary actor. It initiates nothing - the customer starts everything on this diagram - but the system calls out to it, so it belongs outside the boundary with a line into the use case that needs it. Drawing it is how a use case diagram earns its keep in a scoping conversation: the boundary now shows exactly which behaviour you are on the hook for and which you are buying.
Apply discount code extends Place order because most orders do not have one. If nearly every order did, it would be an include instead. The question is not whether the behaviour is important, it is whether it always happens.
Four ellipses is a reasonable size. A real store has hundreds of behaviours, and the diagram does not grow to match - you draw one per conversation, scoped to the question being asked, which is the discipline scoping a model is about.
03Example 3: the same notation used badly
Most bad use case diagrams are bad in exactly one way, and it is worth seeing once.
Four ellipses, one actor, a boundary, no notation errors at all - and the diagram is worthless. Every label is a step in a user interface rather than a goal a person has. Nobody wants to enter a username; they want to log in, and even that is usually only in service of something else.
The whole diagram collapses to a single use case, and the four steps belong in its text description or, if the branching genuinely matters, in an activity diagram. That is the standard repair: sequence goes to activity, goals stay here.
04Adapting these to your system
The two good diagrams above are the same diagram with different nouns, which is the useful thing about the notation - once the shape is in your hand, the next one takes ten minutes.
Reach for it when
- Goals a user would name, phrased as verb plus object: place order, borrow book.
- A boundary drawn around exactly one system, with actors outside it.
- Secondary actors for every external service the system calls, so dependencies are visible.
- Include for behaviour that always happens; extend for behaviour that sometimes does.
Reach for something else when
- Interface steps - click, enter, select, submit. They are not goals.
- CRUD sprayed across the diagram: create, read, update and delete a thing is one use case, not four.
- Plain lines between two ellipses. Only include, extend and generalization are legal there.
- More than about a dozen ellipses. Split by actor or by subsystem instead.
05What to remember
In one line each
- 01A use case is a goal that survives an interface redesign. If the label would change, it is a step.
- 02Include points from the base to the always-included behaviour; extend points from the optional behaviour back to the base.
- 03Included use cases have no actor of their own, and that is correct.
- 04Secondary actors are what makes the diagram useful in a scoping conversation.
- 05Three to a dozen ellipses. Past that, the diagram has become a list of screens.
06Preguntas frecuentes
¿Cuál es un buen ejemplo de diagrama de casos de uso?
Un sistema de biblioteca: un Socio busca en el catálogo, presta y devuelve libros; un Bibliotecario atiende el mostrador de esos mismos dos; prestar incluye comprobar la membresía; y pagar una multa extiende devolver. Dos actores, cinco elipses y una frontera bastan.
¿Iniciar sesión es un caso de uso?
Normalmente no por sí solo. Nadie abre una aplicación para iniciar sesión: inicia sesión para hacer otra cosa, y esa otra cosa es el objetivo. Dibújelo como caso de uso incluido cuando varios objetivos lo exijan de verdad; en otro caso, déjelo fuera.
¿Cuántos casos de uso debe tener un diagrama?
Entre tres y una docena. Menos de tres y habría bastado una frase; más de una docena y las elipses son pasos en vez de objetivos, o la frontera del sistema se trazó alrededor de dos sistemas.
¿Pueden dos casos de uso unirse con una asociación simple?
No. Las asociaciones van solo entre un actor y un caso de uso. Entre dos casos de uso lo legal es include, extend y generalización; una línea simple entre dos elipses es la señal de que alguien dibuja una secuencia de pasos en lugar de un conjunto de objetivos.
¿Qué es un actor secundario en un diagrama de casos de uso?
Una parte externa a la que el sistema llama, no una que inicie nada: una pasarela de pago, un proveedor de identidad, un servicio de correo. Se dibuja como actor al otro lado de la frontera y es la parte que muestra de qué depende sin controlarlo.
Lecturas relacionadas