Requisitos, Arquitetura e Padrões de Projeto de Software

Hierarquia de Requisitos e Definição de Escopo

O processo de definição de requisitos segue uma hierarquia clara:

1. O primeiro item do Documento de Visão é o Escopo, que é identificado durante a entrevista com o cliente.
2. Em seguida, é necessário identificar os Requisitos Funcionais e Não Funcionais (que representam as necessidades dos clientes e definem o que o cliente espera do sistema).

Transformação de Requisitos

É crucial transformar os Requisitos de Cliente em Requisitos de Produto. Nos requisitos de cliente, os requisitos funcionais e não funcionais estão misturados e o nível de detalhamento é menor.

• Através dos Requisitos Funcionais, são identificadas as funcionalidades do sistema, que são representadas pelo Diagrama de Caso de Uso.
• Os Requisitos Não Funcionais dão origem aos Requisitos e Restrições Arquiteturais (que serão detalhados no Documento de Arquitetura).

Requisitos de Produto

Os Requisitos de Produto resultam da quebra e detalhamento das necessidades expressas nos Requisitos de Cliente.

O Documento de Visão

No Documento de Visão, estarão especificados o escopo, os requisitos do cliente e os requisitos de produto (funcionais e não funcionais).

Papéis Chave no Desenvolvimento de Software

Analista de Requisitos

É responsável por definir o escopo e identificar os requisitos funcionais e não funcionais. O Analista de Requisitos também elabora os diagramas de análise (diagrama de classe, sequência, entre outros).

APSI-II: Diagramas de Análise

Fazer diagramas de análise usando classes da UML (Boundary, Control e Entity).

Observação: O Analista de Negócio também pode definir o escopo, mas é uma prática menos usual.

Arquiteto de Software

O Arquiteto analisa todos os requisitos e define os aspectos técnicos (linguagem de programação, frameworks, banco de dados, servidor de aplicação, componentes usados). Ele cria o Documento de Arquitetura baseado em padrões de projeto para atender aos requisitos não funcionais.

Analista Projetista

O Analista Projetista analisa a arquitetura da aplicação e os diagramas de análise, e cria o Diagrama de Projetos.

APSI-III: Requisitos Arquiteturais

Definir os requisitos e restrições arquiteturais baseados em padrões já existentes.

Padrões de Arquitetura e Projeto

Arquitetura em 3 Camadas

Divide o sistema fisicamente, separando a lógica de negócio, lógica de apresentação e lógica de persistência nas seguintes camadas, respectivamente:

• Camada de Apresentação
• Camada de Negócio
• Camada de Persistência

Padrão MVC (Model-View-Controller)

Separa os aspectos de interface dos dados, utilizando um Controlador que comunica a View (componentes de interface) com o Model (componente de regra de negócio e acesso a dados). Não é um modelo hierárquico como a arquitetura em 3 camadas.

DTO (Data Transfer Object)

É um objeto que é transferido entre as camadas, possuindo atributos e métodos get e set. O DTO é gerado pelo Servlet que recebe um request com as informações do objeto, e cria um DTO que será trafegado entre as classes do sistema (sendo passado como parâmetro).

Trafegar entre as camadas: Chamar métodos que estejam em pacotes diferentes.

Padrão Facade

Define que deve existir um ponto de entrada único no sistema. É uma controladora de classes de negócio que define quais classes de negócio serão chamadas e quando serão chamadas.

Padrão BO (Business Object)

Padrão de projeto do J2EE que prega a separação da regra de negócio do acesso aos dados e da interface do sistema. Recebe um DTO para realizar validações.

Padrão DAO (Data Access Object)

Separa o acesso a dados na base do sistema (da regra de negócio e da interface). Recebe o DTO para fazer inserções, alterações, exclusões ou qualquer outra modificação na base de dados.

Estereótipos UML (Boundary, Control, Entity)

• Boundary: Apresentação
• Control: Regras de Negócio
• Entity: Persistência

A camada Boundary acessa a Control, que por sua vez acessa a Entity.