INGENIERO EN SISTEMAS COMPUTACIONALES...
Transcript of INGENIERO EN SISTEMAS COMPUTACIONALES...
UNIVERSIDAD DE GUAYAQUIL
FACULTAD DE CIENCIAS MATEMÁTICAS Y FÍSICAS
CARRERA DE INGENIERÍA EN SISTEMAS COMPUTACIONALES
SISTEMA DE AUTOGESTIÓN DE LA SALUD PARA PACIENTES CON
DIABETES Y ASMA, DESARROLLADO E IMPLEMENTADO EN UNA
PLATAFORMA ANDROID; CON MONITOREO DE UNA APLICACIÓN
WEB EN PHP DIRIGIDA A LOS MÉDICOS TRATANTES, ENFOCADO
EN EL DISEÑO E IMPLEMENTACIÓN DE UNA ARQUITECTURA
DE MICROSERVICIOS USANDO TECNOLOGÍA JAVA PARA LA
INTEGRACIÓN DE LA PLATAFORMA ANDROID CON
LA BASE DE DATOS MYSQL.
PROYECTO DE TITULACIÓN
Previa a la obtención del Título de:
INGENIERO EN SISTEMAS COMPUTACIONALES
AUTOR: JORDY LUIS PEÑALOZA BRAVO
TUTOR: Ing. Fabricio Sánchez
GUAYAQUIL – ECUADOR
2017
REPOSITORIO NACIONAL EN CIENCIAS Y TECNOLOGÍA
FICHA DE REGISTRO DE TESIS
TÍTULO Y SUBTÍTULO:
Sistema de autogestión de la salud para pacientes con diabetes y asma, desarrollado e implementado en una plataforma Android; con monitoreo de una aplicación web en PHP dirigida a los médicos tratantes, enfocado en el diseño e implementación de una arquitectura de microservicios usando tecnología java para la integración de la plataforma Android con la base de datos MySQL.
AUTOR: JORDY LUIS PEÑALOZA BRAVO
REVISOR/TUTOR: ING. FABRICIO SÁNCHEZ, M. Sc.
ING. FABRICIO MEDINA, M. Sc.
INSTITUCIÓN: UNIVERSIDAD DE GUAYAQUIL
FACULTAD: CIENCIAS MATEMÁTICAS Y FÍSICAS
ESPECIALIDAD: INGENIERÍA EN SISTEMAS COMPUTACIONAL
GRADO OBTENIDO: TERCER NIVEL
FECHA DE PUBLICACIÓN:
Diciembre de 2017 No. DE PÁGINAS 89 PÁGINAS
ÁREAS TEMÁTICAS: TECNOLOGÍA DE INFORMACIÓN
PALABRAS CLAVES / KEYWORDS:
WEB SERVICES, MICROSERVICIOS, JAVA, ARQUITECTURA, RESTFUL.
RESUMEN/ABSTRACT:
El presente proyecto consiste en la creación e implementación de una arquitectura de microservicios tipo REST utilizando el lenguaje JAVA para su implementación, manejando el estándar JSON para el intercambio de información, los microservicios creados serán utilizados por la aplicación Health Monitor UG la cual está construida para la plataforma Android. Esta aplicación móvil permitirá a las personas que sufren de la enfermedad del asma y la enfermedad de la diabetes llevar un mejor control de su salud. Para la publicación de los microservicios se utilizará el servidor de aplicaciones WildFly logrando alcanzar un alto rendimiento en la aplicación.
ADJUNTO PDF: SI NO
CONTACTO CON AUTOR: Teléfono: 0990578943 E-mail: [email protected]
CONTACTO CON LA INSTITUCIÓN:
Nombre: AB. JUAN CHÁVEZ ATOCHA
Teléfono: 2307729
E-mail: [email protected]
X
II
CARTA DE APROBACIÓN DEL TUTOR
En mi calidad de Tutor del trabajo de titulación, “SISTEMA DE
AUTOGESTIÓN DE LA SALUD PARA PACIENTES CON DIABETES Y
ASMA, DESARROLLADO E IMPLEMENTADO EN UNA PLATAFORMA
ANDROID; CON MONITOREO DE UNA APLICACIÓN WEB EN PHP
DIRIGIDA A LOS MÉDICOS TRATANTES, ENFOCADO EN EL DISEÑO E
IMPLEMENTACIÓN DE UNA ARQUITECTURA DE MICROSERVICIOS
USANDO TECNOLOGÍA JAVA PARA LA INTEGRACIÓN DE LA
PLATAFORMA ANDROID CON LA BASE DE DATOS MYSQL“ elaborado
por el Sr. Jordy Luis Peñaloza Bravo, Alumno no titulado de la Carrera
de Ingeniería en Sistemas Computacionales, Facultad de Ciencias
Matemáticas y Físicas de la Universidad de Guayaquil, previo a la
obtención del Título de Ingeniero en Sistemas, me permito declarar que
luego de haber orientado, estudiado y revisado, la Apruebo en todas sus
partes.
Atentamente
Ing. Fabricio Sánchez
TUTOR
III
DEDICATORIA
Le dedico este logro a mi
familia en especial a mi
madre que me ha brindado
todo su apoyo incondicional
en todo el largo tiempo que
ha durado este proceso.
A mi padre que, aunque no
esté conmigo el guía mis
pasos desde el cielo.
Ustedes dos han sido un pilar
fundamental en mi vida.
IV
AGRADECIMIENTO
Agradezco en primer lugar a
Dios por llenarme de
bendiciones, fortaleza y
haberme permitido llegar
hasta este día.
Le agradezco a todas las
personas que me apoyaron
desde el inicio de mi carrera,
a mi enamorada Priscila del
Pezo por haberme brindado
todo su apoyo y ánimo
cuando más lo necesitaba.
V
TRIBUNAL PROYECTO DE TITULACIÓN
Ing. Eduardo Santos Baquerizo, M. Sc.
DECANO DE LA FACULTAD
CIENCIAS MATEMATÍCAS Y
FÍSICAS
Ing. Abel Alarcón Salvatierra, M. Sc.
DIRECTOR DE LA CARRERA DE
INGENIERÍA EN SISTEMAS
COMPUTACIONALES
Ing. Fabricio Sánchez, M. Sc.
PROFESOR TUTOR DEL
PROYECTO DE TITULACIÓN
Ing. Fabricio Medina, MDPR.
PROFESOR REVISOR DEL ÁREA -
TRIBUNAL
Ab. Juan Chávez Atocha,
SECRETARIO
DE TITULACIÓN
VI
DECLARACIÓN EXPRESA
“La responsabilidad del contenido de este
Proyecto de Titulación, me corresponden
exclusivamente; y el patrimonio intelectual
de la misma a la UNIVERSIDAD DE
GUAYAQUIL”
Jordy Luis Peñaloza Bravo
C.I.: 0930566252
VII
UNIVERSIDAD DE GUAYAQUIL
FACULTAD DE CIENCIAS MATEMÁTICAS Y FÍSICAS
CARRERA DE INGENIERÍA EN SISTEMAS COMPUTACIONALES
SISTEMA DE AUTOGESTIÓN DE LA SALUD PARA PACIENTES CON
DIABETES Y ASMA, DESARROLLADO E IMPLEMENTADO EN UNA
PLATAFORMA ANDROID; CON MONITOREO DE UNA APLICACIÓN
WEB EN PHP DIRIGIDA A LOS MÉDICOS TRATANTES, ENFOCADO
EN EL DISEÑO E IMPLEMENTACIÓN DE UNA ARQUITECTURA
DE MICROSERVICIOS USANDO TECNOLOGÍA JAVA PARA LA
INTEGRACIÓN DE LA PLATAFORMA ANDROID CON
LA BASE DE DATOS MYSQL.
Proyecto de Titulación que se presenta como requisito para optar por el título de
INGENIERO EN SISTEMAS COMPUTACIONALES
Auto/a: JORDY LUIS PEÑALOZA BRAVO
C.I. 0930566252
Tutor: Ing. Fabricio Sánchez
Guayaquil, diciembre del 2017
VIII
CERTIFICADO DE ACEPTACIÓN DEL TUTOR
En mi calidad de Tutor del proyecto de titulación, nombrado por el Consejo
Directivo de la Facultad de Ciencias Matemáticas y Físicas de la
Universidad de Guayaquil.
CERTIFICO:
Que he analizado el Proyecto de Titulación presentado por el estudiante
JORDY LUIS PEÑALOZA BRAVO, como requisito previo para optar por el
título de Ingeniero en Sistemas Computacionales cuyo problema es:
SISTEMA DE AUTOGESTIÓN DE LA SALUD PARA PACIENTES CON
DIABETES Y ASMA, DESARROLLADO E IMPLEMENTADO EN UNA
PLATAFORMA ANDROID; CON MONITOREO DE UNA APLICACIÓN
WEB EN PHP DIRIGIDA A LOS MÉDICOS TRATANTES, ENFOCADO
EN EL DISEÑO E IMPLEMENTACIÓN DE UNA ARQUITECTURA
DE MICROSERVICIOS USANDO TECNOLOGÍA JAVA PARA LA
INTEGRACIÓN DE LA PLATAFORMA ANDROID CON
LA BASE DE DATOS MYSQL.
Considero aprobado el trabajo en su totalidad.
Presentado por:
Peñaloza Bravo Jordy Luis C.I.: 0930566252
Tutor: Ing. Fabricio Sánchez
Guayaquil, diciembre del 2017
IX
UNIVERSIDAD DE GUAYAQUIL
FACULTAD DE CIENCIAS MATEMÁTICAS Y FÍSICAS
CARRERA DE INGENIERÍA EN SISTEMAS COMPUTACIONAL
Autorización para Publicación de Proyecto de Titulación en Formato
Digital
1. Identificación del Proyecto de Titulación
Nombre Alumno: JORDY LUIS PEÑALOZA BRAVO
Dirección: Coop. Libertad Mz. Ñ Sl. 8
Teléfono: 0990578943 E-mail: [email protected]
Facultad: Ciencias Matemáticas y Físicas
Carrera: Ingeniería en Sistemas Computacionales
Proyecto de titulación al que opta: Ingeniero en Sistemas
Computacionales
Profesor tutor: Ing. Fabricio Sánchez
Título del Proyecto de titulación: “Sistema de autogestión de la salud
para pacientes con diabetes y asma, desarrollado e implementado en una
plataforma android; con monitoreo de una aplicación web en php dirigida
a los médicos tratantes, enfocado en el diseño e implementación de una
arquitectura de microservicios usando tecnología java para la integración
de la plataforma android con la base de datos MySQL.”
X
Tema del Proyecto de Titulación: Web Services, Microservicios, Java,
Arquitectura, RESTful.
2. Autorización de Publicación de Versión Electrónica del Proyecto
de Titulación
A través de este medio autorizo a la Biblioteca de la Universidad de
Guayaquil y a la Facultad de Ciencias Matemáticas y Físicas a publicar la
versión electrónica de este Proyecto de titulación.
Publicación electrónica:
Inmediata X Después de 1 año
Firma Alumno:
3. Forma de envío: El texto del proyecto de titulación debe ser enviado en formato Word, como archivo .Doc. O .RTF y. Puf para PC. Las imágenes que la acompañen pueden ser: .gif, .jpg o .TIFF.
DVDROM CDROM
XI
ÍNDICE GENERAL
CARTA DE APROBACIÓN DEL TUTOR ................................................... II
DEDICATORIA ......................................................................................... III
AGRADECIMIENTO ................................................................................. IV
TRIBUNAL PROYECTO DE TITULACIÓN ................................................ V
DECLARACIÓN EXPRESA ...................................................................... VI
CERTIFICADO DE ACEPTACIÓN DEL TUTOR .................................... VIII
ÍNDICE GENERAL .................................................................................... XI
ABREVIATURAS ................................................................................... XIV
ÍNDICE DE CUADROS ........................................................................... XV
ÍNDICE DE GRÁFICOS ........................................................................ XVII
ÍNDICE DE ILUSTRACIONES ............................................................. XVIII
INTRODUCCIÓN ....................................................................................... 1
CAPÍTULO I ............................................................................................... 4
EL PROBLEMA .......................................................................................... 4
PLANTEAMIENTO DEL PROBLEMA ........................................................ 4
UBICACIÓN DEL PROBLEMA EN UN CONTEXTO ................................. 4
SITUACIÓN CONFLICTO. NUDOS CRÍTICOS ......................................... 5
CAUSAS Y CONSECUENCIAS DEL PROBLEMA .................................... 5
DELIMITACIÓN DEL PROBLEMA ............................................................. 6
FORMULACIÓN DEL PROBLEMA ............................................................ 6
EVALUACIÓN DEL PROBLEMA ............................................................... 7
ALCANCES DEL PROBLEMA ................................................................... 8
OBJETIVOS DE LA INVESTIGACIÓN ...................................................... 9
OBJETIVO GENERAL ............................................................................... 9
OBJETIVOS ESPECÍFICOS ...................................................................... 9
JUSTIFICACIÓN E IMPORTANCIA ........................................................... 9
CAPÍTULO II ............................................................................................ 12
MARCO TEÓRICO .................................................................................. 12
ANTECEDENTES DEL ESTUDIO ........................................................... 12
XII
FUNDAMENTACIÓN TEÓRICA .............................................................. 13
DEFINICIÓN DE MICROSERVICIOS ...................................................... 13
BENEFICIOS DE UNA ARQUITECTURA DE MICROSERVICIOS ......... 14
SOA ......................................................................................................... 15
WEB SERVICES ...................................................................................... 16
SOAP ....................................................................................................... 17
REST ....................................................................................................... 18
REST VS SOAP ....................................................................................... 19
XML ......................................................................................................... 22
JSON ....................................................................................................... 23
XML VS JSON ......................................................................................... 24
SERVIDOR WEB ..................................................................................... 25
WILDFLY ................................................................................................. 26
LENGUAJE JAVA .................................................................................... 27
LIBRERÍA LOG4J .................................................................................... 28
LIBRERÍA JAX-RS ................................................................................... 30
LIBRERÍA JAVAX.MAIL ........................................................................... 31
PEAK FLOW ............................................................................................ 31
FUNDAMENTACIÓN SOCIAL ................................................................. 31
FUNDAMENTACION LEGAL ................................................................... 31
IDEA A DEFENDER ................................................................................ 40
CAPÍTULO III ........................................................................................... 41
METODOLOGÍA ...................................................................................... 41
DISEÑO DE LA INVESTIGACIÓN ........................................................... 41
MODALIDAD DE LA INVESTIGACIÓN ................................................... 41
TIPOS DE INVESTIGACIÓN ................................................................... 41
METODOLOGÍA DE DESARROLLO ....................................................... 41
POBLACIÓN ............................................................................................ 42
MUESTRA ............................................................................................... 43
TÉCNICA DE RECOLECCIÓN DE DATOS ............................................. 43
ENCUESTA ............................................................................................. 43
XIII
CAPÍTULO IV ........................................................................................... 49
PROPUESTA TECNOLÓGICA ................................................................ 49
HERRAMIENTAS UTILIZADAS ............................................................... 49
MICROSERVICIOS ................................................................................. 53
ANÁLISIS DE FACTIBILIDAD .................................................................. 75
FACTIBILIDAD OPERACIONAL .............................................................. 75
FACTIBILIDAD TÉCNICA ........................................................................ 76
FACTIBILIDAD LEGAL ............................................................................ 77
FACTIBILIDAD ECONÓMICA.................................................................. 77
ETAPAS DE LA METODOLOGÍA DEL PROYECTO ............................... 78
ENTREGABLES DEL PROYECTO ......................................................... 78
CRITERIOS DE VALIDACIÓN DE LA PROPUESTA .............................. 81
CRITERIOS DE ACEPTACIÓN DEL PRODUCTO O SERVICIO ............ 82
CONCLUSIONES Y RECOMENDACIONES ........................................... 85
CONCLUSIONES .................................................................................... 85
RECOMENDACIONES ............................................................................ 86
BIBLIOGRAFÍA ........................................................................................ 87
XIV
ABREVIATURAS
SQL Structured Query Language
HTTP Hypertext Transfer Protocol
JSON JavaScript Object Notation
API Application Protocol Interface
HTML Lenguaje de Marca de salida de Hyper Texto
HTTP Protocolo de transferencia de Hyper Texto
Ing. Ingeniero
WAR Web Application Archive
REST Representational State Transfer
URI Identificador de Recurso uniforme
JDBC Java Database Connectivity
OMS Organización Mundial de la Salud
XV
ÍNDICE DE CUADROS
Pág. CUADRO N° 1 ........................................................................................... 5
CAUSAS Y CONSECUENCIAS DEL PROBLEMA .................................... 5
CUADRO N° 2 ......................................................................................... 18
MÉTODOS HTTP .................................................................................... 18
CUADRO N° 3 ......................................................................................... 19
CÓDIGOS DE ESTADOS HTTP .............................................................. 19
CUADRO N° 4 ......................................................................................... 20
CARACTERÍSTICAS DE REST Y SOAP ................................................ 20
CUADRO N° 5 ......................................................................................... 21
COMPARACIÓN ENTRE REST Y SOAP ................................................ 21
CUADRO N° 6 ......................................................................................... 24
COMPARACIÓN ENTRE XML Y JSON .................................................. 24
CUADRO N° 7 ......................................................................................... 30
ANOTACIONES DEL API JAX-RS .......................................................... 30
CUADRO N° 8 ......................................................................................... 43
DISTRIBUCIÓN DE LA POBLACIÓN ...................................................... 43
CUADRO N° 9 ......................................................................................... 44
RESULTADO DE LA PREGUNTA 1 DE LA ENCUESTA ........................ 44
CUADRO N° 10 ....................................................................................... 45
RESULTADO DE LA PREGUNTA 2 DE LA ENCUESTA ........................ 45
CUADRO N° 11 ....................................................................................... 46
RESULTADO DE LA PREGUNTA 3 DE LA ENCUESTA ........................ 46
CUADRO N° 12 ....................................................................................... 47
RESULTADO DE LA PREGUNTA 4 DE LA ENCUESTA ........................ 47
CUADRO N° 13 ....................................................................................... 48
RESULTADO DE LA PREGUNTA 5 DE LA ENCUESTA ........................ 48
CUADRO N° 14 ....................................................................................... 76
HERRAMIENTAS DE SOFTWARE UTILIZADAS .................................... 76
CUADRO N° 15 ....................................................................................... 77
XVI
PRESUPUESTO DEL PROYECTO ......................................................... 77
CUADRO N° 16 ....................................................................................... 78
LISTADO DE MICROSERVICIOS ........................................................... 78
CUADRO N° 17 ....................................................................................... 82
CRITERIOS DE ACEPTACIÓN DEL PRODUCTO .................................. 82
XVII
ÍNDICE DE GRÁFICOS
Pág. GRÁFICO N° 1
RESULTADO DE LA PREGUNTA 1 DE LA ENCUESTA ........................ 44
GRÁFICO N° 2
RESULTADO DE LA PREGUNTA 2 DE LA ENCUESTA ........................ 45
GRÁFICO N° 3
RESULTADO DE LA PREGUNTA 3 DE LA ENCUESTA ........................ 46
GRÁFICO N° 4
RESULTADO DE LA PREGUNTA 4 DE LA ENCUESTA ........................ 47
GRÁFICO N° 5
RESULTADO DE LA PREGUNTA 5 DE LA ENCUESTA ........................ 48
XVIII
ÍNDICE DE ILUSTRACIONES
Pág.
ILUSTRACIÓN N° 1
ARQUITECURA DE MICROSERVICIOS ................................................ 13
ILUSTRACIÓN N°2
BENEFICIOS DE LOS MICROOSERVICIOS .......................................... 14
ILUSTRACIÓN N° 3
MANIFIESTO SOA .................................................................................. 15
ILUSTRACIÓN N° 4
WEB SERVICES SOAP ........................................................................... 16
ILUSTRACIÓN N° 5
ESTRUCTURA DE UN SERVICIO SOAP ............................................... 17
ILUSTRACIÓN N° 6
REST VS SOAP ....................................................................................... 19
ILUSTRACIÓN N° 7
XML ......................................................................................................... 22
ILUSTRACIÓN N° 8
JSON OBJECT ........................................................................................ 23
ILUSTRACIÓN N° 9
JSON OBJECT ........................................................................................ 23
ILUSTRACIÓN N° 10
ILUSTRACION DE UN SERVIDOR ......................................................... 25
ILUSTRACIÓN N° 11
PANTALLA DE BIENVENIDA WILDFLY 8 .............................................. 26
ILUSTRACIÓN N° 12
PRIMERA PÁGINA DESPUÉS DEL LOGGIN ......................................... 27
ILUSTRACIÓN N° 13
FASE DE COMPILACION DE UNA CLASE JAVA .................................. 28
XIX
ILUSTRACIÓN N° 14
NIVELES DE LOGGER ........................................................................... 29
ILUSTRACIÓN N° 15
HERRAMIENTA TRELLO ........................................................................ 42
ILUSTRACIÓN N° 16
LOGO DE ECLIPSE NEON ..................................................................... 49
ILUSTRACIÓN N° 17
EJEMPLO DE INTERFAZ PARA VALIDAR CUENTA
Y CONSULTAR PRESIÓN ...................................................................... 50
ILUSTRACIÓN N° 18
ENVÍO DE EMAIL CON EL PASSWORD ................................................ 50
ILUSTRACIÓN N° 19
CONFIGURACIÓN DE PROPERTIES LOG4J ........................................ 51
ILUSTRACIÓN N° 20
PROPIEDADES DEL DATASOURCE ..................................................... 51
ILUSTRACIÓN N° 21
WARS SUBIDOS AL SERVIDOR ............................................................ 52
ILUSTRACIÓN N° 22
SERVICIO PARA CONSULTAR SÍNTOMAS DE ASMA ......................... 53
ILUSTRACIÓN N° 23
SERVICIO PARA CONSULTAR DESENCADENANTES DE ASMA ....... 54
ILUSTRACIÓN N° 24
SERVICIO PARA REGISTRAR LA LECTURA DE PEAK FLOW ............ 55
ILUSTRACIÓN N° 25
SERVICIO PARA CONSULTAR EL HISTORIAL DE PEAK FLOW ......... 56
ILUSTRACIÓN N° 26
SERVICIO PARA REGISTRAR LA MEDICACIÓN .................................. 57
ILUSTRACIÓN N° 27
SERVICIO PARA ACTUALIZAR LA MEDICACIÓN ................................. 58
ILUSTRACIÓN N° 28
SERVICIO PARA REGISTRAR LA ALARMA .......................................... 59
XX
ILUSTRACIÓN N° 29
SERVICIO PARA CONSULTAR LAS ALARMAS .................................... 60
ILUSTRACIÓN N° 30
SERVICIO PARA EL REGISTRO DEL CONTROL DE MEDICACIÓN .... 61
ILUSTRACIÓN N° 31
SERVICIO PARA CONSULTAR LOS REGISTROS DEL CONTROL ..... 62
ILUSTRACIÓN N° 32
PANTALLA DE REGISTROS DE PEAK FLOW ....................................... 63
ILUSTRACIÓN N° 33
PANTALLA DE INGRESO DE LECTURA DE PEAK FLOW .................... 64
ILUSTRACIÓN N° 34
PANTALLA DE SELECCIÓN DE SINTOMAS ......................................... 65
ILUSTRACIÓN N° 35
PANTALLA DE SELECCIÓN DE LOS DESENCADENANTES ............... 66
ILUSTRACIÓN N° 36
PANTALLA DONDE SE CONSULTA LAS ESTADÍSTICAS DEL ASMA . 67
ILUSTRACIÓN N° 37
PANTALLA DE REGISTROS DE MEDICINAS ........................................ 68
ILUSTRACIÓN N° 38
PANTALLA DE SELECCION DE MEDICAMENTOS ............................... 69
ILUSTRACIÓN N° 39
PANTALLA DE CONFIGURACIÓN DE ALARMA .................................... 70
ILUSTRACIÓN N° 40
PANTALLA DE CONSULTA DE ALARMAS ............................................ 71
ILUSTRACIÓN N° 41
PANTALLA DE ALARMA ......................................................................... 72
ILUSTRACIÓN N° 42
PANTALLA DE MEDICAMENTOS TOMADOS POR EL PACIENTE ...... 73
ILUSTRACIÓN N° 43
PANTALLA DE ESTADÍSTICAS DE MEDICINAS ................................... 74
XXI
UNIVERSIDAD DE GUAYAQUIL
FACULTAD DE CIENCIAS MATEMÁTICAS Y FÍSICAS
CARRERA DE INGENIERÍA EN SISTEMAS COMPUTACIONALES
SISTEMA DE AUTOGESTIÓN DE LA SALUD PARA PACIENTES CON
DIABETES Y ASMA, DESARROLLADO E IMPLEMENTADO EN UNA
PLATAFORMA ANDROID; CON MONITOREO DE UNA APLICACIÓN
WEB EN PHP DIRIGIDA A LOS MÉDICOS TRATANTES, ENFOCADO
EN EL DISEÑO E IMPLEMENTACIÓN DE UNA ARQUITECTURA
DE MICROSERVICIOS USANDO TECNOLOGÍA JAVA PARA LA
INTEGRACIÓN DE LA PLATAFORMA ANDROID CON
LA BASE DE DATOS MYSQL.
RESUMEN
El presente proyecto consiste en la creación e implementación de una
arquitectura de microservicios tipo REST utilizando el lenguaje JAVA para
su implementación, manejando el estándar JSON para el intercambio de
información, los microservicios creados serán utilizados por la aplicación
Health Monitor UG la cual está construida para la plataforma Android. Esta
aplicación móvil permitirá a las personas que sufren de la enfermedad del
asma y la enfermedad de la diabetes llevar un mejor control de su salud.
Para la publicación de los microservicios se utilizará el servidor de
aplicaciones WildFly logrando alcanzar un alto rendimiento en la aplicación.
Palabras claves: web services, microservicios, java, arquitectura, restful.
Autor: Jordy Luis Peñaloza Bravo
Tutor: Ing. Fabricio Sánchez
XXII
UNIVERSIDAD DE GUAYAQUIL
FACULTAD DE CIENCIAS MATEMATICAS Y FISICAS
CARRERA DE INGENIERIA EN SISTEMAS COMPUTACIONALES
HEALTH SELF-MANAGEMENT SYSTEM FOR PATIENTS WITH
DIABETES AND ASTHMA, DEVELOPED AND IMPLEMENTED ON AN
ANDROID PLATFORM; WITH MONITORING OF A WEB APPLICATION
IN PHP DIRECTED TO TREATING PHYSICIANS, FOCUSED ON THE
DESIGN AND IMPLEMENTATION OF A MICROSERVICE
ARCHITECTURE USING JAVA TECHNOLOGY FOR THE
INTEGRATION OF THE ANDROID PLATFORM WITH
THE MYSQL DATABASE.
ABSTRACT
The present project consists of the creation and implementation of a REST
micro services architecture using the JAVA language for its implementation,
handling the JSON standard for the exchange of information, the micro
services created will be used by the Health Monitor UG application, which
is built for the Android platform. This mobile application will enable people
suffering from asthma disease and diabetes disease to take better control
of their health. For the publication of the micro services will be used the
application server WildFly achieving a high performance in the application.
Keywords: web services, microservices, java, architecture, restful.
Autor: Jordy Luis Peñaloza Bravo Tutor: Ing. Fabricio Sánchez
1
INTRODUCCIÓN
El paradigma de los microservicios nace por la necesidad de mejorar las
arquitecturas de las aplicaciones monolíticas, es decir aplicaciones cuya
funcionalidad se encuentran contenidas en un solo proceso, en una misma
aplicación, por lo que al querer agregar nuevas funcionalidades o dar
mantenimiento a las funcionalidades existentes puede haber cierta
complejidad por las dependencias que pueden llegar a tener este tipo de
arquitecturas de software.
Debido a esto la forma de crear una arquitectura de software ha ido
evolucionando, siendo la arquitectura de microservicios una de las
opciones creadas para mejorar las arquitecturas monolíticas, pero de
seguro se preguntarán ¿Qué diferencias podemos encontrar en una
arquitectura de microservicios con respecto a una arquitectura monolítica?
Bueno la respuesta a esta interrogante es la siguiente.
Una arquitectura de microservicios a diferencia de una arquitectura
monolítica, da un enfoque a que los procesos de nuestra aplicación se
comporten como conjunto de servicios más pequeños los cuales por lo
general se exponen mediante los protocolos HTTP. Lo que caracteriza a
cada uno de estos microservicios es que cada uno tiene una funcionalidad
muy bien definida independiente de otros microservicios lo que permite una
mayor escalabilidad y fácil mantenimiento de los mismos.
Por esta y otras razones hemos decidido implementar este tipo de
arquitectura en nuestra aplicación Health Monitor UG, para que su
arquitectura sea escalable y de fácil acoplamiento y mantenimiento de los
módulos de nuestra aplicación.
2
Health Monitor UG es una aplicación desarrollada para dispositivos móviles
con sistema operativo Android, la cual nos va a permitir llevar un control de
registro y monitoreo por parte de un médico tratante, las enfermedades de
diabetes tipo 1, diabetes tipo 2, diabetes gestacional y de la enfermedad
respiratoria conocida como el asma.
La tecnología que se usará para la construcción de los microservicios será
el lenguaje de programación JAVA exponiendo los microservicios mediante
una arquitectura tipo RESTful usando el protocolo HTTP, usando como
servidor de aplicación el servidor WildFly donde estarán alojados los WARS
de nuestros microservicios, el intercambio de información se los hará en
formato JSON el cual es un formato de texto muy ligero que se lo utiliza
para el intercambio de información. Para el almacenamiento de la
información del paciente se utilizará el sistema de gestión de base de datos
MySQL el cual es sistema de gestión de base de datos relacional.
El presente trabajo de titulación está divido en 4 capítulos:
En el capítulo I, se describen las razones que nos condujeron a crear los
microservicios para la arquitectura de la aplicación Health Monitor UG,
cómo afectan a la población ecuatoriana las enfermedades tales como la
diabetes tipo 1, diabetes tipo2, diabetes gestacional y el asma, y la
necesidad de tener una herramienta para llevar el control de las mismas.
En el capítulo II, se describen las razones por las cuales escogimos el
lenguaje JAVA para desarrollar los microservicios, el servidor de
aplicaciones, la tecnología utilizada y los microservicios creados para la
construcción de la aplicación móvil.
En el capítulo III, se explica de qué forma se obtuvieron los datos para
poner a prueba los microservicios creados para la aplicación Health Monitor
3
UG, los instrumentos que me permitieron recolectar información, y la
metodología de Investigación que se utilizó.
En el capítulo IV, se describen las razones por las cuales utilizamos el IDE
de desarrollo escogido para la creación de los microservicios, así como el
análisis de factibilidad operacional, económica, legal y para finalizar se
darán las conclusiones y las recomendaciones a tener en cuenta.
4
CAPÍTULO I
EL PROBLEMA
PLANTEAMIENTO DEL PROBLEMA
Ubicación del Problema en un Contexto
Según estudios realizados por el Instituto Nacional de Estadísticas y
Censos (INEC) en el año 2013 las principales causas de muertes en el
Ecuador fueron por las enfermedades hipertensivas y la diabetes mellitus,
siendo en las mujeres la principal causa de muerte la enfermedad de la
diabetes. (INEC, ecuadorencifras, 2014).
Por otra parte, el asma es una enfermedad crónica cuya principal
característica son los ataques recurrentes de falta de aire y según la OMS
(Organización Mundial de Salud) es una de las enfermedades más común
entre niños y afecta alrededor de 235 millones de personas en todo el
mundo. (OMS, 2013).
En el País, las principales causas para padecer de diabetes son el
sobrepeso y la obesidad, esto se debe a una falta de conciencia y de una
baja cultura en el tema de la salud. Según estadísticas del INEC en el 2013
fallecieron 4600 personas por esta enfermedad, mientras que el asma casi
el 50% de los casos tiene un origen genético, pero existen factores externos
que ayudan a desarrollar la enfermedad como son el polvo, los químicos o
el frío.
5
Si no se lleva un control adecuado de estas enfermedades la tasa de
mortalidad aumentará considerablemente en los próximos años, por
ejemplo, la OMS pronostica que si no se lleva un control de la enfermedad
del asma las muertes por esta enfermedad aumentarán en un 20% en los
próximos 10 años.
Por este motivo se desea crear una aplicación móvil para el control y
monitoreo de estas enfermedades con una arquitectura de microservicios
que le permita a la aplicación tener un mejor rendimiento y fácil
mantenimiento para brindarle al usuario una herramienta amigable y
cómoda aprovechando el auge del uso de los dispositivos móviles y que las
personas, así como los médicos tratantes tengan un mejor control y
monitoreo de la enfermedad de sus pacientes.
Situación Conflicto. Nudos Críticos
Con el presente trabajo de titulación se pretende crear una herramienta
cómoda y de fácil uso que les permita a las personas llevar un mejor control
y registro de su enfermedad ya sea esta diabetes o asma y con esto evitar
que exista un descuido en el control de la salud del paciente.
Causas y Consecuencias del Problema
CUADRO N° 1
CAUSAS Y CONSECUENCIAS DEL PROBLEMA
Causas Consecuencias
No contar con un
aplicativo móvil que
nos ayude a llevar un
control de la
enfermedad del asma
El paciente tendrá que asistir constantemente
a su médico para poder tener una evaluación
de su estado de salud desaprovechando el
tiempo que puede ocupar en otras
actividades.
6
No implementar una
arquitectura de
microservicios en la
aplicación Health
Monitor UG
Mayor costo al querer implementar el proyecto
en varias plataformas ya que se genera una
dependencia en cierta tecnología.
No separar la capa de
presentación de la
lógica de negocio
Aumento de complejidad al querer hacer un
mantenimiento en la aplicación.
No llevar un control de
las transacciones de
los microservicios
No poder ejecutar un Troubleshooting cuando
los servicios no están funcionando
correctamente.
Elaborado por: Jordy Peñaloza Bravo
Fuente: Datos de la Investigación
Delimitación del Problema Campo: Tecnologías de la información y la comunicación.
Área: Web Services – Arquitectura de microservicios tipo REST
Aspecto: Salud
Sistema de autogestión de la salud para pacientes con diabetes y asma,
desarrollado e implementado en una plataforma Android; con monitoreo de
una aplicación web en PHP dirigida a los médicos tratantes, enfocado en el
diseño e implementación de una arquitectura de microservicios usando
tecnología JAVA para la integración de la plataforma Android con la base
de datos MySQL.
Formulación del Problema
¿De qué forma una arquitectura de microservicios para la aplicación Health
Monitor UG beneficiará a las personas que padecen de la enfermedad
conocida como diabetes tipo 1, diabetes tipo 2, diabetes gestacional y de
asma a llevar un mejor control de su enfermedad?
7
Evaluación del Problema
Los siguientes aspectos han sido tomados para la evaluación del problema:
Delimitado: El problema radica en el aumento de las personas que
padecen de diabetes en el Ecuador según ENSANUT (Encuesta Nacional
de Salud y Nutrición) 1 de cada 10 ecuatorianos en los que su edad está
comprendida entre los 50 y 59 años padecen de diabetes debido a sus
malos hábitos alimenticios (paho, 2014).
Por otra parte, el asma es una enfermedad crónica cuya principal
característica son los ataques recurrentes de falta de aire y según la OMS
(Organización Mundial de Salud) es una de las enfermedades más común
entre niños y afecta alrededor de 235 millones de personas en todo el
mundo. (OMS, 2013).
Por tal motivo se pretende crear un aplicativo móvil para que el paciente
pueda registrar actualizar y tener disponible la consulta de la información
registrada por él, y así pueda llevar un mejor control de su enfermedad ya
sea esta la diabetes o el asma.
Claro: Lo que se busca en este estudio es poder crear una aplicación móvil
para que los pacientes que padecen de la enfermedad del asma o de la
diabetes puedan contar con una herramienta que les ayude a llevar un
monitoreo de varios parámetros de su salud para tener un mejor control de
su enfermedad.
Evidente: La diabetes y el asma son dos enfermedades que van en
aumento en el país por lo tanto es necesario contar con una herramienta
que les permita a las personas que padecen estas enfermedades llevar un
mejor estilo de vida cuidando su salud.
8
Relevante: El paciente necesita poder enviar los resultados de sus
exámenes a su médico tratante lo cual le permitirá ahorrar tiempo y dinero.
Original: En la actualidad no existen muchas herramientas que permitan a
las personas llevar un mejor control de estas enfermedades, por lo tanto,
esta propuesta tecnológica ayudará a las personas a llevar una mejor
calidad de vida.
Factible: Con las herramientas Open Source que existen en la actualidad
se podrán construir los microservicios que nos ayudarán a dar una solución
a este problema que afectan a las personas que sufren estas
enfermedades.
Alcances del problema
Al analizar el proyecto con respecto al problema se definieron los siguientes
alcances:
Se crearán los microservicios necesarios para poder guardar, actualizar y
consultar los datos de Peak Flow, medicación, control de medicación y alarmas
de medicina del paciente para poder llevar un control de la enfermedad del asma.
Se aplicará reingeniería a las APIS de integración existentes para registro,
actualización y consulta de glucosa, registro de paciente, administración de
doctores, notificaciones y exámenes complementarios para que se puedan
integrar con las APIS de control del asma.
Los microservicios serán construidos en una arquitectura tipo REST usando como
lenguaje de programación el lenguaje JAVA.
La información que el paciente ingrese a través del aplicativo Health Monitor UG
se registrará en el SGBD MySQL.
La conexión de los microservicios hacia la base de datos se la realizará por medio
de DataSource.
Se usará el Servidor de Aplicaciones WildFly para alojar los microservicios.
Las transacciones realizadas por los microservicios quedarán registradas en Logs
9
para futuros análisis o auditorias hacia los microservicios.
OBJETIVOS DE LA INVESTIGACIÓN
Objetivo general
Diseñar una arquitectura de microservicios mediante el uso de tecnología
JAVA permitiendo la integración de la plataforma Android con la base de
datos MySQL para que los pacientes que padecen de la enfermedad del
asma puedan registrar, consultar y actualizar los datos relacionados a su
enfermedad.
Objetivos específicos
1. Crear las APIS con una arquitectura tipo REST que permitan
registrar, consultar y actualizar datos del asma para que los
pacientes puedan llevar un mejor control de su enfermedad.
2. Reestructurar las APIS de registro, consulta y actualización
existentes para el control de la diabetes para que permita la
integración con las APIS de la enfermedad del asma.
3. Cambiar los Métodos HTTP de GET a POST para registro, consulta
y actualización de las APIS de integración de la diabetes para no
exponer la información del paciente.
4. Usar una arquitectura tipo REST usando el formato de texto JSON
(JavaScript Object Notation) para el envío y recepción de datos.
JUSTIFICACIÓN E IMPORTANCIA
La diabetes es una enfermedad que está afectando a la población
ecuatoriana, el sobrepeso es la principal causa de este mal y esto se debe
10
a los malos hábitos alimenticios de las personas.
Por otra parte, el asma es una enfermedad que afecta al sistema
respiratorio, el 50% de los casos tienen un origen genético, en el país está
enfermad afecta al 10% de la población infantil, comprendida entre los 13
y 14 años.
Si no se lleva un control de estas enfermedades la tasa de mortalidad
aumentará considerablemente en los próximos años. He aquí la
importancia de poder contar con un aplicativo móvil que le facilite a las
personas que padecen estos males poder llevar un mejor control y
monitoreo de su enfermedad.
El número de aplicaciones móviles van en aumento al igual que el uso de
teléfonos inteligentes (smartphones), por lo tanto, las personas que
padecen estas enfermedades se les hace más accesible utilizar una
herramienta como es su teléfono celular que ir constantemente a su
médico.
Contar con una herramienta móvil beneficiará mucho a los pacientes que
padecen de diabetes o asma porque ya no tendrán que ir constantemente
a un especialista por lo que ahorrarán tiempo y dinero además el médico
puede llevar un control de manera remota de los datos que el paciente
ingresa y enviar notificaciones al paciente en el caso que lo requiera.
El tener un sistema con una mala arquitectura que no le permita ser
escalable puede hacer que su mantenimiento sea insostenible al querer
agregar nuevas características o funcionalidades y por lo tanto será un
sistema que tiende a la entropía.
Las arquitecturas monolíticas son arquitecturas que se dificultan al
momento de realizar algún tipo de mantenimiento ya que el cambio en una
11
parte del sistema puede originar un fallo en otro componente.
La ventaja de usar una arquitectura de microservicios es la independencia
entre sus componentes lo que facilita el mantenimiento de los mismo y
permitirá tener una arquitectura escalable lo que permitirá el crecimiento
del sistema.
Los costos de mantenimiento de este tipo de arquitectura son menores en
comparación de una arquitectura monolítica. En la actualidad existen
herramientas open sources que nos facilitan la implementación como son
eclipse, netbeans o servidores como apache tomcat o wildfly los cuales
tienen características premium pero su uso es gratuito.
Si se aplica una arquitectura de microservicios para la aplicación Health
Monitor UG aumentará la eficiencia en el procesamiento para registrar la
información de los datos del paciente que padezcan la enfermedad del
asma o la diabetes desde la aplicación hacia la base de datos por lo que
la experiencia del usuario al usar el aplicativo móvil será gratificante.
12
CAPÍTULO II
MARCO TEÓRICO
ANTECEDENTES DEL ESTUDIO
La investigación parte de una investigación previa realizada por varios
alumnos de la carrera de Ingeniería en Sistemas de la Universidad de
Guayaquil, cuyo proyecto tenía como nombre “Proyecto App Salud
Control”.
Aquel proyecto tenía como objetivo crear una aplicación móvil que le
permita a las personas que padecen de la enfermedad de la diabetes poder
llevar un control de su enfermedad permitiéndole al paciente registrar varios
datos de su estado de salud entre esos datos se encontraban mediciones
de insulina, presión, estado de ánimo, glucosa, triglicéridos, alimentos,
medicina, exámenes complementarios entre otras opciones.
Además, contaba con un aplicativo web donde el doctor que tenía asociado
el paciente podía ver los datos que el paciente había registrado además
enviar notificaciones en el caso de que sean necesarias.
La diabetes, así como el asma son dos enfermedades que afectan a gran
parte de la población ecuatoriana, entre los principales causantes de este
mal se encuentra el sobre peso y la obesidad, los malos hábitos
alimenticios de los ecuatorianos han provocado que el número de personas
que padecen esta enfermedad haya aumentado con los años.
13
Según estudios realizados por el Instituto Nacional de Estadística y Censos
(INEC) en el año 2016 la diabetes fue la segunda Causa de mortalidad en
las mujeres con 2.628 casos de fallecimiento mientras que en los hombres
fue el tercero con 2.278 casos registrados (INEC, ecuadorencifras, 2016).
Siguiendo los mismos objetivos de la investigación realizada por nuestros
compañeros se pretende agregar nuevas funcionalidades a su aplicación
permitiendo entre otras cosas poder llevar un control del asma, así como
mejorar los procesos actuales que existen para el control de la diabetes.
FUNDAMENTACIÓN TEÓRICA Definición de microservicios
Los microservicios son componentes completamente independientes unos
de otros pero que pueden trabajar juntos y su forma de comunicación es a
través del intercambio de mensajes. Cada uno de estos componentes
tienen su propia funcionalidad y sus principales características es que se
pueden deployar individualmente sin afectar a los demás, son pequeños y
descentralizados (Nadareishvili, 2016).
ILUSTRACIÓN N° 1
ARQUITECURA DE MICROSERVICIOS
Fuente: http://dspace.redclara.net
Elaborado por: Daniel Lopez y Edgar Maya
14
Beneficios de una arquitectura de microservicios
Entre las ventajas de implementar una arquitectura de micro servicios
podemos encontrar las siguientes:
• Escalamiento de forma independiente manteniendo la disponibilidad
del sistema asegurando la escalabilidad y la disponibilidad.
• Disminuye la dependencia
• Permite ejecutar micro servicios en paralelo
• Se pueden implementar en diferentes tecnologías
• Se pueden implementar módulos redundantes.
• El tiempo de desarrollo se disminuye considerablemente.
ILUSTRACIÓN N°2
BENEFICIOS DE LOS MICROOSERVICIOS
Fuente: http://dspace.redclara.net
Elaborado por: Daniel Lopez y Edgar Maya
15
SOA
SOA proviene de las siglas en inglés Services Oriented Architecture que en
español significa Arquitectura Orientada a Servicios y como su nombre lo
indica es un estilo de arquitectura de software que se basa en la orientación
a servicios y una de sus principales características es que permite construir
sistemas con una alta posibilidad de escalabilidad además permite la
reutilización para integrarse con diferentes aplicaciones (Dhara, 2015).
SOA se basa en las comunicaciones sin estado Conocidas como servicios,
un servicio no es más que un componente que puede ser reutilizado más
de una vez por diferentes aplicaciones, para esto SOA para poder lograr
estas comunicaciones hace uso de una herramienta conocida como Web
Services.
SOA se rige por los principios de su manifiesto el cual está publicado en su
sitio web (SOA, 2009)
ILUSTRACIÓN N° 3
MANIFIESTO SOA
Fuente: soa-manifesto
Elaborado por: Jordy Peñaloza Bravo
16
Web Services
Los Web Services son servicios que permiten la interacción y comunicación
entre dos máquinas en una red (generalmente internet) y son ejecutados
por el sistema que los almacena (González, 2015).
El caso más común del uso de Web Services se refleja en las
comunicaciones clientes servidor haciendo uso del lenguaje XML siguiendo
el estándar SOAP.
Los Servicios web no depende de una tecnología especifica ya que se
pueden construir en un lenguaje de programación y ser consumidos por
aplicaciones construidas en cualquier otro lenguaje esto es posible ya que
se usa un estándar abierto conocido como XML
La comunicación de los servicios Web basados en SOAP por lo general es
vía HTTP el sistema que aloja el servicio web recibe el mensaje lo interpreta
realiza la tarea que debe hacer y devuelve una respuesta en otro mensaje
tipo SOAP.
ILUSTRACIÓN N° 4
WEB SERVICES SOAP
Fuente: ibm: ws-understand-web-services1
Elaborado por: Jordy Peñaloza Bravo
17
SOAP
El protocolo simple de acceso a objetos (SOAP) es un protocolo estándar
desarrollado por IBM, MICROSOFT entre otros, que define como se
pueden comunicar dos objetos mediante el intercambio de mensajes en
formato XML usando el protocolo HTTP, SMTP, entre otros (López, 2017).
SOAP no define como debe desarrollarse o implementarse una aplicación
para comunicarse, sino que define un mecanismo simple y ligero en un
entorno descentralizado para intercambiar información.
Todos los mensajes que son enviados a través de SOAP están codificados
en formato XML, el mensaje consiste en un sobre (Envelope) que es el
elemento que contiene el mensaje el cual es obligatorio, un encabezado
(Header) que le permite agregar funciones al mensaje de forma
descentralizada, el cuerpo del mensaje (Body) que es el contenido que será
entregado al destinatario del mensaje por lo tanto también es obligatorio
(Box, 2012).
ILUSTRACIÓN N° 5
ESTRUCTURA DE UN SERVICIO SOAP
Fuente: Datos de la Investigación
Elaborado por: Jordy Peñaloza Bravo
Envelope
Header
Body
18
REST
REST (Representational State Transfer) o transferencia de Estado
Representacional es una nueva tecnología web 2.0 la cual se ha convertido
en una importante alternativa para los Web Services que se basan en
SOAP, fue inventado por Roy Fielding en su tesis Doctoral en el año 2000
y se refiere a un tipo de arquitectura de servicios que pueden ser accedidos
a través de un identificador universal de recurso (URI) y son conocidos
como recursos (Muschett, 2011).
REST puede asemejarse mucho a un tipo de programación web orientada
a objeto donde los verbos HTTP vendrían a ser los métodos, y los
parámetros que son enviados a través de la URI vendrían a ser los
parámetros de los métodos siendo el código de respuesta de la petición el
mensaje de respuesta y como se podrán haber dado cuenta el objeto
vendría a ser el recurso solicitado en la petición, generalmente los
lenguajes XML y JSON son los más utilizados para transmitir información
(Muschett, 2011).
Los métodos HTTP soportados por REST son los métodos GET o HEAD,
el método POST, el método PUT y el método DELETE los cuales se
asemejan a las operaciones CRUD en base de datos (CREAR, LEER,
ACTUALIZAR y BORRAR)
CUADRO N° 2
MÉTODOS HTTP
HTTP CRUD Descripción
POST CREAR Crea un nuevo recurso
GET LEER Obtiene la representación de un recurso
PUT ACTUALIZAR Actualiza un recurso
DELETE BORRAR Elimina un recurso
Fuente: http://users.dsic.upv.es
Elaborado por: Jordy Peñaloza Bravo
19
Los códigos de estados que pueden devolver cada uno de los métodos
pueden ser:
CUADRO N° 3
CÓDIGOS DE ESTADOS HTTP
HTTP Códigos de estados
POST 201, 400
GET 200, 301, 410
PUT 200, 301, 400, 410
DELETE 200, 204
Fuente: http://users.dsic.upv.es
Elaborado por: Jordy Peñaloza Bravo
REST vs SOAP
Muchos arquitectos de servicios web han llegado a la conclusión de que
SOAP es muy complicado por los estándares que maneja a diferencia de
REST que es más simple su implementación.
ILUSTRACIÓN N° 6
REST VS SOAP
Fuente: https://blog.nicolashachet.com
Elaborado por: Nicolas Hachet
20
Fielding argumentó que la web funciona mucho mejor cuando se la utiliza
en el estilo que maneja REST (González, 2015).
Las características de SOAP y REST la podemos ver resumidas en la
siguiente tabla:
CUADRO N° 4
CARACTERÍSTICAS DE REST Y SOAP
REST SOAP
Características
Las operaciones son
definidas en los mensajes.
Cada recurso tiene una
dirección única que lo
identifica.
Los componentes están
débilmente acoplados.
Usa los puertos WSDL para
definir sus operaciones.
Todas las operaciones están
en una dirección única.
Existe un fuerte acoplamiento
en sus operaciones.
Ventajas
Su consumo de recursos es
bajo.
Facilidad de construcción y
adaptación.
No es necesaria la
información de enrutamiento
a partir de la URI inicial.
Las instancias de los
procesos se crean
explícitamente
Fácil de utilizar,
Es posible la depuración.
Existen herramientas para la
implementación.
Incrementa la privacidad.
Desventajas
Se puede obtener un gran
número de objetos.
No existe una formalidad en
las descripciones.
Se necesita saber las
operaciones y su semántica
antes de usar.
Las instancias de los
procesos son creadas
implícitamente
Fuente: Datos de la investigación.
Elaborado por: Jordy Peñaloza Bravo
21
Podemos ver una comparación y diferencias entre REST y SOAP en el
siguiente cuadro:
CUADRO N° 5
COMPARACIÓN ENTRE REST Y SOAP
SOAP REST
Es un protocolo de mensajes
basado en XML
Es un protocolo de estilo
arquitectónico.
Usa WSDL para la
comunicación entre el
proveedor y el consumidor
Usa XML o JSON para enviar y
recibir datos
Invoca a los servicios por
medio de llamados a métodos
RPC
Se invoca a los servicios a través
de las URI
Los mensajes que retorna no
son fáciles de entender
Los mensajes que retorna son
fáciles de leer porque es solo
XML o JSON simple
Su transferencia se la hace a
través de HTTP, pero también
se la puede hacer por medio
de otros protocolos como
SMTP, FTP, etc.
Su transferencia es solamente
sobre HTTP
Es muy difícil implementar
llamados a SOAP a través de
JavaScript.
Es fácil hacer el llamado a través
de JavaScript
El rendimiento no es mucho
comparado con REST
Su rendimiento es mucho mejor
comparado con SOAP.
Fuente: Datos de la investigación.
Elaborado por: Jordy Peñaloza Bravo
22
XML
XML (eXtensible Markup Language) o Lenguaje de Marcado Extensible es
un Metalenguaje utilizado para definir otros lenguajes dándole al creador
de estos lenguajes la potestad de definir sus propias etiquetas basándose
en reglas gramaticales para definir el nuevo lenguaje (Schenone, 2011).
XML es un lenguaje derivado de SGML igual que HTML por lo tanto es un
estándar regulado por la W3C y se lo utiliza para estructurar cualquier tipo
de información y que esta esté disponible para todos.
Las principales reglas para construir un documento XML son las siguientes:
• Debe de existir un único elemento raíz por cada documento XML.
• Debe de estar perfectamente anidado.
• Todo dato en el documento siempre va a estar contenido en una
etiqueta de inicio y una etiqueta de fin.
• Los nombres de las etiquetas son case sensitive es decir diferencia
las mayúsculas de las minúsculas.
ILUSTRACIÓN N° 7
XML
Fuente: http://www.mundolinux.info.
Elaborado por: http://www.mundolinux.info
23
JSON
JSON (JavaScript Object Notation) es un formato de texto utilizado para
intercambiar información, los tipos de datos que se pueden representar con
JSON son cuatro del tipo primitivo (Cadenas, Numéricos, booleanos y
nulos) y dos de tipos estructurados (arreglos y objetos) (Bray, 2013).
En JSON un objeto siempre empieza y termina con llaves {}, está
compuesto por los pares clave : valor y siempre van separados por una
coma (,).
ILUSTRACIÓN N° 8
JSON OBJECT
Fuente: http://www.json.org/.
Elaborado por: http://www.json.org/.
En JSON un objeto siempre empieza y termina con [ ] y sus valores siempre
van separado por una coma (,).
ILUSTRACIÓN N° 9
JSON OBJECT
Fuente: http://www.json.org/.
Elaborado por: http://www.json.org/.
24
XML VS JSON
Para el envío y recepción de datos podemos hacer uso de JSON, así como
XML para transmitir información.
Entre las principales diferencias que podemos encontrar entre XML y JSON
podemos destacar las siguientes:
CUADRO N° 6
COMPARACIÓN ENTRE XML Y JSON
XML JSON
Validación XSD No necesita validación
Debe incluir NameSpaces No necesita NameSpaces
Requiere análisis sintáctico, se
analiza a través de parámetros
como xpath
El análisis sintáctico es solo un
eval en JavaScript por lo tanto es
rápido.
Hay que crear un JavaScript para
analizar los objetos XML Es un objeto JavaScript
Es muy pesado comparado con
JSON
JSON es más ligero en
comparación a XML
Necesita una etiqueta inicio y una
etiqueta fin. No necesita de etiqueta fin
Es más complicado de analizar Es más sencillo y rápido de leer y
escribir.
Fuente: Datos de la investigación.
Elaborado por: Jordy Peñaloza Bravo
En conclusión, JSON es mucho más sencillo ser analizado por las
aplicaciones al contrario de XML que muy complicada su interpretación.
25
Servidor Web
Los Servidores Web son servidores que se utilizan para servir los archivos
o documentos que forman las páginas web usando como protocolo de
transferencia el protocolo HTTP ya sea que el contenido se distribuye en
redes internas o en redes externas como el internet (digitalguide, 2016).
Un ejemplo de cómo funcionan los servidores podría ser un esquema
cliente servidor donde el cliente solicita un recurso al servidor y el servidor
como respuesta a la petición del cliente devuelve un documento que el
cliente podrá visualizar en su navegador (Rouse, 2016).
Entre los servidores Web más utilizados tenemos el servidor Apache, el
servidor mginx y el servidor web de Microsoft Internet Information Server
(Rouse, 2016).
ILUSTRACIÓN N° 10
ILUSTRACION DE UN SERVIDOR
Fuente: https://www.euroinnova.edu.es.
Elaborado por: Euroinnova Business School
26
WildFly
Es un servidor de aplicaciones de código abierto el cual se puede instalar
en múltiples plataformas ya que está desarrollado completamente en JAVA
EE 7 el único requerimiento es que tenga instalada la máquina virtual de
JAVA.
ILUSTRACIÓN N° 11
PANTALLA DE BIENVENIDA WILDFLY 8
Fuente: Datos de la investigación.
Elaborado por: Jordy Peñaloza Bravo
Entre las principales características de WildFly tenemos:
• Manejo eficiente de memoria
• Tiene un enfoque modular
• Cada servicio puede ser administrado independientemente sin
afectar a los demás servicios.
• Despliegue rápido también permite editar recursos sin volver a
desplegar
• Escalabilidad
27
ILUSTRACIÓN N° 12
PRIMERA PÁGINA DESPUÉS DEL LOGGIN
Fuente: Datos de la investigación.
Elaborado por: Jordy Peñaloza Bravo
Lenguaje JAVA
El lenguaje de programación JAVA es un lenguaje orientado a objeto, fue
creado por la empresa Sun Microsystems en el año 1991 y en un principio
se lo creo destinado para los electrodomésticos, pensando que se
necesitaba un lenguaje sencillo que se acople a la reducida potencia de
procesamiento de los electrodomésticos.
Sun desarrollo un código intermedio o código neutro el cual se ejecuta en
una máquina virtual por lo que no depende de ningún procesador esta
máquina virtual es conocida como la Java Virtual Machine.
Aunque ninguna empresa de electrodomésticos se interesó en el lenguaje
JAVA se reconvirtió en un lenguaje de programación utilizable en el internet
a finales de 1995 cuando Netscape Navigator 2.0 implemento una Java
Virtual Machine convirtiéndose en una revolución en la época, teniendo
como filosofía “Escribe una vez, corre donde sea” (unav, 2011).
28
ILUSTRACIÓN N° 13
FASE DE COMPILACION DE UNA CLASE JAVA
Fuente: http://nishvitatechnologies.com.
Elaborado por: http://nishvitatechnologies.com
Librería Log4j
Log4j es una librería diseñada para JAVA la cual nos permite poder generar
logs para el monitoreo del funcionamiento de nuestras aplicaciones, Log4j
es un proyecto de Apache Software Foundation.
Log4j posee tres componentes principales:
• Loggers
• Appenders
• Layouts
De estos tres componentes nos enfocaremos en el de Loggers ya que será
ese componente el que usaremos en nuestro aplicativo Health Monitor UG
Los loggers tienen niveles jerárquicos en sus mensajes siendo de menor a
mayor prioridad los siguientes (javatutoriales, 2011):
29
Trace: Se lo utiliza para obtener información aún más detallada que en el
debug.
Debug: Se lo utiliza para llevar un control detallado en el debugger de una
aplicación.
INFO: Se lo utiliza para mostrar mensajes de información de manera
general.
WARN: Se lo utiliza para situaciones en que se pueden dar algún tipo de
conflicto en la aplicación.
ERROR: Se lo utiliza cuando ocurren errores en nuestro aplicativo pero que
dichos errores no impidan que la aplicación termine su ejecución.
FATAL: Se lo utiliza cuando ocurren errores muy graves que hacen que el
aplicativo deje de funcionar.
ILUSTRACIÓN N° 14
NIVELES DE LOGGER
Fuente: http://www.javatutoriales.com.
Elaborado por: javatutoriales
30
Librería JAX-RS
JAX-RS Es una librería desarrollada en JAVA que contiene un conjunto de
interfaces y anotaciones que me permite desarrollar servicios tipo RESTful
de forma rápida.
La principal característica de esta librería es que permite crear los servicios
de una manera sencilla ya que se encarga de hacer automáticamente la
conversión a los diferentes MIME types que soporta.
En el siguiente cuadro se muestra las anotaciones más usadas en los
servicios que hemos creados:
CUADRO N° 7
ANOTACIONES DEL API JAX-RS
Anotación Descripción
@Path Define la ruta Relativa del recurso
@GET HTTP GET request, es usada para obtener un
recurso.
@PUT HTTP PUT request, es usada para crear un recurso
@POST HTTP POST request, es usada para crear o
actualizar un recurso.
@PRODUCES Formato de respuesta en que se devolverá la
información del recurso por ejemplo application/json
application/xml
@CONSUMES Formato en que estará representada la información
que se envíe en la petición. Por ejemplo,
aplication/json aplication/xml
@QUERYPARAM Parámetros BINDS que se pasaran en URI del
recurso.
Fuente: https://www.tutorialspoint.com.
Elaborado por: tutorialspoint
31
Librería JAVAX.MAIL
La librería javax.mail es una API que me permite hacer envío de email a
través de los protocolos conocidos POP3, SMTP, etc.
En nuestro proyecto la usamos para el envío de las credenciales al correo
del paciente cuando el paciente se olvida de su clave.
PEAK FLOW
El Peak Flow o medidor de flujo espiratorio máximo es un dispositivo que
permite medir la fuerza máxima del flujo espiratorio de una persona, lo que
hace este dispositivo es medir la fuerza de los bronquios para saber qué
tan obstruidos se encuentran sus vías respiratorias.
FUNDAMENTACIÓN SOCIAL
En el país hay muchas personas que padecen de la enfermedad de la
diabetes y otras que también padecen de asma, con este proyecto se busca
que las personas que padecen de esta enfermedad tengan una herramienta
que le ayude a llevar un mejor control de la misma y de esa manera poder
llevar un mejor estilo de vida con los beneficios que le ofrece la aplicación
Health Monitor UG.
FUNDAMENTACION LEGAL
El estilo de vida que llevan las personas en el Ecuador y sus malos hábitos
alimenticios ha provocado que las estadísticas de personas que padecen
de la enfermedad de la diabetes aumenten considerablemente esto
también se debe a que muchos de los alimentos que se comercializan en
el país no tienen la información necesaria sobre sus valores alimenticios.
Por ese motivo el estado ecuatoriano tomó la decisión de regular y controlar
los etiquetados de los alimentos procesados para el consumo humano para
32
que muestren la información pertinente, esto lo hizo mediante el
“Reglamento Sanitario de Etiquetado de Alimentos Procesados Para el
Consumo Humano” (Acuerdo No. 00004522) Según el reglamento en base
a lo que la ley Orgánica de salud dispone en su artículo 131:
“Que los envases de los productos que contengan alimentos genéticamente
modificados, sean nacionales o importados deben incluir obligatoriamente
en forma visible y comprensible en sus etiquetas, el señalamiento de esta
condición, además de los otros requisitos que establezca la autoridad
sanitaria nacional, de conformidad con la ley y las normas reglamentarias
que se dicten para el efecto”.
Por lo tanto, en el presente trabajo de titulación nos basamos en los
siguientes fundamentos legales:
Ley 32
Registro Oficial 290 del 11 de marzo del 2004
Estado: Vigente
LEY DE PREVENCIÓN, PROTECCIÓN, Y ATENCION INTEGRAL DE
LAS PERSONAS QUE PADECEN DIABETES
Art.1.- “El Estado Ecuatoriano garantiza a todas las personas la protección,
prevención, diagnóstico, tratamiento de la Diabetes y el control de las
complicaciones de esta enfermedad que afecta a un alto porcentaje de la
población y su respectivo entorno familiar.”
“La prevención constituirá política de Estado y será implementada por el
Ministerio de Salud Pública.”
33
“Serán beneficiarios de esta Ley, los ciudadanos ecuatorianos y los
extranjeros que justifiquen al menos cinco años de permanencia legal en el
Ecuador.”
Art.2.- “Créase el Instituto Nacional de Diabetología - INAD, Institución
Pública adscrita al Ministerio de Salud Pública, con sede en la ciudad de
Quito, que podrá tener sedes regionales en las ciudades de Guayaquil,
Cuenca y Portoviejo o en otras ciudades del país de acuerdo con la
incidencia de la enfermedad; tendrá personería jurídica, y su administración
financiera, técnica y operacional será descentralizada.”
Art. 3.- “El Instituto Nacional de Diabetología (INAD), contará con los
siguientes recursos:”
a) “Los asignados en el Presupuesto General del Estado, a partir del
ejercicio fiscal del 2005; y,”
b) “Los provenientes de la cooperación internacional.”
Art. 4.- “Son funciones del Instituto Nacional de Diabetología (INAD) en
coordinación con el Ministerio de Salud Pública, las siguientes:”
a) “Diseñar las políticas de prevención, detección y lucha contra la
Diabetes;”
b) “Desarrollar en coordinación con la Sociedad Ecuatoriana de
Endocrinología y la Federación Ecuatoriana de Diabetes, estrategias
y acciones para el diseño e implementación del Programa Nacional
de Diabetes que deben ser cumplidas por las instituciones que
conforman el Sistema Nacional de Salud;”
34
c) “Elaborar y coordinar la implementación de estrategias de difusión
acerca de la Diabetes y sus complicaciones en instituciones
educativas a nivel nacional;”
d) “Asesorar, informar, educar y capacitar a la población sobre esta
enfermedad, los factores predisponentes, complicaciones y
consecuencias a través del diseño y ejecución de programas y
acciones de promoción de la salud y prevención de la enfermedad
que contribuyan a desarrollar en la población, estilos de vida y
hábitos saludables;”
e) “Realizar el Censo y la Carnetización de las personas con
Diabetes, cada tres años;”
f) “Coordinar con organismos no gubernamentales, nacionales o
extranjeros, los programas de prevención y atención integral de las
personas con Diabetes;”
g) “Promover la investigación médico - social, básica, clínica y
epidemiológica de las complicaciones agudas y crónicas de la
Diabetes, a nivel del Ministerio de Salud Pública, y organizaciones
no gubernamentales nacionales o extranjeras;”
h) “Elaborar y difundir a nivel nacional, las publicaciones, revistas,
textos, manuales y tratados de Diabetología; “
i) “Crear incentivos a favor de las universidades para que preparen
profesionales especializados en la atención de la Diabetes, así como
gestionar el financiamiento de programas de investigación científica
y de becas para esta especialización;”
35
j) “Establecer las tareas físicas que no puedan ser desarrolladas por
personas diabéticas y, ponerlas en conocimiento de las autoridades
competentes en materia laboral, a fin de que se arbitren las medidas
pertinentes;”
k) “Programar, administrar, ejecutar y evaluar, de manera ágil y
oportuna los recursos asignados al INAD;”
l) “Coordinar con los medios de comunicación social para hacer
conciencia de la diabetes como un problema de salud pública, sus
consecuencias y fomentar medidas de promoción de la salud y
prevención de la enfermedad;”
m) “Velar por el cabal cumplimiento de las disposiciones
establecidas en la presente Ley;”
n) “Dictar los reglamentos internos para el funcionamiento del INAD;”
o) “Velar por la estabilidad de los trabajadores y empleados que
padezcan de Diabetes o sus secuelas para que no sean despedidos
por esta causa; y,”
p) “Las demás funciones y responsabilidades que le asignen las
leyes y reglamentos complementarios vinculados a la Diabetes
(Constitucional, 2004).”
LEY DE COMERCIO ELECTRÓNICO, FIRMAS ELECTRÓNICAS Y
MENSAJES DE DATOS
Art. 2.- “Reconocimiento jurídico de los mensajes de datos. - Los mensajes
de datos tendrán igual valor jurídico que los documentos escritos. Su
36
eficacia, valoración y efectos se someterá al cumplimiento de lo establecido
en esta Ley y su reglamento.”
Art. 4.- “Propiedad Intelectual. - Los mensajes de datos estarán sometidos
a las leyes, reglamentos y acuerdos internacionales relativos a la propiedad
intelectual.”
Art. 5.- “Confidencialidad y reserva. - Se establecen los principios de
confidencialidad y reserva para los mensajes de datos, cualquiera sea su
forma, medio o intención. Toda violación a estos principios, principalmente
aquellas referidas a la intrusión electrónica, transferencia ilegal de
mensajes de datos o violación del secreto profesional, será sancionada
conforme a lo dispuesto en esta Ley y demás normas que rigen la materia.”
CÓDIGO ORGÁNICO INTEGRAL PENAL
Artículo 229.- “Revelación ilegal de base de datos. - La persona que, en
provecho propio o de un tercero, revele información registrada, contenida
en ficheros, archivos, bases de datos o medios semejantes, a través o
dirigidas a un sistema electrónico, informático, telemático o de
telecomunicaciones; materializando voluntaria e intencionalmente la
violación del secreto, la intimidad y la privacidad de las personas, será
sancionada con pena privativa de libertad de uno a tres años.”
“Si esta conducta se comete por una o un servidor público, empleadas o
empleados bancarios internos o de instituciones de la economía popular y
solidaria que realicen intermediación financiera o contratistas, será
sancionada con pena privativa de libertad de tres a cinco años.”
Artículo 230.- “Interceptación ilegal de datos. - Será sancionada con pena
privativa de libertad de tres a cinco años:”
37
1. “La persona que, sin orden judicial previa, en provecho propio o
de un tercero, intercepte, escuche, desvíe, grabe u observe, en
cualquier forma un dato informático en su origen, destino o en el
interior de un sistema informático, una señal o una transmisión
de datos o señales con la finalidad de obtener información
registrada o disponible.”
2. “La persona que diseñe, desarrolle, venda, ejecute, programe o
envíe mensajes, certificados de seguridad o páginas electrónicas,
enlaces o ventanas emergentes o modifique el sistema de
resolución de nombres de dominio de un servicio financiero o
pago electrónico u otro sitio personal o de confianza, de tal
manera que induzca a una persona a ingresar a una dirección o
sitio de internet diferente a la que quiere acceder.”
3. “La persona que a través de cualquier medio copie, clone o
comercialice información contenida en las bandas magnéticas,
chips u otro dispositivo electrónico que esté soportada en las
tarjetas de crédito, débito, pago o similares.”
4. “La persona que produzca, fabrique, distribuya, posea o facilite
materiales, dispositivos electrónicos o sistemas informáticos
destinados a la comisión del delito descrito en el inciso anterior.”
Artículo 231.- “Transferencia electrónica de activo patrimonial. - La
persona que, con ánimo de lucro, altere, manipule o modifique el
funcionamiento de programa o sistema informático o telemático o mensaje
de datos, para procurarse la transferencia o apropiación no consentida de
un activo patrimonial de otra persona en perjuicio de esta o de un tercero,
será sanciona da con pena privativa de libertad de tres a cinco años. “
38
“Con igual pena, será sanciona da la persona que facilite o proporcione
datos de su cuenta bancaria con la intención de obtener, recibir o captar de
forma ilegítima un activo patrimonial a través de una transferencia
electrónica producto de este delito para sí mismo o para otra persona.”
Artículo 232.- “Ataque a la integridad de sistemas informáticos. - La
persona que destruya, dañe, borre, deteriore, altere, suspenda, trabe,
cause malfuncionamiento, comportamiento no deseado o suprima datos
informáticos, mensajes de correo electrónico, de sistemas de tratamiento
de información, telemático o de telecomunicaciones a todo o partes de sus
componentes lógicos que lo rigen, será sancionada con pena privativa de
libertad de tres a cinco años.”
Con igual pena será sancionada la persona que:
1. “Diseñe, desarrolle, programe, adquiera, envíe, introduzca, ejecute,
venda o distribuya de cualquier manera, dispositivos o programas
informáticos maliciosos o programas destinados a causar los efectos
señalados en el primer inciso de este artículo. “
2. “Destruya o altere sin la autorización de su titular, la infraestructura
tecnológica necesaria para la transmisión, recepción o
procesamiento de información en general.”
“Si la infracción se comete sobre bienes informáticos destinados a la
prestación de un servicio público o vinculado con la seguridad
ciudadana, la pena será de cinco a siete años de privación de
libertad.”
39
Artículo 233.- “Delitos contra la información pública reservada legalmente.
-La persona que destruya o inutilice información clasificada de conformidad
con la Ley, será sancionada con pena privativa de libertad de cinco a siete
años. “
“La o el servidor público que, utilizando cualquier medio electrónico o
informático, obtenga este tipo de información, será sancionado con pena
privativa de libertad de tres a cinco años. “
“Cuando se trate de información reservada, cuya revelación pueda
comprometer gravemente la seguridad del Estado, la o el servidor público
encargado de la custodia o utilización legítima de la información que sin la
autorización correspondiente revele dicha información, será sancionado
con pena privativa de libertad de siete a diez años y la inhabilitación para
ejercer un cargo o función pública por seis meses, siempre que no se
configure otra infracción de mayor gravedad. “
Artículo 234.- “Acceso no consentido a un sistema informático, telemático
o de telecomunicaciones. - La persona que sin autorización acceda en todo
o en partea un sistema informático o sistema telemático o de
telecomunicaciones o se mantenga dentro del mismo en contra de la
voluntad de quien tenga el legítimo derecho, para explotar ilegítimamente
el acceso logrado, modificar un portal web, desviar o re direccionar de
tráfico de datos o voz u ofrecer servicios que estos sistemas proveen a
terceros, sin pagarlos a los proveedores de servicios legítimos, será
sancionada con la pena privativa de la libertad de tres a cinco años.”
40
IDEA A DEFENDER
Si se aplica la arquitectura de microservicios en la aplicación Health
Monitor UG aumentará la eficiencia en el procesamiento para registrar la
información de los datos del paciente que padezcan la enfermedad del
asma o la diabetes desde la aplicación hacia la base de datos.
41
CAPÍTULO III
METODOLOGÍA
Diseño de la investigación
Modalidad de la investigación
La modalidad de investigación que se empleó en este proyecto fue una
modalidad de investigación aplicada, en la cual se utilizó el conocimiento
existente sobre las herramientas utilizadas para el desarrollo del proyecto
como es la arquitectura de servicios tipo Rest usando el lenguaje de
programación JAVA.
Tipos de investigación
El tipo de investigación que se aplicó fue una investigación del tipo de
proyecto factible, ya que al momento de hacer el levantamiento de
información se pudo concluir que en la actualidad existen las herramientas
necesarias y gratuitas para llevar a cabo el desarrollo e implementación del
proyecto.
Metodología de desarrollo
La metodología que se aplicó en el desarrollo del proyecto fue la
metodología Ágil Scrum para el desarrollo de Software.
El área de procesos hizo el levantamiento de los requerimientos lo que
permitió poder crear el product BackLog, una vez obtenido el product se
procedió a generar los Sprint para empezar las tareas de desarrollo.
42
Todos los días se realizó el daily meeting (reunión diaria) donde se
respondía las preguntas ¿Qué se realizó el día de ayer? ¿Qué se va a
realizar el día de hoy? ¿Existe algún tipo de bloqueo?
Al final de la semana se realizaba una retroalimentación de todas las tareas
realizadas.
La herramienta tecnológica que se utilizó para llevar el control de las tareas
fue una herramienta conocida como Trello, la cual permitía saber en que
estado se encontraba la realización de una tarea.
ILUSTRACIÓN N° 15 HERRAMIENTA TRELLO
Elaborado por: Jordy Peñaloza
Fuente: Datos de la Investigación
POBLACIÓN Y MUESTRA
Población
La población que se necesita para validar la propuesta planteada en el
presente trabajo de titulación debe de cumplir con características técnicas
y conocer sobre la arquitectura de software propuesta para la validación de
la misma.
43
Por lo tanto, la población que fue utilizada para la validación de la propuesta
fue los 25 integrantes del proyecto APP Salud V2 ya que ellos cuentan con
el conocimiento necesario para la validación de la propuesta tecnológica.
Muestra
La muestra que se consideró para las encuestas fue conformada por los 25
alumnos que conforman el proyecto ya que el conocimiento que tienen
sobre los microservicios desarrollados los hace idóneos para las encuestas.
CUADRO N° 8
DISTRIBUCIÓN DE LA POBLACIÓN
Muestra Cantidad
Personas 25
Total 25
Elaborado por: Jordy Peñaloza Fuente: Datos de la Investigación
TÉCNICA DE RECOLECCIÓN DE DATOS
Encuesta
Las encuestas fueron realizadas en las instalaciones de la Universidad de
Guayaquil en el edificio Centrum de la carrera de Ingeniería en sistemas.
Las encuestas fueron distribuidas a los 25 estudiantes que conforman el
proyecto.
Las preguntas realizadas se formularon en base a lo que se quiere
comprobar en el presente trabajo de titulación.
A continuación, se muestra el resultado de las encuestas con sus
respectivas interpretaciones por cada pregunta que se realizó.
44
Pregunta 1: ¿Cómo calificaría usted el tiempo de respuesta de los
microservicios?
CUADRO N° 9
RESULTADO DE LA PREGUNTA 1 DE LA ENCUESTA
¿Cómo calificaría usted el tiempo de respuesta de los microservicios?
Encuestas
% Respuestas
Excelente 15 60%
Bueno 10 40%
Regular 0 0%
Malo 0 0%
Total 25 100%
Fuente: Datos de Investigación.
Elaborado por: Jordy Peñaloza Bravo
GRÁFICO N° 1
RESULTADO DE LA PREGUNTA 1 DE LA ENCUESTA
Fuente: Datos de Investigación.
Elaborado por: Jordy Peñaloza Bravo
Análisis:
Según el resultado de la encuesta se puede deducir que el 60% de los
encuestados considera que el tiempo de respuesta de los microservicios es
excelente y el 40% indica que es bueno, por lo tanto, se puede deducir que
hay una alta satisfacción en el rendimiento de los microservicios.
45
Pregunta 2: ¿Cómo calificaría usted el estándar y el tipo de petición
utilizado para el envío de datos de los microservicios?
CUADRO N° 10
RESULTADO DE LA PREGUNTA 2 DE LA ENCUESTA
¿Cómo calificaría usted el estándar y el
tipo de petición utilizado para el envío
de datos de los microservicios?
Encuestas
% Respuestas
Excelente 17 68%
Bueno 8 32%
Regular 0 0%
Malo 0 0%
Total 25 100%
Fuente: Datos de Investigación.
Elaborado por: Jordy Peñaloza Bravo
GRÁFICO N° 2
RESULTADO DE LA PREGUNTA 2 DE LA ENCUESTA
Fuente: Datos de Investigación.
Elaborado por: Jordy Peñaloza Bravo
Análisis:
Según el resultado de la encuesta se puede deducir que el 68% de los
encuestados considera que estándar usado en la petición de los
microservicios es excelente y el 32% indica que es bueno, por lo tanto, se
puede deducir que hay una alta aceptación de los media type utilizados en
los microservicios.
46
Pregunta 3: ¿Cree usted que el formato de salida JSON en un micro
servicio es más entendible que el formato XML?
CUADRO N° 11
RESULTADO DE LA PREGUNTA 3 DE LA ENCUESTA
¿Cree usted que el formato de salida JSON en un micro
servicio es más entendible que el
formato XML?
Encuestas
% Respuestas
Si 14 56%
No 7 28%
Talvez 4 16%
Total 25 100%
Fuente: Datos de Investigación.
Elaborado por: Jordy Peñaloza Bravo
GRÁFICO N° 3
RESULTADO DE LA PREGUNTA 3 DE LA ENCUESTA
Fuente: Datos de Investigación.
Elaborado por: Jordy Peñaloza Bravo
Análisis:
Según el resultado de la encuesta se puede deducir que el 56% de los
encuestados considera que el formato de respuesta de los microservicios
es excelente y el 28% indica que es bueno, por lo tanto, se puede deducir
que hay una alta aceptación del uso del formato JSON en los
microservicios.
47
Pregunta 4: ¿Qué tipo de arquitectura considera usted es
recomendable para el uso en aplicaciones móviles?
CUADRO N° 12
RESULTADO DE LA PREGUNTA 4 DE LA ENCUESTA
¿Qué tipo de arquitectura considera
usted es recomendable para el uso en aplicaciones
móviles?
Encuestas
% Respuestas
REST 24 96%
SOAP 1 4%
OTRO 0 0%
Total 25 100%
Fuente: Datos de Investigación.
Elaborado por: Jordy Peñaloza Bravo
GRÁFICO N° 4
RESULTADO DE LA PREGUNTA 4 DE LA ENCUESTA
Fuente: Datos de Investigación.
Elaborado por: Jordy Peñaloza Bravo
Análisis:
Según el resultado de la encuesta se puede deducir que el 96% de los
encuestados considera que la arquitectura tipo REST tiene un mejor
acoplamiento en la implementación con dispositivos Android, lo que da a
entender que se tomó la mejor decisión al momento de construir los
microservicios.
48
Pregunta 5: ¿Cree usted que los microservicios creados para la
aplicación Health Monitor UG permitió que la aplicación alcance un
rendimiento óptimo?
CUADRO N° 13
RESULTADO DE LA PREGUNTA 5 DE LA ENCUESTA
¿Cree usted que los microservicios creados para la
aplicación Health Monitor UG permitió
que la aplicación alcance un
rendimiento óptimo?
Encuestas
% Respuestas
Si 20 80%
No 0 0%
Talvez 5 20%
Total 25 100%
Fuente: Datos de Investigación.
Elaborado por: Jordy Peñaloza Bravo
GRÁFICO N° 5 RESULTADO DE LA PREGUNTA 5 DE LA ENCUESTA
Fuente: Datos de Investigación.
Elaborado por: Jordy Peñaloza Bravo
Análisis: Según el resultado de la encuesta se puede deducir que el 80% de los
encuestados considera que la implementación de una arquitectura de
microservicios logró que el aplicativo Health Monitor UG tenga un alto
rendimiento haciendo que nuestra propuesta de proyecto sea una
propuesta válida.
49
CAPÍTULO IV
PROPUESTA TECNOLÓGICA
La propuesta tecnológica en el presente trabajo de titulación es crear los
microservicios necesarios para que el paciente por medio de la aplicación
Health Monitor UG pueda registrar la información del asma, además aplicar
reingeniería en los servicios existentes para la diabetes para que pueda
integrarse con el asma, toda la información la guardará en la base de datos
MySQL.
HERRAMIENTAS UTILIZADAS
Eclipse NEON para desarrollar aplicaciones JAVA EE
El IDE utilizado para desarrollar los microservicios fue Eclipse Neon, junto
con la librería JAX - RS hicieron posible la creación de los microservicios
con una arquitectura tipo REST, esta librería permite hacer la conversión
automática al tipo MIME types application/json la cual se usó como formato
para el envío y recepción de información.
ILUSTRACIÓN N° 16 LOGO DE ECLIPSE NEON
Fuente: Datos de Investigación.
Elaborado por: Jordy Peñaloza Bravo
50
ILUSTRACIÓN N° 17
EJEMPLO DE INTERFAZ PARA VALIDAR CUENTA
Y CONSULTAR PRESIÓN
Fuente: Datos de Investigación.
Elaborado por: Jordy Peñaloza Bravo
Para la opción de recuperar clave se usó la librería javax.mail para el envío
del password temporal al correo del paciente.
Para llevar un control de logs se utilizó la librería log4j versión 1.2.16 gracias
a esto se pudo auditar en las ocasiones en que los servicios no funcionaban
de manera óptima.
ILUSTRACIÓN N° 18
ENVÍO DE EMAIL CON EL PASSWORD
Fuente: Datos de Investigación.
Elaborado por: Jordy Peñaloza Bravo
51
ILUSTRACIÓN N° 19
CONFIGURACIÓN DE PROPERTIES LOG4J
Fuente: Datos de Investigación.
Elaborado por: Jordy Peñaloza Bravo
La conexión a la base de datos se procedió a realizarla por medio de un
DataSource creado en el servidor de aplicaciones usando la librería de
MySQL-connector-java versión 5.1.40 cómo se puede apreciar en la
siguiente imagen.
ILUSTRACIÓN N° 20
PROPIEDADES DEL DATASOURCE
Fuente: Datos de Investigación.
Elaborado por: Jordy Peñaloza Bravo
52
Servidor de aplicación WildFly 10.1
El servidor de aplicaciones que se utilizó en la propuesta tecnológica fue el
servidor de aplicaciones WildFly versión 10.1 el cual es la siguiente versión
del conocido servidor Jboss
Este servidor se lo utilizó para deployar los WARS de los servicios tanto en
ambiente local, en ambiente de desarrollo y ambiente de producción. En
ambiente local se lo integró a eclipse para hacer el deploy de los WARS,
en ambiente de desarrollo y producción se hizo el deploy exportando los
servicios a un archivo WAR para luego proceder a publicarlos usando la
consola de WildFly.
ILUSTRACIÓN N° 21
WARS SUBIDOS AL SERVIDOR
.
Fuente: Datos de Investigación.
Elaborado por: Jordy Peñaloza Bravo
53
MICROSERVICIOS
Servicio para consultar los síntomas del asma
El servicio para consultar los síntomas del asma lo hace por medio del valor
que el paciente ingreso de su lectura del Peak Flow, dependiendo del rango
en que se encuentre el valor ingresado se mostraran los síntomas
correspondientes.
ILUSTRACIÓN N° 22
SERVICIO PARA CONSULTAR SÍNTOMAS DE ASMA
Fuente: Datos de Investigación.
Elaborado por: Jordy Peñaloza Bravo
54
Servicio para consultar los desencadenantes del asma
El servicio para consultar los desencadenantes del asma lo hace por medio
del valor que el paciente ingreso de su lectura del Peak Flow dependiendo
del rango en que se encuentre el valor ingresado se mostrarán los
desencadenantes correspondientes.
ILUSTRACIÓN N° 23
SERVICIO PARA CONSULTAR DESENCADENANTES DE ASMA
Fuente: Datos de Investigación.
Elaborado por: Jordy Peñaloza Bravo
55
Servicio para registrar la lectura del Peak Flow
El servicio para registrar la lectura de Peak Flow recibe el correo del
paciente, la lectura del Peak Flow, la fecha de la toma, la observación, un
arreglo donde se indica los síntomas que tuvo al momento de tomar la
medición y un arreglo donde se indican los desencadenantes que pudieron
provocar los síntomas, para luego enviar a insertar a la base de datos.
ILUSTRACIÓN N° 24
SERVICIO PARA REGISTRAR LA LECTURA DE PEAK FLOW
Fuente: Datos de Investigación.
Elaborado por: Jordy Peñaloza Bravo
56
Servicio para consultar historial de Peak Flow
El servicio para consultar el historial de Peak Flow recibe como parámetros
el email del paciente, la fecha inicio y fecha fin de la consulta, si las fechas
están vacías se devuelven todos los registros.
ILUSTRACIÓN N° 25
SERVICIO PARA CONSULTAR EL HISTORIAL DE PEAK FLOW
Fuente: Datos de Investigación.
Elaborado por: Jordy Peñaloza Bravo
57
Servicio para registrar medicación
El servicio para registrar medicación recibe como parámetro el correo del
paciente, el id de la medicina que escogió, la dosis, el tipo de frecuencia, la
cantidad de veces, descripción de la frecuencia, observación, fecha de
inicio y fecha fin.
ILUSTRACIÓN N° 26
SERVICIO PARA REGISTRAR LA MEDICACIÓN
Fuente: Datos de Investigación.
Elaborado por: Jordy Peñaloza Bravo
58
Servicio para actualizar medicación
El servicio para actualizar medicación recibe como parámetro el correo del
paciente, el id de la medicina que escogió, la dosis, el tipo de frecuencia, la
cantidad de veces, descripción de la frecuencia, observación, fecha de
inicio y fecha fin.
Este servicio borrará las alarmas que tenga asociada al medicamento por
lo tanto el paciente tendrá que volver a configurar las alarmas.
ILUSTRACIÓN N° 27
SERVICIO PARA ACTUALIZAR LA MEDICACIÓN
Fuente: Datos de Investigación.
Elaborado por: Jordy Peñaloza Bravo
59
Servicio para registrar la alarma para la medicación
El servicio para registrar la alarma para la medicación recibe como
parámetro el correo del paciente, el id de la medicación, hora de la alarma,
fecha de registro y la observación, este servicio se llamará por cada alarma
que se desea registrar.
ILUSTRACIÓN N° 28
SERVICIO PARA REGISTRAR LA ALARMA
Fuente: Datos de Investigación.
Elaborado por: Jordy Peñaloza Bravo
60
Servicio para consultar las alarmas para la medicación
Este servicio permite consultar las alarmas para la medicación recibe como
parámetro el correo del paciente y retornará todas las alarmas configuradas
para las medicaciones registradas del paciente.
ILUSTRACIÓN N° 29
SERVICIO PARA CONSULTAR LAS ALARMAS
Fuente: Datos de Investigación.
Elaborado por: Jordy Peñaloza Bravo
61
Servicio para registrar el control de la medicación
Este servicio permite registrar cuando un paciente ya se ha tomado la
medicina, los parámetros que recibe son el id de la alarma, el id de la
medicación, un indicador de si se tomó la medicina o no, la fecha de registro
y una observación.
ILUSTRACIÓN N° 30
SERVICIO PARA EL REGISTRO DEL CONTROL DE MEDICACIÓN
Fuente: Datos de Investigación.
Elaborado por: Jordy Peñaloza Bravo
62
Servicio para consultar el control de la medicación
Este servicio permite consultar las medicinas que el paciente ya se ha
tomado recibe como parámetro el correo del paciente y retornara todos los
registros de los medicamentos que ya ha tomado.
ILUSTRACIÓN N° 31
SERVICIO PARA CONSULTAR LOS REGISTROS DEL CONTROL
Fuente: Datos de Investigación.
Elaborado por: Jordy Peñaloza Bravo
63
Capturas del funcionamiento de los servicios desde un dispositivo Android
ILUSTRACIÓN N° 32
PANTALLA DE REGISTROS DE PEAK FLOW
Fuente: Datos de Investigación.
Elaborado por: Jordy Peñaloza Bravo
En esta pantalla el paciente podrá visualizar todos los registros de Peak
Flow que haya realizado con el servicio para registrar Peak Flow.
64
ILUSTRACIÓN N° 33
PANTALLA DE INGRESO DE LECTURA DE PEAK FLOW
Fuente: Datos de Investigación.
Elaborado por: Jordy Peñaloza Bravo
En esta pantalla el paciente ingresa su lectura de Peak Flow, la fecha en
que se tomó la lectura y una observación.
65
ILUSTRACIÓN N° 34
PANTALLA DE SELECCIÓN DE SINTOMAS
Fuente: Datos de Investigación.
Elaborado por: Jordy Peñaloza Bravo
Una vez ingresado el flujo máximo dependiendo del valor que el paciente
haya ingresado se mostrarán los síntomas, en esta pantalla se podrán
escoger uno o más síntomas.
66
ILUSTRACIÓN N° 35
PANTALLA DE SELECCIÓN DE LOS DESENCADENANTES
Fuente: Datos de Investigación.
Elaborado por: Jordy Peñaloza Bravo
Una vez escogido los síntomas en esta pantalla el paciente podrá escoger
los desencadenantes que produjeron los síntomas escogidos, finalmente
podrá registrar todos los datos recopilados.
67
ILUSTRACIÓN N° 36
PANTALLA DONDE SE CONSULTA LAS ESTADÍSTICAS DEL ASMA
Fuente: Datos de Investigación.
Elaborado por: Jordy Peñaloza Bravo
En esta pantalla se utiliza el servicio de consulta por rango de fechas de los
registros de Peak Flow.
68
ILUSTRACIÓN N° 37
PANTALLA DE REGISTROS DE MEDICINAS
Fuente: Datos de Investigación.
Elaborado por: Jordy Peñaloza Bravo
En esta pantalla se mostrará todos los registros de medicamentos que el
paciente haya registrado.
69
ILUSTRACIÓN N° 38
PANTALLA DE SELECCION DE MEDICAMENTOS
Fuente: Datos de Investigación.
Elaborado por: Jordy Peñaloza Bravo
En esta pantalla se mostrará una lista de medicamentos relacionados al
asma y la diabetes donde el paciente podrá seleccionar el medicamento
que debe de tomar.
70
ILUSTRACIÓN N° 39
PANTALLA DE CONFIGURACIÓN DE ALARMA
Fuente: Datos de Investigación.
Elaborado por: Jordy Peñaloza Bravo
En esta pantalla se podrá configurar la dosis, la fecha de registro, la hora
de la alarma, la frecuencia, los días y una observación. Utilizando varios de
los servicios descritos para la configuración de alarma.
71
ILUSTRACIÓN N° 40
PANTALLA DE CONSULTA DE ALARMAS
Fuente: Datos de Investigación.
Elaborado por: Jordy Peñaloza Bravo
En esta pantalla se podrá observar las alarmas de cada medicamento que
han sido registrados por el paciente
72
ILUSTRACIÓN N° 41
PANTALLA DE ALARMA
Fuente: Datos de Investigación.
Elaborado por: Jordy Peñaloza Bravo
Esta pantalla aparecerá cuando una alarma se activa una vez que el
paciente haga clic en tomar, la aplicación usara el servicio para registrar
control de medicación indicando que el paciente ya se tomó su
medicamento.
73
ILUSTRACIÓN N° 42
PANTALLA DE MEDICAMENTOS TOMADOS POR EL PACIENTE
Fuente: Datos de Investigación.
Elaborado por: Jordy Peñaloza Bravo
En esta pantalla el paciente podrá llevar un control de los medicamentos
que han sido tomados. En esta pantalla interviene el servicio de consulta
de control de medicación.
74
ILUSTRACIÓN N° 43
PANTALLA DE ESTADÍSTICAS DE MEDICINAS
Fuente: Datos de Investigación.
Elaborado por: Jordy Peñaloza Bravo
En esta pantalla el paciente podrá consultar por medio de un rango de fecha
las estadísticas de consumo de medicina haciendo un filtro según la
medicina que haya tomado.
75
ANÁLISIS DE FACTIBILIDAD
Gracias al api JAX-RS para JAVA es posible crear microservicios con una
arquitectura tipo REST, ya que este API hace la conversión a media type
JSON automáticamente y nos da gran facilidad a la hora de implementar
los microservicios.
La plataforma Android tiene una gran compatibilidad a la hora de consumir
servicios tipo REST, por lo que la comunicación entre los microservicios y
los dispositivos Android se podrá realizar sin inconvenientes.
La base de datos MySQL gracias a su alto performance y rapidez de
respuesta garantiza que los microservicios tendrán un tiempo de respuesta
óptimo por lo tanto la aplicación Health Monitor UG será una herramienta
óptima para las personas que sufren de las enfermedades de la diabetes,
así como la del asma también.
FACTIBILIDAD OPERACIONAL La diabetes es una enfermedad que va en aumento en el país, por tal
motivo muchas de las personas necesitan una herramienta que les permita
llevar un mejor control de su enfermedad.
Al ser nuestra propuesta un aplicativo móvil, y debido al auge del uso de
los celulares Smartphone le permitirá al paciente registrar de una manera
más cómoda y fácil los registros de su enfermedad, gracias a que la
aplicación es muy intuitiva en su uso las personas podrán usarla sin ningún
problema.
En el desarrollo de los microservicios para la aplicación se usó la
metodología Ágil SCRUM lo cual nos permitió llevar un mejor control en las
fases del desarrollo del proyecto.
76
FACTIBILIDAD TÉCNICA
Las herramientas que fueron utilizadas para el desarrollo de este proyecto
se mencionan a continuación:
a. Hardware
Computadora DELL con 1 Terabyte de disco duro, procesador Core
i5 sexta generación, 6 Gigabytes de memoria RAM.
b. Software
CUADRO N° 14
HERRAMIENTAS DE SOFTWARE UTILIZADAS
HERRAMIENTAS DE SOFWARE
Eclipse IDE for Java EE Developers – Neon
MySQL Workbench 6.3 CE
MySQL Server 5.7
WildFly 10.1
Librería Log4j
SoapUI 5.3
Librería mysql-connector-java-5.1.40-bin
Fuente: Datos de Investigación.
Elaborado por: Jordy Peñaloza Bravo
c. Capacidad y conocimiento del personal Conocimiento en desarrollo de microservicios utilizando el lenguaje JAVA.
Conocimiento en administración de servidor de aplicaciones WildFly 10.
77
FACTIBILIDAD LEGAL El proyecto es legalmente factible ya que para el desarrollo se utilizó
herramientas Open Source además no viola ninguna de las leyes vigentes
de la actual constitución de la república.
FACTIBILIDAD ECONÓMICA En la siguiente tabla se muestran los datos del presupuesto que conlleva al
desarrollo del proyecto:
CUADRO N° 15
PRESUPUESTO DEL PROYECTO
RUBROS FUENTES
TOTAL ESTUDIANTES OTROS
Recursos Humanos 1 $8 la hora por
360 horas $2880
Recursos Hardware 0 0 0
Recursos Software 0 0 0
Viajes, Salidas de campo y movilización
1 $50 $50
Recursos Varios 0 0 0
Servicios técnicos 0 0 0
Alimentación 1 $80 $80
Total 0 0 $3010
Fuente: Datos de Investigación.
Elaborado por: Jordy Peñaloza Bravo
78
ETAPAS DE LA METODOLOGÍA DEL PROYECTO
Para el desarrollo de este proyecto se utilizó la metodología Ágil Scrum
para la gestión de todas las fases del proyecto
Los aspectos de la metodología que se tomaron en cuenta para el
desarrollo fueron:
Mayor interacción con el equipo de trabajo.
Entrega funcional de los servicios desarrollados.
Respuesta antes los nuevos requerimientos no contemplados.
ENTREGABLES DEL PROYECTO
Los entregables del proyecto serán los microservicios creados para el
control del asma y de la diabetes, junto con el código fuente de los mismos.
También se incluyen los cuatros archivos WARS que se encuentran
alojados actualmente en el servidor de aplicaciones WildFly.
Como anexo se estregará los tutoriales para la creación del DataSource,
así como el tutorial para deployar los WARS en el servidor de aplicaciones.
CUADRO N° 16
LISTADO DE MICROSERVICIOS
TIPO URI DESCRIPCION
POST /queryCountries
Devuelve el listado de países
para el registro.
POST /validateRegister
Valida que el correo no haya
sigo registrado previamente.
79
POST
/updateComplementaryExams
Permite actualizar los
exámenes complementarios
de un paciente.
POST /registerComplementaryExams
Registra exámenes
complementarios
POST
/disassociateDoctorPatient
Permite desasociar a un doctor
que se encuentre asociado al
paciente
POST /associateDoctorPatient
Permite asociar un doctor a un
paciente
POST /updateMood
Permite actualizar un estado
de ánimo.
POST /registerGoogleFit
Permite registrar datos de
Google Fit
POST
/queryMedicationAlarmLog
Devuelve los medicamentos
registrados con sus
respectivas alarmas
POST /updateMedication
Permite actualizar una
medicación.
POST
/queryControlMedication
Devuelve las medicinas que ya
han sido tomadas por el
paciente
POST
/registerControlMedication
Permite registrar un
medicamento que ya fue
ingerido por el paciente
POST /registerMedication
Permite registrar una
medicación
POST
/registerAlarmMedication
Permite registrar una alarma
para el control de un
medicamento
80
POST /queryPeakFlowLog
Devuelve los registros de Peak
Flow de un paciente
POST /queryAsthmaSymptoms
Devuelve los síntomas del
asma
POST /queryAsthmaDesencadenantes
Devuelve los
desencadenantes del asma
POST /registerPeakFlow
Permite registrar los datos del
Peak Flow
POST /validateAccount
Permite registrarse en el
aplicativo Health Monitor UG
POST /queryWeightLog
Devuelve los registros del
peso del paciente
POST /updateWeight
Permite actualizar un registro
de peso
POST /registerWeight
Permite registrar el peso del
paciente
POST /queryGlucoseLog
Devuelve los registros de
glucosa del paciente
POST /updateGlucose
Permite actualizar un registro
de glucosa
POST /registerGlucose
Permite registrar la glucosa del
paciente
POST /queryCholesterolLog
Devuelve los registros de
colesterol del paciente
POST /updateCholesterol
Permite actualizar un registro
de colesterol
POST /registerCholesterol
Permite registrar el colesterol
del paciente
POST /queryInsulinLog
Devuelve los registros de
insulina del paciente
81
POST /updateInsulin
Permite actualizar un registro
de insulina
POST /registerInsulin
Permite registrar la insulina del
paciente
POST /queryAssociatedDoctor
Devuelve los doctores
asociados a un paciente
POST
/querySpecialties
Devuelve un listado con todas
las especialidades médicas
registradas
POST /registerPatientUser
Permite el registro de un
paciente en la aplicación
POST /updatePressure
Permite actualizar un registro
de presión
POST /registerPressure
Permite registrar la presión del
paciente
POST /registerMood
Permite registrar el estado de
ánimo de un paciente
POST /queryMoodLog
Devuelve los registros de
estado de ánimo del paciente
POST /queryDoctorsBySpecialty
Devuelve un listado de doctor
consultando por especialidad
Fuente: Datos de Investigación.
Elaborado por: Jordy Peñaloza Bravo
CRITERIOS DE VALIDACIÓN DE LA PROPUESTA
Según los resultados obtenidos en las encuestas presentados en el capitulo
III la arquitectura de microservicios propuesta permitirán que la aplicación
Health Monitor UG funcione de una manera muy fluida permitiendo que la
experiencia del usuario al usar la aplicación sea muy satisfactoria.
82
CRITERIOS DE ACEPTACIÓN DEL PRODUCTO O SERVICIO
En el siguiente cuadro se puede verificar el cumplimiento de los sprint
definidos por los requerimientos del proyecto en el área de Arquitectura.
CUADRO N° 17
CRITERIOS DE ACEPTACIÓN DEL PRODUCTO
Sprint N°
Tarea Cumplido
1
Creación del nuevo servicio para consulta de
estado de ánimo, cambiando el método de consulta
a POST y creación de petición en formato JSON
SI
2
Creación del nuevo servicio para insertar estado de
ánimo, cambiando el método de consulta a POST y
creación de petición en formato JSON
SI
3
Creación del nuevo servicio para consulta de
países, cambiando el método de consulta a POST
y creación de petición en formato JSON
SI
4
Creación del nuevo servicio para crear registro de
paciente, cambiando el método de registro a POST
y creación de petición en formato JSON
SI
5
Creación del nuevo servicio para vincular doctor
paciente, se hace cambio para que el proceso llame
al procedimiento de base de datos, se cambia
request y response por Json y se cambia el método
por post.
SI
6
Creación del nuevo servicio para desvincular doctor
paciente, se hace cambio para que el proceso llame
al procedimiento de base de datos, se cambia
SI
83
request y response por Json y se cambia el método
por post.
7
Creación del nuevo servicio para consultar doctor
por especialidad, se hace cambio para que el
proceso llame al procedimiento de base de datos,
se cambia request y response por Json y se cambia
el método por post.
SI
8
Creación del nuevo servicio para consultar todos
los doctores asociados a un paciente, se hace
cambio para que el proceso llame al procedimiento
de base de datos, se cambia request y response
por Json y se cambia el método por post.
SI
9
Creación del nuevo servicio para registrar
medicación, se hace cambio para que el proceso
llame al procedimiento de base de datos, se cambia
request y response por Json y se cambia el método
por post.
SI
10
Creación del nuevo servicio para actualizar la
medicación de un paciente, se hace cambio para
que el proceso llame al procedimiento de base de
datos, se cambia request y response por Json y se
cambia el método por post.
SI
11
Creación del nuevo servicio para registrar Google
Fit, se hace cambio para que el proceso llame al
procedimiento de base de datos, se cambia request
y response por Json y se cambia el método por
post.
SI
12
Creación del nuevo servicio para consultar
exámenes complementarios, se hace cambio para
que el proceso llame al procedimiento de base de SI
84
datos, se cambia request y response por Json y se
cambia el método por post.
13 Implementación y pruebas de los servicios en
desarrollo SI
14 Pase a producción de los servicios SI
15 Pruebas de integración y estabilización de los servicios SI
Fuente: Datos de Investigación.
Elaborado por: Jordy Peñaloza Bravo
85
CONCLUSIONES Y RECOMENDACIONES
CONCLUSIONES
➢ Con el presente trabajo de titulación se pudo comprobar que los
microservicios creados con una arquitectura tipo Rest son ideales
para la implementación con la plataforma Android ya que tienen un
alto performance, escalabilidad y estabilidad permitiendo que la
aplicación móvil Health Monitor UG tenga una mejor fluidez en su
uso, al contrario que los servicios con arquitectura tipo SOAP que
son más difíciles de implementar con la plataforma Android.
➢ Una vez restructuradas las Apis existentes para registro, consultas,
y actualización de la información de la diabetes se pudo integrar la
nuevas Apis para el manejo de la información del asma, además la
arquitectura creada va a permitir que se pueda crear Apis para otras
enfermedades permitiendo la escalabilidad de los microservicios.
➢ El cambio de método de GET a POST que se realizó a las Apis
existentes para el control de la diabetes permitió que la información
del paciente no sea expuesta aumentando la confidencialidad en el
manejo de la información.
➢ El Formato JSON que se implementó para el envío y recepción de
información tanto en las Apis de la diabetes, así como la del asma
permitió manejar una estructura de datos más compleja tanto para
el envío como en la recepción de datos, esto fue posible gracias al
cambio de método de GET a POST ya que al haber pasado los datos
en métodos GET se hubiese complicado la interpretación de los
mismos.
86
RECOMENDACIONES
➢ Se recomienda que para futuras implementaciones de los
microservicios estos sean sometidos a pruebas de estrés para
asegurar que el aumento del uso de la aplicación Health Monitor UG
no afecte a los microservicios.
➢ Se recomienda que las Apis que se vayan a implementar en un
futuro para que la aplicación maneje otras enfermedades siga la
misma estructura de las Apis creadas para asegurar la escalabilidad
de los microservicios.
➢ Se recomienda que los nuevos microservicios que se vayan a crear
se utilice el método POST de HTTP ya que la información que se
maneja del paciente no debe de ser expuesta, además manejar
algún tipo de encriptación para que los datos del paciente se
encripten antes de ser transmitidos en la red.
➢ Se recomienda usar el formato JSON cuando se trabaja con una
arquitectura de microservicios tipo REST ya que cuando se transmite
datos por medio de la red JSON es más ligero en comparación a
XML además JSON es un formato más sencillo y rápido leer y
escribir además no requiere validación.
87
BIBLIOGRAFÍA
Box, D. E. (2012). Obtenido de Simple object access protocol (SOAP)
1.2.: https://www.researchgate.net/profile/Satish_Thatte/publication/
274074544_Simple_Object_Access_Protocol_SOAP_12
Constitucional, T. (11 de 03 de 2004). Registro Oficial 290 . Ley
deprevención, protección y atención de la diabetes. Quito,
Pichincha,Ecuador.
Bray, T. (2013). Obtenido de The JavaScript Object Notation (JSON) Data
Interchange Format: https://buildbot.tools.ietf.org/html/rfc7158
digitalguide. (25 de 10 de 2016). Obtenido de digitalguide:
https://www.1and1.es/digitalguide/servidores/know-how/servidor-
web-definicion-historia-y-programas/
Dhara, K. M. (2015). A Survey Paper on Service Oriented Architecture
Approach and Modern Web Services..
INEC. (5 de Septiembre de 2014). Obtenido de ecuadorencifras:
http://www.ecuadorencifras.gob.ec/diabetes-y-enfermedades-
hipertensivas-entre-las-principales-causas-de-muerte-en-el-2013/
INEC. (Junio de 2016). Obtenido de ecuadorencifras:
http://www.ecuadorencifras.gob.ec/documentos/web-
inec/Poblacion_y_Demografia/Nacimientos_Defunciones/2016/Anu
ario%20Nacimientos%20y%20Defunciones%202016.xlsx
88
javatutoriales. (23 de 04 de 2011). Obtenido de javatutoriales:
http://www.javatutoriales.com/2011/04/log4j-para-creacion-de-
eventos-de-log.html
López, D. &. (07 de 2017). Obtenido de Arquitectura de Software basada
en Microservicios para Desarrollo de Aplicaciones Web:
http://dspace.redclara.net:8080/bitstream/10786/1277/1/93%20Arq
uitectura%20de%20Software%20basada%20en%20Microservicios
%20para%20Desarrollo%20de%20Aplicaciones%20Web.pdf
Gonzales, J. M. (26 de 11 de 2015). Obtenido de Desarrollo de una API
para la descripción y gestión de Servicios Web REST:
http://repositori.uji.es/xmlui/bitstream/handle/10234/156006/TFM_2
014_puertaJ.pdf
Muschett, B. (04 de 08 de 2011). Obtenido de usando WebSphere
DataPower SOA Appliances:
https://www.ibm.com/developerworks/ssa/websphere/library/techarti
cles/0912_muschett/0912_muschett.html
Nadareishvili, I. M. (2016). Microservice Architecture: Aligning Principles,
Practices, and Culture. O'Reilly Media, Inc.
OMS. (9 de Julio de 2013). World Health Organization. Obtenido de who:
http://www.who.int/respiratory/asthma/es/
paho. (13 de Noviembre de 2014). Obtenido de Pan American Health
Organization:
http://www.paho.org/ecu/index.php?option=com_content&view=arti
cle&id=1400:la-diabetes-un-problema-prioritario-de-salud-publica-
en-el-ecuador-y-la-region-de-las-americas&Itemid=360
89
Rouse, M. (12 de 2016). Obtenido de techtarget:
http://searchdatacenter.techtarget.com/es/definicion/Servidor-Web
Schenone, D. S. (29 de 07 de 2011). Obtenido de XML y Tecnologías
Relacionadas: Introducción:
https://www.ibm.com/developerworks/ssa/local/webservices/wa-
xml-related-intro/index.html
SOA. (14 de 10 de 2009). Obtenido de soa-manifesto: http://www.soa-
manifesto.org/default_spanish.html
unav. (2011). Obtenido de unav:
http://www.esi.unav.es/Asignaturas/Informat2/Clases/Clases9899/C
lase01/JavaIntro/tsld002.htm
ANEXOS
ANEXO 1
CRONOGRAMA GENERAL DE TRABAJO
ACTIVIDADES Responsable
Junio Julio Agosto Septiembre
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
FASE DE PLANIFICACIÓN
1. Creación del nuevo servicio para
consulta de estado de ánimo, cambiando
el método de consulta a POST y creación
de petición en formato JSON
Jordy Peñaloza X
2. Creación del nuevo servicio para
inserta estado de ánimo, cambiando el
método de consulta a POST y creación de
petición en formato JSON
Jordy Peñaloza
X
3. Creación del nuevo servicio para
consulta de países, cambiando el método
de consulta a POST y creación de petición
en formato JSON
Jordy Peñaloza
X
4. Creación del nuevo servicio para crear
registro de paciente, cambiando el
método de registro a POST y creación de
petición en formato JSON
Jordy Peñaloza X
5. Creación del nuevo servicio para
vincular doctor paciente, se hace cambio
para que el proceso llame al
procedimiento de base de datos, se
cambia request y response por Json y se
cambia el método por post.
Jordy Peñaloza X
6. Creación del nuevo servicio para
desvincular doctor paciente, se hace
cambio para que el proceso llame al
procedimiento de base de datos, se
cambia request y response por Json y se
cambia el método por post.
Jordy Peñaloza X
7. Creación del nuevo servicio para
consultar doctor por especialidad, se hace
cambio para que el proceso llame al
procedimiento de base de datos, se
cambia request y response por Json y se
cambia el método por post.
Jordy Peñaloza X
8. Creación del nuevo servicio para
consultar todos los doctores asociados a
un paciente, se hace cambio para que el
proceso llame al procedimiento de base
de datos, se cambia request y response
por Json y se cambia el método por post.
Jordy Peñaloza X
9. Creación del nuevo servicio para
registrar medicación, se hace cambio
para que el proceso llame al
procedimiento de base de datos, se
cambia request y response por Json y se
cambia el método por post.
Jordy Peñaloza X
10. Creación del nuevo servicio para
actualizar la medicación de un paciente,
se hace cambio para que el proceso llame
al procedimiento de base de datos, se
cambia request y response por Json y se
cambia el método por post.
Jordy Peñaloza X
11. Creación del nuevo servicio para
registrar Google Fit, se hace cambio para
que el proceso llame al procedimiento de
base de datos, se cambia request y
response por Json y se cambia el método
por post.
Jordy Peñaloza X
12. Creación del nuevo servicio para
consultar exámenes complementarios, se
hace cambio para que el proceso llame al
procedimiento de base de datos, se
cambia request y response por Json y se
cambia el método por post.
Jordy Peñaloza X
13. Implementación y pruebas de los
servicios en desarrollo Jordy Peñaloza X
14. Pase a producción de los servicios Jordy Peñaloza X
15. Pruebas de integración y
estabilización de los servicios Jordy Peñaloza X
ANEXO 2
UNIVERSIDAD DE GUAYAQUIL
FACULTAD DE CIENCIAS MATEMATICAS Y FISICAS
CARRERA DE INGENIERIA EN SISTEMAS COMPUTACIONALES
SISTEMA DE AUTOGESTIÓN DE LA SALUD PARA PACIENTES CON
DIABETES Y ASMA, DESARROLLADO E IMPLEMENTADO EN UNA
PLATAFORMA ANDROID; CON MONITOREO DE UNA APLICACIÓN
WEB EN PHP DIRIGIDA A LOS MÉDICOS TRATANTES, ENFOCADO
EN EL DISEÑO E IMPLEMENTACIÓN DE UNA ARQUITECTURA
DE MICROSERVICIOS USANDO TECNOLOGÍA JAVA PARA LA
INTEGRACIÓN DE LA PLATAFORMA ANDROID CON
LA BASE DE DATOS MYSQL.
MANUAL DE INSTALACIÓN DEL SERVIDOR DE APLICACIONES
Previa a la obtención del Título de:
INGENIERO EN SISTEMAS COMPUTACIONALES
AUTOR: JORDY LUIS PEÑALOZA BRAVO
TUTOR: Ing. Fabricio Sánchez
GUAYAQUIL – ECUADOR
2017
2
ÍNDICES DE IMÁGENES
Imagen N° 1
Directorio del servidor WildFly ............................................................................. 3
Imagen N° 2
Ruta del archivo add_user.bat ............................................................................. 3
Imagen N° 3
Creacion de nuevo usuario .................................................................................. 4
Imagen N° 4
Mensajes de confirmación ................................................................................... 4
Imagen N° 5
Ubicación del archivo Standalone.bat .................................................................. 5
Imagen N° 6
Inicio de Sesión en el servidor ............................................................................. 5
Imagen N° 7
Imagen de bienvenida del Servidor ...................................................................... 6
3
Primero procederemos a descargar la última versión del servidor WildFly desde
su página oficial y de manera gratuita http://wildfly.org/downloads/.
Una vez culminada la descarga procederemos a descomprimir en la ruta donde
desean que este ubicado el servidor en nuestro caso será en el disco C:
Imagen N° 1
Directorio del servidor WildFly
Fuente: Datos de Investigación.
Elaborado por: Jordy Peñaloza Bravo
El siguiente paso será ubicarnos en la carpeta bin del servidor y buscar el archivo
add-user.bat y darle doble click para ejecutarlo
Imagen N° 2
Ruta del archivo add_user.bat
Fuente: Datos de Investigación.
Elaborado por: Jordy Peñaloza Bravo
4
Se nos mostrara la siguiente ventana donde ingresaremos la opción a para
agregar un nuevo usuario administrador, luego ingresaremos el nombre del
usuario a crear y el password.
Imagen N° 3
Creación de nuevo usuario
Fuente: Datos de Investigación.
Elaborado por: Jordy Peñaloza Bravo
En el siguiente mensaje solo daremos enter, luego ingresaremos yes, en los
siguientes dos mensajes que aparecen y finalmente presionamos una tecla para
terminar como se muestra en la siguiente imagen.
Imagen N° 4
Mensajes de confirmación
Fuente: Datos de Investigación.
Elaborado por: Jordy Peñaloza Bravo
Una vez creado el nuevo usuario procederemos a iniciar el servidor ejecutando el
archivo standalone.bat ubicado en la carpeta bin.
5
Imagen N° 5
Ubicación del archivo Standalone.bat
Fuente: Datos de Investigación.
Elaborado por: Jordy Peñaloza Bravo
Luego procederemos a ingresar a la siguiente dirección en nuestro navegador
http://localhost:9990/console donde procederemos a ingresar el usuario y el
password que creamos.
Imagen N° 6
Inicio de Sesión en el servidor
Fuente: Datos de Investigación.
Elaborado por: Jordy Peñaloza Bravo
Una vez que nos registramos en el servidor nos mostrara la ventana de
bienvenida del servidor donde podremos administrar los wars de nuestras
aplicaciones.
7
ANEXO 3
ENCUESTA
1.- ¿Cómo calificaría usted el tiempo de respuesta de los microservicios?
Excelente
Bueno
Malo
Regular
2.- ¿Cómo calificaría usted el estándar y el tipo de petición utilizado para el envío de datos de los microservicios?
Excelente
Bueno
Malo
Regular 3.- Cree usted que el formato de salida JSON en un micro servicio es más entendible que el formato XML?
Sí
No
talvez
4.- ¿Qué tipo de arquitectura considera usted es recomendable para el uso en aplicaciones móviles?
REST
SOAP
OTROS
5- ¿Cree usted que los microservicios creados para la aplicación Health Monitor UG permitió que la aplicación alcance un rendimiento óptimo?
Sí
No
talvez
UNIVERSIDAD DE GUAYAQUIL FACULTAD DE CIENCIAS MATEMÁTICAS Y FÍSICAS
CARRERA DE INGENIERÍA EN SISTEMAS COMPUTACIONALES
APLICACIÓN MÓVIL HEALTHMONITOR DIABETES FCMF
MANUAL DE USUARIO
AUTOR: ANDRES OÑATE
MARCO POLO ADRIAN FIALLOS JESENIA QUITO
MIGUEL RODRIGUEZ
TUTOR: ING. FABRICIO FELIPE MEDINA PALACIOS, M. SC.
Guayaquil, SEPTIEMBRE de 2017
ÍNDICE
ÍNDICE ____________________________________________________________________________ 94
Descripción de la Aplicación ____________________________________________________________ 4
Descarga de la Aplicación ______________________________________________________________ 4
HEALTH MONITOR ___________________________________________________________________ 4
Pantalla de presentación de aplicación móvil ____________________________________________ 4
MENÚ PRINCIPAL ____________________________________________________________________ 5
Inicio de Sesión ____________________________________________________________________ 5
Creación de Cuenta y Registro de Datos_________________________________________________ 5
1.2 Menú de Opciones ______________________________________________________________ 8
1.2.1 CONTROLES DE SALUD ____________________________________________________________ 8
1.2.1.1 Glucosa ______________________________________________________________________ 9
1.2.1.1.1 Pestaña Registro _____________________________________________________________ 9
1.2.1.1.1.1 Pantalla de Registro de Glucosa ______________________________________________ 9
1.2.1.1.2 Pestaña Estadísticas ________________________________________________________ 10
1.2.1.2 PULSO ______________________________________________________________________ 10
1.2.1.2.1 Pestaña Registro __________________________________________________________ 10
1.2.1.2.1.1 Ingreso Manual del Pulso __________________________________________________ 11
1.2.1.2.1.2 Registro Automático ______________________________________________________ 11
1.2.1.2.2 Pestaña Estadísticas ________________________________________________________ 12
1.2.1.3 PRESIÓN ______________________________________________ ¡Error! Marcador no definido.
1.2.1.3.1 Pestaña Registro ____________________________________ ¡Error! Marcador no definido.
1.2.1.3.1.1 Pantalla de Registro de Presión Arterial _________________ ¡Error! Marcador no definido.
1.2.1.3.2 Pestaña Estadísticas __________________________________ ¡Error! Marcador no definido.
1.2.1.4 PESO _______________________________________________________________________ 12
1.2.1.4.1 Pestaña Registro __________________________________________________________ 12
1.2.1.4.1.1 Pantalla de Registro de Peso _______________________________________________ 13
1.2.1.4.2 Pestaña Conoce su IMC _________________________________ ¡Error! Marcador no definido.
1.2.1.4.3 Pestaña Calcule tu Peso Ideal __________________________ ¡Error! Marcador no definido.
1.2.1.4.4 Pestaña Estadísticas ________________________________________________________ 13
1.2.1.5 INSULINA ____________________________________________________________________ 14
1.2.1.5.1 Pestaña Registro __________________________________________________________ 14
_______________________________________________________________________________ 14
1.2.1.5.1.1 Pantalla de Registro de Insulina _____________________________________________ 14
1.2.1.5.2 Pestaña Estadísticas ________________________________________________________ 15
1.2.1.6 ESTADO DE ÁNIMO ____________________________________________________________ 15
1.2.1.6.1 Pestaña Registro __________________________________________________________ 15
1.2.1.6.1.1 Pantalla de Registro de Estado de Ánimo ______________________________________ 16
1.2.1.6.2 Pestaña Estadísticas ________________________________________________________ 16
1.2.1.7 MEDICINAS / MEDICAMENTOS ___________________________________________________ 17
1.2.1.7.1 Pestaña Control de Medicamentos ____________________________________________ 17
1.2.1.7.1.1 Registro de Control de Medicamentos ________________________________________ 17
1.2.1.7.2 Pestaña Registro de Medicamentos ___________________________________________ 18
1.2.1.7.2.1 Ingreso de Medicamentos _________________________________________________ 18
1.2.1.7.2.2 Configuración de Alarmas __________________________________________________ 19
1.2.1.7.2.2.1 Selección de días de la semana____________________________________________ 19
1.2.1.7.2.2.2 Ingreso de número de días _______________________________________________ 20
1.2.1.7.2.2.3 Ingreso de fecha _______________________________________________________ 20
1.2.1.7.2.2.4 Ingreso de hora ________________________________________________________ 21
1.2.1.7.2.2.5 Pantalla de Alarmas ____________________________________________________ 21
1.2.1.7.3 Pestaña Estadísticas ________________________________________________________ 22
1.2.1.8 ENFERMEDAD/ PATOLOGÍA _____________________________________________________ 22
1.2.1.8.1 Pestaña Registro Histórico ___________________________________________________ 22
1.2.1.8.1.1 Pantalla de Registro de Enfermedades ________________________________________ 23
1.2.1.9 EXÁMENES COMPLEMENTARIOS _________________________________________________ 23
1.2.1.9.1 Pestaña Colesterol _________________________________________________________ 23
1.2.1.9.2.1 Registro de Exámenes de Triglicéridos ________________________________________ 24
1.2.1.9.3.1 Registro de Exámenes de HBA1C ____________________________________________ 25
1.2.1.9.4 Pestaña Cetonas ______________________________________ ¡Error! Marcador no definido.
1.2.1.9.4.1 Registro de Exámenes de Cetonas _____________________ ¡Error! Marcador no definido.
1.2.1.10 DOCTOR ___________________________________________________________________ 25
1.2.1.10.1 Visualización de Datos del Doctor Vinculado ___________________________________ 26
1.2.2 EJERCICIOS & DIETA _____________________________________________________________ 26
1.2.2.1 RUTINAS DE EJERCICIOS ______________________________________________________ 26
1.2.2.1.1 Rutinas __________________________________________________________________ 26
1.2.2.2 ALIMENTACIÓN _______________________________________________________________ 28
1.2.2.2.1 Pestaña Registro __________________________________________________________ 28
1.2.2.2.1.1 Registro de Alimento _____________________________________________________ 29
1.2.2.2.2 Pestaña Dieta _____________________________________________________________ 29
1.2.3 NOTIFICACIONES MÉDICAS _______________________________________________________ 30
1.2.3.1 Pestaña Notificaciones _______________________________________________________ 30
1.2.3.2 Pestaña Tips _______________________________________________________________ 31
1.2.4 INFORMES ____________________________________________________________________ 31
1.2.5 REDES SOCIALES _______________________________________________________________ 32
1.2.6 MODULO DE ASMA______________________________________________________________ 34
1.2.6.1 Pantalla principal del módulo de asma____________________________________________ 35
1.2.6.2 Pantalla principal de registro de asma_______________________ _____________________ 35
1.2.6.3 Pantalla de síntomas de asma___________________________ _______________________ 36
1.2.6.4 Pantalla de desencadenantes de asma____________________________________________ 37
1.2.6.5 Pantalla de Con Registros de asma_______________________________________________ 37
1.2.6.6 Pantalla de estadísticas de asma_________________________________________________38
1.2.7 TUTORIALES DE APOYO___________________________________________________________ 39
1.2.7.1 Opción de tutoriales de apoyo__________________________________________________ 39
1.2.7.2 Pantalla de tutorial Restaurar Registros___________________________________________ 40
1.2.7.3 Pantalla de tutorial Crear Cuenta________________________________________________ 40
1.2.7.4 Pantalla de tutorial Recomendaciones____________________________________________ 41
1.2.7.5 Pantalla de tutorial Mis Doctores________________________________________________ 41
1.2.7.6 Pantalla de tutorial Enfermedad_________________________________________________ 42
Descripción de la Aplicación
La aplicación Health Monitor Diabetes FCMF es una aplicación para teléfonos inteligentes
Android versión 4.2 o posterior, que la cual está orientada a los usuarios con diabetes, y sirve
para llevar un control del tratamiento de la diabetes. La aplicación es nativa, por lo que las
conexiones son rápidas y la interfaz está simplificada para el uso en el teléfono. Las funciones
de esta aplicación es permitir el registro y consulta de los datos médicos de los pacientes para
así llevar el control detallado de los mismos, como por ejemplo registro del peso, glucosa,
insulina entre otras opciones que se detallaran más adelante.
Descarga de la Aplicación
Esta aplicación se puede descargar accediendo al sitio de la PlayStore de Google directamente
desde el Smartphone en la pestaña “Aplicaciones” donde podrá descargarla haciendo clic
directamente sobre la imagen del Smartphone, como se aprecia a continuación.
HEALTH MONITOR
Pantalla de presentación de aplicación móvil
MENÚ PRINCIPAL
El menú principal consta de dos secciones:
- Inicio de sesión
- Menú de Opciones
Elaboración: Andres Oñate. Fuente: Pantalla de Menú Principal
Inicio de Sesión
Para acceder a las opciones que brinda la aplicación el usuario deberá tener una cuenta, si no
cuenta con una el usuario deberá crear una cuenta de la siguiente manera:
Creación de Cuenta y Registro de Datos
Dar clic en el botón iniciar sesión, este nos mostrará la pantalla de
inicio de sesión, en la cual se puede realizar las siguientes
funcionalidades:
Elaboración: Andres Oñate. Fuente: Pantalla de Inicio de Sesión
➢ Iniciar sesión: En caso de poseer una cuenta ➢ Recuperar contraseña: Si el usuario posee una cuenta y no recuerda su contraseña,
podrá recuperar su contraseña ingresando su E-mail y presionando el botón “Restablecer Contraseña”, el sistema enviará al correo electrónico digitado una clave temporal, para poder iniciar sesión, una vez iniciada la sesión el sistema le pedirá cambiar la clave temporal.
Elaboración: Andres Oñate. Fuente: Pantalla de Recuperación de Ingreso de nueva contraseña
➢ Crear cuenta: Si el usuario no posee cuenta y desea registrarse para poder utilizar la
aplicación, deberá ingresar su información personal y presionar siguiente.
Elaboración: Andres Oñate. Fuente: Pantallas de Creación de Cuenta
➢ Crear cuenta con las credenciales de Facebook.
Elaboración: Jesenia Quito. Fuente: Pantalla de Crear cuenta con credenciales de Facebook
➢ Mostrar los datos de la cuenta de Facebook en la aplicación Health Monitor
con la foto del perfil.
Elaboración: Jesenia Quito.
Fuente: Pantalla de los datos del Facebook
1.2 Menú de Opciones
Dentro de la sección de menú de opciones tendemos el siguiente submenú:
➢ Control de salud (generales, diabetes, asma) ➢ Ejercicios y Dietas ➢ Notificaciones Médicas ➢ Informes ➢ Publicidad
Elaboración: Andrés Oñate. Fuente: Pantalla de Menú Principal
1.2.1 CONTROLES DE SALUD
Este menú consta de las siguientes opciones:
➢ Pulso y Presión ➢ Peso ➢ Estados de ánimo ➢ Enfermedad ➢ Complementarios ➢ Mis Doctores ➢ Glucosa ➢ Insulina ➢ Flujo Máximo
Elaboración: Andres Oñate. Fuente: Pantalla de Submenú de Controles de Salud
En los cuales cada una de las opciones permite el registro y visualización de gráficos estadísticos según la opción seleccionada.
1.2.1.1 Glucosa
Esta modulo permite el registro y visualización de la glucosa, así mismo nos permite visualizar de manera gráfica la evolución de la misma.
1.2.1.1.1 Pestaña Registro
En esta opción se muestran los últimos registros ingresados, la fecha de ingreso y la cantidad de Concentración en Miligramos / Decilitros registrados. Se visualiza un botón flotante en el cual al darle clic nos dirigirá a la pantalla de registro, o al darle clic en uno de los ítems se podrá actualizar los datos previamente registrado. Se visualiza un icono de una nube con un visto el cual nos indicara si ha sido enviado a la base de datos del servidor, caso contrato aparecerá un icono de una nube con un reloj.
Elaboración: Andrés Oñate. Fuente: Pantalla de Visualización del Módulo de Glucosa
1.2.1.1.1.1 Pantalla de Registro de Glucosa
Se registra la cantidad de Concentración de Glucosa en medida de miligramos o decilitros, la fecha de ingreso de la información y alguna observación no obligatoria, luego presionamos el botón guardar el sistema validará su información y mostrará una alerta de recomendación.
Elaboración: Andrés Oñate. Fuente: Pantalla de Registro del Módulo de Glucosa
1.2.1.1.2 Pestaña Estadísticas
Se presenta un gráfico estadístico por fecha de ingreso de la información registrada. Se podrá visualizar en modo offline los registros previamente ingresados. Permite filtrar por:
• Periodo Inicial: Fecha de Inicio de Búsqueda por Filtro.
• Periodo Final: Fecha Fin de Búsqueda por Filtro.
Elaboración: Andrés Oñate. Fuente: Pantalla de Estadísticas del Módulo de Glucosa
1.2.1.2 PULSO Y PRESIÓN
Esta modulo permite el registro de manera manual y automática, y la visualización del pulso, así mismo nos permite visualizar de manera gráfica la evolución de la misma. 1.2.1.2.1 Pestaña Registro
En esta opción se muestran los últimos registros ingresados, la fecha de ingreso y la cantidad de pulsaciones registradas PPM (Partes por millón), en esta pantalla nos muestra el botón +, el cual nos da la opción de ingreso manual o el ingreso automático. Al darle clic en uno de los ítems se podrá actualizar los datos previamente registrado. Se visualiza un icono de una nube con un visto el cual nos indicara si ha sido enviado a la base de datos del servidor, caso contrato aparecerá un icono de una nube con un reloj.
Elaboración: Andrés Oñate. Fuente: Pantalla de Visualización del Módulo de Pulso
1.2.1.2.1.1 Ingreso Manual del Pulso
Se registra el ritmo cardíaco del Pulso, se registra la presión sistólica y la presión diastólica la fecha de ingreso de la información, selección de Sección del día y alguna observación no obligatoria.
Elaboración: Andrés Oñate. Fuente: Pantalla de Visualización del Módulo de Pulso
1.2.1.2.1.2 Registro Automático
Esta pantalla permite calcular el pulso mientras coloca el dedo en el flash de la cámara.
1. Se crea una línea alrededor del círculo mientras se mide el
pulso.
2. Se completa la circunferencia y muestra el Ritmo Cardíaco.
3. Seleccionamos nuestra sección de medido
4. Ingresamos nuestra presión sistólica y nuestra presión diastólica.
5. De darse el caso añadimos una nota, observación.
6. Presionamos grabar
Elaboración: Andrés Oñate. Fuente: Pantalla de Visualización del Módulo de Pulso
1.2.1.2.2 Pestaña Estadísticas Se presenta un gráfico estadístico por fecha de ingreso de la información registrada. Permite filtrar por:
• Periodo Inicial: Fecha de Inicio de Búsqueda por Filtro.
• Periodo Final: Fecha Fin de Búsqueda por Filtro.
Elaboración: Andrés Oñate. Fuente: Pantalla de Estadísticas del Módulo de Pulso
1.2.1.4 PESO
Esta modulo permite el registro de manera manual y la visualización de la presión arterial Sistólica y Diastólica, así mismo nos permite visualizar de manera gráfica la evolución de la misma. 1.2.1.4.1 Pestaña Registro
En esta opción se muestran los últimos registros ingresados, la fecha de ingreso y la presión arterial sistólica y diastólica y el botón de ingreso el cual nos lleva a la pantalla de registro. Al darle clic en uno de los ítems se podrá actualizar los datos previamente registrado. Se visualiza un icono de una nube con un visto el cual nos indicara si ha sido enviado a la base de datos del servidor, caso contrato aparecerá un icono de una nube con un reloj. En el Cuadro de cabecera azul nos permite conocer tu índice de masa corporal calculando con el ultimo peso ingresado, automáticamente el sistema te mostrará el valor del IMC e indicará el tipo de peso (sobrepeso, peso normal etc.). Además, permitirá conocer cuál debería ser tu peso ideal dependiendo de tu altura.
Elaboración: Andrés Oñate
Fuente: Pantalla de Visualización del Módulo de Peso
1.2.1.4.1.1 Pantalla de Registro de Peso
Se registra el peso en kilogramos, tasa metabólica basal, DMO, % grasa, % de agua, masa muscular, la fecha de ingreso de la información y alguna observación no obligatoria, cabe indicar que el único valor obligatorio es el peso.
Elaboración: Andrés Oñate. Fuente: Pantalla de Registro del Módulo de Peso
1.2.1.4.4 Pestaña Estadísticas
Se presenta un gráfico estadístico por fecha de ingreso de la información registrada. Permite filtrar por:
• Periodo Inicial: Fecha de Inicio de Búsqueda por Filtro.
• Periodo Final: Fecha Fin de Búsqueda por Filtro
Elaboración: Andrés Oñate. Fuente: Pantalla de Estadísticas del Módulo de Peso
1.2.1.5 INSULINA
Esta modulo permite el registro de las dosis de insulina suministradas por el paciente, así mismo nos permite la visualización de los últimos registros ingresados, y un gráfico estadístico 1.2.1.5.1 Pestaña Registro
En esta opción se muestran los últimos registros ingresados como fecha de ingreso y unidades de insulina ingresadas y el botón de ingreso el cual nos lleva a la pantalla de registro. Al darle clic en uno de los ítems se podrá actualizar los datos previamente registrado. Se visualiza un icono de una nube con un visto el cual nos indicara si ha sido enviado a la base de datos del servidor, caso contrato aparecerá un icono de una nube con un reloj.
Elaboración: Andrés Oñate.
Fuente: Pantalla de Visualización del Módulo de Insulina 1.2.1.5.1.1 Pantalla de Registro de Insulina Se registra la dosis de insulina suministrada, la fecha de ingreso de la información y alguna observación no obligatoria.
Elaboración: Andrés Oñate. Fuente: Pantalla de Registro del Módulo de Insulina
1.2.1.5.2 Pestaña Estadísticas
Se presenta un gráfico estadístico por fecha de ingreso de la información registrada. Permite filtrar por:
• Periodo Inicial: Fecha de Inicio de Búsqueda por Filtro.
• Periodo Final: Fecha Fin de Búsqueda por Filtro
Elaboración: Andrés Oñate.
Fuente: Pantalla de Estadísticas del Módulo de Insulina
1.2.1.6 ESTADO DE ÁNIMO
Esta modulo permite el registro del estado de ánimo del paciente esto le permite al médico tratante cómo se siente el paciente diariamente.
1.2.1.6.1 Pestaña Registro
En esta opción se muestran los últimos registros ingresados como fecha de ingreso y el estado de ánimo por medio de una imagen que se acople a su estado y la descripción, ya sea triste, normal alegre, entre otros, y el botón de ingreso el cual nos lleva a la pantalla de registro. Al darle clic en uno de los ítems se podrá actualizar los datos previamente registrado. Se visualiza un icono de una nube con un visto el cual nos indicara si ha sido enviado a la base de datos del servidor, caso contrato aparecerá un icono de una nube con un reloj.
Elaboración: Andrés Oñate Fuente: Pantalla de Visualización del Módulo de Estado de Ánimo
1.2.1.6.1.1 Pantalla de Registro de Estado de
Ánimo
Se registra el estado de ánimo seleccionando la imagen que mejor se acople a su estado (triste, alegre, normal, cansado, entre otras), la fecha de ingreso de la información y alguna observación no obligatoria.
Elaboración: Andrés Oñate.
Fuente: Pantalla de Registro del Módulo de Estado de Ánimo
1.2.1.6.2 Pestaña Estadísticas
Se presenta un gráfico estadístico por fecha de ingreso de la información registrada. Permite filtrar por:
• Periodo Inicial: Fecha de Inicio de Búsqueda por Filtro.
• Periodo Final: Fecha Fin de Búsqueda por Filtro
Elaboración: Andrés Oñate. Fuente: Pantalla de Estadísticas del Módulo de Estado de Ánimo
1.2.1.7 MEDICINAS / MEDICAMENTOS
Esta modulo permite el registro y control de los medicamentos que el paciente ha debe ingerir, así mimo podrá visualizar los registros ingresados. 1.2.1.7.1 Pestaña Control de Medicamentos
En esta opción se muestran un listado de los medicamentos que se le han recetado al paciente así mismo la cantidad y la frecuencia que debe ingerirlo al diariamente.
Elaboración: Marco Polo Espinoza
Fuente: Pantalla de Control del Módulo de Medicamentos
1.2.1.7.1.1 Registro de Control de Medicamentos En esta opción permite el registro de los medicamentos recetados por médico, aquí se registrará el medicamento, la presentación, vía de administración y una descripción opcional.
Elaboración: Marco Polo Espinoza
Fuente: Pantalla de Ingreso Control del Módulo de Medicamentos
1.2.1.7.2 Pestaña Registro de Medicamentos
En esta opción muestra el registro de los medicamentos que el paciente registrados en la pantalla de ingreso de medicamentos. Elaboración: Marco Polo Espinoza
Fuente: Pantalla de Visualización de Registros del Módulo de Medicamentos
1.2.1.7.2.1 Ingreso de Medicamentos En esta opción permite el registro de los medicamentos recetados suministrados por el paciente, aquí se registrará el medicamento, la dosis y descripción opcional.
Elaboración: Marco Polo Espinoza
Fuente: Pantalla de Registro del Módulo de Medicamentos
1.2.1.7.2.2 Configuración de Alarmas
En esta opción el usuario logra configurar alarmas para la toma del medicamento por hora, tiempo y número de veces al día que debe ser consumido el medicamento. Elaboración: Marco Polo Espinoza
Fuente: Pantalla Configuración de alarmas
1.2.1.7.2.2.1 Selección de días de la semana
Esta opción permite al usuario seleccionar los días de la semana en que debe ser administrado el medicamento. Elaboración: Marco Polo Espinoza
Fuente: Pantalla Selección de días
1.2.1.7.2.2.2 Ingreso de número de días
Esta opción permite registrar el número de días en que debe consumirse el medicamento. Elaboración: Marco Polo Espinoza
Fuente: Pantalla Ingreso número de días
1.2.1.7.2.2.3 Ingreso de fecha
Esta opción permite registrar las fechas en que debe consumirse el medicamento Elaboración: Marco Polo Espinoza
Fuente: Pantalla Configurar fechas
1.2.1.7.2.2.4 Ingreso de hora
Esta opción permite registrar la hora en que se debe consumir el medicamento.
Elaboración: Marco Polo Espinoza Fuente: Pantalla Configurar hora
1.2.1.7.2.2.5 Pantalla de Alarmas
En esta pantalla se visualiza la configuración de las alarmas por periodos del día mañana, mediodía, tarde y noche.
Elaboración: Marco Polo Espinoza Fuente: Pantalla de alarmas
1.2.1.7.3 Pestaña Estadísticas
Se presenta un gráfico estadístico por fecha de ingreso de la información registrada. Permite filtrar por:
• Periodo Inicial: Fecha de Inicio de Búsqueda por Filtro.
• Periodo Final: Fecha Fin de Búsqueda por Filtro
Elaboración: Marco Polo Espinoza.
Fuente: Pantalla de Estadísticas del Módulo de Medicamentos
1.2.1.8 ENFERMEDAD/ PATOLOGÍA
Esta opción permite el registro y presentación de las enfermedades que registre el usuario. 1.2.1.8.1 Pestaña Registro Histórico
En esta opción se muestran las enfermedades ingresadas por el usuario y la fecha de ingreso, también tiene un botón el cual permite ir a la pantalla de ingreso de enfermedades.
Elaboración: Marco Polo.
Fuente: Pantalla de Visualización de Registro Histórico del Módulo de Enfermedades
1.2.1.8.1.1 Pantalla de Registro de Enfermedades
Se registra la patología que presenta el usuario, en el campo buscar patología el sistema le mostrará una lista de patologías y el usuario deberá escoger una, también debe ingresar la fecha de registro y una observación opcional y guardar.
Elaboración: Marco Polo.
Fuente: Pantalla de Registro del Módulo de Enfermedades
1.2.1.9 EXÁMENES COMPLEMENTARIOS
Esta opción permite al usuario registrar los resultados de los exámenes complementarios a la diabetes, esto le permitirá al usuario llevar control de dichos exámenes, tales como:
✓ Colesterol y Triglicéridos ✓ HBA1C y Cetonas
1.2.1.9.1 Pestaña Colesterol Y Triglicéridos
En esta opción se muestran los últimos registros ingresados, la fecha de ingreso de colesterol, e triglicéridos presionando el botón de ingreso el cual nos lleva a la pantalla de registro. Al darle clic en uno de los ítems se podrá actualizar los datos previamente registrado. Se visualiza un icono de una nube con un visto el cual nos indicara si ha sido enviado a la base de datos del servidor, caso contrato aparecerá un icono de una nube con un reloj.
Elaboración: Andrés Oñate. Fuente: Pantalla de Visualización de Registros de Colesterol
1.2.1.9.2.1 Registro de Exámenes de Colesterol y Triglicéridos
Esta pantalla le permite al usuario el ingreso de la cantidad de Colesterol y triglicéridos, colesterol ldl y hdl la fecha de ingreso y una observación opcional y guardar lo ingresado.
Elaboración: Andrés Oñate.
Fuente: Pantalla de Registros de Colesterol
1.2.1.9.3 Pestaña HBA1C
En esta opción se muestran los últimos registros ingresados, la fecha de ingreso de HBA1C y Cetonas, presionando el botón de ingreso el cual nos lleva a la pantalla de registro. Al darle clic en uno de los ítems se podrá actualizar los datos previamente registrado. Se visualiza un icono de una nube con un visto el cual nos indicara si ha sido enviado a la base de datos del servidor, caso contrato aparecerá un icono de una nube con un reloj.
Elaboración: Andrés Oñate. Fuente: Pantalla de Visualización de Registros
de Hemoglobina Glucosada del Módulo de Exámenes Complementarios
1.2.1.9.3.1 Registro de Exámenes de HBA1C
Esta pantalla le permite al usuario el ingreso de la cantidad de HBA1C, la fecha de ingreso y una observación opcional y guardar lo ingresado.
Elaboración: Andrés Oñate. Fuente: Pantalla de Visualización de Registros
de Hemoglobina Glucosada del Módulo de Exámenes Complementarios
1.2.1.10 MIS DOCTORES
Esta opción permite vincular doctor al paciente, mediante un listado de especialidades con sus respectivos doctores, el usuario debe escoger un doctor, esta acción servirá para enviarle los informes al médico vinculado para que tenga un detalle del control que está llevando el paciente.
ElabElaboración: Miguel Rodríguez. Fuente: Pantalla de Selección de Doctores del Módulo Doctor
1.2.1.10.1 Visualización de Datos del Doctor Vinculado
Permite la visualización de los datos personales del doctor seleccionado. Además de un botón que le permite desvincularse del doctor en caso de que no quiera seguir el control con él
. Elaboración: Miguel Rodríguez. Fuente: Pantalla de Visualización de Datos del Doctor en Módulo Doctor
1.2.2 EJERCICIOS & DIETA
Este menú consta de dos opciones:
➢ Rutinas de ejercicios ➢ Alimentación
Elaboración: Miguel Rodríguez Fuente: Pantalla de Submenú de Ejercicios & Dietas
1.2.2.1 RUTINAS DE EJERCICIOS
Esta opción le permite al usuario llevar un control de los ejercicios realizados: 1.2.2.1.1 Rutinas
En esta pantalla se mostrará una lista de rutinas para que el usuario escoja la que mejor le convenga, para seleccionar la rutina se debe realizar lo siguiente:
• Damos clic en la imagen de la rutina que va a elegir
Se muestra una pantalla con el listado de ejercicios que componen la rutina dependiendo si la enfermedad a tratar es asma o diabetes
• Presionamos el botón Visto.
• Se muestra una pantalla donde se visualiza el nombre del ejercicio y la descripción de cuantas repeticiones debe realizar en un determinado tiempo.
• Se debe presionar el botón visto para mostrar el siguiente ejercicio una vez completado todo el listado de ejercicios, se muestra la pantalla de listado de ejercicios un visto indicando que los ejercicios han sido concluidos y mostrar en la parte superior unas estrellas para que el usuario pueda calificar la rutina.
Elaboración: Miguel Rodríguez.
Fuente: Pantalla de Módulo de Rutinas & Ejercicios.
• Una vez que el usuario haya calificado la rutina se guarda da clic en el botón visto para guardar la calificación de la rutina, la misma que servirá para el sistema de recomendación.
1.2.2.2 ALIMENTACIÓN
Esta opción le permite al usuario llevar un control de los alimentos que ingiere así mismo tendrá la opción de elegir una dieta y calificarla:
1.2.2.2.1 Pestaña Registro
Esta opción le permite al usuario visualizar los alimentos ingresados en la pantalla de registro de alimento, los datos mostrados son cantidad de caloría de dicho alimento, nombre del alimento, porcentaje de grasa que contiene dicho alimento.
Elaboración: Walter Toala P.
Fuente: Pantalla de Visualización del Módulo de Alimentos
1.2.2.2.1.1 Registro de Alimento
Esta opción le permite al usuario ingresar los alimentos que va a ingerir, se debe ingresar nombre del alimento, fecha de registro, porción, calorías, proteína, grasas carbohidratos, y luego se guarda la información registrada presionando el botón guardar. Elaboración: Walter Toala P. Fuente: Pantalla de Registro del Módulo de Alimentación
1.2.2.2.2 Pestaña Dieta
En esta opción le permite al usuario visualizar una dieta dependiendo de la cantidad de caloría que ingrese, esto se realiza de la siguiente manera. • Se debe ingresar la cantidad de calorías a ingerir • Presionamos el botón buscar • El sistema nos mostrar un listado de dietas a seguir por día • Seleccionamos la dieta que elija seguir
• Nos mostrará el detalle de la dieta el cual está dividido por secciones, desayuno, media mañana, almuerzo, media tarde y merienda, además del detalle de los alimentos que componen cada sección.
• El usuario debe calificar mediante las estrellas que se presentan en la parte superior de la pantalla, y luego guardar.
Elaboración: Walter Toala P. Fuente: Pantalla de Módulo de Alimentos
1.2.3 NOTIFICACIONES MÉDICAS
Esta opción nos permite visualizar las notificaciones que envía su médico tratante, de igual manera se visualizarán los tips de recomendación tanto para asma como para diabetes. 1.2.3.1 Pestaña Notificaciones
Esta opción permite visualizar al usuario las recomendaciones enviadas por su médico tratante, al seleccionar cada registro se mostrará más detalle de cada recomendación.
Elaboración: Miguel Rodríguez.
Fuente: Pantalla de Visualización de Notificaciones recibidas del Módulo de Notificaciones Médicas.
1.2.3.2 Pestaña Tips
Esta opción le permite visualizar al usuario los tips para asma y/o diabetes según el caso como una recomendación que el usuario puede seguir para mejor su salud.
Elaboración: Miguel Rodríguez. Fuente: Pantallas de Visualización de Notificaciones recibidas del Módulo de Notificaciones Médicas
1.2.4 INFORMES
Esta opción le permite al usuario generar un archivo PDF, con la información de todos los registros ingresados en las opciones:
✓ Insulina ✓ Peso ✓ Pulso y Presión arterial ✓ Glucosa ✓ Asma
El usuario tiene la opción de generar de forma individual o general
✓ De forma general se generará un informe de todas las opciones antes mencionadas ✓ De forma individual el usuario podrá escoger que opciones dese generar el informe ✓ Se debe escoger un rango de fechas de la cual desea ver información ✓ Una vez generado el archivo/ informe el usuario tiene la opción de visualizarlo o enviarlo
por correo al doctor vinculado.
Elaboración: Andrés Oñate.
Fuente: Generación de Informe PDF.
1.2.5 REDES SOCIALES
➢ Ingresa directamente a las redes sociales de la página oficial de Health Monitor, la primera pestaña encontramos el Twitter donde se encontrara información subida por Health Monitor y la segunda pestaña es interesante donde mostraran información de cómo prevenir y controlar la diabetes por el #diabetes.
Elaboración: Jesenia Quito Fuente: Pantalla de Twitter
➢ En la tercera pestaña se encuentra Facebook que muestra información subida por Health Monitor y la cuarta pestaña de la Comunidad los que son seguidores de la cuenta podrán comentar o publicar información acerca de la diabetes y asma.
Elaboración: Jesenia Quito Fuente: Pantalla de Facebook
Módulo de asma.
En esta parte es donde podemos entrar al
módulo de control de asma también conocido
como “FLUJO MAXIMO” ya que ese es el nombre
de lo que se registra.
Elaboración: Miguel Andrés Rodríguez Licoa
Fuente: Aplicación HealtMonitor UG- Salud App.
1.2.6.1 Pantalla principal del módulo de asma.
Esta es la pantalla principal de control de asma, esta pantalla se divide en 2 partes, la primera
es para ver los registros y la segunda es para ver las estadísticas de los registros ya hechos.
Para poder crear un registro nuevo se debe tocar el Floating Action Button, que es el botón con
un icono de esfero que se encuentra en la parte inferior derecha de la pantalla.
Elaboración: Miguel Andrés Rodríguez Licoa
Fuente: Aplicación HealtMonitor UG- Salud App.
1.2.6.2 Pantalla principal de registro de asma.
Elaboración: Miguel Andrés Rodríguez Licoa
Fuente: Aplicación HealtMonitor UG- Salud App.
En esta pantalla se registra el flujo máximo que maneja 3 rangos que indican la
situación del paciente, hora, fecha de registro y alguna observación como acotación a la al
registro.
1.2.6.3 Pantalla de síntomas de asma.
Elaboración: Miguel Andrés Rodríguez Licoa
Fuente: Aplicación HealtMonitor UG- Salud App.
Esta pantalla no aparece cuando el flujo máximo del paciente es normal, en ese caso solo
aparecerá una pantalla indicando algunas recomendaciones, ya que no se registrarían
novedades en cuanto al quebrando de salud.
1.2.6.4 Pantalla de desencadenantes de asma.
Elaboración: Miguel Andrés Rodríguez Licoa
Fuente: Aplicación HealtMonitor UG- Salud App.
Al igual que la pantalla anterior esta solo aparece cuando el flujo máximo es grave o
crítico, aquí se debe registrar el desencadenante de la crisis respiratoria.
1.2.6.5 Pantalla de Con Registros de asma.
Elaboración: Miguel Andrés Rodríguez Licoa
Fuente: Aplicación HealtMonitor UG- Salud App.
Luego de un registro exitoso podemos ver en la pantalla de registros.
Los datos que se han guardado y que serán enviados a los doctores especialistas los cuales
los recibirán y podrán visualizar mediante la página web.
Los registros en este caso se guardan con colores que se mostraran dependiendo del estado
del paciente.
1.2.6.6 Pantalla de estadísticas de asma.
Elaboración: Miguel Andrés Rodríguez Licoa
Fuente: Aplicación HealtMonitor UG- Salud App.
En este apartado se podrán ver las estadísticas de las crisis del paciente, lo cual se
podrá filtrar por fechas.
TUTORIALES DE APOYO
1.2.7.1 Opción de tutoriales de apoyo.
Elaboración: Miguel Andrés Rodríguez Licoa
Fuente: Aplicación HealtMonitor UG- Salud App.
En esta sección podemos acceder al apartado de tutoriales de apoyo que está
contenido dentro de la opción “CONFIGURACIONES”.
Pantallas de tutoriales.
1.2.7.2 Pantalla de tutorial Restaurar Registros.
Elaboración: Miguel Andrés Rodríguez Licoa
Fuente: Aplicación HealtMonitor UG- Salud App.
1.2.7.3 Pantalla de tutorial Crear Cuenta.
Elaboración: Miguel Andrés Rodríguez Licoa
Fuente: Aplicación HealtMonitor UG- Salud App.
1.2.7.4 Pantalla de tutorial Recomendaciones.
Elaboración: Miguel Andrés Rodríguez Licoa
Fuente: Aplicación HealtMonitor UG- Salud App.
1.2.7.5 Pantalla de tutorial Mis Doctores.
Elaboración: Miguel Andrés Rodríguez Licoa
Fuente: Aplicación HealtMonitor UG- Salud App.