Diagramas de casos de uso UML

Un diagrama de casos de uso es un mapa del alcance. Nombra a las personas y sistemas que interactúan con lo que estás construyendo, los objetivos con los que llegan, y la línea entre dentro y fuera. Eso es todo lo que hace, y su contención es precisamente el punto.

No dice nada del orden. Nada de pantallas, campos ni algoritmos. Nada de cómo funciona nada. Cada una de esas cosas es otro diagrama, y la tentación de colarlas en este es lo que produce los diagramas de casos de uso desbordados e inútiles que le dieron mala fama a la notación.

Nadie te da la lista. El diagrama de arriba parece obvio una vez dibujado y no lo era en absoluto antes; el hueco entre la página en blanco y esa imagen son cuatro preguntas que se pueden hacer en una sala en veinte minutos.

1. ¿Quién inicia algo aquí? Cada uno es candidato a actor principal. Pregunta por el rol y no por el nombre: quien dijo «eso lo hago yo» es un portador de un rol que le sobrevivirá.
2. ¿Quién o qué recibe algo sin pedirlo? Informes, ficheros, notificaciones, procesos de liquidación. Son los actores de apoyo al lado derecho de la frontera, y son la mitad del diagrama que a la mayoría de los primeros borradores le falta.
3. ¿Qué tiene que estar ahí para que esto funcione? Proveedores de pago, servicios de identidad, el mainframe, un motor antifraude. Cualquier cosa por la que abrirías un ticket a otro equipo está fuera de la frontera y pertenece al diagrama: dibujarlo suele ser el momento en que alguien se da cuenta de que la dependencia nunca se acordó.
4. ¿Qué ocurre porque ha pasado el tiempo? Una conciliación nocturna, un vencimiento a catorce días, una facturación mensual. El tiempo es un actor, dibujado como monigote etiquetado Clock o Scheduler, y los procesos que lo omiten acaban con casos de uso que aparentemente nadie inicia.

Después nombra cada objetivo desde el lado del mostrador del actor, con el verbo primero, en su vocabulario: Submit payment, no Payment submission handling y desde luego no PaymentController. Si el nombre solo tiene sentido para quien ha visto el código, es un paso dentro de un caso de uso y no un caso de uso.

Estos dos son la razón de que los diagramas de casos de uso se dibujen mal. Ambos son flechas discontinuas con una palabra clave, y apuntan en direcciones opuestas.

«include» apunta del caso base a lo que siempre hace. Léelo como «llama a». En el diagrama de arriba, Submit payment incluye Authorize payment: no se puede enviar sin autorizar. Existe para factorizar comportamiento compartido por varios casos, y por eso mismo Refund payment también lo incluye.

«extend» apunta del extra opcional de vuelta al caso base. Léelo como «puede interrumpir». Log audit trail extiende Refund payment: las devoluciones funcionan sin él, y ocurre bajo cierta condición. El caso base no sabe que sus extensiones existen.

El diagrama es el índice. De lo que realmente se construye es de la descripción del caso de uso detrás de cada elipse, y un proyecto que dibuja el diagrama y nunca escribe las descripciones ha producido una imagen del trabajo en vez de una especificación. Justo de esta parte la notación no dice nada, y por eso tantos equipos se quedan en el dibujo.

Hay tres profundidades útiles, y elegir es una decisión de proyecto, no de modelado. Una descripción breve son dos frases en el backlog. Una informal es un párrafo por escenario. Una completamente desarrollada tiene los campos de abajo y compensa para el puñado de casos que llevan dinero o riesgo reales.

• Nombre. La etiqueta de la elipse, verbo primero: Authorize payment.
• Actor principal. Quien quiere el resultado. Merchant.
• Interesados e intereses. A quién más le importa y qué necesita de ello. El adquirente quiere un código de autorización válido; el equipo antifraude quiere el intento registrado tanto si sale bien como si no. En este campo aparecen la mayoría de los requisitos que se escapan.
• Precondiciones. Qué es ya cierto antes de empezar: el comerciante está autenticado, el pedido existe. No una lista de pasos, una lista de garantías.
• Escenario principal de éxito. El camino feliz numerado, paso del actor y luego paso del sistema, en el lenguaje del negocio. Entre cinco y doce pasos; más, y el caso de uso en realidad son dos.
• Extensiones. Numeradas según el paso del que se ramifican -4a, 4b, 7a- cada una con su condición y qué ocurre. Este es el campo que justifica el formato, porque es un recordatorio sistemático de cada forma en que el camino feliz falla.
• Postcondiciones. Qué es cierto después, en éxito y en cada fallo. «Se registra una autorización y los fondos quedan retenidos» se puede probar de una forma en que «el pago se procesa» no.

Desarrollado en pequeño para Authorize payment: el escenario principal es (1) el comerciante envía el pago, (2) el sistema valida el total del pedido, (3) el sistema pide autorización al adquirente, (4) el adquirente devuelve una aprobación, (5) el sistema registra la retención y confirma. El trabajo está en las extensiones -3a el adquirente no responde, 4a el adquirente rechaza, 4b el adquirente pide verificación adicional- y cada una es una conversación que si no se tendría seis semanas después en un triaje de defectos.

Un diagrama de casos de uso útil cabe en una página y tiene entre tres y diez elipses. Es un índice, no el libro. El detalle pertenece a las descripciones -el flujo principal numerado y sus alternativas- o, si el flujo se ramifica lo bastante como para dibujarlo, a un diagrama de actividad por caso.

1. Descomposición funcional. Veinte elipses nombradas según botones. Los casos de uso son objetivos; si no es algo que un actor quiere, no pertenece aquí.
2. Actores nombrados según personas o cargos del organigrama. Modela el rol. Una persona puede ser varios actores, y un actor puede ser un proceso por lotes.
3. Flechas «include» y «extend» invertidas. Apuntan en sentidos opuestos. Aplica la prueba de eliminación de arriba.
4. Actores dentro de la frontera. La frontera es lo que construyes. Un actor está por definición fuera de ella.
5. Secuencia implicada por la posición vertical. Un diagrama de casos de uso no tiene eje temporal. Nada en la disposición dice qué ocurre primero.