Sistema Integrado de Gestão de Unidades de Alimentação e Nutrição: Módulo de Criação e Prescrição de Cardápios

(1)

UNIDADE ACADÊMICA ESPECIALIZADA EM CIÊNCIAS AGRÁRIAS CURSO SUPERIOR DE TECNOLOGIA EM ANÁLISE E DESENVOLVIMENTO DE

SISTEMAS

LARYSSE SAVANNA IZIDIO DA SILVA

SISTEMA INTEGRADO DE GESTÃO DE UNIDADES DE ALIMENTAÇÃO E NUTRIÇÃO

Módulo de Criação e Prescrição de Cardápios

Macaíba, RN 2018

(2)

Trabalho de conclusão de curso de graduação apresentado à Unidade Especializada em Ciências Agrárias – Escola Agrícola de Jundiaí da Universidade Federal do Rio Grande do Norte como requisito parcial para a obtenção do título de Tecnóloga em Análise e Desenvolvimento de Sistemas.

Orientador: Prof. Dr. Taniro Chacon Rodrigues Coorientadora: Ma. Taiana Brito Menêzes Flor

Macaíba, RN 2018

(3)

Universidade Federal do Rio Grande do Norte - UFRN Sistema de Bibliotecas - SISBI

Catalogação de Publicação na Fonte. UFRN - Biblioteca Central Zila Mamede – Escola Agrícola de Jundiaí - EAJ

Silva, Larysse Savanna Izidio da.

Sistema integrado de gestão de unidades de alimentação e nutrição / Larysse Savanna Izidio da Silva. - 2018.

80 f.: il.

Monografia (graduação) - Universidade Federal do Rio Grande do Norte, Unidade Especializada em Ciências Agrárias, Curso de Tecnologia em Análise e Desenvolvimento de Sistemas. Macaíba, RN, 2018.

Orientador: Prof. Dr. Taniro Chacon Rodrigues. Coorientadora: Profª. Ma. Taiana Brito Menêzes Flor.

1. Sistema de informação gerencial (SIG) - Monografia. 2. Nutrição - Monografia. 3. Unidade de alimentação e nutrição (UAN) - Monografia. 4. Alimentação coletiva - Monografia. I. Rodrigues, Taniro Chacon. II. Flor, Taiana Brito Menêzes. III. Título. RN/UF/BCZM CDU 681.5:612.39

(4)

Trabalho de conclusão de curso de graduação apresentado à Unidade Especializada em Ciências Agrárias – Escola Agrícola de Jundiaí da Universidade Federal do Rio Grande do Norte como requisito parcial para a obtenção do título de Tecnóloga em Análise e Desenvolvimento de Sistemas.

Aprovado em: ____ de _______ de _____.

BANCA EXAMINADORA

__________________________________________ Prof. Dr. Taniro Chacon Rodrigues – EAJ/UFRN - Orientador

__________________________________________ Ma. Taiana Brito Menêzes Flor - EAJ/UFRN - Coorientadora

__________________________________________

Profª. Drª Laura Emmanuella Alves dos Santos Santana de Oliveira – EAJ/UFRN

__________________________________________ Prof. Dr. Eiji Adachi Medeiros Barbosa- IMD/UFRN

(5)

Dedico este trabalho primeiramente à Deus, por estar sempre presente em minha vida, aos meus pais, meus irmãos, amigos e professores que me deram todo o apoio nessa jornada de desafios e aprendizado.

(6)

para seguir em frente e dar sempre o meu melhor.

Agradeço à minha família por acreditar em mim e investir no meu futuro. Aos meus pais, Cícero Vicente e Edineuza Izidio, por serem pais amorosos e dedicados. Aos meus irmãos, Luiz Gustavo e Luzyana Izidio, agradeço por me proporcionarem tantos momentos de alegria e por entenderem nas vezes em que não pude estar presente.

Agradeço a todos os meus amigos que me acompanharam na minha trajetória, em especial: Íris, Iaslan, Arthur, Joffrey, Washi, Eric, Babi, Joel e Rayane que também se tornaram família e trouxeram tantos momentos bons que tornaram a minha vida acadêmica mais leve. Agradeço também a todos os amigos do Laboratório UBICOMP e dos demais laboratórios do TAPIOCA, em especial aos meus irmãos acadêmicos: Fábio Henrique por todas as brincadeiras e disputas sobre quem era o filho preferido e Assis Lucas por dividir comigo os momentos de preocupação com a Monografia. Agradeço também a aos amigos Tuany Mariah e Lucas Andrade por todo apoio e incentivo.

Agradeço a todos os meus professores e orientadores por todo o conhecimento que adquiri tanto em sala de aula, quanto fora dela nos diversos projetos que tive o prazer de participar. Um agradecimento especial ao meu orientador, professor e amigo Taniro Rodrigues por todos os ensinamentos e diversos conselhos que, sem dúvidas, foram essenciais para que eu chegasse onde cheguei. Agradeço por toda a compreensão, puxões de orelha e por me ensinar que “é preciso dividir para conquistar” sempre que teimei em querer carregar o mundo nas costas (risos). Obrigada por me servir de exemplo e por contribuir tanto para o meu crescimento acadêmico e profissional. Agradeço a minha coorientadora Taiana Menezes que me acompanhou desde o início da graduação até o final, com quem aprendi bastante sobre a área de Nutrição. Agradeço também ao Prof. Márcio Dias, que me orientou no meu primeiro projeto da graduação e foi o primeiro a acreditar no meu potencial, que também teve grande contribuição para a minha vida acadêmica e por quem tenho um carinho enorme. Agradeço também a Profª Laura Emmanuella e ao Prof. Helder Pacheco por todo o carinho.

(7)

(8)

soluções para auxiliar na gestão de organizações públicas e privadas. As Unidades de Alimentação e Nutrição (UAN) são responsáveis pela produção e distribuição de refeições a grupos de pessoas em diferentes tipos de estabelecimentos. A UAN possui um processo de operacionalização complexo e o nutricionista deve gerenciar desde a estrutura física, equipamentos e funcionários até o planejamento, execução e avaliação de cardápios entre diversas outras atividades. Esses fatores dificultam o gerenciamento das UANs, tornando seu funcionamento mais complexo, dependendo da quantidade e tipo de refeições produzidas. Tendo em vista essa problemática, o objetivo dessa Monografia é apresentar o desenvolvimento de um Sistema Integrado de Gestão de Unidades de Alimentação e Nutrição (SIGUAN) que visa auxiliar o nutricionista na elaboração e prescrição de cardápios e nas atividades de gestão da UAN. O SIGUAN teve sua arquitetura planejada com base no modelo 4+1 e foi desenvolvido com base no estilo arquitetural REST. Suas funcionalidades vão desde a criação e prescrição de cardápios até o gerenciamento de insumos, preparações, estoque e salas de preparação, que são partes comumente presentes nas UANs. A avaliação deste trabalho foi realizada através da execução de um experimento controlado elaborado com base em métodos propostos por diferentes autores, um deles foi o método GQM. Nesse experimento o SIGUAN foi avaliado em termos de usabilidade, utilidade e produtividade em comparação com a abordagem tradicional de criação e prescrição de cardápios utilizando o Excel. Os resultados da avaliação mostraram que o SIGUAN atingiu os objetivos almejados. Palavras-chave: SIG, Sistema de Informação, UAN, Alimentação Coletiva.

(9)

in the management of public and private organizations. The Food and Nutrition Units (UAN) are responsible for the production and distribution of food to groups of people in different types of establishments. The UAN has a complex operation process and the nutritionist must manage everything from the physical structure, equipment and employees to the planning, execution and evaluation of menus in addition to several other activities. These factors make the UANs management difficult, making their operation more complex, depending on the quantity and type of meals produced. In view of this problem, the purpose of this Monograph is to present the development of an Integrated Management System for Food and Nutrition Units (SIGUAN), which aims to assist the nutritionist in menus elaboration and prescribing and in the UAN’s activities management. SIGUAN architecture was planned based on the 4 + 1 model and it was developed based on the REST architectural style. Its functionalities range from the menus creation and prescription to the ingredients, preparations, stock and preparation rooms management, which are common parts of UANs. The evaluation of this work was performed through the execution of a controlled experiment elaborated based on methods proposed by different authors, one of them was the GQM method. In this experiment, SIGUAN was evaluated in terms of usability, utility and productivity compared to the traditional approach to creating and prescribing menus using Excel. The results of the evaluation showed that SIGUAN achieved the objectives.

(10)

Figura 1. Estrutura de um cardápio semanal. ... 16

Figura 2. Desenvolvimento iterativo e incremental. ... 18

Figura 3. Diagrama de Sequência da comunicação entre Cliente e Servidor Web. ... 20

Figura 4. Exemplo de componente Vue. ... 22

Figura 5. Reutilização de componentes Vue. ... 22

Figura 6. Ciclo de vida do OpenUP. ... 23

Figura 7. Modelo arquitetural de visões 4+1. ... 26

Figura 8. Diagrama de Casos de Uso. ... 27

Figura 9. Versão simplificada do Diagrama de Classes do SIGUAN. ... 28

Figura 10. Arquitetura do sistema. ... 31

Figura 11. Diagrama de implantação. ... 32

Figura 12. Diagrama de atividades da criação de cardápio. ... 33

Figura 13. Diagrama de atividades da criação de prescrição. ... 34

Figura 14. Exemplo de requisição de login. ... 35

Figura 15. Exemplo de envio do token. ... 35

Figura 16. Exemplo de solicitação de um insumo utilizando o método HTTP GET. ... 36

Figura 17. Exemplo de cadastro de insumo utilizando o método HTTP POST. ... 37

Figura 18. Exemplo de alteração dos dados de um insumo utilizando o método HTTP PUT. ... 37

Figura 19. Exemplo se remoção de insumo utilizando o método HTTP DELETE... 38

Figura 20. Exemplo de prescrição de um cardápio. ... 39

Figura 21. Template da tela de login do SIGUAN. ... 39

Figura 22. Tela de login do SIGUAN. ... 40

Figura 23. Painel de controle do SIGUAN... 41

Figura 24. Tela de cadastro de insumo per capita. ... 42

Figura 25. Tela de cadastro de preparação. ... 42

(11)

Figura 29. Nível de conhecimento em Nutrição... 50 Figura 30. Nível de conhecimento em Excel. ... 51 Figura 31. Diagrama de Classes completo. ... 77

(12)

Tabela 2. Requisitos funcionais. ... 24

Tabela 3. Requisitos não-funcionais. ... 25

Tabela 4. Descrição do Diagrama de Classes. ... 29

Tabela 5. Tarefas executadas pelos participantes. ... 51

Tabela 6. Questionário para a variável de Facilidade de Uso Percebida. ... 54

Tabela 7. Resultados do questionário sobre facilidade de uso percebida. ... 55

Tabela 9. Questionário para a variável de Utilidade Percebida. ... 55

Tabela 10. Resultados do questionário sobre utilidade percebida. ... 56

Tabela 12. Duração da execução das tarefas pelos participantes. ... 56

Tabela 13. Tempo médio de realização das tarefas. ... 57

(13)

EAJ – Escola Agrícola de Jundiaí REST - Representational State Transfer SIG – Sistema Integrado de Gestão

SIGUAN - Sistema Integrado de Gestão de Unidades de Alimentação e Nutrição UAN – Unidades de Alimentação e Nutrição

(14)

1. INTRODUÇÃO ... 9

1.1 JUSTIFICATIVA ... 10

1.1.1 ABORDAGEM TRADICIONAL ... 12

1.2 VISÃO GERAL DO TRABALHO ... 12

1.3 OBJETIVOS ... 13

1.3.1 OBJETIVO GERAL ... 13

1.3.2 OBJETIVOS ESPECÍFICOS ... 13

1.4 ORGANIZAÇÃO DO TRABALHO ... 13

2. CONCEITOS BÁSICOS ... 15

2.1 PLANEJAMENTO E PRESCRIÇÃO DE CARDÁPIOS NA UAN ... 15

2.2 SISTEMAS DE INFORMAÇÃO ... 17

2.3 PROCESSO UNIFICADO ... 17

2.4 ARQUITETURA ORIENTADA A SERVIÇOS (SOA) ... 19

2.5 SERVIÇO WEB ... 19 2.6 REST ... 20 2.7 VUE.JS ... 21 3. DESENVOLVIMENTO ... 23 3.1 INICIAÇÃO ... 23 3.2 ELABORAÇÃO ... 25 3.2.1 VISÕES 4+1 ... 26

3.2.2 VISÃO DE CASOS DE USO ... 26

3.2.3 VISÃO LÓGICA ... 28 3.2.4 VISÃO DE IMPLEMENTAÇÃO ... 30 3.2.5 VISÃO DE IMPLANTAÇÃO ... 32 3.2.6 VISÃO DE PROCESSOS ... 33 3.3 CONSTRUÇÃO ... 34 3.4 TRANSIÇÃO ... 45 4. AVALIAÇÃO ... 46 4.1 OBJETIVOS DA AVALIAÇÃO ... 46 4.2 QUESTÕES ... 46

(15)

4.5 PARTICIPANTES ... 50

4.6 TAREFAS ... 51

4.7 ROTEIRO DO EXPERIMENTO ... 52

4.8 HIPÓTESES ... 53

4.9 ANÁLISE DOS RESULTADOS ... 54

4.10 ANÁLISE DAS MÉTRICAS ... 58

4.11 AMEAÇAS À VALIDADE DO EXPERIMENTO ... 60

5. CONCLUSÃO ... 62

5.1 TRABALHOS FUTUROS ... 62

REFERÊNCIAS ... 64

APÊNDICE A – DETALHAMENTO DE CASOS DE USO ... 67

(16)

(17)

1. INTRODUÇÃO

Com o desenvolvimento da Tecnologia da Informação, as empresas, instituições e organizações públicas e privadas estão adotando cada vez mais o uso de novas tecnologias para auxiliar na gestão devido à complexidade de suas atividades, funcionamento de processos, envolvimento de pessoas, entidades externas e a manipulação de diversas informações. Entre as tecnologias mais utilizadas encontram-se os Sistemas de Informação que, no ambiente das organizações, são todos os sistemas que coletam, processam, armazenam, analisam e distribuem informações para execução de ações e para auxiliar no processo de tomadas de decisões, na organização e no controle de uma organização (WAKULICZ, 2016).

A adoção dos Sistemas de Informação tem afetado significativamente o modo como essas organizações realizam suas atividades, como as tarefas que antes eram executadas de forma manual e atualmente são realizadas de forma automática, proporcionando mais praticidade e rapidez. Entre os diversos tipos de Sistemas de Informação, encontram-se os Sistemas Integrados de Gestão (SIG) que permitem a integração de várias áreas de uma organização, aumentando a confiabilidade e a produtividade. Ao utilizar um SIG, diversos setores como estoques, produção, logística, compras, entre outros, podem trabalhar e desenvolver-se de forma integrada. (FERRO, 2016). Dessa forma, a organização como um todo pode trabalhar de forma mais eficiente e obter melhores resultados. Outra vantagem dos SIGs é a possibilidade de obter um maior controle do processo de trabalho, gerar informações em tempo hábil, diminuir os custos e controlar os setores. Tais características impactam na redução dos possíveis erros que podem ocorrer durante a gestão. Uma potencial aplicação para esse tipo de sistema ocorre nas organizações que prestam serviços de saúde, como, por exemplo, na área de Nutrição.

O campo da Nutrição possui diversas áreas de atuação, entre elas encontra-se a de Alimentação Coletiva onde o nutricionista atua no planejamento e no controle da qualidade de refeições, no treinamento de funcionários, na administração de custos, entre diversas outras atividades. Além disso, o nutricionista deve supervisionar e avaliar os serviços prestados pelas Unidades de Alimentação e Nutrição (UAN), que são responsáveis pela produção e distribuição de refeições a grupos de pessoas em diferentes tipos de estabelecimentos (CAMPOS et al, 2016). As UANs possuem uma estrutura organizacional linear, caracterizada por unidade de comando, representada por um nutricionista responsável e um número reduzido de níveis hierárquicos. Esses fatores dificultam o gerenciamento das unidades de

(18)

alimentação, tornando seu funcionamento mais complexo, dependendo da quantidade e tipo de refeições produzidas (COLARES, 2007COLARES).

O nutricionista é o profissional responsável por gerenciar uma equipe de funcionários, bem como a estrutura física, equipamentos, planejamento, execução e avaliação de cardápios, controle de custos, gestão de suprimentos entre diversas outras atividades que são de grande importância para o funcionamento adequado da UAN (CONSELHO FEDERAL DE NUTRICIONISTAS, 2018). Muitas dessas atividades são executadas de forma simultânea, tornando a rotina de trabalho nas UANs bastante intensa. Os cardápios normalmente são planejados com antecedência e compostos das receitas, também chamadas pelos especialistas da área, os nutricionistas, de preparações, que serão servidas. É necessário especificar quais ingredientes, ou insumos, serão utilizados para cada preparação. Para isso, deve-se especificar a quantidade de insumos per capita, ou seja, a quantidade necessária de insumos para apenas uma pessoa, e então calcular a quantidade necessária de insumos para as refeições que compõem o cardápio de um dia (café da manhã, almoço, jantar, etc.) de acordo com a quantidade prevista de usuários que irão consumir os alimentos, ou comensais. As informações relacionadas aos funcionários, estoque, refeições, público externo, etc., são de grande importância para o gerenciamento de uma UAN devido à complexidade das atividades do nutricionista. O acesso a essas informações de forma ágil e prática é fundamental para obter mais eficiência.

Nesse contexto, a utilização de um SIG para integrar diferentes áreas de uma instituição tem grande potencial para melhoria do uso de recursos, sejam eles físicos, como insumos, salas etc., ou de pessoal, como o nutricionista e demais funcionários envolvidos. Com o uso de um único sistema para integrar todos os setores de uma UAN, ou pelo menos os setores mais importantes, a comunicação interna se torna mais fácil e prática. Por exemplo, o setor de estoque pode identificar rapidamente a quantidade de insumos que serão levados para as salas de preparação de acordo com as informações que o setor de nutrição disponibiliza no sistema. O nutricionista pode identificar a quantidade necessária de cada ingrediente para as preparações com base na média de refeições servidas diariamente.

1.1 JUSTIFICATIVA

Devido a variação frequente do número de usuários que são atendidos diariamente nas UANs, o processo de planejamento de refeições e cardápios se torna exaustivo e demanda bastante tempo por exigir uma manipulação de per capitas e somatório de insumos que se repetem nas preparações para solicitação diária de retirada de itens da despensa. Diante disso,

(19)

o uso de ferramentas computacionais como os Sistemas de Informação pode contribuir para a diminuição do tempo gasto em uma única tarefa, disponibilizando mais tempo para as outras atividades de gestão das UANs e reduzindo sua complexidade.

Existem no mercado diversos softwares destinados à prescrição de cardápios individuais para acompanhamento clínico, porém, há uma escassez de ferramentas destinadas à gestão de restaurantes institucionais.

O SchoolMeals (desenvolvido pela Teknisa) é um sistema voltado para a gestão de merendas escolares e é destinado a empresas do ramo de alimentação escolar e a prefeituras que desejam administrar de forma centralizada a produção e distribuição de alimentos usados no preparo das refeições dos estudantes. O programa auxilia na redução do desperdício de alimentos e permite o cadastro de produtos adquiridos para as merendas e a elaboração dos cardápios que serão servidos nas escolas abastecidas. Para o controle do estoque, é necessário instalar um aplicativo que é integrado ao sistema da central de merendas para compartilhamento dos dados, assim a prefeitura consegue saber os alimentos que estão em falta, o consumo médio de cada escola e determinar qual deve ser a velocidade média da reposição. Apesar de auxiliar na elaboração de cardápios e no gerenciamento do estoque, essa ferramenta é voltada apenas para o ambiente escolar, portanto a sua utilização em outros tipos de UAN (como restaurantes de hospitais) se torna inviável, além de ser uma ferramenta comercial e não se tratar de uma ferramenta aberta, o que impossibilita a expansão de suas funcionalidades.

O Dietpro Clínico (desenvolvido pela Dietpro) é um software desenvolvido para auxiliar o nutricionista no atendimento clínico. A ferramenta facilita o gerenciamento dos pacientes e a realização de atividades como avaliações nutricionais, cálculos energéticos, prescrição do plano alimentar e elaboração de cardápios individuais e modelos de dietas. Por se tratar de um produto, a comercialização do Dietpro Clínico é disponibilizada apenas na forma de instalação, onde cada uma apresentará características relacionadas a sua condição de liberação e ao perfil do cliente.

O sistema TecDiet (desenvolvido pela Teknisa) é uma ferramenta que foi desenvolvida para auxiliar no controle da produção, distribuição e custos das refeições hospitalares. Suas funcionalidades vão desde a elaboração de refeições e avaliação dos custos da produção até a realização de avaliação nutricional dos pacientes. Uma característica desse software é a possibilidade de elaborar cardápios para o paciente de acordo com seu estado nutricional, permitindo também o acesso rápido a informações como restrições, intolerância alimentar e interação droga-nutriente no cardápio de cada paciente. Apesar de auxiliar na

(20)

elaboração de cardápios e no controle do estoque, o sistema não permite gerenciar alguns dos principais setores de uma UAN como salas de preparação, equipamentos e funcionários. 1.1.1 ABORDAGEM TRADICIONAL

A UAN utilizada como modelo para a execução deste projeto foi o Restaurante Universitário (RU) da Escola Agrícola de Jundiaí (EAJ) da Universidade Federal do Rio Grande do Norte (UFRN). No processo de planejamento e criação de cardápios dessa UAN, os funcionários que executam as operações precisam saber toda a listagem de ingredientes e informações necessárias para que o que foi planejado seja de fato executado. O número de refeições varia de acordo com a quantidade de usuários da UAN, portanto há uma preocupação diária com a otimização dos recursos. Dessa forma, não é possível trabalhar com receitas padronizadas, pois diariamente é preciso fazer ajustes para o número de usuários esperado. A atividade de determinar os ingredientes que vão em cada preparação é denominada Prescrição.

A prescrição de um cardápio é feita no RU da EAJ por meio de planilhas de Excel, havendo a necessidade diária de analisar o número de refeições e fazer constantes ajustes em função do grau de maturação de frutas e hortaliças ou vencimento de produtos, o que impossibilita o nutricionista trabalhar de maneira estática com quantidades pré-definidas.

Tendo em vista o cenário apresentado, o presente trabalho é proposto com o intuito de oferecer uma ferramenta que permite gerenciar os principais setores da UAN (citados anteriormente), que agilize o trabalho do nutricionista permitindo que os principais setores da UAN trabalhem de forma integrada e eficiente. Além de ser uma ferramenta livre, o sistema desenvolvido neste trabalho permite que todas as suas funcionalidades sejam expandidas, o que se torna mais um diferencial em relação aos sistemas já existentes. Essa possibilidade de expansão das funcionalidades ocorre pelo fato das funcionalidades do sistema estarem disponíveis através de uma API (Application Programming Interface) aberta disponibilizada de maneira pública.

1.2 VISÃO GERAL DO TRABALHO

O Sistema Integrado de Gestão de Unidades de Alimentação e Nutrição (SIGUAN) é composto de um conjunto de módulos, onde cada módulo é responsável por gerenciar um determinado conjunto de tarefas da UAN. O foco deste trabalho é o Módulo de Criação e Prescrição de Cardápios, responsável por auxiliar o nutricionista no processo de planejamento e execução de cardápios da UAN.

(21)

O SIGUAN surgiu de um projeto de extensão aplicado na EAJ da UFRN. O desenvolvimento do sistema completo contou com a participação de 6 alunos do curso de Análise e Desenvolvimento de Sistema com a colaboração de professores do curso e nutricionistas do Restaurante Universitário da EAJ.

A solução proposta foi desenvolvida de forma a atender às necessidades do profissional de nutrição no gerenciamento da UAN, principalmente nas atividades de planejamento de cardápios. As ferramentas utilizadas na implementação foram escolhidas com o intuito de facilitar o desenvolvimento e o trabalho dos integrantes do projeto.

1.3 OBJETIVOS

Nas subseções seguintes serão apresentados o objetivo geral e os objetivos específicos.

1.3.1 OBJETIVO GERAL

O objetivo deste trabalho é propor e implementar um sistema de apoio ao nutricionista no planejamento e prescrição de cardápios e no gerenciamento de Unidades de Alimentação e Nutrição.

1.3.2 OBJETIVOS ESPECÍFICOS

Como objetivos específicos podem ser citados:

• Elaboração de um modelo de sistema útil e que aumente a produtividade do profissional de nutrição no processo de planejamento e prescrição de cardápios;

• Implementação da API e serviços para manipulação dos dados; • Construção do Módulo de Elaboração e Prescrição de Cardápios; • Construção do Módulo de Geração de Relatórios;

• Construção do Módulo de Interface Web de fácil utilização.

1.4 ORGANIZAÇÃO DO TRABALHO

O restante deste trabalho está organizado da seguinte forma:

• O Capítulo 2 apresenta os conceitos básicos para este trabalho;

• O Capítulo 3 descreve a arquitetura e todo o processo de desenvolvimento do sistema;

(22)

• O Capítulo 4 descreve como este trabalho foi avaliado;

(23)

2. CONCEITOS BÁSICOS

Este Capítulo apresenta os conceitos básicos acerca das abordagens e tecnologias utilizadas para o desenvolvimento do SIGUAN, assim como conceitos relacionados à área de nutrição no contexto das UANs. O Capítulo 2 está organizado da seguinte forma: a Seção 2.1 que descreve os principais conceitos relacionados ao planejamento e prescrição de cardápios em uma UAN; a seção 2.2 que apresenta o conceito de Sistemas de Informação; a seção 2.3 que descreve o Processo Unificado de desenvolvimento de software; a seção 2.4 que apresenta o conceito da Arquitetura Orientada a Serviços; a Seção 2.5 descreve o que são e como funcionam os serviços web; a Seção 2.6 apresenta o estilo arquitetural REST adotado neste trabalho para a criação dos serviços web e, por fim, a Seção 2.7 descreve o framework Vue.js utilizado para o desenvolvimento para a interface do usuário.

2.1 PLANEJAMENTO E PRESCRIÇÃO DE CARDÁPIOS NA UAN

O nutricionista é o profissional habilitado para atuar na gestão de pessoas, gestão da estrutura física, equipamentos e utensílios, planejamento, execução e avaliação de cardápios mudanças dos processos, nas condições e ambientes de trabalho, etc. O trabalho do nutricionista, em uma UAN, abrange o monitoramento das boas práticas de produção, controle higiênico-sanitário da UAN e das refeições oferecidas e o atendimento aos clientes.

Uma Unidade de Alimentação e Nutrição (UAN) envolve um complexo sistema operacional, com procedimentos que devem ser padronizados, claros e precisos de maneira que todos os funcionários possam executá-los com rapidez. O principal objetivo da UAN é fornecer uma alimentação segura, que possa garantir os principais nutrientes necessários para manter, ou recuperar a saúde de todos aqueles que usufruem do seu serviço (Fonseca, 2012).

No contexto das UANs, o cardápio é composto por menus diários onde em cada menu são especificadas as refeições de cada dia como, por exemplo: café da manhã, almoço e jantar. Em cada refeição devem ser especificadas as receitas que serão elaboradas e servidas. Essas receitas são chamadas de preparações. Para elaborar uma preparação é necessário definir a quantidade de ingrediente (também chamado de insumo) necessária para uma pessoa, esse dado é chamado de per capita que equivale ao peso bruto do insumo. É a partir do per capita que será calculada a quantidade necessária de ingredientes para servir o número total de usuários previstos para uma determinada refeição. Essa previsão de usuários é chamada de previsão de comensais. A Figura 1 apresenta a estrutura de um cardápio semanal da UAN da EAJ.

(24)

Figura 1. Estrutura de um cardápio semanal.

FONTE: própria da autora.

O ato de determinar o que vai em cada preparação do cardápio e suas respectivas quantidades é denominado prescrição. Essa determinação é baseada no cálculo da quantidade necessária de insumos para uma preparação, esse cálculo é feito da seguinte forma:

Q = PC*P Onde:

Q = Quantidade total necessária de insumo. PC = Valor do peso bruto per capita do insumo. P = Previsão de comensais.

Cada colaborador da UAN tem sua rotina de trabalho determinada. Alguns são designados para manipular os vegetais, outros as carnes, outros sobremesas e sucos, além do cozinheiro, profissional responsável pela cocção e finalização das preparações. Os funcionários que irão executar as operações precisam saber toda a listagem de ingredientes e informações necessárias para que o que foi planejado seja de fato executado. Uma UAN normalmente possui salas de manipulação conforme o tipo de alimento e atividade a ser desenvolvida, a fim de evitar contaminação devido a “mistura” de alimentos e operações, portanto é importante gerar relatórios para cada sala de preparação especificando a listagem de ingredientes e instruções de trabalho, tais como as técnicas de cocção, que é o modo de

(25)

cozimento da preparação; tipo de corte do insumo, que especifica como aquele insumo deve ser cortado; modo de preparo, etc. Esses relatórios são essenciais à correta execução do cardápio, uso adequado dos insumos disponíveis e otimização da atividade de supervisão da execução do cardápio por parte do nutricionista.

2.2 SISTEMAS DE INFORMAÇÃO

A informação tem grande importância para as organizações, inclusive para as UANS. Por essa razão, é importante o uso de um Sistema de Informação (SI) para organizar e controlar informações referentes ao funcionamento das organizações em geral. Segundo Gonçalves (2012), o conceito de SI abrange qualquer sistema que manipula dados e gera informação. Os sistemas de informação têm por objetivo gerar informações para auxiliar no processo de tomada de decisões. Nesses sistemas os dados são coletados, processados e transformados em informação útil.

De acordo com Gonçalves (2012), o sucesso da aplicação de um SI ligado à tecnologia requer a compreensão do ambiente que está recebendo o apoio do sistema. Por exemplo, para desenvolver um SI que dê apoio às transações realizadas em um supermercado, é preciso compreender todos os processos e procedimentos relacionados como a compra e venda de produtos nas lojas, demandas irregulares feitas ao sistema, etc. Da mesma forma acontece a um SI aplicado a uma UAN. É preciso entender todas as atividades que ocorrem no ambiente e seus relacionamentos.

De acordo com Davis (1989), dentre os fatores que influenciam na aceitação de um SI pelo usuário encontram-se as características de facilidade de uso e utilidade. Dessa forma, um bom SI deve ser desenvolvido de forma que auxilie o usuário no seu propósito de forma útil e que não possua um nível alto de complexidade.

2.3 PROCESSO UNIFICADO

O Processo Unificado (PU) surgiu como um processo popular para o desenvolvimento de software visando a construção de sistemas orientados a objetos. É um processo iterativo e adaptativo de desenvolvimento e vem ganhando cada vez mais adeptos devido a maneira organizada e consistente que permite conduzir um projeto.

O ciclo de vida iterativo e incremental é baseado em refinamentos e incrementos sucessivos a fim de convergir para um sistema adequado. Em cada iteração incrementa-se um pouco mais o produto, baseando-se na experiência obtida nas iterações anteriores e no feedback do usuário. Cada iteração pode ser considerada um miniprojeto de duração fixa,

(26)

sendo que cada um destes inclui suas próprias atividades de análise de requisitos, projeto, implementação e testes (BRAZ, 2006).

Figura 2. Desenvolvimento iterativo e incremental.

FONTE: (BRAZ, 2006).

O Processo Unificado é organizado em quatro fases principais:

• Concepção: nessa fase ocorre o levantamento do escopo do projeto de uma forma geral. Não deve existir aqui a pretensão de especificar de forma detalhada requisitos, a ideia é ter uma visão inicial do problema, estimar de forma vaga esforço e prazos e determinar se o projeto é viável e merece uma análise mais profunda.

• Elaboração: na fase de elaboração todos (ou a grande maioria dos requisitos) são levantados em detalhes. Estes são implementados e servem como base de avaliação junto ao usuário e desenvolvedores para o planejamento da próxima iteração. Em cada nova iteração na fase de elaboração pode haver um seminário de requisitos, onde requisitos antigos são melhor esclarecidos e novos são detalhados. Ao fim da fase, 90% dos requisitos foram levantados em detalhes, o núcleo do sistema foi implementado com alta qualidade, os principais riscos foram tratados e pode-se então fazer estimativas mais realistas.

• Construção: implementação iterativa dos elementos restantes de menor risco e mais fáceis e preparação para a implantação.

(27)

2.4 ARQUITETURA ORIENTADA A SERVIÇOS (SOA)

A Arquitetura Orientada a Serviços (do inglês, Service-Oriented Architecture - SOA) é um paradigma que determina que as aplicações sejam construídas e reorganizadas através de serviços específicos e bem definidos que são disponibilizados por um ou mais provedores de serviço. Essa abordagem arquitetural é utilizada para lidar com a heterogeneidade sendo conveniente quando é necessário haver a comunicação entre diversas aplicações que são executadas em diferentes tecnologias e plataformas. A SOA promove a interoperabilidade entre os serviços com a utilização de protocolos padronizados e tecnologias como o SOAP (Simple Object Access Protocol) e REST (Representational State Transfer) fazendo com que exista um fraco acoplamento entre os elementos. Dessa forma, cada elemento define sua própria interface de acesso de modo que a interface esteja separada da implementação, o que proporciona maior transparência para as aplicações clientes.

2.5 SERVIÇO WEB

Serviços Web (Web Services) são sistemas de software identificados por URIs (Uniform Resource Identifier) que possibilitam a comunicação entre diferentes máquinas através da rede, realizando a troca de mensagens através de um protocolo de comunicação como, por exemplo, o HTTP (Hypertext Transfer Protocol) (W3C). Esses sistemas facilitam a interoperabilidade entre clientes e servidores fornecendo uma interface por meio da qual um programa cliente em uma organização pode interagir com um programa servidor em outra organização sem a necessidade de supervisão humana (COULOURIS, 2013). Em outras palavras, ao utilizar a tecnologia Web Service, uma aplicação pode invocar outra para realizar tarefas mesmo que as duas aplicações estejam em diferentes sistemas e escritas em linguagens diferentes, pois a linguagem é traduzida para uma linguagem universal em um formato padrão de transferência de dados como o XML (eXtended Markup Language) e JSON (JavaScript Object Notation).

A comunicação entre os sistemas clientes e os serviços é baseada no paradigma request/reply (requisição/resposta). Essa comunicação é exemplificada com um Diagrama de Sequência ilustrado na Figura 3:

(28)

Figura 3. Diagrama de Sequência da comunicação entre Cliente e Servidor Web.

O cliente faz uma requisição HTTP para o servidor solicitando um determinado recurso ou tarefa, em seguida o servidor envia uma resposta HTTP para o cliente com os dados solicitados em um formato padrão de transferência de arquivos (XML ou JSON).

2.6 REST

O REST (REpresentational State Transfer) é um estilo de desenvolvimento de Web Services baseado em recursos, sendo estes os conjuntos de dados que são trafegados pelo protocolo HTTP. O REST tem sido bastante utilizado por desenvolvedores devido a suas diversas vantagens como a garantia de que a troca de dados entre cliente e servidor seja feita sem acoplamento entre as partes, proporcionando mais flexibilidade nas comunicações.

O Cliente interage com os recursos através dos métodos HTTP GET, POST, PUT e DELETE, onde:

• GET: é utilizado quando existe a necessidade de se obter um recurso;

• POST: é utilizado para processamento de um recurso a partir do uso de uma representação;

• PUT: é utilizado como forma de atualizar ou inserir um determinado recurso; • DELETE: é utilizado para fazer a remoção de um determinado recurso.

Cada recurso é representado por uma URI (Uniform Resource Indentifier), onde toda URI deve especificar qual o dado que será manipulado e qual método HTTP será utilizado. Nas requisições as URIs são chamadas de substantivos enquanto os métodos HTTP são denominados de verbos, o que significa que os métodos HTTP são os responsáveis por

(29)

provocar alterações nos recursos identificados pelas URIs (Saudate, 2014). A Tabela 1 mostra exemplos dessas requisições.

Tabela 1. Exemplos de requisições utilizando os métodos HTTP.

URI Verbo HTTP Corpo do JSON Descrição

/siguan/insumo GET Vazio Retorna todos os insumos cadastrados.

/siguan/insumo POST JSON Insere um novo insumo.

/siguan/insumo/:id PUT JSON

Atualiza um

determinado insumo que possui o id especificado na URI.

/siguan/insumo/:id DELETE Vazio

Remove um

determinado insumo que possui o id especificado na URI. 2.7 VUE.JS

O Vue.js é um framework JavaScript progressivo e de código aberto que auxilia no desenvolvimento de interfaces de usuário. Sua diferença em relação a outros frameworks monolíticos se dá pelo fato do Vue ter sido projetado para ser adotado de forma incremental. A biblioteca principal concentra-se na renderização declarativa e composição de componentes podendo ser integrada a outras bibliotecas ou projetos existentes (Vue.js, 2014). Por outro lado, o projeto também inclui bibliotecas e ferramentas que dão suporte a criação de aplicações maiores de página única (Single Page Application - SPA).

O Vue usa uma sintaxe de template baseada em HTML que permite vincular de forma declarativa o DOM (Document Object Model) renderizado aos dados da instância Vue subjacente. Todos os templates do Vue são HTMLs que podem ser interpretados pelos navegadores. Uma outra característica do Vue é o sistema de reatividade discreta. Modelos são objetos JavaScript simples que quando são modificados a visão é atualizada, o que torna o gerenciamento de estado mais simples e intuitivo. O Vue fornece também uma nova renderização otimizada sem muita complexidade. Cada componente monitora suas

(30)

dependências reativas durante a renderização, portanto, o sistema sabe exatamente quando renderizar novamente e quais componentes serão renderizados.

Os componentes são importantes recursos do Vue. Quando se trata de uma aplicação maior, é importante dividir a aplicação em componentes menores, independentes e reutilizáveis para tornar o desenvolvimento gerenciável. Esses componentes estendem a elementos HTML básicos para encapsular o código reutilizável. A Figura 4 mostra um exemplo de componente Vue:

Figura 4. Exemplo de componente Vue.

FONTE: (Vue.js, 2014)

Este componente pode ser reutilizado conforme mostra a Figura 5:

Figura 5. Reutilização de componentes Vue.

FONTE: (Vue.js, 2014)

Um componente essencial de uma SPA é o Router que é responsável por mostrar/esconder um ou mais elementos dependendo da URL que é acessada no navegador. Bibliotecas JavaScript como o Vue fornecem uma interface fácil para alterar o que é exibido na página com base no caminho do URL atual independentemente de como foi alterado. O pacote vue-router fornece uma API para alterar a URL do navegador, usar botões de retorno (histórico de hash) e passar parâmetros pela URL de uma página para outra de forma simples.

(31)

3. DESENVOLVIMENTO

Este Capítulo descreve a fase de desenvolvimento do sistema proposto. Visando reduzir os riscos relacionados a possíveis imprevistos e incertezas do projeto, foi adotado o método ágil OpenUP (Balduino, 2007) que é fundamentado no Processo Unificado (Kruchten, 2003), bastante utilizado no desenvolvimento tradicional de softwares. O OpenUP é um método de desenvolvimento ágil e unificado que contém um conjunto mínimo de práticas que auxiliam no processo de desenvolvimento de software. Esse modelo foi escolhido por ser completo e propositalmente resumido, portanto não exige tecnologias específicas ou uma equipe grande de desenvolvedores, além de ser extensível, podendo ser utilizado como base para agregar novos processos. O OpenUP apresenta características importantes no planejamento e implementação de sistemas orientados a objetos, uma dessas características é a aplicação de abordagens iterativas e incrementais que seguem um ciclo de vida estruturado baseando-se em casos de uso e cenários a fim de manter a comunicação entre os stakeholders.

Seguindo as etapas proposta pelo método OpenUP, o processo de desenvolvimento do SIGUAN foi dividido em quatro fases que indicam os fluxos de trabalho que devem ser enfatizados em um dado instante, dentro de todo o ciclo de vida do projeto. As fases de desenvolvimento estão ilustradas a seguir na Figura 6:

Figura 6. Ciclo de vida do OpenUP.

FONTE: (Meira, 2010).

3.1 INICIAÇÃO

Na fase de Iniciação foi dado início ao planejamento do projeto priorizando o processo de análise de requisitos. Como mencionado no Capítulo 1, este projeto foi planejado com base no contexto do RU da EAJ. O levantamento de requisitos, bem como todas as etapas que envolveram a interação com o cliente, ocorreu com a colaboração de uma nutricionista funcionária do RU onde o sistema foi aplicado. Os requisitos são especificações

(32)

que definem os objetivos do sistema e como ele deve se comportar. Esta etapa é de grande importância para obter um maior entendimento do problema e identificar a melhor forma de solucioná-lo. Nessa fase foram executadas as principais etapas da Engenharia de Requisitos (Nuseibeh & Easterbrook, 2000) que levaram em consideração os elementos de solução de problemas, elaboração, negociação e especificação. Para a obtenção dos requisitos, foram elaboradas perguntas destinadas aos usuários do sistema para que a equipe de desenvolvimento pudesse adquirir um entendimento básico do problema. As perguntas foram respondidas durante reuniões periódicas com a especialista em Nutrição e tinham como objetivo esclarecer a respeito de como eram realizadas as atividades de gestão da UAN, o que o nutricionista esperava do sistema e como o sistema seria utilizado.

Após a obtenção das informações necessárias foram definidos os requisitos funcionais, que determinam as funcionalidades do sistema, e os requisitos não-funcionais, que podem ser descritos como atributos de qualidade, segurança, desempenho e/ou restrições. Os principais requisitos funcionais e não-funcionais estão apresentados na Tabela 2 e Tabela 3 respectivamente.

Tabela 2. Requisitos funcionais.

Código Descrição

RF001 Fazer login e autenticar usuário.

RF002 Cadastro, exclusão, atualização e consulta de

usuários.

insumos.

insumo per capita.

RF005 Cadastro, exclusão, atualização e consulta da

Análise Química de um insumo.

cortes.

salas de preparação

preparações.

(33)

embalagens.

itens no estoque.

RF012 Realizar seleção do cardápio que será aplicado a

uma semana.

prescrição.

RF014 Emitir relatórios de prescrição (Despensa e

preparações por sala).

Tabela 3. Requisitos não-funcionais.

Código Descrição

RNF001

Segurança. O sistema deverá ser usado apenas por usuários cadastrados e autorizados por processo de login. Todas as operações do sistema deverão validar se o usuário possui credenciais válidas para a operação requisitada.

RNF002 Segurança. O sistema deve guardar as senhas dos

usuários de forma criptografada.

RNF003 Portabilidade. O sistema deve ser acessado em

qualquer dispositivo conectado à internet.

RNF004 Usabilidade. O sistema deve oferecer uma

interface fácil de ser usada.

RNF005 Compatibilidade. O sistema deve ser compatível

com qualquer browser (Mozila, Chrome, Edge)

Após a definição dos requisitos, os mesmos foram validados pela nutricionista para garantir que estavam de acordo com esperado. Após a validação foi dado início à análise arquitetural do sistema (fase apresentada na Seção 3.2 ).

3.2 ELABORAÇÃO

Na fase de Elaboração foi enfatizado o processo de desenvolvimento da análise arquitetural do sistema, onde foi estabelecida uma arquitetura estável a partir da qual o sistema pôde evoluir. Por se tratar de um sistema de software complexo e com uma série de requisitos de qualidade, a arquitetura do sistema foi planejada com o intuito de detalhar os

(34)

componentes de software, suas propriedades e seus relacionamentos de modo a atender os requisitos dos usuários e facilitar o seu desenvolvimento e manutenção, bem como proporcionar um alto nível dos atributos de qualidade como confiabilidade, usabilidade, disponibilidade e segurança. Para realizar as especificações da arquitetura de software foi adotado o modelo arquitetural de Visões 4+1, apresentado na Seção 3.2.1.

3.2.1 VISÕES 4+1

O modelo arquitetural de Visões 4+1 foi criado por Kruntchen (1995) e propõe organizar a especificação da arquitetura de software em torno de quatro visões concorrentes e fazer uma ilustração a partir de alguns casos de uso selecionados ou cenários que se tornam uma quinta visão (Figura 7).

Figura 7. Modelo arquitetural de visões 4+1.

3.2.2 VISÃO DE CASOS DE USO

Esta visão ilustra as funcionalidades do sistema a partir de um conjunto de casos de uso especificados conforme a necessidade dos stakeholders do projeto. Os cenários são uma abstração dos requisitos mais importantes. Nessa visão, esses cenários são usados para identificar elementos arquitetônicos e ilustrar e validar o projeto de arquitetura. Esta visão é chamada de ‘+1’, pois ela serve para descobrir os elementos arquitetônicos durante o projeto da arquitetura e como uma função de validação e ilustração após a conclusão do projeto. A Figura 8 apresenta o diagrama de casos de uso que ilustra as principais funcionalidades oferecidas pelo sistema e o modo como os atores interagem com as mesmas.

(35)

Figura 8. Diagrama de Casos de Uso.

FONTE: adaptada do projeto SIGRU.

O sistema desenvolvido contempla quatro atores, que são:

1. Nutricionista: usuário que possui o maior nível de permissão no sistema. É responsável por realizar as principais funcionalidades, como o gerenciamento de todos os registros cadastrados, elaboração de cardápios e preparações, emissão de relatórios e controle dos demais usuários;

2. Estagiário de Nutrição: possui autorização para realizar parte das funcionalidades do sistema, como o gerenciamento de parte dos registros cadastrados e emissão de relatórios. O ator Estagiário de Nutrição não possui autorização para gerenciar os demais usuários do sistema.

3. Almoxarife: responsável por realizar o controle de entrada e saída de itens do estoque;

4. Usuário Externo: utiliza o sistema para visualizar os cardápios semanais. O detalhamento dos casos de uso está disponível na seção de Apêndice A.

(36)

3.2.3 VISÃO LÓGICA

A Visão Lógica abrange principalmente os requisitos funcionais, os quais serão disponibilizados ao usuário final em termos de serviços. Esta visão foi representada neste projeto através do diagrama de classes, responsável por descrever o conjunto de classes e seus relacionamentos lógicos, especificando suas associações, composições, heranças e assim por diante. A Figura 9 mostra o diagrama de classes simplificado com a representação das principais classes do sistema e seus respectivos atributos e relacionamentos. A versão completa do diagrama pode ser encontrada no Apêndice B.

Figura 9. Versão simplificada do Diagrama de Classes do SIGUAN.

FONTE: adaptação do projeto SIGRU

A Tabela 4 apresenta as descrições das classes especificando o que cada uma representa.

(37)

Tabela 4. Descrição do Diagrama de Classes.

Classe Descrição

Usuario

Classe que representa o usuário que irá utilizar o sistema. Possui atributos que indicam os dados do usuário como nome e tipo.

Login Classe que representa o login e possui atributos que

indicam os dados para a autenticação do usuário.

Insumo

Classe que representa o item do ingrediente. Possui atributos que indicam informações como nome, tipo e unidade base.

InsumoPerCapita

Classe que representa o ingrediente necessário para apenas uma pessoa. Possui atributos que indicam o nome, peso bruto, peso limpo e tipo de corte aplicado.

TipoCorte

Classe que representa o tipo de corte que deve ser aplicado ao insumo per capita. Possui atributos que indicam o nome e a descrição do corte.

ItemEstoque

Classe que representa o insumo disponível no estoque. Possui atributos que indicam o nome do item, quantidade, unidade, entrada (operação de entrada ou saída), responsável e data da operação.

Unidade

Classe que representa a embalagem do insumo. Possui atributos que indicam o nome (Ex.: caixa, pacote, etc.), a unidade base (Ex.: grama, litro, etc.) e o multiplicador.

Preparacao

Classe que representa a receita que será preparada em cada refeição. Possui atributos que indicam nome, ingredientes, modo de preparo, local de preparo, técnica de cocção, etc.

SalaDePreparo

Classe que representa o local onde as preparações são produzidas. Possui atributos que indicam o nome, descrição e número de funcionários.

MenuAplicado

Classe que representa um menu aplicado a um dia da semana. Possui atributos que indicam a data, as refeições e a previsão de comensais (usuários da UAN).

CardapioAplicado Classe que representa um cardápio semanal _{contendo um conjunto de menus diários. Possui}

(38)

responsável.

Prescricao

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.

3.2.4 VISÃO DE IMPLEMENTAÇÃO

A visão de implementação ilustra o sistema do ponto de vista do desenvolvedor a respeito de como o sistema será implementado. Visando atingir os objetivos do trabalho, a arquitetura da aplicação desenvolvida foi planejada com base no estilo arquitetural em camadas. A arquitetura em camadas proporciona maior facilidade de compreensão, pois utiliza níveis crescentes de abstração particionando problemas complexos em passos sequenciais e incrementais, além de tornar o sistema mais flexível, o que facilita a manutenção (LARMAN, 2004). As camadas foram organizadas de forma hierárquica de modo que cada camada oferece o serviço para a camada superior e faz uso do serviço oferecido pela camada inferior. A arquitetura proposta para o desenvolvimento do SIGUAN está representada na Figura 10.

(39)

Figura 10. Arquitetura do sistema.

A arquitetura está representada em cinco camadas. A camada de Mapeamento Objeto-Relacional é responsável pela Persistência dos dados no Banco de Dados MySQL. O modelo dos dados que serão persistidos é determinado pela camada Modelo, que representa a especificação das regras de negócios e as estruturas dos dados que serão armazenados na base de dados.

A camada de Serviços RESTful compreende os Serviços Web baseados em REST que serão utilizados pelo frontend para se comunicar com o backend e realizar a troca de recursos utilizando os métodos HTTP. O frontend faz uma requisição e o backend retorna a resposta com o recurso solicitado. Os recursos trafegam em um formato de transferência de dados específico, no caso do SIGUAN, o formato adotado foi o JSON, pois é um formato leve e de fácil interpretação.

A camada do Frontend Vue.js é uma aplicação web que serve de interface para que o usuário possa interagir com as funcionalidades do sistema.

(40)

3.2.5 VISÃO DE IMPLANTAÇÃO

Esta visão demonstra o ambiente de execução do sistema e foca nos aspectos da topologia e organização de componentes de software na camada física, além das conexões físicas entre esses componentes. Nesta fase foram levados em consideração principalmente os requisitos não funcionais do sistema, como disponibilidade, escalabilidade, confiabilidade e desempenho a fim de identificar a melhor forma possível para mapear os artefatos de software ao hardware responsável por hospedar esses artefatos. A arquitetura de implantação deste projeto foi representada pelo diagrama de implantação representado na Figura 11.

Figura 11. Diagrama de implantação.

Como é possível observar na Figura 11, os componentes desse sistema foram organizados da seguinte forma: O Cliente representa a interface gráfica do sistema (frontend) que faz referência ao browser que se encarrega de fazer a comunicação com o servidor através do protocolo HTTP e utiliza os métodos que permitem o acesso às funcionalidades do sistema. O Servidor armazena as regras de negócio que definem como os dados serão acessados e processados. Este componente é responsável por fazer a comunicação entre o banco de dados e o cliente. Por fim, o Banco de Dados que faz referência a todos os registros existentes. A comunicação do servidor com o banco de dados é realizada através do JDBC (Java Database Connectivity) que se trata de uma API que possui um conjunto de rotinas e padrões em Java que fazem o envio de instruções SQL para o banco de dados relacional.

(41)

3.2.6 VISÃO DE PROCESSOS

A visão de processos aborda os aspectos dinâmicos do sistema e demonstra toda a comunicação entre seus processos. Nesta etapa foram descritos como as principais abstrações da visão lógica se enquadram na visão de processos. Alguns requisitos não-funcionais foram levados em consideração para o planejamento desta visão, como desempenho, disponibilidade, integridade e tolerância a erros. Para representar a arquitetura de processos do sistema desenvolvido, foram elaborados diagramas de atividades responsáveis por descrever o fluxo de atividades dos processos. A Figura 12 apresenta o diagrama de atividades que descreve as etapas para a criação de um cardápio no sistema. Primeiramente o usuário deve inserir um nome para o cardápio, em seguida criar os menus e fazer uma busca nas preparações cadastradas e selecionar as que deseja incluir em cada menu.

Figura 12. Diagrama de atividades da criação de cardápio.

A Figura 13 apresenta o diagrama de atividades da criação de uma prescrição. Primeiramente o usuário deve inserir a data da prescrição, em seguida fazer uma busca pelos

(42)

cardápios aplicados cadastrados no sistema e selecionar o cardápio desejado. Após selecionado o cardápio aplicado, o usuário deve escolher os menus que deseja prescrever. Ao salvar a prescrição, o sistema realiza o cálculo da quantidade dos insumos que serão necessários para as preparações dos menus selecionados na prescrição e faz a retirada dos itens do estoque de forma automática.

Figura 13. Diagrama de atividades da criação de prescrição.

3.3 CONSTRUÇÃO

Na fase de Construção foi dado início ao processo de implementação do sistema com base na arquitetura apresentada na seção anterior. A equipe de desenvolvimento é composta por 6 programadores e 1 gerente de projeto responsável por coordenar a equipe, mas tendo em vista o foco desta Monografia, nesta seção serão apresentadas com mais ênfase as implementações realizadas pela autora do trabalho.

O processo de construção foi realizado de forma iterativa e incremental, os requisitos foram transformados em componentes executáveis para que, ao final de cada iteração, houvesse um produto executável que pudesse ser testado pelo usuário e assim obter um feedback contínuo e achar possíveis erros ou má interpretação dos requisitos.

A camada de Mapeamento Objeto-Relacional foi implementada utilizando o framework Hibernate para mapear as classes Java em tabelas do banco de dados relacional. Além de realizar o mapeamento objeto relacional, a ferramenta também disponibiliza

(43)

mecanismos de consulta de dados, o que permite uma redução considerável no tempo de desenvolvimento da aplicação. Para realizar a persistência dos dados, o Hibernate faz uso da API JDBC para fazer o envio de instruções SQL para o banco de dados.

Para ter acesso a maioria das funcionalidades do SIGUAN é necessário realizar a autenticação no sistema para garantir a segurança dos dados. O único recurso que não necessita de autenticação para ser acessado é o do cardápio semanal, pois este recurso foi disponibilizado para que o público externo pudesse visualizar o cardápio da semana. Os demais recursos só podem ser acessados por usuários autenticados. Além das funcionalidades de gerenciamento de recursos, o SIGUAN também dispõe de um serviço responsável por realizar essa autenticação de forma segura. Para isso, o cliente (frontend) envia um JSON contendo os dados de autenticação do usuário (login e senha) através de uma requisição HTTP POST. A Figura 14 apresenta um exemplo de solicitação de login.

Figura 14. Exemplo de requisição de login.

O backend verifica se os dados de login estão corretos e manda uma resposta HTTP passando no corpo do JSON os dados do usuário autenticado e um token no cabeçalho. O token é uma chave única utilizada como um identificador do usuário que está autenticado. Esta chave é verificada sempre que o cliente faz uma solicitação a um serviço. O token deve ser passado no cabeçalho do JSON seguindo o padrão “Authorization: bearer token” como mostra a Figura 15.

(44)

A Figura 16 apresenta um exemplo de solicitação do recurso insumo de id=1 utilizando o método HTTP GET. A resposta enviada pelo servidor é um objeto JSON contendo os dados do insumo solicitado.

Figura 16. Exemplo de solicitação de um insumo utilizando o método HTTP GET.

Além da solicitação de recursos, o SIGUAN também oferece serviços contendo métodos para inserir registros no banco de dados. Nesse caso, o cliente (frontend) faz uma requisição HTTP POST enviando um objeto JSON que contém os dados do recurso que deseja inserir. A resposta enviada pelo servidor é um objeto JSON contendo o id do insumo cadastrado. A Figura 17 mostra um exemplo de cadastro de um insumo.

(45)

Figura 17. Exemplo de cadastro de insumo utilizando o método HTTP POST.

Outra funcionalidade oferecida é a opção de edição de registros. Para isso, o cliente faz uma requisição HTTP PUT enviando um objeto JSON que contém os dados do recurso que deseja alterar. Também é necessário especificar o id do recurso na URI. O servidor envia uma resposta contendo o objeto JSON com os dados do recurso que foi alterado. A Figura 18 mostra um exemplo de edição de cadastro de insumo que possui id=234.

Figura 18. Exemplo de alteração dos dados de um insumo utilizando o método HTTP PUT.

(46)

O SIGUAN também oferece serviços com métodos para remover registros do banco de dados. Para isso, o cliente faz uma requisição HTTP DELETE especificando na URI o id do recurso que deseja remover, por exemplo, na Figura 19 o id é 234. O servidor apresenta como resposta o conteúdo vazio e o status 204 No Content.

Figura 19. Exemplo se remoção de insumo utilizando o método HTTP DELETE.

Uma das principais funcionalidades implementadas foi o serviço de prescrição de cardápios. Este serviço é responsável por calcular a quantidade de insumos necessária para as preparações de um cardápio levando em consideração a lista de ingredientes de cada preparação e o número de comensais previsto para cada refeição. Para prescrever um cardápio é necessário que o cliente envie um objeto JSON contendo as informações das previsões de comensais e o cardápio que deseja prescrever composto das preparações que contém as listas de ingredientes. Ao receber o objeto de Prescrição, o serviço se encarrega de realizar o cálculo dos insumos necessários e preenche as listas de itens para cada refeição informando suas respectivas quantidades. A Figura 20 mostra um exemplo da criação de uma prescrição utilizando o método HTTP POST.

(47)

Figura 20. Exemplo de prescrição de um cardápio.

A camada Frontend Vue JS representa uma aplicação web desenvolvida com o framework Vue JS que serve como uma interface para o usuário. Essa aplicação representa o cliente que irá consumir os serviços e manipular os recursos. A interface foi construída com base em componentes independentes e reutilizáveis a fim de simplificar o desenvolvimento e torna-lo gerenciável. Também foi utilizado o template AdminLTE1_{do Boostrap. O Vue JS} usa uma sintaxe de templates baseada em HTML que são interpretados pelo navegador e os componentes da aplicação são exibidos para o usuário. A Figura 21 mostra o trecho de código do template da tela de login do SIGUAN utilizando o framework Vue JS.

Figura 21. Template da tela de login do SIGUAN.

(48)

A Figura 22 apresenta os componentes da tela de login que são apresentados para o usuário.

Figura 22. Tela de login do SIGUAN.

FONTE: Própria da autora.

O painel de controle, apresentado na Figura 23, possui uma área de trabalho onde é exibido o conteúdo do sistema e uma barra lateral com o menu de opções de trabalho disponíveis que são as seguintes:

1. Insumos: Usada sempre que há a necessidade de cadastrar, alterar ou excluir insumos, insumos per capita ou um tipo de corte no sistema. Para cadastrar um per capita é necessário o cadastro do insumo associado ao per capita. Uma vez definido, um per capita pode ser usado sempre que necessário.

2. Preparação: Usada quando há a necessidade de cadastrar, alterar ou excluir uma preparação ou uma sala de preparação. Para o cadastro de uma preparação é necessário definir os per capitas que serão usados.

3. Cardápios: Usada quando há a necessidade de cadastrar, alterar ou excluir um cardápio. Para o cadastro de um cardápio é necessário cadastrar previamente as preparações que serão utilizadas.

4. Estoque: Usada quando há a necessidade de cadastrar, alterar ou excluir itens no estoque ou embalagens nas quais um insumo pode vir a dar entrada no estoque.

(49)

5. Prescrições: Usada quando há necessidade de prescrever menus.

6. Usuários: Usada quando há a necessidade de cadastrar, alterar ou excluir usuários do sistema.

7. Exibição de cardápios: No centro da tela é exibido o cardápio da semana contendo os menus diários e suas respectivas preparações.

Figura 23. Painel de controle do SIGUAN.

A tela de cadastro de insumo per capita, apresentada na Figura 24, possui um formulário onde o usuário deve inserir os seguintes dados: 1- ingrediente (que é o insumo que já deve ter sido cadastrado anteriormente); 2- observações; 3- especificar se o per capita é condimento ou não; 4- selecionar o tipo de corte (que já deve ter sido cadastrado anteriormente); 5- informar o peso limpo, peso bruto e o fator de correção do insumo per capita.

(50)

Figura 24. Tela de cadastro de insumo per capita.

Na tela de cadastro de preparação (Figura 25) o usuário insere as informações das receitas que serão servidas na UAN. Uma vez cadastrada, a preparação pode ser reutilizada posteriormente sempre que for necessário, sem a necessidade de inserir as mesmas informações novamente, o mesmo serve para os insumos e cardápios. Os dados requeridos para o cadastro das preparações são: 1- nome, 2- ingredientes (que são os insumos per capitas que já devem ter sido cadastrados anteriormente), 3- cor predominante da preparação, 4- textura, 5- grupo de alimentos ao qual a preparação pertence, 6- aspecto gorduroso, 7- técnica de cocção, 8- nível de enxofre, 9- sala de preparo onde a preparação deve ser produzida, 10- nível de sódio da preparação, 11- informar se a preparação é vegetariana e, por fim, 12- informar como a preparação deve ser preparada.