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 ´e instanciada em objetos, contribuindo desta forma para uma melhor organiza¸c˜ao do c´odigo;
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´a n˜ao s˜ao necess´arios, contribuindo desta forma, para a preven¸c˜ao de perdas de mem´oria;
• Segura: como o c´odigo Java corre no interior de uma JVM, ´e criada uma sandbox, impossibilitando que o mesmo possa executar opera¸c˜oes prejudiciais ao computador em que est´a a ser executado.
De forma a realizar uma gest˜ao mais eficiente e eficaz dos v´arios utilizadores, o mo- delo de aplica¸c˜ao Java EE define uma arquitetura para a implementa¸c˜ao de servi¸cos como aplica¸c˜oes em multicamada, isto ´e, a l´ogica da aplica¸c˜ao ´e 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 ;
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
2.5. JAVA PLATAFORM, ENTERPRISE EDITION (JAVA EE) 21
Figura 2.15 – Tecnologia HTTPServlet [37].
A HttpServlet providencia v´arios m´etodos que permitem receber pedidos efetua- dos pelos clientes, process´a-los e retornar as respetivas respostas (Figura 2.15). Quando uma Servlet ´e solicitada, a interface HttpServletRequest define um con- junto de m´etodos que permitem efetuar a extra¸c˜ao 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 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˜ao ser manipulados pelos m´etodos 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 ;
III Inicializa¸c˜ao da instˆancia atrav´es 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´aveis pelo conte´udo dinˆamico.
2.5. JAVA PLATAFORM, ENTERPRISE EDITION (JAVA EE) 23
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˜ao ´e necess´aria 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˜ao deste objeto, ´e da responsabilidade do servidor web efetuar a sua convers˜ao para uma resposta HTTP e retorn´a-la para o cliente que efetuou o pedido [21].
Contudo, o processo descrito anteriormente poder´a ser alterado atrav´es de filtros, caracterizados como objetos geridos pelo Web Container, utilizados para filtragem de pedidos, respostas, ou em ambas as situa¸c˜oes (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.
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˜ao de aplica¸c˜oes baseadas na web, carac- terizados como leves, escal´aveis, de f´acil manuten¸c˜ao [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˜ao web services RESTful com base no standard JAX-RS. Disponibiliza a sua pr´opria API, al´em das funciona- lidades do JAX-RS, permitindo assim que o programador possa usufruir de recursos adicionais no desenvolvimento da aplica¸c˜ao. Na Tabela 2.4 apresentam-se algumas anota¸c˜oes definidas pelo JAX-RS.
2.5. JAVA PLATAFORM, ENTERPRISE EDITION (JAVA EE) 25
@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.
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´es de eventos, sem qualquer dependˆencia do tempo de compila¸c˜ao. 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´avel por realizar a manipula¸c˜ao do evento de acordo com as especifica¸c˜oes definidas pelo programador, podendo posteriormente ser injetado noutra classe.
3
Conce¸c˜ao
O matUTAD ´e um jogo de Matem´atica online constitu´ıdo por 25 quest˜oes, cada uma delas com quatro afirma¸c˜oes do tipo verdadeira ou falsa, em que os utilizadores do sistema poder˜ao 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;
• 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˜ao ainda ser definidas as suas permiss˜oes, de modo a aferir quais os utilizadores autorizados a gerir in- forma¸c˜oes sobre as perguntas, bem como os que s˜ao autorizados a iniciar o modo de competi¸c˜ao.
Para implementa¸c˜ao do matUTAD, de forma a respeitar os princ´ıpios da Engenha- ria de Software, que visa pelo desenvolvimento de software com elevada qualidade, eficiˆencia e fiabilidade, torna-se necess´ario 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˜ao de arquitetura de software Model-View-Controller (MVC), onde s˜ao definidos trˆes componentes, como representado na Figura 3.1:
1. Model : cont´em o n´ucleo funcional da aplica¸c˜ao, respons´avel por encapsular os seus dados disponibilizando os m´etodos que podem ser utilizados no processa- mento dos mesmos. Os dados processados por este componente s˜ao transpa- rentes da sua apresenta¸c˜ao, 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.
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˜ao implementados nesta disserta¸c˜ao s˜ao 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 Subsec¸c˜ao 3.2.1. De modo a melhor visualiza¸c˜ao, foram adaptadas ao formato de tabela, na Subsec¸c˜ao 3.2.2(Tabelas 3.1, 3.2, 3.3,3.4 e3.5).
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 ava-
3.2. LEVANTAMENTO DE REQUISITOS 31
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˜oes e competi¸c˜oes; • Como professor eu posso consultar os rankings das avalia¸c˜oes e competi¸c˜oes; • 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;
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ˆametros (texto da quest˜ao, estado, dificuldade, ano de escolaridade, m´odulos, 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ˆe? Porquˆe? Informa¸c˜ao Adicional
Aluno Log In Aceder a conte´udos restritos Obrigatoriedade de introduzir username e password. Aceder `a p´agina de jogo — —
Jogar um jogo — Modo de treino permite a escolha dos m´odulos de quest˜oes. Ava- lia¸c˜oes e competi¸c˜oes s˜ao apenas acedidas por alunos que se encon- trem registados nas mesmas. Consultar ran-
kings
— Avalia¸c˜ao e Competi¸c˜ao.
3.2. LEVANTAMENTO DE REQUISITOS 33
Quem? O quˆe? Porquˆe? Informa¸c˜ao adicional
Administrador
Log In Aceder a
conte´udos restritos
Obrigat´orio especificar username e password.
Registar novos professores
— Especifica¸c˜ao obrigat´oria de: es- tado, email, nome, escola, turma e permiss˜oes para gerir perguntas e iniciar competi¸c˜oes.
Editar parˆametros do utilizador
— Os parˆametros dispon´ıveis depen- dem do tipo de utilizador.
Criar com-
peti¸c˜oes
— Especifica¸c˜ao obrigat´oria dos seus parˆametros (ano de escolaridade, nome, data, dura¸c˜ao, jogo em pa- res, n´umero de quest˜oes e n´umero 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ˆe? Porquˆe? Informa¸c˜ao 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.
Quem? O quˆe? Porquˆe? Informa¸c˜ao adicional Gestor Consultar lista de perguntas — — de Editar parˆametros 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˜ao ´e exclusivo para utilizadores com essa permiss˜ao.