O que é um Diagrama de Classes?
Um Diagrama de Classes é um diagrama UML que visualiza a arquitetura estática de um sistema de software orientado a objetos. Como um tipo de diagrama UML indispensável, ele mapeia as classes individuais, interfaces e modelos de dados dentro do seu aplicativo, documentando explicitamente seus campos internos (atributos), funções operacionais (métodos) e as relações estruturais que as unem. Este plano é vital para engenheiros de software que precisam traduzir designs de domínio de alto nível em estruturas de objetos limpas e sustentáveis.tipo de diagrama UMLele mapeia as classes individuais, interfaces e modelos de dados dentro do seu aplicativo, documentando explicitamente seus campos internos (atributos), funções operacionais (métodos) e as relações estruturais que as unem. Este plano é vital para engenheiros de software que precisam traduzir designs de domínio de alto nível em estruturas de objetos limpas e sustentáveis.
Com Mermaid.jsvocê pode esboçar seus modelos de dados e serviços do sistema usando definições intuitivas baseadas em texto. O motor de layout calcula automaticamente os tamanhos das caixas, estrutura compartimentos padrão de dados UML e alinha setas relacionais em toda a sua tela sem qualquer sobrecarga de formatação manual.
Guia de Sintaxe Básica: Elementos e Construções
Para criar um diagrama de classes UML preciso e compatível com padrões no Mermaid, você deve dominar as declarações de membros, modificadores de acesso e setas de relacionamento estrutural.
1. Declarando Classes e Compartimentos de Classe
Você pode definir uma classe usando dois formatos válidos. Para uma classe simples, use a palavra-chave classseguida pelo nome da classe. Se você quiser incluir campos e métodos imediatamente, use chaves finais para criar um bloco de corpo claro:
classDiagram
class UserProfile {
+String username
+String email
+updateEmail(newEmail) void
}
2. Adicionando Visibilidade / Modificadores de Acesso
Para documentar as regras padrão de encapsulamento UML, coloque um símbolo específico diretamente antes do nome do atributo ou método para definir seu nível de visibilidade:
+**Público:** Acessível por qualquer outra classe.-**Privado:** Acessível apenas dentro da classe que o declara.#**Protegido:** Acessível dentro da classe e suas subclasses.~**Pacote / Interno:** Acessível dentro da mesma fronteira de pacote.
classDiagram
class ContaBancaria {
-double saldo
#String titularConta
+getSaldo() double
}
3. Dominando as setas de relacionamento e os links de herança
Para mostrar como as classes interagem dentro do seu modelo de diagrama UML, conecte seus IDs usando strings de relacionamento especializadas. No Mermaid, a direção da linha importa: a ponta da seta aponta para a classe pai ou container.
- Herança / Generalização (Seta tracejada ou sólida):
Filho --|> Pai(Representa uma relação “é-um”). - Realização / Implementação:
Classe ..|> Interface(Representa uma classe que cumpre um contrato de interface). - Composição (Diamante sólido):
Filho --* Pai(Representa posse estrita; se o pai morrer, o filho morre). - Agregação (Diamante claro):
Filho --o Pai(Representa uma relação de coleção solta; o filho pode existir de forma independente). - Dependência:
ClasseA ..> ClasseB(Representa uma referência transitória em tempo de execução).
classDiagram
Carro --|> Veículo : "Herda de"
Motor --* Carro : "É parte de"
Melhores Práticas para Layouts de Arquitetura de Classes Limpos
- Agrupe membros da classe visualmente: Sempre agrupe suas variáveis de classe no topo do bloco de corpo e suas funções na parte inferior. Esse layout corresponde às estruturas padrão de classes em IDEs e torna seus diagramas imediatamente legíveis.
- Especifique os Tipos de Retorno: Ao declarar métodos, adicione o tipo de retorno ao final da linha do método (por exemplo,
+fetchData() DataSet). Isso fornece ao seu time de engenharia um contexto de implementação preciso. - Mantenha a Multiplicidade Clara: Para indicar contagens de arrays ou tamanhos de coleções, adicione strings de multiplicidade diretamente ao invólucro da linha de relacionamento (por exemplo,
Customer "1" --o "many" Order).
Exemplos Reais de Diagramas de Classes Mermaid.js
Exemplo 1: Subsistema de Domínio Gateway de Pagamento (Encapsulamento e Interfaces)
Este plano funcional modela um serviço de domínio de checkout online. Ele demonstra como usar modificadores de acesso, agrupar membros de classe e implementar relacionamentos de interface de forma limpa.
classDiagram
class PaymentProcessor {
<<interface>>
+processPayment(amount) boolean
+refundPayment(txnId) boolean
}
class StripeGateway {
-String apiKey
-String endpointUrl
+processPayment(amount) boolean
+refundPayment(txnId) boolean
-logTransaction(status) void
}
class PayPalGateway {
-String merchantId
+processPayment(amount) boolean
+refundPayment(txnId) boolean
}
StripeGateway ..|> PaymentProcessor : "Implementa"
PayPalGateway ..|> PaymentProcessor : "Implementa"
Análise de Sintaxe: O <<interface>> marca claramente `PaymentProcessor` como um contrato arquitetônico de alto nível. As duas classes concretas de implementação de gateway usam campos privados (-apiKey) para credenciais sensíveis, enquanto expõem rotinas públicas de pagamento (+processPayment) ligadas pela seta de realização (..|>).
Exemplo 2: Motor de Processamento de Pedidos Empresarial (Composição e Multiplicidade)
Este plano avançado do sistema mapeia um esquema complexo de gerenciamento de pedidos de comércio eletrônico, demonstrando como documentar a propriedade estrutural e contagens de objetos entre múltiplas classes interconectadas.
classDiagram
class Customer {
+int customerId
+String name
+placeOrder() Order
}
class Order {
+int orderId
+Date dateCreated
-String internalStatus
+calculateTotal() double
}
class OrderItem {
+int itemId
+int quantity
+double pricePerUnit
}
class Address {
+String street
+String city
+String postalCode
}
Customer "1" --o "many" Order : "possui"
OrderItem "1..*" --* "1" Order : "composto por"
Address "1" --> Order : "enviado para"
Análise de Sintaxe: Este exemplo ilustra a diferença entre agregação e composição. A seta com diamante sólido (--*) mostra que um `OrderItem` está firmemente ligado a um `Order` (se um pedido for excluído, seus itens individuais também serão destruídos). Por outro lado, a seta com diamante clara (--o) indica que um `Customer` possui múltiplos pedidos, mas ambas as entidades podem existir independentemente. Strings de multiplicidade (como "1..*") definem os requisitos relacionais do sistema.