Fundamentos da Modelagem & UML

1. O que são modelos?

Um modelo é um descrição completa de um sistema a partir de uma perspectiva particular e atua como uma representação simplificada da realidade. Você cria modelos porque sistemas complexos não podem ser totalmente compreendidos em sua totalidade.

Quatro objetivos principais da modelagem:

1. Visualizar um sistema como pretendido.

2. Especificar a estrutura ou o comportamento de um sistema.

3. Fornecer um modelo para orientar a construção do sistema.

4. Documentar decisões de design.

Quatro princípios da modelagem

• O modelo que você escolhe influencia diretamente como um problema é abordado.

• Todo modelo pode ser expresso em níveis variados de precisão.

• Os modelos mais eficazes permanecem firmemente conectados à realidade.

• Nenhum modelo único é suficiente; sistemas complexos exigem múltiplas perspectivas.

O que é UML?

A Linguagem Unificada de Modelagem (UML) é uma linguagem gráfica padronizada gerenciada pelo Grupo de Gestão de Objetos (OMG). É explicitamente não uma metodologia ou procedimento, mas uma especificação técnica e gráfica usada para:

“Visualize, especifique, construa e documente os artefatos de um sistema intensivo em software.”

O UML fornece um formato universal de planta para elementos conceituais (processos de negócios, funções do sistema) e implementações concretas (declarações de código, esquemas de banco de dados, componentes reutilizáveis).

Os Quatro Pilares do UML

Propósito	Descrição
Visualização	Garante que todos os interessados falem a mesma língua. Modelos explícitos eliminam erros de comunicação e revelam aspectos do sistema invisíveis sem modelagem.
Especificação	Cria definições precisas, inequívocas e completas do sistema.
Construção	Mapeia diretamente para linguagens de programação (Java, C++, VB), tabelas de RDBMS ou armazenamentos de OODBMS. Suporta engenharia para frente (modelo → código) e engenharia reversa (código → modelo).
Documentação	Captura a arquitetura do sistema, requisitos, planos de teste, cronogramas de projeto e gestão de lançamentos.

---

2. O Ecossistema de Diagramas UML

O UML 2.2 define 14 tipos de diagramas, categorizados em dois grupos principais:

1. Modelos Estruturais (arquitetura estática)

2. Modelos de Comportamento e Interação (processos dinâmicos)

Diferentes diagramas atendem a diferentes perspectivas dos interessados:

• Visão de Casos de Uso: funcionalidade do usuário final

• Visão Lógica: Analistas e Designers (estrutura do sistema)

• Visualização de Processo: Gerenciamento de software (desempenho, escalabilidade, throughput)

• Visualização de Implementação: Programadores (componentes concretos)

• Visualização de Implantação: Integradores de sistemas (topologia, instalação, comunicação)

---

3. Diagramas Principais UML Explicados

🔹 Diagrama de Casos de Uso

• Propósito: Modela as funções pretendidas de um sistema e seu ambiente. Atua como um contrato entre clientes e desenvolvedores.

• Componentes: Atores, Casos de Uso e suas relações.

• Diagramas Complementares: Atividade (fluxo dentro de um caso de uso), Sequência (colaboração de objetos para realizar um caso de uso).

🔹 Diagrama de Atividade

• Propósito: Visualiza o fluxo passo a passo de eventos dentro de um processo ou caso de uso.

• Elementos Principais:

  • Ação: Uma etapa discreta no fluxo de trabalho.

  • Fluxo: Sequência de atividades.

  • Decisão: Divide o fluxo com base em uma condição de guarda[condição].

  • Fork: Inicia threads concorrentes.

  • Join: Finaliza threads concorrentes (sincronização).

• Exemplo: Fluxo de matrícula de curso com verificações, resolução de conflitos e atualizações simultâneas do horário.

🔹 Diagrama de Sequência

• Propósito: Mostra como os objetos interagem ao longo de tempo para cumprir um caso de uso.

• Elementos Principais:

  • Linha de Vida: Linha vertical que mostra a existência de um objeto ao longo do tempo.

  • Objeto/Classe: Participante na interação.

  • Mensagem: Dados ou chamadas de método trocados entre objetos.

  • Ocorrência de Execução: Retângulo fino que mostra quando um objeto está ativamente processando.

  • Fragmentos Combinados: opt (execução opcional), loop (execução repetida), ref (referencia outra interação).

🔹 Diagrama de Comunicação

• Propósito: Alternativa aos diagramas de sequência. Enfatiza relacionamentos estruturais entre objetos em vez da ordem temporal.

• Elementos Principais:Objetos ligados entre si, com mensagens numeradas que indicam a sequência de interação ao longo das ligações.

🔹 Diagrama de Componentes

• Propósito: Mostra a estrutura em tempo de execução no nível de componentes de software.

• Elementos Principais: Partes modulares do sistema ocultas por interfaces externas. Muitas vezes inclui classes para mostrar relações de implementação.

🔹 Diagrama de Implantação

• Propósito: Mapeia artefatos de software para hardware físico.

• Elementos Principais:

  • Nó: Representa uma máquina física ou ambiente de execução.

  • Artefato: Representa um arquivo físico ou unidade implantável.

  • Elemento Proprietário: Mostra relações aninhadas ou contidas.

---

4. Dominando Diagramas de Classes e Relações

Diagramas de classes representam a estrutura estática de um sistema. São fundamentais para especificações de dados (por exemplo, INSPIRE) e não não mostram informações temporais.

Anatomia da Classe

Compartimento	Descrição
Nome	Identificador da classe (por exemplo, ParcelaCadastral). Muitas vezes inclui estereótipos como «TipoDeElemento».
Atributos	Propriedades nomeadas com tipos de dados (por exemplo, - Endereço : char, - IdadeÁrvore : int). Tipos suportados: Inteiro, LongInt, Double, Char, Data, Booleano, String, Geometria, etc.
Operações	Comportamentos/métodos da classe. Formato: + nomeOperação(tipoEntrada) : tipoRetorno.

Tipos de Relacionamento

Relacionamento	Símbolo	Significado
Associação	───────	Ligação geral entre classes. Inclui nomes de papéis, setas de navegação e cardinalidade (1..*, 0..*, 1..2, etc.).
Generalização	─────▷	Herança. A subclasse (fonte) herda todas as características da superclasse (alvo).
Agregação	◇─────	Relacionamento “parte-de”. A parte pode existir de forma independentedo todo. (Diamante vazio)
Composição	◆─────	Relação forte de “parte de”. A existência da partedepende inteiramentedo todo. (Diamante preenchido)

Exemplo do Material de Treinamento:

• Pessoa → Cortador de madeira (Generalização: Cortador de madeira herdaNome, Gênero)

• Floresta ◇─ Árvore (Agregação: Árvores podem existir sem uma floresta específica)

• Cortador de madeira ◆─ Funcionários (Composição: Funcionários não podem existir de forma independente da entidade Cortador de madeira neste contexto)

---

5. Aplicação Prática: Modelagem de Cadastro INSPIRE

O material de treinamento utiliza oEspecificação de Dados INSPIRE sobre Cadastro para demonstrar a aplicação prática de UML.

Exercício 1: Modelagem de uma Classe Principal

Tarefa: Crie a ParcelaCadastral classe.
Estrutura da Solução:

«featureType» ParcelaCadastral
- Endereço : char
- APN (Número da Parcela) : char
- Fronteira : GM_Surface
- Centróide : GM_Point
- Rótulo : char
- ReferênciaCadastralNacional : String
- ValorArea : double (opcional)
- PontoReferência : GM_Point (opcional)

Observação: Existem múltias soluções válidas. Os atributos devem refletir características comuns do mundo real.

Exercício 2: Modelagem de Relacionamentos

Tarefa: Conecte ParcelaCadastral, FronteiraCadastral, e ZonaAdministrativa.
Decisões-Chave de Modelagem:

• ParcelaCadastral ──── FronteiraCadastral: Associação/Composição (a fronteira define a parcela; frequentemente 1..1 ou 1..* cardinalidade). Papéis: +éFronteira / +temFronteira.

• ParcelaCadastral ◇── ZonaAdministrativa: Agregação/Associação. A existência da zona não depende da parcela. A parcela pertence a múltiplas zonas hierárquicas (1..* a 0..*).

• Lição: Escolha os tipos de relacionamento com base na dependência de ciclo de vida e nas regras de negócios. Os diagramas devem refletir a realidade, não forçar restrições artificiais.

---

6. Melhores Práticas para Modelagem UML Eficiente

1. Use Diagramas Estrategicamente: Os diagramas visualizam perspectivas específicas. Nenhum sistema complexo pode ser compreendido a partir de um único diagrama.

2. Reutilize Elementos em Diferentes Diagramas: Uma única classe pode aparecer em diagramas de classes, máquinas de estado, diagramas de sequência e visualizações de implantação, cada um destacando um aspecto diferente.

3. Ajuste a Precisão ao Público-Alvo: Ajuste a complexidade do diagrama de acordo com o público: usuário final, desenvolvedor, integrador de sistemas ou gerente de projeto.

4. Valide com a Realidade: Verifique continuamente se os elementos do modelo, relacionamentos e cardinalidades refletem o comportamento real do sistema e as regras do domínio.

5. Aproveite o Suporte de Ferramentas: Use ferramentas compatíveis com UML (por exemplo, Sparx Systems) para engenharia reversa/avançada, verificação de consistência e geração de código.

---

Conclusão

UML é uma linguagem poderosa e padronizada para comunicação, design e documentação de sistemas de software e intensivos em dados. Ao dominar os diagramas principais (especialmente Classe, Sequência, Atividade e Caso de Uso) e compreender a semântica dos relacionamentos (Associação, Generalização, Agregação, Composição), os profissionais podem criar mapas precisos e alinhados à realidade que pontuam a lacuna entre requisitos conceituais e implementação técnica.