Guía de Diagramas de Casos de Uso de PlantUML

Introducción

Uso caso diagramas proporcionan un manera clara para describir cómo usuarios, sistemas externos, y otros actores interactúan con un sistema de software. Ayudan a los equipos a definir el alcance del sistema, identificar funcional requisitos, y comunicar esperado comportamiento antes implementación comience.

PlantUML hace uso caso modelado práctico mediante un basado en texto sintaxis que puede ser almacenado, revisado, versionado, y regenerado junto a proyecto documentación o fuente código. Con un pocos comandos, puedes definir actores, casos de uso, límites del sistema, asociaciones, <<include>> relaciones, <<extend>> relaciones, y notas, y preferencias de diseño. Esta guía explica los

principales conceptos PlantUML uso caso notación mostrado en la referencia hoja y demuestra cómo a aplicar lo en realistas ejemplos. También introduce un flujo de herramientas más amplio utilizando Visual Paradigm UML, asistido por IA modelado, y VPasCode. Juntos, estas herramientas apoyan un proceso completo: proceso: convertir requisitos en un modelo inicial, modelo inicial, validar relaciones UML, relaciones UML, refinar el diagrama, y mantener el modelo final modelo final como diagrama legible diagrama legible fuente.

Un diagrama de casos de uso UML describe cómo los usuarios externos o los sistemas interactúan con un sistema. Se centra en lo que hace el sistema, en lugar de cómo se implementa.

PlantUML le permite crear diagramas de casos de uso utilizando una notación simple basada en texto.

1. Estructura básica de PlantUML

Cada diagrama de PlantUML comienza con @startuml y termina con @enduml.

@startuml

' El contenido del diagrama va aquí

@enduml

Los comentarios comienzan con un apóstrofo:

' Este es un comentario

También puede usar comentarios de varias líneas:

/'
Esto es un
comentario multilinea
'/

2. Definición de actores

Un actor representa una persona, rol, organización, dispositivo o sistema externo que interactúa con tu sistema.

Actor básico

actor Usuario

Esto crea un actor de figura de palo llamado Usuario.

Actor con alias

Los alias son útiles cuando el nombre mostrado contiene espacios o cuando deseas un identificador más corto para las relaciones.

actor "Pasarela de pago" como payment
actor "Administrador del sistema" como admin

Luego puedes referirte a los alias:

payment --> ProcessPayment
admin --> ManageUsers

Actor que utiliza un estilo visual diferente

PlantUML admite varios estilos de actor. El estilo predeterminado suele ser suficiente, pero puedes usar un actor con estilo de icono:

skinparam actorStyle awesome

actor Customer

También puedes usar un actor con estilo de rectángulo simple:

skinparam actorStyle hollow

actor Customer

La apariencia exacta depende del motor de renderizado de PlantUML y de los parámetros de estilo.

3. Definición de casos de uso

Un caso de uso representa un servicio, objetivo o función proporcionado por el sistema.

Caso de uso básico

usecase "Iniciar sesión"

PlantUML representa esto como una elipse etiquetada Iniciar sesión.

Caso de uso con un alias

usecase "Procesar pago con tarjeta de crédito" como ProcessPayment

La etiqueta visible es Procesar pago con tarjeta de crédito, mientras que ProcessPayment se utiliza en relaciones.

actor Cliente
Cliente --> ProcessPayment

Nombres de casos de uso en varias líneas

Puede insertar un salto de línea usando n:

usecase "ProcesarnPago connTarjeta de Crédito" como ProcessPayment

Esto es útil cuando un diagrama contiene etiquetas largas.

4. Límites del sistema

Un límite del sistema agrupa los casos de uso que pertenecen a un sistema en particular.

rectangle "Sistema de Compras en Línea" {
    usecase "Navegar por Productos" como Browse
    usecase "Finalizar Compra" como Checkout
}

El rectángulo representa el sistema, y los casos de uso dentro de él representan la funcionalidad proporcionada por ese sistema.

También puedes usar un alias con nombre para el límite:

rectangle "Sistema de Compras en Línea" como OnlineStore {
    usecase "Navegar por Productos" como Browse
    usecase "Finalizar Compra" como Checkout
}

Un límite del sistema es útil para distinguir el comportamiento del sistema de los actores y servicios externos.

5. Conectar actores y casos de uso

Una asociación muestra que un actor participa en o interactúa con un caso de uso.

Asociación no dirigida

Cliente -- Examinar

Esto crea una línea sólida sin cabeza de flecha.

Asociación dirigida

Cliente --> Examinar

Esto crea una línea sólida con una cabeza de flecha que apunta hacia el caso de uso.

Ambas formas se utilizan comúnmente. La dirección de la flecha debe elegirse de manera consistente según la comunicación o responsabilidad que desee enfatizar.

Asociación con una etiqueta

Cliente --> Caja : inicia

La etiqueta describe la interacción.

Cliente --> VerPedidos : visualiza el historial de pedidos

Para un diseño más legible, puede usar una flecha más larga:

Cliente ---> FinalizarCompra : inicia

6. La <<include>> relación

Una include relación representa un comportamiento que es siempre requerido por otro caso de uso.

Por ejemplo, realizar un pedido puede siempre requerir la validación del pago:

PlaceOrder ..> ValidatePayment : <<include>>

La dirección es importante:

Caso de uso base ..> Caso de uso incluido : <<include>>

La flecha apunta desde el caso de uso que necesita el comportamiento hacia el caso de uso que proporciona el comportamiento reutilizable.

Ejemplo

usecase "Checkout" como Checkout
usecase "Validar Datos del Cliente" como ValidateCustomer
usecase "Calcular Total del Pedido" como CalculateTotal
usecase "Realizar Pago" como MakePayment

Checkout ..> ValidateCustomer : <<include>>
Checkout ..> CalculateTotal : <<include>>
Checkout ..> MakePayment : <<include>>

Esto significa:

1. El proceso de compra siempre valida los datos del cliente.

2. El proceso de compra siempre calcula el total del pedido.

3. El proceso de compra siempre realiza el pago.

Usar <<include>> cuando el comportamiento incluido es obligatorio o reutilizable.

7. La <<extend>> relación

Una extend relación representa un comportamiento opcional, condicional o excepcional añadido a un caso de uso base.

Por ejemplo, aplicar un descuento puede ocurrir solo cuando el cliente tiene un cupón válido:

ApplyDiscount ..> Checkout : <<extend>>

La dirección es:

Caso de uso de extensión opcional ..> Caso de uso base : <<extend>>

La flecha apunta desde el comportamiento opcional hacia el caso de uso base.

Ejemplo correcto

usecase "Checkout" as Checkout
usecase "Apply Discount Coupon" as ApplyDiscount

ApplyDiscount ..> Checkout : <<extend>>

Esto significa que Aplicar cupón de descuento extiende opcionalmente el proceso de pago.

Comparación de incluir y extender

Ejemplo:

Checkout ..> ValidatePayment : <<include>>
ApplyDiscount ..> Checkout : <<extend>>

Evite invertir estas relaciones porque la dirección cambia su significado.

8. Generalización de casos de uso

La generalización muestra que un caso de uso es una forma especializada de otro caso de uso.

usecase "Buscar Productos" as SearchProducts
usecase "Navegar Productos" as BrowseProducts

SearchProducts -|> BrowseProducts

El triángulo hueco apunta hacia el caso de uso más general.

Esto significa que Buscar Productos es una variante especializada de Navegar Productos.

La generalización es menos común que include y extend, así que úsela solo cuando exista una relación genuina de padre-hijo entre los casos de uso.

9. Generalización de actores

Los actores también pueden tener relaciones de generalización.

actor Cliente
actor "Cliente Premium" como PremiumCustomer

PremiumCustomer -|> Cliente

Esto indica que un cliente premium es un tipo especializado de cliente y hereda las interacciones del actor general.

Por ejemplo:

PremiumCustomer --> AplicarDescuento

10. Notas y anotaciones

Las notas añaden explicaciones o restricciones a un diagrama.

Nota adjunta a un caso de uso

note derecha de Checkout
  El cliente debe proporcionar
  información de facturación válida.
end note

Otras posiciones incluyen:

note izquierda de Checkout
  Proceso orientado al cliente
end note

note superior de Checkout
  Flujo de trabajo principal del negocio
end note

note inferior de Checkout
  Incluye procesamiento de pagos
end note

Sintaxis de nota corta

nota a la derecha de Login : Se requiere autenticación de usuario

Nota independiente con un alias

nota "El pago debe ser autorizadonantes de confirmar el pedido" como PaymentNote

Conecte la nota a un elemento con una línea discontinua:

PaymentNote .. MakePayment

Notas para restricciones

Las notas son útiles para documentar condiciones:

nota a la derecha de ApplyDiscount
  Comportamiento opcional:
  usado solo cuando se proporciona un
  cupón válido.
fin nota

11. Dirección del diseño

Por defecto, PlantUML elige un diseño automáticamente. Puedes influir en la dirección.

Diseño de izquierda a derecha

dirección de izquierda a derecha

Esto es a menudo útil para diagramas de casos de uso porque los actores aparecen a la izquierda y los sistemas externos a la derecha.

Diseño de arriba a abajo

dirección de arriba a abajo

Esto puede ser útil para diagramas compactos o flujos de trabajo organizados verticalmente.

Enlaces de diseño invisibles

Un enlace invisible puede influir en la posición sin mostrar una relación visible:

Cliente -[oculto]-> Finalizar compra

Esto es útil para mejorar el diseño del diagrama.

12. Estilizar el diagrama

Quitar sombras

skinparam shadowing false

Usar paquetes y límites rectangulares

skinparam packageStyle rectangle

Establecer colores

skinparam usecase {
    BackgroundColor #FDFDFD
    BorderColor #333333
}

skinparam actor {
    BorderColor #333333
}

Establecer colores de flechas

skinparam ArrowColor #555555

Establecer tamaño de fuente predeterminado

skinparam defaultFontSize 14

Una sección de estilo completa podría verse así:

skinparam shadowing false
skinparam packageStyle rectangle
skinparam actorStyle awesome
skinparam defaultFontSize 14

skinparam usecase {
    BackgroundColor #F9FBFF
    BorderColor #234
}

skinparam ArrowColor #555555

13. Paquetes y agrupación

Los paquetes pueden agrupar casos de uso relacionados.

package "Características del Cliente" {
    usecase "Registrar Cuenta" as Register
    usecase "Iniciar Sesión" as Login
    usecase "Navegar por Productos" as Browse
}

package "Características de Administración" {
    usecase "Gestionar Productos" as ManageProducts
    usecase "Generar Informe de Ventas" as SalesReport
}

Los paquetes son útiles cuando un diagrama contiene muchos casos de uso.

También puedes usar un rectángulo como grupo:

rectangle "Gestión de Pedidos" {
    usecase "Realizar Pedido" as PlaceOrder
    usecase "Rastrear Pedido" as TrackOrder
    usecase "Cancelar Pedido" as CancelOrder
}

14. Sistemas externos

Las aplicaciones o servicios externos pueden representarse como actores.

actor "Pasarela de Pago" as PaymentGateway
actor "Servicio de Correo Electrónico" as EmailService
actor "CRM Externo" as CRM

Conéctalos a los casos de uso del sistema:

PaymentGateway --> MakePayment
EmailService --> SendConfirmation
CRM --> SynchronizeCustomer

Esto separa claramente la funcionalidad del sistema de los servicios fuera del límite del sistema.

15. Ejemplo completo

El siguiente ejemplo combina la notación principal de la hoja de referencia.

@startuml
título Sistema de Compras en Línea - Diagrama de Casos de Uso

dirección de izquierda a derecha

skinparam sombreado false
skinparam estiloPaquete rectángulo
skinparam estiloActor impresionante

skinparam casoUso {
    ColorFondo #F9FBFF
    ColorBorde #333333
}

skinparam ColorFlecha #555555

' Actores
actor Cliente as cliente
actor "Cliente Premium" as premium
actor Administrador as admin
actor "Pasarela de Pago" as pago
actor "Servicio de Correo" as email

' Generalización de actores
premium -|> cliente

' Límite del sistema
rectángulo "Sistema de Compras en Línea" {

    ' Casos de uso del cliente
    casoUso "Registrar Cuenta" as Registrar
    casoUso "Iniciar Sesión" as IniciarSesion
    casoUso "Navegar Productos" as Navegar
    casoUso "Buscar Productos" as Buscar
    casoUso "Ver Detalles del Producto" as VerProducto
    casoUso "Añadir Producto al Carrito" as AñadirAlCarrito
    casoUso "Ver Carrito de Compras" as VerCarrito
    casoUso "Finalizar Compra" as FinalizarCompra
    casoUso "Realizar Pedido" as RealizarPedido
    casoUso "Rastrear Pedido" as RastrearPedido
    casoUso "Cancelar Pedido" as CancelarPedido

    ' Comportamiento compartido incluido
    casoUso "Validar Datos del Cliente" as ValidarCliente
    casoUso "Calcular Total del Pedido" as CalcularTotal
    casoUso "Realizar Pago" as RealizarPago
    casoUso "Enviar Confirmación del Pedido" as EnviarConfirmacion

    ' Comportamiento opcional
    casoUso "Aplicar Cupón de Descuento" as AplicarDescuento
    casoUso "Solicitar Reembolso" as SolicitarReembolso

    ' Casos de uso de administración
    casoUso "Gestionar Productos" as GestionarProductos
    casoUso "Generar Informe de Ventas" as InformeVentas
}

' Asociaciones de actores
cliente --> Registrar
cliente --> IniciarSesion
cliente --> Navegar
cliente --> Buscar
cliente --> VerProducto
cliente --> AñadirAlCarrito
cliente --> VerCarrito
cliente --> FinalizarCompra
cliente --> RastrearPedido
cliente --> CancelarPedido

premium --> AplicarDescuento
premium --> SolicitarReembolso

admin --> GestionarProductos
admin --> InformeVentas

pago --> RealizarPago
email --> EnviarConfirmacion

' Relaciones de inclusión
FinalizarCompra ..> ValidarCliente : <<include>>
FinalizarCompra ..> CalcularTotal : <<include>>
FinalizarCompra ..> RealizarPedido : <<include>>

RealizarPedido ..> RealizarPago : <<include>>
RealizarPedido ..> EnviarConfirmacion : <<include>>

' Relaciones de extensión
AplicarDescuento ..> FinalizarCompra : <<extend>>
SolicitarReembolso ..> CancelarPedido : <<extend>>

' Generalización de casos de uso
Buscar -|> Navegar

' Notas
nota derecha de FinalizarCompra
    Proceso principal de compra del cliente
fin nota

nota derecha de AplicarDescuento
    Comportamiento opcional:
    utilizado solo cuando hay un cupón
    válido disponible
fin nota

nota inferior de RealizarPago
    El pago es gestionado por
    una pasarela de pago externa
fin nota

@enduml

16. Lectura del ejemplo completo

El diagrama comunica lo siguiente:

• Cliente puede navegar por los productos, añadir productos al carrito y finalizar la compra.

• Cliente Premium es una forma especializada de Cliente.

• Finalizar Compra siempre incluye validación del cliente, cálculo del total y colocación del pedido.

• Realizar Pedido siempre incluye pago y confirmación.

• Aplicar Cupón de Descuento es opcional y extiende la finalización de la compra.

• Solicitar Reembolso es una extensión opcional de la cancelación.

• La pasarela de pago gestiona el procesamiento del pago.

• El servicio de correo envía las confirmaciones de los pedidos.

• El administrador gestiona los productos y genera informes.

17. Errores comunes

Invertir incluir

Incorrecto:

ValidateCustomer ..> Checkout : <<incluir>>

Correcto:

Checkout ..> ValidateCustomer : <<incluir>>

El caso de uso base apunta al comportamiento incluido requerido.

Invertirextender

Incorrecto:

Checkout ..> ApplyDiscount : <<extender>>

Correcto:

ApplyDiscount ..> Checkout : <<extend>>

El caso de uso de extensión opcional apunta al caso de uso base.

Usando include para comportamiento opcional

Si un comportamiento ocurre solo bajo ciertas condiciones, use <<extend>>:

ApplyDiscount ..> Checkout : <<extend>>

Si siempre ocurre, use <<include>>:

Checkout ..> ValidateCustomer : <<include>>

Colocar actores externos dentro del límite del sistema

Los usuarios y servicios externos deberían estar normalmente fuera del rectángulo:

actor Cliente

rectangle "Sistema de Compras" {
    usecase "Finalizar Compra" as Checkout
}

Cliente --> Checkout

Crear casos de uso excesivamente detallados

Un caso de uso debe describir un objetivo de usuario significativo, como:

usecase "Realizar Pedido"

Evite convertir cada pequeño paso de implementación en un caso de uso separado, a menos que se reutilice, sea opcional o sea importante para el modelo.

18. Plantilla práctica mínima

Para un diagrama más pequeño, use esta plantilla:

@startuml

dirección de izquierda a derecha

actor Usuario

rectangle "Mi Sistema" {
    usecase "Objetivo Principal del Usuario" as MainGoal
    usecase "Comportamiento Compartido Requerido" as SharedBehavior
    usecase "Comportamiento Opcional" as OptionalBehavior
}

Usuario --> MainGoal

MainGoal ..> SharedBehavior : <<include>>
OptionalBehavior ..> MainGoal : <<extend>>

nota derecha de MainGoal
    Función principal del sistema
end note

@enduml

Esta plantilla contiene la notación esencial:

• Actor

• Límite del sistema

• Casos de uso

• Asociación

• Incluir

• Extender

• Nota

• Dirección del diseño

Herramientas: Visual Paradigm UML, IA y VPasCode

PlantUML es ideal para crear diagramas como texto, pero las herramientas de modelado visual pueden hacer que el mismo flujo de trabajo sea más fácil de revisar, refinar y compartir. Visual Paradigm ofrece capacidades de modelado UML junto con modelado asistido por IA y un espacio de trabajo basado en texto llamado VPasCode. Su plataforma admite diagramas UML estándar, incluidos diagramas de casos de uso, clases, secuencia, actividad, componente, despliegue, máquina de estados, paquetes y objetos.

Modelado UML con Visual Paradigm

Visual Paradigm se puede utilizar cuando desea construir un diagrama de casos de uso de forma visual en lugar de escribir toda la sintaxis manualmente. Un flujo de trabajo típico es:

1. Cree un proyecto UML.

2. Agregue un diagrama de casos de uso.

3. Coloque actores y casos de uso en el lienzo.

4. Dibuje el límite del sistema.

5. Conecte los actores a los casos de uso.

6. Agregue incluir, extender, y relaciones de generalización.

7. Agregue notas y restricciones.

8. Organice y exporte el diagrama finalizado.

El modelado visual es especialmente útil cuando las partes interesadas necesitan revisar el diagrama de forma interactiva. Los miembros del equipo pueden inspeccionar los símbolos, discutir elementos específicos y anotar los diagramas de forma colaborativa.

Un diagrama de casos de uso creado manualmente podría contener:

• Actores como Cliente, Administrador, y Pasarela de pago

• Un límite del sistema como Sistema de compras en línea

• Casos de uso como Finalizar compra, Realizar pedido, y Rastrear pedido

• <<include>> relaciones para comportamiento reutilizable obligatorio

• <<extend>> relaciones para comportamiento opcional

• Relaciones de generalización para actores o casos de uso especializados

El modelo visual debe preservar las mismas reglas semánticas utilizadas en PlantUML:

Finalizar compra ..> ValidarPago : <<include>>
AplicarDescuento ..> Finalizar compra : <<extend>>
ClientePremium -|> Cliente

La distinción importante es que cambiar de herramientas no cambia el significado de UML. Ya sea que el diagrama se cree manualmente, se genere con IA o se escriba en PlantUML, la dirección de la relación debe permanecer correcta.

Modelado asistido por IA

Las capacidades de IA de Visual Paradigm pueden ayudar a transformar requisitos en lenguaje natural en elementos de modelo y diagramas. La plataforma describe sus funciones de IA como capaces de convertir requisitos en diagramas y generar artefactos de desarrollo de software a partir de descripciones de texto.

Por ejemplo, podrías proporcionar el siguiente requisito:

Crea un diagrama de casos de uso para un sistema de compras en línea.

Actores:
- Cliente
- Cliente Premium
- Administrador
- Pasarela de pago
- Servicio de correo electrónico

El cliente puede registrarse, iniciar sesión, navegar por productos, agregar productos al carrito,
finalizar la compra, rastrear pedidos y cancelar pedidos.

Finalizar la compra debe incluir validación del cliente, cálculo del total, pago,
y confirmación del pedido.

Aplicar un cupón de descuento es opcional y extiende Finalizar la compra.
Cliente Premium es un tipo especializado de Cliente.

Una herramienta asistida por IA puede utilizar esta descripción para proponer:

• Definiciones de actores

• Nombres de casos de uso

• Límites del sistema

• Asociaciones

• Casos de uso incluidos

• Casos de uso extendidos

• Generalización de actores

• Notas que describen reglas de negocio

La IA es más útil durante el primer pase de modelado. Puede producir rápidamente un borrador a partir de los requisitos, identificar actores candidatos y sugerir comportamiento reutilizable. El modelo resultante aún debe ser revisado por un desarrollador, analista o experto en el dominio.

Lista de verificación recomendada para la revisión con IA

Después de generar un diagrama, verifique:

• Cada actor está fuera del límite del sistema.

• Cada caso de uso describe un objetivo de usuario significativo o un servicio del sistema.

• El comportamiento reutilizable obligatorio utiliza<<incluir>>.

• El comportamiento opcional o condicional utiliza<<extender>>.

• Laincluir flecha apunta desde el caso de uso base hacia el caso de uso incluido.

• Laextender flecha apunta desde el caso de uso que extiende hacia el caso de uso base.

• Las flechas de generalización apuntan hacia el actor o caso de uso más general.

• Se han eliminado los casos de uso duplicados o excesivamente detallados.

• Los nombres se expresan de manera coherente como frases verbales.

• El diagrama comunica claramente el alcance del sistema.

VPasCode: modelado con texto

VPasCode proporciona un espacio de trabajo de texto a diagrama dentro del ecosistema de Visual Paradigm. La plataforma oficial lo describe como un editor en línea gratuito de texto a diagrama y también lo presenta como una forma de convertir código en diagramas.

Esto hace que VPasCode sea útil para usuarios que prefieren la precisión y la repetibilidad del diagrama como código, pero que aún trabajan dentro de un entorno de modelado visual.

Un diagrama de casos de uso PlantUML se puede escribir de la siguiente manera:

@startuml
título Sistema de Compras en Línea

dirección de izquierda a derecha

actor Cliente as customer
actor "Cliente Premium" as premium
actor Administrador as admin
actor "Pasarela de Pago" as payment
actor "Servicio de Correo Electrónico" as email

premium -|> customer

rectángulo "Sistema de Compras en Línea" {
    usecase "Registrar Cuenta" as Register
    usecase "Iniciar Sesión" as Login
    usecase "Navegar por Productos" as Browse
    usecase "Finalizar Compra" as Checkout
    usecase "Realizar Pedido" as PlaceOrder
    usecase "Rastrear Pedido" as TrackOrder
    usecase "Cancelar Pedido" as CancelOrder

    usecase "Validar Datos del Cliente" as ValidateCustomer
    usecase "Calcular Total del Pedido" as CalculateTotal
    usecase "Realizar Pago" as MakePayment
    usecase "Enviar Confirmación del Pedido" as SendConfirmation

    usecase "Aplicar Cupón de Descuento" as ApplyDiscount
    usecase "Solicitar Reembolso" as RequestRefund

    usecase "Gestionar Productos" as ManageProducts
}

customer --> Register
customer --> Login
customer --> Browse
customer --> Checkout
customer --> TrackOrder
customer --> CancelOrder

premium --> ApplyDiscount
premium --> RequestRefund

admin --> ManageProducts
payment --> MakePayment
email --> SendConfirmation

Checkout ..> ValidateCustomer : <<incluir>>
Checkout ..> CalculateTotal : <<incluir>>
Checkout ..> PlaceOrder : <<incluir>>

PlaceOrder ..> MakePayment : <<incluir>>
PlaceOrder ..> SendConfirmation : <<incluir>>

ApplyDiscount ..> Checkout : <<extender>>
RequestRefund ..> CancelOrder : <<extender>>

@enduml

El mismo modelo puede refinarse de varias maneras:

• Cambiar la dirección del diseño con dirección de izquierda a derecha.

• Añade notas para explicar las reglas de negocio.

• Agrupar casos de uso en paquetes.

• Añadir estilo con skinparam.

• Renombrar alias sin cambiar las etiquetas visibles.

• Mantener el código fuente del diagrama bajo control de versiones.

• Regenerar el diagrama cada vez que el modelo cambie.

Modelado visual frente a diagramas como código

Un flujo de trabajo combinado práctico

Un flujo de trabajo productivo consiste en utilizar cada herramienta para la tarea que maneja mejor:

1. Capturar los requisitos en lenguaje natural.
   Describa usuarios, objetivos, alcance del sistema y reglas de negocio.

2. Utilice la IA para crear un modelo inicial.
   Pida a la IA que identifique los actores y casos de uso, y luego genere un primer borrador.

3. Revise el borrador en Visual Paradigm UML.
   Verifique si el modelo refleja con precisión el dominio y si el diagrama es fácil de entender.

4. Exporte o reescriba el modelo en PlantUML.
   Utilice alias, nombres coherentes y sintaxis explícita de relaciones.

5. Mantenga el código fuente en VPasCode o en control de versiones.
   Almacene el .puml archivo con la documentación del proyecto o el código fuente.

6. Valide la semántica UML.
   Preste especial atención a include, extend, y la dirección de generalización.

7. Publique el diagrama final.
   Exportelo como imagen o documento para requisitos, arquitectura, revisiones de diseño y documentación del proyecto.

Indicaciones para generar un diagrama de casos de uso en PlantUML

Las siguientes indicaciones pueden utilizarse con un asistente de modelado con IA:

Genere un diagrama de casos de uso en PlantUML para un sistema de compras en línea.

Utilice un diseño de izquierda a derecha y coloque todos los casos de uso del sistema dentro de un
rectángulo llamado "Sistema de Compras en Línea".

Actores:
- Cliente
- Cliente Premium
- Administrador
- Pasarela de Pago
- Servicio de Correo Electrónico

Casos de uso del cliente:
- Registrar Cuenta
- Iniciar Sesión
- Navegar por Productos
- Agregar Producto al Carrito
- Finalizar Compra
- Rastrear Pedido
- Cancelar Pedido

Finalizar Compra debe incluir:
- Validar Datos del Cliente
- Calcular Total del Pedido
- Realizar Pedido

Realizar Pedido debe incluir:
- Realizar Pago
- Enviar Confirmación del Pedido

Comportamiento opcional:
- Aplicar Cupón de Descuento extiende Finalizar Compra
- Solicitar Reembolso extiende Cancelar Pedido

Cliente Premium es una especialización de Cliente.

Utilice la sintaxis estándar de PlantUML e incluya:
- Alias de actores
- Alias de casos de uso
- Límite del sistema
- Asociaciones de actores
- Relaciones <<include>>
- Relaciones <<extend>>
- Generalización de actores
- Al menos una nota explicativa

Asegúrese de que las flechas de include apunten desde el caso de uso base hacia el caso de uso incluido,
y que las flechas de extend apunten desde el caso de uso opcional extendido hacia el caso de uso base.

Conclusión clave

Visual Paradigm UML es muy adecuado para el modelado y la revisión interactivos; la IA puede acelerar la transición desde los requisitos hasta un primer borrador, y VPasCode con PlantUML proporciona un flujo de trabajo basado en texto repetible. Utilizados juntos, apoyan todo el ciclo de vida del modelado: describir los requisitos, generar un borrador, validar el UML, refinar la fuente y publicar un diagrama mantenible.