ingeniería de software - upsin
TRANSCRIPT
UNIVERSIDAD POLITÉCNICA DE SINALOA
PROGRAMA ACADÉMICO DE INGENIERÍA EN INFORMÁTICA
Tesina
“Diseño de Agentes Inteligentes con el modelo BDI aplicando Técnicas de
Ingeniería de Software”
Para cumplir la acreditación de las estadías profesionales y contar con los créditos necesarios para obtener el grado de Ingeniero en Informática
Autor:
Garibaldi López Castro Andrea Jeannette
Asesor:
M.C. Iliana Amabely Silva Hernández
Asesor OR:
Dr. René Rodríguez Zamora
Mazatlán, Sinaloa; 15 de diciembre de 2020
"2020, Año de Leona Vicario, Benemérita Madre de la Patria”
Calle: Corsario 1 N
LIC. EDUARDO CRESPO CAMPA.DIRECTOR DE VINCULACIÓN, DIFUSIÓN Y EXT. UNIVERSITARIA.UNIVERSIDAD POLITÉCNICA DE SINALOA.BELTRÁN PRESENTE Por este medio, hago de su conocimiento que la alumnaCastro, con número de matrículaacepada para realizar su estadía práctica, en esta de septiembre de 2020 al 04 de diciembre de 2020, para cubrir un total de 600 horas. Dicha alumna realizará actividades dentro del áreabajo mi supervisión. Por la atención brindada a la presente, manifiesto a usted mi más atenta y distinguida consideración. A T E N T A M E N T E Excelencia en Educación Tecnológica® DR. RENÉ RODRÍGUEZ ZAMORAPROFESOR-INVESTIGADORTECNOLÓGICO NACIONAL DE MÉXICO CAMPUS MAZATLÁN Ccp. Archivo
"2020, Año de Leona Vicario, Benemérita Madre de la Patria”
Calle: Corsario 1 No 203 Colonia: Urías C.P. 82070 Mazatlán, Sinaloa.
Tel. 01 (669) 983-8400 990-0209 991-1061
e-mail: [email protected]
www.tecnm.mx
Mazatlán, Sinaloa
LIC. EDUARDO CRESPO CAMPA. DIRECTOR DE VINCULACIÓN, DIFUSIÓN Y EXT. UNIVERSITARIA. UNIVERSIDAD POLITÉCNICA DE SINALOA.DR. SERGIO EFRAÍN BELTRÁN
, hago de su conocimiento que la alumna Andrea Jeannette Garibaldi López , con número de matrícula 2017030707, de la carrera de Ingeniería en Informática
práctica, en esta institución, durante el período que comprende del 7 de septiembre de 2020 al 04 de diciembre de 2020, para cubrir un total de 600 horas.
realizará actividades dentro del área de investigación en sistemas computacionales
Por la atención brindada a la presente, manifiesto a usted mi más atenta y distinguida consideración.
Excelencia en Educación Tecnológica®
DR. RENÉ RODRÍGUEZ ZAMORA INVESTIGADOR
TECNOLÓGICO NACIONAL DE MÉXICO
"2020, Año de Leona Vicario, Benemérita Madre de la Patria”
Mazatlán, Sinaloa 07/Sept/2020
DR. SERGIO EFRAÍN BELTRÁN
Andrea Jeannette Garibaldi López Ingeniería en Informática, ha sido
institución, durante el período que comprende del 7 de septiembre de 2020 al 04 de diciembre de 2020, para cubrir un total de 600 horas.
de investigación en sistemas computacionales,
Por la atención brindada a la presente, manifiesto a usted mi más atenta y distinguida consideración.
"2020, Año de Leona Vicario, Benemérita Madre de la Patria”
Mazatlán, Sinaloa 07/Dic/2020
LIC. EDUARDO CRESPO CAMPA. DIRECTOR DE VINCULACIÓN, DIFUSIÓN Y EXT. UNIVERSITARIA. UNIVERSIDAD POLITÉCNICA DE SINALOA
PRESENTE
Por este medio, hago de su conocimiento que la alumna Andrea Jeannette Garibaldi López Castro, con número de matrícula 2017030707, de la carrera de Ingeniería en Informática, ha cumplido con 600 horas correspondientes a su estadía final en esta institución, durante el periodo que comprende del 7 de septiembre de 2020 al 4 de diciembre de 2020.
Dicha alumna realizó actividades dentro del área de investigación en sistemas computacionales, bajo mi supervisión.
Por la atención brindada a la presente, manifiesto a usted mi más atenta y distinguida consideración.
A T E N T A M E N T E Excelencia en Educación Tecnológica®
DR. RENÉ RODRÍGUEZ ZAMORA PROFESOR-INVESTIGADOR TECNOLÓGICO NACIONAL DE MÉXICO CAMPUS MAZATLÁN
Ccp. Archivo
Calle: Corsario 1 No 203 Colonia: Urías C.P. 82070 Mazatlán, Sinaloa. Tel. 01 (669) 983-8400 990-0209 991-1061
e-mail: [email protected] www.itmazatlan.edu.mx
2
Dedicatoria
El siguiente documento, así como la carrera en general es un logro personal que tal
vez no hubiera sido tan sencillo de lograr de no ser por la ayuda de ciertas personas
que considero mencionar a continuación, personas que de una manera u otra
estuvieron al tanto de mi crecimiento profesional.
Primeramente, quisiera agradecer a mi mamá por el apoyo, esfuerzo y dedicación
para sacarnos adelante e insistir en que no me rindiera a pesar del cansancio por la
escuela y trabajo. A mis abuelos Olga y Raúl, por estar pendientes de que no hubiera
algo que complicara mis estudios y motivarme a siempre cumplir mis metas.
A mis amigos de la escuela, con quienes pasé varios desvelos antes de las entregas
de los proyectos, así como ratos muy agradables que hacían de la carrera algo más
llevadero.
A la profesora Amabely Silva, por ser una guía en el área de la investigación y
permitirme participar en un par de proyectos junto con ella. Por motivarme a hacer
las cosas de la manera correcta y no de la manera fácil, así como hacer que naciera
mi interés en la ingeniería de software.
A Miguel Alcantar, quien fue mi encargado durante casi tres años y pasó a ser un
muy buen amigo. De quien aprendí y sigo aprendiendo cosas relacionadas con la
computación y las redes. Y quien estuvo para sacarme de apuros con dudas o
proyectos de la escuela.
Por último y no menos importante, quisiera dedicarme este logro. Tres años de
esfuerzo, con pocas horas de sueño pero que al final habrán valido la pena. Logro
que parecía muy distante al iniciar pero que paso a paso lo pude cumplir, porque el
chiste está en no detenerse nunca a pesar de lo difícil que pueda volverse todo.
“Que la fuerza los acompañe.”
3
Resumen
En el mundo de la tecnología, existen diferentes técnicas, herramientas y
metodologías para el desarrollo de proyectos y software. A pesar de que el uso de
cada una de ellas depende de la finalidad del proyecto a desarrollar, estas mismas
son lo suficientemente flexibles como para combinarse unas y otras o para dar una
explicación un poco más detallada de los procesos a desarrollar.
En esta investigación se estudiarán metodologías de Ingeniería de Software
Orientadas a Agentes y las notaciones respectivas, es decir, artefactos de desarrollo
que son específicamente concebidos para crear y simular sistemas basados en
agentes. Asimismo, se seguirá la metodología BDI para el diseño y construcción de
agentes dentro de una simulación que tomará lugar en un área de una playa.
Abstract
In the world of technology, there are different techniques, tools and methodologies for
the development of projects and software. Although the use of each one of them
depends on the purpose of the project to be developed, they are flexible enough to be
combined with each other or to give a more detailed explanation of the processes to
be developed.
In this research, agent-oriented software engineering methodologies and their
respective notations will be studied, that is, development artifacts that are specifically
conceived to create and simulate agent-based systems. Likewise, the BDI
methodology will be followed for the design and construction of agents within a
simulation that will take place in a beach area.
4
Índice Dedicatoria ............................................................................................................... 2
Resumen ................................................................................................................. 3
Abstract ................................................................................................................... 3
Tabla de contenido de imágenes ................................................................................ 8
CAPÍTULO I. INTRODUCCIÓN ................................................................................. 10
Introducción ........................................................................................................... 11
Antecedentes ......................................................................................................... 11
Logo de la empresa............................................................................................ 12
Localización ....................................................................................................... 12
Organigrama ...................................................................................................... 13
Objetivo de la institución .................................................................................... 13
Misión ................................................................................................................. 14
Visión ................................................................................................................. 14
Planteamiento del problema .................................................................................. 14
Hipótesis ................................................................................................................ 15
Objetivos ................................................................................................................ 15
Objetivos generales............................................................................................ 15
Objetivos específicos ......................................................................................... 15
Importancia y/o justificación del estudio................................................................. 15
Limitaciones del estudio......................................................................................... 16
CAPÍTULO II. MARCO TEÓRICO ............................................................................. 17
Ingeniería de software ........................................................................................... 18
Metodología ....................................................................................................... 19
Modelos de desarrollo de software..................................................................... 20
Modelos de proceso prescriptivo ........................................................................ 20
5
Modelos de proceso especializado .................................................................... 21
Ingeniería de software basada en agentes ........................................................ 21
Metodologías de software orientadas a agentes ................................................... 21
Sistemas Multiagente............................................................................................. 22
Agentes .................................................................................................................. 23
Propiedades ....................................................................................................... 23
Modelos basados en agentes ................................................................................ 24
Funciones ........................................................................................................... 25
Ventajas ............................................................................................................. 25
¿Cuándo usar un MBA? ..................................................................................... 25
Metodología BDI .................................................................................................... 26
Simulación ............................................................................................................. 28
Tipos de simulaciones ........................................................................................ 29
Simulaciones que enseñan acerca de una situación ......................................... 29
Simulaciones que enseñan a realizar alguna situación ...................................... 29
GAMA .................................................................................................................... 30
GAML..................................................................................................................... 31
Lenguaje Unificado de Modelado .......................................................................... 31
Conceptos de modelado especificados por UML ............................................... 32
Tipos de diagramas UML ................................................................................... 32
CAPÍTULO III. DISEÑO Y DESARROLLO ................................................................ 40
Diseño.................................................................................................................... 41
Diseño BDI ............................................................................................................. 41
Paciente infectado (Irresponsable) ..................................................................... 41
Paciente sano (Responsable) ............................................................................ 42
6
Paciente sano (Irresponsable) ........................................................................... 43
Historias de usuario ............................................................................................... 44
Historia de usuario #1 – Paciente sano usa cubreboca ..................................... 45
Historia de usuario #2 – Paciente infectado usa cubreboca ............................... 45
Historia de usuario #3 – Paciente no respeta distancia de seguridad ................ 46
Historia de usuario #4 – Paciente sano comparte vaso con paciente infectado . 47
Historia de usuario #5 – Paciente infectado tose sin usar cubrebocas .............. 47
Diagramas de caso de uso .................................................................................... 48
Caso de uso “Paciente infectado (Irresponsable)” ............................................. 48
Caso de uso “Paciente sano (Responsable)” ..................................................... 49
Caso de uso “Paciente sano (Irresponsable)” .................................................... 51
Desarrollo .............................................................................................................. 52
Definición de variables globales ......................................................................... 52
Creación de agentes .......................................................................................... 53
Definición del experimento ................................................................................. 54
Modelo de propagación de virus ........................................................................ 55
Resultados ............................................................................................................. 56
Conclusiones ......................................................................................................... 59
Bibliografía....................................................................................................... 61
Glosario ................................................................................................................. 62
Agente ................................................................................................................ 62
Sistema multiagente ........................................................................................... 62
Ingeniería de software ........................................................................................ 62
Metodología BDI................................................................................................. 62
Simulación .......................................................................................................... 63
7
UML.................................................................................................................... 63
Diagrama de caso de uso .................................................................................. 63
Historia de usuario ............................................................................................. 63
8
Tabla de contenido de imágenes Imagen 1.1 …………………………………………………………………………………..11
Imagen 1.2 …………………………………………………………………………………..12
Imagen 1.3 …………………………………………………………………………………..12
Imagen 2.1 …………………………………………………………………………………..17
Imagen 2.2 …………………………………………………………………………………..26
Imagen 2.3 …………………………………………………………………………………..31
Imagen 2.4 …………………………………………………………………………………..31
Imagen 2.5 …………………………………………………………………………………..32
Imagen 2.6 …………………………………………………………………………………..32
Imagen 2.7 …………………………………………………………………………………..33
Imagen 2.8 …………………………………………………………………………………..33
Imagen 2.9 …………………………………………………………………………………..34
Imagen 2.10 …………………………………………………………………………………35
Imagen 2.11 …………………………………………………………………………….…..35
Imagen 2.12 ………………………………………………………………………………..36
Imagen 2.13 …………………………………………………………………………….…..36
Imagen 2.14 …………………………………………………………………………….…..37
Imagen 2.15 …………………………………………………………………………….…..37
Imagen 3.1 …………………………………………………………………………………..40
Imagen 3.2 …………………………………………………………………………………..41
Imagen 3.3 …………………………………………………………………………………..42
9
Imagen 3.4 …………………………………………………………………………………..43
Imagen 3.5 …………………………………………………………………………………..44
Imagen 3.6 …………………………………………………………………………………..44
Imagen 3.7 …………………………………………………………………………………..45
Imagen 3.8 …………………………………………………………………………………..46
Imagen 3.10 …………………………………………………………………….…………..48
Imagen 3.11 ….……………………………………………………………………………..50
Imagen 3.12 .………………………………………………………………………………..55
Imagen 3.13 .………………………………………………………………………………..56
Imagen 3.14 .………………………………………………………………………………..57
10
CAPÍTULO I. INTRODUCCIÓN
11
Introducción
Como todo enfoque informático para la solución de problemas, el uso de los
sistemas multiagente propone una ayuda metodológica en conjunto con la ingeniería
de software para el estudio de casos. En esta investigación se estudiarán
metodologías de Ingeniería de Software Orientadas a Agentes y las notaciones
respectivas, es decir, artefactos de desarrollo que son específicamente concebidos
para crear y simular sistemas basados en agentes. Una herramienta útil para poder
experimentar en entornos controlados son las simulaciones, las cuales permiten
reproducir un experimento dentro de un equipo de cómputo, usando variables que
permiten orientar la simulación al resultado esperado; bajo esta perspectiva se tomó
como caso de estudio la propagación de virus en una zona determinada.
Para esta investigación se trabajará en la conceptualización de los agentes
desde una arquitectura BDI a través de creencias, objetivos y planes que permiten
iterar las características y comportamientos de los agentes. Para este caso de
estudio se utilizarán dos tipos de agentes, aquellos que siguen los planes preventivos
para evitar la propagación y contagio y aquellos que no toman ninguna medida
preventiva.
Antecedentes
Los primeros Institutos Tecnológicos (IT) surgieron en México en el año de
1948, fueron Durango y Chihuahua los estados en los que se asentaron, con el
propósito de impulsar la ciencia y tecnología regional. Poco tiempo después se
fundaron los de Saltillo (1951) y Ciudad Madero (1954).
Hacia 1955, estos primeros cuatro Tecnológicos atendían una población
escolar de 1,795 alumnos, de los cuales 1,688 eran hombres y sólo 107 mujeres.
En 1957 inició operaciones el IT de Orizaba. En 1959, los Institutos
Tecnológicos son desincorporados del Instituto Politécnico Nacional, para depender,
por medio de la Dirección General de Enseñanzas Tecnológicas Industriales y
Comerciales, directamente de la Secretaría de Educación Pública.
12
En el libro La Educación Técnica en México. Institutos Tecnológicos
Regionales, editado por la Secretaría de Educación Pública en 1958, se marcó la
desincorporación plena de los IT y el inicio de una nueva etapa caracterizada por la
respuesta que dan estas instituciones a las necesidades propias del medio
geográfico y social, y al desarrollo industrial de la zona en que se ubican.
El Tecnológico Nacional de México está constituido por 254 instituciones, de
las cuales 126 son Institutos Tecnológicos Federales, 122 Institutos Tecnológicos
Descentralizados, cuatro Centros Regionales de Optimización y Desarrollo de Equipo
(CRODE), un Centro Interdisciplinario de Investigación y Docencia en Educación
Técnica (CIIDET) y un Centro Nacional de Investigación y Desarrollo Tecnológico
(CENIDET). En estas instituciones, el TecNM atiende a una población escolar de
más de 600 mil estudiantes en licenciatura y posgrado en todo el territorio nacional,
incluida la Ciudad de México.
Logo de la empresa
Imagen 1.1
Fuente: Google Images
Localización
El Instituto Tecnológico de Mazatlán está ubicado en: Calle Corsario 1 No.
203, Colonia Urías. C.P: 82070. Mazatlán, Sin.
13
Imagen 1.2
Fuente: Google Maps
Organigrama
Imagen 1.3
Fuente: www.tecnm.mx
Objetivo de la institución
El egresado del programa de Ingeniería en Sistemas Computacionales será
capaz de identificar y resolver problemas susceptibles de ser atendidos mediante
sistemas y tecnologías informáticas y computacionales, desarrollando e innovando
14
con un enfoque sistemático que conduzca a la viabilidad social.
Misión
Formar profesionistas en Ingeniería en Sistemas Computacionales capaces de
identificar y delimitar problemas relacionados con el procesamiento de información, la
innovación y el desarrollo tecnológico, estructurar e implementar sistemas y
soluciones, con habilidades de autoaprendizaje y trabajo en equipo, apoyados en
herramientas, estándares y métodos científicos, conscientes del impacto de su
ejercicio profesional en la sociedad.
Visión
Ser un programa educativo dinámico, que responda a los requerimientos
locales, nacionales y globales, que tome en consideración los avances y tendencias
de desarrollo tecnológico, que posibilite la formación académica y personal de
profesionistas capaces y comprometidos.
Planteamiento del problema
El uso de simulaciones en sistemas informáticos permite recrear situaciones
reales o crear situaciones hipotéticas en las que, mediante la experimentación y
ajuste constante de diversas variables, podamos obtener comportamientos cercanos
a la realidad. Los resultados arrojados en este tipo de sistemas pueden ser
aprovechados para estudiar de manera previa desde el comportamiento de una
sociedad frente a diferentes situaciones hasta el funcionamiento de diversos
sistemas ante diferentes casos de prueba.
Desde hace un año, el mundo se vio obligado a cambiar su ritmo de vida
debido a una pandemia provocada por el virus conocido como COVID-19. Dichos
cambios obligan a las personas a mantener cierta distancia de seguridad para evitar
el aumento de contagios. Al estar obligados a cambiar el ritmo de vida, es necesario
encontrar alternativas para poder continuar con nuestras actividades diarias de la
mejor manera posible.
Al hablar de investigación, una de las etapas de mayor importancia es la etapa
15
de experimentación y análisis de resultados. A pesar de que ciertas ramas cuentan
con la posibilidad de experimentar de manera física y sin contacto entre dos o más
personas, existen otras que necesitan de la interacción social para poder llevar a
cabo sus experimentos y análisis. Es por esto que se propone como alternativa para
el estudio de ciertos casos el uso de entornos de simulación que puedan ser
diseñados de una manera lo más apegada a la realidad posible, de manera que los
resultados tengan valor para la investigación en la que se vean involucrados.
Hipótesis
Diseñar agentes y entornos de simulación mediante el uso de las
metodologías de ingeniería de software orientada a agentes, en conjunto con la
arquitectura BDI.
Objetivos
Objetivos generales
Diseñar agentes y entornos de simulación que permitan estudiar el
comportamiento de los mismos en un entorno controlado utilizando la plataforma de
simulación GAMA.
Objetivos específicos
Diseñar agentes usando la arquitectura BDI.
Redactar casos de uso para describir las acciones que seguirá el agente.
Representar el entorno controlado mediante el uso del framework GAMA.
Importancia y/o justificación del estudio
El presente proyecto propone el uso de las técnicas de simulación para la
experimentación y análisis de resultados en diferentes proyectos o investigaciones,
de manera que se evite lo más posible el contacto entre dos o más personas durante
este tipo de etapas.
Por otra parte, busca utilizar metodologías de ingeniería de software orientada
a agentes para poder realizar un proceso de abstracción y conceptualización de
16
agentes lo más apegado a la realidad posible.
Limitaciones del estudio
La simulación es un tema que va de la mano con la ingeniería y la
programación, es por esto que puede presentar cierto grado de complejidad ante las
personas que no trabajan directamente con estos temas o laboran en esta área.
De igual manera, se requiere equipo computacional de gama media-alta para
poder llevar a cabo la programación y simulación de los agentes, por lo que puede
ser un impedimento para investigaciones de bajo presupuesto o sin equipo
computacional apto para las actividades propuestas a continuación.
17
CAPÍTULO II. MARCO TEÓRICO
18
Ingeniería de software
La ingeniería de software es una tecnología con varias capas. Como se
aprecia en la figura 2.1, cualquier enfoque de ingeniería (incluso la de software) debe
basarse en un compromiso organizacional con la calidad. La administración total de
la calidad, Six Sigma y otras filosofías similares alimentan la cultura de mejora
continua, y es esta cultura la que lleva en última instancia al desarrollo de enfoques
cada vez más eficaces de la ingeniería de software. El fundamento en el que se
apoya la ingeniería de software es el compromiso con la calidad [1].
Imagen 2.1
Fuente: Ingeniería del software. Un enfoque práctico.
El fundamento para la ingeniería de software es la capa proceso. El proceso
de ingeniería de software es el aglutinante que une las capas de la tecnología y
permite el desarrollo racional y oportuno del software de cómputo. El proceso define
una estructura que debe establecerse para la obtención eficaz de tecnología de
ingeniería de software. El proceso de software forma la base para el control de la
administración de proyectos de software, y establece el contexto en el que se aplican
métodos técnicos, se generan productos del trabajo (modelos, documentos, datos,
reportes, formatos, etc.), se establecen puntos de referencia, se asegura la calidad y
19
se administra el cambio de manera apropiada.
Los métodos de la ingeniería de software proporcionan la experiencia técnica
para elaborar software. Incluyen un conjunto amplio de tareas, como comunicación,
análisis de los requerimientos, modelación del diseño, construcción del programa,
pruebas y apoyo. Los métodos de la ingeniería de software se basan en un conjunto
de principios fundamentales que gobiernan cada área de la tecnología e incluyen
actividades de modelación y otras técnicas descriptivas.
Las herramientas de la ingeniería de software proporcionan un apoyo
automatizado o semiautomatizado para el proceso y los métodos. Cuando se
integran las herramientas de modo que la información creada por una pueda ser
utilizada por otra, queda establecido un sistema llamado ingeniería de software
asistido por computadora que apoya el desarrollo de software [1].
Metodología
En el contexto de la ingeniería de software, un proceso no es una prescripción
rígida de cómo elaborar software de cómputo. Por el contrario, es un enfoque
adaptable que permite que las personas que hacen el trabajo (el equipo de software)
busquen y elijan el conjunto apropiado de acciones y tareas para el trabajo. Se busca
siempre entregar el software en forma oportuna y con calidad suficiente para
satisfacer a quienes patrocinaron su creación y a aquellos que lo usarán.
La estructura del proceso establece el fundamento para el proceso completo
de la ingeniería de software por medio de la identificación de un número pequeño de
actividades estructurales que sean aplicables a todos los proyectos de software, sin
importar su tamaño o complejidad. Además, la estructura del proceso incluye un
conjunto de actividades sombrilla que son aplicables a través de todo el proceso del
software. Una estructura de proceso general para la ingeniería de software consta de
cinco actividades:
Comunicación
Planeación
Modelado
20
Construcción
Despliegue
Estas cinco actividades estructurales genéricas se usan durante el desarrollo
de programas pequeños y sencillos, en la creación de aplicaciones web grandes y en
la ingeniería de sistemas enormes y complejos basados en computadoras. Los
detalles del proceso de software serán distintos en cada caso, pero las actividades
estructurales son las mismas [2].
Modelos de desarrollo de software
Un modelo para el desarrollo de software es una representación abstracta de
un proceso. Cada modelo representa un proceso desde una perspectiva particular y
así proporcione información parcial sobre el proceso. Éstos modelos generales no
son descripciones definitivas de los procesos del software más bien son
abstracciones de los procesos que se pueden utilizar para el desarrollo del software.
Puede pensarse en ellos como marcos de trabajo del proceso y que pueden ser
adaptados para crear procesos más específicos. Los modelos que mencionaremos
en este punto son:
Modelos de proceso prescriptivo
Los modelos de proceso prescriptivo fueron propuestos originalmente para
poner orden en el caos del desarrollo de software. La historia indica que estos
modelos tradicionales han dado cierta estructura útil al trabajo de ingeniería de
software y que constituyen un mapa razonablemente eficaz para los equipos de
software. Sin embargo, el trabajo de ingeniería de software y el producto que genera
siguen “al borde del caos”.
Modelo de cascada
Modelo de proceso incremental
Modelo de proceso evolutivo
Modelo espiral
Modelo concurrente
21
Cada modelo del proceso también prescribe un flujo del proceso (también
llamado flujo de trabajo), es decir, la manera en la que los elementos del proceso se
relacionan entre sí. Todos los modelos del proceso del software pueden incluir las
actividades estructurales generales, pero cada una pone distinto énfasis en ellas y
define en forma diferente el flujo de proceso que invoca cada actividad estructural
(así como acciones y tareas de ingeniería de software) [3].
Modelos de proceso especializado
Los modelos de proceso especializado tienen muchas de las características
de uno o más de los modelos tradicionales. Sin embargo, dichos modelos tienden a
aplicarse cuando se elige un enfoque de ingeniería de software especializado o
definido muy específicamente [4].
Ingeniería de software basada en agentes
Como casi todo enfoque informático para la solución de problemas, los
sistemas multiagentes proponen ayudas metodológicas de ingeniería de software, en
este caso metodologías de ingeniería del software orientada a agentes (en inglés
AOSE, Agent Oriented Software Engineering) y notaciones. Es decir, artefactos de
desarrollo que son específicamente concebidos para crear sistemas basados en
agentes [5].
Metodologías de software orientadas a agentes
Vocales (Voyelles) de Yves Demazeau es una de las primeras propuestas en
el área, y considera la concepción de sistemas multiagentes desde varios
puntos de vista, correspondientes a las vocales: Agente, Entorno,
Interacciones, y Organización.
GAIA de Michael Wooldridge y Nick Jennings de la Univ. de Southampton,
propone cómo realizar un análisis basado en roles del sistema multi-agente.
MASE de Scott A. Deloach propone agentes como extensiones de objetos y
proporciona la herramienta AgentTool para análisis, diseño e implementación.
AgentUML de James Odell, propone una notación, extendiendo UML, para
especificar protocolos de comunicación entre agentes.
22
MADKiT es una herramienta de desarrollo, propuesta por Jacques Ferber,
basada en el paradigma Agente-Role-Organización de la metodología
Aalaadin.
ADELFE del grupo IRIT de la Universidad de Toulouse, trata especialmente
los temas de cooperación entre agentes.
INGENIAS del grupo GRASIA de la UCM, extiende la metodología MESSAGE
y proporciona un conjunto de herramientas para modelar y generar código de
sistemas multiagente.
Mas-CommonKADS de Carlos Iglesias en la UPM extiende la metodología
CommonKADS, para sistemas expertos, a agentes, utilizando estructuración
orientada a objetos y lenguajes de especificación de protocolos como SDL.
SemanticAgent del grupo LIRIS de la Universidad de Lyon. Basada en el
SWRL [5].
Sistemas Multiagente
Un sistema multiagente es un sistema distribuido en el cual los nodos o
elementos son sistemas de inteligencia artificial, o bien un sistema distribuido donde
la conducta combinada de dichos elementos produce un resultado en conjunto
inteligente.
Hay que notar que los agentes no son necesariamente inteligentes. Existen como
en todo el resto del dominio de la inteligencia artificial, dos enfoques para construir
sistemas multiagentes [5]:
El enfoque formal o clásico, que consiste en dotar los agentes de la mayor
inteligencia posible utilizando descripciones formales del problema que
resolver y de hacer reposar el funcionamiento del sistema en tales
capacidades cognitivas. Usualmente la inteligencia es definida utilizando un
sistema formal (por ejemplo, sistemas de inferencia lógica) para la
descripción, raciocinio, inferencia de nuevo conocimiento y planificación de
acciones a realizar en el medio ambiente.
El enfoque constructivista, que persigue la idea de brindarle inteligencia al
23
conjunto de todos los agentes, para que a través de mecanismos
ingeniosamente elaborados de interacción, el sistema mismo genere
comportamiento inteligente que no necesariamente estaba planeado desde un
principio o definido dentro de los agentes mismos (que pueden ser realmente
simples). Este tipo de conducta es habitualmente llamado comportamiento
emergente [5].
Agentes
La palabra "Agente" se refiere a todo ente que posee la habilidad, capacidad y
autorización para actuar en nombre de otro. A diario, los agentes humanos asisten a
las personas en tareas que requieren recursos especializados o conocimiento
específico en un dominio. Por ejemplo, una secretaria atiende y resuelve situaciones
en nombre de su jefe: administra la agenda, coordina las reuniones, recibe a los
visitantes.
Los agentes cumplen con los requerimientos para los cuales fueron
entrenados. El usuario "delega" en el agente una o varias tareas que debe llevar a
cabo quedando a la espera de los resultados. Dichas tareas son a menudo fáciles de
especificar, pero - en algunos casos – complejas de realizar [6].
Propiedades
Autonomía: Capacidad de actuar sin la intervención directa de una persona o
de otro agente. Un agente debe poder controlar sus propias acciones y estado
interno. Una vez que el usuario activa el agente indicando algún objetivo de
alto nivel, éste actúa independientemente, seleccionando estrategias y
monitoreando el progreso en busca de la meta. Si falla con una estrategia,
usará otra, pero sin intervención humana o con la mínima indispensable.
Habilidad Social: Un agente debe ser comunicativo. Debe tener habilidad
para interactuar con otros agentes o incluso con alguna persona, para solicitar
información o bien para exponer los resultados obtenidos de la ejecución de
las tareas agendadas. La naturaleza de la comunicación dependerá del tipo de
agente con quien se comunique (humanos o no), en ambos casos se deberá
24
establecer un protocolo común de intercambio de información entre ambas
partes.
Los agentes deben poseer algún tipo de interface para comunicarse con sus
usuarios. Dicha interface puede establecerse simplemente mediante el envío
de mensajes por correo electrónico o puede ser todo lo sofisticada que uno
quisiera (el deseo es proveer una interface más antropomórfica [human-like]
para los agentes)
Reactividad: Se refiere al hecho de que un agente debe poder sensar el
estado del ambiente dentro del cual se encuentra inmerso y -en función de
esto- actuar, respondiendo de manera adecuada a cambios producidos en el
mismo. Los efectos producidos pueden modificar el estado de su entorno. Por
ejemplo, un agente de filtrado de correo electrónico está sensando su
ambiente, alerta a la llegada de nuevos mensajes. La llegada de un nuevo
mensaje (cambio en el medio) produce que el agente responda de acuerdo a
la tarea asignada.
Orientación por objetivos: Un agente no solo debe actuar por cambios
detectados en el medioambiente, sino que, además, debe "trabajar" en función
de los objetivos para los cual fue diseñado y las tareas que le fueron
delegadas en cada momento [6].
Modelos basados en agentes
La modelación basada en agentes es una técnica de modelación que
complementa los métodos analíticos tradicionales. En los modelos basados en
agentes (MBA), también conocidos como sistemas multi-agentes o sistemas basados
en agentes, un sistema es modelado como una colección de entidades autónomas
de toma de decisión llamadas agentes. Cada agente evalúa su situación y toma
decisiones sobre la base de un conjunto de reglas de decisión. A diferencia de los
métodos analíticos, que se enfocan en modelar y caracterizar el equilibrio de un
sistema (enfoque “top-down”), los modelos basados en agentes ofrecen la posibilidad
de ese equilibrio. En este sentido, los ABM tienen un enfoque “bottom-up”: esto
significa que el modelador representa el comportamiento y las interacciones de los
25
agentes individuales y objetos locales que componen el sistema y obtiene como
resultado un patrón de comportamiento a nivel del sistema [7].
Funciones
Los sistemas complejos se caracterizan por las interdependencias,
heterogeneidad y jerarquías anidadas de sus componentes (individuos, actores
diversos, espacio, etc.). Las interdependencias pueden existir entre los actores, entre
los actores y espacio biofísico y a lo largo del tiempo. A su vez, existe
heterogeneidad entre actores, en el espacio biofísico, y a lo largo del tiempo.
Finalmente, las estructuras jerárquicas surgen, por ejemplo, cuando individuos se
reúnen para formar una familia u organización. Cuando un sistema combina
interdependencia entre sus componentes y heterogeneidad de los mismos las
soluciones analíticas, que asumen agentes homogéneos, son difíciles de obtener.
Los MBA son apropiados para tratar este tipo de situaciones [7].
Ventajas
La gran ventaja de los MBA es la posibilidad de descubrir y explicar el
comportamiento emergente de sistemas complejos como resultado de las
características y comportamiento de las partes del mismo. Así, esta aproximación no
necesita basarse en asunciones exógenas o imposiciones de equilibrio del sistema,
sino que el comportamiento del mismo surge endógenamente (botton-up).
Otra ventaja de los MBA se basa en que permiten incorporar las
características de los sistemas complejos: interdependencia, heterogeneidad, y
jerarquías. Los MBA permiten incluir interacciones explicitas e implícitas entre
agentes y agentes y su ambiente. Para esto el modelador explicita reglas que definen
como los agentes interaccionan entre sí en el marco de la red social que forman y
con su ambiente. Asimismo, los agentes y el ambiente (el espacio virtual en donde
conviven los agentes) de un MBA pueden ser caracterizados por atributos propios y
distintivos [7].
¿Cuándo usar un MBA?
Si el sistema en estudio tiene alguna de las características que a continuación se
26
listan, es posible que un MBA sea una aproximación apropiada para simularlo de
manera más realista [7]:
Interacciones complejas: En el sistema existen interacciones entre agentes,
no-lineales, discontinuas o discretas (de manera de que el comportamiento de
un agente puede ser dramáticamente alterado por otros agentes). En estos
casos, describir los comportamientos con aproximaciones tradicionales puede
ser muy difícil.
Poblaciones heterogéneas: Existen distintos tipos de componentes
(agentes) formando parte del sistema y, a su vez, componentes del mismo tipo
muestran atributos o características diferentes. Las aproximaciones de
modelación tradicionales representan un componente (agente) con
características promedio.
Complejidad topológica: La topología de las interacciones entre los
componentes del sistema en estudio es heterogénea y compleja. Esto es
principalmente importante para procesos sociales (en donde existe
aprendizaje y adaptación) y físicos. Representar de manera realista la
topología de las relaciones entre agentes puede ser necesario para explicar
adecuadamente el comportamiento agregado o global del sistema.
Comportamientos complejos: Los MBA pueden ser una aproximación
apropiada cuando las entidades o individuos del sistema tienen un
comportamiento que: (a) es muy complejo para describirlo a través de
ecuaciones (b) no puede ser claramente definido a través de tasas de
transición agregadas, (c) es estocástico.
Espacialidad: Los MBA pueden ser fundamentales para modelar sistemas en
donde el componente espacial es relevante en el funcionamiento del mismo.
En este sentido, los MBA tienen la flexibilidad de representar agentes que se
mueven en el espacio y características del ambiente que varían
espacialmente.
Metodología BDI
La arquitectura BDI (Belief, Desire, Intention) está caracterizada por el hecho
27
de que los agentes que la implementan están dotados de los estados mentales de
Creencias, Deseos e Intenciones [8].
Imagen 2.2
Fuente: Modelos y Arquitecturas de Agente
Las nociones de complejidad y cambio tienen un gran impacto en la forma en
que se construyen los sistemas computacionales y por tanto en los agentes. Los
agentes y en particular los agentes BDI incorporan componentes que permiten el
desarrollo de sistemas que se integren adecuadamente en el mundo real. Muchas de
las aplicaciones de sistemas informáticos son algorítmicas y trabajan con información
exacta. Pero la mayoría de las aplicaciones requieren sistemas más complejos,
sistemas capaces de relacionarse con un entorno cambiante y con un cierto grado de
incertidumbre. Los agentes y los sistemas multiagentes tienen por tanto que ser
capaces de proporcionar soluciones a este tipo de problemas. El modelo BDI se ha
desarrollado para proporcionar soluciones en entornos dinámicos o inciertos, en los
que el agente o los agentes sólo tienen una visión parcial del problema (el acceso a
la información está limitado) y posiblemente manejen un número limitado de recursos
28
(recursos informáticos finitos). Las creencias, los deseos, las intenciones, y los
planes son una parte fundamental del estado de ese tipo de sistemas [8].
Basándose en el formalismo teórico anteriormente descrito, se definen las
relaciones que deben existir entre las creencias, los deseos y las intenciones del
agente. Algunas de las más importantes se enumeran a continuación de manera
intuitiva:
Compatibilidad entre creencias y objetivos. Si el agente adopta el deseo de
alcanzar un objetivo, debe creer que, en alguno de los mundos accesibles por
la relación de creencia, dicho objetivo es cierto.
Compatibilidad entre objetivos e intenciones. Previamente a que el agente
adopte una fórmula como intención debe haberla adoptado como deseo.
Las intenciones conducen a acciones. Si una de las intenciones es una acción
primitiva o simple, el agente la ejecuta. Es decir, no se pospone la ejecución
de una acción simple.
Relación entre creencias e intenciones. El agente conoce (cree en) sus
propias intenciones.
Relación entre creencias y objetivos. El agente conoce sus objetivos o deseos.
No hay retrasos infinitos. Cuando un agente adopta una intención, sigue con
ella hasta algún momento del futuro, es decir, no puede haber una parada
infinita en el proceso de alcance de un determinado objetivo (esto es, debe
haber progreso) [8].
Simulación
El concepto de la simulación se cristalizó a principios de los años 1950 cuando
se dio una gran importancia al proceso de dividir en partes a un problema para
examinar la interacción simultánea de todas ellas. La simulación hizo posible llevar a
cabo análisis integrados en su totalidad de los sistemas, los cuales solían ser
demasiado complejos para hacerse analíticamente.
Aunque los sistemas varían en sus características y complejidades, la síntesis de
información de modelos, es la ciencia de la computación y las técnicas estadísticas
29
que representa este tipo de simulación constituyen un útil método para aprender
sobre esas características y complejidades e imponerles una estructura.
La simulación es esencialmente una técnica que enseña a construir el modelo
de una situación real aunada a la realización de experimentos con el modelo. Esta
definición es amplia y puede comprender situaciones aparentemente no relacionadas
entre sí, como los simuladores de vuelo, juegos militares, juegos de gerencia,
modelos físicos de ríos, modelos econométricos, diversos dispositivos eléctricos
analógicos y pruebas de aeroplanos en túneles aerodinámicos [9].
Tipos de simulaciones
Simulaciones que enseñan acerca de una situación
Simulaciones físicas: En una simulación física la computadora, el objeto o
fenómeno es representado en la pantalla, ofreciendo a las personas la
oportunidad de aprender sobre él, es decir, el propósito de este tipo de
simulación es enseñar a las personas cómo funciona algo. En este tipo de
simulación las personas pueden tratar de conocer cuál será el resultado si
cambiaran alguna reacción o movimiento. También pueden hacer n número de
intentos que en la realidad no podrían.
Simulaciones de procesos: Este tipo de simulación se utiliza generalmente
para informar a las personas acerca de un proceso o concepto que no
manifiesta visiblemente. En este tipo de simulación la persona escoge desde
el principio de la simulación los valores y parámetros, y puede cambiarlos
cuando lo desee hasta lograr mejor resultado [9].
Simulaciones que enseñan a realizar alguna situación
Simulaciones de procedimientos: El propósito de las simulaciones de
procedimientos es que las personas aprendan una secuencia de acciones que
constituyen un procedimiento, es decir, enseñar a las personas cómo hacer
algo. Este tipo de simulación frecuentemente requiere la simulación de
objetos. La cual permite a las personas conocer e investigar cada paso que se
debe seguir para lograr el objetivo de la simulación. Al igual que en los otros
30
puede intentar diferentes pasos para lograr el procedimiento más adecuado o
que más le convenga.
Simulaciones situacionales: Las simulaciones situacionales tratan con las
actitudes y el comportamiento que deben asumir las personas ante una
situación o problemática. A diferencia de las simulaciones de procedimientos,
las cuales enseñan una serie de reglas, las simulaciones situacionales
permiten a las personas tomar diferentes roles ante una situación y explorar
sus efectos [9].
GAMA
GAMA es una plataforma de simulación, cuyo objetivo es proporcionar a los
expertos en el terreno, a los modeladores y a los informáticos un entorno completo
de desarrollo de modelos y simulaciones para construir simulaciones multiagente
espacialmente explícitas. Ha sido desarrollada por primera vez por el equipo de
investigación vietnamita-francesa MSI (ubicado en el IFI, Hanoi, y que forma parte de
la Unidad de Investigación Internacional del IRD/SU UMMISCO) de 2007 a 2010, y
ahora la desarrolla un consorcio de socios académicos e industriales encabezado por
UMMISCO, entre los que se encuentran la Universidad de Rouen, Francia, la
Universidad de Toulouse 1, Francia, la Universidad de Orsay, Francia, la Universidad
de Can Tho, Vietnam, la Universidad Nacional de Hanoi, EDF R&D, Francia, y CEA
LISC, Francia [10].
Algunas de las características que ofrece GAMA son:
Un completo lenguaje de modelado, GAML, para agentes y entornos de
modelado
Una amplia y extensible biblioteca de primitivas (movimiento del agente,
comunicación, funciones matemáticas, características gráficas, ...)
Una reproducibilidad multiplataforma de los experimentos y simulaciones
Un poderoso subsistema de dibujo y trazado declarativo
Una interfaz de usuario flexible basada en la plataforma Eclipse
Un conjunto completo de herramientas de lotes, que permiten una exploración
31
sistemática o "inteligente" de los modelos de parámetros de los espacios
GAML
Los modelos que los usuarios quieren simular en GAMA tienen que estar
escritos en un lenguaje especial, llamado GAML (abreviatura de GAma Modeling
Language).
GAML nace de la necesidad de tener una forma declarativa de alto nivel para
definir y reutilizar las estructuras que se encuentran en casi todos los modelos
basados en agentes.
Aunque esta elección requiere que los usuarios aprendan un nuevo lenguaje
de programación (o mejor dicho, de modelado), todo se ha hecho en GAMA para
apoyar una corta curva de aprendizaje, de manera que puedan llegar a ser casi
autónomos en un tiempo limitado (las medidas informales tomadas en los diferentes
eventos centrados en GAMA han demostrado que un día es suficiente para adquirir
suficientes habilidades en la escritura de modelos completos en GAML) [11].
Lenguaje Unificado de Modelado
El Lenguaje Unificado de Modelado (UML) fue creado para forjar un lenguaje de
modelado visual común y semántica y sintácticamente rico para la arquitectura, el
diseño y la implementación de sistemas de software complejos, tanto en estructura
como en comportamiento. UML tiene aplicaciones más allá del desarrollo de
software, p. ej., en el flujo de procesos en la fabricación.
Es comparable a los planos usados en otros campos y consiste en diferentes tipos
de diagramas. En general, los diagramas UML describen los límites, la estructura y el
comportamiento del sistema y los objetos que contiene.
UML no es un lenguaje de programación, pero existen herramientas que se pueden
usar para generar código en diversos lenguajes usando los diagramas UML. UML
guarda una relación directa con el análisis y el diseño orientados a objetos [12].
32
Conceptos de modelado especificados por UML
El desarrollo de sistemas se centra en tres modelos generales de sistemas
diferentes:
Funcionales: Se trata de diagramas de casos de uso que describen la
funcionalidad del sistema desde el punto de vista del usuario.
De objetos: Se trata de diagramas de clases que describen la estructura del
sistema en términos de objetos, atributos, asociaciones y operaciones.
Dinámicos: Los diagramas de interacción, los diagramas de máquina de
estados y los diagramas de actividades se usan para describir el
comportamiento interno del sistema.
Estos modelos de sistemas se visualizan a través de dos tipos diferentes de
diagramas: estructurales y de comportamiento [12].
Tipos de diagramas UML
UML usa elementos y los asocia de diferentes formas para formar diagramas que
representan aspectos estáticos o estructurales de un sistema, y diagramas de
comportamiento, que captan los aspectos dinámicos de un sistema [12].
Diagramas UML estructurales
Diagrama de clases: El diagrama UML más comúnmente usado, y la base
principal de toda solución orientada a objetos. Las clases dentro de un
sistema, atributos y operaciones, y la relación entre cada clase. Las clases se
agrupan para crear diagramas de clases al crear diagramas de sistemas
grandes.
33
Imagen 2.3
Fuente: Google Images
Diagrama de componentes: Muestra la relación estructural de los elementos
del sistema de software, muy frecuentemente empleados al trabajar con
sistemas complejos con componentes múltiples. Los componentes se
comunican por medio de interfaces.
Imagen 2.4
Fuente: Google Images
Diagrama de estructura compuesta: Los diagramas de estructura compuesta
34
se usan para mostrar la estructura interna de una clase.
Imagen 2.5
Fuente: Google Images
Diagrama de implementación: Ilustra el hardware del sistema y su software.
Útil cuando se implementa una solución de software en múltiples máquinas
con configuraciones únicas.
Imagen 2.6
Fuente: Google Images
Diagrama de objetos: Muestra la relación entre objetos por medio de ejemplos
del mundo real e ilustra cómo se verá un sistema en un momento dado. Dado
35
que los datos están disponibles dentro de los objetos, estos pueden usarse
para clarificar relaciones entre objetos.
Imagen 2.7
Fuente: Google Images
Diagrama de paquetes: Hay dos tipos especiales de dependencias que se
definen entre paquetes: la importación de paquetes y la fusión de paquetes.
Los paquetes pueden representar los diferentes niveles de un sistema para
revelar la arquitectura. Se pueden marcar las dependencias de paquetes para
mostrar el mecanismo de comunicación entre niveles [12].
Imagen 2.8
36
Fuente: Google Images
Diagramas UML de comportamiento
Diagramas de actividades: Flujos de trabajo de negocios u operativos
representados gráficamente para mostrar la actividad de alguna parte o
componente del sistema. Los diagramas de actividades se usan como una
alternativa a los diagramas de máquina de estados.
Imagen 2.9
Fuente: Google Images
Diagrama de comunicación: Similar a los diagramas de secuencia, pero el
enfoque está en los mensajes que se pasan entre objetos. La misma
información se puede representar usando un diagrama de secuencia y objetos
diferentes.
37
Imagen 2.10
Fuente: Google Images
Diagrama de panorama de interacciones: Hay siete tipos de diagramas de
interacciones. Este diagrama muestra la secuencia en la cual actúan.
Imagen 2.11
Fuente: Google Images
Diagrama de secuencia: Muestra cómo los objetos interactúan entre sí y el
orden de la ocurrencia. Representan interacciones para un escenario
38
concreto.
Imagen 2.12
Fuente: Google Images
Diagrama de máquina de estados: Similar a los diagramas de actividades,
describen el comportamiento de objetos que se comportan de diversas formas
en su estado actual.
Imagen 2.13
Fuente: Google Images
Diagrama de temporización: Al igual que en los diagramas de secuencia, se
39
representa el comportamiento de los objetos en un período de tiempo dado. Si
hay un solo objeto, el diagrama es simple. Si hay más de un objeto, las
interacciones de los objetos se muestran durante ese período de tiempo
particular.
Imagen 2.14
Fuente: Google Images
Diagrama de caso de uso: Representa una funcionalidad particular de un
sistema. Se crea para ilustrar cómo se relacionan las funcionalidades con sus
controladores (actores) internos/externos [12].
Imagen 2.15
Fuente: Google Images
40
CAPÍTULO III. DISEÑO Y DESARROLLO
41
Diseño
Como se mencionaba anteriormente, para diseñar a los agentes de este proyecto
se utilizó la metodología BDI (Beliefs, Desires, Intentions), con la cual se definieron
las metas y acciones que realizarían nuestros agentes a lo largo de la simulación.
Las siguientes plantillas se utilizaron para simular cómo se propagaría un virus en
una sección de una playa. En esta simulación interactúan tres agentes distintos:
Paciente infectado (Irresponsable)
Paciente sano (Responsable)
Paciente sano (Irresponsable)
A continuación, se muestra el diseño de cada agente, mencionando a través de
una tabla sus creencias, deseos e intenciones, así como las interacciones que los
mismos podrán realizar dentro de la simulación.
Diseño BDI
Paciente infectado (Irresponsable)
El primer agente diseñado lleva el nombre de “Paciente infectado
(Irresponsable)”. Su función dentro de la simulación es propagar el virus sin ningún
tipo de protección, es decir, sin tomar las medidas necesarias para evitar la
propagación del mismo.
Como creencia, el agente conocerá la posición de la sombrilla en la que se
encuentra descansando en la playa, espacio al que puede ir y venir a conveniencia.
Su deseo es contagiar personas y como intención busca el acercarse a menos de
1.5m de distancia de otra persona. Esta distancia es la distancia de seguridad
recomendada por las autoridades de salud para disminuir los contagios por virus.
Como interacciones, el agente podrá toser, estornudar y escupir, acciones que
favorecerán la infección dentro de la simulación.
42
Beliefs (Conocimiento
previo)
Desires (Meta) Intentions (Cómo)
Posición de la
sombrilla
Contagiar personas Acercarse a menos de 1.5m de otra
persona
No usar cubrebocas
Imagen 3.1
Fuente: Del autor
Interacciones
o Toser
o Estornudar
o Escupir
Paciente sano (Responsable)
El segundo agente diseñado lleva el nombre de “Paciente sano
(Responsable)”. Su función dentro de la simulación es intentar permanecer sano el
mayor tiempo posible tomando las medidas de seguridad recomendadas por las
autoridades de salud.
Como creencia, el agente conocerá la posición de la sombrilla en la que se
encuentra descansando en la playa, espacio al que puede ir y venir a conveniencia.
Su deseo es evitar contagiarse y como intención busca el mantener una distancia de
al menos 1.5m de otra persona. Asimismo, busca usar cubre bocas, usar
antibacterial y evitar compartir vasos o cubiertos.
Como interacciones el agente podrá ponerse y usar cubrebocas, lavarse las
manos, usar careta, respetar la distancia de seguridad y contagiarse.
Beliefs (Conocimiento Desires (Meta) Intentions (Cómo)
43
previo)
Posición de la sombrilla
Evitar
contagiarse
Mantener una distancia de 1.5m de
otra persona
Usar cubrebocas
No compartir vaso
No compartir cubiertos
Usar antibacterial
Imagen 3.2
Fuente: Del autor
Interacciones
o Ponerse cubrebocas
o Usar cubrebocas
o Lavarse las manos
o Usar careta
o Respetar distancia
o Contagiarse
Paciente sano (Irresponsable)
El último agente diseñado lleva el nombre de “Paciente sano (Irresponsable)”.
Su función dentro de la simulación es ser un agente propenso a infectarse debido a
la falta de medidas de seguridad.
Como creencia, el agente conocerá la posición de la sombrilla en la que se
encuentra descansando en la playa, espacio al que puede ir y venir a conveniencia.
Su deseo es no respetar las medidas preventivas para evitar la infección y como
intención busca no mantener una distancia de al menos 1.5m de otra persona. El
agente tampoco busca usar cubre bocas, no usa antibacterial y no tiene problema al
44
compartir vasos o cubiertos.
Como interacciones el agente no utilizará cubrebocas y podrá acercarse a
cualquier otro agente sin ninguna precaución.
Beliefs (Conocimiento
previo)
Desires (Meta) Intentions (Cómo)
Posición de la
sombrilla
No respetar medidas
preventivas
No mantener una distancia de
1.5m de otra persona
No usar cubrebocas
Compartir vaso
Compartir cubiertos
No usar antibacterial
Imagen 3.3
Fuente: Del autor
Interacciones
o No usar cubrebocas
o Acercarse a otro agente
Historias de usuario
Al tratarse de un proyecto de software, se diseñaron algunas historias de
usuario con la finalidad de validar las actividades que realizaría el agente a lo largo
de la simulación. A continuación, se muestran algunos ejemplos de las historias de
usuario realizadas durante el diseño de la simulación.
45
Historia de usuario #1 – Paciente sano usa cubreboca
La primera historia de usuario define el requerimiento de que el paciente sano
use cubrebocas para reducir el riesgo de infección, tal como se mencionaba en su
diseño con la arquitectura BDI.
ID: 1 Nombre: Paciente sano usa cubreboca
Como: Paciente sano
Quiero: Usa cubrebocas
Para poder: Evitar ser contagiado
Descripción:
El paciente sano usa cubrebocas para reducir el riesgo de infección.
Validación:
Valor:
Prioridad: Estimación:
Imagen 3.4
Fuente: Del autor
Historia de usuario #2 – Paciente infectado usa cubreboca
En la segunda historia de usuario interactúa el paciente infectado con su
entorno. El paciente utiliza cubreboca con la finalidad de evitar infectar las superficies
que lo rodean.
ID: 2 Nombre: Paciente infectado usa cubreboca
Como: Paciente infectado
Quiero: Usa cubrebocas
Para poder: Evitar contaminar superficies
46
Descripción:
El paciente sano usa cubrebocas para evitar contaminar las superficies que lo rodean.
Validación:
Valor:
Prioridad:
Estimación:
Imagen 3.5
Fuente: Del autor
Historia de usuario #3 – Paciente no respeta distancia de seguridad
La historia de usuario #3 describe a un paciente que no respeta la distancia de
seguridad. En esta, el paciente se acerca a menos de 1.5m de distancia de otro
paciente, cualquiera de los dos pacientes puede o no estar infectados.
ID: 3 Nombre: Paciente no respeta distancia de seguridad
Como: Paciente infectado
Quiero: Se acerca a menos de 1.5m de distancia
Para poder: Aumentar el riesgo de contagio
Descripción:
El paciente sano no respeta la distancia de seguridad y aumenta el riesgo de contagio
Validación:
Valor:
Prioridad:
Estimación:
Imagen 3.6
Fuente: Del autor
47
Historia de usuario #4 – Paciente sano comparte vaso con paciente infectado
La historia de usuario #4 describe a un paciente sano que comparte vaso con
una persona infectada, lo cual aumenta el riesgo de contagio del virus.
ID: 4 Nombre: Paciente sano comparte vaso con paciente infectado
Como: Paciente infectado
Quiero: Comparte vaso con paciente infectado
Para poder: Aumentar riesgo de contagio
Descripción:
El paciente sano comparte el vaso con una persona infectada y aumenta el riesgo de contagio
Validación:
Valor:
Prioridad:
Estimación:
Imagen 3.7
Fuente: Del autor
Historia de usuario #5 – Paciente infectado tose sin usar cubrebocas
La última historia de usuario describe a un paciente infectado que tose sin
utilizar cubrebocas. El paciente tose, creando un área de infección de 1.5m de
diámetro alrededor de él.
ID: 5 Nombre: Paciente infectado tose sin usar cubrebocas
Como: Paciente infectado
Quiero: Tose
Para poder: Contaminar área de 1.5m de diámetro
Descripción:
El paciente infectado tose, lo que permite contaminar un área de 1.5m de diámetro alrededor de él
48
Validación:
Valor:
Prioridad:
Estimación:
Imagen 3.8
Fuente: Del autor
Diagramas de caso de uso
Una manera de representar las interacciones de nuestros agentes es mediante el
uso de los diagramas de caso de uso, en donde se detalla cómo se va a comportar
cada uno en su entorno.
Caso de uso “Paciente infectado (Irresponsable)”
Para el primer tipo de agente, llamado “Paciente infectado (Irresponsable)” se creó el
siguiente diagrama. Podemos ver a nuestro actor principal, que es nuestro agente,
cuyo caso de uso principal será el de infectar el área. Para esto, nuestro actor puede
lograrlo mediante tres casos de uso distintos (Conocidos como interacciones en el
modelo BDI) que son:
Toser.
Estornudar.
Escupir.
Nuestro sistema será desarrollado en la playa, que es donde se estará desarrollando
nuestra simulación.
49
Imagen 3.9
Fuente: Del autor
Caso de uso “Paciente sano (Responsable)”
Para el segundo tipo de agente, llamado “Paciente sano (Responsable)” se creó
el siguiente diagrama. Podemos ver a nuestro actor principal, que es nuestro agente,
con tres casos de uso principales:
Desinfectar.
Contagiarse.
Seguir las medidas de seguridad.
Para lograr el caso de uso llamado desinfectar, nuestro actor puede lograrlo
mediante tres casos de uso distintos:
Lavarse las manos.
Usar cubrebocas.
50
Limpiar superficies.
El tercer caso de uso, llamado seguir las medidas de seguridad, puede ser cumplido
mediante cualquiera de los siguientes tres casos de uso:
Usar cubrebocas.
Usar careta.
Mantener una distancia de 1.5m.
Nuestro sistema será desarrollado en la playa, que es donde se estará desarrollando
nuestra simulación.
Imagen 3.10
Fuente: Del autor
51
Caso de uso “Paciente sano (Irresponsable)”
Nuestro tercer tipo de agente, llamado “Paciente sano (Irresponsable)” tiene los
siguientes casos de uso. Nuestro actor tiene tres casos de uso muy similares a los
del agente “Paciente sano (Irresponsable)”, los cuales son:
Infectar áreas y superficies.
Contagiarse.
No seguir las medidas de seguridad.
Para lograr el caso de uso llamado infectar áreas y superficies, nuestro actor
puede lograrlo mediante tres casos de uso distintos que son:
No lavarse las manos.
No usar cubrebocas.
Compartir desechables.
El tercer caso de uso, llamado no seguir las medidas de seguridad, puede ser
cumplido mediante cualquiera de los siguientes tres casos de uso:
No usar cubrebocas.
No usar careta.
No mantener una distancia de 1.5m.
Nuestro sistema será desarrollado en la playa, que es donde se estará desarrollando
nuestra simulación.
52
Imagen 3.11
Fuente: Del autor
Desarrollo
Para el desarrollo de la simulación se utilizó la plataforma GAMA, así como el
lenguaje GAML para la programación de los agentes. Se tomó una simulación de
ejemplo por parte de GAMA para adaptarla al caso de estudio planteado en este
proyecto. A continuación, se describe el modelo y sus variables.
Definición de variables globales
En la función global, se definen las variables de inicio de la simulación. En
este caso se inició con una población de 2147 agentes en total, siendo 5 de ellos
agentes infectados. Se asigna a la variable step el tamaño del paso que dará cada
agente al moverse.
Por otra parte, se hace un cálculo para los agentes infectados y otro para los
53
agentes sanos, actualizando cada variable dependiendo de cómo se vaya
propagando el virus entre los agentes.
Por último, se le indica a la simulación cuándo terminar. En este caso, la
simulación terminará una vez que la tasa de infección llegue a 1.0.
global { int poblacion_inicial <- 2147; int infectados_inicial <- 5; float step <- 0.05 #mn; geometry shape<-square(1500 #m); int infectados_total <- infectados_inicial update: poblacion count (each.contagiado); int sanos_total <- poblacion_inicial - infectados_inicial update: poblacion_inicial - infectados_total; float tasa_infeccion update: infectados_total/poblacion_inicial; init{ create poblacion number:poblacion_inicial; ask infectados_inicial among poblacion { contagiado <- true; } } reflex terminar when: tasa_infeccion = 1.0 { do pause; } }
Creación de agentes
Para crear a nuestros agentes se utiliza la función species. En este caso se
crea un agente llamado población, que serán los que interactúen a lo largo de la
simulación. Se les asigna la habilidad de movimiento, especificando su velocidad en
la variable speed. Asimismo, el agente de población tendrá dos estados, contagiado
o no contagiado.
Para que el agente pueda ser contagiado, se agrega la condición con la que
interactuarán ambos agentes de población, en donde si la distancia entre cada uno
es de 1.5m, el agente sano cambiará su estado a contagiado.
Por último, se les asigna un aspecto a los agentes. La forma general para la
población será un círculo que cambiará su color a verde si está sano y rojo si se
54
encuentra infectado.
species poblacion skills:[moving]{ float speed <- (2 + rnd(3)) #km/#h; bool contagiado <- false; reflex move{ do wander; } reflex infect when: contagiado{ ask poblacion at_distance 1.5 #m { if flip(0.05) { contagiado <- true; } } } aspect circle { draw circle(10) color:contagiado ? #red : #green; } }
Definición del experimento
Como herramienta extra, GAMA nos permite crear un monitor para llevar un
conteo de los cambios que va sufriendo la simulación. En este caso se crea una tabla
que irá mapeando tanto a los agentes sanos como a los infectados.
experiment main type: gui { parameter "Personas infectadas al iniciar: " var: infectados_inicial min: 1 max: 2147; output { monitor "Tasa de infeccion: " value: tasa_infeccion; display map { species poblacion aspect:circle; } display chart_display refresh: every(10 #cycles) { chart "Infección" type: series { data "Sanos" value: sanos_total color: #green; data "Infectados" value: infectados_total color: #red; } } } }
55
Modelo de propagación de virus
A continuación se muestra el modelo completo de la simulación.
model propagacion global { int poblacion_inicial <- 2147; int infectados_inicial <- 5; float step <- 0.05 #mn; geometry shape<-square(1500 #m); int infectados_total <- infectados_inicial update: poblacion count (each.contagiado); int sanos_total <- poblacion_inicial - infectados_inicial update: poblacion_inicial - infectados_total; float tasa_infeccion update: infectados_total/poblacion_inicial; init{ create poblacion number:poblacion_inicial; ask infectados_inicial among poblacion { contagiado <- true; } } reflex terminar when: tasa_infeccion = 1.0 { do pause; } } species poblacion skills:[moving]{ float speed <- (2 + rnd(3)) #km/#h; bool contagiado <- false; reflex move{ do wander; } reflex infect when: contagiado{ ask poblacion at_distance 1.5 #m { if flip(0.05) { contagiado <- true; } } } aspect circle { draw circle(10) color:contagiado ? #red : #green; } } experiment main type: gui { parameter "Personas infectadas al iniciar: " var: infectados_inicial min: 1 max: 2147;
56
output { monitor "Tasa de infeccion: " value: tasa_infeccion; display map { species poblacion aspect:circle; } display chart_display refresh: every(10 #cycles) { chart "Infección" type: series { data "Sanos" value: sanos_total color: #green; data "Infectados" value: infectados_total color: #red; } } } }
Resultados
Como modelo de prueba, se tomó el ejemplo “Luneray flu” que se encuentra
en la documentación de GAMA. Una vez modificadas las variables y adaptadas al
caso de prueba seleccionado (Propagación de virus COVID-19), se ejecutó para
observar el comportamiento de los agentes.
En la figura 3.1, se puede observar la simulación antes de ser ejecutada. La
simulación cuenta con 2142 personas “sanas” (Puntos verdes) y 5 personas
“infectadas” (Puntos rojos) en el segundo 0.
57
Imagen 3.12
Fuente: Del autor
Una vez iniciada la simulación y después de 5002 ciclos, la tasa de infección
llegó a 1.0, por lo que la misma se detuvo.
58
Imagen 3.13
Fuente: Del autor
Al mismo tiempo que la simulación se llevaba a cabo, se podía observar el
siguiente monitor. En donde se muestra el cambio de estado de los agentes de no
infectados a infectados, así como el tiempo que les tomó infectarse.
59
Imagen 3.14
Fuente: Del autor
Conclusiones
La ingeniería de software basada en agentes y el uso de un framework para
representar escenarios de comportamientos (simulaciones) permiten visualizar y
proponer alternativas de solución a diversos problemas en la sociedad. Es por esto
que la ciencia e investigación se ha visto obligada también a modificar sus técnicas
de experimentación, creando nuevas herramientas o utilizando las ya existentes.
Dentro de estas herramientas se encuentra la simulación y el uso de agentes
para diseñar entornos de acuerdo a las necesidades del experimento tal como se
describió en esta investigación para representar el nivel de propagación de un virus,
de acuerdo al uso de reglas definidas por parámetros. GAMA es una herramienta
muy útil para esto, ya que acepta diferentes tipos de arquitecturas para la creación
de los agentes en sus simulaciones, permitiendo al usuario crear y diseñar sus
agentes de la manera que considere más viable.
El uso apropiado de metodologías, métodos, técnicas, herramientas y el
adecuado análisis (conceptualización), diseño e implementación bajo el enfoque de
60
una arquitectura de agentes, permiten en diversos entornos y en diversas
dimensiones (pequeñas y grandes) o que siguen un flujo cambiante en su
comportamiento, simular escenarios previsores para diversos casos de estudio en la
sociedad sin necesidad de poner en riesgo vidas humanas.
61
Bibliografía
[1] R. S. Pressman, «Ingeniería de software,» de Ingeniería del software. Un
enfoque práctico., México, D.F, McGraw-Hill, 2010, pp. 11 - 12.
[2] R. S. Pressman, «El proceso del software,» de Ingeniería de software un enfoque
práctico, México, D. F, McGraw Hill, 2010, pp. 12-13.
[3] R. S. Pressman, «Modelos de proceso prescriptivo,» de Ingeniería del software.
Un enfoque práctico, México, D.F., McGraw Hill, 2010, pp. 33-43.
[4] R. S. Pressman, «Modelos de proceso especializado,» de Ingeniería del
software. Un enfoque práctico, México, D.F., McGraw Hill, 2010, p. 43.
[5] «Sistemas Multiagentes,» EcuRed, [En línea]. Available:
https://www.ecured.cu/Sistemas_Multiagentes.
[6] G. H. T. &. F. Raul, «Revisión: tecnologia de agentes de software,» 1999. [En
línea]. Available: https://www.scielo.br/pdf/ci/v28n3/v28n3a8.pdf.
[7] F. B. &. G. P. Carolina Cardoso, «Modelos Basados en Agentes (MBA):
definición, alcances y limitaciones,» [En línea]. Available:
http://www.iai.int/admin/site/sites/default/files/uploads/2014/03/Cardoso_et_al_Ma
nual_ABM.pdf.
[8] J. M. Corchado, «Modelos y Arquitecturas de Agente,» [En línea]. Available:
https://bisite.usal.es/archivos/c1_1_0.pdf.
[9] Anónimo, «Definición de simulación,» [En línea]. Available:
http://catarina.udlap.mx/u_dl_a/tales/documentos/lcp/texson_a_gg/capitulo2.pdf.
[10
]
Anónimo, «Introducción,» GAMA-Platform, [En línea]. Available: https://gama-
platform.github.io/wiki/Overview.
62
[11
]
Anónimo, «GAML,» GAMA-Platform, [En línea]. Available: https://gama-
platform.github.io/wiki/GamlLanguage.
[12
]
Anónimo, «Qué es el lenguaje unificado de modelado (UML),» Lucidchart, [En
línea]. Available: https://www.lucidchart.com/pages/es/que-es-el-lenguaje-
unificado-de-modelado-uml.
[13
]
G. Choque Aspiazu, «Ingeniería del Software basada en Agentes,» Mente
Errabunda, 12 05 2008. [En línea]. Available:
http://menteerrabunda.blogspot.com/2008/06/ingeniera-del-software-basada-
en.html.
Glosario
Agente
La palabra "Agente" se refiere a todo ente que posee la habilidad, capacidad y
autorización para actuar en nombre de otro.
Sistema multiagente
Sistema modelado como una colección de entidades autónomas de toma de decisión
llamadas agentes, donde cada agente evalúa su situación y toma decisiones sobre la
base de un conjunto de reglas de decisión.
Ingeniería de software
Rama de la ingeniería que estudia todo lo relacionado con la informática o sistemas
de computación, con una orientación metódica, ordenada y cuantificable al
incremento, ejecución y conservación del software.
Metodología BDI
Es una metodología para el diseño de Sistemas Multi-Agente. Un agente percibe a
través de sus sensores una serie de estímulos procedentes de su entorno, los cuales
63
modifican el modelo del mundo que tiene el agente o sea sus Creencias (Beliefs)
acerca del mundo, tomará decisiones gobernadas por sus Deseos (Desires) y tendrá
que valerse por una serie de Intenciones (Intentions).
Simulación
La Simulación es un acto que consiste en imitar o fingir que se está realizando una
acción cuando en realidad no se está llevando a cabo.
UML
Lenguaje de modelado de sistemas de software más conocido y utilizado en la
actualidad. Es un lenguaje gráfico para visualizar, especificar, construir y documentar
un sistema de software.
Diagrama de caso de uso
Diagrama mediante el cual se representan procesos empresariales, así como
sistemas y procesos de programación orientada a objetos.
Historia de usuario
Las historias de usuario son descripciones cortas y simples de una característica
contada desde la perspectiva de la persona que desea la nueva capacidad,
generalmente un usuario o cliente del sistema.