📘 Guia Completo: Diagramas de Classes ao Longo das Fases de Desenvolvimento

📘 Introdução: Dos Componentes Isolados aos Sistemas Conectados — A Evolução dos Diagramas de Classes

No mundo do desenvolvimento de software, os diagramas de classes são mais do que simples ilustrações estáticas — são plantas vivas que evoluem junto com o sistema que representam. Em cada fase do desenvolvimento, desde os requisitos iniciais até a manutenção pós-lançamento, o nível de detalhe, a estrutura e a intenção por trás de um diagrama de classes mudam drasticamente. No entanto, um erro comum persiste: componentes isolados.

Considere a classe típica de processador de pagamentos — ProcessadorCartaoCredito, ProcessadorPayPal, e ProcessadorStripe — frequentemente modelados como entidades autônomas e desconectadas em um diagrama de classes. Embora isso possa ser suficiente na fase inicial de design, revela um problema mais profundo: a falta de integração e clareza comportamental. Essas classes existem em isolamento, sem mecanismo claro para seleção, configuração ou flexibilidade em tempo de execução. Como resultado, o design torna-se rígido, difícil de estender e difícil de testar.

Este artigo explora como os diagramas de classes deveriam evoluir ao longo das fases de desenvolvimento — desde modelos conceituais de alto nível até designs detalhados e prontos para implementação — e como conexões estratégicas entre componentes podem transformar um sistema fragmentado em uma arquitetura coesa e escalável. Vamos nos concentrar em um exemplo do mundo real: o subsistema de processamento de pagamentos — e mostrar como aplicar o Padrão Strategy, Padrão Factory, e injeção de dependência pode preencher a lacuna entre classes isoladas e um sistema verdadeiramente dinâmico e sustentável.

Através dos diagramas PlantUML e insights práticos de design, você aprenderá a como:

• Ir além das relações estáticas entre classes.
• Modelar comportamentos do mundo real e dinâmicas em tempo de execução.
• Projete sistemas que sejam flexíveis, extensíveis e fáceis de evoluir.

No final, você verá que um diagrama de classes bem conectado não é apenas uma ferramenta de documentação — é uma visão de como seu software deveria funcionar.

Diagramas de classes são uma das ferramentas UML mais poderosas para modelar sistemas orientados a objetos. O seu nível de detalhe muda significativamente dependendo do estágio de desenvolvimento. Este guia o conduz por quatro estágios principais do desenvolvimento de software e mostra como os diagramas de classes evoluem conforme necessário.

---

🧩 1. Estágio 1: Requisitos e Projeto Conceitual (Fase Inicial)

🎯 Propósito:

• Capturar conceitos de domínio de alto nível.

• Identificar entidades principais e suas relações.

• Facilitar a comunicação entre partes interessadas e desenvolvedores.

🔍 Características:

• Foco em entidades de domínio e relações.

• Sem métodos ou atributos (ou mínimos).

• Use generalização, associação, agregação, e composição.

• Evite detalhes de implementação (por exemplo, modificadores de acesso, tipos de dados).

📌 Exemplo: Sistema de E-Comércio (Nível Conceitual)

@startuml
' Diagrama de Classes Conceitual - Fase 1: Requisitos

class Cliente {
  +nome: String
  +email: String
}

class Produto {
  +nome: String
  +preco: Decimal
}

class Pedido {
  +dataPedido: Date
  +status: String
}

Cliente "1" -- "0..*" Pedido : realiza
Pedido "1" -- "1..*" Produto : contém
Produto "1" -- "0..*" Pedido : vendido em

note right of Cliente
  Representa um usuário que compra produtos
end note

note right of Produto
  Item físico ou digital à venda
end note

note right of Pedido
  Um registro de transação
end note

@enduml

✅ Caso de Uso: Apresentar aos interessados, aprimorar o modelo de domínio e validar com analistas de negócios.

---

🧱 2. Fase 2: Análise e Projeto de Alto Nível (Meio do Projeto)

🎯 Propósito:

• Aprimorar o modelo de domínio para uma estruturação mais detalhada.

• Introduzir atributos, operações básicas, e associações.

• Começar a identificar interfaces, classes abstratas, e padrões de design.

🔍 Características:

• Adicionar atributos e operações (com tipos mínimos).

• Use classes abstratas e interfaces.

• Introduza multiplicidade e navegabilidade.

• Comece a pensar sobre responsabilidades e coesão.

📌 Exemplo: Sistema de Comércio Eletrônico (Nível de Análise)

@startuml
' Diagrama de Classes de Alto Nível - Fase 2: Análise

@startuml
' Diagrama de Classes de Alto Nível - Fase 2: Análise

classe abstrata Pedido {
  - orderID: String
  - orderDate: Date
  - status: String
  +calcularTotal(): Decimal
  +validar(): Boolean
  +salvar(): void
}

classe Cliente {
  - customerID: String
  - name: String
  - email: String
  +adicionarPedido(pedido: Pedido): void
  +getPedidos(): List<Pedido>
}

classe Produto {
  - productID: String
  - name: String
  - price: Decimal
  - stockQuantity: Integer
  +estaEmEstoque(): Boolean
  +atualizarEstoque(quantidade: Integer): void
}

classe ItemPedido {
  - quantity: Integer
  - unitPrice: Decimal
  +getSubtotal(): Decimal
}

Cliente "1" -- "0..*" Pedido : coloca
Pedido "1" -- "1..*" ItemPedido : contém
ItemPedido "1" -- "1" Produto : referencia
Produto "1" -- "0..*" ItemPedido : aparece em

interface ProcessadorPagamento {
  +processarPagamento(valor: Decimal): Boolean
}

Pedido "1" -- "1" ProcessadorPagamento : usa

@enduml

✅ Caso de Uso: Revisão de design, alinhamento da equipe e decisões iniciais de arquitetura.

---

🔧 3. Fase 3: Projeto Detalhado e Implementação (Fase Tardia)

🎯 Propósito:

• Prepare-se para a codificação.

• Defina atributos exatos, métodos, tipos de dados, modificadores de acesso.

• Incluir restrições, dependências, associações, e composição.

• Use padrões de design (por exemplo, Fábrica, Estratégia, Singleton).

🔍 Características:

• Assinaturas completas de métodos e tipos de retorno.

• Uso de modificadores de acesso (+, -, #).

• Dependências, herança, interfacessão totalmente especificadas.

• Pode incluir restrições (por exemplo, <<restrição>>).

📌 Exemplo: Sistema de Comércio Eletrônico (Design Detalhado)

@startuml
' Diagrama de Classe Detalhado - Fase 3: Implementação

@startuml
' Diagrama de Classe Detalhado - Fase 3: Implementação

class Customer {
  - customerID: String
  - name: String
  - email: String
  - address: String
  +addOrder(order: Order): void
  +getOrders(): List<Order>
  +validateEmail(): Boolean
}

class Order {
  - orderID: String
  - orderDate: Date
  - status: OrderStatus
  - total: Decimal
  +calculateTotal(): Decimal
  +validate(): Boolean
  +save(): void
  +cancel(): void
}

class OrderItem {
  - quantity: Integer
  - unitPrice: Decimal
  +getSubtotal(): Decimal
}

class Product {
  - productID: String
  - name: String
  - price: Decimal
  - stockQuantity: Integer
  +isInStock(): Boolean
  +updateStock(amount: Integer): void
  +getPrice(): Decimal
}

class PaymentProcessor {
  +processPayment(amount: Decimal): Boolean
}

class CreditCardProcessor {
  +processPayment(amount: Decimal): Boolean
}

class Payment {
  - paymentID: String
  - amount: Decimal
  - method: String
  - timestamp: Date
  +confirm(): Boolean
}

' Herança
Customer <|-- PremiumCustomer

' Interfaces
PaymentProcessor <|-- CreditCardProcessor
PaymentProcessor <|-- PayPalProcessor

' Associações
Customer "1" -- "0..*" Order : coloca
Order "1" -- "1..*" OrderItem : contém
OrderItem "1" -- "1" Product : referencia
Order "1" -- "1" Payment : possui
PaymentProcessor "1" -- "1" Payment : processa

' Restrições
note right of Order
  Status: [Pendente, Confirmado, Enviado, Cancelado]
end note

note right of Product
  Estoque deve ser > 0 para ser vendido
end note

@enduml

✅ Caso de Uso: Entrega ao desenvolvedor, geração de código e documentação de design.

---

🛠️ 4. Fase 4: Manutenção e Evolução (Pós-Lançamento)

🎯 Propósito:

• Refletir mudanças do mundo realno sistema.

• Documentar refatoração, obsolescência, novos recursos.

• Apoiar rastreamento da dívida técnica e compreensão do sistema.

🔍 Características:

• Pode incluir obsoleto classes/métodos.

• Mostrar novas classes, elementos renomeados, componentes removidos.

• Use estereótipos (<<obsoleto>>, <<singleton>>, <<fábrica>>).

• Freqüentemente simplificado para legibilidade.

📌 Exemplo: Sistema de Comércio Eletrônico (Fase de Manutenção)

@startuml
‘ Sistema de Pagamento Reformulado: Padrão Estratégia + Fábrica

@startuml
‘ Sistema de Pagamento Reformulado: Estratégia + Padrão de Fábrica

‘ Interface
class ProcessadorDePagamento {
+processarPagamento(amount: Decimal): Boolean
}

‘ Estratégias Concretas
class ProcessadorDeCartaoDeCredito {
+processarPagamento(amount: Decimal): Boolean
}

class ProcessadorDePayPal {
+processarPagamento(amount: Decimal): Boolean
}

class ProcessadorDeStripe {
+processarPagamento(amount: Decimal): Boolean
}

‘ Padrão de Fábrica
class FabricaDeProcessadorDePagamento {
+criarProcessador(type: String): ProcessadorDePagamento
+getTiposDisponiveis(): List<String>
}

‘ Serviço que utiliza a estratégia
class ServicoDePedido {
– processador: ProcessadorDePagamento
+criarPedido(customer: Cliente, items: List<ItemDoPedido]): Pedido
+definirProcessadorDePagamento(processador: ProcessadorDePagamento): void
}

‘ Entidade de Pagamento
class Pagamento {
– idDoPagamento: String
– amount: Decimal
– method: String
– timestamp: Date
+confirm(): Boolean
}

‘ Cliente e Pedido (simplificado)
class Cliente {
– customerID: String
– name: String
– email: String
+addOrder(order: Pedido): void
+getOrders(): Lista<Pedido>
}

class Pedido {
– orderID: String
– orderDate: Date
– status: StatusPedido
– total: Decimal
+calculateTotal(): Decimal
+validate(): Boolean
+save(): void
+cancel(): void
}

‘ Estereótipos para clareza
PaymentProcessor <<interface>>
CreditCardProcessor <<strategy>>
PayPalProcessor <<strategy>>
StripeProcessor <<strategy>>
PaymentProcessorFactory <<factory>>
OrderService <<service>>

‘ Herança: Padrão Strategy
CreditCardProcessor <|– PaymentProcessor
PayPalProcessor <|– PaymentProcessor
StripeProcessor <|– PaymentProcessor

‘ Factory cria processadores
PaymentProcessorFactory “1” — “1” PaymentProcessor : cria

‘ OrderService usa um processador (injeção de dependência)
OrderService “1” — “1” PaymentProcessor : usa

‘ OrderService usa a factory para definir o processador
OrderService “1” — “1” PaymentProcessorFactory : configura via

‘ Payment depende do processador
Payment “1” — “1” PaymentProcessor : usa

‘ Associações
Customer “1” — “0..*” Order : coloca
Order “1” — “1..*” OrderItem : contém
OrderItem “1” — “1” Product : referencia
Order “1” — “1” Payment : tem

‘ Restrições
note right of Order
Status: [Pendente, Confirmado, Enviado, Cancelado]
fim note

note right of Payment
Método: “Cartão de Crédito”, “PayPal”, “Stripe”
fim note

note right of PaymentProcessorFactory
Tipos suportados: “Cartão de Crédito”, “PayPal”, “Stripe”
Pode ser estendido sem modificar o OrderService
fim note

@enduml

✅ Caso de Uso: Onboarding de novos desenvolvedores, refatoração do sistema, rastreamento de auditoria.

---

🔄 Resumo: Evolução dos Diagramas de Classes

Fase	Foco	Nível de Detalhe	Elementos Principais
1. Requisitos	Conceitos de Domínio	Nível Superior	Entidades, associações
2. Análise	Estrutura do Sistema	Médio	Atributos, operações, interfaces
3. Implementação	Código Pronto	Alto	Tipos, modificadores de acesso, padrões
4. Manutenção	Evolução do Sistema	Adaptativo	Estereótipos, obsolescência, simplificação

---

🛠️ Dicas para Usar o PlantUML

• Use @startuml e @enduml para envolver diagramas.

• Use <<estereótipo>>para padrões de design ou metadados.

• Use nota à direita depara documentação.

• Use +, -, #para visibilidade (público, privado, protegido).

• Use <<interface>>, <<abstrato>>, <<singleton>>para clareza.

• Gere imagens por meio de PlantUML Onlineou plugins de IDE (VS Code, IntelliJ).

---

📚 Pensamentos Finais

Diagramas de classe são não estáticos — eles evoluem com o projeto. Use-os strategicamente:

• Início: Comunique-se com partes interessadas não técnicas.

• Meio: Alinhe os desenvolvedores sobre a arquitetura.

• Fim: Guiar a implementação e a qualidade do código.

• Pós-Lançamento: Mantenha o conhecimento do sistema.

✅ Dica Profissional: Controle de versão dos seus arquivos PlantUML junto com o código — são documentações vivas!

---

✅ Conclusão: Projetando não apenas classes, mas sistemas

Diagramas de classes são mais do que diagramas — são mapas de intenção, plantas de colaboração, e registros vivos da evolução arquitetônica. Como vimos, seu valor não está na forma inicial, mas na forma como eles adaptam ao longo do ciclo de vida do desenvolvimento — desde as abstrações de alto nível dos requisitos até os modelos precisos e prontos para implementação do design avançado.

A jornada desde classes de processador isoladas até um sistema conectado e orientado por estratégias ilustra uma verdade fundamental: um bom design não é apenas sobre definir componentes — é sobre definir como eles trabalham juntos. Quando CreditCardProcessor, PayPalProcessor, e StripeProcessor são tratados como estratégias intercambiáveis — orquestradas por uma fábrica e injetadas em serviços — o diagrama deixa de ser uma fotografia estática. Torna-se um modelo dinâmico de flexibilidade, escalabilidade e manutenibilidade.

Ao usar padrões como Strategy, Fábrica, e Injeção de Dependência, transformamos classes isoladas em um ecossistema coeso e extensível. Isso não é apenas sobre diagramas melhores — é sobre construir software melhor. Permite que equipes:

• Adicionar novos métodos de pagamento sem alterar o código existente.
• Testar o comportamento de forma isolada.
• Evolver sistemas com confiança, mesmo anos após o lançamento.

Por fim, os diagramas de classes mais poderosos não são aqueles que mostram cada campo e método em detalhe — mas aqueles que contam uma história: uma história de colaboração, adaptabilidade e design com visão de futuro.

Então, ao esboçar seu próximo diagrama de classes, pergunte a si mesmo:

Minhas classes são apenas definidas — ou estão conectadas?
Elas são isoladas — ou fazem parte de um sistema que pode crescer?

Porque, no fim das contas, os melhores diagramas de classes não descrevem apenas o que o sistema é — eles inspiram como ele deveria se tornar.