Sistema para la gestión del reconocimiento de equivalencias entre asignaturas: aplicación web

ESCUELA T´ ECNICA SUPERIOR DE INGENIER´ IA INFORM´ ATICA GRADO EN INGENIER´ IA INFORM´ ATICA Sistema para la gesti´on del reconocimiento de equivalencias entre asignaturas: aplicaci´on web System for managing the approval of equivalence between subjects: web application Autor: Adri´an Gonz´alez Leiva [email protected] Universidad de M´alaga Tutor: Jos´e del Campo ´ Avila [email protected] Universidad de M´alaga Co-tutor: M´onica Trella L´opez [email protected] Universidad de M´alaga Tutor coordinador: Jos´e del Campo ´ Avila UNIVERSIDAD DE M´ ALAGA M´alaga, Diciembre 2016 Fecha de defensa: El Secretario del Tribunal Resumen La movilidad estudiantil es cada vez mas frecuente entre los estudiantes. El n´umero de acuerdos entre las distintas universidades crece acordemente, adem´as, son varios los programas que se ofertan para ello, tanto internacionalmente (Erasmus y ´ Unica) como nacionalmente (SICUE). El alumno que decida cursar parte de sus estudios en una universidad extranjera debe realizar numerosos tr´amites administrativos. Uno de los m´as importantes es la confecci´on del llamado acuerdo acad´emico, que contiene las asignaturas que cursar´a en la universidad de destino y aquellas que les ser´an reconocidas en su expediente acad´emico de la universidad de origen. Este acuerdo debe ser autorizado por las universidades de origen y destino, lo que implica que la programaci´on docente de cada asignatura cursada en el extranjero debe ser sometida a la evaluaci´on del profesor del ´area de conocimiento correspondiente de la universidad del alumno, que dar´a o no el visto bueno a su reconocimiento. Para la redacci´on del acuerdo acad´emico el alumno contar´a con la ayuda de un tutor, un profesor de su centro de estudios que le ayudar´a a gestionar las peticiones de reconocimientos necesarias para su acuerdo acad´emico. Actualmente, este procedimiento supone una gran carga de trabajo para todos los implicados. Este proyecto presenta la plataforma Willyfog, cuyo objetivo principal es gestionar las peticiones de reconocimiento de asignaturas, de modo que se consiga simplificar el proceso de creaci´on del acuerdo acad´emico coordinando el trabajo de los alumnos y del personal docente implicado (tutores, profesores de ´area y coordinadores de centro). Palabras clave Erasmus, SICUE, ´ Unica, equivalencias, aplicaci´on web, OAuth2, OpenId Connect, MySQL, API, PHP, Java, SBT, Play framework, Slim framework, acuerdo acad´emico 1 Abstract Nowadays, student’s mobility is more frequent among them. The number of agreements among different universities grow accordingly, what is more, there is a great deal of plans that are offered, both internationally (Erasmus and Unica) and nationally (SICUE). The student that decides to take part of their studies in a foreign university must accomplish many administrative processes. The main one is the learning agreement, that contains the subjects that the student will take in the destination and those that will be recognized in their academic record of the original university. This agreement must be authorized by both universities, what implies that the study plan of every subject that was studied in the foreign university must be examined by a professor of the knowledge area corresponding to the original university, whose decision will grant the recognition or not. In order to draw up the learning agreement, the student can be helped by his mentor, a teacher of their centre that will help him through this work flow. At present, this process involves a great deal of effort to all the parts that conforms the picture. This project presents the Willyfog platform, which main objective is to manage the petitions of recognition, in order to simplify the process of construction of the learning agreement, coordinating the work of the student and the staff that is involved (mentors, area professors and centre coordinators). Keywords Erasmus, SICUE, Unica, equivalences, web application, OAuth2, OpenId Connect, MySQL, API, PHP, Java, SBT, Play framework, Slim framework, learning agreement 2 ´ Indice Resumen 1 Palabrasclave..................................... 1 Abstract 2 Keywords ....................................... 2 1. Introducci´on 5 1.1 Programas de movilidad estudiantil . . . . . . . . . . . . . . . . . . . . . . . 5 1.1.1 Movilidad Internacional . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1.2MovilidadNacional............................ 5 1.2Motivaci´on .................................... 6 1.3 Procedimiento de un estudiante de movilidad . . . . . . . . . . . . . . . . . 6 1.4Actoresenelsistema............................... 8 1.5Estadodelarte .................................. 8 1.6Objetivos ..................................... 9 2. Especificaci´on de requisitos 11 2.1Requisitosgenerales ............................... 11 2.2.1 Inicio de sesi´on con roles . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.2.2 Base de conocimiento de equivalencias . . . . . . . . . . . . . . . . . 11 2.2.3 Seguimiento de peticiones . . . . . . . . . . . . . . . . . . . . . . . . 11 2.2 Requisitos de la aplicaci´on web . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.2.1 Registro de usuarios . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.2.2 Creaci´on de peticiones . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.2.3 Sistema de comunicaci´on . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.2.4 Moderaci´on de peticiones . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.2.5 Coordinaci´on de los centros . . . . . . . . . . . . . . . . . . . . . . . 12 3. Dise˜no e implementaci´on 13 3.1Arquitectura ................................... 13 3.1.1Basededatos............................... 14 3.1.2APIRESTful ............................... 17 3.1.3ServidorOpenID ............................. 17 3.1.4Aplicaci´onweb .............................. 17 3.1.5 Servicio externo Gravatar . . . . . . . . . . . . . . . . . . . . . . . . 18 3.2 Tecnolog´ıas usadas. Comparativa . . . . . . . . . . . . . . . . . . . . . . . . 18 3.2.1 Del tipado nulo al fuerte . . . . . . . . . . . . . . . . . . . . . . . . . 18 3.3 Dependencias del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.3.1API .................................... 19 3.3.2Aplicaci´onweb .............................. 20 3.3.3ServidorOpenID ............................. 21 3.4.Dise˜nodelaAPI................................. 21 3.4.1RESTfulvsSOAP ............................ 22 3 3.4.2Endpoints................................. 22 3.4.3Versionado................................. 23 3.5Protecci´ondelaAPI............................... 23 3.5.1Clientcredentials............................. 24 3.5.2 Authorization code . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 3.6. Dise˜no de la aplicaci´on web . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 3.6.1 Arquitectura de la aplicaci´on. MVC . . . . . . . . . . . . . . . . . . . 25 3.6.2 Integraci´on con la API . . . . . . . . . . . . . . . . . . . . . . . . . . 26 3.7 Integraci´on de OAuth2 con Javascript . . . . . . . . . . . . . . . . . . . . . 27 3.8 Inicio de sesi´on OpenID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 4. Metodolog´ıas 29 4.1.Planificaci´on ................................... 29 4.2.Pruebas...................................... 29 4.3.Documentaci´on.................................. 30 4.4.Entornodedesarrollo .............................. 32 5. Conclusiones 35 Referencias 37 Anexo 39 A.Manualdedespliegue............................... 39 I.EntornoVagrant ............................... 39 II.willyfog-api.................................. 39 III.willyfog-openid ............................... 41 IV.willyfog-web................................. 41 V.Dominios................................... 41 B.ManualdelaAPI................................. 42 C. Manual de usuario de la aplicaci´on web . . . . . . . . . . . . . . . . . . . . . 42 I. Usuario de nuevo ingreso . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 II.Iniciodesesi´on................................ 44 III. Profesores de reconocimiento . . . . . . . . . . . . . . . . . . . . . . . 50 IV. Coordinadores de centro . . . . . . . . . . . . . . . . . . . . . . . . . . 51 4 1. Introducci´on En la actualidad, la movilidad estudiantil esta en boga. Cada vez los estudiantes tienen una consciencia m´as global y encuentran una muy buena oportunidad de conocer mundo en el momento en el que cursan sus estudios superiores. Cuando un estudiante decide cursar sus estudios en el extranjero, autom´aticamente se le plantean multitud de ´ambitos en los cu´ales tendr´a que organizarse (aspectos econ´omicos, el transporte, su estancia en el extranjero, etc.). En estos aspectos, las distintas universidades (tanto nacionales como internacionales) ofrecen programas de movilidad muy diversos en los cu´ales tratan de garantizar una cierta estabilidad econ´omica mediante ayudas y acuerdos. 1.1 Programas de movilidad estudiantil La universidad de M´alaga tiene actualmente varios planes de intercambio de estudiantes disponibles. Para el inter´es de este trabajo solo vamos a tratar los tres principales, Erasmus, ´ Unica y SICUE, los cuales podemos dividir en dos grandes categor´ıas: Movilidad Internacional [1] (Erasmus y ´ Unica) y Movilidad nacional [2] (SICUE). Pasamos a detallar cada uno de ellos: 1.1.1 Movilidad Internacional En el ´ambito internacional podemos elegir tanto destinos Europeos (Erasmus) como del resto del mundo (´ Unica): Erasmus: posiblemente el plan m´as conocido entre los estudiantes. En realidad se trata de una familia de programas, tanto como para pr´acticas en el extranjero (Erasmus Pr´acticas), como para movilidad de personal docente. En lo que nos concierne, dentro de este programa se contemplan a todos los estudiantes que pretenden realizar sus estudios de educaci´on superior en un pa´ıs miembro de la Uni´on Europea cuya estancia es de entre tres y doce meses. El programa garantiza que la universidad de origen reconocer´a acad´emicamente los estudios cursados en el extranjero. ´ Unica: este programa esta dise˜nado para cubrir el intercambio de estudiantes con universidades no Europeas. Entre los destinos que contempla se encuentran: Norteam´erica, Iberoam´erica, Asia y Ocean´ıa. Este programa contempla una duraci´on de los estudios aproximada a los del plan Erasmus. 1.1.2 Movilidad Nacional En cuanto a las universidades Espa˜nolas, las universidades tambi´en tienen tratados para poder garantizar el intercambio de estudiantes. El acuerdo que se encarga de esto es el programa SICUE: 5 asignaturas de su universidad de origen y la universidad for´anea en la que ´el considera que podr´a cursar sus estudios. 2.2.3 Sistema de comunicaci´on Para facilitar la comunicaci´on de las partes en el proceso, el sistema debe de contar con un sistema de comentarios para peticiones en el que puedan ofrecer y recibir un feedback del proceso de equivalencia sobre las peticiones del sistema. 2.2.4 Moderaci´on de peticiones El sistema debe de ofrecer la posibilidad de que los profesores reconocedores moderen las distintas peticiones del sistema de forma que puedan aceptarlas o rechazarlas seg´un consideren oportuno. Cuando una petici´on sea aprobada, el sistema tiene que a˜nadir autom´aticamente la equivalencia a la base de conocimiento. 2.2.5 Coordinaci´on de los centros Para los coordinadores de centro, el sistema debe permitir que estos conozcan los profesores reconocedores que hay en su centro y qu´e asignaturas est´an reconociendo actualmente, as´ı como modificar qu´e asignaturas son aquellas que pueden reconocer. Tambi´en deben poder trazar el estado de las peticiones abiertas que ocurren en su centro. 12 3. Dise˜no e implementaci´on 3.1 Arquitectura Puesto que el sistema Willyfog esta pensado para que tenga tanto una aplicaci´on web como m´ovil, la arquitectura que hemos elegido gira entorno a una API RESTful [3] que sirve a las dos aplicaciones de toda la l´ogica necesaria. Teniendo en cuenta este detalle principal, pasamos a enumerar cada una de las partes que podemos ver en el siguiente gr´afico que representa la arquitectura del sistema: Figura 3: Arquitectura del sistema. 13 3.1.1 Base de datos Puesto que nuestra aplicaci´on debe tener una l´ogica centralizada, para servir de la misma forma a la aplicaci´on m´ovil y web, hemos elegido una sola base de datos MySQL, lo cu´al tiene sus puntos a favor y en contra. Como punto positivo tenemos un menor mantenimiento, ya que ambas aplicaciones se sirven de la misma base de datos, por lo tanto no tenemos replicaci´on de informaci´on y la persistencia esta concentrada en un solo punto. Pero no todo es positivo, el problema de esta arquitectura es que llegado grandes niveles de tr´aficos, la base de datos se convertir´ıa en un posible cuello de botella, ya que es un sistema s´ıncrono. No se perder´ıan datos, ya que se establecer´ıan copias de seguridad, pero si la elasticidad del sistema. Por sencillez, es mucho m´as r´apido establecer una sola base de datos ya que la aplicaci´on web y m´ovil comparten el mismo modelo de datos. En el caso de manejar dos fuentes de informaci´on distintas se presentar´ıa un problema a´un m´as dif´ıcil de resolver, como es el de la inconsistencia de los datos. Adem´as, llegado un punto en el que la arquitectura no permita m´as consultas simult´aneas, se podr´ıa realizar copias de la base de datos y balancear la carga entre ellas. 14 El modelo de datos En cuanto al schema, no hemos tenido que definir relaciones demasiado complejas entre las tablas que hay en el sistema. En el modelo ER podemos observar r´apidamente que las tablas m´as predominantes son aquellas que representan entidades b´asicas, como podr´ıan ser los distintos pa´ıses que alberga el sistema, o los distintos grados que ofrece una universidad. Figura 4: Diagrama ER de la base de datos (sin tablas de OAuth por simplicidad). 15 Uno de los detalles de dise˜no, que si es interesante mencionar, es la forma en la que se han modelado los distintos estados de una petici´on. Una petici´on se puede encontrar en tres estados distintos: Aceptada por el profesor de reconocimiento. Rechazada por el profesor de reconocimiento. Pendiente, una petici´on que no ha sido aceptada, ni rechazada, de hecho puede que no haya sido ni revisada. Como primera idea, se podr´ıa pensar en representar dicho estado con una cadena de texto, o un numero que tendr´ıa un significado especial dependiendo del valor que tuviese. Este mecanismo tiene un gran problema de integridad de datos, y es que si en algun momento el sistema descuida la actualizaci´on del estado, o establece un valor inconsistente, la respuesta del mismo es incierta. Con eso en mente, tratamos de evitar este problema de la siguiente forma. En nuestro sistema todas las peticiones est´an almacenadas en una tabla para tal fin. No existe ninguna columna que mantenga ninguna informaci´on sobre el estado de la misma. Para ello existen dos tablas bien diferenciadas, accepted request yrejected request que contienen los ids de aquellas peticiones que se encuentran en dicho estado. Mediante este mecanismo, ahora el estado de una petici´on se puede discernir de la siguiente forma: Una petici´on esta aceptada si su id se encuentra en la tabla accepted request. Una petici´on esta rechazada si su id se encuentra en la tabla rejected request. En cualquier otro caso, la petici´on se encontrar´a en estado pendiente. Lo m´as interesante, sin duda, es que las consultas SQL que obtienen el estado del sistema se vuelven realmente sencillas y directas. De un simple SELECT * FROM obtendr´ıamos todas las peticiones del sistemas. A base de JOIN con accepted request o rejected request podr´ıamos filtrar aquellas cuyo estado viene definido por la tabla, y con una diferencia de conjuntos, podr´ıamos obtener todas aquellas peticiones que estan pendientes. Cabe destacar que con LEFT JOINS y una peque˜na condici´on, podr´ıamos obtener el campo calculado (ya sea una cadena de texto o un valor num´erico) que nos indica el estado de una petici´on. 16 Figura 5: Diagrama ER de las tablas mencionadas. 3.1.2 API RESTful En cuanto a la l´ogica de negocio, como anteriormente se ha mencionado, se tiene que concentrar en un solo punto, es por eso que se ha decidido construir conjuntamente una API RESTful en Java. Al centralizar la base de datos, se hace natural el crear una API en torno a esta que es la encargada de leer y modificar los datos de la misma. Como valor positivo, el concentrar la l´ogica de negocio nos permite crear una funcionalidad una sola vez y compartirla en ambas aplicaciones. Esto vuelve la aplicaci´on mucho m´as mantenible en un primer estad´ıo. 3.1.3 Servidor OpenID Puesto que el sistema tiene que mantener la sesi´on de usuarios en ambas aplicaciones, y especialmente en la aplicaci´on web, decidimos crear un servidor OpenID [4] que se encargase del manejo de las sesiones. Elegimos OpenID por ser el est´andar actual para el manejo de sesiones en un sistema. Adem´as nos ofrec´ıa desde el principio un servidor OAuth2 para proteger la API (comentaremos esto m´as adelante). El hecho de extraer el manejo de sesiones a este servidor tambi´en nos permite concentrar cualquier tipo de login en un solo lugar, entrando en el concepto de Single Sign On [5] que tanto ha puesto de moda Google. El servidor esta construido con PHP con la ayuda de una librer´ıa que permite implementar el protocolo con mucha facilidad. 3.1.4 Aplicaci´on web La parte en la que se centra este trabajo es en la aplicaci´on web que tiene que ofrecer bastantes funcionalidades para los distintos roles que hay en el sistema. El hecho de extraer la l´ogica en una API convierte la aplicaci´on web en pr´acticamente un front-end que trata de guiar al usuario por los distintos flujos de trabajo que hay en el sistema. Es por ello que puesto que era una tarea mucho m´as sencilla la de renderizar vistas y hacer m´as amigable los procesos del sistema, hemos usado PHP como lenguaje 17 junto a frameworks tanto de back-end como de front-end que nos permiten crear una aplicaci´on sencilla y f´acilmente mantenible que se comunica con la API. 3.1.5 Servicio externo Gravatar En el sistema se plantea el uso de avatares para poder identificar usuarios en el sistema. El manejo de contenido est´atico (como en este caso son las im´agenes de un usuario) es un proceso bastante complejo. Hay que tener en cuenta muchos detalles a la hora de permitir la subida de ficheros por parte de un usuario: limitar el tama˜no de los ficheros, las dimensiones de las im´agenes, incluso comprobar si lo que el usuario realmente sube tiene formato de imagen. Es por ello que decidimos usar un servicio externo denominado Gravatar [6], el cual asocia a nuestro correo una imagen que se comparte por todos los sitios donde nos registremos con nuestro correo personal. Esto nos permite, en primer lugar ahorrarnos los costos tanto de servidor (para alojar las im´agenes) como de complejidad en la gesti´on de las mismas. Por otro lado tambi´en nos permite que el usuario configure f´acilmente su avatar, haciendo el uso del sistema mucho m´as amigable. 3.2 Tecnolog´ıas usadas. Comparativa En esta secci´on vamos a pasar a comentar brevemente el por qu´e de las elecciones de tecnolog´ıas que hemos ido realizando en las distintas partes del sistema, centr´andonos sobre todo en los lenguajes de programaci´on. 3.2.1 Del tipado nulo al fuerte Inicialmente elegimos PHP como lenguaje para programar la API de nuestra arquitectura. PHP tiene un t´ıpado nulo, por lo que las variables pueden referenciar a cualquier tipo de dato y este solo se conoce en tiempo de ejecuci´on, pudiendo incluso cambiar aqu´ı. Este tipado en concreto es muy propenso a errores, por lo que requiere una mayor atenci´on y testeado de las aplicaciones, y puesto que nuestra API ten´ıa que ser robusta entendimos que no era el lenguaje m´as indicado. Esto no nos hizo desechar el lenguaje, ya que hab´ıa otras partes de la aplicaci´on m´as triviales (en concreto la aplicaci´on web y el servidor OpenID) donde si era un buen candidato. En cuanto a lo que respecta al servidor OpenID, realmente que la librer´ıa que usamos estuviese escrita en PHP nos condicion´o fuertemente, por lo que tuvimos que usar el mismo lenguaje. En cambio, en la aplicaci´on web pudimos comprobar que es un candidato perfecto, ya que, como m´as adelante podremos observar, la naturaleza de la aplicaci´on, al tener 18 que comunicarse con la API, es bastante din´amica, por lo que PHP se vuelve un buen candidato. Una vez que nos dimos cuenta que lo que busc´abamos era algun tipado en concreto, tratamos de realizar la API en Scala, ya que era un lenguaje de la JVM que estaba teniendo bastante buen recibimiento en el ambiente empresarial. Aunque es un lenguaje que todav´ıa estamos aprendiendo y del cu´al tenemos bastantes puntos a favor, tuvimos que desechar su uso r´apidamente puesto que el desconocimiento relentec´ıa en gran magnitud el ritmo del desarrollo. La aparici´on del lenguaje en cierta medida nos condicion´o a usar el framework Play que permite el uso de Scala y Java de manera conjunta, y nos deja siempre una puerta abierta al salto a este lenguaje. Por ´ultimo, recordamos Java, el lenguaje que estudiamos durante la carrera, y que ofrec´ıa un tipado fuerte. Su uso empresarial es ampliamente conocido y nuestro conocimiento inicial nos permit´ıa avanzar bastante r´apido en el desarrollo. Una de las condiciones que tuvimos es que no quer´ıamos realizar una aplicaci´on totalmente monol´ıtica como podr´ıa ser una aplicaci´on empresarial Java EE, es por ello que tratamos de movernos hacia frameworks m´as modernos y que permitiese un desarrollo m´as ´agil. 3.3 Dependencias del proyecto La posibilidad de usar librer´ıas previamente creadas y testeadas por la comunidad de programadores es una gran ventaja, sobre todo a la hora de realizar un proyecto de gran complejidad. Es por ello que vamos a proceder a comentar el uso de las distintas librer´ıas en las distintas partes de la arquitectura. 3.3.1 API El ecosistema de librer´ıas en Java es bastante grande y puesto que es un lenguaje ampliamente acogido en el ambiente empresarial, la calidad de estas librer´ıas es bastante grande, es por ello que hemos usado algunos frameworks durante el desarrollo: Play Framework [7]: a d´ıa de hoy casi ning´un programador se plantea crear una aplicaci´on web desde cero con un lenguaje, normalmente se recurre al uso de alg´un framework. En nuestro caso optamos por Play ya que es un framework soportado por Lightbend [8], y que tiene un amplio abanico de casos de uso dentro de la empresa. Para nuestra API es un punto vital ya que nos provee de toda la estructura necesaria para enrutar nuestras peticiones a la API y manejarlas correctamente incluso pudiendo establecer capas de middleware (rutinas que se ejecutan en el momento entre que se recibe una petici´on y se va a manejar por la aplicaci´on). Aunque es un framework full-stack, es muy modular, por lo que se puede usar a un nivel tan m´ınimo como es el de la construcci´on de una API que sirve JSON y que no renderiza ning´un tipo de vista. Guice [9]: la inyecci´on de dependencias (DI, dependency injection) es un patr´on b´asico de dise˜no y que nosotros aplicamos en nuestra API. Puesto que la idea es 19 que el sistema maneje con facilidad un n´umero elevado de peticiones, y que nuestro sistema sea f´acilmente testeable y modular, Guice convierte la gesti´on de dependencias en una tarea muy sencilla debido a sus anotaciones. Cabe destacar que es una librer´ıa desarrollada por Google, cuyo uso es muy amplio en la industria y casi se esta convirtiendo en una librer´ıa de facto. Gson [10]: a la hora de serializar y deserializar mensajes JSON y convertirlos en objetos. Aunque Play ya incluye Jackson como librer´ıa para tal fin, encontramos que esta librer´ıa (desarrollada tambi´en por Google y con un a gran adopci´on entre la comunidad) era mucho m´as amigable a la hora de escribir serializadores personalizados para tipos de datos particulares. Sql2o [11]: para realizar consultas a la base de datos y mapear estos resultados en objetos Java. Durante el desarollo aprendimos que la base de datos se pod´ıa encargar de una gran parte de la l´ogica de negocio mediante consultas de SQL avanzadas. Adem´as observamos que SQL es ya el mejor lenguaje para manejar resultados de consultas, es por ello que descartamos el uso de un ORM (Object Relational Mapper) como Hibernate y nos encaminamos m´as al uso de esta librer´ıa que simplemente encapsula el JDBC de Java para ser m´as sencillo de usar y que permite convertir resultados de la base de datos en objetos de Java, aunque en la mayor´ıa de las ocasiones usamos listas de mapas que representan los resultados de las consultas y no mapeamos a ning´un objeto. TypeSafeConfig [12]: el manejo de variables de entorno seg´un estemos en desarollo o en producci´on es b´asico para un despliegue efectivo, y aunque Play nos provee de un buen instrumentaje para la gesti´on de las mismas, nos dimos cuenta de que cuando inyect´abamos dependencias con Guice necesit´abamos acceder a las variables de entorno, antes si quiera de que el framework entrara en juego. Es por eso que Lightbend cre´o esta sencilla librer´ıa y que nos permite acceder a las configuraciones en estad´ıos tempranos del arranque de la aplicaci´on. 3.3.2 Aplicaci´on web La aplicaci´on web tiene un cometido mucho m´as sencillo, y al usar tecnolog´ıas principalmente de front-end, necesitamos usar librer´ıas mucho menos complejas pero sin las cuales, el desarrollo del sistema seria imposible: Slim Framework [13]: el equivalente de Play en el front-end. Este framework de PHP esta orientado a crear mini aplicaciones muy sencillas y r´apidas. El framework trata de ofrecer la m´axima funcionalidad con el m´ınimo overhead para poder escribir aplicaci´ones web en PHP casi plano. Twig [15]: como gestor de plantillas, ya que es la soluci´on m´as conocida para tal fin. Laravel ofrece un un buen gestor de plantillas como es Blade, pero que no es tan modular como podr´ıa parecer en un primer momento, ya que para usarlo hay que recurrir a m´as elementos del framework. En ese aspecto Twig, adem´as de tener una sintaxis clara, permite su uso casi al costo de cero dependencias. 20 Guzzle [14]: el pilar m´as b´asico de la aplicaci´on web es la comunicaci´on HTTP con la API. Es por eso que en este sentido hac´ıa falta una buena liber´ıa que facilitase esta tarea, ya que Curl, la utilidad de facto en PHP es bastante engorrosa y compleja de usar. Es por ello que recurrimos a Guzzle, una librer´ıa bastante probada y que convierte la comunicaci´on HTTP en una tarea mucho m´as sencilla. Bootstrap [16]: en el lado m´as front-end de la aplicaci´on para poder maquetar. Bootstrap nos permite estructurar la web f´acilmente y de forma que es muy compatible con pantallas de peque˜na resoluci´on y m´oviles (aunque esta no es la principal preocupaci´on, puesto que hay una aplicaci´on m´ovil). jQuery [17]: permite un manejo del DOM de HTML muy sencillo, y crear funcionalidades complejas en el lado del cliente sin tener que recurrir a elaboradas estructuras en Javascript. Tambi´en facilita en gran medida el uso de llamadas AJAX, principales tambi´en en una aplicaci´on que en ´ultima instancia se comunica con una API. 3.3.3 Servidor OpenID En este servidor de sesiones, adem´as de las tecnolog´ıas ya mencionadas como Slim Framework (puesto que tambi´en es una aplicaci´on PHP) destaca el uso de una librer´ıa que nos permite la implementaci´on del protocolo OpenID de manera muy sencilla. La librer´ıa en cuesti´on se denomina bshaffer/oauth2-server-php [18]. Una de nuestras primeras ideas fue la de buscar un servidor OpenID que fuese stand-alone, es decir, que sirviese peticiones por si solo, pero al no encontrar ninguna soluci´on que se adaptara a nuestras necesidades, recurrimos al uso de esta librer´ıa que permite la implementaci´on r´apida y sencilla del protocolo en PHP. Con un simple schema de base de datos y un framework que sirva para enrutar las peticiones HTTP, se construye un servidor que vale tanto como servidor de autorizaci´on (OAuth2) como de sesiones (OpenID). Es importante desatacar de que tanto la aplicaci´on web como la m´ovil tiene una gesti´on de sesiones propias, y que cuando mencionamos que OpenID es un servidor de sesiones, nos referimos a que es el mismo el que decide cuando expirar las sesiones y proveer datos sobre los usuarios. Por supuesto, como se puede intuir, es el servidor OpenID el que debe encargarse de registrar usuarios en la aplicaci´on, para as´ı poder aunar el punto de entrada de los usuarios en el sistema. 3.4. Dise˜no de la API En cuanto al dise˜no de la API tuvimos pocas dudas a la hora de elegir protocolos en los que basarnos, puesto que la industria ya esta repleta de casos de ´exito para protocolos como el REST. A´un as´ı pasamos a comentar el por qu´e nos aferramos a esta decisi´on: 21 ejemplo para guardar dicho token) por lo que en nuestra aplicaci´on web le dimos otro enfoque distinto al Implicit Flow. En nuestro caso nostros hicimos que el c´odigo Javascript llamase a rutas de nuestra aplicaci´on web, como si de su propia API se tratase, y que esta a su vez si que se comunicaba con la API en ´ultima instancia. Esto nos permit´ıa dos ventajas claras: por una parte, ten´ıamos cubierta la autorizaci´on con la API, puesto que la aplicaci´on web ya es capaz de establecer una comunicaci´on segura, y por otro lado, nos permite ocultar los endpoints de la API a posibles curiosos que quisieran realizar ingenier´ıa inversa desde el c´odigo Javascript. 3.8 Inicio de sesi´on OpenID Por ´ultimo, nos queda por mencionar OpenID, el cu´al debido a que en nuestro sistema converg´ıan tanto aplicaci´on web, como m´ovil, y que desde ambas se deb´ıa de permitir el inicio de sesi´on, se tornaba un requisito indispensable. El flujo de OpenID para inciar sesi´on es pr´acticamente equivalente a Authorization Code Flow de OAuth2 (puesto que se basa en el mismo) pero con unas peque˜nas salvedades que pasamos a comentar: En el caso de Authorization Code lo que se mostraba al usuario era un formulario para dar autorizaci´on a la aplicaci´on a acceder a sus datos. En este caso, puesto que solo tenemos un sistema (aunque OpenID permite aunar incios de sesiones de varias aplicaciones) al loguear correctamente al usuario, consideramos esta como la autorizaci´on necesaria. OAuth2 provee de un access token cuando se llama al endpoint correspondiente con el authorization code. En este caso, el servidor OpenID responde con un JWT (JSON Web Token) con mucha m´as informaci´on, puesto que ademas relaciona el access token con un usuario de nuestro sistema. 28 4. Metodolog´ıas 4.1. Planificaci´on En cuanto a la planificaci´on del proyecto, hemos puesto en pr´actica una de las metodolog´ıas ´agiles que hoy est´a m´as en boga, como es SCRUM. Por ser un equipo realmente reducido (solo dos integrantes) y trabajando remotamente, divergimos ligeramente sobre la metodolog´ıa original, por eso procedemos a describir los detalles: Elegimos dos semanas como duraci´on de nuestros sprints por varias razones: – Era una duraci´on media que nos permit´ıa establecer un ritmo de desarrollo ligero, y que permit´ıa trazar cada sprint con m´as detalle, ya que no pod´ıamos establecer demasiadas tareas en tan poco tiempo. – Con esa duraci´on, en un a˜no hay aproximadamente 26 sprints, tantos, como letras en el abecedario ingl´es, lo cual nos permit´ıa asignar a cada sprint una letra, y as´ı poder ubicarlo f´acilmente dentro del a˜no. No realiz´abamos stand-ups diarias debido al car´acter remoto del desarrollo, pero si que trat´abamos de mantener reuniones casi diarias a trav´es de comunicaci´on VoIP. No hab´ıa ning´un Scrum Master puesto que solo ´eramos dos integrantes en el equipo y prefer´ıamos mantener una jerarqu´ıa horizontal. Esto nos permiti´o a ambos poder tomar el rol indirectamenre, y as´ı aprender mejor la metodolog´ıa Para ayudarnos con esta metodolog´ıa usamos JIRA como gestor de tareas, de forma que ten´ıamos siempre una pizarra disponible para trazar las tareas, y que nos permit´ıa generar gr´aficos tras un sprint, el burndown chart que nos indicaba c´omo hab´ıa ido el sprint, si nos hab´ıamos cargado demasiado de tareas, si hab´ıamos podido cumplirlas o si necesit´abamos realizar m´as funcionalidades en dicho periodo de tiempo. 4.2. Pruebas Inicialmente, nuestra intenci´on era la de seguir una metodolog´ıa TDD (Test Driven Development). R´apidamente descubrimos que nuestro desconocimiento en el capo del testeo relentec´ıa de sobremanera nuestro desarrollo, y en vez de crear un producto mucho m´as seguro, generaba un sistema que no estaba testeado completamente, y el cu´al tardar´ıa mucho m´as en ser desarrollado. Es por eso que adoptamos una posici´on mucho m´as conservadora, y dejamos de seguir esta metodolog´ıa. En su lugar, y a modo de alternativa, desarroll´abamos nuestras funcionalidades sin tests y ya que ten´ıamos un registro de las funcionalidades que desarroll´abamos en nuestros sprints, dedic´abamos los dos ´ultimos d´ıas de cada sprint en testear las funcionalidades que desarroll´abamos. 29 Esto nos permit´ıa seguir un desarrollo mucho m´as ´agil, sin dejar a un lado la estabilidad del sistema, que indudablemente ser´ıa mucho m´as alta en el caso de haber realizado tests. Pese a todo esto, el sistema ha sido desarrollado con la testeabilidad siempre en mente, mediante distintas t´ecnicas como Inyecci´on de Dependencias, etc. y al ser un proyecto Open Source esta abierto a que se escriba una suite de tests que ponga a prueba su fiabilidad. 4.3. Documentaci´on Un aspecto muy importante de la API, sobre todo desde el punto de vista de un implementador, es la de tener a mano una documentaci´on de que rutas hay disponibles y que par´ametros reciben, puesto que navegar por el c´odigo de la API para discernir estos aspectos es una tarea bastante compleja y que requerir´ıa mucho tiempo. Hay varias utilidades que nos ayudan a escribir documentaci´on sobre API RESTful y que generan luego documentos en varios formatos que pueden ser f´acilmente visualizados, pero nos quedamos con dos candidatos principales como son RAML [21] y Swagger [22], los cu´ales vamos a pasar a comentar y explicar por cu´al nos decidimos: Primeramente probamos RAML el cu´al ofrece una forma realmente c´omoda de documentar la API, que es mediante un documento YAML el cual tiene un formato especifico y que se centra en aspectos bien definidos de la API, como por ejemplo el mecanismo que ten´ıa de autorizaci´on, los distintos endpoint que ofrece, o qu´e tipo de respuestas sirve cada uno. Como punto fuerte, RAML permit´ıa una documentaci´on muy ligera pues tiene muy buenos mecanismos de reutilizaci´on y organizaci´on del documentos, como la definici´on de schemas JSON gen´ericos que pod´ıan reutilizarse a lo largo del fichero, o ejemplo de las respuestas que ofrec´ıa la API. Como caso de uso destacar que la documentaci´on de la API p´ublica de Spotify esta especificado con esta utilidad. Mas tarde, investigamos sobre Swagger el cu´al conocimos anteriormente y que ya se hab´ıa mostrado un buen candidato para ocasiones anteriores, que se presentaba como el candidato ´unico para documentar APIs, pero cuyo desventaja principal era que sus mecanismos de reutilizaci´on no eran t´an pr´acticos. En este segunda visita a la especificaci´on, la cu´al hab´ıan renovado en Agosto de este a˜no, descubrimos gratamente que de un compendio de empresas hab´ıa nacido una iniciativa denominada Open API Initiative [23] que trata de buscar un lenguaje gen´erico para especificar API, y el candidato como no pod´ıa ser de otra forma era Swagger. Es por ello, y por que los mecanismos de documentaci´on, menos peque˜nas diferencias, son realmente semejantes entre ambas utilidades (ambos documentos se pueden escribir en YAML) por lo que elegimos finalmente Swagger que ofrec´ıa una gran potencia expresiva y que apunta a convertise en el est´andar para documentar APIs RESTful. Una herramienta 30 que destacamos para la visualizaci´on es Swagger UI [24], la cual permite tanto navegar por la documentaci´on como probar los distintos endpoints directamente desde una interfaz web. RAML tambi´en tiene la API Console pero, es en este caso particular, que la de Swagger gana la batalla al estar m´as elaborada. La documentaci´on final se puede consultar en el Anexo B. Figura 6: Apariencia de la documentaci´on mediante Swagger UI. 31 4.4. Entorno de desarrollo Este es un punto interesante de este proyecto, puesto que tanto mi compa˜nero Nicolas Vargas Ortega (con quien he realizado este proyecto de forma conjunta) como yo, tenemos un punto de vista muy marcado al respecto. Durante nuestro paso por la carrera descubrimos en profundidad las tecnolog´ıas de virtualizaci´on, y descubrimos el potencial que ten´ıan a la hora de establecer entornos de prueba o sandbox que estaban totalmente aislados mediante el hipervisor de la maquina host que los conten´ıa. M´as tarde descubrimos una utilidad, cada vez m´as famosa en los entornos empresariales como es Vagrant [25]. Esta herramienta permite la gesti´on de m´aquinas virtuales de forma que partiendo de una imagen base, o cajas (como se denominan en el argot de la misma), que no son m´as que una imagen de un sistema operativo como podr´ıa ser un Linux Server, y mediante el uso de recetas, que no son m´as que scripts (los cu´ales pueden escribirse en multitud de lenguajes) que permiten definir el estado deseado de la m´aquina, en un par de sencillos comandos puedes tener un entorno de desarrollo perfectamente definido. Otro a˜nadido de esta herramienta, es que esta disponible en todas las plataformas, y mayoritariamente gracias a que la virtualizaci´on se puede realizar dede casi cualquier plataforma, se puede crear un entorno de desarrollo perfectamente definido el cu´al es totalmente transportable entre sistemas operativos como Linux, Windows u OS X. Pero una vez que empezamos a desplegar sistemas, y a bregar con sistemas que ya estaban en producci´on y que no ten´ıan un entorno de pruebas o de desarrollo bien definido, descubrimos r´apidamente la imperiosa necesidad de estas pr´acticas cuando se empieza un proyecto. De hecho, decidimos ir un paso m´as all´a, y ya que las tecnolog´ıas actuales lo permiten f´acilmente, establecimos que nuestros entornos de desarrollo tienen que ser casi equivalentes a quellos que encontramos en producci´on. Esta afirmaci´on se basa en varios puntos. En primer lugar gracias a la virtualizaci´on, no es dif´ıcil conseguir que nuestro sistema operativo (siempre Linux) en desarrollo sea el mismo que el que encontraremos en producci´on. Adem´as, y esto se vuelve bastante necesario en lenguajes como PHP, el sistema depende en gran medida de los paquetes y modulos que hayan instalado en el mismo, es por eso que los scripts que provisionan nuestra m´aquina virtual se escriben en BASH y de forma independiente a la m´aquina virtual, para que de esa forma puedan ser usados tanto en desarollo como en producci´on. Esto nos permite que ambos entornos (desarrollo y producci´on) sean im´agenes casi especulares, y que cuando se sufre alg´un cambio, ya sea la instalaci´on de un nuevo paquete en el sistema, o una nueva utilidad, esta misma se tiene que trasladar al etorno gemelo, para poder estudiar y convivir con las consecuencias que su a˜nadido puede conllevar. Por ´ultimo, otra utilidad que nos facilita de sobremanera el desarrollo y testeo de 32 aplicaciones es Docker [26]. Con esta herramienta, podemos establecer procesos que son facilmente manejables y que no tienen persistencia de datos (a menos que se indique lo contrario). No llega al nivel de aislamiento de la virtualizaci´on, porque realmente son procesos que se ejecutan en la m´aquina ”host”(aunque realmente no es buen t´ermino, ya que no hay guest) pero nos permite f´acilmente, por ejemplo, crear instancias de base de datos desechables que son totalmente reseteables y que nos permiten tener datos de prueba. Por supuesto, este es el uso que le hemos dados, pero hay casos probados de empresas que usan estos contenedores en producci´on y que lo usan de manera semejante a la que usamos Vagrant, para tener im´agenes concretas de proceso y poder crearlos y destruirlos con mayor simplicidad, y a un menor coste computacional (puesto que no hay hipervisor de por medio), en nuestro caso, que no tenemos un sistema tolerante a fallos, ni de alta disponibilidad, se escapa a nuestro fin. 33 5. Conclusiones Como primer punto a destacar, el desarrollo de este proyecto me ha servido para conocer m´as en profundidad procesos burocr´aticos, los problemas que entra˜nan y como poder resolverlos, principalmente, en el ´ambito acad´emico. Este era un dominio que nunca hab´ıa tratado con anterioridad y que ha servido de escenario para poner en pr´actica los conocimientos adquiridos. En segundo lugar, el desarrollo de una arquitectura totalmente distinta a lo que hab´ıa aprendido en mis estudios me ha servido para conocer, poner en pr´actica, y desarrollar mis conocimientos sobre multitud de nuevas tecnolog´ıas. Abrir manuales, documentaci´on, comunicarme con otros ingenieros e incluso organizarme con ellos ha sido una invariante en todo el proyecto y me ha hecho crecer como profesional, acerc´andome un poco m´as al mundo real de los proyectos software llegando a poner en pr´actica metodolog´ıas que utilizar´e en mi carrera profesional. En cuanto al sistema que hemos desarrollado, ha cubierto unas expectativas y requisitos iniciales, pero que en como cualquier proyecto software, ir´an cambiando con el paso del tiempo. Uno de los puntos m´as fuertes que en mi opini´on tiene el proyecto es la de ser de c´odigo libre, por lo que en cualquier momento, gracias a su documentaci´on y el uso de tecnolog´ıas m´as o menos extendidas, permite que cualquier desarrollador pueda retomarlo y adaptarlo a nuevas necesidades. Tecnol´ogicamente hablando, en un futuro cercano, una buena pr´actica ser´ıa separar la lectura de la base de datos en una API y la modificaci´on de datos (creaci´on, actualizaci´on y borrado) en otra distinta. Esto har´ıa que la carga de trabajo m´as com´un (la lectura de la base de datos) quede totalmente aislada, y la tarea m´as cr´ıtica, de persistencia, quede concentrada en una sola parte. Otra apartado de la arquitectura que podr´ıa ser mejorado es el de separar la tarea de autorizaci´on (controlar si la petici´on contiene un access token v´alido en la cabecera) en un proxy externo a la API, de forma que a ´esta solo lleguen peticiones autorizadas y as´ı eliminar carga computacional innecesaria. Con esto conseguimos que el servidor de la API se encargue exclusivamente de la l´ogica de negocio. Tambi´en ser´ıa interesante subdividir las distintas funcionalidades de la aplicaci´on en peque˜nos micro servicios para tener una arquitectura mucho m´as modular y tolerante a fallos. De esta forma, un proyecto que inicialmente estaba modelado para ajustarse a los requisitos de una sola facultad, podr´ıa llegar a satisfacer las necesidades de multitud de universidades sin importar la cantidad de estudiantes que hagan uso de ella. 35 Referencias [1] Planes de movilidad internacional. Universidad de M´alaga. http://www.uma.es/ relaciones-internacionales/cms/menu/movilidad-estudiantes [2] Planes de movilidad nacional. Universidad de M´alaga. http://www.uma.es/sicue [3] ¿Qu´e son los servicios RESTful? The Java EE 6 tutorial (Ingl´es). http://docs. oracle.com/javaee/6/tutorial/doc/gijqy.html [4] ¿Qu´e es OpenID?. OpenID (Ingl´es). http://openid.net/get-an-openid/ what-is-openid [5] ¿Qu´e es SSO (Single Sign On)?. OAuth0 (Ingl´es). https://auth0.com/docs/sso [6] Gravatar. http://es.gravatar.com [7] Play Framework. https://www.playframework.com [8] Lightbend. http://www.lightbend.com [9] google/guice. GitHub. https://github.com/google/guice [10] google/gson. GitHub. https://github.com/google/gson [11] aaberg/sql2o. GitHub. https://github.com/aaberg/sql2o [12] typesafehub/config. GitHub. https://github.com/typesafehub/config [13] Slim Framework. http://www.slimframework.com [14] guzzle/guzzle. GitHub. https://github.com/guzzle/guzzle [15] Twig. SensioLabs. http://twig.sensiolabs.org [16] Bootstrap. http://getbootstrap.com/ [17] jQuery. https://jquery.com/ [18] bshaffer/oauth2-server-php. GitHub. https://github.com/bshaffer/ oauth2-server-php [19] WSDL. W3.org. https://www.w3.org/TR/wsdl [20] wsimport. Oracle Docs. http://docs.oracle.com/javase/6/docs/technotes/ tools/share/wsimport.html [21] RAML. http://raml.org 37 En el caso de que los datos introducidos sean correctos, ser´as redirigido a la p´agina principal con un mensaje indic´andote que ya formas parte del sistema. En el caso contrario, volver´as al formulario con un mensaje indicando el error al procesar el formulario para que puedas corregirlo. A partir de este momento, podr´as seguir el segundo camino que se puede dar en el sistema, que es el de un usuario ya registrado. II. Inicio de sesi´on En el caso de que seas un usuario ya registrado en el sistema (sea cual sea el rol que tengas en la aplicaci´on) podr´as acceder al mismo pulsando en la secci´on de “Log In” en la cabecera, en la parte superior derecha. Figura 9: Secci´on Log In en la cabecera. 44 Ser´as redirigido al servidor OpenID para el inicio de sesi´on, donde tras introducir tu correo electr´onico y contrase˜na (combinaci´on con la cual te registraste en el sistema) podr´as acceder inmediatamente a la aplicaci´on con los privilegios correspondientes. Figura 10: Inicio de sesi´on OpenID. 45 Una vez iniciada a la sesi´on, llegar´a a la p´agina principal de la aplicaci´on, donde ver´a sus peticiones abiertas en el sistema dependiendo del rol que tenga dentro de la aplicaci´on. Se mostrar´a una tabla donde las peticiones se dividen en aquellas que estan pendientes de moderar y aquellas que ya han sido tratadas por los reconocedores. Figura 11: Pantalla principal una vez iniciada la sesi´on. 46 En parte superior puede observar el buscador de asignaturas, en el que introduciendo un par´ametro de b´usqueda, podr´a realizar una b´usqueda entre la tabla de equivalencias entre asignaturas actual. Figura 12: Buscador sobre la tabla de equivalencias. 47 En la parte inferior de la p´agina principal, y en el caso de tener el rol de estudiante, podr´a acceder a crear peticiones. Acceder´a a un formulario que tendr´a que rellenar con la informaci´on necesaria, con datos como la asignatura de origen, las de destino, tipo de plan de movilidad, etc. Un detalle destacable es el de la posibilidad de a˜nadir m´as de una asignatura de destino con los votones de “Add” y “Delete” en la parte superior derecha de la secci´on de “Destination”. Figura 13: Secci´on de origen en la creaci´on de una petici´on. Figura 14: Secci´on de destino en la creaci´on de una petici´on. 48 Una vez creada una petici´on, aparecer´a en la p´agina principal, y podr´a ser consultada en cualquier momento para ver el estado de la misma (el cual aparecer´a en la parte superior derecha). Las peticiones tambi´en pueden ser comentadas por usuarios del sistema en la parte inferior. Figura 15: Informaci´on de una petici´on. Cualquier usuario en el sistema podr´a acceder a sus notificaciones en la parte superior derecha, pulsando en el icono del asterisco. El sistema ir´a generando notificaciones para los distintos usuarios dependiendo de las acciones que estos tomen. Figura 16: Notificaciones de un usuario. 49 III. Profesores de reconocimiento En esta secci´on vamos a proceder a comentar las particularidades de los usuarios cuyo rol es el de profesor de reconocimiento. Como hemos comentado, el inicio de sesi´on es unificado por lo que su camino hasta entrar en la aplicaci´on no ser´a distinto al de un estudiante. La primera particularidad que observar´an es que los profesores de reconocimiento no pueden crear peticiones. En cambio, ellos si podr´an moderar las peticiones en el sistema. Es por ello que las peticiones que ver´an en su´ındice en la pantalla principal, ser´an aquellas peticiones que tienen como objeto las asignaturas que ellos reconocen. Al acceder a la informaci´on de las mismas, en la esquina superior derecha, en el caso de que una petici´on este pendiente de reconocimiento, encontrar´an dos botones para poder aceptar o rechazar peticiones. Tambi´en podr´an ver qu´e usuario cre´o esa petici´on. Figura 17: Botones para poder moderar una petici´on. Otra particularidad es que tendr´an una secci´on en la cabecera (justo al lado del buscador) para poder ver qu´e asignaturas son las que reconoce. Figura 18: ´ Indice de asignaturas que reconoce el usuario. 50 IV. Coordinadores de centro En el ´ındice de peticiones, un usuario cuyo rol es el de coordinador de centr´o podr´a ver todas las peticiones cuyas asignaturas objetos pertenecen a un grado de su centro. A diferencia de un profesor reconocedor, un coordinador no podr´a modificar el estado de una petici´on, pero tambi´en podr´a ver el usuario el cual cre´o la petici´on. Un coordinador de centro tendr´a dos secciones extra (en la parte superior, junto al formulario de b´usqueda) que no tienen el resto de roles de la aplicaciones. Una de ellas es el registro de profesores de reconocedores. En ella podr´an dar de alta usuarios cuyo rol ser´a el de profesor de reconocimiento. La otra secci´on es un ´ındice de los profesores de reconocimiento que se encuentran en el sistema. En tal ´ındice los coordinadores podr´an asignar y eliminar asignaturas que reconocen dichos profesores. Figura 19: ´ Indice de reconocedores. 51 Figura 20: A˜nadir/eliminar asignaturas a un reconocedor. 52