Este Capítulo descreve o desenvolvimento de um novo incremento para SIGUAN, ou seja, um novo módulo, chamado de Análise de Clientela. O objetivo desse módulo é auxiliar o nutricionista na preparação de um novo cardápio a partir da captação de informações sobre necessidade calórica da clientela do Restaurante Universitário. Assim como o SIGUAN este módulo foi desenvolvido utilizando com base no modelo arquitetural de Visões 4+1. Tal avaliação ocorre devido a necessidade de comprovar que o novo fluxo de processo de implantação explicado na Seção 3.5 NOVO FLUXO DE IMPLANTAÇÃO, é adequado e suficiente para atingir o objetivo principal desse trabalho.
O Capítulo 4 está organizado da seguinte forma: a seção 4.1 apresenta os requisitos para atender o novo módulo; a seção 4.2 ilustra como foi implementada tal modulo seguindo o modelo arquitetural 4+1; a seção 4.3 apresenta o processo de implantação do SIGUAN na ferramenta do Jenkins e demonstra o novo módulo do SIGUAN.
4.1 PROBLEMA
A necessidade de criar tal módulo veio da problemática de que, para o nutricionista, é necessário ter uma base da média calórica necessária para a clientela que será atendida em um determinado dia. Dessa forma, para facilitar tal previsão, é necessário adicionar ao sistema um módulo para cadastro das informações relevantes da clientela para que a média calórica da refeição possa ser estimada durante a preparação dos cardápios. A Tabela 3 apresenta tais requisitos funcionais do novo módulo.
Tabela 3. Requisitos Funcionais
Código Descrição
RF001 Cadastro, exclusão, atualização e consulta de análise de clientela.
RF002 Cadastro, exclusão, atualização e consulta de clientela.
RF003 Consulta de uma análise de clientela durante o processo de cadastro de prescrição.
4.2 ARQUITETURA
Como citado anteriormente, o SIGUAN desenvolvido com base no modelo arquitetural 4+1. Os detalhes da arquitetura do SIGUAN podem ser encontrados no trabalho de (SILVA, 2018). Assim, serão apresentados nessa seção apenas a parte específica necessária para o desenvolvimento do novo módulo.
4.2.1 VISÃO DE CASOS DE USO
A visão de casos de uso ilustra como estão organizados os requisitos funcionais do Módulo de Análise de clientela. Tais requisitos foram obtidos através de reuniões com os usuários do sistema. A Figura 22 apresenta o diagrama de casos de uso que ilustra as principais funcionalidades oferecidas por esse novo módulo e o modo como os atores interagem com as mesmas.
Figura 22: Diagrama de Casos de uso do Módulo de Análise de Clientela
O detalhamento dos casos de uso está disponível na seção de Apêndice
4.2.1.2 VISÃO LÓGICA
A Visão Lógica apresenta a especificação do modelo de regras de negócios que implementam os requisitos funcionas do sistema. Esta visão foi representada através do diagrama de classes com intuito de especificar todos os dados e relacionamentos necessários. A Figura 23 mostra o diagrama de classes do módulo de Análise de Clientela.
Figura 23: Visão do Diagrama de Classe do Módulo de Clientela
A Tabela 4 apresenta as descrições das classes especificando o que cada uma representa.
Tabela 4. Especificação das classes do diagrama de classe
Classe Descrição
Prescrição
Classe que representa uma prescrição, onde é especificado a quantidade necessária dos insumos para preparar as refeições de um dia específico. Possui atributos que indicam o cardápio aplicado, a data, o responsável e a lista de itens que serão retirados do estoque especificando suas respectivas quantidades
Análise Clientela
Classe que utilizasse uma equação que será escolhida pelo ator Nutricionista onde será calculada a partir de uma análise de clientela a média de todos os atributos que um comensal poderá apresentar.
Comensal
Classe que representa as variáveis desejáveis que um ser humano que visite a UAN apresente.
4.2.1.3 VISÃO DE IMPLEMENTAÇÃO
A visão de implementação se baseia no ponto de visto do desenvolvedor no aspecto de como o sistema será implementado. Tal visão não foi alterada, seguindo a mesmo do trabalho de (SILVA, 2018). A Figura 24 apresenta a organização desta visão.
Figura 24. Arquitetura do novo módulo como base no SIGUAN. FONTE: (SILVA, 2018).
Para o desenvolvimento do novo módulo seguindo esta visão, houve a criação do modelo, do serviço e do frontend Vue.js. Tal modelo especifica como ocorre o mapeamento objeto-relacional.
4.2.1.4 VISÃO DE PROCESSOS
A visão de processos deste modulo se baseia em demostrar como funciona o fluxo da visão lógica. A Figura 25 apresenta o diagrama de atividades que descreve as etapas para a criação de uma Análise de Clientela. Primeiramente o usuário deve inserir uma nova Análise, em seguida selecionar a análise que foi criada, após isso, deve-se criar a clientela que irá fazer parte da Análise selecionada anteriormente.
4.2.1.5 VISÃO DE IMPLANTAÇÃO
Nesta visão foi utilizado o novo processo que foi configurado na seção 3.5 NOVO FLUXO DE IMPLANTAÇÃO neste trabalho representado na Figura 26.
Diagrama de implantação do SIGUAN.
Figura 26. Diagrama de implantação do SIGUAN.
No diagrama da Figura 26 é apresentado como a visão de implantação do SIGUAN ficou organizada. Houve a criação de dois ambientes, o de produção e o de testes. Tais ambientes foram configurados dentro de um container Docker e possuem suas configurações idênticas. Um detalhe para o ambiente de testes, houve uma instancia do Jenkins conforme explicada e configurada na Seção 3.3
CONFIGURAÇÃO DO AMBIENTE DE PRODUÇÃO E TESTE UTILIZANDO DOCKER. E por fim, o usuário tem acesso apenas ao ambiente de produção, onde o SIGUAN está implantado de acordo com suas novas funcionalidades.
4.3 RESULTADOS OBTIDOS
Nesta seção abordará como foi feito o processo de implantação utilizando o novo fluxo de processo. Após as modificações serem feitas no código-fonte e enviadas para o Github, é necessário que ocorra a revisão de código. Caso
validado tais modificações, será integrado ao código-fonte do repositório principal. A Figura 27 ilustra o processo de revisão do código.
Figura 27. Processo de revisão de código.
Após essa validação, com todo o ambiente já configurado visto nas seções 3.3 CONFIGURAÇÃO DO AMBIENTE DE PRODUÇÃO E TESTE UTILIZANDO DOCKER e 3.4 CONFIGURAÇÃO DO JENKINS, automaticamente o Jenkins devido a configuração feita na seção 3.5 NOVO FLUXO DE IMPLANTAÇÃO será iniciado automaticamente o processo de implantação no servidor. A Figura 28 representa o processo de início do job de execução do ambiente de testes.
Figura 28. Build no Jenkins do ambiente de testes.
Ao final do job de testes, caso seja corretamente executado, automaticamente é iniciado o job do ambiente de produção, como representado na Figura 29.
Figura 29. Build no Jenkins do ambiente de produção.
Ao final do job do ambiente de produção, o sistema estará disponível para o acesso do usuário. Para utilização do novo módulo é necessário a criação de
uma Análise cliente cujo terá a data de criação e um identificador dessa análise. A Figura 30 ilustra um exemplo da Análise de clientela criada.
Figura 30. Criação da análise de comensais
Posteriormente é necessário selecionar a análise que foi adicionar na
Figura 30 e inserir para cada comensal os dados de altura, peso, idade e nível
de atividade física. Ao final do cadastramento dos comensais é necessário que o usuário realize manualmente o cálculo das médias. A Figura 31 ilustra a análise de clientela com o cálculo das médias já feito.
Figura 31. Cálculo da média calórica.
Por fim, durante o processo de criação uma prescrição, o nutricionista tem a possibilidade de utilizar as análises cadastradas. A Figura 32 ilustra o processo de criação de um prescrição e em destaque (em vermelho) é apresentado a média calórica da análise selecionada.
Figura 32. Cadastro de Prescrição com a utilização do módulo de Análise de Clientela.
O processo de criação de uma prescrição se tornou mais fácil, devido ao fato que o nutricionista tem uma possibilidade de maior distribuição de alimentos na formação de um novo cardápio para quaisquer dias.
5. CONCLUSÃO
Neste trabalho foi apresentado um novo processo de implantação para o SIGUAN com o objetivo de adequar o sistema para que a entrega de software seja rápida, através dos processos automatizados, e segura, através da realização de testes antes da implantação.
O objetivo de criação do módulo de testes automatizados foi atingido a partir do desenvolvimento dos testes unitários e testes de integração, como apresentado na Seção 3.2 NECESSIDADE DE CRIAÇÃO DE UM MÓDULO DE TESTES. Tal módulo promoveu ao SIGUAN uma maior qualidade de desenvolvimento voltado as metodologias ágeis. O objetivo de configuração do ambiente de produção e de testes atingido através da organização e execução do ambiente utilizando uma tecnologia de containers como apresentado na Seção 3.3. Tal configuração visa facilitar a configuração de novos ambientes de implantação. Por fim, o objetivo de especificação do processo de integração contínua foi alcançado através da configuração da ferramenta do Jenkins como elucidado na Seção 3.4 CONFIGURAÇÃO DO JENKINS, proporcionando um aumento da produtividade e uma maior confiabilidade do cliente.
A partir disso, pode-se concluir que o novo fluxo de processo de implantação automática proporcionando ao SIGUAN um ambiente adequado para implantações de novos requisitos de maneira rápida e com garantia do mínimo de qualidade.
5.1TRABALHOSFUTUROS
Este trabalho surgiu de um projeto de extensão e foi desenvolvido sob orientação de uma especialista da área de nutrição e professores do curso de Análise e Desenvolvimento de Sistemas da Escola Agrícola de Jundiaí (EAJ) da Universidade Federal do Rio Grande do Norte (UFRN).
Como trabalhos futuros pretende-se a refatoração do código seguindo o paradigma desenvolvimento orientado a testes, auxiliando o desenvolvedor a contemplar todo o sistema para que os testes sejam criados com mais eficácia.
REFERÊNCIAS
CURADO, Luis Augusto Trindade; MACHADO, Giselle Barbosa Gomes; SILVA, Rogério Oliveira. ENTENDENDO O DESENVOLVIMENTO ÁGIL. Tecnologias em Projeção, v. 7, n. 2, p.55, 2016.
CHEN, Lianping. Continuous Delivery: Overcoming adoption challenges. Dublin, Ireland, 2017
DIAS NETO, Arialo Claudio. Introdução a Teste de Software. Universidade Federal do Amazonas, 2015.
DOCKER. O que é o Docker?. Disponível em: <https://docs.microsoft.com/pt- br/dotnet/standard/microservices-architecture/container-docker-
introduction/docker-defined>. Acesso em: 16 mai. 2019
DOCKER HUB. Build and Ship any Application Anywhere. Disponível em: <https://hub.docker.com/>. Acesso em: 16 mai. 2019
DUVALL, Paul; MATYAS, Steve; GLOVER, Andrew. Continuous Integration:
Improving Software Quality and Reducing Risk. [S.l.]: Addison-Wesley, 2007.
(A Martin Fowler signature book). ISBN 9780321336385.
FADEL, Aline Cristine; SILVEIRA, Henrique da Mota. Metodologias ágeis no
contexto de desenvolvimento de software: XP, Scrum e Lean. UNICAMP –
Universidade Estadual de Campinas. 2010.
FARROHA, Bassam; FARROHA, Debora. A Framework for Managing Mission
Needs, Compliance and Trust in the DevOps Environment. IEEE Military Communications Conference, p. 288–293, out. 2014.
FEITELSON, Dror; FRACHTENBERG, Eitan; BECK, Kent. Development and
Deployment at Facebook. IEEE Internet Computing, v. 17, n. 4, p. 8–17, jul.
2013.
GOTTESHEIM, Wolfgang. Challenges, Benefits and Best Practices of
Performance Focused DevOps. Proceedings of the 4th International Workshop
on Large-Scale Testing, fev. 2015.
JENKINS. Build great things at any scale. Disponível em: <https://jenkins.io/>. Acesso em: 16 mai. 2019
JUNIT. The new major version of the programmer-friendly testing framework for Java. Disponível em: <https://junit.org/junit5/>. Acesso em: 16 mai. 2019.
KRUCHTEN, Philippe. Architectural Blueprints—The “4+1” View Model of
Software Architecture. Novembro, 1995.
LARMAN, C. (2004). Applying UML and Patterns: An Introduction to Object-
<https://doi.org/10.1016/j.nec.2006.05.008>.
LESSA, Rafael Orivaldo; LESSA JUNIOR, Edson Orivaldo. Modelos de
Processos de Engenharia de Software. Santa Catarina, 2013.
MOCKITO. Tasty mocking framework for unit tests in Java. Diposnível em: <https://site.mockito.org/>. Acesso em: 16 mai. 2019.
PIMENTEL, Andrey Ricardo. Teste de Software Estrutural ou “CaixaBranca” Disponível
em: <http://www.inf.ufpr.br/andrey/ci221/apresentacaoTesteEstrutural.pdf>. Acesso em: 30 mai. 2019.
PRESSMAN, Roger.; MAXIM, Bruce. Engenharia de software: uma
abordagem profissional. 8º ed. Porto Alegre: AMGH, 2016. 940 p. ISBN: 978-
85-8055-533-2
SILVA, Larysse Savanna Izidio. Sistema Integrado de Gestão de Unidades de
Alimentação e Nutrição: Módulo de Criação e Prescrição de Cardápios.
2018. 85 f. TCC (Graduação) - Curso de Análise e Desenvolvimento de Sistemas, Universidade Federal do Rio Grande do Norte, Macaíba, 2018.
SHARMA, Sanjeev; COYNE, Bernie. DevOps for dummies. 2. ed. New Jersey: John Wiley & Sons, 2015.
SWEBOK. Guide to the Software Engineering Body of Knowledge. Disponível em: <https://www.computer.org/education/bodies-of- knowledge/software-engineering/v3>. Acesso em: 29 mai. 2019
VELASQUEZ, Carlos Eduardo. Modelo de Engenharia de Software para o
Desenvolvimento de jogos e Simulações Interactivas. Porto, 2009.
WAKULICZ, Gilmar Jorge. Sistemas de informações gerenciais. Universidade Federal de Santa Maria, Colégio Politécnico, Rede e-Tec Brasil, 2016.
APÊNDICE A – ARQUIVOS DA IMAGEM DO TOMCAT
1 <Contextprivileged="true"
antiResourceLocking="false"docBase="${catalina.home}/webapps/manager"
>
2 <ValveclassName="org.apache.catalina.valves.RemoteAddrValve"
allow="^.*$" />
3 </Context>
Trecho de código 10. Arquivo manager.xml 1 <?xml version="1.0" encoding="UTF-8"?>
2 <!--
3 Licensed to the Apache Software Foundation (ASF) under one or more
4 contributor license agreements. See the NOTICE file distributed with
5 this work for additional information regarding copyright ownership.
6 The ASF licenses this file to You under the Apache License, Version 2.0
7 (the "License"); you may not use this file except in compliance with
8 the License. You may obtain a copy of the License at
9
10 http://www.apache.org/licenses/LICENSE-2.0 11
12 Unless required by applicable law or agreed to in writing, software 13 distributed under the License is distributed on an "AS IS" BASIS, 14 WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either
express or implied.
15 See the License for the specific language governing permissions and 16 limitations under the License.
17 -->
18 <tomcat-users xmlns="http://tomcat.apache.org/xml"
19 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
20 xsi:schemaLocation="http://tomcat.apache.org/xml tomcat- users.xsd"
21 version="1.0">
22
23 <role rolename="manager-gui"/>
24 <role rolename="manager-script"/>
25 <user username="tomcat"password="tomcat"roles="manager- gui,manager-script"/>
Arquivos no link: https://drive.google.com/open?id=1dPjnKgAiyZ2Oz0qIYIA8Pyl8M0j_L9NK Trecho de código 11. Arquivo tomcat-users.xml
1 <?xml version="1.0" encoding="UTF-8"?>
2 <!--
3 Licensed to the Apache Software Foundation (ASF) under one or more
4 contributor license agreements. See the NOTICE file distributed with
5 this work for additional information regarding copyright ownership.
6 The ASF licenses this file to You under the Apache License, Version 2.0
7 (the "License"); you may not use this file except in compliance with
8 the License. You may obtain a copy of the License at
9
10 http://www.apache.org/licenses/LICENSE-2.0 11
12 Unless required by applicable law or agreed to in writing, software 13 distributed under the License is distributed on an "AS IS" BASIS, 14 WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either
express or implied.
15 See the License for the specific language governing permissions and 16 limitations under the License.
17 -->
18 <Context>
19
20 <WatchedResource>WEB-INF/web.xml</WatchedResource>
21
<WatchedResource>${catalina.base}/conf/web.xml</WatchedResource>
22
23 </Context>
24 <?xml version="1.0" encoding="UTF-8"?>
25 <!--
26 Licensed to the Apache Software Foundation (ASF) under one or more Trecho de código 12. Arquivo context.xml
APÊNDICE B – DETALHAMENTO DE CASOS DE USO UC 1. Gerenciar Análises de Clientela
A análise de clientela é definida a partir da média dos valores de peso, altura, idade e nível de atividade física dos comensais. Com o uso dessas variáveis aplicadas a uma equação recomendada é possível encontrar a média calórica de uma clientela. Sendo assim, o Nutricionista e o Estagiário de Nutrição podem gerenciar a funcionalidade de cadastrar, buscar, atualizar e remover uma análise de clientela do sistema. Porém, apenas o Nutricionista pode escolher a Análise de clientela e aplicar a análise de clientela e escolher a melhor equação para a clientela disponível, devido ao UC2. Gerenciar Prescrição ser algo restrito ao Nutricionista. Os casos de uso secundários que fazem parte de Gerenciar Unidades estão descritos na Tabela 5.
Tabela 5. UC1 Gerenciar Análises de Clientela. Caso de Uso Objetivo
UC1.1: Cadastrar Análise de clientela
Os atores realizam o cadastro de unidades no sistema
UC1.2: Buscar Análise de clientela
Os atores realizam a busca de unidades no sistema
UC1.3: Atualizar Análise de clientela
Os atores realizam a atualização de unidades cadastradas no sistema
UC1.4: Remover Análise de clientela
Os atores realizam a remoção de unidades no sistema
UC1.5: Aplicar Análise de comensais
Os atores realizam a aplicação da análise de comensais no cadastro de uma prescrição.