matUTAD, restruturação dos serviços de suporte (Web e Business Tier)

(1)

matUTAD, Reestrutura¸

c˜

ao dos Servi¸

cos de

Suporte (Web e Business Tier )

Por

Jos´

e Lu´ıs Santos Barreiro

Orientador: Doutor Pedro Miguel Alves da Silva

Co-orientador: Doutor Jo˜

ao Lu´ıs Hon´

orio Matias

Disserta¸c˜ao submetida `a

UNIVERSIDADE DE TR ´AS-OS-MONTES E ALTO DOURO para obten¸c˜ao do grau de

MESTRE

em Engenharia Electrot´ecnica e de Computadores, de acordo com o disposto no Regulamento Geral dos Ciclos de Estudo Conducentes ao Grau de Mestre na UTAD

(2)

(3)

matUTAD, Reestrutura¸

c˜

ao dos Servi¸

cos de

Suporte (Web e Business Tier )

Por

Jos´

e Lu´ıs Santos Barreiro

Orientador: Doutor Pedro Miguel Alves da Silva

Co-orientador: Doutor Jo˜

ao Lu´ıs Hon´

orio Matias

Disserta¸c˜ao submetida `a

UNIVERSIDADE DE TR ´AS-OS-MONTES E ALTO DOURO para obten¸c˜ao do grau de

MESTRE

em Engenharia Electrot´ecnica e de Computadores, de acordo com o disposto no Regulamento Geral dos Ciclos de Estudo Conducentes ao Grau de Mestre na UTAD

(4)

(5)

Orienta¸c˜ao Cient´ıfica :

Doutor Pedro Miguel Alves da Silva

Professor Auxiliar do Departamento de Engenharias, Da Escola de Ciˆencias e Tecnologia Universidade de Tr´as-os-Montes e Alto Douro

Doutor Jo˜ao Lu´ıs Hon´orio Matias

Professor Auxiliar do Departamento de Matemética, Da Escola de Ciências e Tecnologia Universidade de Trás-os-Montes e Alto Douro

(6)

(7)

”Cada sonho que você deixa para trás, é um peda¸co do seu futuro que deixa de existir.”

Steve Jobs

(8)

(9)

matUTAD, Reestrutura¸c˜

ao dos Servi¸cos de Suporte (Web e Business

Tier )

Jos´e Lu´ıs Santos Barreiro

Submetido na Universidade de Tr´as-os-Montes e Alto Douro para o preenchimento dos requisitos parciais para obten¸c˜ao do grau de

Mestre em Engenharia Electrot´ecnica e de Computadores

Resumo — O matUTAD consiste num jogo de matem´atica online desenvolvido na Universidade de Trás-os-Montes e Alto Douro, que permite a alunos do terceiro ciclo do ensino básico e secundário testarem as suas capacidades. Desenvolvido continua-damente desde 2003 com uma metodologia ad-hoc, as tecnologias utilizadas do lado do servidor não são atualmente as mais eficientes para a comunica¸cão com múltiplas plataformas. Tendo em conta estes fatores, surge a necessidade de uma nova im-plementa¸cão que permita uma boa documenta¸cão da estrutura em diagramas, bem como a utiliza¸cão de tecnologias atuais. Esta disserta¸cão tem como objetivo solu-cionar os problemas referidos com uma nova implementa¸c˜ao do Back-End para o matUTAD, abordando numa primeira fase a pesquisa das tecnologias atuais que me-lhor se adequam ao desenvolvimento, e numa fase posterior o desenvolvimento de um protótipo funcional para a aplica¸cão. A estrutura¸cão da plataforma em diagramas ser´a desenvolvida em conjunto com o respetivo projeto do Front-End.

Palavras Chave: matUTAD, Back End, Java EE, Web Services RESTful, Base

de Dados.

(10)

(11)

matUTAD, Reestrutura¸c˜

ao dos Servi¸cos de Suporte (Web e Business

Tier )

Jos´e Lu´ıs Santos Barreiro

Submitted to the University of Tr´as-os-Montes and Alto Douro in partial fulfillment of the requirements for the degree of Master of Science in Electrical Engineering and Computers

Abstract — matUTAD is an online mathematics game developed at the

Univer-sidade de Tr´as-os-Montes e Alto Douro, which allows students from basic and high school to test their skills. In continuous development since 2003 using an ad-hoc methodology, the technologies used for its implementation are currently outdated, leading to the need of a new matUTAD platform, that would provide documentation of its structure in diagrams, and use state of the art technologies. This thesis’ goal is to solve the problems above described, developing the new Back-End for matU-TAD, starting with a research on the best technologies that would be suitable for the project, and eventually implementing a functional prototype for the application. The structuring of the platform will be defined along with the Front-End project.

Key Words: matUTAD, Back End, Java EE, RESTful Web Services, Database.

(12)

(13)

Agradecimentos

Ao longo da realiza¸cão desta disserta¸cão, contei com o apoio incondicional de muitas pessoas, sem as quais não seria poss´ıvel a conclusão da mesma. A elas um sincero obrigado.

Ao Professor Doutor Pedro Miguel Alves da Silva, orientador deste projeto, pela sua orienta¸cão e sugestões, que muito contribu´ıram para o desenvolvimento desta disserta¸cão.

Ao Professor Doutor Jo˜ao Lu´ıs Hon´orio Matias, co-orientador deste projeto, pelos conselhos e ideias inovadoras.

Aos meus amigos e colegas de curso, pela amizade, desabafos, companheirismo, conv´ıvio e apoio incondicional, nos bons e maus momentos. Um agradecimento especial ao António Pereira, uma vez sem ele não seria poss´ıvel a conce¸cão deste projeto. Quero também agradecer ao Jean Paiva, por todos os momentos de apoio durante o desenvolvimento desta disserta¸cão.

`

A minha fam´ılia, em especial aos meus pais e irm˜a, um enorme obrigado pelo o amor e educa¸c˜ao, cruciais para aquilo que sou hoje.

UTAD, Jos´e Lu´ıs Santos Barreiro

Vila Real, 15 de Outubro de 2017

(14)

(15)

´Indice geral

Resumo ix

Abstract xi

Agradecimentos xiii

´_{Indice de tabelas} _xvii

´_{Indice de figuras} _xix

Gloss´ario, acr´onimos e abreviaturas xxiii

1 Introdu¸c˜ao 1

1.1 Motiva¸c˜ao e Objetivos . . . 1

1.2 Organiza¸c˜ao da Disserta¸c˜ao . . . 2

2 Enquadramento Tecnol´ogico 5 2.1 Hypertext Transfer Protocol (HTTP) . . . 5

2.2 Web Services . . . 8

2.3 Seguran¸ca nas Aplica¸c˜oes Web . . . 11

2.4 Base de Dados. . . 15

2.5 Java Plataform, Enterprise Edition (Java EE) . . . 18

3 Conce¸c˜ao 27 3.1 Arquitetura da Aplica¸c˜ao. . . 28

(16)

3.3 Diagrama Entidade-Relacionamento (E-R) . . . 35

3.3.1 Diagrama E-R para o matUTAD . . . 37

3.4 Diagramas Casos-de-Uso . . . 46

3.5 Diagrama de Classes . . . 50

3.5.1 Diagrama de Classes para o matUTAD . . . 52

3.6 Documento Server Request . . . 53

3.6.1 Server Requests para o matUTAD . . . 53

4 Implementa¸c˜ao 67 4.1 Back End do matUTAD . . . 67

4.1.1 Descri¸c˜ao dos Componentes Utilizados . . . 68

4.1.2 Funcionalidades da Base de Dados . . . 74

4.1.3 Parametriza¸c˜ao da Resposta . . . 76

4.1.4 Codifica¸c˜ao/Descodifica¸c˜ao do JSON . . . 77

4.1.5 Pedido de Login . . . 78

4.1.6 Autentica¸c˜ao e Autoriza¸c˜ao . . . 81

4.1.7 Pedidos do Administrador ( @Path (”Administrator”) ) . . . . 85

4.1.8 Pedidos do Professor (@Path(”Teacher”)) . . . 86

4.1.9 Pedidos de um utilizador com permiss˜oes de gest˜ao de per-guntas ( @Path (”QuestionManager”) ) . . . 87

5 Resultados 89 5.1 Falha na Conex˜ao . . . 89

5.2 Keys do Pedido Incorretas . . . 90

5.3 Pedido de login . . . 91

5.4 Processo de Verifica¸c˜ao do Token . . . 93

5.5 Autoriza¸c˜ao . . . 93

5.6 Pedidos do Administrador . . . 94

5.7 Pedidos do Professor . . . 97

5.8 Pedidos de um Utilizador com Permiss˜oes de Gest˜ao de Perguntas . . 99

6 Conclus˜oes e Trabalho Futuro 105

Referˆencias bibliogr´aficas 107

(17)

´Indice de tabelas

2.1 Status Code numa resposta HTTP [16]. . . 8

2.2 DDL Statements [6]. . . 16

2.3 DML Statements [6]. . . 17

2.4 Algumas anota¸c˜oes definidas pelo JAX-RS [21]. . . 25

2.5 Exemplos de scopes pertinentes [21]. . . 26

3.1 Tabela de user stories do estudante. . . . 32

3.2 Tabela de user stories do administrador . . . 33

3.3 Tabela de user stories do visitante. . . . 33

3.4 Tabela de user stories para utilizadores com permiss˜oes de gest˜ao de perguntas . . . 34

3.5 Tabela de user stories do professor . . . 34

(18)

(19)

´Indice de figuras

2.1 Mensagens HTTP . . . 6

2.2 Request Line . . . 6

2.3 Status Line . . . 7

2.4 Modelo de comunica¸c˜ao REST . . . 11

2.5 Estutura de um objeto JSON . . . 12

2.6 Comunica¸c˜ao com o protocolo HTTPS . . . 13

2.7 Estrutura JWT . . . 14

2.8 JWT Header . . . 14

2.9 JWT Payload . . . 14

2.10 JWT Signature . . . 15

2.11 Autentica¸c˜ao com JWT . . . 15

2.12 Base de Dados Relacional vs Base de Dados N˜ao Relacional . . . 16

2.13 Interface phpMyAdmin . . . 18

2.14 Componentes Java EE . . . 20

2.15 Tecnologia HTTPServlet . . . 21

2.16 Ciclo de vida JSP . . . 22

2.17 Fluxo de informa¸c˜ao com filtro. . . 24

2.18 M´etodo observador de um evento . . . 26 xix

(20)

3.3 Ilustra¸c˜ao dos componentes que constituem um Diagrama E-R . . . . 35

3.4 Diagrama E-R para o matUTAD . . . 37

3.5 Utilizadores do matUTAD . . . 38

3.6 Tabela Escola . . . 39

3.7 Entidades Professor, Escola e Relacionamento entre si . . . 39

3.8 Entidade Turma e Rela¸c˜oes com Professor e Escola . . . 39

3.9 Tabela ClassStudentYear e Relacionamentos com Aluno e Turma . . 40

3.10 Tabelas Autor e M´odulo . . . 41

3.11 Tabela Pergunta e Relacionamentos com Autor e M´odulos . . . 41

3.12 Tabela Afirma¸c˜ao e Relacionamento com Pergunta. . . 42

3.13 Tabela Jogo e Relacionamentos com Tipo e M´odulos . . . 43

3.14 Registo dos Alunos num Jogo . . . 43

3.15 Tabela Playing e StudentPlaying . . . 44

3.16 Tabelas por guardar informa¸c˜oes no decorre de um jogo (GameQues-tion e GameQues(GameQues-tionStatement ) . . . 45

3.17 Ilustra¸c˜ao dos componentes que constituem um Diagrama de Casos-de-Uso . . . 46

3.18 Casos de Uso para o Visitante . . . 47

3.19 Casos de Uso para o Aluno . . . 47

3.20 Casos de Uso para o Administrador . . . 48

3.21 Casos de Uso para o Professor (Parte 1) . . . 49

3.22 Casos de Uso para o Professor (Parte 2) . . . 49

3.23 Casos de Uso para Utilizadores com permissões de Gestão de Perguntas 50 3.24 Ilustra¸cão de um iagrama de classes e respectivas rela¸cões . . . 51

3.25 Diagrama de Classes para o matUTAD . . . 52

3.26 Pedido de not´ıcia e recortes de imprensa . . . 53

3.27 Pedido de login . . . 54

3.28 Pedido de logout . . . 55

3.29 Pedido para adicionar um administrador . . . 55 xx

(21)

3.30 Pedido para adicionar um professor . . . 56

3.31 Pedido para adicionar aluno . . . 56

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

3.33 Pedido para editar informa¸c˜oes do Administrador . . . 57

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

3.35 Pedido para eliminar utilizador . . . 58

3.36 Pedido para listar utilizadores . . . 59

3.37 Pedido para filtrar a pesquisa do utilizadores . . . 60

3.38 Pedido para adicionar quest˜ao com um novo autor . . . 60

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

3.40 Pedido para adicionar um novo m´odulo . . . 61

3.41 Pedido para editar pergunta . . . 62

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

3.43 Pedido para editar afirma¸c˜ao. . . 62

3.44 Pedido para listar perguntas . . . 63

3.45 Pedido para filtrar perguntas. . . 64

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

3.47 Pedido para adicionar uma nova escola . . . 65

3.48 Pedido para adiniconar uma nova turma . . . 65

4.1 Esquema geral do servidor . . . 68

4.2 Ilustra¸c˜ao do filtro associado ao recurso de login . . . 69

4.3 Fluxograma de um evento . . . 70

4.4 Tarefas realizadas por um recurso . . . 72

4.5 Cria¸cão do objeto que irá representar a conexão à base de dados . . . 75

4.6 Exemplo de uma query do tipo SELECT . . . 75

4.7 Invoca¸c˜ao do stored procedure respons´avel por adicionar um novo uti-lizador . . . 76

4.8 M´etodo respons´avel por verificar o tipo de JSON . . . 77

4.9 Valida¸c˜ao do pedido efetuado por um professor na atualiza¸c˜ao da sua escola . . . 77

4.10 Login . . . 78 xxi

(22)

4.14 Processo de descodifica¸c˜ao do token . . . 81 4.13 Filtro responsável por controlar o acesso ao recurso . . . 82 4.15 Extra¸cão das permissões associadas a um recurso . . . 83 4.16 Fluxograma responsável por gerar um objeto com os dados do utilizador 84 5.1 Resposta do servidor na falha da conexão com a base de dados . . . . 90 5.2 Pedido com keys incorretas. . . 90 5.3 Pedido de login por um utilizador n˜ao registado . . . 91 5.4 Pedido de login de um administrador . . . 92 5.5 Pedido de acesso a um servi¸co sem token . . . 93 5.6 Utilizador não Autorizado . . . 94 5.7 Escola adicionada pelo Administrador. . . 95 5.8 Pedido para adicionar um admininstrador . . . 96 5.9 Pedido adicionar um professor . . . 96 5.10 Pedido para adicionar um utilizador já registado . . . 97 5.11 Pedido do professor para adicionar turma . . . 98 5.12 Pedido do professor para adicionar aluno . . . 98 5.13 Pedido para adicionar novos módulos . . . 99 5.14 Pedido para adicionar novos autores . . . 100 5.15 Pedido para adicionar novas perguntas . . . 101 5.16 Pedido para adicionar novas afirma¸cões . . . 101 5.17 Resposta para listar perguntas . . . 102 5.18 Lista de Módulos e Autores . . . 103

(23)

Gloss´

ario, acr´

onimos e

abreviaturas

Lista de acr´

onimos

Sigla Expans˜ao

API Application Programming Interface

CDI Context and Dependency Injection

DoS Denial of Service

EIS Enterprise Information System

HTML HyperText Markup Language

HTTP HyperText Transfer Protocol

HTTPS HyperText Transfer Protocol

Java EE Java Plataform, Enterprise Edition

JSON JavaScript Object Notation

JSP JavaServer Pages

JWT Json Web Token

MVC Model-View-Controller

OSI Open Systems Organization Interconnection

RDBMS Relational Database Management System

(24)

SOAP Simple Object Access Protocol

SQL Structure Query Language

SSL Secure Sockets Layer

TCP-IP Transmission Control Protocol/Internet Protocol

TLS Transport Layer Security

URI Uniform Resource Identifier

WWW World Wide Web

XML eXtensible Markup Language

Lista de abreviaturas

Abreviatura Significado(s)

etc. etecetera, outros

(25)

1

Introdu¸c˜

ao

O Departamento de Matemática da Universidade de Trás-os-Montes e Alto Douro (UTAD) iniciou em 2003 o projeto designado de matUTAD, caracterizando-se como um jogo de matemática online constitu´ıdo por várias questões, cada uma delas com quatro afirma¸cões do tipo verdadeira ou falsa, a ser jogado num tempo limitado. Atualmente o jogo é constitu´ıdo por 25 questões e o tempo limite é de 30 minutos.

1.1 Motiva¸

c˜

ao e Objetivos

O matUTAD é um jogo de matem´atica online desenvolvido de forma ad-hoc, isto ´e, implementa¸cão de novas funcionalidades à medida que estas eram necessárias. Atu-almente o mecanismo de autentica¸cão dos utilizadores é realizado através do uso de sessões, contribuindo para problemas de desempenho e escalabilidade do servidor, sendo também da sua responsabilidade gerar todas as páginas e informa¸cões a serem retornadas para os utilizadores.

Tendo em conta estes fatores, constata-se que este modelo não é adequado ao de-senvolvimento de aplica¸c˜oes web para múltiplas plataformas (browser, aplica¸c˜oes

(26)

m´oveis, etc).

De modo a solucionar os problemas referidos, surge a necessidade de redesenho e reestrutura¸c˜ao desta plataforma dividida em Front End e Back End.

´

E neste enquadramento que surge este projeto, que tem como objetivo o desenvolvi-mento do back end do matUTAD, ap´os a defini¸c˜ao da sua estrutura em diagramas em conjunto com o projeto do Front End (desenvolvido como parte de outra disserta¸c˜ao de mestrado [31]), em que as tarefas principais a serem desenvolvidas s˜ao:

• Especifica¸cão e implementa¸cão dos servi¸cos de autentica¸cão; • Desenvolvimento da base de dados;

• Comunica¸cão com clientes remotos através da implementa¸cão de web services.

Tendo como objetivo o desenvolvimento do back end do matUTAD foi utilizado o Java EE, plataforma que disponibiliza um conjunto de ferramentas para o desenvol-vimento web.

De modo a disponibilizar recursos para o cliente (independentemente da plataforma utilizada), foi implementado RESTful web service com a framework Jersey.

Considerando a necessidade de implementar um mecanismo de autentica¸c˜ao

sta-teless, isto ´e, o servidor não armazena informa¸cões do utilizadores, o processo de autentica¸cão ir´a ser baseado em token do tipo JWT, sendo que, para o armaze-namento das informa¸cões do sistema foi utilizada uma base de dados relacional, nomeadamente MySQL.

1.2 Organiza¸

c˜

ao da Disserta¸

c˜

ao

O presente documento encontra-se dividido em seis cap´ıtulos sendo o primeiro refe-rente `a introdu¸c˜ao.

(27)

1.2. ORGANIZAÇ ÃO DA DISSERTAÇ ÃO 3

No Cap´ıtulo 2 s˜ao abordados as tecnologias e protocolos relevantes para a rea-liza¸c˜ao deste projeto.

A especifica¸c˜ao dos requisitos do sistema e respetivos diagramas, bem como a ar-quitetura da aplica¸c˜ao e o contrato entre pedidos e respostas encontram-se descritos no Cap´ıtulo 3.

No Cap´ıtulo 4 encontra-se a documenta¸c˜ao das funcionalidades implementadas no prot´otipo experimental.

Ap´os a implementa¸c˜ao das funcionalidades do sistema s˜ao apresentados no Cap´ıtulo

5 os resultados obtidos.

Como término da disserta¸cão, s˜ao apresentados no Cap´ıtulo 6, as conclus˜oes do trabalho e indica¸cão de tenologias a utilizar num trabalho futuro.

(28)

(29)

2

Enquadramento Tecnol´

ogico

Neste cap´ıtulo será apresentada a descri¸cão das tecnologias e protocolos relevantes para a implementa¸c˜ao do back end, onde s˜ao também apresentados os diversos tipos de ataques a que se encontram sujeitas as aplica¸c˜oes web e solu¸c˜oes utilizadas de forma a preveni-los.

2.1 Hypertext Transfer Protocol (HTTP)

O HTTP ´e um protocolo de comunica¸c˜ao ao n´ıvel da aplica¸c˜ao do modelo Open

Systems Organization Interconnection (OSI), utilizado para sistemas de informa¸c˜ao distribu´ıdos, como por exemplo, a World Wide Web (WWW) [16]. Este proto-colo implementa a arquitetura do modelo Cliente/Servidor (protoproto-colo do tipo

re-quest -reply), utiliza como protocolo de transporte o Transmission Control Proto-col /Internet ProtoProto-col (TCP-IP), caracterizando-se como [16]:

• Connectionless: Pedidos por qualquer ordem, sem necessidade de

nego-cia¸cão prévia. Sobre uma mesma liga¸cão TCP podem ser enviados vários pedidos não relacionados;

(30)

• Independente: Suporta a comunica¸cão de qualquer tipo de dados; • Stateless: Não guarda informa¸cões relativas aos pedidos já processados.

Mensagens HTTP

As mensagens deste protocolo usam um formato standard definido pela especifica¸c˜ao RFC822, que podem ser de pedido (do cliente para o servidor) ou de resposta (do servidor para o cliente), constitu´ıdas pelas campos apresentados na Figura2.1 [7].

Figura 2.1 – Formato das mensagens HTTP [39].

• Request Line: Identifica o tipo de mensagem e o recurso solicitado,

cons-titu´ıda pelos elementos representados na Figura 2.2:

Figura 2.2 – Request Line [2].

1. Request Method : permite ao cliente indicar o tipo de pedido que vai realizar ao servidor, podendo ser do tipo [16]:

(31)

2.1. HYPERTEXT TRANSFER PROTOCOL (HTTP) 7

GET : método utilizado para a leitura de dados. POST : método utilizado para a submissão de dados. PUT : método utilizado para a atualiza¸cão de dados;

DELETE: m´etodo utilizado para que o servidor apagar dados. HEAD: m´etodo utilizado para a leitura de cabe¸calhos;

CONNECT : m´etodo utilizado para que o cliente estabele¸ca conex˜ao com o servidor;

OPTIONS: utilizado retornar os métodos suportados pelo servidor; TRACE: método utilizado para diagnósticos;

2. Uniform Resource Identifier (URI): permite identificar o recurso alocado no servidor.

3. HTTP Version: vers˜ao do protocolo HTTP.

• Status Line: informa¸c˜ao de estado acerca da resposta, constitu´ıdo elementos

representados na Figura 2.3.

Figura 2.3 – Status Line [16].

1. HTTP Version: Vers˜ao do protocolo HTTP.

2. Status Code: ´E um inteiro de três d´ıgitos, em que o primeiro tem como fun¸cão definir a classe de resposta, assumindo os valores representados na Tabela2.1 [16], e os restantes não assumem nenhuma fun¸cão de cate-goriza¸cão [2].

3. Reason-Phrase: Informa¸c˜ao textual relativa ao status code da resposta.

• General Header: campos que s˜ao aplic´aveis a mensagens de pedidos e

(32)

C´odigo Categoria 1xx Informa¸c˜ao

2xx Sucesso

3xx Redirecionar

4xx Erro do lado do cliente 5xx Erro do servidor

Tabela 2.1 – Status Code numa resposta HTTP [16].

• Request Header: permite o envio de informa¸c˜oes adicionais numa mensagem

de pedido, por exemplo cookie.

• Response Header: permite o envio de informa¸c˜oes adicionais numa

mensa-gem de resposta.

• Entity Header: campos que definem informa¸c˜oes relativas `a entidade a ser

transportada, caso esta n˜ao exista, sobre o recurso identificado pelo pedido.

• Entity Body: opcional numa mensagem HTTP, que corresponde `a entidade

a ser transferida, sendo a sua natureza especificada pelos linhas de cabe¸calho

Content-Type e Content-Length (campos pertencentes `a Entity Header ).

2.2 Web Services

A evolu¸c˜ao dos web services surgiu da computa¸c˜ao distribu´ıda, utilizados na in-tegra¸cão de sistemas. Estes providenciam interfaces bem definidas para servi¸cos distribu´ıdos, que s˜ao independentes da plataforma de hardware, do sistema opera-tivo e da linguagem de programa¸cão [10, 14, 27, 29]. São baseados em tecnologias

web standards respons´aveis por receber os pedidos dos clientes, processá-los e re-tornar as respetivas respostas [12]. Além dos benef´ıcios já referidos, estes ainda providenciam:

• Reutiliza¸cão de código: um recurso da aplica¸cão pode ser utilizado por vários

(33)

2.2. WEB SERVICES 9

• Versatilidade: permite que os recursos disponibilizados por uma aplica¸c˜ao

pos-sam ser acedidos por clientes ou web services;

• Seguran¸ca: respons´avel por controlar o acesso aos dados e os recursos

dis-pon´ıveis para outras aplica¸c˜oes;

• Escalabilidade: permite que um crescimento significativo da aplica¸c˜ao n˜ao

comprometa o seu desempenho;

• Redu¸c˜ao no tempo de desenvolvimento: baseiam-se em tecnologias web stan-dards, sendo facilmente incorporadas novas funcionalidades;

• Redu¸cão de custos: permite que não seja necessário criar aplica¸cões à medida

para a integra¸c˜ao de dados.

Os Web Services mais utilizados para o desenvolvimento de aplica¸c˜oes web, s˜ao os Web Services SOAP (Simple Object Acess Protocol ) e os Web Services REST (Representational State Transfer) [11]. Os Web Services REST, que ser˜ao utilizados neste trabalho, foram criados por Roy Fielding em 2000 na sua tese de doutoramento, ´

e um estilo de arquitetura de software projetado para sistemas distribu´ıdos [13], em que a arquitetura do sistema e as intera¸c˜oes na web s˜ao definidas por seis restri¸c˜oes (constraints) que se lhe aplicam [11, 17, 23,27]:

1. Interface Uniforme: respons´avel por definir os contratos entre os clientes e os servi¸cos, em que os quatro princ´ıpios orientadores desta interface s˜ao:

(a) Identifica¸cão dos recursos: Os recursos de uma aplica¸cão são os servi¸cos que se encontram dispon´ıveis na web, identific´aveis recorrendo ao uso de URIs;

(b) Manipula¸cão dos recursos através das representa¸cões: numa resposta os dados poder˜ao assumir diferentes formatos, como por exemplo, XML,

(34)

(c) Mensagens auto-descritivas: As mensagens trocadas entre o cliente e o servidor devem conter todas as informa¸cões necessárias para que as opera¸cões de mapear, interpretar e processar possam ser realizadas com sucesso;

(d) Hypermedia como ”motor”do estado da aplica¸c˜ao: As representa¸cões de recursos obtidas em uma aplica¸cão REST devem possuir hiperlinks que permitam a navega¸cão do cliente pelos recursos. O estado da aplica¸cão muda apenas através de a¸cões identificados por estes hiperlinks.

2. Stateless (Sem Estado): N˜ao utiliza sessões, isto é, o servidor não guarda informa¸cões relativas aos clientes, devendo encontrar-se dispon´ıvel no pedido (URI, headers, query parameters ou no body);

3. Cache: os dados retornados pelo servidor poder˜ao ser registados como

cache-ble (pass´ıveis de utiliza¸c˜ao de cache), proporcionando maior desempenho do sistema;

4. Cliente-Servidor: Através desta arquitetura torna-se poss´ıvel dividir as fun¸cões do cliente (responsável por solicitar os dados ao servidor e apresentá-los ao utilizador) e as do servidor (responsável guardar e/ou manipular informa¸cões, disponibilizando-as de forma eficiente ao utilizador), permitindo que ambos possam evoluir de forma independente;

5. Sistema em multi-camadas: os utilizadores n˜ao acedem diretamente ao servi-dor da base de dados (application server ), eles conectam-se a um intermedi´ario, permitindo melhorias nas pol´ıticas de seguran¸ca, bem como na escalabilidade obtida pelo balanceamento da carga;

6. Code-On-Demand : caracter´ıstica opcional do REST, que permite ao cliente a possibilidade de transferir scripts armazenados no servidor e execut´a-los do seu lado.

(35)

2.3. SEGURANÇ A NAS APLICAÇ ÕES WEB 11

Figura 2.4 – Modelo de comunica¸c˜ao REST [18].

através de interfaces e protocolos padronizados, não impondo restri¸cões sobre o pro-tocolo de comunica¸cão, embora o mais utilizado seja o HTTP, suportando ainda uma ampla gama de formatos de representa¸cão (por exemplo, XML, HTML, JSON), tal como ilustrado na Figura 2.4.

O JSON é um formato leve baseado em texto e projetado para a troca de dados, onde são definidos um conjunto de regras de estrutura¸cão para o seu envio [19]. Na Figura 2.5 é poss´ıvel observar a estrutura dos dados em JSON, representados por um par key/value, em que a key deverá ser uma string respons´avel por identificar o respetivo value, podendo este ser do tipo primitivo (strings, números, booleans e

null ) ou estruturado (objetos e arrays) [15].

2.3 Seguran¸

ca nas Aplica¸

c˜

oes Web

Os web services encontram-se sujeitos a diversos tipos de ataques, que visam explorar as suas vulnerabilidades, entre os quais [34, 35]:

(36)

Figura 2.5 – Estrutura de um objeto JSON [28].

• Eavesdropping: O atacante obtém uma cópia de mensagens sem autoriza¸cão; • Masquerading: O atacante envia ou recebe mensagens em nome de outro

prin-cipal (entidade identificada positivamente no processo de autentica¸c˜ao) sem o seu consentimento;

• Message tampering: As mensagens enviadas s˜ao intersetados por atacantes

que alteram o seu conte´udo antes de as enviar ao destinat´ario correto;

• Replaying: As mensagens s˜ao intersetadas e enviadas numa data posterior; • Denial of Service (DoS) : consiste em sobrecarregar o sistema com pedidos,

tornando os seus recursos indispon´ıveis aos seus utilizadores.

De forma a prevenir o acesso aos dados por utilizadores n˜ao desejados, o sistema dever´a ser seguro e robusto, suportando caracter´ısticas como:

• Autentica¸cão: verificar a autenticidade do pedido, isto é, determinar se é ou

n˜ao um pedido fidedigno;

• Autoriza¸c˜ao: verificar se o utilizador tem permiss˜ao para aceder ao recurso

que est´a a solicitar;

• Confidencialidade: a informa¸cão só deverá ser revelada a utilizadores

(37)

2.3. SEGURANÇ A NAS APLICAÇ ÕES WEB 13

• Integridade: a informa¸cão não deverá ser modificada por utilizadores não

au-torizados;

O protocolo de comunica¸c˜ao HyperText Transfer Protocol Secure (HTTPS), apresenta-se como uma vers˜ao segura do protocolo HTTP, utiliza protocolos para a encripta¸c˜ao das comunica¸c˜oes, tipicamente Secure Sockets Layer (SSL) ou Transport Layer

Secu-rity (TLS), permitindo garantir confidencialidade e integridade dos dados ( ilustrado

na Figura 2.6) [25].

Figura 2.6 – Comunica¸c˜ao com o protocolo HTTPS [3].

Para garantir a autentica¸c˜ao dos pedidos, poder´a utilizar-se o Basic HTTP

Authen-tication Scheme definido pela RFC7617, onde o utilizador ter´a que enviar em todos os pacotes o seu ID e password no Authorization header codificado em Base64, sendo a principal desvantagem desta técnica a necessidade do servidor estar sempre a au-tenticar, ou seja, se para cada pedido for necessário efetuar uma consulta à base de dados, poderá comprometer a escalabilidade do sistema [26]. De forma a minimizar este problema e garantir que os servi¸cos são acedidos por utilizadores autorizados surge o JSON Web Token (JWT).

O JWT ´e um objeto JSON definido pelo standard RFC75129, como uma forma com-pacta e segura de representar informa¸cões para serem transferidas entre duas partes [4,22,40]. A estrutura do JWT é constitu´ıda por três componentes codificadas em Base64, como ilustrado na Figura 2.7 [4, 22, 36].

(38)

Figura 2.7 – Estrutura JWT [9].

1. Header : geralmente constitu´ıdo por duas partes, o tipo de token, identificado pela key ”type”, e o algoritmo de hashing usado para a signature, identificada pela key ”alg”.

Figura 2.8 – JWT Header [4].

Na Figura2.8podemos ver um exemplo de um header que especifica um token do tipo JWT e o algoritmo hashing utilizado ´e HMAC-SHA256.

2. Claims: geralmente cont´em informa¸c˜oes relativas ao token e utilizador (repre-sentado na Figura 2.9).

Figura 2.9 – JWT Payload [4].

3. Crytographic Signature: constitu´ıda pelo header, payload, ambos codificados em Base64, e por um secret (exemplo na Figura 2.10).

(39)

2.4. BASE DE DADOS 15

Figura 2.10 – JWT Signature com o algoritmo de hashing HMAC-SHA256 [4].

A signature permite averiguar a autenticidade do pedido e garantir que os dados n˜ao foram alterados. A Figura 2.11 ilustra o processo de autentica¸c˜ao com token.

Figura 2.11 – Autentica¸c˜ao com JWT.

2.4 Base de Dados

Uma base de dados é uma cole¸cão de informa¸cão organizada para que possa ser facil-mente acedida, manipulada e atualizada, podendo ser do tipo relacional, Structured

Query Language (SQL), ou n˜ao relacional (NoSQL) [38,43]. A diferen¸ca entre estes dois tipos de base de dados é o modo como são constru´ıdas, o tipo de informa¸cão e a forma como se encontra armazenada, como representado na Figura 2.12.

As bases de dados não relacionais são geralmente utilizadas quando se pretende armazenar grandes volumes de dados não estruturados, onde o seu acesso é realizado sem conhecimentos de linguagem SQL, por exemplo (MongoDB ).

(40)

Figura 2.12 – Base de Dados Relacional vs Base de Dados N˜ao Relacional [43].

Nas base de dados relacionais os dados s˜ao organizados em tabelas relacionadas entre si, acedidas e manipuladas atrav´es de linguagem SQL [8], podendo os comandos subdividir-se nas seguintes categorias:

Data Definition Language (DLL) Statement

Os comandos pertencentes a esta categoria, representados na Tabela 2.2, permitem definir a estrutura da base de dados e das tabelas.

Comando Descri¸c˜ao

CREATE Criar uma nova base de dados/tabela.

ALTER Modificar a estrutura da base de da-dos/tabela.

DROP Apagar a base de dados/tabela.

(41)

2.4. BASE DE DADOS 17

Data Manipulation Language (DML) Statement

Esta categoria define os comandos que poder˜ao ser utilizados nas queries efetuadas `

a base de dados, tal como representado na Tabela 2.3.

Comando Descri¸c˜ao

SELECT Permite ler dados armazenados na base de dados.

INSERT Permite armazenar novos dados na base de dados.

UPDATE Atualizar dados armazenados na base de da-dos.

DELETE Eliminar dados armazenados na base de da-dos.

Tabela 2.3 – DML Statements [6].

Transaction Control Statement (TCS)

Nesta categoria s˜ao enquadradas as transa¸c˜oes caracterizadas pela sigla ACID [32]:

• Atomicidade: todas as opera¸cões que constituem uma transa¸cão deverão ser

realizadas com sucesso ou nenhuma das opera¸c˜oes tem qualquer efeito;

• Consistˆencia: uma transa¸c˜ao deve levar o sistema de um estado consistente

para outro estado consistente;

• Isolamento: cada transa¸cão deverá ser realizada de forma a que não ocorra

qualquer interferˆencia de outra transa¸c˜ao.

• Durabilidade: as modifica¸c˜oes efetuadas por uma transa¸c˜ao que terminou com

sucesso dever˜ao ser tornadas persistentes.

As base de dados relacionais suportam ainda o uso de stored procedures, caracte-rizados como blocos de instru¸c˜oes SQL executadas do lado do servidor. Estes s˜ao

(42)

responsáveis por aceitar parâmetros de entrada e de retornar valores à entidade que invocou, podendo ainda ser utilizados no controlo das transa¸cões.

De forma a facilitar a implementa¸c˜ao de uma base de dados, torna-se vantajosa a utiliza¸c˜ao de um Gestor de Base de Dados, Relational Database Management

Sys-tem (RDBMS), software que possibilita a cria¸c˜ao, leitura, atualiza¸c˜ao e remo¸c˜ao de informa¸c˜oes armazenadas na base de dados, tais como MySQL, Oracle Database,

Microsoft SQL Server etc [33]. De forma a uma melhor administra¸cão e gestão da base de dados podem ser utilizadas ferramentas como o phpMyAdmin, com a interface gráfica ilustrada na Figura 2.13.

Figura 2.13 – Interface phpMyAdmin.

.

2.5 Java Plataform, Enterprise Edition (Java EE)

O Java EE ´e uma plataforma que disponibiliza um conjunto de bibliotecas e tec-nologias que visam simplificar o desenvolvimento de aplica¸c˜oes web, tendo como vantagens:

• Orientada a Objetos: todo o c´odigo Java ´e definido em classes e a maioria

destas classes é instanciada em objetos, contribuindo desta forma para uma melhor organiza¸cão do código;

(43)

2.5. JAVA PLATAFORM, ENTERPRISE EDITION (JAVA EE) 19

• Encapsulamento: o suporte de access modifiers permite realizar o controlo

de acesso aos dados;

• Plataforma Independente: como todas as aplica¸c˜oes em Java s˜ao

execu-tadas pela Java Virtual Machine (JVM), estas s˜ao compiladas em Bytecode (linguagem da JVM), permitindo desta forma, que o c´odigo possa facilmente ser transferido para outro sistema computacional;

• Robusta: uma das grandes vantagens do Java ´e o Garbage Collection,

pro-cesso que consiste em eliminar objetos que já não são necessários, contribuindo desta forma, para a preven¸cão de perdas de memória;

• Segura: como o código Java corre no interior de uma JVM, é criada uma sandbox, impossibilitando que o mesmo possa executar opera¸c˜oes prejudiciais ao computador em que está a ser executado.

De forma a realizar uma gestão mais eficiente e eficaz dos vários utilizadores, o mo-delo de aplica¸cão Java EE define uma arquitetura para a implementa¸cão de servi¸cos como aplica¸cões em multicamada, isto é, a lógica da aplica¸cão é dividida em com-ponentes, ilustrado na Figura 2.14 [21,30]:

1. Client Tier : os componentes desta camada correm do lado do cliente e s˜ao respons´aveis por realizar pedidos ao servidor, como por exemplo, application

client e applets;

2. Web Tier : componentes web, geridos pelo Web Container (interface entre os

web components e o servidor Java EE), respons´aveis por: I gerir as intera¸c˜oes entre os clientes e a business tier ; II gerar respostas para o cliente em v´arios formatos;

III recolher as informa¸c˜oes especificadas no pedido e retornar a resposta ge-rada na business tier ;

(44)

3. Business Tier : componentes que correm do lado do servidor respons´aveis por definir a l´ogica de uma aplica¸c˜ao, como por exemplo, web services;

4. Enterprise Information System Tier (EIS): consiste no servidor da base de dados, geralmente localizado numa m´aquina diferente do servidor Java EE, que s˜ao acedidos pelos componentes da business tier.

Figura 2.14 – Componentes Java EE [21].

Java Servlets

Uma Servlet ´e uma classe de linguagem de programa¸c˜ao Java, executada do lado do servidor, com o objetivo de aumentar as funcionalidades do mesmo, sendo a

(45)

Figura 2.15 – Tecnologia HTTPServlet [37].

A HttpServlet providencia v´arios métodos que permitem receber pedidos efetua-dos pelos clientes, processá-los e retornar as respetivas respostas (Figura 2.15). Quando uma Servlet é solicitada, a interface HttpServletRequest define um con-junto de métodos que permitem efetuar a extra¸cão dos dados relativos ao pedido (presentes por exemplo, no URI, nos headers, ou body) de modo a que o seu pro-cessamento possa ser realizado de forma adequada. Já a resposta a ser retornada para o cliente poder´a ser constitu´ıda por status code, HTTP headers e response body, sendo que, todos estes campos irão ser manipulados pelos métodos disponibilizados pela interface HttpServletResponse.

A cada pedido realizado pelo cliente, ser´a da responsabilidade do Web Container realizar o mapeamento entre o URI `a respetiva Servlet, bem como gerir o seu ciclo de vida[21]:

1. Se ainda n˜ao existe nenhuma instˆancia da Servlet, dever´a: I Carregar a Servlet ;

(46)

III Inicializa¸cão da instância através do m´etodo init().

2. Invocar o m´etodo de servi¸co respons´avel processar o pedido do cliente e retor-nar a respetiva resposta.

3. Caso seja necess´ario remover a Servlet, este ser´a respons´avel por invocar o m´etodo destroy().

JavaSever Pages (JSP)

As JSP s˜ao uma extens˜ao da tecnologia Java Servlet executadas do lado do servidor, caracterizadas como ficheiros de texto que contˆem [21]:

1. Dados est´aticos: podem ser representados em qualquer formato de texto (por exemplo HTML, XML).

2. Elementos JSP: responsáveis pelo conteúdo dinâmico.

(47)

Sempre que se verificar uma solicita¸c˜ao a uma JSP, ´e da responsabilidade do Web

Container a realiza¸c˜ao das seguintes tarefas, representadas na Figura 2.16 [21]:

1. Tradu¸c˜ao: consiste na gera¸c˜ao de um ficheiro Java Servlet a partir de um ficheiro JSP.

2. Compila¸c˜ao: o ficheiro Java Servlet ´e compilado em uma classe Java Servlet. 3. Loading: a classe Servlet compilada ´e armazenada em mem´oria.

4. jspInit(): m´etodo que permite inicializar a instˆancia da Servlet.

5. jspService(): m´etodo que permite processar o pedido do cliente e gerar a respetiva resposta.

6. jspDestroy(): m´etodo solicitado quando não é necessária a instˆancia da Servlet.

Quando um cliente efetua um pedido HTTP ao servidor web, este tem como fun¸c˜ao efetuar a sua convers˜ao para um objeto do tipo HTTPServletRequest e entrega-lo a um web component. De modo a gerar uma resposta, o web component dever´a criar um objeto do tipo HTTPServletResponse, podendo interagir com os JavaBeans

components, ou diretamente com a base de dados. Ap´os a cria¸cão deste objeto, é da responsabilidade do servidor web efetuar a sua convers˜ao para uma resposta HTTP e retorná-la para o cliente que efetuou o pedido [21].

Contudo, o processo descrito anteriormente poderá ser alterado através de filtros, caracterizados como objetos geridos pelo Web Container, utilizados para filtragem de pedidos, respostas, ou em ambas as situa¸cões (ilustrado na Figura 2.17).

As principais tarefas que poder˜ao ser realizadas por um filtro s˜ao:

• Autentica¸c˜ao.

• Leitura/modifica¸c˜ao dos headers e entity body presentes num pedido ou numa

resposta.

(48)

Figura 2.17 – Fluxo de informa¸c˜ao com Filtro [21].

Web Service RESTful com Java EE

S˜ao designados por web services RESTful aqueles que implementam a arquitetura REST, geralmente utilizados para a cria¸cão de aplica¸cões baseadas na web, carac-terizados como leves, escaláveis, de fácil manuten¸cão [21].

JAX-RS

´

E uma Application Programming Interface (API) de linguagem de programa¸c˜ao Java que usa anota¸c˜oes, projetada para simplificar o desenvolvimento de aplica¸c˜oes que implementam a arquitetura REST [21].

O Jersey ´e uma framework open source para a implementa¸cão web services RESTful com base no standard JAX-RS. Disponibiliza a sua pr´opria API, além das funciona-lidades do JAX-RS, permitindo assim que o programador possa usufruir de recursos adicionais no desenvolvimento da aplica¸cão. Na Tabela 2.4 apresentam-se algumas anota¸cões definidas pelo JAX-RS.

(49)

@Path Define o caminho relativo onde o recurso se encon-tra dispon´ıvel

@GET, @POST, @PUT,

@DELETE

Permite mapear o m´etodo presente no pedido HTTP com o recurso correspondente

@QueryParam permite extrair os query parameters presentes no URI

@Consumes Permite especificar o formato dos dados que o re-curso ir´a receber num determinado pedido

@Produces Permite especificar o formato dos dados retornados pelo servidor

@Provider Permite alterar o comportamento do tempo de

execu¸c˜ao, com o objetivo de realizar um conjunto de metas definidas pelo programador

@NameBinding Permite associar filtros a recursos.

Tabela 2.4 – Algumas anota¸c˜oes definidas pelo JAX-RS [21].

Context and Dependecy Injection (CDI)

O CDI define um conjunto de servi¸cos projetados para serem utilizados com objetos

stateful, contribuindo para a simplifica¸c˜ao da estrutura c´odigo. Os principais servi¸cos disponibilizados pelo CDI s˜ao [21]:

• Contexts: permite vincular o ciclo de vida e intera¸c˜oes de componentes statefull

(estado do objeto) a contextos com ciclos de vida bem definidos (designados por beans).

• Dependency Injection: permite a inje¸c˜ao de componentes na aplica¸c˜ao de

forma segura e especificar em que momento este processo dever´a ser despole-tado.

Numa aplica¸c˜ao web para que um bean possa ser injetado noutra classe, este necessita de ser associado a um scope (Tabela2.5) respons´avel por definir o seu ciclo de vida e a sua visibilidade.

(50)

Scope Anota¸c˜ao Dura¸c˜ao

Request @RequestScoped intera¸c˜ao do utilizador com a aplica¸c˜ao

web num ´unico pedido HTTP

Session @SessionScoped intera¸c˜ao do utilizador com a aplica¸c˜ao

web atrav´es de m´ultiplos pedidos HTTP

Application @ApplicationScoped estado partilhado entre todos os utili-zadores durante a sua intera¸c˜ao com a aplica¸c˜ao web

Dependent @Dependent objeto utilizado para servir um cliente espec´ıfico com o mesmo ciclo de vida do cliente

Tabela 2.5 – Exemplos de scopes pertinentes [21].

Os beans podem encontrar-se em camadas diferentes da aplica¸c˜ao, podendo estes comunicar entre si através de eventos, sem qualquer dependência do tempo de compila¸cão. Um evento ´e definido por um objeto statefull e possui zero ou mais

qualifiers (anota¸c˜ao aplicada a um bean, permitindo que este possa ter v´arias imple-menta¸c˜oes). Para que um evento possa ser manipulado dever´a existir um observer

method, que tem como parˆametro de entrada um objeto correspondente ao do evento e tamb´em todos os seus qualifiers, representado na Figura 2.18. O observer method ´

e responsável por realizar a manipula¸cão do evento de acordo com as especifica¸cões definidas pelo programador, podendo posteriormente ser injetado noutra classe.

(51)

3

Conce¸c˜

ao

O matUTAD é um jogo de Matem´atica online constitu´ıdo por 25 quest˜oes, cada uma delas com quatro afirma¸cões do tipo verdadeira ou falsa, em que os utilizadores do sistema poderão ser:

• Administrador: utilizador que poder´a aceder a todas as funcionalidades

dis-ponibilizadas pela aplica¸c˜ao;

• Professor: utilizador respons´avel por gerir as suas turmas e os seus alunos,

com a possibilidade de marcar avalia¸c˜oes;

• Aluno: utilizador que poder´a ter a possibilidade de participar nos jogos a que

se encontra inscrito;

• Visitante: utilizador n˜ao registado com possibilidade de acesso ao jogo de

demonstra¸c˜ao e rankings.

O sistema dever´a ainda disponibilizar diferentes modos de jogo, sendo estes:

• Demonstra¸c˜ao: jogo que dever´a ser disponibilizado a qualquer utilizador;

(52)

• Treino: permite aos alunos selecionar as mat´erias presentes no jogo; • Avalia¸c˜ao: jogo criado pelos professores para as suas turmas;

• Competi¸c˜ao: principal modo de jogo em que os alunos competem entre si.

Para os utilizadores do tipo administrador e professor, deverão ainda ser definidas as suas permissões, de modo a aferir quais os utilizadores autorizados a gerir in-forma¸cões sobre as perguntas, bem como os que são autorizados a iniciar o modo de competi¸cão.

Para implementa¸cão do matUTAD, de forma a respeitar os princ´ıpios da Engenha-ria de Software, que visa pelo desenvolvimento de software com elevada qualidade, eficiência e fiabilidade, torna-se necessário efetuar as seguintes etapas, em conjunto com a disserta¸c˜ao de mestrado referente ao projeto do front end do matUTAD [31]:

3.1 Arquitetura da Aplica¸

c˜

ao

O desenvolvimento da aplica¸c˜ao web, ser´a de acordo com o padrão de arquitetura de software Model-View-Controller (MVC), onde são definidos três componentes, como representado na Figura 3.1:

1. Model : cont´em o núcleo funcional da aplica¸cão, responsável por encapsular os seus dados disponibilizando os métodos que podem ser utilizados no processa-mento dos mesmos. Os dados processados por este componente são transpa-rentes da sua apresenta¸cão, permitindo que m´ultiplas views possam solicitar os mesmos dados.

2. Controller : controla as intera¸c˜oes entre a view e o model, uma vez que ´e da sua responsabilidade receber os pedidos dos utilizadores, traduzi-los em a¸c˜oes que podem ser realiz´aveis pelo model e gerar as respetivas respostas com os dados que lhe forem retornados.

(53)

3.2. LEVANTAMENTO DE REQUISITOS 29

Figura 3.1 – Componentes do padr˜ao de aquitetura MVC [1].

3. View : respons´avel por apresentar os dados ao utilizador.

´

E de notar que, os componentes que serão implementados nesta disserta¸cão são o

Model e Controller, sendo que, a View ´e projeto de desenvolvimento do front end do matUTAD [31].

3.2 Levantamento de Requisitos

O levantamento de requisitos consiste em compreender as necessidades do cliente, onde s˜ao especificadas todas as funcionalidades do sistema. Este processo foi re-alizado atrav´es da utiliza¸c˜ao de User Stories de Agile Modeling, com a estrutura representada na Figura 3.2.

As User Stories desenvolvidas para o matUTAD, encontram-se apresentadas na Subseçcão 3.2.1. De modo a melhor visualiza¸cão, foram adaptadas ao formato de tabela, na Subseçcão 3.2.2(Tabelas 3.1, 3.2, 3.3,3.4 e3.5).

(54)

Figura 3.2 – Estrutura de uma user story.

3.2.1 User Stories para o matUTAD

Visitante

• Como visitante eu posso aceder/come¸car o modo de demonstra¸c˜ao:

– Como visitante eu preciso de especificar o ano de escolaridade do jogo de

forma a iniciar o modo de demonstra¸c˜ao.

• Como visitante eu posso consultar o ranking das competi¸c˜oes.

Utilizador Registado (Aluno, Professor, Administrador)

• Como utilizador registado eu preciso de efetuar o login atrav´es do username e password para aceder aos conte´udos privados.

Aluno

• Como aluno eu posso aceder `as p´aginas do jogo;

• Como aluno eu posso jogar os modos de avalia¸c˜ao e competi¸c˜ao nos quais me

encontro registado;

• Como aluno posso jogar o modo de treino:

– Como aluno eu posso especificar os m´odulos de quest˜oes de forma a filtr´ a-las para o modo treino;

• Como aluno eu posso consultar os rankings referentes aos modos de jogo

(55)

Professor

• Como professor eu posso registar novos alunos:

– Como professor para registar um novo aluno eu necessito de especificar

os seus parˆametros (email, nome, escola, turma, ano de escolaridade);

• Como professor eu posso editar os parˆametros do aluno (email, nome, escola,

turma, ano de escolaridade, estado);

• Como professor eu posso inscrever alunos para avalia¸cões e competi¸cões; • Como professor eu posso consultar os rankings das avalia¸cões e competi¸cões; • Como professor eu posso ver a lista dos meus alunos;

• Como professor eu posso iniciar/terminar uma avalia¸c˜ao/competi¸c˜ao.

Administrador

• Como administrador eu posso registar professores:

– Como administrador para registar um novo professor eu preciso de

espe-cificar os seus parˆametros (estado, email, nome, permiss˜oes para gerir as perguntas, permiss˜oes para iniciar o modo de competi¸c˜ao, escola, turma);

• Como administrador eu posso editar os parˆametros dos utilizadores; • Como administrador eu posso criar competi¸c˜oes:

– Como administrador para criar uma nova competi¸c˜ao eu preciso de espe-cificar os seus detalhes;

• Como administrador eu posso iniciar competi¸c˜oes;

(56)

Utilizadores com permiss˜oes de gest˜ao de perguntas

• Como gestor de perguntas eu posso consultar a lista de perguntas; • Como gestor de perguntas eu posso editar os parˆametros das perguntas; • Como gestor de perguntas eu posso criar novas quest˜oes:

– Como gestor de perguntas para criar uma nova pergunta eu necessito de

especificar os seus parâmetros (texto da questão, estado, dificuldade, ano de escolaridade, módulos, autor, imagem);

• Como gestor de perguntas posso criar um novo m´odulo de perguntas.

3.2.2 User Stories em Formato de Tabelas

Quem? O quê? Porquê? Informa¸cão Adicional

Aluno Log In Aceder a conteúdos restritos Obrigatoriedade de introduzir username e password. Aceder à página de jogo — —

Jogar um jogo — Modo de treino permite a escolha dos módulos de questões. Ava-lia¸cões e competi¸cões são apenas acedidas por alunos que se encon-trem registados nas mesmas. Consultar

ran-kings

— Avalia¸c˜ao e Competi¸c˜ao.

(57)

Quem? O quê? Porquê? Informa¸cão adicional

Administrador

Log In Aceder a

conte´udos restritos

Obrigat´orio especificar username e password.

Registar novos professores

— Especifica¸cão obrigatória de: es-tado, email, nome, escola, turma e permissões para gerir perguntas e iniciar competi¸cões.

Editar parˆametros do utilizador

— Os parˆametros dispon´ıveis depen-dem do tipo de utilizador.

Criar

com-peti¸c˜oes

— Especifica¸cão obrigatória dos seus parâmetros (ano de escolaridade, nome, data, dura¸cão, jogo em pa-res, número de questões e número de tentativas por jogo).

Iniciar Com-peti¸c˜oes

— Requer permiss˜ao para iniciar competi¸c˜oes.

Consultar lista de utilizadores

— —

Tabela 3.2 – Tabela de user stories do administrador

Quem? O quê? Porquê? Informa¸cão Adicinal

Visitante

Aceder ao modo demonstra¸c˜ao

— Especifica¸c˜ao obrigat´oria do ano de escolaridade.

Consultar

ranking das competi¸c˜oes

— Apenas das competi¸c˜oes marca-das como vis´ıveis por um admi-nistrador.

(58)

Quem? O quê? Porquê? Informa¸cão adicional Gestor Consultar lista de perguntas — — de Editar parâmetros das perguntas — — Perguntas

Criar novas per-guntas

— Obrigatoriedade de introduzir: texto da pergunta, estado, di-ficuldade, ano de escolaridade, m´odulo, autor e imagem.

Criar novos

m´odulos

— —

Tabela 3.4 – Tabela de user stories para utilizadores com permiss˜oes de gest˜ao de perguntas

Quem? O quˆe? Porquˆe? Additional Info

Professor Log In Aceder a conte´udos restritos Obrigatoriedade de introduzir username e password. Registar novos alunos

— Especifica¸c˜ao obrigat´oria dos se-guintes parˆametros: email, name, escola, turma e ano atual de esco-laridade.

Editar os

parˆametros do aluno

— Parˆametros dispon´ıveis: email,

nome, escola, turma, ano atual de escolaridade e estado.

Consultar lista de alunos

— Apenas s˜ao apresentados os seus alunos.

Come¸car ava-lia¸c˜oes e com-peti¸c˜oes

— Iniciar o modo de competi¸cão é exclusivo para utilizadores com essa permissão.

(59)

3.3. DIAGRAMA ENTIDADE-RELACIONAMENTO (E-R) 35

3.3 Diagrama Entidade-Relacionamento (E-R)

Os Diagramas de Entidade-Relacionamento permitem descrever toda a estrutura l´ogica da base de dados, em que os seus elementos principais s˜ao [24]:

1. Entidade: representa um conjunto de objetos (concreto ou abstrato) com ca-racter´ısticas comuns entre si;

2. Atributo: a cada entidade, ou relacionamento, podem estar associados um ou mais atributos que representam as suas propriedades elementares;

3. Relacionamento: associa¸c˜oes entre as entidades, classificados de acordo com o n´umero de objetos que participa em cada um dos lados do relacionamento:

I Relacionamento 1...1 (um para um); II Relacionamento 1...* (uma para muitos); III Relacionamento *...* (muitos para muitos).

Figura 3.3 – Ilustra¸c˜ao dos componentes que constituem um Diagrama E-R.

Tal como ilustrado na Figura3.3, no Diagrama ER as entidades possuem uma chave prim´aria (tipicamente o ID, tamb´em designada por Primary Key ), respons´avel por

(60)

identificar, de forma inequ´ıvoca, uma determinada instância. De forma a relacionar as tabelas entre si, surge a chave estrangeira (Foreign key ) caracterizada como um atributo referente à chave primária de outra tabela. Na Subseçcão3.3.1encontra-se a representa¸cão do Diagrama E-R implementado para o matUTAD (Figura 3.4) e respetiva explica¸cão através da sua parti¸cão em blocos.

(61)

3.3.1 Diagrama E-R para o matUTAD

(62)

A Figura3.5mostra o modo como a diferencia¸cão entre os vários tipos de utilizadores ocorre, onde podemos constatar a rela¸cão de heran¸ca entre as entidades envolvidas. A entidade user representa a tabela onde s˜ao armazenadas as informa¸cões comuns a todos os utilizadores (tais como nome, email, permiss˜oes etc), sendo as entidades

administrator (administrador), teacher (professor) e student (aluno) respons´aveis por especificar o seu tipo.

Figura 3.5 – Utilizadores do matUTAD.

Os administradores serão responsáveis por efetuar o registo das escolas no matU-TAD, tornando-se assim necessário a cria¸cão desta entidade (Figura3.6). As escolas contêm vários professores, no entanto, um professor poderá estar associado a mais do que uma escola, sendo este relacionamento caracterizado por uma cardinalidade de muitos para muitos. Por esta razão, torna-se necessária a cria¸cão de uma entidade associativa de forma a mapear os objetos envolvidos no relacionamento. Na Figura 3.7´e poss´ıvel observar a entidade SchoolTeacher, que ser´a responsável por realizar o mapeamento entre os professores e as suas escolas, através das chaves estrangeiras

(63)

Figura 3.6 –

Ta-bela Escola.

Figura 3.7 – Entidades Professor, Escola e

Relacionamento entre si.

O professor ser´a respons´avel por registar as suas turmas, representadas pela enti-dade Class na Figura 3.8. Para uma determinada Turma, de modo a determinar o seu professor e respetiva escola, na entidade Class podemos ainda observar os atributos idTeacher e idSchool (chaves estrangeiras das entidades Escola e Professor respetivamente).

Figura 3.8 – Entidade Turma e Rela¸c˜oes com Professor e Escola.

Sendo a gestão das turmas realizadas pelo respetivo professor, este será responsável por efetuar o registo dos alunos nas mesmas, tornando-se desta forma necessário especificar os parˆametros turma (idClass), aluno (idStudent ) e in´ıcio do ano letivo (beginning year ). De forma a armazenar o hist´orico das turmas de um determinado aluno, surge a entidade ClassStudentYear, ilustrada na Figura 3.9, responsável por

(64)

armazenar os atributos anteriormente descritos.

Figura 3.9 – Tabela ClassStudentYear e Relacionametos com Aluno e Turma.

Na cria¸cão de uma nova questão torna-se necessário especificar os seus parâmetros, entre os quais, autor (Figura3.10(a)) e módulos (3.10(b)). Na Figura3.11é poss´ıvel observar a entidade Question e respetivos atributos. ´E ainda observável a entidade

QuestionModule, respons´avel por guardar quais os m´odulos associados a uma deter-minada quest˜ao (idModule, idQuestion).

(65)

(a) Tabela Autor. (b) Tabela M´odulo.

Figura 3.10 – Tabelas Autor e M´odulo.

(66)

No matUTAD, a cada pergunta irá estar associado um conjunto de afirma¸cões, re-presentadas pela entidade Statement na Figura 3.12 onde são armazenadas as suas informa¸cões, tais como, a pergunta `a qual se encontra associada (idQuestion), o texto da afirma¸c˜ao (statementText ), estado (active) etc.

Figura 3.12 – Tabela Afirma¸c˜ao e Relacionamento com Pergunta.

Na Figura3.13podemos observar alguns parâmetros que deverão ser especificados na cria¸cão de um jogo, como por exemplo o seu tipo (avalia¸cão, competi¸cão ou treino), representado pelo atributo idGameType na entidade Game, e quais os m´odulos de matérias que dever˜ao estar presentes no mesmo (entidade GameModules).

Se o jogo criado corresponder a uma avalia¸cão deverá ser especificada a turma que irá ser avaliada (atualiza¸c˜ao da entidade TeacherGame). Caso corresponda a uma competi¸cão, deverá ser efetuada a inscri¸cão dos alunos na mesma, sendo estas in-forma¸c˜oes guardadas na entidade StudentGame (as entidades anteriormente referi-das encontram-se representareferi-das na Figura 3.14).

(67)

Figura 3.13 – Tabela Jogo e Relacionamentos com Tipo e M´odulos.

(68)

De modo a que o sistema possa guardar informa¸cões sobre os jogos já realizados, surge a entidade Playing, ilustrada na Figura 3.15. Esta está encarregue de armaze-nar informa¸cões como a pontua¸cão e datas de in´ıcio e final do jogo. Porém, a entidade que permite determinar os jogos realizados por um aluno ´e a StudentPlaying.

Figura 3.15 – Tabela Playing e StudentPlaying.

O sistema deverá ainda armazenar as perguntas atribu´ıdas a um determinado jogo, as suas afirma¸cões e respetivas respostas. Na Figura 3.16 podemos observar as entidades GameQuestions e GameQuestionStatements onde s˜ao armazenadas as in-forma¸cões anteriormente referidas.

(69)

Figura 3.16 – Tabelas por guardar informa¸c˜oes no decorre de um jogo (GameQuestion e

(70)

3.4 Diagramas Casos-de-Uso

Os Diagramas Casos-de-Uso consistem na representa¸c˜ao simplificada das funcionali-dades de cada utilizador (Ator), constitu´ıdos pelos seguintes componentes (ilustrado na Figura 3.17) [41]:

• Atores: algu´em ou algo que interage com o sistema;

• Casos-de-uso: funcionalidades disponibilizadas pelo sistema;

• Relacionamentos: respons´aveis por definir o tipo de intera¸c˜oes entre os

dife-rentes componentes do sistema, podendo destacar-se os seguintes: 1. Association: relacionamento entre atores e casos-de-uso;

2. Generalization: relacionamento utilizado quando v´arios atores e/ou casos-de-uso tˆem algo em comum;

3. Include: permite indicar que um case-de-uso utiliza as funcionalidades disponibilizadas por outro caso-de-uso;

4. Extend : permite a um caso-de-uso a possibilidade de aumentar as suas funcionalidades recorrendo a outro caso-de-uso.

(71)

3.4. DIAGRAMAS CASOS-DE-USO 47

A Figura 3.18 encontram-se representadas as funcionalidades dispon´ıveis para um utilizador n˜ao registado, tais como iniciar o modo de demonstra¸c˜ao e consultar

rankings.

Figura 3.18 – Casos de Uso para o Visitante.

Aos alunos o sistema deverá disponibilizar um conjunto de servi¸cos, destacando a configura¸c˜ao do seu perfil, consulta de rankings, jogar o modo de treino, iniciar avalia¸cões e competi¸cões nas quais se encontra registado. A Figura 3.19 ilustra o Diagrama de Casos-de-Uso afeto aos alunos.

(72)

O administrador será um utilizador com acesso a todos os servi¸cos disponibilizados pela aplica¸cão, entre os quais o registo e elimina¸cão de utilizadores, marca¸cão de competi¸cões etc (Figura 3.20).

Figura 3.20 – Casos de Uso para o Administrador.

Os professores serão responsáveis por efetuar a gestão das suas turmas e alunos, com possibilidade de marcar avalia¸cões. Nas Figuras3.21 e3.22 encontram-se represen-tadas todas as funcionalidades que deverão ser disponibilizadas a um utilizador deste tipo.

(73)

3.4. DIAGRAMAS CASOS-DE-USO 49

Figura 3.21 – Casos de Uso para o Professor (Parte 1).

(74)

Um utilizador com permissões de gestão de perguntas será responsável por introdu-zir, editar e eliminar os autores, módulos, perguntas e afirma¸cões, funcionalidades representadas na Figura 3.23.

Figura 3.23 – Casos de Uso para Utilizadores com permiss˜oes de Gest˜ao de Perguntas.

3.5 Diagrama de Classes

O Diagrama de Classes, consiste numa representa¸cão da estrutura e rela¸cões das classes que servem de modelo para objetos, em que os relacionamentos entre si poderão ser [42]:

• Associa¸c˜ao: relacionamento formado entre objetos durante o funcionamento

do sistema.

• Multiplicidade: permite especificar quantos objetos participam numa rela¸c˜ao,

ou seja, o n´umero de instˆancias de uma classe que se pode relacionar com uma ´

unica instˆancia de outras classes participantes.

• Heran¸ca: refere-se `a capacidade de uma sub-classe herdar os atributos e m´etodos

(75)

3.5. DIAGRAMA DE CLASSES 51

• Agrega¸cão: responsável por representar uma rela¸cão do tipo ”é parte de”, em

que o ciclo de vida da parte ´e independente do ciclo de vida do todo

• Composi¸cão: este relacionamento é uma variante da agrega¸cão, responsável

por representar uma dependência entre duas classes (se o todo deixar de existir, a parte também irá deixar).

Figura 3.24 – Ilustra¸c˜ao de um diagrama de classes e respectivas rela¸c˜oes.

Tendo em conta o levantamento de requisitos e o Diagrama E-R do matUTAD, torna-se necessário a realiza¸cão do Diagrama de Classes adequado à representa¸cão dos dados na troca de mensagens entre clientes e servidor. O Diagrama de Classes que foi implementado para o matUTAD encontra-se apresentado na Subseçcão3.5.1.

(76)