Desarrollo de una app móvil para la explotación de una base de datos de pigmentos

Universidad de Valladolild Escuela de Ingenier´ıa Inform´atica TRABAJO DE FIN DE GRADO Grado en Ingenier´ıa Inform´atica, Menci´on en Tecnolog´ıas de la Informaci´on y de la Comunicaci´on Desarrollo de una app m´ovil para la explotaci´on de una base de datos de pigmentos Autor: Sergio Esteban Pellejero Universidad de Valladolild Escuela de Ingenier´ıa Inform´atica TRABAJO DE FIN DE GRADO Grado en Ingenier´ıa Inform´atica, Menci´on en Tecnolog´ıas de la Informaci´on y de la Comunicaci´on Desarrollo de una app m´ovil para la explotaci´on de una base de datos de pigmentos Autor: Sergio Esteban Pellejero Tutor: Joaqu´ın Adiego Rodriguez Angel Carmelo Prieto Colorado UVa Trabajo Fin Grado Resumen El fin de este trabajo de fin de grado es recrear una antigua p´agina web que explotaba una base de datos orientada a la pigmentaci´on. La aplicaci´on antigua hecha en forma de web ha sido trasladada a una aplicaci´on m´ovil capaz de ejecutarse en cualquier dispositivo con Android que hay en la actualidad. La utilidad principal de desarrollo de esta aplicaci´on es permitir que cualquier cient´ıfico o persona especializada en el campo de la restauraci´on, tenga de manera accesible, r´apida y sencilla la informaci´on necesaria acerca de todos los pigmentos naturales que se encuentran en la Tierra. Este prop´osito se ha conseguido redise˜nando una base de datos ya existente con toda esta informaci´on adem´as de generar la informaci´on que faltaba o estaba corrupta. Desarrollando en Android de la mano del cliente una aplicaci´on que cumple los requisitos del mismo y ofreci´endola de manera gratuita en la tienda de Google para que cualquier persona la tenga a su disposici´on. Uno de los principales retos que se han planteado durante el desarrollo de la aplicaci´on ha sido tratar con cantidades muy grandes de datos en tiempos de reacci´on para el ojo humano casi imperceptibles. Aplicaci´on base datos pigmentos 1 UVa Trabajo Fin Grado ´ Indice ´ Indice 2 ´ Indice de figuras 4 1. Introducci´on 1 1.1. Prefacio ......................................... 1 1.2. Visi´onglobal ...................................... 1 1.3. Marcodedesarrollo................................... 2 1.4. Objetivos ........................................ 2 1.5. Beneficios ........................................ 2 1.6. T´ecnicas experimentales y medidas . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Fundamentos y herramientas 5 2.1. Metodolog´ıa....................................... 5 2.1.1. Kanban ..................................... 5 2.1.2. Gitflow...................................... 7 2.2. Herramientas y tecnolog´ıas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.2.1. Taiga....................................... 9 2.2.2. SonarQube ................................... 11 2.2.3. SonarLint .................................... 13 2.2.4. Jenkins ..................................... 14 2.2.5. AndroidStudio ................................. 16 2.2.6. Github...................................... 17 2.2.7. Overleaf..................................... 17 2.2.8. SQLite...................................... 18 2.3. BalsamiqMockups3 .................................. 18 2.4. Resumendelamemoria ................................ 19 3. Planificaci´on y gesti´on del proyecto 20 3.1. Necesidad de planificaci´on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 3.2. Definici´on del alcance y objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 3.3. Tiempodedesarrollo.................................. 21 3.4. Recursosycostes .................................... 21 3.4.1. Recursosytipos ................................ 21 3.4.2. Estimaci´on de los costes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 3.5. Tratamiento de los riesgos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 3.6. Control de configuraciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 3.7. Calidad de los productos entregados . . . . . . . . . . . . . . . . . . . . . . . . . . 25 4. Dise˜no 27 4.1. Volviendo al desarrollo en cascada . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 4.2. Definici´ondecriterios.................................. 32 4.2.1. Definici´ondehecho............................... 32 4.2.2. Criterios de aceptaci´on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Aplicaci´on base datos pigmentos 2 UVa Trabajo Fin Grado 4.3. ´ Epicas e historias de usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 4.3.1. ´ Epicas...................................... 35 4.3.2. Historiasdeusuario............................... 35 4.4. Backlog ......................................... 37 4.5. Bocetosiniciales..................................... 43 4.5.1. Logo de la aplicaci´on y nombre . . . . . . . . . . . . . . . . . . . . . . . . 43 4.5.2. Dise˜no de las primeras interfaces . . . . . . . . . . . . . . . . . . . . . . . 45 4.6. Sistema de Integraci´on continua . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 5. Dise˜no de la base de datos 53 5.1. Suposiciones y convenciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 5.2. Posibles consultas contra la BBDD . . . . . . . . . . . . . . . . . . . . . . . . . . 53 5.3. Modeladoconceptual.................................. 54 5.3.1. Entidadesyatributos.............................. 54 5.3.2. Diagrama de Entidad Relaci´on . . . . . . . . . . . . . . . . . . . . . . . . . 56 5.4. Implementaci´on de la base de datos . . . . . . . . . . . . . . . . . . . . . . . . . . 57 5.4.1. ¿QuesonlosPOJO? .............................. 58 5.4.2. Ejemplo ..................................... 59 5.5. Otrasconsideraciones.................................. 62 5.5.1. Dise˜no antiguo VS dise˜no actual . . . . . . . . . . . . . . . . . . . . . . . . 62 5.5.2. C´odigo frente a eficacia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 5.5.3. Scriptsnecesarios................................ 64 5.6. Tratamiento de las BBDD en Android . . . . . . . . . . . . . . . . . . . . . . . . 65 6. Gu´ıa de Instalaci´on y Manual de Usuario 67 6.1. Gu´ıadeInstalaci´on................................... 67 6.2. ManualdeUsuario ................................... 67 7. Problemas durante el desarrollo 69 8. Conclusiones Finales 71 Referencias 72 Aplicaci´on base datos pigmentos 3 UVa Trabajo Fin Grado ´ Indice de figuras 1. Patr´oncompleto .................................... 8 2. Patr´onDerivado..................................... 9 3. TablerodeTaiga.io................................... 10 4. Configuraci´on del fichero build.gradle . . . . . . . . . . . . . . . . . . . . . . . . . 12 5. Primer an´alisis del c´odigo inicial generado por Android Studio . . . . . . . . . . . 13 6. TareaGradleparaSonar................................ 13 7. SonarLint en Android Studio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 8. FlujoseguidoporJenkins ............................... 15 9. PanelGeneraldejenkins................................ 16 10. Interfaz principal de Balsamiq Mockups . . . . . . . . . . . . . . . . . . . . . . . . 18 11. Flujo de Integraci´on continua . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 12. DiagramadeCasosdeUso............................... 28 13. Diagrama de Paquetes a alto nivel . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 14. Diagrama de secuencia de alto nivel para ver la informaci´on de un pigmento . . . 31 15. Relaci´on entre ´epicas, historias y temas . . . . . . . . . . . . . . . . . . . . . . . . 34 16. Formato que seguir´an las historias de usuario . . . . . . . . . . . . . . . . . . . . . 36 17. Diagrama de precedencia de las principales tareas . . . . . . . . . . . . . . . . . . 42 18. Dise˜no 1 del logo de la aplicaci´on . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 19. Dise˜no 1 del logo de la aplicaci´on . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 20. Dise˜no final del logo de la aplicaci´on . . . . . . . . . . . . . . . . . . . . . . . . . 44 21. Men´u principal de la aplicaci´on . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 22. Lista principal con todos los pigmentos del sistema . . . . . . . . . . . . . . . . . 47 23. Informaci´on de los pigmentos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 24. Informaci´on gr´aficas de pigmentos . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 25. Men´u para hacer una consulta simple . . . . . . . . . . . . . . . . . . . . . . . . . 49 26. Men´u de selecci´on de colores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 27. Men´u de selecci´on de elementos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 28. Men´u de selecci´on de colores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 29. Men´u de selecci´on de elementos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 30. Men´udereportedefallos ............................... 51 31. Entidades y cardinalidades del modelo . . . . . . . . . . . . . . . . . . . . . . . . 56 32. Diagrama de Entidad-Relaci´on de la base de datos . . . . . . . . . . . . . . . . . . 57 33. Dise˜no propuesto en Access de la Base de Datos . . . . . . . . . . . . . . . . . . . 63 34. Dise˜no propio de la base de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 Aplicaci´on base datos pigmentos 4 UVa Trabajo Fin Grado 1. Introducci´on En esta secci´on vamos a comentar, el objetivo de este trabajo de fin de grado, la metodolog´ıa utilizada para llevar a cabo el desarrollo, ya que es un proyecto puramente de desarrollo de una aplicaci´on m´ovil con un fin determinado y focalizado. Tambi´en se expondr´an los principales objetivos que han motivado al alumno. 1.1. Prefacio Durante estos ´ultimos a˜nos debido a la situaci´on econ´omica y pol´ıtica de Espa˜na, el sector de la conservaci´on y la restauraci´on del patrimonio cultural se ha dejado un poco de lado, aunque sigue a la cabeza de tecnolog´ıa para restauraci´on. Al mismo tiempo, se trata de un campo de trabajo que demanda amplia informaci´on, especialmente en lo relativo a la utilizaci´on de nuevas tecnolog´ıas, tanto de tratamiento como de estudio, para evitar intervenciones desafortunadas que han hecho peligrar el estado de conservaci´on de muchas obras de nuestro rico patrimonio. A d´ıa de hoy contamos con tecnolog´ıa puntera en Europa como pueden ser los esc´aneres en 3D de zonas muy amplias, estos esc´aneres nos ofrecen im´agenes de muy alta resoluci´on que los historiadores y profesionales de la materia precian enormemente para evitar deteriora las obras reales. Por citar algunas de las otras tecnolog´ıas que podemos encontrar en el ´ambito de la restauraci´on pueden ser: tomograf´ıa, microscop´ıa ´optica, envejecimiento artificial (cada vez mas desarrollado con los potentes ordenadores con los que contamos), espectrofotometr´ıa infrarroja por transformaci´on de Fourier son algunos de los m´etodos que podemos aplicar cuando se trata de restaurar nuestro patrimonio. Este proyecto trata de facilitar tanto la b´usqueda como la utilizaci´on de informaci´on relacionada con el sector de la restauraci´on y conservaci´on del patrimonio, para que profesionales dedicados a este campo puedan encontrar un punto de referencia pr´actico y de f´acil acceso que les ayude en sus investigaciones y proyectos y que est´e al alcance de todas las personas. 1.2. Visi´on global Este proyecto consiste en la creaci´on de una aplicaci´on m´ovil que explote de una manera adecuada una base de datos ya existente sobre pigmentos naturales y sint´eticos. Dicha base de datos posee informaci´on tanto de las propiedades colorim´etricas como estructurales de cada pigmento, dichos datos han sido recogidos mediante la aplicaci´on de t´ecnicas experimentales en laboratorios con los instrumentos adecuados. M´as adelante hablaremos brevemente. Esta aplicaci´on tiene que ofrecer al usuario la capacidad de obtener de manera sencilla e intuitiva informaci´on compleja acerca de los diferentes pigmentos. Adem´as de cada uno de ellos vamos a Aplicaci´on base datos pigmentos 1 UVa Trabajo Fin Grado hablar tambi´en acerca de sus diferentes usos y de las t´ecnicas por las que se han obtenido dichas medidas, y quiz´a en algunos de ellos (en los que al cient´ıfico director le parezca mas relevante) se podr´an a˜nadir notas curiosas, como por ejemplo de la obtenci´on de dicho pigmento o de usos pintorescos del mismo a lo largo de la historia. La base de datos, como hemos dicho ya existe, la idea y objeto principal de este proyecto es el desarrollo de una aplicaci´on capaz de funcionar en un porcentaje elevado de los dispositivos m´oviles actuales sino en todos. 1.3. Marco de desarrollo El actual proyecto esta asentado sobre un proyecto m´as grande y ya existente, que como dijimos era el que nos aportaba la informaci´on acerca de los pigmentos y de las muestras. Dicho proyecto: ”La aplicaci´on de la t´ecnica l´aser a la conservaci´on del patrimonio”fue desarrollado por el Departamento de F´ısica de la Materia Condensada, Cristalograf´ıa de la Universidad de Valldolid en colaboraci´on con el Centro Tecnolog´ıa L´aser. Aunque esta informaci´on es pasada, me parece como menos importante nombrar dicho proyecto, ya que asienta las bases actuales y todas las medidas e informaci´on presente sobre las que se va a desarrollar la aplicaci´on m´ovil. 1.4. Objetivos EL objetivo principal es facilitar tanto la b´usqueda como al utilizaci´on y acceso a la informaci´on por parte de toda la poblaci´on de posibles usuarios. La manipulaci´on de la base de datos actual es bastante sencilla, por lo que con el paso de los a˜nos si futuras investigaciones en este campo lo desean pueden ir actualizando la informaci´on. Adem´as la presentaci´on sencilla, accesible e intuitiva de la informaci´on hacen que no se requieran conocimientos previos en la materia para sacar conclusiones u obtener informaci´on de manera r´apida, precisa y veraz. Otro objetivo es poner a disposici´on de empresas y cient´ıficos la informaci´on recopilada por otros cient´ıficos. Al final la ciencia no progresa si las personas no ponemos de nuestro lado, si cada una de las futuras investigaciones en la materia aporta informaci´on a la base de datos, por poca que sea, la ciencia se perpet´ua. 1.5. Beneficios A continuaci´on destacaremos algunas de las posibles aplicaciones que tiene este proyecto, incluyendo las posibles utilidades que supondr´a su culminaci´on para diversos colectivos. La utilizaci´on de determinados pigmentos y aglutinantes, as´ı como sus mezclas, es en muchas ocasiones caracter´ıstico de la obra de un autor, as´ı como de la ´epoca, zona de influencia y desarrollo del arte en un periodo hist´orico concreto. De esta forma, los estudios realizados a trav´es de las Aplicaci´on base datos pigmentos 2 UVa Trabajo Fin Grado t´ecnicas instrumentales descritas anteriormente pueden ser aplicados en tareas de identificaci´on, dataci´on y autentificaci´on de obras de arte. Los expertos encargados de realizar estas tareas pueden beneficiarse de la creaci´on de la base de datos, ya que podr´an recurrir a ella para realizar contrastes entre los registros obtenidos en el laboratorio y aquellos recogidos en la base. Los profesionales de empresas de restauraci´on necesitan en ocasiones reintegrar partes da˜nadas siguiendo las t´ecnicas originales. Requieren por lo tanto conocer los or´ıgenes de los pigmentos empleados con el fin de acometer las obras de restauraci´on en las mejores condiciones. Estos expertos pueden beneficiarse de la creaci´on de la base de datos, puesto que podr´an acceder a diverso tipo de informaci´on obtenida a trav´es de potentes herramientas anal´ıticas de una forma f´acil y con una disponibilidad total una vez registrados como usuarios autorizados. Generar una aplicaci´on m´ovil disponible en un dispositivo que podemos llevar a cualquier lugar es una importante innovaci´on por el hecho de que esta herramienta puede ser utilizada de manera directa e inmediata por las empresas y por los expertos de instituciones y organismos dedicados a la restauraci´on y conservaci´on del patrimonio hist´orico-art´ıstico, que muchas veces deben de decidir en un corto espacio de tiempo el tratamiento m´as adecuado para restaurar una determinada obra. Cada uno de los restauradores que tenemos en el territorio puede tener instalada dicha aplicaci´on y visualizar m´etricas y datos mientras realiza trabajos de campo, sin necesidad de acceso a Internet, de una manera r´apida y sencilla. La disponibilidad de la informaci´on es crucial en el desarrollo de este proyecto. De la misma forma, la aplicaci´on m´ovil desarrollada permitir´a poner en contacto a diversos colectivos de profesionales que realizan sus investigaciones en todo el mundo, as´ı como obtener informaci´on complementaria a estas como bibliograf´ıa, ya sea en forma de libro o medio digital. 1.6. T´ecnicas experimentales y medidas En esta parte vamos a hablar de las diferentes t´ecnicas experimentales que han sido usadas para obtener los pigmentos, junto con algunas de las medidas que vamos a presentar dentro de la aplicaci´on. Esto no es del ´ambito inform´atico pero tiene una cierta importancia a la hora de entender las gr´aficas que m´as adelante se mostrar´an a los diferentes usuarios. Las principales t´ecnicas y m´etodos de an´alisis de los que se han dispuesto para la elaboraci´on de las bases de datos son los siguientes: An´alisis micro colorim´etrico - Determinaci´on de coordenadas tricr´omicas: las coordenadas tricr´omicas permiten situar al pigmento dentro de un mapa crom´atico sin ambig¨uedad alguna, posibilitando el estudio del grado de evoluci´on crom´ofora del pigmento en funci´on de su antig¨uedad, composici´on mineral´ogica, procedencia y posible evoluci´on temporal y espacial, e interacci´on con otros pigmentos. Difracci´on de rayos-x: el an´alisis del difractograma de rayos X, permiten obtener con rigor las fases mineral´ogicas presentes en el material pigmentante. Los minerales accesorios a veces son de relevante importancia dado que posibilitan determinar ´areas de procedencia Aplicaci´on base datos pigmentos 3 UVa Trabajo Fin Grado creaci´on de proyectos p´ublicos o privaos como en Github. Cada uno de estos proyectos te deja seleccionar si ha de seguir el modelo Kanban o Scrum, para poner la configuraci´on por defecto del mismo. Una vez creado el proyecto, el tablero principal de control de proyecto, con algunas tareas a˜nadidas queda de la siguiente manera: Figura 3: Tablero de Taiga.io En la figura anterior podemos ver el proyecto publico donde se ira actualizando el proceso de creaci´on de este mismo documento y de todo el trabajo de fin de grado []. Adem´as podemos observar las principales columnas que hemos nombrado anteriormente cuando describ´ıamos la metodolog´ıa de trabajo. Adem´as del tablero principal, esta herramienta nos permite muchas mas opciones, como las siguientes: Timeline: en este apartado, podemos ver la cronolog´ıa de todas las actividades realizadas en el proyecto, desde cuando se ha creado una tarea, cuando se ha actualizado el ultimo issue encontrado o cuando se ha a˜nadido o quitado informaci´on a la wiki del proyecto. Backlog: aqu´ı podemos encontrar todas las tareas, historias de usuario y issues que hemos ido creando en el proyecto. Se presentan de forma resumida, con el estado principal, fecha de creaci´on, etc. Issues: los issues o problemas, son los diferentes problemas o bugs que nos vamos encontrando conforme el desarrollo de la aplicaci´on se va realizando. Aplicaci´on base datos pigmentos 10 UVa Trabajo Fin Grado Wiki: nos proporciona una herramienta de documentaci´on interna para el proyecto. Podemos asemejar esta wiki a Confluence [14], que es una herramienta de pago creada por la empresa Atlassian, para tener informaci´on y documentaci´on en la nube. Nosotros usaremos esta wiki para anotar cosas puntuales de desarrollo o configuraci´on. Members: podemos ver a los dem´as miembros del equipo, en este caso solo voy a ser por lo que este apartado carece de especial importancia. Podemos encontrar el proyecto de este trabajo de fin de grado en la siguiente direcci´on 1. 2.2.2. SonarQube SonarQube [7] es una herramienta que nos permite obtener m´etricas y medidas de la calidad de nuestro c´odigo. Nos permite obtener m´etricas generales de la calidad el c´odigo, a nivel de buenas y malas practicas que estamos cumpliendo, posibles vulnerabilidades junto con el nivel de criticidad de las mismas, nivel de complejidad de diversos tipos, como por ejemplo la ciclom´atica 2. He decidido integrar SonarQube y otras tecnolog´ıas en contenedores Docker [15] En realidad no se gana demasiado dockerizando las herramientas, pero si que es verdad que permite una mayor flexibilidad, a la hora de recrear esa instancia, simplemente tenemos que copiar y pegar el bakcup de la imagen. Dockerizar los servidores en contenedores individuales es una buena medida de seguridad si la aplicaci´on estuviera en producci´on y se sirvieran los servicios hacia el exterior. Nosotros vamos a integrar SonarQube y medir la calidad de nuestro c´odigo de 3 maneras diferentes. La primera y mas directa es en nuestro proyecto de Android Studio junto con Gradle [16]. Ya que los proyectos de aplicaciones m´oviles de Android se hacen con el constructor Gradle, y Sonar (acortaci´on de SonarQube de aqu´ı en adelante) tiene integraci´on con dicha herramienta, solo tenemos que crear el proyecto en el servidor previamente desplegado en docker e introducir las siguientes lineas de c´odigo en el fichero build.gradle de nuestra aplicaci´on, mostrado en la figura 6. Creamos la tarea en gradle correspondiente para enviar la informaci´on a nuestro servidor de an´alisis y el resultado es el mostrado en la siguiente figura: 1https://tree.taiga.io/project/sergioestebanp-tfg/kanban 2La complejidad ciclot´ımica se mide en la cantidad de caminos individuales que se pueden recorrer en nuestro c´odigo. Cuanta menor complejidad ciclot´ımica mejor es la calidad del c´odigo Aplicaci´on base datos pigmentos 11 UVa Trabajo Fin Grado 1// Top−l e v e l build f i l e where you can add con figurat io n options common 2// to a l l sub−p r o j e c t s /modules . 3 4 buildscript { 5 repositories { 6 google () 7 j c e n t e r ( ) 8 9} 10 dependencies { 11 c la sspa th ’com . android . t o o l s . buil d : gra dl e : 3 . 3 . 2 ’ 12 13 // NOTE: Do not place your ap p l ication dependencies here ; 14 // they belong 15 // in the i n d i v i d u a l module build . gradle f i l e s 16 } 17 } 18 19 plugins { 20 id ”org . sonarqube” version ” 2.6 ” 21 } 22 23 allprojects { 24 repositories { 25 google () 26 j c e n t e r ( ) 27 28 } 29 } 30 31 task clean ( type : Delete ) { 32 delete rootProject . buildDir 33 } Figura 4: Configuraci´on del fichero build.gradle Aplicaci´on base datos pigmentos 12 UVa Trabajo Fin Grado Figura 5: Primer an´alisis del c´odigo inicial generado por Android Studio Figura 6: Tarea Gradle para Sonar Una vez tenemos estos par´ametros colocados y el servidor funcionando, podemos pasar a la configuraci´on de SonarLint. 2.2.3. SonarLint SonarLint [8] es un plugin para los entornos de desarrollo proporcionados por JetBrains, como Intellij IDEA o Android Studio. SonarLint nos proporciona la potencia de SonarQube pero sin tener que estar ejecutando el codigo en el servidor de manera constante. Lo que hacemos es configurar nuestro servidor de SonarQube en el plugin, y cada vez que abrimos un fichero de tipo Aplicaci´on base datos pigmentos 13 UVa Trabajo Fin Grado Java, el plugin pasa el fichero por el servidor y nos devuelve los resultados de una manera muy agradable. Podemos ver un ejemplo del uso de SonarLint en la siguiente figura: Figura 7: SonarLint en Android Studio En el recuadro de color azul, podemos apreciar como el plugin nos muestra las vulnerabilidades de c´odigo. En el recuadro naranja nos lista todas las posibles vulnerabilidades o fallos que tiene nuestro software, y en el recuadro verde nos pone lo que significan, argumentos de porqu´e ese c´odigo no es de calidad y lo m´as importante, es que nos pone ejemplos para solucionarlo de manera sencilla y eficaz. 2.2.4. Jenkins Jenkins [9] es una herramienta basada en la integraci´on continua de productos software y en el desarrollo continuo. En nuestro caso lo vamos a usar como tal. Como todo producto software, nuestra aplicaci´on va a requerir pruebas, tanto unitarias como de otros tipos. La idea es meter toda esta suite de pruebas en jenkins e integrarla tanto con github como con sonar. Lo que vamos a hacer es definir una serie de casos de prueba, tanto a nivel unitario como test de regresi´on, para que cada vez que el c´odigo se vea modificado por una Pull Request (nada m´as all´a de una solicitud de cambio), la aplicaci´on tenga que pasar los test satisfactoriamente para comprobar que no hemos roto lo anterior. Esto es para lo que vamos a usar Jenkins principalmente. Adem´as como Jenkins tiene muchas utilidades, tambi´en podemos integrar SonarQube para que nos notifique en caso de que en una Pull Request la calidad de nuestro c´odigo se vea afectada a peor. Un ejemplo de la estructura y flujo que sigue Jenkins es el siguiente: Aplicaci´on base datos pigmentos 14 UVa Trabajo Fin Grado Figura 8: Flujo seguido por Jenkins En Jenkins nosotros lo que definimos son un flujo por el que pasar´a nuestra aplicaci´on. En el caso de nuestra aplicaci´on seguramente tendremos dos flujos diferentes, uno para pasar los test unitarios cada vez que hagamos una propuesta de cambio a nuestro c´odigo; y otro flujo separado que ser´an las pruebas de regresi´on. Las pruebas de regresi´on las haremos cuando tengamos una base de funcionamiento de la aplicaci´on, ya que las haremos sobre la interfaz. Por ejemplo la descripci´on de los flujos seguidos ser´ıan: Pipeline ejemplo: Obtener el c´odigo →pasar las pruebas unitaras →pasar las pruebas de calidad →generar los reportes →desplegar los cambios o dar el visto bueno. Los flujos de Jenkins se describen mediante unos ficheros llamados Jenkinsfile, tambi´en pueden ser especificados en el propio servidor, pero no es una practica recomendable. Normalmente se integra en un archivo separado en el repositorio, precisamente para tener un seguimiento de los cambios que se hacen en el mismo. Dichos ficheros son escritos en groovy, que se basa en Java, pero simplificado. Un vistazo al panel general de Jenkins, es el siguiente: Aplicaci´on base datos pigmentos 15 UVa Trabajo Fin Grado Figura 9: Panel General de jenkins 2.2.5. Android Studio Android Studio [10], no hay mucho que decir, simplemente que es un entorno de desarrollo integrado que trae todas las herramientas necesarias casi de manera nativa la la programaci´on y testeo de aplicaciones para dispositivos multiplataforma, como pueden ser los productos del sistema operativo Android. Las principales herramientas que utilizaremos ser´an las ejecuciones gradle autom´aticas, la capacidad de simulaci´on de un dispositivo de la familia Android de manera casi nativa, el debugger que tiene, junto con el profiler son de gran calidad desde mi punto de vista, la integraci´on con cantidad de plugins como el ya mencionado de SonarLint o VIM son tambi´en de una calidad excelente. En general para la realizaci´on de este proyecto me he decantado por Android Studio por la centralizaci´on de las herramientas que trae el propio IDE. Al igual que estamos desarrollando con este IDE se pueden configurar otros como Intellij o Visual Studio Code para trabajar de manera similar. En mi caso voy a utilizar Android Studio por la familiaridad a la hora de trabajr con ´el. Adem´as incluye ciertas herramientas de manera nativa, que de otra tendr´ıamos que instalar a parte. Estas herramientas son por ejemplo el gestor del Android Software Development Kit [23] y el Android Virtual Device emulator (AVD) [22]. Aplicaci´on base datos pigmentos 16 UVa Trabajo Fin Grado 2.2.6. Github Github [11] es generalmente conocido (o deber´ıa serlo) para todos los desarrolladores que trabajan en el gremio. Ser´a utilizado como gestor de versiones de c´odigo y gestor de cambios del proyecto. Como hemos mencionado anteriormente en la metodolog´ıa (Secci´on 2.1), vamos a seguir un patr´on para la creaci´on de ramas y gestionar los cambios en el c´odigo. Github nos permite seguir estos patrones e implementarlos de una manera sencilla y eficaz. Adem´as cabe destacar que Android Studio tiene integraci´on con Github y permite de manera sencilla hacer commits, cambiar entre ramas y dem´as operaciones importantes. El repositorio de c´odigo de nuestra aplicaci´on se encontrar´a en la siguiente direcci´on: https://github.com/SergioEstebanP/TFG-PigmentationDatabaseApp 2.2.7. Overleaf Overleaf [13] es un editor de textos online que nos permite generar documentos usando L A T EX. Por comodidad a la hora de gestionar la configuraci´on del documento, se ha determinado usar latex como sistema de composici´on de textos, ya que word no ofrece las caracter´ısticas necesarias para ello. Por lo menos no para mi. Algunas de las razones elegidas son: Gesti´on autom´atica de contenidos tales como figuras, tablas, t´ıtulos o secciones. Generaci´on y gesti´on f´acil, automatice y simple de la bibliograf´ıa y las referencias. Facilidad para insertar formulas matem´aticas en caso de que fuera necesario. Configuraci´on global del documento mas sencilla y flexible que en otros sistemas como word. Inadaptaci´on de cambios gestionada por el propio sistema. Overleaf tiene plugin para escribir utilizando los atajos de VIM. El enlace al proyecto de Overleaf, donde se encuentra este mismo documento es el siguiente: https://es.overleaf.com/read/tjcbwvvdxwtq Overleaf permite la edici´on m´ultiple de documentos y adem´as tambi´en tiene un gestor de cambios integrado. El problema es que la l´ınea de cambios en el tiempo que guarda es relativamente peque˜na, y adem´as muestra los cambios de una manera poco intuitiva y eficaz. La ventaja frente subir el c´odigo fuente a Github es que sigue los cambios de manera autom´atica, mientras que subi´endolo a Github hay que hacerlo manualmente. Aplicaci´on base datos pigmentos 17 UVa Trabajo Fin Grado 2.2.8. SQLite SQLite [12] es un sistema gestor de base de datos muy sencillo, que integra Android por defecto. La idea es que la base de datos que tenemos que explotar est´e integrada junto con el c´odigo de la aplicaci´on. La base de datos parece peque˜na, por lo que no ocupar´a nada m´as que unos pocos de Mega Bytes. Adem´as, como el fichero generado para usar la aplicaci´on es un binario, la informaci´on no ser´a accesible al exterior. La informaci´on solo ser´a proporcionada por la aplicaci´on y de la manera propuesta en los cap´ıtulos posteriores. Como describiremos en los cap´ıtulos posteriores, una de las primeras tareas es investigar la estructura de la base de datos y exportarla a SQLite o MySQL, ya que son SGBD a los que estoy m´as acostumbrado y necesarios para la compatibilidad con y buena comunicaci´on de datos con la aplicaci´on. 2.3. Balsamiq Mockups 3 Esta va a ser la herramienta utilizada para el desarrollo de los bocetos de la aplicaci´on. Las opciones eran o la plataforma draw.io el programa de escritorio balsamiq mock up [18]. Como en anteriores proyectos ya he usado esta herramienta es la que usar´e en este tambi´en. A grandes rasgos nos permite dise˜nar de una manera sencilla y r´apida todo tipo de interfaces y entradas de datos visuales para un usuario. Adem´as nos permite simular de una manera bastante sencilla las diferentes interacciones que hay entra las pantallas de una misma aplicaci´on o p´agina web. Un ejemplo de la interfaz que nos ofrece esta aplicaci´on es la que se observa en esta figura: Figura 10: Interfaz principal de Balsamiq Mockups Aplicaci´on base datos pigmentos 18 UVa Trabajo Fin Grado 2.4. Resumen de la memoria En esta memoria se presentan de forma clara el desarrollo de la aplicaci´on presentada en los puntos anteriores. La idea de esta memoria no es solos describir el desarrollo sino tambi´en documentar todos los problemas que se han tenido durante el proceso, como se han resulto y cual ha sido el resultado final. En esta memoria, a modo de gu´ıa se encuentra la siguiente informaci´on, ordenada aproximadamente de la siguiente manera: Introducci´on y presentaci´on de las herramientas: es la secci´on que estamos cerrando, simplemente se ha hecho un repaso de las herramientas que se est´an usando para el proyecto, para que luego cuando se hable de ellas, no se tenga duda alguna de porque las estamos utilizando o porque no las hemos nombrado anteriormente. Investigaci´on de los documentos e informaci´on que existen a cerca de la aplicaci´on y de la base de datos. Primero haremos una peque˜na investigaci´on para saber en que formato esta la base de datos actualmente, como importarla en caso necesario a un SGBD que nos sea mas adecuado para su tratamiento y adem´as revisar la documentaci´on actual. Dicha base de datos fue explotada anteriormente por una pagina web (a˜no 2000), de la cual existe documentaci´on a d´ıa de hoy. Hay que revisar esa informaci´on y ver si se puede aprovechar algo de lo que hay ya implementado o simplemente orientar el trabajo para implementar una funcionalidad u otra. Definici´on del objetivo y del alcance del proyecto, creaci´on de los primeros diagramas, bocetos y modelos iniciales. Presentaci´on al cliente para conocer su impresi´on inicial. En esta parte no solo vamos a centrarnos en los modelos, tambi´en desarrollaremos algo de c´odigo, como prueba de concepto para ver si todo funciona. Podemos hacer esto ya que seguimos un modelo de desarrollo ´agil, lo que nos permite empezar a desarrollar productos software funcionales en poco tiempo e ir present´andoselos al cliente de manera regular. Esta fase estar´a acompa˜nada de material gr´afico, mostrando los diferentes bocetos y diagramas iniciales que compondr´an la aplicaci´on. En las subsiguientes partes de la memoria, se ira directamente a la implementaci´on y a la evoluci´on de las fases iniciales. Es evidente que un sistema de software va evolucionando con el paso del tiempo y conforme se van entendiendo los requisitos y las preferencias de funcionamiento o est´eticas del cliente. Todo esta evoluci´on, los problemas que van surgiendo y las decisiones tomadas son el objetivo de esta memoria. Al final de la memoria podemos encontrar las conclusiones finales. Las conclusiones no solo se van a centrar en si hemos logrado el objetivo principal que es el desarrollo de la aplicaci´on como tal, sino que se har´a un an´alisis introspectivo tanto al flujo de desarrollo como a las diferentes sensaciones que se han sentido durante las fases de las que ha constado el proyecto. Intentando saber si las decisiones que se han tomado han sido las correctas o no. Evidentemente este apartado constar´a de una parte en la que se indicara si hemos logrado los objetivos principales. Aplicaci´on base datos pigmentos 19 UVa Trabajo Fin Grado Podemos ver en la Figura 11, una aproximaci´on del flujo al que se va a someter las diferentes partes de c´odigo que desarrollemos en nuestra aplicaci´on. Figura 11: Flujo de Integraci´on continua Aplicaci´on base datos pigmentos 26 UVa Trabajo Fin Grado 4. Dise˜no En esta secci´on vamos a hablar del dise˜no de la aplicaci´on. Volveremos un poco al dise˜no m´as cl´asico que es el dise˜no en cascada, pero seguiremos hablando en todo momento de metodolog´ıa Kanban. 4.1. Volviendo al desarrollo en cascada Hemos dicho que la metodolog´ıa de dise˜no que vamos a usar es Kanban, pero a mi personalmente me gusta siempre dar una serie de diagramas y de ideas procedentes del cl´asico desarrollo en cascada. Ya que las metodolog´ıas ´agiles tienen unos entregables determinados y en ninguno de ellos aparecen los que yo voy a exponer a continuaci´on, pero me parecen de una gran importancia y adem´as expresan conceptos a nivel de arquitectura que a mi parecer deben de tener toda construcci´on de software. Elicitaci´on de requisitos Aunque la metodolog´ıa que est´a siguiendo el proyecto es Kanban, en todos los proyectos que he realizado me gusta introducir y recordar algunas cosas del proceso unificado. Por ejemplo la elicitaci´on de los requisitos es algo que se hace en todos los proyectos. Por ejemplo en el caso de las metodolog´ıas ´agiles el Product Owner es el encargado de hablar con el cliente y especificar al equipo cuales son los requisitos del mismo. Por lo tanto los principales requisitos b´asicos que ha de tener nuestra aplicaci´on son los siguientes: Requisitos Funcionales: •El usuario tiene que poder ver todos los pigmentos. •El usuario tiene que poder ver informaci´on de las gr´aficas de datos de los pigmentos. •El usuario tiene que poder buscar en la base de datos por nombre. •El usuario tiene que poder buscar los pigmentos en base al elemento qu´ımico principal del pigmento. •El usuario tiene que poder buscar los pigmentos en base al color principal del pigmento. •El usuario tiene que poder a˜nadir notas de cada uno de los diferentes pigmentos, para su propia colecci´on. Requisitos no Funcionales: Aplicaci´on base datos pigmentos 27 UVa Trabajo Fin Grado •La aplicaci´on tiene que ser capaz de ejecutarse en un dispositivo m´ovil. •La base de datos tiene que estar implementada en SQLite, gestor principal de los dispositivos m´oviles. Diagrama de Casos de Uso El diagrama de casos de uso va a tener una gran semejanza al backlog y las historias de usuario que tenemos en las metodolog´ıas ´agiles, pero desde mi punto de vista, este diagrama es intuitivo a la par que simple y nos permite saber lo que puede hacer un usuario de un golpe de vista. Figura 12: Diagrama de Casos de Uso Diagrama de paquetes de alto nivel Uno de los diagramas que refleja muy bien la arquitectura que va a tener el sistema es el diagrama de paquetes, en el se suelen representar los diferentes paquetes y clases principales de las que se va a componer la aplicaci´on. Podemos observar de un vistazo los principales patrones utilizados, as´ı como las principales interacciones entre las diferentes partes que componen el sistema. El diagrama de paquetes, con los principales patrones que m´as se adec´uan a la soluci´on es el mostrado en la Figura 13. En esta arquitectura a alto nivel se puede apreciar el uso del modelo MVC, donde habr´a clases que representen a la vista y accedan al modelo usando un controlador general de aplicaci´on. Luego dicho controlador de aplicaci´on es el que se encargar´a de interactuar con el resto de elementos y de proveer la informaci´on. Aplicaci´on base datos pigmentos 28 UVa Trabajo Fin Grado Una de las partes m´as importantes de esta aplicaci´on es el acceso a los datos, ya que vamos a estar interactuando de manera permanente contra una base de datos. Dichas peticiones tienen que ser eficientes y realizarse en el menor tiempo posible y de una manera sencilla. El patr´on por el que he optado ha sido un patr´on basado en objetos, es decir nosotros vamos a crear un ORM (Object Request Manager), que se va a encargar de atender las peticiones de informaci´on y va a devolver las filas de la base de datos en forma de objetos. Nuestra aplicaci´on ver´a la base de datos como grandes listas de objetos. Cada de una base de datos ser´a representada por un objeto diferente, con tantos atributos como columnas tenga dicha tabla. Cuando la aplicaci´on necesite consultar una de esas filas, lo que hace nuestro ORM es devolver una lista con todas las filas de la base de datos en forma de lista de objetos. Entonces la aplicaci´on se encarga de realizar la b´usqueda dentro de esa lista. Aplicaci´on base datos pigmentos 29 UVa Trabajo Fin Grado Figura 13: Diagrama de Paquetes a alto nivel Aplicaci´on base datos pigmentos 30 UVa Trabajo Fin Grado Diagramas de secuencia de alto nivel En esta secci´on vamos a ilustrar como ser´ıa la interacci´on b´asica de los componentes de alto nivel de la aplicaci´on. No buscamos una fuente detalla de los datos sino simplemente una aproximaci´on a la soluci´on que hemos planteado para que se entienda lo que hemos desarrollado en la aplicaci´on, pero sin entrar a detalles de bajo nivel que pueden ofuscar la presentaci´on. En este caso vamos a especificar un diagrama de secuencia para el supuesto de que el usuario quiere observar las propiedades qu´ımicas de un pigmento determinado. Esta secuencia de actividades la podemos ver reflejada a modo de ejemplo en el diagrama de la Figura 14 Figura 14: Diagrama de secuencia de alto nivel para ver la informaci´on de un pigmento En este diagrama a de secuencias para uno de los casos m´as b´asicos, podemos observar como el actor interact´ua con la aplicaci´on y toca en el bot´on de ver todos los pigmentos, esta acci´on desencadena que el controlador del MVC (Model View Controller) [24] se ponga en contacto con el controlador principal de la aplicaci´on. Dicho controlador interact´ua con el ORM que hemos dicho Aplicaci´on base datos pigmentos 31 UVa Trabajo Fin Grado antes. Este ORM (Object Request Manager) [25] hace la consulta necesaria MySQL en la base de datos y le devuelve al controlador de aplicaci´on una lista con todos los objetos representando las filas de la tabla que se haya consultado, en este caso la general de los pigmentos. El controlador de aplicaci´on devuelve la informaci´on al controlador de la vista y presenta la informaci´on de una manera adecuada para el usuario. Ahora el usuario selecciona un pigmento en concreto, para ello el controlador de las vistas se pone en contacto con el controlador de la aplicaci´on, el cu´al no necesita interactuar con la base de datos porque ya tienes los datos disponibles. Buscamos el pigmento en cuesti´on, devolvemos la informaci´on al controlador de aplicaci´on y este devuelve la informaci´on al controlador de las vistas. Hecho esto la el usuario tiene a su disposici´on la informaci´on que quer´ıa. Una vez que hemos presentado los principales diagramas e ideas en el formato tradicional, vamos a seguir con nuestra metodolog´ıa inicial que es Kanban. 4.2. Definici´on de criterios En Kanban, antes de definir las historias de usuario, tenemos que definir brevemente alguno de los criterios que usaremos en dichas historias y que son muy importantes. Los m´as importantes que tenemos que definir son dos, los criterios de aceptaci´on y los criterios de finalizaci´on. 4.2.1. Definici´on de hecho La definici´on de hecho es una norma que se aplica a las Historias de Usuario, que desarrollaremos m´as adelante, pero para ello es necesario tener bien fijada esta definici´on con anterioridad. Normalmente esta definici´on es fijada de manera conjunta con el cliente final y el l´ıder del equipo y muchas veces est´a presente el euqipo de desarrollo como tal para verificar las diferentes posibilidades, ya que nos permite: Tener un producto potencialmente entregable y usable al finalizar cada iteraci´on. En el caso de este proyecto no tenemos iteraciones como tal, pero si nosotros establecemos unas ciertas normas que tiene que cumplir cada una de las tareas que vamos a desarrollar, cuando nosotros finalicemos esas tareas podemos decir que est´an acabas y entregadas de manera adecuada y conforman el producto final perfectamente entrgeable. De esta forma el cliente, conforme tengamos tareas acabadas puede tomar decisiones de qu´e desarrollar en el futuro y qu´e no de manera clara y sencilla. Establecer unos criterios de calidad: define que entregables y m´ınimos de calidad se tienen que cumplir en todos los objetivos/requisitos que se van a ir aceptando conforme el proyecto vaya avanzando en el tiempo. Aplicaci´on base datos pigmentos 32 UVa Trabajo Fin Grado Ahora que sabemos lo que son y las posibilidades de la definici´on de hecho, pasamos a ver cuales ser´an nuestros criterios de hecho: 1. El trabajo de cada miembro del equipo ha sido revisado y aceptado por lo menos por una persona m´as del proyecto, que en este caso pueden ser tanto el tutor del proyecto como el profesor asociado. 2. Todo el equipo considera que para cada objetivo/requisitos se cumplen sus criterios de aceptaci´on al 100 %. 3. El requisito o tarea tiene que estar probado. 4. Si el requisito lo permite, tiene que superar todas las pruebas unitarias que le hayan sido dise˜nadas. 5. Si el requisito lo permite, tiene que superar todas las pruebas de aceptaci´on que le hayan sido dise˜nadas. 6. Si el requisito lo permite, tiene que superar todas las pruebas de regresi´on que le hayan sido dise˜nadas. 7. El requisito o tarea tiene que estar documentado. 8. El requisito o tarea supera una calidad respecto a c´odigo del 80 %. 9. El product owner ha validado y aceptado el objetivo/requisito. 4.2.2. Criterios de aceptaci´on Mientras que los criterios de finalizaci´on tienden a ser criterios mas objetivos, medibles y triviales. Los criterios de aceptaci´on dependen en gran medida del deseo e idea que el cliente tiene sobre el producto final. Los criterios de aceptaci´on definen los requisitos del Product Owner sobre c´omo debe comportarse la aplicaci´on para que una determinada acci´on se pueda llevar a cabo, normalmente por parte de un usuario de la aplicaci´on. Generalmente ayudan al equipo de desarrollo a responder a las preguntas: ¿He construido el producto correcto? ¿He construido el producto correctamente? Los criterios de aceptaci´on deben describir siempre un contexto, un evento y la respuesta o consecuencia esperada del sistema. La forma m´as utilizada para describir los criterios de aceptaci´on es conocida como Given-When-Then, que veremos m´as adelante cuando mostremos las historias de Aplicaci´on base datos pigmentos 33 UVa Trabajo Fin Grado usuario. Los criterios de aceptaci´on son la clave de las historias de usuario, por lo tanto se tienen que cumplir todos los criterios de aceptaci´on para dar una historia de usuario como terminada y correcta. El cumplimiento de los criterios de aceptaci´on de las historias de usuario, a nivel de funcionalidad se ver´a de una manera muy clara cuando se presente la suite de pruebas asociadas a la aplicaci´on. Como adelanto, dicha suite de pruebas se va a basar en un lenguaje llamado Gherkin en el que los escenarios de prueba se describen en un lenguaje de alto nivel basado en el Given-Then-When. Habr´a una asociaci´on directa entre los criterios de aceptaci´on de una historia de usuario y el test concreto que pruebe la funcionalidad de dicha historia de usuario. Todo esto lo podremos ver m´as en detalle en los cap´ıtulos posteriores, en concreto en el relacionado con las pruebas de la aplicaci´on. 4.3. ´ Epicas e historias de usuario A la hora de estructurar el trabajo que tenemos que hacer en un proyecto de gran magnitud, tenemos que tener en cuenta desde las actividades m´as ambiciosas hasta las mas detalladas. Por eso, existen diferentes estructuras de datos y formas de organizaci´on que nos ayuda a conseguir dicho objetivo. Como bien nos dice el Atlassian Agile Couch, para conseguirlo nos podemos servir de los temas, iniciativas, ´epicas, historias de usuario y tareas. Podemos ver una descomposici´on visual de estos elementos en la Figura 15 Figura 15: Relaci´on entre ´epicas, historias y temas A modo de resumen, cada una de las estructuras significa: Temas: son grandes ´areas de enfoque que abarcan a toda la organizaci´on. Iniciativas: son conjuntos de ´epicas que conducen hacia un objetivo com´un. Aplicaci´on base datos pigmentos 34 UVa Trabajo Fin Grado ´ Epicas: son grandes cantidades de trabajo que se pueden desglosar en un n´umero de tareas m´as peque˜nas, llamadas historias. Historias: son breves requisitos o solicitudes escritas desde el punto de vista del usuario final. Tareas: las tareas son actividades que hay que hacer para conseguir desarrollar las historias, no tienen porque estar escritas desde el punto de vista del cliente. En este proyecto por temas de magnitud, ya que es un proyecto peque˜no, solo vamos a contar con historias, tareas y como mucho con unas cuantas ´epicas que nos van a venir bien a nivel de planificaci´on y explicaci´on del proyecto. 4.3.1. ´ Epicas Las ´epicas que nosotros vamos a presentar en nuestro proyecto son las siguientes: Desarrollo: en esta ´epica se incluir´an las tareas relacionadas con las actividades de desarrollo. Documentaci´on: se relacionar´an tareas de documentaci´on de las diferentes partes que componen el sistema, tanto documentaci´on interna como documentaci´on externa. Configuraci´on: se a˜nadir´an las tareas relacionadas con la configuraci´on de entornos o sistemas necesarios para la consecuci´on de los objetivos del proyecto. Investigaci´on: puede que haya algunas tareas de investigaci´on en ciertos puntos del proyecto, en esta ´epica habr´a seguramente muy pocas tareas, pero tambi´en considero necesaria a˜nadirla. Cabe destacar que tanto las ´epicas del proyecto como las diferentes historias de usuario y tareas, las podemos 4.3.2. Historias de usuario Primero vamos a describir brevemente lo que son las ´epicas y las historias de usuario. Que son la base de la metodolog´ıa que estamos siguiendo. Las historias de usuario son la base trabajo de nuestro equipo de desarrollo. Para presentarlas hemos hecho una peque˜na plantilla que muestra las caracter´ısticas esenciales de una historia de usuario, y tiene los siguientes campos: Id: cada una de las historias de usuario de nuestro proyecto va a tener un ID ´unico que la Aplicaci´on base datos pigmentos 35 UVa Trabajo Fin Grado pensar en cosas de m´as bajo nivel. Tambi´en podemos observar, que estas historias de usuario tiene diferentes dependencias entre ellas, como es esperable en el desarrollo de una aplicaci´on, por ejemplo podemos completar la parte de las consultas avanzadas si no tenemos el desarrollo de la interfaz principal. La precedencia de tareas la podemos observar en la Figura 17 Figura 17: Diagrama de precedencia de las principales tareas Muchas de las tareas, como la ID:07, ID:05 o ID:02 desembocan tambi´en en la ID:11, pero no est´an relacionadas porque no es estrictamente necesario que todas ellas est´en terminadas para poder empezar la 11, la ´unica que si que tiene que estar necesariamente terminada para poder empezar con la ID:11 es la ID:08. Aplicaci´on base datos pigmentos 42 UVa Trabajo Fin Grado 4.5. Bocetos iniciales Ahora que tenemos planificadas la gran mayor´ıa de tareas principales y a m´as alto nivel, vamos a empezar con el desarrollo como tal de la aplicaci´on. En esta secci´on presentaremos el logo de la app junto con el nombre y los dise˜nos de las principales interfaces. 4.5.1. Logo de la aplicaci´on y nombre Una de las primeras cosas en las que pensamos cuando escuchamos aplicaci´on m´ovil es en el nombre y el logo de las grandes aplicaciones. En la ´epoca actual los logos tienen a ser minimalistas, simples y con colores pastel y suaves. As´ı mismo los nombres de las aplicaciones tienden a ser cortos, ya que los dispositivos m´oviles suelen tener un tama˜no reducido y no se pueden meter frases largas. Logo Los dos dise˜nos iniciales para el logo de la aplicaci´on fueron los siguientes: Figura 18: Dise˜no 1 del logo de la aplicaci´on Figura 19: Dise˜no 1 del logo de la aplicaci´on Pero despu´es de una reuni´on con el cliente final, se llego a la conclusi´on de que el logo deber´ıa de ir mas por el estilo de la paleta, pintada de diferentes colores: Aplicaci´on base datos pigmentos 43 UVa Trabajo Fin Grado Figura 20: Dise˜no final del logo de la aplicaci´on En las reuniones posteriores se ha decidido dejar como logo una paleta pero coloreada, en lugar de en tonos blancos y negros. Y quitar el Titulo dentro del logo. Nombre En la secci´on anterior ya hemos dejado ver cual iba a ser el nombre de la aplicaci´on. Una de las ideas iniciales era: PigemtsDB: pero ni al cliente ni al tutor del TFG les convenc´ıa esta opci´on, ya que al contener la acortaci´on DB, procedente de Data Base inclu´ıa unas connotaciones un poco m´as t´ecnicas. Al final se ha dejado como Pigment Studio ya que tiene un significado ligeramente m´as general y no restringe a ning´un tipo de colectivos. Es un nombre corto y que haces una buena referencia a lo que el usuario se va a encontrar cuando abra la aplicaic´on, que no es m´as que un estudio bastante avanzado y claro de los diferentes pigmentos que tenemos en el mundo. Aplicaci´on base datos pigmentos 44 UVa Trabajo Fin Grado 4.5.2. Dise˜no de las primeras interfaces Una de las partes m´as cr´ıticas cuando estamos desarrollando aplicaciones que va a utilizar el usuario final es la interfaz que van a tener que usar. Va a ser una pantalla contra la que el usuario va a interactuar bastante a menudo, por lo tanto tiene que ser c´omoda, clara y sencilla. Algunas de las normas que tienen que tener el dise˜no de interfaces para que el usuario tenga una buena experiencia (UX) las podemos encontrar en la siguiente lista: La aplicaci´on tiene que ser f´acil de utilizar incluso si el usuario no tiene conocimiento previo de c´omo se usa la misma. La aplicaci´on tiene que ir fluida y responder en tiempos peque˜nos. La aplicaci´on tiene que tener las opciones mas importantes resaltadas y en la parte derecha, cerca del pulgar. El logo de la aplicaci´on tiene que ser atractivo y relacionado con la informaci´on que va a contener. Podemos encontrar algunos consejos ´utiles y que yo he utilizado en las referencias de dise˜no de Adobe [26]. Las principales interfaces que vamos a encontrar en nuestro sistema son las siguientes, junto con una descripci´on de lo que har´an. Men´u Principal En el men´u principal de la aplicaci´on podremos encontrar las diferentes opciones que nos presenta para explotar la base de datos de la manera m´as adecuada. Entre ellos los botones que nos podemos encontrar (recordar que solo son bocetos): Pigmentos: en esta secci´on encontraremos una lista con todos los pigmentos que tenemos en la base de datos con algunas caracter´ısticas en miniatura. Consulta Simple: nos permitir´a realizar las principales consultas, que son por color y por el elemento qu´ımico principal del pigmento en cuesti´on. Consulta Avanzada: nos permitir´a realizar b´usquedas m´as avanzadas, como por las coordenadas tricr´omicas de un pigmento o por determinadas caracter´ısticas de las gr´aficas de los mismos. Gr´aficas: mostrar´a al usuario una lista de las diferentes gr´aficas que se disponen de cada pigmento. A˜nadir Pigmento: el usuario podr´a a˜nadir un nuevo pigmento a la base de datos, en el Aplicaci´on base datos pigmentos 45 UVa Trabajo Fin Grado caso de que se disponga de los datos suficientes para hacerlo. Podemos ver la vista del men´u principal en la Figura 21 Aplicaci´on base datos pigmentos 46 UVa Trabajo Fin Grado Figura 21: Men´u principal de la aplicaci´on Figura 22: Lista principal con todos los pigmentos del sistema Vista r´apida de pigmentos Si el usuario pulsa sobre el bot´on de pigmentos, entonces lo que se va a encontrar es una sencilla lista con todos los pigmentos que se encuentran disponibles en el sistema. La entrada de cada pigmento constar´a del nombre del mismo, un color aproximado, para que se le haga mas visual al usuario, junto con una breve descripci´on y en miniatura el elemento qu´ımico principal que compone dicho pigmento. Podemos observar dicho men´u en la Figura 22. En esta vista el usuario puede buscar por nombre un determinado pigmento, puede conseguir esto introduciendo el nombre del mismo en la barra superior que tenemos en el men´u. Informaci´on de los pigmentos Una vez que en la pantalla que hemos presentado anteriormente, el usuario pulsa sobre uno de los pigmentos, el sistema muestra toda la informaci´on detalla del mismo seg´un la Figura 23 Aplicaci´on base datos pigmentos 47 UVa Trabajo Fin Grado Figura 23: Informaci´on de los pigmentos Figura 24: Informaci´on gr´aficas de pigmentos Consulta Simple - Opci´on 1 Volviendo al men´u principal, si el usuario pulsa sobre el bot´on de consulta simple entonces se le muestran las diferentes opciones, que en este caso solo son 3, una es la b´usqueda por color, otra la b´usqueda por un elemento qu´ımico y la tercera es la opci´on que tendr´ıamos en el men´u principal de verlos todos. Adem´as una vez que el usuario pulsa sobre una de las dos opciones, el sistema le muestra los diferentes formularios para ejecutar la b´usqueda. En esta secci´on tenemos que presentar dos bocetos diferentes, que son los que se hab´ıan pensado en el principio, y luego se dar´an m´as detalles para decir con cual nos hemos decantado. Podemos ver los primeros bocetos en las Figuras siguientes: Aplicaci´on base datos pigmentos 48 UVa Trabajo Fin Grado Figura 25: Men´u para hacer una consulta simple Figura 26: Men´u de selecci´on de colores Figura 27: Men´u de selecci´on de elementos En la Figura 25 podemos ver el men´u principal que hemos descrito anteriormente, donde el usuario elije el tipo de b´usqueda que quiere realizar. Mientras que en la Figura 26 podemos ver la selecci´on de colores y en la Figura 27 podemos ver como ser´ıa la pantalla de selecci´on de elementos. La ventaja que tienen estas interfaces es que puedes un solo dise˜no de la vista de la aplicaci´on para dos funcionalidades diferentes. Adem´as es m´as din´amica ya que evita tener que pulsar tantos botones como las opciones que mostraremos a continuaci´on. El usuario simplemente desliza en busca de los colores o elementos que quiere, va pulsando sobre ellos, dichos elementos se van a˜nadiendo a la lista vertical de la derecha, y la lista de resultados se va actualizando autom´aticamente en funci´on de los filtros introducidos. Consulta Simple - Opci´on 2 Sin embargo en las Figuras 28 yFiguras 29 podemos ver como era otra de las ideas iniciales para estas consultas. Aplicaci´on base datos pigmentos 49 UVa Trabajo Fin Grado Figura 28: Men´u de selecci´on de colores Figura 29: Men´u de selecci´on de elementos Las desventajas que podemos encontrar al dise˜nar esta interfaz son varias. Primero es menos din´amica que la opci´on anterior ya que el usuario tiene que hacer m´as pulsaciones en la pantalla para obtener el mismo resultado, adem´as de que tiene m´as pantallas intermedias, ya que se tienen que mostrar los resultados en una vista diferente. Otra de las desventajas desde el punto de vista de desarrollo es que requieren funcionalidades diferentes, en una tendr´ıamos que a˜nadir un selector de color e introducir cosas m´as espec´ıficas de este elemento mientras que la otra opci´on tendr´ıamos que ingeniarnos un selector de elementos qu´ımicos, lo cual puede ser complicado. La opci´on anterior unifica estas opciones, ya que saca los colores y los elementos de una base de datos y solo tiene que cargar la informaci´on para que el usuario la elija como filtro de la b´usqueda. Recordamos que las figuras anteriormente presentadas son solo bocetos de la aplicaci´on. La idea es que la aplicaci´on final quede de manera aproximada a como se ha mostrado, pero por problemas de desarrollo, tiempo u otras causas es posible que los resultados finales se vean afectados o no sean completamente fieles a los presentados en las figuras anteriores. Aplicaci´on base datos pigmentos 50 UVa Trabajo Fin Grado Reportar Bug Esta pantalla no tiene mucha importancia a nivel de funcionalidad, pero si que la considero bastante importante a nivel de peticiones de cambio futuras y cuyo objetivo es mejorar la aplicaci´on el tiempo. Los reportes de fallos o bugs de la aplicaci´on, que sea reportados por los usuarios ser´an almacenados en un servidor central que gestionar´a una base de datos de fallos y bugs. Esta informaci´on se mandar´a de manera completamente an´onima por la red, y no se almacenar´a ning´un posible dato del usuario. La pantalla que tengo pensada para implementar esta funcionalidad la podemos observar en la Figura 30 Figura 30: Men´u de reporte de fallos 4.6. Sistema de Integraci´on continua El sistema de integraci´on continua ha sido ligeramente descrito en los cap´ıtulos anteriores (Secci´on 2.2.4) cuando habl´abamos de la tecnolog´ıa que ´ıbamos a utilizar, que en este caso es Aplicaci´on base datos pigmentos 51 UVa Trabajo Fin Grado la creaci´on y en el futuro la conexi´on entre la propia aplicaci´on y los datos almacenados en la base de datos. Para implementar la base de datos he optado por hacerlo de una manera m´as sencilla que la aprendida en la asignatura de SMOV. La base en realidad es la misma, pero la forma es la misma, bien es sabido que dentro de la inform´atica podemos obtener los mismos resultados pero con algoritmos diferentes. En este caso vamos a realizar una mezcla entre uno de los patrones de acceso comentados al principio, DAO y los POJO. Como hemos dicho en los cap´ıtulos anteriores, cada uno de los elementos de la base de datos, que en este caso son pigmentos, va a estar representado por un objeto t´ıpico de Java. Esta forma de representar los objetos para el almacenamiento de datos se denomina POJO (Plain Old Java Objects). Adem´as cada vez que recuperemos los elementos de la base de datos lo hacemos devolviendo una lista de objetos del tipo adecuado. Por ejemplo para devolver todos y cada uno de los pigmentos que hay en la base de datos lo que hacemos es mandar la consulta al SGBD de SQLite y lo que nos devuelve es una lista de POJOs del tipo deseado. De esta manera podemos acceder de una manera sencilla a todos los atributos de los datos que acabamos de recuperar. 5.4.1. ¿Que son los POJO? Dicho t´ermino [19] fue acu˜nado por Martin Fowler, Rebecca Parsons y Josh MacKenzie en Septiembre del 2000. Se usa para referirse a un objeto Java que no tiene limitaciones de por requerir librer´ıas ni clases externas. Son objetos simples y b´asicos de java, con atributos, funciones para recuperar los valores y para cambiarlos en caso necesario y nada m´as. Este tipo de objetos son muy utilizados cuando tenemos que convertir objetos entre diferentes lenguajes o cuando tenemos que serializarlos para enviarlos por la red. Idealmente y seg´un dice la definici´on de los mismos, un objeto Java es POJO si cumple estos 3 requisitos: No extiende de ninguna clase. 1 public c l a s s Foo extends javax . s e r v l e t . http . HttpServlet {. . . No implementa ninguna clase. 1 public c l a s s Bar implements javax . ejb . EntityBean {. . . No contiene anotaciones. Aplicaci´on base datos pigmentos 58 UVa Trabajo Fin Grado 1 @javax . p e r s i s t e n c e . Entity pu bl ic c l a s s Baz {. . . Los POJO fueron inicialmente utilizados en J2EE para representar los JavaBeans, que son objetos java muy simples y que ofrecen servicios por la red. Se siguen utilizando aunque han cambiado un poco las formas de hacerlo. Ahora los POJO tambi´en son ampliamente utilizados para representar objetos JSON recibidos por parte de microservicios web y ser utilizados en un servidor. Este es uno de los muchos ejemplos de utilizaci´on real a d´ıa de hoy de los POJO. 5.4.2. Ejemplo Vamos a explicar con un sencillo ejemplo lo que son los POJO y como se hace la consulta de los mismos para luego mostrar la informaci´on dentro de la aplicaci´on. En este caso uno de los atributos que nos interesa son las diferentes notas que tiene cada uno de los pigmentos, para ello habr´a una tabla con todas las notas de todos los pigmentos. Como hemos ense˜nado en el modelado conceptual, de cada una de las diferentes notas almacenamos y guardamos los siguientes datos: IdPigmento: para poder relacionar la nota con el pigmento, este dato es interno para la gesti´on de los datos. T´ıtulo: breve descripci´on. Descripci´on: contenido completo de la nota. Fecha: fecha de creaci´on de la misma. La descripci´on anterior la podemos encontrar representada por un POJO en el siguiente fragmento de c˜nodigo Java: Aplicaci´on base datos pigmentos 59 UVa Trabajo Fin Grado 1 package com . dbpigmentationapp . dataModel ; 2 3 public c l a s s Nota { 4 5 private String idPigmento ; 6 private String t i t u l o ; 7 private String d escrip c i on ; 8 9// Constructor por defecto 10 public Nota () { 11 t h i s . idPigmento = ” Id Pigmento” ; 12 t his . t i t u l o = ” T t u l o ” ; 13 t h i s . descri p cion = ”Breve d e s c r i p c i n ” ; 14 } 15 16 // Constructor con parametros 17 public Nota ( String idPigmento , String t itu l o , String descripc i o n ) { 18 t h i s . idPigmento = idPigmento ; 19 t his . t i t u l o = t i t u l o ; 20 t h i s . d es c ri p ci o n = d esc r ip c io n ; 21 } 22 23 // FUNCIONES DE ACCESO A DATOS 24 public String getTitulo () { 25 return t i t u l o ; 26 } 27 28 public void s etTit ulo ( String t i t u l o ) { 29 t his . t i t u l o = t i t u l o ; 30 } 31 32 public String getDescripcion () { 33 return descripcion ; 34 } 35 36 public void setDescripcion ( String d escripc i o n ) { 37 t h i s . d es c ri p ci o n = d esc r ip c io n ; 38 } 39 40 public String getIdPigmento () { 41 return idPigmento ; 42 } 43 44 public void setIdPigmento ( String idPigmento ) { 45 t h i s . idPigmento = idPigmento ; 46 } 47 } Aplicaci´on base datos pigmentos 60 UVa Trabajo Fin Grado Una vez que hemos dise˜nado todos los POJOS que va a contener nuestra aplicaci´on, que simplemente es uno por cada entidad del diagrama de entidad relaci´on, adem´as con los mismos atributos que se muestr´an en el esquema. Ahora podemos implementar todas las operaciones de acceso a esos datos. Las operaciones para cada uno de las diferentes entidades que tenemos en nuestro sistema son: Pigmento: •A˜nadir pigmento. •Obtener todos los pigmentos para mostrarlos en la lista principal. •Obtener los pigmentos que coincidan con un nombre. •Obtener los pigmentos que coincidan con un color. •Obtener los pigmentos que coincidan con un elemento qu´ımico. Notas: •A˜nadir notas. •Obtener todas las notas de un pigmento dado su nombre (en la consulta se usar´a el id del pigmento). Sin´onimos: •A˜nadir notas. •Obtener todos los sin´onimos de un pigmento dado su nombre (en la consulta se usar´a el id del pigmento). Infrarrojos: •A˜nadir infrarrojos. •Obtener todos los datos de los infrarrojos dado un pigmento, para luego poder representarlos en una gr´afica de manera adecuada. •Obtener todos los elementos dadas una coordenadas de infrarrojos determinadas y mostrar los elementos que corresponden a esos valores. Rayos X: •A˜nadir rayos X. •Obtener todos los datos de los rayos X dado un pigmento, para luego poder represen- Aplicaci´on base datos pigmentos 61 UVa Trabajo Fin Grado tarlos en una gr´afica de manera adecuada. •Obtener todos los elementos dadas una coordenadas de infrarrojos determinadas y mostrar los elementos que corresponden a esos valores. Raman: •A˜nadir coordenadas de Raman. •Obtener todos los datos del espectro de Raman dado un pigmento, para luego poder representarlos en una gr´afica de manera adecuada. •Obtener todos los elementos dadas una coordenadas de del espectro de Raman determinadas y mostrar los elementos que corresponden a esos valores. Colorimetria: •A˜nadir coordenadas de colores. •Obtener todos los datos colorim´etricos dado un pigmento, para luego poder representarlos en una gr´afica de manera adecuada. •Obtener todos los elementos dadas una coordenadas de de colores determinadas y mostrar los elementos que corresponden a esos valores. 5.5. Otras consideraciones Algunas otras decisiones de dise˜no que hemos tenido que tener en cuenta, y que afectan tanto al rendimiento de la aplicaci´on como al dise˜no de la base de datos, son las siguientes: 5.5.1. Dise˜no antiguo VS dise˜no actual En el dise˜no antiguo de la base de datos (Figura 33), de manera resumida se tiene una tabla con una entrada para cada pigmento y esta entrada tiene un atributo que referencia a un fichero de datos. Por ejemplo si queremos obtener el difractograma de rayos X del pigmento n´umero 3, nos va a referenciar a un fichero de texto que contiene aproximadamente unas 4000 l´ıneas con 2 valores en cada l´ınea. Es decir que en total vamos a tener unos 50 ficheros cada uno de 4000 l´ıneas. Seg´un el gestor de almacenamiento de Windows estos ficheros tienen un tama˜no medio de unos 30 Kb. En total tenemos unos 150 ficheros lo que hace que el total de los ficheros si los tuvi´eramos que almacenar dentro de la base de datos para su posterior procesado, adem´as de tener aparte la instancia de la base de datos creada supondr´ıa un aumento de unos 5Mb en la aplicaci´on. Aplicaci´on base datos pigmentos 62 UVa Trabajo Fin Grado Figura 33: Dise˜no propuesto en Access de la Base de Datos En el dise˜no que yo he propuesto (Figura 34) lo que tenemos son 3 tablas, cada una de 200.000 entradas (50 x 4000 en el peor de los casos) donde tenemos disponibles todos y cada uno de los datos. Adem´as una de las ventajas de esta forma es que la aplicaci´on no tiene que hacer tantas operaciones de entrada salida para procesar todos los datos al realizar las consultas. Con el dise˜no propuesto solo se procesan una ´unica vez para poder cargar y generar la base de datos. Figura 34: Dise˜no propio de la base de datos 5.5.2. C´odigo frente a eficacia Otro de los problemas es la eficacia y el dise˜no frente a la limpieza y entendibilidad del c´odigo. Podemos implementar la soluci´on de dos maneras diferentes. Aplicaci´on base datos pigmentos 63 UVa Trabajo Fin Grado La primera es creando una ´unica base de datos con todas las tablas y todas las operaciones necesarias. El problema es que esa base de datos y las operaciones se tienen que crear en una ´unica clase que se encarga de ello, esta clase va a ser relativamente grande y uno de los principios de dise˜no que por ejemplo podemos encontrar en el Libro Clean Code [20] es que las clases tienen que ser peque˜nas, autocontenidas y hacer una ´unica cosa. Sin embargo nuestra clase va a crear una base de datos, inicializar 4 tablas y ofrecer todos los m´etodos de acceso y modificaci´on de todas las tablas. De esta forma el c´odigo se ve afectado pero sin embargo el dise˜no de la base de datos y la eficacia de las consultas no se ve afectada. La otra manera es crear una clase para cada una de las tablas, pero de esta manera tendr´ıamos una base de datos por tabla, lo que no concuerda con el dise˜no propuesto de la base de datos y adem´as tendr´ıamos que procesar las consultas via software usando la JVM lo cual puede traducirse en un decremento de la eficiencia de la aplicaci´on. La soluci´on por la que se ha optado es la primera. 5.5.3. Scripts necesarios Por como he decidido hacer el dise˜no de la base de datos, ha sido necesario adaptar de una cierta manera los datos para luego ser procesados de manera autom´atica por la aplicaci´on e introducirlos en la base de datos. Ha sido necesaria la creaci´on de una serie de scripts, para evitar un trabajo manual considerable. Los programas necesarios son los siguientes: Generador de notas: en nuestra base de datos estamos almacenando una breve descripci´on de los pigmentos. Esta descripci´on en la base de datos original esta como una tabla separada con 2 columnas. La primera columna referencia al pigmento mientras que la segunda referencia al archivo donde se puede encontrar la descripci´on. A mi me parece ineficiente la idea de tener los datos separados, por eso en mi base de datos la descripci´on esta dentro de la propia base de datos. Pero para poder generarla hay que tener los ficheros en un formato correspondiente, que en este caso es CSV. Por lo que para ello he tenido que generar el siguiente script, que recorre todos los ficheros y pone las descripciones de los pigmentos en una ´unica l´ınea, que luego la base de datos tomar´a como string y almacenar´a. Aplicaci´on base datos pigmentos 64 UVa Trabajo Fin Grado 1 import os 2 3 f i l e s = {} 4 5for filename in os . l i s t d i r ( ” ./ generador ” ) : 6 f i l e = open ( ” . / generador /” + filename , ” r ” ) 7 f i l e s [ filename ] = f i l e . read () 8 9for filename , text in f i l e s . items ( ) : 10 print ( ’ ; ’ + text . r eplace ( ’ \r ’ , ”” ) . re place ( ’ \n ’ , ”” )) Generador de datos: en nuestra base de datos, como hemos comentado anteriormente, tenemos una tabla para almacenar los datos de IR, otra para los de RX y otra para Raman. Estos datos se han obtenido ejecutando scripts en python donde podemos juntar en un ´unico fichero en formato CSV todos los datos. Por ejemplo para obtener los datos de la tabla de DRX y luego e introducirlos de una manera sencilla en nuestra base de datos, hemos generado un ´unico fichero que tiene la siguiente estructura: idPigmento;valorX;valorY. Esta estructura se ha seguido con todos los ficheros y se ha conseguid gracias al siguiente script. 1 import os 2 import glob 3 4 ids = [ ] 5 i d F i l e s = open ( ” . / id . txt ” , ” r ” ) 6for y in i d F i l e s : 7 ids . append (y . repla ce (”\n” , ”” ) . r ep la ce ( ”\r ” , ” . ” ) ) 8 9 path = ’ ./ generador /∗. txt ’ 10 f i l e s = glob . glob ( path ) 11 i = 0 12 for f i l e in f i l e s : 13 f = open ( f i l e , ’ r ’ ) 14 for x in f : 15 i f ( ”#” not in x ) : 16 print ( id s [ i ] + ” ; ” + x . r eplace (”\r ” , ”” ) . r ep l ac e ( ”\n” , ”” ) 17 . r ep la c e ( ”\t ” , ” ; ” )) 18 i=i+1 5.6. Tratamiento de las BBDD en Android Como es evidente la mayor´ıa de las aplicaciones tiene que almacenar datos entre sus ejecuciones, o para compartirlas entre el resto de aplicaciones. Android nos ofrece una serie de formas de almacenar los datos [21], que son las siguientes: Aplicaci´on base datos pigmentos 65 UVa Trabajo Fin Grado Preferencias compartidas: almacenamiento de datos primitivos en pares de datos clave valor. Almacenamiento interno: almacenamiento de datos privados en la memoria del dispositivo. Almacenamiento externo: almacenamiento de datos p´ublicos en el almacenamiento externo compartido. Bases de datos SQLite: almacenamiento de datos estructurados en una base de datos privada. Conexi´on de red: almacenamiento de datos en la Web mediante tu propio servidor de red. En nuestro caso vamos a realizar una mezcla de tipos de almacenamiento. Por una parte nuestra aplicaci´on contendr´a los ficheros de datos necesarios para generar la base de datos, pero a su vez la aplicaci´on interactuara con esos datos mediante una base de datos SQLite 3 que se generar´a la primera vez que se inicie la aplicaci´on en el dispositivo m´ovil. Nuestra aplicaci´on va a disponer de la informaci´on necesaria y suficiente como para crear la base de datos completa y almacenarla de manera inaccesible para el usuario en el almacenamiento interno privado del dispositivo. La primera ejecuci´on de la aplicaci´on puede ser un poco m´as lenta de lo normal, precisamente porque se est´a creando la base de datos. Una de las mejoras futuras podr´ıa ser que la primera ejecuci´on mostrase un mensaje de configuraci´on del tipo: ”Se est´a configurando la base de datos”. De momento no se va a implementar. En las posteriores ejecuciones la aplicaci´on va a volver a tratar de introducir todos esos datos en la base de datos, pero es el sistema operativo el que ve que ya existen y no los introduce, cancelando as´ı la operaci´on y no gastando tiempo de ejecuci´on. Otra de las comprobaciones que se podr´ıan hacer en un futuro es comprobar si la base de dato ya existe, de esa manera se ahorrar´ıa a´un m´as tiempo. Ya que las bases de datos de las aplicaciones se almacenan en una ruta determinada: $/data/data/com.dbpigmentationapp/databases/pigments.db La parte de ¸com.dbpigmentationapp”tiene que ser reemplazada con el nombre del paquete con el que hemos generado nuestra aplicaci´on, que es el mismo que nos muestra AndroidStudio mientras la estamos desarrollando. Aplicaci´on base datos pigmentos 66 UVa Trabajo Fin Grado 6. Gu´ıa de Instalaci´on y Manual de Usuario 6.1. Gu´ıa de Instalaci´on Vamos a presentar una peque˜na gu´ıa de instalaci´on. Lo que se ha entregado de la aplicaci´on han sido dos cosas (a nivel de instalaci´on). Tenemos dos formas de instalar la aplicaci´on en un dispositivo Android: Fichero APK: uno de los fichero mas importantes generados de manera autom´atica por el programa Android Studio es el debug.apk. Que lo podemos encontrar como fichero de salida dentro de nuestro proyecto. Simplemente tenemos que arrastrar dicho fichero al m´ovil o pasarlo de alguna manera, intentar abrirlo y otorgando los permisos necesarios, podemos instalar la aplicaci´on considerada DEBUG. Es decir, esta aplicaci´on no se puede usar para fines comerciales, ya que no esta registrada en la tienda oficial de Google. Proyecto Android Studio: otra de las formas posibles de instalar la aplicaci´on en un dispositivo real es importar el proyecto en Android Studio. Simplemente tenemos que hacer clic en: Archivo ¿Abrir y elegir la carpeta donde se encuentra el proyecto que he adjuntado al entregar este documento. Una vez hecho esto, la compilaci´on y construcci´on del proyecto no deber´ıa de dar ning´un fallo. En la barra de herramientas superior podemos ver un s´ımbolo de Play. Antes de pulsarlo tenemos que tener el dispositivo objetivo conectado al ordenador con los permisos de desarrollador activados. Una vez dado al play y seleccionado el dispositivo objetivo, la aplicaci´on se abrir´a de manera autom´atica en el m´ovil conectado. 6.2. Manual de Usuario Para abrir la aplicaci´on simplemente tenemos que pulsar en el icono correspondiente dentro del men´u de aplicaciones del m´ovil en el que la tengamos instalada. Una vez abierto el men´u podemos realizar cuatro acciones importantes: 1. Ver todos los pigmentos: situado en el men´u principal de la aplicaci´on. Como usuario, tienes que pulsar en el bot´on de color azul que pone Pigmentos. Una vez pulsado el sistema mostrar´a una lista descendente con la informaci´on b´asica y principal de todos los pigmentos de los que se dispone informaci´on. El usuario puede pulsar en cualquiera de los elementos de la lista, acto seguido se mostrara una pantalla con la informaci´on principal relacionada con ese pigmento. El usuario puede interactuar con esta pantalla. Si desliza hacia abajo ver´a una serie de desplegables, si se pulsa en ellos se puede ver la informaci´on de las gr´aficas m´as importantes que se presentan como informaci´on de cada uno de los pigmentos. 2. Buscar un pigmento por color: situado en el men´u principal de la aplicaci´on. Como usuario tienes que pulsar en el bot´on de color naranja que pone filtrar por color. Entonces se mostrar´a una ventana con un c´ırculo crom´atico donde el usuario puede elegir el color Aplicaci´on base datos pigmentos 67