aplicaciÓn web para la extracciÓn de reglas...

Escu

ela

Polit

écn

ica S

up

eri

or

de J

aé

n

UNIVERSIDAD DE JAÉN Nombre del Centro

Trabajo Fin de Grado

APLICACIÓN WEB PARA LA

EXTRACCIÓN DE REGLAS

DESCRIPTIVAS EN MINERÍA DE

DATOS ORIENTADA AL

ANÁLISIS DE DATOS MÉDICOS

Alumno: David Abad Vich Tutor: María José del Jesús Díaz Pedro González García Dpto: Informática

Febrero, 2016

Agradecimientos

Me gustaría dar las gracias a mi familia por todo el apoyo que me ha dado y por la

educación que he podido recibir gracias a ella. Lugar especial en estos agradecimientos

ocupa mi madre, María, que es la que más me ha soportado y siempre me ha recibido con

una sonrisa y palabras de ánimo.

También quiero agradecerle a mi pareja, Beatrice, el haber estado apoyándome

diariamente, motivándome cuando más lo necesitaba para seguir adelante con este

proyecto. Gracias por toda la ayuda que me has dado, por la compresión en mis peores

momentos y por enseñarme a no rendirme cuando las cosas no iban según lo esperado.

A mi compañero Jesús por el apoyo y ánimo que me ha dado, y lo fácil que me ha

hecho ver las cosas. Álvaro, Javier, Alba, Lucas y José, por todo su apoyo y los mundos que

me han hecho descubrir. Especial mención a Alejandro. Sin olvidar a todos mis compañeros

y amigos de la universidad.

Agradecer a todos y cada uno de los profesores y personas involucradas en mi

formación durante mi estancia en la Universidad de Jaén. En especial mención, dar las

gracias a mis tutores, María José del Jesús Díaz y Pedro González García, por su apoyo y

dedicación en los últimos meses, gracias por su tiempo y consejos que me han permitido

llevar a cabo este proyecto satisfactoriamente.

A todos ellos, gracias.

David Abad Vich Aplicación web para la extracción de reglas descriptivas en Minería de Datos orientada al análisis de datos médicos

2 Escuela Politécnica Superior de Jaén

Índice 1. Introducción .................................................................................................................... 6

1.1. Descripción del problema ........................................................................................ 6

1.2. Objetivos ................................................................................................................. 7

1.3. Alternativas tecnológicas ......................................................................................... 7

1.4. Solución propuesta ................................................................................................. 9

2. Ciencia de datos ...........................................................................................................10

2.1. Minería de datos ....................................................................................................11

2.2. Reglas de asociación y descubrimiento de subgrupos ...........................................15

2.2.1. Elementos en un algoritmo de descubrimiento de subgrupos ..........................17

2.2.2. Medidas de calidad en descubrimiento de subgrupos .....................................18

2.3. Algoritmos incluidos en la aplicación ......................................................................23

2.3.1. SD ...................................................................................................................23

2.3.2. CN2-SD...........................................................................................................24

2.3.3. APRIORI -SD ..................................................................................................25

2.3.4. SD-Map ...........................................................................................................26

2.3.5. SDIGA .............................................................................................................27

2.3.6. MESDIF ..........................................................................................................28

2.4. Herramientas software para la extracción de reglas ...............................................29

3. Tecnologías empleadas ................................................................................................33

3.1. Ruby y JRuby on Rails ...........................................................................................33

3.2. Apache y Phusion Passenger ................................................................................35

3.3. Git con GitHub ........................................................................................................35

3.4. Resque...................................................................................................................36

4. Desarrollo de la aplicación ............................................................................................36

4.1. Análisis...................................................................................................................36

4.1.1. Especificación de requisitos ............................................................................36

4.1.2. Planificación ....................................................................................................38

4.1.3. Casos de uso ..................................................................................................41

4.2. Diseño ....................................................................................................................46

4.2.1. Diagramas de secuencia .................................................................................46

4.2.2. Diagrama de clases ........................................................................................52

4.2.3. Diseño de la interfaz .......................................................................................57

4.3. Implementación y prueba .......................................................................................60

5. Experimentación ...........................................................................................................67

5.1. Algoritmos utilizados ..............................................................................................67



5.2. Conjunto de datos heart: enfermedad del corazón .................................................70

5.2.1. Resultados obtenidos ......................................................................................71

5.2.2. Reglas obtenidas por SDIGA ..........................................................................72

5.3. Conjunto de datos dermatology: enfermedades de la piel ......................................73


5.3.2. Reglas obtenidas por CN2-SD ........................................................................77

5.4. Conjunto de datos thyroid: detección de anomalías en la glándula tiroides ............78


5.4.2. Reglas obtenidas por CN2-SD ........................................................................81

6. Conclusiones .................................................................................................................82

7. Anexos ..........................................................................................................................84

7.1. Manual de instalación .............................................................................................84

7.2. Manual de usuario ..................................................................................................87

7.2.1. Usuarios ..........................................................................................................87

7.2.2. Experimentos ..................................................................................................92

Bibliografía ...........................................................................................................................97



Índice de tablas Tabla 2.1 Clasificación de las técnicas de discretización ......................................................14

Tabla 2.2 Tipos de resultados ..............................................................................................19

Tabla 4.1 Estimación de costes de tareas ............................................................................40

Tabla 4.2 Estimación de costes de recursos ........................................................................40

Tabla 4.3 Caso de uso registrarse ........................................................................................42

Tabla 4.4 Caso de uso realizar experimentos .......................................................................43

Tabla 4.5 Caso de uso elegir algoritmo ................................................................................43

Tabla 4.6 Caso de uso elegir discretizador ...........................................................................44

Tabla 4.7 Caso de uso visualizar experimentos ...................................................................44

Tabla 4.8 Caso de uso ejecutar experimentos ......................................................................45

Tabla 4.9 Acciones de los controladores ..............................................................................56

Tabla 5.1 Parámetros por defecto de los algoritmos .............................................................69

Tabla 5.2 Atributos del conjunto de datos de enfermedad del corazón .................................70

Tabla 5.3 Resultados para el conjunto de datos de enfermedad del corazón .......................71

Tabla 5.4 Reglas obtenidas por SDIGA para heart ...............................................................73

Tabla 5.5 Atributos clínicos de dermatología ........................................................................74

Tabla 5.6 Atributos histopatológicos de dermatología ..........................................................75

Tabla 5.7 Resultados para el conjunto de datos de dermatología ........................................76

Tabla 5.8 Resultados de CN2-SD para dermatology ............................................................78

Tabla 5.9 Atributos de tiroides ..............................................................................................79

Tabla 5.10 Resultados para el conjunto de datos de tiroides ................................................80

Tabla 5.11 Resultados de CN2-SD para thyroid ...................................................................82



Índice de ilustraciones Ilustración 2.1 Interfaz VIKAMINE ........................................................................................29

Ilustración 2.2 Interfaz Orange .............................................................................................30

Ilustración 2.3 Interfaz KNIME con Cortana ..........................................................................31

Ilustración 2.4 Interfaz Weka ................................................................................................32

Ilustración 2.5 Interfaz Keel ..................................................................................................33

Ilustración 4.1 Estimación de tiempos ..................................................................................38

Ilustración 4.2 Diagrama de Gantt ........................................................................................39

Ilustración 4.3 Diagrama de casos de uso ............................................................................41

Ilustración 4.4 Diagrama de secuencia de registro ...............................................................46

Ilustración 4.5 Diagrama de secuencia de realizar experimento ...........................................47

Ilustración 4.6 Diagrama de secuencia de elegir algoritmo ...................................................48

Ilustración 4.7 Diagrama de secuencia de elegir discretizador .............................................49

Ilustración 4.8 Diagrama de secuencia de visualizar experimento ........................................50

Ilustración 4.9 Diagrama de secuencia de ejecutar experimento ..........................................51

Ilustración 4.10 Componentes modelo MVC de Rails ...........................................................52

Ilustración 4.11 Diagrama de clases de los modelos ............................................................53

Ilustración 4.12 Diagrama de clases de los controladores ....................................................55

Ilustración 4.13 Storyboard: Iniciar sesión ............................................................................57

Ilustración 4.14 Storyboard: sesión iniciada ..........................................................................58

Ilustración 4.15 Storyboard: visualizar experimento ..............................................................59

Ilustración 4.16 Storyboard: Listado de experimentos ..........................................................60

Ilustración 7.1 Página de inicio de la aplicación ....................................................................87

Ilustración 7.2 Página de identificación de usuarios .............................................................88

Ilustración 7.3 Página de registro de nuevo usuario .............................................................89

Ilustración 7.4 Correo electrónico de activación de cuenta ...................................................90

Ilustración 7.5 Página de reinicio de contraseña...................................................................91

Ilustración 7.6 Correo electrónico de reinicio de contraseña .................................................91

Ilustración 7.7 Página de creación de experimento ..............................................................93

Ilustración 7.8 Página de confirmación de experimento ........................................................93

Ilustración 7.9 Página con el listado de experimentos realizados .........................................94

Ilustración 7.10 Página de visualización de los datos de un experimento .............................94

Ilustración 7.11 Correo electrónico de finalización de experimento ......................................95

Ilustración 7.12 Página de visualización de experimento finalizado ......................................96



1. Introducción

Se procederá a introducir el problema que cubre este TFG, junto con los

objetivos establecidos para el mismo, las diferentes herramientas con las que

desarrollar la aplicación de este TFG y finalmente la elección de una de las

herramientas previamente mencionadas, con la justificación de elección de la

misma.

1.1. Descripción del problema

Con las grandes cantidades de datos que existen y que día a día siguen

incrementando, surgen varios problemas sobre qué hacer con esa información y

cómo tratarla. La Ciencia de datos busca extraer conocimiento útil de esos datos

mediante el uso de diferentes técnicas y métodos.

Uno de esos métodos consiste en la extracción de reglas descriptivas que

describan el comportamiento de los datos. Existen diversas soluciones y una gran

cantidad de algoritmos que pueden aplicarse de diversas formas a esas grandes

bases de datos.

Debido a esa ingente cantidad de datos, la aplicación de un algoritmo no es

una tarea trivial, requiere potencia y aun así también requiere de una cierta cantidad

de tiempo. Tiempo en el que tendremos un sistema ocupado prácticamente en la

ejecución, sin mucha posibilidad a otro uso paralelo ya que aumentaría la cantidad

de tiempo requerido.

Dentro de la medicina existen varias utilidades de la Ciencia de datos, como la

detección de grupos de riesgo con una enfermedad coronaria del corazón,

conocimiento para el diagnóstico y prevención de isquemia cerebral o factores de

influencia en el cáncer cervical, entre otros ejemplos de uso.

Existen diferentes herramientas para extraer el conocimiento de los datos,

todas ellas con sus características específicas. Sin embargo todas estas

herramientas comparten en común una característica: su uso requiere de una

formación especial, pues si no se es experto en el área difícilmente se puede hacer

un correcto uso de las herramientas. Esto se aplica en concreto al colectivo médico,



experto en su área pero no en el área de aplicación de técnicas de extracción de

conocimiento.

1.2. Objetivos

Los objetivos principales para este TFG son:

Profundizar en el conocimiento de métodos de analítica de datos predictiva y

descriptiva, que será realizado en los siguientes apartados, junto con un estudio de

los métodos de Minería de Datos más adecuados para la extracción de reglas

descriptivas en el campo médico.

Se incluirá el desarrollo de una herramienta que integrará dichos métodos, que

sea útil para médicos, responsables de dirección de empresas, y en general

cualquier persona interesada en Ciencia de Datos.

Con la herramienta desarrollada se plantea una alternativa diferente, un

sistema en el cual se efectuarán las ejecuciones del algoritmo por lo que los

usuarios no tendrán que preocuparse de ese aspecto. Además, al estar enfocada a

los datos médicos tendrá como usuarios personas que no van a tener un

conocimiento completo sobre Minería de Datos, por lo que la herramienta tendrá que

contar con una interfaz sencilla e intuitiva, facilitando todo lo posible la tarea al

personal médico.

1.3. Alternativas tecnológicas

Dentro del marco de desarrollo de aplicaciones para extracción de

conocimiento en bases de datos se encuentran:

R: Es una suite integrada de software para la manipulación de datos,

cálculo y visualización gráfica (Venables & Smith, 2009). Incorpora un

servicio de almacenamiento y manejo de datos, una suite de operadores

para cálculos en arrays, concretamente en matrices, una colección de

herramientas intermedias para análisis de datos, servicios gráficos para

el análisis de datos y visualización de resultados e incorpora su propio

lenguaje, llamado “S”, que incluye condiciones, ciclos, funciones

recursivas definidas por el usuario y servicios de input y output.



Python: Es un lenguaje de programación de propósito general creado

por Guido Van Rossum. Tiene estructuras de datos de alto nivel

eficientes y hace uso del paradigma orientado a objetos. Es un lenguaje

interpretado que posee varias librerías especializadas en el manejo de

datos para minería de datos.

Java: Es un lenguaje de programación concurrente, orientado a objetos

y diseñado para tener el menor número posible de dependencias en su

implementación. Pensado para ser ejecutado en cualquier máquina

virtual de Java, independientemente de la arquitectura del sistema.

Posee una API específica para la minería de datos llamada JDM (Java

Data Mining), además de bibliotecas escritas en Java con algoritmos

para minería de datos.

Ruby: Es un lenguaje de programación dinámico, orientado a objetos,

enfocado a la simplicidad y productividad. Su uso en minería de datos

viene dado principalmente por su variante JRuby, que permite el uso de

código Java junto con el mismo código Ruby, combinando la simplicidad

de Ruby con las bibliotecas disponibles de Java.

Dentro de estos lenguajes existen diferentes posibilidades de implementación.

Voy a enfocar las posibilidades a las necesidades que tiene la herramienta a

desarrollar.

R cuenta con un proyecto de integración a Apache, de manera que permite el

desarrollo de una aplicación web utilizando los dos. Este proyecto se llama rApache

(Vanderbilt University, 2013) y está disponible para sistemas operativos bajo

distribuciones UNIX/Linux y Mac OS X. R también cuenta con un paquete que

permite la creación de aplicaciones web directamente desde el software R. La

solución, llamada Shiny (RStudio, 2014), trabaja prácticamente con el lenguaje S,

dando lugar a una menor posibilidad de personalización de la herramienta.

Para Python existen diferentes frameworks para el desarrollo de aplicaciones

web. Puesto que las librerías se incorporan a Python, no es necesario un framework

específico.



Con Java ocurre de manera similar a Python y es que hay una gran cantidad de

frameworks, sin embargo ninguno especializado en Minería de Datos pues lo

importante son las bibliotecas que posee.

Finalmente Ruby, y en concreto su variante Java JRuby, cuenta con algunos

frameworks para el desarrollo. El más extendido de ellos es Rails por su alta

capacidad.

1.4. Solución propuesta

El tipo de herramienta que se necesita tiene que cubrir una serie de

necesidades para el personal médico que vaya a hacer uso de ella:

Necesitan una herramienta con una interfaz sencilla e intuitiva, que permita al

personal no especializado el poder ejecutar diferentes algoritmos de minería

de datos sobre un conjunto de datos.

Esta herramienta además deberá de realizar la ejecución de los algoritmos en

segundo plano, para permitir a los usuarios seguir navegando por la misma

aunque haya una ejecución activa en el momento.

Esta ejecución no debe entorpecer al usuario, en otras palabras, la ejecución

tiene que realizarse en una máquina diferente a la que está utilizando el

usuario, la ejecución tendrá que realizarse en un servidor.

La herramienta que cubre estas necesidades es una aplicación web.

Dentro de las posibilidades explicadas anteriormente, R puede suponer un

problema debido a la complejidad que genera, dificultando la tarea para el personal

médico sin experiencia.

Entre los frameworks de desarrollo web restantes, Rails destaca por la

simplicidad en su desarrollo y por su facilidad de prototipado para diseñar una

interfaz sencilla que pueda ser intuitiva para el personal médico.

El siguiente aspecto a tener en cuenta son las ejecuciones en segundo plano.

Java cuenta con la concurrencia para llevar a cabo esta tarea, sin embargo se



requiere que el usuario tenga un control completo de la aplicación aún mientras ésta

esté ejecutando un algoritmo.

Ambos Python y Ruby cuentan con bibliotecas para la ejecución de trabajos en

segundo plano, con la posibilidad de realizar colas, para dar prioridad al orden de

llegada, y la posibilidad de establecer la cantidad de trabajos que se van a poder

ejecutar a la vez.

Para poder aprovechar la cantidad de algoritmos en Java y la posibilidad de

desarrollar una interfaz sencilla para ello, he elegido realizar la aplicación web con

JRuby on Rails.

2. Ciencia de datos

La Ciencia de Datos es un campo interdisciplinar sobre los distintos procesos y

sistemas para la extracción de conocimiento de los datos en varias formas. A

menudo se asocia al término Big Data, pero hay que tener cuidado pues no tienen

parecido. Podría decirse que forman parte de un gran proceso para la obtención de

conocimiento: Big Data buscaría la acumulación de grandes cantidades de datos,

organizándolos y preparándolos, mientras que la Ciencia de Datos aportaría los

modelos para extraer información útil de esos datos.

Dentro de la Ciencia de Datos se encuentran muchas disciplinas ya que

engloba áreas como matemáticas, estadística o análisis predictivo. De manera

similar se define el descubrimiento de conocimiento en las bases de datos (KDD,

Knwoledge Discovery from Databases), que forma parte de la Ciencia de Datos

englobando una serie de pasos, para la extracción del conocimiento, definidos por

(Fayyad, Piatetsky-Shapiro, & Smyth, 1996):

1- Entender el dominio de la aplicación y el conocimiento previo necesario e

identificar el objetivo del proceso de extracción de conocimiento.

2- Crear un conjunto de datos objetivo: seleccionando el conjunto, o

centrándose en un subconjunto de variables o de muestra de los datos.



3- Limpieza y pre-procesamiento. Con operaciones básicas como remover el

ruido, obteniendo la información necesaria para modelar el ruido o tenerlo

en cuenta, o decidir estrategias para los datos perdidos.

4- Reducción de los datos. Encontrando características útiles que representen

a los datos en el objetivo de la tarea. Con reducción de dimensionalidad o

métodos de transformación.

5- Ajustar los objetivos a métodos particulares de Minería de Datos.

6- Análisis exploratorio y selección de modelo e hipótesis. Esto es, eligiendo

los algoritmos de minería de datos y los métodos utilizados para encontrar

patrones en los datos.

7- Minería de Datos: búsqueda de patrones de interés representados de una

forma específica o un conjunto de dichas representaciones.

8- Interpretación de los patrones obtenidos, posiblemente volviendo a

cualquiera de los pasos del 1 al 7 para mayor iteración.

9- Actuar con el conocimiento descubierto, ya sea: usando directamente el

conocimiento, incorporándolo a otro sistema o sencillamente

documentándolo para otros.

Como he mencionado, la Minería de datos es una parte de este proceso y en la

que se centra más el desarrollo del TFG.

2.1. Minería de datos

El término Minería de Datos hace referencia a una parte del proceso de

descubrimiento de conocimiento en las bases de datos que consiste en la extracción

de información de grandes cantidades de datos aplicando algoritmos específicos.

Esta información se busca que no sea trivial, que sea desconocida y potencialmente

útil (Hernández, Ramírez, & Ferri, 2004).

Aunque hoy en día se ha generalizado el uso del término y se pueden

encontrar ejemplos en los que se refieren al proceso de descubrimiento como

Minería de Datos, quizás por ser un término de mayor atractivo por las

connotaciones que conlleva el uso de la palabra minería.



Esto ya hace entender la importancia de los datos, pues además de la fase de

procesamiento previa, existen otros factores referentes a los datos que van a afectar

al resultado final.

La minería de datos es un proceso muy costoso, computacionalmente

hablando, ya que las cantidades de datos que se generan hoy en día, sobre los que

se quiere extraer información, son muy grandes. Desde los datos de ventas de un

pequeño supermercado hasta las publicaciones realizadas en una red social

poblada, todo ello contiene información oculta que puede ser muy interesante para

los encargados de gestionar esos sitios y que puede marcar la diferencia, por ello el

uso de minería de datos está cada vez más extendido.

Dentro de las técnicas de minería de datos encontramos dos principales

perspectivas de aplicación:

Predicción inductiva: tiene por objetivo el descubrimiento de

conocimiento para clasificación o predicción. Entre sus características se

encuentran clasificación, regresión o series temporales.

Descripción inductiva: con el objetivo de extraer conocimiento

interesante de los datos. Incluye reglas de asociación, resumen

(summarisation) o descubrimiento de subgrupos.

Los datos a los que se puede aplicar Minería de Datos son, en principio,

cualquier tipo: relacionales, espaciales, temporales, documentales, multimedia o

incluso en la web, son ejemplos de tipos de bases de datos.

Sin embargo para extraer información de estos datos, primero hay que pasar

por un proceso previo de transformación de los mismos. Está definido un proceso

completo, llamado exploración de los datos, que consiste en el tratamiento de los

datos desde diferentes aspectos. (Pyle, 1999)

Los principales problemas con los que nos podemos encontrar y para los que

necesitamos procesar los datos son:

Valores perdidos: Son valores desconocidos de un atributo que tienen

que completarse, usando el método que creamos conveniente acorde al



resto de los datos, para poder utilizarse o ignorarse, siempre y cuando

sea posible ya que el peso de un atributo varía de un conjunto de datos

a otro.

Valores erróneos: También llamados del inglés outliers, son aquellos

cuyas características son diferentes respecto a los otros datos. Aunque

puedan ser correctos también (como valores atípicos), pueden

entorpecer el proceso de minería de datos de ciertos métodos, por lo

que suelen dejarse fuera del rango de los datos.

Ruido: Se produce debido a un error en la medición. En este caso se

usan diferentes métodos para suavizar los mismos.

Cuando la cantidad de datos es demasiado grande, se suele recurrir a

diferentes técnicas de reducción de dimensionalidad. Estas técnicas van desde la

selección de características, que consiste en seleccionar un subconjunto de

variables del problema que optimice la probabilidad de clasificar correctamente hasta

el muestreo (sampling), mediante el cual se extraen diferentes muestras

significativas de los datos, que son subconjuntos del total, sobre las que aplicar las

técnicas de minería de datos.

Entre el conjunto de datos, puede incluirse un atributo extra etiquetado como

“atributo de clase” que contiene el resultado final ya deducido respecto al resto de

atributos. Éste se incluye en los conjuntos de datos de entrenamiento, que son

aquellos conjuntos usados para “entrenar” algoritmos predictores.

Otro problema que nos podemos encontrar son las variables continuas, que

pueden suponer una dificultad añadida dadas las infinitas posibilidades que tienen.

Por ello se utilizan técnicas de discretización que pasan las variables continuas a

discretas, situadas en un dominio finito y por lo tanto reduciendo también los datos.

La discretización es una parte del proceso de procesamiento de los datos que

consiste en la conversión de variables continuas, con un rango de valores infinito, a

variables discretas, con un rango finito. Esto se hace mediante la clasificación en

rangos, dividiendo los infinitos valores que puede tomar la variable en rangos de

valores.



Esta operación es necesaria para reducir el tamaño de los datos, pero al igual

que cualquier otro paso en el procesamiento, es importante siempre aplicar la

técnica en base al conjunto de datos que se está manejando.

Dougherty, Kohavi y Sahami definen tres ejes donde se clasifican las técnicas

de discretización (Dougherty, Kohavi, & Sahami, 1995): global vs., local, supervisado

vs., no supervisado y estático vs., dinámico, dando lugar a una tabla de clasificación

como la siguiente:

Clasificación métodos globales Clasificación métodos locales

Supervisado global estático

Supervisado global dinámico

Supervisado local estático

Supervisado local dinámico

No supervisado global estático

No supervisado global dinámico

No supervisado local estático

No supervisado local dinámico

Tabla 2.1 Clasificación de las técnicas de discretización

Los métodos locales producen particiones que se aplican en regiones

localizadas del espacio de instancia. Los globales producen una malla (mesh) sobre

el espacio de instancia continuo n-dimensional completo, donde cada característica

es particionada en regiones independientes de otros atributos.

Entre los métodos de discretización están aquellos que usan las etiquetas de

clase en el proceso de discretización. A éstos se les llama supervisados mientras

que a los que no hacen uso de las etiquetas de clase se les llama no supervisados.

La diferencia entre método estático y dinámico no se usa puesto que sólo

algunos métodos de discretización requieren de un parámetro, k, que indica el

número máximo de intervalos a producir al discretizar. Los estáticos calculan el valor

de k para cada característica independientemente del resto. Los métodos dinámicos

por su lado realizan una búsqueda en el espacio de los posibles valores de k para

todas las características, captando todas las interdependencias.

La aplicación que se va a desarrollar incluirá los algoritmos de discretización

más adecuados de acuerdo con el tipo de algoritmos que se van a incorporar en la

misma:



Discretizador de análisis de clúster (Chmielewski & Grzymala-Busse,

1996).

Discretizador de Fayyad (Fayyad & Irani, 1993).

2.2. Reglas de asociación y descubrimiento de subgrupos

Las reglas de asociación han surgido de la necesidad de identificar relaciones

no explícitas como resultado de aplicar minería de datos sobre un conjunto de éstos.

Estas reglas expresan la relación o relaciones que se ha encontrado entre las

variables y se expresan de la forma “si el atributo A tiene el valor x, entonces el

atributo B tiene el valor y”.

El descubrimiento de conocimiento en las bases de datos es un término más

genérico que incluye el proceso completo de descubrimiento de conocimiento útil.

Busca utilizar todos los datos disponibles y relevantes para extraer conocimiento que

pueda ser fácilmente comprendido por expertos. Se define como la búsqueda de

patrones existentes en bases de datos, pero ocultos entre los volúmenes de datos y

que pueden aportar conocimiento valioso si los datos con lo suficientemente

conclusivos y contienen atributos relevantes al problema para muchos de los casos

del dominio.

En cuanto al descubrimiento de subgrupos (SD, Subgroup Discovery),

inicialmente definido por Klösgen (Klösgen, 1996) y Wrobel (Wrobel, 1997), más

formalmente definido por Siebes (Siebes, 1995), puede definirse como el

descubrimiento de subgrupos interesantes, es decir, dada una población de

individuos (objetos, clientes, …) y una propiedad de los mismos en la que estamos

interesados, la tarea consiste en descubrir los subgrupos de la población

estadísticamente más interesantes, con las mejores características respecto a la

propiedad de interés.

La representación del conocimiento obtenido al aplicar descubrimiento de

subgrupos se representa en forma de reglas, que consisten en descripciones de

subgrupos inducidas. Podemos definir una regla R como:



Donde es el valor para la variable de interés y es una unión

de características (pares atributo-valor) que describe una distribución estadística

inusual respecto el .

Por ejemplo, si tenemos D un conjunto de datos con cuatro variables:

Pronóstico = {soleado, nublado, lluvioso}, Temperatura = {Alta, Media, Baja},

Humedad = {Alta, Baja} y Ventoso = {True, False}, y la variable de interés, variable

objetivo Jugar = {Sí, No}. Algunas reglas posibles son:

( )

( )

La técnica de descubrimiento de subgrupos se aplica extrayendo patrones, que

son subgrupos formados por un conjunto de reglas, respecto a una propiedad de

interés de los datos, o variable objetivo. Se puede considerar una combinación, o

que está situada en un punto intermedio, entre predicción y descripción. Los

algoritmos que realizan esta tarea deben generar subgrupos por cada valor de la

variable objetivo y deberá realizarse una ejecución por cada uno de éstos valores.

Aquí se puede volver a ver la importancia del procesamiento de los datos, en

concreto la discretización en el caso de que la variable objetivo tome valores

continuos.

Actualmente hay más técnicas que se encuentran a medio camino entre

minería de datos descriptiva y predictiva. “Inducción supervisada de reglas

descriptivas” (Kralj-Novak, Lavrac, & Webb, 2009) es un paradigma que incluye

técnicas que combinan las características de los dos tipos de inducción y tiene por

principal objetivo la extracción de conocimiento descriptivo de una propiedad de

interés. Las técnicas de minería de datos que incluye el paradigma son:

Descubrimiento de subgrupos (Subgroup Discovery), definido como la

extracción de subgrupos interesantes para un valor objetivo.

Minería de conjuntos de contraste (Contrast Set Mining), definida como una

conjunción de pares atributo-valor definidos en grupos sin atributo con más

de una ocurrencia.



Minería de patrones emergentes (Emerging Pattern Mining), definida como

patrones cuyas frecuencias en dos clases difieren en gran proporción.

La principal diferencia entre las técnicas es: mientras que los algoritmos de

descubrimiento de subgrupos persiguen describir distribuciones inusuales en el

espacio de búsqueda respecto un valor de la variable objetivo, algoritmos de

conjuntos de contraste y patrones emergentes buscan patrones con diferentes

frecuencias en dos clases de la variable objetivo.

2.2.1. Elementos en un algoritmo de descubrimiento de subgrupos

Hay varios elementos comunes que se encuentran en el descubrimiento de

subgrupos, entre esos encontramos:

Tipo de la variable objetivo. Hay diferentes tipos de variable: binaria,

nominal o numérica. Para cada tipo se realiza un análisis diferente

considerando la dimensión.

o Análisis binario: tiene sólo dos valores y la tarea se centra en

proveer subgrupos interesantes para cada valor.

o Análisis nominal: puede tomar un número determinado de valores,

pero la filosofía es similar al análisis binario, encontrar subgrupos

para cada valor.

o Análisis numérico: el tipo más complejo ya que hay diferentes

maneras de tratarla como dividir la variable en dos rangos respecto

a la media, discretizar la variable objetivo o buscar por desviaciones

de la media que sean significativas, entre otras.

Lenguaje de descripción (description language). La representación de los

subgrupos debe ser apropiada para obtener reglas interesantes. Estas

reglas tienes que ser sencillas y por ello se representan como pares

atributo-valor en forma normal conjuntiva o disyuntiva.

Medidas de calidad (quality measures). Son el factor clave para la

extracción de conocimiento pues el interés obtenido depende directamente

de ellas. Es más, las medidas de calidad proporcionan la importancia e

interés de los subgrupos obtenidos al experto que analiza los datos.



Estrategia de búsqueda (search strategy). De alta importancia pues la

dimensión del espacio de búsqueda tiene una relación exponencial con el

número de características y valores considerados. Existen diferentes

estrategias usadas hasta el momento, como por ejemplo: búsqueda en

haz (beam search), algoritmos evolutivos o búsqueda en espacios multi-

relacionales, entre otras.

2.2.2. Medidas de calidad en descubrimiento de subgrupos

La elección de las medidas de calidad es uno de los aspectos más importantes,

en el cual no hay ningún consenso sobre cuáles son las más aptas para los

procesos de extracción y evaluación de reglas.

Aunque hay un gran número, aquí se presentan las que son usadas en

descripción de subgrupos, clasificadas por su principal objetivo según (Herrera,

Carmona, González, & del Jesus, 2010).

Antes de empezar hay que aclarar los tipos de resultados que se pueden

obtener al realizar una tarea de descubrimiento de subgrupos:

verdaderos positivos son los valores que pertenecen a la clase y han

sido clasificados correctamente,

falsos positivos son los valores que no pertenecen pero han sido

clasificados como valores de la clase,

verdaderos negativos son los que han sido clasificados como no

pertenecientes a la clase y no pertenecen, y

falsos negativos son los valores que han sido clasificados como no

pertenecientes a la clase pero sí pertenecen a ésta.

La siguiente tabla 2.2 sirve de apoyo para diferenciar los cuatro tipos de

valores:



Pertenece a la clase No pertenece a la

clase

Clasificado como

perteneciente a la

clase

Verdadero positivo

(tp, true positive)

Falso positivo (fp,

false positive)

Clasificado como

no perteneciente a

la clase

Falso negativo (fn,

false negative)

Verdadero negativo

(tn, true negative)

Tabla 2.2 Tipos de resultados

Clasificación de las medidas según su principal objetivo:

Medidas de complejidad

Estas medidas están relacionadas al entendimiento de los subgrupos, es decir,

a la simplicidad del conocimiento extraído. Entre ellas encontramos:

o Número de reglas (nr): Mide el número de reglas inducidas.

o Número de variables (nv): Mide el número de variables del antecedente.

El número de variables para un conjunto de reglas se calcula como la

media de las variables por regla de ese conjunto.

Medidas de generalidad

Utilizadas para cuantificar la cualidad de reglas individuales según los patrones

de interés cubiertos.

o Cobertura: Mide el porcentaje de ejemplos cubiertos de media por una

regla R. Se puede expresar como:

( ) ( )

(1)

Donde es el total de ejemplos y ( ) es el número de ejemplos que

satisfacen las condiciones de la regla determinadas por el antecedente.



o Soporte: Se define como la frecuencia de los casos correctamente

clasificados:

( ) ( )

( )

Con ( ) (true positives), el número de ejemplos que

satisfacen las condiciones y también pertenecen al valor de la variable objetivo.

La media de soporte para un conjunto se calcula como:

∑ (

)

Donde ( ) son todos los ejemplos correctamente

clasificados de una misma clase. Esto es, la suma de todos los ejemplos

correctamente clasificados de todos los valores que puede tomar la variable objetivo,

dividido por el total de ejemplos del conjunto.

Medidas de precisión

Estas medidas muestran la precisión de los subgrupos y son ampliamente

usadas, entre ellas se encuentran las siguientes.

o Confianza: Mide la frecuencia relativa de ejemplos que satisfacen la

regla completa y los que sólo satisfacen el antecedente. Se puede

expresar de diferentes manera:

( ) ( )

( ) ( )

y también puede encontrarse bajo el nombre de precisión.

o Medida de precisión : Mide el término medio entre verdaderos y falsos

positivos cubiertos en una función lineal:

( ) ( ) ( ) ( ̅̅ ̅̅ ̅̅ ̅̅ ̅̅ ̅̅ ̅̅ ̅̅ )



Donde ( ̅̅ ̅̅ ̅̅ ̅̅ ̅̅ ̅̅ ̅̅ ̅̅ ) (false positives) son los ejemplos que

satisfacen el antecedente pero no satisfacen la condición de la regla, y el parámetro

c se usa como parámetro de generalización.

o Medida de precisión : Mide el término medio de un subgrupo entre el

número de ejemplos clasificados perfectamente y la atipicidad de su

distribución. Se puede calcular como:

( )

( )

( ̅̅ ̅̅ ̅̅ ̅̅ ̅̅ ̅̅ ̅̅ ̅̅ )

( )

Donde g se usa como parámetro de generalización.

Medidas de interés

Estas medidas están previstas para seleccionar y clasificar patrones según su

interés potencial para el usuario.

o Interés: Mide el interés de una regla determinado por el antecedente y el

consecuente:

( ) ∑ ( )

(| ( )|) ( )

Donde es la ganancia de información, | ( )| es la cardinalidad de la

variable objetivo, y Ai es el número de valores o intervalos de la variable.

o Novedad (novelty): Esta medida puede detectar subgrupos inusuales y

se puede expresar como:

( ) ( ) ( ( ) ( )) ( )

Donde ( ) son todos los ejemplos de la variable objetivo.

o Significancia: Esta medida indica la significancia de un resultado y se

calcula como el índice de probabilidad de una regla:

( ) ∑ ( )

( )

( ) ( )

( )



Donde ( ), calculado como ( ) , se usa como factor normalizado,

y es el número de valores de la variable objetivo. Hay que aclarar que aunque

cada regla sea para un específico, la significancia mide la novedad en

la distribución imparcialmente, para todos los valores.

Medidas híbridas

Este grupo contiene una gran cantidad de medidas de calidad debido a que el

descubrimiento de subgrupos intenta obtener un término medio entre generalidad,

interés y precisión en los resultados obtenidos.

o Sensibilidad: Esta medida es la proporción de positivos clasificados

correctamente:

( )

( )

( ) ( )

Donde son todos los ejemplos que pertenecen a la variable objetivo

( ). Esta medida combina precisión y generalidad relacionadas a la

variable objetivo.

o Falsa alarma: También conocida como índice de falsos positivos, se

puede expresar como:

( )

( ̅̅ ̅̅ ̅̅ ̅̅ ̅̅ ̅̅ ̅̅ ̅̅ )

( ̅̅ ̅̅ ̅̅ ̅̅ ̅̅ ̅̅ ̅̅ ̅̅ )

( )

Donde es el número de ejemplos que no pertenecen a la variable objetivo

, es decir ( ̅̅ ̅̅ ̅̅ ̅̅ ̅̅ ̅̅ ̅̅ ̅̅ ).

o Especificidad: Mide la proporción de casos negativos incorrectamente

clasificados, se puede expresar como:

( )

( ̅̅ ̅̅ ̅̅ ̅̅ ̅̅ ̅̅ ̅̅ ̅̅ ̅̅ ̅̅ ̅̅ ̅̅ ̅)

( ̅̅ ̅̅ ̅̅ ̅̅ ̅̅ ̅̅ ̅̅ ̅̅ )

( )

Donde son los verdaderos negativos (true negative), que no pertenecen a la

clase y no cumplen las condiciones del antecedente.



o Atipicidad: Se define como la precisión ponderada relativa (weighted

relative accuracy) de una regla, se puede expresar como:

( ) ( )

( ( )

( )

( )

) ( )

La atipicidad de una regla se puede describir como el balance entre la

cobertura de la regla ( ) y su ganancia de precisión ( )

( ). Esta medida deriva de la novedad (novelty).

2.3. Algoritmos incluidos en la aplicación

En esta parte comentaré los algoritmos que he utilizado en el desarrollo de la

aplicación, que clasificados por el tipo de algoritmo que amplían son los siguientes

(Herrera, Carmona, González, & del Jesus, 2010):

Extensiones de algoritmos de clasificación

o SD

o CN2-SD

Extensiones de algoritmos de asociación

o APRIORI-SD

o SD-MAP

Algoritmos evolutivos

o SDIGA

o MESDIF

2.3.1. SD

Es un sistema de inducción de reglas basado en una variación de los

algoritmos de búsqueda en haz (optimización de la búsqueda de primero el mejor)

guiados por conocimiento experto (Gamberger & Lavrac, 2002): en lugar de definir

una medida óptima para descubrir y seleccionar automáticamente los subgrupos, el

objetivo es ayudar al experto en realizar búsquedas flexibles y efectivas en un

amplio rango de soluciones óptimas. Los subgrupos descubiertos deben satisfacer el

criterio de soporte mínimo y también deben ser relevantes.

El algoritmo mantiene las mejores descripciones de subgrupos en un haz de

anchura fija y con cada iteración se añade una conjunción a cada descripción de



subgrupo en el haz, reemplazando el peor subgrupo en el haz por el nuevo

subgrupo, si es mejor. Para evaluar la calidad de los subgrupos se usa la medida de

precisión Qg. Otras variantes usan medidas como: sensibilidad, especificidad, falsa

alarma, soporte o confianza. Subgrupos de alta calidad deben cubrir tantos ejemplos

y el mínimo número de ejemplos que no son como sea

posible. El algoritmo SD usa una visualización que provee a los expertos con una

herramienta sencilla para probar los subgrupos. Además se han propuesto métodos

para evitar el ruido y los valores erróneos (outliers) y diferentes filtros para

subgrupos.

2.3.2. CN2-SD

Es una adaptación del algoritmo CN2 de aprendizaje de reglas, aplicando las

siguientes modificaciones para realizar descubrimiento de subgrupos (Lavrac,

Kavsek, Flach, & Todorovski, 2004) : (a) reemplazando la heurística de búsqueda

basada en precisión por una nueva heurística de precisión relativa ponderada que

compensa la generalidad y precisión de la regla, (b) incorporando pesos de ejemplo

en el algoritmo de cobertura, (c) incorporando pesos de ejemplo en la heurística de

búsqueda, y (d) usando clasificación probabilística basada en la distribución de clase

de los ejemplos cubiertos por las reglas individuales. Una extensión de este

algoritmo llamada CN2-MSD se ha desarrollado para la gestión de variables objetivo

multiclase.

El algoritmo CN2 tiene dos procesos principales: uno de bajo nivel, que realiza

un procedimiento de búsqueda con la búsqueda en haz (beam search) para

encontrar una regla, y el otro de alto nivel, que ejecuta repetidamente el

procedimiento de bajo nivel para inducir un conjunto de reglas. El de bajo nivel

realiza la búsqueda en haz usando la precisión de la regla como función heurística.

CN2 puede aplicar un test de significancia a una regla inducida, que reduce el

número de reglas al coste de reducir ligeramente la precisión.

Pueden usarse dos procedimientos de control de alto nivel. El primero induce

una lista ordenada de reglas y el segundo un conjunto de reglas sin orden. Ambos

añaden una regla estándar como la regla final en el conjunto de reglas inducidas.



Cuando se utiliza la lista ordenada, se escoge la regla más precisa. Para

prevenir encontrar la misma regla de nuevo, todos los ejemplos cubiertos por la regla

se eliminan antes de iniciar una nueva iteración, repitiendo el proceso hasta que

todos los ejemplos están cubiertos o no se encuentran más reglas significativas.

Al usar la lista no ordenada se inducen reglas de cada clase por turnos, por lo

que luego se eliminan sólo los ejemplos cubiertos de la clase de la cual se ha

inducido la regla.

2.3.3. APRIORI -SD

Basado en el algoritmo de aprendizaje de reglas APRIORI-C. Las principales

modificaciones realizadas por (Kavšek, Lavrač, & Jovanoski, 2003) afectan al último

paso de post procesamiento de reglas y clasificación de ejemplos no clasificados:

Post procesamiento mediante selección de subconjuntos de reglas. APRIORI-C

induce reglas según una mínima confianza y un mínimo soporte. El ajuste de esos

dos parámetros suele llevar a la inducción de un gran número de reglas, que dificulta

la comprensibilidad y usabilidad de las reglas inducidas. Además hay problemas

como la redundancia de reglas, imposibilidad de clasificar ejemplos y baja precisión

en dominios con una distribución de clase desequilibrada. Para evitarlo, APRIORI-C

tiene tres métodos para seleccionar las mejores reglas:

Usar las N mejores reglas: Primero selecciona la mejor regla, que tiene el

mayor soporte, entonces elimina todos los ejemplos cubiertos, ordena las

reglas restantes según el soporte y repite proceso. Repite hasta que se

seleccionan N reglas o no quedan más reglas que seleccionar o no quedan

más ejemplos que cubrir.

Usar las N mejores reglas por cada clase: Funciona de forma similar al

anterior método, seleccionando las N mejores reglas por cada clase,

siempre que la clase tenga reglas suficientes o seleccionará las que pueda.

De esta forma las clases minoritarias obtienen también reglas.

Usa una estrategia ponderada para seleccionar las mejores reglas: Se

comporta igual que “usar las N mejores reglas”, pero en lugar de eliminar

los ejemplos cubiertos inmediatamente, se reduce el peso que tienen.

Cuando el peso es menor que el umbral definido se elimina el ejemplo.



Implementa entonces una nueva estrategia de ponderación en el post

procesamiento, una diferente función de calidad para las reglas que hace uso de la

atipicidad definida como precisión relativa ponderada (weighted relative accuracy), la

clasificación probabilística de ejemplos no clasificados y el conjunto de reglas de

evaluación del área inferior de la curva ROC.

2.3.4. SD-Map

Es un método de búsqueda exhaustiva, desarrollado en base al algoritmo FP-

Growth (Frequent Pattern Growth), que depende de un umbral mínimo soporte, pues

si se deja a cero realiza una búsqueda exhaustiva cubriendo todo el espacio de

búsqueda (Atzmueller & Puppe, SD-Map - a fast algorithm for exhaustive subgroup

discovery, 2006).

El algoritmo FP-Growth, en pocas palabras, es similar al algoritmo Apriori,

como método para extraer patrones frecuentes, incluyendo una mejora para evitar

múltiples escaneos de la base de datos usando una técnica recursiva divide y

vencerás. Usa también su propia estructura de datos para facilitar el uso de la

técnica recursiva, el árbol de patrones frecuentes (FP-tree), sobre la que realiza una

búsqueda recursiva en profundidad para evaluar la hipótesis de subgrupo.

Para el cálculo de la calidad de subgrupo usa principalmente cuatro

parámetros: los verdaderos positivos tp (true positives, los casos que contienen la

variable objetivo en el subgrupo), los falsos positivos fp (false positives, los casos

que no contienen la variable objetivo en el subgrupo) y los positivos TP y negativos

FP de la variable objetivo respecto el total de la población del problema.

Controla también los valores perdidos, que pueden suceder en las tareas de

descubrimiento de subgrupos. Para ello tiene en cuenta dos observaciones:

La primera es que sólo necesita los cuatro parámetros básicos tp, fp, TP y FP

para determinar el resto de parámetros, puesto que el tamaño del subgrupo

y el tamaño de la población es .



La segunda es el concepto de interés para descubrimiento de subgrupos, esto

es, que la variable objetivo es fija a diferencia de las reglas de asociación, por los

parámetros especificados previamente pueden calcularse de modo directo.

Se añade al árbol FP la cuenta de la cantidad de tp y fp que contiene el nodo

mientras se generan los patrones comunes. Por lo tanto se restringe la creación de

nodos del árbol FP a los casos en los que la variable objetivo tiene un valor definido

y calculando la población como consecuencia.

Para manejar los valores perdidos propone la construcción de un segundo

árbol FP, el árbol FP de valores perdidos (Missing-FP-tree), que se evaluará de

forma especial para obtener la cuenta de los valores perdidos. Para ajusta éstos

valores sólo hay que ajustar el número de TP y FP de la población.

Considerando los tp y fp del árbol de valores perdidos, se puede obtener el

número de y que permiten ajustar la cuenta de la población

total, calculándola de la siguiente manera:

,

Calculando la calidad del subgrupo con los parámetros tp, fp, TP’ y FP’.

SD-Map incluye un paso de post procesamiento para la selección y gestión de

la redundancia potencial de los conjuntos de subgrupos obtenidos. Puesto que al

usuario le interesa un k número de subgrupos, se pueden seleccionar los k mejores

según la función de calidad. También pueden elegirse todos los subgrupos que

superen un mínimo umbral de calidad.

2.3.5. SDIGA

Es un sistema evolutivo de extracción de reglas difusas que emplea un

algoritmo genético para la extracción de las reglas. Sigue el acercamiento del

aprendizaje iterativo de regla (IRL, Iterative Rule-Learning) donde cada cromosoma

representa una regla y la solución del algoritmo genético es el mejor individuo

obtenido, estando formada la solución global por los mejores individuos obtenidos en

las distintas ejecuciones del algoritmo.



El funcionamiento de SDIGA sigue tienes dos partes importantes (del Jesus,

González, Herrera, & Mesonero, 2007):

La primera en el núcleo, que es un algoritmo genético con un paso de post

procesamiento basado en una búsqueda local, mediante ascensión de colinas

(hill climbing). Extrae una regla difusa sencilla e interpretable con un nivel

adecuado de soporte y confianza. El consecuente de la regla se compone del

valor que elige el usuario o el valor objetivo.

La segunda parte, el algoritmo genético híbrido se incluye en un proceso

iterativo para la extracción de un conjunto de reglas difusas para la

descripción de subgrupos, apoyado en las diferentes áreas del espacio de

instancia para no limitar su búsqueda. Se obtiene un conjunto de soluciones

generadas en diferentes ejecuciones del algoritmo genético correspondientes

a un mismo valor objetivo.

Las reglas difusas que usa están en formato DNF, siguiendo siempre la

descripción básica de una regla donde tenemos un antecedente (condición) y un

consecuente (el valor objetivo), y se pueden expresar como:

donde son dos posibles descripciones, de todas las existentes, para la

variable y análogamente con e . Estas reglas ofrecen una estructura más

flexible permitiendo más de un valor, facilitando la extracción de reglas más

generales. Permite también el uso de atributos numéricos sin necesidad de

discretización.

Hay que mencionar también que el algoritmo genético híbrido extrae diferentes

reglas en cada ejecución. Para ello al finalizar una ejecución y obtenerse una regla

difusa, las instancias positivas de la regla (ejemplos cubiertos) se marcan para

prevenir obtener nuevas reglas que cubran los mismos ejemplos.

2.3.6. MESDIF

Es un algoritmo genético multiobjetivo para la extracción de reglas que

describen subgrupos (MESDIF, Multiobjective Evolutionary Subgroup Discovery

Fuzzy rules).



El algoritmo, descrito en (del Jesús, González, & Herrera, 2007), extrae reglas

cuyo antecedente representa una conjunción de variables, con un consecuente fijo.

De este modo cada ejecución del algoritmo obtiene un número variable de reglas

que expresan información respecto a un mismo valor de la variable objetivo. Por esto

el algoritmo se ejecuta tantas veces como valores pueda obtener la variable objetivo.

Al igual que el algoritmo SDIGA, también genera reglas difusas en formato

DNF, por lo que podrán usarse variables continuas sin discretizar.

El algoritmo genético multiobjetivo se basa en la técnica SPEA2, que aplica los

conceptos de elitismo, en la elección de reglas, y la búsqueda de soluciones en la

frontera de Pareto, que son aquellas que no pueden mejorarse más sin empeorar

otras.

Puede usar varias medidas de calidad para evaluar las reglas obtenidas, como

confianza, soporte, significancia o atipicidad.

2.4. Herramientas software para la extracción de reglas

Actualmente se encuentran una gran variedad de herramientas software que

permiten extraer conocimiento en forma de reglas a partir de conjuntos de datos,

muchas de las cuales son de código abierto, a continuación mencionaré algunas de

ellas:

2.4.1. VIKAMINE

Ilustración 2.1 Interfaz VIKAMINE



Aplicación basada en el framework Eclipse orientada a visualización analítica,

descubrimiento de conocimiento, refinamiento del conocimiento y control de calidad.

Presenta varias visualizaciones potentes complementadas con métodos de minería

automáticos y veloces.

Al estar basado en Java puede ejecutarse en sistemas Windows, Mac OS y

Unix y está bajo licencia LGPL.

Respecto al descubrimiento de subgrupos, utiliza algoritmos como BSD,

búsqueda de haz (beam-search) y SD-Map. El usuario puede elegir entre búsqueda

automática, interactiva o una combinación de las dos. Cuenta además con ejemplos

de aplicaciones reales que hacen uso de VIKAMINE. (Atzmueller & Lemmerich,

VIKAMINE - Open-Source Subgroup Discovery, Pattern Mining, and Analytics,

2012).

2.4.2. Orange

Ilustración 2.2 Interfaz Orange



Una herramienta para el análisis y la visualización de datos de código libre, que

puede ser instalada en los principales sistemas operativos, Windows, Mac OS y

Linux.

Incluye una librería de rutinas y objetos C++ que contienen una gran variedad

de algoritmos de aprendizaje automático y minería de datos, unos comunes, otros no

tanto. También es un entorno programable para el testeo y prototipado de nuevos

algoritmos.

El módulo para descubrimiento de subgrupos se distribuye bajo licencia GPL e

implementa tres algoritmos: SD, CN2-SD y Apriori-SD.

2.4.3. KNIME con Cortana

Ilustración 2.3 Interfaz KNIME con Cortana

KNIME es una herramienta para la extracción, transformación y carga de datos,

cuyo potencial reside en la interfaz que ofrece para realizar el procesamiento de

datos. Mediante el uso de nodos se conectan las diversas opciones que aplicar

sobre los datos.

Lo interesante de KNIME es que cuenta con interesantes plugins como

Cortana, plugin centrado en descubrimiento de subgrupos mediante la aplicación de

un algoritmo genérico con un alto nivel de personalización, por lo que puede ser

adaptado a diferentes conjuntos de datos. KNIME se encuentra bajo licencia GPL.



2.4.4. Weka

Ilustración 2.4 Interfaz Weka

Una colección en Java de varios algoritmos de aprendizaje automático y

minería de datos, que incorpora un software para aplicar los mismos a conjuntos de

datos, todo ello bajo licencia GPL.

Aunque no destaca en el descubrimiento de subgrupos, contiene algoritmos

como Apriori o FP-Growth, básicos en este campo pero no por ello menos

importantes (Hall, Frank, Holmes, Pfahringer, Reutemann, & Witten, 2009).

Tiene su propio tipo de fichero representación de conjunto de datos, explicado

en (Hall, Frank, Holmes, Pfahringer, Reutemann, & Witten, 2009).

2.4.5. KEEL



Ilustración 2.5 Interfaz Keel

Mi última mención, y no menos importante, es KEEL (Knowledge Extraction

based on Evolutionary Learning). Una herramienta Java de código abierto, bajo

licencia GPLv3, que contiene una gran cantidad de algoritmos relacionados a las

tareas de descubrimiento de conocimiento en los datos.

Aporta una interfaz sencilla basada en nodos, para diseñar los experimentos

siguiendo el flujo de los datos. Además de proporcionar herramientas de pre y post

procesamiento de datos.

3. Tecnologías empleadas

Para el desarrollo de la aplicación, ha sido necesario el uso de ciertas

tecnologías para superar los problemas surgidos durante el mismo. Las tecnologías

que han sido utilizadas, así como su función principal, vienen comentadas en esta

sección.

3.1. Ruby y JRuby on Rails

Ruby es un lenguaje de programación interpretado, orientado a objetos,

presentado públicamente en 1995 y creado por Yukihiro Matsumoto, centrado

principalmente en la productividad del desarrollo de aplicaciones. Toma

características de varios lenguajes, entre los que están Perl, Lisp y Smalltalk,



convirtiéndolo en un lenguaje diferente a los demás. Soporta también herencia,

mixins y métodos singleton.

Para la gestión de paquetes de Ruby, llamados gemas, se utiliza RubyGems,

que proporciona un lenguaje estándar para la distribución de los programas y

bibliotecas bajo Ruby y es además una herramienta sencilla para gestionar la

instalación de gemas, junto con un servidor para distribuirlas.

JRuby es una implementación en Java del lenguaje Ruby y funciona también

como lenguaje embebido dentro de la máquina virtual de Java. Proporciona más

características como: concurrencia sin el uso de un GLI (Global Interpreter Lock),

paralelismo auténtico y la integración del lenguaje Java, que permite usar las clases

de Java en un programa Ruby y usar JRuby en una aplicación Java. Aunque

precisamente por esto último requiere también JRE (JVM Runtime Environment).

Para la gestión de las versiones de Ruby y JRuby, y para evitar problemas de

uso, he usado RVM (Ruby Version Manager), una herramienta de la línea de

comandos que permite precisamente gestionar, instalar y trabajar fácilmente con

múltiples intérpretes de gemas.

Rails es un framework de desarrollo de aplicaciones web basado en el lenguaje

Ruby, que sigue la arquitectura MVC (Modelo Vista Controlador) intentando

combinar la simplicidad de Ruby con el desarrollo de aplicaciones web con la

intención de que minimizar la cantidad de código a escribir. Sigue el principio

fundamental de DRY (Don’t Repeat Yourself), no te repitas, que consiste en la

reducción de la repetición de información de cualquier tipo.

La arquitectura MVC de Rails lleva a que para un modelo dado, por ejemplo

user, tendrá su controlador correspondiente asignado, en este caso UsersController.

Este controlador va a estar formado por diferentes acciones, que van a tener su

vista, lo que el usuario va a ver. Por ejemplo, el controlador de usuario va a tener

una acción para crear un nuevo usuario, llamada new, a la que le corresponde la

vista de usuarios bajo el mismo nombre new.

Siguiendo esta correspondencia, Rails tiene diferentes carpetas en las que se

organiza la aplicación. Va a tener una carpeta para los modelos, otra para los



controladores y otra para las vistas, que además dentro de las vistas tendrá carpetas

separadas para las vistas de cada controlador.

Para controlar las acciones que están disponibles y darles una ubicación en la

url de la aplicación web, Rails hace uso de una tabla de rutas en la que se especifica

el tipo de ruta: get, post o delete, junto con el nombre que va a tener en la url y la

acción del controlador que se va a realizar al acceder a la url con ese nombre.

Rails permite incorporar fácilmente SSL para proporcionar una conexión segura

ante posibles redes inseguras en las que se puedan ver expuestos datos de los

usuarios.

Hay que añadir que Rails incorpora una gema que obliga a utilizar una técnica

llamada parámetros fuertes (strong parameters) para los modelos. Esta técnica

permite indicar qué parámetros son permitidos y cuáles son requeridos, al crear o

actualizar los datos de un modelo.

3.2. Apache y Phusion Passenger

Apache es un servidor HTTP de código libre (bajo licencia Apache), un

proyecto que forma parte de la Apache Software Foundation.

La elección de Apache, además de su licencia, fue por su compatibilidad con

Phusion Passenger, una aplicación servidor que facilita en gran medida el

despliegue de aplicaciones Ruby on Rails y que recientemente ha añadido

compatibilidad con JRuby.

3.3. Git con GitHub

Git es un software de control de versiones bastante fácil de aprender a usar,

diseñado para gestionar cualquier tipo de proyecto, que junto a GitHub, un host de

código muy extendido actualmente, he podido mantener las diferentes versiones del

repositorio de la aplicación desde cualquier sistema usado y siempre actualizado a la

última versión.

Para no hacer la aplicación pública desde el inicio, he usado durante el

desarrollo un repositorio privado de GitHub, manteniéndolo sólo para mí.



3.4. Resque

Resque es una gema de Ruby, es decir una biblioteca, usada para la gestión

de los trabajos de fondo (background jobs), que son las ejecuciones de código en

segundo plano. Ofrece un gran número de características muy útiles para proyectos

que, como este, basan la mayor parte de la aplicación en el segundo plano.

Funciona creando una lista de trabajos que se realizan en estricto orden de

llegada. Permite establecer la cantidad de trabajos que se van a realizar al mismo

tiempo, mediante la definición de “trabajadores” y ofrece una pequeña aplicación

hecha con Sinatra para la monitorización de colas, trabajos y trabajadores.

Se apoya en Redis para el almacenamiento de las colas, puesto que puede

haber más de una. Redis es una estructura de almacenamiento de datos, de código

libre, que se usa principalmente como base de datos y admite estructuras de datos

como cadenas, tablas hash, listas o conjuntos, además de otras funcionalidades.

4. Desarrollo de la aplicación

A continuación procederé a explicar el desarrollo y posterior implementación de

la aplicación para la extracción de reglas. Se ha tenido en mente en todo momento

la simplicidad necesaria en la aplicación para poder hacerla intuitiva al personal

sanitario con poca o ninguna experiencia en el campo de la extracción de reglas.

4.1. Análisis

4.1.1. Especificación de requisitos

Requisitos funcionales

Los requisitos funcionales describen la funcionalidad que el sistema debe

aportar a los usuarios. Son especificaciones sobre los servicios que el sistema debe

ofrecer, cómo el sistema debe responder a determinadas entradas por parte del

usuario y cómo el sistema debería comportarse en situaciones particulares.

Los requisitos funcionales son:



El usuario puede darse de alta en la aplicación.

Sólo pueden acceder usuarios dados de alta y activos, previa

identificación por medio de usuario y contraseña.

El usuario podrá crear nuevos experimentos.

El usuario podrá elegir un algoritmo, de entre los disponibles, para

aplicarlo a un experimento.

El usuario podrá cambiar los parámetros de un algoritmo para un

experimento.

El usuario podrá elegir un discretizador, de entre los disponibles, para

aplicarlo a un experimento.

El usuario podrá subir un archivo, un conjunto de datos, al crear un

experimento.

El sistema debe realizar la ejecución de los experimentos.

El sistema debe notificar al usuario de la finalización de un experimento.

La aplicación debe mostrar una lista con los experimentos realizados por

un usuario.

El usuario podrá acceder a sus experimentos para comprobar los

resultados.

Requisitos no funcionales

Los requisitos no funcionales son los relacionados con la calidad y el proceso

de desarrollo del sistema. Surgen de diversos motivos como la necesidad del

usuario, debido a las restricciones de presupuesto, herramientas utilizadas, políticas

de la organización y otras.

Los requisitos no funcionales son los siguientes:

La interfaz de la aplicación deberá ser sencilla para ser usada por

personal médico.

La interfaz deberá ser intuitiva para reducir el tiempo de entrenamiento.

La navegación en la aplicación deberá ser fluida, sin quedar en ningún

momento la interfaz bloqueada.



Los resultados tendrán que mostrarse de la forma más sencilla y

comprensiva posible.

La aplicación deberá estar disponible todos los días del año.

4.1.2. Planificación

Descompondré el proyecto en diferentes tareas con una estimación de la

duración de cada una y los costes de las mismas.

Estimación de tiempos

La estimación se indica en días, considerando que un día corresponde a 5

horas de trabajo, y una semana de 5 días laborables. Por tanto, se considera una

jornada laboral de 25 horas semanales.

La estimación de tiempos del proyecto está realizada en la ilustración 4.1:

Ilustración 4.1 Estimación de tiempos

La realización completa del proyecto se ha estimado en 60 días laborales.

Teniendo en cuenta que el trabajo a realizar será de 5 horas por día laboral, el total

de alcanza las 300 horas de trabajo.

Hay que tener en cuenta que la redacción y revisión de la memoria se realizará

paralelamente junto a otras tareas, por lo que la duración de la misma se ha visto

ampliada. La duración final de la redacción y revisión de la memoria, una vez

finalizadas todas las demás tareas, será de 10 días.



Con las tareas descritas en el apartado previo, he obtenido el diagrama de

Gantt presentado en la ilustración 4.2:

Ilustración 4.2 Diagrama de Gantt

La experimentación con datos médicos cobra una gran importancia en la

valoración de la aplicación, pues debe comprobarse que puede servir de utilidad a

los médicos en la extracción de reglas descriptivas para los problemas que puedan

surgir.

Estimación de costes

El personal para el desarrollo del proyecto será el de un único graduado en

informática, encargado de los diferentes aspectos del desarrollo. El coste se va a

calcular en base al precio por hora y la cantidad de horas en las que trabajará en el

proyecto. El precio por hora del graduado se ha estimado en base a un salario anual

bruto de 21.600€, dando un total de 1.800€ brutos al mes para un trabajo de 40

horas semanales.

Para el graduado en informática es de 11,25€/h brutos por hora. La diferentes

tareas se han separado para comprobar su coste individual, recordando que cada

día supone una jornada laboral de 5 horas y que la cantidad de días en los que se

realiza exclusivamente la tarea de redacción y revisión de la memoria son 10, el

resultado puede verse en la tabla 4.1:



Tarea Horas Coste en €

Revisión bibliográfica 50 562,5

Aprendizaje sobre Ciencia de Datos 25 281,25

Desarrollo software 125 1.406,25

Experimentación con datos médicos 50 562,5

Redacción y revisión de la memoria 50 562,5

Total 3.375

Tabla 4.1 Estimación de costes de tareas

El coste del personal para el proyecto será de 3.375€.

Hay que añadir el los costes derivados del hardware y las licencias utilizadas

para la realización del proyecto. El coste total se ha calculado en la tabla 4.2:

Hardware/Software €/día Días utilizado Coste en €

Equipo portátil 0,2192 35 7,672

Conexión internet 0,8 45 36

Bibliotecas de Keel 0 19 0

Bibliotecas de Weka 0 19 0

JRuby on Rails 0 19 0

Total 43,672

Tabla 4.2 Estimación de costes de recursos

El precio del ordenador portátil es de 400€, se incluye como coste de

amortización del equipo de acuerdo con el tiempo de dedicación al proyecto, a

amortizar en 5 años, se estima que el coste por día usado es de 0,2192€.

La conexión a internet básica de 24€ al mes, por lo que el día son 0,8€. Hay

que tener en cuenta que el uso de internet ha sido elevado debido a que la

aplicación a desarrollar es una aplicación web.

La suma final del coste total para la realización del proyecto es de 3.418,672€.



4.1.3. Casos de uso

En base a los requisitos previamente descritos, se identifican dos actores:

usuario y sistema. Se puede identificar los siguientes casos de uso por actor:

Usuario: registrarse en la aplicación, realizar experimentos, elegir

algoritmo, elegir discretizador y visualizar experimentos.

Sistema: ejecutar experimentos.

El diagrama de los casos de usos se puede ver en la ilustración 4.3:

Ilustración 4.3 Diagrama de casos de uso

Como se puede observar, el usuario es el que va a realizar la principal

interacción con la aplicación web.

El servidor será el encargado de la ejecución de los experimentos, por lo que

siempre tendrá que estar disponible y consultando la lista de experimentos sin

ejecutar para iniciar la ejecución.

El usuario podrá visualizar los experimentos que haya realizado, siempre que

haya realizado alguno, en cuyo caso no podrá visualizar experimentos.



Descripción de los casos de uso

Caso de uso Registrarse

Funcionalidad Permitir al usuario registrarse en la aplicación

Actor Usuario

Casos

relacionados

Pre condición Usuario no registrado en el sistema

Post condición Usuario registrado en el sistema e identificado

Proceso 1- Usuario pulsa el botón de registro

2- Usuario introduce los credenciales

3- Aplicación envía correo de activación al usuario

4- Usuario pulsa el enlace para activar la cuenta

5- Aplicación activa la cuenta

Alternativas Si el usuario no introduce correctamente algún dato, se

producirá un error y se mantendrá en la vista de registro.

Si la dirección de correo ya ha sido registrada, tampoco dejará

registrarla de nuevo.

Tabla 4.3 Caso de uso registrarse



Caso de uso Realizar experimentos

Funcionalidad Permitir al usuario realizar un experimento

Actor Usuario

Casos

relacionados

Elegir algoritmo, elegir discretizador, ejecutar experimentos

Pre condición Usuario identificado en el sistema

Post condición El experimento queda realizado y se añade a la lista de

ejecución

Proceso 1- Usuario pulsa el botón de nuevo experimento

2- Usuario selecciona los datos del experimento

3- Usuario selecciona el archivo de datos

4- Usuario confirma el experimento

5- Aplicación añade el experimento a la lista

Alternativas Si el usuario no introduce correctamente algún dato, se

producirá un error y se mantendrá en la vista de nuevo

experimento.

Tabla 4.4 Caso de uso realizar experimentos

Caso de uso Elegir algoritmo

Funcionalidad Permitir al usuario elegir un algoritmo para un experimento

Actor Usuario

Casos

relacionados

Realizar experimentos

Pre condición Usuario identificado en el sistema y creando un nuevo

experimento

Post condición El algoritmo queda elegido junto con los parámetros del

mismo

Proceso 1- Usuario elige un algoritmo para el experimento

2- Usuario modifica los parámetros del algoritmo

Alternativas El usuario puede elegir utilizar los parámetros por defecto del

algoritmo.

Tabla 4.5 Caso de uso elegir algoritmo



Caso de uso Elegir discretizador

Funcionalidad Permitir al usuario elegir un discretizador para un experimento

Actor Usuario

Casos

relacionados


Pre condición Usuario identificado en el sistema y creando un nuevo

experimento

Post condición El discretizador queda elegido

Proceso 1- Usuario elige un discretizador para el experimento

Alternativas El usuario puede no elegir un discretizador para el experimento,

en ese caso se aplicara sólo el algoritmo.

Tabla 4.6 Caso de uso elegir discretizador

Caso de uso Visualizar experimentos

Funcionalidad Permitir al usuario visualizar un experimento de los que ha

realizado

Actor Usuario

Casos

relacionados

Pre condición Usuario identificado en el sistema con un experimento creado

Post condición

Proceso 1- Usuario accede a la lista de los experimentos realizados

2- Usuario accede a un experimento

3- Usuario visualiza los datos de un experimento

Alternativas Si el experimento ha sido ejecutado, el usuario podrá ver

además los resultados del mismo.

En caso de error en la ejecución, también se mostrará para el

usuario.

Tabla 4.7 Caso de uso visualizar experimentos



Caso de uso Ejecutar experimentos

Funcionalidad Realiza la ejecución de un experimento

Actor Servidor

Casos

relacionados


Pre condición El servidor debe poder ejecutar experimentos

Post condición El experimento finaliza su ejecución

Proceso 1- Servidor coge el primer experimento en la lista de espera

2- Servidor realiza la ejecución del experimento

3- Servidor comunica al usuario la finalización del

experimento

Alternativas Si se produce un error durante la ejecución, se mostrará al

usuario cuando visualice el experimento.

Tabla 4.8 Caso de uso ejecutar experimentos



4.2. Diseño

4.2.1. Diagramas de secuencia

En este apartado mostraré los diagramas de secuencia, para cada caso de uso

especificado previamente, para dar una visión más dinámica de la aplicación.

REGISTRO

Ilustración 4.4 Diagrama de secuencia de registro

Como ya se vio en el caso de uso, si el usuario introduce datos incorrectos, o

una dirección de correo ya registrada, se mantendrá en la misma página con un

mensaje indicando el error, mientras que si introduce datos correctos se le enviará

un correo electrónico para activar su cuenta de usuario.



REALIZAR EXPERIMENTO

Ilustración 4.5 Diagrama de secuencia de realizar experimento

Al crear un nuevo experimento, el usuario tendrá que escoger los datos del

mismo, que contiene a su vez los dos siguientes diagramas de secuencia, y el

archivo sobre el que quiere aplicar el experimento.

Entre los datos incorrectos del usuario se encuentran: no elegir un archivo de

datos para el experimento o no introducir alguno de los datos importantes para el

mismo.



Si introduce los datos correctamente y elige un archivo de datos, se creará

exitosamente el experimento y seguidamente se añadirá a la lista de espera para ser

ejecutado.

ELEGIR ALGORITMO

Ilustración 4.6 Diagrama de secuencia de elegir algoritmo

La secuencia para elegir un algoritmo es bastante sencilla ya que forma parte

de la introducción de los datos del algoritmo. En esta secuencia el usuario deberá

elegir obligatoriamente un algoritmo y opcionalmente podrá introducir los parámetros

del algoritmo o usar los parámetros por defecto.



ELEGIR DISCRETIZADOR

Ilustración 4.7 Diagrama de secuencia de elegir discretizador

La secuencia para elegir un discretizador es también sencilla y junto con la de

elegir un algoritmo, forma parte de la selección de los datos de un experimento.

Aunque la elección del algoritmo no es obligatoria, por ello se puede elegir o no

elegir uno.



VISUALIZAR EXPERIMENTO

Ilustración 4.8 Diagrama de secuencia de visualizar experimento

La visualización de un experimento se va a permitir desde el momento en que

sea creado el mismo, por ellos siempre se van a mostrar los datos con los que se ha

iniciado el experimento. En caso de que haya finalizado se podrán visualizar además

los resultados, mientras que en caso de error, incluida la no finalización, se mostrará

un mensaje indicándolo.



EJECUTAR EXPERIMENTO

Ilustración 4.9 Diagrama de secuencia de ejecutar experimento

Finalmente la secuencia de ejecución de un experimento. El servidor va a

coger el primer experimento de la lista de espera y comenzará a ejecutarlo, esto es,

aplicar el algoritmo, y discretizador si se ha escogido, al conjunto de datos del

archivo elegido. Al finalizar se almacenará el resultado, ya sea con la correcta

finalización y resultado o un error en el proceso. Sea cual sea el resultado, se

notificará siempre al usuario de que se ha terminado la ejecución del experimento.



4.2.2. Diagrama de clases

El diagrama está dividido siguiendo el patrón que sigue Rails, que es el patrón

MVC, formado por:

Modelos: son las clases que representan el modelo de datos. Se

compone de las clases que interactúan con la base de datos.

Vistas: son las páginas que se muestran al usuario, donde se capturan

datos y acciones.

Controladores: son las clases que interactúan con el modelo de datos y

la interfaz de usuario, son un intermediario entre los modelos y las

vistas.

En la siguiente ilustración 4.10 puede observarse como se relacionan estos tres

componentes del patrón MVC:

Ilustración 4.10 Componentes modelo MVC de Rails



Aquí el cliente a través de su navegador realiza una petición al servidor, como

puede ser http://aplicacion.es/inicio. El servidor recibe esa petición y consulta la tabla

de rutas para comprobar que la ruta solicitada es correcta y figura dentro de las

posibles rutas que describe la tabla. De esta manera el servidor crea el controlador

correspondiente con la acción solicitada y le pasa los parámetros correspondientes.

El controlador solicitará datos al modelo, en caso de necesitarlos. Cuando tiene

todos los datos necesarios, devuelve al servidor la vista que debe mostrar y los

datos que irán en ella, además de los metadatos necesarios, como cabeceras o

redirecciones. El servidor se encargará entonces de rellenar la vista con los datos

necesarios y se la envía al cliente, como respuesta a su petición, para que el

navegador pueda mostrar la página.

Clases de los modelos

Las clases del modelo son las que intervienen en los datos, se pueden ver en

la ilustración 4.11:

Ilustración 4.11 Diagrama de clases de los modelos



Las cuatro clases actúan directamente sobre los datos. Aunque son Usuario

(user) y Experimento (query) los que interactúan con la base de datos.

Los modelos de Usuario y Experimento utilizan los modelos mailers para el

envío de correos electrónicos, el de usuario (UserMailer) se encarga de enviar el

correo de activación y de reinicio de contraseña, mientras que el de experimento

(QueryMailer) se encarga de enviar el correo de finalización de experimento. Ambos

heredan las propiedades la clase mailer de la aplicación (ApplicationMailer).

Sólo el modelo Experimento hace uso de los algoritmos (Algorithms) y

discretizadores (Discretizers) en sus respectivos modelos, que contienen todos los

algoritmos y discretizadores disponibles en la aplicación. Su función es aplicar un

algoritmo, o un discretizador, al archivo del experimento. Esto se ve efectivo en la

base de datos, donde cada experimento contiene además el algoritmo y el

discretizador que se han elegido.

Los modelos de Usuario y Experimento contienen también varias funciones

para la realización de diferentes tareas con los datos.



Clases de los controladores

Los controladores interactúan como en la ilustración 4.12:

Ilustración 4.12 Diagrama de clases de los controladores

Como he comentado previamente, los controladores son los encargados de

procesar las solicitudes seleccionando los datos necesarios de los modelos y la vista

a la que se aplica esos datos.

A cada controlador le corresponde un conjunto de vistas definidos por las

acciones que puede realizar el mismo controlador.

En este caso, los controladores de: usuarios (UsersController), reinicio de

contraseñas (PasswordResetsController), activación de cuentas

(AccountActivationsController) y sesiones de usuario (SessionsController),

interactúan con el modelo de Usuario, realizando acciones sobre los usuarios.

Mientras que el controlador de experimentos (QueriesController) interactúa con los



experimentos y con los algoritmos, ya que es el encargado de aplicar un algoritmo al

experimento.

Todos los controladores heredan del controlador de la aplicación

(ApplicationController).

Las acciones son las que utilizan los controladores. Por ser comunes en

algunos de ellos, las separaré por el nombre de la acción indicando los

controladores que la usan, el resultado se puede ver en la tabla 4.9:

Acción Descripción Controladores

create Crea un nuevo elemento, ya sea mediante

el modelo, en la base de datos, o

temporalmente en la aplicación

Usuarios, sesiones,

experimentos, reinicio de

contraseña

edit Edita los datos de los modelos que usa Usuarios, reinicio de

contraseña, activación de

cuenta

new Creación de un nuevo elemento en la

aplicación, sin guardarlo de forma

permanente

Usuarios, sesiones,

experimentos, reinicio de

contraseña

show Muestra una tupla del modelo que utiliza,

directamente de la base de datos

Usuarios, experimentos

update Actualiza el modelo que utiliza Usuarios, reinicio de

contraseña

destroy Elimina una tupla del modelo que utiliza,

directamente de la base de datos o de los

temporales de la aplicación

Sesiones, experimentos

confirm Confirma la creación de un experimento Experimentos

list Muestra una lista con los experimentos Experimentos

Tabla 4.9 Acciones de los controladores



Como ya comente previamente, por cada acción de los controladores existe

una vista correspondiente con el mismo nombre, por ellos las vistas están

contenidas en carpetas que tienen el mismo nombre que el controlador que las usa.

4.2.3. Diseño de la interfaz

El storyboard muestra la navegación que se puede realizar dentro de la

aplicación.

Lo primero que tendrá que hacer un usuario para hacer uso de la aplicación es

iniciar sesión, se ve en la ilustración 4.13:

Ilustración 4.13 Storyboard: Iniciar sesión

Una vez identificado, al usuario le espera una página de bienvenida con los

diferentes experimentos que podrá realizar. Si no posee aún cuenta de usuario,

tendrá que registrarse introduciendo los credenciales deseados.

En esta ventana podrá comprobar el estado de los experimentos que ha

realizado, pudiendo además acceder a los mismos para consultar los parámetros

elegidos y comprobar los resultados, en caso de que el experimento haya finalizado.



La ventana que se muestra es la siguiente ilustración 4.14:

Ilustración 4.14 Storyboard: sesión iniciada

Si el usuario selecciona algún experimento, se mostrarán todos los datos del

mismo como en la ilustración 4.15:



Ilustración 4.15 Storyboard: visualizar experimento

Aquí se podrán ver los datos sobre los que se ha aplicado el algoritmo, el

algoritmo utilizado, el discretizador utilizado, en caso de haber usado uno, y los

resultados obtenidos al aplicar el algoritmo sobre el archivo.

En cualquier momento el usuario puede acceder a la lista completa de los

experimentos que ha realizado a través de la acción “Experimentos”. Esto muestra

una tabla con los experimentos, la fecha de realización y el estado actual, como se

puede observar en la siguiente ilustración 4.16:



Ilustración 4.16 Storyboard: Listado de experimentos

4.3. Implementación y prueba

Para la base de la aplicación, Rails cuenta con una serie de comandos que

generan los archivos necesarios para los modelos, vistas y controladores. Dispone

incluso de un comando para generar el código básico (llamado scaffold) de un

modelo, su controlador para manipularlo, las vistas para manipular los datos y un

conjunto de test básicos. Es útil, aunque va a requerir cambiar bastantes partes del

código ya que por sí solo tiene unas cuentas desventajas: no valida los datos, si

creas usuarios no cuentan con autenticación, hay que incluir más test puesto que

son muy básicos y hay que incorporar estilo a las vistas.

Las bibliotecas de los algoritmos implementados han sido obtenidas de la

aplicación Keel (Alcalá-Fdez, y otros, 2009) y (Alcalá-Fdez, y otros, 2011).

Los archivos y carpetas que forman la aplicación, de forma similar a como

viene descrito en (Tate & Hibbs, 2007), son:



app/ Contiene los controladores (controllers), modelos (models), vistas

(views), ayudantes (helpers), mailers y recursos (assets) básicos de la

aplicación. Contiene las carpetas:

o assets/ Aquí están contenidas las imágenes, código javascript y las

hojas de estilo de la aplicación.

o controllers/ La carpeta con los diferentes controladores que forman la

aplicación.

o helpers/ Los ayudantes contienes diferentes funciones que sirven de

ayuda y que se reutilizan a lo largo de la aplicación.

o jobs/ Con las clases que se ejecutan en segundo plano mediante

Resque. Contiene también:

libraries/ Con los diferentes algoritmos en formato .jar para su

ejecución.

o mailers/ Contiene las clases encargadas de enviar los correos

electrónicos a los usuarios.

o models/ Los modelos que forman la aplicación.

o uploaders/ La clase usada para subir los archivos de los

experimentos.

o views/ Las vistas que forman la aplicación.

bin/ Contiene los scripts de Rails que se encargan de iniciar la aplicación.

config/ Contiene los archivos de configuración de la aplicación: las rutas,

base de datos y otros. Los archivos y carpetas a destacar aquí son:

o deploy/ Carpeta que contiene los archivos que se inician según se

especifique el estado de la aplicación, es decir, cada estado tiene un

archivo correspondiente que inicia la aplicación de forma diferente.

o database.yml El archivo de configuración de la base de datos.

o routes.rb En este archivo se definen las diferentes rutas de la

aplicación, que básicamente son las acciones de los controladores a

las que tiene acceso el usuario y el nombre de las mismas.

db/ Contiene el esquema de la bases de datos y las migraciones.

Gemfile En este archivo se especifican las dependencias de gemas que se

necesitan para la aplicación. Se usa con la gema Bundler.

lib/ Modulos extendidos para la aplicación.



log/ Los archivos de registros de la aplicación.

public/ La única carpeta accesible al servidor como tal, usada para guardar

los archivos subidos y los resultados producidos con los experimentos.

test/ Contiene los diferentes archivos para realizar las pruebas a la

aplicación.

El fichero de rutas tiene una gran importancia en la aplicación, pues es donde

se establecen qué acciones de los controladores están disponibles y cuál es su

nombre en la dirección (url) de la aplicación. También se define el tipo de ruta: get,

post o delete según la petición HTTP que vaya a recibir la aplicación para esa acción

concreta. Por ejemplo: una petición get se utilizará para visualizar un experimento,

mientras que si es post será para crear un nuevo experimento y delete para eliminar

un experimento ya creado.

Las rutas pueden establecerse de dos maneras. La primera es directamente

indicando el tipo de ruta, el nombre que tendrá en la aplicación y su ubicación en la

misma. Siguiendo el ejemplo de los experimentos, para poder acceder a la acción

list del controlador de experimentos (aquí llamados queries), se añade:

get „queries‟ => „queries#list‟

Esta línea indica que se van a aceptar peticiones get a la url acabada con

/queries y que al acceder ahí, se va a mostrar la acción list del controlador

QueriesController. Esta acción tiene asignada su vista bajo el mismo nombre list.

Para el envío de correos electrónicos es necesario configurar la aplicación

editando el archivo correspondiente al entorno en el que se va a utilizar. Yo para

realizar las pruebas de correos con Gmail, primero he creado una cuenta de correo

electrónico exclusiva para la aplicación.

Tras haber creado la cuenta, he editado el archivo de configuración de

ambiente situado en config/environments/ y llamado development.rb añadiendo al

final la configuración para el envío de correos con Gmail, que consiste en las

siguientes líneas:

config.action_mailer.delivery_method = :smtp

config.action_mailer.smtp_settings = {



address: 'smtp.gmail.com',

port: 587,

domain: 'example.com',

user_name: '<username>',

password: '<password>',

authentication: 'plain',

enable_starttls_auto: true }

Indicando en „<username>‟ el nombre de usuario de la cuenta y en

„<password>‟ la contraseña de la misma.

Uno de los entornos que proporciona Rails para realizar comprobaciones del

funcionamiento de la aplicación es el entorno de pruebas (test), utilizado cuando se

ejecutan los test desarrollados. Estas pruebas se realizan mediante un código de

test con el que se definen diferentes funciones para simular el comportamiento de la

aplicación en determinadas situaciones. De este modo se consiguen conjuntos de

pruebas que pueden ejecutarse en cualquier momento para comprobar que los

cambios a la aplicación no afectan al comportamiento que debe tener.

Como dije previamente, los test están ubicados en la carpeta test de la

aplicación, dividiéndose en carpetas según el tipo. A cada modelo y controlador,

siempre que se hayan creado mediante los comandos de Rails, les va a

corresponder un test que de base incorpora las pruebas básicas.

Los test se definen junto a una cadena con la descripción, que sirve para

identificar al test en caso de que no se haya podido cumplir. Después se definen los

pasos que va a seguir la aplicación, que pueden ser desde peticiones como get o

post, o comprobaciones, de redirección, de comprobación HTML y demás.

Para la realización de los test se pueden definir usuarios y experimentos que

serán utilizados como si estuvieran verdaderamente almacenados en la base de

datos, pero en lugar de mantenerse ahí se mantiene su definición en la carpeta

fixtures. Estos datos son útiles para no crear datos de prueba en la base de datos y

además tener un rápido acceso en caso de necesitar añadir o cambiar datos para

las pruebas.



Los test básicos para comprobar las funcionalidades de la aplicación son los

siguientes:

Para los modelos que interactúan con la bases de datos, Usuario y

Experimento, se comprueban las validaciones básicas comprobando que

aceptan sólo valores que entran en lo especificado para el modelo, esto es,

que la contraseña tenga un tamaño mínimo, que el correo electrónico sea

una dirección tipo “[email protected]” pudiendo tomar cualquier valor

mientras se ajuste a la norma, que estén presentes los campos obligatorios,

que la dirección de correo es única y que al destruir un usuario se destruyen

los experimentos asociados.

Para los controladores se comprueba que se obtienen las páginas que se

han especificado por cada acción. Además para los controladores de

usuarios y experimentos se comprueba que no permite el acceso sin

haberse identificado antes, esto es, que redirige a la acción de identificarse

si no está identificado e intenta acceder a la lista de experimentos o editar

los datos de usuario.

Para el ayudante (helper) de sesiones, se comprueba que las funciones que

tiene devuelven los resultados esperados.

Para los mailers se comprueba que el correo que se envía tiene los

parámetros correctos en el mismo.

Además de estos test, se han añadido los siguientes para comprobar el

correcto funcionamiento de la página:

Se comprueba que se puede realizar un reinicio de contraseña correcto,

siguiendo todos los pasos para el mismo y añadiendo algunos pasos de

error para asegurar que responde correctamente. Los pasos que sigue son:

o Tras acceder a la página de solicitud, se introduce un correo

electrónico no válido y se comprueba que recarga la página

indicando que el correo no es válido.

o El siguiente paso es introducir un correo electrónico válido y

comprobar que envía el correo de reinicio de contraseña a la vez que

redirige a la página de inicio.



o Se accede a la página de edición de contraseña con un correo

erróneo y se comprueba que redirige al inicio.

o Se intenta acceder a la página de edición de contraseña con un

usuario no activo y se comprueba que no está permitido redirigiendo

al inicio.

o Intenta acceder a la página de edición de contraseña con un correo

electrónico correcto, pero con el autentificador equivocado y al igual

que antes redirige al inicio.

o Se accede a la página de edición de contraseña con correo

electrónico y autentificador correctos, mostrando los campos para

editar la contraseña.

o Se prueba una combinación errónea de contraseña y confirmación de

contraseña, que genera un error en la misma página.

o No se introduce una nueva contraseña y redirige a la página de

edición de nuevo con un aviso.

o Finalmente se introduce una contraseña y una confirmación de

contraseña correctas, redirigiendo a la página de usuario.

Se comprueba que los enlaces a las páginas estáticas son visibles en todo

momento, estas son las páginas de inicio, ayuda y contacto.

Se comprueba la edición de los datos de un usuario mediante dos

funciones:

o La primera intenta introducir datos no válidos, comprobando que no

deja editar los datos y se mantiene en la página de edición.

o La segunda introduce datos correctos realizando la edición y se

comprueba que redirige a la página de inicio una vez finalizada la

correcta edición.

Se comprueba la identificación de usuarios mediante cuatro funciones:

o Introduciendo datos incorrectos, comprobando que se recarga la

página de identificación con un mensaje indicando la introducción de

datos erróneos.

o Introduciendo datos correctos, comprobando que redirige a la lista de

experimentos, que el enlace para identificarse ya no está y sin

embargo el de cerrar sesión sí está, eliminando la sesión mediante el



enlace de cerrar sesión y comprobando que ha vuelto el enlace de

iniciar sesión.

o Identificándose con permanencia en las cookies y comprobando que

existen cookies para el usuario.

o Identificándose sin permanencia en las cookies y comprobando que

no existen cookies para el usuario.

Se comprueba que no se puede acceder a la lista de experimentos

realizados sin estar identificado, redirigiendo a la acción de iniciar sesión y

que si se inicia sesión, se redirige a la lista de experimentos, como se

pretendía inicialmente.

Finalmente se comprueba el registro de usuarios mediante dos test:

o El primero intenta crear un usuario con datos incorrectos, cargando

de nuevo la acción de registrarse.

o El segundo es más complejo ya que prueba el registro correcto de un

usuario junto con la activación de la cuenta, siguiendo estos pasos:

Accede a la acción de registro e introduce datos correctos

para crear un nuevo usuario.

Comprueba que se ha enviado un correo electrónico tras el

registro.

Intenta iniciar sesión con el usuario no activo, comprobando

que no se inicia la sesión.

Intenta activar la cuenta de usuario utilizando un autentificador

incorrecto y comprueba que no se ha realizado pues el usuario

no está conectado.

Intenta activar la cuenta con el autentificador correcto pero con

el correo electrónico erróneo, otra vez resultando en que el

usuario no está conectado.

Finalmente activa la cuenta de usuario con los datos

correctos, comprueba que la cuenta de usuario está ahora

activa y que la aplicación redirige a la lista de experimentos,

estando el usuario identificado.



5. Experimentación

En esta sección se comprobaran diferentes experimentos utilizando la

aplicación web ya desarrollada, utilizando diferentes conjuntos de datos médicos

para comprobar la viabilidad de la aplicación en este contexto.

Se explicarán los contenidos de cada conjunto de datos que se vaya a analizar

y se mostrarán los resultados de todos los algoritmos implementados

comparándolos, y en cada caso analizando los mismos resultados para ver el

algoritmo que ha obtenido las mejores medidas de calidad.

Es probable que los conjuntos de datos incluyan datos continuos, que no son

tratables por algunos de los algoritmos. En estos casos se aplicará un discretizador,

indicando para cada problema cual ha sido el discretizador elegido y con qué

algoritmos se ha utilizado.

5.1. Algoritmos utilizados

Para todos los experimentos se van comparan los resultados de todos los

algoritmos incluidos en la aplicación con los parámetros establecidos por defecto. El

objetivo de los experimentos es ver el comportamiento de diferentes algoritmos ante

el mismo conjunto de datos.

Los algoritmos que se van a utilizar son:

Apriori-SD

CN2-SD

SD

SD-Map

MESDIF

SDIGA

De entre ellos, los cuatro primeros, Apriori-SD, CN2-SD, SD y SD-Map, no

pueden tratar con variables no discretas y necesitan de una discretización previa. El



proceso de discretización utilizado es el discretizador de Fayyad, descrito con CN2-

SD en (Lavrac, Flach, Kavsek, & Todorovski, 2002).

Los parámetros utilizados, que son los que incorpora por defecto la aplicación,

están resumidos en la tabla 5.2:



Algoritmo Parámetros

Apriori-SD - Minimum support = 0.03

- Minimum confidence = 0.9

- Number of rules = 5

CN2-SD - Nu value = 0.5

- Percentage examples to cover = 0.95

- Star size = 5

- Use multiplicative weights = YES

- Use disjunt selectors = NO

MESDIF - Number of labels = 3

- Number of evaluations = 10000

- Population length = 100

- Crossover probability = 0.6

- Mutation probability = 0.01

- Elite length = 3

SD - g = 10

- Minimum support = 0.1

- Beam width = 5

- Number of rules = 0

SDIGA - Number of labels = 3

- Number of evaluations = 10000

- Population length = 100

- Crossover probability = 0.6

- Mutation probability = 0.01


- Weight for support = 0.4

- Weight for confidence = 0.3

- Weight for unusualness = 0.3

SD-Map - Minimum support = 0.1


- Rules return = 10

Tabla 5.1 Parámetros por defecto de los algoritmos



5.2. Conjunto de datos heart: enfermedad del corazón

La detección de enfermedades en el ámbito médico es un problema que si se

detecta a tiempo, puede ayudar a los médicos a tratar a los pacientes que pueden

tener los problemas. Identificando los diferentes subgrupos que pueden tener una

enfermedad en el corazón, se pretende proporcionar a los médicos una herramienta

que pueda ayudarles en la detección. El objetivo es entonces obtener información de

los pacientes que tienen ausencia o presencia de una enfermedad del corazón.

Este conjunto de datos ha sido obtenido del repositorio de (Lichman, 2013). La

información está recopilada en 13 atributos con la información (como edad, sexo,

dolor en el pecho, presión sanguínea o colesterol, entre otras) sobre diferentes

casos o pacientes, en un total de 270 muestras. La tabla 5.2 muestra los atributos

considerados para el problema:

N Nombre Valores

1 Age [29, 77]

2 Sex [0, 1]

3 Chest pain type [1, 4]

4 Rest blood pressure [94, 200]

5 Serum cholestoral [126, 564]

6 Fasting blood sugar [0, 1]

7 Resting electrocardiographic [0, 2]

8 Maximum heart rate [71, 202]

9 Exercise induced angina [0, 1]

10 Oldpeak [0.0, 62.0]

11 Slope of the peak exercise [1, 3]

12 Number of major vessels [0, 3]

13 Thal [3, 7]

- Class {1, 2}

Tabla 5.2 Atributos del conjunto de datos de enfermedad del corazón

La variable de interés, que en este caso es la clase, representa con los valores

1 y 2 la ausencia o presencia, respectivamente, de una enfermedad del corazón.



5.2.1. Resultados obtenidos

La tabla 5.3 muestra los resultados obtenidos por los algoritmos, donde se

añaden también las siguientes medidas de calidad:

nr es el número medio de reglas obtenidas.

nv es el número medio de variables por regla.

COB es la cobertura (1).

SIG es la significancia (7).

WRAcc es la atipicidad (11).

SOP es el soporte (2).

CNF es la confianza (3).

Los resultados marcados en negrita representan que para esa medida de

calidad, es el mejor obtenido de todos los algoritmos.

Algoritmo nr nv COB SIG WRAcc SOP CNF

Apriori-SD 10 2.6 0.2807 58.7317 - 0.8629 -

CN2-SD 9 1.7778 0.3827 46.2825 0.0883 0.9778 0.8593

MESDIF 6 3.3333 0.279 6.19951 0.05 0.8148 0.6803

SD 10 3.7 0.2719 25.7921 0.1108 0.8556 0.9129

SDIGA 3 2.6666 0.5246 8.8886 0.0909 0.9194 0.6936

SD-Map 10 7 0.011 31.586 0.052 0.1 0.931

Tabla 5.3 Resultados para el conjunto de datos de enfermedad del corazón

Los resultados que no aparecen en la tabla no son calculados por la aplicación

y por ello no han sido incluidos, esto afecta al algoritmo Apriori-SD.

Hay que analizar los resultados por cada medida de calidad para poder

escoger el algoritmo con el mejor comportamiento:

Para el número de reglas y de variables de cada regla, buscamos que la

reglas encontradas tengan la menor cantidad de atributos para facilitar su

comprensión. En este caso SD-Map ha obtenido reglas de descripción de



subgrupos con una elevada cantidad de variables, que no son

representativas. Se puede observar que CN2-SD ha obtenido el menor

número medio de variables, obteniendo buenos resultados, sin embargo

SDIGA ha conseguido un menor número de reglas y la cantidad de

variables por regla se mantiene también relativamente baja.

Para la medida de cobertura (COB), SDIGA ha obtenido los subgrupos que

cubren la mayor cantidad de ejemplos de los datos en comparación al resto,

especialmente a SD-Map que ha vuelve a situarse en última posición en la

cobertura media. Los ejemplos de SDIGA cubren de media más del 50% de

los ejemplos.

En significancia (SIG) los mejores resultados han sido obtenidos por Apriori-

SD, aunque CN2-SD ha obtenido también buenos resultados.

Para la atipicidad (WRAcc) el algoritmo SD ha obtenido el mejor resultado,

un poco mayor de 0.1, teniendo cerca SDIGA y CN2-SD con buenos

resultados, en contraste con los 0.05 y 0.052 obtenidos por MESDIF y SD-

Map.

En soporte (SOP) los resultados de CN2-SD han sido excelentes, cubriendo

casi la totalidad de los ejemplos, seguido muy de cerca por SDIGA que ha

cubierto más de un 90% de los casos. SD-Map ha obtenido un bajo

porcentaje de soporte ajustándose al mínimo especificado en los

parámetros por defecto.

Por último, respeto a la confianza (CNF), el algoritmo SD ha conseguido la

mejor media, obteniendo SDIGA y MESDIF resultados similares.

Teniendo en consideración el análisis previo, el algoritmo que obtiene los

mejores resultados en general es SDIGA por la gran simplicidad y cobertura de

reglas, una buena relación soporte y confianza, buen resultado de atipicidad y

aceptable significancia.

5.2.2. Reglas obtenidas por SDIGA

Ya determinado que SDIGA ha sido el algoritmo que ha obtenido los mejores

resultados para el conjunto de datos de enfermedad del corazón, se van a analizar

las reglas que ha producido junto con las medidas de calidad proporcionadas por

cada regla (tabla 5.4).



Número Regla SIG WRAcc SOP CNF

0 Oldpeak = Label 0 (31.0 0.0 31.0) AND

MajorVessels = Label 0 (1.5 0.0 1.5)

THEN 1 (absence)

16.6797 0.1234 0.92 0.8139

1 ExerciseInduced = Label 0 (0.5 0.0 0.5)

THEN 1 (absence)

7.0599 0.0979 0.8466 0.7016

2 SerumCholestoral = Label 1 (126.0

345.0 564.0) AND MaxHeartRate =

Label 1 (71.0 136.5 202.0) THEN 2

(presence)

2.926 0.0514 0.9916 0.5651

Tabla 5.4 Reglas obtenidas por SDIGA para heart

La primera es una regla con un buen nivel de confianza y gran soporte. La

última sin embargo es menos buena, porque aunque el soporte es muy grande la

confianza es demasiado baja.

5.3. Conjunto de datos dermatology: enfermedades de la piel

Existen diferentes campos de la medicina donde la extracción de conocimiento

de grandes conjuntos de datos puede ayudar mucho a los médicos en el diagnóstico

de enfermedades para su correcto tratamiento. En este conjunto de datos el campo

médico a tratar es la dermatología, que se ocupa de las enfermedades de la piel, y

en concreto del diagnóstico de enfermedades eritematoescamosas (rojas y

escamosas).

Este conjunto de datos, obtenido de (Lichman, 2013), está formado por un total

de 366 muestras junto a un total de 34 atributos, sin incluir la clase, con la

información de pacientes, siguiendo esta clasificación: los pacientes fueron

evaluados clínicamente con 12 características, después se tomaron muestras de piel

para la evaluación de 22 características hispatológicas. Los valores de las

características histopatológicas se determinaron con un análisis de las muestras

bajo microscopio. La cantidad de pacientes de los que se recogieron datos son 366.

En el conjunto de datos construido para este dominio, el historial familiar tiene

valor 1 si alguna de las enfermedades se han observado en la familia, y 0 en caso

contrario. La edad representa simplemente la edad del paciente. Al resto de atributos



se les ha asignado un grado dentro del rango de 0 a 3, donde 0 indica que el atributo

no está presente, 3 indica la mayor cantidad posible, y 1, 2 indican niveles

relativamente intermedios.

Los atributos que contiene el conjunto de datos son los siguientes (teniendo

todos valor comprendido entre 0 y 3, excepto la edad y el historial familiar), primero

los atributos clínicos, mostrados en la tabla 5.5:

N Nombre

1 Erythema

2 Scaling

3 Definite borders

4 Itching

5 Koebner phenomenon

6 Polygonal papules

7 Follicular papules

8 Oral mucosal involvement

9 Knee and elbow involvement

10 Scalp involvement

11 Family history

34 Age

Tabla 5.5 Atributos clínicos de dermatología

Y a continuación los atributos histopatológicos, mostrados en la tabla 5.6:



N Nombre

12 Melanin incontinence

13 Eosinophilis in the infiltrate

14 PNL infiltrate

15 Fibrosis of the papillary dermis

16 Exocytosis

17 Acanthosis

18 Hyperkeratosis

19 Parakeratosis

20 Clubbing of the rete ridges

21 Elongation of the rete ridges

22 Thinning of the suprapapillary epidermis

23 Spongiform pustule

24 Munro microabcess

25 Focal hypergranulosis

26 Disappearance of the granular layer

27 Vacuolisation and damage of basal layer

28 Spongiosis

29 Saw-tooth appearance of retes

30 Follicular horn plug

31 Perifollicular parakeratosis

32 Inflammatory monoluclear inflitrate

33 Band-like infiltrate

Tabla 5.6 Atributos histopatológicos de dermatología

Finalmente la variable de clase puede tomar los valores de 1 a 6,

representando las diferentes categorías que hay de enfermedad en la piel.

Cabe destacar que el conjunto de datos original incluye valores perdidos.

Todos los algoritmos están preparados para recibir valores perdidos pues tienen

métodos incorporados para tratar con ellos. Sin embargo Apiori-SD no incluye

ningún método por lo que han tenido que eliminarse los datos perdidos

directamente, reduciendo la muestra a 358 (pues sólo contiene 8 valores perdidos).



En cuanto al resto de algoritmos, el tener valores perdidos nos permitirá ver

cómo reaccionan ante ello y los resultados que se obtienen.














CN2-SD 7 4.2857 0.1714 190.1635 0.1507 0.9918 0.9836

MESDIF 18 20.6666 0 0 0 0 0

SD 22 3.0909 0.1950 79.4829 0.1292 0.9672 0.8932

SDIGA 6 7.5 0.4699 11.5256 0.0103 0.7212 0.1693

Tabla 5.7 Resultados para el conjunto de datos de dermatología

El algoritmo MESDIF con los parámetros por defecto para este conjunto de

datos no ha obtenido reglas útiles.

Para comprobar el algoritmo que ha obtenido un mejor resultado en la

extracción de reglas para este conjunto de datos, hay que comprobar los resultados

en las distintas medidas de calidad obtenidas:



Respecto al número de reglas, SDIGA ha obtenido el menor número de

todos los algoritmos, que como siempre buscamos que la cantidad sea

la menor posible para una mayor comprensión. Aunque en número de

variables ha sido superado por SD y CN2-SD.

En cuanto a la cobertura, SDGIA ha sido el que más se ha acercado al

50%, con casi un 47% de ejemplos cubiertos. Por su parte CN2-SD no

ha conseguido un buen nivel de cobertura.

Siguiendo con la significancia, CN2-SD ha obtenido el mejor valor,

bastante superior al resto de los algoritmos. El resultado de SD tampoco

ha estado mal, aunque SDIGA no ha obtenido muy buen resultado,

sigue siendo un buen resultado en comparación a otros problemas.

La atipicidad está algo más justa entre CN2-SD y SD, pero el primero ha

logrado un mayor grado de la misma. SDIGA ha obtenido un resultado

bajo en atipicidad.

En cuanto al soporte, CN2-SD ha obtenido un mayor nivel respecto a los

demás, que también han conseguido un alto nivel de soporte.

Para finaliza, respecto a la confianza, CN2-SD vuelve a obtener el mejor

resultado, seguido de cerca por SD. Por el contrario, SDIGA no ha

conseguido una buena confianza.

Teniendo en cuenta los resultados de las diferentes medidas de calidad, el

algoritmo que obtiene los mejores resultados de media es CN2-SD, que aunque no

haya obtenido la menor cantidad de reglas y de variables por regla, sí que ha

obtenido buenos resultados en cuanto al resto de las medidas de calidad.

5.3.2. Reglas obtenidas por CN2-SD

Siendo CN2-SD el algoritmo con mejores resultados de media, a continuación

se verán las reglas generadas por el mismo para este problema. Además del

número de regla y la regla en sí, CN2-SD ofrece también el porcentaje de

pertenencia a la clase consecuencia de los ejemplos clasificados. Por ejemplo, en la

primera regla ha obtenido un poco más de un 83% de pertenencia, esto quiere decir

que de todo los ejemplos que ha clasificado como clase 1, por la conclusión de la

regla, un poco más un 83% pertenecen efectivamente a la clase 1.



Como se ha usado un discretizador para los valores de los atributos, entre

paréntesis se indica la cantidad correspondiente al discretizador, por ejemplo, en la

primera regla dice “Thal = 0 (<4.5)”, quiere decir que el atributo Thal tiene que ser

igual a la etiqueta 0, que significa un valor menor que 4.5 para la variable.

N Regla Pertenencia

1 IF Thal = 0 (<4.5) AND Oldpeak <> 1(>17.0) THEN 1 83.7037%

2 IF MajorVessels <> 1 (>0.5) AND ExerciseInduced = 0 (<0.5)

THEN 1

85.0%

3 IF ChestPainType <> 1 (>3.5) THEN 1 79.4326%

4 IF MajorVessels = 1 (>0.5) AND ChestPainType = 1 (>3.5) THEN

2

92.6471%

5 IF Thal > 0 (<4.5) AND Slope = 1 (>1.5) THEN 2 81.7073%

6 IF MajorVessels = 1 (>0.5) AND Sex = 1 (>0.5) THEN 2 82.9268%

7 IF Slope = 1 (>1.5) AND MaxHeartRate = 0 (<147.5) THEN 2 77.907%

8 IF Thal > 0 (<4.5) AND ChestPainType = 1 (>3.5) THEN 2 87.1795%

9 IF Age = 1 (>54.5) THEN 2 57.971%

Tabla 5.8 Resultados de CN2-SD para dermatology

Como se puede ver, ha obtenido una gran cantidad de positivos verdaderos, es

decir, de casos correctamente identificados. En las dos reglas que se puede apreciar

el descenso de la correcta clasificación es en aquellas que tienen sólo un atributo

clasificador, que son la 3 y la 9, especialmente la número 9 que apenas se ha

realizado una clasificación correcta. Teniendo en cuenta el resto de normas, se ha

obtenido buenos resultados en la extracción de subgrupos.

5.4. Conjunto de datos thyroid: detección de anomalías en la

glándula tiroides

El diagnóstico de enfermedades es un problema común en el ámbito de la

medicina y es usual encontrarse con la necesidad de encontrar una solución al

mismo. El conjunto de datos a tratar está centrado en la detección de algún tipo de



anomalía en la tiroides, glándula encargada de la secreción de hormonas

relacionadas con el metabolismo y el crecimiento.

El conjunto de datos, obtenido de (Lichman, 2013), lo forman un total de 7200

muestras con diferentes características de pacientes. En concreto son 21 atributos,

sin contar con la clase, que describen a cada uno de los pacientes. La tabla 5.8

muestra los atributos que trata el problema, junto a los valores que puede tomar

cada uno:

N Nombre Valores

1 Age [0.01,0.97]

2 Sex [0,1]

3 On_thyroxine [0,1]

4 Query_on_thyroxine [0,1]

5 On_antithyroid_medication [0,1]

6 Sick [0,1]

7 Pregnant [0,1]

8 Thyroid_surgery [0,1]

9 I131_treatment [0,1]

10 Query_hypothyroid [0,1]

11 Query_hyperthyroid [0,1]

12 Lithium [0,1]

13 Goitre [0,1]

14 Tumor [0,1]

15 Hypopituitary [0,1]

16 Psych [0,1]

17 TSH [0.0,0.53]

18 T3 [0.0005,0.18]

19 TT4 [0.0020,0.6]

20 T4U [0.017,0.233]

21 FTI [0.0020,0.642]

Tabla 5.9 Atributos de tiroides

La variable de clase toma uno de los valores entre 1,2 y 3, según el resultado

del paciente. El valor 1 se toma cuando el paciente tiene la tiroides normal, el 2 se



toma cuando el paciente sufre de hipertiroidismo y el 3 se toma cuando el paciente

sufre de hipotiroidismo.














CN2-SD 3 3 0.3264 1409.292 0.0358 0.9754 0.9961

MESDIF 9 11.1111 0.4159 17.3344 0.0065 0.7893 0.33834

SD 5 2 0.3096 143.2799 0.0224 0.9253 0.9958

SDIGA 4 2 0.2901 27.3627 0.0025 0.9999 0.5061

Tabla 5.10 Resultados para el conjunto de datos de tiroides

Paso a analizar los resultados obtenidos en cada medida de forma individual

para determinar el algoritmo que ha obtenido los mejores resultados en la ejecución

con este conjunto de datos:

Por lo general, el número de reglas obtenidas de cada algoritmo ha sido

menor a otras ocasiones, destacando CN2-SD y SDIGA, que junto con

SD tiene una cantidad buena de atributos por regla.

En cuanto a la cobertura de los ejemplos, MESDIF ha obtenido la mayor

cantidad, con CN2-SD siendo el que más se ha aproximado a ese



resultado. Sin embargo SDIGA ha obtenido el resultado más bajo para

esta medida.

Respecto a la significancia, CN2-SD ha vuelto a obtener el mayor valor,

seguido por SD que también ha obtenido buen resultado.

En atipicidad, CN2-SD y SD han obtenido los mejores resultados,

destacando bastante por encima de los evolutivos MESDIF y SDIGA.

En cuanto a soporte, SDIGA ha obtenido un alto nivel de soporte con las

reglas que ha extraído. Aunque CN2-SD también ha obtenido muy buen

resultado, se ha quedado con el menor valor el algoritmo MESDIF.

Por último vuelve a destacar CN2-SD en la confianza de las reglas, que

junto con el algoritmo SD, ha obtenido muy buen resultado.

Considerando los resultados en las medidas de calidad utilizadas, el algoritmo

CN2-SD vuelve a ser el que ha obtenido los mejores resultados, con un alta

comprensión, un porcentaje de cobertura aceptable, una significancia muy elevada y

una atipicidad, soporte y confianza muy buenas.

5.4.2. Reglas obtenidas por CN2-SD

Al igual que en conjunto de datos anterior, CN2-SD ha obtenido los mejores

resultados en cuanto a la extracción de subgrupos. Junto a las reglas, proporciona

un porcentaje de pertenencia a las distintas clases, que en este caso son tres con

los valores 1, 2 y 3.

Como se ha vuelto a usar un discretizador, se indicará entre paréntesis el valor

que puede tomar la etiqueta asignada. En este caso hay atributos que pueden tomar

el valor en un rango, por ejemplo, en la primera regla dice “FTI <= 2 (0.0345,

0.064255)”, esto quiere decir que el valor de FTI será menor o igual que el valor

comprendido entre las dos cifras del paréntesis.



N Regla Pertenencia

1 IF TSH > 0 (< 0.00605) AND FTI <= 2 (0.0345, 0.064255) AND T3

<> 7 (0.02005, 0.0207) THEN 1

91.7127%

2 IF TSH > 0 (< 0.00605) AND FTI > 2 (0.0345, 0.064255) AND

On_thyroxine <> 1 (>0.5) AND TT4 <= 4 (0.0895, 0.1505) AND T3

<> 7 (0.02005, 0.0207) THEN 2

96.5879%

3 IF TSH = 0 (< 0.00605) THEN 3 100.0%

Tabla 5.11 Resultados de CN2-SD para thyroid

El algoritmo CN2-SD ha obtenido en este caso una regla para cada uno de los

valores de la variable de clase. De las tres reglas extraídas, la que proporciona un

patrón para el valor de la clase 3 clasifica correctamente la totalidad de ejemplos que

cumplen el antecedente, demostrando ser una regla de alta importancia debido a su

fácil compresión. La segunda regla, pese a tener también un alto porcentaje de

pertenencia, ha obtenido el mayor número de variables de las tres dificultando un

poco la comprensión de la misma. Para acabar, la primera regla con el menor

porcentaje de pertenencia ha obtenido una menor cantidad de variables que la

segunda, pero el porcentaje conseguido no es tan bueno como en el caso de la

primera, mejorando la comprensión pero empeorando la clasificación correcta.

Sin embargo, en general, el comportamiento de las reglas es muy bueno ya

que ninguna baja del 90% de ejemplos clasificados correctamente.

6. Conclusiones

La aplicación desarrollada para la extracción de reglas descriptivas cumple su

función de proporcionar una interfaz sencilla e intuitiva para la realización de

experimentos y obtención de resultados que muestren que se ha producido una

extracción del conocimiento de los datos utilizados.

Primero se ha realizado un estudio de las tecnologías existentes para

desarrollar una aplicación de este tipo, para la posterior elección de una para el

desarrollo de la aplicación web, que se ha llevado a cabo utilizando JRuby on Rails

para la gestión de la aplicación, consiguiendo que funcione en un servidor Apache



mediante la tecnología de Phusion Passenger. Esto cubre el objetivo de desarrollar

una aplicación para la extracción de reglas.

El desarrollo de la aplicación se ha basado en los algoritmos profundizados a lo

largo del TFG, con los cuales he podido aprender mucho sobre la extracción de

reglas descriptivas en bases de datos.

Otro objetivo cumplido ha sido el aprendizaje y profundización en el

conocimiento de métodos de analítica de datos predictiva y descriptiva, centrado un

poco más en la parte descriptiva pues era el objetivo principal de la aplicación a

desarrollar, junto con la consecuente mejora en el conocimiento sobre Ciencia de

Datos.

El uso de la ingeniería del software en este proyecto ha colaborado a alcanzar

los objetivos propuestos y un correcto desarrollo de la aplicación, manteniendo

siempre en mente los requisitos necesarios que debía cumplir y realizando la

implementación de manera exitosa.

En la experimentación se ha podido observar como uno de los algoritmos ha

obtenido buenos resultados en todos los conjuntos utilizados para las pruebas. Este

ha sido el algoritmo CN2-SD en conjunto con el discretizador definido para el mismo,

discretizador de Fayyad.

La aplicación ha sido desarrollada pensando en el personal sanitario, sin

embargo esto no excluye su uso a otro tipo de personal. Tanto dueños de negocios

como empresas pueden beneficiarse del uso de esta aplicación, aunque los

algoritmos escogidos no hayan sido pensando en su uso, siempre pueden obtenerse

un mayor nivel de conocimiento en base a los resultados que se obtienen mediante

la realización de experimentos.

Para trabajos futuros, puede ampliarse siempre la cantidad de algoritmos que

incorpora la aplicación, además de recomendaciones en base al conjunto de datos

para facilitar aún más la tarea de extracción. También se puede escalar la aplicación

para poder usar más de un servidor y así distribuir las ejecuciones de experimentos,

reduciendo los tiempos de espera y aumentando la eficiencia en ese aspecto. Por

supuesto la separación de aplicación web del procesamiento de aplicaciones es



también otro posible punto de ampliación, que mejoraría mucho la carga inicial de la

aplicación y su navegación interna, pues no estaría dividido el servidor en

procesamiento y ejecución de experimentos.

7. Anexos

7.1. Manual de instalación

En este apartado se explica la instalación de la aplicación en un servidor, usando

como sistema operativo Ubuntu 15.04 e incluye comandos ejecutados directamente

en la consola del sistema.

El primer paso consiste en la instalación de JRuby on Rails para iniciar la

programación de la aplicación. Para la gestión de las diferentes versiones he

utilizado el gestor de versiones rvm, puesto que facilita el uso y el cambio de una

versión a otra. Para instalarlo (más instrucciones en la web), se utilizan dos

comandos:

gpg --keyserver hkp://keys.gnupg.net --recv-keys 409B6B1796C275462A1703113804BB82D39DC0E3

\curl -sSL https://get.rvm.io | bash -s stable

Una vez instalado, sólo hay que instalar JRuby. Primero se actualiza rvm para

obtener la versión más reciente de JRuby:

rvm get head

Para asegurarse de que todas las dependencias están instaladas, rvm cuenta

con el siguiente comando para comprobar que está todo instalado:

rvm requirements

Finalmente instalamos JRuby on Rails:

rvm install jruby

rvm use jruby

jruby -S gem install rails



Para poder utilizar la aplicación a través de la conexión de red mediante

Apache y Phusion Passenger primero hay que instalarlos, primero Apache:

sudo apt-get install apache2

Y luego Passenger, siguiendo las instrucciones que proporcionan de manera

abreviada:

sudo apt-key adv --keyserver keyserver.ubuntu.com --recv_keys 561F9B9CAC40B2F7

Modificar el archivo /etc/apt/sources.list.d/passenger.list introduciendo la

siguiente línea:

deb https://oss-binaries.phusionpassenger.com/apt/passenger trusty main

Ya se puede instalar mediante el comando apt-get:

sudo apt-get update

sudo apt-get install libapache2-mod-passenger

sudo a2enmod passenger

sudo service apache2 restart

Con esto está iniciado el servidor. Para la aplicación, hay que tenerla ya

descargada en el sistema de archivos, ir a la ubicación de la misma e instalar todas

las gemas necesarias mediante:

bundle install

Y preparar la base de datos con el siguiente comando de Rails:

rake db:migrate

Ya se puede iniciar la aplicación de modo local, para ello sólo hace falta ir a la

carpeta de la aplicación y utilizar el comando:

rails s

La misma consola indicará la dirección, que por defecto es localhost:3000. Para

realizar el despliegue, basta con configurar Apache indicando la ubicación de la

aplicación y que se está usando el módulo Passenger. Se crea un archivo con la



configuración en /etc/apache2/sites-available/app_name.conf, donde “app_name” es

el nombre de la aplicación y se añaden las siguientes líneas:

<líneas de configuración para passenger>

El último paso es activar la aplicación web en Apache, para ello hay que

asegurarse de que el enrutador al que está conectado el ordenado permite

forwarding del puerto 80 (dentro de la misma configuración del enrutador).

Desactivamos la aplicación por defecto de Apache y activamos la aplicación JRuby:

sudo a2dissite 000-default

sudo a2ensite app_name

sudo service apache2 reload

Ya se puede acceder a la dirección IP pública del sistema y empezar a utilizar

la aplicación.

Para la ejecución de los algoritmos, primero es necesario tener Java instalado.

Puedes hacerlo siguiendo las instrucciones de la página web.

Con Java instalado, sólo hay que iniciar la cantidad de trabajadores que

quieras (teniendo en cuenta que cada uno te consumirá memoria del sistema)

mediante el siguiente comando, estando ubicado en la carpeta de la aplicación:

jruby -S rake resque:work QUEUE=‟queries‟

Resque proporciona además una sencilla interfaz de visualización de colas,

para saber cómo va la ejecución de código en los trabajadores y controlar

ejecuciones fallidas. Se puede iniciar con la siguiente línea:

jruby -S resque-web -p 8282

Donde “8282” es un puerto específico y puedes usar el que quieras, mientras

que no esté ya ocupado.



7.2. Manual de usuario

En este apartado pasaré a comentar cómo se realizan las cosas, desde el

punto de vista primero del modelo de usuarios y posteriormente desde el modelo de

experimentos. La explicación irá acompañada de diferentes ilustraciones que

mostrarán el comportamiento de la aplicación en las situaciones comentadas.

Ilustración 7.1 Página de inicio de la aplicación

7.2.1. Usuarios

Puesto que la aplicación está pensada para que cada usuario tenga su propia

cuenta y así poder mantener sus experimentos privados, además de acceder a ellos

cómodamente con los credenciales que establezca, es una parte de gran

importancia en la aplicación. La identificación de usuarios se puede ver en la

siguiente ilustración 7.2:



Ilustración 7.2 Página de identificación de usuarios

Al modelo de los usuarios le he incorporado las validaciones para el registro

de usuarios que he considerado básicas para la aplicación: nombre, correo

electrónico y contraseña son los campos básicos, siendo único el correo electrónico

para no tener más de un usuario con el mismo. El correo electrónico tiene también

una comprobación con una expresión regular para asegurarse de que lo que

introduce el usuario al registrarse es un correo electrónico de la forma

“[email protected]” donde usuario y host puede ser cualquier cadena de texto. Se

puede ver un registro de usuario en la ilustración 7.3, accesible a través del enlace

que se muestra en la página de identificación (o log in) de usuario, visible en la

ilustración 7.2.



Ilustración 7.3 Página de registro de nuevo usuario

Para el almacenamiento de la contraseña de usuario, Rails dispone de una

gema llamada bcrypt que crea una “huella digital”, hash, única para la contraseña y

es lo que se almacena en la base de datos. El uso de esta gema queda presente en

la función digest de un usuario, que devuelve el hash de la cadena que se le pase y

se usa tanto para guardar la contraseña como para comprobar si la contraseña

introducida es correcta.

La creación de usuarios dispone de un paso de activación de la cuenta por

correo electrónico, donde al crear un usuario se genera una cadena aleatoria en

base64 que se almacena temporalmente en la base de datos y se envía al usuario

en un enlace, mediante la función send_activation_email de usuario, para que active

la cuenta desde el mismo. Esta función hace uso de UserMailer, que es la clase

encargada de enviar los correos electrónicos para un usuario. Cuenta con sus

propias vistas para personalizar completamente los correos electrónicos. Cuando el

usuario ha realizado el registro, se le envía un correo electrónico como el de la

ilustración 7.4, donde se puede observar el enlace para activar la cuenta.



Ilustración 7.4 Correo electrónico de activación de cuenta

Esta activación se gestiona mediante el controlador

AccountActivationsController para la activación de usuarios que lo que hace es

utilizar la función de activación activate que posee el usuario , función que

sencillamente pone el valor true al estado activado del usuario, junto con la fecha en

que ha sido activado.

La generación de una cadena aleatoria se realiza en la función new_token de

usuario, que devuelve la cadena generada y que además de usarse en la activación,

se va a usar para el reinicio de la contraseña en caso de olvidarla y para mantener a

un usuario conectado de forma duradera mediante las cookies del navegador.

Hay que recordar que Rails obliga a utilizar los parámetros fuertes para indicar

qué parámetros son permitidos y cuáles son requeridos, al crear o actualizar los

datos de un modelo.

En caso de olvidar la contraseña, la aplicación dispone de un método para

establecer una nueva contraseña que usa su propio controlador,

PasswordResetsController. Primero comprueba que existe el usuario en la base de

datos, entonces utiliza la función create_reset_digest de usuario para crea una

cadena en base64 y la almacena junto a su fecha de creación. Esta fecha de

creación es necesaria para establecer el límite de la duración que va a tener esa

cadena. Se envía el enlace al correo electrónico del usuario que conduce al

controlador de reinicio de contraseña (mediante la función edit). Antes de realizar

cualquier acción del controlador, se realiza la comprobación de la caducidad de la



cadena mediante un método establecido en el modelo del usuario, y da acceso a la

vista de reinicio de contraseña.

A la página de introducción de correo electrónico para el reinicio de la

contraseña se accede mediante el enlace “he olvidado la contraseña” en la página

de identificación, visible en la ilustración 7.2. Una vez en la página, ilustración 7.5, se

mostrará el campo para introducir la dirección de correo electrónico, ya existente,

para enviar el correo de reinicio de contraseña, ilustración 7.6.

Ilustración 7.5 Página de reinicio de contraseña

Ilustración 7.6 Correo electrónico de reinicio de contraseña

Para mantener la sesión de un usuario iniciada en la aplicación se utiliza un

controlador específico para la sesiones. Este guarda de manera local, para la

aplicación, el identificador del usuario cuando inicia sesión, pudiendo controlar en



cualquier momento si hay algún usuario identificado o no. Esta variable permanece

activa en los datos temporales del navegador, por lo que mientras no se cierre o se

finalice la sesión, seguirá abierta. También está la opción de mantener identificado al

usuario que hace uso de las cookies del navegador. Mediante esta opción, se

genera una cadena (siempre en base64) que se almacena en el usuario y en las

cookies creadas, junto con el identificador del usuario encriptado. De este modo

cuando se encuentre una cookie que contenga un identificador, se busca el usuario

en la base de datos y se verifica con la cadena que se generó. Cada vez que un

usuario finaliza sesión e inicia una nueva, la cadena que se crea para las cookies se

renueva.

La opción para habilitar mantener la sesión iniciada puede verse en la

ilustración 7.2, como un checkbox con el texto “Este es un ordenador privado

(mantener log in)”.

7.2.2. Experimentos

La otra parte básica de la aplicación la proporcionan los experimentos. El

modelo para los experimentos incluye las validaciones básicas para asegurarme de

que una descripción y un archivo se adjuntan a cada experimento. Cuenta también

con un método para enviar un correo electrónico al finalizar un experimento. El

estado inicial de una consulta siempre es “en espera”.

La creación de experimentos está dividida en dos partes: la primera de

selección de algoritmo e introducción de la descripción, y la segunda de

confirmación del experimento con la subida de fichero y la opción de modificar los

parámetros. Los parámetros incluidos en la aplicación son los que están

considerados como parámetros por defecto para el algoritmo en cuestión, siendo

además únicos para cada algoritmo, por lo que según el algoritmo elegido los

parámetros cambian. Este cambio se hace visible mediante la renderización de unos

campos de datos u otros siempre teniendo en cuenta el algoritmo.

Como comenté anteriormente, también la creación y confirmación de

experimentos hacen uso de los parámetros fuertes para permitir y requerir los

parámetros en cada paso. Pueden verse ambos pasos en las ilustraciones 7.7 y 7.8

respectivamente.



Ilustración 7.7 Página de creación de experimento

Ilustración 7.8 Página de confirmación de experimento

La subida del archivo se realiza mediante la gema carrierwave, que añade

una nueva categoría de archivos, llamada uploaders, donde se crea la clase

encargada de la subida del archivo. Esta clase crea una carpeta en el servidor

donde almacenará los diferentes archivos que suban los usuarios.

Los tipos de archivos que acepta la aplicación son archivos con terminación

“.arff” y “.dat”, ambos correspondientes a los formatos de Weka (Witten, Frank, &

Hall, 2011) y Keel (Alcalá-Fdez, y otros, 2009).



Al crearse correctamente un experimento, se añade a la lista de espera para

ser ejecutado siendo ya visible para el usuario en la lista de experimentos, ilustración

7.9. Esto es, el usuario puede ver en cualquier momento los datos del experimento

incluyendo el estado del mismo, pero hasta que no haya finalizado la ejecución no

se mostrará ningún resultado, como se ve en la ilustración 7.10.

Ilustración 7.9 Página con el listado de experimentos realizados

Ilustración 7.10 Página de visualización de los datos de un experimento

La ejecución del algoritmo en segundo plano se lleva a cabo en el lado del

servidor mediante un trabajador Resque. La clase Algorithms con la función



encargada de ejecutarse en segundo plano contiene también las funciones para

cada algoritmo y recibe el identificador del experimento y las opciones del mismo.

Cada algoritmo se ejecuta siguiendo las pautas de Keel: primero crea un

archivo de configuración con todos los parámetros del algoritmo y segundo realiza la

ejecución del algoritmo en base al archivo de configuración. Tanto el archivo de

configuración como los resultados se guardan junto al fichero con los datos, de

manera que pueden consultarse posteriormente para mostrarlos al usuario.

La clase de los algoritmos también hace uso de la clase de los discretizadores,

aplicando si es conveniente el discretizador al algoritmo. Esta clase funciona de

forma similar a la de algoritmos, teniendo las funciones para los discretizadores

disponibles, creando un nuevo archivo con los datos discretizados junto a los datos

originales.

Al finalizar la ejecución de un algoritmo, la aplicación envía un correo

electrónico a modo de aviso, junto con el enlace para acceder a los resultados del

mismo como se ve en la ilustración 7.11.

Ilustración 7.11 Correo electrónico de finalización de experimento

Cuando se accede al experimento finalizado, se puede ver, además de todos

los datos y parámetros usados para la ejecución, los resultados obtenidos por el

mismo algoritmo, y si se ha usado un discretizador también se muestra la conversión

de los atributos realizada por el mismo, todo esto se puede ver en la ilustración 7.12.



Ilustración 7.12 Página de visualización de experimento finalizado

Al mostrar el listado de experimentos realizados, simplemente accedo a la

base de datos extrayendo los datos de aquellos experimentos realizados por el

usuario y los muestro en una tabla.

Cuando se muestran los datos de un experimento, internamente accedo a los

diferentes archivos que se han creado durante la ejecución y los muestro, teniendo

en cuenta que cada algoritmo produce un archivo de resultado de forma única, por lo

que se renderiza de una manera u otra. Pensando en el caso en que se agreguen

algoritmos, si no se ha añadido la renderización concreta del algoritmo va a mostrar

de manera estándar el contenido de los diferentes archivos de resultado.



Bibliografía Alcalá-Fdez, J., Fernandez, A., Luengo, J., Derrac, J., García, S., Sánchez, L., y otros.

(2011). KEEL Data-Mining Software Tool: Data Set Repository, Integration of

Algorithms and Experimental Analysis Framework. Journal of Multiple-Valued Logic

and Soft Computing 17:2-3 , 255-287.

Alcalá-Fdez, J., Sánchez, L., García, S., Jesus, M. d., Ventura, S., Garrell, J., y otros. (2009).

KEEL: A Software Tool to Assess Evolutionary Algorithms to Data Mining Problems.

Soft Computing 13:3, 307-318.

Atzmueller, M., & Lemmerich, F. (2012). VIKAMINE - Open-Source Subgroup Discovery,

Pattern Mining, and Analytics. European Conference on Machine Learning and

Principles and Practice of Knowledge Discovery in Databases. Springer, Heidelberg.

Atzmueller, M., & Puppe, F. (2006). SD-Map - a fast algorithm for exhaustive subgroup

discovery. 10th European Conference on Principles and Practice of Knowledge

Discovery in Databases vol 4213 (págs. 6-17). Berlin, Germany: Springer.

Chmielewski, M. R., & Grzymala-Busse, J. W. (1996). Global discretization of continuous

attributes as preprocessing for Machine Learning. International Journal of

Approximate Reasoning 15, 319-331.

del Jesús, M. J., González, P., & Herrera, F. (2007). Multiobjective Genetic Algorithm for

Extracting Subgroup. IEEE Symposium on Computational Intelligence in Multicriteria

Decision Making (págs. 50-57). Honolulu, HI: IEEE.

del Jesus, M., González, P., Herrera, F., & Mesonero, M. (2007). Evolutionary Fuzzy Rule

Induction Process for Subgroup Discovery: A Case Study in Marketing. IEEE

Transactions on Fuzzy Systems 15(4), 578-592.

Dougherty, J., Kohavi, R., & Sahami, M. (1995). Supervised and unsupervised discretization

of continuous features. Machine learning: proceedings of the twelfth international

conference (págs. 194-202). Los Altos, California: Morgan Kaufmann.

Fayyad, U. M., & Irani, K. B. (1993). Multi-Interval Discretization of Continuous-Valued

Attributes for Classification Learning. 13th International Joint Conference on

Uncertainly in Artificial Intelligence (IJCAI93) (págs. 1022-1027). France: Morgan

Kaufmann.

Fayyad, U., Piatetsky-Shapiro, G., & Smyth, P. (1996). From Data Mining to Knowledge

Discovery in Databases. AI Magazine, 37-54.

Gamberger, D., & Lavrac, N. (2002). Expert-guided subgroup discovery: methodology and

application. Journal of Artificial Intelligence Research Volume 17 Issue 1, 501-527.

Hall, M., Frank, E., Holmes, G., Pfahringer, B., Reutemann, P., & Witten, I. H. (2009). The

WEKA Data Mining Software: An Update. SIGKDD Explorations.

Hernández, J., Ramírez, M. J., & Ferri, C. (2004). Introducción a la minería de datos.

Editorial Alhambra S. A. (SP).



Herrera, F., Carmona, C. J., González, P., & del Jesus, M. (2010). An overview on subgroup

discovery: foundations and applications. Knowledge and Information Systems, 495-

525.

Kavšek, B., Lavrač, N., & Jovanoski, V. (2003). APRIORI-SD: Adapting Association Rule

Learning to Subgroup Discovery. 5th International Symposium on Intelligent Data

Analysis (págs. 230-241). Berlin, Germany: Springer.

Klösgen, W. (1996). Explora: A Multipattern and Multistrategy Discovery Assistant. En U. e.

Fayyad (Ed.), Advances in knowledge discovery and data mining (págs. 249-271).

California: American Association for Artificial Intelligence Menlo Park.

Kralj-Novak, P., Lavrac, N., & Webb, G. I. (2009). Supervised descriptive rule discovery: a

unifying survey of contrast set, emerging pattern and subgroup mining. Journal of

Machine Learning Research 10, 377-403.

Lavrac, N., Flach, P., Kavsek, B., & Todorovski, L. (2002). Rule induction for subgroup

discovery with CN2-SD. Proceedings of the 2nd international workshop on integration

and collaboration aspects of data mining, decision support and meta-learning (págs.

77-87). University of Helsinki.

Lavrac, N., Kavsek, B., Flach, P., & Todorovski, L. (2004). Subgroup Discovery with CN2-

SD. Journal of Machine Learning Research 5, 153-188.

Lichman, M. (2013). UCI Machine Learning Repository. Obtenido de

http://archive.ics.uci.edu/ml

Pyle, D. (1999). Data preparation for data mining. San Francisco, CA, USA: Morgan

Kaufmann Publishers Inc.

RStudio. (2014). Shiny. Recuperado el 3 de febrero de 2016, de A web application

framework for R: http://shiny.rstudio.com/

Siebes, A. (1995). Data Surveying: Foundations of an Inductive Query Language.

Proceedings of the 1st International Conference on Knowledge Discovery and Data

Mining (pp. 269-274). Quebec, Canada: AAAI Press.

Tate, B. A., & Hibbs, C. (2007). Ruby on Rails. Madrid: Ediciones Anaya Multimedia.

Vanderbilt University. (2013). Web Application Development with R and Apache.

Recuperado el 3 de febrero de 2016, de http://rapache.net/

Venables, W. N., & Smith, D. M. (2009). An Introudction to R. Network Theory Ltd.

Witten, I., Frank, E., & Hall, M. (2011). Data Mining: Practical Machine Learning Tools and

Techniques. Morgan Kaufmann Publishers .

Wrobel, S. (1997). An Algorithm for Multi-relational Discovery of Subgroups. En J.

Komorowski, & J. Zytkow, Principles Of Data Mining And Knowledge Discovery

(págs. 78-87). Springer Berlin Heidelberg.

aplicaciÓn web para la extracciÓn de reglas...

Documents