Server Requests para o matUTAD

Pedidos relacionados com not´ıcias

Na Figura 3.26 podemos observar um pedido do tipo GET para apresenta¸c˜ao das not´ıcias e recortes de imprensa na p´agina inicial.

Pedidos de login e logout

Para que o servidor possa disponibilizar os seus conte´udos privados aos utilizadores, torna-se necess´ario que estes realizem o processo de autentica¸c˜ao atrav´es do envio dos parˆametros username e login, tal como ilustrado na Figura 3.27, sendo que na Figura 3.28 encontra-se representado o pedido de logout (servi¸co que inviabiliza o acesso aos servi¸cos disponibilizados pelo sistema).

3.6. DOCUMENTO SERVER REQUEST 55

Figura 3.28 – Pedido de logout.

Pedidos para gerir utilizadores

O administrador poder´a a qualquer momento realizar a adi¸c˜ao de um novo utilizador no sistema, sendo que, no registo de um administrador dever˜ao ser especificados os seus dados pessoais, tal como ilustrado no Request Body da Figura 3.29. Caso o pedido corresponda a um registo de um novo professor dever˜ao ser especificados os seus dados pessoais e escola(s) a que se encontra associado, representada(s) pela

school id key na Figura 3.30.

Figura 3.30 – Pedido para adicionar um professor.

Os professores ser˜ao respons´aveis por adicionar e gerir os seus alunos atrav´es dos pedidos representados nas Figuras 3.31 e 3.32, respetivamente. J´a as Figuras 3.33 e 3.34 representam os pedidos que permitem atualizar as informa¸c˜oes relativas aos administradores e professores (servi¸cos disponibilizados aos administradores).

3.6. DOCUMENTO SERVER REQUEST 57

Figura 3.32 – Pedido para editar informa¸c˜oes do aluno.

Figura 3.34 – Pedido para editar informa¸c˜oes do Professor.

Para que as informa¸c˜oes relativas a um utilizador possam ser removidas do sistema, dever´a ser realizado um pedido com o respetivo ID, tal como ilustrado na Figura 3.35. Este pedido ir´a permitir ao administrador a remo¸c˜ao de qualquer utilizador, enquanto que, ao professor ir´a possibilitar-lhe a op¸c˜ao de remover qualquer um dos seus alunos.

Figura 3.35 – Pedido para eliminar utilizador.

O administrador e professor dever˜ao ter ainda dispon´ıveis um servi¸co que lhes per- mita obter um lista de utilizadores, onde a resposta retornada pelo servidor ir´a depender do utilizador que realizou este pedido (Figura3.36). Caso este servi¸co seja solicitado por um administrador ´e-lhe retornada uma lista de todos os utilizadores do sistema, caso seja de um professor ser´a-lhe retornada uma lista com todos os seus alunos. No entanto, esta pesquisa poder´a ser filtrada pelos parˆametros que se encontram representados no pedido da Figura3.37.

3.6. DOCUMENTO SERVER REQUEST 59

Figura 3.37 – Pedido para filtrar a pesquisa do utilizadores.

Pedidos para gerir as perguntas

Para que o registo de uma nova pergunta seja realizado com sucesso dever˜ao ser especificados os seus parˆametros, processo que poder´a ser realizado com um novo autor (Figura 3.38), ou com um j´a registado no sistema (Figura 3.39).

3.6. DOCUMENTO SERVER REQUEST 61

Figura 3.39 – Pedido para adicionar quest˜ao com um autor registado.

Nas Figuras3.38e3.39podemos ainda observar que no registo de uma nova pergunta ´

e necess´ario especificar o(s) m´odulo(s) a que se encontra associada (identificado(s) pela question module id key). O pedido que permite realizar o registo de um novo m´odulo no sistema encontra-se apresentado na Figura3.40, onde podemos constatar a obrigatoriedade em especificar o seu nome (identificado module name key).

Figura 3.40 – Pedido para adicionar um novo m´odulo.

De forma a editar as informa¸c˜oes relativas a uma pergunta dever´a ser realizado um pedido tal como o ilustrado na Figura3.41. No entanto, no decorrer de qualquer jogo as perguntas ir˜ao ser constitu´ıdas por afirma¸c˜oes, sendo que, o pedido que permite efetuar o seu registo encontra-se representado na Figura3.42. De forma a atualizar o estado de um determinada afirma¸c˜ao, dever´a ser realizado um pedido da forma descrita na Figura 3.43.

Figura 3.41 – Pedido para editar pergunta.

Figura 3.42 – Pedido para adicionar uma nova afirma¸c˜ao.

3.6. DOCUMENTO SERVER REQUEST 63

O gestor de perguntas poder´a ainda realizar um pedido para listar as perguntas registadas no sistema, Figura 3.44, ou filtrar esta pesquisa atrav´es dos parˆametros representados no Request Body da Figura 3.45.

Figura 3.45 – Pedido para filtrar perguntas.

Na Figura 3.46 encontra-se representado um pedido que permite eliminar pergun- tas e/ou afirma¸c˜oes armazenadas no sistema, sendo apenas necess´ario especificar o respetivo ID.

Figura 3.46 – Pedido para eliminar perguntas ou afirma¸c˜oes.

Pedidos para adicionar escola e turma

Os administradores ser˜ao respons´aveis por realizar o registo das escola no matUTAD atrav´es do pedido representado na Figura 3.47. De forma a que os professores possam realizar o registo das suas turmas, dever´a ser realizado um pedido tal como o ilustrado na Figura 3.48.

3.6. DOCUMENTO SERVER REQUEST 65

Figura 3.47 – Pedido para adicionar uma nova escola.

4

Implementa¸c˜ao

Neste cap´ıtulo ser˜ao apresentadas as tecnologias, protocolos e ferramentas utilizadas no desenvolvimento do back end do matUTAD e a sua implementa¸c˜ao.

Para a implementa¸c˜ao do back end do matUTAD for criado um projeto do tipo Maven [5] (ferramenta Java que facilita a gest˜ao de dependˆencias), que visa a im- plementa¸c˜ao de um web service RESTful utilizando o HTTP como protocolo de comunica¸c˜ao e o JSON como formato de dados.

4.1

Back End do matUTAD

De modo a uma melhor compreens˜ao da constitui¸c˜ao do back end do matUTAD, na Figura 4.1 encontram-se representados os v´arios componentes que integram este projeto e o modo de intera¸c˜ao entre eles.

Figura 4.1 – Esquema geral do servidor.

Quando um cliente realiza um pedido, este ir´a passar por um filtro (1) respons´avel por realizar as fun¸c˜oes especificadas nas Subsec¸c˜oes 4.1.5 e 4.1.6, permitindo desta forma, que o recurso contenha todas as informa¸c˜oes e objetos necess´arios para o processamento adequado do mesmo (2). Posteriormente o recurso solicitado ir´a comunicar com a classe Manager (3), sendo da sua responsabilidade interagir com a base de dados (4 e 5). Ap´os este processo, a classe Manager dever´a notificar o recurso sobre o estado da opera¸c˜ao (6), sendo da sua responsabilidade construir a resposta a ser retornada para o utilizador (7).