Observac¸ ˜ oes

Implementac¸ ˜ao

Conte ´udo

Neste cap´ıtulo ´e descrito o sistema que satisfaz a maioria dos requisitos que constam no cap´ıtulo2, sendo que aqueles que n ˜ao s ˜ao cumpridos, s ˜ao no cap´ıtulo5abordados.

4.1 Arquitetura do sistema

Como referido no cap´ıtulo 2, na secc¸ ˜ao 2.3, esta plataforma ser ´a composta por 2 m ´odulos. Cada m ´odulo ´e composto pelo seu dom´ınio e servic¸os, que culminam na concretizac¸ ˜ao dos casos de uso anteriormente ditos. A Figura4.1, mostra a organizac¸ ˜ao por camadas da plataforma implementada.

Figura 4.1: Arquitetura em camadas da plataforma desenvolvida.

Por ordem ascendente (comec¸ando de baixo para cima), as camadas s ˜ao:

1. Django Framework1– Permite o desenvolvimento fullstack de aplicac¸ ˜oes web, recorrendo `a lin-guagem de programac¸ ˜ao python. Este ´e respons ´avel pela persist ˆencia da informac¸ ˜ao na plata-forma, assim como parte da seguranc¸a da autenticac¸ ˜ao (sendo a restante assegurada pelo CAS do IST) e da sanitizac¸ ˜ao das respostas dadas, salvaguardando o bem-estar da base dados e da ferramenta. Possui ainda mecanismos de envio de emails, formac¸ ˜ao de grupos com permiss ˜oes de adicionar, ver, modificar e apagar elementos dos diversos dom´ınios e criac¸ ˜ao de p ´aginas de apresentac¸ ˜ao din ˆamicas (atrav ´es de Jinja e da p ´agina administrativa);

2. Celery2 – Escalonador utilizado em projetos concebidos em Django, respons ´avel pelo agenda-mento e execuc¸ ˜ao das tarefas ass´ıncronas;

3. Fenix Python SDK3– Respons ´avel por aceder aos endpoints do sistema de informac¸ ˜ao do IST (F ´enix);

1Docoumentac¸ ˜ao: https://docs.djangoproject.com/en/2.2/

2Documentac¸ ˜ao: https://docs.celeryproject.org/en/stable/

4. GUC – M ´odulo que permite a gest ˜ao de utilizadores e conte ´udo. Mais detalhes na secc¸ ˜ao2.3.1; 5. GRQ – M ´odulo que permite a gest ˜ao de respostas e question ´arios. Mais detalhes na secc¸ ˜ao

2.3.2;

6. WebApp – Corresponde `a camada de apresentac¸ ˜ao, com a qual o utilizador interage. Esta ´e a

combinac¸ ˜ao de p ´aginas administrativas com p ´aginas criadas de raiz de modo din ˆamico, recor-rendo a Jinja⁴e Bootstrap⁵.

Como referido no in´ıcio da enumerac¸ ˜ao anterior, o processo de autenticac¸ ˜ao da plataforma resulta num dividir de responsabilidades entre o Django e o CAS, sendo que a maior parte da responsabilidade

recai sobre o CAS. Sendo o CAS um mecanismo que permite a qualquer pessoa com um IST-ID6

v ´alido, usufruir dos servic¸os do IST (como por exemplo, email e F ´enix), este ser ´a respons ´avel, atrav ´es da Fenix Python SDK, garantir que se trata de uma pessoa do IST invocando o url de autenticac¸ ˜ao. Caso o processo de autenticac¸ ˜ao tenha sucesso, ´e de seguida criado um objeto User na base de dados, com informac¸ ˜ao relativa ao utilizador7. A informac¸ ˜ao recolhida neste processo diz respeito ao primeiro e ´ultimo nome, o seu IST-ID e o seu papel (aluno ou docente) dentro da faculdade.

Sendo o processo de autenticac¸ ˜ao assegurado pelo CAS e sendo uma ac¸ ˜ao insegura e incorreta guardar a informac¸ ˜ao de log in (IST-ID e palavra-chave), ´e criado no lado da aplicac¸ ˜ao um ”remote user”8, sendo respons ´avel pela sess ˜ao de utilizador na plataforma, com a informac¸ ˜ao referida anteri-ormente. Consoante o papel do utilizador, ´e posteriormente criado um docente ou aluno, sendo de seguida acedido/preenchido o resto da informac¸ ˜ao que ´e pedida na secc¸ ˜ao 4.2 (como por exemplo, plano curricular e curso).

Dado que um aluno ou um docente podem ter alterac¸ ˜oes no seu plano curricular em qualquer ins-tante, como por exemplo, ficar a lecionar uma nova UC(docente ou aluno-docente), ou inscrever-se noutra UC (aluno), ´e necess ´ario consultar a informac¸ ˜ao nos respetivos endpoints e atualiz ´a-la caso haja necessidade. Para que n ˜ao seja atualizada constantemente a informac¸ ˜ao sempre que um utiliza-dor fac¸a log in, foi programado para que a cada 15 dias ap ´os ´ultimo log in, seja feita uma comparac¸ ˜ao da informac¸ ˜ao nos endpoints, com a que consta na base dados e caso seja d´ıspar, atualiz ´a-la. Esta vari ´avel encontra-se no ficheiro “choices.py”, com o nome “UPDATE DAYS”.

Relembrando os utilizadores que constam na secc¸ ˜ao2.3, n ˜ao ´e feita a refer ˆencia nem a funcion ´arios, nem aos alunos Alumni⁹. Uma vez que para o endpoint do aluno, ser Alumni ´e uma propriedade, n ˜ao basta verificar se ´e aluno e recolher a informac¸ ˜ao do mesmo. Caso este seja Alumni, ´e necess ´ario

4Gerador de templates usado no django - https://jinja.palletsprojects.com/en/2.11.x/

5Framework utilizada para desenvolvimento de componentes da interface do frontend - https://getbootstrap.com/

6Identificador ´unico atribu´ıdo a estudantes, professores e funcion ´arios da faculdade

7Atrav ´es do endpoint https://fenix.tecnico.ulisboa.pt/api/fenix/v1/person

8https://docs.djangoproject.com/en/3.0/howto/auth-remote-user/

redirecion ´a-lo e condicionar o seu acesso `a plataforma, pois esta ´e uma plataforma para docentes e alunos que ainda estejam inscritos e frequentem a faculdade com UCs. Caso um funcion ´ario tente aceder `a plataforma, este ser ´a igualmente redirecionado. Esta detalhe que pode visto como uma falha de seguranc¸a ´e encontrado em outras plataformas desenvolvidas para o IST, que apenas verificam se s ˜ao alunos, como por exemplo a aplicac¸ ˜ao de reservas do shuttle, possibilitando a Alumni usufruir das reservas.

No que diz respeito ao Fenix Python SDK, este foi pela ´ultima vez atualizado em 2015, tendo perma-necido com erros. De modo a que a arquitetura apresentada fosse execut ´avel, foi necess ´ario proceder `a correc¸ ˜ao local deste SDK, tendo colocado os endpoints a aceder corretamente ao ano acad ´emico inserido, em vez de aceder sempre ao instante atual. Foi ainda corrigido a chamada a func¸ ˜oes com os devidos par ˆametros. Este problema surgiu duas vezes, uma durante a fase local e outra quando colocada a ferramenta em modo de produc¸ ˜ao. A correc¸ ˜ao ao SDK encontra-se num ficheiro .rar, em conjunto com o c ´odigo. Do conjunto de endpoints existentes10estes foram os principais utilizados e os respetivos campos acedidos:

1. GET /degrees11- ’acronym’, ’name’, ’id’, ’academicTerm’, ’teachers’ e ’type’;

2. GET /degrees/{id}12- ’teachers’ (’{id}’ refere-se ao id do curso);

3. GET /degrees/{id}/courses13- ’acronym’, ’name’, ’id’ e ’academicTerm’ (’{id}’ refere-se ao id do curso);

4. GET /course/{id}/students¹⁴- ’enrolmentCount’, ’attendingCount’ e ’students’ (’{id}’ refere-se ao id da disciplina);

5. GET /person15- [PRIVADO] ’username’, ’name’ e ’institutionalEmail’;

6. GET /person/curriculum16- [PRIVADO] ’start’, ’end’, ’degree’ e ’acronym’;

7. GET /person/courses17- [PRIVADO] ’name’ e ’acronym’.

10Lista dos endpoints: https://fenixedu.org/dev/api/

11https://fenixedu.org/dev/api/#get-degrees 12https://fenixedu.org/dev/api/#get-degreesid 13https://fenixedu.org/dev/api/#get-degreesidcourses 14https://fenixedu.org/dev/api/#get-coursesidstudents 15https://fenixedu.org/dev/api/#get-person 16https://fenixedu.org/dev/api/#get-personcurriculum 17https://fenixedu.org/dev/api/#get-personcourses

4.1.1 Gest ˜ao de Utilizadores e Conte ´udo

Como referido previamente na secc¸ ˜ao2.3.1, este m ´odulo/camada ´e respons ´avel pela gest ˜ao/importac¸ ˜ao da informac¸ ˜ao relativa aos cursos, UCs, docentes e alunos. Atrav ´es dos endpoints enumerados ante-riormente, ´e poss´ıvel construir o dom´ınio principal da plataforma, obtendo-se o diagrama em Unified Modeling Language (UML) [3] conforme a Figura4.2.

Na Figura 4.2. ´e poss´ıvel visualizar-se o que foi referido neste cap´ıtulo relativamente ao “remote user”, sendo apresentado na imagem como o objeto “DjangoUser”. Por sua vez este tem uma relac¸ ˜ao “one-to-one” com o objeto “Person”, garantindo desta forma que uma pessoa (“Person”) aceda `a plata-forma, se for um Aluno ou docente da comunidade doIST.

No papel de administrador, este ´e capaz de importar toda a informac¸ ˜ao relativa aos cursos (“De-gree”) que existem noIST. Posteriormente, este pode importar todas UCs (“Course”), que s ˜ao perten-centes aos respetivos cursos. ´E importante destacar que algumas UCs, s ˜ao partilhadas entre cursos, tendo o mesmo nome e URL. Ou seja, a mesmaUC, pode pertencer a um ou mais cursos. Este as-peto faz com que n ˜ao possa haver uma reac¸ ˜ao de “cascade” quando eliminado um curso, pois aUC tem que se manter caso pertenc¸a a outro curso. Por esta raz ˜ao, na Figura4.2 ´e vista a cardinalidade entre “Degree” e “Course” como zero ou mais, possibilitando deste modo a exist ˆencia independente de ambos os objetos.

O objeto “Person” ´e respons ´avel por conter a informac¸ ˜ao relativa ao primeiro e ´ultimo nome, assim como o IST-ID. Como ´e observado na Figura 4.2, existe uma relac¸ ˜ao de hierarquia, pois tanto um “Teacher”, como um “Student”, s ˜ao “Person”.

Durante a concec¸ ˜ao da plataforma, observou-se que um docente (“Teacher”), pode coordenar zero ou mais cursos, assim como um Curso (“Degree”), pode ter mais que um coordenador, algo que foi contra a modelac¸ ˜ao inicial e resultou em problemas na primeira implementac¸ ˜ao.

Um aluno (“Student”), est ´a associado a um conjunto de UCs ao qual est ´a inscrito, sendo vis´ıvel na Figura 4.2, pela ligac¸ ˜ao representada por “Classes”. No entanto, uma vez que a plataforma ir ´a enviar emails aos alunos das UCs e estes podem n ˜ao querer ser incomodados pelas notificac¸ ˜oes da plataforma, estes podem ou n ˜ao estar subscritos `as notificac¸ ˜oes, sendo que inicialmente, todos os alunos est ˜ao subscritos a todas as UCs a que est ˜ao inscritos.

Um aluno pode conter duas responsabilidades adicionais dentro doIST. Este pode ser um delegado (representado por um booleano) ou ser um aluno-docente. Caso este seja um aluno-docente, ter ´a uma relac¸ ˜ao semelhante `a dos docentes, referente `as UCs que ´e respons ´avel, denominada “Teaching”.

Cada UC pode conter ou n ˜ao elementos de avaliac¸ ˜ao (“Evaluation”). Quando esta tem um ele-mento de avaliac¸ ˜ao, ´e automaticamente criado um question ´ario correspondente ao tipo do eleele-mento de avaliac¸ ˜ao. Na Figura 4.2, ´e poss´ıvel observar-se dois rect ˆangulos verdes, que dizem respeito a duas enumerac¸ ˜oes, uma para o tipo de avaliac¸ ˜oes que existem (“EvaluationType”) e outra para o estado do

question ´ario (“QuizStatus”). Acrescentado o estado de ”Finalizado”ao restantes estados referido na secc¸ ˜ao 2.1.2, no que diz respeito ao c ´odigo, estes podem ser visto no ficheiro ”choices.py”, vari ´avel ”QUIZ STATES”. A restante modelac¸ ˜ao ´e melhor explicada na secc¸ ˜ao4.1.2.

4.1.2 Gest ˜ao de Respostas e Question ´arios

Como referido na secc¸ ˜ao2.3.2, este m ´odulo permite a gest ˜ao dos v ´arios elementos de avaliac¸ ˜ao e consequentemente a gest ˜ao dos diversos question ´arios. Nesta camada ´e feita uma relac¸ ˜ao com os objetos “Evaluation” e “Quiz” presentes no m ´odulo QUC, permitindo deste modo a realizac¸ ˜ao dos casos de uso presentes na Figura2.2.

´

E de salientar que o objeto “Quiz” n ˜ao tem um tipo associado, isto ´e, por exemplo, n ˜ao ´e um ques-tion ´ario do tipo exame ou projeto. Este, est ´a associado ao objeto “Evaluaques-tion”, que por sua vez tem um tipo associado. O objeto “Quiz” contem informac¸ ˜ao relativa ao estado do question ´ario, alunos que devem responder (sendo todos os alunos inscritos `a disciplina) e a data de quando alterar o seu estado para “Fechado”. O tipo associado ao elemento de avaliac¸ ˜ao, influ ˆencia a resposta dada ao question ´ario, sendo neste caso respons ´avel pelos objetos “BasicAnswer” e “SpecificAnswer”. O objeto “BasicAnswer” ´e respons ´avel por recolher a informac¸ ˜ao relativa ao curso do aluno, n ´umero de inscric¸ ˜oes, e se partici-pou ou n ˜ao naquele elemento de avaliac¸ ˜ao. Caso tenha participado no elemento de avaliac¸ ˜ao, ´e ent ˜ao apresentado as quest ˜oes relevantes para cada tipo de elemento de avaliac¸ ˜ao, ficando a cargo do ob-jeto “SpecificAnswer”, recolher essa informac¸ ˜ao. De momento, os tipos de avaliac¸ ˜ao e as respetivas perguntas s ˜ao:

1. Teste:

(a) Tempo Suficiente;

(b) Perguntas relacionadas com as pr ´aticas/te ´oricas; (c) Erros no enunciado;

(d) Coment ´arios. 2. Laborat ´orios:

(a) Tempo investido por mim; (b) Tempo investido pelo grupo; (c) Nota esperada;

(d) Tempo de laborat ´orio suficiente; (e) Tempo de laborat ´orio ´util/produtivo;

(g) Coment ´arios. 3. Projetos:

(a) Tempo investido por mim; (b) Tempo investido pelo grupo; (c) Nota esperada;

(d) Pontos fortes; (e) Pontos a melhorar;

(f) Coment ´arios.

Os ficheiros respons ´aveis pela implementac¸ ˜ao dos respetivos formul ´arios e os dom´ınios das per-guntas, s ˜ao respetivamente “forms.py” e “choices.py”. A criac¸ ˜ao de novos tipos de elementos de avaliac¸ ˜ao e os seus respetivos question ´arios, ´e simples, havendo apenas a necessidade de criar a base de dados para o novo tipo e modificar/acrescentar alguns aspetos que se encontram no Anexo Adeste documento. Devido ao facto de o Django ser fullstack, recorrendo ao Jinja e ao bootstrap, a parte de visualizac¸ ˜ao/apresentac¸ ˜ao do formul ´ario n ˜ao requer muita atenc¸ ˜ao. Com tudo, estes detalhes encontram-se no anexo mencionado.

4.2 Registo WebAPP/CAS

Como referido na secc¸ ˜ao4.1, o CAS ´e respons ´avel por garantir a autenticidade do utilizador que acede a aplicac¸ ˜ao. Para que seja poss´ıvel usufruir deste servic¸o, ´e necess ´ario registar a aplicac¸ ˜ao web no F ´enix.

Para registar a aplicac¸ ˜ao no F ´enix, ap ´os realizar log in, deve: 1. Aceder ao separador “Pessoal”18;

2. Nas opc¸ ˜oes do lado esquerdo (final da p ´agina em modo compacto), selecionar “Gerir Aplicac¸ ˜oes”; 3. De seguida clicar na opc¸ ˜ao “Criar”, surgindo um pop-up como o da Figura4.3. Neste deve indicar o nome da aplicac¸ ˜ao, uma breve descric¸ ˜ao da aplicac¸ ˜ao, o URL para redirecionar (em modo desenvolvimento e caso n ˜ao esteja alojado ser ´a http://localhost:8000) e por ´ultimo selecionar a informac¸ ˜ao que pretende aceder.

Ap ´os o registo, ´e poss´ıvel ver detalhes do registo, onde ser ´a vis´ıvel informac¸ ˜ao relativa ao “client id” e “client secret”, que ´e crucial para que possa ser usado a camada “Fenix Python SDK” e o CAS, uma

vez que o ficheiro “fenixedu.ini”, deve conter essa informac¸ ˜ao. No fim o ficheiro “fenixedu.ini” deve ter ser semelhante `a Listagem4.1.

O procedimento de registo e utilizac¸ ˜ao do servic¸o CAS para autenticidade, s ˜ao aspetos comum `as outras teses de desenvolvimento de plataformas que requerem reconhecimento dos utilizador e acesso a Endpoints. Um exemplo do referido at ´e ao instante ´e o trabalho de mestrado realizado pelo colega Jorge Sim ˜ao Madeira Cordeiro de Arag ˜ao Goulart [2].

No caso da aplicac¸ ˜ao desenvolvida, a informac¸ ˜ao que ´e poss´ıvel ter acesso ´e:

(a) Gest ˜ao planos curriculares de alunos (b) Gest ˜ao de Delegados

(c) Pagamentos

(d) Informac¸ ˜ao (e) Avaliac¸ ˜oes

(f) Curricular

Dos acessos pedidos, a linha (b), n ˜ao foi poss´ıvel aceder, pois ou n ˜ao se encontra documenta ou n ˜ao ´e de acesso publico. A informac¸ ˜ao relativa `a linha (c) e linha (e), seriam para tornar o ecr ˜a principal do aluno mais atrativo e informativo, sendo a informac¸ ˜ao relativa ao pr ´oximo teste e a pagamentos em falta. Devido `a falta de documentac¸ ˜ao do que ´e acess´ıvel em cada “scope” (Figura4.3) n ˜ao ´e clara a diferenc¸a entre linha (a) e a linha (f).