Guia de Diagrama de Casos de Uso do PlantUML

Introdução

Use caso diagramas fornecem uma clara maneira para descrever como usuários, externos sistemas, e outros atores interagem com um software sistema. Eles ajudam equipes definir sistema escopo, identificar funcional requisitos, e comunicar esperado comportamento antes implementação começa.

PlantUML torna uso caso modelagem prática através uma baseada em texto sintaxe que pode ser armazenada, revisada, versionada, e regenerada ao lado do projeto documentação ou fonte código. Com alguns poucos comandos, você pode definir atores, casos de uso, sistema limites, associações, <<include>> relacionamentos, <<extend>> relacionamentos, generalização, notas, e layout preferências.

Este guia explica os principais PlantUML usar caso notação mostrado em a referência planilha e demonstra como a aplicar a em realista exemplos. Ela também introduz um mais amplo ferramentas fluxo de trabalho usando Visual Paradigm UML, assistido por IA modelagem, e VPasCode. Juntos, essas ferramentas suportam um completo processo: transformar requisitos em um inicial modelo, validando UML relacionamentos, refinando o diagrama, e mantendo o final modelo como legível diagrama fonte.

Um diagrama de casos de uso UML descreve como usuários externos ou sistemas interagem com um sistema. Ele foca em o que o sistema faz, e não em como ele é implementado.

O PlantUML permite criar diagramas de casos de uso usando uma notação simples baseada em texto.

1. Estrutura básica do PlantUML

Todo diagrama PlantUML começa com @startuml e termina com @enduml.

@startuml

' O conteúdo do diagrama vai aqui

@enduml

Os comentários começam com um apóstrofo:

' Este é um comentário

Você também pode usar comentários de múltiplas linhas:

/'
Este é um
comentário multilinha
'/

2. Definindo atores

Um ator representa uma pessoa, função, organização, dispositivo ou sistema externo que interage com o seu sistema.

Ator básico

ator User

Isso cria um ator em forma de boneco de palito chamado Usuário.

Ator com um apelido

Apelidos são úteis quando o nome exibido contém espaços ou quando você deseja um identificador mais curto para relacionamentos.

actor "Gateway de Pagamento" as payment
actor "Administrador do Sistema" as admin

Você pode então referir-se aos apelidos:

payment --> ProcessPayment
admin --> ManageUsers

Ator usando um estilo visual diferente

O PlantUML suporta vários estilos de ator. O estilo padrão geralmente é suficiente, mas você pode usar um ator no estilo de ícone:

skinparam actorStyle awesome

actor Cliente

Você também pode usar um ator no estilo de retângulo simples:

skinparam actorStyle hollow

actor Cliente

A aparência exata depende do mecanismo de renderização do PlantUML e dos parâmetros de estilo.

3. Definindo casos de uso

Um caso de uso representa um serviço, objetivo ou função fornecida pelo sistema.

Caso de uso básico

usecase "Entrar"

O PlantUML renderiza isso como uma elipse rotulada Entrar.

Caso de uso com um alias

usecase "Processar Pagamento com Cartão de Crédito" como ProcessPayment

O rótulo visível é Processar Pagamento com Cartão de Crédito, enquanto ProcessarPagamento é usado em relacionamentos.

ator Cliente
Cliente --> ProcessarPagamento

Nomes de casos de uso em múltiplas linhas

Você pode inserir uma quebra de linha usando n:

usecase "ProcessarnPagamentoncom Cartão de Crédito" as ProcessPayment

Isso é útil quando um diagrama contém rótulos longos.

4. Limites do sistema

Um limite do sistema agrupa os casos de uso que pertencem a um sistema específico.

rectangle "Sistema de Compras Online" {
    usecase "Navegar pelos Produtos" as Browse
    usecase "Finalizar Compra" as Checkout
}

O retângulo representa o sistema, e os casos de uso dentro dele representam a funcionalidade fornecida por esse sistema.

Você também pode usar um alias nomeado para a fronteira:

rectangle "Sistema de Compras Online" as OnlineStore {
    usecase "Navegar Produtos" as Browse
    usecase "Finalizar Compra" as Checkout
}

Uma fronteira de sistema é útil ao distinguir o comportamento do sistema de atores e serviços externos.

5. Conectando atores e casos de uso

Uma associação mostra que um ator participa ou interage com um caso de uso.

Associação não direcionada

Cliente -- Navegar

Isso cria uma linha sólida sem uma seta.

Associação direcionada

Cliente --> Navegar

Isso cria uma linha sólida com uma seta apontando para o caso de uso.

Ambas as formas são comumente usadas. A direção da seta deve ser escolhida de forma consistente de acordo com a comunicação ou responsabilidade que você deseja enfatizar.

Associação com um rótulo

Cliente --> Checkout : inicia

O rótulo descreve a interação.

Cliente --> VerPedidos : visualiza o histórico de pedidos

Para um layout mais legível, você pode usar uma seta mais longa:

Cliente ---> FinalizarCompra : inicia

6. O <<include>> relação

Um incluir a relação representa um comportamento que é sempre necessário por outro caso de uso.

Por exemplo, fazer um pedido pode sempre exigir validação de pagamento:

PlaceOrder ..> ValidatePayment : <<include>>

A direção é importante:

Caso de uso base ..> Caso de uso incluído : <<include>>

A seta aponta do caso de uso que precisa do comportamento para o caso de uso que fornece o comportamento reutilizável.

Exemplo

usecase "Checkout" como Checkout
usecase "Validar Dados do Cliente" como ValidateCustomer
usecase "Calcular Total do Pedido" como CalculateTotal
usecase "Realizar Pagamento" como MakePayment

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

Isso significa:

1. O Checkout sempre valida os dados do cliente.

2. O Checkout sempre calcula o total do pedido.

3. O Checkout sempre realiza o pagamento.

Use <<include>> quando o comportamento incluído é obrigatório ou reutilizável.

7. O <<extend>> relação

Uma extensão relação representa comportamento opcional, condicional ou excepcional adicionado a um caso de uso base.

Por exemplo, a aplicação de um desconto pode ocorrer apenas quando o cliente possui um cupom válido:

ApplyDiscount ..> Checkout : <<extend>>

A direção é:

Caso de uso de extensão opcional ..> Caso de uso base : <<extend>>

A seta aponta do comportamento opcional para o caso de uso base.

Exemplo correto

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

ApplyDiscount ..> Checkout : <<extend>>

Isso significa que Aplicar Cupom de Desconto estende opcionalmente o Finalizaçãoprocesso.

Comparação entre incluir e estender

Exemplo:

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

Evite reverter essas relações, pois a direção altera seu significado.

8. Generalização de casos de uso

A generalização mostra que um caso de uso é uma forma especializada de outro caso de uso.

usecase "Pesquisar Produtos" as SearchProducts
usecase "Navegar Produtos" as BrowseProducts

SearchProducts -|> BrowseProducts

O triângulo vazio aponta para o caso de uso mais geral.

Isso significa que Pesquisar Produtos é uma variação especializada de Navegar pelos Produtos.

A generalização é menos comum do que incluir e estender, portanto, use-o apenas quando houver uma relação genuína de pai-filho entre os casos de uso.

9. Generalização de ator

Os atores também podem ter relações de generalização.

ator Cliente
ator "Cliente Premium" como PremiumCustomer

PremiumCustomer -|> Cliente

Isso indica que um cliente premium é um tipo especializado de cliente e herda as interações do ator geral.

Por exemplo:

PremiumCustomer --> AplicarDesconto

10. Notas e anotações

As notas adicionam explicações ou restrições a um diagrama.

Nota anexada a um caso de uso

note right of Checkout
  O cliente deve fornecer
  informações de cobrança válidas.
end note

Outras posições incluem:

note left of Checkout
  Processo voltado ao cliente
end note

note top of Checkout
  Fluxo de trabalho principal do negócio
end note

note bottom of Checkout
  Inclui processamento de pagamento
end note

Sintaxe de nota curta

nota à direita de Login : Autenticação de usuário é necessária

Nota independente com um alias

nota "O pagamento deve ser autorizadonantes da confirmação do pedido" como PaymentNote

Conecte a nota a um elemento com uma linha tracejada:

PaymentNote .. MakePayment

Notas para restrições

Notas são úteis para documentar condições:

nota à direita de ApplyDiscount
  Comportamento opcional:
  usado apenas quando um cupom
  válido é fornecido.
fim da nota

11. Direção do layout

Por padrão, o PlantUML escolhe um layout automaticamente. Você pode influenciar a direção.

Layout da esquerda para a direita

direção da esquerda para a direita

Isso é frequentemente útil para diagramas de casos de uso, porque os atores aparecem à esquerda e os sistemas externos à direita.

Layout de cima para baixo

direção de cima para baixo

Isso pode ser útil para diagramas compactos ou fluxos de trabalho organizados verticalmente.

Links de layout invisíveis

Um link invisível pode influenciar o posicionamento sem exibir uma relação visível:

Cliente -[oculto]-> Checkout

Isso é útil para melhorar o layout do diagrama.

12. Estilizando o diagrama

Remover sombras

skinparam shadowing false

Usar pacotes e limites retangulares

skinparam packageStyle rectangle

Definir cores

skinparam usecase {
    BackgroundColor #FDFDFD
    BorderColor #333333
}

skinparam actor {
    BorderColor #333333
}

Definir cores das setas

skinparam ArrowColor #555555

Definir tamanho de fonte padrão

skinparam defaultFontSize 14

Uma seção de estilização completa pode parecer com isto:

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

skinparam usecase {
    BackgroundColor #F9FBFF
    BorderColor #234
}

skinparam ArrowColor #555555

13. Pacotes e agrupamento

Pacotes podem agrupar casos de uso relacionados.

package "Recursos do Cliente" {
    usecase "Registrar Conta" as Register
    usecase "Entrar" as Login
    usecase "Navegar pelos Produtos" as Browse
}

package "Recursos de Administração" {
    usecase "Gerenciar Produtos" as ManageProducts
    usecase "Gerar Relatório de Vendas" as SalesReport
}

Pacotes são úteis quando um diagrama contém muitos casos de uso.

Você também pode usar um retângulo como um grupo:

rectangle "Gerenciamento de Pedidos" {
    usecase "Fazer Pedido" as PlaceOrder
    usecase "Rastrear Pedido" as TrackOrder
    usecase "Cancelar Pedido" as CancelOrder
}

14. Sistemas externos

Aplicações ou serviços externos podem ser representados como atores.

ator "Gateway de Pagamento" como PaymentGateway
ator "Serviço de E-mail" como EmailService
ator "CRM Externo" como CRM

Conecte-os aos casos de uso do sistema:

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

Isso separa claramente a funcionalidade do sistema dos serviços fora dos limites do sistema.

15. Exemplo completo

O exemplo a seguir combina as principais notações da folha de referência.

@startuml
title Sistema de Compras Online - Diagrama de Casos de Uso

direção da esquerda para a direita

skinparam shadowing false
skinparam packageStyle rectangle
skinparam actorStyle awesome

skinparam usecase {
    BackgroundColor #F9FBFF
    BorderColor #333333
}

skinparam ArrowColor #555555

' Atores
actor Cliente as cliente
actor "Cliente Premium" as premium
actor Administrador as admin
actor "Gateway de Pagamento" as payment
actor "Serviço de E-mail" as email

' Generalização de atores
premium -|> cliente

' Limite do sistema
rectangle "Sistema de Compras Online" {

    ' Casos de uso do cliente
    usecase "Registrar Conta" as Register
    usecase "Entrar" as Login
    usecase "Navegar em Produtos" as Browse
    usecase "Pesquisar Produtos" as Search
    usecase "Ver Detalhes do Produto" as ViewProduct
    usecase "Adicionar Produto ao Carrinho" as AddToCart
    usecase "Ver Carrinho de Compras" as ViewCart
    usecase "Finalizar Compra" as Checkout
    usecase "Fazer Pedido" as PlaceOrder
    usecase "Acompanhar Pedido" as TrackOrder
    usecase "Cancelar Pedido" as CancelOrder

    ' Comportamento compartilhado incluído
    usecase "Validar Dados do Cliente" as ValidateCustomer
    usecase "Calcular Total do Pedido" as CalculateTotal
    usecase "Realizar Pagamento" as MakePayment
    usecase "Enviar Confirmação do Pedido" as SendConfirmation

    ' Comportamento opcional
    usecase "Aplicar Cupom de Desconto" as ApplyDiscount
    usecase "Solicitar Reembolso" as RequestRefund

    ' Casos de uso de administração
    usecase "Gerenciar Produtos" as ManageProducts
    usecase "Gerar Relatório de Vendas" as SalesReport
}

' Associações de atores
cliente --> Register
cliente --> Login
cliente --> Browse
cliente --> Search
cliente --> ViewProduct
cliente --> AddToCart
cliente --> ViewCart
cliente --> Checkout
cliente --> TrackOrder
cliente --> CancelOrder

premium --> ApplyDiscount
premium --> RequestRefund

admin --> ManageProducts
admin --> SalesReport

payment --> MakePayment
email --> SendConfirmation

' Relações de inclusão
Checkout ..> ValidateCustomer : <<include>>
Checkout ..> CalculateTotal : <<include>>
Checkout ..> PlaceOrder : <<include>>

PlaceOrder ..> MakePayment : <<include>>
PlaceOrder ..> SendConfirmation : <<include>>

' Relações de extensão
ApplyDiscount ..> Checkout : <<extend>>
RequestRefund ..> CancelOrder : <<extend>>

' Generalização de casos de uso
Search -|> Browse

' Notas
note right of Checkout
    Processo principal de compra do cliente
end note

note right of ApplyDiscount
    Comportamento opcional:
    usado apenas quando um cupom
    válido está disponível
end note

note bottom of MakePayment
    O pagamento é tratado por
    um gateway de pagamento externo
end note

@enduml

16. Lendo o exemplo completo

O diagrama comunica o seguinte:

• Cliente pode navegar em produtos, adicionar produtos a um carrinho e finalizar a compra.

• Cliente Premium é uma forma especializada de Cliente.

• Finalizar compra sempre inclui validação do cliente, cálculo do total e confirmação do pedido.

• Confirmar pedido sempre inclui pagamento e confirmação.

• Aplicar cupom de desconto é opcional e estende a finalização da compra.

• Solicitar reembolso é uma extensão opcional do cancelamento.

• A gateway de pagamentos processa os pagamentos.

• O serviço de e-mail envia as confirmações de pedido.

• O administrador gerencia os produtos e gera relatórios.

17. Erros comuns

Reverter incluir

Incorreto:

ValidateCustomer ..> Checkout : <<incluir>>

Correto:

Checkout ..> ValidateCustomer : <<incluir>>

O caso de uso base aponta para o comportamento incluído obrigatório.

Revertendoestender

Incorreto:

Checkout ..> AplicarDesconto : <<estender>>

Correto:

ApplyDiscount ..> Checkout : <<extend>>

O caso de uso opcional de extensão aponta para o caso de uso base.

Usando include para comportamento opcional

Se um comportamento ocorre apenas sob certas condições, use <<extend>>:

ApplyDiscount ..> Checkout : <<extend>>

Se isso sempre acontecer, use <<include>>:

Checkout ..> ValidateCustomer : <<include>>

Colocar atores externos dentro dos limites do sistema

Usuários e serviços externos devem normalmente estar fora do retângulo:

ator Cliente

retângulo "Sistema de Compras" {
    caso de uso "Finalizar Compra" como Checkout
}

Cliente --> Checkout

Criar casos de uso excessivamente detalhados

Um caso de uso deve descrever um objetivo significativo do usuário, como:

usecase "Fazer Pedido"

Evite transformar cada pequena etapa de implementação em um caso de uso separado, a menos que seja reutilizado, opcional ou importante para o modelo.

18. Modelo prático mínimo

Para um diagrama menor, use este modelo:

@startuml

direção da esquerda para a direita

ator User

retângulo "Meu Sistema" {
    usecase "Objetivo Principal do Usuário" as MainGoal
    usecase "Comportamento Compartilhado Necessário" as SharedBehavior
    usecase "Comportamento Opcional" as OptionalBehavior
}

User --> MainGoal

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

nota à direita de MainGoal
    Função principal do sistema
fim nota

@enduml

Este modelo contém a notação essencial:

• Ator

• Fronteira do sistema

• Casos de uso

• Associação

• Incluir

• Estender

• Nota

• Direção do layout

Ferramentas: Visual Paradigm UML, IA e VPasCode

O PlantUML é ideal para criar diagramas como texto, mas ferramentas de modelagem visual podem tornar o mesmo fluxo de trabalho mais fácil de revisar, refinar e compartilhar. O Visual Paradigm oferece capacidades de modelagem UML juntamente com modelagem assistida por IA e um ambiente de trabalho baseado em texto chamado VPasCode. Sua plataforma suporta diagramas UML padrão, incluindo diagramas de casos de uso, classe, sequência, atividade, componente, implantação, máquina de estados, pacote e objeto.

Modelagem UML no Visual Paradigm

O Visual Paradigm pode ser usado quando você deseja construir um diagrama de casos de uso visualmente, em vez de escrever toda a sintaxe manualmente. Um fluxo de trabalho típico é:

1. Crie um projeto UML.

2. Adicione um diagrama de casos de uso.

3. Posicione atores e casos de uso no canvas.

4. Desenhe a fronteira do sistema.

5. Conecte atores aos casos de uso.

6. Adicionar incluir, estender, e relacionamentos de generalização.

7. Adicione observações e restrições.

8. Organize e exporte o diagrama concluído.

A modelagem visual é especialmente útil quando as partes interessadas precisam revisar o diagrama de forma interativa. Os membros da equipe podem inspecionar os símbolos, discutir elementos específicos e anotar os diagramas de forma colaborativa.

Um diagrama de casos de uso criado manualmente pode conter:

• Atores como Cliente, Administrador, e Gateway de Pagamento

• Um limite de sistema como Sistema de Compras Online

• Casos de uso como Finalizar Compra, Registrar Pedido, e Rastrear Pedido

• <<include>> relações para comportamento reutilizável obrigatório

• <<extend>> relações para comportamento opcional

• Relações de generalização para atores ou casos de uso especializados

O modelo visual deve preservar as mesmas regras semânticas usadas no PlantUML:

Checkout ..> ValidatePayment : <<include>>
ApplyDiscount ..> Checkout : <<extend>>
PremiumCustomer -|> Customer

A distinção importante é que mudar de ferramentas não altera o significado UML. Seja o diagrama criado manualmente, gerado por IA ou escrito em PlantUML, a direção da relação deve permanecer correta.

Modelagem assistida por IA

As capacidades de IA do Visual Paradigm podem ajudar a transformar requisitos em linguagem natural em elementos de modelo e diagramas. A plataforma descreve seus recursos de IA como capazes de converter requisitos em diagramas e gerar artefatos de desenvolvimento de software a partir de descrições em texto.

Por exemplo, você poderia fornecer o seguinte requisito:

Crie um diagrama de casos de uso para um sistema de compras online.

Atores:
- Cliente
- Cliente Premium
- Administrador
- Gateway de Pagamento
- Serviço de E-mail

O cliente pode se registrar, fazer login, navegar pelos produtos, adicionar produtos ao carrinho,
finalizar a compra, rastrear pedidos e cancelar pedidos.

A finalização da compra deve incluir validação do cliente, cálculo do total, pagamento e confirmação do pedido.

A aplicação de um cupom de desconto é opcional e estende a finalização da compra.
O Cliente Premium é um tipo especializado de Cliente.

Uma ferramenta assistida por IA pode usar essa descrição para propor:

• Definições de atores

• Nomes de casos de uso

• Limites do sistema

• Associações

• Casos de uso incluídos

• Casos de uso estendidos

• Generalização de atores

• Notas descrevendo regras de negócio

A IA é mais útil durante a primeira passagem de modelagem. Ela pode rapidamente produzir um rascunho a partir dos requisitos, identificar atores candidatos e sugerir comportamento reutilizável. O modelo resultante ainda deve ser revisado por um desenvolvedor, analista ou especialista no domínio.

Lista de verificação recomendada para revisão por IA

Após gerar um diagrama, verifique:

• Cada ator está externo ao limite do sistema.

• Cada caso de uso descreve um objetivo significativo do usuário ou um serviço do sistema.

• Comportamento reutilizável obrigatório usa <<include>>.

• Comportamento opcional ou condicional usa <<extend>>.

• A inclui seta aponta do caso de uso base para o caso de uso incluído.

• A estenderA seta aponta do caso de uso que estende para o caso de uso base.

• As setas de generalização apontam para o ator ou caso de uso mais geral.

• Casos de uso duplicados ou excessivamente detalhados foram removidos.

• Os nomes são expressos de forma consistente como frases verbais.

• O diagrama comunica claramente o escopo do sistema.

VPasCode: modelagem com texto

O VPasCode oferece um ambiente de trabalho de texto para diagrama dentro do ecossistema Visual Paradigm. A plataforma oficial o descreve como um editor online gratuito de texto para diagrama e também o apresenta como uma maneira de transformar código em diagramas.

Isso torna o VPasCode útil para usuários que preferem a precisão e a repetibilidade do diagrama como código, mas ainda assim trabalham dentro de um ambiente de modelagem visual.

Um diagrama de casos de uso PlantUML pode ser escrito da seguinte forma:

@startuml
title Sistema de Compras Online

direção da esquerda para a direita

ator Cliente as customer
ator "Cliente Premium" as premium
ator Administrador as admin
ator "Gateway de Pagamento" as payment
ator "Serviço de E-mail" as email

premium -|> customer

retângulo "Sistema de Compras Online" {
    usecase "Registrar Conta" as Register
    usecase "Entrar" as Login
    usecase "Navegar pelos Produtos" as Browse
    usecase "Finalizar Compra" as Checkout
    usecase "Fazer Pedido" as PlaceOrder
    usecase "Rastrear Pedido" as TrackOrder
    usecase "Cancelar Pedido" as CancelOrder

    usecase "Validar Dados do Cliente" as ValidateCustomer
    usecase "Calcular Total do Pedido" as CalculateTotal
    usecase "Realizar Pagamento" as MakePayment
    usecase "Enviar Confirmação do Pedido" as SendConfirmation

    usecase "Aplicar Cupom de Desconto" as ApplyDiscount
    usecase "Solicitar Reembolso" as RequestRefund

    usecase "Gerenciar Produtos" 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 : <<include>>
Checkout ..> CalculateTotal : <<include>>
Checkout ..> PlaceOrder : <<include>>

PlaceOrder ..> MakePayment : <<include>>
PlaceOrder ..> SendConfirmation : <<include>>

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

@enduml

O mesmo modelo pode ser refinado de várias maneiras:

• Alterar a direção do layout com direção da esquerda para a direita.

• Adicionar notas para explicar as regras de negócio.

• Agrupar casos de uso em pacotes.

• Adicionar estilo com skinparam.

• Renomear aliases sem alterar os rótulos visíveis.

• Manter a fonte do diagrama sob controle de versão.

• Regenerar o diagrama sempre que o modelo mudar.

Modelagem visual versus diagrama como código

Um fluxo de trabalho combinado prático

Um fluxo de trabalho produtivo é usar cada ferramenta para a tarefa que ela melhor executa:

1. Capture os requisitos em linguagem natural.
   Descreva os usuários, objetivos, escopo do sistema e regras de negócio.

2. Use a IA para criar um modelo inicial.
   Pergunte à IA para identificar atores e casos de uso, e depois gere um primeiro rascunho.

3. Revise o rascunho no Visual Paradigm UML.
   Verifique se o modelo reflete com precisão o domínio e se o diagrama é fácil de entender.

4. Exporte ou reescreva o modelo em PlantUML.
   Use aliases, nomes consistentes e sintaxe explícita de relacionamentos.

5. Mantenha a fonte no VPasCode ou em controle de versão.
   Armazene o .puml arquivo com a documentação do projeto ou o código-fonte.

6. Valide a semântica UML.
   Preste atenção especial a include, extend, e direção de generalização.

7. Publique o diagrama final.
   Exporte-o como uma imagem ou documento para requisitos, arquitetura, revisões de design e documentação do projeto.

Prompt para gerar um diagrama de casos de uso PlantUML

O seguinte prompt pode ser usado com um assistente de modelagem por IA:

Gere um diagrama de casos de uso PlantUML para um sistema de compras online.

Use um layout da esquerda para a direita e coloque todos os casos de uso do sistema dentro de um
retângulo chamado "Sistema de Compras Online".

Atores:
- Cliente
- Cliente Premium
- Administrador
- Gateway de Pagamento
- Serviço de E-mail

Casos de uso do Cliente:
- Registrar Conta
- Fazer Login
- Navegar pelos Produtos
- Adicionar Produto ao Carrinho
- Finalizar Compra
- Rastrear Pedido
- Cancelar Pedido

Finalizar Compra deve incluir:
- Validar Detalhes do Cliente
- Calcular Total do Pedido
- Realizar Pedido

Realizar Pedido deve incluir:
- Efetuar Pagamento
- Enviar Confirmação do Pedido

Comportamento opcional:
- Aplicar Cupom de Desconto estende Finalizar Compra
- Solicitar Reembolso estende Cancelar Pedido

Cliente Premium é uma especialização de Cliente.

Use a sintaxe padrão do PlantUML e inclua:
- Aliases de atores
- Aliases de casos de uso
- Fronteira do sistema
- Associações de atores
- Relações <<include>>
- Relações <<extend>>
- Generalização de atores
- Pelo menos uma nota explicativa

Certifique-se de que as setas de include apontem do caso de uso base para o caso de uso incluído,
e que as setas de extend apontem do caso de uso opcional que estende para o caso de uso base.

Principais pontos

O Visual Paradigm UML é bem adequado para modelagem e revisão interativas; a IA pode acelerar a transição dos requisitos para um primeiro rascunho; e o VPasCode com PlantUML oferece um fluxo de trabalho baseado em texto repetível. Usados em conjunto, eles suportam todo o ciclo de vida da modelagem: descrever os requisitos, gerar um rascunho, validar o UML, refinar a fonte e publicar um diagrama mantível.

This post is also available in Deutsch, English, Español, فارسی, Français, Bahasa Indonesia, 日本語, Polski, Ру́сский, Việt Nam, 简体中文 and 繁體中文.