arquitectura de servicios móviles basada en internet de las cosas · 2021. 4. 20. · un modelo de...

ESCOM,CiudaddeMexico,MexicoEnero2019.

Instituto Politécnico Nacional Escuela Superior de Cómputo

Sección de Estudios de Posgrado e Investigación

Arquitectura de Servicios Móviles basada en IoT

TESISQUEPARAOBTENERELGRADODE

MaestrıaenSistemasComputacionalesMoviles

Presenta:

CERDAMARTÍNEZFRANCISCOJAVIER

Director:

M.enC.ChadwickCarretoArellano

Co-Director:

Dr.FelipeRolandoMenchacaGarcıa

Escuela Superior de Cómputo

Sección de Estudios de Posgrado e

Investigación

Arquitectura de Servicios Móviles basada

en Internet de las Cosas

TESIS QUE PARA OBTENER EL GRADO DE

Maestría en Sistemas Computacionales

Móviles

Presenta:

CERDA MARTÍNEZ FRANCISCO JAVIER

Director: M. en C. Chadwick Carreto ArellanoCo-Director: Dr. Felipe Rolando Menchaca García

ESCOM, Ciudad de México, México, Enero 2019.

El presente trabajo fue realizado en el Laboratorio de Proyectos e Investigación de

la Sección de Estudios de Posgrado e Investigación de la Escuela Superior de

Cómputo del Instituto Politécnico Nacional, ubicada en Av. Juan de Dios Bátiz S/N,

Nueva Industrial Vallejo, Ciudad de México, CDMX // CP 07738. Apoyo del

Instituto Politécnico Nacional, Beca Institucional Nivel Maestría y Beca de Tesis de

Maestria.

ResumenResumen

0.1. Abstract

The emergence of the term Internet of Things has generated several pro-blems, for example, services and the management of large volumes ofinformation, the generation of contextual systems, knowledge and the as-

sociation of di�erent de- vices to users, so that, in Multiple proposals have been es-tablished di�erent solutions but without defining a standard, it is for this reason,that in this work we propose an architecture that implements a service implemen-tation model to solve the needs of integrating and managing information so thatof diverse services,and the explanation about how we probed the architecture ina experimental chase.

Keywords

Internet of things, Architectures, Cloud Computing, Computing Modelsand Architectures

0.2. Resumen

La aparición del término Internet de las cosas ha generado varios proble-mas, por ejemplo, los servicios y la gestión de grandes volúmenes de in-formación, la generación de sistemas contextuales, el conocimiento y la

asociación de diferentes dispositivos a los usuarios, por lo que, en múltiples pro-puestas. Se han establecido diferentes soluciones, pero sin definir un estándar, espor esta razón que en este trabajo proponemos una arquitectura que implementaun modelo de implementación de servicios para resolver las necesidades de inte-gración y administración de la información de diferentes servicios y la explicaciónde Cómo probamos la arquitectura en una persecución experimental.

Keywords

Internet de las cosas, Arquitecturas y Modelos de Cómputo, Compu-tación en la Nube.

7

Resumen

8

AgradecimientosAgradecimientos

Agradezco a mis padres Fabiola y Francisco por brindarme la oportunidadde estudiar, además de contar con su apoyo siempre que los necesito,gracias padre por tus regaños y consejos que siempre han sido en el

momento adecuado para enderezar mi camino, gracias por tu gran ejemplo yenseñarme que es ser una persona de bien dedicada y entregada a su trabajo,y que “Las cosas se hacen bien o no se hacen”; a ti madre gracias por tu apoyopor tus consejos en mis momentos más obscuros así como en los más luminosos,gracias por siempre ser tan buena consejera y siempre darte un momento paraescucharme, gracias por el ejemplo que me has dado y por enseñarme a ser fuertey enfrentar los problemas de frente, a mis hermanos gracias porque siempre quelos necesite estuvieron ahí, gracias por enseñarme a sonreír y aprender a reírmede mi mismo; a mis tíos a todos y cada uno de ellos les agradezco porque todos mehan apoyado en distintas formas, gracias por enseñarme el valor y la importanciade la familia , a todos y cada uno de ustedes gracias ya que me han brindado ungran ejemplo, el cual ha logrado formarme como un hombre de bien y apoyo parala sociedad.

Agradezco a mis abuelos mamá Elo, mi abuelo Pancho y mi abuela Cota, yaque gracias a ustedes y a sus consejos me he convertido en la persona que soyen la actualidad, gracias por siempre estar ahí y sus muestras de afecto, ya queme enseñaron la importancia de ver la vida de una forma un poco más tranquilay pensar antes de actuar, por enseñarme que más vale el diablo por viejo que pordiablo, por lo cual siempre hay que escuchar a nuestros mayores ya que ellosson una gran fuente de conocimiento y experiencias que nos pueden servir desustento para enfrentar los desafíos que la vida nos presenta, y aunque ya no seencuentren a mi lado siempre estarán presentes en sus enseñanzas y ejemplos,así como en cada uno de los bellos momentos que pase a su lado.

Así mismo quiero agradecer a mi novia Atalia ya que ha sido mi compañera miconsejera, gracias por tu comprensión y cariño, por apoyarme en este trayecto demi vida.

Agradezco de igual forma a mis profesores que han sabido ser los guías ade-cuados para encaminarme en este gran viaje del saber, gracias porque me hanotorgado las herramientas necesarias para poder desempeñarme de una mejorforma en mi vida laboral, gracias por su comprensión y dedicación, Agradezco enespecial al profesor Chadwick porque ha sido un gran guía a lo largo del presentetrabajo así como también ha sido un gran ejemplo para mí.

Y por último pero no menos importante, no me queda más que agradecer amis compañeros, gracias amigos por compartir conmigo esta etapa de mi vida, esun gusto trabajar con ustedes.

9

Agradecimientos

Cerda Martínez Francisco Javier

10

ContenidoContenido

Resumen 70.1. Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70.2. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Agradecimientos 9

I Planteamiento del problema 19

1. Planteamiento del problema de investigación 211.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211.2. Antecedentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221.3. Formulación del Problema . . . . . . . . . . . . . . . . . . . . . . . 231.4. Pregunta de Investigación . . . . . . . . . . . . . . . . . . . . . . . . 251.5. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

1.5.1. Objetivo general . . . . . . . . . . . . . . . . . . . . . . . . . . 261.5.2. Objetivos especificos . . . . . . . . . . . . . . . . . . . . . . . 26

1.6. Justificación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261.7. Viabilidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

II Marco teórico 29

2. Marco Teórico 312.1. Sistemas comerciales de salud en la actualidad . . . . . . . . . . . . 31

2.1.1. Tap2Tag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312.1.2. Alerta Médica . . . . . . . . . . . . . . . . . . . . . . . . . . . 312.1.3. InfoVital . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312.1.4. PDC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

2.2. Marcos Normativos . . . . . . . . . . . . . . . . . . . . . . . . . . . 322.2.1. Norma Oficial Mexicana NOM-004-SSA3-2012, Del expediente

clínico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322.2.2. ISO/TS 18308:2004 Requerimientos para la Informática de la

Salud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322.2.3. Manual del Expediente Clínico Electrónico de la Secretaría de

Salud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332.2.4. Ley federal de protección de datos personales en poseción de

los particulares . . . . . . . . . . . . . . . . . . . . . . . . . . 342.3. Marco Conceptual . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

2.3.1. Cómputo en la nube . . . . . . . . . . . . . . . . . . . . . . . 35

11

CONTENIDO

2.3.1.1. Características esenciales . . . . . . . . . . . . . . . 352.3.1.2. Ventajas de la computación en la nube . . . . . . . . 362.3.1.3. Modelo de computacion en la nube . . . . . . . . . . 362.3.1.4. Modelo de implementación . . . . . . . . . . . . . . . 37

2.3.2. Arquitectura . . . . . . . . . . . . . . . . . . . . . . . . . . . 372.3.2.1. Arquitectura orientada a Servicios . . . . . . . . . . . 382.3.2.2. Micro servicios . . . . . . . . . . . . . . . . . . . . . . 382.3.2.3. Arquitectura PipeLine . . . . . . . . . . . . . . . . . . 392.3.2.4. Arquitectura Peer to Peer (Entre Pares) . . . . . . . . 392.3.2.5. Arquitectura Orientada a Eventos . . . . . . . . . . . 402.3.2.6. Arquitectura de Tres Niveles . . . . . . . . . . . . . . 40

2.3.3. Internet de las cosas . . . . . . . . . . . . . . . . . . . . . . . 412.3.3.1. Modelo del Internet de Las Cosas . . . . . . . . . . . 42

2.3.4. Redes de Cómputo . . . . . . . . . . . . . . . . . . . . . . . . 452.3.4.1. Redes de Sensores . . . . . . . . . . . . . . . . . . . 45

2.3.5. Protocolos de Comunicación . . . . . . . . . . . . . . . . . . . 452.3.5.1. Protocolo IEEE 802.4.15 . . . . . . . . . . . . . . . . 452.3.5.2. ZigBee . . . . . . . . . . . . . . . . . . . . . . . . . . 462.3.5.3. Digi Mesh . . . . . . . . . . . . . . . . . . . . . . . . 462.3.5.4. Thread . . . . . . . . . . . . . . . . . . . . . . . . . . 47

2.3.6. Middleware . . . . . . . . . . . . . . . . . . . . . . . . . . . . 482.3.7. OAUTH 2.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

III Metodología 51

3. Metodología 53

3.1. Metodología de Investigación . . . . . . . . . . . . . . . . . . . . . . 533.2. Características buscadas dentro de la Arquitectura . . . . . . . . . . 543.3. Definición de módulos de la arquitectura . . . . . . . . . . . . . . . 553.4. Problemáticas encontradas y como resolverlas . . . . . . . . . . . . 56

3.4.1. La falta de recursos . . . . . . . . . . . . . . . . . . . . . . . 563.4.2. Tecnología propia . . . . . . . . . . . . . . . . . . . . . . . . . 563.4.3. Complejidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . 563.4.4. Seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 573.4.5. Dispositivos heterogéneos . . . . . . . . . . . . . . . . . . . . 57

3.5. Especificación de la Arquitectura . . . . . . . . . . . . . . . . . . . . 583.5.1. Middleware . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

3.5.1.1. Control de Replica de Tramas . . . . . . . . . . . . . 583.5.1.2. Gestión y Decodificación de Tramas . . . . . . . . . . 593.5.1.3. Manejo de Nodo de Origen Destino . . . . . . . . . . . 59

12

CONTENIDO

3.5.1.4. Manejo de Peticiones . . . . . . . . . . . . . . . . . . 593.5.2. Arquitectura de Conexión de Servicios . . . . . . . . . . . . . 60

3.5.2.1. Módulo de Control de Acceso . . . . . . . . . . . . . . 603.5.2.2. Módulo de Control de Perfiles . . . . . . . . . . . . . 613.5.2.3. Módulo de Interconexión con Múltiples Servicios . . . 613.5.2.4. Módulo de Interconexión de Servicios Internos . . . . 61

3.6. Arquitectura Propuesta . . . . . . . . . . . . . . . . . . . . . . . . . 623.6.1. Tecnologías Usadas . . . . . . . . . . . . . . . . . . . . . . . . 62

3.6.1.1. Middleware . . . . . . . . . . . . . . . . . . . . . . . 623.6.1.2. Arquitectura de Interconexión de Servicios . . . . . . 643.6.1.3. Sistema de Registro de Errores . . . . . . . . . . . . . 663.6.1.4. Enrutador de Peticiones (API Gateway) . . . . . . . . 663.6.1.5. Contenedor Linux . . . . . . . . . . . . . . . . . . . . 663.6.1.6. Automatizador de Mensajes . . . . . . . . . . . . . . 67

3.7. Caso de Estudio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 683.8. Metodología de Desarrollo . . . . . . . . . . . . . . . . . . . . . . . . 71

3.8.1. Características Principales . . . . . . . . . . . . . . . . . . . . 71

IV Resultados 75

4. Resultados 774.1. Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 774.2. Productos de Investigación . . . . . . . . . . . . . . . . . . . . . . . 83

V Conclusiones 85

5. Conclusiones 875.1. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

VI Trabajo Futuro 89

6. Trabajo Futuro 916.1. Trabajo Futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

Bibliografía 96

VII Anexos 97

13

CONTENIDO

14

Lista de FigurasLista de Figuras

3.1. Pasos realizados a lo largo de la Investigación . . . . . . . . . . . . 533.2. Módulos de la arquitectura . . . . . . . . . . . . . . . . . . . . . . . 553.3. Middleware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 583.4. Módulo de conexión de servicios . . . . . . . . . . . . . . . . . . . . 603.5. Arquitectura de Servicios con Tecnología . . . . . . . . . . . . . . . 623.6. Carnet de Servicios Politécnicos . . . . . . . . . . . . . . . . . . . . 683.7. Diagrama de Bloques de la solución . . . . . . . . . . . . . . . . . . 703.8. Diagrama de SCRUM [1] . . . . . . . . . . . . . . . . . . . . . . . . 73

4.1. Estadísticas de Api Gateway parte 1 . . . . . . . . . . . . . . . . . . 794.2. Estadísticas de Api Gateway parte 2 . . . . . . . . . . . . . . . . . . 794.3. Estadísticas de los Micro servicios parte 1 . . . . . . . . . . . . . . 804.4. Estadísticas de los Micro servicios parte 2 . . . . . . . . . . . . . . 804.5. Estadísticas de Sentry parte 1 . . . . . . . . . . . . . . . . . . . . . 814.6. Estadísticas de Sentry parte 2 . . . . . . . . . . . . . . . . . . . . . 814.7. Estadísticas de Vault parte 1 . . . . . . . . . . . . . . . . . . . . . . 824.8. Estadísticas de Vault parte 2 . . . . . . . . . . . . . . . . . . . . . . 82

15

LISTA DE FIGURAS

16

Lista de TablasLista de Tablas

2.1. Análisis de Problemas y Soluciones en Redes Inalámbricas. . . . . . 43

17

LISTA DE TABLAS

18

I

Planteamiento del problema

Planteamiento del problema de investigaciónCapítulo 1: Planteamiento del problema deinvestigación

1.1. Introducción

La computación a evolucionado a pasos agigantados a lo largo de la historia,y ha ido modificándose según las necesidades que vayan surgiendo, asíse ha podido avanzar desde la creación de la UNIVAC a la aparición del

internet, entre otros muchos grandes aportes al área de la computación cada unode ellos enfrentaron dichas necesidades, además que se enfrentaron a diferentesdificultades y con esto se encargaron de romper los paradigmas ya existentes yproponer nuevos.

Así es como hemos llegado a esta nueva era la cual se de enfrenta a nuevasproblemáticas y paradigmas, entre los cuales destaca el Internet de la cosas oIoT por sus siglas en inglés (Internet of Things), este paradigma deja de ver a uncliente o usuario de una red únicamente como una computadora , sino por elcontrario muchos de los objetos que nos rodean estarán en la red de una formau otra, generando información [2], lo cual trae consigo muchas implicaciones aconsiderar.

El diseño de una arquitectura de software representa una de las mas tempra-nas decisiones en el diseño de un sistema y este tipo de decisión será de las mascriticas para el correcto funcionamiento de un sistema ya que esta arquitecturadefinirá muchas de las características que podrá alcanzar un sistema como loson: El desempeño en tiempo real, la adaptabilidad al cambio, la mantenibilidad,entre otros [3].

El término Internet de las Cosas fue acuñado por primera vez por Kevin Ash-ton en 1999 en el contexto de la gestión de la cadena de suministro [4] Así mismo, en la última década, la definición ha sido modificada para que esta abarqueuna extensa gama de servicios como lo puede ser: servicios públicos, atenciónde la salud, transporte, o cualquier otra necesidad de la vida cotidiana [5]. Unarevolucionaria perspectiva acerca del IoT concibe una red de objetos interconec-tados que no solo recolecte información del entorno (detección) e interactúa con elmundo físico (actuación/ mando/ control), sino que también requiere e implica laselección y empleó de estándares existentes de Internet para proporcionar servi-cios de Transferencia de Información, Análisis de aplicaciones y comunicacionesasí como el establecimiento de un formato de Intercambio [6].

Uno de los aspectos que el hombre a atendido con mayor esmero es garantizarsu salud y supervivencia por lo cual no es raro encontrar que una buena partede la tecnología utilizada hoy en día haya sido creada inicialmente o sea aplicadaen el campo médico, como ejemplo se están empleado diferentes tecnologías paraoptimizar el servicio de atención brindado a los pacientes con ayuda de sistemas

21

Capítulo 1. Planteamiento del problema de investigación

que automaticen el control de expediente clínico[7].

1.2. Antecedentes

El expediente clínico se trata de la recopilación de información detalladay ordenada cronológicamente con relación a la salud de un paciente y lade su familia en un periodo determinado de su vida. Representa la base

para conocer las condiciones de salud, los aspectos médicos y los diferentes pro-cedimientos que han sido solicitados y realizados por profesionales de la salud alo largo del proceso en el cual el paciente solicitó asistencia médica. Gracias a laimplementación de la tecnología el expediente clínico ahora es posible registrarlode manera electrónica, es decir, se almacenan de manera digital los datos delpaciente por medio de un sistema de información. Dichos datos son guardadose intercambiados de manera segura y confiable. A nivel mundial se han desarro-llado diferentes sistemas de información para llevar el registro de los expedientesclínicos electrónicos, tal es el caso de OpenEHR. OpenEHR es una comunidadvirtual que tiene como objetivo garantizar la interoperabilidad y la virtualizaciónen los sistemas electrónicos de salud, con un enfoque particular a los RegistrosElectrónicos de Pacientes (Electronic Health Record, EHR) [8].

La fundación OpenEHR ha publicado un conjunto de especificaciones en don-de se da un modelo de información de salud,un lenguaje para construir ‘modelosclínicos’ que son independientes del software [8].

Existen distintos gobiernos a Nivel Mundial que utilizan las especificacionesde OpenEHR como son:

Brasil. Se estableció el estándar TISS, el cual busca implementar softwareque utilice el modelo de referencia OpenEHR para intercambiar información. Di-namarca. Proyecto de prueba de concepto nacional. Nueva Zelanda. El estándarNeozelandés HISO 10040.2 Exchange Content Model, tiene su base en las espe-cificaciones de OpenEHR Reino Unido. El Servicio Nacional de Salud del ReinoUnido utiliza arquetipos de OpenEHR como una manera formal de capturar con-tenido clínico. Australia. Modelado de datos clínicos utilizando la metodología deOpenEHR[8].

Otro sistema que se puede mencionar es iN2015 (Singapur). Este proyectodestaca debido a la implantación de brazaletes RFID. En la actualidad, otrossistemas de salud públicos se encuentran en proyectos para poder implantarregistros de salud electrónicos. Ejemplo de ello es el iN2015 de Singapur, el cuales un proyecto a 10 años, con inicio en 2011. Este proyecto tiene como fin generarun sistema que abarca cinco dominios. Servicios de Registro de Salud Electrónico.Se fortalece el sistema de Identificación Nacional, Sistema de Identidad y Gestiónde Accesos así como la terminología e integración de los mismos. Además, se tiene

22

1.3 Formulación del Problema

la labor de parametrizar los datos de acuerdo a sufuente; sea de Diagnóstico,Servicios de vacunación, farmacología etc.

El registro médico contiene aspectos como lo son: Accidentes y episodios decuidado, problemas de salud, estudios de laboratorio, documentos clínicos, pro-cesos de vacunación, alertas, medicación, entre otros. El sistema está basado enOpenEHR, un estándar abierto para el desarrollo de registros médicos electróni-cos.

Portal Nacional de Salud: Tiene la visión de proporcionar un sistema baratoy efectivo, orientado al paciente en donde se puedan tener herramientas com-partidas para la gestión de la salud así como para la educación e investigaciónen materia de salud. Brazaletes RFID: Singapur planea otorgar un brazalete acada ciudadano. Estos brazaletes contendrán sus registros médicos así como lainformación que identifica a cada persona que puede ser utilizada para accederal registro médico del paciente Seguridad: Se utilizan políticas RBAC (control deacceso por roles) para tener un acceso seguro al registro médico del paciente. Laautorización del paciente se da a través de un modelo de consentimiento implí-cito, puesto que el consentimiento explícito puede no ser viable, particularmenteen situaciones de emergencia [9] .

1.3. Formulación del Problema

Con la nueva llegada de IoT (Internet de las Cosas ó Internet of Things porsus siglas en Inglés) surge la tecnología de redes de sensores lo cual nosacerca a una nueva problemática, en donde los sistemas de información y

comunicación nos rodean en nuestrosámbitos personales y profesionales lo cualtrae consigo la generación de enormes cantidades de Información y adicionalmen-te es necesario contar con algún sitio donde almacenar la información así comopresentarla, explotarla y tratarla de una forma fácilmente interpretable[2].

Internet of Things permite que los dispositivos (cosas) interactúen y se coor-dinen entre sí, reduciendo así la intervención humana en las tareas cotidianasbásicas. Una red de dispositivos / aplicaciones heterogéneas tiene su propio con-junto de desafíos. Además, como se espera que la comunicación entre estos dis-positivos, así como con los servicios relacionados, suceda en cualquier momentoy en cualquier lugar, con frecuencia se realiza de forma inalámbrica, autónoma yad-hoc. La seguridad es una preocupación importante al tratar con la definiciónestándar de IoT de Internet of Things aún no está disponible. Las empresas detodo el mundo están invirtiendo miles de millones en IoT para resolver problemasindustriales (IoT). El IoT se refiere a objetos industriales equipados con sensores,que se comunican automáticamente a través de una red, sin interacción de per-sona a persona o persona a computadora, para intercambiar información y tomar

23


decisiones inteligentes con el apoyo de análisis avanzados. La seguridad es unapreocupación importante al tratar con la definición estándar de IoT de Internet ofThings aún no está disponible Esta red de una variedad de objetos puede traeruna gran cantidad de desafíos en el desarrollo de aplicaciones y hacer que losdesafíos existentes sean más difíciles de abordar[10].

facilitar el desarrollo de aplicaciones mediante la integración de dispositivosinformáticos y de comunicaciones heterogéneos, y compatibilidad interoperabledentro de las diversas aplicaciones y servicios que se ejecutan en estos dispositi-vos. Se han desarrollado varios sistemas operativos para respaldar ese problema[10].

Residen en dispositivos físicos y proporcionan las funcionalidades necesariaspara habilitar la implementación del servicio. Internet de las cosas no es unatecnología única, es un concepto en el que la mayoría de las cosas nuevas estánconectadas.

La realidad aumentada, la comunicación de campo cercano se integran enel soporte de decisiones situacionales, la administración de activos y los nue-vos servicios. Estos brindan muchas oportunidades de negocios y aumentan lacomplejidad de IoT [11].

La inmensidad del Internet of Things (IoT) lo expone no solo a una serie devulnerabilidades, sino que los problemas de seguridad de Internet también apa-recen en IoT. La naturaleza inalámbrica de las señales hace que esta capa seasusceptible a los atacantes que pueden interceptar el nodo del sensor en los dis-positivos de IoT. Los nodos suelen operar en un entorno externo y esto culminaen ataques físicos a los sensores y dispositivos IoT en los que un atacante puedealterar los componentes de hardware del dispositivo. Dado que la informaciónsolía transmitirse a Internet con la ayuda de computadoras, redes inalámbricas/ por cable y otros componentes, esta capa está compuesta en gran parte porcomputadoras, redes inalámbricas o por cable. Debido a esto, enfrenta problemasde seguridad tales como seguridad de contenido de red, intrusión de hackers yautorización ilegal. La característica de apertura de IoT hace que se enfrente amuchos problemas de autenticación de identidad[12].

Para que la visión del Internet de las cosas trabaje correctamente el para-digma de la computación deberá ir más allá de los enfoques tradicionales de lacomputación móvil ya que para que la tecnología desaparezca de la concienciadel usuario el IoT requiere de tres factores primordiales los cuales son deseablesse cumplan en su mayoría. Una comprensión compartida de la situación de losusuarios y sus dispositivos. Arquitecturas de software y redes de comunicaciónpenetrantes, con lo cual se permita no solo transmitir la información habitualsino además incluir información contextual donde sea necesario esto con el finde proporcionar mejores servicios. La existencia de herramientas analíticas con

24

1.4 Pregunta de Investigación

el fin de conseguir un comportamiento autónomo e inteligente de la red, como delos servicios proporcionados [4].

Aunado a esto existe la necesidad de emplear algún tipo de arquitectura ydefinir un conjunto de protocolos y formatos de intercambio esto con e fin deconseguir o atender los puntos mencionados anteriormente. En la actualidadexisten un conjunto de arquitecturas que permiten el desarrollo de Tecnologíasde última generación, algunas arquitecturas son empleadas de manera particularpara sistemas específicos[3].

También existe la posibilidad de utilizar arquitectura de forma híbrida parapotencializar los mejores aspectos de cada una. Pero esto trae consigo la proble-mática de estandarizar dichas estructuras para garantizar la intercomunicacióny el acoplamiento entre ellas.

En la última década los avances de las Tecnologías de Información y Comu-nicación (TIC’s) han permitido la optimización de servicios que son empleados encampos como la industria, la educación, la medicina, protección ambiental, etc.Tal es el caso de que en años recientes se ha optado por hacer uso de las TIC’spara automatizar el uso de expedientes clínicos y con ello reducir el tiempo deespera para la atención de los pacientes y mejorar el control de la informacióningresada al expediente, por lo cual es necesario emplear una arquitectura quepermita la integración y optimización de diversos servicios médicos para que pue-den ser utilizados por los derechohabientes, pacientes, médicos, investigadores,administrativos, directivos, etc. que forman parte del sector salud [7].

Todo esto proporcionará la oportunidad de brindar solución al caso de estudioque es la implantación de la arquitectura dentro de un sistema de Expedienteclínico electrónico.

1.4. Pregunta de Investigación

Las preguntas de Investigación que se pretenden resolver con la realizacióndel Trabajo de tesis propuesto son las mencionadas a continuación.

¿Es factible integrar varias arquitecturas en un esquema de acoplamientopara su utilización conjunta?

¿Cómo se podría diseñar una arquitectura que permita la correcta interac-ción de los componentes dentro de un sistema inmerso en el Internet de lasCosas?

¿Cuáles son los elementos mínimos necesarios que deba contener la arqui-tectura? ¿La arquitectura Propuesta podrá ser implementada dentro de unsistema de unificación de servicios entre ellos el Historial Clínico?

25


1.5. Objetivos

Los objetivos que persigue la investigación son mencionados a continuación.

1.5.1. Objetivo general

Proponer una Arquitectura de servicios Móviles, diseñada para trabajar en unEntorno de IoT.

1.5.2. Objetivos especificos

Determinar cuales son las características deseables que debe contener unaarquitectura modular orientada a servicios inmersa en un entorno de Inter-net de las cosas.

Proponer una Arquitectura de Servicios Híbrida que atienda las caracterís-ticas anteriormente mencionadas.

Validar con un caso de estudio o prueba el Desarrollo e implantación de laArquitectura en un servicio de salud.

1.6. Justificación

Como se pudo observar dentro de la definición de la problemática con la lle-gada del Internet de las cosas así como el crecimiento acelerado dentro del áreade los sistemas es necesario tomar cartas en el asunto ya que es debido a la li-mitación en el acoplamiento y la estandarización de las estructuras integrantesde una arquitectura que surge la necesidad de proponer Arquitecturas híbridasque permitan la integración de medios estándar de comunicación (Servicios ),aco-plamiento de diversos Módulos (Funcionalidades) que cubran diversos niveles deacceso dependiendo de la especificación técnica del componente. Por otro lado ca-be destacar como se pudo observar dentro de los antecedentes han existido grancantidad de propuestas de expedientes clínicos electrónicos en el mundo peroninguno de los desarrollados hasta el momento se adapta o bien a las necesida-des que marca el sector salud dentro de la Norma Oficial Mexicana o bien no sehan preocupado por integrar a sus soluciones la información que pudiera ser ge-neradas por componentes diferentes al ser humano es decir dentro de un sistemainmerso en el Internet de las Cosas, dichos componentes pueden ser dispositivoselectrónicos como lo son Tag NFC, dispositivos móviles redes de sensores, entreotros que pudieran generar información valiosa para el caso de estudio.

26

1.7 Viabilidad

1.7. Viabilidad

A partir de lo investigado hasta el momento se ha encontrado que es posiblehacer el uso de Arquitecturas Híbridas que permitan explotar las potencialidadesque cada una ofrece así como solventar de cierta forma sus áreas de oportunidad.

Por otro lado existen gran cantidad de investigaciones, artículos, congresos ypublicaciones de las cuales poder apoyarse para poder proponer una propuestade arquitectura que permita satisfacer los objetivos anteriormente propuestos.Aunado a esto, dado el tiempo disponible para llevar a cabo la presente investi-gación se considera necesaria hacer una correcta delimitación del trabajo en elaspecto de que se va a abarcar del expediente clínico electrónico (caso práctico)ya que si bien existen gran cantidad de ejemplos de implementación ninguna deestas ha logrado cubrir por completo lo establecido por la Norma Oficial Mexicana, por lo cual se considera prudente el hacer un análisis mas detallado de dichasituación para determinar que módulo o módulos sean los más adecuados paraimplementar esto con el objetivo de probar correctamente el funcionamiento de laarquitectura propuesta. Por otro lado se considera que a partir de lo investigadono se pretenderá cubrir la totalidad de capas que conforman el modelo de Internetde las cosas sino por cuestiones de tiempo y con el objetivo de dejar en un nivelmas genérico la propuesta de arquitectura se tomarán las capas superiores delmodelo, las cuales no implican el desarrollo de nuevo hardware, sino más bientrabajar sobre las capas lógicas del sistema lo cuál a largo plazo permitiría unenfoque genérico de la arquitectura, ya que no dependerá del dispositivo sino desu forma de intercomunicarse con el sistema y otros dispositivos conectados a laarquitectura.

27


28

II

Marco teórico

Marco TeóricoCapítulo 2: Marco Teórico

2.1. Sistemas comerciales de salud en la actualidad

A continuación se nombrarán algunos casos de implementaciones de expe-dientes clínicos electrónicos, que servirán como un ejemplo y sentará un prece-dente para la realización del caso de estudio a realizar para comprobar la presentetesis.

2.1.1. Tap2Tag

En la actualidad, dichos sistemas se encuentran de manera comercial, loscuales se presentan en una variedad de formas, como lo son llaveros,pulseras o tarjetas. En el Reino Unido, actualmente se comercializa un

sistema llamado tap2tag, en donde a través de un dispositivo NFC se puede acce-der a la información médica del paciente siempre y cuando se tenga un dispositivoconectado a la nube [13].

2.1.2. Alerta Médica

Comercialmente también existen sistemas que utilizan códigos QR comomedio de comunicación, de modo que el doctor o el personal de emergen-cias pueden acceder a la información. Cabe destacar que en este tipo de

dispositivos el paciente es el responsable de actualizar su información personal,lo que limita el rol de los doctores dentro del sistema. Dentro de los sistemas co-merciales existen dos variantes, existen los dispositivos en donde la informaciónse encuentra almacenada en la nube, de modo que para acceder es necesariouna conexión a internet. Ejemplo de ello es el sistema de Alerta-Medica, en dondese ofrece una serie de artículos en donde se puede llevar el código QR, el cualcontiene acceso a su página, con el que el personal médico puede acceder a susdatos[14].

2.1.3. InfoVital

Por otro lado, existen los dispositivos en donde la información se encuentraimpresa en el código QR, como lo es InfoVital. Cuentan con la ventaja deque no es necesario contar con una conexión a internet para la visuali-

zación de la información. Sin embargo, solamente se puede ingresar una vez lainformación, lo que los ubican solo como sistemas de registro de información yno como un expediente[15].

31

Capítulo 2. Marco Teórico

2.1.4. PDC

Es un servicio que integra una pulsera RFID como identificador para lospaciente y un lector RFID de HP(“Hewlett-Packard RFID PDA”), además seintegra con un expediente clínico electrónico; con el objetivo de agilizar los

protocolos quirúrgicos. Permite registrar la llegada de un paciente, hora precisa enla que los anestésicos le fueron suministrados, en que le hizo efecto la anestesia,verificación de la orden de anestesia, comienzo y fin de la cirugía, medicacionesdel paciente y finalmente su alta. En pocas palabras su uso se limita al plan decirugías en un hospital. Esta solución está disponible para Taiwan [16]

2.2. Marcos Normativos

En la presente sección nombraremos diferentes normas con respecto a Siste-mas informáticos de Salud que hay que tomar en cuenta para la realización delcaso de estudio.

2.2.1. Norma Oficial Mexicana NOM-004-SSA3-2012, Del expe-

diente clínico

Se define al expediente clínico como: “El conjunto único de información ydatos personales de un paciente, que se integra dentro de todo tipo de es-tablecimiento para la atención médica, ya sea público, social o privado, el

cual, consta de documentos escritos, gráficos, imagenológicos, electrónicos, mag-néticos, electromagnéticos, ópticos, magneto-ópticos y de cualquier otra índole,en los cuales, el personal de salud deberá hacer los registros, anotaciones, ensu caso, constancias y certificaciones correspondientes a su intervención en laatención médica del paciente, con apego a las disposiciones jurídicas aplicables”[17].

Además, en esta norma se definen los elementos integradores de un expedienteclínico para su utilización en los Estados Unidos mexicanos.

2.2.2. ISO/TS 18308:2004 Requerimientos para la Informática

de la Salud

Hasta recientemente, no existía una definición formal para un ExpedienteClínico Electrónico. La primer publicación técnica fue la “ISO/TS 18308:2004 Health Informatics Requirements for an Electronic Health Record

Architecture”, la cual contiene siete definiciones diferentes tomadas de EstadosUnidos, Australia, Europa y Canadá.

32

2.2 Marcos Normativos

Estas definiciones tienen más similitudes que diferencias, pero reflejan dife-rentes significados entre organizaciones y países[18].

Estas incluyen:

Electronic Medical Record

Electronic Patient Record

Computerized Patient Record

Electronic Health Care Record

Visual HER

Personal Health Record

Digital Medical Record

2.2.3. Manual del Expediente Clínico Electrónico de la Secre-

taría de Salud

En este se define al expediente clínico electrónico como “una fuente deinformación que amplía el dictamen médico de un experto, conformándosepor una descripción de la propedéutica médica aunado a documentos,

imágenes, procedimientos, pruebas diversas, análisis e información de estudiospracticados al paciente.” Además, se ofrece una clasificación de los expedienteselectrónicos, la cual es la siguiente:

Expediente clínico electrónico (EMR). Expediente que relaciona la informa-ción de salud de una persona y que puede ser creado, compartido, gestio-nado y consultado por profesionales de la salud autorizados dentro de unaorganización de salud.

Expediente electrónico de salud (EHR). Registro total de información elec-trónica relacionada con la salud de un individuo, donde se almacena infor-mación por parte de más de una organización o proveedores de servicios desalud.

Expediente electrónico del paciente (PHR). Expediente de una persona quecumple los estándares de interoperabilidad nacionales y que puede ser crea-do y conformado por múltiples fuentes de información. Es compartido, ges-tionado y controlado por la persona.

33


Sistema de Información Hospitalaria (HIS). Sistema integral de informacióndiseñado para administrar los aspectos financieros, clínicos y operativos deuna organización de salud. Puede incluir o estar conectado con un Expe-diente Clínico Electrónico.

Sistema de Información Hospitalaria (HIS). Sistema integral de informacióndiseñado para administrar los aspectos financieros, clínicos y operativos de unaorganización de salud. Puede incluir o estar conectado con un Expediente ClínicoElectrónico[7] .

2.2.4. Ley federal de protección de datos personales en pose-

ción de los particulares

A partir del día 5 de julio de 2010 surgió una ley de datos personalescon el objetivo de proteger la información de particulares, sobre todo conrespecto a informacín sensible. Se entenderá por información sensible:

Aquellos datos personales que afecten a la esfera más íntima de su titular, o cuyautilización indebida pueda dar origen a discriminación o conlleve un riesgo gravepara éste. En particular, se consideran sensibles aquellos que puedan revelar as-pectos como origen racial o étnico, estado de salud presente y futura, informacióngenética, creencias religiosas, filosóficas y morales, afiliación sindical, opinionespolíticas, preferencia sexual. Se requiere que para el tratamiento de datos per-sonales deberá estar sujeto al consentimiento del titular de dicha información.Tratándose de datos personales sensibles, el responsable deberá obtener el con-sentimiento expreso y por escrito del titular para su tratamiento, a través de sufirma autógrafa, firma electrónica, o cualquier mecanismo de autenticación queal efecto se establezca. No podrán crearse bases de datos que contengan datospersonales sensibles, sin que se justifique la creación de las mismas para fina-lidades legítimas, concretas y acordes con las actividades o fines explícitos quepersigue el sujeto regulado. Aunado a esto existen situaciones en las cuales noserá necesario el consentimiento para el tratamiento de la información las cualesse mencionan a continuación[19] .

Que los datos figuren en fuentes de acceso público

Que los datos personales se sometan a un procedimiento previo de disocia-ción

Sean indispensables para la atención médica, la prevención, diagnósticoprestación de asistencia sanitaria, tratamientos médicos o la gestión de ser-vicios sanitarios, mientras el titular no esté en condiciones de otorgar elconsentimiento, en los términos que establece la Ley General de Salud y

34

2.3 Marco Conceptual

demás disposiciones jurídicas aplicables y que dicho tratamiento de datosse realice por una persona sujeta al secreto profesional u obligación equiva-lente.

El responsable tendrá la obligación de informar a los titulares de los datos,la información que se recaba de ellos y con qué fines, a través del aviso deprivacidad

2.3. Marco Conceptual

2.3.1. Cómputo en la nube

El modelo en la nube se compone de cinco características esenciales: au-toservicio a pedido, amplio acceso a la red, agrupación de recursos, elas-ticidad rápida y servicio medido. Consiste en tres modelos de servicio y

cuatro modelos de implementación que están definidos y acordados en el NIST[20].

2.3.1.1. Características esenciales

Autoservicio a pedido: garantiza que el consumidor pueda proporcionar demanera unilateral las capacidades informáticas, como el tiempo del servidory el almacenamiento en red de forma automática, sin necesidad de interac-ción humana con cada proveedor de servicios.

Amplio acceso a la red: Da acceso a las capacidades disponibles a través dela red a través de mecanismos estándar.

Recopilación de recursos: agrupa recursos informáticos para atender a múl-tiples consumidores. Diferentes recursos físicos y virtuales dinámicamen-te asignados y reasignados de acuerdo a la demanda del consumidor. Losejemplos de recursos incluyen almacenamiento, procesamiento, memoria yancho de banda de red.

Elasticidad rápida: se usa para proporcionar y liberar capacidades o recur-sos elásticamente. Para el consumidor, las capacidades disponibles para elaprovisionamiento a menudo parecen ser ilimitadas y pueden asignarse encualquier cantidad y en cualquier momento.

Servicio medido: control del sistema en la nube y optimización del uso derecursos mediante el aprovechamiento de una capacidad de medición enalgún nivel de abstracción adecuado para el tipo de servicio (por ejemplo,

35


almacenamiento, procesamiento, ancho de banda y cuentas de usuario ac-tivas). Para ambos, el proveedor y el consumidor del servicio utilizado, el usode los recursos puede ser monitoreado, controlado e informado, y tambiénproporcionar transparencia.

2.3.1.2. Ventajas de la computación en la nube

Como a los clientes se les cobra por hora de ejecución o gigabyte de almacena-miento, no tienen que preocuparse por el mantenimiento del hardware ni por loscostos de actualización ni por el costo adicional que implican los sistemas físicosinfrautilizados[20].

La escalabilidad fácil debida a la duplicación de instancias o cambiando lacantidad de CPU y memoria disponible en una máquina virtual. Un beneficio esque el entorno de ejecución y los datos se pueden ubicar más cerca de la ubicaciónde mayor demanda.

La mayoría de los proveedores de servicios en la nube tienen varias ubicacio-nes donde alojan datos de clientes. Este enfoque distribuido a los recursos crearedundancia del sistema. Si partes de los recursos caen, tendrá un efecto mínimoen los otros recursos.

2.3.1.3. Modelo de computacion en la nube

En la computación en la nube, todo se proporciona como un servicio (Xaas).Los servicios pueden ser en forma de hardware, software, almacenamiento, pla-taforma, base de datos de infraestructura y muchos más[20].

NIST presentó tres categorías principales de servicios, conocidas como modelode servicio, que se detallan a continuación:

Software como servicio (Saas)

La infraestructura en la nube del proveedor se entrega a múltiples clientes(a pedido) a través del navegador web a través de Internet. El consumidor noadministra ni controla la infraestructura subyacente de la nube, incluidosla red, los servidores, los sistemas operativos, el almacenamiento o inclusolas capacidades de aplicaciones individuales, con la posible excepción deconfiguraciones limitadas de configuración de aplicaciones específicas delusuario.

Plataforma como servicio (Pass)

se proporciona una plataforma al cliente para construir (desarrollar, pro-bar, implementar) las aplicaciones. La capacidad provista al consumidor esimplementar en la infraestructura de la nube aplicaciones creadas o ad-quiridas por el consumidor creadas utilizando lenguajes de programación,

36


bibliotecas, servicios y herramientas compatibles con el proveedor. El con-sumidor no administra ni controla la infraestructura subyacente de la nube,incluida la red, los servidores, los sistemas operativos o el almacenamiento,pero tiene control sobre las aplicaciones implementadas.

.Infraestructura como servicio (Iaas)

Ofrece a los usuarios acceso elástico a demanda a los recursos (servidor,almacenamiento, redes) a través de la API del servicio. El consumidor noadministra ni controla la infraestructura subyacente de la nube, pero tienecontrol sobre los sistemas operativos, el almacenamiento y las aplicacionesdesplegadas, y posiblemente el control limitado de los componentes de redseleccionados, como los firewalls host. Los proveedores de servicios de nubesuelen facturar el servicio Iaas en función del uso, el costo refleja la cantidadde recursos asignados y consumidos. Amazon EC2 es un buen ejemplo deIaas.

2.3.1.4. Modelo de implementación

NIST ha dado cuatro modelos de implementación que deciden los criterios delusuario significa bajo qué modelo puede acceder a los servicios.

Nube pública: la infraestructura de la nube se proporciona al público, esuna infraestructura de mega escala. Nube pública gestionada por terceros

Nube privada: también se conoce como nube interna. La infraestructura enla nube es provista por una sola organización que tiene control total sobrelas aplicaciones que se ejecutan en la infraestructura para un uso específico.

Nube híbrida: es la composición de dos o más infraestructuras de nubedistintas. Permite, una organización puede ejecutar alguna aplicación en lainfraestructura interna y otra puede ejecutarse en la nube pública.

Nube comunitaria: la infraestructura en la nube es provista por una comu-nidad específica. Múltiples organizaciones crean infraestructura en la nubey la comparten. También comparten políticas, requisitos y valores. La in-fraestructura en la nube está alojada por un proveedor externo o puede serhospedada por una de las organizaciones dentro de la comunidad.

2.3.2. Arquitectura

Estructura que define que componentes debe poseer un sistema así comolas relaciones entre cada uno de ellos El diseño de una arquitectura desoftware representa una de las decisiones mas criticas para el correcto

37


funcionamiento de un sistema ya que esta arquitectura definirá muchas de lascaracterísticas que podrá alcanzar un sistema[3]

2.3.2.1. Arquitectura orientada a Servicios

El cómputo Orientado a Servicios, es el paradigma de la computación queutiliza servicios como como elementos fundamentales para el desarrollo de so-luciones, un servicio será descrito como un elemento computacional agnóstico ala plataforma que soporta una veloz y de bajo costo, que componen aplicacionesdistribuidas. Los servicios realizan funciones, que pueden ser desde simples so-licitudes hasta complicados procesos empresariales. Los servicios permiten a lasorganizaciones exponer sus competencias básicas de forma programática a travésde Internet (o intranet) utilizando lenguajes y protocolos estándares (basados enXML, JSON o algún otro formato de intercambio), e implementarse a través deuna interfaz auto descriptiva basada en estándares abiertos [21]. En la época decliente-servidor, tendíamos a centrarnos en la creación de aplicaciones en capasmediante el uso de tecnologías específicas en cada nivel. El término aplicaciónmonolítica ha surgido de estos enfoques. Las interfaces tendían a estar entre losniveles y normalmente utilizaban un diseño más estrechamente acoplado entrelos componentes de cada nivel. Los desarrolladores diseñaban y generaban clasescompiladas en bibliotecas y las vinculaban entre sí en algunos archivos ejecuta-bles y DLL. Dicho enfoque de diseño monolítico tiene varias ventajas. A menudoes más fácil de diseñar y las llamadas entre los componentes son más rápidas, yaque generalmente se realizan a través de comunicación entre procesos (IPC). Ade-más, todo el mundo prueba un único producto, lo que tiende a ser más eficienteen la relación entre personas y recursos. La desventaja es que se produce unacoplamiento estrecho entre las capas en niveles y no se pueden escalar los com-ponentes individuales. Si necesita realizar actualizaciones o correcciones, tendráque esperar hasta que otros usuarios finalicen sus pruebas, lo que dificulta laagilidad [22].

2.3.2.2. Micro servicios

Los micro servicios son una arquitectura y un enfoque sobre la escritura desoftware en el que las aplicaciones se dividen en componentes más pequeños eindependientes entre sí. A diferencia de un enfoque tradicional y monolítico sobrelas aplicaciones, en el que todo se crea en una única pieza, los micro serviciosestán separados y funcionan conjuntamente para llevar a cabo las mismas ta-reas. Cada uno de estos componentes, o procesos, son los micro servicios. Esteenfoque sobre el desarrollo de software valora la granularidad por ser liviana y lacapacidad de compartir un proceso similar en varias aplicaciones [23]. Los mi-

38


cro servicios solucionan estas desventajas y se adaptan mejor a los anterioresrequisitos empresariales, pero también tienen ventajas y desventajas. Las ven-tajas de los micro servicios son que cada uno suele encapsular funcionalidadesempresariales más simples, las cuales se pueden escalar o reducir verticalmente,probar, implementar y administrar de forma independiente. Una ventaja impor-tante del enfoque de micro servicios es que los equipos están más condicionadospor los escenarios empresariales que por la tecnología, que es lo que fomenta elenfoque con niveles. En la práctica, los equipos más pequeños desarrollan unmicro servicio en función de un escenario del cliente y usan las tecnologías queprefieren. Es decir, no es necesario que la organización normalice su tecnologíapara mantener aplicaciones de micro servicio. Los equipos individuales con ser-vicios propios pueden hacer lo más lógico en función de sus conocimientos o delo que sea más adecuado para resolver el problema. En la práctica, es preferibletener un conjunto de tecnologías recomendadas, como un almacén NoSQL o unmarco de aplicaciones web concretos [24]. Los estándares hacen que el enfoquede microservicios funcione al establecer un acuerdo sobre cómo llevar a cabo lacomunicación y tolerar únicamente lo que se necesita de un servicio, en lugarde usar contratos rígidos. Es importante definir estos contratos por adelanta-do en el diseño, ya que los servicios se actualizan de forma independiente entresí. Otra descripción acuñada para el diseño con el enfoque de microservicios es.arquitectura orientada a servicios (SOA) específica"[24].

2.3.2.3. Arquitectura PipeLine

Una tubería (pipeline) conecta componentes (filtros) por medio de conectores(pipes), de modo que los datos se procesan y ejecutan a manera de flujo. Losdatos se transportan a través de las tuberías entre los filtros, transformandogradualmente las entradas en salidas [22].

2.3.2.4. Arquitectura Peer to Peer (Entre Pares)

Podemos considerar un sistema P2P como una arquitectura de varias capas,a saber [22]:

El nivel de red, representa el nivel más bajo de la arquitectura, ofreciendolas capacidades básicas de comunicación entre ordenadores, bien a travésde redes IP o mediante redes Ad- Hoc.

El nivel de administración de la capa P2P, encargado de enrutar mensajesy de realizar tareas de mantenimiento del overlay.

El nivel de características, que da soporte a funcionalidades de la red comola seguridad, la resistencia a fallos o la administración de recursos.

39


El nivel de servicios, que es el encargado de proporcionar funcionalidades alnivel de aplicación.

2.3.2.5. Arquitectura Orientada a Eventos

Las características que definen a una arquitectura orientada a eventos semencionan a continuación [23]:

Comunicaciones de difusión. Los sistemas participantes difunden eventos acualquier grupo. Más de una parte puede escuchar el evento y procesarlo.

Oportunidad. Los sistemas publican eventos a medida que ocurren en lugarde almacenarlos localmente y esperan el ciclo de procesamiento, tal comoun Ciclo discontinuo.

Eventos de grano fino. Las aplicaciones tienden a publicar eventos indivi-duales en lugar de un solo agregado.

Ontología. El sistema global define una nomenclatura para clasificar even-tos, típicamente en alguna forma de jerarquía. Los sistemas receptores amenudo pueden expresar interés en eventos o categorías de eventos.

Procesamiento de Eventos Complejos: El sistema entiende y monitorea lasrelaciones entre eventos, por ejemplo agregación de eventos (un patrón deeventos implica un nivel más alto) o causalidad (un evento es causado porotro)

2.3.2.6. Arquitectura de Tres Niveles

También conocido como Three Tier, o enfoque de tres esquemas. El propósitode la arquitectura de los tres esquemas es que:

Todos los usuarios deben poder acceder a los mismos datos

Una vista de usuarios debe ser inmune a los cambios realizados en otrasvistas

Los usuarios no deben conocer los detalles físicos del almacenamiento de labase de datos

DBA debe ser capaz de cambiar las estructuras de almacenamiento de labase de datos sin afectar la vista de los usuarios

La estructura interna de la base de datos no debería verse afectada porcambios [23].

40


2.3.3. Internet de las cosas

El término Internet de las Cosas fue acuñado por primera vez por KevinAshton en 1999 en el contexto de la gestión de la cadena de suministro[4]. Sin embargo, en la última década, la definición ha sido más inclusi-

va que abarca una amplia gama de aplicaciones como la atención de la salud,servicios públicos, transporte, etc [5]. Aunque la definición de Çosas"ha cambia-do a medida que la tecnología evolucionó, el objetivo principal de hacer que unacomputadora perciba la información sin la ayuda de la intervención humana si-gue siendo la misma. Una evolución radical de la Internet actual en una Red deobjetos interconectados que no sólo recolecta información desde el entorno (de-tección) e interactúa con el mundo físico (actuación / mando / control), sino quetambién utiliza los estándares existentes de Internet para proporcionar serviciosde transferencia de información , Análisis, aplicaciones y comunicaciones. Impul-sado por la prevalencia de dispositivos habilitados por la tecnología inalámbricaabierta, como Bluetooth, RFID, Wi-Fi y servicios de datos telefónicos, así como losnodos de sensores y actuadores integrados, IoT ha salido de su infancia y está enla Transformar la actual Internet estática en una Internet del Futuro totalmenteintegrada [6].

La forma de abordar el termino Internet de las cosas puede ser abordado endos diferentes puntos de vista el centrado al Internet y el centrado en la Cosa.La arquitectura centrada en internet propone que los servicios en internet son elelemento principal y se ve apoyada o enriquecida gracias a las “cosas”

En la arquitectura orientas al objeto o “cosa” entiende a estos objetos comoelementos inteligentes que toman el control del escenario [1] En el presente tra-bajo tomaremos una perspectiva orientada a internet pero sin perder de vista laimportancia también del objeto ya que con el fin de aprovechar por completo elcómputo en la nube nos permitirá una mejor detección de objetos, además quenos permitiría una mejor viabilidad puesto que esta forma de perspectiva permiteal investigador una mayor flexibilidad a la hora de proponer una solución.

IoT se puede ver desde tres perspectivas.

Orientado a Internet

Orientado a las cosas

Orientado semántico

Se definió como "La red mundial de objetos interconectados a los que se pue-de acceder de forma exclusiva en función de los protocolos de comunicaciónestándar"[10]. La arquitectura en este contexto se define como una estructurapara la especificación de los componentes físicos de una red y su organización

41


y configuración funcional, sus principios y procedimientos operativos, así comolos formatos de datos utilizados en su funcionamiento. Capa de percepción: lacapa de percepción es similar a la capa física en dispositivos de interconexiónde sistemas abiertos y elementos ambientales. En general, esta capa hace fren-te a la gestión global del dispositivo, como la identificación y la recopilación deinformación específica por cada tipo de dispositivo sensor [10]. Capa de red: lacapa de red desempeña un papel importante al transferir y mantener de formasegura la información confidencial confidencial desde los dispositivos sensoresal sistema central de procesamiento de información a través de 3G, 4G, UMTS,Wi-Fi, WiMAX, RFID, infrarrojos, satélite [9]. Capa de Middleware: los dispositi-vos en el sistema de IoT pueden generar diversos tipos de servicios cuando estánconectados y se comunican con otros. La capa de middleware tiene dos funcionesesenciales, es decir, la administración del servicio y almacena la información dela capa inferior en la base de datos. Además, esta capa tiene la capacidad de recu-perar, procesar, calcular información y luego decidir automáticamente en funciónde los resultados computacionales.

Capa de aplicación: la capa de aplicación es responsable de la administraciónde aplicaciones inclusivas basadas en la información procesada en la capa deMiddleware[10]. Business Layer: las funciones de esta capa cubren la totalidadde las aplicaciones de IoT y la gestión de servicios. Puede crear gráficos prácticos,modelos comerciales, diagramas de flujo, informes ejecutivos, etc. en función dela cantidad de datos precisos recibidos de la capa inferior y del proceso de análisisde datos efectivo[10].

2.3.3.1. Modelo del Internet de Las Cosas

En el foro Mundial de referencia del modelo de internet of things se establecioun modelo basado en siete niveles los cuales son los siguientes [25]:

I. Dispositivos Físicos y Controladores.-Nivel basado en los objetos del IoT.II. Conectividad.- Nivel basado en los dispositivos de comunicación y unidades

de procesamiento.III. Computo Barrera.- Es el nivel donde se hace el análisis de los elementos

de información y se hace la transformación de la información para garantizar lacomunicación, es la frontera entre la parte lógica y física del sistema.

IV. Acumulación de la Información.- Es el nivel donde se hace el almacena-miento de la información generada.

V. Abstracción de información.- Es la capa capa donde se accede y se agreganueva información por parte de las aplicaciones de capas superiores.

VI. Aplicación.- Es la capa donde se generan los reportes, Control, y Análisisde la información recabada.

42


VI. Colaboración y Procesos.- Es la capa que envuelve tanto a las personas,procesos de negocio y Dispositivos para proporcionar diferentes servicios.

La integración de los conceptos de redes sociales en IoT ha llevado al concep-to Social IoT (SIoT) que permite que las personas y los dispositivos conectadosinteractúen, facilitando el intercambio de información. Sin embargo, interopera-bilidad. los problemas de seguridad y privacidad son un gran desafío para IoT,pero también son factores habilitantes para crear un .ecosistema confiable y in-teroperable". De hecho, al no resolver estos problemas, el paradigma SIoT noalcanzará la popularidad suficiente y se perderá todo su potencial. El problemade seguridad se enfatiza por la falta de estándares diseñados específicamente paradispositivos con recursos limitados y tecnologías heterogéneas. Además, estos dis-positivos, debido a muchas vulnerabilidades, representan un "terreno fértil"paralas amenazas cibernéticas existentes. De hecho, a fines de 2016, hubo ataquesDDoS (Distributed Denial-of-Service) al proveedor de DNS Dyn (que admite lasprincipales plataformas y servicios de Internet, como PayPal, Twitter, VISA, etc.)a través de una botnet que consiste en una gran cantidad de dispositivos de IoTvulnerables [25].

A continuación se anexa un análisis de los diferentes problemas y solucionespropuestas en redes inalámbricas [26].

Cuadro 2.1: Análisis de Problemas y Soluciones en Redes Inalámbricas.

Protocolos Problemas SolucionesTipo de

Solución

IEEE802.15.4

Ataque deTráfico de

DatosAES CCM Estándar

BLE


DatosAES CCM Estándar


Datos

SoluciónBlack Network

Nuevo

Wi-FiAtaque deTráfico de

Datos

WEP, WPA,WPA2

Estándar

LTEAtaque deTráfico de

DatosEEA y EIA Estándar

43


IPv4/IPv6


DatosIPsec Estándar

Amenazasde NDP

SEND en IPv6 Estándar

6LoWPANAtaque deTráfico de

Datos

IPsecCompreso

Nuevo

DTLSCompreso

Nuevo

802.15.4Característicasde Seguridad

Estándar

RPL

Ataques deEnrutamiento

y DOSSVELTE IDS Nuevo


DatosAES/CCM Estándar

MQTT


DatosTLS PSK Estándar


Datos, manejode llaves

escalables,TLS pesados

MQT SegurosABE

Nuevo

Privacidad porfalta de control

del usuarioSecKit Nuevo

CoAP


Datos

DTLS, PSK,RPK


Datos, DTLSde alto

Handshake

Lithe Nuevo

44


2.3.4. Redes de Cómputo

Una red de computadoras (también llamada red de ordenadores o red infor-mática) es un conjunto equipos (computadoras y dispositivos), conectadospor medio de cables, señales, ondas o cualquier otro método de transpor-

te de datos, para compartir información (archivos), recursos (discos, impresoras,programas, etc.) y servicios (acceso a una base de datos, internet, correo electró-nico, chat, juegos, etc.). A cada una de las computadoras conectadas a la red e ledenomina un nodo [27]

2.3.4.1. Redes de Sensores

Una red de sensores inalámbricos (WSN) es una red inalámbrica que consisteen dispositivos distribuidos espaciados autónomos utilizando sensores para mo-nitorear condiciones físicas o ambientales. Un sistema WSN incorpora un gatewayque provee conectividad inalámbrica de regreso al mundo de cables y nodos dis-tribuidos (vea Figura 1). El protocolo inalámbrico que seleccione depende en losrequerimientos de la aplicación. Algunos de los estándares disponibles incluyenradios de 2.4 GHz basados en los estándares IEEE 802.15.4 o IEEE 802.11 (Wi-Fi)o radios propietarios, los cuales son regularmente de 900 Mhz [28].

2.3.5. Protocolos de Comunicación

El modelo OSI así como cualquier otro modelo de comunicación solo pro-veen un marco conceptual para la comunicación entre dispositivos, peroel modelo por sí mismo no define ni provee métodos específicos de co-

municación, actualmente la comunicación esta definida por varios protocolos decomunicación, un protocolo se puede definir como el establecimiento formal delas reglas, convenciones y estructura de datos que norma como las computado-ras y otros dispositivos intercambian información a través de una red, en otraspalabras un protocolo es un estándar de procedimientos y formato que dos o masdispositivos de comunicación de datos deben comprender, aceptar y usar paraser capaces de comunicarse entre ellos [28].

2.3.5.1. Protocolo IEEE 802.4.15

IEEE Std 802.15.4-2003 definió el protocolo y la interconexión compatiblepara dispositivos de comunicación de datos que utilizan transmisiones de ra-diofrecuencia (RF) de corto alcance de baja velocidad de datos, baja potencia ybaja complejidad en una red de área personal inalámbrica (WPAN) . Esta revisiónamplía la aplicabilidad del mercado de IEEE Std 802.15.4, elimina las ambigüe-dades en el estándar y mejora las implementaciones de IEEE Std 802.15.4-2003

45


IEEE 802.15.4 fue diseñado para operar en bandas de radiofrecuencia sin licencia(Aunque normalmente se siguen aplicando normas sobre la envoltura de la sali-da RF y posiblemente el ciclo de trabajo de un dispositivo que funcione en estasbandas). El RF sin licencia, las bandas no son las mismas en todos los territoriosdel mundo, pero IEEE 802.15.4 emplea tres posibles bandas, al menos una delas cuales debería estar disponible en un territorio determinado. El tres Bandasse centran en las siguientes frecuencias: 868, 915 y 2400 MHz. Las bandas de868 MHz y 915 MHz están disponibles con diferentes esquemas de modulación:BPSK, O-QPSK y ASK (el esquema estándar es BPSK). Estos sistemas dan lugara diferentes tasas de datos [29].

2.3.5.2. ZigBee

ZigBee es un estándar de comunicaciones inalámbricas diseñado por la ZigBeeAlliance. Es un conjunto estandarizado de soluciones que pueden ser implemen-tadas por cualquier fabricante. ZigBee está basado en el estándar IEEE 802.15.4de redes inalámbricas de área personal (wireless personal área Newark, WPAN) ytiene como objetivo las aplicaciones que requieren comunicaciones seguras conbaja tasa de envío de datos y maximización de la vida útil de sus baterías[30].

El protocolo ZigBee define tres tipos de nodos: Coordinadores, Enrutadores yDispositivo final, con un requisito de un Coordinador por red. Aunque todos losnodos pueden enviar y recibir datos, existen diferencias en las funciones especí-ficas que desempeñan cada uno de los diferentes tipos.

Los nodos coordinadores son los más capaces de los tres tipos de nodos, existeun coordinador por red y establece el origen de la red es capaz de almacenar y /manejar la información de la red, incluida[31].

2.3.5.3. Digi Mesh

Digi Mesh es un protocolo que solo emplea un tipo de nodo, lo cual genera unared homogénea, esto significa que todos los nodos pueden enrutar información yson e intercambiables ya que no cuentan con una relación a sus nodos raíz [24] .DigiMesh es una topología de redes propietaria para su uso en soluciones inalám-bricas de conectividad de punto final. Es compatible con las funciones avanzadasde red, incluyendo routers para dormir y redes de malla densa. DigiMesh admitemúltiples topologías de red como punto a punto, punto a multipunto y redes demalla. Con soporte para enrutadores para dormir, DigiMesh es ideal para aplica-ciones sensibles a la energía que dependen de baterías o tecnología de recolecciónde energía.

DigiMesh contiene las siguientes características: Auto-sanación: Cualquier no-do puede entrar o salir de la red en cualquier momento sin que la red en su

46


conjunto falle. Arquitectura peer-to-peer: No se necesita jerarquía ni relacionespadre-h�o.

Fácil de usar: La red de malla se simplifica porque no requiere jerarquía ni re-laciones padre-h�o. Silencio: La sobrecarga de enrutamiento se reduce medianteel uso de un protocolo reactivo similar al enrutamiento Ad-hoc de vector de dis-tancia a pedido (AODV). Descubrimiento de ruta: Las rutas se descubren y creansólo cuando es necesario, eliminando la necesidad de mantener un mapa de red.Reconocimientos selectivos: Sólo el nodo de destino responderá a las solicitudesde ruta. Confiable: los agradecimientos confirman la entrega exitosa de los da-tos. Modos de suspensión: admite modos de suspensión de bajo consumo condespertador sincronizado, así como tiempos de sueño y de activación variables[31]. Dado que ZigBee es un estándar abierto, ofrece el potencial de interoperabi-lidad con dispositivos fabricados por diferentes proveedores. Esto proporciona lacapacidad de tener actualizaciones de firmware en el aire. Además, ZigBee ofreceperfiles establecidos para aplicaciones comunes como gestión de energía y contro-les de iluminación. Una buena selección de herramientas de apoyo de diagnóstico,como RF sni�er de paquetes, también está disponible. DigiMesh, como protocolopropietario, permite un control más estricto del espacio de código y, por lo tanto,más espacio para el crecimiento de características. DigiMesh está disponible enplataformas con mayor rango y más opciones de velocidad de datos RF.

La carga útil del marco es generalmente mayor, lo que puede mejorar el ren-dimiento de las aplicaciones que envían bloques de datos más grandes. Además,DigiMesh utiliza un método de direccionamiento simplificado, que mejora la con-figuración de la red y la resolución de problemas [32].

2.3.5.4. Thread

Es un estándar abierto para una comunicación D2D (dispositivo a dispositivo)inalámbrica fiable, rentable y de baja potencia. Está diseñado específicamentepara las aplicaciones de la casa conectada, donde se desea una conexión en redbasada en IP y se puede utilizar una variedad de capas de aplicación en la pila.

Estas son las características generales de la pila de hilos y la red [33]:

Instalación, puesta en marcha y operación sencillas de la red: Los proto-colos simples para formar, unir y mantener las Redes de Hilos permiten alos sistemas autoconfigurarse y corregir los problemas de enrutamiento amedida que ocurren.

Seguro: los dispositivos no se unen a la red de subprocesos a menos queestén autorizados y todas las comunicaciones estén cifradas y seguras.

Redes pequeñas y grandes: las redes domésticas varían de varios disposi-

47


tivos a cientos de dispositivos que se comunican de forma transparente.La capa de red está diseñada para optimizar el funcionamiento de la redbasándose en el uso esperado.

Rango: Los dispositivos típicos junto con redes de malla proporcionan unrango suficiente para cubrir un hogar normal. La tecnología de espectro ex-tendido se utiliza en la capa física para proporcionar una buena inmunidada la interferencia.

No hay un solo punto de falla: la pila está diseñada para proporcionar ope-raciones seguras y confiables incluso con el fallo o pérdida de dispositivosindividuales.

Bajo consumo de energía: Los dispositivos host normalmente pueden fun-cionar durante varios años con pilas tipo AA utilizando ciclos de trabajoadecuados

2.3.6. Middleware

Middleware es software que se sitúa entre un sistema operativo y las apli-caciones que se ejecutan en él. Básicamente, funciona como una capade traducción oculta para permitir la comunicación y la administración

de datos en aplicaciones distribuidas pueden ser denominados como “plumbing”(tuberías), ya que conecta dos aplicaciones para que se puedan pasar fácilmentedatos y bases de datos por una “canalización”. El uso de middleware permite alos usuarios hacer solicitudes como el envío de formularios en un explorador webo permitir que un servidor web devuelva páginas web dinámicas en función delperfil de un usuario [29].

Un Middleware puede ser visto como un conjunto de servicios y funciones re-utilizables, expandibles, que son comúnmente utilizadas por muchas aplicacionespara funcionar bien dentro de un ambiente interconectado [34].

Algunos ejemplos comunes de middleware son el middleware de base de datos,el middleware de servidor de aplicaciones, el middleware orientado a mensajes, elmiddleware web y los monitores de procesamiento de transacciones. Cada progra-ma suele proporcionar servicios de mensajería para que aplicaciones diferentespuedan comunicarse usando marcos de mensajería como el Protocolo simple deacceso a objetos (SOAP), servicios web, transferencia de estado representacio-nal (REST) y notación de objetos JavaScript (JSON). Si bien todo el middlewaredesempeña funciones de comunicación, el tipo que elige una compañía dependedel servicio que se va a usar y del tipo de información que debe comunicarse.Puede tratarse de autenticación de seguridad, administración de transacciones,colas de mensajes, servidores de aplicaciones, servidores web y directorios. El

48


middleware se puede usar también para procesamiento distribuido con accionesque ocurren en tiempo real [34].

2.3.7. OAUTH 2.0

OAuth 2.0 es el protocolo de autorización estándar de la industria. OAuth2.0 reemplaza el trabajo realizado en el protocolo OAuth original creado en2006. OAuth 2.0 se centra en la simplicidad del desarrollador del cliente

al tiempo que proporciona flujos de autorización específicos para aplicacionesweb, aplicaciones de escritorio, teléfonos móviles y dispositivos de sala de estar.Esta especificación se está desarrollando dentro del IETF OAuth WG.

En el modelo tradicional de autenticación cliente-servidor, el cliente solicitaun recurso de acceso restringido (recurso protegido) en el servidor al autenticarsecon el servidor utilizando el propietario del recurso cartas credenciales. Para pro-porcionar acceso a aplicaciones de terceros recursos restringidos, el propietariodel recurso comparte sus credenciales con el tercero. Esto crea varios problemasy limitaciones [35]:

Se requieren aplicaciones de terceros para almacenar el recurso credencialesdel propietario para uso futuro, generalmente una contraseña en Borrartexto.

Se requiere que los servidores admitan la autenticación con contraseña, apesar de las debilidades de seguridad inherentes a las contraseñas.

Las aplicaciones de terceros obtienen un acceso demasiado amplio al re-curso recursos protegidos del propietario, dejando a los propietarios de losrecursos sin ningún capacidad de restringir la duración o el acceso a unsubconjunto limitado de recursos.

Los propietarios de recursos no pueden revocar el acceso a un tercero indi-vidual sin revocar el acceso a todos los terceros, y debe hacerlo cambiandola contraseña del tercero.

49


50

III

Metodología

MetodologíaCapítulo 3: Metodología

3.1. Metodología de Investigación

La metodología de desarrollo explicada a continuación tomará como referen-cia el método científico para la definición de los diferentes pasos a seguirpara conseguir el desarrollo de la presente investigación por otro lado se

aprovechará la presente sección para hacer una pequeña descripción del caso deestudio a implementar. Los pasos a seguir para el desarrollo de esta investigaciónconsiste en los pasos mostrados a continuación.

Figura 3.1: Pasos realizados a lo largo de la Investigación

Una vez analizadas las soluciones actuales y después de revisar y analizar losprotocolos existentes de comunicación de las redes de nodos. Determinar a detallecuales son las características deseables que posean los diferentes módulos de laarquitectura propuesta, definir los elementos necesarios y los procesos necesariosdentro de los diferentes módulos de la arquitectura , para posteriormente imple-mentar dichos módulos, una vez desarrollados dichos módulos por separado, seránecesario la implementación de dichos módulos dentro del caso de estudio el cualse describirá posteriormente dentro del presente documento.

53

Capítulo 3. Metodología

3.2. Características buscadas dentro de la Arquitec-

tura

Necesitamos la interoperabilidad para construir sistemas, crear sistemas desistemas, mantener el consumo de energía, reducir el riesgo y estimular la inno-vación. La interoperabilidad puede incorporarse en varios niveles, al tiempo quese diseña el marco de interoperabilidad / Herramientas / Kit de desarrollo de soft-ware (SDK). A nivel de dispositivo: resúmenes de las características específicas dehardware y software de dispositivos heterogéneos para permitir la interconexión yla interoperabilidad entre sí. En el nivel de protocolo, se permiten variados proto-colos y tecnologías de comunicación que no son modernas, como Ethernet, paraconectarse de forma inalámbrica (por ejemplo, a través de ZigBee, Bluetooth yWifi) con la ayuda de medios de conversión de protocolos. En el nivel de datos,con la ayuda de protocolos flexibles, los datos obtenidos de una multitud de dis-positivos de sensores se traducen usando funciones de procesamiento de datosen formatos que son uniformes [36].

Interfaces hombre-máquina (HMI). Las principales dimensiones de la interope-rabilidad incluyen:

Técnico: se trata de la compatibilidad física y de software de los dispositivos,incluidos los protocolos utilizados para comunicarse entre los dispositivos.

Sintáctico: este es el formato del mensaje a través del cual tiene lugar lacomunicación y es la clave de las comunicaciones. Por ejemplo, usar el XMLo JSON para transmitir información.

Semántica: se refiere a estándares y unidades comunes, por ejemplo, cuan-do se usa la frase sensores, se espera que se comuniquen con los dispo-sitivos que usan las mismas unidades. Un sensor de temperatura podríacomunicarse semánticamente con un dispositivo si tanto el sensor como eldispositivo usan las mismas unidades de temperatura

Organizacional: este es el requisito de las industrias para mantener el mismopatrón de organización para que se puedan administrar múltiples clientes

A continuación mencionaremos los mecanismos adaptados para resolver losproblemas detectados en el Internet de las cosas.

54

3.3 Definición de módulos de la arquitectura

3.3. Definición de módulos de la arquitectura

Los módulos propuestos hasta el momento serán mostrados y explicados demanera general a continuación.

Figura 3.2: Módulos de la arquitectura

La arquitectura propuesta contará por lo menos de 3 aspectos principales loscuales son, el modulo de interconexión el cual será un middleware que permitiráel intercambio de la comunicación entre las diferentes redes de sensores y la ar-quitectura de conexión de servicios. Para conseguir esto es necesario el establecerun formato de trama común el cual sea operable por el middleware de hardwa-re y software para poder conectar con la arquitectura de servicios. Por ultimo laarquitectura de conexión de servicios, será la encargada de consumir y explotarla información generadas por las diferentes redes de sensores así como proveerservicios (funcionalidades) según el perfil del usuario, y sus requerimientos.

55


3.4. Problemáticas encontradas y como resolverlas

Una vez realizada una investigación rigurosa de los problemas a los que sehan enfrentado y publicado en diversos artículos podemos concluir queestos se pueden encasillar en los presentados a continuación.

3.4.1. La falta de recursos

Los recursos son clave para el éxito de un proyecto de IoT. Permiten a losproveedores desviar sus recursos en el diseño y mantenimiento de unaAPI abierta. Estos proveedores de IoT trabajan principalmente en MRI o

sensores. A medida que más y más dispositivos habilitados para la IoT pasana primer plano, sus problemas de interoperabilidad también han cambiado endinámica y funcionamiento [36].

Para mantener las API abiertas, se requieren recursos para probar la API enbusca de mecanismos comunes y también monitorear los dispositivos usando unacapa de monitoreo común. Otra operación intensiva de recursos del sistema IoTes el empuje y la extracción de la información de los dispositivos basados en IoTque utilizan interfaces comunes.

3.4.2. Tecnología propia

Otro problema es que los gigantes del software propietario no querrán lainteroperabilidad de sus dispositivos para que puedan tener la ventajadel mercado sobre los consumidores y por lo tanto no admitirán las API

abiertas de sus productos

3.4.3. Complejidad

Las API son en su mayoría incompatibles entre sí en lo que respecta a losdispositivos de IoT y requerirían una capa de sistema de administraciónde API común, que puede abstraer las complejidades de los dispositivos de

IoT.

56

3.4 Problemáticas encontradas y como resolverlas

3.4.4. Seguridad

La seguridad de cualquier dispositivo basado en IoT se está volviendo cru-cial ya que la privacidad y la protección de los usuarios y las empresasdeben protegerse. Con la creciente conectividad de los dispositivos IoT, la

comunicación segura también se vuelve compleja . Esto gira en torno al accesodado a varios usuarios en diferentes niveles. Esto depende del rol del usuarioademas de un sistema de Permisos granular que nos permita replicat cualquiertipo de rol necesario.

3.4.5. Dispositivos heterogéneos

El otro problema principal en la interoperabilidad de IoT son los disposi-tivos heterogéneos que tienen diferentes representaciones de datos y APIheterogéneas. Por lo cual es necesario el procesamiento de los datos de

los sensores, por ejemplo. Existe una falta de continuidad de datos ya que losdispositivos son incompatibles en la capa de datos. Además, los datos deben serreconocibles, lo que se convierte en un desafío, especialmente cuando se trabajacon datos a gran escala que son redes distribuidas y dispositivos basados en lanube . La interoperabilidad es crucial en la construcción de sistemas y mantieneel costo bajo y reduce el riesgo de construir sistemas fuera de los sistemas.

57


3.5. Especificación de la Arquitectura

Una vez analizada las características deseables para cada uno de estosgrandes grupos descritos anteriormente se puede obtener esta sub espe-cificación.

3.5.1. Middleware

Figura 3.3: Middleware

Dentro del Modulo de Middleware será necesario contar con los siguientesmódulos:

3.5.1.1. Control de Replica de Tramas

Este modulo deberá estar contenido dentro del middleware y se deberá en-cargar de proporcionar un medio de análisis de la trama y así determinar que latrama en cuestión no ha sido decodificada previamente, esto para conseguir elahorro de procesamiento al evitar el tratamiento y envió de tramas “replica”, obien con la misma información.

Ya que al tratarse de dispositivos de bajo consumo y contar con recursoslimitados es necesario ocupar los tiempos y recursos de procesamiento para lagestión de nueva información y no información no significativa para el sistema.Se propone que esto se consiga a través del calculo de un digesto a partir de una

58

3.5 Especificación de la Arquitectura

función hash ya que esta al ser calculada solamente brindará un digesto diferenteen caso de que la información contenida es diferente.

3.5.1.2. Gestión y Decodificación de Tramas

Este modulo es de suma importancia ya que se encargará de la decodificaciónde las tramas ya que al provenir de redes que trabajan bajo distintos protocoloses necesario gestionar y extraer la información contenida en los diferentes forma-tos de trama, es decir transformar la trama a un objeto de tipo json para que elservidor pueda procesar la información así mismo en caso de ser necesario ha-cer la transformación de la trama para la retransmisión a algún otro sistema odispositivo frontera.

3.5.1.3. Manejo de Nodo de Origen Destino

Esto es debido a que es necesario saber la fuente de dicha información asícomo el manejo del dispositivo destino en caso de ser necesario. El conocer el nodoorigen nos proveerá de información estadística necesaria para poder conocer elestado en cierto lugar, sistema o subsistema del cual proviene la información; elnodo destino sirve para saber el formato y el dispositivo que espera la informacióngenerada por el sistema.

3.5.1.4. Manejo de Peticiones

Esto es para poder determinar a partir de la trama recibida la acción a realizar yasí mismo una vez conocida la acción a realizar llevar a cabo la petición necesariaal micro servicio adecuado, o bien conocer cual es la información requerida yhacer la solicitud necesaria a la red de sensores encargada de obtener dichainformación.

59


3.5.2. Arquitectura de Conexión de Servicios

Este módulo se realizará en una arquitectura basada en micro servicios, yaque esto trae consigo una alta mantenibilidad y escalabilidad de cualquiersistemas ya que todos los procesos realizados por el sistema se deberá des-

componer en módulos pequeños e independientes esto con el objetivo de repartirel consumo y los recursos utilizados en la nube.

Los módulos que conforman la arquitectura ce conexión de servicios son lossiguientes.

Figura 3.4: Módulo de conexión de servicios

3.5.2.1. Módulo de Control de Acceso

Este modulo es el encargado de permitir el acceso y las peticiones a los dife-rentes usuarios así como el manejo de peticiones, para autorizar o bien denegarel acceso a los diferentes servicios tanto por usuarios del sistema y módulos in-ternos del sistema o bien sistemas externos que cuenten con una autorizaciónprevia de consumo. Dicho control de acceso y autenticación se realizará median-te Oauth 2.0 el cual es un protocolo de control de acceso basado en tokens, loscuales son el token de acceso (es brindado por el servidor de autenticación parapoder accesar al sistema y define el perfil del usuario), Token de aplicación (es eltoken que permite determinar si el medio por el cual esta teniendo acceso a losmicro servicios el usuario es válido o no), y por último el token de refresco esto

60

3.5 Especificación de la Arquitectura

es debido a que para tener un mejor control de acceso y evitar sesiones activas“estancadas” o sin acciones esto se hace mediante un tiempo de vida de token esel cual establece por cuanto tiempo el token proporcionado seguirá siendo valido,en caso de ser necesario el token de refresco sirve para poder hacer el intercam-bio de tokens y así el usuario cuente con una sesión activa siempre y cuando elusuario siga haciendo uso del sistema. Oauth 2.0.- OAuth 2.0 es el protocolo deautorización estándar de la industria. OAuth 2.0 reemplaza el trabajo realizado enel protocolo OAuth original creado en 2006. OAuth 2.0 se centra en la simplicidaddel desarrollador del cliente al tiempo que proporciona flujos de

autorización específicos para aplicaciones web, aplicaciones de escritorio, te-léfonos móviles y dispositivos de sala de estar. Esta especificación se está desa-rrollando dentro del IETF OAuth WG.

3.5.2.2. Módulo de Control de Perfiles

Este módulo es necesario ya que mediante este este, se dará acceso a losdiferentes módulos dentro del sistema, así como dar un seguimiento personalizadodel usuario para conocer a que servicios esta accediendo y proporcionar unaexperiencia integral, así mismo el control de perfiles se refiere al nivel de accesotanto de servicios como de nivel de acceso de información según los permisos y elperfil del usuario.

3.5.2.3. Módulo de Interconexión con Múltiples Servicios

Este modulo será el encargado de exponer a aplicaciones externas ciertosservicios para que dichas aplicaciones puedan explotar y obtener información oservicios generados dentro del sistema, así como proveer un medio para que elsistema pueda consumir y acceder a diferentes servicios o información generadospor sistemas externos al mismo (Siempre y cuando dichos servicios hallan sidoexpuestos de una forma estándar y publica para su uso). Esto con el fin de obteneresa colaboración entre sistemas buscada dentro del modelo de Internet de lascosas en su capa superior.

3.5.2.4. Módulo de Interconexión de Servicios Internos

Este módulo es muy importante ya que se encarga de monitorear cada uno delos micro servicios proporcionados por el sistema, conociendo así las peticionesque hallan generado algún problema al micro servicio, conocer los errores internosque se pudieran llegar a generar, así como también conocer la carga de peticionesde cada uno de los micro servicios, para que con esta información obtenida sepuedan tomar las medidas necesarias para asegurar el correcto funcionamientogeneral del sistema.

61


3.6. Arquitectura Propuesta

Una vez analizado todos los módulos necesarios para el desarrollo de laarquitectura se puede optar por seleccionar tecnologías para hacer cadauno de los módulos de la arquitectura a realizar, los cuales se explican a

continuación.

Figura 3.5: Arquitectura de Servicios con Tecnología

3.6.1. Tecnologías Usadas

En la figura 3.5 mostrada con anterioridad se puede observar un diagramade Despliegue en el cual se muestra la implantación de la arquitecturacon la propuesta , a continuación se explicará en las siguientes secciones

las tecnologías empleadas.

3.6.1.1. Middleware

El middleware esta diseñado para trabajar a dos diferentes niveles un midd-leware independiente por cada red de sensores el cual deberá ser diseñado yseleccionado según las necesidades y comportamiento de la red en cuestión.

Por otra parte el middleware de conexión se encargará del control de replicade tramas así como la gestión decodificación de tramas así como la redirecciónde peticiones a los micro servicios. Dicho middleware será diseñado utilizando el

62

3.6 Arquitectura Propuesta

framework express.nodejs ya que es un framework especializado en la elaboraciónde middlewares.

Express Es una infraestructura web de direccionamiento y middleware que tieneuna funcionalidad mínima propia: una aplicación Express es fundamentalmenteuna serie de llamadas a funciones de middleware. Las funciones de middlewareson funciones que tienen acceso al objeto de solicitud (req), al objeto de respuesta(res) y a la siguiente función de middleware en el ciclo de solicitud/respuestasde la aplicación. La siguiente función de middleware se denota normalmente conuna variable denominada next. Las funciones de middleware pueden realizar lassiguientes tareas:

Ejecutar cualquier código.

Realizar cambios en la solicitud y los objetos de respuesta.

Finalizar el ciclo de solicitud/respuestas.

Invocar la siguiente función de middleware en la pila.

Una aplicación Express puede utilizar los siguientes tipos de middleware:

Middleware de nivel de aplicación.

Middleware de nivel de direccionador.

Middleware de manejo de errores.

Middleware incorporado.

Middleware de terceros.

Puede cargar middleware de nivel de aplicación y de nivel de direccionadorcon una vía de acceso de montaje opcional. También puede cargar una seriede funciones de middleware a la vez, lo que crea una subpila del sistema demiddleware en un punto de montaje [37]

63


3.6.1.2. Arquitectura de Interconexión de Servicios

Esta arquitectura esta conformada por diferentes módulos los cuales se defi-nen a continuación

Frontend Para el desarrollo de una aplicación cliente que consuma los microservicios se propone un app web responsiva diseñada con el uso de Angular.jsHTML5, css3 y JS pero esto queda completamente a decisión del desarrollador loúnico solicitado es que sea un framework que soporte la modularización y trabajemediante el paradigma Modelo Vista Controlador.

AngularJS Es un marco estructural para aplicaciones web dinámicas. Lepermite usar HTML como su lenguaje de plantilla y le permite extender la sintaxisde HTML para expresar los componentes de su aplicación de forma clara y conci-sa. El enlace de datos y la inyección de dependencia de AngularJS eliminan granparte del código que, de otro modo, tendrías que escribir. Y todo sucede dentrodel navegador, lo que lo convierte en un socio ideal con cualquier tecnología deservidor. AngularJS es lo que HTML habría sido si hubiera sido diseñado paraaplicaciones. HTML es un excelente lenguaje declarativo para documentos está-ticos. No contiene mucho en la forma de crear aplicaciones, y como resultado laconstrucción de aplicaciones web es un ejercicio en lo que tengo que hacer paraengañar al navegador y hacer lo que quiero. La falta de correspondencia de la im-pedancia entre las aplicaciones dinámicas y los documentos estáticos a menudose resuelve con:

Una biblioteca: una colección de funciones que son útiles al escribir aplica-ciones web. Su código está a cargo y llama a la biblioteca cuando lo considereoportuno. Por ejemplo, jQuery.

Frameworks: una implementación particular de una aplicación web, dondesu código rellena los detalles. El marco está a cargo y llama a su código cuandonecesita algo específico de la aplicación. Por ejemplo, durandal, brasas, etc.

AngularJS toma otro enfoque. Intenta minimizar la falta de correspondenciade la impedancia entre el HTML centrado en el documento y lo que una aplicaciónnecesita al crear nuevas construcciones HTML. AngularJS le enseña al navega-dor nueva sintaxis a través de una construcción que llamamos directivas [38].Ejemplos incluyen:

Enlace de datos, como en .

Estructuras de control DOM para repetir, mostrar y ocultar fragmentosDOM.

Soporte para formularios y validación de formularios.

64


Adjuntando un nuevo comportamiento a los elementos DOM, como el ma-nejo de eventos DOM.

Agrupación de HTML en componentes reutilizables.

CSS3 Es la última evolución del lenguaje de las Hojas de Estilo en Cascada(Cascading Style Sheets), y pretende ampliar la versión CSS2.1. Trae consigo mu-chas novedades altamente esperadas , como las esquinas redondeadas, sombras,gradientes , transiciones o animaciones, y nuevos layouts como multi-columnas,cajas flexibles o maquetas de diseño en cuadrícula (grid layouts). Las partes ex-perimentales son particulares para cada navegador y deberían ser evitadas enentornos de producción, o usadas con extrema precaución, ya que tanto la sinta-xis como la semántica pueden cambiar en el futuro[39].

JavaScript (JS) Es un lenguaje ligero e interpretado, orientado a objetos confunciones de primera clase, más conocido como el lenguaje de script para páginasweb, pero también usado en muchos entornos sin navegador, tales como node.jso Apache CouchDB. Es un lenguaje script multi-paradigma, basado en prototi-pos, dinámico, soporta estilos de programación funcional, orientada a objetos eimperativa [40].

Backend Para el desarrollo de micro servicios se propone el uso de Python enel entorno Django REST framework pero esto queda completamente a decisióndel desarrollador lo único solicitado es que sea un framework que soporte lamodularización y trabaje mediante el paradigma Modelo Vista Controlador.

Django REST El marco Django REST es un conjunto de herramientas poten-te y flexible para crear API web.Algunas razones por las que puede querer utilizarel marco REST:

La API navegable web es una gran ventaja de usabilidad para sus desarro-lladores.

Políticas de autenticación que incluyen paquetes para OAuth1a y OAuth2.

Serialización que admite fuentes de datos ORM y no ORM.

Personalizable hasta el final, solo emplea vistas basadas en funciones regu-lares si no necesita las funciones más potentes.

Amplia documentación y gran apoyo de la comunidad.

Utilizado y acreditado por empresas reconocidas internacionalmente comoMozilla, Red Hat, Heroku y Eventbrite.

65


3.6.1.3. Sistema de Registro de Errores

Este módulo es necesario para el manejo de errores es decir hace un manejode log de los errores que han sido generados y donde fueron generados ademásde poder monitorear el estado de cada micro servicio para así poder determinar lacarga en servidor y poder tomar las medidas precautorias necesarias, para estecaso ha sido decidido hacer uso de Sentry para esta actividad.

Sentry Seguimiento de errores de código abierto que ayuda a los desarrolladoresa supervisar y corregir bloqueos en tiempo real, Itera continuamente, aumenta laeficiencia y mejora la experiencia del usuario [41].

3.6.1.4. Enrutador de Peticiones (API Gateway)

El API Gateway es un servicio totalmente administrado que facilita a los desa-rrolladores la creación, la publicación, el mantenimiento, la monitorización y laprotección de API a cualquier escala[42], esto con el fin del manejo de re direccio-namiento de peticiones a los diferentes micro servicios que componen el sistema,logrando con esto una mejor distribución de las peticiones y la carga dentro de losmicro servicios para lograr esto se propone el uso de Tyk pero nuevamente quedaesto en consideración de los desarrolladores y necesidades de los otros sistemasque deseen basarse en la presente arquitectura [42].

Tyk Tyk Gateway atenderá solicitudes entrantes, las ejecutará a través de unconjunto de componentes de middleware que aplican transformaciones y cual-quier otra operación específica del servicio, y luego volverá a proxy la solicitudal origen, interceptando la respuesta, ejecutando un conjunto de middleware derespuesta y luego regresando Tyk también puede ejecutar componentes de midd-leware dinámico escritos en JavaScript, y desde v2.3 otros idiomas, en cualquierextremo del middleware incorporado [42].

3.6.1.5. Contenedor Linux

El uso de contenedores nos permite un encapsulamiento de micro servicioslo cual trae consigo la ventaja de mantener aislados cada uno de ellos, lo cualtrae consigo escalabilidad y mantenibilidad de sistema ya que se pueden agre-gar nuevos módulos sin afectar los anteriores, sustituir módulos o expandir lascaracterísticas de algún modulo sin que esto afecte a algún otro. Para esto serecomienda el uso de Docker, ya que esto trae consigo contenedores ligeros y por-tables para las aplicaciones software que puedan ejecutarse en cualquier máquinacon Docker instalado, independientemente del sistema operativo que la máquinatenga por debajo, facilitando así también los despliegues.

66


Docker Es una herramienta diseñada para beneficiar tanto a desarrolladores,testers, como administradores de sistemas, en relación a las máquinas, a losentornos en sí donde se ejecutan las aplicaciones software, los procesos de des-pliegue, etc. En el caso de los desarrolladores, el uso de Docker hace que puedancentrarse en desarrollar su código sin preocuparse de si dicho código funcionaráen la máquina en la que se ejecutará [43].

3.6.1.6. Automatizador de Mensajes

Dentro de la informática, RabbitMQ es un software de negociación de mensajesde código abierto, y entra dentro de la categoría de middleware de mensajería.Implementa el estándar Advanced Message Queuing Protocol (AMQP). El servidorRabbitMQ está escrito en Erlang y utiliza el framework Open Telecom Platform(OTP) para construir sus capacidades de ejecución distribuida y conmutación anteerrores. Rabbit Technologies Ltd., la compañía que lo desarrolla, fue adquirida enabril de 2010 por la división SpringSource de VMWare. A partir de este momento,es esta última compañía la que desarrolla y da soporte para RabbitMQ [44].

El código fuente está liberado bajo la licencia Mozilla Public License. A partirde Mayo del 2013, por una unión de empresas, Pivotal es el nuevo patrocinantedel proyecto. El proyecto RabbitMQ consta de diferentes partes:

El servidor de intercambio RabbitMQ en sí mismo

Pasarelas para los protocolos HTTP, XMPP y STOMP.

Bibliotecas de clientes para Java y el framework .NET. (Bibliotecas similarespara otros lenguajes se encuentran disponibles por parte de otros provee-dores).

El plugin Shovel (pala) que se encarga de copiar (replicar) mensajes desdeun corredor de mensajes a otros

67


3.7. Caso de Estudio

Las unidades de atención médica del Instituto Politécnico Nacional requie-ren la información médica vital de la comunidad que desea realizar unaconsulta, como puede ser sus datos personales, tipo sanguíneo, vacunas y

alergias. Sin embargo, una persona puede desconocer esa información al momen-to de asistir a la consulta ocasionando retrasos en la atención médica o cuandose solicita un servicio dentro del instituto.

Por otro lado, los servicios que ofrece el IPN se encuentran en diferentes unida-des académicas y edificios ubicados en diferentes sedes, por lo cual en ocasionesespeciales se les solicita a las personas que solicitan los servicios adquirir unacredencial específica para cada uno de los servicios, lo cual representa un gastoinnecesario de tiempo y recursos para el instituto.

Para la comunidad politécnica le sería de gran utilidad contar con una formade identificación que al mismo tiempo le sirva como medio para almacenar suinformación personal y médica vital para que al momento de solicitar uno de lostantos servicios que ofrece el Instituto Politécnico Nacional pueda obtenerlo deuna manera ágil y sin retrasos innecesarios. Al mismo tiempo se podría teneracceso a la información del solicitante desde cualquier unidad de atención.

Figura 3.6: Carnet de Servicios Politécnicos

Se propone desarrollar un sistema que permita a los miembros de la comuni-dad del Instituto Politécnico Nacional tener un acceso ágil y cómodo a los serviciosque ofrece la institución, así como medio de identificación que los acredite comomiembros de la comunidad (estudiantes, docentes o empleados). Así mismo el

68

3.7 Caso de Estudio

medio además de identificarlos contendrá la información personal y médica vitaldel solicitante con la finalidad de que los encargados de brindar un servicio dentrodel instituto puedan ofrecerlo de manera sencilla y además tener un historial delas actividades del solicitante.

Se propone que se implemente el servicio médico institucional como primerservicio para probar esta propuesta de arquitectura. Pero la arquitectura se de-finiría para poder implementar cualquier servicio existente o dará la pauta paracrear servicios basándose en estándares. El servicio médico Institucional se apoyaen los siguientes aspectos:

Atención médica de primer contacto.

Referencia de padecimientos específicos a su respectiva especialidad.

Para el caso de los servicios médicos de optometría, nutriología, odontología ymedicina preventiva usarán la información almacenada dentro del medio de iden-tificación para realizar un diagnóstico médico correcto tomando en cuenta datoscomo alergias, tipo sanguíneo, historial de vacunas e historial de consultas. Elmedio de identificación y que contiene la información, será conocido como Car-net de Servicios Politécnicos y será una credencial que contendrá la informaciónalmacenada en un tag NFC. Cada una de las unidades de atención dentro del ins-tituto donde se ofrecen los servicios para la comunidad politécnica podrá atenderal solicitante pidiendo su carnet para poder obtener su información e identificar-lo como miembro del IPN, esta operación se realizará a través de un lector NFCque se encontrará conectado a una aplicación de escritorio o inalambrica dondese visualizará la información necesaria para poder acceder al servicio. Se tendrátambién un servidor en donde se almacenará el historial de todas los servicios queha solicitado una persona y el historial necesario para casos específicos, siendopor ejemplo el historial de consultas médicas para el caso de cualquier área médi-ca ó el historial de préstamos y adeudos para el servicio de biblioteca. El sistemacontará también con un portal web en donde los usuarios de la comunidad podránacceder con un nombre de usuario y contraseña en el cual tendrán la oportunidadde visualizar el historial de sus solicitudes y su información general. Diagrama abloques de Propuesta de solución

69


A continuación se presenta el diagrama a bloques de la arquitectura propuesta:

Figura 3.7: Diagrama de Bloques de la solución

La arquitectura se conforma de seis módulos básicos que permiten crear unnúcleo de operación de la misma:

Módulo de Registro: Permitirá generar el registro de los usuarios del sistema.

Módulo de Carnet de Servicios: Este módulo se encargara de administrarel acceso e identificación de un perfil para la asignación de los servicioscorrespondientes.

Módulo de Asignación de Perfiles: En él se asigna el perfil que correspondeal usuario de acuerdo a los servicios que requiere y tiene autorizados.

Módulo de Servicios: Este Módulo se encargara de realizar la conexión conlos servicios que se tengan disponibles.

Módulo de Interacción: El módulo de interacción provee la forma de comu-nicación entre servicios y sistemas.

Módulo de Reportes y estadísticas: Todo sistema debe contar con una formade monitoreo del estado del mismo.

70

3.8 Metodología de Desarrollo

3.8. Metodología de Desarrollo

Debido a la naturaleza del proyecto y el tiempo otorgado para la realizacióndel mismo, se ha decidido utilizar la metodología SCRUM. Dicha metodo-logía es adecuada para equipos interdisciplinarios que cuentan con un

tiempo relativamente corto para la fase de Implementación.Scrum es un proceso de la Metodología Ágil que se usa para minimizar los ries-

gos durante la realización de un proyecto, pero de manera colaborativa. Entre lasventajas se encuentran la productividad, calidad y que se realiza un seguimien-to diario de los avances del proyecto, logrando que los integrantes estén unidos,comunicados y que el cliente vaya viendo los avances. Scrum es un proceso en elque se aplican de manera regular un conjunto de buenas prácticas para trabajarcolaborativamente, en equipo, y obtener el mejor resultado posible de un proyecto.Estas prácticas se apoyan unas a otras y su selección tiene origen en un estudiode la manera de trabajar de equipos altamente productivos. En Scrum se realizanentregas parciales y regulares del producto final, priorizadas por el beneficio queaportan al receptor del proyecto. Por ello, Scrum está especialmente indicado pa-ra proyectos en entornos complejos, donde se necesita obtener resultados pronto,donde los requisitos son cambiantes o poco definidos, donde la innovación, lacompetitividad, la flexibilidad y la productividad son fundamentales.

Scrum también se utiliza para resolver situaciones en que no se está entre-gando al cliente lo que necesita, cuando las entregas se alargan demasiado, loscostes se disparan o la calidad no es aceptable, cuando se necesita capacidad dereacción ante la competencia, cuando la moral de los equipos es baja y la rotaciónalta, cuando es necesario identificar y solucionar ineficiencias sistemáticamenteo cuando se quiere trabajar utilizando un proceso especializado en el desarrollode producto.

3.8.1. Características Principales

SCRUM es una metodología basada en las personas, en la cual existen tresroles principales:

Dueño del producto: Tiene la decisión sobre las características que seránañadidas al producto final.

SCRUM Master: Un facilitador que ayuda al equipo a resolver situacionesque impidan el desempeño adecuado del equipo. Sin embargo, no tiene con-trol sobre el equipo de desarrollo

Equipo de desarrollo: Un conjunto de individuos auto organizados con lascapacidades necesarias para el desarrollo del proyecto.

71


De acuerdo a la metodología, las personas anteriormente mencionadas se involu-cran en una serie de actividades iterativas para llegar a un producto terminado.

Dichas actividades incluyen:

Planeación del producto: El dueño del producto y el equipo revisan y asig-nan prioridades a las características que deberá de tener el producto. Paraproyectos que ya se encuentran en desarrollo se pueden incluir mejoras,correcciones de defectos, entre otros.

Planeación del sprint: El equipo de desarrollo revisa la lista de pendientesjunto con el dueño del producto y calendariza el tiempo del sprint, quecomprenderá por máximo un mes. Posteriormente se genera una lista deactividades del sprint que asegure un ritmo de trabajo cómodo y sustentablepara el equipo.

Ejecución del sprint: Se realizan las actividades necesarias para obtenerel producto deseado. Al final de ésta etapa se considera que ya existe unincremento de producto potencialmente comercializable.

Revisión: Se revisa el desarrollo particular contrastándolo con los objetivosdel proyecto. Además, se revisan aspectos del desarrollo y la metodologíapara mejorar el desempeño del equipo de desarrollo.

72

3.8 Metodología de Desarrollo

Figura 3.8: Diagrama de SCRUM [1]

El proceso En Scrum un proyecto se ejecuta en ciclos temporales cortos y deduración fija (iteraciones que normalmente son de 2 semanas, aunque en algunosequipos son de 3 y hasta 4 semanas, límite máximo de feedback de producto realy reflexión). Cada iteración tiene que proporcionar un resultado completo, unincremento de producto final que sea susceptible de ser entregado con el mínimoesfuerzo al cliente cuando lo solicite.

El proceso parte de la lista de objetivos/requisitos priorizada del producto,que actúa como plan del proyecto. En esta lista el cliente prioriza los objetivosbalanceando el valor que le aportan respecto a su coste y quedan repartidos eniteraciones y entregas.

El proceso parte de la lista de objetivos/requisitos priorizada del producto, queactúa como plan del proyecto. En esta lista el cliente (Product Owner) prioriza losobjetivos balanceando el valor que le aportan respecto a su coste (que el equipoestima considerando la Definición de Hecho) y quedan repartidos en iteracionesy entregas. Las actividades que se llevan a cabo en Scrum son las siguientes (lostiempos indicados son para iteraciones de 2 semanas).

73


74

IV

Resultados

ResultadosCapitulo 4: Resultados

4.1. Resultados

En el presente capítulo se expondrán los Resultados obtenidos al imple-mentar la arquitectura propuesta dentro del caso estudio en esta se abor-darán aspectos de consumos de Recursos, Costos y criterios de usabilidad

empleados en el desarrollo y funcionamiento del caso de estudio.Para poder denotar los resultados obtenidos de la arquitectura es necesario

documentar que la arquitectura propuesta fue implantada empleando el uso deuna IaaS (Infraestructura como Servicio) proveído por Amazon Web Services.

La monitorización es un aspecto importante del mantenimiento de la fiabilidad,la disponibilidad y el desempeño de las instancias de Amazon Elastic ComputeCloud (Amazon EC2) y las soluciones de AWS. Es conveniente recopilar datos demonitorización de todas las partes de las soluciones de AWS para que sea mássencillo depurar un error que se produce en distintas partes del código, en casode que ocurra.

Dentro de este caso de estudio se han tomado diferentes estadísticas entre lasmedidas que tomamos son las siguientes:

Uso de CPU El porcentaje de unidades informáticas EC2 asignadas quese usan actualmente en la instancia. Esta métrica identifica la capacidadde procesamiento necesaria para ejecutar una aplicación en una instanciaseleccionada.

Lectura en disco (Bytes)

Operaciones de Lectura en Disco Operaciones de lectura completadas detodos los volúmenes del almacén de instancias disponibles para la instanciaen un periodo de tiempo especificado.

Escritura en Disco (Bytes) Bytes leídos de todos los volúmenes del almacénde instancias disponibles para la instancia.

Esta métrica se usa para determinar el volumen de datos que la aplicaciónlee del disco duro de la instancia. Se puede usar para determinar la velocidadde la aplicación.

El número registrado es el número de bytes recibidos durante el periodo.

Operaciones de escritura en Disco Operaciones de escritura completadas entodos los volúmenes del almacén de instancias disponibles para la instanciaen un periodo de tiempo especificado.

77

Capitulo 4. Resultados

Uso de Red Entrada (Bytes)

El número de bytes recibidos en todas las interfaces de red por la instancia.Esta métrica identifica el volumen de tráfico de red entrante para una solainstancia. El número registrado es el número de bytes recibidos durante elperiodo.

Uso de Red Salidas (Bytes) El número de bytes enviados en todas las inter-faces de red por la instancia. Esta métrica identifica el volumen de tráficode red saliente de una sola instancia. El número registrado es el número debytes enviados durante el periodo.

Paquetes de Entrada El número de paquetes recibidos en todas las interfacesde red por la instancia. Esta métrica identifica el volumen de tráfico dered entrante en cuanto al número de paquetes de una sola instancia. Estamétrica solo está disponible para la monitorización básica.

Paquetes de Salida El número de paquetes enviados en todas las interfacesde red por la instancia. Esta métrica identifica el volumen de tráfico dered saliente en cuanto al número de paquetes de una sola instancia. Estamétrica solo está disponible para la monitorización básica.

Conteos de Fallos en Revisión (Total)Indica si la instancia ha superado lacomprobación de estado de la instancia y la comprobación de estado delsistema en el último minuto. Esta métrica puede ser 0 (superada) o 1 (nosuperada).

Conteos de Fallos en Revisión (Instancia) Indica si la instancia ha superadola comprobación de estado de la instancia en el último minuto.

Conteos de Fallos en Revisión (Sistema) Indica si la instancia ha superadola comprobación de estado del sistema en el último minuto.

Uso de crédito de la CPU La cantidad de créditos de CPU gastados porla instancia para el uso de CPU. Un crédito de CPU equivale a una vC-PU ejecutándose al cien porciento de utilización durante un minuto o unacombinación equivalente de unidades de vCPU, utilización y tiempo

78

4.1 Resultados

A continuación se presentan los resultados obtenidos con respecto a los dife-rentes módulos que conforman la arquitectura.

El api gateway es el encargado de conectar o enrutar las peticiones a cada unode los micro servicios. Como se puede observar en la figura 4.1 y 4.2 se puede

Figura 4.1: Estadísticas de Api Gateway parte 1

Figura 4.2: Estadísticas de Api Gateway parte 2

observar que no se presentaron problemas dentro de la instancia ni en generaldentro del presente módulo lo cual puede comprobar que se cuenta con un nivelde estabilidad acetable, así mismo el consumo de cpu es un consumo moderadoy como se espera el consumo de recursos de red de salida es moderado debido aque esta se encarga de encaminar las diferentes peticiones.

79


Los siguientes resultados corresponden al módulo de micro servicios, cabedestacar que estas estadísticas fueron medidas del servidor contenedor de todoslos micro servicios los cuales se encuentran encapsulados en contenedores linuxcomo fue explicado dentro del capítulo de Metodologia.

Figura 4.3: Estadísticas de los Micro servicios parte 1

Figura 4.4: Estadísticas de los Micro servicios parte 2

Como se puede observar en este modulo es mayor el consumo de procesa-miento de CPU debido a que dentro de este servidor se encuentran contenidoslos diferentes micro servicios (Lógica de Negocio) por lo cual este consumo depen-derá directamente de los micro servicios necesitados dependiendo el problema aresolver, pero como se puede observar al encapsular cada uno de los elementosse puede garantizar el comportamiento de conseguir en medida de lo posible laestabilidad, el comportamiento, y recursos para cada una de las funcionalidades(micro servicios).

80

4.1 Resultados

Las presentes estadísticas corresponden al modulo de Sentry el cual es elmodulo que se encarga de monitorizar el estado de los diferentes servicios asícomo los errores presentados dentro del funcionamiento de la plataforma. Como

Figura 4.5: Estadísticas de Sentry parte 1

Figura 4.6: Estadísticas de Sentry parte 2

se puede observar en este módulo existe un alto consumo de procesamiento y usode red, debido a que este al encargarse de estar capturando todas las operacionesdentro del sistema y sus resultados requiere un alto consumo de procesos enel CPU, así como emplear un alto volumen de trafico de datos debido a la altacantidad de peticiones con las cuales trabaja.

81


Este es el último módulo a destacar de la arquitectura debido a que este proveeun nivel mayor de seguridad ya que el es el encargado de poseer la informaciónde conexión a las bases de datos o la información para conectar los diferentesservicios.

Figura 4.7: Estadísticas de Vault parte 1

Figura 4.8: Estadísticas de Vault parte 2

82

4.2 Productos de Investigación

4.2. Productos de Investigación

En el transcurso del presente trabajo de investigación se han conseguido di-ferentes productos de investigación los cuales se mencionan a continuación.

Premio al mejor Software en su categoría Docente 2016, con sistema titu-lado Çarnet de Servicios Politécnicos", Premio expedido por la Dirección deEstudios Superiores del Instituto Politécnico Nacional.

Ponente en: 6to congreso Internacional de Telemáticas y Computación WIT-COM 2017, Título de la Ponencia:Architecture of Mobile Services applied tothe Internet of Things. 9 de Noviembre de 2017.

Architecture of Mobile Services applied to the Internet of Things. Chad-wick Carreto, Francisco Cerda and Felipe Menchaca. Research in Compu-ting Science – Advances in Computing Science. Noviembre de 2017. Volume.143, ISSN: 1870-4069. Pag, 166.

Ponente en: 7mo Congreso Internacional de Telemáticas y ComputaciónWITCOM 2018, Título de la Ponencia: Service Architecture of Systems Im-mersed in Internet of Things Paradigm. 8 de Noviembre de 2018.

Service Architecture of Systems Immersed in Internet of Things Paradigm.Francisco Cerda, Chadwick Carreto, and Felipe Menchaca. Communica-tions in Computer and Information Science. Springer 2018. , CCIS 944,pp. 147–157, ISSN 1865-0929

83


84

V

Conclusiones

ConclusionesCapitulo 5: Conclusiones

5.1. Conclusiones

Después de la investigación realizada y la implementación de la propuestadentro de un caso de estudio se ha llegado a las siguientes conclusiones.

Se determinaron el conjunto de características mínimas necesarias que debeposeer algún sistema que pretenda inter comunicarse con otros sistemas y esteinmerso dentro de un entorno de internet de las cosas.

Se pueden englobar y resumir las características necesarias en los siguientespuntos

Una plataforma modularizada y encapsulada.

Manejo de micro servicios.

Seguimiento de Todos los Servicios.

Establecimiento de un formato de intercambio.

Manejo de un sistema de enrutamiento de alta disponibilidad.

Implantación de un medio que permita la automatización de ciertos proce-sos.

Sistemas de control de acceso.

Manejo de control de perfiles.

Implantación de un medio que permita interconectar el sistema con multi-ples servicios y / ó sistemas.

Así mismo se detectaron un conjunto de áreas de oportunidad para fortalecerla arquitectura propuesta pero por causas de las limitaciones de tiempo no se pu-dieron proponer e implantar las cuales se mencionarán en el capítulo de TrabajoFuturo.

Se llego a la conclusión que es imposible proponer un único esquema o com-ponentes a incrustar dentro del modulo de middleware que se encontrará di-rectamente conectado con las redes de sensores dado que estas característicasdependerán directamente de la red de sensores en cuestión y las necesidades yfuncionalidades dentro de la red de sensores, lo importante a considerar es quese establezca un formato común de intercambio considerando el protocolo IEEE802.15.4, así como el conjunto de datos necesarios dentro de la cabecera del pa-quete establecidos en las redes thread, digi mesh, zigbee, y dejar por separadodentro de la trama el segmento de datos o de información.

87

Capitulo 5. Conclusiones

Las características mínimas que debe incluir el middleware son las siguientes:

Control de Replicas de Tramas.

Gestión y Decodificación de Tramas.

Manejos de Nodos Origen - Destino.

Manejo de Peticiones.

El caso de estudio sirvió para poder probar la arquitectura propuesta y asímismo sirvió como base para su reutilización y adaptación para otros sistemascomo fue el sistema de apoyo a la vinculación del IPN el cual fue acreedor alpremio al mejor software del IPN y al u-GeOBe Tecnología en Gobierno Digital locual también demuestra que la arquitectura propuesta provee la flexibilidad paraimplantarse en otros entornos y para solventar otras problemáticas.

88

VI

Trabajo Futuro

Trabajo FuturoCapítulo 6: Trabajo Futuro

6.1. Trabajo Futuro

Después de lo desarrollado nos hemos percatado de las diferentes caracterís-ticas o aspectos a mejorar o que pudieran complementar el sistema propuestoanteriormente son la integración de un medio que provea un medio de seguridadque pueda blindar el canal, dentro de las comunicaciones de las redes de sensores

En adición a lo mencionado sería la implantación de un middleware que corradentro de las redes de sensores de una forma más estándar que implemente algúnmedió de control de replica de tramas como puede ser una función Hash pero paradispositivos de bajas prestaciones.

91

Capítulo 6. Trabajo Futuro

92

BibliografíaBibliografía

[1] proyectosagiles.org, “Qué es scrum,” Oct 2016. [Online]. Available:https://proyectosagiles.org/que-es-scrum/

[2] J. Gubbi, R. Buyya, S. Marusic, and M. Palaniswami, “Internet of things (iot):A vision, architectural elements, and future directions,” Future Generation

Computer Systems, vol. 29, no. 7, p. 1645–1660, 2013.

[3] C. D. Rosso, “Continuous evolution through software architecture evaluation:a case study,” Journal of Software Maintenance and Evolution: Research and

Practice, vol. 18, no. 5, p. 351–383, 2006.

[4] K. Ashton et al., “That ‘internet of things’ thing,” RFID journal, vol. 22, no. 7,pp. 97–114, 2009.

[5] H. Sundmaeker, P. Guillemin, P. Friess, and S. Woel�é, “Vision and challen-ges for realising the internet of things,” Cluster of European Research Projects

on the Internet of Things, European Commision, vol. 3, no. 3, pp. 34–36, 2010.

[6] L. Yan, The internet of things: from RFID to the next-generation pervasive

networked systems. Auerbach Publ., 2008.

[7] S. de Salud, “Reglamento interior de la secretaria de salud„” Diario Oficial

de la Federación, 2016. [Online]. Available: http://www.dof.gob.mx/index.php?year=2016

[8] S. Heard and T. Beale, “What is openehr?” 2016. [Online]. Available:https://www.openehr.org/what_is_openehr

[9] P. K. Sinha, Distributed operating systems: concepts and design. Prentice-Hall of India, 2007.

[10] S. Vashi, J. Ram, J. Modi, S. Verma, and C. Prakash, “Internet of things(iot): A vision, architectural elements, and security issues,” 2017 International

Conference on I-SMAC (IoT in Social, Mobile, Analytics and Cloud) (I-SMAC),2017.

[11] M. A. Razzaque, M. Milojevic-Jevric, A. Palade, and S. Clarke, “Middlewarefor internet of things: A survey,” IEEE Internet of Things Journal, vol. 3, no. 1,p. 70–95, 2016.

[12] M. A. and S. T., “Internet of things: Architecture, security issues and counter-measures,” International Journal of Computer Applications, vol. 125, no. 14,p. 1–4, 2015.

93

https://proyectosagiles.org/que-es-scrum/

http://www.dof.gob.mx/index.php?year=2016

http://www.dof.gob.mx/index.php?year=2016

https://www.openehr.org/what_is_openehr

BIBLIOGRAFÍA

[13] Tap2tag.me, “Tap2tag medical alert bracelets, keyfobs, stickers cards.” [On-line]. Available: https://www.tap2tag.me/what-is-tap2tag-medical-alert/

[14] Blueowlcreative.com, “Servicio alerta-médica.” [Online]. Available: http://www.alerta-medica.com/alertamedica.html

[15] Infovital.mx, “Infovital | your medical history always with you,” Nov 2015.[Online]. Available: http://www.infovital.mx

[16] W. Chu, “Pdc rfid wristbands, products and solutions – wristbands.com,”Feb 2017. [Online]. Available: https://www.wristbands.com/pages/rfid-solutions

[17] S. de Salud, “Norma oficial mexicana nom-004-ssa3-2012, del expedienteclínico„” Diario Oficial de la Federación, 2012. [Online]. Available:http://dof.gob.mx/nota_detalle_popup.php?codigo=5272787

[18] ISO, “Health informatics — requirements for an electronic health recordarchitecture.” [Online]. Available: https://www.iso.org/obp/ui/#iso:std:iso:18308:ed-1:v1:en

[19] S. General, “Ley federal de protección de datos personales en posesión delos particulares,” Jul 2010. [Online]. Available: http://www.diputados.gob.mx/LeyesBiblio/pdf/LFPDPPP.pdf

[20] D. Kapil, P. Tyagi, S. Kumar, and V. P. Tamta, “Cloud computing: Overviewand research issues,” 2017 International Conference on Green Informatics

(ICGI), 2017.

[21] M. Papazoglou, “Service-oriented computing: concepts, characteristics anddirections,” Proceedings of the 7th International Conference on Properties and

Applications of Dielectric Materials (Cat. No.03CH37417), 2003.

[22] E. K. Lua, J. Crowcroft, M. Pias, R. Sharma, and S. Lim, “A survey andcomparison of peer-to-peer overlay network schemes,” IEEE Communications

Surveys Tutorials, vol. 7, no. 2, p. 72–93, 2005.

[23] G. Hohpe, “Programming without a call stack–event-driven architectures,”2006.

[24] M. Azure, “What is middleware?” [Online]. Available: https://azure.microsoft.com/en-us/overview/what-is-middleware/

[25] D. Evans, “The internet of things: How the next evolution of the internet ischanging everything,” CISCO white paper, vol. 1, no. 2011, pp. 1–11, 2011.

94

https://www.tap2tag.me/what-is-tap2tag-medical-alert/

http://www.alerta-medica.com/alertamedica.html

http://www.alerta-medica.com/alertamedica.html

http://www.infovital.mx

https://www.wristbands.com/pages/rfid-solutions

https://www.wristbands.com/pages/rfid-solutions

http://dof.gob.mx/nota_detalle_popup.php?codigo=5272787

https://www.iso.org/obp/ui/#iso:std:iso:18308:ed-1:v1:en

https://www.iso.org/obp/ui/#iso:std:iso:18308:ed-1:v1:en

http://www.diputados.gob.mx/LeyesBiblio/pdf/LFPDPPP.pdf

http://www.diputados.gob.mx/LeyesBiblio/pdf/LFPDPPP.pdf

https://azure.microsoft.com/en-us/overview/what-is-middleware/

https://azure.microsoft.com/en-us/overview/what-is-middleware/

BIBLIOGRAFÍA

[26] M. Frustaci, P. Pace, G. Aloi, and G. Fortino, “Evaluating critical securityissues of the iot world: Present and future challenges,” IEEE Internet of Things

Journal, vol. 5, no. 4, p. 2483–2495, 2018.

[27] C. Pérez-Miguel, J. Miguel-Alonso, and A. Mendiburu, “Informe sobre siste-mas de computación en redes p2p,” Tech. Rep.

[28] N. I. Corporation, “What is a wireless sensor network?” Jan 2015. [Online].Available: http://www.ni.com/white-paper/7142/es/

[29] J. T. Inc., Network protocols handbook. Javvin Technologies, 2007.

[30] “Zigbee for developers,” Jun 2017. [Online]. Available: https://www.zigbee.org/zigbee-for-developers/

[31] D. cert, “Wireless mesh networking: ZigbeeR� vs. digimesh,” 2017. [Online].Available: https://www.digi.com/pdf/wp_zigbeevsdigimesh.pdf

[32] ——, “Digi xbee3 digimesh 2.4.” [Online]. Available: https://www.digi.com/support/supporttype?type=documentation

[33] T. Group, “Thread stack fundamentals,” Jul 2015. [Onli-ne]. Available: https://portal.threadgroup.org/DesktopModules/Inventures_Document/FileDownload.aspx?ContentID=633

[34] T. I. Society, “Network policy and services: A report of a workshop onmiddleware.” [Online]. Available: https://tools.ietf.org/html/rfc2768

[35] D. H. Microsoft, “The oauth 2.0 authorization framework,” Oct 2012.[Online]. Available: https://tools.ietf.org/html/rfc6749

[36] V. R. Konduru and M. R. Bharamagoudra, “Challenges and solutions of inter-operability on iot: How far have we come in resolving the iot interoperabilityissues,” 2017 International Conference On Smart Technologies For Smart Na-

tion (SmartTechCon), 2017.

[37] F. Node.js, “Utilización del middleware,” 2017. [Online]. Available:http://expressjs.com/es/guide/using-middleware.html

[38] Google, “What is angularjs?” 2017. [Online]. Available: https://docs.angularjs.org/guide/introduction

[39] M. web Docs, “Css3,” Aug 2016. [Online]. Available: https://developer.mozilla.org/es/docs/Web/CSS/CSS3

[40] ——, “Js,” Sep 2018. [Online]. Available: https://developer.mozilla.org/es/docs/Web/JavaScript

95

http://www.ni.com/white-paper/7142/es/

https://www.zigbee.org/zigbee-for-developers/

https://www.zigbee.org/zigbee-for-developers/

https://www.digi.com/pdf/wp_zigbeevsdigimesh.pdf

https://www.digi.com/support/supporttype?type=documentation

https://www.digi.com/support/supporttype?type=documentation

https://portal.threadgroup.org/DesktopModules/Inventures_Document/FileDownload.aspx?ContentID=633

https://portal.threadgroup.org/DesktopModules/Inventures_Document/FileDownload.aspx?ContentID=633

https://tools.ietf.org/html/rfc2768

https://tools.ietf.org/html/rfc6749

http://expressjs.com/es/guide/using-middleware.html

https://docs.angularjs.org/guide/introduction

https://docs.angularjs.org/guide/introduction

https://developer.mozilla.org/es/docs/Web/CSS/CSS3

https://developer.mozilla.org/es/docs/Web/CSS/CSS3

https://developer.mozilla.org/es/docs/Web/JavaScript

https://developer.mozilla.org/es/docs/Web/JavaScript

BIBLIOGRAFÍA

[41] forum.sentry.io, “Getting started,” 2017. [Online]. Available: https://docs.sentry.io/error-reporting/quickstart/?platform=javascript

[42] T. Technologies, “Tyk documentation,” 2017. [Online]. Available: https://tyk.io/docs/

[43] D. Inc, “Docker documentation,” Aug 2017. [Online]. Available: https://docs.docker.com/

[44] Pivotal, “News,” Nov 2017. [Online]. Available: http://www.rabbitmq.com/news.html

96

https://docs.sentry.io/error-reporting/quickstart/?platform=javascript

https://docs.sentry.io/error-reporting/quickstart/?platform=javascript

https://tyk.io/docs/

https://tyk.io/docs/

https://docs.docker.com/

https://docs.docker.com/

http://www.rabbitmq.com/news.html

http://www.rabbitmq.com/news.html

VII

Anexos

AnexosCapítulo 7: Anexos

7.1. Introducción

En la presente sección se anexa el manual técnico del caso de estudio, tituladoÇarnet de Servicios Politécnicos".

Un manual técnico es aquel que va dirigido a un público con conocimientostécnicos sobre algún área. Se debe presentar una breve descripción del sistemadesarrollado, que contemple el ámbito abarcado, cual es su función principal yun detalle de las funciones macros o partes que lo componen.

99

Anexos

100

CARNET DE SERVICIOS POLITECNICOS

Manual Técnico Resumen: En el presente documento se muestra la propuesta de una Arquitectura Modular y un Sistema de unificación de servicios para el Instituto Politécnico Nacional, por medio de un Tag de identificación (tarjeta inteligente) para el acceso a diversos servicios que oferta el IPN para su comunidad (Médicos, Académicos, Bibliotecarios, Laboratorios, Deportivos, Culturales, etc), en busca de contar con una herramienta de apoyo para incluir a los servicios politécnicos en las nuevas tendencias tecnológicas encaminadas al desarrollo de Ciudades Inteligentes (Smart Cities), es por esta causa que se requiere de un medio que permita a los usuarios integrarse a los servicios que ofrecería un Campus Politécnico Inteligente. La Arquitectura se propone de tal manera que en una primera etapa se genera un módulo de servicios médicos para contar de acuerdo a la norma oficial con un historial clínico de la Comunidad Politécnica. En siguientes etapas se puede implementar esta Arquitectura a diversos servicios politécnicos.

Anexos

101

Contenido Capítulo 1 – Problemática ......................................................................................................................... 103

Capítulo 2 – Propuesta de Solución ......................................................................................................... 106

Capítulo 1.1 Diagrama a bloques de Propuesta de solución ................................................................. 107

Capítulo 1.2 Tecnologías y técnicas a Utilizar ...................................................................................... 109

Capítulo 1.2.1 Patrón de Diseño Modelo-Vista-Controlador .......................................................... 109

Capítulo 3.2.2 Frameworks para la Web ......................................................................................... 110

Capítulo 1.2.3 Modelo ..................................................................................................................... 110

Capítulo 1.2.4 Vista .......................................................................................................................... 110

Capítulo 1.2.5 Controlador .............................................................................................................. 111

Capítulo 1.2.6 Arquitectura RESTful .............................................................................................. 112

Capítulo 2 Análisis ..................................................................................................................................... 117

Capítulo 2.1 Requerimientos del Sistema ............................................................................................. 117

Capítulo 2.1.1 Requerimientos Funcionales ..................................................................................... 117

Capítulo 2.1.2 Requerimientos No Funcionales ............................................................................... 118

Capítulo 3 Diseño ...................................................................................................................................... 119

Capítulo 3.1 Diagramas de Arquitectura .............................................................................................. 119

Capítulo 3.2 Diagramas de Casos de uso .............................................................................................. 120

Capítulo 3.2.1 Diagramas de Casos de uso Autenticación ............................................................... 120

Capítulo 3.3 Diagramas de Base de Datos Modelo Relacional ............................................................ 122

Capítulo 3.4 Diagrama de Clases .......................................................................................................... 124

Capítulo 3.4.1 Diagramas de Clases (Relaciones entre Clases) ........................................................ 124

Capítulo 3.4.2 Diagramas de Clases Modulo de Carnet .................................................................. 124

Capítulo 3.5 Diagramas de Secuencia: ................................................................................................. 126

Capítulo 3.5.1 Secuencia Log In ...................................................................................................... 126

Capítulo 3.5.2 Secuencia Log Out ................................................................................................... 126

Capítulo 3.5.18 Secuencia Buscar Rol ............................................................................................. 127

Capítulo 3.5.19 Secuencia Modificar Rol ........................................................................................ 128

Capítulo 3.5.20 Secuencia Crear Rol .............................................................................................. 129

Capítulo 3.5.21 Secuencia Eliminar Rol ......................................................................................... 130

Capítulo 3.5.22 Secuencia Buscar Usuario ...................................................................................... 131

Capítulo 3.5.23 Secuencia Crear Usuario ....................................................................................... 132

Capítulo 3.5.24 Secuencia Modificar Usuario ................................................................................. 133

Capítulo 3.5.25 Secuencia Eliminar Usuario .................................................................................. 134

Capítulo 3.6 Especificación de Casos de uso (Trayectorias) ................................................................ 135

Capítulo 3.6.1 Registrarse ................................................................................................................ 135

Iniciar Sesión ..................................................................................................................................... 136

Capítulo 3.6.7 Gestión de Usuarios .................................................................................................. 137

Anexos

102

Capítulo 3.6.8 Gestión de Roles ....................................................................................................... 139

Capítulo 3.7 Diagrama de Interfaces Gráficas (Herencias y paquetes): ................................................ 141

Capítulo 3.8 Diseño de Interfaces ........................................................................................................ 142

Capítulo 3.8.1 NOMBRE: “INDEX-BIENVENIDA” .................................................................... 142

Capítulo 3.8.2 NOMBRE: “INDEX-INFO” ................................................................................... 144

Capítulo 3.8.3 NOMBRE: “INDEX-SESION” ............................................................................. 145

Capítulo 3.8.4 NOMBRE: “INDEX-ALUMNO” ......................................................................... 146

Capítulo 3.8.5 NOMBRE: “INDEX-BUSQUEDA” ..................................................................... 146

Capítulo 3.8.6 NOMBRE: “INDEX-CITAS” ................................................................................ 147

Capítulo 3.8.7 NOMBRE: “INDEX-ALERGIAS” ........................................................................ 148

Capítulo 3.8.8 NOMBRE: “INDEX-Consulta” ............................................................................. 148

Capítulo 3.8.25 NOMBRE: “ADMINISTRADOR-ELIMINA-ROL” .......................................... 150

Capítulo 3.8.26 NOMBRE: “ADMINISTRADOR-MODIFICAR-ROL” .................................. 151

Capitulo 4 Actualizaciones .................................................................................................................... 152

Capítulo 5 Pruebas del Sistema ............................................................................................................. 153

Capítulo 5.1 Pruebas de Aceptación ..................................................................................................... 153

Capítulo 5.1.1 Descripción de la Prueba .......................................................................................... 153

Capítulo 5.1.2 Guiones de Prueba .................................................................................................... 154

Anexos

103

Capítulo 1 – Problemática El Instituto Politécnico Nacional ofrece servicios de diferente índole para su comunidad, tanto estudiantes como docentes y personal de apoyo y asistencia a la educación, cada uno de ellos proporciona oportunidades para adquirir productos o solicitar herramientas que son necesarias para que la comunidad pueda desarrollar tareas y actividades tanto académicas como laborales. Servicios para Estudiantes y Docentes El organismo encargado de ofrecer y gestionar los servicios académicos para la comunidad IPN es la Secretaria de Extensión y apoyo, además de la Secretaria de Servicios Estudiantiles por medio de su Dirección de Servicios Estudiantiles. A continuación, se muestran los servicios ofrecidos a la comunidad de estudiantes del Instituto Politécnico Nacional: Centros de Apoyo para Estudiantes (CAE) y Centros de Apoyo Polifuncional (CAP)

o Ofrecen servicios de fotocopiado, impresiones a color y Blanco/Negro a precios por debajo del mercado.

o Venta de diversos artículos escolares, libros, ropa deportiva y artículos de identidad politécnica. o Servicios gratuitos de:

• Equipo de Cómputo. • Quemador de CD's. • Diademas con audífonos y micrófonos para computadoras. • Máquinas de Escribir. • Restiradores. • Equipo de Dibujo. • Salas de Trabajo Grupal. • Mesas de Trabajo. • Enmicado. • Guillotina. • Engargolado.

· Atención a la salud

o Odontología • Diagnóstico de salud bucal. • Tratamiento. • Seguimiento al tratamiento de los padecimientos bucales. • Orientación sobre técnicas de higiene bucal, importancia cuidado de la salud

bucal y del autoexamen. o Medicina Preventiva

• Atención médica de primer contacto. • Referencia de padecimientos específicos a su respectiva especialidad. • Canalización a un Servicio Médico de segundo o tercer nivel cuando el

diagnóstico del estado de salud del paciente lo requiera. • Orientación y asesoría médica. • Promoción de programas de educación para la salud

o Nutriología • Evaluación de tu estado nutrición. • Elaboración de un plan alimentario personalizado. • Seguimiento y asesoría nutricional. • Recomendaciones para el acondicionamiento físico. • Realizar la canalización a un Servicio Médico de segundo o tercer nivel cuando

el diagnóstico de salud lo requiera. o Optometría

• Diagnóstico de salud visual. • Tratamiento y control de enfermedades visuales. • Seguimiento del estado de salud visual.

Anexos

104

• Venta de lentes a precios accesibles con los mejores diseños y la más alta calidad. ·

Servicio de biblioteca Con el propósito de incentivar la investigación y la adquisición de medios físicos de información se creó una red de bibliotecas dentro del Instituto Politécnico Nacional a las cuales los estudiantes tienen acceso con su respectiva identificación que los acredita como miembros de la comunidad politécnica. Los servicios que ofrece la biblioteca son los siguientes:

• Colecciones de estantería abierta: Áreas donde los usuarios buscan directamente (según su clasificación), libros y documentos de su interés.

• Colecciones cerradas: Material que se solicita a un encargado específicamente del área para su consulta en sala. o Hemeroteca: Publicaciones periódicas o seriadas, tales como: periódicos y revistas de

circulación nacional e internacional. o Mapoteca: Se cuenta con más de 8,000 mapas y cerca de 6,700 volúmenes en

publicaciones impresas proporcionadas por la Biblioteca Nacional de Ciencia y Tecnología.

o Mediateca: Préstamo de material audiovisual de arte, cultura, ciencia y tecnología, integrado por materiales no impresos.

o Tesis: Se cuenta con más de 19,500 títulos impresos y en formato CD, además de 13,600 que están actualmente en el repositorio digital.

• Préstamo de acervo • Préstamo de equipo de cómputo • Diseminación de información: En la Biblioteca Nacional de Ciencia y Tecnología se

proporcionan asesorías, talleres y cursos para que sus usuarios aprendan a realizar búsquedas de manera fácil en todos los recursos electrónicos con los que cuenta el Instituto.

• Salas de lectura, salas de trabajo colaborativo, salas con software especializado, salas de internet.

• Servicios de fotocopiado, impresión y ploteo. • Venta de artículos escolares y de identidad politécnica.

Servicio de Laboratorios Cada unidad académica del instituto posee aulas especializadas para desarrollar prácticas e investigaciones enfocadas en una determinada área de conocimiento. Estas aulas poseen la tecnología y herramientas necesarias a las cuales se tiene acceso en horarios establecidos por la unidad académica, de esta manera tanto alumnos como profesores pueden complementar sus prácticas en horarios fuera de clase lo que les brinda la oportunidad de realizar trabajos de alta calidad. Servicios deportivos y culturales Con la finalidad de complementar el crecimiento académico de los estudiantes, las diversas unidades académicas ofrecen actividades extracurriculares que pretenden ofrecer un ambiente de distracción y entretenimiento para los estudiantes. Fomentan el crecimiento de nuevas destrezas y habilidades adicionales que en el ámbito laboral y social les serán de utilidad. Servicios de la Unidad de Informática (UDI) El objetivo de la UDI es supervisar el cumplimiento y la aplicación de las normas, lineamientos y procedimientos establecidos relativos al cómputo y comunicaciones, así como promover el desarrollo de la cultura informática en la escuela, centro, unidad o área correspondiente.

• Préstamo de equipo de cómputo para toda la comunidad de la unidad académica. Impresiones a un costo accesible.

Anexos

105

• Trámite de correo institucional para todos los usuarios, mediante solicitud, previa identificación que los acredite como miembros de la comunidad.

• Soporte técnico a los usuarios del equipo de cómputo. • Administración, control de acceso y mantenimiento de equipo Informático en las Aulas de

Cómputo. Servicios de la Unidad de Tecnología Educativa y Campus Virtual (UTEyCV) Se cuenta con servicios virtualizados de educación como cursos en línea y servicios de educación continua. Problemática Las unidades de atención médica del Instituto Politécnico Nacional requieren la información médica vital de la comunidad que desea realizar una consulta, como puede ser sus datos personales, tipo sanguíneo, vacunas y alergias. Sin embargo, una persona puede desconocer esa información al momento de asistir a la consulta ocasionando retrasos en la atención médica o cuando se solicita un servicio dentro del instituto. Por otro lado, los servicios que ofrece el IPN se encuentran en diferentes unidades académicas y edificios ubicados en diferentes sedes, por lo cual en ocasiones especiales se les solicita a las personas que solicitan los servicios adquirir una credencial específica para cada uno de los servicios, lo cual representa un gasto innecesario de tiempo y recursos para el instituto. Para la comunidad politécnica le sería de gran utilidad contar con una forma de identificación que al mismo tiempo le sirva como medio para almacenar su información personal y médica vital para que al momento de solicitar uno de los tantos servicios que ofrece el Instituto Politécnico Nacional pueda obtenerlo de una manera ágil y sin retrasos innecesarios. Al mismo tiempo se podría tener acceso a la información del solicitante desde cualquier unidad de atención.

Carnet de Servicios

Politecnicos

Servicio Estudiantil

Servicio Medico

Servicio N ..

Servicio Bibliotecario

Anexos

106

Capítulo 2 – Propuesta de Solución Se propone desarrollar un sistema que permita a los miembros de la comunidad del Instituto Politécnico Nacional tener un acceso ágil y cómodo a los servicios que ofrece la institución, así como medio de identificación que los acredite como miembros de la comunidad (estudiantes, docentes o empleados). Así mismo el medio además de identificarlos contendrá la información personal y médica vital del solicitante con la finalidad de que los encargados de brindar un servicio dentro del instituto puedan ofrecerlo de manera sencilla y además tener un historial de las actividades del solicitante. Se propone que se implemente el servicio médico institucional como primer servicio para probar esta propuesta de arquitectura. Pero la arquitectura se definiría para poder implementar cualquier servicio existente o dará la pauta para crear servicios basándose en estándares. El servicio médico Institucional se apoya en los siguientes aspectos:

• Atención médica de primer contacto. • Referencia de padecimientos específicos a su respectiva especialidad. • Canalización a un Servicio Médico de segundo o tercer nivel cuando el

diagnóstico del estado de salud del paciente lo requiera. • Orientación y asesoría médica. • Promoción de programas de educación para la salud

Para el caso de los servicios médicos de optometría, nutriología, odontología y medicina preventiva usarán la información almacenada dentro del medio de identificación para realizar un diagnóstico médico correcto tomando en cuenta datos como alergias, tipo sanguíneo, historial de vacunas e historial de consultas. El medio de identificación y que contiene la información, será conocido como Carnet de Servicios Politécnicos y será una credencial que contendrá la información almacenada en un tag NFC. Cada una de las unidades de atención dentro del instituto donde se ofrecen los servicios para la comunidad politécnica podrá atender al solicitante pidiendo su carnet para poder obtener su información e identificarlo como miembro del IPN, esta operación se realizará a través de un lector NFC que se encontrará conectado a una aplicación de escritorio o inalambrica donde se visualizará la información necesaria para poder acceder al servicio. Se tendrá también un servidor en donde se almacenará el historial de todas los servicios que ha solicitado una persona y el historial necesario para casos específicos, siendo por ejemplo el historial de consultas médicas para el caso de cualquier área médica ó el historial de préstamos y adeudos para el servicio de biblioteca. El sistema contará también con un portal web en donde los usuarios de la comunidad podrán acceder con un nombre de usuario y contraseña en el cual tendrán la oportunidad de visualizar el historial de sus solicitudes y su información general.

Anexos

107

Capítulo 1.1 Diagrama a bloques de Propuesta de solución

La arquitectura se conforma de seis módulos básicos que permiten crear un núcleo de operación de la misma:

• Módulo de Registro: Permitirá generar el registro de los usuarios del sistema.

• Módulo de Carnet de Servicios: Este módulo se encargara de administrar el acceso e identificación de un perfil para la asignación de los servicios correspondientes.

• Módulo de Asignación de Perfiles: En él se asigna el perfil que corresponde al usuario

de acuerdo a los servicios que requiere y tiene autorizados.

• Módulo de Servicios: Este Módulo se encargara de realizar la conexión con los servicios que se tengan disponibles.

• Módulo de Interacción: El módulo de interacción provee la forma de comunicación entre

servicios y sistemas.

• Módulo de Reportes y estadísticas: Todo sistema debe contar con una forma de monitoreo del estado del mismo.

De la misma forma se cuenta con una arquitectura para la interacción entre la arquitectura propuesta, los sistemas institucionales y los dispositivos de Tag que se generan como carnet e servicios politécnicos.

Ilustración 1"Diagrama de Interacción"

Una vez autentificado el usuario por medio del Tag Inteligente, éste podrá realizar operaciones con nuestro sistema de acuerdo al perfil que tenga, utilizando la interfaz gráfica provista por los sistemas y servicios implementados. Además, dentro de la aplicación web se permitirá la administración completa del mismo. Por otro lado, en dado caso de que el usuario utilice una aplicación de terceros que tenga acceso al servicio web, este tendrá que dar consentimiento, de modo que nuestro servidor permita el acceso a la

Anexos

108

información. Para ello se propone el modelo de autentificación OAuth 2; el cual es utilizado por la industria por empresas de renombre tales como GitHub, Google, Twitter [19] [20] [21]. El flujo de autenticación de OAuth se describe en el siguiente diagrama de secuencia, en donde el Servidor es equivalente a la Entidad Certificadora del diagrama de arquitectura.

Ilustración 2 “Funcionamiento de Oauth”

Una vez realizado dicho flujo, la aplicación de un tercero podrá acceder a la API, la cual es un conjunto de peticiones al servidor y sus respectivas respuestas. Será tarea del integrador de servicios procesarlas y manipularlas (ejemplo: agregar una interfaz gráfica, realizar operaciones sobre los datos otorgados por el servidor). Cabe destacar que a pesar de tener cierta funcionalidad, el API no tendrá ciertas equivalencias con la aplicación web, especialmente en el área de administración de usuarios, debido a que este tipo de peticiones presentan un riesgo de seguridad para los datos de los mismos. Se destaca que el sistema estará disponible a través de un Web Service así como aplicación Web, en el cual es fundamental la integridad de información del usuario permitiendo un seguimiento óptimo de sus avances. Esto además propicia la facilidad de integrarse con otros sistemas [22] debido a que la comunicación entre el Web Service y otros sistemas es sencilla y basada en estándares como Django, HTTP, etc. [23]

Además, se destaca la aplicación web que se utilizará para realizar la comunicación con el servicio web utiliza podrá cumplir con mejores prácticas del diseño web como lo son el Responsive Web Design y el Templating [24] El sistema principal se desarrollará con tecnologías diseñadas para la Web como lo son el framework Angular JS, HTML5, Javascript, Node JS, Progres y peticiones HTTP. Esto debido a que soportan los paradigmas y patrones de diseño siguientes:

• MVC • Diseño web responsivo • Arquitectura REST y ruteo para aplicaciones REST

Anexos

109

Además se cuenta con la ventaja de que las tecnologías propuestas son abiertas, utilizando licencia MIT para el caso de Python, JQuery, Twitter Angular; la cual es amigable con los desarrollos abiertos y comerciales. [25] [26] [27]

Resumen de Tecnologías: Frontend

• Angular JS • Java script • Node JS • Bower • Gulp

Backend • Python • Django • Docker

Desktop • C# • C • .NET • arduino

HW

• NFC

Finalmente, para el uso de los servidores se cuenta con licencia Apache, que permite el uso comercial, siempre y cuando se incluya una copia de la licencia y se dirija al sitio de Apache en alguna sección de la aplicación que haga uso de dicha licencia. [28]

Capítulo 1.2 Tecnologías y técnicas a Utilizar

Capítulo 1.2.1 Patrón de Diseño Modelo-Vista-Controlador Las aplicaciones web tienden a ser sujetos a muchos cambios y requieren del enlace entre los datos, la lógica de negocio y la presentación que se le da al usuario. Debido a que las interfaces tienden a cambiar más frecuentemente que la lógica de negocio o las representaciones de datos así como para mantener la modularidad no se recomienda mezclarlas. Una solución es el patrón de diseño modelo-vista-controlador. Como su nombre lo dice, consta de tres partes: [29]

• Modelo: Maneja el comportamiento de los datos dentro del contexto de la aplicación y responde a instrucciones de cambio de estado.

• Vista: Maneja la presentación de la información, • Controlador: Interpreta las entradas de datos del usuario y notifica al

modelo de dichos cambios. De manera gráfica, la relación es la siguiente:

Anexos

110

Ilustración 3 ”Modelo Vista Controlador”

Capítulo 3.2.2 Frameworks para la Web Un framework para la web es un marco de trabajo que está diseñado con el fin de soportar el desarrollo de sitios web dinámicos, aplicaciones web, servicios y recursos web. Estos buscan ayudar con las tareas más comunes como lo son el manejo de plantillas, manejo de sesiones y bases de datos. [30]

Capítulo 1.2.3 Modelo Mapeo Objeto-Relacional Es una técnica de programación que convierte datos entre tipos incompatibles de sistemas, principalmente entre programas orientados a objetos y algún sistema no orientado a objetos (como lo son las bases de datos relacionales). Esta técnica crea una base de datos de objetos virtuales, de modo que los lenguajes orientados a objetos puedan hacer uso de los datos de los sistemas no orientados a objetos. [31]

Capítulo 1.2.4 Vista Diseño Responsivo El diseño web responsivo logra adaptar las interfaces a distintos dispositivos utilizando una misma vista utilizando modelos lógicos de tablas (filas y columnas) para el desarrollo. Internamente se utiliza un concepto llamado media queries que permiten determinar el tamaño de la pantalla y presentar la vista de acuerdo a esta. La ventaja principal de este paradigma de diseño es el hecho de que se puede realizar el diseño de interfaces para abarcar distintos dispositivos sin tener que cambiar el código de la vista de manera sustancial. [32] Reutilización de vistas: Sistemas de Templates (Plantillas)

Un sistema de Templates web utiliza plantillas para formar páginas web terminadas, utilizando alguna fuente de datos para personalizar la presentación o presentar contenidos muy grandes de información. Es una herramienta presente en muchos frameworks que permite la reutilización de código y facilita el trabajo de producir páginas web dinámicas que cambian de acuerdo al estado o un gran volumen de páginas web con apariencias similares. Ciertos sistemas de templates soportan características como herencia de vistas e interoperabilidad entre lenguajes, permitiendo mayor flexibilidad en su uso.

Anexos

111

Capítulo 1.2.5 Controlador Servicios Web Un servicio web son aplicaciones cliente-servidor que se comunican a través de la Web utilizando el protocolo HTTP. Como lo menciona el World Wide Web Consortium, los servicios web proveen métodos estándares de comunicación entre aplicaciones que se encuentran desarrolladas en distintas plataformas. Se caracterizan por su extensibilidad e interoperabilidad dado a su utilización de medios de comunicación estándares y a su acoplamiento débil. [33]

Anexos

112

Capítulo 1.2.6 Arquitectura RESTful La arquitectura REST es una arquitectura en la cual una representación de un recurso (cualquier objeto de interés) se envía. Esta representación pone la aplicación del cliente en un estado que puede cambiar (transferencia de estado) con cada recurso. A pesar de no ser un estándar, esta arquitectura utiliza elementos estándares como lo son:

• HTTP • URI • XML/JSON/GIF/JPEG/etc.

Tipos MIME Una arquitectura REST utiliza URIs lógicas para poder atender las peticiones y así poder regresar los distintos recursos, por lo cual debe especificar el formato de las peticiones y el regreso. [34] Módulo de Lector de Credenciales Inteligentes

El lector de credenciales permite obtener o modificar la información almacenada en la credencial para el uso de los servicios que el instituto ofrece a la comunidad politécnica. El lector se compone de 2 partes principales: Una aplicación que se instala en el equipo donde se realizarán las operaciones con la credencial, esta aplicación incluye los drivers y los módulos necesarios para establecer la comunicación con el lector. Y un lector de credenciales el cual se conecta a través de un cable USB a Mini USB tipo B.

El lector es un bloque de plástico el cual dispone de un conector USB para alimentarlo y comunicarlo con el equipo de cómputo. El lector cuenta con 5 LEDs con los cuales se puede conocer el estado actual del dispositivo y un área de lectura para colocar las credenciales inteligentes como se muestra en el siguiente diagrama:

Ilustración 5 “Lector del Carnet”

En este diagrama apreciamos el lado frontal y lateral izquierdo del lector de credenciales, a continuación se describe la función de cada uno de los LEDs.

• LED de Encendido.- Indica si el Lector de Credenciales esta alimentado correctamente. • LED de Configuración.- Este LED cumple 2 funciones, si el Lector está operando

correctamente este LED se utiliza en caso de que se haya accedido al modo de configuración del lector NFC y permanecerá encendido hasta que se acceda al modo de operación normal. En caso de que al conectar el Lector NFC no se pueda inicializar el microcontrolador de

Anexos

113

comunicación con las credenciales, este LED encenderá de forma intermitente para indicar el fallo y no se podrá usar el Lector hasta ser revisado.

• LED de NFC.- Este LED encenderá a los pocos segundos de haber conectado el Lector a un equipo de cómputo para indicar que se ha inicializado el microcontrolador de comunicación con las credenciales de forma correcta, y permanecerá encendido durante toda la operación del lector.

• LED de Acción.- El LED de acción indica que existe una operación pendiente por ser realizada en el Lector, se utiliza comúnmente para indicar que se espera se coloque una credencial en el Lector para realizar la Acción previamente seleccionada.

• LED de Confirmación.- Este LED parpadea una vez que se ha realizado la acción solicitada y se apaga junto con el LED de acción, en caso de que no parpadee y se apague el LED de acción se entiende que hubo un problema en la acción solicitada. En algunos casos como en la lectura de la información de la tarjeta puede permanecer encendido por algunos segundos antes de terminar la operación.

El lector funciona generando un campo electromagnético que permite energizar e inicializar la comunicación con la credencial inteligente mediante el mismo campo, utilizando la tecnología de comunicación de campo cercano o NFC (Near Field Communication) por sus siglas en inglés.

Para poder comunicar el Lector con el equipo de cómputo y mostrar la información contenida en la credencial o guardarla en el servidor web, es necesario instalar una aplicación de escritorio desarrollada para detectar y establecer la comunicación entre el lector y el equipo. Esta aplicación es necesaria por la forma en la que se comunica el lector con el equipo de cómputo.

La aplicación permite entre otras cosas:

• Visualizar la información básica del usuario. • Detectar 1 o más lectores de tarjetas conectados al equipo. • Activar una credencial limpia para su uso en el sistema. • Desactivar una credencial (ya no se puede usar en el sistema). • Borrar el contenido de una credencial. • Modificar el contenido de una credencial.

Arquitectura del Lector de credenciales

La arquitectura del lector de credenciales muestra cómo se interconectan los módulos internos del lector como de la aplicación de comunicación para establecer y garantizar seguridad en la lectura y escritura de la información en la credencial inteligente.

Anexos

114

Ilustración 4 ”Lector de Credenciales Inteligentes”

Lector de credenciales:

El lector de credenciales se compone de 3 módulos internamente:

• Módulo de comunicación: el módulo de comunicación se compone de un FTDI el cual monta un puerto serial virtual a través de la conexión USB y se encarga de comunicar el módulo de lectura y escritura con la aplicación de comunicación instalada en el equipo de cómputo.

• Módulo de control: En este módulo se validan y manejan todas las operaciones a realizar en el lector de credenciales y en la credencial inteligente: Este módulo contiene la llave de escritura y lectura para las credenciales, al ser esta llave diferente a la llave universal establecida en el estándar ISO 14443 A para tarjetas inteligentes, permite que las credenciales no puedan ser identificadas por otro tipo de lector, teléfono inteligente o aplicación que no conozca la llave de la credencial, incrementando así el nivel de seguridad de la credencial inteligente.

• Transmisor y Receptor: Este módulo se conforma de un micro controlador PN532 y una antena NFC para escribir y leer la información almacenada en la tarjeta inteligente, es importante mencionar que este módulo solo se encarga de escribir y leer de la credencial entregando un flujo de bytes puro el cual se transmite al módulo de control utilizando el protocolo de comunicación SPI, donde el módulo de control es el encargado de validar, descifrar, y gestionar la información.

En el equipo de cómputo donde se realizara la lectura se instala la aplicación de comunicación, internamente se compone en forma general de 2 módulos:

• Módulo de Comunicación: El módulo de comunicación se encarga de comunicarse con el Servidor Web donde se encuentra la aplicación mediante el uso de servicios REST, así como de obtener o preparar la trama de información que se almacena en la credencial inteligente, este módulo tiene la capacidad de enviar la información a el explorador web en donde se consulta la información o desplegarla en una interfaz interna en caso de que el equipo no cuente con conexión a internet.

• Módulo de Seguridad y Comunicación.- El módulo de seguridad se encarga de la comunicación se encarga de cifrar y transmitir o recibir y descifrar la información almacenada

Anexos

115

en la credencial inteligente. Esto garantiza que la información almacenada sea ilegible para los usuarios.

Credenciales Inteligentes

Las credenciales inteligentes que se utilizan en el sistema, son credenciales NFC compartibles con el estándar ISO 14443 A para credenciales de identificación – tarjetas con circuitos integrados sin contacto – tarjetas de proximidad. Estas credenciales se comunican a través de un campo electromagnético a una frecuencia definida por el estándar de 13.56 MHz.

Disponen de una memoria interna de 1KB de la cual solo está disponible para el usuario 768 KB dando que el resto se utiliza para almacenar la información relacionada con el ID único de la credencial, la compañía que fabrico la credencial, los bytes de acceso y las llaves de control para cada uno de los sectores disponibles. Estas credenciales (en su mayoría) son imprimibles permitiendo utilizar el una impresora de credenciales estándar para imprimir la información de la persona asociada a la credencial.

Existen credenciales con una mayor capacidad de información hasta de 64KB pero a un costo mucho más elevado. A continuación se muestra parte de la estructura interna (mapa de bytes) de una credencial inteligente que no contiene información.

Seguridad en la aplicación

La seguridad en la información almacenada en la tarjeta inteligente es algo de suma prioridad dado que se almacena información del usuario asociado con la credencial. Esta credencial es visualmente idéntica a la credencial estándar del IPN. Para garantizar la integridad de la información se manejan 3 niveles de seguridad en la información almacenada.

Primeramente la información se mapea en un arreglo de bytes de tamaño predefinido en el cual se va distribuyendo los diferentes campos de la información a nivel de byte o en algunos casos como, Alergias, Enfermedades Crónico Degenerativas, etc. a nivel de bit.

Posteriormente se cifra el arreglo de bytes con un algoritmo AES obteniendo un nuevo arreglo de bytes del mismo tamaño, este algoritmo fue seleccionado dado que se dispone de un tamaño muy limitado para almacenar información dentro de la credencial inteligente.

Este arreglo de bytes cifrados es el que se envía al Lector de credenciales en donde se almacena en la credencial inteligente asegurándonos que esta sea 9válida, verificando la llave de almacenamiento definida para las credenciales, esta llave al ser diferente para nuestras credenciales en comparación

Anexos

116

con otros dispositivos NFC comerciales permite que no sea obtenible para otros lectores. Evitando que sea adquirida a través de otros dispositivos que no sean parte del sistema.

Si se quiere conocer más a detalle los flujos de información de las 2 aplicaciones consultar las secciones correspondientes.

Anexos

117

Capítulo 2 Análisis Una vez desarrollada la propuesta de solución se procede a evaluar los requerimientos del sistema y a modelar el mismo.

Capítulo 2.1 Requerimientos del Sistema

Capítulo 2.1.1 Requerimientos Funcionales RF 1. El sistema contará con una página de inicio, en la cual se encontrará el “inicio de sesión” el cual contendrá un formulario para llenar con nombre de usuario y contraseña. RF2 .Para dicho sistema es necesario el control y manejos de tipos de usuario entre los que se incluirán “Docente” “Alumno” “Administrador”. RF 3.El alumno únicamente contara con un número definido de servicios RF 4. El docente únicamente contara con un número definido de servicios RF 5. El administrador únicamente contara con un número definido de servicios. RF 6.Dichos servicios estarán interconectados con los servicios institucionales ofrecidos por el IPN. RF 7.Debe ser persistente mientras la sesión se mantenga activa. RF 8.-El alumno contará con permisos de consulta RF 9. Modificación de su información personal así como su contraseña RF 10. Mediante el llenado y uso de formularios RF 11. El docente podrá Modificar su información personal, todo esto se hará mediante el uso de formularios RF 12.El administrador podrá gestionar (altas, bajas cambios y consultas) de usuarios RF 13. El administrador podrá gestionar (altas, bajas cambios y consultas) de servicios RF 14.El administrador podrá Además de poder consultar estadísticas generales de los resultados. Obtenidos por los diversos usuarios RF 15. El administrador podrá consultar la generación de reportes de dichas estadísticas. RF 16. Generar gráficos de las mismas estadísticas. RF 17. El sistema a realizar será un Servicio Web que presente una interfaz gráfica

Anexos

118

Capítulo 2.1.2 Requerimientos No Funcionales RNF 1. La información personal deberá ser segura. RNF 2. Se debe acceder por medio de un token o dispositivo a Servicios institucionales existentes RNF 3. Todas las interfaces deberán atender la sencillez RNF 4. El sistema debe ser usable RNF 5.El sistema debe ser atractivo RNF 6.El sistema deberá poder ser visualizado en diversos Navegadores y Dispositivos. RNF 7. El sistema deberá ser desarrollado para qué soporte el ingreso simultáneo de un gran número de personas debido a que al ser un sistema web no se puede tener un control de acceso. RNF 8. Todos los resultados desplegados deben ser claros y amigables para facilitar la comprensión de los mismos por parte de los usuarios. RNF 9. La interfaz debe ser comprensible, para que no se requiera de una capacitación previa del usuario para poder operarla.

Anexos

119

Capítulo 3 Diseño El siguiente diseño abarca todo lo relacionado directamente a la aplicación web propuesto y no al servicio para el uso por terceros.

Capítulo 3.1 Diagramas de Arquitectura

Ilustración 5”Diagrama de arquitectura del Sistema”

Para el diagrama anterior, se consideran las siguientes definiciones, en donde se especifican las operaciones que podrá realizar el sistema:

• Cliente: Se entenderá por cliente cualquier dispositivo que pueda ingresar al sistema a través de un navegador web. La experiencia de usuario será mejorada para computadoras de escritorio.

• Nube: Se entenderá por nube al servicio virtual que permite tener acceso a servicios usando como herramienta base Internet, y que estos servicios y/o información siempre estén accesibles sin necesidad de descargar o almacenar en algún otro sitio por parte del cliente.

• Identificación y autenticación: Se entenderá por identificación y autenticación aquellos elementos encargados de verificar y asignar al usuario su cuenta correspondiente, así como que al tener acceso a alguna parte del sistema la persona sea quien dice ser comprobándolo a través de las credenciales adecuadas.

• Gestión de Usuarios: Se entenderá por gestión de usuarios al módulo encargado de dar alta

Anexos

120

• Repositorio de Usuarios y Perfiles: Contiene la información de cada usuario relativa al acceso al sistema, sus permisos dentro de él así como los resultados de las evaluaciones que se realicen en el ámbito del sistema.

• Repositorio de Conocimiento: Contiene información que van generado los diferentes sistemas y sirve para poder definir acciones de acuerdo a parámetros.

Capítulo 3.2 Diagramas de Casos de uso A continuación se mostrarán los diversos casos de uso que conforman el sistema el cual pude ser accedido por 3 diferentes tipos de usuario

• Alumno • Docente • Administrador

Capítulo 3.2.1 Diagramas de Casos de uso Autenticación El presente Diagrama considera a dos diferentes tipos de usuario los cuales son el no registrado y el registrado del cual heredan los tres actores mencionados anteriormente.

Ilustración 6"Caso de Uso de autenticación”

El caso de uso general del sistema se muestra a continuación:

Anexos

121

Ilustración 7 "Caso de Uso General”

Diagrama de secuencia gestionar expediente: En este se realiza la parte de autentificar, la cual se mostró anteriormente, una vez ya ingresado al sistema, este muestra el módulo administrar, en el cual al ser médico se permite mostrar el módulo de gestionar expedientes, en donde se crearan, editaran o eliminarán los expedientes clínicos de los pacientes que se encuentran en el sistema.

Anexos

122

Ilustración 8"Secuencia de expediente”

Diagrama de secuencia administrar médico: En este se realiza la parte de autentificar, la cual se mostró anteriormente, una vez ya ingresado al sistema, este muestra el módulo administrar, en el cual se permite la edición de los datos y/o mediciones, las cuales serán validadas y actualizadas en la base de datos.

Ilustración 9"Secuencia de Administrar Medico”

Capítulo 3.3 Diagramas de Base de Datos Modelo Relacional A continuación se mostrarán los diversos elementos que conformarán nuestro sistema, dichos elementos son tanto los campos como las tablas y sus relaciones.

Anexos

123

Ilustración 10 “Modelo Relacional”

Anexos

124

Capítulo 3.4 Diagrama de Clases Aquí se presenta el Diagrama de clases que compone el sistema propuesto, cabe destacar que para su mayor comprensión y entendimiento posteriormente se desglosará en sub diagramas basados en este primer diagrama

Capítulo 3.4.1 Diagramas de Clases (Relaciones entre Clases) A continuación se presenta el diagrama que permite visualizar las relaciones entre las clases que conforman el controlador de nuestro sistema.

Ilustración 11"Diagrama de Relación entre clases"

Capítulo 3.4.2 Diagramas de Clases Modulo de Carnet En el presente diagrama muestra los métodos principales que conforman nuestro sistema, bajo el entendido de que se trata de únicamente la sección de controlador A continuación se presenta el diagrama de clases del módulo de carnet electrónico:

Anexos

125

Ilustración 12 "Diagrama de Clases”

Anexos

126

Capítulo 3.5 Diagramas de Secuencia: Los diagramas de secuencia tienen el objetivo de para explicar el comportamiento del sistema y la comunicación entre los diferentes objetos que componen al mismo. Las siguientes secuencias son en general para cualquier tipo de usuario registrado en el sistema.

Capítulo 3.5.1 Secuencia Log In

Ilustración 1 “Secuencia de Log In”

Capítulo 3.5.2 Secuencia Log Out

Ilustración 13“Secuencia de Log Out”

Anexos

127

Alumno: A continuación se mostrarán las diversas secuencias que llevará a cabo el sistema para atender todas las funcionalidades que tiene permitidas el alumno.

Capítulo 3.5.18 Secuencia Buscar Rol El presente diagrama es el encargado de mostrar las secuencias necesarias para buscar algún rol por parte del administrador.

Ilustración 14 “Secuencia Buscar Rol”

Anexos

128

Capítulo 3.5.19 Secuencia Modificar Rol El presente diagrama es el encargado de mostrar las secuencias necesarias para modificar algún rol por parte del administrador.

Ilustración 15 “Secuencia Modificar Rol”

Anexos

129

Capítulo 3.5.20 Secuencia Crear Rol El presente diagrama es el encargado de mostrar las secuencias necesarias para crear algún rol por parte del administrador.

Ilustración 16 “Secuencia crear Rol”

Anexos

130

Capítulo 3.5.21 Secuencia Eliminar Rol El presente diagrama es el encargado de mostrar las secuencias necesarias para eliminar algún rol por parte del administrador.

Ilustración 17 “Secuencia Borrar Rol”

Anexos

131

Capítulo 3.5.22 Secuencia Buscar Usuario El presente diagrama es el encargado de mostrar las secuencias necesarias para buscar algún usuario por parte del administrador.

Ilustración 18"Secuencia Buscar Usuario"

Anexos

132

Capítulo 3.5.23 Secuencia Crear Usuario El presente diagrama es el encargado de mostrar las secuencias necesarias para crear algún usuario por parte del administrador.

Ilustracion 19 "Secuencia Crear Usuario"

Anexos

133

Capítulo 3.5.24 Secuencia Modificar Usuario El presente diagrama es el encargado de mostrar las secuencias necesarias para modificar algún usuario por parte del administrador.

Ilustración 20 "Secuencia Modificar Usuario"

Anexos

134

Capítulo 3.5.25 Secuencia Eliminar Usuario El presente diagrama es el encargado de mostrar las secuencias necesarias para eliminar algún usuario por parte del administrador.

Ilustración21 "Secuencia Eliminar Usuario"

Anexos

135

Capítulo 3.6 Especificación de Casos de uso (Trayectorias) Se hace uso del análisis de Trayectorias para poder observar los diferentes comportamientos posibles por parte de los diferentes tipos de usuario en el sistema.

Capítulo 3.6.1 Registrarse Tabla 1 “Trayectoria Registrarse”

Actor Todos Propósito • Acceder al Sistema para realizar las

acciones deseadas Entradas • Salidas • Nombre de Usuario

Precondiciones • El usuario no debe tener una cuenta Postcondiciones • El usuario poseerá una cuenta

asignada a él Trayectoria Principal 1. S: Despliega la Interfaz Registro de Usuario 2. A: Introduce la información solicitada [A] 3. A: Hace clic en el botón Registrar 4. S: Valida la información 5. S: Crea el usuario con la información especificada 6. S: Iniciar sesión con la información del usuario recién creado --- fin del caso de uso Trayectorias Alternativas Los datos introducidos no son válidos [A] 1. S: Marcar los campos en los que la información es errónea. 2. S: Desplegar ERR: Datos Inválidos 3. A: Introducir la información solicitada 4. S: Ir al paso 2 de la trayectoria principal --- fin de la trayectoria alternativa

Anexos

136

Iniciar Sesión Tabla 2 "Trayectoria Inicia Sesión"

Actor Todos Propósito • Acceder al Sistema para realizar las

acciones deseadas Entradas • Nombre de Usuario

• Password Salidas • Token

Precondiciones • El usuario no debe tener una sección activa

Postcondiciones • El usuario accederá al sistema a su respectiva sección

Trayectoria Principal 1. S: Despliega la Interfaz Inicio de Sesión 2. A: Introduce la información solicitada [A] 3. A: Hace clic en el botón Iniciar Sesión 4. S: Valida la información. 5. S: Comprueba la información con la base de datos. 6. S: Otorga acceso al sistema con la información especificada 7. S: Despliega la interfaz Menú Principal --- fin de la trayectoria principal Trayectorias Alternativas Los datos introducidos no son válidos [A] 1. S: Marcar los campos en los que la información es errónea 2. S: Desplegar ERR: Datos Inválidos 3. A: Introducir la información solicitada 4. S: Ir al paso 3 de la trayectoria principal --- fin de la trayectoria alternativa La información no coincide [B] 1. S: Despliega ERR: La información no coincide 2. S: Ir al paso 2 de la trayectoria principal --- fin de la trayectoria alternativa

Anexos

137

Capítulo 3.6.7 Gestión de Usuarios Actor Administrador

Propósito • Gestionar los Usuarios Entradas • Depende de la acción

• Alta( Usuario, contraseña, confirmación, rol de usuario, nombre, apellido paterno, apellido materno, correo electrónico, Fecha Nacimiento, institución)

• Baja(identificador, nombre) • Cambios(Usuario, contraseña, confirmación, rol de

usuario, nombre, apellido paterno, apellido materno, correo electrónico, Fecha Nacimiento, institución)

• Baja(identificador, nombre) • Consultas(id, nombre, apellido paterno , apellido

materno) Salidas • Mensaje de confirmación

• En el caso de consulta (Usuario, contraseña, confirmación, rol de usuario, nombre, apellido paterno, apellido materno, correo electrónico, Fecha Nacimiento, institución)

• Baja(identificador, nombre) Precondiciones • El usuario debe tener una sección activa. Postcondiciones • Se ve efectuado el cambios en la Base de Datos

• En caso de Consulta se desplegara la información del usuario buscado.

Trayectoria Principal 7. S: Despliega la interfaz de Usuarios 8. A: Selecciona la operación a realizar [a|b|c|d|e] --- fin del caso de uso Puntos de Extensión 2a. Alta 22. S: Despliega la interfaz IM1.4.4 en blanco. 23. A: Introduce la información solicitada. [A|B] 24. A: Hace clic en el botón Guardar Cambios. 25. S: Valida la información ingresada. 26. S: Guarda la información ingresada. 27. S: Despliega MSG: Alta realizada correctamente. 28. S: Vuelve al paso 2 de la trayectoria principal. --- fin de la trayectoria alternativa 2b. Baja 19. A: Hace clic en el botón Eliminar 20. S: Despliega WAR: Confirmar Operación 21. A: Confirma la operación 22. S: Guarda los cambios realizados 23. S: Despliega MSG: Baja realizada correctamente 24. S: Vuelve al paso 2 de la trayectoria principal. --- fin de la trayectoria alternativa 2c. Cambio 28. S: Despliega la interfaz Datos de Usuario con los datos correspondientes 29. A: Modifica la información solicitada [A|B] 30. A: Hace clic en el botón Guardar Cambios 31. S: Despliega WAR: Confirmar Cambios 32. A: Confirma la operación

Anexos

138

33. S: Valida la información ingresada 34. S: Guarda los cambios 35. S: Despliega MSG: Cambio realizado correctamente 36. S: Vuelve al paso 2 de la trayectoria principal. --- fin de la trayectoria alternativa 2d. Consulta 10. S: Despliega la interfaz Consultar Usuario 11. A: Revisa la información mostrada [b|c] 12. S: Vuelve al paso 2 de la trayectoria principal. --- fin de la trayectoria alternativa 2e. Búsqueda 19. S: Despliega la interfaz Búsqueda de Usuario 20. A: Selecciona los parámetros de búsqueda 21. S: Realiza la búsqueda 22. S: Despliega la interfaz Resultados de Búsqueda con los resultados. 23. A: Revisa la información desplegada [d] 24. S: Vuelve al paso 2 de la trayectoria principal --- fin de la trayectoria alternativa

Anexos

139

Capítulo 3.6.8 Gestión de Roles

Actor Administrador Propósito • Gestionar los Roles Entradas • Depende de la acción

• Alta (id y nombre) • Baja(identificador, nombre) • Cambios (id y nombre) • Baja(identificador, nombre) • Consultas(id, nombre, fecha de modificación)

Salidas • Mensaje de confirmación • En el caso de consulta (id, nombre, fecha de

modificación) • Baja(identificador, nombre)

Precondiciones • El usuario debe tener una sección activa. Postcondiciones • Se ve efectuado el cambios en la Base de Datos

• En caso de Consulta se desplegara la información del Rol buscado.

Trayectoria Principal 9. S: Despliega la interfaz de Roles 10. A: Selecciona la operación a realizar [a|b|c|d|e] --- fin del caso de uso Puntos de Extensión 2a. Alta 29. S: Despliega la interfaz IM1.3.4 en blanco. 30. A: Introduce la información solicitada. [A|B] 31. A: Hace clic en el botón Guardar Cambios. 32. S: Valida la información ingresada. 33. S: Guarda la información ingresada. 34. S: Despliega MSG: Alta realizada correctamente. 35. S: Vuelve al paso 2 de la trayectoria principal. --- fin de la trayectoria alternativa 2b. Baja 25. A: Hace clic en el botón Eliminar 26. S: Despliega WAR: Confirmar Operación 27. A: Confirma la operación 28. S: Guarda los cambios realizados 29. S: Despliega MSG: Baja realizada correctamente 30. S: Vuelve al paso 2 de la trayectoria principal. --- fin de la trayectoria alternativa 2c. Cambio 37. S: Despliega la interfaz Datos de Rol con los datos correspondientes 38. A: Modifica la información solicitada [A|B] 39. A: Hace clic en el botón Guardar Cambios 40. S: Despliega WAR: Confirmar Cambios 41. A: Confirma la operación 42. S: Valida la información ingresada 43. S: Guarda los cambios 44. S: Despliega MSG: Cambio realizado correctamente 45. S: Vuelve al paso 2 de la trayectoria principal. --- fin de la trayectoria alternativa

Anexos

140

2d. Consulta 13. S: Despliega la interfaz Consultar Rol 14. A: Revisa la información mostrada [b|c] 15. S: Vuelve al paso 2 de la trayectoria principal. --- fin de la trayectoria alternativa 2e. Búsqueda 25. S: Despliega la interfaz Búsqueda de Rol 26. A: Selecciona los parámetros de búsqueda 27. S: Realiza la búsqueda 28. S: Despliega la interfaz Resultados de Búsqueda con los resultados. 29. A: Revisa la información desplegada [d] 30. S: Vuelve al paso 2 de la trayectoria principal --- fin de la trayectoria alternativa

Anexos

141

Capítulo 3.7 Diagrama de Interfaces Gráficas (Herencias y paquetes): En el presente diagrama se explica las relaciones entre los distintos archivos que utilizará el motor de templating para la generación de la interfaz gráfica de la aplicación web

Ilustración2 "Diagrama de Herencias y Paquetes"

Anexos

142

Capítulo 3.8 Diseño de Interfaces Su objetivo es que las aplicaciones o los objetos sean atractivos y además, hacer que la interacción con el usuario sea lo más intuitiva posible, conocido como el diseño centrado en el usuario.

Capítulo 3.8.1 NOMBRE: “INDEX-BIENVENIDA” ROL:(VISITANTE/ALUMNO / PROFESOR/ ADMINISTRADOR) INTERFAZ: I1.1 OBJETIVO: La presente pantalla cumple con la función de dar una bienvenida al usuario además de permitirle informarse un poco más acerca del sistema e ingresar al mismo. DISEÑO: La pantalla está conformada por tres secciones las cuales se explicaran a continuación

Ilustración3 "Diseño de Pantalla"

1.- Encabezado e Inicio de sesión 2.- Introducción al Sistema 3.- Inicio de Sesión y Registro

Anexos

143

PANTALLA:

Ilustración22 "Pantalla de Inicio de sesión"

Pantalla 1.1 “sección inicio de sesión” ENTRADAS

La entrada usuario .

La entrada de contraseña. COMANDOS:

: Botón Iniciar Sesión: Permite al usuario ingresar a su respectiva sesión, para poder llevar a cabo las tareas que tiene disponibles

Anexos

144

Capítulo 3.8.2 NOMBRE: “INDEX-INFO” ROL:(VISITANTE/ALUMNO / DOCENTE/ ADMINISTRADOR) INTERFAZ: I1.2 OBJETIVO: La presente pantalla cumple con la función de dar la información de Lectura del Carnet. DISEÑO: Esta pantalla incluye información del paciente y algunas de sus características PANTALLA:

Ilustración23"Pantalla Información del Paciente"

Anexos

145

Capítulo 3.8.3 NOMBRE: “INDEX-SESION” ROL:(VISITANTE/ALUMNO / PROFESOR/ ADMINISTRADOR) INTERFAZ: I1.3 OBJETIVO: La presente pantalla cumple con la función de dar al usuario la capacidad de ingresar al sistema si ya cuenta con una cuenta y en caso contrario redirigir al mismo al sitio para registrarse. DISEÑO: La pantalla está conformada por cuatro secciones las cuales se explicaran a continuación PANTALLA:

Ilustración24"Pantalla inicio sesión bottom"

ENTRADAS

La entrada de correo electrónico.

La entrada de contraseña. COMANDOS:

: Botón Iniciar Sesión: Permite al usuario ingresar a su respectiva sesión, para poder llevar a cabo las tareas que tiene disponibles

: Botón Regístrate ahora te re direccionará a la interfaz que te permita regístrate dentro del sistema.

Anexos

146

Capítulo 3.8.4 NOMBRE: “INDEX-ALUMNO” ROL:(ALUMNO) INTERFAZ: IA1.0 OBJETIVO: La presente pantalla cumple con la función de dar una bienvenida al ALUMNO además de permitirle informarse un poco más acerca sus avances. DISEÑO: La pantalla está conformada por tres secciones las cuales se explicarán en las siguientes pantallas:

Ilustración25 "Pantalla Índex Alumno"

1.- Área de Encabezado 2.- Área de Acciones Posibles 3.- Área de Despliegue, es donde se mostrara todo el contenido con respecto a la acción que desees realizar.

Capítulo 3.8.5 NOMBRE: “INDEX-BUSQUEDA” ROL:(VISITANTE/ALUMNO / PROFESOR/ ADMINISTRADOR) INTERFAZ: I1.5 OBJETIVO: La presente pantalla cumple con la función de dar al usuario la capacidad de buscar pacientes o información de cada Rol. DISEÑO: La pantalla está conformada por una sección de búsqueda y un área de presentación de Información. PANTALLA:

Anexos

147

Ilustración26 "Pantalla “INDEX-CITAS "

Capítulo 3.8.6 NOMBRE: “INDEX-CITAS” ROL:(VISITANTE/ALUMNO / PROFESOR/ ADMINISTRADOR) INTERFAZ: I1.6 OBJETIVO: La presente pantalla cumple con la función de presentar la información de Citas. DISEÑO: La pantalla está conformada por una sección de búsqueda de cita y un área de presentación de Información. PANTALLA:

Ilustración27"Pantalla “INDEX-CITAS "

Anexos

148

Capítulo 3.8.7 NOMBRE: “INDEX-ALERGIAS” ROL:(VISITANTE/ALUMNO / PROFESOR/ ADMINISTRADOR) INTERFAZ: I1.7 OBJETIVO: La presente pantalla cumple con la función de dar al usuario la capacidad de revisar las principales alergias del paciente. DISEÑO: La pantalla está conformada por una sección de búsqueda de alergias y un área de despliegue de Información. PANTALLA:

Ilustración28 "Pantalla “INDEX-Alergias"

Capítulo 3.8.8 NOMBRE: “INDEX-Consulta” ROL:(VISITANTE/ALUMNO / PROFESOR/ ADMINISTRADOR) INTERFAZ: I1.8 OBJETIVO: La presente pantalla cumple con la función de dar al usuario la información de las consultas. DISEÑO: La pantalla está conformada por una sección de búsqueda, fechas y un área de presentación de Información. PANTALLA:

Anexos

149

Ilustración29 "Pantalla “Consultas"

Anexos

150

Capítulo 3.8.25 NOMBRE: “ADMINISTRADOR-ELIMINA-ROL” ROL:(ADMINISTRADOR) INTERFAZ: IM1.5.1 OBJETIVO: La presente pantalla cumple con la función de eliminar la información acerca de búsqueda de roles mediante el identificador del rol seleccionado. DISEÑO: Una pantalla desplegable que permite confirmar la eliminación del rol. PANTALLA:

Ilustración30 "Pantalla Administrador -Eliminar Rol"

COMANDOS:

: Botón que permite al usuario cancelar la eliminación del rol seleccionado.

: Botón que permite al usuario confirmar la eliminación del rol seleccionado

Anexos

151

Capítulo 3.8.26 NOMBRE: “ADMINISTRADOR-MODIFICAR-ROL” ROL:(ADMINISTRADOR) INTERFAZ: IM1.3.5.2 OBJETIVO: La presente pantalla cumple con la función de crear o modificar la información de los roles. DISEÑO: La pantalla está basada en un formulario básico. PANTALLA:

Ilustración31"Pantalla Administrador-Modificar Rol"

ENTRADAS:

La entrada de nombre. COMANDOS:

: Botón que permite al usuario confirmar la creación del rol.

Anexos

152

Capitulo 4 Actualizaciones Durante la segunda fase de desarrollo del presente sistema hubo diversas actualizaciones las cuales pueden ser divididas en varios aspectos:

• Estéticas.- Mejora en el diseño de las interfaces, Interfaces Responsivas, Sistema de Templating • Funcionales.-

o Arquitectura.- Se migro el sistema web a una arquitectura basada en servicios (Arquitectura Rest) la cual se encuentra explicada previamente en el presente documento.

o Seguridad.-Implementación de una validación de usuarios basada en tokens (Arquitectura OAuth) Explicada previamente en el presente documento.

o Algoritmos.- § Motor de Inferencias.- Se implementó un algoritmo de motor de inferencias

para la selección de reactivos para las distintas evaluaciones según el progreso del usuario, dicho motor está basado en (Área de Aprendizaje, Tema, Competencia y Dificultad) el cual se encuentra explicado en el presente documento en el capítulo 4.2.

§ Implementación de un algoritmo genético para la optimización del motor de inferencias así como para recalcular el espacio de Búsqueda óptimo para las inferencias, el cual se encuentra explicado en el capítulo 4.3.

Durante la presente fase también se realizaron pruebas al mismo las cuales se pueden observar en el presente documento en el capítulo 5.

Anexos

153

Capítulo 5 Pruebas del Sistema El único instrumento adecuado para determinar el status de la calidad de un producto software es el proceso de pruebas. En este proceso se ejecutan pruebas dirigidas a componentes del software o al sistema de software en su totalidad, con el objetivo de medir el grado en que el software cumple con los requerimientos. En las pruebas se usan casos de prueba, especificados de forma estructurada mediante Técnicas de prueba. El proceso de pruebas, sus objetivos y los métodos y técnicas usados se describen en el plan de prueba.

Capítulo 5.1 Pruebas de Aceptación El uso de cualquier producto de software tiene que estar justificado por las ventajas que ofrece. Sin embargo, antes de empezar a usarlo es muy difícil determinar si sus ventajas realmente justifican su uso. El mejor instrumento para esta determinación es la llamada 'prueba de aceptación'. En esta prueba se evalúa el grado de calidad del software con relación a todos los aspectos relevantes para que el uso del producto se justifique. Para eliminar la influencia de conflictos de intereses, y para que sea lo más objetiva posible, la prueba de aceptación nunca debería ser responsabilidad de los ingenieros de software que han desarrollado el producto. Para la preparación, la ejecución y la evaluación de la prueba de aceptación ni siquiera hacen falta conocimientos informáticos. Sin embargo, un conocimiento amplio de métodos y técnicas de prueba y de la gestión de la calidad en general facilitan esta labor. La persona adecuada (o el equipo adecuado) para llevar a cabo la prueba de aceptación dispone de estos conocimientos y además es capaz de interpretar los requerimientos especificados por los futuros usuarios del sistema de software en cuestión.

Capítulo 5.1.1 Descripción de la Prueba La prueba consiste en probar el funcionamiento del sistema a través de pruebas de caja negra es decir se crea un guion de respuestas preconcebidas para llevar al sistema a un estado deseado para comprobar que las salidas obtenidas son las esperadas.

Anexos

154

Capítulo 5.1.2 Guiones de Prueba

Tabla 3 "Prueba Inicio de Sesión"

Tipo Aceptación Modulo Todos Nombre “Prueba de Inicio de Sesión”

Descripción La realización de esta prueba se hará mediante el método de caja negra por lo cual solo las entradas y las respectivas Salidas que generan.

Condiciones de ejecución Para que la presente prueba se pueda llevar a cabo, necesitan estar activos y accesibles ambos servicios (En Python).

Entradas /Pasos de Ejecución 1.-¿Se despliega la GUI correctamente?

Si( ) No( ) Observaciones:

Evalué la interfaz : ( )Ortografía, ( )Alineación,( )Espacios,( )Iconografía,( )Codificación,( )Responsividad 2.-El usuario Digita los valores de Entrada para Mal Inicio de Sesión 3.-¿Se negó el acceso al sistema?

Si( ) No ( ) Observaciones:

4.-¿Se redirigió a la pantalla de Índex?

Si ( ) No ( ) Observaciones

5.-El usuario Digita los valores de Entrada para Buen Inicio de Sesión Alumno 6.-¿Se permitió el acceso al sistema?


7.-¿Se redirigió a la pantalla de Índex Alumno?


Evalué la interfaz : ( )Ortografía, ( )Alineación,( )Espacios,( )Iconografía,( )Codificación,( )Responsividad 8. Se procede a cerrar sesión para continuar con la prueba 9.-El usuario Digita los valores de Entrada para Buen Inicio de Sesión Administrador 10.-¿Se permitió el acceso al sistema?


11.-¿Se redirigió a la pantalla de Índex Administrador?


Evalué la interfaz : ( )Ortografía, ( )Alineación,( )Espacios,( )Iconografía,( )Codificación,( )Responsividad 12. Se procede a cerrar sesión para continuar con la prueba 5.-El usuario Digita los valores de Entrada para Buen Inicio de Sesión Profesor

6.-¿Se permitió el acceso al sistema?


7.-¿Se redirigió a la pantalla de Índex

Profesor?


Evalué la interfaz : ( )Ortografía, ( )Alineación,( )Espacios,( )Iconografía,( )Codificación,( )Responsividad 8. Se procede a cerrar sesión para continuar con la prueba

Datos de Prueba Mal Inicio de Sesión Username: 2012630078 Password Sdfghj

Datos de Prueba Buen Inicio de Sesión Alumno Username: 2012630078 Password Sdfghj

Datos de Prueba Buen Inicio de Sesión Administrador

Anexos

155

Username: FARD920818 Password Administrador

Datos de Prueba Buen Inicio de Sesión Profesor Username: SISS930602 Password Profesor

Evaluación de la prueba Tipo de Defecto Número

Ortográfico (Menor) Interfaz (Medio)

Lógica de Negocio (Severo) Conectividad (Serio)

Observaciones

Tabla 4 "Guion de Prueba CRUD Usuarios"

Tipo Aceptación Módulo Administrador Nombre “CRUD Usuarios” Descripción La realización de esta prueba se hará mediante el método de caja negra por lo cual solo las entradas y las respectivas Salidas que generan. Condiciones de ejecución Para que la presente prueba se pueda llevar a cabo, necesitan estar activos y accesibles ambos servicios (Python). El usuario deberá tener una sesión activa como Administrador Entradas /Pasos de Ejecución 1. En gemalms.com/gema introducir Datos De prueba "Inicio Sesión"

Sí ( X ) No( ) Observaciones: No hay observaciones.

2. Revise la ruta del navegador. Es ésta ruta idéntica a gemalms.com/gema/administrators?


Evalué la interfaz : ( ) Ortografía, ( )Alineación, ( )Espacios, ( )Iconografía , ( )Codificación,()Responsividad 4. Haga clic en la pestaña Usuarios. ¿Se despliegan en la parte posterior las pestañas "Buscar un usuario", "Ver todos los usuarios", "Crear un usuario" y "Crear un cliente OAuth"?


Evalué la interfaz : ( )Ortografía, ( )Alineación,( )Espacios,( )Iconografía,( )Codificación,( )Responsividad

6. En la parte inferior debe aparecer una tabla con los siguientes campos: Usuario, Rol, Nombre, Email. ¿Están todos los campos debidamente llenados?


Anexos

156

7. Para la fila con el usuario "Santiago", haga clic en el botón azul que contiene un lápiz. ¿La vista ahora muestra un formulario con los datos del usuario "Santiago"?


8. Borre el campo marcado como "Usuario". Después haga clic en "Guardar cambios". ¿El sistema muestra un mensaje de error?


9. Repita los pasos 5 al 7 del guion de prueba. 10. Borre el campo marcado como "Nombre". Después haga clic en "Guardar cambios". ¿El sistema muestra un mensaje de error?


11. Repita los pasos 5 al 7 del guion de prueba.

12. Borre el campo marcado como "Apellido paterno". Después haga clic en "Guardar cambios". ¿El sistema muestra un mensaje de error?


13. Repita los pasos 5 al 7 del guion de prueba 14. Borre el campo marcado como "Apellido materno". Después haga clic en "Guardar cambios". ¿El sistema muestra un mensaje de error?


15. Repita los pasos 5 al 7 del guion de prueba. 16. Borre el campo marcado como "Correo electrónico". Después haga clic en "Guardar cambios". ¿El sistema muestra un mensaje de error?


17. Escriba los datos de prueba marcados como "Contraseña en blanco". Después de clic en el botón de "Guardar cambios". ¿El sistema muestra un mensaje de error?


18. Escriba los datos de prueba marcados como "Contraseñas no coinciden". Después de clic en el botón de "Guardar cambios". ¿El sistema muestra un mensaje de error?


Anexos

157

19. Escriba los datos de prueba marcados como "Contraseña correcta". Después de clic en el botón de "Guardar cambios". ¿El sistema muestra un mensaje de confirmación?


20. Haga clic en la pestaña "Ver todos los Usuarios". ¿Todos los campos están llenos apropiadamente?



21. Haga clic en la pestaña "Crear un Usuario". ¿Se despliega un formulario?


22. Escriba los datos correspondientes a "Crear usuario administrador". Después haga clic en "Guardar Cambios". ¿El sistema muestra un mensaje de confirmación?





24. Escriba los datos correspondientes a "Crear usuario profesor". Después haga clic en "Guardar Cambios". ¿El sistema muestra un mensaje de confirmación?




Datos de Prueba Inicio de Sesión Usuario Santiago Contraseña santi123 Datos de Prueba Buscar un usuario Campo de búsqueda Santiago Password Alumno Contraseña en blanco Contraseña <<dejar en blanco>> Confirmación de contraseña <<dejar en blanco>> Contraseñas no coinciden Contraseña passwordPrueba

Anexos

158

Confirmación de contraseña Pass Contraseña correcta Contraseña nuevoPassword Confirmación de contraseña nuevoPassword Crear usuario administrador Usuario usuariopruebaadmin Contraseña demodemodemo Confirmación de contraseña demodemodemo Rol de usuario Administrador Nombre Usuario Apellido Paterno DePrueba Apellido Materno Administrador Correo Electrónico [email protected] Crear usuario profesor Usuario usuariopruebaprofesor Contraseña demodemodemo Confirmación de contraseña demodemodemo Rol de usuario Profesor Nombre Usuario Apellido Paterno DePrueba Apellido Materno Profesor Correo Electrónico [email protected] Crear usuario alumno Usuario usuariopruebaalumno Contraseña demodemodemo Confirmación de contraseña demodemodemo Rol de usuario Alumno Nombre Usuario Apellido Paterno DePrueba Apellido Materno Alumno Correo Electrónico [email protected] Evaluación de la prueba Tipo de Defecto Número Ortográfico (Menor) Interfaz (Medio) Lógica de Negocio (Severo) Conectividad (Serio) Observaciones

Anexos

159

Tabla 5 "Guión de Prueba CRUD Roles" Tipo Aceptación Módulo Administrador Nombre “CRUD Roles” Descripción La realización de esta prueba se hará mediante el método de caja negra por lo cual solo las entradas y las respectivas Salidas que generan. Condiciones de ejecución Para que la presente prueba se pueda llevar a cabo, necesitan estar activos y accesibles ambos servicios (Tanto el de PHP como el de Python). El usuario deberá tener una sesión activa como Administrador Entradas /Pasos de Ejecución 1. En gemalms.com/gema introducir Datos De prueba "Inicio Sesión"


2. Revise la ruta del navegador. Es ésta ruta idéntica a gemalms.com/gema/administrators?


Evalué la interfaz : ( ) Ortografía, ( )Alineación, ( )Espacios, ( )Iconografía , ( )Codificación,()Responsividad 3. Haga clic en la pestaña Roles. ¿Se despliegan en la parte posterior las pestañas "Buscar un Rol", "Ver todos los Roles", "Crear un Rol"



4. Haga clic en la pestaña "Crear un Rol". ¿Se despliega un formulario?


5. Escriba los datos correspondientes a "Crear Rol". Después haga clic en "Guardar Cambios". ¿El sistema muestra un mensaje de confirmación?


6. Presione el menú Buscar rol ¿Se despliega Correctamente la pantalla de Búsqueda Rol correctamente?

Sí (X) No() Observaciones: No hay Observaciones


7. En la parte inferior debe aparecer una tabla con los siguientes campos: Nombre . ¿Están todos los campos debidamente llenados?


Anexos

160

8. Para la fila con el rol "Prueba", haga clic en el botón azul que contiene un lápiz. ¿La vista ahora muestra un formulario con los datos del rol "Prueba" Modifique el nombre por NOMBRE2?


9. Presione la opción buscar todos los roles, ¿Se muestran 3 roles y ve reflejado el cambio del NOMBRE2?

Sí (X) No() Observaciones: No hay observaciones.

10. Borre el campo marcado como "NOMBRE2". Después haga clic en "Guardar cambios". ¿El sistema muestra un mensaje de error?


11.- Vuelva a consultar todos los roles ¿Fue borrado con éxito el rol?


Crear Rol Nombre Prueba

Nombre 2 Nombre Nombre2 Evaluación de la prueba Tipo de Defecto Número Ortográfico (Menor) Interfaz (Medio) Lógica de Negocio (Severo) Conectividad (Serio) Observaciones

Tabla 6 "Prueba Registrarse"

Tipo Aceptación Módulo Todos Nombre Registro de usuario Descripción La realización de esta prueba se hará mediante el método de caja negra por lo cual solo las entradas y las respectivas Salidas que generan. Condiciones de ejecución Para que la presente prueba se pueda llevar a cabo, necesitan estar activos y accesibles ambos servicios (Python). Entradas /Pasos de Ejecución 1. Visite la url http://gemalms.com/gema/

Sí( X ) No( ) Observaciones: Ninguna

2. Evalué la interfaz : ( ) Ortografía, ( )Alineación, ( )Espacios, ( )Iconografía ,( )Codificación,()Responsividad 3. Haga clic en la sección "Registro" ¿Se muestra un formulario?


4. Introduzca los datos de prueba correspondientes a "Registro - usuario en blanco". Después haga clic en el botón de "Crear cuenta". ¿El sistema le restringe el botón?


Anexos

161

5. Introduzca los datos de prueba correspondientes a "Registro - contraseña en blanco". Después haga clic en el botón de "Crear cuenta". ¿El sistema le restringe el botón?


6. Introduzca los datos de prueba correspondientes a "Registro - confirmación en blanco". Después haga clic en el botón de "Crear cuenta". ¿El sistema le restringe el botón?


7. Introduzca los datos de prueba correspondientes a "Registro - contraseña no coincide". Después haga clic en el botón de "Crear cuenta". ¿El sistema le restringe el botón?


8. Introduzca los datos de prueba correspondientes a "Registro - correo en blanco". Después haga clic en el botón de "Crear cuenta". ¿El sistema le restringe el botón?


9. Introduzca los datos de prueba correspondientes a "Registro - datos correctos". Después haga clic en el botón de "Crear cuenta". ¿El sistema le permite hacer clic?


Registro - usuario en blanco Usuario <<en blanco>> Contraseña <<en blanco>> Confirmar contraseña <<en blanco>> Correo electrónico <<en blanco>> Registro - confirmación en blanco Usuario pruebaRegistro Contraseña Mipassword Confirmar contraseña <<en blanco>> Correo electrónico <<en blanco>> Registro - contraseña no coincide Usuario pruebaRegistro Contraseña Mipassword Confirmar contraseña Otropassword Correo electrónico <<en blanco>> Registro - correo en blanco Usuario pruebaRegistro Contraseña Mipassword Confirmar contraseña Otropassword Correo electrónico <<en blanco>> Registro - datos correctos Usuario pruebaRegistro Contraseña Mipassword Confirmar contraseña Mipassword Correo electrónico [email protected]

Anexos

162

Evaluación de la prueba Tipo de Defecto Número Ortográfico (Menor) 0 Interfaz (Medio) 0 Lógica de Negocio (Severo) 0 Conectividad (Serio) Observaciones Sin observaciones

7.1 Introducción

163

arquitectura de servicios móviles basada en internet de las cosas · 2021. 4. 20. · un modelo de...

Documents