42. Trabajo integrador: construir el modelo de casos de uso de un sistema completo

42.1 Introducción

Este tema integra todo el recorrido del curso. El objetivo es construir un modelo de casos de uso completo para un sistema, aplicando identificación de actores, definición de alcance, diagramas, especificaciones textuales, reglas, flujos alternativos, trazabilidad y validación.

Un trabajo integrador no consiste en dibujar muchos óvalos ni en escribir documentación extensa sin criterio. Consiste en producir un modelo claro, útil y verificable, que permita entender qué debe hacer el sistema y por qué.

42.2 Sistema propuesto

Para el trabajo integrador se puede elegir un sistema real o ficticio. Algunos ejemplos posibles son una biblioteca digital, una plataforma de cursos, una tienda en línea, un sistema de turnos, una aplicación de reservas, un sistema de reclamos o una gestión de inventario.

Lo importante es que el sistema tenga varios actores, objetivos distintos, reglas de negocio y situaciones alternativas. Si el sistema es demasiado simple, no permitirá practicar todos los conceptos del curso.

42.3 Objetivo del trabajo

El objetivo es elaborar un conjunto coherente de casos de uso que describa el comportamiento funcional principal del sistema elegido. El resultado debe permitir que otra persona comprenda qué usuarios interactúan con el sistema, qué desean lograr, qué reglas se aplican y qué resultados se esperan.

El foco está en el análisis funcional, no en el diseño de pantallas, la arquitectura técnica ni el código.

42.4 Proceso completo del trabajo integrador

La imagen resume el camino de trabajo: elegir el sistema, definir el alcance, identificar actores, descubrir casos de uso, priorizarlos, dibujar el diagrama, especificar los casos principales, revisar reglas y flujos alternativos, validar con ejemplos y preparar la entrega final.

42.5 Paso 1: definir el alcance

Antes de identificar casos de uso, se debe aclarar qué hará el sistema y qué quedará fuera. Esta decisión evita que el modelo crezca sin control o incluya procesos que pertenecen a otros sistemas, áreas o personas.

Una buena definición de alcance puede expresarse con una breve descripción del sistema, una lista de funcionalidades incluidas y una lista de elementos excluidos.

42.6 Paso 2: identificar actores

Los actores se identifican observando quién usa el sistema, quién recibe resultados, quién administra información y qué sistemas externos interactúan con él.

Para cada actor conviene registrar su nombre, tipo, descripción y objetivos principales. No todos los usuarios individuales son actores diferentes; muchas veces varios usuarios comparten el mismo rol.

42.7 Paso 3: descubrir casos de uso

Cada caso de uso debe representar un objetivo completo y observable para un actor. Para descubrirlos, se pueden formular preguntas como: ¿qué necesita lograr este actor?, ¿qué información consulta?, ¿qué operación inicia?, ¿qué resultado espera?

Los nombres deben expresarse con verbo en infinitivo y objeto: Registrar préstamo, Solicitar turno, Realizar compra, Consultar pedido, Administrar catálogo.

42.8 Paso 4: priorizar

No todos los casos de uso tienen la misma importancia. Algunos son centrales para el negocio y otros son de soporte o administración. Priorizar ayuda a decidir cuáles deben especificarse con mayor detalle.

En el trabajo integrador conviene elegir entre tres y cinco casos de uso principales para desarrollar en profundidad.

42.9 Paso 5: construir el diagrama

El diagrama debe mostrar el límite del sistema, los actores externos y los casos de uso principales. También puede incluir relaciones como inclusión, extensión o generalización, siempre que aporten claridad.

Un diagrama útil es legible, no está saturado y permite comprender rápidamente qué actores interactúan con qué funcionalidades.

42.10 Paso 6: especificar casos de uso principales

Para cada caso de uso principal se debe escribir una especificación textual. Como mínimo debería incluir nombre, actor principal, objetivo, precondiciones, disparador, flujo principal, flujos alternativos, postcondiciones y reglas relacionadas.

La especificación debe ser precisa, pero también comprensible para usuarios, analistas, desarrolladores y testers.

42.11 Paso 7: definir reglas de negocio

Las reglas de negocio explican restricciones, políticas, cálculos o condiciones que el sistema debe respetar. Pueden estar dentro de un caso de uso o en una sección separada, siempre que sea fácil vincularlas con los pasos donde se aplican.

Una regla bien escrita evita ambigüedades y permite derivar pruebas más claras.

42.12 Paso 8: revisar flujos alternativos

Un caso de uso completo no describe solo el camino ideal. También debe contemplar errores, cancelaciones, datos inválidos, falta de permisos, información inexistente o servicios externos no disponibles.

Los flujos alternativos ayudan a que el sistema sea analizado en condiciones reales, no solo en una situación perfecta.

42.13 Paso 9: validar con ejemplos

Validar con ejemplos concretos permite comprobar si el caso de uso se entiende y si representa una necesidad real. Por ejemplo, se puede tomar un usuario, un dato de entrada, una condición especial y un resultado esperado.

Si el ejemplo no puede explicarse con el caso de uso escrito, probablemente falta información o existe una ambigüedad.

42.14 Entregables esperados

El trabajo integrador debería incluir:

• descripción general del sistema;
• alcance y límite del sistema;
• lista de actores;
• lista de casos de uso;
• diagrama general de casos de uso;
• especificación detallada de los casos principales;
• reglas de negocio relevantes;
• observaciones de validación y revisión.

42.15 Criterios de evaluación

42.16 Errores frecuentes

• Elegir un sistema demasiado pequeño para practicar todos los conceptos.
• Confundir actores con componentes internos del sistema.
• Nombrar casos de uso como pantallas o botones.
• Incluir demasiados detalles técnicos en la especificación.
• No describir flujos alternativos ni excepciones.
• Presentar un diagrama que no coincide con las especificaciones textuales.

42.17 Qué debes recordar de este tema

• El trabajo integrador debe mostrar comprensión completa del enfoque de casos de uso.
• El alcance, los actores y los objetivos deben estar alineados.
• El diagrama ofrece una vista general, pero la especificación textual aporta el detalle necesario.
• Las reglas y los flujos alternativos son esenciales para representar situaciones reales.
• Validar el modelo ayuda a detectar errores antes de diseñar o desarrollar.

42.18 Conclusión

Construir el modelo de casos de uso de un sistema completo permite integrar análisis, comunicación y validación de requisitos. El resultado no es solo un documento, sino una herramienta para que usuarios, analistas, desarrolladores y testers compartan una misma comprensión del sistema.

Con este trabajo se cierra el curso reforzando la idea central: los casos de uso son útiles cuando ayudan a explicar objetivos reales, límites claros, reglas concretas y comportamientos verificables.