Fundamentos de Engenharia de Software: Guia de Projetos

1. Proposta e Artefatos de um Projeto de Software

O projeto corresponde a uma das três atividades técnicas: projeto, implementação e testes. A fase de projeto evolui a modelagem do sistema, sendo implementada com a adição de requisitos tecnológicos ou não funcionais.

Uma especificação de projeto deve:

• Contemplar todos os requisitos explícitos no modelo de análise e todos os requisitos implícitos desejados pelo cliente;
• Ser um guia legível e compreensível para aqueles que irão codificar, testar e manter o software;
• Fornecer um quadro completo do software, tratando aspectos funcionais, comportamentais e de dados, segundo uma perspectiva de implementação.

Os subprodutos gerados são:

• Projeto da Arquitetura do Software: define os grandes componentes estruturais do software e seus relacionamentos.
• Projeto de Dados: projeta a estrutura dos dados necessária para implementar o software.
• Projeto Procedimental: refina e detalha a descrição dos componentes estruturais da arquitetura do software.
• Projeto de Interfaces: descreve como o software deverá se comunicar internamente (interfaces internas), com outros sistemas (interfaces externas) e com as pessoas que o utilizam (interface de usuário).

2. Domínio do Problema vs. Domínio da Solução

O Domínio do Problema, especificado na fase de análise, busca o entendimento do problema atacado, focando em seu escopo, restrições e premissas. O Domínio da Solução busca uma solução técnica específica para o problema identificado, sendo definido na fase de projeto. Cabe ao arquiteto de software buscar a solução mais aderente ao negócio com a melhor relação custo/benefício.

3. O Projeto como Processo Iterativo

O projeto de software é um processo iterativo pois requisitos podem ter sido entendidos de forma incompleta ou parcial. Assim, faz-se necessário um novo entendimento da proposta e a melhoria dos itens técnicos. Além disso, novas imposições do negócio podem direcionar para uma solução específica, exigindo a reformulação da solução inicial.

4. Características de um Bom Projeto de Software

• Representar a totalidade do que será construído;
• Utilizar a estratégia de dividir para conquistar;
• Refinar a orientação para a construção de cada detalhe;
• Prover diferentes visões (domínio do problema, gestão de tarefas, interface de usuário, gestão de dados);
• Plantar abordagens alternativas com base nos requisitos, recursos e conceitos de projeto;
• Ser rastreável ao modelo de análise;
• Permitir ajustes em virtude de requisitos instáveis;
• Não "reinventar a roda": reutilizar componentes e utilizar padrões de projeto.

5. Atributos de Qualidade de um Projeto de Software

• Completude: atendimento aos requisitos do cliente.
• Desempenho: uso otimizado dos recursos computacionais (hardware, software e peopleware).
• Facilidade de uso: qualidade da interface de usuário.
• Segurança: proteção contra acessos indevidos.
• Confiabilidade: preservação da disponibilidade do sistema e integridade das informações.
• Manutenibilidade: facilidade de alteração.
• Economia: custo adequado ao escopo do software.

6. O que é um Projeto Arquitetural?

Consiste na alocação do modelo de requisitos em uma tecnologia específica, determinando quais processos rodarão em quais processadores, onde os dados serão armazenados e qual a comunicação necessária entre processadores. É uma extensão do modelo de análise visando sua implementação.

7. Classes de Negócio vs. Classes Técnicas

As classes de análise (objetos de negócio) representam os elementos pertinentes durante a realização dos casos de uso. As classes técnicas atuam como suporte, ajudando os objetos de negócio a persistirem, comunicarem-se, apresentarem-se na interface de usuário e terem desempenho aceitável.

8. Atividades de um Projeto Detalhado

• Atribuição de responsabilidades entre os objetos;
• Construção de diagramas de classes e documentação (ex: Javadoc);
• Construção de diagramas de interação (opcional);
• Levantamento de necessidades de concorrência;
• Considerações de tratamento de falhas;
• Detalhamento do formato de saída (interface, relatórios, transações).

9. Entidades no Modelo de Análise e Projeto

Pode haver entidade no modelo de análise que não será representada no projeto (raro). Pode haver entidade adicional no projeto (frequente).

10. Arquitetura Cliente-Servidor

É um processamento cooperativo de informações por um conjunto de processadores, onde clientes iniciam requisições realizadas por servidores centrais.

• 2 camadas: 1 camada de interface e 1 camada contendo regras de negócio + dados.
• 3 camadas: Separação clara entre camada de interface, camada de regra de negócio e camada de dados.
• N camadas: Não há uma identificação clara das camadas lógicas ou físicas.

11. Papel das Camadas

• Apresentação: Captura estímulos externos e apresenta respostas.
• Lógica de Negócio: Executa e impõe as políticas, regras e cálculos do negócio.
• Gerência de Dados: Provê acesso aos dados corporativos e gerencia requisições concorrentes.

12. Matriz CRUD

Ferramenta para identificar como os eventos/casos de uso e entidades estão relacionados. É importante para definir um modelo de arquitetura que contemple essa visão inicial.