Raccode: Um Plugin de
Avaliação Automática
de Programas para o
Eclipse
André Filipe Monteiro da Silva
Mestrado Integrado: Engenharia de Redes e Sistemas Informáticos
Departamento de Ciência de Computadores2018
Orientador
José Paulo de Vilhena Geraldes Leal, Professor Auxiliar, Faculdade de Ciências da Universidade do Porto
Todas as correções determinadas pelo júri, e só essas, foram efetuadas.
O Presidente do Júri,
Abstract
The goal of this dissertation is the automatic evaluation of computer programs in the context of an Integrated Development Environment (IDE).
The project described in this dissertation consists of the development of an Eclipse plugin, henceforth referred to as Raccode. The core idea of Raccode is to extract maximum value from the features already existing on Eclipse and build a pedagogical environment where its users can learn and practice programming languages, all while relishing from Mooshak’s 2.0 automatic program assessment. Raccode presents the user with a perspective based interface which groups all commonly used features and required operational resources. Some features were directly imported from Eclipse, while others were implemented. As mentioned the resources for the automatic assessment of programs is accomplished by Mooshak, via Application Programming Interface (API) based connections. It is the responsibility of Raccode to perform these connections and handle the retrieved data for direct integration with Eclipse.
In this dissertation, the technical implementation details of Raccode are described, including detailed schemas of its architecture, development hurdles and how they were solved. Further along, it is also described the validation of Raccode, where it was subjected to user tests, where the users possess various levels of experience in programming and IDE use.
Resumo
O objetivo desta dissertação é a avaliação automática de programas no contexto de um ambiente integrado de desenvolvimento (IDE).
O projeto descrito nesta dissertação consistiu na criação de um plugin para o Eclipse, a que demos o nome de Raccode. A ideia principal do Raccode é tirar o máximo partido das funcionalidades de um Ambiente de Desenvolvimento Integrado (IDE) e construir um ambiente pedagógico onde os seus utilizadores podem aprender e praticar linguagens de programação, usufruindo de um sistema de avaliação automática de programas, o Mooshak 2.0. É apresentada uma Interface com o utilizador que se baseia numa perspetiva que reúne todas ferramentas e recursos necessários para o funcionamento deste ambiente. Algumas dessas ferramentas são obtidas diretamente do Eclipse, enquanto outras tiveram de ser implementadas. Os recursos para a avaliação automática de programas são provenientes do Mooshak, sendo as comunicações feitas com base na Application Programming Interface (API) do Mooshak. É da responsabilidade do Raccode realizar estas comunicações e tratar dos dados obtidos para as integrar no Eclipse.
Nesta dissertação é também detalhada a implementação do Raccode, onde está incluído a sua arquitetura, os problemas encontrados durante o seu desenvolvimento e como esses problemas foram resolvidos. Para além disso, é ainda descrita a validação do Raccode, onde este foi submetido a testes de grupos de pessoas com diferentes níveis de experiência em programação e na utilização deIDEs.
Agradecimentos
Durante este ano de trabalho, dificuldades e contratempos foram surgindo, mas felizmente pude contar com a ajuda e o apoio de pessoas que sempre se mostraram disponíveis e estiveram ao meu lado.
Gostaria por começar por agradecer ao meu orientador, o Prof. José Paulo Leal, pela partilha da sua ampla experiência de vida e pela persistência em me fazer melhorar e ultrapassar as minhas limitações, tanto a nível académico como pessoal. Um agradecimento especial também ao José Carlos Paiva, que se mostrou sempre disponível a ajudar e essa ajuda foi vital para a conclusão deste projeto.
Aos colegas e amigos que fui conhecendo ao longo destes anos de curso, pela ajuda, pelo ambiente de trabalho e pelos momentos de lazer. Todos eles foram importantes para o sucesso desta minha fase de vida, pelo que me resta agradecer a essas pessoas.
Por último, mas não menos importante (muito pelo contrário), quero agradecer à minha família, em especial aos meus pais e ao meu irmão, que sempre me apoiaram e lutaram para que eu conseguisse concluir esta etapa com sucesso, não só este ano, mas durante todo o percurso universitário.
Conteúdo
Abstract i Resumo iii Agradecimentos v Conteúdo ix Lista de Tabelas xiLista de Figuras xiv
Acrónimos xv 1 Introdução 1 1.1 Motivação . . . 1 1.2 Objetivos . . . 2 1.3 Abordagem . . . 3 1.4 Organização . . . 4 2 Estado da Arte 7 2.1 Ferramentas . . . 7 2.1.1 Mooshak . . . 7
2.1.2 Plugin Development Environment . . . 8
2.1.3 Rich Client Platform . . . 9
2.1.4 Representational State Transfer . . . 10 2.2 Trabalhos Relacionados . . . 13 2.2.1 IDEs online . . . 13 2.3 Resumo . . . 14 3 Raccode 15 3.1 Interface Gráfica . . . 15 3.1.1 Perspetiva . . . 16 3.1.2 Preferências . . . 16 3.1.3 Barra de Menus. . . 17 3.1.4 NewProblemWizard . . . 18 3.1.5 Classificações . . . 18 3.1.6 Perguntas e Respostas . . . 19 3.1.7 Submissão. . . 21 3.2 Arquitetura . . . 22
3.2.1 Raccode como plugin do Eclipse . . . 22
3.2.2 API REST do Mooshak 2.0 . . . 24
3.3 Desenho . . . 25
3.3.1 Back-end package. . . 25
3.3.2 Front-end package . . . 29
3.4 Desenvolvimento . . . 33
3.4.1 Escolha do Ambiente de Desenvolvimento Integrado (IDE) . . . 33
3.4.2 Implementação . . . 34 3.5 Resumo . . . 36 4 Validação 37 4.1 Experiências e Testes . . . 37 4.2 Síntese de resultados . . . 38 4.3 Análise Detalhada . . . 41 viii
4.4 Resumo . . . 43
5 Conclusões 45
5.1 Trabalho Realizado . . . 45
5.2 Trabalho Futuro . . . 46
A Guião de testes ao Raccode 49
B Questionário utilizado na validação 51
C Gráficos das respostas do questionário utilizado na validação 63
Bibliografia 83
Lista de Tabelas
2.1 Caraterísticas de alguns dos mais utilizados software online de aprendizagem. . . 14
3.1 Principais endpoints da API REST do Mooshak . . . 25
Lista de Figuras
1.1 Sugestão de perspetiva para o Raccode. . . 3
2.1 Componentes que constituem o RCP. . . 9
3.1 Perspetiva do Raccode . . . 16
3.2 Configuração das preferências do Raccode . . . 17
3.3 Barra de menus . . . 18
3.4 Wizard para autenticação e seleção de problema e linguagem . . . 18
3.5 Classificações . . . 19
3.6 Janela para criar e submeter uma questão . . . 20
3.7 Janela com informação de todas as perguntas submetidas . . . 20
3.8 Janela com informação das perguntas submetidas pelo utilizador/equipa . . . 21
3.9 Janela com o feedback . . . 21
3.10 Diagrama de sequência das funcionalidades do Raccode . . . 23
3.11 Diagrama de pacotes do Raccode . . . 26
3.12 Diagrama de classes do pacote requests . . . 27
3.13 Diagrama de classes do pacote ui . . . 29
3.14 Diagrama de classes da relação Activator com ServerConnection . . . 30
3.15 Ranking IDEs (agosto 2018). Adaptado de [4]. . . 34
4.1 Experiência com linguagens de programação . . . 38
4.2 Experiência com IDEs . . . 39
4.3 Pontos do guião realizados pelos participantes . . . 39
4.4 Avaliação de satisfação da usabilidade do Raccode . . . 40
4.5 Classificação dada pelos participantes ao Raccode. . . 40
4.6 Obtenção de feedback durante a realização de tarefas em background . . . 41
4.7 Permanência da localização e tamanho dos botões e janelas . . . 42
4.8 Problemas de encoding de caracteres especiais . . . 42
4.9 Possibilidade de desativar/ativar janelas . . . 43
4.10 Compreensão do feedback por parte dos utilizadores . . . 43
Acrónimos
MI:ERSI Mestrado Integrado em Engenharia de Redes e Sistemas Informáticos CC Ciência de Computadores
M:CC Mestrado em Ciência de Computadores
DCC Departamento de Ciência de Computadores
FCUP Faculdade de Ciências da Universidade do Porto HTTP Hypertext Transfer Protocol
HTTPS Hypertext Transfer Protocol Secure IDE Ambiente de Desenvolvimento
Integrado
GUI Graphical User Interface UI User Interface
MPC Marketplace Client
PDE Plug-in Development Environment API Application Programming Interface REST Representational State Transfer
JSON JavaScript Object Notation JVM Java Virtual Machine URL Uniform Resource Locator URI Uniform Resource Identifier AWT Abstract Widget Toolkit SWT Standard Widget Toolkit JNI Java Native Interface
OSGi (Open Services Gateway Initiative RCP Rich Client Platform
Q&A Perguntas e Respostas PDF Portable Document Format HTML HyperText Markup Language XML Extensible Markup Language JWT JSON Web Tokens
JAXB Java Architecture for XML Binding HATEOAS Hypermedia as the Engine of
Application State
UML Unified Modeling Language
Capítulo 1
Introdução
O crescimento da tecnologia da informática e a popularização da Internet fez com que o comportamento dos cidadãos mudasse consideravelmente. A criação dos computadores pessoais veio alargar o leque de oportunidades de mercado, tornando-se imprescindível no quotidiano das pessoas, seja a nível profissional, académico ou entretenimento. Por isso, a aposta no desenvolvimento de software tem vindo a aumentar e existem cada vez mais programas e aplicações no mercado para irem ao encontro com as necessidades e exigências dos utilizadores, e como tal, tem havido uma evolução nas ferramentas para o seu desenvolvimento. Os IDEs (Integrated Development Environment) são um exemplo desse tipo de software que disponibilizam várias ferramentas que auxiliam no trabalho dos programadores e permitem criar software para diferentes finalidades.
1.1
Motivação
Seja a nível escolar ou empresarial, a utilização de ambientes de desenvolvimento de software por parte dos programadores, como os Ambientes de Desenvolvimento Integrado (IDEs), tem vindo a aumentar significativamente[10]. Estes ambientes permitem o desenvolvimento e a integração de ferramentas (plugins e wizards) que, quando bem desenhadas, vêm simplificar as tarefas do utilizador e melhorar a produtividade. Os wizards, por exemplo, tornam tarefas repetitivas, como criar uma classe em Java, numa única tarefa que consiste em preencher os campos necessários de forma a obter a informação suficiente para gerar um código esqueleto, incluindo declarações aos pacotes, construtores, métodos herdados, etc. Já um plugin é uma extensão, um componente que é possível integrar num IDE, oferecendo-lhe mais funções e recursos. No Eclipse existe o modo perspetiva, que define quais e como surgem na Workbench as janelas (views) que lhe estão associadas.
Um outro ponto é a presença forte da Internet no quotidiano das pessoas, que disponibiliza inúmeras ferramentas capazes de corresponderem aos objetivos dos utilizadores. Existem muitos ambientes para resolução de problemas de programação (alguns exemplos no Capítulo2), mas
2 Capítulo 1. Introdução
não existe nenhum desses ambientes integrados em IDEs. Seria útil ao programador fazer a utilização destes serviços num ambiente que lhe é familiar e que utiliza diariamente, ou pelo simples facto de servir como método de aprendizagem, tanto para uma linguagem de programação (ao resolver os problemas) como para o IDE escolhido (através da sua utilização).
1.2
Objetivos
O Eclipse contém várias ferramentas que permitem ao utilizador desenvolver software de forma mais organizada e fácil, sendo os mais importantes o Editor de Texto, o Debugger, o Terminal e o Package Eexplorer. Quanto a sistemas de aprendizagem, como são os sistemas de avaliação automática de programas para resolução de problemas, existem apenas em modo online. As suas principais caraterísticas são a submissão de soluções de problemas de programação, a possibilidade de interação com outros utilizadores através do canal de perguntas e respostas (Q&A) e ainda classificações para cada concurso.
Temos como objetivo usufruir das ferramentas que constituem o Eclipse e integrar as caraterísticas de um sistema de avaliação automática de programas para resolução de problemas de programação, de forma a criar um ambiente de aprendizagem e competitivo num IDE.
Este novo ambiente de aprendizagem combina tanto as principais caraterísticas que definem os ambientes de desenvolvimento como as principais caraterísticas que definem os ambientes de aprendizagem. Assim, as suas principais funcionalidades serão:
• Edição, testes e debugging de programas: que são obtidas diretamente do Eclipse, pois já estão implementadas, e são as principais funcionalidades do que torna um IDE um bom ambiente de desenvolvimento de software;
• Rankings: uma das funcionalidades dos sistemas de aprendizagem que permite aos participantes seguirem a sua classificação em modo competitivo (e não só);
• Submissão de programas: permite ao participante submeter a sua solução para um determinado problema e obter feedback consoante o resultado;
• Aquisição de enunciados: permite aos participantes verem os enunciados dos problemas para implementarem a sua solução;
• Q&A: interação entre participantes como forma de apoio à resolução dos problemas, em que é possível um participante de um determinado concurso colocar uma questão sobre um determinado problema e obter respostas que o ajudem a chegar a uma solução.
São estas as funcionalidades que este ambiente deve abranger, do qual resultará um sistema de aprendizagem bastante completo num dosIDEs mais utilizados para o melhor proveito dos seus utilizadores.
1.3. Abordagem 3
1.3
Abordagem
Com base nestes objetivos, a primeira abordagem considerada foi a criação de um plugin para o Eclipse, a que se chamou Raccode.
Figura 1.1: Sugestão de perspetiva para o Raccode.
A figura 1.1 ilustra o aspeto planeado para o Raccode, no formato de perspetiva, onde as janelas se encontram organizadas de maneira a que o utilizador tenha tudo o que precisa em primeiro plano para o melhor aproveitamento das suas várias funcionalidades. Passemos à descrição de todas as funcionalidades do Raccode, mesmos as que não são visíveis na Figura 1.1:
• Preferências: na página nas preferências do Eclipse associada ao plugin estão os campos necessários para a configuração aos servidores do repositório de problemas e motor de avaliação;
• Autenticação: através de um Wizard, o utilizador pode fazer login num dos concursos disponíveis;
• Menu de problemas: logo após a autenticação, ainda dentro do mesmo Wizard, são apresentados os vários problemas que aquele concurso dispõe, entre outros possíveis campos e/ou opções;
• Package Explorer: mostra todos os projetos em que o utilizador está envolvido, sendo cada projeto relativo a um problema. Na Figura 1.1, essa janela encontra-se no lado esquerdo da perspetiva. Uma funcionalidade interessante desta componente é juntar todos os projetos do mesmo concurso na mesma pasta, de maneira a que seja possível colapsar os concursos em que o utilizador não esteja a trabalhar, o que melhora a sua organização e a experiência de navegação entre projetos;
4 Capítulo 1. Introdução
• Enunciado: janela do topo e centro da perspetiva, onde é ilustrado o enunciado do problema selecionado;
• Editor de Texto: janela com o editor de texto para o utilizador implementar a sua solução;
• Terminal/Casos de Teste/Debugger: esta janela (em baixo e no centro da perspetiva) conta com três tabs, uma com o terminal para a compilação e execução manual do programa e de testes, outra com os casos dos teste (obtidos do servidor ou criados pelo utilizador), e o último para executar e obter feedback do Debugger ;
• Classificações: para o concurso selecionado, mostra as classificações para todos os problemas, bem como as estatísticas pessoais do utilizador nos vários problemas em que participou (número de submissões, respostas de avaliação, entre outros);
• Q&A: possibilita colocar questões sobre um problema para que outros utilizadores apresentem as suas soluções. Isto cria um ambiente de aprendizagem mais interativo entre os utilizadores do Raccode;
• Toolbar: a toolbar é a do próprio Eclipse (não fazendo parte da perspetiva), onde é adicionado um botão para a submissão do programa para avaliação. Depois de avaliado é apresentado o feedback numa janela pop-up.
É esta a nossa abordagem que acreditamos ser a melhor para satisfazer todos os requisitos que são propostos. Todos os ficheiros (enunciado, ficheiros associados ao projeto, casos de teste, etc) são descarregados e mantidos localmente no próprio workspace do projeto, para que o utilizador possa trabalhar offline.
1.4
Organização
Esta dissertação está organizada em cinco capítulos, estruturadas da seguinte forma: a Intro-dução, o capítulo introdutório desta tese, onde são apresentados a motivação deste projeto, os objetivos delineados para este projeto, a nossa abordagem que satisfaz a proposta do projeto e a estrutura desta dissertação; o Estado da Arte, onde são descritas as ferramentas utilizadas no desenvolvimento da nossa solução, sendo eles o Mooshak, cuja última versão é integrante neste projeto, servindo de servidor com repositórios de problemas e motor de avaliação; o Plug-in Development Environment (PDE), um ambiente que reúne um conjunto de ferramentas que assistem no desenvolvimento de plugins; o Rich Client Platform (RCP), uma framework para criação de plugins; e o Representational State Transfer (REST), modelo usado no desenvolvimento da Application Programming Interface (API) do Mooshak 2.0. Este capítulo conta ainda com a exposição de alguns trabalhos relacionados com o nosso projeto, onde estão indicados alguns exemplos de IDEs online e suas caraterísticas; no terceiro capítulo é apresentada a nossa solução, o Raccode, onde é descrito a arquitetura de uma forma mais abstrata, como este se integra
1.4. Organização 5 com o Eclipse e o Mooshak e as suas funções nesta rede e uma representação dos métodos mais importantes que constituem aAPI RESTdo Mooshak 2.0; o desenho do Raccode, onde é descrito com algum detalhe a parte prática da implementação do Raccode, como as suas classes; e o desenvolvimento do Raccode, onde é abordado o motivo da escolha do IDE e são indicados alguns problemas encontrados durante a implementação do plugin; o Capítulo 4 (Testes e Resultados) são abordados os testes feitos ao Raccode que envolveram grupos de pessoas com diferentes níveis de experiência, quer a nível de programação, quer a nível de interação com um
IDE, os resultados desses testes e a respetiva análise; e por último, no Capítulo 5 estão algumas conclusões e observações finais sobre o trabalho realizado no desenvolvimento do Raccode, as principais contribuições resultantes e também algumas sugestões de trabalho futuro que promove o aperfeiçoamento do Raccode.
Capítulo 2
Estado da Arte
O Eclipse, bem como grande parte dos IDEs, pode ser estendido através de ferramentas, denominadas de plugins, que ajudam na construção e desenvolvimento de software. Algumas dessas ferramentas servem também de base para o desenvolvimento de outras ferramentas que se integram no ambiente do Eclipse. Em particular, o Eclipse inclui o Plug-in Development Environment (PDE) que permite fazer esse tipo de desenvolvimento de ferramentas[3], enquanto que o Rich Client Platform (RCP) providencia uma framework que facilita integrar componentes independentes de software, o que permite ao programador não ter que desenvolver uma aplicação do zero[16][11].
2.1
Ferramentas
Nesta secção serão descritas ferramentas que servirão de apoio para o desenvolvimento deste projeto, todos do ponto de vista do Eclipse, tais como o PDE, como foi referido anteriormente, o
RCP, uma framework para a parte da User Interface (UI)[16], o Representational State Transfer (Representational State Transfer (REST)), que será utilizado nas comunicações cliente-servidor, e o (Open Services Gateway Initiative (OSGi), uma framework que define, compõe e executa componentes e bundles. Por estar diretamente ligado a este projeto, é também apresentado o Mooshak, um sistema online de avaliação de programas.
2.1.1 Mooshak
O Mooshak é um sistema web based desenvolvido por José Paulo Leal e Fernando Silva[12] que permite gerir concursos de programação de diferentes tamanhos. Ou seja, pequenos concursos utilizado apenas um servidor ou grandes concursos distribuídos por várias localizações geográficas. Este software avalia automaticamente os programas submetidos pelos concorrentes comparando os resultados obtidos com os resultados esperados no respetivo problema. O Mooshak tem sido
8 Capítulo 2. Estado da Arte
utilizado para várias provas de programação, patrocinadas atualmente pela ACM-ICPC1), como o SWERC2, e concursos inter-universitários, como o MIUP e o TIUP. Devido à sua capacidade de avaliação automática, atualmente é também utilizado em cursos de programação como forma de apoio aos docentes nas aulas, em que dá feedback instantâneo aos alunos e permite a avaliação de entregas de trabalhos práticos, por exemplo.
O Mooshak pode comunicar com dois tipos de componentes externos: repositórios de problemas e motores de avaliação. No repositório de problemas estão armazenados todos os problemas disponíveis para serem resolvidos. Os motores de avaliação contêm casos de teste que permite verificar se a solução apresentada está correta ou não. Estes casos de teste contêm o output esperado, cujo formato é descrito no enunciado do problema e o output obtido pelo programa do concorrente deverá ser exatamente igual para que seja aceite.
Mais recentemente foi desenvolvido o Mooshak 2.03, que tem os mesmos objetivos, mas ao qual foram adicionadas novas funcionalidades. Entre as principais destaca-se um avaliador de diagramas (Kora[7]) e um novo ambiente de aprendizagem (Enki[19]). A versão 2.0 utiliza um novo modelo de comunicação servidor-cliente (substituindo Apache HTTP server e TCL script pelo REST Application Programming Interface (API)[19]), entre muitas outras funcionalidades.
2.1.2 Plugin Development Environment
O PDE é um ambiente com um conjunto de ferramentas que assistem no desenvolvimento de plugins, desde a criação, desenvolvimento, testes, debug, build e deploy. Este ambiente está completamente integrado no Eclipse, ou seja, o PDE incorpora a filosofia de integração de componentes do Eclipse e ele próprio integra-se na workbench fornecendo contribuições à plataforma, como editores, wizards, vistas e um launcher que os utilizadores podem aceder de forma fácil e sem interromper o seu trabalho. Isso, como tudo, tem vantagens e desvantagens. A grande vantagem passa pelo utilizador trabalhar no Eclipse da mesma forma que trabalha para outros projetos. Outra grande vantagem é a facilidade em que, após o seu desenvolvimento, o plugin é publicado no mercado. Em contra partida, a maior desvantagem é ser ‘exclusivo’ do Eclipse, sendo o deploy feito somente no market do Eclipse. Exclusivo aqui está entre aspas porque pensa-se (de uma forma muito pessoal e estudada) ser possível reaproveitar código de forma a integrar no desenvolvimento de plugins para outros IDEs. As componentes que serão apresentadas na Secção 2.1.3 são algumas ferramentas que o PDE disponibiliza e que serão utilizadas na construção do nosso plugin[17].
1
icpc.baylor.edu 2
swerc.up.pt
2.1. Ferramentas 9
2.1.3 Rich Client Platform
Um programador quando desenvolve um software, quer minimizar o seu trabalho e concluir as tarefas o mais rapidamente possível. Desenvolver uma aplicação a partir do zero (from scratch) vai contra esse desejo, porque há muitas tarefas iniciais que são comuns para o desenvolvimento de qualquer software, como criar um projeto Java com a classe principal, método contrutor, etc. Ao trabalhar com IDEs, nomeadamente o Eclipse, existe a possibilidade de utilizar várias ferramentas, desenvolvidas por outros programadores, que vem otimizar o trabalho dos restantes utilizadores.
O Eclipse Rich Client Platform (Eclipse RCP, ou só RCP, numa forma mais genérica), permite ao programador perder o menor tempo possível na fase de criação de um projeto e focar-se mais no seu desenvolvimento. Oficialmente, o RCPsurgiu na versão 3.0 do Eclipse e contém vários componentes, tais como um microkernel, um widget toolkit, editores de texto, workbenchs — perspetivas, vistas, wizards, etc —, uma bundling framework, entre outros. De uma forma sucinta, uma aplicação RCPé uma coleção de plugins e um Runtime, no qual eles são executados. Alguns plugins em específico são a base das aplicações RCP: OSGi, Standard Widget Toolkit (SWT), Runtime, JFace e UI Workbench, divididas em três camadas, como ilustra a figura 2.1.
Figura 2.1: Componentes que constituem o RCP. Source: http://ptgmedia.pearsoncmg.com/images/ chap2_0321334612/elementLinks/02fig02.jpg [Acces-sed: 2018-01-11]
10 Capítulo 2. Estado da Arte
conjunto de especificações definindo um sistema dinâmico de componentes para a plataforma Java[1]. De forma resumida, no desenvolvimento de um plugin RCP, é criado um ficheiro de configuração chamado MANIFEST.MF. Neste ficheiro encontram-se informações sobre o plugin, sendo as configurações standard o seu ID, nome, versão, classe e dependências (utilização de outros plugins).
• SWT: SWT é a biblioteca de componentes padrão da UI. É uma biblioteca gráfica de baixo nível que fornece controlo da Graphical User Interface (GUI), que permite criar componentes gráficos tais como listas, menus, tipos de letras e cores. A implementação
SWTfaz uso das bibliotecas nativas GUI do sistema operativo utilizando o Java Native Interface (JNI). Isso permite que os programas que a utilizem tenham maior portabilidade entre sistemas operativos.
• Runtime: No início, o Eclipse Runtime incluía o modelo do plugin, mas entretanto, esse modelo desceu para a camada do OSGi. Assim sendo, o Runtime está na camada acima e contém alguns mecanismos importantes, como o modelo da aplicação e o registo de extensões. O Runtime corre uma aplicação definida, isto é, simula como a aplicação desenvolvida é executada. As aplicações são definidas usando extensões, e essas extensões identificam uma classe para ser usada como ponto de entrada (main entry point). Especificada a aplicação a executar, ficará totalmente sob controlo do Eclipse. Quando a aplicação terminar o Eclipse também é encerrado.
• JFace: Fornece algumas APIs gráficas desenvolvidas sobre o SWT. É uma toolkit da interface do utilizador (UI) com classes para manipular tarefas comuns na programação da UI. É desenhada para funcionar em conjunto com o SWT. JFace contém várias componentes, desde frameworks para preferências, wizards, imagens, janelas, ações, vistas, entre outros. Todas estas estruturas formam a base daUI do Eclipse.
• User Interface Workbench (UI Workbench): A Workbench adiciona apresentação e coordenação à JFace. Segundo a descrição geral e sucinta das funcionalidades da Workbench, feita por Jeff McAffer e Jean-Michel Lemieux[16], ela fornece pontos de extensão que permitem aos plugins definir esses elementos doUI de forma declarativa; permite também que os utilizadores personalizem o visual da aplicação que estão a desenvolver, posicionando as várias janelas da maneira pretendida.
Todas estas funcionalidades tornam o EclipseRCPbastante utilizado nos dias de hoje. A NASA, a Adobe e a IBM são exemplos de empresas que utilizam componentes RCP, seja no controlo de versões dos seus produtos, ou no armazenamento de imagens de missões espaciais feitas pela NASA[16][11][22].
2.1.4 Representational State Transfer
Roy Fielding, um dos principais autores do protocolo HTTP, co-fundador da Apache Software Foundation (ASF), é o criador da Representational State Transfer (REST). Na sua teste
2.1. Ferramentas 11 de doutoramento em 2000[9] descreve o REST como um modelo com restrições arquiteturais aplicadas a componentes, conectores e de dados num sistema de hipermédia distribuído. A Web é o principal sistema que usa o modelo REST, como é por exemplo o caso da Google, que foi dos primeiros serviços Web a seguir os padrões REST(o Google Maps é totalmente construído com base no princípio REST). Essa arquitetura descreve seis restrições[9][8][20]:
• Client-Server: Citando Gregory R. Andrews[2], “Um cliente é um processo desencadeador; um servidor é um processo reativo.”. Ou seja, os clientes fazem pedidos (HTTP) aos servidores que, por sua vez, reagem a esses pedidos. Os clientes não necessitam estar continuamente ligados aos servidores, ao contrário dos servidores que ficam à espera que chegue algum pedido proveniente de um cliente. O servidor pode fornecer serviços para mais que um cliente. A separação de responsabilidades é o princípio por trás das restrições cliente-servidor. Esta divisão permite que haja uma melhoria na portabilidade da interface em várias plataformas (do lado do cliente) e na escalabilidade, por simplificar os componentes (no lado do servidor). Olhando para a Web, esta separação permite que tanto os clientes como os servidores possam ser desenvolvidos de forma independente, o que apoia a exigência dos múltiplos domínios organizacionais que existem na Internet. • Stateless: Significa que qualquer pedido feito pelo cliente ao servidor contém toda a
informação desse mesmo pedido, seja como parte do Uniform Resource Identifier (URI), parâmetros query-string, corpo da mensagem ou cabeçalho, o que torna possível todos os pedidos recebidos pelo servidor serem independentes uns dos outros. Por outras palavras, a resposta obtida após o envio de uma request é completamente independente de qualquer armazenamento do estado do servidor. O estado da sessão é guardado no lado do cliente, em forma de cache. Esta restrição traz melhorias a nível de visibilidade, fiabilidade e escalabilidade. Visibilidade porque, como cada pedido contém toda a informação necessária, o servidor consegue receber vários pedidos e trata-los sem nenhuma ordem específica. A fiabilidade é melhorada pela simples razão de que facilita na recuperação de pequenas falhas, pois um pedido que siga as especificações REST que não chegue ao servidor, dando timeout, simplesmente reenvia o pedido, ao contrário de outro tipo de pedido em que o servidor tinha de guardar o estado da sessão, como autenticação ou alterações na base de dados, e houvesse uma perda de comunicação durante este processo, a tarefa teria que recomeçar do início. Quanto à escalabilidade, o servidor, como não guarda os estados entre os pedidos, tem mais recursos livres (como memória), o que também simplifica a sua implementação, já que não tem de gerir essas sessões. Obviamente que nem tudo são vantagens. O desempenho da rede é reduzida, cada pedido do mesmo cliente repete a mesma informação, visto que o estado da sessão não é armazenado no servidor, mas sim no cliente. Outro aspeto é também a perda de controlo da aplicação por parte do servidor, já que trabalha (ou pode trabalhar) com várias versões da aplicação.
• Cache: Esta restrição exige que os dados de uma resposta a um pedido contenham uma label, implícita ou explicitamente, que diga se são ou não cacheable. Em caso positivo, a resposta é armazenada em cache e poderá ser reutilizada para pedidos futuros. Isto
12 Capítulo 2. Estado da Arte
traz várias vantagens, como reduzir ou eliminar completamente algumas interações com o servidor, melhorar a eficiência, escalabilidade e desempenho da aplicação, visto que a resposta, por estar em cache, será obtida de forma muito mais rápida, o que resulta numa diminuição significativa da latência dessas interações. No entanto, existe perda de fiabilidade, já que os dados podem estar em cache durante muito tempo e ficarem obsoletos. Esses dados podem diferir bastante dos dados atuais, ou seja, dos dados que seriam obtidos caso o pedido fosse realizado diretamente ao servidor.
• Uniform Interface: Definição de uma interface entre clientes e servidores. O sistema da arquitetura é simplificado e as implementações são desacopladas, o que permite desenvolver cada componente de forma independente. O REST é definido por quatro princípios: identificação de recursos, recursos individuais são identificados nos pedidos através de Uniform Resource Indentifiers (URIs), isto é, os próprios recursos são separados conceptualmente das representações que são retornadas do cliente, de maneira a que a aplicação consiga diferenciar qual dos recursos deve ser utilizado para um determinado pedido; representações dos recursos, a aplicação cliente consegue armazenar uma representação do recurso que solicitou (por exemplo um pedido do tipo GET), onde a própria aplicação modifica essa representação e envia essas alterações a outras aplicações, havendo uma transferência de representações de recursos entre aplicações, evitando transferências ao servidor todas as vezes que forem feitas essas comunicações; mensagens auto-descritivas, cada mensagem inclui informação suficiente para processar a mensagem, ou seja, para completar a tarefa (conceito similar ao stateless); Hypermedia as the Engine of Application State (HATEOAS)), cuja ideia em usar hypermedia nas respostas do servidor é dizer a um cliente que transições levam a estados subsequentes válidos, ou seja, se uma aplicação cliente estiver informado dos métodos Hypertext Transfer Protocol (HTTP), códigos HTTP e tipos de media usados no serviço, só é necessário um único Uniform Resource Locator (URL) para completar o serviço. Todas as outras operações podem ser executadas pelas transições de estado que o cliente realiza quando segue as ligações. Isto liberta os clientes de terem de conhecer vários URLpara os diferentes recursos que um serviço fornece[13].
• Layered System: Tendo em conta a dimensão da Internet, um sistema de camadas foi introduzido no REST. Através das mensagens auto-descritivas, tanto o cliente como o servidor conseguem usufruir de intermediários (proxies). Estes intermediários podem ser usados para várias tarefas, como firewalls entre clientes e servidores, guardar resultados de pedidos e funcionar como uma cache, entre outros. Isto liberta a carga do servidor e melhora o sistema em termos de escalabilidade, pois permite haver um equilíbrio de carga dos serviços entre as múltiplas redes e processadores e, num sistema network-based que suporte restrições de cache, compensa na sobrecarga e aumento de latência que pode ocorrer no processamento de dados[5].
• Code-on-Demand: Esta restrição é opcional, embora recomendável. Permite a extensão das funcionalidades do cliente fazendo download e executando código localmente (applets,
2.2. Trabalhos Relacionados 13 scripts, flash...), processo esse que já era possível ser realizado antes da chegada do REST. Por exemplo, estamos a navegar num web browser numa página com vários streamings flash. Quando selecionamos um (normalmente em forma de link), é enviado um pedido do código para o executar. A nossa aplicação, já com esse código armazenado localmente, executa-o, evitando que o servidor, logo após a primeira resposta com a informação da página, enviasse os códigos para todas as streams disponíveis na página e, também, que fosse necessário que o cliente instalasse software adicional. Também é útil a nível visual, pois determinadas páginas, através do JavaScript, adaptam-se ao dispositivo a que estamos a acedê-las (computador, telemóvel, tablet, etc). Isto traz benefícios, tais como a níveis de desempenho, de eficiência, de escalabilidade, de extensibilidade e de modificabilidade. Mas a reduzida visibilidade torna mais difícil monitorizar as ações no sistema, daí esta restrição ser opcional[15][6].
Um serviço ou aplicação que siga todas estas restrições é chamado de RESTful (inclusive se não incluir a restrição Code-on-Demand). É importante seguir ao máximo estes princípios para que o serviço desenvolvido beneficie deste modelo.
2.2
Trabalhos Relacionados
O objetivo principal do Raccode — a avaliação automática de programas — não é uma ideia nova, existindo já vários sistemas que o fazem, mas são geralmente baseados na web. São exemplos o CodeChef4, CodinGame5, HackerRank6, Codeboard7, Coderunner[14], Mooshak8, entre outros. Neste capítulo são abordados estes sistemas, dando maior ênfase ao Mooshak por estar ligado diretamente a este projeto, bem como algumas tecnologias que permitem a criação de plugins em Ambientes de Desenvolvimento Integrado (IDEs).
2.2.1 IDEs online
Existem muitas plataformas online que apresentam problemas de programação e possibilitam aos seus utilizadores a sua resolução, colocando à sua disposiçãoIDEs próprios. Estas plataformas têm um lado educativo, permitindo ao programador adquirir conhecimento e prática em linguagens de programação, bem como aperfeiçoar o raciocínio lógico. Além disso, certos sites apelam ao espírito competitivo dos utilizadores, realizando esporadicamente concursos online para os membros desse mesmo site.
É de destacar o CodinGame, uma plataforma com vários problemas divididos por dificuldade, dispondo de várias linguagens para a sua resolução, que também permite aos seus utilizadores
4www.codechef.com 5 www.codingame.com 6 www.hackerrank.com 7www.codeboard.io 8 mooshak.dcc.fc.up.pt
14 Capítulo 2. Estado da Arte
submeterem os seus próprios problemas e organizam concursos disponíveis a nível mundial, cujos participantes competem entre si diretamente. Por exemplo, um concurso que consiste num ’ringue’ com tanques e o objetivo é eliminar o maior número de oponentes possível.
CodeChef é um outro caso, desenvolvido pela companhia indiana Directi9. A filosofia desta plataforma é bastante semelhante à do CodinGame, ajudar os programadores a aprenderem novos conceitos de programação (como os algoritmos) e a melhorarem os seus métodos de programação (como a otimização dos seus programas).
Outra plataforma deste tipo é o HackerRank, este com a particularidade de facilitar o recrutamento de programadores mediante as suas habilidades de programação demonstradas na apresentação de soluções dos problemas.
Embora permitam uma boa aprendizagem, estes sistemas têm algumas limitações. Na Tabela
2.1 estão alguns desses software online e as principais caraterísticas esperadas de um bom ambiente de aprendizagem, na perspetiva do desenvolvimento de programas.
CARATERÍSTICAS
Avaliador de programas Multilinguagem Debugger integrado Auto-correção Multiplataforma Competitivo Registo
CodinGame Sim Sim Não Sim Sim Sim Free
CodeChef Sim Sim Não Sim Sim Sim Free
HackerRank Sim Sim Não Sim Sim Sim Free
Sphere Online Judge Sim Sim Não Não Sim Sim Free
CodeFights Sim Sim Não Não Sim Sim Free
Codeboard Sim Sim Não Sim Sim Sim Free
CodeRunner Sim Sim Não Não Sim Sim Free
Softwar
e
Online
CodeWars Sim Sim Não Não Sim Sim Free
Tabela 2.1: Caraterísticas de alguns dos mais utilizados software online de aprendizagem.
Da Tabela2.1pode-se deparar no que já foi dito anteriormente, ou seja, nas falhas que estas plataformas possuem. Nenhuma das testadas apresenta um debugger, uma funcionalidade crucial para detetar e corrigir erros. Algumas delas não possuem a caraterística de auto-correção na escrita de código, que deve fazer parte de um IDE. Todos os aspetos mencionados na tabela são atingíveis no Eclipse, o que torna este projeto mais relevante.
2.3
Resumo
Neste capítulo foram apresentadas as ferramentas utilizadas pelo Raccode, com destaque para o Mooshak que voltará a ser abordado no capítulo seguinte (Capítulo 3) para demonstrar como este se integra na arquitetura do Raccode.
São também indicados alguns trabalhos relacionados, como algunsIDEs online existentes e como estes funcionam, que pode servir de inspiração para o nosso projeto, bem como as suas falhas e como estas podem ser colmatadas com o Raccode.
9
Capítulo 3
Raccode
Neste capítulo é apresentado o Raccode, um plugin para avaliação automática de exercícios de programação do Eclipse. É apresentada a Graphical User Interface (GUI) da versão pública do Raccode. É também descrita a sua arquitetura, em que destaca: a integração e interação do plugin com o Eclipse (cliente) e com o Mooshak 2.0 (servidor); o desenho dos vários componentes que compõem o plugin. É ainda analisada a escolha do Eclipse como IDE para alojar o Raccode. São ainda apresentados detalhes da implementação do Raccode, sendo abordadas as várias dificuldades e limitações que foram encontradas, bem como a forma como foram ultrapassadas.
3.1
Interface Gráfica
Após meses de desenvolvimento do Raccode, conseguimos obter e lançar a primeira versão para utilização pública. Nesta secção serão apresentados os componentes importantes da interface gráfica, sendo eles:
• a perspetiva;
• as janelas para cada uma das três opções da vista das perguntas; • a janela das classificações;
• as duas páginas do wizard para a autenticação e seleção do problema e linguagem; • a barra de menus com três menus adicionados;
• a janela com o feedback obtido após uma submissão;
• a janela de configuração do servidor nas preferências do Eclipse.
Outros componentes importantes para este ambiente não serão destacados, visto que já fazem parte do Eclipse, como são os casos do Package Explorer, Debugger e Terminal.
16 Capítulo 3. Raccode
3.1.1 Perspetiva
Como já foi referido ao longo desta dissertação, o Raccode apresenta uma GUI em formato de perspetiva, como é possível verificar pela Figura 3.1.
Figura 3.1: Perspetiva do Raccode
A caixa com destaque a vermelho identifica os dois botões criados para selecionar um novo problema (com a autenticação a ser feita no caso de o utilizador ainda não esteja autenticado) e submeter um programa para ser avaliado pelo Mooshak. A distribuição das vistas na perspetiva foi desenvolvida para se semelhar com outras perspetivas já disponíveis (ex.: JavaPerspective), com o intuito de facilitar a adaptação dos utilizadores que já as tenham usado. O Package Explorer permanece à esquerda, assim como o Terminal e o Editor de Texto encontram-se posicionadas ao centro, com a adição de uma tab no separador do Terminal relativo ao Debugger. De resto foi apenas adicionado ao topo centro o enunciado do problema, para que o utilizador possa ter acesso ao mesmo enquanto implementa a sua solução, e à direita foram criadas dois separadores para alojar as classificações e as perguntas.
3.1.2 Preferências
O Eclipse tem um módulo de gestão de preferências que permite configurar uma série de funcionalidades nele instaladas, incluindo os plugins. Essas preferências são acessíveis através de um wizard chamado Preferências. Na Figura3.2é possível constatar que foi criado uma página de preferências para o Raccode.
3.1. Interface Gráfica 17
Figura 3.2: Configuração das preferências do Raccode
Esta página tem dois campos, o primeiro para colocar o host (Uniform Resource Locator (URL) com o caminho para a home do servidor) e o segundo serve para colocar a porta de comunicação. Tem também dois botões (para além dos pré-definidos) que servem para guardar um novo host ou apagar um existente.
3.1.3 Barra de Menus
Os comandos associados aos dois botões presentes na toolbar também se encontram associados aos correspondentes dois menus adicionados à barra de menus (Figura 3.3).
Este menu visa melhorar a usabilidade do Raccode, oferecendo várias formas de realizar uma ação. Também tem a particularidade de conter os ícones de cada funcionalidade com o objetivo de que o utilizador consiga associar esses menus com as outras opções (ex.: ao identificar o ícone do NewProblemWizard, a partir desse momento consegue distinguir com mais facilidade o botão corresponde na toolbar ).
18 Capítulo 3. Raccode
Figura 3.3: Barra de menus
3.1.4 NewProblemWizard
O wizard que permite ao utilizador autenticar-se e escolher o problema e a linguagem tem duas páginas, como está ilustrado na Figura 3.4.
Figura 3.4: Wizard para autenticação e seleção de problema e linguagem
A primeira página (imagem da esquerda da Figura3.4) é referente à autenticação do utilizador num concurso, bastando para isso selecionar o concurso e preencher os dois restantes campos com as suas credenciais (username e password). Ao clicar no botão Login a autenticação é processada e se for realizada com sucesso, a página seguinte fica disponível.
A segunda página (imagem da direita da Figura3.4) contem apenas dois campos, um para a seleção do problema e outro para a seleção da linguagem de programação. Ao finalizar o wizard, o projeto é criado, o enunciado aberto na respetiva vista da perspetiva e as vistas das classificações e perguntas ficam disponíveis.
3.1.5 Classificações
As classificações podem ser acedidas de duas maneiras: pelo menu presente na barra de menus (Figura 3.3) ou pelo botão presente na vista das classificações (Figura 3.1). Ambos os modos apresentam uma janela que exibe a informação mais importante acerca das submissões feitas por cada utilizador registado no concurso (Figura3.5).
3.1. Interface Gráfica 19
Figura 3.5: Classificações
da equipa (Team), cada uma das colunas que identifica o problema (A, B e C no caso da Figura 3.5), o número de exercícios resolvidos (Solved) e a pontuação (Points).
3.1.6 Perguntas e Respostas
Na vista à direita e em baixo da perspetiva (Figura 3.1) estão as perguntas e respostas. Esta vista está dividida em três partes: criação de perguntas, visualização de todas as perguntas submetidas e visualização das perguntas submetidas apenas pelo utilizador/equipa.
Sempre que o utilizador tiver uma dúvida sobre os problemas, pode submeter uma questão que irá ser respondida posteriormente. Ao clicar no botão presente na área referente à criação de perguntas, uma nova janela é criada e o seu conteúdo contém o campos que definem uma questão, conforme é possível visualizar na Figura 3.6.
O utilizador apenas tem de selecionar o problema, colocar o assunto da sua questão, colocar a pergunta e premir o botão Submit.
Relativamente às perguntas já submetidas, elas estão separadas em duas áreas, para que o utilizador possa ter acesso às suas perguntas mais facilmente. Para visualizar todas as perguntas
20 Capítulo 3. Raccode
Figura 3.6: Janela para criar e submeter uma questão
submetidas por todos os utilizadores, basta selecionar um problema na área ALL QUESTIONS e premir Show Questions. Uma nova janela é criada com o aspeto apresentado na Figura 3.7.
Figura 3.7: Janela com informação de todas as perguntas submetidas
O utilizador só tem que selecionar o assunto para conseguir ver a pergunta. Isto pode ser útil para o utilizador verificar se a sua pergunta já foi submetida por outro utilizador antes de criar uma nova questão. Assim, evita (ou há a intenção de querer evitar) a duplicação de questões por parte dos utilizadores, já que pode haver dúvidas em comum entre os utilizadores, em que estes podem ter acesso a um esclarecimento à sua dúvida, ao verem que uma pergunta relacionada com a sua dúvida foi submetida.
No caso de o utilizador querer ter acesso às suas questões para verificar se já obtiveram resposta ou não, por exemplo, a forma mais fácil e rápida é premir o botão Show Questions na
3.1. Interface Gráfica 21 área TEAM QUESTIONS. A janela exibida na Figura3.8 contém vários campos que apresentam a informação sobre as perguntas submetidas pelo utilizador/equipa. Esta funcionalidade também permite editar a pergunta, premindo o botão Update e reescrever a nova pergunta.
Figura 3.8: Janela com informação das perguntas submetidas pelo utilizador/equipa
3.1.7 Submissão
Por último temos a submissão dos programas para avaliação. Esta operação pode ser feita de duas formas, ao clicar no botão presente na toolbar (Figura 3.1) e ao selecionar o menu Submit na barra de menus (figura3.3). Uma caixa de diálogo é aberta a pedir a confirmação do utilizador para submeter o programa. Confirmada a submissão, o programa é submetido, avaliado e retornado o feedback sobre essa avaliação. No caso da Figura 3.9, o feedback obtido está vazio, pois a solução submetida estava correta.
Figura 3.9: Janela com o feedback
Os dados exibidos incluem o ID do utilizador/equipa, o estado da avaliação do programa e os comentários. Quando o programa é avaliado como errado, os comentários apresentados são diferentes de submissão para submissão. O feedback é dado de forma progressiva, pelo que ao longo das submissões, o feedback apresente comentários com mais detalhe e mais ajuda ao utilizador.
22 Capítulo 3. Raccode
3.2
Arquitetura
O Raccode serve de ligação entre o Eclipse e o Mooshak, usufruindo das ferramentas mais importantes de ambos os sistemas e juntando-as para criar um ambiente de aprendizagem mais completo. Um ambiente de aprendizagem baseado em avaliação automática de programas necessita de uma conexão ao avaliador de programas, como é o caso do motor de avaliação do Mooshak. Para além disso, o Mooshak apresenta um repositório de problemas, que possibilita a criação de concursos mais apropriados aos seus fins. Por exemplo, para uma cadeira de introdução à programação podem ser criados concursos com problemas mais acessíveis para alunos que estão a ter a primeira experiência com linguagens de programação, ou então podem ser criados concursos com problemas mais exigentes para que os alunos mais dotados tenham forma de progredir no desenvolvimento da capacidade de programação.
3.2.1 Raccode como plugin do Eclipse
O potencial deste tipo de ambiente pode ser melhorado com a associação de ferramentas que permitam implementar as soluções para os problemas destes concursos. Sendo o Eclipse um ambiente de desenvolvimento de software extensível por plugins, é interessante que exista um plugin que permita unir a avaliação ao desenvolvimento, onde o utilizador pudesse criar os seus programas e ambientar-se as ferramentas disponíveis num Ambiente de Desenvolvimento Integrado (IDE) (como o Debugger, o Terminal, o Package Explorer, as Java Virtual Machines (JVMs), entre outros), úteis a um programador, e aprender uma linguagem nova ou simplesmente treinar e desenvolver as suas capacidades numa linguagem já conhecida.
No diagrama Unified Modeling Language (UML) de sequência da Figura3.10estão represen-tados os três sistemas associados a este projeto: o Eclipse, o Raccode e o Mooshak 2.0, bem como as principais funcionalidades. Podemos classificar os objetos deste diagrama da seguinte forma: o Eclipse é o lado do cliente, onde o utilizador tem feedback visual das operações e fornece input que é tratado pelo sistema (o front-end); o Mooshak 2.0 é o lado do servidor, onde são realizados os processos de avaliação automática de programas, de acesso aos problemas, perguntas e respostas e classificações (o back-end); e o Raccode é o componente de ligação entre ambas as extremidades da rede, que está responsável por obter as informações do servidor e mostrá-las no cliente.
Podemos constatar que na Figura 3.10 não é detalhado o lado do servidor, o Mooshak. Isto justifica-se pois o sistema já existia e apenas foi usada a documentação dos métodos da Application Programming Interface (API) Representational State Transfer (REST). A sua implementação não integra este projeto, embora a suaAPIseja apresentada posteriormente neste capítulo.
Em termos de arquitetura, vejamos como se relaciona o Raccode com o Eclipse e o Mooshak. O Eclipse fornece ferramentas que permitem desenvolver software, neste caso em forma de plugin, para o próprio Eclipse. Como tal, o Raccode é um plugin cujo User Interface (UI) se baseia numa
3.2. Arquitetura 23
Eclipse Raccode Mooshak 2.0
WIZARD: Login page
WIZARD: Problem Page
PERSPECTIVE: Create Project / Show Statement
POST: login
GET: Problems / Languages / Statement
Authentication Process RESPONSE: token
WIZARD: Next page available
RESPONSE: Problems / Languages / Statement
GET: Questions / Rankings
RESPONSE: Questions / Rankings VIEW: Questions / Rankings
DIALOG: Show Questions / Show Rankings
COMMAND: Submit
POST: Program File
Evaluation Process
RESPONSE: Feedback DIALOG: Show Feedback
Figura 3.10: Diagrama de sequência das funcionalidades do Raccode
perspetiva, onde se encontram distribuídos em vistas — ou janelas — os vários componentes essenciais a um ambiente de aprendizagem, tendo já sido apresentados no Capítulo 1. Para além da perspetiva, a existência de comandos associados a botões e menus é fulcral para realizar certas operações, como realizar a autenticação num concurso e submeter um programa, que também já foram descritos no Capítulo1. Considerando todos estes componentes e a Figura3.10, o primeiro passo que o utilizador tem de efetuar para ter acesso às restantes funcionalidades é autenticar-se num concurso. Para a autenticação e para a seleção de um problema e de uma linguagem, o utilizador tem de o fazer via wizard. Esta é a forma mais fácil de realizar um conjunto de tarefas, uma vez que o utilizador só tem de preencher os campos pedidos para realizar a operação. O Eclipse permite a utilização de wizards pré-definidos, mas também permite a criação de novos wizards, que é o ideal para o nosso caso, pois permite personalizar o método de autenticação e seleção do problema e linguagem. Assim, um novo wizard foi criado pelo Raccode e para o efeito foram adicionadas duas páginas: a primeira para a autenticação do utilizador e a segunda para a seleção do problema e da linguagem. Na página da autenticação, o Raccode recolhe as credenciais introduzidas pelo utilizador e estabelece uma comunicação com o Mooshak para efetuar o processo de autenticação. Na segunda página, o Raccode está responsável por obter a lista de problemas e de linguagens e disponibiliza-os no cliente para que o utilizador possa fazer as suas escolhas. Quando o wizard é terminado com sucesso, várias alterações na perspetiva são percetíveis, como no Package Explorer com a criação de um novo projeto na linguagem escolhida
24 Capítulo 3. Raccode
relativo ao concurso, caso ainda não exista, a apresentação do enunciado do problema e a ativação dos botões e menus que estavam desativos até então (rankings, questões e submissão). Também as informações dos rankings e das perguntas e respostas são atualizadas neste momento, embora não seja visível ao utilizador. Este, para ter acesso a esta informação, tem de interagir com os botões presentes nas respetivas vistas ou com o menu presente na barra de menus do Eclipse. O Raccode é responsável por realizar estes pedidos ao servidor para obter as informações associados a cada componente e gerar janelas de diálogo (Dialog) para mostrar estas informações. Por fim, a submissão de programas pode ser realizada de duas formas: pelo botão presente na toolbar ou pelo menu presente na barra de menus do Eclipse. Ambos têm em comum o mesmo comando, onde o Raccode obtém o conteúdo do ficheiro da solução e envia-o para avaliação no Mooshak. O feedback resultante dessa avaliação é mostrado numa janela para que o utilizador possa saber se a sua solução está correta ou não, e o que deve alterar, caso seja esse o caso. Só é possível ao utilizador enviar o programa relativo ao último problema selecionado no wizard. Caso queira submeter uma solução de outro problema deve selecionar esse problema no wizard.
3.2.2 API REST do Mooshak 2.0
AAPI RESTdo Mooshak baseia-se no Jersey1, um framework open-source que é a implementação
referência em Java de serviços web RESTful, em que acrescenta alguns recursos que o simplificam ainda mais. O Jersey fornece um Core Server para construir serviços RESTful baseados em anotação que suporta JavaScript Object Notation (JSON) e Java Architecture for XML Binding (JAXB). Também inclui um Core Client que facilita a comunicação da aplicação cliente com os serviços REST. AAPI RESTdo Mooshak 2.0 contém endpoints para autenticação e autorização (auth), concursos (contests), problemas (problems), questões (questions), impressões (printouts), balões (balloons), linguagens (languages) e submissões (submissions). A maior parte dos endpoints consomem e produzem JSON e Extensible Markup Language (XML), mas alguns destes requerem outros formatos, tal como FormData (por exemplo, o endpoint de avaliação recebe um ficheiro txt como input). Os endpoints mais importantes estão sumariados na Tabela 3.1.
A autenticação da API usa JSON Web Tokens (JWT)2, que define como transmitir e armazenar objetos JSON de forma compacta e segura entre diferentes aplicações. Uma vez que o endpoint RESTpara login recebe um pedido do cliente, este extrai o nome do utilizador, palavra-passe e domínio ao qual o utilizador está a tentar conectar-se e aproveita o trabalho no AuthManagerque verifica as credenciais na base de dados. Se tiver sucesso, um JWT Token é gerado e enviado de volta para o cliente, mas caso contrário, um erro é retornado. Depois disso, todos pedidos devem conter o JWT Token no cabeçalho Authorization.
1
https://jersey.github.io/
2
3.3. Desenho 25
Método Endpoint Consome Produz Descrição
POST auth/login JSON/XML Autenticação
num concurso GET data/contests/contestId/rankings JSON/XML vista das classificações
de um concurso
GET data/contests/contestId/problems JSON/XML Lista todos os problemas de um concurso/curso
GET data/contests/contestId/problems/problemId/view JSON/XML vista do problema de um concurso/curso POST data/contests/contestId/problems/problemId/evaluate form-data JSON/XML Avalia o programa
de um concurso/curso
GET data/contests/contestId/languages JSON/XML Lista todas as linguagens de um concurso/curso
GET data/contests/contestId/languages/languageId JSON/XML Obtém a linguagem de um concurso/curso
GET data/contests/contestId/submissions/submissionId
/evaluation-summary JSON/XML
Obtém o feedback de uma avaliação
GET data/contests/contestId/questions JSON/XML JSON/XML Lista todas as perguntas de um concurso/curso
POST data/contests/contestId/questions JSON/XML JSON/XML Cria uma pergunta num concurso/curso
PUT data/contests/contestId/questions/questionId JSON/XML JSON/XML Atualiza a pergunta num concurso/curso
POST data/contests/contestId/printouts form-data JSON/XML Cria um printout num concurso
POST data/contests/contestId/balloons JSON/XML JSON/XML Cria um balloon num concurso
Tabela 3.1: Principais endpoints da API REST do Mooshak
3.3
Desenho
O desenho do plugin está dividido, principalmente, em dois pacotes: um relacionado com o back-end e outro relacionado com o front-end, como é possível ver na Figura3.11. Esta divisão promove a adaptação do Raccode para outros IDEs, em que é apenas preciso trabalhar na parte do front-end (pacote ui). Existe ainda outro pacote que contém classes auxiliares, que foram criadas apenas com o intuito de facilitar a passagem de valores entre classes entre outras funções. Como tal, não será dado mais destaque a este pacote. A Figura 3.11 apresenta todas as classes mais importantes de cada pacote.
3.3.1 Back-end package
Neste pacote estão as classes que comunicam com o servidor, enviando e recebendo dados para as várias funcionalidades do Raccode, desde a autenticação até à submissão da solução e respetivo feedback. As comunicações com o servidor são feitas através da classe HttpsURLConnection que suporta as especificações do Hypertext Transfer Protocol Secure (HTTPS). Como o Mooshak 2.0 utiliza umaAPI RESTe as suas respostas são em formatoJSON, o package javax.json fornece uma API orientada a um modelo de objetos que processa oJSON. Desta forma conseguimos
26 Capítulo 3. Raccode ui ServerConnection JavaLanguageDefinition LoginPage requests Contests Languages Problems Questions Rankings Request Submission ProblemsPage QuestionsView RankView NewProblemWizard SubmitHandler <<interface>> LanguageDefinition
Figura 3.11: Diagrama de pacotes do Raccode
obter os valores associados a uma chave e guardá-los para serem tratados numa operação futura. De seguida apresentamos uma pequena descrição de cada classe apresentada na Figura3.12
para uma melhor compreensão das funcionalidades de cada uma delas:
• Auth: Esta classe trata da autenticação do utilizador. Essa autenticação consiste em três campos de preenchimento ou escolha, sendo eles a seleção de um concurso e o preenchimento dos campos username e password. Os valores destes campos são enviados ao servidor que, por sua vez, responde com o token que ficará associado ao utilizador durante a sessão atual. Este token tem uma validade de uma hora, sendo este atualizado automaticamente por mais uma hora após essa hora ter terminado, caso o utilizador permaneça na mesma sessão. Este procedimento evita que o utilizador se tenha de voltar a autenticar durante a submissão de uma solução, por exemplo. O logout é feito automaticamente no término da sessão, ou seja, quando o plugin for desligado.
• Contests: Classe que gere todos os concursos que estão disponíveis no servidor atual. A obtenção destes concursos é feita através de um pedido GET, cuja resposta está em formato
JSON. Após o seu processamento conseguimos saber as chaves e os seus valores, sendo os mais importantes o nome do concurso e o seu ID. Estes valores são armazenados em arrays para que possam ser reutilizados sempre que forem precisos sem ser necessário voltar a
3.3. Desenho 27 Request - url:str - token:str + sendGet():JsonReader + sendGetFile():InputStream + sendPost():JsonReader + sendPostFile():JsonReader + sendPut():JsonReader + sendDelete():JsonReader + sendPatch():JsonReader Contests - contests:str[] - contestsID:str[] - listContests():void Languages - languages:str[] - languagesID:str[] - token:str - listLanguages():void Auth - username:str - password:str - contest:str + isConnected():bool Problems - problems:str[] - problemsID:str[] - token:str - listProblems():void Questions - token:str - url:str + getListOfQuestions():void Rankings - token:str - url:str + getRankings():void ServerConnection - host:str - path:str - port:int + isConnected():bool Submission - token:str - url:str + submit():JsonObject SubmitHandler (from UI package) + execute():Object - submit():void - showFeedback():void
Figura 3.12: Diagrama de classes do pacote requests
pedi-los ao servidor.
• LanguageDefinition: Interface que define a verificação de uma instalação de uma linguagem, bem como a criação do projeto nessa mesma linguagem. Por outras palavras, quando o utilizador escolhe a linguagem na qual quer usar para implementar a sua solução, o projeto a ser criado terá que ter a "natureza"dessa linguagem, como as bibliotecas necessárias, as pastas de input e output, asJVMs para a execução do código, entre outras definições. Então, para ser possível criar o projeto, a linguagem tem de estar instalada na máquina do utilizador e é por essa razão que está definido nesta interface a verificação da instalação de uma linguagem. No momento da escrita da tese, o Raccode só é capaz de criar projetos em Java (ver a secção Dificuldades e Limitações 3.4.2).
• Languages: Esta classe pede ao servidor todas as linguagens de programação que estão disponíveis no concurso atual e guarda-as num array. Isto é o mesmo que dizer que o motor de avaliação consegue executar as soluções submetidas nestas linguagens e avaliá-las. O processo de obtenção das linguagens é semelhante ao descrito no ponto Contests, em que é enviado um pedido GET, juntamente com o token, e a resposta obtida contém os dados sobre as linguagens. Por outro lado, conforme já foi dito no ponto anterior, o Raccode só aceita a criação de projetos em Java no momento da escrita deste documento (ver a Secção
28 Capítulo 3. Raccode
• Problems: Classe que gere os problemas associados ao concurso atual. Mais uma vez, o método para obter a informação dos problemas é semelhante aos já mencionados. No entanto, esta classe tem a particularidade de ordenar os problemas por ordem alfabética antes de os armazenar num array. Esta ordenação é feita puramente para efeitos visuais, como será devidamente justificada na Secção3.3.2.
• Questions: As questões submetidas durante o decorrer do concurso são obtidas nesta classe. Neste caso, no processamento da resposta obtida após realizado o pedido (que é feito da mesma forma que os anteriores) é armazenado todo o JsonArray, ao invés de serem só guardados os valores mais importantes, pois um determinado par chave/valor pode conter mais do que um valor para essa chave. Então, como existem muitos pares importantes neste caso, como a pergunta em si, o ID e o nome do problema ao qual a pergunta se refere, o ID da pergunta, o assunto da pergunta, a equipa ou utilizador que a submeteu, se já foi ou não respondida, a resposta no caso de já ter sido respondida, entre outros, o seu processamento será feito apenas no front-end (Secção3.3.2).
• Rankings: Algumas estatísticas referentes às submissões de cada equipa ou utilizador em cada problema do concurso corrente são obtidas através desta classe, como a pontuação, o número de submissões em cada problema e o número de problemas resolvidos com sucesso. Pelo mesmo motivo que os dados das questões foram armazenados no seu todo ao invés de retirar apenas a informação importante, aqui também temos um conjunto grande de dados importante, pelo que faz também sentido manter o JsonReader com todos os dados. O seu processamento é feito aquando da exposição dos mesmos (Secção 3.3.2).
• Request: Esta classe pode ser vista como o motor das restantes, pois é a classe que estabelece as comunicações ao servidor. Para enviar um pedido, seja GET, POST, PATCH, DELETE ou PUT, apenas é necessário o caminho (path) do URL e o token associado ao utilizador, visto que existem ações que requerem autenticação. Para passar o token no cabeçalho do pedido é adicionado uma propriedade com a chave Authorization, sendo o token precedido de Bearer o valor que completa este par. De salientar que se o pedido contiver conteúdo, como por exemplo, o envio de um programa para avaliação, foi necessário adicionar outra propriedade, em que a chave é Content-Type e o seu valor multipart/form-data; boundary= seguido de uma String com o boundary. No caso do envio de ficheiros para submissão, o ficheiro é processado nesta classe, ou seja, um dos parâmetros a ser passado é o próprio ficheiro.
• ServerConnection: Esta classe tem simplesmente duas funções, verificar se é possível estabelecer uma conexão ao servidor e fazer parser ao URL, obtendo assim o host, o caminho (path) e a porta.
• Submission: Por fim, a classe de submissão de ficheiros, que obtém o ficheiro pretendido para avaliação e envia-o ao motor de avaliação. Depois de este o avaliar, é retornado o feedback com a avaliação da solução para que o utilizador possa saber se foi ou não aceite e em quantos testes falhou no caso de insucesso, entre outros eventuais comentários.
