📚 CAPÍTULO 01: INTRODUÇÃO E NATUREZA DO SOFTWARE


🎯 1. Objetivos de Aprendizagem & Competências

Estimativa de Dedicação: 2 horas de estudo autoguiado.
Ao final deste capítulo, você será capaz de:

  • 🔹 Compreender a evolução histórica da Engenharia de Software, a crise do software de 1968 e os princípios da Conferência da OTAN.
  • 🔹 Diferenciar software como produto de engenharia (projetado e evolutivo) versus produtos de manufatura física (sujeitos a desgaste de peças).
  • 🔹 Analisar a arquitetura de tipos de dados, mutabilidade e integridade no ecossistema moderno em Python 3.11+.
  • 🔹 Implementar classes com encapsulamento defensivo e validação de integridade para serviços corporativos.

🏢 2. Cenário Corporativo & Estudo de Caso (TecProExpress)

Imagine que você acaba de ingressar como Engenheiro de Software Júnior na TecProExpress, uma empresa nacional de logística expressa que opera 50.000 encomendas/dia. A diretoria herdou um sistema monolítico legado de 15 anos que se tornou frágil, lento e difícil de manter.

O Desafio: Seu objetivo não é apenas escrever linhas de código, mas transformar a prática empírica em uma disciplina de engenharia rigorosa, garantindo que novos módulos sejam construídos com baixo acoplamento, alta coesão e prontidão para evolução sustentável nos próximos anos.


🧠 3. Fundamentação Teórica & Modelos Visuais

3.1. A Natureza Singular do Software

Ao contrário de pontes ou automóveis, o software não se desgasta pelo atrito físico. Ele se degrada por alterações mal projetadas, acúmulo de débito técnico e divergência entre a especificação e as regras de negócio.

flowchart TD
    subgraph "PRODUTOS FÍSICOS VS SOFTWARE"
        subgraph Hardware ["🏭 Manufatura Física"]
            H1["Projeto Inicial"] --> H2["Linha de Montagem"]
            H2 --> H3["Desgaste Físico por Atrito"]
            H3 --> H4["Substituição de Peças"]
        end
        subgraph Software ["💻 Engenharia de Software"]
            S1["Elicitação & Design"] --> S2["Construção Lógica"]
            S2 --> S3["Degradação por Complexidade"]
            S3 --> S4["Refatoração & Evolução Contínua"]
        end
    end
    style Hardware fill:#fff3e0,stroke:#e65100
    style Software fill:#e1f5fe,stroke:#0277bd

3.2. Os 4 Pilares da Engenharia de Software

A Engenharia de Software estrutura-se na integração equilibrada entre Pessoas, Processos, Métodos e Ferramentas:

flowchart LR
    P["👥 Pessoas<br>(Stakeholders & Times)"] --> PR["⚙️ Processos<br>(Ágil, Scrum, Kanban)"]
    PR --> M["📐 Métodos<br>(UML, DDD, Testes)"]
    M --> F["🛠️ Ferramentas<br>(Python, Git, CI/CD, Docker)"]
    
    style P fill:#e8f5e9,stroke:#2e7d32
    style PR fill:#ede7f6,stroke:#4527a0
    style M fill:#e3f2fd,stroke:#1565c0
    style F fill:#fbe9e7,stroke:#d84315

💻 4. Aplicação Prática & Código Executável (Python 3.11+)

No código corporativo moderno, a aplicação dos princípios de orientação a objetos e auto-defesa de integridade impede que estados inconsistentes sejam criados na memória.

📋 Pré-requisitos e Instalação

Este módulo utiliza exclusivamente recursos nativos do Python 3.11+ (dataclasses e decimal). Nenhuma instalação externa é necessária:

# Ambiente padrão Python 3.11+ (sem dependências externas)

💻 Código Completo e Autocontido (tecpro_frete.py)

Crie o arquivo tecpro_frete.py e insira o código abaixo:

"""
Módulo: tecpro_frete.py
Domínio: Validação e cálculo defensivo de encomendas corporativas.
Stack: Python 3.11+
"""
from dataclasses import dataclass
from decimal import Decimal

@dataclass(frozen=True)
class Encomenda:
    codigo_rastreio: str
    peso_kg: Decimal
    valor_declarado: Decimal
    destino_uf: str

    def __post_init__(self):
        if not self.codigo_rastreio or len(self.codigo_rastreio) < 8:
            raise ValueError("Código de rastreio inválido (mínimo 8 caracteres).")
        if self.peso_kg <= Decimal("0.0"):
            raise ValueError("O peso da encomenda deve ser estritamente positivo.")
        if self.valor_declarado < Decimal("0.0"):
            raise ValueError("O valor declarado não pode ser negativo.")

    def calcular_seguro(self, taxa_percentual: Decimal = Decimal("0.01")) -> Decimal:
        """Calcula a taxa de seguro proporcional ao valor declarado."""
        return self.valor_declarado * taxa_percentual

if __name__ == "__main__":
    try:
        pacote = Encomenda(
            codigo_rastreio="BR-SP-2026-001",
            peso_kg=Decimal("2.450"),
            valor_declarado=Decimal("1500.00"),
            destino_uf="SP"
        )
        seguro = pacote.calcular_seguro()
        print("✅ Encomenda criada com sucesso!")
        print(f"📦 Pacote: {pacote.codigo_rastreio} | Seguro: R$ {seguro:.2f}")
    except ValueError as erro:
        print(f"❌ Falha de integridade: {erro}")

🚀 Como Executar

Execute o script no terminal:

python tecpro_frete.py

🖥️ Saída Esperada no Terminal

✅ Encomenda criada com sucesso!
📦 Pacote: BR-SP-2026-001 | Seguro: R$ 15.00

💡 5. Checkpoint de Engenharia & Boas Práticas

Boas Práticas & Anti-Patterns

  • Princípio SFB (Safe From Bugs): Centralize regras de validação nos construtores ou métodos de fábrica. Nunca permita que um objeto transite pela aplicação em estado inconsistente.
  • Anti-Pattern Primitive Obsession: Evite passar múltiplos tipos primitivos soltos (str, float) entre funções. Agrupe-os em estruturas semânticas ricas (Value Objects ou dataclasses).

🔗 6. Conexão com os Projetos Integradores

Projeto IntegradorComo o conceito deste capítulo é aplicado no PI
PI-01: ManuTrackMapeamento de ativos industriais com blindagem de integridade e horas de operação.
PI-04: ShopFlowCriação de modelos de Pedido e Itens de Carrinho com validação imutável de valores.

🧪 7. Quiz de Fixação e Autoavaliação (Formative Assessment)

🧪 Quiz de Autoavaliação — Capítulo 01

1. Qual das alternativas abaixo melhor descreve uma característica única do software em relação a produtos físicos (hardware)?

  • A) O software se desgasta fisicamente com o uso contínuo pelo atrito mecânico.
  • B) O custo principal do software concentra-se na reprodução fabril de cópias.
  • C) O custo do software concentra-se no design e arquitetura; ele não se desgasta fisicamente, mas degrada por acúmulo de complexidade e débito técnico.
  • D) O software é manufaturado em linhas de montagem industriais automatizadas.
💡 Ver Resposta e Justificativa

Resposta Correta: C
Justificativa: O software não é manufaturado — ele é projetado. Seu custo principal reside na engenharia e arquitetura. Ele não sofre desgaste de peças, mas degrada se não for continuamente refatorado e mantido.


2. Em que ano ocorreu a Conferência da OTAN que marcou o nascimento formal da disciplina de 'Engenharia de Software'?

  • A) 1975
  • B) 1995
  • C) 1968
  • D) 2001
💡 Ver Resposta e Justificativa

Resposta Correta: C
Justificativa: Em 1968, em Garmisch (Alemanha), a conferência da OTAN formalizou a crise do software e estabeleceu a necessidade de aplicar o rigor da engenharia ao desenvolvimento.


3. Como são denominados os sistemas antigos que sustentam operações corporativas vitais, mas possuem arquiteturas rígidas e alto acoplamento?

  • A) Sistemas Serverless
  • B) Sistemas Legados
  • C) Microsserviços Reativos
  • D) Sistemas de Alta Disponibilidade
💡 Ver Resposta e Justificativa

Resposta Correta: B
Justificativa: Sistemas legados são ativos corporativos essenciais que continuam em operação comercial, mas exigem cuidados especiais de migração e manutenção devido à arquitetura legada.


🛠️ 8. Ponte para a Ação: Laboratório Prático

🎯 Próximo Passo Prático

Coloque esta teoria em prática executando o roteiro de laboratório autoguiado:
👉 ATIVIDADE 01: ESCOPO E PERSONAS


📌 9. Resumo Executivo & Key Takeaways

  • Engenharia vs Programação: Programar é escrever código funcional; Engenharia de Software é construir sistemas sustentáveis, testáveis e escaláveis ao longo de décadas.
  • Degradação de Software: O software degrada por alterações desordenadas e falta de testes, não por desgaste de peças.
  • Pilares de Excelência: Pessoas, Processos, Métodos e Ferramentas trabalhando de forma sinérgica.
  • Auto-defesa de Dados: Validar dados no momento da instanciação impede a propagação silenciosa de bugs na aplicação.