UNIVERSIDADE FEDERAL RURAL DO SEMI-ÁRIDO

PRÓ-REITORIA DE GRADUAÇÃO
DEPARTAMENTO DE ENGENHARIAS E TECNOLOGIA
CURSO DE GRADUAÇÃO INTERDISCIPLINAR EM TECNOLOGIA DA
INFORMAÇÃO

LEONARDO INÁCIO GUILHERME DANTAS

DESENVOLVIMENTO BACK-END DE UM SERVIÇO WEB UTILIZANDO DJANGO

REST FRAMEWORK PARA O GERENCIAMENTO DE HORÁRIOS DAS TURMAS
DO CURSO DE BACHARELADO EM TECNOLOGIA DA INFORMAÇÃO DO
CENTRO MULTIDISCIPLINAR DE PAU DOS FERROS DA UFERSA

PAU DOS FERROS

2023
 LEONARDO INÁCIO GUILHERME DANTAS

DESENVOLVIMENTO BACK-END DE UM SERVIÇO WEB

UTILIZANDO DJANGO REST FRAMEWORK PARA O
GERENCIAMENTO DE HORÁRIOS DAS TURMAS DO CURSO
DE BACHARELADO EM TECNOLOGIA DA INFORMAÇÃO
DO CENTRO MULTIDISCIPLINAR DE PAU DOS FERROS DA
UFERSA

Monografia apresentada à Universidade Federal

Rural do Semi-Árido como requisito parcial
para obtenção do título de Bacharel em Interdis-
ciplinar em Tecnologia da Informação.

Orientador: Prof. Dr. Ítalo Augusto Souza de

Assis - UFERSA

PAU DOS FERROS

2023
© Todos os direitos estão reservados a Universidade Federal Rural do Semi-Árido. O conteúdo desta obra é de inteira
responsabilidade do (a) autor (a), sendo o mesmo, passível de sanções administrativas ou penais, caso sejam infringidas as leis
que regulamentam a Propriedade Intelectual, respectivamente, Patentes: Lei n° 9.279/1996 e Direitos Autorais: Lei n°
9.610/1998. O conteúdo desta obra tomar-se-á de domínio público após a data de defesa e homologação da sua respectiva
ata. A mesma poderá servir de base literária para novas pesquisas, desde que a obra e seu (a) respectivo (a) autor (a)
sejam devidamente citados e mencionados os seus créditos bibliográficos.

D192d Dantas, Leonardo Inácio Guilherme.

Desenvolvimento back-end de um serviço web
utilizando Django Rest Framework para o
gerenciamento de horários das turmas do curso de
Bacharelado em Tecnologia da Informação do Centro
Multidisciplinar de Pau dos Ferros da Ufersa /
Leonardo Inácio Guilherme Dantas. - 2023.
39 f. : il.

Orientador: Ítalo Augusto Souza de Assis.

Monografia (graduação) - Universidade Federal
Rural do Semi-árido, Curso de Tecnologia da
Informação, 2023.

1. Conflitos de Horários. 2. Desenvolvimento

Web. 3. Programação Back-end. 4. Django Rest
Framework. 5. API. I. Assis, Ítalo Augusto Souza
de, orient. II. Título.

Ficha catalográfica elaborada por sistema gerador automáto em conformidade

com AACR2 e os dados fornecidos pelo) autor(a).
Biblioteca Campus Pau dos Ferros
Bibliotecária: Erlanda Maria Lopes da Silva
CRB: 15/966

O serviço de Geração Automática de Ficha Catalográfica para Trabalhos de Conclusão de Curso (TCC´s) foi desenvolvido pelo Instituto
de Ciências Matemáticas e de Computação da Universidade de São Paulo (USP) e gentilmente cedido para o Sistema de Bibliotecas
da Universidade Federal Rural do Semi-Árido (SISBI-UFERSA), sendo customizado pela Superintendência de Tecnologia da Informação
e Comunicação (SUTIC) sob orientação dos bibliotecários da instituição para ser adaptado às necessidades dos alunos dos Cursos de
Graduação e Programas de Pós-Graduação da Universidade.
 LEONARDO INÁCIO GUILHERME DANTAS

DESENVOLVIMENTO BACK-END DE UM SERVIÇO WEB UTILIZANDO DJANGO REST

FRAMEWORK PARA O GERENCIAMENTO DE HORÁRIOS DAS TURMAS DO CURSO
DE BACHARELADO EM TECNOLOGIA DA INFORMAÇÃO DO CENTRO
MULTIDISCIPLINAR DE PAU DOS FERROS DA UFERSA

Monografia apresentada à Universidade Federal

Rural do Semi-Árido como requisito parcial
para obtenção do título de Bacharel em Interdis-
ciplinar em Tecnologia da Informação.

Aprovada em: 03/04/2024

BANCA EXAMINADORA

Prof. Dr. Ítalo Augusto Souza de Assis (Orientador)

UFERSA

Prof. Dr. Alysson Filgueira Milanez

UFERSA

Prof. Dr. Demétrios Araújo Magalhães Coutinho

IFRN
Dedico este trabalho aos meus pais, Jacinta e
Inácio, aos meus irmãos, Luan e Lucas, que
sempre me incentivaram.
 AGRADECIMENTOS

Primeiramente, quero agradecer a Deus por me proporcionar forças para chegar até
aqui; me abençoando e trazendo energia e juízo para me manter firme naquilo que é importante e
necessário para superar todos os desafios durante essa fase.
À minha família, expresso tamanha gratidão, em especial, aos meus pais, minha
mãe Jacinta Guilherme e meu pai Inácio Dantas, aos meus irmãos, Luan Guilherme e Lucas
Guilherme, por todos os incentivos, além de toda paciência e compreensão nos momentos mais
difíceis. Por sempre acreditarem em mim, muito obrigado!
Agradeço de coração aos meus amigos que iniciaram essa jorgada junto comigo,
Lívia, Geísa, Pedro e Tiago. O início foi um período difícil para todos, em meio a uma pandemia,
iniciar uma carreira acadêmica não foi fácil, mas com a presença dessas pessoas, as coisas
ficaram bem mais fáceis em meio a tanta risada. Não tenho palavras para expressar e agradecer
a companhia e carinho de vocês até hoje, sempre serei grato a todos vocês. Aos amigos que
conheci durante esses últimos anos, vocês foram e são muito importantes para mim hoje. Mesmo
diante de todas as brincadeiras e covardias, esses últimos anos foram sensacionais, tudo o que
aconteceu não poderia ter sido melhor se fosse planejado.
Meu muito obrigado ao meu orientador e professor Ítalo Augusto, que me ofereceu
a oportunidade de participar do desenvolvimento desse trabalho e sistema. Por não medir
esforços para me auxiliar sempre que necessário, mesmo diante de tamanhas dificuldades,
compreendendo-as e me guiando para o melhor caminho.
Também gostaria de agradecer a todos os professores que contribuíram de alguma
forma com seus ensinamentos para o desenvolvimento desse trabalho, em especial: Alysson
Milanez e Walber José.
 EPÍGRAFE

“No fundo do inconsciente humano existe a necessidade generalizada de um universo

lógico que faça sentido. Mas o universo real está sempre um passo além da lógica.”
(Frank Herbert)
 RESUMO

Este trabalho propõe o desenvolvimento de um sistema web back-end para o gerenciamento da

grade de horários do curso de Tecnologia da Informação (BTI) do Centro Multidisciplinar de Pau
dos Ferros da Universidade Federal Rural do Semi-Árido (UFERSA). Atualmente, a coordenação
enfrenta constantes desafios para realizar a criação da grade de horários do curso. O método
atual faz uso manual de planilhas eletrônicas e requer grande esforço para ser executado por
parte da coordenação. O problema recorrente nesse modelo é dado pela constante necessidade
de realizar análises dos horários, a fim de evitar possíveis conflitos. Portanto, este trabalho tem
como objetivo desenvolver uma aplicação web que forneça um meio eficiente para substituir
o método ultrapassado e problemático utilizado. O desenvolvimento do sistema utilizou as
metodologias de desenvolvimento dos modelos clássicos conhecidos na engenharia de software,
em especial, o modelo incremental. Realizando o levantamento e análise dos requisitos, seguido
da elaboração do projeto, implementação, realização dos testes de software e finalizando com a
implantação e distribuição do sistema. Com a execução dos testes, constatou-se que os requisitos
elencados para a resolução dos problemas estão presentes e funcionando conforme o esperado.

Palavras-chave: Conflitos de horários. Desenvolvimento web. Programação back-end. Django

Rest Framework. API.
 ABSTRACT

This work proposes the development of the back-end of a web system for managing the class
schedule of the Tecnologia da Informação (BTI) course at Centro Multidisciplinar de Pau dos
Ferros (CMPF) of the Universidade Federal Rural do Semi-Árido (UFERSA). Currently, the
coordination faces constant challenges in creating the class schedule. The current method invol-
ves the manual use of spreadsheets and requires significant effort from the coordination. The
recurring problem in this model is the constant need to analyze schedules to avoid possible
conflicts. Therefore, this work aims to develop a web application that provides an efficient way to
replace the outdated and problematic methods used. The development of the system used metho-
dologies from the classical models known in software engineering, especially the incremental
model. It involved the elicitation and analysis of requirements, followed by project development,
implementation, software testing, and ending with system deployment and distribution. Through
the execution of tests, it was verified that the requirements listed for solving the problems are
present and functioning as expected.

Keywords: Schedule conflicts. Web development. Backend programming. Django Rest

Framework. API.
 LISTA DE FIGURAS

Figura 1 – Modelos Utilizados na Criação de Ambientes em Nuvem . . . . . . . . . . 22

Figura 2 – Diagrama de Classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Figura 3 – Diagrama ER. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Figura 4 – Modelo Cascata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Figura 5 – Arquitetura em Nuvem de Implantação . . . . . . . . . . . . . . . . . . . . 32
Figura 6 – Casos de Teste Utilizando Unittest . . . . . . . . . . . . . . . . . . . . . . 35
Figura 7 – Resultados dos Testes com Unittest . . . . . . . . . . . . . . . . . . . . . . 35
Figura 8 – Falha do Método Patch de Componente Curricular . . . . . . . . . . . . . . 36
 LISTA DE ABREVIATURAS E SIGLAS

Abcomm Associação Brasileira de Comércio Eletrônico

ACM AWS Certificate Manager
API Application Programming Interface
AWS Amazon Web Services
BTI Bacharelado em Tecnologia da Informação
CMPF Centro Multidisciplinar Pau dos Ferros
DNS Domain Name System
DRF Django Rest Framework
ECR Elastic Container Registry
ECS Elastic Container Service
ER Entity-Relationship
HTTP Hypertext Transfer Protocol
HTTPS Hypertext Transfer Protocol Secure
IDE Integrated Development Environment
RDS Relational Database Service
Rest Representational State Transfer
SGBD Sistema Gerenciamento de Banco de Dados
SOAP Simple Object Access Protocol
UFERSA Universidade Federal Rural do Semi-Árido
UML Unified Modeling Language
URI Uniform Resource Identifier
VPC Virtual Private Cloud
W3C World Wibe Web Consortium
WWW World Wide Web
XML Extensible Markup Language
 SUMÁRIO

1. INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

1.1 Problematização . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

1.2 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

1.2.1 Objetivo Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

1.2.2 Objetivos Específicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

1.3 Justificativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

1.4 Organização do trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2. REVISÃO TEÓRICA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.1 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.2 Desenvolvimento de sistemas web . . . . . . . . . . . . . . . . . . . . . . . . 16

2.3 Arquitetura Rest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.4 Teste de Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.5 Ferramentas e Tecnologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3. METODOLOGIA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.1 Elicitação e Análise de requisitos . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.2 Projeto do sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.3 Implementação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.4 Testes de Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.5 Implantação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4. ANÁLISE DO GERENCIADOR DE HORÁRIOS . . . . . . . . . . . . . . . . . 34

4.1 Resultados dos testes de unidade . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.2 Resultados dos testes de integração . . . . . . . . . . . . . . . . . . . . . . . 35

5. CONCLUSÕES E TRABALHOS FUTUROS . . . . . . . . . . . . . . . . . . . . 37

REFERÊNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
 12

1 INTRODUÇÃO

A evolução da tecnologia viabilizou inúmeros avanços em uma vasta gama de setores,

criando e melhorando métodos que antes eram executados de maneiras diversas (OwInteractive,
2023). Dessa forma, com o surgimento da internet, os meios de comunicação passaram por
uma revolução, possibilitando a criação e desenvolvimento de sistemas web. Atualmente, esses
sistemas desempenham um papel fundamental na vida das pessoas e empresas, concedendo um
ótimo meio para divulgação e gerenciamento de processos na área da saúde e educação.
O processo de gerenciamento dos horários das turmas em universidades tem como base,
principalmente, suas regras e normas. Isso inclui também considerar a disponibilidade de
componentes curriculares e professores para serem alocados nos horários disponíveis. Em meio
a um cenário que busca evitar conflitos e inconsistências o máximo possível, o ato de verificar
e concluir a distribuição dos horários em uma grade de horário pode ser caracterizada como
problema de natureza combinatorial (Kripka; Kripka; Oro, 2007), na qual a ordem de distribuição
dos horários das turmas é relevante.
O modelo de gerenciamento das grades de horários do curso de Bacharelado em Tecnolo-
gia da Informação (BTI) do Centro Multidisciplinar Pau dos Ferros (CMPF) da Universidade
Federal Rural do Semi-Árido (UFERSA) utiliza um método ineficiente para realizar uma tarefa
feita periodicamente. Tendo como base a utilização de planilhas eletrônicas, o coordenador,
de forma manual, realiza o ato de cadastrar e atribuir um horário a cada turma. Este modelo
abre brecha para falhas humanas, em um cenário onde o coordenador dispõe de uma grande
quantidade de dados na etapa de verificação e correção dos conflitos de horários.
Diante disso, o presente trabalho tem como proposta o desenvolvimento de um sistema
web back-end para tornar o gerenciamento da grade de horários do curso de BTI mais rápido
e eficiente. A principal proposta deste sistema é a automação do processo mais exaustivo no
gerenciamento da grade de horário, a análise e verificação dos conflitos de horários. Além disso,
a fim de evitar falhas no momento de cadastro e duplicidade de dados, a aplicação é capaz de
realizar a verificação e validação de todos os elementos que compõem a solução.

1.1 Problematização

A cada semestre, o processo de planejamento, criação e gerenciamento da grade de

horários do curso de BTI se repete na UFERSA. Ele é realizado pela coordenação do curso de
 13

forma manual com o uso de planilhas eletrônicas, o que o torna um serviço árduo, desgastante e
bastante ineficiente, ao ponto de levar semanas para ser concluído.
De modo geral, a criação da grade de horários leva em consideração, de forma central,
fatores definidos previamente pela universidade, como também a ausência de conflitos e incon-
sistências entre os horários das turmas cadastradas. Esses conflitos são derivados principalmente
de um professor que está com várias turmas de componentes curriculares distintos cadastradas
no mesmo horário, ou de turmas de componentes curriculares diferentes do mesmo semestre,
cadastradas com o mesmo horário.
Além dos fatores mencionados, o trabalho manual e repetitivo de inserir e editar turmas
em suas respectivas grades está sujeito principalmente a falhas humanas. Já que conforme
o número de dados aumenta, realizar a verificação de cada carga horária de docentes ou da
consistência de dados, para evitar duplicidade e inconsistência, acaba se tornando uma tarefa
difícil para o coordenador.
Analisando essas causas, é evidente que, à medida que o número de turmas cadastradas
aumenta, o trabalho do coordenador se torna cada vez mais exaustivo, em consequência da
necessidade de verificar e validar ainda mais turmas. Tal fato torna a construção das grades de
horários livre de conflitos e inconsistências uma atividade complexa.

1.2 Objetivos

Nesta seção, é apresentado o objetivo geral e os objetivos específicos deste trabalho de

conclusão de curso.

1.2.1 Objetivo Geral

O objetivo geral desse trabalho consiste no desenvolvimento back-end de um serviço

web, para auxiliar e agilizar o processo de gerenciamento das grades de horários. O sistema
tem o propósito de substituir planilhas eletrônicas usadas pela coordenação do curso de BTI na
UFERSA a cada semestre. Assim, deseja-se fornecer, de forma rápida e clara, uma maneira de
analisar, verificar e validar os problemas da criação das grades de horário, decorrentes desse
processo.
 14

1.2.2 Objetivos Específicos

Tomando como base o objetivo geral deste trabalho, os objetivos específicos a seguir
foram criados:
• Levantar e analisar os requisitos conforme as necessidades do cliente;
• Realizar a modelagem do software utilizando diagramas da Unified Modeling Language
(UML), tomando como base aspectos estruturais e comportamentais do sistema;
• Implementar o sistema web para o gerenciamento de grades de horários;
• Efetuar testes na aplicação desenvolvida;
• Disponibilizar o sistema para uso por parte do cliente.

1.3 Justificativa

Em um estudo para otimizar a distribuição de cargas horárias na universidade de Passo

Fundo–RS, publicado em uma revista científica de administração chamada Gestão (UFFC, 2009),
foi analisado que lidar com a combinação de uma quantidade considerável de dados estará
sempre sujeita a complicações e erros humanos (Kripka; Kripka; Oro, 2007). Esse cenário é mais
agravante quando o trabalho é realizado de forma manual e requer semanas para ser executado.
Atualmente, o trabalho realizado pela coordenação do curso de BTI para gerenciar os
horários das turmas é feito de forma manual com o auxílio de planilhas eletrônicas. Nesse
processo de gerenciamento, o coordenador verifica se os docentes da turma possuem horário
disponível em sua agenda para lecionar a turma, como também verifica se o docente possui carga
horária disponível para ser cadastrado na turma. Além dessas verificações, existe a necessidade
de verificar cada turma quando outra é cadastrada a fim de evitar conflitos. Ao final de todas essas
verificações e validações na planilha, a chance de haver alguma inconsistência e duplicidade de
dados aumenta quanto mais o trabalho for exaustivo.
Diante desse cenário, a utilização de um sistema que auxilie o tratamento dessa massa de
dados traria consigo inúmeros benefícios tanto à coordenação quanto à própria universidade. Já
que o tempo ganho por parte da coordenação do curso com o uso do sistema poderia ser utilizado
no desenvolvimento de outras atividades.
Além disso, com a utilização e aceitação do sistema por parte dos usuários, o mesmo
poderá ser utilizado por coordenações de outros cursos do CMPF e, até mesmo, de outros
campi da instituição. Essa mudança vai tornar o trabalho de gerenciar os horários mais simples,
 15

deixando-o de ser exaustivo/improdutivo.

Então, são evidentes os inúmeros benefícios que a utilização de um sistema gerenciador
os horários proporcionará à instituição, facilitando, minimizando e lidando diretamente com os
principais problemas na criação das grades de horários, conflitos e inconsistência de dados.

1.4 Organização do trabalho

Portanto, este documento está organizado da seguinte forma. No Capítulo 2 há o referen-

cial teórico contendo os principais termos e conceitos utilizados no confecção deste trabalho. O
Capítulo 3 apresenta as metodologias utilizadas para desenvolver e solucionar o problema desse
trabalho. No Capítulo 4 são apresentados os resultados, contendo a análise da execução dos
testes de software. Por fim, no Capítulo 5 são apresentadas as considerações finais e os possíveis
trabalhos futuros.
 16

2 REVISÃO TEÓRICA

Nesse capítulo, serão apresentados conceitos e tecnologias fundamentais para uma

melhor compreensão acerca deste trabalho. Na seção 2.1, é contextualizado o que são softwares
e por que são desenvolvidos, após, na seção 2.2, é descrito um pouco sobre a internet e seus
impactos no desenvolvimento de sistemas, na seção 2.3 são apresentados conceitos sobre a
arquitetura Representational State Transfer (Rest) utilizada no desenvolvimento de web services,
avançando para seção 3.4, é demonstrado o que são testes de software e sua importância durante
o desenvolvimento, por fim, na seção 2.5 é falado sobre as ferramentas e tecnologias utilizados
no desenvolvimento desse trabalho.

2.1 Software

Um produto abstrato e intangível, independente das leis da física e sem limites naturais
para a evolução, é como os softwares são definidos (Sommerville, 2011). Essas características
concedem aos sistemas de softwares um nível de complexidade maior para concluir seu desenvol-
vimento. De forma geral, softwares são desenvolvidos para executar instruções visando resolver
problemas de forma tecnológica, rápida e eficiente.
Segundo Pressman e Maxim (2016), a engenharia de software, ciência que estuda a
aplicação dos princípios de engenharia no desenvolvimento de softwares, é uma tecnologia
construída em camadas, onde todas abordagens, processos, métodos e ferramentas adotados
possibilitam que as pessoas desenvolvam um software com qualidade de formas diferentes. Desse
modo, não existe apenas um método ou processo para o desenvolvimento correto de software,
mas sim, aquele que melhor se encaixa para determinadas situações (Bezerra, 2007).
Atualmente, os softwares são vistos como elementos fundamentais na integração global
de pessoas, empresas e organizações. Eles assumiram esse papel ao se tornarem veículos
poderosos para distribuição de produtos, os caracterizando como um meio globalizado para a
transmissão de informação (Pressman; Maxim, 2016).

2.2 Desenvolvimento de sistemas web

A internet, como hoje é conhecida, nasceu a partir da proposta de Tim Berners-Lee,

um cientista da computação em 1989, onde a internet, baseada na utilização de hiperlinks, era
empregada para exibir conteúdos estáticos para seus colegas de sala. A partir disso, a internet
 17

evoluiu tanto ao ponto de ser definida como um aglomerado de redes conectadas entre si ao redor
do planeta terra (UFPE, 1997).
A medida que o nível de complexidade dos sistemas web crescia, a abordagem mono-
lítica de comunicação ponto a ponto, onde os sistemas estavam conectados entre si, se tornou
ultrapassada e limitada para aquele momento (Newman, 2019). Tal deficiência impossibilitava a
escalabilidade e gerenciamento das redes de comunicação. Então, a arquitetura Cliente-Servidor
(CS) surgiu para lidar com o aumento crescente do tráfego de dados na internet. A arquitetura
CS gerencia os recursos da internet de maneira centralizada, onde um servidor irá fornecer os
serviços para atender as requisições dos clientes (Grandi, 1996).
Junto às novas arquiteturas, surgiram métodos e tendências de desenvolvimento que
contribuíram para o declínio de arquiteturas monolíticas. Um desses métodos foi a separação
do desenvolvimento entre front-end e back-end de sistemas, trazendo consigo escalabilidade,
flexibilidade e manutenibilidade para aplicações (Newman, 2019). Nessa abordagem, o front-end
desenvolve a interface do usuário (Cliente), enquanto o back-end é responsável pela lógica
interna do sistema (Servidor) (Erse, 2021).
Como foco do desenvolvimento desse trabalho, o back-end pode abranger diferentes
aspectos na engenharia de software: elaboração da estrutura (modelagem); implementação lógica
para resolver o que sistema se propõe; configuração de armazenamento de dados para o cliente,
dentre muitos outros (Erse, 2021).
Com o avanço tecnológico, a internet ganhou grande popularidade, ao ponto de que hoje
está presente na vida cotidiana de cerca de 66% da população mundial (KEMP, 2024). Com isso,
empreender e gerar engajamento na internet se tornou cada vez mais comum entre as pessoas, é o
que mostra os dados da Associação Brasileira de Comércio Eletrônico (Abcomm). Fazendo com
que o e-commerce no Brasil obtivesse um crescimento significativo no ano de 2015, persistindo
até meados de 2022, onde cerca de R$ 169 bilhões foram faturados com e-commerce.

2.3 Arquitetura Rest

Proposto por Roy Fielding, o modelo arquitetural Rest tem como fundamento os padrões
aplicados no desenvolvimento de web services. Conforme definida pela World Wibe Web
Consortium (W3C)1 , web services são sistemas construídos a fim de apoiar diretamente as
interações entre sistemas distribuídos na rede.
1 https://www.w3.org
 18

De acordo com Pautasso, Zimmermann e Leymann (2008), os fundamentos das web

services buscam identificar recursos, manipulá-los e representá-los, a partir do uso de Uniform
Resource Identifier (URI), Hypertext Transfer Protocol (HTTP) e Extensible Markup Language
(XML). Visto que, com intensa presença de sistemas distribuídos na web, esses elementos
se tornaram essenciais para a comunicação, permitindo a interoperabilidade entre diferentes
plataformas (Oliveira, 2012).
Comumente utilizada na construção de Application Programming Interfaces (APIs) (um
meio que permite que os softwares se comuniquem com outros), a arquitetura Rest facilita
e agiliza o processo de desenvolvimento, além de permitir a transmissão de informação com
rapidez para outros sistemas mediante um ponto de acesso ou um endereço específico em um
serviço web, conhecido como endpoints (Lei et al., 2020). Apesar de ser uma abstração da
arquitetura World Wide Web (WWW), o Rest não faz o uso rigoroso da padronização verbosa da
arquitetura Simple Object Access Protocol (SOAP), priorizando a utilização de protocolos mais
otimizados para uma melhor transmissão (Oliveira, 2012).

2.4 Teste de Software

Conforme o relatório divulgado pela Statista2 , apesar do declínio no ano 2020, em

decorrência da pandemia, o mercado global da indústria de software continuará a crescer de
forma estável nos próximos anos. Então, à medida que a procura de softwares aumenta, por
partes de empresas e usuários, cada vez mais softwares serão desenvolvidos e, aqueles escolhidos,
serão os que apresentam uma melhor qualidade perante os outros (Miguel; Mauricio; Rodríguez,
2014).
Como mencionado anteriormente, softwares são produtos complexos de serem desen-
volvidos e estão suscetíveis a falhas e erros humanos ou computacionais. Com base nisso, a
etapa de teste durante o desenvolvimento de um software é um passo fundamental e necessário
para revelar a presença de erros e defeitos (Sommerville, 2011), possibilitando sua correção e,
consequentemente, melhorando a sua qualidade.
Erros podem aparecer no início ou ao final do projeto, derivados da má implementação
de uma função no código, da falha de comunicação entre processos ou de pessoas no momento
do desenvolvimento (Delamaro; Jino; Maldonado, 2013). A depender do momento em que esses
erros são identificados, o custo para corrigi-los pode ser desastroso para empresas.
2 www.statista.com/topics/1694/app-developers/
 19

Com base nisso, a fase de teste é de suma importância na identificação e possível correção
de uma boa parcela de erros antes que o produto seja entregue a seu cliente (Pressman; Maxim,
2016). Apesar disso, nenhum software está livre de erros, pois além do processo de desenvolver
um software ser complexo, a etapa de teste não garante a ausência total de erros.
Segundo GonÇalves (2019), a execução de testes deve ser feita em todos os estágios do
ciclo de vida de uma aplicação para um melhor aproveitamento. Dessa forma, os testes podem
ser divididos entre cinco fases, unidade, integração, aceitação, sistema e regressão. Cada fase
de teste é aplicada em diferentes estágios do desenvolvimento do projeto, a fim de garantir que
todos os âmbitos do sistema foram testados.
Dentre as cinco fases, vale destacar três delas, fundamentais para garantir a qualidade de
um sistema de software. A primeira fase diz respeito aos testes de unidade, eles buscam identificar,
principalmente, erros de programação, visto que seu foco é realizar testes nas menores unidades
do sistema, métodos e funções. Após as unidades testadas, é realizado o teste da execução da
interligação no sistema dessas unidades, chamado de teste de integração. Os testes de integração
visam verificar se, após a junção das unidades, o funcionamento persistiu correto. Por fim, é
efetuado o teste de sistema, onde a aplicação com todas as partes integradas é testada. Nessa
última fase, os testes certificam que os requisitos levantados foram realmente atendidos na
execução do sistema, levando em consideração a visão do usuário (Delamaro; Jino; Maldonado,
2013).
Apesar do processo de fasear a realização de teste durante o desenvolvimento facilite a
identificação de erros, a sua execução sem elaboração de bons casos de testes não será eficaz
(Pressman; Maxim, 2016), uma vez que será necessário executar mais testes. Partindo desse
ponto, casos de teste são projetados para tornar a tarefa criar e executar os testes mais eficientes,
uma vez que casos de testes bem projetados podem detectar ainda mais erros com menos esforço
(Delamaro; Jino; Maldonado, 2013).
A construção de casos de testes pode ser feita utilizando critérios ou técnicas como
Particionamento por Equivalência e Análise do Valor Limite, mas não se resume a só elas, como,
por exemplo, grafo de causa-efeito, tabela de decisão, error guessing e muitos outros. Essas
técnicas são construídas tomando com base a especificação do sistema a ser testado (Delamaro;
Jino; Maldonado, 2013). No entanto, a escolha dos critérios de casos de testes deve ser tomada
com base nas características do objeto de teste, por exemplo, caso o domínio de entrada do campo
testado possua intervalos bem definidos, utilizar o critério de particionamento é ideal, já que ele
 20

divide os grupos de dados em classes de equivalências para explorar todos os intervalos. Já se o

domínio de entrada possuir intervalos bem definidos, a utilização do critério de análise de valor
limite é de interesse, uma vez que explorar as condições limites têm uma maior probabilidade de
encontrar erros, como afirma Delamaro, Jino e Maldonado (2013).

2.5 Ferramentas e Tecnologia

A escolha das ferramentas e tecnologias utilizadas para o desenvolvimento do sistema

apoiou-se na facilidade de uso, manutenibilidade e domínio da ferramenta, além de aspirar um
desenvolvimento ágil com um resultado confiável.
Dentre essas ferramentas e tecnologias estão, o Astah UML (Seção 2.5) uma ferramenta
que auxilia na modelagem de diagramas UML (Astah, 2006), o Django Rest Framework (Seção
2.5) uma biblioteca do framework Django empregue na confecção de APIs utilizando arquitetura
Rest (MkDocs, 2011), na Seção 2.5, há a plataforma para hospedagem de aplicações na nuvem, a
Amazon Web Services (AWS) (AWS, 2006), o Github (Seção 2.5) um sistema de versionamento
de código para controlar as versões da API (GitHub, 2008), o PostgreSQL (Seção 2.5) um
Sistema Gerenciamento de Banco de Dados (SGBD) relacional gratuito (PostgreSQL, 1996)
e por fim, na Seção 2.5, encontra-se o Postmam, uma ferramenta utilizada na colaboração do
desenvolvimento de APIs (Postmam, 2014).

- Astah UML

A etapa de modelagem de uma aplicação é fundamental em qualquer desenvolvimento

de software, pois servirá como base para o desenvolvimento do sistema. Possibilitando obter
uma interpretação do sistema independente da implementação do sistema. O Astah UML3 é uma
variante da ferramenta Astah muito utilizada em modelagens UML (Neto, 2022).
Além de sua simplicidade, o Astah UML conta com um grande catálogo de tipos de
modelagens UML como diagramas de classes, casos de uso, componentes, etc. Com isso, a
ferramenta é de grande ajuda para qualquer desenvolvedor (Neto, 2022).
3 https://astah.net/products/astah-uml/
 21

- Django Rest Framework

A utilização de frameworks se tornou cada vez mais presente em empresas e startups

devido à capacidade e comprometimento em acelerar processos do desenvolvimento de sistemas,
sem prejudicar a qualidade na entrega (Santos; Nagao; Montanha, 2017). Assim, surge o
Django4 , um framework gratuito de código aberto criado em Python, que foca em agilizar
o desenvolvimento de etapas repetitivas, permitindo que desenvolvedores se concentrem em
processos mais complexos.
O Django Rest Framework é uma biblioteca de código aberto que estende as capacidades
do Django, visando simplificar e agilizar a construção de API’s para internet. Ela dispõe de
ferramentas versáteis com arquitetura modular para o desenvolvimento de endpoints, um serviço
acessível via rede de internet (Quintagroup, 2014).

- Amazon Web Services

Comumente conhecida como AWS5 , a Amazon Web Services é uma plataforma de

serviços de computação em nuvem provido pela Amazon. Como provedora de nuvem, a AWS
oferece uma grande variedade de serviços, computação, banco de dados, redes e entrega de
conteúdo, segurança, identidade e conformidade, dentre muitos outros, para diversos fins para
seus clientes. Pensando nisso, a AWS utiliza três modelos de computação em nuvem, como
apresentado na Figura 1. Cada modelo apresenta suas próprias vantagens e desvantagens e são
utilizados para diferentes estilos de arquitetura em sistemas. Tal fato é decorrente da diferença
do nível de controle e responsabilidade que o usuário exerce sobre a arquitetura, onde na Figura
1, aquilo que está em azul é de responsabilidade do usuário e o em vermelho do provedor.
A infraestrutura como serviço (IaaS) é o nível mais baixo de computação em nuvem,
está relacionada com serviços de armazenamento e servidores virtuais, possuindo controle total
sobre os sistemas operacionais e aplicativos (SalmijÄrvi, 2023). Já as Plataformas como serviços
(PaaS) são utilizados, na maioria, para hospedar ou desenvolver softwares que serão utilizados,
permitindo executar e gerenciar aplicações sem necessidade de criar e manter a infraestrutura
(RedHat, 2023). Por fim, os Softwares como serviço (SaaS) são aplicações prontas que os
usuários podem utilizar para resolver determinados problemas (SalmijÄrvi, 2023).
De forma geral, a AWS prioriza a utilização de arquiteturas robustas e práticas operacio-
4 https://www.djangoproject.com
5 https://aws.amazon.com
 22

Figura 1 – Modelos Utilizados na Criação de Ambientes em Nuvem

Fonte: RedHat (2023)

nais que contribuem para a confiabilidade e escalabilidade de seus serviços, conforme os pilares
da AWS Well-Architected6 .

- Relational Database Service (RDS)

Um gerenciador de sistema de armazenamento de dados relacional que promove a

operação e escalabilidade de bancos de dados relacionais na nuvem (AWS, 2009). Ele oferece
suporte a vários tipos de bancos de dados, como MySQL, PostgreSQL, MariaDB, Oracle e
SQL Server, gerenciando tarefas como provisionamento de hardware, aplicação de patches de
6 https://aws.amazon.com/architecture/well-architected/
 23

software, backups automatizados e monitoramento de desempenho.

Por ser um serviço Paas, o usuário pode se concentrar mais no desenvolvimento de
aplicativos e menos na administração de seus bancos de dados, já que AWS cuida de muitas das
tarefas operacionais complexas associadas ao gerenciamento de um banco de dados relacional.

- Elastic Container Registry (ECR)

É um serviço gerenciado pela AWS que facilita o armazenamento, gerenciamento e

implantação de imagens de contêiner Docker. A partir do ECR, é possível realizar a criação
de repositórios privados para armazenar suas imagens de contêiner e controlar o acesso a esses
repositórios com base nas políticas do AWS (AWS, 2015a);

- Elastic Container Service (ECS)

Um serviço de orquestração de contêineres que permite basicamente gerenciar facilmente

imagens Docker armazenadas no ECR, como também, armazenadas em diferentes locais, por
meio de clusters (AWS, 2015b). Com o ECS, é possível criar aplicativos baseados em micros-
serviços altamente disponíveis e escaláveis, além de integrar facilmente a outros serviços da
AWS, como o Amazon ECR, o Elastic Load Balancing, o Amazon Virtual Private Cloud (VPC)
e muito mais (AWS, 2015b).

- Route 53

Um serviço de Domain Name System (DNS), utilizado principalmente na AWS para

gerenciar o tráfego de comunicação de forma rápida e confiável(AWS, 2011). Projetado também
para fornecer resolução de nomes de domínio, com ele é possível registrar nomes de domínio e
associá-los a recursos da AWS ou de fora da AWS, como servidores web, buckets do Amazon
S3, Load Balancers do Elastic Load Balancing e muito mais.

- GitHub

O GitHub é uma plataforma que permite a hospedagem de código, possibilitando ver-

sionar e gerenciar seus projetos utilizando o Git7 . Utilizando GitHub, a colaboração entre
desenvolvedores presentes no repositório se torna mais simplificada e rápida, independente de
7 https://git-scm.com
 24

sua localidade e tamanho do projeto (Batista et al., 2017).

- PostgreSQL

Um SGBD relacional, o PostgreSQL8 é um software gratuito, de código aberto e al-

tamente extensível. Suas origens datam por volta de 1986, em um projeto também chamado
POSTGRES da Universidade da Califórnia em Berkeley. O software é bem flexível, permi-
tindo se adaptar às mais variadas situações com o uso de funções e linguagem de programação
(Mancilla, 2017).

- Postmam

O Postmam9 é uma ferramenta muito utilizada para o desenvolvimento de APIs. Ela

permite criar, compartilhar, testar e documentar suas APIs de forma simples e rápida, além de
possibilitar a elaboração de documentação e de testes automatizados (Westerveld, 2021).
Com o Postman, é possível enviar e testar requisições para serviços web, utilizando
diversos métodos do protocolo HTTP (GET, POST, PUT, PATCH e DELETE), além de visualizar
suas respostas em diferentes formatos, visando realizar o desenvolvimento e o teste das rotas.

8 https://www.postgresql.org
9 https://www.postman.com
 25

3 METODOLOGIA

Neste capítulo, é apresentada a metodologia e o processo para o desenvolvimento back-

end do sistema Gerenciador de Horários. Iniciando com o levantamento e análise dos requisitos
(Seção 3.1) do sistema, seguindo com a construção do projeto (Seção 3.2), incluindo modelos
e diagramas, avançando para a implementação do código-fonte (Seção 3.3) e partindo para
realização dos testes (Seção 3.4) e, ao final, na Seção 3.5, é descrito o processo de implantação e
distribuição do sistema proposto.
Esse serviço web irá utilizar uma interface (front-end) para realização de alguns testes,
essa aplicação front-end está disponível no repositório de versionamento de código10 sob a
licença MIT, facilitando assim a realização de algumas atividades essenciais ao projeto.

3.1 Elicitação e Análise de requisitos

O levantamento dos requisitos é um procedimento no desenvolvimento de sistemas que

busca obter um entendimento comum, entre cliente e desenvolvedores, acerca do problema a ser
resolvido (Bezerra, 2007). Pensando nisso, a fim de garantir uma boa compreensão do sistema,
foram realizadas reuniões em conjunto à coordenação do curso de BTI. Essas reuniões foram
registradas em um documento a fim recolher as ideias e opiniões dos clientes sobre o sistema.
Após a realização das reuniões, o documento de requisitos foi moldado e estruturado para
eliminar esses possíveis problemas de redundância nas informações. Esse processo de sintetizar
as respostas obtidas nas entrevistas para corrigir e melhorar a documentação do software é
essencial durante o desenvolvimento de softwares (Vazquez; SimÕes, 2016).
Além disso, na engenharia de requisitos, o processo de validação é apontado como um
dos seus princípios, já que requisitos não validados são inúteis (Pohl, 2010). Uma vez que é
impossível garantir que os mesmos (não validados) representem as verdadeiras necessidades do
cliente. Com base nisso, após a identificação dos requisitos, o processo de análise e validação é
concluído junto ao coordenador do curso de BTI.
Com o documento estruturado e validado, foi possível definir os principais aspectos que
compôs o sistema, incluindo suas funcionalidades (requisitos funcionais), descrito na Seção 3.1,
e suas restrições e aspectos de qualidade (requisitos não funcionais), apresentados na Seção 3.1,
além de algumas expectativas acerca do sistema a ser desenvolvido.
10 https://github.com/gpsics/horarios-bti-front
 26

- Requisitos funcionais

A seguir, são listados os requisitos funcionais do sistema proposto. Eles possibilitam

principalmente o gerenciamento de professores, componentes curriculares e turmas, que juntos
permitem o gerenciamento da grade de horários.
• RF001 - Gerenciar professores: O sistema deve permitir o gerenciamento de professores,
possibilitando criação, leitura, atualização e exclusão de professores;
• RF002 - Gerenciar componentes curriculares: O sistema deve permitir o gerencia-
mento de componentes curriculares, tornando possível a sua criação, leitura, atualização e
exclusão;
• RF003 - Gerenciar turmas: O sistema deve permitir o gerenciamento de turmas, sendo
capaz de criar, ler, atualizar e excluir turmas;
• RF004 - Listar turmas cadastradas filtrada pelo Professor: O sistema deve permitir a
listagem de todas as turmas cadastradas com mesmo professor;
• RF005 - Listar turmas cadastradas filtrada pelo Componente Curricular: O sistema
deve permitir a listagem de todas as turmas cadastradas com o mesmo componente
curricular;
• RF006 - Listar turmas cadastradas filtrada pelo número do semestre dos Componen-
tes Curriculares: O sistema deve permitir a listagem de todas as turmas cadastradas que
possuem o mesmo número de semestre em seu componente curricular;
• RF007 - Listar turmas com conflitos de horários: O sistema deve permitir a listagem de
todas as turmas cadastradas que possuem conflitos de horários, identificando as turmas
envolvidas e os motivos dos conflitos.

- Requisitos não funcionais

A seguir, são apresentados os requisitos não-funcionais do sistema apresentado. Esses

requisitos garantem que o usuário possa utilizar o sistema de forma segura a qualquer momento.
• RNF001 - Confidencialidade; O sistema deve requisitar a autenticação do usuário para
que as funcionalidades do sistema sejam acessadas;
• RNF002 - Integridade; O sistema não deve permitir que as informações do sistema e do
usuário sejam acessados por terceiros;
• RNF003 - Disponibilidade; O sistema deve garantir a disponibilidade a qualquer mo-
 27

mento.

3.2 Projeto do sistema

Posterior à análise e validação dos requisitos, conduziu-se à fase de planejamento do

sistema, onde foram feitas a elaboração dos modelos e diagramas. A etapa de projeto do sistema
antecede a fase de implementação, já que a mesma independe da linguagem de programação
utilizada no momento da codificação (Sommerville, 2011). Após isso, foram definidas as
tecnologias e ambientes necessários para o desenvolvimento nas etapas seguintes.
Antes de iniciar a implementação das funcionalidades, foram construídos os modelos e
diagramas à base do uso da UML, uma linguagem padronizada para a elaboração da estrutura
de projetos de software (Neto, 2022). Como ferramenta para elaboração desses diagramas e
modelos, utilizou-se do Astah UML, uma ferramenta que oferece suporte para criação de diversos
diagramas utilizados na engenharia de software.
Diante disso, como primeira representação, foi elaborado um diagrama de classe para
visualizar o comportamento das classes relacionadas entre si. A prioridade em sua construção se
dá pelo fato de que diagramas de classes permitem definir a estrutura lógica do sistema (Guedes,
2018), processo fundamental no desenvolvimento back-end de sistemas.
O diagrama de classe criado para o sistema em questão é composto por três classes
relacionadas, como apresentado na Figura 2. Cada classe é uma representação de uma entidade
do sistema com seus respectivos atributos e métodos.

Figura 2 – Diagrama de Classe

Fonte: Autoria própria (2023)

Como parte do planejamento, devido ao gerenciador de horários ser um sistema orientado

a objetos, para representar sua estrutura de dados e auxiliar na construção dos bancos de dados
utilizando PostgreSQL (PostgreSQL, 1996), foi feito o uso de um modelo de dados Entity-
 28

Relationship (ER).
O diagrama ER, representado na Figura 3, possui quatro tabelas relacionadas, três repre-
sentando os objetos principais do sistema e uma referindo-se à normalização do relacionamento
múltiplo entre duas entidades.

Figura 3 – Diagrama ER.

Fonte: Autoria própria (2023)

Definidas as estruturas do sistema, é possível estabelecer quais tecnologias e ambientes

de desenvolvimento serão utilizados. A escolha desses elementos considerou a expertise do
desenvolvedor com a tecnologia e ambiente, bem como seus benefícios para o estilo do projeto.
Para o desenvolvimento, foi utilizado o framework Django como tecnologia, um ótimo meio
para o desenvolvimento de aplicações web (Santos; Nagao; Montanha, 2017).
Para a codificação da aplicação, foi escolhido o PyCharm11 como ambiente de desen-
volvimento. O PyCharm é uma Integrated Development Environment (IDE) utilizada para
desenvolver sistemas em Python, mesma linguagem de programação que serve como base do
Django framework utilizado nesse trabalho.
11 https://www.jetbrains.com/pt-br/pycharm/
 29

3.3 Implementação

Nessa fase, é iniciada a codificação do sistema, onde o que foi projetado em fases
anteriores é transformado em códigos executáveis (Bezerra, 2007). Em conjunto com a linguagem
e framework utilizado nesse trabalho, como mencionado no tópico anterior, foi utilizada uma
biblioteca (conjunto de funções prontas) para facilitar e agilizar o desenvolvimento, o Django
Rest Framework (DRF).
Antes de iniciar a implementação, foram definidos como processo de desenvolvimento
alguns modelos simples e sequenciais para guiar a codificação. O modelo principal utilizado na
codificação desse sistema teve como base o método Cascata, também conhecido como Waterfall,
que consiste no desenvolvimento sequencial da aplicação (Stair et al., 2021), mas com a junção
do modelo Incremental no desenvolvimento do sistema desse trabalho (Pressman; Maxim, 2016).
O modelo cascata pode ser visualizado na Figura 4.

Figura 4 – Modelo Cascata

Fonte: Stair et al. (2021)

Nesse modelo, a codificação ocorre majoritariamente de forma sequencial, onde uma

 30

etapa é só finalizada quando a sua anterior finaliza. Essa característica é marcante no modelo e
muitas das vezes é vista como uma desvantagem em alguns cenários (Pressman; Maxim, 2016),
mas em um cenário onde há apenas uma pessoal responsável pelo sistema, o desenvolvimento é
facilitado. Com a adição do modelo Incremental, é possível flexibilizar a implementação das
funcionalidades do sistema proposto.
A partir disso, o processo de desenvolvimento ocorreu de maneira progressiva, seguindo
o modelo proposto, desenvolvendo implementações parciais do sistema a cada incremento,
gradativamente.

3.4 Testes de Software

À medida que um sistema é incrementado, erros podem se acumular se testes não forem
executados, chegando ao ponto de impossibilitar o desenvolvimento de possíveis funcionalidades
seguintes (Delamaro; Jino; Maldonado, 2013). Com base nisso, a execução de testes foi
faseada, para que, a cada incremento (nova funcionalidade) desenvolvido, testes sejam criados e
executados para encontrar erros e verificar se as funcionalidades estavam em conformidade com
a especificação.
A execução e análise de testes pode ser uma atividade custosa a depender da forma
como for realizada. Pensando nisso, foi utilizado um ferramente de testes presente tanto no
Python, quanto no Django, chamado de unittest, para facilitar a criação e execução dos testes
unitários. Ele fornece uma forma simples e flexível de escrever testes, possibilitando que os
desenvolvedores criem casos de teste de forma mais legível e eficiente.
O sistema proposto realiza validações para garantir que os dados enviados durante as
solicitações do usuário correspondam com os tipos aceitos pelos campos das entidades, em alguns
casos, a aplicação realiza operações para adequar o formato dos dados, assim como, certificar
que os dados enviados pelo usuário sejam confiáveis. Esse processo é de suma importância e
é realizado por funções presentes no sistema. Então, para assegurar seu bom funcionamento,
foram realizados testes nesses métodos individualmente.
Visando identificar e testar o funcionamento das validações de dados realizadas pelo
sistema proposto em conjunto com outras funcionalidades, foram elaborados alguns casos de
testes para serem executados. Os casos de testes foram construídos levando como base as técnicas
de análise do valor limite e particionamento por equivalência para garantir e assegurar que esses
casos de testes sejam significativos e eficientes. (Pressman; Maxim, 2016).
 31

Ao criar um sistema web, especialmente uma API, é fundamental garantir o bom funcio-
namento das rotas que possibilitam a sua utilização. Então, para isso, foi utilizado o Postmam
para realizar os testes de rotas da API, já que o mesmo permite enviar diferentes tipos de soli-
citações HTTP para o servidor e receber suas respostas, possibilitando assim, a verificação do
comportamento da API em diversas situações.
Para visualizar e certificar o funcionamento das rotas, foram realizadas requisições para
o servidor utilizando os principais métodos do protocolo HTTP (GET, POST, PUT, PATCH e
DELETE). A partir da especificação do sistema e com a resposta da solicitação, foi possível
verificar a existência inconsistências perante a especificação.

3.5 Implantação

Com a conclusão dos testes do software, foi realizada a fase de preparação do ambiente
para iniciar a implantação e distribuição do sistema proposto. Onde, ao final desse processo,
outros sistemas e usuários poderão ter acesso e utilizar a API do sistema de Gerenciador de
Horários a qualquer momento.
É uma prática comum entre desenvolvedores utilizar configurações e ferramentas para
tornar o ambiente de desenvolvimento mais funcional durante o desenvolvimento de sistemas.
Mas, manter essas configurações em produção não é considerada boa prática, visto que em
ambientes de produção é preferido que os sistemas possuam concorrência e escalabilidade. Por
exemplo, o Django, por padrão, é integrado ao SQLite, um mecanismo de banco de dados
que armazena dados em um arquivo local, leve e fácil de se utilizar (Kreibich, 2010). Mas no
ambiente de produção, o nosso sistema utilizou o PostgreSQL como banco de dados, pois ele é
capaz de prover escalabilidade e concorrência, ideal para sistemas em produção.
Realizada a etapa de preparação do ambiente, foi confeccionado um diagrama para
representar a arquitetura na nuvem em que o sistema foi hospedado. A hospedagem foi feita
utilizando os serviços da AWS, visando abstrair grande parte do processo de implantação
de sistemas na internet. Dessa forma, buscando tornar a hospedagem do sistema escalável,
apresentamos a arquitetura na Figura 5 que torna isso possível. Os serviços utilizados na
arquitetura de implantação podem ser descritos como:
Seguindo o diagrama presente na Figura 5, a implantação do software foi feita utilizando
de contêineres Docker12 executados no ECS em conjunto com AWS Fargate, um serviço de
12 https://www.docker.com
 32

Figura 5 – Arquitetura em Nuvem de Implantação

Fonte: Autoria própria (2023)

computação serverless para contêineres gerenciados pela própria AWS. Esse serviço, permite
executar contêineres sem precisar gerenciar a infraestrutura subjacente. Em conjunto com a
computação desse sistema, há o sistema de armazenamento de banco de dados que está sendo
gerenciado com o RDS e tem como SGBD o PostgreSQL.
O Route 53, o serviço de DNS, foi utilizado para gerenciar o tráfego de comunicação do
sistema apresentado. A sua escolha levou em consideração a sua eficiência em rotear o tráfego
na internet, principalmente, para os recursos construídos e hospedados na infraestrutura da AWS.
Apesar do sistema já estar em produção, o acesso via endereços binários (endereços IP) dificulta
a disponibilidade de sistema web para os usuários (Tanenbaum, 1996). Com base nisso, a fim de
tornar a aplicação ainda mais acessível, foi feito uso da plataforma Hostinger13 para adquirir um
domínio simples e de fácil memorização para ser utilizado na aplicação.
Além de garantir que o tráfego esteja sempre sendo redirecionado, é de suma importância
que a comunicação aconteça com segurança. Por essa razão, utilizamos o Hypertext Transfer
Protocol Secure (HTTPS). Então, para isso, implantamos um certificado SSL/TLS no domínio do
sistema com o auxílio do AWS Certificate Manager (ACM), outro serviço da AWS, que permite
provisionar, gerenciar e implantar certificados SSL/TLS para domínios ligados ao uso de serviços
e recursos da AWS. Ao final de todo o processo de nomeação e certificação, o Gerenciador de
13 https://www.hostinger.com.br
 33

Horários tornou-se disponível de forma eficiente e segura.

 34

4 ANÁLISE DO GERENCIADOR DE HORÁRIOS

Neste capítulo, são apresentados os resultados da análise dos testes do desenvolvimento

Back-end do Gerenciador de Horários. Na seção 4.1 e na seção 4.2 são apresentados os resultados
de testes de softwares que tornaram possível identificar erros presentes na codificação do sistema
proposto. Desta forma, é possível avaliar o desenvolvimento e alguns aspectos de qualidade do
sistema Gerenciador de Horários. Vale ressaltar que o sistema está disponível em repositório de
versionamento de código14 (GitHub) sob a licença MIT em conjunto com a aplicação front-end15 .

4.1 Resultados dos testes de unidade

Com base nos resultados obtidos da execução dos testes unitários no sistema, utilizando
o unittest, foi possível identificar algumas inconsistências no funcionamento da API. Dentre as
funcionalidades testadas, algumas não tiveram um comportamento esperado, por exemplo, o
sistema aqui apresentado realiza, através da função split-horarios, a modificação do horário da
turma passado pelo usuário quando o mesmo o envia junto e não separado.
Antes de iniciar a realização dos testes unitários das menores partes do sistema, foram
elaborados alguns casos de testes com base na especificação visando identificar possíveis erros.
Com base nisso, os casos de testes da função split-horarios foram compostos por um valor
passado ao método e o resultado esperado da execução do método. No quadro 1, podem ser
visualizados os casos de testes e, na Figura 6, a codificação dos casos de testes.
Com a execução dos casos de testes, foi possível constatar a presença de anormalidades,
uma vez que o resultado da função não condizia com o valor esperado do método, conforme
a especificação. Ao realizar a análise do resultado, presente na Figura 7, identificou-se que o
problema estava na ordem em que os horários estavam presentes na String resultante. Então,
para resolver esse problema, foi utilizada a função sorted(), nativa do Python, para realizar a
ordenação dos horários.
14 https://github.com/gpsics/horarios-bti-back
15 https://github.com/gpsics/horarios-bti-front

Quadro 1 – Casos de Teste para o Método Split-horarios

Valor passado (String) Resultado esperado (String)
2M23 2M4 2M5 2M2 2M3 2M4 2M5
45T45 4T4 4T5 5T4 5T5
2N2 2N3 2N4 2N2 2N3 2N4
Fonte: Autoria própria (2023)
 35

Figura 6 – Casos de Teste Utilizando Unittest

Fonte: Autoria própria (2023)

Figura 7 – Resultados dos Testes com Unittest

Fonte: Autoria própria (2023)

4.2 Resultados dos testes de integração

Utilizando o Postmam para realizar requisições HTTP ao servidor, foi possível validar
o funcionamento das rotas. A verificação de sucesso das rotas foi feita a partir da análise do
status da resposta recebida do servidor. Assim, à medida que os casos de teste eram executados,
observou-se que algumas rotas não estavam retornando os resultados esperados. Isso levou à
descoberta de erros associados a essas rotas.
Na Figura 8, por exemplo, verificou-se que, em primeira instância, a execução do método
PATCH (utilizado para atualizar parcialmente os dados de um objeto), retornava um erro do
servidor (Status 500), que inicialmente poderia ser alguma incompatibilidade ou configuração
incorreta do servidor.
Após a análise do código, verificou-se que o problema estava presente no código de
validação dos métodos HTTP da API. Quando a API recebe uma requisição (POST, PATCH
ou PUT) para adicionar ou modificar os dados de um objeto no banco de dados, é realizada
a validação de todos os campos. No entanto, quando o cliente utiliza o método PATCH, são
enviados ao servidor apenas os dados modificados do objeto, assim, no momento da validação, o
 36

Figura 8 – Falha do Método Patch de Componente Curricular

Fonte: Autoria própria (2023)

sistema informa que é necessário informar todos os dados para realizar a operação, retornando um
erro. Para resolver esse problema, o sistema foi modificado para verificar e tratar separadamente
a requisição e para atualização total (PUT) ou parcial (PATCH) dos objetos.
 37

5 CONCLUSÕES E TRABALHOS FUTUROS

O presente trabalho tem como propósito o desenvolvimento de um sistema web para

gerenciar os horários do curso de BTI no CMPF da UFERSA. O sistema foi projetado para
automatizar o processo de análise e verificação de conflitos de horários, proporcionando uma
forma simples, prática e rápida para a criação da grade de horários. Essa automação se tornou
necessária devido à natureza repetitiva e manual do trabalho da coordenação, que demandava
muito tempo e esforço para ser concluído.
Com o propósito de substituir o uso de planilhas eletrônicas na criação das grades de
horário, foram estabelecidos cinco objetivos específicos para o desenvolvimento do software. O
primeiro consistiu no levantamento e análise dos requisitos, permitindo realizar a listagem das
necessidades do cliente. Em seguida, foi realizada a construção da modelagem do sistema, que
facilitou o desenvolvimento do sistema, fornecendo uma visão de sua estrutura. Posteriormente,
a implementação do sistema web permitiu a visualização das funcionalidades em execução.
Após isso, os testes de software foram então realizados, com o auxílio de uma interface16 para
identificar a presença de erros e posteriormente corrigí-los. Por fim, o sistema foi disponibilizado
para o usuário, permitindo sua utilização.
Portanto, ao final do processo de construção do sistema, verificou-se que a utilização
do método de desenvolvimento, descrito nos objetivos específicos, junto às técnicas adotadas,
contribuiu significativamente para o desenvolvimento e entrega do software com qualidade,
tomando como medidor, a sua adequação funcional. Ao fim, o sistema é capaz de identificar
conflitos entre turmas com componentes do mesmo semestre que se encontram com algum
horário igual e entre turmas de componentes diferentes, com mesmos professores e horários
iguais, como também, realizar a verificação e validação dos dados, a fim de eliminar a duplicidade
de dados, assim como verificar a carga horária dos professores.
O software ainda não chegou a ser avaliado e utilizado pela coordenação do curso para o
gerenciamento da grade de horários, sendo empregado apenas em ambientes de testes. Com base
nisso, como perspectiva para trabalhos futuros, surge a necessidade de realizar um levantamento
e uma análise sobre a avaliação do sistema por parte dos seus usuários finais.
Mediante o trabalho aqui exposto, ainda há melhorias que podem ser incorporadas ao
sistema desenvolvido. Existe hoje a necessidade de lidar com conflitos entre turmas com horários
iguais que carecem de salas equipadas para suas aulas. Já que a estrutura presente na UFERSA
16 https://github.com/gpsics/horarios-bti-front
 38

no CMPF, no que diz respeito à quantidade de laboratórios de informática à disposição, não é

suficiente para suprir a demanda por reservas de todas as turmas em um único horário.
Outra possibilidade a ser considerada com a resolução desse novo conflito é a possível
integração com o SRS17 (Sistema de Reserva de Salas) da UFERSA. Visando ser possível realizar
de maneira automática as reservas das salas para as turmas com base na finalização da construção
da grade de horário do semestre.
Pensando no uso recorrente e futuro do sistema, uma atualização interessante para
otimizar o gerenciamento das grades de horários seria a possibilidade de utilizar e manter
armazenadas as grades de horários de semestre anteriores. Essa mudança permitiria que o
coordenador do curso replicasse uma grade horário criada anteriormente, caso as características
da grade antiga correspondessem com a nova.

17 https://srs.ufersa.edu.br/Sistema_Reserva_de_Salas/
 39

REFERÊNCIAS

ASTAH. The Best UML Diagramming Tool Available. 2006. Disponível em:
https://astah.net/products/astah-uml/. Acesso em 22 Nov 2023.
AWS. AWS Free Tier. 2006. Disponível em: https://aws.amazon.com/free/. Acesso em 26 Nov
2023.
AWS. Amazon Relational Database Service. 2009. Disponível em:
https://aws.amazon.com/pt/rds/. Acesso em 10 Fev 2024.
AWS. Amazon Route 53. 2011. Disponível em: https://aws.amazon.com/pt/route53/. Acesso
em 10 Fev 2024.
AWS. Amazon Elastic Container Registry. 2015. Disponível em:
https://aws.amazon.com/pt/ecr/. Acesso em 10 Fev 2024.
AWS. Amazon Elastic Container Service. 2015. Disponível em:
https://aws.amazon.com/pt/ecs/. Acesso em 10 Fev 2024.
BATISTA, N. A.; BRANDAO, M. A.; SILVA, A. P. C. da; MORO, M. M. Aspectos temporais
para medir a força da colaboração no github. In: SBC. Anais do XXXII Simpósio Brasileiro de
Bancos de Dados. [S.l.], 2017. p. 234–239.
BEZERRA, E. Princípios de Análise e Projeto de Sistemas com UML. [S.l.]: Elsevier Rio de
Janeiro, 2007. v. 2.
DELAMARO, M.; JINO, M.; MALDONADO, J. Introdução ao teste de software. [S.l.]:
Elsevier Brasil, 2013.
ERSE, A. V. Desenvolvimento e análise do backend do projeto cuidaidoso. UFOP, 2021.
GITHUB. GitHub: Let’s build from here. 2008. Disponível em: github.com. Acesso em 23
Nov 2023.
GONÇALVES, P. F. Testes de Software e Gerência de Configuração. [S.l.]: Grupo A, 2019.
GRANDI, G. Metodologia para especificação de sistemas em ambiente cliente/servidor
orientada a objetos. 1996.
GUEDES, G. UML 2 - Uma Abordagem Prática. 3. ed. [S.l.]: Novatec Editora, 2018.
KEMP, S. Digital 2024: Global Overview Report. 2024. Disponível em: https:
//datareportal.com/reports/digital-2024-global-overview-report. Acesso em 09 Jan. 2024.
KREIBICH, J. Using SQLite: Small. Fast. Reliable. Choose Any Three. [S.l.]: O’Reilly
Media, 2010.
KRIPKA, M.; KRIPKA, R. M. L.; ORO, N. T. Aplicação de técnicas de otimização na
determinação da distribuição de cargas horárias na universidade de passo fundo. Gestão, p. 45,
2007.
LEI, L.; MEHDI, B.; PARK, J.; CHEN, W.-P. Web api search: Discover web api and its endpoint
with natural language queries. In: KU, W.-S.; KANEMASA, Y.; SERHANI, M. A.; ZHANG,
L.-J. (Ed.). Web Services – ICWS 2020. [S.l.]: Springer International Publishing, 2020.
 40

MANCILLA, G. A. Comparação de desempenho entre bancos de dados utilizando dados

espaciais. UFMT CUC, 2017.

MIGUEL, J. P.; MAURICIO, D.; RODRÍGUEZ, G. A review of software quality models for the
evaluation of software products. arXiv preprint arXiv:1412.2977, 2014.

MKDOCS. Django REST framework. 2011. Disponível em: https://www.django-rest-

framework.org. Acesso em 23 Nov 2023.

NETO, M. F. Tutorial da ferramenta de modelagem ASTAH. [S.l.]: Santa, 2022. Disponível

em:http://codilon.qlix.com.br/bd/bdaula09.pdf. Acesso em 12 Abril 2024.

NEWMAN, S. Monolith to microservices: evolutionary patterns to transform your

monolith. [S.l.]: O’Reilly Media, 2019.

OLIVEIRA, R. R. d. Avaliação de manutenibilidade entre as abordagens de Web Services

RESTful e SOAP-WSDL. Tese (Doutorado) — Universidade de São Paulo, 2012.

OWINTERACTIVE. A importância do desenvolvimento tecnológico na evolução humana.

2023. Disponível em: https://owinteractive.com/blog/curiosidades/a-evolucao-historica-da-
tecnologia. Acesso em 15 Dez 2023.

PAUTASSO, C.; ZIMMERMANN, O.; LEYMANN, F. Restful web services vs. "big"’ web
services: making the right architectural decision. In: Proceedings of the 17th International
Conference on World Wide Web. [S.l.]: Association for Computing Machinery, 2008.

POHL, K. Requirements engineering: fundamentals, principles, and techniques. [S.l.]:

Springer Publishing Company, Incorporated, 2010.

POSTGRESQL. PostgreSQL: About. 1996. Disponível em: https://www.postgresql.org/about/.

Acesso em 23 Nov 2023.

POSTMAM. Postman API Platform. 2014. Disponível em: https://www.postman.com. Acesso

em 25 Nov 2023.

PRESSMAN, R.; MAXIM, B. Engenharia de Software. 8. ed. [S.l.]: MCGraw Hioll Brasil,
2016.

QUINTAGROUP. Django REST Framework. 2014. Disponível em: https://quintagroup.com/

cms/python/django-rest-framework. Acesso em 23 Nov 2023.

REDHAT. Cloud computing. 2023. Disponível em: https://www.redhat.com/pt-br/topics/cloud-

computing/. Acesso em 01 Mar 2024.

SALMIJÄRVI, A. Cloud architecture evaluation. 2023.

SANTOS, J. V. M. dos; NAGAO, M. R. d. S. M. A.; MONTANHA, G. K. Uso de frameworks

para aumento de produtividade no desenvolvimento web em conjunto com o idioma inglÊs.
Jornada Científica e Tecnológica, 2017.

SOMMERVILLE, I. Engenharia de software. 9. ed. [S.l.]: Pearson Prentice Hall, 2011.

STAIR, R. M.; REYNOLDS, G. W.; BRYANT, M. F. J.; GREENBERG, H. et al. Princípios de

Sistemas de Informação. [S.l.]: Cengage Learning Brasil, 2021.
 41

TANENBAUM, A. Computer Networks. [S.l.]: Prentice Hall PTR, 1996. (Prentice Hall
international editions).

UFFC. Revista de Ciência e Administração. 2009. Disponível em: https://periodicos.ufsc.br/

index.php/adm. Acesso em 11 Dez 2023.

UFPE. INTERNET. 1997. Disponível em: https://www.cin.ufpe.br/~flash/resultados/cursos/

taais/1997-2/Internet/internet.html. Acesso em 14 Dez 2023.

VAZQUEZ, C. E.; SIMÕES, G. S. Engenharia de Requisitos: software orientado ao negócio.

[S.l.]: Brasport, 2016.

WESTERVELD, D. API Testing and Development with Postman: A practical guide to

creating, testing, and managing APIs for automated software testing. [S.l.]: Packt Publishing
Ltd, 2021.