Guia Extra: Engenharia de Software e Modelagem UML • Bloco 5: Do Modelo ao Código e à Evolução

🗺️ Mapa Conceitual do Capítulo

flowchart TD
    subgraph PROCESS_PRODUCT["Qualidade de Processo vs Qualidade de Produto"]
        ISO["ISO/IEC 25010 (SQuaRE)\n8 Características de Qualidade de Produto"]
        CMMI["Modelos de Maturidade\nCMMI v2.0 (1 a 5) · MPS.BR (G a A)"]
        FAGAN["Inspeções Formais de Fagan\nRevisões Estáticas por Pares & Checklists"]
        CK["Métricas CK (Chidamber & Kemerer)\nWMC · DIT · NOC · CBO · RFC · LCOM"]
    end

    subgraph EVOLUTION["Evolução e Manutenção de Software"]
        LEHMAN["Leis de Lehman (E-Type Systems)\nMudança Contínua & Complexidade Crescente"]
        MAINT["Taxonomia ISO/IEC 14764\nCorretiva · Adaptativa · Perfectiva · Preventiva"]
        TECH_DEBT["Quadrante de Débito Técnico (Fowler)\nPrudente/Imprudente · Deliberado/Inadvertido"]
    end

    subgraph SCM["Gerência de Configuração de Software (GCS)"]
        CI_ITEM["Itens de Configuração (CI) & Baselines"]
        BRANCH["Estratégias de Branching\nGitFlow vs Trunk-Based Development & Feature Flags"]
        SEMVER["Versionamento Semântico (SemVer 2.0)\nMAJOR.MINOR.PATCH & Conventional Commits"]
    end

    PROCESS_PRODUCT --> EVOLUTION
    EVOLUTION --> SCM

    style PROCESS_PRODUCT fill:#ede7f6,stroke:#512da8,stroke-width:2px
    style EVOLUTION fill:#e1f5fe,stroke:#0288d1,stroke-width:2px
    style SCM fill:#e8f5e9,stroke:#2e7d32,stroke-width:2px

🏅 1. Qualidade de Processo e Modelos de Maturidade

A engenharia de software distingue com rigor a Qualidade de Produto (atributos intrínsecos do software em execução, padronizados pela norma ISO/IEC 25010 SQuaRE) da Qualidade de Processo (a eficácia e repetibilidade dos métodos de engenharia empregados pela organização para conceber e entregar valor).

CMMI (Capability Maturity Model Integration)

Mantido pelo ISACA (originalmente concebido pelo Software Engineering Institute da Carnegie Mellon University), o CMMI v2.0 avalia a capacidade organizacional através de cinco níveis de maturidade em sua representação por estágios (staged representation):

Nível de Maturidade Denominação Filosofia Operacional e Características
Nível 1 Inicial Processos imprevisíveis, reativos e caóticos. O sucesso depende exclusivamente do heroísmo individual dos profissionais.
Nível 2 Gerenciado Projetos planejados, executados, medidos e controlados ao nível de equipe. Gestão básica de requisitos e baseline de configuração.
Nível 3 Definido Processos padronizados e documentados em nível corporativo, customizados para projetos específicos através de diretrizes organizacionais.
Nível 4 Quantitativamente Gerenciado O desempenho dos processos é controlado por meio de técnicas estatísticas rigorosas e métricas quantitativas de causa-efeito.
Nível 5 Em Otimização Foco contínuo na inovação incremental e na melhoria contínua dos processos com base no entendimento estatístico de variações.

MPS.BR (Melhoria de Processo do Software Brasileiro)

Coordenado pela Softex, o MPS.BR foi desenhado para viabilizar a maturidade em pequenas e médias empresas de tecnologia. Sua estrutura escalonada divide a evolução em sete níveis graduais: Nível G (Parcialmente Gerenciado) até o Nível A (Em Otimização), alinhando normas ISO/IEC 12207 e ISO/IEC 15504 a custos acessíveis ao mercado nacional.

Inspeções Formais de Código e Modelagem (Michael Fagan)

Formulada em 1976 na IBM, a Inspeção de Fagan provou que revisões estáticas formais removem até 80% dos defeitos antes da execução do primeiro teste de unidade. O processo segue um ritual rigoroso com papéis segregados: Moderador (conduz a sessão), Autor (escreveu o artefato), Leitor (guia a leitura do código/modelo) e Inspetores (buscam defeitos orientados por checklists de conformidade).

📐 2. Métricas de Qualidade OO: A Suite Chidamber & Kemerer (CK)

Para mensurar matematicamente o acoplamento, a coesão e a complexidade do design orientado a objetos, a engenharia adota a clássica suíte métrica de Chidamber & Kemerer (1994):

Métrica CK Nome Completo Significado Matemático e Limite Saudável
WMC Weighted Methods per Class Soma da complexidade ciclomática de todos os métodos da classe. Classes com WMC elevado concentram responsabilidades indevidas (God Classes).
DIT Depth of Inheritance Tree Distância máxima da classe até a raiz da hierarquia. DIT > 5 indica fragilidade da classe base e acoplamento desmedido.
NOC Number of Children Quantidade de subclasses imediatas que herdam da classe. NOC alto exige testes exaustivos na superclasse para evitar violação de Liskov.
CBO Coupling Between Objects Contagem de classes externas às quais a classe está vinculada. CBO alto dificulta reuso e manutenção.
RFC Response For a Class Quantidade de métodos locais somados a todos os métodos chamados por ela em outros objetos. RFC alto amplia a propagação de falhas em cadeia.
LCOM Lack of Cohesion in Methods Mede se os métodos operam sobre os mesmos atributos internos. LCOM alto indica que a classe deve ser dividida (violação do SRP).

🔧 3. Dinâmica da Evolução e Manutenção de Software

Um sistema de software em produção não é estático; ele é um artefato sociotécnico vivo submetido às célebres Leis de Lehman:

  • 1ª Lei (Mudança Contínua): Todo sistema computacional que reflete a realidade do mundo real (E-Type System) deve se adaptar continuamente, caso contrário perde utilidade progressivamente.
  • 2ª Lei (Complexidade Crescente): À medida que um sistema evolui, sua entropia e complexidade interna aumentam, a menos que esforços intencionais de refatoração sejam aplicados para reduzi-las.

Tipologias de Manutenção (ISO/IEC 14764)

Pesquisas seminais da indústria (Lientz & Swanson e Ian Sommerville) revelam uma distribuição de esforço surpreendente ao longo do ciclo de vida:

pie title Distribuição Real do Esforço de Manutenção na Indústria
    "Manutenção Perfectiva / Evolutiva (Novas Features)" : 65
    "Manutenção Adaptativa (Novos Ambientes / Leis)" : 18
    "Manutenção Corretiva (Bugs em Produção)" : 17
  • Corretiva: Reparação reativa de defeitos funcionais e incidentes em ambiente de produção.
  • Adaptativa: Ajustes derivados de alterações nas plataformas externas (atualização de SGBD, migração de nuvem, conformidade LGPD).
  • Perfectiva (Evolutiva): Implementação de novas funcionalidades requeridas pelo mercado e otimizações de performance.
  • Preventiva: Engenharia proativa para sanar dívidas técnicas e refatorar algoritmos antes que falhas se manifestem.

O Quadrante do Débito Técnico (Martin Fowler)

O débito técnico traduz o custo composto futuro de decisões apressadas tomadas no presente:

  • Prudente & Deliberado: “Temos que lançar a feature hoje para a Black Friday; registramos no backlog o débito e refatoraremos na Sprint subsequente.” (Válido e gerenciável).
  • Imprudente & Deliberado: “Não temos tempo para escrever arquitetura nem testes; apenas empurre para produção.” (Inaceitável na engenharia).
  • Prudente & Inadvertido: “Agora que terminamos o domínio, compreendemos como deveríamos ter estruturado as entidades desde o início.” (Aprendizado natural).
  • Imprudente & Inadvertido: “A equipe não conhece padrões de projeto básicos nem princípios SOLID e construiu um monólito espaguete sem perceber.” (Desastre estrutural).

🗂️ 4. Gerência de Configuração e Estratégias de Branching

A Gerência de Configuração de Software (GCS) assegura a rastreabilidade e integridade de todos os Itens de Configuração (CI) que formam a entrega:

gitGraph
    commit id: "v1.0.0" tag: "v1.0.0"
    branch feature/emprestimo-online
    checkout feature/emprestimo-online
    commit id: "feat: entidade reserva"
    commit id: "test: unitario regra"
    checkout main
    merge feature/emprestimo-online id: "v1.1.0" tag: "v1.1.0"
    branch hotfix/multa-feriado
    checkout hotfix/multa-feriado
    commit id: "fix: regra de feriados"
    checkout main
    merge hotfix/multa-feriado id: "v1.1.1" tag: "v1.1.1"
  1. Item de Configuração (CI): Qualquer artefato submetido a versionamento (código-fonte, modelos UML em DaC, esquemas SQL de migração, manifestos de infraestrutura).
  2. Baseline Arquitetural: Conjunto consistente de versões de CIs formalmente revisado e congelado para servir de base a novas entregas.
  3. Estratégias de Ramificação (Branching):
    • GitFlow: Abordagem robusta com branches de longa duração (main, develop, release/*, feature/*), excelente para softwares com ciclos de lançamento formais e auditorias estritas.
    • Trunk-Based Development (TBD): Todos os desenvolvedores integram código diariamente no branch main através de pequenos commits suportados por Feature Flags (Toggles) e testes automatizados instantâneos.
  4. Versionamento Semântico (SemVer 2.0.0): Formato MAJOR.MINOR.PATCH:
    • MAJOR: Quebra de compatibilidade retroativa na API ou contratos.
    • MINOR: Acréscimo de funcionalidade retrocompatível.
    • PATCH: Correção de bugs retrocompatível.
    • Conventional Commits: Padronização semântica das mensagens de commit (feat:, fix:, docs:, refactor:, perf:, chore:, feat!:) permitindo a geração 100% automatizada de CHANGELOG.md e releases sem intervenção humana.