Comprar por Internet, renovar un préstamo y reservar una sala son objetivos que un sistema puede ayudar a cumplir. Un caso de uso explica la interacción necesaria para alcanzar un resultado, incluidas las alternativas cuando algo cambia o falla.
UML significa Unified Modeling Language, o lenguaje unificado de modelado. Permite expresar modelos mediante una notación común; no es por sí mismo una metodología de desarrollo. Los casos de uso ayudan a hablar de requisitos y resultados observables, sin decidir todavía cómo programarlos. [1][2]
10 ejemplos de casos de uso completos
Estas fichas describen sistemas didácticos con reglas explícitas. Cada una distingue objetivo, condiciones iniciales, pasos, alternativas y estado final. La ficha textual complementa al diagrama: los óvalos no muestran por sí solos todos esos detalles. [4]
EJEMPLO 01 · Objetivo completo y pago externo
Comprar por Internet
Sistema y límite: Tienda en línea; el servicio bancario queda fuera de su límite.
Actores: Cliente y servicio bancario. El comercio es la organización propietaria de la tienda, no un actor adicional por ese solo hecho.
Objetivo: Obtener un pedido confirmado de los productos seleccionados.
Precondiciones: El cliente puede acceder a la tienda y al catálogo. Este ejemplo admite compra como invitado y pago con tarjeta mediante un servicio externo.
Disparador: El cliente decide comprar un producto del catálogo.
Flujo principal
El cliente consulta el catálogo; la tienda muestra productos, precios y disponibilidad.
El cliente elige un producto y una cantidad. La tienda guarda el identificador del producto y su cantidad en el carrito, y actualiza el número de unidades y el importe. El proceso permite añadir o quitar productos.
El cliente solicita realizar el pago. La tienda pide los datos de entrega y muestra el resumen, incluidos los gastos aplicables. Comprueba la disponibilidad antes de continuar.
El cliente acepta el resumen y continúa al servicio de pago. Introduce allí los datos solicitados y pulsa Pagar; ese clic todavía no confirma el pedido.
La tienda solicita la autorización a través del servicio bancario y recibe una respuesta. En este flujo, el servicio autoriza el pago.
La tienda registra el pedido confirmado con un identificador y muestra el resultado al cliente.
Alternativas
Sin existencias al revisar el carrito: la tienda identifica el producto y pide modificar la selección. No inicia el pago de ese resumen.
Pago rechazado: la tienda comunica el rechazo y conserva el carrito para que el cliente pueda decidir qué hacer. No registra un pedido confirmado.
Respuesta de pago pendiente o no recibida: la tienda conserva una referencia y muestra «Pendiente de confirmación». Un tiempo de espera agotado no demuestra que no haya habido cargo; no presenta el intento como éxito ni induce a repetirlo a ciegas.
Cancelación antes de enviar el pago: el recorrido termina sin pedido confirmado. Si ya se envió, hace falta conocer su estado y aplicar el proceso de cancelación correspondiente; cerrar una ventana no revierte un cargo.
Poscondiciones: Éxito: pedido confirmado, identificador y autorización asociados. Rechazo o cancelación previa al pago: sin pedido confirmado. Incertidumbre de pago: operación pendiente identificable, sin mostrar una confirmación falsa.
Cómo interpretarlo: La compra alcanza un resultado observable; «pulsar Pagar» es un paso, no la poscondición. En el diagrama 1, Gestionar autorización es un comportamiento incluido en la compra con tarjeta. Un fallo al registrar el pedido tras autorizar el pago debe quedar pendiente de resolución, no mostrarse como compra completada.
EJEMPLO 02 · Consulta sin cambio de estado
Consultar un catálogo
Sistema y límite: Catálogo público de una tienda.
Actores: Visitante.
Objetivo: Encontrar productos que cumplan unos criterios.
Precondiciones: El catálogo está publicado; no se exige una cuenta.
Disparador: El visitante escribe un término o elige un filtro.
Flujo principal
El visitante indica categoría y rango de precio.
El sistema valida los criterios y consulta el catálogo.
El sistema muestra los resultados y el visitante abre la ficha de un producto.
Alternativas
Si no hay coincidencias, muestra una lista vacía y permite modificar los filtros: una búsqueda sin resultados no es necesariamente un fallo técnico.
Si el precio mínimo supera al máximo, solicita corregir el rango sin ejecutar esa búsqueda.
Si la consulta no está disponible, comunica el fallo sin inventar productos.
Poscondiciones: Se muestran resultados o un mensaje que explica por qué no pueden mostrarse. No se crea un pedido ni se modifica el catálogo.
Cómo interpretarlo: Un caso de uso puede aportar información sin cambiar los datos de negocio. Consultar puede existir como objetivo independiente aunque forme parte de un recorrido de compra más amplio.
EJEMPLO 03 · Regla de elegibilidad y disponibilidad
Solicitar el préstamo de un libro
Sistema y límite: Servicio de préstamos de una biblioteca con entrega mediante un terminal.
Actores: Lector.
Objetivo: Obtener un ejemplar en préstamo con fecha de devolución.
Precondiciones: El lector está identificado y el ejemplar está registrado. La elegibilidad se comprueba durante el caso.
Disparador: El lector solicita llevarse un ejemplar.
Flujo principal
El lector identifica el ejemplar en el terminal.
El sistema comprueba que la cuenta puede tomar préstamos, que no supera el límite y que el ejemplar está disponible.
El sistema registra el préstamo y su fecha de devolución.
El terminal muestra la confirmación al lector.
Alternativas
Cuenta bloqueada o límite alcanzado: se explica el motivo y no se registra el préstamo.
Ejemplar no disponible al confirmar: se informa de ello sin asignarlo al lector.
Poscondiciones: Éxito: préstamo activo asociado al lector y ejemplar marcado como prestado. Rechazo: no se crea el préstamo ni se cambia su disponibilidad por esta solicitud.
Cómo interpretarlo: Estar identificado es una precondición de este modelo. No hace falta dibujar «include Iniciar sesión» si el inicio de sesión ya ocurrió antes de solicitar el préstamo.
EJEMPLO 04 · Alternativa que impide el objetivo
Renovar un préstamo
Sistema y límite: Portal de la biblioteca.
Actores: Lector.
Objetivo: Ampliar el plazo de un préstamo propio.
Precondiciones: Lector identificado y préstamo propio activo.
Disparador: El lector solicita renovar el préstamo.
Flujo principal
El sistema muestra el préstamo y la fecha vigente.
El lector pide la renovación.
El sistema comprueba que no hay una reserva pendiente de otro lector y que las reglas permiten renovar.
El sistema registra la nueva fecha y la muestra.
Alternativas
Otro lector ha reservado el ejemplar: rechaza la renovación y conserva la fecha vigente.
Se alcanzó el máximo de renovaciones permitido: informa del motivo y no amplía el plazo.
Poscondiciones: Éxito: nueva fecha de devolución registrada. Rechazo: fecha anterior intacta.
Cómo interpretarlo: El rechazo de la renovación es un flujo alternativo del mismo objetivo; no obliga a inventar otro caso de uso llamado «Mostrar error».
EJEMPLO 05 · Cupo y solicitud duplicada
Inscribirse en un taller
Sistema y límite: Portal de talleres de un centro cultural.
Actores: Participante.
Objetivo: Conseguir una plaza en un taller.
Precondiciones: Participante identificado y taller con inscripciones abiertas.
Disparador: El participante solicita inscribirse.
Flujo principal
El sistema muestra horario y requisitos del taller.
El participante confirma la solicitud.
El sistema comprueba requisitos, ausencia de inscripción previa y disponibilidad en el momento de registrar.
El sistema registra una inscripción y muestra su identificador.
Alternativas
No quedan plazas: informa de que no hay cupo y no registra una inscripción confirmada.
Ya existe una inscripción del participante: muestra la existente, sin crear otra ni consumir otra plaza.
Se cerraron las inscripciones antes de registrar: comunica el cierre y no confirma la solicitud.
Poscondiciones: Éxito: exactamente una inscripción del participante en el taller. Solicitud duplicada: se conserva la inscripción existente. Sin cupo o cierre: no se añade una inscripción.
Cómo interpretarlo: La poscondición expresa qué debe cumplir el sistema. El diagrama no resuelve por sí mismo dos peticiones simultáneas; la implementación debe garantizar la regla de cupo.
EJEMPLO 06 · Repetición de una operación
Cancelar una reserva
Sistema y límite: Portal de reservas de salas de estudio.
Actores: Persona que reservó.
Objetivo: Liberar una reserva propia antes de su inicio.
Precondiciones: Persona identificada y reserva propia existente.
Disparador: La persona solicita cancelar la reserva.
Flujo principal
El sistema muestra los datos y el estado de la reserva.
La persona confirma la cancelación.
El sistema comprueba que la reserva está activa y que todavía se puede cancelar.
El sistema marca la reserva como cancelada y libera su intervalo.
Alternativas
La reserva ya está cancelada: muestra ese estado y no realiza una segunda liberación.
La reserva ya comenzó y la norma del centro no admite cancelación: rechaza la operación y conserva el estado.
Poscondiciones: Éxito: reserva cancelada e intervalo disponible. Repetición: mismo estado cancelado, sin efectos duplicados. Fuera de plazo: estado previo conservado.
Cómo interpretarlo: No se debe definir «reserva activa» como precondición si se quiere incluir aquí la repetición sobre una reserva ya cancelada. La existencia de la reserva basta; su estado se evalúa durante el flujo.
EJEMPLO 07 · Servicio externo y credencial caducada
Recuperar el acceso a una cuenta
Sistema y límite: Portal de usuarios con recuperación mediante correo.
Actores: Persona solicitante y servicio de correo.
Objetivo: Establecer una nueva contraseña tras acreditar el control del medio de recuperación.
Precondiciones: El servicio de recuperación está disponible; el resultado no presupone que el correo escrito corresponda a una cuenta.
Disparador: La persona solicita recuperar el acceso.
Flujo principal
La persona indica su dirección de correo.
El portal muestra una respuesta genérica y, si procede, solicita al servicio de correo enviar un enlace de recuperación de uso limitado.
La persona abre un enlace válido e introduce una nueva contraseña que satisface las reglas del portal.
El portal actualiza la credencial e invalida el enlace utilizado.
Alternativas
Dirección sin cuenta elegible: no cambia ninguna credencial; la respuesta pública sigue siendo genérica.
Enlace caducado o ya usado: rechaza el cambio y permite solicitar otro.
No puede entregarse el correo: no cambia la contraseña; no confunde haber solicitado el envío con su recepción.
Poscondiciones: Éxito: credencial actualizada y enlace utilizado invalidado. Cualquier rechazo previo a la actualización: credencial sin cambios.
Cómo interpretarlo: El servicio de correo es un actor de apoyo porque está fuera del portal e intercambia información con él. Esta ficha describe requisitos del recorrido, no una implementación completa de seguridad.
EJEMPLO 08 · Extensión de una compra
Añadir envoltorio de regalo
Sistema y límite: Tienda en línea del ejemplo 1.
Actores: Cliente.
Objetivo: Añadir un envoltorio disponible a un producto de la compra.
Precondiciones: La compra está en el punto de extensión «antes de confirmar el resumen» y contiene al menos un producto apto.
Disparador: El cliente solicita envoltorio en ese punto.
Flujo principal
La tienda muestra opciones y precios de envoltorio para los productos aptos.
El cliente elige una opción.
La tienda la añade al resumen y actualiza el total antes de que el cliente acepte el pago.
El control vuelve a la compra para confirmar el resumen.
Alternativas
El cliente descarta el envoltorio: vuelve a la compra sin añadirlo.
La opción dejó de estar disponible: la tienda informa y permite seguir sin envoltorio o elegir otra opción disponible.
Poscondiciones: La compra continúa con el envoltorio elegido y su importe, o sin él. Todavía no hay pedido confirmado solo por completar esta extensión.
Cómo interpretarlo: La relación «extend» va de Añadir envoltorio a Realizar compra. La compra base tiene sentido y puede completarse sin esta extensión. En este ejemplo la condición es que el cliente la solicite; no todos los comportamientos opcionales necesitan modelarse como casos separados.
EJEMPLO 09 · Generalización de actores
Reservar una sala como docente
Sistema y límite: Portal de una biblioteca escolar.
Actores: Docente, especialización del actor Lector en este modelo.
Objetivo: Reservar una sala para una actividad docente.
Precondiciones: Docente identificado con autorización para reservar salas y horario de reservas abierto.
Disparador: El docente solicita una sala para una fecha y un intervalo.
Flujo principal
El docente indica fecha, intervalo y aforo necesario.
El portal muestra salas compatibles.
El docente selecciona una; el portal comprueba nuevamente su disponibilidad.
El portal registra la reserva y devuelve un identificador.
Alternativas
No hay sala compatible o la elegida ya se ocupó: informa y permite escoger otro intervalo sin confirmar una reserva.
Se solicita un intervalo inválido: pide corregirlo antes de buscar.
Poscondiciones: Éxito: reserva del docente para una sala e intervalo. Rechazo: no se añade una reserva.
Cómo interpretarlo: En el diagrama 3, Docente hereda la participación de Lector en Solicitar préstamo y añade Reservar sala. Es una decisión de este portal: no significa que toda persona docente sea siempre un tipo de lector en cualquier sistema.
EJEMPLO 10 · Actor externo no humano
Actualizar el estado de un envío
Sistema y límite: Seguimiento de pedidos de una tienda.
Actores: Sistema del transportista.
Objetivo: Registrar en la tienda un cambio comunicado sobre un envío.
Precondiciones: Integración identificada y autorizada; el mensaje se puede recibir. La existencia del envío y la validez del cambio se comprueban dentro del caso.
Disparador: El transportista comunica un evento de seguimiento.
Flujo principal
El transportista envía identificador de envío, identificador de evento y nuevo estado.
La tienda valida el mensaje y localiza el envío.
La tienda comprueba que el evento no se ha aplicado y que la transición está permitida.
La tienda registra el evento, actualiza el seguimiento y confirma la recepción.
Alternativas
Evento duplicado: confirma que ya se recibió sin aplicar de nuevo sus efectos.
Envío desconocido o cambio no permitido: rechaza el cambio y deja constancia del motivo para su tratamiento.
Mensaje inválido: no modifica el estado del envío.
Poscondiciones: Éxito: evento registrado una sola vez y seguimiento actualizado. Duplicado: sin efectos adicionales. Rechazo: estado del envío intacto.
Cómo interpretarlo: El actor puede ser otro sistema. Una base de datos interna del seguimiento no se convierte en actor externo por almacenar el evento.
3 diagramas de casos de uso UML
Los óvalos representan casos de uso. El rectángulo marca el sistema modelado y los actores quedan fuera. Un actor es un rol: puede corresponder a una persona o a otro sistema. Estos diagramas seleccionan relaciones concretas; no son diagramas de flujo ni inventarios completos de todas las funciones de una tienda o biblioteca. [3]
1. Compra con un comportamiento incluido
En pantallas pequeñas, desplaza el diagrama horizontalmente. También puedes enfocarlo con Tab y usar las flechas.
El rectángulo delimita el software de la tienda. Cliente y servicio bancario son actores externos; las líneas continuas expresan participación, no una secuencia. La flecha «include» sale de Realizar compra y llega a Gestionar autorización. La tienda solicita y procesa la respuesta; el servicio bancario decide la autorización. Este modelo describe el pago con tarjeta, no todos los medios de pago posibles. [5]
2. Envoltorio como extensión de la compra
En pantallas pequeñas, desplaza el diagrama horizontalmente. También puedes enfocarlo con Tab y usar las flechas.
La punta abierta señala el caso base, Realizar compra. La extensión aporta el envoltorio en el punto «antes de confirmar el resumen», definido por la compra, cuando el cliente lo solicita. La línea discontinua de la nota expresa la condición de este ejemplo. El caso base puede terminar sin ejecutar la extensión; el dibujo no representa el orden de todas las pantallas. [6]
3. Un actor especializado hereda la participación
En pantallas pequeñas, desplaza el diagrama horizontalmente. También puedes enfocarlo con Tab y usar las flechas.
La generalización va del actor específico Docente al actor general Lector: línea continua y triángulo hueco orientado hacia Lector. Docente hereda la participación de Lector en Solicitar préstamo y tiene además la asociación con Reservar sala. No representa una jerarquía de cargos ni el orden de ejecución de dos operaciones. [7]
Elementos y relaciones: qué significa cada uno
Diagrama y ficha cumplen funciones diferentes
Elemento
Qué expresa
Ejemplo
Actor
Rol externo al sistema que participa en una interacción.
Cliente o servicio bancario.
Límite del sistema
Qué software o sujeto se modela; no es el límite físico del edificio.
La tienda en línea, sin incluir el banco.
Caso de uso
Comportamiento orientado a un resultado de valor observable.
Realizar compra; se nombra con una acción y su objeto.
Precondición
Situación que se supone cumplida antes de comenzar.
Lector identificado.
Disparador
Hecho o solicitud que inicia el recorrido.
El lector pide renovar.
Flujo principal
Interacciones del escenario de éxito elegido.
Solicitar, comprobar y registrar renovación.
Alternativas
Desvíos, excepciones u otros resultados del mismo objetivo.
Renovación rechazada por una reserva pendiente.
Poscondición
Estado que queda al terminar; conviene distinguir éxito y otros desenlaces.
Fecha nueva registrada o fecha anterior conservada.
Los actores y casos aparecen en el diagrama; los pasos y condiciones se desarrollan en la ficha. UML no obliga a utilizar exactamente esta plantilla textual ni convierte cada paso en un óvalo. [2][4]
Asociación
La línea continua entre actor y caso indica participación. Aquí se dibuja sin flechas: no informa quién envía primero un mensaje ni el orden de los pasos.
«include»
El caso que incluye incorpora comportamiento definido por otro caso. La flecha discontinua con punta abierta va del primero al incluido. Sirve para expresar comportamiento requerido dentro del flujo correspondiente; no significa simplemente «una pantalla viene después de otra». [5]
«extend»
Un caso aporta comportamiento adicional en puntos de extensión definidos por el caso base. La flecha discontinua con punta abierta va de la extensión al caso extendido. El caso base se entiende por sí mismo. Puede haber condiciones de extensión, como la solicitud de envoltorio del ejemplo 8. [6]
Generalización
Relaciona un actor específico con otro más general; el específico hereda su participación. La línea continua termina en un triángulo hueco que apunta al general. Debe expresar una especialización válida en el modelo, no quién tiene mayor autoridad en una organización. [7]
Plantilla para escribir un caso de uso
Elige primero un objetivo del usuario, fija el límite del sistema y describe un recorrido completo. Después prueba qué ocurre si una condición falla o el usuario cambia de decisión.
Ver y copiar la plantilla
Nombre del caso:
Sistema y límite:
Actores:
Objetivo observable:
Precondiciones:
Disparador:
Flujo principal (actor → respuesta del sistema):
1.
2.
3.
Alternativas y punto del flujo donde ocurren:
Poscondición de éxito:
Estado final si se rechaza, cancela o queda pendiente:
Relaciones con otros casos, si aportan claridad:
Lee la poscondición antes de darlo por terminado: debe decir qué quedó registrado, mostrado o sin modificar. «El sistema funciona correctamente» no permite evaluar el resultado.
8 ejercicios para practicar
El sistema modelado es una tienda en línea. ¿El comercio propietario debe aparecer automáticamente como actor?
La compra termina con «el cliente pulsa Pagar». ¿Qué falta?
Añadir envoltorio extiende Realizar compra. ¿Cuál debe poder entenderse sin el otro?
Docente especializa Lector. ¿Dónde se coloca el triángulo de generalización?
Solicitar préstamo parte de un lector ya identificado. ¿Es obligatorio incluir Iniciar sesión?
Una búsqueda devuelve cero productos. ¿Eso incumple necesariamente su poscondición?
Se cancela dos veces la misma reserva. ¿Qué resultado debe describir la ficha del ejemplo 6?
Ver respuestas razonadas
No. El actor es un rol externo que interactúa con el sistema. El propietario de la tienda no es actor solo por ser propietario; un empleado que gestione pedidos sí podría desempeñar un rol externo al software.
La respuesta del pago y los estados finales: confirmación del pedido, rechazo o situación pendiente. Pulsar un botón no acredita una autorización ni un pedido registrado.
Del caso que incluye, Realizar compra, al comportamiento incluido, Gestionar autorización. Es discontinua y tiene punta abierta.
Realizar compra debe tener sentido sin el envoltorio. La flecha «extend» parte de Añadir envoltorio y apunta a Realizar compra; el punto de extensión pertenece a la compra.
En el extremo que apunta a Lector, el actor más general. Se dibuja una línea continua con triángulo hueco.
No. La identificación ya cumplida puede ser una precondición. Una relación «include» representa comportamiento incluido en la ejecución, no una condición que ya se cumplió antes.
No. Si el objetivo es consultar y la respuesta vacía es correcta, puede ser un resultado válido. Un fallo de conexión es otro escenario y debe distinguirse.
La primera cancelación libera el intervalo; la repetición mantiene la reserva cancelada sin liberar dos veces ni producir efectos duplicados. La ficha admite ese recorrido porque la precondición exige una reserva existente, no necesariamente activa.
Errores frecuentes
Acabar al pulsar un botón: Describe la respuesta y las poscondiciones; no confundas solicitud con resultado.
Poner al propio sistema como actor: Delimita primero el sujeto modelado. Sus componentes internos no son actores externos de ese mismo modelo.
Dibujar cada clic como un caso independiente: Busca objetivos con resultados; desarrolla los pasos en la ficha.
Dar por cumplida una condición que luego quieres comprobar: Si vas a describir su incumplimiento como alternativa, no la presupongas verdadera en la precondición.
Invertir «include» y «extend»: «include» apunta al comportamiento incluido; «extend» apunta al caso base extendido.
Usar flechas para contar pantallas: Las relaciones del diagrama no representan una secuencia temporal. Para eso puedes utilizar otros diagramas UML, como actividad o secuencia.
Llamar generalización a cualquier relación entre roles: El actor específico debe poder participar como el general dentro de ese modelo.
Olvidar los estados pendientes: Ante una respuesta externa desconocida, no inventes éxito ni rechazo: describe cómo queda identificada la operación.
