Read this post in: de_DEen_USes_ESfr_FRhi_INid_IDjapl_PLru_RUvizh_CNzh_TW

Guia Completo sobre Diagramas de Classes UML (Diagrama como Código)

💡 Nota: Todos os diagramas são fornecidos em PlantUML formato. Você pode renderizá-los instantaneamente usando o Visual Paradigm Diagrama como Código.


🔹 Introdução ao UML

O que é UML?

“A Linguagem de Modelagem Unificada (UML) é uma linguagem de modelagem visual de propósito geral usada para especificar, visualizar, construir e documentar os artefatos de um sistema de software.” — Rumbaugh et al., 1999

Características Principais:

  • 🎨 Notação visual: Sintaxe gráfica para modelagem de sistemas

  • 📐 Padronizado: Padrão adotado pela OMG desde 1997

  • 🔧 Linguagem, não um método: Define notação, não processo

  • 🌐 Alcance amplo: Modela processos de negócios, funções do sistema, estruturas de código e esquemas de banco de dados

O que o UML NÃO É

Equívoco Realidade
Uma metodologia de desenvolvimento Apenas uma notação de modelagem
Uma linguagem de programação Linguagem de especificação abstrata
Apenas para programação orientada a objetos Aplicável a bancos de dados, modelagem de negócios, etc.
Precisamente definido em todos os aspectos Algumas ambiguidades semânticas permanecem nas versões iniciais

🔹 Histórico e Padronização

Cronologia da Evolução

The Evolution of Unified Modeling Language (UML)

1965-1970: Simula-67 (primeira linguagem orientada a objetos)
     ↓
Anos 1970-1980: Smalltalk no Xerox PARC
     ↓
1984: C++ introduzido por Bjarne Stroustrup
     ↓
1988-1992: Proliferação de métodos orientados a objetos (Booch, OMT, OOSE, etc.)
     ↓
1994: Rumbaugh une-se a Booch na Rational → Início da unificação
     ↓
1995: Versão preliminar UML 0.8 lançada
     ↓
1996: OMG emite RFP para linguagem padrão de modelagem
     ↓
1997: UML 1.1 adotado pela OMG (14 de novembro)
     ↓
2000: UML 1.3 publicado formalmente
     ↓
2003: UML 1.5 publicado; estrutura superior UML 2.0 aceita

Por que o UML venceu a “Guerra dos Métodos”

  • Consolidou mais de 50 métodos OO concorrentes em um único padrão

  • Apoiado por grandes players da indústria (IBM, Microsoft, Oracle, HP)

  • Forneceu mecanismos de extensão para personalização

  • Tornou-se o padrão de fato para modelagem orientada a objetos

⚠️ Perspectiva Crítica: Alguns argumentam que o UML é “uma linguagem monstro projetada por um comitê” com semânticas imprecisas nas versões iniciais.


🔹 Classes e Atributos

Estrutura da Classe

Uma classe UML é representada como um retângulo com até três compartimentos.

@startuml
class Student {
  firstName: String
  lastName: String
  email[0..1]: String
  encryptedPW: String
  + totalPoints(): Integer
  + setPassword(pw: String)
  + checkPW(pw: String): Boolean
}
@enduml

Sintaxe de Declaração de Atributos

[visibilidade] nome[multiplicidade]: Tipo [= valorPadrão] {propriedades}

Exemplos de PlantUML:

@startuml
class Student {
  + ProgramOfStudy[0..2]: String = "MIS"
  - encryptedPW: String {frozen}
  # internalID: Integer
  ~ packagePrivateData: String
}
@enduml

Escopo de Atributo

  • Escopo de instância (padrão): Cada objeto tem seu próprio valor

  • Escopo de classe (estático): Valor único compartilhado por todas as instâncias

@startuml
class Student {
  name: String
  {estático} count: Integer
}
@enduml

Chaves em UML ⚠️

Limitação Importante: O UML não tem noção embutida de chaves. Use estereótipos ou valores com marcadores como soluções alternativas.

@startuml
class Student {
  {pk} id: Integer
  {ak1} email: String
  - name: String
}
@enduml


🔹 Associações e Relacionamentos

Associação Básica e Multiplicidade

@startuml
class Exercise
class Chapter
Exercise "0..*" -- "1..1" Chapter : PertenceA
@enduml

Interpretação: Cada exercício pertence a exatamente um capítulo; um capítulo pode conter zero ou mais exercícios.

Nomes de Papel

Em vez de (ou em adição aos) nomes de associação, use nomes de papel nas extremidades da associação:

@startuml
class Person
class Company
Person "0..*" --> "0..1" Company : Funcionário/Empregador
@enduml

Implementação: O Pessoa tabela teria uma chave estrangeira empregador referenciando Empresa.

Navegabilidade

Especifique a direção de percurso com setas:

@startuml
class Exercício
class Capítulo
Exercício "0..*" --> "1" Capítulo
@enduml

  • A seta indica a direção eficiente de percurso

  • Em OODBs: implementa-se como ponteiro em uma única direção

  • Em RDBMS: as junções funcionam em ambas as direções independentemente

Tipos de coleção com {ordenado}

@startuml
class Capítulo
class Exercício
Capítulo "1" -- "0..*" Exercício : {ordenado}
@enduml

  • {ordenado}: Manter a sequência (use lista, não conjunto)

  • Implementação em RDBMS: Adicione um atributo de número de sequência

EXERCÍCIOS (
    id PRIMARY KEY,
    chapter_id REFERÊNCIAS CAPÍTULOS,
    sort_no INTEGER,
    ÚNICO (chapter_id, sort_no)
)

Qualificadores

Qualificadores particionam objetos relacionados usando um mecanismo semelhante a chave:

@startuml
class Chapter
class Exercise
Chapter "1" --> "0..1" Exercise : <<qualificador>> no: Integer
@enduml

Significado: Dado um Capítulo e um número de exercício, é retornado no máximo um Exercício.

Classes de Associação

Quando uma associação tem atributos ou operações:

@startuml
class Student
class Exercise
class Solution {
  date: Date
  points: Integer
}
Student "0..*" -- "0..*" Exercise : tem resolvido
Solution .. Student
Solution .. Exercise
@enduml

  • Um Solução objeto por par (Aluno, Exercício)

  • Força: o mesmo aluno não pode submeter duas soluções para o mesmo exercício

Composição vs. Agregação

Recursos Composição (*--) Agregação (o--)
Símbolo Diamante preto Diamante branco
Relação Todo-parte, propriedade forte Todo-parte, referência fraca
Ciclo de Vida Partes excluídas com o todo Partes independentes
Multiplicidade 1 ou 0..1 no lado do todo Qualquer
Mapeamento RDBMS ON DELETE CASCADE Chave estrangeira padrão
@startuml
class Capítulo
class Exercício
Capítulo *-- "0..*" Exercício : Composição
Capítulo o-- "0..*" Exercício : Agregação
@enduml


🔹 Operações e Métodos

Sintaxe de Declaração de Operação

@startuml
class Calculadora {
  + getTotal(idAluno: Integer, inclExtra: Boolean = true): Float {isQuery=true}
  + {static} getInstance(): Calculadora
  + {constructor} Calculadora(valorInicial: Float)
  - recalcular(): void
}
@enduml

Especificação de Parâmetros:

[direção] nome: Tipo [= valorPadrão]
  • Direções: entrada (padrão), saídaentrada/saída

  • Valores padrão habilitam parâmetros opcionais

Estereótipos Especiais de Operação

Estereótipo Propósito
{isQuery=true} Garante que não haja modificação de estado
{construtor} Cria e inicializa novas instâncias
{estático} Operação de nível de classe, sem implícitoself

Operações no Contexto de Banco de Dados

O Choque Cultural: OO enfatiza encapsulamento; relacional enfatiza acesso direto aos dados.

Estratégias de Implementação:

Tipo de Operação Implementação em RDBMS
Acesso a atributo simples SELECT/UPDATE diretos
Atributo derivado (sem parâmetros) VISÃO do Banco de Dados
Atributo derivado (com parâmetros) Procedimento armazenado ou lógica de aplicação
Aplicação de restrições complexas Gatilhos ou procedimentos de aplicação

🔹 Generalização e Herança

Generalização Básica

@startuml
class Pessoa
class Aluno
class Professor
Pessoa <|-- Aluno
Pessoa <|-- Professor
@enduml

Classes Abstratas e Operações

@startuml
classe abstrata Conta {
  - saldo: Float
  + depositar(valor: Float): void
  + {abstrato} retirar(valor: Float): void
}
@enduml

Restrições de Generalização

@startuml
class Pessoa
class Aluno
class Professor
class OutraPessoa
Pessoa <|-- Aluno : <<{disjuntas, completas}>>
Pessoa <|-- Professor : <<{disjuntas, completas}>>
Pessoa <|-- OutraPessoa : <<{disjuntas, completas}>>
@enduml

Classificação Múltipla / Discriminadores

@startuml
class Funcionário
class Equipe
class Docente
class PlanoHMO
class NãoHMO
Funcionário <|-- Equipe : <<tipo>>
Funcionário <|-- Docente : <<tipo>>
Funcionário <|-- PlanoHMO : <<seguro>>
Funcionário <|-- NãoHMO : <<seguro>>
@enduml

  • Os discriminadores agrupam especializações mutuamente exclusivas

  • Objetos podem ter um valor por dimensão de discriminador


🔹 Mecanismos de Extensão

O UML fornece três mecanismos de extensibilidade:

1. Estereótipos<< >>

Estenda a semântica do UML criando novos “subtipos” de elementos do metamodelo.

@startuml
class Cliente <<entidade>> {
  - id: Integer
  - nome: String
}
class BibliotecaMatemática <<utilitário>> {
  + sin(x: Float): Float
  + cos(x: Float): Float
}
@enduml

2. Valores com Marcadores{chave=valor}

Adicione propriedades personalizadas aos elementos do modelo.

@startuml
class Student {
  {author=sb, version=1.0, persistence=persistent}
  - id: Integer
}
@enduml

3. Restrições {...}

Adicione restrições semânticas usando texto livre, OCL ou abreviações pré-definidas.

@startuml
class Exercise {
  - no: Integer
  - points: Integer {value >= 0}
  {points <= maxPoints}
}
@enduml


🔹 UML para Design de Banco de Dados: Principais Considerações

Traduzindo UML para Esquema Relacional

Construto UML Implementação Relacional
Classe Tabela
Atributo Coluna
Chave primária {pk} Restrição PRIMARY KEY
Associação (1:*) Chave estrangeira no lado “muitos”
Associação (:) Tabela de junção/interseção
Composição Chave estrangeira + ON DELETE CASCADE
Classe de associação Tabela com chaves estrangeiras compostas + atributos
Generalização Tabelas separadas (com FK) ou tabela única com discriminador de tipo
{ordenado} associação Adicionar coluna de sequência + restrição única
Qualificador Parte de chave composta ou coluna indexada

Diferenças Críticas: Orientado a Objetos vs. Relacional

Aspecto Orientado a Objetos Relacional
Identidade Referência de objeto (surrogado) Chave primária (de negócio ou surrogado)
Operações Central para o design, encapsulado Externo (SQL, procedimentos)
Encapsulamento Atributos privados, interface pública Acesso direto à tabela por padrão
Herança Suporte nativo à linguagem Estratégias complexas de mapeamento
Relacionamentos Ponteiros/referências Chaves estrangeiras e junções

Recomendações Práticas para Designers de Banco de Dados

  1. Modelar chaves explicitamente: Use {pk}{ak1} estereótipos, pois o UML não possui suporte nativo para chaves

  2. Marcar persistência: Use {persistent} valor marcado para distinguir classes de banco de dados das classes de aplicação transitórias

  3. Simplificar operações: Mapear operações de consulta para visualizações; operações complexas para procedimentos armazenados

  4. Tratar herança com cuidado: Escolher a estratégia de mapeamento com base nos padrões de consulta

  5. Documentar restrições: Use OCL ou restrições em texto claro para regras de negócios

  6. Usar classes de associação com cautela: Apenas quando a relação possui atributos significativos


🎯 Folha de Referência Rápida

Resumo da Notação de Diagrama de Classes PlantUML

@startuml
class <<estereótipo>> NomeDaClasse {
  {tagged=valor}
  [+/-/#/~] nome[mult]: Tipo [= val] {props}
  [+/-/#/~] nome(parametros): Ret {props}
}
@enduml

Notação de Associação

@startuml
ClasseA "multA" -- "multB" ClasseB : NomeDaAssociação
ClasseA *-- ClasseB  ' Composição
ClasseA o-- ClasseB  ' Agregação
ClasseA --> ClasseB  ' Navegável
@enduml

Símbolos de Visibilidade

  • + Público

  • - Privado

  • # Protegido

  • ~ Pacote

Propriedades e Restrições Comuns

  • {estático} / {isQuery=true} / {abstrato}

  • {valor >= 0} / {xor} / {ordenado} / {pk}


💡 Pensamento Final: Diagramas de classes UML são poderosos para modelagem conceitual, mas lembre-se de que foram projetados principalmente para engenharia de software. Ao usar UML para projetos de banco de dados, esteja preparado para expandir a notação (com estereótipos, valores etiquetados, restrições) para capturar conceitos relacionais como chaves, normalização e restrições declarativas que não são nativas na fundação orientada a objetos do UML.

Guia compilado a partir de “Parte 6: Diagramas de Classes UML” por Stefan Brass, Universität Halle, 2003. Todos os diagramas formatados na sintaxe PlantUML para compatibilidade com ferramentas modernas.

Leave a Reply