Sistema para la reconstrucción de tomografías de impedancia eléctrica en tiempo real, basado en técnicas de Machine Learning

UNIVERSIDAD DE SANTIAGO DE COMPOSTELA ESCUELA T´ ECNICA SUPERIOR DE INGENIER´ IA Sistema para la reconstrucci´on de tomograf´ıas de impedancia el´ectrica en tiempo real, basado en t´ecnicas de Machine Learning Autor: Mart´ın Aller Dom´ınguez Directores: Jos´e Manuel Cotos Y´a˜nez David Mera P´erez Grado en Ingenier´ıa Inform´atica Noviembre 2020 Trabajo de Fin de Grado presentado en la Escuela T´ecnica Superior de Ingenier´ıa de la Universidad de Santiago de Compostela para la obtenci´on del Grado en Ingenier´ıa Inform´atica D. Jos´e Manuel Cotos Y´a˜nez, Profesor del Departamento de Electr´onica y Computaci´on de la Universidad de Santiago de Compostela, y D. David Mera P´erez, Investigador posdoctoral del Centro de Investigaci´on en Tecnolog´ıas Inteligentes de la Universidad de Santiago de Compostela, INFORMAN: Que la presente memoria, titulada Sistema para la reconstrucci´on de tomograf´ıas de impedancia el´ectrica en tiempo real, basado en t´ecnicas de Machine Learning, presentada por D. Mart´ın Aller Dom´ınguez para superar los cr´editos correspondientes al Trabajo de Fin de Grado de la titulaci´on del Grado en Ingenier´ıa Inform´atica, se realiz´o bajo nuestra direcci´on en el Departamento de Electr´onica y Computaci´on de la Universidad de Santiago de Compostela. Y para que as´ı conste a los efectos oportunos, expiden el presente informe en Santiago de Compostela, a 9 de noviembre de 2020: El director, El codirector, El alumno, Jos´e M. Cotos Y´a˜nez David Mera P´erez Mart´ın Aller Dom´ınguez i ALLER DOMINGUEZ MARTIN - 46095056C Firmado digitalmente por ALLER DOMINGUEZ MARTIN - 46095056C Fecha: 2020.11.09 12:12:12 +01'00' COTOS YAÑEZ JOSE MANUEL - 32649200X Firmado digitalmente por COTOS YAÑEZ JOSE MANUEL - 32649200X Fecha: 2020.11.09 12:56:19 +01'00' Firmado por MERA PÉREZ, DAVID (FIRMA) el día 09/11/2020 con un certificado emitido por AC DNIE 002 ´ Indice general 1. Introducci´on 1 1.1. Tomograf´ıa de Impedancia El´ectrica . . . . . . . . . . . . . . . . . 1 1.2. Soluci´onpropuesta .......................... 2 1.3. Objetivos del trabajo . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Planificaci´on y presupuestos 5 2.1. Planificaci´on temporal . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1.1. Ciclodevida ......................... 5 2.1.2. EDT.............................. 6 2.1.3. Diagrama de Gantt . . . . . . . . . . . . . . . . . . . . . . 9 2.2. Gesti´ondecostes ........................... 13 2.2.1. Costes de los recursos humanos . . . . . . . . . . . . . . . 13 2.2.2. Costes de los recursos materiales . . . . . . . . . . . . . . 14 2.2.3. Coste del proyecto . . . . . . . . . . . . . . . . . . . . . . 15 2.3. Gesti´onderiesgos........................... 17 2.3.1. Definici´on de las categor´ıas de probabilidad e impacto . . . 17 2.3.2. Identificaci´on y an´alisis de riesgos . . . . . . . . . . . . . 18 2.3.3. Planificaci´on de riesgos . . . . . . . . . . . . . . . . . . . . 22 2.3.4. Supervisi´on de riesgos . . . . . . . . . . . . . . . . . . . . 24 3. Especificaci´on de requisitos y casos de uso 26 3.1. Requisitos funcionales . . . . . . . . . . . . . . . . . . . . . . . . 26 3.2. Requisitos no funcionales . . . . . . . . . . . . . . . . . . . . . . . 36 3.3. Requisitos de informaci´on . . . . . . . . . . . . . . . . . . . . . . 37 3.4. Casosdeuso.............................. 45 3.4.1. Diagrama de casos de uso . . . . . . . . . . . . . . . . . . 45 3.4.2. Descripci´on de los casos de uso . . . . . . . . . . . . . . . 46 4. Tecnolog´ıas y herramientas 60 4.1. Tecnolog´ıas .............................. 60 4.1.1. Python............................. 60 4.1.2. DjangoREST......................... 60 4.1.3. React ............................. 61 ii 4.1.4. Keras ............................. 61 4.1.5. EIDORS............................ 61 4.1.6. Celery ............................. 61 4.1.7. C++.............................. 62 4.1.8. HTML5 ............................ 62 4.1.9. CSS3.............................. 62 4.1.10.PostgreSQL.......................... 62 4.1.11.Bootstrap ........................... 62 4.2. Herramientas ............................. 63 4.2.1. Visual Studio Code . . . . . . . . . . . . . . . . . . . . . . 63 4.2.2. ProjectLibre ......................... 63 4.2.3. StarUML ........................... 63 4.2.4. Diagrams.net ......................... 63 4.2.5. NinjaMock........................... 63 4.2.6. LaTeX............................. 63 5. Dise˜no e implementaci´on 64 5.1. Selecci´on de la arquitectura . . . . . . . . . . . . . . . . . . . . . 64 5.1.1. Arquitectura web monol´ıtica . . . . . . . . . . . . . . . . . 64 5.1.2. Serviciosweb ......................... 65 5.1.3. Arquitectura seleccionada . . . . . . . . . . . . . . . . . . 66 5.2. Dise˜no del backend .......................... 67 5.2.1. Diagrama de arquitectura . . . . . . . . . . . . . . . . . . 67 5.2.2. Diagrama de clases del m´odulo de acceso a BD . . . . . . 69 5.2.3. Diagrama de clases del m´odulo de EIT . . . . . . . . . . . 70 5.2.4. Patrones de dise˜no empleados en el backend ........ 71 5.2.5. Diagramas de secuencia . . . . . . . . . . . . . . . . . . . 72 5.2.6. Integraci´on entre Python y EIDORS . . . . . . . . . . . . 80 5.2.7. Autenticaci´on y permisos . . . . . . . . . . . . . . . . . . . 80 5.3. Dise˜no del frontend .......................... 82 5.3.1. Diagrama de clases del frontend ............... 82 5.3.2. Dise˜no de la interfaz gr´afica . . . . . . . . . . . . . . . . . 83 5.3.3. Ventana principal . . . . . . . . . . . . . . . . . . . . . . . 84 5.3.4. Tipo de reconstrucci´on . . . . . . . . . . . . . . . . . . . . 86 5.3.5. Reconstrucci´on de im´agenes . . . . . . . . . . . . . . . . . 87 5.3.6. Modelos ............................ 92 5.3.7. Datasets............................ 99 5.3.8. Tareas............................. 102 6. Machine Learning 104 6.1. Datasets ................................ 104 6.1.1. Metodolog´ıa de entrenamiento . . . . . . . . . . . . . . . . 105 6.2. Modelos ................................ 105 iii 6.2.1. Redes neuronales . . . . . . . . . . . . . . . . . . . . . . . 106 6.2.2. Random Forest ........................ 109 6.2.3. M´aquina de soporte vectorial . . . . . . . . . . . . . . . . 112 6.3. Postprocesado............................. 115 7. Pruebas y validaci´on 117 7.1. Pruebas de validaci´on de requisitos . . . . . . . . . . . . . . . . . 117 7.1.1. Prueba de gesti´on de usuarios (P1) . . . . . . . . . . . . . 117 7.1.2. Prueba de modelos (P2) . . . . . . . . . . . . . . . . . . . 122 7.1.3. Prueba de predicci´on de conductividades y reconstrucci´on deim´agenes(P3) ....................... 127 7.1.4. Prueba de datasets (P4) ................... 131 7.1.5. Prueba de tareas (P5) . . . . . . . . . . . . . . . . . . . . 137 7.2. Validaci´on por parte de los usuarios . . . . . . . . . . . . . . . . . 138 7.2.1. Cuestionario de usabilidad . . . . . . . . . . . . . . . . . . 138 7.2.2. Resultados obtenidos . . . . . . . . . . . . . . . . . . . . . 139 8. Conclusiones y posibles ampliaciones 141 8.1. Posibles ampliaciones . . . . . . . . . . . . . . . . . . . . . . . . . 142 A. Manuales t´ecnicos 143 A.1.Requerimientos ............................ 143 A.2. Instalaci´on y despliegue . . . . . . . . . . . . . . . . . . . . . . . 143 A.2.1. Instalaci´on del backend .................... 143 A.2.2. Instalaci´on del frontend ................... 144 A.2.3.Despliegue........................... 145 A.3.Configuraci´on............................. 145 B. Manual de usuario 147 B.1. Inicio de sesi´on y registro . . . . . . . . . . . . . . . . . . . . . . . 147 B.2.P´aginaprincipal............................ 147 B.3. Reconstrucci´on de im´agenes . . . . . . . . . . . . . . . . . . . . . 148 B.3.1. Selecci´on de modelo . . . . . . . . . . . . . . . . . . . . . . 148 B.3.2. Reconstruir la imagen de una malla . . . . . . . . . . . . . 148 B.3.3. Predicci´on de conductividades a partir de un fichero de voltajes ............................ 149 B.4.Modelos ................................ 149 B.4.1. Entrenar modelo . . . . . . . . . . . . . . . . . . . . . . . 149 B.4.2. Comparar modelos . . . . . . . . . . . . . . . . . . . . . . 150 B.5. Datasets ................................ 151 B.5.1. Subida de dataset . . . . . . . . . . . . . . . . . . . . . . . 151 B.5.2. Generaci´on de dataset .................... 151 B.6.Tareas ................................. 152 iv Bibliograf´ıa 153 v ´ Indice de figuras 1.1. Ejemplo de malla con dos artefactos y 16 electrodos. . . . . . . . 3 2.1. EDTdeprimernivel.......................... 6 2.2. EDT de segundo nivel. Planificaci´on del proyecto. . . . . . . . . . 6 2.3. EDT de segundo nivel. Formaci´on. . . . . . . . . . . . . . . . . . 7 2.4. EDT de segundo nivel. An´alisis. . . . . . . . . . . . . . . . . . . . 7 2.5. EDT de segundo nivel. Primer sprint: BD de modelos, datasets y usuarios ................................ 8 2.6. EDT de segundo nivel. Segundo sprint: m´odulo de EIT . . . . . . 8 2.7. EDT de segundo nivel. Tercer sprint: API REST . . . . . . . . . . 8 2.8. EDT de segundo nivel. Cuarto sprint: interfaz gr´afica . . . . . . . 9 2.9. Diagrama de gantt. Planificaci´on. . . . . . . . . . . . . . . . . . . 10 2.10. Diagrama de gantt. An´alisis y dise˜no de alto nivel. . . . . . . . . . 10 2.11. Diagrama de gantt. Formaci´on. . . . . . . . . . . . . . . . . . . . 10 2.12. Diagrama de gantt. Incremento 1. . . . . . . . . . . . . . . . . . . 11 2.13. Diagrama de gantt. Incremento 2. . . . . . . . . . . . . . . . . . . 11 2.14. Diagrama de gantt. Incremento 3. . . . . . . . . . . . . . . . . . . 11 2.15. Diagrama de gantt. Incremento 4. . . . . . . . . . . . . . . . . . . 11 2.16. Diagrama de gantt. Elaboraci´on de memoria y fin de TFG. . . . . 12 3.1. Diagrama de casos de uso. . . . . . . . . . . . . . . . . . . . . . . 45 5.1. Diagrama de arquitectura. . . . . . . . . . . . . . . . . . . . . . . 67 5.2. Diagrama de clases del m´odulo de acceso a BD. . . . . . . . . . . 69 5.3. Diagrama de clases del m´odulo de EIT. . . . . . . . . . . . . . . . 70 5.4. Diagrama de secuencia: reconstrucci´on de la de la imagen de la malla de un dataset. ......................... 73 5.5. Diagrama de secuencia: realizaci´on de predicciones de un conjunto devoltajes. .............................. 74 5.6. Diagrama de secuencia: entrenamiento de una red neuronal. . . . 75 5.7. Diagrama de secuencia: comparaci´on de varios modelos. . . . . . . 77 5.8. Diagrama de secuencia: generaci´on de un dataset. ......... 78 5.9. Diagrama de clases del frontend.................... 82 5.10. Vista principal de la aplicaci´on. . . . . . . . . . . . . . . . . . . . 85 vi 5.11. Selecci´on de la operaci´on a realizar en la secci´on de Reconstrucci´on de im´agenes............................... 86 5.12. Vista de selecci´on de dataset y malla (I). . . . . . . . . . . . . . . 87 5.13. Vista de selecci´on de dataset y malla (II). . . . . . . . . . . . . . 88 5.14. Vista de imagen reconstruida. . . . . . . . . . . . . . . . . . . . . 89 5.15. Vista de corte de una malla. . . . . . . . . . . . . . . . . . . . . . 90 5.16. Vista de las predicciones de conductividades a partir de un conjuntodevoltajes. ........................... 91 5.17. Vista del listado de modelos disponibles. . . . . . . . . . . . . . . 92 5.18. Vista de los detalles de una red neuronal. . . . . . . . . . . . . . . 93 5.19. Vista de una matriz de confusi´on. . . . . . . . . . . . . . . . . . . 94 5.20. Vista de la definici´on de los par´ametros de la comparaci´on de modelos................................... 95 5.21. Vista de los resultados de la comparaci´on de modelos (1). . . . . . 96 5.22. Vista de los resultados de la comparaci´on de modelos (2). . . . . . 96 5.23. Vista de selecci´on de tipo de modelo para entrenamiento. . . . . . 97 5.24. Vista de la definici´on de par´ametros para el entrenamiento de una redneuronal. ............................. 98 5.25. Vista de la informaci´on detallada de un dataset. .......... 100 5.26. Vista de la informaci´on detallada de un dataset. .......... 100 5.27. Vista de generaci´on de dataset. ................... 101 5.28. Vista de selecci´on del tipo de tarea. . . . . . . . . . . . . . . . . . 102 5.29. Vista de selecci´on del tipo de tarea. . . . . . . . . . . . . . . . . . 103 6.1. Arquitectura de una red neuronal [28]. . . . . . . . . . . . . . . . 106 6.2. C´alculo de la salida de una neurona. . . . . . . . . . . . . . . . . 107 6.3. Reconstrucci´on mediante una DNN. . . . . . . . . . . . . . . . . . 109 6.4. ´ Arbolderegresi´on. .......................... 109 6.5. Reconstrucci´on mediante un Random Forest............. 112 6.6. Hiperplano en un espacio bidimensional [29] . . . . . . . . . . . . 113 6.7. Reconstrucci´on mediante una SVM. . . . . . . . . . . . . . . . . . 114 6.8. Reconstrucci´on de la imagen de una malla mediante una DNN (modelo 97), un Random Forest (modelo 135) y una SVM (modelo 137) .................................. 115 vii ´ Indice de cuadros 2.1. Costes de los diferentes roles (e). .................. 14 2.2. Costes totales de los diferentes roles (e)............... 14 2.3. Amortizaci´on de equipos electr´onicos. . . . . . . . . . . . . . . . . 15 2.4. Coste total (e)............................. 16 2.5. Categor´ıas de probabilidad. . . . . . . . . . . . . . . . . . . . . . 18 2.6. Categor´ıas de impacto. . . . . . . . . . . . . . . . . . . . . . . . . 18 2.7. Listaderiesgos............................. 21 2.8. Matriz de probabilidad-impacto. . . . . . . . . . . . . . . . . . . . 21 2.9. Planificaci´on de los riesgos cr´ıticos. . . . . . . . . . . . . . . . . . 24 2.10. Supervisi´on de los riesgos cr´ıticos. . . . . . . . . . . . . . . . . . . 25 3.1. Requisito funcional RF1. . . . . . . . . . . . . . . . . . . . . . . . 27 3.2. Requisito funcional RF2. . . . . . . . . . . . . . . . . . . . . . . . 27 3.3. Requisito funcional RF3. . . . . . . . . . . . . . . . . . . . . . . . 27 3.4. Requisito funcional RF4. . . . . . . . . . . . . . . . . . . . . . . . 27 3.5. Requisito funcional RF5. . . . . . . . . . . . . . . . . . . . . . . . 28 3.6. Requisito funcional RF6. . . . . . . . . . . . . . . . . . . . . . . . 28 3.7. Requisito funcional RF7. . . . . . . . . . . . . . . . . . . . . . . . 29 3.8. Requisito funcional RF8. . . . . . . . . . . . . . . . . . . . . . . . 30 3.9. Requisito funcional RF9. . . . . . . . . . . . . . . . . . . . . . . . 30 3.10. Requisito funcional RF10. . . . . . . . . . . . . . . . . . . . . . . 31 3.11. Requisito funcional RF11. . . . . . . . . . . . . . . . . . . . . . . 31 3.12. Requisito funcional RF12. . . . . . . . . . . . . . . . . . . . . . . 32 3.13. Requisito funcional RF13. . . . . . . . . . . . . . . . . . . . . . . 32 3.14. Requisito funcional RF14. . . . . . . . . . . . . . . . . . . . . . . 33 3.15. Requisito funcional RF15. . . . . . . . . . . . . . . . . . . . . . . 33 3.16. Requisito funcional RF16. . . . . . . . . . . . . . . . . . . . . . . 34 3.17. Requisito funcional RF17. . . . . . . . . . . . . . . . . . . . . . . 34 3.18. Requisito funcional RF18. . . . . . . . . . . . . . . . . . . . . . . 34 3.19. Requisito funcional RF19. . . . . . . . . . . . . . . . . . . . . . . 35 3.20. Requisito funcional RF20. . . . . . . . . . . . . . . . . . . . . . . 35 3.21. Requisito funcional RF21. . . . . . . . . . . . . . . . . . . . . . . 35 3.22. Requisito funcional RF22. . . . . . . . . . . . . . . . . . . . . . . 35 3.23. Requisito funcional RF23. . . . . . . . . . . . . . . . . . . . . . . 36 viii Cap´ıtulo 2 Planificaci´on y presupuestos En este cap´ıtulo se presentar´a la planificaci´on propuesta para la realizaci´on del TFG, la cual constar´a de tres bloques: la planificaci´on temporal, la gesti´on de costes y la gesti´on de riesgos. Para ejecutar con ´exito las tareas asociadas a estos tres bloques, se tomar´a como referencia la gu´ıa del PMBOK (Project Management Body of Knowledge) [2]. La gu´ıa del PMBOK contiene las pr´acticas recomendadas para gestionar de forma eficaz un proyecto. 2.1. Planificaci´on temporal La planificaci´on temporal del TFG consistir´a en el desarrollo de su cronograma. Se llevar´an a cabo los siguientes procesos recomendados por el PMBOK: Definici´on de las actividades. Secuenciaci´on de las actividades. Estimaci´on de la duraci´on de las actividades. 2.1.1. Ciclo de vida Antes de realizar las tareas asociadas a los tres procesos anteriores, es preciso seleccionar un ciclo de vida que se adec´ue a las caracter´ısticas del proyecto. A pesar de que los requisitos del proyecto son claros, existe un alto nivel de incertidumbre en lo relativo a la integraci´on de las tecnolog´ıas que se emplear´an en la fase de implementaci´on, desconoci´endose previamente si esta integraci´on se podr´a llevar a cabo sin dificultades. Considerando el escenario anterior, se ha optado por emplear un ciclo de vida incremental. El ciclo de vida incremental consta de una fase de an´alisis y de una fase de dise˜no gen´ericas y de fases de dise˜no y codificaci´on espec´ıficas en cada uno de los incrementos que se definan. Un enfoque habitual para ejecutar el ciclo 5 CAP´ ITULO 2. PLANIFICACI ´ ON Y PRESUPUESTOS 6 de vida incremental consiste en asociar una serie de requisitos a cada incremento, de forma que tras la finalizaci´on del incremento, se incorporen al software nuevas funcionalidades completamente operativas. Sin embargo, el enfoque que se adoptar´a en este proyecto ser´a ligeramente diferente, puesto que cada incremento estar´a asociado a un m´odulo del sistema, el cual deber´a ser integrado con los m´odulos desarrollados hasta ese momento. 2.1.2. EDT La EDT (Estructura de Descomposici´on del Trabajo) permite subdividir los entregables del proyecto en componentes m´as peque˜nos, los cuales son m´as f´aciles de gestionar. Mediante la EDT, se ejecutar´a el proceso de definici´on de las actividades, propuesto por el PMBOK. Figura 2.1: EDT de primer nivel. En la figura 2.1 se muestra la EDT de primer nivel para el TFG. Como se puede observar, se han definido cuatro incrementos para el desarrollo del proyecto. Las actividades del diagrama anterior se han explotado en EDTs de segundo y tercer nivel (exceptuando las actividades de Dise˜no de alto nivel yElaboraci´on de la memoria), tal y como se puede ver en las figuras 2.2, 2.3, 2.4, 2.5, 2.6, 2.7 y 2.8. Figura 2.2: EDT de segundo nivel. Planificaci´on del proyecto. CAP´ ITULO 2. PLANIFICACI ´ ON Y PRESUPUESTOS 7 Figura 2.3: EDT de segundo nivel. Formaci´on. Figura 2.4: EDT de segundo nivel. An´alisis. CAP´ ITULO 2. PLANIFICACI ´ ON Y PRESUPUESTOS 8 Figura 2.5: EDT de segundo nivel. Primer sprint: BD de modelos, datasets y usuarios Figura 2.6: EDT de segundo nivel. Segundo sprint: m´odulo de EIT Figura 2.7: EDT de segundo nivel. Tercer sprint: API REST CAP´ ITULO 2. PLANIFICACI ´ ON Y PRESUPUESTOS 9 Figura 2.8: EDT de segundo nivel. Cuarto sprint: interfaz gr´afica 2.1.3. Diagrama de Gantt Una vez que se han definido las actividades de las que constar´a el proyecto, es necesario secuenciarlas y definir su duraci´on. Para ello, se ha elaborado un diagrama de Gantt. Cabe se˜nalar que el anteproyecto de este TFG fue aprobado a principios del mes de marzo de 2020. No obstante, debido a la situaci´on familiar del alumno derivada de la crisis del coronavirus, el proyecto no pudo iniciarse en ese mismo mes. El 5 de junio de 2020, la Secretar´ıa Xeral de la USC public´o la Instrucci´on 4/2020 [3], en la cual se establec´ıa que el alumnado de la USC pod´ıa solicitar el aplazamiento de la entrega del TFG por causas derivadas del coronavirus y, en caso de que dicha solicitud fuese aprobada, el TFG podr´ıa ser entregado fuera de plazo ordinario. El alumno realiz´o la solicitud y comenz´o el TFG en el mes de junio de 2020. La planificaci´on temporal propuesta en este apartado se realiz´o suponiendo que la solicitud del alumno ser´ıa aceptada y que, por tanto, podr´ıa entregar el TFG fuera del plazo ordinario, tal y como finalmente aconteci´o. En el apartado de gesti´on de riesgos (apartado 2.3) se incluy´o un riesgo que contempla la posibilidad de que la solicitud de aplazamiento del alumno no fuese aceptada. En el diagrama de Gantt que se muestra a continuaci´on, no s´olo se refleja el orden y la duraci´on de las tareas a realizar, sino tambi´en la fecha de realizaci´on y el rol que desempe˜na el alumno en cada una de las tareas. Con el prop´osito de facilitar su visualizaci´on, se ha dividido el diagrama de Gantt en diferentes bloques, los cuales se muestran en las figuras 2.9, 2.10, 2.11, 2.12, 2.13, 2.14, 2.15 y 2.16. CAP´ ITULO 2. PLANIFICACI ´ ON Y PRESUPUESTOS 10 Figura 2.9: Diagrama de gantt. Planificaci´on. Figura 2.10: Diagrama de gantt. An´alisis y dise˜no de alto nivel. Figura 2.11: Diagrama de gantt. Formaci´on. CAP´ ITULO 2. PLANIFICACI ´ ON Y PRESUPUESTOS 11 Figura 2.12: Diagrama de gantt. Incremento 1. Figura 2.13: Diagrama de gantt. Incremento 2. Figura 2.14: Diagrama de gantt. Incremento 3. Figura 2.15: Diagrama de gantt. Incremento 4. CAP´ ITULO 2. PLANIFICACI ´ ON Y PRESUPUESTOS 12 Figura 2.16: Diagrama de gantt. Elaboraci´on de memoria y fin de TFG. CAP´ ITULO 2. PLANIFICACI ´ ON Y PRESUPUESTOS 13 2.2. Gesti´on de costes 2.2.1. Costes de los recursos humanos En el desarrollo del TFG participan tres personas: el alumno y los dos tutores. Los tutores ser´an considerados clientes, de manera que no tienen ning´un coste asociado. Para calcular el coste relativo a las horas trabajadas por el alumno, se tendr´an en consideraci´on los roles que desempe˜n´o en las diferentes tareas de las que consta el proyecto: director de proyecto, arquitecto de software, analista y programador. Se ha decidido tener en cuenta estos diferentes roles con el prop´osito de realizar una estimaci´on lo m´as realista posible de un proyecto de Ingenier´ıa de Software. En el diagrama de Gantt (figuras 2.9, 2.10, 2.11, 2.12, 2.13, 2.14, 2.15 y 2.16) se muestra qu´e rol desempe˜na el alumno para cada tarea. Para estimar el coste de cada rol, se utilizar´a el estudio salarial sobre el sector TIC en Galicia elaborado por la consultora Vitae [4]. Siguiendo este informe, se supondr´a que los sueldos brutos anuales del director de proyecto, del arquitecto de software, del analista y del programador son 36000 e, 29000 e, 18000 ey 16000 e, respectivamente. Por otra parte, se supondr´a que los costes asociados a la Seguridad Social son del 33 % para todos los roles. Por tanto, para obtener el coste total anual de cada rol, se multiplicar´a su sueldo bruto anual por un factor de 1.33. Una vez que se hayan calculado los costes totales anuales para los diferentes roles, es preciso calcular cu´al es el coste por hora de cada rol. Para ello, se debe dividir el coste total anual entre el n´umero de horas que cada rol trabajar´ıa en un a˜no a jornada completa. Para estimar cu´al es el n´umero de horas anuales, se emplear´a el XIX Convenio colectivo del sector de empresas de ingenier´ıa y oficinas de estudios t´ecnicos, disponible en el BOE [5]. Seg´un el anterior convenio, el n´umero m´aximo de horas anuales en jornada ordinaria para cada uno de los cuatro roles mencionados es de 1792 horas. En la la tabla 2.1 se muestran los resultados obtenidos realizando los c´alculos explicados a lo largo de este apartado. CAP´ ITULO 2. PLANIFICACI ´ ON Y PRESUPUESTOS 14 Rol Sueldo bruto anual Coste total anual Coste / hora Director de proyecto 36000 47880 26.72 Arquitecto de software 29000 38570 21.52 Analista 18000 23940 13.36 Programador 16000 21280 11.88 Cuadro 2.1: Costes de los diferentes roles (e). El coste total asociado a los recursos humanos se obtiene multiplicando el coste/hora de cada rol por el n´umero de horas que el alumno trabaja desempe˜nando ese rol. El n´umero de horas trabajadas por el alumno para cada rol puede consultarse en el diagrama de Gantt. En la tabla 2.2 se muestra el coste total para el proyecto que supone cada uno de los roles. Rol Node horas trabajadas Coste / hora Coste total Director de proyecto 35.5 26.72 948.52 Arquitecto de software 76 21.52 1635.78 Analista 131 13.36 1750.08 Programador 172.5 11.88 2048.44 Cuadro 2.2: Costes totales de los diferentes roles (e). Por tanto, el coste total asociado al trabajo del alumno es: 948.52 + 1635.78 + 1750.08 + 2048.44 = 6382.81 e 2.2.2. Costes de los recursos materiales Tal y como se explicar´a en el cap´ıtulo 4, las tecnolog´ıas y herramientas software empleadas para el proyecto son libres, de forma que su uso no supone ning´un coste. Por tanto, el ´unico recurso material cuya utilizaci´on implica un coste para el proyecto es el ordenador port´atil con el que se ha realizado todo el trabajo. CAP´ ITULO 2. PLANIFICACI ´ ON Y PRESUPUESTOS 21 RSG8 Dificultad para replicar los experimentos del art´ıculo de referencia Los experimentos realizados en el art´ıculo utilizado como punto de partida para realizar este TFG tienen un cierto grado de complejidad, por lo que el alumno podr´ıa necesitar m´as horas de las previstas para replicarlos y comprender su funcionamiento. Media Tolerable RSG9 Rechazo de la solicitud de aplazamiento por parte de la Secretar´ıa Xeral de la USC Tal y como se explic´o en el apartado 2.1.3, la planificaci´on para el TFG ha sido elaborada con el prop´osito de presentar el proyecto fuera de plazo ordinario, como consecuencia de la situaci´on personal del alumno (al amparo de la Instrucci´on 4/2020 de la Secretar´ıa Xeral). No obstante, la solicitud enviada por el alumno debe ser aprobada por la propia Secretar´ıa Xeral. En caso de que dicha solicitud fuese rechazada, el TFG no podr´ıa presentarse en el curso acad´emico 2019/2020. Baja Catastr´ofico Cuadro 2.7: Lista de riesgos. A continuaci´on, se muestra una matriz de probabilidad-impacto. En la regi´on marcada en color naranja se encuentran los riesgos cr´ıticos para el TFG. Alta RSG3 RSG1,RSG4 Media RSG8 RSG7 Baja RSG6 RSG5 RSG2, RSG9 Insignificante Tolerable Serio Catastr´ofico Probabilidad Impacto Cuadro 2.8: Matriz de probabilidad-impacto. CAP´ ITULO 2. PLANIFICACI ´ ON Y PRESUPUESTOS 22 2.3.3. Planificaci´on de riesgos Una vez que se han identificado y analizado los riesgos que pueden afectar al TFG, se definir´an las estrategias para tratar los riesgos que se encuentran en la regi´on naranja de la matriz de probabilidad-impacto. RSG1 Problemas de compatibilidad entre la biblioteca EIDORS, Matlab y Python Tipo de estrategia Prevenci´on y contingencia. Descripci´on Antes de iniciar la fase de codificaci´on, se realizar´a un an´alisis de diferentes frameworks que permitan ejecutar funciones de Matlab desde Python. Las pruebas a realizar consistir´an en la ejecuci´on de diferentes funciones de la biblioteca EIDORS desde Python, utilizando cada uno de los frameworks considerados. Se seleccionar´a el framework mediante el cual se obtenga un menor n´umero de llamadas fallidas a funciones. En caso de que no se encuentre ning´un framework que proporcione un grado de compatibilidad aceptable, las llamadas a Matlab desde Python se realizar´an mediante la ejecuci´on scripts. RSG2 Imposibilidad de acceder al trabajo realizado Tipo de estrategia Evitaci´on. Descripci´on El alumno crear´a la carpeta TFG AllerDominguez en un directorio de su equipo sincronizado con una cuenta de Dropbox, utilizando la versi´on gratuita. En esta carpeta almacenar´a todos los ficheros correspondientes al TFG. En caso de que se corrompa el equipo del alumno, podr´a acceder igualmente al trabajo realizado a trav´es de su cuenta de Dropbox, empleando cualquier otro equipo. Esta carpeta estar´a sincronizada con sendas carpetas de los codirectores, con lo que se triplican los almacenamientos f´ısicos eliminando as´ı el riesgo. RSG3 Tiempo de formaci´on superior al estimado Tipo de estrategia Minimizaci´on CAP´ ITULO 2. PLANIFICACI ´ ON Y PRESUPUESTOS 23 Descripci´on La planificaci´on se realizar´a de tal forma que se dejar´a libre la ´ultima semana de junio. En caso de que durante las actividades de formaci´on se detecte que el tiempo necesario es superior al estimado, se podr´a retrasar la planificaci´on hasta una semana, obteniendo as´ı el tiempo adicional necesario para la formaci´on. RSG4 Poca disponibilidad temporal por parte de los tutores Tipo de estrategia Minimizaci´on Descripci´on En las semanas en las que no se pueda llevar a cabo la reuni´on prevista con ambos tutores por los compromisos de ´estos, se realizar´a una reuni´on a trav´es de Skype en horario de tarde, atendiendo a la disponibilidad de los tutores. De esta forma, los dos tutores podr´an participar simult´aneamente en la reuni´on. Por otra parte, la carpeta de Dropbox utilizada por el alumno para almacenar la documentaci´on y el c´odigo del TFG ser´a compartida con ambos tutores, pudiendo acceder al trabajo del alumno cuando lo deseen, de manera que se puedan mantener informados en todo momento de cu´al el progreso del alumno. RSG7 Eliminaci´on accidental de un archivo o directorio Tipo de estrategia Contingencia y minimizaci´on. Descripci´on Si el alumno detecta la p´erdida de los archivos en un plazo igual o inferior a 30 d´ıas, podr´a recuperarlos accediendo a su cuenta de Dropbox desde un navegador. En caso de que hayan transcurrido m´as de 30 d´ıas, esta opci´on no ser´a posible, por lo que se har´a uso de backups para disponer de una copia de los archivos. Se realizar´a un backup completo semanalmente del directorio que contiene los ficheros del TFG. El alumno almacenar´a dicho backup en un disco duro externo. De esta forma, si detecta que se ha eliminado un archivo hace m´as de 30 d´ıas, podr´a recuperarlo a trav´es del backup almacenado en el disco duro externo. CAP´ ITULO 2. PLANIFICACI ´ ON Y PRESUPUESTOS 24 RSG9 Rechazo de la solicitud de aplazamiento por parte de la Secretar´ıa Xeral de la USC Tipo de estrategia Minimizaci´on y contingencia. Descripci´on Por un lado, se utilizar´a una estrategia de minimizaci´on con el prop´osito de reducir la probabilidad de que la solicitud de aplazamiento del alumno sea rechazada. Para ello, en la solicitud que el alumno env´ıe a la Secretar´ıa Xeral, se adjuntar´a en formato PDF la documentaci´on que acredita la situaci´on personal y familiar del alumno. En caso de que la estrategia de minimizaci´on no funcione y se rechace la solicitud, se utilizar´a un plan de contingencia, consistente en la reelaboraci´on de la planificaci´on del proyecto, con el prop´osito de presentarlo en el mes de febrero de 2021. Cuadro 2.9: Planificaci´on de los riesgos cr´ıticos. 2.3.4. Supervisi´on de riesgos En este apartado se definir´an indicadores para los riesgos que se tratar´an mediante estrategias de minimizaci´on y de contingencia. Para cada indicador, se definir´a un umbral, de manera que, si el valor del indicador alcanza o supera el umbral establecido, se considerar´a que la probabilidad de que acontezca el riesgo inminentemente es elevada. RSG3 Tiempo de formaci´on superior al estimado Indicador Cociente entre el n´umero de horas planificadas para las actividades de formaci´on realizadas hasta el momento y el n´umero de horas reales necesitadas. Si se alcanza un valor igual o inferior al umbral, se considera que existe una probabilidad elevada de que se produzca el riesgo. Umbral Valor del cociente de 0.85 RSG4 Poca disponibilidad temporal por parte de los tutores Indicador N´umero de reuniones consecutivas canceladas o a las que alguno de los tutores no ha podido asistir. Umbral 3 reuniones. CAP´ ITULO 2. PLANIFICACI ´ ON Y PRESUPUESTOS 25 RSG5 Funcionamiento incorrecto de la biblioteca EIDORS Indicador N´umero de errores irresolubles en las llamadas a funciones de EIDORS. Umbral 5 errores RSG7 Eliminaci´on accidental de un archivo o directorio Indicador N´umero de archivos eliminados de forma accidental. Umbral 3 archivos eliminados accidentalmente. Cuadro 2.10: Supervisi´on de los riesgos cr´ıticos. Para el riesgo RSG9 (rechazo de la solicitud de aplazamiento por parte de la Secretar´ıa Xeral de la USC), a pesar de utilizar una estrategia de minimizaci´on, no se incluyen indicadores, puesto que no existen factores externos analizables por parte del alumno que permitan predecir la decisi´on que tome finalmente la Secretar´ıa Xeral. Cap´ıtulo 3 Especificaci´on de requisitos y casos de uso Un requisito puede definirse como una condici´on o capacidad que necesita el usuario para resolver un problema o conseguir un objetivo determinado. En este apartado se describir´an los requisitos funcionales, los requisitos no funcionales y los requisitos de informaci´on del sistema a desarrollar. Por otro lado, a partir de los requisitos funcionales, se definir´an los casos de uso m´as relevantes de la aplicaci´on. Adem´as de la descripci´on, para cada requisito se han incluido dos atributos adicionales: Importancia. Indica el inter´es que tiene un requisito para el cliente del proyecto (se considerar´a que tanto el tutor como el cotutor son los clientes del proyecto). Este atributo podr´a adoptar los siguientes valores: •Normal. El cliente lo pide y lo necesita. •Esperado. El cliente no lo pide, pero lo necesita. •Estimulante. El cliente no lo pide, pero la inclusi´on del requisito en el sistema le resulta satisfactoria. Estabilidad. Indica la probabilidad de que un requisito cambie a lo largo del tiempo. Puede adoptar tres valores: baja, media, alta. 3.1. Requisitos funcionales Los requisitos funcionales definen las funcionalidades que implementar´a la aplicaci´on. Se han identificado 23 requisitos funcionales. 26 CAP´ ITULO 3. ESPECIFICACI ´ ON DE REQUISITOS Y CASOS DE USO 27 RF1 Iniciar sesi´on Descripci´on El sistema deber´a permitir a un usuario iniciar sesi´on introduciendo su nombre de usuario y su contrase˜na. Importancia Esperado Estabilidad Alta Cuadro 3.1: Requisito funcional RF1. RF2 Cerrar sesi´on Descripci´on El sistema deber´a permitir a un usuario cerrar una sesi´on abierta, regresando a la pantalla de inicio. Importancia Esperado Estabilidad Alta Cuadro 3.2: Requisito funcional RF2. RF3 Registrar nuevo usuario Descripci´on El sistema permitir´a a un usuario registrarse en el sistema, introduciendo los siguientes datos: nickname, contrase˜na, correo electr´onico, nombre y apellidos. Una vez que el usuario haya cubierto y enviado el formulario de registro, se enviar´a le un correo de forma autom´atica para que confirme su registro. Importancia Esperado Estabilidad Alta Cuadro 3.3: Requisito funcional RF3. RF4 Editar usuario Descripci´on El sistema permitir´a a un usuario editar la siguiente informaci´on de su cuenta: contrase˜na, correo electr´onico, nombre y apellidos. Importancia Esperado Estabilidad Media Cuadro 3.4: Requisito funcional RF4. CAP´ ITULO 3. ESPECIFICACI ´ ON DE REQUISITOS Y CASOS DE USO 28 RF5 Eliminar usuario Descripci´on El sistema permitir´a a un administrador eliminar a un usuario registrado, de manera que todos sus datos ser´an borrados del sistema. Importancia Esperado Estabilidad Alta Cuadro 3.5: Requisito funcional RF5. RF6 Entrenar red neuronal Descripci´on El sistema permitir´a a un usuario entrenar una red neuronal. El usuario podr´a introducir o seleccionar los siguientes par´ametros del modelo: Dataset con el que desea entrenar el modelo. N´umero de capas ocultas. N´umero de neuronas en cada una de las capas ocultas. Funci´on de activaci´on de las capas ocultas. Funci´on de activaci´on de la capa de salida. Tama˜no de los lotes. Learning rate. Momentum. Visibilidad del modelo (p´ublico o privado). M´etricas que desea emplear para evaluar el modelo. Importancia Esperado Estabilidad Media Cuadro 3.6: Requisito funcional RF6. CAP´ ITULO 3. ESPECIFICACI ´ ON DE REQUISITOS Y CASOS DE USO 29 RF7 Entrenar random forest Descripci´on El sistema permitir´a a un usuario entrenar un random forest. El usuario podr´a introducir o seleccionar los siguientes par´ametros del modelo. Dataset con el que desea entrenar el modelo. N´umero de estimadores empleados. Profundidad m´axima de cada rama. N´umero m´ınimo de muestras necesarias para dividir un nodo interno. N´umero m´ınimo de muestras necesarias para que un nodo pueda ser nodo hoja. Visibilidad del modelo. M´etricas que desea emplear para evaluar el modelo. Importancia Esperado Estabilidad Media Cuadro 3.7: Requisito funcional RF7. CAP´ ITULO 3. ESPECIFICACI ´ ON DE REQUISITOS Y CASOS DE USO 30 RF8 Entrenar m´aquina de soporte vectorial Descripci´on El sistema permitir´a a un usuario entrenar una m´aquina de soporte vectorial. El usuario podr´a introducir o seleccionar los siguientes par´ametros del modelo: Dataset con el que desea entrenar el modelo. Kernel. Grado. Esta informaci´on s´olo ser´a relevante en caso de emplear un kernel de tipo polin´omico. Gamma. Coeficiente 0. Tolerancia. Constante C. Epsilon. Visibilidad del modelo. M´etricas que desea emplear para evaluar el modelo. Importancia Esperado Estabilidad Media Cuadro 3.8: Requisito funcional RF8. RF9 Almacenar modelo Descripci´on El sistema permitir´a a un usuario almacenar un modelo entrenado, de forma que dicho modelo pueda ser utilizado posteriormente para reconstruir la imagen de un cuerpo. Importancia Normal Estabilidad Media Cuadro 3.9: Requisito funcional RF9. CAP´ ITULO 3. ESPECIFICACI ´ ON DE REQUISITOS Y CASOS DE USO 37 RNF-1 Software libre Descripci´on El sistema a desarrollar deber´a dise˜narse e implementarse utilizando ´unicamente herramientas y tecnolog´ıas de uso libre. Importancia Normal Estabilidad Alta Cuadro 3.25: Requisito no funcional RNF1. RNF-2 Restricci´on en las eliminaciones Descripci´on Un usuario no podr´a nunca eliminar los modelos y datasets generados por otro usuario. Importancia Normal Estabilidad Alta Cuadro 3.26: Requisito funcional RNF2. RNF-3 Usabilidad Descripci´on El sistema deber´a obtener una puntuaci´on media igual o superior a 4/5 en el test de usabilidad definido en el apartado 7.2.1 , tras ser evaluado por al menos cuatro usuarios. Importancia Estimulante Estabilidad Alta Cuadro 3.27: Requisito funcional RNF3. 3.3. Requisitos de informaci´on Los requisitos de informaci´on indican qu´e datos se guardar´an en almacenamiento persistente. Se han identificado nueve requisitos de informaci´on. CAP´ ITULO 3. ESPECIFICACI ´ ON DE REQUISITOS Y CASOS DE USO 38 RI1 Usuario Descripci´on El sistema deber´a almacenar la siguiente informaci´on sobre cada usuario: Nombre de usuario. Contrase˜na resumida mediante la funci´on hash SHA256. Correo electr´onico. Tipo de usuario. Nombre completo. Importancia Esperado Estabilidad Alta Cuadro 3.28: Requisito funcional RI1. CAP´ ITULO 3. ESPECIFICACI ´ ON DE REQUISITOS Y CASOS DE USO 39 RI2 Modelo gen´erico Descripci´on El sistema deber´a incluir la siguiente informaci´on sobre cada modelo almacenado: Identificador. Tipo. Fecha y hora de inicio de entrenamiento. Fecha y hora de finalizaci´on de entrenamiento. Creador. Es el usuario que ha generado el modelo. Path. Es el directorio en el que se encuentra el binario del modelo. Dataset. Es el identificador del dataset utilizado para entrenar el modelo. Umbral de postprocesado. Es el valor calculado mediante la t´ecnica de las curvas ROC que se utilizar´a para aplicar postprocesado en las predicciones realizadas con el modelo (v´ease apartado 6.3). Importancia Normal Estabilidad Alta Cuadro 3.29: Requisito funcional RI2. CAP´ ITULO 3. ESPECIFICACI ´ ON DE REQUISITOS Y CASOS DE USO 40 RI3 Modelo de red neuronal Descripci´on El sistema deber´a incluir la siguiente informaci´on sobre cada modelo de red neuronal almacenado: Identificador del modelo gen´erico al cual est´a asociado. N´umero de capas ocultas. N´umero de neuronas en cada una de las capas ocultas. Funci´on de activaci´on de las capas ocultas. Funci´on de activaci´on de la capa de salida. Tama˜no de los lotes. Learning rate. Momentum. Archivo binario con la arquitectura de la red. Archivo binario con los pesos de la red. Importancia Esperado Estabilidad Media Cuadro 3.30: Requisito funcional RI3. CAP´ ITULO 3. ESPECIFICACI ´ ON DE REQUISITOS Y CASOS DE USO 41 RI4 Modelo de random forest Descripci´on El sistema deber´a incluir la siguiente informaci´on sobre cada modelo de random forest almacenado: Identificador del modelo gen´erico al cual est´a asociado. N´umero de estimadores empleados. Profundidad m´axima de cada rama. N´umero m´ınimo de muestras necesarias para dividir un nodo interno. N´umero m´ınimo de muestras necesarias para que un nodo pueda ser nodo hoja. Path del fichero binario que contiene el modelo entrenado. Importancia Esperado Estabilidad Media Cuadro 3.31: Requisito funcional RI4. CAP´ ITULO 3. ESPECIFICACI ´ ON DE REQUISITOS Y CASOS DE USO 42 RI5 Modelo de m´aquina de soporte vectorial Descripci´on El sistema deber´a incluir la siguiente informaci´on sobre cada modelo de m´aquina de soporte vectorial almacenado: Identificador del modelo gen´erico al cual est´a asociado. Kernel. Grado. Esta informaci´on s´olo ser´a relevante en caso de emplear un kernel de tipo polin´omico. Gamma. Coeficiente 0. Tolerancia. Constante C. Epsilon. Path del fichero binario que contiene el modelo entrenado. Importancia Esperado Estabilidad Media Cuadro 3.32: Requisito funcional RI5. CAP´ ITULO 3. ESPECIFICACI ´ ON DE REQUISITOS Y CASOS DE USO 43 RI6 Dataset Descripci´on El sistema deber´a almacenar la siguiente informaci´on sobre cada dataset: Identificador. Semilla de generaci´on. Radio m´ınimo de los artefactos. Radio m´aximo de los artefactos. Visibilidad. Importancia Normal Estabilidad Media Cuadro 3.33: Requisito funcional RI6. RI7 Malla Descripci´on El sistema deber´a almacenar la siguiente informaci´on sobre cada malla: Identificador del dataset al que pertenece. ´ Indice de la malla. N´umero de artefactos contenidos por la malla. Voltajes. Impedancias. Importancia Normal Estabilidad Media Cuadro 3.34: Requisito funcional RI7. CAP´ ITULO 3. ESPECIFICACI ´ ON DE REQUISITOS Y CASOS DE USO 44 RI8 M´etrica Descripci´on El sistema deber´a incluir la siguiente informaci´on sobre cada m´etrica almacenada: Identificador del modelo gen´erico al que est´a asociada la m´etrica. Nombre de la m´etrica. Valor de la m´etrica. Importancia Estimulante Estabilidad Media Cuadro 3.35: Requisito funcional RI8. RI9 Matriz de confusi´on Descripci´on El sistema deber´a incluir la siguiente informaci´on sobre cada matriz de confusi´on almacenada: Identificador del modelo gen´erico al que est´a asociada la matriz de confusi´on. N´umero de verdaderos negativos. N´umero de verdaderos positivos. N´umero de falsos negativos. N´umero de falsos positivos. Importancia Estimulante Estabilidad Media Cuadro 3.36: Requisito funcional RI9. CAP´ ITULO 3. ESPECIFICACI ´ ON DE REQUISITOS Y CASOS DE USO 45 3.4. Casos de uso Un caso de uso puede definirse como un conjunto de secuencias de acciones que ejecuta un sistema para producir un resultado observable de valor para un actor. En este apartado se describir´an los casos de uso del sistema de mayor importancia. Para cada caso de uso se incluir´a un escenario principal y, en algunos de los casos de uso, se describir´an ciertos escenarios alternativos. 3.4.1. Diagrama de casos de uso Figura 3.1: Diagrama de casos de uso. CAP´ ITULO 3. ESPECIFICACI ´ ON DE REQUISITOS Y CASOS DE USO 46 En la figura 3.1 se muestra un diagrama de casos de uso, el cual incluye los principales casos de uso del sistema. Se ha incluido una relaci´on de generalizaci´on entre los casos de uso Entrenar red neuronal, Entrenar ´arbol de decisi´on y Entrenar m´aquina de soporte vectorial con el caso de uso Entrenar modelo, puesto que los tres primeros son casos espec´ıficos del ´ultimo. Entre algunos de los casos de uso identificados existen relaciones de inclusi´on. Esto sucede cuando un caso de uso incorpora el comportamiento de otro. Por ejemplo, el caso de uso Eliminar modelo incluye al caso de uso Consultar modelos ya que para eliminar un modelo es preciso realizar previamente una consulta de los modelos almacenados en el sistema, de manera que ejecutar el caso de uso Eliminar modelo implica necesariamente ejecutar el caso de uso Consultar modelos. 3.4.2. Descripci´on de los casos de uso En este apartado se describir´an con detalle los casos de uso m´as importantes del diagrama de casos de uso del apartado anterior. Caso de uso CU1: Registrarse Prop´osito: crear una cuenta para un nuevo usuario en el sistema y almacenar sus datos. Actores: usuario Precondiciones: Poscondiciones: se crea una cuenta en el sistema para el usuario que se ha registrado. Curso normal de los eventos: 1. El usuario selecciona la opci´on Registrarse en la ventana de inicio del sistema. 2. El sistema carga la ventana de registro, mostrando al usuario un formulario de registro. 3. El usuario cubre el formulario, introduciendo los datos requeridos: nombre de usuario, contrase˜na, confirmaci´on de la contrase˜na, nombre real, apellidos, correo electr´onico e idioma preferido. El usuario selecciona Registrarse. 4. El sistema env´ıa un correo electr´onico con un c´odigo de confirmaci´on al usuario a la cuenta de correo electr´onico especificada durante el registro. A continuaci´on, el sistema carga la pantalla de confirmaci´on de registro, indicando al usuario que introduzca el c´odigo de confirmaci´on recibido. 5. El usuario introduce el c´odigo de confirmaci´on recibido. 6. El sistema carga una nueva pantalla indicando al usuario que el registro se ha completado con ´exito. CAP´ ITULO 3. ESPECIFICACI ´ ON DE REQUISITOS Y CASOS DE USO 53 Caso de uso CU8: Entrenar random forest Prop´osito: generar un modelo mediante el entrenamiento de un random forest. Actores: usuario. Precondiciones: debe existir alg´un dataset en el sistema. Poscondiciones: se genera un modelo de tipo random forest capaz de predecir valores de conductividad a partir de voltajes. Curso normal de los eventos: 1. En la secci´on de Modelos del sistema, el usuario selecciona la opci´on Entrenar nuevo modelo. 2. El sistema carga la ventana de selecci´on de tipo de modelo. 3. El usuario selecciona la opci´on Random forest. 4. El usuario introduce o selecciona los siguientes par´ametros sobre el modelo: dataset de entrenamiento. N´umero de estimadores. Profundidad m´axima de las ramas. N´umero m´ınimo de muestras para divisi´on. N´umero m´ınimo de muestras para generar un nodo hoja. Lista de m´etricas. Visibilidad. Comentarios adicionales. A continuaci´on, el usuario selecciona la opci´on Iniciar entrenamiento. 5. El sistema carga la ventana de entrenamientos. En el apartado de Entrenamientos en curso aparece el registro del nuevo entrenamiento de tipo random forest iniciado por el usuario. 6. Cuando el entrenamiento finaliza, el sistema env´ıa un correo notificando al usuario que el entrenamiento del modelo de random forest ha finalizado. Curso alternativo 1: 4. El usuario introduce alg´un par´ametro de forma incorrecta o no selecciona alg´un par´ametro obligatorio. a) El sistema muestra un mensaje de error al usuario y le indica qu´e par´ametros ha introducido de forma incorrecta (y por qu´e la informaci´on introducida no es correcta) o cu´ales ha olvidado introducir o seleccionar. Se vuelve al paso 4. CAP´ ITULO 3. ESPECIFICACI ´ ON DE REQUISITOS Y CASOS DE USO 54 Caso de uso CU9: Entrenar m´aquina de soporte vectorial Prop´osito: generar un modelo mediante el entrenamiento de una m´aquina de soporte vectorial. Actores: usuario. Precondiciones: debe existir alg´un dataset en el sistema. Poscondiciones: se genera un modelo de tipo m´aquina de soporte vectorial capaz de predecir valores de conductividad a partir de voltajes. Curso normal de los eventos: 1. En la secci´on de Modelos del sistema, el usuario selecciona la opci´on Entrenar nuevo modelo. 2. El sistema carga la ventana de selecci´on de tipo de modelo. 3. El usuario selecciona la opci´on M´aquina de soporte vectorial. 4. El usuario introduce o selecciona los siguientes par´ametros sobre el modelo: dataset de entrenamiento. Kernel. Grado (el usuario s´olo puede especificar este par´ametro en caso de que el kernel sea de tipo polin´omico). Gamma. Coeficiente 0. Tolerancia. Constante C. ´ Epsilon. Lista de m´etricas. Visibilidad. Comentarios adicionales. A continuaci´on, el usuario selecciona la opci´on Iniciar entrenamiento. 5. El sistema carga la ventana de entrenamientos. En el apartado de Entrenamientos en curso aparece el registro del nuevo entrenamiento de tipo m´aquina de soporte vectorial iniciado por el usuario. 6. Cuando el entrenamiento finaliza, el sistema env´ıa un correo notificando al usuario que el entrenamiento del modelo de m´aquina de soporte vectorial ha finalizado. Curso alternativo 1: CAP´ ITULO 3. ESPECIFICACI ´ ON DE REQUISITOS Y CASOS DE USO 55 4. El usuario introduce alg´un par´ametro de forma incorrecta o no selecciona alg´un par´ametro obligatorio. a) El sistema muestra un mensaje de error al usuario y le indica qu´e par´ametros ha introducido de forma incorrecta (y por qu´e la informaci´on introducida no es correcta) o cu´ales ha olvidado introducir o seleccionar. Se vuelve al paso 4. Caso de uso CU10: Eliminar modelo Prop´osito: eliminar un modelo almacenado en el sistema. Actores: usuario. Precondiciones: debe existir en el sistema alg´un modelo creado por el usuario. Poscondiciones: se elimina del sistema el modelo seleccionado por el usuario. Curso normal de los eventos: 1. En el apartado de entrenamientos de la ventana principal, el usuario pulsa en la opci´on Acceder. 2. El sistema carga la ventana con la lista de modelos p´ublicos o entrenados por el propio usuario. En los modelos entrenados por el propio usuario, el sistema muestra la opci´on Eliminar. 3. El usuario pulsa en la opci´on Eliminar en el modelo que desea eliminar del sistema. 4. El sistema carga una ventana de confirmaci´on, preguntando al usuario si desea realmente eliminar el modelo. 5. El usuario selecciona la opci´on S´ı. 6. El sistema elimina el modelo de la base de datos. A continuaci´on, el sistema carga una ventana informando al usuario de que el modelo se ha eliminado con ´exito. Curso alternativo 1: 5. El usuario selecciona la opci´on No. a) El sistema carga de nuevo la ventana de modelos. Se vuelve al paso 2. CAP´ ITULO 3. ESPECIFICACI ´ ON DE REQUISITOS Y CASOS DE USO 56 Caso de uso CU11: Consultar datasets Prop´osito: mostrar a un usuario los datasets p´ublicos o a˜nadidos/generados por el propio usuario que se encuentran almacenados en el sistema. Actores: usuario. Precondiciones: debe existir en el sistema alg´un dataset p´ublico o a˜nadido/generado por el usuario. Poscondiciones: se muestran todos los datasets p´ublicos o a˜nadidos/generados por el usuario que cumplan con los requisitos establecidos por ´este. Curso normal de los eventos: 1. En el apartado de datasets de la ventana principal, el usuario pulsa en la opci´on Acceder. 2. El sistema carga todos los datasets p´ublicos o a˜nadidos/generados por el propio usuario almacenados en el sistema y muestra al usuario las opciones de filtrado. 3. El usuario selecciona las opciones de filtrado que le interesan y pulsa en Filtrar. 4. El sistema carga los datasets que cumplen con las opciones de filtrado indicadas por el usuario. Curso alternativo 1: 4. No existen datasets en el sistema que cumplan con las opciones de filtrado indicadas por el usuario. a) El sistema muestra un mensaje indicando que no hay datasets que cumplan con las condiciones especificadas. Se vuelve al paso 3. Caso de uso CU12: Descargar dataset. Prop´osito: permitir a un usuario descargar en su equipo un dataset en formato CSV. Actores: usuario. Precondiciones: debe existir en el sistema alg´un dataset p´ublico o a˜nadido/generado por el usuario. Poscondiciones: el dataset seleccionado por el usuario es descargado en su equipo en el directorio indicado por el propio usuario. Curso normal de los eventos: 1. Se ejecuta el caso de uso CU11. Para cada uno de los datasets cargados, se muestra al usuario la opci´on de Descargar. CAP´ ITULO 3. ESPECIFICACI ´ ON DE REQUISITOS Y CASOS DE USO 57 2. El usuario selecciona la opci´on Descargar para el dataset que desea guardar en su equipo. 3. El usuario selecciona las opciones de filtrado que le interesan y pulsa en Filtrar. 4. El sistema carga los datasets que cumplen con las opciones de filtrado indicadas por el usuario. 5. El sistema prepara el dataset para ser descargado. Durante esta preparaci´on del dataset, muestra al usuario un s´ımbolo de carga. Una vez que el dataset est´a preparado, el sistema muestra al usuario una nueva ventana de confirmaci´on de la descarga. 6. El usuario pulsa en la opci´on Descargar de la nueva ventana. 7. El sistema muestra una ventana de selecci´on del directorio de descarga. 8. El usuario selecciona el directorio en el que desea descargar el dataset. 9. El sistema guarda el dataset en formato CSV en el directorio indicado por el usuario Curso alternativo 1: 6. El usuario decide finalmente no descargar el dataset y regresa a la p´agina anterior. Se repite el paso 1. Caso de uso CU13: Eliminar dataset Prop´osito: eliminar un dataset almacenado en el sistema. Actores: usuario. Precondiciones: debe existir en el sistema alg´un dataset a˜nadido/generado por el usuario. Poscondiciones: se elimina del sistema el dataset seleccionado por el usuario. Curso normal de los eventos: 1. El usuario ejecuta el caso de uso CU11 y obtiene una lista de los datasets p´ublicos o a˜nadidos/generados por ´el que se encuentran almacenados en el sistema. Una de las opciones que se presentan para cada uno de los datasets es la opci´on Eliminar. 2. El usuario pulsa en la opci´on Eliminar en el dataset que desea eliminar del sistema. CAP´ ITULO 3. ESPECIFICACI ´ ON DE REQUISITOS Y CASOS DE USO 58 3. El sistema carga una ventana de confirmaci´on, preguntando al usuario si desea realmente eliminar el dataset. 4. El usuario selecciona la opci´on S´ı. 5. El sistema elimina el dataset de la base de datos . A continuaci´on, el sistema carga una ventana informando al usuario de que el dataset se ha eliminado con ´exito. Caso de uso CU14: A˜nadir dataset Prop´osito: subir un dataset al sistema desde el equipo del usuario Actores: usuario. Precondiciones: Poscondiciones: el dataset seleccionado por el usuario es subido al sistema. Curso normal de los eventos: 1. En la ventana de datasets, el usuario pulsa en la opci´on Subir dataset. 2. El sistema carga la ventana de subida de un dataset. 3. El usuario introduce el tama˜no m´ınimo y m´aximo del radio de los artefactos de las mallas que integran el dataset, la semilla con la que el dataset ha sido generado e indica si desea que el dataset sea visible. Adem´as, el usuario selecciona el fichero de su equipo que contiene el dataset y pulsa en la opci´on Subir dataset. 4. El sistema valida el fichero subido por el usuario y carga la ventana de tareas de datasets. El dataset subido por el usuario aparece en la lista de Datasets en curso de ser subidos o generados. Curso alternativo 1: 4. El sistema determina que el fichero subido no tiene un formato o una estructura v´alida y muestra al usuario un error inform´andolo de la situaci´on. Se repite el paso 3. Caso de uso CU16: Generar dataset Prop´osito: generar un nuevo dataset en el sistema con las caracter´ısticas especificadas por el usuario. Actores: usuario. Precondiciones: Poscondiciones: se genera un nuevo dataset, el cual es almacenado en el sistema. Curso normal de los eventos: CAP´ ITULO 3. ESPECIFICACI ´ ON DE REQUISITOS Y CASOS DE USO 59 1. En la ventana de datasets, el usuario pulsa en la opci´on Generar dataset. 2. El sistema carga la ventana de generaci´on de un dataset. 3. El usuario introduce el n´umero de mallas con uno, dos y tres artefactos, el tama˜no m´ınimo y m´aximo del radio de los artefactos de las mallas que integran el dataset, la semilla con la que el dataset ha sido generado e indica si desea que el dataset sea visible. El usuario pulsa en la opci´on Generar dataset. 4. El sistema carga la ventana de tareas de datasets. El dataset cuya generaci´on ha iniciado el usuario aparece en la lista de Datasets en curso de ser subidos o generados. Cap´ıtulo 4 Tecnolog´ıas y herramientas En este apartado se incluye la descripci´on de las principales tecnolog´ıas y herramientas utilizadas para realizar el proyecto. Cabe se˜nalar que tanto las tecnolog´ıas como las herramientas que se presentar´an a continuaci´on son software libre, por lo que no han supuesto coste alguno para el proyecto. 4.1. Tecnolog´ıas 4.1.1. Python El lenguaje de prop´osito general utilizado para implementar el backend del sistema fue Python. Aunque Python no suele ser un lenguaje habitual para implementar servicios web, a diferencia de otros lenguajes como Java, se consider´o el lenguaje apropiado para este proyecto. Python es el lenguaje m´as empleado en el ´ambito de la Inteligencia Artificial, por lo que dispone de numerosos m´odulos relacionados con este campo y, por tanto, de gran utilidad para la consecuci´on de los objetivos de este proyecto. Considerando que el prop´osito de este proyecto es el desarrollo de una aplicaci´on capaz de simular tomograf´ıas de impedancia el´ectrica mediante t´ecnicas de Machine Learning, se opt´o por emplear Python como lenguaje de implementaci´on del backend. En particular, en este proyecto fueron fundamentales los m´odulos numpy y sklearn de Python, para el manejo de datasets y el entrenamiento de modelos de Machine Learning, respectivamente. 4.1.2. Django REST Django REST [8] es un framework de Python para el desarrollo de APIs REST (las caracter´ısticas de una API REST se explicar´an en el apartado 5.1 del trabajo). Django REST enmascara la complejidad y los riesgos de seguridad asociados desarrollo de APIs REST. Por esta raz´on, se logra una notable aceleraci´on en la fase de codificaci´on. Cabe destacar que mediante el empleo de Django REST, no 60 CAP´ ITULO 4. TECNOLOG´ IAS Y HERRAMIENTAS 61 fue necesario escribir consultas de SQL puro para realizar accesos a la base de datos. 4.1.3. React Para desarrollar el frontend del sistema, se emple´o React, [9] un framework de JavaScript para el desarrollo de interfaces gr´aficas. React se basa en el empleo de componentes, los cuales son clases de JavaScript. Cada una de las vistas de la aplicaci´on puede estar conformada por uno o varios componentes. Por otra parte, la utilizaci´on de este framework facilit´o la implementaci´on de comportamientos din´amicos en las vistas, como la aparici´on de s´ımbolos de carga al pulsar un bot´on o la creaci´on de ciertos nodos en la estructura DOM del documento HTML como respuesta a una interacci´on del usuario. Por otra parte, para realizar las llamadas a los servicios ofrecidos por el backend desde el frontend implementado en React, se utiliz´o la biblioteca Axios [10], un cliente HTTP para JavaScript. 4.1.4. Keras La biblioteca Keras [11] de Python se utiliz´o para incorporar la funcionalidad de entrenamiento de redes neuronales, as´ı como la funcionalidad de realizar predicciones utilizando dichos modelos. Cabe se˜nalar que como backend de Keras se emple´o, a su vez, la biblioteca TensorFlow [12]. 4.1.5. EIDORS La biblioteca EIDORS [13] se utiliz´o para simular la realizaci´on de tomograf´ıas de impedancia el´ectrica, haciendo uso de los algoritmos que incluye la biblioteca para resolver tanto el forward problem como el inverse problem. Aunque EIDORS es una biblioteca de MATLAB, muchas de sus funciones pueden utilizarse a trav´es de Octave. Para este trabajo, se hizo uso del m´odulo oct2py de Python [14], que permite ejecutar funciones de Octave desde Python. Por otra parte, para la generaci´on de las representaciones gr´aficas de las mallas se utiliz´o la biblioteca NetGen [15]. 4.1.6. Celery Celery [16] es una cola de tareas implementada en Python. El entrenamiento de modelos y la generaci´on de datasets son tareas costosas con un tiempo de ejecuci´on muy elevado, por lo que conviene ejecutarlas de forma as´ıncrona. Celery se ha utilizado para gestionar estas tareas de manera eficiente. CAP´ ITULO 4. TECNOLOG´ IAS Y HERRAMIENTAS 62 4.1.7. C++ Para construir los datasets, se hizo uso de un algoritmo de generaci´on de mallas, dise˜nado por el grupo de investigaci´on COGRADE del CiTIUS. Dicho algoritmo se utiliza a trav´es de un programa escrito en C++, el cual se ha integrado con la aplicaci´on de Django REST (v´ease apartado 5.1.3). C++ es un lenguaje de programaci´on que extiende al lenguaje C, incorporando el paradigma de orientaci´on a objetos. 4.1.8. HTML5 HTML5 es la quinta versi´on de HTML (HyperText Markup Language), el lenguaje de marcas est´andar para la elaboraci´on de p´aginas web. Es un lenguaje de marcas porque que utiliza etiquetas (marcas) para definir cierta informaci´on sobre el contenido y estructura de las p´aginas del sitio web que se muestran al usuario. De las nuevas caracter´ısticas incorporadas en la quinta versi´on, en este proyecto se ha hecho uso especialmente de aqu´ellas relacionadas con los formularios, como los atributos required, min o max, evitando as´ı tener que implementar ciertas funciones en JavaScript, logrando acelerar el proceso de codificaci´on. 4.1.9. CSS3 CSS3 es la ´ultima versi´on de CSS (Cascading Style Sheets). CSS es un lenguaje de dise˜no que permite definir cu´al ser´a la apariencia y c´omo se mostrar´a gr´aficamente un documento HTML o cualquier tipo de documento XML. En este proyecto, para definir la apariencia gr´afica de las vistas, se utiliz´o principalmente la biblioteca Bootstrap. No obstante, se emple´o CSS3 directamente para definir ciertas caracter´ısticas de la visualizaci´on que la biblioteca Bootstrap no permite definir. 4.1.10. PostgreSQL PostgresSQL es un SGBD (Sistema de Gesti´on de Bases de Datos) relacional y de c´odigo abierto. 4.1.11. Bootstrap Tal y como se mencion´o anteriormente, la apariencia de las vistas se defini´o principalmente mediante el framework Bootstrap [17]. Una de las caracter´ısticas fundamentales de este framework es que la colocaci´on de los elementos en pantalla se realiza a trav´es de la divisi´on de ´esta en filas de hasta 12 columnas. De esta manera, permite construir con facilidad vistas responsivas que se adapten al tama˜no de la pantalla del dispositivo que emplee el usuario. CAP´ ITULO 5. DISE ˜ NO E IMPLEMENTACI ´ ON 69 M´odulo de C++ para la generaci´on de mallas: se trata de un m´odulo externo al que el sistema llama cuando un usuario inicia la generaci´on de un nuevo dataset. 5.2.2. Diagrama de clases del m´odulo de acceso a BD A continuaci´on, se muestra el diagrama de clases del m´odulo de acceso a BD. Figura 5.2: Diagrama de clases del m´odulo de acceso a BD. Las clases presentes en el diagrama 5.2 son mapeadas por Django en tablas de la base de datos. Como se puede observar en el diagrama, los datasets constan de un conjunto de mallas. Cada dataset es creado por un usuario y cada usuario puede generar un n´umero ilimitado de datasets. Por otro lado, un mismo dataset puede ser utilizado para entrenar diferentes modelos de Machine Learning. Cada modelo de Machine Learning tiene asociadas varias m´etricas, con las que se eval´ua la precisi´on del modelo y, adicionalmente, algunos de los modelos tambi´en tienen asociada una matriz de confusi´on (v´ease el cap´ıtulo 6). Dado que los modelos pueden ser de tres tipos (redes neuronales, random forest y m´aquinas de soporte vectorial), existe una relaci´on de herencia entre la clase Modelo y las clases Modelo red neuronal,Modelo random forest yModelo m´aquina soporte vectorial, de CAP´ ITULO 5. DISE ˜ NO E IMPLEMENTACI ´ ON 70 manera que estas tres ´ultimas clases heredan todos los atributos y m´etodos de la clase Modelo. Todas estas clases se encuentran definidas en el fichero models.py, siguiendo la convenci´on de Django. 5.2.3. Diagrama de clases del m´odulo de EIT En la siguiente figura, se muestra el diagrama de clases del m´odulo de EIT. Figura 5.3: Diagrama de clases del m´odulo de EIT. Todas las clases del m´odulo de EIT son clases est´aticas, puesto que todos sus m´etodos han sido definidos como est´aticos. Esto implica que los m´etodos de dichas clases pueden ser empleados sin necesidad de instanciar las clases. Las clases de este m´odulo son las que implementan las principales funcionalidades del sistema. Las clases del m´odulo son la siguientes: CAP´ ITULO 5. DISE ˜ NO E IMPLEMENTACI ´ ON 71 Gesti´onModelos. Incluye los m´etodos necesarios para entrenar, cargar y comparar los diferentes tipos de modelos del sistema. Gesti´onDatasets. Incluye los m´etodos necesarios para generar o subir datasets al sistema. Reconstrucci´onIm´agenes. Incluye los m´etodos necesarios para realizar las predicciones de impedancias de mallas, as´ı como las reconstrucciones de las im´agenes asociadas a las mallas. ProcesadoDatos. Incluye los m´etodos necesarios para realizar los cortes en las mallas, calcular m´etricas para la comparaci´on de modelos, as´ı como para realizar el postprocesado de los datos predichos por un modelo (v´ease cap´ıtulo 6). Gesti´onFicheros. Algunas de las clases del m´odulo necesitan generar o hacer uso de ficheros. Esta clase ofrece todos los m´etodos necesarios para gestionar los diferentes ficheros que necesiten las dem´as clases. Gesti´onCorreos. Incluye los m´etodos para enviar correos electr´onicos a los usuarios que hayan enviado tareas a la cola de tareas, con el prop´osito de informales de la finalizaci´on de dichas tareas. FachadaEIT. Siguiendo el patr´on fachada (v´ease apartado 5.2.4), esta clase se emplea con el prop´osito de que no existan m´ultiples dependencias entre el m´odulo de servicios y las clases del m´odulo de EIT. En particular, el m´odulo de servicios tendr´a una ´unica dependencia con la clase FachadaEIT. 5.2.4. Patrones de dise˜no empleados en el backend Patr´on Fachada El patr´on Fachada es un patr´on de tipo estructural. Los patrones de tipo estructural son aqu´ellos que permiten conformar estructuras de una cierta complejidad mediante la combinaci´on de clases. El patr´on fachada permite proporcionar una interfaz simple para un subsistema complejo. De esta forma, se logra descomponer un sistema en un conjunto de subsistemas, los cuales se comunican a trav´es de sus respectivas fachadas. As´ı, se reducen considerablemente las dependencias entre las clases de la aplicaci´on. La fachada conoce las clases de las que consta el subsistema, de forma que delega las peticiones que recibe en dichas clases. En el caso particular de esta aplicaci´on, la clase FachadaIA desempe˜na el papel de fachada del m´odulo de EIT y tiene dependencias con las clases Gesti´onFicheros, Gesti´onModelos, Gesti´onDatasets, ProcesadoDatos y Reconstrucci´onIm´agenes. Estas cinco clases son las que implementan la l´ogica de negocio. CAP´ ITULO 5. DISE ˜ NO E IMPLEMENTACI ´ ON 72 Patrones DAO y DTA El patr´on DAO (Data Access Object) permite separar la l´ogica de negocio de la l´ogica de acceso a los datos. De esta manera, se emplea una interfaz que recibe peticiones de clientes que desean acceder a la fuente de datos, sin necesidad de que los clientes conozcan los detalles de implementaci´on de la fuente de datos. Por otra parte, mediante el patr´on DTA (Data Transfer Object) la informaci´on obtenida de la fuente de datos se empaqueta en un objeto Python. El framework Django incorpora ambos patrones. La incorporaci´on del patr´on DAO en dicho framework es evidente, puesto que sin necesidad de modificar el c´odigo que implementa la l´ogica de negocio, puede sustituirse la base de datos utilizada por la aplicaci´on, cambiando el valor de la variable ENGINE en el fichero settings.py. DATABASES = { ’ de fault ’ : { ’ENGINE ’ : ’ django . db . backends . p ostgresql p sy copg2 ’ , . . . } } La utilizaci´on del patr´on DTA en Django tambi´en es clara, puesto que en el fichero models.py se definen las clases que se utilizar´an para empaquetar los datos obtenidos al realizar las consultas en la BD. 5.2.5. Diagramas de secuencia En este apartado se mostrar´an los diagramas de secuencia de los casos de uso m´as relevantes del sistema. Los diagramas de secuencia permiten realizar el modelado de comportamiento del sistema, representando interacciones entre objetos y reflejando el orden en el que estas interacciones se producen. CAP´ ITULO 5. DISE ˜ NO E IMPLEMENTACI ´ ON 73 Reconstrucci´on de la imagen de la malla de un dataset Figura 5.4: Diagrama de secuencia: reconstrucci´on de la de la imagen de la malla de un dataset. Los pasos reflejados en la 5.4 son los siguientes: 1. Desde el frontend se env´ıa una petici´on HTTP al servicio de reconstrucci´on de im´agenes de datasets, utilizando GET como verbo de la petici´on. En los par´ametros de la petici´on, se indica el dataset, el ´ındice de la malla cuya imagen se desea reconstruir y el modelo que se quiere utilizar para la reconstrucci´on. 2. Desde el servicio, se llama al m´etodo reconstruir img de la fachada del m´odulo de EIT. 3. El m´etodo de la fachada llama al m´etodo reconstruir img de la clase Reconstrucci´onIm´agenes. 4. Se realiza una consulta en la base de datos, para obtener la informaci´on de la malla cuya imagen se reconstruir´a. Se instancia un objeto de la clase Malla. 5, 6. Se obtienen los voltajes y las impedancias de la malla 7, 8, 9, 10. Se llama al m´etodo predecir impedancias, el cual, a su vez, llama al m´etodo cargar modelo de la clases Gesti´onModelos. Se instancia un objeto de la clase Modelo. CAP´ ITULO 5. DISE ˜ NO E IMPLEMENTACI ´ ON 74 11. Se suministran los voltajes de la malla como entrada del modelo cargado y se realizan las predicciones de las impedancias. 12. A partir del fichero base que contiene la informaci´on para representar una malla vac´ıa, se generan dos ficheros en el formato adecuado para EIDORS. Uno de ellos contiene las impedancias reales de la malla, mientras que el otro contiene las impedancias predichas. 13, 14. Para generar la imagen real y la imagen reconstruida con el modelo, se ejecuta el correspondiente c´odigo de Octave (a trav´es del m´odulo oct2py de Python), el cual construye ambas im´agenes a partir de los dos ficheros generados en el paso 12. 15, 16, 17. Se devuelve al frontend las urls de las im´agenes generadas, as´ı como la lista de impedancias predichas para la imagen reconstruida. Realizaci´on de predicciones de un conjunto de voltajes Figura 5.5: Diagrama de secuencia: realizaci´on de predicciones de un conjunto de voltajes. Los pasos reflejados en la 5.5 son los siguientes: 1. Desde el frontend se env´ıa una petici´on HTTP al servicio de predicci´on de impedancias, utilizando POST como verbo de la petici´on. En el cuerpo de la petici´on, se env´ıa un fichero con un conjunto de voltajes, as´ı como el identificador del modelo con el que se desea realizar la predicci´on. CAP´ ITULO 5. DISE ˜ NO E IMPLEMENTACI ´ ON 75 2. Desde el servicio, se llama al m´etodo predecir impedancias de la fachada del m´odulo de EIT. 3. El m´etodo de la fachada llama al m´etodo predecir impedancias de la clase Reconstrucci´onIm´agenes. 4, 5. Se llama al m´etodo validar estructura fichero voltajes de la clase Gesti´onFicheros para determinar si el fichero recibido por el backend tiene el formato adecuado. 6, 7, 8. Una vez se ha determinado que el fichero de voltajes tiene el formato correcto, se carga el modelo correspondiente, mediante el m´etodo cargar modelo, de la clase Gesti´oModelos. 9. Mediante el modelo cargado y los voltajes suministrados, se realizan las predicciones de las impedancias. 10, 11, 12, 13. Se devuelven al frontend las impedancias predichas por el modelo. Entrenamiento de una red neuronal Figura 5.6: Diagrama de secuencia: entrenamiento de una red neuronal. CAP´ ITULO 5. DISE ˜ NO E IMPLEMENTACI ´ ON 76 Los pasos reflejados en la 5.6 son los siguientes: 1. Desde el frontend se env´ıa una petici´on HTTP al servicio de entrenamiento de redes neuronales, utilizando POST como verbo de la petici´on. En el cuerpo de la petici´on, se env´ıan los atributos que se desea que tenga el modelo a entrenar. 2. Desde el servicio, se instancia un objeto de la clase Modelo DNN asign´andole los atributos indicados en la petici´on HTTP. 3. Mediante el m´etodo save, se guarda la informaci´on del nuevo modelo en la base de datos. 4. Desde el servicio, se llama al m´etodo entrenar modelo de la fachada del m´odulo de EIT. 5. Se llama al m´etodo entrenar modelo de la clase Gesti´onModelos. 6. Dado que el tipo de modelo es una red neuronal, se llama al m´etodo entrenar red neuronal, para iniciar el entrenamiento de la red neuronal. Mediante la palabra clave delay, el m´etodo es tratado como una tarea, la cual es enviada a la cola de tareas de Celery. 7. Se env´ıa una respuesta al frontend con el c´odigo 200 de HTTP, indicando que el entrenamiento se ha enviado con ´exito a la cola de tareas. 8. Una vez que ha finalizado el entrenamiento, se llama al m´etodo enviar correo modelo, mediante el cual se env´ıa un correo electr´onico a la direcci´on asociada al usuario que realiz´o el entrenamiento, inform´andolo de la finalizaci´on de ´este. Comparaci´on de varios modelos En este ejemplo, se supondr´a que la comparaci´on entre modelos se realiza utilizando como m´etrica el porcentaje de acierto. Adem´as, se supondr´a tambi´en que se ha seleccionado la opci´on de postprocesar los resultados. CAP´ ITULO 5. DISE ˜ NO E IMPLEMENTACI ´ ON 77 Figura 5.7: Diagrama de secuencia: comparaci´on de varios modelos. Los pasos reflejados en la 5.7 son los siguientes: 1. Desde el frontend se env´ıa una petici´on HTTP al servicio de comparaci´on de modelos, utilizando GET como verbo de la petici´on. En los par´ametros de la petici´on, se indica IDs de los modelos que se desea comparar, la lista de m´etricas que se desea utilizar para la comparaci´on, el dataset sobre el que se realizar´an las predicciones y, finalmente, se indica si se desea postprocesar o no los resultados. 2. Desde el servicio, se llama al m´etodo comparaci´on modelos de la fachada del m´odulo de EIT. 3. Desde el m´etodo anterior, se llama al m´etodo comparaci´on modelos de la clase Gesti´onModelos. A continuaci´on, para cada uno de los modelos a comparar, se realizan los siguientes pasos: 4, 5. Mediante el m´etodo cargar modelo, se instancia el correspondiente modelo. 6, 7. Se realizan las predicciones de todo el conjunto de mallas del dataset. CAP´ ITULO 5. DISE ˜ NO E IMPLEMENTACI ´ ON 78 8, 9. Se postprocesan las predicciones realizadas, mediante el m´etodo postprocesar de la clase ProcesadoDatos. 10. Se llama al m´etodo porcentaje acierto de la clase ProcesadoDatos y se calcula el porcentaje de acierto a partir de las predicciones postprocesadas. 11. Se instancia un objeto de la clase MatrizConfusi´on con los resultados del paso 10. 12. Empleando el m´etodo save, se guarda la matriz de confusi´on generada en la base de datos. 13. El m´etodo porcentaje acierto devuelve el porcentaje de acierto calculado y la matriz de confusi´on generada. Cuando se ha iterado sobre todos los modelos, se realizan los ´ultimos pasos: 14, 15, 16. Como respuesta a la petici´on del frontend, se devuelve un diccionario con los valores de las m´etricas obtenidos por cada modelo (en este ejemplo, la ´unica m´etrica es el porcentaje de acierto) y un diccionario con las matrices de confusi´on asociadas a los modelos. Generaci´on de un dataset Figura 5.8: Diagrama de secuencia: generaci´on de un dataset. CAP´ ITULO 5. DISE ˜ NO E IMPLEMENTACI ´ ON 85 Figura 5.10: Vista principal de la aplicaci´on. En la ventana principal, se muestran al usuario las cuatro principales secciones de la aplicaci´on: Reconstrucci´on de im´agenes. Modelos. Datasets. Tareas. Para cada una de las secciones, se ofrece una muy breve descripci´on de lo que puede encontrar el usuario al acceder a esa secci´on. En esta vista y en todas las vistas sucesivas, el usuario dispondr´a en la parte superior de la ventana de un men´u. En el caso de la ventana principal, el men´u dispone ´unicamente de las opciones de Ayuda yTu cuenta. En el caso de esta ´ultima, se incluye el s´ımbolo de una flecha apuntando hacia abajo, para cumplir con el principio N2, puesto que cualquier usuario asocia esa flecha a un desplegable. En las dem´as ventanas de la aplicaci´on, en el men´u superior aparece una nueva opci´on: la opci´on Inicio. Pulsando en ella, el usuario regresar´a a la p´agina principal. Esta opci´on aparecer´a en todas las vistas sucesivas que se presenten en los siguientes apartados. De esta forma, se cumple con el principio N3, puesto CAP´ ITULO 5. DISE ˜ NO E IMPLEMENTACI ´ ON 86 que los usuarios tienen la posibilidad de regresar al men´u principal en cualquier momento. Cabe se˜nalar que el men´u superior es est´atico y se encontrar´a siempre en la parte superior de la p´agina, independientemente de que el usuario haga scroll hacia abajo. Se ha optado por este dise˜no para que el men´u sea visible para el usuario en todo momento, de forma que pueda acudir con facilidad a la ventana principal. Por otra parte, tambi´en en la esquina superior izquierda de las vistas, se encuentra el bot´on Atr´as, que incluye una flecha apuntando hacia la izquierda, que es interpretada por los usuarios como una se˜nal de regreso (se cumple con N2). Este bot´on tambi´en se incluir´a en la mayor parte de las vistas sucesivas y permitir´a al usuario regresar a la p´agina anterior, cumpliendo con N3. 5.3.4. Tipo de reconstrucci´on En la secci´on de Reconstrucci´on de im´agenes, una vez que el usuario elija un modelo para la reconstrucci´on de una imagen, deber´a indicar qu´e tipo de operaci´on desea realizar. Puede seleccionar entre la reconstrucci´on de la imagen de una malla de un dataset o la predicci´on de las conductividades a partir de un fichero de voltajes (el cual debe subir al sistema). Figura 5.11: Selecci´on de la operaci´on a realizar en la secci´on de Reconstrucci´on de im´agenes. CAP´ ITULO 5. DISE ˜ NO E IMPLEMENTACI ´ ON 87 5.3.5. Reconstrucci´on de im´agenes Selecci´on de dataset y malla Figura 5.12: Vista de selecci´on de dataset y malla (I). CAP´ ITULO 5. DISE ˜ NO E IMPLEMENTACI ´ ON 88 Figura 5.13: Vista de selecci´on de dataset y malla (II). Si en la vista de selecci´on de operaci´on, el usuario selecciona la opci´on An´alisis de mallas de datasets, acceder´a a la vista de selecci´on de malla. En ella podr´a escoger un dataset y seleccionar la malla del dataset que desea reconstruir con el modelo. En lo relativo a la usabilidad de esta vista, cabe destacar que se busca cumplir con el principio N6 mostrando al usuario en pantalla la siguiente informaci´on: qu´e modelo ha seleccionado, qu´e dataset ha seleccionado y qu´e n´umero de artefactos por malla ha seleccionado. De esta manera, el usuario no se ve obligado a recordar toda esta informaci´on. Cuando el usuario haya seleccionado la malla que desea reconstruir, pulsando en el bot´on Reconstruir imagen se iniciar´a la reconstrucci´on de la imagen. Como este proceso tarda unos segundos, se muestra al usuario un s´ımbolo habitual de carga, cumpliendo con el principio N1. Cuando la reconstrucci´on haya finalizado, se cargar´a una nueva ventana con la imagen reconstruida. CAP´ ITULO 5. DISE ˜ NO E IMPLEMENTACI ´ ON 89 Imagen reconstruida Figura 5.14: Vista de imagen reconstruida. En esta vista, se mostrar´an al usuario dos im´agenes: la primera de ellas es la imagen real asociada a la malla seleccionada. La segunda imagen es la imagen reconstruida mediante el modelo elegido por el usuario. De nuevo, se indica al usuario el dataset, la malla y el modelos utilizados, cumpliendo con N6. Debajo de las dos im´agenes se encuentra la secci´on para realizar cortes sobre las mallas. El usuario puede seleccionar el valor del eje Y para el que desea realizar el corte. Pulsando en Analizar secci´on, se generar´a en la misma ventana una gr´afica en la que se muestran los valores de conductividad de la malla en el eje Y indicado por el usuario, como se puede ver en la figura 5.15. CAP´ ITULO 5. DISE ˜ NO E IMPLEMENTACI ´ ON 90 Figura 5.15: Vista de corte de una malla. Predicciones realizadas Si en la ventana de selecci´on de operaci´on, el usuario escoge la opci´on Predicci´on de conductividades a partir de un conjunto de voltajes, acceder´a a una vista en la que deber´a subir un fichero CSV, el cual debe contener los voltajes asociados a mallas. Una vez que lo suba y pulse en Realizar predicciones, podr´a visualizar los resultados de las predicciones y reconstruir las im´agenes de las mallas que desee. CAP´ ITULO 5. DISE ˜ NO E IMPLEMENTACI ´ ON 91 Figura 5.16: Vista de las predicciones de conductividades a partir de un conjunto de voltajes. CAP´ ITULO 5. DISE ˜ NO E IMPLEMENTACI ´ ON 92 5.3.6. Modelos Lista de modelos Figura 5.17: Vista del listado de modelos disponibles. Accediendo a la secci´on de Modelos desde la ventana principal de la aplicaci´on, se muestra una vista que contiene el listado de modelos p´ublicos o entrenados por el propio usuario, con la informaci´on general de cada modelo. Mediante la opci´on Filtrar modelos, el usuario tiene la posibilidad de filtrar los modelos de acuerdo a caracter´ısticas de su inter´es como, por ejemplo, el tipo de modelo. Tal y como se puede ver en la figura 5.17, en la parte derecha de la fila correspondiente a cada modelo, se encuentra la opci´on Ver detalles. Pulsando en esa opci´on, el usuario podr´a consultar informaci´on espec´ıfica sobre cada modelo. El tipo de informaci´on que se mostrar´a variar´a en funci´on del tipo de modelo que se consulte. Por ejemplo, para una red neuronal, al clicar en Ver detalles se acceder´a a una ventana como la mostrada en la figura 5.18. CAP´ ITULO 5. DISE ˜ NO E IMPLEMENTACI ´ ON 93 Figura 5.18: Vista de los detalles de una red neuronal. Como se puede ver en la figura 5.18, entre la informaci´on asociada a un modelo, se encuentra el dataset con el que se entren´o. El usuario tiene la posibilidad de consultar, a su vez, la informaci´on detallada del dataset utilizado para entrenar el modelo que est´a examinando, pulsando en el bot´on Ver informaci´on de la fila en la que se indica el ID del dataset. Al pulsar en ese bot´on, acceder´a a una nueva ventana de detalles del dataset, la cual se analizar´a posteriormente. Por otra parte, cabe destacar que si una de las m´etricas almacenadas para el modelo es el porcentaje de acierto, el usuario tiene la posibilidad de visualizar la matriz de confusi´on, pulsando en Ver matriz de confusi´on. Al pulsar en ese bot´on, se despliega en la misma ventana un cuadro que contiene la matriz de confusi´on y que el usuario puede cerrar clicando en el bot´on Cerrar que contiene dicho cuadro o en el s´ımbolo X situado en la esquina superior derecha del cuadro. Un ejemplo de la visualizaci´on de una matriz de confusi´on se puede ver en la figura 5.19. CAP´ ITULO 5. DISE ˜ NO E IMPLEMENTACI ´ ON 94 Figura 5.19: Vista de una matriz de confusi´on. Comparar modelos Como se puede observar en la figura 5.17 en la ventana de Modelos, bajo el listado de modelos disponibles, se encuentra la opci´on Comparar modelos. El usuario tiene la posibilidad de realizar la comparaci´on de dos a cuatro modelos, seleccionando de la lista los modelos que desea comparar. Si pulsa en Comparar modelos habiendo seleccionado menos de dos modelos, se le mostrar´a un mensaje de error (principio N9). Si ya ha seleccionado cuatro e intenta seleccionar uno m´as, el sistema no se lo permitir´a, cumpliendo con el principio N5. Habiendo seleccionado un n´umero adecuado de modelos y pulsando en Comparar modelos, el usuario acceder´a a la ventana de definici´on de los par´ametros de la comparaci´on (figura 5.20). CAP´ ITULO 5. DISE ˜ NO E IMPLEMENTACI ´ ON 101 La informaci´on general ya mostrada se incluye de nuevo en la ventana de detalles, para cumplir con el principio N6. Generar dataset Figura 5.27: Vista de generaci´on de dataset. Si en la vista de Datasets, el usuario pulsa en Generar dataset acceder´a a una nueva ventana (figura 5.27) en la que podr´a definir las caracter´ısticas del dataset que desea generar, como el n´umero de mallas. Al pulsar en el bot´on Generar dataset de esta ventana, se iniciar´a la generaci´on del dataset y el usuario ser´a redirigido a la ventana de Datasets en generaci´on, donde podr´a ver que el dataset que cuya generaci´on acaba de iniciar se encuentra en la lista de datasets en curso de ser generados. De forma an´aloga a los modelos en entrenamiento, este dise˜no cumple con el principio N1. CAP´ ITULO 5. DISE ˜ NO E IMPLEMENTACI ´ ON 102 5.3.8. Tareas Figura 5.28: Vista de selecci´on del tipo de tarea. En la secci´on de Tareas, los usuarios podr´an consultar los entrenamientos en curso y los datasets en generaci´on. Cuando el usuario accede a esta secci´on desde el men´u principal, se le mostrar´a una ventana sencilla (se cumple el principio N8) en la que podr´a indicar si desea acceder a las tareas asociadas a los modelos (entrenamientos) o a las tareas asociadas a los datasets (generaci´on). CAP´ ITULO 5. DISE ˜ NO E IMPLEMENTACI ´ ON 103 Entrenamientos Figura 5.29: Vista de selecci´on del tipo de tarea. En la vista de entrenamientos, se muestran al usuario dos listas diferentes. La lista superior incluye los entrenamientos que se encuentran en curso en ese momento, mientras que la lista inferior contiene los modelos cuyo entrenamiento ya ha finalizado. En la esquina superior derecha de la ventana, el usuario tiene la posibilidad de refrescar la pantalla, pulsando en el bot´on Refrescar. Se cumple as´ı con con el principio N3. Por otra parte, el bot´on incluye el s´ımbolo t´ıpicamente asociado a la acci´on de recargar, por lo que se cumple tambi´en con el principio N2. Cap´ıtulo 6 Machine Learning En este cap´ıtulo se analizar´an los aspectos m´as relevantes del sistema asociados al ´ambito del Machine Learning. En primer lugar, se explicar´an las caracter´ısticas de los datasets utilizados y c´omo ´estos son empleados para entrenar los modelos. En segundo lugar, se presentar´an los diferentes tipos de modelos de Machine Learning y se realizar´a una comparaci´on entre ellos. Finalmente, se describir´a la t´ecnica de postprocesado utilizada a la hora de reconstruir las im´agenes. 6.1. Datasets De manera simplificada, un dataset se puede definir como un conjunto de datos utilizado para entrenar modelos de Machine Learning. Cada uno de los elementos de un dataset est´a constituido por una serie de variables, las cuales pueden ser dependientes (inputs) o independientes (outputs). Los valores de las variables dependientes est´an condicionados por los valores de las variables independientes. En el problema que nos ocupa, los datos que integran los datasets son mallas, las cuales constan de 1052 variables: 208 variables de voltaje y 844 variables de conductividad el´ectrica. Las variables de conductividad el´ectrica son las variables dependientes, puesto que deseamos entrenar modelos capaces de predecir su valor a partir de las variables de voltaje, que son las variables independientes. El sistema desarrollado concede libertad al usuario a la hora de generar los datasets, permiti´endole seleccionar el n´umero de mallas con uno, dos y tres artefactos, as´ı como el radio m´ınimo y m´aximo de los artefactos. Sin embargo, si se desea generar un dataset que sea adecuado para entrenar modelos, ´este debe contar con un n´umero de mallas suficiente y ´estas deben ser representativas. Si el n´umero de mallas del dataset es demasiado reducido, los modelos entrenados con dicho dataset no habr´an “aprendido“ a generalizar el conocimiento adquirido y las predicciones realizadas con esos modelos sobre datos no pertenecientes al dataset ser´an poco precisas (overfitting). Por otra parte, se producir´a una situaci´on 104 CAP´ ITULO 6. MACHINE LEARNING 105 similar si las mallas del dataset no son lo suficientemente representativas. Por ejemplo, si todas las mallas de un cierto dataset est´an integradas por un ´unico artefacto con un determinado radio, un modelo entrenado con ese dataset tendr´a dificultades para realizar las predicciones de mallas con tres artefactos de radios diversos. 6.1.1. Metodolog´ıa de entrenamiento Cuando un usuario selecciona un dataset para entrenar un nuevo modelo, se desordenan sus mallas de forma aleatoria. A continuaci´on, el dataset se dividide en dos conjuntos: un conjunto de entrenamiento y un conjunto de test. El conjunto de entrenamiento est´a constituido por el 70 % de las mallas del dataset, mientras que el conjunto de test lo conforman el 30 % de las mallas restantes. El conjunto de entrenamiento se utiliza para entrenar el modelo, mientras que el conjunto de test se emplea ´unicamente para evaluar la precisi´on del modelo, una vez que ´este ya ha sido entrenado. La raz´on por la que se desordenan las mallas antes de dividir el dataset es garantizar que tanto en el conjunto de entrenamiento como en el conjunto de test existan mallas de todos los tipos (con diferente n´umero de artefactos y con artefactos de diferente radio), de forma que no se produzca underfitting. Por otro lado, la divisi´on de un dataset en los dos conjuntos mencionados es necesaria para poder evaluar el modelo de forma satisfactoria. Si el modelo se evaluase con el mismo conjunto de datos con el que se entren´o, no se podr´ıa determinar si el conocimiento del modelo es generalizable. Todas estas tareas se llevan a cabo empleando el m´etodo obtiene conjuntos de la clase Dataset. 6.2. Modelos La predicci´on de las 844 conductividades de una malla a partir de los 208 voltajes suministrados por sus electrodos es realizada por modelos de Machine Learning. Los problemas de este tipo, consistentes en predecir variables continuas dependientes a partir de variables continuas independientes reciben el nombre de problemas de regresi´on. Para solucionar este problema de regresi´on, los modelos del sistema SageTomo son entrenados siguiendo la metodolog´ıa expuesta en el apartado anterior. Sin embargo, cada uno de los tres tipos de modelos utilizados por el sistema tiene caracter´ısticas particulares. A continuaci´on, se describir´an los rasgos principales de los tres tipos de modelos: redes neuronales, random forest y m´aquinas de soporte vectorial. CAP´ ITULO 6. MACHINE LEARNING 106 6.2.1. Redes neuronales Las redes neuronales se encuentran ligeramente inspiradas su hom´ologo biol´ogico, de forma que una red neuronal est´a constituida por un conjunto de neuronas interconectadas. En la figura 6.1 se puede observar una arquitectura gen´erica para una red neuronal. Figura 6.1: Arquitectura de una red neuronal [28]. Las neuronas de una red neuronal se distribuyen en capas, existiendo una capa de entrada, un conjunto de capas ocultas y una capa de salida. Las neuronas de una capa se conectan con las neuronas de la siguiente capa mediante enlaces, los cuales tienen asignado un peso. En la figura 6.2 se muestra c´omo se calcula la salida de una neurona. CAP´ ITULO 6. MACHINE LEARNING 107 Figura 6.2: C´alculo de la salida de una neurona. Como se puede ver en la figura anterior, adem´as de los valores de entrada y de los pesos de los enlaces, existen dos elementos adicionales: el valor de bias y la funci´on de activaci´on. El valor de la salida yde una ´unica neurona con n entradas xy con nenlaces (cada uno de los cuales tiene asignado un peso w), empleando un valor de bias b y utilizando una funci´on de activaci´on ϕse obtiene de la siguiente manera: y=ϕ(b+ n X i=1 xiwi) La salida de una neurona se utiliza como entrada para las neuronas de las siguientes capas. El entrenamiento de una red neuronal consiste en ajustar los pesos de los enlaces progresivamente, hasta lograr que el modelo sea capaz de predecir con una cierta precisi´on la salida Y para una entrada X. Existen diferentes m´etodos para ajustar los pesos de una red. Las redes neuronales entrenadas por el sistema SageTomo emplean el m´etodo del descenso del gradiente, que es un algoritmo iterativo consistente en la minimizaci´on de una funci´on de coste. En el caso particular de los modelos del sistema a desarrollar, la capa de entrada tiene necesariamente 208 neuronas, puesto que existen 208 valores de entrada: los 208 voltajes generados por los electrodos. Por otra parte, la capa de salida tiene 844 neuronas, cada una de las cuales devuelve el valor de una de las 844 conductividades de una malla. Existen varios factores relevantes a la hora de entrenar una red neuronal. A continuaci´on, se describir´an aquellos factores que el usuario del sistema SageTomo puede definir para entrenar este tipo de modelo: N´umero de capas ocultas y n´umero de neuronas por capa oculta. Las capas ocultas son las capas de neuronas que se encuentran entre la capa de entrada y la capa de salida. El usuario puede elegir el n´umero de capas ocultas que desea, as´ı como el n´umero de neuronas de cada una de las capas ocultas. CAP´ ITULO 6. MACHINE LEARNING 108 Funci´on de activaci´on para las capas internas y las capas de salida. Tal y como se ha visto, en la salida de una neurona se aplica una funci´on que modifica el valor de dicha salida (funci´on de activaci´on), logrando que el valor de salida de la neurona pertenezca a un intervalo concreto. Aunque podr´ıa utilizarse una funci´on de activaci´on particular para cada neurona, lo habitual es emplear una misma funci´on de activaci´on para todas las neuronas de las capas internas y otra funci´on de activaci´on para las neuronas de la capa de salida. ´ Esta es la opci´on que se le presenta al usuario de SageTomo, quien puede seleccionar la funci´on de activaci´on para ambos tipos de neuronas. Funci´on de error. Es la funci´on de coste que se debe minimizar durante la ejecuci´on del m´etodo del descenso de gradiente. N´umero de ´epocas. En una ´epoca, todos los datos del conjunto de entrenamiento son suministrados a la red neuronal. Entrenamiento por lotes y tama˜no de los lotes. Al utilizar un entrenamiento por lotes, el conjunto de entrenamiento se divide en subconjuntos denominados lotes. Cada vez que un lote es suministrado a la red neuronal, se actualizan los pesos de los enlaces. Learning rate. Es el par´ametro empleado en el m´etodo de descenso de gradiente para determinar cu´anto se modifican los pesos en cada iteraci´on. Cuanto mayor sea el valor del learning rate, mayor ser´a la modificaci´on de los pesos realizada en cada iteraci´on. Momentum. Es el par´ametro empleado en el m´etodo de descenso de gradiente para acelerar o frenar la modificaci´on de los pesos. Este factor perjudica o ayuda al learning rate dependiendo de lo sucedido en las iteraciones previas. De esta forma, permite evitar que el algoritmo se quede “atrapado“ en un m´ınimo local, siendo incapaz de alcanzar el m´ınimo global. Cuanto menor sea el valor asignado al momentum, m´as dif´ıcil resultar´a que el algoritmo sea capaz de evitar los m´ınimos locales. Normalmente, el valor del momentum suele ser inversamente proporcional al learning rate. En la siguiente figura se muestra como ejemplo la reconstrucci´on de la imagen de una malla con dos artefactos empleando una DNN. CAP´ ITULO 6. MACHINE LEARNING 109 Figura 6.3: Reconstrucci´on mediante una DNN. 6.2.2. Random Forest El random forest es un tipo de modelo basado en ´arboles de decisi´on. Los ´arboles de decisi´on empleados para resolver problemas de regresi´on reciben el nombre de ´arboles de regresi´on. En la figura 6.4 se muestra la representaci´on de un ´arbol de regresi´on. Figura 6.4: ´ Arbol de regresi´on. Como se puede ver, cada nodo del ´arbol constituye la evaluaci´on de una condici´on. De cada nodo nacen dos ramas: una rama se corresponde con la situaci´on CAP´ ITULO 6. MACHINE LEARNING 110 en la que la evaluaci´on de la condici´on del nodo es verdadera y la otra rama se corresponde con la situaci´on en la que la evaluaci´on es falsa. Dado un determinado dato de entrada, se comienza evaluando la condici´on del nodo ra´ız del ´arbol (el nodo superior) y se sigue el camino hasta alcanzar un nodo hoja (los nodos verdes de la figura anterior). Los nodos hoja no contienen una condici´on, sino un valor, que es la predicci´on para el dato de entrada. Por ejemplo, para el dato tridimensional x1= 9 , x2= 72 , x3= 8 , la predicci´on obtenida por el ´arbol de regresi´on de la figura es 26. Supongamos que se dispone de un dataset con ndatos, los cuales constan de las variables de entrada x1, ... , xky de la variable de salida y. Para construir un ´arbol de regresi´on a partir de dicho dataset, se divide el espacio de las variables predictoras (xi) en regiones diferentes. Para cada dato que caiga en una de esas regiones, se realiza una predicci´on, consistente en calcular la media de los datos de esa regi´on. Se sigue una aproximaci´on arriba-abajo, comenzando en el nodo ra´ız del ´arbol y dividiendo el espacio de variables predictoras en dos nuevas ramas. En cada nodo, se elije la mejor divisi´on posible del espacio de esa regi´on. Siendo kel n´umero de variables predictoras y cel punto de corte para una regi´on, en un determinado nodo, el espacio de variables predictoras se divide en los dos siguientes conjuntos: R1(k, c) = {x|xk≤c} R2(k, c) = {x|xk> c} Existen diferentes criterios para medir la bondad de una partici´on. Uno de los m´etodos para seleccionar las mejores particiones consiste en minimizar la suma de los cuadrados de los residuos. Siendo yila variable de salida para el dato xi y ˆyRtla predicci´on en la regi´on Rtpara el dato xi, el objetivo es buscar en cada nodo los valores de kycque minimicen la siguiente expresi´on: X i:xi∈R1(k,c) (yi−ˆyR1)2+X i:xi∈R2(k,c) (yi−ˆyR2)2 Por tanto, el objetivo es minimizar la expresi´on anterior (la suma de los cuadrados de los residuos). Regresando al problema de predicci´on de conductividades de las mallas, se observa que existen 844 variables de salida (las 844 conductividades). Sin embargo, un ´arbol de regresi´on s´olo permite predecir una variable de salida. La soluci´on consiste en entrenar 844 ´arboles de regresi´on, de forma que cada uno de ellos se encargue de predecir una de las 844 impedancias. Sin embargo, el gran problema que presentan los ´arboles de regresi´on es su dificultad para generalizar el conocimiento adquirido a trav´es del dataset de entrenamiento. Es decir, estos modelos presentan una precisi´on reducida al realizar predicciones sobre datos a los que no se hab´ıan enfrentado anteriormente Cap´ıtulo 7 Pruebas y validaci´on En este apartado se definir´an las pruebas a las que se someter´a la aplicaci´on SmartTomo. En primer lugar, se realizar´an pruebas de validaci´on de requisitos. Las pruebas que se definir´an constar´an de diferentes casos de prueba asociados a los distintos requisitos incluidos en el cap´ıtulo 3. Especificaci´on de requisitos y casos de uso, con el prop´osito de determinar el cumplimiento de dichos requisitos. En segundo lugar, se analizar´a la usabilidad de la aplicaci´on. Para ello, la aplicaci´on ser´a validada por usuarios reales. 7.1. Pruebas de validaci´on de requisitos 7.1.1. Prueba de gesti´on de usuarios (P1) ID P1.1 Entrada En la ventana de inicio de sesi´on, se introduce “user1010” como nombre de usuario y “abcdefg10” como contrase˜na. Salida El sistema muestra un error indicando que el usuario o la contrase˜na no son correctos. Requisitos asociados RF1 Necesidades del entorno No debe existir en el sistema el usuario “user1010” Resultado ´ Exito Cuadro 7.1: Caso de prueba unitario P1.1. 117 CAP´ ITULO 7. PRUEBAS Y VALIDACI ´ ON 118 ID P1.2 Entrada En la ventana de inicio de sesi´on, se introduce “user1010” como nombre de usuario y “abcdefg10” como contrase˜na. Salida Se inicia sesi´on con ´exito y el sistema carga la ventana principal de la aplicaci´on. Requisitos asociados RF1 Necesidades del entorno Debe existir en el sistema el usuario “user1010” y su contrase˜na debe ser “abcdefg10”. Resultado ´ Exito Cuadro 7.2: Caso de prueba unitario P1.2. ID P1.3 Entrada Desde la ventana principal de la aplicaci´on, debe pulsarse en el bot´on Tu cuenta y, a continuaci´on, debe pulsarse en la opci´on Cerrar sesi´on. Salida El sistema cierra la sesi´on y regresa a la pantalla de inicio de sesi´on. Requisitos asociados RF2 Necesidades del entorno Ninguna. Resultado ´ Exito Cuadro 7.3: Caso de prueba unitario P1.3. CAP´ ITULO 7. PRUEBAS Y VALIDACI ´ ON 119 ID P1.4 Entrada Desde la ventana de inicio de sesi´on, se pulsa en la opci´on Registrarse. En el formulario de registro se introducen los siguientes datos: “robert plant10” como nombre de usuario, “Robert” como nombre real del usuario, “Plant Roosevelt” como apellidos y “contrasenha10” como contrase˜na. Salida El sistema almacena al usuario “robert plant10” en la base de datos. Requisitos asociados RF3 Necesidades del entorno No debe existir el usuario “robert plant10” en el sistema. Resultado ´ Exito Cuadro 7.4: Caso de prueba unitario P1.4. ID P1.5 Entrada Desde la ventana de inicio de sesi´on, se pulsa en la opci´on Registrarse. En el formulario de registro se introducen los siguientes datos: “robert plant10” como nombre de usuario, “Robert” como nombre real del usuario, “Plant Roosevelt” como apellidos y “contrasenha10” como contrase˜na. Salida El sistema muestra un mensaje de error al usuario, indic´andole que ya existe otro usuario con ese nickname. Requisitos asociados RF3 Necesidades del entorno Debe existir el usuario “robert plant10” en el sistema. Resultado ´ Exito Cuadro 7.5: Caso de prueba unitario P1.5. CAP´ ITULO 7. PRUEBAS Y VALIDACI ´ ON 120 ID P1.6 Entrada Desde la ventana de edici´on de cuenta, habiendo accedido con la cuenta “robert plant10”, se sustituye el apellido actual por “Plant Aller” Salida El sistema realiza la modificaci´on del apellido del usuario “robert plant10” en la base de datos, estableciendo “Plant Aller” como el nuevo apellido. Requisitos asociados RF4 Necesidades del entorno Debe existir el usuario “robert plant10” en el sistema y su apellido debe ser “Plant Roosevelt”. Resultado ´ Exito Cuadro 7.6: Caso de prueba unitario P1.6. ID P1.7 Entrada Desde la ventana del administrador “admin1”, se elimina al usuario “brian johnson”. Salida El usuario “brian johnson” y todos sus modelos y datasets privados son eliminados del sistema. El atributo creador de los modelos y datasets p´ublicos creados o generados por el usuario “brian johnson” adquiere el valor Desconocido. Requisitos asociados RF5 Necesidades del entorno Debe existir el administrador “admin1”. Debe existir el usuario “brian johnson”. Resultado ´ Exito Cuadro 7.7: Caso de prueba unitario P1.7. CAP´ ITULO 7. PRUEBAS Y VALIDACI ´ ON 121 CAP´ ITULO 7. PRUEBAS Y VALIDACI ´ ON 122 7.1.2. Prueba de modelos (P2) ID P2.1 Entrada Desde la cuenta del usuario “robert plant” se inicia el entrenamiento de un modelo de tipo Red neuronal. Los par´ametros utilizados deben ser los siguientes: Dataset:dataset por defecto del sistema con ID igual a 1. N´umero de capas ocultas: 1. N´umero de neuronas en la capa oculta: 369. Funci´on de activaci´on para las capas internas: ReLu. Funci´on de activaci´on para la capa de salida: ReLu. Funci´on de error: SME. Node ´epocas: 20. Entrenamiento por lotes: s´ı. Tama˜no de los lotes: 64. Learning rate: 0.001. Momentum:0.9 M´etricas: SME y porcentaje de acierto. Visibilidad: p´ublico. Comentarios adicionales: “Caso de prueba unitario de red neuronal”. Salida El sistema inicia el entrenamiento de un modelo de tipo Red neuronal. Requisitos asociados RF6 Necesidades del entorno Debe existir el usuario “robert plant”. Resultado ´ Exito Cuadro 7.8: Caso de prueba unitario P2.1. CAP´ ITULO 7. PRUEBAS Y VALIDACI ´ ON 123 ID P2.2 Entrada Desde la cuenta del usuario “robert plant” se inicia el entrenamiento de un modelo de tipo Red neuronal. Los par´ametros utilizados deben ser los siguientes: Dataset:dataset por defecto del sistema con ID igual a 1. N´umero de estimadores: 1. Profundidad m´axima: 10000. N´umero m´ınimo de muestras para divisi´on: 0. N´umero m´ınimo de muestras para nodo hoja: 0. M´etricas: SME y porcentaje de acierto. Visibilidad: p´ublico. Comentarios adicionales: “Caso de prueba unitario de random forest”. Salida El sistema inicia el entrenamiento de un modelo de tipo Random forest. Requisitos asociados RF7 Necesidades del entorno Debe existir el usuario “robert plant”. Resultado ´ Exito Cuadro 7.9: Caso de prueba unitario P2.2. CAP´ ITULO 7. PRUEBAS Y VALIDACI ´ ON 124 ID P2.3 Entrada Desde la cuenta del usuario “robert plant” se inicia el entrenamiento de un modelo de tipo Red neuronal. Los par´ametros utilizados deben ser los siguientes: Dataset:dataset por defecto del sistema con ID igual a 1. Kernel: RBF Grado: 3 Gamma: Auto Coeficiente 0: 100 Tolerancia: 7 C: 1200000 ´ Epsilon: 0.1 M´etricas: SME y porcentaje de acierto. Visibilidad: p´ublico. Comentarios adicionales: “Caso de prueba unitario de SVM ”. Salida El sistema inicia el entrenamiento de un modelo de tipo M´aquina de soporte vectorial. Requisitos asociados RF8 Necesidades del entorno Debe existir el usuario “robert plant”. Resultado ´ Exito Cuadro 7.10: Caso de prueba unitario P2.3. CAP´ ITULO 7. PRUEBAS Y VALIDACI ´ ON 125 ID P2.4 Entrada Desde la ventana de Entrenamientos de la cuenta del usuario “robert plant”, se selecciona la opci´on de Guardar modelo para un modelo cuyo entrenamiento ha finalizado. Salida El modelo cuyo entrenamiento ha finalizado se guarda en el sistema. Requisitos asociados RF9 Necesidades del entorno Debe existir el usuario “robert plant”. Debe existir alg´un entrenamiento iniciado por el usuario “robert plant” y dicho entrenamiento debe haber finalizado. Resultado ´ Exito Cuadro 7.11: Caso de prueba unitario P2.4. ID P2.5 Entrada Se accede a secci´on de Modelos la cuenta del usuario “robert plant”. Salida Se muestra al usuario un modelo de tipo Red neuronal creado por ´el y un modelo de tipo Random forest creado por el usuario “brian johnson”. Requisitos asociados RF10 Necesidades del entorno En el sistema deben existir ´unicamente tres modelos: un modelo de tipo Red neuronal cuyo creador debe ser “robert plant”, un modelo de tipo Random forest cuyo creador debe ser “brian johnson” (el modelo debe ser p´ublico) y un modelo de tipo M´aquina de soporte vectorial cuyo creador debe ser “brian johnson” (el modelo debe ser privado). Resultado ´ Exito Cuadro 7.12: Caso de prueba unitario P2.5. CAP´ ITULO 7. PRUEBAS Y VALIDACI ´ ON 126 ID P2.6 Entrada En la secci´on de Modelos, utilizando la cuenta del usuario “robert plant”, se selecciona la opci´on Eliminar modelo de un modelo creado por “robert plant”. Salida El modelo seleccionado es eliminado del sistema. Requisitos asociados RF11 Necesidades del entorno Debe existir el usuario “robert plant”. Debe existir en el sistema un modelo creado por el usuario “robert plant”. Resultado ´ Exito Cuadro 7.13: Caso de prueba unitario P2.6. ID P2.7 Entrada En la secci´on de Modelos, utilizando la cuenta del usuario “robert plant”, se seleccionan tres modelos: uno de tipo Red neuronal, otro de tipo Random forest y otro de tipo M´aquina de soporte vectorial. A continuaci´on, se pulsa en la opci´on Comparar modelos. Se escoge el dataset por defecto (el cual tiene ID 1), se elige la opci´on de postprocesar los resultados y se seleccionan el MSE y el porcentaje de acierto como m´etricas. Salida Se muestran los valores obtenidos de MSE y porcentaje de acierto para cada uno de los tres modelos. Se muestran las matrices de confusi´on para cada uno de los tres modelos. Se muestran cuatro im´agenes: la imagen real de la malla y las reconstrucciones realizadas con cada uno de los tres modelos. Requisitos asociados RF12 Necesidades del entorno Debe existir el usuario “robert plant”. Debe existir en el sistema un modelo p´ublico de tipo Red neuronal, un modelo p´ublico de tipo Random Forest y un modelo p´ublico de tipo M´aquina de soporte vectorial. Resultado ´ Exito Cuadro 7.14: Caso de prueba unitario P2.7. CAP´ ITULO 7. PRUEBAS Y VALIDACI ´ ON 133 ID P4.3 Entrada En la secci´on de Datasets, utilizando la cuenta del usuario “robert plant”, se selecciona la opci´on Subir dataset. En el formulario de subida de dataset, se seleccionan las siguientes opciones: Node electrodos: 16 electrodos. Patr´on de estimulaci´on: Adyacente. Tama˜no m´ınimo del radio de los artefactos: 4. Tama˜no m´aximo del radio de los artefactos: 10. Normalizado: no. Visibles: s´ı. Semilla: 12345. Dataset seleccionado: se selecciona el fichero “dataset prueba1.csv”. Salida El sistema muestra un error al usuario, indicando que el fichero subido no tiene la estructura adecuada. Requisitos asociados RF15 Necesidades del entorno Debe existir el usuario “robert plant”. Debe existir en el entorno de prueba el fichero “dataset prueba1.csv”, el cual debe contener 600 l´ıneas, cada una de las cuales con 208 + 844 + 1 valores num´ericos separados por punto y coma, excepto la ´ultima l´ınea, que tendr´a 208 + 844 + 2 valores. El ´ultimo valor num´erico de cada una de las l´ıneas ser´a un entero perteneciente al intervalo [1,3]. Resultado ´ Exito Cuadro 7.23: Caso de prueba unitario P4.3. CAP´ ITULO 7. PRUEBAS Y VALIDACI ´ ON 134 ID P4.4 Entrada En la secci´on de Datasets, utilizando la cuenta del usuario “robert plant”, se selecciona la opci´on Generar dataset. En el formulario de generaci´on de dataset, se seleccionan las siguientes opciones: Node electrodos: 16 electrodos. Patr´on de estimulaci´on: Adyacente. N´umero de cuerpos con un artefacto: 500. N´umero de cuerpos con dos artefactos: 200. N´umero de cuerpos con tres artefactos: 100. Tama˜no m´ınimo del radio de los artefactos: 4. Tama˜no m´aximo del radio de los artefactos: 10. Normalizado: no. Visibles: s´ı. Semilla: 12345678. Dataset seleccionado: se selecciona el fichero “dataset prueba1.csv”. Salida El sistema genera un dataset con 500 cuerpos de un artefactos, 200 cuerpos de dos artefactos y 100 cuerpos de tres artefactos. Requisitos asociados RF16 Necesidades del entorno Debe existir el usuario “robert plant”. Resultado ´ Exito Cuadro 7.24: Caso de prueba unitario P4.4. CAP´ ITULO 7. PRUEBAS Y VALIDACI ´ ON 135 ID P4.5 Entrada Se accede a la secci´on de Datasets, utilizando la cuenta del usuario “robert plant”. Salida El sistema muestra los datasets con ID 1 e ID 2. Requisitos asociados RF17 Necesidades del entorno Debe existir el usuario “robert plant”. Debe existir el dataset con ID 1 y su creador debe ser el usuario el usuario “robert plant”. Debe existir el dataset con ID 2, su creador debe ser el usuario el usuario “brian johnson” y debe tener visibilidad p´ublica. Debe existir el dataset con ID 3, su creador debe ser el usuario el usuario “brian johnson” y debe tener visibilidad privada. Resultado ´ Exito Cuadro 7.25: Caso de prueba unitario P4.5. ID P4.6 Entrada Se accede a la secci´on de Datasets, utilizando la cuenta del usuario “robert plant”. Para el dataset con ID 1, se selecciona la opci´on Descargar dataset. A contiuaci´on, se selecciona el directorio en el que se guardar´a el archivo descargado Salida Se descarga el dataset con ID 1 en formato CSV en el directorio del equipo del usuario indicado por ´este. Requisitos asociados RF18 Necesidades del entorno Debe existir el usuario “robert plant”. Debe existir el dataset con ID 1. Resultado ´ Exito Cuadro 7.26: Caso de prueba unitario P4.6. CAP´ ITULO 7. PRUEBAS Y VALIDACI ´ ON 136 ID P4.7 Entrada Se accede a la secci´on de Datasets, utilizando la cuenta del usuario “robert plant”. Para el dataset con ID 5, se selecciona la opci´on Eliminar dataset. A continuaci´on, se confirma la eliminaci´on. Salida Se descarga el dataset con ID 5 en formato CSV en el directorio del equipo del usuario indicado por ´este. Requisitos asociados RF19 Necesidades del entorno Debe existir el usuario “robert plant”. Debe existir el dataset con ID 5, su creador debe ser el usuario “robert plant” y el dataset no puede haber sido usado para entrenar ning´un modelo del sistema ni puede estar utiliz´andose para entrenar ning´un modelo del sistema. Resultado ´ Exito Cuadro 7.27: Caso de prueba unitario P4.7. ID P4.8 Entrada Se accede a la secci´on de Datasets, utilizando la cuenta del usuario “robert plant”. Para el dataset con ID 5, se selecciona la opci´on Eliminar dataset. A continuaci´on, se confirma la eliminaci´on. Salida El sistema muestra un error al usuario indic´andole que no puede eliminar un dataset asociado a un modelo del sistema. Requisitos asociados RF19 Necesidades del entorno Debe existir el usuario “robert plant”. Debe existir el dataset con ID 5, su creador debe ser el usuario “robert plant” y el dataset debe estar asociado a un modelo del sistema. Resultado ´ Exito Cuadro 7.28: Caso de prueba unitario P4.8. CAP´ ITULO 7. PRUEBAS Y VALIDACI ´ ON 137 ID P4.9 Entrada Se accede a la secci´on de Datasets, utilizando la cuenta del usuario “robert plant”. Para el dataset con ID 5, se selecciona la opci´on Eliminar dataset. A continuaci´on, se confirma la eliminaci´on. Salida El sistema muestra un error al usuario indic´andole que no puede eliminar un dataset asociado a un modelo del sistema. Requisitos asociados RF19 Necesidades del entorno Debe existir el usuario “robert plant”. Debe existir el dataset con ID 6, su creador debe ser el usuario “robert plant” y el dataset no debe estar asociado a ning´un modelo del sistema. Resultado ´ Exito Cuadro 7.29: Caso de prueba unitario P4.9. 7.1.5. Prueba de tareas (P5) ID P5.1 Entrada Se accede a la secci´on de Entrenamientos, utilizando la cuenta del usuario “robert plant”. Salida El sistema muestra al usuario la lista de sus entrenamientos en curso, integrada ´unicamente por el modelo con id 7 y las lista de entrenamientos finalizados, integrada ´unicamente por el modelo con id 8. Requisitos asociados RF20 Necesidades del entorno Debe existir el usuario “robert plant”. Debe existir el usuario “brian johnson”. Debe existir un entrenamiento en curso de un modelo de tipo Red neuronal con id 7 iniciado por el usuario “robert plant”. Debe existir un entrenamiento finalizado de un modelo de tipo Ranfom forest con id 8, iniciado por el usuario “robert plant”. Debe existir un entrenamiento en curso de un modelo de tipo Ranfom forest con id 9, iniciado por el usuario “brian johnson”. Resultado ´ Exito Cuadro 7.30: Caso de prueba unitario P5.1. CAP´ ITULO 7. PRUEBAS Y VALIDACI ´ ON 138 ID P5.2 Entrada Se accede a la secci´on de Datasets en generaci´on, utilizando la cuenta del usuario “robert plant”. Salida El sistema muestra al usuario la lista de sus datasets en generaci´on, integrada ´unicamente por el dataset con id 7 y las lista de datasets generados, integrada ´unicamente por el dataset con id 8. Requisitos asociados RF21 Necesidades del entorno Debe existir el usuario “robert plant”. Debe existir el usuario “brian johnson”. Debe existir un dataset en generaci´on con id 7 creado por el usuario “robert plant”. Debe existir un dataset ya generado con id 8, creado por el usuario “robert plant”. Debe existir un dataset en generaci´on con id 9, creado por el usuario “brian johnson”. Resultado ´ Exito Cuadro 7.31: Caso de prueba unitario P5.2. 7.2. Validaci´on por parte de los usuarios 7.2.1. Cuestionario de usabilidad Las pruebas de validaci´on por parte de los usuarios consistir´an en la evaluaci´on de la usabilidad de la aplicaci´on. Para ello, se ha elaborado un cuestionario, empleando la herramienta de formularios de Google. Cada una de las preguntas del cuestionario pretende analizar aspectos de la aplicaci´on relacionados con su grado de usabilidad. El modelo de respuesta que se le presenta al usuario en ocho de las diez preguntas del cuestionario es el siguiente: Muy de acuerdo De acuerdo Neutral En desacuerdo Muy en desacuerdo En nueve de las diez preguntas, el usuario tiene cinco opciones para expresar su grado de acuerdo con la afirmaci´on que se le propone. Sin embargo, en la pregunta 10, el usuario dispone de varias l´ıneas para escribir un breve comentario. CAP´ ITULO 7. PRUEBAS Y VALIDACI ´ ON 139 Las preguntas de las que consta el cuestionario son las siguientes: 1. He podido reconstruir f´acilmente la imagen de una malla perteneciente a un dataset. 2. He logrado subir con facilidad un fichero de mallas al sistema y he podido reconstruir f´acilmente la imagen de una de esas mallas. 3. He podido entrenar un modelo de tipo red neuronal con facilidad. 4. He conseguido generar un dataset sin dificultad. 5. He logrado eliminar un modelo o un dataset sin problemas. 6. He podido consultar f´acilmente qu´e tareas ten´ıa en curso. 7. He podido cancelar una tarea con facilidad. 8. En todo momento sab´ıa en qu´e parte de la aplicaci´on me encontraba. 9. La secci´on de Ayuda me ha resultado ´util. 10. ¿Incluir´ıas alg´un cambio o mejora en la aplicaci´on? 7.2.2. Resultados obtenidos La aplicaci´on fue probada por cuatro usuarios, los cuales completaron el cuestionario presentado en el apartado anterior. En la tabla 7.32 se muestran los resultados obtenidos, as´ı como la puntuaci´on media para cada pregunta del cuestionario. Usuario 1 Usuario 2 Usuario 3 Usuario 4 Media por pregunta P1 4 5 5 5 4.75 P2 45454.5 P3 55555 P4 4 5 5 5 4.75 P5 55555 P6 55555 P7 55555 P8 4 5 5 5 4.75 P9 34544 Cuadro 7.32: Resultados de las pruebas de validaci´on por parte de los usuarios. CAP´ ITULO 7. PRUEBAS Y VALIDACI ´ ON 140 La calificaci´on media obtenida es de 4.75, por lo que se cumple con el requisito no funcional RNF3 (tabla 3.27), dado que la puntuaci´on de usabilidad es superior a 4 puntos. Respecto a la cuesti´on 10, en la que se preguntaba al usuario si realizar´ıa alg´un cambio o mejora, ninguno de los usuarios propuso modificaciones. No obstante, examinando la puntuaci´on media obtenida en cada una de las preguntas, se observa que la pregunta 9, relativa a la utilidad de la secci´on de Ayuda, es la que obtuvo una calificaci´on menor. Por esta raz´on, se decidi´o ampliar los textos de ayuda de la aplicaci´on, ofreciendo explicaciones m´as detalladas sobre el uso del sistema. Cap´ıtulo 8 Conclusiones y posibles ampliaciones El proyecto propuesto para el TFG pudo ser completado con ´exito, a pesar de haber tenido que afrontar los inconvenientes que la crisis del coronavirus ha supuesto. El haber desarrollado el proyecto durante una situaci´on de crisis ha puesto de manifiesto la extrema importancia de las fases de planificaci´on y gesti´on de riesgos. La situaci´on en la que se desarrolla cualquier proyecto de Ingenier´ıa puede verse afectada por factores externos con los que no se cuenta inicialmente, pero dichos factores deben gestionarse de manera que puedan alcanzarse igualmente los objetivos del proyecto. Un aspecto caracter´ıstico del TFG realizado es la formaci´on Durante el transcurso del proyecto se han combinado dos ramas del conocimiento diferentes: la Ingenier´ıa del Software y la Ciencia de Datos. El sistema SageTomo es el resultado de la uni´on de estas dos disciplinas. Sin embargo, la ejecuci´on de dicha uni´on de manera satisfactoria present´o ciertas dificultades. El principal problema afrontado a lo largo del transcurso del proyecto fue la necesidad de trabajar con tecnolog´ıas muy diferentes. Tal y como se ha mencionado, se consider´o que Python era el lenguaje m´as apropiado para implementar las funcionalidades asociadas al ´ambito del Machine Learning. Sin embargo, la herramienta EIDORS para simular las tomograf´ıas de impedancia el´ectrica es una biblioteca de MATLAB. Por esta raz´on, fue necesario realizar un an´alisis para determinar el mejor modo de integrar ambas tecnolog´ıas. Por otra parte, tambi´en se decidi´o que la forma de maximizar la utilidad de un sistema de este tipo era el empleo de servicios web. Partiendo de esta decisi´on, fue necesario encontrar la tecnolog´ıa adecuada para ofrecer dichos servicios, concluyendo que el framework Django REST se adaptaba con creces a las necesidades del proyecto. Por tanto, la principal conclusi´on extra´ıda de la realizaci´on de este trabajo es que el empleo de 141 CAP´ ITULO 8. CONCLUSIONES Y POSIBLES AMPLIACIONES 142 tecnolog´ıas de caracter´ısticas diferentes no impide alcanzar resultados ´optimos, siempre y cuando las tecnolog´ıas se integren de forma correcta. Finalmente, cabe destacar que las t´ecnicas de IA utilizadas para la realizaci´on de las tomograf´ıas de impedancia el´ectrica permiten sustituir con ´exito a las t´ecnicas anal´ıticas tradicionales, muy costosas en recursos temporales y computacionales. Empleando este tipo de t´ecnicas en un ´ambito industrial puede mejorarse la eficiencia de los procesos de an´alisis del interior de cuerpos. En la introducci´on de este trabajo se plante´o el caso de la industria maderera, en la cual es necesario analizar la distribuci´on de humedad de productos de madera, de forma que si se detecta un producto defectuoso, se descarta todo el lote al que pertenece el producto. Mediante el empleo de las t´ecnicas de IA propuestas en este trabajo, ser´ıa posible analizar todos los productos de un lote y descartar ´unicamente las piezas defectuosas. ´ Este es un ejemplo m´as de c´omo las t´ecnicas de Inteligencia Artificial tienen el potencial de penetrar en pr´acticamente todos los ´ambitos industriales y econ´omicos, permitiendo que se est´e produciendo la denominada Cuarta Revoluci´on Industrial. 8.1. Posibles ampliaciones En este proyecto se han utilizado mallas de 844 elementos triangulares. El n´umero de elementos triangulares es un factor que depende del n´umero de electrodos utilizados para generar los voltajes. En el sistema SageTomo se utilizan 16 electrodos a la hora de generar un dataset. Una ampliaci´on interesante del sistema consistir´ıa en incluir la posibilidad de generar datasets eligiendo el n´umero de electrodos que se desea utilizar. Utilizar un mayor n´umero de electrodos implicar´ıa que las mallas estar´ıan divididas en un n´umero mayor de elementos triangulares. En este escenario, se deber´ıa estudiar si esta mayor granularidad en las mallas implica un incremento en la precisi´on de las predicciones de los modelos.