2022-tcc-rlnunes

Prévia do material em texto

UNIVERSIDADE FEDERAL DO CEARÁ
CAMPUS DE SOBRAL
CURSO DE GRADUAÇÃO EM ENGENHARIA DE COMPUTAÇÃO
RAYON LINDRAZ NUNES
SISTEMA WEB DE GESTÃO FINANCEIRA PARA OVINOCAPRINOCULTURA
SOBRAL
2022
RAYON LINDRAZ NUNES
SISTEMA WEB DE GESTÃO FINANCEIRA PARA OVINOCAPRINOCULTURA
Trabalho de Conclusão de Curso apresentado ao
Curso de Graduação em Engenharia de Com-
putação do Campus de Sobral da Universidade
Federal do Ceará, como requisito parcial à
obtenção do grau de bacharel em Engenharia de
Computação.
Orientador: Prof. Dr. Iális Cavalcante de
Paula Júnior
SOBRAL
2022
Dados Internacionais de Catalogação na Publicação 
Universidade Federal do Ceará
Biblioteca Universitária
Gerada automaticamente pelo módulo Catalog, mediante os dados fornecidos pelo(a) autor(a)
N928s Nunes, Rayon Lindraz.
 Sistema web de gestão financeira para Ovinocaprinocultura / Rayon Lindraz Nunes. – 2022.
 38 f. : il. color.
 Trabalho de Conclusão de Curso (graduação) – Universidade Federal do Ceará, Campus de Sobral,
Curso de Engenharia da Computação, Sobral, 2022.
 Orientação: Prof. Dr. Prof. Dr. Iális Cavalcante de Paula Júnior.
 1. Aplicação WEB. 2. Agropecuária. 3. Gestão Financeira. 4. EMBRAPA. 5. Ovinos e Caprinos. I.
Título.
 CDD 621.39
RAYON LINDRAZ NUNES
SISTEMA WEB DE GESTÃO FINANCEIRA PARA OVINOCAPRINOCULTURA
Trabalho de Conclusão de Curso apresentado ao
Curso de Graduação em Engenharia de Com-
putação do Campus de Sobral da Universidade
Federal do Ceará, como requisito parcial à
obtenção do grau de bacharel em Engenharia de
Computação.
Aprovada em:
BANCA EXAMINADORA
Prof. Dr. Iális Cavalcante de Paula
Júnior (Orientador)
Universidade Federal do Ceará (UFC)
Prof. Dr. Erick Aguiar Donato
Universidade Federal do Ceará (UFC)
Prof. Dr. Yuri Victor Lima d Melo
Universidade Federal do Ceará (UFC)
RESUMO
A pecuária de ovinos e caprinos no nordeste brasileiro enfrenta grandes dificuldades quando se
comparada com o setor do agronegócio, ainda que componha parte importante da renda e nutrição
da região do semiárido. Como forma de oferecer uma solução de coleta de dados, aplicação
de metodologias e boas-práticas de gestão aos pequenos e médios ovinocaprinocultores, este
trabalho tem como objetivo o desenvolvimento de um sistema web juntamente com a EMBRAPA
que permita a gestão financeira da propriedade e seus rebanhos com acompanhamento de
indicadores e gráficos da propriedade rural. Para o desenvolvimento deste trabalho utiliza-se
principalmente com a linguagem de programação JavaScript que possui robustez e versatilidade
necessárias para o desenvolvimento de soluções para as operações tanto do usuário final quanto
para aplicações executadas em servidores. A concepção do projeto parte de reuniões periódicas
para discussão do problema, exposição das dificuldades enfrentadas e definição do escopo
do projeto. Cada etapa de desenvolvimento foi submetida à revisão e avaliação constantes
para o controle de qualidade e adequação aos fins propostos, procurando definir um meio de
informatização, melhorias no controle de renda e manejo para produtores rurais.
Palavras-chave: Agropecuária. Aplicação WEB. Gestão Financeira. EMBRAPA. Ovinos e
Caprinos.
ABSTRACT
Sheep and goat livestock in northeastern Brazil faces major difficulties when compared to the
agribusiness sector, even though it makes up an important part of the income and nutrition of
the semiarid region. As a way to offer a solution for data collection, application of management
methodologies and best practices to small and medium-sized sheep and goats farm producers,
this work aims to develop a web system together with EMBRAPA that allows for financial
management of the property and its herds with monitoring of indicators and graphs of the rural
property. For the development of this work, it is mainly used with the programming language
JavaScript which has the necessary robustness and versatility for the development of solutions for
both the end user’s operations and for server-side applications. The design of the project starts
with periodic meetings to discuss the problem, expose the difficulties faced and define the scope
of the project. Each stage of development was subjected to constant review and evaluation for
quality control and adequacy to the proposed goals, seeking to define a means of computerization,
improvements in income control and management for rural producers.
Palavras-chave: Farming. WEB application. Financial management. EMBRAPA. Sheeps and
Goats.
LISTA DE FIGURAS
Figura 1 – Visão simplificada de uma comunicação TCP/IP. . . . . . . . . . . . . . . . 15
Figura 2 – Modelo de comunicação cliente servidor sob arquitetura de uma API REST. 16
Figura 3 – Ilustração do padrão de arquitetura MVC. . . . . . . . . . . . . . . . . . . 19
Figura 4 – Aplicação de interfaces visuais com Bootstrap. . . . . . . . . . . . . . . . . 20
Figura 5 – Fluxograma do Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Figura 6 – Diagrama Entidade-Relacional do Projeto . . . . . . . . . . . . . . . . . . 27
Figura 7 – Tela de login. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Figura 8 – Tela de cadastro de usuário. . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Figura 9 – Tela de seleção de propriedade. . . . . . . . . . . . . . . . . . . . . . . . . 32
Figura 10 – Tela de cadastro de propriedade. . . . . . . . . . . . . . . . . . . . . . . . 33
Figura 11 – Tela de cadastro de rebanho. . . . . . . . . . . . . . . . . . . . . . . . . . 34
Figura 12 – Tela de informações adicionais da propriedade. . . . . . . . . . . . . . . . . 34
Figura 13 – Tela de dashboard. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Figura 14 – Acompanhamento de Finanças. . . . . . . . . . . . . . . . . . . . . . . . . 36
Figura 15 – Tela de lançamentos financeiros. . . . . . . . . . . . . . . . . . . . . . . . 36
LISTA DE TABELAS
Tabela 1 – Comparativo de funcionalidade entre outros softwares comerciais. . . . . . 23
LISTA DE ABREVIATURAS E SIGLAS
API REST Application Programming Interface of a Representational State Transfer
CD Continuous Deployment
CSS Cascading StyleSheet
EMBRAPA Empresa Brasileira de Pesquisa Agropecuária
FK Foreign Key
HTML Hypertext Markup Language
HTTP Hypertext Transfer Protocol
JSON JavaScript Object Notation
MVC Model, View, Controller
ORM Object-relational Mapping
PIB Produto Interno Bruto
PK Primary Key
SGBD Sistema de Gerenciamento de Bancos de Dados
SMTP Simple Mail Transfer Protocol
UI User Interface
URL Uniform Resource Locator
UX User Experience
LISTA DE SÍMBOLOS
d Despesa (R$)
j Taxa de juros (%)
L Lucro Total (R$)
Lb Margem de lucro bruta (R$)
Lliq Margem de lucro líquida (R$)
r Receita (R$)
R Receita bruta (R$)
t Vida Útil (anos)
u Investimento (R$)
Vc Valor de custo total (R$)
Vce Valor de custo operacional efetivo (R$)
Vct Valor de custo operacional total (R$)
Vd Valor de depreciações (R$)
Vr Valor de remuneração do capital (R$)
Vt Valor do terreno (R$)
SUMÁRIO
1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.1 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.1.1 Objetivo Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.1.2 Objetivos Específicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2 TECNOLOGIAS WEB . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.1 Modelo cliente-servidor . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2 Linguagem de Programação . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.3 Node.js . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.3.1 Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.4 ArquiteturaMVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.5 Responsividade, UI e UX . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.6 Banco de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.6.1 PostgreSQL e ORM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.7 Docker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.8 Git e Github . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3 TRABALHOS RELACIONADOS . . . . . . . . . . . . . . . . . . . . . 23
4 METODOLOGIA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.1 Módulos do sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.1.1 Usuários . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.1.2 Propriedades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.1.3 Rebanho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.1.4 Finanças . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.2 Indicadores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.2.1 Custo Operacional Efetivo . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.2.2 Depreciações . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.2.3 Custo Operacional Total . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.2.4 Remuneração do Capital . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.2.5 Custo Total . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.2.6 Receita Bruta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.2.7 Margem de Lucro Bruta . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.2.8 Margem de Lucro Líquida . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.2.9 Lucro Total . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
5 RESULTADOS E DISCUSSÃO . . . . . . . . . . . . . . . . . . . . . . . 31
5.1 Cadastro e login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.2 Seleção e cadastro de propriedade. . . . . . . . . . . . . . . . . . . . . . 32
5.3 Cadastro de rebanho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.4 Cadastro de informações adicionais da propriedade . . . . . . . . . . . . 33
5.5 Dashboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.6 Lançamentos financeiros . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
6 CONCLUSÕES E TRABALHOS FUTUROS . . . . . . . . . . . . . . . 37
REFERÊNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
12
1 INTRODUÇÃO
A informatização de produtos e serviços vem conquistando cada vez mais espaço
no comércio global. No entanto, seu uso na agropecuária brasileira ainda é bastante incipiente,
apesar do setor corresponder à uma grande parcela da economia nacional, visto que contribui
significativamente para o Produto Interno Bruto (PIB), emprego da população economicamente
ativa e exportações. O foco da informatização do meio rural concentra-se principalmente em
multinacionais do setor de agronegócio, máquinas, sementes, defensivos, fertilizantes e demais
insumos (HADDAD, 1999).
Na agricultura familiar e de subsistência, vê-se que estas mudanças podem intensi-
ficar desigualdades latentes existentes no campo. Grandes barreiras são impostas ao produtor
rural que não possui acesso às possibilidades tecnológicas, tais como infraestrutura, capacitação
e controle financeiro, onde a maioria dos produtores brasileiros baseiam-se no que produzir,
quanto, quando e com qual tecnologia através principalmente de recomendações de pessoas
próximas com raras ocasiões de recomendações técnicas e informações confiáveis e sem um
acompanhamento estruturado de receitas ou despesas (LOCATEL; CHAPARRO, 2004).
Aponta-se que o uso de computadores de forma geral, concentra-se em grandes
propriedades que oscilam entre 5 mil e 10 mil hectares, representando 65% das propriedades
que os adotam além de uma correlação direta de 56% dos donos de terras possuírem formação
universitária.
Mesmo neste cenário de baixa informatização dos pequenos agricultores, é possível
adotar diferentes estratégias para geração de renda. No caso da região semiárida do nordeste, a
ovinocaprinocultura é uma importante fonte de geração de renda e alimentação para o sertanejo1,
representando 92,8% e 57,8%, respectivamente, dos rebanhos de ovinos e caprinos de todo o
país, mesmo sob condições adversas e pouca implementação de tecnologias de informação e
comunicação (NOGUEIRA et al., 2008).
A Empresa Brasileira de Pesquisa Agropecuária (EMBRAPA) constitui nesse cenário
um meio de viabilizar o acesso a informações técnicas, já que possui como um de seus objetivos,
desenvolver soluções sustentáveis para a agricultura e promover a integração e capacitação de
pequenos e médios agricultores na gestão agropecuária, desta forma, aperfeiçoando os processos
de coleta de dados, aplicação de metodologias e boas práticas de gestão de rebanhos e de finanças.
Como forma de atingir tais objetivos aproveitando-se dos benefícios da informati-
1 que se situa no interior, de modo rústico.
13
zação planeja-se em parceria com a Universidade Federal do Ceará a implementação de um
sistema web com o intuito de gerenciar propriedades com rebanhos de ovinos e caprinos.
1.1 Objetivos
Os objetivos deste trabalho podem ser classificados através do escopo geral, definido
os resultados a serem alcançados e também em aspectos mais específicos detalhando as etapas e
os processos de desenvolvimento da aplicação.
1.1.1 Objetivo Geral
Desenvolvimento de um sistema web que permita à agricultores o cadastro de
propriedades, rebanhos e finanças bem como obtenção de relatórios de acompanhamento e
indicadores de produtividade que auxiliam na gestão da propriedade.
1.1.2 Objetivos Específicos
Montar um protótipo da interface, dos módulos dos sistemas e estruturas da comuni-
cação entre o usuário final e os servidores do sistema. As etapas de desenvolvimento consistirão
em:
1. Definição dos módulos do sistema e suas integrações;
2. Implementação da camada de interface visual (front-end);
3. Implementação do servidor web (back-end);
4. Implementação da camada de dados (Banco de dados);
5. Hospedagem e disponibilidade do sistema para acesso aos usuários;
6. Avaliação de usabilidade e adequação às demandas;
7. Documentação e registro das estruturas e arquiteturas desenvolvidas.
14
2 TECNOLOGIAS WEB
A web (forma compacta do termo World Wide Web) consiste na comunicação global
e aberta entre coleções de dispositivos digitais (computadores, celulares e demais eletrônicos)
capazes de enviar e receber dados através de protocolos ou pilhas de protocolos. O TCP/IP é a
pilha de protocolos mais comum que define padrões de comunicação confiáveis e toleráveis à
falhas (JACKSON, 2007).
Portanto o conceito de tecnologias ou aplicações web são softwares que trabalham
na camada de mais alto nível do protocolo TCP/IP; e.g., Protocolo de Aplicação como Hypertext
Transfer Protocol (HTTP).
A Figura 1 demonstra uma aplicação Simple Mail Transfer Protocol (SMTP) onde
cada caixa representa uma camada do protocolo, elipses representam o dado transmitido entre os
protocolos e cada número corresponde a ordem das operações. Neste exemplo encaminham-se
dados de um servidor nomeado Host B através do protocolo TCP identificado pela porta 25, que
registra o endereço do servidor, através de um código de 32-bits (comumente representado por 4
blocos de 8 bits, onde em representação decimal consiste no intervalo de 0 à 255), denominado
IP. O cliente denominado Host A realiza o mesmo processo para requisição dos dados, logo o
conjunto de dados "IP+TCP[25]+Data"que identifica a mensagem é modulado e transmitido por
um canal (fibra ótica, ondas de rádio e etc) através da internet. Amensagem é então traduzida
pelo servidor pelo mesmo protocolo TCP e porta 25 e finalmente os dados são recebidos e
processados pelo servidor.
2.1 Modelo cliente-servidor
Este modelo de comunicação para a web define dois tipos de "atores"que implemen-
tam diferentes versões do software da aplicação onde: o cliente, representado por um browser,
ou navegador web, terá o papel de consumir e requisitar informações de um servidor que deve
respondê-las provendo, autenticando e armazenando as informações fornecidas pelo cliente.
Ainda tomando o exemplo da Figura 1 o Host B deve ser capaz de acessar todos os
emails e fornecer ao cliente Host A, somente os emails associados à conta que foram solicitados.
As tecnologias que interagem do lado cliente são conhecidas como front-end que tratam de:
• Estruturar a apresentação dos dados através de linguagens de marcação que
definem textos, cabeçalhos, listas e etc. (e.g., HTML, XML, LaTeX, Markdown);
15
Figura 1 – Visão simplificada de uma comunicação TCP/IP.
Fonte: (JACKSON, 2007)
• Definir estilização, cores, posicionamento e tamanhos através de linguagens de
estilo como Cascading StyleSheet (CSS);
• Permitir interações do lado do cliente com elementos da página (menus, formulá-
rios e etc.) com a linguagem JavaScript.
A versão do software contendo tecnologias definidas para o servidor, possuem a
denominação back-end e atuam na disponibilização de recursos para o cliente sob arquiteturas
como uma Application Programming Interface of a Representational State Transfer (API REST).
O conceito de uma API REST define o acesso de recursos através de métodos ou verbos HTTP
(GET, POST, PUT/PATCH ou DELETE) localizados por um endereço denominado Uniform
Resource Locator (URL) com tráfego de informações via formatos de dados como o JavaScript
Object Notation (JSON) de forma a permitir uma comunicação padronizada, independente de
qual tecnologia tenha sido adotada pelo servidor ou pelo cliente.
Como demonstrado na Figura 2, a caixa superior indica o conteúdo de uma requisição
HTTP que procura enviar dados para um servidor através do método POST, tomando como
exemplo o cadastro de um usuário. O servidor localizado através de sua URL pública transmite
16
informações codificadas no formato JSON. O servidor por sua vez devolve uma resposta, descrita
na caixa inferior, com um código numérico que identifica o sucesso ou falha no recebimento da
requisição e opcionalmente um outro objeto JSON com informações pertinentes retornadas ao
cliente.
Figura 2 – Modelo de comunicação cliente servidor sob arquitetura de uma API REST.
Fonte: elaborado pelo autor (2021)
2.2 Linguagem de Programação
Uma linguagem de programação consiste em um conjunto de regras de sintaxe e
semântica que permitem fornecer instruções para um computador através de comandos mais ou
menos próximos da linguagem humana, dado o propósito de cada linguagem (COMPUTERSCI-
ENCE.ORG, 2021).
Os dados são processados pelo computador através de sinais elétricos representados
pelo sistema de numeração binário. Traduzir a linguagem de programação em binário é conhecido
17
como "compilação". Cada linguagem tem seus próprios recursos distintos, embora muitas vezes
haja semelhanças entre as linguagens de programação, definidos como paradigmas.
A linguagem JavaScript é uma linguagem multiparadigma, mais conhecida como
uma linguagem de scripts para páginas web (front-end). Entretanto é também usada para
ambientes sem browsers como é o caso do interpretador de scripts Node.js (Seção 2.3) uma
ferramenta que estende o uso da linguagem também para aplicações back-end, oferecendo uma
mesma base de código para ambas as partes da aplicação, contribuindo para a manutenção do
projeto como um todo (MOZILLA, 2021) .
2.3 Node.js
O Node.js® é um projeto de código aberto de um interpretador (runtime) que executa
código JavaScript em um ambiente desacoplado do browser, permitindo a criação de aplicações
tanto para web quanto para desktops, dispositvos móveis, servidores e etc. O termo runtime difere-
se de um compilador pois não há conversão de arquivo de código-fonte em um binário, onde as
instruções são executadas diretamente no ambiente do Node.js. A ferramenta também possui
uma arquitetura baseada em eventos que permite acesso concorrente de funções o que oferece
a possibilidade de desenvolvimento de aplicações escaláveis; i.e., que atendam à diferentes
demandas de acesso simultâneo.
2.3.1 Framework
Devido ao amplo uso de aplicações web atualmente, emergem inúmeros padrões de
arquitetura que solucionam problemas cotidianos no contexto do desenvolvimento de software e
que podem ser reaproveitados em diferentes ocasiões acelerando a implementação, melhorando
o trabalho em equipe e contribuindo na manutenção de projetos de longo prazo. Estes padrões
podem ser encapsulados em classes ou funções onde não é necessário entender os detalhes de
implementação, apenas a estrutura de dados de entrada e saída. O conjunto destas soluções agre-
gando bibliotecas de código, estrutura de pastas e arquivos são empacotadas em um Framework,
que diferentemente de simplesmente bibliotecas, impõem o padrão de arquitetura e de práticas
para o desenvolvimento de um software em um domínio específico.
Como um exemplo de framework aplicado neste trabalho, foi utilizado o Express, um
framework para o .js que fornece um conjunto de recursos para servidores web, como conexão
18
com bancos de dados, middlewares para controle de acesso de recursos, definição de URL
amigável composta por um sistema de rotas, permitindo o acesso informações de forma legivel e
estruturada.
2.4 Arquitetura MVC
A sigla Model, View, Controller (MVC) representa os três principais componentes
deste padrão de arquitetura (Figura 3), que assim como Frameworks também definem soluções
para problemas comuns no desenvolvimento de software, porém com a diferença de estar
desassociado de uma linguagem ou tecnologia específica, mas como conceitos abstratos para
padronização de projetos e da comunicação formal entre a comunidade de desenvolvedores
(REENSKAUG, 2003).
• Um Model é responsável por representar as regras de negócio (business logic)
ou entidades do sistema, muitas vezes descrito por uma classe em linguagens
orientadas à objetos, que descrevem atributos e comportamentos (métodos) destas
entidades. Tomando como exemplo um model utilizado neste trabalho, tem-se a
entidade "Propriedade"que possui atributos como nome, endereço, área e saldo
bem como métodos que são injetados na classe pela biblioteca Sequelize (Seção
2.6.1) como o método create para criação de uma nova entidade e persistência
no banco de dados (Seção 2.6), o método findAll para buscar todas as entidades
armazenadas e etc.;
• Um Controller torna-se responsável por processar a requisição do usuário manipu-
lar as entidades através do model, verificando autenticação e possíveis validações
da informação fornecida pelo cliente. A partir deste processamento, define-se o
código HTTP de acordo com o sucesso ou falha do processamento bem como é
devolvido a mensagem ao requisitante codificada em JSON;
• A View é responsável por montar os dados que serão apresentados ao usuário
empacotados na forma de um bundle, bem como o gerenciamento de eventos
de entrada pelo usuário (mouse e teclado). A view é entregue ao usuário pelo
controller nos casos onde todo as partes do sistema são projetados em um mesmo
repositório. Neste trabalho de forma a permitir que os dados da aplicação sejam
escaláveis e aptos comunicar-se com múltiplas aplicações, a camada de view está
desacoplada em um repositório independente. No caso de uma futura necessidade
19
de desenvolvimento de uma outra aplicação para dispositivos móveis o acesso
aos recursos do servidor podem ser compartilhados devido ao acesso dos dados
(models e controllers) estar disponibilizado através de uma API REST.
Figura 3 – Ilustração do padrão de arquitetura MVC.
Fonte: (ZHU, 2018)2.5 Responsividade, UI e UX
Este trabalho tem como público-alvo diferentes perfis de usuários com diferentes
níveis de domínio de ferramentas digitais, portanto é de suma importância que a aplicação tenha
um design consistente e siga padrões de usabilidade que permitam adequação de User Interface
(UI) e User Experience (UX) (BATURAY; BIRTANE, 2013).
Os padrões de cores, layouts e tipografias foram definidos pela biblioteca open-
source Bootstrap, permitindo o uso de elementos CSS reaproveitáveis com uma interface visual
agradável e adequadas aos padrões da web. Uma das vantagens do uso de bibliotecas CSS está
no suporte nativo à interfaces responsivas, onde os elementos visuais se dispõem de acordo com
o tamanho da tela do usuário, podendo ser uma tela de desktop caracterizada por ser disposta na
horizontal ou uma tela de um dispositivo móvel (smartphones) com um padrão de tela vertical.
Demonstra-se um design adaptado tanto para telas com maior largura na Figura 4a
quanto para telas com maior altura na Figura 4b. A Figura 4c por sua vez ilustra o cenário quando
a responsividade não é aplicada corretamente, causando uma maior densidade de elementos
visuais na tela, reduzindo o tamanho de cada elemento e prejudicando sua visualização .
20
Figura 4 – Aplicação de interfaces visuais com Bootstrap.
(a) Desktop
(b) Smartphone respon-
siva
(c) Smartphone não respon-
siva
Fonte: elaborado pelo autor (2021)
2.6 Banco de Dados
Um banco de dados consiste em um repositório de uma coleção de arquivos de dados.
Este repositório permite definir estruturas de dados na forma de tabelas e realizar operações de
busca, inserção, atualização e remoção de dados. Cada Sistema de Gerenciamento de Bancos de
Dados (SGBD) pode ser classificado por sua forma de armazenamento e indexação de dados
(DATE, 2003).
21
No caso de SGBDs relacionais, cada tabela é indexada por uma chave-primária,
ou Primary Key (PK) que representa um identificador único na tabela, e esta chave pode estar
presente como uma associação em outra tabela na forma de uma chave estrangeira, ou Foreign Key
(FK) permitindo que uma linha inserida em uma tabela contenha informações que a relacionem
com outra tabela. Este relacionamento pode ser obrigatório ou opcional conforme estabelecido
nas regras de definição de cada tabela. Os tipos de relacionamentos mais comuns em um banco
de dados relacional são:
• Relacionamento 1:1 (um para um): Cada PK de uma tabela possui apenas um
registro como FK de relacionamento de outra tabela associada;
• Relacionamento 1:N (um para muitos): Uma PK pode estar registrada como FK
em uma ou múltiplas tabelas associadas;
• Relacionamento N:M (muitos para muitos): Permite a relação entre tabelas de
forma múltipla e bidirecional, para isto é necessário a criação de uma tabela
intermediária que contenha como FK, tanto a PK de uma tabela quanto de outra.
2.6.1 PostgreSQL e ORM
O SGBD relacional e open-source PostgreSQL é uma solução confiável, perfor-
mática, sem ônus de licenças proprietárias e com uma taxa de adoção comparada à grandes
companhias como Oracle® e Microsoft®. A manipulação de dados neste trabalho é feita através
de Object-relational Mapping (ORM) fornecido pela biblioteca Sequelize onde as operações de
bancos de dados são representadas por uma interface baseada em classes, removendo a necessi-
dade de recorrer diretamente à linguagem SQL para comunicação com o PostgreSQL. Portanto o
Model definido na Seção 2.4 é representado por uma classe que possui métodos que encapsulam
a interação com o banco de dados permitindo a manutenção das regras de persistência com a
mesma linguagem de programação definida no back-end como o JavaScript.
2.7 Docker
Docker é um serviço de empacotamento de software através de contêineres. Um
contêiner é uma unidade padronizada que guarda uma versão de código-fonte, juntamente com
todas suas dependências para que sua execução ocorra em qualquer ambiente computacional,
independente de sistema operacional e suas versões (DOCKER, 2021).
22
Seu uso facilita por exemplo a mudança de ambiente (local e remoto) de hospedagem
sem a necessidade de configuração de servidor e instalação de softwares necessários para executar
o projeto em si.
2.8 Git e Github
Git e Github são softwares que frequentemente se confundem devido à nomenclatura
similar e seu uso normalmente integrado, porém, Git diz respeito a uma ferramenta executada na
linha de comando de um terminal, capaz de criar, recuperar e organizar versões do código-fonte
que são modificados ao longo do tempo no computador local ou em repositórios remotos, como
o Github, que por sua vez permite que diferentes computadores possam acessar e modificar o
repositório disponibilizado através da internet de forma pública ou privada. O Github permite
agregar funcionalidades ao projeto como o controle das modificações de códigos sejam revisadas
por pares através de um processo denominado Pull Request, que após revisado e incorporado
ao sistema, é capaz de integrar-se à serviços em nuvem de Continuous Deployment (CD) que
disponibilizam a nova versão imediatamente aos usuários finais através de ferramentas como o
Github Actions.
23
3 TRABALHOS RELACIONADOS
Também foram avaliadas outras soluções já existentes no mercado em busca de
definir critérios e comparativos para a implementação do sistema, tais como:
• BIPP TECH: Plataforma de Negociação de compra e venda entre produtores,
fornecedores e agroindústrias;
• Aegro: Software de gestão agrícola com módulos de controle de safra, finanças,
maquinário e comércio;
• OvinoPro: Sistema de gestão para manejo de ovinocultura permitindo um acom-
panhamento de histórico de indivíduos e análise de dados.
A ferramenta Aegro apresentou o maior número de funcionalidades que se asseme-
lham aos requisitos do sistema, porém a limitação se dá no fato de ser uma ferramenta ampla
e voltada para agricultura, não atendendo às necessidades da pecuária de caprinos e ovinos.
Já o software OvinoPro traz um controle de rebanhos dedicados ao manejo da ovinocultura
permitindo também a gestão financeira, no entanto não se aplica à gestão de caprinos. O software
BIPP TECH após análise demonstrou-se fazer parte de uma categoria distinta à proposta deste
trabalho como apenas uma plataforma de comércio entre produtores, não tendo funcionalida-
des comparáveis. O trabalho proposto procura analisar os melhores aspectos das ferramentas
disponíveis adequando-se ao contexto do da ovinocaprinocultura permitindo trazer indicadores
específicos para cada espécie bem como o adequado controle de finanças.
Tabela 1 – Comparativo de funcionalidade entre outros
softwares comerciais.
Funcionalidade BIPP TECH Aegro OvinoPro Trabalho Proposto
Comércio de produtos x
Gestão de rebanho x x
Gestão financeira x x x
Gestão de estoque x x
Cronograma x
Indicadores x x
Relatórios x x x
Fonte: elaborado pelo autor (2021)
Com a definição dos pré-requisitos e comparativo com modelos existentes, avaliou-se
que a implementação de um sistema personalizado aos critérios da EMBRAPA, com o foco em
pequenos produtores de ovinos e caprinos e gratuito seria uma solução adequada e justificável de
implementação.
24
4 METODOLOGIA
A necessidade de tal aplicação surge a partir de reuniões periódicas ocorridas com
a equipe técnica da EMBRAPA, expondo os métodos executados diretamente com o produtor
in loco e as dificuldades enfrentadas para realizar o acompanhamento de propriedades rurais,
coleta de métricas, indicadores de produção e econômicos. Por consequência, tais dificuldades
impactam na gestão financeira da propriedade podendo acarretar em perdas e prejuízos devido à
falta de controle de despesas pelo produtor. As principais dificuldades citadas são:
• Longo deslocamento da equipe técnica gerando custos com transportes e estadia;
• O atual método de coleta de dados consiste em um formulário preenchido em uma
planilha impressa ou digital, aplicando todos os dadosda propriedade, rebanho e
finanças de uma única vez, o que dificulta a o acompanhamento dos eventos e da
situação financeira da propriedade ao longo do tempo;
• A coleta pode conter dados imprecisos ou que o produtor não lembra acarretando
muitas vezes em indicadores distorcidos baseados em critérios opinativos e
subjetivos;
• A análise de dados torna-se um processo complexo devido à necessidade de
indexação e integração manual dos dados coletados.
Elencados os problemas, a proposta consiste de um sistema informatizado onde o
próprio produtor rural, em posse de um dispositivo com acesso à internet (computador ou celular)
deverá ser capaz de realizar o cadastro de dados de sua propriedade bem como informações
relativas ao rebanho e finanças com armazenamento e processamento de dados realizado pela
infraestrutura da EMBRAPA. O sistema deve permitir o registro de eventos sob demanda
atualizando os parâmetros da propriedade rural e a geração de relatórios de acompanhamento e
gráficos sobre determinado período de tempo.
A estrutura do sistema e suas integrações foram definidos com base no fluxograma
da Figura 5. As setas indicam as possibilidades de navegação entre os módulos, setas com duas
pontas indicam a possibilidade de retorno ao módulo anterior. Para que sejam gerenciadas as
propriedades o usuário deve ser identificado por suas credenciais (email e senha) e caso possua
uma ou mais propriedades cadastradas previamente, é possível prosseguir para o dashboard da
propriedade diretamente, permitindo gerenciar os lançamentos e obtenção de relatórios.
Para melhor comunicação e alinhamento entre o desenvolvimento e a equipe técnica
da EMBRAPA a etapa inicial consiste no desenvolvimento das interfaces visuais com Hypertext
25
Figura 5 – Fluxograma do Projeto
Fonte: elaborado pelo autor (2021)
Markup Language (HTML), CSS e Javascript com a padronização de UI definida pela biblioteca
Bootstrap populada-as com dados fictícios. Cada tela é submetida por um processo de revisão,
discussão e aprovação. Após definição do front-end com certo grau de maturidade, a camada
de back-end implementa todo o processamento de requisições do usuário sob arquitetura MVC
(Seção 2.4) utilizando essencialmente Node.js, Express e Sequelize, sendo este último operando
sobre o banco de dados PostrgreSQL. A partir da implementação de todas as camadas, é permitido
ao usuário interagir com o sistema, realizar cadastros, a partir da disponibilização do sistema aos
usuários por meio das hospedagem. Durante etapa de testes e avaliações a hospedagem é feita
através de serviços em nuvem como o Netlify® e Heroku® devido à praticidade e infraestrutura
fornecidas gratuitamente além da integração com o Github, que permite publicar novas versões
26
aos usuários tão logo que os Pull Requests sejam aprovados, através do processo de CD.
4.1 Módulos do sistema
Os módulos foram implementados de acordo com as entidades definidas na Figura 6
e dizem respeito à entidades do sistema e como cada uma destas é operada pelo usuário final.
A camada de dados foi definida com base no modelo estrutural dos dados (EVEREST,
1976) demonstrado na Figura 6 para representação do sistema e seus respectivos relacionamentos.
Em cada quadro representa-se uma entidade contendo uma chave primária ou PK representando
um identificador único, as propriedades de cada quadro foram omitidos para fins de manter a
nitidez da ilustração. Cada PK possui uma ou mais linhas conectadas à uma chave-estrangeira
FK que carrega a informação do relacionamento entre as entidades. Cada linha de conexões
possui na extremidade uma barra vertical ou três linhas projetadas, denominada crow-foot,
representando respectivamente um relacionamento único ou múltiplo entre as entidades. Junto
à extremidade, o símbolo adjacente representada a obrigatoriedade do relacionamento, onde
uma barra vertical indica um relacionamento mandatório e o círculo vazio corresponde a um
relacionamento opcional. Neste exemplo tem-se por exemplo a relação entre propriedades e
lançamentos financeiros, onde uma propriedade pode conter nenhum ou inúmeros lançamentos
financeiros associados, que podem estar categorizados como despesa, receita ou investimento.
O processo de desenvolvimento e versionamento do projeto foi gerenciado pela
ferramenta Git e disponibilizado através da plataforma Github dada a necessidade de desen-
volvimento do sistema em equipe. Cada nova atualização do sistema gera um processo de
revisão por pares denominado Pull Request onde os trechos de código-fonte modificados são
destacados e aprovados para que então sejam incorporados a versão principal do sistema de
forma automatizada pelo processo de CD.
4.1.1 Usuários
Os usuários correspondem aos produtores que detém as propriedades de ovinocapri-
nocultura, onde cada entidade possuirá um email distinto que o identificará perante os demais,
este identificador único associado a uma senha, permitirá que o usuário realize a autenticação no
sistema recebendo permissão para gerenciar as propriedades à ele associada.
27
Figura 6 – Diagrama Entidade-Relacional do Projeto
Fonte: elaborado pelo autor (2021)
4.1.2 Propriedades
Cada usuário pode cadastrar e gerenciar múltiplas propriedades no sistema, cada
propriedade possui informações sobre localização, valor do hectare da propriedade, e divisão
do terreno para áreas de pastagens, benfeitorias (bens móveis e imóveis) e de reserva nativa,
bem como é permitido ao usuário cadastrar um inventário de sua propriedade dentre as opções
de benfeitorias, animais de trabalho, equipamentos, forrageiras e outras atividades pecuárias.
A partir de uma propriedade, são associados os rebanhos e as finanças, logo cada propriedade
permite gerenciar estas entidades de forma distinta e independente.
4.1.3 Rebanho
O sistema possibilita tanto o cadastro de rebanhos como também o cadastro individual
de animais, permitindo que futuros lançamentos financeiros ou de manejo, possam ser associados
a um animal específico, impactando nos indicadores da propriedade e relatórios.
28
4.1.4 Finanças
As despesas da propriedade estão diferenciadas em três tipos: despesas, receitas e
investimentos. Cada tipo possui sugestões de categorias predefinidas (e.g., despesa com ração,
receita com leite, investimento em cercado), também é possível registrar a data do lançamento
informações sobre quantidade e valor. Um investimento se diferencia de uma despesa por possuir
o parâmetro de vida útil onde o gasto financeiro se aplica por determinado período tempo, os
indicadores de depreciações(Seção 4.2.2) e remuneração capital(Seção 4.2.4) utilizam-se desta
informação para serem calculados. Cada lançamento financeiro permite uma associação a um
determinado rebanho bem como os rebanhos podem estar associados à lançamentos financeiros,
como é o caso de compra e venda de animais, que adicionam ou removem animais do rebanho
respectivamente. estas informações são computadas e armazenadas para o cálculo de indicadores
e relatórios.
4.2 Indicadores
Os indicadores financeiros foram implementados como pré-requisitos de métricas
utilizadas pela equipe técnica da EMBRAPA para avaliação dos rendimentos de uma propriedade.
Estes indicadores podem ser filtrados tanto por ano ou para rebanhos individualmente.
4.2.1 Custo Operacional Efetivo
O custo operacional efetivo refere-se ao somatório simples de todas as despesas
lançadas, tal que:
Vce = ∑(d) (4.1)
onde:
Vce = Valor de custo operacional efetivo (R$)
d = despesa (R$)
4.2.2 Depreciações
A taxa de depreciação é calculada a partir do valor do investimento proporcional ao
seu tempo de vida útil, tal que:
Vd = ∑
(u
t
)
(4.2)
29
onde:
Vd = Valor de depreciações (R$)
u = Valor do investimento (R$)
t = Vida útil (anos)
4.2.3 Custo Operacional Total
O custo operacional total refere-se à soma do custo operacional efetivo somado ao
valor total de depreciações, tal que:
Vct =Vce +Vd (4.3)
onde:
Vct = Valorde custo operacional total (R$)
4.2.4 Remuneração do Capital
A remuneração do capital consiste em um parâmetro de análise do capital investido
em equipamentos e benfeitorias somados ao valor do terreno atrelado a uma taxa de juros
informado pelo produtor que diz respeito à valorização ou desvalorização dos bens, tal que:
Vr =Vt +
[
∑(u)
]
∗ j (4.4)
onde:
Vr = Valor de remuneração capital (R$)
Vt = Valor do Terreno (R$)
u = Investimento (em R$)
j = Taxa de juros (%)
4.2.5 Custo Total
O custo total é um indicador calculado a partir da soma do custo operacional total
juntamente com a remuneração capital, tal que:
Vc =Vct +Vr (4.5)
onde:
Vc = Valor de custo total
30
4.2.6 Receita Bruta
Consiste no somatório simples de todos os lançamentos de receitas, tal que:
R = ∑(r) (4.6)
onde:
R = Receita Bruta (R$)
r = Receita (R$)
4.2.7 Margem de Lucro Bruta
A margem de lucro bruta é o resultado da diferença entre a receita bruta e custo
operacional efetivo, tal que:
Lb = R−Vcoe (4.7)
onde:
Lb = Margem de Lucro Bruta (R$)
4.2.8 Margem de Lucro Líquida
A margem de lucro líquida é o resultado da diferença entre a receita bruta e custo
operacional total, tal que:
Lliq = R−Vcot (4.8)
onde:
Lliq = Margem de Lucro Líquida (R$)
4.2.9 Lucro Total
O lucro total, por sua vez, é dado pela receita bruta subtraída do valor de custo total,
tal que:
L = R−Vc (4.9)
onde:
L = Lucro Total (R$)
31
5 RESULTADOS E DISCUSSÃO
Este capitulo aborda os módulos desenvolvidos a partir da metodologia aplicada para
o desenvolvimento do sistema de gestão financeira voltado para propriedades de ovinocaprino-
cultores.
5.1 Cadastro e login
A tela inicial de login (Figura 7) deve permitir ao usuário acesso á plataforma
mediante autenticação e a possibilidade de recuperação de senha com link enviado via email
cadastrado para a criação de uma nova senha. A tela de cadastro do sistema (Figura 8) permitirá ao
usuário criar uma conta gratuitamente na plataforma através do seu email e senha e informações
adicionais como cidade e estado do usuário. O acesso pode ser opcionalmente armazenado no
cache da aplicação permitindo ao usuário manter os dados da sessão para uso em computadores
pessoais e não compartilhados. Ao acessar novamente a tela inicial enquanto os dados de
autenticação estão armazenados em cache o usuário será automaticamente redirecionado para a
seleção de propriedades (Figura 9).
Figura 7 – Tela de login.
Fonte: elaborado pelo autor (2021)
32
Figura 8 – Tela de cadastro de usuário.
Fonte: elaborado pelo autor (2021)
5.2 Seleção e cadastro de propriedade.
Após autenticação, serão exibidas todas as propriedades associadas ao usuário,
bem como um botão de cadastro de uma nova propriedade onde serão informadas todas as
características da propriedade (Figura 10).
Figura 9 – Tela de seleção de propriedade.
Fonte: elaborado pelo autor (2021)
33
Figura 10 – Tela de cadastro de propriedade.
Fonte: elaborado pelo autor (2021)
5.3 Cadastro de rebanho
A tela de cadastro do rebanho (Figura 11) permite informar as características essen-
ciais para o manejo do rebanho e também informações sobre indivíduos agrupados em categorias
(matriz, reprodutor, fêmea em lactação, macho em lactação, fêmea jovem, macho jovem, fêmea
adulta, macho adulto). É permitido ao usuário o cadastro de múltiplos animais dentro de um
mesmo rebanho onde todas as modificações futuras em um rebanho serão propagadas à todos os
indivíduos pertencentes ao rebanho.
5.4 Cadastro de informações adicionais da propriedade
A tela da Figura 12 permite ao usuário cadastrar informações adicionais da proprie-
dade como o tipo de vegetação forrageira; i.e., plantações utilizadas para a alimentação animal ou
outras atividades agropecuárias como bovinos, avinos, suínos, etc. Também pode ser informado
um inventário ou estrutura da propriedade que atua como um investimento financeiro dentro da
propriedade cujos valores impactam no cálculo dos indicadores.
5.5 Dashboard
O dashboard (Figuras 13a e 13b) consiste em um painel de informações rápidas onde
o usuário poderá ter uma visão geral da sua propriedade, com gráficos que tratam das finanças,
34
Figura 11 – Tela de cadastro de rebanho.
Fonte: elaborado pelo autor (2021)
Figura 12 – Tela de informações adicionais da propriedade.
Fonte: elaborado pelo autor (2021)
listagem dos últimos lançamentos realizados e exibição dos indicadores da propriedade. É
permitido ao usuário que seja feito uma filtragem anual e por rebanho das informações do painel.
O acesso às operações cotidianas como realizar novos lançamentos financeiros, de rebanho, bem
como atualizá-las e gerar relatórios estão disponíveis a partir desta tela.
35
Figura 13 – Tela de dashboard.
(a) Botões de lançamentos, gráfico de despesas e informações de indicadores.
(b) Gráfico de acompanhamento de finanças, informações de indicadores e listagem de lançamentos
financeiros.
Fonte: elaborado pelo autor (2021)
5.6 Lançamentos financeiros
Tanto a partir do dashboard quanto do menu de finanças (Figura 14) é possível lançar
uma despesa (Figura 15a), receita (Figura 15b) ou investimento (Figura 15c), cada lançamento é
bastante similar onde é possível informar uma categoria, data, produto ou serviço, quantidade,
valor e alguma descrição opcionalmente. Também é permitido que um lançamento financeiro
tenha associação direta com um rebanho, no exemplo da Figura 15a, são exibidos os rebanhos
36
cadastrados onde o usuário pode selecionar a quais rebanhos deseja direcionar a despesa e
informar uma porcentagem que será aplicada a um rebanho, com isso será possível fragmentar a
informação de um lançamento por rebanho onde, por exemplo, um lançamento de R$100 alocado
50% para um Rebanho A e 50% para um Rebanho B criará uma associação com um lançamento
de R$50 para ambos.
Figura 14 – Acompanhamento de Finanças.
Fonte: elaborado pelo autor (2021)
Figura 15 – Tela de lançamentos financeiros.
(a) Lançamento de despesa. (b) Lançamento de receita. (c) Lançamento de investimento.
Fonte: elaborado pelo autor (2021)
37
6 CONCLUSÕES E TRABALHOS FUTUROS
Os módulos do sistema foram completamente desenvolvidos aplicando as tecnologias
descritas neste trabalho sob acompanhamento e validação da equipe técnica da EMBRAPA com
o foco de atingir os objetivos descritos e permitir que este sistema seja utilizado por pequenos e
médios produtores de ovinocaprinocultura, atingindo um grau de maturidade do sistema como um
de Produto Mínimo Viável (MVP). Ao longo deste trabalho muito conhecimento foi adquirido
no que diz respeito à arquiteturas modernas de sistemas web como a estruturação de uma API
REST, contêineres Docker, versionamento com Git e CD com o Github.
Como possíveis melhorias para trabalhos futuros pode-se elencar:
• Permitir georreferenciamento da propriedade;
• Extensão para outros tipos de rebanhos;
• Criação de cronogramas e agendamentos de eventos do rebanho e financeiro.
38
REFERÊNCIAS
BATURAY, M. H.; BIRTANE, M. Responsive web design: A new type of design for web-based
instructional content. Procedia - Social and Behavioral Sciences, v. 106, p. 2275–2279, 2013.
ISSN 1877-0428. 4th International Conference on New Horizons in Education. Disponível em:
<https://www.sciencedirect.com/science/article/pii/S1877042813048829>.
COMPUTERSCIENCE.ORG. Computer Programming Languages. 2021. Disponível em:
<https://www.computerscience.org/resources/computer-programming-languages>. Acesso em:
04 dez. 2021.
DATE, C. J. Introdução à sistemas de Bancos de Dados. Upper Saddle River, NJ, USA:
Elsevier, 2003.
DOCKER. What is a Container? 2021. Disponível em: <https://www.docker.com/resources/
what-container>. Acesso em: 17 dez. 2021.
EVEREST, G. C. Basic data structure models explained with a common example.
Proceedings Fifth Texas Conference on Computing Systems, IEEE Computer
Society Publications Office, Long Beach, CA, USA, 1976. Disponível em: <https:
//geverest.umn.edu/home/papers-and-publications>.HADDAD, P. R. A competitividade do agronegocio e o desenvolvimento regional no Brasil
: estudo de cluster. Brasília, DF: CNPq, Embrapa, 1999.
JACKSON, J. C. Web Technologies - A computer science perspective. Upper Saddle River,
NJ, USA: Pearson Prentice Hall, Duquesne University, 2007.
LOCATEL, C.; CHAPARRO, J. Panorama de la agricultura informatizada en brasil. Scripta
Nova, Revista Electrónica de Geografía y Ciencias Sociales, Universidad de Barcelona., VIII,
n. 170, p. 17, 2004.
MOZILLA, M. D. N. JavaScript. 2021. Disponível em: <https://developer.mozilla.org/pt-BR/
docs/Web/JavaScript>. Acesso em: 12 dez. 2021.
NOGUEIRA, A. F. N.; YAMAMOTO, A.; FIGUEIREDO, C. A. Panorama atual da
caprino-ovinocultura nordestina. Informe Rural ETENE/BNB, 2008.
REENSKAUG, T. The model-view-controller (mvc) its past and present. Oslo, NOR, 2003.
ZHU, R. From MVC to Modern Web Frameworks. 2018. Disponível em: <https:
//medium.com/hackernoon/from-mvc-to-modern-web-frameworks-8067ec9dee65>. Acesso em:
12 dez. 2021.
https://www.sciencedirect.com/science/article/pii/S1877042813048829
https://www.computerscience.org/resources/computer-programming-languages
https://www.docker.com/resources/what-container
https://www.docker.com/resources/what-container
https://geverest.umn.edu/home/papers-and-publications
https://geverest.umn.edu/home/papers-and-publications
https://developer.mozilla.org/pt-BR/docs/Web/JavaScript
https://developer.mozilla.org/pt-BR/docs/Web/JavaScript
https://medium.com/hackernoon/from-mvc-to-modern-web-frameworks-8067ec9dee65
https://medium.com/hackernoon/from-mvc-to-modern-web-frameworks-8067ec9dee65
	Folha de rosto
	Resumo
	Abstract
	Lista de Símbolos
	Sumário
	Introdução
	Objetivos
	Objetivo Geral
	Objetivos Específicos
	Tecnologias web
	Modelo cliente-servidor
	Linguagem de Programação
	Node.js
	Framework
	Arquitetura MVC
	Responsividade, UI e UX
	Banco de Dados
	PostgreSQL e ORM
	Docker
	Git e Github
	Trabalhos Relacionados
	Metodologia
	Módulos do sistema
	Usuários
	Propriedades
	Rebanho
	Finanças
	Indicadores
	Custo Operacional Efetivo
	Depreciações
	Custo Operacional Total
	Remuneração do Capital
	Custo Total
	Receita Bruta
	Margem de Lucro Bruta
	Margem de Lucro Líquida
	Lucro Total
	Resultados e Discussão
	Cadastro e login
	Seleção e cadastro de propriedade.
	Cadastro de rebanho
	Cadastro de informações adicionais da propriedade
	Dashboard
	Lançamentos financeiros
	Conclusões e Trabalhos Futuros
	REFERÊNCIAS