DOCUMENTO DE ARQUITETURA REDMONT. Aurum

Transcrição

1 DOCUMENTO DE ARQUITETURA REDMONT Aurum Juazeiro do Norte - CE 201 1

2 HISTÓRICO DE REVISÃO DATA VERSÃO DESCRIÇÃO AUTOR 31/03/201 31/03/201 02/04/201 04/04/201 04/04/201 25/04/201 25/04/201 25/04/201 25/04/201 26/04/201 26/04/201 26/04/201 04/05/ Criação do tópico 2 Weslley e Pedro Gabriel 0.2 Criação do tópico 3 André e Gabriel 0.3 Criação do tópico 3.1 Francisco Sergio e Pedro Gabriel 0.4 Criação do tópico 1 Gabriel e André 0.5 Revisão Geral 0.6 Criação do tópico Criação do tópico 5 0. Criação do tópico 6 André Luis Francisco Sergio André Luis, Weslley Gabriel Ramos, Francisco Sergio Weslley, Francisco Sergio 0.9 Criação do tópico e 9 Pedro Gabriel 1.0 Revisão geral do documento e comentários para melhoria do ponto 1, 2 e Criação do tópico 7 André Luis André Luis e Pedro Gabriel 1.2 Correção do tópico 1 e 5 Gabriel Ramos 1.3 Finalização do tópico 7 / Revisão geral do documento Pedro Gabriel 2

3 1 Sumário

4 2 Abreviaturas TI - Tecnologia da Informação 3 Lista de Tabelas Tabela 1 Informações sobre os membros da equipe Lista de Quadros Quadro 1 Visão de Implementação...12 Quadro 2 Dicionário de Dados...14 Quadro 2 Tamanho e desempenho Lista de Figuras Figura 01 - Representação Arquitetural...05 Figura 02 - Visão Lógica...06 Figura 03 - Pacotes significativos para a arquitetura Figura 04 - Visão de Processos Mobile...07 Figura 05 - Visão de Processos Web...0 Figura 06 - Visão de implantação WEB...09 Figura 07 - Visão de implantação Mobile...10 Figura 0 - Visão de Implementação...10 Figura 09 - Visão de implementação WEB...11 Figura 10 - Visão de implementação Mobile...11 Figura 11 - Visão de Dados

5 6 REPRESENTAÇÃO ARQUITETURAL O padrão arquitetural escolhido para o desenvolvimento do sistema foi o modelo MVC (Modelo, Visão e Controle). O MVC separa a representação da informação da interação do usuário com ele. O model consiste nos dados da aplicação, regras de negócios, lógica e funções. A view (visão) pode ser qualquer saída de representação dos dados, como uma tabela ou um diagrama. É possível ter várias visões do mesmo dado, como um gráfico de barras para gerenciamento e uma visão tabular para contadores. O controller (controlador) faz a mediação da entrada, convertendo-a em comandos para o modelo ou visão. A escolha deste padrão proporciona ao processo de desenvolvimento suporte para reuso, evolução e manutenção e separação de conceitos. Figura 01 - Representação Arquitetural O usuário na plataforma mobile através do aplicativo, irá realizar cadastro de revendedoras,.na plataforma WEB é onde haverá um controle do sistema, quando os dados do celular forem sincronizados serão salvos no banco de dados e em seguida estarão acessíveis pela plataforma web. Além do controle das vendas também haverá um acompanhamento de negócios na plataforma web. 7 METAS E RESTRIÇÕES DA ARQUITETURA O sistema deve prover de uma arquitetura de sistemas e de dados MVC (Model, View, Controller)que atenda a solução proposta atualmente e seja altamente flexível de forma a permitir evoluções no sistema. O desenvolvimento deve ser priorizado o reuso de módulos dos sistemas já prontos para a maior rapidez de entrega e desenvolvimento do sistema. Existem alguns importantes requisitos e restrições do sistema que possuem uma influência significativa na arquitetura. São elas: Todas as funções do sistema devem estar disponíveis para o usuário administrador. O sistema será desenvolvido com a linguagem PHP, juntamente com o framework Laravel. Todos os módulos do sistema com interface gráfica devem ser desenvolvidos com o framework BOOTSTRAP. 5

6 Todos os requisitos de desempenho, conforme estipulados no Documento de Requisitos devem ser considerados como a arquitetura sendo desenvolvida. Na base de dados será usado o Mysql, possuindo capacidade de se comunicar outras bases de dados. METAS E RESTRIÇÕES DA ARQUITETURA (MOBILE) A aplicação mobile deve prover de uma arquitetura de sistemas e de dados MVC (Model, View, Controller) que atenda a solução proposta atualmente e seja altamente flexível de forma a permitir evoluções no sistema. O desenvolvimento deve ser priorizado com reuso de módulos de sistemas já prontos para a maior rapidez de entrega e desenvolvimento do sistema. Existem alguns importantes requisitos e restrições do sistema que possuem uma influência significativa na arquitetura. São elas: O aplicativo será desenvolvido na linguagem JAVA. A ferramenta para o desenvolvimento será a IDE Android Studio que é a ferramenta oficial para desenvolvimento Android. O aplicativo deve salvar os dados em uma base de dados local, quando conectado a internet deve realizar a transferência de dados para o banco de dados do sistema web. VISÃO LÓGICA O usuário interage com o nosso sistema através das views, realizando alguma operação no sistema, a view solicita a controller a ação realizada, o controller por sua vez processa as informações por meio da comunicação com o model, que por sua vez se comunica com o banco de dados, que por conseguinte repassa o resultado da operação solicitada para a view. Figura 02 - Visão Lógica.1 PACOTES SIGNIFICATIVOS PARA A ARQUITETURA Nesta subseção será descrita a estrutura da aplicação em pacotes e termos de hierarquia em suas camadas baseado na arquitetura MVC com os quais serão descritos os seguintes pacotes: 6

7 Figura 03 - Pacotes significativos para a arquitetura 9 VISÃO DE PROCESSOS A visão de processos é utilizada para exemplificar de forma gráfica como serão divididos os processos em todos os seus módulos, abaixo temos uma visão do módulo mobile do nosso sistema: Figura 04 - Visão de Processos Mobile 7

8 Abaixo temos a visão do módulo Web do nosso Software: Figura 05 - Visão de Processos Web 10 VISÃO DE IMPLANTAÇÃO O Aurum é um software dividido em duas plataformas: WEB e mobile. No qual seguirá o padrão MVC de arquitetura, Para ter acesso à plataforma WEB o computador do usuário precisa estar conectado com a internet que fará um requerimento HTTP/HTTPS. Para que o software tenha um bom funcionamento o computador precisa ter um navegador instalado (Google Chrome, Mozilla Firefox, Opera, Microsoft Edge, outros). A plataforma Android também seguirá o padrão MVC de arquitetura. Para ter acesso ao App o usuário deverá ter baixado onde o app estará disponível no Google Play. Para que o app tenha um melhor funcionamento recomenda se que o aparelho seja da da plataforma Android possuindo uma versão 5.0 ou superior, com processador Quad core e 16GB de memória interna. Segue a baixo as representações das visões de implantação dos dois softwares:

9 Figura 06 - Visão de implantação WEB Figura 07 - Visão de implantação Mobile 11 VISÃO DA IMPLEMENTAÇÃO O Arum contará com 3 níveis de acesso e em cada um terá 2 níveis de arquitetura, o primeiro segue clienteservidor onde segue as regras de apresentação, regras de negócio, regras de persistência e o segundo nível de arquitetura é o MVC que contará com as boas práticas do Laravel. O MVC permite com que as camadas 9

10 trabalhem com bastante fluência, onde o model são os dados, a visão onde o usuário possui controle da aplicação e o controller passando as informações necessárias para que tudo funcione corretamente. Figura 0 - Visão de Implementação Figura 09 - Visão de implementação WEB 10

11 Figura 10 - Visão de implementação Mobile Camadas Apresentação Negócio Persistência Descrição Esta camada é responsável por apresentar de forma gráfica as funcionalidades do sistema para o usuário, a visão administrador é referente a plataforma web, a vendedor é referente ao mobile Essa camada vem com o objetivo tratar todas as regras de negócio, que chegam através das solicitações do usuário, o módulo ADM é responsável pelo controle WEB, módulo VEND é responsável pelo controle MOBILE. Camada responsável por manter os dados de forma a permitir o acesso das informações sempre quando requisitadas das plataformas WEB e MOBILE. Quadro 01 Visão de Implementação 12 VISÃO DE DADOS 11

12 Figura 11 - Visão de Dados 12

13 TABELA ATRIBUTOS TIPO DESCRIÇÃO idprodutocompra quantidade ProdutoCompra Compra_idCompra valorunitario Armazena a quantidade de determinados produtos nas compras. valortotal Produto_idProduto idcompra valortotal Compra formapagamento comentario Armazena as compras efetuadas. pago TINY Distribuidor_idDistribui dor enderecodistribuidor Distribuidor nomedistribuidor cpfdistribuidor Guarda os distribuidores cadastrados no sistema. iddistribuidor idproduto Produto nomeproduto precovenda Armazena os produtos em estoque. QuantidadeEstoque idcategoriaproduto CategoriaProduto Produto_idProduto nomecategoria Divide os produtos em sua determinada categoria. ativo TINY datacadastro DATE Vendedor idvendedor Armazena os dados dos 13

14 vendedores. nomevendedor telefonevendedor rgvendedor Endereco_idEndereco cpfvendedor iditenscampanha quantidadekit ItensCampanha Campanha_idCampanha Produto_idProduto valortotal Armazena os produtos que foram enviados para uma determinada campanha. valorunidade quantidadetotal idcampanha Campanha datadistribuicao Praca_idPraca DATE Armazena as campanhas cadastradas no Software vendedor idpraca Praca nomepraca observacao Armazena os locais de atuação das campanhas. Vendedor_idVendedor iditemcampanhapedido quantidaderecebida ItensCamPanhaPedido quantidadevendida valortotal valorvendido Armazena os pedidos feitos em determinadas campanhas. ItensCampanha_idItens Campanha Pedido_idPedido Pedido idpedido datapedido DATE Armazena os pedidos efetuados. 14

15 status valortotal valorvendido valorpago comissao campanha Revendedora_idRevend edora Pagamento_idPagament o idrevendedora nomerevendedora Revendedora cpfrevendedora rgrevendedora telefonerevendedora Armazena as revendedoras cadastradas no Software. Endereco_idEndereco Praca_idPraca idendereco Endereco rua numeroendereco bairro Armazena os endereços dos vendedores e das revendedoras cadastradas. pontoreferencia Cidade idcidade nomecidade Estado_idEstado Armazena a cidade dos vendedores e revendedoras cadastradas. Status idstatus Armazena a situação do pagamento, mostrando nomestatus se o mesmo encontra-se quitado ou pendente. Pagamento idpagamento Pedido Armazena os pagamentos efetuados 15

16 de cada pedido. datapagamento DATE valorpago formapagamento Status_idStatus Estado idestado nomeestado Armazena o estado dos vendedores e revendedoras cadastrados. Quadro 02 Dicionário de Dados. 13 TAMANHO E DESEMPENHO O tamanho e desempenho do Software dizem respeito a técnicas de velocidade da abertura ou fechamento de uma aplicação, tendo como base o tempo de resposta reduzido ao máximo possível para que o usuário possa esperar menos tempo e obter mais produtividade. RNF-06 Tempo de Resposta O Aurum deverá informar o resultado buscado pelo usuário em uma estimativa de 2 segundos podendo chegar em até no máximo 5 segundos para concluir a busca efetuada. RNF-07 Capacidade O software deve suportar 500 (quinhentos) usuários online simultaneamente sem que seja afetado o desempenho e velocidade do mesmo. RNF-0 Taxa de Transferência O Aurum não pode ultrapassar segundos para realizar qualquer ação. RNF-09 Tamanho O Software deve ser leve a compacto utilizando métodos simples e eficazes a fim de acelerar as funcionalidades do mesmo. Quadro 03 Tamanho e desempenho. 14 QUALIDADE A arquitetura foi modelada e escolhida a fim ser fácil e viável em portabilidades futuras em outros sistemas de desenvolvimento, sendo também possível realizar manutenções práticas no mesmo sem que ocorram falhas ou atrasos. 16