Full text
Desarrollo de una aplicación en Android para la estimación automática de carbohidratos mediante un análisis de imágenes y técnicas de Inteligencia Artificial. Laura Casas Torres Milagros del Rocío Peña Quineche José Antonio Bernal Pérez GRADO EN INGENIERÍA DEL SOFTWARE FACULTAD DE INFORMÁTICA DEPARTAMENTO DE ARQUITECTURA DE COMPUTADORES Y AUTOMÁTICA UNIVERSIDAD COMPLUTENSE DE MADRID TRABAJO DE FIN DE GRADO EN INGENIERÍA DEL SOFTWARE Director: José Ignacio Hidalgo Pérez Codirectora: María Guijarro Mata-García
2 Dedicatoria Dedicado a nuestras familias que siempre nos han apoyado a pesar de las dificultades.
3 Agradecimientos Agradecimientos a todos los profesores que nos han ayudado a lo largo de nuestras vidas haciendo de sus asignaturas algo más que una mera forma de aprendizaje. Además agradecer a María e Ignacio por su dedicación y apoyo durante este trabajo.
4 Índice LISTA DE FIGURAS............................................................................................................................... 7 RESUMEN ............................................................................................................................................ 11 PALABRAS CLAVE .................................................................................................................................... 12 ABSTRACT ........................................................................................................................................... 13 KEYWORDS ........................................................................................................................................... 14 INTRODUCCIÓN .................................................................................................................................. 15 ANTECEDENTES ...................................................................................................................................... 15 Diabetes ........................................................................................................................................ 15 Análisis automático de imágenes ................................................................................................... 17 Inteligencia artificial ...................................................................................................................... 19 OBJETIVOS Y PLAN DE TRABAJO.................................................................................................................. 20 MOTIVACIÓN ........................................................................................................................................ 21 FUNDAMENTOS TEÓRICOS .............................................................................................................. 22 SISTEMA OPERATIVO .............................................................................................................................. 22 DATA-SET Y BASE DE DATOS ..................................................................................................................... 23 SQLite ............................................................................................................................................ 26 Cloud SQL ...................................................................................................................................... 27 MySQL y MariaDB.......................................................................................................................... 27 CLASIFICACIÓN Y SEGMENTACIÓN ............................................................................................................... 28 ALGORITMOS DE SEGMENTACIÓN ............................................................................................................... 29 Algoritmo iterativo ........................................................................................................................ 29 Algoritmo clásico ........................................................................................................................... 30 Algoritmo KMeans ......................................................................................................................... 31 ALGORITMOS DE CLASIFICACIÓN ................................................................................................................ 34 Bayes ............................................................................................................................................ 34
5 K-Nearest Neighbors (KNN) ............................................................................................................ 35 IMPLEMENTACIÓN ............................................................................................................................ 37 CLIENTE ............................................................................................................................................... 38 Java............................................................................................................................................... 38 Android Manifest ........................................................................................................................... 45 Gradle ........................................................................................................................................... 46 Activities, Intents y Layouts ............................................................................................................ 48 Generación de la Base de Conocimientos ....................................................................................... 51 K – Nearest Neighbor ..................................................................................................................... 56 API de USDA .................................................................................................................................. 61 API de traducción de Google .......................................................................................................... 63 Concurrencia, paralelismo e hilos ................................................................................................... 64 Funcionalidades destacadas .......................................................................................................... 66 SERVIDOR ............................................................................................................................................. 88 Apache .......................................................................................................................................... 88 SEGURIDAD......................................................................................................................................... 90 MANTENIMIENTO .............................................................................................................................. 94 ANÁLISIS DE INGENIERÍA DEL SOFTWARE ................................................................................... 96 RIESGOS ............................................................................................................................................... 96 COSTES Y NEGOCIO ................................................................................................................................. 98 CALIDAD Y RENDIMIENTO ......................................................................................................................... 99 MANUAL DE USUARIO ..................................................................................................................... 102 INICIO DE SESIÓN .................................................................................................................................. 102 OPCIONES DE IMÁGENES ........................................................................................................................ 105 MENÚ SECUNDARIO .............................................................................................................................. 109 MENÚ DE USUARIO ............................................................................................................................... 112 RESULTADOS ..................................................................................................................................... 116 CONTRIBUCIONES ............................................................................................................................ 119
6 CONCLUSIONES ................................................................................................................................. 127 CONCLUSIONS ................................................................................................................................... 130 LISTA DE REFERENCIAS .................................................................................................................. 133
7 Lista de figuras FIGURA 1. ETAPAS DEL ANÁLISIS AUTOMÁTICO DE UNA IMAGEN. ........................................ 17 FIGURA 2. VENTA DE TERMINALES EN JUNIO DE 2018 ............................................................... 22 FIGURA 3. SISTEMA OPERATIVO MÁS UTILIZADO A NIVEL MUNDIAL. ................................... 22 FIGURA 4. ESQUEMA GENERAL FUNCIONAMIENTO APLICACIÓN. ........................................... 24 FIGURA 5. ESQUEMA DE FUNCIONAMIENTO SEGMENTACIÓN Y CLASIFICACIÓN. ............... 28 FIGURA 6. REPRESENTACIÓN DEL FUNCIONAMIENTO DE UN ALGORITMO DE AGRUPACIÓN. REFERENCIADO EN MARAVALL, D. (1993) .......................................................... 32 FIGURA 7. ESQUEMA DE FUNCIONAMIENTO DE LA ARQUITECTURA CLIENTE-SERVIDOR. 38 FIGURA 8. ESQUEMA DE FUNCIONAMIENTO DE LA ARQUITECTURA MVC ............................ 39 FIGURA 9. DIAGRAMA DE CLASES SIMPLIFICADO DE LA CAPA DE PRESENTACIÓN. ........... 41 FIGURA 10. DIAGRAMA DE CLASES SIMPLIFICADO DE LA CAPA DE NEGOCIO. .................... 43 FIGURA 11. DIAGRAMA DE CLASES SIMPLIFICADO DE LA CAPA DE INTEGRACIÓN. ............ 44 FIGURA 12. EXTRACTO DEL ARCHIVO ANDROIDMANIFEST.XML ............................................ 45 FIGURA 13. PLUGIN DEL ARCHIVO BUILD.GRADLE..................................................................... 46 FIGURA 14. ANDROID DEL ARCHIVO BUILD.GRADLE ................................................................. 47 FIGURA 15. DEPENDENCIES DEL ARCHIVO BUILD.GRADLE ...................................................... 47 FIGURA 16. IMÁGENES DE GOOGLE DRIVE ................................................................................... 52 FIGURA 17. ALIMENTO PARA BASE DE CONOCIMIENTOS .......................................................... 53 FIGURA 18. COMPARACIÓN DE KMEANS DE JAVA CON MATLAB ............................................ 53 FIGURA 19. BASE DE CONOCIMIENTOS PARA KNN...................................................................... 54 FIGURA 20. BASE DE CONOCIMIENTOS PARA KNN...................................................................... 55 FIGURA 21. CROPACTIVITY, RECORTAR ALIMENTO DE UNA IMAGEN .................................... 56 FIGURA 22. CÓDIGO DE LA CLASE KNNCLASSIFIER .................................................................... 57
8 FIGURA 23. CÓDIGO DE LA CLASE KNNQUEUE ............................................................................ 58 FIGURA 24. CÓDIGO DE LA CLASE KNNQUEUEELEMENT .......................................................... 59 FIGURA 25. MÉTODO DE CÁLCULO DE PESOS .............................................................................. 59 FIGURA 26. MÉTODO DE VOTOS DE LA CLASE BOXVOTE .......................................................... 60 FIGURA 27. CÓDIGO DE LA CLASE PREDICTION ........................................................................... 61 FIGURA 28. ESQUEMA DE EJECUCIÓN DE LA CLASE ASYNCTASK [30] .................................... 64 FIGURA 29. USO DE ASYNCTASK EN LA APLICACIÓN ................................................................. 65 FIGURA 30. CASOS DE USO EL USUARIO ........................................................................................ 66 FIGURA 31. DIAGRAMA DE ACTIVIDAD DE CALCULAR BOLO PRANDIAL .............................. 71 FIGURA 32. DIAGRAMA DE ACTIVIDAD DE CALCULAR BOLO CORRECTOR ........................... 72 FIGURA 33. DIAGRAMA DE SECUENCIA DE AÑADIR INSULINA ................................................ 73 FIGURA 34. DIAGRAMA DE FLUJO DE AÑADIR PLATO EN USUARIOS DIABÉTICOS .............. 74 FIGURA 35. DIAGRAMA DE SECUENCIA DE AÑADIR PLATO A SUS COMIDAS ........................ 75 FIGURA 36. CASOS DE USO PARA LA IMAGEN .............................................................................. 76 FIGURA 37. DIAGRAMA DE FLUJO DE PROCESAR IMAGEN ........................................................ 77 FIGURA 38. DIAGRAMA DE ACTIVIDAD DE SEGMENTAR Y CLASIFICAR IMAGEN ................ 78 FIGURA 39. DIAGRAMA DE SECUENCIA DE SEGMENTAR IMAGEN........................................... 79 FIGURA 40. DIAGRAMA DE SECUENCIA DE PROCESAR IMAGEN DE USUARIO ...................... 80 FIGURA 41. DIAGRAMA DE CASOS DE USO PARA LA COMIDA .................................................. 81 FIGURA 42. DIAGRAMA DE FLUJO PARA REPORTE DE ALIMENTOS ......................................... 82 FIGURA 43. DIAGRAMA DE ACTIVIDAD PARA REPORTE DE ALIMENTOS ............................... 83 FIGURA 44. DIAGRAMA DE SECUENCIA PARA REPORTE DE ALIMENTOS ............................... 84 FIGURA 45. DIAGRAMA DE FLUJO PARA AÑADIR COMIDA NUEVA A LA BD ......................... 85 FIGURA 46. DIAGRAMA DE ACTIVIDAD PARA AÑADIR COMIDA NUEVA A LA BD ................ 86 FIGURA 47. DIAGRAMA DE SECUENCIA PARA AÑADIR COMIDA NUEVA A LA BD................ 87
9 FIGURA 48. SCRIPTS PHP DEL SERVIDOR ....................................................................................... 89 FIGURA 49. ESQUEMA ENTIDAD-RELACIÓN DE LA BD ............................................................... 89 FIGURA 50. MÉTODOS DE ENCRIPTACIÓN Y DESENCRIPTACIÓN ............................................. 91 FIGURA 51. FUNCIONAMIENTO DEL ESTÁNDAR AES PARA ENCRIPTADO DE TEXTO........... 92 FIGURA 52. FUNCIONAMIENTO DEL SCRIPT DE BACKUP EN CASO DE ERROR ...................... 94 FIGURA 53. BACKUP CORRECTO ..................................................................................................... 94 FIGURA 54. TABLA DE PRIORIZACIÓN DEL RIESGO..................................................................... 97 FIGURA 55. GRÁFICA DE MONITORIZACIÓN AL INICIAR LA APLICACIÓN ............................. 100 FIGURA 56. GRÁFICA DE MONITORIZACIÓN DURANTE EL PROCESAMIENTO DE LA IMAGEN. ............................................................................................................................................. 101 FIGURA 57. GRÁFICA DE MONITORIZACIÓN DURANTE EL REPORTE NUTRICIONAL DE LOS ALIMENTOS........................................................................................................................................ 101 FIGURA 58. VISTA DE ACCESO A LA APLICACIÓN ...................................................................... 102 FIGURA 59. VISTA DE MENÚ PRINCIPAL ....................................................................................... 103 FIGURA 60. VISTA DE GALERÍA ...................................................................................................... 103 FIGURA 61. VISTA DE CÁMARA ...................................................................................................... 104 FIGURA 62. VISTA DE MENÚ DE USUARIO SANO ........................................................................ 104 FIGURA 63. VISTA DE MENÚ DE USUARIO DIABÉTICO .............................................................. 105 FIGURA 64. VISTA PARA PROCESAR IMAGEN .............................................................................. 106 FIGURA 65. VISTA CON LISTA DE POSIBLE/S COMIDAS EN LA IMAGEN ................................. 106 FIGURA 66. MENÚ SECUNDARIO .................................................................................................... 107 FIGURA 67. VISTA PARA RECORTAR IMAGEN ............................................................................. 107 FIGURA 68. VISTA PARA AÑADIR NOMBRE A LA NUEVA COMIDA.......................................... 108 FIGURA 69. VISTA PARA AÑADIR NUEVA COMIDA CON NOMBRE E INGREDIENTES ........... 108 FIGURA 70. VISTA PARA AÑADIR INGREDIENTES DE LA NUEVA COMIDA ............................ 109
16 hormona. Normalmente el páncreas de las personas que padecen este tipo de diabetes tiende a disminuir la producción de insulina paulatinamente. El 80% de las personas que desarrollan diabetes tipo 2 tienen obesidad y un estilo de vida muy sedentario. El 20% restante suelen tener un defecto hereditario que causa resistencia a la insulina. - Diabetes gestacional: durante el embarazo se produce una intolerancia total a la glucosa que puede ser debida a múltiples causas. Este tipo de diabetes aparece en una de cada diez mujeres embarazadas. - Otros tipos de diabetes: diabetes MODY (Maturity Onset Diabetes in the Young) que se produce por defectos de las células beta o Diabetes DRFQ (Diabetes Relacionada con Fibrosis Quística) que se produce por el impacto de la Fibrosis Quística en el páncreas. En España los datos sobre la diabetes no son nada alentadores. Un estudio epidemiológico realizado por la Sociedad Europea de Diabetes muestra que el 13,8% de los españoles mayores de 18 años tiene diabetes tipo 2, lo que equivale a más de 5,3 millones de personas. De estos, el 43% desconocía que padecía la enfermedad. El retraso en descubrir que se padece diabetes implica que cuando se diagnostica la mitad de los casos ya presentan alguna complicación. Además, el estudio ha revelado más datos importantes relacionados con situaciones que se relacionan estrechamente con la diabetes. El 28,2% de la población es obesa y el 12,6% es intolerante a la glucosa. [3]
17 Análisis automático de imágenes La visión por computador [4] trata de dotar a las máquinas del sentido de la vista con el objetivo de extraer información de las imágenes y poder utilizarla en distintas prácticas. Suele girar en torno al reconocimiento de formas, aunque hay muchas más características que se pueden utilizar de una imagen como, por ejemplo, el color. Cada píxel que conforma una imagen digital contiene un vector de tres valores que contiene el nivel de rojo, azul y verde, respectivamente. Figura 1. Etapas del análisis automático de una imagen. Para poder conseguir información útil de una imagen se siguen una serie de etapas y procesamientos orientados a mejorar la calidad de la información que se va a extraer de ella, tal y como se describe en la Figura 1. La primera etapa consistirá en la toma de la imagen. En este trabajo se realizará a través de la cámara del móvil donde esté instalada la aplicación. En la etapa de pre-procesado se contemplan innumerables operaciones de preprocesamiento de imágenes que ayuden a facilitar la tarea a las etapas sucesivas. Dentro de las técnicas de pre-procesamiento de imágenes existen dos grandes áreas: Imagen Pre-procesado Segmentación Cálculo de características Clasificación
18 procesamiento con observador humano o procesamiento sin observador humano. El procesamiento sin observador humano tiene mayor interés práctico en los sistemas de visión por computador. La técnica más común sería: • Transformación del histograma: el histograma de una imagen es un gráfico que representa los niveles de gris en el eje de abscisas y el número de pixeles de cada nivel en el eje de ordenadas. Aunque en algunas ocasiones el histograma solo otorga la posibilidad de aumentar o disminuir los niveles de contraste de una imagen, en otras ocasiones es suficiente para separar objetos dentro de una imagen facilitando la etapa de interpretación. Después de la etapa de pre-procesado la imagen pasa por la etapa de segmentación. La segmentación de una imagen separa las distintas zonas de interés de estudio, convirtiéndose así en una etapa decisiva por la importancia de los resultados que proporciona. Esta etapa difiere dependiendo del objetivo que se persiga con la interpretación de la imagen. En general se separan en zonas o en objetos individuales. Existen distintos tipos de técnicas de segmentación: • Agrupación por rasgos comunes: segmenta las imágenes mediante algoritmos de agrupación de datos. Esta técnica segmenta las imágenes de forma automática y no supervisada sin exigir un conocimiento previo de las clases de objetos existentes. • Extracción de bordes: separa los objetos a partir de sus bordes. Esta técnica se inspira en un principio muy intuitivo y simple puesto que los pixeles situados en los bordes de los distintos objetos presentan grandes variaciones en sus características con respecto a los pixeles vecinos. Por ejemplo, un objeto oscuro situado en un fondo claro.
19 Una vez la imagen ha sido segmentada se pasa a la fase de extracción de rasgos. Independientemente de la forma elegida de segmentación, los rasgos obtenidos han de ser suficientes para poder distinguir los distintos objetos. Las distintas características extraídas de cada objeto forman un vector que se usará en la etapa de clasificación. Antes de pasar a la clasificación de los objetos es imprescindible haberlos catalogado previamente. Es decir, un sistema de visión artificial basa su conocimiento en una batería de datos cargados con anterioridad por un equipo de especialistas. La complejidad de la batería de datos depende del objetivo de la aplicación pudiendo ser muy sencilla o compleja. [5] Inteligencia artificial La inteligencia artificial [6] es aquella dirigida a las máquinas con el objetivo de “imitar las funciones «cognitivas» que los humanos asocian con otras mentes humanas, como por ejemplo aprender y resolver problemas”. Este concepto es conocido desde 1956, año en el que se determinaba si una máquina era capaz de imitar la inteligencia humana con el test de Alan Turing y los axiomas de la Ley de Moore. [6] Hasta la actualidad, el desarrollo y la investigación de la Inteligencia Artificial ha tenido un crecimiento exponencial que gracias a los proyectos de innovación sigue aumentando. Por esto, en los últimos años ha crecido un nuevo concepto derivado de la IA, que es el Machine Learning [6], cuyo objetivo es construir programas que mejoren
20 automáticamente mediante la experiencia. Gracias a esta rama ha evolucionado el aprendizaje automático de las máquinas y con él, el concepto principal que estamos tratando en este TFG, que es la Visión por Computador o Visión Artificial. Del mismo modo que la IA pretende emular la inteligencia humana dotando a las máquinas de la capacidad de manipular datos sensoriales similares a los empleados por los seres vivos, la Visión Artificial sirve a este propósito con el objetivo último de generar información a partir de datos visuales mediante el estudio de los procesos de reconocimiento y localización de objetos por medio del procesamiento de imágenes. [7] Objetivos y plan de trabajo El objetivo es la construcción de una aplicación para dispositivos móviles con sistema operativo Android que sea capaz de estimar de forma automática, con un nivel de error bajo, los distintos alimentos que se le muestran a través de una imagen digital, extrayendo características de color de cada uno de los pixeles y usando éstas para segmentar y clasificar los alimentos. Además, la aplicación debe proporcionar y guardar información nutricional sobre cada alimento detectado.
21 Motivación Varios han sido los motivos que nos han impulsado en el desarrollo de este proyecto. El primero de todos ha sido el interés y motivación que nos proporcionaba trabajar en una aplicación que usa técnicas de inteligencia artificial con el objetivo de identificar objetos. El campo de la inteligencia artificial, que se encuentra lejos de ofrecer todas las ventajas que es capaz de proporcionar, supone un reto y un área de investigación fascinante donde poder aplicar muchos de los conocimientos que hemos adquirido a lo largo de nuestra carrera, el Grado en Ingeniería de Software, e incluso más que hemos adquirido a raíz de nuestro trabajo en este proyecto. Además, para nosotros poder desarrollar esta aplicación en una plataforma como Android suponía un doble reto al vernos enfrentados a nuevas complicaciones y desafíos que no hemos tenido tan presentes a lo largo de nuestros estudios. Por último, desarrollar una aplicación que supone una pequeña aportación al mundo de la salud y que, por lo tanto, podría suponer una mejora de la calidad de vida de un sector de la población nos ha motivado enormemente para perfeccionar aún más todo el trabajo que se ha realizado durante el proyecto.
22 Fundamentos teóricos Sistema Operativo Uno de los principales objetivos de este proyecto es mejorar la calidad de vida de la mayor cantidad de personas posible. Para conseguir esa meta realizamos una investigación sobre los terminales más vendidos en el año 2018 y el sistema operativo más utilizado, ambos a nivel mundial. Figura 2. Venta de terminales en junio de 2018 [8] Figura 3. Sistema Operativo más utilizado a nivel mundial. [9]
23 Como se puede apreciar en la Figuras 2 las tres marcas más vendidas en el mundo en junio de 2018 eran Samsung con el 30.66%, Apple con el 18.94% y Xiaomi con el 7.01%, de las cuales la primera y la tercera usan el sistema operativo Android. Además, en la Figura 3 existe un predominio de dicho sistema como el más usado también a nivel mundial. Esto, añadido a la falta de recursos del equipo que imposibilitaba realizar una correcta fase de pruebas en un dispositivo con sistema operativo iOS y a la mayor experiencia en este terreno, debido a los conocimientos sobre Android adquiridos a lo largo de la carrera, nos hizo decantarnos por realizar el proyecto en esta plataforma. Data-set y Base de datos La implementación de la aplicación consta de dos partes a desarrollar. La primera parte es off-line y se encargará de generar un data-set, o base de conocimientos, para que el algoritmo encargado de la clasificación de los alimentos pueda obtener conocimientos y aprender. Por otro lado, se tendrá una parte on-line en la que al tomar la decisión e identificar el alimento, deberá registrar esa información en una base de datos.
24 Figura 4. Esquema general funcionamiento aplicación. Como se muestra en la Figura 4 la aplicación divide su comportamiento en dos partes principales. La parte off-line tiene como objetivo crear un data-set o conjunto de datos lo más extenso posible para el correcto funcionamiento de la parte on-line. Se tomó una batería de imágenes que fueron segmentadas automáticamente mediante el algoritmo KMeans [15] y etiquetadas manualmente por el equipo de desarrollo. Toda esta información fue subida manualmente a la base de datos proporcionando así el conjunto de datos de aprendizaje de la aplicación. La parte on-line sigue un flujo lineal dividido en cuatro tareas principales: Captura de información: es la primera etapa contenida en la parte on-line de la aplicación. En este caso, la captura de información es la toma en tiempo real de una fotografía por parte del usuario, o la elección de una que haya sido tomada previamente, del plato de comida que vaya a ingerir. Extracción de la información: una vez el usuario ha proporcionado una imagen pasamos a la etapa de extracción de la información. En esta etapa segmentaremos por color los distintos componentes, en este caso alimentos, que forman el plato.
25 Como resultado de la segmentación obtenemos los pixeles pertenecientes a cada alimento con los que calcularemos su tamaño y su media RGB. Codificación de la información: tras conseguir la información de cada alimento lo etiquetaremos mediante un algoritmo de clasificación. El algoritmo de clasificación Knn [20] hace uso de un data-set creado previamente en la parte offline. Gracias a este conjunto de datos somos capaces mediante el cálculo de distancias euclídeas de predecir la categoría más posible a la que puede pertenecer el alimento. Después se muestra al usuario una lista de múltiple opción de las categorías más probables a las que pueden pertenecer donde podrá seleccionar la etiqueta final a la que se asignará cada uno, o crear una nueva en caso de que no existiese. Identificación de la decisión: los distintos alimentos ya han sido etiquetados correctamente, dicha información será subida a la base de datos para aumentar el data-set con el objetivo de que la aplicación continúe siempre aprendiendo. Además, se realizará una consulta a la base de datos estadounidense USDA [42], mediante la cual se consiguen los nutrientes, centrándonos sobre todo en los carbohidratos, de cada alimento. Para estas bases de datos, el equipo decidió investigar qué bases de datos tendría mejor rendimiento y compatibilidad con Android. En un principio, se contempló la opción de utilizar el módulo INTERNAL STORAGE que ofrece Android, para poder guardar la información en el propio dispositivo. La gran ventaja de este módulo es que cada usuario tiene solo información con respecto a sí mismo siendo factible al esquema relacional de la BD. Sin embargo, la aplicación terminaría abarcando demasiado espacio en memoria y afectaría al terminal.
32 Figura 6. Representación del funcionamiento de un algoritmo de agrupación. Referenciado en Maravall, D. (1993) El funcionamiento del algoritmo sería el siguiente partiendo de un conjunto de objetos a clasificar: [18] • Paso 1: selecciona aleatoriamente k puntos dentro del conjunto de objetos o data set. Estos puntos serán considerados los centros de las k clases. • Paso 2: calcula respectivamente la distancia de cada punto con cada uno de los centros. Los puntos pertenecerán al centro con menor distancia. 𝑱=∑∑||𝒙𝒏− 𝝁𝒌||𝟐 𝑲 𝒌=𝟏 𝑵 𝒏=𝟏 • Donde k es el número de centros y n el número de observaciones, siendo k ≤ n. • Siendo ( 𝑥1 ,𝑥2,…,𝑥𝑛 ) el conjunto de observaciones, en nuestro caso, siendo el conjunto de pixeles. • Donde 𝝁𝒌 es la media de puntos en el centro k. {𝑋1,𝑋2…𝑋𝑝} Algoritmo de Agrupación ∝1:{𝑋12 …𝑋1𝑟} ∝2:{𝑋21 …𝑋2𝑠} ∝𝑘:{𝑋41 …𝑋4𝑡}
33 • Paso 3: una vez se han agrupado los puntos en sus respectivos centros, es preciso recalcular los centros de las clases. El objetivo de recalcular los centros es minimizar J. En cada iteración J irá disminuyendo o al menos no sufrirá ningún cambio, pero nunca aumenta su valor, lo que garantiza que eventualmente alcanzará su mínimo. • Paso 4: de acuerdo con los nuevos centros se vuelve a calcular la distancia de cada punto con cada centro. Si la distancia con el nuevo centro es menor que la distancia con el centro anterior el punto pasa a formar parte del nuevo grupo. Este paso se repite hasta que el algoritmo sea estable, es decir, ninguno de los puntos cambia de centro. El algoritmo K-means depende en gran medida de los centros que se eligen aleatoriamente en la primera iteración. El problema principal es que si la clasificación inicial que se hace entorno a estos centros se desvía mucho de la clasificación óptima lleva a resultados erróneos. Cuanto mayor es el conjunto de datos, por ejemplo, en el caso de una imagen, mayor es la desviación hacia la clasificación óptima. Debido a esto la imagen debe procesarse en varias rondas de agrupamiento para poder lograr mejores resultados. Utilizando K-means para segmentar una misma imagen varias veces, los resultados conseguidos son diferentes al cambiar los centros de agrupación iniciales. El algoritmo suele repetirse varias veces consiguiendo así mejores resultados al haber contemplado más posibilidades. En conclusión, K-means es un algoritmo que nos permitirá segmentar las imágenes sin un conocimiento previo de las clases en las que tenía que dividir los distintos objetos ofreciéndonos así la posibilidad de automatizar la segmentación de las imágenes para poder conseguir los datos de cada uno de los alimentos automáticamente.
34 Algoritmos de clasificación Una vez las imágenes han sido segmentadas el siguiente paso es clasificar las distintas clases, en el caso de este proyecto los distintos alimentos, que forman parte de la imagen. Para esto se han investigado distintos algoritmos de clasificación que usan distintos métodos para clasificar datos. Bayes El clasificador bayesiano [19] es un clasificador probabilístico que se fundamenta en el Teorema de Bayes. Este clasificador se basa en que toma como hipótesis que cada variable predictora es independiente, es decir, ninguna variable está influida por la existencia o desaparición de otra. Debido a la independencia de las variables el algoritmo recibe el apelativo de ingenuo. El funcionamiento de este clasificador se basa en encontrar la probabilidad de que, conociendo los valores que describen a una muestra, esta pertenezca a una clase u otra. De esta manera, cada característica ayuda independientemente a la probabilidad de que pertenezca a una clase u otra. Un hecho importante y positivo de este tipo de clasificador, es que el “peso” o “probabilidad” de una variable en la clasificación puede ser muy importante en relación con la causa, pero ser además muy común en otras, con lo cual el “peso” final disminuye.
35 𝑓(𝑥𝑖,𝑤)=𝑝(𝑥𝑖 𝑚,𝐶) • Donde w = (w1, w2) es el vector de parámetros a estimar. • Siendo p(𝑥𝑖/m) la función de probabilidad condicional de la clase 𝑥𝑖 para m. • Donde C es la matriz de covarianza. El clasificador bayesiano ingenuo suele entrenarse de manera muy eficaz en un entorno de aprendizaje supervisado, es decir, estima los parámetros a partir de un conjunto de datos de entrenamiento. Este conjunto de datos no tiene por qué ser grande ya que como se asumen las variables independientes solo es necesario calcular las varianzas de las variables de cada clase. K-Nearest Neighbors (KNN) K-Nearest Neighbors o K-vecinos más cercanos [20] forma parte de la familia de algoritmos de aprendizaje basado en instancias o Instance-Based Learning. Este tipo de algoritmos no tienen un modelo global asociado a los conceptos a aprender, en su lugar las predicciones se realizan basándose en los ejemplos más parecidos a la instancia a predecir. Es decir, el aprendizaje en este tipo de algoritmos consiste simplemente en almacenar los datos de entrenamiento y cuando existe un nuevo dato se recupera de memoria un conjunto de datos similares que serán usados para clasificarlo. La ventaja de este tipo de algoritmos es que son capaces de usar una representación de los datos más compleja. Por otro lado, puede llegar a ser muy costoso clasificar nuevas instancias. Knn asume que todas las instancias o datos corresponden a puntos en un plano de n dimensiones. Los vecinos más cercanos de cada instancia son calculados mediante
36 distancias euclidianas. De esta manera la distancia entre dos instancias 𝑥𝑖 y 𝑥𝑗 se define como: 𝑑(𝑥𝑖,𝑥𝑗)= √∑(𝑥𝑖− 𝑥𝑗)2 𝑛 • Donde 𝑥𝑖 y 𝑥𝑗 son los puntos considerados para calcular la distancia euclidea. • Siendo n el número de atributos a considerar. Después de calcular la distantica con cada muestra de entrenamiento nos quedaremos con K muestras más cercanas. Esta implementación puede ser optimizada si pesamos la contribución que hace cada uno de los k vecinos más cercanos dándole, de esta forma, mayor peso al vecino más cercano. La mayoría de las variaciones del algoritmo KNN consideran sólo los k vecinos más cercanos para clasificar la nueva instancia, pero al añadirles peso a los datos del conjunto de entrenamiento el algoritmo considerará todas las muestras. Permitir que todas las muestras tengan influencia en el clasificador no supone un peligro para el algoritmo ya que las muestras más distantes apenas tendrán peso. Esta modificación hace que el algoritmo sea más robusto y efectivo cuando el conjunto de datos de entrenamiento es muy grande, además puede suavizar el impacto que tienen los datos de entrenamiento más aislados. El problema de esta modificación es que al considerar todas las muestras el algoritmo se vuelve más lento. El equipo de desarrollo decidió elegir como algoritmo de clasificación el KNearest Neighbors ya que es un algoritmo cuyo coste de aprendizaje es nulo, no necesita hacer ninguna suposición sobre los conceptos a aprender y es muy tolerante al ruido.
37 Implementación Teniendo en cuenta la investigación y las decisiones tomadas a lo largo del desarrollo, descritas en el apartado anterior, veremos a lo largo de este apartado en mayor detalle cómo es la implementación de la aplicación. Nuestra aplicación basa su funcionamiento en una arquitectura cliente-servidor, REST [43], siendo el cliente nuestro Smartphone y, el servidor, el proporcionado por la Universidad Complutense de Madrid. Esta arquitectura consiste en el envío de peticiones HTTP desde el cliente hacia el servidor y, en consecuencia, en el envío de respuestas del servidor hacia el cliente. Esta arquitectura permite tener varios clientes conectados al mismo servicio al unísono y un mantenimiento de la consistencia de la base de datos ya que, debido a estar situada en el propio servidor, es común a todos los clientes; por tanto, permite procesar la información de un modo distribuido. [20]
38 Figura 7. Esquema de funcionamiento de la arquitectura cliente-servidor. Tecnologías y SO • Debian GNU/Linux 8 (jessie) • Windows 10 10.0 • mysql Ver. 14.14 Distrib 5.6.28, for Linux (x86_64) using EditLine wrapper • Matlab R2018b Update 2(9.5.0.1033004) • Android Studio 3.4.1 • JRE: 1.8.0_152-release-1343-b01 amd64 • JVM: OpenJDK 64-Bit Server VM by JetBrains s.r.o • Eclipse IDE for Enterprise Java Developers. Version: 2018-12 (4.10.0) • Postman v7.1.1 • Sublime Text 3.2.1 • Github v2.17.0 Cliente La parte cliente del sistema corresponde a la aplicación Android en sí misma. El código fuente de ésta consta, prácticamente en su totalidad, de código Java. También contiene archivos xml para configuración y layouts, incluido el AndroidManifest. Java La arquitectura elegida para desarrollar el código en Java ha sido una arquitectura multicapa basada en el patrón Modelo-Vista-Controlador (MVC) [21]. La ventaja de este
39 tipo de arquitecturas es el aumento de la mantenibilidad, la modularidad y el desacoplamiento del software, así como proporcionar una base para el desarrollo. Figura 8. Esquema de funcionamiento de la arquitectura MVC Esta arquitectura separa y desacopla el funcionamiento de las partes de la aplicación en tres módulos: Modelo: sus componentes contienen la representación de los datos del sistema, la lógica de negocio, los mecanismos de acceso y persistencia de dichos datos. Vista: la vista tiene como objetivo principal manejar las interacciones entre la aplicación y el usuario. Las vistas contienen toda la información de valor para el usuario, por lo tanto, su principal cometido es mostrar de forma intuitiva y clara dicha información. Controlador: se encarga de manejar las comunicaciones entre el modelo y la vista; actúa como un middleware entre los dos.
40 En cuanto a la separación física de los componentes en paquetes, la estructura consiste en tres capas diferenciadas: Presentación: todo lo relacionado con los elementos gráficos que el usuario ve en la pantalla de su móvil, así como las interacciones entre dichos elementos y con el usuario de la aplicación. El funcionamiento de la interfaz gráfica en Android se basa en activities, y las interacciones se realizan mediante intents. Sobre este funcionamiento hablaremos más adelante. Esta capa contiene la interfaz gráfica y el controlador, que comunica el modelo con la vista. Dentro de esta capa encontramos varias divisiones: - Activities, componentes de la interfaz gráfica; hablaremos de ellos más adelante. - Comandos, que son usados por el controlador para llevar a cabo un comportamiento u otro. - Controlador, que recibe las peticiones del usuario y llama al dispatcher con el resultado para actualizar la vista. - Dispatcher, se encarga de actualizar la vista según el resultado del comando que ha ejecutado previamente el controlador. La comunicación entre estas divisiones se puede ver en el diagrama de clases descrito en la Figura 9.
41 Figura 9. Diagrama de clases simplificado de la capa de presentación. Negocio: esta capa se encarga de toda la lógica de negocio de la aplicación y la representación de los datos del modelo. La capa de presentación se comunica con esta capa de negocio a través del controlador, dependiendo de la acción del usuario en la interfaz gráfica, el controlador realiza una operación u otra y, con la respuesta, se comunica de nuevo con la vista para actualizarla como proceda. Dentro de esta capa encontraríamos los distintos servicios de aplicación de las distintas funcionalidades de la aplicación. El uso de servicios de aplicación nos permite centralizar la lógica del negocio y proporciona una capa de servicio uniforme. Se han implementado los siguientes servicios de aplicación: • UsersAppService: realiza todas las operaciones relacionadas con el usuario como el registro/inicio de sesión, actualización de datos del usuario como su peso y contraseña o la bajada de la lista de alimentos consumidos por el usuario, así como sus dosis de insulina registradas.
48 Activities, Intents y Layouts Hablábamos antes de las activity [24] como una parte importante del funcionamiento de la interfaz gráfica de Android. Las activities son componentes de la aplicación que contienen una representación gráfica con la que los usuarios pueden interactuar para realizar una acción concreta Dependiendo de la acción que se dispare con la interacción del usuario, puede ser que se necesite iniciar otra activity, mandar un mensaje o iniciar un servicio concreto. Para este fin se utilizan objetos intent [25], que permite comunicar y hacer peticiones desde un componente de la aplicación hacia otro. En nuestro caso, se han implementado varias activities: AddAlimentActivity: permite al usuario añadir alimentos de la base de datos internacional USDA, pidiendo un nombre y una cantidad (gramos) para poder añadir un ingrediente al alimento que pretende registrar. Una vez añadidos los ingredientes, le ofrece la opción de registrar el plato o cancelar el proceso. CameraActivity: maneja las peticiones relacionadas con la cámara: tomar fotos, ver la preview de la foto tomada y realizar la petición de procesamiento de la foto. Esta activity, a su vez, está dividida en dos fragments. Un fragment [26] es un fragmento del comportamiento y/o interfaz de usuario de una activity. En nuestro caso, dividimos la interfaz de usuario y el comportamiento en dos: CameraFragment, encargado de mostrar lo que ve la cámara en tiempo real y de tomar la foto, y UploadFragment, encargado de visualizar la foto tomada y mostrar botones para que el usuario interactúe con ella.
49 CorrectiveBolusActivity: da la opción al usuario diabético de calcular el bolo corrector, permitiéndole ingresar su dosis actual, ver y registrar la nueva dosis correctora. CropActivity: permite al usuario hacer un recorte personalizado de una comida en una imagen tomada o seleccionada previamente para posteriormente añadir ese plato a la base de datos si es que no existe. CropImageActivity: muestra al usuario el recorte que ha realizado a una imagen previamente y le permite añadir un nombre personalizado al plato que pretende subir, dándole la opción de continuar con la subida si está conforme con el recorte. FoodExplorerActivity: encargada de mostrar en una lista de selección múltiple las predicciones de los distintos alimentos encontrados en el plato. FoodSelectorActivity: encargada de mostrar en una nueva lista los alimentos seleccionados en la activity anterior mostrando su nombre, la cantidad en gramos y los carbohidratos correspondientes. Esta activity además amplía su funcionamiento mediante el fragment FoodItemFragment que usa un adaptador, FoodAdapter, para poder personalizar visualmente la lista. FoodReportActivity: se encarga de recoger y mostrar los informes de los alimentos mostrados en la activity anterior mostrando sus nutrientes indicando la cantidad aportada y la cantidad diaria recomendada.
50 FoodUserActivity: encargada de recoger y mostrar las últimas 30 comidas del usuario, mostrando un breve resumen de los componentes del plato y la información de estos componentes como los gramos, los carbohidratos y la insulina que haya decidido el usuario calcular en esa comida. InsulinHistoryActivity: muestra un resumen de las dosis de insulina del día, una media de dosis diaria de los últimos días y una gráfica que muestra la cantidad de dosis en los días anteriores. InsulinParametersActivity: permite al usuario ingresar sus datos para poder calcular el bolo prandial de la comida que haya procesado previamente. LoginActivity: maneja todas las peticiones del usuario relacionadas con el inicio de sesión o el registro de usuario. También se encarga de mostrar errores en caso de inicio de sesión incorrecto o fallo de conexión. MenuActivity: ofrece un menú al usuario que le permite añadir una comida ya procesada a sus comidas, obtener un reporte general y/o específico de los nutrientes de cada alimento o calcular la insulina de esa comida. UpdateUserActivity: gestiona la recogida, validez y modificación de los datos que el usuario quiera cambiar sobre su cuenta, es decir, si es diabético, su peso y su azúcar en sangre, hipoglucemia, glucosas objetivo, además, de la contraseña y la fecha de nacimiento, parámetro común de todos los usuarios.
51 SelectorAlimentActivity: muestra una lista de los alimentos que componen el plato que ha procesado el usuario, informando de los gramos y carbohidratos que componen cada alimento y dando la opción de seleccionar alguno para obtener un reporte nutricional más específico sobre el alimento. UserActivity: maneja las peticiones del usuario relacionadas con el cierre de sesión. La representación gráfica de una activity se define mediante un archivo layout. Los layouts son archivos con formato xml que describen una representación gráfica concreta, entendiendo por esto los componentes de una interfaz gráfica, sus identificadores, su composición y su posición dentro del marco de la interfaz. Generación de la Base de Conocimientos La base de conocimientos es aquella con la cual el algoritmo, en este caso el Knn [20], utiliza unos datos registrados en esta base para modelar y entrenar un conjunto de soluciones con las que, finalmente, se obtenga un conjunto de resultados semejantes al que se ha solicitado. Para este proceso se ha utilizado Google Drive, Matlab, Eclipse (Java) y la BD. Esta base de conocimientos ha sido generada gracias a un repositorio de imágenes, tanto de la cafetería como personales, creado en Google Drive con un peso total de 726MB.
52 Figura 16. Imágenes de Google Drive En un principio, se utilizó para la segmentación de la imagen el algoritmo KMeans de Matlab [27], con el que separábamos los alimentos del plato según los clusters generados por el algoritmo y representábamos esos alimentos en una imagen aparte generando también un documento CSV en el que se registraban las medias de rojo, verde y azul junto a los pixeles totales de cada cluster.
53 Figura 17. Alimento para base de conocimientos Como se puede apreciar en la Figura 11, para obtener las medias, este equipo ha segmentado la imagen utilizando el algoritmo KMeans de Matlab y creando una capa para cada parte, en función del número de cluster y así, posteriormente, calcular las medias RGB de cada sección y corroborar que se asemeja a las medias obtenidas por nuestro algoritmo KMeans, implementado en Java, con el fin de poder insertarlas en la base de datos. Figura 18. Comparación de KMeans de Java con Matlab Como anotación, mencionar que las medias no tienen que ser exactamente iguales sino parecidas, ya que el algoritmo de Java, ha sido implementado por el equipo realizando una segmentación parecida a la de Matlab, pero no idéntica, debido a que la de Matlab es mucho más precisa y tiene ventaja en cuanto al avance algorítmico y al procesamiento de imágenes; aun así, la diferencia entre un algoritmo y otro ha sido de unos 25 puntos de media por encima con respecto a la implementación de Matlab.
54 Figura 19. Base de conocimientos para Knn Esta aplicación no guarda las imágenes en la BD, ya que abarcaría demasiado espacio para información irrelevante, debido a que cada usuario puede tener imágenes de la misma comida con los mismos ingredientes y, por tanto, se repetiría la misma fotografía para muchas personas. Por eso, se queda con las medias RGB para la base de conocimientos y con los pixeles para saber la cantidad de comida que hay en el plato. Esto es posible ya que la foto sigue siempre el mismo “estándar”, es decir, una imagen tomada desde arriba al plato con los componentes y el menor fondo posible, como se puede observar en la Figura 20. Si la imagen que recibe la aplicación se ha hecho desde esta perspectiva, da igual la cámara del dispositivo o la escala a la que se haya producido la fotografía que siempre se realizará un resize a nivel de sistema, para que la variación del número de pixeles sea mínima y poder concretar mejor la cantidad de gramos que existe de cada alimento, asignando los gramos en función de los pixeles recogidos y los pixeles de los que consta ese alimento en la BD.
55 Figura 20. Base de conocimientos para Knn Finalmente, cabe destacar que para que el usuario pueda añadir alimentos a la base de conocimientos que puedan compartir plato con otros que sí que están añadidos, facilitamos una vista para que se saltara el paso de segmentación y pudiera recortar la sección de manera personalizada y facilitar la obtención de medias sin mezclar información con otros elementos de la imagen.
56 Figura 21. CropActivity, recortar alimento de una imagen K – Nearest Neighbor La correcta generación de la base de conocimiento es indispensable para un funcionamiento adecuado del clasificador. La implementación de este es extensa y hace uso de distintas clases que serán explicadas detalladamente a continuación.
57 La clase principal KnnClassifier es la encargada de llevar a cabo la clasificación, cuenta con varios parámetros, los cuales son necesarios explicar para comprender el funcionamiento de la clase: - Knn: es la constante usada para definir el número de k vecinos. - Threshold: representa el porcentaje de umbral permitido pudiendo valer entre 0 y 1. Nos ayudará a decidir si un punto en el lado límite pertenece a una clase u a otra. Figura 22. Código de la clase KnnClassifier El primer paso que realiza el clasificador es calcular las distancias euclídeas entre los puntos a clasificar, en este caso los clústeres, y las distintas categorías. Para ordenar los resultados se hace uso de otra clase, KnnQueue, en la que se ha implementado una cola que ordena las posibles categorías a las que podría pertenecer el cluster por prioridad, es decir, de menor a mayor distancia euclídea.
64 Concurrencia, paralelismo e hilos Estos tres conceptos son determinantes para poder realizar una aplicación en Android que funcione de manera rápida y eficiente, por lo que, para la mejora de rendimiento de muchos procesos, este equipo ha hecho uso de la clase AsyncTask [30], una clase que proporciona Android, para poder realizar hilos que trabajen paralelamente con otros procesos de la aplicación sin que se crucen entre sí, esperando los eventos y respuestas del otro para poder seguir ejecutando la aplicación sin errores. Además, sin ella no sé pueden realizar peticiones a un servidor y/o base de datos. Figura 28. Esquema de ejecución de la clase AsyncTask [30] Esta clase es utilizada en varias ocasiones en la aplicación, ya que permite crear una concurrencia que nos ayuda a recoger y/o procesar datos que se necesitan o necesitarán para poder ejecutar distintas funcionalidades de la aplicación.
65 Casos en los que se utiliza AsyncTask: Peticiones al servidor: se realizan peticiones HTTP de tipo GET y POST para la inserción o selección de datos de la BD. Procesamiento de una imagen: se procesa la imagen en otro hilo con el algoritmo KMeans y Knn para la obtención de la lista de comidas predecidas. Comunicación con APIs: para la traducción de los términos y la comunicación con las BD USDA. Cambio de activity con información: existen diferentes activities en los que se necesita calcular, procesar u obtener datos ya sea de una comida, de una imagen o de un usuario, para poder realizar esos procesos se hace usos de estos hilos. Figura 29. Uso de AsyncTask en la aplicación
66 Funcionalidades destacadas En esta aplicación hay que destacar tres módulos principales, los cuales ofrecen al usuario diversas funcionalidades de las que se compone la aplicación. User: este módulo ofrece al usuario las funcionalidades mostradas en la Figura 30. Figura 30. Casos de uso el usuario Este es el módulo que más casos de uso contiene ya que está relacionado con el módulo Food y el equipo ha decidido implementar las operaciones en User, ya que al final es quien se considera que está más relacionado con la comida y la insulina, conceptos muy importantes en esta aplicación. Para el cálculo de la insulina tenemos que diferenciar entre la dosis de insulina basal, que sirve para reemplazar entre el 40% y 50% de la insulina total durante la noche o durante los periodos de ayuno, y la insulina de bolo que representa el tanto por ciento
67 restante y sirve como cobertura de carbohidratos. A continuación, se explica detalladamente el cálculo de la dosis de bolo prandial, Ir(t): [31] Ir(t)=Ii(t) + Ic(t) Donde Ii(t) es la insulina necesaria para metabolizar la ingesta de carbohidratos y Ic(t) es el valor de la insulina correctora que puede ser positiva o negativa. Para empezar el cálculo hay que hablar de los siguientes datos: G(t): cantidad de glucosa en sangre en el instante t. C(t): carbohidratos que se van a ingerir en el instante t. Gpre: glucosa objetivo antes de la comida. Ghipo: valor de glucosa considerado como hipoglucemia. R: ratio insulina-carbohidratos. Es la insulina necesaria para metabolizar una ración de CH. S: factor de sensibilidad a insulina. P: pero del paciente. Edad del paciente. Como en este proceso se utilizará el ratio y lo ideal es obtener el histórico de dosis del paciente, se pueden calcular también a partir de las siguientes fórmulas: Requisito diario de insulina= 0.55∗ Peso corporal en kg Cobertura de CHO= 500 Requisito diario de insulina
68 𝑅=𝑢𝑛𝑖𝑑𝑎𝑑𝑒𝑠 𝑑𝑒 𝑖𝑛𝑠𝑢𝑙𝑖𝑛𝑎 𝑐𝑎𝑟𝑏𝑜ℎ𝑖𝑑𝑟𝑎𝑡𝑜𝑠 Existen 2 condiciones a considerar para poder calcular el bolo prandial correctamente: Si Ghipo < G(t) < Gpre la recomendación de insulina para t será: Ir(t)=Ii=C(t)∗R Si G(t) < Gpre ó G(t) > Gpre se calculará tanto Ii(t) como Ic(t). En ambos casos Ii(t) no varía y vale lo siguiente: Ii(t)=C(t)∗𝑅 Para calcular Ic, se necesita el factor de sensibilidad a la insulina S, el cual se puede estimar de una forma fiable si la dosis total de insulina diaria está entre 0,4 y 0,8 u/kg/día a partir de la regla del “1800”: S= 1800 Insulina diaria Por tanto, si G(t) < Gpre, entonces: Ic(t)=Gpre−G(t) S
69 Y si G(t) > Gpre, entonces: Ic(t)=G(t)−Gpre S Para que finalmente el bolo prandial sea la suma de la insulina cobertura de CH y la insulina correctora, como se ha mencionado anteriormente. Por último, especificamos como calcular el bolo corrector, del cual también hay que conocer otros conceptos además de los que ya se han explicado. Gesp(t + tc): glucosa esperada en el instante de tiempo t DIA: duración de la acción de la insulina (Duration of the Insulin Action), su valor por defecto es 0.0182 IOB: la insulina activa (Insulin On Board) Δpost: recomendación de glucosa pasado tc tiempo. u(t): unidades de insulina en el instante t Para empezar a calcular el bolo corrector se empieza por: 𝐺𝑒𝑠𝑝(𝑡+𝑡𝑐)=𝐺(𝑡)+Δ𝑝𝑜𝑠𝑡 Δ𝑝𝑜𝑠𝑡=𝐺(𝑡𝑐)−𝐺(𝑡) Se puede simplificar el cálculo de Δ𝑝𝑜𝑠𝑡 de la siguiente manera: Si tc < 90 => Δ𝑝𝑜𝑠𝑡 = G(tc) – G(t) Si 90 ≤ tc < 105 => Δ𝑝𝑜𝑠𝑡 = 60 Si 105 ≤ tc < 125 => Δ𝑝𝑜𝑠𝑡 = 80 Si 125 ≤ tc ≤ 140 => Δ𝑝𝑜𝑠𝑡 = 60 Si tc > 140 => Δ𝑝𝑜𝑠𝑡 = G(tc) – G(t)
70 La insulina activa se calcula a partir de las siguientes ecuaciones: 𝐶1(𝑡+1)=𝑢(𝑡)−𝐷𝐼𝐴∗𝐶1(𝑡)+𝐶1(𝑡) 𝐶2(𝑡+1)=𝐷𝐼𝐴∗(𝐶1(𝑡)−𝐶2(𝑡))+𝐶2(𝑡) 𝐼𝑂𝐵=𝐶1(𝑡)+𝐶2(𝑡) Tomando como casos base C1(0) = 0 y C2(0) = 0. Así esto permitirá calcular IOB de forma iterativa para obtener el IOB que nos interesa en el instante t. Con esto, podremos calcular el bolo corrector Irc. 𝐼𝑟𝑐(𝑡+𝑡𝑐)=𝐺(𝑡+𝑡𝑐)−𝐺𝑒𝑠𝑝(𝑡+𝑡𝑐) 𝑆−𝐼𝑂𝐵
71 Figura 31. Diagrama de actividad de calcular bolo prandial
72 Figura 32. Diagrama de actividad de calcular bolo corrector
73 Figura 33. Diagrama de secuencia de añadir insulina
80 Añadimos la Figura 39, ya que forma parte del proceso para añadir una comida inexistente en la base de datos. Esta parte es primordial debido a que es necesario el cálculo de las medias para la base de conocimiento. El resto del proceso se especifica más adelante. Figura 40. Diagrama de secuencia de procesar imagen de usuario
81 Food: este módulo ofrece al usuario las funcionalidades mostradas en la Figura 41. Figura 41. Diagrama de casos de uso para la comida Este módulo consta de las operaciones principales que se pueden realizar con las comidas. Además, es el encargado de comunicarse con las APIs para la traducción de los datos y la obtención de los reportes nutricionales de cada alimento que contenga cada comida, pero estas operaciones ya están implícitas en todos los casos de uso de este módulo. Aun así, hay que destacar una funcionalidad, añadir comidas a la BD, debido a que gracias a esta funcionalidad se puede ampliar la base de conocimientos de los algoritmos y, por tanto, ampliar la lista de predicciones.
82 A continuación, se puede observar cómo actúan las funcionalidades más relevantes de este módulo. Figura 42. Diagrama de flujo para reporte de alimentos
83 Figura 43. Diagrama de actividad para reporte de alimentos
84 Figura 44. Diagrama de secuencia para reporte de alimentos
85 Figura 45. Diagrama de flujo para añadir comida nueva a la BD
86 Figura 46. Diagrama de actividad para añadir comida nueva a la BD
87 Figura 47. Diagrama de secuencia para añadir comida nueva a la BD
88 Servidor La parte servidor consiste en un servidor que utiliza Apache para manejar las peticiones y phpMyAdmin para administrar la base de datos, como mencionamos en apartados anteriores. Apache Apache [31] es el servicio que se ejecuta en el servidor para que éste actúe precisamente como un servidor web. Este software se encarga de manejar las peticiones que lleguen desde la parte cliente y de responder dichas peticiones con los datos o información que correspondan. Los datos que componen la respuesta del servidor a las peticiones del cliente se extraen de la base de datos utilizando scripts escritos en PHP. Estos scripts están alojados en el servidor y hacen una petición HTTP a la base de datos utilizando el servicio de MySQL. Al recibir los datos, componen la respuesta en formato JSON y devuelven los datos al cliente o devuelven un error en caso de haber ocurrido alguno. Todo este proceso es transparente tanto a la parte cliente como al usuario como tal. Además, a este navegador se le ha añadido el servicio phpMyAdmin, con el cual se puede gestionar la base de datos utilizada desde cualquier navegador, este servicio trabaja de la mano con Apache, por lo que se ha tenido que crear otro archivo de configuración e instalar todos los paquetes relacionados con PHP para que el servicio funcione correctamente.
89 Figura 48. Scripts PHP del servidor Figura 49. Esquema Entidad-Relación de la BD
96 Análisis de Ingeniería del Software A pesar de ser un equipo compuesto por 3 miembros, se ha intentado seguir el sistema de Sprints que ofrece la metodología ágil, Scrum. Con esto, desde que se empezó el proyecto se ha ido generando y actualizando un Backlog con el que se repartían las tareas los miembros del equipo. Además, se ha intentado hacer una estimación de tiempoesfuerzo que se iba a invertir en cada Sprint, aunque estas normalmente han sido incorrectas debido a que se ha tenido que invertir demasiado tiempo y esfuerzo en la fase de investigación del proyecto y en la fase de pruebas. Riesgos Cuando se habla de riesgos en IS se refiere a todo aquello que puede afectar de forma negativa al desarrollo del software, por eso se realizar un plan de gestión de riesgos en el cual se clasifican los riesgos en función de su probabilidad de aparición y del esfuerzo necesario para mitigarlo y la prioridad que hay que darle a cada uno. Existen 3 tipos de riesgos, pero en este caso al ser un TFG solo se consideraron los riesgos del proyecto: A. Entrega tardía. B. Abandono de un miembro del equipo. C. Falta de comunicación entre el equipo. D. Falta de implicación por parte de algún miembro. E. Inexperiencia con las tecnologías. F. Cambios en los requisitos. G. Ocupaciones extra laborables. H. Baja de algún miembro.
97 Tras esto, se realizó un análisis de basado en el SQAS-SET [41] donde la probabilidad podía ser frecuente, probable, ocasional, remota e improbable y el grado de gravedad podía ser catastrófico, crítico, serio, tolerable e insignificante. Probabilidad Gravedad Frecuente Probable Ocasional Remota Improbable Catastrófica Crítica A B Seria C, D F Tolerable E, G, H Insignificante INTOLERABLE ALTO MEDIO BAJO TOLERABLE Figura 54. Tabla de priorización del riesgo Para filtrar estos riesgos se utilizó la Regla de Pareto, escogiendo el 20% de los riesgos identificados, con esto, se han elegido 2 riesgos con mayor prioridad, es decir, A y B. Así, se aplicaron las técnicas de reducción, supervisión y gestión del riesgo. A. Entrega tardía 1. Reducción: llevar una organización del equipo basado en alguna metodología. 2. Supervisión: comprobar si con lo que se ha hecho hasta el momento se llega a la entrega final. 3. Gestión: implementar lo máximo posible, aunque en poca cantidad y comunicárselo a los directores.
98 B. Abandono de un miembro del equipo 1. Reducción: maximizar la comunicación en el equipo para conocer las circunstancias por las que pasa cada miembro. 2. Supervisión: ayudar en todo lo posible a ese miembro para que siga trabajando. 3. Gestión: comunicárselo a los directores y establecer un nuevo plan para la organización del proyecto. Costes y negocio Existen diferentes maneras de estimar costes a nivel de hardware y software y costes a nivel de esfuerzo humano y tiempo, para este proyecto el análisis de costes fue el siguiente: Hardware: se utilizaron los portátiles y smartphones de los miembros del equipo, de los que se constaba antes de este proyecto. Un servidor cuyo nodo físico se encuentra en las instalaciones de la UCM. Software: herramientas de uso libre, aunque también se incluye la API de Google, que está en periodo de prueba y que hay que pagar la licencia tras un año. Persona: se ha desarrollado por 3 estudiantes de la UCM y bajo acuerdo de confidencialidad con los directores del proyecto.
99 Con respecto al negocio, existen bastantes aplicaciones relacionadas con el cálculo de los bolos y la creación de dietas para comer diariamente en función de las dosis diarias de insulina que suelen inyectarse [40], al igual que existen algunas para clasificar elementos mediante fotografías o la propia cámara, por ejemplo, Google Lens, pero, por ahora, no existe ninguna que procese la imagen de un plato completo y de información sobre todos los componentes existentes en él, además, de ofrecer un calculador de bolo prandial y corrector. Aun así, no se puede descartar que en poco tiempo aparezca una parecida, ya que el campo de la informática está en constante cambio e innovación, pero no se descarta que a corto plazo la aplicación pueda ser incluida en plataformas de servicios para Android como PlayStore de Google. Calidad y rendimiento En la fase de pruebas es cuando se garantiza la calidad del software y se realiza un análisis de rendimiento con el fin de mejorar el proyecto. Aunque no se han podido realizar demasiadas pruebas la calidad, el software ha superado las siguientes pruebas: Pruebas de unidad: ya que a cada método ha dado el resultado esperado según una entrada concreta que el equipo ha ido ingresando. Pruebas de integración: para cada funcionalidad se ha utilizado un conjunto de clases relacionadas entre sí, y por el mismo método que en el de las pruebas de unidad, todas han dado los resultados esperados según la entrada.
100 Pruebas de sistema: el sistema completo ha sido probado con un nivel de opacidad denominado “de caja negra”, el cual ha funcionado correctamente y ha respondido adecuadamente. Pruebas de aceptación: aquí solo se han podido realizar pruebas Alpha, es decir, llevadas a cabo por los desarrolladores, al superarlas se podrán pasar a los usuarios finales para seguir con las pruebas beta y terminar la verificación y validación del software. Por otro lado, se han realizado pruebas de rendimiento en los cuales se ha monitorizado el funcionamiento de la RAM, la CPU, la red y la energía del dispositivo gracias a la herramienta Profile que ofrece Android Studio para ver en qué cantidad afecta la aplicación al hardware disponible en los dispositivos de prueba. Figura 55. Gráfica de monitorización al iniciar la aplicación La parte en la que más consumía recursos era durante el procesamiento de la imagen para la obtención de los alimentos, como se puede observar en la Figura 56.
101 Figura 56. Gráfica de monitorización durante el procesamiento de la imagen En el resto de las operaciones la aplicación mantenía datos parecidos a los que se muestran en la Figura 55, con muy poca varianza entre transiciones. Figura 57. Gráfica de monitorización durante el reporte nutricional de los alimentos
102 Manual de usuario Inicio de sesión Para poder acceder a la aplicación hay que estar registrado/a e iniciar sesión. Figura 58. Vista de acceso a la aplicación El registro se realiza en esta misma vista, para ello hay que ingresar un email válido y una contraseña de mínimo seis caracteres. Una vez hecho el registro correctamente la aplicación llevará al usuario al menú principal, este ofrece tres opciones.
103 Figura 59. Vista de menú principal Acceder a la galería y elegir una foto para procesarla. Figura 60. Vista de galería
104 Realizar una foto con la cámara y procesarla. Figura 61. Vista de cámara Menú de usuario. Figura 62. Vista de menú de usuario sano
105 Figura 63. Vista de menú de usuario diabético Opciones de imágenes Una vez elegida o realizada la fotografía, se da la opción al usuario de cancelar la operación, procesar la imagen o añadir una nueva comida inexistente en la BD.
112 Figura 75. Mensaje de bolo prandial para usuario diabético Menú de usuario En este menú se le ofrece al usuario poder modificar su usuario, ver sus comidas recientes, ver histograma de dosis de insulina (en el caso de ser diabético), calcular bolo corrector y cerrar sesión. Figura 76. Vista para modificar usuario
113 Figura 77. Vista de comidas recientes Figura 78. Vista de histograma de dosis de insulina
114 Figura 79. Vista para calcular bolo corrector
115 Figura 80. Mensaje sobre dosis correctora
116 Resultados Durante la fase de pruebas se han obtenido diferentes resultados que garantizan la mantenibilidad y usabilidad de la aplicación. En este apartado las pruebas están enfocadas al rendimiento y porcentajes de fallo y acierto que proporcionaron los algoritmos utilizados en el proyecto. Por una parte, el tiempo de espera en el algoritmo KMeans era en un principio de casi 5 minutos, dato que se consiguió reducir al 94,4% de lo que duraba en un principio, es decir, que actualmente el tiempo medio de espera es de 2,3 segundos. Figura 81. Tiempo de espera actual del kMeans
117 Para la obtención de las tasas de acierto y fallo, se realizaron 50 pruebas con imágenes diferentes en las que algunas tenían alimentos en común y se fueron registrando los intentos que eran necesarios para obtener los alimentos correctos, los alimentos encontrados y los no encontrados. Gracias a esto se obtuvieron los siguientes resultados: Tasa de acierto: 91,5% para 50 imágenes con un total 75 alimentos encontrados. Tasa de fallo: 8,5% para 50 imágenes con un total de 6 alimentos no encontrados. Más intentos: se obtuvo un 21,17% más de intentos para conseguir obtener todos los alimentos de la imagen. Con estos datos se puede deducir que el algoritmo obtiene buenos resultados, aunque en algunas ocasiones va a necesitar procesar la imagen más de una vez para obtener los alimentos correctos. Finalmente, se realizaron pruebas para comprobar los tiempos de espera para la conexión con la base de datos, en este caso es útil volver al apartado de Calidad y Rendimiento con el fin de observar las gráficas mostradas en él y poder observar el comportamiento de la CPU, ya que en todas las figuras se realizan peticiones a la BD y esto ayuda a decidir si se debe optimizar la base de datos. Para obtener estos tiempos se hizo uso de PostMan, una herramienta que ayuda a realizar pruebas con scripts php y que devuelve la respuesta de la petición realizada junto con parámetros de interés como es el tiempo de espera de respuesta, es decir, lo que se tarda en realizar la conexión la base de datos, realizar una petición a esta, obtener un resultado y devolverlo. Con esto, los tiempos quedaron como se muestra en la Figura 81 y la media de tiempo que se obtuvo fue de 44 ms.
118 Figura 82. Tiempos de espera en la conexión con la BD
119 Contribuciones En el comienzo del proyecto se realizó una reunión, no solo para asentar las bases y la estructura del trabajo que se realizaría posteriormente, sino para definir claramente los requisitos necesarios de la aplicación. Definimos que era de máxima importancia tanto el trabajo de investigación y codificación como su correcta documentación. La unión de estas tres partes era indispensable para conseguir el resultado buscado, por lo que todos los miembros del equipo han formado parte de todas ellas en mayor o menor medida. A continuación, se procede a explicar más detalladamente la contribución individual de cada uno de los miembros del equipo: LAURA Como se menciona anteriormente una de las bases sobre las que asentamos nuestro proyecto fue la investigación. Era de vital importancia informarse de los distintos métodos y opciones que teníamos para realizar la aplicación para poder elegir cuál de todos ellos encajaba mejor en el proyecto. Por lo tanto, desde un inicio me centré más en la investigación, en primer lugar, sobre las formas de segmentar la imagen, y en segundo lugar, sobre como etiquetarlas y clasificarlas correctamente. Ambos campos son muy extensos por lo que recibí la ayuda de mi compañera Milagros para poder avanzar más rápido. Dentro de la segmentación de imágenes existen multitud de métodos ya desarrollados por lo que mi trabajo consistió en investigar todos ellos, con sus ventajas y
120 desventajas, valorando si su implementación era viable y encajaba con la aplicación. Toda esta información nos ayudó a decidir qué método elegiríamos para la segmentación. Una vez decidimos el algoritmo Kmeans comenzó la etapa de codificación del algoritmo donde me centré en que arrojara resultados eficientes, pero también en implementarlo rápidamente ya que era necesario para seguir el curso de la aplicación. Mis compañeros contribuyeron también a esta tarea aportando código e ideas. Después de realizar la segmentación de las imágenes era necesario ser capaces de clasificarlas automáticamente y que, además, la aplicación continuase aprendiendo constantemente. Debido a esto comencé la etapa de investigación sobre algoritmo de segmentación y sobre machine learning. Para tomar la decisión sobre que algoritmo usaríamos para la clasificación era necesario encontrar un algoritmo que fuese compatible con los resultados arrojados por el Kmeans. Esta etapa me resultó muy complicada por lo que tuvimos que acudir a varias reuniones con nuestros tutores. Una vez se decidió que sería el algoritmo K-nearest neightbors para la clasificación comencé a formarme sobre el tema. Este algoritmo nos permitía tratar cada uno de los pixeles como puntos en un plano lo que me permitió encajarlo perfectamente al Knn. Además era necesario dotar al algoritmo Knn de un conjunto de datos de entrenamiento con los que fuese capaz de entrenar y aprender. Con este objetivo creamos una tabla en la base de datos en la que almacenaríamos todos los datos referentes al conjunto de entrenamiento. Dicho algoritmo toma mejores decisiones cuanto mayor es el conjunto por lo que comencé a calcular los datos necesarios para completar la BBDD que utilizaría posteriormente el Knn. Los datos obtenidos provienen no solo de la propia aplicación sino que además utilicé Matlab como herramienta auxiliar para contrastar que los datos obtenidos eran correctos. Este código fue configurado junto con mi compañera Milagros con el objetivo de conseguir datos más fiables disminuyendo de esta forma la tasa de errores de la aplicación.
121 Mientras yo realizaba el trabajo anteriormente mencionado mis compañeros se dedicaron a establecer la base de datos necesaria para guardar los resultados obtenidos por los algoritmos y a implantar la base de la aplicación. Además, era necesario comenzar con el trabajo de documentación ya que debe ser paralelo a la investigación, por esta razón comencé a escribir la memoria del proyecto planteando la estructura que debía seguir. Me he encargado de la redacción de la parte principal incluyendo no solo la información necesaria sobre los algoritmos anteriormente mencionados y su investigación previa sino además sobre algunos de los conocimientos que nos han sido necesarios para comprender el objetivo del proyecto como la diabetes o la misma inteligencia artificial. Además, he ido corrigiendo las distintas versiones que íbamos redactando, teniendo en cuenta las anotaciones y correcciones que nuestra directora María nos iba proporcionando. MILAGROS Desde un inicio y una vez sabidos los requisitos para la creación de la aplicación, todos contribuimos a la identificación de los módulos principales de los que se componía la aplicación, es decir, el usuario, las imágenes y la comida, por lo que propuse utilizar una arquitectura Modelo-Vista-Controlador (MVC) de tipo activo, ya que teníamos experiencia previa con ese patrón y por la forma de actuar de la aplicación era también coherente elegir un tipo de arquitectura así. Una vez aceptada esta propuesta por el equipo procedí a la creación del modelado de software de la aplicación, ya habían sido especificados y validados los requisitos funcionales y aunque durante la implementación aparecieron requisitos emergentes, esto fue suficiente para empezar a crear los diagramas que componen el modelo. Empecé por la creación de los casos de uso, de flujo del usuario y de actividad, para así tener aún más idea de cómo debía actuar cada
128 A partir de este trabajo y los resultados obtenidos queda una amplia base de conocimiento para el trabajo dentro del campo de procesamiento de imágenes a través del color. En un futuro podría ampliarse a, no solo el estudio por color, sino también por textura, lo que proporcionaría una mayor cantidad de información al clasificador haciéndolo más fiable y puliría la segmentación de la imagen. No sería el único aspecto a poder mejorar, pudiendo utilizar algoritmos más complejos como el de Sobel para identificar bordes y nos permitiría recortar el plato automáticamente y así realizar las mismas tareas mejorando los resultados actuales. El campo de la aproximación, no solo de carbohidratos, sino también de dietas añadiría mayor funcionalidad a la aplicación haciéndola más completa, pudiendo proponer al usuario recetas a partir de los alimentos que ha proporcionado o dando más información al usuario mediante email o incluso proporcionándole un gestor nutricional en función de su altura y peso. También sería interesante el desarrollo de esta aplicación para distintas plataformas, como iOS, ampliando así la cobertura a una mayor cantidad de usuarios. En cuanto a seguridad, es necesario cambiar las peticiones a HTTPS para evitar intrusiones o robos de sesión en redes que no sean de confianza, por otro lado, el servidor debería de permanecer en una extranet para poder garantizar la seguridad de los datos almacenados en la base de datos y restringir el acceso al servidor como administrador. Por último, para el mantenimiento de la aplicación sería mejorar el sistema de monitorización y de alertas, para ello, se utilizaría un servicio ELK, el cual mediante elasticsearch accedería a los logs o archivos de interés con el fin de obtener métricas para finalmente obtener una gráfica, tabla, etc. que permita plasmar esa información en datos relevantes y métricas útiles para mantener el sistema, mientras que, por otro lado, añadir
129 también una herramienta de alertas que pueda acceder a esta información con el fin de notificar a las personas responsables de la aplicación. Además, crear un sistema de disaster recovery por si se cayera el servidor, que siempre hubiera otro servidor con los datos sincronizados y preparado para seguir dando el servicio.
130 Conclusions The segmentation method supplied by the KMeans algorithm has been proven very successful in the image segmentation area. It has not only achieved a suitable separation by color, it has also made it in an acceptable time. In the other hand, the results acquired by the Knn classifier through the calculation of Euclidean distances, had provided convenient data to take on the classification of the different aliments. Furthermore, the methods used for the calculus of the quantities and proportions of carbohydrates and, therefore, the calculus of nutrients and the appropriate doses of insulin for each user have been reflected reliable and secure. Likewise, with the aim of achieving total functionality it has been attach the possibility to add manually aliments in case of failure of the classification algorithm. That way, we have not only accomplished providing useful nutritional information, but also that, the application continues learning and improving through the user itself. Lastly, all the information generated by the application is considered highly useful and, therefore, it will be saved dynamically in the DDBB. We could affirm that we have developed a totally functional Android application with a client server structure that is able to segment and classify images through color study.
131 From this project and the results obtained remains a broad knowledge base of work within the field of image processing through color. In the future it could be extend to, not only to the study through color but through texture, which would provide a larger quantity of information for the classifier making it more reliable, and also, would refine the image segmentation. It wouldn’t be the only aspect to upgrade; we could use more complex algorithms such as the Sobel algorithm to identify edges and allow us to cut the plate automatically to improve the actual results. Besides, it could be interesting adding not only the estimation of carbohydrates but also the approach on diets; making the application more complex, including recipes containing the aliments supplied by the user or giving more information by email or even providing a nutritional manager in function of its height or weight. Finally, it would be compelling the development for different platforms, such as iOS, increasing the coverage of users. In terms of security, it’s necessary to chague the type of requests to HTTPS to avoid instrusions or theft of user sessions on networks that are not trusted, on the other hand, the server should remain on an extranet in order to guarantee the security of the information in the database and finally, restrict access to the server as administratos. Finally, the maintenance of the application would be to improve the monitoring and alerts system, for this, an ELK service could be the best option, because it uses elasticsearch service tha access to logs or files of interest in order to obtain metrics to finally show every important data in a graphic, table, etc. With ELK, we could translate this information into relevant data and useful metrics to maintain the system, however, also add an alert tool that can access to this information with the purpose of notifying the people who are responsible for the application. In addition, create a disaster recovery
132 system to use in case the server goes down, in this way there is always another server with the data synchronized and ready to continue giving the service.
133 Lista de referencias [1] J.I.Hidalgo, et al., Modeling glycemia in humans by means of Grammatical Evolution, Appl. Soft Comput J.(2013),https://doi.org/10.1016/j.asoc.2013.11.006 [2] Esmeralda Colino. (2015). Fundación para la Diabetes: Tipos de diabetes. Recuperado de https://www.fundaciondiabetes.org/infantil/177/tipos-de-diabetesninos [3] Fundación para la Diabetes (2016) Fundación para la Diabetes: La diabetes en España. Recuperado de https://www.fundaciondiabetes.org/prensa/297/ladiabetes-en-espana [4] Shapiro, L. & Stockman, G. (2000) Computer Vision. Seattle, Washington. EEUU: Prentice Hall Editorial. [5] Maravall Gómez-Allende, D. (1993) Reconocimiento de formas y visión artificial. Madrid, España: RA-MA Editorial. [6] Deep Learning, Inteligencia Artificial y Machine Learning. Recuperado de https://www.blog.andaluciaesdigital.es/deep-learning-inteligencia-artificial-ymachine-learning/ [7] Sucar, L.Enrique & Gómez, Giovani (2011) Visión Computacional. Instituto Nacional de Astrofísica, Óptica y Electrónica, México. https://www.researchgate.net/profile/Luis_Sucar/publication/267295870_Vision_ Computacional/links/54d8cae30cf2970e4e7940c1/Vision-Computacional.pdf [8] Statcounter: Mobile Vendor Market Share Worldwide http://gs.statcounter.com/vendor-market-share/mobile [9] Android vs iPhone: la guerra de los smartphones en cifras. Recuperado de https://computerhoy.com/reportajes/industria/android-vs-iphone-guerrasmartphones-cifras-271447 [10] Cloud SQL. Recuperado de https://cloud.google.com/sql/?hl=es [11] Android Documentation: Device Storage. Recuperado de https://developer.android.com/training/data-storage/files [12] About SQLite. Recuperado de https://www.sqlite.org/about.html [13] MySQL Documentation. Recuperado de https://dev.mysql.com/doc/ [14] About MariaDB. Recuperado de https://mariadb.org/about/ [15] Pajares, G & De la Cruz, JM (2008) Visión por computador: imágenes digitales y aplicaciones. Ra-Ma Editorial.
134 [16] MacQueen, J. (1867) Some methods for classification and analysis of multivariate observations. University of Cailfornia, Los Angeles. EEUU. [17] Hong Yao & Qingling Duan & Daoliang Li & Jianping Wang (2013) Mathematical and Computer Modelling. Pekín, China. https://www.journals.elsevier.com/mathematical-and-computer-modelling [18] Maravall Gómez-Allende, D. (1993) Reconocimiento de formas y visión artificial. Madrid, España: RA-MA Editorial. [19] Mitchell, Tom M. (1997) Machine learning. Pittsburgh, Pensilvania. EEUU. WCB McGraw-Hill Publisher. [20] Arquitectura cliente-servidor. Recuperado de http://somebooks.es/arquitecturaclienteservidor/ [21] Modelo Vista Controlador (MVC). Recuperado de https://si.ua.es/es/documentacion/asp-net-mvc-3/1-dia/modelo-vista-controladormvc.html [22] Android Manifest. Recuperado de https://developer.android.com/guide/topics/manifest/manifest-intro?hl=es-419 [23] ¿Qué es el Gradle? Recuperado de https://androidstudiofaqs.com/conceptos/que-es-gradle-en-android-studio [24] Activity. Recuperado de https://developer.android.com/guide/components/activities.html?hl=es-419 [25] Intent. Recuperado de https://developer.android.com/guide/components/intents-filters?hl=es-419 [26] Fragments. Recuperado de https://developer.android.com/guide/components/fragments?hl=es-419 [27] KMeans en Matlab. Recuperado de https://es.mathworks.com/help/stats/kmeans.html [28] NDB API. Recuperado de https://ndb.nal.usda.gov/ndb/doc/index# [29] Cloud Translation. Recuperado de https://cloud.google.com/translate/ [30] AsyncTask. Recuperado de https://corochann.com/asynctask-usage-summary-341.html [31] Cálculo de la dosis de insulina. Recuperado de https://dtc.ucsf.edu/es/tipos-dediabetes/diabetes-tipo-2/tratamiento-de-la-diabetes-tipo-2/medicamentos-yterapias-2/prescripcion-de-insulina-para-diabetes-tipo-2/calculo-de-la-dosis-deinsulina/
135 [32] About Apache. Recuperado de https://httpd.apache.org/ABOUT_APACHE.html https://developer.android.com/training/articles/security-tips?hl=es-419 [33] Patrick Favre-Bulle (2018) Symmetric Ecnryption with AES in Java and Android. Recuperado de https://proandroiddev.com/security-best-practices-symmetricencryption-with-aes-in-java-7616beaaade9 [34] What is a block cipher? Recuperado de https://www.wolfssl.com/what-is-a-blockcipher/ [35] ECB – AES electronic codebook mode encryption. Recuperado de https://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.nrf 52832.ps.v1.1%2Fecb.html [36] Cipher. Recuperado de https://developer.android.com/reference/javax/crypto/Cipher [37] SecretKeySpec. Recuperado de https://developer.android.com/reference/javax/crypto/spec/SecretKeySpec [38] Sugerencias de seguridad Android. Recuperado de https://developer.android.com/training/articles/security-tips?hl=es-419 [39] IPC mechanisms. Recuperado de https://stackoverflow.com/questions/5740324/what-are-the-ipc-mechanismsavailable-in-the-android-os [40] Apps de diabetes. Recuperado de https://republikadiabetes.com/apps-contar-raciones-calculo-dosis-registro-datos/ [41] Certificación SQAS. Recuperado de https://www.bureauveritas.es/home/about-us/our-business/our-businesscertification/su-sector/transport-and-distribution/transporte-sqas [42] USDA Food Composition Database. Recuperado de https://ndb.nal.usda.gov/ndb/ [43] ¿Qué es REST? Recuperado de https://www.arquitecturajava.com/que-es-rest/