Sincronización de información para un asistente virtual offline

ESCUELA DE INGENIER´ IA INFORM ´ ATICA DE VALLADOLID SINCRONIZACI ´ ON DE INFORMACI ´ ON PARA UN ASISTENTE VIRTUAL OFFLINE Trabajo de Fin de Grado Grado en Ingenier´ ıa Inform´ atica Menci´ on Tecnolog´ ıas de la Informaci´ on Alumno: Santiago Rabad´ an Fern´ andez Tutores: Jes´ us Mar´ ıa Vegas Hern´ andez C´ esar Llamas Bello 2021 2 ´ Indice general Resumen 6 Abstract 8 1. Introducci´ on 11 1.1. Estructuradelamemoria.................................. 12 2. Estado del Arte 15 2.1. ¿Qu´ eeselinternetdelascosas? .............................. 15 2.2. Losaltavocesinteligentes.................................. 15 2.3. Motivaci´ on: El problema de la necesidad de conexi´ on a Internet . . . . . . . . . . . . . 18 2.4. Caching........................................... 19 2.5. Webcaching......................................... 19 2.6. Web scrapping y los datos abiertos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.7. Soluci´ onPlanteada ..................................... 20 3. Plan de Desarrollo 23 3.1. Introducci´ on......................................... 23 3.2. Calendario de realizaci´ on del Trabajo de Fin de Grado . . . . . . . . . . . . . . . . . . 23 3.3. Plan de desarrollo del software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 3.4. Riesgos ........................................... 24 3.5. Plandetrabajo ....................................... 26 3.5.1. Estudio y puesta en funcionamiento de los sistemas previos . . . . . . . . . . . 26 3.5.2. Migraci´ onaMycroft................................ 27 3 4´ INDICE GENERAL 3.5.3. Documentaci´ on................................... 27 3.5.4. Creaci´ ondeunwebscrapper............................ 28 3.5.5. Creaci´ on de una estructura cliente-servidor HTTP b´ asica............. 28 3.5.6. Creaci´ on de una skill paraMycroft......................... 29 3.5.7. Redacci´ ondelProyecto............................... 29 4. An´ alisis del Proyecto 31 4.1. Introducci´ on......................................... 31 4.2. Antecedentes ........................................ 31 4.2.1. Proyecto1 ..................................... 31 4.2.2. Proyecto2 ..................................... 32 4.3. Identificaci´ onderequisitos................................. 32 4.3.1. Requisitos funcionales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 4.3.2. Requisitos de informaci´ on ............................. 33 4.3.3. Requisitos No Funcionales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 4.4. Casosdeuso ........................................ 34 4.5. Costes............................................ 35 5. Dise˜ no e implementaci´ on 37 5.1. Recursosyherramientas .................................. 37 5.1.1. Mycroft....................................... 37 5.1.2. Picroft........................................ 38 5.1.3. AstahProfessional ................................. 38 5.1.4. draw.io ....................................... 38 5.1.5. Microsoft Visual Studio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 5.1.6. Overleaf....................................... 38 5.1.7. Python ....................................... 38 5.2. Diagrama de tipos de procesos del sistema . . . . . . . . . . . . . . . . . . . . . . . . . 39 5.2.1. Diagramadelcliente ................................ 39 5.2.2. Diagramadelservidor ............................... 42 ´ INDICE GENERAL 5 5.3. L´ ogica conversacional y di´ alogos.............................. 44 6. Pruebas 49 6.1. Pruebas del sistema de creaci´ on y paso de cach´ es ..................... 49 6.2. Pruebas de la skill que lee la cach´ edescargada....................... 50 7. Despliegue 53 7.1. Preparaci´ ondePicroft.................................... 53 7.2. Instalaci´ ondelservidor................................... 55 7.3. Instalaci´ on de la skill .................................... 56 7.4. Instalaci´ ondelcliente.................................... 56 8. Conclusiones y trabajo futuro 57 Bibliograf´ ıa 59 6´ INDICE GENERAL Resumen Los asistentes basados en voz son herramientas muy ´ utiles para ayudar a personas con necesidades especiales de movilidad o que tengan una situaci´ on de dependencia, por ejemplo, algunas personas ancianas que viven solas. Este tipo de dispositivos les podr´ ıa permitir acceder a informaci´ on ´ util que de otra forma ser´ ıa dif´ ıcil de obtener para ellas. La presente memoria describe el Trabajo de Fin de Grado que trata el problema de la creaci´ on y puesta en funcionamiento de un sistema de sincronizaci´ on de informaci´ on para estos asistentes virtuales offline. Consiste principalmente en el dise˜ no de un software que sea capaz de generar cach´ es atomizadas dependiendo del n´ ucleo de poblaci´ on en el que se encuentre situado el asistente virtual, el paso de las cach´ es del servidor a los clientes, y en el dise˜ no de una skill que sea capaz de narrar esa informaci´ on. Esto permitir´ a que las personas con alguna de estas condiciones que vivan en entornos rurales donde la conexi´ on a internet no sea fluida, puedan seguir utilizando el dispositivo, y este les pueda dar el m´ ınimo servicio exigible. Este proyecto deber´ ıa facilitar a las personas que trabajen en el en el futuro, toda la parte relacionada con la interacci´ on entre el altavoz y el usuario, y deber´ a ser integrada en el sistema final, cuando se junten todas las partes, como servicio esencial teniendo en cuenta la naturaleza de uso del dispositivo. 7 8´ INDICE GENERAL Abstract Voice assistants are nowadays very useful tools to help people with special needs, in movility for example, o who lives in a dependency situation, for example, old persons who live alone. This type of devices could help them to have access to some information that in other way they can´t obtain. This document describes the Final Degree Work that treat to solve the problem of make function a system of information synchronization between the server an those intelligent assistants. It consists mainly in the design of a software that creates atomized caches for a concrete location, the passage of this file between server al clients, and also a skill that permits the speaker to read the downloaded information. This will able to people who lives in tiny villages or rural zones, where internet connection probably is not too fluid, to use the system, and it could give them the minimum exigible service. This project will make easier to the future developers of the project the task of create the interaction between the user and the speaker, and this funcion should be integrated in the final prototype of the project. 9 16 CAP´ ITULO 2. ESTADO DEL ARTE Si bien, es cierto, que este tipo de tecnolog´ ıa parece no estar dise˜ nada para la poblaci´ on m´ as adulta, y que para la gente m´ as joven, tiene una barrera de entrada muy peque˜ na, este proyecto tiene como finalidad el hacer que personas de ese rango de edad para las que no suelen estar dirigidos estos aparatos, lo usen en su d´ ıa a d´ ıa y les puedan servir de gran ayuda, e incluso de compa˜ n´ ıa. Y sobretodo, darnos cuenta de que complementos de este tipo pueden ser muy ´ utiles para paliar en parte problemas generados por vivir en zonas despobladas, tener situaciones de dependencia o vivir en soledad, ya que puede ponerse al alcance de su voz mecanismos para pedir ayuda inmediata, dar avisos importantes, o incluso mantener conversaciones. Este tipo de aparatos tienen un problema a˜ nadido que habr´ a que tener en cuenta en el desarrollo del proyecto, y es la privacidad. Estamos poniendo en nuestras casas unos dispositivos que se encuentras en un estado de escucha constante a la espera de que les despiertes con una palabra de activaci´ on que le haga hacer algo. Pero durante todo ese tiempo el altavoz sigue escuchando. El funcionamiento interno de estos altavoces intenta imitar como ser´ ıa una conversaci´ on humana. En una conversaci´ on humana cualquiera de los interlocutores podr´ ıa iniciar la conversaci´ on, en este tipo Figura 2.1: Diagrama de secuencia de una conversaci´ on humana de dispositivos no es lo habitual. Sin embargo una funci´ on interesante para el sistema a dise˜ nar, ya que est´ a pensado para personas que vivan solas y que puedan tener alg´ un problema, ser´ ıa que los altavoces narrasen en ciertos momentos del d´ ıa algunas alertas y ya de paso preguntasen a la persona si necesita algo. 2.2. LOS ALTAVOCES INTELIGENTES 17 M´ as adelante cuando expliquemos los antecedentes de este trabajo, hablaremos de uno cuyo objetivo era la creaci´ on de una funcionalidad de este tipo. Un diagrama de secuencia que adapte esta l´ ogica al problema conversacional entre una persona y un altavoz ser´ ıa as´ ı. El usuario dir´ ıa la palabra de activaci´ on que despierte al altavoz. Este habitualmente responde con alguna se˜ nal sonora que indica que puedes comenzar a hablar y hacerle una petici´ on. Esa petici´ on ser´ ıa enviada en crudo por el altavoz y ya en el servidor ser´ ıa procesada. Se saldr´ ıa a internet para buscar la respuesta m´ as apropiada y lo que devolviese el servidor ser´ ıa de nuevo la respuesta convertida a texto para que la narre el altavoz de vuelta al usuario. M´ as adelante veremos que esta secuencia difiere en Mycroft y explicaremos las modificaciones que se hacen al respecto. Figura 2.2: Diagrama de secuencia usuario-altavoz 18 CAP´ ITULO 2. ESTADO DEL ARTE 2.3. Motivaci´ on: El problema de la necesidad de conexi´ on a Internet Como hemos comentado anteriormente la mayor´ ıa de estos dispositivos necesitan una conexi´ on a internet fluida y constante. La naturaleza de un dispositivo de estas caracter´ ısticas, pensado para atender a personas dependientes, y residentes en zonas con muy bajas densidades de poblaci´ on, confronta totalmente con el poder tener acceso a una conexi´ on a internet fluida. Seg´ un un estudio realizado en el a˜ no 2019 por el Ministerio de Asuntos Econ´ omicos y Transformaci´ on Digital [6], un 28,87 % del territorio Espa˜ nol a´ un no dispone de una conexi´ on a internet de velocidad superior a los 10 Mbps, concentr´ andose las zonas sin esta conexi´ on principalmente en Castilla y Le´ on, Arag´ on, y el norte de Castilla la Mancha. La falta de conexi´ on a internet en estas zonas se localiza principalmente en aquellos lugares donde se concentra poca poblaci´ on. Se puede extraer de este mismo estudio, que, de media, el acceso a conexiones de internet de velocidad superior a 10 Mbps llega al 72,43 % de los hogares en poblaciones con m´ as de 2000 habitantes, pero que sin embargo, en poblaciones de menor tama˜ no, este porcentaje disminuye hasta el 39,83 %. Las zonas con baja cobertura de internet coinciden con las m´ as despobladas de nuestro pa´ ıs. En los ´ ultimos a˜ nos se est´ an haciendo esfuerzos por dar a conocer las dificultades a˜ nadidas que suponen vivir en alguno de estos lugares que se encuentran en lo que hoy com´ unmente se conoce como ”la Espa˜ na Vaciada”. Una de las principales consignas de los colectivos que defienden la necesidad de mejorar la calidad de vida en estos lugares es, adem´ as de aumentar los servicios prestados en estas zonas, la mejora de la cobertura de internet. En un mundo globalizado y conectado como el que vivimos desde hace casi ya dos d´ ecadas, internet se ha convertido en un bien de primera necesidad, y la falta de acceso a la red agrava un problema que ya venia d´ andose desde hace a˜ nos con la migraci´ on de los habitantes de los pueblos a las ciudades por la falta de oportunidades en el medio rural. Sin internet ”no se puede vivir”. Seg´ un un estudio realizado por la OCU en Julio de 2020 [2], un 28 % de la poblaci´ on encuestada (personas de 25 a 74 a˜ nos) se ha planteado cambiar su lugar de residencia, y al preguntar a esas mismas personas por su preferencia sobre donde les gustar´ ıa vivir, de las que viven en un entorno urbano o semiurbano, es decir, una ciudad, o en los alrededores de una ciudad, un 30 % querr´ ıan irse a vivir a un entorno rural, es decir, al campo o la monta˜ na, o bien a un pueblo (semirrural). Adem´ as, del total de encuestados que viven en un entorno rural o semirrural, que es el 24 %, un 80,5 % prefiere seguir viviendo en el mismo h´ abitat o uno similar. Una de las principales requerencias de las personas que viven en ciudades y que se plantear´ ıan volverse al campo pasa por poder teletrabajar, para lo cual hace falta una conexi´ on a internet que sigue sin ser suficiente en muchos lugares para poder trabajar a distancia. Y ya no solo teletrabajar. Cada vez m´ as emprendedores encuentran en el campo una oportunidad para poder montar nuevos negocios. Por esto se est´ an haciendo muchos avances en nuevas maneras de llevar internet a los pueblos. Algunas de las empresas m´ as grandes del sector tecnol´ ogico como Google o SpaceX est´ an avanzando en este tipo de tecnolog´ ıas, que permitir´ ıan, sin la necesidad de tener que desplegar miles de kil´ ometros de cable desde los grandes n´ ucleos de poblaci´ on m´ as cercanos, dotar a estas zonas de una conexi´ on a internet de alta velocidad. Los m´ as importantes son los siguientes: 2.4. CACHING 19 Google esta poniendo en pruebas un proyecto llamado LOON. Consiste en el despliegue de globos aerost´ aticos similares a los que se usan en meteorolog´ ıa, que van equipados con paneles solares que alimentan unas antenas de radio, que permiten recibir la se˜ nal de internet desde unos emisores que el proveedor tenga en superficie, para posteriormente redistribuirla desde el aire el internet, tanto a los usuarios finales como a otros globos cercanos, y as´ ı extender la red, sin necesidad de una infraestructura f´ ısica al uso [14]. SpaceX por su parte esta probando un sistema m´ as costoso, pero con m´ as perspectiva a largo plazo, Starlink, un sistema compuesto en la actualidad por m´ as de 1000 sat´ elites, pero que cuando la constelaci´ on completa est´ e en orbita rondar´ an los 30000. A diferencia del sistema de Google funciona mediante antenas sat´ elite, por lo que los futuros usuarios necesitar´ an de un receptor en el lugar donde quieran darle uso. Actualmente se encuentra en fase de pruebas en Estados Unidos, Canad´ a y Reino Unido. Samsung tiene un proyecto similar en desarrollo [3]. Debido a toda esta casu´ ıstica, que no tiene vistas a ser solucionada en el corto plazo, el sistema que estamos dise˜ nado trata de incorporar ciertas funcionalidad que lo hagan m´ ınimamente dependiente de internet. 2.4. Caching A modo introductorio podr´ ıa decirse que las cach´ es son espacios reservados en memoria para guardar alg´ un dato que esperamos tener que volver a usar pronto, bien porque lo hemos usado recientemente o porque es de uso recurrente. Durante a˜ nos las caches se han usado a bajo nivel, siendo su principal uso el ahorro de operaciones de acceso a disco, disminuyendo en muchos casos el tiempo de respuesta de los ordenadores [7]. A pesar de su extendido uso como herramienta en la gesti´ on de sistemas operativos, con la aparici´ on de internet se le dio un nuevo uso. [10] 2.5. Web caching Con la generalizaci´ on del uso de internet el ancho de banda de las primeras instalaciones existentes estaba empezando a coparse. Hac´ ıa falta un parche que solventase en parte este problema. Entonces, se adapt´ o el sistema de caches y se aplico a la navegaci´ on web. B´ asicamente consiste en crear una copia en local de una web la que hayamos accedido muy recientemente, y en caso de querer volver a acceder a ella en un corto plazo de tiempo, en vez de ir al servidor y descargarla de nuevo, si no ha pasado m´ as de ciertos minutos desde la creaci´ on de la cach´ e, se utilizar´ a la versi´ on local. Cabe la posibilidad de que la pagina web que est´ a descargada cambie dentro del tiempo que se supone que deber´ ıa ser v´ alida. En ese caso la web no mostrar´ a la informaci´ on actualizada [1]. 20 CAP´ ITULO 2. ESTADO DEL ARTE 2.6. Web scrapping y los datos abiertos El Web Scrapping es una t´ ecnica que consiste en el an´ alisis de paginas web, para la extracci´ on de datos contenidos en las mismas. Luego esos datos pueden almacenarse para su posterior uso. T´ ecnicas de este tipo son utilizadas por ejemplo por los comparadores web entre otros muchos servicios. Los datos que almacenan las paginas web puede que a veces est´ en sometidos a cierta normativa de propiedad, por ello en EEUU ya ha habido sanciones en contra de empresas y personas por hacer scrapping de sitios web [17] y entender que estaban violando una propiedad personal. Por ello en los ´ ultimos tiempos, sobretodo en el plano pol´ ıtico, se ha hecho un avance en transparencia de datos, y gobiernos municipales y nacionales, as´ ı como empresas privadas, est´ an poniendo en marcha proyectos de Datos Abiertos. Las webs de Datos Abiertos, son sitios donde se publican datos de muy diversos aspectos para el uso general evitando generar conflictos de propiedad de la informaci´ on, ya que est´ an dise˜ nadas precisamente para darle uso a esos datos. Adem´ as en muchas ocasiones estas webs ofrecen los datos ya recopilados en archivos de tipo XML, JSON o similares, facilitando la tarea del programador que necesite utilizarnos y haciendo casi innecesario tener que hacer un scrapper. 2.7. Soluci´ on Planteada Para solucionar el problema que se planteaba para el sistema de altavoces inteligentes que se quiere desplegar, se ha pensado en una soluci´ on que combina el web caching y el web scrapping. Luego explicaremos de manera m´ as detallada como se ha hecho cada parte, pero aqu´ ı vamos a dar una explicaci´ on general de como funciona el sistema. Figura 2.3: Diagrama del sistema 2.7. SOLUCI ´ ON PLANTEADA 21 Se crear´ a un scrapper que hay que programar manualmente para cada una de las webs de las que se quiera extraer informaci´ on. El scrapper lo que hace es, mediante el uso de algunas librer´ ıas de Python, que luego detallaremos, analizar las webs en busca de ciertos campos, que son los que queremos extraer para posteriormente almacenarlos en un archivo JSON. Este archivo JSON tendr´ a catalogados mediante etiquetas los datos que quisi´ eramos extraer de esa web concreta. Para cada nueva web de la que queramos obtener los datos habr´ ıa que dise˜ nar un nuevo scrapper. Posteriormente todos los archivos JSON se juntan en uno solo que ser´ a la cache atomizada para el municipio en el que se encuentre el altavoz. Esa cache general ser´ a la que se env´ ıe a los altavoces para su lectura en caso de no disponer de conexi´ on a internet. El paso de la cache atomizada al servidor se hace mediante un protocolo que se ha dise˜ nado para este fin que se basa en encapsular en peticiones HTTP el contenido a enviar, y que es desencapsulado en los clientes, ya como archivo JSON [13], preparado para su lectura. Finalmente se ha dise˜ nado una skill para Mycroft [12] cuya funcionalidad consiste en leer la cach´ e recibida desde el servidor para darle al usuario la informaci´ on que requiera. Se ha dise˜ nado intentando abarcar el m´ aximo n´ umero posible de construcciones verbales de las que se puedan formular las preguntas que deber´ ıan responderse. 22 CAP´ ITULO 2. ESTADO DEL ARTE Cap´ ıtulo 3 Plan de Desarrollo 3.1. Introducci´ on A continuaci´ on detallaremos como se ha desarrollado el proyecto, a que metodolog´ ıa se adapta, cuales han sido las fases de desarrollo del mismo, as´ ı como las herramientas utilizadas, incluyendo software de desarrollo, IDE, librer´ ıas, o los sistemas operativos. 3.2. Calendario de realizaci´ on del Trabajo de Fin de Grado La duraci´ on del TFG en este grado es de 300 horas. Debido a que las practicas las he desarrollado junto con este Trabajo de Fin de Grado, y en el mismo laboratorio, y al no tener asignaturas por cursas, ni ning´ un compromiso laboral externo, la dedicaci´ on del desarrollador ha podido ser completa. Desde el inicio de este segundo cuatrimestre hasta la fecha limite de entregas ha habido 154 d´ ıas, a los que hay que restar como m´ ınimo los 44 d´ ıas de fin de semana que ha habido de por medio. Teniendo en cuenta que entre practicas y TFG suman 600 horas, si repartimos estas horas entre los 110 d´ ıas disponibles, nos sale un promedio de 5,45 horas al d´ ıa. Si bien desde Febrero hasta Junio la jornada habitual ha sido de 9 a 2 de la tarde, es decir, 5 horas/d´ ıa, y para compensar el resto de horas, durante el mes de Junio y Julio, adem´ as de las 5 horas de por la ma˜ nana se ha seguido con el trabajo por la tarde para cumplir los plazos exigidos, teniendo en cuenta otras festividades como Semana Santa o el D´ ıa de Castilla y Le´ on. Se ha utilizado todo el tiempo disponible. 3.3. Plan de desarrollo del software La metodolog´ ıa que hemos utilizado para el desarrollo de este proyecto ha sido una metodolog´ ıa Incremental. En esta metodolog´ ıa de desarrollo de software se va construyendo el proyecto final de manera progresiva. En cada etapa incremental se a˜ nade una nueva funcionalidad, lo que permite ver resultados de una forma m´ as r´ apida en comparaci´ on con el modelo en cascada. 23 24 CAP´ ITULO 3. PLAN DE DESARROLLO Adem´ as permite que el software se puede empezar a utilizar incluso antes de que se complete totalmente y, en general, es m´ as flexible que otras metodolog´ ıas. La ventaja de haber usado una metodolog´ ıa incremental adem´ as es que por necesidades de desarrollo todo el proyecto ha sido desarrollado de una forma muy modular, de tal manera que a˜ nadir nuevas funcionalidades a lo que ya est´ a dise˜ nado no supondr´ a un problema, ya que todos los posibles elementos a a˜ nadir tienen un claro lugar de encaje. El uso de esta metodolog´ ıa se ha dado sobretodo en la creaci´ on del sistema de paso de las cach´ es entre cliente y servidor, donde hasta hacerlo funcionar completamente, ha habido 4 iteraciones: En la primera iteraci´ on se cre´ o un cliente y un servidor b´ asicos que fuesen capaces de comunicarse entre ellos pas´ andose un mensaje el uno al otro. Para la segunda iteraci´ on se crearon los diagramas de estados que veremos m´ as adelante tanto del lado del cliente como del lado del servidor y se fueron implementando sobre la estructura previamente creada las primitivas que se dise˜ naron. Hizo falta hacer una tercera iteraci´ on para cambiar como estaba montando el servidor ya que debido a un fallo de dise˜ no hubo que incluir una primitiva m´ as y para que fuese m´ as modular se cambio de uno a varios endpoints, de tal manera que cada nueva primitiva ejecutaba una porci´ on de c´ odigo del servidor y as´ ı no hab´ ıa casi que cambiar lo anterior. La cuarta iteraci´ on simplemente a˜ nadi´ o otra primitiva m´ as de la que nos dimos cuenta mientras implement´ abamos la tercera. Luego en el an´ alisis del proyecto explicaremos que esto forma parte de un proyecto m´ as amplio, para el que ya se hab´ ıan desarrollado dos trabajos previos que necesitaban de cierta adaptaci´ on. Por ello la primera parte del desarrollo de este proyecto no se adapta a la metodolog´ ıa indicada, pero si el desarrollo de la mejora propuesta para el sistema general de altavoces desarrollada en este trabajo, que es el dise˜ no e implementaci´ on de un software que crea caches atomizadas por poblaci´ on para su futuro uso offline. 3.4. Riesgos En esta secci´ on analizaremos los riesgos por los que el proyecto puede verse afectado. Estos riesgos pueden suponer desde un retraso en la fecha de entrega del proyecto hasta un posible aumento de los costes. Para ello nos hemos guiado del libro estandarte sobre la gesti´ on de proyectos [5]. Los riesgos deben analizarse, seg´ un el libro de referencia, teniendo en cuenta la probabilidad de que acabe pasando y el posible impacto que pueda tener en el proyecto en general. Los riesgos detectados para este proyecto son los siguientes: 3.4. RIESGOS 25 C´ odigo Descripci´ on R-01 Baja del desarrollador R-02 P´ erdida del trabajo realizado R-03 Cierre de algun servicio externo R-04 Cierre del centro de trabajo R-05 Mala planificaci´ on del proyecto A continuaci´ on detallaremos para cada uno de los riesgos el impacto que puede tener el proyecto, la probabilidad de que ocurran y como podr´ ıa solucionarse o mitigarse. R-01: La baja del desarrollador, por enfermedad o cualquier causa sobrevenida sobre la persona que se est´ a encargando de la realizaci´ on del proyecto es un riesgo que tiene distintas posibles soluciones en funci´ on del tiempo que dure el problema: Si la circunstancia sobrevenida no se alarga demasiado en el tiempo (identificamos esta variante como R-01.1): Impacto BAJO Probabilidad SIGNIFICANTE Mitigaci´ on Dar descanso al desarrollador Soluci´ on Alargar brevemente el proyecto, o aumentar la intensidad de trabajo a la vuelta de la baja Si la circunstancia sobrevenida se alarga en el tiempo (identificamos esta variante como R-01.2): Impacto SIGNIFICANTE Probabilidad MODERADA Mitigaci´ on Evitar sobrecargar al desarrollador Soluci´ on Alargar bastante la duraci´ on del proyecto, o teletrabajar desde casa R-02: Si debido a algun problema f´ ısico con los dispositivos con los que se est´ a desarrollando el c´ odigo del proyecto, se perdiese el trabajo realizado, supondr´ ıa un importante retraso en la entrega del proyecto. Estos problemas van desde la rotura de los propios equipos, hasta un posible incendio que arrase el edificio en el que se encuentran estos equipos. Impacto ALTO Probabilidad BAJA Mitigaci´ on Utilizar software de almacenamiento en linea para los archivos que conforman el proyecto. Soluci´ on Rehacer el proyecto o continuarlo desde una versi´ on m´ as antigua que puede que no se haya perdido. 32 CAP´ ITULO 4. AN ´ ALISIS DEL PROYECTO La API se dise˜ n´ o en Kotlin y es la encargada de gestionar todas las operaciones entre el cliente, en este caso cada uno de los altavoces, y el servidor donde estaba almacenada la informaci´ on sobre el usuario que tenia asignado cada dispositivo, as´ ı como su estado o su localizaci´ on geogr´ afica. Para el dise˜ no de la web de gesti´ on, desde la que se ejecutan a trav´ es de la API las operaciones para controlar los altavoces, se utiliz´ o Vue, un lenguaje que combina HTML, JavaScript y CSS en un ´ unico archivo, facilitando mucho la labor del programador, que no tenia 3 archivos distintos para cada vista de la web. Las operaciones que pueden llevarse a cabo con este sistema van desde el cambio de ciertos par´ ametros de los altavoces, as´ ı como reinicios, apagados, o actualizaciones del sistema. Este proyecto es de una gran envergadura, y a pesar de que funciona a la perfecci´ on, y ser adem´ as bastante modular en forma, resulta bastante complicado incorporar las funcionalidades que se desarrollaron en el segundo trabajo, as´ ı como las que hemos desarrollado en este. La parte de front-end, es decir los clientes, se dise˜ n´ o para funcionar sobre un sistema de c´ odigo abierto para la gesti´ on precisamente de altavoces inteligentes llamado Snips, que en este caso correr´ ıa sobre Raspbian. Al final del desarrollo del mismo se anunci´ o que Snips se iba a convertir en un sistema privativo tras su compra por la compa˜ n´ ıa Sonos. Esto oblig´ o a tener que buscar una alternativa open-source, que fue Mycroft, y su sistema operativo Picroft basado tambi´ en en Raspbian, pero menos desarrollado que Snips. Esto provoc´ o que el desarrollo de la parte que se refiere al habla no pudiese realizarse finalmente. 4.2.2. Proyecto 2 El segundo proyecto, se realiz´ o de forma casi paralela al primero debido a que la pandemia retras´ o los plazos de entrega, y aunque empez´ o lo suficientemente tarde como para que ya pudiese ser realizado desde cero en Picroft y no en Snips, la idea original era continuar con el desarrollo del trabajo realizado por el otro estudiante. En este segundo proyecto se ahond´ o en la parte conversacional de los altavoces y se creo un sistema de alertas con prioridad que buscaba que tras cada conversaci´ on de un usuario con el altavoz, o que en momentos concretos del d´ ıa, este narrase alg´ un aviso importante que el usuario debiese conocer (como por ejemplo sobre la potabilidad del agua). Tambi´ en se comenz´ o a desarrollar un sistema que extra´ ıa informaci´ on de sitios web para su lectura posterior. Para todo ello de nuevo se realiz´ o un sistema cliente-servidor de cero, con una web de gesti´ on sencilla, un cliente, y el desarrollo de una base de datos din´ amica que ordenaba las alertas que deb´ ıan narrarse en funci´ on de su prioridad. 4.3. Identificaci´ on de requisitos A continuaci´ on expondremos los requisitos que deber´ a satisfacer el sistema: 4.3. IDENTIFICACI ´ ON DE REQUISITOS 33 4.3.1. Requisitos funcionales ID Descripci´ on RF-1 El dispositivo debe ser capaz de identificarse ante el sistema. RF-2 El dispositivo debe poder recibir la cach´ e del servidor. RF-3 El sistema debe recopilar informaci´ on de la API de AEMET. RF-4 El sistema debe recopilar informaci´ on de la web de la Diputaci´ on de Valladolid. RF-5 El dispositivo debe poder actualizar de forma peri´ odica. RF-6 El sistema debe comprobar si el dispositivo est´ a registrado. RF-7 El sistema debe comprobar si la cach´ e descargada en el dispositivo es reciente. RF-8 El sistema debe comprobar si la informaci´ on recopilada de la API de AEMET ha sido actualizada. RF-9 El sistema deber´ a permitir conversaciones simples de pregunta-respuesta entre el usuario y el altavoz. RF-10 El sistema deber´ a permitir al usuario conocer la ´ ultima informaci´ on disponible sobre el tiempo. RF-11 El sistema deber´ a permitir al usuario conocer la informaci´ on disponible del ayuntamiento. RF-12 El sistema deber´ a permitir al usuario saber de cuando es la ´ ultima informaci´ on que est´ a disponible. RF-13 El sistema deber´ a permitir al usuario saber en qu´ e localidad se encuentra situado el altavoz. 4.3.2. Requisitos de informaci´ on ID Descripci´ on RI-1 El sistema deber´ a almacenar informaci´ on del municipio en el que est´ e colocado. RI-2 El sistema deber´ a almacenar informaci´ on sobre la fecha de descarga de la ´ ultima cach´ e. RI-3 El sistema deber´ a almacenar informaci´ on sobre los dispositivos con acceso al servicio, concretamente, su direcci´ on MAC como identificador, y un token generado en funci´ on de la MAC. RI-4 El sistema deber´ a almacenar informaci´ on del ayuntamiento, concretamente, direcci´ on postal, numero de tel´ efono, numero de fax y el correo electr´ onico. RI-5 El sistema deber´ a almacenar informaci´ on de la previsi´ on del tiempo, concretamente, la fecha de la previsi´ on, la probabilidad d precipitaci´ on, la cota de nieve, el estado del cielo, la velocidad y la direcci´ on del viento, las temperaturas m´ axima y m´ ınima. 34 CAP´ ITULO 4. AN ´ ALISIS DEL PROYECTO 4.3.3. Requisitos No Funcionales ID Descripci´ on RNF-1 Los clientes deber´ an poder ser desplegados en m´ aquinas Raspberry Pi 3 Modelo B+. RNF-2 El servidor deber´ a poder ser desplegado en cualquier sistema capaz de ejecutar c´ odigo Python. RNF-3 El sistema dispondr´ a de una capa de seguridad b´ asica basada en autenticaci´ on de los dispositivos mediante usuario y contrase˜ na. RNF-4 El asistente deber´ a poder comunicarse en Castellano. RNF-5 El asistente deber´ a minimizar el numero de veces que acude al servidor para descargar la cach´ e. RNF-6 El sistema deber´ a minimizar el n´ umero de veces que descarga nueva informaci´ on de la API de AEMET. RNF-7 Los asistentes deber´ an procesar la m´ ınima informaci´ on necesaria para ser funcionales. 4.4. Casos de uso Debido a que este proyecto aunque presenta una parte de interacci´ on con el usuario, principalmente est´ a enfocado al dise˜ no del sistema de creaci´ on de caches y paso de estas desde los servidores a los clientes, este diagrama de casos de uso tiene tres: Figura 4.1: Diagrama de casos de uso Estos casos de uso representan los dos tipos de operaciones que el usuario puede hacer contra el cliente, que son pedir informaci´ on del ayuntamiento, pedir informaci´ on del tiempo atmosf´ erico, y pedir informaci´ on sobre el propio dispositivo, como la fecha de la cach´ e descargada, o el municipio para el que est´ a configurado. El resto de acciones del sistema, al no haber desarrollado un servidor con interfaz gr´ afica si no que es un servidor que est´ a en constante espera de peticiones de los clientes y cuyo funcionamiento una vez llegan estas es totalmente autom´ atico. 4.5. COSTES 35 4.5. Costes A continuaci´ on haremos una estimaci´ on de los costes que podr´ ıa haber tenido el proyecto si este hubiese sido realizado por una empresa. La duraci´ on del proyecto son 300 horas. El salario medio de un Programador Junior, es decir un estudiante de Ingenier´ ıa Inform´ atica que a´ un no est´ a en posesi´ on del titulo debido a que no ha finalizado sus estudios, en Espa˜ na es de 19477C [11]. Si hacemos los c´ alculos teniendo en cuenta que en Espa˜ na en 2021 habr´ a 254 d´ ıas laborables, tenemos que: 9477 euros al a˜ no 254 d´ ıas laborables = 76,68 euros / d´ ıa laborable 76,68 euros por d´ ıa laborable 8horas por jornada = 9,59euros/hora 9,59 euros por hora trabajada ∗300 horas = 2877C Los costes del hardware utilizado son aproximadamente los siguientes [20] [9]: Componente Coste Raspberry Pi 3 Modelo B+ 40C ReSpeaker 2-Mics Pi HAT 10C Carcasa de pl´ astico impresa en 3D 15C Por lo que sumando los costes anteriores, el precio final que tendr´ ıa el proyecto ser´ ıa de 2942C. 36 CAP´ ITULO 4. AN ´ ALISIS DEL PROYECTO Cap´ ıtulo 5 Dise˜ no e implementaci´ on 5.1. Recursos y herramientas A continuaci´ on detallaremos todas las herramientas y software utilizado durante el desarrollo del proyecto, as´ ı como las librer´ ıas m´ as importantes que permiten el correcto funcionamiento del mismo. 5.1.1. Mycroft Es un sistema de gesti´ on de asistentes de voz de c´ odigo abierto [12], que permite la creaci´ on de skills que permitan la interacci´ on humano-altavoz de una manera muy sencilla. Dispone de multitud de herramientas ejecutables mediante linea de c´ odigo que autogeneran skills y permiten editar configuraciones sobre las ya creadas. Para la conversi´ on de texto a lenguaje y viceversa utiliza lo siguiente: Google STT (Speech-to-text): Por el momento Mycroft para realizar la conversi´ on de voz a texto utiliza un servicio externo de Google. Es cierto que este proyecto busca poder independizar el sistema de altavoces de internet hemos de explicar que eso de momento no es posible, y es debido a que al correr estos en una Raspberry, resulta imposible que el an´ alisis sint´ actico de las ordenes del usuario y la s´ ıntesis de voz del altavoz para generar la respuesta se hagan de manera local, ya que este tipo de dispositivos tiene una potencia de computo limitada. Adapt: Es el analizador sint´ actico que viene configurado por defecto para realizar el an´ alisis de intenci´ on, que es lo que se conoce com´ unmente como ¨ ıntent parser”. Es el encargado de detectar si en las palabras que hemos pronunciado se encuentra la palabra de activaci´ on. Google TTS (Text-to-speech): El sintetizador de voz que utiliza Mycroft por defecto para convertir el texto en voz para que lo narre de vuelta al usuario tras realizar este alguna petici´ on es Mimic, sin embargo, este sistema de momento no comprende entre sus idiomas el castellano, por lo que de nuevo nos vemos obligados a utilizar los servicios de Google. Gracias a la modularidad de Mycroft estos componentes pueden cambiarse por otros. Actualmente Mozilla se encuentra desarrollando junto a Mycroft un software de speech-to-text de c´ odigo abierto para dejar de depender de los servicios de Google, aunque por el momento no puede usarse en producci´ on. 37 38 CAP´ ITULO 5. DISE ˜ NO E IMPLEMENTACI ´ ON 5.1.2. Picroft Picroft es un sistema operativo basado en Raspbian Lite, de c´ odigo abierto y creado por Mycroft [12] que trae incluido todo lo necesario para poder utilizar Mycroft de forma nativa. 5.1.3. Astah Professional Programa utilizado para la realizaci´ on de los diagramas de secuencia y de casos de uso que se exponen en este trabajo, y que hemos utilizado en varias asignaturas a lo largo de la carrera. 5.1.4. draw.io Para otros diagramas m´ as sencillo he hecho uso de la aplicaci´ on online draw.io que permite crearlos de una forma sencilla e intuitiva, y adem´ as tiene una gran cantidad de s´ ımbolos que permiten hacer representaciones muy variadas, incluso UML. 5.1.5. Microsoft Visual Studio Es el IDE que se ha elegido para desarrollar el c´ odigo del proyecto. Es muy vers´ atil y tiene muchas extensiones que permiten visualizar el c´ odigo muy variados lenguajes, as´ ı como ejecutarlos, incluso en paralelo, funci´ on que ha sido muy ´ util para el desarrollo del cliente-servidor. 5.1.6. Overleaf Editor online de archivos L A T EXpara hacer la presente memoria. 5.1.7. Python Es el lenguaje utilizado para el desarrollo del proyecto completo. Cliente Servidor y skill est´ an dise˜ nados en Python, un lenguaje muy conocido por muchos motivos, entre otros por la simplicidad de su c´ odigo, su flexibilidad, y una comunidad muy grande que la respalda, creando un gran numero de librer´ ıas que simplifican nuestros trabajos. Para las caches as´ ı como en los mensajes que se pasan entre cliente y servidor hemos utilizado archivos JSON, por su facilidad de manejo. Las librer´ ıas m´ as importantes que hemos utilizado son las siguientes: requests: Esta librer´ ıa [19] nos permite hacer peticiones HTTP de una forma mucho m´ as simple. Adem´ as con urllib3 automatiza el uso de conexiones HTTP persistentes, que consiste en utilizar una ´ unica conexi´ on TCP y enviar sobre ella m´ ultiples peticiones HTTP. La manera de manejar las peticiones ser´ ıa la siguiente: r = requests.post(date_url, json=payload) 5.2. DIAGRAMA DE TIPOS DE PROCESOS DEL SISTEMA 39 cache_status = r.text Se har´ ıa la petici´ on y en el payload de la misma se introducir´ ıa la informaci´ on a enviar al servidor. Despu´ es la respuesta ser´ ıa analizada utilizando alguna de las m´ ultiples funciones que incluye la librer´ ıa como text para ver el contenido de la respuesta, status para el status que nos env´ ıa de vuelta el servidor o status_code para ver el c´ odigo de respuesta. json: Nos permite el manejo de este tipo de archivo. Podemos codificar y descodificar cadenas de texto, parsear Strings a JSON y viceversa... Estas funciones son muy ´ utiles para extraer la informaci´ on devuelta por el servidor tras una petici´ on HTTP y en funci´ on de la cadena que contenga ejecutar unas tareas u otras. beautifulsoup4 (bs4): Es una librer´ ıa [18] que nos permite hacer scrapping de sitios web. Es b´ asicamente un analizador de HTML y XML. Flask: librer´ ıa que utilizaremos para ejecutar el servidor. 5.2. Diagrama de tipos de procesos del sistema En esta secci´ on explicaremos el protocolo que hemos dise˜ nado para la creaci´ on y paso de cach´ es entre los altavoces y el servidor, los posibles procesos del sistema en cada punto y los mensajes. Se ha empleado notaci´ on SDL en vez de UML por la facilidad a la hora de representar los mensajes enviados por el cliente y el servidor y poder verlos comparados secuencialmente. 5.2.1. Diagrama del cliente En el lado del cliente es donde se da el inicio de la comunicaci´ on. El cliente con el env´ ıo de un mensaje de alive inicia el proceso de creaci´ on o actualizaci´ on de la cach´ e remota, y posterior recepci´ on. Con este primer mensaje se env´ ıan el usuario y la contrase˜ na que deber´ an estar previamente registradas en el servidor. El user o id est´ a conformado por la MAC del cliente, y la contrase˜ na se genera mediante un mecanismo dise˜ nado para el servidor del proyecto del back-end, y ha sido reutilizado para ser consistente y hacer m´ as f´ acil una futura integraci´ on. En caso de no coincidir con ninguna de las credenciales guardadas en el servidor este devolver´ a un mensaje de error y se interrumpir´ a la comunicaci´ on. Si el id es correcto, el cliente comprobar´ a si ya tiene una cach´ e descargada. En caso de tenerla, extrae la fecha de creaci´ on de esa cach´ e y se la env´ ıa al servidor para que este compruebe cuanto tiempo tiene. El servidor responde con la diferencia de tiempo, que, en caso de ser inferior a 12 horas, lo entiende como reciente, no descarga una nueva y se interrumpe la conexi´ on. Si han pasado m´ as de 12 horas continua el flujo normal del diagrama. Si por el contrario no hay ninguna cach´ e descargada en el dispositivo, se salta esta comprobaci´ on y el flujo continua normalmente. 40 CAP´ ITULO 5. DISE ˜ NO E IMPLEMENTACI ´ ON Una vez se ha comprobado si existe o no cache, y si en caso de existir la cach´ e descargada est´ a actualizada, lo siguiente que se hace es enviar al servidor la localidad en la que est´ a situado el altavoz. El servidor devuelve si puede generar una cache completa para esa poblaci´ on. En caso de no poder se interrumpe la conexi´ on. Si por el contrario se puede el cliente descarga directamente la cach´ e del servidor y continua el flujo normal. Si la cach´ e ha sido recibida en el paso anterior, finalmente se guarda en un archivo tipo JSON en la ruta /home/pi/caches, para que la pueda leer la skill dise˜ nada a estos efectos. A continuaci´ on vemos la figura que representa este flujo. 5.2. DIAGRAMA DE TIPOS DE PROCESOS DEL SISTEMA 41 Figura 5.1: Diagrama de tipo de proceso del lado del cliente 48 CAP´ ITULO 5. DISE ˜ NO E IMPLEMENTACI ´ ON Cap´ ıtulo 6 Pruebas A continuaci´ on se detallan las pruebas realizadas con el asistente, donde adem´ as se incluyen los di´ alogos que se pueden mantener con el dispositivo. 6.1. Pruebas del sistema de creaci´ on y paso de cach´ es Para probar el sistema de creaci´ on de cach´ es y paso de las mismas entre el servidor y el cliente se fueron probando las funciones seg´ un se implementaban, y como ya hemos explicado previamente, debido al uso de una metodolog´ ıa incremental todo se iba probando tras su desarrollo. Una vez ha habido un cliente-servidor completamente funcional se han hecho las siguientes pruebas: P-01 Solicitar cach´ e cuando no hay una descargada Resultado esperado Cach´ e descargada Resultado obtenido Cach´ e descargada Test satisfactorio S´ ı P-02 Solicitar cach´ e cuando hay una descargada y tiene m´ as de 12 horas Resultado esperado Cach´ e descargada. Resultado obtenido Cach´ e descargada. Test satisfactorio S´ ı P-03 Solicitar cach´ e cuando hay una descargada y tiene menos de 12 horas Resultado esperado Cach´ e actualizada. No se descarga una nueva. Resultado obtenido Cach´ e actualizada. No se descarga una nueva. Test satisfactorio S´ ı P-04 Intentar loguearse en el sistema estando el dispositivo bien registrado Resultado esperado Logged in. Resultado obtenido Logged in. Test satisfactorio S´ ı 49 50 CAP´ ITULO 6. PRUEBAS P-05 Intentar loguearse en el sistema estando el dispositivo no registrado Resultado esperado Wrong username. Resultado obtenido Wrong username. Test satisfactorio S´ ı P-06 Intentar loguearse en el sistema estando el dispositivo mal registrado (nombre de usuario incorrecto) Resultado esperado Wrong username. Resultado obtenido Wrong username. Test satisfactorio S´ ı P-07 Intentar loguearse en el sistema estando el dispositivo mal registrado (contrase˜ na incorrecta) Resultado esperado Wrong password. Resultado obtenido Wrong password. Test satisfactorio S´ ı P-08 Solicitar una cach´ e para un municipio que no est´ a en la lista de municipios de la AEMET. Resultado esperado El municipio no existe o no est´ a disponible para hacer la cach´ e. Resultado obtenido El municipio no existe o no est´ a disponible para hacer la cach´ e. Test satisfactorio S´ ı P-09 Solicitar una cach´ e para un municipio cuya web no est´ a integrada en la web de datos abiertos de la Diputaci´ on de Valladolid. Resultado esperado El municipio no existe o no est´ a disponible para hacer la cach´ e. Resultado obtenido El municipio no existe o no est´ a disponible para hacer la cach´ e. Test satisfactorio S´ ı 6.2. Pruebas de la skill que lee la cach´ e descargada Primeramente veremos las pruebas que se han hecho respecto de los di´ alogos relacionados con el tiempo atmosf´ erico. Expondremos todas las maneras de las que se le puede hacer las preguntas al dispositivo, sobre qu´ e se se le puede preguntar, y finalmente el resultado de las pruebas: Preguntas sobre el tiempo atmosf´ erico 1. Dime/Dame la ´ ultima informaci´ on disponible sobre el/acerca del/sobre la/acerca de la/sobre las/acerca de las ___________ 2. Cu´ al es la ´ ultima informaci´ on disponible sobre el/acerca del/sobre la/acerca de la/sobre las/acerca de las ___________ 3. Qu´ e informaci´ on tienes disponible sobre el/acerca del/sobre la/acerca de la/sobre las/acerca de las ___________ 6.2. PRUEBAS DE LA SKILL QUE LEE LA CACH ´ E DESCARGADA 51 4. Dime lo ´ ultimo que sepas sobre el/acerca del/sobre la/acerca de la/sobre las/acerca de las ___________ 5. Cu´ al es la ultima informaci´ on que tienes sobre el/acerca del/sobre la/acerca de la/sobre las/acerca de las ___________ 6. Qu´ e sabes del/de la ___________ 7. Cu´ al es el/la ___________ 8. Cu´ ales son las ___________ 9. A cu´ anto est´ a la cota de nieve 10. A que altura habr´ a hoy nieve Opciones 1. Tiempo 2. Cielo 3. Temperaturas 4. Temperatura m´ axima 5. Temperatura m´ ınima 6. Viento 7. Lluvia 8. Nieve Resultado de las pruebas: Al dotar a la skill de una gran diversidad de preguntas, que pueden ser formuladas en singular o plural y masculino o femenino, y a las que se podr´ ıa acoplar cualquiera de las posibles opciones de informaci´ on disponibles, las pruebas son satisfactorias y siempre responden lo que se esperaba. A continuaci´ on expondremos las preguntas que se le pueden hacer al asistente sobre los datos del ayuntamiento: Preguntas sobre el ayuntamiento: 1. Dime/Dame la ´ ultima informaci´ on disponible sobre el/acerca del ___________ del ayuntamiento 2. Dime/Dame el ___________ del ayuntamiento 3. Cu´ al es la ´ ultima informaci´ on disponible sobre el/acerca del ___________ del ayuntamiento 4. Qu´ e informaci´ on tienes disponible sobre el/acerca del ___________ del ayuntamiento 5. Dime lo ´ ultimo que sepas sobre el/acerca del ___________ del ayuntamiento 6. Cu´ al es la ultima informaci´ on que tienes sobre el/acerca del ___________ del ayuntamiento 7. Qu´ e sabes del ___________ del ayuntamiento 8. Cu´ al es el/la ___________ del ayuntamiento 52 CAP´ ITULO 6. PRUEBAS 9. Dime/Dame la ´ ultima informaci´ on disponible sobre el ayuntamiento 10. Cu´ al es la ´ ultima informaci´ on disponible sobre el ayuntamiento 11. Qu´ e informaci´ on tienes disponible sobre el ayuntamiento 12. Dime lo ´ ultimo que sepas sobre el ayuntamiento 13. Cu´ al es la ultima informaci´ on que tienes sobre el ayuntamiento 14. Qu´ e sabes del ayuntamiento Opciones 1. Email 2. Correo electronico 3. Correo 4. Tel´ efono 5. Fax Resultado de las pruebas: Al dotar a la skill de una gran diversidad de preguntas a las que se podr´ ıa acoplar cualquiera de las posibles opciones de informaci´ on disponibles, las pruebas son satisfactorias y siempre responden lo que se esperaba. Por ´ ultimo exponemos las preguntas que se pueden hacer sobre el propio dispositivo, para ayudar a los usuarios a determinar si la informaci´ on que est´ an recibiendo est´ a vigente: Preguntas sobre el dispositivo: 1. Dime para qu´ e pueblo estoy configurado 2. Dime en qu´ e pueblo estoy 3. Cu´ al es mi pueblo 4. En qu´ e pueblo estoy 5. De cu´ ando es la ´ ultima informaci´ on disponible 6. De cu´ ando es esta informaci´ on 7. De qu´ e d´ ıa es esta informaci´ on 8. De qu´ e fecha es esta informaci´ on Las preguntas son cerradas y no tienen opciones Resultado de las pruebas: Permitir a los usuarios que conozcan de cuando es la informaci´ on almacenada les ayudar´ a a determinar si es v´ alida o no. Ante estas preguntas se comprueban la fecha de descarga de la cach´ e y el municipio para el que se ha creado. Todas las preguntas reciben la respuesta que se esperaban para ellas. Cap´ ıtulo 7 Despliegue El despliegue del sistema se llevar´ a a cabo en 3 fases. La primera consistir´ a en la instalaci´ on de Picroft en una Raspberry y en hacer todas las configuraciones necesarias para que funcione con el hardware que hemos utilizado, e integrar la funcionalidad del Proyecto 1 en el sistema operativo. La segunda fase consistir´ a en el despliegue y ejecuci´ on del servidor que hemos creado. Esta tarea deber´ ıa ser la m´ as sencilla de todas si se configura de forma correcta un entorno virtual de ejecuci´ on en Windows o si no ejecutarlo en una m´ aquina Linux. La tercera consistir´ a en el despliegue y ejecuci´ on del cliente en Picroft, as´ ı como la instalaci´ on de la skill en el sistema montado en el paso 1 de esta gu´ ıa de despliegue. 7.1. Preparaci´ on de Picroft A continuaci´ on exponemos los pasos que deben realizarse para la correcta puesta en funcionamiento de Picroft. 1. Flasheamos Mycroft en la microSD, y elegimos configuraci´ on manual, y ejecutamos sudo raspi-config para cambiar la contrase˜ na a ”pi 2 la distribuci´ on de teclado a espa˜ nol. 53 54 CAP´ ITULO 7. DESPLIEGUE 2. Ejecutamos las siguientes ´ ordenes para instalar los controladores de la tarjeta de sonido que nos permitir´ a interactuar vocalmente con la Raspberry: pip install requests pip install pyopenssl sudo apt-get update sudo apt-get upgrade git clone https://github.com/respeaker/seeed-voicecard.git cd seeed-voicecard sudo ./install.sh 3. Reiniciamos la Raspberry, y al encenderse de nuevo ejecutamos mycroft-cli-client para que se abra el cliente de Mycroft y poder registrarlo en la web https://account.mycroft.ai/devices. Reiniciamos de nuevo la Raspberry y comprobamos que las skills b´ asicas funcionan en ingl´ es. 4. Editamos el fichero de configuraci´ on /etc/mycroft/mycroft.conf y sustituimos las lineas expuestas a continuaci´ on para configurar las lineas de entrada y salida de audio que vienen configuradas por defecto en la Raspberry, para que detecte correctamente los micr´ ofonos de la tarjeta de sonido, y que la salida de audio se produzca por el altavoz conectado a la misma . Las l´ ıneas a sustituir son las siguientes: ’’play_wav_cmdline’’:’’aplay -Dplughw:ArrayVAC10,0 %1’’ por ’’play_wav_cmdline’’:’’aplay -Ddmix:CARD=seeed2micvoicec,DEV=0 %1’’ y ’’play_mp3_cmdline’’:’’mpg123 -a plughw:ArrayUAC10,0 %1’’ por ’’play_mp3_cmdline’’:’’mpg123 -a plughw:CARD=seeed2micvoicec,DEV=0 %1’’ 5. Ejecutamos a continuaci´ on los dos siguientes comandos para cambiar el idioma en el que Mycroft comprende nuestras palabras y tambi´ en el idioma con el que responder´ a: mycroft-config set lang "es-es" mycroft-config set stt.mycroft.lang "es-es" 7.2. INSTALACI ´ ON DEL SERVIDOR 55 6. Ejecutamos el comando mycroft-config edit user y sustituimos el contenido por lo siguinte para acabar de configurar el idioma de Mycroft: { "max_allowed_core_version": 20.8, "lang":"es-es", "tts": { "espeak": { "lang":"es", "voice":"es" }, "module":"google" }, "stt": { "mycroft": { "lang":"es-es" } } } 7. Reiniciamos de nuevo la Raspberry, y al encenderla probamos que Mycroft ejecute skills b´ asicas ya en Castellano. 8. Copiamos el contenido de pregonero-controller del Proyecto 2 en /home/pi/pregonero/ y ejecuto setup.sh, y el contenido de pregonero-skill tambi´ en del Proyecto 2 en /opt/mycroft/skills/. 9. Copiamos el contenido de assistant.task del Proyecto 1 en /home/pi/. 10. Ejecutamos sudo apt install python3-pip ysudo apt install python-pip. 11. Accedemos al directorio de assistant.task y ejecutamos sh requeriments.sh. Por lo general nos obliga a ejecutarlo dos veces. 12. Reiniciamos la Raspberry y al encenderse Mycroft es completamente funcional con sus skills b´ asicas y las operaciones de gesti´ on remota de la Raspberry pueden hacerse desde el backend del Proyecto 1, ya que se conecta directamente tras ejecutar el paso 11. 7.2. Instalaci´ on del servidor Copiamos la carpeta server en la m´ aquina donde queramos ejecutarlo. Esta contiene los scrappers, asi como el programa que crea las caches de cada scrapper y el que las junta en un solo archivo, adem´ as del propio servidor. Habr´ ıa que ejecutar en el entorno en el que quisi´ eramos hacer correr el servidor el comando pip install -r requirements.txt que instala los paquetes necesarios para la correcta ejecuci´ on del entorno virtual en el que el servidor se ha comprobado funciona. Despu´ es, para ejecutar el servidor simplemente hay que hacer python server.py 56 CAP´ ITULO 7. DESPLIEGUE Para que pueda funcionar correctamente debemos introducir en el archivo credentials.json la MAC de la m´ aquina en la que se ejecute el cliente y su clave asociada. 7.3. Instalaci´ on de la skill Para la instalaci´ on de la skill que lee los datos de la cach´ e simplemente tenemos que copiar la carpeta speaker-reader-skill a la ruta /opt/mycroft/skills y reiniciar la Raspberry para que cuando Mycroft se inicie cargue la skill. 7.4. Instalaci´ on del cliente Para la instalaci´ on del cliente copiamos la carpeta client en el directorio /home/pi de Picroft. Es necesario previamente ejecutar el programa setup.py, que crea los directorios necesarios para el correcto funcionamiento del cliente, uno en el que se almacenan las caches que se descargan del servidor, y un archivo JSON con una localidad por defecto para que el cliente no falle a la hora de pedir una cach´ e al servidor. La localidad por defecto ser´ a Wamba. A continuaci´ on, para ejecutar el cliente simplemente hay que hacer python client.py Cap´ ıtulo 8 Conclusiones y trabajo futuro A continuaci´ on y para finalizar esta memoria expondremos unas breves conclusiones y que trabajo queda para el futuro. Un trabajo de este tipo te ayuda a comprender en mejor medida la dificultad que puede llegar a tener sacar adelante ciertos proyectos, y haberme dado cuenta con este que es sencillo, me hace pensar en todas las dificultades que tienen que surgir en proyectos de mayor calado, de cuanto tiempo de reflexi´ on y an´ alisis hay que emplear para que las cosas funcionen como deben. Otra conclusi´ on que he sacado es que el trabajo en equipo es mejor, porque tener a alguien al lado que te ayude o al que poder ayudar cuando no se sabes por donde seguir. Entiendo ahora que durante toda la carrera se nos haya forzado a hacer trabajos de este tipo ya que considero que es algo completamente necesario para la vida laboral. Tambi´ en es muy importante tener una buena planificaci´ on del proyecto, marcarse plazos y horarios, y metas asequibles, o hitos, que te permitan comprobar que avanzas en la buena direcci´ on. Como trabajo futuro remarcar´ ıa las siguientes tareas: Se podr´ ıa crear un script que sea capaz de crear nuevos archivos JSON de forma semiautom´ atica, y no haya que programarlo manualmente para cada nuevo sitio web del que queramos hacer scrapping. Buscando en internet aparecen grupos de trabajo que han avanzado en analizadores de webs de este tipo que luego son utilizados en otras webs del tipo comparador, como www.trivago.es, www.kayak.es u otras webs del estilo. Integrar el sistema aqui creado en el back-end dise˜ nado en el desarrollo del Proyecto 1. Ajustar de forma din´ amica el tiempo que tardan las cach´ es en actualizarse, en vez de hacerlo mediante un par´ ametro fijo. Cambiar la palabra de activaci´ on de Mycroft. Crear di´ alogos complejos con men´ us que permitan al usuario explorar todas las funcionalidades que le da la skill e ir ampli´ andola con las nuevas funciones que se a˜ nadan si se incluye alguna 57