un sistema de control inteligente de entrada/salida de...
TRANSCRIPT
I
Un sistema de control inteligente de
entrada/salida de humanos a un recinto
siguiendo la metodología VigilAgent Tomás de Teresa Trancón
Tomás de Teresa Trancón, Un sistema de control inteligente de entrada/salida de humanos
a un recinto siguiendo la metodología VigilAgent. Proyecto fin de carrera, Departamento
de Sistemas Informáticos, Universidad de Castilla-La Mancha, 2010.
III
UNIVERSIDAD DE CASTILLA-LA MANCHA
ESCUELA SUPERIOR DE INGENIERÍA INFORMÁTICA
Departamento de Sistemas Informáticos
PROYECTO FIN DE CARRERA
Un sistema de control inteligente de entrada/salida de
humanos a un recinto siguiendo la metodología VigilAgent
Autor: Tomás de Teresa Trancón
Directores: Antonio Fernández-Caballero
José Manuel Gascueña Noheda
Septiembre, 2010
IV
V
Resumen
Los sistemas de control de entrada/salida de humanos basan su funcionamiento en la
identificación de usuarios y el uso de barreras para impedir el paso a usuarios no
autorizados. Muchas veces los mecanismos de identificación y las barreras no son
suficientes para evitar situaciones no deseadas, por lo que en ocasiones los sistemas se
complementan con vigilantes de seguridad. En este proyecto se propone como alternativa
utilizar un Sistema Multi-Agente para solucionar los problemas de identificación, control y
detección de situaciones anómalas en sistemas de control de entrada/salida de humanos.
A lo largo de la presente memoria se describe el proceso llevado a cabo para modelar e
implementar un sistema inteligente que simula la colaboración necesaria para controlar
automáticamente la entrada/salida de humanos a/de un recinto cerrado. Este proceso sigue
las fases de la metodología VigilAgent, específica para la creación de sistemas de
seguridad basados en organizaciones de agentes.
VigilAgent se basa en dos metodologías de agentes suficientemente maduras,
Prometheus e INGENIAS, con el fin de guiar al desarrollador en las fases de análisis,
diseño e implementación. Durante las dos primeras fases de la metodología se obtiene un
modelo conforme a Prometheus, que posteriormente se transforma en otro modelo
expresado con el lenguaje utilizado en INGENIAS. Para la fase de implementación, se
genera automáticamente código para la infraestructura ICARO-T, tomando como base el
modelo desarrollado finalmente en INGENIAS. Por último, se completa el código
referente a la interacción entre entidades y se crean los interfaces gráficos pertinentes.
VI
VII
A mis padres.
VIII
IX
Agradecimientos
En primer lugar, Antonio Fernández-Caballero y a José M. Gascueña, por brindarme la
oportunidad de realizar este proyecto, por la ayuda prestada a lo largo de todo este tiempo
y por los conocimientos compartidos conmigo. Su dedicación y paciencia han sido
fundamentales para la finalización de este trabajo.
A mis padres, por todo lo que me han ayudado durante estos años, especialmente a mi
madre, por su confianza y por el ánimo que me ha dado en todo momento.
Por último y no menos importante, a Olaya, por haber sido para mi una fuente
inagotable de inspiración. De otra manera no habría llegado este momento.
X
XI
ÍNDICE
1. INTRODUCCIÓN .................................................................................................. 1
1.1. Motivación ......................................................................................................... 1
1.2. Objetivos y límites del proyecto ........................................................................ 2
1.3. Estructura de la memoria ................................................................................... 4
2. ESTADO DEL ARTE ............................................................................................. 5
2.1. Metodología Prometheus ................................................................................... 7
2.2. Metodología INGENIAS ................................................................................. 10
2.3. Metodología VigilAgent .................................................................................. 12
2.4. ICARO-T ......................................................................................................... 16
2.5. Sistemas de control de acceso de entrada/salida.............................................. 20
2.6. Sensores ........................................................................................................... 21
2.7. Metodología de desarrollo de redes de sensores mediante SMA .................... 22
3. MODELADO DEL SISTEMA ............................................................................ 25
3.1. Descripción del problema ................................................................................ 25
3.2. Fase de especificación del sistema .................................................................. 28
3.2.1. Identificación de la interacción del sistema con el entorno .................. 28
3.2.2. Desarrollo de escenarios ....................................................................... 29
3.2.3. Especificación de objetivos del sistema ................................................ 33
3.2.4. Descripción de roles .............................................................................. 34
3.3. Fase de diseño arquitectónico .......................................................................... 35
3.3.1. Identificación de tipos de agentes ......................................................... 35
3.3.2. Especificación de acoplamiento de datos ............................................. 35
3.3.3. Descripción de las interacciones ........................................................... 36
3.3.4. Descripción de la arquitectura global del sistema ................................ 41
3.4. Fase de diseño detallado .................................................................................. 43
3.4.1. Transformación de estructuras de Prometheus a INGENIAS .............. 43
3.4.2. Identificación de tareas ......................................................................... 54
3.4.3. Especificación del modelo de comportamiento de los agentes ............. 59
3.4.4. Crear diagrama de componentes ........................................................... 73
3.4.5. Crear diagrama de despliegue ............................................................... 74
4. IMPLEMENTACIÓN .......................................................................................... 77
4.1. Fase de generación de código ........................................................................ 77
4.2. Mejora de la aplicación .................................................................................... 88
4.3. Pruebas ............................................................................................................. 94
XII
5. CONCLUSIONES Y TRABAJOS FUTUROS .................................................. 95
5.1. Métricas ........................................................................................................... 95
5.2. Conclusiones .................................................................................................... 98
5.3. Trabajos futuros ............................................................................................. 100
6. ANEXO: CONFIGURACIÓN Y USO .............................................................. 101
6.1. Configuración de la aplicación ...................................................................... 101
6.2. Uso de la aplicación ....................................................................................... 102
7. BIBLIOGRAFÍA ................................................................................................. 105
XIII
ÍNDICE DE FIGURAS
Figura 2.1. Modelo de agente ......................................................................................... 5
Figura 2.2. Ventana de la herramienta PDT ................................................................... 9
Figura 2.3. Ventana de la herramienta IDK .................................................................. 12
Figura 2.4. Fases de la metodología VigilAgent .......................................................... 15
Figura 2.5. Ciclo de trabajo básico de un agente reactivo ............................................ 17
Figura 2.6. Capas de una aplicación ICARO-T ............................................................ 19
Figura 2.7. MDD de aplicaciones ICARO-T utilizando IDK ....................................... 20
Figura 2.8. Proceso de desarrollo en redes de sensores ................................................ 23
Figura 3.1. Vista general ............................................................................................... 26
Figura 3.2. Módulo de entrada ...................................................................................... 26
Figura 3.3. Diagrama de visión general del análisis ..................................................... 29
Figura 3.4. Diagrama de escenarios .............................................................................. 30
Figura 3.5. Escenario Controlar Entrada scenario ........................................................ 31
Figura 3.6. Escenario Controlar Salida scenario ........................................................... 31
Figura 3.7. Escenario Bloquear Puerta scenario ........................................................... 32
Figura 3.8. Escenario Tailgating scenario .................................................................... 32
Figura 3.9. Escenario Deshabilitar Modulo scenario .................................................... 33
Figura 3.10. Diagrama de visión general de objetivos ................................................. 33
Figura 3.11. Diagrama de roles del sistema .................................................................. 34
Figura 3.12. Diagrama de agrupamiento Agente-Rol ................................................... 35
Figura 3.13. Diagrama de acoplamiento de datos ......................................................... 36
Figura 3.14. Protocolo PI Identificación ....................................................................... 37
Figura 3.15. Protocolo PI Acceso ................................................................................. 39
Figura 3.16. Protocolo PI Tailgating ............................................................................ 40
Figura 3.17. Protocolo PI Puerta Bloqueada Usuario ................................................... 41
Figura 3.18. Diagrama de visión general del sistema ................................................... 42
Figura 3.19. Diagrama de comunicación de agentes .................................................... 42
Figura 3.20. Transformación de una percepción .......................................................... 44
Figura 3.21. Transformación de una acción ................................................................. 44
Figura 3.22. Transformación de un mensaje ................................................................. 45
Figura 3.23. Transformación de un dato ....................................................................... 45
Figura 3.24.a. Diagrama de entorno ............................................................................. 51
Figura 3.24.b. Diagrama de entorno ............................................................................. 52
Figura 3.25.a. Diagrama de interacción ........................................................................ 53
Figura 3.25.b. Diagrama de interacción ........................................................................ 54
Figura 3.26. Comportamiento de un agente .................................................................. 59
Figura 3.27.a. Autómata del agente agLector obtenido en INGENIAS ....................... 60
Figura 3.27.b. Autómata del agente agLector ............................................................... 61
Figura 3.28.a. Autómata del agente agPuerta obtenido en INGENIAS ....................... 62
XIV
Figura 3.28.b. Autómata del agente agPuerta ............................................................... 62
Figura 3.29.a. Autómata del agente agSensorInfrarrojo obtenido en INGENIAS ....... 64
Figura 3.29.b. Autómata del agente agSensorInfrarrojo ............................................... 64
Figura 3.30.a. Autómata del agente agSensorContacto obtenido en INGENIAS ......... 66
Figura 3.30.b. Autómata del agente agSensorContacto ................................................ 67
Figura 3.31.a. Autómata del agente agTailgating obtenido en INGENIAS ................. 68
Figura 3.31.b. Autómata del agente agTailgating ......................................................... 69
Figura 3.32.a. Autómata del agente agPuertaBloqueada obtenido en INGENIAS ....... 70
Figura 3.32.b. Autómata del agente agPuertaBloqueada .............................................. 71
Figura 3.33.a. Autómata del agente agIntercomunicador obtenido en INGENIAS ..... 72
Figura 3.33.b. Autómata del agente agIntercomunicador ............................................. 73
Figura 3.34. Diagrama de componentes ........................................................................ 74
Figura 3.35. Diagrama de despliegue ............................................................................ 75
Figura 4.1. Fragmento del fichero XML del despliegue de la aplicación ..................... 78
Figura 4.2. Descripción de una instancia del agente agSensorInfrarrojo ...................... 78
Figura 4.3. Descripción de la instancia del recurso BDD ............................................. 79
Figura 4.4. Estructura de paquetes de la aplicación ................................................. 80
Figura 4.5. Fragmento de código del autómata del agente agTailgating ...................... 80
Figura 4.6. Esqueleto generado para la acción aNotificarTailgating ............................ 81
Figura 4.7. Implementación final de la acción NotificarTailgating .............................. 82
Figura 4.8. Método cortarInfrarrojo del recurso acSensorInfrarrojo ............................ 83
Figura 4.9. Fragmento de la acción semántica ComunicarInfrarrojoCortado
del agente agSensorInfrarrojo ....................................................................... 84
Figura 4.10. Paquete del recurso acSensorInfrarrojo .................................................... 84
Figura 4.11. Diagrama de clases relacionadas con el recurso acSensorInfrarrojo ........ 85
Figura 4.12. Ventana que genera la clase InterfazCentralita ........................................ 86
Figura 4.13. Ventana que genera la clase InterfazLector .............................................. 86
Figura 4.14. Ventana que genera la clase InterfazSensorInfrarrojo .............................. 87
Figura 4.15. Ventana que genera la clase InterfazSensorContacto ............................... 87
Figura 4.16. Recurso de trazas de ICARO-T ................................................................ 87
Figura 4.17. Aspecto de la aplicación tras su lanzamiento ........................................... 88
Figura 4.18. Fragmento del diagrama de entorno ......................................................... 90
Figura 4.19.a. Automáta del agente agLector en INGENIAS ...................................... 91
Figura 4.19.b. Automáta del agente agLector ............................................................... 92
Figura 4.20. Fragmento del fichero entradaLectores.xml ............................................. 93
Figura 4.21. Interfaz de la aplicación Reloj .................................................................. 93
Figura 5.1. Tiempo de desarrollo del proyecto por fases .............................................. 96
Figura 5.2. Tiempo dedicado a la implementación de cada módulo ............................. 97
Figura 6.1. Estructura de directorios propuesta .......................................................... 102
Figura 6.2. Ventana CENTRALITA ........................................................................... 102
XV
Figura 6.3. Ventana L 1 .............................................................................................. 103
Figura 6.4. Ventana C1 ............................................................................................... 103
Figura 6.5. Ventana IR 1 ............................................................................................. 104
Figura 6.6. Ventana Reloj ........................................................................................... 104
Figura 6.7. Detalle del Modulo 1 ................................................................................ 104
XVI
XVII
ÍNDICE DE TABLAS
Tabla 3.1. Descripción de las entidades ........................................................................ 27
Tabla 3.2. Descripción de los roles ............................................................................... 34
Tabla 3.3. Equivalencia entre conceptos de Prometheus e INGENIAS ....................... 46
Tabla 3.4. Agentes obtenidos desde Prometheus .......................................................... 46
Tabla 3.5. Aplicaciones obtenidas a partir de los actores de Prometheus .................... 47
Tabla 3.6. Leyenda ........................................................................................................ 47
Tabla 3.7. Aplicación acLector ..................................................................................... 47
Tabla 3.8. Aplicación acPuerta ..................................................................................... 47
Tabla 3.9. Aplicación acSensorInfrarrojo ..................................................................... 48
Tabla 3.10. Aplicación acSensorContacto .................................................................... 48
Tabla 3.11. Aplicación acCentralita ............................................................................. 48
Tabla 3.12. Aplicación BDD ........................................................................................ 49
Tabla 3.13. Métodos auxiliares de la aplicación acLector ............................................ 49
Tabla 3.14. Métodos auxiliares de la aplicación acSensorInfrarrojo ............................ 49
Tabla 3.15 Métodos auxiliares de la aplicación acSensorContacto .............................. 50
Tabla 3.16. Métodos auxiliares de la aplicación acCentralita ...................................... 50
Tabla 3.17. Acciones ejecutadas por el agente agLector .............................................. 55
Tabla 3.18. Acciones ejecutadas por el agente agPuerta .............................................. 55
Tabla 3.19. Acciones ejecutadas por el agente agSensorInfrarrojo .............................. 55
Tabla 3.20. Acciones ejecutadas por el agente agSensorContacto ............................... 56
Tabla 3.21. Acciones ejecutadas por el agente agTailgating ........................................ 57
Tabla 3.22. Acciones ejecutadas por el agente agPuertaBloqueada ............................. 57
Tabla 3.23. Acciones ejecutadas por el agente agIntercomunicador ............................ 58
Tabla 3.24. Eventos recibidos por el agente agLector .................................................. 60
Tabla 3.25. Eventos recibidos por el agente agPuerta .................................................. 61
Tabla 3.26. Eventos recibidos por el agente agSensorInfrarrojo .................................. 63
Tabla 3.27. Eventos recibidos por el agente agSensorContacto ................................... 66
Tabla 3.28. Eventos recibidos por el agente agTailgating ............................................ 68
Tabla 3.29. Eventos recibidos por el agente agPuertaBloqueada ................................. 70
Tabla 3.30. Eventos recibidos por el agente agIntercomunicador ................................ 71
Tabla 4.1. Aplicación Reloj .......................................................................................... 89
Tabla 4.2. Métodos añadidos a la aplicación acLector ................................................. 90
Tabla 4.3. Acciones semánticas añadidas al agente agLector ...................................... 91
Tabla 4.4. Eventos recibidos por el agente agLector .................................................... 91
XVIII
1
1. INTRODUCCIÓN
1.1. Motivación
En la actualidad se está produciendo una demanda cada vez mayor de sistemas de
control de accesos para llevar a cabo la organización del tránsito humano, la gestión de
diversas zonas de seguridad y el registro de sucesos en tiempo real. La mayoría de estos
sistemas basan su uso en la identificación mediante tarjetas o mediante el código
introducido utilizando un teclado. Generalmente, los sistemas de control de entrada/salida
incorporan además una barrera, una puerta o un sistema de barreras y/o puertas para
impedir el paso a usuarios no autorizados. Los costos de estos sistemas varían ampliamente
en función del nivel de seguridad que son capaces de proporcionar. En muchas ocasiones,
los sistemas se acompañan de presencia humana para evitar situaciones en las que los
sistemas pueden fallar. Un ejemplo son las intrusiones que se producen aprovechando el
acceso de usuarios autorizados. El problema en muchos casos es que la introducción de
vigilantes de seguridad no compensa el perjuicio económico que tratan de evitar.
Los Sistemas Multi-Agente (SMA) pueden resolver el compromiso entre pérdidas e
inversión ofreciendo sistemas inteligentes más asequibles y baratos de mantener. En primer
lugar, sustituyendo las costosas barreras mecánicas por puertas sencillas pero efectivas,
provistas de sensores capaces de proporcionar información a los agentes. En segundo
lugar, haciendo innecesaria la utilización de vigilantes en cada punto de acceso o salida,
siendo suficiente con un vigilante de seguridad para supervisar todo lo que ocurre desde
una centralita. Por lo tanto, el trabajo de vigilancia puede efectuarse por una organización
de agentes que cooperan para detectar la intrusión de personas no autorizadas, basándose
en la información proporcionada por los sensores y alertando al vigilante cuando sucedan
situaciones anómalas.
Un sistema de vigilancia se puede entender como una red compleja, compuesta por un
gran número de sensores distribuidos por el entorno físico que producen diferentes tipos de
información. Dicha información es percibida del entorno con el fin de contribuir a realizar
una labor de vigilancia determinada. Los SMA pueden utilizarse para el desarrollo de este
tipo de sistemas mediante el modelado flexible de entidades autónomas. El concepto de
agente aplicado a sensores permite convertir a éstos en entidades inteligentes que, además
de percibir el entorno, pueden reaccionar ante los cambios que se producen y comunicarse
entre sí con el fin de alcanzar objetivos comunes. Por cada sensor existe un agente software
que lo gestiona. Esta aproximación al problema simplifica sustancialmente la manera de
controlar y coordinar los sensores, a la vez que distribuye la carga de trabajo entre los
agentes que forman el sistema. Los SMA se presentan como una tecnología idónea para su
uso en redes de sensores, contribuyendo a mejorar su escalabilidad y dotándolas de
flexibilidad, robustez y autonomía. En resumen, debido a la analogía descrita previamente
2
entre las redes de sensores y los sistemas de vigilancia, la tecnología de los SMA también
resulta adecuada para aplicarla en el desarrollo de los sistemas de vigilancia inteligentes.
Actualmente no se conoce la existencia de un sistema de control de entrada/salida de
humanos basado en agentes que esté implementado en un entorno complejo, como puede
ser por ejemplo, en una entrada/salida al/del metro en horas punta. La aplicación de la
metodología VigilAgent resulta interesante para comprobar la viabilidad del desarrollo de
un sistema de control inteligente de entrada/salida porque se trata de una metodología que
puede facilitar y mejorar la labor de desarrollo de SMAs orientados a la vigilancia de
sistemas complejos. VigilAgent está basada en dos metodologías suficientemente maduras,
Prometheus e INGENIAS, con el fin de guiar al desarrollador durante las fases de análisis,
diseño e implementación, utilizando la infraestructura ICARO-T en la realización de la
última fase. Este proyecto permite estudiar más a fondo la problemática asociada al control
de entrada/salida, así como sentar las bases para futuros desarrollos basados en la
metodología VigilAgent. El problema se abordará en un entorno simulado.
1.2. Objetivos y límites del proyecto
El objetivo global que se plantea en el presente trabajo se puede resumir como sigue:
“Desarrollar un sistema inteligente, siguiendo la metodología de agentes VigilAgent,
capaz de detectar las situaciones anómalas que se producen en un entorno que simula la
entrada y salida de humanos en un recinto cerrado”.
El objetivo global mencionado anteriormente, se puede descomponer a su vez en los
objetivos particulares que se detallan a continuación:
1. Estudio de los Sistemas Multi-Agente. Se estudiará la rama de la inteligencia
artificial distribuida que trata los agentes y sistemas de agentes: sus características y
los problemas que pueden resolver.
2. Conocimiento de la Ingeniería del Software Orientada a Agentes (AOSE). Se
estudiarán diferentes metodologías para el desarrollo de software orientado a
agentes, centrando especialmente la atención en aquellas en las que se basa
VigilAgent.
3. Estudio de sistemas de control para la entrada y salida. Se investigará acerca de
los sistemas de control de entrada/salida para adquirir los conocimientos necesarios
en el tema en cuestión.
4. Investigación en sensores aplicados a la vigilancia y control automáticos. Se
investigarán los tipos de sensor más utilizados en sistemas automáticos de
vigilancia y control.
3
5. Prevención de situaciones anómalas en el funcionamiento del sistema. Se
identificarán las situaciones anómalas que pueden alterar el funcionamiento normal
del sistema.
6. Toma de decisiones y previsión de sus efectos durante las fases de diseño de
software. Las decisiones de diseño se tomarán con sumo cuidado, tratando de
evitar errores que puedan afectar negativamente al sistema.
7. Integración de las metodologías Prometheus e INGENIAS para el diseño de
software orientado a agentes. La integración se realizará tal y cómo describe la
metodología VigilAgent.
8. Conocimiento de la plataforma ICARO-T. Se aprenderán los conceptos
utilizados en la infraestructura ICARO-T para implementar aplicaciones
distribuidas de organizaciones de agentes.
9. Procesos de intercomunicación entre agentes. Se estudiará cómo se implementa
la comunicación entre agentes en ICARO-T.
10. Implementación del software siguiendo los modelos definidos en el diseño. Se
implementará el software conforme al diseño realizado.
11. Adición de nuevas funcionalidades en la aplicación. Una vez entregada la
aplicación que satisface los requisitos iniciales se nos plantea la incorporación de
un nuevo requisito. Para ello, se volverá a iterar en el ciclo de vida de desarrollo de
software para integrar la nueva funcionalidad en la aplicación.
12. Documentación del proceso de desarrollo de software. Se detallará todo el
proceso seguido para desarrollar la aplicación.
Dados los objetivos del proyecto es necesario establecer unos límites para centrar la
atención de la problemática concreta a abordar en el caso de estudio. No se pretende
obtener un sistema aplicable al mundo real, sino un sistema que funcione en un entorno
simulado. Se desea que el sistema permita la realización de múltiples pruebas, así como el
estudio de la problemática abordada, con la finalidad de poder aplicarlo en el futuro al
desarrollo de otros sistemas basados en la misma tecnología y cuyo fin sea su aplicación en
un entorno simulado o real. Por lo tanto, las situaciones que sucedan durante la simulación
pueden no ajustarse a lo esperado en casos reales. Tampoco se pretende obtener fórmulas
óptimas para detectar todas las situaciones anómalas posibles que se pueden presentar en
un sistema de control de entrada salida, sino tan sólo aquellas que se planteen en la
descripción del problema a abordar en el presente proyecto.
4
1.3. Estructura de la memoria
El capítulo 1, “Introducción”, explica el motivo por el que se ha desarrollado este
proyecto así como los objetivos que se desean alcanzar.
El capítulo 2, “Estado del arte”, introduce conceptos de los Sistemas Multi-Agente y
describe algunas de las principales metodologías de desarrollo software orientado a
agentes. En particular se detalla la metodología VigilAgent utilizada en el desarrollo de
este proyecto, así como las metodologías Prometheus e INGENIAS que dieron origen a
VigilAgent, y la infraestructura orientada a agentes ICARO-T.
El capítulo 3, “Modelado del sistema”, explica todo el proceso de modelado del
sistema siguiendo la metodología VigilAgent. Las dos primeras fases, especificación del
sistema y diseño arquitectónico, se desarrollan utilizando la herramienta Prometheus
Design Tool (PDT) que ofrece soporte a la metodología Prometheus. La tercera fase,
diseño detallado, se desarrolla utilizando la herramienta INGENIAS Development Kit
(IDK) que ofrece soporte a la metodología INGENIAS.
El capítulo 4, “Implementación”, detalla el proceso de implementación del sistema a
partir del diseño desarrollado en el capítulo anterior. Se detalla la generación de código
obtenida utilizando la herramienta IDK y cómo se completa la implementación de la
aplicación.
El capítulo 5, “Conclusiones y trabajos futuros”, describe las conclusiones obtenidas
tras la finalización de la aplicación, indicando sugerencias para posibles mejoras en
Sistemas Multi-Agente de características similares, así como sistemas que utilicen la
metodología VigilAgent.
5
2. ESTADO DEL ARTE
Los agentes nacieron de la investigación en Inteligencia Artificial (IA) y más
concretamente de la Inteligencia Artificial Distribuida (IAD), que integra la IA con los
Sistemas Distribuidos. Un agente (véase figura 2.1) es una entidad física o abstracta que
percibe su ambiente a través de sensores, es capaz de evaluar las percepciones y tomar
decisiones por medio de mecanismos de razonamiento, comunicarse con otros agentes para
obtener información y actuar sobre su entorno a través de efectores (Fernández-Caballero,
Gascueña, 2009).
Figura 2.1 Modelo de agente
Un agente puede trabajar solo o en cooperación con otros agentes con el fin de
satisfacer uno o varios objetivos. En el segundo caso se habla de Sistemas Multi-Agente
(SMA), es decir, sistemas formados por un conjunto de agentes que interaccionan entre sí
para alcanzar objetivos comunes. Estos sistemas se sitúan en un entorno que proporciona a
cada agente información que modifica su estado mental, activando mecanismos de
razonamiento que desencadenan la ejecución de acciones y la comunicación con otros
agentes para alcanzar los objetivos marcados. Integrados en el entorno, debe haber objetos
de tal forma que puedan ser percibidos, creados, destruidos o modificados por los agentes.
Por esto, cada agente debe disponer de un conjunto de operaciones que le permitan
percibir, producir, consumir, transformar y manipular dichos objetos. Además, cada agente
debe perseguir uno o varios objetivos. Por lo tanto, para poder hablar de un SMA, es
necesario que el sistema reúna los siguientes elementos: un conjunto de agentes, un
entorno y un conjunto de objetos.
Existen varias metodologías para desarrollar estos sistemas y cada una de ellas tiene
unas características particulares que la hacen más adecuada para ciertos proyectos. A
continuación se describen brevemente algunas de las metodologías más utilizadas en el
desarrollo de SMA.
Percepción
Acción
AGENTE Entorno
EFECTOR
SENSOR
6
- MAS-CommonKADS. Extiende al campo de los SMA la metodología
CommonKADS, para sistemas expertos, utilizando estructuración orientada a
objetos y lenguajes de especificación de protocolos. Gira alrededor del modelo de
experiencia y está pensada para desarrollar sistemas expertos que interactúen con el
usuario. Además, plantea el desarrollo de SMA integrado en el ciclo de vida
software denominado espiral.
- MaSE (Multi-agent systems Software Engineering). Parte del paradigma orientado
a objetos y asume que un agente es la especialización de un objeto. Los agentes se
coordinan unos con otros vía conversaciones y actúan proactivamente para alcanzar
metas individuales y globales. El proceso de desarrollo en MaSE consta de las
siguientes etapas: captura de objetivos, aplicación de casos de uso, refinamiento de
roles, creación de las clases de agentes, construcción de las conversaciones,
ensamblaje de las clases de agentes y diseño del sistema. La mayoría de estas fases
están soportados por la herramienta AgentTool.
- ZEUS. Combina distintos resultados de investigación en agentes (planificación,
ontologías, asignación de responsabilidades, relaciones sociales entre agentes) en
un sistema ejecutable. ZEUS propone un desarrollo en cuatro etapas: el análisis del
dominio, el diseño de los agentes, la realización de los agentes y el soporte en
tiempo de ejecución. Estas etapas están basadas en el uso de roles para analizar el
dominio y la asignación de roles a agentes.
- GAIA. Propone cómo realizar un análisis basado en los roles del SMA. El objetivo
es comprender el sistema y su estructura, sin referenciar ninguna característica de la
implementación, con el fin de de obtener un diseño suficientemente detallado como
para poder ser implementado directamente. Esto se consigue a través de la idea de
organización, la cual es una colección de roles que mantienen relaciones entre sí y
toman parte en patrones institucionalizados de interacción con otros roles. Los roles
agrupan cuatro aspectos: las responsabilidades del agente, los recursos que se le
permite utilizar, las tareas asociadas y las interacciones.
Las metodologías Prometheus e INGENIAS son de especial interés por ser la base de la
metodología VigilAgent, utilizada en el desarrollo de este proyecto. En las siguientes
secciones se describen detalladamente ambas metodologías.
7
2.1. Metodología Prometheus
La metodología Prometheus define un proceso detallado para especificar, diseñar,
implementar y probar/depurar sistemas software orientados a agentes. Propone un proceso
de desarrollo iterativo que consta de tres fases: especificación del sistema, diseño
arquitectónico y diseño detallado. Además, detalla cómo seguir el proceso y qué resultados
se obtienen en cada fase (Padgham, Winikoff, 2004).
La fase de especificación del sistema consiste en identificar los objetivos y
funcionalidades básicas del sistema, desarrollar los escenarios que ilustran el
funcionamiento del sistema y especificar las entradas y salidas del sistema (percepciones y
acciones, respectivamente). Los objetivos son un mecanismo para especificar los requisitos
del sistema, es decir, permiten identificar por qué razones se está construyendo el sistema.
El proceso de especificación de objetivos se recomienda hacer en dos pasos. El primero
consiste en identificar los objetivos iníciales a partir de los requisitos proporcionados. El
segundo paso consiste en refinar los objetivos agrupándolos por sus similitudes, de tal
modo que pueda obtenerse un grupo de objetivos por cada funcionalidad que deba soportar
el sistema. Es preciso resaltar que una funcionalidad describe un fragmento del
comportamiento del sistema. Los escenarios describen el funcionamiento del sistema
ilustrando la ejecución normal del sistema, así como las situaciones en las que se den
sucesos anormales (alternativos). Un escenario se especifica en varios pasos, haciendo
evidente dónde se necesita información del entorno y dónde es necesario realizar
actuaciones. La información recogida del entorno se denomina percepción en la
metodología Prometheus y constituye la entrada al sistema.
La fase de diseño arquitectónico toma los artefactos producidos en la fase anterior para
identificar los tipos de agentes que existirán en el sistema y cómo interactuarán entre ellos
para alcanzar los objetivos del sistema. Cada agente debe ser responsable de al menos una
de las funcionalidades identificadas en la fase anterior. Por ello, para identificarlos se
agrupan funcionalidades considerando todas las alternativas posibles de tal modo que
finalmente se considere aquella agrupación que tenga una mayor cohesión y un mínimo
acoplamiento. Otra tarea importante en esta fase consiste en especificar las interacciones
que se producen entre agentes. En este caso, estas se describen mediante protocolos de
interacción que incluyen los mensajes que se envían los agentes entre sí, qué percepciones
llegan a los agentes y qué acciones efectúan sobre el entorno.
Por último, la fase de diseño detallado consiste en desarrollar la estructura interna de
cada agente identificado previamente y detallar cómo llevar a cabo sus tareas dentro del
sistema global. Para ello, se especifican las capacidades necesarias que cada agente tiene
para satisfacer sus responsabilidades, además de desarrollar los protocolos con el objetivo
de indicar el procesamiento interno de cada agente individualmente.
8
Una vez especificado el sistema se utiliza la herramienta Prometheus Design Tool
(PDT) (Padgham, Thangarajah, Paul) para generar el código que sirve de base para
implementar la aplicación en el lenguaje de programación Jack.
La herramienta PDT permite llevar a cabo el diseño de un SMA siguiendo la
metodología Prometheus. Proporciona una ventana principal dividida en cuatro áreas: la
lista de diagramas, la vista del diagrama, la lista de entidades y la vista de descripción de
entidades (véase figura 2.2).
La lista de diagramas presenta de manera ordenada cada una de las fases de la
metodología (especificación del sistema, diseño arquitectónico y diseño detallado)
e incluye los diferentes tipos de diagramas que se crean en cada una de ellas.
La vista del diagrama permite visualizar y especificar el diagrama seleccionado en
la lista de diagramas. Para ello ofrece una paleta con las entidades que pueden
incluirse en el diagrama seleccionado.
La lista de entidades muestra de forma ordenada todas y cada una de las entidades
existentes en el diseño del sistema, es decir, muestra todos los agentes, los actores,
las percepciones, las acciones, los mensajes, los roles, los datos, los escenarios y los
protocolos de interacción que forman parte de cada uno de los diagramas que
componen el diseño del sistema.
La vista de descripción de entidades muestra una descripción detallada de la
entidad seleccionada en la lista de entidades o en la vista del diagrama. Además,
permite añadir o modificar cualquier detalle de la descripción.
El menú de la herramienta ofrece, a parte de las opciones esperadas en una herramienta
de este tipo, una opción denominada Crosscheck para comprobar la consistencia del diseño
y conocer, antes de generar el código, si el diseño obtenido se ajusta por completo a lo
especificado en la metodología Prometheus. Otro detalle relevante es la posibilidad de
utilizar la opción Complete HTML Report para generar automáticamente un informe
completo de la especificación en HTML. Por último, comentar que tras completar el
diseño, comprobar la consistencia y generar el informe, se puede utilizar la opción
Generate Code para generar automáticamente una base de código que permitirá iniciar la
implementación del sistema en el lenguaje JACK1.
1 JACK Intelligent Agents (JACK) es un entorno de desarrollo orientado a agentes construido sobre y
completamente integrado con el lenguaje de programación Java.
9
Figura 2.2. Ventana de la herramienta PDT
A continuación se describen algunos conceptos fundamentales utilizados en la
metodología Prometheus:
- Percepción. Ítem de información del entorno recogida por algún tipo de sensor.
- Acción. Aquello que hace el agente y que puede ser de dos tipos, acción externa y
acción interna. Una acción externa es la que produce cambios en el entorno,
mientras que una acción interna es aquella que no afecta al entorno y que necesita
realizar el agente, como por ejemplo, el acceso a una base de datos.
- Objetivo. Algo en lo que está trabajando el agente y hacia lo que se dirige.
- Evento. Un suceso significativo al que el agente debe responder de alguna forma.
Una percepción es un tipo particular de evento.
- Mensaje. Unidad de interacción entre agentes, la cual se utiliza siguiendo un
protocolo definido.
- Protocolo: Definición de patrones de interacción permitidos.
10
2.2. Metodología INGENIAS
La metodología INGENIAS (Gómez, Pavón) propone un proceso de desarrollo basado
en el Proceso Unificado de Desarrollo de Software (Unified Software Development
Process o RUP) para desarrollar SMA2. Durante este proceso se generan una serie de
modelos que se detallan a continuación:
- Modelo de organización. Describe la estructura del SMA, los roles y los flujos de
trabajo (workflows).
- Modelo de entorno. Describe las entidades y relaciones con el entorno del SMA.
- Modelo de agente. Describe los agentes del sistema, así como sus
responsabilidades, control y estado mental.
- Modelo de objetivos y tareas. Identifica los objetivos y tareas generales del
sistema, los cuales pueden asignarse a agentes.
- Modelo de interacción. Describe las interacciones existentes entre agentes.
Estos modelos se especifican en los flujos de análisis y diseño (Gómez, 2002), los
cuales se dividen a su vez en tres fases, inicio, elaboración y construcción, de acuerdo al
modelo iterativo RUP. La fase de análisis-inicio identifica los componentes que utilizan
los agentes para interactuar con el entorno y especifica los casos de uso más relevantes.
Los componentes se traducen en aplicaciones que especifican las acciones que pueden
ejecutar los agentes, así como las percepciones de los agentes. La fase de diseño-inicio
consiste en elaborar un prototipo del sistema que muestra cómo interactúa el usuario con la
aplicación y qué tipo de resultados se esperan. En la fase de análisis-elaboración se
analizan los casos de uso, obtenidos en la etapa anterior, para generar la arquitectura del
sistema. Para ello se refinan los casos de uso y se asocian con modelos de interacciones. La
fase de diseño-elaboración aumenta el nivel de detalle de la especificación determinando
cómo se llevan a cabo los casos de uso identificados. Los resultados que se obtienen se
centran en refinar los flujos de trabajo y las tareas asociadas, las interacciones, cómo es el
control del agente y cómo se satisfacen los objetivos del sistema. El modelo de
organización se refina asociando tareas a los flujos de trabajo. El modelo de interacción se
detalla añadiendo relaciones con los flujos de trabajo. Tras desarrollar los casos de uso
necesarios para determinar la arquitectura del sistema, se pasa a la fase de análisis-
construcción para identificar los casos de uso restantes sin modificar sustancialmente la
visión del sistema que se tiene hasta ahora del sistema. En la fase de diseño-construcción
se detallan las relaciones sociales, principalmente las relaciones de subordinación y las
relaciones cliente-servidor.
2 Recientemente también se ha formalizado el proceso de acuerdo a SCRUM, pudiéndose elegir
dinámicamente el proceso que mejor se adapte a las características del proyecto abordado.
11
INGENIAS Development Kit (IDK) es una colección de herramientas para especificar,
verificar e implementar SMA. La primera de estas herramientas es un editor gráfico, que
permite al desarrollador crear y modificar especificaciones de un SMA utilizando
conceptos del lenguaje de INGENIAS. Cada entidad puede visualizarse gráficamente con
la notación de UML o utilizando la notación propia definida en la metodología
INGENIAS. La ventana principal del editor se divide en cuatro áreas de forma muy similar
a la herramienta PDT descrita previamente (véase figura 2.3).
El área de proyecto muestra en una estructura arbórea todos los diagramas del
proyecto. Estos pueden ser de los tipos siguientes: modelo de entorno, modelo de
organización, modelo de tareas y objetivos, modelo de interacción, modelo de
agente, diagrama de componentes, diagrama de actividad, diagrama de casos de
uso, diagrama de interacción AUML y diagrama de despliegue.
En el área de diagramas se visualizan los diagramas seleccionados en el área del
proyecto. En el área de diagramas se crea una pestaña por cada modelo visualizado
y ofrece una paleta para crear las entidades específicas de cada tipo de diagrama.
El área de Logs, localizada en la parte inferior del área de diagramas, se utiliza para
mostrar informes de la herramienta y para mostrar los detalles descriptivos de la
entidad seleccionada.
El área de entidades muestra jerárquicamente todas las entidades existentes en el
modelo.
El segundo tipo de herramientas disponibles en el IDK son los módulos o pluggins.
Estos requieren de especificaciones de SMA modelados con el lenguaje INGENIAS para
verificar sus propiedades y generar automáticamente el código asociado al modelo. El
soporte de este tipo de herramientas permite a los desarrolladores extender la funcionalidad
de IDK creando sus propios módulos de acuerdo a sus necesidades. Este es el caso del
módulo disponible para generar, automáticamente, código para la plataforma ICARO-T.
Este módulo se ha utilizado en el desarrollo de este proyecto como parte de la metodología
VigilAgent, la cual se describe más adelante.
12
Figura 2.3. Ventana de la herramienta IDK
2.3. Metodología VigilAgent
El ciclo de vida software de VigilAgent se divide en cinco fases, tal y como se describe
en (Gascueña, 2010). Dichas fases son: especificación del sistema, diseño arquitectónico,
diseño detallado, implementación y despliegue (véase figura 2.4).
En la fase de especificación del sistema, el analista de software identifica, a partir de la
descripción proporcionada por el cliente, los requisitos del sistema y el entorno en el que
va a estar situada la aplicación. Esta fase se desarrolla mediante las siguientes actividades:
La primera de ellas consiste en determinar las interacciones existentes entre el
sistema y el entorno. Para ello es necesario identificar, en primer lugar, los
actores del sistema. Estos son cualquier entidad humana, software o hardware
que interacciona con el sistema. Seguidamente deben identificarse las entradas
y salidas del sistema, es decir, las percepciones y acciones, respectivamente.
Estas se definen como la información del entorno que estará disponible para el
sistema (percepciones) y lo que hará el sistema para interactuar sobre el entorno
(acciones). Posteriormente, deben identificarse los escenarios iniciales que
13
describen el comportamiento del sistema. Por último, se establecen relaciones
entre cada una de las entidades identificadas (actoracción, actorpercepción,
escenarioacción y escenariopercepción).
La segunda actividad consiste en desarrollar los escenarios identificados
previamente. Para ello debe describirse el flujo normal de un escenario.
Además, también se deben describir todas las alternativas posibles a un
escenario. Cada paso del escenario está etiquetado como una acción, una
percepción, un objetivo u otro escenario.
La tercera actividad consiste en identificar los objetivos del sistema a partir de
la descripción del problema. Un objetivo es aquello que debe poder conseguir o
resolver el sistema. Es la razón por la que se construye. Por lo tanto, una vez
identificados los objetivos iníciales, estos deben refinarse y reagruparse
relacionando objetivos con subobjetivos.
La última actividad consiste en describir los roles del sistema. Un rol es un
trozo de comportamiento del sistema. Un rol se obtiene a partir de la agrupación
de objetivos y debe poder describirse mediante un nombre único, pues una
descripción demasiado extensa indica que el rol debe dividirse en varios roles.
La fase de diseño arquitectónico consiste en determinar los tipos de agente que hay en
el sistema y cómo interactúan entre ellos. Esta fase se desarrolla con las cuatro actividades
siguientes:
La primera actividad consiste en especificar el acoplamiento de datos, es decir,
identificar los datos necesarios, para que el sistema pueda llevar a cabo el
comportamiento asociado, y establecer las relaciones de lectura/escritura entre
los datos identificados y los roles obtenidos en la fase previa.
La segunda actividad consiste en identificar los tipos de agente existentes en el
sistema. Esta actividad se debe hacer agrupando los roles del sistema para
obtener agentes independientes en su comportamiento, es decir, dos tipos de
agente no deben compartir un mismo rol, por lo tanto deben evaluarse las
agrupaciones obtenidas mediante criterios de cohesión3 y acoplamiento
4. Se
considera como mejor agrupación a aquella que tiene una mayor cohesión y un
mínimo acoplamiento. A partir de la asignación de roles a un agente se obtienen
los objetivos asociados al agente, las percepciones ante las que reacciona, las
acciones que efectúa y los datos que consume y/o produce.
3 La cohesión hace referencia al agrupamiento de agentes que desempeñan la misma funcionalidad.
4 El acoplamiento hace referencia al grado de dependencia entre agentes.
14
La tercera actividad consiste en describir las interacciones entre agentes
mediante protocolos de interacción. La representación gráfica se obtiene a partir
de sentencias textuales. Los protocolos se desarrollan a partir de los escenarios
especificados en la fase de especificación del sistema e incluyen las acciones,
las percepciones y los mensajes mediante los cuales los agentes interaccionan
entre sí, y éstos con sus actores asociados.
La última actividad consiste en diseñar la arquitectura global del sistema para
recoger en una sola vista la información recogida en las actividades previas. Se
obtiene un diagrama que muestra las relaciones que hay entre los agentes y las
percepciones, los agentes y las acciones, los agentes y los datos, además de
incluir los protocolos de interacción obtenidos previamente. Se debe mencionar
que en esta fase se genera automáticamente, a partir de la información incluida
en los protocolos de interacción, un diagrama de comunicación entre agentes
que muestra las relaciones de comunicación existentes entre los agentes del
sistema.
La fase de diseño detallado consiste en transformar los conceptos obtenidos en
Prometheus en conceptos equivalentes en la metodología INGENIAS. Posteriormente se
completa el diseño que servirá como entrada para la generación de código.
En primer lugar debe hacerse la transformación de conceptos de una
metodología a otra, prestando especial atención a la obtención de un diseño
equivalente al original mediante la terminología de INGENIAS.
A partir del modelo de interacción obtenido se puede deducir que por cada
“evento” que recibe un agente debe haber una tarea asociada al agente para
responder a la llegada de dicho “evento”. Por lo tanto, por cada mensaje y
percepción recibida por un agente se crea una tarea que incluye las acciones y
mensajes que ejecutará/enviará el agente a su recepción.
Otra tarea consiste en refinar las aplicaciones obtenidas al aplicar la
transformación. Este refinamiento consiste en añadir métodos auxiliares que
reflejen las acciones que no efectúan cambios en el entorno, sino acciones
internas, como por ejemplo el acceso a una base de datos.
Una vez conocidas las tareas que ejecutará el agente y los mensajes que recibe
se procede a especificar el autómata que describe el comportamiento del agente.
La última tarea consiste en establecer, en el diagrama de componentes, una
relación entre la tarea de cada agente y un componente de código. Esto es
necesario para la generación de código.
15
La fase de implementación consiste en obtener el código final de la aplicación a partir
del esqueleto de código generado automáticamente mediante el módulo de generación de
código. Se deben completar los métodos de las aplicaciones y las tareas porque el
generador únicamente genera las cabeceras. Una vez implementados los métodos se puede
actualizar el diseño, concretamente los componentes de código, con el código introducido
manualmente. Este paso es necesario para que el código introducido no se pierda la
próxima vez que se repita el proceso de generación de código. En la figura 2.7 de la
siguiente sección se describe el proceso de generación de código desde INGENIAS y el
procedimiento para salvar el código generado.
La fase de despliegue consta de una única tarea que consiste en la especificación del
número de instancias que habrá de cada tipo de agente y aplicación al desplegar la
aplicación. Esta tarea se realiza adjuntando, en un modelo del entorno, notas a los agentes
y aplicaciones presentes en el diseño.
Figura 2.4. Fases de la metodología VigilAgent
16
2.4. ICARO-T
ICARO-T (Garijo, Polo, Spina, 2009) es una infraestructura software que tiene como
objetivo el desarrollo de aplicaciones distribuidas con organizaciones de agentes.
Proporciona patrones de agente a partir de los cuales pueden generarse instancias de
agentes de aplicación, dotados de comportamiento en incluidos en una organización
formada por agentes y recursos. Estas organizaciones persiguen unos mismos objetivos
globales, mediante la coordinación de sus actividades, además de unos patrones de
actividad establecidos. De esta manera, permite gestionar aplicaciones distribuidas a gran
escala, pues optimiza y regula la gestión de servicios y distribución de tareas, obteniendo
gran eficiencia en la consecución de los objetivos del sistema.
ICARO-T proporciona tres tipos de modelos de componentes reutilizables para
desarrollar una aplicación: modelos de organización de componentes para describir la
estructura general del sistema, modelos de agentes basados en comportamientos reactivos y
cognitivos, y modelos de recursos para encapsular las entidades computacionales que
ofrecen servicios a los agentes. Además proporciona componentes más elementales como
son los patrones software utilizados para construir los modelos de agentes y los modelos de
recursos.
El patrón de agentes provee a los agentes de interfaces externos y estructuras internas
comunes, facilitando su desarrollo, su evolución y la inclusión de los mismos dentro de
aplicaciones ya desarrolladas. La arquitectura del agente reactivo se basa en tres
componentes incluidos en el patrón de agente de ICARO-T: percepción, control y
actuación. El agente recibe eventos a través de la percepción, los cuales se entregan al
control bajo demanda. El control está definido mediante un autómata de estados finitos que
consume los eventos almacenados en la percepción, provocando transiciones de estado y la
ejecución de acciones por parte del componente de actuación. Las acciones generan
cambios en el entorno que son de nuevo percibidas por los agentes provocando cambios en
el autómata y la ejecución de nuevas acciones. Los mecanismos de percepción y control se
encuentran definidos en el patrón de agente que ofrece ICARO-T. El patrón le permite al
desarrollador definir el comportamiento de un agente reactivo mediante una tabla de
transiciones localizada en un fichero XML y el modelo de ejecución mediante una clase de
acciones semánticas.
El ciclo de trabajo de un agente reactivo se muestra en figura 2.5 (Gascueña,
Fernández-Caballero, Garijo, 2010). El agente recibe eventos, procedentes de agentes y
recursos a través de su interfaz de uso, que son encolados en su interfaz para su posterior
consumo. Cuando el componente de control solicita un nuevo evento, el componente de
percepción se lo proporciona a través de su interfaz de consumo. En ese momento el
control del agente procesa el evento para obtener la información que contiene el evento y
17
provocar cambios internos en el autómata que describe su comportamiento. Estos cambios
consisten en transiciones de estado, las cuales, al consumir un evento, provocan la
ejecución de acciones semánticas por parte del componente de actuación. Una vez iniciada
la acción, el agente espera a que ésta finalice para solicitar un nuevo evento a través del
control.
Figura 2.5. Ciclo de trabajo básico de un agente reactivo
18
Los agentes necesitan interactuar con el entorno para satisfacer sus objetivos. Para ello
se utilizan unas entidades llamadas recursos, las cuales ofrecen información del entorno a
los agentes y les permiten efectuar acciones sobre este. Los recursos de aplicación se
encuentran encapsulados en componentes que aíslan su estructura interna. Además, al igual
que los agentes, ofrecen interfaces bien definidas para su uso y gestión.
Una aplicación en ICARO-T se modela como una organización formada por los
componentes de control y los recursos de aplicación. Esta organización se estructura en
tres capas (véase figura 2.6): la capa de control está formada por los componentes de
control, es decir, los agentes; la capa de recursos está formada por los componentes que
sirven información o proveen de funcionalidad a los agentes para alcanzar sus objetivos; la
capa de información contiene las entidades de información necesarias para modelar los
datos de las aplicaciones (ontologías, clases, etc.).
El usuario arranca una aplicación pasando como parámetro la descripción de la
organización de la aplicación. Esta descripción, denominada despliegue, consiste en un
fichero XML. Su estructura se detallará posteriormente en el capítulo de implementación.
En ese momento se crean tres componentes: el recurso de trazas, el componente de
configuración y el repositorio de interfaces. El recurso de trazas es una interfaz gráfica que
muestra los componentes de la organización, tanto recursos como agentes, y permite
visualizar en un cuadro de texto toda la traza de ejecución de la aplicación. El componente
de configuración interpreta la configuración que describe el fichero de despliegue y ordena
la creación del agente gestor de la configuración, encargado de controlar la creación del
agente gestor de recursos y del agente gestor de agentes. Estos últimos toman el control
para crear y gestionar los recursos y agentes de aplicación, respectivamente. Por último,
resaltar que cada entidad de la organización informa de su estado a la entidad que lo creó,
la cual se encarga de tomar decisiones en función de la información recibida. Así, los
agentes de aplicación informan al gestor de agentes, los recursos de aplicación al gestor de
recursos y estos últimos informan al gestor de la organización.
19
Figura 2.6. Capas de una aplicación ICARO-T
En figura 2.7 se muestra el Desarrollo Dirigido por Modelos (Model Driven
Development o MDD) de aplicaciones ICARO-T utilizando IDK (Gascueña, 2009). En
primer lugar se crea un proyecto nuevo sobre el que poder trabajar (fase 1). Una vez creado
el proyecto, se ejecuta el entorno IDK y se modela la aplicación utilizando el perfil
específico para ICARO-T, el cual sólo permite utilizar entidades válidas para el desarrollo
en ICARO-T (fase 2). Una vez finalizado el proceso de modelado se genera el código
asociado el modelo obtenido (fase 3) para posteriormente modificar el código en Eclipse
(fase 4). Si fuera necesario, se puede salvaguardar el código modificado en Eclipse para
realizar cambios en el modelo (fase 5). Una vez realizados estos cambios se puede volver a
generar el código, el cual incluirá las modificaciones realizadas anteriormente en Eclipse.
Este proceso se puede repetir las veces que sea necesario.
Para conocer otros proyectos desarrollados con ICARO-T pueden consultarse (Benito,
Valerón, 2009), (Fernández de Alba, 2009) y (Rodríguez, 2009).
20
Figura 2.7. MDD de aplicaciones ICARO-T utilizando IDK
2.5. Sistemas de control de acceso de entrada/salida
El control de acceso de humanos de entrada/salida tiene como objetivo proteger de
accesos no autorizados a zonas de seguridad, gestionando el tráfico de personas e
impidiendo el paso a individuos no autorizados. Los sistemas de control de acceso de
humanos de entrada/salida son una solución difundida ampliamente: se utilizan en metros,
bancos, hoteles, instituciones oficiales, centros de trabajo y todo tipo de áreas restringidas
localizadas en hospitales, universidades y zonas militares, entre otras. Su configuración es
amplia y variada, dependiendo de las necesidades de cada caso particular, aunque suelen
compartir dos elementos comunes: por un lado, constan de un medio lógico para identificar
al usuario en el sistema y, por otro lado, de un medio físico que impide o permite el acceso.
Además, dichos elementos se utilizan conjuntamente con un componente de control
encargado de comparar la información obtenida del usuario con la información almacenada
de una base de datos. En caso de coincidir ordena la apertura del medio utilizado como
barrera. En muchos casos este componente se encarga también de registrar información
relativa al usuario, el momento y el acceso utilizado.
21
La identificación de usuarios en el sistema se realiza mediante uno o varios medios
combinados. La utilización de uno u otro depende del nivel de seguridad y control deseado.
Uno de los métodos más comunes es la identificación basada en la información codificada
en la banda magnética de una tarjeta. Es un método similar al de los tickets, salvo que cada
tarjeta suele ser única e intransferible por cada usuario y permite el acceso controlado.
Muchas veces se suele combinar con la utilización de un código de seguridad personal
(PIN) para evitar casos de robo o extravío de la tarjeta. Los sistemas que requieren un nivel
más alto de seguridad utilizan también la biometría como método de identificación. Esta
tecnología gestiona el acceso a través de la identificación de la huella dactilar, el escaneo
de la palma de la mano u otras características físicas individuales tales como por ejemplo
el iris.
Los medios físicos para controlar el acceso dependen del tipo de zona que se desea
controlar. Para la entrada principal a edificios se suelen utilizar las puertas giratorias y las
esclusas de seguridad. Son la solución más común en bancos e instituciones que requieren
de cierto nivel de seguridad. Para áreas interiores se utilizan puertas y pasillos con tornos,
los cuales pueden disponer de sensores para mayor seguridad. Estos pasillos son similares
a los utilizados en los metros para el acceso de viajeros. En áreas más grandes, como
pueden ser las áreas perimetrales, suelen utilizarse tornos de altura completa.
La combinación de medios lógicos y físicos produce diferentes sistemas de seguridad
para el control de acceso de entrada/salida. Uno de los sistemas más difundidos por su
eficacia es el de puertas esclusas. Este sistema consta de un espacio delimitado entre dos
puertas que previene el paso de más de una persona a la vez. El funcionamiento es el
siguiente: en primer lugar el usuario se identifica en la primera puerta, la cual le da acceso
a la esclusa. Posteriormente, una vez cerrada la primera puerta, el usuario se identifica de
nuevo ante la segunda puerta, la cual le da acceso al área restringida. Algunos de estos
sistemas constan además de un sensor por ultrasonido de forma que si dos o más personas
son detectadas en la esclusa se niega el acceso (Kaba, 2010).
2.6. Sensores
Un sensor es un dispositivo capaz de medir magnitudes físicas o químicas y
transformar dichas medidas en variables eléctricas. Los sensores se utilizan para medir, por
ejemplo, temperatura, intensidad lumínica, distancia, aceleración, presencia, color,
inclinación, desplazamiento, presión, fuerza, torsión, humedad y pH. En general,
convierten una señal física no eléctrica en otra eléctrica que, en alguno de sus parámetros
(nivel de tensión, nivel de corriente o frecuencia) contiene la información correspondiente
a su medición. Por otra parte, es necesario utilizar circuitos de acondicionamiento con el
objeto de que éste genere una señal eléctrica normalizada (ya sea por el fabricante o
22
siguiendo pautas de organismos de normalización como IEC5 o IEEE
6). Los sensores se
pueden clasificar según múltiples características (Armesto, 2007), como son: el tipo de
funcionamiento (activos y pasivos), el tipo de señal eléctrica que generan (analógicos,
digitales y temporales), el rango de valores que proporcionan (de medida y todo-nada), el
nivel de integración (discretos, integrados e inteligentes) y el tipo de variable física
medida.
Los sensores más utilizados en los sistemas de vigilancia y control están destinados a
percibir la presencia de personas y comprobar el estado de los elementos del sistema. En el
primer caso se utilizan sensores de presencia, sensores de proximidad, sensores acústicos,
sensores ópticos y sensores de presión, entre otros. En el segundo caso se utilizan sensores
de temperatura, sensores de estado, sensores de desplazamiento y sensores de humo, entre
otros. Resaltar que para el presente proyecto resultan de gran interés los sensores de
presencia y los sensores de estado, concretamente los sensores infrarrojos y los sensores de
contacto. Estos sensores resultan de gran utilizad para detectar el paso de una persona
(corte del rayo infrarrojo) y para conocer el estado de una puerta (abierta o cerrada).
Ambos sensores se clasifican en el tipo todo-nada, también conocido como on-off.
2.7. Metodología de desarrollo de redes de sensores mediante SMA
La red de sensores es una de las tecnologías más prometedoras para las próximas
décadas gracias a la continua reducción de tamaño y precio que se está produciendo en los
sensores (Vinyals, Rodríguez Aguilar, Cerquides, 2010). Se trata de un concepto
relativamente nuevo en adquisición y tratamiento de datos que tiene múltiples aplicaciones
en distintos campos tales como los entornos militares, la medicina, la industria, la
domótica, la inteligencia ambiental y la eficiencia energética. Están formadas por un grupo
de sensores dotados de capacidades sensitivas y de comunicación, los cuales permiten
formar redes ad hoc7 sin una infraestructura física preestablecida ni administración central.
Los SMA pueden contribuir al desarrollo de este tipo de sistemas mediante el
modelado flexible de entidades autónomas. En (Fuentes-Fernández, Guijarro, Pajares,
2009) se propone un proceso para el desarrollo de redes de sensores mediante SMA. Este
proceso está basado en la metodología INGENIAS, al igual que VigilAgent. En figura 2.8
se puede observar cada uno de los pasos que componen este proceso, así como los puntos
de toma de decisiones.
5 International Electrotechnical Commission (IEC)
6 Institute of Electrical and Electronics Engineers (IEEE)
7 Ad hoc se refiere a una red en la que no hay un nodo central, sino que todos los dispositivos están en
igualdad de condiciones.
23
act Phase 1
1. Identificar contenedores y
recursos
2. ¿Se deben generar más datos?
3. Identificar datos a
generar
4. Identificar el equipo de
procesamiento de
información
5. ¿Hay recursos reemplazables?
6. Identificar recursos
reemplazables
7. Identificar el equipo de
balanceo de carga
8. Refinar el PIM
9. Refinar el modelo
especifico de plataforma
PSM
10. Desarrollar el Modelo
de plataforma PM
11. Desarrollar
transformaciones
12. Aplicar
transformaciones al
modelo
13. Aplicar modelo a las
transformaciones de texto
[Sí]
[No]
[Sí][No]
Figura 2.8. Proceso de desarrollo en redes de sensores
La actividad 1 Identificar contenedores y recursos consiste en determinar los
dispositivos que van a percibir información del entorno y los que van a procesar la
información suministrada por los sensores. Los primeros se identifican como sensores,
mientras que los segundos pueden ser un ordenador o cualquier otro dispositivo
informático. Cuando la respuesta a la pregunta que se formula en la decisión 2 “¿Se deben
generar más datos?” es afirmativa, se continúa en la actividad 3 Identificar datos a
generar, consistente en identificar los datos que van a ser generados por el sistema al
margen de los datos que proveen los sensores. Para cada grupo de datos, la actividad 4
Identificar el equipo de procesamiento de información, asigna a cada sensor dos
controladores para inicializar el sensor y permitir el acceso a los datos que genera el
sensor, respectivamente. Las actividades siguientes permiten el estudio del
24
comportamiento dinámico de la red y su refinamiento. Así pues, la decisión 5 ¿Hay
recursos reemplazables? conduce, en caso afirmativo, a la búsqueda de recursos que
pueden fallar durante el funcionamiento del sistema, con las correspondientes
modificaciones sobre el modelo (actividad 6 Identificar recursos reemplazables y actividad
7 Identificar el equipo de balanceo de carga). Una vez concluidas estas actividades se
deben haber obtenido los dispositivos, los agentes y los roles que conforman el sistema, así
como la información que intercambian y sus interacciones.
Las actividades siguientes se centran en el proceso de desarrollo en INGENIAS, las
cuales se realizan sobre el modelo obtenido mediante las actividades expuestas
previamente. La actividad 8 Refinar el PIM (Modelo Independiente de la Plataforma)
consiste en modificar el modelo de actores y roles con objetivos adicionales, capacidades e
información. Las actividades 9 y 10 acercan el modelo al siguiente nivel de desarrollo,
añadiendo componentes de código a las entidades para hacerlas más específicas (actividad
9 Refinar el modelo especifico de plataforma PSM y la actividad 10 Desarrollar el Modelo
de plataforma PM). Las actividades 11, 12 y 13 realizan las transformaciones necesarias
para realizar el proceso semi-automático de generación de código mediante el IDK
(actividad 11 Desarrollar transformaciones, actividad 12 Aplicar transformaciones al
modelo y actividad 13 Aplicar modelo a las transformaciones de texto).
El proceso de desarrollo descrito cuenta con múltiples similitudes con la metodología
VigilAgent. Se puede llegar a la conclusión de que las actividades 1 a 7 se asemejan a las
actividades realizadas en Prometheus para la identificación de actores, agentes, roles y las
interacciones posibles, además de los datos generados. Las actividades siguientes (8 a 13)
se asemejan a las fases que usan INGENIAS en VigilAgent, consistentes en realizar las
transformaciones necesarias al modelo de Prometheus y añadir componentes de código
para realizar el proceso semi-automático de generación de código a partir del modelo final
especificado en INGENIAS.
25
3. MODELADO DEL SISTEMA
3.1. Descripción del problema
El caso de estudio presentado en este capítulo ilustra todo el proceso de desarrollo
considerado en la metodología VigilAgent para modelar una aplicación utilizando como
base tecnológica los fundamentos de los SMA. En particular, se pretende modelar un
sistema inteligente que simule la colaboración necesaria para controlar, automáticamente,
la entrada/salida de humanos a un recinto a través de los módulos instalados (véase figura
3.1). Cada módulo facilita la entrada o la salida en función de su configuración. Un módulo
está compuesto por un dispositivo lector de tickets, una puerta de apertura y cierre
automático, un sensor de contacto y un sensor de infrarrojos (véase figura 3.2).
Inicialmente, el usuario introduce el ticket en el lector de un módulo y el sistema
ilumina el led del lector con un determinado color para advertirle al usuario cuál ha sido el
resultado de su autentificación. El led se ilumina de color rojo si se trata de un usuario no
autorizado. En caso contrario, se ilumina de color verde y seguidamente se abre la puerta,
dando tiempo a que el usuario la atraviese antes de que ésta se cierre. El sensor de
infrarrojos se utiliza para contar el número de personas que pasan por el módulo.
El sistema lleva un control de la cantidad de usuarios que atraviesan cada puerta
individualmente y un control global del número total de usuarios que se encuentran en el
interior del recinto en cada instante. Evidentemente, los protocolos para entrar y salir del
recinto son similares, es decir, la salida del recinto se puede ver como la “entrada” al
exterior desde el interior del recinto. Además, el sistema debe controlar la ocurrencia de
situaciones anómalas porque cualquier usuario puede realizar acciones no autorizadas,
tanto en el proceso de entrada como en el de salida. Así, por una parte, se contempla la
posibilidad de que el usuario pueda bloquear una puerta, en el momento en que ésta se abra
para darle paso, impidiendo que se cierre. Por otra parte, se deben detectar las situaciones
de tailgating, es decir, la práctica que siguen determinados usuarios que no se autentifican
para atravesar la puerta aprovechando que está abierta porque otra persona ha introducido
correctamente su ticket previamente. Resaltar que el tailgating puede darse porque la
puerta está bloqueada y/o aprovechando el intervalo de tiempo durante el que la puerta
permanece abierta para que el usuario autorizado pueda atravesarla.
Finalmente, otra funcionalidad que ofrece el sistema consiste en permitir que el
vigilante de seguridad, responsable de supervisar todo el proceso de entrada y salida de
usuarios al/del recinto, tenga capacidad para deshabilitar un módulo cuando su puerta esté
cerrada. Además, le informa en todo momento del estado en que se encuentra cada
dispositivo del sistema y las estadísticas obtenidas. Por ejemplo, el estado de una puerta, el
26
resultado de identificación de un usuario, el número de usuarios que hay dentro del recinto,
etc.
Figura 3.1. Vista general
Figura 3.2. Módulo de entrada
Entrada
Entrada Entrada
Salida
Salida
Recinto cerrado
Puerta de
entrada
Sensor de infrarrojos
Sensor de
contacto
Lector de
tarjetas
Recinto cerrado
27
El problema se ha acotado considerablemente porque simplemente se pretende realizar
un estudio y proponer una solución mediante el uso de un sistema Multi-Agente. Las
suposiciones de partida consideradas para abordar el caso de estudio descrito previamente
son las siguientes:
- Un usuario sólo podrá identificarse en un módulo cuando esté habilitado y no lo
esté utilizando otro usuario que se haya identificado previamente.
- La puerta se abre automáticamente cuando un usuario autorizado se autentifica en
el sistema.
- El usuario autentificado atraviesa la puerta, una vez abierta, y se detecta un corte
del rayo infrarrojo, por parte del sensor dedicado a tal efecto, que indicará el paso
del usuario autorizado a través de la puerta. Esto ocurre dentro del retardo que cada
módulo introduce para que el usuario cruce la puerta.
- No se contempla el caso de que un usuario pase por una puerta en sentido contrario
al permitido. Un módulo sólo funciona en sentido de entrada o en sentido de salida,
dependiendo de su configuración, es decir, en ningún caso se puede utilizar una
puerta de entrada para salir o una de salida para entrar.
- La puerta se cierra automáticamente cuando finaliza el tiempo de retardo. Esta se
intentará cerrar cuando un usuario (diferente al vigilante) la haya bloqueado, pero
el resultado solamente se conocerá por la información obtenida por el sensor de
contacto.
En este caso de estudio se ha utilizado una nomenclatura para nombrar cada tipo de
entidad del sistema. En tabla 3.1 se observa que el nombre de cada tipo de entidad tiene
como prefijo unas iníciales que identifican cuál es su tipo.
Tabla 3.1. Descripción de las entidades
Entidad Identificador
Actor acNombreDelActor
Agente agNombreDelAgente
Percepción pNombreDeLaPercepción
Acción aNombreDeLaAcción
Protocolo PINombreDelProtocolo
28
3.2. Fase de especificación del sistema
3.2.1. Identificación de la interacción del sistema con el entorno
La fase de especificación del sistema se inicia con el diagrama de visión general del
análisis (véase figura 3.3), el cual muestra un esbozo de las interacciones que se producen
entre el sistema y el entorno. Para ello, se han identificado una serie de actores que
representan los dispositivos instalados en el sistema: el lector de tickets (acLector), la
puerta de apertura y cierre automático (acPuerta), el sensor de contacto de la puerta
(acSensorContacto), el sensor de infrarrojos (acSensorInfrarrojo) y la centralita del
vigilante (acCentralita).
El actor acLector representa el lector de tickets con el que interacciona el usuario. Este
dispositivo puede participar en la identificación del usuario tanto a la entrada como a la
salida del recinto – estos procesos se describen en los escenarios Controlar Entrada
scenario y Controlar Salida scenario – mediante las acciones aIluminarLedAutorizado y
aIluminarLedNoAutorizado y la percepción pIdentificaciónUsuario.
La apertura y cierre de la puerta se representa mediante las acciones aAbrir y aCerrar,
respectivamente, ejecutadas sobre el actor acPuerta. Además, la acción aBloquearPuerta
permite al vigilante deshabilitarla, tal y como se describe en el escenario Deshabilitar
Módulo scenario.
El actor acSensorContacto representa al dispositivo sensor de contacto utilizado para
determinar en qué estado se encuentra la puerta en un momento dado (percepciones
pPuertaAbierta y pPuertaCerrada). Este dispositivo se utiliza para detectar la situación
anómala en la que un usuario bloquea la puerta para impedir su cierre (Bloquear Puerta
scenario).
Otro dispositivo físico, representado por el actor acSensorInfrarrojo, se corresponde
con el sensor de infrarrojo utilizado para detectar el paso de personas (percepción
pInfrarrojoCortado) a través de la puerta. Por lo tanto, la funcionalidad de este dispositivo
permite controlar el tráfico de usuarios y detectar la ocurrencia de la situación anómala de
tailgating en la que varias personas pasan por la puerta utilizando un único ticket válido.
Es preciso resaltar que las situaciones anómalas detectadas se notifican a la centralita
mediante las acciones aNotificarPuertaBloqueadaUsuario y aNotificarTailgating
ejecutadas sobre el actor acCentralita que representa la interfaz de la centralita. De esta
forma el vigilante puede conocer los hechos detectados.
29
Figura 3.3. Diagrama de visión general del análisis
3.2.2. Desarrollo de escenarios
Los escenarios del sistema se detallan en el diagrama de escenarios (véase figura 3.4).
Un escenario es una secuencia de pasos en forma de guión que describen un posible
comportamiento del sistema frente a una situación dada. Los escenarios principales,
Controlar Entrada scenario y Controlar Salida scenario, describen el flujo básico de una
entrada y una salida, respectivamente. Los escenarios Deshabilitar Módulo scenario,
Puerta Bloqueada Usuario scenario y Tailgating scenario son variantes de estos
escenarios. El primero, describe la situación en la que el vigilante de seguridad bloquea la
puerta utilizando la funcionalidad ofrecida por la interfaz de la centralita. Los otras dos
variantes describen las dos situaciones anómalas que es capaz de detectar el sistema: el
paso a través de un módulo de más de una persona mientras éste permanece abierto
(escenario Tailgating) y un usuario que bloquea la puerta para impedir su cierre automático
(escenario Bloquear Puerta scenario).
30
Figura 3.4. Escenarios
La secuencia de pasos que describen la entrada de un usuario en el recinto se muestra
en figura 3.5. El suceso que dispara esta secuencia es la percepción pIdentificaciónUsuario
que contiene el número del ticket introducido por el usuario en el lector de tickets. Notar
que el sistema sólo puede leer tickets cuando la puerta está cerrada. Por lo tanto, la
percepción pPuertaCerrada aparece en primer lugar para garantizar que el proceso de
identificación no se produce cuando un usuario autorizado haya provocado previamente la
apertura de la puerta. Una vez que el usuario introduce su ticket en el lector, se comprueba
la validez del ticket (paso 3) y se comunica el resultado de esta comprobación tanto al
usuario, iluminando el led del lector para notificar que se trata de un usuario autorizado
(paso 4), como al vigilante que supervisa las incidencias que llegan a la pantalla de la
centralita (paso5). Una vez que se ha comprobado que el usuario dispone de un ticket
válido se inicia el proceso de apertura (paso 6), se monitoriza en qué estado se encuentra la
puerta (paso 7) y se introduce un retardo para que se cierre de nuevo la puerta (paso 8).
Mientras la puerta permanece abierta, se detecta el paso de usuarios (paso 9) y se actualiza
el control del tráfico de usuarios que pasan a través de la puerta y el número de usuarios
que se encuentran dentro del recinto (paso 10). Al finalizar el retardo, se inicia el proceso
que cierra la puerta y se muestra el estado de la puerta en la centralita (pasos 11 y 12,
respectivamente).
El escenario Controlar Salida scenario muestra casi los mismos pasos que el escenario
de entrada. La única diferencia se encuentra en la actualización del contador para el tráfico
de salida, tal y como puede observarse en el paso 10 de figura 3.6.
31
Figura 3.5. Escenario Controlar Entrada scenario
Figura 3.6. Escenario Controlar Salida scenario
El escenario Bloquear Puerta scenario describe la detección de la situación anómala en
la que un usuario bloquea la puerta del módulo (véase figura 3.7). Los pasos son los
mismos que para los escenarios de entrada y salida hasta el paso 12, momento en el cual se
detecta que la puerta sigue abierta después de haberse gestionado el proceso de cierre en el
paso previo. Cuando esto ocurre se notifica a centralita la detección de la situación (paso
13).
32
Figura 3.7. Escenario Bloquear Puerta scenario
El escenario Tailgating scenario describe la detección de una situación de tailgating en
uno de los módulos (véase figura 3.8). Igualmente se comparten los primeros pasos con los
escenarios de entrada y de salida, aunque en este caso hasta el paso 9. Una vez se ha
detectado el paso de una persona mediante la percepción del infrarrojo pInfrarrojoCortado
y se produce la actualización del tráfico del módulo (pasos 8 y 9, respectivamente), se
vuelve a detectar el corte del infrarrojo, lo que indica el paso de otra persona (paso 10).
Cuando se detecta este hecho se notifica a la centralita la detección de la situación (paso
11).
Figura 3.8. Escenario Tailgating scenario
En figura 3.9 se muestra el escenario Deshabilitar Modulo scenario que describe la
situación excepcional en la que el vigilante deshabilita la puerta del módulo impidiendo su
uso por parte de cualquier usuario. Esta situación sólo puede producirse con la puerta
33
cerrada (paso 1). Posteriormente, el vigilante bloquea la puerta a través de la interfaz que le
ofrece la centralita (paso 2). El paso 2 (acción aBloquearPuerta) tiene el propósito de
deshabilitar el módulo, es decir, el módulo queda fuera de servicio temporalmente hasta
que se decide ponerlo en marcha de nuevo.
Figura 3.9. Escenario Deshabilitar Modulo scenario
3.2.3. Especificación de objetivos del sistema
Los escenarios descritos previamente están directamente relacionados con los objetivos
del sistema, es decir, por cada escenario existe un objetivo relacionado. Esto significa que
la consecución de dicho objetivo se produce cuando se han completado todos los pasos que
componen el escenario asociado. En el diagrama de visión general de objetivos se
muestran los objetivos de forma jerárquica (véase figura 3.10). El objetivo raíz Controlar
Entrada/Salida se descompone en varios subobjetivos que describen cómo se alcanza el
objetivo padre, es decir, tratando el comportamiento legal de los usuarios (Soportar
Acceso), las situaciones anómalas (Detectar Situación Anómala) y la situación excepcional
que permite al vigilante deshabilitar un módulo. A su vez, el objetivo Soportar Acceso se
descompone en dos subobjetivos (Controlar entrada y Controlar Salida) y el objetivo
Detectar Situación Anómala se descompone en los subobjetivos Tailgating y Bloquear
Puerta.
Figura 3.10. Diagrama de visión general de objetivos
34
3.2.4. Descripción de roles
Los roles del sistema se obtienen agrupando objetivos y relacionando acciones y
percepciones. Como resultado de estas agrupaciones se han identificado roles para cada
una de las funcionalidades que se deben soportar en el sistema (véase figura 3.11). En tabla
3.2 se ofrece una breve descripción de los roles identificados.
Figura 3.11. Diagrama de roles del sistema
Tabla 3.2. Descripción de los roles
Rol Descripción
rIdentificación Usuario Gestiona el proceso de identificación de un usuario en el sistema para el acceso/salida
al/del recinto cerrado.
rControl Acceso Es responsable de facilitar el acceso/salida al/del recinto al usuario previamente
identificado positivamente.
rControl Infrarrojo Es responsable de detectar el paso de usuarios a través de la puerta.
rControlContacto Es responsable de detectar el estado de la puerta.
rDetección Tailgating Su objetivo es notificar la detección de la situación anómala denominada Tailgating.
rDetección Puerta
Bloqueada
Su objetivo es notificar la detección de la situación anómala en la que la puerta ha sido
bloqueada por un usuario.
rIntercomunicación Se encarga de gestionar la comunicación entre agentes necesaria para soportar el
acceso/salida de usuarios al/del recinto.
35
3.3. Fase de diseño arquitectónico
3.3.1. Identificación de tipos de agentes
Una vez que se han identificado los roles en la fase de especificación del sistema, la
primera cuestión que hay que resolver en la fase de diseño arquitectónico es identificar los
tipos de agente que van a formar parte del sistema. Para esto, se toma como base los roles
del sistema y se agrupan de tal modo que cada nuevo agente introducido sea el responsable
de llevar a cabo la funcionalidad de uno o varios roles. Como norma general, se pretende
que las agrupaciones tengan como resultado la máxima cohesión y el mínimo
acoplamiento. Los roles obtenidos en la fase anterior han dado como resultado la
introducción de un tipo de agente por cada rol (véase figura 3.12).
Figura 3.12. Diagrama de agrupamiento Agente-Rol
3.3.2. Especificación de acoplamiento de datos
En algunos casos, para soportar la funcionalidad que representa un rol se deben leer y/o
escribir datos. La relación existente entre estos conceptos (roles y datos) se muestra
gráficamente en el diagrama de acoplamiento de datos, tal y como puede observarse en la
figura 3.13. El rol rIdentificaciónUsuario tiene el objetivo de comprobar la validez de cada
ticket introducido en el sistema. Para ello, su agente asociado (agLector) accede al dato
BDD que se corresponde con una base de datos de tickets de usuario. Por otro lado, el rol
36
rControlInfrarrojo tiene el objetivo de controlar el tráfico de usuarios que pasan a través
de la puerta. Para satisfacer esta funcionalidad, su agente asociado (agSensorInfrarrojo)
debe controlar, por una parte, el total de usuarios que pasan a través de la puerta (Tráfico),
y por otra parte, el total de usuarios que se encuentran dentro del recinto (Personas
Dentro). Además, debe acceder a la configuración del módulo para actualizar
correctamente estas estadísticas, es decir, Configuración Módulo permite determinar si el
paso de una persona a través de la puerta es de entrada o de salida.
Figura 3.13. Diagrama de acoplamiento de datos
3.3.3. Descripción de las interacciones
Otra tarea importante en la fase de diseño arquitectónico es la descripción de los
protocolos de interacción. Los escenarios describen el comportamiento del sistema
mediante una secuencia de pasos. Sin embargo, no contemplan la comunicación entre
agentes. Por el contrario, los protocolos de interacción reflejan gráficamente la interacción
entre agentes, así como la interacción con el entorno a través de los actores. A
continuación se describe detalladamente cada uno de los protocolos considerados en este
caso de estudio.
PI Identificación especifica cómo se produce la identificación de un usuario en el
sistema (véase figura 3.14). Un usuario sólo puede identificarse en el sistema cuando
encuentra que la puerta está inicialmente cerrada (percepción pPuertaCerrada). Por lo
tanto, cuando se da este caso y un usuario introduce un ticket en el lector, el agente
agLector percibe la información del ticket (pIdentificaciónUsuario) para proceder a
comprobar la validez del ticket introducido. En función de si el ticket introducido por el
usuario es válido o no pueden darse dos situaciones alternativas. En el primer caso, cuando
el usuario introduce un ticket válido - se satisface la guarda Usuario Autorizado - se
ejecuta la acción aIluminarLedAutorizado para iluminar el led del lector con el fin de
notificarle al usuario que ha introducido un ticket válido. Al mismo tiempo, se ilumina un
37
led de la centralita para notificárselo al vigilante (aIluminarLedAutorizadoCentralita).
Posteriormente, el agente agLector comunica al agente agPuerta que puede proceder a la
apertura de la puerta. Esta comunicación se realiza a través del agente
agIntercomunicador, que se encarga de hacer de intermediario en la comunicación entre
dos agentes ligados a los dispositivos. En el segundo caso, cuando el usuario introduce un
ticket no válido - se satisface la guarda Usuario No Autorizado - se ilumina el led del lector
y de la centralita para notificar que se trata de un ticket no válido mediante las acciones
aIluminarLedNoAutorizado y aIluminarLedNoAutorizadoCentralita, respectivamente.
Figura 3.14. Protocolo PI Identificación
PI Acceso especifica todo el proceso de entrada/salida al/del recinto por parte de un
usuario, desde que se abre la puerta hasta que se vuelve a cerrar (véase figura 3.15). En
esta descripción se supone que el usuario ya se ha autentificado con éxito previamente, es
decir, el agente agPuerta ha recibido el mensaje LectorAPuertaUsuarioAutorizado enviado
por el agente agIntercomunicador (véase figura 3.14). Cuando esto ocurre, se satisface la
guarda Usuario Autorizado y el agente agPuerta ordena que se abra la puerta
(aAbrirPuerta) e introduce un retardo (aRetardar), durante el cual la puerta permanecerá
abierta, con el fin de darle tiempo al usuario para que la atraviese antes de que se cierre de
nuevo. Tras esto, el agente agPuerta se pone en contacto con el agente agSensorContacto
para anunciarle la apertura de la puerta.
38
Es preciso resaltar de nuevo que el agente agIntercomunicador hace de intermediario
en esta comunicación. Cuando el agente agSensorContacto recibe el mensaje
PuertaASensorContactoAbriendoPuerta enviado por el agente agIntercomunicador,
percibe el estado de la puerta. En este caso se va a encontrar abierta (pPuertaAbierta) y por
lo tanto el agente agSensorContacto ejecuta la acción
aIluminarLedPuertaAbiertaCentralita para mostrarlo en la centralita. En ese momento el
agente agSensorContacto envía el mensaje SensorContactoASensorInfrarrojoActivar al
agente agSensorInfrarrojo para que proceda a su activación. Además, envía el mensaje
SensorContactoATailgatingPuertaAbierta al agente agTailgating para que conozca que se
ha abierto la puerta y que debe ponerse a monitorizar las ocurrencias de tailgating una vez
que el agente agSensorInfrarrojo ha detectado que ha pasado una persona.
Las guardas Entrada y Salida permiten contemplar lo que ocurre cuando el usuario
atraviesa la puerta de un módulo para entrar o para salir, de acuerdo a cómo esté
configurado, respectivamente. En ambos casos es necesario ejecutar la acción
aIncrementarContadorTrafico para incrementar el contador de personas que atraviesan el
módulo. La diferencia está en que en la alternativa marcada como Entrada se incrementa el
contador de personas que hay dentro del recinto mientras que en la alternativa Salida se
decrementa.
Tras comunicar al agente agTailgating la detección del corte del infrarrojo
(SensorInfrarrojoATailgatingInfrarrojoCortado), se inicia el proceso que detecta la
ocurrencia de situaciones anómalas correspondientes al fenómeno de tailgating (el
contenido de este subprotocolo se detallará en la figura 3.16).
Una vez que ha finalizado el retardo se cierra la puerta (aCerrarPuerta) y se le
comunica al agente agSensorContacto que debe percibir el estado de la puerta cuando le
llegue el mensaje PuertaASensorContactoCerrandoPuerta. Al igual que en el caso de la
apertura, esto se hace a través del agente agIntercomunicador. En este instante se
contempla la posibilidad de que el usuario haya bloqueado la puerta, impidiendo su cierre,
para que otros individuos puedan atravesarla sin necesidad de gastar un ticket (el contenido
de este subprotocolo PI Puerta Bloqueada Usuario se detallará en la figura 3.17). Si la
puerta está cerrada (pPuertaCerrada) entonces muestra este hecho en la centralita
iluminando el led asociado a la puerta, envía el mensaje
SensorContactoASensorInfrarrojoDesactivar al agente agSensorInfrarrojo y finalmente
envía el mensaje SensorContactoATailgatingPuertaCerrada al agente agTailgating para
que deje de monitorizar la situación que es responsable de detectar. A continuación se
describen con más detalle las situaciones anómalas citadas previamente.
39
Figura 3.15. Protocolo PI Acceso
40
PI Tailgating especifica cómo se detecta la situación en la que uno o más individuos
pasan a través de la puerta aprovechando el paso de un usuario autorizado (véase figura
3.16). Esta situación, como se ha podido ver en el protocolo PI Acceso se produce, cuando
la puerta se encuentra abierta, después de que la haya atravesado una persona autorizada. A
partir de ese momento, cada vez que el agente agSensorInfrarrojo percibe que se ha
cortado el infrarrojo (pInfrarrojoCortado) se contabiliza el paso de otra persona a través de
la puerta, se actualiza el número de personas que hay dentro del recinto y se comunica la
detección al agente agTailgating mediante el mensaje
SensorInfrarrojoATailgatingInfrarrojoCortado. Finalmente, el agente agTailgating
notifica la situación a centralita ejecutando la acción aNotificarTailgating. Como puede
observarse, la detección se hace de la misma manera tanto en la alternativa de entrada
como en la de salida.
Figura 3.16. Protocolo PI Tailgating
41
PI Puerta Bloqueada Usuario describe cuándo se detecta que la puerta ha sido
bloqueada por un usuario para impedir su cierre (véase figura 3.17). Esta detección se
produce cuando el agente agPuerta envía el mensaje
PuertaASensorContactoCerrandoPuerta al agente agSensorContacto para comunicarle
que ha procedido a cerrar la puerta, tal y como se puede apreciar en el protocolo PI Acceso
(véase figura 3.15). Tras recibir este mensaje, el agente agSensorContacto percibe el
estado de la puerta. En caso de estar abierta (pPuertaAbierta) interpreta que ha sido
bloqueada por el usuario y se lo comunica al agente agPuertaBloqueada mediante el
mensaje SensorContactoAPuertaBloqueadaPuertaBloqueada. Este agente informa
inmediatamente de esta situación en la centralita (aNotificarPuertaBloqueadaUsuario) tras
recibir el mensaje.
Figura 3.17. Protocolo PI Puerta Bloqueada Usuario
Notar que en la detección de situaciones anómalas no se utiliza el agente intermediario
agIntercomunicador porque interesa que la ocurrencia de una situación anómala se
notifique instantáneamente. Por esto, el agente agSensorInfrarrojo se comunica
directamente con el agente agTailgating en el protocolo PI Tailgating (véase figura 3.16) e
igualmente lo hace el agente agSensorContacto con el agente agPuertaBloqueada en el
protocolo PI Puerta Bloqueada Usuario (véase figura 3.17).
3.3.4. Descripción de la arquitectura global del sistema
Por último, el diagrama de visión general del sistema (véase figura 3.18) muestra en
una única vista la arquitectura del sistema, es decir, los agentes identificados, las
percepciones que reciben, las acciones que ejecutan, los datos que leen y/o escriben y los
protocolos de interacción en los que participan.
42
El diagrama de comunicación de agentes incluye las relaciones de comunicación entre
los agentes del sistema. Este diagrama se genera automáticamente a partir de los mensajes
incluidos en los protocolos de interacción. En figura 3.19 se observa cómo el agente
agIntercomunicador hace de intermediario en las conversaciones entre los agentes
agLector, agPuerta, agSensorContacto y agSensorInfrarrojo. Por otra parte se aprecia la
comunicación directa entre los agentes agSensorInfrarrojo y agSensorcontacto y los
agentes agTailgating y agPuertaBloqueada identificados para reconocer las situaciones
anómalas.
Figura 3.18. Diagrama de visión general del sistema
Figura 3.19. Diagrama de comunicación de agentes
43
3.4. Fase de diseño detallado
3.4.1. Transformación de estructuras de Prometheus a INGENIAS
La fase de diseño detallado requiere, en primer lugar, la transformación de los
conceptos de Prometheus incluidos en el diagrama de visión general del sistema en
conceptos equivalentes en la metodología INGENIAS. Esto se debe a que ambas
metodologías no utilizan la misma terminología para describir los elementos que
conforman el sistema. Las equivalencias entre las entidades del lenguaje de modelado de
Prometheus y el lenguaje de modelado de INGENIAS se pueden resumir como sigue:
La entidad agente está presente en Prometheus e INGENIAS y por lo tanto su
traducción es directa.
Un actor en Prometheus queda descrito en INGENIAS mediante una aplicación
con la que interacciona un agente por medio de métodos y eventos.
Una entidad aplicación, presente en INGENIAS, encapsula una serie de
métodos y eventos y se relaciona con uno o varios agentes. Un método es el
procedimiento que describe una acción, que puede ser invocado junto con una
serie de argumentos y devolver un resultado. El método puede enviar un evento
de aplicación, el cual puede contener información (véanse figuras 3.20 y 3.21),
a un agente.
La interacción entre agentes y aplicaciones se hace a través de métodos. Así
pues, cada actor de Prometheus se ha llevado a INGENIAS transformado en
una aplicación, dentro de la cual se ha creado un método por cada acción que
un agente puede ejecutar sobre este actor y, seguidamente, se ha creado un
evento de aplicación por cada percepción que puede recibir un agente de este
actor (véanse figuras 3.20 y 3.21).
Respecto a las interacciones entre agentes resaltar que los mensajes utilizados
en Prometheus se reflejan en INGENIAS mediante las denominadas Unidades
de Interacción, equivalentes a los mensajes, las cuales pueden contener
información adicional, al igual que sucede en los eventos de aplicación (véase
figura 3.22).
Por último, los datos en Prometheus no tienen una equivalencia directa en
INGENIAS. Por lo tanto, la manera de reflejar un dato se hace mediante una
aplicación con la que pueden interaccionar los agentes (véase figura 3.23).
Las figuras 3.20, 3.21, 3.22 y 3.23 muestran gráficamente la transformación de
conceptos que debe realizarse al traducir un modelo de Prometheus a INGENIAS. Cada
figura muestra en su parte izquierda el modelo original en Prometheus y en su parte
44
derecha el modelo equivalente en INGENIAS. En la parte inferior de cada figura aparece
una tabla que indica los diagramas que se ven afectados en la transformación. En la
columna de la izquierda aparece lo que afecta en Prometheus y en la de la derecha lo que
afecta a INGENIAS.
Figura 3.20. Transformación de una percepción
Figura 3.21. Transformación de una acción
45
Figura 3.22. Transformación de un mensaje
Figura 3.23. Transformación de un dato
El resultado de estas transformaciones se resume en tabla 3.3, la cual muestra en su
lado izquierdo las entidades procedentes de Prometheus junto a sus figuras asociadas, y en
el lado derecho, las entidades equivalentes en INGENIAS y sus respectivas figuras.
46
Tabla 3.3. Equivalencia entre conceptos de Prometheus e INGENIAS
Prometheus INGENIAS
Entidad Figura Entidad Figura
Agente
Agente
Actor
Aplicación
Acción
Método
Percepción
Evento de Aplicación
Mensaje
Unidad de Interacción
Dato
Aplicación
A lo largo de este capítulo, se proporcionan una serie de tablas con el fin de mostrar al
lector cómo se realiza la transformación de conceptos entre ambas metodologías. Dichas
tablas muestran en su parte izquierda la entidad origen en Prometheus y su tipo, y en la
parte derecha la entidad obtenida en INGENIAS junto con su tipo equivalente.
A continuación se muestran las equivalencias obtenidas en INGENIAS a partir de los
agentes y actores procedentes de Prometheus (tablas 3.4 y 3.5, respectivamente).
Tabla 3.4. Agentes obtenidos desde Prometheus
Prometheus INGENIAS
Entidad Tipo Entidad Tipo
agLector Agente agLector Agente
agPuerta Agente agPuerta Agente
agSensorContacto Agente agSensorContacto Agente
agSensorInfrarrojo Agente agSensorInfrarrojo Agente
agTailgating Agente agTailgating Agente
agPuertaBloqueada Agente agPuertaBloqueada Agente
agIntercomunicador Agente agIntercomunicador Agente
47
Tabla 3.5. Aplicaciones obtenidas a partir de los actores de Prometheus
Prometheus INGENIAS
Entidad Tipo Entidad Tipo
acLector Actor acLector Aplicación
acPuerta Actor acPuerta Aplicación
acSensorContacto Actor acSensorContacto Aplicación
acSensorInfrarrojo Actor acSensorInfrarrojo Aplicación
acCentralita Actor acCentralita Aplicación
A continuación se muestran las tablas que describen las aplicaciones obtenidas a partir
de la transformación de los actores obtenidos en la fase anterior (tablas 3.7 a 3.11). La
columna tipo muestra el tipo de entidad origen y destino en la transformación. Además, se
ha añadido una descripción para aclarar el cometido de cada entidad. Resaltar que el
nombre de la entidad obtenida en INGENIAS es el mismo que su equivalente en
Prometheus. En tabla 3.6 se resume el significado de cada uno de los tipos empleados.
Tabla 3.6. Leyenda
Tipo Descripción
P Percepción
ME Método
M Mensaje
IU Unidad de interacción sin información
IUFF Unidad de interacción con información
AE Evento de aplicación sin información
AES Evento de aplicación con información
AC Acción
Tabla 3.7. Aplicación acLector
Prometheus INGENIAS
Entidad Tipo Tipo Descripción
pTicketLeido P AES Evento que contiene el número de ticket leído.
aIluminarLedAutorizado AC ME Ilumina el led verde en el interfaz del lector que indica un
usuario autorizado.
aIluminarLedNoAutorizado AC ME Ilumina el led rojo en el interfaz del lector que indica un
usuario no autorizado.
Tabla 3.8. Aplicación acPuerta
Prometheus INGENIAS
Entidad Tipo Tipo Descripción
aAbrir AC Provoca la apertura de la puerta.
aRetardar AC Introduce un retardo entre la apertura y el cierre de la
puerta.
aCerrar AC Provoca el cierre de la puerta.
48
Tabla 3.9. Aplicación acSensorInfrarrojo
Prometheus INGENIAS
Entidad Tipo Tipo Descripción
pInfrarrojoCortado P AE Evento que indica que el infrarrojo se ha cortado debido
al paso de un usuario a través de la puerta.
Tabla 3.10. Aplicación acSensorContacto
Prometheus INGENIAS
Entidad Tipo Tipo Descripción
pPuertaAbierta P AE Evento que indica que la puerta se encuentra en
estado abierto.
pPuertaCerrada P AE Evento que indica que la puerta se encuentra en
estado cerrado.
Tabla 3.11. Aplicación acCentralita
Prometheus INGENIAS
Entidad Tipo Tipo Descripción
aNotificarTailgating AC ME
Notifica al vigilante la detección de una
situación de tailgating en el interfaz del
recurso.
aNotificarPuertaBloqueada AC ME
Notifica al vigilante la detección de una
situación de bloqueo de la puerta en el interfaz
del recurso.
aIluminarLedPuertaAbiertaCentralita AC ME Ilumina el led verde en el interfaz de centralita
que indica que la puerta se encuentra abierta.
aIluminarLedPuertaCerradaCentralita AC ME Ilumina el led rojo en el interfaz de centralita
que indica que la puerta se encuentra cerrada.
aIluminarLedAutorizadoCentralita AC ME Ilumina el led verde en el interfaz de centralita
que indica un usuario autorizado.
aIluminarLedNoAutorizadoCentralita AC ME Ilumina el led rojo en el interfaz de centralita
que indica un usuario no autorizado.
aIncrementarContadorTrafico AC ME Incrementa el contador de tráfico de un
módulo concreto.
aIncrementarContadorPersonasDentro AC ME Incrementa el contador de personas que se
encuentran dentro del recinto cerrado.
aDecrementarContadorPersonasDentro AC ME Decrementa el contador de personas que se
encuentran dentro del recinto cerrado.
En tabla 3.12 se describe la aplicación obtenida en INGENIAS al transformar un dato
de granularidad gruesa obtenido en el modelo de Prometheus. El dato BDD se ha
transformado en INGENIAS en una aplicación que permite gestionar el acceso a la base de
datos que contiene la información relativa a los tickets de usuario autorizados. Esta
aplicación devuelve el resultado de la consulta (comprobarUsuario) en dicha base de datos
49
con uno de los dos eventos siguientes: UsuarioAutorizado y UsuarioNoAutorizado.
Resaltar que los datos ConfiguracionModulo, PersonasDentro y Trafico no se han
transformado en aplicaciones dado que su simplicidad (son de granularidad fina) permiten
manejarlos en la implementación de los métodos de aplicación como variables. Notar que
en las columnas entidad y tipo de Prometheus aparece un “-” que significa que lo
introducido en INGENIAS no tiene correspondencia con ningún concepto de Prometheus.
Tabla 3.12. Aplicación BDD
Prometheus INGENIAS
Entidad Tipo Entidad Tipo Descripción
- - comprobarUsuario ME Comprueba en la BDD la validez del ticket
introducido por el usuario en el lector.
- - UsuarioAutorizado AE Indica que el ticket de usuario leído es válido.
- - UsuarioNoAutorizado AE Indica que el ticket de usuario leído no es válido.
Las aplicaciones obtenidas mediante la transformación sólo incluyen relaciones con los
agentes para representar las percepciones que éstas envían y los métodos que representan
las acciones ejecutadas por los agentes, es decir, solamente contemplan cambios sobre el
entorno. Es preciso refinar las aplicaciones añadiendo métodos auxiliares que representen
otro tipo de acciones necesarias para permitir, por ejemplo, cambiar el estado de una puerta
o controlar el interfaz gráfico de una aplicación. A continuación se muestran los métodos
auxiliares añadidos en cada una de las aplicaciones que lo han requerido (tablas 3.13 a
3.16).
Tabla 3.13. Métodos auxiliares de la aplicación acLector
Prometheus INGENIAS
Entidad Tipo Entidad Tipo Descripción
- - insertarTicket ME Dispara la percepción pTicketLeido.
- - activarInterfaz ME Activa el interfaz del lector.
- - desactivarInterfaz ME Desactiva el interfaz del lector.
- - dameId ME Devuelve el ID asociado al recurso.
Tabla 3.14. Métodos auxiliares de la aplicación acSensorInfrarrojo
Prometheus INGENIAS
Entidad Tipo Entidad Tipo Descripción
- - iluminarLedInfrarrojoCortado ME Ilumina el led negro que indica que el
infrarrojo se ha cortado.
- - iluminarLedInfrarrojoLibre ME Ilumina el led rojo que indica que el
infrarrojo no está cortado.
- - cortarInfrarrojo ME Dispara la percepción pInfrarrojoCortado.
- - activarInterfaz ME Activa el interfaz del infrarrojo.
- - desactivarInterfaz ME Desactiva el inferfaz del infrarrojo.
- - dameId ME Devuelve el ID asociado al recurso.
50
Tabla 3.15. Métodos auxiliares de la aplicación acSensorContacto
Prometheus INGENIAS
Entidad Tipo Entidad Tipo Descripción
- - iluminarLedPuertaAbierta ME Ilumina el led verde en el interfaz del sensor
que indica que la puerta se encuentra abierta.
- - iluminarLedPuertaCerrada ME
Ilumina el led rojo en el interfaz del sensor
que indica que la puerta se encuentra
cerrada.
- - iluminarLedPuertaBloqueada ME
Ilumina el led negro en el interfaz del sensor
que indica que la puerta se encuentra
bloqueada.
- - iluminarLedPuertaDesbloqueada ME
Ilumina el led blanco en el interfaz del
sensor que indica que la puerta no está
bloqueada.
- - cambiarEstadoPuerta ME Provoca que se perciba un cambio en estado
en la puerta.
- - bloquearPuertaUsuarioToggle ME Provoca el bloqueo/desbloqueo de la puerta
por parte de un usuario.
- - bloquearPuertaVigilanteToggle ME Provoca el bloqueo/desbloqueo de la puerta
por parte del vigilante.
Tabla 3.16. Métodos auxiliares de la aplicación acCentralita
Prometheus INGENIAS
Entidad Tipo Entidad Tipo Descripción
- - incrementarContadorTickets ME Incrementa el contador de tickets
introducidos en un módulo concreto.
- - incrementarContadorTicketsTotal ME Incrementa el contador de tickets totales
introducidos en el sistema.
- - activarBotonVigilante ME Desactiva el botón que permite al vigilante
bloquear la puerta de un módulo.
- - desactivarBotonVigilante ME Activa el botón que permite al vigilante
bloquear la puerta de un módulo.
- - reinicializarContadores ME Pone a cero todos los contadores mostrados
en la centralita.
Las aplicaciones obtenidas han dado como resultado el diagrama de entorno que se
muestra en las figuras 3.24.a y 3.24.b. Este diagrama incluye el conjunto de agentes y
aplicaciones existentes en el sistema. La relación entre estas entidades se establece para
reflejar la utilización de aplicaciones por parte de los agentes (ApplicationBelongsTo) y
para conocer los agentes receptores de los eventos generados por cada aplicación
(EPercives).
51
Figura 3.24.a. Diagrama de entorno
52
Figura 3.24.b. Diagrama de entorno
El diagrama de interacción muestra un esquema de la comunicación entre agentes por
medio de mensajes (véanse las figuras 3.25.a y 3.25.b). En el diagrama aparecen todos los
mensajes existentes en el sistema sobre los que se ha establecido una relación de tipo
UInitiates con el agente emisor y otra relación de tipo UColaborates con el receptor.
53
Figura 3.25.a. Diagrama de interacción
54
Figura 3.25.b. Diagrama de interacción
3.4.2. Identificación de tareas
El siguiente paso en el diseño detallado consiste en identificar las tareas que ejecuta
cada agente. Una tarea, engloba la invocación de uno o varios métodos y/o el envío de
mensajes a otros agentes con el fin de acercarse a un objetivo marcado o como respuesta a
eventos que el agente recibe de su entorno. Al examinar el modelo de interacción de
agentes obtenido, se puede deducir que por cada “mensaje” recibido por un agente debe
haber una tarea asociada al agente para atender la llegada del evento. De la misma manera,
examinando el modelo del entorno inicial obtenido, se puede deducir que por cada
percepción que llega a un agente también debe haber una tarea asociada. Se debe aclarar
que las tareas se corresponden con las acciones semánticas que ejecutan los agentes.
Las tablas siguientes muestran las acciones semánticas ejecutadas por cada agente del
sistema en respuesta a mensajes y percepciones (tablas 3.17 a 3.23). Cada tabla presenta en
lado izquierdo el evento en INGENIAS, y su tipo, que provoca la ejecución de la acción
semántica. Después se muestra la acción semántica ejecutada y a su derecha una breve
descripción.
55
Tabla 3.17. Acciones semánticas ejecutadas por el agente agLector
INGENIAS
Evento Tipo Acción Semántica Descripción
pTicketLeido AE ComprobarTicket
Comprueba el ticket introducido por el
usuario mediante el método
ComprobarUsuario del recusoBDD.
SensorContactoALector
Activar IU Activar Se activa la interfaz del recurso acLector.
SensorContactoALector
Desactivar IU Desactivar
Se desactiva la interfaz del recurso
acLector.
usuarioAutorizado AE Autorizado
Comunica al agente agPuerta que puede
comenzar el proceso de apertura ya que se
trata de un usuario autorizado.
usuarioNoAutorizado AE NoAutorizado
No comunica nada al agente agPuerta, se
prepara para la introducción de un nuevo
ticket.
Comenzar AE Nula -
Finalizar AE Nula -
Tabla 3.18. Acciones semánticas ejecutadas por el agente agPuerta
INGENIAS
Evento Tipo Acción Semántica Descripción
LectorAPuertaIdentificacion
Valida IU AbrirPuertaAutorizado
Inicia el proceso de apertura, retardo y
cierre de la puerta.
pCerrandoPuerta AE ComunicarCerrandoPuerta Comunica al agente SensorContacto
que se va a proceder a cerrar la puerta.
Comenzar AE Nula -
Finalizar AE Nula -
Tabla 3.19. Acciones semánticas ejecutadas por el agente agSensorInfrarrojo
INGENIAS
Evento Tipo Acción Semántica Descripción
pInfrarrojoCortado AE ComunicarInfrarrojoCortado Comunica al agente agTailgating que ha
atravesado la puerta un usuario.
SensorContactoASensor
InfrarrojoActivar IU Activar
Activa la interfaz del recurso
acSensorInfrarrojo.
SensorContactoASensor
InfrarrojoDesactivar IU Desactivar
Desactiva la interfaz del recurso
acSensorInfrarrojo.
PuertaASensorInfrarrojo
PasarUsuarioAutorizado IU ComunicarInfrarrojoCortado
Comunica al agente agTailgating que ha
atravesado la puerta un usuario
autorizado.
Comenzar AE Nula -
Finalizar AE Nula -
56
Tabla 3.20. Acciones semánticas ejecutadas por el agente agSensorContacto.
INGENIAS
Evento Tipo Acción Semántica Descripción
pPuertaAbierta AE ComunicarPuertaAbierta
Comunica al agente
agTailgating que la
puerta esta abierta y al
agente
agSensorInfrarrojo que
debe activarse.
pPuertaAbierta AE ComunicarPuertaBloqueada
Comunica al agente
agPuertaBloqueada que
la puerta está bloqueada.
pPuertaCerrada AE ComunicarPuertaCerrada
Comunica al agente
agTailgating que la
puerta está cerrada, al
agente
agSensorInfrarrojo que
debe desactivarse y al
agente agLector que
debe activarse.
pPuertaCerrada AE ComunicarPuertaBloqueada
Comunica al agente
agPuertaBloqueada que
la puerta está bloqueada.
PuertaASensorContacto
AbriendoPuerta IU CambiarEstadoPuerta
Cambia el estado de la
puerta.
PuertaASensorContacto
AbriendoPuerta IU Nula -
PuertaASensorContacto
CerrandoPuerta IU CambiarEstadoPuerta
Cambia el estado de la
puerta.
PuertaASensorContacto
CerrandoPuerta IU Nula -
pDesbloqueo AE CambiarEstadoPuerta Cambia el estado de la
puerta.
pPuertaBloqueadaVigilante AE ComunicarPuertaBloqueadaVigilante
Comunica al agente
agLector que debe
desactivarse.
pPuertaDesbloqueadaVigilante AE ComunicarPuertaDesbloqueadaVigilante
Comunica al agente
agLector que debe
activarse.
pBloquearPuertaVigilante AE BloquearPuertaVigilante Cambia el estado de
bloqueo.
Comenzar AE Nula -
Finalizar AE Nula -
57
Tabla 3.21. Acciones semánticas ejecutadas por el agente agTailgating
INGENIAS
Evento Tipo Acción Semántica Descripción
SensorInfrarrojoATailgating
InfrarrojoCortado IU NotificarTailgating
Notifica a centralita la detección de una
situación de tailgating.
SensorInfrarrojoATailgating
InfrarrojoCortado IU Nula -
SensorContactoATailgating
PuertaAbierta IU Nula -
SensorContactoATailgating
PuertaCerrada IU Nula -
Comenzar AE Nula -
Finalizar AE Nula -
Tabla 3.22. Acciones semánticas ejecutadas por el agente agPuertaBloqueada
INGENIAS
Evento Tipo Acción Semántica Descripción
SensorContactoAPuerta
BloqueadaPuertaBloqueada IU NotificarPuertaBloqueada
Notifica a centralita la detección de una
situación de puerta bloqueada.
Comenzar AE Nula -
Finalizar AE Nula -
Se debe decir que el evento Comenzar ha sido necesario introducirlo porque está ligado
a la implementación y no genera código asociado. Comenzar es enviado por el gestor de
agentes al agente de aplicación para que se inicie la ejecución del autómata que describe su
comportamiento. El evento Finalizar se envía para cerrar la aplicación y liberar los
recursos utilizados. La acción semántica Nula no realiza ningún cómputo.
58
Tabla 3.23. Acciones semánticas ejecutadas por el agente agIntercomunicador
INGENIAS
Evento Tipo Acción Semántica Descripción
LectorAPuertaIdentificacionValida IU ComunicarAPuertaAbrir Notifica mensaje del agente agLector al agente agPuerta
para comunicarle que la identificación ha sido válida.
PuertaASensorContactoAbriendoPuerta IU ComunicarASensorContactoAbriendo
Notifica mensaje del agente agPuerta al agente
agSensorContacto para comunicarle que se está
procediendo a abrir la puerta.
PuertaASensorContactoCerrandoPuerta IU ComunicarASensorContactoCerrando
Notifica mensaje del agente agPuerta al agente
agSensorContacto para comunicarle que se está
procediendo a cerrar la puerta.
SensorContactoALectorActivar IU ComunicarALectorActivar
Notifica mensaje del agente agSensorContacto al agente
agLector para comunicarle que puede proceder a activar la
interfaz del lector.
SensorContactoALectorDesactivar IU ComunicarALectorDesactivar
Notifica mensaje del agente agSensorContacto al agente
agLector para comunicarle que puede proceder a
desactivar la interfaz del lector.
SensorContactoASensorInfrarrojoActivar IU ComunicarASensorInfrarrojoActivar
Notifica mensaje del agente agSensorContacto al agente
agInfrarrojo para comunicarle que puede proceder a
activar la interfaz del sensor.
SensorContactoASensorInfrarrojoDesactivar IU ComunicarASensorInfrarrojoDesactivar
Notifica mensaje del agente ag SensorContacto al agente
agInfrarrojo para comunicarle que puede proceder a
desactivar la interfaz del sensor.
PuertaASensorInfrarrojoPasarUsuarioAutorizado IU ComunicarASensorInfrarrojoPasarUsuarioAutorizado
Notifica mensaje del agente agPuerta al agente
agSensorInfrarrojo para comunicarle que debe pasar el
usuario autorizado.
Comenzar AE Nula -
Finalizar AE Nula -
59
3.4.3. Especificación del modelo de comportamiento de los agentes
El comportamiento de un agente se puede describir mediante un diagrama de estados
que indica, para cada estado, los eventos que puede recibir y las acciones semánticas que
puede ejecutar como respuesta a cada evento. El autómata resultante se puede obtener a
partir de las acciones semánticas expuestas previamente y los eventos que recibe el agente.
En la figura 3.26 se muestra, para un agente cualquiera, una transición entre estados. Esta
transición se produce cuando el agente recibe un evento (Evento_Recibido), para el que
responde con una acción semántica (Acción_Respuesta_a_Evento), transitando al estado
siguiente (Estado_Tras_Ejecutar_Acción).
Figura 3.26. Comportamiento de un agente
Existe un estado común al autómata de todos los agentes que conforman el sistema.
Este estado, denominado UniversalState, se utiliza para describir la transición universal y
representa cualquier estado del autómata. La transición universal se produce cuando un
agente, en cualquiera de sus estados, transita al estado Fin al recibir el evento finalizar.
Como respuesta a este evento el agente responde con la acción semántica Nula.
A continuación se describe el autómata de cada agente obtenido en INGENIAS. Para
ilustrar la descripción de los autómatas se incluye una figura del autómata especificado con
la herramienta IDK y otra representación equivalente del diagrama con la notación propia
de UML (véanse figuras 3.27.a a 3.33.b). Además, se muestra la tabla de eventos recibidos
que recoge la entidad que emite el evento, la entidad y tipo correspondiente en Prometheus,
el tipo correspondiente en INGENIAS y el contenido del evento (tablas 3.24 a 3.30).
El autómata del agente agLector (véanse figuras 3.27.a y 3.27.b) se encuentra
inicialmente inactivo para evitar que un usuario introduzca un ticket cuando el sistema aún
no puede atender una petición (estado EsperarActivación). Una vez que el sistema se ha
inicializado por completo y se ha detectado que la puerta se encuentra cerrada, el agente
60
agSensorContacto comunica al agente agLector que puede proceder a activar la interfaz
(estado EsperarTicket). En ese momento el lector se encuentra disponible para leer los
tickets de usuario. Cuando un usuario introduce un ticket se ejecuta la acción semántica
ComprobarTicket y se pasa al estado EsperarComprobacionTicket en espera del resultado.
En caso de que el ticket sea válido se desactivará la interfaz para que un nuevo usuario no
pueda introducir otro ticket (estado EsperarActivacion). En otro caso se regresará al estado
anterior a la espera de un nuevo ticket (estado EsperarTicket).
Tabla 3.24. Eventos recibidos por el agente agLector
Prometheus INGENIAS
Evento Tipo Tipo Contenido Emisor
pTicketLeido P AES Ticket String acLector
SensorContactoALectorActivar M IU - agSensorContacto
SensorContactoALectorDesactivar M IU - agSensorContacto
usuarioAutorizado P AE - recursoBDD
usuarioNoAutorizado P AE - recursoBDD
Comenzar - AE - -
Finalizar - AE - -
Figura 3.27a. Autómata del agente agLector obtenido en INGENIAS
61
stm agLector
EstadoInicial
EstadoFinal
EsperarActiv acion
EsperarTicket
EsperarComprobacionTicket
Transición universal: (Sx, EstadoFinal): finalizar / nula
Sx es cualquier estado del autómata
[usuarioAutorizado /
Autorizado]
[usuarioNoAutorizado /
NoAutorizado]
[SensorContactoALectorDesactivar
/ desactivar]
[SensorContactoALectorDesactivar
/ desactivar]
[pTicketLeido /
ComprobarTicket]
[SensorContactoALectorActivar
/ activar]
[comenzar / nula]
Figura 3.27b. Autómata del agente agLector
El agente agPuerta (véanse figuras 3.28.a y 3.28.b) se encuentra esperando la
comunicación de un usuario válido (estado EsperarUsuarioValido). Cuando recibe el
evento LectorAPuertaIdentificaciónValida procede a abrir la puerta mediante la acción
semántica AbirPuerta. Tras ejecutar dicha acción semántica comunica al agente
agSensorContacto que se está procediendo a cerrar la puerta para que compruebe si esta
acción se ha realizado con éxito.
Tabla 3.25. Eventos recibidos por el agente agPuerta
Prometheus INGENIAS
Evento Tipo Tipo Contenido Emisor
LectorAPuertaIdentificacionValida M IU - agLector
pCerrandoPuerta P AE - acPuerta
Comenzar - AE - -
Finalizar - AE - -
62
Figura 3.28a. Autómata del agente agPuerta obtenido en INGENIAS
stm agPuerta
EstadoInicial
EstadoFinal
EsperarUsuarioValido
Transición universal: (Sx, EstadoFinal): finalizar / nula
Sx es cualquier estado del autómata
[pCerrandoPuerta /
ComunicarCerrandoPuerta][LectorAPuertaIdentificacionValida
/ AbrirPuerta]
[comenzar / nula]
Figura 3.28b. Autómata del agente agPuerta
63
El autómata del agente agSensorInfrarrojo (véanse figuras 3.29.a y 3.29.b) cuenta con
un solo estado intermedio (EsperarInfrarrojo). Inicialmente se encuentra a la espera de
recibir, de la aplicación acSensorInfrarrojo, el evento que le indica que el infrarrojo se ha
cortado (pInfrarrojoCortado), al que reacciona comunicando al agente agTailgating dicho
suceso mediante la acción semántica ComunicarInfrarrojoCortado. Este evento se produce
como consecuencia de la interacción con la interfaz de uso del recurso8, la cual permite
provocar el corte del infrarrojo. El agente agSensorInfrarrojo reacciona de la misma
manera cuando recibe el evento PuertaASensorInfrarrojoPasarUsuarioAutorizado, ya que
de esta manera se contabiliza el usuario autorizado que debe pasar cuando se abre la puerta
del módulo como consecuencia de la identificación positiva del usuario. Los eventos
SensorContactoASensorInfrarrojoActivar y SensorContactoASensorInfrarrojoDesactivar
comunican al agente la necesidad de activar/desactivar la interfaz de uso mientras la puerta
del módulo permanece abierta/cerrada. Esta activación/desactivación no afecta al
funcionamiento del agente, que puede contabilizar el paso del usuario autorizado antes de
que se permita operar a través de la interfaz.
Tabla 3.26. Eventos recibidos por el agente agSensorInfrarrojo
Prometheus INGENIAS
Evento Tipo Tipo Contenido Emisor
pInfrarrojoCortado P AE - acSensorInfrarrojo
SensorContactoASensorInfrarrojoActivar M IU - agSensorContacto
SensorContactoASensorInfrarrojoDesactivar M IU - agSensorContacto
PuertaASensorInfrarrojoPasarUsuarioAutorizado M IU - agPuerta
Comenzar - AE - -
Finalizar - AE - -
8 El recurso es un concepto que aparecerá en la implementación. Los recursos se obtienen a partir de las
entidades de tipo aplicación del modelo de INGENIAS. En el contexto de este capítulo utilizar el término
recurso es equivalente a utilizar el término aplicación.
64
Figura 3.29.a. Autómata del agente agSensorInfrarrojo obtenido en INGENIAS
stm agSensorInfrarrojo
EstadoInicial
EstadoFinal
EsperarInfrarrojo
Transición universal: (Sx, EstadoFinal): finalizar / nula
Sx es cualquier estado del autómata
[PuertaASensorInfrarrojoPasarUsuarioAutorizado
/ ComunicarInfrarrojoCortado]
[SensorContactoASensorInfrarrojoDesactivar
/ desactivar]
[SensorContactoASensorInfrarrojoActivar
/ activar]
[pInfrarrojoCortado /
ComunicarInfrarrojoCortado]
[comenzar / nula]
Figura 3.29.b. Autómata del agente agSensorInfrarrojo
65
El autómata del agente agSensorContacto (véanse figuras 3.30.a y 3.30.b) dispone de
dos estados claramente diferenciados, PuertaAbierta y PuertaCerrada, que se
corresponden con los estados detectados en la puerta del módulo. La puerta, controlada por
el agente agPuerta, funciona de manera independiente al estado detectado por el sensor de
contacto, es decir, únicamente realiza las acciones de apertura y cierre, introduciendo el
correspondiente retardo, al margen del estado que detecta el sensor de contacto. Esto puede
producir situaciones en las que la puerta efectúe el proceso de apertura cuando ésta haya
sido bloqueada, por lo tanto, el estado real en que se encuentra la puerta solamente lo
puede determinar el agente agSensorContacto. Este agente se encuentra inicialmente en el
estado PuertaCerrada, a la espera de recibir la comunicación del agente agPuerta que le
indique el inicio del proceso de apertura de la puerta
(PuertaASensorContactoAbriendoPuerta). Cuando recibe el evento ejecuta la acción
semántica CambiarEstadoPuerta que provoca el cambio de estado, almacenado
internamente, y cuyo resultado dependerá del estado de bloqueo/desbloqueo de la puerta.
Inmediatamente, el agente recibe el evento de la aplicación acSensorContacto que indica el
nuevo estado de la puerta. Si la puerta se encuentra desbloqueada será pPuertaAbierta, el
cual provoca la transición al estado PuertaAbierta. En caso contrario recibirá el evento
pPuertaCerrada, que indica al agente que la puerta se encuentra bloqueada al encontrarse
ya en el estado PuertaCerrada. En el estado PuertaAbierta el agente espera a recibir el
evento que provoque un cambio en el estado de la puerta
(PuertaASensorContactoCerrandoPuerta), tal y como se acaba de explicar, mediante la
acción semántica CambiarEstadoPuerta. Como sucedía en el estado PuertaCerrada, la
ejecución de la acción semántica provoca la percepción del estado de la puerta en función
de si está bloqueada o no. En caso de no estar bloqueada, recibirá el evento
pPuertaCerrada que provoca la transición al estado PuertaCerrada. En caso contrario,
recibirá el evento pPuertaAbierta, indicándole que la puerta ha sido bloqueada y
provocando la ejecución de la acción semántica ComunicarPuertaBloqueada. En este
estado, el bloqueo ha sido efectuado por un usuario, por lo tanto no se desbloqueará hasta
que el usuario desactive el bloqueo. El agente recibirá el evento pDesbloqueo provocando
un nuevo cambio de estado.
66
Tabla 3.27. Eventos recibidos por el agente agSensorContacto
Prometheus INGENIAS
Evento Tipo Tipo Contenido Emisor
pPuertaAbierta P AE - acSensorContacto
pPuertaCerrada P AE - acSensorContacto
PuertaASensorContactoAbriendoPuerta M IU - agPuerta
PuertaASensorContactoCerrandoPuerta M IU - agPuerta
pDesbloqueo P AE - acSensorContacto
pPuertaBloqueadaVigilante P AE - acSensorContacto
pPuertaDesbloqueadaVigilante P AE - acSensorContacto
pBloquearPuertaVigilante P AE - acCentralita
Comenzar - AE - -
Finalizar - AE - -
Figura 3.30.a. Autómata del agente agSensorContacto obtenido en INGENIAS
67
Figura 3.30.b. Autómata del agente agSensorContacto
El agente agTailgating (véanse figuras 3.31.a y 3.31.b) se encuentra inicialmente a la
espera de que se produzca la apertura de la puerta para contabilizar el paso de usuarios a
través de la puerta (estado EsperarPuertaAbierta). El paso de un usuario autorizado se
contempla cada vez que se abre la puerta. Cuando esto ocurre, el agente recibe el evento
SensorInfrarrojoATailgatingInfrarrojoCortado, provocando que el autómata transite al
estado Infrarrojo1. En este estado se puede volver a cortar el infrarrojo, lo cual produce la
detección de una situación de tailgating (acción semántica NotificarTailgating) y el paso al
siguiente estado, Infrarrojo2. En el estado Infrarrojo2 cualquier nuevo evento que indique
el corte del infrarrojo produce la notificación de la situación de tailgating. Resaltar que
esta notificación se envía a la aplicación acCentralita para poner en conocimiento del
vigilante la detección del suceso. En ambos estados, Infrarrojo1 e Infrarrojo2, puede
recibirse el evento que indica que se ha detectado que la puerta está cerrada, lo cual
68
provoca que el agente transite al estado inicial EsperarPuertaAbierta, dejando de ser
posible el paso de usuarios no autorizados a través de la puerta del módulo.
Tabla 3.28. Eventos recibidos por el agente agTailgating
Prometheus INGENIAS
Evento Tipo Tipo Contenido Emisor
SensorInfrarrojoATailgatingInfrarrojoCortado M IU - agSensorInfrarrojo
SensorContactoATailgatingPuertaAbierta M IU - agSensorContacto
SensorContactoATailgatingPuertaCerrada M IU - agSensorContacto
Comenzar - AE - -
Finalizar - AE - -
Figura 3.31.a. Autómata del agente agTailgating obtenido en INGENIAS
69
stm agTailgating
EstadoInicial
EstadoFinal
EsperarNotificacionInfrarrojo
Infrarrojo1
Infrarrojo2
EsperarPuertaAbierta
Transición universal: (Sx, EstadoFinal): finalizar / nula
Sx es cualquier estado del autómata
[SensorContactoATailgatingPuertaAbierta / nula]
[SensorContactoATailgatingPuertaCerrada
/ nula]
[SensorInfrarrojoATailgatingInfrarrojoCortado /
NotificarTailgating]
[SensorContactoATailgatingPuertaCerrada
/ nula][SensorInfrarrojoATailgatingInfrarrojoCortado /
NotificarTailgating]
[SensorInfrarrojoATailgatingInfrarrojoCortado /
nula]
[comenzar / nula]
Figura 3.31.b. Autómata del agente agTailgating
El agente agPuertaBloqueada (véanse figuras 3.32.a y 3.32.b) se encuentra a la espera
de recibir la notificación que le indique que la puerta ha sido bloqueada, pues la detección
de la situación se produce en el agente agSensorContacto. Este último agente comunica al
agente agPuertaBloqueada el suceso mediante el evento
SensorContactoAPuertaBloqueadaPuertaBloqueada, que produce la ejecución de la acción
semántica NotificarPuertaBloqueada por parte del agente agPuertaBloqueada. Esta
notificación se envía a la aplicación agCentralita, al igual que se hace cuando se detecta
una situación de tailgating.
70
Tabla 3.29. Eventos recibidos por el agente agPuertaBloqueada
Prometheus INGENIAS
Evento Tipo Tipo Contenido Emisor
SensorContactoAPuertaBloqueadaPuertaBloqueada M IU - agSensorContacto
Comenzar - AE - -
Finalizar - AE - -
Figura 3.32.a. Autómata del agente agPuertaBloqueada obtenido en INGENIAS
71
stm agPuertaBloqueada
EstadoInicial
EstadoFinal
EsperarNotificacionPuertaBloqueada
Transición universal: (Sx, EstadoFinal): finalizar / nula
Sx es cualquier estado del autómata
[SensorContactoAPuertaBloqueadaPuertaBloqueada /
NotificarPuertaBloqueada]
[comenzar / nula]
Figura 3.32.b. Autómata del agente agPuertaBloqueada
El agente agIntercomunicador (véanse figuras 3.33.a y 3.33.b) tiene la responsabilidad
de operar como intermediario en la comunicación entre agentes ligados a dispositivos
físicos, salvo en los casos de detección de situaciones sospechosas, tal y como se comentó
en la fase anterior del diseño. Por lo tanto, el autómata de este agente dispone de un único
estado intermedio (EsperarMensaje) que le permite recibir los eventos enviados por el
agente que inicia la comunicación, para de inmediato, proceder a reenviar el evento
recibido al agente receptor en la comunicación.
Tabla 3.30. Eventos recibidos por el agente agIntercomunicador
Prometheus INGENIAS
Evento Tipo Tipo Contenido Emisor
LectorAPuertaIdentificacionValida M IU - agLector
PuertaASensorContactoAbriendoPuerta M IU - agPuerta
PuertaASensorContactoCerrandoPuerta M IU - agPuerta
SensorContactoALectorActivar M IU - AgSensorContacto
SensorContactoALectorDesactivar M IU - AgSensorContacto
SensorContactoASensorInfrarrojoActivar M IU - AgSensorContacto
SensorContactoASensorInfrarrojoDesactivar M IU - AgSensorContacto
PuertaASensorInfrarrojoPasarUsuarioAutorizado M IU - AgPuerta
Comenzar - AE - -
Finalizar - AE - -
72
Figura 3.33.a. Autómata del agente agIntercomunicador obtenido en INGENIAS
73
Figura 3.33.b. Autómata del agente agIntercomunicador
3.4.4. Crear diagrama de componentes
El último paso de la fase de diseño detallado consiste en establecer, para cada tarea,
una relación con un componente de código en el diagrama de componentes (véase figura
3.34). Esto es necesario para realizar la generación de código, pues se utilizará este
componente como base para generar el código, tal y cómo se describirá más adelante en el
siguiente capítulo.
74
Figura 3.34. Diagrama de componentes
75
3.4.5. Crear diagrama de despliegue
El Diagrama de despliegue muestra la cantidad de instancias que se generarán para
cada entidad (véase figura 3.35). En el diagrama puede observarse que cada entidad se ha
relacionado con una nota de texto que muestra un número en su interior. Este número
indica el número de instancias que se generarán, en la ejecución, para cada entidad. Por
ejemplo, para el agente agLector se generarán cinco instancias, mientras que para el
recurso acCentralita se generará sólo una.
Figura 3.35. Diagrama de despliegue
76
77
4. IMPLEMENTACIÓN
La fase de implementación tiene como objetivo obtener un sistema ejecutable a partir
de los modelos obtenidos en la fase anterior. Para ello se genera automáticamente el código
de la infraestructura ICARO-T sobre el que se continúa la implementación manual del
sistema, añadiendo las interacciones agente-agente, agente-recurso y recurso-agente.
Posteriormente, se crean los interfaces gráficos para la interacción del usuario con el
sistema. Con el fin de ilustrar este proceso, se proporcionan algunos fragmentos de código
generado automáticamente, algunos fragmentos de código añadido manualmente para
llevar a cabo los tipos de interacción citados previamente y algunas capturas de los
interfaces gráficos. En el último apartado del capítulo se añade una mejora al sistema para
facilitar al usuario su uso.
4.1. Fase de generación de código
El código de la infraestructura se genera automáticamente a partir de los modelos
especificados en INGENIAS, dando como resultado, por un lado, el fichero que describe la
organización de la aplicación y que toma como base el modelo de despliegue explicado en
la sección 3.4.5 y, por otro lado, los paquetes y clases relativos a los agentes y aplicaciones
especificados durante el modelado.
El fichero despliegue.xml generado en el directorio
“config\icaro\aplicaciones\descripcionOrganizaciones” describe las características
generales de los componentes de la organización de la aplicación. Comienza describiendo
las propiedades globales de la organización, el comportamiento de los gestores y el
comportamiento de los agentes de la aplicación (véase figura 4.1), el cual queda descrito
para todos los agentes como reactivo9 (véase por ejemplo la línea 8 de la figura 4.1). Tras
una descripción de los recursos se describen las instancias de la aplicación. Por un lado,
describe las instancias de los gestores y por otro, las instancias de los agentes y de los
recursos. El identificador de cada instancia viene dado por el valor de atributo id (línea 4
de figura 4.2), mientras que el tipo lo proporciona el atributo refDescripción (línea 5 de
figura 4.2). Tras estos atributos pueden declararse otros manualmente para dotar a los
agentes de ciertas propiedades. Este ha sido el caso del agente agSensorInfrarrojo, que
incluye en cada una de sus instancias un atributo especial denominado Tipo y que puede
tomar los valores “entrada” o “salida” (línea 7 de figura 4.2). Este atributo se ha añadido
al despliegue de la aplicación para configurar cada instancia del agente como módulo de
entrada o de salida. Las instancias de los recursos de la aplicación quedan descritas de
forma similar a los agentes, es decir, el atributo id identifica cada una de las instancias y el
tipo viene dado por el atributo refDescripción. Al igual que en el caso del agente
9 Un agente reactivo, como su nombre indica, reacciona ante los cambios en el entorno ejecutando tareas que
lo acercan a los objetivos que tiene marcados.
78
agSensorInfrarrojo, ha sido necesario añadir una serie de atributos adicionales al recurso
BDD que proporcionan la configuración del origen de datos de la base de datos que
gestiona. Concretamente, se han añadido los atributos NOMBRE_DNS_SISTEMA,
NOMBRE_INICIO_SESION, CONTRASEÑA, URL_CONEXION y DRIVER_JDBC
(véanse líneas 3 a 7 de figura 4.3).
(1) <!--******************************************************************************************
(2) ***************** Descripcion del comportamiento de los agentes de aplicacion ********************
(3) ******************************************************************************************-->
(4) <icaro:DescComportamientoAgentesAplicacion>
(5) <icaro:DescComportamientoAgente nombreComportamiento="AgenteAplicacionagLector"
(6) rol="AgenteAplicacion"
(7) localizacionComportamiento="icaro.aplicaciones.agentes.agenteAplicacionagLectorReactivo.comporta
(8) miento" tipo="Reactivo" />
(9) <icaro:DescComportamientoAgente nombreComportamiento="AgenteAplicacionagIntercomunicador"
(10) rol="AgenteAplicacion"
(11) localizacionComportamiento="icaro.aplicaciones.agentes.agenteAplicacionagIntercomunicadorReactivo.
(12) comportamiento" tipo="Reactivo" />
(13) <icaro:DescComportamientoAgente nombreComportamiento="AgenteAplicacionagSensorInfrarrojo"
(14) rol="AgenteAplicacion"
(15) localizacionComportamiento="icaro.aplicaciones.agentes.agenteAplicacionagSensorInfrarrojoReactivo.
(16) comportamiento" tipo="Reactivo" />
(17) <icaro:DescComportamientoAgentenombreComportamiento="AgenteAplicacionagPuertaBloqueada"
(18) rol="AgenteAplicacion"
(19) localizacionComportamiento="icaro.aplicaciones.agentes.agenteAplicacionagPuertaBloqueadaReactivo.
(20) comportamiento" tipo="Reactivo" />
(21) <icaro:DescComportamientoAgente nombreComportamiento="AgenteAplicacionagPuerta"
(22) rol="AgenteAplicacion"
(23) localizacionComportamiento="icaro.aplicaciones.agentes.agenteAplicacionagPuertaReactivo.comportamiento"
(24) tipo="Reactivo" />
(25) <icaro:DescComportamientoAgente nombreComportamiento="AgenteAplicacionagTailgating"
(26) rol="AgenteAplicacion"
(27) localizacionComportamiento="icaro.aplicaciones.agentes.agenteAplicacionagTailgatingReactivo.
(28) comportamiento" tipo="Reactivo" />
(29) <icaro:DescComportamientoAgente nombreComportamiento="AgenteAplicacionagSensorContacto"
(30) rol="AgenteAplicacion"
(31) localizacionComportamiento="icaro.aplicaciones.agentes.agenteAplicacionagSensorContactoReactivo.
(32) comportamiento" tipo="Reactivo" />
(33) </icaro:DescComportamientoAgentesAplicacion>
Figura 4.1. Fragmento del fichero XML del despliegue de la aplicación
(1) <!--******************************************************************************************
(2) *************************** Instancias de Agentes de aplicacion *******************************
(3) ******************************************************************************************-->
………………………….
(4) <icaro:Instancia id="AgenteAplicacionagSensorInfrarrojoReactivo1"
(5) refDescripcion="AgenteAplicacionagSensorInfrarrojo">
(6) <icaro:listaPropiedades>
(7) <icaro:propiedad atributo="Tipo" valor="Entrada"/>
(8) </icaro:listaPropiedades>
(9) </icaro:Instancia>
Figura 4.2. Descripción de una instancia del agente agSensorInfrarrojo
79
(1) <icaro:Instancia id="RecursoBDD1" refDescripcion="RecursoBDD" xsi:type="icaro:Instancia">
(2) <icaro:listaPropiedades>
(3) <icaro:propiedad atributo="NOMBRE_DNS_SISTEMA" valor="TablaTickets" />
(4) <icaro:propiedad atributo="NOMBRE_INICIO_SESION" valor="usuario1" />
(5) <icaro:propiedad atributo="CONTRASEÑA" valor="contraseña1" />
(6) <icaro:propiedad atributo="URL_CONEXION" valor="jdbc:odbc:TablaTickets" />
(7) <icaro:propiedad atributo="DRIVER_JDBC" valor="sun.jdbc.odbc.JdbcOdbcDriver" />
(8) </icaro:listaPropiedades>
(9) </icaro:Instancia>
Figura 4.3. Descripción de la instancia del recurso BDD
La estructura de paquetes generada consta de un paquete por cada agente y recurso del
modelo, tal y como puede observarse en la figura 4.4. Considerando como ejemplo el
paquete que contiene la implementación del comportamiento del agente agTailgating,
icaro.aplicaciones.agentes.agenteAplicacionagTailgatingReactivo.comportamiento, se
puede ver que consta de dos ficheros. El primero de ellos es la clase
AccionesSemanticasAgenteAplicacionagTailgating que proporciona un esqueleto para los
métodos que implementarán, en Java, las acciones semánticas del autómata y que
constituirán la reacción del agente ante los estímulos exteriores. Estos métodos se
corresponden con las acciones semánticas ejecutadas por el agente. El otro fichero
generado dentro del paquete es el fichero automata.xml que describe el autómata
especificado en el modelo de INGENIAS. En este fichero se distinguen tres tipos de
estado: inicial, intermedio y final (líneas 1, 5 y 13, respectivamente, de figura 4.5). Los
estados inicial y final son comunes a todos los autómatas de INGENIAS y contienen una
única transición, la que inicia al agente mediante el evento comenzar (estado inicial) y la
que lo finaliza mediante finalizar (estado final), respectivamente. Esta última es una
transición de tipo universal, lo que implica que el autómata puede transitar al estado final
desde cualquier estado cuando reciba el evento citado. Las transiciones que describen el
comportamiento del agente se encuentran descritas con estados de tipo intermedio. El
estado Infrarrojo1 contiene dos transiciones posibles,
SensorInfrarrojoATailgatingInfrarrojoCortado y
SensorContactoATailgatingPuertaCerrada. Estas transiciones son los imput o eventos a
los que el agente reaccionará cuando se encuentre en dicho estado (líneas 6 y 9 de figura
4.5). La primera de ellas transita al estado Infrarrojo2 y provoca la ejecución de la acción
NotificarTailgating (línea 7) por parte del agente; la segunda lo hace al estado
EsperarPuertaAbierta y provoca la ejecución de la acción nula (línea 9). Ambas
transiciones son de tipo bloqueante, lo que significa que el agente no atenderá ningún otro
evento hasta que no haya finalizado la tarea lanzada en la última transición. Cualquier
evento recibido por el agente durante la ejecución de tareas quedará encolado a la espera
de su interpretación por parte del agente.
80
Figura 4.4. Estructura de paquetes de la aplicación
(1) <estadoInicial idInicial="EstadoInicial">
(2) <transicion input="comenzar" accion="nula" estadoSiguiente="EsperarNotificacionInfrarrojo"
(3) modoDeTransicion="bloqueante"/>
(4) </estadoInicial>
………………………….
(5) <estado idIntermedio="Infrarrojo1">
(6) <transicion input="SensorInfrarrojoATailgatingInfrarrojoCortado"
(7) accion="NotificarTailgating" estadoSiguiente="Infrarrojo2"
(8) modoDeTransicion="bloqueante"/>
(9) <transicion input="SensorContactoATailgatingPuertaCerrada" accion="nula"
(10) estadoSiguiente="EsperarNotificacionInfrarrojo"
(11) modoDeTransicion="bloqueante"/>
(12) </estado>
………………………….
(13) <estadoFinal idFinal="EstadoFinal"/>
Figura 4.5. Fragmento de código del autómata del agente agTailgating
Como se ha comentado anteriormente, cuando un agente recibe un evento reacciona
transitando conforme a lo descrito en su autómata asociado. Cada transición trae consigo la
ejecución de una acción semántica que se encuentra implementada en el código que
describe el comportamiento del agente. A la hora de desarrollar este código se parte del
esqueleto generado automáticamente, el cual consta de un método por cada acción
semántica que puede efectuar el agente. En figura 4.6 se puede apreciar un fragmento de
81
código del fichero AccionesSemanticasAgenteAplicacionagTailgating.java que muestra el
esqueleto generado para la acción semántica NotificarTailgating del agente agTailgating.
Como se puede observar, el código solamente declara el método asociado a la acción y
define un espacio donde añadir el código pertinente. Este espacio viene delimitado por los
comentarios #start_nodeNotificarTailgating y #end_nodeNotificarTailgating que se
emplean para permitir la modificación de los modelos en INGENIAS paralelamente al
desarrollo del código de la aplicación (líneas 4 y 6 de figura 4.6). Estos delimitadores
evitan que el código, previamente desarrollado, se “machaque” por el nuevo código
generado a partir de los modelos de INGENIAS. En la figura 4.7 se muestra el código
desarrollado manualmente para la acción aNotificarTailgating que, como se comentó en el
capítulo anterior, se encarga de notificar al recurso acCentralita la detección de una
situación anómala de tailgating. En el código mostrado se puede apreciar, en primer lugar,
la inicialización de la variable r_RecursoCentralita con la referencia al interfaz de uso de
la instancia del recurso acCentralita (línea 9). Para ello se utiliza el método
obtenerInterface del interfaz de uso itfUsoRepositorio, que proporciona la referencia a los
interfaces de cada uno de los agentes y aplicaciones declarados en el fichero XML de
despliegue. Es interesante resaltar, que el nombre pasado al método obtenerInterfaz es el
mismo que se ha asignado en dicho fichero de despliegue de la aplicación. Seguidamente,
en el código del método, se puede apreciar cómo se ejecutan las acciones sobre el recurso
acCentralita a través del interfaz de uso declarado. El método aMostrarTexto permite
mostrar un texto a través del interfaz gráfico del recurso (línea 14) y seguidamente, el
método aNofitifarTailgating (que comparte nombre con la acción semántica del agente)
muestra un mensaje preestablecido a través de dicho interfaz gráfico informando de la
detección de dicha situación anómala (línea 15). Nótese la trazabilidad de estos métodos a
lo largo de todo el diseño de la aplicación y cómo se puede llegar a las acciones declaradas
en el diseño inicial en Prometheus.
(1) //aNotificarTailgating is an intermediate action
(2) public void aNotificarTailgating(){
(3) //TODO: Complet aNotificarTailgating action implementation
(4) //#start_nodeaNotificarTailgating:aNotificarTailgating <--aNotificarTailgating-DO
NOT REMOVE THIS
(5)
(6) //#end_nodeaNotificarTailgating:aNotificarTailgating <--aNotificarTailgating—DO
NOT REMOVE THIS
(7) }
Figura 4.6. Esqueleto generado para la acción semántica aNotificarTailgating
82
(1) //aNotificarTailgating is an intermediate action
(2) public void aNotificarTailgating(){
(3) //TODO: Complet aNotificarTailgating action implementation
(4) //#start_nodeaNotificarTailgating:aNotificarTailgating <--aNotificarTailgating—DO
NOT REMOVE THIS
(5) System.out.println("aNotificarTailgating");
(6) trazas.aceptaNuevaTraza(new InfoTraza(this.nombreAgente,"NOTIFICAR DETECCION
TAILGATING A CENTRALITA",InfoTraza.NivelTraza.debug));
(7) //RecursoCentralita
(8) try {
(9) r_RecursoCentralita = (ItfUsoRecursoacCentralita)
itfUsoRepositorio.obtenerInterfaz(NombresPredefinidos.ITF_USO +
"RecursoacCentralita1");
(10) } catch (Exception e) {
(11) // TODO Auto-generated catch block
(12) e.printStackTrace();
(13) }
(14) r_RecursoCentralita.aMostrarTexto(this.nombreAgenteCorto+": Tailgating
detectado");
(15) r_RecursoCentralita.aNotificarTailgating(id);
(16) //#end_nodeaNotificarTailgating:aNotificarTailgating <--aNotificarTailgating-- DO
NOT
REMOVE THIS
(17) }
Figura 4.7. Implementación final de la acción semántica aNotificarTailgating
De la misma manera que los agentes disponen de un método por cada tarea o acción
semántica que pueden ejecutar, los recursos disponen de métodos por cada acción que
pueden realizar. Así pues, se ha generado automáticamente un esqueleto de código para
cada recurso de la aplicación al que posteriormente se ha añadido el código necesario para
llevar a cabo cada una de sus acciones. En figura 4.8 se muestra un fragmento del
contenido del fichero ClaseGeneradoraRecursoacSensorInfrarrojo.java, concretamente el
método cortarInfrarrojo que implementa la acción que permite simular el corte que se
produce en el rayo del sensor infrarrojo cuando una persona atraviesa la puerta de un
módulo. Esta acción se produce cuando el usuario de la aplicación desea que una persona
atraviese la puerta de forma intencionada para provocar cambios en el sistema que lleven a
la detección de situaciones, tanto habituales como anómalas. La forma de implementar esta
acción es enviando el evento pInfrarrojoCortado al agente agSensorInfrarrojo para que
actúe conforme a la definición de su autómata y detecte este hecho. Examinando el código
de la figura 4.8 se puede observar cómo se recupera la referencia a la interfaz de uso del
agente agSensorInfrarrojo por medio de la ClaseGeneradoraRepositorioInterfaces y se
asigna a la variable itfUsoAgente (línea 6). Seguidamente se crea un nuevo evento recurso-
agente EventoRecAgte de tipo pInfrarrojoCortado que contiene el identificador del propio
recurso como origen y el identificador del agente agSensorInfrarrojo como destinatario (en
83
la línea 7 aparece esta información como primer, segundo y tercer argumento,
respectivamente). Finalmente, se envía el evento (línea 8) ejecutando el método
aceptaEvento() de la interfaz recuperada (línea 6), pasándole como argumento el evento
recién creado.
(1) /#start_nodelocalMethods:localMethods <--localMethods-- DO NOT REMOVE THIS
(2) public void cortarInfrarrojo(){
(3) //se le envia al agente agTailgating la percepcion pInfrarrojoCortado
(4) trazas.aceptaNuevaTraza(new InfoTraza(this.getId(),"COMUNICAR PINFRARROJOCORTADO
AAGTAILGATING",InfoTraza.NivelTraza.debug));
(5) try {
(6) ItfUsoAgenteReactivo itfUsoAgente =
(ItfUsoAgenteReactivo)ClaseGeneradoraRepositorioInterfaces
.instance().obtenerInterfaz(NombresPredefinidos.ITF_USO+NombresPredef
inidos.NOMBRE_AGENTE_APLICACION+"agSensorInfrarrojoReactivo"+id);
(7) EventoRecAgte ev = new EventoRecAgte("pInfrarrojoCortado", this.getId(),
NombresPredefinidos.NOMBRE_AGENTE_APLICACION+"agSensorInfrarrojoReact
ivo"+id);
(8) itfUsoAgente.aceptaEvento(ev);
(9) } catch (Exception e1) {
(10) // TODO Auto-generated catch block
(11) e1.printStackTrace();
(12) }
(13) }
Figura 4.8. Método cortarInfrarrojo del recurso acSensorInfrarrojo
Un agente se comunica con otro agente por medio de mensajes, los cuales se traducen
en el código de la aplicación como eventos. Las percepciones también se traducen a
eventos en el código de la implementación. Por lo tanto, la manera en que se envían
eventos entre agentes es similar a la manera en que se envían los eventos de un recurso a
un agente. En figura 4.9 se muestra un fragmento de código de la acción semántica
ComunicarInfrarrojoCortado. Esta acción se encuentra implementada en el fichero
AccionesSemanticasAgenteAplicacionagSensorInfrarrojo.java. El método relativo a dicha
acción semántica es utilizado por el agente agSensorInfrarrojo para comunicar al agente
agTailgating la detección del corte del infrarrojo al recibir el evento pInfrarrojoCortado.
Para ello, el agente agSensorInfrarrojo debe recuperar la referencia al interfaz de uso del
agente agTailgating al que va destinado el evento (línea 4). A continuación crea el evento
SensorInfrarrojoATailgatingInfrarrojoCortado cuyo origen y destino son el agente
agSensorInfrarrojo y el agente agTailgating, respectivamente (línea 5). Por último, se
envía el evento creado al agente agTailgating (línea 6).
84
(1) //se le comunica al agente agTailgating que se ha cortado el sensor infrarrojo
(2) ItfUsoRepositorioInterfaces itfUsoRepositorioInterfaces =
ClaseGeneradoraRepositorioInterfaces.instance();
(3) try {
(4) ItfUsoAgenteReactivo itfUsoAgente = (ItfUsoAgenteReactivo)
itfUsoRepositorioInterfaces.obtenerInterfaz(NombresPredefinidos.ITF_USO +
NombresPredefinidos.NOMBRE_AGENTE_APLICACION + "agTailgatingReactivo"+id)
(5) EventoRecAgte ev = new
EventoRecAgte("SensorInfrarrojoATailgatingInfrarrojoCortado",
this.getNombreAgente(),NombresPredefinidos.NOMBRE_AGENTE_APLICACION+
"agTailgatingReactivo"+id);
(6) itfUsoAgente.aceptaEvento(ev);
(7) } catch (Exception ex){
(9) ex.printStackTrace();
(10) }
Figura 4.9. Fragmento de la acción semántica ComunicarInfrarrojoCortado del agente
agSensorInfrarrojo
Para que el usuario pueda interaccionar con el sistema y el vigilante de seguridad pueda
visualizar cómodamente las situaciones detectadas ha sido necesario implementar una
interfaz gráfica para cada recurso de la aplicación. Por tanto, se han creado interfaces
gráficas para los recursos acCentralita, acLector, acSensorInfrarrojo y acSensorContacto.
La parte visual de las interfaces y las cabeceras de los métodos que responden a la
interacción con el usuario se han implementado con la herramienta NetBeans que
simplifica la creación de interfaces gráficas, aunque también podría haberse utilizado
indistintamente por ejemplo Eclipse o JBuilder. Las clases obtenidas han sido
InterfazCentralita, InterfazLector, InterfazSensorInfrarrojo, InterfazSensorContacto. Éstas
se han integrado en ICARO-T dentro del mismo paquete que la clase generadora que
corresponde a cada interfaz (véase figura 4.10 para el caso concreto del recurso
acSensorInfrarrojo). Posteriormente se han hecho modificaciones en las clases
generadoras, añadiendo los import correspondientes y modificando los constructores para
crear un objeto que hace referencia a una instancia del interfaz gráfico. Es preciso resaltar
que cuando se crea la instancia de un interfaz se le pasa como parámetro una referencia de
la instancia de la clase generadora del recurso, de forma que el objeto de tipo interfaz tiene
acceso a la clase generadora que lo creo. El diagrama de clases relacionadas con el recurso
acSensorInfrarrojo se muestra en la figura 4.11.
Figura 4.10. Paquete del recurso acSensorInfrarrojo
85
class recursoacSensorInfrarojo
javax.swing.JFrame
imp::InterfazSensorInfrarojo
- idRecurso: ClaseGeneradoraRecursoacSensorInfrarojo
- jBotonAtravesarPuerta: JButton
- jLedInfrarojo: JProgressBar
- numId: int
+ activarInterfaz() : void
+ desactivarInterfaz() : void
- initComponents() : void
+ InterfazSensorInfrarojo() : void
+ InterfazSensorInfrarojo(ClaseGeneradoraRecursoacSensorInfrarojo) : void
- jBotonAtravesarPuertaActionPerformed(ActionEvent) : void
+ ledInfrarojoCortado() : void
+ ledInfrarojoLibre() : void
+ main(String[]) : void
ImplRecursoSimple
imp::ClaseGeneradoraRecursoacSensorInfrarojo
- id: String
- idRecurso: String
- trazas: ItfUsoRecursoTrazas
- ventanaSInfrarojo: InterfazSensorInfrarojo
+ activarInferfaz() : void
+ aLedInfrarojoCortado() : void
+ aLedInfrarojoLibre() : void
+ ClaseGeneradoraRecursoacSensorInfrarojo(String) : void
+ cortarInfrarojo() : void
+ dameId() : String
+ desactivarInferfaz() : void
+ termina() : void
java.lang.Object
«interface»
ItfUsoRecursoacSensorInfrarojo
+ activarInterfaz() : void
+ aIluminarLedInfrarrojoCortado() : void
+ aIluminarLedInfrarrojoLibre() : void
+ cortarInfrarrojo() : void
+ dameId() : String
+ desactivarInterfaz() : void
-idRecurso-ventanaSensorInfrarojo
Figura 4.11. Diagrama de clases relacionadas con el recurso acSensorInfrarrojo
Tal y como se ha mencionado anteriormente, se han creado interfaces gráficos para los
recursos acCentralita, acLector, acSensorInfrarrojo y acSensorContacto, para permitir
que el usuario interactúe con la aplicación con dos papeles distintos: (1) el de una persona
que entra en el recinto y puede realizar actos no permitidos; y (2) el de un vigilante de
seguridad que supervisa el proceso de entrada y salida de usuarios en/del recinto. El
interfaz InterfazCentralita consiste en una ventana dividida en cinco secciones, cada una
de las cuales está dedicada a un módulo de entrada o salida (véase figura 4.12). Cada
sección muestra, para el módulo al que está dedicada, el número de tickets leídos, el
número de usuarios que han atravesado la puerta, la validez del ticket introducido y el
estado de la puerta. Además incluye un botón para deshabilitar la puerta del módulo. Por
otro lado, la ventana muestra el número total de tickets leídos y el número de personas que
se encuentran dentro del recinto e incluye, en la parte inferior, un cuadro de texto donde se
va mostrando todo lo que sucede en el sistema. El interfaz InterfazLector (véase figura
4.13) muestra todo lo necesario para interactuar con el lector de tickets: un cuadro de texto
en el que se puede escribir el número de ticket que se quiere introducir, un botón que
simula la introducción del ticket en el lector (tomando como valor el número de ticket
escrito en el cuadro de texto) y un recuadro que cambia de color cuando el ticket es válido
y que hace el papel de led. El interfaz InterfazSensorInfrarrojo (véase figura 4.14) muestra
86
en primer lugar un recuadro que cambia de color cuando una persona atraviesa la puerta,
simulando el corte del rayo infrarrojo, y un botón que permite cortar el rayo a petición del
usuario. Destacar que este botón únicamente se activa cuando la puerta del módulo se
encuentra abierta, momento en el que un usuario la puede atravesar. El interfaz
InterfazSensorContacto (véase figura 4.15) muestra en todo momento el estado de la
puerta del módulo por medio de un recuadro que cambia de color según su estado y que
hace el papel de led. Además, muestra el estado del bloqueo de la puerta mediante otro
recuadro relacionado con el botón de bloqueo que permite bloquear o desbloquear la puerta
por parte de un usuario. Este bloqueo, al igual que sucede con el corte del rayo infrarrojo,
sólo puede realizarse cuando la puerta está abierta, pues en otro caso el botón aparece
deshabilitado.
Comentar que el número que aparece en la barra de título de los interfaces gráficos
asociados a los dispositivos nos permite conocer en qué módulo está instalado.
Figura 4.12. Ventana de la clase InterfazCentralita
Figura 4.13. Ventana de la clase InterfazLector
87
Figura 4.14. Ventana de la clase InterfazSensorInfrarrojo
Figura 4.15. Ventana de la clase InterfazSensorContacto
Finalmente, comentar que para lanzar el despliegue de la aplicación se deben ejecutar
los script que se encuentran en la carpeta /ICAROTCode/bin/ del proyecto. El primero de
ellos, Fija entorno.bat, establece las rutas necesarias para el IDK de INGENIAS, ANT y
JDK; y el segundo, Despliegue.bat, lanza la aplicación mediante el comando “ant -
buildfile=../build.xml run -DrutaDescripcion=DespliegueDNS5modulos”, siendo
DespliegueDNS5modulos el nombre del fichero XML que describe el despliegue de la
organización recién lanzada. Como resultado se lanza el Recurso de trazas de ICARO-T
(véase figura 4.16) que permite acceder a las trazas de cada uno de los elementos que
componen la aplicación. El aspecto de la aplicación recién iniciada se puede ver en la
figura 4.17.
Figura 4.16. Recurso de trazas de ICARO-T
88
Figura 4.17. Aspecto de la aplicación tras su lanzamiento
4.2. Mejora de la aplicación
La introducción de tickets de forma manual por parte del usuario resulta una tarea
bastante ardua porque el usuario de la aplicación debe teclear los números de ticket y
pulsar los botones correspondientes para simular la entrada/salida de usuarios en/del
recinto. Este procedimiento impide una interacción ágil con la aplicación para simular el
bloqueo de puertas y la introducción de personas no autorizadas, así como la supervisión
de toda la simulación a través de la centralita. Ha resultado interesante mejorar la
aplicación haciendo la introducción de tickets en el sistema una tarea automática,
89
permitiendo así una interacción más cómoda con la aplicación. Este procedimiento
automático se basa en la introducción de un reloj en la aplicación que va contabilizando el
tiempo y que va enviando eventos a los recursos lectores pertinentes para que estos
reaccionen como si el usuario hubiera introducido un número de ticket.
Para llevar a cabo esta mejora ha sido necesario utilizar la herramienta de actualización
de código ICAROTcodeUploader que se incluye en el IDK de INGENIAS. Esta
funcionalidad permite actualizar el diseño de la aplicación durante el proceso de
implementación en java, de tal manera que el código introducido manualmente se salva
para evitar que pueda sobrescribirse. Una vez actualizado el diseño, añade el código
generado automáticamente a partir de los cambios realizados en el diseño junto con el
código salvado. Por lo tanto, una vez salvado el código implementado de forma manual, se
ha procedido a introducir una nueva aplicación en el diseño denominada Reloj. Esta
aplicación ha producido cambios en el diseño detallado de la aplicación, los cuales se
explican a continuación.
En primer lugar, se han introducido los métodos necesarios para que la aplicación Reloj
pueda desempeñar funciones de control de instantes de tiempo (tabla 4.1). Además se ha
dotado a la aplicación acLector de nuevos métodos para permitir la introducción de tickets
de forma automática al recibir instantes de tiempo por parte del Reloj (tabla 4.2). A
continuación se han añadido las relaciones pertinentes en el diagrama de entorno, el cual
muestra el envío de eventos al agente agLector mediante la relación EPercibes y el manejo
de métodos de aplicación por parte del agente a través de la relación AplicationBelongsTo
(véase figura 4.18).
Tabla 4.1. Aplicación Reloj
Prometheus INGENIAS
Entidad Tipo Entidad Tipo Descripción
- - iniciarSimulacion ME Lanza en el sistema la simulación programada.
- - continuarSimulacion ME Comunica a cada lector el instante de reloj
actual.
- - nuevoInstante ME
Comunica al reloj la disponibilidad por parte de
un lector para la recepción de un nuevo instante
de reloj.
- - incrementarInstante ME Incrementa un instante de reloj.
- - dameInstante ME Devuelve el instante de reloj actual.
- - Pausar ME Detiene el avance de reloj.
- - Reanudar ME Reanuda el avance de reloj.
- - estaEnPausa ME Devuelve cierto cuando el reloj esta pausado.
- - Disponibles ME
Devuelve cierto cuando todos los lectores están
disponibles para recibir un nuevo instante de
reloj.
- - obtenerVaribleSimulando ME Devuelve cierto cuando el recurso se encuentra
en medio de una simulación.
- - obtenerVariableInstante ME Devuelve el instante en que se encuentra el reloj.
90
Tabla 4.2. Métodos añadidos a la aplicación acLector
Prometheus INGENIAS
Entidad Tipo Entidad Tipo Descripción
- - insertarTicketAuto ME Durante la simulación, dispara la percepción
pTicketLeido.
- - nuevoInstanteRecibido ME Durante la simulación, provoca la búsqueda de un
ticket asociado a un instante concreto de tiempo.
Figura 4.18. Fragmento del diagrama de entorno
En segundo lugar, se han identificado las acciones semánticas del agente agLector
ejecutadas como respuesta a los nuevos eventos (nuevoInstante) que puede recibir del
recurso Reloj. Según el caso, el agente puede recibir un número de ticket para cierto
instante si así ha sido programado, recibiendo el evento nuevoInstante al que reacciona
mediante la acción semántica NuevoInstanteRecibido que incluye acciones destinadas a
buscar el ticket correspondiente al instante recibido, si lo hubiera. Si para un instante dado
no se ha programado la introducción de un ticket, el lector recibirá el evento noTicket, al
que reaccionará con la acción semántica InstanteSinTicket (véase tabla 4.3).
91
Tabla 4.3. Acciones semánticas añadidas al agente agLector
INGENIAS
Entidad Tipo Acción Semántica Descripción
nuevoInstante AES NuevoInstanteRecibido
Durante una simulación, provoca la
ejecución del método
nuevoInstanteRecibido del recurso
acLector que se encarga de buscar un
ticket asociado al instante recibido.
noTicket AE InstanteSinTicket Durante una simulación, no introduce
ningún ticket.
El último paso en la revisión del diseño detallado ha consistido en modificar el
autómata del agente agLector para incluir las nuevas acciones semánticas que puede
ejecutar. La tabla 4.4 muestra los nuevos eventos recibidos por el agente mientras que las
figuras 4.19.a y 4.19.b muestran el autómata del agente con la notación empleada en
INGENIAS y UML, respectivamente.
Tabla 4.4. Eventos recibidos por el agente agLector
Prometheus INGENIAS
Entidad Tipo Entidad Tipo Contenido Emisor
- - nuevoInstante AES Instante Integer Reloj
- - noTicket AE - acLector
Figura 4.19.a. Automáta del agente agLector en INGENIAS
92
stm agLector
EstadoInicial
EstadoFinal
EsperarActiv acion
EsperarTicket
EsperarComprobacionTicket
Transición universal: (Sx, EstadoFinal): finalizar / nula
Sx es cualquier estado del autómata
[usuarioAutorizado /
Autorizado]
[usuarioNoAutorizado /
NoAutorizado]
[SensorContactoALectorDesactivar
/ desactivar]
[noTicket /
InstanteSinTicket]
[nuevoInstante /
NuevoInstanteRecibido]
[SensorContactoALectorDesactivar
/ desactivar]
[pTicketLeido /
ComprobarTicket]
[SensorContactoALectorActivar
/ activar]
[comenzar / nula]
Figura 4.19.b. Automáta del agente agLector
Una vez rediseñada la aplicación en INGENIAS se ha vuelto a generar el código,
obteniendo el esqueleto de la implementación para el nuevo recurso y el código generado
inicialmente junto con todo el desarrollado realizado previamente de forma manual. De la
misma manera que se ha hecho en la primera etapa de implementación se han completado
los métodos del recurso Reloj partiendo del esqueleto generado automáticamente.
Debido a que el nuevo recurso Reloj envía instantes de tiempo a los recursos lectores,
estos deben conocer si existe un ticket para ellos asociado a cada instante de tiempo, por lo
que ha sido necesario crear un fichero XML denominado entradalectores.xml que contiene
los lectores que poseen un ticket asociado en cada instante de tiempo y el número de cada
ticket (véase líneas 1 y 2 de figura 4.20). Por lo tanto, una instancia del agente agLector
ejecutará dentro de la tarea NuevoInstanteRecibido una acción destinada a la búsqueda, en
el fichero entradalectores.xml, del instante recibido, su número de lector y el número de
ticket correspondiente. Esta acción se ejecuta en el método nuevoInstanteRecibido() del
93
recurso acLector, el cual se encarga de realizar la búsqueda en el fichero XML. Una vez
finalizada la búsqueda y, en caso de que no haya encontrado un ticket para el instante
recibido, enviará un evento noTicket a la instancia correspondiente del agente agLector. En
caso contrario, ejecutará el método insertarTicketAuto(), que equivale a la inserción
manual de un ticket por parte de un usuario del sistema.
(1) <LECTURA instante = "1">
(2) <Lector id = "1" ticket = "8"></Lector>
(3) <Lector id = "3" ticket = "8"></Lector> (4) </LECTURA>
(5) <LECTURA instante = "2">
(6) <Lector id = "2" ticket = "4"></Lector> (7) <Lector id = "3" ticket = "6"></Lector>
(8) <Lector id = "5" ticket = "2"></Lector>
(9) </LECTURA> (10) <LECTURA instante = "3">
(11) <Lector id = "2" ticket = "1"></Lector>
(12) </LECTURA> (13) <LECTURA instante = "5">
(14) <Lector id = "1" ticket = "3"></Lector>
(15) <Lector id = "2" ticket = "7"></Lector> (16) <Lector id = "3" ticket = "6"></Lector>
(17) </LECTURA>
Figura 4.20. Fragmento del fichero entradaLectores.xml
Por último, se ha creado un interfaz gráfico para iniciar la simulación mediante el clic
sobre un botón, además de indicar el instante de tiempo en el que se encuentra el reloj en
cada momento (véase figura 4.21). Nótese que el diseño de la interfaz y la integración con
ICARO-T se han realizado siguiendo el mismo procedimiento que anteriormente se ha
descrito. Evidentemente, también ha sido necesario dar de alta el recurso Reloj en el
fichero de despliegue de la aplicación.
Figura 4.21. Interfaz de la aplicación Reloj
94
4.3. Pruebas
Las pruebas de la aplicación han estado presentes desde los primeros pasos de la
implementación. Por una parte, se han efectuado pruebas de complejidad creciente para
asegurar el funcionamiento correcto de cada módulo desarrollado, además de comprobar la
correcta coordinación e interacción entre módulos. Por otra parte, se han realizado pruebas
para comprobar que se alcanzan los objetivos globales del sistema, además de los objetivos
propios de cada agente. Los errores más comunes detectados durante la realización de las
pruebas se muestran a continuación:
- Un agente no recibe un evento enviado por otro agente o un recurso.
- Un recurso no efectúa la acción ordenada por un agente.
- Un evento no se produce.
- Un evento se produce demasiado pronto o llega tarde a su receptor.
- La interfaz gráfica no se muestra como es debido.
- Errores de coordinación del reloj.
Como puede apreciarse, los principales errores tienen que ver con el uso incorrecto de
la infraestructura ICARO-T, errores de relevancia leve que se han solucionado
modificando el código tras revisar el manual correspondiente y algunos ejemplos de uso.
Otros errores, como los de coordinación, se han producido como consecuencia de la
ejecución paralela de múltiples hilos. Se debe decir que el uso de ICARO-T, junto con una
metodología sólida y efectiva como es VigilAgent, han simplificado enormemente la fase
de desarrollo de código, ya que ésta se reduce a la codificación manual de la comunicación
entre agentes, el desarrollo de interfaces gráficos y el acceso a bases de datos.
95
5. CONCLUSIONES Y TRABAJOS FUTUROS
Antes de comenzar a describir las conclusiones obtenidas tras finalizar este proyecto,
resulta oportuno comentar las medidas obtenidas referentes al tiempo de desarrollo.
5.1. Métricas
Durante la realización del proyecto se ha ido documentando el tiempo invertido en cada
una de las fases del desarrollo con el fin de obtener conclusiones acerca del desarrollo de
SMA mediante la metodología VigilAgent. Resulta de gran importancia conocer el coste
de cada una de las actividades realizadas para saber qué punto del desarrollo nos ofrece
ventajas y dónde se deben centrar los esfuerzos para reducir los costes en futuros
proyectos. En la figura 5.1 se muestra, en orden horario, el tiempo empleado para cada fase
del proyecto, siguiendo la leyenda adjunta, cuyos ítems se explican a continuación.
- Investigación en SMA: estudio e investigación del estado del arte en SMA, así
como de las metodologías existentes para el desarrollo de SMA, en especial las
metodologías Prometheus, INGENIAS y VigilAgent.
- Investigación en ICARO-T: estudio e investigación de la infraestructura
ICARO-T.
- Investigación en entrada/salida: investigación de sistemas automáticos de
entrada/salida de humanos, así como sensores y redes de sensores.
- Especificación del sistema: primera fase de desarrollo del sistema siguiendo la
metodología VigilAgent.
- Diseño arquitectónico: segunda fase de desarrollo del sistema siguiendo la
metodología VigilAgent.
- Diseño detallado: tercera fase de desarrollo del sistema siguiendo la metodología
VigilAgent.
- Implementación: cuarta fase de desarrollo del sistema siguiendo la metodología
VigilAgent.
- Base de datos: creación de la base de datos de usuarios para el acceso y
modificación por parte de la aplicación en desarrollo.
- Despliegue: quinta y última fase de desarrollo del sistema siguiendo la metodología
VigilAgent.
- Pruebas: realización de pruebas de la aplicación.
- Documentación: generación de la presente memoria del proyecto.
96
8%
7%
3%
9%
13%
12%
23%
1%
1%
3%
20%
Investigación en SMA
Investigación en ICARO-T
Investigación en entrada/salida
Especificación del sistema
Diseño arquitectónico
Diseño detallado
Implementación
Base de datos
Despliegue
Pruebas
Documentación
Figura 5.1. Tiempo de desarrollo del proyecto por fases
El tiempo total empleado en el proyecto se estima en 384 horas, las cuales se han
repartido en el desarrollo de cada una de sus fases. Se ha invertido un 18% del tiempo en
investigación y estudio (investigación en SMA, investigación en ICARO-T e investigación
en entrada/salida). Durante estas fases se ha han estudiado los fundamentos de los SMA,
las metodologías Prometheus, INGENIAS y VigilAgent, además de la infraestructura
ICARO-T. También se ha investigado en materia de sistemas de control de entrada/salida y
tipos de sensores utilizados en dicho ámbito. Se puede considerar que el tiempo invertido
en investigación en SMA, así como el aprendizaje de la metodología VigilAgent, es algo
elevado, sin embargo, esta inversión se compensa enormemente en tiempo de
implementación, como se comenta más adelante.
Tras finalizar la fase de investigación se ha empleado un 34% del tiempo en la
especificación y diseño de la aplicación (especificación del sistema, diseño arquitectónico
y diseño detallado). Durante estas fases se han seguido los pasos y recomendaciones que
hace VigilAgent, facilitando considerablemente la identificación de entidades y la creación
de relaciones.
La fase de implementación ha necesitado solamente un 23% del tiempo total de
desarrollo. Esto se debe a que la generación automática de código permite obtener el
código de la infraestructura a partir del diseño obtenido en las tres primeras fases de la
metodología. De esta manera, la fase de implementación se reduce a completar los
métodos para los que se han creado automáticamente las cabeceras, crear los interfaces
gráficos y establecer el acceso a bases de datos. ICARO-T ofrece al desarrollador un
sistema de intercomunicación entre entidades, gestión automática para la creación de
agentes y recursos, control de eventos y coordinación entre entidades, reduciendo el
tiempo de implementación considerablemente.
97
En el gráfico, también se puede observar que la base de datos ha supuesto un 1% del
coste en tiempo. Esto es debido a su sencillez, de la misma manera que la configuración
del despliegue sólo ha necesitado de otro 1%, empleado en la realización de algunos
ajustes en el código generado automáticamente. Las pruebas, realizadas a medida que se
iba completando el código, han supuesto un coste del 3% del tiempo total. Por último, ha
sido necesario invertir un 20% en la realización de la presente memoria de proyecto.
En figura 5.2 se muestra el tiempo requerido para implementar cada uno de los
módulos que componen el sistema. Cada módulo se considera como el conjunto que
forman la suma de sus partes (por ejemplo, el módulo Lector está formado por el agente
agLector, el recurso asociado al agente acLector y la interfaz gráfica del lector
InterfazLector). Se puede observar que el módulo Contacto ha requerido mucho más
tiempo que otros módulos (35% del total). Esto se debe a que dicho módulo participa en
todos los procesos de funcionamiento del sistema, siendo más complejo que el resto de
módulos. Sin embargo, el módulo Puerta ha necesitado tan sólo un 5% debido a un
comportamiento mucho más básico y a la falta de una interfaz gráfica. El módulo Reloj por
su parte, ha necesitado un 21% del tiempo ya que ha sido necesario integrarlo con el
módulo Lector.
Por último, se debe comentar que habiendo trabajado en un inicio de este proyecto con
Prometheus y JACK, el uso de VigilAgent ha significado una efectiva reducción del
tiempo de trabajo. Se puede afirmar que la implementación mediante la generación
automática de código para ICARO-T resulta más sencilla que mediante JACK, por lo que
la etapa de aprendizaje se hace más corta, se reduce el tiempo de implementación y se
invierte menos tiempo en la resolución de errores.
18%
5%
11%
35%
10%
21%
Módulo Lector
Módulo Puerta
Módulo Infrarrojo
Módulo Contacto
Módulo Centralita
Módulo Reloj
Figura 5.2. Tiempo dedicado a la implementación de cada módulo
98
5.2. Conclusiones
Como resultado de este trabajo se ha diseñado y desarrollado un sistema software
basado en organizaciones de agentes que permite simular el funcionamiento de un sistema
inteligente de control para la entrada/salida de humanos a/de un recinto cerrado. Para
obtener este sistema se ha utilizado la metodología VigilAgent, especifica para el
desarrollo se SMA orientados a la vigilancia. Esta metodología integra, como se ha
explicado a lo largo de la presente memoria, las metodologías Prometheus e INGENIAS en
las etapas de diseño, realizando finalmente la implementación del software sobre la
plataforma ICARO-T. Este método de trabajo ha proporcionado consistencia desde la
captura de requisitos a la etapa de diseño detallado, que se efectúan siguiendo las
recomendaciones proporcionadas por la metodología. De la misma manera, la utilización
de la infraestructura ICARO-T ha proporcionado robustez arquitectónica como base para la
obtención del producto final. Además, esta infraestructura ha permitido centrar los
esfuerzos en el desarrollo de las funcionalidades deseadas para el sistema, evitando el gasto
que conlleva implementar los mecanismos propios de una organización de agentes (por
ejemplo, la gestión para la creación de agentes y recursos y el subsistema de comunicación
entre entidades). Se ha podido comprobar una gran flexibilidad de trabajo, permitiendo
incluso dar marcha atrás en la etapa de implementación, regresando al diseño detallado sin
perder el código ya desarrollado.
Este trabajo se ha realizado para satisfacer los objetivos descritos en el capítulo uno,
por lo que resulta interesante comentar en qué grado se han satisfecho dichos objetivos a la
finalización del proyecto.
Estudio de los Sistemas Multi-Agente. Se ha investigado qué es un agente, en qué
consiste un SMA y qué aplicaciones tiene, tratando de confirmar la viabilidad para
el desarrollo de sistemas de control y vigilancia. Además, la labor de investigación
ha permitido establecer una base para continuar con el estudio de metodologías de
desarrollo de SMA.
Conocimiento de la Ingeniería del Software Orientada a Agentes (AOSE). Se
han estudiado diferentes metodologías para el desarrollo de SMA centrando los
esfuerzos en Prometheus e INGENIAS, bases de la metodología VigilAgent.
Estudio de sistemas de control para la entrada y salida. Se ha investigado sobre
el estado del arte en sistemas de control de entrada/salida de humanos para adquirir
los conocimientos necesarios para el desarrollo de este proyecto.
Investigación en sensores aplicados a la vigilancia y control automáticos. Se ha
indagado en los tipos de sensores más utilizados en los sistemas de vigilancia y
99
control automáticos, proporcionando la idea de utilizar sensores de infrarrojo para
la detección de personas y sensores de contacto para las puertas.
Prevención de situaciones anómalas en el funcionamiento del sistema. A partir
de los conocimientos adquiridos se han abordado un conjunto de situaciones
anómalas que pueden producirse en un sistema de control de entrada/salida de
humanos. Concretamente se han tratado el caso de tailgating y el bloqueo de
puertas.
Toma de decisiones y previsión de sus efectos durante las fases de diseño de
software. Realizar minuciosamente el diseño de la aplicación ha resultado de suma
importancia para evitar problemas en la fase de implementación.
Integración de las metodologías Prometheus e INGENIAS para el diseño de
software orientado a agentes. Se ha seguido el procedimiento propuesto en
VigilAgent para la integración de las metodologías Prometheus e INGENIAS. De
esta manera se ha podido obtener un modelo en INGENIAS equivalente al obtenido
inicialmente en Prometheus.
Conocimiento de la plataforma ICARO-T. Los conocimientos adquiridos sobre
ICARO-T han permitido realizar el despliegue del sistema con éxito, así como
aprovechar las ventajas que ofrece relativas a la organización de agentes.
Procesos de intercomunicación entre agentes. ICARO-T ha evitado tener que
implementar manualmente un subsistema de intercomunicación entre entidades.
Además, ha permitido poner en práctica los procesos de intercomunicación entre
agentes tal y cómo se han definido en el diseño.
Implementación del software siguiendo los modelos definidos en el diseño. Se
ha conseguido desarrollar un sistema acorde con los modelos especificados desde
las primeras etapas del diseño y que proporciona trazabilidad desde la primera fase
del proceso de desarrollo.
Adición de un nuevo módulo al sistema software terminado. Una vez
completado el sistema se ha vuelto a la etapa de diseño para incorporar la
identificación de usuarios de forma automática. Gracias a la flexibilidad que ofrece
VigilAgent en este aspecto no se han producido efectos negativos en el sistema. El
nuevo módulo ha dotado al sistema de mayor libertad a la hora de controlar la
simulación sin crear conflictos con las especificaciones de diseño originales.
Documentación del proceso de desarrollo de software. El resultado final ha sido
la presente memoria del proyecto.
100
A la vista del grado de satisfacción alcanzado en este proyecto, y tras haber
comprobado la viabilidad y ventajas de VigilAgent para el desarrollo de sistemas de
vigilancia basados en organizaciones de agentes, se puede augurar un alto grado de éxito
en futuros desarrollos basados en esta metodología.
5.3. Trabajos futuros
El sistema desarrollado puede admitir algunas ampliaciones y modificaciones con el fin
de mejorar su funcionamiento, y por lo tanto, utilidad a la hora de proporcionar resultados
basados en las simulaciones efectuadas. Gracias a la utilización de la metodología
VigilAgent se garantiza la posibilidad de efectuar modificaciones y extender la
funcionalidad de una aplicación basada en agentes. A continuación se proponen algunas
mejoras para el sistema.
Una primera mejora podría consistir en poder definir el despliegue dinámicamente, de
forma que el usuario pudiera definir el número de módulos de entrada o salida al lanzar la
aplicación. Esta mejora conllevaría la adaptación de los interfaces gráficos en tiempo de
ejecución, mostrando en centralita únicamente los módulos definidos, así como las
ventanas asociadas a los sensores.
Otra mejora podría ser la detección de nuevas situaciones anómalas, como por ejemplo,
la detección de piggy-backing. Esta situación se da cuando un usuario autorizado introduce
su identificación para que una tercera persona entre o salga del recinto. Un caso concreto
de piggy-backing podría ser aquel en el que un usuario autorizado se identifica desde el
interior del recinto para que otra persona no autorizada pase a través del módulo desde el
exterior. Este caso necesitaría que los módulos permitieran la entrada y la salida a la vez,
característica que también sería interesante contemplar como mejora.
También resultaría interesante incluir en la interfaz del módulo Centralita un mapa
para mostrar gráficamente los módulos de entrada y salida, así como su distribución en el
recinto, indicando el estado de las puertas y las situaciones anómalas detectadas. Esta
mejora haría más fácil la visualización de toda la simulación.
Una última mejora podría consistir en la provocación automática de situaciones
anómalas, ampliando la mejora descrita en el apartado 4.2.
101
6. ANEXO: CONFIGURACIÓN Y USO
6.1. Configuración de la aplicación
Para el funcionamiento correcto de la aplicación es necesario instalar el software
proporcionado junto a la presente memoria y realizar una serie de configuraciones en el
equipo, tal y como se detalla a continuación.
Software proporcionado:
Aplicación ICARO-T (ControlES.rar)
Apache Ant 1.7.1 (apache-ant-1.7.1-bin.rar)
Jdk 1.6.16 (jdk-6u16-windows-i586)
Pasos para instalar, configurar y ejecutar el software:
1. Descomprimir el archivo de la aplicación en el directorio deseado (Ej. C:\ControlES)
2. Descomprimir la herramienta Apache Ant en el directorio deseado (Ej. C:\apache-ant-
1.7.0).
3. Instalar la herramiento Jdk en el directorio deseado (Ej. C:\jdk1.6.0_16).
La estructura de directorios propuesta se muestra en la figura 6.1.
4. Crear un DNS de sistema con los valores que se encuentran en el archivo
“DespliegueDNS5modulos.xml” del directorio de la aplicación
“…\ControlES\ICAROTCode\config\icaro\aplicaciones\descripcionOrganizaciones”.
Este paso se debe realizar de la siguiente manera (partiendo de un sistema operativo
Windows XP o Vista):
1.1. Acceder a Panel de control Herramientas administrativas Origenes de datos
(ODBC).
1.2. Crear un DNS de sistema de nombre “TablaTickets”.
1.3. Configurar la ruta de acceso a la BDD como “…\ControlES\BDTickets.mdb”.
1.4. Configurar las opciones avanzadas con el nombre de inicio de sesión “usuario1” y
la contraseña “contraseña1”.
5. Acceder al directorio “…\ControlES\ICAROTCode\bin” y editar el archivo “Despliegue
5 modulos.bat” ajustando las rutas conforme a la instalación realizada de Ant y Jdk.
102
6. Lanzar la aplicación mediante el ejecutable “Despliegue 5 modulos.bat” recién editado.
Figura 6.1. Estructura de directorios propuesta
6.2. Uso de la aplicación
Una vez lanzada la aplicación aparece en primer lugar el recurso de trazas,
posteriormente las ventanas correspondientes a cada uno de los módulos y finalmente la
ventana correspondiente a la centralita. Se debe esperar a que la ventana CENTRALITA
(véase figura 6.2) indique la configuración de cada uno de los módulos monitorizados, de
modo que sean conocidos los que permiten la entrada de usuarios al recinto y los que
permiten la salida. A partir del instante en el que la ventana de centralita describe
textualmente que las cinco puertas se encuentran cerradas es posible interactuar con la
aplicación. A continuación, en la figura 6.2, aparecen resaltadas en rojo las zonas de la
ventana que han sido nombradas en el texto, al igual que se hace en figuras sucesivas a lo
largo de la presente sección.
Figura 6.2. Ventana CENTRALITA
103
Para introducir un ticket en el lector L 110
de forma manual basta con escribir un
número de ticket (del uno al diez) y pulsar el botón Insertar Ticket (figura 6.3). Si el ticket
es válido se ilumina el led del lector en color verde y únicamente falta esperar a que la
puerta se encuentre abierta para provocar cualquiera de las dos acciones anómalas que
detecta el sistema.
Figura 6.3. Ventana L 1
Para bloquear la puerta basta con pulsar el botón U-Bloquear del sensor de contacto
C 1 (véase figura 6.4), provocando el bloqueo de la puerta, tal y como muestra su led
inferior, que cambia del color blanco al negro.
Figura 6.4. Ventana C 1
Tras el bloqueo es posible atravesar la puerta ilegalmente mediante el botón “Atravesar
Puerta” del sensor infrarrojo IR 1 (véase figura 6.5). El parpadeo en negro del led indica
que se ha atravesado la puerta, hecho que muestra el cuadro de texto de la centralita
(tailgating detectado). Tras esta acción es posible desbloquear la puerta o continuar
introduciendo personas en el recinto. Una vez desbloqueada la puerta y, tras unos instantes,
la puerta volverá a encontrarse cerrada permitiendo la identificación de un nuevo usuario
en dicho módulo. Se debe aclarar que también puede provocarse la situación de tailgating
10
Las ventanas correspondientes a los dispositivos que conforman un módulo de entrada o salida se
distinguen por su inicial (L para el lector, C para el contacto e IR para el infrarrojo). Esta inicial se acompaña
de un número que indica a qué módulo pertenecen (valores del uno al cinco). Así pues, el módulo uno
dispone de las ventanas L 1, C 1 e IR 1, correspondientes a los dispositivos lector, contacto e infrarrojo,
respectivamente.
104
aprovechando el instante de tiempo en que la puerta permanece abierta para dejar paso al
usuario, pero este método requiere pulsar el botón de bloqueo en el momento preciso.
Figura 6.5. Ventana IR 1
Otra manera de interactuar con la aplicación consiste en simular la entrada y salida de
usuarios mediante el botón Simular que muestra la ventana Reloj (figura 6.6). Esta opción
permite al usuario de la aplicación concentrarse en provocar situaciones anómalas.
Figura 6.6. Ventana Reloj
Por último, comentar que pueden deshabilitarse varios módulos de la aplicación
mediante los botones Bloquear puerta que posee la ventana CENTRALITA (Figura 6.7).
Esta acción solamente se puede realizar cuando el estado de la puerta es “CERRADA”.
Figura 6.7. Detalle del Modulo 1
105
7. BIBLIOGRAFÍA
- José Ignacio Armesto Quiroga. Instalación de Sistemas de Automatización y Datos.
Departamento de Ingeniería de Sistemas y Automática, Universidad de Vigo, 2007.
- Camilo Andrés Benito Rojas y Dulce María Valerón Almazán. Doctoris. Proyecto
Fin de Máster, Departamento de Sistemas Informáticos y Programación,
Universidad Complutense de Madrid, 2009.
- José María Fernández de Alba López de Pablo. Talking Agents: Arquitectura para
Sistemas de Agentes Conversacionales. Proyecto Fin de Máster, Departamento de
Sistemas Informáticos y Programación, Universidad Complutense de Madrid, 2009.
- Antonio Fernández-Caballero y José M. Gascueña. Sistemas Multi-Agente.
Transparencias de la asignatura, Departamento de Sistemas Informáticos,
Universidad de Castilla la Mancha, 2009.
- Rubén Fuentes Fernández, María Guijarro, Gonzalo Pajares. A Multi-Agent System
Architecture for Sensor Networks. Sensors, 9, 10244-10269, 2009.
- Francisco J Garijo, Felipe Polo y Damiano Spina. Manual de uso ICAROMini v1.1.
2009.
- José M. Gascueña. Modelado con INGENIAS para generar código para ICARO-T.
Transparencias, Departamento de Sistemas Informáticos, Universidad de Castilla-
La Mancha, 2009.
- José M. Gascueña. VigilAgent: Una metodología basada en agentes para el
modelado y la implementación de sistemas de vigilancia multisensoriales. Tesis
Doctoral, Departamento de Sistemas Informáticos, Universidad de Castilla-La
Mancha, 2010.
- José M. Gascueña, Antonio Fernández-Caballero, Francisco J. Garijo. Using
ICARO-T Framework for Reactive Agent-Based Mobile Robots. 8th International
Conference on Practical Applications of Agents and Multi-Agent Systems
(PAAMS’10). Advances in Intelligent and Soft Computing. Springer, pp. 91-101,
2010.
- Jorge Gómez Sanz. Modelado de Sistemas Multi-Agente. Tesis doctoral,
Departamento de Sistemas Informáticos y Programación, Universidad Complutense
de Madrid, 2002.
106
- Jorge Gómez Sanz y Juan Pavón Mestras. Desarrollo de Sistemas Multi-Agente con
INGENIAS. Transparencias, Departamento de Sistemas Informáticos y
Programación, Universidad Complutense de Madrid.
- The Kaba Group. Productos y soluciones. Web disponible en http://www.kaba.es/,
2010.
- Lin Padgham y Michael Winikoff. Developing Intelligent Agent Systems: A
Practical Guide. John Wiley and Sons, 2004.
- Ling Padgham, John Thangarajah y Paresh Paul. Prometheus Design Tool Version
2.5. User Manual. RMIT Agents Group, web disponible en:
http://www.cs.rmit.edu.au/agents/pdt/
- Álvaro Rodríguez Pérez. Asistente para la Gestión de Organizaciones de Agentes
Software. Proyecto Fin de Máster, Departamento de Sistemas Informáticos y
Programación, Universidad Complutense de Madrid, 2009.
- Meritxell Vinyals, Juan A.Rodríguez Aguilar, Jesús Cerquides. A Survey on Sensor
Networks from a Multi-Agent Perspective. The Computer Journal, Febrero de
2010.