PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO...
Transcript of PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO...
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES
Javier Ricardo Alfonso Alba
Alvaro Iván Ronderos Acevedo
Jurado:
M.I. Luis Felipe Wanumen Silva
UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS
FACULTAD TECNOLÓGICA
INGENIERÍA TELEMÁTICA
Bogotá 2016
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 2
Contenido
Introducción ........................................................................................................................................ 7
1. FASE INICIAL ................................................................................................................................ 9
1.1. Titulo ................................................................................................................................... 9
1.2. Tema .................................................................................................................................... 9
1.3. Descripción del Problema ................................................................................................... 9
1.4. Formulación del Problema ................................................................................................ 10
1.5. Objetivo General ............................................................................................................... 10
1.6. Objetivos Específicos ........................................................................................................ 10
1.7. Justificación ....................................................................................................................... 10
1.8. Alcances y Delimitaciones ................................................................................................. 12
1.8.1. Delimitación Temática .............................................................................................. 12
1.8.2. Delimitación Geográfica ............................................................................................ 13
1.8.3. Delimitación Temporal .............................................................................................. 13
1.8.4. Alcances..................................................................................................................... 13
1.9. Marco Teórico ................................................................................................................... 14
1.9.1. Desarrollo de aplicaciones MVC ................................................................................ 14
1.9.2. Arquitectura de un sistema bajo el patrón MVC ...................................................... 16
1.9.3. Ventajas de la arquitectura MVC .............................................................................. 19
1.9.4. Desventajas de la arquitectura MVC ................................................................ 19
1.9.5. JAVA ......................................................................................................................... 20
1.9.6. Netbeans IDE . ........................................................................................................ 21
1.9.7. MongoDB. ................................................................................................................. 21
1.10. Marco Conceptual ......................................................................................................... 23
1.10.1. Sensor .................................................................................................................... 23
1.10.2. Telemetría ................................................................................................................. 23
1.10.3. Raspberry Pi .............................................................................................................. 23
1.10.4. Gestor de Bases de Datos ..................................................................................... 24
1.10.5. Aplicación .................................................................................................................. 24
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 3
1.10.6. TCP/IP ....................................................................................................................... 24
1.10.7. Equipo Servidor ....................................................................................................... 25
1.10.8. Equipo Cliente ......................................................................................................... 25
1.10.9. Sistema Distribuido ................................................................................................ 25
1.10.10. Lightweight Directory Access Protocol ................................................................. 25
1.11. Estado del Arte .............................................................................................................. 26
1.12. Marco Metodológico ..................................................................................................... 29
1.13. Factibilidad .................................................................................................................... 30
1.13.1. Factibilidad Técnica ................................................................................................... 30
1.13.2. Factibilidad Operativa ............................................................................................... 31
1.13.3. Factibilidad Legal ....................................................................................................... 31
1.13.4. Factibilidad Económica.............................................................................................. 32
1.14. Riesgos del Proyecto ..................................................................................................... 33
1.14.1. Estrategias del riesgo pre activo. .............................................................................. 33
1.14.2. Consecuencias del riesgo .......................................................................................... 34
1.14.3. Probabilidad e impacto de riesgo ............................................................................. 35
2. FASE DE DEFINCIÓN .................................................................................................................. 37
2.1. Requerimientos ................................................................................................................. 37
2.1.1. Requerimientos Funcionales ..................................................................................... 37
2.1.2. Requerimientos No funcionales ................................................................................ 37
2.2. Historias de Usuario. ......................................................................................................... 38
2.2.1. Definiciones ............................................................................................................... 38
Directorio LDAP ......................................................................................................................... 38
2.2.2. IDH-1 Fallas en la conexión de red ............................................................................ 38
2.2.3. IDH-2 Almacenamiento de Eventos .......................................................................... 41
2.2.4. IDH-3 Reglas de Acceso ............................................................................................. 43
2.2.5. IDH-4 Interfaz Gráfica De Administración ................................................................. 44
2.3. Cronograma....................................................................................................................... 46
3. FASE DE DESARROLLO ............................................................................................................... 49
3.1. Diagramas de Flujo Funcional ........................................................................................... 49
3.1.1. Solicitud de Acceso .................................................................................................... 49
3.1.2. Generar Evento ......................................................................................................... 50
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 4
3.1.3. Modificar Regla de Acceso ........................................................................................ 50
3.1.4. Agregar Una Unidad Al Sistema ................................................................................ 51
3.2. BackLog de Actividades ..................................................................................................... 52
3.3. Sprints ............................................................................................................................... 52
3.3.1. Sprint 1 Desarrollo del Core del sistema ................................................................... 53
3.3.2. Sprint 2 Desarrollo de los Eventos de acceso al sistema .......................................... 54
3.3.3. Sprint 3 Administración del Sistema ......................................................................... 55
3.4. Resumen de Esfuerzos ...................................................................................................... 57
3.4.1. Esfuerzo primera versión estable .............................................................................. 58
3.4.2. Esfuerzo total del proyecto ....................................................................................... 58
3.5. Diagramas de Clases .......................................................................................................... 59
3.5.1. Capa de Persistencia ................................................................................................. 59
3.5.2. Capa de Servicios ....................................................................................................... 60
3.5.3. Capa de Control ......................................................................................................... 62
3.6. Diseño de Interfaces ......................................................................................................... 63
3.7. Diccionario de Datos ......................................................................................................... 66
4. FASE DE IMPLEMENTACIÓN ...................................................................................................... 69
4.1. Diagrama de Paquetes ...................................................................................................... 69
4.2. Diagramas de Despliegue .................................................................................................. 70
4.3. Esquema Telemático del sistema ...................................................................................... 71
5. FASE DE CIERRE ......................................................................................................................... 73
5.1. Pruebas del Sistema .......................................................................................................... 73
5.1 Pruebas Sprint 1 ............................................................................................................ 73
5.1.1 Pruebas Sprint 2 ........................................................................................................ 75
5.1.2 Pruebas Sprint 3 ........................................................................................................ 78
5.2. Cierre del proyecto............................................................................................................ 82
5.3. Mejoras propuestas .......................................................................................................... 84
Conclusiones ..................................................................................................................................... 85
Recomendaciones ............................................................................................................................. 87
Bibliografía ........................................................................................................................................ 88
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 5
Índice de Ilustraciones
Ilustración 1 Arquitectura MVC......................................................................................................... 15
Ilustración 2 Arquitectura de un Sistema Bajo el patrón MVC. ........................................................ 17
Ilustración 3 MVC del lado del servidor (Desacoplado) .................................................................... 18
Ilustración 4 Montaje de un sistema de control de acceso .............................................................. 28
Ilustración 5 Ciclo de vida de un proyecto con Scrum. ..................................................................... 29
Ilustración 6 Cronograma de actividades. ......................................................................................... 48
Ilustración 7 Flujo Funcional Solicitud de Acceso. ............................................................................ 49
Ilustración 8 Flujo funcional Generar Evento. ................................................................................... 50
Ilustración 9 Flujo funcional Modificar Regla de Acceso. ................................................................. 50
Ilustración 10 Flujo funcional Agregar Una Unidad Al Sistema......................................................... 51
Ilustración 11 Grafica de esfuerzo vs días del Sprint 1. .................................................................... 54
Ilustración 12 Grafica de esfuerzo vs días del Sprint 2. .................................................................... 55
Ilustración 13 Grafica de esfuerzo vs días del Sprint 3. .................................................................... 56
Ilustración 14 Esfuerzo en horas antes de la versión estable. .......................................................... 58
Ilustración 15 Esfuerzo total del proyecto. ....................................................................................... 59
Ilustración 16 Diagrama de clases de la capa de persistencia. ......................................................... 60
Ilustración 17 Diagrama de clases Capa de Servicios - parte 1. ....................................................... 61
Ilustración 18 Diagrama de clases Capa de Servicios - parte 2. ....................................................... 61
Ilustración 19 Diagrama de clases Capa de Control. ......................................................................... 62
Ilustración 20 Diagrama de clases utilitarias. .................................................................................... 63
Ilustración 21 Interfaz de Administración de unidades. ................................................................... 64
Ilustración 22 Interfaz de administración para las reglas de acceso. ............................................... 64
Ilustración 23 Interfaz de consulta de eventos. ................................................................................ 65
Ilustración 24 Interfaz de administración de las zonas. .................................................................... 65
Ilustración 25 Diagrama de paquetes core del sistema. ................................................................... 69
Ilustración 26 Diagrama de paquetes punto de inicio del sistema. ................................................. 70
Ilustración 27 Diagrama de despliegue, componentes de software. ............................................... 70
Ilustración 28 Diagrama Telemático del sistema. ............................................................................. 71
Ilustración 29 Esfuerzo Total Vs Esfuerzo en la resolución de los errores ........................................ 83
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 6
Índice de Tablas
Tabla 1 Riesgos pre activos ............................................................................................................... 33
Tabla 2 Consecuencias del riesgo ..................................................................................................... 34
Tabla 3 Probabilidad e impacto de riesgo ......................................................................................... 35
Tabla 4 BackLog general del proyecto. ............................................................................................. 52
Tabla 5 Esfuerzos Sprint 1. ................................................................................................................ 53
Tabla 6 Esfuerzos Sprint 2. ................................................................................................................ 54
Tabla 7 Esfuerzos Sprint 3. ................................................................................................................ 56
Tabla 8 BackLog general del proyecto con Esfuerzos. ...................................................................... 57
Tabla 9 Diccionario de datos colección ZoneDTO. ............................................................................ 67
Tabla 10 Diccionario de datos colección UserDTO. .......................................................................... 67
Tabla 11 Diccionario de datos colección UnitDTO. ........................................................................... 67
Tabla 12 Diccionario de datos colección UnitDTO. ........................................................................... 67
Tabla 13 diccionario de datos colección ConfigurationDTO. ............................................................ 68
Tabla 14 Diccionario de datos colección AccessRuleDTO. ................................................................ 68
Tabla 15 Diccionario de datos colección EventDTO. ......................................................................... 68
Tabla 16 Tiempo desarrollo Vs Errores de desarrollo. ...................................................................... 82
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 7
Introducción
La seguridad de los activos es uno de los ítems más importantes dentro de los planes de
seguridad implantados por cada organización, en la actualidad las empresas y
organizaciones comúnmente delegan la función de seguridad en terceros, generalmente
una empresa de seguridad privada, estas empresas de seguridad se encargan de
salvaguardar las instalaciones de las organizaciones y en algunos casos un cierto control
en el acceso a las instalaciones por parte de extraños. sin embargo el nivel de acceso
privilegiado sobre ciertas áreas, recursos o activos de la empresa es tratado de forma
trivial en muchos casos y en otros hace parte del plan general de la organización
enfocado a la seguridad de los activos de información con que cuenta la empresa, la
forma de control es mediante sistemas como el RFID (Radio Frequency IDentification,
en español identificación por radiofrecuencia) que es un sistema de almacenamiento y
recuperación de datos remoto que usa dispositivos denominados etiquetas, tarjetas,
transpondedores o tags RFID. El propósito fundamental de la tecnología RFID es
transmitir la identidad de un objeto (similar a un número de serie único) mediante ondas
de radio. Las tecnologías RFID se agrupan dentro de las denominadas Auto ID
(automatic identification, o identificación automática). Esta clase de tecnología permite
garantizar el acceso, sin embargo no garantiza la identidad de quien accede, lo que
representa una gran falencia, en el otro extremo se tienen los sistemas de control de
acceso, con lectores biométricos, que cuyos esquemas de seguridad permiten controlar
que a determinadas áreas de la organización solo ingresen las personas autorizadas. En
estos sistemas de control de acceso se usa la huella digital, u otra cualidad diferencial, a
manera de llave o pase de entrada por lo cual es plenamente identificable la identidad de
las persona que intenta obtener acceso.
Los sistemas de identificación biométrica son esencialmente software que corre sobre un
equipo que permite la identificación inequívoca de personas, previamente registradas por
otra parte del sistema en una base de datos. Estas características físicas individuales no
pueden ser falsificadas fácilmente. Habitualmente estas lecturas biométricas se basan en
las características de las huellas digitales o cualquier otro identificador biométrico.
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 8
Para proveer movilidad al sistema de identificación de forma que permita ser transportado e
instalado fácilmente, este debe cumplir con ciertas características como: ser liviano,
permitir conectarse por diversos medios, poseer respaldo de datos externo, permitir
guardar registros de transacciones, sincronizar las transacciones cuando se encuentre de
nuevo en línea, permitir adicionar nuevo hardware de control, y las demás características
de un sistema distribuido.
El presente proyecto de grado hace uso de los conocimientos adquiridos durante la
formación académica en la ingeniería en telemática para desarrollar un prototipo de
sistema de control de acceso, que sea distribuido y utilice las tecnologías libres que
existen en el mercado; El desarrollo de dicho prototipo se hace bajo la metodología ágil
de desarrollo Scrum y pretende demostrar la viabilidad de construir y mantener un
sistema de este tipo en las organizaciones.
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 9
1. FASE INICIAL
1.1. Titulo Prototipo de Sistema de Control de Acceso Distribuido con Tecnologías Libres.
1.2. Tema Los temas tratados en este proyecto son: El control de Acceso, desarrollo de software libre, la
tecnología Java, los sistemas distribuidos, la seguridad física de las organizaciones y las Bases
de datos.
1.3. Descripción del Problema
Las empresas se ven abocadas en la actualidad a proteger activos de gran valor para sus
organizaciones, los controles establecidos para salvaguardar dichos activos no suelen ser muy
efectivos ya que en gran parte se ven limitados por los proveedores de soluciones de seguridad,
quienes en muchos casos no cuentan con productos adaptables a la necesidad de cada cliente, o
en otros casos son muy costosas para ser implementadas, lo que limita a las empresas para
establecer un esquema de seguridad adecuado y a su vez contribuye a que no puedan tener
controles adecuados eficientes que se traduce en pérdidas de activos, como perdidas de
información o fugas de información.
Las soluciones que ofrecen los proveedores de tecnología del área de la seguridad presentan costos
elevados para ser implementadas porque dependen de una inversión económica para la
adecuación de la infraestructura física, contratos de servicio por periodos de tiempo prefijados,
cobros asociados a licencias de tecnologías propietarias con periodos de expiración y costos
ocultos en la actualización de los esquemas de seguridad como lo menciona John LaFond en su
artículo ‘Counting Up the Hidden Costs of Security Licensing’1:
“Al ampliar o actualizar los sistemas, todos los clientes son susceptibles a una amplia gama de
honorarios por licencia (además de cualquier costo laboral o de hardware) que puede aumentar
significativamente la cantidad que usted está pagando por las mejoras o actualizaciones de
tecnología que su empresa quiere y necesita. Los costos ocultos pueden provenir de tarifas de
servicios cloud, cliente o cobros de licencias de base de datos, comisiones por licencias de
hardware, o cualquier combinación de éstos. Esto significa que cualquier momento que desee
1 LaFond, John. (2010). Counting Up the Hidden Cost of Security Licensing. [versión Electrónica], Security
Magazine. Recuperado el Junio 10 de 2014, de http://www.securitymagazine.com/articles/85588-counting-up-the-hidden-cost-of-security-licensing
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 10
ampliar el número de puntos de acceso, implementar la integración de vídeo o tal vez actualizar
su sistema con control de acceso al ascensor, le podría costar en múltiples niveles.”
1.4. Formulación del Problema ¿Cómo construir una solución tecnológica que sea una alternativa a las soluciones actuales del
mercado, que sea económica, confiable y adaptable a las empresas interesadas en proteger la
integridad y confidencialidad de sus activos por medio de control de acceso?
1.5. Objetivo General
Desarrollar un prototipo de sistema de control de acceso distribuido de software libre, adaptable y
de bajo costo de implementación.
1.6. Objetivos Específicos
Analizar los requerimientos para el desarrollo del sistema de control de acceso.
Diseñar una solución tecnológica que cumpla con los requerimientos identificados.
Desarrollar un prototipo de solución tecnológica para el control del acceso que
permita ser usada con propósito general, que sea adaptable a diferentes contextos
dentro de las organizaciones, permita escalabilidad y adaptación a diversos
componentes de hardware como lectores biométricos, teclados numéricos, tarjetas
RFID o etiquetas NFC.
Implementar una solución Tecnológica que no tenga costos asociados al
licenciamiento de las tecnologías utilizadas.
Probar el prototipo en la empresa A & G Tecnología para comprobar que el sistema
desarrollado cumpla con los objetivos planteados.
1.7. Justificación
Un estudio del mercado de la tecnología en américa latina sugiere que “El mercado de la
Seguridad Electrónica” es un mercado de cambios tecnológicos constantes, lo que
hace que las empresas usuarias de un sistema de seguridad quieran estar siempre a
la par con la tecnología de países desarrollados como Estados Unidos.
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 11
Actualmente y desde hace ya un par de años, en Seguridad Electrónica se vive en la era de
la tecnología IP y la convergencia de las tecnologías, por lo cual las empresas
buscan que sus sistemas de seguridad cuenten con estas características.
Igualmente los sistemas de control de acceso buscan el uso más
eficiente y seguro de la biometría para la identificación de las personas,
para ello se han experimentado diferentes ideas como la de usar la
saliva como elemento identificador y proporcionador de datos de
pacientes como son los de las enfermedades que padecen, su historia
patológica, entre otras. También cada vez está siendo más usado la
biometría en los gobiernos de países para la identificación de los
extranjeros que ingresan al país, como es el caso del gobierno de
Canadá, o la identificación de los estudiantes mediante dispositivos
biométricos faciales, como lo está realizando un colegio Británico. En
Control de Acceso, la competencia está planteada entre el uso de la
biometría o las tarjetas inteligentes o Smart Cards. Estas últimas
pretenden que bajo una misma y única tarjeta se pueda manejar mucha
información para ser utilizada en diferentes aplicaciones. Por ejemplo,
que sea usada una única tarjeta para el ingreso a la empresa o centro
educativo, el pago en un centro comercial, etc.2
Después de analizar las soluciones tecnológicas para el control de acceso que se
encuentran en la actualidad para el mercado colombiano, se puede identificar que
estas soluciones incluyen generalmente un hardware y software propietario, lo que
se ve reflejado en el costo para el usuario final quien debe pagar una subscripción o
licencia de uso por periodos de tiempos establecidos para que la empresa que
proporciona los sistemas de control de acceso le presten el servicio, estos contratos
de servicio por lo general son de periodos no menores a un año. Si el usuario final
desea modificar o ampliar el esquema de seguridad debe adquirir otra licencia o
subscripción con la empresa contratante lo que impacta económicamente sus
2 Garcia, M., Alex. (2009). Estudio de Mercado De La Seguridad Electrónica en Colombia. Recuperado el 10
de marzo de 2015, de https://docs.google.com/file/d/0B1Hnm-wBJAJCNDE2NGNiNTItMzI5OS00NGQyLWIzODMtMGM1ZDU3YmY5M2Zl/edit?hl=en_US
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 12
finanzas. Esto genera que las organizaciones no vean las soluciones de control de
acceso como sistemas más allá del ingreso del personal a el lugar del trabajo, y
aunque la protección de los activos con que cuentan las organizaciones siempre son
importantes, las empresas no cuentan con una opción completa, confiable y
económica para mantener un manejo efectivo sobre la protección y el acceso sobre
dichos activos que hacen parte de la organización. Teniendo en cuenta lo anterior se
debe considerar que las empresas colombianas interesadas en implementar un
sistema de control, fácilmente optarían por un sistema de control de acceso con la
seguridad que ofrecen las variables biométricas, que pueda ser utilizado no
solamente como control de acceso a áreas, que pueda ser fácilmente adaptable a
otros contextos dentro de las organizaciones, que sea altamente escalable y cuya
implantación, mantenimiento y gestión sea más económica que las soluciones que
se pueden conseguir en el mercado actualmente.
El Prototipo de Sistema de control de acceso con tecnologías libres busca presentarse como
una opción económica y simple para implementar el control de acceso en diversos
escenarios dentro de las organizaciones, al hacer uso de las tecnologías existentes tanto
en software y hardware libre, es posible desarrollar mediante el diseño de interacción
un prototipo de sistema de control de acceso con la posibilidad de usar una gran variedad
de módulos y sensores, la principal ventaja de esta aproximación es la economía y la
posibilidad de usar y modificar su configuración para ser adaptado a las necesidades de
cada organización.
1.8. Alcances y Delimitaciones
1.8.1. Delimitación Temática
El presente proyecto pretende usar los conocimientos adquiridos durante la carrera de
Ingeniería en Telemática, por lo cual solo se abordarán los temas técnicos necesarios
para poder desarrollar un prototipo de sistema de control de acceso distribuido.
Por lo anterior los sensores, lectores o cualquier otro medio de lectura de información serán
considerados en el proyecto pero no serán implementados en el prototipo.
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 13
El proyecto se centra en el sistema distribuido, todas las adaptaciones, adecuaciones de los
dispositivos de reconocimiento, interfaz de potencia, motores, compuertas y demás
elementos físicos no se encuentran dentro de la finalidad del proyecto.
1.8.2. Delimitación Geográfica
La solución tecnológica será desarrollada en la ciudad de Santa Fe De Bogotá, distrito
capital del estado colombiano.
1.8.3. Delimitación Temporal
El proyecto se desarrollará entre los meses de Mayo y Agosto de 2015 para un total de 4
meses.
1.8.4. Alcances
El sistema desarrollado cumplirá la función básica de los sistemas de control de
acceso de permitir o denegar el acceso a un usuario, por tal motivo para modo de
ilustración el prototipo contará con un mecanismo básico de autenticación simulado.
La solución tecnológica al ser un prototipo solo contará con una unidad de acceso y
el servidor de control.
La solución tecnológica dentro de las labores de administración solo contará con los
flujos funcionales de Creación y Modificación, no el de eliminación.
El sistema desarrollado contará con un canal de comunicación encriptado.
El prototipo del sistema de control de acceso tendrá una apartado para la
visualización histórica de eventos, para poder evidenciar el funcionamiento, contará
con un filtro dentro del cual se podrá seleccionar el periodo de tiempo a consultar.
El sistema será desarrollado usando Raspberry Pi, por lo que el sistema asume las
limitaciones inherentes a este hardware.
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 14
1.9. Marco Teórico Los siguientes son las técnicas y tecnologías escogidas para el desarrollo del proyecto,
teniendo en cuenta que son software libre y patrones de diseño disponibles para su
uso.
1.9.1. Desarrollo de aplicaciones MVC
Arquitectura MVC (Modelo vista Controlador). Fue descrita por primera vez en
1979 en el documento “Applications Programming in Smalltalk-80(TM): How to
use Model-View-Controller (MVC)”3. Dirigido al lenguaje de programación
Smalltalk. Usada como el patrón clásico para aplicaciones donde el usuario
interactúa constantemente con el sistema, “La arquitectura de diseño MVC
(iniciales en inglés de “Model View Controller” o “Modelo Vista Controlador”)
provee un mecanismo que posibilita separar los datos (el modelo) de la forma en
que estos serán visualizados (la vista) Usando un puente entre los dos (El
controlador)”4, lo anterior se puede observar en la figura 1.
3 Burbeck, Steve. (2012) Applications Programming in Smalltalk-80(TM):
How to use Model-View-Controller (MVC). Recuperado el 08 de septiembre de 2014, Disponible en: < http://st-www.cs.illinois.edu/users/smarch/st-docs/mvc.html> 4 SZNAJDLEDER, Pablo. Java a fondo: estudio del lenguaje y desarrollo de aplicaciones 1ª ed. Buenos Aires,
Alfaomega, 2010,528p.
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 15
Ilustración 1 Arquitectura MVC
Fuente: Bullet, Cristhoper. Model-View-Controller frameworks. [En línea] [Consulta: 08 de septiembre de 2013]
Disponible en: <http://www.adobe.com/newsletters/inspire/october2008/articles/article2/index.html>
Lo que se consigue con la arquitectura MVC es un mantenimiento más sencillo de
las aplicaciones. Si por ejemplo una misma aplicación Web debe ejecutarse tanto en
un navegador estándar como un navegador de un dispositivo móvil, solamente es
necesario crear una vista nueva para cada dispositivo; manteniendo el controlador y
el modelo original.
Según Rigada, Aitor5. Los componentes MVC se pueden definir como:
El Modelo. Incorpora la capa del dominio y persistencia, es la encargada de guardar
los datos en un medio persistente (ya sea una base de datos, un archivo de texto,
XML, registro, etc.). En el modelo es donde se hace el levantamiento de todos los
objetos que el sistema debe de utilizar, es el proveedor de recursos. Es muy típico
que las clases del modelo incorporen otro patrón de diseño ya que así es más fácil
manejar la información usada por el motor de la base de datos, como el caso de
motor MySQL, aunque pueden ser también un conjunto de archivos formateados o
5 Rigada, Aitor. (2008). Model View Controller. Recuperado el 15 de septiembre de 2014. de
< http://blogdeaitor.wordpress.com/2008/10/20/model-view-controller/>
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 16
incluso archivos planos. Lo importante es que esta parte debe ser la más oculta del
sistema, para proporcionar la menor cantidad de información a los usuarios o en
general a cualquier persona (incluso aquellas malintencionadas). De esta forma, se
crea una capa de Software para abstraer la información concreta del modelo. Un
ejemplo de esto es la abstracción de Java para conexión a las bases de datos
(JDBC).
La Vista. Se concentra en la presentación de los datos al cliente o usuario. Por
ejemplo en el caso de las aplicaciones de escritorio, la vista serían las diferentes
ventanas que componen la aplicación, en el caso que la aplicación fuera Web, la
vista serían las páginas HTML, JSP o ASP que se cargan en el navegador, dándole
al usuario la información que le corresponde. La construcción de la vista puede estar
a cargo de diseñadores gráficos (para la imagen de la empresa, uniformidad de
conceptos). Al ser completamente independiente del resto del sistema, puede
cambiarse fácilmente sin afectar las capas inferiores.
En la vista solo se deben de hacer operaciones simples que estén orientadas a forma en que
se mostraran los datos, como ciclos, formateo, etc.
El Controlador. Crea un puente entre las dos capas anteriores (Modelo y Vista). Se
encarga de obtener las peticiones hechas por el cliente desde la vista, formatearlas
para que sean entendibles para el sistema, y acceder al módulo correspondiente que
a su vez consultará al modelo en el momento que se necesite. De igual manera, al
obtener una respuesta del sistema, el controlador se encarga de generar una vista de
retroalimentación para el usuario y así cerrar el ciclo para quedarse a la espera de un
nuevo evento que inicie un nuevo ciclo, dicho evento por lo general lo genera el
usuario del sistema.
1.9.2. Arquitectura de un sistema bajo el patrón MVC
En la figura 2 Se marca la disposición común con el cual se desarrolla un sistema bajo la
arquitectura o patrón MVC, se muestra la forma en que interactúan las tres capas
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 17
de información, se debe denotar que el usuario del sistema no debe tener acceso a la
capa del Modelo (donde están los datos) por seguridad y dado que así lo dispone el
patrón de diseño, el usuario solo debe interactuar con la capa de vista o
presentación a través del Controlador y es este último quien se comunica con todas
las capas que componen la aplicación.
Ilustración 2 Arquitectura de un Sistema Bajo el patrón MVC.
Fuente: ADOBE INC. The MVC Architecture. [En línea]. [Consulta: 12 de septiembre de 2013] Disponible en
<http://www.symfony-project.org/jobeet/1_2/Doctrine/en/04.>
Flujo de un sistema MVC de escritorio.6 Junto al usuario, los componentes de MVC forman
dos ciclos de información y flujo de control:
Ciclo de la Vista: Usuario → Controlador → Vista → Usuario. El usuario manipula
un dispositivo de entrada - por ejemplo, con un clic, mientras el cursor del ratón en
6 Steele, Oliver. (2004). LANGUAGES OF THE REAL AND ARTIFICIAL. Web MVC. Recuperado el 12 de
septiembre de 201], de <http://osteele.com/archives/2004/08/web-mvc>
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 18
la parte inferior de una barra de desplazamiento. El controlador responde enviando
un mensaje a La Vista que actualiza su estado, y actualiza la información que se
presenta al usuario.
Ciclo del Modelo: Usuario → Controlador → Modelo → Vista → Usuario. El
usuario manipula un dispositivo de entrada de una forma y en un contexto
diferente. El controlador actualiza el estado del Modelo, la vista se actualiza para
reflejar el cambio en el modelo, y al usuario se le presenta la nueva vista.
Flujo de un sistema MVC en un servidor7. Cuando un sistema MVC se emplea en un Servidor este
debe compartir el esquema de desarrollo con el cliente, debido a que este último a través
de su capa de control se comunica con la capa controlador del servidor. En la figura 3 se
instruye sobre este hecho. Para el caso de Java se usa un JDK para el desarrollo del
servidor y un Java ME SDK, para el desarrollo de la aplicación en el dispositivo móvil,
gracias a un IDE (entorno de desarrollo integrado) como NetBeans se logra usar un mismo
entorno de desarrollo para las tres capas donde solo cambia la forma visual de la Vista.
Ilustración 3 MVC del lado del servidor (Desacoplado)
Fuente: Iriarte, Leandro. Web MVC. [En línea] [Consulta: 12 de septiembre de 2013] Disponible en:
<http://www.leandroiriarte.com.ar/spanish/web_mvc.php.>
7 Ibíd.
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 19
1.9.3. Ventajas de la arquitectura MVC
Según Aguilar, José M.8 Al tener un amplio recorrido histórico y al ser la base de desarrollo
de muchas aplicaciones Web esta arquitectura presente varias ventajas, entre las que se
cuentan:
fácil y flexible estructuración del código.
Si se desarrolla respetando los lineamientos, seguridad y ayuda para el
programador.
Clara separación entre interfaz, lógica de negocio y de presentación, que además
provoca parte de las ventajas siguientes.
Sencillez para crear distintas representaciones de los mismos datos.
Reutilización de los componentes.
Simplicidad en el mantenimiento de los sistemas.
Facilidad para desarrollar prototipos rápidos.
Los desarrollos suelen ser más escalables.
las piezas de un programa se pueden construir por separado.
1.9.4. Desventajas de la arquitectura MVC9
Al igual que las restantes arquitecturas utilizadas para construir sistemas informáticos,
entre las principales se encuentran:
Tener que ceñirse a una estructura predefinida, lo que a veces puede incrementar la
complejidad del sistema. Hay problemas que son más difíciles de resolver
respetando el patrón MVC.
La curva de aprendizaje para los nuevos desarrolladores se estima mayor que la de
modelos más simples.
La distribución de componentes obliga a crear y mantener un mayor número de
ficheros.
8 Aguilar, José M. (2012) ASP.NET MVC 2: Quince cuestiones que deberías conocer. Recuperado el 12 de
septiembre de 2014, de <http://www.variablenotfound.com/2010/05/aspnet-mvc-2-quince-cuestiones-que.html> 9 Ibíd.
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 20
El tiempo de desarrollo de una aplicación que implementa el patrón de diseño
MVC es mayor, al menos en la primera etapa, que el tiempo de desarrollo de una
aplicación que no lo implementa.
1.9.5. JAVA 10
Es una plataforma virtual de software desarrollada por Sun Microsystems, orientada a que
los programas creados en ella puedan ejecutarse sin cambios en diferentes tipos de
arquitecturas y dispositivos computacionales (“diferentes Plataformas”).
La plataforma Java consta de las siguientes partes:
El lenguaje de programación, mismo.
La máquina virtual de java o JRE, que permite la portabilidad en ejecución.
El API (del inglés Application Programming Interface), una biblioteca estándar
para el lenguaje.
En un principio fue diseñado para correr en computadoras incrustadas. Sin embargo, en
1995, dada la atención que se estaba produciendo en la Web, Sun Microsystems la
distribuyo para sistemas operativos tales como Microsoft Windows.
Con la evolución de las diferentes versiones, no solo se han producido cambios en el
lenguaje, sino que también se han producido cambios mucho más importantes en
sus bibliotecas asociadas y dando la posibilidad de expandirse al terreno de los
dispositivos móviles mediante la plataforma J2ME (Java 2 Micro Edition).
Java Development Kit (JDK). También conocido como J2SE (Java Standard
Edition), es un software que provee herramientas de desarrollo para la creación de
programas en java orientados a ordenadores de sobremesa, en donde se han
incorporado clases adicionales para facilitar el desarrollo de aplicaciones y donde la
interfaz de usuario tiene una importancia muy especial. Los programadores de
software que en la actualidad programen soluciones orientadas a la Web suelen
recurrir a este conjunto de APIS para realizar su desarrollo. Entre sus componentes
se encuentran:
10
FROUFE QUINTAS, Agustín. Java 2 Manual de Usuario y Tutorial. 5 Edi. México. Alfaomega, 2008, 696 p.
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 21
Intérprete en tiempo de ejecución (JRE). Permite la ejecución de los programas
Java (*.class) no gráficos (aplicaciones).
Compilador. Se utiliza para compilar archivos de código fuente Java
(habitualmente *.java), en archivos de clases Java ejecutables (*.class).
Visualizador de applets. Es una herramienta que sirve como campo de pruebas de
applets, visualizando cómo se mostrarían en un navegador, en lugar de tener que
esperar.
Depurador. Es una utilidad de línea de comandos que permite depurar aplicaciones
Java. No es un entorno de características visuales, pero permite encontrar y
eliminar los errores de los programas Java con mucha exactitud.
Desensamblador de archivo de clase. Se utiliza para desensamblar un archivo de
clase. Su salida por defecto, muestra los atributos y métodos públicos de la clase
desensamblada, es útil cuando no se tiene el código fuente de una clase de la que se
quisiera saber cómo fue codificada.
1.9.6. Netbeans IDE. 11
Es un entorno de desarrollo integrado (IDE),una herramienta de código libre, gratuita, que
sirve para que los programadores puedan escribir, compilar, depurar y ejecutar
programas, tiene soporte para crear interfaces gráficas de forma visual, crear
aplicaciones para móviles, Web, etc. Está escrito en Java, pero puede servir para
cualquier otro lenguaje de programación. Las funcionalidades son ampliables
mediante instalación de paquetes adicionales. NetBeans IDE se conoce como la
solución más completa para programar en Java.
1.9.7. MongoDB. 12
Es un sistema de bases de datos no relacionales (NoSQL), multiplataforma e inspirada en el
tipo de bases de datos documental y clave/valor, su nombre proviene del término en
11
Bienvenido a NetBeans y www.netbeans.org. Recuperado el 05 de septiembre de 2014, del sitio oficial de netbeans, Disponible en < http://netbeans.org/index_es.html> 12
Graterol, Yohan D.(2014) MongoDB en español – Tomo 1 “El principio”. Recuperado el 22 de marzo de 2015. Disponible en: < http://www.etnassoft.com/biblioteca/mongodb-en-espanol-t1-el-principio/ >
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 22
inglés "humongous". Está liberada bajo licencia de software libre, específicamente
GNU AGPL 3.0. MongoDB usa el formato BSON (JSON Compilado) para guardar
la información, dando la libertad de manejar un esquema libre. Este motor de bases
de datos es uno de los más conocidos y usados, pudiéndolo comparar en
popularidad con MySQL en el caso de las bases de datos relacionales.
MongoDB ha ganado popularidad por una serie de atractivas características:
Uso de documentos en formato JSON.
Los registros son almacenados como documentos.
Permite asociar los documentos sobre estructuras de tipo colección similares a las
tablas en los sistemas relacionales.
Está optimizado para equipos de múltiples procesadores.
Es muy destacable su velocidad de respuesta.
Soporta modelos de datos embebidos lo que reduce la actividad de lectura y
escritura en el sistema de base de datos.
Suporta indexación sobre documentos para realizar búsquedas rápidas.
Su administración permite la fácil escalabilidad.
Posee un alto grado de disponibilidad.
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 23
1.10. Marco Conceptual
Los siguientes son los conceptos a tener en cuenta para el desarrollo del proyecto.
1.10.1. Sensor13
Es un dispositivo capaz de detectar magnitudes físicas o químicas, llamadas variables de
instrumentación, y transformarlas en variables eléctricas. Las variables de
instrumentación pueden ser por ejemplo: temperatura, intensidad lumínica,
distancia, aceleración, inclinación, desplazamiento, presión, fuerza, torsión,
humedad, pH, etc. Una magnitud eléctrica puede ser una resistencia eléctrica (como
en una RTD), una capacidad eléctrica (como en un sensor de humedad), una
Tensión eléctrica (como en un termopar), una corriente eléctrica (como en un
fototransistor), etc.
1.10.2. Telemetría14
La telemetría es una tecnología que permite la medición remota de magnitudes físicas y el
posterior envío de la información hacia el operador del sistema. La palabra
telemetría procede de las palabras griegas tele ("lejos") y metron ("medida").
El envío de información hacia el operador en un sistema de telemetría se realiza
típicamente mediante comunicación inalámbrica, aunque también se puede realizar
por otros medios (teléfono, redes de ordenadores, enlace de fibra óptica, etcétera).
1.10.3. Raspberry Pi15
Es una placa computadora (SBC) de bajo costo desarrollada en Reino Unido por la
Fundación Raspberry Pi, con el objetivo de estimular la enseñanza de ciencias de la
computación en las escuelas.
El diseño de la Raspberry Pi incluye un System-on-a-chip Broadcom BCM2835, que
contiene un procesador central (CPU) ARM1176JZF-S a 700 MHz (el firmware
incluye unos modos Turbo para que el usuario pueda hacerle overclock de hasta 1
13
Vargas, Aldo. Sensores. Centro de formación profesional automotriz. Mexico.2009.20p. 14
TELEMETRIA. (sin fecha). Recuperado el 10 de septiembre de 2014. Del sitio oficial de IOCOM <http://iocom.com.co/telemetria> 15Página oficial de Raspberrypi. (Sin Fecha). Recuperado el 10 de septiembre de 2014. Disponible
en <http://www.raspberrypi.es/ >
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 24
GHz sin perder la garantía), un procesador gráfico (GPU) VideoCore IV, y 512 MB
de memoria RAM aunque originalmente al ser lanzado eran 256 MB. El diseño no
incluye un disco duro o una unidad de estado sólido, ya que usa una tarjeta SD para
el almacenamiento permanente; tampoco incluye fuente de alimentación o carcasa.
El modelo B se vende a 35$ y el modelo A a 25$. El 29 de febrero de 2012 la
fundación Raspberry Pi empezó a aceptar órdenes de compra del modelo B, y el 4
de febrero de 2013 del modelo A.
1.10.4. Gestor de Bases de Datos16
Un gestor de base de datos o sistema de gestión de base de datos (SGBD o DBMS) es un
software que permite introducir, organizar y recuperar la información de las bases
de datos; en definitiva, administrarlas.
1.10.5. Aplicación17
También llamados Aplicativos, forman parte del software ya que son una serie de
programas que han sido desarrollados para facilitarle al usuario la utilización de la
máquina para una acción o fin determinados. Una aplicación está diseñada y
optimizada como una herramienta para un propósito específico, como respuesta
ante una necesidad del usuario.
1.10.6. TCP/IP18
“Protocolo de control de transmisión/Protocolo de Internet", Es una familia de protocolos
desarrollados para permitir la comunicación entre cualquier par de ordenadores de
cualquier red o fabricante, respetando los protocolos de cada red individual. En
algunos aspectos, TCP/IP representa todas las reglas de comunicación para Internet
y se basa en la noción de dirección IP, es decir, en la idea de brindar una dirección
IP a cada equipo de la red para poder enrutar paquetes de datos. Originalmente se
creó con fines militares.
16
Barranco, Manuel J. (2013). GESTORES DE BASES DE DATOS. Recuperado el 10 de septiembre de 2014, de <http://wwwdi.ujaen.es/~barranco/publico/ofimatica/tema7.pdf> 17
Lanzillotta, Analía. (2013). Definición de Aplicación. Recuperado el 22 de septiembre de 2014, de <http://www.mastermagazine.info/termino/3874.php> 18
García, Jesús. Ferrando, Santiago y Piattini, Mario. Redes Para Procesos Distribuidos. México, Alfaomega, 1997, P267.
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 25
1.10.7. Equipo Servidor19
Cuando en una red cliente/servidor existe una gran cantidad de recursos, es normal que
existan varios equipos servidores, pudiendo estar cada uno de ellos dedicado a
ofrecer un solo tipo de servicio o información. Así, un servidor dedicado puede ser
exclusivamente de archivos, de impresoras, de bases de datos, de correo electrónico,
de páginas web, etc.
1.10.8. Equipo Cliente
Si un servidor se encarga de prestar un servicio, su contra parte, el cliente, se encarga de
hacer uso de este servicio, es así como un a través de un equipo cliente se encarga
de interactuar con un sistema informático.
1.10.9. Sistema Distribuido
Un sistema distribuido es una colección de computadoras independientes, conectadas en
red, comunican y coordinan sus acciones únicamente mediante el paso de mensajes,
que aparecen ante los usuarios del sistema como una única computadora o servicio.
1.10.10. Lightweight Directory Access Protocol 20
Conocido como LDAP por sus siglas en inglés, es un protocolo para los servicios de
directorios basados en el estándar x.500 donde se almacenan atributos basados en
datos, utiliza un modelo cliente servidor que se basa en entradas con colecciones de
atributos almacenados en un árbol lógico bajo un nombre de domino.
19
Ibíd.,p226. 20
Marshall, Brand.(sin fecha) Introduction to LDAP. Recuperado el 28 de septiembre de 2014, Disponible en: <http://quark.humbug.org.au/publications/ldap/ldap_tut_v2.pdf>
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 26
1.11. Estado del Arte
Los sistemas de Control de Acceso son tan antiguos como la sociedad misma, puesto que
dichos sistemas consisten en la restricción selectiva de acceso a un lugar u otro
recurso, comúnmente el permiso de acceso al recurso, objeto o lugar se denomina
autorización.
Los primeros controles de acceso se basaron en el reconocimiento individual y el uso de
personal de seguridad para la conmutación del elemento de bloqueo (puerta), o el
uso de otro tipo de barrera para el acceso que comúnmente incluye candado y
llave.
En la seguridad física y control de acceso es importante conocer quien, donde y cuando. El
sistema debe determinar quién está autorizado para ingresar o salir, dónde está
autorizado para ingresar o salir y cuando está autorizado para ingresar o salir.
Históricamente se ha relacionado con el uso de cerraduras y llaves. Cuando la
puerta está cerrada, únicamente una persona con la llave puede abrirla,
dependiendo de cómo esté adecuada la cerradura. Los mecanismos de cerradura y
llave no tienen restricciones de tipo temporal, no tienen registros de los accesos
sobre las cerraduras, y pueden ser copiadas con relativa facilidad, de manera que el
responsable puede trasferir la llave a alguien sin autorización.
Los sistemas de control de acceso electrónico usan equipos de cómputo para solventar las
limitaciones de los sistemas mecánicos como cerraduras y llaves, un amplio rango
de credenciales puede suplantar los sistemas mecánicos. Los sistemas de control de
acceso electrónicos garantizan el acceso basados en la credencial que se presente.
Cuando el acceso se ha garantizado, la puerta se desbloquea y el sistema deja un
registro con la hora del suceso y el usuario. Cuando el acceso no es permitido, la
puerta permanece cerrada y el sistema deja un registro de la hora, y si es necesario
dispara una alerta. Si el sistema detecta que la puerta es forzada se debe generar
una alarma.
La Identificación Biométrica, consiste en el estudio de métodos automáticos para el
reconocimiento único de seres humanos basado en una o más características físicas.
En las tecnologías de la información la “autenticación biométrica” o “biometría
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 27
informática” es la aplicación de algoritmos sobre los rasgos físicos del individuo
para verificar su identidad.
Los sistemas de control de acceso con identificación biométrica son relativamente nuevos,
en 1883 Alphonse Bertillon desarrolló un sistema antropométrico para la
identificación de criminales.A finales del siglo XIX el científico Sir Francis Galton
demostró que el patrón de huellas dactilares es exclusivo de cada individuo. En
1936 el oftalmólogo Frank Burch propuso usar patrones de iris como método de
identificación. Para la década de 1980 las películas de ciencia ficción mostraban
modernos sistemas que identificaban el usuario por sus características físicas. En
1994 la compañía Iridian Technologies presentó los primeros algoritmos para el
reconocimiento del iris.
Existen muchas soluciones tecnológicas en el mercado actual, estas soluciones tecnológicas
no usan tecnologías libres, debido que los temas de soporte y el licenciamiento de
los componentes del Sistema, sin embargo son numerosas las iniciativas
académicas y de entusiastas de la tecnología, las cuales abordan el tema de control
de acceso haciendo uso de componentes como el Raspberry Pi, algunos de estos
proyectos son:
Monitor Your Home With the Raspberry Pi B+21
: Este proyecto de domótica hace uso
de tecnologías libres para programar un sistema que permita el monitoreo remoto a
través de una cámara de video. Dentro de las mejoras futuras mencionan la
capacidad de completar el sistema con sensores y por ende con métodos de control
de acceso.
RFPiD – Raspberry Pi RFID door access system22
: Desarrollado por la organización
NESIT, es un proyecto para remplazar su sistema de control de acceso a base
de tarjetas RFID, este sistema de acceso puede ser controlado vía remota a
21
Schwartz, Marco. (2014) Monitor Your Home With the Raspberry Pi B+. publicado el 26 de septiembre de 2014.Recuperado el 31 de julio de 2015, de https://www.openhomeautomation.net/monitor-your-home-raspberry-pi-b/ 22
RFPiD – Raspberry Pi RFID door access system. (Sin fecha). Recuperado el 31 de julio de 2015, de http://nesit.org/rfpid-raspberry-pi-rfid-door-access-system/
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 28
través de Google Talk, utiliza un base SQLite la cual almacena la información
del sistema.
Raspberry Pi Access Control System (RPAC)23: Este proyecto también utiliza
Raspberry Pi como herramienta para habilitar o denegar el acceso a través de
un lector de tarjetas RFID que se conecta a una puerta física. Esta desarrollado
bajo el lenguaje de Phyton y utiliza el protocolo I2C para intercomunicar el
hardware del sistema.
También existen artículos científicos publicados sobre el tema de las tecnologías libres y
los sistema de control de acceso, es el caso del articulo ‘Access Control of Door
and Home Security by Raspberry Pi Through Internet’24
, el cual menciona los
aspectos técnicos para crear un proyecto de control de acceso usando un Raspberry
Pi como elemento central. La figura 4 ilustra el montaje general del proyecto.
Ilustración 4 Montaje de un sistema de control de acceso
Fuente: Chowdhury, Nasimuzzaman. Nooman, Shiblee, Sarker, Srijon. Access Control of Door and Home Security
by Raspberry Pi Through Internet. [En línea] [consulta: 31 de Julio de 2015] Disponible en: <
http://www.researchgate.net/publication/258337862_Access_Control_of_Door_and_Home_Security_by_Ras
pberry_Pi_Through_Internet.>
23
Pearson, Oskar. (2014). Raspberry Pi Access Control System (RPAC), recuperado el 31 de julio de 2015, disponible en https://github.com/oskarpearson/raspberry-pi-access-control-system 24
Chowdhury, Nasimuzzaman. Nooman, Shiblee, Sarker, Srijon. (2013). Access Control of Door and Home Security by Raspberry Pi Through Internet. International Journal of Scientific & Engineering Research, Volume 4, Issue 1ŗ. Recuperado el 31 de julio de 2015, de http://www.researchgate.net/publication/258337862_Access_Control_of_Door_and_Home_Security_by_Raspberry_Pi_Through_Internet
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 29
1.12. Marco Metodológico La metodología seleccionada para ejecutar el proyecto es Scrum por la agilidad y
adaptabilidad que tiene para un este tipo de desarrollos, las fases de esta
metodología son:
Planificación: corresponde al análisis, diseño de arquitectura, selección de
tecnologías, equipo de trabajo y alcances de la solución tecnológica.
Sprint: Corresponde al desarrollo de una cantidad de elementos identificados en la
primera fase, ejecución de las tareas, pruebas de los componentes y revisión de los
entregables
Implementación: Ensamblar los componentes entregados y aprobados en el Sprint.
Revisión del Sprint: Analizar las falencias y aciertos en el Sprint, así como los
impactos en los Sprits subsiguientes, preparar el equipo de trabajo para el siguiente
Sprint.
Ilustración 5 Ciclo de vida de un proyecto con Scrum.
Fuente: Trigas, Manuel . Metodología Scrum. [En línea] [Consulta: 08 de septiembre de 2014]
Disponible en: < http://openaccess.uoc.edu/webapps/o2/bitstream/10609/17885/1/mtrigasTFC0612memoria.pdf>
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 30
1.13. Factibilidad
1.13.1. Factibilidad Técnica
El proyecto es viable ya que se cuentan con las herramientas técnicas necesarias para poder
desarrollar el prototipo de sistema de control de acceso como lo son el hardware,
software y los sistemas de interconexión que hacen posible su funcionamiento, a
continuación el detalle de cada uno de estos aspectos técnicos:
Hardware
Las herramientas de trabajo para el desarrollo del proyecto son las apropiadas para
implementar un sistema tecnológico como el propuesto, ya que se cuenta con los
siguientes equipos de cómputo y hardware
1 computadores Dell Inspiron R14 con:
Procesador Intel Core i3-M370.
Linux Ubuntu 14.04 LTS de 64Bit.
Pantalla 14.0" High Definition (720p) LED.
Disco duro SATA de 320 GB (5400 rpm).
Unidad combo DVD+/-RW.
Memoria 3 GB Dos canales SDRAM DDR3 a 1333 MHz.
1 computador Dell Inspiron 1420 con:
Linux Ubuntu 12.0 LTS 32 bits.
Procesador Intel core 2 Duo de 2.4 GHz.
Disco duro SATA de 160 GB.
Memoria 2 GB Dos canales SDRAM DDR3.
Unidad combo DVD+/-RW.
1 tarjeta RASPBERRY PI modelo B
512 MB of RAM.
Dos puertos USB.
Un puerto 100mb Ethernet.
Procesador 700 MHz (Familia ARM11 con set de instrucciones ARMv6).
GPU Broadcom VideoCore IV de 250 MHz.
Dos puertos USB 2.0.
Dos salidas de video Compuesta por una RCA (PAL and NTSC) y un puerto HDMI .
Salida de audio con Jack de 3.5 mm.
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 31
Interconexión
Para la conexión de red se cuenta con un Switch de 8 puertos marca Encore de referencias
ENH908-NWY, con conectividad de 10/100 Mbps, detección automática de
velocidad y soporte full-duplex. Los equipos de cómputo y hardware que
componen el sistema tienen puertos de conexión Ethernet lo que permite una
adecuada conexión de red para realizar la transmisión de información.
Software
Se cuenta con el software que logra una dualidad de tipo lógico y gráfico que permite
cumplir con todos los requerimientos de diseño e implementación que el proyecto
exige. Dicho Software está compuesto por el IDE NetBeans 7.3, para el desarrollo
de las interfaces y lógica del sistema, El motor de Base de datos No SQL donde se
almacena la información requerida por el Sistema para su funcionamiento el
Sistema operativo Ubuntu 14.04 LTS donde se ejecutara la aplicación.
1.13.2. Factibilidad Operativa
El Prototipo de Sistema de Control de Acceso con Tecnologías Libres, requiere para su
operación de un administrador del sistema y un directorio activo además requiere
que los usuarios de la organización estén registrados en el directorio activo. Los
anteriores requisitos se pueden cumplir lo que hace factible el proyecto en su parte
operativa.
1.13.3. Factibilidad Legal
Se cuenta con el completo licenciamiento del software requerido para el proyecto
(compuesto por Equipos con sistema operativo Linux , Netbeans IDE 7.0 y Mongo
DB 3.0) y se trabajará teniendo en cuenta las leyes que rigen la normatividad y
ética profesional inherente a la Ingeniería en Telemática, lo anterior permite
establecer que el proyecto cuenta con un marco legal el cual lo hace factible.
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 32
1.13.4. Factibilidad Económica
Gastos de Software.
Licencia Netbeans IDE 7.3 $ 0
Licencia MongoDB 3.0 $ 0
Licencia Ubuntu 14.04 LTS $ 0
Licencia Ubuntu 12.04 LTS $ 0
Licencia Centos OS $ 0
Licencia OpenLDAP $ 0
Gastos de Hardware
Dell Inspiron R14 $ 1.050.000
Dell Inspiron 1420 $ 980.000
Raspberry Pi Model B $ 140.000
Recurso Humano (por hora)
Desarrolladores x 2 recursos $ 30.000
Asesor Técnico $ 50.000
Servicios Públicos (por 4 meses)
Teléfono $ 150.000
Energía Eléctrica $ 200.000
Otros gastos
2 Resmas de Papel: $ 26.000
5 DVD: $ 15.000
Fotocopias: $ 20.000
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 33
Transporte: $ 200.000
Internet: $ 300.000
Los gastos operativos del proyecto evidencian que no hay costos asociados al
licenciamiento, lo que permite establecer que el sistema no va a poseer ningún
costo asociado al licenciamiento del software o hardware que lo componen. Por lo
anterior el proyecto es factible económicamente.
1.14. Riesgos del Proyecto
1.14.1.Estrategias del riesgo pre activo. A continuación se encuentra la tabla que contiene los riesgos pre activos.
Tabla 1 Riesgos pre activos
CATEGORÍA PREGUNTAS RIESGO
Requerimientos ¿Los requerimientos identificados al
iniciar el proyecto han sido los mismos a
lo largo de su desarrollo?
Cambiar los requerimientos a
mitad del proyecto puede
causar pérdida de tiempo y de
trabajo.
Equipo de trabajo
¿Los integrantes del equipo de trabajo
presentan problemas que los obligue a
salir temporal o permanentemente del
proyecto?
- Retraso en el tiempo
estimado para la finalización
del proyecto.
Tecnología ¿Se han tenido en cuenta las herramientas
de software con que cuenta la entidad?
- Desarrollar un producto que
no se pueda ajustar a las
herramientas con las que
cuenta el cliente.
Usuarios
¿Se han identificado completamente a los
usuarios finales del sistema?
- Podrían aparecer al finalizar
el proyecto nuevas tareas que
no estaban estipuladas que
obliguen a la modificación del
trabajo realizado.
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 34
¿El resultado del proyecto es familiar y
fácil de comprender para los usuarios
finales del sistema?
¿Tienen los usuarios finales alguna
herramienta en donde apoyarse en caso de
dudas o inquietudes?
- Los Usuarios finales no
podrían entender el manejo y
acceso al sistema, lo que
produciría un rechazo a este.
- El no proporcionar a los
usuarios las ayudas necesarias
para operar el sistema puede
provocar rechazo hacia él o
bien no aprovecharlo al
máximo.
Fuente: Adaptado de: Varas, Marcela. Gestión de Proyectos de Desarrollo de Software.
Departamento de Ingeniería Informática y Ciencias de la Computación Facultad de Ingeniería
Universidad de Concepción. Chile 2000. 81p.
1.14.2. Consecuencias del riesgo
Tabla 2 Consecuencias del riesgo
RIESGO CONSECUENCIA
Cambiar los requerimientos a mitad
del proyecto puede causar pérdida de
tiempo y de trabajo.
Además de significar pérdida de tiempo, el trabajo realizado
podría quedar desechado, y además se requerirá más tiempo
para volver a identificar las necesidades e implementarlas,
por consiguiente el retraso en la entrega del proyecto.
Retraso en el tiempo estimado para
la finalización del proyecto.
Descontento por parte del cliente, quien podría perder el
interés en el proyecto y dejar de apoyarlo.
Desarrollar un producto que no se
pueda ajustar a las herramientas con
las que cuenta el cliente.
Descontento por parte del cliente, quien podría perder el
interés hacia el sistema.
Podrían aparecer al finalizar el
proyecto nuevas tareas que no
estaban estipuladas que obliguen a la
modificación del trabajo realizado.
Requerir más tiempo para identificar las nuevas necesidades
e implementarlas en el trabajo ya hecho, retrasando la
entrega del proyecto.
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 35
Los Usuarios finales no podrían
entender el manejo y acceso al
sistema, lo que produciría un rechazo
a este.
Descontento por parte del cliente, quien podría rechazar
totalmente el sistema y volver a su antigua forma de trabajo.
Fuente: Adaptado de: Varas, Marcela. Gestión de Proyectos de Desarrollo de Software.
Departamento de Ingeniería Informática y Ciencias de la Computación Facultad de Ingeniería
Universidad de Concepción. Chile 2000. 81p.
1.14.3. Probabilidad e impacto de riesgo
Tabla 3 Probabilidad e impacto de riesgo
RIESGO PROBABILIDAD DE QUE
OCURRA (100%)
IMPACTO
(1 - 5)
Cambiar los requerimientos a mitad del
proyecto puede causar pérdida de tiempo y de
trabajo.
10% 4
Retraso en el tiempo estimado para la
finalización del proyecto.
40%
4
Desarrollar un producto que no se pueda
ajustar a las herramientas con las que cuenta
el cliente.
10% 3
Podrían aparecer al finalizar el proyecto
nuevas tareas que no estaban estipuladas y
obligar la modificación del trabajo realizado.
25% 3
Los Usuarios finales no podrían entender el
manejo y acceso al sistema, lo que produciría
un rechazo a este.
10%
2
El no proporcionar ayudas al usuario sobre 10% 3
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 36
como operar el producto puede provocar
rechazo hacia él o bien no aprovecharlo al
máximo.
TOTAL 17.5% 3.16%
Fuente: Adaptado de: Varas, Marcela. Gestión de Proyectos de Desarrollo de Software.
Departamento de Ingeniería Informática y Ciencias de la Computación Facultad de Ingeniería
Universidad de Concepción. Chile 2000. 81p.
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 37
2. FASE DE DEFINCIÓN
2.1. Requerimientos
2.1.1. Requerimientos Funcionales
• El sistema debe poder gestionar las zonas de acceso según usuarios.
• El sistema debe contar una interfaz gráfica para su administración.
• Se requiere que el sistema funcione de forma distribuido, soportando la falta de conexión de la
red.
• El sistema debe permitir la consultar de información de los usuarios registrados en un directorio
LDAP.
• Se requiere que el sistema permita administrar dispositivos.
• Se requiere que el sistema registre eventos relacionados con el acceso de los usuarios.
• Se requiere que el sistema permita generar reglas de acceso de los usuarios o grupos sobre los
dispositivos o zonas.
• Se requiere que el sistema registre los cambios en las reglas de acceso de los usuarios.
• Se requiere que el sistema permita consultar la información de los grupos de usuarios en un
directorio LDAP.
• Se requiere que el sistema implemente un protocolo de comunicación seguro.
2.1.2. Requerimientos No funcionales
• Se requiere que el sistema funcione sobre Raspberry Pi.
• Se requiere que no tenga ninguna licencia propietaria para la operación.
• Se requiere que el sistema haga uso de las tecnologías libres que existen en el mercado.
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 38
2.2. Historias de Usuario. A continuación se presentan las historias de Usuarios que componen el Prototipo de Sistema de
control de Acceso, estas Historias de usuarios son el insumo para el desarrollo de la solución
tecnológica.
2.2.1. Definiciones
Unidad: Dispositivo Raspberry Pi configurado para funcionar dentro del sistema.
Sistema Central: Aplicativo el cual se encarga de comunicarse con las unidades del sistema a
modo de fuente de información para el sistema, también se encarga de hacer las consultas al
directorio LDAP.
Directorio LDAP: servicio que implemente un árbol LDAP donde se almacenen los datos de los
usuarios que hacen parte del sistema.
Regla de Acceso: Conjunto de información que identifica una política de acceso o denegación del
mismo y que se encuentra guardada en el sistema central.
Evento: Todo acción efectuada sobre la unidad que modifica su estado inicial sea por interacción
de con los usuarios del sistema o por un cambio interno en su funcionamiento.
2.2.2. IDH-1 Fallas en la conexión de red
Funcionamiento: Cuando por algún motivo se pierde conexión con el sistema central, cada unidad
debe estar en la capacidad de funcionar de forma individual de tal manera que permita ser
utilizadas por los usuarios del sistema:
Resultado: La unidad que se encuentre fuera de línea permitirá acceso a los usuarios que tengan los
permisos correspondientes para dicho punto de acceso. En caso que el usuario no tenga los
permisos necesarios la unidad negara el acceso y procederá a generar un evento de alerta que
será guardado de forma local, Cuando el sistema se encuentre de nuevo en línea, los datos
locales de los eventos se sincronizarán con el sistema central.
Escenarios:
Número de Escenario: R1-1.
Criterio de Aceptación Usuario con permisos logra acceder.
Contexto: Unidad sin conexión de red.
Evento: El usuario procede a realizar el proceso de
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 39
acceso usando el método de identificación
determinado para la unidad.
Funcionamiento La unidad válida en sus reglas de acceso local
que el usuario tiene los permisos requeridos y
procede a dar acceso.
Número de Escenario: R1-2.
Criterio de Aceptación Usuario sin permisos no logra acceder.
Contexto: Unidad sin conexión de red.
Evento:
El usuario procede a realizar el proceso de
acceso usando el método de identificación
determinado para la unidad.
Funcionamiento
La unidad válida en sus reglas de acceso
local que el usuario no tiene los permisos
requeridos y procede a negar el acceso.
Número de Escenario: R1-3.
Criterio de Aceptación La unidad sincroniza su información con el
sistema central.
Contexto: Unidad retoma la conexión con el sistema
central y vuelve estar en línea.
Evento:
La unidad retoma la conexión con el sistema
central, procede a sincronizar la información
que guardo de forma local mientras se
encontraba fuera de línea.
Funcionamiento
El sistema central y la unidad comparten la
misma información actualizada sobre los
eventos de acceso.
Número de Escenario: R1-4.
Criterio de Aceptación La unidad se encuentra fuera de línea.
Contexto: La unidad pierde conexión con el sistema
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 40
central
Evento:
La unidad identifica que se encuentra sin
conexión al sistema central y procede a
registrar de forma local eventos de acceso.
Funcionamiento
La unidad entra a funcionar en el modo fuera
de línea, utiliza su base de datos local para
registrar los eventos
Número de Escenario: R1-5.
Criterio de Aceptación La unidad procede a denegar el acceso a
todos los usuarios.
Contexto: La unidad excede el tiempo máximo que
puede estar fuera de línea.
Evento:
La unidad supera el tiempo máximo
establecido para funcionar fuera de línea,
procede a entrar en modo “suspendido”
donde solo le permite acceso a los usuarios
que se encuentren cobijados bajo la regla de
acceso que permite el acceso a todas las
zonas del sistema.
Funcionamiento
La unidad no permitirá el acceso a ningún
usuario que se encuentre por fuera de la regla
de acceso a todas las zonas del sistema hasta
que se encuentre de nuevo en línea.
Número de Escenario: R1-6.
Criterio de Aceptación
El sistema central informa que una unidad ha
superado el tiempo máximo en que puede
encontrarse fuera de línea
Contexto: La unidad excede el tiempo máximo en que
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 41
puede estar fuera de línea.
Evento:
La unidad supera el tiempo máximo
establecido para funcionar fuera de línea, el
sistema central procede a generar un evento
indicando la situación actual de la unidad.
Funcionamiento El sistema cuenta con el registro de la falla en
la conexión con la unidad
2.2.3. IDH-2 Almacenamiento de Eventos
Funcionamiento: Cuando el usuario o el sistema interactúan con la unidad, esta debe generar
eventos que serán persistidos por el sistema central
Resultado: La unidad debe generar un evento por cada acceso garantizado o denegado a los
usuarios, errores de conexión con el sistema central, actualización de su copia local de
información y registro de uso de la unidad por parte de los usuarios.
Escenarios:
Número de Escenario: R2-1.
Criterio de Aceptación La unidad genera un evento cuando se
garantiza el acceso al usuario que lo solicita
Contexto: Usuario con permisos solicita acceso.
Evento: El usuario procede a realizar el proceso de
acceso.
Funcionamiento
La unidad valida que el usuario tenga
permiso de acceso con sus reglas de acceso
locales, guarda el registro localmente.
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 42
Número de Escenario: R2-2.
Criterio de Aceptación La unidad genera un evento cuando se niega
el acceso al usuario que lo solicita.
Contexto: Usuario sin permisos solicita acceso
Evento: El usuario procede a realizar el proceso de
ingreso.
Funcionamiento
La unidad valida que el usuario tenga
permiso de acceso con sus reglas de acceso
locales, guarda el registro localmente.
Número de Escenario: R2-3.
Criterio de Aceptación La unidad genera un evento de acceso.
Contexto: Unidad en línea con el sistema central.
Evento:
La unidad otorga o niega el acceso a un
usuario y genera un evento de acceso que se
envía al sistema central para que sea
persistido.
Funcionamiento
La unidad envía la información del evento al
sistema central quien almacenará la
información del evento generado.
Número de Escenario: R2-4.
Criterio de Aceptación La unidad genera un evento de acceso.
Contexto: Unidad en fuera de línea con el sistema
central.
Evento:
La unidad pierde la conexión con el sistema
central, a su vez se genera un evento cuando
otorga o niega el acceso a un usuario.
Funcionamiento
La unidad guarda la información en su base
de datos loca, una vez vuelva a estar en línea
con el sistema envía la información de los
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 43
eventos generados durante el tiempo en que
se encontró fuera de línea al sistema central
,quien almacenará la información del evento
generado.
2.2.4. IDH-3 Reglas de Acceso
Funcionamiento: Cuando el usuario administrador realiza cambios en el sistema, este debe guardar
registro en el almacenamiento central
Resultado: El sistema debe guardar un registro por cada cambio en la configuración por cada uno
de los dispositivos, zonas o reglas. Las reglas serán definidas en modo descendente, donde se
aplica la regla que primero se encuentre. Las reglas identifican quién (usuario o grupo) participa
en la regla, a dónde se dirige la regla (dispositivo o zona), cuando actúa la regla (siempre o por
horario) y qué se quiere lograr (permitir o denegar) a modo de configuración de políticas de
firewall.
Escenarios:
Número de Escenario: R3-1.
Criterio de Aceptación El sistema guarda el registro del cambio
realizado.
Contexto: El usuario administrador modifica una regla
de acceso.
Evento: El usuario administrador procede a realizar
un cambio en una regla de acceso.
Funcionamiento
En el momento en que la unidad esté en línea
el sistema procede a enviar las reglas
actualizadas de acceso a la unidad
Número de Escenario: R3-2.
Criterio de Aceptación El sistema guarda el registro de la regla
creada.
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 44
Contexto: El usuario administrador crea una regla de
acceso.
Evento: El usuario administrador procede a crear una
regla de acceso
Funcionamiento
En el momento en que la unidad esté en línea
el sistema procede a enviar las nuevas reglas
de acceso a la unidad
Número de Escenario: R3-3.
Criterio de Aceptación El sistema elimina la regla y guarda el
registro.
Contexto: El usuario administrador elimina una regla de
acceso.
Evento: El usuario administrador procede a eliminar
una regla de acceso.
Funcionamiento
En el momento en que la unidad esté en línea
el sistema procede a enviar las reglas
actualizadas de acceso a la unidad.
2.2.5. IDH-4 Interfaz Gráfica De Administración
Funcionamiento: El administrador del sistema debe contar con una herramienta de gestión del
sistema con una interfaz gráfica que le permita realizar las operaciones de administración sobre
las unidades, las zonas y reglas de acceso.
Resultado: El sistema tendrá la capacidad de ser monitoreado y administrado por un usuario
administrador mediante una interfaz gráfica en un entorno Web.
Escenarios:
Número de Escenario: R4-1.
Criterio de Aceptación El Usuario Administrador podrá consultar las
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 45
unidades en el sistema.
Contexto: Usuario con permisos administra las unidades
del sistema
Evento:
El usuario procede a ingresar al apartado de
la administración de las unidades y procede a
consultar las unidades
Funcionamiento La unidad procede a generar una vista con las
unidades configuradas y su estado actual.
Número de Escenario: R4-2.
Criterio de Aceptación El Usuario Administrador podrá agregar una
nueva unidad al sistema.
Contexto: Usuario con permisos administra las unidades
del sistema.
Evento:
El usuario procede a ingresar al apartado de
la administración de las unidades y procede a
configurar una nueva unidad.
Funcionamiento
La unidad procede a generar un evento de
configuración inicial informando el estado de
la configuración
Número de Escenario: R4-3.
Criterio de Aceptación El Usuario Administrador podrá administrar
las reglas de acceso
Contexto: Usuario con permisos administra las reglas
de acceso.
Evento:
El usuario procede a ingresar al apartado de
la administración de las reglas de acceso,
consulta, crea, modifica o elimina una regla
de acceso.
Funcionamiento El sistema realiza la consulta, creación,
modificación o eliminación de la regla de
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 46
acceso informando de los cambios a las
unidades afectadas.
Número de Escenario: R4-4.
Criterio de Aceptación El Usuario Administrador podrá Administrar
las zonas de acceso.
Contexto: Usuario con permisos administra las zonas de
acceso
Evento:
El usuario procede a ingresar al apartado de
la administración de las zonas de acceso y
consulta, crea, modifica o elimina las zonas
de acceso.
Funcionamiento
El sistema realiza la consulta, creación,
modificación o eliminación de la zona de
acceso informando de los cambios a las
unidades afectadas.
2.3. Cronograma El Prototipo de Sistema de Control de Acceso Tiene un cronograma estimado de 86 días
comenzando el lunes 13 de abril del 2015 y terminando el 13 de agosto de 2015, para un total de
4 meses calendario. Las actividades que componen el proyecto se detallan a continuación:
Nombre de tarea Duración Comienzo Fin
Análisis 15 días lun 13/04/15 vie 01/05/15
Identificación de Tareas 1 día lun 13/04/15 lun 13/04/15
Determinación de la fecha de entrega y la funcionalidad de una o más versiones
1 día mar 14/04/15 mar 14/04/15
Selección de la versión más adecuada para desarrollo inmediato
2 días mié 15/04/15 jue 16/04/15
Trazado de los “paquetes del producto” (objetos) sobre los elementos del backlog de la versión elegida.
3 días vie 17/04/15 mar 21/04/15
Selección del equipo o equipos para desarrollar la nueva versión.
2 días mié 22/04/15 jue 23/04/15
Evaluación y control adecuado de los riesgos 2 días vie 24/04/15 lun 27/04/15
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 47
Estimación del coste de la versión, incluyendo desarrollo, material, marketing, formación y despliegue
3 días mar 28/04/15 jue 30/04/15
Conformidad de la dirección y financiación del proyecto
1 día vie 01/05/15 vie 01/05/15
Diseño y Arquitectura 10 días lun 04/05/15 vie 15/05/15
Revisión de los elementos de las tareas incluidos en la versión
1 día lun 04/05/15 lun 04/05/15
Identificación de los cambios necesarios para implementar el backlog
2 días mar 05/05/15 mié 06/05/15
Análisis del dominio para incluir los requisitos que incluye el desarrollo mejora o actualización.
1 día jue 07/05/15 jue 07/05/15
Acotar la arquitectura del sistema para apoyar el nuevo contexto y necesidades
1 día vie 08/05/15 vie 08/05/15
Identificar problemas del desarrollo o modificaciones.
3 días lun 11/05/15 mié 13/05/15
Reunión de revisión de diseño. Cada equipo presenta los cambios para implementar los elementos del backlog, e identificar posibles reasignaciones
2 días jue 14/05/15 vie 15/05/15
Desarrollo 57 días lun 18/05/15 mar 04/08/15
Sprint 1 25 días lun 18/05/15 vie 19/06/15
Planeación 1 2 días lun 18/05/15 mar 19/05/15
Desarrollo 1 15 días mié 20/05/15 mar 09/06/15
Envoltura 1 2 días mié 10/06/15 jue 11/06/15
Revisión 1 4 días vie 12/06/15 mié 17/06/15
Ajuste 1 2 días jue 18/06/15 vie 19/06/15
Sprint 2 18 días lun 22/06/15 mié 15/07/15
Planeación 2 2 días lun 22/06/15 mar 23/06/15
Desarrollo 2 10 días mié 24/06/15 mar 07/07/15
Envoltura 2 1 día mié 08/07/15 mié 08/07/15
Revisión 2 3 días jue 09/07/15 lun 13/07/15
Ajuste 2 2 días mar 14/07/15 mié 15/07/15
Sprint 3 14 días jue 16/07/15 mar 04/08/15
Planeación 3 2 días jue 16/07/15 vie 17/07/15
Desarrollo 3 6 días lun 20/07/15 lun 27/07/15
Envoltura 3 1 día mar 28/07/15 mar 28/07/15
Revisión 3 3 días mié 29/07/15 vie 31/07/15
Ajuste 3 2 días lun 03/08/15 mar 04/08/15
Cierre 4 días mié 05/08/15 lun 10/08/15
Implementación 3 días mié 05/08/15 lun 08/08/15
Retrospectiva 1 día mié 09/08/15 lun 10/08/15
Total Tiempo Del Proyecto 86 días lun 13/04/15 lun 10/08/15
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 48
Ilustración 6 Cronograma de actividades.
Fuente: Los autores
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 49
3. FASE DE DESARROLLO
3.1. Diagramas de Flujo Funcional Los diagramas de Flujo Funcional permiten visualizar el flujo lógico del sistema, la forma en que el
usuario interactúa con las unidades y a su vez, la forma en que la unidad se comunica con el
sistema central.
3.1.1. Solicitud de Acceso
Ilustración 7 Flujo Funcional Solicitud de Acceso.
Fuente: Los autores.
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 50
3.1.2. Generar Evento
Ilustración 8 Flujo funcional Generar Evento.
Fuente: Los autores.
3.1.3. Modificar Regla de Acceso
Ilustración 9 Flujo funcional Modificar Regla de Acceso.
Fuente: Los autores.
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 51
3.1.4. Agregar Una Unidad Al Sistema
Ilustración 10 Flujo funcional Agregar Una Unidad Al Sistema.
Fuente: Los autores.
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 52
3.2. BackLog de Actividades Dentro de las actividades de desarrollo de un proyecto bajo la metodología Scrum se hace necesario
priorizar las tareas con los tiempos utilizados para cada uno de ellas. Es por eso que en la fase de
desarrollo del presente proyecto se acordaron 3 Sprints con 2 recursos de desarrollo, la
priorización de las tareas se detallan en la siguiente tabla:
ID Descripción
1 Configurar entorno de integración
2 Crear versión del ejecutable
3 Revisar comunicación entre dispositivos
4 Configurar servidor central Y Directorio LDAP
5 Revisar Escenarios
Sprint 1 Desarrollo del core del sistema
20 R4-2 Agregar unidad al Sistema
19 R4-1 Consultar unidades del Sistema
17 R3-2 Creación de reglas de acceso
6 R1-1 Usuario con permisos accede (unidad fuera de línea)
7 R1-2 Usuario sin permisos no accede (unidad fuera de línea)
8 R1-3 Unidad Sincroniza información con el servidor central
Sprint 2 Desarrollo de los Eventos de acceso al sistema
15 R2-4 Unidad genera evento (fuera de línea)
12 R2-1 Unidad genera evento al garantizar acceso (fuera de línea)
13 R2-2 Unidad genera evento al denegar acceso (fuera de línea)
9 R1-4 Unidad almacena eventos localmente
14 R2-3 Unidad genera un evento de acceso (en línea)
Release 1 Versión Estable
Sprint 3 Administración del Sistema
22 R4-4 Administración de zonas de acceso
21 R4-3 Administrar Reglas de Acceso
16 R3-1 Edición de una regla de acceso
18 R3-3 Eliminación de una regla de acceso
11 R1-6 Sistema genera evento de alarma (unidad excede tiempo fuera de línea)
10 R1-5 Unidad niega acceso a todos usuarios (unidad excede tiempo fuera de línea)
Release 2 Versión Funcional del Sistema
Tabla 4 BackLog general del proyecto.
Fuente: Los autores.
3.3. Sprints El desarrollo del sistema se dividió en 3 fases o Sprints como se puede observar en el backlog
general, cada Sprint tiene una lista de actividades y unos esfuerzos en horas comprometidos, el
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 53
resultado de cada Sprint es una iteración en el ciclo de desarrollo, a continuación se detallan los
esfuerzos para cada uno de los Sprints del proyecto.
3.3.1. Sprint 1 Desarrollo del Core del sistema
El primer Sprint pretendió dar inicio al desarrollo de los componentes que conforman el Core del
sistema, dentro de este sprint se incurrieron es sobre esfuerzos de tiempo por parte de los
recursos, lo que se consideró anormal al comenzar esta etapa del proyecto, la siguiente tabla
demuestra los esfuerzos en horas de este Sprint:
Tabla 5 Esfuerzos Sprint 1.
Fuente: Los autores.
Los sobre esfuerzos de este primer sprint se agruparon en los primeros días fueron de 56 horas lo
que genera una alarma en cuanto a la programación de los esfuerzos, en los siguientes Sprints
puede observarse como fue corregido este error.
ID Historia/Tarea
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
Total Esfuerzos 27 19 15 17 26 17 13 11 14 10 4 6 10 11 4 4
Configurar entorno de integración 2 0 0 1 1 4
Crear versión del ejecutable 2
Revisar comunicación entre dispositivos 4 8 6 4 0 4 0 0 2 2 0 0 6
Configurar servidor central Y Directorio
LDAP8 8 4 3 4 5 5 6 6 4 0 0 5
Revisar Escenarios 2 2
IDH-1 Fallas en la conexión de red
R1-1Usuario con permisos accede (unidad
fuera de línea) 6 2 0 0 2
R1-2 Usuario sin permisos no accede (unidad
fuera de línea) 6 4
R1-3Unidad Sincroniza información con el
servidor central5 0 2 0 1
IDH-2 Almacenamiento de Eventos
R2-3 Unidad genera un evento de acceso (en
línea)4 0 2
IDH-3 Reglas de Acceso
R3-2 Creación de reglas de acceso 10 3 2 4 1
IDH-4 Interfaz Gráfica De Administración
R4-1 Consultar unidades del Sistema 8 2
R4-2 Agregar unidad al Sistema 5 0 3 6 5 4 2 0 0 0 0 6 0 5
Dias del Sprint/Esfuerzo en horas
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 54
Ilustración 11 Grafica de esfuerzo vs días del Sprint 1.
Fuente: Los autores.
3.3.2. Sprint 2 Desarrollo de los Eventos de acceso al sistema
El sprint 2 se planeó para ser ejecutado en 10 días. Durante ese tiempo se pudo observar como la
carga de desarrollo decreció, y los esfuerzos a través de los días llevaron a que estabilizar el
proceso de desarrollo, en la siguiente tabla se puede observar los esfuerzos diarios del sprint.
Tabla 6 Esfuerzos Sprint 2.
Fuente: Los autores.
27
19
15 17
26
17
13 11
14
10
4 6
10 11
4 4
0
5
10
15
20
25
30
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
Esfu
erz
o(h
ora
s)
Días
Esfuerzo en el Sprint
ID Historia/Tarea
0 1 2 3 4 5 6 7 8 9 10
Total Esfuerzos 15 16 14 14 13 11 12 10 11 10 9
Configurar entorno de integración 2 0 1
Crear versión del ejecutable 2
Revisar comunicación entre dispositivos 2 2 1 1 0 0 0 1 0 0 3
Configurar servidor central Y Directorio
LDAP3 1
Revisar Escenarios 2 2 0 0 0 2 0 2 2 0
IDH-1 Fallas en la conexión de red
R1-1Usuario con permisos accede (unidad
fuera de línea) 2 2
R1-2 Usuario sin permisos no accede (unidad
fuera de línea) 1 3
R1-4 Unidad almacena eventos localmente 6 8 2 2 0 0 4 8 4
R1-5 Unidad niega acceso a todos usuarios
(unidad excede tiempo fuera de línea)2 1
IDH-2 Almacenamiento de Eventos
R2-1 Unidad genera evento al garantizar
acceso (fuera de línea)8 5 0 0 1
R2-2 Unidad genera evento al denegar acceso
(fuera de línea)2 2
R2-3 Unidad genera un evento de acceso (en
línea)3 0 3 4 1 0 0 4
R2-4 Unidad genera evento (fuera de línea) 3 6 6 8
IDH-3 Reglas de Acceso
R3-2 Creación de reglas de acceso 3 2
Dias del Sprint/Esfuerzo en horas
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 55
En la siguiente figura se puede observar como los esfuerzos diarios tuvieron una tendencia a
estabilizarse al pasar los días, esto se encuentra acorde a las premisas de las metodologías agiles
de desarrollo, las cuales buscan que las cargas de desarrollo sean repartidas equitativamente a
través de los Sprints.
Ilustración 12 Grafica de esfuerzo vs días del Sprint 2.
Fuente: Los autores.
3.3.3. Sprint 3 Administración del Sistema
Durante el último Sprint se puede observar como la tendencia del esfuerzo en el desarrollo se
mantuvo con la misma tendencia que en el Sprint anterior, lo que indica que el proyecto entro en
una fase de estabilización, se cumplieron los objetivos de esta fase, y se produjo los
componentes de software necesarios para el funcionamiento del sistema. En la siguiente tabla se
muestran los esfuerzos del Sprint
15 16
14 14 13
11
12
10 11
10 9
0
2
4
6
8
10
12
14
16
18
0 1 2 3 4 5 6 7 8 9 10
Esfu
erz
o(h
ora
s)
Días
Esfuerzos en el Sprint
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 56
Tabla 7 Esfuerzos Sprint 3.
Fuente: Los Autores
Para el último sprint de la fase de desarrollo se puede observar como no hay cambios abruptos en
los esfuerzos a través de los seis días del sprint, la siguiente figura ilustra como al final del
Sprint los esfuerzos van disminuyendo una vez las tareas presentes en la anterior tabla son
completadas.
Ilustración 13 Grafica de esfuerzo vs días del Sprint 3.
Fuente: Los autores.
ID Historia/Tarea
0 1 2 3 4 5 6
Total Esfuerzos 16 14 13 13 12 10 8
Configurar entorno de integración 1
Crear versión del ejecutable 2
Revisar comunicación entre dispositivos 2 0 0 0 2
Configurar servidor central Y Directorio
LDAP2
Revisar Escenarios 2 4 8 4
IDH-1 Fallas en la conexión de red
R1-5 Unidad niega acceso a todos usuarios
(unidad excede tiempo fuera de línea)2
R1-6 Sistema genera evento de alarma
(unidad excede tiempo fuera de línea)3 0 0 2
IDH-3 Reglas de Acceso
R3-1 Edición de una regla de acceso 5 2 3 2 2
R3-3 Eliminación de una regla de acceso 4
IDH-4 Interfaz Gráfica De Administración
R4-3 Administrar Reglas de Acceso 4 6 4 2
R4-4 Administración de zonas de acceso 8 6 4
Dias del Sprint/Esfuerzo en horas
16
14 13 13
12
10
8
0
2
4
6
8
10
12
14
16
18
0 1 2 3 4 5 6
Esfu
erz
o(h
ora
s)
Días
Esfuerzos en el Sprint
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 57
3.4. Resumen de Esfuerzos Una vez concluidos los Sprints se cuenta con información suficiente para ser consolidada, los
tiempos gastados en cada una de los Sprints permite evidenciar el comportamiento y la eficiencia
de los recursos para llevar a cabo las tareas asignadas. En la siguiente tabla contiene los tiempos
utilizados durante cada sprint, también se puede ver el consolidado de esfuerzo (horas) para
llegar a la primera versión del producto.
ID Descripción Sprint # 1 2 3
1 Configurar entorno de integración 8 3 1
2 Crear versión del ejecutable 2 2 2
3 Revisar comunicación entre dispositivos 36 10 4
4 Configurar servidor central Y Directorio LDAP 58 4 2
5 Revisar Escenarios 4 10 18
Sprint 1 Desarrollo del core del sistema
20 R4-2 Agregar unidad al Sistema 36 0 0
19 R4-1 Consultar unidades del Sistema 10 0 0
17 R3-2 Creación de reglas de acceso 20 5 0
6 R1-1 Usuario con permisos accede (unidad fuera de línea) 10 4 0
7 R1-2 Usuario sin permisos no accede (unidad fuera de línea) 10 4 0
8 R1-3 Unidad Sincroniza información con el servidor central 8 0 2
Sprint 2 Desarrollo de los Eventos de acceso al sistema
15 R2-4 Unidad genera evento (fuera de línea) 0 23 0
12 R2-1 Unidad genera evento al garantizar acceso (fuera de línea) 0 14 0
13 R2-2 Unidad genera evento al denegar acceso (fuera de línea) 0 4 0
9 R1-4 Unidad almacena eventos localmente 0 34 0
14 R2-3 Unidad genera un evento de acceso (en línea) 6 15 0
Release 1 Versión Estable
Esfuerzo versión estable 208 132 29
Sprint 3 Administración del Sistema
22 R4-4 Administración de zonas de acceso 0 0 16
21 R4-3 Administrar Reglas de Acceso 0 0 18
16 R3-1 Edición de una regla de acceso 0 0 12
18 R3-3 Eliminación de una regla de acceso 0 0 4
11 R1-6 Sistema genera evento de alarma (unidad excede tiempo fuera de línea)
0 0 5
10 R1-5 Unidad niega acceso a todos usuarios (unidad excede tiempo fuera de línea) 0 3 2
Release 2 Versión Funcional del Sistema
Esfuerzo backlog completo 208 135 86
Tabla 8 BackLog general del proyecto con Esfuerzos.
Fuente: Los autores.
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 58
3.4.1. Esfuerzo primera versión estable
En la tabla anterior también existe un hito importante en el desarrollo de las actividades, el esfuerzo
requerido para tener una primera versión estable del “producto”, en siguiente figura se puede
observar cómo se cumple la premisa de la metodología ágil que fue seleccionada, la cuela
establece que el esfuerzo necesario para el desarrollo de los componentes decrece con el paso de
cada sprint.
Ilustración 14 Esfuerzo en horas antes de la versión estable.
Fuente: Los autores.
3.4.2. Esfuerzo total del proyecto
A continuación se puede ver el esfuerzo general que se requirió para poder llevar a cabo la fase de
desarrollo del proyecto. La figura nos indica como a través de las iteraciones de la fase de
desarrollo, los tiempos tienden a estabilizarse y eliminar los sobreesfuerzos que se presentaron
en la primera fase de desarrollo.
208
132
29
0
50
100
150
200
250
1 2 3
Esfu
erz
o (
ho
ras)
Sprint #
Esfuerzo versión Estable
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 59
Ilustración 15 Esfuerzo total del proyecto.
Fuente: Los autores.
3.5. Diagramas de Clases Dentro de la documentación necesaria para entender el desarrollo del prototipo de sistema de
control de acceso se encuentra los diagramas de clase, estos diagramas permiten ver la
implementación lógica de los componentes del software programado a nivel de cada clase
funcional. A continuación se encuentran los diagramas de clases según las capas del sistema.
3.5.1. Capa de Persistencia
Dentro de la capa de persistencia se encuentran todas las clases que representan los datos
almacenados en la Base de datos Mongo DB, estas clases representa la información del sistema
que viaja entre las diferentes capas que componen el proyecto, los diagramas de las clases de
esta capa se presentan a continuación.
208
135
86
0
50
100
150
200
250
1 2 3
Esfu
erz
o (
ho
ras)
Sprint #
Esfuerzo en todo el Backlog
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 60
Ilustración 16 Diagrama de clases de la capa de persistencia.
Fuente: Los autores.
3.5.2. Capa de Servicios
La capa de servicios permite que la capa de persistencia interactúe con las demás capas del sistema,
es el mediador de la información desde y hacia la base de datos, son accesibles desde cualquier
punto de la aplicación lo que permite tener una alta cohesión de las clases encargadas de las
operaciones en la Base de Datos, por esta razón fueron desarrolladas bajo el patrón Singleton el
cual asegura una sola instancia de la clase invocada sea cargada en la máquina virtual java y a su
vez pueda ser invocada desde cualquier punto del sistema, la siguientes figuras demuestran el
diagrama de clases para las clases que conforman la capa de servicio del sistema.
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 61
Ilustración 17 Diagrama de clases Capa de Servicios - parte 1.
Fuente: Los autores.
Ilustración 18 Diagrama de clases Capa de Servicios - parte 2.
Fuente: Los autores.
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 62
3.5.3. Capa de Control
En esta capa se encuentran las clases que controlan la lógica del sistema, por esta razón se
comunican con las clases de la capa de persistencia a través de las operaciones expuestas por la
capa de servicio, las clases que componen esta capa se observan a continuación.
Ilustración 19 Diagrama de clases Capa de Control.
Fuente: Los autores.
Existe un conjunto de clases que se encuentran en la capa de control cuya función se basas en
proveer varias operaciones de ayuda al sistema propiamente a interactuar con otros sistemas
como lo son el directorio LDAP y el Motor de Bases de Datos, el conjunto de clases está
compuesto por las siguientes clases.
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 63
Ilustración 20 Diagrama de clases utilitarias.
Fuente: Los autores.
3.6. Diseño de Interfaces Dentro del diseño del proyecto se encuentra un apartado de suma importancia, el diseño de las
interfaces con las que los usuarios van a interactuar, en este caso el usuario administrador será el
encargado de administrar los componentes del sistema, a continuación se encuentran los diseños
preliminares de las interfaces con las que el usuario administrador podrá modificar las
asociaciones entre unidades y usuarios, administrar las reglas de acceso, las zonas que
comprenden el sistema y el apartado de consulta de eventos generados.
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 64
Ilustración 21 Interfaz de Administración de unidades.
Fuente: Los autores.
Ilustración 22 Interfaz de administración para las reglas de acceso.
Fuente: Los autores.
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 65
Ilustración 23 Interfaz de consulta de eventos.
Fuente: Los autores
Ilustración 24 Interfaz de administración de las zonas.
Fuente: Los autores
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 66
3.7. Diccionario de Datos La tecnología seleccionada para almacenar los datos que conforman el aplicativo fue MongoDB,
debido a que es un motor de base de datos NoSql no existe una arquitectura relacional en los
datos almacenados, estos son almacenados en objetos con formato Json lo que permitió que los
objetos que componen la capa de persistencia en el sistema se puedan almacenar directamente en
la base datos. Un ejemplo de cómo MongoDB almacena un registro en su sistema se presenta a
continuación:
{
“_id” : “4da2c0e2e999fb56bf000002”
“title” : “Publicación sobre los efectos del cambio climatico”,
“body” : “Lorem ipsum dolor sit amet…”,
“ranking” : 108,
“tags” : [“MongoDB”, “NoSQL”, “Bases de datos”],
“published_at” : “2011-05-09T18:17:07-07:00”,
“author_info” : {
“_id” : “4dc8919331c0c00001000002”
“name” : “Carlos Paramio”
},
“liked_by” : [“4d7cf768e999fb67c0000001”, “4da34c62ba875a19d4000001”]
}
En el anterior ejemplo existe un campo identificador “_id” que es único y por defecto es adicionado
a todos los registros almacenados en MongoDB; Como se puede observar en el campo “tags”, un
registro también puede llevar un arreglo de datos, incluso estar compuesto por más objetos de
tipo Json como el caso del campo “author_info” que representa otra estructura, y es almacenada
como parte de una estructura mayor.
A continuación se encuentran los diccionarios de datos de las colecciones utilizadas en MongoDB
para almacenar la información del sistema.
ZoneDTO
Campo Tipo Descripción
zoneId String ID de la zona de acceso
unit_ids Array[String] Lista de los id de las
unidades que conforman la zona
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 67
Tabla 9 Diccionario de datos colección ZoneDTO.
Fuente: Los autores.
UserDTO
Campo Tipo Descripción
userId String ID del usuario en el
directorio LDAP
accessToken AccessToken Valor que identifica
al usuario.
userName String Nombre del usuario
como está registrado en el LDAP
Tabla 10 Diccionario de datos colección UserDTO.
Fuente: Los autores.
UnitDTO
Campo Tipo Descripción
Id String ID de la unidad de acceso
IP String IP de la unidad
name String Nombre de la unidad en el
sistema
status String estado actual de al unidad
lastCheck long Ultima fecha de
comunicación de la unidad
Tabla 11 Diccionario de datos colección UnitDTO.
Fuente: Los Autores
UnitDTO
Campo Tipo Descripción
Id String ID de la unidad de acceso
IP String IP de la unidad
name String Nombre de la unidad en el
sistema
status String estado actual de la unidad
lastCheck long Ultima fecha de
comunicación de la unidad
Tabla 12 Diccionario de datos colección UnitDTO.
Fuente: Los autores.
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 68
ConfigurationDTO
Campo Tipo Descripción
unitId String ID de la unidad de
acceso
confs Mapa<String,String>
Mapa de datos que contiene el nombre de la propiedad y el
valor de la configuración
Tabla 13 diccionario de datos colección ConfigurationDTO.
Fuente: Los autores.
AccessRuleDTO
Campo Tipo Descripción
idRule String Identificador de la regla de acceso
unit_ids Array[String] Lista de los id de las unidades que
conforman la zona
zone_ids Array[String] lista de los id de las zonas a las
que aplica la regla.
tokens Array[AccessToken]
Valor que identifica los
tokens habilitados para acceder.
description String Descripción de la regla de acceso
Tabla 14 Diccionario de datos colección AccessRuleDTO.
Fuente: Los autores.
EventDTO
Campo Tipo Descripción
type String Tipo de evento
time long fecha del evento
unit_id String ID de la unidad de acceso donde ocurrió el evento
user_id String ID del usuario que genero
el evento
description long Descripción adicional del
evento
Tabla 15 Diccionario de datos colección EventDTO.
Fuente: Los autores.
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 69
4. FASE DE IMPLEMENTACIÓN
4.1. Diagrama de Paquetes Dentro de los paquetes que componen el sistema se pueden destacar los paquetes que contienen el
core del sistema y los paquetes que conforman el punto de inicio del sistema, a continuación se
presentan los paquetes que conforman el sistema.
Ilustración 25 Diagrama de paquetes core del sistema.
Fuente: Los autores.
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 70
Ilustración 26 Diagrama de paquetes punto de inicio del sistema.
Fuente: Los autores.
4.2. Diagramas de Despliegue El diagrama de despliegue identifica los componentes de software necesarios para obtener la
funcionalidad del sistema, y las relaciones de dependencia de dichos componentes.
Ilustración 27 Diagrama de despliegue, componentes de software.
Fuente: Los autores.
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 71
4.3. Esquema Telemático del sistema El sistema al ser distribuido, tiene las características inherentes de los sistemas distribuidos, como
son:
débilmente acoplado: El sistema servidor puede ser instalado en un entorno de software
propietario y el sistema cliente puede ser adaptado a cualquier dispositivo con procesador ARM.
No existe reloj común: el sistema servidor y los dispositivos al funcionar en equipos
independientes no poseen reloj global.
Los elementos de Entrada y Salida están asociados a cada procesador por sistema.
Las fallas en los dispositivos o en la red no provoca una falla en el sistema central, y se puede
crear un sistema de alta disponibilidad del software servidor.
Ilustración 28 Diagrama Telemático del sistema.
Fuente: Los autores.
Adicionalmente, el sistema exhibe los siguientes componentes de los sistemas distribuidos: En
Comunicación el sistema implementa sokets, y utiliza la arquitectura SOA. En distribución de
nombres, el sistema puede usar DNS, e implementa el directorio LDAP para autenticación de
usuarios. Para el uso de memoria el sistema utiliza el esquema de variables compartidas. Los
Servicios de Sincronización se realizan usando sincronización de relojes por NTP, manejo de
transacciones por mensajes, identificación por certificado SSL y seguridad en comunicaciones
con SSL/TLS. Para los Servicios de Tolerancia a falla se implementó un esquema de replicación
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 72
de datos, actualización de las réplicas, autenticación de dispositivos, negación de servicios a
dispositivos o usuarios no autorizados, e implementación de firewall por iptables.
Ya que el sistema se comunica enteramente por TCP/IP, la implementación de la capa SSL muestra
el aspecto de aseguramiento de la comunicación con protocolo seguro que hace parte de la
seguridad en redes y del sistema de gestión de seguridad de la información.
La creación del protocolo de comunicaciones requiere conceptos específicos de teoría de la
información, y su diseño es resultado de la aplicación de las técnicas de la Ingeniería de
software.
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 73
5. FASE DE CIERRE
5.1. Pruebas del Sistema Durante cada uno de los Sprints del proyecto se encontraba un segmento de tiempo dedicado a la
revisión de los escenarios propios de las historias de usuario designadas para ser desarrolladas en
un sprint determinado, de encontrarse fallidas, las historias de usuarios eran prolongadas como
tareas en el siguiente Sprint, a continuación se encuentran las pruebas realizadas dentro de cada
Sprint.
5.1 Pruebas Sprint 1
Número de Escenario: R1-1. Resultado de la Prueba
Criterio de Aceptación Usuario con permisos logra
acceder. Fallida
Contexto: Unidad sin conexión de red. Observaciones
Evento:
El usuario procede a realizar
el proceso de acceso usando
el método de identificación
determinado para la unidad.
EL usuario logra acceder la primera vez, pero las siguientes ocasiones el sistema le niega el acceso
Funcionamiento
La unidad válida en sus reglas
de acceso local que el usuario
tiene los permisos requeridos
y procede a dar acceso.
Se prolonga el desarrollo al sprint 2.
Número de Escenario: R1-2. Resultado de la Prueba
Criterio de Aceptación Usuario sin permisos no logra
acceder. Fallida
Contexto: Unidad sin conexión de red. Observaciones
Evento:
El usuario procede a realizar
el proceso de acceso usando
el método de identificación
determinado para la unidad.
EL usuario logra acceder la primera vez, pero las siguientes ocasiones el sistema le niega el acceso
Funcionamiento
La unidad válida en sus reglas
de acceso local que el usuario
no tiene los permisos
requeridos y procede a negar
el acceso.
Se prolonga el desarrollo al sprint 2.
Número de Escenario: R1-3. Resultado de la Prueba
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 74
Criterio de Aceptación
La unidad sincroniza su
información con el sistema
central.
Fallida
Contexto:
Unidad retoma la conexión
con el sistema central y
vuelve estar en línea.
Observaciones
Evento:
La unidad retoma la conexión
con el sistema central,
procede a sincronizar la
información que guardo de
forma local mientras se
encontraba fuera de línea.
Se presentan errores de comunicación entre las unidades y el servidor
Funcionamiento
El sistema central y la unidad
comparten la misma
información actualizada sobre
los eventos de acceso.
Se prolonga el desarrollo al sprint 3.
Número de Escenario: R3-2. Resultado de la Prueba
Criterio de Aceptación El sistema guarda el registro
de la regla creada. Fallida
Contexto: El usuario administrador crea
una regla de acceso. Observaciones
Evento:
El usuario administrador
procede a crear una regla de
acceso
El sistema central no sincroniza las nuevas reglas de acceso con las unidades
Funcionamiento
En el momento en que la
unidad esté en línea el
sistema procede a enviar las
nuevas reglas de acceso a la
unidad
Se prolonga el desarrollo al sprint 2
Número de Escenario: R4-1. Resultado de la Prueba
Criterio de Aceptación
El Usuario Administrador
podrá consultar las unidades
en el sistema.
Exitosa
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 75
Contexto:
Usuario con permisos
administra las unidades del
sistema
Observaciones
Evento:
El usuario procede a ingresar
al apartado de la
administración de las
unidades y procede a
consultar las unidades
Funcionamiento
La unidad procede a generar
una vista con las unidades
configuradas y su estado
actual.
Número de Escenario: R4-2. Resultado de la Prueba
Criterio de Aceptación
El Usuario Administrador
podrá agregar una nueva
unidad al sistema.
Exitosa
Contexto:
Usuario con permisos
administra las unidades del
sistema.
Observaciones
Evento:
El usuario procede a ingresar
al apartado de la
administración de las
unidades y procede a
configurar una nueva unidad.
Funcionamiento
La unidad procede a generar
un evento de configuración
inicial informando el estado
de la configuración
5.1.1 Pruebas Sprint 2
Número de Escenario: R1-1. Resultado de la Prueba
Criterio de Aceptación Usuario con permisos logra
acceder. Exitosa
Contexto: Unidad sin conexión de red. Observaciones
Evento:
El usuario procede a realizar
el proceso de acceso usando
el método de identificación
determinado para la unidad.
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 76
Funcionamiento
La unidad válida en sus reglas
de acceso local que el usuario
tiene los permisos requeridos
y procede a dar acceso.
Número de Escenario: R1-2. Resultado de la Prueba
Criterio de Aceptación Usuario sin permisos no logra
acceder. Exitosa
Contexto: Unidad sin conexión de red. Observaciones
Evento:
El usuario procede a realizar
el proceso de acceso usando
el método de identificación
determinado para la unidad.
Funcionamiento
La unidad válida en sus reglas
de acceso local que el usuario
no tiene los permisos
requeridos y procede a negar
el acceso.
Número de Escenario: R1-4. Resultado de la Prueba
Criterio de Aceptación La unidad se encuentra fuera
de línea. Exitosa
Contexto: La unidad pierde conexión
con el sistema central Observaciones
Evento:
La unidad identifica que se
encuentra sin conexión al
sistema central y procede a
registrar de forma local
eventos de acceso.
Funcionamiento
La unidad entra a funcionar
en el modo fuera de línea,
utiliza su base de datos local
para registrar los eventos
Número de Escenario: R2-1. Resultado de la Prueba
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 77
Criterio de Aceptación
La unidad genera un evento
cuando se garantiza el acceso
al usuario que lo solicita
Exitosa
Contexto: Usuario con permisos solicita
acceso. Observaciones
Evento: El usuario procede a realizar
el proceso de acceso.
Funcionamiento
La unidad valida que el
usuario tenga permiso de
acceso con sus reglas de
acceso locales, guarda el
registro localmente.
Número de Escenario: R2-2. Resultado de la Prueba
Criterio de Aceptación
La unidad genera un evento
cuando se niega el acceso al
usuario que lo solicita.
Fallida
Contexto: Usuario sin permisos solicita
acceso Observaciones
Evento: El usuario procede a realizar
el proceso de ingreso.
La unidad genera el evento pero no almacena de forma local.
Funcionamiento
La unidad valida que el
usuario tenga permiso de
acceso con sus reglas de
acceso locales, guarda el
registro localmente.
Número de Escenario: R2-3. Resultado de la Prueba
Criterio de Aceptación La unidad genera un evento
de acceso. Fallida
Contexto: Unidad en línea con el
sistema central. Observaciones
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 78
Evento:
La unidad otorga o niega el
acceso a un usuario y genera
un evento de acceso que se
envía al sistema central para
que sea persistido.
Por problemas de comunicación la unidad no sincronía la información con la unidad
Funcionamiento
La unidad envía la
información del evento al
sistema central quien
almacenará la información
del evento generado.
El problema de comunicación se aborda en el sprint 3
Número de Escenario: R2-4. Resultado de la Prueba
Criterio de Aceptación La unidad genera un evento
de acceso. Exitosa
Contexto: Unidad en fuera de línea con
el sistema central. Observaciones
Evento:
La unidad pierde la conexión
con el sistema central, a su
vez se genera un evento
cuando otorga o niega el
acceso a un usuario.
Funcionamiento
La unidad guarda la
información en su base de
datos loca, una vez vuelva a
estar en línea con el sistema
envía la información de los
eventos generados durante el
tiempo en que se encontró
fuera de línea al sistema
central ,quien almacenará la
información del evento
generado.
5.1.2 Pruebas Sprint 3
Número de Escenario: R1-3. Resultado de la Prueba
Criterio de Aceptación
La unidad sincroniza su
información con el sistema
central.
Exitosa
Contexto:
Unidad retoma la conexión
con el sistema central y
vuelve estar en línea.
Observaciones
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 79
Evento:
La unidad retoma la conexión
con el sistema central,
procede a sincronizar la
información que guardo de
forma local mientras se
encontraba fuera de línea.
Funcionamiento
El sistema central y la unidad
comparten la misma
información actualizada sobre
los eventos de acceso.
Número de Escenario: R1-5 Resultado de la Prueba
Criterio de Aceptación La unidad procede a denegar
el acceso a todos los usuarios. Exitosa
Contexto:
La unidad excede el tiempo
máximo que puede estar fuera
de línea.
Observaciones
Evento:
La unidad supera el tiempo
máximo establecido para
funcionar fuera de línea,
procede a entrar en modo
“suspendido” donde solo le
permite acceso a los usuarios
que se encuentren cobijados
bajo la regla de acceso que
permite el acceso a todas las
zonas del sistema.
Funcionamiento
La unidad no permitirá el
acceso a ningún usuario que
se encuentre por fuera de la
regla de acceso a todas las
zonas del sistema hasta que se
encuentre de nuevo en línea.
Número de Escenario: R1-6. Resultado de la Prueba
Criterio de Aceptación
El sistema central informa
que una unidad ha superado
el tiempo máximo en que
puede encontrarse fuera de
línea
Exitosa
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 80
Contexto:
La unidad excede el tiempo
máximo en que puede estar
fuera de línea.
Observaciones
Evento:
La unidad supera el tiempo
máximo establecido para
funcionar fuera de línea, el
sistema central procede a
generar un evento indicando
la situación actual de la
unidad.
Funcionamiento
El sistema cuenta con el
registro de la falla en la
conexión con la unidad
Número de Escenario: R3-1. Resultado de la Prueba
Criterio de Aceptación El sistema guarda el registro
del cambio realizado. Exitosa
Contexto: El usuario administrador
modifica una regla de acceso. Observaciones
Evento:
El usuario administrador
procede a realizar un cambio
en una regla de acceso.
Funcionamiento
En el momento en que la
unidad esté en línea el
sistema procede a enviar las
reglas actualizadas de acceso
a la unidad
Número de Escenario: R3-3. Resultado de la Prueba
Criterio de Aceptación El sistema elimina la regla y
guarda el registro. Fallida
Contexto: El usuario administrador
elimina una regla de acceso. Observaciones
Evento:
El usuario administrador
procede a eliminar una regla
de acceso.
El sistema no elimina la regla de la base de datos
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 81
Funcionamiento
En el momento en que la
unidad esté en línea el
sistema procede a enviar las
reglas actualizadas de acceso
a la unidad.
Se procede con el ajuste de la funcionalidad en los dos últimos días del sprint
Número de Escenario: R4-3. Resultado de la Prueba
Criterio de Aceptación
El Usuario Administrador
podrá administrar las reglas
de acceso
Exitosa
Contexto:
Usuario con permisos
administra las reglas de
acceso.
Observaciones
Evento:
El usuario procede a ingresar
al apartado de la
administración de las reglas
de acceso, consulta, crea,
modifica o elimina una regla
de acceso.
Funcionamiento
El sistema realiza la consulta,
creación, modificación o
eliminación de la regla de
acceso informando de los
cambios a las unidades
afectadas.
Número de Escenario: R4-4. Resultado de la Prueba
Criterio de Aceptación
El Usuario Administrador
podrá Administrar las zonas
de acceso.
Fallida
Contexto:
Usuario con permisos
administra las zonas de
acceso
Observaciones
Evento:
El usuario procede a ingresar
al apartado de la
administración de las zonas
de acceso y consulta, crea,
modifica o elimina las zonas
de acceso.
Se presenta error cuando la unidad esta tiene otra regla de acceso que entra en conflicto con las zonas del sistema, el error se corrige en el 4 día del sprint.
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 82
Funcionamiento
El sistema realiza la consulta,
creación, modificación o
eliminación de la zona de
acceso informando de los
cambios a las unidades
afectadas.
Se procede a ajustar la lógica de la unidad para que las reglas que denieguen acceso tengan precedencia sobre las demás reglas.
5.2. Cierre del proyecto Para el cierre del proyecto los integrantes del grupo se reunieron y definieron los aciertos y fallas
durante el desarrollo del proyecto. Se evaluaron los tiempos requeridos en los esfuerzos para el
desarrollo del producto versus el esfuerzo re querido para solucionar los imperfectos dentro de
cada uno de los Sprints la siguiente tabla contiene el compilado de los datos obtenidos.
sprint Errores Esfuerzo para solucionar
errores (Horas) Esfuerzo Total
(Horas) % Esfuerzo para
solucionar errores
1 12 60 208 29
2 6 28 135 21
3 2 13 86 15 Tabla 16 Tiempo desarrollo Vs Errores de desarrollo.
Fuente: Los autores.
Se puede ver como el primer Sprint requirió de un mayor esfuerzo en la resolución de los errores
que se presentaron durante ese tiempo, esto responde al sobreesfuerzo que se presentó al inicio
del proyecto. En los siguientes Sprints el esfuerzo requerido para solucionar los imperfectos
decreció, lo que indica que se pudieron sobreponer las falencias iniciales en cuanto a carga y
esfuerzos requeridos para el desarrollo del producto.
La siguiente Figura presenta un gráfico del esfuerzo total medido en horas, requerido para el
desarrollo del proyecto versus el tiempo requerido para solucionar los errores de desarrollo que
se presentaban a medida que pasaba el tiempo.
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 83
Ilustración 29 Esfuerzo Total Vs Esfuerzo en la resolución de los errores
Fuente: Los Autores.
Dentro del análisis las fallas en la construcción del producto se encuentran:
Falta de comunicación de los integrantes del grupo en cuanto a las tareas de desarrollo.
Deficiente planeación y estimación de tiempos para el primer sprint del proyecto.
Sobreesfuerzos en los tiempos de desarrollo durante el primer sprint.
Errores en la integración de los objetos compilados.
A continuación los principales aciertos del proyecto:
Selecciona adecuada de la tecnología que permitió no tener errores relacionados al uso de
las tecnologías seleccionadas para el desarrollo.
Selección adecuada de la arquitectura del producto que permitió no tener problemas
derivados de la definición arquitectura.
60
28
13
208
135
86
0 50 100 150 200 250
1
2
3
Esfuerzo (Horas)
Spri
nts
Esfuerzo Total Vs Esfuerzo por Errores
Esfuerzo Total (Horas) Esfuerzo para solucionar errores (Horas)
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 84
Fácil adaptación a los cambios consecuencia de los errores y el sobreesfuerzo del primer
sprint.
5.3. Mejoras propuestas Se entiende que el proyecto pretende ser un ejemplo de la viabilidad de construir un sistema de
control de acceso apoyado en las tecnologías libres que se encentran en el mercado, es por esto
que dentro del desarrollo del producto se identificaron algunas características que aportarían un
gran valor al producto, y sería pertinente que en un futuro se contara con una versión que las
incluya, algunas de ellas son:
El usuario pueda identificarse con una forma alterna a la forma de identificación con que
cuenta el sistema de forma predefinida.
El sistema Envíe notificaciones de accesos prohibidos a los administradores del sistema.
Generación de Reportes de las estadísticas de cada una de las unidades.
El sistema permita hacer búsquedas de eventos por tipo y periodo de tiempo.
Las unidades de acceso puedan ser administradas de forma remota.
El sistema pueda funcionar en clúster.
Cuando por alguna razón el servidor esta fuera de línea, cualquier unidad del sistema esté
en la capacidad de asumir los servicios que el servidor central presta a todo el sistema.
Cuando exista un alto volumen de información que llega el servidor y que congestione la
red, cualquier unidad del sistema esté en la capacidad de asumir los servicios que el
servidor central presta a todo el sistema mientras se libera la congestión en el tráfico de
datos.
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 85
Conclusiones
El análisis y diseño son la parte más importante del desarrollo de software, puesto que al hacer una
plantificación detallada se reducen los tiempos de desarrollo y teniendo clara la arquitectura
permite organizar y distribuir mejor los componentes relacionados, de forma tal que el sistema
puede crecer fácilmente sin perderse el control sobre cada componente, así mismo al reconocer
claramente las funcionalidades comunes se reduce la redundancia de código.
La documentación del código es esencial para poder entender y recordar las funcionalidades de cada
clase, así como su utilidad y dominio sobre el negocio, permitiendo encontrar y corregir
fácilmente los errores.
La estandarización de los nombres de las clases y las tablas reduce la complejidad del sistema al
reunirlas por funcionalidades permitiendo una administración más sencilla.
El uso de archivos de configuración permite hacer modificaciones en las funcionalidades del
sistema de forma tal que se puede cambiar el comportamiento de la aplicación rápidamente,
también añaden características dinámicas extra.
Es importante mantener limpia la memoria usada, removiendo los objetos innecesarios, esto
aumenta el desempeño de la aplicación y es fundamental en entornos embebidos.
Para una funcionalidad especializada es preferible tomar tiempo para buscar una implementación ya
existente, y no emprender un desarrollo ya que el uso de bibliotecas dinámicas reduce
considerablemente el tiempo de desarrollo.
La implementación de la capa SSL minimiza los riesgos inherentes a la transmisión de datos.
Durante el proyecto se presentaron falencias en la definición de tiempos y esfuerzos para construir
el software a base de los requerimientos identificados, en la fase de cierre del proyecto se puede
observar como la mala planeación del primer Sprint represento una sobreesfuerzo en tiempo, una
mayor cantidad de errores y un tiempo mayor para la resolución de dichos errores a diferencia de
los Sprints subsiguientes.
La metodología Scrum permitió evidenciar las falencias y corregirlas de forma oportuna durante la
fase de desarrollo del producto, a su vez a medida que pasaban los Sprints, equilibrar las cargas
de trabajo y esfuerzos requeridos por cada recurso para llevar a cabo las tareas planeadas.
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 86
El enfoque de “servicio” que se le dio a la forma de funcionar de cada una de las unidades que
conforman el sistema permitió que el sistema en si sea escalable en hardware, ya que es
adaptarlo a el número de las unidades requeridas para el funcionamiento del sistema.
El uso de motores de bases de datos NoSql permite una gran adaptabilidad a los cambios que surgen
en el transcurso de la construcción del software como de los posibles cambios en los
requerimientos iniciales; A diferencia de las bases relacionales donde los cambios en las
estructuras de persistencia conllevan a mayores tiempos en la adaptación funcional por parte de
los componentes desarrollados.
Las tecnologías libres que se encuentran en el mercado actual como el Raspberry Pi, tienen un gran
potencial para ser usadas como puntos de integración entre diversas tecnologías más robustas
como los lenguajes de programación, motores de Bases de datos y aplicaciones web.
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 87
Recomendaciones
Ya que el sistema es distribuido y no tiene reloj global, se recomienda implementar servicios NTP y
configurar los diversos sistemas con dicho protocolo.
Se recomienda implementar SNMP y SYSLOG para la revisión extra de los dispositivos y el
servidor en redes locales, una de las herramientas libres disponibles que permiten dicha
integración es NAGIOS.
Para redes WAN o esquemas Cloud se recomienda la creación de CRON para la realización de
tareas de mantenimiento como son: limpieza de registro de log, reinicio programado de
procesos, actualización automática, etc.
Se recomienda el uso de logrotate, realizar labores de hardering sobre los servicios asociados al
sistema y la revisión periódica de las políticas de firewall local de cada dispositivo.
Si el sistema servidor se publica en internet, se recomienda el uso de IPS, IDS y registro de eventos
de seguridad con equipos especializados.
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 88
Bibliografía
CRAIG, Larman. UML y patrones. Introducción al análisis y diseño orientado a objetos 2a edición,
2003.
FALKNER, Jayson y JONES, Kevin. Servlets and JavaServer Pages™: The J2EE™ Technology
Web Tier. Addison Wesley, 2003.
KURNIAWAN, Budi. Java for the Web with Servlets, JSP, and EJB: A Developer's Guide to J2EE
Solutions. New Riders Publishing, 2004.
MARCHAL, Benoit, XML con ejemplos. Pearson Education. Mexico. 2001.
PRESSMAN, Roger S. Ingeniería del software. Un enfoque práctico MacGraw Hill, 2005 6ta
Edición.
WEITZENFELD, Alfredo. Ingeniería de Software orientada a objetos con UML, JAVA e
INTERNET. México: Thomson, 2005.
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 89
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO
DISTRIBUIDO CON TECNOLOGIAS LIBRES
Javier Alfonso. Alvaro Ronderos
Ingeniería en Telemática, Universidad Distrital Francisco José de Caldas,
Abril de 2015, Bogotá, Colombia
Resumen
- Este documento provee una vista general de los
aspectos técnicos de la propuesta de grado
PROTOTIPO DE SISTEMA DE CONTROL DE
ACCESO DISTRIBUIDO CON TECNOLOGIAS
LIBRES. Este proyecto busca aprovechar las
ventajas de las tecnologías libres para desarrollar un
prototipo de sistema distribuido que permita el
control de acceso en las organizaciones de tal forma
que pueda adaptarse a diferentes contextos de
seguridad; Sea escalable y económico de
implementar.
Palabras claves- control de Acceso, desarrollo de
software libre, la tecnología Java, los sistemas
distribuidos, la seguridad física de las organizaciones
y las Bases de datos.
1. INTRODUCCIÓN
La seguridad de los activos es uno de los ítems más
importantes dentro de los planes de seguridad
implantados por cada organización, en la actualidad las
empresas y organizaciones comúnmente delegan la
función de seguridad en terceros, generalmente una
empresa de seguridad privada, estas empresas de
seguridad se encargan de salvaguardar las instalaciones
de las organizaciones y en algunos casos un cierto
control en el acceso a las instalaciones por parte de
extraños. sin embargo el nivel de acceso privilegiado
sobre ciertas áreas, recursos o activos de la empresa es
tratado de forma trivial en muchos casos y en otros hace
parte del plan general de la organización enfocado a la
seguridad de los activos de información con que cuenta
la empresa, la forma de control es mediante sistemas
como el RFID (Radio Frequency IDentification, en
español identificación por radiofrecuencia) que es un
sistema de almacenamiento y recuperación de datos
remoto que usa dispositivos denominados etiquetas,
tarjetas, transpondedores o tags RFID. El propósito
fundamental de la tecnología RFID es transmitir la
identidad de un objeto (similar a un número de serie
único) mediante ondas de radio. Las tecnologías RFID
se agrupan dentro de las denominadas Auto ID
(automatic identification, o identificación automática).
Esta clase de tecnología permite garantizar el acceso, sin
embargo no garantiza la identidad de quien accede, lo
que representa una gran falencia, en el otro extremo se
tienen los sistemas de control de acceso, con lectores
biométricos, que cuyos esquemas de seguridad permiten
controlar que a determinadas áreas de la organización
solo ingresen las personas autorizadas. En estos sistemas
de control de acceso se usa la huella digital, u otra
cualidad diferencial, a manera de llave o pase de entrada
por lo cual es plenamente identificable la identidad de
las persona que intenta obtener acceso.
Los sistemas de identificación biométrica son
esencialmente software que corre sobre un equipo que
permite la identificación inequívoca de personas,
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 90
previamente registradas por otra parte del sistema en una
base de datos. Estas características físicas individuales
no pueden ser falsificadas fácilmente. Habitualmente
estas lecturas biométricas se basan en las características
de las huellas digitales o cualquier otro identificador
biométrico.
Para proveer movilidad al sistema de identificación de
forma que permita ser transportado e instalado
fácilmente, este debe cumplir con ciertas características
como: ser liviano, permitir conectarse por diversos
medios, poseer respaldo de datos externo, permitir
guardar registros de transacciones, sincronizar las
transacciones cuando se encuentre de nuevo en línea,
permitir adicionar nuevo hardware de control, y las
demás características de un sistema distribuido.
2. DESCRIPCIÓN DEL PROBLEMA
Las empresas se ven abocadas en la actualidad a
proteger activos de gran valor para sus organizaciones,
los controles establecidos para salvaguardar dichos
activos no suelen ser muy efectivos ya que en gran parte
se ven limitados por los proveedores de soluciones de
seguridad, quienes en muchos casos no cuentan con
productos adaptables a la necesidad de cada cliente, o en
otros casos son muy costosas para ser implementadas, lo
que limita a las empresas para establecer un esquema de
seguridad adecuado y a su vez contribuye a que no
puedan tener controles adecuados eficientes que se
traduce en pérdidas de activos, como perdidas de
información o fugas de información.
Las soluciones que ofrecen los proveedores de
tecnología del área de la seguridad presentan costos
elevados para ser implementadas porque dependen de
una inversión económica para la adecuación de la
infraestructura física, contratos de servicio por periodos
de tiempo prefijados, cobros asociados a licencias de
tecnologías propietarias con periodos de expiración y
costos ocultos en la actualización de los esquemas de
seguridad como lo menciona John LaFond en su
artículo ‘Counting Up the Hidden Costs of Security
Licensing’:
“Al ampliar o actualizar los sistemas, todos los clientes
son susceptibles a una amplia gama de honorarios por
licencia (además de cualquier costo laboral o de
hardware) que puede aumentar significativamente la
cantidad que usted está pagando por las mejoras o
actualizaciones de tecnología que su empresa quiere y
necesita. Los costos ocultos pueden provenir de tarifas
de servicios cloud, cliente o cobros de licencias de base
de datos, comisiones por licencias de hardware, o
cualquier combinación de éstos. Esto significa que
cualquier momento que desee ampliar el número de
puntos de acceso, implementar la integración de vídeo
o tal vez actualizar su sistema con control de acceso al
ascensor, le podría costar en múltiples niveles.” [1]
Los controles de seguridad que se ofrecen en la
actualidad presentan problemas para las organizaciones
debido a que no siempre es posible de adaptar la
solución tecnológica a las necesidades de cada
organización, la mayoría de soluciones no están
enfocadas en las normas de calidad sino en el control de
acceso a áreas y presentan dificultades en la
escalabilidad del sistema a medida que la organización
crece o cambia.
“La seguridad física para diferentes ubicaciones puede
requerir variaciones en la implantación de las medidas
que permitan que se adapten a las peculiaridades de
cada sede o infraestructura. Por ello, niveles de
protección deseables pueden variar dentro de una
misma organización. Es recomendable implantar un
sistema de gestión maduro, que evite redundancias en
contratos y servicios, y que, por otra parte, no deje
ningún activo sin salvaguardar, adaptándose a las
necesidades específicas de cada lugar y los cambios de
las amenazas en el tiempo.” [2]
2.1 Formulación del problema
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 91
¿Cómo construir una solución tecnológica que sea una
alternativa a las soluciones actuales del mercado, que
sea económica, confiable y adaptable a las empresas
interesadas en proteger la integridad y confidencialidad
de sus activos por medio de control de acceso?
3. OBJETIVOS
En la propuesta de grados se pretende cumplir los
siguientes objetivos:
3.1. Objetivo General:
Desarrollar un prototipo de sistema de control de acceso
distribuido de software libre, adaptable y de bajo costo
de implementación.
3.2 Objetivos Específicos
Analizar los requerimientos para el desarrollo
del sistema de control de acceso.
Diseñar una solución tecnológica que cumpla
con los requerimientos identificados.
Desarrollar un prototipo de solución tecnológica
para el control del acceso que permita ser usada
con propósito general, que sea adaptable a
diferentes contextos dentro de las
organizaciones, permita la escalabilidad y
adaptación a diversos componentes de hardware
como lectores biométricos, teclados numéricos,
tarjetas RFID o etiquetas NFC.
Implementar una solución Tecnológica que no
tenga costos asociados al licenciamiento de las
tecnologías utilizadas.
Probar el prototipo en la empresa A & G
Tecnología para comprobar que el sistema
desarrollado cumple con los objetivos
planteados.
4. MARCO TEORICO
Los siguientes son las técnicas y tecnologías escogidas
para el desarrollo del proyecto, teniendo en cuenta que
son software libre y patrones de diseño disponibles para
su uso.
4.1. Arquitectura MVC (Modelo vista Controlador).
Fue descrita por primera vez en 1979 en el documento
“Applications Programming in Smalltalk-80(TM):
How to use Model-View-Controller (MVC)” [3].
Dirigido al lenguaje de programación Smalltalk. Usada
como el patrón clásico para aplicaciones donde el
usuario interactúa constantemente con el sistema, “La
arquitectura de diseño MVC (iniciales en inglés de
“Model View Controller” o “Modelo Vista
Controlador”) provee un mecanismo que posibilita
separar los datos (el modelo) de la forma en que estos
serán visualizados (la vista) Usando un puente entre
los dos (El controlador)”[4], lo anterior se puede
observar en la figura 1.
Figura 1: Arquitectura MVC.
4.2 Arquitectura de un sistema distribuido bajo el
patrón MVC:
En la figura 2 Se marca la disposición común con el cual
se desarrolla un sistema distribuido bajo la arquitectura o
patrón MVC, se muestra la forma en que interactúan las
tres capas de información, se debe denotar que el usuario
del sistema no debe tener acceso a la capa del Modelo
(donde están los datos) por seguridad y dado que así lo
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 92
dispone el patrón de diseño, el usuario solo debe
interactuar con la capa de vista o presentación a través
del Controlador y es este último quien se comunica con
todas las capas que componen la aplicación distribuida.
Figura 2: Arquitectura de un Sistema distribuido Bajo el
patrón MVC.
4.3 Raspberry Pi.
El Raspberry Pi (Figura 3) es un ordenador del tamaño
de una tarjeta de crédito, de bajo costo, se conecta a un
monitor de ordenador o un televisor, y utiliza un teclado
y un ratón estándar. Es un dispositivo poco capaz que
permite a las personas de todas las edades para explorar
la computación, y para aprender a programar en
lenguajes como Python, C++, o incluso Java. Es capaz
de hacer todo lo que espera un ordenador de sobremesa
que hacer, desde navegar por Internet y reproducción de
vídeo de alta definición, con la toma de hojas de cálculo,
procesador de textos, y jugar juegos. Lo que es más, el
Raspberry Pi tiene la capacidad de interactuar con el
mundo exterior, y se ha utilizado en una amplia gama de
proyectos fabricante digitales, como máquinas de
música, detectores de padres, estaciones meteorológicas
y twitteando casas de aves con cámaras infrarrojas.
La fundación Raspberry Pi espera masificar el uso del
Raspberry Pi como componente académico en todo el
mundo para aprender a programar y entender cómo
funcionan los ordenadores [5].
Figura 3: Componentes de un Raspberry Pi
4.4. Metodología Scrum
Como lo menciona Juan Palacios en el documento “El
Modelo Scrum”[6], Scrum es una metodología de
desarrollo muy simple, que requiere trabajo duro porque
no se basa en el seguimiento de un plan, sino en la
adaptación continua a las circunstancias de la evolución
del proyecto.
Scrum es una metodología ágil, y como tal:
Es un modo de desarrollo de carácter
adaptable más que predictivo.
Orientado a las personas más que a los procesos.
Emplea la estructura de desarrollo ágil:
incremental basada en iteraciones y
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 93
revisiones.
Se comienza con la visión general del producto,
especificando y dando detalle a las funcionalidades o
partes que tienen mayor prioridad de desarrollo y que
pueden llevarse a cabo en un periodo de tiempo breve
(normalmente de 30 días).
Cada uno de estos periodos de desarrollo es una
iteración que finaliza con la producción de un
incremento operativo del producto.
Estas iteraciones son la base del desarrollo ágil, y Scrum
gestiona su evolución a través de reuniones breves
diarias en las que todo el equipo revisa el trabajo
realizado el día anterior y el previsto para el día
siguiente como lo muestra la figura 4.
Figura 4: Flujo de trabajo en Scrum
5. PERSPECTIVAS:
Se pretende hacer el uso de las tecnologías libres para
construir un prototipo de sistema distribuido para el
control de acceso que en el futuro se pueda volver un
sistema mucho más robusto, cuyo costo de
implementación sea menor al que actualmente ofrecen
las demás soluciones tecnológicas que están en el
mercado colombiano.
Se propone aplicar los principios del desarrollo ágil en
proyectos bajo la metodología de Scrum.
Se proyecta tener un sistema que use elementos de
hardware y software libre, escalable y adaptable a
nuevas tecnologías de carácter libre.
6.CONCLUSIONES
Los avances en tecnologías libres de software y
hardware como el Raspberry Pi proveen una plataforma
robusta para el desarrollo de aplicaciones de interacción
con los humanos, debido a que poseen la potencia básica
de un ordenador de escritorio bajo una arquitectura
adaptable a sistemas embebidos.
Los Sistemas distribuidos son el presente de la
computación, siendo a la par de la computación en la
nube, las bases para los desarrollos de los sistemas
ubicuos que interactúan con los seres humanos.
La metodología Scrum es aplicable a diversos proyectos
de tecnología no solo de software por su enfoque de
actividades y adaptabilidad al cambio constante en los
requerimientos.
REFERENCIAS
[1] LaFond, John. Counting Up the Hidden Costs of
Security Licensing. Publicado en Security Magazine.
Junio 10 de 2014. [En línea]. [Consulta: 08 de febrero
de 2015] Disponible en:
http://www.securitymagazine.com/articles/85588-
counting-up-the-hidden-costs-of-security-licensing
[2] Rego, Miguel. La eficiencia y la eficacia en la
Seguridad Patrimonial. [En línea]. [Consulta: 22 de
febrero de 2015] Disponible en
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 94
http://www.redseguridad.com/opinion/articulos/la-
eficiencia-y-la-eficacia-en-la-seguridad-patrimonial
[3] Burbeck, Steve. Applications Programming in
Smalltalk-80(TM):
How to use Model-View-Controller (MVC) [en línea]
[consulta: 08 de noviembre de 2014]. Disponible en:
http://st-www.cs.illinois.edu/users/smarch/st-
docs/mvc.html
[4] Sznajdleder, Pablo. Java a fondo: estudio del
lenguaje y desarrollo de aplicaciones 1ª ed. Buenos
Aires, Alfaomega, 2010,528p.
[5] WHAT IS A RASPBERRY PI? [En línea]
[Consulta: 08 de febrero de 2014]. Disponible en:
https://www.raspberrypi.org/help/what-is-a-raspberry-pi/
[6] Palacios, Juan. El Modelo Scrum. [En línea]
[Consulta. 10 de marzo de 2015]. Disponible en
http://www.navegapolis.net/files/s/NST-010_01.pdf
Sobre los Autores
Javier Ricardo Alfonso Alba.
Es Tecnólogo grado I en la Contraloría
General de la República, Culmino sus
estudios de Ingeniería en telemática y es
Tecnólogo en Sistematización de datos de
la Universidad Distrital. Interesado en las redes,
sistemas distribuidos y seguridad de la información.
e-mail: [email protected]
Alvaro Iván Ronderos Acevedo,.
Es Ingeniero de Desarrollo en Grupo Dot
S.A.S, Culmino sus estudios de Ingeniería
en telemática y es Tecnólogo en
Sistematización de datos de la Universidad
Distrital. Interesado en la programación de portales web,
la gerencia y administración de proyectos informáticos.
e-mail: [email protected]
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 1
MANUAL DE USUARIO DEL PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO
DISTRIBUIDO CON TECNOLOGIAS LIBRES
Javier Ricardo Alfonso Alba
Álvaro Iván Ronderos Acevedo
UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS
FACULTAD TECNOLÓGICA
INGENIERÍA TELEMÁTICA
Bogotá 2016
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 2
Contenido 1. Introducción .............................................................................................................................................. 1
2. INSTALACION DEL SISTEMA ...................................................................................................................... 1
2.1. Requerimientos de Hardware ............................................................................................................ 1
2.2 Requerimientos de Software .............................................................................................................. 1
3. OPERACIÓN DE LA APLICACIÓN ................................................................................................................ 2
4. PÁGINA HOME .......................................................................................................................................... 2
4.1 Componentes de la página ................................................................................................................. 3
5. PÁGINA UNIDADES .................................................................................................................................... 4
5.1 Componentes de la página ................................................................................................................. 4
5.2 Acciones sobre la página. .................................................................................................................... 5
5.2.1 Seleccionar una unidad. ............................................................................................................... 5
5.2.2 Agregar una unidad a una zona. .................................................................................................. 6
5.2.3 Quitar una unidad de una zona.................................................................................................... 7
5.2.4 Agregar una nueva unidad. .......................................................................................................... 9
6. PÁGINA USUARIOS .................................................................................................................................. 10
6.1 Componentes de la página ............................................................................................................... 11
6.2 Acciones sobre la página. .................................................................................................................. 12
6.2.1 Agregar usuario a un grupo. ...................................................................................................... 12
6.2.2 Quitar usuario de un grupo. ....................................................................................................... 13
7. PÁGINA REGLAS DE ACCESO ................................................................................................................... 15
7.1 Componentes de la página ............................................................................................................... 17
7.2 Acciones sobre la página. .................................................................................................................. 18
7.2.1 Agregar grupo a la regla ............................................................................................................. 18
7.2.2 Quitar grupo de la regla. ............................................................................................................ 19
7.2.3. Agregar usuario a la regla. ........................................................................................................ 21
7.2.4 Quitar usuario de la regla........................................................................................................... 22
7.2.5 Agregar zona a la regla ............................................................................................................... 24
7.2.6 Quitar zona de la regla ............................................................................................................... 25
7.2.7 Agregar unidad a la regla ........................................................................................................... 27
7.2.8 Quitar unidad de la regla ........................................................................................................... 28
7.2.9 Agregar una nueva regla de acceso ........................................................................................... 30
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 3
8. PÁGINA EVENTOS .................................................................................................................................... 31
8.1 Componentes de la página. .............................................................................................................. 32
8.2 Acciones sobre la página. .................................................................................................................. 33
8.2.1 Buscar por fechas ....................................................................................................................... 33
8.2.2 Buscar por usuario ..................................................................................................................... 34
8.2.3 Buscar por unidad ...................................................................................................................... 34
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 1
1
1. Introducción
El prototipo de sistema de control de acceso con tecnologías libres, es un aplicativo informático
diseñado como alternativa libre para los sistemas de control de acceso. Este sistema está enfocado en la
utilización de tecnologías libres como un medio para la construcción de un prototipo de sistema de
control de acceso.
El prototipo consta de un aplicativo servidor con interfaz gráfica el cual permite al administrador del
sistema administrar los componentes del sistema: Usuarios, Unidades, Reglas de Acceso, Grupo de
Usuarios y Zonas. Este manual de usuario pretende guiar al usuario administrador sobre las diferentes
interfaces graficas que componen el sistema.
2. INSTALACION DEL SISTEMA
2.1. Requerimientos de Hardware
Para la Instalación del Sistema se requiere un computador de escritorio con las siguientes características
o superiores:
Procesador de 2.3 Ghz.
Disco duro de 80 GB.
Memoria RAM de 2048 MB.
Periféricos estándar (Mouse, Teclado, Pantalla).
2.2 Requerimientos de Software
El equipo Servidor requiere:
Conexión a Lan
Motor de bases de datos MongoDB 3.0 o superior.
JRE (java Runtime Environment) 6 o superior.
Navegador de Internet con soporte de Html 5
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 2
1
3. OPERACIÓN DE LA APLICACIÓN
Una vez el servidor este ejecutándose, se debe ingresar desde un equipo que se encuentre en la misma
red local y a través de un navegador web en a la dirección y puerto de la maquina donde se está
ejecutando el servidor, para este documento se asume que el servidor está ejecutándose en la maquina
local sobre el puerto 4567, por lo que será accesible desde la url 127.0.0.1:4567 o la url localhost:4567.
4. PÁGINA HOME
La página home es un medio para conocer el estado actual de las unidades que componen el sistema, al
ingresar se podrá ver una tabla con los campos Unidad, Último Reporte y Estado
Al ingresar a la página localhost:4567/home se podrá observar la siguiente interfaz gráfica:
Imagen 1 Página Home del aplicativo.
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 3
1
4.1 Componentes de la página
Columna Unidad: En esta columna se encuentran los nombres de las unidades que componen el
sistema.
Columna Último Reporte: En esta columna se encuentra la fecha y hora en que la unidad se ha
reportado como activa en el servidor.
Columna Status: En esta columna se puede observar el estatus de la unidad.
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 4
1
5. PÁGINA UNIDADES
La página unidades permite gestionar las unidades que componen el sistema y que se encuentran
asociadas a zonas definidas por el usuario, cada zona se compone de varias unidades y a su vez una
unidad pueda pertenecer a una o más zonas.
Al ingresar a la página localhost:4567/units se podrá observar la siguiente interfaz gráfica:
Imagen 2 Página Units del aplicativo.
5.1 Componentes de la página
COMPONENTE NOMBRE DESCRIPCION
Lista de unidades
Permite observar la lista de unidades que
componen el sistema
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 5
1
Lista de Zonas
Activas para la
Unidad
Permite ver las zonas a las que pertenece
una unidad seleccionada
Zonas disponibles
para la Unidad
Permite ver las zonas disponibles a las cuales
puede ser vinculada una unidad
Vinculo para
agregar una nueva
Unidad
Vinculo para agregar una nueva unidad.
Vinculo para
agregar una nueva
Zona
Vinculo para agregar una nueva zona al
sistema
Botón Agregar Botón que permite agregar el elemento
seleccionado a la lista correspondiente.
Botón Quitar Botón que permite quitar el elemento
seleccionado de la lista correspondiente.
Tabla 17 Componentes página Units.
5.2 Acciones sobre la página.
5.2.1 Seleccionar una unidad.
Cuando se selecciona una unidad de la lista se podrá ver los datos de esta, a su vez se mostraran las
zonas a las que pertenece y las posibles zonas a la que la unidad podrá ser vinculada.
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 6
1
Imagen 3 Seleccionar Unidad.
5.2.2 Agregar una unidad a una zona.
Para agregar una unidad a una zona ya existente se debe seleccionar la zona en la lista correspondiente
y a continuación se debe hacer clic en el botón agregar, a continuación la lista de zonas se verá
actualizada como lo muestra la siguiente imagen:
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 7
1
Imagen 4 Agregar una zona a una unidad.
5.2.3 Quitar una unidad de una zona.
Para proceder a quitar una unidad de una zona se debe seleccionar la zona de la lista de zonas para la
unidad y a continuación se debe dar clic en el botón quitar a continuación se ilustra el proceso de quitar
una unidad una zona existente:
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 8
1
Imagen 5 Quitar unidad de una zona (seleccionar zona).
Imagen 6 Quitar unidad de una zona (Zonas actualizadas)
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 9
1
5.2.4 Agregar una nueva unidad.
Para Agregar una nueva unidad al sistema se debe hacer clic en el vínculo correspondiente, luego se
debe diligenciar los datos Nombre y dirección IP, la dirección IP debe ser la misma que tenga asignada la
unidad en la red LAN.
Imagen 7 Crear una nueva unidad.
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 10
1
Imagen 8 Lista de unidades actualizadas.
6. PÁGINA USUARIOS
La página usuarios permite administrar los usuarios que componen el sistema y como estos se
relacionan con los grupos creados por el administrador del sistema, un grupo es una forma de agrupar a
unos usuarios de tal manera que facilite su administración frente a las reglas de acceso que cada unidad
del sistema va a tener.
Al ingresar a la página localhost:4567/users se podrá observar la siguiente interfaz gráfica:
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 11
1
Imagen 9 Página usuarios del aplicativo.
6.1 Componentes de la página
COMPONENTE NOMBRE DESCRIPCION
Lista de Usuarios
Permite observar la lista de Usuarios que
componen el sistema
Lista de Grupos
Activos para el
Usuario
Permite ver los grupos a los que pertenece
una usuario seleccionado
Grupos disponibles
para la Usuario
Permite ver los Grupos disponibles a los
cuales puede ser vinculado un Usuario
Lista de reglas que
afectan al usuario
seleccionado
Permite ver que reglas están afectando a un
usuario seleccionado
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 12
1
Agregar Grupo Permite agregar un nuevo grupo al sistema
Botón Agregar Botón que permite agregar el elemento
seleccionado a la lista correspondiente.
Botón Quitar Botón que permite quitar el elemento
seleccionado de la lista correspondiente.
Tabla 18 Componentes página Users.
6.2 Acciones sobre la página.
6.2.1 Agregar usuario a un grupo.
Para proceder a agregar un usuario a un grupo ya existente se debe primero seleccionar el usuario, a
continuación se debe seleccionar el grupo al cual va a pertenecer el usuario de la lista de grupos
disponibles, luego se debe hacer clic en el botón de agregar.
Imagen 10 Seleccionar grupo Disponible.
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 13
1
Imagen 11 Resultado de agregar un usuario a un grupo existente.
.
6.2.2 Quitar usuario de un grupo.
Para eliminar la asociación de un grupo con un usuario es necesario seleccionar el usuario, luego
seleccionar el grupo del cual ya no hará más parte el usuario de la lista de grupos del usuario, a
continuación se debe hacer clic en el botón quitar.
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 14
1
Imagen 12 Seleccionar grupo asociado al usuario.
Imagen 13 Resultado de quitar a un usuario de un grupo.
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 15
1
7. PÁGINA REGLAS DE ACCESO La página rules permite administrar las reglas de acceso que componen el sistema y como estas se
relacionan con los usuarios; grupos, zonas y unidades creados por el administrador del sistema, una
regla de acceso puede afectar a un usuario de muchas maneras, ya sea a través de los grupos que a los
que pertenece o directamente, de la misma forma una regla de acceso puede afectar a una unidad
directamente o a través de una zona creada por el administrador
Al ingresar a la página localhost:4567/rules se podrá observar la siguiente interfaz gráfica:
Imagen 14 Vista general de la página rules.
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 16
1
Imagen 15 vista detallada de la página rules 1 de 2.
Imagen 16 vista detallada de la página rules 2 de 2.
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 17
1
7.1 Componentes de la página
COMPONENTE NOMBRE DESCRIPCION
Lista de Reglas
Permite observar la lista de Reglas que
componen el sistema
Lista de Usuarios
Permite observar la lista de Usuarios que
están afectados por la regla seleccionada
Usuarios
Disponibles
Permite observar la lista de Usuarios que
componen el sistema
Lista de Grupos
Activos para la
Regla
Permite ver los grupos afectados por una
regla
Grupos disponibles
para la Regla Permite ver los Grupos disponibles
Lista de usuarios
afectados por la
regla seleccionada
Permite ver que usuarios están siendo
afectados por la regla seleccionada
Lista de Zonas
afectada por la
regla
Permite ver las zonas a las se encuentra
afectando la regla seleccionada
Zonas disponibles
para la Regla Permite ver las zonas disponibles.
Unidades de la regla
Permite observar la lista de unidades que
están asociadas a la regla
Lista de unidades
Permite observar la lista de unidades que
componen el sistema
Agregar Regla de
Acceso
Vinculo que permite agregar una nueva
regla de acceso.
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 18
1
Botón Agregar Botón que permite agregar el elemento
seleccionado a la lista correspondiente.
Botón Quitar Botón que permite quitar el elemento
seleccionado de la lista correspondiente.
Tabla 19 Componentes página Rules.
7.2 Acciones sobre la página.
7.2.1 Agregar grupo a la regla
Para agregar un grupo a una regla de acceso se debe primero seleccionar la regla, luego de la lista de
grupos disponibles se debe seleccionar el grupo que va a ser afectado por la regla y a continuación se
debe hacer clic en el botón agregar.
Imagen 17 Seleccionar grupo para ser afectado.
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 19
1
Imagen 18 Grupo agregado para ser afectado por la regla.
En las imágenes anteriores es posible evidenciar como al agregar un grupo a una regla, inmediatamente
se ve actualiza la lista de usuarios afectados por la regla, lo que facilita el control y el seguimiento de la
cantidad de usuarios que se ven afectados por una regla en particular.
7.2.2 Quitar grupo de la regla.
Para eliminar la asociación del grupo con la regla se debe seleccionar la regla, a continuación se debe
seleccionar de la lista de grupos afectados por la regla el grupo a quitar, luego de esto se debe hacer clic
en el botón quitar.
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 20
1
Imagen 19 Seleccionar el grupo a quitar de la regla.
Imagen 20 Resultado de eliminar el grupo de la regla.
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 21
1
7.2.3. Agregar usuario a la regla.
Para agregar un usuario para que sea afectado por una regla se debe primero seleccionar la regla, luego
se debe seleccionar el usuario a agregar de la lista de usuarios disponibles, a continuación se debe hacer
clic en el botón de agregar.
Imagen 21 Seleccionar usuario a agregar.
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 22
1
Imagen 22 Resultado de agregar un usuario a una regla.
7.2.4 Quitar usuario de la regla.
Para eliminar la asociación de un usuario con una regla se debe seleccionar la regla, a continuación se
debe seleccionar el usuario a retirar de la lista de usuarios afectados por la regla, y luego se debe hacer
clic en el botón quitar.
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 23
1
Imagen 23 Seleccionar el usuario.
Imagen 24 Resultado de quitar el usuario de la regla.
En las imágenes anteriores es posible evidenciar como la lista de usuarios afectados por una regla se
modifica una vez se quita el usuario de la regla.
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 24
1
7.2.5 Agregar zona a la regla
Para agregar una zona para que sea afectada por una regla se debe primero seleccionar la regla, luego
se debe seleccionar la zona a agregar de la lista de zonas disponibles, a continuación se debe hacer clic
en el botón de agregar.
Imagen 25 Seleccionar zona a agregar.
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 25
1
Imagen 26 Resultado de agregar una zona a la regla.
En las imágenes anteriores es posible evidenciar como la lista de unidades afectadas por una regla se
modifica una vez se agrega la zona a la regla.
7.2.6 Quitar zona de la regla
Para eliminar la asociación de una zona con una regla se debe seleccionar la regla, a continuación se
debe seleccionar la zona a retirar de la lista de zonas afectadas por la regla, y luego se debe hacer clic en
el botón quitar.
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 26
1
Imagen 27 Seleccionar zona a retirar de la regla.
Imagen 28 Resultado de retirar la zona.
En las imágenes anteriores es posible evidenciar como la lista de unidades afectadas por una regla se
modifica una vez se quita la zona de la regla.
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 27
1
7.2.7 Agregar unidad a la regla
Para agregar una unidad para que sea afectada por una regla se debe primero seleccionar la regla, luego
se debe seleccionar la unidad a agregar de la lista de unidad disponibles, a continuación se debe hacer
clic en el botón de agregar.
Imagen 29 Seleccionar unidad.
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 28
1
Imagen 30 Resultado de agregar unidad.
En las imágenes anteriores es posible evidenciar como la lista de unidades afectadas por una regla se
modifica una vez se agrega la unidad a la regla
7.2.8 Quitar unidad de la regla
Para eliminar la asociación de una unidad con una regla se debe seleccionar la regla, a continuación se
debe seleccionar la unidad a retirar de la lista de unidades afectadas por la regla, y luego se debe hacer
clic en el botón quitar.
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 29
1
Imagen 31 Seleccionar unidad a retirar.
Imagen 32 Resultado de retirar la unidad de la regla.
En las imágenes anteriores es posible evidenciar como la lista de unidades afectadas por una regla se
modifica una vez se quita la unidad de la regla.
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 30
1
7.2.9 Agregar una nueva regla de acceso
Para agregar una nueva regla de acceso se debe hacer clic en el vínculo de agregar nueva regla de
acceso, se deben diligenciar los datos:
Descripción: es el nombre descriptivo de la regla en el sistema.
Tipo de acceso: La regla creada puede operar de dos maneras, permitiendo el acceso o negándolo.
Imagen 33 Proceso de creación de una nueva regla.
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 31
1
Imagen 34 Resultado de agregar un nueva regla.
8. PÁGINA EVENTOS La página de eventos permite hacer una búsqueda de los eventos generados en el sistema, estos
eventos pueden ser filtrados por fecha, id de usuario, id de la unidad o tipo de evento.
Al ingresar a la página localhost:4567/events se podrá observar la siguiente interfaz gráfica:
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 32
1
Imagen 35 Página events.
8.1 Componentes de la página.
COMPONENTE NOMBRE DESCRIPCION
Campo Id Usuario Permite ingresar el id del usuario a
buscar
Campo id de la
Unidad
Permite ingresar el id de la unidad a
buscar
Campo tipo de
acceso
Permite seleccionar el tipo de acceso
a buscar
Fecha inicial Permite ingresar la fecha inicial del
periodo a buscar
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 33
1
Fecha Final Permite ingresar la fecha final del
periodo a buscar
Botón buscar Permite ejecutar la búsqueda de los
eventos.
Tabla 20 Componentes página Events.
8.2 Acciones sobre la página.
8.2.1 Buscar por fechas
Para buscar por rango de fechas es necesario seleccionar la fecha inicial, luego la fecha final,
posteriormente se debe hacer clic en el botón buscar. Se debe tener en cuenta que la fecha inicial debe
ser menor a la fecha final.
Imagen 36 Ejemplo de búsqueda por fechas.
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 34
1
8.2.2 Buscar por usuario
Para buscar por usuario se hace necesario ingresar el id del usuario en el campo correspondiente, a
continuación se debe hacer clic en el botón buscar.
Imagen 37 Ejemplo de búsqueda filtrada por usuario.
8.2.3 Buscar por unidad
Para buscar por id de la unidad es necesario ingresar el id de la unidad en el campo correspondiente y a
continuación se debe hacer clic en el botón buscar.
PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES 35
1
Imagen 38 Ejemplo de búsqueda filtrada por unidad.
MANUAL DE INSTALACIÓN DEL PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON
TECNOLOGIAS LIBRES 36
1
MANUAL DE INSTALACIÓN DEL PROTOTIPO DE SISTEMA DE CONTROL DE
ACCESO DISTRIBUIDO CON TECNOLOGIAS LIBRES
Javier Ricardo Alfonso Alba
Álvaro Iván Ronderos Acevedo
UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS
FACULTAD TECNOLÓGICA
INGENIERÍA TELEMÁTICA
Bogotá 2016
MANUAL DE INSTALACIÓN DEL PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON
TECNOLOGIAS LIBRES 37
1
Contenido Instalar LDAP (Servidor) .................................................................................................................... 38
Instalar Sistema Operativo del Dispositivo ....................................................................................... 43
Desplegar el Sistema ......................................................................................................................... 45
Desplegar el Servidor ........................................................................................................................ 46
Desplegar el cliente (Dispositivo) ...................................................................................................... 47
MANUAL DE INSTALACIÓN DEL PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON
TECNOLOGIAS LIBRES 38
1
Instalar LDAP (Servidor)
Nota: La instalación documentada corresponde a Ubuntu Linux, esta se realiza a modo de ejemplo,
puede realizarse la instalación de LDAP en cualquier sistema operativo que lo soporte.
Si ya tiene un servidor de dominio de Active Directory o LDAP solo debe modificar el archivo
configuration.properties del paquete acco_ldap_pscal para que cumpla con las
especificaciones del árbol de dominio.
Para instalar LDAP ejecute desde una terminal autenticado como super usuario:
apt-get install slapd
Cuando finalice la instalación del paquete, se debe reconfigurar, pare realizar la reconfiguración
ejecute en la terminal:
dpkg-reconfigure slapd
Responda a las preguntas de la siguiente forma:
¿Desea omitir la configuración del servidor LDAP?: No
MANUAL DE INSTALACIÓN DEL PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON
TECNOLOGIAS LIBRES 39
1
Introduzca su nombre de dominio de DNS: acco.local
Nombre de la organización: acco
Contraseña del administrador: seleccione una contraseña para la instalación.
Verificación de contraseña: digite la contraseña seleccionada, de nuevo.
Motor de base de datos a utilizar: HDB
¿Desea que se borre la base de datos cuando se purgue el paquete slapd?: No
¿Desea mover la base de datos antigua?: Si
¿Desea permitir el protocolo LDAPv2?: No
Instale un administrador gráfico de LDAP como PHPldapadmin o Apache Directory Studio
para conectarse al directorio y restaurar el arbol de ejemplo de acco.local:
MANUAL DE INSTALACIÓN DEL PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON
TECNOLOGIAS LIBRES 40
1
Indique los datos de conexión y datos del usuario administrador:
Al acceder se debe desplegar la siguiente pantalla:
MANUAL DE INSTALACIÓN DEL PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON
TECNOLOGIAS LIBRES 41
1
Realizar la importación del archivo ldif de ejemplo:
Comprobar la creación de los objetos:
MANUAL DE INSTALACIÓN DEL PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON
TECNOLOGIAS LIBRES 42
1
Contenido del Archivo ldif de ejemplo:
dn: ou=people,dc=acco,dc=local
objectClass: top
objectClass: organizationalUnit
ou: people
dn: ou=groups,dc=acco,dc=local
objectClass: top
objectClass: organizationalUnit
ou: groups
dn: uid=javier.alfonso,ou=people,dc=acco,dc=local
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
objectClass: top
cn: javier.alfonso
sn: ACCO
displayName: Javier Ricardo Alfonso Alba
givenName: Javier Ricardo Alfonso Alba
mail: [email protected]
title: Ingeniero
uid: javier.alfonso
userPassword::
e3NzaGF9N2FFYjZCOWRiQStnZTA3NTdxYXVXeDNiQ3VIenRKTmtjSTRna2c9
dn: uid=alvaro.acevedo,ou=people,dc=acco,dc=local
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
objectClass: top
cn: alvaro.acevedo
sn: ACCO
displayName: Alvaro Ivan Acevedo Ronderos
givenName: Alvaro Ivan Acevedo Ronderos
mail: [email protected]
title: Ingeniero
uid: alvaro.acevedo
userPassword::
e3NzaGF9N2FFYjZCOWRiQStnZTA3NTdxYXVXeDNiQ3VIenRKTmtjSTRna2c9
dn: cn=administradores,ou=groups,dc=acco,dc=local
objectClass: top
objectClass: posixGroup
cn: administradores
gidNumber: 500
memberUid: cn=javier.alfonso,ou=people,dc=acco,dc=local
memberUid: cn=alvaro.acevedo,ou=people,dc=acco,dc=local
MANUAL DE INSTALACIÓN DEL PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON
TECNOLOGIAS LIBRES 43
1
Instalar Sistema Operativo del Dispositivo
Descargar
Para Instalar el sistema operativo del dispositivo primero debe descargar la última imagen de
raspbian de la página de raspberry pi, en
https://downloads.raspberrypi.org/raspbian_latest
Formatear la Tarjeta SD
Nota: esta guía es tomada enteramente de:
https://www.raspberrypi.org/documentation/installation/installing-images/linux.md
como referencia se ha realizado la traducción del formateo con Linux, pero puede
consultar el formateo con Windows o Mac OS en:
https://www.raspberrypi.org/documentation/installation/installing-images/README.md
Por favor tenga en cuenta que el uso del comando dd puede sobre escribir cualquier partición de
la máquina, si usted especifica un dispositivo incorrecto en las instrucciones posteriores,
puede eliminar la partición primaria del sistema operativo Linux. Por favor sea
cuidadoso.
Ejecute df –h para identificar los dispositivos montados
Si su equipo de cómputo tiene una ranura para tarjetas SD, inserte la tarjeta. De lo
contrario, inserte la tarjeta dentro de un lector de tarjetas SD, y conecte el lector al
computador.
Ejecute df –h de nuevo. El dispositivo adicional que aparece es su tarjeta SD, la siguiente
columna tiene el nombre del dispositivo de su tarjeta SD, este debe ser mostrado así
como: /dev/mmcblk0p1 o /dev/ssd1 . la última parte (p1 o 1 respectivamente) es el
número de la partición pero se debe escribir la tarjeta SD por completo, no solamente la
partición. Como consecuencia se debe remover esta parte del nombre, obteniendo así,
por ejemplo: /dev/mmcblk0 o /dev/sdd , este es el nombre del dispositivo para la tarjeta
SD completa. Tenga en cuenta que la tarjeta SD puede verse más de una vez en la salida
de la ejecución de df; Esto puede ocurrir si previamente se ha escrito una imagen de
raspberry pi en esta tarjeta, debido a que la imagen de tarjeta SD de raspberry pi tiene
más de una partición.
Ahora debe tener en cuenta el nombre del dispositivo, es necesario desmontarlo, para que
los archivos pueden ser leídos o escritos en la tarjeta SD mientras se realiza la copia de la
imagen.
Ejecute umount /dev/sdd1, reemplace sdd1 con cualquiera que sea el nombre del
dispositivo de la tarjeta SD (Incluido el número de partición).
Si la tarjeta SD aparece más de una vez en la salida de la ejecución del comando df quiere
decir que tiene múltiples particiones, debe desmontar cada una de ellas.
MANUAL DE INSTALACIÓN DEL PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON
TECNOLOGIAS LIBRES 44
1
En una terminal, escriba la imagen a la tarjeta con el comando a continuación, debe estar
seguro de reemplazar el parámetro de archivo de entrada if= con el argumento adecuado
de ubicación del archivo de imagen .img, y /dev/sdd en el argumento de archivo de salida
of= con la ruta del nombre del dispositivo correcto. Este paso es muy importante debido a
que se puede perder información del disco duro principal si se ingresa un nombre de
dispositivo equivocado. Debe estar seguro que el nombre del dispositivo corresponde a la
tarjeta SD entera, descrito a continuación, no solamente a una partición, por ejemplo: sdd,
no sdd1 o sddp1, y mmcblk0, no mmcblk0p1.
dd bs=4M if=2016-03-18-raspbian-jessie.img of=/dev/sdd
Por favor tenga en cuenta establecer el tamaño del bloque en 4M así funciona bien la
mayoría de las veces, si no, por favor intente con 1M, sin embargo tomará
considerablemente más tiempo.
También tenga en cuenta que si no está autenticado como root es necesario anteponer el
comando sudo.
El comando dd no muestra ninguna información del progreso y puede parecer que está
congelado; la operación puede tomar más de cinco minutos en terminar de escribir la
tarjeta. Si su lector de tarjetas tiene un LED este puede parpadear en el proceso de
escritura. Para ver el progreso de la operación de copia usted puede ejecutar pkill -USR1 -
n -x dd en otra terminal, recuerde adicionar sudo si no está autenticado como root. El
progreso será visualizado en la ventana original y no en donde se ejecutó el comando pkill,
puede que el progreso no se visualice inmediatamente, debido a la recarga del buffer.
En lugar de dd se puede usar dcfldd; este ofrece un reporte de avance sobre que tanto ha
logrado escribir.
Se puede verificar que se escribió sobre la tarjeta SD haciendo una copia desde la tarjeta
hacia otro archivo de imagen en el disco duro, truncando la im{agen al mismo tamaño que
la original y ejecutando diff ( o md5sum) sobre las dos imágenes.
La tarjeta SD pude tener más capacidad de almacenamiento que la imagen original, y dd
haría una copia de la tarjeta entera. Como consecuencia se debe asegurar de truncar la
nueva imagen con el tamaño de la original. Debe estar seguro de reemplazar el parámetro
de archivo de entrada if= con el argumento correcto del nombre del dispositivo. Así diff
podría reportar que las imágenes son idénticas.
dd bs=4M if=/dev/sdd of=from-sd-card.img
truncate --reference 2016-03-18-raspbian-jessie.img from-sd-card.img
diff -s from-sd-card.img 2016-03-18-raspbian-jessie.img
Ejecute sync; para asegurarse que el caché de escritura es desocupado de forma segura
antes de desmontar la tarjeta SD.
Remueva la tarjeta SD del lector.
MANUAL DE INSTALACIÓN DEL PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON
TECNOLOGIAS LIBRES 45
1
Primer Inicio
Antes de iniciar por primera vez el dispositivo, asegúrese de transferir a la tarjeta SD los archivos
necesarios para la instalación y/o ejecución de los programas a instalar.
Cuando finalice el proceso de copiado de los archivos, retire la tarjeta SD de forma segura del
computador e insértela en el dispositivo.
Conecte al dispositivo teclado, ratón, monitor y sus cables.
Ahora conecte el cable de poder USB al dispositivo
El dispositivo iniciará en modo de configuración, en este modo se puede: ampliar el
sistema de archivos para usar toda la tarjeta SD (Para dispositivos SD de más de 2 GB),
cambiar las opciones locales para seleccionar su ubicación, cambiar las opciones de zona
horaria para seleccionar su ubicación o crear usuarios. Para terminar seleccione finish y el
sistema se reiniciará.
Acceso por terminal
Después del reinicio de la configuración puede acceder a la terminal usando el usuario pi con la
contraseña raspberry.
Desplegar el Sistema Para desplegar el sistema, debe instalar mongDB v3 o superior y JRE (Java RunTime Environment)
1.6 o superior en el servidor y los dispositivos.
Instalar JRE
Descargar JRE
Descargar el tar.gz para Linux x64 de la página de Oracle (Servidor):
http://www.oracle.com/technetwork/es/java/javase/downloads/jre7-downloads-1880261.html
Descargar el tar.gz para arm hard Float de la página de Oracle (Dispositivo):
http://www.oracle.com/technetwork/java/javase/downloads/jdk7-arm-downloads-2187468.html
Descomprimir
Copiar el archivo tar.gz en una ubicación adecuada, por ejemplo /usr/local y descomprimirlo con
tar –xvzf.
Enlazar
Crear enlaces simbólicos a los binarios de java en la carpeta /bin con ln –s
/usr/local/bin/jre1.version/bin/java, repetir la operación para javac, javah, javadoc y jar.
MANUAL DE INSTALACIÓN DEL PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON
TECNOLOGIAS LIBRES 46
1
Probar
Ejecute java –version para conocer la versión de java instalada en el sistema.
Desplegar el Servidor Instalar Mongo DB
Para instalar mongoDB ejecute en una terminal como super usuario apt-get install –y mongo-org ,
inicie el servicio de mogoDB con el comando service mongod start , verifique que mongoDB ha
iniciado correctamente visualizando el contenido del archivo /var/log/mongodb/mogod.log
Copiar el jar del servicio
Copie el archivo Acco.jar en la ubicación /usr/local/acco, si no existe la ubicación créela.
Copiar el bash del servicio
Ejecute:
cd /etc/init.d touch accod chmod +x accod vi accod
Inserte dentro del archivo:
#!/bin/sh
SERVICE_NAME=acco
PATH_TO_JAR=/usr/local/acco/Acco.jar
PID_PATH_NAME=/tmp/acco-pid
case $1 in
start)
echo "Starting $SERVICE_NAME ..."
if [ ! -f $PID_PATH_NAME ]; then
nohup java -jar $PATH_TO_JAR /tmp 2>> /dev/null >> /dev/null
&
echo $! > $PID_PATH_NAME
echo "$SERVICE_NAME started ..."
else
echo "$SERVICE_NAME is already running ..."
fi
;;
stop)
if [ -f $PID_PATH_NAME ]; then
PID=$(cat $PID_PATH_NAME);
MANUAL DE INSTALACIÓN DEL PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON
TECNOLOGIAS LIBRES 47
1
echo "$SERVICE_NAME stoping ..."
kill $PID;
echo "$SERVICE_NAME stopped ..."
rm $PID_PATH_NAME
else
echo "$SERVICE_NAME is not running ..."
fi
;;
restart)
if [ -f $PID_PATH_NAME ]; then
PID=$(cat $PID_PATH_NAME);
echo "$SERVICE_NAME stopping ...";
kill $PID;
echo "$SERVICE_NAME stopped ...";
rm $PID_PATH_NAME
echo "$SERVICE_NAME starting ..."
nohup java -jar $PATH_TO_JAR /tmp 2>> /dev/null >> /dev/null
&
echo $! > $PID_PATH_NAME
echo "$SERVICE_NAME started ..."
else
echo "$SERVICE_NAME is not running ..."
fi
;;
esac
Por último ejecute: service accod start
Desplegar el cliente (Dispositivo) Instalar Mongo DB 25
Para instalar mongoDB primero descargue los binarios para arm desde la url con el siguiente
comando y permisos de super usuario: wget
http://andyfelong.com/downloads/core_mongodb.tar.gz .
Descomprima el paquete con: tar –xvzf core_mongodb.tar.gz .
Copie los binarios a /usr/bin:
cd core_mongodb
25
Tomado de http://andyfelong.com/2016/01/mongodb-3-0-9-binaries-for-raspberry-pi-2-jessie/ traducción de los autores.
MANUAL DE INSTALACIÓN DEL PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON
TECNOLOGIAS LIBRES 48
1
chown root:root mongo* chmod 755 mongo* strip mongo* cp -p mongo* /usr/bin
Cree el usuario mongodb: adduser --ingroup nogroup --shell /etc/false --disabled-password --
gecos "" --no-create-home mongodb
Cree el directorio de log con los permisos apropiados:
mkdir /var/log/mongodb chown mongodb:nogroup /var/log/mongodb
Cree el directorio de la base de datos con los permisos adecuados:
mkdir /var/lib/mongodb chown mongodb:root /var/lib/mongodb chmod 775 /var/lib/mongodb
Cree el archivo de configuración mongodb.conf en /etc:
cd /etc vi mongodb.conf
Inserte dentro del archivo:
# /etc/mongodb.conf
# minimal config file (old style)
# Run mongod --help to see a list of options
bind_ip = 127.0.0.1
quiet = true
dbpath = /var/lib/mongodb
logpath = /var/log/mongodb/mongod.log
logappend = true
storageEngine = mmapv1
Cree la entrada en el systemd
cd /lib/systemd/system vi mongodb.service
Inserte dentro del archivo:
[Unit]
Description=High-performance, schema-free document-oriented database
MANUAL DE INSTALACIÓN DEL PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON
TECNOLOGIAS LIBRES 49
1
After=network.target
[Service]
User=mongodb
ExecStart=/usr/bin/mongod --quiet --config /etc/mongodb.conf
[Install]
WantedBy=multi-user.target
Ahora está listo para iniciar el servicio de mongoDB:
service mongodb start
Verificar el estado de mongoDB:
service mongodb status
Debe asegurarse que mongoDB baje limpiamente:
service mongodb stop
Copiar el bash de integración
Ejecute:
cd /usr/bin touch acco chmod +x acco vim acco
Inserte dentro del archivo:
!/bin/bash
id_unidad="unidad_001"
Date=$(date +%d/%m/%Y\ %T )
DateL=$(date +%s)
#mongo acco --eval
"printjson(db.userDTO.findOne({accessToken:'$1'},{id:1,_id:0}))" | grep
id
result=$(/usr/bin/mongo acco --eval
"printjson(db.userDTO.findOne({accessToken:'$1'},{id:1,_id:0}))" | grep
id)
id_user="user_id:''"
if [ "$result" ] ; then
echo "encontrado"
MANUAL DE INSTALACIÓN DEL PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON
TECNOLOGIAS LIBRES 50
1
id_user=$(echo "$result" | sed 's/id/user_id/g' | sed 's/{//' | sed
's/}//')
echo "id_user: $id_user"
type="GRANTED"
else
echo "no encontrado"
type="DENIED"
fi
mongo acco --eval
"db.eventDTO.insert({type:'$type',time:NumberLong('$DateL'),unit_id:'$id_
unidad',$id_user,description:'$Date',accessToken:'$1'})"
Modifique el nombre de la unidad acorde con la nomenclatura seleccionada.
Copiar el jar del servicio
Copie el archivo accomobile.jar en la ubicación /usr/local/acco, si no existe la ubicación créela.
Copiar el bash del servicio
Ejecute:
cd /etc/init.d touch accomobiled chmod +x accomobiled vi accomobiled
Inserte dentro del archivo:
#!/bin/sh
SERVICE_NAME=accomobile
PATH_TO_JAR=/usr/local/acco/accomobile.jar
PID_PATH_NAME=/tmp/accomobile-pid
case $1 in
start)
echo "Starting $SERVICE_NAME ..."
if [ ! -f $PID_PATH_NAME ]; then
nohup java -jar $PATH_TO_JAR /tmp 2>> /dev/null >> /dev/null
&
echo $! > $PID_PATH_NAME
echo "$SERVICE_NAME started ..."
else
echo "$SERVICE_NAME is already running ..."
fi
;;
MANUAL DE INSTALACIÓN DEL PROTOTIPO DE SISTEMA DE CONTROL DE ACCESO DISTRIBUIDO CON
TECNOLOGIAS LIBRES 51
1
stop)
if [ -f $PID_PATH_NAME ]; then
PID=$(cat $PID_PATH_NAME);
echo "$SERVICE_NAME stoping ..."
kill $PID;
echo "$SERVICE_NAME stopped ..."
rm $PID_PATH_NAME
else
echo "$SERVICE_NAME is not running ..."
fi
;;
restart)
if [ -f $PID_PATH_NAME ]; then
PID=$(cat $PID_PATH_NAME);
echo "$SERVICE_NAME stopping ...";
kill $PID;
echo "$SERVICE_NAME stopped ...";
rm $PID_PATH_NAME
echo "$SERVICE_NAME starting ..."
nohup java -jar $PATH_TO_JAR /tmp 2>> /dev/null >> /dev/null
&
echo $! > $PID_PATH_NAME
echo "$SERVICE_NAME started ..."
else
echo "$SERVICE_NAME is not running ..."
fi
;;
esac
Por último ejecute: service accomobiled start