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.

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}

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.

Figura 10. Arquitetura do sistema.

FONTE: própria da autora.

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.

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.

FONTE: própria da autora.

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.

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.

FONTE: própria da autora.

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

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.

FONTE: própria da autora.

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

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.

FONTE: própria da autora.

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.

FONTE: própria da autora.

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.

FONTE: própria da autora.

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.

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

FONTE: própria da autora.

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.

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.

FONTE: própria da autora.

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.

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

FONTE: própria da autora.

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.

FONTE: própria da autora.

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.

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.

FONTE: própria da autora.

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.

Figura 24. Tela de cadastro de insumo per capita.

FONTE: própria da autora.

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.

FONTE: própria da autora.

Na tela de planejamento e criação de cardápios (Figura 26) os dados requeridos para o cadastro do cardápio são: 1- nome e 2- dados dos menus diários. Cada menu diário deve possuir um nome e as preparações para cada refeição. Não é obrigatório o preenchimento de todas as refeições.

Figura 26. Tela de criação de cardápio.

FONTE: própria autora.

Os dados requeridos para o cadastro de prescrição são: 1- data, 2- cardápio aplicado (que é o cardápio semanal com menus aplicados a uma data específica), 3- seleção dos menus que deseja prescrever e informação a respeito da previsão de comensais para cada refeição. A Figura 27 apresenta a tela de cadastro da prescrição de um cardápio.

Figura 27. Tela de prescrição de cardápio.

FONTE: própria autora.

A partir da prescrição o usuário poderá gerar os relatórios de cada sala de preparação, que são: 1- Sala de Vegetais: que contém todos os insumos que são vegetais, 2- Sala de Carnes: composto pelos insumos que são carnes e 3- Cozinha: que contém os demais insumos. Além de gerar o relatório de Requisição Diária que contém todos os insumos que serão retirados da despensa pelo almoxarife. A Figura 28 apresenta um exemplo de relatório da cozinha.

FONTE: própria autora.

3.4 TRANSIÇÃO

A fase de Transição enfatizou o processo de implantação do sistema com foco na realização de testes para verificar se o sistema consegue suprir as necessidades dos usuários. Esta etapa compreendeu a configuração do ambiente de produção e o treinamento dos usuários do sistema. A princípio o sistema foi disponibilizado online para que a nutricionista integrante do projeto pudesse utiliza-lo e retornar informações sobre erros, ajustes e sugestões. O próximo passo do projeto nesta fase é disponibilizar o SIGUAN para ser utilizado no ambiente do RU pelos demais funcionários e continuar a fase de testes nesse ambiente.

4. AVALIAÇÃO

Este Capítulo descreve o processo de avaliação do SIGUAN realizado através da execução de um experimento controlado baseado no método proposto por Jedlitschka at al. (2008). O experimento teve como objetivo investigar se as funcionalidades do sistema desenvolvido atingem os objetivos deste trabalho (especificados no Capítulo 1) e avaliar o nível de complexidade, utilidade e produtividade do sistema em comparação com um método tradicional de planejamento e prescrição de cardápios em UANs.

4.1 OBJETIVOS DA AVALIAÇÃO

Os objetivos da avaliação partiram dos objetivos estabelecidos para esta Monografia e foram definidos com base na metodologia Goal, Question, Metric (GQM) proposta por Basili at al. (1992). O paradigma GQM é uma abordagem orientada a objetivos bastante utilizada em engenharia de software para a avaliar produtos e processos de software. Essa abordagem parte do princípio de que toda a coleta dos dados deve ser baseada num fundamento lógico, em um objetivo que é documentado de forma explícita (FONTOURA et al., 2004). O primeiro passo seguindo o método GQM é definir os objetivos que serão alcançados no processo de avaliação.

Como especificado no Capítulo 1, os objetivos deste trabalho são: (i) 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; (ii) Implementação de serviços para manipulação dos dados; (iii) Construção do Módulo de Elaboração e Prescrição de Cardápios; (iv) Construção do Módulo de Geração de Relatórios; (v) Construção do Módulo de Interface Web de fácil utilização. Estes objetivos foram aperfeiçoados para dar origem ao objetivo (Goals) do experimento controlado:

Objetivo 1 (G1): Analisar o SIGUAN no processo de planejamento e prescrição de cardápios com o propósito de avaliar sua eficácia com relação à usabilidade percebida, utilidade percebida e produtividade no contexto da UAN.

A partir do objetivo da avaliação foram elaboradas questões (Questions) que refinam o objetivo de forma quantitativa. As questões estão especificadas a seguir na Seção 4.2.

4.2 QUESTÕES

Um conjunto de questões foi elaborado a partir do objetivo a fim de especificar as