Prestalud: prototipo telemático para el proceso de préstamo y control de recursos de los laboratorios de industrial de la Facultad Tecnológica De La Universidad Distrital Francisco José De Caldas

Texto completo

(1)PRESTALUD: PROTOTIPO TELEMÁTICO PARA EL PROCESO DE PRÉSTAMO Y CONTROL DE RECURSOS DE LOS LABORATORIOS DE INDUSTRIAL DE LA FACULTAD TECNOLÓGICA DE LA UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS. WILMAR ALEXIS CAICEDO SERRANO MIGUEL ANTONIO CARO OCAMPO. UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS FACULTAD TECNOLÓGICA INGENIERÍA EN TELEMÁTICA BOGOTÁ D.C. 2017.

(2) PRESTALUD: PROTOTIPO TELEMÁTICO PARA EL PROCESO DE PRÉSTAMO Y CONTROL DE RECURSOS DE LOS LABORATORIOS DE INDUSTRIAL DE LA FACULTAD TECNOLÓGICA DE LA UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS. WILMAR ALEXIS CAICEDO SERRANO MIGUEL ANTONIO CARO OCAMPO. Proyecto de grado para optar al título de Ingeniero en Telemática. INGENIERO, MIGUEL ANGEL LEGUIZAMÓN PÁEZ Asesor Universidad Distrital Francisco José de Caldas. UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS FACULTAD TECNOLÓGICA INGENIERÍA EN TELEMÁTICA BOGOTÁ D.C. 2017.

(3) Nota de aceptación ____________________________ ____________________________ ____________________________ ____________________________ ____________________________ ____________________________. ____________________________ Firma del tutor. ____________________________ Firma del jurado.

(4) Quiero dedicar este trabajo a mi hermosa hija María Paula Caro Murcia, el alma de mi vida, mi motivo de alegría y mis ganas de superación. A mi compañera sentimental Rubiela Murcia, a mi padre, amigo y consejero José Antonio Caro, a mi madre Liliana Ocampo, a mi hermano Cristian Andrés Caro Ocampo, a mi familia y allegados que siempre estuvieron allí presentes en todos los ámbitos de mi vida. Dedico este logro a la Universidad Distrital Francisco José de Caldas y a la Facultad Tecnológica en cuyo campus viví momentos de alegría, angustia, aprendizaje y formación. Miguel Antonio Caro Ocampo. Dedicado a mis padres y hermanas Wilmar Alexis Caicedo Serrano.

(5) AGRADECIMIENTOS. Quiero agradecer primeramente a mi padre el logro de este esfuerzo por ser la persona que impulso en mí el deseo de superación, paciencia, persistencia y humildad. Agradezco a mi compañera sentimental y mi hija por ser ambas ese motor que me impulsa a salir adelante todos los días. Agradezco a mi familia el esfuerzo, la dedicación y el amor que me brindaron para poder cumplir con este sueño, este objetivo en el trayecto de mi vida profesional. Agradezco a la Universidad Distrital Francisco José de Caldas por haberme dado la oportunidad de formarme en su campus, en su alma máter como persona y profesional. Miguel Antonio Caro Ocampo. Agradezco a Dios, a mi familia y a la Universidad Distrital Francisco José de Caldas por la oportunidad y consecución de ser un profesional. Mis padres y hermanas gracias por su apoyo, colaboración y acompañamiento durante este camino trazado que me permite lograr tan importante objetivo en mi vida académica. Wilmar Alexis Caicedo Serrano.

(6) TABLA DE CONTENIDO. GLOSARIO ............................................................................................................ 10 RESUMEN ............................................................................................................. 12 ABSTRACT ............................................................................................................ 13 1. INTRODUCCIÓN ............................................................................................ 14 2. JUSTIFICACIÓN ............................................................................................. 15 3. DEFINICIÓN DEL PROYECTO....................................................................... 16 3.1. TÍTULO ..................................................................................................... 16. 3.2. PROBLEMA .............................................................................................. 16. 4. OBJETIVOS .................................................................................................... 17 4.1. OBJETIVO GENERAL .............................................................................. 17. 4.2. OBJETIVOS ESPECÍFICOS ..................................................................... 17. 5. MARCO DE REFERENCIA ............................................................................. 18 5.1. ANTECEDENTES ..................................................................................... 18. 5.2. MARCO TEÓRICO ................................................................................... 19. 5.2.1. ¿Qué es el control del uso? ............................................................... 19. 5.2.2. ¿Qué es Scrum? ................................................................................ 19. 5.2.3. Protocolos de comunicación. ............................................................. 21. 5.2.4. Servidor web. ..................................................................................... 24. 5.2.5. Gestión de la información. .................................................................. 26. 5.2.6. Sistema de control de versiones. ....................................................... 28. 5.2.7. Cliente web. ....................................................................................... 31. 5.2.8. Cliente rest móvil. ............................................................................... 32. 6. METODOLOGÍA SCRUM ............................................................................... 35 6.1. PROCESO DE ANÁLISIS ÁGIL ................................................................ 35. 6.1.1. Roles de usuarios............................................................................... 35. 6.1.2. Identificación de los procesos de negocio. ......................................... 36. 6.1.3. Identificación de funcionalidades del software. .................................. 36. 6.1.4. Identificación de MVP (producto mínimo viable) y posteriores entregas. 37. 6.1.5. Historias de usuario............................................................................ 39. 6.1.6. Plan de Entregas. ............................................................................... 45.

(7) 6.1.7. Duración del proyecto. ....................................................................... 49. 6.1.8. Costo del proyecto. ............................................................................ 49. 7. DISEÑO E IMPLEMENTACIÓN ...................................................................... 51 7.1. REQUERIMIENTOS NO FUNCIONALES ................................................ 51. 7.2. DICCIONARIO DE DATOS....................................................................... 52. 7.3. DIAGRAMA DE CLASES.......................................................................... 58. 7.4. SERVICIOS DEL API REST ..................................................................... 59. 8. PRUEBAS DEL SERVICIO WEB .................................................................... 80 9. CRONOGRAMA DE ACTIVIDADES ............................................................. 105 10.. CONCLUSIONES ...................................................................................... 107. 11.. RECOMENDACIONES .............................................................................. 108. 12.. REFERENCIAS BIBLIOGRÁFICAS ........................................................... 109. ANEXOS .............................................................................................................. 111.

(8) LISTA DE TABLAS. Tabla 1. Colección users ....................................................................................... 52 Tabla 2. Colección profiles ..................................................................................... 52 Tabla 3. Colección metrics ..................................................................................... 53 Tabla 4. Colección teachers .................................................................................. 53 Tabla 5. Colección subjects ................................................................................... 53 Tabla 6. Colección providers ................................................................................. 54 Tabla 7. Colección entries ..................................................................................... 55 Tabla 8. Colección stocks ...................................................................................... 55 Tabla 9. Colección maintenances .......................................................................... 56 Tabla 10. Colección controls .................................................................................. 56 Tabla 11. Colección schedules .............................................................................. 57 Tabla 12. Colección requests ................................................................................ 57 Tabla 13. Colección practices ................................................................................ 58 Tabla 14. Prueba para crear solicitud de práctica .................................................. 80 Tabla 15. Prueba para consultar solicitudes de práctica filtrada por semestre y año ........................................................................................................................ 81 Tabla 16. Prueba para consultar solicitud de práctica por día filtrada por fecha y laboratorio ....................................................................................................... 81 Tabla 17. Prueba para actualizar datos de solicitud de práctica ............................ 82 Tabla 18. Prueba para consultar solicitudes de práctica por fecha y laboratorio ... 82 Tabla 19. Prueba para consultar solicitudes de práctica por usuario y laboratorio 83 Tabla 20. Prueba para consultar solicitud de práctica por consecutivo ................. 83 Tabla 21. Prueba para consultar solicitudes de práctica del año y semestre actual ........................................................................................................................ 84 Tabla 22. Prueba para consultar solicitudes de práctica filtrada por laboratorio .... 84 Tabla 23. Prueba para crear solicitud de material.................................................. 85 Tabla 24. Prueba para consultar equipos o materiales disponibles del inventario . 85 Tabla 25. Prueba para consultar solicitudes de material filtrado por año, semestre y laboratorio .................................................................................................... 86 Tabla 26. Prueba para consultar solicitudes de material por usuario filtrado por año y semestre ...................................................................................................... 86 Tabla 27. Prueba para consultar solicitudes de material por sesión de usuario .... 87 Tabla 28. Prueba para consultar solicitudes de práctica y material filtrado por año y semestre ......................................................................................................... 87 Tabla 29. Prueba para consultar solicitudes de práctica y material por usuario filtrado por año y semestre ............................................................................. 88 Tabla 30. Prueba para actualizar el campo observaciones de la solicitud de material ........................................................................................................... 88 Tabla 31. Prueba para actualizar el estado de ejecución de la solicitud de material ........................................................................................................................ 89 Tabla 32. Prueba para consultar las solicitudes de práctica y material por sesión de usuario y que se encuentran en estado finalizado ..................................... 89.

(9) Tabla 33. Prueba para consultar información de todos los usuarios ...................... 90 Tabla 34. Prueba para consultar información de usuarios filtrado por código ....... 90 Tabla 35. Prueba para consultar usuarios agrupados por perfil ............................ 91 Tabla 36. Prueba para crear un usuario ................................................................ 92 Tabla 37. Prueba para iniciar sesión con las credenciales de un usuario .............. 92 Tabla 38. Prueba para modificar el estado de activación de un usuario ................ 93 Tabla 39. Prueba para actualizar los datos de un usuario ..................................... 93 Tabla 40. Prueba para eliminar los datos de un usuario ........................................ 94 Tabla 41. Prueba para obtener una métrica por su identificador ........................... 94 Tabla 42. Prueba para obtener un listado de métricas filtradas por el tipo al que pertenecen ...................................................................................................... 95 Tabla 43. Prueba para crear una nueva métrica .................................................... 95 Tabla 44. Prueba para actualizar una métrica ....................................................... 96 Tabla 45. Prueba para eliminar una métrica .......................................................... 96 Tabla 46. Prueba para obtener el listado de todas las entradas de almacén ........ 97 Tabla 47. Prueba para obtener una entrada de almacén por su identificador ....... 97 Tabla 48. Prueba para crear una nueva entrada de almacén ................................ 98 Tabla 49. Prueba para actualizar los datos de una entrada de almacén ............... 99 Tabla 50. Prueba para eliminar los datos de una entrada de almacén .................. 99 Tabla 51. Prueba para obtener el listado de todas las fichas técnicas ................ 100 Tabla 52. Prueba para obtener las entradas de almacén que tienen recursos o herramientas que aún no se han registrado en el inventario ........................ 100 Tabla 53. Prueba para obtener los datos de una ficha técnica por su identificador ...................................................................................................................... 101 Tabla 54. Prueba para retornar los recursos y las cantidades que aún se pueden registrar en el inventario ............................................................................... 101 Tabla 55. Prueba para crear una nueva ficha técnica.......................................... 102 Tabla 56. Prueba para actualizar los datos de una ficha técnica ......................... 103 Tabla 57. Prueba para actualizar el estado de una ficha técnica ......................... 104 Tabla 58. Prueba para actualizar el estado de una ficha técnica por no disponible ...................................................................................................................... 104.

(10) GLOSARIO. ANGULARJS: es un framework MVC de JavaScript para el Desarrollo Web Front End que permite crear aplicaciones SPA Single-Page Applications. Entra dentro de la familia de frameworks como BackboneJS o EmberJS.1 AJAX: un método que utiliza JavaScript y XML para modificar páginas Web en forma dinámica, sin mostrar una nueva página, mediante la obtención de pequeñas cantidades de datos del servidor. BASE DE DATOS: un almacén de datos electrónico definido de manera formal y controlado en forma central, para usarse en muchas aplicaciones. BASES DE DATOS NO SQL: son sistemas de almacenamiento de información que no cumplen con el esquema entidad–relación. Tampoco utilizan una estructura de datos en forma de tabla donde se van almacenando los datos sino que para el almacenamiento hacen uso de otros formatos como clave–valor, mapeo de columnas o grafos. CSS: hojas de estilo en cascada, un conjunto de estilos que controlan el formato de una página Web. Los estilos CSS se pueden almacenar en un archivo y usar para dar formato a varias páginas Web, o se pueden definir dentro de una página Web. DICCIONARIO DE DATOS: una obra de consulta con información sobre los datos (metadatos) creados por el analista de sistemas con base en los diagramas de flujo de datos; recopila y coordina términos de datos específicos, confirmando lo que cada término significa para distintas personas en la organización. FTP: protocolo de transferencia de archivos, en la actualidad es la forma más común de mover archivos entre distintos sistemas computarizados. HTML: lenguaje de marcado de hipertexto, el lenguaje detrás de la apariencia de los documentos en Web. En realidad es un conjunto de convenciones que marcan las porciones de un de un documento para indicarle al navegador qué formato distintivo debe aparecer en cada porción de una página. HTTP: protocolo de transferencia de hipertexto, se utiliza para mover páginas Web entre distintas computadoras; por ejemplo, desde un sitio Web en una computadora que esté en otro país, hasta su computadora personal.. 1. AZAUSTRE, Carlos. ¿Qué es AngularJS? Primeros pasos para aprenderlo. Formación JS [en línea], 9 de septiembre de 2013 [revisado 10 agosto 2017]. Disponible en Internet: https://carlosazaustre.es/empezando-con-angular-js/. 10.

(11) JSON: es un formato de intercambio de datos abierto y basado en texto. Igual que XML, es legible e independiente de la plataforma, además de tener a su disposición una amplia gama de implementaciones. Los datos con formato según el estándar JSON son ligeros y las implementaciones de JavaScript pueden analizarlos sintácticamente con increíble facilidad, lo que lo convierte en el formato ideal de intercambio de datos para aplicaciones web de Ajax. Puesto que JSON es ante todo un formato de datos, no está limitado a las aplicaciones web de Ajax y prácticamente se puede usar en cualquier escenario en que las aplicaciones necesiten intercambiar o almacenar información estructurada como texto.2 METODOLOGÍA ÁGIL: una metodología de desarrollo de sistemas que tiene valores, principios y prácticas útiles para los analistas de sistemas que desean una metodología flexible, interactiva y participativa.3 MONGODB: se trata de una base de datos creada por 10gen del tipo orientada a documentos, de esquema libre, es decir, que cada entrada puede tener un esquema de datos diferente que nada tenga que ver con el resto de registros almacenados. Es bastante rápido a la hora de ejecutar sus operaciones ya que está escrito en lenguaje C++.4 NODE.JS: es un entorno de ejecución para JavaScript construido con el motor de JavaScript V8 de Chrome. Node.js usa un modelo de operaciones E/S sin bloqueo y orientado a eventos, que lo hace liviano y eficiente. El ecosistema de paquetes de Node.js, npm, es el ecosistema más grande de librerías de código abierto en el mundo.5 URL: localizador uniforme de recursos, la dirección de un documento o programa en Internet. Las extensiones conocidas son .com para comercios, .edu para instituciones educativas, .gov o .gob para instituciones gubernamentales, .org para organizaciones, etcétera.6. 2. ATIF AZIZ, Scott Mitchell. Introducción a JavaScript Object Notation (JSON) en JavaScript y .NET. Microsoft Developer Network [en línea], 26 de junio de 2007 [revisado 10 Agosto 2017]. Disponible en Internet: https://msdn.microsoft.com/esco/library/bb299886.aspx 3 KENDALL, Kenneth E. KENDALL, Julie E. Análisis y diseño de sistemas. 8 ed. México.: Pearson Educación, 2011. 559 561 p. 4 Acens the cloud services company. Bases de datos NoSQL: Qué son y tipos que nos podemos encontrar. Telefónica [en línea], 28 de febrero de 2014 [revisado 10 agosto 2017]. Disponible en Internet: https://www.acens.com/wpcontent/images/2014/02/bbdd-nosql-wp-acens.pdf 5 Node.js Foundation. Node.Js. Linux Foundation Collaborative Projects [en línea], [revisado 10 agosto 2017]. Disponible en Internet: https://nodejs.org/es/ 6 KENDALL, Kenneth E. KENDALL, Julie E. Análisis y diseño de sistemas. 8 ed. México.: Pearson Educación, 2011. 349 p.. 11.

(12) RESUMEN. El prototipo telemático está compuesto por las aplicaciones web y móvil, que permiten la administración de usuarios de la comunidad educativa, controlar el inventario y gestionar el horario de uso libre de los laboratorios de tecnología industrial e ingeniería de producción. La comunicación entre las aplicaciones se realiza por medio de un servicio web y la información es almacenada en una base de datos no relacional. El servicio web está basado en el protocolo HTTP utilizando frecuentemente los métodos de petición get, post, put y delete. La transferencia de información entre el servidor y cliente se realiza mediante el formato JSON, además, se utiliza el estándar JSON web token (JWT) para la autenticación de usuarios y seguridad en la transferencia de datos. Para el desarrollo de este prototipo se utilizaron los lenguajes de programación JavaScript, NodeJS, Angular y Java. El entorno de programación Android Studio. El sistema de control de versiones Git. Base de datos MongoDB y la metodología Scrum. Con base en la metodología scrum se establecen los requerimientos funcionales, sprints y las diferentes actividades que permitieron comprender los procedimientos que ejecutan el grupo de trabajo del laboratorio y construir el prototipo con el cumplimiento de los objetivos planteados en este proyecto. Palabras clave: servicio web, metodología, control de uso, aplicación, scrum.. 12.

(13) ABSTRACT. Prototype of the telematics is formed by web and mobile applications, which allow the administration of users of the educational community as well as control inventory and manage free schedule for laboratories of industrial technology and production engineering. The communication between applications is done by a web service and the information is accumulated in a non-relational database. The web service is based on the HTTP protocol, using frequently the get, post, put and delete request methods. The transfer of information between the server and the customer is done using the JSON format, in addition, the standard JSON Web Token (JWT) is used for users authentications and data transfer security. For the development of this prototype was used programming languages as JavaScript, NodeJS, Angular and Java. The Android Studio programming environment. The Git version control system. MongoDB database and Scrum methodology. Based on the scrum methodology were set the functional requirements, sprints and the different activities that let understand procedures that execute the work group of the laboratory and tbuild the prototype with the fulfillment of the objectives set in this project. Keywords: web service, methodology, use control, application, scrum.. 13.

(14) 1. INTRODUCCIÓN. El presente proyecto de grado se centra en la realización de un prototipo telemático para el control de uso e inventario de los recursos del laboratorio de industrial de la Universidad Distrital Francisco José de Caldas Facultad Tecnológica. La construcción del prototipo se genera por la falta de información en tiempo real para conocer la disponibilidad de los laboratorios (HAS-200, FMS-200, sala de software especializado, gestión de operaciones GEIO y trabajo en alturas) y sus correspondientes equipos o materiales. Por otra parte, las operaciones manuales que ejecutan el grupo de trabajo del laboratorio no les permite llevar un control y gestión sobre el banco de información o de datos, el cual puede llegar a ser muy útil en la toma de decisiones como: ¿Si la inversión de millones de pesos en sistemas como la HAS-200 o la FMS-200 es coherente con la utilización por parte de la comunidad universitaria sobre la cual fueron planeadas? O si, por el contrario, se requiere inversión en otros recursos que se involucren frecuentemente al método de enseñanza implementado por cada docente e igualmente satisfagan los objetivos académicos del proyecto curricular. La finalidad de este proyecto es mejorar la administración del inventario y gestionar el uso de horarios libres de los laboratorios de tecnología industrial e ingeniería de producción a partir de la disponibilidad, confiabilidad e integridad de la información. Para abordar la problemática actual se hizo necesario abarcar una metodología que permita evidenciar resultados en el menor tiempo posible, es por ello que una de las alternativas seleccionadas para este proyecto es la metodología scrum, la cual consiste en el levantamiento de información por medio de historias de usuario, que a su vez permiten dividir los procesos generales del proyecto y planear todas las actividades que con llevan al cumplimiento de los objetivos de cada uno de estos procesos. Para cumplir con nuestro propósito, el presente documento se compone del marco de referencia, metodología scrum, diseño e implementación y pruebas de software. En el marco de referencia, se describió cada una de las herramientas de software libre utilizadas. En la metodología scrum, se desarrollaron los requerimientos funcionales y los sprints ejecutados. En diseño e implementación, se detallan las colecciones construidas en la base de datos no relacional y los servicios elaborados en la api rest. En las pruebas de software, se definen los test construidos y se exponen los respectivos resultados.. 14.

(15) 2. JUSTIFICACIÓN. Automatizar algunos procesos con relación al préstamo y control de los recursos del laboratorio de industrial, que permita mejorar la calidad de respuesta, organización y almacenamiento de la información. Dado que actualmente se lleva a cabo un ejercicio manual en el proceso de préstamo y control, este presenta inconvenientes para el acceso de los recursos y no permite en muchos casos la escalabilidad de la información, ya que el sitio puede llegar a ser un factor de impedimento para el almacenamiento físico, organización y búsqueda de los mismos. El acceso a la información es muy importante ya que permite informar a una comunidad e involucra a la toma de decisiones sobre hechos relevantes. En la página web de la universidad en el apartado del laboratorio de industrial se puede evidenciar información sobre los recursos y horarios en los cuales pueden estar disponibles para su uso, sin embargo se queda muy corta en el sentido de conocer información actualizada para desarrollar prácticas libres. Este proyecto busca mejorar los procesos de préstamo y control de los recursos haciendo uso de tecnologías web y móviles.. 15.

(16) 3. DEFINICIÓN DEL PROYECTO. 3.1. TÍTULO. PRESTALUD: PROTOTIPO TELEMÁTICO PARA EL PROCESO DE PRÉSTAMO Y CONTROL DE RECURSOS DE LOS LABORATORIOS DE INDUSTRIAL DE LA FACULTAD TECNOLÓGICA DE LA UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS 3.2. PROBLEMA. La gestión de prácticas libres del laboratorio de industrial de la Facultad Tecnológica inicia con la exposición del horario de uso libre de los laboratorios en su página web. El préstamo de las salas, máquinas y entrega de instrumentos se lleva a cabo mediante el diligenciamiento de formatos físicos y requerimiento del carnet para los estudiantes y profesores de la universidad. El administrador del laboratorio tiene que verificar la disponibilidad de las salas, equipos e instrumentos para permitir el acceso o entrega a quien realiza la solicitud. El control del inventario del laboratorio se desarrolla de forma manual a partir de los soportes que brinda el almacén general de la universidad que realiza la entrega de los equipos o instrumentos. El grupo de trabajo realiza una revisión de los equipos registrando los resultados del proceso en informes que describen los daños, necesidades de mantenimiento y organización dentro de la infraestructura del laboratorio. Los estudiantes para realizar las prácticas libres deben ceder el carnet en la administración del laboratorio durante el tiempo que desarrollen la práctica para garantizar la identidad de la persona responsable en la manipulación de los equipos, máquinas, instrumentos, salas, entre otros. Este procedimiento de ceder el carnet durante un tiempo a un recurso de la universidad como laboratorios, biblioteca, salones de talleres o auditorio restringe al estudiante de poder acceder en paralelo a varios recursos. El grupo de trabajo del laboratorio de industrial como se describe anteriormente desarrolla procesos manuales para brindar el acceso a integrantes de la universidad; el control e inventario de las salas, máquinas, equipos e instrumentos es poco eficiente porque les dificulta el análisis de la información recaudada en los formatos físicos para tomar decisiones que promuevan actividades o procesos académicos en pro de toda la comunidad educativa. ¿De qué manera se pueden mejorar, agilizar o facilitar los procesos de préstamo y control del laboratorio de industrial?. 16.

(17) 4. OBJETIVOS. 4.1. OBJETIVO GENERAL. Desarrollar un prototipo telemático para el control del uso e inventario de los recursos (HAS 200, FMS 200, sala de software, trabajo en alturas e instrumentos) del laboratorio de industrial de la Universidad Distrital Francisco José de Caldas Facultad Tecnológica. 4.2. OBJETIVOS ESPECÍFICOS.     . Desarrollar un módulo para la administración de los usuarios del sistema. Implementar un módulo para la gestión del préstamo de los recursos del laboratorio de industrial. Realizar un módulo para la visualización de los recursos del laboratorio de industrial disponibles para su uso. Diseñar API REST y base de datos para la comunicación entre las aplicaciones web y móvil. Construir un módulo para llevar el inventario y hoja de vida de los recursos del laboratorio de industrial.. 17.

(18) 5. MARCO DE REFERENCIA. 5.1. ANTECEDENTES. Documentación de procesos de los laboratorios de Tecnología Industrial e Ingeniería de Producción de la Facultad Tecnológica de la Universidad Distrital Francisco José de Caldas. Tomando como base la calidad se realiza un proceso de documentación en los laboratorios del proyecto curricular de tecnología industrial e ingeniería de producción, partiendo de cada uno de los 5 laboratorios independientemente, para lograr una buena documentación de cada uno ellos y generando la propuesta de los documentos que se deben utilizar, basando el análisis en las normas de calidad como: la ISO 9001:2008, la NTC-ISO-IEC 17025:2000 y la NTCGP 1000:2009; contemplando estas normas porque la primera es la norma que actualmente se maneja para los procesos de certificación de calidad, la segunda es la norma que se utiliza para laboratorios de ensayo y calibración, y la tercera la norma que rige para la calidad de la gestión pública. Partiendo de las necesidades de tener una mejor calidad de laboratorios y servicios que se prestan en ellos se crea el proyecto de iniciar el proceso y la primera fase de la certificación de calidad de cada uno de estos laboratorios ya que como entidad pública estamos en el derecho y la obligación de ser cada vez mejores y se sabe que para lograrlo tenemos que enfocar nuestros espacios y conocimiento hacia la calidad y la mejora continua de los mismos; generando el incentivo de acoger el ciclo PHVA en nuestra universidad y la conciencia de utilizar todas las herramientas que nos ofrece la misma para tener una educación de la mejor calidad posible, se desea documentar los procesos de los laboratorios porque son elementos fundamentales dentro de la formación académica ya que otorgan información y el conocimiento necesario para cada uno de los estudiantes dependiendo la práctica o investigación que se desarrollen en los mismos.7. 7. HERRERA, Sonia y SARMIENTO, Camilo. Documentación de Procesos de los Laboratorios de Tecnología Industrial e Ingeniería de Producción de la Facultad Tecnológica de la Universidad Distrital Francisco José de Caldas con miras hacia la certificación de Calidad. Bogotá D.C.: Universidad Distrital Francisco José de Caldas. Facultad Tecnológica. 2016. 8 p.. 18.

(19) 5.2. MARCO TEÓRICO. 5.2.1 ¿Qué es el control del uso? El Control del Uso se refiere a la administración del acceso de los estudiantes, al cumplimiento de horario de uso de laboratorios, a la entrega y recepción del equipamiento móvil, así como también, velar por la adecuada utilización del equipamiento y la prevención de fallas en su funcionamiento. ¿Qué beneficios tiene realizar un adecuado Control del Uso? Un adecuado control del uso facilita la utilización de los recursos digitales, asegurando el acceso de los estudiantes, mediante el cumplimiento de los horarios establecidos y las reservas de equipamiento móvil realizadas. Además, al promover normas y buenas prácticas, el control del uso facilita el funcionamiento continuo de los recursos (PCs, portátiles, proyectores, software, etc.). Un adecuado control del uso previene descoordinaciones que ocasionen pérdida de horas de clases, pérdida de equipos, deterioros, fallas u otras situaciones que pueden afectar el equipamiento. Además, en caso de ocurrencia, permite detectarlas en forma temprana. El cumplimiento de los horarios del laboratorio y de la reserva del equipamiento móvil (entrega y recepción), beneficia al establecimiento facilitando un acceso equitativo a la tecnología de todos los estudiantes.8 5.2.2 ¿Qué es Scrum? Scrum es un marco de trabajo que nos permite encontrar prácticas emergentes en dominios complejos, como la gestión de proyectos de innovación. No es un proceso completo, y mucho menos, una metodología. En lugar de proporcionar una descripción completa y detallada de cómo deben realizarse las tareas de un proyecto, genera un contexto relacional e iterativo, de inspección y adaptación constante para que los involucrados vayan creando su propio proceso. Esto ocurre debido a que no existen ni mejores ni buenas prácticas en un contexto complejo. Es el equipo de involucrados quien encontrará la mejor manera de resolver sus problemáticas. Este tipo de soluciones serán emergentes. El equipo de desarrollo se encuentra apoyado en dos roles: el ScrumMaster y el Product Owner. El ScrumMaster es quien vela por la utilización de Scrum, la remoción de impedimentos y asiste al equipo a que logre su mayor nivel de performance posible. Puede ser considerado un coach o facilitador encargado de acompañar al equipo de desarrollo. El Product Owner es quien representa al. 8. MINISTERIO DE EDUCACIÓN GOBIERNO DE CHILE. Guía para Control del Uso [en línea], [revisado 11 julio 2017]. Disponible en Internet: http://www.enlaces.cl/wp-content/uploads/Control_del_Uso.pdf. 19.

(20) negocio, stakeholders, cliente y usuarios finales. Tiene la responsabilidad de conducir al equipo de desarrollo hacia el producto adecuado. El progreso de los proyectos que utilizan Scrum se realiza y verifica en una serie de iteraciones llamadas Sprints. Estos Sprints tienen una duración fija, pre-establecida de no más de un mes. Al comienzo de cada Sprint el equipo de desarrollo realiza un compromiso de entrega de una serie de funcionalidades o características del producto en cuestión. Al finalizar el Sprint se espera que estas características comprometidas estén terminadas, lo que implica su análisis, diseño, desarrollo, prueba e integración al producto. En este momento es cuando se realiza una reunión de revisión del producto construido durante el Sprint, donde el equipo de desarrollo muestra lo construido al Product Owner y a cualquier stakeholder interesado en participar. El feedback obtenido en esta reunión puede ser incluido entre las funcionalidades a construir en futuros Sprints.9 Scrum estructura el desarrollo del producto en ciclos o iteraciones que denomina Sprints. La idea central es que un Sprint se fije objetivos (funcionalidades que desarrollará) al comienzo del mismo, y que el trabajo acordado esté finalizado al terminar. Antes de comenzar un Sprint, el Product Owner discute y define con el resto del equipo qué requisitos o ítems del Product Backlog habrá que desarrollar en el Sprint, construyendo con ellos el Sprint Backlog. Se parte de requisitos para generar tareas. El Sprint Backlog, por lo tanto, no es un subconjunto del Product Backlog, ya que sus ítems son tareas, mientras que los de éste son requisitos. En cuanto a la organización de los Sprints, también existen algunas reglas. Durante un Sprint, no se pueden cambiar los integrantes de un grupo de trabajo ni el Sprint Backlog. Lo único que se puede hacer es cancelar un Sprint por razones de fuerza mayor. Durante el Sprint, se realizan diariamente las Scrum Daily Meetings, en las que participa todo el equipo, y en las que se analiza el avance y el trabajo del día. Estas reuniones son las que dieron nombre al método. El Scrum Master hace de moderador de estas reuniones. Al finalizar el Sprint, se realiza una reunión denominada Sprint Review Meeting, de la que se obtienen las lecciones aprendidas, que se dejan registradas en un artefacto denominado Sprint Retrospective.. 9. ALAIMO, Diego Martín. Proyectos ágiles con Scrum: flexibilidad, aprendizaje, innovación y colaboración en contextos complejos. 1 ed. Ciudad Autónoma de Buenos Aires: Kleer, 2013. 22 p. EBook.. 20.

(21) En cuanto a las métricas, se pueden usar las que desee el equipo. No obstante, hay un reporte típico de Scrum, denominado Burndown Chart. El objetivo de este gráfico es hacer un seguimiento sobre la base del trabajo que falta por hacer. Se puede realizar durante el Sprint, en cuyo caso se llama Sprint Burndown Chart, y muestra día a día cuánto trabajo falta realizar dentro del Sprint, y su relación con el que se esperaba realizar. También se puede proceder Sprint a Sprint el Product Burndown Chart, en el nivel del proyecto. Visto en forma más global, un proyecto Scrum tiene tres fases:  Inicio: incluye la planificación de una versión, con una primera estimación en tiempo y costo, y un diseño de alto nivel.  Fase iterativa, con varios Sprints.  Cierre: preparación para la versión desplegable, documentación final y entornos necesarios.10 5.2.3 Protocolos de comunicación. 5.2.3.1. La web y el protocolo HTTP. Dentro del mundo de Internet destaca una aplicación que es, con mucho, la más utilizada: la Word Wide Web (WWW), a la que nos referiremos coloquialmente como la web. Su gran éxito se debe a la facilidad de uso, dado que simplifica el acceso a todo tipo de información, y a que está información es presentada de forma atractiva. Básicamente, la web nos ofrece un servicio de acceso a información distribuida en miles de servidores en todo Internet, que nos permite ir navegando por todo tipo de documentos multimedia gracias a un sencillo sistema de hipervínculos. Para la comunicación entre los clientes y los servidores de esta aplicación, se emplea el protocolo HTTP (Hypertext Transfer Protocol), que será el objeto de estudio de este apartado. El protocolo HTTP HTTP es un sencillo protocolo cliente-servidor que articula los intercambios de información entre los navegadores web y los servidores web. Fue propuesto por Tim Berners-Lee, atendiendo a las necesidades de un sistema global de distribución de información como la World Wide Web. En la web los servidores han de escuchar en el puerto 80, esperando la conexión de algún cliente web. Versión 1.0 del protocolo HTTP Con la popularización de la aplicación WWW, pronto se vio la necesidad de ampliar este sencillo protocolo para permitir nuevas funcionalidades. Se definió la versión 10. FONTELA, Carlos. UML: modelado de software para profesionales. Buenos Aires.: Alfaomega Grupo Editor Argentino, 2011. 23-24 p.. 21.

(22) 1.0 del protocolo, que añadía nuevos métodos (PUT, POST) además de permitir el intercambio de cabeceras entre cliente y servidor. Aunque el método GET es el más utilizado, en la versión 1.0 se añaden nuevos métodos. A continuación se incluye una descripción: GET: Petición de lectura de un recurso. POST: Envió de información asociada a un recurso del servidor. PUT: Creación de un nuevo recurso en el servidor. DELETE: Eliminación de un recurso. HEAD: El servidor solo transmitirá las cabeceras, no la página.11 De manera esquemática, el funcionamiento de HTTP es el siguiente: el cliente establece una conexión TCP hacia el servidor, hacia el puerto HTTP (o el indicado en la dirección de conexión), envía un comando HTTP de petición de un recurso (junto con algunas cabeceras informativas) y por la misma conexión el servidor responde con los datos solicitados y con algunas cabeceras informativas. El protocolo define además cómo codificar el paso de parámetros entre páginas, el tunelizar las conexiones (para sistemas de firewall), define la existencia de servidores intermedios de cache, etc. Las directivas de petición de información que define HTTP 1.1 (la versión considerada estable y al uso) son: GET: Petición de recurso. POST: Petición de recurso pasando parámetros. HEAD: Petición de datos sobre recurso. PUT: Creación o envío de recurso. DELETE: Eliminación de recurso. TRACE: Devuelve al origen la petición tal como se ha recibido en el receptor, para depurar errores. OPTIONS: Sirve para comprobar las capacidades del servidor. CONNECT: Reservado para uso en servidores intermedios capaces de funcionar como túneles. Respuestas en HTTP Las respuestas en HTTP son muy similares a las peticiones. Una respuesta estándar a una petición de una página sería similar a lo siguiente: HTTP/1.1 200 OK Date: Mon, 04 Aug 2003 15:19:10 GMT Server: Apache/2.0.40 (Red Hat Linux) Last-Modified: Tue, 25 Mar 2003 08:52:53 GMT Accept-Ranges: bytes Content-Length: 428 Connection: close 11. TOMÁS, Jesús. El gran libro de Android. 5 ed. México.: Alfaomega, 2016. 477 p.. 22.

(23) <HTML> ... En ella podemos observar que la primera línea nos responde con la versión del protocolo empleada para enviarnos la página, seguida de un código de retorno y una frase de retorno. El código de retorno puede adoptar uno de los siguientes valores: - 1xx Petición recibida, continúa en proceso. - 2xx Correcta. Petición procesada correctamente. - 3xx Redirección. La petición debe repetirse o redirigirse. - 4xx Error de cliente. No se puede procesar la petición porque ésta es incorrecta, no existe, etc. - 5xx Error de servidor. El servidor ha fallado intentando procesar la petición, que a priori es correcta. La frase de retorno dependerá de la implementación, pero sólo sirve como aclaratorio del código de retorno. Después del estatus aparece una serie de campos de control, con el mismo formato que en las cabeceras de la petición que nos informan del contenido (fecha de creación, longitud, versión del servidor, etc.).12 5.2.3.2. Servicios web basados en REST. En primer lugar conviene destacar que el término REST se refiere a una arquitectura en lugar de a un protocolo en concreto, como es el caso de SOAP. A diferencia de SOAP, no vamos a añadir una capa adicional a la pila de protocolos, sino que utilizaremos directamente el protocolo HTTP. Siendo estrictos, la arquitectura REST no impone el uso de HTTP; no obstante, en la práctica se entiende que un servicio web basado en REST es aquel que se implementa directamente sobre la web. Este planteamiento supone seguir los principios de la aplicación WWW, pero en lugar de solicitar páginas web solicitaremos servicios web. Los principios básicos de la aplicación WWW y, por tanto, los de REST son:  . Transporte de datos mediante HTTP, utilizando las operaciones de este protocolo, que son GET, POST, PUT y DELETE. Los diferentes servicios son invocados mediante el espacio de URI unificado. Como ya se ha tratado, una URI identifica un recurso en internet. Este sistema ha demostrado ser flexible, sencillo y potente al mismo tiempo. Se cree que fue uno de los principales factores que motivó el éxito de WWW.. 12. MATEU, Carles. Desarrollo de aplicaciones web. Barcelona.: Fundació per a la Universitat Oberta de Catalunya, 2004. 1418 p.. 23.

(24) . La codificación de datos es identificada mediante tipos MIME (text/html, image/gif, etc.), aunque el tipo de codificación preferido es XML (text/xml).. Las ventajas de REST derivan de su simplicidad, Entre estas podemos destacar: mejores tiempos de respuesta y disminución de sobrecarga tanto en cliente como en servidor, mayor estabilidad frente a futuros cambios y, también, una gran sencillez en el desarrollo de clientes, que solo han de ser capaces de realizar interacciones HTTP y codificar información en XML. Como inconveniente podemos indicar que, al igual que ocurre con el protocolo HTTP, no se mantiene el estado. Es decir, cada solicitud es tratada por el servidor de forma independiente sin recordar solicitudes anteriores.13 5.2.4 Servidor web. 5.2.4.1. Node.js. La meta número uno declarada de Node es "proporcionar una manera fácil para construir programas de red escalables". ¿Cuál es el problema con los programas de servidor actuales? Hagamos cuentas. En lenguajes como Java™ y PHP, cada conexión genera un nuevo hilo que potencialmente viene acompañado de 2 MB de memoria. En un sistema que tiene 8 GB de RAM, esto da un número máximo teórico de conexiones concurrentes de cerca de 4.000 usuarios. A medida que crece su base de clientes, si usted desea que su aplicación soporte más usuarios, necesitará agregar más y más servidores. Desde luego, esto suma en cuanto a los costos de servidor del negocio, a los costos de tráfico, los costos laborales, y más. Además de estos costos están los costos por los problemas técnicos potenciales — un usuario puede estar usando diferentes servidores para cada solicitud, así que cualquier recurso compartido debe almacenarse en todos los servidores. Por todas estas razones, el cuello de botella en toda la arquitectura de aplicación Web (incluyendo el rendimiento del tráfico, la velocidad de procesador y la velocidad de memoria) era el número máximo de conexiones concurrentes que podía manejar un servidor. Node resuelve este problema cambiando la forma en que se realiza una conexión con el servidor. En lugar de generar un nuevo hilo de OS para cada conexión (y de asignarle la memoria acompañante), cada conexión dispara una ejecución de evento dentro del proceso del motor de Node. Node también afirma que nunca se quedará en punto muerto, porque no se permiten bloqueos y porque no se bloquea directamente para llamados E/S. Node afirma que un servidor que lo ejecute puede soportar decenas de miles de conexiones concurrentes.. 13. TOMÁS, Jesús. El gran libro de Android. 5 ed. México.: Alfaomega, 2016. 489-490 p.. 24.

(25) Entonces, ahora que usted tiene un programa que puede manejar cientos de miles de conexiones concurrentes, ¿qué puede usted construir en realidad con Node? Sería extraordinario si usted tuviera una aplicación Web que necesitara de toda esta cantidad de conexiones. Ese es uno de esos problemas del tipo "si usted tiene este problema, no es un problema". Antes de pasar a ello, observemos cómo funciona Node y cómo está diseñado que se ejecute. Cómo funciona Node Node ejecuta V8 JavaScript. Espere... ¿qué? ¿JavaScript en el servidor? Sí, leyó correctamente. El JavaScript del lado del servidor puede ser un concepto nuevo para cualquiera que haya trabajado exclusivamente con JavaScript del lado del cliente, pero la idea en sí no es tan inverosímil — ¿por qué no utilizar el mismo lenguaje de programación que usted usa en el cliente del lado del servidor? ¿Qué es el V8? El motor V8 JavaScript es el motor JavaScript subyacente que Google usa con su navegador Chrome. Pocas personas piensan en lo que en realidad sucede con JavaScript en el cliente. Bien, un motor JavaScript en realidad interpreta el código y lo ejecuta. Con el V8, Google creó un intérprete ultra-rápido escrito en C++, con otro aspecto único: usted puede descargar el motor e incorporarlo a cualquier aplicación que desee. No está restringido a ejecutarse en un navegador. Así, Node en realidad usa el motor V8 JavaScript escrito por Google y le da otro propósito para usarlo en el servidor. ¡Perfecto! Para qué crear un nuevo lenguaje cuando ya hay una buena solución disponible.14 5.2.4.2. Express. Es un módulo de NodeJS implementado por terceras partes. Es el módulo por excelencia para el desarrollo web, proporcionando una API muy completa, con múltiples funcionalidades necesarias en cualquier aplicación web. Los objetos application, request y response Objeto application: Es una instancia o referencia asociada al módulo Express. Con frecuencia se utiliza para configurar la aplicación Express u obtener información de las características de la misma. Objeto request: Es un objeto, que encapsula a su vez a otro objeto utilizado en el módulo http de NodeJS, llamado request. Almacena información de la última petición HTTP realizada al servidor, como por ejemplo parámetros de la petición o cabeceras HTTP.. 14. ABERNETHY, Michael. ¿Simplemente qué es Node.js? IBM developerWorks [en línea], 14 de junio de 2011 [revisado 20 julio 2017]. Disponible en Internet: https://www.ibm.com/developerworks/ssa/opensource/library/os-nodejs/index.html. 25.

(26) Objeto response: Es un objeto, que encapsula a su vez a otro objeto utilizado en el módulo http de NodeJS, llamado response. Almacena la información a proporcionar, como respuesta ante la última petición HTTP realizada al servidor. La abreviatura común para trabajar con el objeto es res.15 5.2.4.3. Json web token. JSON Web Token (JWT) es un estándar abierto (RFC-7519) basado en JSON para crear un token que sirva para enviar datos entre aplicaciones o servicios y garantizar que sean válidos y seguros. El caso más común de uso de los JWT es para manejar la autenticación en aplicaciones móviles o web. Para esto cuando el usuario se quiere autenticar manda sus datos de inicio del sesión al servidor, este genera el JWT y se lo manda a la aplicación cliente, luego en cada petición el cliente envía este token que el servidor usa para verificar que el usuario este correctamente autenticado y saber quién es. Este igual no es el único caso de uso para JWT, es posible usarlo para transferir cualquier dato entre servicios de nuestra aplicación y asegurarnos de que sean siempre válido. Por ejemplo si tenemos un servicio de envío de email otro servicio podría enviar una petición con un JWT junto al contenido del mail o cualquier otro dato necesario y que estemos seguros que esos datos no fueron alterados de ninguna forma.16 5.2.5 Gestión de la información. 5.2.5.1. Bases de datos no relacionales. Durante la evolución del modelo relacional de almacenamiento de datos, otros diferentes modelos de almacenamiento también han surgido. Uno de los más conocidos es el modelo de almacenamiento de datos orientado a documentos. Este tipo de modelo de almacenamiento de datos no utiliza tablas. Almacena la información en unas estructuras jerárquicas, llamadas colecciones. Cada uno de los elementos de una colección es un documento. El formato más utilizado para representar la información de un documento en XML o JSON. Ambos, son dos formatos de representación de la información de forma jerarquizada, con diferentes niveles de jerarquía, normalmente en función de la importancia del dato. JSON representa la información en una cadena de caracteres y XML lo hace utilizando un lenguaje de etiquetas para establecer las jerarquías.. 15. LÓPEZ JURADO, Francisco Carlos. Api rest con mean para contenidos multimedia. Madrid.: Universidad Politécnica de Madrid. Escuela Técnica Superior de Ingeniería de Sistemas Informáticos. 2015. 37 p. 16 XALAMBRÍ, Sergio Daniel. Introducción a JSON Web Tokens (JWT). Blog Platzi [en línea], [revisado 20 Agosto 2017]. Disponible en Internet: https://platzi.com/blog/introduccion-json-web-tokens/. 26.

(27) Esta representación de la información, permite almacenar una gran cantidad de datos, que tienen cierta relación entre sí. Al almacenar diferentes tipos de datos en una misma estructura, pero formando parte de una misma colección, las operaciones típicas de manipulación de la información (acceso, inclusión, modificación o borrado), se aceleran en gran medida. Las BBDDs no relacionales, tienen que trabajar con menos contenedores de información (colecciones) que las BBDDs relacionales, que necesitaría manipular una mayor cantidad de tablas. Las colecciones pueden ser más heterogéneas que una tabla, albergando datos de distinta tipología dentro de un mismo entorno de manipulación. Otra de las ventajas de las BBDDs no relacionales, es la flexibilidad para modificar modelos. En una BBDD relacional, es necesario modificar la estructura de una tabla y los registros existentes, para añadir un nuevo campo. En cambio, en las BBDDs no relacionales, se puede añadir un nuevo atributo a una colección, sin necesidad de modificar los datos de la colección. A partir del cambio, lo nuevos documentos que se almacenen en la colección disponen de este nuevo campo. Los anteriores documentos carecen de esta propiedad. No existen problemas de incompatibilidad de documentos en una misma colección, al ser permitida la heterogeneidad en este tipo de bases de datos. En las BBDDs relacionales es algo impensable. Al disponer de documentos dentro de una misma colección y que algunos de ellos dispongan de atributos diferentes, permite asignar la responsabilidad de la estructura de cada colección a la aplicación web, en lugar de ser responsabilidad de la propia BBDD. Esta ventaja acelera notablemente el proceso de desarrollo.17 5.2.5.2. MongoDB. MongoDB (que proviene de «humongous») es la base de datos NoSQL líder y permite a las empresas ser más ágiles y escalables. Organizaciones de todos los tamaños están usando MongoDB para crear nuevos tipos de aplicaciones, mejorar la experiencia del cliente, acelerar el tiempo de comercialización y reducir costes. Es una base de datos ágil que permite a los esquemas cambiar rápidamente cuando las aplicaciones evolucionan, proporcionando siempre la funcionalidad que los desarrolladores esperan de las bases de datos tradicionales, tales como índices secundarios, un lenguaje completo de búsquedas y consistencia estricta.. 17. LÓPEZ JURADO, Francisco Carlos. Api rest con mean para contenidos multimedia. Madrid.: Universidad Politécnica de Madrid. Escuela Técnica Superior de Ingeniería de Sistemas Informáticos. 2015. 62-63 p.. 27.

(28) MongoDB ha sido creado para brindar escalabilidad, rendimiento y gran disponibilidad, escalando de una implantación de servidor único a grandes arquitecturas complejas de centros multidatos. MongoDB brinda un elevado rendimiento, tanto para lectura como para escritura, potenciando la computación en memoria (in-memory). La replicación nativa de MongoDB y la tolerancia a fallos automática ofrece fiabilidad a nivel empresarial y flexibilidad operativa. 18 5.2.5.3. Mongoose. Mongoose es un módulo NodeJS implementado por terceras partes. Puede ser empleado en una aplicación Express, para el manejo de BBDDs MongoDB. Emplea esquemas, para la definición de las colecciones de la BBDD. Estos esquemas son estructuras JSON, en las que se definen los atributos de la colección y las características de cada uno. El modelado se realiza con estos esquemas y a partir del mismo, los documentos de una colección pueden ser manipulados como objetos, en una aplicación Express. Gracias a la definición de estos esquemas, Mongoose aporta estructuración en BBDDs no relacionales, que no tienen una estructura fija para sus colecciones. Como cualquier otro módulo de NodeJS implementado por terceras partes, su instalación es sencilla, incluyendo la dependencia correspondiente al módulo, en el fichero package.json, Posteriormente a la inclusión de la dependencia, se hace uso de NPM para la instalación del código fuente asociado al módulo. Para definir los esquemas de cada colección, Mongoose ofrece un objeto llamado Schema para la definición de las estructuras. Tras la definición de las estructuras asociadas a cada colección, es posible crear instancias del objeto esquema, para gestionar los documentos de la colección como objetos. Mediante la manipulación de estos objetos, es posible realizar las operaciones de creación, consulta, actualización y borrado de la información.19 5.2.6 Sistema de control de versiones. ¿Qué es el control de versiones, y por qué debería importarte? El control de versiones es un sistema que registra los cambios realizados sobre un archivo o conjunto de archivos a lo largo del tiempo, de modo que puedas recuperar versiones específicas más adelante. Los ejemplos de este libro utilizan el control de versiones. 18. MONGODB. Reinventando la gestión de datos. [en línea], [revisado 20 julio 2017]. Disponible en Internet: https://www.mongodb.com/es 19 LÓPEZ JURADO, Francisco Carlos. Api rest con mean para contenidos multimedia. Madrid.: Universidad Politécnica de Madrid. Escuela Técnica Superior de Ingeniería de Sistemas Informáticos. 2015. 76 p.. 28.

(29) para el código fuente, pero puedes emplearlo para casi cualquier tipo de archivo que encuentres en un ordenador. Si eres diseñador gráfico o web, y quieres mantener cada versión de una imagen o diseño (algo que sin duda quieres), un sistema de control de versiones (Version Control System o VCS en inglés) es una elección muy sabia. Te permite revertir archivos a un estado anterior, revertir el proyecto entero a un estado anterior, comparar cambios a lo largo del tiempo, ver quién modificó por última vez algo que puede estar causando un problema, quién introdujo un error y cuándo, y mucho más. Usar un VCS también significa que si fastidias o pierdes archivos, puedes recuperarlos fácilmente. Además, obtienes todos estos beneficios a un coste muy bajo. 5.2.6.1. Sistemas de control de versiones distribuidos. Es aquí donde entran los sistemas de control de versiones distribuidos (Distributed Version Control Systems o DVCSs en inglés). En un DVCS (como Git, Mercurial, Bazaar o Darcs), los clientes no sólo descargan la última instantánea de los archivos: replican completamente el repositorio. Así, si un servidor muere, y estos sistemas estaban colaborando a través de él, cualquiera de los repositorios de los clientes puede copiarse en el servidor para restaurarlo. Cada vez que se descarga una instantánea, en realidad se hace una copia de seguridad completa de todos los datos. Es más, muchos de estos sistemas se las arreglan bastante bien teniendo varios repositorios con los que trabajar, por lo que puedes colaborar con distintos grupos de gente de maneras distintas simultáneamente dentro del mismo proyecto. Esto te permite establecer varios tipos de flujos de trabajo que no son posibles en sistemas centralizados, como pueden ser los modelos jerárquicos.20 5.2.6.2. Git. Es uno de los SCV distribuidos más populares, inicialmente desarrollado para Linux. Git permite a varios programadores trabajar paralelamente con sus propias copias de trabajo obtenidas de un repositorio, como lo efectúan todos los SCV distribuidos. Git está compuesto de una estructura de tres secciones, las cuales son:  Directorio de Git. Es donde se guardan los objetos que mantienen el historial con los cambios que se han producido en el proyecto.  Directorio de trabajo. Contiene los archivos de la versión actual del proyecto sobre los que se realizan los cambios.. 20. CHACON, Scott. Pro Git, el libro oficial de Git. LIBROSWEB [en línea], [revisado 20 julio 2017]. Disponible en Internet: http://librosweb.es/libro/pro_git/capitulo_1/acerca_del_control_de_versiones.html. 29.

(30) . Área de preparación o índice. Es un archivo que incluye la información de los cambios que se van a enviar en la próxima confirmación.. Git utiliza ramas favoreciendo el trabajo paralelo sobre un mismo proyecto. En el momento de iniciar un repositorio se genera una rama maestra, de donde se extienden nuevas ramas que incluirán todo el historial del proyecto. Cuando se han realizado los cambios en una rama, permite que ésta se combine con otras ramas, uniéndose a la rama maestra (merge), integrando historiales y archivos de las ramas participantes; es entonces cuando se genera una nueva versión. El proceso de actualización de los archivos contenidos en un repositorio y la posterior generación de una nueva versión utilizando Git es el siguiente: cada desarrollador debe generar una copia del repositorio original en su computadora, creando un repositorio local. Este repositorio local contiene toda la información del historial de cambios y los archivos del directorio de trabajo. En esta etapa el desarrollador puede empezar a trabajar en el repositorio Git local, creando y modificando los archivos de acuerdo a sus requerimientos. Para crear y almacenar una nueva versión el procedimiento es el siguiente: primeramente se debe consultar el estado del repositorio, con lo cual se obtiene un listado de los archivos que han sido modificados. Enseguida, se seleccionan los que se almacenarán en la nueva versión, esto es, los archivos que contienen cambios y se quieren incluir en la nueva versión. Posteriormente, se detallan los cambios que se han realizado en los archivos, esto servirá a los desarrolladores para identificar las versiones. Al finalizar estos pasos, Git almacenará en la sección "área de preparación" una nueva copia en el historial del proyecto con todos los cambios incluidos. Posteriormente, el desarrollador debe confirmar los cambios, con lo cual Git almacenará una nueva versión del proyecto en la sección "directorio de git" conteniendo los archivos que sufrieron cambios y, de los archivos que no fueron modificados solo guarda el enlace al archivo anterior, que ya se encontraba en el repositorio del proyecto. En esta parte del proceso del funcionamiento de Git, los cambios y actualización de versión solo se han realizado en el repositorio local del desarrollador. Enseguida se debe realizar un proceso de fusión (merge), el cual consiste en combinar una o varias ramas de un proyecto en un repositorio local al repositorio origen o al repositorio de otros desarrolladores. La acción de merge realiza una combinación de los historiales y archivos de las dos ramas implicadas. Git detecta los cambios que existen en las dos ramas, combinándolas y generando una única versión con los cambios realizados en ambas ramas. Al efectuar el merge se cambian todos los archivos en la rama del proyecto destino, generándose una nueva versión.21. 21. Tello, Edgar; Sosa, Claudia; Tello, Diego. Revisión de los sistemas de control de versiones utilizados en el desarrollo de software. En: Revista de Ingenierías USBMED. Junio, 2012. vol. 3, no. 1, p. 78.. 30.

(31) 5.2.7 Cliente web. 5.2.7.1. JavaScript. JavaScript es un lenguaje de programación que se utiliza principalmente para crear páginas web dinámicas. Una página web dinámica es aquella que incorpora efectos como texto que aparece y desaparece, animaciones, acciones que se activan al pulsar botones y ventanas con mensajes de aviso al usuario. Técnicamente, JavaScript es un lenguaje de programación interpretado, por lo que no es necesario compilar los programas para ejecutarlos. En otras palabras, los programas escritos con JavaScript se pueden probar directamente en cualquier navegador sin necesidad de procesos intermedios. A pesar de su nombre, JavaScript no guarda ninguna relación directa con el lenguaje de programación Java. Legalmente, JavaScript es una marca registrada de la empresa Sun Microsystems, como se puede ver en 22 http://www.sun.com/suntrademarks/. 5.2.7.2. AngularJS. Es un framework diseñado para construir aplicaciones web, que sean servidas bajo el concepto de una única página o documento HTML, que va alterando su contenido en función de las operaciones que un usuario realiza. Esto se consigue, modificando una única vista dinámicamente tras cada operación del usuario. Uno de los objetivos que persigue y logra, es la potenciación de las características del lenguaje HTML, utilizado para la estructuración de una vista. AngularJS lo consigue al añadir nuevas etiquetas a este lenguaje, junto a nuevos atributos para etiquetas ya existentes. Por otro lado, es un framework de fácil utilización en proyectos con menor enjundia. A medida que el proyecto es más grande y existe una mayor complejidad en los algoritmos, las implementaciones con AngularJS pueden aumentar en dificultad exponencialmente. No obstante, si el desarrollador o equipo de desarrollo tiene claro los conceptos clave del framework, se reduce esta dificultad considerablemente.23. 22. Eguiluz, Javier. Introducción a JavaScript. LIBROSWEB. [en línea], [revisado 20 julio 2017]. Disponible en Internet: http://librosweb.es/libro/javascript/capitulo_1.html 23 LÓPEZ JURADO, Francisco Carlos. Api rest con mean para contenidos multimedia. Madrid.: Universidad Politécnica de Madrid. Escuela Técnica Superior de Ingeniería de Sistemas Informáticos. 2015. 79 p.. 31.

(32) 5.2.8 Cliente rest móvil. 5.2.8.1. Android y arquitectura. Android constituye un sistema operativo para dispositivos móviles. Las aplicaciones para Android se programan en el lenguaje Java y C++, y son ejecutadas en una máquina virtual llamada Dalvik, el núcleo de la cual está basado este sistema operativo es Linux. Maneja la licencia de distribución apache 2.0, lo que es denominado software de libre distribución. Android es patrocinado principalmente por la compañía Google y por un conjunto de empresas que conforman el Open Handset Alliance (OHA). Actualmente Android ha conseguido reunir los elementos necesarios para desarrollar y controlar las funcionalidades ofrecidas por los dispositivos móviles (GPS, NFC, Videojuegos, Etc.), estandarizando así el desarrollo de aplicaciones para una gran cuota del mercado actual. Además de todo ello, otro aspecto básico para entender la visión de Android es que proyecta facilitar la integración de estos dispositivos con las contingencias cada vez mayores ofrecidas por la Web. Por ejemplo, aplicaciones desarrolladas en Android que indican la posición en coordenadas a través del servicio Google Maps, introducir medios de pago electrónico por medio del chip NFC de un teléfono con Android, entre otras aplicaciones. La arquitectura empleada de Android se caracteriza porque cada una de las capas se apoya en los servicios ofrecidos en las capas inferiores. La capa 1 corresponde al núcleo de Android, que utiliza a su vez el núcleo Linux como una capa de integración para el hardware disponible en los dispositivos móviles. Esta capa contiene los drives necesarios para que los componentes de hardware puedan comunicarse. La capa intermedia proporciona las librerías que son escritas en C/C++, que proporcionan la mayor parte de sus características. Los últimos niveles corresponden al framework de aplicaciones que está escrito directamente en lenguaje Java y que representa fundamentalmente la herramienta para el desarrollo de aplicaciones en Android.24 ¿Qué hace que Android sea especial?  Plataforma realmente abierta. Es una plataforma de desarrollo libre basada en Linux y de código abierto. Una de sus grandes ventajas es que se puede usar y customizar el sistema sin pagar royalties.  Adaptable a cualquier tipo de hardware. Android no ha sido diseñado exclusivamente para su uso en teléfonos y tabletas. Hoy en día podemos 24. ACOSTA LÓPEZ, Alberto; MANZANO GONZÁLEZ, Dago José; MARTÍNEZ MORALES, Carlos A. Diseño e implementación de un prototipo para el registro y verificación de activos fijos utilizando plataforma android y tecnología NFC. Bogotá D.C.: Universidad Distrital Francisco José de Caldas. Facultad de ingeniería. 2014.. 32.

(33) .    . . . encontrar relojes, gafas, cámaras, TV, sistemas para automóviles, electrodomésticos y una gran variedad de sistemas empotrados que se basan en este sistema operativo, lo cual tiene sus evidentes ventajas, pero también va a suponer un esfuerzo adicional para el programador. La aplicación ha de funcionar correctamente en dispositivos con una gran variedad de tipos de entrada, pantalla, memoria, etc. Esta característica contrasta con la estrategia de Apple: en IOS tenemos que desarrollar una aplicación para iPhone y otra diferente para iPad. Portabilidad asegurada. Las aplicaciones finales son desarrolladas en Java, lo que nos asegura que podrán ser ejecutadas en cualquier tipo de CPU, tanto presente como futuro. Esto se consigue gracias al concepto de máquina virtual. Arquitectura basada en componentes inspirados en Internet. Por ejemplo, el diseño de la interfaz de usuario se hace en XML, lo que permite que una misma aplicación se ejecute en un reloj de pantalla reducida o en un televisor. Filosofía de dispositivo siempre conectado a Internet. Muchas aplicaciones solo funcionan si disponemos de una conexión permanente a Internet. Por ejemplo, comunicaciones interpersonales o navegación con mapas. Gran cantidad de servicios incorporados. Por ejemplo, localización basada tanto en GPS como en redes, bases de datos con SQL, reconocimiento y síntesis de voz, navegador, multimedia, etc. Aceptable nivel de seguridad. Los programas se encuentran aislados unos de otros gracias al concepto de ejecución dentro de una caja, que hereda de Linux. Además, cada aplicación dispone de una serie de permisos que limitan su rango de actuación (servicios de localización, acceso a Internet, etc.). Desde la versión 6.0 el usuario puede conceder o retirar permisos a las aplicaciones en cualquier momento. Optimizado para baja potencia y poca memoria. En el diseño de Android se ha tenido en cuenta el hardware específico de los dispositivos móviles. Por ejemplo, Android utiliza la máquina virtual ART (o Dalvik en versiones antiguas). Se trata de una implementación de Google de la máquina virtual Java optimizada para dispositivos móviles. Alta calidad de gráficos y sonido. Gráficos vectoriales suavizados, animaciones, gráficos en 3D basados en OpenGL. Incorpora los codecs estándares más comunes de audio y video, incluyendo H.264 (AVC), MP3, AAC, etc.25. 5.2.8.2. Retrofit. Retrofit es un cliente REST para Android y Java creado por Square. Hace relativamente fácil el proceso de obtener un JSON (u otra estructura de datos) desde un WebService REST. Retrofit usa la librería OkHttp para realizar las peticiones HTTP. Suele configurarse con algún convertidor para la serialización de 25. TOMÁS, Jesús. El gran libro de Android. 5 ed. México: Alfaomega, 2016. 24 p.. 33.

(34) datos. Generalmente cuando se obtienen JSON's se suele usar como convertidor la librería GSon, pero se pueden utilizar otros convertidores por ejemplo para XML.26 5.2.8.3. Gson. Gson es una biblioteca de Java que se puede usar para convertir objetos de Java en su representación JSON. También puede ser usado para convertir una cadena JSON a su objeto Java equivalente. Gson puede funcionar con objetos Java arbitrarios, incluyendo objetos preexistentes de los cuales no se tiene el código fuente. Existen unos pocos proyectos de código abierto que puedan convertir objetos Java a JSON. La mayoría no soportan el uso de las colecciones genéricas de Java. Gson considera esto como un objetivo esencial en su diseño.27. 26. LAZA, Javier. Desarrollo de una aplicación Android para la localización proactiva de establecimientos. Madrid.: Universidad Politécnica de Madrid. Escuela Técnica Superior de Ingeniería de Sistemas Informáticos. 2016. 13 p. 27 Chillarón, Diego Castaño. Desarrollo de una plataforma social para compartir imágenes en dispositivos Android. Madrid.: Universidad Politécnica de Madrid. Escuela Técnica Superior de Ingeniería de Sistemas Informáticos. 2016. 26 p.. 34.