Diagramas de Classes UML para Modelagem de Dados com PlantUML

Um diagrama de classes UML descreve a estrutura de um sistema: as coisas que ele modela, suas propriedades e como elas se relacionam. Para modelagem de dados, pode capturar conceitos e restrições do domínio antes de definir tabelas ou código de aplicação.

PlantUML torna o diagrama reproduzível: você escreve texto, o renderiza, revisa as alterações no controle de versão e o atualiza conforme o modelo evolui. Ele complementa — não substitui — esquemas de banco de dados, migrações e regras de negócio detalhadas.

1. Escolha o nível de modelagem

Um diagrama de modelagem de dados útil geralmente foca em um nível por vez:

• Conceitual: conceitos e relacionamentos de negócio, com mínimo detalhe técnico. Exemplo: Cliente realiza Pedido.

• Lógico: atributos, identificadores, multiplicidades e regras, sem vincular o modelo a um banco de dados específico.

• Físico: detalhes de implementação, como tipos de colunas SQL, índices e restrições específicas do banco de dados.

O exemplo abaixo é um modelo de domínio lógico. Tipos como UUID, Money, e DateTime são ilustrativos; decida suas representações concretas ao escolher uma tecnologia.

2. Fundamentos do PlantUML

Uma classe tem um nome e pode listar atributos e operações:

@startuml
class Customer {
  -id: UUID
  +name: String
  +email: String
  +changeEmail(newEmail: String): void
}
@enduml

Marcadores de visibilidade são dicas de modelagem opcionais:

• + público

• - privado

• # protegido

• ~ visibilidade de pacote

Para um diagrama de domínio ou de dados, os atributos são os mais importantes. Inclua operações apenas quando elas esclarecerem comportamentos importantes; evite transformar o diagrama em uma listagem completa de código.

3. Relacionamentos e multiplicidade

As notações de relacionamento mais úteis para modelagem de dados são:

Rótulos de multiplicidade ficam próximos às extremidades da associação:

• 1 — exatamente um

• 0..1 — opcional, no máximo um

• * ou 0..* — zero ou mais

• 1..* — um ou mais

• 2..5 — um intervalo limitado

Por exemplo:

Cliente "1" -- "0..*" Pedido : coloca

Leia os rótulos em cada extremidade com atenção: um cliente pode fazer zero ou mais pedidos; cada pedido está associado a exatamente um cliente. Os rótulos descrevem o relacionamento, não necessariamente a implementação de chave estrangeira de um banco de dados específico.

4. Exemplo prático: loja online

Este modelo inclui clientes, pedidos, itens de pedido, produtos e registros de pagamento. Ele demonstra identificadores, tipos semelhantes a valores, um enum, composição e multiplicidades.

@startuml ShopDomain
skinparam classAttributeIconSize 0
skinparam shadowing false

hide methods

class Customer {
  +customerId: UUID
  +email: EmailAddress
  +displayName: String
}

class Order {
  +orderId: UUID
  +placedAt: DateTime
  +status: OrderStatus
  +total: Money
}

class OrderLine {
  +lineNumber: Integer
  +quantity: PositiveInteger
  +unitPrice: Money
}

class Product {
  +productId: UUID
  +sku: SKU
  +name: String
  +currentPrice: Money
}

class Payment {
  +paymentId: UUID
  +amount: Money
  +status: PaymentStatus
  +paidAt: DateTime [0..1]
}

class Money <<value object>> {
  +amount: Decimal
  +currency: CurrencyCode
}

enum OrderStatus {
  DRAFT
  PLACED
  PAID
  FULFILLED
  CANCELLED
}

enum PaymentStatus {
  PENDING
  AUTHORIZED
  CAPTURED
  FAILED
  REFUNDED
}

Customer "1" -- "0..*" Order : places
Order "1" *-- "1..*" OrderLine : contains
OrderLine "0..*" --> "1" Product : refers to
Order "1" -- "0..*" Payment : payment attempts
Order --> OrderStatus
Payment --> PaymentStatus
OrderLine --> Money : unit price
Payment --> Money : amount

note right of OrderLine
  quantity must be greater than zero
  unitPrice is the price captured
  when the order is placed
end note

note right of Product
  Product.currentPrice may change.
  It does not replace OrderLine.unitPrice.
end note
@enduml

Por que modelar OrderLine explicitamente? O relacionamento entre um pedido e um produto possui seus próprios dados — quantidade e o preço no momento da compra. Isso o torna um conceito de domínio, não apenas uma ligação simples.

Por que composição de Order para OrderLine? O exemplo assume que uma linha de pedido pertence a um único pedido e não tem significado independente. Use composição apenas quando essa regra de propriedade e ciclo de vida for verdadeira no seu domínio; a notação UML não a impõe no banco de dados.

Por que distinguir preços atuais e históricos? O preço de um produto pode mudar após um pedido ser feito. Manter o preço no momento da compra na linha de pedido preserva o valor histórico.

5. Decisões de modelagem que importam

Identificadores: Marque identificadores de forma consistente, como customerId ou orderId. UML não define uma notação universal única para chaves primárias, portanto escolha uma convenção e documente-a. Um estereótipo ou nota pode tornar isso explícito:

class Customer {
  +customerId: UUID <<PK>>
  +email: EmailAddress
}

Valores opcionais: Use [0..1] para um atributo opcional quando isso for claro para seus leitores, ou anote a regra. Por exemplo, um pagamento pode não ter nenhum paidAt timestamp até que seja bem-sucedido.

Objetos de valor: Um tipo como Money ou EmailAddress pode representar um conceito com validação ou semântica próprias. Decida se deve aparecer como uma classe separada, um tipo de atributo ou uma estrutura de banco de dados, com base no público-alvo e no nível de detalhe.

Enumerações e valores controlados: Use uma enumeração quando o conjunto permitido for pequeno e relativamente estável. Se os valores precisarem de descrições independentes, ciclo de vida ou administração, modele-os como uma classe em vez disso.

Normalização e implementação: Um diagrama de classes comunica conceitos e regras; não define todos os detalhes relacionais. Por exemplo, se Money se torna duas colunas, uma tabela separada ou um tipo específico do banco de dados é uma decisão de implementação.

Mantenha os diagramas legíveis: Divida um domínio grande em diagramas focados — como pedidos, estoque e identidade — e use pacotes para agrupar classes relacionadas. Mostre apenas atributos relevantes para a questão que o diagrama deve responder.

6. Construa um modelo a partir dos requisitos

1. Extraia conceitos candidatos da linguagem do domínio: substantivos frequentemente sugerem classes; verbos frequentemente sugerem relacionamentos ou comportamento.

2. Esclarecer regras com perguntas concretas: Um pedido pode existir sem um cliente? Ele pode ter zero linhas? Um pagamento pode ser tentado novamente?

3. Escolha um nível de modelagem e mantenha decisões técnicas de banco de fora de um diagrama conceitual.

4. Adicione atributos e identificadores apenas quando ajudarem a explicar o modelo.

5. Defina multiplicidades a partir das regras de negócio, verificando ambas as extremidades de cada relacionamento.

6. Revise casos de borda: exclusão, registros históricos, campos opcionais, tentativas repetidas e valores mutáveis.

7. Renderize e revise o diagrama com especialistas do domínio e implementadores. Trate-o como um modelo a ser validado, não meramente como uma imagem a ser aprovada.

7. Use VPasCode e Visual Paradigm

VPasCode é um editor de texto-para-diagrama baseado em navegador com suporte a PlantUML e uma visualização ao vivo. Sua descrição de recursos também lista geração e modificação de código de diagrama por IA, além de assistência de sintaxe. Um fluxo de trabalho prático é:

1. Abra o VPasCode e selecione ou insira PlantUML.

2. Cole o exemplo acima e inspecione o diagrama renderizado.

3. Itere sobre a fonte PlantUML; mantenha o texto como o artefato versionável.

4. Use o assistente de IA, se disponível em seu espaço de trabalho, para rascunhar ou revisar uma primeira versão.

5. Verifique por si mesmo cada classe, relacionamento, multiplicidade e regra de negócio gerados.

As ferramentas de diagramação assistidas por IA do Visual Paradigm podem gerar diagramas editáveis a partir de descrições em linguagem natural. Seu fluxo de trabalho publicado descreve a geração de um diagrama de classes a partir de um prompt, seguido pelo refinamento de seus elementos e relacionamentos. Trate a saída da IA como umrascunho: ela pode inferir propriedade incorreta, restrições ausentes ou classes injustificadas. A correção do modelo ainda depende de validá-lo contra os requisitos.

Por exemplo, faça um prompt a um assistente de IA com:

Crie um diagrama de classes UML lógico para uma loja online. Clientes fazem pedidos. Cada pedido contém uma ou mais linhas de pedido. Cada linha de pedido refere-se a um produto e armazena a quantidade e o preço unitário no momento da compra. Pedidos podem ter múltiplas tentativas de pagamento. Inclua identificadores, multiplicidades e enumeradores de status de pedido e pagamento. Saída apenas em PlantUML.

Em seguida, revise a saída contra os requisitos antes de aceitá-la. Para melhores resultados, especifique pressupostos explicitamente — por exemplo, se os pedidos podem ser rascunhos sem linhas e se os pagamentos podem ser reembolsados.

O Visual Paradigm descreveVPasCode como um editor com capacidade para PlantUML com renderização em tempo real e geração ou modificação assistida por IA. As ferramentas e a disponibilidade podem variar conforme a versão do produto ou o espaço de trabalho.

8. Uma lista de verificação de revisão compacta

Antes de compartilhar ou implementar um diagrama de classes, verifique:

• Cada classe representa um conceito de domínio significativo?

• Os identificadores e atributos importantes estão claros?

• Os rótulos de relacionamento e as multiplicidades estão corretos em ambos os extremos?

• A composição reflete uma dependência real do ciclo de vida?

• Os fatos históricos são preservados onde os valores atuais podem mudar?

• Os valores opcionais e as restrições de negócios estão visíveis?

• O diagrama é suficientemente focado para seu público?

• O conteúdo gerado foi verificado em relação aos requisitos reais?

O melhor fluxo de trabalho de diagrama como código é IA para um rascunho inicial, PlantUML para edições precisas e histórico de versões, e revisão humana para correção de domínio.

This post is also available in Deutsch, English, Español, Français, Bahasa Indonesia, 日本語, Polski, Việt Nam, 简体中文 and 繁體中文.