Caso de uso 5 Alterar Permissão

Ao observar a Figura12, para alterar a permissão de um usuário, o administrador busca o usuário e o sistema vai até o banco de dados com a lista com todos os usuários do sistema. O administrador seleciona o usuário, o qual vai alterar a permissão e seleciona o novo nível de acesso do mesmo, então, a camada de controller redireciona para a próxima página, o qual vai conter um formulário com informações extras de acordo com o nível selecionado. No primeiro caso, o usuário preenche o formulário de forma errada ou sem preencher todos os campos, então, o controller valida esses dados e retorna para o usuário uma mensagem de erro. Após alertado, o usuário preenche de forma correta o formulário e os dados são inseridos no banco de dados.

Capítulo 3. Proposta de Solução 41

Figura 10 – Caso de uso 3 - Cadastrar prontuário

Figura 11 – Caso de uso 4 - Solicitar adoção

Capítulo 3. Proposta de Solução 43

Figura 12 – Caso de uso 5 - Alterar Permissão de Usuário

4 Proposta de Implementação

A estrutura do sistema é algo muito importante, pois vai mostrar como o sistema funciona internamente de uma forma bem simples. Para se ter uma arquitetura organizada, é preciso decidir qual modelo de organização seguir para estruturar essa arquitetura, o modelo escolhido foi o cliente-servidor, o qual consiste num modelo em que o sistema é organizado como um conjunto de serviços, servidores e clientes associados que acessam e usam os serviços (SOMMERVILLE,2007)

Na Figura 13, está a estrutura geral do sistema, o qual representa exatamente o que foi dito porSommerville(2007), ou seja, é possível identificar que o sistema foi dividido em 3 camadas principais, sendo elas, a camada de apresentação, de aplicação e de dados. E que, segundoMariano e Paes (2017), a estrutura sendo dividida dessa forma, ela possibilita uma divisão de responsabilidades além de agilizar o desenvolvimento, facilitar a manutenção e inserir novas funcionalidades no futuro.

Figura 13 – Arquitetura Geral do Projeto

Fonte: (MARIANO; PAES,2017)

Como a proposta é que o sistema seja disponibilizado em pelo menos duas platafor- mas, foi percebido a necessidade de fazer o uso de uma camada de aplicação para realizar a comunicação entre as plataformas e o servidor de banco de dados, ou seja, entre a camada de apresentação e a de dados. Ao observar a Figura13, é possível identificar que a camada de aplicação se conecta com a de dados, fazendo com que o acesso aos dados armazenados ocorra em tempo real para qualquer aplicação.

Além da arquitetura geral do projeto, é necessário detalhar para que ainda fique mais simples dos projetistas entender como irá ser implementado o sistema em si. Com a finalidade de explicar melhor, os próximos tópicos irão detalhar mais sobre essa arquitetura.

Capítulo 4. Proposta de Implementação 45

4.1

Camada de Dados

Nessa camada, é onde ficam armazenados os dados do sistema. Para isso, foi desenvol- vido um banco de dados relacional, o qual é responsável por armazenar as informações geradas pelos clientes. A ferramenta de banco de dados utilizada no sistema foi o MySQL na versão 5.7.27.

Figura 14 – Trecho do código do modelo de dados de animais

Fonte: Desenvolvedores do sistema

Na Figura 14, é possível observar como é feito para mapear os dados de um animal usando JavaScript, o qual permite manipular as informações e facilita na aplicação das regras de negócio. Para realizar as consultas, foi utilizado o Knex, pois ele é um construtor de consultas SQL, flexível e portátil (KNEX.JS,2013), facilitando ainda mais na hora de solicitar e armazenar os dados na base de dados.

O trecho de código apresentado na Figura14remete à estrutura oferecida pelo Knex, o qual consiste num Object-relational Mapping (ORM), ou seja, uma técnica de mapeamento de objeto relacional que auxilia durante as consultas em um banco de dados relacional. O Knex abstrai quase que total a linguagem SQL, fazendo com que facilite na hora que o programador esteja implementando a camada de negócio.

4.2

Camada de Aplicação

Essa camada é uma das mais complexas dentro do sistema, pois ela é responsável pelas regras de negócio e a comunicação com o banco de dados. Ela foi desenvolvida utilizando o Express, um framework do Node.js, o qual foi adotado por fornecer recursos para aplicações

Webe Mobile (EXPRESS.JS,2019). Tendo em vista essa portabilidade, foi escolhido utilizar os princípiosREST. Abaixo, está a estrutura detalhada desta camada.

Figura 15 – Detalhes da Camada de Aplicação

Fonte: A própria autora

Ao observar a Figura15, é possível notar que ela é a principal responsável por comunicar o usuário com o banco de dados, e com isso, ela fica com a parte mais complexa do sistema. No entanto, a Figura15 mostra que a camada de apresentação envia as informações para o frameworkresponsável por levar esses dados até o servidor de banco de dados, o Node.js. Esse frameworkconsiste num ambiente de execução JavaScript para operações feitas pelo servidor (LENON,2018) e possui a estruturaMVCcomo padrão para desenvolvimento.

Dentro do Node.js será utilizado o Express.js. Ele é um framework Node.js que fornece um conjunto de recursos para aplicações Web e Mobile (EXPRESS.JS,2019). Nela ficará a

API, a qual sua tarefa principal é a conversão de listas de parâmetros de um formato para outro (FOLDOC,1995). Ou seja, ela ficará responsável por transformar o conjunto de dados requisitados em JSON e quando o cliente estiver enviando dados, ele ficará responsável por traduzir do JSON para a linguagem do banco de dados. Na Figura16é possível ver como são feitas as requisições.

Após a camada do Express.js, vem a camada de negócios. Ela é utilizada para tratar os dados antes de ir para o banco de dados e antes de voltar para o cliente como é possível verificar na Figura17. Nela é possível tratar erros não foram percebidos antes. Além disso, se houver mudança de alguma funcionalidade ou regras, somente ela será alterada.

Capítulo 4. Proposta de Implementação 47

Figura 16 – Exemplo das requisições em JSON

Fonte: Desenvolvedores do sistema

Com todos os dados preparados para serem armazenados no banco de dados, é preciso um drive, o qual é o responsável por comunicar o Node.js com o servidor de banco de dados, para auxiliar na realização de consultas no banco de dados, foi utilizado o Knex.

4.3

Camada de Apresentação

A camada de apresentação é o meio de comunicação entre o usuário e os dados. Nela, é coletada informações a serem utilizadas pela camada de aplicação e armazená-las no banco de dados, e ela também permite a visualização das informações armazenadas no banco de dados. Na Figura18, é possível observar de forma detalhada o front-end adotado por este trabalho.

Ao observar a Figura18, é possível identificar que quando o usuário acessa a aplicação, seja Web ou Mobile, ele vai ver a camada de visão da aplicação, que no presente trabalho, fará o uso de XML e Material Design para a versão Mobile e Hypertext Markup Language (HTML) e CSS na versão Web.

Na versão Mobile, a camada de visão se comunica diretamente com a camada de controle para tratar as informações e enviá-las ao servidor. Já na versão Web, a camada de visão se comunica com o Laravel, o qual é o responsável por enviar os dados para a camada de controle e só depois que essas informações são enviadas ao servidor. No presente trabalho, a camada de controle será desenvolvida na linguagem PHP para o sistema Web e em Java para a aplicação

Figura 17 – Exemplo do código da API

Fonte: Desenvolvedores do Sistema

Mobile.

A camada de controle de ambas as plataformas deve se comunicar com a camada de aplicação, o qual é responsável por realizar a comunicação entre a camada de apresentação e a de dados.

4.3.1

Capturas de tela

Com a finalidade de mostrar como está ficando a camada de apresentação do sistema, serão mostradas algumas capturas de telas do sistema Web até o momento deste trabalho.

Para poder acessar o sistema, o usuário deve estar cadastrado e realizar o login com o seu nome usuário e sua senha, como é possível observar na Figura19.

Ao completar o login, o usuário vai para a página inicial do sistema, nela contém algumas informações sobre a quantidade de animais e a quantidade de estoque presente na instituição, como é possível observar na Figura20.

O protótipo conta com a listagem de todos os animais da instituição, como é possível observar na Figura21. Nesta tela é possível editar e visualizar informações de cada animal.

Para solicitar a adoção do animal, o adotante busca a lista de animais aptos à adoção, onde escolhe o animal a ser adotado, como é possível verificar na Figura22.

Capítulo 4. Proposta de Implementação 49

Figura 18 – Detalhes da Camada de Apresentação

Fonte: A própria autora

Figura 19 – Tela de Login

Fonte: A própria autora

Para que o adotante de fato conclua a solicitação de adoção, é necessário que ele preencha um formulário com informações para que um funcionário avalie se o adotante está apto para adotar. O formulário contém as principais perguntas escolhidas pelo cliente, como é possível observar no formulário da Figura23.

Figura 20 – Página Inicial

Fonte: A própria autora

Figura 21 – Listagem de Animais

Capítulo 4. Proposta de Implementação 51

Figura 22 – Lista de Animais Aptos à Adoção

Fonte: A própria autora

Figura 23 – Formulário de Adoção

5 Resultados

5.1

Atividades Realizadas

Tendo em vista que o sistema se caracteriza como sendo um software acadêmico, ou seja, desenvolvidos por estudantes da graduação, então foi feito um planejamento baseado em que a equipe só estaria disponível por um tempo bastante limitado.

Apesar do tempo limitado e de todos os imprevistos descritos na Seção5.2, algumas funcionalidades já podem ser utilizadas pelo usuário final, como é o caso do cadastro de usuário e funcionário, gerenciamento do animal e estoque, como mostra a Tabela3.

Tabela 3 – Atividades Planejadas

Atividades Realizadas Não realizadas Documentação X Prototipação X Configuração do Ambiente X Módulo Usuários X Módulo Animais X Módulo Estoque X Módulo de Documentos X Testes do Sistema X Ajustes e testes finais X

Fonte: A própria autora

5.2

Gerenciamento

Com a finalidade de ter um melhor proveito da metodologia escolhida, o Scrum, foi elaborado inicialmente um cronograma geral, como mostra na Tabela4, ele serviu de base para delimitar o tempo de desenvolvimento.

Devido aos prazos e por se tratar de um software acadêmico, ou seja, o time de desen- volvimento sendo composto por alunos que ainda não finalizaram a graduação, a implementação completa do software não foi possível ser finalizada de acordo com o que foi modelado e proje- tado durante esse trabalho. Porém, foi realizado as tarefas mais urgentes para a instituição de apoio à animais estudada.

O projeto inicial contou com mais ou menos 138 dias de desenvolvimento, a partir do levantamento de requisitos, planejamento, documentação, criação de diagramas, modelagem,

Capítulo 5. Resultados 53

Tabela 4 – Cronograma Geral

Mês Demanda Mês 1 Planejamento Documentação Mês 2 Documentação Design Mês 3 Implementação Testes Unitários Mês 4 Implementação Testes Unitários Mês 5 Implementação Testes Unitários Mês 6 Testes Integrados Correção de Erros Implantação

Fonte: A própria autora

Tabela 5 – Fases do Projeto

Fase Atividade 1a Documentação 2a _{Desenvolvimento}

3a _{Implantação} Fonte: A própria autora

codificação, realização de testes e os ajustes finais e foi dividido em 3 fases, como mostra a Tabela5.

A primeira fase, foi a parte de desenvolvimento de toda a documentação, onde foram realizados reuniões toda semana afim de deixar bem claro quais eram as necessidades daONG. Na segunda fase, foi o desenvolvimento do protótipo do sistema, o qual os encontros com o cliente era somente para que ele pudesse acompanhar o que estava sendo feito, e fornecer um feedbackpara a equipe. Já a terceira fase, trata-se da parte de disponibilização do sistema para o usuário final e treinamento do mesmo.

Já que se tratou de um software acadêmico, houve muitos imprevistos, alguns já previstos, mas que causaram impactos fazendo com que não fosse possível finalizar o que havia sido planejado. A não disponibilidade frequente do time de desenvolvedores foi o que mais causou atraso no projeto, pois eram estudantes e nem sempre estavam disponíveis para cumprir os horários.

Além disso, houve a troca do desenvolvedor back-end, o qual o primeiro finalizou o estágio com a documentação do banco de dados e o segundo ficou com o desenvolvimento da API, porém ele teve que revisar e adaptar quase todo o banco de dados, devido a novas

funcionalidades que foram sendo solicitadas pelo cliente. No entanto, esse atraso no back-end acarretou no retardo do desenvolvimento de algumas funcionalidades do front-end Web.

Já a aplicação Mobile, só foi realizada a prototipação, pois o responsável pelo desenvol- vimento da aplicação desistiu do estágio e não foi possível encontrar outra pessoa para ser posta em seu lugar.