Guia Extra: Engenharia de Software e Modelagem UML • Bloco 2: Requisitos e Processos em Modelo

🗺️ Mapa Conceitual do Capítulo

flowchart TD
    subgraph ATORES["Atores (Papéis Externos)"]
        AP["Ator Primário\n(Inicia a interação para atingir meta)"]
        AS["Ator Secundário\n(Sistema de Apoio / Gateway de Pagamento)"]
        AT["Ator Temporal\n(Cron Job / Timer do Sistema)"]
    end

    subgraph SISTEMA["Fronteira do Sistema (System Boundary)"]
        UC_BASE["Caso de Uso Base: Realizar Matrícula"]
        UC_INC["Caso de Uso Incluído: Validar CPF\n<<include>> (Obrigatório e Reutilizável)"]
        UC_EXT["Caso de Uso Extensão: Solicitar Bolsa\n<<extend>> (Opcional sob Ponto de Extensão)"]
        
        UC_BASE -.->|"<<include>>"| UC_INC
        UC_EXT -.->|"<<extend>>"| UC_BASE
    end

    AP --> UC_BASE
    UC_BASE --> AS

    subgraph ESPECIFICACAO["Especificação Textual Estruturada (Alistair Cockburn)"]
        EP_META["Meta no Nível do Mar (Objetivo do Usuário)"]
        EP_COND["Pré-condições e Pós-condições (Garantia de Sucesso)"]
        EP_FLUX["Fluxo Principal (Caminho Feliz)"]
        EP_ALT["Fluxos Alternativos e Tratamento de Exceções"]
    end

    UC_BASE --> ESPECIFICACAO

    style ATORES fill:#ede7f6,stroke:#512da8,stroke-width:2px
    style SISTEMA fill:#e1f5fe,stroke:#0288d1,stroke-width:2px
    style ESPECIFICACAO fill:#e8f5e9,stroke:#4caf50,stroke-width:2px
    style UC_BASE fill:#fff3e0,stroke:#ff9800,stroke-width:2px
    style UC_INC fill:#fce4ec,stroke:#e91e63,stroke-width:2px
    style UC_EXT fill:#e0f2f1,stroke:#009688,stroke-width:2px

🎭 1. Conceito e Elementos Centrais do Modelo de Casos de Uso

Introduzido por Ivar Jacobson no método OOSE e incorporado à UML, o Modelo de Casos de Uso é a técnica padrão da indústria para capturar requisitos funcionais sob a perspectiva dos usuários. Ele estabelece uma fronteira rigorosa entre o que reside dentro do software e o que está fora dele no ambiente operacional.

O modelo é composto por dois artefatos complementares:

  1. O Diagrama de Casos de Uso: Funciona como o mapa visual ou “índice gráfico” das capacidades oferecidas pelo sistema.
  2. A Especificação Textual: Onde reside o verdadeiro valor da engenharia, documentando passo a passo o diálogo entre os atores e o sistema.

Elementos Estruturais do Diagrama

  • Fronteira do Sistema (System Boundary): Um retângulo delimitador que contém todos os casos de uso internos. Tudo o que estiver fora do retângulo é considerado ambiente externo.
  • Atores: Entidades externas que interagem com o sistema. Um ator representa um papel, nunca o cargo de uma pessoa física específica.
    • Ator Primário: Quem inicia o caso de uso para alcançar um objetivo mensurável (posicionado convencionalmente à esquerda).
    • Ator Secundário: Sistemas externos, bancos ou serviços de terceiros que fornecem suporte ao caso de uso (posicionados à direita).
    • Ator Temporal: Eventos baseados em tempo (ex: “Relógio do Sistema à meia-noite”).
  • Caso de Uso: Uma sequência de ações executadas pelo sistema que produz um resultado observável de valor para o ator. Sua nomenclatura deve obrigatoriamente iniciar com um verbo no infinitivo seguido de um substantivo (ex: Emitir Boleto, Efetuar Matrícula, Consultar Saldo).

🔗 2. Os Relacionamentos da UML: Semântica e Regras de Ouro

Relacionamento Notação Visual Semântica Formal Regra de Ouro Prática
Associação Linha contínua sólida Comunicação direta bidirecional entre ator e caso de uso. Atores nunca se associam diretamente entre si no diagrama.
<<include>> Seta tracejada: Base $\rightarrow$ Incluído O caso base sempre e obrigatoriamente executa o caso incluído. Usado para reaproveitar lógicas comuns em múltiplos casos de uso (ex: autenticação, logs).
<<extend>> Seta tracejada: Extensão $\rightarrow$ Base O caso de extensão insere comportamento opcional no caso base sob uma condição. A seta aponta para o caso base. O caso base precisa desconhecer a extensão para manter baixo acoplamento.
Generalização Linha com triângulo fechado vazado Especialização e herança de comportamento (de atores ou casos). Exemplo: Professor é uma especialização do ator Usuário. 
classDiagram
    direction LR
    class AtorPrimario["Ator: Aluno"]
    class UC_Inscricao["UC01: Inscrever em Disciplina"]
    class UC_Verificar["UC02: Verificar Pré-requisitos"]
    class UC_Trancar["UC03: Solicitar Trancamento Excepcional"]

    AtorPrimario --> UC_Inscricao
    UC_Inscricao ..> UC_Verificar : <<include>>
    UC_Trancar ..> UC_Inscricao : <<extend>> (se reprovação >= 2)

🎚️ 3. A Granularidade dos Casos de Uso (Níveis de Cockburn)

Alistair Cockburn estabeleceu uma metáfora clássica baseada em altitude para calibrar o nível de abstração dos casos de uso:

  1. Nível Muito Alto (Nuvens / Céu): Objetivos estratégicos corporativos (ex: “Gerenciar Cadeia de Suprimentos”). Abrange múltiplos sistemas e processos de negócio completos.
  2. Nível do Mar (Sea Level - Padrão Ouro): Objetivos da tarefa do usuário (ex: “Cadastrar Novo Fornecedor”). É o nível canônico para a UML: uma única sessão de uso onde o usuário atinge um objetivo concreto.
  3. Nível Submarino (Peixe / Fundo do Mar): Subfunções técnicas pequenas demais para serem casos de uso autônomos (ex: “Digitar Senha”, “Clicar em Salvar”). Não devem ser diagramados como casos de uso isolados.

📝 4. Template Formal de Especificação Textual (Cockburn)

# UC04 — Efetuar Reserva de Exemplar de Livro

- **Identificador:** UC04
- **Ator Primário:** Leitor (Aluno ou Professor)
- **Atores Secundários:** Provedor de Notificação por E-mail (SendGrid)
- **Pré-condições:** 
  1. O Leitor deve estar devidamente autenticado no portal.
  2. O Leitor não pode possuir multas em aberto superiores a R$ 10,00.
- **Pós-condições (Garantia de Sucesso):**
  1. A reserva é gravada na base de dados com status "PENDENTE".
  2. A posição na fila de espera é recalculada e informada ao usuário.
  3. Um e-mail de confirmação é despachado.

### Fluxo Principal (Caminho Feliz):
1. O Leitor localiza o título desejado e solicita a reserva de um exemplar.
2. O Sistema verifica se todos os exemplares físicos daquele título estão emprestados.
3. O Sistema valida que o Leitor não ultrapassou o limite máximo de 3 reservas ativas.
4. O Sistema inclui o Leitor na fila de espera do título e atribui a posição ordinal.
5. O Sistema exibe a data limite estimada de espera e o número do protocolo da reserva.
6. O Sistema agenda o envio de e-mail de confirmação através do ator secundário.

### Fluxos Alternativos:
- **2a. Existe exemplar disponível na estante:**
  1. O Sistema informa que a reserva é desnecessária pois há cópias disponíveis no balcão.
  2. O Sistema oferece a opção de gerar um mapa de localização na estante.
  3. O caso de uso termina.

### Fluxos de Exceção:
- **3a. Leitor possui pendência financeira ou suspensão cadastral:**
  1. O Sistema bloqueia a transação e exibe o extrato das multas em aberto.
  2. O Sistema encerra o fluxo sem efetivar a reserva.

🚫 5. Anti-Patterns Clássicos de Modelagem

  1. Decomposição em Fluxograma Funcional: Criar casos de uso para cada etapa sequencial de uma tela (“Validar Campo Nome”, “Clicar no Botão OK”).
  2. Proliferação de CRUDs Vazios: Criar quatro casos de uso idênticos (Incluir, Alterar, Excluir, Consultar) para entidades simples. O padrão correto é unificar em um único caso de uso abrangente: “Manter Cadastro de Clientes”.
  3. Abuso de <<extend>> e <<include>>: Criar teias complexas de dezenas de setas tracejadas. Diagramas legíveis possuem no máximo 5 a 10 casos de uso por pacote funcional.