Reengenharia de um sistema de eLearning

UMinho | 2023 Ricardo Vieira Carvalho Reengenharia de um Sistema de eLearning Setembro de 2023 Ricardo Vieira Carvalho Reengenharia de um Sistema de eLearning outubro de 2022 duardo João Gomes Teixeira da Costa iii Ricardo Vieira Carvalho Reengenharia de um Sistema de eLearning Dissertação de Mestrado Mestrado Integrado em Engenharia Informática Trabalho efetuado sob a orientação do Professor Doutor Orlando Manuel Belo iv DECLARAÇÃO Nome: Ricardo Vieira Carvalho Título da Dissertação: Reengenharia de uma Sistema de eLearning Mentores: Orlando Manuel de Oliveira Belo Ano de Conclusão: 2023 Designação do Mestrado: Mestrado Integrado em Engenharia Informática Este é um trabalho académico que pode ser utilizado por terceiros desde que respeitadas as regras e boas práticas internacionalmente aceites, no que concerne aos direitos de autor e direitos conexos. Assim, o presente trabalho pode ser utilizado nos termos previstos na licença abaixo indicada. Caso o utilizador necessite de permissão para poder fazer um uso do trabalho em condições não previstas no licenciamento indicado, deverá contactar o autor, através do RepositóriUM da Universidade do Minho. Atribuição-NãoComercial-SemDerivações CC BY-NC-ND https://creativecommons.org/licenses/by-nc-nd/4.0/ Universidade do Minho, 16/10/_2023__ Assinatura: ___________________________________ Assinado por : Ricardo Vieira Carvalho Num. de Identificação: 15025255 Data: 2023.10.16 19:08:33+01'00' v AGRADECIMENTOS Gostaria de agradecer a todas as pessoas que acompanharam e que conheci durante o meu percurso académico, sem exceção, por todos os momentos ao longo deste caminho. Gostaria de agradecer a todos os meus amigos, que sempre me ajudaram com tudo o que lhes foi possível ajudar, a eles, um muito obrigado. Gostaria de agradecer fundamentalmente à minha família: aos meus pais, à minha irmã e aos meus avós por tudo o que me ensinaram, por fazerem de mim a pessoa que sou hoje. Gostaria de agradecer à minha mulher e ao meu filho por todo a apoio e motivação que me deram. A eles, dedico esta dissertação. vi DECLARAÇÃO DE INTEGRIDADE Declaro ter atuado com integridade na elaboração do presente trabalho académico e confirmo que não recorri à prática de plágio nem a qualquer forma de utilização indevida ou falsificação de informações ou resultados em nenhuma das etapas conducente à sua elaboração. Mais declaro que conheço e que respeitei o Código de Conduta Ética da Universidade do Minho. Resumo vii Resumo Reengenharia de um Sistema de eLearning A integração de módulos de serviços é aceite como uma necessidade no desenvolvimento de sistemas complexos, uma vez que garante que todos os componentes individuais de um sistema atinjam o propósito para o qual o sistema, como um todo, foi desenhado. Essencialmente, construir um sistema não é nada mais que integrar diversas partes num todo. A divisão de um sistema em diversas partes garante uma maior produtividade e qualidade das operações de desenvolvimento e teste, permitindo realizar estas tarefas de forma mais eficiente e focada em cada funcionalidade específica. Isso resulta numa maior produtividade, uma vez que equipas de desenvolvimento podem trabalhar de forma paralela e colaborativa em diferentes módulos, agilizando o processo de construção do sistema como um todo, bem como permite um menor custo de manutenção do próprio sistema. Esta técnica não é apenas usada para conectar os diversos serviços de um sistema. Permite também fazer a conexão de um sistema com outros sistemas externos. Neste trabalho de dissertação identificou-se e caracterizou-se as diversas funcionalidades dos serviços que se pretendiam integrar num sistema de avaliação de conhecimento, de forma a implementar um sistema de eLearning que operasse de forma consistente. Grande parte do trabalho realizado envolveu a análise de um conjunto de módulos de serviços implementados anteriormente num novo sistema, com uma nova arquitetura, acolhendo os tradicionais serviços de autenticação e validação de credenciais. A nova versão do sistema que alcançámos, resultado de um processo de reengenharia bastante trabalhoso, permite definir e suportar processos de avaliação do conhecimento de estudantes em diversos domínios de estudo, bem como suporta todos os serviços de gestão e manutenção da informação associada como a avaliação de estudantes, nomeadamente, os domínios e subdomínios de estudo, as estruturas de conhecimento dos processos de avaliação e os serviços de análise relacionados com os resultados obtidos pelos alunos. Palavras-Chave: eLearning, Reengenharia, Módulos, Serviços Abstract viii Abstract Reengineering of an eLearning System The integration of service modules is widely accepted as a necessity in the development of complex systems, as it ensures that all individual components of a system achieve the purpose for which the system as a whole was designed. Essentially, building a system is nothing more than integrating various parts into a whole. Breaking down a system into various parts enhances productivity and the quality of development and testing operations, allowing these tasks to be carried out more efficiently and focused on specific functionalities. This results in increased productivity, as development teams can work in parallel and collaboratively on different modules, streamlining the overall system construction process, as well as reducing the maintenance cost of the system itself. This technique is not only used to connect various services within a system but also to connect a system to other external systems. In this dissertation work, the various functionalities of the services to be integrated into a knowledge assessment system were identified and characterized in order to implement a consistent eLearning system. Much of the work involved analyzing a set of previously implemented service modules in a new system with a new architecture, utilizing traditional authentication and credential validation services. The new version of the system that we achieved, as a result of a rather laborious reengineering process, allows for the definition and support of knowledge assessment processes for students in various study domains, as well as supporting all information management and maintenance services associated with student assessment. This includes study domains and subdomains, knowledge structures of assessment processes, and analysis services related to student performance results. Key-Words: eLearning, Reengeneering, Modules, Services Índice ix Índice 1 Introdução .................................................................................................................. 14 1.1 Contextualização e Motivação .....................................................................................14 1.2 O Trabalho e seus Objetivos .......................................................................................15 1.3 O Trabalho Realizado .................................................................................................16 1.4 Organização da dissertação .........................................................................................17 2 Sistemas de eLearning, Modularização e Integração ................................................. 19 2.1 Sistemas de eLearning ................................................................................................19 2.2 Modularização de Sistemas .........................................................................................22 2.3 Integração de Sistemas ..............................................................................................25 3 O Sistema Leonardo .................................................................................................... 28 3.1 Apresentação Global ...................................................................................................28 3.2 Os Atores de Sistema .................................................................................................31 3.2.1 Alunos ................................................................................................................33 3.2.2 Professores .........................................................................................................35 3.2.3 Administradores ..................................................................................................37 3.3 Validação do sistema ..................................................................................................39 4 Os Módulos do Sistema Leonardo ............................................................................... 41 4.1 Front-end Base ..........................................................................................................43 4.2 Autenticação e Registo de Utilizadores .........................................................................45 4.3 A Base de Dados do Sistema .......................................................................................49 4.4 O Gestor de Informação .............................................................................................57 4.5 O Serviço de Criação de Testes ...................................................................................65 4.6 A Avaliação de Conhecimento .....................................................................................74 4.7 Gerador e avaliador de Quizzes ...................................................................................75 5 Comentário Final ......................................................................................................... 78 Introdução 16 grande vantagem relativamente às duas anteriores, que é a facilidade de integrar novos serviços e módulos, sendo que para a integração de um novo serviço é apenas necessário a implementação de uma nova interface para o mesmo (Vulcano, 2019). Na Reengenharia deste sistema, foi utilizada a integração em Estrela, devido à existência de apenas 3 serviços e devido à prévia implementação da mesma nos módulos já implementados. Com esta metodologia de integração, houve apenas a necessidade de conectar o front-end ao back-end e, o back-end à base de dados. Os objetivos desta dissertação foram definidos de forma a estabelecer a plataforma base para o sistema Leonardo (Belo, Coelho, e Fernandes, 2019), de forma a garantir que este incorporasse um serviço de autenticação capaz de validar credenciais de acesso de forma eficiente e robusta e que todos os seus serviços ficassem devidamente integrados. Para isso foi necessário desenvolver o trabalho de integração de forma metódica, para que a consistência e a integridade da base de dados geral do sistema se mantivessem quando suportasse os processos base do sistema e a troca de informação que pudesse ocorrer entre eles. Esperavase, assim, alcançar um novo sistema de eLeaning, uma nova versão para o sistema Leonardo, uniforme, composta pelos diversos serviços e módulos desenvolvidos até ao momento, corretamente integrados, cuja interação entre eles garantisse um funcionamento global do sistema correto, sem qualquer perda de informação. 1.3 O Trabalho Realizado Antes de iniciarmos este trabalho de dissertação, o sistema Leonardo era apenas composto por dois módulos de serviços simples, não integrados – um front-end e um back-end – suportados por uma base de dados. No âmbito desses dois serviços, foram desenvolvidos diversos módulos, como resultado de várias iniciativas independentes levadas a cabo por outros colegas, em trabalho de licenciatura, ou mesmo em trabalhos de dissertação. Desse leque de serviços, realçamos os seguintes: • gestão de utilizadores, que permite o registo, ativação e criação de utilizadores. • gestão da informação base, que permite gerir todas as informações de dados relativos ao funcionamento de uma disciplina. Introdução 17 • avaliação de conhecimento, que permite avaliar corretamente não só as notas dos alunos, como o estado de espírito, atenção e dificuldades encontradas pelos mesmos. • Gerador e realizador de Testes, que permite a geração e realização de testes para os vários domínios em sistema • Gerador e Avaliador de Quizzes • Data Warehouse Após a análise da implementação de cada um desses serviços, delineou-se um plano de trabalhos para fazer a sua integração num único sistema, aquilo que viríamos a designar mais tarde por Leonardo Versão 2. Cada um desses serviços foi refactured, tendo sido analisado e reescrito de forma a não perder qualquer das funcionalidades implementadas, mas, ao mesmo tempo, garantindo-se que se tornariam mais simples e fáceis de manter (Martin Fowler et al., 1999). Desta forma, poderíamos garantir a composição de um sistema consistente e coerente, no qual todos serviços utilizariam a mesma base de dados e estruturas de partilha de informação e controlo. 1.4 Organização da dissertação Para além do presente capítulo, esta dissertação encontra-se dividida em mais quatro outros capítulos, nomeadamente: • Capítulo 2 - Sistemas de eLearning, Modularização e Integração -, um capítulo que expõe e apresenta alguns aspetos sobre o domínio de eLearning e, em particular a modularização e integração de serviços neste tipo de sistemas. • Capítulo 3 – O Sistema Leonardo -, onde é apresentado o sistema Leonardo e onde se descreve, com detalhe, os seus serviços base, bem como arquitetura e os atores do sistema. • Capítulo 4 – Módulos e Serviços do Sistema –, que apresenta e explica, detalhadamente, cada serviço e cada módulo do Sistema. Introdução 18 • Capítulo 5 – Conclusões e Trabalho Futuro -, que apresenta as conclusões alcançadas a partir da análise e desenvolvimento do sistema Leonardo, com integração modular de serviços, bem como propõe direções para trabalhos futuros. Sistemas de eLearning, Modularização e Integração 19 2 Sistemas de eLearning, Modularização e Integração 2.1 Sistemas de eLearning Um sistema de eLearning é uma ferramenta tecnológica que permite a criação, distribuição e acesso de conteúdos educacionais, sendo bastante útil para estudantes do ensino universitário e do ensino básico. Como tal, esses sistemas são frequentemente usados por instituições de ensino, mas também são utilizadas por empresas e organizações para passar conhecimento de novos conteúdos a funcionários. No futuro, é esperado que o uso de sistemas de eLearning continue a crescer, tanto em instituições de ensino como noutras áreas. Geralmente, os sistemas de eLearning incluem diversos tipos de recursos para suporte às suas atividades, como ficheiros pdf de material de estudo, aulas em vídeo, exercícios interativos, fóruns de discussão, entre muitas outras coisas. Alguns desses sistemas também oferecem outro tipo de recursos, um pouco mais avançados, como assistência ao vivo com professores, grupos de estudo online ou programas de certificação de habilitações. Os sistemas de eLearning têm se tornado uma das principais ferramentas de ensino, impulsionados, em parte, pelo aumento do uso da educação online provocado pela pandemia vivida em 2020/2021, período no qual muitas instituições de ensino optaram por oferecer aulas online em vez de aulas presenciais. Isto causou um aumento significativo do interesse por este tipo de serviços, o que, consequentemente, provocou também um aumento na demanda da sua personalização (Yadav et al., 2012). Tabela 1: Número de utilizadores de sistemas de eLearning Pré e Pós Pandemia Plataforma Alunos em 2018 Alunos em 2022 Udemy 30 milhões 52 milhões Coursera 37 milhões 113 milhões SkillShare 3.5 milhões 24 milhões A personalização de sistemas de eLearning pode ser alcançada de várias maneiras, nomeadamente através de conteúdo adaptativo, feedback e avaliação personalizada ou comunicação e interação personalizada. Por vezes, a personalização de sistemas implica, também, a inclusão de sistemas de tutoria inteligentes. Estes Sistemas de eLearning, Modularização e Integração 20 sistemas são projetados para serem mais adaptativos, tirando proveito de algoritmos de inteligência artificial para analisar o progresso e o desempenho dos estudantes e ajustar o conteúdo que deve ser apresentado a cada individuo. Esta é uma forma mais sofisticada de fazer a personalização de um sistema. No desenvolvimento de um sistema de eLearning deve-se ter em conta alguns aspetos cruciais. Um desses aspetos está diretamente relacionado com os conteúdos que o sistema deve conter que devem ser necessariamente úteis, de interesse e de fácil compreensão. Além disso, é necessário também que o sistema seja amigável (user friendly), apresentando características inovadoras que permitam captar a atenção dos utilizadores e permitam personalizar os serviços de ensino de acordo com as necessidades de cada aluno. A personalização do ensino envolve a adaptação do conteúdo, das perguntas e do ritmo de ensino acerca de um determinado tema, de forma a poder-se atender às necessidades individuais de cada estudante. Isso pode ser feito através de algoritmos de inteligência artificial que analisam o progresso e o desempenho do estudante ao longo do tempo, ajustando conteúdos e modelos de exposição ou de avaliação. A personalização do ensino pode ajudar os estudantes a aprender de maneira mais eficiente. Por exemplo, pode-se personalizar uma dada ação de ensino, com o objetivo de desafiar o aluno, implicando, brincando ou incentivando-o ao longo das sessões de trabalho que forem promovidas. Outra forma de personalização que pode ser utilizada em sistemas de eLearning implica que as perguntas apresentadas em quizzes, por exemplo, sejam selecionadas e trabalhadas de acordo o nível atual do aluno, de forma a garantir que, por exemplo, um aluno com grandes capacidades continue a ter desafios interessantes pela frente, adequado aos objetivos do seu processo de aprendizagem ou de avaliação, ou que um aluno com mais dificuldades na sua aprendizagem não fique desmotivado pela complexidade das perguntas apresentadas. Outro tipo de personalização pode ser materializado através da aplicação de técnicas de gamificação. A gamificação é o uso de elementos de jogo em contextos não lúdicos, como o ensino, para torná-los mais atraentes e motivadores (Kapp, 2012). Isso pode incluir recompensas por atingir meta ou pontuação por completar tarefas e desafios. A gamificação pode ajudar a manter os estudantes interessados e motivados, uma vez que dessa forma eles têm uma sensação de progresso, de competição e, acima de tudo, aprendem sem a noção que o estão a fazer Sistemas de eLearning, Modularização e Integração 21 devido a terem a sensação de que estão efetivamente a jogar um jogo. A combinação da personalização do ensino com a gamificação, pode ser especialmente eficaz para o ensino, uma vez que permite que o conteúdo seja adaptado às necessidades individuais dos estudantes e, em simultâneo, que os alunos tenham uma sensação de progresso e recompensa por completarem tarefas (que noutra altura seriam consideradas monótonas) e atingir metas. Outra forma de diferenciar uma plataforma deste tipo, é através da integração com as redes sociais. Hoje em dia, as plataformas de eLearning estão a ser integradas cada vez mais com este tipo de sistemas para permitir que os estudantes compartilhem conteúdos e colaborem uns com os outros de maneira mais fácil. A Inteligência Artificial tem sido cada vez mais utilizada em plataformas de eLearning, proporcionando uma série de benefícios tanto para professores como para alunos. Uma das principais vantagens do uso da Inteligência Artificial em plataformas de eLearning é o facto desta poder ser usada para preencher lacunas no conhecimento de um aluno através de recomendações de conteúdo ou exercícios personalizados. De uma forma mais ampla, uma plataforma de ensino deve ser um ambiente que proporcione uma experiência de ensino eficaz, tanto para alunos como para professores. Isso inclui fornecer recursos pedagógicos para ajudar os professores a criar aulas mais atrativas e úteis, como ferramentas para ajudar os alunos a aprender e a compreender os conteúdos que têm que estudar. Além disso, uma plataforma de ensino deve ser fácil de aceder e usar pelos seus utilizadores, de forma a que eles possam aceder ao material de ensino e realizar atividades independentemente em qualquer lugar, a qualquer momento. Apesar das evidentes e reais vantagens dos sistemas de eLearning, é importante tirar algumas elações sobre quais as razões que podem levar ao seu insucesso ou que a sua utilização fique aquém do esperado. Dentro de um leque bastante diversificado, selecionámos algumas das razões que podem conduzir ao falhanço de um sistema deste tipo. Considere-se, então, por exemplo: • Problemas de usabilidade. Alguns sistemas de eLearning são difíceis de usar e de explorar, o que pode desencorajar os utilizadores a continuar a utilizar o sistema e os seus serviços. • Falta de conteúdo relevante. É importante que os sistemas de eLearning ofereçam conteúdo relevante e atualizado, para encorajar os seus utilizadores a continuar a utilizarem os seus serviços. Sistemas de eLearning, Modularização e Integração 22 • Problemas técnicos. A ocorrência frequente de problemas técnicos é algo bastante crítico para um sistema de eLearning, uma vez que causa instabilidade, interrupções no serviço e problemas de compatibilidade, entre outras coisas mais. • Falta de suporte. Alguns sistemas de eLearning não têm mecanismos adequados para oferecerem o suporte operacional necessário aos seus utilizadores. Isso dificulta a utilização do sistema quando os utilizadores enfrentam problemas ou dificuldades com os seus serviços • Falta de personalização. A personalização deveria ser uma característica base de todos os serviços de um sistema de eLearning, por forma a que este se possa adequar às necessidades específicas dos seus utilizadores, professores e alunos. Não sendo possível personalizar serviços pode ser motivo para abandonar o sistema. Resumindo, um sistema de eLearning deve ser projetado especificamente para atender às necessidades de “ambos os lados” da sala de aula, promovendo ações de aprendizagem eficazes e um ensino eficiente. Qualquer sistema de eLearning deve permitir aos professores colocarem facilmente conteúdos de estudo e material de suporte. 2.2 Modularização de Sistemas A modularização de sistemas tem-se tornado cada vez mais popular. Esta é uma abordagem que permite um desenvolvimento mais eficiente e rápido do próprio sistema. Quando um sistema é dividido em módulos, cada um deles pode ser tratado de forma individual, o que facilita o processo de adição, remoção e substituição de componentes, por exemplo. No entanto, é importante sublinhar que cada módulo não pode funcionar de forma totalmente independente, mas que deve ser capaz de se integrar no sistema global de maneira eficiente. Este tipo de estrutura modular permite uma maior flexibilidade e facilidade de manutenção do sistema como um todo (Wright, 2022). Tendo isto em conta, nos dias que correm, ao desenvolver um novo sistema, seja ele de eLearning ou não, a tendência é fazer a sua implementação de forma distribuída, envolvendo a colocação de componentes em locais diferentes (Coulouris et al., 2012). Sendo que um sistema distribuído é composto por diferentes componentes que são distribuídos em locais diferentes, como servidores ou dispositivos conectados em Sistemas de eLearning, Modularização e Integração 23 rede, a abordagem de desenvolvimento modular tornou-se um conceito essencial, pois permite dividir o sistema em partes independentes e interconectadas Um módulo, ou um subprograma, é um bloco procedimental que não é autónomo (Busbee 2013),. Um módulo, não é reutilizável para vários serviços, podendo, no entanto, ser facilmente copiado, adaptado e integrado noutros sistemas. Um módulo é uma unidade de encapsulamento de funcionalidades relacionadas que podem ser facilmente copiadas, adaptadas e integradas noutros sistemas e que contém um conjunto de instruções ou algoritmos que realizam uma tarefa específica dentro de um sistema maior (Rellermeyer, Duller, and Alonso, 2009). Um módulo pode ser uma forma de moldar o código-fonte de um programa, para que este possa ficar mais coeso. Além disso permite transformar programas complexos, de grandes dimensões, em diversos módulos, mais pequenos e simples, que serão, por sua vez, mais fáceis de gerir (Busbee and Braunschweig, 2018). Uma das vantagens de um sistema estar dividido em diversos módulos é podermos reduzir o tempo de desenvolvimento do mesmo e tornarmos mais rápida a evolução do sistema ao longo do tempo. A manutenção do sistema também fica mais facilitada. Um sistema baseado em módulos permite uma maior escalabilidade, pois as suas funcionalidades podem ser adicionadas gradualmente, sem afetar as já disponibilizadas. Inclusive, a integração de serviços, pode ser faseada, consoante as importâncias das mesmas, permitindo assim atingir a MVP (minimum viable product) mais rapidamente. A divisão de um sistema em módulos pode trazer muitas vantagens no processo de desenvolvimento e na estrutura final do sistema. Algumas dessas vantagens são: • Maior velocidade de desenvolvimento - ao se dividir o sistema em módulos mais pequenos e independentes, é possível ter vários grupos de programadores a trabalhar de forma paralela, o que aumenta a eficiência e reduzi o tempo de desenvolvimento. • Facilidade de manutenção – com o sistema dividido em módulos, torna-se mais fácil identificar e corrigir problemas em áreas específicas, sem afetar o funcionamento de outras partes do sistema. • Escalabilidade – torna-se mais fácil adicionar novas funcionalidades ou mesmo expandir o sistema, adicionando módulos adicionais, sem haver a necessidade de refazer todo o sistema. Sistemas de eLearning, Modularização e Integração 24 • MVP atingida mais rapidamente – com a modularização é possível entregar uma versão mínima viável (MVP) do sistema mais rapidamente, uma vez que é possível priorizar e entregar os módulos mais importantes primeiro, enquanto outros ficam a ser desenvolvidos em paralelo. • Reutilização de código – com o sistema dividido em módulos independentes, é possível reutilizar o código de um módulo num outro sistema qualquer, o que pode ser útil em situações nas quais é necessário desenvolver sistemas semelhantes. Isso pode garantir uma melhor escalabilidade para o sistema no futuro. Já foram apresentadas diversas razões para a utilização de módulos num sistema. Este tipo de abordagem no desenvolvimento de uma arquitetura de um sistema tem diversos exemplos práticos bastante bemsucedidos e, em muitos casos, mundialmente conhecidos. Alguns desses exemplos são: • Aplicações de mensagens – plataformas como o WhatsApp (“WhatsApp Business Platform”, n.d.) e o Telegram (“Telegram APIs”, n.d.) estão divididas em módulos que permitem aos seus utilizadores enviar mensagens, fazer chamadas de voz e vídeo, compartilhar arquivos e outras funcionalidades. Estas duas plataformas lidam com milhões de utilizadores a cada hora. São um bom exemplo para demonstrar a escalabilidade deste tipo de arquitetura. • Sistemas de gestão de conteúdo (CMS) – plataformas como o Drupal (“About | Drupal.org”, n.d.)e o Sitecore (“Sitecore Experience Platform (XP) - Powering Unforgettable Digital Experiences | Sitecore”, n.d.) são divididas em módulos que permitem aos seus utilizadores gerir e publicar conteúdo nos seus sites. Esses módulos incluem funcionalidades como gestão de utilizadores, criação e organização de conteúdo, personalização de design, otimização de SEO e integração de redes sociais. • Sistemas operativos – muitos sistemas operativos modernos, como o Windows e o Linux, estão divididos em módulos, que funcionam juntos para fornecer uma ampla gama de funcionalidades. Cada módulo é responsável por realizar tarefas específicas, como gestão de memória, gestão de arquivos e comunicação com hardware. Sistemas de eLearning, Modularização e Integração 25 2.3 Integração de Sistemas A integração de sistemas é definida na engenharia como um processo de juntar diversos subsistemas ou serviços, de forma a gerar um único sistema global, resultante da agregação dos subsistemas e da cooperação existente entre si. A integração de sistemas é algo bastante importante no mundo de hoje, sendo especialmente trabalhado em empresas que usam vários sistemas diferentes, como sistemas de gestão de relacionamento com o cliente (CRM), sistemas de gestão de stock (ERP) ou sistemas de gestão de vendas, entre outros. Existem diferentes maneiras de fazer a integração de sistemas de software, nomeadamente: • Integração baseada em APIs, uma opção de utilização frequente, que permite que os sistemas compartilhem informações através de interfaces de programação de aplicativos (APIs); isso permite que os sistemas comuniquem de forma mais direta e automatizada, mas requer que as APIs dos sistemas estejam disponíveis e que sejam compatíveis. • Integração baseada em arquivos, um tipo de integração que permite que os sistemas compartilhem informações através de arquivos, como folhas de cálculo e arquivos de texto; é uma das formas mais simples de integração, mas pode ser menos flexível e escalável do que outras opções. • Integração baseada em fluxo de trabalho, que permite que os sistemas compartilhem informações através de fluxos de trabalho automatizados; esta opção permite que os sistemas comuniquem entre si de forma mais direta e automatizada; porém requer que os fluxos de trabalho estejam configurados e os sistemas estejam conectados corretamente. • Integração baseada em middleware, uma opção que assenta numa camada de software intermediário que fornece a ligação entre os diferentes sistemas; o middleware pode fornecer serviços como roteamento, transformação de dados e gestão de mensagens, para ajudar a garantir que os sistemas se comuniquem corretamente. Após a decisão do tipo de integração a ser utilizada ser tomada e, de forma a garantir que alguém seja capaz de gerir a integração de serviços num sistema, existem, tipicamente, dois aspetos fundamentais a ter em consideração, nomeadamente, o aspeto técnico e o aspeto de gestão. O aspeto técnico envolve o conhecimento das tecnologias e do conhecimento especializado em cada um dos serviços a integrar, O Sistema Leonardo 32 • Realizar testes. Os testes, podem apenas ser realizados por alunos e, após o inicio de um teste, a hora de inicio do mesmo é enviada para a base de dados. Após isso, quando o tempo finaliza ou o aluno finaliza o teste, este é automaticamente sumbetido para a base de dados. • Consultar avaliações. Todos os membros do sistema podem consultar a secção das avaliações. Os alunos apenas podem ver as suas avaliações e os docentes podem ver as avaliações de todos os seus alunos. • Realizar quizzes. Os quizzes podem ser realizados apenas por alunos e a dificuldade dos quizzes varia consoante a capacidade que o aluno demontra nas perguntas a que vai respondendo. Caso um aluno apresente um bom registo, vão ser apresentadas perguntas mais complexas e, caso um aluno apresente um mau conhecimento do domínio, as perguntas apresentadas serão mais simples. • Login/Registo. Esta é uma funcionalidade geral para ambos os atores do sistema. Consiste na capacidade de efetuar um registo e, após a validação do mesmo, consiste na capacidade de realizar um login. Em relação ao registo, ao contrário do aluno, um professor já com acesso ao sistema, tem a capacidade de validar registos feitos por alunos. O Sistema Leonardo 33 Figura 3: Diagrama de Use Cases 3.2.1 Alunos Os alunos são o principal público-alvo do sistema Leonardo. Estes são o ator mais importante do sistema. As suas atividades no sistema estão essencialmente associadas com as tarefas e processos de aferição ou de avaliação de conhecimento, dos conteúdos de um ou mais cursos. Os alunos são o ator que possui o nível de permissões mais reduzido no sistema. Para obterem acesso ao sistema, os alunos devem-se registar de forma adequada. A partir desse registo o sistema cria-lhes uma conta, um perfil de acesso e utilização do sistema. Esse processo envolve fornecer todas as informações relevantes e obrigatórias, como nome, endereço de e-mail e informações de contato. Depois de preencher o formulário de registo, o aluno terá que aguardar a aprovação do seu pedido por parte O Sistema Leonardo 34 de um professor ou administrador do sistema. Após o pedido de registo for aceite, o aluno terá acesso à plataforma e usufruir dos seus serviços, podendo realizar testes e quizzes, ou consultar a informação que está disponível no sistema. Além disso, o aluno também poderá ver e analisar o seu progresso e desempenho no curso e aceder a recursos didáticos adicionais. Estes serviços, em particular, visam auxiliar os alunos a atingir os seus objetivos académicos. Quando comparado com os outros atores, o aluno é aquele que tem menos privilégios e, consequentemente, menos acesso a serviços do sistema. Na Figura 4, podemos ver um diagrama que ilustra os serviços e funcionalidades a que o aluno tem acesso. De modo a aceder ao sistema, um aluno deve registar-se. O registo deve ser validado por um professor e, só após esta validação é que um aluno irá ser capaz de fazer login. Após o acesso ao sistema, o aluno visualiza a Home Page do Leonardo. Lá, é capaz de consultar os domínios e subdomínios que lhe foram atribuídos. Pode também realizar testes que se encontrem disponíveis e realizar quizzes. Caso exista um teste válido e o aluno o realize, o aluno tem a permissão de consultar a sua avaliação. Figura 4: Os serviços e funcionalidades do ator aluno O Sistema Leonardo 35 Na Figura 5, podemos ver um screenshot do ambiente principal do sistema para um ator aluno, após a sua autenticação no sistema. Na parte superior da imagem vemos um cabeçalho com um botão que permite abrir ou esconder a tab lateral com todas as secções, vemos também três opções de linguagem e, por fim, vemos a imagem de perfil do utilizador, que é a zona onde o aluno pode alterar os seus dados. Do lado esquerdo da imagem vemos as várias opções de serviço a que um aluno tem acesso. O aluno pode carregar sobre as opções apresentadas e será direcionado para a página correspondente. Nas opções que apresentam uma seta, o aluno deve carregar na mesma e, após isso, serão então apresentadas as diversas opções correspondentes à secção onde o utilizador carregou. Figura 5: O ambiente principal do sistema 3.2.2 Professores Os professores são um ator importante no sistema Leonardo, pois são responsáveis por criar e gerir avaliações, acompanhar o progresso dos estudantes e avaliar o desempenho do curso. Para ajudá-los nessas tarefas, o sistema Leonardo fornece uma série de recursos e funcionalidades. Por exemplo, os professores podem importar alunos e questões em massa para o sistema, o que facilita a gestão de acessos e de questões. Além disso, o sistema fornece acessos a todos os professores para cada domínio, o que facilita a divisão de trabalho entre as equipes docentes. O sistema também disponibiliza aos professores um conjunto de serviços para que eles possam analisar e interpretar os resultados obtidos pelos alunos. Os resultados são O Sistema Leonardo 36 expostos através de gráficos e relatórios detalhados, que permitem aos professores avaliar o progresso dos estudantes, bem com identificar quais as áreas nas quais os alunos necessitam de mais apoio. Esses recursos ajudam a tornar o sistema Leonardo mais acessível e eficiente para os professores. Figura 6: Os serviços e funcionalidades do ator professor. De forma semelhante ao que fizemos para o ator aluno, na Figura 6: Os serviços e funcionalidades do ator professor., podemos ver os serviços a que o professor pode ter acesso. Após a devida autenticação, um professor pode então criar perfis para novos alunos, validar registos de utilizadores, consultar e criar domínios, subdomínios e questões, gerar testes e, por fim, consultar avaliações. O Sistema Leonardo 37 Figura 7: O ambiente principal do sistema Na Figura 7, podemos ver o ambiente principal do sistema configurado para o perfil de professor. Tal como para o perfil de aluno, o ambiente apresenta um cabeçalho com um botão que permite abrir ou esconder a tab lateral com todas as secções, três opções de linguagem e, por fim, a imagem de perfil do utilizador. 3.2.3 Administradores Os administradores do sistema são o ator mais importante do sistema Leonardo. Estes são os responsáveis pela gestão, pelo funcionamento regular do sistema e pela sua disponível e atualidade. Para ajudar os administradores a realizar essas tarefas, o sistema disponibiliza uma série de recursos e ferramentas específicas. Por exemplo, os administradores têm acesso a logs detalhados na base de dados do sistema, que podem ser usados para identificar e corrigir qualquer erro que possa surgir. Podem também aceder a todas as interfaces existentes na plataforma, o que lhes permite interagir diretamente com todas as funcionalidades do sistema. Além disso, ainda existem outros serviços (e recursos) específicos para os administradores do sistema, que permitem, entre outras coisas, criar novos utilizadores, gerir permissões de acesso ou controlar os conteúdos que estão disponíveis no sistema. Tudo isso ajuda a garantir que o sistema Leonardo funcione de maneira eficiente e atenda às necessidades dos seus diversos utilizadores, quer estes sejam alunos, professores ou administradores. O Sistema Leonardo 38 Figura 8: Os serviços e funcionalidades do ator administrador. Na Figura 8: Os serviços e funcionalidades do ator administrador., podemos ver um diagrama que ilustra os serviços e funcionalidades a que um administrador tem acesso. Tal como todos os outros utilizadores, os administradores só acedem ao sistema após se autenticarem. Todavia, têm credenciais específicas e, obviamente, podem fazer “tudo” no sistema. Vejamos o que significa este “tudo”. Depois de se autenticar, um aluno difere de um professor pois não pode criar testes, mas pode realizá-los. Um Administrador, no entanto, tem ambas as permissões. Um administrador pode também criar questões e realizar quizzes, sendo que a primeira destas funcionalidades não é permitida a alunos e a segunda não é permitida a professores. O Sistema Leonardo 39 3.3 Validação do sistema A validação de sistemas é um processo bastante criterioso e importante para o sucesso de qualquer produto ou componente de software. O processo de validação garante que um sistema atenda aos requisitos previamente definidos e consequentemente às necessidades dos seus utilizadores, garantindo que o sistema cumpra com as especificações técnicas inicialmente estipuladas. É, pois, um processo crucial, que deve ser realizado antes de o sistema ser colocado à disposição dos seus utilizadores. A validação de sistema serve para garantir a boa realização do trabalho dos programadores, como também para garantir que o seu trabalho acompanhou corretamente os trabalhos já desenvolvidos (Richards, Branstad, and Cherniavsky, 1981). O processo de validação do sistema Leonardo não foi completamente desenvolvido. Os motivos foram vários, estando associados, essencialmente, com o tipo de modelo de desenvolvimento adotado. Como referido anteriormente, o projeto do sistema foi realizado em diferentes períodos de tempo, por diferentes equipas de desenvolvimento, acompanhando as necessidade e etapas definidas por disciplinas específicas ou por dissertações de mestrado. Devido a isso, o sistema não foi, de facto, validade e algumas das funcionalidades idealizadas não foram implementadas. A não validação de todos os módulos desenvolvidos até ao momento e, consequentemente, do sistema, como um todo, não permitiram a integração de serviços necessária para a regular operacionalidade do sistema. Porém, os processos de validação foram iniciados e realizados na maioria dos módulos. Mas não a parte da sua integração no sistema. A validação de sistemas de software deve ser realizada através de testes de aceitação, de forma a garantir que o sistema atenda corretamente às necessidades dos seus utilizadores, em particular alunos e professores, e que garanta que o sistema cumpra as especificações técnicas definidas. Os testes devem ser projetados para simular as condições reais da utilização do sistema, incluindo diferentes cenários de utilizadores, entradas de dados e condições de operacionalidade. Porém, antes de se iniciarem os testes de aceitação, é importante definir claramente as especificações do sistema e as expectativas dos utilizadores. Isso inclui fazer a descrição das funcionalidades do sistema, os requisitos de desempenho, de segurança e de usabilidade, bem como as normas regulatórias aplicáveis. Após a realização dos testes de aceitação, é importante analisar os resultados obtidos e documentar eventuais problemas ou falhas detetadas. Todos os problemas que ocorram devem ser corrigidos antes de o sistema ser tornado público, obviamente. O Sistema Leonardo 40 A validação de sistemas é importante por diversas razões. Em primeiro lugar, garante que o sistema atenda às necessidades requisitadas, o que faz como que o sistema seja eficaz e eficiente. Além disso, a validação é importante para garantir a segurança e a privacidade dos utilizadores. Os testes de aceitação permitem identificar potenciais problemas de segurança e garantir que os requisitos de privacidade sejam atendidos. Finalmente, a validação é importante para garantir a conformidade regulatória. Os testes de aceitação permitem identificar se o sistema cumpre com as normas e regulamentações aplicáveis. Em suma, a validação de sistemas de software é uma etapa crucial no processo de desenvolvimento de software, nomeadamente para evitar possíveis problemas que possam gerar grandes prejuízos à organização e inclusive aos utilizadores. Os Módulos do Sistema Leonardo 41 4 Os Módulos do Sistema Leonardo O Sistema Leonardo é composto por diversos módulos que, na sua maioria, são independentes entre si. A integração desses módulos num único sistema apresentou vários desafios devido às diferentes tecnologias utilizadas no seu desenvolvimento, que, em alguns casos, não eram coincidentes. Assim, para fazer o desenvolvimento do sistema global da forma mais eficiente possível, foi necessário definir a ordem pela qual os diversos módulos seriam integrados. Essa ordem foi estabelecida após a integração do módulo com os serviços de autenticação, credenciação, registo e importação de utilizadores, que é considerado um dos componentes-chave do sistema. Após a integração deste módulo foi realizado um estudo detalhado dos restantes módulos e programas já desenvolvidos. Esse estudo revelou a existência de dependências entre os diversos programas a serem integrados. De acordo com essas dependências estabelecemos a ordem de integração pela qual os programas seriam integrados. A ordem estabelecida considerou a seguinte sequência de desenvolvimento e integração: 1. Gestão da Informação Base. Este módulo inclui os serviços de consulta e criação de domínios, subdomínios e questões. Este módulo foi o primeiro a ser integrado devido à não dependências de outros sistemas. 2. Gestão e Realização de Testes. Permite a criação de testes por parte de professores e administradores e a realização dos mesmos, por parte dos alunos. Sendo que um teste é composto por uma ou mais questões, este serviço é dependente do serviço de informação base. 3. Avaliação de Conhecimento. Após a criação e realização dos testes, este módulo foi integrado de modo a realizar e disponibilizar para consulta as avaliações dos testes. 4. Geração e Avaliação com Quizzes. Esta funcionalidade permite a realização e avaliação de quizzes e apenas tem dependência do módulo de informação base, no entanto, é um módulo que foi considerado menos relevante que os anteriores, pelo que, por isso, foi o último a ser integrado. 5. Suporte à Decisão - Data Warehousing. Deste serviço, foi apenas integrada a funcionalidade que permite avaliar estatísticas relativas a testes. Inicialmente, o sistema Leonardo foi concebido e desenvolvido para ser utilizado no Departamento de Informática da Universidade do Minho. Como tal, o sistema está hospedado numa máquina dedicada nos servidores do departamento, podendo ser acedido através do endereço http://leonardo2.di.uminho.pt ou http://192.168.85.198/, desde que se esteja dentro da rede da Universidade do Minho. Conforme iam sendo Os Módulos do Sistema Leonardo 48 Figura 14: Formulário para pedido de acesso ao sistema Qualquer pessoa que pretenda aceder ao sistema deve realizar um pedido de acesso a partir da página de autenticação do sistema. Os pedidos de acesso ao sistema são realizados num formulário específico (Figura 14) e registados na base do sistema para posterior análise e validação pelo administrador do sistema. O administrador, de modo a aceitar pedidos de acesso, tem acesso à secção de utilizadores, onde tem a subsecção de Pedidos de acesso. Após aceder a esta subsecção, o administrador ira então ver todos os pedidos de acesso que não se encontrem aprovados ou recusados (Figura 15). Os Módulos do Sistema Leonardo 49 Figura 15: Pedidos de Acesso 4.3 A Base de Dados do Sistema A base de dados do sistema é suportada pelo sistema de gestão de bases de dados MongoDB (Chadorow, 2013). O MongoDB é um sistema NoSQL de código aberto, que armazena os dados de forma estruturada em documentos no formato JSON. Foi desenvolvido com o objetivo de fornecer uma alternativa escalável e flexível aos sistemas de gestão de bases de dados relacionais tradicionais. Apesar da sua juventude, o MongoDB é atualmente um dos sistemas de gestão de bases de dados NoSQL mais populares na implementação e manutenção de document stores, sendo bastante utilizado, por exemplo, na implementação dos sistemas de dados para aplicações web. É um sistema fácil de usar, flexível, e capaz de lidar com grandes volumes de dados. Além disso, tem uma grande comunidade de programadores, que ao longo do tempo criaram e disponibilizaram uma grande variedade de recursos e ferramentas para apoio ao desenvolvimento de document stores. A escolha pelo sistema de gestão de bases de dados MongoDB deveu-se, essencialmente, às seguintes razões: • Facilidade de utilização. O MongoDB é conhecido por ser fácil de usar e de se integrar com outras aplicações e sistemas. Isso pode torná-lo uma opção atraente para um projeto como o Leonardo, que pode ter muitos módulos diferentes e pode precisar se integrar, no futuro, com outras aplicações. • Estruturas de dados flexíveis. Como um sistema NoSQL, o MongoDB oferece muita flexibilidade em relação à forma como os dados são armazenados e consultados. Isso pode ser útil num sistema Os Módulos do Sistema Leonardo 50 como o Leonardo, que pode ter muitos tipos diferentes de dados e pode precisar de uma solução de gerenciamento de base de dados que seja capaz de lidar com isso de forma eficiente. • Disponibilidade de recursos e suporte. A comunidade de desenvolvedores e a empresa por trás do MongoDB são muito ativas e oferecem uma ampla variedade de recursos e ferramentas para os usuários do sistema. Isso pode ser importante para um projeto como o Leonardo, que pode precisar de muito suporte e recursos para garantir a sua boa utilização. • Escalabilidade do sistema de dados. O MongoDB é conhecido por sua capacidade de lidar com grandes quantidades de dados de forma eficiente. Isso pode ser útil num sistema como o Leonardo, que pode precisar lidar com muitos utilizadores e muitos dados. O módulo que permite o acesso à base de dados do sistema está devidamente integrado com o seu serviço de back-end, bem como com os módulos de autenticação e registo, informação base, gerador e realizador de testes e, por fim, com o módulo de gestão e realização de quizzes. Todas as comunicações relativas ao acesso e manipulação de elemento da base de dados são realizadas através da biblioteca PyMongo (O’Higgins, 2011). Tal como usualmente acontece numa base de dados MongoDB, a base de dados do sistema é composta por diversas coleções (collections), que, na prática, são grupos de documentos JSON que estão juntos de acordo com algum tipo de critério. Na atual versão, a base de dados do sistema inclui as seguintes coleções: 1) activeUsers. Nesta coleção são guardados os documentos que contêm o último início de sessão de cada utilizador. Esta informação é bastante útil para a gestão quotidiana do sistema. Pode, por exemplo, ajudar os professores a verificarem se os seus alunos utilizaram (ou não) o sistema. Na Figura 16: Exemplo de um documento da coleção activeUsers., apresentamos um exemplo de um dos documentos desta coleção. Figura 16: Exemplo de um documento da coleção activeUsers. 2) documentation. Aqui são mantidos todos os documentos relativos ao sistema, como FAQ’s, documentos relativos a domínios, subdomínios, questões, testes e quizzes. Esta coleção tem como principal funcionalidade, o armazenamento de documentos e pequenas informações, relativas aos Os Módulos do Sistema Leonardo 51 mesmos, como o autor, a data de submissão e a descrição. Um exemplo de um dos documentos desta coleção pode ser observado na Figura 17: Exemplo de um documento da coleção documentation. Figura 17: Exemplo de um documento da coleção documentation. 3) domains. A informação relativa à identificação e caracterização de cada domínio de conhecimento do sistema é mantida nesta coleção. Os documentos JSON desta coleção contêm informação essencial para o funcionamento regular do sistema, uma vez que determinam a forma como o sistema deve atuar e caracterizar os processos de avaliação em cada um dos domínios. Na Figura 18, podemos ver um exemplo de um dos documentos desta coleção. Através de uma rápida análise, podemos identificar, por exemplo, a identificação, a descrição e o responsável pelo domínio que são elementos essenciais na caracterização do domínio Figura 18: Collection domains Os Módulos do Sistema Leonardo 52 4) Evaluation – Nesta coleção, são armazenadas todas as realizações de testes feitas pelos alunos do sistema. Como se pode verificar na Figura 19, esta coleção armazena um array de questões, que contêm as respostas dadas pelo aluno e, algo também bastante relevante que é armazenado neste JSON, é o campo “startTime”, que armazena a hora exata a que um aluno iniciou um teste. Este campo, garante que um aluno nunca pode exceder o tempo limite de um teste. Figura 19: Collection Evaluation 5) history –Esta coleção, serve para manter um histórico de interações do serviço front-end, com os serviços de back-end, garantindo assim um registo de logs que permite aos administradores do sistema uma maior facilidade de análise de problemas. No exemplo da Figura 20, o log armazenado representa uma visualização de uma imagem de perfil de um utilizador. Esta coleção ajuda também os administradores a melhor compreender o tráfego do sistema. Figura 20: Collection history 6) pageLogs – À semelhança da coleção de history, esta coleção, como o nome indica, é composta por logs do sistema, mais precisamente, logs de ações de utilizadores no sistema. Serve também para facilitar análises de problemas por parte dos administradores do sistema. Pode-se verificar na Figura 21, que o JSON armazenado contém informação bastante útil para a resolução de possíveis Os Módulos do Sistema Leonardo 53 problemas, como o utilizador que gerou o log, a data do log, qual a ação realizada e os detalhes da mesma. Figura 21: Collection pageLogs 7) question – Coleção responsável por armazenar todos os dados relativos às questões armazenadas em sistema. Os documentos JSON desta coleção contêm toda a informação necessária para caracterizar uma questão. Como se pode verificar na Figura 22, o JSON armazenado contém todos os campos relativos a uma questão, como o domínio, subdomínio, tempo de resposta. Dentro do único array existente no JSON, encontram-se as respostas e dados das respostas associadas à questão. Este array é composto apenas pelo texto da resposta, e dados de configuração da resposta, como os pontos a atribuir à mesma. Os Módulos do Sistema Leonardo 54 Figura 22: Collection question Figura 23: Array de respostas de uma questão 8) requests – Aqui, são armazenados todos os pedidos de criação de conta, até ao momento em que os mesmos são aprovados ou rejeitados. No exemplo apresentado na Figura 24: Collection , podemos validar que é armazenada toda a informação fornecida pelos utilizadores na página de registo e que, toda a informação é legível, com exceção da palavra-passe, que se encontra encriptada, de modo a que não possa ser vista por administradores do sistema. Os Módulos do Sistema Leonardo 55 Figura 24: Collection requests 9) Tests –Aqui armazenamos toda a informação relativa a um teste. Na Figura 25, podemos verificar que o JSON se encontra partido em dois objetos e um array, sendo que o array apresenta a informação das questões do teste e, os dois objetos apresentam informação de configurações do teste, como o tempo máximo de resolução, as datas de início e fim e visibilidade do teste. Os Módulos do Sistema Leonardo 56 Figura 25: Collection tests 10) users – A coleção de utilizadores, mantêm informações como nome, palavra-passe encriptada e universidade. Estas informações que podem ser validadas na Figura 26 e vão de encontro ao que se encontra armazenado na coleção de requests, pois as mesmas apresentam a mesma informação, sendo que um registo armazenado na coleção de requests, é posteriormente convertido num utilizador. Os Módulos do Sistema Leonardo 57 Figura 26: Collection users 4.4 O Gestor de Informação O gestor de informação do sistema é o módulo responsável por gerir todos os dados relativos ao funcionamento de um processo de avaliação de um dado domínio de conhecimento. Um domínio de conhecimento do sistema é algo equivalente a uma cadeira ou disciplina, que inclui na sua estrutura vários subdomínios, os tópicos de estudo da disciplina, e um conjunto diversificado de questões acerca da matéria desses subdomínios. Este módulo inclui um componente de serviços no sistema de front-end, que foi desenvolvido Vue.js, e um componente de serviços no sistema de back-end, contendo os programas para cada uma das suas funcionalidades e as estruturas de acesso aos dados da document store do sistema, que como foi referido, está suportada por um sistema MongoDB. Este é um módulo essencial para o funcionamento geral do sistema. Apenas os professores e os administradores podem utilizá-lo, para adicionarem, atualizarem ou removerem domínios, subdomínios ou questões. Os Módulos do Sistema Leonardo 64 De modo a dar suporte a uma questão, foi desenvolvida a aba de Suporte (Figura 34), onde definimos informação dedicada a auxiliar um a aluno na resolução de uma questão: - Foto, onde adicionamos uma foto que deverá ser apresentada junto do texto duma questão. - Vídeo, onde definimos um vídeo que deverá ser apresentada junto do texto duma questão. - Explicação, onde explicamos sucintamente a questão. Esta opção, aparece nos testes e quizzes e serve para auxiliar os alunos na resposta à questão. - Notas, onde detalhamos qualquer nota adicional relativa à questão. - Fontes, onde indicamos quais as fontes utilizadas na geração da questão. Figura 34: Especificação dos dados de suporte de uma questão Os Módulos do Sistema Leonardo 65 Após a inserção das questões relativas a um domínio, é possível fazer a sua edição (ou remoção) pelo responsável do domínio. No entanto, caso existam já testes com alguma das questões que tenha sido editada, estes poderão ficar desatualizados, uma vez que mantêm a versão anterior da questão. Os testes são objetos que guardam na sua estrutura todas as perguntas que o constituem. Optámos por armazenar as questões na estrutura do teste, de modo a minimizar os acessos realizados à base de dados e também para aumentar a segurança do sistema. Na secção seguinte descreveremos o processo de criação e edição dos testes de avaliação. 4.5 O Serviço de Criação de Testes O serviço de criação de testes de avaliação do sistema permite aos professores que estão associados com um dado domínio de conhecimento, fazer a criação de testes de avaliação especialmente orientados para a aferição do conhecimento dos alunos desse domínio, nos vários tópicos incluídos na matéria do domínio. Esta funcionalidade, é composta por um subprograma de front-end (integrado no front-end referenciado no ponto 4.1), um back-end dedicado a armazenar a informação dos testes e, finalmente, inclui um módulo de inteligência artificial, que, a partir das questões atualmente em sistema e das especificidades do teste em questão, vai gerar um teste, que respeite o tempo máximo de finalização definido pelo docente responsável pela criação do teste. Os testes são criados por professores, sendo que podem excecionalmente ser criados por administradores. A geração de um novo teste deve ser realizada a partir o gestor de testes (Figura 35), onde podemos consultar, atualizar ou remover qualquer teste em sistema. Figura 35: Gestor de Testes Os Módulos do Sistema Leonardo 66 O processo de criação de testes requer a existência de pelo menos um domínio com no mínimo, um subdomínio associado. Após a seleção do domínio e subdomínios do teste, é apresentado um formulário onde o docente deve configurar o teste (Figura 36). As configurações a ser definidas são: - Identificador, onde o identificador único do teste deve ser indicado. - Descrição, em que descrevemos sucintamente o teste e os seus objetivos. - Data de Inicio, onde selecionamos a data do primeiro dia onde o teste está disponível para resolução. Antes desta data, nenhum aluno tem visibilidade do teste na aba de realizar testes. - Data de fim, onde selecionamos a data-limite para a resolução de um teste. Após esta data, nenhum aluno tem visibilidade do teste na aba de realizar testes. - Número de Questões, em que indicamos ao gerador o número desejado de questões para o teste. - Nível de dificuldade, onde indicamos um valor entre um e cinco correspondente à dificuldade do teste. - Máximo de opções por questão, onde definimos o número máximo de opções de resposta que as questões devem ter. - Tempo de realização, em que definimos o tempo máximo que um aluno pode demorar para realizar um teste, após a sua inicialização. - Mostrar Respostas, no qual definimos se após a realização de um teste, as respostas corretas devem ser apresentadas ao aluno. - Tipo de teste, no qual selecionamos a opção de avaliação ou aferição. - Visibilidade, onde definimos se um teste deve ser tornado público quando dentro da sua data de resolução ou se deve manter-se privado independentemente da sua data de início e de fim. - Observações, em que definimos qualquer observação relevante ao teste. Os Módulos do Sistema Leonardo 67 Figura 36: Configurador de testes Os Módulos do Sistema Leonardo 68 Após o sistema gerar o teste, as configurações do mesmo são apresentadas no ecrã, de forma que possam ser validadas as configurações e para que as questões que foram automaticamente geradas possam ser verificadas. Neste ecrã (Figura 37), o criador do teste pode alterar as perguntas que achar necessário. Este módulo, apresenta um botão que permite ao professor pedir ao sistema que tente gerar novamente o teste, isto é, que (se possível) altere todas as questões, ou apenas as selecionadas. Figura 37: Ecrã de validação de testes Os Módulos do Sistema Leonardo 69 Neste ecrã, o teste pode ser submetido e, após a sua criação e caso o mesmo se encontre no seu período de resolução, o mesmo pode ser inicializado por um aluno na secção de avaliação (Figura 38). Figura 38: Menu de realização de testes O teste deve ser selecionado e, após isso, o aluno é direcionado para uma página onde deve validar a sua intenção de iniciar a resolução do teste e onde lhe são apresentadas as configurações do teste, como se pode verificar na Figura 39. Após o botão Iniciar ser pressionado, o teste começa e começa também a contar o tempo de resolução do mesmo. Figura 39: Resumo de teste Os Módulos do Sistema Leonardo 70 Um teste, como referido, tem um tempo de execução máximo e, aqui, surgiu uma das dificuldades da integração desta funcionalidade. Inicialmente, O sistema não só não guardava as tentativas realizadas por um utilizador, como permitia que cada aluno que realizasse um refresh na página, pudesse recomeçar o teste em questão, voltando a ter o tempo completo para a resolução do mesmo. De forma a solucionar o primeiro destes problemas, foi necessário criar um objeto na base de dados Mongo, representativo de uma tentativa de resolução de teste. Desta forma, cada aluno pode ter um registo deste objeto, por cada teste, permitindo desta forma, impedir que um aluno possa resolver um teste múltiplas vezes. Caso um aluno entre na página de resolução de testes após a entrega de um teste, ao clicar no mesmo, irá ser levado para a página onde é fornecida a nota que o aluno em questão conseguiu alcançar. Para resolver o segundo ponto, cada resolução de teste passou a ser inserida na base de dados aquando do início de cada teste, com uma data e hora de início. Desta forma, é possível finalizar um teste a um aluno quando o tempo termina e, para a situação em que o aluno faça refresh na página, ou mesmo caso um aluno se desconecte da plataforma, aquando da entrada no teste, o tempo de sobra será calculado a partir da hora de começo do mesmo, garantindo assim, que um aluno não sai do teste de forma a ter mais tempo para responder a uma questão. Para a garantir que em caso de desconexão de um aluno, aquando da realização de um teste, as respostas previamente escolhidas pelo aluno não são perdidas, sempre que um aluno avança de questão, todo o estado da tentativa de resolução é enviado para a base de dados. No decorrer de um teste (Figura 40), um aluno tem sempre a opção de voltar para a pergunta anterior ou de avançar para a pergunta seguinte. Em cada pergunta, são apresentados dois relógios, um representativo do tempo médio que o aluno deve demorar na pergunta em questão, e outro relógio representativo do tempo de sobra do teste em geral. Após o tempo do relógio chegar ao fim, o estado atual do teste irá ser submetido para o back-end e o aluno irá ser transportado para a página onde é apresentada a nota atingida pelo mesmo. Os Módulos do Sistema Leonardo 71 Figura 40: Resolução de teste Após o teste ser finalizado, é apresentado o resultado do mesmo ao aluno, indicando quantas questões foram apresentadas no teste e, das apresentadas, quantas foram respondidas corretamente, incorretamente, a taxa de acerto e, por fim, o resultado obtido numa escala de zero a vinte. É também disponibilizado o botão de sair e, quando aplicável, o botão de ver resolução (Figura 41). Os Módulos do Sistema Leonardo 72 Figura 41: Resultado de um teste A qualquer altura, um professor pode verificar as estatísticas relativas aos seus testes, seja por domínio, subdomínio ou aluno. Neste ecrã (Figura 42), quando um professor validar as estatísticas relativas a um domínio, poderá também validar quais os próximos testes relativos ao domínio selecionado. Um aluno, por sua vez, pode apenas validar as suas prestações em todas as suas avaliações, na aba de resultados, onde lhe são indicados os seus resultados (Figura 43). Os Módulos do Sistema Leonardo 73 Figura 42: Estatísticas de testes Figura 43: Menu de resultados de testes Caso o professor permita a visualização da resolução de um teste, é disponibilizado um botão, que permite aos alunos validar as perguntas do teste, com as opções erradas sublinhadas a vermelho, e as corretas, sublinhadas a verde. De forma a facilitar a alteração de visibilidade das respostas, na página geral dos testes, os professores dispõem de um botão que altera esta visibilidade para o oposto do estado onde se encontram, isto é, caso sejam visíveis, faz com que as mesmas deixem de o ser, e caso as respostas não estejam visíveis, faz com que as mesmas possam ser então consultadas pelos alunos (Figura 44). Comentário Final 80 5.2 Trabalho Futuro Apesar de grande parte dos módulos do sistema estar já a funcionar de modo integrado, é necessário realizar mais algum trabalho, não só em termos de integração como de desenvolvimento de serviços complementares. Vejamos algumas das tarefas que poderiam ser realizadas a curto ou a médio prazo por uma eventual nova equipa de integração: - é necessário incorporar na atual versão do sistema alguns módulos que já estão desenvolvidos, mas que não foram alvo de atenção nesta dissertação, nomeadamente o módulo de Análise de dados estatísticos. Outro módulo relevante que não se encontra integrado, é o módulo de chatbot, desenhado para interagir com os alunos. - Deve ser realizada uma documentação extensiva dos serviços e das interfaces implementadas no Leonardo. O sistema está atualmente sem qualquer tipo de documentação funcional de todos os seus módulos e API’s. - Integração de ferramentas de comunicação por email, de modo a que um aluno que seja aprovado receba essa informação ou que, um professor tenha a capacidade de mandar um email para todos os seus alunos a partir da plataforma. - Desenvolvimento de sistema de notificações para eventos relevantes, como testes, disponibilização de documentos ou novas perguntas nos quizzes. Para futuros trabalhos de integração, algumas recomendações e sugestões podem ser relevantes. Em primeiro lugar, é fundamental realizar uma análise detalhada dos requisitos de integração, identificando claramente as metas e funcionalidades desejadas. Além disso, estabelecer prazos realistas e gerir eficazmente os recursos disponíveis são aspetos críticos para o sucesso do projeto. A padronização de interfaces e protocolos de comunicação desde o início pode facilitar a integração e garantir uma maior interoperabilidade entre os serviços. Incentivar uma comunicação aberta e contínua entre as equipas deve também ser uma prática a adquirir. Por fim, é importante considerar a escalabilidade do sistema e a preparação para futuras expansões, pois isto é vital para garantir que a integração permaneça eficaz e funcional ao longo do tempo. Estas sugestões visam aprimorar os processos de integração e contribuir para resultados mais eficientes e bem-sucedidos em projetos futuros que visem integrar o Leonardo. Bibliografia 81 6 Bibliografia “About | Drupal.org.” n.d. Accessed May 27, 2023. https://www.drupal.org/about. Anton, K. 2013. “Integração do sistema: aspecto técnico.” March 12, 2013. Accessed October 17, 2021. https://www.kholodkov.ru/it/?p=630. Belo, O., J. Coelho, e L. Fernandes. 2019. “An Evolutionary Software Tool for Evaluating Students on Undergraduate Courses.” Seville, Spain. Busbee, K. L. 2013. “Programming Fundamentals-A Modular Structured Approach Using C++.” http://cnx.org/content/col10621/1.22/. Busbee, K. L., e D. Braunschweig. 2018. “Modular Programming.” Accessed October 12, 2022. Chadorow, K. 2013. “MongoDB The Definitive Guide” 2. Coulouris, G., J. Dollimore, T. Kindberg, e G. Blair. 2012. “Distributed Systems: Concepts and Design.” Fagerberg, J. 2019. “ASP.NET Core 2.2 MVC, Razor Pages, API, JSON Web Tokens HttpClient How to Build a Video Course Website (Jonas Fagerberg) (z-Lib.Org).” Kapp, K. M. 2012. “The Gamification of Learning and Instruction.” Kelhini, F. 2022. “Axios vs. fetch(): Which is best for making HTTP requests?” January 17, 2022. Accessed October 12, 2022. https://blog.logrocket.com/axios-vs-fetch-best-http-requests/. Kyriakidis, A., K. Maniatis, e E. You. 2016. “The Majesty of Vue.Js 2.” http://leanpub.com/vuejs2. Martin Fowler, by, K. Beck, J. Brant, W. Opdyke, e don Roberts. 1999. “Refactoring: Improving the Design of Existing Code.” Mason, R., e F. Rennie. 2006. Elearning: The Key Concepts . Elearning: The Key Concepts . London: Routledge. Accessed October 16, 2021. https://www.taylorfrancis.com/books/mono/10.4324/9780203099483/elearning-keyconcepts-robin-mason-frank-rennie. McGrath Caitlin. 2012. “What is Elearning? The Good, The Bad, The Ugly - Knowledge Direct.” Association ELearning Blog. 2012. Accessed October 16, 2021. https://www.kdplatform.com/elearning-good-bad-ugly/. Bibliografia 82 O’Higgins, N. 2011. “MongoDB and Python” 1 (January). Pereira, C. R. 2014. “Aplicações Web Real-Time Com Node.Js.” Rellermeyer, J. S., M. Duller, e G. Alonso. 2009. “Engineering the Cloud from Software Modules.” In Proceedings of the 2009 ICSE Workshop on Software Engineering Challenges of Cloud Computing, CLOUD 2009 , 32–37. https://doi.org/10.1109/CLOUD.2009.5071530. Richards, W., M. Branstad, e J. Cherniavsky. 1981. “Computer Science and Technology - Special Publication - Validation, Verification, and Testing of Computer Software.” “Sitecore Experience Platform (XP) - Powering Unforgettable Digital Experiences | Sitecore.” n.d. Accessed May 27, 2023. https://www.sitecore.com/products/sitecore-experience-platform. “Telegram APIs.” n.d. 2023. Accessed May 27, 2023. https://core.telegram.org/api. Tomczyk, Ł., K. Potyrała, A. Włoch, J. Wnęk-Gozdek, e N. Demeshkant. 2020. “Evaluation of the Functionality of a New E-Learning Platform vs. Previous Experiences in e-Learning and the Self-Assessment of Own Digital Literacy.” Sustainability (Switzerland) 12 (23): 1–22. https://doi.org/10.3390/su122310219. Vaisman, A., e E. Zimányi. 2014. “Data Warehouse Systems: Design and Implementation.” Data Warehouse Systems: Design and Implementation , January, 1–625. Accessed January 26, 2022. https://doi.org/10.1007/978-3-642-54655-6. Vulcano, G. 2019. “Integration Evolution: from point-to-point to ESB - GreenVulcano.” July 29, 2019. Accessed October 17, 2021. https://www.greenvulcano.com/integration-evolutionfrom-point-to-point-integration-toesb/?doing_wp_cron=1634487213.3792030811309814453125. “WhatsApp Business Platform.” n.d. 2023. Accessed May 27, 2023. https://developers.facebook.com/docs/whatsapp. Wright, G. 2022. “What is a module in software, hardware and programming?” 2022. Accessed October 12, 2022. https://www.techtarget.com/whatis/definition/module. Yadav, D., A. R. Salman, M. Goyal, e A. Choubey. 2012. “E-Learning: Current State of Art and Future Prospects Related Papers T He Use of Int Elligent Tut Oring Syst Em for Developing Web-Based Learning Communit Ies E-Learning: Current State of Art and Future Prospects.” www.IJCSI.org.