Desarrollo de una prótesis personal con software y hardware libre
Descripción
´ tica Facultad de Informa
´n Departamento de Computacio
Proyecto de fin de Grado ´ tica en Ingenier´ıa Informa
Desarrollo de una pr´ otesis personal con software y hardware libre
Autor/a: Tirso Varela Rodeiro Director/a: Juan Jos´e S´anchez Penas A Coru˜ na, a 15 de junio de 2015.
Informaci´ on general
T´ıtulo del proyecto:
“Desarrollo de una pr´ otesis personal con software y hardware libre”
Clase de proyecto:
Proyecto Cl´asico de Ingenier´ıa
Nombre del alumno:
Tirso Varela Rodeiro
Nombre del director:
Juan Jos´e S´anchez Penas
Miembros del tribunal:
Miembros suplentes:
Fecha de lectura: Calificaci´on:
D. Juan Jos´e S´anchez Penas
CERTIFICA
Que la memoria titulada “Desarrollo de una pr´ otesis personal con software y hardware libre” ha sido realizada por Tirso Varela Rodeiro con D.N.I. 47.363.763-R bajo la direcci´on de Juan Jos´e S´anchez Penas. La presente constituye la documentaci´on que, con mi autorizaci´on, entrega el mencionado alumno para optar a la titulaci´on de Grado en Ingenier´ıa en Inform´atica.
A Coru˜ na, a 15 de junio de 2015.
A Pablo Rey Periscal, el hombre que camin´o 500 millas y habr´ıa caminado 500 m´as.
Agradecimientos En primer lugar, quisiera agradecer a todo el proyecto Exandounamano y a la empresa Igalia por dejarme participar en esta idea para hacer del mundo un lugar mejor, en concreto a Juan Jos´e S´anchez Penas y a Alejandro G. Castro por el apoyo y el tiempo que dedicaron a ayudarme. Tambi´en me gustar´ıa agradecer las facilidades y ayuda que me brind´o el grupo BricoLabs y la Domus de Coru˜ na en lo referente a la construcci´on f´ısica de la pr´otesis, destacando a Luigi Pirelli, Pablo L´opez y Luis Anllo.
Resumen El objetivo del proyecto aqu´ı presentado es crear una pr´otesis de extremidad superior con un sistema de informaci´on asociado que permita monitorizarla. La idea nace a partir de la comunidad Exandounamano, una comunidad sin a´nimo de lucro dedicada a la creaci´on y desarrollo de estas pr´otesis, y el intento de mejorar sus procesos de creaci´on e investigaci´on. Durante el proyecto aqu´ı descrito se ha construido un sistema completo, desde la pr´otesis f´ısica hasta el servidor que gestiona la informaci´on, construido en base a frameworks de alto nivel de abstracci´on. Todo ello siguiendo siempre la filosof´ıa del hardware y software libre garantizando que el producto final llegue al mayor n´ umero de personas posible, tanto usuarios como desarrolladores voluntarios que sigan mejorando el producto. El sistema consta de cinco partes bien diferenciadas: la mano artificial, creada con las nuevas t´ecnicas de impresi´on en tres dimensiones; un software de control, encargado del movimiento de la mano en funci´on de los est´ımulos recibidos de los m´ usculos de un brazo real as´ı como de la transmisi´on de estos datos al resto del sistema; un software local, que recibe los datos del movimiento temporalmente y los manda al servidor central a trav´es de internet; un servidor, que gestiona la persistencia de la informaci´on en el sistema; y, un cliente web que permite consultar, modificar y borrar el conocimiento que contiene el sistema.
Palabras clave: √ √ √ √ √ √ √ √ √
Biotecnolog´ıa Sistema de informaci´on Pr´otesis Arquitectura de componentes Arduino Impresora 3D Hardware libre Software libre Integraci´on
´Indice general
P´ agina 1. Introducci´ on
1
1.1. Referencia hist´ orica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1.2. Exandounamano . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
1.3. Alcance y objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
1.4. Estructura de la memoria . . . . . . . . . . . . . . . . . . . . . . . . . .
4
2. Revisi´ on del estado del arte
7
2.1. Introducci´ on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.2. Soluciones disponibles . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
2.2.1. Soluciones libres . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
2.2.2. Soluciones propietarias . . . . . . . . . . . . . . . . . . . . . . . .
9
3. Requisitos del sistema 3.1. Elementos b´ asicos
13 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
3.2. Casos de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
4. Metodolog´ıa
31
4.1. Metodolog´ıas de desarrollo software . . . . . . . . . . . . . . . . . . . . .
31
4.2. Desarrollo guiado por pruebas (TDD) . . . . . . . . . . . . . . . . . . .
32
5. Planificaci´ on y seguimiento
37
5.1. Planificaci´ on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
5.2. Seguimiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
42
6. Evaluaci´ on de costes
45
i
´INDICE GENERAL
ii 7. Arquitectura
47
7.1. Definici´ on arquitect´ onica . . . . . . . . . . . . . . . . . . . . . . . . . . .
47
7.2. Patrones arquitect´ onicos . . . . . . . . . . . . . . . . . . . . . . . . . . .
49
7.2.1. Capas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
49
7.2.1.1. Cliente-Servidor . . . . . . . . . . . . . . . . . . . . . .
49
7.2.1.2. Modelo-Vista-Controlador (MVC) . . . . . . . . . . . .
49
7.2.2. REST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
50
7.2.3. Componentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
51
7.2.4. FLUX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
51
8. Dise˜ no del sistema
53
8.1. Dise˜ no de cada componente . . . . . . . . . . . . . . . . . . . . . . . . .
53
8.1.1. Pr´ otesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
54
8.1.1.1. Tecnolog´ıas de apoyo . . . . . . . . . . . . . . . . . . .
54
8.1.2. Software de control: Arduino . . . . . . . . . . . . . . . . . . . .
55
8.1.2.1. Pruebas que configuraron el dise˜ no . . . . . . . . . . . .
57
8.1.2.2. Tecnolog´ıas de apoyo . . . . . . . . . . . . . . . . . . .
58
8.1.3. Software local: App para dispositivos m´oviles . . . . . . . . . . .
59
8.1.3.1. Pruebas que configuraron el dise˜ no . . . . . . . . . . . .
61
8.1.3.2. Tecnolog´ıas de apoyo . . . . . . . . . . . . . . . . . . .
66
8.1.4. Servidor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
68
8.1.4.1. Pruebas que configuraron el dise˜ no . . . . . . . . . . . .
72
8.1.4.2. Tecnolog´ıas de apoyo . . . . . . . . . . . . . . . . . . .
75
8.1.5. Cliente web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
76
8.1.5.1. Pruebas que configuraron el dise˜ no . . . . . . . . . . . .
78
8.2. Otras herramientas y tecnolog´ıas . . . . . . . . . . . . . . . . . . . . . .
83
9. Implementaci´ on del sistema
85
9.1. Pr´otesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
85
9.2. Arduino Uno . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
88
9.3. Aplicaci´ on m´ ovil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
90
9.4. Servidor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
93
9.5. Cliente web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
96
10. Pruebas del sistema
99
´INDICE GENERAL
iii
11. Conclusi´ on y futuras l´ıneas de trabajo
101
11.1. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 11.2. Futuras l´ıneas de trabajo A. Licencia
. . . . . . . . . . . . . . . . . . . . . . . . . . 103 107
A.1. Introducci´ on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 A.2. General Public License vs Affero General Public License . . . . . . . . . 107 A.3. Licencias de componentes usados . . . . . . . . . . . . . . . . . . . . . . 108 A.4. Licencia del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 B. Glosario de acr´ onimos
111
C. Glosario de t´ erminos
113
Bibliograf´ıa
115
iv
´INDICE GENERAL
´Indice de figuras
Figura
P´ agina
1.1. Pr´ otesis de Gottfried von Berlichingen . . . . . . . . . . . . . . . . . . .
2
3.1. Diagrama de casos de uso del software de control . . . . . . . . . . . . .
15
3.2. Diagrama de casos de uso del software local . . . . . . . . . . . . . . . .
17
3.3. Diagrama de casos de uso del servidor . . . . . . . . . . . . . . . . . . .
21
3.4. Diagrama de casos de uso del cliente web . . . . . . . . . . . . . . . . .
22
4.1. Test Driven Development (TDD) [1] . . . . . . . . . . . . . . . . . . . .
35
5.1. Diagrama de Gantt: Hamacas . . . . . . . . . . . . . . . . . . . . . . . .
38
5.2. Tareas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
5.3. Diagrama de Gantt: Tareas (parte 1) . . . . . . . . . . . . . . . . . . . .
40
5.4. Diagrama de Gantt: Tareas (parte 2) . . . . . . . . . . . . . . . . . . . .
41
7.1. Diagrama de componentes . . . . . . . . . . . . . . . . . . . . . . . . . .
48
8.1. Vista de la app m´ ovil . . . . . . . . . . . . . . . . . . . . . . . . . . . .
61
8.2. Diagrama E-R de la base de datos . . . . . . . . . . . . . . . . . . . . .
71
8.3. Vista del cliente web para un administrador . . . . . . . . . . . . . . . .
77
8.4. Vista del cliente web para un usuario . . . . . . . . . . . . . . . . . . . .
77
9.1. Desglose de las piezas de la mano artificial . . . . . . . . . . . . . . . . .
86
9.2. Conexi´ on entre el componente bluetooth y arduino . . . . . . . . . . . .
88
9.3. C´ odigo del funcionamiento del servo . . . . . . . . . . . . . . . . . . . .
89
9.4. Conexi´ on entre el sensor muscular, el m´ usculo y arduino . . . . . . . . .
90
9.5. Prueba de integraci´ on del plugin de bluetooth con Cordova . . . . . . .
91
9.6. C´ odigo del funcionamiento del la aplicaci´on m´ovil . . . . . . . . . . . . .
92
9.7. Ejemplo de modelo con mongoose . . . . . . . . . . . . . . . . . . . . . .
93
v
vi
´INDICE DE FIGURAS
9.8. Ejemplo de enrutamiento y procesamiento apoyado en express . . . . . .
94
9.9. Prueba ’Consultar listas de recursos almacenados’ con postman
. . . .
95
9.10. Prueba ’Consultar listas de recursos almacenados’ con postman
. . . .
97
´Indice de cuadros
Tabla
P´ agina
3.1. Caso de uso ‘Controlar movimiento’ . . . . . . . . . . . . . . . . . . . .
16
3.2. Caso de uso ‘Transmitir datos (Software de control)’ . . . . . . . . . . .
16
3.3. Caso de uso ‘Autenticar de usuario (Software local)’ . . . . . . . . . . .
17
3.4. Caso de uso ‘Mostrar informaci´on usuario (Software local)’ . . . . . . .
18
3.5. Caso de uso ‘Salir’ (Software local) . . . . . . . . . . . . . . . . . . . . .
18
3.6. Caso de uso ‘Forzar env´ıo de datos’ . . . . . . . . . . . . . . . . . . . . .
19
3.7. Caso de uso ‘Mostrar informaci´on detallada (Software local)’ . . . . . .
19
3.8. Caso de uso ‘Marcar evento’ . . . . . . . . . . . . . . . . . . . . . . . . .
20
3.9. Caso de uso ‘Recibir datos (Software Local)’ . . . . . . . . . . . . . . . .
20
3.10. Caso de uso ‘Recibir datos (Servidor)’ . . . . . . . . . . . . . . . . . . .
21
3.11. Caso de uso ‘Transmitir datos (Servidor)’ . . . . . . . . . . . . . . . . .
22
3.12. Caso de uso ‘Autenticar usuario (Cliente Web)’ . . . . . . . . . . . . . .
23
3.13. Caso de uso ‘Salir (Cliente Web)’ . . . . . . . . . . . . . . . . . . . . . .
23
3.14. Caso de uso ‘Mostrar informaci´on usuario (Cliente Web)’ . . . . . . . .
24
3.15. Caso de uso ‘Listar personas’ . . . . . . . . . . . . . . . . . . . . . . . .
24
3.16. Caso de uso ‘Ver persona concreta ’
. . . . . . . . . . . . . . . . . . . .
25
3.17. Caso de uso ‘Editar persona ’ . . . . . . . . . . . . . . . . . . . . . . . .
25
3.18. Caso de uso ‘Mostrar informaci´on detallada (Cliente web)’ . . . . . . . .
26
3.19. Caso de uso ‘Buscar persona por campo’ . . . . . . . . . . . . . . . . . .
27
3.20. Caso de uso ‘Listar pr´otesis’ . . . . . . . . . . . . . . . . . . . . . . . . .
27
3.21. Caso de uso ‘Agregar pr´otesis ’ . . . . . . . . . . . . . . . . . . . . . . .
28
3.22. Caso de uso ‘Listar sesiones’ . . . . . . . . . . . . . . . . . . . . . . . . .
28
3.23. Caso de uso ‘Agregar sesi´on’ . . . . . . . . . . . . . . . . . . . . . . . . .
29
3.24. Caso de uso ‘Ver sesi´ on concreta’ . . . . . . . . . . . . . . . . . . . . . .
29
3.25. Caso de uso ‘Listar experimentos’ . . . . . . . . . . . . . . . . . . . . . .
29
vii
´INDICE DE CUADROS
viii
3.26. Caso de uso ‘Agregar experimento’ . . . . . . . . . . . . . . . . . . . . .
30
8.1. Prueba ‘Simular movimiento de la pr´otesis’ . . . . . . . . . . . . . . . .
57
8.2. Prueba ‘Detectar est´ımulo muscular’ . . . . . . . . . . . . . . . . . . . .
57
8.3. Prueba ‘Transmitir por bluetooth’ . . . . . . . . . . . . . . . . . . . . .
58
8.4. Prueba ‘Comunicaci´ on con un servidor’ . . . . . . . . . . . . . . . . . .
62
8.5. Prueba ‘Comunicaci´ on peri´ odica con un servidor’ . . . . . . . . . . . . .
62
8.6. Prueba ‘Recibir datos por bluetooth’ . . . . . . . . . . . . . . . . . . . .
62
8.7. Prueba ‘Almacenar datos de forma persistente’ . . . . . . . . . . . . . .
63
8.8. Prueba ‘Comprobar conectividad’ . . . . . . . . . . . . . . . . . . . . . .
63
8.9. Prueba ‘Marcar evento’ . . . . . . . . . . . . . . . . . . . . . . . . . . .
64
8.10. Prueba ‘Forzar env´ıo’
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
64
8.11. Prueba ‘Autenticar usuario insatisfactoriamente (Software local)’ . . . .
65
8.12. Prueba ‘Autenticar usuario satisfactoriamente (Software local)’ . . . . .
65
8.13. Prueba ‘Consultar recurso concreto inexistente’ . . . . . . . . . . . . . .
72
8.14. Prueba ‘Consultar listas de recursos almacenados’
. . . . . . . . . . . .
72
8.15. Prueba ‘Consultar recurso concreto’ . . . . . . . . . . . . . . . . . . . .
73
8.16. Prueba ‘Almacenar nuevos datos de forma persistente’ . . . . . . . . . .
73
8.17. Prueba ‘Eliminar datos no almacenados en el sistema’ . . . . . . . . . .
74
8.18. Prueba ‘Eliminar datos almacenados de forma persistente’ . . . . . . . .
74
8.19. Prueba ‘Actualizar datos no almacenados en el sistema’ . . . . . . . . .
74
8.20. Prueba ‘Actualizar datos almacenados de forma persistente’ . . . . . . .
75
8.21. Prueba ‘Obtener lista de recursos del servidor’ . . . . . . . . . . . . . .
78
8.22. Prueba ‘Obtener recurso concreto del servidor’ . . . . . . . . . . . . . .
79
8.23. Prueba ‘Insertar nuevos datos en el sistema’ . . . . . . . . . . . . . . . .
79
8.24. Prueba ‘Eliminar datos inexistentes en el sistema’ . . . . . . . . . . . . .
80
8.25. Prueba ‘Eliminar datos almacenados en el sistema’ . . . . . . . . . . . .
80
8.26. Prueba ‘Actualizar datos inexistentes en el sistema’ . . . . . . . . . . . .
81
8.27. Prueba ‘Actualizar datos almacenados en el sistema’ . . . . . . . . . . .
81
8.28. Prueba ‘Autenticar usuario insatisfactoriamente (Cliente web)’ . . . . .
82
8.29. Prueba ‘Autenticar usuario satisfactoriamente (Cliente web)’ . . . . . .
82
10.1. Prueba ‘Comunicaci´ on insatisfactoria entre todos los componentes’ . . .
99
10.2. Prueba ‘Comunicaci´ on insatisfactoria entre todos los componentes’ . . . 100 10.3. Prueba ‘Reactivaci´ on del flujo’ . . . . . . . . . . . . . . . . . . . . . . . 100
Cap´ıtulo 1
Introducci´ on
1.1.
Referencia hist´ orica
El hombre desde siempre ha buscado soluciones a sus problemas, desde las primeras herramientas de s´ılex hasta hoy en d´ıa donde la biotecnolog´ıa ayuda a muchas personas a superar sus dificultades, sustituyendo partes de su cuerpo por miembros bi´onicos que les proporcionan una vida perfectamente normal. Aunque parezca un tema de actualidad, la primera mano mec´anica de la que se tiene noticia se construy´o en el a˜ no 1504 por encargo de Gottfried von Berlichingen de Hornberg, que habiendo perdido una de sus manos a causa del disparo de un ca˜ no´n, no se resign´o a vivir sin ella aunque no pudiera entrar en combate. Por ello, acudi´o a Nuremberg, el Silicon Valley de la ´epoca, famoso por la precisi´on de sus armeros y la aplicaci´on de nuevas tecnolog´ıas. All´ı se cre´o la primera mano mec´anica de la historia que se adaptaba al brazo del caballero, consegu´ıa girar la mu˜ neca, cerrar el pu˜ no, el movimiento independiente de cada falange y el pulgar. Tambi´en presentaba una serie de botones que devolv´ıan la pieza a su posici´on original. Desde entonces pas´o a la historia como ’el caballero de la mano de hierro’, llegando a escribir Goethe una obra biogr´afica de su vida en 1774 [3] .
1
2
1.1. Referencia hist´ orica
Figura 1.1: Pr´otesis de Gottfried von Berlichingen Tras muchos a˜ nos sin avances en este campo, durante la primera guerra mundial, donde la cantidad de personas que perdieron alguna extremidad aument´o exponencialmente, el cirujano alem´an Sauerbruch recuper´o la mano del caballero antes explicada para adaptarla a una soluci´on m´as moderna, convirti´endose as´ı en el prototipo de todas las manos artificiales hasta hoy en d´ıa. En su experimento alteraba la parte del brazo natural del paciente para que conectara con la pr´otesis y poder leer de manera rudimentaria las se˜ nales del brazo, esto se traduc´ıa en movimientos un tanto d´ebiles y difusos. A´ un as´ı, en su u ´ltima versi´on, consigui´o que los pacientes pudieran realizar tareas cotidianas como encender un cigarrillo o beber caf´e, como demuestra en un v´ıdeo que ´el mismo film´o.
1. Introducci´ on
1.2.
3
Exandounamano
Exandounamano es una comunidad que nace a ra´ız del caso concreto de Paula, una ni˜ na diagnosticada con agenesia en el brazo izquierdo, es decir, que su brazo izquierdo no se desarroll´o completamente. As´ı, a partir del caso de esta ni˜ na, se pretende crear un proceso gen´erico que pueda aplicarse a otros casos ayudando a otras personas con problemas similares. El proyecto Exandounamano defiende el hardware y el software libre para mejorar el aprendizaje colaborativo y el desarrollo conjunto, as´ı como la uni´on entre colectivos para construir desde la base con m´aquinas de fabricaci´on casera que hacen posible la autofabricaci´on en c´odigo abierto de una pr´otesis de miembro superior. Por el momento, es un proyecto de investiaci´on que se encuentra en sus primeras fases, se han construido algunos prototipos que consiguen realizar movimientos limitados pero cada d´ıa aumenta el n´ umero de voluntarios que se suman al proyecto acercando en el tiempo cada vez m´as y m´as la construcci´on de la pr´otesis perfecta. Durante el desarrollo de este proyecto se ha establecido contacto con la sede que tiene la comunidad en Sevilla para perfilar los requisitos que deb´ıa cumplir el proyecto e informar de los avances que se han ido consiguiendo. Una vez finalizado, el proyecto se entregar´a a esta comunidad con la esperanza de que sea de utilidad y abriendo la puerta a futuros desarrollos que lo mejoren.
1.3.
Alcance y objetivos
El objetivo final del presente proyecto es el mismo que el de la comunidad Exandounamano, conseguir un procedimiento en constante evoluci´on que permita mejoras sobre las pr´otesis creadas. Como se explic´o en el apartado anterior, es un proyecto de investigaci´on en busca de conocimiento pero con medios muy limitados. Una de estas limitaciones son las reuniones de pruebas de los avances; peri´odicamente los especialistas y desarrolladores se reunen para tratar una iteraci´on del proyecto realizando experimentos y comparando resultados.
4
1.4. Estructura de la memoria
Por el momento, todas estas sesiones se llevan a cabo ’en vivo’, esto es, sin soporte de ninguna tecnolog´ıa: se realiza un experimento, se comparan resultados, se toman notas en papel (y alg´ un v´ıdeo en contadas ocasiones) y se archivan siguiendo un proceso poco definido. Esto no es solo perjudicial para la continuaci´on del proyecto, sino que dificulta en sobremanera la repetici´on de experimentos, el contraste de resultados (la mayor´ıa de las veces los resultados a comparar son grandes series de n´ umeros de apariencia aleatoria) y la comunicaci´on (especialmente importante ya no solo a nivel interno del colectivo, tambi´en de cara a futuros voluntarios que quieran unirse a la comunidad en distintas localizaciones geogr´aficas). Por todo esto, sumado a que la menci´on del autor es Sistemas de Informaci´on, el objetivo de este proyecto se ha centrado en mejorar todo este procedimiento creando un sistema de informaci´on que sea capaz de almacenar toda los datos referentes a los experimentos, las reuniones, las personas involucradas y cualquier entidad necesaria para mejorar la comunicaci´on. El problema fundamental a resolver es crear un m´etodo con el que se consiga transmitir de forma autom´atica la informaci´on de los movimientos reales de la pr´otesis al sistema de consulta. Estos datos ser´an integrados con el resto de informaci´on a guardar de la sesi´on y del experimento, entendiendo sesi´on como cada una de las reuniones peri´odicas que se realizan para analizar los resultados de una iteraci´on y entendiendo experimento como cada una de las acciones que realiza la mano artificial. Por supuesto, tambi´en se guardar´a informaci´on de los participantes en cada reuni´on (perfil personal y otros datos de inter´es) y de las pr´otesis concretas (estado, mantenimientos, etc). Incluso se abrir´a la rama orientada al usuario final en la que el cliente podr´a consultar el estado de su pr´otesis en cualquier momento entre otras funciones al ineractuar con varios componentes del sistema creado.
1.4.
Estructura de la memoria
1. Introducci´ on: Breve referencia hist´orica y explicaci´on a grandes rasgos del proyecto. 2. Revisi´ on del estado del arte: Enumeraci´on de los productos y desarrollos disponibles en el mundo que comparten los objetivos de este proyecto.
1. Introducci´ on
5
3. Requisitos del sistema: Descripci´on de las diferentes funcionalidades que debe presentar el sistema detallando actores implicados, casos de uso y relaciones entre ellos. 4. Metodolog´ıa: En este apartado se explica detalladamente la metodolog´ıa empleada para el desarrollo del proyecto. 5. Planificaci´ on y seguimiento: Diagramas de Gantt y explicaci´on detallada del trabajo previsto en funci´on del tiempo y los recursos. En la segunda parte del cap´ıtulo se exponen las diferencias entre lo planificado y lo ocurrido. 6. Estudio de viabilidad y costes: Estimaci´on del coste final del proyecto y su viabilidad en funci´on de los requisitos y el tiempo. 7. Arquitectura: Explicaci´on de alto nivel del proyecto donde se tratan los patrones arquitect´onicos empleados para su construcci´on. 8. Dise˜ no: Descripci´on detallada del dise˜ no de cada componente, explicando tecnolog´ıas usadas en cada uno y los pasos a seguir para su implementaci´on. 9. Implementaci´ on: Explicaci´on detallada del proceso de implementanci´on de cada componente del proyecto. 10. Pruebas finales: Especificaci´on de las pruebas a seguir para cumplir con los objetivos del proyecto. 11. Conclusi´ on y futuras l´ıneas de trabajo: An´alisis de los resultados obtenidos , an´alisis del grado de satisfacci´on de los objetivos propuestos y futuras mejoras del producto entregado.
6
1.4. Estructura de la memoria
Cap´ıtulo 2
Revisi´ on del estado del arte
n este cap´ıtulo se comentan los proyectos vinculados al mundo de las pr´otesis que podr´ıan servir de referencia, inspiraci´on o alternativa al desarrollo realizado.
E
2.1.
Introducci´ on
A d´ıa de hoy existen una serie de grupos y organizaciones trabajando en esta a´rea en constante expansi´on. La novedad de este campo de trabajo se traduce en el gran n´ umero de proyectos de investigaci´on que se est´an realizando frente al reducido n´ umero de productos acabados y en el mercado. Por el momento, la idea m´as extendida es la b´ usqueda de creaci´on de conocimiento, no de creaci´on de un producto (con algunas excepciones, por supuesto). Como en toda la comunidad inform´atica, los proyectos de este campo tambi´en se dividen en desarrollos libres y desarrollos propietarios. Los primeros buscan la creaci´on de una comunidad en torno a su proyecto, bas´andose en la comunicaci´on de toda la informaci´on para conseguir una mejora constante. En el extremo opuesto se encuentran los desarrollos propietarios, limitando el conocimiento de cualquier fase del proyecto a personas pertenecientes al propio equipo de trabajo y que en la mayor parte de los casos concluir´a en la creaci´on de un producto que se comercializar´a con un precio poco econ´omico. Las soluciones m´as destacables en la actualidad de ambas vertientes se exponen a continuaci´on.
7
8
2.2. Soluciones disponibles
2.2. 2.2.1.
Soluciones disponibles Soluciones libres
Dextrus Proyecto iniciado por un graduado en rob´otica ingl´es bajo el nombre ’Open Hand Project’ que comparte objetivo con el proyecto Exandounamano: obtener una mano rob´otica de bajo coste que est´e al alcance de todas las personas con discapacidad en las extremidades superiores. De hecho, el objetivo no es lo u ´nico que comparte estos proyectos, la medici´on de los est´ımulos musculares que se traducen a movimiento y los materiales usados para la construcci´on de la pr´otesis son similares a los del proyecto aqu´ı explicado. No obstante, Dextrus consta solamente de dos partes: el modelo f´ısico de la mano artificial y el controlador, el proyecto que aqu´ı se presenta no solo cumple estas partes sino que a˜ nade funcionalidad que permitir´a estudiar y gestionar la pr´otesis a trav´es de un sistema m´as completo 1 .
e-NABLE Del ingl´es ’habilitar’, ’posibilitar’, ’permitir’. Comunidad de desarrollo de pr´otesis que surge en el continente africano con la necesidad de crear una pr´otesis para una ni˜ na con deformidades en su mano natural. Una vez terminado el primer proyecto se liberan los planos de construcci´on y funcionamiento para captar voluntarios que trabajen por su cuenta mejorando el dise˜ no y el producto final. En un primer momento del proyecto Exandounamano se contact´o con los fundadores de esta comunidad ofreciendo la posibilidad de trabajar de forma conjunta pero e-NABLE, por el momento, solo desarrolla manos artificiales totalmente mec´anicas. Al finalizar este proyecto se enviar´an los resultados, software y dise˜ nos obtenidos a esta comunidad por si en alg´ un momento deciden incluir alguno de los componentes aqu´ı tratados a su producto 2 .
1 2
Open Hand Project: (http://www.openhandproject.org/dextrus.php) e-NABLE: (http://enablingthefuture.org/)
2. Revisi´ on del estado del arte
2.2.2.
9
Soluciones propietarias
Mano BeBionic Vendida como ’la mejor pr´otesis del mundo’. Se trata de un producto final que ya se est´a comercializando que destaca por sus funcionalidades ergon´omicas. El movimiento de los dedos artificiales es mec´anico, impulsado a trav´es de peque˜ nos motores individuales ayudados por potentes microprocesadores que monitorizan la posici´on de cada dedo en tiempo real y de forma precisa. El producto incluye catorce patrones de agarre reconocidos que simplifican la interacci´on con la mano adem´as de la funci´on de ’autoagarre’ en la que la pr´otesis es capaz de detectar si un objeto se est´a deslizando debido a la gravedad y ejerce m´as fuerza para frenarlo. Tambi´en incluye software de control que permite personalizar varios par´ametros de la pr´otesis como potencia o velocidad para adaptarse a cada usuario. Los materiales y el dise˜ no de la mano refuerzan sus capacidades, durabilidad y resistencia. Esta soluci´on es un sistema con funcionamiento realmente parecido al proyecto presentado; las diferencias fundamentales radican en las tecnolog´ıas usadas, mucho m´as potentes y precisas en BeBionic, y, por supuesto, el tiempo y recursos involucrados en el desarrollo 3 . Michelangelo Mano artificial totalmente articulada desarrollada por una compa˜ n´ıa alemana en colaboraci´on con otra americana. Fue la primera pr´otesis en incorporar un dedo pulgar artificial totalmente funcional. Tambi´en funciona a trav´es de un sistema de electrodos. Desde 2011, esta soluci´on se ha proporcionado a gran cantidad de militares americanos que han sufrido amputaciones en conflicto 4 . ENK’D Peque˜ na empresa americana que se dedica al dise˜ no de pr´otesis, ocup´andose u ´nicamente de este nivel. Los dise˜ nos que consiguen son extremadamente realistas convirtiendo cualquier pr´otesis de las aqu´ı mencionadas en un simple guante o similar en funci´on de las preferencias del usuario 5 . 3
Bebionic: (http://es.bebionic.com) Ottobock: Michelangelo (http://www.ottobockus.com/prosthetics) 5 ENK’D (http://evan-kuester.squarespace.com/) 4
10
2.2. Soluciones disponibles
Bionic Hand Project El Insituto Tecnol´ogico Lausanne (Suiza) consigue llegar un paso m´as all´a creando una pr´otesis avanzada capaz de reproducir el sentido del tacto. Mediante un dispositivo que han desarrollado se traduce la informaci´on generada por la mano artificial a se˜ nales el´ectricas que permiten al sistema nervioso sentir texturas y formas en tiempo real. El usuario que ha utilizado la pr´otesis asegura que puede sentir lo mismo con su mano natural y con la mano artificial. El sistema de movimiento se basa en el uso de electrodos realmente peque˜ nos y precisos conectados al m´ usculo del brazo (un sistema similar al usado en este proyecto). Por el momento, solo se ha probado con un u ´nico usuario pero los investigadores est´an trabajando en mejorar la tecnolog´ıa para conseguir mayores capacidades y hacer el producto m´as confortable para los usuarios y conseguir as´ı la primera mano artificial totalmente funcional [4]. Pr´ otesis artificial controlada con la mente El profesor Oskar Aszmann, experto en cirug´ıa de reconstrucci´on, comenz´o en 2011 un proyecto de reconstrucci´on de extremidades en Gottingen, Alemania. El caso de los pacientes de este proyecto es especial, perdieron la movilidad de la mano en un accidente que desactiv´o las conexiones de la extremidad con el resto del cuerpo. El primer paso del proyecto fue transplantar tejido nervioso procedente de las piernas del paciente en el antebrazo para restaurar esas conexiones. El segundo paso consiste en la amputaci´on de la mano natural de los pacientes reemplaz´andola con la mano artificial que responde a los impulsos el´ectricos que llegan directamente desde el cerebro del usuario. A trav´es de rehabilitaci´on y t´ecnicas de restauraci´on se ha conseguido que la pr´otesis reproduzca casi en su totalidad el abanico de acciones que ofrece una mano natural. Se ha recubierto de un tejido similar en color y textura a la piel para darle un aspecto humano. El proyecto result´o ser un ´exito pero los propios investigadores involucrados advierten que todav´ıa no existen resultados a largo plazo que determinen si el proyecto cumple todos sus objetivos [5].
2. Revisi´ on del estado del arte
11
Es evidente que las diferencias que separan a unos proyectos de otros son abismales, especialmente los dos u ´ltimos expuestos. No obstante, el objetivo que mueve todos estos proyectos son distintos, los proyectos propietarios desarrollan esos grandes productos con el objetivo de lucrarse de los beneficios que obtendr´an al venderlos, los proyectos libres como el aqu´ı presente llegar´an a todas esas personas que no pueden permitirse esas soluciones de precios privativos, aport´andoles la mejora en calidad de vida que necesitan. Adem´as, es preciso resaltar que las tecnolog´ıas y funcionamientos usados en la mayor parte de los proyectos antes descritos son realmente similares al aqu´ı desarrollado, dando la oportunidad a este proyecto de convertirse en una soluci´on a tener en cuenta en un futuro no muy lejano.
12
2.2. Soluciones disponibles
Cap´ıtulo 3
Requisitos del sistema
na de las primeras tareas a realizar en un proyecto es la especificaci´on de requisitos, una descripci´on completa del comportamiento del sistema que se va a desarrollar. Debe incluir diagramas de casos de uso que describan todas las interacciones que tendr´an los usuarios con el software. En este cap´ıtulo se tratan los requisitos y funcionalidades finales (algunos requisitos variaron en el tiempo para ajustarse a cambios externos u optimizar la funcionalidad) que el proyecto debe cumplir una vez finalizado.
U
3.1.
Elementos b´ asicos
Actores Un actor es una entidad externa al sistema que guarda una relaci´on con este y que le demanda una funcionalidad. No solo son actores los operadores humanos, tambi´en se incluyen los sistemas externos. En el caso de los seres humanos se puede entender al actor como un rol por lo que a un mismo individuo le podr´ıan corresponder uno o m´as actores y viceversa. Los actores presentes en el caso que nos ocupa son varios: 1. Usuario: El usuario final, la persona que usar´a la pr´otesis y que tendr´a una cuenta asociada en la base de datos principal. 2. Personal: Parte de los trabajadores del proyecto Exandounamano que administran y gestionan todo lo relacionado con el proyecto (sesiones, pr´otesis, experimentos . . . ) 13
14
3.1. Elementos b´ asicos
3. Especialistas: Personas especializadas en alg´ un ´area relevante para el proyecto que realizan las tareas de apoyo. Formar´an parte de los administradores ya que estar´an presentes en las sesiones y su objetivo fundamental ser´a analizar los experimentos. Un ejemplo de este actor ser´ıa un doctor traumat´ologo colaborador. 4. Software de control : Actor que representa al software de control usado en el desarrollo. 5. Software local: Actor que representa el software local desarrollado en el proyecto. 6. Tiempo: Actor que representa el paso del tiempo. Relaciones
1. Communicates: Relaci´on b´asica que conecta un actor y un caso de uso que denota la participaci´on del actor en dicho caso de uso. 2. Extend : Relaci´on con direcci´on que especifica un comportamiento definido de forma opcional que ampl´ıa la funcionalidad del caso de uso al que extiende. En los diagramas aqu´ı expuestos, adem´as, est´an orientadas a ejemplificar el flujo final del sistema. 3. Include : Relaci´on con direcci´on entre dos casos de uso que indica inclusi´on, es decir, el comportamiento de un caso de uso est´a incluido en otro. A diferencia de la relaci´on extend, esta inclusi´on no tiene un car´acter opcional.
3. Requisitos del sistema
3.2.
Casos de uso
Figura 3.1: Diagrama de casos de uso del software de control
15
16
3.2. Casos de uso
C´ odigo
Controlar movimiento CU-001
Tipo
Caso de uso del software de control
Descripci´ on
El software de control interpreta los impulsos el´ectricos de los m´ usculos del usuario y lo transforma en el movimiento de la pr´otesis.
Actores
Individuo conectado a los sensores (usuario final o administrador)
Precondiciones
La pr´otesis y sensores deben estar correctamente conectados al software de control.
Postcondiciones
El movimiento de la pr´otesis se habr´a realizado.
Cuadro 3.1: Caso de uso ‘Controlar movimiento’
C´ odigo
Transmitir datos CU-002
Tipo
Caso de uso del software de control
Descripci´ on
El software de control recoge la informaci´on creada durante el movimiento de la pr´otesis y lo env´ıa al software local.
Actores
Tiempo, entendido como actor ya que es el que acciona la transmisi´on y la reactiva peri´odicamente en intervalos muy peque˜ nos de tiempo poniendo en marcha todo el sistema.
Precondiciones
La transmisi´on del software de control debe estar correctamente habilitada.
Postcondiciones
Los datos se enviaron al software local.
Cuadro 3.2: Caso de uso ‘Transmitir datos (Software de control)’
3. Requisitos del sistema
17
Figura 3.2: Diagrama de casos de uso del software local
C´ odigo
Autenticar usuario CU-003
Tipo
Caso de uso del software local
Descripci´ on
El usuario introduce sus credenciales y el sistema verifica que son correctas.
Actores
Usuario final y administradores
Precondiciones
El usuario no est´a autenticado.
Postcondiciones
El usuario est´a autenticado si la verificaci´on del sistema es positiva.
Cuadro 3.3: Caso de uso ‘Autenticar de usuario (Software local)’
18
3.2. Casos de uso
C´ odigo
Mostrar informaci´ on usuario CU-004
Tipo
Caso de uso del software local
Descripci´ on
El software local muestra la informaci´on de inter´es para el usuario relativa a su pr´otesis y a su cuenta.
Actores
Usuario final
Precondiciones
El usuario debe estar autenticado.
Postcondiciones
La informaci´on de usuario es mostrada.
Cuadro 3.4: Caso de uso ‘Mostrar informaci´on usuario (Software local)’
Salir C´ odigo
CU-005
Tipo
Caso de uso del software local
Descripci´ on
El sistema hace que el usuario deje de estar autenticado.
Actores
Usuario final y administradores
Precondiciones
El usuario debe estar autenticado.
Postcondiciones
El usuario ya no est´a autenticado
Cuadro 3.5: Caso de uso ‘Salir’ (Software local)
3. Requisitos del sistema
19
Forzar env´ıo de datos CU-006
C´ odigo Tipo
Caso de uso del software local
Descripci´ on
Un usuario autenticado fuerza el env´ıo de datos al servidor en lugar de esperar a que la aplicaci´on decida hacerlo.
Actores
Usuario final y administradores
Precondiciones
El usuario debe estar autenticado y debe estar activa una conexi´on con el servidor.
Postcondiciones
La informaci´on es enviada al servidor.
Cuadro 3.6: Caso de uso ‘Forzar env´ıo de datos’
C´ odigo
Mostrar informaci´ on detallada CU-007
Tipo
Caso de uso del software local
Descripci´ on
El software local entrega informaci´on detallada sobre la pr´otesis de un usuario.
Actores
Administradores
Precondiciones
El administrador debe estar autenticado.
Postcondiciones
Informaci´on detallada de una pr´otesis es mostrada por pantalla
Cuadro 3.7: Caso de uso ‘Mostrar informaci´on detallada (Software local)’
20
3.2. Casos de uso
C´ odigo
Marcar evento CU-008
Tipo
Caso de uso del software local
Descripci´ on
El software local almacena el evento asociado a la informaci´on recibida en un instante de tiempo concreto.
Actores
Administradores
Precondiciones
El administrador debe estar autenticado.
Postcondiciones
El evento seleccionado queda almacenado en el software local.
Cuadro 3.8: Caso de uso ‘Marcar evento’
C´ odigo
Recibir datos CU-009
Tipo
Caso de uso del software local
Descripci´ on
El software local recibe los datos enviados por el software de control.
Actores
Software de control
Precondiciones
El canal de comunicaci´on entre el software de control y el software local debe estar activo.
Postcondiciones
Los datos enviados por el software de control se almacenan el en software local.
Cuadro 3.9: Caso de uso ‘Recibir datos (Software Local)’
3. Requisitos del sistema
21
Figura 3.3: Diagrama de casos de uso del servidor Nota: En este componente reside la carga del sistema pero esas funcionalidades quedan patentes en los casos de uso de otros componentes que interact´ uan con el servidor dejando este diagrama simple.
C´ odigo
Recibir datos CU-010
Tipo
Caso de uso del servidor
Descripci´ on
El servidor recibe los datos enviados por el software local.
Actores
Software de control
Precondiciones
El canal de comunicaci´on entre el software local y el servidor debe estar activo.
Postcondiciones
Los datos enviados por el software local se almacenan de forma persistente en el servidor.
Cuadro 3.10: Caso de uso ‘Recibir datos (Servidor)’
22
3.2. Casos de uso
C´ odigo
Transmitir datos CU-011
Tipo
Caso de uso del servidor
Descripci´ on
El servidor transmite los datos requeridos por una consulta.
Actores
Cliente web y software local
Precondiciones
-
Postcondiciones
Los datos han sido enviados.
Cuadro 3.11: Caso de uso ‘Transmitir datos (Servidor)’
Figura 3.4: Diagrama de casos de uso del cliente web
3. Requisitos del sistema
23
C´ odigo
Autenticar usuario CU-012
Tipo
Caso de uso del cliente web
Descripci´ on
El usuario introduce sus credenciales y el sistema verifica que son correctas.
Actores
Usuarios finales y administradores.
Precondiciones
El usuario no est´a autenticado.
Postcondiciones
El usuario pasa al estado autenticado si la verificaci´on del sistema ha sido positiva.
Cuadro 3.12: Caso de uso ‘Autenticar usuario (Cliente Web)’
Salir C´ odigo
CU-013
Tipo
Caso de uso del cliente web
Descripci´ on
El sistema hace que el usuario deje de estar autenticado.
Actores
Usuarios finales y administradores.
Precondiciones
El usuario est´a autenticado.
Postcondiciones
El usuario deja de estar autenticado.
Cuadro 3.13: Caso de uso ‘Salir (Cliente Web)’
24
3.2. Casos de uso
Mostrar informaci´ on usuario CU-014
C´ odigo Tipo
Caso de uso del cliente web
Descripci´ on
El software local muestra la informaci´on de inter´es para el usuario relativa a su pr´otesis y a su cuenta.
Actores
Usuarios finales
Precondiciones
El usuario est´a autenticado.
Postcondiciones
Se muestran la informaci´on para el usuario.
Cuadro 3.14: Caso de uso ‘Mostrar informaci´on usuario (Cliente Web)’
C´ odigo
Listar personas CU-015
Tipo
Caso de uso del cliente web
Descripci´ on
Recupera una lista de las personas almacenadas en el sistema con la informaci´on correspondiente a cada una de ellas.
Actores
Administradores
Precondiciones
El administrador est´a autenticado.
Postcondiciones
Se muestra la lista de todas las personas almacenadas en el sistema.
Cuadro 3.15: Caso de uso ‘Listar personas’
3. Requisitos del sistema
25
Ver persona concreta CU-016
C´ odigo Tipo
Caso de uso del cliente web
Descripci´ on
Muestra una instancia concreta de la entidad persona.
Actores
Administradores
Precondiciones
El administrador est´a autenticado.
Postcondiciones
-
Cuadro 3.16: Caso de uso ‘Ver persona concreta ’
C´ odigo
Editar persona CU-017
Tipo
Caso de uso del cliente web
Descripci´ on
Modifica una instancia concreta de la entidad persona.
Actores
Administradores
Precondiciones
El administrador est´a autenticado.
Postcondiciones
Los datos modificados se almacenan de forma persistente.
Cuadro 3.17: Caso de uso ‘Editar persona ’
26
3.2. Casos de uso
C´ odigo
Mostrar informaci´ on detallada CU-018
Tipo
Caso de uso del cliente web
Descripci´ on
El cliente web entrega informaci´on detallada sobre un usuario o administrador concreto.
Actores
Administradores
Precondiciones
El administrador debe estar autenticado.
Postcondiciones
Informaci´on detallada de una persona es mostrada por pantalla
Cuadro 3.18: Caso de uso ‘Mostrar informaci´on detallada (Cliente web)’
3. Requisitos del sistema
27
Buscar persona por campo CU-019
C´ odigo Tipo
Caso de uso del cliente web
Descripci´ on
El cliente web busca una persona a trav´es de uno de sus atributos y, si la encuentra redirige al caso de uso CU018. En caso de no encontrarla muestra un mensaje de error.
Actores
Administradores
Precondiciones
El administrador debe estar autenticado.
Postcondiciones
Informaci´on detallada de una persona o un mensaje de error es mostrada por pantalla
Cuadro 3.19: Caso de uso ‘Buscar persona por campo’
C´ odigo
Listar pr´ otesis CU-020
Tipo
Caso de uso del cliente web
Descripci´ on
Recupera una lista de las pr´otesis almacenadas en el sistema con la informaci´on correspondiente a cada una de ellas.
Actores
Administradores
Precondiciones
El administrador est´a autenticado.
Postcondiciones
Se muestra la lista de todas las pr´otesis almacenadas en el sistema.
Cuadro 3.20: Caso de uso ‘Listar pr´otesis’
28
3.2. Casos de uso
C´ odigo
Agregar pr´ otesis CU-021
Tipo
Caso de uso del cliente web
Descripci´ on
Se crea una nueva instancia de la entidad pr´otesis en el sistema.
Actores
Administradores
Precondiciones
El administrador est´a autenticado.
Postcondiciones
Una nueva pr´otesis est´a almacenada de forma permantente en el sistema.
Cuadro 3.21: Caso de uso ‘Agregar pr´otesis ’
C´ odigo
Listar sesiones CU-022
Tipo
Caso de uso del cliente web
Descripci´ on
Se listan las sesiones almacenadas en el sistema.
Actores
Administradores
Precondiciones
El administrador est´a autenticado.
Postcondiciones
-.
Cuadro 3.22: Caso de uso ‘Listar sesiones’
3. Requisitos del sistema
29
C´ odigo
Agregar sesi´ on CU-023
Tipo
Caso de uso del cliente web
Descripci´ on
Se crea una nueva instancia de la entidad sesi´on en el sistema.
Actores
Administradores
Precondiciones
El administrador est´a autenticado.
Postcondiciones
Una nueva sesi´on forma parte del sistema.
Cuadro 3.23: Caso de uso ‘Agregar sesi´on’
C´ odigo
Ver sesi´ on concreta CU-024
Tipo
Caso de uso del cliente web
Descripci´ on
Se muestra la informaci´on referente a una sesi´on concreta.
Actores
Administradores
Precondiciones
El administrador est´a autenticado.
Postcondiciones
-
Cuadro 3.24: Caso de uso ‘Ver sesi´on concreta’
C´ odigo
Listar experimentos CU-025
Tipo
Caso de uso del cliente web
Descripci´ on
Se listan las sesiones almacenadas en el sistema.
Actores
Administradores
Precondiciones
El administrador est´a autenticado.
Postcondiciones
-
Cuadro 3.25: Caso de uso ‘Listar experimentos’
30
3.2. Casos de uso
C´ odigo
Agregar experimento CU-026
Tipo
Caso de uso del cliente web
Descripci´ on
Se crea una nueva instancia de la entidad experimento en el sistema.
Actores
Administradores
Precondiciones
El administrador est´a autenticado.
Postcondiciones
Existe un nuevo experimento en el sistema almacenado de forma persistente.
Cuadro 3.26: Caso de uso ‘Agregar experimento’
Cap´ıtulo 4
Metodolog´ıa
ste cap´ıtulo contiene una peque˜ na introducci´on a las metodolog´ıas software haciendo especial incidencia en las metodolog´ıas empleadas durante el desarrollo de este proyecto.
E
4.1.
Metodolog´ıas de desarrollo software
Una metodolog´ıa de desarrollo software es una representaci´on simplificada del proceso de desarrollo software presentada desde una perspectiva espec´ıfica que define su estructura, planeamiento y control. El objetivo general es dividir el desarrollo en distintas fases para simplificar su gesti´on. En la d´ecada de 1960 y gran parte de los 70 el desarrollo software depend´ıa pr´acticamente en su totalidad del programador al que se encargaba la implementaci´on, era algo muy similar al trabajo artesano que se realizaba en las f´abricas antes de la revoluci´on industrial. En 1968 se acu˜ na un t´ermino que describe a la perfecci´on la situaci´on de la inform´atica en aquel momento: ‘Crisis del software’. Los proyectos no terminaban en plazo, el software generado era de baja calidad y no segu´ıa ning´ un patr´on est´andar dando lugar a c´odigo inmantenible . . . A consecuencia de esto, se empiezan a aplicar mejoras en la calidad de producci´on de software para frenar esta situaci´on, surgiendo as´ı las metodolog´ıas basadas en el ciclo de vida del software.
31
32
4.2. Desarrollo guiado por pruebas (TDD)
Con esta nueva aproximaci´on el problema complejo que supone el desarrollo del producto final queda divido en peque˜ nas fases mucho m´as simples que juntas conforman un todo final mejorado, no solo estableciendo patrones comunes de desarrollo en toda la comunidad inform´atica, tambi´en mejorando la planificaci´on de tiempo y costes. Pronto se extiende el modelo en cascada, una metodolog´ıa lineal lo suficientemente buena para desbancar cualquier otra aproximaci´on hasta el momento convirti´endose en la metodolog´ıa cl´asica pero todav´ıa con algunos inconvenientes a resolver; uno de ellos es que el cliente solo participa en la primera y u ´ltima fase, quedando aislado durante todo el proceso que puede durar una cantidad indeterminada de tiempo. A ra´ız de este problema nacen otros modelos como el prototipado que se basa precisamente en eso, la construcci´on iterativa de prototipos que se presentan al cliente para su validaci´on y correcci´on, a˜ nadiendo en cada iteraci´on funcionalidades nuevas. Ese es el nacimiento de las conocidas metodolog´ıas a´giles, que buscan la r´apida respuesta al cambio y la colaboraci´on con el cliente frente al seguimiento del plan contractual de los modelos m´as cl´asicos.
4.2.
Desarrollo guiado por pruebas (TDD)
Metodolog´ıa a´gil de desarrollo que surge de la fusi´on de otras dos pr´acticas: escribir las pruebas primero (en ingl´es Test First Development) y refactorizaci´on. Se basa en la idea de desarrollar las pruebas, desarrollar el c´odigo que cumpla esas pruebas y refactorizar dicho c´odigo. Dado el car´acter variable y poco definido que tiene este proyecto al ser un proyecto de investigaci´on y a los componentes bien definidos, esta metodolog´ıa encaja perfectamente. Se crear´a un prototipo inicial de cada componente a partir de pruebas b´asicas (incluidas en el cap´ıtulo dedicado al dise˜ no de componentes) y se llevar´an a cabo gran n´ umero de iteraciones cortas sobre ´el, definiendo nuevas caracter´ısticas del sistema en cada iteraci´on seg´ un las necesidades que surjan.
4. Metodolog´ıa
33
Esta metodolog´ıa declara tres reglas: No escribir c´odigo software salvo para satisfacer una prueba fallida. Escribir u ´nicamente lo suficiente de una prueba para demostrar un fallo. Escribir u ´nicamente lo suficiente de c´odigo para superar una prueba. En un primer momento, esta metodolog´ıa puede parecer que solo se preocupa por las pruebas, desatendiendo los dem´as detalles del proceso; sin embargo, no se trata simplemente de un desarrollo como hace entender su nombre, es un dise˜ no. A trav´es de esas reglas simples se va configurando poco a poco el sistema aumentando la productividad y la eficiencia. El proceso a seguir es el siguiente: 1. Elegir un requisito. Comenzando por los m´as simples y que mayor visi´on del problema ofrezcan. 2. Escribir una prueba. Este paso obliga a ver el software desde el punto de vista del cliente, lo que aproxima al desarrollado a sus necesidades y aporta una visi´on m´as concreta del problema a resolver. 3. Verificar que la prueba falla. A esta fase tambi´en se la conoce como ’ROJO’. Si la prueba no falla en este paso es porque la funcionalidad ya estaba implementada o porque la prueba es err´onea. 4. Crear c´odigo espec´ıfico para resolver la prueba. Este c´odigo debe ser el c´odigo m´as sencillo que convierta la prueba en satisfactoria. 5. Ejecutar de nuevo la prueba. A esta fase tambi´en se la conoce como ’VERDE’. Si la prueba todav´ıa no funciona, habr´a que volver a retocar el c´odigo y repetir la fase. 6. Refactorizaci´on. Una vez que la prueba est´a funcionando se refactoriza el c´odigo, consistiendo esta fase la mayor parte de las veces en eliminar c´odigo duplicado. Esta fase es igual de importante que las fases anteriores ya que es la que permite obtener un c´odigo legible y f´acil de mantener. 7. Actualizar la lista de requisitos. Se tacha el requisito implementado de la lista y se a˜ naden los requisitos que surgieron durante esta iteraci´on.
34
4.2. Desarrollo guiado por pruebas (TDD)
Esta metodolog´ıa presenta muchas ventajas, realizar primero las pruebas requiere hacer un an´alisis en profundidad previo de los requisitos y de los diversos escenarios. Adem´as, si se implementa el software y luego se realizan las pruebas, estas suelen estar condicionadas por lo implementado. Por otra parte, siguiendo esta metodolog´ıa el c´odigo creado ser´a siempre m´ınimo y se evitar´a la redundancia. Otra ventaja del desarrollo conducido por pruebas son los peque˜ nos pasos con los que se construye el software, esta pr´actica aumenta considerablemente la productividad. Comparando con una codificaci´on cl´asica donde, por ejemplo, se avanza a trav´es de la implementaci´on de nuevas funcionalidades hay una gran probabilidad de que las pruebas de la funcionalidad fallen; sin embargo, usando esta metodolog´ıa es f´acil depurar el c´odigo y corregir los errores que se encontrar´an en la u ´ltima actualizaci´on del c´odigo [2].
4. Metodolog´ıa
Figura 4.1: Test Driven Development (TDD) [1]
35
36
4.2. Desarrollo guiado por pruebas (TDD)
Cap´ıtulo 5
Planificaci´ on y seguimiento
n este cap´ıtulo se trata la planificaci´on temporal del proyecto realizada en las primeras fases de este, en funci´on de las iteraciones impuestas por la tecnolog´ıa usada descrita en el apartado anterior. Tambi´en aborda todo lo relacionado con el seguimiento del proyecto, haciendo una comparativa entre la planificaci´on inicial y el resultado real final.
E
5.1.
Planificaci´ on
El primer paso de la planificaci´on es esclarecer las tareas a realizar y establecer la disponibilidad de los recursos que realizar´an estas tareas. Al tratarse de un proyecto de fin de grado, los recursos se limitan a una u ´nica persona que har´a las veces de analista-programador desarrollando todas las fases del proyecto. En un primer momento, se asign´o un calendario de media jornada (5 horas diarias) de dedicaci´on al proyecto hasta el 16 de Abril, fecha en la que finaliza el contrato de pr´acticas en empresa que ocupa las ma˜ nanas del recurso; a partir de ese momento se aplicar´ıa un calendario de jornada completa (9 horas diarias). As´ı, la planificaci´on inicial del proyecto contempla su realizaci´on en un per´ıodo de cinco meses comenzando el 19 de Enero de 2015 y finalizando el 1 de Junio del mismo a˜ no. Quedando el desarrollo dividido en cinco fases gen´ericas, representadas en forma de hamacas en la siguiente figura. Fase inicial Durante esta fase se llevar´an a cabo las tareas preliminares del proyecto que no devuelven ning´ un resultado tangible pero que son imprescindibles para establecer una buena base. 37
38
5.1. Planificaci´ on
Fase de planificaci´ on Se crean los diagramas incluidos en este cap´ıtulo y se establece una aproximaci´on lo m´as realista posible sobre la evoluci´on del desarrollo del proyecto en funci´on del tiempo, esfuerzo y coste. Fase de elaboraci´ on Se establecen las tecnolog´ıas a usar y la arquitectura de alto nivel del sistema. Fase de desarrollo Durante esta fase se desarrollan cada uno de los componentes siguiendo la metolog´ıa TDD anteriormente descrita. Al seguir esta metodolog´ıa ´agil el desarrollo de cada componente se divide en peque˜ nas iteraciones, cada una de ellas con su propias fases de an´asisis, dise˜ no, desarrollo y pruebas. Por u ´ltimo, se integran todos los componentes creados conformando el sistema final. Fase final Se analiza el sistema construido en busca de posibles mejoras y optimizaciones y se presenta el producto final al director del proyecto para su aprobaci´on.
Figura 5.1: Diagrama de Gantt: Hamacas
5. Planificaci´ on y seguimiento
Figura 5.2: Tareas
39
40
5.1. Planificaci´ on
Figura 5.3: Diagrama de Gantt: Tareas (parte 1)
5. Planificaci´ on y seguimiento
41
Figura 5.4: Diagrama de Gantt: Tareas (parte 2)
Nota: Las iteraciones relativas a la construcci´on f´ısica de pr´otesis solo se pueden realizar las tardes de los Viernes porque es el horario de acceso a la impresora 3D que le han impuesto al recurso.
42
5.2. Seguimiento
5.2.
Seguimiento
Una vez obtenida la planificaci´on inicial, se establece la l´ınea base, la referencia para comparar los avances reales con lo planificado. Estas comparaciones reciben el nombre de seguimiento y se acostumbra a realizar al menos cuatro durante el desarrollo de un proyecto, normalmente en cada cuarto de la realizaci´on estimada del proyecto. Seguimiento al 25 por ciento: Realizada el 20 de Febrero, todav´ıa no se hab´ıa terminado la fase inicial, continuando el estudio de los requisitos como estaba previsto. Seguimiento al 50 por ciento: Llevada a cabo el 19 de Marzo, las fases de planificaci´on y elaboraci´on se han acabado en el plazo estimado. Se han terminado las iteraciones relativas al servidor y el componente alcanz´o el estado finalizado y operativo. Las iteraciones del software local est´an en pleno desarrollo sin presentar retrasos. Aunque la renovaci´on del contrato de trabajo que impon´ıa el horario a media jornada hace necesario modificar la planificaci´on inicial para aplicar este horario a todo el per´ıodo de desarrollo. Seguimiento al 75 por ciento: El seguimiento del 27 de Abril muestra tres problemas graves que retrasan todo el proyecto: • El proceso de impresi´on resulta ser mucho m´as complicado de lo que los estudios preliminares hab´ıan supuesto. La impresora necesita asistencia total para poder acabar una pieza sin incidentes, especialmente las piezas el´asticas, que atascan la impresora y es necesario desmontar el cabezal de impresi´on cada vez que surje un incidente. • Se retrasa la llegada de los dispositos hardware y materiales de apoyo (cables, conexiones, protoboard...) lo que hace imposible empezar con las iteraciones del software de control hasta conseguir construir el circuito. • El funcionamiento de la conexi´on bluetooth entre el software de control y el software local se retrasa m´as de lo esperado y cuando se consigue establecer funciona de forma err´atica. Ser´a necesario invertir m´as horas de las esperadas en esta incidencia.
5. Planificaci´ on y seguimiento
43
Debido a esto se ha centrado el alcance del proyecto en el desarrollo de todas las iteraciones de los componentes necesarios para el funcionamiento del sistema de informaci´on, dejando para el final el componente cliente web ya que no solo no es necesario para el funcionamiento completo del resto de componentes sino que adem´as es el componente m´as sencillo de integrar. Seguimiento al 100 por ciento: El d´ıa establecido como finalizaci´on del proyecto (1 de Junio) se revisan los logros conseguidos en comparaci´on a la l´ınea base inicial. Las incidencias antes mencionadas, especialmente la impresi´on y el horario a media jornada, quiebran la planificaci´on inicial traduci´endose en una replanificaci´on de todas las tareas pendientes y una reducci´on del alcance del proyecto. Las iteraciones del desarrollos correspondientes al u ´ltimo cuarto del per´ıodo se replanifican apoy´andose en horas extra y horario nocturno. En el u ´ltimo per´ıodo, se hace obvio que la linea base inicial era demasiado ambiciosa y no ser´a posible conseguir desarrollar todas las iteraciones del u ´ltimo componente. Como el tiempo es un factor de vital importancia, se realizan las primeras iteraciones hasta la fecha de finalizaci´on del proyecto combin´andolo con la tarea de optimizaciones, de forma que se obtenga un prototipo de este componente que poder integrar con el resto del sistema para la aprobaci´on del director del proyecto.
44
5.2. Seguimiento
Cap´ıtulo 6
Evaluaci´ on de costes
Al ser un proyecto basado en el software y hardware libre, el coste del desarrollo est´a asociado principalmente a las horas de trabajo. En primer lugar no existen licencias que conseguir para la utilizaci´on de ning´ un software usado en el este sistema, adem´as los componentes de hardware libre tienen costes del todo asequibles. La suma total a la que asciende el precio de los integrantes del circuito electr´onico no supera los 150 euros. S´ı es cierto que los filamentos de impresi´on, al ser una tecnolog´ıa novedosa, no son demasiado econ´omicos: 1kg de filamento PLA cuesta 40 euros y para adquirir 250 gramos del filamento flexible para las juntas de la pr´otesis es necesario desembolsar 20 euros m´as. Para la creaci´on de este proyecto se utilizar´a un equipo propio del autor, igual que los dispositivos m´oviles con los que se contrastar´a el sistema por lo que no suponen gasto alguno. Respecto a los recursos usados, suponiendo que el analista-programador cobra 25 euros la hora, sumando todas las horas de trabajo normal (aproximadamente 500 h) es igual a un total de 12500 euros aproximadamente. Teniendo en cuenta los materiales usados, los dispositivos hardware del circuito y el sueldo del analista-programador, el coste total del proyecto asciende hasta la cantidad de 12710 euros.
45
46
Cap´ıtulo 7
Arquitectura
a arquitectura software es un planteamiento a muy alto nivel de los componentes del sistema y las interacciones entre ellos pensado en funci´on de unos requerimientos y restricciones, impuestos por la funcionalidad que debe alcanzar el sistema de informaci´on y por las limitaciones que imponen las tecnolog´ıas usadas. En este cap´ıtulo se explica la estructura general de este proyecto, una aproximaci´on a m´as bajo nivel con los detalles de la arquitectura de cada componente son tratados en el pr´oximo cap´ıtulo.
L
7.1.
Definici´ on arquitect´ onica
Se trata de un proyecto claramente distribuido, por lo que es necesario dividir la funcionalidad final en distintos componentes que conformen un sistema. Se pueden distinguir cinco grandes bloques en este desarrollo: 1. Pr´otesis: Figura de pl´astico especial con la forma de una mano humana. A pesar de no ser un componente inform´atico, es la parte fundamental del sistema y el objetivo final del proyecto Exandounamano. Su funci´on es la reproducci´on de los movimientos musculares del usuario f´ısicamente. 2. Software de control: Plataforma encargada de los movimientos de la pr´otesis y de la transmisi´on de los datos al software local. Uno de los cometidos de este componente es la gesti´on de los impulsos el´ectricos musculares del usuario, debe interpretar estas se˜ nales traduci´endolos a movimientos concretos
47
48
7.1. Definici´ on arquitect´ onica
que reproducir´a manipulando la pr´otesis pl´astica. Adem´as, deber´a transmitir estas se˜ nales interpretadas junto con los problemas ocurridos durante la ejecuci´on al software local para su posterior almacenamiento persistente en el servidor. 3. Software local: Su funcionalidad b´asica es recoger los datos enviados por la pr´otesis (a trav´es del software de control ) y enviarlos al servidor. Esta pieza es fundamental para el sistema de informaci´on ya que es la encargada de establecer comunicaci´on entre la parte f´ısica y la parte software del sistema, permitiendo salvaguardar la informaci´on en caso de fallo de alguna de las partes. Tambi´en permite la consulta de cierta informaci´on relevante como el estado de una pr´otesis concreta. 4. Servidor: Recibe la informaci´on y la almacena a largo plazo en la base de datos permitiendo su consulta, encarg´andose de la gesti´on de persistencia de todos los datos del sistema de informaci´on. Este servidor ofrecer´a acceso a diferentes servicios que podr´an consultar y manipular la informaci´on. 5. Cliente web: Interfaz de usuario que permite realizar peticiones sobre el servidor para consultar la informaci´on y modificarla. Su u ´nica misi´on en este proyecto es permitir la interacci´on con el servidor por parte de los usuarios y administradores en vista a ampliar este servicio en el futuro, pudiendo darse casos como la incorporaci´on de esta herramienta al trabajo diario de los m´edicos para ver la informaci´on y el avance de cada paciente.
Figura 7.1: Diagrama de componentes
7. Arquitectura
7.2. 7.2.1.
49
Patrones arquitect´ onicos Capas
Estructuraci´on de la aplicaci´on en diversas capas, agrupando en cada capa funcionalidad relacionada. Las capas se aplican verticalmente entre los usuarios y los datos, permitiendo la comunicaci´on entre capas solo a trav´es de interfaces bien definidos para minimizar el acoplamiento. Los componentes de una capa solo pueden interactuar entre s´ı o con los de la capa inferior. 7.2.1.1.
Cliente-Servidor
Tambi´en conocido como arquitectura en dos capas. Distribuye la funcionalidad del programa entre los proveedores de recursos (servidores) y los demandantes (clientes). El cliente se comunica con el servidor a trav´es de un sistema de peticiones (generalmente siguiendo el protocolo HTTP). Se puede apreciar claramente este patr´on en las interacciones entre el servidor y el cliente web o el servidor y el software local. 7.2.1.2.
Modelo-Vista-Controlador (MVC)
Caso concreto de la arquitectura en capas que solo utiliza tres capas utilizado en el desarrollo del software local. La idea principal de este patr´on es separar la representaci´on de la informaci´on de la l´ogica de negocio. Para este fin presenta tres componentes distintos:
1. Modelo: Elemento responsable de la gesti´on de la informaci´on del programa, encarg´andose de su persistencia, actualizaciones, privilegios de accesos, etc. Env´ıa a la vista aquella parte de la informaci´on que en cada momento se le solicita para que sea mostrada. Las peticiones de actualizaci´on de la informaci´on las recibe el modelo a trav´es del controlador.
50
7.2. Patrones arquitect´ onicos
2. Controlador: El intermediario entra la vista y el modelo. Responde a eventos (en la mayor´ıa de ocasiones acciones del usuario) e invoca al modelo cuando se hace alguna solicitud sobre la informaci´on, tambi´en puede hacer peticiones de cambio a la vista para adaptarse a la informaci´on del modelo. 3. Vista: Su u ´nica funci´on es presentar la informaci´on del modelo de una forma adecuada para el usuario. En aplicaciones web es com´ un encontrar HTML definido este elemento (aunque existen otras alternativas).
7.2.2.
REST
Arquitectura software para sistemas distribuidos que especializa la arquitectura cliente-sevidor, basado en la publicaci´on de recursos que pueden ser accedidos por un conjunto de clientes en base a su identificador u ´nico. Esta sintaxis universal para alcanzar recursos se denomina URI, algo con lo que el mundo est´a familiarizado gracias a internet (un ejemplo de URI es https://www.twitter.com/fic) Para realizar este acceso a los recursos, los clientes env´ıan peticiones al servidor y este les devuelve una representaci´on del objeto en cuesti´on. Pero esta petici´on debe contener toda la informaci´on necesaria para que se pueda efectuar la transacci´on porque REST es una arquitectura sin estado, es decir, no se almacena en el servidor ninguna clase de informaci´on relacionada con la petici´on o los clientes. Se deben definir igualmente un conjunto de operaciones b´asicas que se apliquen a todos los recursos disponibles (habitualmente GET, PUT, POST y DELETE). En la actualidad, se utiliza el t´ermino REST para designar cualquier interfaz web que emplea XML o HTTP.
7. Arquitectura
7.2.3.
51
Componentes
Este patr´on descompone el sistema en componentes funcionales comunicados a trav´es de interfaces bien definidos. Es un planteamiento que busca la extensibilidad y el encapsulamiento para fomentar la reemplazabilidad y la reusabilidad. Este proyecto es un ejemplo claro de estas cualidades, se ha distribuido la funcionalidad total del sistema entre los distintos componentes antes mencionados para que el producto pueda evolucionar con las tecnolog´ıas y la investigaci´on. As´ı, por ejemplo, si en alg´ un momento se decide cambiar la tecnolog´ıa de la pr´otesis por decisi´on de los especialistas a otra que se adapte mejor a las necesidades del proyecto la u ´nica preocupaci´on para la integraci´on con el resto de componentes ser´ıa el canal de transmisi´on de datos al software local.
7.2.4.
FLUX
El objetivo principal de la arquitectura FLUX es alcanzar un flujo de datos unidireccional que simplifique el paradigma tradicional de renderizaci´on de vistas (com´ unmente implementado a trav´es de un esquema MVC). Las aplicaciones con estructura FLUX constan de tres partes principales: el despachador, los almacenes y las vistas. Las vistas se encuentran en lo alto de la jerarqu´ıa, recogiendo la informaci´on para los almacenes y enviando la informaci´on hacia sus hijos. Cuando un usuario interact´ ua con una vista de REACT, la vista propaga la acci´on a trav´es de los despachadores a los almacenes donde se encuentran los datos de la aplicaci´on y la l´ogica de negocio, que hace que se actualicen todas las vistas afectadas. El despachador es el foco central que gestiona todo el flujo de datos de una aplicaci´on FLUX. Esencialmente es un registro de callbacks a los almacenes y no tiene inteligencia propia (solo es un mecanismo que distribuye las acciones entre los almacenes).Los almacenes contienen el estado y la l´ogica de la aplicaci´on. Como ya se ha explicado, un almac´en se registra en el despachador y este lo invoca a trav´es de callbacks. Estos callbacks tienen la acci´on como par´ametro, en funci´on del tipo de acci´on se invocan los m´etodos internos adecuados del almac´en. Una vez que el almac´en ha sido actualizado, se env´ıa un evento broadcast para comunicar el cambio de estado, es entonces cuando las vistas consultan el nuevo
52
7.2. Patrones arquitect´ onicos
estado y se actualizan. Al tipo de vista que se encarga de recoger el broadcast de los almacenes se le denomina vista-controlador, una vez que reciben el mensaje consultan las actualizaciones del almac´en y propagan los cambios a todos los elementos descendientes. Se ha empleado esta arquitectura en el cliente web para adaptar el sistema a las nuevas tecnolog´ıas ya que todo parece indicar que en un futuro no muy lejano habr´a un gran acercamiento a este tipo de arquitectura en detrimento de las arquitectura comunes como el MVC. En la realidad, es complicado encontrar uno de estos patrones ejemplificado estrictamente seg´ un la teor´ıa, lo com´ un es encontrar distintas versiones de distintos patrones arquitect´onicos coexistiendo en una aplicaci´on. Este proyecto sigue esta tendencia implementando todos los patrones antes expuestos. Como ya se ha visto, para el dise˜ no de la arquitectura a alto nivel se ha empleado un desarrollo en componentes que busca la reemplazabilidad para adaptarse al car´acter de investigaci´on que requiere el producto final. Este dise˜ no por componentes se combina con los patrones arquitect´onicos usados en cada uno de esos mismos componentes, permitiendo que cada uno de distribuya de la forma m´as eficiente para el desarrollo de su funcionalidad.
Cap´ıtulo 8
Dise˜ no del sistema
e entiende por dise˜ no la definici´on de un dispositivo, sistema o proceso con los suficientes detalles como para permitir su realizaci´on f´ısica. Eso es precisamente lo que se trata en este cap´ıtulo, se expone la visi´on del proyecto un paso m´as all´a de lo tratado en el cap´ıtulo de arquitectura, se describe el dise˜ no de sistema a nivel de componente incluyendo patrones, especificaci´on de pruebas y tecnolog´ıas usadas.
S
8.1.
Dise˜ no de cada componente
Debido al car´acter experimental del trabajo todo el dise˜ no es solo un prototipo que se ir´a adaptando en funci´on de las distintas necesidades que requiera el proyecto en el futuro. Como se expuso en cap´ıtulos anteriores, se ha seguido una metodolog´ıa conducida por las pruebas por lo que en este cap´ıtulo tambi´en se tratar´an la especificaci´on de cada test que se han esbozado para cada componente conformando el resultado final del dise˜ no. Dada la orientaci´on del proyecto, se podr´ıa aplicar un modelo de integraci´on continua, que consiste en compilar el c´odigo y ejecutar las pruebas de forma autom´atica y peri´odica (lo m´as a menudo posible) para detectar fallos cuanto antes. Existen herramientas de c´odigo libre como BuildBot que permiten lograr esto de manera muy simple.
53
54
8.1.1.
8.1. Dise˜ no de cada componente
Pr´ otesis
El objetivo u ´ltimo del proyecto Exandounamano es obtener como producto final una pr´otesis a tama˜ no real capaz de realizar las funciones de una mano humana natural. El dise˜ no de esta pr´otesis se ha basado en los nuevos materiales revolucionarios para impresi´on en tres dimensiones, que permiten crear este componente de manera bastante sencilla en aproximadamente una semana. Cabe destacar la simulaci´on de ligamentos en la mano artificial a trav´es de un material llamado filaFlex que conserva su elasticidad una vez enfriado, sin ´el ser´ıa imposible el movimiento de las articulaciones. 8.1.1.1.
Tecnolog´ıas de apoyo
LulzBot TAZ 4 3D Printer Impresora en tres dimensiones de alto rendimiento con fines industriales. Consta de una cama, un cabezal (a trav´es del cual pasan los filamentos pl´asticos) y una estructura met´alica que los soporta. El funcionamiento es simple: antes de la impresi´on se calientan la cama y el cabezal lo suficiente para poder moldear el filamento, una vez alcanzada la temperatura adecuada el cabezal reproduce la figura a recrear usando el filamento como pintura y la cama como lienzo. Es un proceso lento y con alta probabilidad de fallo ya que el material a esas temperaturas es inestable y el grosor de las capas es ´ınfimo, una sola mota de material colocada en lugar incorrecto puede suponer que la pieza salga defectuosa y haya que volver a empezar la impresi´on desde el principio.
Slic3r Software libre que permite modelar y organizar las piezas a imprimir en una impresora 3D. Su caracter´ıstica fundamental es que permite transformar una (o varias) piezas concreta en el conglomerado de capas que la representan.
8. Dise˜ no del sistema
8.1.2.
55
Software de control: Arduino
Para la implantaci´on de las funciones del software de control esbozado en el planteamiento de la arquitectura del sistema se ha elegido un microcontrolador Arduino que, trabajando en colaboraci´on con otros m´odulos electr´onicos, es capaz de realizar estas tareas. Entre otras tecnolog´ıas, se ha optado por usar Arduino debido a su condici´on de hardware libre y la gran comunidad de apoyo que existe en torno a este dispositivo que abarata los costes del proyecto siguiendo su filosof´ıa y pone a disposici´on de los desarrolladores grandes vol´ umenes de documentaci´on que agilizan el avance. Arduino Uno [6] es un microcontrolador con catorce puertos de entrada/salida, seis entradas anal´ogicas, una conexi´on USB y un bot´on de Reset entre otros componentes. Utiliza su propio lenguaje de programaci´on para su configuraci´on, requiriendo importar un archivo .ino con el c´odigo de funcionamiento a trav´es de la conexi´on USB. Se puede descargar el entorno de desarrollo para Arduino de forma sencilla y totalmente gratuita. Su bajo coste, su alta eficiencia y gran fiabilidad convierten a este microcontrolador en el hardware perfecto para proyectos de este tipo. El primer cometido que debe ser capaz de realizar este componente es la gesti´on de los impulsos el´ectricos generados por el m´ usculo del usuario o administrador que se encuentre usando la pr´otesis en un momento determinado. Esta tarea se realiza mediante la conexi´on de los tendones del brazo del sujeto a un sensor muscular que a su vez estar´a conectado con el microcontrolador. De esta forma se consigue la traducci´on de los impulsos musculares en se˜ nales el´ectricas procesables por el Arduino. Una vez que se ha completado este paso, el dispositivo debe conseguir que la pr´otesis pl´astica reproduzca el movimiento vali´endose de un servo (un peque˜ no dispositivo cuyo componente m´as destacable es un motor de corriente continua, de forma que es capaz de transformar energ´ıa el´ectrica en energ´ıa mec´anica) y un mecanismo de uni´on entre el servo y la pr´otesis. Este mecanismo de uni´on ser´a alguna clase de filamento o hilo (preferiblemente con una elasticidad m´ınima para evitar la p´erdida de la energ´ıa mec´anica) que se conecta con cada una de las extremidades de la pr´otesis y con las aspas conectadas al motor.
56
8.1. Dise˜ no de cada componente
As´ı, el microcontrolador manda los movimientos a realizar a trav´es de las se˜ nales recibidas del sensor muscular que hace rotar las aspas tensando los filamentos y haciendo que la pr´otesis se mueva. Por u ´ltimo, el software de control debe enviar la informaci´on obtenida en los procesos anteriores al software local. Ya que, por definici´on, el software local siempre estar´a a una distancia peque˜ na de la pr´otesis donde ir´a integrada el software de control, la comunicaci´on se har´a a trav´es de bluetooth. Para esta tarea el microcontrolador se apoyar´a en una tarjeta blueetooth, como esta informaci´on ya se encuentra f´ısicamente en el Arduino del proceso anterior solo ser´a necesario referenciarla a la salida de la tarjeta. En vista a futuros problemas que puedan suceder, se desarrollar´a un sistema de almacenamiento temporal donde se guardar´an los datos antes de ser enviados, de forma que si sucede cualquier imprevisto los datos no se pierdan y puedan reenviarse cuando se estime oportuno. Curiosamente, observando el dise˜ no final del componente se puede observar como tambi´en emplea una arquitectura basada en componentes para su funcionamiento, en concreto se pueden distinguir tres componentes: un componente encargado de los est´ımulos musculares, un componente encargado del movimiento de la pr´otesis y componente encargado de la transmisi´on de informaci´on. Para mejorar la eficiencia del producto final, se podr´ıan incluir distintas aproximaciones a las posiciones m´as comunes de una mano real. As´ı, usando el patr´on estrategia, el dispositivo tendr´ıa que elegir en funci´on de la colocaci´on de los dedos de la pr´otesis a qu´e posici´on se est´a intentando llegar y corregir la postura de la mano artificial mejorando la experiencia del usuario.
8. Dise˜ no del sistema
8.1.2.1.
57
Pruebas que configuraron el dise˜ no
Simular movimiento de la pr´ otesis PA-001
C´ odigo
Componentes usados
Arduino y servo
Descripci´ on
El microcontrolador conseguir´a realizar un movimiento concreto con la mano artificial.
Resultado esperado
La pr´otesis simula el movimiento deseado.
Cuadro 8.1: Prueba ‘Simular movimiento de la pr´otesis’
Detectar est´ımulo muscular PA-002
C´ odigo
Componentes usados
Arduino y sensor muscular
Descripci´ on
Almacenamiento en el microprocesador de la informaci´on proporcionada por el sensor muscular. Conectar el sensor a Arduino y a un brazo humano, posteriormente tensar los m´ usculos del brazo.
Resultado esperado
El sensor transforma los est´ımulos musculares en se˜ nales interpretables por Arduino y llegan al microcontrolador.
Cuadro 8.2: Prueba ‘Detectar est´ımulo muscular’
58
8.1. Dise˜ no de cada componente
Transmitir por bluetooth PA-003
C´ odigo
Componentes usados
Arduino, tarjeta bluetooth y programa de prueba para la recepci´on de datos.
Descripci´ on
Enviar informaci´on desde el microcontrolador a trav´es de bluetooth que recoger´a un programa de prueba creado espec´ıficamente con este prop´osito.
Resultado esperado
Los datos insertados en Arduino llegan al programa de prueba a trav´es de la conexi´on Bluetooth.
Cuadro 8.3: Prueba ‘Transmitir por bluetooth’
8.1.2.2.
Tecnolog´ıas de apoyo
Sensor muscular RB Dispositivo capaz de transformas los impulsos musculares en se˜ nales el´ectricas reconocibles por el microcontrolador.
Arduino Bluetooth BLUEFRUIT LE Low Energy nRF8001 Dispositivo capaz de transmitir datos desde el microprocesador Arduino por bluetooth.
Placa de pruebas Tablero con orificios conectados el´ectricamente entre s´ı sobre el que se pueden insertar componentes electr´onicos y cables para la construcci´on de circuitos electr´onicos y otros sistemas
8. Dise˜ no del sistema
8.1.3.
59
Software local: App para dispositivos m´ oviles
En la sociedad sobreinformatizada en la que vivimos todas las personas tienen acceso a la informaci´on de una forma u otra, destaca especialmente el uso de los tel´efonos inteligentes que se duplica a˜ no tras a˜ no. Partiendo de esta premisa se puede deducir que todo usuario final al que llegue el producto ser´a propietario de un dispositivo m´ovil con acceso a internet. As´ı, se ha elegido este medio para dar soporte al software local del sistema. Usar los propios dispositivos m´oviles de los usuarios no solo abarata los costes del producto final, sino que adem´as mejora la experiencia del usuario, pudiendo tener acceso en tiempo real a informaci´on de su pr´otesis en su propio tel´efono con el que ya est´a familiarizado, reduciendo la curva de aprendizaje al m´ınimo. La idea para la que fue dise˜ nada la aplicaci´on m´ovil es sencilla: conectar la pr´otesis con el servidor. Bas´andose en el patr´on proxy, seg´ un el cual, se proporciona un intermediario de un objeto para gestionar su acceso. En este caso concreto, el software local aqu´ı usado har´ıa las veces de proxy remoto, el componente del modelo te´orico encargado de codificar peticiones y argumentos y enviarla al objeto remoto. Realmente, la meta del middleware es conectar componentes del sistema, en la mayor parte de los casos el usuario final no es consciente de su existencia; pero, nuevamente al usar el tel´efono del usuario se pueden incluir diversas funcionalidades de su inter´es. De esta forma, el usuario puede acceder al hist´orico de incidencias, al estado actual de la pr´otesis o algo tan simple e importante como consultar la bater´ıa que le queda a la pr´otesis. Esta aplicaci´on permitir´ıa incluso en el futuro poder ver las constantes vitales del usuario que est´a usando la pr´otesis en tiempo real (por el momento del todo imposible debido a los sensores usados para recoger los impulsos el´ectricos de los m´ usculos). Respecto al funcionamiento interno, la aplicaci´on m´ovil seguir´a una estructura MVC (explicada en el cap´ıtulo anterior) implementada sobre la nueva tecnolog´ıa: Cordova [7]. Esta nueva aproximaci´on para la programaci´on en dispositivos m´oviles se basa en la programaci´on de aplicaciones en JavaScript, HTML y CSS esquivando el c´odigo nativo de cada plataforma m´ovil con el objetivo de crear aplicaciones multiplataforma.
60
8.1. Dise˜ no de cada componente
Esta no es la u ´nica ventaja que presenta, debido su alto n´ umero de adeptos y su car´acter libre tiene un gran refuerzo en forma de plugins en constante actualizaci´on. De hecho, en este proyecto se ha usado un plugin de la comunidad para poder gestionar el bluetooth del dispositivo desde la propia aplicaci´on (un plugin con carencias ya que solo funciona correctamente bajo plataformas Android o iOS). Usando este plugin la aplicaci´on es capaz de interactuar con el Arduino y recoger los datos transmitidos. Esto se implementa usando un patr´on observador en el que el observado ser´ıa el buffer de llegada de datos desde el microcontrolador y el observador ser´ıa el controlador de la aplicaci´on. El plugin en s´ı podr´ıa ser considerado como un software que implementa el patr´on adaptador, ya que ese es el rol que realiza en este sistema. Una vez que los datos est´an en el dispositivo m´ovil ser´an enviados al servidor mediante una petici´on HTTP. Como esta transmisi´on de datos requiere una conexi´on a internet constante es recomendable realizarla bajo el amparo de una conexi´on wifi activa en el dispositivo m´ovil. Para prevenir posibles incidencias relacionadas con la imposibilidad de transmisi´on por la conexi´on a internet la aplicaci´on es capaz de detectar si existe una conexi´on activa y, en caso de no existir, guardar la informaci´on a transmitir en un buffer en la memoria del tel´efono que recuperar´a cuando se encuentre una conexi´on, dotando as´ı a esta comunicaci´on de un m´etodo de tolerancia a fallos. Una primera aproximaci´on a la forma que tomar´ıa la vista de la aplicaci´on se puede observar en la figura siguiente. Como se pude intuir en la imagen, la interacci´on con el usuario o administrador se resume en dos acciones: forzar env´ıo de datos y marcar evento. La primera acci´on parece autoexplicativa, una vez que este bot´on de la vista se pulse el controlador obligar´a al modelo a intentar enviar los datos al servidor, u ´til para casos en los que la exista una conexi´on que no sea wifi potente o para casos de prueba, es conveniente recordar que este es un proyecto de investigaci´on en sus primera fases y este desarrollo se ha orientado al avance en este campo y no como un producto final listo para entregar a los usuarios finales.
8. Dise˜ no del sistema
61
Figura 8.1: Vista de la app m´ovil De este car´acter experimental del proyecto se deduce tambi´en el segundo bot´on, que ser´a empleado por los administradores durante las pruebas para asociar el evento concreto que reprodujo o deber´ıa haber reproducido la pr´otesis a la informaci´on que llega del microcontrolador para poder cotejar resultados una vez almacenados en la base de datos. Al pulsar el bot´on, se abre un desplegable enumerando todos los eventos disponibles y al pulsar sobre un elemento de la lista se guarda ese evento. 8.1.3.1.
Pruebas que configuraron el dise˜ no
Todas las pruebas a continuaci´on descritas deber´an realizarse para cada plataforma m´ovil en la que se desee utilizar la aplicaci´on, para las pruebas de este proyecto se han utilizado las plataformas Android e iOS.
62
8.1. Dise˜ no de cada componente
Comunicaci´ on con un servidor PM-001
C´ odigo
Componentes usados
Servidor y aplicaci´on m´ovil.
Descripci´ on
Realizar una consulta desde el m´ovil al servidor.
Resultado esperado
La aplicaci´on recibe una respuesta correcta desde el servidor .
Cuadro 8.4: Prueba ‘Comunicaci´on con un servidor’
C´ odigo
Comunicaci´ on peri´ odica con un servidor PM-002
Componentes usados
Servidor y aplicaci´on m´ovil.
Descripci´ on
Programar el env´ıo de consultas de forma autom´atica desde el m´ovil al servidor.
Resultado esperado
La aplicaci´on recibe una respuesta correcta a cada una de las peticiones desde el servidor .
Cuadro 8.5: Prueba ‘Comunicaci´on peri´odica con un servidor’
Recibir datos por bluetooth PM-003
C´ odigo
Componentes usados
Arduino y aplicaci´on m´ovil.
Descripci´ on
Transmitir datos de prueba desde el microcontrolador al dispositivo m´ovil via bluetooth.
Resultado esperado
La aplicaci´on recibe e interpreta correctamente los datos enviados desde Arduino.
Cuadro 8.6: Prueba ‘Recibir datos por bluetooth’
8. Dise˜ no del sistema
C´ odigo
63
Almacenar datos de forma persistente PM-004
Componentes usados
Aplicaci´on m´ovil.
Descripci´ on
Guardar datos de prueba de forma persistente en la memoria del dispositivo. Reiniciar la aplicaci´on y leer los datos guardados.
Resultado esperado
La aplicaci´on guardar´a correctamente los datos y ser´a capaz de recuperarlos e interpretarlos.
Cuadro 8.7: Prueba ‘Almacenar datos de forma persistente’
Comprobar conectividad PM-005
C´ odigo
Componentes usados
Aplicaci´on m´ovil.
Descripci´ on
Configurar la aplicaci´on para que se˜ nale si el dispositivo est´a conectado a una red wifi. Desconectar el dispositivo de la red y volver a conectarlo.
Resultado esperado
La aplicaci´on identificar´a cuando est´a conectado el tel´efono a la red wifi.
Cuadro 8.8: Prueba ‘Comprobar conectividad’
64
8.1. Dise˜ no de cada componente
Marcar evento PM-006
C´ odigo Componentes usados
Arduino y aplicaci´on m´ovil.
Descripci´ on
Seleccionar un evento en la aplicaci´on m´ovil y comprobar que se asocia a los datos recibidos por bluetooth.
Resultado esperado
La aplicaci´on asociar´a correctamente los datos.
Cuadro 8.9: Prueba ‘Marcar evento’
C´ odigo
Forzar env´ıo PM-007
Componentes usados
Aplicaci´on m´ovil.
Descripci´ on
Al pulsar el bot´on de ’Forzar env´ıo’ la aplicaci´on intentar´a mandar la informaci´on sin importar la conectividad.
Resultado esperado
La aplicaci´on intentar´a enviar la informaci´on y, en caso de que exista conectividad, la enviar´a con ´exito.
Cuadro 8.10: Prueba ‘Forzar env´ıo’
8. Dise˜ no del sistema
65
Autenticar usuario insatisfactoriamente (Software local) C´ odigo PM-008 Componentes usados
Aplicaci´on m´ovil y servidor.
Descripci´ on
Al iniciar la aplicaci´on m´ovil se presentar´a por pantalla un formulario donde se insertar´a un nombre de usuario y una contrase˜ na inv´alidos para este sistema. Despu´es, se pulsar´a el bot´on de env´ıo.
Resultado esperado
Al presionar el bot´on se cotejar´a la informaci´on con los datos almacenados y, al no obtener una coincidencia, la aplicaci´on mostrar´a un mensaje de error.
Cuadro 8.11: Prueba ‘Autenticar usuario insatisfactoriamente (Software local)’
Autenticar usuario satisfactoriamente (Software local) C´ odigo PM-009 Componentes usados
Aplicaci´on m´ovil y servidor.
Descripci´ on
Al iniciar la aplicaci´on m´ovil se presentar´a por pantalla un formulario donde se insertar´a un nombre de usuario y una contrase˜ na v´alidos en el sistema. Despu´es, se pulsar´a el bot´on de env´ıo.
Resultado esperado
Al presionar el bot´on se cotejar´a la informaci´on con los datos almacenados y, al obtener una coincidencia, la aplicaci´on mostrar´a la vista principal de la aplicaci´on.
Cuadro 8.12: Prueba ‘Autenticar usuario satisfactoriamente (Software local)’
66
8.1.3.2.
8.1. Dise˜ no de cada componente
Tecnolog´ıas de apoyo
JavaScript Lenguaje de programaci´on interpretado orientado a objetos, d´ebilmente tipado y din´amico. Todos los navegadores modernos interpretan el c´odigo JavaScript integrado en las p´aginas web. Para interactuar con una p´agina web se provee al lenguaje JavaScript de una implementaci´on del Document Objetct Model (DOM). Tradicionalmente se ven´ıa usando en p´aginas web HTML para realizar operaciones y u ´nicamente en el marco de la aplicaci´on cliente por su simplicidad y rapidez a la hora de modificar el DOM, pero poco a poco se ha extendido llegando a usarse para construir directamente un servidor completo (como es el caso del desarrollo que se ha realizado).
HTML HyperText Markup Language (HTML) hace referencia al lenguaje de marcado para la elaboraci´on de p´aginas web. Es un est´andar que sirve de referencia para la elaboraci´on de p´aginas web en sus distintas versiones, define una estructura b´asica y un c´odigo para la definici´on de contenido de una p´agina web (im´agenes, v´ıdeos, etc). HTML se basa en la referenciaci´on,as´ı, una p´agina web contiene solo texto mientras que recae en el int´erprete del c´odigo (el navegador web) la tarea de unir todos los elementos y visualizar la p´agina final. HTML se escribe en forma de etiquetas contenidas entre corchetes angulares.
CSS Hoja de estilos en cascada (del ingl´es Cascading Style Sheets, CSS) es un lenguaje usado para definir y crear la presentaci´on de un documento estructurado escrito en HTML o XML. La idea que se encuentra detr´as del desarrollo de CSS es separar la estructura de un documento de su presentaci´on. La informaci´on de estilo puede ser definida en un documento separado o en el mismo documento HTML. En este u ´ltimo caso podr´ıan definirse estilos generales en la cabecera del documento o en cada etiqueta particular mediante el atributo style.
8. Dise˜ no del sistema
67
JQuery JQuery es una biblioteca de JavaScript que permite simplificar la manera de interactuar con los documentos HTML, manipular el ´arbol DOM, manejar eventos, generar animaciones y agregar interacci´on con la t´ecnica AJAX a p´aginas web. Su lema resume esta biblioteca a la perfecci´on: escribe menos, haz m´as. JQuery ofrece una serie de funcionalidades basadas en JavaScript que de otra manera requerir´ıan de mucho m´as c´odigo, esto es, con las nuevas funciones que aporta se consiguen grandes resultados en poco tiempo y espacio.
68
8.1.4.
8.1. Dise˜ no de cada componente
Servidor
La pieza fundamental de este sistema, como suele ocurrir en los sistemas inform´aticos, es el servidor. El componente central que se encarga de atender las peticiones de los dem´as componentes asegurando la persistencia de los datos y el flujo continuo de informaci´on. En concreto en este desarrollo, el servidor presenta una interfaz REST con la que los dem´as componentes interaccionan, dejando la puerta abierta para futuros componentes software que se podr´an integrar en el sistema mediante un cliente REST sencillo de dise˜ nar e implementar. Usando esta aproximaci´on, se puede observar como se hace uso del patr´on de software conocido como fachada, todas las peticiones llegan al mismo punto donde un controlador las enruta a su destino final. Para el desarrollo y ejecuci´on de este componente durante el proyecto se usar´a un u ´nico equipo personal que ser´a suficiente para satisfacer las peticiones de las pruebas pero, a medida que el proyecto evolucione, ser´a necesario migrar este componente a una estructura con mayor capacidad para poder hacer frente a la gran cantidad de peticiones que seguramente tendr´a que soportar en un futuro no muy lejano. Para la implementaci´on del servidor se utilizar´an las nuevas tecnolog´ıas emergentes basadas en javascript, tomando como base Node JS [8]. Node es un entorno de programaci´on en la capa del servidor basado en el lenguaje de programaci´on JavaScript, as´ıncrono, con entrada/salida de datos en una arquitectura orientada a eventos y basado en el motor V8 de Google. Su objetivo es crear programas de red altamente escalables (por ejemplo servidores web). Se basa en la agregaci´on de funcionalidad al programa final a trav´es de la participaci´on de diversos m´odulos con funcionalidades menores. El funcionamiento del servidor queda definido en la siguiente API: Agregar mano (nuevaMano): Almacena en el sistema la nueva mano pasada como un objeto en el par´ametro. Listar manos: Devuelve todas las manos guardadas en la base de datos. Recuperar mano (IdMano): Devuelve la informaci´on referente a una de las pr´otesis en funci´on de su identificador.
8. Dise˜ no del sistema
69
Actualizar mano (IdMano, nuevaMano): Actualiza la informaci´on almacenada en el sistema sobre una mano concreta asociada al identificador que se la pasa como par´ametro. Eliminar mano (idMano): Borra la informaci´on asociada al identificador del par´ametro. Agregar persona (nuevaPersona): Almacena en el sistema la informaci´on relativa a una nueva persona pasada a trav´es del par´ametro. Listar personas: Devuelve todas las personas almacenadas en el sistema. Recuperar persona (dniPersona): Devuelve la informaci´on referida a la persona concreta que se corresponde con el DNI pasado como par´ametro Recuperar persona (email): Devuelve la informaci´on referida a una persona concreta asociada al email pasado como par´ametro. Actualizar persona (dniPersona, nuevaPersona): Actualiza la informaci´on almacenada sobre una persona concreta asociada al dni que se le pasa como par´ametro. Eliminar persona (dniPersona): Elimina la informaci´on de una persona asociada al dni que se le pasa como par´ametro. Agregar sesi´ on (nuevaSesi´ on): Inserta en el sistema la informaci´on relativa a una nueva sesi´on pasada como par´ametro. Recuperar sesi´ on (idSesi´ on): Devuelve la informaci´on referida a una sesi´on concreta asociada con el identificador del par´ametro. Listar sesiones: Devuelve todas las sesiones almacenadas en el sistema. Agregar experimento (nuevoExperimento): Almacena en el sistema la informaci´on relativa a un nuevo experimento pasado como par´ametro. Recuperar experimento (idExperimento): Devuelve la informaci´on asociada a un experimento concreto identificado por el par´ametro. Recuperar experimentos asociados a una sesi´ on (idSesion): Devuelve todos los experimentos asociados a la sesi´on pasada como par´ametro.
70
8.1. Dise˜ no de cada componente
Y dado que se busca un alto rendimiento, una gran escalabilidad y se trabaja en un entorno javascript, el almacenamiento persistente se ha delegado en un sistema MongoDB [9]: un sistema de gesti´on de base de datos NoSQL orientado a documentos, desarrollado en c´odigo abierto. En lugar de guardar la informaci´on en tablas como las bases de datos relacionales, MongoDB guarda estructuras de datos en documentos tipo BSON (binarios derivados de documentos JSON). Los elementos de los datos se denominan documentos y se guardan en colecciones, pudiendo tener cada colecci´on un n´ umero indeterminado de documentos. Comparando con una base de datos relacional, se puede decir que las colecciones son como tablas y los documentos son registros en la tabla. Las principales caracter´ısticas de MongoDB son: Consultas Ad hoc: Soporta la b´ usqueda por campos, consultas de rangos y expresiones regulares. Replicaci´on: Soporta el tipo de replicaci´on maestro-esclavo. Pudiendo el maestro ejecutar comandos de lectura y escritura y el esclavo copiar los datos del maestro con el objetivo de crear copias de seguridad. El esclavo puede elegir otro maestro en caso de que se caiga el servicio del maestro actual. Indexaci´on: Cualquier campo de un documento puede ser indexado, adem´as de permitir la creaci´on de ´ındices secundarios. Balanceo de carga: Ofrece la posibilidad de ejecutarse en m´ ultiples servidores, balanceando la carga y/o duplicando los datos para poder mantener el sistema funcionando en caso de que exista un fallo de hardware. Los datos a guardar en esa base de datos son los relativos a las entidades antes especificadas (manos artificiales, sesiones, experimentos y personas), dando el soporte final a los objetivos propuestos para este proyecto. En el siguiente diagrama entidad-relaci´on se puede observar la estructura de estas entidades en el sistema.
8. Dise˜ no del sistema
Figura 8.2: Diagrama E-R de la base de datos
71
72
8.1. Dise˜ no de cada componente
8.1.4.1.
Pruebas que configuraron el dise˜ no
C´ odigo
Consultar recurso concreto inexistente PS-001
Componentes usados
Servidor.
Descripci´ on
Realizar una consulta a la base de datos pidiendo un recurso concreto a trav´es de un atributo que lo identifique pero que no existe en la base de datos.
Resultado esperado
El servidor devolver´a un mensaje de error.
Comentarios
Esta prueba se debe repetir para cada entidad que el sistema debe almacenar de manera persistente.
Cuadro 8.13: Prueba ‘Consultar recurso concreto inexistente’
Consultar listas de recursos almacenados C´ odigo PS-002 Componentes usados
Servidor.
Descripci´ on
Realizar una consulta a la base de datos habiendo insertado previamente recursos de prueba.
Resultado esperado
El servidor devolver´a la lista de recursos insertados previamente como respuesta.
Comentarios
Esta prueba se debe repetir para cada entidad que el sistema debe almacenar de manera persistente.
Cuadro 8.14: Prueba ‘Consultar listas de recursos almacenados’
8. Dise˜ no del sistema
73
Consultar recurso concreto PS-003
C´ odigo
Componentes usados
Servidor.
Descripci´ on
Realizar una consulta a la base de datos pidiendo un recurso concreto a trav´es de un atributo que lo identifique habiendo insertado previamente recursos de prueba.
Resultado esperado
El servidor devolver´a el recurso concreto insertado previamente como respuesta.
Comentarios
Esta prueba se debe repetir para cada entidad que el sistema debe almacenar de manera persistente.
Cuadro 8.15: Prueba ‘Consultar recurso concreto’
Almacenar nuevos datos de forma persistente C´ odigo PS-004 Componentes usados
Servidor.
Descripci´ on
Realizar una inserci´on en la base de datos para almacenar la nueva informaci´on de forma persistente.
Resultado esperado
El servidor insertar´a los datos correctamente en la base de datos.
Comentarios
Esta prueba se debe repetir para cada entidad que el sistema debe almacenar de manera persistente y cada vez que se actualice la estructura (atributos) de alguno de ellas.
Cuadro 8.16: Prueba ‘Almacenar nuevos datos de forma persistente’
74
8.1. Dise˜ no de cada componente
Eliminar datos no almacenados en el sistema C´ odigo PS-005 Componentes usados
Servidor.
Descripci´ on
Intentar eliminar un recurso inexistente en la base de datos.
Resultado esperado
El servidor devolver´a un mensaje de error al no poder encontrar el recurso a borrar.
Cuadro 8.17: Prueba ‘Eliminar datos no almacenados en el sistema’
Eliminar datos almacenados de forma persistente C´ odigo PS-006 Componentes usados
Servidor.
Descripci´ on
Eliminar uno de los recursos.
Resultado esperado
El servidor borrar´a los datos asociados al recurso referenciado de la base de datos, desapareciendo para siempre del sistema.
Cuadro 8.18: Prueba ‘Eliminar datos almacenados de forma persistente’
Actualizar datos no almacenados en el sistema C´ odigo PS-007 Componentes usados
Servidor.
Descripci´ on
Intentar actualizar uno o varios campos de una entidad inexistente en la base de datos.
Resultado esperado
El servidor devolver´a un mensaje de error al no poder encontrar el recurso concreto a actualizar.
Cuadro 8.19: Prueba ‘Actualizar datos no almacenados en el sistema’
8. Dise˜ no del sistema
75
Actualizar datos almacenados de forma persistente C´ odigo PS-008 Componentes usados
Servidor.
Descripci´ on
Actualizar uno o varios campos de una entidad en la base de datos.
Resultado esperado
El servidor actualizar´a el campo de la entidad referenciada correctamente en la base de datos descartando la informaci´on que antes ocupada ese lugar.
Cuadro 8.20: Prueba ‘Actualizar datos almacenados de forma persistente’
8.1.4.2.
Tecnolog´ıas de apoyo
Express JS Express es un framework web minimalista y flexible para Node JS que proporciona un conjunto robusto de caracter´ısticas para aplicaciones web y m´oviles. En su u ´ltima versi´on se ha decidido separar algunas de sus funcionalidades a m´odulos independientes como ’body-parser’, un middleware para traducir el formato de las peticiones en node para que sean entendidas por el programa, convirti´endose ahora en m´odulos independientes de Node JS. La funcionalidad m´as importante de express en el desarrollo realizado es el enrutamiento de las p´aginas, que se consigue de forma sencilla y eficaz con el apoyo de este m´odulo.
Mongoose Librer´ıa de modelado de objetos para Node JS que ofrece un riguroso entorno de modelado similar al modelado de objetos relacional (ORM) pero trabajando con documentos. En resumen, Mongoose transforma la informaci´on de la base de datos en objetos JavaScript que puede usar la aplicaci´on y viceversa.
76
8.1. Dise˜ no de cada componente
Postman Postman es una extensi´on del navegador Google Chrome. Hace las veces de Cliente REST para validar servicios web. Se ha empleado esta herramienta para hacer las pruebas contra el servidor antes de implementar el cliente final. Presenta una interfaz sencilla y f´acil de usar con posibilidad de guardar consultas y enviar y recibir peticiones en diferentes formatos.
8.1.5.
Cliente web
El cliente web aparece como una funcionalidad a˜ nadida para abrir la l´ınea de trabajo que permitir´ıa probar en una aplicaci´on real todas las funcionalidades del servidor implementado y hacer las veces de base para los futuros clientes web que trabajaran contra este sistema. Para facilitar esta futura evoluci´on, se emplear´an para su construcci´on una herramienta de u ´ltima generaci´on: REACT JS [10]. REACT es una librer´ıa JavaScript para crear interfaces de usuario din´amicas que sigue la arquitectura FLUX. Ha sido creada por Facebook para implementar tanto la red social l´ıder en el mundo como para Instagram (perteneciente a la compa˜ n´ıa desde 2012). El objetivo de React es construir aplicaciones de gran dimensi´on con un importante n´ umero de cambios a lo largo del tiempo. Esta librer´ıa intenta simplificar la creaci´on de vistas a trav´es de la reutilizaci´on de componentes, su pieza angular. React no usa plantillas, presenta una nueva forma de ver las interfaces como un conjunto de componentes con estado que son capaces de actualizarse cada vez que cambia este estado. La ventaja m´as llamativa que presenta REACT frente a otra herramientas con funcionalidad similares como Angular JS es la eficiencia en la actualizaci´on del DOM (Document Object Model): REACT introduce el concepto de DOM virtual, una copia virtual que usa para comparar los cambios de un componente en la vista, actualizando u ´nicamente los fragmentos que cambian, algo mucho m´as r´apido y eficiente que revisar el DOM en busca de cambios. En resumen, para REACT todos los elementos son componentes compuestos por componentes con un estado asociado del que son conscientes y, por consecuencia, son capaces de reaccionar cuando este estado cambia. Esta reacci´on se traduce en una comparaci´on entre el estado actual y el estado en el DOM virtual y en caso de ser distintos se actualiza en el DOM real ese u ´nico componente.
8. Dise˜ no del sistema
77
Una primera aproximaci´on al resultado final que deber´ıan adoptar las vistas del cliente web se puede ver en las im´agenes presentadas a continuaci´on.
Figura 8.3: Vista del cliente web para un administrador
Figura 8.4: Vista del cliente web para un usuario
78
8.1. Dise˜ no de cada componente
En estas im´agenes se puede apreciar como se emplea nuevamente el patr´on estrategia para optar por una presentaci´on u otra en funci´on del tipo de usuario; adem´as, este patr´on tambi´en podr´ıa usarse en este componente para realizar distintos an´alisis de datos en funci´on del cliente, filtrar por permisos de los distintos administradores, etc.
8.1.5.1.
Pruebas que configuraron el dise˜ no
C´ odigo
Obtener lista de recursos del servidor PC-001
Componentes usados
Servidor y cliente web.
Descripci´ on
El cliente web consultar´a los recursos almacenados en el sistema de una entidad a trav´es del servidor y los mostrar´a por pantalla.
Resultado esperado
El cliente muestra por pantalla la lista de recursos almacenados en la base de datos .
Comentarios
Esta prueba se repetir´a para cada entidad del sistema.
Cuadro 8.21: Prueba ‘Obtener lista de recursos del servidor’
8. Dise˜ no del sistema
C´ odigo
79
Obtener recurso concreto del servidor PC-002
Componentes usados
Servidor y cliente web.
Descripci´ on
El cliente consultar´a un recurso concreto almacenados en el sistema a trav´es del servidor y los mostrar´a por pantalla.
Resultado esperado
El cliente web muestra por pantalla el recurso concreto almacenado en la base de datos .
Comentarios
Esta prueba se repetir´a para cada entidad del sistema.
Cuadro 8.22: Prueba ‘Obtener recurso concreto del servidor’
C´ odigo
Insertar nuevos datos en el sistema PC-003
Componentes usados
Servidor y cliente web.
Descripci´ on
El cliente web insertar´a nueva informaci´on en el sistema a trav´es del servidor.
Resultado esperado
Los nuevos datos enviados por el cliente se almacenan correctamente en la base de datos.
Comentarios
Esta prueba se repetir´a para cada entidad del sistema.
Cuadro 8.23: Prueba ‘Insertar nuevos datos en el sistema’
80
8.1. Dise˜ no de cada componente
Eliminar datos inexistentes en el sistema C´ odigo PC-004 Componentes usados
Servidor y cliente web.
Descripci´ on
El cliente web intentar´a borrar informaci´on que no se encuentra almacenada en el sistema a trav´es del servidor.
Resultado esperado
El cliente web mostrar´a un mensaje de error al no encontrar el recurso a eliminar en el sistema.
Comentarios
Esta prueba se repetir´a para cada entidad editable del sistema.
Cuadro 8.24: Prueba ‘Eliminar datos inexistentes en el sistema’
Eliminar datos almacenados en el sistema C´ odigo PC-005 Componentes usados
Servidor y cliente web.
Descripci´ on
El cliente web intentar´a borrar informaci´on que no se encuentra almacenada en el sistema a trav´es del servidor.
Resultado esperado
El cliente web mostrar´a un mensaje de error al no encontrar el recurso a eliminar en el sistema.
Comentarios
Esta prueba se repetir´a para cada entidad editable del sistema.
Cuadro 8.25: Prueba ‘Eliminar datos almacenados en el sistema’
8. Dise˜ no del sistema
81
Actualizar datos inexistentes en el sistema C´ odigo PC-006 Componentes usados
Servidor y cliente web.
Descripci´ on
El cliente web intentar´a actualizar informaci´on que no se encuentra almacenada en el sistema a trav´es del servidor.
Resultado esperado
El cliente web mostrar´a un mensaje de error al no encontrar el recurso a actualizar en el sistema.
Comentarios
Esta prueba se repetir´a para cada entidad editable del sistema.
Cuadro 8.26: Prueba ‘Actualizar datos inexistentes en el sistema’
Actualizar datos almacenados en el sistema C´ odigo PC-007 Componentes usados
Servidor y cliente web.
Descripci´ on
El cliente web actualizar´a informaci´on almacenada en el sistema a trav´es del servidor.
Resultado esperado
Los nuevos datos enviados por el cliente se almacenan correctamente en la base de datos reemplazando la informaci´on que exist´ıa previamente.
Comentarios
Esta prueba se repetir´a para cada entidad editable del sistema.
Cuadro 8.27: Prueba ‘Actualizar datos almacenados en el sistema’
82
8.1. Dise˜ no de cada componente
Autenticar usuario insatisfactoriamente (Cliente web) C´ odigo PC-008 Componentes usados
Cliente web y servidor.
Descripci´ on
Al iniciar el cliente web se presentar´a por pantalla un formulario donde se insertar´a un nombre de usuario y una contrase˜ na inv´alidos para este sistema. Despu´es, se pulsar´a el bot´on de env´ıo.
Resultado esperado
Al presionar el bot´on se cotejar´a la informaci´on con los datos almacenados y, al no obtener una coincidencia, la aplicaci´on mostrar´a un mensaje de error.
Cuadro 8.28: Prueba ‘Autenticar usuario insatisfactoriamente (Cliente web)’
Autenticar usuario satisfactoriamente (Software local) C´ odigo PC-009 Componentes usados
Cliente web y servidor.
Descripci´ on
Al iniciar la aplicaci´on m´ovil se presentar´a por pantalla un formulario donde se insertar´a un nombre de usuario y una contrase˜ na v´alidos en el sistema. Despu´es, se pulsar´a el bot´on de env´ıo.
Resultado esperado
Al presionar el bot´on se cotejar´a la informaci´on con los datos almacenados y, al obtener una coincidencia, la aplicaci´on mostrar´a la vista principal de la aplicaci´on.
Cuadro 8.29: Prueba ‘Autenticar usuario satisfactoriamente (Cliente web)’
8. Dise˜ no del sistema
8.2.
83
Otras herramientas y tecnolog´ıas
En este apartado se describen las tecnolog´ıas de apoyo usadas en el desarrollo de m´as de un componente o que no encajan en ninguno de los apartados anteriores. Google Chrome Navegador web desarrollado por Google, considerado el navegador m´as usado de Internet. Incluye una consola muy u ´til para el desarrollador de aplicaciones web que permite depurar fallos y realizar distintas pruebas.
Safari Navegador web desarrollado por Apple de c´odigo cerrado. La consola que incorpora permite depurar fallos y realizar pruebas en dispositivos iOS (solo desde un equipo Macintosh) .
ProjectLibre Es la respuesta en c´odigo abierto a Microsoft Project (MS Project). Ambos son software de administraci´on de proyectos que permite gestionar todo lo relacionado con la planificaci´on y seguimiento de proyectos. Incluye la posibilidad de crear gr´aficos PERT, diagramas de Gantt, diagramas de estructura anal´ıtica de recursos(RBS)... Comparado con MS Project, ProjecLibre tiene una interfaz de usuario similar y una metodolog´ıa muy parecida para la construcci´on de un plan de proyecto: se crea una lista de tareas identadas o una estructura de descomposici´on del trabajo (WBS), se establecen duraciones, se crean enlaces y se asignan recursos. Los campos y las caracter´ısticas de costos son las mismas en ambos productos. Adem´as, ProjectLibre ofrece una compatibilidad completa con Microsoft Project 2010.
84
8.2. Otras herramientas y tecnolog´ıas
Cap´ıtulo 9
Implementaci´ on del sistema
na vez presentada una visi´on abstracta de todo el proyecto en las p´aginas anteriores, este cap´ıtulo se centra en los detalles del nivel m´as bajo, incluyendo fragmentos de c´odigo y ejemplos reales de la construcci´on y desarrollo de los componentes del sistema.
U
9.1.
Pr´ otesis
Como se expuso anteriormente, el objetivo final del proyecto Exandounamano es conseguir una pr´otesis a tama˜ no real que pueda ser usada por personas discapacitadas, por tanto la construcci´on f´ısica de este componente es fundamental para validar el funcionamiento del sistema. Por suerte, las posibilidades que ofrecen las nuevas tecnolog´ıas para la creaci´on de objetos f´ısicos son pr´acticamente ilimitadas. Aunque las impresoras en tres dimensiones todav´ıa est´an en las fases iniciales de su evoluci´on, son una buena forma de construir piezas de forma sencilla. En la construcci´on de esta pr´otesis se han empleado dos clases distintas de materiales: PLA: a´cido polil´actico o polil´actido es un pol´ımero biodegradable derivado del ´acido l´actico, se trata de un pl´astico biodegradable y reciclable procedente del ma´ız o de la patata. No es un material nuevo, fue descubierto en 1932 por Wallace Carothers pero el alto coste del proceso de obtenci´on retras´o la producci´on en masa hasta la d´ecada de los noventa cuando los avances tecnol´ogicos abarataron el procedimiento.
85
86
9.1. Pr´ otesis
FilaFlex: Pl´astico de origen espa˜ nol formado por una mezcla de pol´ımeros similar al PLA pero con una serie de aditivos y mejoras que le otorgan flexibilidad. En 2013 se convirti´o en el primer material en el mercado con estas caracter´ısticas y, a d´ıa de hoy, sigue siendo el m´as el´astico (un setecientos por ciento de alargamiento a la rotura). Las caracter´ısticas de estos materiales se extienden a todas las piezas de la pr´otesis final, creando un producto biodegradable, es decir, con el paso del tiempo y el efecto de los elementos la mano artificial se descompondr´a en elementos qu´ımicos simples que no son nocivos para la naturaleza; y adem´as, reciclabe de forma que cuando una pr´otesis finaliza su ciclo de vida puede fundirse y volver a usar los pl´asticos de los que se compone en nuevas impresiones. La construcci´on de la mano artificial se ha basado en el dise˜ no ’Flexy-Hand’ de Gyrobot. Las dimensiones de las piezas son totalmente adaptables al usuario final, en este caso concreto se han usado unas medidas proporcionales a las de la mano del autor del proyecto.
Figura 9.1: Desglose de las piezas de la mano artificial
9. Implementaci´ on del sistema
87
Tambi´en es posible adaptar las piezas en funci´on del tipo de discapacidad del usuario final, es muy simple modificar cualquier pieza de este dise˜ no o a˜ nadir nuevas piezas al dise˜ no con alg´ un software CAD como AutoCAD; realmente la mayor complejidad del dise˜ no se encuentra en el movimiento de los dedos, a˜ nadir nuevas piezas para mejorar la sujeci´on no supone un problema. Respecto al proceso de impresi´on, el primer paso es importar el dise˜ no de cada pieza al programa Slic3r (que admite varias piezas a la vez) en donde se trocear´a por capas y se exporta en un archivo .gcode interpretable por la impresora en tres dimensiones. La primera impresi´on se llev´o a cabo en una peque˜ na impresora de construcci´on manual pero los resultados distaban considerablemente de la calidad esperada por lo que se continu´o el proceso de impresi´on en una impresora profesional LulBotz TAZ 4 (localizada en el museo de la Domus de Coru˜ na). Como es preferible no cortar el proceso de impresi´on para evitar defectos en las piezas y como esta impresora solo est´a disponible en intervalos de tres horas diarias, fue necesario organizar con el Slic3r el orden de impresi´on para no exceder el tiempo de cada proceso. Una vez que el archivo .gcode es exportado hay dos formas de comenzar la impresi´on, la primera y menos eficiente es usando el programa Printrun, que permite el control de la impresora desde el ordenador a trav´es de una conexi´on USB; y la segunda a trav´es de una tarjeta SD y posteriormente insertar esta en el lector de tarjetas que incorpora la impresora. El proceso de impresi´on todav´ıa necesita optimizarse considerablemente, especialmente para los nuevos materiales como el filaFlex. Durante las horas de impresi´on es necesaria una supervisi´on continua para evitar que alg´ un fragmento de material fundido se atasque en el cabezal de extrusi´on de la impresora o sea arrastrado fuera de su lugar, si esto sucediera se debe parar la impresi´on retirar el material impreso y volver a comenzar el proceso desde el principio. Una vez impresas todas las piezas se pueden montar a trav´es de los enlaces de material flexible que hace las veces de ligamentos. Cada una de las piezas no flexibles est´a atravesada por un peque˜ no conducto por el que se introducir´a un filamento conector (hilo de pescar) que unir´a la pr´otesis con el motor que, tensando estos filamentos, conseguir´a simular el movimiento de una mano humana.
88
9.2.
9.2. Arduino Uno
Arduino Uno
El microprocesador Arudino Uno es el encargado de realizar las funciones del software de control. El primer paso en la implementaci´on de este componente es familiarizarse con su entorno de desarrollo y su lenguaje de programaci´on. Es un lenguaje sencillo debido su nivel de abstracci´on, no lo suficientemente alto como para utilizar estructuras complejas como los lenguajes de programaci´on m´as comunes ni lo suficientemente bajo como para dificultar la programaci´on como en un procesador MIPS. Para probar un programa solo es necesario validarlo y ’subirlo’ al microcontrolador que se puede hacer de forma sencilla usando los botones del IDE habilitados para ello. Una vez que se han realizado algunas pruebas con el lenguaje comienza la fase de construcci´on del circuito, fase que se realiza en tres iteraciones (una por cada componente) realizando en cada iteraci´on las pruebas espec´ıficas descritas en el cap´ıtulo anterior. En la figura se puede observar un croquis del montaje de la primera iteraci´on, donde se acopla y prueba el componente bluetooth al software de control.
Figura 9.2: Conexi´on entre el componente bluetooth y arduino
9. Implementaci´ on del sistema
89
La segunda iteraci´on de la implementaci´on del software de control consiste en conectar el servo al arduino y realizar las pruebas espec´ıficas ideadas en la fase de dise˜ no. El siguiente c´odigo pertenece al archivo .ino encargado de controlar el servo. Se puede observar la asignaci´on de conexiones del arduino (pin) nada m´as comenzar, en las l´ıneas siguientes se asignan los valores del voltaje que representar´an los movimientos. Por u ´ltimo, se puede ver que el control del servo se realiza mediante la actualizaci´on de su posici´on que ser´a enviada al puerto en el que se encuentra conectado f´ısicamente el motor mediante una funci´on vinculante posterior (no inclu´ıda en la imagen para simplificar la explicaci´on).
Figura 9.3: C´odigo del funcionamiento del servo La u ´ltima iteraci´on se resume en la integraci´on del sensor muscular con los componentes integrados anteriormente, representando en el c´odigo el puerto correspondiente por el que entrar´a la informaci´on que transmita el sensor (puede verse en la segunda l´ınea del c´odigo anterior). El problema fundamental de esta tercera iteraci´on es la vida de los electrodos que toman la informaci´on directamente del m´ usculo y la env´ıan al sensor, tienen un intervalo de recogida de est´ımulos aceptable durante una media de veinte minutos, algo del todo inaceptable para conseguir el objetivo final del proyecto. No obstante, por falta de tiempo y una alternativa mejor se ha creado el prototipo siguiendo el plan original de usar esta tecnolog´ıa.
90
9.3. Aplicaci´ on m´ ovil
Figura 9.4: Conexi´on entre el sensor muscular, el m´ usculo y arduino
9.3.
Aplicaci´ on m´ ovil
Como se vi´o en cap´ıtulos anteriores se ha decidido que la funci´on de software local la lleve a cabo el dispositivo m´ovil del usuario, por lo que es necesario implementar una app (preferiblemente multiplataforma) que consiga este objetivo. La instalaci´on de Apache Cordova y su despliegue sobre plataformas android son realmente sencillos, con un n´ umero m´ınimo de comandos se puede a˜ nadir la plataforma y ejecutar la aplicaci´on en el dispositivo mediante conexi´on USB. Para otras plataformas como blackberry es necesario realizar unos pasos previos que incluyen darse de alta oficialmente como programador de la plataforma y la configuraci´on de tokens tanto en el dispositivo como en el equipo de trabajo. Al ser una tecnolog´ıa basada en javascript, HTML y CSS es bastante intuitivo de usar y los plugins que a˜ naden funcionalidad (especialmente con el hardware del dispositivo) son realmente sencillos de instalar y utilizar. Para la conexi´on bluetooth se ha instalado un plugin de la comunidad que solo opera con plataformas iOS y android, lo cual es un impedimento si alg´ un usuario o administrador trabaja con otra plataforma. No obstante, al ser c´odigo libre existe la posibilidad de extender la funcionalidad del plugin a otras plataformas populares como blackberry o windows phone.
9. Implementaci´ on del sistema
91
Figura 9.5: Prueba de integraci´on del plugin de bluetooth con Cordova
Para la internacionalizaci´on se ha empleado un plugin para detectar el idioma en el que se encuentra el tel´efono y en funci´on de esto llamar a una vista u otra, al no ser una aplicaci´on demasiado compleja no parece un problema la repetici´on de ciertas partes del c´odigo en varios idiomas. Por otra parte, la detecci´on de conectividad se llev´o a cabo mediante otro plugin de Apache Cordova que permite a la aplicaci´on conocer el estado de la conectividad del dispositivo, como se aprecia en el siguiente c´odigo es sencillo implementar esta funcionalidad con el plugin y una sentencia condicional. De esta forma, en el caso de que el dispositivo se encuentre conectado a una red wifi se enviar´a la petici´on de manera habitual y en caso de que no se cumpla la condici´on se almacenar´a la informaci´on a enviar en el dispositivo vali´endose de los m´etodos de localStorage que ofrece HTML.
92
9.3. Aplicaci´ on m´ ovil
Figura 9.6: C´odigo del funcionamiento del la aplicaci´on m´ovil
Para la conexi´on con el servidor se utiliz´o javascript plano para realizar las peticiones HTTP, pero eventualmente se introdujo la librer´ıa JQuery que simplifica el trabajo y mejora la visibilidad del c´odigo especialmente en esta funci´on usando el m´etodo ajax. El formato de intercambio de dato que emplear´an estas peticiones HTTP ser´a JSON, se ha elegido este formato frente a XML debido a la tecnolog´ıa usada en la base de datos del servidor (mongoDB) que trabaja directamente con documentos JSON (almacen´andolos en BSON por motivos de eficiencia) por lo que no ser´ıa necesaria transformaci´on alguna de los datos desde el dispositivo m´ovil hasta su almacenamiento persistente simplificando todo el proceso. En el c´odigo anterior se puede observar como se realiza estas peticiones HTTP a trav´es del m´etodo ajax de JQuery de forma autom´atica en el tiempo gracias a la funci´on de javascript ’setInterval’ que toma como par´ametros una funci´on y un n´ umero entero que es el tiempo (en milisegundos) entre ejecuciones de la funci´on. Al tratarse de un prototipo, la soluci´on m´as sencilla para establecer un canal de comunicaci´on entre el dispositivo m´ovil y el servidor localizado en el equipo de trabajo es la conexi´on de ambos elementos a la misma red wifi privada y establecer comunicaci´on a trav´es de la direcci´on ip privada que tienen asignada; esto es, al conectar ambos dispositivos a la misma red privada se les asigna autom´aticamente una direcci´on ip privada que los identifica de manera inequ´ıvoca dentro de esa red, a trav´es del cual se pueden referenciar entre ellos.
9. Implementaci´ on del sistema
9.4.
93
Servidor
La implementaci´on del componente servidor del sistema recae sobre la nueva tecnolog´ıa Node JS, una tecnolog´ıa que simplifica en gran medida la creaci´on de esta clase de software y la gesti´on de aspectos como el balance de carga. Adem´as, tambi´en sigue una arquitectura modular que permite a˜ nadir nuevas funcionalidades integrando otras librer´ıas javascript. La primera de estas librer´ıas que se integr´o fue mongoose, una librer´ıa de modelado de objetos que agiliza la comunicaci´on entre un servidor escrito en Node JS y una base de datos MongoDB. Se trata b´asicamente de crear una especificaci´on detallada de cada entidad para que la librer´ıa sea capaz de traducir los objetos del servidor a objetos de la base de datos, tambi´en se pueden delegar en mongoose las acciones de validaci´on. En el c´odigo siguiente aparece uno de los modelos empleados en este desarrollo.
Figura 9.7: Ejemplo de modelo con mongoose
94
9.4. Servidor
Otra de las librer´ıas empleadas en este desarrollo es express js que complementa a node con una amplia lista de nuevas capacidades pero entre las que destaca el enrutamiento. Esta tarea se ha delegado completamente en express js ya que permite crear en pocas l´ıneas un sistema de enrutamiento a trav´es de URIs todo lo que complejo que se precise. De esta forma, se crea una API REST para atender las llamadas del cliente web y de la aplicaci´on m´ovil, dejando la puerta abierta para futuros componentes que podr´an integrarse al sistema de esta misma forma.
Figura 9.8: Ejemplo de enrutamiento y procesamiento apoyado en express
Para la realizaci´on de las pruebas asociadas al dise˜ no del servidor se emple´o la herramienta postman, del navegador Google Chrome. Su u ´nico objetivo es la validaci´on de un servidor ofreciendo una interfaz amigable y f´acil de entender. En la siguiente ilustraci´on aparece representado el momento en el que se supera satisfactoriamente una de las pruebas asociadas a este componente. Por falta de medios, tanto el servidor como la base de datos se alojan en el mismo equipo de trabajo, esto reduce todas las ventajas y optimizaciones paras las que fueron concebidos. En el futuro, cuando llegue el momento de desplegar este sistema en un entorno real ser´a necesario revisar la infraestructura necesaria para el despliegue de estos componentes ya que queda fuera del alcance de este proyecto.
9. Implementaci´ on del sistema
Figura 9.9: Prueba ’Consultar listas de recursos almacenados’ con postman
95
96
9.5.
9.5. Cliente web
Cliente web
Para la implementaci´on del cliente web se ha elegido la nueva tecnolog´ıa de Facebook: REACT. Aunque el lenguaje de programaci´on es javascript la curva de aprendizaje es mayor porque cambia totalmente la visi´on cl´asica de una aplicaci´on en este lenguaje al tratar todos los elementos como competentes interconectados. Este inconveniente sumado a los retrasos temporales frente a la planificaci´on inicial hace que no se consiga acabar la implementaci´on dise˜ nada para este componente, construyendo u ´nicamente un programa base que servir´a para erigir la estructura ideada. Este cliente web es capaz de consultar las bases de datos y actualizar la vista en tiempo real y de forma totalmente autom´atica mostrando las actualizaciones en los experimentos de una sesi´on activa. A continuaci´on se muestra el c´odigo escrito con REACT para probar la conexi´on con el servidor. En este programa simple, se muestra un formulario en la vista que inserta los datos de una persona al pulsar el bot´on de env´ıo y los env´ıa mediante una petici´on POST al servidor para su inserci´on en la base de datos.
9. Implementaci´ on del sistema
Figura 9.10: Prueba ’Consultar listas de recursos almacenados’ con postman
97
98
9.5. Cliente web
Cap´ıtulo 10
Pruebas del sistema
Continuando con la metodolog´ıa propuesta en los apartados anteriores, en este cap´ıtulo se tratan las pruebas de integraci´on de alto nivel que aparecen como consecuencia l´ogica del aumento de abstracci´on y complejidad de las pruebas descritas en dise˜ no.
Comunicaci´ on satisfactoria entre todos los componentes C´ odigo PI-001 Componentes usados Arduino, aplicaci´on m´ovil, cliente web y servidor Descripci´ on Conectar el sistema al brazo del usuario y el m´ovil donde se ejecuta la aplicaci´on m´ovil a una red wifi. Despu´es, el usuario cerrar´a el pu˜ no comprobando que la pr´otesis realiza el movimiento correcto. Despu´es, comprobar que la informaci´on pertinente se ha guardado en el sistema. Resultado esperado La mano artifical realiza el movimiento de cerrar el pu˜ no y los datos se almacenan de forma permanente en el sistema Cuadro 10.1: Prueba ‘Comunicaci´on insatisfactoria entre todos los componentes’
99
100
Comunicaci´ on insatisfactoria entre todos los componentes C´ odigo PI-002 Componentes usados Arduino, aplicaci´on m´ovil, cliente web y servidor Descripci´ on Conectar el sistema al brazo del usuario y desconectar el m´ovil donde se ejecuta la aplicaci´on m´ovil de cualquier red wifi. Despu´es, el usuario cerrar´a el pu˜ no comprobando que la pr´otesis realiza el movimiento correcto. Despu´es, comprobar que la informaci´on de este experimento no ha llegado al sistema. Resultado esperado La mano artifical realiza el movimiento de cerrar el pu˜ no y los datos no se almacenan de forma permanente en el sistema Cuadro 10.2: Prueba ‘Comunicaci´on insatisfactoria entre todos los componentes’
Reactivaci´ on del flujo C´ odigo PI-003 Componentes usados Arduino, aplicaci´on m´ovil, cliente web y servidor Descripci´ on Tras realizar la prueba PI-002, conectar el dispositivo m´ovil a una red wifi. Despu´es, comprobar que los datos de los experimentos durante el per´ıodo de conexi´on se han almacenado correctamente en el sistema. Resultado esperado La informaci´on guardada en el tel´efono durante el per´ıodo sin conexi´on a la red wifi se env´ıa al recuperar la conexi´on. Cuadro 10.3: Prueba ‘Reactivaci´on del flujo’
Cap´ıtulo 11
Conclusi´ on y futuras l´ıneas de trabajo
n este u ´ltimo cap´ıtulo se hace un peque˜ no resumen del proyecto, haciendo balance del grado de satisfacci´on de los objetivos planteados al inicio frente a los problemas encontrados y proponiendo posibles futuras l´ıneas de trabajo.
E
11.1.
Conclusiones
El objetivo de este proyecto era crear un sistema de informaci´on para dar soporte a la comunidad de desarrollo de pr´otesis de extremidades superiores, implementando una mejora en sus procedimientos que incluyera una automatizaci´on en el proceso de recolecci´on de datos y la posibilidad de consultar las informaci´on guardada desde cualquier lugar y en cualquier momento. Una vez finalizado el proyecto, se puede afirmar que el objetivo se ha cumplido satisfactoriamente. Se ha construido un sistema con componentes totalmente heterog´eneos completamente integrados, de forma que todos los desarrollos futuros del sistema no tendr´an que preocuparse por incidencias con la comunicaci´on entre componentes; incluso llegando a cambiar la tecnolog´ıa de alguno de ellos, las interfaces de comunicaci´on se encuentran totalmente definidas simplificando el proceso. Se ha creado un producto capaz de responder a las necesidades que lo motivaron sin abandonar en ning´ un momento la filosof´ıa original del proyecto Exandounamano al trabajar u ´nicamente con software y hardware libre y siendo el producto final parte de estas corrientes. 101
102
11.1. Conclusiones
S´ı es cierto que ha sido un proyecto ambicioso desde el principio y ha sido un largo camino, especialmente porque no se puede asociar este sistema a una especialidad de la inform´atica concreta ya que ha sido necesario involucrarse en distintos campos para poder llevarlo a cabo. Entre los problemas encontrados cabe destacar la dificultad del proceso de impresi´on en tres dimensiones con los filamentos pl´asticos, que consumi´o m´as de cuarenta horas del desarrollo del proyecto; y la dificultad de integraci´on de todos los componentes, especialmente la conexi´on de la plataforma arduino con el dispositivo m´ovil provocado por los distintos formatos del protocolo bluetooth. No obstante, los conocimientos adquiridos durante la implementaci´on de este proyecto ser´an de gran ayuda para la incorporaci´on al mundo laboral y la creaci´on de otros muchos proyectos que ahora ya podr´an versar sobre materias pertenecientes a distintos campos. En comparaci´on con los productos similares que se encuentran en el mercado actual, las funcionalidades de este sistema son reducidas. Sin embargo, haciendo una media ponderada m´as justa en la que se tenga en cuenta los recursos y el tiempo empleados en este desarrollo, el producto descrito en este texto no tiene nada que envidiar a sus semejantes, especialmente porque los m´etodos de funcionamiento de las pr´otesis son exactamente iguales (variando la calidad de la tecnolog´ıa) y adem´as incluyendo todo lo relativo al sistema de informaci´on que se ha desplegado alrededor de la mano aritificial, algo que otras soluciones no ofrecen. Por supuesto, este producto no puede competir con el de grandes compa˜ n´ıas del sector que vender´an su desarrollo por un elevado precio; pero este sistema no intenta competir con esas grandes soluciones, est´a destinado a otro colectivo, est´a destinado a las personas discapacitadas que no tengan recursos suficientes para conseguir esas soluciones y que a´ un as´ı tienen derecho a una mejora en su calidad de vida. Con el fin de llegar a esas personas, se entregar´a este proyecto al grupo Exandounamano y e-NABLE para que puedan usarlo como base para futuros y presentes desarrollos o para perfeccionarlo hasta convertirlo en un producto que cumpla con todas sus necesidades.
11. Conclusi´ on y futuras l´ıneas de trabajo
103
Por u ´ltimo, solo queda a˜ nadir que la valoraci´on del proyecto desde el punto de vista del autor, atendiendo a todos los aspectos tanto profesionales como personales, ha sido realmente positiva.
11.2.
Futuras l´ıneas de trabajo
Migraci´ on multiplataforma
La primera mejora en el proyecto deber´ıa ser trasladarlo a cualquier plataforma m´ovil existente, es l´ogico que los administradores y usuarios de esta pr´otesis usen distintas plataformas en sus tel´efonos, haciendo este proyecto compatible con Blackberry o Windows Phone el producto se hace compatible con m´as personas. Actualmente, el producto entregado ya es compatible con Android e iOS, simplemente extendiendo el plugin de bluetooth empleado en el software local ya ser´ıa compatible con todas las plataformas posibles. Mejora de sensores de recepci´ on de o ´rdenes
El sensor muscular empleado en este desarrollo as´ı como los electrodos asociados comienzan a bajar la calidad de recolecci´on de informaci´on en un per´ıodo demasiado corto de tiempo debido a la p´erdida de adhesi´on a la piel de los electrodos. Parece necesario una actualizaci´on inminente en esta tecnolog´ıa que se reflejar´a en la mejora de todo el sistema. En esta actualizaci´on se podr´ıa tener en cuenta la l´ınea de trabajo en la que el usuario final puede consultar sus constantes vitales en la app m´ovil. No es complicado encontrar sensores que adem´as de interpretar los est´ımulos musculares env´ıen las constantes b´asicas. Y, ya en el supuesto de cambiar los sensores musculares, podr´ıa pensarse en cambiarlos por otra tecnolog´ıa totalmente distinta como los sensores cerebrales. Hoy en d´ıa existen en el mercado distintos sensores cerebrales con un funcionamiento similar al sensor muscular aqu´ı empleado.
104
11.2. Futuras l´ıneas de trabajo
Por ejemplo, el sensor cerebral ’Muse’, incrusta siete sensores en una peque˜ na diadema de dise˜ no, siendo capaz de detectar las cinco bandas de ondas cerebrales. Una vez captadas las se˜ nales, ser´ıa sencilla la integraci´on con el sistema aqu´ı creado. Mejora del cliente web
El cliente web aqu´ı presentado es un prototipo con infinidad de posibilidades a explotar. La principal funci´on que podr´ıa cumplir es la mejora de la comunicaci´on entre especialistas de distintas materias, a trav´es de la inclusi´on de gr´aficas que faciliten el entendimiento de los datos almacenados en el sistema. Esto no solo mejorar´ıa la comunicaci´on entre expertos y administradores, en el futuro podr´ıa usarse para que los propios m´edicos comprueben el estado de la pr´otesis de su paciente incluso haciendo consultas online. La librer´ıa D3JS es totalmente compatible con REACT y se podr´ıan integrar de forma que se muestren visual e interactivamente no solo la informaci´on de los experimentos, sino que se podr´ıan crear gr´aficos peri´odicos que aporten informaci´on sobre aspectos tan variados como las visitas a la p´agina, las secciones m´as visitadas, el crecimiento de la comunidad, el ´ındice de calidad de las pr´otesis fabricadas . . .
Ap´ endices
Ap´ endice A
Licencia
A.1.
Introducci´ on
Una licencia de software es un contrato entre el licenciante (autor/titular de los derechos de explotaci´on/distribuidor) y el licenciatario (usuario consumidor) del programa inform´atico, para usar el software cumpliendo una serie de t´erminos y condiciones establecidas dentro de sus cl´ausulas. En este contrato se pueden establecer la responsabilidad por fallos del producto, la reinstalaci´on del programa en equipos distintos al que se instal´o originalmente, el ´ambito geogr´afico de validaez del contrato, etc.
A.2.
General Public License vs Affero General Public License
La Licencia P´ ublica General de GNU (GPL) es la licencia m´as usada en el mundo del software y garantiza a los usuarios finales la libertad de usar, estudiar, compartir y modificar ese software. El objetivo final de esta licencia es declarar que el software licenciado es software libre y protegerlo de intentos de apropiaci´on que restrinjan las libertades del usuario. La licencia de GNU es una licencia copyleft, esto es, la licencia aplicada a un software bajo su influencia se extiende a todas las futuras versiones y proyectos derivados de ese software. Por ejemplo, si una aplicaci´on usa una decena de componentes y solo uno de ellos presenta una licencia GPL, la aplicaci´on final deber´a usar esa misma licencia, asegur´andose as´ı
107
108
A.3. Licencias de componentes usados
que el software est´a protegido cada vez que el trabajo es distribuido, modificado o ampliado. Es importante destacar que para que el copyleft tenga validez sobre el software final, este debe estar integrado por el componente con licencia GPL, por esta raz´on no es necesario que las aplicaciones instaladas en sistemas operativos bajo licencia GPL (como Linux) tengan restricciones de licencia o de distribuci´on de c´odigo fuente. La Licencia P´ ublica General de Affero (AGPL) es una licencia derivada de la Licencia P´ ublica General de GNU (GPL) dise˜ nada espec´ıficamente para asegurar la cooperaci´on con la comunidad en el caso de software que corra en servidores de red. Es una licencia copyleft que garantiza las libertades de usuario propuestas por la licencia GPL antes descrita, adapt´andola a las nuevas arquitecturas de software. La necesidad de esta actualizaci´on es consecuencia de las cl´ausulas de la licencia GPL, que se basan en la distribuci´on f´ısica del software. En la ´epoca actual, pocas aplicaciones y programas se distribuyen f´ısicamente al usuario, se tiende al uso de servicios web donde el c´odigo licenciado se encuentra en los servidores de la empresa sin necesidad de que el usuario final tenga contacto f´ısico con ´el (ejemplos de productos que encajan en esta descripci´on son Google, Facebook...), por tanto no aplican los t´erminos de distribuci´on de la licencia original permitiendo legalmente el incumplimiento de la licencia. Surge as´ı AfferoGPL, que a˜ nade una cl´ausula nueva con la obligaci´on de distribuir el software si este se ejecuta para ofrecer servicios a trav´es de una red de ordenadores, es decir, aplica el copyleft y las libertades de la GPL al software sin necesidad de su distribuci´on f´ısica al cliente final.
A.3.
Licencias de componentes usados
REACT JS Presenta una licencia BSD, una de las licencias m´as permisivas. Arduino El n´ ucleo y las librer´ıas de Arduino se ofrecen bajo la licencia LGPL, una versi´on m´as permisiva que la GPL. Apache Cordova Licencia Apache, licencia permisiva sin copyleft. MongoDB La licencia de MongoDB presenta un caso especial. Este sofwtare ofrece una licencia distinta para el servidor y sus m´odulos y otra para los drivers de acceso. Esto se debe a que el n´ ucleo de MongoDB est´a licenciado
A. Licencia
109
bajo los t´erminos de la licencia AGPL, de forma que todas las aplicaciones que usen Mongo tendr´ıan que licenciarse bajo AGPL. Para que esto no suceda los drivers que usan las aplicaciones para comunicarse con la base de datos tienen una licencia Apache (mucho m´as permisiva y sin copyleft). JQuery Los proyectos de la fundaci´on JQuery se publican bajo los t´erminos de la licencia MIT, una licencia muy permisiva que a penas impone restricciones al software que representa. Node JS Presenta una licencia MIT, esta licencia es muy permisiva y no aplica copyleft.
A.4.
Licencia del proyecto
Dado el car´acter de este proyecto, basado en el apoyo a la investigaci´on y con fines acad´emicos se ha optado por una licencia p´ ublica general de Affero (AGPL) para garantizar las libertades de todos los usuarios a los que llegue este proyecto con intenci´on de fomentar su estudio y mejora. Copyright (C) 2015
Tirso V. Rodeiro
This program is free software: you can redistribute it and/or modify it under the terms of the GNU Affero General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Affero General Public License for more details. You should have received a copy of the GNU Affero General Public License along with this program. If not, see .
110
A.4. Licencia del proyecto
Ap´ endice B
Glosario de acr´ onimos
AGPL Affero General Public License AJAX Asynchronous JavaScript And XML API Application Programming Interface BSON Binary JSON CAD Computer Aided Design CSS Cascading Style Sheets DOM Document Object Model GPL General Public License HTTP Hypertext Transfer Protocol IDE Integrated Development Environment IP Internet Protocol JSON JavaScript Object Notation MIPS Microprocessor without Interlocked Pipeline Stages PLA Poli´acido l´actico REST Representational State Transfer SD Secure Digital 111
112
TDD Test Driven Development URI Uniform Resource Identifier URL Uniform Resource Locator WBS Work Breakdown Structure XML eXtensible Markup Language
Ap´ endice C
Glosario de t´ erminos
Agenesia Anomal´ıa de todo (o parte de) un o´rgano al desarrollarse durante el crecimiento embrionario. Ciclo de vida Conjunto de fases por las que fluye un software desde su concepci´on hasta su muerte (entendiendo su muerte como el momento en el que se deja de usar). Habitualmente incluye las fases de an´alisis, dise˜ no, desarrollo y pruebas. Direcci´ on IP Etiqueta num´erica que identifica de manera inequ´ıvoca un elemento dentro de una red que utilice el protocolo IP. FilaFlex Material de impresi´on en tres dimensiones de origen espa˜ nol constituido por una mezcla de pol´ımeros y otros aditivos que le otorgan flexibilidad. Hamaca En planificaci´on, actividad especial cuyo fin es medir el tiempo transcurrido entre dos puntos de la red y que engloba a otras actividades. Hardware libre Dispositivos de hardware cuyas especificaciones y diagramas esquem´aticos son de acceso p´ ublico. Servidor Software en ejecuci´on capaz de atender las peticiones de un cliente y responder en concordancia. Servo Peque˜ no dispositivo cuyo componente m´as destacable es un motor de corriente continua, de forma que es capaz de transformar energ´ıa el´ectrica en energ´ıa mec´anica.
113
114
Software CAD Rango de herramientas computacionales de dibujo 2D y modelado 3D que asisten a ingenieros, arquitectos y dise˜ nadores en el dise˜ no de sus productos.
Bibliograf´ıa
[1] Kent Beck. Test Driven Development. Addison-Wesley, 4 edition, 2002. [2] Martin Fowler. The new methodology, 2005. [3] Johann Wolfgang Goethe. G¨otz von Berlichingen. RECLAM VERLAG, 2013. [4] Fergus Walsh. Bionic hand allows patient to ’feel’. BBC, Febrero 2014. [5] Ronald Zak. Bionic reconstruction gives men first prosthetic hands controlled by mind. The Guardian, Marzo 2015. [6] Antonio Caicedo Pedrera. Arduino para principiantes. Createspace, 1 edition, 2014. [7] John M. Wargo. Apache Cordova 3 Programming (Mobile Programming). Pearson Education, 2 edition, 2014. [8] Manuel Kiessling. The Node Beginner Book: A comprehensive Node.js tutorial. LeanPub, 1 edition, 2015. 115
116
[9] Kristina Chodorow. MongoDB: The Definitive Guide. O’Reilly Media, 2 edition, 2013. [10] Facebook. React js: A javascript library for building user interfaces.
BIBLIOGRAF´IA
Lihat lebih banyak...
Comentarios
