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

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


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



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


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;



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.


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.


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);


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.


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;


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.


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.


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 (){}

}

?>


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.


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.


3.4.3 Versão 0.6


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.



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


sistema

ajuda.php



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.



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


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



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.


3.4.4 Versão 0.7


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.


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.


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


3.4.5 Versão 0.8


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 ’);

}

?>


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.


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).


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.


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 ();

}

?>


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


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.


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


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.


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.


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.


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.


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.


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.


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.


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.


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.


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.


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.


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.


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.


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.


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>.

https://httpd.apache.org/ABOUT_APACHE.html

https://httpd.apache.org/ABOUT_APACHE.html

https://getbootstrap.com/docs/4.1/getting-started/introduction/

https://getbootstrap.com/docs/4.1/getting-started/introduction/

https://bootswatch.com/

https://bootswatch.com/

https://www.ciawebsites.com.br/sites/o-que-e-bootstrap/

https://codeigniter.com/userguide3/index.html

https://codeigniter.com/userguide3/index.html

https://www.devmedia.com.br/introducao-ao-mysql/27799

https://www.devmedia.com.br/introducao-ao-mysql/27799

https://www.devmedia.com.br/introducao-ao-padrao-mvc/29308

https://www.devmedia.com.br/introducao-ao-padrao-mvc/29308

https://www.heidisql.com/

https://www.heidisql.com/

https://www.ieepeducacao.com.br/jeff-sutherland/

https://king.host/blog/2018/06/linguagem-php-porque-aprender-a-utilizar/

http://www.macoratti.net/vbn_mvc.htm

https://dev.mysql.com/doc/refman/8.0/en/commit.html

https://www.php.net/manual/pt_BR/history.php.php

https://www.php.net/manual/pt_BR/history.php.php

https://github.com/PHPMailer/PHPMailer

https://github.com/PHPMailer/PHPMailer

https://tcpdf.org/

https://www.techtudo.com.br/artigos/noticia/2012/04/o-que-e-e-como-usar-o-mysql.html

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>.

https://www.ufjf.br/cursocomputacao/para-alunos/atividades-curriculares-eletivas/

https://www.ufpe.br/documents/38970/411209/ciencia_computacao_perfil_2002.pdf/09862676-8330-4642-af94-6ec9e8607a62

https://www.ufpe.br/documents/38970/411209/ciencia_computacao_perfil_2002.pdf/09862676-8330-4642-af94-6ec9e8607a62

https://www.ufsm.br/app/uploads/sites/425/2018/11/Normas-Internas-de-ACGs-2011-CC.pdf

https://www.ufsm.br/app/uploads/sites/425/2018/11/Normas-Internas-de-ACGs-2011-CC.pdf

http://www.ccp.ufv.br/?page_id=599

http://www.ccp.ufv.br/?page_id=599

https://drive.google.com/file/d/0ByomiL4g3q4AbmxqaFk3Vk9yaUE/view

http://www.ufrgs.br/cepe/legislacao/resolucoes-normativas/resolucao-no-24-2006-de-03-05-2006

http://www.ufrgs.br/cepe/legislacao/resolucoes-normativas/resolucao-no-24-2006-de-03-05-2006

joão vitor machado de mello

Documents