Archyno

Plantillas

Plantilla de diagrama de casos de uso UML

Dos actores, una frontera del sistema y cuatro casos de uso con include y extend bien dibujados: el diagrama de alcance que un documento de requisitos necesita de verdad.

Notación: UML 2.5.1Diagrama: Diagrama de casos de uso

System«include»«extend»CustomerAdministratorPlace orderTake paymentApply discountTrack orderManage catalogue
La plantilla al abrirse. La frontera es el elemento que casi todos los borradores olvidan.

Abre esta plantilla en Archyno

Se abre como un modelo editable, no como una imagen. Cámbialo en el navegador y expórtalo a PNG, SVG, Mermaid, XMI o un fichero Sparx .qea.

Abrir la plantilla

Qué hay en este diagrama

Frontera del sistema
El rectángulo. Todo lo de dentro te toca construirlo.
Customer
El actor principal, el que tiene un objetivo. Renómbralo al tuyo.
Administrator
Un actor secundario. Bórralo si solo importa un rol.
Place order
El caso de uso a nivel de objetivo. Uno por cosa que el actor quiere.
«include»
Comportamiento que siempre corre, extraído del caso base.
«extend»
Comportamiento condicional. La flecha apunta al caso que extiende.

Cómo hacerlo tuyo

  1. Nombra cada caso con un verbo y desde el actor: «Realizar pedido», no «Procesamiento de pedidos».
  2. Dibuja la frontera alrededor de lo que construyes y deja fuera a todos los actores.
  3. La flecha include sale del caso base; la flecha extend apunta hacia él.
  4. Borra todo caso que sea un paso y no un objetivo: iniciar sesión rara vez lo es.
  5. Para sobre los ocho óvalos. Un diagrama de casos de uso es un índice, no el contenido.

Preguntas frecuentes

¿Qué diferencia hay entre include y extend?

Include es comportamiento que el caso base ejecuta siempre, extraído para que dos casos lo compartan, y su flecha va del caso base al incluido. Extend es comportamiento que solo corre bajo una condición, y su flecha va del caso que extiende de vuelta al caso base.

¿Los actores van dentro de la frontera del sistema?

No. La frontera encierra aquello que te toca construir, y un actor está por definición fuera: una persona, otro sistema o un reloj. Meter un actor dentro es el error más común en estos diagramas, porque afirma en silencio que estás construyendo al usuario.

¿Cuánto detalle debe tener un diagrama de casos de uso?

Muy poco. Existe para nombrar los objetivos y mostrar quién los tiene, y el detalle va en el texto de los casos de uso debajo. Ocho óvalos son un diagrama sano; treinta son un diagrama que nadie lee y un alcance que nadie aprobó.

Lee la notación

Todas las plantillas