raccode: um plugin de avaliação automática de programas ......de plugins, desde a criação,...

Raccode: Um Plugin de Avaliação Automática de Programas para o EclipseAndré Filipe Monteiro da SilvaMestrado Integrado: Engenharia de Redes e Sistemas InformáticosDepartamento 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,

Porto, ______/______/_________

Abstract

The goal of this dissertation is the automatic evaluation of computer programs in the context ofan 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 fromthe features already existing on Eclipse and build a pedagogical environment where its users canlearn and practice programming languages, all while relishing from Mooshak’s 2.0 automaticprogram assessment. Raccode presents the user with a perspective based interface which groupsall commonly used features and required operational resources. Some features were directlyimported from Eclipse, while others were implemented. As mentioned the resources for theautomatic assessment of programs is accomplished by Mooshak, via Application ProgrammingInterface (API) based connections. It is the responsibility of Raccode to perform these connectionsand handle the retrieved data for direct integration with Eclipse.

In this dissertation, the technical implementation details of Raccode are described, includingdetailed schemas of its architecture, development hurdles and how they were solved. Furtheralong, it is also described the validation of Raccode, where it was subjected to user tests, wherethe users possess various levels of experience in programming and IDE use.

i

Resumo

O objetivo desta dissertação é a avaliação automática de programas no contexto de um ambienteintegrado de desenvolvimento (IDE).

O projeto descrito nesta dissertação consistiu na criação de um plugin para o Eclipse, aque demos o nome de Raccode. A ideia principal do Raccode é tirar o máximo partido dasfuncionalidades de um Ambiente de Desenvolvimento Integrado (IDE) e construir um ambientepedagó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. É apresentadauma Interface com o utilizador que se baseia numa perspetiva que reúne todas ferramentas erecursos necessários para o funcionamento deste ambiente. Algumas dessas ferramentas sãoobtidas diretamente do Eclipse, enquanto outras tiveram de ser implementadas. Os recursos paraa avaliação automática de programas são provenientes do Mooshak, sendo as comunicações feitascom base na Application Programming Interface (API) do Mooshak. É da responsabilidade doRaccode 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 suaarquitetura, os problemas encontrados durante o seu desenvolvimento e como esses problemasforam resolvidos. Para além disso, é ainda descrita a validação do Raccode, onde este foisubmetido a testes de grupos de pessoas com diferentes níveis de experiência em programação ena utilização de IDEs.

iii

Agradecimentos

Durante este ano de trabalho, dificuldades e contratempos foram surgindo, mas felizmente pudecontar com a ajuda e o apoio de pessoas que sempre se mostraram disponíveis e estiveram aomeu lado.

Gostaria por começar por agradecer ao meu orientador, o Prof. José Paulo Leal, pela partilhada sua ampla experiência de vida e pela persistência em me fazer melhorar e ultrapassar asminhas limitações, tanto a nível académico como pessoal. Um agradecimento especial tambémao José Carlos Paiva, que se mostrou sempre disponível a ajudar e essa ajuda foi vital para aconclusão deste projeto.

Aos colegas e amigos que fui conhecendo ao longo destes anos de curso, pela ajuda, peloambiente de trabalho e pelos momentos de lazer. Todos eles foram importantes para o sucessodesta 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 à minhafamília, em especial aos meus pais e ao meu irmão, que sempre me apoiaram e lutaram para queeu conseguisse concluir esta etapa com sucesso, não só este ano, mas durante todo o percursouniversitário.

v

Conteúdo

Abstract i

Resumo iii

Agradecimentos v

Conteúdo ix

Lista de Tabelas xi

Lista 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

vii

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

ix

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

xi

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

xiii

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

xiv

Acrónimos

MI:ERSI Mestrado Integrado em Engenhariade Redes e Sistemas Informáticos

CC Ciência de Computadores

M:CC Mestrado em Ciência deComputadores

DCC Departamento de Ciência deComputadores

FCUP Faculdade de Ciências daUniversidade do Porto

HTTP Hypertext Transfer Protocol

HTTPS Hypertext Transfer Protocol Secure

IDE Ambiente de DesenvolvimentoIntegrado

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 ofApplication State

UML Unified Modeling Language

xv

Capítulo 1

Introdução

O crescimento da tecnologia da informática e a popularização da Internet fez com que ocomportamento dos cidadãos mudasse consideravelmente. A criação dos computadores pessoaisveio alargar o leque de oportunidades de mercado, tornando-se imprescindível no quotidianodas pessoas, seja a nível profissional, académico ou entretenimento. Por isso, a aposta nodesenvolvimento de software tem vindo a aumentar e existem cada vez mais programas eaplicaçõ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 disponibilizamvárias ferramentas que auxiliam no trabalho dos programadores e permitem criar software paradiferentes finalidades.

1.1 Motivação

Seja a nível escolar ou empresarial, a utilização de ambientes de desenvolvimento de software porparte dos programadores, como os Ambientes de Desenvolvimento Integrado (IDEs), tem vindoa aumentar significativamente[10]. Estes ambientes permitem o desenvolvimento e a integraçãode ferramentas (plugins e wizards) que, quando bem desenhadas, vêm simplificar as tarefas doutilizador e melhorar a produtividade. Os wizards, por exemplo, tornam tarefas repetitivas, comocriar uma classe em Java, numa única tarefa que consiste em preencher os campos necessários deforma a obter a informação suficiente para gerar um código esqueleto, incluindo declarações aospacotes, construtores, métodos herdados, etc. Já um plugin é uma extensão, um componenteque é possível integrar num IDE, oferecendo-lhe mais funções e recursos. No Eclipse existe omodo perspetiva, que define quais e como surgem na Workbench as janelas (views) que lhe estãoassociadas.

Um outro ponto é a presença forte da Internet no quotidiano das pessoas, que disponibilizainúmeras ferramentas capazes de corresponderem aos objetivos dos utilizadores. Existem muitosambientes para resolução de problemas de programação (alguns exemplos no Capítulo 2), mas

1

2 Capítulo 1. Introdução

não existe nenhum desses ambientes integrados em IDEs. Seria útil ao programador fazer autilização destes serviços num ambiente que lhe é familiar e que utiliza diariamente, ou pelosimples 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 formamais organizada e fácil, sendo os mais importantes o Editor de Texto, o Debugger, o Terminal eo Package Eexplorer. Quanto a sistemas de aprendizagem, como são os sistemas de avaliaçãoautomática de programas para resolução de problemas, existem apenas em modo online. As suasprincipais caraterísticas são a submissão de soluções de problemas de programação, a possibilidadede interação com outros utilizadores através do canal de perguntas e respostas (Q&A) e aindaclassificações para cada concurso.

Temos como objetivo usufruir das ferramentas que constituem o Eclipse e integrar ascaraterísticas de um sistema de avaliação automática de programas para resolução de problemasde 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 definemos ambientes de desenvolvimento como as principais caraterísticas que definem os ambientes deaprendizagem. 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 umbom ambiente de desenvolvimento de software;

• Rankings: uma das funcionalidades dos sistemas de aprendizagem que permite aosparticipantes 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 umdeterminado problema e obter feedback consoante o resultado;

• Aquisição de enunciados: permite aos participantes verem os enunciados dos problemaspara implementarem a sua solução;

• Q&A: interação entre participantes como forma de apoio à resolução dos problemas, emque é possível um participante de um determinado concurso colocar uma questão sobre umdeterminado 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 sistemade aprendizagem bastante completo num dos IDEs mais utilizados para o melhor proveito dosseus utilizadores.

1.3. Abordagem 3

1.3 Abordagem

Com base nestes objetivos, a primeira abordagem considerada foi a criação de um plugin para oEclipse, 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, ondeas janelas se encontram organizadas de maneira a que o utilizador tenha tudo o que precisaem 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 camposnecessários para a configuração aos servidores do repositório de problemas e motor deavaliação;

• Autenticação: através de um Wizard, o utilizador pode fazer login num dos concursosdisponíveis;

• Menu de problemas: logo após a autenticação, ainda dentro do mesmo Wizard, sãoapresentados os vários problemas que aquele concurso dispõe, entre outros possíveis campose/ou opções;

• Package Explorer : mostra todos os projetos em que o utilizador está envolvido, sendocada projeto relativo a um problema. Na Figura 1.1, essa janela encontra-se no ladoesquerdo da perspetiva. Uma funcionalidade interessante desta componente é juntar todosos projetos do mesmo concurso na mesma pasta, de maneira a que seja possível colapsar osconcursos em que o utilizador não esteja a trabalhar, o que melhora a sua organização e aexperiência de navegação entre projetos;

4 Capítulo 1. Introdução

• Enunciado: janela do topo e centro da perspetiva, onde é ilustrado o enunciado doproblema selecionado;

• Editor de Texto: janela com o editor de texto para o utilizador implementar a suasoluçã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 programae de testes, outra com os casos dos teste (obtidos do servidor ou criados pelo utilizador), eo último para executar e obter feedback do Debugger ;

• Classificações: para o concurso selecionado, mostra as classificações para todos osproblemas, bem como as estatísticas pessoais do utilizador nos vários problemas emque participou (número de submissões, respostas de avaliação, entre outros);

• Q&A: possibilita colocar questões sobre um problema para que outros utilizadoresapresentem as suas soluções. Isto cria um ambiente de aprendizagem mais interativoentre 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 quesã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 utilizadorpossa 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, osobjetivos delineados para este projeto, a nossa abordagem que satisfaz a proposta do projeto e aestrutura desta dissertação; o Estado da Arte, onde são descritas as ferramentas utilizadasno desenvolvimento da nossa solução, sendo eles o Mooshak, cuja última versão é integranteneste projeto, servindo de servidor com repositórios de problemas e motor de avaliação; o Plug-inDevelopment Environment (PDE), um ambiente que reúne um conjunto de ferramentas queassistem no desenvolvimento de plugins; o Rich Client Platform (RCP), uma framework paracriação de plugins; e o Representational State Transfer (REST), modelo usado no desenvolvimentoda Application Programming Interface (API) do Mooshak 2.0. Este capítulo conta ainda com aexposição de alguns trabalhos relacionados com o nosso projeto, onde estão indicados algunsexemplos 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 maisimportantes que constituem a API REST do Mooshak 2.0; o desenho do Raccode, onde é descritocom algum detalhe a parte prática da implementação do Raccode, como as suas classes; e odesenvolvimento do Raccode, onde é abordado o motivo da escolha do IDE e são indicadosalguns problemas encontrados durante a implementação do plugin; o Capítulo 4 (Testes eResultados) são abordados os testes feitos ao Raccode que envolveram grupos de pessoas comdiferentes níveis de experiência, quer a nível de programação, quer a nível de interação com umIDE, os resultados desses testes e a respetiva análise; e por último, no Capítulo 5 estão algumasconclusões e observações finais sobre o trabalho realizado no desenvolvimento do Raccode, asprincipais contribuições resultantes e também algumas sugestões de trabalho futuro que promoveo 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. Algumasdessas ferramentas servem também de base para o desenvolvimento de outras ferramentas quese integram no ambiente do Eclipse. Em particular, o Eclipse inclui o Plug-in DevelopmentEnvironment (PDE) que permite fazer esse tipo de desenvolvimento de ferramentas[3], enquantoque o Rich Client Platform (RCP) providencia uma framework que facilita integrar componentesindependentes de software, o que permite ao programador não ter que desenvolver uma aplicaçãodo zero[16][11].

2.1 Ferramentas

Nesta secção serão descritas ferramentas que servirão de apoio para o desenvolvimento desteprojeto, todos do ponto de vista do Eclipse, tais como o PDE, como foi referido anteriormente, oRCP, 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 executacomponentes e bundles. Por estar diretamente ligado a este projeto, é também apresentado oMooshak, 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] quepermite gerir concursos de programação de diferentes tamanhos. Ou seja, pequenos concursosutilizado apenas um servidor ou grandes concursos distribuídos por várias localizações geográficas.Este software avalia automaticamente os programas submetidos pelos concorrentes comparandoos resultados obtidos com os resultados esperados no respetivo problema. O Mooshak tem sido

7

8 Capítulo 2. Estado da Arte

utilizado para várias provas de programação, patrocinadas atualmente pela ACM-ICPC1), comoo SWERC2, e concursos inter-universitários, como o MIUP e o TIUP. Devido à sua capacidadede avaliação automática, atualmente é também utilizado em cursos de programação como formade apoio aos docentes nas aulas, em que dá feedback instantâneo aos alunos e permite a avaliaçãode entregas de trabalhos práticos, por exemplo.

O Mooshak pode comunicar com dois tipos de componentes externos: repositórios deproblemas e motores de avaliação. No repositório de problemas estão armazenados todosos problemas disponíveis para serem resolvidos. Os motores de avaliação contêm casos de testeque permite verificar se a solução apresentada está correta ou não. Estes casos de teste contêmo output esperado, cujo formato é descrito no enunciado do problema e o output obtido peloprograma do concorrente deverá ser exatamente igual para que seja aceite.

Mais recentemente foi desenvolvido o Mooshak 2.03, que tem os mesmos objetivos, mas aoqual foram adicionadas novas funcionalidades. Entre as principais destaca-se um avaliador dediagramas (Kora[7]) e um novo ambiente de aprendizagem (Enki[19]). A versão 2.0 utiliza umnovo modelo de comunicação servidor-cliente (substituindo Apache HTTP server e TCLscript pelo REST Application Programming Interface (API)[19]), entre muitas outrasfuncionalidades.

2.1.2 Plugin Development Environment

O PDE é um ambiente com um conjunto de ferramentas que assistem no desenvolvimentode plugins, desde a criação, desenvolvimento, testes, debug, build e deploy. Este ambienteestá completamente integrado no Eclipse, ou seja, o PDE incorpora a filosofia de integraçãode 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 deforma fácil e sem interromper o seu trabalho. Isso, como tudo, tem vantagens e desvantagens. Agrande vantagem passa pelo utilizador trabalhar no Eclipse da mesma forma que trabalha paraoutros projetos. Outra grande vantagem é a facilidade em que, após o seu desenvolvimento, oplugin é publicado no mercado. Em contra partida, a maior desvantagem é ser ‘exclusivo’ doEclipse, sendo o deploy feito somente no market do Eclipse. Exclusivo aqui está entre aspasporque pensa-se (de uma forma muito pessoal e estudada) ser possível reaproveitar código deforma a integrar no desenvolvimento de plugins para outros IDEs. As componentes que serãoapresentadas na Secção 2.1.3 são algumas ferramentas que o PDE disponibiliza e que serãoutilizadas na construção do nosso plugin[17].

1icpc.baylor.edu2swerc.up.pt3mooshak2.dcc.fc.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 astarefas 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 desenvolvimentode 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áriasferramentas, desenvolvidas por outros programadores, que vem otimizar o trabalho dos restantesutilizadores.

O Eclipse Rich Client Platform (Eclipse RCP, ou só RCP, numa forma mais genérica), permiteao programador perder o menor tempo possível na fase de criação de um projeto e focar-se maisno seu desenvolvimento. Oficialmente, o RCP surgiu na versão 3.0 do Eclipse e contém várioscomponentes, 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. Algunsplugins 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]

• OSGi: A tecnologia OSGi é atualmente controlada pela OSGiTMAlliance e consiste num

http://ptgmedia.pearsoncmg.com/images/chap2_0321334612/elementLinks/02fig02.jpghttp://ptgmedia.pearsoncmg.com/images/chap2_0321334612/elementLinks/02fig02.jpg


conjunto de especificações definindo um sistema dinâmico de componentes para a plataformaJava[1]. De forma resumida, no desenvolvimento de um plugin RCP, é criado um ficheirode configuração chamado MANIFEST.MF. Neste ficheiro encontram-se informações sobreo 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 debaixo nível que fornece controlo da Graphical User Interface (GUI), que permite criarcomponentes gráficos tais como listas, menus, tipos de letras e cores. A implementaçãoSWT faz uso das bibliotecas nativas GUI do sistema operativo utilizando o Java NativeInterface (JNI). Isso permite que os programas que a utilizem tenham maior portabilidadeentre sistemas operativos.

• Runtime: No início, o Eclipse Runtime incluía o modelo do plugin, mas entretanto, essemodelo desceu para a camada do OSGi. Assim sendo, o Runtime está na camada acima econté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 umaclasse para ser usada como ponto de entrada (main entry point). Especificada a aplicação aexecutar, ficará totalmente sob controlo do Eclipse. Quando a aplicação terminar o Eclipsetambém é encerrado.

• JFace: Fornece algumas APIs gráficas desenvolvidas sobre o SWT. É uma toolkit dainterface do utilizador (UI) com classes para manipular tarefas comuns na programaçãoda UI. É desenhada para funcionar em conjunto com o SWT. JFace contém váriascomponentes, desde frameworks para preferências, wizards, imagens, janelas, ações, vistas,entre outros. Todas estas estruturas formam a base da UI do Eclipse.

• User Interface Workbench (UI Workbench): A Workbench adiciona apresentação ecoordenaçã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 quepermitem aos plugins definir esses elementos do UI de forma declarativa; permite tambémque os utilizadores personalizem o visual da aplicação que estão a desenvolver, posicionandoas várias janelas da maneira pretendida.

Todas estas funcionalidades tornam o Eclipse RCP bastante utilizado nos dias de hoje. ANASA, a Adobe e a IBM são exemplos de empresas que utilizam componentes RCP, seja nocontrolo de versões dos seus produtos, ou no armazenamento de imagens de missões espaciaisfeitas pela NASA[16][11][22].

2.1.4 Representational State Transfer

Roy Fielding, um dos principais autores do protocolo HTTP, co-fundador da Apache SoftwareFoundation (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 arquiteturaisaplicadas 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 dosprimeiros serviços Web a seguir os padrões REST (o Google Maps é totalmente construído combase 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) aosservidores que, por sua vez, reagem a esses pedidos. Os clientes não necessitam estarcontinuamente ligados aos servidores, ao contrário dos servidores que ficam à esperaque chegue algum pedido proveniente de um cliente. O servidor pode fornecer serviçospara mais que um cliente. A separação de responsabilidades é o princípio por trás dasrestrições cliente-servidor. Esta divisão permite que haja uma melhoria na portabilidadeda interface em várias plataformas (do lado do cliente) e na escalabilidade, por simplificaros componentes (no lado do servidor). Olhando para a Web, esta separação permite quetanto os clientes como os servidores possam ser desenvolvidos de forma independente, oque 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 ainformaçã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 ospedidos recebidos pelo servidor serem independentes uns dos outros. Por outras palavras,a resposta obtida após o envio de uma request é completamente independente de qualquerarmazenamento 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 eescalabilidade. 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. Afiabilidade é melhorada pela simples razão de que facilita na recuperação de pequenasfalhas, pois um pedido que siga as especificações REST que não chegue ao servidor, dandotimeout, simplesmente reenvia o pedido, ao contrário de outro tipo de pedido em que oservidor tinha de guardar o estado da sessão, como autenticação ou alterações na base dedados, e houvesse uma perda de comunicação durante este processo, a tarefa teria querecomeçar do início. Quanto à escalabilidade, o servidor, como não guarda os estadosentre os pedidos, tem mais recursos livres (como memória), o que também simplifica asua implementação, já que não tem de gerir essas sessões. Obviamente que nem tudo sãovantagens. O desempenho da rede é reduzida, cada pedido do mesmo cliente repete amesma informação, visto que o estado da sessão não é armazenado no servidor, mas sim nocliente. 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 umalabel, 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


traz várias vantagens, como reduzir ou eliminar completamente algumas interações como servidor, melhorar a eficiência, escalabilidade e desempenho da aplicação, visto quea resposta, por estar em cache, será obtida de forma muito mais rápida, o que resultanuma diminuição significativa da latência dessas interações. No entanto, existe perda defiabilidade, 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 obtidoscaso o pedido fosse realizado diretamente ao servidor.

• Uniform Interface: Definição de uma interface entre clientes e servidores. O sistema daarquitetura é simplificado e as implementações são desacopladas, o que permite desenvolvercada componente de forma independente. O REST é definido por quatro princípios:identificação de recursos, recursos individuais são identificados nos pedidos atravésde Uniform Resource Indentifiers (URIs), isto é, os próprios recursos são separadosconceptualmente das representações que são retornadas do cliente, de maneira a quea aplicação consiga diferenciar qual dos recursos deve ser utilizado para um determinadopedido; representações dos recursos, a aplicação cliente consegue armazenar umarepresentação do recurso que solicitou (por exemplo um pedido do tipo GET), onde a própriaaplicação modifica essa representação e envia essas alterações a outras aplicações, havendouma transferência de representações de recursos entre aplicações, evitando transferências aoservidor todas as vezes que forem feitas essas comunicações; mensagens auto-descritivas,cada mensagem inclui informação suficiente para processar a mensagem, ou seja, paracompletar a tarefa (conceito similar ao stateless); Hypermedia as the Engine ofApplication State (HATEOAS)), cuja ideia em usar hypermedia nas respostas doservidor é dizer a um cliente que transições levam a estados subsequentes válidos, ou seja, seuma 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 UniformResource Locator (URL) para completar o serviço. Todas as outras operações podem serexecutadas pelas transições de estado que o cliente realiza quando segue as ligações. Istoliberta os clientes de terem de conhecer vários URL para os diferentes recursos que umserviço fornece[13].

• Layered System: Tendo em conta a dimensão da Internet, um sistema de camadas foiintroduzido no REST. Através das mensagens auto-descritivas, tanto o cliente como oservidor conseguem usufruir de intermediários (proxies). Estes intermediários podem serusados para várias tarefas, como firewalls entre clientes e servidores, guardar resultadosde pedidos e funcionar como uma cache, entre outros. Isto liberta a carga do servidore melhora o sistema em termos de escalabilidade, pois permite haver um equilíbrio decarga dos serviços entre as múltiplas redes e processadores e, num sistema network-basedque suporte restrições de cache, compensa na sobrecarga e aumento de latência que podeocorrer no processamento de dados[5].

• Code-on-Demand: Esta restrição é opcional, embora recomendável. Permite a extensãodas 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 streamingsflash. Quando selecionamos um (normalmente em forma de link), é enviado um pedidodo 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 dapágina, enviasse os códigos para todas as streams disponíveis na página e, também, quefosse 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 estamosa acedê-las (computador, telemóvel, tablet, etc). Isto traz benefícios, tais como a níveis dedesempenho, de eficiência, de escalabilidade, de extensibilidade e de modificabilidade. Masa reduzida visibilidade torna mais difícil monitorizar as ações no sistema, daí esta restriçãoser opcional[15][6].

Um serviço ou aplicação que siga todas estas restrições é chamado de RESTful (inclusive senão incluir a restrição Code-on-Demand). É importante seguir ao máximo estes princípios paraque 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 oCodeChef4, CodinGame5, HackerRank6, Codeboard7, Coderunner[14], Mooshak8, entre outros.Neste capítulo são abordados estes sistemas, dando maior ênfase ao Mooshak por estar ligadodiretamente a este projeto, bem como algumas tecnologias que permitem a criação de plugins emAmbientes de Desenvolvimento Integrado (IDEs).

2.2.1 IDEs online

Existem muitas plataformas online que apresentam problemas de programação e possibilitam aosseus utilizadores a sua resolução, colocando à sua disposição IDEs próprios. Estas plataformas têmum lado educativo, permitindo ao programador adquirir conhecimento e prática em linguagensde programação, bem como aperfeiçoar o raciocínio lógico. Além disso, certos sites apelamao espírito competitivo dos utilizadores, realizando esporadicamente concursos online para osmembros 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.com5www.codingame.com6www.hackerrank.com7www.codeboard.io8mooshak.dcc.fc.up.pt


submeterem os seus próprios problemas e organizam concursos disponíveis a nível mundial, cujosparticipantes 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 destaplataforma é bastante semelhante à do CodinGame, ajudar os programadores a aprenderem novosconceitos 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 orecrutamento de programadores mediante as suas habilidades de programação demonstradas naapresentação de soluções dos problemas.

Embora permitam uma boa aprendizagem, estes sistemas têm algumas limitações. Na Tabela2.1 estão alguns desses software online e as principais caraterísticas esperadas de um bomambiente de aprendizagem, na perspetiva do desenvolvimento de programas.

CARATERÍSTICASAvaliador de programas Multilinguagem Debugger integrado Auto-correção Multiplataforma Competitivo Registo

CodinGame Sim Sim Não Sim Sim Sim FreeCodeChef Sim Sim Não Sim Sim Sim FreeHackerRank Sim Sim Não Sim Sim Sim Free

Sphere Online Judge Sim Sim Não Não Sim Sim FreeCodeFights Sim Sim Não Não Sim Sim FreeCodeboard Sim Sim Não Sim Sim Sim FreeCodeRunner Sim Sim Não Não Sim Sim Free

Soft

war

eO

nlin

e

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 Tabela 2.1 pode-se deparar no que já foi dito anteriormente, ou seja, nas falhas que estasplataformas possuem. Nenhuma das testadas apresenta um debugger, uma funcionalidade crucialpara detetar e corrigir erros. Algumas delas não possuem a caraterística de auto-correção naescrita de código, que deve fazer parte de um IDE. Todos os aspetos mencionados na tabela sãoatingí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 oMooshak que voltará a ser abordado no capítulo seguinte (Capítulo 3) para demonstrar comoeste se integra na arquitetura do Raccode.

São também indicados alguns trabalhos relacionados, como alguns IDEs online existentes ecomo estes funcionam, que pode servir de inspiração para o nosso projeto, bem como as suasfalhas e como estas podem ser colmatadas com o Raccode.

9www.directi.com

Capítulo 3

Raccode

Neste capítulo é apresentado o Raccode, um plugin para avaliação automática de exercícios deprogramação do Eclipse. É apresentada a Graphical User Interface (GUI) da versão pública doRaccode. É também descrita a sua arquitetura, em que destaca: a integração e interação doplugin com o Eclipse (cliente) e com o Mooshak 2.0 (servidor); o desenho dos vários componentesque 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áriasdificuldades 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 parautilização pública. Nesta secção serão apresentados os componentes importantes da interfacegrá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á fazemparte do Eclipse, como são os casos do Package Explorer, Debugger e Terminal.

15

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 deperspetiva, 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 novoproblema (com a autenticação a ser feita no caso de o utilizador ainda não esteja autenticado) esubmeter um programa para ser avaliado pelo Mooshak. A distribuição das vistas na perspetivafoi 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 PackageExplorer permanece à esquerda, assim como o Terminal e o Editor de Texto encontram-seposicionadas 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 utilizadorpossa ter acesso ao mesmo enquanto implementa a sua solução, e à direita foram criadas doisseparadores 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 defuncionalidades nele instaladas, incluindo os plugins. Essas preferências são acessíveis através deum wizard chamado Preferências. Na Figura 3.2 é possível constatar que foi criado uma páginade 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 hostou apagar um existente.

3.1.3 Barra de Menus

Os comandos associados aos dois botões presentes na toolbar também se encontram associadosaos correspondentes dois menus adicionados à barra de menus (Figura 3.3).

Este menu visa melhorar a usabilidade do Raccode, oferecendo várias formas de realizar umaação. Também tem a particularidade de conter os ícones de cada funcionalidade com o objetivode que o utilizador consiga associar esses menus com as outras opções (ex.: ao identificar o íconedo NewProblemWizard, a partir desse momento consegue distinguir com mais facilidade obotão corresponde na toolbar).


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 duaspá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 Figura 3.4) é referente à autenticação do utilizadornum concurso, bastando para isso selecionar o concurso e preencher os dois restantes camposcom 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 Figura 3.4) contem apenas dois campos, um para aseleção do problema e outro para a seleção da linguagem de programação. Ao finalizar o wizard, oprojeto é criado, o enunciado aberto na respetiva vista da perspetiva e as vistas das classificaçõese 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 modosapresentam uma janela que exibe a informação mais importante acerca das submissões feitas porcada utilizador registado no concurso (Figura 3.5).

Das colunas que constituem a tabela de classificações, as mais importantes são o nome


Figura 3.5: Classificações

da equipa (Team), cada uma das colunas que identifica o problema (A, B e C no caso daFigura 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. Estavista está dividida em três partes: criação de perguntas, visualização de todas as perguntassubmetidas 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ãoque irá ser respondida posteriormente. Ao clicar no botão presente na área referente à criaçãode perguntas, uma nova janela é criada e o seu conteúdo contém o campos que definem umaquestão, conforme é possível visualizar na Figura 3.6.

O utilizador apenas tem de selecionar o problema, colocar o assunto da sua questão, colocara pergunta e premir o botão Submit.

Relativamente às perguntas já submetidas, elas estão separadas em duas áreas, para que outilizador possa ter acesso às suas perguntas mais facilmente. Para visualizar todas as perguntas


Figura 3.6: Janela para criar e submeter uma questão

submetidas por todos os utilizadores, basta selecionar um problema na área ALL QUESTIONS epremir 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 útilpara o utilizador verificar se a sua pergunta já foi submetida por outro utilizador antes de criaruma nova questão. Assim, evita (ou há a intenção de querer evitar) a duplicação de questões porparte dos utilizadores, já que pode haver dúvidas em comum entre os utilizadores, em que estespodem ter acesso a um esclarecimento à sua dúvida, ao verem que uma pergunta relacionadacom a sua dúvida foi submetida.

No caso de o utilizador querer ter acesso às suas questões para verificar se já obtiveramresposta ou não, por exemplo, a forma mais fácil e rápida é premir o botão Show Questions na


área TEAM QUESTIONS. A janela exibida na Figura 3.8 contém vários campos que apresentam ainformação sobre as perguntas submetidas pelo utilizador/equipa. Esta funcionalidade tambémpermite 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 feitade duas formas, ao clicar no botão presente na toolbar (Figura 3.1) e ao selecionar o menuSubmit na barra de menus (figura 3.3). Uma caixa de diálogo é aberta a pedir a confirmaçãodo 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 obtidoestá 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 programae os comentários. Quando o programa é avaliado como errado, os comentários apresentadossão diferentes de submissão para submissão. O feedback é dado de forma progressiva, pelo queao longo das submissões, o feedback apresente comentários com mais detalhe e mais ajuda aoutilizador.


3.2 Arquitetura

O Raccode serve de ligação entre o Eclipse e o Mooshak, usufruindo das ferramentas maisimportantes de ambos os sistemas e juntando-as para criar um ambiente de aprendizagemmais completo. Um ambiente de aprendizagem baseado em avaliação automática de programasnecessita de uma conexão ao avaliador de programas, como é o caso do motor de avaliação doMooshak. Para além disso, o Mooshak apresenta um repositório de problemas, que possibilita acriaçã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 queestão a ter a primeira experiência com linguagens de programação, ou então podem ser criadosconcursos com problemas mais exigentes para que os alunos mais dotados tenham forma deprogredir 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 quepermitam implementar as soluções para os problemas destes concursos. Sendo o Eclipse umambiente de desenvolvimento de software extensível por plugins, é interessante que exista um pluginque permita unir a avaliação ao desenvolvimento, onde o utilizador pudesse criar os seus programase 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), entreoutros), úteis a um programador, e aprender uma linguagem nova ou simplesmente treinar edesenvolver as suas capacidades numa linguagem já conhecida.

No diagrama Unified Modeling Language (UML) de sequência da Figura 3.10 estão represen-tados os três sistemas associados a este projeto: o Eclipse, o Raccode e o Mooshak 2.0, bem comoas principais funcionalidades. Podemos classificar os objetos deste diagrama da seguinte forma: oEclipse é 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 osprocessos de avaliação automática de programas, de acesso aos problemas, perguntas e respostase classificações (o back-end); e o Raccode é o componente de ligação entre ambas as extremidadesda 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 daApplication Programming Interface (API) Representational State Transfer (REST). A suaimplementação não integra este projeto, embora a sua API seja apresentada posteriormente nestecapí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

AuthenticationProcess

RESPONSE: tokenWIZARD: Next page available

RESPONSE: Problems / Languages / Statement

GET: Questions / Rankings

RESPONSE: Questions / Rankings

VIEW: Questions / Rankings

DIALOG: Show Questions / Show Rankings

COMMAND: SubmitPOST: Program File

EvaluationProcess

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 componentesessenciais a um ambiente de aprendizagem, tendo já sido apresentados no Capítulo 1. Para alémda perspetiva, a existência de comandos associados a botões e menus é fulcral para realizar certasoperações, como realizar a autenticação num concurso e submeter um programa, que também jáforam descritos no Capítulo 1. Considerando todos estes componentes e a Figura 3.10, o primeiropasso que o utilizador tem de efetuar para ter acesso às restantes funcionalidades é autenticar-senum concurso. Para a autenticação e para a seleção de um problema e de uma linguagem, outilizador 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. OEclipse permite a utilização de wizards pré-definidos, mas também permite a criação de novoswizards, que é o ideal para o nosso caso, pois permite personalizar o método de autenticaçãoe seleção do problema e linguagem. Assim, um novo wizard foi criado pelo Raccode e para oefeito foram adicionadas duas páginas: a primeira para a autenticação do utilizador e a segundapara a seleção do problema e da linguagem. Na página da autenticação, o Raccode recolhe ascredenciais introduzidas pelo utilizador e estabelece uma comunicação com o Mooshak paraefetuar o processo de autenticação. Na segunda página, o Raccode está responsável por obter alista de problemas e de linguagens e disponibiliza-os no cliente para que o utilizador possa fazeras suas escolhas. Quando o wizard é terminado com sucesso, várias alterações na perspetiva sãopercetíveis, como no Package Explorer com a criação de um novo projeto na linguagem escolhida


relativo ao concurso, caso ainda não exista, a apresentação do enunciado do problema e a ativaçãodos botões e menus que estavam desativos até então (rankings, questões e submissão). Tambémas informações dos rankings e das perguntas e respostas são atualizadas neste momento, emboranão seja visível ao utilizador. Este, para ter acesso a esta informação, tem de interagir com osbotões presentes nas respetivas vistas ou com o menu presente na barra de menus do Eclipse. ORaccode é responsável por realizar estes pedidos ao servidor para obter as informações associadosa 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 oupelo 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 saberse a sua solução está correta ou não, e o que deve alterar, caso seja esse o caso. Só é possível aoutilizador enviar o programa relativo ao último problema selecionado no wizard. Caso queirasubmeter uma solução de outro problema deve selecionar esse problema no wizard.

3.2.2 API REST do Mooshak 2.0

A API REST do Mooshak baseia-se no Jersey1, um framework open-source que é a implementaçãoreferência em Java de serviços web RESTful, em que acrescenta alguns recursos que o simplificamainda mais. O Jersey fornece um Core Server para construir serviços RESTful baseados emanotaçã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 osserviços REST. A API REST do 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). Amaior 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 deavaliação recebe um ficheiro txt como input). Os endpoints mais importantes estão sumariadosna Tabela 3.1.

A autenticação da API usa JSON Web Tokens (JWT)2, que define como transmitir earmazenar objetos JSON de forma compacta e segura entre diferentes aplicações. Uma vezque o endpoint REST para 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 noAuthManager que 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.

1https://jersey.github.io/2https://tools.ietf.org/html/rfc7519

https://jersey.github.io/https://tools.ietf.org/html/rfc7519

3.3. Desenho 25

Método Endpoint Consome Produz Descrição

POST auth/login JSON/XMLAutenticaçãonum concurso

GET data/contests/contestId/rankings JSON/XMLvista das classificaçõesde um concurso

GET data/contests/contestId/problems JSON/XMLLista todos os problemasde um concurso/curso

GET data/contests/contestId/problems/problemId/view JSON/XMLvista do problemade um concurso/curso

POST data/contests/contestId/problems/problemId/evaluate form-data JSON/XMLAvalia o programade um concurso/curso

GET data/contests/contestId/languages JSON/XMLLista todas as linguagensde um concurso/curso

GET data/contests/contestId/languages/languageId JSON/XMLObtém a linguagemde um concurso/curso

GETdata/contests/contestId/submissions/submissionId/evaluation-summary

JSON/XMLObtém o feedbackde uma avaliação

GET data/contests/contestId/questions JSON/XML JSON/XMLLista todas as perguntasde um concurso/curso

POST data/contests/contestId/questions JSON/XML JSON/XMLCria uma perguntanum concurso/curso

PUT data/contests/contestId/questions/questionId JSON/XML JSON/XMLAtualiza a perguntanum concurso/curso

POST data/contests/contestId/printouts form-data JSON/XMLCria um printoutnum concurso

POST data/contests/contestId/balloons JSON/XML JSON/XMLCria um balloonnum 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 oback-end e outro relacionado com o front-end, como é possível ver na Figura 3.11. Esta divisãopromove a adaptação do Raccode para outros IDEs, em que é apenas preciso trabalhar na partedo front-end (pacote ui). Existe ainda outro pacote que contém classes auxiliares, que foramcriadas 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 classesmais 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 asvárias funcionalidades do Raccode, desde a autenticação até à submissão da solução e respetivofeedback. As comunicações com o servidor são feitas através da classe HttpsURLConnectionque suporta as especificações do Hypertext Transfer Protocol Secure (HTTPS). Como o Mooshak2.0 utiliza uma API REST e as suas respostas são em formato JSON, o package javax.json forneceuma API orientada a um modelo de objetos que processa o JSON. Desta forma conseguimos


ui

ServerConnection

JavaLanguageDefinition

LoginPage

requests

Contests

Languages

Problems

Questions

Rankings

Request

Submission

ProblemsPage

QuestionsView

RankView

NewProblemWizard

SubmitHandler

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 Figura 3.12para 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êscampos de preenchimento ou escolha, sendo eles a seleção de um concurso e o preenchimentodos 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ãoatual. Este token tem uma validade de uma hora, sendo este atualizado automaticamentepor mais uma hora após essa hora ter terminado, caso o utilizador permaneça na mesmasessão. Este procedimento evita que o utilizador se tenha de voltar a autenticar durante asubmissão de uma solução, por exemplo. O logout é feito automaticamente no término dasessão, ou seja, quando o plugin for desligado.

• Contests: Classe que gere todos os concursos que estão disponíveis no servidor atual. Aobtenção destes concursos é feita através de um pedido GET, cuja resposta está em formatoJSON. Após o seu processamento conseguimos saber as chaves e os seus valores, sendo osmais importantes o nome do concurso e o seu ID. Estes valores são armazenados em arrayspara 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


+ getRankings():void

ServerConnection

- host:str- path:str- port:int

+ isConnected():bool

Submission


+ 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 umalinguagem, 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 bibliotecasnecessárias, as pastas de input e output, as JVMs para a execução do código, entre outrasdefinições. Então, para ser possível criar o projeto, a linguagem tem de estar instalada namáquina do utilizador e é por essa razão que está definido nesta interface a verificação dainstalação de uma linguagem. No momento da escrita da tese, o Raccode só é capaz decriar 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ãodisponíveis no concurso atual e guarda-as num array. Isto é o mesmo que dizer que o motorde avaliação consegue executar as soluções submetidas nestas linguagens e avaliá-las. Oprocesso 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 dadossobre 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ção3.4.2).


• 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. Noentanto, esta classe tem a particularidade de ordenar os problemas por ordem alfabéticaantes de os armazenar num array. Esta ordenação é feita puramente para efeitos visuais,como será devidamente justificada na Secção 3.3.2.

• Questions: As questões submetidas durante o decorrer do concurso são obtidas nestaclasse. 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 deserem só guardados os valores mais importantes, pois um determinado par chave/valorpode conter mais do que um valor para essa chave. Então, como existem muitos paresimportantes neste caso, como a pergunta em si, o ID e o nome do problema ao qual apergunta se refere, o ID da pergunta, o assunto da pergunta, a equipa ou utilizador que asubmeteu, se já foi ou não respondida, a resposta no caso de já ter sido respondida, entreoutros, o seu processamento será feito apenas no front-end (Secção 3.3.2).

• Rankings: Algumas estatísticas referentes às submissões de cada equipa ou utilizador emcada problema do concurso corrente são obtidas através desta classe, como a pontuação, onú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 deretirar apenas a informação importante, aqui também temos um conjunto grande de dadosimportante, pelo que faz também sentido manter o JsonReader com todos os dados. O seuprocessamento é 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 queestabelece 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 associadoao utilizador, visto que existem ações que requerem autenticação. Para passar o tokenno 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 opedido contiver conteúdo, como por exemplo, o envio de um programa para avaliação, foinecessário adicionar outra propriedade, em que a chave é Content-Type e o seu valormultipart/form-data; boundary= seguido de uma String com o boundary. Nocaso do envio de ficheiros para submissão, o ficheiro é processado nesta classe, ou seja, umdos parâmetros a ser passado é o próprio ficheiro.

• ServerConnection: Esta classe tem simplesmente duas funções, verificar se é possívelestabelecer uma conexão ao servidor e fazer parser ao URL, obtendo assim o host, ocaminho (path) e a porta.

• Submission: Por fim, a classe de submissão de ficheiros, que obtém o ficheiro pretendidopara avaliação e envia-o ao motor de avaliação. Depois de este o avaliar, é retornado ofeedback com a avaliação da solução para que o utilizador possa saber se foi ou não aceite eem quantos testes falhou no caso de insucesso, entre outros eventuais comentários.

3.3. Desenho 29

Estas são as classes que constroem o back-end do Raccode, bastando, assim, ao front-endinvocar os vários métodos e atributos para obter os recursos necessários ao funcionamento doplugin. Obviamente, esses métodos e atributos são públicos, pelo que o acesso de outras classes épossível. Teremos oportunidade de também conhecer as classes constituintes do front-end naSecção 3.3.2, bem como uma descrição de cada uma delas, à semelhança do que foi feito nestasecção.

3.3.2 Front-end package

Este pacote inclui as classes que constroem a parte visual (gráfica) do plugin, também denominadoGUI. Ao contrário do back-end, a execução destas classes é exclusivamente feita no Eclipse, istoé, a GUI foi construída para ser usada apenas no Eclipse.

Sendo o plugin desenvolvido em Java, existem alguns toolkits que poderemos usar paraa construção da nossa GUI, como o Abstract Widget Toolkit (AWT), o Standard WidgetToolkit (SWT) e o Swing. Um toolkit inclui um conjunto de widgets, que por sua vez sãocomponentes que compõem uma GUI. Decidimos usar o SWT, pois contém todas as ferramentasde que precisamos e utiliza as bibliotecas gráficas nativas do sistema operacional através do JavaNative Interface (JNI).

Figura 3.13: Diagrama de classes do pacote ui


São agora apresentadas as classes que compõem o front-end do Raccode, cuja descriçãoconsiste na especificação das funcionalidades de cada uma das classes, bem como uma justificaçãodo uso de um tipo de recurso, caso seja preponderante fazê-lo. De notar que a maior parte dasclasses representadas na Figura 3.13 estão relacionadas com outras classes do pacote request,como será mencionado ao longo desta descrição quando necessário:

• Activator: Esta classe é a primeira e a última a ser executada. Quando o Raccode éiniciado, esta classe é a primeira a ser chamada e carrega os dados relativos à autenticação doutilizador e aos servidores armazenados até então. Estes dados são armazenados através daclasse Preferences, da biblioteca java.util.prefs.Preferences, que permite guardarum pequeno conjunto de dados de forma permanente, onde esses dados são guardadosnum ficheiro ou nos registos do sistema (Figura 3.14). Os dados guardados são todos osservidores já conectados pelo Raccode com sucesso, o último servidor a que o Raccodese conectou e os dados de autenticação (username, password, último concurso em que outilizador se autenticou e se é ou não para carregar estes dados nesta nova sessão). Quandoo utilizador encerra o Raccode, esta classe é de novo chamada para guardar todos os valoresrelativos aos campos anteriormente apresentados.

Figura 3.14: Diagrama de classes da relação Activator com ServerConnection

• JavaLanguageDefinition: Esta classe cria o projeto com natureza Java. A composiçãodo projeto consiste em criar as pastas de input e output (bin e src, respetivamente), as

3.3. Desenho 31

bibliotecas principais, o package e a classe main e a configuração da JVM, que é necessáriopara executar os programas. Também decidimos guardar os enunciados no próprio projeto,para que possam ser consultados sempre que o utilizador o entender e também por umaquestão de organização. Outra caraterística desta classe é que permite organizar os projetospor concurso, em que os problemas associados a um respetivo concurso esteja integradoneste projeto. Assim, o nome do projeto é o nome do concurso e cada problema dá onome a um package, permitindo ao utilizador ter uma visão hierárquica e limpa dos seusprogramas no Package Explorer, podendo colapsar ou expandir os projetos.

• LoginPage: Esta classe implementa a primeira página do wizard que contém os campospara a autenticação do utilizador num concurso. Esta página contém três campos: umpara a seleção do concurso e dois para os preenchimentos do username e da password.Contém ainda uma CheckBox para o utilizador confirmar se pretende salvar ou não assuas credenciais quando encerrar o plugin e um botão Login para efetuar o login. Se ologin for efetuado com sucesso, o botão Next fica ativo e permite ao utilizador avançarpara a segunda e última página do wizard.

• PerspectiveFactory: Uma classes que divide as Views que formam a perspetiva doRaccode. A perspetiva é dividida em seis partes: na coluna da esquerda está o PackageExplorer ; na coluna central, no topo é apresentado o enunciado do problema, o Editor deTexto é posicionado no centro e o Terminal e Debugger aparecem na vista inferior, divididosem duas tabs; na coluna da direita encontram-se as duas últimas componentes, em cima avista dos Rankings e em baixo a vista com Perguntas e Respostas (Q&A).

• ProblemHandler: Este handler está associado ao botão New Problem na toolbar e aoitem do menu, com o mesmo nome. Quando pressionado, chama a classe NewProblemWizardque cria o wizard para a autenticação e seleção de um problema e uma linguagem deprogramação. Este wizard é apresentado mais detalhadamente no ponto Wizards destalista.

• ProblemsPage: Cria a segunda e última página do wizard New Problem. Esta páginaapenas contém dois campos, sendo eles a seleção do problema e a seleção da linguagemde programação. Ambas as listas são formadas após o login realizado na página anteriorter sido efetuado com sucesso, pois só aí é possível saber qual concurso foi selecionadoe que problemas mostrar. Quando ambos os campos tiverem um valor, ou seja, quandofor realizada a seleção de um item em ambos os campos por parte do utilizador, o botãoFinish é habilitado e o utilizador pode finalizar o wizard.

• ProblemsView: Esta classe expõe o enunciado do problema selecionado. A vista estáposicionada na coluna central e no topo. Inicialmente, quando o utilizador ainda nãofez qualquer tipo de autenticação e seleção do problema, um pequeno tutorial de como ofazer é apresentado nesta vista, que posteriormente é substituído pelo enunciado quando outilizador concluir o wizard New Problem. O formato do enunciado é, preferencialmente,em Portable Document Format (PDF), utilizando para a sua leitura o leitor de ficheiros PDF


instalado no sistema. É feito download do ficheiro e guardado no respetivo projeto, para queo utilizador possa trabalhar em modo offline. Caso o problema não contenha o enunciadoem formato PDF, é então utilizada a versão HyperText Markup Language (HTML) doenunciado, embora desta forma já seja necessário a conexão à rede.

• QuestionsView: Todas as perguntas submetidas no concurso são processadas e mostradasnesta classe. O processamento serve apenas para filtrar as perguntas que devem ou não sermostradas num determinado evento. São vários os eventos que estão associados aos várioscomponentes presentes nesta vista, que está dividida em três partes: Create Question,All Questions e Team Questions. Todas as partes têm botões que desencadeiam osrespetivos eventos, mas no All Questions tem a adicionante de conter uma ComboBoxcom os problemas para que seja mais fácil ao utilizador obter as perguntas sobre umproblema em específico. Em Create Question, o utilizador (ou a equipa) pode colocaruma questão clicando no único botão presente nessa secção. Isso irá criar um nova janelacom os campos necessários para obter toda informação sobre a pergunta, campos como oassunto da pergunta, a pergunta e a que problema deve estar associada. Para além dissoainda existem dois botões, um para submeter a questão e outro para cancelar a operação.Na secção All Questions existem dois campos, como já foi referido, onde o utilizadorseleciona um problema e clica no botão aí presente para serem exibidas todas as perguntasjá efetuadas sobre o respetivo problema. Nesta nova janela é apresentada a informaçãodas perguntas, e é também é possível responder a uma pergunta. Para isso basta clicarno botão Answer, que criará um nova janela para colocar a resposta à pergunta. Porfim, na terceira secção também é constituído apenas por um botão que cria uma novajanela com toda a informação das perguntas submetidas pelo utilizador (ou equipa) até aomomento. Aqui é possível saber se uma pergunta já obtém uma resposta, bem como editaruma questão já submetida (clicando em Update).

• RankHandler: Esta classe é um handler que permite ao utilizador ver os rankingsatravés da barra de menus, ao invés de o fazer interagindo com a vista. Apenas tem ométodo execute() que invoca o método da classe RankView que trata da criação databela de classificações. O objetivo de adicionar um menu ao plugin é permitir que outilizador possa realizar as mesmas operações com as janelas não cruciais minimizadas.

• RankView: Associada a esta classe está a vista na perspetiva do Raccode, que tem apenasum botão. O utilizador ao clicar nesse botão irá criar uma nova janela com classificaçõescom todos os problemas no concurso corrente e com todos os utilizadores registados noconcurso. A informação aqui apresentada consiste na nacionalidade do utilizador/equipa,no nome do grupo ao qual o utilizador/equipa está associado, no nome do utilizador/equipa,no número de problemas resolvidos e na pontuação do utilizador.

• ServerPreferences: Classe responsável pela criação da página nas preferências do Eclipse.Nesta página o utilizador pode adicionar um novo servidor ou apagar um existente. O novoservidor só será adicionado à lista se for possível estabelecer uma conexão. Para isso énecessário preencher os dois campos existentes, o primeiro relativo ao host (com o path

3.4. Desenvolvimento 33

incluído) e o segundo relativo à porta. Esta classe é ativada pela classe Activator logo noarranque do Raccode (Figura 3.14).

• SubmitHandler: Este handler está associado ao botão Submit na toolbar e ao itemdo menu com o mesmo nome. Quando pressionado é apresentada uma caixa de diálogocom o nome do ficheiro a enviar e a pedir a confirmação do utilizador para a submissão doprograma. O programa é obtido devido à forma como está estruturado o projeto, usandoo nome do concurso e do problema para chegar a esse ficheiro. Submetido o programa, éretornado o feedback do mesmo, em que o utilizador fica a saber se o programa passounos testes com sucesso, e caso contrário, que tipo de erro aconteceu ou em quantos testesfalhou. O tipo de mensagens no feedback vão variando conforme o número de submissões,exibindo um maior detalhe nos erros à medida que forem sendo feitas mais submissões.

• NewProblemWizard: Este wizard está associado ao botão New Problem presente natoolbar. O wizard consiste em duas páginas, a primeira para a autenticação do utilizador(LoginPage) e a segunda para a seleção do problema e da linguagem de programação(ProblemsPage). Além disso, esta classe tem mais funções, como carregar e guardar osdados com as credenciais do utilizador (através dos registos do sistema operativo), atualizaro enunciado do problema e habilitar as vistas Rankings e Q&A. As três últimas operaçõessão executadas quando o wizard é terminado.

Os três componentes restantes (Package Explorer, Terminal e Debugger) são obtidos direta-mente do Eclipse, bastando invocá-los e associá-los à vista correspondente, completando assim aperspetiva do Raccode.

3.4 Desenvolvimento

A utilização do Mooshak 2.0 neste projeto já estava determinada aquando o lançamento daideia, pelo que restava apenas escolher em que IDE desenvolver e alojar a nossa solução. Omotivo da escolha do Eclipse é apresentado nesta secção, bem como as escolhas feitas ao longoda implementação do Raccode e as dificuldades encontradas durante este processo.

3.4.1 Escolha do IDE

A escolha do Eclipse como ferramenta para o desenvolvimento e alojamento do Raccode deve-sea vários fatores, sendo um deles o Eclipse ser um dos IDEs mais utilizados atualmente, conformeé possível confirmar na Figura 3.15.

Para além disso, o conjunto de ferramentas que o Eclipse disponibiliza, permite a criaçãode todos os componentes necessários para um ambiente de aprendizagem rico e intuitivo. OEclipse possibilita a criação de uma perspetiva que agrupa todas as ferramentas e funcionalidadesdo Raccode. É possível reutilizar as ferramentas do próprio Eclipse, como são os casos do


Figura 3.15: Ranking IDEs (agosto 2018). Adaptado de [4].

Package Explorer, Editor de Texto, Terminal e Debugger. É ainda possível a criação de novoscomponentes a serem incorporados nesta perspetiva, como são os exemplos das várias vistas parao enunciado do problema, classificações e perguntas e respostas dos utilizadores no concurso emque se encontram autenticados. A existência dessa GUI facilita a integração dos utilizadorescom pouca ou nenhuma experiência na utilização de ambientes do género (quer de programaçãoquer de utilização de IDEs) e a presença de ferramentas como o Debugger e a possibilidade de osutilizadores poderem importar os seus próprios casos de teste, motiva o desenvolvimento contínuodas capacidades desses utilizadores com mais prática na programação e no uso de IDEs.

Para finalizar, o Eclipse tem a vantagem de conter um market integrado no próprio sistema,chamado MarketPlace. A publicação e partilha de um novo plugin com os restantes utilizadores dacomunidade do Eclipse é simplificada com o MarketPlace. O Eclipse Foundation criou um website3

que funciona como um catálogo que fornece uma lista dos vários plugins do Eclipse. A instalaçãode um plugin num ambiente de trabalho no Eclipse é feita via Marketplace Client (MPC), quefunciona como uma ’ponte’ entre o Eclipse Workspace e o Eclipse MarketPlace.

3.4.2 Implementação

Para a implementação do Raccode utilizamos um conjunto de plugins. Esta abordagem permitea realização de várias tarefas de uma forma mais simples e eficiente, e também assegura a

3https://marketplace.eclipse.org/

3.4. Desenvolvimento 35

compatibilidade com o próprio sistema Eclipse, dando mais garantias de que a nossa solução iráfuncionar noutras máquinas. A linguagem de programação utilizada para a sua construção foi oJava, que apresenta uma API vasta em ferramentas e protocolos úteis, tanto para as comunicaçõesentre cliente e servidor, como para a construção gráfica do Raccode, para além da sua excelentedocumentação.

Ao longo da implementação do Raccode, foram encontradas algumas dificuldades e limitaçõesno desenvolvimento de alguns dos componentes idealizados na fase inicial do projeto, dos quaisnem todos os problemas foram possíveis de serem resolvidos.

Comecemos por descrever as dificuldades maiores, que, para já, são limitações ao desenvolvi-mento do projeto. Uma dessas limitações é a verificação das linguagens de programação instaladasnuma máquina. Cada cliente Raccode pode ter instalado no seu Eclipse várias outras linguagenspara além do Java (que vem instalado por default). A possibilidade de instalar essas mesmaslinguagens é �

raccode: um plugin de avaliação automática de programas ......de plugins, desde a criação,...

Documents