📚 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
- 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 Objectsoudataclasses).
🔗 6. Conexão com os Projetos Integradores
| Projeto Integrador | Como o conceito deste capítulo é aplicado no PI |
|---|---|
| PI-01: ManuTrack | Mapeamento de ativos industriais com blindagem de integridade e horas de operação. |
| PI-04: ShopFlow | Criaçã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
🧪 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
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.