Diagramas de casos de uso UML como código con PlantUML y VPasCode

Un diagrama de casos de uso UML muestra lo que ofrece un sistema y quién o qué interactúa con él. Con un flujo de trabajo de diagramas como código, la fuente del diagrama es texto plano: edite el texto, genere el diagrama y mantenga la fuente junto con la documentación del proyecto.

PlantUML admite diagramas de casos de uso. El editor VPasCode de Visual Paradigm proporciona un editor y vista previa de PlantUML, junto con funciones de generación y edición de diagramas asistidas por IA.

1. Lo que comunica un diagrama de casos de uso

Los diagramas de casos de uso se centran en el alcance del sistema y los objetivos del usuario, no la mecánica paso a paso de un flujo de trabajo. Un diagrama típicamente contiene:

• Límite del sistema: Un rectángulo que nombra el sistema que se está modelando.

• Actor: Un rol fuera del sistema que interactúa con él. Los actores pueden ser personas, organizaciones, dispositivos o sistemas externos.

• Caso de uso: Una capacidad o objetivo proporcionado por el sistema, generalmente mostrado como un óvalo y nombrado con una frase verbal, como “Realizar pedido”.

• Asociación: Una línea que muestra que un actor participa en un caso de uso.

• Relaciones de casos de uso: Incluir, extender y generalización.

Los actores representan roles, no individuos específicos. Un servicio de pago externo puede ser un actor si interactúa con el sistema que se está modelando.

Los diagramas de casos de uso son útiles para aclarar el alcance del sistema, discutir requisitos con las partes interesadas, identificar dependencias externas y proporcionar una visión compartida para el desarrollo y las pruebas. Acompáñelos con descripciones escritas de casos de uso cuando necesite detalles como precondiciones, pasos principales, flujos alternativos y resultados.

2. Relaciones de un vistazo

• Asociación actor–caso de uso: Una línea simple que indica interacción.

• <<incluir>>: El caso de uso que incluye siempre utiliza el comportamiento incluido. La flecha punteada apunta desde el caso de uso que incluye hacia el caso de uso incluido. Por ejemplo, realizar un pedido puede siempre incluir la autorización de pago.

• <<extender>>: Un caso de uso que extiende añade comportamiento a un caso de uso base bajo una condición. La flecha punteada apunta desde el caso de uso extendido hasta el caso de uso base. Por ejemplo, aplicar una promoción puede extender la colocación de un pedido.

• Generalización: Un actor o caso de uso especializado hereda de uno más general. La línea sólida con un triángulo hueco apunta hacia el elemento general.

Una distinción útil: incluir significa comportamiento requerido; extender significa comportamiento condicional añadido.

3. Esenciales de PlantUML

Un diagrama de PlantUML comienza con @startuml y termina con @enduml. Declara actores con actor, casos de uso con usecase y límites del sistema con rectangle. Los alias facilitan la referencia de elementos en las relaciones.

@startuml
dirección de izquierda a derecha

actor Cliente

rectangle "Tienda en línea" {
  usecase "Navegar productos" como Navegar
  usecase "Realizar pedido" como Realizar
}

Cliente --> Navegar
Cliente --> Realizar
@enduml

dirección de izquierda a derecha solicita a PlantUML que disponga el diagrama horizontalmente. PlantUML puede ajustar el diseño preciso a medida que cambia el diagrama.

4. Ejemplo: tienda en línea básica

@startuml
dirección de izquierda a derecha

actor Cliente
actor Administrador como Admin

rectángulo "Tienda en línea" {
  caso de uso "Navegar productos" como Navegar
  caso de uso "Realizar pedido" como Realizar
  caso de uso "Rastrear envío" como Rastrear
  caso de uso "Gestionar catálogo" como Gestionar
}

Cliente --> Navegar
Cliente --> Realizar
Cliente --> Rastrear
Admin --> Gestionar
@enduml

Los clientes navegan, realizan pedidos y rastrean envíos. El administrador gestiona el catálogo. El diagrama omite deliberadamente los pasos internos del procesamiento del pedido.

5. Ejemplo: incluir y extender

Supongamos que realizar un pedido siempre requiere autorización de pago, mientras que aplicar una promoción es opcional y condicional.

@startuml
dirección de izquierda a derecha

actor Cliente

rectángulo "Tienda en línea" {
  caso de uso "Realizar pedido" como Realizar
  caso de uso "Autorizar pago" como Pago
  caso de uso "Aplicar promoción" como Promoción
}

Cliente --> Realizar

Realizar ..> Pago : <<incluir>>
Promoción ..> Realizar : <<extender>>
@enduml

La Realizar ..> Pago flecha significa que “Realizar pedido” incluye el comportamiento de pago requerido. La Promoción ..> Realizar flecha significa que “Aplicar promoción” extiende “Realizar pedido” cuando se cumple su condición.

Documente la condición, por ejemplo, “el cliente ingresa un código de promoción válido”, en la descripción del caso de uso o en una nota.

6. Ejemplo: generalización de actores y sistemas externos

Un actor especializado hereda interacciones de un actor más general. Los servicios externos también pueden ser actores cuando interactúan con el sistema.

@startuml
dirección de izquierda a derecha

actor "Usuario" como Usuario
actor "Cliente registrado" como Cliente
actor "Pasarela de pago" como Pasarela

Cliente --|> Usuario

rectángulo "Tienda en línea" {
  caso de uso "Navegar productos" como Navegar
  caso de uso "Realizar pedido" como Realizar
  caso de uso "Procesar pago" como Pagar
}

Usuario --> Navegar
Cliente --> Realizar
Realizar ..> Pagar : <<incluir>>
Pasarela --> Pagar
@enduml

El «Cliente registrado» especializa a «Usuario» y hereda la interacción general del usuario. La pasarela de pago está fuera del límite de la Tienda en línea, pero participa en el caso de uso de pago.

7. Ejemplo: generalización de casos de uso

La generalización puede representar versiones especializadas de un caso de uso más amplio. El triángulo hueco apunta hacia el caso de uso general.

@startuml
dirección de izquierda a derecha

actor Cliente

rectángulo "Sistema de pago" {
  caso de uso "Realizar pago" como Pago
  caso de uso "Pagar con tarjeta" como Tarjeta
  caso de uso "Pagar por transferencia bancaria" como Transferencia
}

Cliente --> Tarjeta
Cliente --> Transferencia

Tarjeta --|> Pago
Transferencia --|> Pago
@enduml

Úsalo cuando los casos de uso especializados compartan un objetivo general pero tengan diferencias significativas. Si las variaciones son meros pasos condicionales, un <<extender>> relación o una descripción escrita del caso de uso puede ser más clara.

8. Trabajar en VPasCode

Un flujo de trabajo práctico:

1. Define el alcance.Identifica el límite del sistema, los roles de los actores y los objetivos que cada rol desea lograr.

2. Crea un borrador.Escribe PlantUML directamente o pide al asistente de IA que genere un diagrama de casos de uso.

3. Revisa el código y la vista previa.Confirma que los actores están fuera del límite del sistema, los casos de uso están dentro y las flechas apuntan en la dirección correcta.

4. Refina el modelo.Reemplaza nombres vagos, elimina detalles de implementación y añade relaciones solo cuando reflejen requisitos reales.

5. Solicita ediciones dirigidas de IA.Por ejemplo: «Añade un actor de pasarela de pago externa y muestra la interacción de pago requerida utilizando una relación de inclusión. Mantén el resto sin cambios.»

6. Valida con las partes interesadas.Verifica que el diagrama refleje el alcance real del sistema y los objetivos de los usuarios.

7. Guarda el código fuente. Mantenga el .puml texto junto con la documentación del proyecto o en el control de versiones. Exporte una imagen cuando sea necesario para documentos o presentaciones.

Ejemplo de solicitud para asistencia de IA

Cree un diagrama de casos de uso UML en PlantUML para una tienda en línea. Incluya un límite del sistema, actores Cliente y Administrador, y los objetivos: Explorar productos, Realizar pedido, Rastrear envío y Gestionar catálogo. Muestre la autorización de pago como un comportamiento requerido incluido por Realizar pedido. Muestre la aplicación de una promoción como una extensión condicional de Realizar pedido. Devuelva únicamente código fuente válido de PlantUML.

Trate el código generado por IA como un primer borrador. Revise los actores, límites, relaciones y supuestos comerciales antes de utilizarlo.

9. Errores comunes

• Modelar componentes internos como actores: Los actores deben ser roles externos o sistemas que interactúan con el sujeto.

• Nombrar casos de uso como tareas de implementación: Prefiera “Rastrear envío” en lugar de “Llamar a la API de rastreo.”

• Usar <<include>> para comportamiento opcional: Include representa el comportamiento que el caso de uso base requiere.

• Invertir las flechas de relación: Include apunta al caso de uso incluido; extend apunta al caso de uso base.

• Sobrecargar un diagrama con detalles: Use un diagrama de alto nivel para el alcance y luego diagramas separados o texto para escenarios detallados.

• Asumir que un renderizado exitoso significa que el modelo es correcto: PlantUML puede renderizar un diagrama que aún representa incorrectamente los requisitos.

10. Lista de verificación de revisión

Antes de compartir el diagrama, confirme que:

• El límite del sistema es claro.

• Cada actor es externo y representa un rol.

• Los nombres de los casos de uso describen objetivos significativos.

• Las asociaciones de actores reflejan interacciones reales.

• Las relaciones Include son obligatorias; las relaciones Extend son condicionales o están justificadas de otra manera.

• Las flechas de generalización apuntan al actor o caso de uso general.

• El diagrama permanece legible en su tamaño previsto.

• Las suposiciones generadas por IA han sido revisadas con personas familiarizadas con los requisitos.