Actas del Segundo Congreso de Estudiantes deIngeniería Informática de la Universidad de La

Laguna

30 de Noviembre y 1 de Diciembre de 2016

Escuela Superior de Ingeniería y Tecnología de laUniversidad de La Laguna

PUBLISHED BY COMITÉ ORGANIZADOR DEL II CONGRESO DE ESTUDIANTES DE INGENIERÍA

INFORMÁTICA DE LA UNIVERSIDAD DE LA LAGUNA

VERSIÓN BORRADOR (DRAFT)

cesinf.webs.ull.es

30 de Noviembre de 2016

Índice general

I Carta del Director de la EscuelaII Congreso de Estudiantes / Leopoldo Acosta 7

II AgradecimientosNota de agradecimiento / Organizacíón del Congreso 11

III Contribuciones: trabajos científicosVideojuegos para la neurorrehabilitación mediante eye-tracking / R. Martí-nez y M.A. Rodríguez 15

QuasarAPP: una aplicación móvil para el estudio del glaucoma / A.J. Vera19

Generación automática de código OpenCL para arquitecturas ARM / Ser-gio M. Afonso Fumero 23

Sistema basado en machine learning para la selección de algoritmos / A.Dávila 29

Procesamiento de la DBpedia para mejorar ADEGA basado en grafos / A.Rodríguez 35

IV Contribuciones: trabajos académicosPredicción de abandonos en cursos online masivos y abiertos / Manuel Ba-callado 45

Comparativa de fusión y reorganización en GIT / J.T. Villar y I. González 51Técnicas de optimización multi-objetivo en la planificación de menús / J.M.Ramos 55Estudio de las alertas del servicio 112 / V. Plaza 59

I

II Congreso de Estudiantes / Leopoldo Acosta

Carta del Director de laEscuela

Seguna Edición del Congreso de Estudiantes

LA SEGUNDA EDICIÓN DEL CONGRESO DE ESTUDIANTES DEINGENIERÍA INFORMÁTICA

Leopoldo Acosta SánchezDirector de la Escuela Superior de Ingeniería y Tecnología de la Universidad de La Laguna

Todos los que formamos la comunidad educativa de la ESIT celebramos la segunda edición delCongreso de Estudiantes de Ingeniería Informática de la ULL. Tras vivir la experiencia exitosa delaño pasado es una satisfacción comprobar que el nivel técnico de los ponentes sigue siendo muyalto.

El Equipo de dirección de la ESIT desea agradecer a los alumnos que se han implicado en losdiversos aspectos que conlleva la organización de un evento de esta naturaleza. No es fácil para unestudiante de Ingeniería Informática encontrar tiempo entre práctica y práctica para casi nada, nisiquiera para el ocio. En segundo lugar, pero no en menor medida, nuestro agradecimiento a losprofesores que han tutorizado los trabajos que se presentan al Congreso. No han transmitido a losalumnos solo conocimiento sino ilusión y ganas de aprender.

Por último un reconocimiento muy especial al “Alma Mater” de este Congreso, el profesor JoséIgnacio Estévez Damas. Los que lo conocemos sabemos de su rigurosidad, capacidad de trabajo ygenerosidad. Tengo mi despacho al lado del suyo y se que en estas últimas semanas ha dedicadocasi todo su tiempo a la organización de este Congreso.

Leopoldo Acosta SánchezDirector de la ESIT

II

Nota de agradecimiento / Organizacíón del Congreso

Agradecimientos

Agradecimientos

NOTA DE AGRADECIMIENTO

Comité Organizador del II Congreso de Estudiantes de IngenieríaInformática

Escuela Superior de Ingeniería y Tecnología de la Universidad de La Laguna

Con estas palabras queremos agradecer la colaboración de todas las instituciones, empresas yparticulares que han hecho posible este Congreso.

Nuestro principal apoyo ha sido sin duda la Escuela Superior de Ingeniería y Tecnología, quenos ha dado todas las facilidades y apoyo para llevar esta idea desde un proyecto a una realización.

El Vicerrectorado de Docencia y su convocatoria de proyectos de innovación permite queproyectos como este se materialicen. Son actividades que complementan la enseñanza más reglada,y creemos aportan un valor añadido a la formación universitaria. Este año hemos querido mejorarnuestro proyecto y creemos haber hecho cosas nuevas e interesantes.

Esta vez tenemos un conferenciante de la Universidad del Pais Vasco, gracias a la colaboracióndel Seminario Últimos Avances de la Informática, y al Vicerrectorado de Investigación. Nuestroespecial agradecimiento a ambos.

La Fundación General de la Universidad de La Laguna, nos ha ofrecido un servicio eficiente yresuelto nuestras dudas rápidamente. Le estamos muy agradecidos también.

Nuestros patrocinadores nos han dado un impulso inestimable. Hablamos especialmente delColegio Profesional de Ingenieros Técnicos en Informática de Canarias (COITIC), que se haprestado a colaborar y apoyar la idea desde el primer momento. También asociaciones como losJóvenes Investigadores de Tenerife (JINTE) contactaron de forma inmediata brindándonos todo suapoyo y patrocinio.

Estamos en deuda con profesionales como Isidro Quintana, CEO de Promineo Studios, AntonioCabrera, CEO de “The Game Experience”, Luis Antón Canalís en representación de SAVE (Asocia-ción Canaria de Empresas y Profesionales de la Animación, el Videojuego y los Efectos Visuales) yDaniel Blanco quienes han colaborado en el Congreso acercándonos su visión de la industria de losvideojuegos en Canarias y participando en la valoración de los proyectos presentados en la actividad“Anímate a programar a un Videojuego”. Quiero mencionar a todos los equipos que se inscribieronen la actividad para crear un videouego. Fueron siete y llegaron tres, nuestro agradecimiento a

12 CESINF-2016, Universidad de La Laguna

todos, ojalá sepamos diseñar esta actividad de modo que todos puedan presentar sus trabajos alfinal, incluso con la presión de las clases y las prácticas.

También queremos agradecer a Marcelino Concepción, de la asociación INNOVA 7 su disponi-bilidad para ofrecernos su experiencia en la charla de cierre de esta edición del Congreso sobre unevento tan importante como TLP Tenerife.

Tenemos un agradecimiento especial para los centros de enseñanza IES Andrés Bello, IESGeneto e IES Tacoronte-Oscar Domínguez, por traer a sus alumnos a la ESIT participando ennuestro taller con App Inventor. Estamos en deuda con ellos y sus profesores: Carlos Tejera yMiguel Curbelo del IES Andrés Bello, Julián Garrido Martín del IES Geneto y María SoledadEstévez Damas del IES Tacoronte-Óscar Domínguez por aceptar el reto. Y como no, con losalumnos de estos institutos que vinieron a pasar una jornada con nosotros y los alumnos del gradoMelissa Díaz Arteaga, Patricia García Erustes y Rafael Gonzalez de Chaves Gonzalez que lesayudaron toda la jornada. Este evento en particular no hubiera sido posible sin la ayuda del PASJosé María Carralero, que nos preparó la sala de ordenadores a la perfección, y el STIC que nosmontó una red Wifi mejor que la que existía, gracias a las gestiones de José María.

Las Facultades de Física y Matemáticas nos han cedido sus espacios para la realización de esteCongreso. Les damos las gracias por ello otro año más.

Queremos agradecer a todos los ponentes su participación. Los conferenciantes invitados sehan prestado desinteresadamente a compartir con los estudiantes de la Escuela su experiencia,conocimiento, visión y opiniones. Nuestro muy especial reconocimiento a todos los estudiantes yegresados que han presentado su trabajo para dar cuerpo a este congreso. Sin ellos, por supuesto,este Congreso no tendría ningún sentido.

Los miembros del Comité Científico han realizado una gran labor, leyendo las contribuciones yproponiendo cambios constructivos. Gracias a su trabajo, los artículos, que pueden ser consultadoen esta memoria, han ganado en calidad.

Finalmente, como Coordinador Académico de este evento no quiero pasar la oportunidad deagradecer el esfuerzo y entusiasmo de los alumnos y alumnas que se han implicado de verdad en estereto. Ojalá les haya servido y lo recuerden siempre como una experiencia positiva y enriquecedora.

III

Videojuegos para la neurorrehabilitación medianteeye-tracking / R. Martínez y M.A. RodríguezQuasarAPP: una aplicación móvil para el estudiodel glaucoma / A.J. VeraGeneración automática de código OpenCL paraarquitecturas ARM / Sergio M. Afonso FumeroSistema basado en machine learning para la se-lección de algoritmos / A. DávilaProcesamiento de la DBpedia para mejorar ADEGAbasado en grafos / A. Rodríguez

Contribuciones: trabajoscientíficos

CESINF 2016 - Trabajos científicos - 1

DESARROLLO DE VIDEOJUEGOS PARA LA NEURORREHABILITACIÓNMEDIANTE EYE-TRACKING

Rebecca Martínez y Manuel Alejandro Rodríguez SantanaGraduados en Ingeniera Informática – Universidad de La Laguna

Tutor: Silvia Alayón MirandaDepartamento de Ingeniería Informática y Sistemas - Universidad de La Laguna

Objetivo

El objetivo principal de este trabajo es el desarrollo de videojuegos serios para la neurorrehabi-litación de pacientes con problemas motores. Por este motivo el juego no sólo debe poder jugarsecon un medio de control tradicional, como por ejemplo un ratón, sino que también debe ofrecerla posibilidad de ser controlado a través de la mirada, mediante el movimiento de los ojos. Estemodo de juego beneficiaría potencialmente la recuperación del movimiento de las extremidadessuperiores en pacientes con daño cerebral.

Introducción

El uso de videojuegos en los distintos ámbitos de la vida cotidiana es cada vez más comúndebido a la gran cantidad de ventajas que ofrece, como son, por ejemplo, la mejora de las habilidadesmotoras y visuales o el aumento de la sociabilidad. Además, es una forma común y divertida depasar el rato para la mayoría de las personas. Por tanto, en este trabajo se pretende aprovechar todasestas ventajas para ofrecer una herramienta de ayuda para la recuperación de las funciones motorasde personas con daño cerebral.

Para ello, se propone la realización de videojuegos que se controlen tanto con el ratón como conel movimiento de los ojos, mediante el uso de un eye-tracker, un dispositivo que permite registrar elmovimiento ocular con mucha exactitud, y saber el recorrido que la persona ha hecho con los ojos

16 CESINF-2016, Universidad de La Laguna

y las zonas en las que ha detenido más su mirada. El eye-tracker que se ha utilizado en este trabajoes The Eye Tribe [1].

La idea de este proyecto surge de diversas investigaciones realizadas [2] por el Grupo deNeurquímica y Neuroimagen de la Universidad de La Laguna. En los estudios realizados, unapersona debía controlar un objeto virtual que se movía en una pantalla mediante dos métodos decontrol diferentes: usando la mano y usando la mirada. Los resultados mostraron que utilizar losojos para controlar un objeto virtual producía una gran activación cerebral en regiones motoras, muysimilar a la que se produce cuando el objeto se controla con la mano (figura 1). Estos resultadostienen una aplicación potencial en el campo de la neurorrehabilitación, como una nueva formapara generar la activación del sistema sensoriomotor. El entrenamiento de control de elementosvirtuales con los ojos podría ayudar a incrementar la actividad cortical de regiones relacionadas conel movimiento de los miembros afectados.

Figura 1: Activación de zonas cerebrales motoras cuando el paciente “controla” un objeto virtualcon los ojos y/o la mano. Estudio realizado por el Grupo de Neuroquímica y Neuroimagen de laULL con resonancia magnética funcional [2]

Métodos

El primer paso realizado en este trabajo fue la selección del tipo de juego más adecuado parapoder ser usado en un proceso de neurorrehabilitación. Los requisitos eran: juego sencillo, adictivo,que la mayoría de los pacientes conocieran ya, y que permitiera el movimiento de un objeto endos direcciones (derecha-izquierda). Tras valorar varios juegos, finalmente se decidió implementarel “Break out” [3] y el “Space Invaders” [4], juegos clásicos muy sencillos y conocidos. En elBreak Out el objetivo es controlar una plataforma para evitar que una bola caiga al suelo, almismo tiempo que se deben destruir los bloques presentes en la imagen. En el Space Invadrers elobjetivo es controlar el disparo de un cañón para destruir las naves de extraterrestres que se acercanprogresivamente a la Tierra.

Una vez seleccionados los juevos. se procedió a su implementación mediante Unity [5], unmotor de videojuegos versátil que ofrece multitud de opciones a aquellos que desean iniciarse en eldesarrollo de videojuegos multiplataforma.

Los primeros prototipos desarrollados permitían controlar el juego completo con un ratón. Unavez terminada esta parte, el equipo médico evaluó el juego para ver si estaba bien implementado osi era necesario añadir o eliminar alguna funcionalidad. Finalmente, se integró el eye-tracker en eljuego.

Videojuegos para la neurorrehabilitación mediante eye-tracking / R. Martínez y M.A.Rodríguez 17

The Eye Tribe [1] es el eye-tracker que se utilizó para desarrollar el juego. Se trata de undispositivo que puede calcular el lugar al que una persona está mirando por medio de la informaciónextraída de la cara y los ojos (ver figura 2. Las coordenadas se calculan con respecto a una pantallaque la persona está mirando y están representadas por un par (x, y).

Figura 2: Ejemplo de uso del dispositivo The Eye Tribe

Para que el eye-tracker funcione correctamente y calcule las coordenadas de forma adecuada,es necesario que se realice una calibración inicial (figura 3) que consiste en ir mirando unos puntosque se iluminan en la pantalla.

Figura 3: Calibración The Eye Tribe

ResultadosEn la figura 4 se muestran unas imágenes de los videojuegos desarrollados.Ambos juegos constan de varios niveles, y permiten guardar las puntuaciones obtenidas. Para

ello, se implementó un teclado donde el jugador puede introducir su nombre, para que se guardejunto a sus puntuaciones.

El trabajo aquí presentado es el fruto de dos Trabajos Fin de Grado, presentados por los autoresen el curso 2015-2016 [6, 7]. Los juegos implementados fueron validados por varios usuarios paracomprobar su correcta usabilidad y niveles de dificultad.

Tras haber jugado varias veces, durante bastante rato, se obtuvieron buenas valoraciones porparte de las personas que probaron el videojuego. La mayoría de las personas encontraban difíciljugar con la vista, debido a la falta de costumbre, pero tras haber jugado varias partidas se adaptabany conseguían buenos resultados. Además, la vista se les cansaba rápidamente, pero este efecto ibadisminuyendo a medida que practicaban más. En estos momentos el equipo médico colaboradorestá probando la herramienta con pacientes reales.

18 CESINF-2016, Universidad de La Laguna

Figura 4: Juegos Break Out (izquierda) y Space Invaders (derecha).

ConclusionesMediante la realización de este trabajo se ha conseguido crear videojuegos entretenidos y

relativamente sencillos de jugar, que pueden ser controlados tanto con el ratón como con la vista, yque ofrece la posibilidad de ayudar a recuperar las funciones motoras a pacientes con daño cerebral.El producto final desarrollado cumple con todos los objetivos planteados inicialmente e incluso sele ha añadido alguna funcionalidad extra, como la posibilidad de escribir el nombre mediante unteclado.

A pesar de que los juegos, una vez finalizados, cumplen con todos los requisitos establecidosinicialmente, es cierto que pueden añadirse múltiples funcionalidades para completarlos. Porejemplo, una posible mejora sería adaptar el juego para que pueda ser utilizado con otros eye-trackers que ofrezcan una mayor precisión. Otra vía abierta es la implementación de nuevos juegos,ya que el paciente pasará muchas horas jugando y, por ello, cuanta más variedad de juegos tenga,menos se aburrirá y más tiempo dedicará a la neurorrehabilitación.

Referencias[1] Dispositivo eye-tracker “The Eye Tribe”. URL: https://theeyetribe.com/.

[2] Cristián Modroño, Julio Plata-Bello, Fernando Zelaya, Sofía García, Iván Galván, FranciscoMarcano, Gorka Navarrete, Oscar Casanova, Manuel Mas y José Luis González-Mora.“Enhancing Sensorimotor Activity by Controlling Virtual Objects with Gaze.” En: Plos One10.3 (2015).

[3] Juego Breakout. URL: https://es.wikipedia.org/wiki/Breakout_(videojuego).

[4] Juego Space Invaders. URL: https://es.wikipedia.org/wiki/Space_Invaders.

[5] Motor gráfico Unity. URL: https://unity3d.com/es.

[6] R. Martínez. “Desarrollo de video-juegos para la neurorehabilitación mediante eye-tracking”.En: Trabajo Fin de Grado. Grado en Ingeniería Informática, Universidad de La Laguna,2016.

[7] M. A. Rodríguez. “Implementación de video-juegos para la neurorehabilitación medianteeye-tracking”. En: Trabajo Fin de Grado. Grado en Ingeniería Informática, Universidad deLa Laguna, 2016.

CESINF 2016 - Trabajos académicos - 5

QUASARAPP: UNA APLICACIÓN MÓVIL PARA EL ESTUDIO DE LAPROGRESIÓN DEL GLAUCOMA

Aarón José Vera CerdeñaGraduado en Ingeniería Informática – Universidad de La Laguna

Tutor: Silvia Alayón 1, Francisco Fumero 1, Tinguaro Díaz-Alemán 2

(1) Departamento de Ingeniería Informática y de Sistemas - Universidad de La Laguna(2) Hospital Universitario de Canarias

ObjetivoEl trabajo presentado es la adaptación de un software ya existente para el seguimiento de

la evolución del glaucoma (enfermedad oftalmológica) a una aplicación móvil. Se parte de unprograma llamado Quasar, desarrollado en Python. Este programa utiliza análisis de regresiónlineal del defecto medio (MD),y de la pérdida de varianza (sLV) o desviación respecto al patrón(PSD), parámetros oftalmológicos muy utilizados en el diagnóstico del glaucoma. El programaalmacena los parámetros de cada paciente e indica la progresión de la enfermedad,si detecta uncambio significativo en el MD y en la sLV o PSD.

IntroducciónEl glaucoma es una enfermedad ocular que se caracteriza por la pérdida del campo visual como

consecuencia de un daño en el nervio óptico [1]. Uno de los métodos más comunes utilizados parael diagnóstico de esta enfermedad y el estudio de su evolución es una prueba funcional conocidacomo perimetría.

Un perímetro es un equipo médico que realiza análisis del campo visual, que es el espacioque percibe cada ojo por separado cuando mira hacia un punto fijo central [2]. En una perimetríaconvencional se estudian varios puntos concretos del campo visual, como los mostrados en la figura1.

20 CESINF-2016, Universidad de La Laguna

Figura 1: Puntos del campo visual que se estudian en una perimetría convencional.

La interpretación de los resultados del campo visual resulta más fácil si se emplean índicesestadísticos, así como representaciones gráficas de los resultados en forma de escala de grises. Losíndices estadísticos más importantes [3] son:

La sensibilidad media (MS), es la media aritmética de las sensibilidades de todos los puntosestudiados.El defecto medio (MD), es la media aritmética de las diferencias de las sensibilidades decada punto con respecto al valor para una persona de la misma edad(permite comparacionesentre grupos de edades distintos).La varianza de pérdida en Octopus (sLV) o desviación respecto al patrón en Humphery (PSD),es el resultado de dividir la suma de las diferencias cuadráticas entre el defecto medio y eldefecto encontrado en cada punto concreto, por el número de casos menos uno. Representala variabilidad del campo visual. A mayor variabilidad, mayor será el valor de la varianza.

Analizando estos parámetros es posible evaluar el campo visual del paciente, detectar alteracio-nes precoces y diagnosticar enfermedades de la retina, el nervio óptico y la vía visual.

Quasar [Diaz2015] es un programa diseñado para evaluar la progresión del campo visual en lospacientes con glaucoma,utilizando el análisis de regresión lineal tanto de MD y sLV o PSD, bajo lahipótesis de que la combinación de estos dos parámetros debe mejorar la sensibilidad de cada unopor separado.

El programa Quasar (figura 2) fue desarrollado por un grupo de investigación del Serviciode Oftalmología del Hospital de Universitario de Canarias. Fue programado en el lenguaje deprogramación Python 2.7.3 y en el entorno Linux Fedora 17 por uno de los médicos de dicho grupo.

Figura 2: Programa Quasar.

QuasarAPP: una aplicación móvil para el estudio del glaucoma / A.J. Vera 21

En este trabajo se pretende crear una aplicación para dispositivos móviles partiendo del progra-ma Quasar, con el objetivo de facilitar su usabilidad en el entorno médico.

Métodos

Para el desarrollo de esta aplicación móvil se utilizaron las siguientes tecnologías:1. Apache Cordova [4] es un framework de software libre que cuenta con muchas apis de

diversos dispositivos móviles para desarrollar aplicaciones nativas dentro de un smartphone.Cada vez es más popular ya que para el desarrollo de las aplicaciones se utilizan las tecnolo-gías web HTML5, CSS y JavaScript. Una de las grandes peculiaridades de este entorno detrabajo es la posibilidad de desarrollar para iOS, Android y demás sistemas operativos sin lanecesidad de programar en sus lenguajes nativos (Java,Objetive-C, etc.).

2. Intel XDK [5] es una herramienta para desarrollar apps cross-plataform utilizando HTML5.Con XDK, los desarrolladores pueden programar usando tecnologías estándar como HTML5y desde una misma base de código generar apps para distintas plataformas.

3. IndexedDB [6] es un tipo de base de datos NoSQL no relacional. Se puede definir IndexedDBcomo una herramienta que HTML5 proporciona a los programadores para poder trabajar conuna base de datos desde la propia aplicación web, sin tener que conectarse a ningún servidor,disponible offline (en entornos sin conexión web) y persistente (al cerrar la aplicación, elcontenido no se borra).

Resultados

Como resultado se ha desarrollado una aplicación móvil denominada QuasarApp. Presentavarias funcionalidades: crear nuevos pacientes, buscar/borrar pacientes ya existentes, añadir/eli-minar pruebas de pacientes, calcular la evolución de los parámetros perimétricos estudiados, yrepresentación gráfica de esta evolución (Figura 3).

Figura 3: Ventanas de la aplicación QuasarApp.

Conclusiones

En este trabajo se ha abordado la implementación de una app móvil, QuasarApp, partiendo deun programa llamado Quasar, para el seguimiento de la evolución del glaucoma. La app incluyeademás mejoras sobre el programa original del que se parte.

22 CESINF-2016, Universidad de La Laguna

Esta aplicación móvil permite a los oftalmólogos expertos en glaucoma llevar a cabo elseguimiento del paciente de una manera más centralizada, haciendo su trabajo más eficiente graciasa la utilización de las nuevas tecnologías. Además, poder utilizar el programa sobre una plataformamóvil facilita su usabilidad.

Actualmente no existe ninguna aplicación móvil similar a QuasarApp. El prototipo ha sido yavalidado por los expertos del HUC, y en estos momentos se prepara su lanzamiento al mercado.Como líneas futuras de desarrollo, se podría hacer uso de un servicio de almacenamiento de datosen la nube de datos,y añadir la funcionalidad de generar un informe que contenga todos los datosde los resultados del análisis de regresión lineal, entre otros.

Referencias[1] Glaucoma. URL: http://www.clinicabaviera.com/glaucoma.

[2] Manual sobre perimetría. URL: http://es.slideshare.net/wildercito35/interpretaciondel-campo-visual-computadorizado.

[3] Valentín Tinguaro Díaz Alemán. “Estudio comparativa de procedimientos para la evaluaciónde la progresión campimétrica en pacientes glaucomatosos”. En: Tesis Doctoral, Universidadde La Laguna, 2008.

[4] Apache Cordova. URL: http://www.batanga.com/tech/13241/que-es-apachecordova.

[5] Intel XDK. URL: https://software.intel.com/es-es/intel-xdk.

[6] IndexedDB. URL: https://developer.mozilla.org/es/docs/IndexedDB.

CESINF 2016 - Trabajos científicos - 3

GENERACIÓN AUTOMÁTICA DE CÓDIGO OPENCL PARAARQUITECTURAS ARM

Sergio M. Afonso FumeroDoctorando en Ingeniería Industrial, Informática y Medioambiental – Universidad de La Laguna

Tutor: Francisco Almeida Rodríguez1, Alejandro Acosta Díaz(1) Departamento de Ingeniería Informática y Sistemas - Universidad de La Laguna

ObjetivoLa heterogeneidad de los Sistemas en Chip (SoC) hace necesario un conocimiento muy espe-

cífico de su hardware para aprovechar el rendimiento que éstos ofrecen. OpenCL es un conocidoestándar multiplataforma para el acceso a dispositivos heterogéneos, soportado en gran cantidad deplataformas móviles. Utilizando una aproximación basada en anotaciones, proponemos generarautomáticamente código OpenCL de alto rendimiento a partir de código escrito en un lenguaje dealto nivel. El código generado puede ser ejecutado en dispositivos Android y demuestra ser unaalternativa más sencilla y flexible que Renderscript.

IntroducciónTecnologías que antes sólo estaban disponibles en ordenadores de sobremesa y servidores

son ahora comunes en SoCs localizados en dispositivos móviles y tablets [1, 2, 3]. Estas nuevasplataformas son heterogéneas, porque integran CPUs multinúcleo, GPUs y DSPs, y proporcionangrandes prestaciones con un coste energético bajo. Algunos de los SoCs más relevantes en laactualidad son los sistemas Samsung Exynos, Qualcomm Snapdragon, Apple Ax y Nvidia Tegra,todos basados en ARM, y que abarcan la gran mayoría de dispositivos móviles.

Para poder aprovechar la potencia de las arquitecturas móviles actuales es necesario dar accesoa los distintos elementos de cómputo presentes en éstas. Lenguajes como Renderscript [4] enAndroid y Metal [5] en iOS nos ofrecen esta posibilidad, pero algunas plataformas también nos

24 CESINF-2016, Universidad de La Laguna

Anotación Se aplica a Parámetros Depende@Target Clases value -@Map Campos y parámetros value @Target@Declare Campos y métodos size @Target@Parallel Métodos — @Target@Input Parámetros — @Parallel@Output Parámetros — @Parallel@NumThreads Métodos y parámetros field @Parallel@Index Parámetros — @Parallel

Cuadro 1: Anotaciones de Paralldroid

facilitan OpenCL [6] o CUDA [7] como alternativas a más bajo nivel. Aunque los primeros sonlenguajes más sencillos, también requieren al desarrollador un esfuerzo adicional. Las diferenciasentre OpenCL y Renderscript o Metal es que es más flexible y multiplataforma, pero necesita unmayor conocimiento de la arquitectura en la que se ejecuta para obtener un buen rendimiento,porque requiere un manejo manual de los dispositivos. Herramientas que permitan aprovechar lasposibilidades que ofrece OpenCL evitando el coste asociado a escribir este código son, por ello,necesarias.

Paralldroid [8, 9, 10] es una plataforma de desarrollo que permite la generación automáticade código Renderscript en Android y código nativo, y pretende facilitar la escritura de códigoparalelo, eficiente y portable en arquitecturas heterogéneas. El desarrollador escribe código Java yañade anotaciones, consiguiendo así separar el algoritmo de su implementación paralela optimizada,generada por Paralldroid. El código generado puede ejecutarse en cualquier dispositivo acelerador,como la CPU o GPU. Esta plataforma, desarrollada por el Grupo de Computación de AltasPrestaciones de la ULL, se coloca entre el código Java y los lenguajes paralelos para propiciar elaprovechamiento de estos recursos de cómputo por desarrolladores poco especializados. Nuestracontribución consiste en un nuevo módulo en Paralldroid que permite generar automáticamentecódigo OpenCL. Esta contribución ha demostrado ser eficiente, y puede ampliar el rango dedispositivos a los que portar el código paralelo generado desde Paralldroid.

Métodos

En esta sección se describe Paralldroid y las modificaciones necesarias para generar códigoOpenCL en esta plataforma. En la Tabla 1 se presenta la lista de anotaciones que define, junto alos elementos del código donde se pueden aplicar, sus parámetros y otras anotaciones de las quedependen.

@Target: Define una clase a traducir. Sus campos son representados en el entorno de destino,y sus métodos ejecutados en el mismo. Permite decidir los traductores utilizados para generarel código destino.@Map: Indica el modo de mapeo de datos en el contexto destino. Los tipos son Alloc, To,ToFrom y From.@Declare: Especifica que el elemento sólo es accesible en el contexto destino. El parámetrosize es opcional, y permite indicar un tamaño inicial a campos de tipo array.@Parallel: Indica que el método se debe ejecutar en paralelo.@Input y @Output: Especifican los vectores de entrada y salida en la ejecución de unmétodo paralelo. Se aplican sobre parámetros de tipo array o bitmap y permiten simplificarla definición de parámetros.@NumThreads: Define la variable que indica en un método paralelo cuántos hilos deben

Generación automática de código OpenCL para arquitecturas ARM / Sergio M. AfonsoFumero 25

usarse. Se puede aplicar al propio método utilizando el parámetro field o se puede aplicar auno de sus parámetros. No es necesaria cuando hay algún parámetro marcado como @Inputo @Output, y sólo puede aparecer una vez.@Index: Permite especificar la variable utilizada como índice en cada uno de los hilosque ejecutan un método paralelo. Su valor se asigna automáticamente y varía entre 0 y@NumThreads.

En el Listado 1 se muestra un ejemplo de implementación del algoritmo de transformación deuna imagen a escala de grises en Java utilizando Paralldroid. Nótese que al obtener el número dehilos de un bitmap, debemos definir dos parámetros @Index que recorrerán todo el ancho y alto dela imagen.

@Target (OPENCL)p u b l i c c l a s s GraySca l e {

@Declarep r i v a t e f l o a t gMonoMult [ ] = {0 .299 f , 0 . 587 f , 0 . 114 f } ;

@ P a r a l l e lp u b l i c vo id run ( @Input Bitmap s rcPxs , @Output Bitmap outPxs ,

@Index i n t x , @Index i n t y ) {i n t p i x e l = s r c P x s . g e t P i x e l ( x , y ) ;i n t acc ;acc = ( i n t ) ( Co lo r . r e d ( p i x e l ) ∗ gMonoMult [ 0 ] ) ;acc += ( i n t ) ( Co lo r . g r e e n ( p i x e l ) ∗ gMonoMult [ 1 ] ) ;acc += ( i n t ) ( Co lo r . b l u e ( p i x e l ) ∗ gMonoMult [ 2 ] ) ;ou tPxs . s e t P i x e l ( x , y , Co lo r . a rgb ( Co lo r . a l p h a ( p i x e l ) ,

acc , acc , acc ) ;}

}

Programa 1: Escala de grises en Paralldroid

Figura 1: Modelos de ejecución y datos

Paralldroid hace uso del analizador de OpenJDK para obtener el Árbol Sintáctico Abstracto(AST) del código desarrollado. El procedimiento consiste en convertir, utilizando clases traductoras,

26 CESINF-2016, Universidad de La Laguna

el AST de origen para generar varios ASTs de destino, que representan el código generado. Hemosdotado a Paralldroid del conjunto de clases necesarias para la generación automática de OpenCL.En OpenCL es necesario generar código Java, C y OpenCL C. El primero actúa como interfazfrente al resto de la aplicación, el segundo comunica Java con OpenCL y gestiona la ejecución decódigo en aceleradores, y el tercero es el código paralelo de alto rendimiento. Hay que tener encuenta que el código OpenCL C se compila en tiempo de ejecución al crear la primera instancia dela clase generada, lo cual nos permite obtener un binario optimizado para la plataforma específicaen la que se ejecuta.

El modelo de ejecución en OpenCL se resume en las siguientes partes principales:Constructor: Al crear la primera instancia de una clase generada, se debe inicializar elcontexto OpenCL nativo y compilar los kernels que implementan sus métodos paralelos.Métodos paralelos:Los parámetros @Index se eliminan, ya que su valor está asociado acada hilo. El código nativo contiene las llamadas a la API OpenCL que configuran unallamada a un kernel en la GPU.Destructor: Se asegura de que al eliminar la última instancia de la clase, se libere el contextoOpenCL.

El modelo de datos, por otro lado, se compone de las siguientes partes:Constructor: El contexto nativo se inicializa con los valores que el código Java original lohacía.Campos: Dependiendo de las anotaciones @Map presentes en el campo, se generan métodosgetter y setter que sincronizan la memoria de la GPU con la CPU y hacen las conversionesde formato de datos necesarias. Los campos @Declare no son gestionados, ya que sólo sonválidos en el contexto de destino.Métodos: Sus parámetros se gestionan como campos de la clase, pero al principio y al finaldel método.Destructor: Realiza la operación inversa que el constructor, liberando la memoria ocupadaen la GPU.

Como soporte al código generado por Paralldroid, se ha desarrollado también una librería nativa.Esta librería se enlaza al código generado compilado, y proporciona funciones para el manejo deexcepciones y objetos de tipo bitmap. Además gestiona los objetos OpenCL globales necesarios paraque todas las clases generadas puedan acceder a los mismos dispositivos aceleradores seleccionadosal inicio.

Resultados

Las pruebas de rendimiento se han llevado a cabo en los dispositivos Sony Xperia Z (etiquetadoSXZ) y Odroid-XU3 (etiquetado XU3) sobre varios algoritmos de procesamiento de imágenes. ElSony Xperia Z está basado en un SoC Qualcomm APQ8064 S4 Pro [11], mientras el Odroid-XU3se basa en un SoC Samsung Exynos 5422 Octa [12]. Ambos están dotados de 2GB de memoriaRAM compartida entre CPU y GPU.

Los algoritmos sobre los que las pruebas fueron realizadas son:Escala de grises: Transformación de una imagen en color a escala de grises.Niveles: Modificación de los niveles de brillo, contraste y color de una imagen.Convolución 3x3: Modificación valor de cada píxel en función de sus 8 píxeles vecinos.Convolución 5x5: Aplicación de una convolución evaluando los 24 píxeles vecinos.

Para todos estos algoritmos, hemos implementado dos versiones del código: Una versión Javasecuencial y otra versión que utiliza anotaciones de Paralldroid. A partir de la versión anotada seha generado una implementación Renderscript y otra OpenCL. Se ha utilizado varios tamaños deimagen comunes, y se compara los tiempos de ejecución del código auto-generado con los delcódigo secuencial de referencia. En las dos subfiguras superiores de la Figura 2 vemos la aceleración

Generación automática de código OpenCL para arquitecturas ARM / Sergio M. AfonsoFumero 27conseguida para todos los algoritmos en las imágenes de menor y mayor tamaño, mientras que lasdos subfiguras inferiores muestran el rendimiento para el algoritmo de grano más fino y grueso delos estudiados. Definimos granularidad como la cantidad de cómputo que es realizada por cada unode los hilos. Al diseñar algoritmos paralelos es importante hacer un balance entre granularidad muyfina – el coste de crear hilos puede ser muy grande para la cantidad de cómputo que se lleva a cabo– y granularidad muy gruesa – el trabajo está poco repartido y puede dar lugar a desbalanceo de lacarga en las distintas unidades de proceso. Lanzamos las pruebas utilizando un hilo por píxel, deforma que el driver se encarga de gestionar los recursos disponibles.

Figura 2: Resultados de las pruebas de rendimiento

Debido a limitaciones del hardware [13], la GPU del Odroid-XU3 es reportada por el driverOpenCL como dos plataformas distintas, lo cual obliga a nuestro código auto-generado a seleccionarsólo un subconjunto de sus unidades de cómputo para ejecutar nuestros algoritmos. La adiciónde soporte para múltiples aceleradores en un solo dispositivo ayudaría a mitigar este problema.Nuestra experimentación, además, confirma que Renderscript se ejecuta siempre en la CPU deeste dispositivo, que además parece ofrecer un mejor rendimiento que su GPU. El código OpenCLgenerado, por otro lado, siempre se ejecuta en la GPU, por lo que no se puede hacer una comparaciónjusta entre las dos versiones de código acelerado en este dispositivo. El Sony Xperia Z, por otrolado, demuestra que cuando la ejecución entre Renderscript y OpenCL es comparable – es decir, seutiliza el mismo acelerador en ambos casos – el código OpenCL generado tiene un rendimientosignificativamente mejor.

ConclusionesLa generación de código OpenCL presentada en este trabajo demuestra conseguir buenas

mejoras de rendimiento, con respecto al código Java secuencial, en la ejecución de algoritmos de

28 CESINF-2016, Universidad de La Laguna

procesamiento de imágenes fácilmente paralelizables. Nuestra aproximación permite al programa-dor de aplicaciones aprovechar la potencia de cómputo de los aceleradores presentes en multitud dedispositivos móviles de manera sencilla, y además distintos algoritmos pueden ser generados endistintos lenguajes rápidamente, lo que posibilita rápidamente encontrar el lenguaje más apropiadopara implementar un cierto algoritmo.

Nuestro código OpenCL generado demuestra ser la opción más rápida cuando la GPU deldispositivo tiene mejores prestaciones que su CPU, ya que Renderscript puede seleccionar entreambos pero el driver OpenCL de éste – si está presente – normalmente no nos da esta posibilidad.Sin embargo, si se da esta circunstancia se puede utilizar código Renderscript auto-generado, puestoque es trivial este cambio gracias a Paralldroid.

Referencias[1] Exynos. Samsung. Nov. de 2016. URL: http://www.samsung.com/semiconductor/

minisite/Exynos/.

[2] Snapdragon. Qualcomm. Nov. de 2016. URL: https://www.qualcomm.com/products/snapdragon.

[3] Nvidia Tegra. Nvidia. Nov. de 2016. URL: https://www.nvidia.com/object/tegra.htmlhttps://www.qualcomm.com/products/snapdragon.

[4] Renderscript. Open Handset Alliance. Nov. de 2016. URL: https://developer.android.com/guide/topics/renderscript/compute.html.

[5] Metal for developers. Apple. Nov. de 2016. URL: https://developer.apple.com/metal/.

[6] OpenCL: The open standard for parallel programming of heterogeneous system. KhronosGroup. Nov. de 2016. URL: https://www.khronos.org/opencl/.

[7] CUDA Zone. NVIDIA. Nov. de 2016. URL: https://developer.nvidia.com/cuda-zone.

[8] Alejandro Acosta, Sergio Afonso y Francisco Almeida. “Extending Paralldroid with objectoriented annotations”. En: Parallel Computing 57 (2016), páginas 25-36. ISSN: 0167-8191.DOI: http://dx.doi.org/10.1016/j.parco.2016.04.003. URL: http://www.sciencedirect.com/science/article/pii/S0167819116300126.

[9] A. Acosta y F. Almeida. “Towards an Unified Heterogeneous Development Model in An-droid”. En: Eleventh International Workshop HeteroPar. 2013.

[10] Alejandro Acosta y Francisc Almeida. “Towards a Unified Heterogeneous DevelopmentModel in AndroidTM”. En: Euro-Par 2013: Parallel Processing Workshops: BigDataCloud,DIHC, FedICI, HeteroPar, HiBB, LSDVE, MHPC, OMHI, PADABS, PROPER, Resilience,ROME, and UCHPC 2013, Aachen, Germany, August 26-27, 2013. Revised Selected Papers.Editado por Dieter an Mey y col. Berlin, Heidelberg: Springer Berlin Heidelberg, 2014,páginas 238-248. ISBN: 978-3-642-54420-0. DOI: 10.1007/978-3-642-54420-0_24.URL: http://dx.doi.org/10.1007/978-3-642-54420-0_24.

[11] Sony Xperia Z. Qualcomm. Nov. de 2016. URL: https://www.qualcomm.com/products/snapdragon/smartphones/sony-xperia-z.

[12] Odroid-XU3. Hardkernel. Nov. de 2016. URL: http://www.hardkernel.com/main/products/prdt_info.php?g_code=G140448267127.

[13] OpenCL for GPU and CPU on Odroid XU3. ARM Community. Nov. de 2016. URL: https://community.arm.com/thread/8394#28633.

CESINF 2016 - Trabajos científicos - 2

SISTEMA BASADO EN MACHINE LEARNING PARA LA SELECCIÓN DEALGORITMOS

Alan Dávila de LeónAlumno de 2o Máster de Ingeniería Informática – Universidad de La Laguna

Tutor: José Marcos Moreno-Vega 1, Belén Melián-Batista 1, Eduardo Lalla-Ruiz 2

(1) Departamento de Ingeniería Informática y de Sistemas - Universidad de La Laguna(2) Dpt. of Information Systems - University of Hamburg

ObjetivoDiseñar e implementar un sistema basado en Machine Learning (ML) que permita generar

un ranking ordenado de algoritmos atendiendo a las características que conforman cada instanciaespecífica que se quiere resolver, con el objetivo de maximizar la calidad de las soluciones.

IntroducciónA pesar del éxito general que tienen las metaheurísticas en una multitud de problemas, su

aplicación a nuevos problemas o variantes es una tarea compleja. La dificultad radica en la grancantidad de problemas y algoritmos existentes para resolverlos, sin que se disponga de una guía odirectrices que indiquen cuando y como emplear cada algoritmo. Por otra parte, el teorema NFLpropuesto por Wolpert y Macready en 1995 [1], expone que, si se ejecuta un conjunto de algoritmossobre todos los posibles problemas, su desempeño será el mismo en promedio. Debido a esto, laselección del algoritmo a emplear tiene que tener en cuenta las características del problema. Esto seconsigue mediante la extracción de conocimiento del problema y su posterior utilización.

En este sentido, el problema de selección de algoritmos fue introducido por John Rice en 1976[2], donde trata de responder a la pregunta “¿Qué algoritmo es más problema que sea el mejor pararesolver mi problema?” Sus componentes principales son el espacio del problema P, el espacio decaracterísticas F , el espacio de algoritmos A, y el espacio de métricas de rendimiento Y asociados

30 CESINF-2016, Universidad de La Laguna

a los algoritmos; P representa el conjunto de instancias de una clase de problemas, mientras queA el conjunto de todos los algoritmos considerados. Por otra parte, F contiene las característicasde un problema x ∈ P. Por último, Y representa la asignación de cada algoritmo a un conjunto demétricas de rendimiento, en función del problema. En base a estos componentes, el problema deselección de algoritmos se puede definir formalmente como: para una determinada instancia x ∈ P,con las características f (x) ∈ F buscar el mapeo S( f (x)) en el espacio del algoritmo A, tal que elalgoritmo seleccionado αinP maximice el rendimiento y(α,x) ∈ Y,y(α,x)≥ y(a,x)∀a ∈ A. Pararesponder a la pregunta formulada anteriormente, se suele analizar los resultados obtenidos en uncostoso estudio computacional, donde se ejecuta una batería de algoritmos A sobre un conjuntorepresentativo de instancias I. Tras analizar los resultados, se escoge el algoritmo y configuraciónque mejor desempeño proporcione en promedio. Esta estrategia implica una reducción de losbeneficios ya que las soluciones proporcionadas por α son de una calidad inferior a la que se podríaproporcionar si se selecciona el mejor algoritmo atendiendo a las características de la instancia.

En este trabajo se propone la aplicación de un sistema basado en Machine Learning [3], capazde proporcionar un ranking de algoritmos en función del problema de entrada a resolver. Es decir,la elección del algoritmo se realiza en base a las características de la instancia y no en base alrendimiento promedio del algoritmo. Se utiliza un generador de instancias general, con el objetivode obtener instancias con diferentes características que representen diferentes escenarios.

PROPUESTA BASADA EN MACHINE LEARNING PARA LA SELECCIÓN DE ALGORITMOS

El proceso de recomendación se muestra en la Figura 1. En primer lugar, es necesario en-trenar el sistema ejecutando el conjunto de algoritmos disponibles a = {A1, . . . ,Am} sobre unabatería de instancias de entrenamiento PT = {xT

1 , . . . ,xTn }. Dichas instancias deben cubrir casi

la totalidad de los escenarios posibles para que el sistema pueda reaccionar adecuadamente an-te las nuevas instancias. Cada algoritmo se ejecuta un cierto número de iteraciones sobre cadauna de las instancias con el fin de obtener los datos de entrenamiento referentes al rendimientoY = {y(Ai,xT

1 ), . . . ,y(Ai,xTn )}. Estos datos deben permitir obtener la calidad de las soluciones y el

rendimiento para cada par algoritmo-instancia, información que empleará el sistema para realizarla recomendación más adecuada en base a las necesidades del usuario. Cada instancia es analizadapara extraer las características F = { f (xT

1 ), . . . , f (xTn )}.

En este punto el sistema se encuentra entrenado, manteniendo una tabla cuyas filas correspondencon cada posible combinación instancia-algoritmo, almacenando las características de extraídas decada instancia f (i) y el algoritmo empleado Ai. Además, cada fila es etiquetada con los resultadosobtenidos y(α,x) tras la ejecución de la experimentación como, por ejemplo, el valor objetivo y eltiempo de cómputo medios.

Posteriormente se aplica un algoritmo de Machine Learning cuya entrada sea la tabla anteriory como salida proporciona una base de conocimiento. La base de conocimiento consiste en unconjunto de rankings ordenados de algoritmos en función de su rendimiento, un ranking por cadainstancia de entrenamiento. Una vez entrenado, cuando el sistema recibe una nueva instancia deentrada para la que se solicita una recomendación, en primer lugar, se extraen las métricas dela instancia, ya sean variables propias de la instancia o calculadas a partir de ella. Éstas debenrepresentar sus características y las del problema para poder detectar de forma adecuada el escenarioque se quiere resolver. Las características que definen la instancia se incluyen posteriormente dentrode un vector para ser comparadas con el conocimiento extraído anteriormente mediante el algoritmode Machine Learning, KNN [4].

En base a este algoritmo se proporciona el ranking de algoritmos recomendados. El ranking seconstruye realizando una agregación de rankings buscando un emparejamiento mínimo mediante elAlgoritmo Húngaro [5] sobre un grafo bipartito. Se recomienda un ranking en lugar de un algoritmoconcreto, debido a que es posible que el primer algoritmo del ranking recomendado no sea el mejor

Sistema basado en machine learning para la selección de algoritmos / A. Dávila 31

algoritmo para esa instancia concreta, sino que este último se encuentre en las n primeras posicionesdel ranking. Por ello, el usuario es capaz de ejecutar estos primeros n algoritmos y quedarse con lamejor solución. El valor n se calcula mediante una validación cruzada del sistema extrayendo tresinstancias de cada escenario y procediendo a su recomendación. El valor de n se calcula obteniendola posición del primer algoritmo del ranking ideal, en el ranking recomendado.

Figura 1: Estructura del sistema basado en ML

Resultados

Para evaluar el sistema se utiliza el problema de asignación de atraques [6] y se emplea lametaheurística LNS [7]. Se generan 72 posibles escenarios y 10 instancias por cada uno de ellos,proporcionando un total de 720 instancias, con un total de 20 etiquetas (diferentes escenarios sepueden etiquetar con las mismas etiquetas). Los escenarios corresponden con modelos prefijadosde posibles situaciones. El conjunto de algoritmos utilizados se compone de la LNS con distintasconfiguraciones de parámetros, modificando el grado de destrucción entre {0,1, . . . ,1}. Durante lavalidación del sistema se determina que el valor óptimo de posiciones del ranking n es 2.

La Tabla 1 muestra los resultados obtenidos agrupados por etiquetas. El coeficiente de correla-ción de Spearman indica como de parecidos son el ranking ideal y el ranking recomendado, siendo1 una coincidencia perfecta y -1 los rankings son inversos. El índice ∆ indica la posición en la quese encontraba el mejor algoritmo dentro del ranking recomendado, se puede observar es bastantesimilar a n. Por cada estrategia se muestra el valor objetivo (Obj.), el tiempo de cómputo (Tiempo) y

32 CESINF-2016, Universidad de La Laguna

el GAP en relación a la mejor solución conocida obtenida por el mejor algoritmo para esa instanciaconcreta.

Índiceetiqueta

Mejor sol.conocida

Sistema ML PromedioObj. T.(s) Gap (%) ∆ Sp. Obj. T. (s) Gap (%)

1 129,67 130,15 0,02 0,33 2,11 0,82 134,17 0,04 3,242 143,23 143,57 0,03 0,22 3,08 0,65 149,96 0,05 4,433 147,77 148,58 0,03 0,48 3,30 0,53 150,78 0,04 1,874 150,92 151,06 0,03 0,09 2,20 0,74 156,26 0,05 3,415 402,40 403,73 0,26 0,33 2,48 0,71 412,87 0,97 2,536 434,27 435,79 0,37 0,36 2,63 0,67 443,93 1,11 3,287 438,45 439,66 0,23 0,30 1,98 0,80 456,14 0,78 4,248 448,80 452,74 0,26 0,58 3,06 0,68 461,01 0,68 3,309 1325,90 1327,21 7,52 0,10 1,25 0,82 1336,15 6,24 1,9010 1356,48 1359,80 8,63 0,29 1,74 0,72 1365,79 6,97 1,7611 1412,62 1414,53 5,00 0,21 1,64 0,83 1431,74 4,35 2,2912 1422,36 1424,01 6,33 0,15 1,48 0,76 1435,34 5,28 1,5113 2965,90 2966,09 15,34 0,01 0,79 0,79 2971,80 14,03 0,1914 3130,05 3133,85 22,00 0,10 0,80 0,77 3134,07 15,78 0,1615 3138,61 3141,18 11,01 0,15 1,39 0,75 3147,46 10,03 0,3516 3255,11 3256,06 15,06 0,05 0,67 0,82 3263,83 11,96 0,2417 4628,44 4628,64 6,41 0,00 0,11 0,85 4631,41 5,84 0,0618 4761,56 4762,75 9,60 0,03 0,59 0,80 4762,83 7,82 0,0319 4933,55 4933,55 8,13 0,00 0,53 0,78 4938,57 6,79 0,1020 5079,95 5079,95 11,07 0,00 0,00 0,78 5079,95 8,89 0,00

Media: 1985,30 1986,64 6,37 0,19 1,59 0,75 1993,20 5,39 1,74

Cuadro 1: Resultados comparativos entre el mejor algoritmo en promedio y el algoritmo recomen-dado. T.=Tiempo, Sp.=Spearman

Como se puede observar en la tabla anterior, el algoritmo que proporciona el mejor rendimientoen promedio obtiene soluciones cercanas a la óptima, pero el sistema propuesto es capaz de mejorardichos resultados consiguiendo un error porcentual (gap) de 0,19% en promedio.

ConclusionesTras realizar el estudio computacional, se puede concluir que el uso del mejor algoritmo en

promedio permite obtener soluciones aceptables, suficiente para algunos escenarios. Sin embargo,el uso de sistemas que analicen las características de las instancias, permiten obtener soluciones demayor calidad, a costa de un leve incremento del tiempo de cómputo debido al uso de algoritmosde ML.

Referencias[1] David H. Wolpert y William G. Macready. No free lunch theorems for search. Informe

técnico. Santa Fe Institute, 1995.

[2] John R. Rice. “The Algorithm Selection Problem*”. En: editado por Morris Rubinoffy Marshall C. Yovits. Volumen 15. Advances in Computers. Elsevier, 1976, páginas 65-118.DOI: http://dx.doi.org/10.1016/S0065-2458(08)60520-3. URL: http://www.sciencedirect.com/science/article/pii/S0065245808605203.

Sistema basado en machine learning para la selección de algoritmos / A. Dávila 33

[3] Ryszard S Michalski, Jaime G Carbonell y Tom M Mitchell. Machine learning: An artificialintelligence approach. Springer Science & Business Media, 2013.

[4] L. E. Peterson. “K-nearest neighbor”. En: 4.2 (2009), página 1883.

[5] H.W Kuhn. “The Hungarian Method for the Assignment Problem”. En: Naval ResearchLogistics 2.1 (1955), páginas 83-98.

[6] Nitish Umang, Michel Bierlaire e Ilaria Vacca. “Exact and heuristic methods to solve theberth allocation problem in bulk ports”. En: Transportation Research Part E: Logisticsand Transportation Review 54 (2013), páginas 14-31. ISSN: 1366-5545. DOI: http://dx.doi.org/10.1016/j.tre.2013.03.003. URL: http://www.sciencedirect.com/science/article/pii/S1366554513000537.

[7] Paul Shaw. “Using Constraint Programming and Local Search Methods to Solve VehicleRouting Problems”. En: Proceedings of the 4th International Conference on Principles andPractice of Constraint Programming. CP ’98. London, UK, UK: Springer-Verlag, 1998,páginas 417-431. ISBN: 3-540-65224-8. URL: http://dl.acm.org/citation.cfm?id=647485.726320.

CESINF 2015 - Trabajos científicos - 4

PROCESAMIENTO DE LA DBPEDIA PARA EJORAR EL ALGORITMO DEANOTACIÓN SEMÁNTICA (ADEGA) BASADO EN GRAFOS PARA EL

ENRIQUECIMIENTO DE CONTENIDO EDUCACIONAL

Adrián Rodríguez BazagaAlumno de 4o del Grado en Ingeniería Informáitca - Universidad de La Laguna

Tutor: Manuel Lama y J.C. VidalCentro de Investigación en Tecnoloxías da Información – Universidad de Santiago de Compostela

ObjetivoEl objetivo de este trabajo es procesar una de las mayores bases de datos semánticas, llamada

DBpedia, para identificar relaciones de longitud n entre conceptos (la DBpedia es una versiónsemántica de la Wikipedia), y una vez extraídas dichas relaciones, se indexarán en una base dedatos para su posterior acceso, lo que nos permite mejorar el algoritmo ADEGA [1] de anotaciónsemántica basado en grafos, utilizado para el enriquecimiento de contenido educacional.

IntroducciónUna de las características de las bases de datos semánticas es que los datos se representan

siguiendo el estándar RDF, es decir, tripletas sujeto-verbo-predicado. Por lo tanto, estas BBDDse pueden ver como un grafo donde cada uno de los nodos del grafo es un concepto (sujeto opredicado) conectados a través de una o varias aristas (verbos). Con BBDD pequeñas es posibledetectar relaciones entre cualquier concepto recorriendo los grafos en anchura o en profundidad, sinembargo, esta aproximación no es efectiva con grafos de varios GB, como es el caso de la DBpedia.

Debido a esto, el objetivo en este trabajo, es el de aplicar técnicas de procesamiento de datosmasivos (Big Data) para extraer estas relaciones y lograr una mejora significativa en la fase deevaluación de nodos del algoritmo de filtrado del grafo de relaciones basado en el contexto.

36 CESINF-2016, Universidad de La Laguna

MétodosEn este trabajo se propone desarrollar un framework de preprocesamiento de los datasets de

la DBpedia que permita mejorar el framework de anotación semántica y enriquericimiento dedocumentos [2], concretamente intensificando (ampliando) los grafos de relaciones resultantes alaplicar el algoritmo de filtrado basado en contexto (ADEGA: All your Documents Enriched withGraph Annotations). Otros trabajos consultados han sido: [3], [4], [5], [6] y [7].

El problema subyacente es que en el estado del arte, debido a que la complejidad del procesa-miento de los datasets es exponencial, el problema se convierte en intratable al ser aplicado teniendoen cuenta relaciones de longitud mayor a 3, debido a que dichas relaciones deben ser extraídas parapoder realizar la evaluación de los nodos (pesar el grafo), algo que se hace en tiempo de ejecución.

Figura 1: Framework de anotación semántica y enriquecimiento de documentos

El tercer paso de la solución conceptual (ver Figura 1) es un algoritmo de búsqueda enprofundidad (DFS) limitado y se aplica a cada nodo devuelto por el módulo de identificación derecursos. El algoritmo representado en “Algoritmo 1”, expande el primer nodo fijo del árbol debúsqueda RDF avanzando niveles de profundidad hasta que se encuentra con un nodo sin hijos o sealcance el límite de profundidad λd . Entonces el DFS vuelve hasta el nodo más reciente que no haterminado de explorar.

ADEGA devuelve el grafo λ que contiene los nodos relevantes para el contexto ∆, empezandopor el nodo ns. En la primera llamada, ns es el nodo devuelto por el módulo de identificación derecursos (URI identification) y Φn, Φc, Φt son listas vacías. Estas 3 listas se utilizan para reducir laexploración de nodos que ya han sido procesados. Específicamente, Φn se utiliza para almacenarlos nodos visitados, y los otros dos, Φc y Φt , para las categorías visitadas y los tipos de clases,respectivamente.

El algoritmo tiene dos partes. En la primera, las relaciones r del nodo procesado nss sonvisitadas, mientras que en la segunda ns es evaluado:

Sólo se procesan las relaciones que tienen una cardinalidad menor a un umbral δi, esto es,relaciones donde |r(ns,)| < δi. Si el número de instancias de relaciones entre r y ns estápor encima de dicho umbral, se considera que la relación es demasiado genérica como paraproveer información relevante sobre el nodo.Cada instancia de la relación r se procesa recursivamente (línea 5). El grafo resultanteADEGA(nt) se añade a la solución λ . Nótese que ADEGA(nt) puede ser un grafo vacío en elcaso de que nt no tenga relevancia para ∆.Si la relación enlaza el nodo con una categoría o un tipo de clase (líneas 6-22 y 23-32,respectivamente), también exploraremos las instancias hermanas, padres e hijas de dichacategoría. El umbral δi también se aplica a los elementos que exploramos ya que tener

Procesamiento de la DBpedia para mejorar ADEGA basado en grafos / A. Rodríguez 37

Relaciones Peso fijadordfs:label 0,70

dbpedia-owl:abstract, is dcterms:subject of, 1,00is rdf:type of, is skos:broader of, is rdfs:subClassOf of, default

dcterms:subject 0,90rdf:type, skos:broader, rdfs:subClassOf 0,60

Cuadro 1: Pesos prefijados de algunas relaciones de la DBpedia

demasiada información penaliza la exploración tanto en calidad de los resultados como entiempo de cómputo.

Figura 2: Algoritmo de filtrado de grafos según contexto (ADEGA)

Durante la fase de filtrado, el algoritmo debe evaluar cada nodo para determinar si es un nodorelevante para el documento que pretendemos enriquecer o no, para ello se deben tener en cuentacierta información:

∆ = el contexto del documento; |Rn| = número de relaciones distintas que tienen a ‘n’ comodominio; i identifica la i-ésima relación de ‘n’; wi es el peso de ‘i’, 0 ≤ wi ≤ 1. Prefijadoen cada relación (ver Tabla 1); |Si,n es el número de instancias de ‘i’ que tienen a ‘n’ comodominio; t identifica la t-ésima instancia de ‘i’, esto es, r(n,nt); nt = nodo objetivo de lat-ésima instancia de ‘i’.

La formula de evaluación de nodos (ver Ecuación 1) tiene dos sumatorios: el sumatorio exterioritera sobre cada relación de n, y multiplica su peso wi por su relevancia. La relevancia de unarelación i se calcula como la media aritmética de la relevancia de los nodos nt de los cuales hay unainstancia de la relación entre n y nt . La formula evalúa cada relación una única vez, con el objetivode balancear la influencia de cada relación. Por ejemplo, suponiendo que tenemos un nodo con 9relaciones diferentes con valores únicos, y una décima relación que tiene 10 valores distintos, si larelevancia del nodo objetivo de cada instancia de la relación fuera añadida independientemente de sies o no multi-valor, la décima relación podría perjudicar el resultado final. Siendo más específicos,imaginemos que la décima relación antes nombrada es el nombre de un personaje y varios de susnombres incluyen un término del contexto, probablemente el nodo evaluado será incluido en elgrafo final, independientemente de la evaluación de otras relaciones. Por esta razón, cada relacióndebe contribuir de forma equitativa.

rel(n,∆) =1|Rn|

|Rn

∑i=1

(wi1

Si,n

|Si,n|

∑t=1

rel(nt ,∆)) (1)

38 CESINF-2016, Universidad de La Laguna

Aplicando técnicas de procesamiento de datos masivos (Big Data), implementando una soluciónmap-reduce mediante Apache Hadoop (ver en la Figura 3 la Arquitectura 1), se han preprocesado losdatasets más relevantes para las instancias de test, los cuales son: SKOS categories, MappingbasedObjects, Instance type, Labels, Disambiguations, Short Abstracts.

Obteniendo como resultado las relaciones semánticas de los conceptos presentes en dichos data-sets con hasta una profundidad de nivel diez, almacenando cada camino de los grafos de relacionessemánticas de cada concepto en una base de datos Cassandra e integrando dicho procesamiento enel algoritmo de filtrado.

Para el salvado de las URIs se ha utilizado un algoritmo de codificación (véase en la Figura 4 elAlgoritmo 2) en Base64 con ASCII ampliado, y así obtener una reducción de cada elemento delas relaciones a cadenas de 5 caracteres alfanuméricos, lo que conlleva una mayor velocidad en lacomparación de cadenas y procesamiento de los datasets, dicho algoritmo cumple las propiedadesde una función biyectiva, es decir si f : X → Y e y = f (x), entonces

∀y ∈ Y : ∃!x ∈ X/ f (x) = y (2)

correspondiendo una URI completa a la cadena codificada, y su vez la correspondencia inversa,por ejemplo:

f(“<dbpedia.org/resource/Mick_Byrne>”) = CUT1Ig(“CUT1I”) = “<dbpedia.org/resource/Mick_Byrne>”

Figura 3: Arquitectura 1: Arquitectura de la implementación map-reduce

ResultadosUna vez integrado el algoritmo de codificación, se consigue una reducción significativa en

cuanto a espacio de almacenamiento de los ficheros resultantes de realizar las uniones mediante

Procesamiento de la DBpedia para mejorar ADEGA basado en grafos / A. Rodríguez 39

Figura 4: Algoritmo 2: Algoritmo de codificación de URIs

Hadoop, ya que por ejemplo, en el nivel 2 de profundidad, cada relación pasa de ocupar 256 bytesa ocupar 24 bytes, por lo tanto, un fichero inicial ordenado por claves y codificado pasa a ocupar∼300MB, mientras que antes ocupaba ∼2.5GB. A su vez, un fichero de relaciones de nivel dosocupa ∼3.6GB, mientras que sin codificar ocupaba ∼40GB, un fichero de relaciones de nivel tresocupa ∼11GB mientras que sin codificar ocupaba ∼140GB, etc.

Por otro lado, las correspondencias de las URIs codificadas y su valor original es guardado enuna base de datos Cassandra (véase comparativa entre BBDD en Figura 5), junto a su correspon-dencia inversa (para maximizar la velocidad de acceso mediante la clave), así como los caminos delas relaciones semánticas de cada concepto con sus respectivos niveles de profundidad, obteniendoasí una posterior mejora drástica de la eficiencia del algoritmo de anotación apoyándonos en el usode dicha BBDD.

Por otro lado, los resultados en la eficiencia del framework son notables, permitiendo ahoraobtener grafos de relaciones semánticas (véase ejemplo en Figura 6) de longitud indeterminada,sin limitar la búsqueda mediante un umbral δi y permitiendo, por ejemplo, mediante el algoritmobidireccional actual y teniendo indexado en base de datos únicamente hasta el nivel 2 de las relacio-nes semánticas con maxd = 20, obtendríamos las relaciones de profundidad en cinco iteracionesde ADEGA; nótese que teniendo indexado hasta el nivel 5 sólo necesitaríamos una iteración,por lo que hemos relajado el problema reduciendo permitiendo obtener grafos ADEGA de granprofundidad en un tiempo aceptable, habiendo procesado los datasets previamente (véase Tabla 2para la comparativa del tiempo de procesado).

ConclusionesEn este trabajo se ha propuesto un algoritmo de anotación semántica mejorado mediante la

integración de soluciones Big Data para el enriquecimiento de contenido educacional.Comparando nuestro resultado con otras propuestas disponibles en la literatura hemos notado

40 CESINF-2016, Universidad de La Laguna

Figura 5: Comparativa de operaciones/segundo entre distintas bases de datos

Figura 6: Ejemplo de grafo semántico enriquecido mediante el algoritmo ADEGA

Tiempo de procesado Profundidad 2 Profundidad3Inicialmente (tiempo real) ∼ 1460 horas ∼ 14016000 horas

Actualmente (Hadoop) ∼ 30 minutos ∼ 1 hora 30 minutos

Cuadro 2: Resultados obtenidos para el tiempo de procesado

que muchas de las herramientas de anotación anotan términos a través de una única instancia, porlo que no podemos realizar una comparación justa ya que obtendrían un ratio de precisión muybajo, sólo RelFinder tiene un mecanismo de anotación similar y por lo tanto puede ser comparadocon nuestra aproximación, los resultados muestran que nuestra solución supera notablemente aRelFinder, tanto en precisión como en recall.

Para continuar el proyecto de investigación presentado en este trabajo, nuestra intención esanalizar el comportamiento de nuestro sistema de anotación basado en grafos para utilizarla encombinación con sistemas de guía turística, dónde ciertos elementos del lugar (como monumentos

Procesamiento de la DBpedia para mejorar ADEGA basado en grafos / A. Rodríguez 41

emblemáticos) pueden ser enriquecidos con información utilizando el sistema propuesto paraofrecer al usuario mayor información de interés.

Referencias[1] Estefanía Otero-García, Juan C. Vidal, Manuel Lama, Alberto Bugarín y José E. Domenech.

“A context-based algorithm for annotating educational content with Linked Data”. En: 3rdFuture Internet Symposium (FIS 2010), FIS-Workshop on Mining Future Internet (MIFI2010). 2010.

[2] Juan C. Vidal, Manuel Lama, EstefanÃa Otero-GarcÃa y Alberto BugarÃn. “Graph-basedsemantic annotation for enriching educational content with linked data”. En: Knowledge-Based Systems 55 (2014), páginas 29-42. ISSN: 0950-7051. DOI: http://dx.doi.org/10.1016/j.knosys.2013.10.007. URL: http://www.sciencedirect.com/science/article/pii/S0950705113003183.

[3] Estefanía Otero-García, Juan C. Vidal, Manuel Lama, Alberto Bugarín y José E. Domenech.“Semantic Annotation of Educational Resources through Linked Data”. En: New Horizonsin Web-Based Learning - ICWL 2010 Workshops: ICWL 2010 Workshops: STEG, CICW,WGLBWS, and IWKDEWL, Shanghai, China, December 7-11, 2010 Revised Selected Pa-pers. Editado por Xiangfeng Luo, Yiwei Cao, Bo Yang, Jianxun Liu y Feiyue Ye. Berlin,Heidelberg: Springer Berlin Heidelberg, 2011, páginas 311-320. ISBN: 978-3-642-20539-2.DOI: 10.1007/978-3-642-20539-2_33. URL: http://dx.doi.org/10.1007/978-3-642-20539-2_33.

[4] J. C. Vidal, M. Lama, E. Otero-García y A. Bugarín. “An evolutionary approach for learningthe weight of relations in linked data”. En: 2011 11th International Conference on IntelligentSystems Design and Applications. Nov. de 2011, páginas 1002-1007. DOI: 10.1109/ISDA.2011.6121789.

[5] Atanas Kiryakov, Borislav Popov, Ivan Terziev, Dimitar Manov y Damyan Ognyanoff.“Semantic Annotation, Indexing, and Retrieval”. En: Web Semantics: Science, Servicesand Agents on the World Wide Web 2.1 (2004). ISSN: 1570-8268. URL: http://www.websemanticsjournal.org/index.php/ps/article/view/53.

[6] ENRICO MOTTA, SIMON BUCKINGHAM SHUM y JOHN DOMINGUE. “Ontology-driven document enrichment: principles, tools and applications”. En: International Journalof Human-Computer Studies 52.6 (2000), páginas 1071-1109. ISSN: 1071-5819. DOI: http://dx.doi.org/10.1006/ijhc.2000.0384. URL: http://www.sciencedirect.com/science/article/pii/S1071581900903847.

[7] Francisco Bueno, Ana GarcÃa-Serrano y Josà c© L. MartÃnez-Fernández. “Enrichmentof text documents using information retrieval techniques in a distributed environment”.En: Expert Systems with Applications 37.12 (2010), páginas 8348-8358. ISSN: 0957-4174.DOI: http://dx.doi.org/10.1016/j.eswa.2010.05.048. URL: http://www.sciencedirect.com/science/article/pii/S0957417410004598.

IV

Predicción de abandonos en cursos online masivosy abiertos / Manuel BacalladoComparativa de fusión y reorganización en GIT /J.T. Villar y I. GonzálezTécnicas de optimización multi-objetivo en la plani-ficación de menús / J.M. RamosEstudio de las alertas del servicio 112 / V. Plaza

Contribuciones: trabajosacadémicos

CESINF 2016 - Trabajos académicos - 1

PREDICCIÓN DE ABANDONOS EN CURSOS ONLINE MASIVOS YABIERTOS

Manuel Alejandro Bacallado LópezGraduado en Ingeniería Informática – Universidad de La Laguna

Tutor: Jesús Manuel Jorge SantisoDepartamento de Ingeniería Informática y Sistemas - Universidad de La Laguna

ObjetivoExponer la integración y uso de la biblioteca de clases de RapidMiner Studio 7.0 en el desarrollo

de una aplicación para resolver problemas de minería de datos mediante el caso práctico “Predicciónde abandonos en cursos online masivos y abiertos”.

IntroducciónEl aumento del volumen y variedad de información que se encuentra informatizada en bases de

datos digitales y otras fuentes ha crecido espectacularmente en las últimas décadas. Gran parte deesa información es histórica, representando situaciones que se han producido. Esta información esútil para explicar situaciones pasadas, comprender el presente y poder hacer predicciones sobre elfuturo.

La mayoría de las decisiones de empresas, organizaciones e instituciones se basan también eninformación sobre experiencias pasadas extraídas de diversas fuentes. Por ello parece ineludible lanecesidad de analizar los datos para extraer información útil para la organización. Complicando aúnmás el problema, hay que tener en cuenta que los datos pueden proceder de fuentes muy diversas ypertenecer a diferentes dominios.

Para solucionar este problema, se integran numerosas técnicas de bases de datos, análisis dedatos y extracción de modelos, dando lugar a un campo de conocimiento denominado Minería deDatos.

46 CESINF-2016, Universidad de La Laguna

Se trata de extraer patrones, describir tendencias y regularidades, predecir comportamientos ysacar el máximo potencial a la información almacenada ya sea en ficheros, sistemas gestores debases de datos o almacenes de datos mediante técnicas adecuadas de minería de datos. De estaforma, las personas y empresas tienen a su disposición una forma eficiente de actuar y de tomardecisiones.

En este documento, se va a utilizar la Minería de Datos para realizar una clasificación de losalumnos matriculados en los cursos online masivos y abiertos, prestando atención a su posibleabandono o finalización con éxito. Para ello se ha implementado una aplicación en Java [1] queutiliza algunos de los algoritmos incluidos en la biblioteca de clases RapidMiner Studio 7.0 [2]. Enel desarrollo del proyecto, se han utilizado las siguientes técnicas y herramientas: bases de datos [3]para el almacenamiento de los datos pertenecientes al problema y control de versiones [4], pruebasunitarias [5] y documentación del código fuente para el desarrollo del software [6].

Rapidminer studio 7.0

RapidMiner Studio 7.0 es una herramienta software para el análisis de datos, empleandotécnicas de minería de datos.

La forma de trabajar de RapidMiner es mediante el uso de operadores, que representan tanto alos pasos previos de un proceso de KDD (Knowledge Discovery in Databases o Descubrimiento deconocimiento en bases de datos en castellano) tales como la preparación de los datos, como a losalgoritmos de minería de datos a utilizar y la presentación de los resultados.

El KDD es un proceso complejo que incluye no solo la obtención de los modelos o patrones,sino la evaluación, interpretación y visualización del mismo, además de la generación de nuevascaracterísticas, por lo que finalmente la minería de datos es una fase dentro de este proceso.

Una de las características más importantes de RapidMiner es su sistema “Drag and drop", elcual permite arrastrar los operadores a su panel central, conectarlos y configurarlos sin problemaalguno.

Figura 1: Herramienta RapidMiner Studio 7.0

Caso de estudio

Los cursos masivos online y abiertos (en inglés, Massive Open Online Course (MOOC))revolucionan la educación, ya que proveen fácil acceso a los materiales de un curso medianteInternet. Este tipo de cursos tienen una gran aceptación respecto a los cursos en los centrostradicionales, gracias a la disponibilidad de los materiales y su bajo coste. Sin embargo, aparte deestas ventajas, también tienen una enorme desventaja: la tasa de abandono de los cursos suele sermuy alta.

Predicción de abandonos en cursos online masivos y abiertos / Manuel Bacallado 47

El proyecto que se va a describir en este documento trata de analizar los datos del desafíoplanteado en el KDD Cup 2015 (Predicting dropouts in MOOC).

KDD Cup es una competición anual de minería de datos y descubrimiento de conocimientoorganizado por la entidad ACM (Association of Computing Machinery). En esta competición seplantea un problema, se proporcionan los datos, los objetivos para superar la prueba, las restriccionesde la misma y la recompensa para los primeros ganadores.

Estos datos se han insertado en una base de datos. Se han renombrado al castellano los atributosoriginales para una mejor compresión de los mismos. Se han realizado consultas previas paraconocer que, sin realizar ningún tipo de conocimiento nuevo o minería de datos, el porcentaje deabandono es del 79%, siendo el objetivo del proyecto obtener una precisión predictiva superior aese 79% y finalmente se ha generado una batería de cuestiones sobre estos datos iniciales, medianteconsultas realizadas en la base de datos, que nos ha proporcionado una vista minable con todos losatributos necesarios para su posterior uso con las técnicas de minería de datos.

Aplicación softwareUtilizando los operadores de RapidMiner Studio 7.0, se ha decidido desarrollar una interfaz

gráfica de usuario (GUI) para el uso de las técnicas de minera de datos, necesarias para resolver elcaso de estudio, comentado en la sección anterior. La aplicación está desarrollada en el lenguajeJava, utilizando la biblioteca gráfica Swing, patrones de diseño tales como “Strategy”, “Observer”y “MVC” [7]. Cabe destacar que en su interior no estarán todos los operadores existentes enRapidMiner configurados, únicamente los necesarios para realizar un proceso de clasificación.

Figura 2: Interfaz gráfica del usuario

La aplicación está estructurada en diversas secciones reconocibles en la vista principal (Figura2):

Sección superior: En esta sección se encuentran los botones que inicia el proceso una vezconfigurado (Start Process), el de resetear el proceso (Reset Process) y el de parar el proceso

48 CESINF-2016, Universidad de La Laguna

(Stop Process).Sección lateral izquierda: En esta sección están los operadores del conjunto de entrenamiento,del conjunto de prueba y los operadores necesarios para aplicar el modelo.Sección lateral derecha: En esta sección se mostraría la predicción obtenida una vez ejecutadoel proceso.Sección inferior: En esta sección se encuentra organizado por “pasos"las distintas seccionesque componen un proceso de minería de datos. Su interior está compuesto por un cuadrode dialogo en donde se podría seleccionar la categoría y configurar el operador que mejorsatisfaga la necesidad del usuario.

Resultados

Para obtener los resultados, se han utilizado tanto la interfaz gráfica creada, como RapidMinerStudio 7.0 y se han utilizado los siguientes algoritmos de minería de datos: “K-nn”, “Árbol dedecisión (Decision Tree)” y “Naive Bayes” (consultar la documentación de RapidMiner [8]).

En RapidMiner Studio 7.0, se ha utilizado el operador “Compare ROCS” [8] para calcular lacurva roc de los algoritmos ejecutados. Los resultados se muestran en la figura 3

Figura 3: Curva ROC resultante

Se puede observar que el algoritmo que ofrece el mejor resultado es el árbol de decisión(Decision Tree), seguido del K-nn y por último el Naive Bayes. Esto se debe a la altura de las curvasque genera el operador. En la versión actual de la aplicación desarrollada, los resultados se guardanen un archivo csv. Se han ejecutado por separado los algoritmos utilizando sus configuracionesbásicas y ofreciendo como resultado una predicción predictiva superior al 79% obtenido sin haberaplicado ninguna técnica de minería de datos.

Los resultados para el árbol de decisión, K-nn y Naive Bayes se muestran en la tabla 3

Conclusiones

Con este trabajo se ha profundizado en el interesante y beneficioso área de la minería de datos,resolviendo eficazmente un caso práctico para los cursos online masivos y abiertos y desarrollandouna aplicación en Java utilizando los operadores internos de RapidMiner Studio 7.0. Ambos sontemas de actualidad, el análisis del seguimiento de los cursos online por sus masivas inscripciones

Predicción de abandonos en cursos online masivos y abiertos / Manuel Bacallado 49

Técnica Criterio ValorÁrbol de decisión Accuracy 0,8549

K-nn Accuracy 0,8950Naive Bayes Accuracy 0,8474

Cuadro 3: Resultados para el árbol de decisión, el K-nn y Naive Bayes.

y la minería de datos por su potencial para resolver problemas relacionados con el tratamiento deingentes cantidades de datos.

Referencias[1] Java. URL: https://www.java.com/es.

[2] Biblioteca de clases de RapidMiner Studio 7.0. URL: https://github.com/rapidminer/rapidminer-studio.

[3] SGBD MarÃa DB. URL: https://mariadb.org/.

[4] Git. URL: https://git-scm.com.

[5] JUnit. URL: http://junit.org/junit4/.

[6] Doxygen. URL: http://www.stack.nl/%20dimitri/doxygen/.

[7] E. Freeman, E. Robson, B. Bates y K. Sierra. Head First Design Patterns. O’Reilly Media,2004.

[8] Documentación de RapidMiner. URL: http://docs.rapidminer.com.

CESINF 2016 - Trabajos académicos - 2

COMPARATIVA DE FUSIÓN Y REORGANIZACIÓN EN GIT

Julián Tanausú Villar Vázquez y Iván González AguiarAlumnos de 3o Grado de Ingeniería Informática - Universidad de La Laguna

Tutor: Coromoto LeónDepartamento de Ingeniería Informática y Sistemas - Universidad de La Laguna

ObjetivoGit es un sistema de control de versiones que se ha convertido en el estándar de facto. Estos

sistemas se encargan de registrar los cambios realizados sobre un archivo o un conjunto de archivosa lo largo del tiempo, de forma que más adelante se puedan recuperar versiones. El objetivo de estetrabajo es mostrar las diferentes formas con las que se puede organizar un determinado repositorioGit. Existen dos posibilidades: mediante una fusión (“merge”) o una reorganización (“rebase”). Através de un ejemplo se mostrará la diferencia entre ambas.

IntroducciónGit es un sistema de control de versiones que surge para cubrir las necesidades de gestión de un

proyecto grande como es el mantener el Sistema Operativo Linux. Se trata de un sistema de controlde versiones distribuido, esto es, las distintas versiones se almacenan tanto en un servidor como enlas máquinas locales de todos los participantes, aportando todos ellos contenido.

En este artículo se hará una simulación de cómo sería el desarrollo de una aplicación de formacolaborativa usando Git mostrando sus distintas formas de funcionamiento. Se han usado las fuentes[1, 2, 3, 4]

MétodosPara la realización de este trab ajo se ha utilizado GitHub que es una plataforma de desarrollo

colaborativo para alojar proyectos utilizando el sistema de control de versiones Git. También para

52 CESINF-2016, Universidad de La Laguna

la realización del código fuente se ha usado el lenguaje de programación Ruby, un lenguaje deprogramación orientado a objetos e interpretado.

Se desarrollará la clase “Point” para representar puntos en unas coordenadas cartesianas.Posteriormente se comprobará su correcto funcionamiento mediante la creación de “pruebasunitarias”. Se trabajará de la siguiente manera:

Se codifica una determinada funcionalidad de la clase Point y se añadirá al repositorioGitHub.Se escribirá el código para probar esta funcionalidad y se añadirá al repositorio GitHub.

Cada componente del equipo desarrollará su parte del código en una rama diferente. El encar-gado de la implementación de la clase trabajará en la rama denominada desarrollo y el encargadode generar las pruebas unitarias trabajará en la rama llamada test. Una vez implementado un bloquede código y sus correspondientes pruebas se procederá a la fusión o a la reorganización para unirlas dos ramas del proyecto.

En primer lugar el encargado de escribir la parte correspondiente al código fuente de la clasedesarrollará la definición del método initialize, donde se inicializan los atributos del objeto de laclase punto y el método to_s, que devolverá una cadena con la representación del objeto. Guardaráuna versión en su repositorio local mediante el comando git commit. A continuación subirá sutrabajo a GitH ub en la rama correspondiente con el comando git pull.

Ahora es el turno del encargado de las pruebas, que deberá escribir un pequeño código paraprobar que los métodos funcionan de forma adecuada. En primer lugar prepara en el método setupel conjunto de las variables a probar. Luego en las pruebas simples escribe afirmaciones ( asserts)para probar los métodos initialize y to_s, de esta forma se comprueba que las variables se inicializanbien y que luego se transforman en cadenas sin problemas. Una vez realizado esto, mediante elcomando git commit creará una nueva versión local y también subirá su parte a GitHub, en la ramaadecuada.

Se procede entonces a realizar una fusión (merge). Para ello, el miembro del grupo responsablede dicha tarea deberá descargar todas las ramas del repositorio remoto a su máquina mediante elcomando git pull –all, una vez hecho esto procederá a la fusión mediante el comando git merge.

Una vez mezclado el trabajo de ambas ramas se ejecutan las pruebas, utilizando la herramientarake, y si son satisfactorias se suben todos los cambios al repositorio remoto mediante git push-u origin master, que dejará el código que funciona perfectamente en la rama denominada masterdonde irá el resultado final del trabajo. En este momento, el otro miembro del equipo puededescargar la versión fusionada a su máquina local mediante el comando git pull –all.

A continuación el encargado del código fuente proseguirá su trabajo realizando los métodospara la multiplicación y el cambio de signo. Por otro lado, en la rama test, el encargado de laspruebas realizará las pruebas para los métodos que se están desarrollando. Una vez todos terminen,se procede a subir cada uno su trabajo en su rama en el repositorio remoto. Después el encargadode la fusión descarga todo el contenido del repositorio y se procede a realizar otra fusión. De estamanera se podrá probar el código fuente nuevo añadido al proyecto. Ahora el otro componente delequipo descarga todo el repositorio remoto a su máquina.

En este último paso se procede al desarrollo del método para la suma de las coordenadas de unpunto. El encargado del código fuente realizará el desarrollo del código fuente en la rama desarrolloy el encargado de las pruebas realizara el código fuente para las pruebas en la rama test. Una vezterminado todo se procederá, en este caso, a realizar una reorganización (rebase). Una vez cadauno haya terminado con su parte del trabajo lo subirán a GitHub, ahora el encargado de realizar lareorganización se bajará todo lo que haya en el repositorio remoto y realizará una reorganizaciónen local para probar el código mediante el comando git rebase.

Comparativa de fusión y reorganización en GIT / J.T. Villar y I. González 53

Figura 1: Resultado del proceso de creación de confirmaciones

ResultadosEl resultado del proceso de creación de las confirmaciones del control de versiones se ve

reflejado en el siguiente grafo (figura 1):Se observa en el grafo, que empieza desarrollando en la rama principal ( master), donde se

llevan a cabo tres confirmaciones locales que se suben al repositorio remoto.A continuación se separa el desarrollo en dos ramas ( Test y Desarrollo), cada miembro del

equipo realizará dos confirmaciones en cada una de las ramas y las subirá al repositorio remoto.Uno de los miembros del equipo actualizará su repositorio local a la última versión.

Luego hará una fusión entre las ramas Test y Desarrollo y acto seguido de la rama desarrollo ala rama master, la fusión o merge realiza una mezcla de contenidos entre las ramas, por lo que larama master tendrá el trabajo realizado, tanto en la rama Test como en la rama Desarrollo. Comose aprecia en el grafo la fusión crea una sola confirmación automática en la rama master, una vezrealizado, el miembro del equipo empuja el trabajo en el repositorio remoto. Una vez finalizado, elotro integrante del equipo la recupera para actualizarse a la última versión.

Se vuelve a trabajar por separado, cada miembro del equipo en una rama, como sucedía antesde realizar la fusión, haciendo cada uno dos confirmaciones, ambas subidas al repositorio remoto.Uno de los integrantes, descarga la última versión y procede a la realización de la reorganización.En primer lugar hará una reorganización de la rama Test sobre Desarrollo, el resultado de esto esque en la rama Desarrollo se encontrarán también las confirmaciones realizadas en la rama Test.En segundo lugar, se reorganiza (rebase) la rama Desarrollo en la rama master, donde todas lasconfirmaciones existentes actualmente en la rama Desarrollo pasarán a la rama master situadas acontinuación de la última confirmación realizada en dicha rama C8.

ConclusionesComo resultado de la realización de este trabajo se obtiene un grafo en el que quedan patentes

las diferencias que existen entre estos dos métodos de organización disponibles en la herramientapara el control de versiones Git.

La fusión ( merge), mezcla el contenido de las ramas insertandolo en una única confirmacióncreada de forma automática, a diferencia, de la reorganización ( rebase) que no solamente mezclael contenido, si no que lo hace guardando todas las confirmaciones de la rama reorganizada.

Referencias[1] Dave Thomas. Programming Ruby 1.9. Pragmatic Bookself, 2013.

54 CESINF-2016, Universidad de La Laguna

[2] Sitio web del lenguaje Ruby. URL: https://www.ruby-lang.org/es/.

[3] Sitio web de Github. URL: https://github.com.

[4] Scott Chacon. Pro Git. Apress, 2014.

CESINF 2016 - Trabajos académicos - 3

TÉCNICAS DE OPTIMIZACIÓN MULTI-OBJETIVO APLICADAS ALPROBLEMA DE PLANIFICACIÓN DE MENÚS

Juan Manuel Ramos PérezGraduado en Ingeniería Informática – Universidad de La Laguna

Tutor: Gara Miranda ValladaresDepartamento de Ingeniería Informática y Sistemas - Universidad de La Laguna

ObjetivoEl objetivo de este Trabajo Fin de Grado ha sido el desarrollo de una aplicación mediante

una formulación de optimización multi-objetivo cuyo propósito es la planificación de un menúescolar. La aplicación tiene como principal objetivo ofrecer un plan alimenticio variado, económicoy equilibrado desde el punto de vista nutricional para un número de días determinado, asegurandoasí la adecuada alimentación de los niños. También se tendrán en cuenta aspectos como las posiblesalergias e intolerancias alimenticias que pueda poseer una persona y por las cuales requiera un planalimenticio especial.

IntroducciónEl problema del planificador de menús consiste en la generación de un plan dietético, gene-

ralmente semanal o mensual, compuesto por menús saludables para las principales comidas deldía. Es importante que el menú generado se adapte a las condiciones fisiológicas del usuario,principalmente su género y edad, ya que la cantidad de nutrientes recomendados a consumir varíasegún estos factores.

En este proyecto se plantea la creación de un planificador de menús dirigido a un comedorescolar, lo cual conlleva una serie de particularidades que lo diferencian del problema general. Enprimer lugar los comedores escolares trabajan principalmente en horario de mediodía, por lo que larecomendación de menús se hará para el almuerzo. En segundo lugar está dirigido exclusivamente

56 CESINF-2016, Universidad de La Laguna

a niños. Debido a que la distinción de nutrientes recomendados en niños no difiere en exceso poredad o género (según datos de la Asociación Española de Pediatría [1]), la aplicación no hará estadistinción.

Los aspectos a tener en cuenta por la aplicación serán el coste de los menús y la variedad delos platos. Estos dos aspectos serán considerados los dos objetivos del problema. Las restriccionesdel problema estarán compuestas por la ingesta recomendada de nutrientes. También se tendrán encuenta las principales incompatibilidades alimenticias y alérgenos que pueda poseer alguno o variosde los usuarios por lo que requieran de un plan alimenticio diseñado específicamente para ellos.

Métodos

Menu Planning AppLa idea tras el desarrollo de esta aplicación es que cualquier usuario, independientemente del

nivel de conocimiento y manejo de aplicaciones informáticas que posea, sea capaz de utilizar laherramienta. Para ello la aplicación dispone de una interfaz sencilla, fácil de manejar y con undiseño intuitivo que permite comprender todo lo que la aplicación contiene y de lo que es capaz.

La aplicación, desarrollada en Qt [2] mediante el lenguaje C++, está compuesta por cuatroventanas principales más una pantalla de inicio. En primer lugar la pantalla o sección de ingredientes,donde el usuario podrá añadir a la aplicación todos los ingredientes que desee con su respectivainformación nutricional, alérgenos, incompatibilidad alimenticia, precio, etc. Este conjunto deingredientes será necesario para la segunda pantalla, la sección de platos. En esta pantalla se podráncrear los platos que se desee con los ingredientes anteriormente mencionados y almacenadosen la aplicación. Los platos pueden ser divididos en primer plato, segundo plato y postre. Latercera sección corresponde al planificador de menús (ver Figura 1), desde donde el usuariopodrá especificar características del plan alimenticio que se vaya a generar, como, por ejemplo,los platos que quieren que sean considerados, la duración en días del plan alimenticio, y si sedebe diseñar un plan especial para personas con determinados alérgenos o incompatibilidadesalimenticias. Finalmente, la última pantalla se utiliza para visualizar el plan alimenticio, con losmenús correspondientes a cada uno de los días.

Figura 1: Menu Planning App – Ventana del planificador

Técnicas de optimización multi-objetivo en la planificación de menús / J.M. Ramos 57

Algoritmos Evolutivos Multi-ObjetivoLos algoritmos evolutivos son una familia de técnicas metaheurísticas basadas en población e

inspiradas en la evolución de las especies. Estas técnicas han sido utilizadas satisfactoriamente ennumerosos problemas de gran complejidad en diferentes campos científicos y tecnológicos.

Trasladando el concepto de la evolución natural a la resolución de problemas de optimización,en este tipo de problemas tenemos funciones objetivo a optimizar sujetas a unas determinadasrestricciones. En estos algoritmos se hace uso de funciones de aptitud para averiguar cuan buenaes una solución con respecto a los objetivos. La calidad de este valor de aptitud determinará siuna solución es apta para la supervivencia en la población y su reproducción. Los algoritmosevolutivos de optimización multi-objetivo (Multi-Objective Evolutionary Algorithm, MOEA) [3]son algoritmos evolutivos diseñados específicamente para dar solución a problemas de optimizaciónmulti-objetivo. Son capaces de lidiar con un conjunto de soluciones y obtener una aproximación delfrente de Pareto en una solo ejecución ofreciendo buenas aproximaciones y en tiempos de ejecuciónrazonables. El algoritmo utilizado es el NSGA-II (Non-dominated Sorting Genetic Algorithm) [4],uno de los MOEA más utilizado. Hace uso de método denominado fast non-dominates sortingque reduce la complejidad computacional del mismo y un operador llamado crowded comparisonutilizado para ordenar a los individuos.

Algoritmo implementadoLa creación de un plan alimenticio consiste en la generación de un número de menús igual al

número de días que el usuario seleccione en la aplicación. Un menú para un día está compuestopor primer plato, segundo plato y postre. Para generar un plan alimenticio el algoritmo ejecuta unaserie de procedimientos.

En primer lugar se seleccionan los platos elegidos por el usuario para trabajar únicamente conellos. Se genera una tabla de compatibilidad de platos en los que se le dará un valor numérico acada combinación de platos indicando cuan buena es dicha combinación. Esto será de utilidadpara tener una idea de la variedad existente en los menús. Seguidamente se hace un cálculo de laingesta recomendada de nutrientes en base al número de días seleccionados. Una vez hecho esto secomienza a crear individuos, o planes alimenticios, en primer lugar generando los menús de formaaleatoria para posteriormente, calculados los objetivos de coste y variedad del plan así como sucumplimiento o no de las restricciones del problema, evaluar su calidad, cruzarlos para obtenernuevas soluciones y pasar a la siguiente generación de soluciones, siendo estas generalmente demayor calidad que las anteriores.

ResultadosUna de las características del trabajo con algoritmos evolutivos es su particular sensibilidad

a los resultados obtenidos debido a la experimentación con diferentes parámetros de entrada quese les administra. Incluso para los mismos parámetros de entrada, el carácter estocástico de estetipo de algoritmos puede ofrecer resultados con un rango variado en cuanto a la calidad de lassoluciones.

Los parámetros de entrada que se han utilizado y para los que las pruebas realizadas hanmostrado ofrecer mejores resultados se mostrarán a continuación. Los resultados de las pruebas(ver Figura 2) representan los mejores planes alimenticios obtenidos en cada generación mostrada,teniendo como funciones objetivo el precio del plan alimenticio y el grado de repetición de losmenús, ambos objetivos a minimizar.

N = tamaño de la población = 50nGen = número de generaciones = 200pC = probabilidad de cruce = 0.9pM = probabilidad de mutación = 0.1CDist = mínimo valor de crowding distance = 0.4

58 CESINF-2016, Universidad de La Laguna

Figura 2: Resultados obtenidos con los parámetros de entrada óptimos.

ConclusionesEl problema de la malnutrición de la población junto con la capacidad de la tecnología actual

para interactuar con la sociedad y servir de apoyo a sus necesidades han impulsado la realizaciónde este trabajo, consistente en el desarrollo de una aplicación capaz de realizar planes alimenticioscompuestos por menús equilibrados desde el punto de vista nutricional para niños en centrosescolares. También se persigue una máxima variedad en los menús y precios reducidos, los cualesrepresentan los objetivos del problema, teniendo en consideración adicionalmente, los principalesalérgenos e incompatibilidades alimenticias más comunes entre la población, pretendiendo asíobtener planes alimenticios de calidad y adaptables a personas con requerimientos nutricionalesespeciales.

El problema que se está tratando es el llamado Menu Planning, o planificador de menús, unproblema de optimización multi-objetivo para el que se ha hecho uso de técnicas metaheurísticaspara su resolución. Más concretamente se ha utilizado el algoritmo NSGA-II, un algoritmo pertene-ciente a la familia de algoritmos evolutivos que ha demostrado ofrecer buenos resultados en estetipo de problemas.

Referencias[1] AEP. Libro blanco de la nutrición infantil. URL: http://www.aeped.es/sites/default/

files/documentos/libro_blanco_de_la_nutricion_infantil.pdf.

[2] Qt Documentation. URL: http://doc.qt.io/qt-5/.

[3] Carlos A. Coello, Gary B. Lamont y David A. Van Veldhuizen. Evolutionary Algorithms forSolving Multi-Objective Problems. Springer, 2007.

[4] Kalyanmoy Deb, Amrit Pratap, Sameer Agarwal y T. Meyarivan. “A fast and elitist multi-objective genetic algorithm:” en: IEEE TRANSACTIONS ON EVOLUTIONARY COMPU-TATION 6.2 (2002).

CESINF 2016 - Trabajos académicos - 4

ESTUDIO DE LAS ALERTAS DEL SERVICIO 112 UTILIZANDO TÉCNICASDE CIENCIA DE LOS DATOS

Víctor Plaza MartínGraduado y alumno del máster en Ingeniería Informática – Universidad de La Laguna

Tutor: Carlos Pérez González 1 Marcos Colebrook Santamaría 2 José Luis Roda García 2

(1) Dpt. de Matemáticas, Estadística e Investigación Operativa – Universidad de La Laguna(2) Dpt. de Ingeniería Informática y de Sistemas – Universidad de La Laguna

Objetivo

En este trabajo se presenta un proyecto de tratamiento y análisis de datos realizado en colabo-ración con el Centro Coordinador de Emergencias y Seguridad (CECOES) 1-1-2 de Canarias, apartir la información de alertas e incidencias gestionadas por el servicio durante los últimos 10años. El análisis se ha llevado a cabo en sucesivas etapas comenzando en la importación de datos ynormalización de la información hasta su representación mediante tablas y gráficos mediante unaherramienta web de cuadros de mando. La funcionalidad de dicha herramienta se presenta mediantealgunos ejemplos ilustrativos, siendo el objetivo final la generación de conocimiento útil para elCentro Coordinador de Emergencias y Seguridad en base a unos datos actualmente infrautilizados.

Introducción

El Centro Coordinador de Emergencias y Seguridad (CECOES) 1-1-2 del Gobierno de Canarias,dependiente de la Consejería de Política Territorial, Sostenibilidad y Seguridad, es el serviciopúblico que da respuesta a todas las llamadas de emergencia que se producen en el Archipiélagocanario. Su funcionamiento está encomendado a la empresa pública Gestión de Servicios parala Salud y Seguridad en Canarias (GSC). El 1-1-2 de Canarias es un centro coordinador desdeel que se gestionan los recursos de emergencia que existen en el Archipiélago, de tal forma que

60 CESINF-2016, Universidad de La Laguna

cualquier alerta, ya sea sanitaria, de seguridad, salvamento, extinción o rescate, recibe una respuestainmediata e integral.

Una vez que el ciudadano realiza una llamada al 1-1-2, ésta es respondida por un operadorespecializado en atender las peticiones de ayuda ante cualquier tipo de urgencia o emergencia.Mientras se toman los datos haciendo uso de unos protocolos automáticos, la llamada se clasifica yse determina el recurso adecuado a enviar, ya pueda ser sanitario, de salvamento, de seguridad. . .El operador se ayuda de un software que se encarga a través de un cuestionario de clasificar el tipode incidencia con el fin de asignar los recursos más adecuados, quedando toda esta informaciónregistrada en bases de datos Access.

Dada esta problemática se plantea la posibilidad de obtener información relevante para el 112de manera que se analice, se encuentren patrones o relaciones entre las variables y llegado el casose planteen sugerencias de asignación de los recursos con el fin de mejorar la calidad del servicioprestado.

Procesamiento y análisis de datos

El 112 dispone de un registro histórico de todas las incidencias o alertas gestionadas en ambasprovincias canarias desde el año 2005 hasta la actualidad. Esto hace que el volumen de datos delque hablamos ronde las 700000 incidencias anuales, compuesta cada incidencia por 21 variablesantes del proceso de filtrado y limpieza.

Dicho proceso de filtrado y limpieza de los datos se volvió una necesidad debido a la he-terogeneidad de los mismos, y el factor humano presente en el momento de la captación. Paraejemplificar esto, una variable a priori categórica como puede ser la variable sexo, con 2 o tresvalores a lo sumo, llegó a contar con 18 posibles valores que hacían que el análisis de los mismosfuese imposible. Cabe destacar que los datos se encontraban en todo momento anonimizados paraproteger la intimidad de las personas, ya que se trabajamos siempre con datos reales.

Por tanto, se han llevado a cabo diversas tareas de adquisición de datos (utilizando el softwareR) y se han preparado de forma previa a su análisis (depuración, normalización, etc..). En estesentido, se han obtenido diversas variables de interés para el estudio:

Sexo y edad de la persona que es objeto de la alerta.Fecha y hora del inicio y final de la alerta.Municipio donde tiene lugar el incidente.Tipología del incidente (tráfico, incendio, etc. . . ).Valoración del incidente (leve, grave, etc. . . ).Recursos movilizados para la atención de la incidencia (policía, bomberos, etc. . . ).

Una vez los datos se han limpiado y se puede trabajar con ellos se opta por un desarrollo basadoen una arquitectura MVC (modelo vista-controlador) de tal manera que abstraemos los datos y lalógica de negocio de la interfaz de usuario.

Haciendo uso del IDE RStudio generamos automáticamente un proyecto de estas característicasde manera que el fichero “ui.R” hace referencia a la interfaz de usuario, y el fichero “server.R”cuenta con el procesamiento de los datos y la lógica de negocio.

A su vez sobre esta idea, se ha tendido al encapsulamiento del código de manera que lasfunciones y en general el código asociado a cada una de las pestañas de la interfaz de usuario (y portanto funcionalidades) desarrolladas son independientes. Por otra parte, se cuenta con un conjuntode complementos y funcionalidades globales a todo el proyecto de funciones genéricas que sonfácilmente modificables en caso de necesidad. De esta manera se consigue un proyecto fácilmenteescalable y flexible, mejorando además su mantenimiento.

La idea principal a la hora de diseñar la solución ha sido pre-analizar todo lo posible de maneraque se disminuya la carga computacional en tiempo de ejecución, y la utilización de libreríasapropiadas para la carga y modificación de grandes cantidades de datos debido al volumen de datos

Estudio de las alertas del servicio 112 / V. Plaza 61

con los que trabajamos, como se puede ver en la tabla 1.

Estado inicial de los datosNúmero de registros total 7,003,168Número de variables original 21Número de datos original 147,066,528Número de variables creadas traslimpieza y procesamiento 7

Número de datos final traslimpieza y procesamiento (fi-las*columnas)

196,088,704

Cuadro 1: Volumen y morfología de los datos a analizar.

El resultado de este análisis se almacena en dos estructuras de datos principales, “dataframe”en caso de que sea un volumen moderado cuyo tiempo de carga sea aceptable, y “ffdf” en caso degrandes volúmenes de datos. Para ello hacemos uso de la librería “ffbase”, especialmente diseñadapara el trabajo con grandes cantidades de datos que generan un tipo especial de “dataframe”denominado “ffdf” cuya particularidad es la utilización de métodos de acceso rápidos a los datosmediante el uso de índices y paginación en memoria. De esta manera los tiempos de carga sereducen drásticamente como podemos observar, al coste de un aumento de la memoria RAMempleada, como podemos observar en la Tabla 2.

Tiempo de carga (segundos)data.frame ffbase

66,81 0,0668,02 0,1662,51 0,1757,35 0,2558,95 0,0960,01 0,1164,33 0,19

Cuadro 2: Comparativa en segundos de tiempos de carga sobre el mismo conjunto de datos.

A su vez y con el fin de enriquecer el análisis de los datos originales aportados por el 112 se hahecho uso de datos de terceros, como pueden ser datos del Instituto Canario de Estadística (ISTAC)sobre paro y empleo, o datos de eventos con el fin de cruzarlos y determinar de qué manera afectana la evolución de las incidencias.

ResultadosEl conjunto de resultados obtenidos se podría clasificar en función de pestaña desarrollada en

la interfaz de usuario, aportando mayor profundidad al análisis cada una de ellas. Para ello se hahecho uso en mayor parte de la librería HighCharter, la cual es un “wrapper” de una librería deJavaScript muy utilizada para la representación gráfica de datos como es HighCharts.

En primer lugar, se realiza un análisis geoespacial de frecuencias porcentuales de incidentespor municipios mostrándose mediante un mapa de calor. Para ello hacemos uso de un “GeoJSON”con la información de los municipios de canarias sobre los que pintamos la información requerida,permitiendo al usuario personalizar la búsqueda mediante el uso de “dashboards” y “sliders”

62 CESINF-2016, Universidad de La Laguna

dinámicos como podemos observar en la figura 1.

Figura 1: UI que analiza la frecuencia porcentual de incidentes por municipios en Canarias.

A continuación, se realiza un análisis de frecuencias tanto de incidentes, como de recursos yvaloraciones en mayor profundidad haciendo uso de representaciones mediante gráficas lineales.De manera análoga se permite al usuario personalizar la búsqueda mediante un “dashboard” con elfin de hacer la aplicación web lo más interactiva y útil posible, como se muestra en la figura 2.

Figura 2: UI que analiza la frecuencia de diversos parámetros mediante gráficas lineales.

De manera similar se lleva a cabo un análisis mediante una representación basada en gráficas debarras en la siguiente pestaña, de manera que las combinaciones de ambas representaciones ayudena una mayor comprensión de la problemática.

Con el fin de enriquecer los datos y buscar patrones o relaciones entre determinadas variables secruzaron éstos con datos tanto del ISTAC como de diversos eventos como pueden ser el mundial de

Estudio de las alertas del servicio 112 / V. Plaza 63

fútbol del año 2010 o las fases lunares. En este sentido se desarrollaron dos interfaces que permitenponer en relación ambas realidades para ver de manera gráfica la evolución de ambos factores,como podemos observar tanto en la figura 3 como 4.

Figura 3: UI que analiza la relación entre tasa de paro y evolución de los incidentes.

Figura 4: UI que analiza la evolución de las incidencias en función de determinados eventos.

Si bien la información obtenida es relevante y puede ayudar a discernir tendencias, requiere deun análisis caso a caso muy tedioso y de poca precisión. Con el fin de resolver esta problemática sellevó a cabo un análisis de correlaciones, haciendo uso de diversos métodos de normalización. Asu vez se implantó un sistema de sugerencias, que selecciona para el usuario aquellas casuísticasmás prometedoras en valor absoluto para ser analizadas, a la vez que permite llevar a cabo análisispersonalizados como podemos observar en la figura 7. La principal diferente respecto al gráficomostrado en la figura 5 radica en la generación de un sistema de sugerencias que permita analizarcon un simple “click” aquellas relaciones más significativas a la vez que éstas se hacen en basea unos datos normalizados de manera que se pueden identificar con mayor precisión las posibles

64 CESINF-2016, Universidad de La Laguna

relaciones entre la evolución de las incidencias y la tasa de paro.

Figura 5: UI que analiza la correlación entre la tasa de paro y las incidencias de manera normalizada,aportando sugerencias por isla.

ConclusionesLas principales conclusiones que hemos obtenido son por una parte la idoneidad de la utilización

del software estadístico R para el análisis de los datos, tanto por el volumen del mismo como porla cantidad y calidad de las librerías que cuenta, así como la importancia de cruzar los datos conterceros con el fin de enriquecerlos y obtener resultados relevantes.

Las conclusiones parciales obtenidas a partir de los datos muestran relaciones evidentes entredeterminadas situaciones en función de la isla, y plantea la necesidad de llevar a cabo un análisis deregresión logística multinomial para generar aquellas posibles predicciones que ayuden al 112 aatender de manera óptima el conjunto de incidencias que gestionan a diario y la distribución de losrecursos con que cuentan, el cual se encuentra en desarrollo.

Referencias[1] Ayuda a la toma de decisiones para mejorar el rendimiento del servicio de emergencias

italiano. URL: http://link.springer.com/article/10.1007/s10479-013-1487-0.

[2] Factores claves a la hora de movilizar una ambulancia. URL: https://www.ncbi.nlm.nih.gov/pmc/articles/PMC1285673/.

[3] Análisis comparativo entre las llamadas al servicio general y de emergencias. URL: https://www.ncbi.nlm.nih.gov/pmc/articles/PMC1295520/.

[4] Introducción a la limpieza de datos con R. URL: https://cran.r-project.org/doc/contrib/de_Jonge+van_der_Loo-Introduction_to_data_cleaning_with_R.pdf.

[5] Librería Highcharts, en JavaScript. URL: http://api.highcharts.com/highcharts/.

[6] Librería Highcharter, “wrapper” en R para la librería Highcharts. URL: http://jkunst.com/highcharter/.

[7] Ejemplos de gráficos de análisis de servicios de emergencias. URL: https://www.kaggle.com/umeshnarayanappa/d/mchirico/montcoalert/explore-911-data/notebook.

Estudio de las alertas del servicio 112 / V. Plaza 65

[8] Mejores paquetes de R para la importación, tratamiento y visualización de datos. URL: http://www.computerworld.com/article/2921176/business-intelligence/great-r-packages-for-data-import-wrangling-visualization.html.

[9] Lista de paquetes y herramientas para R en base al tipo de manipulación: URL: https://github.com/qinwf/awesome-R/blob/master/README.md.