sistema automático para control y seguridad en ciclo
TRANSCRIPT
Universidad de La Salle Universidad de La Salle
Ciencia Unisalle Ciencia Unisalle
Ingeniería en Automatización Facultad de Ingeniería
1-31-2014
Sistema automático para control y seguridad en ciclo Sistema automático para control y seguridad en ciclo
parqueaderos parqueaderos
Jorge Wilson Salinas Corba Universidad de La Salle, Bogotá
Jorge Adrián Amaya Espitia Universidad de La Salle, Bogotá
Follow this and additional works at: https://ciencia.lasalle.edu.co/ing_automatizacion
Part of the Computer Engineering Commons, and the Mechanical Engineering Commons
Citación recomendada Citación recomendada Salinas Corba, J. W., & Amaya Espitia, J. A. (2014). Sistema automático para control y seguridad en ciclo parqueaderos. Retrieved from https://ciencia.lasalle.edu.co/ing_automatizacion/29
This Trabajo de grado - Pregrado is brought to you for free and open access by the Facultad de Ingeniería at Ciencia Unisalle. It has been accepted for inclusion in Ingeniería en Automatización by an authorized administrator of Ciencia Unisalle. For more information, please contact [email protected].
SISTEMA AUTOMÁTICO PARA CONTROL Y SEGURIDAD EN CICLO-PARQUEADEROS.
JORGE WILSON SALINAS CORBA 44961125
JORGE ADRIÁN AMAYA ESPITIA 45101438
UNIVERSIDAD DE LA SALLE
PROGRAMA DE INGENIERIA EN AUTOMATIZACIÓN
BOGOTÁ D.C.
2014
SISTEMA AUTOMÁTICO PARA CONTROL Y SEGURIDAD EN CICLO-PARQUEADEROS.
JORGE WILSON SALINAS CORBA
JORGE ADRIÁN AMAYA ESPITIA
Monografía para optar por el título de
Ingeniero de diseño & Automatización Electrónica
Ingeniero en Automatización
Directora
DIANA JANETH LANCHEROS CUESTA
Msc. Tecnología de la información.
UNIVERSIDAD DE LA SALLE
PROGRAMA DE INGENIERIA EN AUTOMATIZACIÓN
BOGOTÁ D.C.
2014
Nota de Aceptación
_____________________________________________
_____________________________________________
_____________________________________________
_____________________________________________
_____________________________________________
_____________________________________________
_____________________________________________
_____________________________________________
Firma del Director
_____________________________________________
Firma del Jurado
_____________________________________________
Firma del Jurado
Bogotá D.C. Enero31 de 2014
DEDICATORIA
Este trabajo y la culminación de esta etapa van dedicados, a mis padres, por ser
guías y gestores. A mi amada esposa, Natalia por su apoyo y animo que me brinda
día a día para alcanzar nuevas metas, tanto profesionales como personales.
JORGE WILSON SALINAS
Este trabajo de grado va dedicado a todas las personas que me colaboraron en esta
etapa de mi vida en especial a mis padres, familia, cuerpo docentes y compañeros
los cuales fueron de vital importancia para poder sacar esta carrera adelante y tener
una visión mucho más amplia del mundo profesional y poder crecer mucho más
como persona.
JORGE ADRIÁN AMAYA
AGRADECIMIENTOS
Agradecemos a cada una de las personas involucradas en el desarrollo de este
proyecto, a las directivas, por su comprensión, apoyo y seguimiento constante. A
nuestras familias por su apoyo incondicional a lo largo de nuestro camino de
estudiantes a profesionales.
Agradecemos a la ingeniera Diana Lancheros, por sus lecciones en arquitectura de
software, las cuales nos permitieron plasmar a la realidad y en un tiempo record una
excelente idea de negocio.
Agradecemos especialmente al ingeniero Barajas y al ingeniero Elimelet por su
seguimiento y acompañamiento en el desarrollo de este proyecto.
Agradecemos a los estudiantes y docentes del programa de ingeniería en
automatización, ya que gracias a todos ellos hoy podemos ejercer como
profesionales competitivos.
CONTENIDO
Pág.
RESUMEN 15
INTRODUCCIÓN 16
1. OBJETIVOS 17
1.1 OBJETIVO GENERAL 17
1.2 OBJETIVOS ESPECIFICOS 17
2. ESTADO DEL ARTE 18
3. MARCO TEORICO 20
3.1 MARCO CONCEPTUAL 20
3.1.1 Ciclo-Parqueaderos 20
3.1.2 Biométrico 20
3.1.3 Lector de código de barras 20
3.1.4 Sistema de seguridad 20
3.1.5 Software 20
3.1.6 Hardware 20
3.1.7 Redes de comunicación 20
3.1.8 Servidor 21
3.1.9 Interfaz 21
3.1.10 Interactivo 21
3.2 HERRAMIENTAS DE DESARROLLO 21
3.2.1 Sistema de información 21
3.2.2 Arquitectura de Software en 3-Capas 23
3.2.3 UnifiedModelingLanguage UML 24
3.2.4 Bases de datos 25
3.2.5 Códigos de barras en 2D 26
3.2.6 Reconocimiento de Huellas Dactilares 27
7
3.2.7 Placa arduino 29
4. ANALISIS Y DISEÑO DEL SISTEMA DE INFORMACIÓN 30
4.1 METODOLOGÍA AGILE UNIFIED PROCESS (AUP) 32
4.2 MODELO DE REQUISITOS 33
4.2.1 Requisitos funcionales 35
4.2.1.1 Requisitos de inicio de sesión 35
4.2.1.2 Requisitos de registro de Bici-usuarios 37
4.2.1.3 Requisitos de registro de bicicletas 39
4.2.1.4 Requisitos de reportes 40
4.2.3 Requisitos no funcionales 38
4.2.3.1 Rendimiento 38
4.2.3.2 Seguridad 39
4.2.3.3 Fiabilidad 40
4.2.3.4 Disponibilidad 40
4.2.3.5 Mantenibilidad 40
4.2.3.6 Escalabilidad 41
4.2.4 Otros requisitos 41
4.3 DIAGRAMAS DE CASOS DE USO 42
4.3.1 Roles de usuario 42
4.3.2 Registro de Bici-usuarios y bicicletas en Ciclo-parqueadero 45
4.4 REGLAS DE NEGOCIO 50
4.4.1 Reglas de negocio para registro de ingreso 50
4.4.2 Reglas de negocio para registro de salida 52
4.5 DIAGRAMA DE CLASES 53
4.5.1 Clases, Atributos y métodos identificados 53
4.5.2 Asociaciones y agregaciones entre clases 54
4.6 DISEÑO DE LA BASE DE DATOS 56
4.6.1 Tablas de operadores 57
8
4.6.1.1Operadores 58
4.6.1.2 Nivel de administración 58
4.6.1.3 Nivel de usuario 59
4.6.1.4 Diagrama entidad relación operadores 60
4.6.2 Tabla de Bici-usuarios 60
4.6.2.1 Bici-Usuarios 60
4.6.2.2 Tipo de Bici-Usuario 61
4.6.2.3 Tipo de identificación 62
4.6.2.4 Datos Bici-usuario adicionales 63
4.6.2.5 Tipo de ocupación 63
4.6.2.6 Diagrama entidad relación Bici-usuarios 64
4.6.3 Tablas de bicicletas 65
4.6.3.1 Tipo de bicicletas 66
4.6.3.2 Colores de Bicicletas 66
4.6.3.3 Bicicletas 66
4.6.3.4 Diagrama entidad relación bicicletas 67
4.6.4 Tablas de enlaces 67
4.6.4.1 Enlace bicicletas – Bici-usuarios 67
4.6.4.2 Diagrama entidad relación enlace bicicletas – Bici-usuarios 68
4.6.5 Tabla de registro de eventos 68
4.6.5.1 Tabla Ciclo-parqueaderos 69
4.6.5.2 Tabla histórica de registro de ingresos 69
4.6.5.3 Diagrama entidad relación de registro de ingresos 70
4.7 INTERFAZ DE USUARIO 70
4.7.1 Barra de herramientas 72
4.7.2 Formulario de inicio de sesión 73
4.7.3 Formulario de registro de Bici-usuarios 74
4.7.4 Formulario de captura de fotografía 77
4.7.5 Formulario de captura de huellas dactilares 78
4.7.6 Formulario de registro de bicicletas 79
5. DESARROLLO DEL SISTEMA DE INFORMACIÓN 83
5.1 DESARROLLO DE LA CAPA DE ACCESO A DATOS 85
5.2 DESARROLLO DE LA CAPA LÓGICA DE NEGOCIO 85
5.3 DESARROLLO DE LA CAPA LÓGICA DE INTERFAZ DE USUARIO 86
6. DISEÑO DE INTERFAZ ELECTRÓNICA 88
6.1 Protocolo de comunicación
6.1 Modulo de comunicación 92
7. INTEGRACIÓN SOFTWARE Y HARDWARE 99
8. PRUEBAS DEL SISTEMA 101
9. RESULTADOS 108
10. CONCLUSIONES 109
BIBLIOGRAFIA 110
ANEXOS 113
Anexo A MODELO DE REQUISITOS NO FUNCIONALES 113
Anexo B CAPA DE ACCESO A DATOS PARA BICI-USUARIOS 121
Anexo C PROGRAMACIÓN ARDUINO 129
Anexo D MANUAL DE USUARIO 131
LISTA DE TABLAS
Pág.
Tabla 1. Tabla de descripción de componentes del sistema 31
Tabla 2. Fases de AUP 33
Tabla 3. Esquema general de los requisitos 34
Tabla 4. Requisitos: Inicio de Sesión 35
Tabla 5. Requisitos: Contraseñas de Alta Seguridad 36
Tabla 6. Requisitos: Perfiles de Usuarios 37
Tabla 7. Registrar Bici-Usuarios 37
Tabla 8. Fotografiar a Bici-Usuarios 38
Tabla 9. Requisitos: Huella Dactilar de Bici-Usuarios. 38
Tabla 10. Requisitos: Lectura de documentos con códigos de barras en 2D 38
Tabla 11. Requisitos: Registro de Bicicletas 39
Tabla 12. Requisitos: Estado de Bicicletas 39
Tabla 13. Requisitos: Impresión de Stiker para Bicicletas. 40
Tabla 14. Requisitos: Filtro de Reportes 41
Tabla 15. Requisitos: Reporte de Ingresos vs. Salidas. 41
Tabla 16. Requisitos: Reporte Histórico de ingresos y Salidas. 41
Tabla 17. Requisitos: Reporte Histórico de ingresos y salidas con información
detallada del Bici-Usuario 42
Tabla 18. Requisitos: Exportación de Reportes 42
Tabla 19. Formato para especificación de casos de uso 43
Tabla 20. Casos de Uso: Roles de Usuario 44
Tabla 21. Casos de Uso: Registro de Bici-Usuarios. 47
Tabla 22. Casos de Uso: Registro de Bicicletas. 49
Tabla 23. Casos de Uso: Reportes 50
Tabla 24. Tabla de operadores 58
Tabla 25. Tabla operadores_adminlevel 59
11
Tabla 25. Tabla operadores_userlevel 59
Tabla 26. Tabla Bici-Usuarios 61
Tabla 27. Tabla Tipo_Usuarios 61
Tabla 28. Tabla Descripción Tipo_Usuarios 62
Tabla 29. Tipo_Identificación 62
Tabla 30. Tabla Bici-Usuarios Anexos 62
Tabla 31. Tabla Tipo_ocupación 63
Tabla 32. Tabla Descripción Tipo_ocupación 63
Tabla 33. Tabla Tipo_bicicleta 64
Tabla 34. Tabla Descripción Tipo_bicicleta 65
Tabla 35. Tabla colores bicicleta 65
Tabla 36. Tabla bicicletas 66
Tabla 37. Tabla enlace bicicletas – Bici-usuario 66
Tabla 38. Tabla Ciclo-parqueaderos 67
Tabla 39. Tabla Histórica de Registro de Ingresos 69
Tabla 40. Tabla Histórica de Registro de Ingresos 69
Tabla 41. Formularios que componen la aplicación 71
Tabla 42. Esquema General de Formularios 72
Tabla 43. Esquema de la barra de herramientas 72
Tabla 44. Esquema del Formulario de inicio de sesión. 74
Tabla 45. Esquema del Formulario Registro de Bici-Usuarios. 75
Tabla 46. Esquema del Formulario Registro de Bici-Usuarios datos adicionales. 76
Tabla 47. Esquema del Formulario Captura de Fotografía. 77
Tabla 48. Esquema del Formulario Captura de Huellas Dactilares. 79
Tabla 49. Esquema del Formulario Registro de Bicicletas. 81
12
Tabla 50. Contenido explorador de soluciones Visual Studio .Net 2010. 84
Tabla 51. Contenido capa de interface de Usuario 87
Tabla 52. Tabla de descripción de la interface electrónica 90
Tabla 53. Tabla de crecimiento de bici-usuarios 102
Tabla 54. Tabla de tendencias de ingreso bici-usuarios 103
Tabla 55. Tabla de tendencias de ingreso bici-usuarios octubre 2013 104
Tabla 56. Tabla de tendencias de ingreso bici-usuarios noviembre 2013 105
Tabla 57. Tabla aumento de nuevos usuarios desde la implementación 106
LISTA DE FIGURAS
Pág.
Figura 1. Cubículos de ciclo parqueaderos para bicicletas eléctricas 19
Figura 2. Tipos de sistemas según el nivel de organización 22
Figura 3. Codificación PDF417 27
Figura 4. Proceso de Captura de huellas dactilares 28
Figura 5. Proceso de identificacion de huellas dactilares 28
Figura 6. Placa arduino 29
Figura 7. Diagrama General del sistema de información 30.
Figura 8. Casos de Uso: Roles de Usuario 43
Figura 9. Casos de Uso: Registro de bici-usuarios 46
Figura 10. Regla de negocio para registro de ingreso 51
Figura 11. Regla de negocio para registro de salida 52
Figura 12. Clases, Atributos y Métodos Identificados. 53
Figura 13. Asociaciones y Agregaciones Entre Clases 54
Figura 14. Diagrama General de la Base de Datos. 56
Figura 15. Diagrama Entidad Relación Operadores 60
Figura 16. Diagrama Entidad Relación Bici-Usuarios 64
Figura 17. Diagrama Entidad Relación Bicicletas 67
Figura 18. Diagrama Entidad Relación de Registro de Ingresos 70
Figura 19. Mapa de Navegación 71
Figura 20. Barra de herramientas software 72
Figura 21. Formulario de inicio de sesión 73
Figura 22. Formulario de registro de Bici-usuarios 74
Figura 23. Formulario de registro de Bici-usuarios 2 75
Figura 24. Formulario de registro de Bici-usuarios datos adicionales 76
Figura 25. Formulario de Captura de fotografía 77
Figura 26. Formulario de Captura de huellas dactilares 79
Figura 27. Formulario de Registro de Bicicletas 81
Figura 28. Diseñando Sistemas empleando el modelo de capas en desarrollo de software. 83
Figura 29. soluciónSBC_CicloPark. 84
Figura 30. Capa lógica interfaz de usuario 86
Figura 31. Diagrama de descripción interfaz electrónica 88
Figura 32. Diagrama de secuencia electrónica 89
Figura 33. Diagrama de funcionamiento módulo de comunicación 93
Figura 34. Ventana software X-CTU 94
Figura 35. Ventana X-CTU UserComPorts 95
Figura 36. X-CTU Añadir nuevo dispositivo 96
Figura 37. Configuración Xbee modo Terminal 97
Figura 38. Configuración Xbee modo Terminal 98
Figura 39. Comunicación para integrar software y hardware 99
Figura 40. Minuta de registro antiguo 101
Figura 41. Operario de turno manejando el software 101
Figura 42. Gráfico de ingreso vs salida de bicicletas 102
Figura 43. Gráfico de tendencias ingreso vs salida de bicicletas 103
Figura 44. Gráfico de tendencias ingreso vs salida de bicicletas octubre 2013 104
Figura 45. Gráfico de tendencias ingreso vs salida de bicicletas Noviembre 2013 105
Figura 46. Gráfico de nuevas bicicletas registradas desde la implementación del sistema 107
RESUMEN
Una de las estrategias para incentivar el uso de la bicicleta en Bogotá, es la creación de ciclo-parqueaderos, sin embargo, en la actualidad poseen un nivel de seguridad bajo, por lo que los posibles usuarios de estos ciclo-parqueaderos disminuyen considerablemente. En el proyecto se va diseñar e implementar un sistema de información que permita al operador del sistema registrar a los bici-usuarios y automáticamente seleccione el sitio de parqueo de las bicicletas que ingresen al ciclo-parqueadero, constituyendo un gran incentivo para su uso, pues disminuye la exposición al hurto. La herramienta diseñada está basada en la integración de varias tecnologías, entre ellas:
Lectura de códigos de barras en 2D: Permite lectura de documentos de identificación (Cedula de Ciudadanía, Tarjeta de Identidad), en formato de código de barras PDF417.
Captura de fotografía: Almacena las fotos de bici-usuarios en bases de datos.
Captura de huella dactilar: Habilita la verificación 1:1 de bici-usuarios por medio de la huella dactilar.
Impresión de stikers permeabilizados con código de barras: Las bicicletas ingresadas al sistema, llevaran el stiker impreso.
Módulo de entradas y salidas digitales: permite el accionamiento de tres indicadores luminosos, los cuales le darán a conocer al bici-usuario si el sitio de parqueo esta usado, libre o es el sitio en el cual debe aparcar, para ello se integraran con el software sensores de presencia.
16
INTRODUCCIÓN
El crecimiento exponencial de los centros urbanos en nuestros días, acarrean problemas cada vez más notorios en temas de movilidad, polución por emisiones de vehículos y múltiples enfermedades en personas sedentarias.(Movilidad, 2012)
La forma de atacar estos problemas específicamente en la ciudad de Bogotá, ha sido la implementación de ciclo rutas, ciclo puentes, y cicloparqueaderos para incentivar el uso de medios alternativos de transporte, como la bicicleta.
Sin embargo, la inseguridad de los cicloparqueaderos, no permite que un mayor número de usuarios utilice esta infraestructura. Aunque en la mayoría de los cicloparqueaderos de Bogotá, existe vigilancia privada, esta no está provista de las herramientas adecuadas que permitan administrar de manera eficiente los cicloparqueaderos, encontrando situaciones de robo o cambiazo. Adicional a esto, encontramos que el registro de las bicicletas se realiza manualmente, generando filas muy largas para ingresar o salir en las horas pico.(Movilidad, 2012)
Es aquí, donde vimos la necesidad de desarrollar un sistema de información que aumente el nivel de seguridad y la velocidad de registro en estos sitios por medio de la integración de tecnologías de última generación como lo son el reconocimiento de huellas dactilares, la lectura de códigos de barras en 2D y sensores de posicionamiento para detectar puestos libres en los cicloparqueaderos.
La comunidad en general y los administradores de los cicloparqueaderos, son los beneficiarios directos de este desarrollo, ya que tendrán una mejor percepción de seguridad en estos sitios. Se espera por lo tanto una mayor utilización de la bicicleta como medio alternativo de transporte.
17
1. OBJETIVOS
1.1. OBJETIVO GENERAL
Implementar un sistema automático para control y seguridad en ciclo parqueaderos integrando tecnología de huella dactilar y lectura de códigos de barras en 2d.
1.2. OBJETIVOS ESPECIFICOS
1. Diseñar e implementar la arquitectura del sistema de información para control de ciclo-parqueaderos.
2. Implementar la interfaz electrónica que permita la supervisión de las plazas disponibles en el ciclo-parqueadero, seleccionando los sensores, actuadores y medios de comunicación adecuados.
3. Diseñar e implementar la interfaz gráfica para el sistema control de registro de bici-usuarios y monitoreo de plazas.
4. Integrar la interfaz electrónica con el sistema de información. 5. Analizar el funcionamiento del prototipo. 6. Documentar el desarrollo del sistema automático.
18
2. ESTADO DEL ARTE
Los últimos desarrollos de sistemas de ciclo-parqueaderos en Colombia, no permiten la integración con otras tecnologías ya que son netamente manuales, como se aprecia en las principales universidades y centros comerciales del país. En el continente europeo ya existe una integración más avanzada tecnológicamente con respecto a la existente en Colombia, como lo es el caso de España que en la mayor parte de estaciones del metro se tiene uno o varios ciclo-parqueaderos los cuales cuentan con un ingreso totalmente automático, este tipo de ciclo-parqueaderos basa su funcionamiento en cubículos subterráneos los cuales son asignados a los usuarios por medio de una tarjeta inteligente, el usuario simplemente desliza la tarjeta mediante un lector de tarjetas e ingresa la bicicleta a un cubículo el cual se situara automáticamente en una cavidad subterránea especifica. Uno de los proyectos de ciclo-parqueaderos que existe en Europa es el proyecto BIKENNEL (pronunciado baikenel) es una solución técnica patentada para el aparcamiento de bicicletas. Una solución concebida para guardar la bicicleta bajo llave en un lugar cerrado con una manipulación limpia y ergonómica.(Bikennel, 2012) Las premisas que inspiran su concepción son las siguientes:
La gente no empezará a usar la bicicleta mientras no tenga un sitio seguro donde guardarla. Quien opta por la bicicleta no usa una cualquiera sino una buena bicicleta, y además la gente no acude al trabajo con las manos en los bolsillos. Por tanto hay que crear soluciones de aparcamiento que custodien bajo llave tanto la bicicleta como su carga.
Estas custodias bajo llave han de tener una manipulación fácil, limpia y cómoda. Los usuarios no van a ser forzosamente ni muy jóvenes ni muy fuertes ni llevarán indumentaria deportiva.
El tráfico de personas en las ciudades funciona por oleadas, especialmente en estaciones de transporte público. El sistema de aparcamiento ha de permitir el acceso simultáneo de un gran número de usuarios. (Bikennel, 2012)
ARAGONESA CUCOBIKE esta empresa ha puesto en marcha un innovador servicio de alquiler de bicicletas eléctricas para todo tipo de usuario que facilita el disfrute de los atractivos históricos y naturales de la cuna del antiguo Reino de Aragón, con una rica variedad de rutas ligadas al Camino de Santiago. La base operativa está instalada en la legendaria “Venta de Esculabolsas” (Santa Cruz de la Serós), al pie de la carretera N-240, km 295, cruce y parada obligatoria de la ruta aragonesa del camino de Santiago, entre las localidades altoaragonesas de Jaca y Puente la Reina, donde hoy ofrece sus servicios el Hotel Aragón. Se trata de un avanzado sistema también desarrollado por UNDERCOVER, único en el mundo, que entrega, o recibe la bicicleta eléctrica en menos de 5 segundos y permite brindar todo el equipamiento entregado con el servicio como son la cesta, chaleco, casco, rutómetro, o los accesorios demandados “a la carta” por el cliente en su reserva. La moderna tecnología, desarrollada íntegramente por Undercover, además del alquiler de bicicletas ofrece aparcamiento seguro para el peregrino y una particular aplicación
19
que permite el depósito de tu bicicleta a la vez del préstamo de la bicicleta eléctrica para acceder a los entornos de fuerte desnivel en los que no es la más adecuada la propia. Incorpora un desarrollo de software de ‘visión artificial’ para el reconocimiento de la carga y de la integridad de la bicicleta, gestión remota de los alquileres y un novedoso sistema de habilitación de usuarios a través de teléfono móvil y códigos ‘bidi’. Los cubículos de dichas bicicletas son como se aprecian en la figura 1 (Cucobike, 2012) Figura 1. Cubículos de ciclo parqueaderos para bicicletas eléctricas.
Fuente: (Cucobike, 2012) Bühler Ralph. Presenta un análisis del papel de los aparcamientos de bicicletas gratuitos y como beneficios como determinantes de la bicicleta al trabajo El análisisse basa en datosconmutados de trabajadores en elárea de Washington,DC. Resultadosdeeventosrarosregresión logística las cuelesindican que los aparcamientos para bicicletas gratuitosestán relacionados conlos nivelesmás altos delos desplazamientosen bicicleta, incluso cuando se controla porotras variablesexplicativas. [4] (Buehler, 2012) Rodier J. Caroline y Shaheen A. Susan. Presentan una evaluacióndel primer proyectode aparcamientointeligentede tránsitobasadaenlos EE.UU. la cual se ejecutó en el San FranciscoBayArea Rapid TransitSanestación(BART) Distrito deOakland, California. La cual tras una revisión dela literatura y campo deestacionamientos inteligentes, lo describeincluyendo sucoste de mantenimientode capital, operativos y, finalmente se presentanlos resultadosdelanálisis de la encuestaparticipante. (Rodier, 2011) Santos L. Miguel y Ramírez G. Juan. Dan a conocer mediante su trabajo de grado un sistema de información para control de tiempo y asistencia basado en marcación biométrica de huella dactilar en pymes el cual consiste que mediante la integración de diferentes dispositivos como los son sensor de huella dactilar Biométrico, sistema embebido (tarjeta electrónica micro controlada) las cuales mediante un software y una base de datos permite el registro, horas de entrada y de salida y reportes de los usuarios para tener un control administrable del personal.(Santos, 2011)
3. MARCO TEÓRICO
20
3.1. MARCO CONCEPTUAL
Para el desarrollo del proyecto, a continuación se tratarán los temas de gran importancia para la investigación, diseño y construcción del prototipo final. 3.1.1 Ciclo-Parqueaderos: Es un sitio dedicado al parqueo seguro de bicicletas.
3.1.2 Biométrico: El concepto biometría proviene de las palabras bio (vida) y metría (medida), por lo tanto con ello se infiere que todo equipo biométrico mide e identifica alguna característica propia de la persona. La biometría es una tecnología de seguridad basada en el reconocimiento de una característica de seguridad y en el reconocimiento de una característica física e intransferible de las personas, como por ejemplo la huella digital. (Homini, 2004) 3.1.3 Lector de código de barras: Escáner que por medio de un láser lee un código de barras y emite el número que muestra el código de barras, no la imagen. Hay escáner de mano y fijos, como los que se utilizan en las cajas de los supermercados. Tiene varios medios de conexión: los más modernos por orden de aparición USB, bluetooth, wifi, los más viejos puerto serie, incluso directamente al puerto PS2 del teclado por medio de un adaptador, cuando se pasa un código de barras por el escáner es como si se hubiese escrito en el teclado el número del código de barras (ingeniatic, 2011) 3.1.4 Sistema de seguridad: es el conjunto de elementos en instalaciones necesarios para proporcionar a las personas y bienes materiales y protección frente agresiones, robos incendios etc. (Duran, 2009)
3.1.5 Software: el software es todo aquello que le proporciona a la computadora las instrucciones necesarias para realizar una determinada función. Entre ellos se destacan el sistema operativo, juegos, controladores de dispositivos, etc. (Informatica, 2013)
3.1.6 Hardware:El hardware es un término genérico utilizado para designar a todos los elementos físicos que lo componen, es decir, gabinete, monitor, motherboard, memoria RAM y demás. (Informatica, 2013) 3.1.7 Redes De Comunicación: Una red de comunicación es básicamente un conjunto o sistema de equipos informáticos conectados entre sí, por medio de dispositivos físicos que envían y reciben impulsos eléctricos, ondas electromagnéticas o cualquier otro medio para el transporte de datos con la finalidad de compartir datos, información recursos y ofrecer servicios. (rodriguez, 2013)
21
3.1.8 Servidor:En informática, un servidor es un tipo de software que realiza ciertas tareas en nombre de los usuarios. El término servidor ahora también se utiliza para referirse al ordenador físico en el cual funciona ese software, una máquina cuyo propósito es proveer datos de modo que otras máquinas puedan utilizar esos datos. (Virtual, 2013) 3.1.9 Interfaz: En software, parte de un programa que permite el flujo de información entre un usuario y la aplicación, o entre la aplicación y otros programas o periféricos. Esa parte de un programa está constituida por un conjunto de comandos y métodos que permiten estas intercomunicaciones. (Alegsa, 2011)
3.1.10 Interactivo: Un sistema es interactivo cuando permite un diálogo continuo entre el usuario y la aplicación, respondiendo ésta a las órdenes de aquel. (Mastermagazine, 2012)
3.2. HERRAMIENTAS DE DESARROLLO
3.2.1. Sistemas De Información
Los sistemas de información son un conjunto de componentes interrelacionados que permiten capturar, procesar, almacenar y distribuir la información para apoyar la toma de decisiones y el control en una institución. La implementación de un sistema de información, genera múltiples ventajas, entre ellas se pueden destacar:(Alarcon Fernandez, 2006)
Permite un acceso rápido a determinada información y por ende mejora tanto en tiempos como en resultados el servicio a los usuarios.
Genera información e indicadores los cuales permiten analizar, comparar estudiar para detectar fallas y así mismo tener el control del sistema.
Da la posibilidad de planear, idear proyectos los cuales van a estar generados de un sistema de información que tiene unos elementos claros y en dado caso sustentados para prever cualquier tipo de requerimientos.
Evita la pérdida de tiempo en la organización de la información ya que realizándola de forma manual se corre el riesgo de no dar la investigación correcta.
Logra ventajas competitivas a través de su implementación y uso. Por su amplio campo de acción, existen diferentes tipos de sistemas de información, los cuales se clasifican según el nivel de organización y función empresarial. Figura 2. Figura 2:Tipos De Sistemas Según El Nivel De Organización Y Función Empresarial
22
Fuente:(Omana, 2011) Los sistemas de procesamiento transaccionales, son los sistemas de información que logran la automatización de procesos operativos, ya que su función primordial consiste en procesar transacciones tales como pagos, cobros, entradas, salidas, etc. Estos se encuentran en un nivel operativo. (Omana, 2011) Los sistemas de trabajo de conocimiento y de oficina, se encuentran en el nivel de conocimiento, permitiendo labores como trabajo para la ingeniería, gráficos, procesamiento de texto, digitalización de conocimiento y calendarios electrónico. (Alarcon Fernandez, 2006) Los sistemas de soporte a la toma de decisiones (DSS), son sistemas de información que apoyan el proceso de toma de decisiones. Se encuentran a un nivel administrativo, permitiendo el análisis de datos como, análisis de ventas regionales, programación de programas de inducción, análisis de costos, análisis de fijación de precios y rentabilidad, análisis de costos de contrato, etc. Los sistemas estratégicos, se desarrollan en las instituciones con el fin de lograr ventajas competitivas a través del uso de la tecnología de la información. (Cuellar, 2011) El sistema que se va a diseñar, se clasifica en el nivel operativo, ya que debe cumple con las siguientes características:
A través de éstos suelen lograrse ahorros significativos de mano de obra, debido a que automatizan tareas operativas de la organización.
Con frecuencia son el primer tipo de Sistemas de Información que se implanta en las organizaciones. Se empieza apoyando las tareas a nivel operativo de la
23
organización para continuar con los mandos intermedios y posteriormente con la alta administración conforme evolucionan.
Son intensivos en entrada y salida de información; sus cálculos y procesos suelen ser simples y poco sofisticados. Estos sistemas requieren mucho manejo de datos para poder realizar sus operaciones y como resultado generan también grandes volúmenes de información.(Cuellar, 2011)
Tienen la propiedad de ser recolectores de información, es decir, a través de
estos sistemas se cargan las grandes bases de información para su explotación posterior. Estos sistemas son los encargados de integrar gran cantidad de la información que se maneja en la organización, la cual será utilizada posteriormente para apoyar a los mandos intermedios y altos.
Son fáciles de justificar ante la dirección general, ya que sus beneficios son
visibles y palpables. El proceso de justificación puede realizarse enfrentando ingresos y costos. Esto se debe a que en el corto plazo se pueden evaluar los resultados y las ventajas que se derivan del uso de este tipo de sistemas. Entre las ventajas que pueden medirse se encuentra el ahorro de trabajo manual.(Cuellar, 2011)
Son fácilmente adaptables a paquetes de aplicación que se encuentran en el
mercado, ya que automatizan los procesos básicos que por lo general son similares o iguales en otras organizaciones. Ejemplos de este tipo de sistemas son la facturación, nóminas, cuentas por cobrar, cuentas por pagar, contabilidad general, conciliaciones bancarias, inventarios, etcétera. (Cuellar, 2011)
3.2.2. Arquitectura de Software en 3-Capas.
Dividir un software en varias partes lógicas, ya sean módulos, paquetes o capas, ofrece la posibilidad de comprender fácilmente su filosofía y distribuir las tareas que ejecuta. Por ello la comunidad del software desarrolló la noción de una arquitectura de varios niveles y entre las más difundidas se encuentra la arquitectura de tres capas. (Evans,2011)
La arquitectura en tres capas divide la aplicación en tres partes lógicas, con un grupo de interfaces perfectamente definidas.
La Primera Capa o Capa de Presentación: consiste en una interfaz gráfica que reúne los aspectos de software enfocados a la interacción con los diferentes tipos de usuarios. Es decir, incluye el manejo y aspecto de las ventanas, la autentificación, el formato de los reportes, menús, gráficos y demás elementos multimedia.
24
La Segunda Capa o Capa Intermedia: reúne los aspectos de software que automatizan los procesos de negocio. Conocida también como capa de la Lógica de la Aplicaciónó Lógica de Negocio. Recibe la entrada de la capa anterior, interactúa con los servicios de datos para ejecutar las operaciones y envía el resultado procesado a la capa de presentación.
La Tercera Capa o Capa de Datos: contiene los datos necesarios para la aplicación. Es la encargada de almacenarlos, recuperarlos y mantener su integridad. Estos datos consisten en cualquier fuente de información, incluido una base de datos de empresa como SQL Server,Oracle o MySQL, un conjunto de documentos XML o incluso un servicio de directorio como LDAP. Además del tradicional mecanismo de almacenamiento relacional de base de datos, existen muchas fuentes diferentes de datos de empresa a las que pueden acceder las aplicaciones.
La separación entre la lógica de la aplicación y la interfaz de usuario ofrece mayor flexibilidad al diseño de la misma. De manera que los modelos de N capas están encaminados a maximizar aspectos importantes dentro de las aplicaciones, su autonomía, confiabilidad, disponibilidad, escalabilidad e interoperabilidad.
3.2.3. UnifiedModelingLanguage - Uml
El Lenguaje de Moldeamiento Unificado (UML - UnifiedModelingLanguage) es un lenguaje gráfico para visualizar, especificar y documentar cada una de las partes que comprende el desarrollo de software. UML entrega una forma de modelar cosas conceptuales como los procesos de negocio y funciones de sistema, además de cosas concretas como escribir clases en un lenguaje determinado, esquemas de base de datos y componentes de software reusables.(Raymond Mcleod, 2000)
Diagrama de Casos de Uso: modela la funcionalidad del sistema agrupándola en descripciones de acciones ejecutadas por un sistema para obtener un resultado. Se utiliza para entender el uso del sistema. Muestra el conjunto de casos de uso y actores (Un actor puede ser tanto un sistema como una persona) y sus relaciones: es decir, muestra quien puede hacer qué y las relaciones que existen entre acciones (casos de uso). Son muy importantes para modelar y organizar el comportamiento del sistema.(Raymond Mcleod, 2000)
Diagrama de Clases: muestra las clases (descripciones de objetos que comparten características comunes) que componen el sistema y cómo se relacionan entre sí. (Raymond Mcleod, 2000)
Diagrama de Objetos: muestra una serie de objetos (instancias de las clases) y sus relaciones. A diferencia de los diagramas anteriores, estos diagramas se
25
enfocan en la perspectiva de casos reales o prototipos. Es un diagrama de instancias de las clases mostradas en el diagrama de clases. (OMG, 2012)
Diagrama de Secuencia: enfatiza la interacción entre los objetos y los mensajes que intercambian entre sí junto con el orden temporal de los mismos. (OMG, 2012)
Diagrama de Colaboración: igualmente, muestra la interacción entre los objetos resaltando la organización estructural de los objetos en lugar del orden de los mensajes intercambiados.(OMG, 2012)
El diagrama de secuencia y el diagrama de colaboración: muestran a los diferentes objetos y las relaciones que pueden tener entre ellos, los mensajes que se envían entre ellos. Son dos diagramas diferentes, que se puede pasar de uno a otro sin pérdida de información, pero que nos dan puntos de vista diferentes del sistema. En resumen, cualquiera de los dos es un Diagrama de Interacción.(OMG, 2012)
Diagrama de Estados: Se utiliza para analizar los cambios de estado de los objetos. Muestra los estados, eventos, transiciones y actividades de los diferentes objetos. Son útiles en sistemas que reaccionen a eventos. (OMG, 2012)
Diagrama de Actividades: Es un caso especial del diagrama de estados, simplifica el diagrama de estados modelando el comportamiento mediante flujos de actividades. Muestra el flujo entre los objetos. Se utilizan para modelar el funcionamiento del sistema y el flujo de control entre objetos. (OMG, 2012)
Diagrama de Componentes: muestra la organización y las dependencias entre un conjunto de componentes. Se usan para agrupar clases en componentes o módulos.
Diagrama de Despliegue (o implementación): muestra los dispositivos que se encuentran en un sistema y su distribución en el mismo. Se utiliza para identificar Sistemas de Cooperación: Durante el proceso de desarrollo el equipo averiguará de qué sistemas dependerá el nuevo sistema y que otros sistemas dependerán de él. (Raymond Mcleod, 2000)
3.2.4. Bases De Datos Una base de datos es un “almacén” que permite guardar grandes cantidades de información de forma organizada para que luego se pueda encontrar y utilizar fácilmente. Una base de datos se puede definir como un conjunto de información relacionada que se encuentra agrupada ó estructurada.
26
Cada base de datos se compone de una o más tablas que guarda un conjunto de datos. Cada tabla tiene una o más columnas y filas. Las columnas guardan una parte de la información sobre cada elemento que queramos guardar en la tabla, cada fila de la tabla conforma un registro. Los motores de bases de datos, son programas informáticos que permiten por medio de librerías específicas para cada lenguaje de programación, la administración y control de los datos almacenados en las bases de datos. Las bases de datos, utilizan el lenguaje SQL (STRUCT QUERY LANGUAJE), para realizar las funciones típicas como lo son seleccionar, modificar, eliminar o agregar datos. Los diagramas de bases de datos, permiten establecer la relación entre diferentes tablas que componen una base de datos, y se usan para diseñar la base de datos que almacenara la información. [3] (Peter Rob C & Coronel, 2004) 3.2.5. Códigos De Barras En 2d
Los códigos de barras de dos dimensiones, 2D, son códigos que su principal característica es que pueden “guardar” más información que la que contienen los códigos de una dimensión 1D. Dependiendo del tipo de código, se pueden “guardar” hasta casi 7,000 caracteres. Los códigos de barras de dos dimensiones, 2D, más populares son:
Código 49
Código 16K
Código PDF417
Código Data Matrix
Código MaxiCode
Código Aztec
Código QR Debido a que la RegistraduríaNacional del Estado Civil, ha implementado el código de barras PDF-417, para las cedulas de ciudadanía y la tarjeta de identidad, se seleccionó esta codificación para su lectura ya queeste tipo de código puede almacenar como máximo 1.800 caracteres alfanuméricos (ASCII) o 1,100 códigos binarios por cada símbolo (cada rectángulo en forma de “nube de puntos”).
27
Figura 3: Codificación PDF417
Fuente: Manual de usuario lector HoneywellXenon 1900. El estándar de la codificación PDF417 posee tres áreas distintas, como se muestra en la figura 3:
Patrón de inicio y fin: se usa para ayudar a los lectores de código de barras, a encontrar el inicio y fin del código de barras. Estos patrones son estáticos y son los mismos para todos los códigos de barras de codificación PDF417.
Indicadores de fila izquierda y derecha: se utilizan para ayudar a orientar el escáner de código de barras. Estos patrones son dependientes de los datos reales en el código de barras para lograr el máximo contraste.
Los datos y recuento de datos: Este espacio es único para cada código de barras y representa los datos codificados. PDF417 especifica varias maneras de codificar los datos almacenados para alcanzar el nivel máximo de compresión basada en el conocimiento y restricción del alfabeto usado. Es decir, puede usar una codificación especial si se trata de almacenar solo números para compactar más eficientemente los datos que si se tratara de almacenar valores alfanuméricos.
3.2.6. Reconocimiento de Huellas Dactilares
Desde hace varios años atrás, las huellas dactilares se usan como sistema de identificación personal, ya que dos personas nunca compartirán las mismas características de sus huellas dactilares. Gracias al avance tecnológico, se pueden encontrar hoy en día varios tipos de escáner de huellas dactilares que pueden ser usados para diferentes propósitos de acuerdo a sus características técnicas. El escáner seleccionado para el desarrollo de este prototipo, es el lector de huellas dactilares UAREU 4500, de la marca Digital Persona, debido a que cumple con las siguientes características técnicas:
Comunicación con el host por USB.
Resolución de 512 DPI en la imagen capturada de la huella dactilar.
Carcaza de metal para ambientes hostiles.
Diseño ergonómico que permite ocupar poco espacio.
28
Los procesos de captura (Figura 4) e identificación (Figura 5) de huellas dactilares se realiza por medio del Algoritmo licenciado VerifingerSDK, de la empresa Lituana Neurotechnoljija. Figura 4: Proceso de Captura de huellas dactilares.
Fuente: BioTronicFS Distribuidor de lectores de huellas dactilares. La captura de la huella dactilar, inicia con la detección de un dedo por parte del lector biométrico. El lector biométrico, se encarga de generar una imagen de 512DPI, en escala de grises de 8 bits. Esta imagen, es procesada por el algoritmo de extracción de minucias o pequeños detalles, el cual se encarga de extraer las características de cada huella dactilar, para luego almacenarlas en bases de datos. Figura 5: Proceso de identificacion de huellas dactilares.
Fuente: Neurotechnolojija. Fabricante de algoritmo de extracción y comparación de huellas dactilares.
29
Para realizar la identificación de huellas dactilares (Figura 5), el sistema carga en memoria las características de las huellas dactilares que tenga almacenadas en la base de datos, para luego realizar la comparación 1:1 cuando se tiene el ID del usuario, ó 1:N cuando se quiere buscar dentro de una base de datos extensa de usuarios. 3.2.7. Placa Arduino
Arduino es una plataforma de hardware libre, basada en una placa con un micro controlador y un entorno de desarrollo, diseñada para facilitar el uso de la electrónica en proyectos multidisciplinares. (Arduino, 2013)
El hardware consiste en una placa con un micro controlador Atmel AVR y puertos de entrada/salida. Los microcontroladores más usados son el Atmega168, Atmega328, Atmega1280, ATmega8por su sencillez y bajo coste que permiten el desarrollo de múltiples diseños.Por otro lado el software consiste en un entorno de desarrollo que implementa el lenguaje de programación Processing/Wiring y el cargador de arranque(bootloader) que corre en la placa.(Arduino, 2013)
Figura 6: Placa arduino
Fuente: (Arduino, 2013)
30
4. ANALISIS Y DISEÑO DEL SISTEMA DE INFORMACIÓN
En este capítulo, se documenta el diseño del sistema de información, partiendo desde una breve explicación de su funcionalidad, presentando los requisitos solicitados por el cliente, diseñando la arquitectura de software, bases de datos relacionales y finalizando con un prototipo del sistema de información.
Figura 7: Diagrama General del sistema de información para control de ciclo-parqueaderos.
Fuente: Los Autores
Como se puede ver en la figura 7, El sistema de información para control de cicloparqueaderos, posee los siguientes componentes que funcionan como entradas:
La información recolectada de cada Bici-Usuario capturada desde el lector de códigos de barras 2D.
La foto del Bici-usuario.
Imagen y templatede la huella dactilar.
Sensores de posición para detectar los cicloparqueaderos libres y en uso.
Como salidas del sistema, se tienen:
Impresión de stikers con el código del marco de la bicicleta.
Activación de indicadores luminosos para que él bici-usuario ubique fácilmente un sitio disponible para parquear, así como los puestos ocupados.
31
En la tabla 1. Se mencionan los componentes del proyecto, con una breve explicación de su función dentro del sistema.
Tabla 1: Tabla de descripción de componentes del sistema.
TABLA DE DESCRIPCIÓN DE LA INTERFACE ELECTRÓNICA
Nombre de la Unidad
Descripción
Lector de Código de Barras 2D
El lector de código de barras 2D, permite capturar la información almacenada en códigos de barras con formato unidireccional y bidimensional. El lector usado es de marca Honeywell referencia Xenon 1900, el cual permite leer códigos de barras con formato PDF417, el mismo que poseen los documentos de identificación como la cedula de ciudadanía y la tarjeta de identidad colombianas. Su comunicación es por puerto USB y su sensor, es una cámara, por lo que no tiene partes móviles, lo que aumenta la vida útil del lector.
Escáner de huellas dactilares
El escáner de huellas dactilares de la marca digital persona, referencia UAREU, fue el seleccionado para ser usado en la aplicación. Su función principal será la de autenticar los biciusuarios ya enrolados que deseen sacar la bicicleta. La comunicación de este escáner es via USB, y su característica más importante, es la calidad de la imagen que genera, ya que es una imagen de 500DPI. La integración con este dispositivo, se realizó con el usó del SDK VerifingerSDK para reconocimiento de huellas dactilares de la empresa Lituana, Neurotechnologija.
Cámara Web
La cámara web que se utilizó, es de marca Microsoft y referencia life HD3000, esta cámara tiene una resolución máxima de 720p, lo que permite generar imágenes de alta resolución. El sistema de información sin embargo, permite capturar las imágenes de cualquier cámara USB, ya que el algoritmo usa la API WDM de Windows.
32
Impresora de Stikers
La impresora térmica de stikers seleccionada fue la TSC 244Plus, gracias a que permite usar papel de transferencia térmica, así como cinta de resina para hacer más durables las impresiones en los stikers. Otra gran ventaja de esta impresora, es que el fabricante otorga la API de manera gratuita para enviar comandos de programación a la impresora, y así imprimir códigos de barras de varios formatos usados comercialmente, entre ellos 128, 39 y PDF417.
Interface electrónica.
La interface electrónica implementada e integrada al sistema de información, utiliza la placa Arduino Uno, y dos módulos de comunicación ZigBee, de la marca XBee. En el capítulo 5 se profundiza en el diseño de la interface electrónica, y en el capítulo 6 se explica cómo se realizó la integración hardware y software.
Sistema de Información.
El sistema de información está basado en la arquitectura de 3-Capas, para realizar de manera ordenada y eficiente su desarrollo en grupo, así como facilitar las actualizaciones futuras que se le apliquen. Como lenguaje de programación se utilizó C#, con el IDE Visual Studio .Net 2010, y el framework 4.0.Las bases de datos se diseñaron e implementaron en Microsoft SQL Server 2008. El diseño del sistema de información se documenta en el capítulo 4. El desarrollo del sistema de información se documenta en el capítulo 5.
4.1. METODOLOGÍA AGILE UNIFIED PROCESS (AUP)
Para el desarrollo del sistema en cada una de sus etapas, se implementó la metodología AUP, la cual es una versión simplificada de RationalUnifiedProcess (RUP) [Ambler 2004]. Este describe un enfoque simple y fácil de entender para desarrollar Software de aplicaciones de negocio usando técnicas y conceptos aunque aun permaneciendo como RUP.
33
El enfoque aplica técnicas ágiles tales como desarrollo manejado por las pruebas (test drivendevelopment (TDD)), gestión de cambios ágil (agile changemanagement), desarrollo ágil manejado por el modelo (Agile ModelDrivenDevelopment (AMDD)) y rediseño de la Base de datos (databaserefactoring).
Las disciplinas de AUP son diferentes a las de RUP, se han mezclado modelación del negocio, requisitos, análisis y diseño en la disciplina de modelación y además, se unieron gestión de cambios y gestión de configuración en una sola disciplina. Las disciplinas son entonces:
- Modelación - Implementación - Prueba - Despliegue - Gestión de configuración - Gestión de Proyecto - Ambiente
Las fases y su resultado final coinciden con la propuesta de RUP y son representadas en la tabla 2.
Tabla 2:Fases de AUP
Fase Objetivos Hito
Inicio Identificar el alcance inicial del proyecto, una arquitectura potencial, la interface de usuario inicialy la aceptación de los involucrados
Objetivos del ciclo de vida (LifeCycleObjectives: LCO)
Elaboración Probar la arquitectura del sistema
Ciclo de vida de la arquitectura(LifeCycleArquitecture; LCA)
Construcción Construir el Software que trabaje sobre bases iterativas y que encuentre las necesidades de mayor prioridad de los involucrados
Capacidad operacional inicial (InitialOperationalCapability; IOC)
Transición Validar y desplegar el sistema en el ambiente de producción
Entrega del producto (ProductRelease; PR)
Fuente: Los Autores.
El uso de esta metodología, permitió generar una versión de pruebas en corto tiempo, la cual fue madurando de acuerdo a las necesidades puntuales del negocio, dando como resultado una aplicación estable y robusta.
34
4.2. MODELO DE REQUISITOS.
La especificación de requisitos de software (SRS) que se presenta a continuación, está basado y es conforme con el estándar IEEE Std 830-1998.Para presentar los requisitos del sistema de información, se usará el formato presentado en la tabla 3.
Tabla 3: Esquema general de los requisitos
Título:
Código:
Prioridad: Estado:
Autor(es): Rol(es):
Descripción:
Requisitos relacionados:
Fuente: Los autores
A continuación, se explican los campos del formato:
Título: breve resumen del contenido del requisito.
Código: sirve para la identificación de cada requisito. Se asigna de forma única y su parametrización es la siguiente: RF – NN o RNF – NN donde “RF” indica se es un requisito funcional, “RNF” indica si es un requisito no funcional y “NN” indica el número de requisito.
Prioridad: la prioridad tiene que ver con el orden de implementación de los requisitos. Los posibles valores que pueden tomar este campo son: Alta, Media y Baja.
Estado: punto en el que se encuentra el requisito dentro de la aplicación, puede ser “implementado” o sin “implementar”.
Autor(es): persona o personas que han escrito el requisito.
Rol(es): se rellena este campo con los roles que lo pueden cumplir, si no se aplica NA “No Aplica”.
Descripción: explicación detallada y clara del requisito.
Requisitos Relacionados: lista de requisitos que se pueden relacionar de alguna forma o sean importantes para el entendimiento del requisito que se está manejando.
Debido a la complejidad del sistema a diseñar, el modelo de requisitos se dividió en dos grandes grupos:
35
A. Requisitos funcionales: En esta sección se presentan los requisitos primordiales que debe cumplir el sistema de información, y definen la lógica de negocio que se debe desarrollar.
B. Requisitos no funcionales: Los requisitos no funcionales que se presentan permiten delimitar el sistema a ser diseñado, así como establecer las interfaces hombre-máquina involucradas. Los requisitos no funcionales, se presentan en el Anexo A.
4.2.1. Requisitos Funcionales.
Los requisitos funcionales son los más importantes ya que definen la lógica de negocio y se dividen en las siguientes secciones:
A. Requisitos de Inicio de sesión: Requisitos fundamentales de seguridad de la aplicación y definición de roles.
B. Requisito de Registro de Bici-Usuarios: Se presentan los requisitos que debe cumplir el software para registrar a los Bici-Usuarios.
C. Requisito de Registro de Bicicletas: Indican los requisitos que se deben tener en cuenta para registrar las bicicletas.
D. Requisitos de Reportes: Define los reportes que debe generar el sistema.
4.2.1.1. Requisito de Inicio de Sesión.
Para iniciar sesión, los operadores deben ingresar nombre de usuario y contraseña.
Si los datos ingresados son correctos, el sistema debe permitir el ingreso a la
aplicación de acuerdo al perfil del usuario.
Si los datos no son correctos, debe aparecer un mensaje de advertencia
donde especifique el motivo por el cual no pudo iniciar sesión.
Los inicios de sesión validos mantendrán en memoria el ID del usuario, para permitir relacionarlos en las tablas de eventos de ingresos y salidas. La tabla 4, indica los requisitos de inicio de sesión.
Debido a que cada evento generado quedara relacionado con un operador, es de suma importancia, que los operadores no se borren del sistema, para mantener la integridad de los datos. Si se desea que un operador no ingrese al sistema, se tendrá la opción de bloquear su inicio de sesión, sin necesidad de eliminarlo de la base de datos.
36
Tabla 4: Requisitos: Inicio de Sesión.
Título: Iniciar Sesión.
Código: RF-01
Prioridad: Alta Estado: Implementado
Autor(es): Wilson Salinas, Jorge Amaya Rol(es): NA
Descripción: Para iniciar sesión, los usuarios del sistema deben ingresar nombre de usuario y contraseña para ser validados.
Requisitos relacionados:
Fuente: Los autores
Las contraseñas de los usuarios del sistema, deben poseer características de alta
seguridad cumpliendo con las siguientes reglas:
Longitud mínima de 8 caracteres.
Debe tener por lo menos una letra mayúscula.
Debe tener por lo menos una letra minúscula.
Debe tener por lo menos un número.
Debe tener por lo menos un carácter (.,!&%$·#+*-_:;)
Debe renovarse cada tres meses.
En la tabla 5 se relaciona el requisito de las contraseñas de alta seguridad.
Tabla 5: Requisitos: Contraseñas de Alta Seguridad.
Título: Ingresar Contraseña de Alta Seguridad.
Código: RF-02
Prioridad: Alta Estado: Implementado
Autor(es): Wilson Salinas, Jorge Amaya Rol(es): NA
Descripción: Las contraseñas de los operadores deben cumplir con características de alta seguridad para ser válidas.
Requisitos relacionados:RF-01
Fuente: Los autores
Para el uso del sistema, se requieren como mínimo dos perfiles de Usuarios, la tabla
6 especifica el requisito para los perfiles de usuarios.
37
Operadores: Estos usuarios serán los encargados de realizar registros de Bici-
Usuarios, Bicicletas, y eventos de ingreso y salida.
Por seguridad no podrán eliminar ningún Bici-Usuario ya creado, pero si
podrán modificar y agregar más Bicicletas, así como generar reportes.
Administradores: Estos usuarios tendrán permiso para configurar la base de
datos del sistema y realizar todas las operaciones que realiza un usuario con
perfil Operador.
Tabla 6: Requisitos: Perfiles de Usuarios.
Título: Crear Perfiles de Usuarios.
Código: RF-03
Prioridad: Alta Estado: Implementado
Autor(es): Wilson Salinas, Jorge Amaya Rol(es): NA
Descripción:Existen dos perfiles: Operadores y administradores.
Requisitos relacionados:RF-01
Fuente: Los autores
4.2.1.2. Registro de Bici-Usuarios.
El sistema debe tener un formulario para registro de bici-usuarios. Esta pantalla permitirá recibir datos desde el teclado y/ó lector de código de barras 2D, para buscar por número de documento de identificación al bici-usuario. Si el bici-usuario ya existe en la base de datos, se visualizara su información en este formulario. Si no existe en la base de datos, el formulario quedara en modo edición para ingresar los datos del bici-usuario. Desde la tabla 7 hasta la tabla 10, se relacionan los requisitos para la recolección de datos de bici-usuarios.
Tabla 7: Registrar Bici-Usuarios.
Título: Registrar Bici-Usuarios
Código: RF-04
Prioridad: Alta Estado: Implementado
Autor(es): Wilson Salinas, Jorge Amaya Rol(es): NA
Descripción:Permite registrar datos básicos de los bici-usuarios.
Requisitos relacionados:
Fuente: Los autores
Los datos mínimos que se deben recolectar de cada Bici-Usuario, son:Nombres,
Apellidos, Documento de Identificación, Tipo de Documento, Estrato socioeconómico,
Ocupación, Dirección, Barrio y Teléfono.
38
El sistema debe permitir la captura de la foto de los bici-usuarios. La foto, se usara para que el operador realice verificación visual del Bici-Usuario. Este requisito se especifica en la Tabla 8.
Tabla 8: Fotografiar a Bici-Usuarios.
Título: Capturar Fotografía de Bici-Usuarios
Código: RF-05
Prioridad: Alta Estado: Implementado
Autor(es): Wilson Salinas, Jorge Amaya
Rol(es): NA
Descripción:El operador deberá capturar la foto del bici-usuario en el momento del ingreso.
Requisitos relacionados:RF-04
Fuente: Los autores
El sistema debe permitir la captura de la huella dactilar de los bici-usuarios. La huella dactilar, se usara para realizar validación 1-1 del Bici-Usuario. La tabla 9 especifica el requisito para la captura de las huellas dactilares.
Tabla 9: Requisitos: Huella Dactilar de Bici-Usuarios.
Título: Capturar Huella Dactilar de Bici-Usuarios
Código: RF-06
Prioridad: Alta Estado: Implementado
Autor(es): Wilson Salinas, Jorge Amaya
Rol(es): NA
Descripción:El operador deberá capturar la huella dactilar del bici-usuario en el momento del primer ingreso. Para luego ser utilizada como medio de autenticación 1 a 1 con respecto a los templates almacenados en la base de datos.
Requisitos relacionados:RF-04
Fuente: Los autores
Para aumentar la velocidad de enrolamiento, el sistema debe permitir la lectura de códigos de Barras 2D en formato PDF417, el cual es usado en el código de barras de cedulas de ciudadanía y tarjetas de identidad. Se deben cargar los datos almacenados en el código de barras en el formulario de Bici-Usuarios. Este requisito se relaciona en la tabla 10.
39
Tabla 10: Requisitos: Lectura de documentos con códigos de barras en 2D.
Título: Leer documentos con códigos de barras en 2D
Código: RF-07
Prioridad: Alta Estado: Implementado
Autor(es): Wilson Salinas, Jorge Amaya
Rol(es): NA
Descripción:Permite la lectura de códigos de Barras 2D formato PDF417, impresos en cedulas de ciudadanía y tarjetas de identidad.
Requisitos relacionados:RF-04
Fuente: Los autores
4.2.1.3. Requisito de Registro de Bicicletas.
El formulario para registro de bici-usuarios, debe tener una sección para registrar la o
las bicicletas propiedad de un Bici-Usuario. Este requisito se relaciona en la tabla 11.
Los datos básicos que se deben almacenar de la bicicleta son:Tipo de Bicicleta,
Marca, Serial de Fabricación ó Número de Marco, Color y Observaciones.
Tabla 11: Requisitos: Registrar Bicicletas.
Título: Registrar Bicicletas
Código: RF-08
Prioridad: Alta Estado: Implementado
Autor(es): Wilson Salinas, Jorge Amaya
Rol(es): NA
Descripción:
Requisitos relacionados:
Fuente: Los autores
El sistema debe tener la opción de mostrar en algún momento determinado, el estado de la bicicleta, es decir, si está dentro o fuera del parqueadero, y debe generar un mensaje de alerta para las bicicletas que hayan estado parqueadas más de un día sin ser retiradas. Este requisito se relaciona en la tabla 12.
La información del estado de las bicicletas, es de vital importancia para los bici-parqueaderos que tengan alto flujo de bicicletas, puesto que quedaran pocas plazas de estacionamiento libres si las bicicletas no se retiran constantemente, saturando el servicio e impidiendo que otros bici-usuarios utilicen el sistema.
Si un bici-usuario deja su bicicleta por más de 24 horas, se le realizara un llamado de atención por parte del operador del sistema. En caso de que el bici-usuario no regrese por motivos externos, se realizara una búsqueda del bici-usuario por medio de los datos consignados en la base de datos.
40
Tabla 12: Requisitos: Estado de Bicicletas.
Título: Registrar Estado de Bicicletas
Código: RF-09
Prioridad: Alta Estado: Implementado
Autor(es): Wilson Salinas, Jorge Amaya Rol(es): NA
Descripción: permite identificar si la bicicleta se encuentra dentro o fuera del bici-parqueadero.
Requisitos relacionados:
Fuente: Los autores
Se debe imprimir un stiker para la bicicleta, el cual debe tener relacionado el número de marco o serial de fabricación de la bicicleta, y la cedula de ciudadanía del Bici-Usuario correspondiente.
En el stiker, debe estar impreso el código de barras de la cedula de ciudadanía del Bici-Usuario, para usarlo como medio alternativo de búsqueda desde el sistema de información, realizando la lectura del código de barras que va impreso en el marco de la bicicleta.
Los stikers, deben ser impresos con materiales durables que permitan prolongada vida útil y uso en la intemperie. El requisto de la impresión del stiker, se relaciona en la tabla 13.
Tabla 13: Requisitos: Impresión de Stiker para Bicicletas.
Título: ImprimirStiker para Bicicletas
Código: RF-10
Prioridad: Alta Estado: Implementado
Autor(es): Wilson Salinas, Jorge Amaya Rol(es): NA
Descripción:se imprime un sticker en el cual se relacionan los datos del usuario con los de su bicicleta.
Requisitos relacionados:
Fuente: Los autores
4.2.1.4. Requisitos de Reportes.
El sistema de información debe permitir generar reportes de acuerdo a los campos filtrados por el operador del sistema.Dentro de los reportes que debe generar el sistema se encuentran:
Grafica de Ingresos Vs Salidas: permite generar un gráfico histórico de puntos y líneas donde se visualicen la cantidad de bicicletas que ingresaron y salieron a diario.
41
Histórico de Ingresos y salidas: permite generar un listado histórico de todos los ingresos y salidas del sistema.
Histórico de ingresos y salidas con información detallada del Bici-usuario: permite generar un listado histórico de todos los ingresos y salidas del sistema, con información adicional de cada bici-usuario, incluyendo la fotografía.
Los diferentes requisitos para la generación de reportes, se encuentran documentados en las tablas 14, 15, 16 y 17.
Tabla 14: Requisitos: Filtro de Reportes.
Título: Generar Reportes
Código: RF-11
Prioridad: Alta Estado: Implementado
Autor(es): Wilson Salinas, Jorge Amaya Rol(es): NA
Descripción: El sistema de información debe ser versátil a la hora de generar reportes, por lo tanto, los filtros para generar reportes deben hacerse por uno o varios campos de la base de datos de Bici-Usuarios.
Requisitos relacionados:
Fuente: Los autores
Tabla 15: Requisitos: Reporte de Ingresos vs. Salidas.
Título: Generar Reporte de Ingresos vs. Salidas
Código: RF-12
Prioridad: Alta Estado: Implementado
Autor(es): Wilson Salinas, Jorge Amaya Rol(es): NA
Descripción: Debe existir un reporte que permita gráficamente comparar la cantidad de ingresos y salidas diarias. El reporte se debe estar limitado para ser generado en cualquier intervalo de tiempo donde existan datos.
Requisitos relacionados:
Fuente: Los autores
Tabla 16: Requisitos: Reporte Histórico de ingresos y salidas.
Título: Generar Reporte Histórico de ingresos y salidas.
Código: RF-13
Prioridad: Alta Estado: Implementado
Autor(es): Wilson Salinas, Jorge Amaya Rol(es): NA
Descripción: Debe existir un reporte que genere un listado de ingresos y salidas de Bici-Usuarios.
42
Requisitos relacionados:
Fuente: Los autores
Tabla 17: Requisitos: Reporte Histórico de ingresos y salidas con información detallada del Bici-Usuario.
Título: GenerarReporte Histórico de ingresos y salidas con información detallada del Bici-Usuario
Código: RF-14
Prioridad: Alta Estado: Implementado
Autor(es): Wilson Salinas, Jorge Amaya
Rol(es): NA
Descripción: Debe existir un reporte que genere un listado de ingresos y salidas de Bici-Usuarios, y permita visualizar información detallada de los Bici-Usuarios.
Requisitos relacionados:
Fuente: Los autores
Los informes generados serán exportados a otros formatos, este requisito se documenta en la tabla 18.
Tabla 18: Requisitos: Exportación de Reportes
Título: Exportar Reportes
Código: RF-15
Prioridad: Alta Estado: Implementado
Autor(es): Wilson Salinas, Jorge Amaya Rol(es): NA
Descripción: Los reportes deben ser exportables fácilmente a otros formatos ó tipos de documentos, entre ellos como mínimo a Word, Excel y PDF.
Requisitos relacionados:
Fuente: Los autores
4.3. DIAGRAMAS DE CASOS DE USO.
Para una mejor comprensión el modelo se presentara en varios casos de uso con su descripción. Los casos de uso se definen en dos grupos:
Roles.
Registro de Bici-Usuarios y Bicicletas.
4.3.1. Casos de Uso Roles de Usuarios.
El caso de Uso Roles de Usuarios (Figura 8), permite definir los Actores que manipularan el sistema y las funciones permitidas para cada uno de ellos.
43
El actor Administrador, puede realizar todas las funciones.
El actor Operador, no podrá administrar operadores ni tablas.
Figura 8: Casos de Uso: Roles de Usuario.
A continuación se presentan las especificaciones de los casos de uso. Cada especificación de caso de uso, se presenta en el formato de la tabla 19.
Tabla 19: Formato para especificación de casos de uso.
Nombre: Número de Caso de Uso – Nombre del caso de uso.
Actores: Actores que ejecutaran el caso de uso
Propósito: Se define la finalidad del caso de uso
Escenario: Se describen los pasos que deben ejecutar los actores para que se ejecute correctamente el caso de uso.
44
En la tabla 20, se especifican los casos de uso que definen las acciones permitidas de acuerdo a los diferentes roles de usuario. En general, los usuarios del sistema registrados como operador, no podrán administrar los inicios de sesión y la configuración de las tablas básicas. El usuario administrador por el contrario, será el encargado de la configuración de los inicios de sesión y de la configuración de las tablas.
Tabla 20: Especificación de Casos de Uso: Roles de Usuario.
Nombre: CU1 - Iniciar Sesión.
Actores: Administrador, Operador
Propósito: El usuario debe registrarse para poder acceder al sistema con sus propios permisos. Un usuario que no haya iniciado sesión no puede entrar al sistema
Escenario:
1. Digitar nombre de usuario. 2. Digitar contraseña. 3. Pulsar “OK”, se verifica que el usuario este registrado en la
base de datos. Si la comprobación es correcta debe cerrar el formulario de inicio de sesión y habilitar los botones de la barra de herramientas de acuerdo al perfil del usuario. Si la comprobación es incorrecta, el sistema debe indicarle el motivo por el cual no pudo ingresar, entre los motivos deben estar:
Nombre de usuario inexistente.
Contraseña invalida.
Contraseña caducada. Si la contraseña se caducó, debe mostrar un mensaje para actualizar la contraseña.
4. Pulsar Cancelar para cerrar el formulario de inicio de sesión.
Todos los iconos de la barra de herramientas quedan bloqueados a excepción del icono de iniciar sesión.
Nombre: CU2 - Registrar Bici-Usuarios.
Actores: Administrador, Operador.
Propósito: Gestiona los datos de los Bici-usuarios.
Escenario: Hacer clic en el icono Bici-Usuarios de la barra de herramientas operativa.
Nombre: CU3 - Registrar Bicicletas.
45
Actores: Administrador, Operador.
Propósito: Gestiona los datos de las Bicicletas.
Escenario: Hacer clic en el icono Bici-Usuarios de la barra de herramientas operativa.
Nombre: CU4 - Registrar Ingreso y Salida de Bici-Parqueadero.
Actores: Administrador, Operador.
Propósito: Registra los ingresos y salidas de los biciusuarios con su bicicleta en los bici-parqueaderos.
Escenario: Clic en botón ingreso ó salida según corresponda del formulario registro de bici-usuarios.
Nombre: Administrar Operadores.
Actores: Administrador.
Propósito: Gestionar los operadores del sistema.
Escenario: Hacer clic en el icono Administración de Operadores de la barra de herramientas administrativa.
Nombre: Administrar Tablas.
Actores: Administrador
Propósito: Gestionar las tablas que componen las listas desplegables del formulario de registro de Bici-Usuarios.
Escenario: Hacer clic en el icono Administración de Tablas de la barra de herramientas administrativa.
Fuente: Los autores
4.3.2. Casos de Uso Registro de Bici-Usuarios y Bicicletas en Bici-Parqueadero.
Los casos de uso para el registro de los bici-usuarios y bicicletas en los bici-parqueaderos son los más importantes de toda la aplicación, y definen la lógica de negocio, este caso de uso se ve diagramado en la figura 9.
46
Figura 9: Casos de Uso: Registro de bici-usuarios.
Los actores de este caso de uso son:
Usuario: es el usuario que realizo el registro y puede ser un operador o un administrador que haya iniciado sesión en el sistema.
47
Bici-Usuario: es la persona propietaria de la bicicleta que desea ingresar o salir del bici-parqueadero.
Bicicleta: es el vehículo que el bici-usuario desea almacenar en el bici-parqueadero por un tiempo indeterminado.
Tanto el registro de ingreso como el registro de salida se realizan con una secuencia lógica que permiten definir los casos de uso diagramados en la figura 9.
La tabla 21, es la especificación de los casos de uso del registro de bici-usuarios, y bicicletas.
Tabla 21: Casos de Uso: Registro de Bici-Usuarios.
Nombre: Presentar Documentos.
Actores: Bici Usuario
Propósito: Presenta documento de identificación para ser leído por el lector de código de barras.
Escenario:
El bici-usuario debe presentar la cedula de ciudadanía o la tarjeta de identidad para ser registrado en el sistema, así como la tarjeta de propiedad de la bicicleta, para evitar problemas de seguridad y verificar que la bicicleta pertenezca al bici-usuario.
Nombre: Leer código de Barras del Documento.
Actores: Operador, Administrador
Propósito:
Realizar la lectura del documento presentado por el biciusuario para la carga automática de los datos almacenados en el código de barras de formato PDF417. Los datos que se cargan automáticamente son:
Nombres.
Apellidos.
Número de Documento.
Tipo de Documento (Cedula de ciudanía ó Tarjeta de Identidad).
Fecha de Nacimiento.
RH.
Genero (Masculino ó Femenino).
Escenario:
El documento debe presentarse frente al lector de códigos de barras. Si el biciusuario ya está registrado, se cargan los datos desde la base de datos. Si el biciusuario es nuevo se cargan los datos desde el documento de identificación.
Nombre: Registrar Datos Adicionales.
48
Actores: Operador, Administrador, Bici-Usuario.
Propósito:
Alimentar la base de datos de Bici-Usuarios con los datos adicionales que solicita el cliente final. Los datos adicionales deben ser digitados por el operador del sistema. Los datos adicionales solicitados por el cliente final son:
Estrato socioeconómico. (Estrato 0 a 6)
Ocupación (Trabaja ó Estudia).
Barrio.
Dirección.
Teléfono fijo.
Teléfono celular.
Correo electrónico.
Escenario: El formulario de Bici-Usuarios, debe tener dos secciones Datos Básicos y Datos Adicionales.
Nombre: Captura de Fotografía.
Actores: Operador, Administrador, Bici-Usuario.
Propósito: Tener un registro fotográfico del Bici-Usuario.
Escenario: El operador debe capturar la fotografía del bici-usuario usando el formulario de captura de fotografías.
Nombre: Captura de huella dactilar.
Actores: Operador, Administrador, Bici-Usuario.
Propósito: Tener un registro de la huella dactilar para autenticar a los bici-usuarios.
Escenario: El operador debe capturar la imagen de la huella dactilar del bici-usuario usando el formulario de captura de fotografías.
Fuente: Los autores
Luego de obtener todos los datos requeridos para los bici-usuarios, se procede a registrar la bicicleta del biciusuario. En la tabla 22 se especifican los casos de uso necesario para realizar el registro de las bicicletas.
49
Tabla 22: Casos de Uso: Registro de Bicicletas.
Nombre: Registrar Bicicleta.
Actores: Operador, Administrador, Bicicleta.
Propósito:
El bici-usuario presenta la tarjeta de propiedad de la bicicleta, para que el operador del sistema ingrese manualmente los datos de la bicicleta por primera vez.Los datos solicitados para la bicicleta son:
Número de serie.
Tipo de Bicicleta.
Color.
Marca.
Modelo.
Observaciones.
Escenario: El formulario de registro de bicicletas permite registrar una o varias bicicletas por biciusuario.
Nombre: Imprimir stiker de Bicicleta.
Actores: Operador, Administrador, Bicicleta.
Propósito:
Imprimir un stiker para la bicicleta el cual se utilizara como medio de identificación de bicicletas ya registradas. El stiker debe tener los datos:
Numero de documento del Bici-Usuario que registro la bicicleta.
Código de barras del serial de fabricación de la bicicleta.
Nombre de Bici parqueadero.
Escenario: El stiker, puede usarse posteriormente para realizar una búsqueda rápida con el serial de la bicicleta. Cargado los datos del biciusuario propietario de la bicicleta.
Nombre: Registrar estado de bicicleta.
Actores: Operador, Administrador, Bici-Usuario, Bicicleta.
Propósito: Registrar el ingreso o salida de la bicicleta al biciparqueadero. Se debe generar un registro histórico en la base de datos, almacenando la fecha y hora de ingreso y la fecha y hora de salida de la bicicleta.
Escenario: Se debe tener un botón dispuesto para el registro de ingreso o salida de la bicicleta, el cual se configurara de acuerdo al estado actual de la bicicleta.
Fuente: Los autores
50
Los datos almacenados en el sistema, servirán para que el cliente final identifique y clasifique los usuarios que usan los biciparqueaderos, así como verificar la frecuencia de uso de los biciparqueaderos. Para ello, se requiere de reportes especializados que permitan filtrar y exportar los datos. La tabla 23 especifica los casos de uso concernientes a la generación de reportes por parte de los actores Operador, ó Administrador.
Tabla 23: Casos de Uso: Reportes.
Nombre: Generar Consultas Históricas.
Actores: Operador, Administrador.
Propósito: Generar consultas históricas de los ingresos y salidas de biciusuarios y bicicletas en los bici parqueaderos.
Escenario: El operador del sistema podrá realizar consultas a las bases de datos para generar reportes que informen la cantidad de ingresos y salidas de biciusuarios en intervalos de tiempo definidos.
Nombre: Exportar Informe.
Actores: Operador, Administrador.
Propósito: Los informes creados podrán exportarse a diferentes formatos, entre los cuales deben estar: Word, Excel, PDF, CSV.
Escenario: Luego de realizado el informe debe existir un botón para exportar informe.
Fuente: Los autores
4.4. REGLAS DE NEGOCIO.
Las principales reglas de negocio que posee el sistema de información son las correspondientes a:
Registrar el ingreso de bici-usuarios con su respectiva bicicleta al bici-parqueadero
Registrar la salida de bici-usuarioscon su respectiva bicicleta del bici-parqueadero.
Para documentar adecuadamente cada regla de negocio, se realizan los diagramas EPC (Cadena de procesos condicionados por eventos) los cuales son utilizados para documentar la secuencia detallada de las actividades de los procesos del bici-parqueadero, las cuales son impulsadas por eventos y controladas por nodos de decisión, concatenando eventos y funciones en un orden lógico (funcional y temporal) produciendo de esta forma cadenas de procesos.
51
4.4.1. Regla de negocio para registro de ingreso.
Para realizar el registro de ingreso del Bici-Usuario, el operador del sistema debe realizar la búsqueda en la base de datos del bici-usuario, ya sea digitando el número de documento de identificación, ó realizando la lectura del código de barras PDF417 de un documento de identificación ya sea la cedula de ciudadanía ó la tarjeta de identidad. La figura 10 presenta el diagrama EPC para la regla de negocio de ingreso al bici-parqueadero.
Figura 10:Regla de negocio para registro de ingreso.
Existen dos eventos concatenados a la función Búsqueda de Bici-Usuario por documento de identidad, a saber:
Bici-Usuario registrado: este evento ocurre cuando el bici-usuario ya ha sido registrado con anterioridad en la base de datos. En este caso, se debe verificar que la bicicleta que está ingresando sea la misma bicicleta que tiene registrada en base de datos para proceder a registrar el ingreso. En caso contrario se debe registrar la nueva bicicleta y finalmente registrar su ingreso.
Bici-Usuario Nuevo: Este evento ocurre cuando es la primera vez que se registra al Bici-Usuario. Se debe proceder a registrar su bicicleta y finalmente registrar su ingreso.
52
4.4.2. Regla de negocio para registro de salida.
El registro de salida, se realiza desde que el operador busca en la base de datos al Bici-Usuario, y este presenta el estado “Dentro”. Existen dos posibles eventos que se concatenan con la función búsqueda de usuario:
El Bici-Usuario tiene una sola bicicleta registrada. En este caso, el operador solo debe registrar la salida del parqueadero.
El Bici-Usuario tiene varias bicicletas registradas. En este caso el operador debe seleccionar la bicicleta que el Bici-Usuario está retirando.
La figura 11, presenta el diagrama EPC para la regla de negocio de registro de salida.
Figura 11: Regla de negocio para registro de salida.
53
4.5. DIAGRAMA DE CLASES.
El diagrama de clases se diseñó principalmente con relación a la lógica de negocio documentada. A continuación se explican las clases, atributos y métodos identificados, junto con las asociaciones y agregaciones entre objetos.
4.5.1. Clases, Atributos y Métodos Identificados.
En la capa de negocio de la aplicación, se identifican cuatro clases (figura 12):
Operador: Esta clase permite cargar los datos de los operadores y administradores del sistema. Dentro de sus métodos están las operaciones básicas de agregar, búsqueda, eliminar, modificar y cambiar contraseña.
Bici-Usuarios: La clase Bici-Usuarios posee los atributos necesarios para realizar las operaciones básicas con los Bici-Usuarios.
Bicicleta: La clase bicicleta define los atributos que se usaran para relacionar las bicicletas de los bici-usuarios.
RegistrosParqueadero: Esta clase permite realizar registros históricos en las bases de datos. No se permite modificar y eliminar por seguridad e integridad de los datos.
Figura 12:Clases, Atributos y Métodos Identificados.
54
4.5.2. Asociaciones y Agregaciones Entre Clases.
El diagrama de asociaciones y agregaciones entre clases se muestra en la figura 13.
La asociación expresa una conexión bidireccional entreobjetos.
Una asociación es una abstracción de la relaciónexistente en los enlaces entre los objetos.
Figura 13:Asociaciones y Agregaciones Entre Clases.
En la capa de negocio del sistema de información, se determinan cuatro relaciones entre las clases de los tipos:
A. Relaciones por agregación: existen tres relaciones por agregación por valor entre la clase RegistroParqueadero y las clases Operator, Bici-Usuario y Bicicleta, en donde se destaca que:
o Un RegistroParqueadero posee Bici-usuario, Bicicleta y Operator.
o Para cada registro de un Bici-usuario, pueden existir n RegistroParqueadero.
o Para cada registro de una Bicicleta, pueden existir n RegistroParqueadero.
55
o Para cada registro de una Operator, pueden existir n RegistroParqueadero.
o Si se destruye un objeto RegistroParqueadero no se destruyen Operator, Bicicleta ni Bici-usuario.
o Si se destruye un objeto Operator, Bicicleta y/o Bici-usuario, el objeto RegistroParqueadero quedara incompleto lo cual puede generar perdida de la información, por lo tanto esta eliminación debe ser controlada.
B. Relaciones por asociación:existe una relación por asociación entre las clases Bici-usuario y Bicicleta, en donde se destaca que:
o Un Bici-usuario puede tener asociados muchos objetos Bicicleta.
o Un objeto Bicicleta puede tener asociado solo un objeto Bici-usuario.
Generalizando, se plantea que los bici-usuarios pueden registrar más de una bicicleta en el sistema, y las bicicletas pueden registrarse a un solo objeto bici-usuarios.
Sin embargo, en la realidad se encuentran casos en los que una bicicleta pertenece a un núcleo familiar, compuesto por varios bici-usuarios, y cualquiera de ellos podría entonces registrar el ingreso y/o salida de la bicicleta. Para solucionar este evento y hacerlo compatible con el modelo, se crea una función ReasignarBicicleta que permite a las bicicletas, realizar la modificación del atributo ID_Biciusuario, de la clase Bicicleta, el cual define el bici-usuario al cual pertenece la bicicleta. Esta modificación, solo se puede realizar al momento del ingreso al biciparqueadero. De esta forma, solo el mismo biciusuario podrá registrar la salida de la bicicleta, pero cualquier bici-usuario podrá registrar su ingreso.
4.6. DISEÑO DE LA BASE DE DATOS.
El primer paso en el diseño de la base de datos fue analizar los datos que se recolectarían y determinar el uso que se pensaba hacer de los mismos. En la figura 14se muestra un diagrama general de la base de datos. La base de datos diseñada posee catorce (14) tablas relacionadas entre ellas.
56
Figura 14: Diagrama General de la Base de Datos.
Fuente: Los Autores
57
El análisis de las hojas de datos y de los métodos de recolección de datos identificó cinco (5) grupos de datos.Cada grupo de datos se define como un grupo de tablas de datos relacionadas. En un grupo pueden incluirse los datos de uno o más objetos del sistema de información. Los grupos de datos identificados son:
Tablas de Operadores.
Tablas de Bici-Usuarios.
Tablas de Bicicletas.
Tablas de Enlaces.
Tabas de Registro de Eventos.
Después de identificar los grupos, se identificaron los elementos comunes en las hojas de datos dentro de cada grupo. Estos elementos comunes se encuentran en una tabla, a la cual se enlazan todas las otras tablas del grupo. Esto proveerá una conexión entre las diferentes tablas del grupo y se presentara el diagrama al final del grupo.
Con el fin de facilitar el manejo de los datos y las tablas, cada tabla tendrá por lo menos un campo que contiene un identificador único para ese registro, un campo para identificar quién ingresó los datos y otro campo para registrar cuándo se los ingresó. En la mayoría de los casos, estos campos están ocultos al usuario y el sistema los actualiza de manera automática.
El administrador tendrá acceso a esta información con el fin de reparar los problemas que puedan surgir. En este informe se siguen ciertas convenciones. Los nombres de todas las tablas están en negrita. Los nombres de todas las columnas están en cursiva. Los siguientes valores se pueden encontrar en la Columna de Índices de las tablas de este informe:
Llave: Todos los nombres de columnas en una tabla que tienen el icono de llave indexados juntos para crear un índice primario en la tabla.
4.6.1. Tablas de Operadores.
4.6.1.1. Operadores.
La tabla OPERADORES(tabla 24), permite almacenar los datos requeridos para cada operador. Cabe destacar que:
El campo USERLEVEL, permite definir los permisos que tiene el operador para realizar las funciones básicas para agregar, buscar, eliminar, modificar.
El campo ADMINLEVEL, permite definir los permisos que tiene el administrador para realizar las funciones básicas para agregar, buscar, eliminar, modificar además de cambiar contraseñas.
58
El campo ENABLE, permite establecer si el operador o administrador está habilitado para ingresar al software. Un operador no se elimina nunca del sistema, para evitar la pérdida de relación entre objetos mencionada en el diagrama de clases.
El campo EXPDATE, se usa para almacenar la fecha de expiración de la contraseña, la cual es de tres meses después de ser creada o actualizada. Una vez la fecha actual del sistema sobrepasa el valor del campo EXDATE, el campo ENABLE pasa a valor FALSO y así evitar el acceso al software por el operador hasta que se actualice nuevamente la contraseña.
El campo PASSWORD, debe cumplir con las siguientes características de alta seguridad: incluir letras en mayúsculas y minúsculas, números, caracteres y longitud mínima de 8 caracteres.
Tabla 24: Tabla de operadores
4.6.1.2. Nivel de Administración.
La tabla OPERADORES_ADMINLEVEL (tabla 43), se utiliza para crear perfiles de administración del software yotorgando y habilitando permisos de administración a cada operador en el software.
El campo ID, es la llave principal.
El campo DESCRIPCION, es el nombre que se le dará al perfil de Administrador.
59
El campo PASSWORDS, Define si el operador relacionado podrá cambiar las contraseñas de seguridad del sistema.
El campo DATATABLES, Define si el operador relacionado podrá actualizar, modificar o eliminar datos de las tablas comunes.
El campo SKIN, Permite establecer si el operador relacionado tendrá acceso al cambio de la apariencia de la interface grafica.
Tabla 25: Tabla operadores_adminlevel
4.6.1.3. Nivel de Usuario.
La tablaOPERADORES_USERLEVEL (tabla 25), se usa para habilitar las características que serán habilitadas para el operador delsoftware.
El campo ID, es la llave principal.
El campo DESCRIPCION, es el nombre que se le dará al perfil de Operador.
El campo BICIUSUARIOS, Define si el operador relacionado podrá administrar biciusuarios.
El campo BICICLETAS, Define si el operador relacionado podrá administrar las bicicletas.
El campo HISTORICOS, Define si el operador relacionado podrá registrar eventos históricos del ingreso y salida de bicicletas y biciusuarios.
El campo CONSULTAS, Define si el operador relacionado puede realizar reportes a la base de datos.
El campo EXPORTAR, Define si el operador relacionado podrá exportar las consultas generadas.
60
Tabla 26: Tabla operadores_userlevel
4.6.1.4. Diagrama Entidad Relación Operadores.
En el diagrama entidad relación del grupo operadores (figura 15), se puede apreciar que cada operador del sistema, tendrá una característica para habilitar las funciones de administrador del software y otra para usar las funciones de operación.
Figura 15:Diagrama Entidad Relación Operadores
4.6.2. Tablas de Bici-Usuarios.
Para aumentar la velocidad en la búsqueda de Bici-Usuarios, se diseñó este grupo de tal forma que la búsqueda inicial solo apunte a la tabla 26, si se encuentran objetos en la búsqueda, se cargan los datos adicionales almacenados en la tabla 30.
4.6.2.1. Bici-Usuarios.
La tabla BICIUSUARIOS, permite almacenar los datos básicos de los Bici-Usuarios, cabe destacar los siguientes campos:
61
El campo TIPO_IDENTIFICACION, se relaciona con la tabla 29, y se creó con el fin de almacenar el tipo de documento que presenta el biciusuario al momento de su registro.
El campo ID_TIPO_USUARIO se relaciona con la tabla 27, y se encarga de almacenar el estrato socio-económico del Bici-Usuario.
El campo ESTADO, permite establecer si el Bici-Usuario ingreso ó salió del cicloparqueadero.
Tabla 26: Tabla Bici-Usuarios
Fuente: Los Autores
4.6.2.2. Tipo de Bici-Usuario.
En la tabla 27, se almacenan los estratos socioeconómicos en el campo DESCRIPCION, como se observa en la tabla 28:
62
Tabla 27: Tabla Tipo_Usuarios
Fuente: Los Autores
Tabla 28: ContenidoTabla DescripciónTipo_Usuarios
ID DESCRIPCION
1 BICI-USUARIO ESTRATO 0
2 BICI-USUARIO ESTRATO 1
3 BICI-USUARIO ESTRATO 2
4 BICI-USUARIO ESTRATO 3
5 BICI-USUARIO ESTRATO 4
6 BICI-USUARIO ESTRATO 5
7 BICI-USUARIO ESTRATO 6
8 BICI-USUARIO RESTRINGIDO
Fuente: Los autores
4.6.2.3. Tipo de Identificación.
En la tabla 29 se definen los diferentes documentos con los que se puede registrar un bici-usuario, la tabla 30 lista los elementos que posee esta tabla.
Tabla 29: Tabla Tipo_Identificación
Fuente: Los autores
63
Tabla 30: ContenidoTablaTipo_Identificacion
ID DESCRIPCION
1 Cedula de Ciudadanía
2 Tarjeta de Identidad
Fuente: Los autores
4.6.2.4. Datos Bici-Usuario Adicionales.
La tabla 31, Biciusuarios_Anexos, permite alamacenar la información adicional de cada biciusuario, y se relaciona uno a uno con la tabla 26 biciusuarios.
Tabla 31: Tabla Biciusuarios_Anexos
Fuente: Los autores
El campo ID_OCUPACION, se relaciona con la tabla 32.
4.6.2.5. Tipo de Ocupación.
4.6.2.6. Tabla 32: Tabla Tipo_ocupación
64
Fuente: Los autores
La tabla32, posee los valores consignados en la tabla 33.
Tabla 33: Contenido Tabla DescripciónTipo_ocupación
ID DESCRIPCION
1 ESTUDIA
2 TRABAJA
3 TRABAJA Y ESTUDIA
4 NINGUNA
Fuente: Los autores
4.6.2.7. Diagrama Entidad Relación Bici-Usuarios.
En el diagrama entidad relación del grupo Bici-Usuarios, se establece una relación 1 a 1 entre las tablas BICIUSUARIOS y BICIUSUARIO_ANEXOS, en las otras relaciones se destaca el uso de las relaciones 1 a n, para facilitar la búsqueda y disminuir el tamaño de uso en disco por cada registro de Bici-Usuarios.
Figura 16:Diagrama Entidad Relación Bici-Usuarios
Fuente: Los autores
4.6.3. Tablas de Bicicletas.
Las tablas del grupo de bicicletas, permiten almacenar la caracterización de las bicicletas.
65
4.6.3.1. Tipos de Bicicletas.
Tabla 34: Tabla Tipo_bicicleta
Fuente: Los autores
Los valores almacenados en la tabla32se consignan en la tabla 35:
Tabla 35: Contenido Tabla DescripciónTipo_bicicleta
ID DESCRIPCION
1 MONTAÑA
2 ELECTRICA
3 MOTOR
4 URBANA
5 PLEGABLE
6 PISTA
7 CROSS
8 BICITAXI
9 TRICICLO
10 CUATRICICLO
11 MONARETA
12 TODOTERRENO
13 SEMIPROFESIONAL
14 OTRO
15 TURISMO
16 PANADERA
17 CARGA
18 CARRERAS
19 PLAYERA
66
Fuente: Los autores
4.6.3.2. Colores de Bicicletas.
Tabla 36: Tabla colores bicicleta
Fuente: Los autores
Los valores almacenados en la tabla 36, son los colores binarios y sus combinaciones en dos y tres colores, agregando colores especiales como: cromado, plateado, mate, pelado.
4.6.3.3. Bicicletas.
Tabla 37: Tablabicicletas
Fuente: Los autores
La tabla 37, permite caracterizar las bicicletas, cabe destacar el campo STATUS, el cual define si una bicicleta está dentro o fuera del bici parqueadero.
67
4.6.3.4. Diagrama Entidad Relación Bicicletas.
Figura 17: Diagrama Entidad Relación Bicicletas
Fuente: Los autores
En el diagrama entidad relación del grupo Bicicletas, se pueden apreciar las relaciones creadas para cada una de las caracterizaciones con respecto al tipo de bicicleta y su color.
4.6.4. Tablas de Enlaces.
Las tablas de enlaces son de suma importancia, ya que permiten realizar una relación directa entre objetos.
4.6.4.1. Enlace Bicicletas-Bici-usuarios
La tabla 38, permite relacionar un bici-usuario con una ó varias bicicletas. Almacenando adicionalmente, la fecha de registro de la relación Bici-Usuario, Bicicleta, junto con el operador que realizo el registro.
Tabla 38: Tabla enlace bicicletas – Bici-usuario
Fuente: Los autores
68
4.6.4.2. Diagrama Entidad Relación Enlace Bicicletas-Bici-usuarios.
El diagrama entidad relación del grupo enlace bicicletas-biciusuarios (figura 17), permite realizar el seguimiento de las asignaciones de las bicicletas a los bici-usuarios.
Por cada registro nuevo de un biciusuario o reasignación de las bicicletas, se creara un elemento en la tabla 38. Que relacionara un solo bici-usuario con una única bicicleta.
Cuando se reasignan bicicletas, el registro de la tabla 38, cambia de acuerdo al nuevo usuario que registro el ingreso de la bicicleta.
Figura 17:Diagrama Entidad Relación Enlace Bicicletas-Bici-usuarios.
Fuente: Los autores
4.6.5. Tablas de Registros de Eventos.
Estas tabas permiten registrar los eventos de ingreso y salida en manera cronológica y su mayor importancia radica en que en base a estas tablas y sus relaciones, serán generados los informes históricos de ingresos y salidas.
4.6.5.1. Tabla Bici parqueaderos.
La tabla 39, permite caracterizar el biciparqueadero. El campo CAPACIDAD_MAXIMA, se refiere a la cantidad máxima de bicicletas que pueden ocupar el parqueadero.
69
El campo CONTADOR_BICICLETAS, se refiere al número actual de bicicletas que se encuentran almacenadas en el Ciclo-parqueadero.
Tabla 39: Tabla Ciclo-parqueaderos
Fuente: Los autores
4.6.5.2. Tabla Histórica de Registro de Ingresos.
Tabla 40: Tabla Histórica de Registro de Ingresos
Fuente: Los autores
En la tabla 40, se almacenan de manera histórica los eventos de ingresos y salida de bicicletas relacionando el id del biciusuario, el id de la bicicleta y el id del operador que realizo el registro.
4.6.5.3. Diagrama Entidad Relación de Registro de Ingresos.
El diagrama entidad relación del grupo registro de ingresos (figura 18), muestra cómo se almacenan los eventos de ingreso y salida de bicicletas, y los actores que se interrelacionan para poder dar como resultado los informes de ingresos y salidas.
70
Figura 18:Diagrama Entidad Relación de Registro de Ingresos.
Fuente: Los autores
El campo FECHA_PROG, nos indica la fecha y hora programada en la que la bicicleta cumple un tiempo de parqueo de 24 horas, y por lo tanto, después de esta fecha y hora, el sistema debe advertir que esta bicicleta se encuentra almacenada por un tiempo mayor del permitido.
4.7. INTERFACE DE USUARIO.
Cumpliendo con los requerimientos de interfaces de usuario descritas en el Anexo A de este documento, se presenta el mapa de navegación en la figura 19.
El mapa de Navegación planteado usa una estructura mixta jerarquica-lineal, también
recibe el nombre de navegación compuesta en la cual el usuario navega libremente y
de forma no lineal, pero también están limitados en algunos momentos por itinerarios prefijados.
71
Figura 19:Mapa de Navegación.
Fuente: Los autores.
Como se aprecia en la figura 19, desde el formulario principal, el cual es un formulario tipo MDI (MultipleDocument Interface), se accede a los otros formularios que componen la aplicación.
Al acceder al formulario frmCicloPark, el usuario tiene la opción de registrar biciusuario, y bicicletas, así como generar reportes. Los formularios que componen la aplicación se definen en la tabla 41.
Tabla 41: Formularios que componen la aplicación.
NOMBRE DESCRIPCION
frmMain Formulario MDI principal, contenedor de los otros formularios.
frmLogin Formulario de inicio de sesión.
frmHelp Formulario para visualizar ayuda.
frmAbout Formulario que muestra la información de licenciamiento y derechos de autor.
frmCicloPark Formulario que permite realizar los registros de biciusuarios y bicicletas.
frmOperators Formulario que administra los operadores y administradores del sistema.
frmDatabase Formulario de configuración de tablas genéricas.
Fuente: Los autores.
72
Para documentar el diseño de las interfaces de usuario, se usa el formato que se muestra en la tabla 42.
Tabla 42: Esquema General de Formularios.
Título:
Campos Tipo Control Observaciones
Nombre de Usuario
Texto Se usa para digitar el nombre de usuario que va a iniciar sesión.
Contraseña Texto oculto Se usa para digitar la contraseña del usuario que va a iniciar sesión.
Comando Tipo Control Observaciones
OK Botón Se usa para que el usuario acepte los datos ingresados e iniciar sesión.
Cancelar Botón Se usa para que el usuario cancele el inicio de sesión.
Requisitos relacionados:
Fuente: Los autores
4.7.1. Barra de Herramientas.
La barra de herramientas (figura 20) se encuentra en el formulario principal, y es lanzadora a los demás formularios. Su diseño es intuitivo gracias a los iconos que se utilizan para el acceso a cada sección. La tabla 43 define cada uno de los botones que componen la barra de herramientas.
Figura 20:Barra de herramientas software.
Fuente: Los autores
Tabla 43: Esquema de la barra de herramientas.
Título: Esquema de la Barra de Herramientas
Comando Tipo Control Observaciones
Botón Inicio de sesión.
Botón Ayuda, despliega el manual de usuario.
73
Botón Acerca de, muestra la información de licenciamiento y derechos de autor.
Botón Módulo de bici parqueaderos.
Botón Administración de operarios.
Botón Configuración de tipos de bici-usuarios.
Botón Configuración de listados.
Botón Administración de bases de datos.
Botón Salir de la aplicación.
Requisitos relacionados:
Fuente: Los autores
4.7.2. Formulario de Inicio de Sesión.
El formulario de inicio de sesión permite controlar el acceso al software y registra en memoria al usuario que utiliza la aplicación. La figura 21 presenta la apariencia del formulario frmLogin, la tabla 44 especifica cada uno de los objetos que lo componen y su funcionalidad.
Figura 21:Formulario de inicio de sesión.
Fuente: Los autores
74
Tabla 44: Esquema del Formulario de inicio de sesión.
Título: Esquema del Formulario de inicio de sesión
Campos Tipo Control Observaciones
Nombre de Usuario
Texto Se usa para digitar el nombre de usuario que va a iniciar sesión.
Contraseña Texto oculto Se usa para digitar la contraseña del usuario que va a iniciar sesión.
Comando Tipo Control Observaciones
OK Botón Se usa para que el usuario acepte los datos ingresados e iniciar sesión.
Cancelar Botón Se usa para que el usuario cancele el inicio de sesión.
Requisitos relacionados:
Fuente: Los autores
4.7.3. Formulario de Registro de Bici-usuarios.
El formulario mas importante de todo el sistema es el formulario de registro de biciusuarios. Por la cantidad de datos que maneja, se optó por realizar un diseño por secciones, permitiendo visualizar datos del biciusuario al mismo tiempo que se visualizan los datos de las bicicletas que este biciusuario tiene registradas. La figura 22 muestra el formulario de registro de bici-usuarios, la figura 23 muestra la sección para registrar bicicletas y la tabla 45 especifica los objetos que componen el formulario.
Figura 22:Formulario de registro de Bici-usuarios.
Fuente: Los autores
75
Este formulario se encuentra dividido en tres secciones:
Sección de Foto y Huella dactilar
Sección de Bici-Usuario
Sección de Bicicletas
Las cuales se describirán en la figura 18.
Figura 23:Formulario de registro de Bici-usuarios 2.
Fuente: Los autores
Tabla 45: Esquema del Formulario Registro de Bici-Usuarios.
Título: Esquema del Formulario Registro de Bici-Usuarios.
Pestaña de Bici-Usuarios
Campos Tipo Control Observaciones
Número de Identificación
Texto En este se digita el número de identificación del Bici-Usuario.
Tipo de Documento
Vista desplegable
En este se especifica qué tipo de documento de identificación tiene el Bici-Usuario.
Nombre(s) Texto Se digita el nombre(s) que se encuentra en el documento de identificación del Bici-Usuario.
Apellido(s) Texto Se digita el apellido(s) que se encuentra en el documento de identificación del Bici-Usuario.
Ocupación Vista desplegable
Se selecciona la ocupación que tiene el Bici-Usuario.
Tipo de Bici-Usuario/Estrato
Vista desplegable
Se selecciona el estrato socio-económico al que pertenece el Bici-Usuario.
Observaciones del Bici-Usuario
Texto Estas se realizan cuando el Bici-Usuario tiene un comportamiento inadecuado en cuanto al manejo del sistema.
Comando Tipo Control Observaciones
Buscar Botón Se usa para buscar un Bici-Usuario
76
Modificar Botón Se usa para modificar la información del Bici-Usuario.
Registro de Entrada
Botón Se usa para registrar la entrada del Bici –Usuario al bici parqueadero.
Borrar Botón Inhabilitado
Inicializar Botón Se usa para limpiar los datos que están cargados en el formulario.
Requisitos relacionados: RF-03
Fuente: Los autores
Figura 24:Formulario de registro de Bici-usuarios datos adicionales
Fuente: Los autores
Tabla 46: Esquema del Formulario Registro de Bici-Usuarios.
Título: Esquema del Formulario Registro de Bici-Usuarios.
Pestaña de Datos Adicionales
Campos Tipo Control Observaciones
Dirección Texto En este se digita la dirección actual donde reside el Bici-Usuario.
Barrio Texto En este se especifica el barrio en el cual se encuentra viviendo el Bici-Usuario.
Teléfono(fijo) Texto Se digita el teléfono fijo del lugar de residencia del Bici-Usuario.
Celular Texto Se digita el número celular del Bici-Usuario.
Correo electrónico
Texto Se digita el correo electrónico del Bici-Usuario.
Sexo Vista desplegable
Se selecciona el sexo del Bici-Usuario.
Rh Vista desplegable
Se Selecciona el grupo sanguíneo que posee el Bici-Usuario
Fecha de Cumpleaños
Texto Se digita la fecha de nacimiento del Bici-Usuario.
Ultimo Cambio Automático Permite visualizar la fecha en la que se le
77
realizo algún tipo de actualización al Bici-Usuario.
Ciclo parqueadero
Vista desplegable
Se debe seleccionar el punto en el cual se registró el Bici-Usuario.
Comando Tipo Control Observaciones
Buscar Botón Se usa para buscar un Bici-Usuario
Modificar Botón Se usa para modificar la información del Bici-Usuario.
Registro de Entrada
Botón Se usa para registrar la entrada del Bici –Usuario al bici parqueadero.
Borrar Botón Inhabilitado
Inicializar Botón Se usa para limpiar los datos que están cargados en el formulario.
Requisitos relacionados:
Fuente: Los autores
4.7.4. Formulario de Captura de Fotografía.
Para realizar la captura de la fotografía se diseñó un formulario dinámico que permita configurar efectos en la imagen capturada, y realiza la integración directa con la cámara web. La figura 25 muestra el formulario de captura fotográfica y en la tabla 47 se especifican sus componentes.
Figura 25:Formulario de Captura de fotografía
Fuente: Los autores
78
Tabla 47: Esquema del Formulario Captura de Fotografía.
Título: Esquema del Formulario Captura de Fotografía.
Pestaña de Foto
Campos Tipo Control Observaciones
Dispositivo Vista desplegable
Se debe seleccionar el driver del dispositivo a utilizar.
Comando Tipo Control Observaciones
Seleccionar Origen de Video
Botón Permite seleccionar la cámara a utilizar.
Seleccionar Formato de Video
Botón Permite escoger la resolución de la imagen.
Ajustar Foto Botón Permite ajustar el tamaño de la foto.
Galería Efectos Botón Permite aplicar brillo, iluminación, saturación y contraste a la foto capturada.
Ajustes Generales
Botón Define la cantidad de compresión de la imagen.
Ajustes E/S de Archivo
Botón Selecciona la carpeta por defecto desde donde se cargar y hacia donde se exportaran las imágenes.
Cargar Default de Usuario
Botón Carga las características del operador seleccionadas.
Crear Default de Fabrica
Botón Carga las características por defecto del programa.
Guardar Default de Usuario
Botón Guarda las características que el usuario cambio en su perfil.
Procesar Botón Inhabilitado.
Aceptar Botón Mediante esta acción acepta las acciones realizadas
Cancelar Botón Mediante este botón cancela las acciones realizadas.
Exportar Botón Exporta la imagen que se capturo.
Congelar Botón Captura la imagen del Bici-Usuario.
Requisitos relacionados:
Fuente: Los autores
4.7.5. Formulario de Captura de Huellas Dactilares.
Para realizar la captura de la huella se diseñó un formulario dinámico que permita configurar la calidad de la huella capturada, y realiza la integración directa con el lector biométrico UAREU 4500. La figura 26 muestra el formulario de captura fotográfica y en la tabla 48 se especifican sus componentes.
79
Figura 26:Formulario de Captura de huellas dactilares
Fuente: Los autores
Tabla 48: Esquema del Formulario Captura de Huellas Dactilares.
Título: Esquema del Formulario Captura de Huellas Dactilares.
Huella Dactilar
Campos Tipo Control Observaciones
Fuente de Captura
Vista desplegable
Se debe seleccionar el driver del lector biométrico a utilizar.
FAR Vista Desplegable
Permite seleccionar el porcentaje permitido de error.
Comando Tipo Control Observaciones
Reconocimiento Rápido
Botón de opción
Permite definir que el algoritmo de reconociendo de huella dactilar sea más rápido.
Reconocimiento Completo
Botón de opción
Permite definir que el algoritmo de reconocimiento de huella dactilar sea más lento.
Threshold Indicador numérico seleccionable
Permite seleccionar el porcentaje permitido de error.
Image DPI Indicador numérico seleccionable
Permite definir la resolución de la imagen
Enrolamiento Indicador Permite definir la cantidad mínima de
80
“Contador Mínimo de Detalles”
numérico seleccionable
características para que una huella dactilar sea válida.
Buscar Duplicados
Botón de opción
Al seleccionar esta opción, el sistema buscara si hay un duplicado de esa huella dactilar.
Características de imagen binaria
Botón de opción
Permite definir si se muestran los puntos característicos de la huella en la imagen. Se puede seleccionar:
Mostrar detalles. Mostar puntos singulares. Mostrar bloques de orientación.
Galería de Efectos
Botón Permite aplicar brillo, iluminación, saturación y contraste a la huella capturada.
Ajustes Generales
Botón Define la cantidad de compresión de la imagen.
Ajustes E/S de Archivo
Botón Selecciona la carpeta por defecto desde donde se cargar y hacia donde se exportaran las imágenes.
Cargar Default de Usuario
Botón Carga las características del operador seleccionadas.
Crear Default de Fabrica
Botón Carga las características por defecto del programa.
Guardar Default de Usuario
Botón Guarda las características que el usuario cambio en su perfil.
Procesar Botón Inhabilitado.
Aceptar Botón Mediante esta acción acepta las acciones realizadas
Cancelar Botón Mediante este botón cancela las acciones realizadas.
Exportar Botón Inhabilitado
Enrolar Botón Inhabilitado
Tipo de Acción Cuando coloque
Añadir Botón Permite añadir la huella dactilar capturada.
Modificar Botón Inhabilitado
Borrar Botón Permite borrar la huella dactilar capturada.
Requisitos relacionados: RF-03
Fuente: Los autores
4.7.6. Formulario de Registro de Bicicletas.
La sección para el registro de bicicletas, permite visualizar los datos requeridos por el cliente y tiene la funcionalidad para agregar, buscar e imprimir stikers a las bicicletas.
81
La figura 27 muestra el formulario de captura fotográfica y en la tabla 49 se especifica sus componentes.
Figura 27: Formulario de Registro de Bicicletas
Fuente: Los autores
Tabla 49: Esquema del Formulario Registro de Bicicletas.
Título: Esquema del Formulario Registro de Bicicletas.
Pestaña de Bicicletas
Campos Tipo Control Observaciones
Numero Serial Texto En este campo se digita el numero serial de la bicicleta a registrar
Tipo de Bicicleta
Vista desplegable
En este se selecciona a qué tipo de bicicleta corresponde la que se está registrando.
Color Vista desplegable
Se debe seleccionar el color que más predomine en la bicicleta a registrar.
Marca Texto Se digita la marca de la bicicleta a registrar.
Modelo Texto Se digita el modelo al que corresponde la bicicleta.
Observaciones Texto Este campo permite anotar características específicas de la bicicleta que se está registrando.
Comando Tipo Control Observaciones
Buscar Botón Se usa para buscar una bicicleta ya registrada.
Modificar Botón Se usa para modificar la información de la bicicleta ya registrada.
Añadir Botón Permite añadir otra bicicleta al Bici-Usuario.
82
Borrar Botón Se utiliza cuando se desea borrar una bicicleta ya registrada.
Sticker Botón Se utiliza para generar el sticker a la bicicleta y al Bici –Usuario registrado
Registrar Entrada
Botón Permite la entrada o salida de la bicicleta al bici parqueadero.
Imprimir Botón Permite imprimir el sticker generado.
Requisitos relacionados: RF-03
Fuente: Los autores
83
5. DESARROLLO DEL SISTEMA DE INFORMACIÓN
El modelo de programación por capas para desarrollo de software, se basa en la separación de la lógica de acceso a datos, de la lógica de negocio, y de la lógica de presentación, obteniendo las siguientes ventajas:
Mayor encapsulamiento de las diferentes etapas.
Alta Escalabilidad, al permitir realizar modificaciones requeridas en determinada capa, sin necesidad de cambiar drásticamente las demás capas.
Reducción de la complejidad para el grupo de trabajo.
Figura 28:Diseñando Sistemas empleando el modelo de capas en desarrollo de software.
Fuente: Ernesto Alexander Calderon. Depto de ingeniería. Universidad del Salvador
A continuación se documenta el proceso que se realizó en cada una de las capas para llegar al sistema de información final.
Para el desarrollo del sistema de información se utilizó Visual Studio .Net 2010, con su lenguaje nativo C#. Se utilizó SQL SERVER 2008 Express como motor de bases de datos relacionales. Los reportes fueron creados en CrystalReports e integrados al sistema de información con su API.
El explorador de soluciones de Visual Studio .Net 2010, muestra que la solución SBC_CicloPark, se compone de 6 proyectos distribuidos como se muestra en la figura29
84
Figura 29:solución SBC_CicloPark
Fuente: Los autores
Tabla 50: Contenido explorador de soluciones Visual Studio .Net 2010.
CAPA PROYECTO OBSERVACIONES
Acceso a Datos
SBC_DB_OracleData No se utiliza, se crea para integrar la aplicación a futuro con el motor de bases de datos ORACLE.
Acceso a Datos
SBC_DB_SqlData Funcionalidades de bajo nivel requeridas para integrar la aplicación con el motor de bases de datos SQL Server Express 2008.
Acceso a Datos
SBCEntities Crea las entidades de las clases que serán enviadas a la capa lógica de negocio.
Acceso a Datos
SBCProviders
Se encarga de crear el proveedor de datos que compartirá información entre las funcionalidades de bajo nivel y las entidades.
Lógica de Negocio
SBCBussinessLayer
Capa lógica de negocio, se encarga de implementar los requisitos y restricciones para que el control de cicloparqueadero funcione adecuadamente.
Interface de Usuario
SBC_UI
Se encarga de crear los formularios que se utilizaran para presentación al usuario final. Se comunica con la capa de negocio para y la capa de acceso a datos para implementar las funcionalidades desde los comandos disñeados.
Fuente: Los autores
85
5.1. DESARROLLO DE LA CAPA DE ACCESO A DATOS.
La capa de acceso a datos, se encarga de crear las clases necesarias para agregar, modificar, borrar y buscar datos. Es la capa de más bajo nivel, por lo tanto interactúa directamente con el motor de bases de datos.
En el anexo x se presenta la capa de acceso a datos del objeto BiciUsuario.
5.2. DESARROLLO DE LA CAPA LOGICA DE NEGOCIO.
Desde la capa lógica de negocio, se llaman las funcionalidades desarrolladas en la capa de acceso a datos, llamando el namespace creado para ello. En el siguiente código se muestra la implementación de esta integración entre capas al llamar los namespacesAdvansys.Providers y Advansys.Entities, los cuales están especificados en anexos . Capa de acceso a datos.
using System; usingSystem.Collections.Generic; usingSystem.Linq; usingSystem.Text; usingAdvansys.Providers; usingAdvansys.Entities; namespaceAdvansys.BussinessLayer { publicclassUser { #region Properties privateint _IdUsuario; publicintIdUsuario { get { return _IdUsuario; } set { _IdUsuario = value; } } privatestring _FirstName; publicstringFirstName { get { return _FirstName; } set { _FirstName = value; } } privatestring _LastName; publicstringLastName { get { return _LastName; }
86
set { _LastName = value; } } #endregion publicstaticdouble Add(stringFirstName, stringLastName) { UserEntity usuario = newUserEntity(2, "ANDRES CAMILO", "PEREZ SANCHEZ", "123456789", "CEDULA DE CIUDADANIA", "BICIUSUARIO ESTRATO 3"); double result = Provider.User.AddUser(usuario); return result; } publicdouble Add() { return Add(this.FirstName, this.LastName); } } } 5.3. DESARROLLO CAPA LOGICA DE INTERFAZ DE USUARIO.
La capa de interface de usuario posee los formularios que se muestran en la figura 26.
Figura 30:Capa lógica interfaz de usuario
Fuente: Los autores
Tabla 51: Contenido capa de interface de Usuario.
87
FORMULARIO OBSERVACIONES
frmAbout Formulario que muestra los créditos de derechos de autor y licenciamiento de la aplicación.
frmCicloPark Formulario principal de la aplicación para control de cicloparqueaderos, tiene embebidos el formulario de biciusuarios y el formulario de bicicletas.
frmDataBase Formulario para funcionalidades de mantenimiento a las bases de datos, listas genéricas y tipos de biciusuarios.
frmLogin Formulario de inicio de sesión.
frmMain Formulario principal de la aplicación. Es un formulario MDI (MultipleDocument Interface.)
frmOperators Formulario para configuración de operadores.
frmReports Formulario para generación de reportes.
Fuente: Los autores
88
6. DISEÑO DE INTERFACE ELECTRÓNICA
Para realizar la interface electrónica entre el software y la aplicación física se utilizaran los dispositivos mostrados en la tabla 67, su funcionamiento se encuentra estructurado mediante el diagrama de flujo de la figura x y la secuencia de implementación se puede observar en la figura 31
Figura 31: Diagrama de descripción interfaz electrónica
NO
SI
INICIO
Recepción de datos del software
Procesamiento de datos en el micro
controlador (Placa Arduino)
Se enciende indicador de sitio de
parqueo
Estado del sensor para envío de
dato de plaza ocupada
¿Está activo el
sensor en el sitio
de parqueo?
Envío de dato al software de plaza
ocupada y encendido de indicador
de plaza ocupada
89
6.1 SELECCIÓN DE TECNOLOGIAS DE HARDWARE
Para dar solución al problema planteado en un inicio y poder obtener como resultado un buen sistema automático para ciclo-parqueaderos se necesitó un método para controlar el parqueo en los sitios asignados para las bicicletas. Se utilizaron sensores para detectar el estado del sitio de parqueo (vacío/ ocupado)y dispositivos de control.
Tabla 52: Tabla de descripción de la interface electrónica
TABLA DE DESCRIPCIÓN DE LA INTERFACE ELECTRÓNICA
Nombre de la Unidad
Descripción
Microcontrolador Atmega 328P
La familia de microcontroladores con arquitectura RISC fabricados por atmel es la elección para el control de los dispositivos utilizados en este proyecto, además de suplir todas los requerimientos previstos en la solución y optar con una mejor velocidad de respuesta que los microcontroladores PIC como lo podemos observar a continuación
Fuente:http://antares.itmorelia.edu.mx/~talfaro/Materias/prope/Curso%20Microcontroladores.pdf
CRITERIO DE SELECCIÓN MICROCONTROLADOR
ATMEGA PIC
VELOCIDAD DE PROCESADOR 90 80
TIEMPO DE EJECUCION DE CODIGO 90 85
CONFIABILIDAD 100 100
COMPATIBILIDAD CON PATAFORMA
DE HARDWARE ARDUINO 100 0
TOTAL 380 265
Fuente: Los autores
90
Arduino
Al realizar la elección del mirocontrolador y en vista del poco tiempo de ejecución del proyecto se optó por la implementación de la interface electrónica en la plataforma arduino la cual es compatible con el microcontrolador Atmega328 y cuenta con las siguientes características: Cuenta con 14 pines digitales de entrada / salida (de los cuales 6 pueden ser utilizados como salidas PWM), 6 entradas analógicas, un resonador cerámico 16 MHz, una conexión USB, un conector de alimentación, un header ICSP, y un botón de reinicio. Contiene todo lo necesario para apoyar el microcontrolador Atmega328.
CRITERIO DE SELECCIÓN PLATAFORMA DE HARDWARE
ARDUINO CASERA
TIEMPO DE DISEÑO 100 70
CONFIABILIDAD 90 80
COSTO 50 100
PRESENTACIÓN 100 80
TOTAL 340 330
Fuente: Los autores
Módulo Xbee
Para la comunicación entre el equipo de monitoreo y los espacios de parqueo después de observar diferentes métodos de comunicación con cableado, bluetooth y Xbee, se seleccionó esta última por ser una tecnología práctica, fácil de usar y amigable al entorno a implementar. Los módulos Xbee proveen 2 formas amigables de comunicación: Transmisión serial transparente (modo AT) y el modo API que provee muchas ventajas. Los módulos Xbee pueden ser configurados desde el PC utilizando el programa X-CTU o bien desde tu micro controlador. Los Xbee pueden comunicarse en arquitecturas punto a punto, punto a multi punto lo cual es ideal para este proyecto o en una red mesh. La elección del módulo XBee correcto pasa por escoger el tipo de antena (chip, alambre o conector SMA) y la potencia de transmisión (2mW para 300 pies o 60mW para hasta 1 milla), la escogida en este proyecto fue la XBee 1mW Wire Antenna la cual posee una Max date rate de 250Kbps, funciona a una frecuencia en banda de 2.4Ghz y tiene un rango de cobertura de 100m sin interferencias físicas y de 60m con interferencias físicas lo cual es ideal ya que el espacio de parqueo no supera los 30m2 .
91
CRITERIO DE
SELECCIÓN
MODULO DE COMUNICACIÓN
XBEE BLUETOOTH CABLEADO
COMUNICACIÓN
PARA ENTORNO
RUIDOSO 100 90 100
CONFIABILIDAD 90 80 85
COBERTURA DE
COMUNICACIÓN 90 75 100
COSTO 50 70 40
TIEMPO DE
IMPLEMENTACION 100 100 40
DURABILIDAD 95 90 100
TOTAL 525 505 465
Fuente: Los autores
Shield Xbee
Para tener una buena recepción de los datos suministrados por el equipo de monitoreo y los espacios de parqueo y tener una mejor estructura en la interface electronica para la solución la Xbee shield permite a una placa Arduino comunicarse de forma inalámbrica usando Zigbee. Está basada en el módulo Xbee de MaxStream. El módulo puede comunicarse hasta (100 metros) al aire libre (en visión directa). Puede ser usado como reemplazo del puerto serie/usb o puedes ponerlo en modo de comandos y configurarlo para una variedad de opciones de redes broadcast o malladas. La shield tiene pistas desde cada pin del Xbee hasta un orificio de soldar. También provee conectores hembra para usar los pines digitales desde 2 hasta 7 y las entradas analógicas, las cuales están cubiertas por la shield (los pines digitales de 8 a 13 no están cubiertos por la placa, así que puedes usar los conectores de la placa directamente).
92
CRITERIO DE SELECCIÓN PLACA DE EMISION DE DATOS
SHIELD XBEE CASERA
TIEMPO DE DISEÑO 100 70
CONFIABILIDAD 90 80
COSTO 50 100
PRESENTACIÓN 100 80
TOTAL 340 330
Fuente: Los autores
Sensor
Para la detección de la bicicleta al momento del parqueo por costo y manejo práctico se seleccionó el sensor capacitivo ya que por su ubicación en la parte posterior del marco de los rines es ideal ya que no todos los marcos de los rines son metálicos. El sensor permitirá tener una detección apropiada del estado de la bahía de parqueo con el fin que el sistema lo bloquee para que no puedan estacionar más bicicletas en este sitio hasta que el bici-usuario salga del mismo.
CRITERIO DE SELECCIÓN
SENSOR
SENSOR
CAPACITIVO
SENSOR
INDUCTIVO
LIMITACIONES DE
SENSADO 100 70
CONFIABILIDAD 90 90
COSTO 100 100
PRESICION 100 80
TOTAL 340 330
Fuente: Los autores
93
Baliza indicadora de parqueo
La baliza se compone de tres indicadores luminosos
- ROJO: Indica al bici-usuario que la bahía se encuentra ocupada
- AMARILLO: Indica al bici-usuario la bahía de parqueo en la cual debe parquear la bicicleta
- VERDE: Indica que la bahía de parqueo se encuentra desocupada.
El modulo electrónico en su totalidad el cual es el encargado de controlar los sitios de parqueo
Fuente: Los autores
En la figura 32 se observa el modo de funcionamiento de la interfaz electrónica la cual desde el software (Sistema de información) se controla todo el sistema de parqueo de las bicicletas el cual envía un dato inalámbricamente al lugar de parqueo mediante un módulo de comunicación xbee allí otro módulo xbee recibe este dato y por medio del micro controlador (placa arduino) enciende un indicador el cual le hace saber al bici- usuario el lugar de parqueo a su vez mediante un sensor óptico ubicado en el lugar de parqueo le da a conocer al bici-usuario que la bicicleta quedo parqueada correctamente ya que puede observar que el indicador de espacio ocupado se enciende y el de espacio libre se apaga, enviando inalámbricamente desde la placa arduino un dato al software dándole a conocer que el espacio de parqueo se encuentra ocupado.
94
Figura 32: Diagrama de secuencia electrónica
Fuente: Los autores
95
6.2 PROTOCOLO DE COMUNICACIÓN
6.2.1. RS232
Es la forma más comúnmente usada para realizar transmisiones de datos entre ordenador y un microcontrolador, fácil de manejar, estándar reconocido, económico, fácil de conseguir y desarrollar, y está presente en la mayoría de los ordenadores actuales.
6.2.2. SERIAL RX. TX. Este puerto serie USART utiliza los dos terminales TX/CK y RX/DT del Microcontrolador, las cuales se utilizan para conectar el Módulo Xbee
6.2.3. Comunicación Xbee
El protocolo de comunicación a implementar es elZigbee el cual esta basado en el estándar 802.15.4 de redes inalámbricas de área personal (wireless personal área network, WPAN). (Salgado Vidri, 2012)
Razón por la cual no será necesario realizar ningún tipo de cableado para la comunicación
A continuación se presentan las principales características de esta tecnología:
Opera en las bandas libres ISM (Industrial, Scientific& Medical) de 2.4 GHz, 868 MHz (Europa) y 915 MHz (Estados Unidos).
- Utiliza un protocolo asíncrono, halfduplex y estandarizado, permitiendo a productos de distintos fabricantes trabajar juntos.(Salgado Vidri, 2012)
- Velocidad de transmisión entre 25-250 kbps (debe emplearse en aplicaciones que no requieran alta transmisión de datos). (Salgado Vidri, 2012)
- Rango de cobertura de 10 a 150 metros.
- A pesar de coexistir en la misma frecuencia con otro tipo de redes como WiFi o Bluetooth su desempeño no se ve afectado, esto debido a su baja tasa de transmisión y, a características propias del estándar IEEE 802.15.4.
- Se puede decir que ZigBee ocupa el vacío que hay por debajo de Bluetooth, para comunicaciones de datos que no requieren altas velocidades.
- Capacidad de operar en redes de gran densidad, esta característica ayuda aumentar la confiabilidad de la comunicación, ya que entre más nodos existan dentro de una red, entonces, mayor número de rutas alternas existirán para garantizar que un paquete llegue a su destino.
96
- Cada red ZigBee tiene un identificador de red único, lo que permita que coexistan varias redes en un mismo canal de comunicación sin ningún problema. (Salgado Vidri, 2012)
Teóricamente pueden existir hasta 16 000 redes diferentes en un mismo canal y cada red puede estar constituida por hasta 65 000 nodos, obviamente estos límites se ven truncados por algunas restricciones físicas (memoria disponible, ancho de banda, etc.). (Salgado Vidri, 2012)
- Es un protocolo fiable, la red se organiza y se repara de forma automática y se rutean los paquetes de manera dinámica.
- Es un protocolo de comunicación multi-salto, es decir, que se puede establecer comunicación entre dos nodos aún cuando estos se encuentren fuera del rango de transmisión, siempre y cuando existan otros nodos intermedios que los interconecten, de esta manera, se incrementa el área de cobertura de la red.(Salgado Vidri, 2012)
- Su topología de malla (MESH) permite a la red auto recuperarse de problemas en la comunicación aumentando su confiabilidad.
- Se pueden formar redes que contengan desde dos dispositivos hasta cientos de ellos. (Salgado Vidri, 2012)
- Es un protocolo seguro ya que se puede implementar encriptación y autentificación. (Salgado Vidri, 2012)
Para la solución de este proyecto se trabajó con una red de Xbee Punto a Multi-punto como se puede observar en la figura 33
Figura 33: Red Xbee punto a multi-punto
Fuente: Los autores
97
6.3 DESARROLLO DEL HARDWARE
El diseño del hardware se organizó por dos módulos los cuales son: el módulo de envío de datos (Maestro) y el módulo de recepción de datos (Esclavo), estos módulos se interconectan por medio de estándares de comunicación como lo son RS-232 (entre el equipo de monitoreo y el modulo maestro ) IEEE 802.15.4 de redes inalámbricas de área personal (wireless personal areanetwork, WPAN) (entre módulo maestro y esclavo.
6.3.1. MÓDULO MAESTRO
En la figura 34 podemos observar de forma general el modulo maestro el cual se compone de una comunicación por RS – 232 con el equipo central en el cual se tiene el sistema de control de los ciclo-parqueaderos, la cual con una xbee la cual realiza la comunicación por medio del protocolo IEEE 802.15.4 a los n números de esclavos.
Figura 34: Esquema de funcionamiento módulo maestro
Fuente: Los autores
6.3.2. PLANO ELECTRÓNICO DEL MÓDULO MAESTRO
Figura 35: Plano electrónico módulo maestro
Fuente: http://soloelectronicos.com/category/domotica/page/2/
98
En la figura 35 podemos observar el plano del modulo maestro el cual esta conformado por una xbee conectada por puerto serie Tx Rx pin 2 y 3 respectivamente al ordenador central (Computador).
6.3.3. MÓDULO ESCLAVO
Este módulo al igual que el anterior cuenta con un modulo xbee el cual será el encargado de recepcionar toda la información proporcionada por el módulo maestro, esta xbee se comunica a la tarjeta arduino por medio del puerto serie USART el cual utiliza los dos terminales TX/CK y RX/DT del Microcontrolador Atmega 328 para dicho fin. Este módulo cuenta con un microcontrolador Atmega 328 el cual se encuentra inmerso en una placa arduino uno cuyas entradas son los sensores capacitivos de cada bahía de parqueo y sus salidas son los indicadores luminosos de vacío, ocupado y sitio de parqueo, como podemos observar en la figura 36.
Figura 36: Esquema de funcionamiento módulo esclavo
Fuente: Los autores
99
6.3.4. PLANO ELECTRÓNICO DEL MÓDULO ESCLAVO
Figura 37: Esquema de funcionamiento módulo esclavo
Fuente: Los autores
La figura 37 ilustra el esquema electrónico del módulo esclavo que se compone de la tarjeta xbee la cual recepciona la información transmitida por el módulo maestro y la envía por medio del puerto serie Tx Rx al microcontrolador para que este ejecute su programación.
100
6.3.5. PLANO DE POTENCIA Y ALIMENTACIÓN
Figura 38: Esquema de potencia
Fuente: Los autores
En la figura 38 se observa el esquema de potencia utilizado el cual básicamente es
una fuente la cual se compone de un trasformador de 110VAC a 24VAC, un puente
de diodos el cual rectifica la entrada y por ultimo se tiene dos reguladores de uno a
12VDC el otro a 9VDC los cuales energizaran los dispositivos del sistema.
6.3.6. PLANO ELÉCTRICO
Figura 40: Esquema eléctrico alto voltaje
101
Fuente: Los autores
En la figura 40 se da a conocer el diagrama eléctrico el cual está compuesto por toda la composición eléctrica de las instalaciones demarcando la ductería desde el cuarto eléctrico y el sistema de respaldo UPS hasta las bahías de parqueo de las bicicletas. El plano de la figura 40 se diseñó bajo la norma internacional de simbología IEEE. 6.4 SISTEMA DE COMUNICACIÓN
El sistema automático compuesto por el equipo de monitoreo, un módulo maestro y n-módulos esclavos, se conecta el equipo de monitoreo con el módulo maestro mediante el estándar RS-232, y el módulo maestro con los n-módulos esclavos en una red con el estándar IEEE 802.15.4, esta última con grandes ventajas ya que la distancia a comunicar es corta por las condiciones del sitio y al utilizar este tipo de tecnología inalámbrica se tiene un gran ahorro en tubería, cableado y obras civiles (regatas) lo cual conlleva más tiempo y más contaminación en el sitio, además del aumento en la mano de obra.
6.4.1. MÓDULO DE COMUNICACIÓN
Figura 41: Diagrama de funcionamiento módulo de comunicación
Fuente: Los autores
Para poder realizar la comunicación entre el software y la interfaz electrónica como
podemos apreciar en la figura 23 es necesario el uso del software X-CTU el cual se
encarga de la configuración de la comunicación de el modulo inalámbrico XBEE,
Xbee Emisor• Emisión de datos del software
Xbee Receptor• Recepción de datos para control de plazas disponibles
Shield Xbee• Proporciona los datos recibidos de la xbee hacia el microcontrolador
Proceso de información
• el microcontrolador recibe datos de los sensores
Xbee
• La Xbee envia un dato de indicandole al software si los sitios de parqueo se encuentran libres u ocupados.
102
desde este se configura cual va ser el modulo maestro y esclavo (cual envía y cual
recibe). Los cuales en este caso van a tener una comunicación bidireccional
Los módulos XBEE pueden ser programados a través del software X-CTU el cual
tiene el principio de funcionamiento del hyperterminal y una interfaz serial rs 232.
Existen dos tipos de interfaces, serial y USB que pueden ser utilizadas para
programarlos módulos XBee con el software llamado X-CTU; con este software se
puede definir de una forma rápida todos los parámetros que se quieren
modificar en los módulos.
En la figura 34 se puede observar la ventana delsoftware X-CTU, con el cual se
programan los módulos XBee
Figura 42: Ventana software X-CTU
Fuente: Los autores
103
Una vez se tenga abierto el software se procede a realizar la configuración del
módulo XBEE para ello se debe seguir los siguientes pasos:
- Conectar el módulo XBEE por el puerto USB para que el equipo de cómputo u
ordenador detecte el puerto
- Una vez que se haya detectado el puerto, en este caso el puerto USB, hay
que añadirlo en el programa a través de la sección "UserComPorts" y en la
parte que pone "Com Port Number". Como se observa en la figura 35se coloca
el nombre que se le ha dado al usb en la línea de código que se puso
anteriormente en el terminal, en el ejemplo anterior se uso "com1". Se Pude
ver en la figura x, señalado en rojo, donde se debe realizar los cambios.
Figura 43: Ventana X-CTUUserComPorts
104
Fuente: Los autores
- Después de poner en la casilla correspondiente a “Com Port Numbre” el
nombre del puerto, se pulsa el boton “Add” y saldrá algo parecido a la figura x.
- A continuación, después de añadir el nuevo dispositivo, se debe señalar en la
ventana "SelectCom Port" dicho dispositivo , y se selecciona el botón
"Test/Query". Aparecerá una ventana como la que aparece en la figura 36.
Figura 44: X-CTU Añadir nuevo dispositivo
Fuente: Los autores
A continuación seva explicar cómo se configura el nodo encargado de recepcionar la
información de los nodos sensores y enviar dicha información al servidor.
Existen dos formas de realizar la configuración de nuestros nodos:
1. Terminal
2. Modem Configuration
105
Si se utiliza la configuración a través de “Terminal” se debe escribir +++ antes de
escribir cualquier comando, tal y como se muestra en la figura 37. Los comandos que
se van a utilizar para la configuración de el nodo son:
ATRE: restaura los valores predeterminados de fábrica antes de realizar cualquier
modificación.
ATAP*: configuración de la API de XBee. Colocar el número que tiene la API de
XBee, en este caso 2, por lo que el comando sería ATAP2.
ATCE1: configuración del módulo XBee en modo Coordinador.
ATMY*: dirección del módulo XBee en modo Coordinador. El valor de * en este caso
será 1234. (ATMY1234)
ATID*: ID de la conexión que vamos a crear entre nuestros módulos XBee. El valor
de * en este caso es 1111. (ATID1111)
ATCH*: Canal por el cual los módulos XBee se van a conectar. El valor de * en este
caso será 0C. (ATCH0C)
ATWR: escribe una nueva configuración en la memoria no volátil. Si no se escribiese
este comando, las modificaciones realizadas solo duraría hasta que el módulo se
quede sin batería.
ATFR: reinicia el módulo XBee.
Figura 45: Configuración Xbee modo Terminal
106
Fuente: Los autores
Si se realiza la configuración a través de "Modem Configuration" se busca los
nombres, por ejemplo, si se quieres configurar el canal por el cual los módulos XBee
se van a conectar, tendría que buscar CH - Channel y poner el canal 1111 descrito
anteriormente. Para escribir en la memoria no volátil tendría que pulsar el botón
"Write". Como se puede observar en la la figura 38.
Figura 46: Configuración Xbee modo Terminal
Fuente: Los autores
107
7. INTEGRACIÓN SOFTWARE Y HARDWARE
Para la integración del software y del hardware expuestos en los capítulos 5 y 6 básicamente se realiza una comunicación inalámbrica con envió y recepción de datos bidireccionales mediante el módulo de comunicación Xbee, una vez el dato llega a la Xbee esta se comunica con el software y la placa arduino mediante el puerto de comunicación RS-232 como se observa en la figura 27
Figura 47:Comunicación para integrar software y hardware
Fuente: Los autores
Una vez el bici-usuario queda registrado en el sistema de información el operario de turno podrá visualizar que espacios de parqueo hay libres y envía un dato al espacio de parqueo que se le haya asignado al bici-usuario registrado, una vez el dato sea recibido por la placa arduino se activara un indicador luminoso de color amarillo en el cual le da a conocer al bici-usuario en que espacio debe aparcar su bicicleta.
Al momento en que el bici-usuario aparque su bicicleta en el lugar asignado el sensor óptico detectará que el espacio de parqueo se encuentra ocupado e inmediatamente apaga los indicadores luminosos de espacio libre y sitio de parqueo dando lugar a la activación del indicador luminoso rojo el cual da a conocer que el espacio de parqueo
108
se encuentra ocupado, además de encender el indicador de espacio ocupado envía un dato por medio del módulo Xbee hacia el sistema de información para que el sistema tenga presente que ese espacio de parqueo se encuentra ocupado y no se puedan enviar más bici-usuarios a este espacio de parqueo.
Para observar el funcionamiento del programa implementado en la placa arduino y el código fuente del sistema de información véase anexos
109
8. PRUEBAS DEL SISTEMA
En la figura 28 podemos observar la minuta de anotaciones la cual era la que utilizaban los operarios para registrar a los bici-usuarios los cuales quedaban inconformes por la poca seguridad en la información proporcionada durante el ingreso y la salida de estos.
Figura 48:Minuta de registro antiguo
Fuente: Los autores
Se realizaron pruebas al sistema durante dos meses, en los cuales se pudo comprobar las funcionalidades desarrolladas y poner a punto la aplicación.
Para la implementación fue necesario solicitar al cliente final, puntos de red eléctrica y moviliario para instalar los equipos, ya que estos recursos no se encontraban disponibles en el Ciclo-parqueadero de la estación Ricaurte, punto donde se implementó.
Figura 49:Operario de turno manejando el software
Fuente: Los autores
110
Inicialmente se realizó un acompañamiento de ocho horas diarias, durante ocho días hábiles a los operadores del sistema. Los operadores del sistema son en su totalidad vigilantes, quienes tenían pocos o nulos conocimientos en sistemas.
Entre los inconvenientes más significativos encontrados, se tuvieron:
Bajos conocimientos de algunos operadores para manipular sistemas en general.
Mala Utilización de los equipos por parte de operadores con conocimientos más adelantados en sistemas, ya que usaban los equipos para jugar, escuchar música, ver videos, y para ingresar a páginasweb con contenido para adultos y redes sociales.
El sistema se instaló a finales del mes de abril, en la gráfica se aprecia la aceptación
que se tuvo por parte de los bici-usuarios, quienes luego de una semana de estar
instalado el sistema, vieron las bondades que implica registrarse en el sistema, y
luego de estar registrando un promedio de 44 eventos diarios, el sistema se dispara
a un promedio diario de 557 registros en solo tres días.
Figura 50:Gráfico de ingreso vs salida de bicicletas
Fuente: Los autores
Tabla 53: Tabla de crecimiento de bici-usuarios
FECHA INGRESOS SALIDAS TOTAL EVENTOS
20/04/2013 2 1 3
22/04/2013 36 31 67
23/04/2013 32 32 64
27/04/2013 22 20 42
111
28/04/2013 90 72 162
29/04/2013 343 312 655
30/04/2013 449 407 856 974 875 1.849
Para el mes de Mayo, la tendencia hacia el uso del sistema continuo llegando ha
registrar 26.162 eventos de ingresos y salidas, para un promedio diario de 843
eventos solo un mes después de ser instalado el sistema.
Figura 51:Gráfico de tendencias ingreso vs salida de bicicletas
Fuente: Los autores
Tabla 52: Tabla de tendencias de ingreso bici-usuarios
FECHA INGRESOS SALIDAS TOTAL EVENTOS
01/05/2013 161 149 310
02/05/2013 504 504 1.008
03/05/2013 501 494 995
04/05/2013 340 318 658
05/05/2013 107 109 216
06/05/2013 536 541 1.077
07/05/2013 520 512 1.032
08/05/2013 561 570 1.131
09/05/2013 528 507 1.035
10/05/2013 515 502 1.017
11/05/2013 360 354 714
12/05/2013 83 92 175
13/05/2013 109 111 220
14/05/2013 563 604 1.167
15/05/2013 561 555 1.116
16/05/2013 569 566 1.135
17/05/2013 295 297 592
18/05/2013 400 368 768
19/05/2013 80 92 172
112
20/05/2013 569 586 1.155
21/05/2013 524 511 1.035
22/05/2013 432 461 893
23/05/2013 561 543 1.104
24/05/2013 498 489 987
25/05/2013 343 355 698
26/05/2013 86 89 175
27/05/2013 516 528 1.044
28/05/2013 563 596 1.159
29/05/2013 576 557 1.133
30/05/2013 602 595 1.197
31/05/2013 535 509 1.044
13.098 13.064 26.162
Fuente: Los autores
El pico más alto se registró en el mes de octubre, donde se registraron 31.061
eventos de ingresos y salidas, con un promedio diario de 1.001 registros. Estas cifras
demuestran que cada vez más biciusuarios están usando el servicio de Ciclo-
parqueaderos, gracias a la confianza que genera el servicio.
Figura 53:Gráfico de tendencias ingreso vs salida de bicicletas octubre 2013
Fuente: Los autores
Tabla 55: Tabla de tendencias de ingreso bici-usuarios octubre 2013
FECHA INGRESOS SALIDAS TOTAL EVENTOS
01/10/2013 692 603 1.295
02/10/2013 572 646 1.218
03/10/2013 649 632 1.281
04/10/2013 631 623 1.254
05/10/2013 422 416 838
113
06/10/2013 116 153 269
07/10/2013 580 586 1.166
08/10/2013 641 647 1.288
09/10/2013 711 700 1.411
10/10/2013 645 640 1.285
11/10/2013 591 552 1.143
12/10/2013 372 401 773
13/10/2013 107 120 227
14/10/2013 119 130 249
16/10/2013 432 368 800
17/10/2013 598 642 1.240
18/10/2013 671 621 1.292
19/10/2013 426 443 869
20/10/2013 118 142 260
21/10/2013 628 653 1.281
22/10/2013 682 652 1.334
23/10/2013 675 690 1.365
24/10/2013 661 669 1.330
25/10/2013 634 603 1.237
26/10/2013 437 426 863
27/10/2013 130 162 292
28/10/2013 632 644 1.276
29/10/2013 668 660 1.328
30/10/2013 675 674 1.349
31/10/2013 625 623 1.248
Totales 15.540 15.521 31.061
Fuente: Los autores
Para el mes de Noviembre, el sistema continúa presentando buenos registros, ya
que se registraron 29.452 eventos para un promedio diario de 982 registros, solo 19
registros diarios por debajo del mes anterior.
Figura 54:Gráfico de tendencias ingreso vs salida de bicicletas Noviembre 2013
Tabla 56: Tabla de tendencias de ingreso bici-usuarios noviembre 2013
114
FECHA INGRESOS SALIDAS TOTAL EVENTOS
01/11/2013 606 563 1.169
02/11/2013 432 441 873
03/11/2013 111 133 244
04/11/2013 99 109 208
05/11/2013 597 604 1.201
06/11/2013 618 618 1.236
07/11/2013 604 615 1.219
08/11/2013 636 626 1.262
09/11/2013 449 410 859
10/11/2013 119 139 258
11/11/2013 138 157 295
12/11/2013 630 648 1.278
13/11/2013 659 554 1.213
14/11/2013 618 703 1.321
15/11/2013 643 618 1.261
16/11/2013 440 427 867
17/11/2013 124 142 266
18/11/2013 613 631 1.244
19/11/2013 671 677 1.348
20/11/2013 693 671 1.364
21/11/2013 654 668 1.322
22/11/2013 637 613 1.250
23/11/2013 449 446 895
24/11/2013 138 158 296
25/11/2013 461 507 968
26/11/2013 663 616 1.279
27/11/2013 598 624 1.222
28/11/2013 626 618 1.244
29/11/2013 608 568 1.176
30/11/2013 410 404 814
14.744 14.708 29.452
Fuente: Los autores
En la tabla 57 se visualizan la cantidad de nuevas bicicletas registradas mensuales
en el sistema desde Abril hasta Noviembre de 2013.
Tabla 57: Tabla aumento de nuevos usuarios desde la implementación
MES DEL AÑO 2013
NUEVAS BICICLETAS
REGISTRADAS
ABRIL
640
MAYO
115
Fuente: Los autores
Figura 55:Gráfico de nuevas bicicletas registradas desde la implementación del sistema
Se puede apreciar en la gráfica que el pico más alto fue en Mayo cuando el sistema
tenía aproximadamente dos semanas de estar instalado. Los siguientes meses, la
cantidad de bicicletas nuevas registrada empieza a disminuir, sin embargo, aún se
vienen registrando en el mes de noviembre un promedio de 10 Bicicletas nuevas a
diario.
-
200
400
600
800
1.000
1.200
NUEVAS BICICLETAS REGISTRADAS
NUEVAS BICICLETASREGISTRADAS
1.101
JUNIO
477
JULIO
497
AGOSTO 509
SEPTIEMBRE
416
OCTUBRE
386
NOVIEMBRE
321
TOTAL 4.347
116
9. RESULTADOS
Luego de la estabilización del sistema, se logró obtener una buena aceptación por parte de los biciusuarios y operadores del sistema, ya que mejoró sustancialmente el servicio de cicloparqueaderos.
En el anexo x, se encuentran los reportes generados del sistema durante un intervalo de tiempo determinado.
El aumento del uso de los cicloparqueaderosfue de un 60% luego de implementar el sistema.
El registro de un biciusuario nuevo se demora alrededor de 60 segundos. El registro de un biciusuario ya registrado se demora 5 segundos, lo que disminuyo las filas generadas en las horas pico tanto para el ingreso como para la salida.
La satisfacción de los biciusarios que usan los biciparqueaderos es notoria ya que en las encuestas realizadas el 100% de los biciusuarios estaban satisfechos con la agilidad del sistema para registrar el ingreso y salida.
Luego de una prueba de dos meses en la Estación Ricaurte, el cliente final solicito implementar el sistema de información en otros sitios, entre ellos: Portal sur, Portal Américas, Portal Suba, Portal 20 de Julio, Portal Dorado, Estación General Santander, Estación Banderas.
Actualmente se encuentran registrados 2.000 Biciusuarios. Y 30.000 eventos de ingresos y salidas.
117
10. CONCLUSIONES
La implementación del sistema automático de control de ciclo-parqueaderos permitió mejorar el tiempo de ingreso y salida de los bici-usuarios lo cual fue satisfactorio para la calidad de vida de 3000 bici-usuarios, ya que gastaran menos tiempo en las filas que se realizan para ingresar o salir con su bicicleta, lo que incentiva el uso de la bicicleta.
La implementación de tecnología de punta en los ciclo-parqueaderos disminuyo la perdida de bicicletas por suplantación ó cambiazo. Los ciclo-parqueaderos de transmilenio son ahora seguros ya que durante el tiempo instalado, no han ocurrido robos.
El modelo de desarrollo por capas, permite desarrollar aplicaciones con más orden, facilitando el trabajo en equipo y la depuración puntual de las aplicaciones.
La primera versión del sistema de ciclo-parqueaderos se implementó exitosamente, lo que permite continuar explotando la idea para mejorarla tecnológicamente, atacando los problemas externos encontrados.
118
BIBLIOGRAFIA
Alarcon Fernandez, V. (2006). Desarrollo de sistemas de información: Una
metodología basada en el modelado. . Cataluya: UPC : Universidad
politécnica de Cataluya.
Alegsa. (2011). © 1998 - 2013 - ALEGSA - Santa Fe, Argentina. Recuperado el 16 de
09 de 2013, de © 1998 - 2013 - ALEGSA - Santa Fe, Argentina:
http://www.alegsa.com.ar/Dic/interfaz.php
Ambisoft. (2012). Copyright © 2005-2012 Scott W. Ambler. Recuperado el 16 de 09
de 2013, de AUP: http://www.ambysoft.com/unifiedprocess/agileUP.html
Arduino. (20 de 11 de 2013). Ogma9000. Obtenido de Arduino:
http://www.ogma9000.com/arduino.html
Bikennel. (2012). Bikennel corporation. Recuperado el 18 de 09 de 2013, de Bikennel
corporation: www.bikennel.com
bogotá, M. (2013). Secretaria Distrital de Movilidad. Recuperado el 13 de 09 de 2013,
de Secretaria Distrital de Movilidad: http://www.movilidadbogota.gov.co/?sec=8
Buehler, R. (2012). Determinants of bicycle commuting in the Washington, DC region:
The role of bicycle parking, cyclist showrs, and free car parking at work.
Science Direct.
Cucobike. (2012). Cucobike corporation. Recuperado el 11 de 09 de 2013, de
Cucobike corporation: http://ca.wikiloc.com/wikiloc/user.do?id=237495 Bici-
Parking
Cuellar, G. (2011). Copyright © Universidad del Cauca. Recuperado el 11 de 09 de
2013, de Copyright © Universidad del Cauca:
http://fccea.unicauca.edu.co/old/tiposdesi.html
Duran, C. (17 de 03 de 2009). Blogs corporation. Recuperado el 15 de 09 de 2013,
de Blogs corporation: http://instalacioneselectrotecnicas-
carlota.blogspot.com/2009/03/concepto-de-sistema-de-seguridad.html
Concepto de sistema de seguridad. (2009).
Homini, S. (2004). Plataforma biométrica Homini. Recuperado el 12 de 09 de 2013,
de Copyright © 2004 Homini S.A: http://www.homini.com/new_page_5.htm
hoy, I. (03 de 05 de 2013). Copyright © 2007-2012 www.informatica-hoy.com.ar.
Recuperado el 14 de 09 de 2013, de Copyright © 2007-2012 www.informatica-
119
hoy.com.ar: http://www.informatica-hoy.com.ar/aprender-informatica/Que-es-
Hardware-y-Software.php Concepto de hardware y software. (2012).
IDAE. (2010). CONBICI IDAE. Recuperado el 15 de 09 de 2013, de CONBICI IDAE:
http://www.laciudaddelasbicis.com/documentos/recursos/documentos/laBiciMo
vilidadSostenible.pdf
ingeniatic. (2011). ingeniatic® 2011. Recuperado el 12 de 09 de 2013, de ingeniatic®
2011: http://ingeniatic.euitt.upm.es/index.php/tecnologias/item/492-lector-de-
c%C3%B3digo-de-barras
Mastermagazine. (2012). Recuperado el 19 de 09 de 2013, de
www.mastermagazine.info/termino/5398.php
Movilidad, B. (2012). movilidadbogota. Recuperado el 2013, de movilidadbogota:
www.movilidadbogota.gov.co
Omana, N. (22 de 05 de 2011). blogs sistemas de información. Recuperado el 12 de
04 de 2013, de Tipos de sistemas de información según el nivel de
organización y función empresarial (2010).: http://nestor-omana-
sistemasinformacion.blogspot.com/2010/05/tipos-de-sistemas-segun-el-nivel-
de.html
Peter Rob C & Coronel, C. (2004). Sistemas de bases de datos: Diseño
im´plementacion y administracion. Mexico: Thomson Editores.
Raymond Mcleod, J. (2000). Sistemas de información gerencial. Mexico: Prentice
Hall Latinoamerica.
Rodier, J. &. (2011). Transit-based smart parking: An evaluation of the San Francisco
Bay area field test. Science Direct.
rodriguez, A. (2013). 2013 Slide Share. Recuperado el 16 de 09 de 2013, de 2013
Slide Share: http://www.slideshare.net/punk-andii/definicin-de-red-de-
comunicaciones Rodriguez, A. (2012). Definición de red de comunicaciones.
Salgado Vidri, I. (2012). ZigBee y sus aplicaciones. Recuperado el 2013, de Escuela
Técnica Superior de Ingeniería-ICAI. Universidad Pontificia Comillas. :
http://www.dea.icai.upco.es/sadot/Comunicaciones/avanzadas/Zigbee%20y%2
0sus%20aplicaciones.pdf
Santos, L. &. (2011). Sistema de información "Biotouch" Para control de tiempo y
asistencia basado en marcación biométrica de huella dactilar en Pymes.
Bogota: Universidad de la Salle.
120
Virtual, P. (2013). ® Nro. 1.847.110 Pergaminovirtual.com - © 1998-2013 .
Recuperado el 18 de 09 de 2013, de ® Nro. 1.847.110 Pergaminovirtual.com -
© 1998-2013 : http://www.pergaminovirtual.com.ar/definicion/Servidor.html
121
ANEXOS
ANEXO A. MODELO DE REQUISITOS NO FUNCIONALES.
REQUISITOS NO FUNCIONALES.
Los requisitos no funcionales, permiten delimitar el sistema de información a desarrollar:
A. Requisitos comunes de las interfaces: Tienen que ver con todas las interfaces hombre-máquina involucradas.
B. Rendimiento: Son los requisitos que se deben cumplir para que el sistema sea eficiente.
C. Seguridad: Presenta requisitos que se deben cumplir con respecto a la seguridad de la información.
D. Fiabilidad: Estos requisitos se definen para que el sistema funcione bien.
E. Disponibilidad: Define el tiempo en el cual deberá ser usado el sistema.
F. Mantenibilidad: Es el requisito que se solicita para que el sistema tenga la menor cantidad de fallas posibles.
G. Escalabilidad: Este requisito se solicita para que el sistema pueda ser implementado a futuro en otros cicloparqueaderos.
H. Otros requisitos: Este requisito hace referencia a las pruebas del sistema.
Interfaces de Software.
Requisitos: Motor de Bases de Datos.
Título: Implementar Motor de Bases de Datos
Código: RNF-02
Prioridad: Alta Estado: Implementado
Autor(es): Wilson Salinas, Jorge Amaya
Rol(es): NA
Descripción: El motor de bases de datos que usara la aplicación debe ser SQL Server 2005 Express.
Requisitos relacionados:
Fuente: Los autores
122
Requisitos: Reportes Generados.
Título: Exportar Reportes Generados
Código: RNF-02
Prioridad: Alta Estado: Implementado
Autor(es): Wilson Salinas, Jorge Amaya
Rol(es): NA
Descripción: El software debe permitir generar reportes que se puedan exportar a diferentes formatos de archivos, entre ellos Microsoft Word, Microsoft Excel, Adobe PDF, texto plano delimitado por comas.
Requisitos relacionados:
Fuente: Los autores
Interfaces de Comunicación.
Requisitos: Comunicación entre software y hardware.
Título: ImplementarComunicación entre software y hardware
Código: RNF-02
Prioridad: Alta Estado: Implementado
Autor(es): Wilson Salinas, Jorge Amaya
Rol(es): NA
Descripción: La comunicación entre el sistema de información y el hardware de control de los bici-parqueaderos, se realizara por medio de una interface inalámbrica Zigbee.
Requisitos relacionados:
Fuente: Los autores
Rendimiento.
Requisitos: Rapidez de Empadronamiento y Registro.
Título: Empadronar y Registrar.
Código: RF-03
Prioridad: Alta Estado: Implementado
Autor(es): Wilson Salinas, Jorge Amaya
Rol(es): NA
Descripción: El sistema de información debe ser ágil y de fácil manejo, para que un registro de un Bici-Usuario nuevo no supere 30 Segundos, y de un Bici-Usuario ya registrado no supere 10 Segundos.
Requisitos relacionados:
Fuente: Los autores
123
Requisitos: Crecimiento de Bases de Datos.
Título: Aumentar Bases de Datos.
Código: RF-03
Prioridad: Alta Estado: Implementado
Autor(es): Wilson Salinas, Jorge Amaya
Rol(es): NA
Descripción: El sistema de información debe almacenar los datos de los Bici-Usuarios, incluyendo las imágenes de la foto y huella dactilar, en un espacio reducido para aumentar la capacidad de almacenamiento de la información.
Requisitos relacionados:
Fuente: Los autores
Seguridad.
Requisitos: Seguridad de Bases de Datos.
Título: Implementar Seguridad de Bases de Datos.
Código: RF-03
Prioridad: Alta Estado: Implementado
Autor(es): Wilson Salinas, Jorge Amaya
Rol(es): NA
Descripción: La basen de datos del sistema de información deberá tener un usuario y contraseña, distintos a los usados para el ingreso al software.
Requisitos relacionados:
Fuente: Los autores
Requisitos: Seguridad del Sistema Operativo.
Título: Implementar Seguridad del Sistema Operativo.
Código: RF-03
Prioridad: Alta Estado: Implementado
Autor(es): Wilson Salinas, Jorge Amaya
Rol(es): NA
Descripción: Es de suma importancia, que los operadores del sistema sean restringidos para modificar los archivos del disco duro, acceder a internet y conectar algún dispositivo USB que pueda contagiar el sistema con virus informáticos.
Requisitos relacionados:
Fuente: Los autores
124
Fiabilidad.
Requisitos: Fiabilidad en la Información Recolectada.
Título: Implementar Fiabilidad en la Información Recolectada.
Código: RF-03
Prioridad: Alta Estado: Implementado
Autor(es): Wilson Salinas, Jorge Amaya
Rol(es): NA
Descripción: Se requiere que los datos recolectados por los operadores sean fiables, para que el cliente obtenga datos reales de los Bici-Usuarios que frecuentan el parqueadero.
Requisitos relacionados:
Fuente: Los autores
Disponibilidad.
Requisitos: Disponibilidad del sistema.
Título: Disponer del sistema.
Código: RF-03
Prioridad: Alta Estado: Implementado
Autor(es): Wilson Salinas, Jorge Amaya
Rol(es): NA
Descripción: Se requiere que el sistema sea operativo todos los días desde las 4:00am hasta las 11:00 pm, tiempo que dura el sistema de transporte transmilenio en operación.
Requisitos relacionados:
Fuente: Los autores
Mantenibilidad.
Requisitos: Mantenimiento del sistema.
Título: Mantener el sistema.
Código: RF-03
Prioridad: Alta Estado: Implementado
Autor(es): Wilson Salinas, Jorge Amaya
Rol(es): NA
Descripción: Se realizaran visitas periódicas para realizar mantenimiento preventivo de los equipos, con el fin de realizar limpieza de las partes electrónicas, backup de las bases de datos y generación de reportes para ser entregados al cliente final.
125
Requisitos relacionados:
Fuente: Los autores
Escalabilidad.
Requisitos: Escalabilidad del sistema.
Título: Desarrollar la escalabilidad del sistema.
Código: RF-03
Prioridad: Alta Estado: Implementado
Autor(es): Wilson Salinas, Jorge Amaya
Rol(es): NA
Descripción: El sistema de información debe estar diseñado de tal forma que permita su escalabilidad para ser usado en otros bici-parqueaderos.
Requisitos relacionados:
Fuente: Los autores
OTROS REQUISITOS.
Requisitos: Prototipo Inicial.
Título: Implementar prototipo Inicial.
Código: RF-03
Prioridad: Alta Estado: Implementado
Autor(es): Wilson Salinas, Jorge Amaya
Rol(es): NA
Descripción: El prototipo inicial del sistema será implementado en el bici-parqueadero de la estación Ricaurte del sistema de transporte masivo transmilenio.
Requisitos relacionados:
Fuente: Los autores
Requisitos Comunes De Las Interfaces.
Los requisitos de las interfaces, se dividen en las siguientes secciones:
A. Interfaces de Usuario: Requisitos específicos que debe cumplir la interface de usuario, y que manipularan los usuarios finales.
B. Interfaces de Hardware: Se presentan los requisitos que debe cumplir el hardware a implementar.
C. Interfaces de Software: Estos requisitos hacen referencia a la integración que se debe realizar con software de terceros.
D. Interfaces de Comunicación: Indica los requisitos con respecto a la comunicación entre hardware y software.
126
Interfaces de Usuario.
Requisitos: Aplicación Para Windows 7.
Título: Desarrollar Aplicación Para Windows 7
Código: RNF-01
Prioridad: Alta Estado: Implementado
Autor(es): Wilson Salinas, Jorge Amaya
Rol(es): NA
Descripción: El sistema debe contar con una aplicación totalmente compatible con Windows 7. La aplicación debe tener instalador, manual de usuario, manual de administración y manual de instalador.
Requisitos relacionados:
Fuente: Los autores
Requisitos: Barra de Herramientas.
Título: Implementar Barra de Herramientas
Código: RNF-02
Prioridad: Alta Estado: Implementado
Autor(es): Wilson Salinas, Jorge Amaya
Rol(es): NA
Descripción: En la parte superior, se mostrará una barra de herramientas con iconos gráficos e intuitivos, que permitan acceder a cada formulario de manera fácil.
Requisitos relacionados:
Fuente: Los autores
Requisitos: Formularios.
Título: ImplementarFormularios
Código: RNF-02
Prioridad: Alta Estado: Implementado
Autor(es): Wilson Salinas, Jorge Amaya
Rol(es): NA
Descripción: El sistema debe mantener una misma apariencia física en cada una de sus pantallas y formularios, para que de manera intuitiva sea fácil de manipular por los operadores, los cuales tienen conocimientos básicos o nulos en sistemas.
Requisitos relacionados:
Fuente: Los autores
127
Interfaces de Hardware.
Requisitos: Equipo de Cómputo.
Título: Implementar Equipo de Computo
Código: RNF-02
Prioridad: Alta Estado: Implementado
Autor(es): Wilson Salinas, Jorge Amaya
Rol(es): NA
Descripción: El sistema debe ser totalmente funcional en un equipo todo en uno Compaq 18-2001LA. Procesador Intel Atom D2550, 2 Gigas de Memoria RAM DDR3, Disco Duro 500GB.
Requisitos relacionados:
Fuente: Los autores
Requisitos: Lector de huella dactilar.
Título: ImplementarLector de huella dactilar
Código: RNF-02
Prioridad: Alta Estado: Implementado
Autor(es): Wilson Salinas, Jorge Amaya
Rol(es): NA
Descripción: El sistema debe usar el lector de huella dactilar de escritorio UAREU 4500, el cual se comunica por USB.
Requisitos relacionados:
Fuente: Los autores
Requisitos: Cámara Web.
Título: ImplementarCámara Web
Código: RNF-02
Prioridad: Alta Estado: Implementado
Autor(es): Wilson Salinas, Jorge Amaya
Rol(es): NA
Descripción: El sistema debe ser compatible con la cámara web Microsoft HD 3000
Requisitos relacionados:
Fuente: Los autores
128
Requisitos: Impresora.
Título: ImplementarImpresora
Código: RNF-02
Prioridad: Alta Estado: Implementado
Autor(es): Wilson Salinas, Jorge Amaya
Rol(es): NA
Descripción: El sistema debe ser compatible con la impresora TSC-244 Plus
Requisitos relacionados:
Fuente: Los autores
Requisitos: Lector de códigos de barras 2D.
Título: ImplementarLector de códigos de barras 2D
Código: RNF-02
Prioridad: Alta Estado: Implementado
Autor(es): Wilson Salinas, Jorge Amaya
Rol(es): NA
Descripción: El sistema debe ser compatible con el lector de códigos de barras HoneyWell 1900.
Requisitos relacionados:
Fuente: Los autores
129
ANEXO B. CAPA DE ACCESO A DATOS PARA BICI-USUARIOS
El modelo de acceso a datos posee las entidades, las funcionalidades de bajo nivel para conectarse con el motor de bases de datos y el proveedor de bases de datos para integrar la funcionalidad de bajo nivel con las entidades.
130
ClaseUserDAO
using System; usingSystem.Collections.Generic; usingSystem.Linq; usingSystem.Text; usingSystem.Data.SqlClient; usingAdvansys.Entities; namespaceAdvansys.Sql.DAO { publicclassUserDAO : Advansys.Providers.UserProvider { privateSqlConnection connection; publicSqlConnection Connection { get { if (connection == null) { connection = newSqlConnection(GlobalConnectionString); if (connection == null) { thrownewException("Data Base Connection Failed"); } } return connection; }
131
} publicoverridedoubleAddUser(Advansys.Entities.UserEntity user) { SqlCommand command = newSqlCommand("SBConsole_UserAdd",connection); command.CommandType = System.Data.CommandType.StoredProcedure; command.Parameters.AddWithValue("@IdUser",user.IdUser); //command.Parameters["@IdUser"].Direction = System.Data.ParameterDirection.Output; if (user.FirstName == null) command.Parameters.AddWithValue("@FirstName", System.DBNull.Value); else command.Parameters.AddWithValue("@FirstName", user.FirstName); intresultado = 0; try { if (connection.State == System.Data.ConnectionState.Closed) connection.Open(); resultado = ExecuteNonQuery(command); } catch (Exception ex) { thrownewException("Error Adding User",ex); } finally { if (connection.State == System.Data.ConnectionState.Open) connection.Close(); } if (resultado> 0) return (double)command.Parameters["@IdUser"].Value; else return 0; } publicoverrideintDeleteUser(Advansys.Entities.UserEntity user) { SqlCommand command = newSqlCommand("SBConsole_UserDelete", connection); command.CommandType = System.Data.CommandType.StoredProcedure; command.Parameters.AddWithValue("@IdUser", user.IdUser); intresultado = 0; try { if (connection.State == System.Data.ConnectionState.Closed) connection.Open();
132
resultado = ExecuteNonQuery(command); } catch (Exception ex) { thrownewException("Error Deleting User", ex); } finally { if (connection.State == System.Data.ConnectionState.Open) connection.Close(); } returnresultado; } publicoverrideintEditUser(Advansys.Entities.UserEntity user) { SqlCommand command = newSqlCommand("SBConsole_UserUpdate", connection); command.CommandType = System.Data.CommandType.StoredProcedure; command.Parameters.AddWithValue("@IdUser", user.IdUser); //command.Parameters["@IdUser"].Direction = System.Data.ParameterDirection.Output; if (user.FirstName == null) command.Parameters.AddWithValue("@FirstName", System.DBNull.Value); else command.Parameters.AddWithValue("@FirstName", user.FirstName); intresultado = 0; try { if (connection.State == System.Data.ConnectionState.Closed) connection.Open(); resultado = ExecuteNonQuery(command); } catch (Exception ex) { thrownewException("Error Editing User", ex); } finally { if (connection.State == System.Data.ConnectionState.Open) connection.Close(); } returnresultado; } publicoverrideList<Advansys.Entities.UserEntity>GetUsers() {
133
SqlCommand command = newSqlCommand("SBConsole_UserGetAll", connection); command.CommandType = System.Data.CommandType.StoredProcedure; System.Data.IDataReaderrd = null; List<UserEntity> users = newList<UserEntity>(); try { if (connection.State == System.Data.ConnectionState.Closed) connection.Open(); rd = ExecuteReader(command); while (rd.Read()) { UserEntity entity = GetUserFromReader(rd); users.Add(entity); } } catch (Exception ex) { thrownewException("Error Listing Users", ex); } finally { if (connection.State == System.Data.ConnectionState.Open) connection.Close(); } return users; } publicoverrideAdvansys.Entities.UserEntityGetUserById(doubleIdUser) { SqlCommand command = newSqlCommand("SBConsole_UserGetOne", connection); command.CommandType = System.Data.CommandType.StoredProcedure; command.Parameters.AddWithValue("@IdUser", IdUser); //command.Parameters["@IdUser"].Direction = System.Data.ParameterDirection.Output; System.Data.IDataReaderrd = null; UserEntity entity = null; try { if (connection.State == System.Data.ConnectionState.Closed) connection.Open(); rd = ExecuteReader(command); if (rd.Read()) entity = GetUserFromReader(rd); } catch (Exception ex)
134
{ thrownewException("Error Adding User", ex); } finally { if (connection.State == System.Data.ConnectionState.Open) connection.Close(); } return entity; } } }
ClaseUserEntity
using System; usingSystem.Collections.Generic; usingSystem.Linq; usingSystem.Text; namespaceAdvansys.Entities { publicclassUserEntity { privatedouble _IdUser; publicdoubleIdUser { get { return _IdUser; } set { _IdUser = value; } } privatestring _FirstName; publicstringFirstName { get { return _FirstName; } set { _FirstName = value; } } privatestring _LastName; publicstringLastName { get { return _LastName; }
135
set { _LastName = value; } } privatestring _nDocument; publicstringNDocument { get { return _nDocument; } set { _nDocument = value; } } privatestring _TypeDocument; publicstringTypeDocument { get { return _TypeDocument; } set { _TypeDocument = value; } } privatestring _TypeUser; publicstringTypeUser { get { return _TypeUser; } set { _TypeUser = value; } } privatestring _Address1; publicstring Address1 { get { return _Address1; } set { _Address1 = value; } } privatestring _Address2; publicstring Address2 { get { return _Address2; } set { _Address2 = value; } } privatestring _City; publicstring City { get { return _City; } set { _City = value; } } privatestring _Departament; publicstringDepartament
136
{ get { return _Departament; } set { _Departament = value; } } privatestring _Title; publicstring Title { get { return _Title; } set { _Title = value; } } publicUserEntity() { } publicUserEntity(doubleIdUser, stringFirstName, stringLastName, stringnDocument, stringTypeDocument, stringTypeUser) { this._IdUser = IdUser; this._FirstName = FirstName; this._LastName = LastName; this._nDocument = nDocument; this._TypeDocument = TypeDocument; this._TypeUser = TypeUser; } } } ANEXO C. PROGRAMACIÓN ARDUINO
constintbuttonPinSensor = 2;
constintledPinLibre = 13;
constintledPinOcupado = 12;
137
constintledPinParqueo = 11;
intincomingByte;
intbuttonState = 0;
void setup() {
pinMode(ledPinLibre, OUTPUT);
pinMode(ledPinOcupado, OUTPUT);
pinMode(ledPinParqueo, OUTPUT);
pinMode(buttonPinSensor, INPUT);
Serial.begin(9600);
}
void loop(){
buttonState = digitalRead(buttonPinSensor);
if (buttonState == HIGH) {
digitalWrite(ledPinOcupado, HIGH);
digitalWrite(ledPinLibre, LOW);
digitalWrite(ledPinParqueo, LOW);
Serial.print("o");
delay(100);
}
else {
138
digitalWrite(ledPinLibre, HIGH);
digitalWrite(ledPinOcupado, LOW);
if (Serial.available() > 0) {
incomingByte = Serial.read();
if (incomingByte == 'a') {
digitalWrite(ledPinParqueo, HIGH);
}
else{
digitalWrite(ledPinParqueo, LOW);
}
}
}
}
ANEXOD. MANUAL DE USUARIO
INICIO DE SESION.
Ingresar al icono señalado (SBConsole - Acceso directo)
139
Luego digitar el usuario y la contraseña en este caso es : Nombre de Usuario: Ricaurte y Contraseña: Estacionricaurte2013. Finalmente dar click en OK
REGISTRO DE UN NUEVO BICIUSUARIO
Para ingresar a Biciusuarios dar click en el icono de la bicicleta
140
Para registrar un usuario nuevo o bicicleta al cicloparqueadero debe solicitarle la cedula y tarjeta de propiedad de la bicicleta al usuario; debe apuntar la lectora laser en dirección al código de barras de la cedula de ciudadanía automáticamente el software SBConsolereconocerá los datos básicos del usuario (Ejemplo).
Después de esto debe completar los campos que dicen ocupación y Tipo de Bici-Usuario/Estrato dando click para desplegar las opciones y seleccionar la que corresponda:
141
Después de esto se toma la foto del usuario y la huella dactilar pasando el cursor al lado izquierdo parte superior y dando click en el área señalada.
142
Al darle click se va a abrir la siguiente ventana debe pedirle al usuario que se ubique frente a la cámara de manera que pueda tomarle la foto dándole click en el botón Congelar y al final click en Aceptar
Para tomar la huella dactilar se realiza el mismo procedimiento dando click sobre la foto del usuario
143
Se selecciona la pestaña Huella Dactilar y luego Añadir; en este paso se le pide al usuario poner el dedo índice sobre el lector biométrico aproximadamente por 4 segundos ,
Después de esto damos click en OK y Aceptar
144
Luego de esto damos click en la pestaña Datos Adicionales
145
Aquí digitamos los datos correspondientes Dirección, Barrio, etc..., al terminar de llenar estos datos damos click en el botón Añadir, con esto terminamos de llenar los datos del usuario .
REGISTRO DE NUEVA BICICLETA
146
Ahora empezamos a llenar los datos de la bicicleta dándole click en el botón Añadir
Aquí ponemos el serial que este en la tarjeta de propiedad en caso de que tenga 3 dígitos o menos se debe completar con las iniciales de la marca ejemplo (SA512), también digitar los datos que correspondan al tipo de bicicleta asi como el color y demás características, Al terminar le damos Click en OK
147
y finalmente Click en Estiker para imprimir el código que el usuario debe pegar en su bicicleta para registrarle la entrada y salida del Cicloparqueadero
Para terminar este paso no olvide darle Click en Registrar Entrada asi podrá guardar la entrada y salida de las bicicletas de cada usuario nuevo.
Con esto terminamos de registrar a un usuario nuevo, junto con su bicicleta. Para volver a la ventana principal cerramos al ventana desde la x en la parte superior derecha
148
Y nuevamente click en el icono de la bicicleta para registrar la entrada o salida de alguna bicicleta del Ciclo parqueadero o para registrar un usuario nuevo
REGISTRO DE INGRESO Y SALIDAS DE BICICLETAS
Una vez ingresado el bici usuario con su bicicleta, cada vez que se lea el código de barras de su cedula de ciudadanía o el stiker de la bicicleta, se cargaran sus datos.
149
Mostrando en la pantalla de monitoreo el estado del visitante y el estado de la bicicleta, en la figura, vemos que el visitante y la bicicleta están afuera. Para registrar el ingreso, solo se debe oprimir dos veces enter. Igualmente, para registrar la salida, luego de buscar los datos del biciusuario, se debe oprimir doble enter.