Versão 1.5

Histórico da Revisão

Data	Versão	Descrição	Autor
01/04/2016	1.0	Criação do documento	Omar Junior
03/04/2016	1.1	Elaboração da seção 4.1	Omar Junior
03/04/2016	1.2	Inclusão do Diagrama de Classes	Eduardo Moreira
03/04/2016	1.3	Adaptação ASP.NET	Eduardo Moreira
23/06/2016	1.4	Elaboração da seção 4.3	Omar Junior
23/06/2016	1.5	Elaboração da seção 4.6	Eduardo Moreira

1. Introdução

1.1. Finalidade

Este documento fornece uma visão geral da arquitetura do FarManager através de vários diagramas seguindo os padrões da UML, fornecendo visões arquiteturais diferentes para ilustrar os diversos aspectos da aplicação.

1.2. Escopo

A arquitetura do projeto FarManager é fundamentada e detalhada, para servir como base a equipe de desenvolvimento da aplicação, apresentando como será o comportamento do sistema.

1.3. Refência

Este documento possui referência a outros artefatos que descrevem o sistema do FarManager, são eles:

• Especificação suplementar;
• Descrição dos casos de uso.

2. Visão Geral

Este documento descreve os limites da arquitetura do sistema FarManager, que será uma aplicação voltada para auxiliar as necessidades no gerenciamento da fazenda do cliente.

Este documento está organizado em seções, que estão dispostas da seguinte maneira (ocultando-se a presente seção):

Representação da arquitetura - Esta seção apresenta o modelo de arquitetura padrão que será seguido para o desenvolvimento do sistema.

Metas e Restrições de Arquitetura - Esta seção apresenta os requisitos não funcionais do software que irão impactar os objetivos da arquitetura do projeto.

Visão dos casos de uso - Esta seção apresenta o diagrama de caso de uso do projeto de forma simplificada, para entender mais sobre cada caso de uso se tem a necessidade de selecionar o caso de uso que o leitor será redirecionado.

Visões arquiteturais - Esta seção apresenta as diferentes visões arquiteturas da aplicação.

2.1. Representação da Arquitetura

O padrão de arquitetura utilizado neste projeto foi o MVC - Model, View e Controller em uma aplicação Web ASP.NET. Este modelo divide o sistema em diferentes camadas sobrepostas, de forma que o usuário só terá interação com a camada View.

• Model - Esta camada representa os dados abstraídos do problema e possibilita o acesso a eles: leitura, escrita e validação, assim como pode implementar alguma regra de negócio.

• View - Camada responsável por exibir as informações, uma interface gráfica de interação com usuário, na qual não tem acesso aos códigos fontes da aplicação.

• Controller - Camada intermediária responsável por controlar o fluxo de informações entre as demais camadas. Ela controla a lógica em torno do Model, processa as requisições e transmite as respostas que foi processado para a camada View.

A imagem a seguir apresenta como cada camada se comunica:

3. Metas e Restrições da Arquitetura

Os requisitos não funcionais estão documentados na Especificação Suplementar eles definem os limites do sistema que afetam de forma direta a arquitetura do sistema.

4. Visões Arquiteturais

4.1. Visão Geral

Dentro do pacote Web, é possível notar que é empregado o padrão MVC, sendo utilizados os pacotes model, view e controller. O pacote model, é composto pelas classes originadas da modelagem. No pacote view, é onde estão as classes principais de interação com o usuário. Já no pacote controller, estão as classes que controlam o funcionamento geral da aplicação, como aplicação de regras de negócio, interação entre as classes da view e da model.

No pacote Dados, estão os pacotes e classes que possuem a função de criar as tabelas do banco de dados da aplicação.

O pacote Negocio armazena as classes utilizadas pelo Entity Framework para mapeamento entre o banco de dados e as models geradas.

O pacote Tests, contém um conjunto de classes para realizar testes unitários das classes do pacote controller, e garantir que estas cumprem o objetivo para que foram codificadas.

O pacote config contém os arquivos responsáveis por configurar aspectos relevantes da aplicação nos seus diferentes estágios: produção, teste e desenvolvimento.

4.2. Visão de Caso de Uso

4.2.1. Atores

Funcionário

Este ator representa os funcionários que irão interagir com o sistema para realizar cadastros e visualizar os planos de manejo de gado

Fazendeiro

Este ator representa o dono da fazenda e herda todas as funcionalidades do funcionário, além de possuir algumas funcionalidades, como o cadastro do módulo financeiro.

4.2.2. Diagrama de Caso de Uso

[Modelo de caso de uso](Modelo de caso de uso)

4.3. Visão Lógica

4.3.1. Responsabilidades por camada

A camada View apresenta os componentes de interface gráfica que com os quais o usuário interage. Ela se comunica com a camada Controller enviando requisições. Também faz requisições a camada Content, que contém elementos de customização de interface gráfica (nesse caso, Bootstrap) e a um diretório de Imagens que contém todas as imagens da aplicação.

A camada Controller possui as classes responsáveis por receber as requisições das classes da camada View e que se comunicam com as classes das camadas Model e DAL.

A camada Model contém as classes que representam o domínio da aplicação.

A camada DAL contém as camadas responsáveis pela persistência ou recuperação de dados no banco de dados da aplicação. Comunica-se com a camada de Controller respondendo às requisições feitas por essa camada.

4.4. Visão de Dados

4.5. Visão de Implementação

4.5.1. View

Este pacote possui a funcionalidade de apresentar os dados já modelados, engloba os pacotes que contém as classes responsáveis pela interação com o usuário, de forma a gerar uma interface com este. Este pacote não deve realizar nenhum processamento de dado no framework utilizado, deixando toda a responsabilidade de processamento nas controllers.

4.5.2. Controller

Este pacote que contém as classes responsáveis por fazer a interação entre os pacotes Model e View. Elas são como gerentes da aplicação, respondem as requisições feitas pelos usuários na interface aos objetos do modelo, estruturas de dados. Neste pacote está embutido as lógicas da aplicação e as regras de negócio.

4.5.3. Model

Pacote que contém as classes responsáveis pelo armazenamento das classes derivadas das entidades criadas no Banco de Dados (pacote Dados) e mapeadas pelo Entity Framework (pacote Negocio).

[Diagrama de Classes](Diagrama de Classes)

4.5.3. DAL

4.6. Visão de Implantação

A aplicação irá rodar de maneira Stand-Alone. Isso significa que não será necessária nenhuma comunicação com servidores externos ao ambiente em que a aplicação é executada.

Será necessário um arquivo .mfd que será responsável por armazenar os dados gerados pela aplicação. Este arquivo funciona como uma base de dados local e não requer instalação de nenhum Sistema Gerenciador de Banco de Dados.

Para o deploy, deverá ser criado um Pool de aplicação no IIS (Internet Information Services) que será rodado localmente. Isso permite que usuários externos possam acessar a aplicação, caso haja conexão com a internet.