João Vitor Machado de Mello
Transcript of João Vitor Machado de Mello
UNIVERSIDADE FEDERAL DE SANTA MARIACENTRO DE TECNOLOGIA
CURSO DE GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO
João Vitor Machado de Mello
UM SISTEMA PARA GERENCIAMENTO DE ACGS PARA O CURSO DECIÊNCIA DA COMPUTAÇÃO
Santa Maria, RS2021
João Vitor Machado de Mello
UM SISTEMA PARA GERENCIAMENTO DE ACGS PARA O CURSO DE CIÊNCIA DACOMPUTAÇÃO
Trabalho de Conclusão de Curso apresen-tado ao Curso de Graduação em Ciênciada Computação da Universidade Federal deSanta Maria (UFSM, RS), como requisito par-cial para obtenção do grau de Bacharel emCiência da Computação.
ORIENTADOR: Prof. Giovani Rubert Librelotto
483Santa Maria, RS
2021
©2021Todos os direitos autorais reservados a João Vitor Machado de Mello. A reprodução de partes ou do tododeste trabalho só poderá ser feita mediante a citação da fonte.End. Eletr.: [email protected]
RESUMO
UM SISTEMA PARA GERENCIAMENTO DE ACGS PARA O CURSO DECIÊNCIA DA COMPUTAÇÃO
AUTOR: João Vitor Machado de MelloORIENTADOR: Giovani Rubert Librelotto
As atividades complementares de graduação compõem um importante passo na gradua-
ção de um aluno. São eventos e experiências que o aluno vivencia fora da aula e, portanto,
constituem uma parte essencial do aprendizado, seja como graduando ou como ser hu-
mano. O processo de registro das ACGs, no entanto, é problemático e lento. Com a
pandemia, este problema se agravou, pois há a necessidade de registro destas atividades
sem uma estrutura ainda preparada para receber estes pedidos remotamente. Percebendo
a importância das ACGs no projeto pedagógico do curso e buscando uma melhor aborda-
gem para pedido de horas complementares, este sistema foi idealizado com a proposta de
permitir aos alunos e membros do colegiado, um melhor gerenciamento destas atividades
e disponibilidade destas informações online, desde a parte de cadastro até a homologação
de uma solicitação.
Palavras-chave: Atividade Complementar de Graduação, Computação, Desenvolvimento,
Sistema.
ABSTRACT
A SYSTEM FOR MANAGING UNDERGRADUATE COMPLEMENTARYACTIVITIES FOR THE COMPUTER SCIENCE COURSE
AUTHOR: João Vitor Machado de MelloADVISOR: Giovani Rubert Librelotto
Complementary undergraduate activities make up an important step in a student’s gradua-
tion. These are events and experiences that the student experiences outside of class and,
therefore, constitute an essential part of learning, either as a graduate student or as a hu-
man being. The registration process for the ACGs, however, is problematic and slow. With
the pandemic, this problem worsened, as there is a need to register ACGs without a struc-
ture yet prepared to receive these requests remotely. Realizing the importance of these
activities in the pedagogical project of the course and seeking a better approach for re-
questing additional hours, this system was designed with the proposal of allowing students
and members of the collegiate a better management of these activities and availability of
this information online, from the registration part to the approval of a request.
Keywords: Undergraduate Complementary Activity. Computation, Development, System.
LISTA DE FIGURAS
Figura 2.1 – Representação visual do MVC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23Figura 2.2 – Representação das classes Pessoa e Banco. . . . . . . . . . . . . . . . . . . . . . . . . . . . 26Figura 2.3 – Estrutura de uma tabela em um SGBD. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29Figura 3.1 – Fluxograma de uma ACG solicitada. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32Figura 3.2 – Diagrama de casos de uso para o usuário Aluno. . . . . . . . . . . . . . . . . . . . . . . . 35Figura 3.3 – Diagrama de casos de uso para o usuário Professor. . . . . . . . . . . . . . . . . . . . 36Figura 3.4 – Diagrama de casos de uso para o usuário Secretário. . . . . . . . . . . . . . . . . . . . 37Figura 3.5 – Modelo da base de dados do sistema. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38Figura 3.6 – MVC aplicado ao ACG-CC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42Figura 3.7 – Situações possíveis para um pedido e sua ordem. . . . . . . . . . . . . . . . . . . . . . . 43Figura 3.8 – A página de cadastros antes e depois da importação das folhas de estilo
do Bootstrap. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47Figura 3.9 – Comparação entre a página de cadastro de sistema e o formulário de
pedidos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48Figura 3.10 – Tela para verificação de horas do aluno. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49Figura 3.11 – Tabela de logs para um pedido exemplo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50Figura 3.12 – Tela de login do ACG-CC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52Figura 3.13 – Módulo para assinalar professores a pedidos (juntamente com a opção
de visualizar pedidos). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52Figura 3.14 – Opção para busca automática de professores. . . . . . . . . . . . . . . . . . . . . . . . . . 53Figura 3.15 – Documentos no ACG-CC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56Figura 3.16 – Configurações disponíveis no ACG-CC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57Figura 3.17 – Exemplo de e-mail enviado. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58Figura 4.1 – Página de pedidos ativos após o cadastro de uma ACG. . . . . . . . . . . . . . . . . 59Figura 4.2 – Interface do usuário para fornecer o parecer como coordenador. . . . . . . . . 60Figura 4.3 – Tela de pedidos com a possibilidade de assinalar professor. . . . . . . . . . . . . . 60Figura 4.4 – Tela de visualização do pedido com a opção de assinalar professores. . . 61Figura 4.5 – Interface do usuário para fornecer o parecer como relator. . . . . . . . . . . . . . . 61Figura 4.6 – Opção de homologação de pedidos no sistema. . . . . . . . . . . . . . . . . . . . . . . . . 62Figura 4.7 – Situação ”Correção necessária” no ACG-CC. . . . . . . . . . . . . . . . . . . . . . . . . . . . 63Figura 4.8 – Tela de avaliação de pedidos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63Figura 4.9 – Opção para editar pedidos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64Figura 4.10 – Opção para excluir documentos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64Figura 4.11 – Página de avaliação com mudança da carga horária aceita. . . . . . . . . . . . 66Figura 4.12 – Visualização do pedido após homologação com carga horária reduzida. 67
LISTA DE TABELAS
Tabela 2.1 – Listagem de atividades da UFSM e outras informações. . . . . . . . . . . . . . . . . 13Tabela 2.2 – Listagem de atividades da UFV e suas cargas horárias. . . . . . . . . . . . . . . . . 18Tabela 2.3 – Comparativo da UFSM com as instituições citadas na pesquisa em rela-
ção às ACGs no curso de Ciência da Computação. . . . . . . . . . . . . . . . . . . . . . . 19Tabela 3.1 – Requisitos funcionais e não-funcionais da solução proposta. . . . . . . . . . . . . 33Tabela 3.2 – Cronograma de desenvolvimento do ACG-CC. . . . . . . . . . . . . . . . . . . . . . . . . . . 39Tabela 3.3 – Relação de telas do módulo aluno. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44Tabela 3.4 – Relação de telas do módulo professor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45Tabela 3.5 – Relação de telas do módulo secretário. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
LISTA DE ABREVIATURAS E SIGLAS
ACG Atividade Complementar de Graduação
API Application Programming Interface
ASP Active Server Pages
BD Banco de Dados
CPD Centro de Processamento de Dados
CSS Cascading Style Sheets
HTML HyperText Markup Language
HTTP HyperText Transfer Protocol
ISAM Indexed Sequential Access Method
NCSA Next College Student Athlete
PHP PHP Hypertext Preprocessor
SGBD Sistema de Gerenciamento de Banco de Dados
SQL Structured Query Language
UFSM Universidade Federal de Santa Maria
UFJF Universidade Federal de Juiz de Fora
UFPE Universidade Federal do Pernambuco
UFRGS Universidade Federal do Rio Grande do Sul
UFV Universidade Federal de Viçosa
UFC Universidade Federal do Ceará
SUMÁRIO
1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.1 OBJETIVO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.2 JUSTIFICATIVA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101.3 ESTRUTURA DO TEXTO. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 REFERENCIAL TEÓRICO. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.1 AS ACG NO CURSO DE CIÊNCIA DA COMPUTAÇÃO DA UFSM .. . . . . . . . . . . . . 112.2 AS ACGS NO CURSO DE CIÊNCIA DA COMPUTAÇÃO DE OUTRAS INS-
TITUIÇÕES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.2.1 UFC - Universidade Federal do Ceará . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.2.2 UFJF - Universidade Federal de Juiz de Fora . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.2.3 UFPE - Universidade Federal de Pernambuco . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.2.4 UFRGS - Universidade Federal do Rio Grande do Sul . . . . . . . . . . . . . . . . . . . . . . . . 162.2.5 UFV - Universidade Federal de Viçosa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.2.6 Comparativo entre as instituições pesquisadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.3 MÉTODOS E FERRAMENTAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.3.1 Metodologia Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.3.2 Arquitetura MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.3.3 PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242.3.4 Orientação a objetos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252.3.5 Apache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272.3.6 CodeIgniter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272.3.7 Bootstrap. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282.3.8 Banco de dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282.3.9 HeidiSQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303 METODOLOGIA E DESENVOLVIMENTO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.1 ANÁLISE DO PROBLEMA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.2 REQUISITOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333.3 MODELAGEM DO SISTEMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343.3.1 Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343.3.1.1 Módulo aluno . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343.3.1.2 Módulo professor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353.3.1.3 Módulo secretário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363.3.2 Base de dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373.3.3 Cronograma de desenvolvimento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383.4 DESENVOLVIMENTO DO SISTEMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393.4.1 Helpers - Bibliotecas adicionais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403.4.2 Versão 0.5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403.4.2.1 Organização do sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403.4.2.2 Situações de um pedido . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423.4.3 Versão 0.6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433.4.3.1 Estruturas dos menus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433.4.3.2 Telas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443.4.3.3 Folhas de estilo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463.4.4 Versão 0.7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473.4.4.1 Cadastro de pedidos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.4.4.2 Visualização de pedidos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483.4.4.3 Horas do aluno . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483.4.4.4 Avaliação de pedidos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493.4.4.5 Registro de atividades - log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493.4.5 Versão 0.8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503.4.5.1 Sistema de usuários. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503.4.5.2 Assinalar professores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 523.4.5.3 Algoritmo para escolha dos professores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 523.4.5.4 Concorrência na base de dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543.4.5.5 Permissões de acesso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 553.4.6 Versão 0.9 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 553.4.6.1 Anexos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 553.4.6.2 Emissão do Formulário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 563.4.7 Versão 1.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 563.4.7.1 Configurações . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 563.4.7.2 Notificações . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 574 ESTUDOS DE CASO. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 594.1 CADASTRO COMPLETO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 594.1.1 Cadastro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 594.1.2 Avaliação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 594.1.3 Homologação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 614.2 PEDIDO COM DOCUMENTAÇÃO INCOMPLETA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 624.2.1 Cadastro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 624.2.2 Avaliação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 624.2.3 Nova tentativa de cadastro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 634.2.4 Reavaliação e homologação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 654.3 PEDIDO APROVADO PARCIALMENTE EM CARGA HORÁRIA. . . . . . . . . . . . . . . . . 654.3.1 Cadastro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 654.3.2 Avaliação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 654.3.3 Homologação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 665 CONCLUSÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
REFERÊNCIAS BIBLIOGRÁFICAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
1 INTRODUÇÃO
As Atividades Complementares de Graduação (ACG) são atividades vivenciadas
pelo graduando fora da sala de aula. Estas atividades compõem um importante passo na
formação dos alunos, contribuindo tanto no desenvolvimento profissional como também no
humano.
O curso de Ciência da Computação da UFSM possui um regulamento para cum-
primento das ACGs (Universidade Federal de Santa Maria, 2011). Nele, constam os tipos
de atividades que podem ser consideradas como ACG e como elas podem ser inseridas
como carga horária no currículo do aluno. Para que o aluno possa registrar estas ativida-
des, ele deve cadastrar as mesmas seguindo os processos atuais de pedidos de atividades
complementares.
Estes pedidos acabam por gerar vários tipos de problemas. Por ser um processo
manual e que é delegado apenas em reuniões do colegiado, podem ser necessários vá-
rios encontros para que uma única atividade seja aprovada ou reprovada. Em alguns
casos, também, alunos não recebem o devido retorno de suas requisições. Além disso,
o consumo de papel para envio dos pedidos pode ser visto como algo desnecessário,
considerando o momento ”digital” que o mundo se encontra, principalmente em assuntos
relevantes ao curso de Ciência da Computação.
A pandemia do novo coronavírus também é um fator determinante, pois mostrou o
quanto o curso pode evoluir nessas questões. Foi determinado que, durante o período de
suspensão das atividades presenciais, as ACGs só seriam julgadas em casos extremos
(prováveis formandos) e com envios de documentos digitalizados.
Durante o desenvolvimento deste trabalho, uma ferramenta para requisição de ACGs
foi implementada pelo CPD da universidade junto ao portal do aluno. No entanto, a apli-
cação funciona no âmbito de todos os cursos da universidade, vindo a ignorar particula-
ridades de cada curso. A ferramenta descrita neste trabalho funciona baseando-se em
normativas específicas do curso de Ciência da Computação da UFSM.
1.1 OBJETIVO
Desenvolver uma ferramenta, denominada ACG-CC, que possa maximizar o de-
sempenho no processamento das atividades complementares de graduação do curso de
Ciência da Computação da Universidade Federal de Santa Maria, auxiliando nos proces-
sos de pedido e também de correções das requisições.
10
1.2 JUSTIFICATIVA
Possibilitar, aos alunos do curso, eficiência no pedido de horas e também aos mem-
bros do colegiado na correção destes pedidos. Além disso, providenciar a consulta das
horas aprovadas e restantes para cada um, facilitando o acesso à informação.
1.3 ESTRUTURA DO TEXTO
No Capítulo 2 será vista uma revisão bibliográfica dos conceitos utilizados no de-
senvolvimento do trabalho. No Capítulo 3 será abordada a metodologia para o desenvolvi-
mento do sistema, desde modelagem a usos e testes. No Capítulo 4 serão apresentados
casos de uso e como o software trata cada um deles. No Capítulo 5 será feita uma conclu-
são do trabalho, apresentando a importância do desenvolvimento e como o sistema pode
ser aprimorado para trabalhos futuros.
2 REFERENCIAL TEÓRICO
Neste capítulo são vistos conceitos que serão pertinentes ao entendimento do de-
senvolvimento da tese, seja em questão de algoritmo ou em questão de conhecimento
para o assunto tratado.
2.1 AS ACG NO CURSO DE CIÊNCIA DA COMPUTAÇÃO DA UFSM
Entende-se por ACG toda e qualquer atividade considerada pertinente e útil para a
formação humana e profissional do acadêmico, realizada concomitantemente ao curso de
Ciência da Computação da Universidade Federal de Santa Maria (Universidade Federal de
Santa Maria, 2011).
No curso de Ciência da Computação da UFSM, as ACGs são divididas em nove
eixos:
1. Participação em eventos;
2. Atuação em núcleos temáticos;
3. Atividades de extensão;
4. Estágios extra-curriculares;
5. Atividades de iniciação científica e de pesquisa;
6. Publicação de trabalhos;
7. Participação em órgãos colegiados;
8. Monitoria;
9. Outras atividades a critério do Colegiado.
Cada aluno precisa realizar uma solicitação para cada atividade realizada. Esse
processo consiste em:
• Envio do formulário de solicitação fornecido pela coordenação, impresso, preenchido
e assinado pelo aluno;
• Envio de documentos comprobatórios, conforme descrição da atividade e normativa
do curso (Universidade Federal de Santa Maria, 2011).
12
A solicitação precisa ser feita até o fim do semestre subsequente do qual a atividade
foi realizada. Por exemplo, a data limite de registro de uma atividade realizada em abril de
2019 (2019/1) se dá no final do segundo semestre letivo de 2019. O registro dessas horas
é feito junto à coordenação do curso após avaliação e aprovação do colegiado, este tendo
pelo menos uma reunião por semestre para apreciação das ACGs enviadas durante o
semestre.
Para cada eixo, existe um limite na carga horária aceita para conclusão do curso.
Um aluno pode, por exemplo, registrar uma atividade de estágio com 500 horas, com esta
atividade constando no currículo do aluno, mas apenas as 150 limítrofes serão contadas
para as 290 exigidas pelo currículo do curso.
No curso de Ciência da Computação da UFSM existe uma particularidade quanto às
exigências currículares: o acadêmico precisa ter, no mínimo, noventa horas somando-se os
itens “Atuação em núcleos temáticos”, ”Atividades de extensão”, ”Atividades de iniciação
científica” e ”Monitoria”.
A Tabela 2.1 relata as atividades, o limite de carga horária contabilizada, a docu-
mentação necessária e outras informações para cada atividade.
13
Tabela 2.1 – Listagem de atividades da UFSM e outras informações.
Atividade Ações necessárias Limite
Participação em
eventos
Anexar certificado e, se organizador, relatório de
atividades
75 horas
Atuação em núcleo
temático
Anexar comprovante de registro do projeto na
instituição, relatório compatível com a carga ho-
rária e parecer do tutor/orientador
75 horas
Atividades de ex-
tensão
Anexar comprovante de registro do projeto na
instituição, relatório de atividades compatível
com a carga horária solicitada e parecer do co-
ordenador do projeto
75 horas
Estágios extra-
curriculares
Anexar atestado, relatório de atividades compa-
tível com a carga horária solicitada e parecer do
responsável pelo estágio
150 horas
Atividades de inici-
ação científica
Anexar comprovante de registro do projeto na
instituição, relatório de atividades compatível
com a carga horária solicitada e parecer do pro-
fessor coordenador do projeto
150 horas
Publicação de tra-
balhos
Anexar cópia da publicação e identificação do
veículo (evento, revista, etc.)
75 horas
Participação em ór-
gãos colegiados e
diretórios acadêmi-
cos
Anexar portaria do colegiado ou atestado assi-
nado pelo presidente do diretório
75 horas
Monitoria Anexar comprovante de registro do projeto na
instituição, relatório de atividades compatível
com a carga horária solicitada e parecer do pro-
fessor responsável pela disciplina
135 horas
Outras atividades a
critério do Colegi-
ado
Anexar certificado com carga horária 75 horas
Fonte: (Universidade Federal de Santa Maria, 2011)
14
2.2 AS ACGS NO CURSO DE CIÊNCIA DA COMPUTAÇÃO DE OUTRAS INSTITUI-
ÇÕES
Nesta seção, são apresentadas as regulamentações internas de cursos de Ciência
da Computação de outras instituições, explicando todas as normas e as formas de registro
de ACGs.
Como critério para o levantamento, foram usados os dados do Exame Nacional de
Desempenho de Estudantes (ENADE) e as universidades com cursos mais bem avaliados
foram escolhidas.
2.2.1 UFC - Universidade Federal do Ceará
O curso de Ciência da Computação da UFC possui um site com toda a regulamen-
tação envolvendo ACGs, desde plano pedagógico a uma seção própria de informações. No
curso, são requisitadas 192 horas de atividades complementares para a colação de grau
do aluno. As atividades complementares são divididas nos seguintes tipos (Universidade
Federal do Ceará, 2016):
1. Atividades de Iniciação à Docência, à Pesquisa e/ou Extensão, com máximo de até
96 horas registradas;
2. Atividades artísticas, culturais e/ou esportivas, totalizando até 80 horas de formação;
3. Atividades de participação e/ou organização de eventos, contabilizando o máximo de
32 horas;
4. Atividades de iniciação profissional e/ou correlatas, contabilizando o máximo de 64
horas;
5. Produção técnica e/ou científica, contabilizando o máximo de 96 horas;
6. Vivência ou experiências de gestão, contabilizando o máximo de 48 horas;
7. Outras atividades relacionadas à Universidade ou ao curso, contabilizando o máximo
de 48 horas.
Para registro das atividades complementares, o aluno deve preencher e assinar o
formulário de submissão (ou seja, sem sistema para tal), anexando ao pedido documentos
comprobatórios. Essa solicitação é feita de forma única, com um formulário indicando a
atividade e qual o documento anexado referente a ela. O processo pode ser feito em duas
etapas, sendo a primeira ao final dos dois primeiros anos do curso e a segunda até ses-
senta dias antes da conclusão do mesmo. Uma comissão composta por dois professores,
juntamente com o coordenador e um representante dos estudantes avalia os pedidos.
15
2.2.2 UFJF - Universidade Federal de Juiz de Fora
O curso de Ciência da Computação da UFJF propõe outra nomenclatura para ativi-
dades complementares, sendo estas chamadas de ”Atividades Curriculares Eletivas”. Na
tabela de flexibilização curricular, as mesmas são referenciadas como atividades comple-
mentares (Universidade Federal de Juiz de Fora, 2013). Estes dados podem ser acessados
via site do curso, com as informações sugerindo que, mais uma vez, os pedidos são feitos
de forma manual.
Segundo o projeto pedagógico, as cargas horárias requisitadas são 360 horas para
o curso diurno e 390 horas para o curso noturno.
As atividades são divididas em doze eixos, possuindo as seguintes definições (Uni-
versidade Federal de Juiz de Fora, 2013):
1. Atividades de iniciação à docência, à pesquisa, à extensão ou treinamento profissi-
onal, treinamento administrativo ou grupo de educação tutorial, contando 60 horas
por atividade no período letivo. Em caso de bolsa/projeto, existe um limite total de
120 horas, já em caso de participação em grupos de educação tutorial esse limite é
de 240 horas;
2. Disciplina opcional (limite pré-fixado na ementa da disciplina);
3. Estágio, limite de 60 horas por semestre;
4. Grupo de estudos, limite de 30 horas por semestre;
5. Participação em eventos, divididos em seis subeixos: Congressos, Seminários, Sim-
pósios, Encontros, Palestras e Cursos de curta duração. Para cursos, o limite semes-
tral é proporcional ao dobro da carga horária, com limite de 15 horas. Nos elementos
restantes, o limite é proporcional à carga horária, limitando-se a 15 horas;
6. Organização de Eventos, divididos em três subeixos: Semanas acadêmicas, Con-
gressos e Eventos do DCC. Todos com limite de 15 horas;
7. Apresentação em eventos, sejam palestras ou minicursos. Para palestras, limite de
15 horas por título, para minicursos, limite de 30 horas;
8. Representação estudantil, sendo 60 horas o limite semestral e 120 horas o limite
total;
9. Certificação em língua estrangeira, com 15 horas de limite;
10. Certificação na área do curso, 30 horas;
11. Participação na administração de empresa júnior, sendo 60 horas o limite semestral
e 180 horas o limite total;
16
12. Vivência profissional complementar, sendo 15 horas o limite semestral e 240 horas o
limite total.
2.2.3 UFPE - Universidade Federal de Pernambuco
O curso de Ciência da Computação da UFPE não disponibiliza, em seus canais
informativos, dados suficientes para a pesquisa. Há, entretanto, uma menção de atividades
complementares na carga horária do currículo.
O aluno precisa ter 390 horas em componentes eletivos do curso, podendo ser
computadas no máximo 255 horas em tópicos de curso e no máximo 90 horas em compo-
nentes de tipo seminário em outros centros da universidade ou até mesmo outras institui-
ções superiores de ensino que possuam convênio com a UFPE (Universidade Federal de
Pernambuco, 2002).
2.2.4 UFRGS - Universidade Federal do Rio Grande do Sul
O curso de Ciência da Computação da UFRGS oferece atividades complementares
no formato de créditos complementares. O aluno pode ter, no máximo, 22 créditos e, no
mínimo, 8 créditos complementares para colação de grau (Universidade Federal do Rio
Grande do Sul, 2006). O pedido também é feito de forma manual, via formulário, sem
sistema para tal, com análise individual de comissão estabelecida.
As normativas para ACGs no curso de Ciência da Computação da UFRGS são as
seguintes (Universidade Federal do Rio Grande do Sul, 2006):
• 1 crédito complementar a cada 60 horas de atividades de extensão universitária;
• 1 crédito complementar para cada 6 meses de atividades de monitoria com carga
semanal mínima de 10 horas;
• 1 crédito complementar para 12 meses de atividades de representação discente junto
aos órgãos da instituição;
• 1 crédito complementar para para cada 1 crédito de disciplinas eletivas cursadas
com aproveitamento;
• 1 crédito complementar para cada 15 horas de cursos de extensão universitária;
• 1 crédito complementar para cada 1 crédito de disciplinas de outros cursos da UFRGS
cursadas com aproveitamento e sem duplicidade de conteúdo com as disciplinas re-
gulares do curso;
17
• 1 crédito complementar para 15 horas de disciplinas de outros cursos de outras ins-
tituições de ensino superior nacionais, desde que sejam correlacionadas com a área
de Ciência da Computação;
• 1 crédito complementar para 15 horas de disciplinas de outros cursos de outras ins-
tituições de ensino superior estrangeiras, desde que sejam correlacionadas com a
área de Ciência da Computação;
• 2 créditos complementares para cada 6 meses de atividades de iniciação científica,
bolsa PET e bolsas de natureza semelhante que tenham uma carga mínima de 20
horas e sejam desenvolvidas em atividades da área de Ciência da Computação ou
correlatas;
• 2 créditos complementares para cada 6 meses de atividades de estágios não obri-
gatórios;
• 2 créditos complementares para a publicação de trabalhos em eventos científicos na
área de computação.
Outras atividades que não estejam nos itens acima são analisadas e pontuadas a
critério da comissão responsável.
2.2.5 UFV - Universidade Federal de Viçosa
O curso de Ciência da Computação da UFV considera suas atividades extracurri-
culares como disciplinas. Cada disciplina possui uma carga horária determinada, sendo
estas (Universidade Federal de Viçosa, 2019):
1. INF290: 30 horas;
2. INF291: 60 horas;
3. INF292: 90 horas;
4. INF293: 120 horas;
5. INF294: 180 horas;
O estudante pode se matricular em mais de uma disciplina, sendo o aproveitamento
de atividades complementares limitado a 240 horas.
No momento da matrícula na disciplina, aluno deve reunir a documentação com-
probatória das atividades a serem realizadas. Essa documentação precisa ser enviada à
comissão coordenadora para apreciação, antes da conclusão do plano de estudos para
18
o último semestre do curso. Assim, a comissão tem tempo hábil para emitir um parecer
que indique quantas horas poderão ser aproveitadas e quais atividades ainda podem ser
exercidas. A escolha das disciplinas deve se basear na análise da documentação feita pela
comissão.
No final do último semestre do curso, um conceito ”S” será dado aos estudantes
que de fato comprovem o cumprimento das atividades. Caso não se complete a documen-
tação, arranjos deverão ser conduzidos para aproveitar as atividades cuja documentação
foi comprovada.
A seguir, uma tabela com as atividades, suas descrições e a carga horária máxima
possível para cada uma delas.
Tabela 2.2 – Listagem de atividades da UFV e suas cargas horárias.
Atividade Limite
Bolsista de pesquisa ou extensão 60 horas por ano, com limite total
de 120 horas
Estágio na área da computação registrado 10% da carga horária, com limite
total de 120 horas
Estágio voluntário em pesquisa, ensino ou
extensão
10% da carga horária, com limite
total de 60 horas
Publicação em periódico ou anais de con-
gresso com Qualis
10% da carga horária, com limite
total de 60 horas
Apresentação em congresso com Qualis 20 horas por publicação, com li-
mite total de 60 horas
Participação em eventos (congressos, simpó-
sios, seminários, palestras, cursos, minicur-
sos)
10 horas por apresentação, com
limite total de 30 horas
Ministrar minicurso, palestra ou seminário 10 horas por evento, limite total de
60 horas
Organização de eventos 20 horas por apresentação, com
limite total de 60 horas
Representante e participação em órgão cole-
giado
20 horas por evento, com limite to-
tal de 30 horas
Participação em empresa júnior 10 horas por ano, com limite total
de 30 horas
Participação na diretoria da empresa júnior 15 horas por ano, com limite total
de 30 horas
Participação em atividade esportiva ou cultu-
ral
30 horas por ano, com limite total
de 60 horas
Fonte: (Universidade Federal de Viçosa, 2019)
19
Outras atividades que não estejam na tabela acima são analisadas e pontuadas a
critério da comissão responsável.
2.2.6 Comparativo entre as instituições pesquisadas
Esta subseção apresenta um comparativo entre as instituições pesquisadas com o
panorama da Universidade Federal de Santa Maria.
Analisando os dados fornecidos pelas instituições, conclui-se que a UFSM possui
uma carga horária de atividades complementares semelhante ao que outras instituições
propõem. Além disso, os conceitos são semelhantes, pois são vários eixos em comum nas
regulamentações, além dos pesos dados a estas atividades sendo bem parecidos. Há,
portanto, semelhança de ideias e projetos pedagógicos nos cursos de Ciência da Compu-
tação destas instituições. Há na UFSM, no entanto, a diferenciação de disciplinas com-
plementares com atividades complementares, com boa parte das instituições estudadas
considerando todas estas atividades como partes semelhantes do currículo.
A disponibilidade de informações das instituições pesquisadas também é seme-
lhante, com grande parte possuindo uma regulamentação disponível ao público.
Entretanto, nenhuma instituição possui um sistema para processamento de ACGs.
Todo o processo é manual. O comparativo utilizando estes dados pode ser visto na Ta-
bela 2.3.
Tabela 2.3 – Comparativo da UFSM com as instituições citadas na pesquisa em relação àsACGs no curso de Ciência da Computação.
Instituição Carga horária Informações a respeito das
ACGs
Sistema para
submissão
UFSM 290 horas Projeto pedagógico e normas de
ACGs
Não
UFC 192 horas Projeto pedagógico e normas de
ACGs
Não
UFJF 360 horas (diurno),
390 horas (noturno)
Projeto pedagógico e normas de
ACGs
Não
UFPE Projeto Pedagógico Não especificado Não
UFRGS Ajustável com cré-
ditos (mínimo de 8)
Projeto pedagógico e normas de
ACGs
Não
UFV 240 horas Projeto pedagógico e normas de
ACGs (disciplinas)
Não
Fonte: Autor do Trabalho
20
As informações levantadas por esta pesquisa mostram a importância e a inovação
representadas por uma ferramenta para processamento de ACGs, visto que seria algo
inédito entre estas instituições. Além disso, foi possível verificar as particularidades e a
diversidade das normativas, a fim de entender como uma alternativa digital para estes
processos precisa ser inteiramente personalizada.
2.3 MÉTODOS E FERRAMENTAS
Essa seção apresenta os métodos e ferramentas que serão utilizados na metodolo-
gia proposta neste trabalho.
2.3.1 Metodologia Scrum
A metodologia de trabalho Scrum foi proposta em 1993 por Jeff Sutherland (IEEP
Educação, 2020), que percebeu que os métodos de cascata dos desenvolvedores da em-
presa em que ele trabalhava não rendiam o esperado e, ainda por cima, não conseguiam
entregar projetos nos seus respectivos prazos.
O Scrum se baseia em sprints de desempenho para realizar os objetivos. Os pontos
principais do Scrum, segundo (SUTHERLAND, 2014), podem ser definidos da seguinte
forma:
• Escolher um dono do produto: É necessário escolher uma pessoa responsável
pela visão do que vai ser feito. Ela leva em consideração os riscos, os benefícios, o
que é possível e o que pode ser feito para o bem da equipe;
• Escolher uma equipe: Uma equipe deve possuir as habilidades necessárias para
transformar a visão do dono do produto em realidade. O princípio básico são equipes
com três a nove integrantes;
• Escolher um mestre Scrum: A pessoa que vai orientar o restante da equipe em
relação à estrutura do Scrum, além de identificar problemas de lentidão e eliminá-
los;
• Criação de uma lista de pendências do produto: Trata-se de uma lista com tudo
que precisa ser feito para transformar a visão em realidade. As pendências evoluem
durante o desenvolvimento do produto, sendo o mapa do mesmo. Em qualquer fase
do projeto, as pendências são a única e definitiva visão de tudo que precisa ser feito
pela equipe a qualquer momento, em ordem de prioridade;
21
• Estimativas para as pendências do produto: As pessoas que irão realmente con-
cluir os itens da lista precisam fazer as estimativas de quanto esforço estes itens
exigirão. A equipe deve olhar para cada item das pendências e ver se aquilo é fac-
tível. Se existem informações suficientes, se ele é pequeno para ser estimado, se
pode ser definido como feito... Cada item deve poder ser mostrado, demonstrado e
ser enviado. É necessário usar uma estimativa usando uma classificação relativa por
tamanho: Pequeno, Médio ou Grande (SUTHERLAND, 2014);
• Planejamento do sprint: Isso deve ser abordado na primeira reunião. A equipe,
o dono e o mestre se reúnem para planejar o sprint, sempre com duração definida
de tempo menor que um mês. O tamanho costuma ser definido como uma ou duas
semanas. As equipes olham a lista de pendências e estimam o que podem fazer
durante aquele sprint. Se a equipe já está trabalhando, ela deve pegar tarefas que
totalizem o mesmo número de pontos do sprint anterior. Esse número de pontos
é conhecido como a velocidade da equipe, com o mestre e a equipe aumentando
o número de pontos a cada sprint. Além disso, a cada reunião, todos os membros
precisam concluir algo como o objetivo do sprint. Todo esse processo não pode ser
alterado, ou seja, o que foi definido ali será cumprido no prazo e sem mudanças;
• Trabalho Visível: É necessário mostrar o que está sendo feito de forma física. Um
método comum consiste em criar quadros Scrum com três colunas: A fazer, Fazendo
e Feito. Outro método é o gráfico de Burn-Down, cuja ideia é ter o número de pontos
que a equipe definiu para o sprint em um eixo e o número de dias o outro eixo. O
ideal, nesse caso, é um gráfico em formato de ladeira até chegar no último dia de
sprint (SUTHERLAND, 2014);
• Scrum diário: Todos os dias, com reuniões que durem não mais que quinze minutos,
montar uma reunião com equipe e mestre com o único objetivo de responder o que foi
feito no dia anterior, o que será feito durante o dia e quais os obstáculos encontrados
por cada membro até então;
• Revisão do sprint: Reunião para a equipe mostrar o que foi feito durante o sprint,
mostrando apenas o que satisfaz a condição de feito;
• Retrospectiva do sprint: Passo seguinte à revisão, que busca entender o que pode
melhorar do sprint atual para o próximo, levando a aprimoramentos dos processos
internos;
• Começar imediatamente o próximo sprint : Considerando a experiência da equipe
com os impedimentos e os aprimoramentos no processo.
22
2.3.2 Arquitetura MVC
O modelo de três camadas físicas (3-tier ) divide um aplicativo de modo que a lógica
de negócio resida no meio das três camadas físicas. Isto é chamado de camada física
intermediária ou camada física de negócios. A maior parte do código escrito reside na
camada de apresentação e de negócio (Macoratti, 2004).
A arquitetura MVC - (Modelo Visualização Controle) fornece uma maneira de dividir
a funcionalidade envolvida na manutenção e apresentação dos dados de uma aplicação.
A arquitetura MVC foi originalmente desenvolvida para mapear as tarefas tradicionais de
entrada, processamento e saída para o modelo de interação com o usuário. Usando o pa-
drão MVC fica fácil mapear esses conceitos no domínio de aplicações web multicamadas
(Macoratti, 2004).
O padrão MVC se divide em três camadas, sendo elas Modelo (Model), Visualiza-
ção (View) e Controle (Controller ).
• A camada de modelo é o coração da aplicação, sendo responsável por tudo que a
aplicação vai fazer. Ela modela os dados e o comportamento por trás do processo
de negócios, se preocupando apenas com o armazenamento, a manipulação e a
geração dos dados, sendo independente da apresentação destes dados;
• A classe de visualização apenas exibe a informação, sem se preocupar em como
ela foi obtida. Inclui elementos de exibição do cliente, como HTML e XML, sendo a
camada de interface do usuário, usada para receber a entrada de dados e apresentar
o resultado;
• A classe de controle determina o fluxo da apresentação, servindo como uma camada
intermediária entre o modelo e a visualização (lógica e apresentação) controlando e
mapeando as ações.
A Figura 2.1 mostra a representação visual do MVC.
23
Figura 2.1 – Representação visual do MVC.
Fonte: Adaptado de (Macoratti, 2004)
São benefícios do uso de MVC (Devmedia, 2013b):
1. Aumento de produtividade;
2. Uniformidade na estrutura do software;
3. Redução de complexidade no código;
4. Facilidade na manutenção;
5. Facilidade na documentação;
6. Estabelecimento de um vocabulário comum de projeto entre desenvolvedores;
7. Permite a reutilização de módulos do sistema em outros sistemas;
8. Considerada uma boa prática utilizar um conjunto de padrões para resolver proble-
mas maiores que, sozinhos, não conseguiriam;
9. Ajuda na construção de softwares confiáveis com arquiteturas testadas;
10. Redução do tempo de desenvolvimento de um projeto.
24
2.3.3 PHP
A linguagem de programação PHP foi criada em 1994 por Rasmus Lerdorf. Em seu
início, era formada por um conjunto de scripts feitos para criação de páginas dinâmicas
utilizadas por Rasmus para monitorar o acesso ao seu currículo na internet. À medida
que a ferramenta foi crescendo em funcionalidades, foi escrita uma implementação em
C, a qual permitia às pessoas desenvolverem suas aplicações para web. Em 1995, a
versão, nomeada PHP/FI (Personal Home Pages/Forms Interpreter ), foi disponibilizada
para compartilhamento e também relatórios de bugs.
A segunda versão do PHP foi lançada em novembro de 1997. Naquele momento,
aproximadamente 50 mil domínios já utilizavam a linguagem. No mesmo ano, Andi Gut-
mans e Zeev Suraski, dois estudantes que utilizavam PHP em um projeto acadêmico, re-
solveram ajudar Rasmus no aprimoramento do PHP. O PHP 3 foi lançado em junho de
1998, após os três reescreverem o código-fonte da linguagem. Dentre as características
dessa versão estavam a extensibilidade, a conectabilidade com vários bancos de dados,
novos protocolos, uma sintaxe mais consistente, suporte à orientação a objetos e uma
nova API que possibilitava a criação de novos módulos. No final de 1998, o PHP já fazia
parte de 10% dos domínios da internet e o significado da sigla foi alterado para Hypertext
Preprocessor.
Após o lançamento da versão 3 do PHP, os envolvidos em seu desenvolvimento
focaram em uma reescrita do núcleo do PHP, a fim de melhorar a performance e modula-
ridade em aplicações complexas. O novo núcleo foi batizado como mecanismo Zend. O
PHP 4, baseado neste mecanismo, foi lançado em maio de 2000, trazendo várias melho-
rias e recursos novos, suporte a muitos servidores web, além da abstração de sua API, o
que permitia ser uma linguagem de shell script. Neste momento, o PHP já se encontrava
presente em 20% dos domínios da internet (DALL’OGLIO, 2007).
O PHP 5 foi lançado em 2004 com massivas melhorias no suporte de orientação a
objetos, competindo no quesito com linguagens como C++ e Java. Atualmente, a lingua-
gem encontra-se na versão 8.0, lançada em 2020.
São vantagens do uso do PHP no desenvolvimento de aplicações, segundo (Kinghost,
2018) e (PHP, 2020):
1. Curva de aprendizado: na construção do PHP foram utilizados elementos proveni-
entes das linguagens Perl, C e Java, fazendo com que programadores que já pos-
suem conhecimento em tais linguagens tenham maior familiaridade com o PHP;
2. Robustez: sua versão atual trouxe melhorias de performance, no qual é possível
executar várias funções sem alterar a velocidade do servidor;
3. Código aberto: por se tratar de uma linguagem de código aberto, são feitas me-
lhorias constantes por qualquer programador, facilitando a correção de bugs ou o
25
acréscimo de novas funções;
4. Multiplataforma: conta com versões que rodam em diversos sistemas operacionais,
como distribuições do Linux e Windows;
5. Compatibilidade com bancos de dados: é compatível com inúmeros bancos de
dados, como Oracle, PostgreSQL, MySQL, SQLite e MySQL, não se limitando ape-
nas a estes;
6. Comunidade: conta com uma das comunidades mais ativas dentre as linguagens
mais populares. Também possui uma série de bibliotecas e pacotes disponibilizados
para uso;
7. Hosting: é possível encontrar hospedagem para sistemas PHP em praticamente to-
das as empresas que oferecem serviços de hospedagem, sendo que muitas dessas
empresas inclusive possuem o PHP instalado de forma nativa em seus servidores.
2.3.4 Orientação a objetos
(DALL’OGLIO, 2007) define a orientação a objetos como um paradigma que repre-
senta toda uma filosofia para construção de sistemas. Em linguagens ditas como estrutu-
radas, como Cobol e Pascal, os procedimentos e variáveis são agrupados em um contexto.
Já na orientação a objetos, é utilizada uma ótica mais próxima da real, contendo objetos
e estruturas conhecidas no dia-a-dia e de facilitada compreensão. Ao trabalhar-se com
orientação a objetos é essencial conceituar classes e objetos.
Classe é uma estrutura que define um tipo de dado, podendo conter variáveis (cha-
madas conceitualmente de atributos) e também funções (métodos) para manipular estes
atributos. Podem ser classes: entidades do negócio da aplicação (uma pessoa, por exem-
plo), entidades de interface (como, por exemplo, botões), dentre outras (uma conexão com
base de dados pode ser escrita como uma classe).
Se modelarmos uma classe chamada Pessoa, por exemplo, suas propriedades po-
dem ser: Nome, Altura, Idade, Nascimento, Escolaridade e Salário. Métodos que são fun-
cionalidades da classe podem ser definidos como Crescer(), Formar() e Envelhecer(). No
caso de uma classe Banco, as propriedades podem ser Agencia, Codigo, DataDeCriacao,
Titular, Senha, Saldo e uma flag de cancelamento (Cancela), assim como seus métodos
podem ser Retirar(), Depositar() e ObterSaldo(). A estrutura do código destas duas classes
pode ser vista na Figura 2.2.
26
Figura 2.2 – Representação das classes Pessoa e Banco.
Fonte: Adaptado de (DALL’OGLIO, 2007)
Um objeto contém as mesmas propriedades e estrutura de uma classe, só que
sua estrutura é dinâmica, com atributos podendo alterar valores durante a execução do
programa. Além disso, vários objetos oriundos da mesma classe podem ser declarados.
Essa declaração é chamada de instância, sendo cada objeto uma instância de uma classe.
São nestes objetos que os dados são armazenados.
Considerando o exemplo visto acima, objetos para a classe Pessoa seriam valores
como João, Maria, José... Todos com a mesma estrutura, mas a diferença de valores que
os torna únicos. Para instanciar um objeto no PHP, declara-se uma variável qualquer e
atribui-se o operador new seguido do nome da classe que é alvo da instância. O exemplo
da Listagem 2.1 demonstra estes conceitos em código-fonte.
Listagem 2.1: Criação e instância de uma classe no PHP.
<?php
class Pessoa {
var $Codigo;
var $Nome;
var $Altura;
var $Idade;
var $Nascimento;
var $Escolaridade;
var $Salario;
function Crescer($centimetros ){
$this ->Altura += $centimetros;
}
function Formar($titulacao ){
$this ->Escolaridade = $titulacao;
27
}
function Envelhecer($anos ){
$this ->Idade += $anos;
}
}
// Criação do objeto $carlos
$carlos = new Pessoa;
$carlos ->Codigo = 10;
$carlos ->Nome = "Carlos␣da␣Silva";
$carlos ->Altura = 1.85;
$carlos ->Idade = 25;
$carlos ->Escolaridade = "Ensino␣Médio";
?>
Fonte: Adaptado de (DALL’OGLIO, 2007)
2.3.5 Apache
O Apache é o projeto de servidor HTTP utilizado para visualização e teste de aplicações web. Desen-
volvido baseando-se no httpd do NCSA, é um servidor de código livre que funciona tanto para aplicações
online quanto locais, tendo sua primeira versão lançada em 1995. Atualmente, encontra-se na versão 2.4
(Apache, 2020).
2.3.6 CodeIgniter
O CodeIgniter é um framework de desenvolvimento de aplicações (Application Development Framework )
feito para a construção de aplicações web que utilizam PHP. Um dos maiores objetivos de sua criação é
facilitar e agilizar o processo de desenvolvimento de código, tornando-o muito mais eficaz do que programar
tudo do zero e, para isso, utilizando bibliotecas que possam executar tarefas conhecidas (CodeIgniter, 2019).
O framework permite ao criador de código um foco maior na criatividade do projeto, minimizando o có-
digo necessário nas tarefas básicas. Isso acontece devido às várias funções já implementadas, tendo como
exemplo conexões à base de dados, configurações automáticas, helpers (classes que ”ajudam” o sistema a
funcionar com funcionalidades globais), entre outras. Além disso, o CodeIgniter permite a customização em
certos aspectos, aumentando ainda mais o leque de opções para o desenvolvedor.
O CodeIgniter implementa a arquitetura MVC (Model View Controller) como padrão em seus projetos.
28
2.3.7 Bootstrap
O Bootstrap é um framework de código aberto para desenvolvimento front-end em aplicações web que
utiliza HTML, CSS e Javascript para desenvolvimento de soluções responsivas e de layout limpo e moderno.
Atualmente, está na versão 4 (Bootstrap, 2018). Foi criado em 2011 por engenheiros do Twitter, que tinham
o objetivo de otimizar o desenvolvimento da rede social através de uma estrutura única. Graças ao potencial
alcançado pela ferramenta, uma versão do software foi disponibilizada no Github (Cia Websites, 2017).
Esta ferramenta possibilita a criação de padrões de estilo (temas), que são arquivos prontos com todas
as configurações e classes CSS necessárias para um projeto. Desde que o projeto se mantenha com as
mesmas estruturas de classes e nomes, apenas a mudança do arquivo de folhas de estilo já altera todo o
sistema de acordo com o padrão oferecido. O Bootstrap também tem funções Javascript embutidas para
otimizar sua performance.
Também é possível criar temas próprios, desde que sejam seguidas as regras do Bootstrap. Além disso,
o site possui tutoriais de elementos HTML básicos e ícones que podem ser utilizados no sistema de forma
padronizada.
2.3.8 Banco de dados
Os bancos de dados são definidos como conjuntos de dados integrados que têm por objetivo atender a
uma comunidade de usuários (HEUSER, 1998). Esta é uma solução para evitar redundância de dados, seja
ela controlada ou não controlada, armazenando todas as informações uma única vez, sendo que elas podem
ser acessadas pelos vários sistemas que dela necessitam. O conjunto de arquivos integrados que atendem
a um conjunto de sistemas é conceituado como BD.
O SGBD é o software que incorpora as funções de definição, recuperação e alteração de dados em um
banco de dados. Estes programas contêm operações de interface e comunicação com outros sistemas e
programas que ajudam no gerenciamento do BD e são usados para manter grandes repositórios compar-
tilhados de dados. Assim, todos os programas possuem uma modularização que mantém a manutenção
de programas mais simples, pois a separação de funções torna tudo mais facilmente compreensível, e a
produtividade também aumenta, visto que todas as funções básicas já foram construídas.
No mercado, há vários tipos de SGBD, sendo os de tipo relacional dominantes no mercado (HEUSER,
1998).
Um banco de dados relacional é composto de tabelas ou relações. Alguns dos principais conceitos
dessa abordagem são listados abaixo (HEUSER, 1998):
• Tabelas: Conjunto não ordenado de linhas. Cada linha é composta por uma série de campos (ou
valores de atributo). Cada campo é identificado por um nome, sendo o conjunto de campos das
linhas de uma tabela que possuem o mesmo nome chamado de coluna. A Figura 2.3 mostra as
representações de uma tabela de um banco de dados relacionais;
29
Figura 2.3 – Estrutura de uma tabela em um SGBD.
Fonte: Adaptado de (HEUSER, 1998)
• Chaves: São o conceito básico para estabelecer relações entre linhas de tabelas de um banco de
dados relacional. Podem ser três tipos: primária, cujos valores distingue uma linha das demais dentro
de uma tabela, alternativa, quando mais de uma coluna ou combinações de colunas podem servir
para distinguir uma linha das demais, e estrangeira, cujos valores aparecem necessariamente na
chave primária de uma tabela.
O MySQL é o sistema gerenciador de banco de dados relacional de código aberto usado na maioria das
aplicações gratuitas para gerir suas bases de dados. O serviço utiliza a linguagem SQL, que é a linguagem
mais popular para inserir, acessar e gerenciar o conteúdo armazenado num banco de dados (Techtudo,
2012).
O banco MySQL é totalmente compatível com PHP e suporta operações de cadastro, edição e exclusão
de dados em suas bases, sendo suficiente para o desenvolvimento do sistema. São características do
MySQL (Devmedia, 2013a):
1. Portabilidade: Devido o MySQL ter sido desenvolvido em C e C++, tornou-se extremamente fácil a
portabilidade entre os diferentes sistemas, plataformas e compiladores. Possui também módulos de
interface para múltiplas linguagens, tais como Delphi, Java, Python, PHP, ASP, Ruby e entre outras
linguagens mais;
2. Armazenamento: O MySQL possibilita diversos tipos de tabela para o armazenamento dos dados,
tendo em conta que cada tipo tem suas próprias características, podendo-se escolher o tipo para cada
situação específica;
3. Velocidade: Alta velocidade no acesso dos dados em razão de diversos motivos em seu desenvol-
vimento com tabelas ISAM, que foi substituído pelo novo sistema MyISAM na versão 5 do MySQL, e
InnoDB, além de utilização de caches em consultas, utilizando a indexação BTREE para as tabelas,
algoritmos de busca, entre outros recursos;
4. Capacidade: As tabelas que utilizam MySQL podem armazenar grandes volumes de dados, e o limite
fica por conta somente do tamanho máximo de arquivos que a plataforma que estiver sendo utilizada
puder manipular. Quanto a expressões SQL, o MySQL suporta execuções de script SQL com até 61
milhões de tabelas joins. E, no quesito de velocidade de execução, o MySQL é considerado um dos
mais velozes. O MySQL, por ser um banco de dados poderoso, tem a capacidade de realizar bilhões
de consultas em um único dia em um site e também fazer o processamento de milhões de transações
por minuto;
5. Uso da linguagem SQL em sua estrutura: O MySQL trabalha com a linguagem SQL, sendo ex-
tremamente rápido. E isso foi possível devido a SQL ter sido implementada no MySQL através de
códigos e funções altamente customizadas pelos seus desenvolvedores.
30
2.3.9 HeidiSQL
O HeidiSQL é um software livre que permite ao usuário visualizar e editar dados e estruturas de compu-
tadores rodando SGBDs como MariaDB, MySQL, PostgreSQL e SQLite, sendo criado em 2002 por Ansgar
Becker (HeidiSQL, 2020).
São algumas das funcionalidades do HeidiSQL (HeidiSQL, 2020):
1. Código livre;
2. Conexão a vários servidores em uma única janela;
3. Suporte a vários SGBDs conhecidos mundialmente, como MySQL e PostgreSQL;
4. Configuração dos privilégios para cada usuário;
5. Exportação de códigos gerada de forma limpa, com vários tipos possíveis de arquivos de saída;
6. Sintaxe de comandos customizável;
7. Criação e edição de tabelas, views, rotinas, triggers e eventos.
3 METODOLOGIA E DESENVOLVIMENTO
Este capítulo apresenta as ferramentas utilizadas para a elaboração do sistema proposto. Também
serão mostradas as metodologias utilizadas para apresentar o resultado final.
3.1 ANÁLISE DO PROBLEMA
Dada a sua importância, uma ACG deve ser tratada com o máximo de agilidade nos seus processos. No
entanto, não se vê isso no modelo atual, que consome muitas folhas e requer várias reuniões de colegiado
para que suas etapas sejam executadas.
Para entender o problema, é necessário compreender todos os processos pelos quais uma ACG passa.
Assim, o fluxo de atividades pode ser definido na seguinte sequência:
1. Submissão do pedido: o aluno reúne os documentos necessários, os imprime e entrega ao secretá-
rio ou o responsável por armazenar todos os pedidos. A documentação inclui um formulário comum a
todas as solicitações e os documentos exigidos para o eixo o qual a atividade é atribuída (um sumário
sobre os eixos e as atividades contempladas é apresentado na seção 2.1);
2. Definição do avaliador: a coordenação do curso delibera sobre quais membros do colegiado serão
definidos como avaliador de cada ACG recebida, sendo um para cada atividade;
3. Avaliação da solicitação: o membro assinalado tem um tempo médio de uma semana para ava-
liação, com retorno geralmente dado na próxima reunião do colegiado agendada. Essa avaliação
consiste em verificar se a documentação está correta de acordo com o tipo da atividade, além de
conferir se o relatório (se constar) condiz com a carga horária solicitada pelo aluno.
4. Reuniões do colegiado: as reuniões realizadas pelo colegiado do Curso que contemplam as ACGs
em geral acontecem pelo menos uma vez por semestre. Cada membro do colegiado faz a apreciação
da ACG em avaliação e dá o seu parecer: caso a solicitação seja aprovada, será homologada pela co-
ordenação do Curso; caso a solicitação não seja aprovada, ela retorna para o aluno, o qual é avisado
e orientado por onde necessita corrigir, necessitando uma nova submissão após estes ajustes;
5. Homologação do pedido: após a aprovação pelo colegiado, o pedido é homologado com a carga
horária decidida pela avaliação, sendo então incorporada ao currículo do aluno.
Os passos e processos de envio de uma ACG podem ser visualizados no fluxograma da Figura 3.1.
32
Figura 3.1 – Fluxograma de uma ACG solicitada.
Fonte: Autor do Trabalho
Analisando os passos, são notados alguns problemas que englobam os processos. Estes problemas
mostram o quão importante uma ferramenta para otimização destes passos vem a ser para o curso.
Na parte de submissão, é possível perceber aprimoramentos possíveis do processo, visto que este é
feito de forma completamente manual. Um formulário online, por exemplo, poderia ser implementado ao
menos para cadastro inicial das requisições, a fim de evitar consumo excessivo de papel em relatórios e
certificados de atividades.
Quanto às reuniões e avaliações, o processo é lento, pois além de ter que entregar em mãos os pedidos
para os membros do Colegiado que farão a avaliação, não há um local onde consiga-se fazer uma busca
sobre todas as ACGs aprovadas previamente (seja do aluno em questão, ou dos demais alunos do curso).
Um exemplo de solução seria disponibilizar ao secretário uma interface para controle dos pedidos e como
atribuir avaliadores a eles.
Além disso, a comunicação com o aluno é um fator que deixa a desejar, pois ele só costuma ser avi-
sado do progresso da requisição quando há problemas, não havendo nenhuma forma de todo esse processo
ser acompanhado a cada passo. Da mesma forma, um sistema automatizado poderia ter essa funcionali-
dade através de uma interface, com disparos de e-mails para avisos sobre a mudança de estado de cada
solicitação de ACG.
33
3.2 REQUISITOS
Segundo (PRESSMANN, 2011), a engenharia de requisitos é uma ação de engenharia de software
que se inicia durante a atividade de comunicação (análise do problema) e continua na de modelagem, ser-
vindo como uma ponte entre essas duas etapas, fornecendo aquilo que o usuário deseja em seu produto e
possibilitando entender o que o sistema fornece nessa situação. Estes requisitos são um importante passo
para definir o que guiará o desenvolvimento da aplicação e quais funcionalidades estarão disponíveis na
ferramenta.
Considerando os problemas levantados e a tecnologia disponível para a implementação da solução, a
seguinte tabela de requisitos foi proposta:
Tabela 3.1 – Requisitos funcionais e não-funcionais da solução proposta.
Requisito Tipo
Cadastro de pedidos de ACGs Funcional
Emissão do formulário de pedidos de ACGs Funcional
Verificação de horas complementares do aluno Funcional
Conferir situação de pedidos do aluno Funcional
Conferir situação de pedidos que o professor está envolvido Funcional
Conferir log de atividades do pedido Funcional
Atribuir professores para a avaliação de pedidos Funcional
Avaliar pedidos Funcional
Acesso ao sistema com credenciais dos portais da UFSM Funcional
Homologar solicitações Funcional
O sistema possui sistema de login Funcional
O sistema pode ser acessado por um computador, desde que
este tenha conexão à internet
Não-Funcional
O sistema deve ter uma interface limpa e didática Não-Funcional
O sistema deve possuir rápida interação para com os pedidos Não-Funcional
O sistema deve impedir problemas de concorrência para com
os pedidos
Não-Funcional
Fonte: Autor do trabalho
Inicialmente, definiu-se que o sistema será feito em uma versão web, facilitando o acesso, já que o
sistema requisitará apenas conexão estável à Internet. Além disso, todas as operações efetuadas durante um
processo de cadastro e registro de ACGs precisam ser simuladas no sistema, juntamente com as alterações
na base de dados propostas.
Nessa ideia, também é possível a usuários do tipo Professor avaliar pedidos e conceder os respectivos
pareceres necessários. Outra ação funcional é possibilitar ao aluno visualizar sua situação quanto às horas
de ACG e também a situação de seus respectivos pedidos, uma funcionalidade necessária e vantajosa aos
usuários.
34
3.3 MODELAGEM DO SISTEMA
Após a análise do problema e o levantamento de requisitos, começou a fase de modelagem do sistema
a ser feito. Este processo inclui definir a estrutura do sistema, a estrutura da base de dados utilizada e um
cronograma de desenvolvimento adequado às necessidades.
3.3.1 Projeto
Buscando as melhores formas de acesso para o sistema, definiu-se que o mesmo seria feito em forma
de aplicação web devido à disponibilidade de ferramentas e funções existentes nesse paradigma de progra-
mação.
Com isso, foi decidido que o sistema seria feito na linguagem de programação PHP, utilizando o fra-
mework CodeIgniter (CodeIgniter, 2019), visto que essa ferramenta proporciona ótimos modos de organi-
zação e propõe soluções utilizando o MVC. O framework possui, inclusive, uma série de bibliotecas com
funções comuns já implementadas em seu núcleo, potencializando o processo de desenvolvimento de siste-
mas.
Quanto aos estilos (folhas de estilo CSS), foi utilizado o Bootstrap, framework mais popular para a
linguagem (Bootstrap, 2018). Nesse caso, um tema já existente foi importado, possuindo todos os elementos
precisos para que o sistema possua uma interface amigável e simples.
Para a estrutura do sistema, foi definido um padrão com três módulos: Aluno, Professor e Secretário.
Esse método possibilita melhor organização, seja na base de dados ou nas funcionalidades oferecidas pelo
sistema.
Estes módulos são modelados por meio de diagramas de casos de uso, que ajudam a determinar
a funcionalidade e as características do software sob o ponto de vista do usuário. Estes diagramas são
uma visão geral de todos os casos de uso e como estão relacionados, fornecendo uma visão geral da
funcionalidade do sistema. Cada usuário, no diagrama, é visto como um ator (PRESSMANN, 2011).
3.3.1.1 Módulo aluno
O módulo Aluno possibilita cadastrar pedidos, verificar a situação dos mesmos, além de verificar um
histórico com os pedidos. Também é possível verificar suas horas de atividades complementares juntamente
à base de dados da universidade, em caso de conexões com APIs disponíveis.
Cabem ao módulo de aluno as seguintes funções:
• Cadastro de pedidos;
• Edição de pedidos;
• Exclusão de pedidos;
• Consulta de horas de ACGs;
• Consulta de situações dos seus pedidos feitos;
• Login/Logoff do sistema.
As atividades incluídas no módulo podem ser vistas no diagrama de casos de uso da Figura 3.2.
35
Figura 3.2 – Diagrama de casos de uso para o usuário Aluno.
Fonte: Autor do Trabalho
3.3.1.2 Módulo professor
O módulo Professor possibilita verificar pedidos em que ele esteja envolvido como coordenador, além
de ver os pedidos que ele tem de avaliar. A avaliação é realizada em uma tela semelhante à de cadastro,
com dois elementos principais: Observações e Situação (aprovado, reprovado...).
O usuário Professor também pode fornecer parecer de atividades que é coordenador e, caso este usuá-
rio seja o relator do colegiado, emitir pareceres que encaminham o pedido pra o processo de homologação.
Cabem ao módulo de professor as seguintes funções:
• Acompanhamento de pedidos que é coordenador;
• Acompanhamento de pedidos que é avaliador;
• Avaliação de pedidos;
• Conceder parecer para os projetos que é coordenador;
• Conceder parecer para os projetos como relator (usuário relator do colegiado);
• Login/Logoff do sistema.
36
As atividades incluídas no módulo podem ser vistas no diagrama de casos de uso da Figura 3.3
Figura 3.3 – Diagrama de casos de uso para o usuário Professor.
Fonte: Autor do Trabalho
3.3.1.3 Módulo secretário
O módulo Secretário possibilita realizar consultas de horas complementares de qualquer aluno, além
de ter uma visão bem detalhada (ao estilo dashboard) de todos os pedidos, podendo encaminhar estes ao
professor responsável.
É possível, também, acessar e manipular todos os pedidos existentes, além de modificar configurações
que sejam úteis para o sistema de acordo com as normativas regentes.
Cabem ao módulo do secretário as seguintes funções:
• Cadastro de pedidos;
• Edição de pedidos;
• Exclusão de pedidos;
• Consulta de horas de ACGs para qualquer aluno;
• Consulta de situações de todos os pedidos existentes;
• Homologação de pedidos;
• Modificar configurações do sistema;
• Login/Logoff do sistema.
As atividades incluídas no módulo podem ser vistas no diagrama de casos de uso da Figura 3.4
37
Figura 3.4 – Diagrama de casos de uso para o usuário Secretário.
Fonte: Autor do Trabalho
3.3.2 Base de dados
O sistema prevê conexões à base de dados nos momentos da manipulação dos pedidos. A estrutura
utilizada para a base de dados é a relacional e o SGBD escolhido foi o MySQL. Outros recursos utilizados
foram o InnoDB como mecanismo de armazenamento e, para controle de alterações, transactions.
A base de dados do sistema ACG possui uma tabela principal, chamada pedidos. Esta tabela possui
todos os dados de um pedido e as relações entre usuários e pedidos. Quanto aos usuários, foi feita uma
única tabela com um modificador de tipo entre elas.
Quanto aos anexos de cada pedido, uma tabela com documentos foi planejada, possuindo todas as
relações com o pedido e o caminho em que o upload do arquivo é feito. O documento é armazenado
internamente no sistema e seu caminho é salvo na base de dados, além do identificado do pedido ao qual
ele é pertencente.
Cada pedido precisa ter relações com um usuário aluno, que fez um pedido, um usuário professor
coordenador (caso a atividade exija) e um usuário professor avaliador (este sempre obrigatório). Existem
outras relações com as classificações de atividades da normativa do curso, visto que os tipos de atividades
são dados de forma fixa, e com a situação principal que o pedido se encontra (também fixa de acordo com
uma tabela predefinida).
A tabela logs possui todas as atividades e situações as quais um pedido passou, armazenando tudo
38
isso como um histórico próprio. Essa tabela possui relações com o pedido escolhido, com o usuário que
realizou a modificação e com a situação em que está o pedido no dado momento, além de ter um timestamp
para monitorar as modificações e sua cronologia.
Para consulta de horas do aluno, foi projetada a tabela de horas, que armazena o identificador do aluno e
a carga horária conquistada em cada eixo. Além disso, as cargas horárias necessárias para cada eixo podem
ser configuradas na tabela para configurações, que também armazena a matrícula do professor relator do
colegiado.
Outras tabelas projetadas são a de classificações de atividades e as de situações, com valores predefi-
nidos que são usados pelo sistema.
O modelo proposto para a base de dados do sistema pode ser visto na Figura 3.5.
Figura 3.5 – Modelo da base de dados do sistema.
Fonte: Autor do Trabalho
3.3.3 Cronograma de desenvolvimento
O cronograma de desenvolvimento do aplicativo foi focado no conceito de sprints da metologia Scrum.
Assim sendo, cada sprint significa uma nova versão do sistema, com cada uma dessas versões tendo uma
39
série de funções implementadas e um prazo de desenvolvimento. O versionamento do sistema e seus
respectivos deadlines podem ser vistos abaixo, na Tabela 3.2.
Tabela 3.2 – Cronograma de desenvolvimento do ACG-CC.
Versão Novidades Deadline
0.5 Início do desenvolvimento e estruturação dos módulos. Im-
portação via CodeIgniter e criação das classes model, view e
controller necessárias
30/10/2020
0.6 Implementação de telas (views) e funções atribuídas. Cons-
trução de menus e aplicação dos estilos do Bootstrap
15/11/2020
0.7 Criação de modelos de cadastro de pedidos e avaliações,
além dos históricos de pedidos e atividades disponíveis
30/11/2020
0.8 Correções no cadastro e na visualização de pedidos, possibi-
lidade do secretário verificar as horas de todos os alunos e de
assinalar professores às atividades, classe de login/logout e
outros ajustes
15/12/2020
0.9 Inserção de anexos aos pedidos, emissão do formulário de
pedido de ACGs via tela de cadastro, otimizações na interface
31/12/2020
1.0 Módulo de configurações, possibilidade de configurar profes-
sor relator e horas necessárias para cada eixo, sistema de no-
tificações via e-mail
14/01/2021
Fonte: Autor do trabalho
3.4 DESENVOLVIMENTO DO SISTEMA
Esta seção visa mostrar todas as fases do desenvolvimento do projeto e como todas as soluções foram
implementadas.
Beneficiando-se das funcionalidades apresentadas por frameworks e buscando um desenvolvimento
mais flexível, o CodeIgniter foi usado, após a criação de um projeto do zero com seu núcleo. Aos poucos,
cada módulo foi ganhando suas classes model e controller, além de suas diversas views.
Buscando uma interface limpa, robusta e responsiva, o Bootstrap foi aplicado. Para isso, foi usada um
template disponível no Bootswatch, website que possui bibliotecas e outros utilitários especialmente para
Bootstrap.
Para a manipulação da base de dados a nível de interface para melhor interação, foi utilizado o aplicativo
HeidiSQL (HeidiSQL, 2020). O prompt de comandos do MySQL também foi utilizado para alguns casos.
Outras bibliotecas e ferramentas utilizadas são descritas ao longo desta seção.
40
3.4.1 Helpers - Bibliotecas adicionais
Helpers são bibliotecas adicionais do CodeIgniter. Estas ferramentas podem ser carregadas automati-
camente ao inicializar o sistema e possibilitam chamadas de funções ”globais” utilizadas em vários módulos
distintos. Estes ”ajudantes” podem ser carregados predefinidamente ou criados pelo usuário. No ACG-CC,
alguns helpers foram utilizados, com as bibliotecas de formulário e upload já carregadas pelo CodeIgniter.
Além disso, foram implementadas as seguintes bibliotecas: pedido, log, documento, e-mail e database.
O helper para pedidos implementa funções básicas para cadastro e visualização dos pedidos. São
funções de correção de datas e visualização de arquivos de acordo com o eixo escolhido.
O helper para logs possui todas as interações do sistema com o banco de logs, com as funções do
mesmo sendo chamadas a cada modificação nova.
O helper para documentos utiliza as funções de upload para inserir novos arquivos no sistema e arma-
zenar suas informações na base de dados. Além disso, também emite documentos utilizando a biblioteca
TCPDF.
O helper para e-mails importa uma classe vinda do PHPMailer para envio de mensagens. Ela contém
todas as funções necessárias e utilizadas a cada interação do sistema com a base de dados e necessidade
de avisos ao usuário.
O database helper é uma classe auxiliadora à base de dados. Todas as funções de busca para qualquer
tabela são armazenados nessa classe para evitar repetição de código ou até mesmo confusão entre módulos.
3.4.2 Versão 0.5
Esta subseção apresenta o que foi desenvolvido para a versão 0.5 do sistema. Esta versão foi entregue
no dia 30/10/2020.
3.4.2.1 Organização do sistema
O sistema aplica os conceitos visto no MVC de Model, View e Controller da seguinte forma:
• Model : São todas as interações e requisições que o sistema faz com a base de dados. Toda vez que
um pedido é cadastrado ou qualquer alteração nele é feita, a classe de model do módulo é chamada.
A Listagem 3.1 exemplifica as funções existentes da classe model no módulo Aluno;
Listagem 3.1: Classe model do módulo Aluno
<?php
class aluno_model extends CI_Model {
public function __construct (){
$this ->load ->database ();
}
public function login($matricula , $senha ){}
public function configura_arquivos($arq ){}
41
public function cadastra_pedido($arquivos ){}
public function exclui_pedido($id ){}
public function atualiza_pedido (){}
}
?>
Fonte: Autor do Trabalho
View : São as páginas que o usuário vê. Cada página diferente do sistema é uma view por si só,
sendo chamada pelo controller toda vez que alguma página precisa ser mostrada. O módulo Aluno,
por exemplo, possui as seguintes views:
– ajuda.php;
– ativos.php;
– cadastrar.php;
– editar.php;
– historico.php;
– horas.php;
– index.php;
– login.php;
– pedidos.php;
– visualizar.php;
Controller : Como o nome diz, controla as informações que o usuário vê, determinando quando é
necessário mostrar uma view ou realizar uma operação de model. Quando um cadastro é feito,
por exemplo, a função que consta no model para cadastro é chamada, mas antes disso a view de
cadastros precisa ser chamada. Clicando o botão, aí sim a função de cadastro é chamada. A classe
controller do módulo de aluno consiste nas seguintes funções:
– index();
– login();
– logout();
– pedidos_ativos();
– historico_de_pedidos();
– visualizar(id do pedido);
– cadastrar();
– horas();
– deletar(id do pedido);
– editar(id do pedido);
42
– atualizar().
A Figura 3.6 mostra um exemplo do funcionamento do MVC no sistema.
Figura 3.6 – MVC aplicado ao ACG-CC.
Fonte: Autor do Trabalho
3.4.2.2 Situações de um pedido
Para facilitar no acompanhamento de situações, foi implementada uma tabela da base de dados com
nomenclaturas de situações que um pedido pode se encontrar. Todo pedido possui uma chave estrangeira.
Quanto à busca, estas situações podem dividir-se em:
• Ativas: Aguardando parecer do coordenador, Aguardando avaliação, Em avaliação, Aguardando pa-
recer do relator, Correção necessária, Aguardando homologação;
• Inativas: Documentação rejeitada, Homologado, Arquivado, Homologado com carga horária reduzida.
Outro conceito envolvido nas situações é o de sequências. Alguns tipos de situação só são atingíveis
em certos estágios do processamento de pedido. Um pedido não pode, por exemplo, passar de ”Aguardando
avaliação” para ”Homologado” diretamente.
Ao cadastrar um pedido, o pedido assume o estado de ”Aguardando avaliação”, podendo ir para os
estados ”Correção necessária” (voltando ao primeiro estágio), ou avançando para "Em avaliação". Caso o
projeto possua coordenador, o parecer deste deve ser dado antes do pedido ser avaliado.
Após avaliação, o membro responsável define a nova situação. Se a requisição está de acordo com a
normativa, o pedido avança para o estado de ”Aguardando parecer do relator” para apreciação do colegiado.
Caso o pedido seja rejeitado, este pode ser completamente descartado com a opção ”Documentação rejei-
tada” ou configurado para ”Correção necessária”, sendo encaminhado diretamente para reenvio por parte do
aluno.
Após a apreciação do colegiado e parecer do relator, este pedido pode receber um pedido para correção
ou ser descartado. Caso seja aprovado, ele passa para a situação ”Aguardando homologação”, alterada para
”Homologado” após o pedido ser processado.
A Figura 3.7 representa os passos de organização das situações.
43
Figura 3.7 – Situações possíveis para um pedido e sua ordem.
Fonte: Autor do Trabalho
3.4.3 Versão 0.6
Esta subseção apresenta o que foi desenvolvido para a versão 0.6 do sistema. Esta versão foi entregue
no dia 15/11/2020.
3.4.3.1 Estruturas dos menus
Os menus foram implementados utilizando navbars do HTML reunindo seções específicas para cada
módulo. Quanto à estrutura, toda vez que um dos menus é chamado, a classe Control do módulo é acionada,
conferindo os dados e qual View chamar.
• Aluno: Início, Horas, Cadastro de Pedidos, Pedidos Ativos, Histórico de Pedidos, Ajuda, Logout ;
44
• Professor: Início, Pedidos coordenados, Pedidos avaliados, Ajuda, Logout ;
• Secretário: Início, Horas, Cadastro de Pedidos, Pedidos Ativos, Histórico de Pedidos, Ajuda, Logout.
3.4.3.2 Telas
Quanto às telas disponíveis no sistema, uma relação pode ser vista abaixo. Todas são vistas como um
arquivo de view, todos localizados na pasta de seu respectivo módulo, conforme apresenta a Tabela 3.3.
Tabela 3.3 – Relação de telas do módulo aluno.
Tela Descrição Arquivo
Início Página inicial contendo informações perti-
nentes
index.php
Horas Visualização de horas do aluno horas.php
Cadastro de pedi-
dos
Formulário para cadastro de pedidos no
sistema
cadastrar.php
Pedidos ativos Mostra pedidos do aluno que possuam si-
tuações descritas como ativas
ativos.php
Histórico de pedi-
dos
Mostra todos os pedidos do aluno historico.php
Ajuda/Sobre Links úteis, normas e informações sobre o
sistema
ajuda.php
Edição de Pedidos Formulário contendo informações sobre o
pedido com possibilidade de edição
editar.php
Visualizar Pedidos Visualização de um pedido visualizar.php
Login Tela de Login login.phpFonte: Autor do trabalho
Para o módulo de professor, a relação das telas é apresentada na Tabela 3.4.
45
Tabela 3.4 – Relação de telas do módulo professor.
Tela Descrição Arquivo
Início Página inicial contendo informações perti-
nentes
index.php
Horas Visualização de horas do aluno horas.php
Avaliação de pedi-
dos
Formulário para avaliação de pedidos no
sistema
avaliar.php
Pedidos para avali-
ação
Mostra pedidos aguardando avaliação do
professor
ativos.php
Pedidos (coordena-
dor)
Mostra todos os pedidos em que o profes-
sor é coordenador
historico.php
Parecer (coordena-
dor)
Mostra as informações do formulário e dis-
ponibiliza o parecer como coordenador
parecer_coordenador.php
Parecer (relator) Mostra as informações do formulário e dis-
ponibiliza o parecer como relator
parecer_relator.php
Ajuda/Sobre Links úteis, normas e informações sobre o
sistema
ajuda.php
Visualizar Pedidos Visualização de um pedido visualizar.php
Login Tela de Login login.phpFonte: Autor do trabalho
Em relação ao módulo de secretário, a Tabela 3.5 descreve a relação de telas.
46
Tabela 3.5 – Relação de telas do módulo secretário.
Tela Descrição Arquivo
Início Página inicial contendo informações perti-
nentes
index.php
Horas Visualização de horas para qualquer aluno horas.php
Cadastro de pedi-
dos
Formulário para cadastro de pedidos no
sistema
cadastrar.php
Pedidos ativos Mostra pedidos do aluno que possuam si-
tuações descritas como ativas
ativos.php
Pedidos pendentes Mostra pedidos marcados como penden-
tes
pendentes.php
Histórico de pedi-
dos
Mostra todos os pedidos do aluno historico.php
Ajuda/Sobre Links úteis, normas e informações sobre o
sistema
ajuda.php
Edição de Pedidos Formulário contendo informações sobre o
pedido com possibilidade de edição
editar.php
Homologação de
Pedidos
Formulário contendo informações sobre o
pedido com possibilidade de homologação
homologar.php
Visualizar Pedidos Visualização de um pedido visualizar.php
Login Tela de Login login.phpFonte: Autor do trabalho
3.4.3.3 Folhas de estilo
A aplicação das folhas de estilo via Bootstrap deu-se por importação do tema Flatly, disponível no site
Bootswatch (Bootswatch, 2020). Com isso, a interface foi redefinida com os benefícios do framework CSS.
Um comparativo de uma das páginas do sistema (cadastro de pedidos) antes e depois da aplicação do estilo
pode ser vista na Figura 3.8
47
Figura 3.8 – A página de cadastros antes e depois da importação das folhas de estilo doBootstrap.
Fonte: Autor do Trabalho
3.4.4 Versão 0.7
Esta subseção apresenta o que foi desenvolvido para a versão 0.7 do sistema. Esta versão foi entregue
no dia 30/11/2020.
3.4.4.1 Cadastro de pedidos
A tela para cadastro de pedidos considerou todos os elementos do formulário para pedidos de ACGs.
O aluno pode inserir manualmente os valores de local, carga horária, data e início da atividade e atividades
desenvolvidas. Além disso, ele pode escolher em um select qual o tipo da atividade a ser pedida, sendo
este controlado por uma função do Javascript que confere os documentos necessários para a classificação
escolhida.
Os documentos são adicionados em formas de input e tratados diretamente usando a biblioteca FILES
do PHP.
Após o processo, a classe controller do módulo de alunos é chamada, inserindo os dados na base de
dados via model, utilizando a função de cadastro.
A representação vista na Figura 3.9 mostra uma comparação entre o cadastro visto no ACG-CC e como
é no formulário atual para entender melhor como a tela foi projetada e a distribuição dos dados.
48
Figura 3.9 – Comparação entre a página de cadastro de sistema e o formulário de pedidos.
Fonte: Autor do Trabalho
3.4.4.2 Visualização de pedidos
Esta view é utilizada por todos os módulos e por várias outras telas como base. Ela reúne todos os
dados de um pedido e os mostra na tela. Para realizar isso, o controller é chamado e, verificando que
existe um id de pedido sendo processado, busca todos os dados deste pedido junto à model e aciona a view
responsável para mostrar os dados.
Os dados mostrados nesta tela não são editáveis. No entanto, acionando funções de edição/exclusão e
outras de manipulação isso é possível.
3.4.4.3 Horas do aluno
A view horas.php pode ser acessada por qualquer aluno. Nela, é possível receber as situações em cada
eixo complementar, buscando dados diretamente da tabela de horas. O secretário pode pesquisar as horas
de qualquer aluno, possuindo um campo para facilitar essa busca.
A tela vista na Figura 3.10 demonstra o processo para o aluno.
49
Figura 3.10 – Tela para verificação de horas do aluno.
Fonte: Autor do Trabalho
3.4.4.4 Avaliação de pedidos
Esta é a primeira das partes que utiliza a visualização do pedido. É realizado o mesmo processo para
mostrar os dados e, após isso, são desenhados os campos contendo parecer e a avaliação do professor
contendo a ação necessária para continuar o processo.
3.4.4.5 Registro de atividades - log
O sistema possui uma forma de garantir que as ações feitas sejam registradas. Estas informações são
salvas na tabela ”log” da base de dados via helper de logs (3.4.1). A função inserir_log() é a responsável
por estas ações, sendo chamada a cada vez que um pedido é cadastrado, editado (neste caso, avaliações e
outras ações semelhantes são consideradas como edição) ou excluído.
São informações pertinentes ao histórico do pedido o seu identificador, a situação em que o pedido se
encontra, a matrícula do usuário que registrou estas ações, observações cadastradas e um carimbo de data
e hora da ação (timestamp). A Figura 3.11 mostra a tabela de ações de um pedido aprovado com todas as
interações registradas.
50
Figura 3.11 – Tabela de logs para um pedido exemplo
Fonte: Autor do Trabalho
3.4.5 Versão 0.8
Esta subseção apresenta o que foi desenvolvido para a versão 0.8 do sistema. Esta versão foi entregue
no dia 15/12/2020.
3.4.5.1 Sistema de usuários
O sistema possui um sistema de login e senha inspirado no utilizado pelos portais da UFSM. O usuário
inserido é o número de matrícula do usuário, e a senha é a mesma para os portais. Na fase do desenvol-
vimento, foram adicionadas estes dados às tabelas de usuários para que os testes sejam realizados. Após
a entrega do sistema, o ideal é realizar uma importação de dados do portal do aluno para as bases do
ACG-CC.
No PHP, estes atributos podem ser controlados pela biblioteca session, implementada com userdata
no CodeIgniter. Toda vez que um usuário tenta acessar o sistema, os dados de usuários são solicitados
pelo controller do módulo. Caso não exista nada, o módulo de controle redireciona o usuário à página de
login. Quanto ao processo, o usuário informa seus dados e o controller confere os mesmos junto ao model,
fazendo uma requisição para a base de dados buscando entender se aqueles dados existem no sistema.
Caso existam, é realizado o armazenamento dos dados de matrícula e nome do usuário na variável userdata.
Em termos de algoritmo, o processo foi realizado da seguinte forma: toda vez que uma função encon-
trada no controller do módulo é acionada, o sistema verifica os dados da sessão. Se estes dados já existem,
o usuário é considerado logado e a view é carregada. Se não, a tela de login aparece para proteger a página.
Este processo pode ser visto no Algoritmo 3.
51
Algoritmo 1: Processo de reconhecimento da sessão
1 início;
2 solicita o acesso ao sistema;
3 confere dados existentes na sessão;
4 se usuario_logado então5 mostra a view requisitada pelo usuário;
6 senão7 mostra a página de login;
8 reconhece e armazena os novos dados;
9 fim
Em termos de código, a Listagem 3.2 demonstra a utilização destes recursos e a chamada de funções
conforme dados do usuário.
Listagem 3.2: Dados de login no ACG-CC.
<?php
public function visualizar($id){
$dados[’pedido ’] = get_pedidos($id);
$dados[’documentos ’] = get_documentos($id);
$dados[’logs’] = get_logs($id);
if(empty($dados[’pedido ’])){
show_404 ();
}
$dados[’titulo ’] = "Pedido␣".$dados[’pedido ’][’codigo_hash ’];
$this ->load ->view(’templates/cabecalho ’);
if($this ->session ->userdata(’aluno_logado ’)){ // aluno logado no sistema
$this ->load ->view(’templates/menu_aluno ’);
$this ->load ->view(’aluno/visualizar ’, $dados );
} else{ //não está logado , chama as funções e views de login
$dados[’titulo ’] = ’ACG␣-␣Login ’;
$this ->load ->view(’aluno/login ’, $dados );
}
$this ->load ->view(’templates/rodape ’);
}
?>
Fonte: Autor do Trabalho
O design de tela de login usado para todos os módulos pode ser visto na Figura 3.12.
52
Figura 3.12 – Tela de login do ACG-CC.
Fonte: Autor do Trabalho
3.4.5.2 Assinalar professores
A Figura 4.4 demonstra o design relativo à designação de um professor a uma tarefa.
Figura 3.13 – Módulo para assinalar professores a pedidos (juntamente com a opção devisualizar pedidos).
Fonte: Autor do Trabalho
3.4.5.3 Algoritmo para escolha dos professores
Para definir um algoritmo que possa aconselhar membros do colegiado para avaliações de pedidos,
vários recursos são levados em conta. Estes tópicos são:
1. O professor é o coordenador deste pedido?
2. Quantos pedidos estão em mãos deste professor?
3. Sabendo quais os pedidos assinalados ao professor, qual a carga horária destes?
53
4. Sabendo quais os pedidos assinalados ao professor, qual o peso da documentação destes?
O primeiro padrão é cortar professores coordenadores da relação. Após isso, organiza-se a relação
de acordo com o número de pedidos do professor. Por último, os pesos destes pedidos são avaliados. O
peso de um pedido é um conceito referente ao tamanho da documentação necessária para aceitação de um
pedido, assim como a quantidade de horas solicitadas. Os pesos, por documentação, são listados abaixo:
• Peso 1: Outras atividades a nível de colegiado;
• Peso 2: Participação em órgãos colegiados e diretórios acadêmicos;
• Peso 3: Participação em eventos;
• Peso 4: Atuação em núcleos temáticos, atividades de extensão, monitoria;
• Peso 5: Estágios extracurriculares, atividades de iniciação científica.
Quanto à carga horária, os pesos são os seguintes:
• Peso 1: Pedidos com carga horária pedida menor que 50 horas;
• Peso 2: Pedidos com carga horária pedida maior que 50 horas e menor que 100 horas;
• Peso 3: Pedidos com carga horária pedida maior que 100 horas e menor que 150 horas;
• Peso 4: Pedidos com carga horária pedida maior que 150 horas;
O secretário pode buscar o professor recomendado via botão na tela ”assinalar” (Figura 3.14). Nele, uma
função Javascript é chamada, fazendo uma requisição Ajax que retorna os professores da base e calcula os
valores.
Figura 3.14 – Opção para busca automática de professores.
Fonte: Autor do Trabalho
Estes valores são multiplicados e, após o cálculo, o professor com melhor pontuação é retornado. A
nível de código, o Algoritmo 2 mostra estes processos na forma de pseudocódigo.
54
Algoritmo 2: Processo de escolha de professores
1 início;
2 busca todos os professores cadastrados no sistema;
3 exclui o professor coordenador da contagem;
4 reúne informações de pedidos ativos e suas respectivas cargas horárias;
5 utiliza uma função para cálculo dos pesos;
6 se conseguiu_resultados então7 retorna dados em forma de menu, com o primeiro resultado sendo o professor melhor
recomendado para a atividade;
8 senão9 retorna erro;
10 fim
3.4.5.4 Concorrência na base de dados
Para gerir o problema de concorrência na alteração de dados, a recurso do MySQL de transactions foi
utilizado. Este método garante integridade dos dados manipulados mantendo modificações apenas após
todo um procedimento ser concluído. Neste caso, um cadastro de pedido, que manipula várias tabelas simul-
taneamente, não sofre alterações caso seja manipulado por dois usuários ao mesmo tempo. Isto acontece
porque a transaction responsável insere as modificações apenas após todas as inserções forem concluídas.
Caso alguma retorne um erro, todas as alterações são desfeitas (MySQL, 2018).
O CodeIgniter possui um método próprio para chamar estes métodos. A Listagem 3.3 demonstra isso a
níveis de código.
Listagem 3.3: Transactions no ACG-CC.
<?php
$this ->db ->trans_begin ();
$this ->db ->insert(’pedidos ’, $dados );
$last_id = $this ->db ->insert_id ();
foreach($arquivos as $key => $arquivo ){
insere_arquivo($arquivo );
}
inserir_log($this ->db ->insert_id (), $id_situacao , "Pedido␣criado",
$this ->session ->userdata(’matricula ’));
// Caso haja algum problema , reverte
if ($this ->db ->trans_status () === FALSE ){
$this ->db ->trans_rollback ();
}
55
else {
$this ->db ->trans_commit ();
}
?>
Fonte: Autor do Trabalho
3.4.5.5 Permissões de acesso
Seguindo um padrão semelhante ao login, outra verificação que precisa ser feita é a de o que está
sendo visto pelo usuário. Nesse caso, mais especificamente, se o que está sendo visto pelo usuário pode
ser visualizado por ele. Garantir acesso apenas aos pedidos de um único usuário é uma preocupação para
elementos acadêmicos tão importantes.
Com isso, foi definido que cada pedido possui uma chave hash para acesso via URL. Isso dificulta a
visualização de pedidos via link diretamente, com esse padrão hash sendo gerado ao inserir um pedido.
Além disso, a verificação de matrícula é feita sempre juntamente com a de login. Se o pedido não pertence
ao usuário, a página de acesso negado é mostrada. Este algoritmo é visto na Figura 3.
Algoritmo 3: Processo de proteção a acessos
1 início;
2 solicita o acesso ao módulo;
3 confere dados existentes na sessão;
4 se matricula_do_usuario == matricula_registrada_do_pedido então5 mostra a view requisitada pelo usuário;
6 senão7 mostra a página de erro (acesso_negado);
8 encerra execução;
9 fim
3.4.6 Versão 0.9
Esta subseção apresenta o que foi desenvolvido para a versão 0.9 do sistema. Esta versão foi entregue
no dia 31/12/2020.
3.4.6.1 Anexos
Para a inserção de anexos no sistema, foi elaborada uma classe em forma de helper e uma tabela na
base de dados para documentos. O helper, descrito em 3.4.1, possui as funções para inserção de anexos à
base de dados, com funções que verificam as necessidades de documentação para cada tipo e retornam a
situação (se falta algo ou se o pedido pode ser cadastrado) a cada tentativa de cadastro.
Os anexos são inseridos na tabela documentos, que possui as informações de nome, caminho e pedido.
Além disso, uma tabela de tipos, assim como a de situações, verifica o que é cada arquivo inserido e mostra
estas informações ao usuário, caso ele queira visualizar o pedido pós-cadastro. Para a inserção de docu-
mentos, foi utilizada o helper de upload, que salva os arquivos em uma pasta do projeto. Este método de
56
inserção dos arquivos no local do projeto é temporário, visto que existem outras opções de armazenamento
nos servidores da UFSM.
A Figura 3.15 situa estes arquivos junto à base e à interface do sistema.
Figura 3.15 – Documentos no ACG-CC.
Fonte: Autor do Trabalho
3.4.6.2 Emissão do Formulário
Assim como os anexos, a emissão do formulário também é feita via helper. Esta função é importada via
TCPDF (TCPDF, 2020), uma biblioteca própria que gera PDFs utilizando comandos comuns ao PHP e que
”desenham” seus dados utilizando HTML.
No caso de uma emissão feita junto ao sistema, é feita uma requisição com os dados de um pedido e
os mesmos escritos no documento, que segue a formatação de um formulário de pedidos.
3.4.7 Versão 1.0
Esta subseção apresenta o que foi desenvolvido para a versão 1.0 do sistema. Esta versão foi entregue
no dia 14/01/2020.
3.4.7.1 Configurações
Aos usuários do tipo secretário, é permitido acessar uma nova tela: configurações. Nela, o usuário
pode alterar, até o momento, o professor relator do colegiado e as horas necessárias para cada atividade
complementar, se preciso.
57
O processo é como uma edição de cadastro, interagindo diretamente com a tabela de configurações no
BD.
Esta tela é totalmente configurável, visto que é ditada por regras da base de dados. Existem tipos de
configurações, com estes tipos podendo ser uma categoria ou uma configuração. As categorias transformam-
se em fieldsets na camada de visualização, enquanto configurações são campos configuráveis que possuem
uma categoria como pai (assim, organizando os campos dentro do fieldset da categoria). Também é possível
configurar o tipo de campo que uma configuração aceita, além destas possuírem um valor que define a con-
figuração. Ou seja, é uma interface totalmente customizável de acordo com as necessidades do colegiado.
A tela de configurações pode ser vista na Figura 3.16.
Figura 3.16 – Configurações disponíveis no ACG-CC.
Fonte: Autor do Trabalho
3.4.7.2 Notificações
Para envio de e-mails notificando alterações, o sistema utilizou a classe PHPMailer (PHPMailer, 2020),
disponível via Github e de código aberto. O helper é chamado toda vez que uma alteração de log é efetuada,
58
processando os dados do pedido, salvando eles em uma instância de e-mail, promovendo ajustes necessá-
rios para a conexão no momento do envio e enviando a mensagem ao usuário informando a situação em que
o pedido se encontra naquele momento e o que foi feito. A Figura 3.17 mostra um exemplo de notificação
enviada pelo ACG-CC.
Figura 3.17 – Exemplo de e-mail enviado.
Fonte: Autor do Trabalho
4 ESTUDOS DE CASO
Neste capítulo, são apresentados os estudos de três casos comuns no sistema. Primeiramente, um
exemplo completo de cadastro e seus processos é mostrado. A seguir, um pedido que possui documentação
incompleta e precisa de correção. Na sequência, é realizado o detalhamento de um pedido que teve sua
carga horária reduzida após julgamento na avaliação.
4.1 CADASTRO COMPLETO
Esta seção apresenta e detalha as ações de usuário e comportamentos do sistema desde o início de
um pedido até sua homologação, sendo este bem-sucedido.
4.1.1 Cadastro
Após acessar o sistema, o usuário Aluno acessa o cadastro de pedido nos menus Pedido > Cadastro. Ali,
ele insere os dados necessários para cadastro e envia os documentos pedidos. No exemplo, para abranger
o parecer do coordenador, a atividade escolhida é uma de monitoria.
Feito isso, o pedido é cadastrado na base. A situação do pedido, neste momento, é ”Aguardando parecer
do coordenador”, assim, o pedido fica listado como ativo (Figura 4.1) e disponível no menu Pedidos > Ativos.
Figura 4.1 – Página de pedidos ativos após o cadastro de uma ACG.
Fonte: Autor do Trabalho
4.1.2 Avaliação
Após a inserção do pedido, o professor responsável pelo projeto é notificado. Ele pode acessar o pedido
seguindo o caminho Pedidos > Pedidos que coordeno e, ao ver a breve introdução do projeto, clicando no
botão ”Parecer” (Figura 4.2).
60
Figura 4.2 – Interface do usuário para fornecer o parecer como coordenador.
Fonte: Autor do Trabalho
Após fornecer o parecer de aprovação, o pedido é encaminhado para a situação ”Aguardando avali-
ação”, possibilitando a revisão do secretário responsável via menu Pedidos > Ativos, na opção ”Revisar”.
Caso a documentação esteja situada como ok, clicando na opção ”Assinalar” (Figura 4.3), o secretário pode
escolhendo o professor responsável para avaliação na tela vista na view assinalar.php (Figura 4.4).
Figura 4.3 – Tela de pedidos com a possibilidade de assinalar professor.
Fonte: Autor do Trabalho
O professor é notificado e inicia o processo de avaliação. A situação do pedido é alterada para ”Em
avaliação”.
61
Figura 4.4 – Tela de visualização do pedido com a opção de assinalar professores.
Fonte: Autor do Trabalho
O professor realiza a avaliação e, aprovando o pedido, este é encaminhado para a situação ”Aguardando
parecer do relator”. Em um processo parecido ao do professor coordenador, o professor relator pode ver
quando um pedido precisa do seu parecer e, via histórico de pedidos ativos (Figura 4.5), ele pode fornecer o
parecer aprovando a solicitação, passando o pedido para a situação ”Aguardando homologação”.
Figura 4.5 – Interface do usuário para fornecer o parecer como relator.
Fonte: Autor do Trabalho
4.1.3 Homologação
Para realizar a homologação, o secretário precisa acionar a sequência de menus Pedidos > Pedidos em
homologação. Lá, ele selecionará a opção ”Homologar” (Figura 4.6) para a solicitação deste exemplo.
62
Figura 4.6 – Opção de homologação de pedidos no sistema.
Fonte: Autor do Trabalho
Na tela de homologação, o secretário define o pedido como ”homologado” de acordo com as situações
disponíveis e, neste caso, aprova a carga horária completa. As alterações são salvas e a carga horária da
atividade é assimilada ao aluno na base de horas. O pedido vai para a situação ”Processado e Homologado”,
podendo também ser arquivado, assim indo para o setor de pedidos arquivados caso necessário. As altera-
ções feitas interferem na carga horária aceita e na situação do pedido, além de encontrar o eixo deste aluno
e incrementar a carga horária presente com as horas apreciadas pelo colegiado.
4.2 PEDIDO COM DOCUMENTAÇÃO INCOMPLETA
Esta seção apresenta e detalha as ações de usuário e comportamentos do sistema desde o início de um
pedido até sua homologação, sendo este bem-sucedido após revisão da documentação inicialmente enviada.
Para este e o posterior exemplos, muitos processos são repetidos, logo algumas partes não serão
aprofundadas.
4.2.1 Cadastro
Novamente o aluno acessa o cadastro de pedidos (Pedidos > Cadastro) e realiza o cadastro normal-
mente, com documentos e descrições das atividades. O sistema, no entanto, não permite o cadastro sem
a inserção de todos os documentos necessários para a atividade listada. No exemplo, o aluno acabou se
enganando e inserindo um documento incorreto.
4.2.2 Avaliação
Neste exemplo, o secretário pode perceber a falta de documentação ou de conteúdo e já encaminhar
o pedido para correção, usando a situação ”Correção necessária” (Figura 4.7). Caso creia que não seja
necessário o alerta, ele novamente realiza o processo de escolha de professor e encaminha o pedido para
”Em avaliação”.
63
Figura 4.7 – Situação ”Correção necessária” no ACG-CC.
Fonte: Autor do Trabalho
No processo de avaliação, o professor confere os documentos e verifica que um deles está incorreto,
encaminhando para a situação ”Correção necessária”. Além disso, ele também pode descrever suas percep-
ções no campo de descrição. Este processo é mostrado na Figura 4.8.
Figura 4.8 – Tela de avaliação de pedidos.
Fonte: Autor do Trabalho
4.2.3 Nova tentativa de cadastro
Após a avaliação, o aluno é notificado e pode realizar o reenvio. Isto acontece via botão edição de um
pedido. Para chegar nisso, o aluno precisa realizar o seguinte caminho de ações no sistema: pedidos >
ativos, na listagem de pedidos, clicar em ”Visualizar” e, na tela de visualização, encontrar o botão ”Editar”
(Figura 4.9).
64
Figura 4.9 – Opção para editar pedidos.
Fonte: Autor do Trabalho
Na tela de edição, é possível ao aluno editar todos os dados anteriormente informados e, por con-
sequência, excluir os arquivos anteriormente salvos. Essa ação é realizada apertando no botão com o ”X”
ao lado da label do arquivo (Figura 4.10). Após isso, o usuário pode clicar em ”Editar” e os dados serão
atualizados na base. Novamente, o pedido terá a situação ”Aguardando avaliação”.
Figura 4.10 – Opção para excluir documentos.
Fonte: Autor do Trabalho
65
4.2.4 Reavaliação e homologação
O pedido é encaminhado ao professor, que pode novamente selecionar o mesmo professor ou outro à
sua preferência. A partir daí, os passos são os mesmos de um pedido completo. Caso seja necessário, o
pedido pode ser reenviado quantas vezes for necessário ou, caso algum usuário prefira, deletado, tornando-
se arquivado no sistema.
4.3 PEDIDO APROVADO PARCIALMENTE EM CARGA HORÁRIA
Esta seção apresenta e detalha as ações de usuário e comportamentos do sistema desde o início de
um pedido até sua homologação, sendo este com carga horária reduzida.
4.3.1 Cadastro
Este processo é o mesmo dos demais. O aluno solicita a ACG com uma carga horária pré-definida,
sendo esta descrita na base de dados como carga horária pedida.
4.3.2 Avaliação
Os processos são semelhantes até o de avaliação, que é onde o professor pode definir quantas horas
um pedido poderá receber. O campo ”Carga horária aprovada” possui, como sugestão, o número de horas
solicitado pelo aluno, mas pode ser editado pelo professor com a forma que ele avalia a carga horária da
atividade (Figura 4.11).
66
Figura 4.11 – Página de avaliação com mudança da carga horária aceita.
Fonte: Autor do Trabalho
Assim, ele encaminha essa carga horária como algo sugerido, e esta é salva na coluna ”carga_horaria_aceita”
da base como algo temporário.
Após o parecer do relator, o secretário recebe estes dados para homologação.
4.3.3 Homologação
No processo de homologação, o secretário tem, no campo de carga horária sugerida, o valor inserido
pelo professor. Este valor, no entanto, ainda pode ser editado caso o secretário responsável prefira mudar
antes de ser confirmado. Com os valores definidos, o pedido é homologado, as horas distribuídas e o pedido
assume a situação ”Homologado com carga horária reduzida” (Figura 4.12).
67
Figura 4.12 – Visualização do pedido após homologação com carga horária reduzida.
Fonte: Autor do Trabalho
5 CONCLUSÃO
Este trabalho propôs uma solução para informatizar processos de pedidos de ACGs do curso de Ciência
da Computação da UFSM. O sistema é composto por um back end capaz de gerenciar todo o histórico de
solicitações de ACGs dos alunos do curso e um front end responsável por prover todo o acesso aos dados,
seja pelos alunos, seja pela coordenação, seja pelos professores do colegiado responsáveis pela avaliação
destes pedidos.
Este trabalho baseou-se no desenvolvimento de uma ferramenta web com o auxílio de bibliotecas e
frameworks de desenvolvimento para atingir os objetivos propostos.
Após apresentação das funcionalidades e testes das mesmas, conclui-se que a ferramenta será de
grande importância e utilidade para a comunidade acadêmica do curso de Ciência da Computação da UFSM,
visto que facilita o acesso a informações, agiliza processos que costumam ser longos e também atende à
atual urgência da digitalização das informações.
Para trabalhos futuros, há a possibilidade de implementação de assinaturas digitais para os usuários,
possibilitando a geração de arquivos e formulários completos, prontos para homologação. Também exis-
tem ajustes possíveis para o módulo de configurações, tornando-o ainda mais customizável. Estes ajustes
consistem em regular eixos e os documentos necessários para cada atividade dando mais atributos aos do-
cumentos salvos. Assim, assembleias e reuniões importantes para regulamentação das ACGs podem ser
finalizadas com simples ajustes no sistema.
Outros ajustes também podem ser feitos em caso de implementação completa do sistema e a integração
junto aos servidores da UFSM.
REFERÊNCIAS BIBLIOGRÁFICAS
Apache. Informações sobre o Apache. 2020. Acessado em 18 dez. 2020. Disponível em: <https://httpd.apache.org/ABOUT_APACHE.html>.
Bootstrap. Documentação do Bootstrap 4. 2018. Acessado em 19 dez. 2020. Disponível em: <https://getbootstrap.com/docs/4.1/getting-started/introduction/>.
Bootswatch. Site do repositório Bootswatch. 2020. Acessado em 01 fev. 2020. Disponível em: <https://bootswatch.com/>.
Cia Websites. O que é Bootstrap e para que serve? 2017. Acessado em 05 jan. 2021. Disponível em:<https://www.ciawebsites.com.br/sites/o-que-e-bootstrap/>.
CodeIgniter. Documentação do CodeIgniter 3. 2019. Acessado em 17 dez. 2020. Disponível em: <https://codeigniter.com/userguide3/index.html>.
DALL’OGLIO, P. PHP: Programando com orientação a objetos. 1. ed. [S.l.]: Novatec Editora, 2007.
Devmedia. Introdução ao MySQL. 2013. Acessado em 18 dez. 2020. Disponível em: <https://www.devmedia.com.br/introducao-ao-mysql/27799>.
. Introdução ao Padrão MVC. 2013. Acessado em 25 jan. 2021. Disponível em: <https://www.devmedia.com.br/introducao-ao-padrao-mvc/29308>.
HeidiSQL. Site da aplicação HeidiSQL. 2020. Acessado em 01 fev. 2020. Disponível em: <https://www.heidisql.com/>.
HEUSER, C. A. Projeto de Banco de Dados. 4. ed. [S.l.: s.n.], 1998.
IEEP Educação. Quem é Jeff Sutherland? Conheça o pai do Scrum e sua trajetória. 2020. Acessado em11 fev. 2020. Disponível em: <https://www.ieepeducacao.com.br/jeff-sutherland/>.
Kinghost. Linguagem PHP: Porque Aprender a Utilizar. 2018. Acessado em 02 dez. 2020. Disponível em:<https://king.host/blog/2018/06/linguagem-php-porque-aprender-a-utilizar/>.
Macoratti. Padrões de Projeto: O modelo MVC - Model View Control. 2004. Acessado em 25 jan. 2021.Disponível em: <http://www.macoratti.net/vbn_mvc.htm>.
MySQL. START TRANSACTION, COMMIT, and ROLLBACK Statements. 2018. Acessado em 11 fev. 2020.Disponível em: <https://dev.mysql.com/doc/refman/8.0/en/commit.html>.
PHP. História do PHP. 2020. Acessado em 03 dez. 2020. Disponível em: <https://www.php.net/manual/pt_BR/history.php.php>.
PHPMailer. Repositório da biblioteca PHPMailer. 2020. Acessado em 10 jan. 2021. Disponível em: <https://github.com/PHPMailer/PHPMailer>.
PRESSMANN, R. S. Engenharia de Software: Uma abordagem profissional. 7. ed. [S.l.: s.n.], 2011.
SUTHERLAND, J. SCRUM: A arte de fazer o dobro do trabalho na metade do tempo. 1. ed. [S.l.: s.n.], 2014.
TCPDF. Site da aplicação TCPDF. 2020. Acessado em 02 jan. 2021. Disponível em: <https://tcpdf.org/>.
Techtudo. O que é e como usar o MySQL? 2012. Acessado em 25 jan. 2021. Disponível em: <https://www.techtudo.com.br/artigos/noticia/2012/04/o-que-e-e-como-usar-o-mysql.html>.
70
Universidade Federal de Juiz de Fora. Regulamentação das Atividades Complementares do Curso deCiência da Computação da Universidade Federal de Juiz de Fora. 2013. Acessado em 21 nov. 2020.Disponível em: <https://www.ufjf.br/cursocomputacao/para-alunos/atividades-curriculares-eletivas/>.
Universidade Federal de Pernambuco. Projeto Pedagógico do Curso de Ciência da Com-putação da Universidade Federal de Pernambuco. 2002. Acessado em 22 nov. 2020. Dis-ponível em: <https://www.ufpe.br/documents/38970/411209/ciencia_computacao_perfil_2002.pdf/09862676-8330-4642-af94-6ec9e8607a62>.
Universidade Federal de Santa Maria. Normas para atividades complementares de Graduação do Cursode Ciência da Computação da Universidade Federal de Santa Maria. 2011. Acessado em 15 nov. 2020.Disponível em: <https://www.ufsm.br/app/uploads/sites/425/2018/11/Normas-Internas-de-ACGs-2011-CC.pdf>.
Universidade Federal de Viçosa. Atividades Complementares do Curso de Ciência da Computação daUniversidade Federal de Viçosa. 2019. Acessado em 22 nov. 2020. Disponível em: <http://www.ccp.ufv.br/?page_id=599>.
Universidade Federal do Ceará. Regulamentação das Atividades Complementares do Curso de Ciênciada Computação da Universidade Federal do Ceará. 2016. Acessado em 21 nov. 2020. Disponível em:<https://drive.google.com/file/d/0ByomiL4g3q4AbmxqaFk3Vk9yaUE/view>.
Universidade Federal do Rio Grande do Sul. Resolução envolvendo as Atividades Complementa-res do Curso de Ciência da Computação da Universidade Federal do Rio Grande do Sul. 2006.Acessado em 21 nov. 2020. Disponível em: <http://www.ufrgs.br/cepe/legislacao/resolucoes-normativas/resolucao-no-24-2006-de-03-05-2006>.