Tesis Final AntokoletzV4

Facultad de Ciencias de la Administración
Carrera: Ingeniería de Sistemas
Tesis de grado.
Título:
“Metodología para el desarrollo de sistemas multi-agente basado
en fichas”
Director de tesis: Prof. Ing. Daniela Diaz

Alumno: Daniel Víctor José Antokoletz Huerta
Mesa examinadora:
Presidente: Ing. BRESSANO, Mario
Vocal 1: Ing. MELONI, Brenda
Vocal 2: Ing. DIAZ, Daniela
Año 2019
Historia de Revisión del Documento
Fecha Versión Descripción Autor
11/08/2017 1.0.0 Creación Daniel Antokoletz Huerta
20/11/2018 2.0.0 Correcciones sugeridas por la tutora. Daniel Antokoletz Huerta
14/02/2019 3.0.0 Correcciones sugeridas por la tutora. Daniel Antokoletz Huerta

Dedicatoria
Dedico éste trabajo a Mónica, mi esposa y

a Erik, mi hijo, que me inspiran a seguir
adelante cuando fallan las fuerzas. Entre
los tres somos un sistema multi-agente en
toda regla.
Agradecimientos
Por lo pronto debo agradecer la paciencia y la guía de mi tutora Ing. Daniela Diaz, los
empujones para que no abandone de la Mg. Ing. Brenda Meloni, que buscó siempre
allanarme el trabajo; y la paciencia de mi familia que siempre me apoya.
Índice
Historia de Revisión del Documento ____________________________________________ 2

Dedicatoria ________________________________________________________________ 3
Agradecimientos ___________________________________________________________ 4
Índice ____________________________________________________________________ 5
Índice de ilustraciones _______________________________________________________ 9
Índice de tablas ___________________________________________________________ 11
Resumen _________________________________________________________________ 13
Palabras clave ____________________________________________________________ 14
Listado de símbolos y convenciones ___________________________________________ 15
1. Introducción __________________________________________________________ 17
1.1. Motivación del proyecto __________________________________________________ 20
1.2. Alcances del proyecto ____________________________________________________ 21
1.3. Organización del trabajo __________________________________________________ 22
1.4. Mapa Conceptual ________________________________________________________ 23
PARTE I - Marco teórico: De los agentes y cómo se reúnen en sistemas multi-agentes. __ 24
Propósito de la sección __________________________________________________________ 25
2. De los agentes ________________________________________________________ 25
2.1. Introducción ____________________________________________________________ 25
2.2. ¿Constituyen los agentes un nuevo paradigma de desarrollo de software? __________ 27
2.2.1. Agentes vs. Objetos _____________________________________________________________ 28
2.3. Mitos y verdades de la programación con Agentes _____________________________ 29
3. El concepto de agente __________________________________________________ 30
3.1. ¿Qué es un agente? ______________________________________________________ 30
4. De cómo los agentes se reúnen y forman sistemas multi-agente ________________ 38
4.1. Introducción ____________________________________________________________ 38
4.2. Comunicación entre agentes _______________________________________________ 38
4.2.1. Introducción___________________________________________________________________ 38
4.2.2. ¿Qué es comunicar? ____________________________________________________________ 39
4.2.3. Formas de comunicación entre los agentes. _________________________________________ 39
4.3. Coordinación en sistemas multi-agente ______________________________________ 46
4.3.1. Introducción___________________________________________________________________ 46
4.3.2. Tipos de relaciones entre los agentes_______________________________________________ 46
5. Metodologías de desarrollo de sistemas multiagente _________________________ 47

5.1. Introducción ____________________________________________________________ 47
5.1.1. Introducción___________________________________________________________________ 47
5.2. Marco de análisis de metodologías agentes ___________________________________ 47
5.2.1. Introducción___________________________________________________________________ 47
5.2.2. Criterios a tener en cuenta en la elección de una metodología. __________________________ 47
5.3. Metodologías de desarrollo de sistemas multi-agentes. _________________________ 48
5.3.1. Introducción___________________________________________________________________ 48
5.3.2. Metodología: AAII/BDI __________________________________________________________ 48
5.3.3. Metodología: Cassiopeia _________________________________________________________ 49
5.3.4. Metodología: CommonKADS _____________________________________________________ 50
5.3.5. Metodología: CoMoMAS _________________________________________________________ 52
5.3.6. Metodología: DESIRE ____________________________________________________________ 53
5.3.7. Metodología: Gaia ______________________________________________________________ 54
5.3.8. Metodología: INGENIAS _________________________________________________________ 58
5.3.9. Metodología: MaSE _____________________________________________________________ 59
5.3.10. Metodología: MASSIVE ________________________________________________________ 60
5.3.11. Metodología: MESSAGE _______________________________________________________ 62
5.3.12. Metodología: Prometheus _____________________________________________________ 64
5.3.13. Metodología: RETSINA ________________________________________________________ 66
5.3.14. Metodología: SONIA __________________________________________________________ 69
5.3.15. Metodología: TROPOS ________________________________________________________ 70
5.3.16. Metodología: ZEUS ___________________________________________________________ 72
PARTE II: Desarrollo de la metodología y diseño de una aplicación.__________________ 75

6. Metodología MeDeSMAGF de desarrollo de sistemas multiagentes. _____________ 76
6.1. Introducción ____________________________________________________________ 76
6.1.1. Propósito de la sección __________________________________________________________ 76
6.1.2. Alcances de la sección ___________________________________________________________ 76
6.1.3. Notación______________________________________________________________________ 77
6.1.4. Definiciones y conceptos_________________________________________________________ 77
6.1.4.1. Objetivo____________________________________________________________________ 77
6.1.4.2. Entorno ____________________________________________________________________ 80
6.1.4.3. Actor ______________________________________________________________________ 82
6.1.4.4. Rol ________________________________________________________________________ 83
6.1.4.5. Agente _____________________________________________________________________ 85
6.1.4.6. Plan _______________________________________________________________________ 86
6.1.4.7. Protocolo___________________________________________________________________ 87
6.1.4.8. Acciones: ___________________________________________________________________ 90
6.1.4.9. Riesgo: _____________________________________________________________________ 91
6.1.4.10. Conocimientos: ______________________________________________________________ 92
6.1.4.11. Pruebas unitarias: ____________________________________________________________ 94
6.2. Descripción de los modelos y diagramas _____________________________________ 95
6.2.1. Modelo de entorno _____________________________________________________________ 95
6.2.2. Modelo de objetivos ____________________________________________________________ 96
6.2.3. Modelo de roles________________________________________________________________ 97
6.2.4. Modelo de conocimientos _______________________________________________________ 97
6.2.5. Modelo interno de agentes _______________________________________________________ 98
6.2.6. Diagramas de secuencia _________________________________________________________ 99
6.2.7. Diagrama de estados ___________________________________________________________ 100
6.2.8. Diagrama de actividades ________________________________________________________ 102
6.3. Pasos a seguir e hitos de la metodología ____________________________________ 107
6
6.3.1. Hitos de la metodología. ________________________________________________________ 107
6.3.2. Esquema de desarrollo. _________________________________________________________ 108
6.3.3. Captura de requerimientos ______________________________________________________ 109
6.3.4. Análisis ______________________________________________________________________ 114
6.3.5. Diseño ______________________________________________________________________ 117
6.3.6. Desarrollo o codificación. _______________________________________________________ 119
6.3.7. Pruebas _____________________________________________________________________ 120
7. Ejemplo de aplicación de la metodología MeDeSMAGF ______________________ 122

7.1. Introducción ___________________________________________________________ 122
7.1.1. Propósito de la sección _________________________________________________________ 122
7.1.2. Alcance de la sección ___________________________________________________________ 122
7.2. Captura de requisitos para una IA para el juego SPIA-Wari ______________________ 122
7.2.1. Introducción__________________________________________________________________ 122
7.2.2. Desarrollo ___________________________________________________________________ 123
7.2.2.1. Pautas que debe cumplir la IA _________________________________________________ 123
7.2.2.2. Determinar los objetivos del sistema ___________________________________________ 123
7.2.2.3. Determinar entorno _________________________________________________________ 124
7.2.2.4. Determinar salidas del sistema ________________________________________________ 125
7.2.2.5. Determinar entradas al sistema ________________________________________________ 125
7.2.2.6. Bosquejar los roles responsables de entradas y salidas _____________________________ 126
7.2.2.7. Determinar los recursos que necesita el sistema. __________________________________ 127
7.2.2.8. Buscar restricciones _________________________________________________________ 127
7.2.2.9. Buscar riesgos y mitigación de los mismos _______________________________________ 128
7.2.2.10. Generar modelo de entorno __________________________________________________ 128
7.2.2.11. Generar el modelo inicial de objetivos __________________________________________ 129
7.3. Análisis de una IA para el juego SPIA-Wari ___________________________________ 129
7.3.1. Introducción__________________________________________________________________ 129
7.3.2. Desarrollo ___________________________________________________________________ 129
7.3.2.1. Refinamiento de objetivos ____________________________________________________ 130
7.3.2.2. Definición de planes _________________________________________________________ 130
7.3.2.3. Asociación de planes a roles __________________________________________________ 137
7.3.2.4. Establecer las necesidades de conocimiento interno de los roles _____________________ 138
7.3.2.5. Determinar las necesidades de comunicaciones entre roles. ________________________ 139
7.3.2.6. Generar modelo de roles _____________________________________________________ 142
7.3.2.7. Modificar el modelo de objetivos ______________________________________________ 142
7.4. Diseño para una IA para el juego SPIA-Wari __________________________________ 143
7.4.1. Introducción__________________________________________________________________ 143
7.4.2. Desarrollo ___________________________________________________________________ 143
7.4.2.1. Diseñar las unidades de conocimiento. __________________________________________ 143
7.4.2.2. Diseñar los agentes. _________________________________________________________ 143
7.4.2.3. Diseñar los casos de prueba unitarios.___________________________________________ 145
7.4.2.3.1. entFrontera _____________________________________________________________ 145
7.4.2.3.2. entCoordinador. __________________________________________________________ 146
7.4.2.3.3. entAgujero. _____________________________________________________________ 147
7.4.2.4. Diseño de los modelos de conocimientos. ________________________________________ 147
7.4.2.5. Generar el modelo interno de los agentes. _______________________________________ 148
7.4.2.5.1. entFrontera. _____________________________________________________________ 148
7.4.2.5.2. entCoordinador. __________________________________________________________ 149
7.4.2.5.3. entAgujero. _____________________________________________________________ 149
7.4.2.5.4. Modelo interno de agentes. ________________________________________________ 150
8. Conclusiones y próxima línea de investigación. ______________________________ 151
7
9. Referencias/Bibliografía _______________________________________________ 153
10. Anexos ___________________________________________________________ 159
10.1. Códigos de transmisión. __________________________________________________ 159
10.2. Reglas del juego WARI. __________________________________________________ 161
10.2.1. Material ___________________________________________________________________ 162
10.2.2. Objetivo___________________________________________________________________ 162
10.2.3. Reglas ____________________________________________________________________ 162
10.2.4. Tablero ___________________________________________________________________ 162
10.2.5. Movimiento _______________________________________________________________ 162
10.2.6. Capturas __________________________________________________________________ 163
10.2.7. Reglas Suplementarias _______________________________________________________ 164
10.2.8. Fin de la Partida ____________________________________________________________ 165
10.2.9. Breves notas sobre técnica y estrategia _________________________________________ 166
8
Índice de ilustraciones
Ilustración 1:Paradigmas de programación ............................................................... 18

Ilustración 2: Mapa conceptual .................................................................................. 23
Ilustración 3:Predator ................................................................................................ 25
Ilustración 4: Volk-2 ................................................................................................... 26
Ilustración 5: Oportunity ............................................................................................ 27
Ilustración 6:Agentes-Entorno ................................................................................... 31
Ilustración 7: Varillas en un reactor nuclear............................................................... 33
Ilustración 8: Robot de SUMO (Parallax) .................................................................. 35
Ilustración 9: Modelo pizarra ..................................................................................... 40
Ilustración 10: Esquema de mensaje ACL ................................................................ 42
Ilustración 11: Pasos CoMoMAS ............................................................................... 52
Ilustración 12: Mapa metodológico DESIRE ............................................................. 53
Ilustración 13: Fases GAIA ........................................................................................ 55
Ilustración 14: Fase de análisis GAIA ........................................................................ 56
Ilustración 15: Proceso de análisis GAIA .................................................................. 57
Ilustración 16: Proceso de desarrollo GAIA ............................................................... 57
Ilustración 17: Vistas MASSIVE ................................................................................ 61
Ilustración 18: Relación entre objetos MESSAGE ..................................................... 63
Ilustración 19: Estructura RETSINA .......................................................................... 68
Ilustración 20: Módulos RETSINA ............................................................................. 69
Ilustración 21: Pasos de metodología ZEUS ............................................................. 73
Ilustración 22: Kir de herramientas ZEUS ................................................................. 74
Ilustración 23: Esquemático objetivo obligatorio........................................................ 80
Ilustración 24: Esquemático objetivo optativo............................................................ 80
Ilustración 25. Esquemático de entorno .................................................................... 81
Ilustración 26: Esquemático de actor ........................................................................ 83
Ilustración 27: Esquemático de role .......................................................................... 84
Ilustración 28:Esquemático de agentes ..................................................................... 86
Ilustración 29: Esquemático de plan .......................................................................... 87
Ilustración 30: Esquemático de mensaje ................................................................... 89
Ilustración 31: Esquemático de acción ...................................................................... 91
Ilustración 32: Esquematico de riesgo ....................................................................... 92
9
Ilustración 33: Esquemático de conocimientos.......................................................... 93
Ilustración 34: Esquemático de prueba unitaria......................................................... 94
Ilustración 35: Modelo de entorno ............................................................................. 95
Ilustración 36: Modelo de objetivos ........................................................................... 96
Ilustración 37: Modelo de roles.................................................................................. 97
Ilustración 38: Modelo interno de agente .................................................................. 98
Ilustración 39: Diagrama de secuencias .................................................................. 100
Ilustración 40: Diagrama de estados ....................................................................... 101
Ilustración 41: Ejemple de diagrama de flujo ........................................................... 104
Ilustración 42: Cursograma .................................................................................... 106
Ilustración 43: Pasos e hitos.................................................................................... 107
Ilustración 44: Relecamiento de objetivos ............................................................... 115
Ilustración 45: Tablero SPIA-Wari ........................................................................... 125
Ilustración 46:Modelo de entorno ............................................................................ 129
Ilustración 47:Modelo inicial de objetivos ................................................................ 129
Ilustración 48: Modelo de roles................................................................................ 142
Ilustración 49: Modelo de objetivos ......................................................................... 142
Ilustración 50: Modelo interno de entFrontera ......................................................... 148
Ilustración 51: Modelo interno de entCoordinador ................................................... 149
Ilustración 52: Modelo interno de entAgujero .......................................................... 149
Ilustración 53: Modelo interno de agentes ............................................................... 150
10
Índice de tablas
Tabla 1: Glosario 16
Tabla 2: Tabla de propiedades del mensaje 43
Tabla 3: Tabla de operaciones de los mensajes 44
Tabla 4: Tabla de relaciones entre agentes 46
Tabla 5: Tabla de rol 56
Tabla 6: Tabla de modelos de Prometheus 65
Tabla 7: Infraestructura Multiagentes 67
Tabla 8: Infraestructura RETSINA 67
Tabla 9: Ficha de objetivos 79
Tabla 10: Ficha de objetivos 79
Tabla 11: Ficha de entorno 81
Tabla 12: FIcha de actores 82
Tabla 13: Ficha de rol 84
Tabla 14: Ficha de agentes 85
Tabla 15: Ficha de roles 87
Tabla 16: FIcha de protocolo 88
Tabla 17: FIcha de mensaje 89
Tabla 18: Ficha de acciones 90
Tabla 19: Ficha de riesgo 91
Tabla 20: Ficha de conocimiento 93
Tabla 21: Ficha de prueba unitaria 94
Tabla 22: Explicación cursograma 107
Tabla 23: Ficha de objetivos objPpal 123
Tabla 24:Ficha de objetivos objRecibir 124
Tabla 25: Ficha de objeticos objCoordinaOper 124
Tabla 26: Ficha de intorno entIA 125
Tabla 27: Tabla de entrada 126
Tabla 28: Ficha de rol rolEntrada 126
Tabla 29: Ficha de rol rolSalida 127
Tabla 30:Ficha de objetivos objPpal con recursos 127
Tabla 31:Ficha de objetivos objPpal con restricciones 128
Tabla 32: Ficha de riesgo: rsgEntradaFalla 128
Tabla 33:Ficha de plan plaRecibir 131
11
Tabla 34: Ficha de plan: plaDecodifica 131
Tabla 35:Ficha de plan: plaValida 132
Tabla 36: Ficha de plan: plaCreaCoord 132
Tabla 37: Ficha de plan: plaCoordinaOper 133
Tabla 38: Ficha de plan: plaCoordinaOper 133
Tabla 39: Ficha de plan: plaCapturarSemillas 134
Tabla 40: Ficha de plan: plaProfFuturo 134
Tabla 41: Ficha de plan plaSeecEstrategia 135
Tabla 42: Ficha de plan plaSelecAgujero 135
Tabla 43: Ficha de plan plaEntregaMensaje 136
Tabla 44: Ficha de plan plaGestError 136
Tabla 45: Ficha de rol rolEntrada 137
Tabla 46: Ficha de rol rolCoordinador 137
Tabla 47: Ficha de rol rolAgujero 138
Tabla 48: Ficha de rol rolSalida 138
Tabla 49: Fichas de conocimietno knoCoordinador knoAgujero 139
Tabla 50: Fichas de mensajes msgPedido y msgProfundidad 140
Tabla 51: Fichas de mensajes msgRespuesta y msgOk 140
Tabla 52: Ficha de protocolo proSinProfundidad y proConProfundidad 141
Tabla 53: Fichas de protocolo: proEntrada y proSalida 141
Tabla 54: Fichas de agentes entFrontera y entCoordinador 144
Tabla 55: Ficha de agentes entAgujero 144
Tabla 56: Ficha de pruebas pruFro01 y pruFro02 145
Tabla 57: Ficha de pruebas pruFro03 y pruFro04 145
Tabla 58: Fichas de pruea pruCoo01 y pruCoo02 146
Tabla 59: Fichas de pruebas pruCoo03 y pruCoo04 146
Tabla 60: Fichas de pruebas: pruCoo05 y pruCoo06 146
Tabla 61: Fichas de pruebas: pruAgu01 y pruAgu02 147
Tabla 62: Ficha de prueba pruAgu03 147
12
Institucuón: Instituto Universitario Aeronáutico Fecha: 12/12/2018
Proyecto: Metodología de desarrollo de sistemas multi agente Versión: 2.0.0
Documento: Tesis de grado Autor: Daniel Antokoletz Huerta
Resumen
La idea del proyecto es, en primer lugar dar una introducción teórica de los sistemas
multi-agente, a continuación se analizarán las diferentes metodologías de desarrollo
de sistemas multi-agente. Siguiendo una de ellas, se realizará el análisis y el diseño
para el futuro desarrollo de una aplicación de inteligencia artificial para el sistema
SPIA-Wari (desarrollado como trabajo práctico final de pregrado). Luego, el presente
proyecto es una consecuencia de los problemas hallados para el desarrollo del
proyecto de pregrado desarrollado en el año 2014.
13
Palabras clave
Laboratorio de inteligencia artificial

IA
Inteligencia Artificial
Desarrollo de una inteligencia artificial
Sistemas multi-agentes
Metodología de desarrollo de sistemas Multi-agentes
14
Listado de símbolos y convenciones
En el presente documento utilizaremos las siguientes definiciones, acrónimos y

abreviaturas.
IA Inteligencia Artificial
S.P.I.A. Sistema de Prueba de Inteligencia Artificial.
GNU GNU es un acrónimo recursivo que significa GNU No es Unix (GNU is

Not Unix). El proyecto GNU fue iniciado por Richard Stallman con el
objetivo de crear un sistema operativo completamente libre: el sistema
GNU. http://www.gnu.org
GPL La GNU GPL (General Public License o licencia pública general) es una
licencia creada por la Free Software Foundation a mediados de los 80, y
está orientada principalmente a proteger la libre distribución, modificación
y uso de software. Su propósito es declarar que el software cubierto por
esta licencia es software libre y protegerlo de intentos de apropiación que
restrinjan esas libertades a los usuarios.
http://www.gnu.org/copyleft/gpl.html
http://www.garaitia.com/new/gpl-spanish.php
Software Software libre (en inglés free software) es el software que, una vez
Libre obtenido, puede ser usado, copiado, estudiado, modificado y
redistribuido libremente. El software libre suele estar disponible
gratuitamente, pero no hay que asociar software libre a software gratuito,
aunque conserve su carácter de libre, puede ser vendido.
http://www.fsfla.org/
Posix POSIX corresponde a las iniciales de interfase de sistema operativo

portable
(Portable Operating System Interface). Es un estándar de interfase de
sistema operativo, basado en el popular sistema operativo UNIX. El
estándar POSIX está actualmente en desarrollo, y su principal objetivo
es permitir la portabilidad de aplicaciones a nivel de código fuente, es
decir, que sea posible portar una aplicación de un computador a otro sin
más que recompilar su código. Está siendo desarrollado por la Computer
Society de IEEE, con la referencia IEEE-P1003. También está siendo
estandarizado a nivel internacional con la referencia ISO/IEC-9945.
SMA Sistema Multi-Agente
15
RNA Red neuronal artificial
Semilla Es la ficha de juego
Agujero Posición del tablero. Son las casillas en dónde se desarrolla el juego.
Almacén Posiciones extremas del tablero que almacenan las fichas ganadas por
cada uno de los jugadores
Tabla 1: Glosario
16
1. Introducción
Según menciona Michael Wooldridge en "An introduction to multi-agent systems"[1] si

analizamos la historia y la actualidad de la computación está marcada por cinco
tendencias:
 Ubicuidad: Es indudable la continua reducción de costos y el aumento de la

capacidad computacional de los equipos según la ley de Moore. La ley de
Moore expresa que, aproximadamente cada dos años, se duplica el número
de transistores en un circuito integrado. Las computadoras son cada vez más
pequeñas y considerablemente más poderosas. Hoy en día el celular más
pequeño tiene más memoria y capacidad de procesamiento que el AGC
(Apollo Guidance Computer) que permitió la llegada del hombre a la luna.
 Interconexión: en la historia de la computación, los grandes computadores se

encontraban totalmente aislados. Su única comunicación con el mundo exterior
era a través de los operadores. Hoy, hablar de una computadora aislada, o de
un dispositivo incomunicado, sería impensable. La presencia de las redes,
especialmente de Internet, irrumpió en nuestras vidas y casi todos los
dispositivos electrónicos se interconectan entre sí a través de Internet
formando enormes sistemas distribuidos.
 Inteligencia: Los sistemas son cada vez más complejos y, muchas veces, esa
complejidad se traduce en un comportamiento cada vez más inteligente.
Si bien, hablar de inteligencia podría requerir de libros enteros, hay que admitir
que muchos elementos actuando de cierta manera, podría constituir un
comportamiento inteligente.
Por ejemplo, una hormiga sola, no es un organismo inteligente, pero un
hormiguero, ¿no tiene una sociedad organizada?
Para tener una sociedad organizada, se requiere de un tipo de inteligencia.
Luego, tienen hormigas guerrero, trabajadoras comunes, reproductoras,
agricultoras y, por supuesto, la reina. Por separado, las hormigas funcionan de
manera elemental, pero juntas, presentan una inteligencia distribuida.
 Delegación: esta tendencia es una consecuencia lógica de la aplicación de las

tecnologías a la realidad, del abaratamiento y crecimiento de la potencia
computacional. Si prestamos atención a nuestras vidas, cada vez más,
delegamos las decisiones y las operaciones que realizamos diariamente en las
computadoras. Es fácil ver cómo se delega en sistemas robóticos la
construcción de vehículos, el control de los sistemas de vuelo de los aviones y
sondas espaciales, la programación de nuestros viajes, los sistemas de
17
tránsito, etc.
 Orientación humana: La tendencia actual, es un movimiento alejándose de

las vistas orientadas a las máquinas, hacia conceptos y metáforas más
acordes a la manera de pensar de los seres humanos.
Si prestamos atención nuevamente a la historia de la computación, tiene
sentido porque, en los inicios de la computación, los primeros programas los
hacían gurúes manipulando clavijas e interruptores. Luego se pasó a tarjetas
perforadas y programas lineares escritos en Assembler. Aparecieron los
primeros lenguajes orientados a procedimientos como el Fortran y el Cobol. A
continuación, aparecieron las consolas de texto y se consolidaron los
lenguajes de programación orientados a procedimientos, aparecieron los
primeros lenguajes sencillos como el Basic. También emergieron las consolas
gráficas y con ellas la programación orientada a eventos, entonces la
ejecución de los programas ya no era lineal. Comienzan las mejoras para la
programación, aparecen los primeros IDEs (Integrated development
environment – Entorno de desarrollo integrado) con impresionantes ayudas al
momento de programar. Se sube un nivel de abstracción y aparece la
programación orientada a objetos.
En la actualidad hay entornos de desarrollo que permiten programar utilizando
bloques sin que el programador deba tener grandes conocimientos de
programación (Scratch y AppInventor de Android).
Paradigma de programación orientada a agentes
Paradigma de programación orientada a objetos
Abstracción de tipos de datos
Paradigma procedural
Assembler
Cód máqu
Ilustración 1:Paradigmas de programación

Se puede observar que, desde la programación en código de máquina a la
programación orientada a objetos, los lenguajes se van acercando a la manera de
18
pensar se los seres humano. En los primeros tiempos, los primeros programadores
eran considerados gurús, y la programación era oscura y elitista.
En la actualidad, puede programar toda persona que posea un mínimo de
conocimiento. Y este camino lleva (entre otras bifurcaciones) a la programación
orientada a agentes.
Como se podrá comprobar, en la primera parte de éste trabajo, los seres humanos
piensan y se comportan como agentes.
La programación orientada a agentes aparece como consecuencia de las tendencias

mencionadas. Y surge el interrogante, ¿es la única posibilidad? No. Sin dudas no. La
programación orientada a agentes permite acercarse más a la forma de pensar del
ser humano.
En la actualidad, son pocos los sistemas multi-agente completamente operativos, las
tecnologías basadas en agentes se encuentran en desarrollo. Dichas tecnologías son
aún inmaduras. De todas formas, la robustez y tolerancia a fallos que promete, hacen
que sea ideal para sistemas aero-espaciales, control de tráfico aéreo, medicina,
control de procesos electrónicos, automotrices, logística, minería de datos, etc.
19
1.1. Motivación del proyecto
En mi proyecto de pregrado, he desarrollado un juego como laboratorio de inteligencia

artificial. El mismo, permite que se desarrollen módulos de inteligencia artificial para
que compitan entre sí. Si bien en su momento y para poder probar el juego, desarrollé
un par de módulos de IA para poder demostrar la funcionalidad del juego, las mismas
estaban desarrolladas exclusivamente utilizando tecnologías de subsunción.
Cuando desarrollé ese proyecto, me he encontrado con problemas en la aplicación de
metodología de desarrollo de software. Intenté aplicar RUP (Rational Unified Process),
y se complicó en varios aspectos no siendo totalmente adecuado para el tipo de
desarrollo del que se trataba.
Cuando buscaba una metodología para poder hacer los desarrollos de las IA para el
juego, me encontré con que ninguna era completa y que, para poder realizar
concienzudamente ese trabajo, primero debería analizar las metodologías.
Lógicamente, para poder analizar las metodologías primero hay que tener en claro los
conceptos.
El proyecto terminó siendo el desarrollo de la metodología, y mostrar un ejemplo del
análisis y el diseño de un posible módulo de inteligencia artificial (ver trabajos futuros).
20
1.2. Alcances del proyecto
El alcance total del proyecto es el desarrollo de una metodología de desarrollo de

sistemas multi-agentes, y, como ejemplo, el análisis y el diseño de una inteligencia
artificial para el juego S.P.I.A. Wari.
A los fines prácticos, se hará una introducción teórica para unificar los criterios sobre
los conceptos a aplicarse tanto de agentes tratados de manera unitaria como unidos
en sistemas multi-agente, se definirá la metodología de desarrollo y, como último
punto, se seguirá paso a paso esa metodología para el análisis y el diseño de una IA
que pudiera aplicarse al juego S.P.I.A. Wari. Se intentará responder las preguntas,
¿Qué es necesario para desarrollar…?
¿Qué es necesario para desarrollar un agente?
¿Qué es necesario desarrollar para que los agentes se comuniquen?
¿Qué se necesita para desarrollar un sistema multi-agente?
Para obtener respuestas a las preguntas precedentes, es necesario encontrar la
información sobre los temas que debería tener en cuenta una metodología para que
se pueda desarrollar, de manera racional y ordenada, un sistema multi-agente
funcional.
21
1.3. Organización del trabajo
Este trabajo está desarrollado en tres partes y algunos anexos:
PARTE I: Marco Teórico: Agentes y programación orientada a agentes.
En ésta parte se expondrán los conceptos de agentes, los tipos de agentes,

inteligencia de los agentes. Los sistemas multi-agentes, los tipos de sistemas multi-
agente, modos de comunicación entre agentes y lenguaje de comunicación entre
agentes,
Las metodologías de desarrollo convencionales pueden ser inadecuadas para el
desarrollo de sistemas multi-agentes. Se analizarán, a vuelo de pájaro, las diferentes
metodologías existentes en la actualidad verificando sus bondades y sus falencias. Se
seleccionará una metodología, si es necesario, extendiéndola a fin de tratar de
subsanar sus falencias.
PARTE II: Aplicación de la metodología
Se desarrollará una metodología para desarrollo de sistemas multiagente que guíe al

arquitecto y analista por el proceso. Debe ser sencilla de aprender y de aplicar. Se
explicará paso a paso cómo comenzar con la recolección de requerimientos, pasando
por el análisis, el diseño, desarrollo y testeo.
A fin de poder hacer más explicativo el proceso, se analizará y diseñará una IA para
poder ser aplicada al juego S.P.I.A. Wari.
ANEXOS:
Al final del trabajo, se presentarán anexos con el reglamento del juego SPIA Wari, las
características que deben tener las IA para el juego, la codificación para la
comunicación.
22
1.4. Mapa Conceptual
Agente
Agentspeak
Prometheus Concepto
Definiciones
Componentes
Tropos
Gaia
MASSIVE Sistema multiagente
INGENIAS
Agente Agente
MESSAGE
ZEUS
MASBMethod Agente
Agente
METODOLOGÍAS
CoMoMAS DE DESARROLLO Organización del
sistema
multiagente
CommonKAD
Cassiopeia
MeDeSMAGF
Desire
Comunicación
Archon RETSINA entre agentes
MADE PASSI
Vowels Agentspeak KQML

ANIC Engineering
ACL
AAII/BDI Agent Communication
Languaje
ODAC
Ilustración 2: Mapa conceptual
23
PARTE I - Marco teórico: De

los agentes y cómo se
reúnen en sistemas multi-
agentes.
24
Propósito de la sección
El propósito de la esta sección, es presentar una introducción teórica de los sistemas

multi-agente.
Se Pasará del análisis de un solo agente viendo sus características y luego veremos
de la necesidad de aprovechar las características de cada agente para hacerlos
trabajar juntos y/o competir en busca de un objetivo común.
Como se mencionó en el inicio del trabajo, la pregunta que intentaremos responder
en ésta sección, es ¿Qué es necesario conocer para desarrollar un agente?
2. De los agentes
2.1. Introducción
Películas como Terminator con una inteligencia distribuida como Skynet se trata de
un posible escenario no muy lejano. De hecho, en la actualidad, aviones no tripulados
como los MQ-1 Predators norteamericanos, pueden llevar misiles AGM114 Hellfire y
tienen cierta autonomía operativa. El MQ-9 Reaper puede llevar armamento hasta
4500 Kg.
Ilustración 3:Predator
Es cuestión de tiempo que, por razones operativas, se vaya aumentando esa

autonomía de operación…
En Rusia, las plataformas robóticas "Soldado universal", fueron diseñadas para

combate autónomo. Un ejemplo de éste tipo de plataforma es el Complejo robótico
móvil Volk-2 como el que se ve en la imagen.
25
Ilustración 4: Volk-2
Sin importar su tamaño y complejidad, las computadoras necesitan de un conjunto de

instrucciones ordenadas para poder funcionar y lograr sus objetivos (¿No es posible
pensar que los humanos también tenemos instrucciones?). Sin éstas instrucciones,
son un conjunto de componentes electrónicos sin más utilidad que un pisapapeles
caro. Esas instrucciones son dadas por programadores "todavía" humanos. Incluso
esos programitas que todo el mundo conoce: se copian y activan en nuestros equipos,
y se contagian a otros ordenadores y celulares para obtener control sobre ellos. Son
los troyanos y los virus.
Como hemos visto en la introducción de éste trabajo, una de las tendencias es dotar
a los sistemas de más y más "inteligencia" y "autonomía". Hasta hace poco tiempo,
los programas tenían que ser guiados por un operador, pero en ciertas operaciones el
esperar por la acción de un humano, puede hacer peligrar los objetivos del sistema
entonces, se opta por darle más autonomía.
Veamos los siguientes escenarios:
 Operaciones de trading: en el mundo de los negocios de bolsa, las operaciones
son cada vez más rápidas. Hay sistemas que se encargan de monitorear
segundo a segundo el valor de las acciones. Muchas veces, el operador tiene
que estar siguiendo decenas o centenas de acciones para poder actuar y debe
comprar y vender las mismas en cuestión de minutos para obtener ganancias
significativas. Es imposible, físicamente, semejante atención en un humano.
Para poder automatizar esas operaciones se opera con agentes software con
algoritmos que reconocen ciertos patrones o que se activan cuando se dan
ciertas características en los valores de las acciones y que tienen posibilidad
de comprar o vender.
 Operaciones espaciales: El envío de robots a explorar diferentes planetas,
asteroides y cometas son cada vez más frecuentes. Una sonda planetaria como
el Oportunity de la NASA que se encuentra explorando el planeta Marte desde
2004, tiene un comportamiento autónomo que le permite tomar ciertas
decisiones sin necesidad que control de misión la corrobore.
26
Ilustración 5: Oportunity
Hay que tener en cuenta que, en el mejor de los casos, el tiempo que requiere
la información de los sensores desde Marte hasta La Tierra y la vuelta con las
instrucciones (suponiendo que el operador de misión responda
inmediatamente), lleva varios minutos ya que la velocidad de las
comunicaciones no es infinita, no son instantáneas, no pueden superar la
velocidad de la luz. Incluso hay que tener en cuenta que en muchos casos la
comunicación se torna imposible ya que La Tierra y Marte se encuentran en los
puntos opuestos de las órbitas con el Sol en el medio.
 Operaciones de vuelo en aeronáutica: Los sistemas electrónicos de un avión,
en especial en un avión de combate, cumplen con sus objetivos de manera
autónoma para quitarle ciertas responsabilidades a los pilotos como mantener
la estabilidad y el sistema de puntería,
 Operaciones en una central nuclear: No requiere de mucha explicación el darle
autonomía a los sistemas de seguridad de una central nuclear.
Al darle más autonomía e inteligencia a programas podemos decir que nos

encontramos frente a agentes software.
Por supuesto que no es necesario llegar a casos extremos para utilizar agentes. En
muchas operaciones diarias, también se utilizan agentes: en juegos, en medicina, en
plantas fabriles, en reservas de pasajes, en operaciones de comercio, etc.
2.2. ¿Constituyen los agentes un nuevo paradigma de desarrollo

de software?
En primer lugar, se puede decir que un paradigma de programación, podría definirse

como una tecnología de desarrollo que es adoptada por la comunidad de
programadores. Una de las características principales es que un paradigma tiene un
dominio específico de problemas a resolver claramente definidos.
Si observamos la historia de la programación, podemos ver los siguientes paradigmas:
27
 Paradigma imperativo (procedimientos)

 Paradigma funcional (declarativo)
 Paradigma lógico (declarativo)
 Paradigma orientado a objetos
 Paradigma de programación dinámica
En la actualidad, la mayoría de los programadores se alinean con la programación

orientada a objetos en primer lugar y con el imperativo en segundo lugar. En ambos
casos suele mezclarse con la programación dinámica (se divide el problema en
problemas menores de más fácil solución).
Teniendo en cuenta las tendencias enunciadas al comienzo del trabajo, se observa

que la programación orientada a agentes es, probablemente, un nuevo paradigma de
desarrollo. Aún se encuentra en los estados iniciales, pero es claro que está
evolucionando a pasos agigantados.
Lo extraño de éste paradigma es que la manera en que se está desarrollando sirve no

sólo para el desarrollo de agentes software, sino también para el análisis y simulación
de cualquier tipo de situación en dónde se involucran individuos o comunidades (seres
humanos o ecosistemas). Todas las definiciones que se detallan sobre agentes y
multi-agentes, pueden aplicarse tranquilamente a las personas o a cualquier tipo de
ecosistema. En el artículo "Intervening to archieve co-operative ecosystem
management: Towards an agent based model" [2] Doran propone un modelo basado
en agentes para simular la gestión de ecosistemas.
2.2.1. Agentes vs. Objetos

Cuando recién se comienza a desarrollar con agentes y ya se ha trabajado con
programación orientada a objetos, el programador tiene tendencia a pensar que no
hay diferencia entre ambas tecnologías. Nada más alejado de la realidad. Las
diferencias son no sólo conceptuales, sino también prácticas.
Para poder ver la diferencia entre ambas tecnologías, Wooldridge enunció muy
claramente las diferencias entre agentes y objetos. Veamos la siguiente lista:
 Los agentes tienen autonomía, los objetos no. Veremos más adelante en la
definición de agente que un agente recibe un estímulo y realiza una acción. Es
él mismo quien decide cuándo aceptar el estímulo y cómo reaccionar ante él.
Los objetos, al igual que los agentes, se comunican utilizando mensajes, que
no son otra cosa que métodos públicos que se activan para realizar sus
28
operaciones. Pero los objetos no tienen control sobre el momento en que se

activan sus métodos. El control lo tiene el objeto que lo llama. En cambio, el
agente tiene el control sobre sí mismo.
 Los agentes, por definición, reaccionan al entorno y lo modifican. Los objetos,
por otro lado, modifican su estado interno y es el objeto llamante quien le
entrega los datos y le pide los resultados. Es cierto que los agentes también
modifican su estado interno, pero lo realizan en función de su interacción con
el medio.
 Los agentes están pensados para ejecución distribuida y, se tiene muy en
cuenta el concepto de paralelismo. Cada agente tiene sus propios recursos.
Según Wooldridge los agentes deben que tener, necesariamente, al menos un
hilo de ejecución (como un proceso de Unix). Los objetos pueden ejecutarse
en diferentes hilos, pero no es una condición necesaria.
 Los agentes manifiestan un comportamiento flexible, reactivo y, muchas veces,
proactivo. También puede observarse que tienen un comportamiento social, ya
sea colaborativo o competitivo. Son reactivos, porque perciben el entorno. Los
objetos sólo se ejecutan a demanda. Cuando se le presenta al agente una
situación no totalmente contemplada entre sus reglas de operación, tiene la
flexibilidad necesaria para adaptarse y tratar de cumplir con sus objetivos
incluso en ese entorno. Es proactivo porque no sólo intenta cumplir con sus
objetivos, sino que también los genera. Muchas veces toma la iniciativa.
Lo dicho anteriormente, no significa que no se pueda utilizar la tecnología de
programación orientada a objetos para programar los agentes, sino que están en
distintos niveles de abstracción.
2.3. Mitos y verdades de la programación con Agentes

Cuando se menciona sistema multi-agentes, la gente común e incluso los
programadores que no tuvieron acceso a éste tipo de tecnología, tiene ciertas
creencias. Supongo que, con la siguiente lista, aclararemos muchos puntos:
 Los agentes pueden aprender y hacer cualquier cosa: Los agentes no son
magia. Pueden hacer lo que se le imponga por diseño, nada más.
 Hay cosas que sólo pueden hacerse con agentes: Si hay algo que no se puede
hacer con programación estándar, sin duda, tampoco podrá realizarse
utilizando tecnología de agentes. Hay ciertas cosas que los agentes pueden
hacer de manera más sencilla. No pueden hacer posible lo imposible.
 Los agentes son el santo grial del desarrollo de software: Nada más lejos de la
realidad. No son omnipotentes. Como toda herramienta, es la ideal para cierto
tipo de problemas (en especial los que se ejecutan de manera distribuida). Para
otro tipo de desarrollos, es mejor el paradigma de objetos y, para otro, el viejo
paradigma procedural.
 Mejor si se puede desarrollar usando MAS: Dada la complejidad de un
desarrollo de un sistema multi-agentes (lo veremos en el desarrollo de éste
29
trabajo), si para una solución se pueden aplicar tanto tecnología MAS como
POO o cualquier otra, hay que optar siempre por la que sea más sencilla.
 Para mi proyecto debo desarrollar mi propia arquitectura: Durante el transcurso
de los años, se desarrollaron muchas arquitecturas de agente. Sin duda hay
alguna que se amolde al proyecto. Desarrollar una arquitectura como
corresponde, puede llevar mucho tiempo (años).
3. El concepto de agente
3.1. ¿Qué es un agente?
Como todo concepto de éste tipo, que es un concepto aprovechado desde otro
dominio, tiene una definición un tanto controversial.
¿Por dónde empezar?
Empezamos por la definición que da la Real Academia Española y la etimología de la
palabra:
"Agente: (del latín agens - entis, part, act de agere, hacer)

1-Que obra o tiene virtud de obrar.
…
2-Persona o cosa que produce un efecto.
…
"
Verificando en la wikipedia, podemos ir especificando más la definición:
"Un agente inteligente es una entidad capaz de percibir su entorno, procesar tales
percepciones y responder o actuar en su entorno de manera racional, es decir, de
manera correcta y tendiendo a maximizar un resultado esperado. Es capaz de percibir
su medio ambiente con la ayuda de sensores y actuar en ese medio utilizando
actuadores (elementos que reaccionan a un estímulo realizando una acción)"
30
Ilustración 6:Agentes-Entorno
Por las definiciones que se plasmaron hasta ahora, podemos ver que es aplicable a
un agente humano, biológico, químico, etc. En cualquiera de ellos se aplica el
concepto a la perfección.
En éste trabajo nos abocaremos al estudio de los agentes informáticos, más

específicamente de los agentes software.
Wooldridge, ha dado una de las definiciones más citadas en la bibliografía, y la que
desmenuzaremos:
"Un agente es un sistema informático situado en un entorno y que es capaz de realizar

acciones de forma autónoma, para conseguir sus objetivos de diseño" [3].
Un agente no es, necesariamente, un robot, pero un robot, que sin duda es un agente,
nos permite hacernos una idea de lo que es un agente.
Un robot se mueve dentro de un entorno específico. Si se diseña una sonda espacial,
tendrá su utilidad en el espacio. Sus sensores y efectores o actuadores, interpretarán
y operarán correctamente si están en el entorno apropiado.
El robot tiene sensores a través de los cuales puede percibir su entorno. Puede
tratarse de bigotes si tiene que moverse evitando impactar superficies, ultrasonido si
tiene que medir distancias, sensores de presión, si tiene que levantar objetos o visión
si debe cumplir con objetivos observacionales.
Hasta aquí el robot percibe el mundo y, cuanto mucho, realiza un mapeo de ese
entorno en su interior. De manera que, si necesitamos y deseamos (lógicamente para
eso lo desarrollamos) que modifique su entorno (haga algo), se le agregan actuadores
apropiados a la tarea a realizar. Los efectores son las herramientas que tiene el
robot/agente para actuar sobre el medio. Puede tratarse de ruedas o patas para
moverse, brazo mecánico para realizar ciertas operaciones, parlantes para emitir
sonidos o pantallas para mostrar información.
Analizaremos a continuación, la definición de Wooldridge que, a mi manera de ver, es

una de las más amplias y, a la vez, concisas.
31
Un agente es un sistema de computadora…
Como hemos mencionado, en éste trabajo nos abocaremos al análisis y diseño de

sistemas con agentes software.
Es cierto que el término agente, como hemos visto, se puede aplicar a gran cantidad
de elementos, incluyendo comunidades hombre/máquina.
Como puede leerse en el artículo "Una Aplicación de la Tecnología de MultiAgentes a
los Sistemas Tutores Inteligentes: Enseñanza de Computación en Carreras de
Ingeniería" [4]. Puede plantearse un sistema multi-agente en la enseñanza en dónde
se combinan agentes software con agentes humanos (alumnos).
…Que está situado en un entorno…

Lógicamente, necesitamos comprender es qué es el entorno.
Lo primero que podemos decir es que el entorno es todo aquello que se encuentra
alrededor del agente y con lo que el agente interactuar, ya sea recibiendo información
desde el mismo o modificándolo.
La RAE define: "entorno (De en- y torno)
1.m Ambiente, lo que rodea
2.m Inform. Conjunto de condiciones extrínsecas que necesita un sistema informático
para funcionar.
…"
32
Nos quedamos con la segunda

definición, pero veamos un ejemplo:
Tenemos un sistema de refrigeración de

un reactor.
(Imagen: Reed Research Reactor,
Creative Commons)
El sistema de refrigeración está inmerso
en agua. Ese agua, rodea a nuestro
sistema que se conecta de una serie de
sensores de temperatura. Cuando la
temperatura pasa de cierto límite,
enciende unas bombas que enfrian a un
radiador por el que se hace circular el
agua para enfriarla. Al otro lado del
radiador, se encuentran las varillas que,
al enfriarse, calientan el agua.
Nuestro sistema se compone entonces
por los sensores (por donde se reciben
las entradas) y el radiador (el actuador
Ilustración 7: Varillas en un reactor que modifica el entorno). Entonces ¿Cuál
nuclear es el entorno? Sin lugar a dudas, el
líquido que envuelve a los sensores no
forma parte del sistema, forma parte del entorno.
Las preguntas claves a hacerse es: ¿las varillas forman parte del entorno?¿El
contenedor forma parte del entorno?
Para poder responder esas preguntas, tenemos que fijarnos si esos elementos
interactúan directamente con nuestro agente. Las varillas no interactúan con el
agente-sistema, sino a través del líquido. De manera que podríamos decir que las
varillas no forman parte del entorno. De la misma manera, el contenedor, tampoco
formaría parte del entorno.
Según Wooldridge los entornos se clasifican según varios parámetros:
Según su accesibilidad puede ser:
 Accesible: en estos entornos, los agentes obtienen información completa,
correcta y en tiempo real del estado del entorno. Cuando el entorno depende
casi exclusivamente de leyes físicas, podemos decir que estamos en éste tipo
de entornos.
 Inaccesible: hay información incompleta sobre el estado del entorno. En la
mayoría de los escenarios reales, no se tiene acceso a toda la información del
entorno.
Lógicamente, cuanto más información se tiene del entorno, mejores decisiones tomará
el agente, cuánto más accesible es el entorno es lo ideal.
33
Según su certidumbre se clasifica en:

 Determinístico: los entornos determinísticos son aquellos que establece una
relación causa-efecto unívoca. Obviamente, en estos casos, se descartaría
totalmente la presencia de eventos aleatorios.
 No-Determinístico: en el mundo real, la mayoría de los entornos, pertenecen a
ésta clasificación. Casi siempre hay elementos de incertidumbre en los
entornos reales. Lo importante es tratar de acotar esa incertidumbre y saber
manejarla. Desarrollar agentes para un entorno determinístico no tiene mucho
sentido. Para ello puede desarrollarse un programa común y corriente.
Según su posibilidad de cambio:
 Estático: un entorno es estático cuando permanece inalterable durante todo el
tiempo que necesita el agente para tomar sus decisiones. Las únicas
modificaciones que sufre el entorno es a causa del agente (o de los agentes
cuando se trata de un sistema multi-agente.
 Dinámico: el entorno evoluciona constantemente y el agente debe adaptarse a
ese cambio y anticiparlo. Supongamos el escenario que presenta para un
agente el tener que moverse u operar dentro de internet. El entorno se
encuentra cambiando a cada momento.
Según su continuidad puede ser:
 Discreto: cuando trabajamos en un entorno discreto, estamos en presencia de
un número finito de estados de entorno que puede ser percibido casi
completamente por el agente.
 Contínuo: en éste caso el número de estados que presenta el entorno en
infinito. O, al menos incontable o con demasiadas posibilidades para tenerlas
en cuenta a todas. Para trabajar en estos entornos, el agente debe clasificar y
agrupar los estados del entorno y, en caso de que se trate de un entorno
analógico, debe digitalizarlo para poder comprenderlo.
El agente necesita disminuir la complejidad tratando de discretizar, hacer más estático
y moverse en un entorno lo más determinístico posible. La realidad es demasiado
compleja y las técnicas que se usan en la programación de los agentes deben, sobre
todo disminuir la complejidad.
…y es capaz de realizar acciones autónomas para conseguir sus objetivos de

diseño.
Diseñar un agente que no realice ninguna acción, que no modifique, de alguna
manera, su entorno, no tiene ningún sentido.
34
Las acciones que puede realizar un agente son de muy variada índole:
 Recopilación de información
 ordenamiento de información
 almacenamiento de información
 coordinación de otros agentes
 realización de tareas físicas
 creación de otro agentes
 transportar objetos (físicos, lógicos, otros
Ilustración 8: Robot de SUMO agentes)
(Parallax)
 etc.
Sin duda, el límite es la imaginación del diseñador.
Una de las condiciones que establece la definición que estamos analizando es que
realice las operaciones en forma autónoma. En éste momento necesitamos
comprender la diferencia entre un sistema autónomo y un sistema automático.
Para plantear la distinción entre los sistemas automáticos y autónomos, primero
veremos que dice el diccionario de la Real Academia Española sobre las palabras
automático y autónomo:
Para automático la RAE dice lo siguiente:

adj. Perteneciente o relativo al autómata.
adj. Dicho de un mecanismo: Que funciona en todo o en parte por sí solo. U. t.
c. s.
adj. Que sigue a determinadas circunstancias de un modo inmediato y la mayoría
de las veces indefectible.
Para autónomo, la RAE define:
Que tiene autonomía.
Que trabaja por cuenta propia. U. t. c. s.
Entonces podemos decir que un Sistema Automático es un sistema que tiene una
serie de pasos prefijados que cumplirá indefectiblemente desde el principio hasta el
final. El salteo de algunos pasos dependerá de la programación, pero jamás será
decisión del propio sistema. Por otro lado, un Sistema Autónomo es aquel que no
necesita de la supervisión de un operario. Tomará decisiones de acuerdo a las
condiciones del entorno y almacenará su experiencia en su memoria interna. El
35
sistema autónomo es un superconjunto de un sistema automático. Si a un sistema

automático se le adiciona algún tipo de inteligencia que le permita almacenar
experiencia y tomar decisiones no pre-programadas se convertirá en un sistema
autónomo.
Son ejemplos de sistemas automáticos:

 Lavarropas y lavavajillas automáticos (el aparato cargará el agua, moverá la
ropa cierto tiempo, calentará el agua, enjuagará cierta cantidad de veces y
centrifugará cierto tiempo de acuerdo a programas preestablecidos),
 Armas automáticas (el ciclo completo de cargar, amartillar, disparar y extraer
es completamente mecánico)
 Cajero automático (Realiza una gran cantidad de operaciones emulando a un
cajero, pero no poseen inteligencia propia. Realizan siempre los mismos pasos
dependiendo de la operación elegida)
 Robot soldador en una línea de montaje, realiza operaciones de soldadura
sobre piezas de acuerdo a un programa minuciosamente preestablecido. De
hecho, si la pieza que toma se encuentra en mala posición no opera
correctamente y hasta puede detenerse por no poder continuar con el
programa.
Son ejemplos de sistemas autónomos:

 Las sondas robóticas enviadas por la NASA al espacio y a los distintos planetas
para obtener muestras de diferentes planetas, satélites, cometas, polvo estelar;
datos y fotografías.
 Algunos web-bots multiagentes que se utilizan para hacer datamining en
Internet.
 Algunos sistemas expertos que sirven para apoyo de decisiones.
 Algunas secretarias electrónicas que pueden ocuparse de coordinar vuelos y
transportes.
Lo importante que debe tenerse en cuenta es la última parte de la definición es que

las tareas deben tener un objetivo, y ese objetivo, se establece en el momento de
diseño. ¿puede modificarse el objetivo? Creo que la respuesta depende de la
inteligencia del agente. Un humano tomado como un agente, por ejemplo, podría
modificar sus objetivos. Coincidamos que, según las definiciones, un humano entra
dentro de la definición genérica de agente. No es un agente software, pero es un
agente al fin. También tiene sus objetivos, que han sido implantados en el momento
de diseño: alimentarse, sobrevivir y procrear para que la especie se preserve. Pero
pueden ser modificados por la cultura. Así es como podemos ver personas que se
sacrifican por otros: actos de heroísmo donde una persona puede elegir entre su
supervivencia o la supervivencia de los demás. ¿No estará en ese caso también
36
respondiendo a su programación? En éste caso está primando una de las reglas

implantadas: la supervivencia de la "especie".
37
4. De cómo los agentes se reúnen y forman sistemas multi-

agente
4.1. Introducción
Teniendo claro el concepto de agente, podemos ver la verdadera potencia de éste

paradigma: la interacción entre los agentes, el procesamiento distribuido, la
especialización, puesta en común, etc.
Son muchas las formas de interacción entre los agentes y la comunicación entre ellos
es imprescindible.
Cuando los agentes interactúan, surge a priori, la necesidad de que se comuniquen
entre sí, de que reciban peticiones y resultados de otros agentes y de que puedan
comunicar sus propios resultados; de manera que surge la comunicación entre
agentes.
Al interactuar y comunicarse, al igual que en los grupos humanos (recordemos que
cuando definimos los agentes, vimos que los seres humanos cumplen con todas las
condiciones para ser agentes), los agentes forman estructuras sociales. Establecen
algún tipo de jerarquía organizándose, estableciendo arquitecturas de sistemas multi-
agentes.
4.2. Comunicación entre agentes

4.2.1. Introducción
La única manera de que los agentes interactúen entre ellos es que tengan algún tipo
de comunicación. El agente no puede cumplir con sus propios objetivos sin considerar
los de los otros. En algunos casos, un agente necesitará de la asistencia de otros para
llegar a sus metas; en otros casos, deberá competir con otros agentes por el acceso
a recursos y en otras oportunidades deberá negociar con sus contrincantes porque
sus objetivos pueden ser opuestos.
A la interacción entre los agentes se la denomina habilidad social. Esa habilidad puede
manifestarse a través de la cooperación, coordinación y negociación. La única manera
de interactuar sería usando algún lenguaje de comunicación.
En este punto se intentará responder a las preguntas: ¿Qué es comunicar? ¿qué
comunicar? y ¿cómo hacerlo?
38
4.2.2. ¿Qué es comunicar?
Como se ha hecho en otros puntos, nos remitiremos a la RAE para tener una primera
aproximación de lo que es comunicar.
Comunicar proviene del latín comunicarse y significa:

1. Hacer a una persona partícipe de lo que se tiene
2. Descubrir, manifestar o hacer saber a alguien algo
3. Conversar, tratar con alguien de palabra o por escrito.
4. Transmitir señales mediante un código común al emisor y al receptor.
5. Establecer medios de acceso entre poblaciones o lugares.
6. Consultar con otros un asunto, tomando su parecer.
Como puede verse hay varias acepciones, y en el transcurso de éste punto, se verá
que pueden aplicarse todas ellas.
4.2.3. Formas de comunicación entre los agentes.

Son variadas las formas de comunicación entre los agentes. Casi siempre involucra
el intercambio de mensajes, pero no siempre.
Las formas de comunicación que se analizarán son las siguientes:
 Comunicación indirecta:
o Comunicación mediante el entorno.
o Sistema de pizarra
o Interacción sin comunicación (inferencias)
 Comunicación directa:
o Comunicación a nivel del conocimiento.
4.2.3.1. Comunicación mediante el entorno

Es un tipo de comunicación indirecta en dónde se dejan señales en el entorno para
que puedan ser analizadas y utilizadas por otros agentes.
Un tipo de comunicación mediante el entorno es el que sucede entre las hormigas.
Cuando una hormiga pasa por un lugar, va dejando un rastro de feromonas. Ese rastro
se va diluyendo con el tiempo. Pero cuando pasa la siguiente hormiga, siguiendo el
rastro, dejará también feromonas reforzando el rastro. Las hormigas son un tipo de
agentes (cumplen con todas las condiciones de agentes) y pueden comunicarse entre
sí sin estar uno con otro.
39
4.2.3.2. Comunicación mediante sistema de pizarra

La comunicación mediante un sistema de pizarra[32][33] es indirecta, porque no hay
comunicación directa entre los agentes. Toda comunicación se realiza mediante un
espacio (o varios) de memoria compartida a la que los agentes se registran y dejan o
toman mensajes del mismo.
Ilustración 9: Modelo pizarra
La arquitectura de pizarrón es un medio de representación de conocimiento accesible

a todos los agentes. El primer programa que utilizó este método de comunicación entre
agentes ha sido un sistema de reconocimiento de voz llamado Hearsay II.
Los sistemas más modernos que implementan la estructura pizarra, pueden incorporar
uno o los dos siguientes agentes:
Agente moderador: Es un agente especializado que puede evaluar los elementos
que son publicados en la pizarra. Tiene capacidad de control y puede decidir a qué
agentes asignarle los problemas, de entre los que se registraron para resolverlos.
Agente despachador: Es un agente que verifica constantemente la pizarra y envía
mensajes a los agentes registrados cuando detecta algún cambio.
Por supuesto que, como cualquier tipo de arquitectura, tuene fortalezas y debilidades.
La fortaleza principal es que para ésta arquitectura es sencillo agregar o quitar agentes
ya que sólo tienen que registrarse en la pizarra.
La debilidad que presenta esta arquitectura es que la pizarra puede transformarse en
un cuello de botella.
4.2.3.3. Interacción sin comunicación.

Ésta interacción completamente indirecta se realiza a través de la inferencia de
acciones de lo que realizan otros agentes.
Un ejemplo clásico es la utilización de la teoría de juegos para tratar de comprender
la interacción entre agentes competidores.
40
Un caso de aplicación de éste tipo de interacción es el famoso dilema del prisionero.

Se captura a dos delincuentes que cometieron un crimen. Se los encierra
incomunicados, y se le dice a cada uno: “Si uno de los dos confiesa, el delator obtiene
su libertad, mientras que el otro será condenado a cinco años; Si los dos confiesan,
purgarán dos años y medio; y si ninguno confiesa, irán sólo un año a prisión”.
Si se analiza el dilema usando la teoría de juegos, se determina que la mejor opción
que tienen ambos delincuentes es mantener la boca cerrada. Pero no siempre sucede.
En la robótica se aplica éste tipo de interacción en el sumo robótico y en los partidos
de football robótico.
4.2.3.4. Comunicación a nivel de conocimiento.

En éste tipo de comunicación directa, los agentes comparten conocimiento.
Comparten sus estados mentales, o persuaden e intentan modificar el estado mental
de otros agentes.
También transmiten necesidades y resoluciones obtenidas.
Como se analizará en la sección lenguajes, FIPA se basa en éstas teorías para
desarrollar su lenguaje de comunicación entre agentes.
4.2.4. Pasaje directo de mensajes.

La comunicación entre los agentes, se realiza a través de mensajes, tanto en los casos
en donde hay comunicación directa, como en los casos en que la comunicación es
indirecta. Debe entenderse mensaje, como una estructura de datos que se envía de
una entidad a otra ya sea en forma directa o a través de una pizarra o filesystem.
4.2.4.1. Estándares y protocolos de mensajes

Cuando se desarrolla un sistema multiagente, es posible diseñar una nueva estructura
y tipo de mensajes, pero no es aconsejable. Sería como reinventar la rueda ya que
hay varios estándares que pueden ser aplicados satisfactoriamente a la mayoría de
los casos.
Serán analizados los estándares:
 FIPA-ACL
 KQML
4.2.4.2. FIPA-ACL
El FIPA-ACL es un estándar definido por Fundation for Intelligent Physical Agents
(FIPA – www.fipa.org) donde ACL significa Agent Communication Languaje.
Inicialmente analizaremos la composición de un mensaje FIPA-ACL.
41
Ilustración 10: Esquema de mensaje ACL
Un mensaje se compone de la instrucción que indica el tipo de mensaje de que se

trata y de los parámetros del mismo. Los parámetros de los mensajes comienzan con
“:”
Parámetro Categoría y descripción.
performative Tipo de acto comunicativo. Son las operaciones que

puede realizar el agente. Más adelante se analizarán las
acciones posibles. Es un campo obligatrio.
:sender Participante de la comunicación. Es la identidad del

agente que envía el mensaje. Es un campo obligatorio.
:receiver Participante de la comunicación. Es la identidad del o de

los agentes destinatarios del mensaje. Sólo hay una
posibilidad de que éste campo se encuentre en blanco:
cuando se utilice algún tipo de proxy.
:replay-to Participante de la comunicación. Indica que los mensaje

subsecuentes deben ser direccionados al agente cuyo
identificador se pone en este campo. Es optativo.
:content Contenido. En este campo se envía el contenido del

mensaje. Lógicamente, el contenido debe ser
comprensible para el/los agente/s receptor/es.
:language Descripción del contenido. Determina el lenguaje en el

que el contenido se encuentra expresado.
:encoding Descripción del contenido. Es la codificación que se usa

en el contenido. Es un campo optativo ya que si no, se
toma la codificación por omisión.
42
:ontology Descripción del contenido. Tomando en cuenta la

ontología y el lenguaje, permite al agente receptor
interpretar el contenido del mensaje. Todos los mensajes
FIPA comparten las siguientes ontologías: fipa-acl-
message y fipa-acl. En los casos que la ontología sea
común a todos los agentes, puede omitirse este campo.
:protocol Control de conversación. Esto define el protocolo de

interacción para el mensaje. Si bien es un parámetro
opcional, se aconseja que se definan protocolos para la
mayoría de las acciones.
:conversation-id Control de conversación. Es un identificador único que se

utilizará durante toda la aplicación de los protocolos.
:reply-with Control de conversación. Este campo se utiliza para

poder seguir una conversación cuando se están dando
varias conversaciones simultáneamente.
:in-reply-to Control de conversación. Es una referencia al mensaje

previo que generó la necesidad de la respuesta.
Reply-by Control de conversación. Es un valor de fecha/hora que

pone límite a cuánto se va a esperar para recibir una
respuesta.
Tabla 2: Tabla de propiedades del mensaje
4.2.4.2.1. Operaciones de los mensajes
Realización
Paso de Solicitud de Manejo de
Acto comunicativo Negociación de
información infromación errores
acciones
accept-proposal ×
Agree ×
Cancel ×
Cpf ×
Failure ×
Inform ×
43
not-understood ×
Propose ×
query-if ×
refuse ×
reject-proposal ×
Request ×
request-when ×
request-whenever ×
Subscribe ×
Tabla 3: Tabla de operaciones de los mensajes

accept-proposal: el agente acepta la propuesta.
agree: el agente acepta la petición.
cancel: el agente cancela la petición que ha realizado.
cfp: el agente solicita propuestas para la realización de una acción (Call for Proposals).
failure: el agente informa porque ha fallado en la acción.
inform: el agente envía información al agente requirente.
not-understood: el agente informa que no comprende el contenido del mensaje.
propose: el agente hace una propuesta. Generalmente como respuesta a un cfp.
query-if: el agente emisor consulta algo al agente receptor.
refuse: el agente rechaza un petición que le hizo otro agente.
reject-proposal: el agente rechaza una propuesta .
request: el agente solicita a otro que realice una acción.
request-when: el agente solicita a otro que realice una acción cuando se cumpla una
condición.
Request-whenever: el agente solicita a otro una acción que deberá hacerse siempre
que se cumpla con una condición.
subscribe: el agente se subscribe a un servicio de un agente receptor. El agente
receptor, cuando encuentre algo interesante para el elisor, se lo informará.
44
4.2.4.3. KQML
KQML es la sigla para Knowledge Query and Manipulation Languaje (Lenguaje de
consulta y manipulación de conocimiento. El mismo ha sido desarrollado en el
programa ARPA Knowledge sharing effort (Esfuerzo de compartición de conocimiento
de ARPA).
KQML es tanto un formato de mensaje como un protocolo de manipulación de esos
mensajes. Se enfoca en un conjunto de enunciados performativos (son enunciados
que al utilizarse realiza la acción que significa). Que define las operaciones que los
agentes pueden intentar basado en los conocimientos de otros agentes y apuntando
a los objetivos. El desarrollo de este lenguaje se basa en la teoría de actos del habla.
Las oraciones expresadas por los humanos no siempre aseveran un hecho, pueden
transmitir una creencia, un conocimiento, una intención o un deseo. Además puede
establecerse una relación entre el estado interno de un agente y de los mensajes que
intercambia con los demás agentes. Como redes de contactos y negociación entre
agentes.
Características KQML:
 El lenguaje KQML cumple con los estándares FIPA (Foundation for Intelligent
Phisical Agents,).
 Los mensajes, además de tener una sintaxis y una semántica, comunican una
acción apoyada por el contenido (solicita, consulta, niega afirma, etc.)
 Las primitivas del lenguaje se llaman ejecutivas
o performativa
o acción
o realizativos
Estas primitivas señala las intenciones y las acciones de los agentes influyendo
en la base de conocimiento de los otros agentes.
 Es posible definir unos agentes especializados que se denominan agentes
facilitadores cuya función es coordinar la interacción entre otros agentes.
Realizando las siguientes acciones:
o Asociación de direcciones físicas con nombres simbólicos
o registro de bases de datos
o registro de servicios ofrecidos
o registro de servicios buscados por los agentes
o servicios de comunicación (reenvío, intermediación, etc.).
45
4.3. Coordinación en sistemas multi-agente

Como es posible imaginar, el trabajar con sistemas multi-agente, significa algún tipo
de coordinación de los sistemas multi-agente.
Pueden concebirse muchos agentes siguiendo un objetivo sin tener ningún tipo de
coordinación, mientras los objetivos sean simples. Pueden colaborar, lo que sin duda
requiere coordinación o pueden competir.
4.3.2. Tipos de relaciones entre los agentes
Podremos ver las relaciones entre agentes en la siguiente tabla:
Reducción de intervalos
Temporal
Extensión de intervalos
Recursos
Reducción de recursos
insuficientes
Competitivo
Material Sustitución de recursos
Tipo de
Cancelación de acciones
relación
Objetivos Incompatibles
Mismos objetivos Igualdad
Cooperativo Objetivos complementarios Favores
Refuerzo e inhibición Subsunción
Tabla 4: Tabla de relaciones entre agentes
En el caso de una relación competitiva, los agentes deben competir por algún recurso
escaso. Esa escasez no significa faltante. Es que, en un instante dado, lo esté usando
otro agente. Por ejemplo el acceso a un determinado efector o una línea de
comunicaciones en un instante dado.
Lo más interesante es cuando los agentes tienen objetivos incompatibles en donde se
dan negociaciones, intermediación, etc.
46
5. Metodologías de desarrollo de sistemas multiagente
5.1. Introducción
La palabra metodología proviene del griego μέθοδος que provinene a su vez de μετά
que significa más o meta, objetivo, οδως (odós) significa camino y λογος (logos)
significa estudio. Podemos decir que metodología es el camino, el conjunto de
procedimientos racionales que se utilizan para alcanzar el objetivo o la gama de
objetivos. Con frecuencia puede definirse la metodología como el estudio o elección
de un método pertinente o adecuadamente aplicable a determinados objetos.
La metodología supone sistematizar las series de procedimientos, la organización de
los pasos a través de los cuales se ejecutarán los procedimientos. No es posible
investigar sin pensar en la secuencia lógica de pasos que, necesariamente, deben
cumplirse para lograr cumplir con los objetivos de manera racional y segura.
5.2. Marco de análisis de metodologías agentes
En la actualidad hay muchas metodologías de desarrollo que nos permitirían analizar

y diseñar sistemas multi-agentes. Esto plantea un nievo nivel de dificultad al momento
de seleccionar la herramienta adecuada a aplicar en nuestro caso. Hay muchas
características, marcos de trabajos, lenguajes de desarrollo específicos a tener en
cuenta.
5.2.2. Criterios a tener en cuenta en la elección de una

metodología.
Según [35] y [36] podemos basarnos en cuatro componentes para evaluar un marco de
trabajo para el análisis:
 Criterio de procesos: se analiza el proceso de desarrollo de sistemas multi-
agentes
 Criterio de técnicas: se analiza el acceso a técnicas para desarrollar un sistema
multi-agentes
47
 Criterio de modelos: se analizan las capacidades de modelado de la

metodología.
 Criterio de soporte: se analizan las herramientas de soporte para la
metodología.
5.3. Metodologías de desarrollo de sistemas multi-agentes.
En ésta sección realizaremos una vista a vuelo de pájaro de las diferentes
metodologías definiéndolas brevemente y brindando lugares donde obtener más
información de la misma. Algunas de estas metodologías han sido abandonadas por
sus autores.
La mayoría de las metodologías tienen una gran influencia de las orientadas a objetos
y otras del proceso unificado de desarrollo de software (RUP)
5.3.2. Metodología: AAII/BDI
Esta metodología fue desarrollada por un grupo de investigación de aplicaciones de

agente pionero: Australian Artificiale Intelligence Institute (AAII) quienes desarrollaron
la metodología descripta por Kinny, Georgeff y Rao en el año 1996.
Los sistemas multi-agentes modelados con ésta metodología responden al tipo BDI
(believe, desire, intention – creencias, deseos intenciones)
Esta metodología opera a dos niveles de abstracción:
 Externo: el sistema es descompuesto en agentes. Estos agentes están
modelados como objetos complejos con diferentes propósitos,
responsabilidades, servicios que deben proveer, datos que debe consumir, etc.
 Interno: Las creencias, objetivos y planes definidos para cada agente.
Teniendo en cuenta el nivel externo, podemos identificar cuatro pasos:
1. Identificación de roles apuntando a generar una jerarquía de agentes. Los roles
pueden ser organizacionales o funcionales.
2. Identificación de las responsabilidades asociadas a cada rol y los servicios
necesarios para cumplir con esas responsabilidades. Estos servicios pueden
incluir interacciones con el entorno.
3. Identificar las interacciones que están asociadas a los servicios:
 De actuación
 informativos
 Eventos y condiciones (notificativos)
 Acciones a realizar
48
 Requerimiento de informaciones
4. Refinamiento e introducción de las instancias de agentes (lo que indica que es
una metodología iterativa).
Estos pasos se plasman en los modelos de agentes y en los modelos de interacción.
Teniendo en cuenta el nivel interno, podemos considerar dos pasos:
 Análisis del plan para lograr los objetivos
 Contextos
 Condiciones
 Sub-objetivos
 Acciones
 Gestión de errores
 Consideraciones de las creencias (conocimientos internos que tiene el
agente y análisis de las entradas y los requerimientos de salida)
Éstos pasos definen el propósito y los objetivos de un agente.
Al final, el sistema está conformado por una jerarquía de agentes que cumplen roles
y están afectados por la interacción entre los roles. Los roles y las interacciones entre
los roles son invariantes en el tiempo.
Estos agentes tienen una estructura organizacional rígida y, por ende, no es muy
maleable cuando el ambiente es dinámico.
5.3.3. Metodología: Cassiopeia
Cassiopeia [1][38], fue propuesta por Collinot et. al. Es de naturaleza bottom-up, en
contraste a GAIA y AAII que es up-bottom. Se comienza analizando los
comportamientos necesarios para realizar una tarea.
La metodología Cassiopeia adopta la aproximación orientada a la organización de los
agentes hacia los agentes.
Las fases del ciclo de vida de Cassiopeia comienzan con la definición de las tareas
colectivas del sistema al diseño del sistema multi-agentes a través de dos fases: la
iniciación y la construcción.
Cassiopeia modela a los agentes a través de sus roles que tienen tres capas:
 Roles dependientes del dominio: comportamiento individual de los agentes.
 Roles relacionales: cómo interactúan los agentes entre sí.
 Roles organizacionales: como se agrupan los agentes.
Propone tres pasos:
49
1. Identificar los comportamientos elementales: Se definen los comportamientos

individuales de los roles para cumplir con la tarea colectiva del sistema. Modela
la funcionalidad del sistema.
2. Identificar las relaciones entre esos comportamientos elementales: busca
identificar las dependencias entre los roles definidos en el paso 1 y determina
los roles relacionales de los agentes.
3. Identificar el comportamiento organizacional del sistema, por ejemplo cómo se
agrupan los agentes en grupos: especificar los roles organizacionales que
permitan que los agentes generen grupos de agentes (por ejemplo, los grupos
iniciadores o los grupos participantes) y especificar los comportamientos
organizacionales de los agentes, como los comportamientos de generación de
grupos, los comportamientos de disolución de grupos, etc.
En la RoboCup 2001[37], uno de los equipos fue diseñado por Collinot usando esta
metodología que se enfoca en los temas organizacionales analizando las
interdependencias de las especializaciones de bajo nivel, facilitando la formación de
grupos usando esas interdependencias.
5.3.4. Metodología: CommonKADS
CommonKADS[39][40] es una metodología diseñada para el desarrollo de KBS

(knowledge based system – sistema basado en conocimiento) como resultante dep
proyecto KADS-II del programa estratégico europeo para investigación y desarrollo
en tecnología de la información entre 1990 y 1994. Esta metodología contiene:
 Un marco de trabajo para los proyectos de especificación de conocimiento sin
importar la implementación. Posee una biblioteca con modelos de conocimiento
reutilizables.
 Un modelo de ciclo de vida señalando fases, actividades y productos.
CommonKADS está orientado al desarrollo de sistemas basados en conocimiento y
permite reconocer este tipo de dominios.
Establece cuatro modelos que permiten modelar un entorno KBS.
 Modelo organizacional: Permite analizar la organización, el entorno en el que
el KBS se introducirá
 Modelo de tareas: Permite describir las tareas que deben ser realizadas por el
KBS.
 Modelo de agentes: describe las capacidades y características que deben tener
los agentes que se encargan de ejecutar las tareas (pueden ser software o
humano)
 Modelo de comunicaciones: describe la interacción entre los agentes y los
agentes y el entorno.
 Modelo de experiencia: es uno de los modelos principales de CommonKADS y
modela los problemas a ser resueltos y tiene tres niveles:
50
o Nivel de dominio
o Nivel de inferencia
o Nivel de tarea
 Modelo de diseño: describe la arquitectura y diseño técnico del KBS (es en el
que hay que basarse para realizar el desarrollo y la implementación)
CommonKADS tiene limitaciones para el trabajo con sistemas multi-agente. Una

extensión a ésta metodología es MAS-CommonKADS, que le agrega características
para poder lidiar con agentes inteligentes y comunicación entre agentes inteligentes,
agregándole:
 Modelo de coordinación: Describe las interacciones entre los agentes software,
los protocolos de usuario y las características necesarias para implementar
esas interacciones. Éste modelo sirve de base para generar el modelo de
comunicaciones.
Y gira en torno del modelo de experiencia.
MAS-CommonKADS[45] ha sido la primera metodología en integrar un ciclo de vida
con un desarrollo multi-agentes. Se complementa con notaciones SDL (Specification
and Design Language) y MSC (Message Sequence Chart) para describir el
comportamiento de los agentes cuando interactúan.
El ciclo de vida sigue las siguientes fases:
 Conceptualización: durante esta fase, se obtiene una primera descripción del
problema a través de casos de uso.
 Análisis: esta fase determina los requerimientos funcionales del sistema
utilizando un conjunto de modelos.
 Diseño: La fase de diseño combina una aproximación top-down con una
bottom-up. Lógicamente toma como entrada a los modelos de análisis y debe
transformarlo en especificaciones que se consignan en el modelo de diseño.
Se determinan en ésta fase la arquitectura interna del agente y la arquitectura
de red del sistema.
 Desarrollo: Codificación de los agentes definidos durante la fase de diseño.
 Testing: Verificación de que el comportamiento del sistema se ajusta a lo
definido en la fase de conceptualización y de análisis.
 Operación: operación y mantenimiento del sistema.
MAS-CommonKADS necesita de herramientas de soporte debido al nivel de detalle
alcanzado en la descripción.
La metodología MASINA[41](Multi-Agent Systems IN Automation) es una extensión de
CommonKADS orientado a la automatización (robótica). Le agrega las siguientes
características:
 En la fase de conceptualización, MASINA usa diagramas de actividades UML
para la descripción de los servicios que brindarán los agentes.
 En la fase de análisis incorpora:
o Modelo de inteligencia que reemplaza al modelo de experiencia y
describe los aspectos necesarios para generar un comportamiento
51
inteligente, como aprendizaje, razonamiento, representación de

conocimientos y acumulación de experiencia.
o Modelo de tareas muestra las tareas que deben realizar los agentes en
el entorno organizacional.
 Los modelos de comunicación y coordinación son diferentes en MASINA.
Coordinación describe las conversaciones y el de comunicaciones los actos de
habla (utiliza los diagramas de interacción para describir las conversaciones)
 El modelo de agentes tiene más atributos generando niveles de abstracción
 El modelo de tareas permite especificar las tareas con técnicas de inteligencia
artificial (redes neuronales, algoritmos genéticos, etc.)
5.3.5. Metodología: CoMoMAS
Si bien CoMoMAS[42] también es una extensión de CommonKADS y también está

orientado a ingeniería del conocimiento, lo ponemos como metodología separada
debido a que se basa en los actos de habla del CommonKADS, y de allí se desarrolló
la metodología.
Esta metodología se basa en los resultados de cinco pasos de análisis:
Modelo de
diseño
Modelo de Modelo de
tareas experiencia
AGENTE
Modelo de Modelo de
sistema cooperación
Ilustración 11: Pasos CoMoMAS
 Análisis funcional: debe identificar las tareas a ser resueltas por el sistema
multi-agentes. También deben identificarse las dependencias de datos y de
control entre las tareas. Los resultados del análisis funcional se recaban en el
modelo de tareas.
 Análisis de requerimientos: debe identificar los requerimientos de diseño del
sistema multi-agentes. El resultado de este análisis se consignan en el modelo
de diseño. También del análisis de requerimientos surge información para
identificar a los agentes a crear.
52
 Análisis de competencia: identifica las competencias cognitivas y reactivas para

solucionar las tareas enunciadas en el análisis funcional. Con el resultado del
análisis de competencia se desarrolla el modelo de experiencia.
 Análisis de cooperación: debe identificar los protocolos de cooperación, los
métodos de cooperación y los métodos de resolución de conflictos entre
agentes. El modelo de cooperación se hace con la información de éste análisis.
 Análisis social: identifica la organización y estructura del sistema multi-agentes.
El resultado de este análisis se consigna en el modelo de sistema.
Las mayores diferencias entre CommonKADS y CoMoMAS se presentan en el modelo
de experiencia y en el modelo de agentes.
5.3.6. Metodología: DESIRE
DESIRE[43][44] Es una sigla de DEsign and Specification of Interacting REasoning.

Originalmente ha sido diseñado para especificar sistemas de razonamiento complejos,
pero luego se extendió a una especificación formal de sistemas multi-agentes.
DESIRE especifica la dinámica de comportamiento de razonamiento y actuación.
De los sistemas de razonamiento complejos, se tienen los componentes de
razonamiento por un lado y los subsistemas de cálculo, recuperación de información
y de optimización por el otro. La semántica formal de estos sistemas la lógica temporal.
Agregándole las extensiones DESIRE como activación paralela de agentes, control
de comunicaciones, despertar o dormir, duplicación de tareas, etc.
Solo la metodología DESIRE implementa correctamente el proceso de identificación
de agentes guiado por componentes en sentido bottom-up.
En la siguiente figura podemos ver el mapa metodológico de DESIRE:
Diseño conceptual
Descripción del problema
Diseño racional
Diseño conceptual
Diseño conceptual
Ilustración 12: Mapa metodológico DESIRE
53
 Problem description (descripción del problema): contiene los requerimientos

impuestos en momento de diseño.
 La fase de diseño se divide en tres subfases:
o Conceptual design (diseño conceptual): debe incluir el diseño
conceptual de cada agente, para el entorno y para las interacciones.
o Detailed design (diseño detallado): especifica todos los aspectos del
comportamiento y conocimiento del sistema.
o Operational design (diseño operacional): especifica los parámetros
necesarios para la implementación.
 Design rationale (diseño racional): cada subfase anterior debe estar sostenida
por un diseño racional
Un agente estándar tiene los siguientes componentes:

 Componente de mantenimiento de información del mundo (mundo externo)
 Componente de gestión de interacción con el mundo (recibe información del
mundo exterior, razona sobre ella y la almacena en el componente de
mantenimiento de información del mundo)
 Gestor de mantenimiento de información del agente (información interior)
 Gestor de interacción del agente (recibe la información razonada por el agente
que influencia la salida de información del agente)
 Tarea específica del agente (almacena las tareas que tiene el agente al
momento. Es la encargada de seleccionar la tarea instantánea que debe
realizar el agente)
 Control propio del proceso (son los objetivos del agente)
DESIRE tiene ventajas: permite una delimitación clara entre componentes y tareas,
permite una buena modularidad, el lenguaje para especificación formal permite un
diseño conceptual y un diseño detallado, utiliza una herramienta gráfica para el diseño
y especificación; y tiene herramientas de verificación para chequear consistencia,
acciones completas y correctas. Otra ventaja es que la herramietna de prototipade
está construida en SWIProlog y se integra fácilmente con JAVA.
5.3.7. Metodología: Gaia
La metodología GAIA[46] [47] descripta inicialmente por Wooldridge, Jennings y Kinni en

el año 2000. El alcance de la metodología abarca las fases de análisis y desarrollo
dejando fuera los requerimientos, la implementación y el testing.
GAIA describe los aspectos macro, los aspectos societales; y los aspectos micro, los
aspectos intra-agente. Toma al sistema como una sociedad organizada de individuos.
54
Como todas las metodologías, GAIA define conceptos. En éste caso los conceptos
pueden ser concretos o abstractos:
 Concretos (son los resultados del diseño del sistema)
o Tipos de agentes
o Servicios
o Conocimientos
 Abstractos (conceptualizan el sistema durante el análisis)
o Sistema
o Roles
o Permisos
o Responsabilidades
o Protocolos
o Actividades
o Propiedades de seguridad
o Propiedades de vida
El proceso de GAIA consiste en construir una serie de modelos de forma ordenada

como lo indica la siguiente figura:
Especificación
requerimientos
Modelo de
Modelo de roles Fase de Análisis
interacción
Modelo de Modelo de Modelo de Fase de Diseño

agentes servicios conocimientos
Ilustración 13: Fases GAIA
Como se mencionó más arriba, la especificación de requerimientos queda afuera de

la metodología GAIA.
El objetivo de la fase de análisis es comprender el sistema y su estructura.
Comprender la organización sabiendo que es un conjunto de roles y las relaciones
entre ellos, de manera que se deben generar un modelo de roles y un modelo de
interacciones.
Conceptualmente puede resumirse el análisis en el siguiente gráfico:
55
Sistema
Roles Interacciones
Responsabilidades Permisos
Seguridad Tiempo de vida
Ilustración 14: Fase de análisis GAIA
Como se mencionó más arriba, en la fase de análisis deben desarrollarse dos

modelos:
 Modelo de roles: El objetivo de este modelo es identificar los roles claves en el
sistema. Es una descripción abstracta de una función. Cada rol posee dos tipos
de atributos: permisos (o derechos – los recursos que puede utilizar) y
responsabilidades (que debe hacer el rol), que responden a dos categorías: el
ciclo de vida (lo que debe hacer) y la seguridad (especificado por una lista de
predicados y límites).
ROL Nombre_del_rol
Descripción Descripción del rol
Protocolos y actividades Los protocolos y actividades en los que el rol está
involucrado
Permisos Permisos o derechos asociados al rol
Responsabilidades
Ciclo de vida Responsabilidades en el ciclo de vida, lo que debe
hacer
Seguridad Listado de predicados sobre los límites del rol
Tabla 5: Tabla de rol

 Modelo de interacciones: Entre los roles hay dependencias y relaciones. Un
agente solitario que no interactúe con nada, no tiene sentido. El objetivo de este
modelo es mostrar las dependencias e interacciones de los agentes definiendo
protocolos que deben tener las siguientes propiedades:
o Propósito: descripción del protocolo
o Iniciador: agente que inicia la interacción
56
o Destinatario: agente destinatario de la interacción

o Entradas: parámetros usados por el rol iniciador al activar el protocolo
o Salidas: información suministrada por el destinatario.
o Proceso: descripción del proceso que debe realizar el iniciador durante
la interacción.
El proceso de análisis puede resumirse:
Identificar roles
Análisis
Ilustración 15: Proceso de análisis GAIA

El objetivo de la fase de diseño es transformar los conceptos abstractos (que fueran
definidos durante el proceso de análisis) en conceptos concretos. Esta fase requiere
de la generación de tres modelos como se vio en la primera parte de éste punto:
 Modelo de agentes: documenta los tipos de agentes que se usarán en el
sistema y las instancias de agentes necesarios al tiempo de ejecución. Un tipo
de agente implementa un rol específico del modelo de roles. El modelo se
define utilizando un árbol de agentes.
 Modelo de servicios: debe generarse con los servicios identificados que debe
proveer cada rol de agente. Es la funcionalidad del agente.
 Modelo de conocimientos: define las comunicaciones que existen entre los
tipos de agentes. No define qué mensajes deben ser enviados ni cuándo
hacerlo. Sólo el camino de comunicación (permite prever cuellos de botella).
El proceso de desarrollo puede esquematizarse de la siguiente manera:
Generar tipos de agentes Documentar las

desde los roles. instancias de los
Armar jerarquía agentes Desarrollar modelo de servicios usando las propiedades Desarrollar el modelo de conocimientos desde los
de los roles modelos de agentes t de servicios
Crear modelo de agentes
Ilustración 16: Proceso de desarrollo GAIA
57
La metodología GAIA es muy buena para desarrollar sistemas multi-agentes de

mediana y gran escala, funciona en un ambiente abierto y dinámico, se puede
garantizar comportamientos seguros y predecibles, y da al agente una posición bien
definida y un comportamiento esperado.
GAIA tiene puntos en los que no es muy bueno: es cerrado y estático, tiene
requerimientos inusuales, no maneja bien el diseño del entorno del agente y no abarca
el proceso completo de desarrollo de software (no contempla la toma de
requerimientos, el desarrollo y el testing).
5.3.8. Metodología: INGENIAS
La metodología INGENIAS[48] [49] se basa en investigaciones de ingeniería guiada por

modelos (Model-Driven Engineering - MDE) que se enfoca en crear y explotar modelos
de dominio, que son modelos conceptuales de todos los elementos referidos a un
determinado problema. INGENIAS es una metodología acompañada de herramientas
para poder modelas sistemas multi-agentes.
Ingenias se basa en cinco puntos de vista:
 Punto de vista de la organización: es un conjunto de entidades con relaciones
y jerarquías, compuestas de grupos y flujos de trabajo. Lo grupos pueden
contener agentes, roles, recursos o aplicaciones.
 Punto de vista del agente: Un agente procesa conocimiento y sigue el principio
de racionalidad. Muestra la funcionalidad de cada agente: roles (con sus
propósitos y responsabilidades). Cada agente tiene su estado mental, un gestor
de estado mental y un procesador de estado mental.
 Punto de vista de tareas y objetivos: describe las consecuencias de ejecución
de las tareas y cómo logra los objetivos.
 Punto de vista de interacción: es el intercambio de información entre los
agentes y de los agentes con su entorno.
 Punto de vista del entorno: define los elementos con los que interactúa el
sistema multi-agentes (Recursos, otros agentes y aplicaciones).
El proceso envuelve a dos flujos: Análisis y Diseño, con tres fases cada uno:
Comiendo, elaboración y construcción.
 Análisis:
o Comienzo: Como está basado el RUP, lo inicial es identificar los actores
y los casos de uso en los que se encuentran involucrados. Esos casos
de uso deben modelar la organización y deben tomar los elementos de
interacción con el entorno. Se modeliza a los actores como agentes que
deben cumplir con esos casos de uso. Debe guiarse por los puntos de
vista enunciados previamente.
58
o Elaboración: Es una tarea iterativa de refinación de los casos de uso y

de los agentes obtenidos en la fase anterior agregando todos los
elementos que se consideren necesarios. Debe prestarse atención a la
interacción entre los agentes.
o Construcción: Generar modelos necesarios para que los agentes
cumplan con los casos de uso.
 Diseño:
o Comienzo: Generar prototipos de los agentes para cumplir con los
modelos obtenidos durante el análisis. Se pueden usar herramientas
como Zeus o Agent Tool o herramientas convencionales como JAVA,
C++, Pascal, etc.
o Elaboración: refinar los flujos de trabajo, armar modelos de interacción
que visualicen el modo de ejecución de las tareas, realizar un modelo de
tareas y objetivos para lograr los flujos de trabajo, y modelar los agentes
para establecer los requerimientos del estado mental necesario.
o Construcción: generar nuevos modelos y establecer las relaciones entre
los agentes que regulen el comportamiento organizacional
Este proceso de desarrollo se puede seguir fácilmente utilizando el INGENIAS
Development Kit (IDK).
Posee una plataforma para análisis, diseño e implementación de sistemas multi-
agentes basado en JAVA. Se basa en la especificación de metamodelos de SMA con
herramientas como el editor y generador de código que puede encontrarse en el
Proyecto ingenias.
5.3.9. Metodología: MaSE
MaSE[50] [51] fue concebida como extensión de la metodología de software orientada a

objetos. Ha sido desarrollada por Instituto de Fuerza Aérea de los Estados Unidos de
Norteamérica como alternativa para el desarrollo de soluciones para problemas de
búsqueda. Fue desarrollada por Booch. Esta metodología no trata a los agentes como
autónomos o proactivos. Toma a los agentes como procesos simples que interactúan
unos con otros para cumplir con los objetivos del sistema.
La metodología MaSE involucra básicamente:

 Análisis
o Captura de requerimientos: establecer el entorno del sistema, los
objetivos, los sub-objetivos y jerarquía de objetivos. Es importante que
se ordenen los objetivos por relevancia.
o Búsqueda de casos de uso: con lo obtenido en el punto anterior, se
definen los casos de uso y los diagramas de secuencia. Las
59
conversaciones entre los agentes son la base de un sistema multi-

agentes.
o Refinamiento de roles: basado en la estructura de objetivos obtenida se
construyen los roles. Los roles son descripciones abstractas que
describen la funcionalidad que se le va a asignar a los agentes. Debe
comprenderse que un objetivo siempre genera, al menos, un rol. Los
roles impactan en el “modelo de roles”, junto con la comunicación entre
roles.
 Diseño
o Creación de clases de agentes: generación de las clases de agentes,
tomando como origen a los roles definidos y las comunicaciones entre
ellos. En el diagrama de clases de agentes, las líneas de unión no
representan herencia ni jerarquía, representa comunicación.
o Construir conversaciones: diseñar la interacción entre los agentes. Esta
fase está muy vinculada a la siguiente que es ensamblar agentes. Las
comunicaciones son agente a agente, no multi-cast. En esta fase se
definen los protocolos que permiten interactuar a los agentes. Se usan
diagramas de transición.
o Crear clases de agentes: generar la arquitectura de agentes de acuerdo
a los roles definidos previamente. Es en esta fase en la que se crea la
operatoria interna del agente: si va a ser reactivo, BDI, planeador,
basado en conocimientos, etc.
o Diseño del sistema: Fase final. Es el punto en donde se instancian los
agentes en base a las clases de agentes definidos. Se usa un diagrama
de despliegue. En esta fase se definen los parámetros del sistema,
cantidad de agentes, tipos de agentes, ubicación de los agentes, etc.
AgentTool es una herramienta desarrollada para poder soportar MaSE: crea clases
de agentes, construye conversaciones y ensambla las clases de agentes.
5.3.10. Metodología: MASSIVE
La metodología MASSIVE[52] (MultiAgent SystemS Iterative View Engineering) es un

marco de trabajo pragmático para desarrollo de sistemas multi-agentes. La
implementación es uno de los resultados del diseño iterativo.
MASSIVE, se basa en vistas. Cada vista tiene elementos agrupados
conceptualmente.
60
Vista de
entorno
Vista de
Vista de
arquitectura
Tareas
Vista de
sistema
Vista de
Vista de
roles
sociedad
Vista de
interacción
Ilustración 17: Vistas MASSIVE
Las vistas con las que trabaja MASSIVE son:

 Vista de entorno: esta vista tiene dos perspectivas diferentes: el punto de vista
del desarrollador (es completo, puede ver todo el entorno del sistema) y el punto
de vista del sistema (que es más limitado, el agente sólo ve parte del entorno).
 Vista de tareas: aquí se analiza la funcionalidad del sistema. El resultado es
una jerarquía de tareas que se utilizarán para determinar las capacidades de
los agentes. En esta vista también se definen los requerimientos no
funcionales.
 Vista de roles: en esta vista se asignan las tareas. Un rol es una abstracción
que vincula un grupo de tareas y permisos.
 Vista de interacción: la interacción dentro del sistema, no se refiere sólo a
comunicación entre agentes, es una forma generalizada de resolución de
conflictos. En esta vista se desarrollan todas las interacciones del sistema.
 Vista de sociedad: Una sociedad es una colección de entidades
interrelacionadas. En esta vista se deben clasificar la sociedad y las medidas
para analizar su performance. Debe ser consistente con las vistas previamente
descriptas.
 Vista de arquitectura: aquí se describen las arquitecturas de agentes que se
usarán de acuerdo a las necesidades de los objetivos del sistema.
 Vista de sistema: en esta vista se consignan los aspectos que afectan a más
de una de las vistas anteriores. Por ejemplo: el manejo de errores, las interfaces
de usuario, la performance del sistema y el despliegue del sistema.
Esta metodología es iterativa y se va mejorando en cada uno de los ciclos. La
información inicial, que siempre es incompleta, se va mejorando y completando.
61
5.3.11. Metodología: MESSAGE
La metodología MESSAGE[53], al igual que GAIA, cubre el análisis y el diseño de

sistemas multi-agentes. Se basa en UML, y la extiende agregándoles conceptos como
organización, roles, objetivos y tareas.
MESSAGE adoptó el RUP (Rational Unified Process) como marco de trabajo para el
ciclo de vida del proyecto.
Los conceptos específicos de MESSAGE son:
 Agente
 Organización
 Rol
 Objetivo
Y las actividades:
 Tarea
 Servicio
 Interacción
 Protocolo de interacción
Estos conceptos se relacionan de la siguiente manera (gráfico tomado de [53]):

62
Ilustración 18: Relación entre objetos MESSAGE

El proceso de desarrollo incluye:
 Análisis (Se realiza a través de niveles que van iterando)
o Creación del modelo de organización
o Creación del modelo de Objetivos y tareas
o Creación del modelo de agentes y roles
o Creación del modelo de dominio
o Creación del modelo de interacción
 Diseño (También se realiza a través de mejora iterativas)
o Proceso de alto nivel
 Asignación de roles a agentes
 Utilizando tareas, proveer los servicios
 Refinar los protocolos de interacción
 Especificar el comportamiento de interacción de los roles con
diagramas de estado
o Proceso de diseño detallado
 Definir la arquitectura de sistema multi-agente
 Seleccionar una arquitectura de los agentes
 Especificar el comportamiento de los agentes y sus interfaces
 Usando ingeniería de software convencional, detallar la
arquitectura interna del agente
 Definir la estructura de la sociedad de agentes.
63
Los diagramas que se trabajan en MESSAGE son:

 Diagrama de organización
 Diagrama de implicación objetivo-tarea
 Diagrama de delegación
 Diagrama de flujos de trabajo
 Diagrama de agentes
 Esquema de agente
 Esquema de roles
 Diagrama de interacción
 Diagrama de protocolo de interacción
 Diagrama ontológico
5.3.12. Metodología: Prometheus

La metodología Prometheus[54][55][56] es de propósito general y una metodología
basada en agentes, práctica, pragmática. Pone énfasis en la determinación de los
objetivos del sistema y funcionalidades, es iterativo por naturaleza y está soportado
por herramientas (Prometeus Desing Tool – PDT y Jack Development Environment –
JDE)
Prometheus tiene ciertas diferencias con respecto a otras metodologías:
 Soporta el desarrollo de agentes con sus propios objetivos, planes y eventos,
no como un proceso separado enfocado a los objetivos del sistema.
 Abarca todo el proceso de desarrollo de software: desde las especificaciones
hasta la implementación pasando por el análisis, diseño y diseño detallado.
 Evolucionó gracias a experiencias industriales y pedagógicas.
 Provee estructuración jerárquica que permite diseñar en múltiples niveles de
abstracción.
 Usa proceso iterativo más que un modelo de cascada.
 Tiene verificaciones cruzadas de los artefactos de diseño.
 Tiente una herramienta (PDT) que está diseñada como un plugin de Eclipse
que permite trabajar a lo largo del proceso (Especificación del sistema, diseño
de alto nivel o arquitectura y diseño detallado).
 Tiene que ser de uso sencillo para que lo usen desarrolladores de software
industrial y estudiantes.
Las fases por las que pasa la metodología Prometheus son:

 Especificación del sistema: se especifica el sistema usando
o Escenarios
o Objetivos del sistema
o Funcionalidades
o Interfaz del sistema en términos de acciones, percepciones y datos
externos.
64
 Diseño de alto nivel (arquitectura): es donde se identifican los tipos de agentes

y se captura la estructura en:
o Diagrama de sistema
o Diagramas de interacción
o Protocolos de interacción
o Casos de uso de los escenarios
o Descriptores de agentes
 Diseño detallado: Se desarrollan los detalles internos de los agentes

o Diagramas de procesos (se usan para coordinar los protocolos de
interacción y los planes)
o Descriptores de planes
o Descriptores de datos
o Descriptores de eventos
o Capacidades.
Los modelos que utiliza son:
Modelos dinámicos Modelos de resumen Descriptores de

estructurales entidad
Especificación del Escenarios Objetivos Funcionalidades,

sistema acciones y
percepciones
Diseño de (diagramas de (Diagramas de Agentes

arquitectura interacción) acoplamiento de Mensajes
datos)
Protocolos de
(conocimietno del
interacción
agente)
resumen del sistema
Diseño detallado Diagramas de Resumen de agente Capacidades

procesos Resumen de Planes, datos y
capacidades eventos
Tabla 6: Tabla de modelos de Prometheus
La notación en el diagrama de resumen del sistema es (tomado de [56]):
65
La notación en el diagrama de resumen de agente (tomado de [56]):
5.3.13. Metodología: RETSINA
El proyecto RETSINA[57][58][59] es una iniciativa del Robotics Institute –

Carnegie Mellon University (Pittsburgh Pennsylvania) desde 1995. RETSINA
es la sigla de REusable Task Structure-based Intelligent Network
Agents. (Red de agentes inteligentes basado en estructuras de tareas
reusables). Originalmente se desarrolló para búsqueda de información
distribuida.
Los agentes diseñados con ésta metodología operan de manera asincrónica
y colaboran tanto entre ellos como con los usuarios intercambiando servicios
e información. Deben ser capaces de manejar interacciones sociales
complejas siguiendo complejos protocolos de comunicación.
La infraestructura multi-agentes y la de un agente individual se podrían

conceptualizar de la siguiente manera (Traducido de [59]):
Infraestructura Multi-agentes Infraestructura de agente individual
Interoperacion Multi-agentes Inter-operación

Servicios de traducción - Servicios de interoperación Módulos de interoperación
Capacidad de mapeo de agentes Mapeo de capacidad a agente

Agentes medios Componentes medios de agentes
Mapeo nombre a ubicación Mapeo nombre a ubicación

ANS Componente ANS
Seguridad Seguridad
Autoridad de certificación - Servicios criptográficos Módulo de seguridad - Claves públicas/privadas
Servicios de performance Servicios de performance

Monitoreo del sistema - Servicios de reputación Módulos de servicios de performance
Servicios de gestión multi-agentes Servicios de gestión

Logging - Visualizador de Actividad Lanzamiento Logging - Componentes de visualización
Infraestructura ACL Infraestructura ACL

Ontología pública - Servidores de protocolos ACL Parser - Ontología privada - Máquina de protocolo
66
Infraestructura de comunicaciones Módulos de comunicaciones

Descubrimiento - Transferencia de mensajes Componente de descubrimiento - Módulo de transferencia
de mensaje
Entorno operativo
Máquina, S.O., Red – Multicast - Capa de transporte: TCP/IP, Inalámbrico, infrarrojo, SSL
Tabla 7: Infraestructura Multiagentes
En RETSINA, sería:
Infraestructura de agente individual

Infraestructura Multi-agentes
Interoperacion Multi-agentes
interoperador RETSINA-OAA
Capacidad de mapeo de agentes Mapeo de capacidad a agente

Matchamaker Módulo Matchmaker
Mapeo nombre a ubicación Mapeo nombre a ubicación

ANS Componente ANS
Seguridad Seguridad
Autoridad de certificación - Servicios criptográficos Módulo de seguridad - Claves públicas/privadas
Servicios de performance Servicios de performance

Monitoreo de fallas Automonitoreo - clonación
Servicios de gestión multi-agentes Servicios de gestión

Logging - Visualizador de Actividad - Lanzamiento Módulo de logueo
Infraestructura ACL Infraestructura ACL

Ontología pública - Servidores de protocolos ACL Parser - Ontología privada - Máquina de protocolo
Infraestructura de comunicaciones Módulos de comunicaciones

Descubrimiento - Transferencia de mensajes Componente de descubrimiento – Comunicador RETSINA
Entorno operativo
Máquina, S.O., Red – Multicast - Capa de transporte: TCP/IP, Inalámbrico, infrarrojo, SSL
Tabla 8: Infraestructura RETSINA
En RETSINA, la comunicación entre agentes se realiza usando KQML.
Gráficamente se puede representar la estructura multi-agentes RETSINA de la

siguiente manera:
67
USUARIO 1 USUARIO 2 USUARIO m Resultados

Especificadiones
de objetivos y
tareas
AGENTE DE AGENTE DE AGENTE DE
INTERFAZ 1 INTERFAZ 2 INTERFAZ p Soluciones
Tareas
AGENTE DE AGENTE DE AGENTE DE

TAREA 1 TAREA 2 TAREA q
Pedidos de
servicio e Integración de
Resolución de
información información
conflictos
AGENTE DE Agente AGENTE DE

INFORMACIóN intermediario INFORMACIóN
1 1 n
Respuestas
Respuestas
Origen de
infromación1 Origen de
infromación r
Origen de
infromación1
Ilustración 19: Estructura RETSINA
Si analizamos la estructura de un agente RETSINA, se encontrará, al menos, cuatro

módulos:
1. Módulo de comunicación y coordinación

2. Módulo de planeamiento
3. Módulo de agendamiento
4. Módulo de ejecución
Graficamente
68
Ilustración 20: Módulos RETSINA
RETSINA se aplica en: Gestión de protocolos financieros, Negociaciones de comercio

electrónico, mantenimiento de aeronaves, Dominios logística, etc.
5.3.14. Metodología: SONIA
SONIA[60] es la sigla de Sets of mOdels for a Natural Identification of Agents (Conjunto

de modelos para una identificación natural de agentes) apunta a la resolución de
problemas.
Abarca dos fases y dos sub-fases cada fase:
 Análisis
o Conceptualización
 Modelo estructural inicial: describe la estructura del dominio del
problema.
 Modelo de tarea inicial: cómo los problemas hallados en el
dominio son solucionados (basados en tareas y métodos)
o Análisis extendido
 Modelo de entorno: define las entidades externas al sistema y sus
interacciones.
 Modelo estructural: describe las estructuras que proviene del
dominio de conocimientos, de las entidades externas.
 Modelo de tareas: funcionalidades necesarias para interactuar
con las entidades definidas en el modelo de entorno.
 Diseño
o Síntesis
69
Modelo de conocimiento: Identifica los componentes tomados del

modelo estructural agrupados y que van a ser usados por los
agentes.
 Modelo de comportamiento: se obtiene agrupando todas las
tareas que están en el modelo de tareas.
 Modelo de responsabilidad: asigna componentes de
conocimientos a comportamientos. Esto guiará a identificar los
agentes.
o Diseño de arquitectura
 Modelo de objetos: de los datos obtenidos en los modelos de
análisis se deben identificar los elementos pasivos que son parte
del entorno.
 Modelo de agentes: Con los datos obtenidos en los modelos de
análisis, se seleccionan cuáles serán los agentes autónomos (con
sus objetivos, tareas y conocimientos)
 Modelo de interacción: identifica las relaciones entre los agentes,
y los agentes con los objetos.
5.3.15. Metodología: TROPOS
La metodología TROPOS[61][62][63][64] fue propuesta en el 202 por Mylopoulos, Kolp y

Giorgini.
Es una metodología de desarrollo de software orientado a agentes. Guiada por los
requerimientos y pasa por las cinco fases:
1. Análisis de requerimientos tempranos: se enfoca en las intenciones de los
actores claves. Esas intenciones u objetivos pueden modelarse como casos de
uso para simplificar el intercambio de información de los actores. Como es un
análisis guiado por objetivos, las intenciones u objetivos hallados deben
convertirse en requerimientos funcionales y no funcionales. Para ello Tropos
cuenta con una herramienta: i*. Es un marco de trabajo que establece modelos
y utiliza concepto de acuerdo a las necesidades del proyecto. En ésta fase se
genera un Modelo estratégico de dependencias (es un gráfico que involucra a
los actores que tienen dependencias estratégicas a tener en cuenta, Esas
dependencias se denominan acuerdos).
Hay varios tipos de dependencias:
a. Dependencia objetivo (goal dependency): es la delegación de
responsabilidad.
b. Dependencia objetivo blando (softgoal dependency): similar al anterior
pero el grado de dependencia es subjetivo.
c. Dependencia de tarea (Task dependency): es para los casos en los que
la dependencia sólo es necesaria en caso de que sea necesaria para la
ejecución de una tarea.
70
2. Análisis de requisitos tardíos: genera una especificación de requerimientos con

los requerimientos recabados, tanto los funcionales como los no funcionales.
El modelo se extiende con un nuevo actor que representa al sistema. Se
establecen las dependencias de este nuevo actor con los ya existentes. Se
genera el modelo racional estratégico (es un grafo con cuatro tipos de roles:
objetivo, tarea, recurso y objetivo blando; que se une con dos tipos de enlaces:
enlace de descomposición y enlace de medios-fines)
3. Diseño de arquitectura: permite establecer la arquitectura global del sistema
definiendo los subsistemas como acores y se agregan las dependencias como
flujos de control. Constituye in modelo de la estructura de sistema sencillo que
describe cómo los componentes funcionan juntos.
4. Diseño detallado: explota detalles adicionales a cada uno de los componentes
del sistema mencionados en el punto anterior. Incluye las especificaciones de
comunicación entre agentes y el comportamiento de cada agente.
5. Implementación: sigue paso a paso las especificaciones del diseño detallado.
Para la aplicación de estos pasos, Tropos cuenta con un marco de trabajo que está
formado por dos diagramas:
 Diagrama de actores: es un modelo gráfico en donde se encuentras los actores,
sus metas y las dependencias entre los actores.
 Diagrama de metas: En éste gráfico se consignan la metas, dependencias y
planes de los distintos actores, y las dependencias.
En tropos hay primitivas gráficas con su respectivo concepto y su representación
gráfica:
 Actor: entidad con metas estratégicas. Puede ser una persona, todo un
sistema, un rol o una posición.
 Agente: un actor con manifestaciones concretas. Puede ser una persona o un

agente software. El agente tiene dependencias que dependen del rol que está
ocupando.
 Rol: elemento abstracto que representa el comportamiento de un agente.
 Posición: abtracción entre un rol y un agente. Se dice que un agente ocupa una
posición cuando cumple con cierto conjunto de roles.
 Asociación: es un conjunto de roles, posiciones y/o agentes.

 Objetivo: son objetivos que representan los intereses de un actor.
71
 Objetivo blando: es similar a los objetivos, pero queda a criterio si debe

cumplirse necesariamente o no.
 Plan: Este elemento es una tarea. Un conjunto de operaciones a ser llevadas a

cabo por el/los agentes.
 Recurso: entidad física o de información a ser accedida o compartida.
 Dependencias:
o Dependencia de objetivo: Un actor depende de otro para cumplir con un
objetivo.
o Dependencia de objetivo blando: Esta dependencia es similar a la

anterior sólo que el objetivo a cumplir es un objetivo blando.
o Dependencia de plan: Se establece una dependencia de este tipo para

realizar una tarea. Cuando se usa esta dependencia, es importante
aclarar la manera a realizarse el plan.
o Dependencia de recurso: Una agente depende de otro para dar uso a

un recurso o entregar información.
Tropos tiene algunas críticas. No está bien adecuada al mundo real, todavía está en
desarrollo y aún no ha madurado en la especificación y diseño de agentes de sistema
5.3.16. Metodología: ZEUS
La metodología ZEUS [65][66][67][68] es un sistema de agentes de código abierto. Está

escrito en java y fue desarrollado por los laboratorios de British Telecom.
Zeus define una metodología de diseño de sistemas multi-agentes y lo soporta
mediante un entorno visual para capturar las especificaciones. Estas especificaciones
generan luego código JAVA.
Zeus está diseñado para facilitar el rápido desarrollo de aplicaciones multi-agentes
evitando que el desarrollador vea lo intrincado del desarrollo de sistemas multi-
agentes y pueda enfocarse en resolver el problema en cuestión.
Zeus tiene seis pasos para el desarrollo:
 Estudio de dominio e identificación de agentes: El desarrollador analiza el
dominio del problema buscando candidatos a agentes.
 Definición de agentes: Deben identificarse los atributos importantes de los
agentes, los recursos iniciales que necesita.
72
 Definición de tareas: Se analiza y detallan las tareas que debe realizar cada
agente.
 Organización de los agentes: Una vez definidos los agentes y las tareas que
realizan, debe analizarse los conocidos de cada agente, que información
pueden requerir y qué información deben compartir, formando una especie de
organización de los agentes.
 Coordinación de los agentes: Se definen los protocolos de comunicación de
cada agente, lo que permite que trabajen coordinados.
 Generación de código y implementación de tareas: una vez que está todo
definido, las herramientas permiten la generación del código y la prueba de lo
desarrollado.
Graficamente [69]
Ilustración 21: Pasos de metodología ZEUS
Zeus, además de ser una metodología de desarrollo de sistemas multi-agentes, posee

un conjunto completo de herramientas para construir aplicaciones multi-agentes
colaborativas incluyendo un IDE para desarrollo.
Zeus es un conjunto de componentes JAVA categorizados en tres grupos funcionales:
Librería de componentes: son las clases que forman los bloques de construcción de
los agentes. Provee un lenguaje de comunicaciones asincrónico (basado en actos del
habla), un lenguaje de representación de conocimientos basados en frames, un
planificador de propósito general, un mecanismo cooperativo de resolución de
problemas, un motor que controla el comportamiento social del agente, etc.
Herramientas de construcción de un agente: Contiene un conjunto de editores para
ontologías del dominio, de hechos y variables, de definiciones de agentes (describe
lógicamente los agentes) y de coordinación (para seleccionar el conjunto de
protocolos de coordinación entre agentes).
73
Agentes utilitarios ZEUS: Agentes servidores de nombres, facilitador de

descubrimiento de la información, Agente para visualizar o realizar debugging de
sociedades de agentes.
Ilustración 22: Kir de herramientas ZEUS

En el gráfico[69] podemos ver los componentes del Kit de herramientas de
construcción de agentes ZEUS.
74
PARTE II: Desarrollo de la

metodología y diseño de una
aplicación.
75
6. Metodología MeDeSMAGF de desarrollo de sistemas

multiagentes.
6.1. Introducción
En los capítulos precedentes se intentó dar una visión a vuelo de pájaro de lo que es
la teoría en sistemas multi-agentes.
Este marco teórico permite poder comprender qué es lo necesario para definir y tener
en cuenta al momento de armar una metodología de desarrollo de sistemas multi-
agentes: Como se conforma un agente y qué tipos de agentes podemos usar en
nuestros sistemas, cómo se comunican los agentes, cómo es posible la coordinación
entre ellos y los desarrollos hechos por los investigadores en torno a metodologías
que nos puedan servir como guía en el desarrollo de la parte final de este trabajo.
La intención es que la metodología pueda aplicarse a sistemas informáticos, sistemas
humanos y sistemas mixtos, por ello se dejan de lado las condiciones referentes a los
lenguajes de programación que deberían surgir a fines de la etapa de diseño.
La mayoría de las metodologías de desarrollo de software tienen diferentes fases que
pueden tener nombres que pueden variar como captura de requerimientos, análisis,
diseño, desarrollo, pruebas e implementación.
En el desarrollo de agentes podemos ver que muchas metodologías abarcan solo las
fases de análisis y diseño dejando libertad en las otras. En el presente trabajo se
intentará cubrir el proceso completo de desarrollo de software.
6.1.1. Propósito de la sección
El propósito de ésta sección es el de comprender la metodología MeDeSMAGF para

el desarrollo de sistemas multi-agentes (SMA).
6.1.2. Alcances de la sección
El alcance de ésta sección del documento es intentar definir la metodología

MeDeSMAGF y establecer los pasos necesarios para poder implementarla dejando
en claro los modelos a ser definidos en cada fase a fin de que el desarrollador
encuentre en ésta metodología una guía para su incursión en la programación multi-
agentes.
76
6.1.3. Notación
A fin de unificar la creación de nombres, MeDeSMAGF sugiere utilizar una

modificación de la notación Húngara.
La notación húngara consiste en utilizar prefijos en minúsculas que preceden al

nombre del concepto y que permite reconocer de qué tipo se trata. El resto del nombre
identifica unívocamente al concepto en cuestión. La modificación que se sugiere es
que se utilicen, en el prefijo, tres letras en minúsculas de acuerdo a lo enunciado en
la definición de cada uno.
De la misma forma, el nombre unívoco que se coloca luego del prefijo, será un
sustantivo (o construcción sustantiva), una acción (verbo o construcción verbal) o un
adjetivo; según se enuncie en las definiciones que se describirán a continuación.
6.1.4. Definiciones y conceptos
Si bien durante toda la introducción teórica se han desarrollado los conceptos que se
definirán a continuación, es importante que se entienda qué significan en el contexto
de ésta metodología.
MeDeSMAGF se basa en la generación y depuración de fichas.
A fin de facilitar el proceso de desarrollo, a modo de guía, se definirá, para cada
concepto, la ficha que debería ser completada y refinada durante el proceso de
desarrollo de software.
Las fichas junto a los modelos a los que deban incorporarse, forman la columna
vertebral de ésta metodología.
6.1.4.1. Objetivo
Los objetivos o metas son los intereses que tienen los diferentes actores.
Los objetivos los podemos clasificar:
Según el ámbito de aplicación:
77
 Objetivos generales del sistema: Son los intereses generales para el

desarrollo del sistema. Todo el resto de los objetivos tienen que estar
subordinados a éste. Deben estar perfectamente definidos en etapas
tempranas del proyecto.
 Objetivos particulares de los agentes: Son los intereses que deben cumplir
los agentes. Estos objetivos deben estar enfocados con el fin de satisfacer los
objetivos generales del sistema.
Según la obligatoriedad de ejecución:
 Objetivos primarios u obligatorios: Este tipo es de ejecución obligatoria.

Apuntan al éxito del sistema y que marcan la funcionalidad obligatoria del
sistema. Son el norte del proyecto.
 Objetivos secundarios u opcionales: los objetivos opcionales se encuentran
con mínima prioridad en el desarrollo. Nunca estos objetivos deben obstaculizar
el desarrollo de los objetivos obligatorios
Como se ha mencionado al principio de este punto, durante el proceso se

confeccionará una tarjeta de objetivos que se irá completando y modificando a medida
que se van pasando por las distintas fases.
En las diferentes fases se irán detallando el modo de llenado y combinación de las
fichas.
78
Tabla 9: Ficha de objetivos
Ficha de objetivos
Nombre del objetivo Tipo de objetivo:
Descripción
Actividades: Roles:
Recursos:
Restricciones:
Tabla 10: Ficha de objetivos
A fin de poder determinar los objetivos debe partirse de los objetivos del sistema multi-
agentes e ir retrocediendo hasta llegar a los objetivos unitarios que se le asignarán a
los diferentes planes o roles.
Esquema:
En los modelos, los objetivos se esquematizarán como una elipse con el nombre del
objetivo inserto en ella:
79
Objetivo primario
Ilustración 23: Esquemático objetivo obligatorio
Objetivo secundario
Ilustración 24: Esquemático objetivo optativo
Notación:
Prefijo: obj
Identificador: Verbo o frase verbal que indica la acción.
6.1.4.2. Entorno
El entorno, también llamado medio, es todo lo que rodea al sistema y tiene algún tipo
de interacción con él.
Es el que brinda los recursos para que pueda operar el sistema multi-agentes. El
entorno incluye, y no está limitado a, lugar de operación (en caso de ser sistemas
humanos o mixtos), equipamiento, sistema operativo, memoria, etc.
Los entornos pueden ser estáticos en donde está básicamente definido y no tiene
mucho cambio a lo largo del tiempo de ejecución del sistema multi-agentes; o
dinámicos en donde la información es incierta y no siempre completa, de manera que
debería analizarse el uso de lógica difusa. Es posible definir más de un entorno que
se conecte al sistema. Con esto se puede determinar que el sistema debe funcionar
inmerso en varios entornos, posiblemente con diferentes recursos.
El entorno debe estar bien descripto y no debe omitirse nada que pueda afectar al
sistema.
Esquema:
El entorno se representa en los modelos como una nube:
80
Entorno
Ilustración 25. Esquemático de entorno
Notación:
Prefijo: ent
Identificador: sustantivo o frase substantiva que identifique al entorno.
Ficha de entorno
Nombre del entorno:
Descripción
Actores: Roles:
Recursos: Restricciones:
Tabla 11: Ficha de entorno
81
6.1.4.3. Actor
El actor es, generalmente una entidad externa al sistema que tiene intereses sobre él,
exigiendo alguna funcionalidad. El actor no es necesariamente un humano, puede ser
otro sistema.
Lo primero que veremos en la captura de requisitos es la identificación de él o los
actores.
Ficha de actores
Nombre del actores: Tipo de actor:
Descripción
Recursos: Restricciones:
Agentes:
Tabla 12: FIcha de actores
Esquema:
En los modelos, representaremos a los actores como una personita. No importa si el

actor es humano, robótico o software.
82
Ilustración 26: Esquemático de actor
Notación:
Prefijo: act
Identificador: sustantivo o frase substantiva que identifique al actor.
6.1.4.4. Rol
En capítulos anteriores se ha definido el concepto de rol para las diferentes

metodologías. Para esta metodología, los roles son funcionalidades que realizan las
entidades que los asumen. Un mismo rol puede ser asumido por distintos agentes del
sistema y un agente del sistema puede asumir distintos roles dependiendo de
diferentes parámetros: situaciones, tiempos, necesidades del sistema, negociaciones,
etc.
Los roles tienen la funcionalidad para cumplir con los objetivos. Son los que
establecerán el comportamiento y la organización de los agentes. El elegir
correctamente los roles, permitirá diseñar el sistema más fácilmente.
La tarjeta que se ha diseñado para los roles es la siguiente:
83
Ficha de roles
Nombre del objetivo
Descripción
Actividades: Objetivos:
Agentes:
Planes: Restricciones:
Tabla 13: Ficha de rol

Esquema:
En los modelos se representa a los roles como cuadrados con el nombre del rol dentro:
Rol
Ilustración 27: Esquemático de role
Notación:
Prefijo: rol
Identificador: sustantivo o frase substantiva que identifique al entorno.
84
6.1.4.5. Agente
En el capítulo 3 de ha desarrollado extensamente la definición de agente de manera

que se verá someramente y se presentará la tarjeta.
A los fines de ésta metodología utilizaremos la definición desarrollada por Woodridge
[3]: "Un agente es un sistema informático situado en un entorno y que es capaz de
realizar acciones de forma autónoma, para conseguir sus objetivos de diseño"

Los agentes cumplen uno o más roles que son los que le darán la funcionalidad al
agente.
Como se ha visto, hay muchos tipos de agentes, y su comportamiento y funcionalidad
se verán definidos por los roles que asuma.
Ficha de agentes
Tipo de agente
Nombre del agente
Descripción
Roles: Actores
Tecnología utilizada:
Lenguajes de programación:
Ubicación del agente (indicar si es fijo o móvil)
Elementos de prueba del agente:
Ubicación del código
Tabla 14: Ficha de agentes
85
Esquema
Los agentes se representarán en los modelos como rectángulo con líneas verticales
en los costados y el nombre asignado al agente dentro:
Agente
Ilustración 28:Esquemático de agentes
Notación:
Prefijo: ent
Identificador: sustantivo o frase substantiva que identifique al agente.
6.1.4.6. Plan
Un plan es una secuencia de tareas o actividades que se asocia a un rol para que
cumpla con su objetivo.
Debe especificarse claramente la lista de actividades u tareas que integran el plan y
debe tenerse en cuenta que el plan puede ser extremadamente complejo. Se puede
desarrollar textualmente o utilizando diagramas de flujo.
86
Tabla 15: Ficha de roles
Esquema
Los planes se representarán en los modelos como:
Plan
Ilustración 29: Esquemático de plan
Notación:
Prefijo: pla
Identificador: acción o frase verbal que identifique al plan.
6.1.4.7. Protocolo
Es parte fundamental en los sistemas multi agente las comunicaciones entre los
agentes y los agentes y el entorno. A fin de definir las comunicaciones, se establecen
los protocolos de interacción. Los protocolos entre agentes y entre agente y entorno,
se graficará como un sistema de anda-niveles (para establecer la secuencia) y un
esquema de mensajes.
87
Se recomienda el uso de ACL (Agent Control Languaje) de FIPA (Foundation for

Intelligent Physical Agents)1 para la definición de los mensajes, aunque el tipo y modo
de comunicación debe surgir del análisis y del diseño. En el capítulo 4 se ha visto de
manera bastante completa la comunicación entre agentes.
Ficha de protocolo
Nombre del protocolo
Descripción
Rol de origen: Mensajes involucrados
Rol destino:
Secuencia de mensajes
Diagrama de secuencias:
Tabla 16: FIcha de protocolo
La estructura de los mensajes se consigna en la ficha de mensajes. Conviene realizar

uno por tipo de mensaje o, si se quiere, utilizar expresiones regulares para definir un
grupo de mensajes. Lo importante es que quede claramente expresado.
1ACL es la sigla de Agent Control Languaje un estándar de comunicaciones entre

agentes diseñado por FIPA.
88
Ficha de mensaje
Nombre del mensaje:
Descripción
Estructura del mensaje:
Tabla 17: FIcha de mensaje
Esquema:
En el modelo de agentes, las comunicaciones se representan como:
Protocolo
Mensaje
Ilustración 30: Esquemático de mensaje
Notación:
Prefijo: msg
Identificador: sustantivo o frase substantiva que identifique al mensaje.
89
Prefijo: prt
Identificador: sustantivo o frase substantiva que identifique al protocolo.
6.1.4.8. Acciones:
Las acciones son modificaciones producidas por un agente ya sea en el entorno o en

otros agentes del sistema. Las acciones se diferencian de los planes porque son
físicas. Se aplican sólo en los casos de que los agentes sean robóticos o humanos.
Normalmente las acciones complejas contienen un listado de acciones simples a
realizar generando una jerarquía
Ficha de acción
Nombre de la acción:
Descripción
Acciones/procedimiento: Restricciones:
Esquema:
Tabla 18: Ficha de acciones
Esquema:
En los modelos de agentes, las acciones se representan como:
90
accTomaPieza
Ilustración 31: Esquemático de acción

Notación:
Prefijo: acc
Identificador: verbo o frase verbal que identifique la acción.
6.1.4.9. Riesgo:
In riesgo es la posibilidad de que se produzca un contratiempo o una falla en los planes

de desarrollo del sistema multi-agentes.
Lo primero que debe determinarse es el tipo de riesgo, con esto significa el impacto
que significaría para el sistema si el riesgo se convierte en un hecho.
Luego de darle un nombre al riesgo y describir claramente en qué consiste el riesgo,
debe explicarse cuál sería el impacto de que el riesgo se convierta en una realidad.
Es importante determinar indicadores que puedan alertar cuando el riesgo se está
realizando. Hay casos en los que no es posible encontrar esos indicadores. Son esos
los casos en los que los involucrados en el proyecto deben estar más alertas.
Deben determinarse estrategias de mitigación para minimizar los daños producidos
por la realización del riesgo, y por supuesto, un plan de contingencia que permita
encontrar una salida para evitar los daños por la ejecución del riesgo.
Ficha de riesgo
Tipo de riesgo
Nombre del riesgo:
Alto Medio Bajo
Descripción
Impacto:
Indicadores:
Estrategia de mitigación;
Plan de contingencia:
Tabla 19: Ficha de riesgo
91
Esquema:
En los modelos, las restricciones se representan como:
Ilustración 32: Esquematico de riesgo
Notación:
Prefijo: rsg
Identificador: sustantivo o frase substantiva que identifique al riesgo.
6.1.4.10. Conocimientos:
Las unidades de conocimiento se asocian a roles y agentes y son la representación

de los datos que el agente conoce (o almacena) para poder operar dentro del entorno
en cumplimiento de los objetivos.
Una unidad de conocimiento puede ser implementada por uno o más roles y/o
agentes.
En las unidades de conocimientos se tienen que exponer las variables o estructuras
relevantes para representar las creencias o conocimientos funcionales del agente o
del rol. No es necesario consignar las variables operacionales que se usan en la
programación del rol o del agente. Por ejemplo, TemperaturaEntorno, sí podría ser
una estructura de datos funcional. Si se tiene que iterar, y en el programa se utiliza la
i como iterador, no es necesario ubicarla en la ficha de conocimientos.
92
Ficha de conocimiento
Nombre del conocimiento:
Descripción
Variables/predicados: Rol/Agente:
Arch. modelo de datos:
Tabla 20: Ficha de conocimiento
Si el conocimiento que se necesita representar es complejo, podría ser necesario

adjuntar archivos que contengan diagramas de bases de datos (tanto DER como
orientadas a objetos) como estructuras de predicados.
Esquema:
En los modelos, los conocimientos se colocarán como llamadas conectadas al

artefacto sobre el cual tiene efecto:
knoConocimiento1
iCantFichas
iIdAgujero
Ilustración 33: Esquemático de conocimientos
Notación:
Prefijo: kno
Identificador: sustantivo o frase substantiva que identifique al conocimiento.
93
6.1.4.11. Pruebas unitarias:
A medida que se diseña un agente, deben establecerse las pruebas unitarias

necesarias a fin de poder asegurar que el desarrollo se ajusta a lo analizado y
diseñado.
Ficha de Pruebas
Tipo de
Nombre de la pueba Prueba:
Nombre del agente
Descripción
Entradas:
Salidas o comportamientos esperados:
Observaciones
Tabla 21: Ficha de prueba unitaria
Esquema:
En los modelos, los conocimientos se colocarán como llamadas conectadas al

artefacto sobre el cual tiene efecto:
pruPrueba
Ilustración 34: Esquemático de prueba unitaria

Notación:
Prefijo: pru
94
Identificador: palabra o frase que identifique a la prueba.
6.2. Descripción de los modelos y diagramas
6.2.1. Modelo de entorno
El modelo de entorno nos permite tener una visión de las necesidades del sistema
multi-agentes y de las condiciones a las que se verá sometido. Deben consignar
principalmente los actores involucrados, los entornos definidos y las restricciones.
Entorno 1 Entorno 2
rsgSistema1
rsgSistema2
.....
msgRol2Ent1
msgRol13Ent1
msgRol4Ent2
msgEnt2Rol4
Actor1
Rol1 Rol 2 Actor 2
Rol 4
Actor 3
SIstema
Ilustración 35: Modelo de entorno
En caso de considerarlo necesario, el analista puede agregar los roles que tienen
intercambio directo con el entorno.
Se sugiere es tener en cuenta los mensajes que se intercambian entre el entorno y el
sistema.
Hay que recordar que los roles son los que tienen los objetivos asociados. Es posible
que un rol tenga más de un objetivo, de manera
95
6.2.2. Modelo de objetivos
El modelo de objetivos permite al analista ver la jerarquía y conexiones entre los

objetivos que se irán asignando a los agentes. Podrá verse si hay agrupamientos de
objetivos.
El modelo de objetivos se diseña utilizando las tarjetas de objetivos que se van
completando y depurando en las distintas fases del desarrollo. Debe comenzarse con
los objetivos principales del sistema e ir verificando qué es necesario para que esos
objetivos se cumplan, esas necesidades podrían convertirse también en objetivos.
Luego se continúa con los objetivos secundarios.
Es importante analizar muy bien los objetivos para comprender bien si hay objetivos
contradictorios, objetivos que puedan competir por recursos, objetivos que son
inalcanzables, objetivos que requieren recursos que no estaban previstos, etc. a fin
de poder considerar las medidas necesarias para que el sistema sea estable y robusto.
rsgConsumoRecursos
objDetermJugada1 objDetPuntuación1 rsgAnalizTiempos
objDecodEntrada objDetermJugada2 objDetPuntuación2 objMinimiJugadas
objDetermJugada3 objDetPuntuación3
objRecibiAnálisisAgentes
objPerdirAsistAgent objDetermJugada4 objDetPuntuación4
esq
objEnviarJugada
objVerificaPosibilidades objDetermJugada6
objRecibeEstado
objSelecciona
Ilustración 36: Modelo de objetivos
Si se considera complejo un objetivo, se puede ampliar con los objetivos internos que
lo forman.
Los objetivos sirven como base para la generación de roles. Un rol puede tener uno o
más objetivos. Los mismos deben estar jeraquizados y, dentro de un mismo rol, no
deberían ser contradictorios, o si lo son, al estar jerarquizados, estará claro a cual de
esos objetivos se le dará prioridad.
96
Si alguno de los objetivos conlleva riesgos específicos es bueno ponerlo en el modelo

a fin de que no se pierda de vista durante todo el proceso.
6.2.3. Modelo de roles
El modelo de roles es un modelo estático que permite al arquitecto/analista visualizar

la interacción entre los roles, que luego se traducirá en la interacción entre los agentes.
En la gráfica, se podrá comprender si hay agrupación de roles. En éste caso, esos
roles agrupados podrían asignarse a un mismo agente.
Agente
accApagaCircuitos
msgActiva
rolOperador
rolVerificador
rolCoordinador
rolMuestra
msgDeter msgConsu
msgAltera
accElevaTemp msgInfor
rolAnalizador
Ilustración 37: Modelo de roles
6.2.4. Modelo de conocimientos
El modelo de conocimientos, permite visualizar las estructuras de datos de los

diferentes agentes. Teniendo en cuenta que los sistemas multi-agentes son
distribuidos, no debería haber una estructura centralizada de conocimientos. Sí es
posible utilizar una base de datos centralizada con registros propios de los agentes.
No es la estructura ideal pero es una posible solución de compromiso para los
sistemas chicos que no justifican estructuras de datos sofisticadas locales al rol o al
agente.
97
Por otra parte, dependiendo del sistema, los agentes se registran con el agente
coordinador quién lo da de alta en una base de datos del sistema
Un agente puede tener un tipo de modelo de conocimientos mientras otros tener otro
completamente distinto, de manera que los modelos de conocimiento se asocian a
roles o agentes.
6.2.5. Modelo interno de agentes
El modelo interno de agentes es un modelo que incluye información de cada uno de

los agentes diseñados. El modelo es un conjunto de diagramas que incluye planes,
modelos de conocimientos, arquitectura de agente, etc.
Por lo general, la unidad de desarrollo es el agente, de manera que una vez diseñado
y depurado el modelo interno de agentes, se estaría en condiciones de iniciar la
programación.
Objetivo primario
rolVerificador rolCoordinador dbExterna
knoConocimiento1
iCantFichas
iIdAgujero
msgMensaje1 msgMensaje2 msgmensaje3
Agente2
Ilustración 38: Modelo interno de agente
98
6.2.6. Diagramas de secuencia
El diagrama de secuencias permite modelar la interacción entre roles o agentes en un

sistema multi-agentes. Permite ver la interacción dentro de la sociedad de agentes
para llevar a cabo una actividad.
En los diagramas de secuencia, se establece el orden de operaciones para que un
conjunto de agentes cumpla con una tarea o que llegue a un objetivo.
A fin de poder definir el diagrama de secuencia, se podrán utilizar los siguientes

elementos:
6.2.6.1. Línea de vida del rol/Agente:
Rol1
6.2.6.2. Activación u operación del agente
6.2.6.3. Mensaje sincrónico

Mensaje sincrónico
6.2.6.4. Mensaje de respuesta

Mensaje devuelto
6.2.6.5. Mensaje asincrónico

Mensaje Asincrónico
99
6.2.6.6. Ejemplo de diagrama de secuencias
Rol 1 Rol 2 Agente1
msgSolucitudServicio
msgBuscarInfo
msgComprendido
msgReactivación
msgHallado
msgRespuesta
msgComprendido
Ilustración 39: Diagrama de secuencias
6.2.7. Diagrama de estados
Hay dos tipos de diagrama de estados:

 Diagrama de estados del sistema
 Diagrama de estados interno del rol/agente
La diferencia entre ambos es el ámbito de aplicación.
Un diagrama de estados se define considerando al sistema, agente o rol como una
máquina de estados finitos. Es un grafo dirigido en donde los extremos son los estados
y la flecha de unión es la transición entre estados.
6.2.7.1. Estado inicial
100
6.2.7.2. Estado final
6.2.7.3. Estado
Procesando
6.2.7.4. Transición
SolicitaInfo
6.2.7.5. Ejemplo de diagrama de estados
Buscando Esperando
Hallado SolicitaInfo
Procesando Informando
Ilustración 40: Diagrama de estados
101
6.2.8. Diagrama de actividades
Un diagrama de actividades muestra visualmente un proceso como un flujo de trabajo

ejecutando acciones y decisiones.
Cuando un proceso presenta cierta complejidad, es útil poder visualizarlo utilizando
un diagrama de actividades.
El diagrama de actividades puede presentarse como un diagrama de flujo sencillo o
como un cursograma con andaniveles.
Estos diagramas permiten visualizar claramente la lógica de un algoritmo.
Básicamente ambos diagramas contienen los siguientes elementos:
6.2.8.1. Nodo inicial
Inicio
6.2.8.2. Acción
plaAcción
6.2.8.3. Unión
102
6.2.8.4. Bifurcación
6.2.8.5. Decisión
Si
si
Estado
no
6.2.8.6. Flujo
6.2.8.7. Conector de página
103
6.2.8.8. Conector de acción
11
6.2.8.9. Nodo terminal
FIN
6.2.8.10. Ejemplo de diagrama de flujo
Inicio
Fase1 no
Depurada
si
Fase2 no
no
Depurada
si
Fase3 no
Depurada
si
Refinada
si
FIN
Ilustración 41: Ejemple de diagrama de flujo
104
6.2.8.11. Ejemplo de cursograma
Es importante en el caso del uso de los cursogramas, numerar las operaciones y

bifurcaciones, para luego, por medio de una tabla, explicar ese procedimiento o
bifurcación.
En general los cursogramas se utilizan para comprender flujos a nivel macro. Los
roles, en caso de sistemas multi-agentes mixtos (humanos y software) pueden ser los
departamentos, divisiones, oficinas o jefaturas.
105
A. Gestión de errores de equipos de laboratorio
Laboratorio Ingeniería Biomédica Gerencia de Tecnología
Inicio
1. Detección de la
falla
2. ¿Funciona pero
no llegan
mensajes?
NO
3. Comunicarse con
4. Estimar solución
Ing. Biomédica SI
6. Comunicarse con
Mesa de ayuda y 5.
generar ticket ¿Problema de
infraestructura
?
si
7. Comunicarse con
8. Verificar
Mesa de ayuda y
NO conectividad
generar ticket
14.
¿Problema de 9. ¿no es problema
equipamiento de infraestructura?
?
SI SI
15. Llamar al 10. Llamar a

proveedor Proveedor
NO NO
16.Hacer 11.Hacer
seguimiento seguimiento
17. Solucionarlo 12. Solucionarlo
18. Comunicar la 13. Comunicar la

solución solución
Fin
Ilustración 42: Cursograma
106
A – Gestión de errores de equipos de laboratorio

# Descripción de actividad
1 El personal de laboratorio detecta una falla en uno de los equipos
2 ¿El equipo funciona, pero los resultados no se visualizan en el DNLAB?

3 Comunicación con Ingeniería Biomédica.
4 Verificar el equipo en estado de error. Estimar la solución
5 ¿Es un problema de infraestructura?
6 Comunicarse con mesa de ayuda informando la falla y generación del ticket enviando mail al:
[email protected]
Tabla 22: Explicación cursograma
6.3. Pasos a seguir e hitos de la metodología
La aplicación de la metodología es esencialmente iterativa. Cada paso mejora con la

iteración de paso y luego, se afina integralmente y se mantiene integrado con la
iteración genérica de la metodología.
Fase 1
Fase 2
Fase n
Ilustración 43: Pasos e hitos
6.3.1. Hitos de la metodología.
Hay dos tipos de hitos de la metodología: Los primarios y los secundarios.

Los hitos primarios o principales son los puntos en los cuales se puede considerar
cumplida una de las iteraciones del proceso de desarrollo de los agentes.
Los hitos secundarios son los puntos de control en los cuales se considera cumplida
cada una de las fases dentro de un ciclo.
107
Dependiendo del tamaño del proyecto, es posible agregar hitos donde el aquitecto o
analista considere necesario.
6.3.2. Esquema de desarrollo.

Esquematizando el proceso de desarrollo de software, podemos ver:
 Fase 1: Captura de requerimientos
o Paso 1: Identificar actores
o Paso 2: Determinar objetivos del sistema.
o Paso 3: Buscar entorno.
o Paso 4: Determinar las salidas del sistema cumpliendo el paso 2.
o Paso 5: Determinar las entradas que recibirá el sistema.
o Paso 6: Bosquejar los roles responsables de las entradas y de las
salidas.
o Paso 7: Determinar los recursos que necesita el sistema.
o Paso 8: Buscar restricciones.
o Paso 9: Buscar riesgos y mitigación de los mismos.
o Paso 10: Generar el modelo de entorno.
o Paso 11: Generar el modelo de objetivos.
o Paso 12: Iterar
 Fase 2: Análisis
 Fase 3: Diseño
 Fase 4: Desarrollo
 Fase 5: Pruebas
o Unitarias
 Internas de agentes
 comunicaciones
o Integrales
 Fase 6: Implementación
108
6.3.3. Captura de requerimientos
6.3.3.1. Introducción
Durante ésta fase, el objetivo principal a cumplir es responder las siguientes

preguntas: ¿quiénes son los actores? ¿Cuál es el entorno?, ¿de qué recursos se
dispone?, ¿cuáles son las restricciones que tiene?, ¿qué esperan los actores que
haga el sistema?, ¿Cuál es el alcance del sistema?,…
En el capítulo anterior, pudimos ver que AAII toma los requisitos como un punto de
vista externo; GAIA captura requisitos usando casos de uso y construyendo un modelo
de entorno y un modelo de conocimientos; MASE se basa en Rational Unified Process
con sus herramientas; TROPOS busca identificar los actores relevantes con sus
objetos en la etapa de requisitos iniciales; en ZEUS no se consideran los requisitos;
MAS-CommonKADS captura los requisitos como casos de uso en la fase de
conceptualización; MESSAGE adopta RUP e INGENIAS los captura a través de un
modelo de organización buscando (roles, relaciones de poder, flujos de trabajo, etc.).
En esta metodología buscaremos capturar los requerimientos a través de pasos que
permitirá completar las tarjetas para construir el modelo de entorno.
6.3.3.2. Pasos para la captura de requerimientos
Se sugiere que el desarrollo de la captura de requerimientos se realice siguiendo los

pasos que se sugieren, si se analizan las fichas, se podrá observar que cada ficha
tiene referencia a otra u otras fichas formando una red.
A fin de poder completa esta fase, se sugieren los siguientes pasos:
Paso 1: Identificar actores.
En la primera parte de éste capítulo hemos definido el concepto de actor para ésta
metodología.
Por cada uno de los actores hallados deben completarse los datos que se conozcan
de las fichas de actores.
Es importante comprender que, no conocer a todos los actores involucrados en el
sistema, pueden llevar a retrasos importantes o, incluso, a hacer fracasar el proyecto.
Los actores pueden ser personas físicas, organizaciones u otros sistemas.
En el caso de estar tratando con organizaciones, debe buscarse reducirlo a personas
de manera que sea más sencillo ubicar los objetivos y necesidades que pueda tener.
109
La ficha de actores es un complemento que nos permitirá determinar sus intereses e

importancia.
Otro punto a tener en cuenta es la jerarquía relativa de los actores. Se utiliza la
jerarquía relativa porque es la jerarquía que tienen con respecto al sistema.
Determinar la jerarquía de los actores, si la hay, es un factor importante al momento
de tomar en consideración la jerarquía de objetivos que se van a definir
No debería suceder, pero si en el análisis, hay objetivos o intereses contrapuestos,
que deben competir por recursos o al momento de asignar prioridades a los objetivos,
poder determinar la jerarquía relativa de cada actor ayuda al análisis y diseño del
sistema.
En caso de que sea necesario competir por recursos, debería considerarse la
necesidad de agentes mediadores a fin de evitar condiciones de carrera (deadlock).
En el modelo de necesidades se deben consignar los actores con sus respectivas
jerarquías, intereses y objetivos.
Paso 2: Determinar objetivos del sistema.
En el paso 1 se ha determinado la lista de actores. Cada uno de esos actores tiene

uno o varios intereses sobre el sistema. Deben analizarse esos intereses, descartar
los intereses que no son funcionales al sistema en análisis. Los intereses que quedan
son los candidatos a ser objetivos que debe cumplir el sistema. Puede verse una
relación entre actores y objetivos.
Se van completando las fichas de los objetivos teniendo en cuenta el actor interesado,
las actividades que se cree que serán necesarias a priori (en siguientes ciclos se irá
depurando esta lista, se asignará a planes y, estos a un rol).
A medida que se definen los objetivos, puede establecerse una jerarquía de sub-
objetivos. Los sub-objetivos son objetivos que se deben ir cumpliendo para lograr el
cumplimiento del objetivo primario.
Debe analizarse cuáles son los objetivos primario u obligatorios y cuáles los
secundarios u optativos.
Debe completarse el modelo de necesidades con los objetivos hallados y sus

jerarquías.
Paso 3: Buscar entorno.
Teniendo bien en claro los objetivos del sistema. A fin de poder buscar el entorno
deben determinarse, de manera clara, los límites del sistema. De esa determinación
110
surgen todas las interacciones entre sistema y entorno. Agregar el entorno en el

modelo de necesidades. Debe recordarse que todo lo que no es sistema, es entorno.
Paso 4: Determinar las salidas del sistema cumpliendo el paso 2.
Las salidas del sistema son un tipo determinado de objetivos que se consideran
objetivos finales del sistema.
Pueden identificarse claramente porque estos objetivos tienen contacto con el sistema
y con el entorno estregándole información o realizando alguna acción sobre el mismo.
Este tipo de objetos nunca pueden ser sub-objetivos. En la ficha, como tipo de objeto,
se consignará primario-salida o secundario-salida.
Normalmente las salidas del sistema se dan en forma de mensajes o de acción.
Paso 5: Determinar las entradas que recibirá el sistema.
Nuevamente se está frente a un tipo especial de objetivos. También tienen contacto

con el entorno, pero esta vez reciben información del sistema. Puede ser una entrada
de datos (a través de una interfaz) o recolección de información.
Este tipo de objetos nunca pueden ser sub-objetivos. En la ficha, como tipo de objeto,
se consignará primario-entrada o secundario-entrada.
Paso 6: Bosquejar los roles responsables de las entradas y de las salidas.
Una vez que se conocen las entradas y las salidas, pueden comenzar a definir roles.
Hay un rol que es el responsable de enviar un mensaje al medio o de ejecutar una
acción sobre él. Uno de los objetivos de ese rol sería entregar ese mensaje y/o
ejecutar la acción.
Nuevamente hay un rol responsable y cuyo objetivo es recibir entradas desde el
entorno del sistema, ya sea como mensaje o interpretando una acción del medio sobre
el sistema.
En próximas etapas se definirán planes que permitan a esos roles llegar a cumplir con
los objetivos que se le van asignando.
Paso 7: Determinar los recursos que necesita el sistema.
111
A medida que se va avanzando en el análisis y en el diseño, se irán depurando las

necesidades de recursos que requiere el sistema y agregando las que surjan en las
diferentes etapas.
Hay que identificar los recursos necesarios de los aconsejables. Los recursos
necesarios son aquellos sin los cuales el sistema no puede operar; los recursos
aconsejables son aquellos que harían que el sistema funcionara de forma óptima, pero
si no se llegaran a estar disponibles, el sistema podría continuar funcionando de un
modo que pierda performance o con menos capacidades.
Los recursos pueden ser: de hardware, de infraestructura, de software o en el caso de
tratarse de sistemas mixtos, elementos edilicios.
Deben completarse las fichas de recursos, una por recurso.
Paso 8: Buscar restricciones.
Como parte de la captura de requerimiento es necesario relevar las restricciones que

se presentarán al sistema, y por extensión, a los agentes.
Hay varios tipos de restricciones:

 restricciones físicas (cantidad de agentes, memoria disponible),
 restricciones de software (Sistema operativo, lenguaje de desarrollo)
 restricciones funcionales,
 restricciones legales,
 restricciones de seguridad
 restricciones de tiempos
 …
Todas las restricciones que se vayan identificando deben consignarse en el modelo

de entorno.
Paso 9: Buscar riesgos y mitigación de los mismos.
El poder identificar los riesgos en etapas tempranas del desarrollo, y saber cómo
mitigarlos permitirá un desarrollo más tranquilo.
Los posibles riesgos que pueden encontrarse en el desarrollo de un sistema multi-

agentes son:
 Actores clave con objetivos poco claros o con objetivos contrapuestos.
 Problemas de comunicaciones
112
 Fallas en el acceso a los recursos

 …
Es posible que exista un riesgo para el cual no podamos establecer alguna mitigación.
No es lo ideal, pero es necesario tener conocimiento de ese riesgo. Es importante
tratar de evitar todos los riesgos, pero más que nada deben evitarse y controlarse los
riesgos para los cuales no se tiene previstas operaciones para mitigarlos.
De todas formas son muchos más peligrosos para el sistema los riesgos no previstos.
Con los datos obtenidos deben completarse las fichas de riesgos.
Paso 10: Generar el modelo de entorno.
Como se dijo al principio de éste punto, las fichas completas van formando un
diagrama de red o de mallas. Para generar el modelo de entorno, debe considerarse
lo que se ha hallado e inscripto en la ficha de entornos lo los elementos que están
relacionados en un primer nivel.
Si el analista lo considera importante, puede agregar más de un nivel.
Paso 11: Generar el modelo inicial de objetivos con los datos obtenidos en los puntos
anteriores.
El modelo de objetivos tiene más granularidad que el modelo de entorno. Tomando

como base las fichas de objetivos, se diseñará el modelo de objetivos en dónde podrá
entenderse la relación existente entre los diferentes artefactos que compondrán el
sistema.
En esta fase se diseña una primera versión del modelo de objetivos que se irá
completando y depurando en el resto de las fases.
Debe considerarse cuáles son los objetivos generales del sistema y analizar y
considerar cómo pasar de los datos iniciales que se ingresan al sistema a cumplir con
esos objetivos finales. Es muy común definir objetivos “internos genéricos” en una
primera etapa, que luego, en las siguientes etapas, se irá desgranando en objetivos
más detallados.
Paso 12: Iterar

Volver al paso 1 hasta lograr un nivel de exactitud aceptable.
113
6.3.4. Análisis
Ésta fase debe definir qué debemos hacer.

Como en el caso del punto anterior, las metodologías que estuvimos analizando
manejan el análisis de diferentes maneras: AAII analiza los roles y los va refinando;
GAIA, también se basa en el análisis de roles refinando su interacción, genera el
modelo de roles y el modelo de interacción; TROPOS lo maneja a través de requisitos
posteriores; ZEUS realiza un análisis basado en el modelado de roles usando
diagramas de clase UML y aplicando patrones; MAS-CommonKADS realiza el análisis
a través de la especificación del sistema generando un modelo de agente, modelo de
tareas, modelo de experiencias, modelo de la organización de la sociedad de agentes,
modelo de comunicación con el usuario y un modelo de coordinación; MESSAGE
adapta el proceso unificado de desarrollo de software y en PROMETHEUS, se podría
asociar al diseño de arquitectura.
En todos los casos la metodología MeDeSMAGF se basa en completar y depurar

fichas y en la creación de nuevas a medida que avanza el proceso. En el análisis, se
completarán las fichas de los objetivos ya definidos como así también las de los
actores y los roles. A medida que se van completando surge la necesidad de crear
nuevos objetivos, se definirán los planes que permitan unir las entradas con los
objetivos mediante procesos.
6.3.4.2. Pasos para el análisis
Los pasos que se sugieren son los siguientes:
Paso 1: Refinamiento de los objetivos
Este paso se basa en los planes definidos en el paso anterior y en los objetos hallados
en la captura de requerimientos. A medida que se definen los planes, es posible que
surjan nuevos objetivos secundarios, que a su vez tendrán sus propios planes.
En el modelo de objetivos generado en la fase anterior, se agregarán los nuevos
objetivos englobados y con objetivo final el objetivo que se desglosa.
114
Ilustración 44: Relecamiento de objetivos
Un objetivo es siempre el fin último de un plan. En la fase de análisis ya no debería

ser posible encontrar un objetivo sin tener un plan o un rol asociado.
Paso 2: Definición de planes
En base a los objetivos hallados en el paso anterior, deben realizarse planes que
permitan, a partir de los disparadores u ingresos del sistema, lograr el cumplimiento
de los objetivos. Como mínimo habrá un plan por objetivo.
A medida que se desarrollan esos planes, surgen bifurcaciones que justifican nuevos
objetivos y planes.
Cuando se define un plan que puede repetirse cierta cantidad de veces variando
entradas, salidas o conocimientos internos, estamos en presencia de un posible rol
con sus ingresos y conocimientos internos, que el plan transformará en salida en caso
de información o acción en caso de elemento físico.
Los diferentes planes pueden tener asociados Diagramas de actividades y Diagramas
de estados para poder hacer más explícitas las operaciones que se irán definiendo.
Operativamente, se sugiere realizar una lista de planes, atendiendo al detalle. Con
esto se intenta decir que los planes deben realizarse lo más atómico que se desee a
fin de simplificar el proceso de codificación y testing.
Paso 3: Asociación de planes a roles
Un rol es un artefacto que modela cómo un agente participa en una relación. Los roles
tienen definidos planes, acciones y protocolos de comunicaciones y están enfocados
al cumplimiento de un objetivo. Dado que los agentes son artefactos sociales,
ineludiblemente tienen uno o más roles asociados.
Los roles son los que le dan la funcionalidad al agente y es una relación muchos a
muchos, esto quiere decir que cuando se diseñen los agentes, estos pueden cubrir
uno o más roles, y un rol puede estar incluido en uno o más agentes.
La ficha de roles sirve como guía para poder completar los datos necesarios. Las
fichas de los roles, pueden tener asociados diagrama de estados que clarifiquen la
definición del rol.
115
Paso 4: Establecer las necesidades de conocimiento interno de los roles
En la introducción teórica hemos establecido que los agentes tienen un conocimiento

interno o creencia dependiendo de la estructura interna de agente que se utilice. Si
bien es posible que haya conocimiento específico del agente, generalmente, el rol
asociado (o los roles asociados) son los que tienen el conocimiento que almacenará
el agente para su operación. A fin de poder cumplir con los planes, se define qué
información necesita el agente para poder cumplir con esos planes y tratar de llegar
al objetivo que se le definió.
Paso 5: Determinar las necesidades de comunicaciones entre los roles.
A fin de que pueda establecerse una relación entre los roles, tiene que haber algún
tipo de comunicación o interacción.
A fin de poder establecer una interacción entre roles, y por ende, entre agentes, es
necesario establecer protocolos. En éste paso se definen los protocolos de interacción
o comunicaciones entre agentes. La ficha de protocolo da una guía en el proceso de
interacción entre los roles. En caso de que la interacción sea de comunicación, debe
también establecerse claramente el formato de mensaje.
En la definición del protocolo de comunicaciones, se establece el tipo de comunicación
que habrá entre los agentes: comunicación directa (sincrónica), comunicación a través
de agente negociador (asincrónica), comunicación a través de base de datos,
comunicación a través de archivo, servicios (sincrónica), etc.
En ésta metodología MeDeSMAGF se sugiere el uso de algunos de los sistemas de
mensajes ya estandarizados como KQML o FIPA-ACL, pero puede definirse como lo
considere necesario el arquitecto/analista.
En éste punto, el arquitecto/analista puede valerse de diagramas de secuencia.
Paso 6: Generar el modelo de roles.
Teniendo claro los protocolos de interacción entre los roles, se puede generar el
modelo de roles del sistema multi-agente.
Éste modelo permitirá comprender las relaciones entre los roles y las posibles
comunicaciones/interacciones entre ellos.
Paso 7: Iterar
116
6.3.5. Diseño
Durante esta fase debe comprenderse cómo vamos a hacer definido durante la fase
de análisis. Se diseñan los modelos de datos para el conocimiento de lo que puedan
ser necesarios.
Siguiendo el mismo esquema verificamos qué es el diseño para las otras
metodologías. Para AAII el diseño se enfoca en el punto de vista interno basado en el
análisis del propósito de los servicios y planes; GAIA se basa en la agrupación de
roles de agentes y define un modelo de agentes, un modelo de servicios y un modelo
de conocidos o interacciones; MASE se basa en Rational Unified Process; Tropos
trabaja el diseño arquitectural y el diseño detallado; ZEUS trabaja el diseño de los
agentes; MAS-CommonKADS aborda el diseño a través del modelo de diseño y
arquitectura; y MESSAGE adoptó el Proceso unificado de desarrollo de software.
6.3.5.2. Pasos para el diseño
Paso 1: Diseñar las unidades de conocimiento.
Como se ha definido en la introducción teórica, los agentes, por lo general necesita

una representación interna del conocimiento, de su entorno inmediato o, por lo menos
de su estado interno. Esto sucede incluso en los sistemas con arquitectura de
subsunción.
Las unidades de conocimiento pueden ser volátiles (residir en la memoria del agente)
o pueden ser permanentes (almacenada como archivos, base de datos, predicados,
etc.).
En caso de agentes humanos, se considera que lo que no está registrado en archivos
o documentos, es memoria volátil. Lo que la persona se acuerda debe considerarse
volátil.
Este es el punto en donde se definen y diseñan las bases de datos y las estructuras
de los archivos.
Paso 2: Diseñar los agentes.
Ya se tienen todos los elementos para poder generar las fichas de agentes, que
posteriormente se volcarán en los gráficos que forman el modelo de agentes. Al
momento de diseñar los agentes deben tenerse en cuenta los datos recabados en las
fichas de roles y que rol o roles se le asignarán al agente en cuestión. Al asignarle uno
117
o más roles, el agente heredará uno o varios comportamientos que dependen del
entorno o de la funcionalidad que es necesario darle. Recibirá un modo de
comunicarse con otros agentes que cumplirán otros roles y tendrá una estructura de
conocimientos heredada.
Es posible, pero no recomendable, trabajar en el diseño de un paciente que no reciba
comportamientos y estructuras de al menos un rol dado que se perderá trazabilidad
entre el análisis y el diseño del mismo.
Paso 3: Diseñar los casos de prueba.
Una vez diseñado un agente, se sugiere estudiar la manera de probar su

funcionamiento y establecer una rutina para poder comprobar que, una vez
programado el agente, pueda comprobarse que cumple correctamente con las
necesidades de diseño.
En éste paso, lo que se diseña es el test unitario del agente. Debe tenerse en cuenta:
Funcionamiento, comunicaciones, consumo de memoria, performance, etc.
Estos datos deben completarse en la ficha del agente.
Paso 4: Generar el modelo de conocimientos.
El modelo de conocimientos debe abordarse de manera particular para cada

rol/agente y analizar la necesidad de generalizar ese conocimiento. Dado que
conceptualmente los sistemas multi-agentes son distribuidos, en el caso de necesitar
“centralizar” la información, debe hacerse a través de un agente que sea responsable
de mantener y servir ese conocimiento.
Hay sistemas que no requieren de la definición de este modelo ya que sus estructuras
de datos son sencillas. Es necesario enfocarse sólo en aquellos agentes que tienen
estructuras complejas.
Paso 5: Generar los modelos internos de los agentes.
Generar los modelos internos de los agentes es graficar lo volcado en las fichas de
agentes, para tener una comprensión visual y modular de lo que se necesario
programar.
Paso 6: Iterar.
118
6.3.6. Desarrollo o codificación.
Durante ésta fase se desarrolla y codifica, si se trabaja con bases de datos, se crean
las bases de datos (tablas, índices, triggers y stored procedures) que almacenarán los
conocimientos de los roles y agentes; y se programarán los agentes.
Durante el diseño se llevó a detalle concreto cómo se deben programar los agentes.
La metodología MedeSMAGF, fue guiando el desarrollo de manera que pueda
programarse a los agentes de manera modular.
Pueden identificarse los siguientes módulos que podrían programarse de manera de
ser reusados:
 Rol (un agente tiene indefectiblemente un rol, pero puede tener más de uno)
 Comunicaciones
 Servicios
 Conocimientos
 Acciones
Es importante que mientras se transita por esta etapa, se vayan desarrollando las
funciones y pasos necesarios para poder realizar las pruebas unitarias (unit testing),
119
6.3.7. Pruebas
Fase en la que se comprueba que el sistema cumpla con las necesidades recabadas
durante la captura de requerimientos y el análisis y que el código no falle.
6.3.7.2. Pasos para el diseño y ejecución de pruebas

Los pasos de testeo deberían ser:
Paso 1: Testeo unitario del rol
La metodología empuja al desarrollador a trabajar modularmente. El módulo principal

que se desarrolla en cada sistema multi-agentes es el rol.
Es muy importante tener perfectamente testeado el software que define el rol antes
de continuar con el resto. Como recibe las entradas o pedidos de servicios, como
procesa esos datos y como prepara la información para la salida o, en caso de ser
robótico, como realizará las acciones.
Paso 2: Testeo unitario de agente: cada agente debe ser testeado como sistema
aparte.
Un agente es un sistema por sí mismo. Debe probarse completamente. En caso de

que el agente tenga más de un rol, debe comprobarse el orden de importancia de los
mismos. Qué rol tiene prioridad de ejecución.
Es importante testear los sistemas de aprendizaje y de producción de conocimiento.
Paso 3: Testeo de grupos de agentes del sistema
Este punto trata de las pruebas de comunicaciones. Se verificarán todos los puntos
de interacción directa de cada agente con el resto. Primero uno a uno, luego ir
agregando agentes hasta poder comprobar toda interacción.
En caso de no poder probar todas las conexiones ya que no se conoce a priori la
cantidad de agentes, deben probarse íntegramente todos los tipos de agentes, y tratar
de establecer una proyección de la performance de la interacción del grupo de
agentes.
120
Paso 4: Testeo integral del sistema: A través de checklist y lote de pruebas
En este paso, se consideran realizadas todas las pruebas unitarias enunciadas en los
pasos anteriores. Cualquier falla en el testeo integral, forzaría:
 Un análisis de la desviación, buscando los motivos. Es posible que la
desviación no afecte significativamente al sistema o que afecte sólo a un
objetivo secundario.
 Revisión si es una falla sólo de codificación. En este caso, debe realizarse las
correcciones necesarias y volver a realizar los testeos correspondientes.
 En caso de determinarse un error de análisis o diseño, debe forzar un nuevo
ciclo.
 Es posible que la falla no sea relevante, o que afecte a un objetivo secundario.
En esos casos, el analista debe considerar la necesidad de iniciar un nuevo
ciclo para reparar la falla, o si se acepta la falla. En caso de que se acepta la
falla es muy importante de que quede perfectamente documentada como
limitación del sistema.
El testeo integral debe realizarse, inicialmente en un ambiente controlado. Luego ir
ampliando las variables hasta lograr un ambiente lo más cercano a la realidad.
En este paso, se plantea la generación de un checklist que permita comprobar, dentro
de lo posible, todas las opciones que puedan plantearse.
121
7. Ejemplo de aplicación de la metodología MeDeSMAGF
7.1. Introducción
En esta etapa implementamos un sistema multi-agentes aplicando la metodología

MeDeMASGF.
7.1.1. Propósito de la sección
El propósito de la presente sección es plantear un ejemplo de aplicación de la

metodología MeDeMASGF.
El ejemplo que se usará es el análisis y diseño de una inteligencia artificial compatible
con el juego SPIA-Wari desarrollado como tesis de pre-grado.
7.1.2. Alcance de la sección
El alcance de ésta sección del documento es servir de guía para la realización de una
Inteligencia artificial utilizando tecnología multi-agente para ser aplicada al proyecto
S.P.I.A.-Wari.
Se realizará la captura de requisitos, el análisis, el diseño y se plantearán las pruebas
de test unitario y las pruebas integrales.
Queda fuera del alcance la fase de codificación y la fase de testing de la inteligencia
artificial.
7.2. Captura de requisitos para una IA para el juego SPIA-Wari
Para realizar la captura de requisitos, nos basaremos en el reglamento del juego Wari
para poder comprender los objetivos de la IA a desarrollar.
122
El ejemplo es sencillo de manera que nos permitirá aplicar la metodología

MeDeMASGF y tener una visualización clara del proceso que, si se tratara de un
desarrollo complejo, podría perderse el foco que es la aplicación de la metodología.
7.2.2. Desarrollo
7.2.2.1. Pautas que debe cumplir la IA
Lógicamente las cuatro primeras pautas que debe cumplir son las generales para
todos los ejecutables que quieran funcionar como IAs.
 Ser un ejecutable (ya sea .com, .exe, .cmd, .vbs, .war, etc. No importa si
compilado o interpretado)
 Admitir una cadena de 14 caracteres como parámetro.
 Devolver un entero entre 1 y 6.
 Considerar los seis primeros agujeros y el primer almacén como propios
Las pautas anteriores han sido definidas en el Trabajo práctico final para la obtención
de mi título de pregrado de “Analista de sistemas”. [70]
7.2.2.2. Determinar los objetivos del sistema
El principal objetivo del sistema es ganar el juego respetando las reglas asignadas en
el anexo 2.
Llevándolo a un campo medible, maximizar la captura total de fichas.
Tabla 23: Ficha de objetivos objPpal
123
Tabla 24:Ficha de objetivos objRecibir
Tabla 25: Ficha de objeticos objCoordinaOper
7.2.2.3. Determinar entorno

La IA que se intenta diseñar funcionará interactuando exclusivamente con el sistema
SPIA Wari.
El Sistema SPIA Wari activará a la inteligencia artificial cuando se requiera una
selección de agujero, enviándole una cadena de caracteres que representa una
fotografía con el estado actual del juego.
124
Tabla 26: Ficha de intorno entIA
7.2.2.4. Determinar salidas del sistema
La salida del sistema es un número comprendido entre 1 y 6 que representa el número

de agujero desde el cual el Sistema SPIA Wari debe extraer las semillas.
Ilustración 45: Tablero SPIA-Wari
7.2.2.5. Determinar entradas al sistema
La estrada al sistema será desde el Sistema SPIA Wari al momento de la activación

de la memoria.
La entrada consiste en una cadena de 14 caracteres codificados de acuerdo al anexo
1° del presente trabajo.
El significado de los 14 caracteres es el siguiente:
125
1a6 Agujeros de los cuales la IA debe seleccionar uno. Son los que se
consideran agujeros propios.
7 a 12 Son agujeros que muestran las semillas que se encuentran dentro de las
elecciones del contrincante. Son los que se consideran agujeros del
contrincante.
13 Almacén de las semillas capturadas propias. Éste es el número a
maximizar (para éste diseño). Las semillas tomadas por las jugadas
propias durante el transcurso del juego irán a parar a éste almacén.
14 Almacén de semillas del contrincante. Las semillas tomadas por las
jugadas del contrincante durante el transcurso del juego irán a parar a éste
almacén.
Tabla 27: Tabla de entrada
7.2.2.6. Bosquejar los roles responsables de entradas y salidas
Los primeros roles que pueden determinarse en el sistema son los encargados de
ingresar datos al sistema y de devolver resultados al entorno.
Tabla 28: Ficha de rol rolEntrada
126
Tabla 29: Ficha de rol rolSalida
7.2.2.7. Determinar los recursos que necesita el sistema.
El sistema sólo necesita los permisos y capacidad de crear hilos o procesos.

No hay especificaciones especiales de recursos.
Tabla 30:Ficha de objetivos objPpal con recursos
7.2.2.8. Buscar restricciones
Las restricciones que se encuentra: Actualmente debe ejecutarse en sistemas

operativos Windows, el entorno entrega sólo estado actual del juego de manera que
no es posible inferir cuales fueron las jugadas previas.
127
Tabla 31:Ficha de objetivos objPpal con restricciones
7.2.2.9. Buscar riesgos y mitigación de los mismos
LA IA que estamos diseñando es sencilla. No tendrá conexión a base de datos para

armar un historial (en próximas versiones podría considerarse la posibilidad)
Tabla 32: Ficha de riesgo: rsgEntradaFalla
7.2.2.10. Generar modelo de entorno
Con los datos recabados en entorno, roles y riesgos, es posible generar el modelo de
entorno.
128
SPIA Wari
rsgEntradaFalla
rolEntrada rolSalida
SIstema
Ilustración 46:Modelo de entorno
7.2.2.11. Generar el modelo inicial de objetivos
objPpal
objRecibir objCapturarSemillas
objCoordinaOper objEntregarMensaje
Ilustración 47:Modelo inicial de objetivos
7.3. Análisis de una IA para el juego SPIA-Wari
Durante esta fase, debemos comprender perfectamente qué se necesita hacer.
7.3.2. Desarrollo
129
7.3.2.1. Refinamiento de objetivos

Se establece una posible lista de objetivos que deberían cumplirse para unir los
objetivos que establecen las entradas y el objetivo principal del sistema multi-agentes:
 Objetivo principal del sistema multi-agentes (objPpal)
o Recibir los datos del sistema multi-agentes (objRecibir)
 Decodifica el mensaje (objDecodifica).
 Valida el mensaje (objValida)
 Crea agente coordinador (objCreaCoord)
o Coordinar las operaciones (objCoordinaOper)
 Crea los seis agentes que analizarán las capturas y representan
la selección de agujeros (objCreaAgujeros)
o Calcular la cantidad de semillas capturadas (objCapturarSemillas).
 Verifica profundidad de futuro (objProfFuturo)
 Selecciona estrategia de captura (objSelecEstrategia)
 Crea agente coordinador (objCreaCoord)
o Selecciona mejor opción(objSeleccAgujero)
o Entrega el mensaje (objEntregarMensaje)
7.3.2.2. Definición de planes
Lo ideal es hacer un listado de planes y luego desarrollarlos. Se seguirá la consigna

de realizar planes operativamente atómicos.
Los planes que se detectan son, al menos uno por cada objetivo, se va completando
con cada ciclo:
 Recibir los datos (plaRecibir)  objRecibir

 Decodificar el mensaje (plaDecodifica)  objDecodifica
 Validar el mensaje (plaValida)  objValida
 Crear agente coordinador (plaCreaCoord)  objCreaCoord
 Coordinar las operaciones (plaCoordinaOper)  objCoordinaOper
 Crear los seis agentes de selección de agujeros (plaCreaAgujeros) 
objCreaAgujeros
 Calcular la cantidad de semillas capturadas (plaCapturarSemillas) 
objCapturarSemillas
 Verifica profundidad de futuro (plaProfFuturo  objProfFuturo
 Selecciona estrategia de captura (plaSelecEstrategia)  objSelecEstrategia
 Selecciona mejor opción (plaSeleccAgujero)  objSeleccAgujero
 Entregar mensaje (plaEntregaMensaje)  objEntregaMensaje
130
Tabla 33:Ficha de plan plaRecibir
Tabla 34: Ficha de plan: plaDecodifica
131
Tabla 35:Ficha de plan: plaValida
Tabla 36: Ficha de plan: plaCreaCoord
132
Tabla 37: Ficha de plan: plaCoordinaOper
Tabla 38: Ficha de plan: plaCoordinaOper
133
Tabla 39: Ficha de plan: plaCapturarSemillas
Tabla 40: Ficha de plan: plaProfFuturo
134
Tabla 41: Ficha de plan plaSeecEstrategia
Tabla 42: Ficha de plan plaSelecAgujero
135
Tabla 43: Ficha de plan plaEntregaMensaje
Tabla 44: Ficha de plan plaGestError
136
7.3.2.3. Asociación de planes a roles
Tabla 45: Ficha de rol rolEntrada
Tabla 46: Ficha de rol rolCoordinador

137
Tabla 47: Ficha de rol rolAgujero
Tabla 48: Ficha de rol rolSalida
7.3.2.4. Establecer las necesidades de conocimiento interno de

los roles
138
Si bien este es un proyecto pequeño, estableceremos una estructura de datos que le

permita actuar al que ejerza el rol de coordinador. Esta estructura debe permitirle
tomar la decisión en base al disparo de red neuronal. El peso de cada dendrita surgirá
de una ecuación que sea el producto de la proyección cantidad de semillas capturadas
por la inversa de la profundidad.
Tabla 49: Fichas de conocimietno knoCoordinador knoAgujero
7.3.2.5. Determinar las necesidades de comunicaciones entre

roles.
Claramente verificando los puntos anteriores, pueden establecerse dos tipos de

comunicaciones:
 Comunicaciones entre el entorno y el sistema.
 Comunicaciones entre los agentes/roles.
En el primer caso, no es necesario definir los mensajes debido a que vienen dados
por definición: como entrada una cadena de 14 caracteres alfanuméricos que tienen
el estado del juego codificado según tabla.
139
Tabla 50: Fichas de mensajes msgPedido y msgProfundidad
En el segundo caso, podemos ver que hay comunicación entre el “coordinador” y los
agujeros.
Tabla 51: Fichas de mensajes msgRespuesta y msgOk
140
Los protocolos son:
Tabla 52: Ficha de protocolo proSinProfundidad y proConProfundidad
Tabla 53: Fichas de protocolo: proEntrada y proSalida

141
7.3.2.6. Generar modelo de roles

En el modelo de roles combinamos los roles con los planes, los conocimientos y los
mensajes desarrollados durante el análisis. Permitirá tener una vista clara del sistema.
Ilustración 48: Modelo de roles
7.3.2.7. Modificar el modelo de objetivos
objPpal
objRecibir
objDecodifica
objCreaCoord
objValida
objCoordinaOper objEntregarMensaje
objCapturarSemillas
objSelecAgujero
objSelecEstrategia objCreaAgujeros
objProfFuturo
objGestError
objCapturarSemillas
Ilustración 49: Modelo de objetivos
142
7.4. Diseño para una IA para el juego SPIA-Wari
El objetivo de ésta sección es concretar lo analizado determinando las diferentes

unidades que se volcarán en el desarrollo del sistema multi-agentes.
7.4.2. Desarrollo
Durante esta etapa, como se explicó en el desarrollo de la metodología, de sugieren

los siguientes pasos, pero según el proyecto, pueden agregarse pasos o eliminarse
los mismos.
7.4.2.1. Diseñar las unidades de conocimiento.
En éste proyecto, las unidades de conocimientos son simples y no requieren de

desarrollos especiales.
7.4.2.2. Diseñar los agentes.
Para diseñar los agentes, es necesario apoyarse en los roles que se han definido
durante la fase de análisis.
143
Tabla 54: Fichas de agentes entFrontera y entCoordinador
Tabla 55: Ficha de agentes entAgujero
144
7.4.2.3. Diseñar los casos de prueba unitarios.
Se desarrollarán los casos de prueba basado en los agentes y los distintos planes que
deberán ejecutar cada agente.
7.4.2.3.1. entFrontera
Tabla 56: Ficha de pruebas pruFro01 y pruFro02
Tabla 57: Ficha de pruebas pruFro03 y pruFro04
145
7.4.2.3.2. entCoordinador.
Tabla 58: Fichas de pruea pruCoo01 y pruCoo02
Tabla 59: Fichas de pruebas pruCoo03 y pruCoo04
Tabla 60: Fichas de pruebas: pruCoo05 y pruCoo06

146
7.4.2.3.3. entAgujero.
Tabla 61: Fichas de pruebas: pruAgu01 y pruAgu02
Tabla 62: Ficha de prueba pruAgu03
7.4.2.4. Diseño de los modelos de conocimientos.
En éste proyecto, no se requiere el diseño de un modelo de conocimientos. Ver punto

7.4.2.1,
147
7.4.2.5. Generar el modelo interno de los agentes.
En éste sistema tenemos tres agentes. De manera que tendremos tres modelos
internos de agentes. Se utilizarán todos los gráficos que se consideren necesarios
para evitar sorpresas al momento de desarrollo.
Primero se mostrarán los gráficos disgregados por agente, y al final, se mostrará un

panorama general del modelo interno de los agentes. El mostrarlo disgregado, sirve
en el caso de que asigne el desarrollo de los distintos agentes a diferentes grupos de
trabajo.
7.4.2.5.1. entFrontera.
Ilustración 50: Modelo interno de entFrontera
148
7.4.2.5.2. entCoordinador.
Ilustración 51: Modelo interno de entCoordinador
7.4.2.5.3. entAgujero.
Ilustración 52: Modelo interno de entAgujero

149
7.4.2.5.4. Modelo interno de agentes.
Ilustración 53: Modelo interno de agentes
150
8. Conclusiones y próxima línea de investigación.
Los sistemas se complejizaron cada vez más, desde los viejos programas lineales de
las primeras computadoras como las ENIAC, a los actuales sistemas distribuidos que
funcionan en supercomputadoras. Como vimos en la introducción teórica, las
metodologías de desarrollo de software han ido acompañando esa evolución
facilitando la construcción y el manejo de sistemas complejos. En un principio, los
ordenadores trabajaban por lotes bach. Luego comenzaron a usarse las interfaces
para interactuar con los usuarios. Ahora, se espera que el usuario intervenga sólo
cuando sea necesario, que los sistemas actúen solos. Permitiendo organizar agendas,
comunicar, recordar, negociar, comprar, vender, jugar de manera realista, simular, etc.
Los sistemas de desarrollo también evolucionaron. Distintos paradigmas se fueron
creando para acompañar las necesidades de complejidad. Entre esos paradigmas se
encuentra la Programación orientada a agentes.
Debe recordarse que lo que se explicó al principio, en mitos y verdades. La
programación orientada a sistema multi-agentes, no es la panacea del desarrollo de
software, ni debería aplicarse a todos los tipos de sistemas. Es ideal cuando se trata
de sistemas distribuidos o cuando el comportamiento del sistema depende de
demasiadas variables desconocidas en donde la negociación entre agentes (o partes
del mismo) puede hacer la diferencia.
El desarrollo de sistemas multi-agentes presenta complicaciones que sólo pueden
comprenderse desarrollando uno. Sin una metodología clara que guíe durante el
proceso, los tiempos pueden dispararse y puede perderse el control del proyecto.
Por otra parte, para desarrollar una metodología es necesario comprender plenamente
las necesidades de un sistema multi-agentes, durante la captura de requerimientos,
durante el análisis y el diseño, las complejidades del desarrollo y las pruebas.
Como se pudo ver en el desarrollo del trabajo lo que se plantea es un proceso cíclico
que va completando fichas y modelos hasta lograr minimizar la incertidumbre sobre lo
que deben y no deben hacer los agentes, cómo deben comunicarse y cómo deben
interactuar con el entorno.
Las idas y vueltas para la determinación de los datos necesarios para ir completando
los pasos fuerzan al analista u arquitecto a comprender la evolución que debe seguir
el proceso durante todas las fases enunciadas. Como resultado final, obtendrá un
juego de fichas y modelos que le permitirá a los programadores, codificar limitando las
pérdidas de tiempo por reprogramación y clarificando las pruebas que se deben
realizar para asegurar un funcionamiento dentro de unos parámetros considerados
como normales.
También se puede concluir que la modelación de un sistema multi-agente puede
aplicarse a organizaciones en donde interactúan: agentes software puros, agentes
software con humanos y sistemas de humanos puros; que permite la aplicación en
151
una gran variedad de entornos y organizaciones. La metodología permite el análisis y

diseño de sistemas mixtos integrándolos de una manera racional.
Con respecto a la próxima línea de investigación que se seguirá es el desarrollo de un

sistema de administración de fichas y generación de modelos que permitan guiar y
documentar usando la metodología MeDeSMAGF facilitando las tareas del analista.
152
9. Referencias/Bibliografía
Michael Wooldridge: An introduction to multi-agent systems. John Willey & sons,

[1]
ISBN 0-471-49691-X. 2002
Doran Jim: Intervening to achieve co-operative ecosystem management: Towars an

[2]
agent based model. Journal of Artificial Societies and Social Simulation vol. 4, no. 2.
2001
http://jasss.soc.surrey.ac.uk/4/2/4.html
[3]Michael Wooldridge: Agent-based software engineering. Proc on software

engineering. IEEE. 1997
JIMÉNEZ REY, M. Elizabeth; GROSSI, María Delia; PERICHINSKY, Gregorio: Una

[4]
Aplicación de la Tecnología de Multi-Agentes a los Sistemas Tutores Inteligentes:

Enseñanza de Computación en Carreras de Ingeniería
Ana Mas: Agentes software y sistemas multiagentes. Conceptos, arquitecturas y

[5]
aplicaciones. Pearson Educación S.A. 2005.
Rodney A. Brooks and Anita M. Flynn: Fast, cheap and out of control: A robot
[6]
invasion of the solar system. Journal of The British Interplanetary Society. Volumen
42. 1989; pp 478-485
Savage, John E.: Models of Computation, Exploring the power of computing. Brown
[7]
University; http://cs.brown.edu/~jes/book/. 2008
[8] Freeman, James A.; Skapura, David M.: Redes Neuronales, Algoritmos,
aplicaciones y técnicas de programación. Addison-Wesley/Diaz de Santos. ISBN 0-
201-60115-X. 1991
J. J. Hopfield: Neural networks and physical systems with emergent collective

[9]
computational abilities. Proceedings of the National Academy of Sciences of the USA.

1982
[10]J.
Febres, C. Prieto, Y. Gonzalez: Control en 2D de un asistente robótico para
cirugías laparoscópicas. Mecánica Computacional Vol XXIX. 2010; págs. 6539-6547
153
[12]Xavier Basogain Olabe: Redes neuronales artificiales y sus aplicacio-

nes. Escuela Superior de Ingeniería de Bilbao. 2005
HAYKIN, Simón. Neural Networks, A comprehensive foundation, Second Edition.

[13]
Ed. Prentice Hall. ISBN 0-13-273350-1. 1999
[14] http://www.swi-prolog.org/
[15] http://www.learnprolognow.org/
[16] http://homepages.inf.ed.ac.uk/stg/research/Psharp/
[17] http://www.gprolog.org/
[18] http://www.dobrev.com/
[19] http://ciao-lang.org/
[20] http://www.visual-prolog.com/
Zalta Edward: Basic Concepts in Modal Logic. Center for the Study of Languaje and
[21]
Information, Stanford University. 1990
Luis Carlos Torres Soler: Inteligencia Artificial: Conceptros básicos. Facultad de

[22]
ingeniería, Universidad Nacional de Colombia. 2007
José Luis Fernández Vindel, Ángeles Manjarrés Riesco, Francisco Javier Díez
[23]
Vegas: Lógica Computacional. Dpto. Inteligencia Artificial, E.T.S.I. Informática, UNED

— 2003
[24]Manuel Sierra: Lógicas epistémica y doxástica con restricciones. Ingeniería y

ciencia; volumen 6 N° 12. 2010
Herrera Gonzalez, José Rafael: La lógica del conocimiento y la creencia.

[25]
Universidad de La Laguna, España. 2001
[26] International Planning Competition. IPC2014. 2014.
Jill Fain Lehman, John Laird, Paul Rosenbloom: A Gentle Introduction to Soar, an
[27]
Architecture for Human Cognition. Sternberg & D. Scarborough (Eds). 1996
154
Robert Wray y Randolph Jones: An Introduction to Soar as an Agent Architecture

[28]
– 2004
Robert Kowalski and Fariba Sadri: An Agent Architecture that Unifies Rationality
[29]
with Reactivity. Department of Computing, Imperial College, London. 1997
Jörg Müller y Markus Pischel: The agent architecture InteRRaP: Concept and
[30]
application. German Research Center for Artificial Intelligence (DFKI) – 2011
Ines A. Ferguson: TouringMachines: an architecture for dinamic, rational, mobile

[31]
agents. University of Cambridge Computer Laboratory. 1991
Max Winiewski: Agent-based Blackboard Architecture for a Higher-Order Theorem

[32]
Prover. Freie Universität, Berlin. 2014
D. Rudenko, A.Borisov: An overview of blackboard architecture application for real

[33]
tasks. Scientific proceedings or Rigal Technical University. 2007;
Gottifredi, Sebastián: Formalismos de argumentación en especificación de agentes

[34]
autónomos. Universidad Nacional del Sur. 2012
Arnon Sturm, Onn Shehory: A Framework for Evaluating Agent-Oriented

[35]
Methodologies. Lecture Notes in Computer Science Volume 3030. 2004. pp 94-109
http://link.springer.com/chapter/10.1007%2F978-3-540-25943-5_7#page-1
[36]Quynh-Nhu Numi Tran, Grahan oy, Mary-Anne Williams – A feature análisis

framework for evaluating Multy-agent system development methodologies – En
ZHong. N et. Al. (eds) 2003. Foundations of intelligent systems – Proc. Of the 14th Int.
Symposium on Methodolofies for Intelligent systems ISMIS’03 – Springer – Verlag –
Pág 613-617.
[37]Peter Stone, Manuela Veloso – Multiagent systems: A survey from machine

learning perspective – Autonomous robotics Volume 8, number 3 – July, 2000
[38]Abdulsalam Alarabeyyat – Evaluating Agent-oriented engineering methodologies

– Information Technology Department (IT) – Faculty of Prince Abdullah Bin Ghazi of
Science and Information Technology – Al-Balqa Applied University – Jordan
155
Carlos Iglesias, Mercedes Garijo, José Gonzalez, Juan Velazco – A methodological

[39]
proposal for multiagent system development extending KommonKADS – Universidad

Politécnica de Madrid – 1996
http://ksi.cpsc.ucalgary.ca/KAW/KAW96/iglesias/Iglesias.html
[40]Jignesh Patel, Chetan Bhatt, “CommonKADS Model Framework for Web Based
Agricultural Decision Support System”. World Conference on Computers in Agriculture
and Natural Resources, University of Costa Rica, San Jose, Costa Rica, July 27th-
30th, 2014.
http://CIGRProceedings.org
Aguilar Jose, Cerrada Mariela, Hidrobo Francisco – A methology to specify

[41]
multiagent systems – Agent and Multi-Agent Systems: Technologies and Applications

– LNAI (Lectur Notes in Artificial Intelligence) Número 4496 _ Ed. Springer – 2007
Norbert Glaser – The ComoMAS Aproach: From conceptual models to Executable

[42]
code – CRIN/CNRS-INRIA Lorraine, France – 1997
Maja Hadzic, Pornpit Wongthongham, Tharam Dillon, Elizabeth Chang – Ontology-

[43]
Based Multi-Agent System – Springer Verlag – Berlin – germany – 2009.
Gheorghe Cosmin Silaghi – Contributions to Conception, Design and Development

[44]
of Collaborative Multi-Agent systems – BABEŞ-BOLYAI UNIVERSITY – Cluj-Napoca,

Romania – 2005
Carlos A. Iglesias, Mercedes Garijo – The Agent-Oriented Methodology MAS-

[45]
CommonKADS – Idea group Inc. – 2005
[46]FrancoZamborelli, Nicholas R. Jennings, Michael Wooldridge – Developing

Multiagent Systems: The Gaia Methodology – ACM Transactions on Software
Engineering and Methodology – Vol.17 Nro. 3 – 2003
[47]Luca
Cernuzzi, Thomas Juan, Leon Sterling, Franco Zamborelli – The GAIA
Methodology: Basic concept and extensions – 2005
[48] http://ingenias.sourceforge.net/
Juan Pavón, Jorge Gómez-Sanz, Ruben Fuentes – The INGENIAS Methodology

[49]
and Tools – Agent-Oriented Methodologies – Idea Group Publishing – Chapter IX –

Pág-236 – 273 – 2005
[50]Mark Wood, Scott DeLoach – An Overview of the Multiagent Systems Engineering

Methodology – Agent-Oriented Software Engineering – Proceedings of the First
International Workshop on Agent-Oriented Software Engineering, 10th June 2000,
156
(Eds.) Lecture Notes in Computer Science. Vol. 1957, Springer Verlag, Berlin –
January 2001.
Scott DeLoach – The MaSE Methodology – Methodologies and Software

[51]
Engineering for Agent Systems – Srpinger – 2004 – Cap. 6 – Pág. 107 – 125
Jürgen Lind Ackerstraße – Agent-Oriented Software Engineering with MASSIVE –

[52]
LNCS 1994, Springer, Berlin – 2001
Francisco Garijo, Jorge Gómez-Sanz, Philippe Massonet – The MESSAGE

[53]
Methodology for Agent-Oriented Análisis ans Design – Chapter VIII – Agent-Oriented

Methodologies – Idea Group Publishing – Pág. 203 – 235 – 2005
[54]Lin Padgham, Michael Winikoff – Prometheus: A Methodology for Developing

Intelligent Agents – RMIT University – Melbourne, Australia
[55]Lin Padgham, Michael Winikoff – Prometheus: A Practical Agent-Oriented

Methodology – Methodologies and software Engineering for Agent Systems Chapter
V – 2005 – Pág. 107 - 135
Lin Padgham, Michael Winikoff – The prometheus methodology – RMIT University

[56]
– Abril 2004
[57] http://www.cs.cmu.edu/~./blangley/commusersguide/Overview.html
[58] http://www.cs.cmu.edu/~softagents/retsina.html
Katia Sycara, Massimo Paolucci, Martin van Velsen, Joseph Giampapa, The
[59]
RETSINA MAS infraestructure – Autonomous Agents and Multi-Agent Systems – July

2003, Volume 7 Pág. 29-48
[60]Fenando Alonso, Sonia Frutos, Lole Martinez, Cesar Montes – SONIA: A

Methodology for Natural Agent Development – In:Gleizes MP., Omicini A., Zambonelli
F. (eds) Engineering Societies in the Agents World V. ESAW 2004. Lecture Notes in
Computer Science, vol 3451. Springer, Berlin, Heidelberg
[61] http://www.troposproject.eu/
Paolo Giorgini, Manuel Kolp, John Mylopoulos, Pistone Marco – The Tropos
[62]
Methodology: An Overview – In Methodologies and Software Engineering for Agent

Systems, Kluwer – 2003
Alicia Martinez Rebollar, Hugo Estrada Esquivel, Luis Antonio Gama Moreno –
[63]
una guía rápida de la metodología tropos – Revista: Gerencia Tecnológica Informática

Vol. 7 Num19 (2008)
157
[64] Alicia Martinez, Hugo Estrada, Luis Antonio Gama, Carmen Velazco, Eliel Morales
– Lenguaje de especificación para el framework TROPOS – Conference: Anais do
WER10 - Workshop em Engenharia de Requisitos, Cuenca, Ecuador, April 12-13,
2010
[65] Jaron Collis, Divine Ndumu – The Role Modelling Guide – The Zeus Agent Building
Toolkit – Zeus Methodology Documentarion Part I – 2001
Jaron Collis, Divine Ndumu – ZEUS Technical Manial – The Zeus Agent Building
[66]
Toolkit – 1999
[67] www.fipa.org/resources/methodologies
[68] http://193.113.209.147/projects/agents/zeus/
J.C. Collis, D.T. Ndumu, H.S. Nwana L.C. Lee – The Zeus Agent tool-kit – BT
[69]
Technol J Vol 16 No 3 July 1998
[70]Daniel Antokoletz Huerta – “SPIA-Wari – Uso de un juego como laboratorio de

inteligencia artificial” – Tesis correspondiente al trabajo práctico de grado – Instituto
Universitario Aeronáutico – Universidad de la Defensa Nacional – 2014
158
10. Anexos
10.1. Códigos de transmisión.
A fin de poder minimizar los tiempos de transmisión entre equipos y simplificar el

envíos del string a las IA, se establece es siguiente código para las cantidades de
semillas por agujero y por almacén.
Códig Srin Semilla

o g s
64 @ 0
65 A 1
66 B 2
67 C 3
68 D 4
69 E 5
70 F 6
71 G 7
72 H 8
73 I 9
74 J 10
75 K 11
76 L 12
77 M 13
78 N 14
79 O 15
80 P 16
81 Q 17
159
82 R 18
83 S 19
84 T 20
85 U 21
86 V 22
87 W 23
88 X 24
89 Y 25
90 Z 26
91 [ 27
92 \ 28
93 ] 29
94 ^ 30
95 _ 31
96 ‘ 32
97 a 33
98 b 34
99 c 35
100 d 36
101 e 37
102 f 38
103 g 39
104 h 40
105 i 41
106 j 42
160
107 k 43
108 l 44
109 m 45
110 n 46
111 o 47
De manera que cuando el sistema envíe a la IA o a la red la siguiente cadena de

caracteres:
“DDDDDDDDDDDD@@”
Estaremos diciendo que hay 4 semillas en cada uno de los agujeros y ninguna en los
almacenes. Ésta es la configuración inicial del juego.
La cadena:
“AEEEEDDD@EEE@@”
Estamos indicando que en el primer agujero hay sólo una semilla, en el segundo,
tercero, cuarto y quinto hay cinco semillas, en el sexto, séptimo y octavo hay cuatro
semillas, en el noveno no hay semillas, en el décimo, décimo primero y en el décimo
segundo, hay cinco semillas. No hay semillas en el almacén. Esta configuración puede
surgir cuando el primer jugador selecciona el primer agujero, y el segundo jugador
selecciona el noveno agujero.
NOTA: Por lo poco que es necesario transmitir se optó por la sencillez dado que
comprimir la información no tiene sentido.
Las IA deberán devolver un número del 1 al 6 seleccionando el agujero del cual extraer
las semillas.
NOTA: El sistema acondicionará el string para que siempre el valor devuelto sea un
número del 1 al 6.
10.2. Reglas del juego WARI.
El wari es el ajedrez de África. Pertenece a la familia del manqala, juego practicado

desde hace milenios, en sus distintas variantes, por la gente de África y oriente medio.
La variante que se suele llamar «wari», «ourri», «warri», «oware», «awari», «awele»,
161
o similares --que es la que comentaré aquí-- se juega en Costa de Marfil y en el Caribe,

lugar al que fue llevada por los esclavos negros.
10.2.1. Material
El material no puede ser más simple:
Cuarenta y ocho piedrecitas, semillas, palitos... cualquier cosa pequeña vale.
Doce (aunque, por comodidad, suelen ser catorce) recipientes o agujeros. Pueden
hacerse en el suelo, en un trozo de madera, en un bloque de arcilla...
Y dos personas dispuestas a exprimirse el cerebro
10.2.2. Objetivo
El objetivo del juego es hacernos con mas piedras, garbanzos, o lo que sean, que el
contrario. Puesto que hay cuarenta y ocho al empezar el juego, con capturar
veinticinco habremos ganado la mayoría de ellas y, por lo tanto, la partida.
10.2.3. Reglas
Las reglas del wari son sencillísimas:
10.2.4. Tablero
El tablero (si queremos llamarle así) está compuesto por dos filas de seis recipientes
o agujeros. De ellas, la que está más cerca de nosotros es nuestra, y la que está más
cerca de nuestro contrario suya. Siempre se empieza a mover desde un hoyo de
nuestro lado del tablero, y siempre se come en los hoyos del lado contrario.
Al empezar el juego en cada uno de los doce hoyos habrá cuatro fichas.
Además de estos, suele haber dos hoyos suplementarios, uno en cada extremo del
tablero, que se llaman «casas». El que queda a nuestra derecha es nuestra casa, el
otro la casa del contrario. Sirven para ir dejando en ellos las fichas que comamos
durante la partida.
Veamos cómo sería un tablero con casas al inicio de la partida
10.2.5. Movimiento
Un movimiento consiste en lo siguiente:
Tomamos todas las piedras de uno de los hoyos de nuestro lado.
Las vamos depositando una a una en los hoyos siguientes (tanto nuestros como de
nuestro rival) en el sentido contrario al de las agujas del reloj.
por ejemplo, si el jugador A mueve el hoyo de más a su derecha:
(se ha representado el movimiento de la mano del jugador A con una flecha)
162
Si el hoyo inicial contenía en concreto doce o más piedras, daremos una vuelta
completa al tablero; en ese caso el hoyo del que tomamos las piedras debe saltarse.
Es decir, al finalizar un movimiento, da igual el número de piedras que contuviera el
hoyo inicial, éste debe quedar siempre vacío.
Veamos un ejemplo. El jugador B mueve el hoyo que se indica.
10.2.6. Capturas
La captura, si se produce, es la última parte del movimiento:
Si al depositar la última piedra de un movimiento se hace en un hoyo enemigo, y este
contiene (contando la piedra que acabamos de depositar) dos o tres piedras, estas
son comidas. Es decir, las sacaremos y las dejaremos en nuestra casa (o las
mantendremos en la mano si jugamos en un tablero sin casas).
Lo mismo iremos haciendo, uno a uno, con los hoyos anteriores al último siempre que
contengan dos o tres piedras y pertenezcan al enemigo, hasta que lleguemos a uno
que no cumpla alguna de estas condiciones (del que no tomaremos las piedras).
Veamos un ejemplo:
El movimiento de la mano de A al retirar las fichas capturadas se representa en el

siguiente diagrama con una flecha gris:
163
El máximo número de piedras que podremos comer en un movimiento es pues de

dieciocho (tres en cada uno de los seis hoyos del rival).
Veamos una de las maneras de conseguirlo:
10.2.7. Reglas Suplementarias

Las dos reglas suplementarias conciernen al caso de que un jugador se quede con
todos los hoyos de su lado vacíos. Esto puede suceder por dos motivos:
Si un jugador realiza un movimiento y queda sin fichas en sus hoyos, el rival está
obligado a realizar en su turno un movimiento que introduzca fichas en el lado del
jugador que se ha quedado sin ellas.
Veamos un caso:
B ha quedado sin fichas, en su siguiente movimiento A debe darle fichas con que
seguir jugando. Sólo puede hacerlo moviendo del hoyo señalado.
164
En caso de que esto no sea posible la partida finaliza y el jugador que conserva fichas
en sus hoyos une estas a las que comiera durante la partida. Se considera que
controla el tablero y que, por tanto, todas las fichas que queden sobre él son suyas.
Sin embargo, si un jugador realiza una captura y con ello deja al contrario sin fichas,
el contrario pasará en su turno y, siendo nuevamente el turno del que realizó la
captura, se aplica la regla anterior. Es decir, está obligado a introducir fichas en los
hoyos del adversario si le es posible. (el efecto es que el jugador que come todas las
fichas del lado del contrario, mueve de nuevo inmediatamente).
Veamos un caso:
B al comer ha dejado a A sin fichas, debe jugar inmediatamente y, aplicando la regla

anterior, debe mover del hoyo señalado, pues es el único movimiento que da fichas a
A.
10.2.8. Fin de la Partida

Cuando un jugador logra hacerse con la mayoría de las fichas (veinticinco o más), la
partida finaliza y ese jugador ha ganado.
Cuando un jugador logra controlar todas las fichas que quedan en el tablero como se
ha indicado más arriba, añade estas a las que haya comido y la partida finaliza. En
este caso ganará el jugador que haya conseguido el mayor número de fichas.
Veamos un ejemplo, le toca jugar a A (se observa que B está sin fichas y que A no
tiene ningún movimiento que se las dé, que son las dos condiciones para considerar
que A controla todas las fichas del tablero):
165
En ocasiones, cuando la partida está finalizando y quedan muy pocas fichas sobre el
tablero, se produce una posición que se repite cíclicamente sin que los jugadores
puedan o quieran evitarlo. En este caso la partida se considera finalizada y cada
jugador unirá a las que haya comido durante la partida las fichas que estén en su lado
del tablero.
Veamos una de tales posiciones:
Cuando ambos jugadores consiguen hacerse con veinticuatro fichas la partida termina
en empate.
10.2.9. Breves notas sobre técnica y estrategia

Una de las operaciones mentales más repetidas durante la partida de wari es calcular
en qué agujero acabará un determinado movimiento. Esto es importante al momento
de diseñar las inteligencias artificiales.
Hay un par de trucos que facilitan la vida:
El movimiento desde un agujero con seis fichas termina en el agujero que ocupa la
posición simétrica al de partida respecto al centro del tablero (el agujero final siempre
pertenecerá al rival, claro. A partir de esto, es fácil calcular dónde acabará el
movimiento de un hoyo con un número de fichas cercano a seis.
El movimiento desde un agujero con doce fichas termina en el agujero siguiente al que
contiene originalmente las fichas. A partir de esto, es fácil calcular también donde
acaban los movimientos de agujeros con algo más o menos de doce fichas.
En cuanto a la estrategia:
Acumular fichas: Una técnica básica es acumular cuantas más fichas mejor en uno de
los propios agujeros.
No dar fichas al rival: Una segunda técnica básica consiste en tratar de que los propios
movimientos no metan fichas en los agujeros del rival, sino que sean movimientos
cortos completamente dentro de los hoyos propios.
166
167

Tesis Final AntokoletzV4

Cargado por

Copyright:

Formatos disponibles

Tesis Final AntokoletzV4

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Tesis Final AntokoletzV4

Cargado por

Copyright:

Formatos disponibles

Facultad de Ciencias de la Administración

Carrera: Ingeniería de Sistemas

Director de tesis: Prof. Ing. Daniela Diaz

Fecha Versión Descripción Autor

11/08/2017 1.0.0 Creación Daniel Antokoletz Huerta

20/11/2018 2.0.0 Correcciones sugeridas por la tutora. Daniel Antokoletz Huerta

14/02/2019 3.0.0 Correcciones sugeridas por la tutora. Daniel Antokoletz Huerta

Dedico éste trabajo a Mónica, mi esposa y

Historia de Revisión del Documento ____________________________________________ 2

5. Metodologías de desarrollo de sistemas multiagente _________________________ 47

PARTE II: Desarrollo de la metodología y diseño de una aplicación.__________________ 75

7. Ejemplo de aplicación de la metodología MeDeSMAGF ______________________ 122

8. Conclusiones y próxima línea de investigación. ______________________________ 151

Ilustración 1:Paradigmas de programación ............................................................... 18

Laboratorio de inteligencia artificial

Listado de símbolos y convenciones

En el presente documento utilizaremos las siguientes definiciones, acrónimos y

S.P.I.A. Sistema de Prueba de Inteligencia Artificial.

GNU GNU es un acrónimo recursivo que significa GNU No es Unix (GNU is

Posix POSIX corresponde a las iniciales de interfase de sistema operativo

SMA Sistema Multi-Agente

RNA Red neuronal artificial

Semilla Es la ficha de juego

Según menciona Michael Wooldridge en "An introduction to multi-agent systems"[1] si

 Ubicuidad: Es indudable la continua reducción de costos y el aumento de la

 Interconexión: en la historia de la computación, los grandes computadores se

 Delegación: esta tendencia es una consecuencia lógica de la aplicación de las

 Orientación humana: La tendencia actual, es un movimiento alejándose de

Paradigma de programación orientada a agentes

Paradigma de programación orientada a objetos

Abstracción de tipos de datos

Ilustración 1:Paradigmas de programación

La programación orientada a agentes aparece como consecuencia de las tendencias

1.1. Motivación del proyecto

En mi proyecto de pregrado, he desarrollado un juego como laboratorio de inteligencia

1.2. Alcances del proyecto

El alcance total del proyecto es el desarrollo de una metodología de desarrollo de

1.3. Organización del trabajo

Este trabajo está desarrollado en tres partes y algunos anexos:

PARTE I: Marco Teórico: Agentes y programación orientada a agentes.

En ésta parte se expondrán los conceptos de agentes, los tipos de agentes,

PARTE II: Aplicación de la metodología

Se desarrollará una metodología para desarrollo de sistemas multiagente que guíe al

1.4. Mapa Conceptual

MASSIVE Sistema multiagente

Vowels Agentspeak KQML

Ilustración 2: Mapa conceptual

PARTE I - Marco teórico: De

El propósito de la esta sección, es presentar una introducción teórica de los sistemas

Es cuestión de tiempo que, por razones operativas, se vaya aumentando esa

En Rusia, las plataformas robóticas "Soldado universal", fueron diseñadas para

Sin importar su tamaño y complejidad, las computadoras necesitan de un conjunto de

Al darle más autonomía e inteligencia a programas podemos decir que nos

2.2. ¿Constituyen los agentes un nuevo paradigma de desarrollo

En primer lugar, se puede decir que un paradigma de programación, podría definirse

Si observamos la historia de la programación, podemos ver los siguientes paradigmas:

 Paradigma imperativo (procedimientos)

En la actualidad, la mayoría de los programadores se alinean con la programación