Prepare-se para defender sua arquitetura e aprender com o feedback.
1. Defesa de Projeto (Básico 1)
Contexto: Um analista deve saber explicar suas escolhas técnicas.
Pergunta: Por que a fase de apresentação é considerada tão importante quanto a fase de desenho dos diagramas na vida real de um escritório de projetos?
2. O Olhar do Outro (Básico 2)
Contexto: A avaliação por pares (Peer Review) é uma prática comum de qualidade.
Pergunta: Como o feedback de outros alunos pode ajudar a melhorar a qualidade técnica dos seus diagramas UML?
3. Auto-crítica (Intermediário 1)
Contexto: Nenhum modelo é perfeito de primeira.
Pergunta: Ao rever o seu projeto final, qual diagrama você considera o mais difícil de manter atualizado e por quê?
4. Do Modelo ao Código (Intermediário 2)
Contexto: UML serve para guiar a construção.
Pergunta: Se um desenvolvedor pegar sua documentação hoje, qual o item (diagrama ou descrição) que você acredita ser o mais crucial para que ele não cometa erros de implementação?
5. Desafio: Simulação de Consultoria (Desafio)
Contexto: Durante sua apresentação, um "cliente" questiona por que você usou Composição em vez de Agregação em uma relação crítica de banco de dados.
Pergunta: Como você justificaria essa escolha tecnicamente, focando na integridade dos dados e no ciclo de vida dos objetos?
---
📚 Gabarito e Soluções Comentadas
Gabarito Explicado Respostas e explicações para os exercícios da **Aula 16**. --- ### ✅ 1. O Valor da Documentação (Básico) **Resposta Sugerida:** Uma documentação UML de alta qualidade serve como o "Manual de Construção" para os desenvolvedores. Se a documentação estiver correta, qualquer time técnico deve ser capaz de construir o software com o mínimo de dúvidas. --- ### ✅ 2. Feedback e Peer Review (Básico) **Resposta Sugerida:** O Peer Review (revisão por pares) ajuda a identificar erros de lógica que o autor original não percebeu por estar muito "mergulhado" no problema. É uma prática comum em grandes empresas de tecnologia (Code Review). --- ### ✅ 3. Defesa Técnica (Intermediário) **Explicação:** Defender o projeto não é apenas "mostrar os desenhos", mas sim explicar **por que** você escolheu aquela solução arquitetural (ex: "Usei composição aqui para garantir a integridade dos dados"). --- ### ✅ 4. Critérios de Avaliação (Intermediário) **Itens Críticos:** 1. **Rastreabilidade:** O diagrama de classes reflete os requisitos? 2. **Sintaxe UML:** As setas e símbolos estão corretos de acordo com a norma? 3. **Clareza:** O diagrama é visualmente limpo ou está poluído (spaghetti)? --- ### ✅ 5. Desafio: O Analista como Consultor (Desafio) **Resolução Sugerida:** Ao receber uma crítica pesada sobre seu modelo: 1. Não leve para o lado pessoal; foque no problema técnico. 2. Pergunte: "Qual alternativa você sugere para resolver esse gargalo?". 3. Documente a mudança e atualize os diagramas, demonstrando humildade e profissionalismo. ---