UNIDADE ACADÊMICA ESPECIALIZADA EM CIÊNCIAS AGRÁRIAS – ESCOLA AGRÍCOLA DE JUNDIAÍ
CURSO SUPERIOR DE TECNOLOGIA EM ANÁLISE E DESENVOLVIMENTO DE SISTEMAS
PEDRO HENRIQUE DO NASCIMENTO FERNANDES
SISTEMA PARA GERENCIAMENTO E CONTROLE DE ANÁLISES DE LEITE
Macaíba, RN 2019
SISTEMA PARA GERENCIAMENTO E CONTROLE DE ANÁLISES DE LEITE
Trabalho de conclusão de curso de graduação apresentado à Unidade Acadêmica Especializada em Ciências Agrárias da Universidade Federal do Rio Grande do Norte como requisito parcial para a obtenção do título de Tecnólogo em Análise e Desenvolvimento de Sistemas.
Orientador: Prof. Dr. Taniro Chacon Rodrigues.
Macaíba 2019
SISTEMA PARA GERENCIAMENTO E CONTROLE DE ANÁLISES DE LEITE
Trabalho de conclusão de curso de graduação apresentado à Unidade Acadêmica Especializada em Ciências Agrárias da Universidade Federal do Rio Grande do Norte como requisito parcial para a obtenção do título de Tecnólogo em Análise e Desenvolvimento de Sistemas.
Aprovado em 29 de novembro de 2019.
BANCA EXAMINADORA
__________________________________________ Prof. Dr. Taniro Chacon Rodrigues – EAJ/UFRN - Orientador
__________________________________________ Prof. Dr. Eduardo Alexandre Ferreira Silva – EAJ/UFRN
__________________________________________ Prof. Dr. Adriano Henrique do Nascimento Rangel – EAJ/UFRN
A tecnologia da informação tem proporcionado às organizações a melhoria da qualidade dos serviços através do acesso a dados e na segurança das informações da organização. O setor brasileiro de lácteos têm passado por diversas alterações desde a década de 1990, provocando aumento entre a competitividade entre empresas captadoras fazendo com que induzam os produtores a buscar profissionalização na produção do leite, com isso melhorando a qualidade de leite e adquirindo boas práticas agropecuárias dentro da fazenda, uma das melhorias notadas é que muitos produtos têm implementado sistemas de gestão viabilizando o gerenciamento da produção e da produtividade leiteira. Tendo em vista essa problemática, o objetivo deste Trabalho de Conclusão de Curso é apresentar o desenvolvimento de sistema de informação como objetivo realizar o cadastro de clientes e de solicitações de análises de leite. Dentre os seus requisitos esse sistema deve ser capaz de gerenciar a criação e a emissão do laudo da solicitação além de gerar os QRCodes para as amostras de leite visando melhorar a organização do Laboratório de Qualidade do Leite (Laboleite). A avaliação deste trabalho foi realizada através da utilização de uma ferramenta chamada Attrakdiff, que avaliou a qualidade pragmática, hedônica e a atratividade da aplicação.
Information technology has enabled organizations to improve the quality of services through data access and security of information. The Brazilian dairy sector has undergone several changes since the 1990s, leading to increased competitiveness among capturing companies, leading producers to seek professionalization in milk production, improving milk quality and acquiring good agricultural practices. Within the farm, one of the notable improvements is that many products have implemented management systems that make it possible to manage dairy production and productivity. Faced with this problem, the purpose of this Course Completion Document is to present the development of an information system with the purpose of performing the customer registration and milk analysis requests. Among its requirements, this system should be able to manage the creation and issuance of the request report and generate QRCodes for milk samples in order to improve the organization of the Milk Quality Lab (Laboleite). This work was evaluated using a tool called Attrakdiff, which evaluated the pragmatic, hedonic and attractive quality of the application.
Figura 1: Fluxograma do Laboleite...11
Figura 2: Ciclo de vida do OpenUp...17
Figura 3: Diagrama de caso de uso...18
Figura 4: Modelo arquitetural de visões 4+1...21
Figura 5: Versão simplificada do diagrama de classe do projeto desenvolvido em projeto aplicados II...22
Figura 6: Arquitetura do Sistema...24
Figura 7: Ilustração da visão física do sistema...25
Figura 8: Diagrama de Atividades representando a criação de uma solicitação...27
Figura 9: Diagrama de atividades que descreve o cadastro e a emissão do laudo.. 28
Figura 10: Imagem do software Jaspersoft iReport Design 5.6.0...30
Figura 11: Tela de login do Laboleite...30
Figura 12: Tela inicial do sistema...32
Figura 13: Tela do cadastro do laudo...33
Figura 14: Tela de listar dos laudos...33
Figura 15: Tela de edição do laudo...34
Figura 16: Tela dos detalhes da solicitação exibindo dados do cliente...34
Figura 17: Tela de detalhes da solicitação exibindo dados da análise...35
Figura 18: Imagem dos QRCodes gerados para impressão...36
Figura 19: Tela de detalhes da solicitação...37
Figura 22: Tela de listar o laudo da solicitação...39
Figura 23: Tela de gráfico dos laudos da solicitação...39
Figura 24: Tela de gráfico da média dos laudos da solicitação...40
Figura 25: Tela de Atendimento da solicitação...41
Figura 26: Tela do laudo PDF gerado 1...42
Figura 27: Tela do laudo PDF gerado 2...43
Figura 28: Tela do laudo PDF gerado 3...44
Figura 29: Tela do laudo XLS gerado...45
Figura 30: Tela do aplicativo mobile...46
Figura 31: Tela do login do aplicativo...46
Figura 32: Tela de solicitações do cliente...47
Figura 33: Tela da análise...47
Figura 34: Tela de pop-up da solicitação...48
Figura 35: Tela de detalhamento da análise...48
Figura 36: Tela do comprovante...49
Figura 37: Tela da lista de amostras recebidas no laboratório...49
Figura 38 Tela da situação das amostras...50
Figura 39: Tela de coleta das amostras...50
Figura 40: Tela da verificação da amostra coletada...51
Figura 41: Tela da amostra coletada...51
Figura 42: Tela dos detalhes da amostra coleta...52
Figura 45: Tela de consulta do QRCode do laboratório (A)...54
Figura 46: Tela de consulta do QRCode do laboratório (B)...54
Figura 47: Tela de consulta do QRCode do laboratório (C)...55
Figura 48: Portifólio dos resultados...56
Figura 49: Diagrama dos valores médios...57
Figura 50: Descrição dos pares de palavras...59
Figura 51: Diagrama de caso de uso completo...66
EAJ – Escola Agrícola de jundiaí
UFRN – Universidade Federal do Rio Grande do Norte LABOLEITE – Laboratório de Qualidade do Leite
1 INTRODUÇÃO...9 1.1 objetivos...12 1.1.1 Objetivo geral... 12 1.1.2 Objetivos específicos... 12 1.2 justificativa...12 2 REFERENCIAL TEÓRICO...13
2.1 ARQUITETURA ORIENTADA A SERVIÇOS (SOA)...13
2.2 SERVIÇO WEB...13 2.3 REST... 13 2.4 PROCESSO UNIFICADO...14 3 MATERIAIS E MÉTODOS...16 3.1 INICIAÇÃO...16 3.2 ELABORAÇÃO...19 3.2.1 VISÕES 4+1... 19
3.2.2 VISUALIZAÇÃO DE CASO DE USO...20
3.2.3 VISÃO LÓGICA... 21 3.2.4 VISÃO DE DESENVOLVIMENTO...23 3.2.5 VISÃO DE FÍSICA... 25 3.2.6 VISÃO DE PROCESSOS... 26 3.3 CONSTRUÇÃO...27 3.3.1 APLICAÇÃO WEB... 29 3.3.2 APLICAÇÃO MOBILE...44 3.4 TRANSIÇÃO...53 4 RESULTADOS...55 5 CONCLUSÃO...60 REFERÊNCIAS...62
1 INTRODUÇÃO
A tecnologia de informação trata do processamento de informação e comunicação integrada através de equipamento eletrônico (RODRIGRUES, 1998). Atualmente a tecnologia da informação vem adquirindo cada vez mais relevância na vida das pessoas e empresas, provocando uma transformação no trabalho que passou de manual para eletrônico, possibilitando para a indústria e outros setores a modernização de diferentes processos. Toda empresa necessita ser informatizada para se manter atualizada mercado. Além disso, as empresas devem acompanhar a evolução da tecnologia objetivando o aumento da produtividade, a melhoria na qualidade dos serviços, a facilidade de acesso às informações da empresa, maior segurança das informações e maior estímulo para os profissionais da área.
A produção leiteira no Brasil deixou de ser realizada, em grande parte, para subsistência, e passou a ser utilizada como fonte de renda a partir da década de 1950, momento em que estava ocorrendo o início do processo de industrialização do País. Nas quatro décadas seguintes, até 1990, o comércio de leite cru foi regulamentado pelas agências governamentais e os preços praticados eram os mesmos em todas as regiões do Brasil (BORTOLETO e WILKINSON, 2000).
Desde a década de 1990, o setor brasileiro de lácteos têm passado por diversas alterações e isso se deve principalmente pela desregulamentação do mercado e também no final da intervenção estatal, em 1972 registrou-se a maior competitividade entre empresas captadoras induzindo os produtores a buscar profissionalização na produção do leite (TESSARO, TORRES e BULHÕES, 2008). Outro aspecto no processo de diversificação dos produtos derivados de leite foi a demanda das multinacionais que já atuavam no mercado, resultando em um necessário aumento na produção, já que as empresas necessitavam de mais matéria prima à produção dos derivados. Com isso, os produtores começaram a ofertar mais leite in natura (MENDES, PEREIRA e TEIXEIRA, 2011). Por meio deste ambiente favorável, cada região do Brasil desenvolveu a atividade leiteira de forma diferente, umas com mais intensidade tecnológica e outras como sendo apenas uma atividade para subsistência (GOMES, 1995). Apesar do grande volume de leite produzido, a qualidade do leite cru ainda é uma das maiores dificuldades ao desenvolvimento tecnológico e à estabilização da indústria de laticínios no Brasil, sendo diretamente prejudicada pela alta contaminação microbiológica interferindo à
qualidade de leite pasteurizado e destinado à produção de derivados (Dumalisile et al. 2005, Nero et al. 2005, Mattos et al. 2010).
A baixa qualidade do leite pode ser atribuída a deficiências no manejo, à higiene na ordenha, à sanidade da glândula mamária, dentre outras (Nero et al., 2005). Por isso, cuidados higiênicos para evitar a contaminação do leite devem ter início na ordenha e seguir até o seu beneficiamento (Santana et al., 2001). Isso pode ser obtido por meio das boas práticas agropecuárias (BPA), que constituem um conjunto de atividades desenvolvidas dentro da fazenda com objetivo de garantir a saúde, o bem-estar e a segurança dos animais, do homem e do ambiente (Embrapa, 2005).
Atualmente existe na Universidade Federal do Rio Grande do Norte (UFRN) o Laboratório de Qualidade de Leite (Laboleite) da Escola Agrícola de Jundiaí (EAJ). No Laboratório de Qualidade do leite o controle dos resultados das análises de leite é registrado através de planilhas eletrônicas geradas automaticamente, pelo DairySpec FT® (Bentley Instruments Inc., Chaska MN, EUA) que é um equipamento que realizar análises automatizadas de leite. Quando os dados de análises não são suportados pelo DairySpec FT as planilhas são modificadas manualmente a partir das análises realizadas. Por fim, é emitido um laudo que sumariza resultado da solicitação do cliente. Tal laudo é feito a partir de um documento modelo que também é preenchido manualmente. Na Figura 1 apresentada a seguir mostra o fluxograma o atual funcionamento do Laboleite.
FONTE: Laboratório de Qualidade do Leite.
Todo o processo é iniciado quando o cliente realiza um cadastro de solicitação de análises. A seguir, é realizada a análise de viabilidade da solicitação realizada pela equipe do laboratório. Se for possível atender à solicitação o laboratório envia o material de coleta (frascos onde as amostras de leite devem ser armazenadas) e o cliente coleta as amostras e realiza o acondicionamento para ser enviada para o Laboleite. O processamento dessas amostras é registrado criando uma ordem de serviço indicando o mês, o número da análise e o ano (Ex: OS 11/1/2019). Tais informações constarão no laudo que será emitido com base em um documento modelo existente. Atualmente, esse é um serviço pago. Dessa forma, um boleto é emitido pela FUNPEC para que o cliente possa realizar o pagamento e posterior envio do comprovante para o laboratório. Ao final desse fluxo, o cliente recebe o laudo contendo as informações da análise solicitada.
Atualmente o uso de sistemas de informação para gerenciar fazendas leiteiras já é uma realidade. A Embrapa lançou em 2012 o aplicativo também disponibilizado em ambiente web chamado Gisleite que é uma solução tecnológica de informação gerencial desenvolvido em parceria com outras instituições para gestão zootécnica e econômica de unidades de produção de leite. O objetivo do Gisleite é orientar a tomada de decisão dos gerentes componentes da cadeia produtiva do leite, mediante análise de relatórios que apresentam indicadores de desempenho
produtivo e reprodutivo dos animais, indicadores de produtividade dos rebanhos e eficiência econômica da atividade. Outra ferramenta é o aplicativo OnFarmApp desenvolvido pela OnFarm no desafio de startups da Embrapa para soluções tecnológicas para a pecuária de leite de 2018, que gerencia o processo de coleta, incubação e leitura dos testes de cultura na fazenda (SmartGRAM e SmartColor). Permite também ao usuário gerar relatórios com indicadores gerenciais relacionados a incidência de mastite e com isso oferecer uma solução simples e inovadora que permite a identificação da causa da mastite na própria fazenda sendo benéfico no uso racional de antibióticos, menor descarte de leite na mastite clínica, maior assertividade nos tratamentos, maior rapidez para ações de prevenção e na avaliação na eficiência do manejo.
Esse trabalho foi iniciado a partir de um projeto feito na disciplina de Projetos Aplicados II, no qual foi desenvolvido um sistema que tinha como objetivo realizar o cadastro de clientes e de solicitações de análises de leite. Ficaram de fora do escopo, à época, as seguintes funcionalidades: Cadastro e emissão do laudo e a geração dos QRCodes que são fundamentais para concluir todo o fluxo de uma solicitação de análise dentro do laboratório.
1.1 OBJETIVOS
A seguir são apresentados os objetivos gerais e específicos deste trabalho.
1.1.1 Objetivo geral
O objetivo deste trabalho é desenvolver um sistema de informação para o Laboratório de Qualidade do Leite (Laboleite) da EAJ-UFRN capaz de realizar o cadastro e a organização dos laudos de análises de qualidade de leite que conterão os dados em relação aos resultados das análises de amostras de leite, podendo também ser representado graficamente.
1.1.2 Objetivos específicos
Como objetivos específicos espera-se automatizar o processo de análise de leite e coleta através da modernização do processo com o auxílio das interfaces web
e mobile para que possa garantir mais agilidade e eficiência nas atividades do Laboleite.
1.2 JUSTIFICATIVA
Este projeto tem como importância o desenvolvimento de software que suprirá uma das necessidades do laboratório de qualidade do leite com um sistema de informação para gerenciamento das atividades cotidianas do laboratório e otimizar o processo de comunicação com o cliente.
2 REFERENCIAL TEÓRICO
2.1 ARQUITETURA ORIENTADA A SERVIÇOS (SOA)
A Arquitetura Orientada a Serviços (do inglês, ServiceOriented Architecture -SOA) (ERL, 2007) é um estilo arquitetural que busca disponibilizar as funcionalidades de um sistema como um serviço para que possam ser compartilhadas e reutilizadas entre aplicações, tendo como principal objetivo a interoperabilidade e como vantagens a diminuição de tempo de desenvolvimento, a facilidade de agregar novas tecnologias a plataforma, o isolamento da estrutura de um serviço trazendo flexibilidade durante mudanças, o baixo acoplamento entre as partes do sistema facilitando a manutenção e a reutilização de componentes. Frequentemente esses serviços são conectados através de um barramento de serviços (do inglês, Enterprise Service Bus - ESB) que disponibiliza interfaces, ou contratos, acessíveis através de web services e outra forma e comunicação entre aplicações.
2.2 SERVIÇO WEB
Serviço web (Web Service) é uma solução utilizada na integração de sistemas e na comunicação entre aplicações usando mensagens transportadas por protocolos de internet que são identificados por URIs (Uniform Resource Identifier), sendo uma interface que permite às aplicações enviar e receber dados podendo cada uma ter sua própria linguagem que é traduzida para um formato intermediário que pode ser XML (Extensible Markup Language) e JSON (JavaScript Object Notation). O objetivo dos Serviços Web é a comunicação de aplicações através da internet que é realizada com intuito de facilitar a EAI (Enterprise Application Integration) que significa a integração das aplicações de uma empresa, ou seja, interoperabilidade entre sistemas numa organização nas diferentes aplicações como, por exemplo, o comércio eletrônico com aos seus clientes e seus fornecedores. Essa interação constitui o sistema de informação de uma empresa.
2.3 REST
O REST (Representational State Transfer) é um estilo arquitetural de criação de Web Services, que foi apresentado em uma tese de doutorado de Roy Fielding no ano 2000, que gerencia recursos que são nada mais do que uma abstração sobre um determinado tipo de informação que a aplicação gerência. Um dos princípios é que cada recurso tenha uma identificação única criada utilizando o conceito de URI, para que possa ser identificado e manipulado em uma determinada solicitação. O cliente pode acessar esses recursos através de requisições HTTP pelos métodos GET, POST, PUT e o DELETE, onde:
GET: Obter dados de um recurso. POST: Cria um recurso.
PUT: Substituir os dados de um determinado recurso. DELETE: Excluir um determinado recurso.
Tabela 1: Exemplos de requisições utilizando os métodos HTTP
URI Verbo HTTP Corpo JSON Resultado
/laudo GET Vazio Retorna todos os laudos
cadastrados.
/laudo/ POST JSON Cadastra um novo laudo.
/laudo/:id PUT JSON Atualiza um laudo determinado
pelo id na URI.
/laudo/:id DELETE Vazio Remove um laudo determinado
pelo id na URI.
2.4 PROCESSO UNIFICADO
O Processo unificado (Unified Process - UP) foi proposto por Jacobson, Booch e Rumbaugh (1999) é um conjunto de atividades necessárias para transformar
requisitos do usuário em um sistema de software, que surgiu para realizar o desenvolvimento de software visando a construção de sistemas orientados a objetos sendo iterativos e adaptativos desta forma consegue produzir um sistema de grande porte como se fossem vários pequenos sistemas, o que diminui o risco de projeto e é fundamental que na visão de que o avanço de um projeto deve estar baseado na construção de artefatos de software, e não apenas em documentação. Características básicas do processo unificado:
Fluxo do Processo iterativo e incremental; Comunicação com o cliente;
Uso de métodos para descrever a visão do sistema pelo cliente (casos de uso);
Arquitetura de software como centro dos esforços da equipe do projeto O processo unificado é dividido em quatro fases:
Concepção: nesta fase ocorre o levantamento do escopo de projeto. 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: durante essa fase, a maioria dos casos de uso são especificados e detalhados. A arquitetura do sistema é projetada utilizando artefatos que podem ser estáticos ou dinâmicos. Neste instante são apresentados, o Baseline completo do projeto, os componentes que formarão a equipe de desenvolvimento etc. No final dessa fase os envolvidos devem estar aptos a planejar a fase de construção em detalhes.
Construção: implementação iterativa dos elementos restantes de menor risco e mais fáceis e preparação para a implantação.
3 MATERIAIS E MÉTODOS
Para o desenvolvimento do sistema proposto foi adotado uma metodologia ágil conhecida como OpenUp (Open Unified Process, ou Processo Unificado Aberto) que é fundamentado no Processo Unificado (Kruchten, 2003), sendo cada vez mais frequente nas empresas de desenvolvimento de software. O OpenUp é um processo objetivo e independente de ferramenta, que pode ser estendido para direcionar uma grande variedade de projetos (OpenUP, 2010). É considerado um processo mínimo, completo e extensível, valorizando a colaboração entre a equipe e os benefícios aos interessados, ao invés da formalidade e entrega de itens desnecessários (OpenUP, 2010). O projeto foi desenvolvido seguindo as quatro etapas da metodologia ágil OpenUp que é ilustrado na imagem a seguir na Figura 2:
FONTE: (Meira, 2010).
3.1 INICIAÇÃO
Na fase da iniciação foi enfatizado o processo de análise de negócio e requisitos. Como mencionado anteriormente este projeto foi planejado com base no
funcionamento do Laboleite da EAJ, sendo assim o levantamento de requisitos ocorreu com a interação do cliente que no caso foram tanto os colaboradores quando o coordenador do laboratório. É apresentado o diagrama de caso de uso na Figura 3 a seguir.
FONTE: adaptação do projeto de projetos aplicados II.
O levantamento de requisitos é umas das partes mais importantes no processo de desenvolvimento de um software, porque serve para entender o que o cliente deseja ou o que cliente acredita que precisa e as regras do negócio ou processos do negócio, dessa forma para obtenção dos requisitos foram feitas várias reuniões semanalmente com a equipe do Laboleite, onde foram elaboradas várias perguntas entre os bolsistas, funcionários e o coordenador para que pudesse obter um conhecimento básico do problema. Com os requisitos coletados e especificados
foi possível moldar como o sistema iria se comportar definindo os requisitos funcionais, ou funcionalidades do sistema, e os não-funcionais, ou as necessidades que não podem ser atendidas através de funcionalidades estão apresentados na Tabela 2 e Tabela 3 respectivamente.
Tabela 2. Requisitos funcionais.
Código Descrição
RF001 Realizar login e autenticar usuário RF002 Cadastro, atualização, exclusão e busca
de usuário
RF003 Cadastro, exclusão, busca e
atendimento da solicitação da análise RF004 Cadastro, atualização, exclusão e busca
da Fazenda
RF005 Cadastro, atualização, exclusão, busca e emissão do laudo
RF006 Cadastro e atualização de imagens da
solicitação
RF007 Cadastro, atualização, exclusão e busca da média do laudo
RF008 Cadastro, atualização, exclusão, coleta, buscar e geração do QRCode da
amostra
Tabela 3. Requisitos não-funcionais.
Código Descrição
RNF001 O sistema só deve ser acessado por usuários cadastros no sistema e autorizados por processo de login, sendo que todas as operações devem
validar as credenciais para cada operação requisitada.
RNF002 O sistema deve guardar às senhas de forma criptografada.
RNF003 O sistema deve ser acessado através da internet.
RNF004 O sistema deve ser compatível com qualquer browser.
3.2 ELABORAÇÃO
Na fase de elaboração é enfatizado o processo de desenvolvimento da análise arquitetural do sistema, onde foi escolhida uma arquitetura estável para que fosse possível o sistema evoluir. Por se tratar de um software complexo e com muitos requisitos de qualidade foi planejada para detalhar os componentes, suas propriedades e relacionamentos de modo que possa facilitar o desenvolvimento e manutenção. Para realizar as especificações da arquitetura de software foi adotado o modelo arquitetural de Visões 4+1.
3.2.1 VISÕES 4+1
O modelo arquitetural visão-modelo 4+1 foi desenvolvida por Philippe Kruchten (1995) com o objetivo de descrever o funcionamento de sistemas software e é baseado no uso de múltiplas visões concorrentes. As visões são usadas para mostrar o sistema sob várias perspectivas, como: usuário final, desenvolvedores e gerentes de projeto e são divididas em quatro visões de modelo que são a visão lógica, visão de desenvolvimento, visão de processo, visão física e além disso são usados casos de uso ou cenários selecionados para ilustrar a arquitetura que serve como a visualização transversal. Portanto, o modelo o modelo contém 4+1 visualizações, como ilustrado na Figura 4 a seguir.
FONTE: Bruno buzzi
3.2.2 VISUALIZAÇÃO DE CASO DE USO
As funcionalidades do sistema são ilustradas usando um pequeno conjunto de casos de uso e cenários, que se tornam uma quinta visualização. Os cenários descrevem sequências de interações entre objetos e processo. Eles são usados para identificar elementos arquitetônicos e para ilustrar e validar o design da arquitetura também servem como ponto de partida para teste de um protótipo de arquitetura. Essa visualização também é conhecida como visualização de caso de uso.
O sistema desenvolvido é composto por três atores que são:
1. Administrador: é o usuário têm o controle de gerenciamento do sistema e que cadastra os usuários.
2. Colaborador: é o usuário responsável por realizar parte das funcionalidades do sistema que foi criado com base que no laboratório é composto tanto por
funcionários quanto que bolsistas que pode atender solicitações e emitir laudos.
3. Cliente: é o usuário que solicitar a análise, visualizar e pode realizar a coleta das amostras.
3.2.3 VISÃO LÓGICA
A Visão Lógica é responsável por suportar os requisitos funcionais do sistema e sua representação é feita pelo diagrama de classe, que têm como objetivo descrever as classes, relacionamentos, herança e assim por diante. A Figura 5 a seguir apresenta o diagrama de classe.
FONTE: adaptação do projeto de projetos aplicados II.
Figura 5: Versão simplificada do diagrama de classe do projeto desenvolvido em projeto aplicados II.
Tabela 3: Descrição do diagrama de classes
Classe Descrição
Usuario Classe que representa o usuário que tipo de usuário utilizará o sistema dentre o cliente, administrador e o
colaborador.
Fazenda Classe que representa às informações da fazenda do cliente.
Solicitacao Classe que representa a solicitação criada pelo usuário composta por
análises e dados de cliente. Analise Classe que representa às análises
solicitadas composta por origem do leite, produto, espécie e quantidade de
amostras.
Amostra Classe que representa uma amostra tendo informações como o estado de
coleta e data da coleta.
OrdemServico Classe que representa o atendimento da solicitação do cliente contendo informações como os responsáveis pelo
atendimento.
Credencial Classe que representa a credencial do usuário para logar no sistema. Laudo Classe que representa os resultados
das amostras analisadas. LaudoMedia Classe que representa a média
referente a lista de laudos da solicitação.
Arquivo Classe que representa a imagem que será guardada no banco de dados.
3.2.4 VISÃO DE DESENVOLVIMENTO
A visão de desenvolvimento ilustra a modularização do software, o sistema é dividido em pequenos subsistemas e organizado em hierarquia. Essa visão também é conhecida como visão de implementação. Visando atingir os objetivos do projeto a arquitetura do sistema foi planejada como base na arquitetura em camadas que pode ser definida como um processo de modularização de sistemas complexos em camadas proporcionando maior facilidade na compreensão e de modo criando uma hierarquia de níveis de modos de acesso, protegendo as camadas mais internas fazendo com que uma camada seja dependente somente das camadas abaixo dela.
A arquitetura está representada em cinco camadas como apresentado na Figura 6: 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ócio e as estruturas dos 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, o formato adotado foi o JSON, pois é leve e de fácil interpretação. A camada do frontend é dividida entre uma aplicação web desenvolvida em Vue.js para o laboratório e uma mobile desenvolvida em android para os clientes que servem como interfaces para os usuários possam interagir com as funcionalidades do sistema.
3.2.5 VISÃO DE FÍSICA
A Visão Física demostra o ambiente no qual o sistema é executado e leva em consideração os requisitos não funcionais como disponibilidade, escalabilidade, confiabilidade e desempenho.
A Figura 7 descreve os componentes do sistema: O cliente representa a interface do sistema que faz referência ao browser que se comunica com o servidor através do protocolo HTTP e utiliza os métodos que permitem acessar as funcionalidades do sistema. O servidor armazena às regras de negócio que definem como os serão dados acessado, sendo também responsável por fazer a comunicação entre o banco de dados e o cliente. E o banco de dados faz referência a todos os registros existentes, a comunicação com o servidor é realizar através do JDBC (Java Database Connectivity) que é um conjunto de classes e interfaces escritas em Java que fazem o envio de instruções SQL para qualquer banco de dados relacional.
3.2.6 VISÃO DE PROCESSOS
A Visualização de Processos lida com os aspectos de tempo de execução do sistema, explica os processos e como eles se comunicam, focando no comportamento do sistema. O diagrama de atividades é usado nesta visão. A Figura 8 apresenta o diagrama de atividades que descreve as etapas da criação de uma solicitação pelo usuário. Primeiramente o cliente deve ser selecionado, em seguida selecionar a fazenda na qual será coletada as amostras de leite e selecionar às análises disponíveis no sistema.
A Figura 9 apresenta o diagrama de atividades que descreve o cadastro e a emissão do laudo. Primeiramente os laudos das análises da solicitação devem ser cadastrados podendo ser manualmente e importando um arquivo CSV no sistema, em seguida selecionar o batch que é o identificador comum entre o conjunto de laudos para gerar a média do laudo e selecionar a forma de exportação laudo podendo ser no formato PDF ou XLS.
3.3 CONSTRUÇÃO
Na fase de construção é enfatizada o processo de implementação da solução proposta com base na arquitetura apresentada anteriormente. A equipe de desenvolvimento é composta por 13 programadores e 3 gerentes de projeto responsáveis por coordenar a equipe, mas no contexto desta monografia serão
apresentadas com mais ênfase as implementações realizadas pelo autor do trabalho.
Para a construção do sistema foi utilizado o framework Spring Boot para o desenvolvimento do backend já que um projeto Spring serve para facilitar o processo de configuração e de publicação das aplicações. Para o mapeamento objeto-relacional das classes em tabelas do banco objeto-relacional foi utilizada o framework Hibernate. Para a realização de consultas no banco de dados foi utilizada o framework Spring Data JPA, facilita a criação dos repositórios liberando os desenvolvedores de ter que implementar às interfaces referentes os repositórios (ou DAOs), também já deixando pré-implementado algumas funcionalidades como, por exemplo, de ordenação das consultas e de paginação de registro. Para acessar o sistema é necessário ser um usuário autenticado (username e senha válidos) pelo sistema tendo em vista que as funcionalidades do sistema estão protegidas para manter de forma segura cada requisição HTTP, podendo ser GET, POST, PUT e DELETE feita no frontend pelo usuário.
Umas das principais funções implementadas foi o serviço da emissão do laudo. Esse serviço é responsável por exibir todas as informações da solicitação do cliente e do laudo que são os resultados das análises solicitadas e feitas no laboratório para enviar para o cliente. Para construir esse serviço foi necessário utilizar um software chamado Jaspersoft iReport Design 5.6.0, que cria relatórios que podem ser exportados em PDF e XLS. A criação do relatório tem como passos: 1 -Definir uma conexão com o banco de dados e 2 - Através de um SQL buscar os dados, podendo usar os componentes disponíveis como list, table dentre outros como representa a Figura 10. Para emitir um laudo é necessário o cliente solicitar para sua fazenda análises de amostra de leite pelo aplicativo mobile e o laboratório vai atender à solicitação podendo aprovar, recusar dentre outras opções. Somente quando aceita, o laboratório envia os potes com QRCodes para a coleta das amostras, em seguida são enviadas para o Laboleite para ser atendida na aplicação web e então o laudo pode ser cadastrado com os resultados das análises para ser gerado a média do laudo da solicitação e assim poder exportar os arquivos.
3.3.1 APLICAÇÃO WEB
A Figura 11 apresenta os componentes da tela de login que são apresentados para os usuários.
Figura 10: Imagem do software Jaspersoft iReport Design 5.6.0.
Na Tela inicial do sistema, apresentada na Figura 12, são listadas todas as solicitações feitas para o laboratório essa tela possui uma barra lateral com um menu de opções de trabalho disponíveis que são as seguintes:
1. Clientes: Usada para listar todos os clientes cadastrados podendo ser atualizados ou excluídos e visualizar suas fazendas.
2. Colaboradores: Usada para listar todos os colaboradores do laboratório cadastrados, podendo ser atualizados ou excluídos.
3. Administradores: Usada para listar todos os administradores cadastrados, podendo ser atualizados e excluídos.
4. Cadastrar Solicitação: Usada para cadastrar uma nova solicitação de análise para o cliente.
5. Listar Solicitação: Usada para listar às solicitações cadastradas no sistema e exibindo o nome do cliente, nome da fazenda, status da solicitação, a data de criação e algumas ações sobre a solicitação.
6. Cadastro Laudo: Usada para cadastrar um novo laudo, podendo ser importando um arquivo CSV ou digitando os dados.
7. Listar Laudo: Usada para lista os laudos cadastrados, podendo ser atualizados ou excluídos.
8. Sair: Usada para sair do sistema.
9. Atualizar Solicitação: Usada para atualizar os dados da solicitação. 10.Excluir Solicitação: Usada para excluir a solicitação.
11.Detalhar Solicitação: Usada para detalhar os dados da solicitação.
12.Atender Solicitação: Usada para atender à solicitação mudando seu status, observação, temperatura da amostra etc.
13.Cadastro Laudo na Solicitação: Usada para cadastrar o laudo na solicitação.
14.Listar Laudo Cadastrado na Solicitação: Usada para listar o laudo cadastrado na solicitação.
A tela de cadastro do laudo, apresentada na Figura 13, apresenta duas maneiras de cadastro:
1. Importando um CSV.
2. Digitando os dados nas entradas.
O cadastro por importação é realizado a partir de um arquivo gerado do DairySpec FT é uma máquina que realiza análises nas amostras de leite inseridas e no final produz um CSV com os resultados para o usuário. O cadastro por digitação é feito porque o DairySpec FT não faz todas as análises.
A tela de listar os laudos, apresentada na Figura 14 é onde todos os laudos cadastros são exibidos, tendo essas funcionalidades:
1. Editar Laudo: Redireciona o laudo selecionado para a tela de edição. 2. Excluir Laudo: Remove o laudo selecionado.
3. Cadastrar Novo Laudo: Redireciona para tela de cadastrar laudo. 4. Pesquisar: Pesquisar dados nos laudos da tabela.
Figura 13: Tela do cadastro do laudo.
Na tela de edição de laudo, apresentada na Figura 15, o laudo selecionado irá preencher os componentes nos seus respectivos dados para a edição.
Na tela de detalhes da solicitação, apresentada na Figura 16 os dados da solicitação são exibidos como dados do cliente, da fazenda e a análise selecionada.
Figura 15: Tela de edição do laudo.
Na Figura 17 é apresentada a tela dos detalhes da solicitação, onde são exibidas as informações da análise selecionado e uma funcionalidade que é:
1. Gerar QRCode: Usada para gerar QRCodes da quantidade de amostras da análise.
Na Figura 18 é apresentada a página A4 onde os QRCodes da análise foram gerados para serem colocados nos potes das amostras para os clientes.
Na Tela dos detalhes da solicitação, apresentada na Figura 19, exibe os dados referente a solicitação como:
1. Observação: Usada exibir a observação adicionada pelo laboratório.
2. Detalhes da Solicitação: Usada para exibir detalhes como temperatura das amostras recebidas, coletadas, não analisadas e recebidas.
3. Comprovante: Usada para exibir o comprovante do pagamento da solicitação adicionada pelo cliente.
Na Tela de detalhes da solicitação exibindo imagens das amostras, apresentada na Figura 20, listar as amostras que vieram danificadas na aplicação mobile, para os clientes.
Na tela de cadastro do laudo na solicitação, apresentada na Figura 21, é utilizado um componente para exibir o identificador dos laudos para cadastrar os laudos referentes a solicitação selecionada.
Figura 19: Tela de detalhes da solicitação.
Na tela de listar o laudo da solicitação, apresentada na Figura 22, mostra a média e a lista de laudos da solicitação, também apresenta funcionalidades como:
1. Excluir Média do Laudo: Usada para excluir a média e a lista dos laudos da solicitação.
2. Gerar Relatório PDF do Lado: Usada para gerar um relatório do laudo em PDF.
3. Gerar Relatório XLS do Laudo: Usada para gerar um relatório do laudo em XLS.
4. Exibir Gráficos do Laudo: Usada para redirecionar para a página dos gráficos dos laudos da solicitação.
5. Pesquisar: Usada para pesquisa na lista de laudos da solicitação. Figura 21: Tela de cadastro do laudo na solicitação.
Na Tela de gráfico dos laudos da solicitação, apresentada na Figura 23, são mostrados os dados da lista de laudos da solicitação no gráfico com uma legenda sobre as variáveis do laudo.
Na Tela de gráfico da média dos laudos da solicitação, apresentada na Figura 24, é exibido ainda à mesma tela da figura anterior a média da lista de laudos no gráfico de barras com uma legenda exibindo às variáveis do laudo.
Figura 22: Tela de listar o laudo da solicitação.
Na Tela de Atendimento da solicitação, apresentada na Figura 25, o usuário do laboratório realiza o atendimento da solicitação aprovada, alterando dados como:
1. Status da Solicitação: Usada para alterar o status da solicitação. 2. Observação: Usada para registrar uma ocorrência da solicitação.
3. Emissão do Laudo: Usada para registrar o responsável pela emissão do laudo.
4. Análise Laboratorial: Usada para registrar o responsável pela análise laboratorial.
5. Entregas das Amostras: Usada para registrar o responsável pela entrega das amostras.
6. Data de Recebimento: Usada para registrar da data do recebimento das amostras no laboratório.
7. Data da Análise: Usada para registrar da data do início das análises das amostras.
8. Data do Processamento: Usada para registrar da data do início do processamento.
9. Amostra Recebidas: Usada para registrar a quantidade de amostras recebidas no laboratório.
10. Amostras Não Analisadas: Usada para registrar a quantidade de amostras não analisadas da solicitação.
11. Temperatura: Usada para registrar a temperatura do recipiente recebido com as amostras dentro.
12. Valor: Usada para registrar o valor total da solicitação para o cliente.
13.Salvar Amostras: Usada para enviar as imagens das amostras danificadas recebidas para os clientes.
Nas telas de laudo PDF gerado, apresentada nas Figuras 26, 27 e 28, o laboratório visualizará um relatório gerado sobre a solicitação e seus resultados. Na Figura 29 é apresentado a tela com o laudo gerado em XLS.
3.3.2 APLICAÇÃO MOBILE
Na aplicação mobile do sistema, apresentada na Figura 30, é exibido a tela inicial que a de login do sistema com funcionalidades como: 1-Criação de uma nova conta e 2-Entrar no sistema. A tela de login, apresentada na Figura 31, é exibida com componentes de identificação para o usuário entrar no sistema como: nome do usuário e a senha.
Na tela das solicitações do cliente, apresentada na Figura 32, o cliente visualiza as suas solicitações cadastras exibindo itens como: item 1: nome da sua fazenda, quantidade de análise e seu status; item 2: cadastrar nova solicitação; E os itens 3, 4 e 5 que respectivamente apresentam funcionalidades como listar solicitações, coletar amostras e acessar o perfil do cliente. Acessando a Tela da análise que é visualizada ao entrar na tela de solicitações, apresentada na Figura 33, o cliente visualiza alguns detalhes da solicitação como a quantidade de amostra da análise, a espécie e origem do leite.
Figura 31: Tela do login do aplicativo. Figura 30: Tela do aplicativo mobile.
Na tela de detalhamento da solicitação, apresentada na Figura 34, o cliente pode visualizar completamente a solicitação contendo a origem do leite, produto, espécie, número de amostras e as análises solicitadas. Voltando para a tela das solicitações do cliente, apresentada na Figura 32, o cliente dando um clique longo a solicitação abre um pop-up, apresentada na Figura 35, exibindo funcionalidades como:
1. Visualizar Amostras: Usada para o cliente visualizar as fotos das amostras danificadas recebidas pelo laboratório.
2. Adicionar Comprovante: Usada para o cliente enviar uma foto do comprovante de pagamento da solicitação.
3. Preço: Usada para informar o preço da solicitação. Figura 32: Tela de solicitações do
cliente.
Na tela do comprovante, apresentada na Figura 36, o cliente poderá tanto visualizar como enviar uma imagem do comprovante para o laboratório visualizar. 1. Enviar Comprovante: Usada para enviar a imagem do comprovante. A tela da lista das amostras recebidas da solicitação, apresentada na Figura 37, o cliente visualizará as imagens das amostras danificadas enviadas pelo laboratório.
Figura 34: Tela de detalhamento da análise.
Na seção das amostras é possível visualizar a lista de solicitações e acessando a solicitação é apresentado uma tela de análise, apresentada na Figura 38, que dando um clique longo na análise é exibido a quantidade de amostras coletadas e o total de amostras. Na tela de coleta das amostras, apresentada na Figura 39, o cliente poderá realizar a coleta das amostras verificando o QRCode no botão consultar QRCode e voltar para a tela anterior na anterior no botão finalizar.
Figura 36: Tela do comprovante. Figura 37: Tela da lista de amostras recebidas no laboratório.
Na tela de verificação da amostra coletada, apresentada na Figura 40, o cliente depois de pesquisar o QRCode da amostra, só se for realmente daquela análise os dados serão preenchidos nos componentes da tela e é aberto um pop-up perguntando se ele quer adicionar uma observação que é uma verificação para que a amostra seja coletada. A tela de amostra coletada, apresentada na Figura 41 o cliente realizou a coleta da amostra e verificou novamente para visualizar a data da coleta atualizada e a observação e os dados da amostra.
Figura 38: Tela da situação das amostras.
Na tela dos detalhes da amostra coleta, apresentada na Figura 42, o cliente depois de coletar amostra e volta para tela da análise para abrir o pop-up dos detalhes para verificar quantidade de amostras coletadas.
Figura 40: Tela da verificação da amostra coletada.
Na tela do perfil, apresentada na Figura 43 (A), são mostrados os dados do cliente cadastrado como nome, email, cpf e telefone e funcionalidades no item 1 que serve para atualizar a foto do perfil do cliente e apresentadas na Figura 44 (B), como o editar os dados e visualizar as fazendas.
Figura 42: Tela dos detalhes da amostra coleta.
Na tela de consulta do QRCode do laboratório, apresentada nas Figuras 45 (A), Figura 46 (B), é uma tela que só pode acessada pelos usuários do laboratório logados no aplicativo para consultar os QRCodes dos potes das amostras recebidas no laboratório e depois que pesquisada, preencher os componentes correspondentes aos dados da amostra como apresentado na Figura 47 (C).
Figura 45 Tela de consulta do QRCode do laboratório (A).
Figura 46: Tela de consulta do QRCode do laboratório (B).
3.4 TRANSIÇÃO
A fase de transição enfatizou a implantação do sistema para realização de testes para verificar se o sistema consegue atender os requisitos. Esta etapa compreendeu em colocar o sistema em produção, a princípio o sistema foi colocado online para as pessoas do laboratório pudessem utilizá-lo e retornar erros, ajustes e sugestões.
Figura 47: Tela de consulta do QRCode do laboratório (C).
4 RESULTADOS
Para avaliar a experiência do usuário, foi utilizado uma ferramenta chamada AttrakDiff proposto por Marc Hassenzahl, Michael, Burmester e Franz Kollere desenvolvido na Alemanha foi utilizado por permitir avaliar a atratividade através de diferentes aspectos com pares de adjetivos opostos. Com o AttrakDiff é possível aprender o que os usuários percebem subjetivamente sobre a usabilidade e a aparência do produto interativo. O AttrakDiff captura a qualidade pragmática que mede a facilidade com que o usuário consegue manipular o produto e hedônica que é dividida entre estimulação que mede o quanto os usuários desejam desenvolver suas habilidades sobre o produto e a identificação que mede o quanto os usuários se identificaram com o produto no contexto social e a atratividade que mede quão atrativo é o produto composto por 28 itens em escala semântica para medir a percepção do usuário. A avaliação foi feita com colaboradores responsáveis pelo processo atendimento das solicitações e pela geração dos laudos. Após o término do período de avaliação com os participantes foram obtidos os resultados que são apresentados a seguir:
FONTE: AttrakDiff.
A Figura 48 apresenta os resultados do sistema de como ele é avaliado sob o eixo vertical que exibe a qualidade hedônica que mede as reações emocionais e o eixo horizontal que mostra a qualidade pragmática que mede a usabilidade. O retângulo azul da confiança que mostra o quanto as opiniões dos usuários convergem ou divergem e dependendo dos valores das dimensões pode estar em uma ou mais regiões. Uma das características do retângulo de confiança é quanto maior, menor é a certeza de qual região de qual ele pertence representando uma maior divergência de opiniões. Um pequeno retângulo de confiança é uma vantagem, pois significa que os resultados são mais confiáveis e menos coincidentes. Nos resultados obtidos que o produto mostra-se com controlável orientado a tarefa, desejável e se sobressaindo como neutro e auto orientado. A avaliação também apresentou os resultados sobre a qualidade pragmática de 0,52 e hedônica de 0,52.
FONTE: AttrakDiff.
A Figura 49 representa o diagrama que mostra valores médios das quatro dimensões sendo composta pela qualidade pragmática (PQ), a qualidade hedônica que é subdividida entre os aspectos de estímulo (HQ-S) e a identidade (HQ-I), e a atratividade (ATT). Podemos identificar com os dados do diagrama que os valores próximos da (zona entre 1 e 0) são padronizados: não são valores negativos, significando que o produto atinge seu objetivo sem ter impacto negativo, fora desta zona neutra devem ser considerados como pontos positivos (de 1 a 3) e negativos (de -1 a -3) do produto. A qualidade pragmática indica o grau de sucesso no atingimento dos objetivos e obteve uma pontuação de 0,96 na experiência do usuário. Para a qualidade hedônica identidade, que indica o nível de identificação do usuário com a aplicação desenvolvida, foi obtida uma pontuação de 1,11. Esse resultado indica que o usuário se identificou e para a qualidade hedônica estímulo que mensura se a aplicação é original, interessante e estimulante foi obtido uma pontuação de 0,71, indicando um resultado positivo. Por fim, a atratividade que indica o quanto a aplicação é atrativa para o usuário foi obtido uma pontuação de 1,75, indicando que o usuário considerou a aplicação muito atrativa. Para melhoras podemos observar que a qualidade pragmática e a qualidade hedônica estímulo foram baixas em relações as mais ainda são resultados positivos.
FONTE: AttrakDiff.
A Figura 50 apresenta os valores médios dos pares de palavras para criar uma descrição do sistema utilizando adjetivos opostos que representam características críticas ou bem resolvidas. Ao analisarmos os dados podemos dizer que a linha de pontos azuis está mais posicionada a direta representando uma boa experiência em termos gerais.
A qualidade pragmática (PQ) obteve o maior número de resultados positivos, no entanto para os atributos técnico - humano indicou que o sistema é mais técnico.
Para a qualidade hedônica identidade (HQ-I) obteve maior parte dos resultados positivos.
A qualidade hedônica estímulo (HQ-S) obteve também a maior parte dos resultados positivos, apesar que para o atributo cauteloso – ousado indicou sendo mais cauteloso.
A percepção dos usuários sobre a atratividade (ATT) obteve todos os resultados positivos demostrando que ele considerou o sistema agradável, atraente, simpático, convidativo, bom e motivador.
5 CONCLUSÃO
Neste trabalho de conclusão de curso foi apresentado um novo modulo para o sistema foi desenvolvido durante a disciplina de Projetos Aplicados II, que auxilia com a criação e emissão de laudos e a coleta de amostras das análises, proporcionando mais agilidade para as atividades do Laboleite permitindo que trabalhem de forma mais integrada e eficiente consequentemente gerando uma centralização das informações aumentando a produtividade e confiabilidade.
Os resultados obtidos da avaliação do AttrakDiff apresentaram que os usuários consideraram a aplicação desenvolvida atraente, simpática agradável, profissional, simples, um pouco técnica e cautelosa. Portanto, é possível concluir que o sistema é de útil na realização das atividades do laboratório e atingiu os objetivos esperados para este trabalho.
Uma das ameaças a validade do experimento é que teve poucos participantes na avaliação do AttrakDiff, para trabalhos futuros deve ser feita novamente o mesmo experimento com mais pessoas da equipe do laboratório.
REFERÊNCIAS
BALDUINO, R. (2007). Introduction to OpenUP (Open Unified Process).
Organization, 1–9. Disponível em:
<https://www.eclipse.org/epf/general/OpenUP.pdf> Acessado em 16 de novembro de 2019.
WAKULICZ, G. J. Sistemas de informações gerenciais. Universidade Federal de Santa Maria, Colégio Politécnico, Rede e-Tec Brasil, 2016.
BRAZ, C. C. M. Introdução ao Processo Unificado. DEVMEDIA. 2006.
COULOURIS, G.; DOLLIMORE, J.; KINDBERG, T. Sistemas distribuídos: conceitos e projetos. São Paulo: Bookman, 2007.
EMBRAPA. Desafio de startups apresenta novas tecnologias para a pecuária
de leite. Disponível em:
<https://www.embrapa.br/gado-de-leite/busca-de-noticias/-/noticia/39758198/desafio-de-startups-apresenta-novas-tecnologias-para-a-pecuaria-de-leite>Acessado em 11 de junho de 2019.
EMBRAPA. Embrapa lança aplicativo para gerenciamento de fazendas leiteiras.
Disponviel em:
<https://www.embrapa.br/busca-de-noticias/-/noticia/30536909/embrapa-lanca-aplicativo-para-gerenciamento-de-fazendas-leiteiras>. Acesso em 26 de maio de 2019.
EMBRAPA. Gestão informatizada de sistemas de produção de leite. Disponível em: <http://gisleite.cnpgl.embrapa.br/> Acesso em 26 de maio de 2019.
EMBRAPA. Gisleite: um sistema computacional para a gestão de sistemas de produção de leite. Disponível em: <https://www.embrapa.br/busca-de- publicacoes/-/publicacao/1021929/gisleite-um-sistema-computacional-para-a-gestao-de-sistemas-de-producao-de-leite> Acessado em 12 de junho de 2019.
EMBRAPA. GISLEITE - Gestão de Sistemas de Produção de Leite. Disponível em: <https://www.embrapa.br/gado-de-leite/busca-de-solucoes-tecnologicas/-/ produto-servico/1430/gisleite---gestao-de-sistemas-de-producao-de-leite> Acessado em 12 de junho de 2019.
EMBRAPA. Tecnologias para a produção de leite chamam a atenção de grande público em Rondônia. Disponível em: <https://www.embrapa.br/busca-de-noticias/-/
noticia/2049118/tecnologias-para-a-producao-de-leite-chamam-a-atencao-de-grande-publico-em-rondonia> Acesso em 26 de maio de 2019.
MORAES, B. M. M.; FILHO, R. F. B. Mercado Brasileiro de Lácteos: análise do impacto de políticas de estímulo à produção. Revista de Economia e Sociologia Rural. Brasília, vol.55, no.4, Oct./Dec. 2017.
PAIXÃO, M. G. LOPES, M. A. PINTO, S. M. ABREU, L. R. Impacto econômico da implantação das boas práticas agropecuárias relacionadas com a qualidade do leite. Revista Ceres. Viçosa, vol.61, no.5, Sept/Oct. 2014.
ONFARM. Inovando no Controle da Mastite. Disponível em:<http://onfarm.com.br/ > Acessado em 11 de junho de 2019.
ERL, T. Service-Oriented Architecture - SOA: Concepts, Technology, And Design. Prentice Hall, 2005.
W3C. Web Services Architecture: W3C Working Group 2004. Disponível em: <https://www.w3.org/TR/ws-arch/>. Acesso em: 16 novembro 2019.
FIELDING, R. Architectural Styles and the Design of Network-based Software Architectures. 100 p. Tese (Doutorado) — University of California, 2000.
ANEXO A – DIAGRAMA DE CASOS DE USO E DE CLASSES COMPLETO
FONTE: projeto da disciplina de projetos aplicados II. Figura 51: Diagrama de caso de uso completo.
FONTE: projeto da disciplina de projetos aplicados II. Figura 52: Diagrama de classes completo.
