Herramienta de análisis semántico de la descripción de resultados de aprendizaje en los planes de estudio universitario

Escola Tècnica Superior d’Enginyeria Informàtica Universitat Politècnica de València Herramienta de análisis semántico de la descripción de resultados de aprendizaje en los planes de estudio universitario Proyecto Final de Carrera Ingeniería Informática Autor: Pablo Fuentes Rodríguez Director: José Luis Poza Luján Director: José Alberto Conejero Casares 28 de juliol de 2016 Resumen El diseño de los planes de estudio, especialmente universitarios, se basa en las competencias que se espera que los alumnos adquieran. La adquisición de las competencias requiere de una serie de actividades formativas (antes sólo eran las clases teóricas; ahora hay prácticas, trabajos, etc.). Por medio de los actos de evaluación (antes sólo se hacía por exámenes), se comprueba el nivel de desarrollo que se ha logrado de cada competencia. Para poder ayudar al profesor acerca de qué tipo de competencia se relaciona con cada actividad formativa y con cada acto de evaluación, se propone este proyecto. El proyecto consiste en la programación de algoritmos de análisis semántico que permitan al profesor determinar, de forma automática, las competencias cubiertas por su asignatura y, a los responsables de títulos, comprobar la coherencia de los planes de estudio basados en competencias. Palabras clave: Competencias, CMS, gestión, software, educación Resum El disseny dels plans d’estudi, especialment universitaris, es basa en les competències que s’espera que els alumnes adquirisquen. L’adquisició de les competències requereix d’una sèrie d’activitats formatives (abans sols eren les classes teòriques; ara hi ha pràctiques, treballs, etc.). Mitjançant els actes d’avaluació (abans sols es feia per exàmens), es comprova el nivell de desenvolupament que s’ha adquirit de cada competència. Per a poder ajudar al professor sobre quin tipus de competència es relaciona amb cada activitat formativa i amb cada acte d’avaluació, es proposa aquest projecte. El projecte consisteix en la programació d’algorismes d’anàlisi semàntica que permetran al professor determinar, de forma automàtica, les competències cobertes per la seua assignatura i, als responsables de títols, comprovar la coherència dels plans d’estudi basats en competències. Palabras clave: Competències, CMS, gestió, software, educació Abstract The design of a syllabus, especially for university degrees, is based on the expected achievement of competences by the students. Their acquisitions require a series of training activities (before, only theoretical classes, and now, also practices, projects, etc. are considered). The level of achievement in the development of each competence can be measured by performing evaluation acts. Before, these acts were only exams, but now a broad range of acts is considered. This project is intending for helping teachers to relate competences with training activities and evaluation acts. It involves programming of semantic analysis algorithms that allow teachers to determine, automatically, which competencies are covered by their subjects, and to allow the degrees managers to check the consistency of the curriculum of the degree based on competencies. Palabras clave: Competencies, CMS, management, software, education Índice general Lista de figuras 3 Lista de tablas 4 1 Introducción 6 1.1 Motivación .............................. 6 1.2 Objetivos ............................... 6 1.3 Descripcion del documento . . . . . . . . . . . . . . . . . . . . . 6 2 Estudio del entorno 8 2.1 Introducción.............................. 8 2.2 Sistemas de gestión de competencias . . . . . . . . . . . . . . . . 9 2.2.1 NasaCMS .......................... 9 2.2.2 CVPlusVisual ........................ 9 2.2.3 GestPeople .......................... 11 2.2.4 IonCUDOS .......................... 12 2.3 Análisis ................................ 12 2.3.1 Análisis cuantitativo . . . . . . . . . . . . . . . . . . . . . 12 2.3.2 Análisis cualitativo . . . . . . . . . . . . . . . . . . . . . . 13 2.4 Síntesis ................................ 13 2.5 Tecnología a utilizar . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.6 Conclusiones ............................. 14 3 Especificación de requisitos 16 3.1 Introducción.............................. 16 3.1.1 Propósito ........................... 16 3.1.2 Ámbito ............................ 16 3.1.3 Personal involucrado . . . . . . . . . . . . . . . . . . . . . 16 3.1.4 Definiciones, acrónimos y abreviaturas . . . . . . . . . . . 17 3.2 Descripción general . . . . . . . . . . . . . . . . . . . . . . . . . . 18 3.2.1 Perspectiva del producto . . . . . . . . . . . . . . . . . . . 18 3.2.2 Funcionalidad del producto . . . . . . . . . . . . . . . . . 18 3.2.3 Características del usuario . . . . . . . . . . . . . . . . . . 19 3.2.4 Restricciones ......................... 19 3.3 Requisitos específicos . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.3.1 Requisitos no funcionales . . . . . . . . . . . . . . . . . . 20 3.3.2 Requisitos funcionales . . . . . . . . . . . . . . . . . . . . 21 3.3.3 Otros requisitos . . . . . . . . . . . . . . . . . . . . . . . . 22 2 Índice general Índice general 3.3.4 Conclusiones ......................... 22 4 Diseño del sistema 23 4.1 Introducción.............................. 23 4.2 Especificación formal . . . . . . . . . . . . . . . . . . . . . . . . . 23 4.2.1 Capa presentación . . . . . . . . . . . . . . . . . . . . . . 24 4.2.2 Capanegocio......................... 25 4.2.3 Capa persistencia . . . . . . . . . . . . . . . . . . . . . . . 27 4.3 Conclusiones ............................. 28 5 Implementación e implantación 29 5.1 Introducción.............................. 29 5.2 Implementación............................ 29 5.2.1 Capa presentación . . . . . . . . . . . . . . . . . . . . . . 29 5.2.2 Capalógica.......................... 33 5.2.3 Capa persistencia . . . . . . . . . . . . . . . . . . . . . . . 37 5.3 Implantación ............................. 37 5.3.1 Instalación .......................... 38 5.3.2 Ejecución ........................... 39 5.4 Conclusiones ............................. 40 6 Conclusiones 41 6.1 Dificultades encontradas . . . . . . . . . . . . . . . . . . . . . . . 41 6.2 Aportaciones ............................. 42 6.2.1 Tecnológicas ......................... 42 6.2.2 Académicas.......................... 42 6.3 Ampliaciones ............................. 42 3 Índice de figuras 2.1 Captura de pantalla del software NASA CMS . . . . . . . . . . . 9 2.2 Captura de pantalla del software CVPlus Visual . . . . . . . . . 10 2.3 Captura de pantalla del software GestPeople . . . . . . . . . . . 11 2.4 Workflow del software IonCUDOS . . . . . . . . . . . . . . . . . 12 3.1 Casosdeuso ............................. 19 4.1 Arquitectura programación por capas . . . . . . . . . . . . . . . 23 4.2 Diagrama de navegabilidad . . . . . . . . . . . . . . . . . . . . . 24 4.3 Propuesta disposición interfaz . . . . . . . . . . . . . . . . . . . . 24 4.4 Diagrama secuencia CU01 . . . . . . . . . . . . . . . . . . . . . . 25 4.5 Diagrama secuencia CU02 . . . . . . . . . . . . . . . . . . . . . . 26 4.6 Diagrama secuencia CU03 . . . . . . . . . . . . . . . . . . . . . . 26 4.7 Diagrama secuencia CU04 . . . . . . . . . . . . . . . . . . . . . . 27 4.8 Diagrama entidad relación base de datos . . . . . . . . . . . . . . 27 5.1 Captura vista taxonomía de Bloom . . . . . . . . . . . . . . . . . 30 5.2 Captura vista asignaturas . . . . . . . . . . . . . . . . . . . . . . 31 5.3 Captura vista resultados aprendizaje . . . . . . . . . . . . . . . . 32 5.4 Captura vista resultados aprendizaje en detalle . . . . . . . . . . 33 5.5 Captura vista analizar . . . . . . . . . . . . . . . . . . . . . . . . 33 4 Índice de cuadros 2.1 Análisis cuantitativo . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.2 Análisis cualitativo . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.3 Características del sistema . . . . . . . . . . . . . . . . . . . . . . 14 3.1 Miembro Pablo Fuentes . . . . . . . . . . . . . . . . . . . . . . . 17 3.2 Miembro José Luis Poza . . . . . . . . . . . . . . . . . . . . . . . 17 3.3 Miembro Jose Alberto Conejero . . . . . . . . . . . . . . . . . . . 17 3.4 Casosdeuso ............................. 19 3.5 Requisito no funcional RE01 . . . . . . . . . . . . . . . . . . . . 20 3.6 Requisito no funcional RE02 . . . . . . . . . . . . . . . . . . . . 20 3.7 Requisito no funcional RE03 . . . . . . . . . . . . . . . . . . . . 20 3.8 Requisito no funcional RE04 . . . . . . . . . . . . . . . . . . . . 20 3.9 Requisito no funcional RE05 . . . . . . . . . . . . . . . . . . . . 21 3.10 Requisito funcional RE06 . . . . . . . . . . . . . . . . . . . . . . 21 3.11 Requisito funcional RE07 . . . . . . . . . . . . . . . . . . . . . . 21 3.12 Otros resquisitos RE08 . . . . . . . . . . . . . . . . . . . . . . . . 22 5 Capítulo 1 Introducción 1.1 Motivación En los planes de estudio diseñados por competencias se espera que los alumnos las adquieran y que estarán cualificados para desempeñar un trabajo relacionado con su titulación. Es importante disponer de herramientas que guíen en la definición de planes de estudios basados en competencias. Estas herramientas pueden asesorar, comparando las competencias a adquirir con las necesidades del entorno socioeconómico. La herramienta desarrollada en este proyecto está pensada para ayudar a los profesores a formar mejor o de forma más coherente a las futuras generaciones de estudiantes. Además de orientar la docencia a la consecución de competencias. 1.2 Objetivos El objetivo de este proyecto es desarrollar un sistema que permita a los docentes determinar de forma automática las competencias cubiertas por su asignatura en base a las actividades formativas que el profesor haya definido. Este sistema permitirá al profesor asegurarse de que sus actividades formativas y la forma de evaluarlas corresponde con las competencias que se han establecido para desarrollar en su asignatura en función de la taxonomía de Bloom. Para desarrollar este sistema se implementará un servidor con la base de datos y el análisis de los datos. Y un cliente que permitirá al profesor interactuar con el servidor y mostrar los datos de forma elegante y ordenada. 1.3 Descripcion del documento El presente documento esta estructurado en 6 capítulos que detallarán el desarrollo del proyecto. A continuación se especifica el contenido de cada capítulo. En el capitulo 2 se han buscado sistemas similares y analizado puntos fuertes y características deseables a tener también este proyecto. En el capítulo 3 6 Capítulo 2. Estudio del entorno 2.4. Síntesis 1. C1 - Interfaz web Poder acceder al software con cualquier dispositivo, sistema operativo y navegador. 2. C2 - Orientado a la educación La gestión de competencias debe estar destinada al ámbito de la educación. 3. C3 - Uso de taxonomías Utilizar taxonomías para la clasificación de las competencias. 4. C4 - Actualizado Continua en uso y los desarrolladores siguen manteniendo el proyecto e incluyendo mejoras en él. 5. C5 - Gratuito El uso de la aplicación no tiene ningún coste para el usuario. 6. C6 - Open Source El código fuente está disponible para la comunidad, y permiten las aportaciones por parte de terceros. Característica Nasa CMS CVPlus Visual GestPeople IonCUDOS C1 3 7 7 3 C2 7 7 7 3 C3 7 7 7 3 C4 7 3 7 3 C5 7 7 7 7 C6 7 7 7 7 Cuadro 2.1: Análisis cuantitativo 2.3.2 Análisis cualitativo 1. D1 - Diseño amigable Interfaz gráfica elaborada y actual, siguiendo las últimas tendencias de diseño. 2. D2 - Moderno Desarrollado utilizando los últimos lenguajes de programación y/o frameworks del mercado. Característica Nasa CMS CVPlus Visual GestPeople IonCUDOS D1 7 7 7 7 D2 7 7 7 7 Cuadro 2.2: Análisis cualitativo 2.4 Síntesis En base al resultado del análisis se han extraído una serie de características deseables para nuestro sistema. Se detallan en la siguiente tabla 13 2.5. Tecnología a utilizar Capítulo 2. Estudio del entorno Característica Descripción CA01 - Basado en web El acceso a la aplicación debe ser mediante un navegador web compatible con todos los sistemas operativos. CA02 - Arq. 3 capas La aplicación tiene que estar diseñada utilizando una arquitectura por capas separando totalmente la persistencia, la lógica y el diseño. CA03 - RESTful Con la idea de posibles ampliaciones como aplicación móvil o escritorio. La forma de separar la lógica del diseño es mediante un servidor RESTful. CA04 - Uso de taxonomías Utilizar la taxonomía de Bloom para la clasificación de los resultados de aprendizaje. Cuadro 2.3: Características del sistema 2.5 Tecnología a utilizar En primer lugar, para desarrollar la parte de la vista (fronted) del proyecto, se ha elegido AngularJS [Angb] que es un framework javascript con el que poder crear complejas aplicaciones web del lado del cliente. Utiliza el patrón MVC y cuenta con potentes librerías que permiten, de forma muy fácil, la conexión con un servidor RESTful para obtener los datos que mostrar al cliente. A continuación, para la base de datos, se ha elegido PostgreSQL [Pos] que es un motor de base de datos SQL muy utilizado en los proyectos Open Source. Lleva más de 15 años en el mercado, funciona en los sistemas operativos más utilizados y los lenguajes de programación más comunes tienen conectores para poder trabajar con PostgreSQL. Finalmente, para la lógica se ha elegido Django [Dja] que es un framework de desarrollo web escrito en Python. Django utiliza una técnica de programación llamada ORM que convierte los objetos del lenguaje de programación en objetos de la base de datos, y viceversa. Gracias a esta técnica es posible olvidar la gestión de la base de datos ya que Django se encarga de ello. También dispone de la librería Django REST framework [fra] que es una gran herramienta para crear un servicio RESTful. 2.6 Conclusiones En base al resultado de análisis de sistemas similares, la conclusión principal a la que se ha llegado es que no hay muchas herramientas. Las que hay son antiguas, sin soporte y no cumplen las características deseadas para este proyecto. El único programa que tiene un gran parecido y es utilizado para trabajar en el sector de la educación es IonCUDOS. Los otros programas están pensados para el sector empresarial y lo único que comparten es la gestión de las competencias. 14 Capítulo 2. Estudio del entorno 2.6. Conclusiones Con estos datos se demuestra que hay un gran sector por cubrir y que, aparentemente, no se está trabajando en ello (excepto IonCUDOS). Por esta causa, es una buena idea seguir hacia delante con el proyecto y dedicarle esfuerzos. 15 Capítulo 3 Especificación de requisitos 3.1 Introducción El sistema permitirá al equipo docente consultar la taxonomía de Bloom, así como, visualizar los resultados de aprendizaje de las asignaturas. Además, cabe la posibilidad de añadir nuevos resultados de aprendizaje. El objetivo del sistema es analizar los resultados de aprendizaje y clasificarlos en una categoría de la taxonomía de Bloom (en el nivel cognitivo). Así, a partir del análisis, el profesor podrá saber si sus resultados de aprendizaje y sus actos de evaluación cubrirán las competencias asignadas a su asignatura. 3.1.1 Propósito Con la especificación de requisitos se pretende determinar completamente la descripción del sistema que se va a desarrollar. En la primera parte se hablará del ámbito, personal involucrado, definiciones, acrónimos y abreviaturas; en la segunda parte, se hará una descripción general del producto dejando para la parte final la especificación de requisitos. 3.1.2 Ámbito Este proyecto es un componente de otro proyecto piloto interno de la ETSINF más grande llamado Evalua2. 3.1.3 Personal involucrado En este apartado se va a mostrar a las personas involucradas en el proyecto, indicando: •Nombre: Nombre de la persona involucrada en el proyecto. •Rol: Papel que desesarrolla esta persona en el proyecto. •Categoría profesional: Cargo que ocupa la persona •Responsabilidades: De que tareas se encarga 16 Capítulo 3. Especificación de requisitos 3.1. Introducción •Información de contacto: Dirección de correo para poder contactar con esa persona Nombre Pablo Fuentes Rodríguez Rol Desarrollador Categoría profesional Estudiante Responsabilidades Desarrollar el sistema Información de contacto [email protected] Cuadro 3.1: Miembro Pablo Fuentes Nombre José Luis Poza Luján Rol Director Categoría profesional Profesor Responsabilidades Dirigir el proyecto Información de contacto jop[email protected]v.es Cuadro 3.2: Miembro José Luis Poza Nombre José Alberto Conejero Casares Rol Director Categoría profesional Profesor Responsabilidades Dirigir el proyecto Información de contacto [email protected] Cuadro 3.3: Miembro Jose Alberto Conejero 3.1.4 Definiciones, acrónimos y abreviaturas •UPV: Universidad Politécnica de Valencia. •ETSINF: Escuela Técnica Superior de Ingeniería Informática de la UPV. •IEEE: Institute of Electrical & Electronics Engineers. •Taxonomía: Ciencia que trata de los principios, métodos y fines de la clasificación. Se aplica para la ordenación jerarquizada y sistemática. •Resultado de aprendizaje: Declaración de lo que el estudiante se espera que conozca, comprenda y sea capaz de hacer al finalizar un período de aprendizaje. •Acto de evaluación: Tarea que realiza el estudiante para ser evaluado. •Sistema: Producto software, resultado de este proyecto final de carrera. •REST: Es un estilo de arquitectura software para servidores web que utiliza peticiones HTTP para obtener o indicar la ejecución de operaciones sobre los datos del servidor. •RESTful: Sistema que sigue los principios REST 17 3.2. Descripción general Capítulo 3. Especificación de requisitos •Framework: Es una estructura conceptual y tecnológica con módulos o artefactos ya definidos que sirven de base para la organización y el desarrollo de un desarrollo software. •JSON: Es un formato de text ligero para el intercambio de datos. •HTML: Lenguaje de marcada que se utiliza para la elaboración de páginas web. •CSS: Lenguaje usado para definir y crear el estilo y la presentación de un documento HTML. •Javascript: Lenguaje de programación interpretado, utilizado en la parte del navegador web, que permite mejoras de funcionalidad en las páginas web. •AngularJS: Framework Javascript que se utilizará en este proyecto. •Python: Lenguaje de programación interpretado cuya filosofía hace hincapié en una sintaxis que favorezca el código legible. •Django: Framework Python que se utilizará en este proyecto. •IDE: Entorno de desarrollo dinámico, aplicación informática que proporciona servicios integrales para facilitarle al programador el proceso del desarrollo software 3.2 Descripción general 3.2.1 Perspectiva del producto El sistema se trata de una interfaz web que se encarga de mostrar los datos al usuario de forma elegante y ordenada. Los datos se obtienen mediante peticiones a un servidor RESTful que contiene la lógica y la base de datos. A continuación se van a detallar los requisitos necesarios que se han de cumplir para que el sistema sea considerado un producto válido. 3.2.2 Funcionalidad del producto Como se viene indicando durante todo el documento, el proyecto está enfocado al personal docente de la UPV. Así que solo se dispondrá de un tipo de usuario en el sistema (profesor) y, a continuación, mediante diagramas de casos de uso, se indicarán las funciones que el profesor podrá realizar: 18 Capítulo 3. Especificación de requisitos 3.3. Requisitos específicos Figura 3.1: Casos de uso Caso de uso Descripción CU01 El profesor podrá acceder y buscar todas las asignaturas de la carrera agrupadas por cursos. La vista hará una llamada al servidor el cual hará todos los cálculos necesarios y devolverá los datos para que puedan ser pintados. CU02 El profesor podrá acceder y buscar todos los verbos de la taxonomía agrupados por las categorías a las que pertenecen. CU03 El profesor podrá ver el listado de resultados de aprendizaje de cada asignatura, filtrarlo y consultar el resultado de aprendizaje que desee. CU04 El profesor podrá subir un fichero en formato JSON con resultados de aprendizaje para ser analizado y clasificado por el servidor y poder ver el resultado por pantalla. Cuadro 3.4: Casos de uso 3.2.3 Características del usuario El sistema solo cuenta con un tipo de usuario, el usuario profesor quien podrá realizar toda la funcionalidad que ha sido expresada en el apartado anterior 3.2.2 3.2.4 Restricciones Para poder utilizar el sistema no existen restricciones pero sí hay tres requisitos a cumplir. Disponer de un ordenador con sistema operativo Windows, Linux o Mac, el ordenador debe tener un navegador web moderno y debe estar conectado a Internet. 3.3 Requisitos específicos El sistema que se va a desarrollar se trata de un prototipo, puesto que dispone de pocos requisitos y todos son altos o esenciales. En el último capítulo se 19 3.3. Requisitos específicos Capítulo 3. Especificación de requisitos detallarán las posibles ampliaciones de este prototipo. 3.3.1 Requisitos no funcionales Número RE01 Nombre Accesibilidad web Tipo Usuario 3Sistema Funcional Restricción Descripción El sistema ha de adaptarse a todas las pantallas de ordenador permitiendo que la experiencia del usuario sea satisfactoria. Prioridad 3Alta/Esencial Media/Deseado Baja/Opcional Cuadro 3.5: Requisito no funcional RE01 Número RE02 Nombre Desarrollo de la vista Tipo Usuario 3Sistema Funcional Restricción Descripción La vista del sistema tiene que estar desarrollada con HTML, CSS y Javascript. El framework Javascript a utilizar debe ser AngularJS Prioridad 3Alta/Esencial Media/Deseado Baja/Opcional Cuadro 3.6: Requisito no funcional RE02 Número RE03 Nombre Desarrollo de la lógica Tipo Usuario 3Sistema Funcional Restricción Descripción La lógica del sistema tiene que estar desarrollada en el lenguaje de programación Python. Concretamente con el framework Django. Prioridad 3Alta/Esencial Media/Deseado Baja/Opcional Cuadro 3.7: Requisito no funcional RE03 Número RE04 Nombre Desarrollo de la persistencia Tipo Usuario 3Sistema Funcional Restricción Descripción Para la capa de persistencia el sistema tiene que utilizar el sistema de gestión de base de datos relacionales PostgreSQL. Prioridad 3Alta/Esencial Media/Deseado Baja/Opcional Cuadro 3.8: Requisito no funcional RE04 20 Capítulo 3. Especificación de requisitos 3.3. Requisitos específicos 3.3.2 Requisitos funcionales Número RE05 Nombre Listado de asignaturas Tipo Usuario Sistema 3Funcional Restricción Descripción El usuario podrá consultar todas las asignaturas de la carrera agrupadas por cursos, además se dispondrá de un buscador con el que poder filtrar las asignaturas. Prioridad 3Alta/Esencial Media/Deseado Baja/Opcional Cuadro 3.9: Requisito no funcional RE05 Número RE06 Nombre Taxonomía de Bloom Tipo Usuario Sistema 3Funcional Restricción Descripción El usuario podrá consultar todos verbos de la taxonomía de Bloom agrupados por categoría, además se dispondrá de un buscador con el que poder filtrar los verbos. Prioridad 3Alta/Esencial Media/Deseado Baja/Opcional Cuadro 3.10: Requisito funcional RE06 Número RE07 Nombre Analizar fichero resultados de aprendizaje Tipo Usuario Sistema 3Funcional 3Restricción Descripción El usuario, desde la interfaz, podrá subir un fichero en formato JSON al servidor. El servidor lo analizará y devolverá el resultado a la vista para que pueda ser mostrado de forma elegante y ordenada al usuario. Prioridad 3Alta/Esencial Media/Deseado Baja/Opcional Cuadro 3.11: Requisito funcional RE07 21 3.3. Requisitos específicos Capítulo 3. Especificación de requisitos 3.3.3 Otros requisitos Número RE08 Nombre Copias de seguridad Tipo Usuario 3Sistema Funcional Restricción Descripción Al estar todos los datos almacenados en la base de datos, es altamente recomendable crear un sistema de copias de seguridad diarios. Para evitar que si hubiera algún fallo no se pierdan datos. Prioridad Alta/Esencial Media/Deseado 3Baja/Opcional Cuadro 3.12: Otros resquisitos RE08 3.3.4 Conclusiones Para realizar esta especificación de requisitos se ha seguido el estándar IEEE 830 [EE84]. Los requisitos se han establecido a partir de la tecnología a utilizar definida en el apartado 2.5 y de los casos de uso indicados en el apartado 3.4. A su vez, estos casos de uso han sido definidos siguiendo las características del apartado 2.3 del capítulo anterior. 22 Capítulo 5 Implementación e implantación 5.1 Introducción Una vez diseñado el sistema en el capítulo anterior, en este se procederá a especificar su implantación. Se explicará la tecnología utilizada en el sistema, que ya ha sido introducida al lector en el apartado 2.5 entrando más en detalle y completando el capítulo de una manera más técnica. También se explicarán las herramientas utilizadas para el desarrollo del sistema. Mostrando capturas reales del producto final y partes de código más significativas. 5.2 Implementación Para el desarrollo se ha utilizado el IDE de desarrollo Pycharm [Pyc] que es una herramienta muy utilizada por los desarrolladores Python. Tiene dos versiones la Profesional (de pago) y la Community (gratuita). Como es evidente la gratuita tiene menos funcionalidad que la de pago, pero para el desarrollo de este proyecto la versión Community ha sido más que suficiente. 5.2.1 Capa presentación Esta capa está desarrollada con HTML, CSS y AngularJS y es una interfaz que, sin conexión a la capa lógica, no funciona ya que no tiene datos. Todos los datos utilizados para poder mostrar la vista correctamente se obtienen mediante llamadas GET y POST a la REST API que hay implementada en la capa lógica. Gracias a la potencia de AngularJS esto se puede a hacer en muy pocas lineas con el uso de Factories. Las Factories son contenedores de código que se pueden utilizar entre los controladores y tienen la característica de ser fragmentos de código que solo se instancian una vez, por lo que no pierden su estado. 29 5.2. Implementación Capítulo 5. Implementación e implantación El siguiente fragmento de código es el que se encarga de la conexión entre la vista y la lógica angular.module(’evalua2’) .factory(’CursoFactory’,function($resource){ return $resource(’http://localhost:8000/api/v1/curso/:id’); }) .factory(’AsignaturaFactory’,function($resource){ return $resource(’http://localhost:8000/api/v1/asignatura/:id’); }) .factory(’CategoriaBloomFactory’,function($resource){ return $resource(’http://localhost:8000/api/v1/categoria-bloom/:id’); }) .factory(’CategoriaBloomValorFactory’,function($resource){ return $resource(’http://localhost:8000/api/v1/categoria-bloom-valor/:id’); }) .factory(’AnalizarFactory’,function ($resource) { return $resource(’http://localhost:8000/api/v1/analizar/’, {}, { save: {method: ’POST’,isArray: true} }); }); A continuación, se muestran unas capturas de pantalla de cada uno de los apartados del cliente web para verificar que se cumple el diseño planteado en el apartado 4.2.1 Figura 5.1: Captura vista taxonomía de Bloom 30 Capítulo 5. Implementación e implantación 5.2. Implementación En la figura 5.1 se muestra un gráfico de radar que expone de forma muy visual qué categoría tiene mayor número de verbos asociados. Este gráfico esta desarrollado utilizando la librería Angular Chart [Chaa] que, a su vez utiliza para sus directivas la librería ChartJS [Chab] que es una libreria Javascript open source que permite crear gráficos utilizando el componente canvas de HTML. El siguiente fragmento de código HTML muestra lo rápido que es generar una gráfica utilizando esta librería <canvas id="categorias-chart" class="chart chart-radar" chart-data="data" chart-labels="labels" chart-series="series"> </canvas> Las variables data, labels y series son listas que están definidas en el controlador de la vista, se inicializan a listas vacías y son rellenadas cuando la lógica devuelve los valores $scope.labels = []; $scope.data = [[]]; $scope.values = []; CategoriaBloomFactory.query(function(categorias){ angular.forEach(categorias, function(categoria){ $scope.labels.push(categoria.name); $scope.data[0].push(categoria.values.length); $scope.values.push(categoria.values); }); }); Figura 5.2: Captura vista asignaturas La figura superior 5.2 muestra el listado de asignaturas agrupadas por curso. Al pulsar sobre una de ellas se accede al detalle de la asignatura mostrando todos su resultados de aprendizaje. Para obtener el listado de asignaturas, la vista hace una petición GET a la url http://localhost:8000/api/v1/curso/ 31 5.2. Implementación Capítulo 5. Implementación e implantación // Directiva vista listado asignaturas por curso $scope.cursos = []; $scope.asignaturas = []; CursoFactory.query(function(cursos){ angular.forEach(cursos, function(curso){ $scope.cursos.push(curso.name); $scope.asignaturas.push(curso.values); }); }); Figura 5.3: Captura vista resultados aprendizaje En la figura superior 5.3 se ve una tabla con cada uno de los resultados de aprendizaje y el número de ocurrencias que contiene la frase en cada una de las categorías de la taxonomía de Bloom. Como se puede ver en la siguiente figura 5.4 al pasar el ratón sobre una de las palabras que pertenece a la taxonomía aparece un cartel indicando a que categoría pertenece. 32 Capítulo 5. Implementación e implantación 5.2. Implementación Figura 5.4: Captura vista resultados aprendizaje en detalle Por ultimo, queda por mostrar la vista de análisis, en la que aparece un botón grande y al hacer click sobre el botón se puede elegir el fichero que se ha de analizar. Figura 5.5: Captura vista analizar Una vez analizado el fichero por el servidor, se muestra un listado como el de la figura 5.3 y, al pasar el ratón sobre las palabras, se muestra el mismo detalle que en la vista 5.4 5.2.2 Capa lógica Esta capa es la encargada de servir los datos y realizar los cálculos. Todo esto ha sido desarrollado con Django. Los proyectos Django se componen de apps, que son paquetes de código. La filosofía de Django es que un app solo realice una funcionalidad y un conjunto de apps (funcionalidades) generen un proyecto. Las apps pueden ser desarrollos 33 5.2. Implementación Capítulo 5. Implementación e implantación propios o de terceros. A continuación se detallan las apps utilizadas en este proyecto. core Esta aplicación es la base del proyecto y sobre la que construir posibles ampliaciones. Contiene los modelos básicos con los que trabajar •Curso •Asignatura •CategoriaBloom •CategoriaBloomValor •ResultadoAprendizaje En esta app solo están definidos los modelos y sus campos, nada más. restapi Esta aplicación es la base de la comunicación entre la lógica y la vista. Aquí están definidos los Serializers que son modelos que se encargan de convertir los objetos ORM a objetos JSON y viceversa. Hay un modelo serializador por cada modelo definido en la app core 5.2.2 •CursoSerializer •AsignaturaSerializer •CategoriaBloomSerializer •CategoriaBloomValorSerializer •ResultadoAprendizajeSerializer Después están definidas las URLs de la API en la que el el servidor escucha peticiones. Django, al recibir una petición en una URL, ejecuta una función asociada a esa URL. A continuación, un ejemplo de la vista asociada al listado completo de cursos. # Peticion GET a http://127.0.0.1:8000/api/v1/curso/ @api_view([’GET’]) def curso_list(request): if request.method == ’GET’: cursos = Curso.objects.all() serializer = CursoSerializer(cursos, many=True) data = [] for cin serializer.data: serializer_vals = AsignaturaSerializer(Asignatura .objects 34 Capítulo 5. Implementación e implantación 5.2. Implementación .filter(curso_id=c[’id’]), many=True) c[’values’] = sorted(serializer_vals.data, key=lambda k: k[’name’]) data.append(c) return Response(data) Este código se ejecuta al recibir una petición GET en la URL http://127. 0.0.1:8000/api/v1/curso/. Por cada curso lo serializa, busca sus asignaturas y también las serializa y, después, las añade al objeto curso para más tarde devolver una lista como resultado @api_view([’GET’]) def asignatura_list(request): if request.method == ’GET’: asignaturas = Asignatura.objects.all() serializer = AsignaturaSerializer(asignaturas, many=True) return Response(serializer.data) El código superior muestra como devolver todas las asignaturas que hay en la base de datos. Como se puede observar el procedimiento es muy fácil y rápido para el desarrollador en objetos que no requieren procesamiento. Django y rest-framework 5.2.2 se encargan de todo. def analyze_ra(ra_name): """ Comparamos cada palabra del resultado de aprendizaje con todos los verbos de las categorías de bloom. """ res = { ’phrase’: [], ’categs’: {c.name: 0for cin CategoriaBloom.objects.all()} } # Quitamos acentos y pasamos a minusculas unaccent_categs = {unicodedata .normalize(’NFKD’, c) .encode(’ASCII’,’ignore’).lower(): c for cin res[’categs’]} # Mientras no haya ningún token que pertenezca a alguna categoria de bloom 35 5.2. Implementación Capítulo 5. Implementación e implantación # reconstruimos la frase en esta variable phrase = ’’ for token in ra_name.split(’ ’): unaccent_token = unicodedata .normalize(’NFKD’, token) .encode(’ASCII’,’ignore’).lower() cat_bloom = CategoriaBloomValor.objects.filter(name__iexact=token) if cat_bloom or unaccent_token in unaccent_categs.keys(): # Guardamos la parte de la frase reconstruida hasta ahora if phrase: res[’phrase’].append([phrase]) phrase = ’’ tokens = [token] # Si el token actual coincide con algun verbo de bloom # añadimos a la lista las categorias de los verbos # y añadimos un ocurrencia más al contador de categorias. if cat_bloom: for cin cat_bloom: res[’categs’][c.categ_id.name] += 1 tokens.append([c.categ_id.name]) else: # Si el token es una de las categorias y no es un verbo tokens.append(token) res[’categs’][unaccent_categs[unaccent_token]] += 1 res[’phrase’].append(tokens) else: phrase = ’%s %s’ % (phrase, token) if phrase else token if phrase: res[’phrase’].append([phrase]) return res Esta función es la encargada del análisis de los resultados de aprendizaje. Recibe por parámetro una frase y compara cada palabra de la frase con todos los verbos de la taxonomía de Bloom. Si hace ’matching’ entonces suma +1 en el contador por categorías y marca en la frase a que categoría pertenece este verbo. El resultado es una lista en la que sus elementos son también listas de uno o más elementos. El primer elemento de esta sublista es la palabra y el resto de elementos de las sublistas (si los hay), son las categorías de la taxonomía de Bloom a las que pertenece esa palabra. 36 Capítulo 5. Implementación e implantación 5.3. Implantación restframework Esta es una aplicación de terceros [fra]. Es una herramienta que proporciona todo lo necesario para empezar a desarrollar una REST API. •Página web desde la que hacer consultas a la API. Sirve de gran ayuda a la hora de empezar a programar. •Varias políticas de autenticación entre las incluidas OAuth1a y OAuth2. •Serialización de fuentes de datos ORM y no-ORM. •Extensa documentación, con muchos ejemplos. •Usada y reconocida por muchas empresas como Mozilla, Red Hat y Heroku. corsheaders Es una aplicación de terceros [Hea] que complementa a la app rest-framework 5.2.2 añade headers CORS (Cross-Origin Resource Sharing) a las respuestas HTTP. Con corsheaders se puede añadir una lista blanca de dominios o expresiones regulares a rutas a las que si permitir CORS y así saltarnos la política del mismo origen que utilizan los navegadores, si no las peticiones AngularJS a la API darían error y no se podría acceder a los datos. Para este proyecto se ha configurado una expresión regular que acepte CORS a todos los dominios si la ruta contine /api/v1/ 5.2.3 Capa persistencia Para la base de datos, la única gestión por parte del desarrollador que se ha de hacer es tener PostgreSQL instalado y crear la base de datos tal y como se explica en el apartado 5.3.1 Esto es gracias al object-relational mapper (ORM) de Django, que se encarga de crear las tablas y campos de la base de datos, así como también se encarga de leer y guardar los datos en la base de datos sin que el desarrollador tenga que preocuparse. Este nivel de abstracción facilita el trabajo del desarrollador puesto que Django permite trabajar con PostgreSQL, MySQL y SQL lite y el desarrollador no necesita saber trabajar con todos los motores de base de datos puesto que Django ya lo hace por él. 5.3 Implantación El proyecto se encuentra en un repositorio de acceso público https://github. com/fuentes010/evalua2, que pertenece a Pablo Fuentes, el proyectando que desarrolla este proyecto. 37 5.3. Implantación Capítulo 5. Implementación e implantación 5.3.1 Instalación Para poder utilizar el sistema hay que seguir unos sencillos pasos. En primer lugar, instalar git en la máquina Linux o Mac que vaya a ejecutar el proyecto y, posteriormente, clonar el repositorio en el directorio que se desee. ~ git clone https://github.com/fuentes010/evalua2.git Tener instalado PostgreSQL. Se puede hacer mediante el gestor de paquetes en el caso de los sistemas operativos Linux # Archlinux ~ sudo pacman -S postgresql # Fedora ~ sudo yum install postgresql-server postgresql-contrib # Debian, Ubuntu ~ sudo apt-get install postgresql postgresql-contrib Para sistema operativo Mac la forma más cómoda es utilizar la aplicación Postgres.app que se puede descargar en http://postgresapp.com/ Y crear una base de datos nueva para el proyecto. ~ createdb pfc Como último paso para tener la base de datos correctamente, hay que ir hasta el fichero de configuración del proyecto que se encuentra en la ruta backend/evalua2/settings.py y establecer en la variable DATABASES (línea 101) la conexión a la base de datos. DATABASES = { ’default’: { ’ENGINE’:’django.db.backends.postgresql’, ’NAME’:’NOBRE DE LA BASE DE DATOS’, ’USER’:’TU USUARIO CON PERMISOS DE ACCESO A POSTGRESQL’, ’PASSWORD’:’TU CONTRASENA’, ’HOST’:’127.0.0.1’, ’PORT’:’5432’, } } También es recomendable instalar un software llamado virtualenvwrapper [wra]. No es obligatorio pero es altamente recomendable. Este software permite tener múltiples entornos virtuales de Python y, en cada uno de estos entornos, tener diferentes librerías y diferentes versiones de estas. Esto a la hora de programar es de gran ayuda, ya que nunca tendremos conflictos entre proyectos causados por incompatibilidades de versiones ni entre librerías. Cada entorno utiliza las suyas. Para instalarlo podemos usar el gestor de paquetes de nuestro sistema operativo o pip, que es un gestor de paquetes software escritos en Python 38