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.


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

mailto:[email protected]

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












Proyecto de Titulación que se presenta como requisito para optar por el título de


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:









Considero aprobado el trabajo en su totalidad.

Presentado por:

Peñaloza Bravo Jordy Luis C.I.: 0930566252


Guayaquil, diciembre del 2017

IX



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.”

mailto:[email protected]

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


CUADRO N° 11 ....................................................................................... 46


CUADRO N° 12 ....................................................................................... 47


CUADRO N° 13 ....................................................................................... 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


GRÁFICO N° 2


GRÁFICO N° 3


GRÁFICO N° 4


GRÁFICO N° 5


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












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


XXII


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


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


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



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


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


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.


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.



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.



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



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



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


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.


GRÁFICO N° 1




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


¿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%



GRÁFICO N° 2




Análisis:


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


¿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%



GRÁFICO N° 3




Análisis:


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


¿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%



GRÁFICO N° 4




Análisis:


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


¿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%



GRÁFICO N° 5 RESULTADO DE LA PREGUNTA 5 DE LA ENCUESTA



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



50

ILUSTRACIÓN N° 17

EJEMPLO DE INTERFAZ PARA VALIDAR CUENTA

Y CONSULTAR PRESIÓN



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



51

ILUSTRACIÓN N° 19

CONFIGURACIÓN DE PROPERTIES LOG4J



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



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

.



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



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



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



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



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



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



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



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



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



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



63

Capturas del funcionamiento de los servicios desde un dispositivo Android

ILUSTRACIÓN N° 32

PANTALLA DE REGISTROS DE PEAK FLOW



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



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



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



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



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



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



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



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



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



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



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



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



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



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


de glucosa

POST /registerGlucose

Permite registrar la glucosa del

paciente

POST /queryCholesterolLog


colesterol del paciente

POST /updateCholesterol


de colesterol

POST /registerCholesterol

Permite registrar el colesterol

del paciente

POST /queryInsulinLog


insulina del paciente

81

POST /updateInsulin


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


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


estado de ánimo del paciente

POST /queryDoctorsBySpecialty

Devuelve un listado de doctor

consultando por especialidad



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


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


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


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



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


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


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


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


Jordy Peñaloza X


desvincular doctor paciente, se hace

cambio para que el proceso llame al




Jordy Peñaloza X


consultar doctor por especialidad, se hace

cambio para que el proceso llame al




Jordy Peñaloza X


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


registrar medicación, se hace cambio

para que el proceso llame al




Jordy Peñaloza X


actualizar la medicación de un paciente,

se hace cambio para que el proceso llame

al procedimiento de base de datos, se



Jordy Peñaloza X


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


consultar exámenes complementarios, se

hace cambio para que el proceso llame al




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


FACULTAD DE CIENCIAS MATEMATICAS Y FISICAS

CARRERA DE INGENIERIA EN SISTEMAS COMPUTACIONALES









MANUAL DE INSTALACIÓN DEL SERVIDOR DE APLICACIONES

Previa a la obtención del Título de:



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



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



http://wildfly.org/downloads/

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



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



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



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



Una vez que nos registramos en el servidor nos mostrara la ventana de

bienvenida del servidor donde podremos administrar los wars de nuestras

aplicaciones.

http://localhost:9990/console

6

Imagen N° 7

Imagen de bienvenida del Servidor

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


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.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.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.5 INSULINA ____________________________________________________________________ 14


_______________________________________________________________________________ 14

1.2.1.5.1.1 Pantalla de Registro de Insulina _____________________________________________ 14


1.2.1.6 ESTADO DE ÁNIMO ____________________________________________________________ 15


1.2.1.6.1.1 Pantalla de Registro de Estado de Ánimo ______________________________________ 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.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.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.


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


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 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


Se presenta un gráfico estadístico por fecha de ingreso de la información registrada. Permite filtrar por:


• 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






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.


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.


Fuente: Pantalla de Registro del Módulo de Estado de Ánimo





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.


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.


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





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.


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:


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.


Fuente: Generación de Informe PDF.

1.2.5 REDES SOCIALES

Twitter

➢ 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

Facebook

➢ 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.



1.2.6.2 Pantalla principal de registro de asma.



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.



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.



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.



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.



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.



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.



1.2.7.3 Pantalla de tutorial Crear Cuenta.



1.2.7.4 Pantalla de tutorial Recomendaciones.



1.2.7.5 Pantalla de tutorial Mis Doctores.



1.2.7.6 Pantalla de tutorial Enfermedad.



ingeniero en sistemas computacionales...

Documents