Relatório_de_prática_profissional___Gustavo_Melo_e_Raul_Lima.pdf

Transcript

1. GUSTAVO HENRIQUE DE MELO BEZERRA BRANDÃO RAUL FILIPE OLIVEIRA DOS SANTOS LIMA RELATÓRIO DE PRÁTICA PROFISSIONAL: COLABORAÇÃO COM O SADHI ­ SISTEMA DE APOIO À DECISÃO DE HORÁRIOS CEARÁ­MIRIM/RN 2022
2. GUSTAVO HENRIQUE DE MELO BEZERRA BRANDÃO RAUL FILIPE OLIVEIRA DOS SANTOS LIMA RELATÓRIO DE PRÁTICA PROFISSIONAL: COLABORAÇÃO COM O SADHI ­ SISTEMA DE APOIO À DECISÃO DE HORÁRIOS Relatório de Prática Profissional apresentado ao Curso Técnico Integrado em Informática do Instituto Federal de Educação, Ciência e Tecno­ logia do Rio Grande do Norte em cumprimento às exigências legais como requisito parcial para a obtenção do título de Técnico em Informática. Aprovado em: 17/02/2022 Nota Final: 100 Orientador: Prof. Adorilson Bezerra de Araújo AVALIADORES Alexmay Soares Nunes Professor de Matemática Matrícula: 2110337 Fernanda Ligia Rodrigues Lopes Professora de Sistemas de Informação Matrícula: 2122658 José Durval Pacheco Tavares Júnior Professor de Design, Multimídia, Construção de Personagens e Narrativas para Jogos Digitais Matrícula: 2310636 CEARÁ­MIRIM/RN 2022
3. RESUMO O SADHI – Sistema de Apoio à Decisão de Horários – é um sistema web desenvolvido em PHP, e que foi pensado inicialmente para auxiliar o IFRN Campus Ipanguaçu na criação dos horários escolares, posteriormente, ele expandiu­se e passou a ser utilizado em outros campi. Assim como outros softwares, para continuar funcionando bem e cumprindo com seus objeti­ vos, o SADHI precisa receber manutenção e adição de novas funcionalidades, além disso ele precisa ser documentado, e essa documentação precisa ser atualizada com o passar do tempo. Em algumas situações, também pode ser útil reescrever o sistema. Pensando nessas necessi­ dades e na relevância desse software no contexto escolar, nosso trabalho objetivou atender a essas demandas e contribuir para o pleno funcionamento dele. O trabalho desenvolvido teve três etapas: a primeira foi definição dos objetivos do projeto e a apresentação para o orientador e a Coordenação de Curso; a segunda foi focada no aprendizado das tecnologias utilizados no SADHI; enquanto na terceira, o principal objetivo foi aplicar os conhecimentos adquiridos ante­ riormente e implementar novos componentes, corrigir defeitos, produzir e atualizar documentos (tais como documentos de requisitos e diagrama de atividades) bem como pensar a reescrita do sistema para um futuro lançamento de uma nova versão usando o framework Django. Como resultados, foram corrigidas algumas falhas, e implementadas melhorias que contribuíram para tornar o sistema mais amigável e eficiente. Ainda, os documentos atualizados e produzidos norte­ arão novas equipes de programadores, e embora a nova versão planejada não tenha sido lançada, os componentes produzidos podem ser usados como base para o seu desenvolvimento. Palavras­chave: Programação; Documentação de software; Manutenção de software;
4. LISTA DE FIGURAS Figura 5.1 – Etapas da prática profissional. . . . . . . . . . . . . . . . . . . . . . . . . . 15 Figura 5.2 – Fluxograma de tarefas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Figura 5.3 – GitHub Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Figura 7.1 – Estrutura de diretórios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 Figura 7.2 – Lista de issues. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 Figura 7.3 – Lista de pull requests. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Figura 7.4 – Antes e depois da remoção de um número mágico de um mesmo trecho de código. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Figura 7.5 – Visão geral do diagrama de casos de uso. . . . . . . . . . . . . . . . . . . . 31 Figura 7.6 – Planilha Perfis x Permissões . . . . . . . . . . . . . . . . . . . . . . . . . 34 Figura 7.7 – Diagrama de Entidades e Relacionamentos. . . . . . . . . . . . . . . . . . 35 Figura 7.8 – Exemplo da tela atual de montagem de horários . . . . . . . . . . . . . . . 37 Figura 7.9 – Google Agenda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 Figura 7.10–Protótipo da tela de montagem de horários feito com TOAST UI . . . . . . 38 Figura 7.11–Vínculos de Disciplinas do(a) Professor(a) . . . . . . . . . . . . . . . . . . 40 Figura 7.12–Exemplo de planilha usada para definir os vínculos de disciplinas . . . . . . 41 Figura 7.13–Exemplo da ferramenta grid do TOAST UI . . . . . . . . . . . . . . . . . . 41
5. LISTA DE TABELAS Tabela 4.1 – Síntese de carga horária e atividades de Raul Filipe Lima. . . . . . . . . . . 13 Tabela 4.2 – Síntese de Carga horária e Atividades de Gustavo Henrique de Melo. . . . . 14 Tabela A.1 – Relação das issues resolvidas durante essa prática profissional . . . . . . . 49 Tabela B.1 – Documentos produzidos ou atualizados. . . . . . . . . . . . . . . . . . . . 50
6. LISTA DE ABREVIAÇÕES E SIGLAS CSS Cascading Style Sheets. 9, 13, 15, 19, 20, 26 FTP File Transfer Protocol. 17 HTML Hypertext Markup Language. 9, 13, 15, 19, 20, 26 IFRN Instituto Federal de Ciência e Tecnologia do Rio Grande do Norte. 9, 11, 13, 15, 16, 26 MVC Model­View­Controller. 9, 20, 27 PHP PHP: Hypertext Preprocessor. 9, 13, 16, 20, 25, 26, 43 POO Programação Orientada a Objetos. 25 SADHI Sistema de Apoio à Decisão de Horários. 6, 9, 10, 12, 14–17, 19–21, 23, 25, 28–30, 34, 42, 48–50 SGBD Sistema Gerenciador de Banco de Dados. 9, 20 SUAP Sistema Unificado de Administração Pública. 10, 23, 49 UML Linguagem de Modelagem Unificada. 20, 30
7. SUMÁRIO LISTA DE ABREVIAÇÕES E SIGLAS . . . . . . . . . . . . . . . . . . . . . . . . . 5 1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2 JUSTIFICATIVA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3 OBJETIVOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.1 Objetivo geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.2 Objetivos específicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4 DADOS GERAIS DA PRÁTICA PROFISSIONAL . . . . . . . . . . . . . . . . 13 4.1 Síntese de carga horária e atividades de Raul Lima . . . . . . . . . . . . . . . 13 4.2 Síntese de carga horária e atividades de Gustavo de Melo . . . . . . . . . . . . 14 5 METODOLOGIA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 6 FUNDAMENTAÇÃO TEÓRICA . . . . . . . . . . . . . . . . . . . . . . . . . . 19 6.1 Tecnologias usadas no sistema . . . . . . . . . . . . . . . . . . . . . . . . . . 19 6.2 Arquitetura de software do SADHI . . . . . . . . . . . . . . . . . . . . . . . . 20 6.3 Produção e atualização da documentação . . . . . . . . . . . . . . . . . . . . . 21 6.4 Manutenção . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 6.5 Prototipagem de novos componentes . . . . . . . . . . . . . . . . . . . . . . . 23 7 DESCRIÇÃO DAS ATIVIDADES . . . . . . . . . . . . . . . . . . . . . . . . . . 25 7.1 Projeto Integrador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 7.2 Aprendizado de tecnologias utilizadas no sistema . . . . . . . . . . . . . . . . 25 7.3 Estudo do código­fonte do SADHI . . . . . . . . . . . . . . . . . . . . . . . . 26 7.4 Resolução de problemas e melhorias . . . . . . . . . . . . . . . . . . . . . . . 27 7.5 Construção de diagramas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 7.6 Prototipagem de componentes para uma nova versão . . . . . . . . . . . . . . 34 7.6.1 Prototipagem da tela de montagem de horários . . . . . . . . . . . . . 36 7.6.2 Tela de vínculos de disciplinas . . . . . . . . . . . . . . . . . . . . . . 39 8 CONSIDERAÇÕES FINAIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 8.1 Trabalhos futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 REFERÊNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
8. Apêndices 47 APÊNDICE A DESCRIÇÃO DAS MELHORIAS E CORREÇÕES FEITAS NO SADHI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 APÊNDICE B DOCUMENTOS E DIAGRAMAS PRODUZIDOS PARA O PRO­ JETO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
9. 1. INTRODUÇÃO Tornou­se banal dizer que as novas tecnologias revolucionaram a sociedade. Diversos autores já dissertaram sobre os impactos que as ferramentas digitais têm no trabalho e nos relaci­ onamentos pessoais. Para Kenski (2003), “a possibilidade de acesso generalizado às tecnologias eletrônicas de comunicação e informação trouxe novas formas de viver, de trabalhar e de se or­ ganizar socialmente”. Ainda segundo a mesma autora Kenski (2007), “essas novas tecnologias [...], quando disseminadas socialmente, alteram as qualificações profissionais e a maneira como as pessoas vivem cotidianamente, trabalham, informam­se e se comunicam com outras pessoas e com todo o mundo.” Nesse contexto, a escola e o processo de ensino­aprendizagem não passaram ilesos. Seja pelo desenvolvimento de softwares capazes de reunir mais facilmente, no mundo virtual, profes­ sores e alunos (tais como Edmodo1 e Google Sala de Aula2), seja pela maior difusão de conteú­ dos educacionais em eBooks, podcasts e vídeos online, a tecnologia exigiu que o ensino fosse pensando de modo diferente. Dessa maneira, Garcia (2013) afirmou que “não é mais possível pensar em educação sem a utilização das tecnologias.” Embora sejam notáveis os impactos dos recursos digitais nas salas de aula, é mister des­ tacar que a revolução digital não beneficiou apenas o processo de aprendizagem, mas também os vários setores escolares que atuam para que o ensino seja possível. Nesse ínterim, podemos destacar um processo importante na organização escolar, mas que ainda é feito com pouco ou nenhum auxílio da tecnologia em várias escolas: a criação dos horários escolares. Especialmente em instituições de ensino maiores, com mais turmas, turnos e docentes, criar os horários escola­ res pode ser uma tarefa complexa. Por exemplo, Menezes e Alves (2020) destacam que muitas escolas usam planilhas para elaborar suas grades de horários. Mesmo em instituições que já usavam softwares, como Urâ­ nia e Timetables, para auxiliar na criação dos horários, as autoras afirmam que algumas tarefas ainda precisavam ser feitas manualmente. Por exemplo, um operador precisava recolher as pre­ ferências de horários dos professores (que normalmente eram colocadas em uma planilha), e passá­las para um dos softwares acima mencionados, dessa forma, a comissão de horários da 1 Disponível em: https://edmodo.com/ 2 Disponível em: https://edu.google.com/intl/ALL_br/
10. Capítulo 1. INTRODUÇÃO 9 escola tinha um retrabalho. Dentre as instituições que usavam essas soluções para a construção de horários escolares estavam alguns campi do Instituto Federal de Ciência e Tecnologia do Rio Grande do Norte (IFRN). Embora esses sistemas ajudassem de algum modo às comissões de horários, urgia a necessidade de um software que auxiliasse a construção de horários escolares e que eliminasse os ciclos de retrabalho. Surge a partir dessas demandas o Sistema de Apoio à Decisão de Horários (SADHI), um sistema web desenvolvido utilizando­se tecnologias como PHP, JavaScript, HTML e CSS. Além disso, ele foi construído na arquitetura Model­View­Controller (MVC) e utiliza o Mari­ aDB como seu Sistema Gerenciador de Banco de Dados (SGBD). O desenvolvimento e implantação do SADHI, segundo ARAUJO et al. (2017), ocorreu em duas etapas distintas. Em um primeiro momento, foi disponibilizado um módulo que automa­ tizava tarefas antes feitas manualmente. Por exemplo, a primeira versão do sistema permitia que os professores cadastrassem suas preferências de horário e possibilitava a distribuição das disci­ plinas entre os docentes. Esses dados eram então levados para outro sistema, onde os horários das aulas era finalmente gerados. A possibilidade de gerar grades horárias no próprio SADHI só seria implantada na segunda etapa. Considerando o modo como o sistema foi desenvolvido, é possível inferir a partir da literatura de Pressman (2011) que o modelo do processo de desenvolvimento do SADHI foi o modelo incremental. Este modelo, segundo o autor, “libera uma série de versões, denominadas incrementais, que oferecem, progressivamente, maior funcionalidade para o cliente à medida que cada incremento é entregue.” (PRESSMAN, 2011, p. 61) Segundo seus idealizadores, o projeto, inicialmente pensado para o Campus Ipanguaçu e desenvolvido por docentes e estudantes daquele campus, objetiva ser um software que “forneça suporte à formação da grade horária, visando auxiliar na organização das diversas atividades docentes, de forma a melhorar o funcionamento da instituição local.” (ARAUJO et al., 2017) Em 2020, em decorrência da pandemia de COVID­19, o SADHI foi remodelado para atender o novo formato de aulas que estava sendo adotado no IFRN, que seria baseado em mó­ dulos e não mais em bimestres, daí ter sido rebatizado de SADHI Modular. Essa mudança, feita
11. Capítulo 1. INTRODUÇÃO 10 emergencialmente, atendeu às necessidades da instituição, mas devido ao prazo de desenvolvi­ mento apertado, o código produzido ainda precisava ser melhorado e nem todas as funciona­ lidades foram adaptadas para o formato modular. Convém mencionar também que embora os desenvolvedores do SADHI estivessem inicialmente lotados em Ipanguaçu, eles posteriormente foram remanejados, o que favoreceu a adoção do SADHI por outros campi do Instituto. Após a adoação do SADHI pelo Campus Ceará­Mirim, ocorrida em 2019 para elabo­ ração dos horários de 2020, foi iniciado neste campus um núcleo de desenvolvimento. Sob co­ ordenação do professor Adorilson Bezerra, a primeira contribuição desse núcleo foi a criação da documentação para usuários3, elaborado pelas alunas Esteffane Menezes e Thaynara Alves, quando da realização de suas práticas profissionais em 2019 para conclusão do Curso Técnico em Informática. No ano de 2020, este núcleo teve acesso ao código­fonte do sistema, quando pode am­ pliar as suas contribuições e envolvimento com o desenvolvimento e melhoria do sistema, in­ cluindo a hospedagem do código­fonte em um repositório específico para código­fonte de soft­ ware, com acesso distribuído e controle de versão. Além disso, o então aluno Arthur Medeiros desenvolveu diversas melhorias, tais como nova tela inicial, com mais destaques para os campi e integração com o Sistema Unificado de Administração Pública para autenticação de usuários4. Em 2021, além dos autores deste relatório, cujas contribuições serão apresentas ao longo do documento, também participou do desenvolvimento do SADHI o aluno do 4º ano do curso de Informática, Arthur Holanda. Como dito antes, o SADHI, embora já estivesse em produção, ainda carecia de melho­ rias, tanto acréscimos de novas funcionalidades, quanto correções de defeitos existentes. Este trabalho surgiu para colaborar com os objetivos do sistema em três campos fundamentais: pro­ dução de documentos e diagramas atualizados, implementação de melhorias na versão atual, e prototipagem e projeto de uma nova versão para o sistema. Embora todo o trabalho tenha sido desenvolvimento a partir do código do SADHI Modular, por uma questão de simplicidade, chamaremos apenas de SADHI em todo documento. 3 Disponível em https://gitlab.devops.ifrn.edu.br/adorilson/sadhi­docs/­/wikis/home 4 Mais informações em https://portal.ifrn.edu.br/campus/ceara­mirim/noticias/aluno­do­campus­ceara­mirim­ desenvolve­melhorias­para­o­sadhi
12. 11 2. JUSTIFICATIVA Antes de mais nada, é preciso destacar a rápida evolução pela qual passam as tecnologias. Por exemplo, em um espaço de tempo relativamente curto, uma linguagem de programação pode sofrer atualizações que contemplam melhorias, mas também pode sofrer significativas mudanças em sua sintaxe, de modo que com o passar do tempo algumas declarações fiquem obsoletas em um primeiro momento e incompatíveis em algum momento futuro. Dessa forma, o sistema que não acompanha os avanços tecnológicos corre o sério risco de perder competitividade, ou até mesmo deixar de funcionar. Podemos mencionar ainda que ele precisa ser documentado, e a documentação deve ser atualizada juntamente com a evolução do sistema. Incluindo documentos para usuários e documentação para desenvolvedores. Além disso, quando um software é utilizado pelo público, logo são reportados problemas que precisam ser corrigidos, ou funcionalidades que deveriam ser implementadas ou terem sua usabilidade melhorada. Visando oferecer a melhor experiência ao usuário, é imprescindível que correções e melhorias sejam feitas. Outrossim, a relevância da prática profissional desenvolvida por essa equipe fica mais evidente ao considerarmos o que dispõe a Organização Didática do IFRN (IFRN, 2012a, p. 65, art. 281), que a respeito dos objetivos da prática profissional reza: “A prática profissional configurar­se­á como um procedimento didático­pedagógico que contextualiza, articula e interrelaciona os saberes apreendidos, relacionando teoria e prática, a partir da atitude de desconstrução e (re)construção do co­ nhecimento, viabilizando ações que conduzam ao aperfeiçoamento técnico­ científico­cultural e de relacionamento humano.” O trabalho desenvolvido pela equipe foi ao encontro daquilo que é proposto pela Insti­ tuição, visto que proporcionou aos envolvidos, além de um conhecimento técnico mais aprofun­ dado, a formação e consolidação de qualidades fundamentais no mundo do trabalho.
13. 12 3. OBJETIVOS 3.1 Objetivo geral Este trabalho teve como objetivo geral atender as necessidades básicas de todos os siste­ mas computacionais: contribuir com a manutenção, adição de novas funcionalidades, correção de defeitos, melhoria da documentação do Sistema de Apoio à Decisão de Horários, e também a idealização de versões e atualizações futuras. 3.2 Objetivos específicos • Compreender o funcionamento da definição dos horários de aula no SADHI; • Compreender o código­fonte do sistema e como seus componentes se relacionam; • Estudar novas tecnologias e ferramentas utilizadas; • Implementar novas funcionalidades e corrigir defeitos no sistema; • Melhorar a usabilidade do sistema; • Melhorar ou produzir documentação do projeto; • Prototipar componentes para futuras implementações.
14. 13 4. DADOS GERAIS DA PRÁTICA PROFISSIONAL De acordo com a Organização Didática do IFRN (IFRN, 2012a, p. 17, art. 36 § 1 e p.65, art. 280), para obtenção do diploma de técnicos de níveis médio, é obrigatória a realização de, no mínimo, 400 horas de prática profissional. Essa seção apresenta de forma sintética a carga­horária exercida pelos colaboradores Raul Lima e Gustavo Melo, tendo sido realizada de 18/11/2020 à 30/01/2022. As tabelas 4.1 e 4.2 indicam, respectivamente, a carga horária dedicada pelos colabora­ dores Raul Lima e Gustavo de Melo para as atividades desenvolvida ao longo da realização de suas práticas profissionais. 4.1 Síntese de carga horária e atividades de Raul Lima • Colaborador: Raul Filipe Oliveira dos Santos Lima Carga­horária total: 450 horas Tabela 4.1 – Síntese de carga horária e atividades de Raul Filipe Lima. CARGA HORÁRIA ATIVIDADES DESENVOLVIDAS 60 horas Projeto Integrador 90 horas Aprendizado de tecnologias utilizadas no sistema (Git, GitHub, Django, HTML, CSS, JavaScript e PHP.) 70 horas Construção e atualização de diagramas e documentos do projeto. (Detalhes no apêndice B) 230 horas Resolução de problemas e melhorias. (De­ talhes no apêndice A)
15. Capítulo 4. DADOS GERAIS DA PRÁTICA PROFISSIONAL 14 4.2 Síntese de carga horária e atividades de Gustavo de Melo • Colaborador: Gustavo Henrique de Melo Bezerra Brandão Carga­horária total: 575 horas Tabela 4.2 – Síntese de Carga horária e Atividades de Gustavo Henrique de Melo. CARGA HORÁRIA ATIVIDADES DESENVOLVIDAS 60 horas Projeto Integrador 80 horas Estudo do código­fonte do SADHI e lin­ guagens para prototipação de uma nova versão do SADHI 20 horas Estudo de Git, Github e processo de con­ tribuição 185 horas Construção de diagramas e Prototipagem de componentes para uma nova versão (Detalhes no apêndice A e B) 140 horas Resolução de problemas e melhorias e de­ senvolvimento da versão atual com resolu­ ções de acordo com a demanda do projeto (Detalhes no apêndice A) Embora os dois colaboradores tenham trabalhado no mesmo projeto, eles se dedicaram a partes diferentes do projeto e em momentos diferentes, resultando, deste modo, em cargas horárias diferentes para cada colaborador como mostrado nas duas tabelas. Além disso, podemos mencionar que embora eles tenham estudado as mesmas tecnologias, o colaborador Raul se identificou com materiais de estudo mais concisos e também, por problemas em seu computador, ele teve sua participação no projeto reduzida por um perído.
16. 15 5. METODOLOGIA Segundo o Projeto Pedagógico do Curso de Informática do IFRN (IFRN, 2012b, p. 17), o componente curricular Projeto Integrador é um “elemento impulsionador da prática [profissi­ onal]”. De fato, foi no âmbito desse componente, que constituiu a primeira etapa dessa prática profissional, onde foi escolhido o SADHI como objeto de estudo. Após essa escolha, foram apre­ sentados para orientação e Coordenação de Curso os objetivos e o plano de atividades, conforme prevêem os documentos institucionais. (Resolução 25/2019 (IFRN, 2019)) Como já destacado, esse trabalho focou em três eixos de atuação: produção de documen­ tos (tais como diagrama de casos de uso e diagrama de atividades), melhorias e correções no código e prototipagem de componentes de uma nova versão. Desse modo, após a definição dos objetivos da prática profissional durante o Projeto Integrador (etapa 1), definiu­se mais duas eta­ pas a serem percorridas: estudo das tecnologias necessárias para atingir as objetivos elencados e aplicação dos conhecimentos adquiridos em forma de melhorias e correções no sistema. Assim, é possível sintetizar a estrutura desse trabalho nessas três etapas: Definição do projeto e estruturação de objetivos; estudo de tecnologias; e aplicação. Esse processo pode ser visto em forma de diagrama na figura 5.1. Figura 5.1 – Etapas da prática profissional. Fonte: Autoria própria. Tratando mais detalhadamente da etapa de estudos, nela procurou­se consolidar uma boa base de conhecimentos nas tecnologias demandadas. Vale destacar que algumas das competên­ cias necessárias ao projeto (tais como HTML/CSS, JavaScript e banco de dados) integravam a grade curricular do curso de Informática. Dessa forma, os discentes puderam contar com as aulas e o auxílio dos professores durante o aprendizado de algumas tecnologias, que associadas à consulta de outros materiais mais direcionados às necessidades do SADHI, colaboraram para a construção de conhecimentos essenciais à execução do projeto. Em outros casos, algumas tecnologias não integravam a matriz de conhecimentos do
17. Capítulo 5. METODOLOGIA 16 curso, ou ainda não haviam sido ministradas nas aulas. Dentre as tecnologias até então des­ conhecidas, podemos mencionar o Django (framework de desenvolvimento web) que embora também tenha sido ministrado durante o curso, precisava ser aprendido antes do início da dis­ ciplina que o apresentaria. No caso do PHP (linguagem de programação da versão atual), que não integrou a grade curricular em nenhum momento, foi preciso fazer um estudo autodidata da linguagem baseado em videoaulas disponíveis online e na documentação oficial da linguagem.1 Na última etapa ­ a de aplicação do conhecimento ­ foram executados os objetivos ante­ riormente elencados no capítulo 3. O código­fonte do sistema está hospedado no Github em um repositório privado da organização IFRN. Quando um nova pessooa entra para equipe de desen­ volvimento do, ela é adicionada ao repositório e terão acesso para clonar o código do SADHI na sua própria máquina. Todo o processo foi supervisionado pelo professor Adorilson Bezerra, que garantia tanto a qualidade daquilo que era produzido, quanto o aprendizado dos colaboradores. É possível estruturar esse processo da seguinte maneira: 1. Designação das tarefas: o professor Adorilson designava tarefas para cada um dos cola­ boradores por meio da plataforma GitHub em um recurso chamado issue (que se refere às atividades que precisam ser realizadas no projeto). 2. Orientação: por meio de reuniões e da indicação de materiais, o professor orientava como o trabalho deveria ser feito. Tais orientações ocorriam pelas plataformas Discord2 ou Go­ ogle Meet 3, por meio de comentários na própria issue e mais recentemente de forma presencial nas dependências do campus. Discord e Google Meet permitem comunicação online por mensagem e ligações audiovisuais com a possibilidade de compartilhar a tela dos dispositivos dos participantes. 3. Envio dos resultados: o colaborador submetia, através do recurso que o GitHub chama de pull request, o código para avaliação. Também poderia ser adicionado, tanto na issue quanto no pull request, comentários e imagens, a fim de mostrar a evolução da tarefa ou colher mais informações para continuidade do trabalho. 4. Avaliação do trabalho: o professor avaliava o resultado do trabalho, inclusive ainda es­ tando em andamento, o que permitia corrigir o rumo o quanto antes, e se ele estivesse 1 Disponível em: https://www.php.net/manual/pt_BR/index.php 2 https://discord.com/ 3 https://meet.google.com/
18. Capítulo 5. METODOLOGIA 17 satisfatório, a proposta era incorporada ao código principal do SADHI e o colaborador poderia passar para a próxima tarefa. Se não estivesse, eram solicitadas alterações. 5. Incorporação: estando a tarefa (ou a issue) finalizada, o professor incorporava a mudança ao código do sistema, ou incorporava o diagrama à documentação oficial do projeto. Um fluxograma que representa todo o processo anteriormente descrito pode ser visto na figura 5.2. Figura 5.2 – Fluxograma de tarefas Fonte: Autoria própria. Nesse ponto, cabe dar um detalhamento maior sobre fluxo de trabalho do Git usado na etapa 3. Nesse projeto, foi usado o fluxo de trabalho de ramificação de recurso (também chamado de GitHub Flow). Segundo Atlassian (s.d.), nesse modelo existe um ramo (que o Git chama de branch) principal que é protegida (por vezes chamada de main ou master) e não possui códigos quebrados, isso protege a base do código de alterações indesejadas. A implementação de novas funcionalidades (features) ou correção de defeitos (bugfix), segundo o que diz Antunes (2021), é feita em novas branches que são criadas a partir da original. Quando o código dessas novas branches está pronto, ele é mesclado na branch principal.Esse processo pode ser visto na figura 5.3 No caso do SADHI, o professor Adorilson é o único que pode fazer modificações di­ retamente no código da branch principal, por isso, todas as alterações produzidas por qualquer outro colaborador eram feitas em branches criadas a partir do ramo principal e somente após avaliação dele eram incorporados ao código­base. Posteriormente, de forma manual via FTP, as alterações eram colocadas em produção.
19. Capítulo 5. METODOLOGIA 18 Figura 5.3 – GitHub Flow Fonte: Antunes (2021).
20. 19 6. FUNDAMENTAÇÃO TEÓRICA Como destacado no capítulo 1, o SADHI foi idealizado para suprir a falta de um soft­ ware capaz de atender as demandas de escolas e instituições de ensino no que diz respeito à construção de horários escolares. Segundo os seus desenvolvedores, o SADHI surge diante da necessidade “de um sistema que facilite a organização da cadeia de carga horária semanal, sendo esta consistente e atendendo às peculiaridades de cada instituição de ensino, com o máximo de flexibilidade.” (ARAUJO et al., 2017, grifo nosso) A preocupação dos desenvolvedores em desenvolver uma solução que atendesse as ne­ cessidades das escolas está em consonância com o posicionamento de Pressman (2011, p. 126) que disse sobre a necessidade de atender as demandas do usuário: “Projetar e construir um pro­ grama de computador elegante que resolva o problema errado não atende às necessidades de ninguém.” Nessa seção, discorreremos sobre a fundamentação teórica das atividades desenvolvidas no âmbito desta prática profissional, nos três eixos de trabalho mencionados anteriormente no capítulo 5, todavia, primeiramente apresentaremos as tecnologias que foram utilizadas nesse projeto e a arquitetura em que ele foi construído. 6.1 Tecnologias usadas no sistema • Git e GitHub: segundo Guedes (s.d.), Git é uma ferramenta de versionamento local de código. Quando um arquivo é disponibilizado no Git, ele gerencia e faz um registro das alterações que ocorrem. De acordo com Noleto (2020), o GitHub é uma plataforma de armazenamento remoto de repositórios Git. Além de fornecer um backup seguro e possi­ bilidade de acessar seus arquivos de qualquer lugar, o GitHub ainda funciona como uma rede social de programadores, permitindo compartilhar e acessar milhões de repositórios de código. • HTML e CSS: de acordo com Khan Academy (s.d.), o Hypertext Markup Language (HTML) é uma linguagem de marcação utilizada para organizar o conteúdo das páginas web. Ela é responsável por inserir na página elementos como parágrafos, títulos e tabelas. Segundo a documentação da linguagem no MDN Web Docs (s.d.[a]), um site mantido
21. Capítulo 6. FUNDAMENTAÇÃO TEÓRICA 20 pela fundação Mozilla, “o HTML é o bloco de construção mais básico da web”. Já as Cascading Style Sheets (CSS), ainda de acordo com Khan Academy (s.d.), são as respon­ sáveis por prover a estilização da página. Elas definem elementos como tipos de fonte, cores e alinhamento de itens. • JavaScript: novamente segundo a MDN Web Docs (s.d.[b]), JavaScript “é uma linguagem leve, interpretada e baseada em objetos com funções de primeira classe”. Pensado inici­ almente como uma linguagem de programação client­side que objetivava dar dinamismo às páginas web criadas com HTML e CSS, JavaScript passou a ser executado também como linguagem server­side, embora nesse projeto ele só tenha sido usada na interface do cliente. • PHP: conforme a própria documentação da linguagem PHP (s.d.), o PHP é uma linguagem server­side. Sendo uma linguagem de código aberto, é muito utilizada para o desenvolvi­ mento web. • Django: também de acordo com sua própria documentação, Django (s.d.) é um framework pensado para o desenvolvimento web. Ele é baseado em Python. • UML: segundo a Wikipedia (s.d.), é a sigla em inglês para Linguagem de Modelagem Unificada. Como o próprio nome sugere, é uma linguagem de notação usada para produzir diagramas, fluxogramas e outros documentos técnicos de software de modo padronizado. • MariaDB: o MariaDB, segundo a MariaDB Foundation (s.d.), é um Sistema Gerenciador de Banco de Dados (SGBD) de código aberto e desenvolvido pela mesma equipe que desenvolveu o MySQL. Cabe ressaltar que, embora haja um certo grau de compatibilidade entre os dois SGBD, ela não é 100%. De fato, foram encontradas divergências de execução do SADHI nos diferentes SGBDs. 6.2 Arquitetura de software do SADHI A arquitetura Model­View­Controller (MVC) é usada no projeto. De acordo com o Me­ deiros (2013), a vantagem de usar esse padrão é que ele separa o código em camadas bem de­ finidas. Isso possibilita que as regras de negócio fiquem separadas da interface gráfica, o que possibilita maior possibilidade de reuso dos componentes do código. Embora tenha sido pro­
22. Capítulo 6. FUNDAMENTAÇÃO TEÓRICA 21 jetado com essa arquitetura, o SADHI optou por implementar essa arquitetura com algumas particularidades, o que em alguns casos dificulta a compreensão do código. 6.3 Produção e atualização da documentação Primeiramente, é preciso definir o conceito de documentação. Uma das definições dis­ poníveis na literatura é a de Coelho (2009, p. 2): Documentação descreve cada parte do código­fonte, uma função, uma classe, um trecho ou módulo. Podemos dizer que a documentação consiste em um conjunto de manuais gerais e técnicos, podendo ser organizado em forma de textos e comentários, utilizando ferramentas do tipo dicionários, diagramas e fluxogramas, gráficos, desenhos, dentre outros. Além disso, Michelazzo (2006) conceituou dois tipos de documentação: a documentação técnica e a documentação de uso. Segundo ele: A primeira [documentação técnica] é voltada ao desenvolvedor ou pessoa de TI e compreende principalmente dicionários e modelos de dados, fluxogramas de processos e regras de negócios, dicionários de funções e comentários de código. Já a documentação de uso é voltada tanto para o usuário final quanto para o administrador do sistema e comumente é formada por apostilas ou manuais que apresentam como o software deve ser usado, o que esperar dele e como receber as informações que se deseja. Embora seja negligenciada por alguns (o que Coelho (2009) destaca em sua pesquisa), a documentação é parte essencial de um software. Sommerville (2011, p. 4) destaca essa importân­ cia ao conceituar software como sendo “programas de computador e documentação associada” (o grifo é nosso). Um dos teóricos que destaca a importância da documentação é Amui (2015, p. 40) que a colocou como essencial ao sucesso do processo de manutenção de um software bem como ao suporte técnico ao usuário. Ele ainda afirma que “a documentação atualizada, presente e completa” auxilia no processo de melhorias do software e garante mais qualidade. No SADHI, a documentação de uso1 foi desenvolvida pelas colaboradoras Esteffane Menezes e Thaynara Alves (MENEZES; ALVES, 2020). Quando tratamos da documentação técnica, alguns documentos ou não existiam ou precisavam ser atualizados. Durante essa prática profissional, foram produzidos para o SADHI documentos como diagrama de casos de uso, diagramas de classes, diagrama de atividades e diagrama de sequência. Em outros casos, foram 1 Disponível em https://gitlab.devops.ifrn.edu.br/adorilson/sadhi­docs/­/wikis/home
23. Capítulo 6. FUNDAMENTAÇÃO TEÓRICA 22 atualizados documentos existentes como a planilha que descrevia os perfis de usuário dentro do sistema e cada uma de suas permissões. 6.4 Manutenção Outra necessidade básica dos softwares refere­se à manutenção. Segundo Amui (2015, p. 41): Manutenção é o termo para qualquer esforço que é colocado em uma parte do software após ele ter sido desenvolvido e colocado em operação. Ou, ainda, po­ demos definir como sendo o processo de melhoria e otimização de um software já desenvolvido, visando a correção de defeitos que este venha a ter eventual­ mente. Ainda segundo o mesmo autor Amui (2015, p. 40), sua importância se dá por: A manutenção de software, além de reparar, ajustar, também garante melhorias constantes com o objetivo de prevenir falhas e buscar um estado de perfeição, quando possível. Estas ações deixam o software sempre útil às necessidades do negócio, estendendo o seu uso e aumentando o seu ciclo de vida. Segundo Sommerville (2011, p. 170), existem três tipos de manutenção de sistema: cor­ reção de defeitos, adaptação ambiental (esse tipo ocorre quando algum aspecto do ambiente do sistema, tal como o sistema operacional, é alterado e o software deve ser atualizado para acompanhar as mudanças) e adição de funcionalidade. É bom destacar que as linhas que divi­ dem cada tipo de manutenção nem sempre são bem divididas. O próprio autor destaca isso ao exemplificar que um sistema pode receber novas funcionalidades quando ele é adaptado a um novo ambiente. Nesse caso, ele adquiriu uma nova funcionalidade graças a uma manutenção de adaptação ambiental. Essa também foi uma das dimensões abarcada pela prática profissional descrita no pre­ sente relatório. O trabalho concentrou­se principalmente em dois tipos de manutenção: a corre­ ção de defeitos e a adição de novas funcionalidades e melhorias. As modificações que eram de­ mandadas no sistema eram catalogadas por meio de “issues”, um recurso da plataforma GitHub para documentar necessidades do software. Uma das issues2 resolvidas dizia respeito a um problema com as rotas do sistema. Quando 2 https://github.com/IFRN/sadhi/pull/134
24. Capítulo 6. FUNDAMENTAÇÃO TEÓRICA 23 o usuário clicava no botão ”Cancelar”na tela de ”Cadastro de Usuários”, a menos que ele tivesse permissões de Diretor Acadêmico, o sistema o redirecionava para uma tela branca. Em outro caso, foram removidos do código números mágicos que dificultavam a le­ gibilidade do código. Números mágicos, segundo DIAS (2017), “seriam presença de valores numéricos ou textuais constantes no código que não sejam auto descritivos”. Ainda merece des­ taque que essa correção não é percebida pelos usuários do sistema, ela visa melhorar a qualidade do código para as equipes de programadores. 6.5 Prototipagem de novos componentes Nessa seção, convém dar um breve detalhamento a respeito dos planos de melhorias no SADHI. Em uma das reuniões entre o núcleo de Ceará–Mirim e a equipe de desenvolvimento em Ipanguaçu ventilou­se a possibilidade de lançar uma nova versão do sistema usando um framework baseado em Python, o Django. Pensar em remodelar o sistema é razoável. Para Sommerville (2011, p. 164), “a mudança é inevitável caso os sistemas de software devam permanecer úteis”. Na verdade, em alguns casos, reformar o software em um processo conhecido como reengenharia pode ser a opção mais viável. Segundo Pressman (2011, p. 662), em alguns casos, quando a manutenção de um software se tornou muito difícil de realizar, convém reformá­lo para garantir melhor desempenho e novas funcionalidades. Não é possível afirmar que o SADHI se encontra, necessariamente, na categoria de soft­ ware que seria melhor remodelar. Porém, cabe pesar alguns benefícios de uma eventual adoção do Django, ou mesmo outro framework para desenvolvimento de sistemas web. Como dito an­ teriormente, Django é baseado em Python, que segundo levantamento do site Stack OverFlow (2021), é uma das linguagens de programação mais populares do mercado. Sendo utilizada no desenvolvimento do SUAP, o que facilitaria eventuais integrações e intercâmbio com a equipe de desenvolvimento daquele sistema. Python também é a linguagem de programação que está em processo de adesão para todas as disciplinas da área de Sistemas de Informação no curso de Informática no Campus Ceará­Mirim. Embora não tenha sido possível concretizar essa nova versão, foram desenvolvidos pro­ tótipos de telas que integrariam esse novo sistema. Isso será abordado em detalhes adiante no
25. Capítulo 6. FUNDAMENTAÇÃO TEÓRICA 24 capítulo 7.
26. 25 7. DESCRIÇÃO DAS ATIVIDADES 7.1 Projeto Integrador No início de todo o projeto de desenvolvimento do SADHI, demos os primeiros passos buscando saber qual seria as melhores ferramentas para isso. Desta forma, foram feitas algumas reuniões com o objetivo de definir qual framework utilizar no projeto ou qual nos atendia melhor e qual o propósito da nova versão e da versão atual. Durante nosso percurso inicial pensamos em duas opções de frameworks sendo elas o Django baseado em Python e o Laravel baseado em PHP, e como já mencionado nos textos anteriormente no capítulo 6, escolhemos o Django para a nova versão do projeto pois era de nosso interesse que o projeto passasse a ter o Python como sua linguagem de programação principal. Feito isso, por meio de reuniões, fizemos alguns ajustes no modo de como iríamos tra­ balhar com essa nova abordagem e também foi feito uma pesquisa para apontar detalhes que levamos em consideração como, por exemplo, as diferenças de popularidade entre as tecnolo­ gias ou o poder de eficiência para o nosso propósito. Com isso, levamos esses dados para a equipe responsável por aprovar ou não essas ideias. 7.2 Aprendizado de tecnologias utilizadas no sistema Para entender melhor como a estrutura do sistema do SADHI funciona, foi necessário aprender um pouco mais sobre as tecnologias usadas para o seu desenvolvimento do lado do cliente e do lado do servidor(client­side e server­side), ou seja, tecnologias usadas para o uso do cliente e para o uso do servidor funcionando simultaneamente para emitir informações visuais pela máquina que acessa o site e o controle de dados com o servidor que organiza os dados para serem enviados para os clientes, solicitadas pelos mesmos. Sendo assim, foi utilizado a plataforma online de cursos gratuitos Curso em Vídeo1, lançada em 2013 pelo educador de sistemas de informação Gustavo Guanabara, para auxiliar nessa aprendizagem, Sendo eles, primeiramente, o curso de Git e GitHub para o domínio de versionamento do código, PHP Básico e PHP POO para aprender e entender a linguagem de 1 Disponível em: https://www.cursoemvideo.com/cursos/
27. Capítulo 7. DESCRIÇÃO DAS ATIVIDADES 26 programação utilizada pelo sistemas no lado do servidores, e por conseguinte foram feitos os cursos de HTML5, JavaScript e todos os cinco módulos do Curso HTML5 e CSS3 para toda a parte visual das páginas. Além disso, foram usados os conteúdos apresentados em sala de aula durante os 4 anos do curso de Informática do IFRN. Além destes cursos, também aprendemos através do canal Node Studio Treinamentos2 as linguagens PHP, JavaScript, CSS e HTML, disponível no YouTube e usamos o site Stack Overflow3 para nos auxiliar com pequenos problemas de ajustes de sintaxe dos códigos, fizemos isso dedicando parte das nossas carga horárias programando e testando na prática os recursos ensinados nos cursos para aprimorar nossas técnicas nas linguagens de programação que iremos usar mais tarde no projeto. Desta forma, foi possível efetuar essa etapa fundamental da compreensão do projeto e poder gerar ou localizar futuras edições para melhorá­lo de acordo com as demandas. 7.3 Estudo do código­fonte do SADHI O estudo do código fonte foi uma parte muito importante para a continuidade das ativi­ dades que seriam desenvolvidas. Foi preciso estudar como as partes se comportava em conjunto para formar o todo, seja ela visual ou sua parte interna responsável pelo controle e processamento de dados. Para entender melhor sobre como cada uma dessas partes funcionavam, foi­se obser­ vado, primeiramente, que todo o projeto é uma aplicação para WEB. Desta forma, o seu código obedece a uma estrutura específica de aplicação tendo o objetivo de criar páginas visuais para acesso de usuários(cliente) e o funcionamento de servidores em máquinas. Essas estruturas eram programadas por JavaScript, CSS e HTML para estilização e emissão de recursos visuais para os clientes, e as programações por PHP e banco de dados pelo lado do servidor que contém esses dados e os processam antes de enviá­los ao cliente. Após essa leitura profunda de todo o código do projeto e a compreensão de acordo com as linguagens de programação que foram usadas, passamos a testar a estruturação de dados e funcionamento do sistema a fim de associar as páginas visuais aos códigos e entender o funcio­ 2 Disponível em: https://www.youtube.com/c/NodeStudioTreinamentos 3 Disponível em: https://pt.stackoverflow.com
28. Capítulo 7. DESCRIÇÃO DAS ATIVIDADES 27 namento com a experiência de um cliente. Tendo em vista todo o funcionamento do sistema e seus comportamentos, vimos, com ajuda do artigo publicado inicialmente pela equipe de Ipanguaçu, que este sistema havia sido es­ crito utilizando padrão Model­View­Controller (MVC) como mostra na Figura 7.1, que deveria ter, por efeito desta arquitetura, facilitado o entendimento do código. Entretanto, devido a forma como os elementos foram escritos tendo em vista a quantidade de elementos de um componente está em outro, como por exemplo a presença de elementos como trechos de código da camada Model estar na camada View ou até mesmo no Controller, tirando o real sentido e objetivo dessa construção. Isso acabou por dificultar as alterações no projeto. Figura 7.1 – Estrutura de diretórios Fonte: Autoria própria. 7.4 Resolução de problemas e melhorias Nesta etapa, utilizamos alguns métodos de organização no projeto para criar um fluxo de informações eficientes e que funcionasse muito bem para a demanda do projeto. Durante
29. Capítulo 7. DESCRIÇÃO DAS ATIVIDADES 28 esse processo, todo o código do projeto estava disponível no GitHub4 5, que nos possibilitou trabalhar no mesmo projeto em máquinas diferentes e deixar uma cópia para testes permitindo que todos os membros pudessem contribuir com os códigos e as áreas específicas onde cada um iria contribuir, além disso, todas as reuniões e comunicados importantes a respeito dos afazeres eram discutidos via Discord e Meet. Nessa perspectiva, foram utilizados alguns conceitos já aprendidos anteriormente sobre as funcionalidades que o GitHub pode oferecer para a ajudar na organização e no monitoramento e controle do que estava sendo produzido, como issues, forks, clones, pull requests, repositórios, commits, organização no GitHub e outros conceitos como exemplificados na Figura 7.2 e Figura 7.3. Figura 7.2 – Lista de issues. Fonte: Autoria própria. Uma melhoria muito importante para o funcionamento do sistema, como citado no ca­ pítulo 6, foi a remoção de números mágicos do código que dificultavam a sua legibilidade. No caso do código do SADHI, números mágicos foram utilizados para representar as permissões de usuários exigidas para cada ação dentro do sistema. Por exemplo, caso o sistema exigisse para determinada função permissão igual a 1, isso quer dizer que a função exige que o usuário tenha permissões de Professor para poder acessar. O grande problema desse recurso, como dito anteriormente, é que o significado do nú­ 4 Disponíveis em: https://github.com/IFRN/sadhi/issues 5 Disponíveis em:https://github.com/IFRN/sadhi/pulls
30. Capítulo 7. DESCRIÇÃO DAS ATIVIDADES 29 Figura 7.3 – Lista de pull requests. Fonte: Autoria própria. mero é de difícil recuperação para um programador novato. Existe a possibilidade de colocar comentários para esclarecer, mas como ocorreu no SADHI, alguns dos comentários que descre­ viam o significado dos números estavam incorretos. Na figura 7.4, é possível observar a diferença de legibilidade que existe entre um trecho do código do SADHI que tem números mágicos (trecho à esquerda), e o mesmo código após a manutenção (trecho à direita). Ainda merece destaque que essa correção não é percebida pelos usuários do sistema, ela visa melhorar a qualidade do código para as equipes de programadores. Figura 7.4 – Antes e depois da remoção de um número mágico de um mesmo trecho de código. Fonte: Autoria própria. Esse fluxo de trabalho foi seguido durante o ano de 2021, trazendo melhorias ao usuário com as modificações das telas que trouxeram mais informações e deram as telas mais funciona­ lidades visuais que facilitaram a compreensão do conteúdo e melhor usabilidade. Desse modo, conseguimos cumprir as metas de melhorar a performace de algumas ferramentas das páginas
31. Capítulo 7. DESCRIÇÃO DAS ATIVIDADES 30 de acordo com a demanda de alterações no código que tínhamos de apresentar soluções. 7.5 Construção de diagramas Perante as alterações já feitas no projeto e todas as etapas de organização para resolver os problemas pendentes, surgiu a necessidade de se produzir alguns modelos de diagramas para melhorar a compreensão do fluxo de dados do sistema já que o mesmo até então tinha apenas um diagrama produzido por Thaynara Alves e Esteffane Menezes, com isso fizemos mais alguns diagramas seguindo a Linguagem de Modelagem Unificada (UML). Desse modo, foi possível observar de uma forma mais ampla e entender melhor como o sistema funciona e até mesmo tornar o processo de entendimento mais eficiente para outras pessoas que quiserem contribuir ou que entrarem no projeto futuramente, pois este também foi um dos nossos focos durante a produção. Dentre os diagramas desenvolvidos destacamos aqui dois deles6, úteis para situações di­ ferentes. O primeiro deles é o diagramma de casos de uso, que possui a característica de descrever as funcionalidades de alguma parte do sistema e quais atores interagem com essa funcionalidade. É um diagrama simple e mostra como um ator pode se comportar em diversas situações como mostrado na Figura 7.5. Devido sua finalidade e simplicidade é útil para a equipe de desenvol­ vimento se comunicar dos usuários do sistema. No SADHI, há usuários que possuem permissões diferentes dentro do sistema, ou seja, possuem funções próprias. Para entender melhor as suas funcionalidades, segue abaixo os atores presentes no diagrama e os casos de usos que poderão executar: Usuário Anônimo: representa uma pessoa que acessa o sistema sem fazer login. Poderá executar os seguintes casos de uso: • Ver horários Aluno: representa uma pessoa que faz login com uma matrícula de aluno. Além dos casos de uso do Usuário Anônimo, poderá executar os seguintes: 6 Disponível em: https://github.com/IFRN/sadhi/issues/139
32. Capítulo 7. DESCRIÇÃO DAS ATIVIDADES 31 Figura 7.5 – Visão geral do diagrama de casos de uso. Fonte: Autoria própria.
33. Capítulo 7. DESCRIÇÃO DAS ATIVIDADES 32 • Gerenciar dados pessoais Servidor: representa uma pessoa que faz login com uma matrícula de servidor. Ao con­ trário dos outros atores, que foram definidos no banco de dados, o ator Servidor foi criado nesse diagrama com o intuito de representar funções comuns a vários atores e evitar repetições desne­ cessárias. Além dos casos de uso do Usuário Anônimo, ele pode executar os seguintes casos: • Gerenciar dados pessoais Apoio Acadêmico: acessa o sistema como servidor de Apoio Acadêmico. Além dos casos de uso padrões dos servidores, poderá executar os seguintes: • Gerenciar ambientes Diretor Acadêmico: acessa o sistema como um servidor com responsabilidades de Di­ retor Acadêmico. Possui as mesmas permissões comuns aos outros sevidores, além de poder: • Gerenciar usuários • Gerenciar cursos • Gerenciar semestres e módulos Coordenador de Curso: representa um servidor que atua como Coordenador de Curso. Além dos casos de uso comuns a todos os servidores, poderá executar os seguintes, sendo o acesso restrito ao curso que coordena: • Gerenciar disciplinas • Gerenciar turmas • Gerenciar ofertas
34. Capítulo 7. DESCRIÇÃO DAS ATIVIDADES 33 Comissão de Horários: acessa o sistema como servidor integrante da Comissão de Ho­ rários. Pode executar os mesmos casos de uso comuns aos demais servidores e poderá executar os seguintes: • Alterar disponibilidade dos docentes • Alterar vínculos dos docentes • Editar/excluir simulações de horários • Publicar uma simulação de horários como horários do semestre Professor: acessa o sistema como professor. Executa os casos de uso comuns aos servi­ dores, além de poder executar os seguintes: • Ver histórico/rodízio de horários • Planejamento de distribuição de carga horária • Cadastrar links do ensino remoto • Ver gráfico de carga horária • Ver relatório de horários das turmas • Gerenciar vínculos de disciplinas • Consultar vínculos dos docentes • Visualizar simulações de horário • Consultar disponibilidade dos docentes • Gerenciar disponibilidade Por conseguinte as etapas anteriores, fizemos algumas atualizações a respeito de cada perfil presente no sistema e suas permissões. Para isso, utilizamos uma planilha para separar, analisar e determinar o que cada usuário faria dentro do site, ou seja, o que seria possível alterar ou não, como mostrado na Figura 7.6.
35. Capítulo 7. DESCRIÇÃO DAS ATIVIDADES 34 Figura 7.6 – Planilha Perfis x Permissões Fonte: Autoria própria O segundo diagrama apresentado neste documento, é o diagrama de entidades e relacio­ namentos. Esse tipo de diagrama descreve a estrutura estática das entidades no banco de dados e seus relacionamentos. O diagrama criado é apresentado na Figura 7.7. Com ele, teremos uma melhor compreensão de como as informações são armazenadas no banco de dados. Vale ressaltar que os diagramas produzidos mostram como o sistema é atualmente, o que possibilitou à equipe observar pontos que podem ser melhorados futuramente. Por exem­ plo, por uma questão de transparência alguns dos casos de uso que atualmente são exclusivos do ator Professor poderiam ser remodelados e concedidos a outros atores também, tais como ver/consultar disponibilidade/vínculos dos docentes e ver histórico de rodízios de horários. 7.6 Prototipagem de componentes para uma nova versão A proposta e idealização da versão de prototipagem do SADHI surgiu com a necessidade de se construir um novo sistema com códigos mais limpos (melhor construído), com menos defeitos e que tivesse telas mais simples e intuitivas para o usuário. Porém, na medida do possível e viabilidade, algumas dessas ideias poderiam ser aproveitadas e implementadas também na versão atual. Desse modo, duas telas do sistema foram escolhidas para serem repensadas nessa etapa: tela de montagem dos horários e tela de vínculos de disciplinas. O motivo da escolha dessas
36. Capítulo 7. DESCRIÇÃO DAS ATIVIDADES 35 Figura 7.7 – Diagrama de Entidades e Relacionamentos. Fonte: Autoria própria.
37. Capítulo 7. DESCRIÇÃO DAS ATIVIDADES 36 telas foram: 1. Relevância no sistema: a tela de vínculos é a tela que cada docente indica no sistema quais disciplinas assumirá naquele semestre, enquanto que a tela de montagem de horários é a tela onde a comissão de horários faz a montagem de horários propriamente dita, alocando disciplina/professor nos horários de aula das turmas. São telas de uso intenso na confecção dos horários de aula de um semestre letivo. 2. Reclamações dos usuários: embora não tenha sido feito nenhum tipo de pesquisa, é comum ouvirmos reclamações dos usuários ou dúvidas constantes no uso dessas telas. O Campus de Ceará­Mirim não possui docente especialista na área de Web Design. As­ sim, foi convidado para colaborar nesta tarefa o professor Cesimar Xavier, do Campus Zona Norte, que indicou uma biblioteca JavaScript focada em interfaces com usuários, chamada TO­ AST UI7, e acompanhou parte deste processo. Embora o mesmo tenha dado importantes con­ tribuições, por eventualidade de suas atividades acadêmicas, foi preciso retirar­se do projeto, o que impediu de avançarmos mais na prototipagem dessas telas. 7.6.1 Prototipagem da tela de montagem de horários Após as coordenações de curso definirem as ofertas de disciplinas (ou seja, quais disci­ plinas serão ofertadas em quais turmas), após as pessoas docentes se vincularem às disciplinas e informarem disponibilidades e restrições de horários, é na tela de montagem de horários que a comissão de horários irá se debruçar para fazer a montagem de horários propriamente dita. Portanto, essa tela é uma das mais importantes do sistema, devendo ser de utilização simples, intuitiva e que minimize erros e falhas nessa etapa do processo. A Figura 7.8 apresenta a tela atual de montagem de horários de uma turma. A região central é a area onde os horários da turma vão sendo montados. Ao lado, temos uma coluna com as disciplinas, docentes e algumas informações relacionadas. Duas características dessa tela são frutos de reclamações da comissão de horários do Campus Ceará­Mirim: 7 Disponível em: https://ui.toast.com
38. Capítulo 7. DESCRIÇÃO DAS ATIVIDADES 37 Figura 7.8 – Exemplo da tela atual de montagem de horários Fonte: Autoria própria. 1. Expansão das células na região central ao passar o mouse 2. Muitos cliques para eventuais ajustes A expansão das células faz com que os elementos saiam do campo de visão do usuário e por vezes o elemento que seria clicado sai do foco do mouse, levando o usuário a clicar no lugar errado. Já em relação aos muitos cliques, isso não diz respeito à montagem dos horários em si, mas caso alguma alteração seja necessária durante a montagem dos horários (como a substituição de docentes) é necessário sair da tela, acessar outras telas, fazer as alterações, e voltar à tela de montagem de horários. Ocorre que essas mudanças são frequentes, seja porque o grupo de docentes realiza trocas entre si, seja porque essa é a forma mais simples para ”fechar”os horários de determinadas turmas. Para o primeiro caso, pensou­se em uma abordagem de arrastar e soltar. O usuário po­ deria arrastar a disciplina da barra lateral e soltar na posição desejada. De forma semelhante, se uma disciplina já está alocada mas é necessário mudar de horário, bastaria arrastá­la no próprio quadro de horários. Essa abordagem é inspirada na interface do Google Agenda, apresentada na figura 7.9. Sendo assim, as novas telas seriam construída com a aplicação Calendar8 da já citada TOAST UI. Através desta biblioteca, conseguiríamos mais facilmente alterar a forma como os 8 Disponível em: https://ui.toast.com/tui­calendar
39. Capítulo 7. DESCRIÇÃO DAS ATIVIDADES 38 Figura 7.9 – Google Agenda Fonte: Autoria própria. as disciplinas são exibidas e alocadas nos horários das turmas. O prótotipo produzido pode ser visto na Figura 7.10. Figura 7.10 – Protótipo da tela de montagem de horários feito com TOAST UI Fonte: Autoria própria Já para o problema de muitos cliques, não foi possível evoluir o protótipo até o ponto de mostrar soluções para este caso. Porém, duas ideias bases são: 1. O sistema não impedir que um professor seja alocado em um horário bloqueado, que ocorre quando ele já está em outra turma, ou quando trata­se de um horário que ele não
40. Capítulo 7. DESCRIÇÃO DAS ATIVIDADES 39 indicou disponibilidade. Neste caso, o sistema apenas avisaria ao usuário, que tomaria a decisão. Outras situações, como colocar dois professores ou disciplinas no mesmo horá­ rios ou uma quantidade de aulas diferente da prevista, também se encaixam aqui. 2. Quando for preciso alterar o docente da disciplina, ou outras alterações de cadastro, elas deveriam ser possível através dessa própria tela, sejam através de janelas modais, sejam na forma de popups, como também ocorre com Google Agenda. Em algum momento, essas telas passariam por testes com usuários, que pudessem asse­ gurar a melhor usabilidade através da implementação de botões com menor quantidade de rotas alternativas para o usuário e que todas as informações necessárias estivessem otimizadamente organizadas em um único local específico para, por exemplo, em um único clique (ou poucos), editar, arrastar e expandir um horário de qualquer disciplina. 7.6.2 Tela de vínculos de disciplinas Uma importante etapa da elaboração de horários é a distribuição de turmas/disciplinas entre o grupo docente, que no SADHI é chamado de vínculos. Cada docente é responsável por indicar seus próprios vínculos, não sendo possível que se faça de terceiros, a menos por membros da comissão de horários. A Figura 7.11 apresenta a tela de vínculos de disciplinas. Embora exista, na própria tela, uma lista com a sequência dos passos a serem seguidos, ela não é de uso intuitivo. Na verdade, a existência dessa lista apenas reforça essa percepção. Além da sequência de passos precisar ser seguida de uma forma bem restrita, a quantidade de cliques é bem grande. No Campus Ceará­Mirim, e também em outros, anteriormente ao SADHI, era utilizada uma planilha no Google Planilhas, como a apresentada na figura 7.12, para os docentes fazerem esses vínculos. Dessa forma, acreditamos que uma interface semelhante, onde fosse possível filtrar e ordenar pelas colunas seria bem útil aqui, pois seria familiar para os usuários. Não foi possível implementarmos um protótipo, porém também fez parte desta etapa de prototipagem a análise do uso da aplicação Grid9 da TOAST UI para este propósito. A Figura 7.13 apresenta um exemplo dessa aplicação retirado da documentação da biblioteca. 9 Disponível em: https://ui.toast.com/tui­grid
41. Capítulo 7. DESCRIÇÃO DAS ATIVIDADES 40 Figura 7.11 – Vínculos de Disciplinas do(a) Professor(a) Fonte: Autoria própria. Em meio ainda a esse processo de prototipagem com a finalidade de preparar um esboço para novas versões, foi preciso desenhar, programar e desenvolver novas telas para mudar a forma como o sistema funciona. Iniciamos a remodelagem de algumas páginas com o intuito de tornar algumas ferramentas melhores ao uso de usuários com permissões de edição e usuários com permissão de convidado (que possui apenas a função de ver horários e semestres), dessa forma, foram criadas durante este percurso algumas telas para visualização da proposta de um novo sistema, para que, dessa forma, os desenvolvedores pudessem realizar testes de usabilidade futuramente afim de deixar o sistema mais fácil, como consequência, e intuitivo do que a versão atual e promover uma melhor usabilidade.
42. Capítulo 7. DESCRIÇÃO DAS ATIVIDADES 41 Figura 7.12 – Exemplo de planilha usada para definir os vínculos de disciplinas Fonte: Autoria própria. Figura 7.13 – Exemplo da ferramenta grid do TOAST UI Fonte: Autoria própria.
43. 42 8. CONSIDERAÇÕES FINAIS De acordo com os resultados obtidos, os avanços e melhorias feitas no sistema mos­ tram uma nova perspectiva para os usuários, e também aos desenvolvedores, sejam elas as oti­ mizações nos códigos, implementação de operações ou adaptações para melhor atender­se às propostas tornando­se um sistema de melhor usabilidade. Tendo em vista a atribuição para as ferramentas que tiveram uma ampliação de suas funcionalidades. Apesar de que não modificamos o sistema por inteiro, conseguimos deixar a experiência de uso do sistema mais amigável, ainda que em situações pontuais, e também possibilitamos que o desenvolvimento tornar­se mais fácil com a reestruturação dos códigos, conseguindo atingir nosso objetivo de melhorar o sistema. Além disso, as contribuições feitas pelo núcleo de Ceará­Mirim os proporcionou ainda mais experiência e conhecimento sobre o projeto, tornando as atividades de resolução e melho­ rias mais eficientes. Logo após os objetivos alcançados, concluímos as demandas acerca do sistema e seu código fonte para a versão atual em funcionamento, dessa forma também as telas remodeladas para o uso de recursos do sistema e todas as mudanças no código e sua documentação. 8.1 Trabalhos futuros Um dos resultados deste trabalho foi a consolidação do núcleo de desenvolvimento do SADHI de Ceará­Mirim, que continuará com o objetivo de realizar mais contribuições, adapta­ ções e avanços para as páginas de exibições de horários e outros dados de usuário tanto externa como internamente, tendo em vista conseguir alcançar um portfólio amplo de funcionalidades que sirvam bem aos seus propósitos. Dessa forma outros grupos de desenvolvimento terão ao seu dispor formas de conhecer melhor como toda a estrutura do sistema funciona e possam uti­ lizar os feitos anteriores para problematizar e gerar novas melhorias, transformando­o em um sistema mais completo. Outros colaboradores poderão vir a fazer suas contribuições e terão acesso a todas as documentações que concluímos para que uma nova versão seja implementada ao sistema atual
44. Capítulo 8. CONSIDERAÇÕES FINAIS 43 seguindo as decisões que tomamos e decidimos ao longo de nossas pesquisas, seguindo os mo­ delos e as novas estruturas passando da linguagem de programação PHP para Django baseado em Python como linguagem principal.
45. 44 REFERÊNCIAS AMUI, S. Processos de desenvolvimento de software. Rio de Janeiro: SESES, 2015. P. 176. ANTUNES, F. Git Workflow: o que é e principais tipos. [S.l.: s.n.], 2021. Acesso em: 10 de fev. de 2022. Disponível em: <https://www.zup.com.br/blog/git­workflow>. ARAUJO, E. A. B. et al. SADHI: Sistema de Apoio à Decisão de Horários do Campus Ipanguaçu. In: ANAIS IV CONEDU. Campina Grande: Realize Editora, 2017. Disponível em: <https://editorarealize.com.br/artigo/visualizar/38596>. ATLASSIAN. Comparando fluxos de trabalho. [S.l.: s.n.]. Acesso em: 10 de fev. de 2022. Disponível em: <https://www.atlassian.com/br/git/tutorials/comparing­workflows>. COELHO, H. S. Documentação de software: uma necessidade. Texto Livre, Belo Horizonte, v. 2, n. 1, p. 17–21, 2009. Acesso em: 31 de jan. de 2022. Disponível em: <https://periodicos.ufmg.br/index.php/textolivre/article/view/16562>. DIAS, E. Números mágicos: O que são e como corrigir. [S.l.: s.n.], 2017. Acesso em: 01 de fev. de 2022. Disponível em: <https://www.devmedia.com.br/numeros­magicos­o­que­sao­e­como­corrigir/38711>. DJANGO. Overview. [S.l.: s.n.]. Acesso em: 01 de fev. de 2022. Disponível em: <https://www.djangoproject.com/start/overview/>. GARCIA, F. W. A importância do uso das tecnologias no processo de ensino­aprendizagem. Educação a Distância, Batatais, v. 3, n. 1, p. 25–48, 2013. GUEDES, M. Git e GitHub: quais as diferenças? [S.l.: s.n.]. Acesso em: 01 de fev. de 2022. Disponível em: <https://www.treinaweb.com.br/blog/git­e­github­quais­as­diferencas>. IFRN. Organização Didática do Instituto do IFRN. Natal: [s.n.], mar. 2012. Acesso em: 28 de jan. de 2022. Disponível em: <https://portal.ifrn.edu.br/ensino/legislacao­1>. . Projeto Pedagógico do Curso Técnico em Informática do IFRN. Natal: [s.n.], mar. 2012. Acesso em: 28 de jan. de 2022. Disponível em: <https://portal.ifrn.edu.br/ensino/legislacao­1>.
46. REFERÊNCIAS 45 IFRN. Resolução 25/2019 ­ CONSUP/IFRN. Natal: [s.n.], jun. 2019. Acesso em: 12 de fev. de 2022. Disponível em: <https://portal.ifrn.edu.br/conselhos/consup/resolucoes/2019/resolucao­ no­25­2019/view#:~:text=Aprova%20a%20atualiza%C3%A7%C3%A3o%20da% 20Regulamenta%C3%A7%C3%A3o%20da%20Pr%C3%A1tica%20Profissional%20no% 20%C3%A2mbito%20do%20IFRN>. KENSKI, V. M. Educação e tecnologias: O novo ritmo da informação. Campinas: Papirus, 2007. P. 62. . Tecnologias e ensino presencial e a distância. Campinas: Papirus, 2003. P. 160. KHAN ACADEMY. Introdução a HTML/CSS: criação de páginas Web. [S.l.: s.n.]. Acesso em: 01 de fev. de 2022. Disponível em: <https://pt.khanacademy.org/computing/computer­programming/html­css>. MARIADB FOUNDATION. About MariaDB Server. [S.l.: s.n.]. Acesso em: 05 de fev. de 2022. Disponível em: <https://mariadb.org/about/#entry­header>. MDN WEB DOCS. HTML: Linguagem de Marcação de Hipertexto. [S.l.: s.n.]. Acesso em: 05 de fev. de 2022. Disponível em: <https://developer.mozilla.org/pt­BR/docs/Web/HTML>. . O que é JavaScript? [S.l.: s.n.]. Acesso em: 01 de fev. de 2022. Disponível em: <https://developer.mozilla.org/pt­BR/docs/Learn/JavaScript/First_steps/What_is_JavaScript>. MEDEIROS, H. Introdução ao Padrão MVC. [S.l.: s.n.], 2013. Acesso em: 08 de fev. de 2022. Disponível em: <https://www.devmedia.com.br/introducao­ao­padrao­mvc/29308>. MENEZES, E. V.; ALVES, T. S. Relatório do desenvolvimento da documentação para usuários de um software: SADHI ­ Sistema de Apoio à Decisão de Horários. [S.l.], 2020. MICHELAZZO, P. Dicas para documentação de softwares. [S.l.: s.n.], 2006. Acesso em: 31 de jan. de 2022. Disponível em: <http://www.michelazzo.com.br/dicas­para­documentacao­de­softwares/>. NOLETO, C. Git e GitHub: o que são, quais as diferenças e como usar na prática? [S.l.: s.n.], 2020. Acesso em: 01 de fev. de 2022. Disponível em: <https://blog.betrybe.com/tecnologia/git­e­github/>. PHP. O que é PHP? [S.l.: s.n.]. Acesso em: 30 de jan. de 2022. Disponível em: <https://www.php.net/manual/pt_BR/intro­whatis.php>.
47. REFERÊNCIAS 46 PRESSMAN, R. S. Engenharia de Software: Uma abordagem profissional. 7ª. [S.l.]: Mc Graw Hill, 2011. P. 780. SOMMERVILLE, I. Engenharia de Software. 9ª. São Paulo: Pearson Prentice Hall, 2011. STACK OVERFLOW. Stack Overflow Developer Survey 2021. [S.l.: s.n.], 2021. Acesso em: 01 de fev. de 2022. Disponível em: <https://insights.stackoverflow.com/survey/2021#technology>. WIKIPEDIA. UML. [S.l.: s.n.]. Acesso em: 01 de fev. de 2022. Disponível em: <https://pt.wikipedia.org/wiki/UML>.
48. Apêndices
49. 48 A. DESCRIÇÃO DAS MELHORIAS E CORREÇÕES FEITAS NO SADHI Como explicitado ao longo do relatório, as correções e melhorias feitas no SADHI basearam­se nas chamadas “issues”, um conceito do GitHub que descreve atividades que devem ser realizadas no projeto. Abaixo, está a relação das issues resolvidas pela dupla de discentes no âmbito da sua prática profissional.
50. APÊNDICE A. DESCRIÇÃO DAS MELHORIAS E CORREÇÕES FEITAS NO SADHI 49 Tabela A.1 – Relação das issues resolvidas durante essa prática profissional Issue Descrição 75 Exibir cor do professor no nome dele em páginas com calendário. 48 Em algumas telas, uma das colunas estava rotulada como “Período”, ela foi renomeada para “Semestre”. Além disso, outra coluna nomeada como “Disciplina” foi renomeada para “Componente curricular”. 77 Em algumas telas do sistema não haviam botões de cancelar ou haviam botões sem redi­ recionamento para outra página, por isso, foi preciso substituir as tags <button> por tags <a> para estes botões de “Cancelar” para dar a funcionalidade correta. 79 Acrescentar área do professor na listagem de vínculos que se encontra na tela de lista de professores. 54 Na barra de título de uma das páginas, havia um erro de digitação que precisava ser corri­ gido. 92 No menu, no item ”Disciplinas e Disponibilidades”, o subitem ”Consultar disciplinas dos docentes”é alterado para ”Consultar vínculos dos docentes”. A mudança da nomenclatura também ocorre nas telas subsequentes. 133 Mudar rotas de usuários com permissões diferentes nos botões de “Cancelar” de algumas páginas. 87 A fim de pensar um novo design para o SADHI, foi solicitado tirar prints de todas as telas do sistema. 139 Diagramação do sistema do SADHI para ajudar na compreensão de como ele funciona. 100 Estudar componente JavaScript de Calendario: https://ui.toast.com/tui­calendar. 106 Na tela de login, deveria inserir uma janela modal que seria ativada quando o usuário clicasse no botão “Esqueci minha senha”. Essa janela lembraria ao usuário que ele deveria logar no SADHI com as mesmas credenciais do SUAP, caso o usuário confirmasse que queria redefinir a senha, ela deveria direcioná­lo para concluir a operação no SUAP. 41 No código do SADHI, haviam muitos “números mágicos”, que é uma má­prática de pro­ gramação que ocorre quando atribuímos valores que não são auto descritivos a números e valores textuais. A issue pedia que isso fosse corrigido, isso foi feito por substituir os números mágicos por constantes que tinham seu sentido facilmente recuperável.
51. 50 B. DOCUMENTOS E DIAGRAMAS PRODUZIDOS PARA O PROJETO Aa tabela B descreve as contribuições em forma de documentos produzidos ou atualiza­ dos durante essa prática profissional. Tabela B.1 – Documentos produzidos ou atualizados. Documento Contribuição Diagrama de casos de uso Produção Diagrama de dados de relacionamento Produção Diagrama de atividades Produção Diagrama de sequência ­ login Produção Documento de telas do SADHI (produzido para a issue 87). Produção Planilha Perfis x Funcionalidades Atualização Comparativo Django x Laravel Produção Protótipo de novas telas Produção Documento de requisitos Atualização