replicaciÓn en mongodb, cifrado y envÍo de mÉtricas...

REPLICACIÓN EN MONGODB, CIFRADO Y ENVÍO DE MÉTRICAS DE HARDWARE EN TIEMPO REAL, COMO UN SISTEMA DE ALTA

DISPONIBILIDAD, CONFIDENCIALIDAD Y TOLERANTE A FALLOS

MAURICIO ANDRÉS GUERRA CUBILLOS

ERWIN HAMID PARDO QUIROGA

UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS FACULTAD TECNOLÓGICA INGENIERÍA TELEMÁTICA

BOGOTÁ D.C. COLOMBIA

2018

REPLICACIÓN EN MONGODB, CIFRADO Y ENVÍO DE MÉTRICAS DE HARDWARE EN TIEMPO REAL, COMO UN SISTEMA DE ALTA

DISPONIBILIDAD, CONFIDENCIALIDAD Y TOLERANTE A FALLOS

MAURICIO ANDRÉS GUERRA CUBILLOS 20152678001

ERWIN HAMID PARDO QUIROGA 20152678012

PROYECTO DE GRADO PRESENTADO COMO REQUISITO PARA OPTAR AL TÍTULO DE INGENIERO EN TELEMÁTICA

TUTOR-DIRECTOR: ROBERTO EMILIO SALAS RUIZ

UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS FACULTAD TECNOLÓGICA INGENIERÍA TELEMÁTICA

BOGOTÁ D.C. COLOMBIA

2018

Nota de Aceptación:

____________________________ ____________________________ ____________________________ ____________________________

Tutor

_______________________________ Ing. Roberto Emilio Salas Ruiz

Jurado

______________________________ Ing. Jorge Rodríguez

Bogotá D.C., mayo de 2018

CONTENIDO

PÁG.

RESUMEN EJECUTIVO 13

ABSTRACT 14

INTRODUCCIÓN 15

1 DESCRIPCIÓN DEL PROYECTO. 16

1.1 TÍTULO DEL PROYECTO 16

1.2 OBJETIVOS 16

1.2.1 Objetivo general 16

1.2.2 Objetivos específicos 16

1.3 PLANTEAMIENTO DEL PROBLEMA 17

1.3.1 Descripción del problema 17

1.3.2 Formulación del problema 18

1.4 ALCANCES 19

1.5 DELIMITACIONES 20

1.6 JUSTIFICACIÓN 21

1.7 MARCO DE REFERENCIA 22

1.7.1 Marco histórico 22

1.7.2 Marco teórico 25

1.7.3 Marco conceptual 48

1.8 FACTIBILIDAD 52

1.8.1 Factibilidad técnica 52

1.8.2 Factibilidad operativa 53

1.8.3 Factibilidad económica 54

1.9 CRONOGRAMA 57

2 FASE DE EXPLORACIÓN. 58

2.1 ÉPICAS 58

2.2 DEFINICIÓN DE LENGUAJE DE PROGRAMACIÓN Y TECNOLOGÍAS DE DESARROLLO 59

2.2.1 JAVA 60

2.2.2 C# 62

2.2.3 ACUERDO DEFINITIVO 65

3 FASE DE PLANEACIÓN. 75

3.1 MODELO DE CAPAS 75

3.2 DIAGRAMAS DE FLUJO Y CASOS DE USO 76

3.3 HISTORIAS DE USUARIO 81

3.4 SENSORES A MONITOREAR 85

4 FASE DE ITERACIONES. 88

4.1 ITERACIÓN 1: CAPTURA DE DATOS 88

4.1.1 Desarrollo de la historia de usuario HU-001. 88



4.1.4 Pruebas de serialización y cifrado en XML y JSON 95

4.2 ITERACIÓN 2: DISEÑO E IMPLEMENTACIÓN DE la replicación DE los DATOS 100

4.2.1 Diseño – Modelo de replicación 100

4.2.2 Implementación inicial del modelo de replicación 101

4.2.3 Pruebas de replicación 102

4.2.4 Prueba de desconexión del nodo primario 103

4.3 ITERACIÓN 3: CRUD EN BASE DE DATOS DISTRIBUIDA 106

4.3.1 Desarrollo de la historia de usuario HU-007 106


4.3.3 Desarrollo de la historia de usuario HU-009 y HU-010. 108






4.4 ITERACIÓN 4: APLICACIÓN EN TIEMPO REAL 113

4.4.1 Desarrollo de las historias de usuario HU-016, HU-017 y HU-018. 113

4.5 ITERACIÓN 5: INTEGRACIÓN Y PRUEBAS 118

5 FASE DE PRODUCCIÓN. 126

6 MUERTE DEL PROYECTO. 132

7 CONCLUSIONES. 134

8 RECOMENDACIONES. 135

BIBLIOGRAFÍA 136

ANEXOS 138

LISTA DE TABLAS

Tabla 1. Delimitaciones. ......................................................................................... 20

Tabla 2. Comparación de sistemas distribuidos..................................................... 23

Tabla 3. Uso de sistemas operativos 2009 - 2017 ................................................. 25

Tabla 4. Clasificación de las bases de datos NoSQL a 2018 ................................ 29

Tabla 5. Requerimientos mínimos de .NET Framework. ....................................... 35

Tabla 6 Diferencias entre metodologías ágiles y no ágiles. ................................... 39

Tabla 7. Estructura de las historias de usuario. ..................................................... 44

Tabla 8. Comparación entre AES y DES ............................................................... 47

Tabla 9. Check list de recursos técnicos. ............................................................... 52

Tabla 10. Recursos principales de hardware. ........................................................ 52

Tabla 11. Recursos principales de software. ......................................................... 53

Tabla 12. Factibilidad operativa. ............................................................................ 54

Tabla 13. Factibilidad económica – Recursos humanos. ....................................... 54

Tabla 14. Factibilidad económica – Recursos de hardware. .................................. 55

Tabla 15. Factibilidad económica – Recursos de software. ................................... 55

Tabla 16. Factibilidad económica – Gastos adicionales. ....................................... 55

Tabla 17. Factibilidad económica – Total recursos. ............................................... 56

Tabla 18. Proyectos desarrollados y años de experiencia por lenguaje de programación. ........................................................................................................ 59

Tabla 19. Caracteres utilizados en Base64. .......................................................... 68

Tabla 20. Compatibilidad del driver C#/.NET para MongoDB. ............................... 70

Tabla 21. Historia de usuario: Tiempo de espera entre reportes (HU-002). .......... 82

Tabla 22. Historia de usuario: Almacenamiento de datos (HU-006). ..................... 83

Tabla 23. Historia de usuario: Generación del archivo de configuración (HU-011). ............................................................................................................................... 84

Tabla 24. Bytes en claro vs bytes cifrados en AES-128 y AES-256. ..................... 96

Tabla 25. Tiempos en cifrado AES-128 y AES-256. .............................................. 97

Tabla 26. Tiempos en descifrado AES-128 y AES-256. ........................................ 98

Tabla 27. Configuración de host de replicación. .................................................. 103

Tabla 28. Nodo Windows de pruebas. ................................................................. 118

Tabla 29. Nodo Linux de pruebas. ....................................................................... 119

Tabla 30. Especificaciones del servidor de base de datos. ................................. 126

Tabla 31. Especificaciones servidor en producción. ............................................ 127

LISTA DE FIGURAS

Figura 1. Diagrama general de la solución. ........................................................... 19

Figura 2. Teorema CAP. ........................................................................................ 23

Figura 3. Base de datos centralizada. .................................................................... 26

Figura 4. Base de datos distribuida. ....................................................................... 26

Figura 5. Arquitectura de n capas implementado una base de datos distribuida. .. 28

Figura 6. Características de MongoDB. ................................................................. 30

Figura 7. Representación de los datos en MongoDB. ............................................ 31

Figura 8. Arquitectura Replica Set en MongoDB. .................................................. 32

Figura 9. Elección de nodo primario en caso de falla. ........................................... 33

Figura 10. .NET Framework en contexto. .............................................................. 36

Figura 11. Componentes del patrón MVVM. .......................................................... 37

Figura 12 Comparación de los modelos de desarrollo de software en cascada, iterativos y XP. ....................................................................................................... 40

Figura 13 El ciclo de vida de un proyecto XP. ....................................................... 41

Figura 14. Ejemplo de la descripción de una historia de usuario. .......................... 43

Figura 15. Cifrado y descifrado en AES ................................................................. 46

Figura 16. Cronograma de actividades. ................................................................. 57

Figura 17. Épicas del sistema. ............................................................................... 58

Figura 18. Componentes de texto en Java Swing. ................................................. 60

Figura 19. Clientes y Servidores. Sockets y ServerSockets. ................................. 61

Figura 20. Fragmento de código XAML. ................................................................ 62

Figura 21. Ejemplo de consulta con LINQ. ............................................................ 63

Figura 22. Vista física de la implementación de SignalR. ...................................... 64

Figura 23. Aes en C#. ............................................................................................ 66

Figura 24. Cifrar texto en C# con AES. .................................................................. 66

Figura 25. Arreglo de bytes a Base64. ................................................................... 67

Figura 26. Cadena en Base64. .............................................................................. 67

Figura 27. Paquetes de MongoDB en C#. ............................................................. 68

Figura 28. Conexión con MongoDB desde C#. ...................................................... 69

Figura 29. Acceso a una colección de MongoDB desde C#. ................................. 69

Figura 30. Principales componentes de Visual Studio. .......................................... 71

Figura 31. Team Explorer en Visual Studio. .......................................................... 72

Figura 32. Vista física de conexiones. ................................................................... 73

Figura 33. Entidades de dominio. .......................................................................... 74

Figura 34. Modelo de capas. ................................................................................. 75

Figura 35. Conexión al servidor (Emisor). .............................................................. 77

Figura 36. Conexión al servidor (Administrador). ................................................... 78

Figura 37. Enviar reporte. ...................................................................................... 79

Figura 38. Gestión de emisores. ............................................................................ 80

Figura 39. Gestión de usuarios. ............................................................................. 81

Figura 40. Métricas y datos a reportar de la placa madre. ..................................... 85

Figura 41. Métricas y datos a reportar del BIOS. ................................................... 85

Figura 42. Métricas y datos a reportar de la RAM. ................................................. 86

Figura 43. Métricas y datos a reportar del procesador. .......................................... 86

Figura 44. Métricas y datos a reportar de los discos duros o de estado sólido. ..... 87

Figura 45. Métricas y datos a reportar de las tarjetas de video. ............................ 87

Figura 46. Ejecutar un programa al inicio en Windows 7. ...................................... 89

Figura 47. Ejecución del comando shell:startup..................................................... 90

Figura 48. Aplicación al inicio................................................................................. 90

Figura 49. Carpeta de configuración. ..................................................................... 91

Figura 50. Tiempo de espera en archivo de configuración. ................................... 91

Figura 51. Leer archivo de configuración. .............................................................. 91

Figura 52. Iniciar captura. ...................................................................................... 92

Figura 53. Inicio de sesión. .................................................................................... 92

Figura 54. Cifrado AES 256 en CrypTool 2. ........................................................... 93

Figura 55. Fragmento de un reporte serializado en XML (izquierda) y en JSON (derecha). .............................................................................................................. 94

Figura 56. Modelo de replicación. ........................................................................ 100

Figura 57. Carpetas y archivo de configuración. .................................................. 101

Figura 58. Inicio de instancias en MongoDB. ....................................................... 101

Figura 59. Acceso a la consola de comandos de mongo. .................................... 101

Figura 60. Inicializar el Replica-Set. ..................................................................... 102

Figura 61. Adición de nodos. ............................................................................... 102

Figura 62. Vista de nodos desde RoboMongo. .................................................... 102

Figura 63. Documentos en base de datos. .......................................................... 103

Figura 64. Conexión desde C#. ........................................................................... 104

Figura 65. Agregar documentos desde C#. ......................................................... 104

Figura 66. Contar documentos desde C#. ........................................................... 105

Figura 67. Aplicación de pruebas. ........................................................................ 105

Figura 68. Módulo Emisores. ............................................................................... 106

Figura 69. Agregar Cliente. .................................................................................. 107

Figura 70. Reutilización de la vista Agregar Cliente y Editar Cliente. .................. 107

Figura 71. Editar Cliente. ..................................................................................... 108

Figura 72. Eliminación de emisores. .................................................................... 108

Figura 73. Vista Eliminar en XAML. ..................................................................... 109

Figura 74. Flujo Generar archivo de configuración. ............................................. 109

Figura 75. Estructura del archivo config.json. ...................................................... 110

Figura 76. Módulo Usuarios del sistema. ............................................................. 110

Figura 77. Agregar Usuario. ................................................................................. 111

Figura 78. Notificación de nueva contraseña. ...................................................... 111

Figura 79. Editar Usuario. .................................................................................... 111

Figura 80. Creación y edición de usuarios (Código). ........................................... 112

Figura 81. Eliminar Usuario.................................................................................. 112

Figura 82. Generar contraseña aleatoria. ............................................................ 113

Figura 83. Inicio del Servidor. .............................................................................. 114

Figura 84. Recibir Reporte ................................................................................... 114

Figura 85. Clase ClienteReporte. ......................................................................... 115

Figura 86. Dashboard .......................................................................................... 116

Figura 87. Tabla de emisores y sus sensores. .................................................... 117

Figura 88. Otros sensores. .................................................................................. 117

Figura 89. Dashboard Full Screen. ...................................................................... 118

Figura 90. Configuración red en archivo hosts. ................................................... 119

Figura 91. Cadena de conexión en pruebas. ....................................................... 119

Figura 92. Replica set inicial en Robo 3T. ........................................................... 119

Figura 93. Cuenta de correo electrónico. ............................................................. 120

Figura 94. Decodificación de base 64. ................................................................. 120

Figura 95. Edición del emisor en pruebas. ........................................................... 121

Figura 96. Dashboard en pruebas. ...................................................................... 121

Figura 97. Detención del nodo primario. .............................................................. 122

Figura 98. Nodo 'Not reachable' en Robo 3T. ...................................................... 122

Figura 99. Inicio de la instancia detenida. ............................................................ 122

Figura 100. Dirección IP del nodo primario. ......................................................... 123

Figura 101. Estado del nodo server1. .................................................................. 123

Figura 102. Salida del comando db.isMaster() .................................................... 123

Figura 103. Dashboard despues de las pruebas. ................................................ 124

Figura 104. Configuración de instancias. ............................................................. 126

Figura 105. Modelo implementado en producción. .............................................. 127

Figura 106. Dirección http del servidor en producción. ........................................ 127

Figura 107. Emisores en producción. .................................................................. 128

Figura 108. Tabla de sensores en producción. .................................................... 128

Figura 109. Dashboard equipos en producción. .................................................. 129

Figura 110. Otros emisores en producción. ......................................................... 130

Figura 111. Datos de tarjetas de video. ............................................................... 131

Figura 112. Planes MongoDB Atlas. .................................................................... 132

Figura 113. Características instancia M0 MongoDB Atlas. .................................. 133

LISTA DE GRÁFICAS

Gráfica 1. Comparación de los tiempos de cifrado entre AES y DES .................... 48

Gráfica 2. Porcentaje de recursos. ......................................................................... 56

Gráfica 3. Bytes en claro vs bytes cifrados. ........................................................... 96

Gráfica 4. Tiempos en cifrado AES-128 y AES-256. .............................................. 97

Gráfica 5. Tiempo en descifrado AES-128 y AES-256. .......................................... 98

Gráfica 6. Tiempo de cifrado y descifrado AES-128 y AES-256. ........................... 99

LISTA DE ANEXOS

ANEXO A. HISTORIAS DE USUARIO

ANEXO B. MÉTRICAS DE LOS SENSORES A REPORTAR

ANEXO C. MANUALES DE USUARIO

ANEXO D. MANUAL DE INSTALACIÓN

RESUMEN EJECUTIVO

Tener un dashboard (tablero) donde puedas visualizar en tiempo real, el estado de los componentes de hardware de los equipos de cómputo en tu compañía, es vital para detectar anomalías a tiempo, facilitar el inventario, programar mantenimientos preventivos, actualizaciones de software y una mejor utilización de los recursos que componen un equipo de cómputo.

En este documento está plasmado el desarrollo de una aplicación que permite visualizar en tiempo real la temperatura del procesador, cantidad de memoria utilizada, entre otros. Además de la actualización de los datos en tiempo real, se implementa un modelo de replicación de los datos que permite que el sistema esté disponible aun si se existe una desconexión de la base de datos. Por último, se utiliza un estándar de cifrado de tal forma que garantice confidencialidad de los datos durante la transmisión de los reportes desde los equipos emisores hasta los tableros de monitoreo de los administradores.

Palabras Clave: Monitoreo de hardware, aplicación en tiempo real, replica – set en MongoDB, cifrado AES-256.

ABSTRACT

In the dashboard will be possible view in real-time the hardware’s components status of the company’s computers; it is vital to detect anomalies on time, to ease the inventory, schedule preventive maintenances, software updates and get a better usage of resources that integrate computers.

This document contains the development of an application that allow to view in real time processor’s temperature, amount of memory used, among others. Besides the data updating in real time, it implements a data compilation model that allows the system to remains available even there is a disconnection from data base. Last but not least, it uses an encryption standard that ensures the data confidentiality during the reports transmission from the issuer devices to the administrators’ monitoring dashboards.

Key words: Hardware monitoring, real time application, replica - set in MongoDB, AES-256 encryption.

15

INTRODUCCIÓN

Las empresas, colegios, universidades, entre otros, cuentan con redes de computadores donde se realizan tareas cotidianas en ordenadores. Según statscounter.com, a marzo de 2018 se tiene que el sistema operativo de Windows representa el 82% de los computadores a nivel mundial, por lo tanto, existe una gran demanda por aplicaciones compatibles con el sistema operativo de Microsoft. A pesar que existen pequeñas y grandes redes de ordenadores con Windows, no se tiene un control y monitoreo de los mismos computadores, particularmente, de un monitoreo y control de los componentes de hardware como RAM, CPU, Discos de estado sólido y discos duros instalados en los ordenadores.

En esta monografía se desarrolló una aplicación donde se pueden monitorear computadores con sistema operativo Windows en tiempo real, implementando un modelo de replicación en MongoDB y cifrando los datos con el estándar AES. Se habla desde el punto de vista conceptual de las bases de datos distribuidas, NoSQL y sobre tecnologías para el desarrollo de aplicaciones para escritorio. Asimismo, se desarrolló bajo la metodología ágil XP utilizando las historias de usuario como artefactos para definir los requerimientos funcionales y no funcionales de la aplicación a desarrollada.

En las secciones finales se muestran los resultados de las pruebas de cifrado AES 128 y AES 256, tanto para los datos serializados en JSON y XML, se evidencia la ventaja de utilizar la codificación en base64 para el almacenamiento y transmisión de los datos. También, se realizan simulaciones de desconexiones de nodos de la base de datos para descubrir si el sistema es tolerante a fallos y de alta disponibilidad.

16

1 DESCRIPCIÓN DEL PROYECTO.

El presente capítulo presenta los objetivos, etc.

1.1 TÍTULO DEL PROYECTO

El presente escrito lleva por título “Replicación en MONGODB, cifrado y envío de métricas de hardware en tiempo real, como un sistema de alta disponibilidad, confidencialidad y tolerante a fallos”.

Dentro de los principales temas que se desarrollan están la replicación en el sistema de base de dato MongoDB, la implementación de cifrado simétrico y la visualización de los datos en tiempo real.

1.2 OBJETIVOS

1.2.1 Objetivo general

Implementar una base de datos distribuida en MongoDB con un modelo de replicación de datos que provea redundancia, alta disponibilidad y tolerancia a fallos para registrar métricas de hardware de ordenadores en una intranet o extranet, que permita el monitoreo y visualización en tiempo real de los sensores de los equipos conectados.

1.2.2 Objetivos específicos

Analizar el rendimiento del sistema cifrando las métricas tanto en AES128 como en AES256 en comparación con el texto en claro.

Desarrollar una aplicación de escritorio que permita visualizar en tiempo real las métricas de los equipos conectados.

Desarrollar un servicio que permita capturar las métricas de hardware tales como: temperatura del procesador, porcentaje de uso de la memoria RAM, porcentaje de uso del procesador, porcentaje de capacidad disponible del disco, etc.; almacenarlas en la base de datos distribuida y enviarlas en tiempo real. Véase Anexo B.

Especificar los requerimientos de las aplicaciones de escritorio (captura de sensores y visualización en tiempo real) en historias de usuario, implementando versiones, restricciones y parámetros de aceptación.

17

1.3 PLANTEAMIENTO DEL PROBLEMA

1.3.1 Descripción del problema

En la actualidad contamos con diversos dispositivos como smartphones, ordenadores de escritorio, asistentes virtuales, tabletas electrónicas, televisores inteligentes en donde usamos diversas aplicaciones que nos permiten estar conectados con amigos o familiares, además que facilitan nuestras tareas cotidianas y en algunos casos nos ayudan a tomar mejores decisiones basadas en recomendaciones de aplicaciones de tráfico, transporte, comida, entre otras.

El alto flujo de información que enviamos y generamos por los diferentes medios de transmisión de las redes telemáticas en la mayoría de los casos es transparente al usuario final, gracias a las características de estas redes de telecomunicaciones, al igual que sucede con los procesos internos que realizan los procesadores, las asignaciones de bloques en la memoria RAM, el espacio de almacenamiento, etc. Sin embargo, gracias al trabajo en conjunto de estos componentes de hardware, es que podemos realizar nuestras tareas y usar las aplicaciones de nuestros dispositivos electrónicos.

Es allí donde toma importancia el seguimiento a estos componentes de hardware, en cuanto al monitoreo de la temperatura de operación, voltajes adecuados, espacio libre de almacenamiento, etc., que permitan la correcta operación y funcionamiento, por ejemplo, de ordenadores de cómputo.

Para ello ya se han implementado una serie de herramientas con las cuales podemos capturar información actualizada de los sensores de hardware que componen nuestros equipos de cómputo, celulares, autos inteligentes, aplicaciones domóticas, dispositivos de agricultura de precisión, entre muchas otras.

En esta monografía realizaremos una investigación y desarrollo de una aplicación de escritorio para capturar los datos que los sensores específicamente de los ordenadores con sistema operativo Windows no de forma individual como se hace en la actualidad, sino de manera conjunta, interconectados en una red y de esta forma facilitar el monitoreo, así posteriormente con esa información se logre realizar un trabajo de mantenimiento preventivo de fallos, uso de los equipos e inteligencia de negocio y análisis de los datos.

Ya que se desea capturar y visualizar los datos que los sensores arrojan, se busca que estos se envíen de forma confidencial y en tiempo real, allí surgen otras necesidades desde el punto de vista tecnológico que se deben satisfacer, entre estas se encuentra la disponibilidad de los datos, ligado al motor de la base de datos y en muchos casos al servidor de aplicaciones, que generalmente en arquitecturas clásicas son centralizados, sin replicas y propensos a fallos y desconexiones.

18

1.3.2 Formulación del problema

De acuerdo con la descripción del problema de la sección anterior, nos formulamos la siguiente pregunta:

¿Por qué al implementar replicación de los datos en MongoDB, junto al cifrado y el envío de datos en tiempo real de sensores de hardware se puede desarrollar un sistema de alta disponibilidad, confidencialidad e integridad de los datos, que permita una mejor toma de decisiones, o acciones preventivas, correctivas y monitoreo de ordenadores con sistema operativo Windows en una red telemática?

19

1.4 ALCANCES

El proyecto se encuentra enfocado en la captura de métricas de hardware y envío en tiempo real de estas métricas cifradas con el estándar AES256, y el almacenamiento de esta información en un sistema de bases de datos distribuido, usando un modelo de replicación con MongoDB como se ilustra de forma básica en la Figura 1. El alcance este desarrollo es la captura los sensores de hardware instalados en los equipos de cómputo con sistema operativo Windows, que sirva para realizar un seguimiento en tiempo real de todos los equipos, lograr anomalías o desperfectos que se detecten con los datos enviados. Todo esto dentro de un sistema alta mente disponible y tolerante a fallos de desconexión en el servidor de la base de datos y se logren enviar las métricas de forma segura por una red telemática.

Figura 1. Diagrama general de la solución.

Fuente: Elaboración propia.

20

1.5 DELIMITACIONES

Las delimitaciones de este proyecto se resumen en cinco características principales descritas en la Tabla 1, con las cuales se busca limitar el desarrollo, construcción y expectativas del proyecto; asimismo, tener los objetivos planteados medibles y limitados.

Tabla 1. Delimitaciones.

Delimitación Descripción

Duración

El proyecto se estimó para ser entregado en una duración de 7 meses, en el cual se aplica una metodología de desarrollo ágil, de acuerdo a los objetivos planteados y a la fase de planeación. Este tiempo se distribuye de acuerdo a las tareas de cada una de las fases e iteraciones descritas en la Figura 16. Cronograma de actividades.

Enfoque

El desarrollo del proyecto está enfocado principalmente en la distribución de los datos y la tolerancia a fallos del sistema de replicación a implementar, para así lograr ver las características principales de un sistema de bases de datos distribuido. También, adicionando un componente de seguridad en la implementación del estándar AES256 para la confidencialidad de los datos.

Delimitación geográfica y de

sistema operacional

Está limitado inicialmente a redes LAN (Local Área Network) que cuenten con equipos de cómputo que tengan como sistema operativo Windows y que su versión sea igual o superior a Windows XP, ya que es el Windows es el sistema operativo más usado en el mundo.

Delimitación de conocimiento

El proyecto se basa específicamente en tres (3) temáticas diferentes como lo son las bases de datos distribuidas, envío de datos en tiempo real y cifrado de información. Se busca con la aplicación de los conocimientos en Seguridad, Ingeniería de Software, Desarrollo de Aplicaciones, Bases de Datos y Sistemas Distribuidos construir un producto que cumpla con los objetivos planteados y la formulación del problema.

Equipo de trabajo

El proyecto se estimó para ser elaborado por tres (3) recursos humanos principales, de los cuales dos (2) como desarrolladores, que realizan las tareas descritas en el cronograma de actividades y se verán apoyados con el conocimiento, gestión y dirección con el tutor de la monografía.


21

1.6 JUSTIFICACIÓN

Implementar replicación de los datos, conlleva a tener un sistema distribuido gestor de bases de datos, responsable de garantizar transparencia de ubicación, transparencia de acceso, transparencia de escalamiento e implica mayor responsabilidad que un gestor centralizado de base de datos, por el hecho de tener múltiples nodos (servidores o instancias) que trabajan en como una única unidad. Sin embargo, estas transparencias benefician al usuario final y al equipo desarrollador en tolerancia a fallos, integridad y fiabilidad de los datos, rendimiento en las consultas y varias peticiones en un mismo instante de tiempo.

El otro componente telemático que se incorpora y se desarrolla en esta monografía

es el envío de datos en tiempo real, que permite visualizar el estado en todo

momento de los ordenadores conectados en una red, tomados de los sensores del

procesador, memoria RAM, discos duros, tarjetas de video que tienen integrados

estos componentes de hardware. Tener esta información visible en una consola de

administración sin necesidad de estar físicamente en el equipo les permitirá a los

administradores de una red monitorear los computadores y tomar decisiones acerca

de mantenimientos preventivos, correctivos, sobre cambios de temperatura, voltaje,

almacenamiento y memoria ocupada en los equipos.

Por último, se construye una aplicación para la captura y envió de los reportes del

estado del hardware, implementando replicación de los datos y cifrado AES-256, sin

que afecte el rendimiento de la transmisión en tiempo real, pero que, si aporte

confidencialidad de los datos, para su posterior visualización por parte de los

administradores de la red telemática, de tal forma, que sirva como una aplicación

genérica a implementar en redes LAN o públicas, en instituciones educativas,

entidades bancarias, es decir, para cualquier tipo de empresas que tenga la

necesidad de monitorear el estado de los equipos de cómputo con sistema operativo

Windows.

22

1.7 MARCO DE REFERENCIA

1.7.1 Marco histórico

1.7.1.1 Paradigma de bases de datos no relacionales El trascurso de los años ha dado cada vez más relevancia al manejo de la información, requiriendo velocidades de respuesta más óptimas y con una disponibilidad superior. Además, los volúmenes de información están creciendo de una manera abrumadora y cada vez se hace más compleja su administración1 y de allí surge el paradigma de las bases de datos NoSQL.

Las bases de datos no relacionales fueron la respuesta a dicha necesidad de gestionar enormes cantidades de información y engloba todos todas las tecnologías de almacenamiento estructurado que no cumplen el esquema relacional dentro de las cuales se encuentran cuatro categorías:

Basadas en clase/valor.

Basadas en documentos.

Basadas en grafos.

Basadas en columnas.

Las bases de datos NoSQL poseen diferentes características que las diferencia del uso tradicional de las bases de datos relacionales y por las cuales han tomado gran fuerzo y acogida durante los últimos años:

Escalabilidad horizontal.

Habilidad de distribución.

Uso eficiente de los recursos.

Libertad de esquema.

ACID es de uso abierto.

Consultas simples.

Todas estas características mencionadas, hacen de las bases de datos NoSQL una solución, puede ser “temporal”, al mejor almacenamiento y administración de toda la información, y por ende, a una satisfacción mayor de los usuarios, sin embargo, cabe resaltar cuatro (4) aspectos técnicos importantes que engrandecen in poco más el uso de este tipo de bases de datos y que a lo largo de la historia le han dado fuerza a su uso:

Teorema CAP: Esta idea surge en el año 2000 gracias a Eric Brewer2, quien propone que en un entorno distribuido un sistema no puede mantener

1 ROMERO, Alexander Castro.; et al. Óp. cit. 2 A. Fox and E. Brewer.; Op. cit.

23

continuamente consistencia perfecta, disponibilidad y tolerancia a particiones simultáneamente. Es de allí que según las necesidades del proyecto o del cliente se debe sacrificar al menos una de las características mencionadas, tal y como se muestra en la Figura 2.

Figura 2. Teorema CAP.


De acuerdo con este teorema, Sepúlveda Cruz3 realizo una tabla comparativa (Tabla 2) donde se visualizan algunas ventajas y desventajas de cada tipo de sistema:

Tabla 2. Comparación de sistemas distribuidos.

Sistema CA Sistema CP Sistema AP

Ventajas Disponibilidad constante Consistencia estricta

Consistencia sólida Amplia escalabilidad

Disponibilidad constante Amplia escalabilidad

Desventajas Poca escalabilidad Disponibilidad sujeta a conexiones de nodo

Los datos no son consistentes en todo momento

Tipo de BD Relacionales NoSQL NoSQL

Ejemplos de BD MySQL Oracle Database SQL Server

MongoDB HBase Redis

Cassandra Riak CouchDB

Fuente: SEPÚLVEDA CRUZ, Sergio Andrés. Clasificación de sistemas gestores de base de datos según el teorema de CAP. 2018.

3 SEPÚLVEDA CRUZ, Sergio Andrés. Clasificación de sistemas gestores de base de datos según el teorema de CAP. 2018.

24

ACID (Atomicity, Consistency, Isolation, Durability)4: es muy importante en los sistemas de bases de datos relacionales; sin embargo, en los sistemas NoSQL se hizo evidente que con el fin de proporcionar una gran escalabilidad, puede ser necesario relajarse o redefinir algunas de las cualidades de este modelo, en particular consistencia y durabilidad.

Datos y modelo de acceso: El modelo relacional presenta problemas tales como la relación con los lenguajes orientados a objetos y presentan dificultad para la adaptación a datos no estructurados, y adicionalmente tiene dificultades de gestión en un entorno distribuido y las soluciones a esto conllevan a sobrecargas de red lo cual puede detener el progreso del sistema.

Datos y procesos distribuidos: Las bases de datos NoSQL permiten la implementación con gran facilidad de sistemas distribuidos sin necesidad de centralizar la información, lo cual contribuye a la fiabilidad y escalabilidad de las bases de datos, sin embargo, tiene retos de gestión debido a los datos duplicados y los costos extra.

Como bien se destaca, las bases de datos NoSQL son una medida para el manejo de la información que hoy en día se maneja, sin embargo, existen algunos retos a superar para cada vez tomar más fuerza en el mercado y lograr aumentar sus niveles de implementación.

Realizar una estandarización, ya que existen una amplia cantidad de tecnologías y esto, a la larga, puede llegar a convertirse en una debilidad, ya que existen alrededor de 50 motores diferentes.

Establecer las tecnologías de bases de datos NoSQL y que estas se presenten de manera completa a los usuarios.

Finalmente, el gran reto es demostrar que las bases de datos NoSQL son algo nuevo y bueno, esto mediante el uso principal de las comunidades académicas.

1.7.1.2 Actualidad de Windows OS Este proyecto está encaminado específicamente al almacenamiento de métricas de hardware mediante el sistema operativo Windows, así como también su completo desarrollo, por ende, es importante evidenciar el gran porcentaje de usuarios del mundo y específicamente en Colombia hace uso de este y las variaciones que se han dado desde enero de 2009 hasta diciembre de 2017.

4 ACID es un término que describe el conjunto de propiedades necesarias para garantizar que las transacciones en una base de datos se realicen de forma confiable. Estas propiedades son: Atomicidad, Consistencia, Aislamiento y Durabilidad. [ T. Haerder and A. Reuter]

25

Tabla 3. Uso de sistemas operativos 2009 - 2017

Año Uso de Windows (%) Uso de otros OS (%)

2009 98.42 1.58

2010 97.89 2.11

2011 97.30 2.7

2012 96.64 3.36

2013 95.59 4.41

2014 91.58 8,42

2015 86.58 13.42

2016 82.16 17.84

2017 81.41 18.59 Fuente: http://gs.statcounter.com/os-market-share

Como se puede apreciar en la Tabla 3, a pesar que con el paso de los años ha disminuido el porcentaje de uso del sistema operativo Windows en Colombia, es aún predominante frente a otros sistemas operativos en el mercado. Actualmente, la estadística al día a marzo de 2018 muestra un 81.19% de equipos de cómputo con el sistema operativo Windows en Colombia y un 82.56% a nivel mundial.

1.7.2 Marco teórico

1.7.2.1 Bases de datos distribuidas ÖZSU, M. Tamer y VALDURIEZ, Patrick5, definen una base de datos distribuida como una colección de múltiples bases de datos interrelacionadas lógicamente distribuidas a través de una red informática. Un sistema de gestión de base de datos distribuido (SGBDD, en español y DDBMS, en inglés) se define entonces, como el sistema de software que permite la gestión de la base de datos distribuida y hace la distribución transparente para los usuarios.

En un sistema distribuido de bases de datos (DDBS), no es un sistema donde a pesar exista una red de comunicaciones, la base de datos reside en un único nodo de la red (Figura 3) y los demás nodos redireccionan las peticiones al nodo de la base datos, en ese caso la administración o la gestión se realiza de forma similar que una base de datos centralizada. Lo que se diferencia a un DDBS, es un entorno donde los datos están distribuidos entre un número de nodos en la red (Figura 4).

5 ÖZSU, M. Tamer; VALDURIEZ, Patrick. Principles of distributed database systems. Springer Science & Business Media, 2016. 868 p

26

Figura 3. Base de datos centralizada.

Fuente: ÖZSU, M. Tamer; VALDURIEZ, Patrick. Principles of distributed database systems. Springer Science & Business Media, 2016.

Figura 4. Base de datos distribuida.


27

1.7.2.2 Características de las bases de datos distribuidas La independencia de los datos, es una forma fundamental de transparencia, se refiere a la inmunidad de las aplicaciones de los usuarios, a los cambios en la definición y organización de los datos, y viceversa. Esta inmunidad se realiza tanto en un nivel lógico (esquema) y físico de los datos, por tanto una aplicación no debería ser modificada cuando se producen cambios en la organización de datos.

Para el usuario no debe haber diferencia entre las aplicaciones de base de datos que se ejecutarían en una base de datos centralizada y las que se ejecutarían en una base de datos distribuida. Este tipo de transparencia se denomina transparencia de red o transparencia de distribución, esta determina que los usuarios no tengan que especificar dónde se encuentran los datos

La transparencia de ubicación se refiere al hecho de que el comando utilizado para realizar una tarea es independiente tanto de la ubicación de los datos, como del sistema en el que se lleva a cabo una operación.

La transparencia de replicación se refiere sólo a la existencia de réplicas, no a su ubicación real, es decir que los usuarios no deben ser conscientes de la existencia de copias, sino, es el sistema (SGBD) quien debe manejar la gestión de copias, de tal forma que el usuario debe actuar como si existiera una sola copia de los datos. La distribución de estas réplicas a través de la red de una manera transparente pertenece a la transparencia de la red.

1.7.2.3 Servidor de base de datos en una arquitectura distribuida El enfoque de servidor de aplicaciones y servidor de base de datos en una arquitectura distribuida de N niveles, puede verse como una extensión de la arquitecturas cliente / servidor clásica, de esta forma, existen múltiples servidores de bases de datos y múltiples servidores de aplicaciones (Figura 5). En este caso, es típico que cada servidor de aplicaciones esté dedicado a una o algunas aplicaciones, mientras que los servidores de bases de datos operan en la forma de servidor de base de datos distribuida.

28

Figura 5. Arquitectura de n capas implementado una base de datos distribuida.


1.7.2.4 Bases de datos NoSQL Poveda6 dice que inicialmente las bases de datos no relacionales, denominadas NoSQL, se referían a bases de datos que no usaban el estándar de consultas SQL, sin embargo, con el transcurso de los años y su uso extendido se entiende en la actualidad como Not Only SQL, recalcando que las bases de datos no relacionales también soportan el lenguaje de consultas SQL.

Surgen debido al constante aumento en el volumen de los datos que son almacenados, la constante consulta de estos y el mayor procesamiento que es requerido para estos procedimientos y se caracterizan en gran medida por el uso de las propiedades “ACID”7

6 POVEDA GALVIS, Juan Pablo. Propuesta de Notación Gráfica para el Modelo Orientado a Documentos de MongoDB. Trabajo de grado para optar por el título de Ingeniero Electrónico. Universidad Distrital Francisco José de Caldas. 2016, p.7. 7 ACID es un término que describe el conjunto de propiedades necesarias para garantizar que las transacciones en una base de datos se realicen de forma confiable. Estas propiedades son: Atomicidad, Consistencia, Aislamiento y Durabilidad. [ T. Haerder and A. Reuter].

29

“Los sistemas NoSQL son distribuidos por naturaleza.”8

En la Tabla 4 se relacionan los diferentes tipos de bases de datos y su clasificación según el ranking actualizado de DB-Engines:

Tabla 4. Clasificación de las bases de datos NoSQL a 2018

Modelo de datos Base de datos Clasificación9

Orientado a documentos

MongoDB Couchbase CouchDB RavenDB

5 23 28 68

Orientado a gráficos Neo4j OrientDB ArangoDB

22 47 62

Clase-valor

Redis Memcached Amazon DynamoDB Riak

8 24 21 44

Por columnas Cassandra Hbase Accumulo

10 17 64

Fuente: POVEDA GALVIS, Juan Pablo. Propuesta de Notación Gráfica para el Modelo Orientado a Documentos de MongoDB. 2016

1.7.2.5 MongoDB Como se indica CHODOROW10 “MongoDB es una base de datos de gran alcance potente, flexible y escalable”. Combina la capacidad de escalar con características tales como índices de educación media, rangos, clasificación, agregación e índices geoespaciales. Su nombre proviene de la palabra homongous que significa enorme y su filosofía es conseguir mayor velocidad y escalabilidad11.

Como se puede observar en la tabla 3, MongoDB es una base de datos NoSQL orientada a documentos, es decir, en lugar de almacenar los datos en registros, los almacena en documentos y estos a su vez en colecciones. Dichos documentos se almacenan en BSON22, lo cual brinda el beneficio de un mejor mapeo de los objetos permitiendo que la integración de los datos sea más fácil, rápida y flexible, además de permitir una fácil gestión y codificación12.

8 POVEDA. Óp. cit., p. 8. 9 Puesto en el que se encuentra catalogada la base de datos según DB-Engines 10 CHODOROW, Kristina. MongoDB: the definitive guide. " O'Reilly Media, Inc.", 2013. 11 POVEDA. Óp. cit., p. 15. 12 BERMEJO, María. Desarrollo de un sistema de autoescalado dinámico de base de datos distribuida MongoDB sobre una plataforma cloud OpenStack. 2016. Tesis de Maestría.

30

MongoDB es una base de datos de propósito general, por lo que además de crear, leer, actualizar y eliminar datos, proporciona una lista cada vez mayor de características únicas13 que se evidencian en la Figura 6:

Figura 6. Características de MongoDB.

Fuente: CHODOROW, Kristina. MongoDB: the definitive guide. " O'Reilly Media, Inc.", 2013.

Indexación: Apoya los índices secundarios genéricos, permitiendo una variedad de consultas rápidas, y proporciona capacidades exclusivas de indexación compuesta, geoespacial y de texto completo.

Agregación: soporte y "pipeline de agregación", que le permite crear agregaciones complejas a partir de piezas simples y permitir que la base de datos lo optimice.

Tipos de Colecciones Especiales: Apoye las colecciones de tiempo de vida para datos que deben expirar en un momento determinado, tales sesiones. También admite colecciones de tamaño fijo, que son útiles para almacenar datos recientes, como registros.

Almacenamiento de archivos: Mongo soporta un protocolo fácil de usar para almacenar archivos grandes y metadatos de archivos.

13 CHODOROW. Óp. cit., p. 4.

31

1.7.2.6 Componentes de MongoDB Las bases de datos en MongoDB poseen una estructura y representación de los datos especiales como se muestra en la Figura 7 ya que es una base de datos orientada a documentos:

Las bases de datos en MongoDB se encuentran conformadas por colecciones.

A su vez una colección es un conjunto de varios documentos agrupados en ella.

Los documentos se muestran al usuario en formato JSON para facilitar su lectura.

La interacción entre el usuario y los documentos JSON, se hace por medio de una terminal que usa el lenguaje de programación JavaScript.

Con la ayuda de JavaScript se pueden hacer consultas y modificar los documentos JSON.

Para hacer más eficiente la codificación, decodificación, transporte y el almacenamiento de los diferentes tipos de datos, se usa BSON.

Figura 7. Representación de los datos en MongoDB.

Fuente: POVEDA GALVIS, Juan Pablo. Propuesta de Notación Gráfica para el Modelo Orientado a Documentos de MongoDB. Trabajo de grado para optar por el título de Ingeniero Electrónico. Universidad Distrital Francisco José de Caldas. 2016.

1.7.2.7 Replicación con MongoDB La replicación consiste en contar con varias copias de la misma información en varios equipos. Esto con el fin de tener alta disponibilidad de los datos en caso de error, y asegurar copias de seguridad para recuperar los datos en caso de desastre. Al conjunto de equipos que contiene la misma información, se le llama conjunto de réplica14.

El número de equipos presente en un conjunto de réplica se denomina factor de replicación, abreviado como RF (Replication Factor). Conociendo el factor de replicación y la cantidad de documentos distintos en el sistema n = 100 × 106, se puede calcular con la siguiente ecuación el total de documentos que hay en el sistema dT

14 Ibíd., p. 18.

32

RF · n = dT

3 · 100 × 106 = 300 × 106

En cada conjunto de réplica solo puede haber un equipo primario o maestro que es el que replica la información a los equipos secundarios o esclavos como se puede ver en la Figura 8. Esto se hace para que solo el miembro primario del conjunto pueda aceptar operaciones de escritura, y de esta manera asegurar estricta consistencia en todas las lecturas que se hagan en él15.

Figura 8. Arquitectura Replica Set en MongoDB.

Fuente: BERMEJO, María. Desarrollo de un sistema de autoescalado dinámico de base de datos distribuida MongoDB sobre una plataforma cloud OpenStack. 2016. Tesis de Maestría.

Un replica set, técnicamente, es un grupo de instancias mongod que albergan el mismo conjunto de datos. Existen 2 tipos de instancias16.

Primarios: Reciben todas las operaciones de la escritura.

Secundarios: Copian operaciones del Primario de modo que todos tienen el mismo conjunto de datos.

En la Figura 8, se puede observar un ejemplo de un replica set sencillo, en general, si el nodo primario se cae o no se encuentra disponible, se elige a otro miembro dentro de los nodos secundarios y se convertirá en el nuevo nodo primario como se ilustra en la Figura 9, por lo cual añade las características de tolerancia a fallos, failover y recuperación automática de la información.

15 Ibíd., p. 19. 16 BERMEJO. Óp. cit., p. 15.

33

Únicamente puede existir un nodo principal por Replica-Set y en general debe existir un número impar de miembros en dentro del sistema de replicación17.

Elección del nodo primario

Figura 9. Elección de nodo primario en caso de falla.

Fuente: BERMEJO, María. Desarrollo de un sistema de autoescalado dinámico de base de datos distribuida MongoDB sobre una plataforma cloud OpenStack. 2016. Tesis de Maestría.

En un Replica-Set los miembros envían ping entre si cada 2 segundos, si alguno de estos demora más de 10s, los demás miembros lo marcaran como inaccesible, seguidamente se inicia una especie de votación para elegir al nodo con la prioridad más alta18.

Rollback

Un rollback reestablece las operaciones del nodo primario anterior luego de que se incorpora al replica-set luego de una falla o caída. El rollback es necesario cuando existe información u operaciones que no alcanzaron a replicar y permite que la coherencia de la base de datos se mantenga19.

1.7.2.8 .NET Framework Como su nombre lo indica es un marco o entorno de trabajo creado por Microsoft en los 90, tiene la particularidad de ejecutarse únicamente en Windows. Es una

17 BERMEJO. Óp. cit., p. 15 18 Ibíd., p. 15 19 Ibíd., p. 15

34

tecnología que admite la compilación, ejecución de aplicaciones y servicios web. Dentro de los principales objetivos de esta tecnología están20:

Proporcionar un entorno coherente de programación orientada a objetos, en el que el código de los objetos se pueda almacenar y ejecutar de forma local, ejecutar de forma local pero distribuida en Internet o ejecutar de forma remota.

Proporcionar un entorno de ejecución de código que reduzca lo máximo posible la implementación de software y los conflictos de versiones.

Ofrecer un entorno de ejecución de código que promueva la ejecución segura del mismo, incluso del creado por terceras personas desconocidas o que no son de plena confianza.

Proporcionar un entorno de ejecución de código que elimine los problemas de rendimiento de los entornos en los que se utilizan scripts o intérpretes de comandos.

Ofrecer al programador una experiencia coherente entre tipos de aplicaciones muy diferentes, como las basadas en Windows o en Web.

Basar toda la comunicación en estándares del sector para asegurar que el código de .NET Framework se puede integrar con otros tipos de código.

Este marco de trabajo incluye el Common Language Runtime (CLR), una biblioteca de clases, librerías y otros frameworks como ASP.NET, Windows Forms y WPF. Dentro de las funciones del Common Language Runtime están: la administración de la memoria, ejecución de código y subprocesos, comprobación de la seguridad del código. El Runtime, impone solidez al código, mediante la implementación de una infraestructura estricta y comprobación de tipos denominada Common Type System (CTS). También, controla la disposición de los objetos, administra las referencias a estos y los librea cuando ya no se utilizan. Esta administración automática de la memoria soluciona dos problemas de software comunes: la fuga de memoria y las referencias no válidas a la memoria. Otra característica importante es la compilación JIT (Just-In-Time), que permite ejecutar todo el código administrado en el lenguaje de la máquina en el que se ejecuta.

La biblioteca de clases, es un conjunto de clases reutilizables orientada a objetos, lo que reduce el tiempo de aprendizaje de las nuevas características de .NET Framework y sean fáciles de utilizar. Además, permite que componentes de terceros se integren fácilmente con las clases de .NET Framework. Como cualquier biblioteca de clases, permite realizar tareas de programación comunes, como la recolección de datos, conectividad con bases de datos, acceso a archivos, entre

20 Overview of the .NET Framework. Microsoft Docs. 2017. Disponible en: https://docs.microsoft.com/en-us/dotnet/framework/get-started/overview

https://docs.microsoft.com/en-us/dotnet/framework/get-started/overview

35

otros. Microsoft recomienda usar .NET Framework para desarrollar las siguientes aplicaciones y servicios21:

Aplicaciones de consola.

Aplicaciones de interfaz gráfica de usuario de Windows (Windows Forms).

Aplicaciones de Windows Presentation Foundation. (WPF).

Aplicaciones de ASP.NET

Servicios de Windows.

Aplicaciones orientadas a servicios, mediante Windows Communication Foundation (WCF).

En la Figura 10 se muestra la relación del CLR y la biblioteca de clases de .NET Framework con las aplicaciones y el sistema operativo.

Los requerimientos mínimos del sistema que se necesitan para instalar .Net Framework son los plasmados en la Tabla 522:

Tabla 5. Requerimientos mínimos de .NET Framework.

HARDWARE REQUERIMIENTO MÍNIMO

PROCESADOR 1 GHz RAM 512 MB ESPACIO EN DISCO 4.5 GB (32-bits)

4.5 GB (64-bits) Fuente: .NET Framework system requirements. Microsoft Docs. 2018. https://docs.microsoft.com/en-us/dotnet/framework/get-started/system-requirementst

21 Información general acerca de .NET Framework. Microsoft Docs. 2017. Disponible en: https://docs.microsoft.com/es-es/dotnet/framework/get-started/overview 22 .NET Framework system requirements. Microsoft Docs. 2018. https://docs.microsoft.com/en-us/dotnet/framework/get-started/system-requirementst

https://docs.microsoft.com/en-us/dotnet/framework/get-started/system-requirementst

https://docs.microsoft.com/es-es/dotnet/framework/get-started/overview



36

Figura 10. .NET Framework en contexto.

Fuente: Microsoft Docs. Overview of the .NET Framework. https://docs.microsoft.com/en-us/dotnet/framework/get-started/overview

1.7.2.9 MVVM en XAML MVVM (Modelo, Vista, Vista-Modelo) es un patrón de diseño que se puede implementar en tecnologías con vistas XAML como Windows Forms, Silverlight, WPF, Windows Phone y Xamarin. La intención de este patrón es proveer una clara separación de la interfaz gráfica de usuario y la lógica23.

Como particularidad del XAML está el sistema de enlace de datos, este permite enlazar las propiedades de diferentes objetos y mantenerlos sincronizados. Esto ofrece al desarrollador concentrarse únicamente en calcular el valor de las propiedades de los objetos sin tener que preocuparse de actualizar la interfaz de usuario. La siguiente ilustración (Figura 11) muestra los tres componentes del patrón MVVM.

23 The MVVM Pattern. Microsoft. https://msdn.microsoft.com/en-us/library/hh848246.aspx



https://msdn.microsoft.com/en-us/library/hh848246.aspx

37

Figura 11. Componentes del patrón MVVM.

Fuente: Implementing the Model-View-ViewModel Pattern. Microsoft. https://msdn.microsoft.com/en-us/library/ff798384.aspx

Gracias al XAML el enlace de datos se puede expresar en forma declarativa, directamente en el cuerpo del documento. Esto permite un proceso desacoplado, donde el desarrollador se preocupa del modelo y del ViewModel, mientras que un diseñador se hace cargo de la vista en forma simultánea o no.

La Vista es responsable de definir la estructura, el diseño y la apariencia de lo que el usuario ve en la pantalla. Generalmente, la vista se define puramente con XAML, con un “code-behid” limitado que no contiene lógica de negocio. Una vista puede tener su propio ViewModel donde obtiene los datos a través de bindings o invocando métodos del ViewModel. En tiempo de ejecución la vista cambia cuando los controles UI responden a los eventos de notificación de los cambios generados en las propiedades de los objetos del ViewModel24.

El Modelo son las entidades de negocio, repositorios, objetos de trasferencia de datos (DTO) y Plain Old CLR Objects (POCOs). Es decir, son clases que al instanciarlas proveen de objetos con propiedades y atributos a mostrar y modificar en la vista.

El ViewModel actúa como intermediario entre la vista y el modelo y es responsable de la lógica de la vista. Normalmente interactúa con el modelo invocando métodos en las clases del modelo, manipulando datos de este en el formato requerido por la vista. También, se encarga de notificar a la vista si los datos subyacentes del modelo cambian. Asimismo, provee implementación de comandos que un usuario inicia en

24 Implementing the Model-View-ViewModel Pattern. Microsoft. https://msdn.microsoft.com/en-us/library/ff798384.aspx

https://msdn.microsoft.com/en-us/library/ff798384.aspx

https://msdn.microsoft.com/en-us/library/ff798384.aspx

38

la vista. Por ejemplo, cuando un usuario da click sobre un botón en la interfaz gráfica, activa un comando en el ViewModel25.

1.7.2.10 Metodología XP26 La metodología en que se basa el desarrollo de esta monografía es la programación extrema, esta metodología pertenece al conjunto conocido como metodologías agiles27, las cuales han cambiado el desarrollo de software en contraste con las metodologías clásicas.

El término ágil utilizado en el desarrollo de software surge de una reunión celebrada en febrero de 2001, donde participaron expertos en la industria de software, incluyendo algunos de los creadores de las metodologías de software28. Tras esta reunión se fundó The Agile Alliance, una organización sin ánimo de lucro, que apoya a las personas que exploran y aplican valores, principios y prácticas ágiles para hacer que las soluciones de software sean más efectivas, humanas y sostenibles.

Además de la creación de "The Agile Alliance"29, tras la reunión cuatro principios se establecieron en lo que se conoce como: el manifiesto por el desarrollo ágil de software30, estos principios son:

Individuos e interacciones sobre procesos y herramientas.

Software funcionando sobre documentación extensiva.

Colaboración con el cliente sobre negociación contractual.

Respuesta ante el cambio sobre seguir un plan.

En el manifiesto que se puede encontrar en la dirección http://agilemanifesto.org/iso/es/manifesto.html, ellos dicen que "aunque valoramos los elementos de la derecha, valoramos más los de la izquierda".

Aunque los creadores e impulsores de las metodologías ágiles más populares han suscrito el manifiesto ágil y coinciden con los principios enunciados anteriormente, cada metodología tiene características propias y hace hincapié en algunos aspectos más específicos. Canós, Letelier y Penadés,31 enumeran las principales diferencias de una metodología ágil respecto de las metodologías tradicionales. La siguiente tabla, recoge estas diferencias que no se refieren sólo al proceso en sí, sino también

25 The MVVM Pattern. Microsoft. https://msdn.microsoft.com/en-us/library/hh848246.aspx 26 www.extremeprogramming.org, www.xprogramming.com, c2.com/cgi/wiki?ExtremeProgramming 27 BEN OTHMANE, Lotfi, et al. Extending the agile development process to develop acceptably secure software. 2014. p. 2. 28 CANÓS, José H.; LETELIER, Patricio; PENADÉS, Mª Carmen. Metodologías ágiles en el desarrollo de software. 2012. p. 2. 29 The Agile Alliance, https://www.agilealliance.org/ 30 Manifiesto por el Desarrollo Ágil de Software, http://agilemanifesto.org/iso/es/manifesto.html 31 CANÓS, José H.; et al. Óp. cit.

http://agilemanifesto.org/iso/es/manifesto.html

https://msdn.microsoft.com/en-us/library/hh848246.aspx

39

al contexto de equipo y organización que es más favorable a cada uno de estas filosofías de procesos de desarrollo de software.

A continuación, en la Tabla 6 se encuentra un cuadro comparativo entre la metodología ágil y la metodología tradicional.

Tabla 6 Diferencias entre metodologías ágiles y no ágiles.

Metodología Ágil Metodología Tradicional

Pocos Artefactos. El modelado es prescindible, modelos desechables.

Más Artefactos. El modelado es esencial, mantenimiento de modelos.

Pocos Roles, más genéricos y flexibles. Más Roles, más específicos.

No existe un contrato tradicional, debe ser bastante flexible.

Existe un contrato prefijado.

El cliente es parte del equipo de desarrollo. (además in-situ)

El cliente interactúa con el equipo de desarrollo mediante reuniones.

Orientada a proyectos pequeños. Corta duración (o entregas frecuentes), equipos pequeños (< 10 integrantes) y trabajando en el mismo sitio.

Aplicables a proyectos de cualquier tamaño, pero suelen ser especialmente efectivas/usadas en proyectos grandes y con equipos posiblemente dispersos.

La arquitectura se va definiendo y mejorando a lo largo del proyecto.

Se promueve que la arquitectura se defina tempranamente en el proyecto.

Énfasis en los aspectos humanos: el individuo y el trabajo en equipo.

Énfasis en la definición del proceso: roles, actividades y artefactos.

Basadas en heurísticas provenientes de prácticas de producción de código.

Basadas en normas provenientes de estándares seguidos por el entorno de desarrollo.

Se esperan cambios durante el proyecto.

Se espera que no ocurran cambios de gran impacto durante el proyecto.

Fuente: CANÓS, José H.; LETELIER, Patricio; PENADÉS, Mª Carmen. Metodologías ágiles en el desarrollo de software. 2012. p. 4.

The Agile Alliance, define la programación extrema32 (XP) como una metodología ágil de desarrollo de software, que tiene como objetivo producir software de mayor calidad y mayor calidad de vida para el equipo de desarrollo. Canós, Letelier y Penadés33, citan a al padre de XP, Kent Beck y afirman que es una metodología ágil centrada en potenciar las relaciones interpersonales como clave para el éxito en desarrollo de software, promoviendo el trabajo en equipo, preocupándose por el aprendizaje de los desarrolladores, y propiciando un buen clima de trabajo. Canós, Letelier y Penadés, también afirman que XP se define como especialmente

32 The Agile Alliance. Programación Extrema, https://www.agilealliance.org/glossary/xp 33 CANÓS, José H.; et al. Metodologías ágiles en el desarrollo de software. 2012. p. 4.

40

adecuada para proyectos con requisitos imprecisos y muy cambiantes, y donde existe un alto riesgo técnico.

The Agile Alliance y Mousques34, coinciden que XP tiene cinco valores que son la comunicación, la simplicidad, la retroalimentación, el coraje y el respeto. Por otro lado, Joskowicz35 describe detalladamente que el ciclo de vida de un proyecto XP incluye al igual que las otras metodologías entender lo que el cliente necesita, estimar el esfuerzo, crear la solución entregar el producto final al cliente. Sin embargo, XP propone un ciclo de vida dinámico, donde se admite expresamente que, en muchos casos, los clientes no son capaces de especificar sus requerimientos al comienzo de un proyecto.

Por esto, se trata de realizar ciclos de desarrollo cortos (llamados iteraciones), con entregables funcionales al finalizar cada ciclo. En cada iteración se realiza un ciclo completo de análisis, diseño, desarrollo y pruebas, pero utilizando un conjunto de reglas y prácticas que caracterizan a XP.

La Figura 12 tomada del trabajo de Joskowicz, esquematiza los ciclos de desarrollo en cascada (a) e iterativos (b) tradicionales, comparadas con el de XP (c).

Figura 12 Comparación de los modelos de desarrollo de software en cascada, iterativos y XP.

Fuente: JOSKOWICZ, José. Reglas y prácticas en eXtreme Programming. Universidad de Vigo, 2008, pág. 8.

34 MOUSQUES, Gastón. Cátedra de Ingeniería de Software. Universidad ORT Uruguay. Facultad de Ingeniería. 2013. 35 JOSKOWICZ, José. Reglas y prácticas en eXtreme Programming. Universidad de Vigo, 2008.

41

Mousques36 describe las fases del ciclo de vida de un proyecto XP, en la siguiente imagen (Figura 13) se pueden apreciar las fases que más adelante se describen en de forma detallada.

Figura 13 El ciclo de vida de un proyecto XP.

Fuente: MOUSQUES, Gastón. Cátedra de Ingeniería de Software. Universidad ORT Uruguay. Facultad de Ingeniería. 2013.

Fase de exploración: Se plantean a grandes rasgos las historias de usuario que son de interés para la primera entrega del producto. El equipo de desarrollo se familiariza con las herramientas, tecnologías y prácticas.

Fase de planificación: En esta fase el cliente establece la prioridad de cada historia de usuario, los programadores realizan una estimación del esfuerzo necesario de cada una de ellas. Se toman acuerdos sobre el contenido de la primera entrega y se determina un cronograma en conjunto con el cliente.

Fase de iteraciones: Esta fase incluye varias iteraciones del sistema antes de la entrega del primer release. El calendario es dividido en un número iteraciones de tal manera de que cada iteración tome de una a cuatro semanas de implementación. En la primera iteración se crea un sistema que abarca los aspectos más importantes de la arquitectura global. Esto se logra seleccionando las stories que hagan referencia a la construcción de la estructura de todo el sistema. Al final de la última iteración el sistema estará listo para entrar en producción.

Fase de puesta en producción: La fase de producción requiere de pruebas adicionales y revisiones de rendimiento antes de que el sistema sea

36 MOUSQUES, Gastón. Óp. cit.

42

trasladado al entorno del cliente. Se deben tomar decisiones sobre la inclusión de nuevas características a la versión actual, debido a cambios durante esta fase.

Mantenimiento: En esta fase por lo general se necesita un esfuerzo extra de los programadores para satisfacer los requerimientos del cliente. Por este motivo la velocidad de desarrollo suele disminuir una vez que el sistema es puesto en producción

Muerte: Es cuando el cliente no tiene más historias para ser incluidas en el sistema. Se genera la documentación final del sistema y no se realizan más cambios en la arquitectura. La muerte del proyecto también ocurre cuando el sistema no genera los beneficios esperados por el cliente o cuando no hay presupuesto para mantenerlo.

1.7.2.11 Historias de Usuario Canós, Letelier y Penadés37, definen las historias de usuario como la técnica utilizada en extrem Programming, para especificar requerimientos de software. Consisten en tarjetas (“cards” en inglés) de papel en las cuales el cliente describe brevemente los requerimientos funcionales o no funcionales que el sistema debe poseer. Por otra parte, Joskowicz38 dice que las historias de usuario sustituyen a los documentos de especificación funcional y a los casos de uso. Afirma que, la principal diferencia entre las historias de usuario y los tradicionales documentos de especificación funcional están en el nivel de detalle requerido, ya que, las historias de usuario deben ser los suficientemente compresible y delimitada para que los programadores puedan realizar una estimación poco riesgosa y logren implementarla en pocas semanas.

The Agile Alliance39, coincide con las anteriores descripciones de las historias de usuario y dice que independientemente del orden de su implementación, se espera que éstas produzcan una contribución al valor global del producto.

Izaurralde y Andriano40 citan a Cohn41 para indicar que toda historia de usuario tiene una descripción que será utilizada para planificar y posteriormente disgregar los detalles con el dueño del producto las pruebas para determinar si una historia está finalizada o no. Asimismo, concuerdan con The Agile Alliance al decir que las historias de usuario se escriben en notas de papel (post-its) para facilitar la

37 CANÓS, José H.; et al. Metodologías ágiles en el desarrollo de software. 2012. p. 4. 38 JOSKOWICZ, José. Reglas y prácticas en eXtreme Programming. Universidad de Vigo, 2008. 39 The Agile Alliance. User Stories, https://www.agilealliance.org/glossary/user-stories 40 IZAURRALDE, Paula; ANDRIANO, Natalia. Trazabilidad Ágil. Universidad Tecnológica Nacional, Argentina. 2013. p. 3 41 COHN, Mike. User stories applied: For agile software development. Addison-Wesley Professional, 2004.

43

planificación y discusiones que se llevan a cabo, típicamente se escriben de la forma4243:

Como <rol o tipo de usuario>, quiero <acción a ejecutar>, para <finalidad>.

Un ejemplo de historias de usuario se puede apreciar en la Figura 14.

Figura 14. Ejemplo de la descripción de una historia de usuario.


Historias épicas y “Splitting”: Dentro de los beneficios que tienen las historias de usuario, están que pueden ser escritas en diferentes niveles de detalle, las historias que cubren múltiples funcionalidades, son llamadas historias épicas y tienen la particularidad que no pueden ser finalizadas en una sola iteración, por tanto son dividas en historias de usuario más cortas, este proceso The Agile Alliance lo define como división de historias (“story splitting”)44. En la fase de exploración se definirán las épicas que tendrá el proyecto, estas determinarán las grades funcionalidades y el desarrollo de software.

Todas las historias de usuario que se definirán en la fase de planeación tendrán la estructura que se muestra en la Tabla 7.

42 CHIRIBOGA, Washington Alberto. Aplicación informática para la integración y alimentación de datos del balanced scorecard de la Universidad Técnica Estatal de Quevedo. 2016. Tesis de Maestría. Ecuador. 2015. p. 8. 43 IZAURRALDE, Paula; ANDRIANO, Natalia. Óp. cit. p. 3. 44 The Agile Alliance. Story Splitting, https://www.agilealliance.org/glossary/split/

44

Tabla 7. Estructura de las historias de usuario.

NOMBRE:

ID: HU-xyz

PRIORIDAD: n

ESTIMACIÓN: m

VERSIÓN: a.b.

DESCRIPCIÓN:

CRITERIOS DE ACEPTACIÓN:

PROTOTIPO:


A continuación, se describen cada uno de los campos que se tienen de la estructura definida.

ID: Hace referencia a la identificación de la historia de usuario, la cual está compuesta de la abreviatura “HU” (Historia de Usuario), seguida de un numero consecutivo que distingue a las demás historias definidas.

NOMBRE: El nombre es un título que resume a grandes rasgos la historia de usuario, por tanto, constituye un breve enunciado.

PRIORIDAD: Es un valor numérico entre 1 y 10 que representa la prioridad de la historia de usuario para el negocio o el usuario final.

ESTIMACIÓN: Es un valor numérico que hace referencia al esfuerzo en horas / programador para el cumplimiento de la historia de usuario.

VERSIÓN: La versión está compuesta de dos números, en donde el de la izquierda del punto es el de mayor valor y representa un cambio fundamental en la historia de usuario, mientras que el aumento del número a la derecha representa modificaciones menores a la historia de usuario.

DESCRIPCIÓN: Representa la descripción de la historia de usuario que se trató en párrafos anteriores. Es de la forma: “Como <rol o tipo de usuario>, quiero <acción a ejecutar>, para <finalidad>”.

CRITERIOS DE ACEPTACIÓN: Son condiciones, restricciones o limitaciones que la historia de usuario debe cumplir, también, determinan las pruebas que se deben realizar.

PROTOTIPO: Es un modelo grafico generalmente de la interfaz de usuario, que sirve de bosquejo o muestra antes del desarrollo de la funcionalidad.

En el anexo A, se encuentran las historias de usuario con la anterior estructura definidas en la fase de exploración.

45

1.7.2.12 Cifrado AES45 Tanto la implementación en hardware como en software son rápidas y puede ser implementado en varias plataformas especialmente en dispositivos pequeños. Es el nuevo estándar de cifrado recomendado por NIST como reemplazo al DES46.

El cifrado de bloques AES tiene una longitud de bloque de 128 bits y puede utilizar una clave de 128, 192 o 256 bits. Katz y Lindell47 dicen que, la longitud de la clave afecta al cálculo de la subclave de cada ronda, así como el número de rondas, pero no afecta a la estructura de alto nivel de cada ronda.

Durante el cálculo del algoritmo AES, una matriz de 4x4 bytes llamada estado (16 bytes son exactamente 128 bits que hace referencia a la longitud de bloque) que se modifica en una serie de rondas. El número de rondas depende de la longitud de la clave48. Diez rondas se utilizan para clave de 128 bits, 12 rondas para una clave de 192 bits y 14 rondas para una clave de 256 bits49.

En la siguiente imagen (Figura 15) se muestra el diagrama de flujo realizado por MAHAJAN y SACHDEVA50 tanto para el cifrado, como el descifrado de bloques de datos en AES-128. Existen cuatro operaciones que se realizan en este tipo de cifrado por bloques, estas son: Add Round Key, Sub Bytes, Shift Rows y Mix Columns. La principal diferencia que se observa entre rondas, es que en la última ronda del cifrado la operación Mix Columns no se realiza.

Por otro lado, el descifrado consiste en invertir todos los pasos usados en el cifrado, mediante funciones inversas como: Inverse Shift Rows, Inverse Add Round Key, Inverse Sub Bytes e Inverse Mix Columns. Al igual que ocurre con el cifrado, la operación Inverse Mix Columns no se realiza en la última ronda del descifrado.

45 AES, es la abreviatura de ADVANCED ENCRYPTION STANDARD, nombrado por la NIST en el año 2001 (FIPS PUB 197). Disponible en: http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.197.pdf 46 MAHAJAN, Prerna; SACHDEVA, Abhishek. A Study of Encryption Algorithms AES, DES and RSA for security. Global Journal of Computer Science and Technology, 2013, vol. 13, no 15, p. 16 47 KATZ, Jonathan; LINDELL, Yehuda. Introduction to modern cryptography. CRC press, 2014. Ed. 2, p. 224 48 MAHAJAN, Prerna; SACHDEVA, Abhishek. Op. cit., p. 16. 49 KATZ, Jonathan; LINDELL, Yehuda. Op. cit., p. 224 50 MAHAJAN, Prerna; SACHDEVA, Abhishek. Op. cit., p. 17.

46

Figura 15. Cifrado y descifrado en AES

Fuente: MAHAJAN, Prerna; SACHDEVA, Abhishek. A Study of Encryption Algorithms AES, DES and RSA for security. Global Journal of Computer Science and Technology, 2013, vol. 13, no 15, p. 17

MAHAJAN y SACHDEVA51, realizan una comparación entre AES y DES (Tabla 8), donde se puede apreciar que el algoritmo de cifrado AES posee algunas características que sobresalen, por ejemplo, el tamaño del bloque, la velocidad de cifrado y descifrado, y por último que es considerado con un algoritmo seguro.

51 Ibíd., p. 17

47

Tabla 8. Comparación entre AES y DES


Por último, MAHAJAN y SACHDEVA52 realizan pruebas en cuatro archivos de texto de diferentes tamaños (153KB, 196KB, 312KB y 868KB), para evaluar el rendimiento en el cifrado de los algoritmos AES y DES, dando como resultado que AES es más rápido que DES como se evidencia en la Grafica 1.

52 Ibíd., p. 21

48

Gráfica 1. Comparación de los tiempos de cifrado entre AES y DES


1.7.3 Marco conceptual

En esta sección se detallan los conceptos fundamentales en los que se basa la construcción del proyecto, enfocado a la implementación de una base de datos distribuida en MongoDB, por lo cual se describirán las características y conceptos fundamentales a considerar para el desarrollo. Se definirá MongoDB como una base de datos NoSQL orientada a documentos y se describen conceptos utilizados en la replicación de los datos en este motor de base de datos.

1.7.3.1 Bases de datos distribuidas ÖZSU, M. Tamer y VALDURIEZ, Patrick53, definen una base de datos distribuida como una colección de múltiples bases de datos interrelacionadas lógicamente distribuidas a través de una red informática. Un sistema de gestión de base de datos distribuido (SGBDD, en español y DDBMS, en inglés) se define entonces, como el sistema de software que permite la gestión de la base de datos distribuida y hace la distribución transparente para los usuarios.

Entrega de datos

De acuerdo a la clasificación expuesta por ÖZSU, y VALDURIEZ, existen tres tipos de alternativas en la entrega de los datos, estas son:

Pull-only

En este modo, la transferencia de datos de los servidores a los clientes se realiza mediante un pull del cliente. Cuando se recibe la petición de un cliente, el servidor responde localizando la información solicitada, sin embargo, la inserción de nuevos

53 ÖZSU, M. Tamer; VALDURIEZ, Patrick. Principles of distributed database systems. Springer Science & Business Media, 2016. 868 p

49

datos o actualizaciones a elementos existentes se llevan a cabo en el servidor sin notificar a los clientes, a menos que éstos explícitamente realicen pull al servidor. Los sistemas gestores de base de datos convencionales, ofrecen principalmente este modo.

Push-only

La transferencia de datos de servidores a clientes se inicia mediante un push desde el servidor, sin que existan peticiones específicas de algún cliente. La dificultad de este enfoque es que el servidor depende en gran medida de la exactitud para predecir las necesidades de los clientes, ya que no se conoce qué datos serían de interés común y cuándo enviarlos a los clientes. En el modo basado en push, los servidores difunden información a un grupo ilimitado de clientes (broadcast) o un conjunto selectivo de clientes (multicast), que pertenecen a algunas categorías de destinatarios que pueden recibir los datos.

Híbrido

Este modo combina los mecanismos cliente-pull y server-push. El método de consulta continua presenta una forma posible de combinar los modos de pull y push: es decir, la transferencia de información de los servidores a los clientes se inicia primero mediante un pull de cliente y la posterior transferencia de la información a los clientes se inicia mediante un push del servidor.

1.7.3.2 Bases de datos NoSQL Poveda54 dice que inicialmente las bases de datos no relacionales, denominadas NoSQL, se referían a bases de datos que no usaban el estándar de consultas SQL, sin embargo, con el transcurso de los años y su uso extendido se entiende en la actualidad como Not Only SQL, recalcando que las bases de datos no relacionales también soportan el lenguaje de consultas SQL.

Surgen debido al constante aumento en el volumen de los datos que son almacenados, la constante consulta de estos y el mayor procesamiento que es requerido para estos procedimientos y se caracterizan en gran medida por el uso de las propiedades “ACID”55

54 POVEDA GALVIS, Juan Pablo. Propuesta de Notación Gráfica para el Modelo Orientado a Documentos de MongoDB. Trabajo de grado para optar por el título de Ingeniero Electrónico. Universidad Distrital Francisco José de Caldas. 2016, p.7. 55 ACID es un término que describe el conjunto de propiedades necesarias para garantizar que las transacciones en una base de datos se realicen de forma confiable. Estas propiedades son: Atomicidad, Consistencia, Aislamiento y Durabilidad. [ T. Haerder and A. Reuter].

50

1.7.3.3 MongoDB Como se indica CHODOROW56 “MongoDB es una base de datos de gran alcance potente, flexible y escalable”. Combina la capacidad de escalar con características tales como índices de educación media, rangos, clasificación, agregación e índices geoespaciales. Su nombre proviene de la palabra homongous que significa enorme y su filosofía es conseguir mayor velocidad y escalabilidad57. Algunas características de MongoDB son:

Indexación: Apoya los índices secundarios genéricos, permitiendo una variedad de consultas rápidas, y proporciona capacidades exclusivas de indexación compuesta, geoespacial y de texto completo.

Agregación: soporte y "pipeline de agregación", que le permite crear agregaciones complejas a partir de piezas simples y permitir que la base de datos lo optimice.

Tipos de Colecciones Especiales: Apoye las colecciones de tiempo de vida para datos que deben expirar en un momento determinado, tales sesiones. También admite colecciones de tamaño fijo, que son útiles para almacenar datos recientes, como registros.

Almacenamiento de archivos: Mongo soporta un protocolo fácil de usar para almacenar archivos grandes y metadatos de archivos.

1.7.3.4 Replicación con MongoDB La replicación consiste en contar con varias copias de la misma información en varios equipos. Esto con el fin de tener alta disponibilidad de los datos en caso de error, y asegurar copias de seguridad para recuperar los datos en caso de desastre. Al conjunto de equipos que contiene la misma información, se le llama conjunto de réplica58.

Rollback

Un rollback reestablece las operaciones del nodo primario anterior luego de que se incorpora al replica-set luego de una falla o caída. El rollback es necesario cuando existe información u operaciones que no alcanzaron a replicar y permite que la coherencia de la base de datos se mantenga59.

56 CHODOROW, Kristina. MongoDB: the definitive guide. " O'Reilly Media, Inc.", 2013. 57 POVEDA. Óp. cit., p. 15. 58 Ibíd., p. 18. 59 Ibíd., p. 15

51

1.7.3.5 .NET Framework Como su nombre lo indica es un marco o entorno de trabajo creado por Microsoft en los 90, tiene la particularidad de ejecutarse únicamente en Windows. Es una tecnología que admite la compilación, ejecución de aplicaciones y servicios web.

La biblioteca de clases, es un conjunto de clases reutilizables orientada a objetos, lo que reduce el tiempo de aprendizaje de las nuevas características de .NET Framework y sean fáciles de utilizar. Además, permite que componentes de terceros se integren fácilmente con las clases de .NET Framework. Como cualquier biblioteca de clases, permite realizar tareas de programación comunes, como la recolección de datos, conectividad con bases de datos, acceso a archivos, entre otros.

52

1.8 FACTIBILIDAD

1.8.1 Factibilidad técnica

El desarrollo del proyecto requiere de una seria de recursos con los cuales se llevara a cabo toda la implementación, la siguiente tabla (Tabla 9) es un check list de los recursos técnicos principales que son necesarios y serán la base del proyecto:

Tabla 9. Check list de recursos técnicos.

Recurso Si No

Equipos para el desarrollo X

Entornos de desarrollo IDE X

Equipos para pruebas X

Lugares de trabajo X

Internet X

Switch, Cables de red X

Motor de base de datos X

Elaboración propia.

Como elementos principales de hardware se encuentran los equipos en los cuales se realizara el desarrollo y ejecución del proyecto por parte de los integrantes de este. Dichos equipos cuentan con las características suficientes y necesarias para el proyecto como se muestra en la Tabla 10, y por ende, no requieren una inversión económica inicial.

Tabla 10. Recursos principales de hardware.

Equipo 1

Disco Duro 128 GB

RAM 6 GB

Procesador Intel Core 2 Duo E8400

Tarjeta de video NVIDIA GeForce 9500 GT 512MB

Tarjeta de red Marvell Yukon PCI Gigabit Ethernet Controller

Equipo 2

Disco Duro 500GB

RAM 6GB

Procesador Core i3 1.6Ghz

Tarjeta de video INTEL HD Graphics 3000 - 1.5 GB

Tarjeta de red Controladora Realtek PCIe FE Family

Ralink RT5390R 802.11 bgn Wi-Fi Adapter Fuente: Elaboración propia.

Como componente principal de software se encuentra el sistema operativo base sobre el cual se va a desarrollar la aplicación y van dirigidas las pruebas respectivas

53

es Windows en varias de sus versiones (Windows 10, Windows 7, Windows 8), este va de la mano con el recurso ofimático Microsoft Office mediante el cual se realiza toda la documentación del proyecto.

Como entorno de desarrollo se eligió el uso de Microsoft Visual Studio Community, el cual puede ser descargado gratuitamente en la página del proveedor y nos ofrece todas las características necesarias para la implementación completa y lograr cumplir con los objetivos planteados. Así mismo, se eligió como gestor de bases de datos MongoDB, el cual ofrece almacenamiento de enormes cantidades de información y la posibilidad de implementar un sistema de bases de datos distribuido, también indispensable para el cumplimiento de los objetivos del proyecto y que se integra fácilmente con el IDE Visual Studio.

En la actualidad es parte importante del desarrollo de software contar con un repositorio que almacene y nos dé la posibilidad de administrar nuestros documentos y código fuente principalmente, es por ello que se adquirieron cuentas de Microsoft para el uso de Visual Studio Team Services por parte de los desarrolladores y de esta manera alojar los recursos necesarios en la nube.

Es importante aclarar que los recursos de hardware con los que cuenta el equipo de trabajo cuentan con los requisitos de rendimiento suficientes para soportar las aplicaciones de software descritas en la Tabla 11.

Tabla 11. Recursos principales de software.

Software Versión utilizada

Microsoft Office 2013

Visual Studio Community 2015

Sistema Operativo Windows 10 y

Windows 7

MongoDB 3.4

Visual Studio Account

Team Services


1.8.2 Factibilidad operativa

El estudio de la factibilidad operativa nos lleva a visualizar los recursos humanos necesarios durante el desarrollo, implementación e implantación del proyecto (Tabla 12). Inicialmente el proyecto cuenta con dos (2) recursos que se encargaran de diferentes tareas relacionadas con la parte técnica y operativa, incluyendo el levantamiento de requerimientos e historias de usuario, el desarrollo del proyecto, la realización de las pruebas, la documentación completa de las fases del desarrollo y las respectivas capacitaciones para los usuarios finales, ambos recursos son Ingenieros en Telemática especialistas y con gran experiencia en el desarrollo de

54

software y las tareas descritas. Adicionalmente, cuenta con un director de proyecto, el cual se encarga de dirigir y apoya técnica y administrativamente el proyecto, realizando las revisiones y aprobaciones correspondientes.

Tabla 12. Factibilidad operativa.

Recurso Descripción

Desarrollador 1 Mauricio Andrés Guerra Cubillos

Desarrollador 2 Erwin Hamid Pardo Quiroga

Tutor Roberto Emilio Salas Ruiz

Capacitaciones Mauricio Guerra – Erwin Pardo

Levantamiento de requerimientos Mauricio Guerra – Erwin Pardo

Documentación Mauricio Guerra – Erwin Pardo

Revisión y aprobación Roberto Emilio Salas Ruiz


1.8.3 Factibilidad económica

Cada uno de los recursos que son necesarios durante todo el proceso de desarrollo acarrean una serie de gastos y costos, por lo cual se hizo una estimación de estos para el proyecto en la Tabla 13, Tabla 14, Tabla 15 y Tabla 16 para finalmente presentar un consolidado en la Tabla 17 y su representación en la Grafica 2.

A continuación, se muestra un resumen por cada uno de los recursos y su estimación de costo:

Tabla 13. Factibilidad económica – Recursos humanos.

Recurso Descripción Valor-día Cantidad Total

Tutor Tutor y asesor del

desarrollo del proyecto

$50.000 63 $3’150.000

Desarrollador 1 Implementación del

proyecto $30.000 126 $3’780.000

Desarrollador 2 Implementación del

proyecto $30.000 126 $3’780.000

Total $10’710.000


55

Tabla 14. Factibilidad económica – Recursos de hardware.

Recurso Descripción Valor unitario Cantidad Total

Computadores de desarrollo

Equipos de escritorio para

el desarrollo del proyecto

$1’500.000 2 $3’000.000

Computadores de trabajo y pruebas

Equipos para pruebas de

aplicaciones y de red

$1’500.000 3 $4’500.000

Total $7’500.000


Tabla 15. Factibilidad económica – Recursos de software.


Microsoft Office Documentación $300.000 2 $600.00

Visual Studio IDE $0 2 $0

Sistema Operativo Entorno trabajo

y pruebas $200.000 Pack x3 $200.000

MongoDB Motor de base

de datos $0 3 $0

Visual Studio Account

Repositorio $0 2 $0

Total $800.000


Tabla 16. Factibilidad económica – Gastos adicionales.


Impresiones y papelería

Documentos, empastado y

anillado

$100.000

Transportes Transporte a

tutorías $48.000 mes 6 meses $280.000

Material extra

Gastos de materiales

imprevistos o extraordinarios.

$100.000

Internet Uso durante el

desarrollo $60.000 mes 6 meses $360.000

Total $840.000


56

Tabla 17. Factibilidad económica – Total recursos.

Recurso Valor

Recursos humanos $10’710.000

Recursos de hardware $7’500.000

Recursos de software $800.000

Recursos adicionales $840.000

Total $19’850.000


Gráfica 2. Porcentaje de recursos.


Parte de los objetivos del proyecto es lograr construir un sistema capaz de

almacenar enormes cantidades de información de manera más rápida, más óptima

y con altos niveles de disponibilidad y tolerancia a fallos, es de estos objetivos que

surgen los beneficios a obtener con el desarrollo de este proyecto y el cumplimiento

de la propuesta:

Beneficios tangibles:

o Reducción en los tiempos de almacenamiento, consulta y

manipulación de la información.

o Un porcentaje mayor en la disponibilidad de la información.

54%38%

4%4%

RECURSOS

Humanos Hardware Softwware Adicionales

57

o Reducción de los fallos y aumento en la confiabilidad de la

información.

o Respuestas en tiempo real del análisis de métricas de hardware de

equipos de cómputo.

Beneficios Intangibles:

o Información cifrada y almacenada de manera más segura.

o Escalabilidad de registro de métricas de hardware de equipos de

cómputo a manejo de diferentes tipos de información.

o Visualización de la información de manera más completa y correcta

mediante gráficos y reportes.

1.9 CRONOGRAMA

A continuación en la Figura 16 se muestra el cronograma de actividades planteado para el desarrollo completo del proyecto:

Figura 16. Cronograma de actividades.

Fuente: Gantt Project.

58

2 FASE DE EXPLORACIÓN.

En la fase de exploración se realiza la definición de las épicas del sistema, el lenguaje de programación de acuerdo a las tecnologías que solucionan los problemas tratados en esta monografía. Asimismo, se toma como parámetros los proyectos desarrollados y los años de experiencia en los lenguajes de programación a comparar.

2.1 ÉPICAS

Una de las actividades en la fase de exploración es definir a grandes rasgos las principales funcionalidades que el sistema tendrá, estas son conocidas como “las épicas”. En la siguiente figura (Figura 17) se pueden apreciar estas historias de alto nivel que en la siguiente fase se dividirán en historias de usuario más concretas y detalladas.

Figura 17. Épicas del sistema.


Como administrador del sistema, quiero que se capturen datos de los

sensores de hardware paraalmacenarlos y visualizarlos en

tiempo real.

Como administrador quiero que se guarden los datos de los sensores en

una base de datos, para realizar consultas posteriores.

Como administrador quiero que los datos de los sensores se envíen, para visualizarlos en tiempo real.

Como administrador quierovisualizar los datos en tiempo real, para monitorear los equipos de una

red.

59

Las épicas anteriores se encuentran ordenadas de forma secuencial conforme se vayan desarrollando en el transcurso del proyecto. Es claro que en este punto solo se ha identificado un rol (“administrador del sistema”), quien será el encargado de monitorear los equipos de una red, gracias a los datos que los sensores de estos envían en tiempo real.

2.2 DEFINICIÓN DE LENGUAJE DE PROGRAMACIÓN Y TECNOLOGÍAS DE DESARROLLO

Para la selección del lenguaje de programación se toma como indicador el número de años experiencia y proyectos realizados por los desarrolladores por cada lenguaje de programación utilizado. Esta información se puede ver en la siguiente tabla (Tabla 18).

Tabla 18. Proyectos desarrollados y años de experiencia por lenguaje de programación.

Lenguaje JAVA C#

Métrica / Desarrollador

Proyectos desarrollados

Años de experiencia

Proyectos desarrollados

Años de experiencia

Erwin Pardo 1 1 7 3

Mauricio Guerra 2 2 5 4

TOTAL 3 3 12 7 Fuente: Elaboración propia.

Se evidencia que existen más proyectos desarrollados y más años de experiencia para el lenguaje de programación C# comparando con los de JAVA, lo cual inclina la balanza al lenguaje de Microsoft. En las siguientes secciones se tratará de tecnologías que de los dos lenguajes relacionadas con los tres componentes a tratar: replicación de los datos, cifrado y envió en tiempo real.

Antes de describir las tecnologías se tiene que el producto final es una aplicación de escritorio, por tanto, se busca que exista total compatibilidad con la replicación, cifrado y envío en tiempo real de los reportes de hardware de los equipos conectados.

60

2.2.1 JAVA

Para el caso de JAVA se toma como referencia el artículo escrito por Dana Nourie que se encuentra en la documentación de Oracle, en el cual expone diversas tecnologías en aplicaciones de escritorio60.

La interfaz gráfica de usuario (GUI) en JAVA se puede crear con Java Foundation Classes/Swing (JFC/Swing) o Abstract Window Toolkit (AWT) API. Con estos dos paquetes se pueden crear botones, cajas de chequeo, cajas de texto, entre otros componentes que integran una aplicación de escritorio como se muestra en la Figura 18.

Figura 18. Componentes de texto en Java Swing.

Fuente: Using Text Components. Oracle. Java Documentation. Disponible en: https://docs.oracle.com/javase/tutorial/uiswing/components/text.html

Para la escritura y lectura de datos, java cuenta con el paquete java.io, que proporciona entrada y salida a de flujos de datos (data streams), serialización y sistemas de archivos. Específicamente para el manejo de archivos JAVA cuenta

60 NOURIE, Dana. Java Technologies in Desktop Applications. Oracle. 2006. Disponible en: http://www.oracle.com/technetwork/articles/java/new-tech-138589.html

http://www.oracle.com/technetwork/articles/java/new-tech-138589.html

61

con las clases FileInputStream y FileOutputStream que por medio de flujos de bytes enlazan los datos en los archivos.

Una aplicación de escritorio generalmente requiere almacenar y consultar una base de datos, para esto, JAVA cuenta con el API JDBC que provee una forma universal de acceder a los datos en bases de datos relacionales, hojas de cálculo y archivos planos.

Con respecto a la concurrencia de procesos JAVA provee el paquete java.util.concurrent y para la seguridad se cuenta con un conjunto de Apis con mecanismos, protocolos y algoritmos comúnmente usados, como firmas digitales, cifrado simétrico (que es de internes en esta monografía) y asimétrico, generación de claves y soporte de algoritmos como RSA, DSA, AES Triple DES, SHA, RC4, entre otros.

Por otra parte, Patrick Niemeyer y Jonathan Knudsen en su libro, describen otros API de JAVA, entre ellos, el API de Sockets y RMI. El primero permite el acceso a protocolos estándar de red usados en comunicaciones entre equipos. Estos sockets son una herramienta para de bajo nivel, ya que se deben implementar los mecanismos para el manejo e interpretación de los datos a nivel de aplicación. RMI (Remote Method Invocation) aprovecha la serialización de objetos, permitiendo trabajar con estos en máquinas remotas, de forma transparente tal como en una maquina local. Con esta tecnología, es fácil construir aplicaciones distribuidas donde clientes y servidores trabajan con datos en conjunto en lugar de flujos o paquetes de datos.

Figura 19. Clientes y Servidores. Sockets y ServerSockets.

Fuente: NIEMEYER, Patrick; KNUDSEN, Jonathan. Learning java. " O'Reilly Media, Inc.", 2005.

Los clientes pueden crear sockets para iniciar una conversación con el servidor, mientras que el servidor se encarga de escuchar las conexiones entrantes. Tal como se aprecia en la Figura 19, cada socket representa un lado en cliente y en el

62

servidor, mientras que el ServerSocket es la parte dentro del servidor encargada de escuchar y establecer las conexiones de los clientes61.

2.2.2 C#

Microsoft creo el lenguaje de C# y ha sido utilizado desde la versión 1.0, en la documentación oficial se listan dos formas de construir aplicaciones de escritorio, destacando en ambas el enlace de datos (data binding) como característica que beneficia el manejo y visualización de datos en la interfaz gráfica.

.NET Windows Forms, fue la primera tecnología para construir este tipo de aplicaciones y en algunos escenarios es más ligera que su predecesora, por lo que aún es utilizada en empresas de desarrollo de aplicaciones.

En segundo lugar, se encuentra WPF (Windows Presentation Foundation) que actualmente es la tecnología preferida para el desarrollo de aplicaciones de escritorio que requieren interfaces de usuario complejas, estilos personalizados y escenarios intensivos para gráficos. La principal diferencia con su antecesora, es que WPF usa XAML (Extensible Application Markup Language) que provee una forma declarativa de programar estas aplicaciones. Este lenguaje declarativo tiene como ventaja separar la interfaz de usuario y la logica de negocio, lo que ayuda a tener desarrolladores front-end dedicados a XAML y a desarrolladores back-end centrados en el lenguaje C#.

Figura 20. Fragmento de código XAML.

Fuente: XAML Overview (WPF). Microsoft Docs. 2017. https://docs.microsoft.com/en-us/dotnet/framework/wpf/advanced/xaml-overview-wpf

De la Figura 20 se puede apreciar cómo se puede crear un botón de forma declarativa, con un fondo azul y una fuente de color rojo con el texto "Click Me".

Para los flujos de datos y manejo de archivos, .Net Framework cuenta con el espacio de nombres System.IO que contiene clases para la lectura y escritura, tanto síncrona como de forma asíncrona para flujos, archivos, directorios y rutas. Este espacio de nombres (namespace) también cuenta con clases para leer y escribir en memoria, sockets, tubos anónimos y nombrados62.

ADO.NET es la tecnología principal de acceso a datos, mediante el espacio de nombres Sysytem.Data.SqlClient se accede a SQL Server y para acceder a otros

61 NIEMEYER, Patrick; KNUDSEN, Jonathan. Learning java. " O'Reilly Media, Inc.", 2005. 62 File and Stream I/O. Microsoft Docs. 2017. Disponible en: https://docs.microsoft.com/en-us/dotnet/standard/io/

https://docs.microsoft.com/en-us/dotnet/framework/wpf/advanced/xaml-overview-wpf

https://docs.microsoft.com/en-us/dotnet/framework/wpf/advanced/xaml-overview-wpf

https://docs.microsoft.com/en-us/dotnet/standard/io/

https://docs.microsoft.com/en-us/dotnet/standard/io/

63

motores de base de datos se puede utilizar System.Data.Odbc o System.Data.Oledb. Otra tecnología utilizada para la manipulación de dato es LINQ (Language-Integrated Query) es una forma de realizar consultas a cualquier origen de datos, desde un archivo de texto, una colección en memoria hasta una base de datos relacional, la particularidad es que todas las consultas se realizan desde el lenguaje C#.

Figura 21. Ejemplo de consulta con LINQ.

Fuente: Language Integrated Query (LINQ). Microsoft Docs. 2017. https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/concepts/linq/

El fragmento de código anterior (Figura 21), muestra cómo se utiliza linq para seleccionar los puntajes mayores a 80 de un arreglo de números enteros y luego imprimirlos por consola. Se puede notar una gran similitud con el lenguaje SQL utilizado en las bases de datos relacionales, por eso LINQ es considerado un lenguaje de consultas con código C#63.

En.Net Framework, existe una librería de tareas paralelas (Task Parallel Library) que utiliza el concepto de tarea como una operación asíncrona, de forma semejante como un subproceso pero a un nivel más abstracto. Según Microsoft es uso de tareas tiene dos ventajas: un uso eficaz y escalable de los recursos del sistema y un mayor control mediante programación del que se puede conseguir con un subproceso, por esto, el API TPL es el preferido para escribir código multiproceso, asíncrono y paralelo64.

63 Language Integrated Query (LINQ). Microsoft Docs. 2017. https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/concepts/linq/ 64 Programación asincrónica basada en tareas. Microsoft Docs. 2017. https://docs.microsoft.com/es-es/dotnet/standard/parallel-programming/task-based-asynchronous-programming

https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/concepts/linq/



https://docs.microsoft.com/es-es/dotnet/standard/parallel-programming/task-based-asynchronous-programming

https://docs.microsoft.com/es-es/dotnet/standard/parallel-programming/task-based-asynchronous-programming

64

Con respecto a la seguridad, .Net Framework proporciona numerosas implementaciones de algoritmos criptográficos estándar: AES, para privacidad y confidencialidad de los datos, SHA-256 y SHA-512 para la integridad de los datos, firmas digitales, intercambios de claves, entre otros65.

2.2.2.1 SignalR SignalR es una librería para desarrolladores .NET que simplifica el proceso de agregar funcionalidad en tiempo real a las aplicaciones web, de escritorio y móviles. Es utilizada en aplicaciones como por ejemplo dashboards, monitoreo de aplicaciones, aplicaciones de colaboración, actualizaciones de progreso y formularios en tiempo real. SignalR también se puede utilizar en aplicaciones que requieren actualizaciones de alta frecuencia, como los juegos en tiempo real.

SignalR proporciona un API para crear llamadas a procedimiento remoto (RPC) que llaman funciones de Javascript (y otras plataformas clientes como WPF) al servidor en código .NET. SignalR controla automáticamente la administración de conexiones y permite que enviar mensajes de broadcast a todos los clientes conectados al mismo tiempo, tal como ocurre en una sala de chat. Asimismo, cuenta con la característica que admite la funcionalidad conocida como “server push”, en el que el código del servidor puede llamar a código del cliente, mediante RPC en lugar del modelo solicitud-respuesta común hoy en día. Otra característica fundamental, es que SignalR es de código abierto y accesible a través de GitHub.

Figura 22. Vista física de la implementación de SignalR.


65 Modelo de criptografía de .NET Framework. Microsoft Docs. 2017. https://docs.microsoft.com/es-es/dotnet/standard/security/cryptography-model

https://docs.microsoft.com/es-es/dotnet/standard/security/cryptography-model

https://docs.microsoft.com/es-es/dotnet/standard/security/cryptography-model

65

La Figura 22 es una vista física de los componentes cuando se implementa SignalR. En la izquierda y derecha está los equipos clientes, y en el centro se encuentra es servidor que se encarga de las conexiones. SignalR usa WebSockets cuando estos estén disponibles, sino, regresa a otros transportes únicamente cuando es necesario. Tiene implementado el concepto de “fall back”. Una conexión en SignalR se inicia como HTTP y a continuación, se promueve una conexión con WebSockets si está disponible. Esta conexión hace más eficaz el uso de la memoria del servidor, tiene la latencia más baja y comunicación full dúplex entre cliente y servidor.

2.2.3 ACUERDO DEFINITIVO

Después de explorar las características de los dos lenguajes descritos en las secciones anteriores y teniendo en cuenta las épicas definidas se acordó desarrollar esta monografía con el lenguaje de Microsoft. Esta inclinación por el lenguaje C# se da, por la cantidad de proyectos construidos y los años de experiencia desarrollando aplicaciones para este lenguaje de programación. Otro aspecto que influyó en la decisión fue el patrón de diseño MVVM tratado en el marco teórico, el cual posee como característica el enlace de datos (binding) lo que permite a los desarrolladores no preocuparse por la actualización de la vista, sino por el modelo y lógica de negocio. Por ultimo como se busca visualizar los reportes en tiempo real, el framework SignalR se ajusta perfectamente a lo requerido, a diferencia de los sockets en JAVA, de tal forma que permite implementar conexiones a nivel de aplicación por medio de HTTP, sin que los desarrolladores se preocupen por las capas inferiores del modelo OSI.

A continuación se describen otras características que se deben tener en cuenta para dar solución al problema planteado, como lo son la conexión con MongoDB y el cifrado simétrico AES.

2.2.3.1 AES en C# Para el cifrado en este lenguaje de programación se utiliza el espacio de nombres System.Security.Cryptography. El cual proporciona servicios criptográficos, codificación y decodificación segura de datos, hashing, generación de números aleatorios y autentificación. Dentro de este espacio de nombre se encuentra la clase Aes y se instancia como se muestra en la siguiente imagen (Figura 23)66.

66 System.Security.Cryptography Namespace. Microsoft Docs. Disponible en: https://msdn.microsoft.com/en-us/library/system.security.cryptography(v=vs.110).aspx

https://msdn.microsoft.com/en-us/library/system.security.cryptography(v=vs.110).aspx

66

Figura 23. Aes en C#.

Fuente: Aes Class. Microsoft Docs. Disponible en: https://msdn.microsoft.com/en-us/library/system.security.cryptography.aes(v=vs.110).aspx

En la Figura 23 se aprecia la creación de dos objetos de la clase AES y se diferencian por la longitud de la clave de 128 bits y 256 bits. En la siguiente imagen (Figura 24), se muestra el código fuente para cifrar un texto mediante el estándar AES.

Figura 24. Cifrar texto en C# con AES.

Fuente: Aes Class. Microsoft Docs. Disponible en: https://msdn.microsoft.com/en-us/library/system.security.cryptography.aes(v=vs.110).aspx

Del anterior código fuente se distingue inicialmente que el parámetro “textoEnClaro” se valida de tal forma que exista y tenga una longitud de al menos un carácter. Luego se convierte en un arreglo de bytes teniendo en cuenta la codificación UTF-8 para cifrarlos y por último los bytes cifrados se convierten en una cadena de texto en base 64.

https://msdn.microsoft.com/en-us/library/system.security.cryptography.aes(v=vs.110).aspx




67

Figura 25. Arreglo de bytes a Base64.

Fuente: Convert.ToBase64String Method. Microsoft Docs. Disponible en: https://msdn.microsoft.com/en-us/library/dhx0d524(v=vs.110).aspx

El anterior código (Figura 25), tomado de la documentación oficial de Microsoft muestra la conversión de un arreglo de bytes a una cadena en base64 y viceversa.

La ventaja de utilizar esta codificación es que genera cadenas de caracteres ASCII imprimibles, con ello estamos seguros que los datos en esta codificación no tendrán problemas para su transmisión, lectura o almacenamiento. El resultado del código anterior es el que se evidencia en la Figura 26:

Figura 26. Cadena en Base64.

Fuente: Convert.ToBase64String Method. Microsoft Docs. Disponible en: https://msdn.microsoft.com/en-us/library/dhx0d524(v=vs.110).aspx

Esta codificación es muy usada para la transmisión de imágenes, audios, videos sobre una red telemática; está compuesta de 64 caracteres de letras y números (Tabla 19), finalmente un carácter de relleno (=). La definición se encuentra en el RFC 4648 de Simon Josefsson67.

67 JOSEFSSON, Simon. The base16, base32, and base64 data encodings. 2006. RFC 4648. Disponible en: https://www.ietf.org/rfc/rfc4648.txt

https://msdn.microsoft.com/en-us/library/dhx0d524(v=vs.110).aspx

https://msdn.microsoft.com/en-us/library/dhx0d524(v=vs.110).aspx

https://www.ietf.org/rfc/rfc4648.txt

68

Tabla 19. Caracteres utilizados en Base64.

# Carácter # Carácter # Carácter # Carácter

0 A 17 R 34 i 51 z

1 B 18 S 35 j 52 0

2 C 19 T 36 k 53 1

3 D 20 U 37 l 54 2

4 E 21 V 38 m 55 3

5 F 22 W 39 n 56 4

6 G 23 X 40 o 57 5

7 H 24 Y 41 p 58 6

8 I 25 Z 42 q 59 7

9 J 26 a 43 r 60 8

10 K 27 b 44 s 61 9

11 L 28 c 45 t 62 +

12 M 29 d 46 u 63 /

13 N 30 e 47 v

14 O 31 f 48 w (pad) =

15 P 32 g 49 x

16 Q 33 h 50 y

Fuente: JOSEFSSON, Simon. The base16, base32, and base64 data encodings. 2006. RFC 4648. Disponible en: https://www.ietf.org/rfc/rfc4648.txt

2.2.3.2 MongoDB en C# El controlador oficial de MongoDB para C#/.Net proporciona interacción asíncrona con MongoDB, una biblioteca Core y compatibilidad con BSON para la serialización de objetos. Para el desarrollo de esta monografía se utiliza la versión 2.5.0 del driver, el cual se puede agregar por medio de los siguientes paquetes Nuget (Figura 27).

Figura 27. Paquetes de MongoDB en C#.

Fuente: MongoDB .NET Driver. MongoDB Documentation. Disponible en: http://mongodb.github.io/mongo-csharp-driver/?jmp=docs

Así mismo en la documentación oficial de MongoDB, muestran fragmentos de código para el uso del driver para el lenguaje de programación seleccionado. En la

69

siguiente imagen (Figura 28) se muestran tres formas de conexión a la base de datos.

Figura 28. Conexión con MongoDB desde C#.

Fuente: MongoDB Driver Quick Tour. MongoDB Documentation. Disponible en: http://mongodb.github.io/mongo-csharp-driver/2.5/getting_started/quick_tour/

La instancia cliente contiene un pool de conexiones al servidor o servidores (replica) especificados en la cadena de conexión. Como ventaja de realizar una instancia de la clase MongoClient es que se tiene un pool de conexión incluso con múltiples hilos68.

Para la conexión con una base de datos en específico, se utiliza el método GetDatabase. Si la base de datos no existe, esta se creará. Recordando que en MongoDB no existen tablas, sino colecciones que se pueden acceder desde el objeto database con el método GetCollection especificando el nombre de la colección y al igual que ocurre con la base de datos, si la colección no existe, se creará sin que genere error y con el mismo método se accederá en futuras invocaciones. En la Figura 29 está la implementación de los métodos nombrados, donde se accede a la colección “myCollection” de la base de datos “myDB”. Para obtener todos los documentos de una colección se utiliza el método ToList o ToListAsync.

Figura 29. Acceso a una colección de MongoDB desde C#.

Fuente: MongoDB Driver Quick Tour. MongoDB Documentation. Disponible en: http://mongodb.github.io/mongo-csharp-driver/2.5/getting_started/quick_tour/

Con respecto a la compatibilidad del driver con las versiones de MongoDB, se encuentra la siguiente tabla (Tabla 20) donde se especifica las versiones recomendadas del driver C#/.NET para las versiones de la base de datos.

68 MongoDB Driver Quick Tour. MongoDB Documentation. Disponible en: http://mongodb.github.io/mongo-csharp-driver/2.5/getting_started/quick_tour/

70

Tabla 20. Compatibilidad del driver C#/.NET para MongoDB.

C#/.NET Driver

MongoDB 2.6

MongoDB 3.0

MongoDB 3.2

MongoDB 3.4

MongoDB 3.6

Versión 2.5 ✓ ✓ ✓ ✓ ✓

Versión 2.4 ✓ ✓ ✓ ✓

Versión 2.3 ✓ ✓ ✓

Fuente: C# and .NET MongoDB Driver. MongoDB Documentation. Disponible en: https://docs.mongodb.com/ecosystem/drivers/csharp/

Para esta monografía se utilizará la versión 2.5 del driver C#/.NET que posee compatibilidad para las últimas versiones de las bases de datos MongoDB incluida la versión 3.6. Asimismo, es totalmente compatible con la versión 4.5 de .NET Framework, .Net Core 1, 1.1 y 2.069.

2.2.3.3 Visual Studio El IDE (Entorno de Desarrollo Integrado) a utilizar es Visual Studio en la versión Community de 2015. Este IDE es compatible con los sistemas operativos Windows y MAC y permite la edición y depuración de código para aplicaciones en Android, iOS, Windows y en la nube. Microsoft Visual Studio 2015 es un conjunto de herramientas para crear software, desde la fases de diseño de la interfaz de usuario, codificación, pruebas, depuración, análisis de la calidad y el rendimiento del código, y recopilación de telemetría de uso. Estas herramientas están diseñadas para trabajar juntas de la forma más eficiente70.

En este IDE se pueden crear:

Aplicaciones y juegos que se ejecutan no solo en Windows, sino también en Android y en iOS.

Sitios web y servicios web basados en ASP.NET, JQuery, AngularJS y otros entornos populares.

Aplicaciones para dispositivos y plataformas tan diversas como Azure, Office, Sharepoint, Hololens, Kinect e Internet de las cosas, por nombrar solo algunos ejemplos.

Juegos y aplicaciones con gráficos avanzados para una variedad de dispositivos Windows, incluido Xbox, con Direct.

69 C# and .NET MongoDB Driver. MongoDB Documentation. Disponible en: https://docs.mongodb.com/ecosystem/drivers/csharp/ 70 IDE de Visual Studio. Microsoft Docs. https://msdn.microsoft.com/library/dn762121(v=vs.140).aspx

71

Figura 30. Principales componentes de Visual Studio.

Fuente: IDE de Visual Studio. Microsoft Docs. https://msdn.microsoft.com/library/dn762121(v=vs.140).aspx

De forma predeterminada Visual Studio, proporciona compatibilidad con C#, C, C++, Javascript, F# y Visual Basic. La versión Community es gratuita con todas las características para estudiantes, desarrolladores de código abierto y desarrolladores individuales. En la imagen anterior (Figura 30) se pueden identificar los principales componentes del IDE como la ventana de explorador de soluciones para tener acceso a todos los archivos de la solución.

Visual Studio permite conectarse a VSTS (Visual Studio Team Services) que es un servicio en la nube para hospedar proyectos de software y que permite la colaboración en los equipos. También, admite los sistemas de control de versiones como Git y Team Foundation, así como metodologías de desarrollo: Scrum, CMMI y Agile. En la Figura 31 se muestra el panel de Team Explorer de Visual Studio.

https://msdn.microsoft.com/library/dn762121(v=vs.140).aspx

72

Figura 31. Team Explorer en Visual Studio.

Fuente: IDE de Visual Studio. Microsoft Docs. https://msdn.microsoft.com/library/dn762121(v=vs.140).aspx

2.2.3.4 Vista Física En la siguiente imagen (Figura 32) está representada la vista física de la solución a desarrollar. En la izquierda se encuentran los emisores quienes comparten conexión con los administradores en la derecha. Por medio de los enlaces punteados, se representa la conexión a través de un servidor en tiempo real, es decir el envío de reportes de los sensores y datos del hardware de los emisores a los administradores, mientras que, con las líneas continuas se representa la conexión con la base de datos que se encuentra en la parte inferior en replica en tres nodos adicionales.

https://msdn.microsoft.com/library/dn762121(v=vs.140).aspx

73

Figura 32. Vista física de conexiones.


2.2.3.5 Entidades del dominio Las entidades del dominio son los objetos y funcionalidades más relevantes del negocio y problema a tratar. En este caso un reporte está compuesto de sensores y datos del hardware instalado en la tarjeta madre o board, procesador, memoria de acceso aleatorio y discos duros de los emisores. Luego de cifrar el reporte con los datos del hardware, se envían en tiempo real a los administradores que realiza el descifrado y por medio de un servidor intermediario se visualizan los datos en un tablero o dashboard.

Las entidades del dominio que se encontraron se encuentran en el siguiente diagrama (Figura 33), las cuales se utilizarán para la definición de diagramas de flujo y la construcción de historias de usuario en la fase de planeación.

74

Figura 33. Entidades de dominio.


75

3 FASE DE PLANEACIÓN.

En la fase de planeación se describe el modelo de capas a implementar en el desarrollo de software para toda la solución. Asimismo, se muestran los diagramas de flujo y casos de uso más relevantes. Para la documentación de los mismos y de los requerimientos funcionales y no funcionales como la disponibilidad y replicación de los datos se usan las historias de usuario de acuerdo al formato definido en el marco teórico. Posteriormente, se determinan los sensores de hardware que contendrán los reportes que los emisores enviarán en tiempo real. Por último se realiza un estudio del alcance del proyecto y las delimitaciones que se presentan para el desarrollo de este.

3.1 MODELO DE CAPAS

En el desarrollo de software se definió un modelo de capas, que permita el trabajo en equipo y facilite la modularidad y reutilización de componentes. Este pódelo está compuesto por una capa Transversal y una pila de tres capas: Acceso a Datos, Lógica de Negocio y Presentación. Esta última es compartida por las tres aplicaciones a desarrollar. El modelo se muestra a continuación en la Figura 34.

Figura 34. Modelo de capas.


En la gráfica se ilustra el modelo de capas a implementar durante el desarrollo de software, este modelo cuenta con las capas:

Transversal. Esta capa es transversal a toda la solución, como se muestra en el diagrama es una capa vertical y de acceso común a las demás capas

76

del modelo. Aquí se sitúan las entidades del negocio que se instancian en las demás capas y aplicaciones.

Presentación. Es la capa que cuenta con todos los formularios y pantallas que permiten al usuario la interacción con las tres aplicaciones (Emisor, Servidor, Administrador), la ventaja de tener esta capa es que contiene formularios comunes de las aplicaciones, como el acceso al sistema (login), lo que evita la redundancia de componentes de la interfaz gráfica.

Negocio. Contiene las funcionalidades de todas las aplicaciones y la lógica de negocio, por tanto, es la capa intermediaria entre los datos y las interacciones de los usuarios. Esta capa también encapsula los subprocesos y el flujo de un proceso de negocio que ocurre con la acción del usuario en la capa superior. Asimismo, es la capa que realiza las acciones a la capa de acceso y posterior a ello, actualiza la información de la capa de presentación.

Datos. Es la capa que accede al replica set de MongoDB, por tanto, se ocupa de realizar consultas, actualizaciones e inserciones a la base de datos, de tal forma que abstrae la lógica para que sea transparente para la capa de negocio la base de datos y su implementación en toda la aplicación, lo que permite que sea más fácil de configurar y mantener.

3.2 DIAGRAMAS DE FLUJO Y CASOS DE USO

Para identificar las entidades, procesos, funcionalidades e interacciones de los usuarios se definieron los siguientes diagramas de flujo y casos de uso. Representan las principales acciones dentro de las aplicaciones: Emisor, Administrador y Servidor. En primer lugar se encuentra el diagrama de flujo de la conexión al servidor desde el Emisor (Figura 35 y Figura 36). Este proceso inicia de forma automática, es decir, no requiere de una interacción por parte de algún usuario, de tal forma, que cuando la aplicación inicia o se ejecuta se realiza el siguiente flujo.

1. Inicialmente se lee el archivo de configuración “config.json”, el cual contendrá los datos de conexión con el servidor y la base de datos.

2. Una vez se tengan estos, se procede a validar la disponibilidad del servidor, es decir que el servidor responda a una petición http. Si este responde con un estado 200, es decir “OK”, se valida la licencia del equipo.

3. En la validación de la licencia, se verifica que el equipo tenga una licencia vigente y que se encuentre en la base de datos. Si el resultado es positivo se sigue con la conexión al servidor.

4. En la conexión se envían al servidor datos de conexión y es el servidor el responsable de aceptar la nueva conexión.

77

Figura 35. Conexión al servidor (Emisor).

Fuente: Elaboración Propia

78

Figura 36. Conexión al servidor (Administrador).


79

La principal diferencia de los diagramas anteriores hace referencia a la interacción del usuario. Mientras que en el Emisor la conexión con el servidor es de forma automática, en la aplicación Administrador se requiere que el usuario inicie sesión. Una vez se valide que el usuario ha sido autenticado en el sistema, se procede con la conexión al servidor y por último, se direcciona al dashboard para tener una visión general del estado de todos los emisores conectados (Figura 37).

Figura 37. Enviar reporte.


Uno de los procesos relacionados directamente con las Épicas, definidas en la

fase anterior, es el envío de los reportes desde los emisores para ser vistos por los

administradores.

80

1. El flujo de este proceso, parte por el proceso Conexión al servidor, descrito en

anteriormente.

2. Si la conexión es de forma correcta, se inicia el temporizador que cada cierto

tiempo ejecutará las siguientes tareas:

2.1. Conformar el reporte con las métricas de hardware capturadas en ese

instante de tiempo.

2.2. Cifrar el reporte con el estándar AES.

2.3. Registrar el reporte en la base de datos para su posterior consulta.

3. Luego, se envía el reporte cifrado al servidor, quien se encarga de distribuirlo y

direccionarlo a los administradores que estén conectados.

4. Cuando el reporte es recibido por el Administrador, se realiza el proceso de

descifrado.

5. Finalmente, el reporte descifrado se muestra en pantalla actualizando valores

del reporte anterior.

Para los diagramas de casos de uso se tomaron las interacciones más relevantes

que el usuario administrador realizará. Uno de los subsistemas que existirá en la

aplicación Administrador es la sección de gestión de los emisores como se

muestra en la Figura 38. Allí, el rol administrador puede agregar, editar, eliminar y

generar archivos de configuración. Para esta última acción, se tiene como salida el

archivo “config.json”, necesario para la conexión con el servidor, como se mostró

anteriormente.

Figura 38. Gestión de emisores.


81

El otro subsistema está relacionado con la gestión de usuarios, es decir, a la

creación, edición y eliminación de los usuarios administradores que tendrán

acceso a los reportes en tiempo real de los emisores conectados (Figura 39).

Figura 39. Gestión de usuarios.


Para la definición, descripción y documentación de los requerimientos funcionales

y no funcionales se describen en la siguiente sección por medio de una técnica

usada en metodologías agiles, las historias de usuario.

3.3 HISTORIAS DE USUARIO

En el marco teórico se definió la estructura que tendrán las historias de usuario, en esta sección se toma ese modelo para registrar los requerimientos de la solución que se plantea en las tres aplicaciones.

El Anexo A., contiene la definición de las historias de usuario siguiendo la estructura definida, a continuación se muestran algunos ejemplos de las historias de usuario más relevantes de acuerdo a los diagramas de flujo y casos de uso de la sección anterior.

82

Tabla 21. Historia de usuario: Tiempo de espera entre reportes (HU-002).

NOMBRE: Tiempo de espera entre reportes.

ID: HU-002

PRIORIDAD: 5

ESTIMACIÓN: 16

VERSIÓN: 1.0

DESCRIPCIÓN: Como administrador quiero configurar el tiempo en segundos que debe esperar la aplicación de captura para enviar un nuevo reporte.


El tiempo no puede ser global para todos los equipos.

El tiempo debe configurarse en cada equipo.

El tiempo mínimo permitido es 30seg y el

máximo es 300seg (5min).

PROTOTIPO:


La historia de usuario HU-002, hace referencia al tiempo que debe esperar la aplicación Emisor para enviar un reporte cifrado en tiempo real y luego ser visualizado por los Administradores conectados.

Esta historia de usuario pertenece al diagrama de flujo “Enviar reporte”, donde se debe inicializar el temporizador para que cada vez que se cumpla el tiempo en segundos definido, el Emisor captura, cifra y envía el reporte al servidor. Como restricciones y criterios de aceptación de la historia, se tiene que este tiempo debe ser personalizado para cada equipo y el tiempo mínimo es de 30 segundos, así como, 300 segundos como el tiempo de espera máximo para enviar un reporte. Como primer prototipo se define un variable en un archivo de configuración que el administrador puede cambiar.

83

Tabla 22. Historia de usuario: Almacenamiento de datos (HU-006).

NOMBRE: Almacenamiento de datos.

ID: HU-006

PRIORIDAD: 10

ESTIMACIÓN: 200

VERSIÓN: 1.0

DESCRIPCIÓN: Como administrador del sistema, quiero almacenar la información con un sistema de replicación de datos que me permita consistencia y disponibilidad los datos.


Al guardar la información, esta debe quedar

almacenada en varios nodos.

Debo poder acceder a la información desde

cualquier aplicación (Emisor, Administrador y

Servidor).

Si el lugar principal donde guardo y consulto la

información falla, debe poderse acceder al

respaldo inmediatamente y no se debe ver

afectada la integridad ni el rendimiento de la

aplicación.

PROTOTIPO: Modelo de replicación MongoDB Fuente: Elaboración Propia

Uno de los problemas principales que se tratan en esta monografía, es la centralización de los datos, sin replicación de los datos, lo que afecta directamente la disponibilidad de los datos. Para ello se requiere que estos, estén distribuidos en una base de datos que implemente replicación. Este requerimiento no funcional, está registrado en la historia de usuario HU-006 la cual tiene el valor más alto en prioridad y estimación. Como condición se tiene que deben existir múltiples nodos donde se almacene la información, de tal forma que si el nodo principal falla uno de los demás nodos debe suplir la función del nodo principal, siendo transparente para el usuario la falla ocurrida. El prototipo a generar es un replica-set en MongoDB.

Para la gestión de emisores, como se denota en el diagrama de caso de uso con el mismo nombre, se tiene que uno de los casos que el Administrador puede realizar es la generación del archivo de configuración. Esta definición y descripción la tiene la historia de usuario HU-011, en la que se específica en los criterios de aceptación que debe abrirse un cuadro de dialogo donde el usuario escoja la ruta donde desea almacenar dicho archivo. Otro criterio trata sobre el nombre, el cual debe ser “config.json” y como prototipo se tiene representado una pantalla de visualmente es mucho más fácil de interpretar.

84

Tabla 23. Historia de usuario: Generación del archivo de configuración (HU-011).

NOMBRE: Generación del archivo de configuración.

ID: HU-011

PRIORIDAD: 8

ESTIMACIÓN: 20

VERSIÓN: 1.0

DESCRIPCIÓN:

Como administrador del sistema, quiero generar el archivo de configuración para que un emisor pueda generar, cifrar y enviar de forma correcta los reportes de hardware.


Debe abrirse un cuadro de dialogo, donde se

seleccione la ruta a almacenar el archivo.

El archivo debe tener la configuración necesaria

con los datos actualizados del emisor.

El archivo debe llamarse “config.json”.

PROTOTIPO:

Fuente: Elaboración Propia.

Las demás historias de usuario están definidas en el Anexo A., las cuales se desarrollarán a detalle en la fase de iteraciones.

85

3.4 SENSORES A MONITOREAR

Una vez se ha realizado el dimensionamiento de alto nivel mediante los diagramas de flujo, casos de uso e historias de usuario; es necesario, definir los sensores a los que se les realizará monitoreo, es decir, las métricas de hardware a capturar y enviar en tiempo real.

Inicialmente se tiene la placa madre, de la cual se obtiene el fabricante, modelo, versión, cantidad de ranuras libres y ocupadas por las memorias RAM instaladas en el equipo.

Figura 40. Métricas y datos a reportar de la placa madre.

Fuente: Elaboración Propia. Icono creado por Andrea Rizzato71.The Noun Project.

Del sistema básico de entrada y salida (BIOS) se capturan el fabricante y la versión. Este último es un dato muy importante para futuras actualizaciones y compatibilidades con hardware y software a instalar.

Figura 41. Métricas y datos a reportar del BIOS.

Fuente: Elaboración Propia. Icono creado por Arthur Shlain 72.The Noun Project.

De la memoria RAM, se captura el porcentaje de uso, la memoria libre y utilizada en Gigabytes (GB).

71 RIZZATO, Andrea. Motherboard. https://thenounproject.com/term/motherboard/494047/ 72 SHLAIN, Arthur. Integrated circuit. https://thenounproject.com/term/semiconductor/249952/

Placa madre (Main board)

• Fabricante.

• Modelo.

• Version.

• Cantidad de ranuras RAM libres / ocupadas.

Sistema básico de entrada -salida (BIOS)

• Fabricante.

• Versión.

https://thenounproject.com/term/motherboard/494047/

https://thenounproject.com/term/semiconductor/249952/

86

Figura 42. Métricas y datos a reportar de la RAM.


Para el procesador se tienen más datos, entre ellos, el fabricante, versión, cantidad de núcleos e hilos para el multiprocesamiento. Asimismo, se captura el porcentaje de uso de cada núcleo y del procesador en general, la temperatura de cada uno de los núcleos y porcentaje de uso utilizado en procesos gráficos.

Figura 43. Métricas y datos a reportar del procesador.


Para los discos duros y de estado sólido se captura el nombre, la temperatura del disco y porcentaje de espació utilizado.

73 ALP, Mahmure. RAM. https://thenounproject.com/search/?q=ram&i=902070 74 SHLAIN, Arthur. CPU. https://thenounproject.com/term/cpu/86215/

Memoria de acceso aleatorio (RAM)

• Uso de RAM.

• RAM utilizada.

• RAM libre.

Procesador (CPU)

• Fabricante.

• Versión.

• Núcleos.

• Hilos.

• Uso de CPU.

• Uso del núcleo.

• Temperatura de CPU.

• Temperatura del núcleo.

• Uso de gráficos.

https://thenounproject.com/search/?q=ram&i=902070

https://thenounproject.com/term/cpu/86215/

87

Figura 44. Métricas y datos a reportar de los discos duros o de estado sólido.


Para los equipos que cuenten con al menos una tarjeta de video, se reporta el nombre, el porcentaje de uso, la temperatura y el voltaje en el que se encuentra operando.

Figura 45. Métricas y datos a reportar de las tarjetas de video.


En el Anexo B, se tiene una tabla con los datos de un equipo de cómputo con sistema operativo Windows 7, denotando el tipo de dato y la salida que la librería OpenHardwareMonitor proporciona para los sensores definidos en esta sección.

75 KAITO, Bakunetsu. Hard disk. https://thenounproject.com/term/hard-disk/843962/ 76 PETRISHCHEV, Misha. GPU. https://thenounproject.com/mishapetrishchev/collection/gpu/?i=1132942

Disco de almacenamiento (HDD o SDD)

• Nombre del disco.

• Temperatura del disco.

• Espacio usado.

Tarjeta de video (GPU)

• Nombre de la tarjeta.

• Uso de la GPU.

• Temperatura de la GPU.

• Voltaje de la GPU.

https://thenounproject.com/term/hard-disk/843962/

https://thenounproject.com/mishapetrishchev/collection/gpu/?i=1132942

88

4 FASE DE ITERACIONES.

4.1 ITERACIÓN 1: CAPTURA DE DATOS

El nombre de esta iteración hace referencia a los datos que los sensores del hardware proporcionan, que se capturan con la librería Openhardwaremonitor. Además, en esta iteración se realiza una evaluación del cifrado AES, teniendo en cuenta dos longitudes para la llave de cifrado: AES-128 y AES-256.

Los componentes de un equipo de cómputo a lo que se le realizará la captura de datos son: la placa madre (mainboard), la memoria de acceso aleatorio (RAM), la unidad central de procesamiento (CPU), la unidad de procesamiento gráfico (GPU) y las unidades de almacenamiento (HDD y/o SSD).

En esta iteración se desarrollarán las siguientes historias de usuario con relación a la aplicación que realiza la captura de datos (Emisor).

Ejecución automática después del arranque del sistema operativo (HU-001 V.1.0).

Tiempo de espera entre reportes (HU-002 V.1.0).

Acceso a la aplicación de captura de datos (HU-003 V.1.0).

Icono de notificación (HU-004 V.1.0).

Minimizar al cerrar (HU-005 V.1.0).

Con respecto al cifrado de datos se tratarán las siguientes historias de usuario.

4.1.1 Desarrollo de la historia de usuario HU-001.

En Windows existe una forma de ejecutar programas después que el sistema operativo a iniciado. La forma gráfica de acceder es Inicio > Todos los programas > Click derecho en la carpeta Inicio.

89

Figura 46. Ejecutar un programa al inicio en Windows 7.

Fuente: Sistema operativo Windows 7.

Debido a que la historia de usuario no especifica si la aplicación debe iniciar para un usuario en específico, se realizó la investigación de tal forma que se inicie para todos los usuarios o para un usuario determinado. En el menú contextual se encuentran las opciones “Abrir” y “Explorar” que abren una carpeta para el usuario (en este caso es el usuario “WAR”) que ha iniciado sesión, la ruta de la carpeta es:

C:\Users\WAR\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup

Mientras que las opciones “Abrir todos los usuarios” y “Explorar todos los usuarios” abren la carpeta donde se ubican los programas que ejecutarán para todos los usuarios que inicien sesión en el equipo. La ruta es:

C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup

90

Otra forma de acceder a estas carpetas es con los siguientes comandos. Estos se pueden digitar desde: Inicio > Ejecutar; otra opción es con la combinación de teclas (Windows + R).

Figura 47. Ejecución del comando shell:startup.


shell:startup: Abre la carpeta donde se ejecutarán los programas (luego del arranque del sistema operativo) para el usuario que ha iniciado sesión.

shell:common startup: Abre la carpeta de se ubican los programan que se ejecutarán para todos los usuarios que inicien sesión.

Una vez se tenga definido si la aplicación se ejecutará para todos los usuario o para uno en específico, el segundo paso es copiar y pegar el acceso directo de la aplicación que capturará los datos (Emisor) en la carpeta elegida.

Figura 48. Aplicación al inicio.


En la imagen se aprecia el acceso directo a nuestra aplicación Emisor. La ventaja que Windows aporta con el acceso directo, es que si se realiza una actualización al ejecutable no se requiere repetir los pasos anteriores, ya que este acceso hace referencia a la ruta de la aplicación, por lo que es muy útil para las próximas iteraciones y modificaciones en el software.

Versión nueva a la historia 001.

91


Esta historia hace referencia al tiempo de espera para el envío de reportes, como lo indican los criterios de aceptación de la historia de usuario el tiempo no puede ser global, sino que debe ser configurado para cada equipo. Como solución propuesta se tendrá un archivo de configuración en formato JSON, el cual estará almacenado en una carpeta llamada “Config”, ubicada en la misma ruta de la aplicación Emisor.

Figura 49. Carpeta de configuración.


En la carpeta estará alojado el archivo “config.json”, que tiene el tiempo de espera como se aprecia en la siguiente imagen.

Figura 50. Tiempo de espera en archivo de configuración.


En la aplicación Emisor, se ejecutará una función que buscará el archivo de configuración y deserializará el JSON en un objeto de tipo “ConfigCliente”.

Figura 51. Leer archivo de configuración.


92

En la Figura 52 se encuentra el código fuente utilizado para leer el archivo de configuración en caso de que este exista, de lo contrario, se lanzará una excepción indicando que no se encontró el archivo de configuración. Claramente el objeto configCliente tendrá un atributo “TiempoEspera” donde se almacenará el dato que se encuentra en el archivo config.json.

Figura 52. Iniciar captura.


En la imagen anterior se establece un temporizador que realizará la captura de un reporte cada “tiempoEspera” en segundos como lo indica la historia de usuario.


La aplicación Emisor tendrá un login para restringir el acceso de los datos que se despliegan.

Figura 53. Inicio de sesión.


El nombre de usuario permite hasta 15 caracteres, mientras que el campo de contraseña permite hasta 25 caracteres para contraseñas más seguras. Una vez la aplicación inicia, visualmente se muestra el formulario de la imagen anterior,

93

aunque, no se requiere iniciar sesión para que la aplicación capture y envíe reportes en tiempo real.

Las contraseñas estarán cifradas con el estándar AES. En las pruebas realizadas en esta iteración que se explican más adelante, se concluyó que el estándar a implementar para cifrar los reportes es el estándar AES256, el cual también será utilizado para el cifrado y descifrado de las contraseñas del usuario administrador.

En la siguiente imagen (Figura 54) se ilustra el proceso de cifrado AES256 en modo CBC y padding PKCS7, para el texto “miContraseña” con una clave “5c47b4f43f44da14961b8101d359b3a4” y un vector de inicialización con el valor de “961b8101d359b3a4”, dando como resultado el texto “6GOO+KNG4sLWV1sQWU9z8g==” codificado en base64.

Figura 54. Cifrado AES 256 en CrypTool 2.

Fuente: CrypTool 2. Disponible en: https://www.cryptool.org/en/cryptool2

Un estudio que realizamos para determinar si se implementaría cifrado AES128 y AES256, consistió en primer lugar la captura de los datos que los sensores de hardware arrojan, luego se serializaron estos datos y en tercer lugar se cifraron.

Cuando se tiene una aplicación en tiempo real, se busca que los datos lleguen a su destino en el menor tiempo posible, de tal forma que se requiere eficiencia en la transmisión, para ello los datos deben tener el menor número de bytes como sea posible y con la capacidad del canal se consiga una mayor tasa de transferencia de estos datos.

Por lo anterior, se realizó un estudio de dos tipos de lenguajes de marcado o también conocidos como formatos de intercambio de datos, que para los computadores sea

94

fácil de interpretar y para las personas sea fácil de leer y escribir. Los dos formatos que se trataron fueron XML y JSON.

En la siguiente imagen (Figura 55) se puede apreciar un ejemplo de los datos serializados en XML (izquierda) y a la derecha en JSON. Debido a que los datos no se encuentran cifrados, los llamaremos: "Reporte XML en claro" y "Reporte JSON en claro" respectivamente.

Figura 55. Fragmento de un reporte serializado en XML (izquierda) y en JSON (derecha).


Como se puede apreciar XML, es más estructurado por ello es sumamente estricto, pero por otro lado, para algunas personas suele ser más cómodo de comprender. Al observar el reporte en JSON notamos que es mucho más simple, tiene menos símbolos, pero si es la primera vez que se observa un objeto serializado en este formato puede ser más difícil de interpretar. Dentro de las ventajas de JSON frente a XML es que los archivos son de menor tamaño, por tanto, los objetos serializados tienen un menor tamaño lo cual para nuestro proyecto es sumamente importante ya que se busca en lo posible un número menor de bytes serializados.

95

4.1.4 Pruebas de serialización y cifrado en XML y JSON

La pruebas realizadas consistieron en la captura de 70 reportes, (entiéndase reporte al estado de cada uno de los sensores de hardware a monitorear) en diferentes máquinas a distintas horas del día. Por cada reporte, se realizó el cifrado en AES-128 y AES-256 tanto con el formato XML, como para el formato JSON; asimismo, se tuvo en cuenta el tiempo que le toma a cada equipo realizar estos dos tipos de cifrado. Las comparaciones a realizar son:

Bytes en claro vs bytes cifrados.

Tiempos en cifrado AES-128 vs cifrado AES-256.

Tiempos en descifrado AES-128 vs descifrado AES-256.

Tiempos en cifrado y descifrado AES-128 y AES-256.

Los objetivos de estas pruebas son:

Encontrar un incremento promedio de los bytes cifrados en comparación con los bytes del texto en claro de los reportes en el formato XML y JSON.

Definir entre el formato JSON y XML que tenga menor número de bytes después del cifrado y el formato que tarde menos tiempo en procesar el cifrado y descifrado de los algoritmos AES-128 y AES-256.

Observar las diferencias promedio en términos de tiempo que tarda un equipo en realizar el cifrado y el descifrado para los algoritmos de cifrado y determinar cuál de los dos es conveniente implementar en este proyecto.

4.1.4.1 Bytes en claro vs bytes cifrados Inicialmente se comparó los bytes cifrados con los bytes en claro, para ello se serializó cada reporte en XML y JSON, posteriormente, se cifro cada reporte en AES-128 y en AES-256. Los resultados encontrados están en la siguiente tabla, donde los:

Bytes de un reporte JSON en claro: es el promedio en bytes que un reporte en claro (sin cifrar) tiene al estar serializado en el formato JSON.

Bytes de un reporte JSON cifrado en AES-128: representan el promedio en bytes que un reporte cifrado en AES-128 tiene en el formato JSON.

Bytes de un reporte JSON cifrado en AES-256: es el promedio en bytes que un reporte cifrado en AES-256 tiene en el formato JSON.

Bytes de un reporte XML en claro: es el promedio en bytes que un reporte en claro tiene en el formato XML.

Bytes de un reporte XML cifrado en AES-128: es el promedio en bytes que un reporte cifrado en AES-128 tiene en el formato XML.

Bytes de un reporte XML cifrado en AES-256: es el promedio en bytes que un reporte cifrado en AES-256 tiene en el formato XML.

96

Tabla 24. Bytes en claro vs bytes cifrados en AES-128 y AES-256.

Tipo Promedio (bytes)

Bytes en claro (JSON) 1089,34

Bytes en cifrado AES-128 (JSON) 1465,94

Bytes en cifrado AES-256 (JSON) 1465,94

Bytes en claro (XML) 1626,54

Bytes en cifrado AES-128 (XML) 2180,46

Bytes en cifrado AES-256 (XML) 2180,46


De la Tabla 24 se puede notar que tanto el cifrado AES-128 como el AES-256 tienen el mismo promedio de bytes al estar serializados en un formato especifico, estos resultados concuerdan ya que la diferencia fundamental entre los dos tipos de cifrados está en la longitud de la clave y el número de rondas, sin embargo, la longitud de bloque es igual para los dos.

La diferencia que se aprecia en el promedio de bytes de un reporte JSON en claro es notable comparado con el promedio de bytes en XML; aproximadamente un 49% (537 bytes) es mayor un reporte serializado en XML que en JSON en términos de bytes. Es decir, si tenemos en cuenta que el MTU de Ethernet es de 1500 bytes, se requieren al menos dos paquetes IP para enviar un reporte serializado en XML, mientras que con un solo paquete IP se puede enviar un reporte en JSON tanto en texto en claro como cifrado en AES.

Con respecto al cifrado se tiene que aproximadamente se incrementa un 34% la cantidad de bytes con relación al texto en claro; 376 bytes para el formato JSON y 554 bytes para un reporte serializado en XML. En la Grafica 3 se encuentran representados los resultados obtenidos para una mejor apreciación.

Gráfica 3. Bytes en claro vs bytes cifrados.


97

En conclusión, se determina que el formato JSON será el indicado para serializar los reportes que tendrán los datos de los sensores del hardware instalado en los computadores a monitorear. Se encontró que este formato al no utilizar una etiqueta de cierre y al utilizar una sintaxis más corta para arreglos y objetos, reduce significativamente la cantidad de bytes a diferencia del formato XML.

4.1.4.2 Tiempos en cifrado AES-128 vs cifrado AES-256 Teniendo en cuenta la prueba anterior, se observó que al cifrar tanto en AES-128 como en AES-256, se obtiene el mismo número de bytes, por tanto, falta por analizar el tiempo que tarda un equipo al realizar estos dos tipos de cifrado simétrico. En la Tabla 25 se pueden apreciar los resultados del cifrado, en la próxima sección trataremos los resultados obtenidos en el proceso inverso, el descifrado.

Tabla 25. Tiempos en cifrado AES-128 y AES-256.

Tipo Tiempo (µs)

Tiempo en cifrado AES-128 (JSON) 266,86

Tiempo en cifrado AES-256 (JSON) 280,17

Tiempo en cifrado AES-128 (XML) 357,66

Tiempo en cifrado AES-256 (XML) 421,51 Fuente: Elaboración propia.

Cada uno de los anteriores tiempos, representan los microsegundos promedio que tarda un equipo en cifrar un reporte serializado en JSON y XML para el estándar AES-128 y AES-256.

En la siguiente grafica (Gráfica 4) están representados los resultados de la tabla anterior, en donde se puede apreciar, que cifrar un reporte en el formato JSON es más rápido que el cifrado para el formato XML para los dos tipos del estándar AES tratados en esta iteración.

Gráfica 4. Tiempos en cifrado AES-128 y AES-256.


98

Tan solo hay 13 microsegundos que distan entre los cifrados para un reporte en JSON, sin embargo, para el formato XML esta diferencia es mayor (63 µs), pero en los dos formatos es el cifrado AES-128 quien toma menos tiempo.

4.1.4.3 Tiempos en descifrado AES-128 vs descifrado AES-256 Para el proceso complementario al cifrado, encontramos que los tiempos son significativamente más bajos que los hallados al cifrar los reportes.

Tabla 26. Tiempos en descifrado AES-128 y AES-256.

Tipo Tiempo (µs)

Tiempo en descifrado AES-128 (JSON) 86,12

Tiempo en descifrado AES-256 (JSON) 104,82

Tiempo en descifrado AES-128 (XML) 100,01

Tiempo en descifrado AES-256 (XML) 101,91 Fuente: Elaboración propia.

Los datos de la Tabla 26 representan los microsegundos promedio que tarda un equipo en descifrar un reporte, tanto en el formato JSON como en XML. Comparando los resultados con los tiempos en el cifrado se puede apreciar una diferencia de hasta 300 µs, es decir, que el descifrado en promedio es hasta tres veces más rápido que el cifrado de datos.

Gráfica 5. Tiempo en descifrado AES-128 y AES-256.


No se aprecia una diferencia fundamental entre el descifrado AES-128 y AES-256 para el formato XML, asimismo, se destaca que estos dos tiempos son menores que el tiempo promedio en descifrado AES-256 para el formato JSON.

4.1.4.4 Tiempos en cifrado y descifrado AES-128 y AES-256 Por ultimo queda analizar el tiempo total empleado en el cifrado y descifrado para AES-128 y AES-256 en los formatos XML y JSON. La Gráfica 6 ilustra los tiempos expuestos en las tablas anteriores, clasificados por el estándar AES, por el proceso de cifrado y por el descifrado para los dos formatos ya vistos.

99

Gráfica 6. Tiempo de cifrado y descifrado AES-128 y AES-256.


Al igual que con el promedio de bytes, es el formato JSON quien tiene mejor performance comparado con XML, al tomar menos tiempo en los dos procesos del AES, al igual, en la gráfica se puede notar que el AES-256 requiere más tiempo que el AES-128, debido a las 14 rondas frente a las 10 que realiza el algoritmo AES-128.

4.1.4.5 Conclusiones El objetivo de las pruebas era determinar en qué formato es conveniente serializar los datos que los sensores de hardware reportan y determinar cuál algoritmo de cifrado se debería seleccionar, tomando como dos variables el número de bytes y el tiempo que emplea un equipo en serializar y cifrar dichos datos.

En la prueba donde comparábamos los bytes promedio en texto en claro, observamos que el formato JSON serializa los objetos en menor tamaño que con el formato XML, al igual para el cifrado AES fue el formato JSON quien tiene un menor tamaño en términos de bytes que el formato XML, es por ello que se concluyó utilizar el formato JSON para enviar los datos en una red.

Para las comparaciones de los tiempos promedio que un equipo emplea para el cifrado y descifrado de los datos, encontramos que nuevamente el formato JSON tiene mejor rendimiento que XML, también, notamos que el proceso de descifrado es más de tres veces veloz que el tiempo para cifrar datos. Con respecto a los dos algoritmos AES-128 y AES-256 implementados en esta iteración, podemos decir

100

que, el estándar AES-128 es ligeramente más rápido de procesar tanto para el cifrado como para el descifrado que el algoritmo AES-256, ya que este último realiza cuatro rondas más que el primero, sin embargo, es el AES-256 quien provee un cifrado más seguro, por este motivo y teniendo en cuenta que la diferencia entre los dos algoritmos es de 13 microsegundos en promedio para el cifrado y 18 microsegundos para el descifrado, tomamos la decisión de implementar AES-256 para el cifrado de los datos a enviar en tiempo real, lo cual conllevará menos de 400 microsegundos en promedio que se requieren para asegurar la confidencialidad de los datos.

4.2 ITERACIÓN 2: DISEÑO E IMPLEMENTACIÓN DE LA REPLICACIÓN DE LOS DATOS

Durante la iteración 2 se realizó el diseño y la implementación del modelo de replicación a utilizar con MongoDB, visualizando los resultados obtenidos y las pruebas realizadas en este proceso.

4.2.1 Diseño – Modelo de replicación

Figura 56. Modelo de replicación.


101

4.2.2 Implementación inicial del modelo de replicación

Inicialmente se realizaron pruebas de replicación simulando las instancias de mongo desde diferentes puertos en un mismo equipo local, para lo cual se crearon en principio 3 carpetas host, donde cada una de ellas será tomada como una instancia diferente.

Cada uno de los host contiene la carpeta “data” que usa mongo para el almacenamiento de las colecciones, una carpeta con un archivo para el registro de logs y un archivo .conf el cual contiene la configuración general de la instancia,

Figura 57. Carpetas y archivo de configuración.


Luego, desde la consola de comandos en modo administrador, se realiza la asignación del puerto a cada una de las instancias y el nombre del replica-set al que pertenecerá con el siguiente comando:

Figura 58. Inicio de instancias en MongoDB.


Luego se realiza la inicialización del host1 como primario, luego de ejecutar el comando rs.initiate() y un pequeño lapso de espera queda configurado el host1 como PRIMARY del replica-set nombrado “replica”:

Figura 59. Acceso a la consola de comandos de mongo.


102

Figura 60. Inicializar el Replica-Set.


Finalmente, para concluir con la configuración inicial se adicionan los host restantes al replica-set con el siguiente comando, indicando la IP del equipo y el puerto indicado en la configuración de cada uno:

Figura 61. Adición de nodos.


4.2.3 Pruebas de replicación

La prueba de replicación se realizó utilizando RoboMongo, que es el entorno grafico para el manejo de bases de datos MongoDB.

Se crea la conexión del host1 (PRIMARY), se valida el rol de cada uno de los nodos y se crea una base de datos para la prueba, en este caso se nombró “monitoreo”:

Figura 62. Vista de nodos desde RoboMongo.


Se crean la conexión de los nodos secundarios y automáticamente se ve reflejada la creación de la base de datos del nodo primario.

Se realizó la inserción de 2 colecciones con varios documentos y se evidencia que todas las instancias tienen una réplica de los registros insertados. También se realizaron pruebas de actualización y eliminación de los registros.

103

Adicionalmente, el host4 fue agregado posteriormente y se replicó la base de datos automáticamente con la información de las colecciones ya insertadas:

Figura 63. Documentos en base de datos.


4.2.4 Prueba de desconexión del nodo primario

Se realizó la configuración de 3 hosts en diferentes sistemas operativos de la siguiente manera:

Tabla 27. Configuración de host de replicación.

HOST IP SISTEMA OPERATIVO

PRIMARY 10.8.0.6 WINDOWS 10

SECONDARY 10.8.0.1 LINUX Centos 6.7

SECONDARY 10.8.0.10 WINDOWS 7 SP1 Fuente: Elaboración propia.

104

Para la verificación del correcto funcionamiento del replica-set luego de la desconexión del nodo primario se implementó una aplicación en lenguaje de programación C#, con el objetivo de realizar la inserción de 5000 documentos dentro de la colección llamada “colección” en la base de datos “testReplica”. En el constructor de la clase ConexionMongoDB se encuentra la referencia a los hosts 10.8.0.1, 10.8.0.6, 10.8.0.10. Adicionalmente la referencia a la base de datos y la colección que se crearán durante la ejecución del programa.

Figura 64. Conexión desde C#.


Continuando en la clase ConexionMongoDB se encuentra el método ‘agregaUnDocumento’, el cual se encargará de la inserción de un documento en formato BSON(JSON Binario) con los campos “num” y nombre al interior de la colección creada en el constructor. En caso de encontrar alguna excepción se detiene la ejecución por un tiempo de 5 segundos y nuevamente se reanuda la inserción de los datos faltantes para garantizar la integridad de estos.

Figura 65. Agregar documentos desde C#.


105

El otro método que hace parte de la clase ConexionMongoDB llamado ‘contarTodosLosDocumentos’ retorna el número de documentos que conforman la colección referenciada.

Figura 66. Contar documentos desde C#.


Por último la aplicación se ejecuta desde el método ‘realizarPrueba’ de la clase MainWindow. En este método se consultan los documentos que la colección contenga, más adelante se invoca la función ‘agregaUnDocumento’ por 5000 veces y al final se muestra los documentos de la colección.

Figura 67. Aplicación de pruebas.


106

4.3 ITERACIÓN 3: CRUD EN BASE DE DATOS DISTRIBUIDA

CRUD es el acrónimo de las siguientes acciones: Create, Read, Update y Delete. Estas operaciones se realizan desde el software hacia la base de datos, en nuestro caso desde la aplicación Administrador hacia el conjunto de nodos en replica de MongoDB.

El objetivo de esta fase es crear los componentes de software que permita cumplir con los casos de uso: Gestión de usuarios y gestión de emisores de la fase de planeación. Para ello, se definieron las historias de usuario HU-007, HU-008. HU-009, HU-010, HU-011, HU-012. HU-013, HU-014, HU-015.

4.3.1 Desarrollo de la historia de usuario HU-007

En esta historia de usuario llamada Creación de emisores, se busca registrar a los equipos que enviarán reportes de tal forma que únicamente los registrados en el sistema puedan enviar reportes. Inicialmente se crea un módulo donde se puedan visualizar los datos de los emisores y estén los botones de las acciones definidas en la historia de usuario: gestión de emisores.

En la siguiente imagen (Figura 68) se aprecia el módulo con nombre “Emisores” y por medio de una tabla se listan los emisores registrados en el sistema. Las columnas definidas para mostrar los datos más relevantes de los equipos son: Nombre, Ubicación, Licencia Vigente, Fecha de Vencimiento y Estado. Los botones de la interfaz le permitirán al Administrador registrar, editar, eliminar emisores, y generar el archivo de configuración de cada emisor.

Figura 68. Módulo Emisores.


Para el registro de emisores se tiene el botón “Agregar emisor” en la parte superior, el cual al presionarlo muestra una nueva ventana con los datos definidos en la historia de usuario. Luego de ingresar los datos se actualiza la tabla del módulo emisores.

107

Figura 69. Agregar Cliente.



Para la edición de los datos de los emisores se reutilizó el componente de software de la historia anterior, es decir, que la vista se modifica cuando el Administrador presiona el botón “Editar” que está en cada fila de la tabla del módulo Emisores. En el ViewModel está el siguiente fragmento de código fuente que realiza los cambios a la vista.

Figura 70. Reutilización de la vista Agregar Cliente y Editar Cliente.


Las diferencia entre la vista “Agregar Cliente” y “Editar Cliente” están en que la última tiene el campo de Estado, indica que un Emisor puede estar Activo o Inactivo para enviar reportes a los administradores.

108

Figura 71. Editar Cliente.


4.3.3 Desarrollo de la historia de usuario HU-009 y HU-010.

Estas dos historias de usuario tratan de la eliminación de los emisores y se diferencian en que la historia HU-010 tiene como criterio de aceptación que la eliminación del emisor también elimina los reportes generados de ese emisor. Para cada una de estas acciones existe un botón en la tabla del módulo Emisores.

Las dos historias de usuario tienen en común que debe existir un cuadro dialogó donde el usuario Administrador confirme la acción a realizar. Esto permite reutilizar otro componente de software para las dos acciones, donde el mensaje cambia si se quiere realizar una eliminación permanente del emisor.

Figura 72. Eliminación de emisores.


En la anterior imagen (Figura 72) se puede notar la diferencia entre las dos acciones. En la izquierda está el cuadro de dialogo donde se elimina el emisor, lo que ocasiona que cambie a un tercer estado: “Eliminado”. A la derecha el cuadro de dialogo informa que también se eliminarán todos los reportes que se hayan generado del emisor “WAR-PC”. El fragmento de código muestra el enlace de datos hacia la vista Eliminar.

109

Figura 73. Vista Eliminar en XAML.


Del código en XAML se distinguen los bloques de texto para el título (“Eliminar Cliente”) y la descripción que cambia para la eliminación permanente. Al final se crean dos botones (“Eliminar y “Cancelar”) donde el primero tiene como parámetro una variable con valor verdadero indicando que el usuario confirma la eliminación para posteriormente enviar la acción a la base de datos.


Para la generación del archivo de configuración se tiene un botón por cada fila en la tabla del módulo Emisores. Una vez el administrador presiona este botón se realiza el proceso del siguiente diagrama (Figura 74). Como salida del proceso se tiene el archivo “config.json”, necesario para la conexión de los emisores con el servidor.

Figura 74. Flujo Generar archivo de configuración.


Este proceso se debe realizar cada vez que la fecha de vencimiento de la licencia cambie, es decir, si se cumple esta fecha el administrador edita el emisor, luego genera el archivo de configuración y posteriormente procede a copiar el archivo en la carpeta “Config” del emisor para que esté pueda volver a enviar reportes en tiempo real.

110

La estructura del archivo es un objeto JSON. En la siguiente imagen se muestra un ejemplo del archivo “Config.json” para el emisor “WAR-PC” y se puede ver que la licencia está cifrada, la cadena de conexión para la conexión con los nodos en réplica de MongoDB y la url del servidor que se utilizará para enviar los reportes en tiempo real.

Figura 75. Estructura del archivo config.json.



Para las historias de usuario que tratan de la gestión de usuarios se crea un módulo llamado “Usuarios del sistema” para hacer referencia a los administradores que tienen acceso a las aplicaciones y podrán ver los reportes de los emisores.

Al igual que en el módulo anterior, el módulo de usuarios está compuesto por una tabla donde se listan cada uno de los usuarios del sistema. En esta tabla se destacan el UserName, Nombre del usuario, Correo electrónico y Estado. También, existen los botones para agregar, editar y eliminar usuarios.

Figura 76. Módulo Usuarios del sistema.


Asimismo se tiene una ventana que permita registrar los datos del nuevo usuario a crear. Como criterio de aceptación de la historia de usuario se tiene que se debe enviar un correo electrónico al nuevo usuario indicando la contraseña para el ingreso al sistema.

111

Figura 77. Agregar Usuario.


El correo que se envía tiene el mensaje de la siguiente imagen, claro está, con una contraseña distinta para cada usuario del sistema.

Figura 78. Notificación de nueva contraseña.



Para la edición de los usuarios también se reutiliza el componente de software de la historia anterior. Asimismo, se adiciona el campo Estado con los valores Activo o Inactivo, de tal forma que un usuario Inactivo no puede ingresar a la aplicación.

Figura 79. Editar Usuario.


112

Aunque se permite cambiar el username del usuario, se realiza una validación de tal forma que no existan dos usuarios con el mismo valor. Otra restricción que se tiene en cuenta es que nunca puede ser visible la contraseña de los usuarios.

Figura 80. Creación y edición de usuarios (Código).


Del código anterior se puede identificar la creación o edición de un usuario del sistema. En este caso el ViewModel de la capa de presentación llama a la función CreateUsuarioAsync o EditarUsuarioAsync (dado el caso) de la capa de Negocio, quien a su vez se comunica con la capa de acceso a datos y envía un mensaje de éxito o no que se muestra en pantalla, luego de actualizarse la tabla de usuarios.


La eliminación de usuarios se realiza desde un botón en cada fila de la tabla del módulo usuarios del sistema, una vez el administrador oprime el botón se muestra en pantalla un cuadro de dialogo como el siguiente.

Figura 81. Eliminar Usuario.


Si se confirma la eliminación se da de baja del sistema al usuario, de tal forma que, este no podrá volver a ingresar a la aplicación y a tener acceso a los reportes en tiempo real.

113


Para restablecer la contraseña se requiere generar una contraseña aleatoria de 8 caracteres alfa-numéricos, como lo indican los criterios de aceptación de la historia.

Figura 82. Generar contraseña aleatoria.


De la función “generarContrasenia” de la imagen anterior, se toman de forma aleatoria ocho caracteres del alfabeto definido y al final se retorna la cadena con los caracteres seleccionados. El proceso continúa en la capa de negocio con el cifrado y envío del correo electrónico al usuario de acuerdo a la estructura de la historia de usuario HU-012.

4.4 ITERACIÓN 4: APLICACIÓN EN TIEMPO REAL

En la cuarta iteración se construyen los componentes de software necesarios para el envío y visualización de reportes en tiempo real. Recordando que ya se tiene el componente que captura los datos de los sensores de hardware desarrollados en la primera iteración. A continuación se desarrollan las historias de usuario HU-016 y HU-017 que implica la interacción de las tres aplicaciones: Emisor, Servidor y Administrador.

4.4.1 Desarrollo de las historias de usuario HU-016, HU-017 y HU-018.

Como tercer módulo de la aplicación administrador se tiene el dashboard o tablero, donde se visualizan de forma gráfica los datos de los sensores de hardware. Se toman como referencia los diagramas de flujo: conexión al servidor y enviar reporte,

114

para ello se tiene una aplicación que actúa como servidor que espera por las conexiones de emisores y administradores.

Figura 83. Inicio del Servidor.


En la función “StartServer” de la aplicación Servidor se inicia una aplicación web básica con la url que se obtiene desde la capa de negocio. Esta aplicación web se embebe en WPF tal como lo que haría un servidor web IIS. Es decir que únicamente al iniciar la aplicación Servidor se crea una aplicación web que escuchará conexiones de emisores y administradores. Luego se buscan los emisores (Clientes) y administradores (usuarios) habilitados para la conexión con el servidor, es decir, los emisores y administradores con estado Activos.

Figura 84. Recibir Reporte


115

En el servidor existe una función (RecibirReporte) que recibe el reporte cifrado que el emisor envía. Utilizando el framework de SignalR se puede obtener el identificador de la conexión del emisor, luego, de acuerdo al diagrama de flujo de la fase de planeación se buscan los administradores conectados y se envía el reporte cifrado junto al nombre del emisor.

Figura 85. Clase ClienteReporte.

Fuente: Visual Studio 2015 Community. Diagrama de Clases.

En el administrador se descifra el reporte y se utiliza un objeto de la clase “ClienteReporte” donde existen las siguientes propiedades:

Un objeto Cliente, con el nombre y ubicación del emisor.

Un objeto Reporte con los datos de los sensores del hardware (RAM, discos, procesador, board, BIOS y GPU) y software del emisor (Versión de Windows).

Un arreglo de Discos, con los datos de temperatura y espacio utilizado de los discos duros y de estado sólido.

Un arreglo de GPU con la información de las tarjetas de video instaladas.

Un objeto (RAMSeries) con la cantidad de memoria RAM libre y utilizada en Gigabytes.

Como se está utilizando el patrón de diseño MVVM se debe implementar la interfaz “INotifyPropertyChanged” y con el método “NotifyPropertyChanged se le indica a la vista los cambios ocurridos en modelo para que automáticamente se actualice.

116

Figura 86. Dashboard


La imagen anterior (Figura 86) muestra el reporte del equipo WAR-PC, indicando las direcciones IPV6 y las direcciones IP Versión 4. Del procesador se identifican el nombre, el porcentaje de uso y la temperatura. Para la RAM se tiene un gráfico circular con la cantidad de memoria usada y libre en Gigabytes. Se identifican dos discos instalados con el porcentaje de espacio utilizado y la temperatura actual.

Para la historia de usuario HU-017 se utiliza la misma clase “ClienteReporte” y con la ayuda del patrón MVVM se construye una tabla en XAML que contiene las columnas de los criterios de aceptación.

117

Figura 87. Tabla de emisores y sus sensores.


En el fragmento de código se crea una tabla (DataGrid) y se enlaza un arreglo de “ClienteReporte” llamado Clientes. En el resto de etiquetas XML se definen las columnas de la tabla. Por ejemplo, la columna “Hilos” que hace referencia a la cantidad de hilos del procesador se obtiene del objeto CPU que es una propiedad del objeto Reporte, es decir: “Reporte.CPU.Hilos”; de esta forma se tiene la referencia del dato que se desea ubicar en esa columna desde la vista, por cada ClienteReporte del arreglo Clientes.

Figura 88. Otros sensores.


Para el desarrollo de la historia de usuario HU-018 se tiene en la barra de título el botón minimizar, maximizar y cerrar, de esta forma, si el usuario decide maximizar

118

la ventana a la resolución de la pantalla el contenido se adapta permitiendo visualizar más emisores y datos de hardware.

Figura 89. Dashboard Full Screen.


4.5 ITERACIÓN 5: INTEGRACIÓN Y PRUEBAS

Una vez desarrolladas las tres aplicaciones de escritorio (Emisor, Servidor y Administrador) se procede a realizar la integración entre ellas. Para esto, se configura un modelo de réplica en dos equipos con sistemas operativos diferentes.

Tabla 28. Nodo Windows de pruebas.

Sistema Operativo Windows 7 Ultimate SP1 x86_64

Memoria RAM 6 GB

Procesador Intel(R) Core(TM) 2 Duo CPU E8400 @ 3.00GHz

Espacio en disco 128 Gigabytes Fuente: Elaboración propia

En el equipo con sistema operativo Windows 7 se instala la base de datos MongoDB en la versión 3.2.7. Mientras que en el Raspberry pi 3 se instala la versión 3.0.14.

119

Tabla 29. Nodo Linux de pruebas.

Sistema Operativo Raspbian GNU/Linux 9 (stretch) ARM 7

Memoria RAM 1 GB

Procesador ARMv7 Processor rev 4 (v7l)

Espacio en disco 32 Gigabytes Fuente: Elaboración propia.

Como se puede apreciar en la Tabla 29, el equipo con sistema operativo Linux tiene una arquitectura ARM utilizada en dispositivos móviles en la actualidad, totalmente distinta a la arquitectura (x64) del equipo Windows. Sin embargo, el modelo de replicación funciona incluso si se tiene un sistema operativo distinto, diversas arquitecturas de procesador y versiones diferentes.

Se realiza una configuración en el archivo hosts de los equipos de forma que, se configuran los nombres de la siguiente imagen para las direcciones IP denotadas.

Figura 90. Configuración red en archivo hosts.


Se configura el replica-set y se tiene que el server1 será el host primario, por otra parte se configura otra instancia en el mismo dispositivo (Raspberry PI 3) para el server2 como árbitro. Mientras que el equipo Windows tiene la instancia del server3 como host secundario.

Figura 91. Cadena de conexión en pruebas.


La cadena de conexión anterior se configura en todos los archivos de configuración para la conexión con la base de datos desde las aplicaciones.

Figura 92. Replica set inicial en Robo 3T.


120

Asimismo, se configura una cuenta de correo para el envío de las notificaciones de las contraseñas de los usuarios del sistema.

Figura 93. Cuenta de correo electrónico.


Como se puede apreciar la contraseña está almacenada en base 64, tal cual se definió en anteriores iteraciones. Es claro denotar que también esta contraseña está cifrada, ya que si se utiliza una decodificación de la contraseña se obtiene una cadena de caracteres sin sentido y con posibles errores si se desea transmitir en una red de datos, por esta razón se decidió utilizar la codificación base 64.

Figura 94. Decodificación de base 64.


Para la puesta en marcha del sistema se despliega el servidor de forma local y se registra la dirección en los archivos de configuración de las tres de aplicaciones. Una vez se ingresa a la aplicación Administrador se crea o edita un emisor como el de la siguiente imagen, también, se establece el tiempo entre reportes a dos (2) segundos como prueba de estrés.

121

Figura 95. Edición del emisor en pruebas.


Figura 96. Dashboard en pruebas.


122

En la imagen del dashboard anterior (Figura 96) se muestra que los datos se están enviando en tiempo real en las tres aplicaciones con el modelo hibrido de replicación. Luego se decide simular la desconexión del nodo primario de la base de datos que se encuentra en la instancia mongodb1 del Raspberry Pi 3.

Figura 97. Detención del nodo primario.


Para ello se utiliza el comando anterior en cual se detiene el servicio mongodb1. Al realizar esta acción automáticamente se realiza una votación con los otros nodos y de modo que solo existe server3 como secundario, es elegido para convertirse como nodo primario.

Figura 98. Nodo 'Not reachable' en Robo 3T.


Desde Robo 3T se puede apreciar que el estado de server1 es “Not reachable” y que el server3 es ahora el nodo primario. Esto también indica que es posible que nodos con distintas versiones de MongoDB y con diferentes sistemas operativos pueden llegar a cumplir con el rol de nodo primario en caso de un fallo o desconexión de otros nodos.

Figura 99. Inicio de la instancia detenida.


Otra prueba que se realizó fue la reconexión de la instancia detenida minutos antes, de tal forma que, la instancia detenida no tenía los reportes generados por los emisores mientras estuvo desconectada. Luego de unos segundos de actualización y copia de los datos desde server3 a server1, automáticamente se realiza otra votación y se determina que la instancia del Raspberry debe ser la primaria, elección que es totalmente transparente para la aplicación Administrador y Emisor por lo que los usuarios del sistema no se enteran de lo sucedido con los nodos del modelo de replicación en MongoDB.

123

Figura 100. Dirección IP del nodo primario.


Para simular uno de los fallos más comunes en los sistemas actuales, se decide desconectar el cable de red del server1, es decir, que se tiene una desconexión en la red de datos. Esto causa una votación entre los nodos secundarios dando como resultado que el nodo primario es el server3.

Figura 101. Estado del nodo server1.


Otra ventaja que se tiene desde el software Robo 3T, es la posibilidad de enviar comandos a MongoDB. De la imagen anterior (Figura 101), se tiene que el nodo server1 no se puede acceder, esto se obtiene con el comando rs.status(). Una vez se vuelve a conectar el cable de red se evidencia con el comando db.isMaster() para conocer quien es nodo primario.

Figura 102. Salida del comando db.isMaster()


124

Del comando anterior se puede observar el nombre del replica set, los nodos que pertenecen al replica, los árbitros que ayudaran a desempatar en caso que ocurra en una votación e identificar cual es nodo primario y si desde el nodo donde se envía el comando es el nodo maestro o secundario.

Figura 103. Dashboard despues de las pruebas.


De las pruebas realizadas concluimos que el modelo de replicación MongoDB es robusto para ser utilizado desde aplicaciones como la desarrollada en esta monografía. Permitiendo ser un replica set hibrido entre versiones de la base de

125

datos, hibrido en cuanto a arquitectura de procesadores de los diferentes nodos y permitiendo ser hibrido para nodos con sistemas operativos diferentes.

En la imagen anterior (Figura 103) se puede notar el estado del computador WARPC utilizado en las pruebas, sin embargo, al usuario final el cambio de un nodo secundario a primario fue totalmente transparente. Al igual que ocurrió al detener una instancia de MongoDB o desconectado el cable de red del nodo primario. Esto conlleva que es totalmente viable tener un modelo de replicación que ofrece alta disponibilidad y tolerancia a fallos.

126

5 FASE DE PRODUCCIÓN.

Una vez las pruebas han resultado exitosas se decide entrar en producción para ello se realiza la instalación y puesta en marcha del sistema de monitoreo. Para ello con el ayuda de la empresa Virtual Smart Business se decide realizar una instalación de forma hibrida de la solución, es decir, se utiliza un servidor en la nube para la replicación de los datos en MongoDB y se utiliza un equipo en la oficina para alojar la aplicación servidor.

Las características del servidor donde están las instancias de MongoDB se especifican en la Tabla 30:

Tabla 30. Especificaciones del servidor de base de datos.

Sistema Operativo Linux CentOS 7.2.1511 (Core) x86_64

Memoria RAM 8 GB

Procesador Intel(R) Xeon(R) CPU E5-1630 v3 @ 3.70GHz

Espacio en disco 500 Gigabytes Fuente: Elaboración propia.

Se realiza la configuración de las tres instancias y con los siguientes comandos se inician en el servidor.

Figura 104. Configuración de instancias.


El modelo implementado consta dos instancias de datos y una instancia que actúa de árbitro. En las dos primeras se elige un servidor que tendrá el rotulo de Primario, mientras que el restante es el nodo esclavo o Secundario. La instancia con el rol de Arbitró se crea con el objetivo de mantener el quorum del replica set, responder a los heartbeats y decidir cuál instancia debe ser la primaria en caso de empate, por ello, como diferencia de las demás instancias, el árbitro no almacena datos, sino que interviene únicamente en la elección del nodo primario.

Como regla general, si el número de miembros (instancias o nodos que almacenan datos) es par, se debe agregar un árbitro para no exista empate y conseguir la elección del nodo Primario. Es decir, un primario puede renunciar y convertirse en secundario y viceversa, mientras, que un árbitro nunca podrá ser primario o secundario. La Figura 105 muestra el modelo del replica set implementado para el monitoreo de equipos en la empresa Virtual Smart Business.

127

Figura 105. Modelo implementado en producción.

Fuente: Replication. MongoDB Docs. Disponible en: https://docs.mongodb.com/manual/replication/

Luego de tener las tres instancias ejecutándose como un replica set de mongodb se procede a configurar la cadena de conexión en los archivos de configuración de la aplicación servidor y administrador.

Para ello se decide desplegar la aplicación servidor de un equipo que tiene las especificaciones plasmadas en la Tabla 31.

Tabla 31. Especificaciones servidor en producción.

Sistema Operativo Microsoft Windows 10 Pro

Memoria RAM 8 GB

Procesador Intel(R) Core(TM) i5 7400 @ 3.00GHz

Espacio en disco 2 Terabytes Fuente: Elaboración propia.

En el equipo ya se contaba con la versión 4.5 de .NET Framework instalada. Posteriormente, se toma la dirección IP del equipo y se establece la dirección http que escuchará las conexiones y el envío de reportes de los emisores a los administradores.

Figura 106. Dirección http del servidor en producción.


Una vez se establecen los permisos en el firewall para el puerto 8088 se procede a iniciar el servidor. Luego, se establece esa dirección web en el archivo de configuración de la aplicación administrador para que pueda iniciar.

https://docs.mongodb.com/manual/replication/

128

Se crearon múltiples emisores, se estableció el tiempo entre reportes diferente para cada equipo y se generaron los archivos de configuración. Luego de copiar la aplicación a los diferentes equipos se procedió a lanzar la aplicación Emisor.

Figura 107. Emisores en producción.


Inicialmente se ejecutan las aplicaciones de los equipos: “MGUERRA”, “BGARZON”, “APOLO” y” PGOMEZ”. Se obtienen los datos que se reflejan en las siguientes imágenes.

Figura 108. Tabla de sensores en producción.


129

Figura 109. Dashboard equipos en producción.


Se logra identificar a primera vista que el equipo PGOMEZ del departamento de Diseño tiene la temperatura más alta en cuanto al procesador, a pesar que el porcentaje de uso es bajo. Al ser un equipo utilizado para diseño gráfico es más alto muchas veces es más alto el uso de los recursos del computador ya que durante el día se realizan renders, ediciones de video, diseño de interfaces, entre otras que conllevan a un uso y por tanto una temperatura más elevada que el resto de equipos.

Siguiendo con el aspecto de la temperatura se nota que el equipo BGARZON posee las temperaturas más altas en los discos duros y en segundo lugar con 46 °C del procesador. Teniendo en cuenta que el reporte fue generado al medio día y como

130

lo indica la tabla de emisores el equipo se encuentra sobre la ventana del área de Ingeniería, es completamente normal que la temperatura sea más elevada que la del resto de equipos que no se encuentran sobre la ventana.

Figura 110. Otros emisores en producción.


En la tarde se decide iniciar la aplicación en los equipos restantes: ORODRIGUEZ y NRICO, y logró comprobar que la temperatura es menor que al medio día aun cuando el sol continua irradiando sobre la ventana del departamento de Ingeniería.

131

Por último, se encontró una diferencia entre las tarjetas de video de los equipos: MGUERRA (izquierda), PGOMEZ (centro) y NRICO (derecha).

Figura 111. Datos de tarjetas de video.


Se evidencia que el porcentaje de uso de la GPU del equipo PGOMEZ es la más alta; como se mencionó es el equipo del área de Diseño Gráfico en la compañía. Por otro parte, la tarjeta gráfica del equipo MGUERRA es quien tiene la temperatura más elevada, lo que indica que existe una alta probabilidad que el ventilador de la GPU requiera algún mantenimiento preventivo.

132

6 MUERTE DEL PROYECTO.

Una vez finalizada la etapa de construcción en iteraciones, luego de las pruebas exitosas y puesta en marcha del sistema en producción se procede a la construcción de manuales de usuario e instalación de la solución propuesta a la problemática presentada.

Retomando la formulación del problema del capítulo 1 decimos que el cifrado de los datos representa una característica importante en la transmisión y almacenamiento de los datos garantizando confidencialidad, por ello, se recomienda que el estándar AES-256 para la confidencialidad de los datos. Otro aspecto importante es el monitoreo de los ordenadores que usamos día a día, el cual se convierte una tarea que se debe realizar de forma periódica para detectar anomalías y una mejor toma de decisiones en los mantenimientos preventivos.

La instalación de la base de datos MongoDB se puede realizar de forma transparente en la nube. Si se desea, se puede adquirir un plan en la plataforma Atlas para las necesidades de cada proyecto.

Figura 112. Planes MongoDB Atlas.

Fuente: MongoDB Atlas. Disponible en: https://www.mongodb.com/cloud/atlas

Es posible crear un cluster para diferentes proveedores como AWS, Google Cloud Platform y Azure. En nuestro caso se utilizó la instancia M0 que viene disponible en Amazon Web Services totalmente gratis. Algunas características de este plan son:

Memoria RAM compartida.

512 Megabytes de espacio en disco duro.

3 nodos en replicación (replica set).

En la siguiente imagen se tienen otras características del plan adquirido y se puede observar la ubicación geográfica del replica set (N. Virginia, USA). Esta instancia es posible para proyectos que están empezando y para el prototipado de aplicaciones a desarrollar, sim embargo, es recomendable utilizar las demás instancias para entornos en producción ya que vienen habilitados con otras características importantes como el Backus de los datos de forma automática.

133

Figura 113. Características instancia M0 MongoDB Atlas.

Fuente: MongoDB Atlas. Disponible en: https://www.mongodb.com/cloud/atlas

Otra ventaja de utilizar esta plataforma de MongoDB, es la capacidad de tener un monitoreo de los nodos, cabe destacar, que es posible tener un cluster con más de 3 nodos en replicación desplegados en diferentes países, lo que ayuda a ofrecer un mejor servicio de acuerdo a la ubicación geográfica de los nodos.

134

7 CONCLUSIONES.

Una vez finalizada esta monografía concluimos que el monitoreo de los equipos es importante, ya que permite tomar acciones preventivas y disuasivas de posibles fallos que pueden ocurrir en procesadores, memorias RAM, discos (duros y de estado sólido) y demás componentes de hardware instalados en los equipos de empresas, colegios, universidades, entre otras.

Lograr visualizar en tiempo real el estado de los componentes del hardware fue un reto superado. Asimismo, poseer un sistema altamente disponible con la implementación de un modelo de replicación, permite que los datos se puedan consultar y actualizar siendo transparentes desconexiones o adiciones de nodos que en muchos casos afectan la experiencia del usuario final y hasta pérdidas considerables de dinero.

Se implementó AES-256 para el cifrado de reportes, se serializaron con JSON y por último se codificaron en base64 para la transmisión en tiempo real. Del algoritmo de cifrado se concluye que es el más seguro a la fecha en términos de cifrado simétrico por lo que representa un ítem importante para la confidencialidad de los datos. De la serialización en JSON se encontró que es mucho más eficiente en cantidad de bytes que XML y junto al cifrado representan un proceso no mayor a 400 microsegundos que se tarda un computador en realizarlos. Por último se tiene que para una correcta transmisión de estos reportes se utilizó la codificación en base64 que le aporta integridad y consistencia de los datos desde el emisor hasta los diferentes receptores.

Con respecto a la utilización de MongoDB como base de datos, se evidenció que poseen un driver fácil de usar en el lenguaje de programación C# y con excelente documentación que permitió adaptarse rápidamente a este tipo de base de datos NoSQL y orientada a documentos. Con respecto al replica set, se encontró que es totalmente compatible entre diferentes versiones de la base de datos, sistemas operativos y arquitecturas de los procesadores.

Del lenguaje de programación de Microsoft utilizado para el desarrollo de software se encontró que, la implementación del patrón MVVM y SignalR ayudaron en la construcción y reutilización de los componentes de software. Del patrón MVVM se utilizó el enlace de datos (bindings) que evitó ocuparnos de la sincronización de los datos con las vistas, apropiado para la visualización y actualización de los reportes en tiempo real. Con respecto a la implementación del Framework SignalR nos favoreció en la transmisión de datos por medio del protocolo de aplicación http directamente sin tener que preocuparnos por administrar las conexiones a nivel de sockets.

135

8 RECOMENDACIONES.

Después de la construcción de las aplicaciones y el desarrollo de esta monografía realizamos las siguientes recomendaciones:

1. Con respecto a las aplicaciones desarrolladas se sugiere una futura versión 2.0, donde se tenga el Dashboard en una página web para la visualización del estado de los equipos conectados. Adicionalmente, se puede desarrollar un agente que capture las métricas de hardware en equipos con sistema operativo Linux, esto sería de gran utilidad para los administradores de servidores y redes telemáticas conformadas por equipos con las diferentes distribuciones de Linux que existen.

2. Otra recomendación es agregarle un componente de inteligencia artificial a la solución, ya que se tienen reportes de múltiples equipos cada minuto, es inevitable que en algunos meses esa información pase la frontera de los megabytes a los gigabytes, por lo tanto, es útil tener un componente de machine learning que ayude a predecir posibles fallas antes que ocurran, es decir, que utilice los reportes históricos almacenados en MongoDB para crear un modelo matemático que pronostique comportamientos y ayude a prever futuras fallas o estados no deseados de los emisores.

3. Se recomienda que la Universidad Distrital Francisco José de Caldas apoye estos proyectos que pueden ayudar tanto para el campus, sedes, bibliotecas de la misma Universidad, como a múltiples entidades públicas y privadas en Colombia. Es claro que esta solución telemática desarrollada se puede implementar para cualquier tipo de industria y con el apoyo de la Universidad se pueden conseguir beneficios para los estudiantes, la comunidad en general y la Universidad.

136

BIBLIOGRAFÍA

BEN OTHMANE, Lotfi, et al. Extending the agile development process to develop acceptably secure software. IEEE Transactions on Dependable and Secure Computing, 2014, vol. 11, no 6, p. 497-509. Disponible en: http://ieeexplore.ieee.org/document/6702438/

BERMEJO, María. Desarrollo de un sistema de autoescalado dinámico de base de datos distribuida MongoDB sobre una plataforma cloud OpenStack. 2016. Tesis de Maestría.

CANÓS, José H.; LETELIER, Patricio; PENADÉS, Mª Carmen. Metodologías ágiles en el desarrollo de software. 2012. DSIC -Universidad Politécnica de Valencia. 2012. Disponible en: http://roa.ult.edu.cu/handle/123456789/476

CHIRIBOGA, Washington Alberto. Aplicación informática para la integración y alimentación de datos del balanced scorecard de la Universidad Técnica Estatal de Quevedo. 2016. Tesis de Maestría. Ecuador. 2015.

CHODOROW, Kristina. MongoDB: the definitive guide. " O'Reilly Media, Inc.",

2013.

COHN, Mike. User stories applied: For agile software development. Addison-Wesley Professional, 2004.

DEL BUSTO, Hansel Gracia; ENRÍQUEZ, Osmel Yanes. Bases de datos NoSQL. Revista Telem@ tica, 2013, vol. 11, no 3, p. 21-33.

FOX, Armando; BREWER, Eric A. Harvest, yield, and scalable tolerant systems. En Hot Topics in Operating Systems, 1999. Proceedings of the Seventh Workshop on. IEEE, 1999. p. 174-178.

HAERDER, Theo y REUTER, Andreas. Principles of transaction-oriented database

recovery. ACM Computing Surveys (CSUR), 1983, vol. 15, no 4, p. 287-317.

Disponible en: http://doi.acm.org/10.1145/289.291

IZAURRALDE, Paula; ANDRIANO, Natalia. Trazabilidad Ágil. Universidad Tecnológica Nacional, Argentina. 2013. Disponible en: http://conaiisi.unsl.edu.ar/2013/113-528-1-DR.pdf

JOSKOWICZ, José. Reglas y prácticas en eXtreme Programming. Universidad de Vigo, 2008, p. 22.

KATZ, Jonathan y LINDELL, Yehuda. Introduction to modern cryptography. CRC press, 2014. Ed. 2. 603 p.

http://ieeexplore.ieee.org/document/6702438/

http://roa.ult.edu.cu/handle/123456789/476

http://doi.acm.org/10.1145/289.291

137

MAHAJAN, Prerna y SACHDEVA, Abhishek. A Study of Encryption Algorithms AES, DES and RSA for security. Global Journal of Computer Science and Technology, 2013, vol. 13, no 15.

MOUSQUES, Gastón. Cátedra de Ingeniería de Software. Universidad ORT Uruguay. Facultad de Ingeniería. 2013.

ÖZSU, M. Tamer; VALDURIEZ, Patrick. Principles of distributed database systems. Springer Science & Business Media, 2016. 868 p.

POVEDA GALVIS, Juan Pablo. Propuesta de Notación Gráfica para el Modelo Orientado a Documentos de MongoDB. Trabajo de grado para optar por el título de Ingeniero Electrónico. Universidad Distrital Francisco José de Caldas. 2016, p.7.

ROMERO, Alexander Castro; SANABRIA, Juan Sebastián González; CUERVO, Mauro Callejas. Utilidad y funcionamiento de las bases de datos NoSQL. Facultad de Ingeniería, 2012, vol. 21, no 33, p. 21-32.

SEPÚLVEDA CRUZ, Sergio Andrés. Clasificación de sistemas gestores de base de datos según el teorema de CAP. 2018.

138

ANEXOS

ANEXO A. HISTORIAS DE USUARIO

En este anexo se encuentran las historias de usuario definidas en la fase de planeación, de acuerdo a la estructura descrita en el marco teórico.

NOMBRE: Ejecución automática después del arranque del sistema operativo.

ID: HU-001

PRIORIDAD: 7

ESTIMACIÓN: 1

VERSIÓN: 1.0

DESCRIPCIÓN:

Como administrador quiero que una vez inicie el sistema operativo WINDOWS, se ejecute la aplicación y empiece a enviar los datos de los sensores de forma automática, para visualizarlos en tiempo real.


PROTOTIPO:

NOMBRE: Tiempo de espera entre reportes.

ID: HU-002

PRIORIDAD: 5

ESTIMACIÓN: 16

VERSIÓN: 1.0

DESCRIPCIÓN: Como administrador quiero configurar el tiempo en segundos que debe esperar la aplicación de captura para enviar un nuevo reporte.


El tiempo no puede ser global para todos los equipos.

El tiempo debe configurarse en cada equipo.

El tiempo mínimo permitido es 30seg y el

máximo es 300seg (5min).

PROTOTIPO:

139

NOMBRE: Acceso a la aplicación de captura de datos.

ID: HU-003

PRIORIDAD: 5

ESTIMACIÓN: 16

VERSIÓN: 1.0

DESCRIPCIÓN:

Como administrador del sistema, quiero que la aplicación que captura datos posea un login, para restringir al acceso a la configuración y a la información que se visualiza.


Usuario.

Contraseña.

PROTOTIPO:

NOMBRE: Icono de notificación.

ID: HU-004

PRIORIDAD: 6

ESTIMACIÓN: 8

VERSIÓN: 1.0

DESCRIPCIÓN:

Como administrador del sistema, quiero que la aplicación que captura datos se mantenga minimizada, para que no aparezca en la barra de tareas y los usuarios de los equipos no noten que la aplicación se encuentra en ejecución.


Debe aparecer un icono de notificación.

No debe aparecer un icono en la barra de

tareas.

140

PROTOTIPO:

NOMBRE: Minimizar al cerrar.

ID: HU-005

PRIORIDAD: 8

ESTIMACIÓN: 10

VERSIÓN: 1.0

DESCRIPCIÓN: Como administrador del sistema, quiero que la aplicación no permita cerrarse, para que el equipo siga enviando reportes de los sensores de hardware.


Al presionar el botón cerrar, la aplicación no se

deberá cerrar, sino minimizar.

Al presionar la combinación de teclas “Alt + F4”,

la aplicación no se deberá cerrar, sino

minimizar.

PROTOTIPO:

NOMBRE: Almacenamiento De Datos.

ID: HU-006

PRIORIDAD: 10

ESTIMACIÓN: 200

VERSIÓN: 1.0

DESCRIPCIÓN: Como administrador del sistema, quiero almacenar la información con un sistema de replicación de datos que me permita consistencia y disponibilidad los datos.


Al guardar la información, esta debe quedar

almacenada en varios nodos.

Debo poder acceder a la información desde

cualquier lugar.

141

Si el lugar principal donde guardo y consulto la

información falla, debe poderse acceder al

respaldo inmediatamente y no se debe ver

afectada la integridad ni el rendimiento de la

aplicación.

PROTOTIPO: Modelo de replicación MongoDB

NOMBRE: Creación de emisores.

ID: HU-007

PRIORIDAD: 5

ESTIMACIÓN: 5

VERSIÓN: 1.0

DESCRIPCIÓN: Como administrador del sistema, quiero crear emisores para que únicamente los registrados en el sistema envíen reportes.


El nombre del emisor debe ser único, es decir,

no pueden existir dos emisores con el mismo

nombre.

La ubicación como un campo de texto.

Deben tener una fecha de vencimiento de la

licencia.

PROTOTIPO:

NOMBRE: Edición de emisores.

ID: HU-008

PRIORIDAD: 5

ESTIMACIÓN: 10

VERSIÓN: 1.0

DESCRIPCIÓN: Como administrador del sistema, quiero editar los datos de los emisores para que estos permanezcan actualizados.


Modificar el nombre, siguiendo las restricciones

de la historia HU-007.

Permitir cambiar la fecha de vencimiento, por

una posterior al día actual.

Permitir cambiar la ubicación.

PROTOTIPO:

142

NOMBRE: Eliminación de emisores.

ID: HU-009

PRIORIDAD: 7

ESTIMACIÓN: 5

VERSIÓN: 1.0

DESCRIPCIÓN: Como administrador del sistema, quiero eliminar los emisores para darlos de baja en el sistema.


La eliminación del emisor, no elimina los

reportes que este haya generado y enviado.

La eliminación causa un cambio de estado.

Debe existir un cuadro de dialogo donde se

confirme la eliminación a realizar.

PROTOTIPO:

NOMBRE: Eliminación permanente de emisores.

ID: HU-010

PRIORIDAD: 7

ESTIMACIÓN: 10

VERSIÓN: 1.0

DESCRIPCIÓN: Como administrador del sistema, quiero eliminar todos datos de un emisor para darlos de baja en el sistema de forma permanente.


La eliminación del emisor también ocasiona la

eliminación de todos los reportes que haya

generado y enviado.

Debe existir un cuadro de dialogo donde se

informe que serán eliminados los reportes

también.

PROTOTIPO:

143

NOMBRE: Generación del archivo de configuración.

ID: HU-011

PRIORIDAD: 8

ESTIMACIÓN: 20

VERSIÓN: 1.0

DESCRIPCIÓN:

Como administrador del sistema, quiero generar el archivo de configuración para que un emisor pueda generar, cifrar y enviar de forma correcta los reportes de hardware.


Debe abrirse un cuadro de dialogo, donde se

seleccione la ruta a almacenar el archivo.

El archivo debe tener la configuración necesaria

con los datos actualizados del emisor.

El archivo debe llamarse “config.json”.

PROTOTIPO:

NOMBRE: Creación de usuarios.

ID: HU-012

PRIORIDAD: 6

ESTIMACIÓN: 5

VERSIÓN: 1.0

DESCRIPCIÓN: Como administrador del sistema, quiero crear usuarios para que administren el sistema y puedan ver los reportes en tiempo real.


El nombre usuario debe ser único.

El correo electrónico debe ser obligatorio.

144

Debe existir un campo para registrar el nombre.

Al crear un usuario, se debe enviar por correo

electrónico la contraseña de acceso al sistema.

PROTOTIPO:

NOMBRE: Edición de usuarios.

ID: HU-013

PRIORIDAD: 6

ESTIMACIÓN: 4

VERSIÓN: 1.0

DESCRIPCIÓN: Como administrador del sistema, quiero editar usuarios para que se tengan los datos actualizados en el sistema.


Debe permitir cambiar el nombre de usuario,

nombres y correo electrónico.

No debe permitirse ver la contraseña en ningún

momento.

PROTOTIPO:

NOMBRE: Eliminación de usuarios.

ID: HU-014

PRIORIDAD: 6

ESTIMACIÓN: 4

VERSIÓN: 1.0

DESCRIPCIÓN: Como administrador del sistema, quiero eliminar los usuarios para darlos de baja en el sistema.


La eliminación de usuario, no le permitirá tener

acceso de nuevo al sistema.

Debe existir un cuadro de dialogo con la

confirmación del usuario, preguntando si está

seguro de hacerlo.

PROTOTIPO:

NOMBRE: Restablecer contraseña.

ID: HU-015

PRIORIDAD: 5

ESTIMACIÓN: 6

VERSIÓN: 1.0

145

DESCRIPCIÓN: Como administrador del sistema, quiero restablecer la contraseña de los usuarios para que se notifique de la acción realizada.


La contraseña debe tener 8 caracteres alfa

numéricos.

Se debe enviar por correo electrónico la nueva

contraseña.

PROTOTIPO:

NOMBRE: Dashboard.

ID: HU-016

PRIORIDAD: 9

ESTIMACIÓN: 15

VERSIÓN: 1.0

DESCRIPCIÓN: Como administrador del sistema, quiero ver en un dashboard los datos de los sensores que envían los emisores en tiempo real.


En el dashboard deben aparecer el porcentaje

de uso de CPU, temperatura de CPU, Nombre

del equipo, direcciones IP.

De la RAM las gigas libres y utilizadas.

De los discos duros el porcentaje de uso y la

temperatura.

De las GPU, el porcentaje de uso, la

temperatura y el voltaje.

Los datos deben visualizarse de forma gráfica

utilizando íconos, gráficas y colores.

PROTOTIPO:

NOMBRE: Tabla de emisores y sus sensores.

ID: HU-017

PRIORIDAD: 9

ESTIMACIÓN: 5

VERSIÓN: 1.0

DESCRIPCIÓN: Como administrador del sistema, quiero ver en una tabla los datos de los sensores que envían los emisores en tiempo real.


Nombre, Ubicación, hora local, versión de

Windows instalada en el emisor.

146

Del procesador el fabricante, porcentaje de uso,

temperatura, núcleos e hilos.

De la RAM el porcentaje de uso, las ranuras

libre y ocupadas de la board.

La cantidad de discos conectados en la board.

Dela board el modelo, la versión y fabricante de

la BIOS.

Todos los anteriores datos se deben mostrar en

columnas para cada uno de los emisores (filas).

PROTOTIPO:

NOMBRE: Maximizar ventana.

ID: HU-018

PRIORIDAD: 5

ESTIMACIÓN: 1

VERSIÓN: 1.0

DESCRIPCIÓN:

Como administrador del sistema, que la aplicación administrador permita maximizar la ventana a la resolución de la pantalla, para que pueda ver en pantalla completa los sensores y los emisores reportando.


Debe existir un botón maximizar.

El contenido se debe ajustar a la resolución de

la pantalla.

PROTOTIPO:

147

ANEXO B. MÉTRICAS DE LOS SENSORES A REPORTAR

En este anexo se listan las métricas y datos que se capturan de los sensores de hardware, incorporados en los diferentes componentes de un computador.

Métrica o sensor de hardware Tipo de dato Ejemplo de Salida

Fabricante Board Texto MSI

Modelo Board Texto Asus P5Q3 Deluxe

Versión Board Texto 1.0

Fabricante BIOS Texto American Megatrends Inc.

Versión BIOS Texto V1.9

Cant. Ranuras RAM Libres Número Entero 2

Cant. Ranuras RAM Ocupadas

Número Entero 2

Núcleos del Procesador Número Entero 4

Hilos del Procesador Número Entero 4

Fabricante del Procesador Texto Intel(R) Corporation

Versión del Procesador Texto Intel(R) Core 2 Duo (TM) E8400 CPU @ 3.00GHz

Uso de CPU Porcentaje 10,89%

Uso núcleo 1 Porcentaje 8,89%

Uso núcleo 2 Porcentaje 12,89%

Temperatura CPU Número Entero 34 °C

Temperatura núcleo 1 Número Entero 35 °C

Temperatura núcleo 2 Número Entero 36 °C

Gráficos de CPU Número Entero 0 W

Uso de RAM Porcentaje 55,37%

RAM Usada Flotante 4,41 GB

RAM Libre Flotante 3,55 GB

Nombre del Tarjeta Gráfica Texto AMD Radeon HD 5450

Uso de la GPU Porcentaje 5%

Temperatura GPU Número Entero 42 °C

Voltaje de GPU Número Entero 1 V

Nombre del Disco Duro (HDD) Texto ST3750640NS

Temperatura HDD Número Entero 43 °C

Espacio Usado Porcentaje 54,84%

replicaciÓn en mongodb, cifrado y envÍo de mÉtricas...

Documents