UA2 — Fase de Projeto (Modelagem)
A fase de projeto transforma requisitos em uma solução técnica detalhada. É a ponte entre 'o que o sistema deve fazer' e 'como ele vai fazer'. Modelar antes de codificar reduz retrabalho e facilita a comunicação da equipe.
O lugar da fase de projeto no ciclo de vida
Após o levantamento e a análise de requisitos, a fase de projeto descreve como o sistema funcionará internamente — arquitetura, linguagens, banco de dados, interface gráfica e outros elementos — de forma que acompanhe os objetivos definidos na análise. O projeto é desenvolvido de forma iterativa: formalidade e detalhes são acrescidos por meio de revisões constantes.
| Fase | Entradas | Saídas |
|---|---|---|
| Requisitos | Necessidades do cliente | Especificação de requisitos |
| Análise | Especificação de requisitos | Modelo de domínio / casos de uso |
| Projeto / Modelagem | Modelo de análise | Diagramas UML, arquitetura, DER |
| Implementação | Diagramas e especificações | Código-fonte |
| Testes | Código-fonte e critérios de aceite | Produto validado |
Não é possível pular a fase de projeto sem pagar o preço depois. Corrigir um erro no papel custa cents; corrigi-lo em produção custa horas ou dias de engenharia.
As quatro atividades do projeto de software
O processo de projeto de sistemas de informação pode envolver quatro atividades principais:
Projeto Arquitetural
Identifica a estrutura geral do sistema: componentes principais (subsistemas ou módulos), seus relacionamentos e como são distribuídos.
Projeto de Interface
Define as interfaces entre os componentes. Uma interface precisa permite que um componente seja usado sem que outros saibam como ele é implementado.
Projeto de Componente
Projeta o funcionamento interno de cada componente. Pode ser uma declaração de funcionalidade esperada ou um modelo para gerar código automaticamente.
Projeto de Banco de Dados
Projeta as estruturas de dados do sistema e como devem ser representadas e persistidas no banco de dados.
UML — Linguagem de Modelagem Unificada
A UML (Unified Modeling Language) é o padrão adotado para documentar e comunicar decisões de projeto. A UML pode ser aplicada de três formas distintas:
UML como rascunho
Diagramas informais, frequentemente desenhados à mão em quadros brancos. Usados para explorar partes difíceis do problema antes de decidir a solução.
UML como planta
Diagramas detalhados usados tanto para engenharia reversa (entender código existente) quanto para geração de código (engenharia avante).
UML como linguagem
Especificação executável completa do sistema em UML, da qual o código é gerado automaticamente. Ainda em desenvolvimento teórico e de ferramentas.
Os 5 diagramas UML mais utilizados
Na prática, cinco diagramas da UML concentram a maior parte dos casos de uso:
| Diagrama | O que representa |
|---|---|
| Atividades | Atividades envolvidas em um processo ou processamento de dados (fluxo de trabalho). |
| Casos de Uso | Interações entre o sistema e seus atores externos (o “quê” o sistema faz). |
| Sequência | Interações entre atores e sistema, ou entre componentes, ao longo do tempo (ordem das mensagens). |
| Classes | Classes de objetos no sistema e as associações entre elas (estrutura estática). |
| Estado | Como o sistema reage a eventos internos e externos; transições entre estados finitos. |
Sequência vs. Comunicação: quando usar cada um
Dois diagramas de interação são frequentemente confundidos — vale entender a diferença:
| Critério | Diagrama de Sequência | Diagrama de Comunicação |
|---|---|---|
| Ponto forte | Mostra com clareza a ordem temporal das mensagens; amplas opções de notação | Economia de espaço — novos objetos podem ser adicionados em duas dimensões |
| Ponto fraco | Cresce horizontalmente ao acrescentar objetos; consome espaço | Mais difícil visualizar a sequência; menos opções de notação |
| Melhor para | Documentação formal, leitura de fluxo de chamadas, engenharia reversa | Rascunho em quadro branco (modelagem ágil), espaço físico limitado |
Perspectivas de modelagem
A mesma notação UML pode ser usada com três intenções diferentes:
- Perspectiva conceitual: os diagramas descrevem coisas do mundo real ou do domínio de negócio — útil na fase de análise, antes de pensar em código.
- Perspectiva de especificação: os diagramas descrevem abstrações de software com interfaces definidas, sem comprometimento com uma tecnologia específica (Java, C#, etc.).
- Perspectiva de implementação: os diagramas descrevem implementações concretas em uma tecnologia específica, prontas para guiar o desenvolvimento.
Modelagem não é burocracia
O objetivo não é gerar documentação pela documentação. É criar um entendimento compartilhado. Um diagrama desenhado numa reunião de 30 minutos pode evitar semanas de retrabalho. A escolha de quais diagramas usar fica a critério da necessidade do projeto — pode-se usar todos ou apenas alguns dos que a UML disponibiliza.
Práticas Modernas — Modelagem e UML
Ferramentas e abordagens que complementam ou substituem o uso tradicional da UML nos projetos atuais:
- UML como código — ferramentas como PlantUML e Mermaid.js permitem gerar diagramas a partir de texto puro, versionado em Git junto com o código. Fim do problema de “diagramas desatualizados em PowerPoint”.
- C4 Model (Simon Brown) — hierarquia de 4 níveis de abstração (Contexto → Container → Componente → Código) que simplifica a comunicação arquitetural sem o overhead da notação UML completa. Amplamente adotado em times ágeis.
- Architecture Decision Records (ADRs) — documentos curtos que registram por quê uma decisão arquitetural foi tomada. Substituem grandes documentos de especificação com registros imutáveis e auditáveis.
- Modelagem ágil — o manifesto ágil não bane a modelagem; recomenda “just enough design upfront”. Diagramas de sequência e componentes continuam valiosos, mas feitos em colaboração, não por um arquiteto isolado.
- Domain-Driven Design (DDD) — abordagem que conecta diretamente a modelagem do software ao domínio de negócio. Conceitos como Bounded Context e Ubiquitous Language complementam o que UML representa estruturalmente.
Dicas para a Prova
- Diagrama de atividades = diagrama de estado onde todos ou a maioria dos estados representam execuções de atividades (fluxo de trabalho).
- A vantagem de diagramas que tem relação direta com visão arquitetural é a visão mais abrangente do sistema — permite entender módulos e partes.
- A primeira atividade da fase de projeto é a representação da arquitetura do sistema (projeto arquitetural = projeto de alto nível).
- Entrada da fase de projeto: especificação de requisitos. Saída: modelos e artefatos que documentam as principais decisões tomadas.
- Diagrama de sequência: melhor para leitura de fluxo temporal de chamadas e documentação formal. Diagrama de comunicação: melhor para rascunho em quadro branco (economiza espaço).
- As três perspectivas de uso da UML: conceitual (mundo real), especificação (abstração de software sem comprometimento tecnológico), implementação (tecnologia específica).
Referências bibliográficas desta UA
- SOMMERVILLE, I. Engenharia de software. 9. ed. São Paulo: Pearson, 2011.
- FOWLER, M. UML distilled. 3. ed. Boston: Addison-Wesley, 2004.
- LARMAN, C. Utilizando UML e padrões. 3. ed. Porto Alegre: Bookman, 2007.
- ERICKSON, J.; SIAU, K. Theoretical and practical complexity of modeling methods. Communications of the ACM, v. 50, n. 8, 2007.
- REZENDE, D. A. Engenharia de software e sistemas de informação. 3. ed. Rio de Janeiro: Brasport, 2005.