Now Reading: Dominando os Relacionamentos de Casos de Uso UML: O Poder e o Perigo de «include» e «extend»

1
  • 01

    Dominando os Relacionamentos de Casos de Uso UML: O Poder e o Perigo de «include» e «extend»

Read this post in: de_DEen_USes_ESfr_FRhi_INid_IDjapl_PLru_RUvizh_CNzh_TW

Dominando os Relacionamentos de Casos de Uso UML: O Poder e o Perigo de «include» e «extend»

UMLYesterday

No mundo dos requisitos de software e modelagem de sistemas, UML (Linguagem de Modelagem Unificada) permanece uma pedra angular para visualizar o comportamento do sistema. Entre seus recursos mais poderosos, mas frequentemente mal compreendidos, estão os «include» e  «extend»  relacionamentos entre casos de uso. Esses mecanismos são projetados para reduzir a duplicação, gerenciar a variabilidade, e melhorar a modularidade em modelos de casos de uso. No entanto, seu uso incorreto é comum—levando a diagramas excessivamente complexos, confusão entre os interessados e perda de foco no valor para o usuário.

 

 

Este artigo oferece um guia compreensivo, prático e baseado em especialistas para compreender, aplicar e evitar os erros comuns de «include» e «extend». Vamos explorar seus verdadeiros significados, os comparar lado a lado, examinar por que caem no mesmo armadilha dos DFDs (decomposição funcional) e oferecer melhores práticas modernas para equipes de 2025–2026—especialmente aquelas que trabalham em ambientes ágeis, lean ou híbridos.

🔹 Semântica Central: O que «include» e «extend» Realmente Significam

✅ «include»: Reutilização Obrigatória – O “Sub-fluxo Sempre-Obrigatório”

Definição:
O relacionamento «include» representa umobrigatório, sempre executado fluxo secundário que é fatorado para reutilização em múltiplos casos de uso.

📌 Características Principais:

  • Sempre executado: O caso de uso incluído é executado toda vez que o caso de uso base é invocado.

  • O caso de uso base está incompleto sem ele: Sem o comportamento incluído, o caso de uso base não pode cumprir seu propósito.

  • Direção da dependência: A seta apontado base → incluído.

  • Significado independente: O caso de uso incluído é tipicamentenão significativo sozinho—ele só faz sentido como parte de um processo maior.

  • Analogia: Como umchamada de funçãoousubrotina em programação—essencial para a rotina principal.

🧠 Mnemônico Clássico:

“Para fazerLogin, você deveAutenticar Usuário.”
“Para fazerSacar Dinheiro, você deve Validar PIN.”

Estes são etapas não negociáveis. Você não pode fazer login sem autenticação. Você não pode sacar dinheiro sem validar o PIN.

💡 Quando usar:

  • Quando um comportamento comum, complexo e reutilizável aparece em dois ou mais casos de uso.

  • Exemplos:

    • Autenticar Usuário

    • Registrar Registro de Auditoria

    • Enviar Notificação

    • Validar Formato de Entrada

✅ Regra de Ouro: Use «incluir» apenas quando o comportamento reutilizado for significativo, não trivial, e aparece em ≥2–3 casos de uso.

✅ «extender»: Variação Opcional – O “Acrescentar Condicional”

Definição:
O relacionamento «extend» defineopcional, condicional ou variantecomportamento quese conecta aum ponto específicoponto de extensãodo caso de uso base.

📌 Características Principais:

  • Executado condicionalmente: Apenas é executado sob certas circunstâncias.

  • O caso de uso base é completo por si só: O fluxo normal funciona sem a extensão.

  • Direção da dependência: A seta apontado estendido → base (para trás).

  • Significado autônomo: O caso de uso estendido équase nunca significativo por si só—ele só faz sentidoem contexto.

  • Analogia: Como umgancho, plugin, ouAOP (programação orientada a aspectos) conselho—adiciona comportamento em um ponto definido.

🧠 Mnemônico Clássico:

“Enquanto estiver fazendo Reservar Voo, você pode querer Selecionar Assento Preferido.”
“Enquanto estiver fazendo Pagar com Cartão de Crédito, você pode ter que Digitar Código 3D Seguro.”

Esses são melhorias opcionais—não são necessários para o fluxo principal.

💡 Quando usar:

  • Para modelar caminhos alternativos, exceções, ou recursos opcionais.

  • Quando um caso de uso tem comportamentos variáveis baseados em condições (por exemplo, papéis de usuário, estados do sistema, preferências).

  • Exemplos:

    • Aplicar Desconto (extends Colocar Pedido)

    • Solicitar Reembolso (extends Processar Pagamento)

    • Gerar Comprovante em PDF (extends Concluir Transação)

✅ Regra de Ouro: Use «extend» com parcimônia—apenas para variações significativas com clareza pontos de extensão.

🔍 Comparação Rápida: «include» vs «extend»

Aspecto «include» «extend»
Execução Sempre Às vezes / condicionalmente
O UC Base é Completo Sozinho? ❌ Não — depende do incluído ✅ Sim — completo sem extensões
Direção da Dependência Base → Incluído Estendendo → Base
Direção da Setas Aponta para o caso de uso incluído Aponta para o caso de uso base
Objetivo Principal Reutilização obrigatória, etapas compartilhadas Gerenciar fluxos opcionais/variantes
Analogia Chamada de função / subrotina Ponto de gancho / plugin / orientação AOP
Significado Independente? Raramente Quase nunca
Melhor Para Preocupações reutilizáveis, complexas e transversais Comportamento condicional, opcional ou alternativo

⚠️ A “Armadilha da Decomposição”: Por que os Diagramas de Casos de Uso saem dos trilhos

Assim como DFD (Diagramas de Fluxo de Dados) sofrem com o armadilha da decomposição funcional, os diagramas de casos de uso são propensos à mesma doença letal: sobre-decomposição.

📉 A Armadilha da Decomposição Funcional do DFD (Resumo):

  • As equipes continuam dividindo processos em bolhas cada vez menores.

  • Os diagramas explodem em dezenas de funções pequenas e de baixo nível.

  • O o propósito original—entregar valor ao usuário—é perdido.

  • Acaba parecendo pseudo-código ou design de algoritmo interno, não o comportamento do usuário.

🧨 O Caso de Uso “Doença da Decomposição Funcional”:

  • Cada pequeno passo torna-se seu próprio caso de uso:

    • Digite o nome de usuário

    • Digite a senha

    • Clique no botão de login

    • Valide o formato

    • Exiba a mensagem de erro

  • «incluir» é aplicado liberalmente para dividir cada ação.

  • Resultado: Uma hierarquia profunda de casos de uso (A → B → C → D…) sem objetivo claro do ator.

  • Os diagramas tornam-se difíceis de manter, confusos, e inúteis para os interessados.

❌ Flaga Vermelha: Se o seu diagrama de casos de uso tiver mais de 15–20 casos de uso, ou se a maioria dos casos de uso básicos tem de 2 a 4 passos, você provavelmente está na armadilha.

🛠️ Por que isso acontece: Armadilhas comuns e mal-entendidos

Armadilha Explicação Como evitar
Excesso de uso de «include» Tratar cada subpasso como um caso de uso reutilizável. Use apenas «include» para significativo, reutilizável, transversal comportamentos (por exemplo, autenticação, registro).
Confusão na direção da seta Desenhando as setas de «include» no sentido contrário (base ← incluído) ou as setas de «extend» no sentido direto. Lembre-se: include = base → incluído; extend = estendendo → base.
Usar «extend» para alternativas Modelar fluxos alternativos dentro um caso de uso como «extend» em vez de usar alternativas textuais. Use fluxos alternativos textuais para a maioria das variações. Reserve «extend» para extensões verdadeiramente opcionais.
Criando cadeias de inclusão A → B → C → D → E… Evite cadeias profundas. Se precisar de múltiplas inclusões, considere refatoração em um único caso de uso reutilizável.
Pontos de extensão vagos Adicionando relacionamentos «extend» sem pontos de inserção claros e nomeados. Defina pontos de extensão explícitos (por exemplo, “Após confirmação do pagamento”) no caso de uso base.
Acúmulo de elementos no diagrama Muitos casos de uso e relacionamentos → ruído visual. Mantenha os diagramas pequenos, focados e centrados no ator. Use múltiplos diagramas por subsistema.
Confusão dos interessados Interessados não técnicos acham difícil entender «include/extend». Use cenários textuais ou mapas de histórias de usuário para clareza.
Modelagem de nível de design Modelando a arquitetura interna (por exemplo, “chamar banco de dados”) em vez de objetivos do usuário. Mantenha o foco em valor do ator—não implementação.
Debates intermináveis Equipes discutindo sobre “é incluir ou estender?” em vez de escrever cenários. Use heurísticas práticas e priorize clareza sobre formalidade.

✅ Melhores Práticas para 2025–2026: Uma Abordagem Moderna e Ágil

O cenário da engenharia de requisitos mudou. Equipes ágeis, enxutas e orientadas a produto estão se afastando cada vez mais dos diagramas UML pesados em favor de técnicas leves e focadas no valor técnicas.

🎯 Princípio Central: Foque no Valor do Ator, Não na Estrutura Interna

❗ Pergunte esta pergunta antes de adicionar qualquer «incluir» ou «estender»:
“Essa relação ajuda o usuário a entender o objetivo, ou é apenas dividir o sistema?”

✅ Práticas Modernas Recomendadas:

1. Use «incluir» com parcimônia — Apenas para comportamentos reutilizáveis principais

  • Use apenas para preocupações transversais que aparecem em múltiplos casos de uso.

  • Exemplos:

    • Autenticar Usuário

    • Enviar Notificação por E-mail

    • Registrar Evento de Segurança

    • Aplicar Regras de Negócio

❌ Evite: Digite o Nome de Usuário, Clique em Enviar, Validar Formato de E-mail

2. Prefira Fluxos Alternativos Textuais em vez de «extend»

  • Em vez de:

    «extend»: Selecionar Assento Preferido → Reservar Voo

  • Use:

    Caso de Uso: Reservar Voo
...
Fluxo Alternativo:
  1. Usuário seleciona a opção "Assento Preferido".
  2. Sistema exibe o mapa de assentos.
  3. Usuário seleciona o assento.
  4. Sistema aplica a preferência de assento.

✅ Por quê? Os fluxos textuais são mais fáceis de ler, mais flexíveis, e menos propensos a uso indevido.

3. Mantenha Diagramas de Casos de Uso Pequenos e Focados

  • Um diagrama por ator ou subsistema.

  • Limite a 5–10 casos de uso por diagrama.

  • Use diagramas de pacotes ou diagramas de contexto para mostrar a estrutura de alto nível.

4. Pergunte: “Um Mapa de História de Usuário comunicaria isso melhor?”

  • Se você estiver usando 10+ relacionamentos «incluir»/«estender», considere substituir o diagrama por:

    • Um mapa de história de usuário

    • Um tabela baseada em cenários

    • Um fluxograma simples com caminhos principais

🔄 Tendência moderna: Muitas equipes ágeis evitam diagramas de casos de uso por completo ou usam-nos apenas para descoberta de alto nível.

5. Use «extend» Apenas para Variantes Significativas

  • Reserve «extend» paraopcional, não essencialrecursos que:

    • Sãoraramente usados

    • Sãodependentes do contexto

    • Sãoindependentesdo objetivo principal

✅ Exemplo:
Processar Pagamento (básico)
Aplicar Autenticação 3D Segura (extend) — apenas quando exigido pelo banco

❌ Evite:
Digitar Número do Cartão → Validar Cartão → Processar Pagamento (todos devem ser etapas no mesmo caso de uso)

📊 Resumo: As Regras Douradas de «include» e «extend»

Regra Orientação
1. «include» = Obrigatório Use apenas paraessenciais, reutilizáveisetapas que aparecem em ≥2 casos de uso.
2. «extend» = Opcional Use apenas paracondicional, variante ou raracomportamentos.
3. O caso de uso base deve ser completo «extend»: o base funciona sozinho. «include»: o base é incompleto sem ele.
4. Mantenha simples Se um caso de uso tem menos de 4–6 passos após «include»/«extend», você já o decompsô demais.
5. Priorize a legibilidade Cenários textuais > diagramas complexos.
6. Evite cadeias Não A → B → C → D. Refatore em um único caso de uso reutilizável.
7. Conheça seu público-alvo Os interessados não se importam com as setas «include»—eles se importam com o valor.
Pergunte: “Este é um objetivo do usuário ou um passo interno?” Se não for um objetivo para o ator, provavelmente não deveria estar em um caso de uso.

🎯 Pensamento final: Ferramentas, não armadilhas

«include» e «extend» sãoferramentas poderosas—não regras rígidas. Foram projetadas para:

  • Reduzir a duplicação

  • Gerenciar a variabilidade

  • Melhorar a manutenibilidade

Mas comoa decomposição funcional em DFDs, elas se tornamarmas perigosasquando são usadas em excesso. O perigo real não são as próprias relações—éperder de vista o objetivo do usuário.

🔥 Lembre-se:
Um caso de uso não é um processo técnico.
É umhistória sobre o que o usuário deseja alcançar—e como o sistema ajuda.

Quando em dúvida, questione-se:

“Um usuário entenderia isso sem saber UML?”
Se não, simplifique.
Se sim, você está no caminho certo.

📚 Leitura adicional e referências

  • Especificação UML (OMG): www.omg.org/spec/UML

  • Martin Fowler – Modelagem de Casos de Uso: Padrões de Análise & UML Resumido

  • Ivar Jacobson – A vantagem dos objetos: Trabalho fundamental sobre casos de uso

  • Modelagem Ágil (AM) por Scott W. Ambler

  • Mapeamento de Histórias de Usuário por Jeff Patton – Uma alternativa moderna a diagramas complexos

✅ A regra da frase única

Use «include» para reutilização obrigatória, «extend» para variação opcional — mas apenas quando realmente adiciona valor. Caso contrário, mantenha-o simples.

Porque no final das contas, o objetivo não é desenhar diagramas perfeitos diagramas UML—é construir sistemas que entreguem valor real a pessoas reais.

📌 Nota do Autor (2025–2026):
À medida que as equipes se deslocam para centrados em produto, orientados por valor, e colaborativo desenvolvimento, o papel dos diagramas UML tradicionais está evoluindo. «include» e «extend» permanecem úteis — mas apenas quando usados com moderação, clareza e propósito. Deixe-os servir o usuário, não o diagrama.

Related Posts

Recent Comments

Nenhum comentário para mostrar.
Sidebar Search
Loading

Signing-in 3 seconds...

Signing-up 3 seconds...