SISTEMAS MULTIANGENTES

ANDRES CALERO
ELMER GIL ANGULO
EDINSON

UNIVERSIDAD DEL PACIFICO

BUENAVENTURA-VALLE
2017
TRABAJO DE SISTEMAS MULTIANGENTES

ANDRES CALERO
ELMER GIL ANGULO
EDINSON

HERNAN GOMEZ

INTELIGENCIA ARTIFICIAL
INGENIERIA DE SISTEMAS

SEPTIMO SEMESTRE

UNIVERSIDAD DEL PACIFICO

BUENAVENTURA-VALLE
2017
 INTRODUCCION

El presente trabajo se realiza con el fin de dar a conocer la metodologa PASSI

que es una metodologa de multiagentes, se enunciaran conceptos, diagramas,
ejemplos y un resumen del tema.
Tambin se resalta que PASSI ha sido utilizado en una gran variedad de dominios
de aplicacin, tales como modelado de negocios , desarrollo de software
orientado a objetos e licitacin de requisitos de software, desarrollo de software
orientado a agentes , anlisis de requisitos no funcionales, requisitos de seguridad
y privacidad.
 OBJETIVO

Definir y darle claridad a PASSI como metodologa de multiagentes, basndose en

diagramas ejemplos y resumen.
 RESUMEN

Dentro del marco de la Inteligencia Artificial, los Sistemas Multiagente se han

caracterizado por ofrecer una posible solucin al desarrollo de problemas
complejos con caractersticas distribuidas. A la hora de abordar el desarrollo de
sistemas multiagente es indudable un notable aumento de complejidad, as como
la necesidad de adaptar tcnicas ya existentes o, en ocasiones, el desarrollo de
tcnicas y herramientas nuevas. Resulta evidente que el desarrollo de cualquier
tipo de software necesita de la existencia de mtodos y herramientas que faciliten
la obtencin de productos finales fiables. En esa lnea, en los ltimos aos han
aparecido diferentes trabajos que tratan de proponer procesos de desarrollo de
sistemas multiagente. En este artculo se presenta fundamentalmente un anlisis
de diversos mtodos de desarrollo de sistemas multiagente, as como una
ampliacin de uno de ellos para su adecuacin a entornos de tiempo real. El
paradigma de agentes y sistemas multiagente constituye actualmente un rea de
creciente inters dentro de la Inteligencia Artificial, entre otras razones, por ser
aplicable a la resolucin de problemas complejos no resueltos de manera
satisfactoria mediante tcnicas clsicas. Numerosas aplicaciones basadas en este
nuevo paradigma vienen ya siendo empleadas en infinidad de reas [Jennings98],
tales como control de procesos, procesos de produccin, control de trfico areo,
aplicaciones comerciales, gestin de informacin, comercio electrnico,
aplicaciones mdicas, juegos, etc.
En la actualidad, la complejidad de los sistemas de informacin ha forzado a los
ingenieros de software a plantearse seriamente el entendimiento profundo de la
organizacin antes de iniciar la construccin de un sistema de software que
automatice ciertos procesos de la empresa. Es por esta razn que, en los ltimos
aos, la etapa temprana de requisitos (aquella que considera los requisitos
organizacionales) ha adquirido una enorme importancia en el proceso de
produccin de software. En este sentido, PASSI dentro de esta metodologa
podemos identificar varias fases con las cuales se asegura llegar de la
especificacin del sistema a una versin implementarle. Dentro de la etapa de
anlisis, tenemos las siguientes fases: descripcin del dominio: utilizando los
diagramas de casos de uso de UML se describe el dominio de la aplicacin,
identificacin de agentes: a partir del diagrama anterior y utilizando Rational Rose
identificamos los agentes que componen el sistema, identi- ficcin de roles: los
roles de los agentes los representamos mediante diagramas de secuencia e
identificacin de tareas: se dibuja un diagrama de actividad para cada agente y se
deciden que tareas son necesarias para realizar las funcionalidades descritas
anteriormente.
En la segunda etapa, la etapa de diseo, podemos identificar otras fases entras
cuales se encuentran: descripcin de ontologas: se describe la sociedad desde el
punto de vista ontolgico, descripcin de roles: se modela la vida de los agentes
observando sus roles, descripcin de protocolos: se define cuales protocolos se
utilizaran y si es necesario, se definirn los nuevos, definicin de la estructura y
del comportamiento de los agentes: se disea la estructura de la sociedad y de los
agentes en particular. Finalmente tenemos las fases de implementacin y
configuracin. La fase de produccin de cdigo no est completamente
implementada, pero est en desarrollo la bsqueda de una solucin en un
metalenguaje basado en XML. En cuanto a la configuracin, se acenta su
importancia si se trabaja con agentes mviles y con problemas significativos en la
diseminacin de los agentes en el sistema.

Al concebir esta metodologa de diseo, seguimos una directriz especfica: la

siempre que sea posible. Esto justifica el uso de UML como modelo lenguaje, el
uso de la arquitectura FIPA para la implementacin de nuestros agentes, y el uso
de XML para representar el conocimiento intercambiado por los agentes en sus
mensajes. PASSI (Proceso de Especificacin e Implementacin de Sociedades de
Agentes) es un paso a paso la metodologa de requerimiento de cdigo para el
desarrollo de multiagentes que integra modelos de diseo y filosofas tanto desde
el punto de vista ingeniera de software y MAS utilizando (extendiendo ms
adecuadamente) el UML.

Debido a las necesidades especficas del diseo del agente, el UML semntica y
notacin se utilizarn como puntos de referencia, pero se extendern, y diagramas
UML a menudo se usan para representar conceptos que no son consideradas en
UML y la notacin se modificar para representar mejor lo que debe ser modelado
en el artefacto especfico. El proceso PASSI se compone de cinco componentes
del proceso: Requisitos del sistema, Sociedad de agentes, Agente Imple-
tentacin, Cdigo y Despliegue, y varias definiciones de trabajo cada uno de ellos
(Figura 1). La produccin de cdigo est fuertemente respaldada por la generacin
de una gran cantidad de cdigo gracias al PASSI ToolKit (PTK) utilizado para
disear el sistema y una biblioteca de patrones reutilizables de cdigo y piezas de
diseo gestionado por la aplicacin AgentFactory. En lo que sigue, los cinco
componentes del proceso se denominarn modelos y las definiciones de trabajo
como fases; para aclarar el significado de estos trminos, proporcionar un
paralelismo con el Meta modelo de Ingeniera de Procesos de Software (SPEM).
Refirindonos a SPEM, podramos decir que un proceso se compone de
componentes del proceso; cada componente del proceso podra ser por fases (un
tipo de definicin de trabajo) que a su vez se descomponen en actividades y pasos
(tanto las actividades como los pasos son de nuevo definiciones de trabajo).
Los "modelos" y las "fases" de PASSI son:

System Requirements Model: rene los requisitos del sistema en cuatro etapas.
Su primera etapa, Domain Requirements Description, recoge en diagramas de
casos de uso convencionales los requisitos de los escenarios posibles del sistema.
Las dems etapas describen una especiacin de alto nivel de los agentes, primero
haciendo una identificacin preliminar de los agentes y repartiendo los casos de
uso, posteriormente planteando los roles de los agentes mediante diagramas de
secuencia donde se presentan los escenarios principales del sistema, y fcilmente
se especifican las tareas asignadas a cada agente mediante diagramas de
actividades.
Agent Society Model: describe el conocimiento y las comunicaciones entre los
agentes que pueblan el sistema y por tanto, la ontologa del mismo. De esta forma,
en las diferentes etapas, se compone una descripcin de la ontologa mediante un
diagrama de clases, al que se aade otro que modela las interacciones (una clase
por cada clase de agente identicada y una relacin por cada comunicacin).
Posteriormente se asignan roles a las clases de agentes identificadas mediante
otro diagrama de clases (en este caso, los agentes se representan con paquetes y
los roles con clases). Finalmente, se especifican los protocolos que guan las
comunicaciones entre agentes, siguiendo los contenidos en el estndar FIPA o
definiendo nuevos mediante diagramas de secuencia AUML.
Agent Implementation Model: comienza definiendo tanto la estructura general del
sistema 10 como la estructura individual de los agentes. En el primer caso se har
mediante un diagrama de clases que representa las interacciones significativas
con el entorno mediante actores. Por otra parte, para la estructura individual, es
suficiente con un diagrama de clase corriente por cada clase de agentes.
La estructura definida ser completada con la especificacin del comportamiento
de los agentes a nivel global mediante diagramas de actividades, donde se
muestra la ejecucin de las diferentes tareas y los mensajes intercambiados. Para
expresar el comportamiento local de los agentes se considera suficiente una
descripcin informal de las tareas implementadas. Esto significa que la estructura
del sistema y de los agentes condiciona el comportamiento de estos, y al contrario.
De esta manera, existe una relacin iterativa entre la estructura y el
comportamiento del sistema.
Code Model: ocupa el lugar de la fase de implementacin. Esta fase se
desarrollar primero generando el cdigo a partir de los modelos mediante alguna
de las herramientas de soporte, que incluyen la generacin de plantillas adems
de la opcin de reutilizacin de patrones.
Deployment Model: describe el despliegue del sistema. Para ello, se utilizan
diagramas de despliegue con una sintaxis extendida para poder expresar la
movilidad de los agentes. Para finalizar la iteracin se considera el testing del
sistema desplegado. Como soporte a la metodologa, resulta destacable la
herramienta PASSI ToolKit (PTK), que incluye generacin de cdigo a nivel de
tmplate. Posteriormente, se completa manualmente el cdigo automticamente
generado previamente. Respecto a la enseanza de PASSI, no se ha encontrado
referencias.
 METODOLOGIA PASSI

El agente PASSI, se consideran en dos aspectos diferentes del agente: durante

los pasos iniciales del diseo, se considera como una entidad autnoma capaz de
perseguir un objetivo a travs de sus decisiones autnomas, acciones y relaciones
sociales. Esto ayuda en preparar una solucin que se implemente ms tarde,
refirindose al agente como importante unidad de software. Un agente puede
asumir varios roles funcionales durante interacciones con otros agentes para
lograr sus objetivos. Una funcin es una coleccin de tareas desempeado por el
agente en la consecucin de un subjetivo u ofreciendo algn otros miembros de la
sociedad. Una tarea, a su vez, se define como una unidad comportamiento
individual o interactivo. Cada agente tiene una representacin del mundo en
trminos de una ontologa a la que tambin se hace referencia en todos los
mensajes que los agentes intercambiar.

PASSI es iterativo, al igual que los mtodos orientados a objetos ms

ampliamente aceptados. Ah ocurren dos tipos de iteraciones en l. El primero
est liderado por nuevos requisitos e involucra a todos los modelos PASSI. La
segunda iteracin ocurre, implicando solamente modificaciones a la
Implementacin. Se caracteriza por un doble nivel de iteracin.
Este modelo se caracteriza por dos puntos de vista: el multi-agente y las vistas de
un solo agente. El nivel exterior de iteracin (flechas discontinuas) se refiere a las
dependencias entre las vistas de agentes mltiples y de agente nico. La primera
(multi- agente) se refiere a la estructura de los agentes (en trminos de
cooperacin y tareas implicados) y comportamientos (flujos de eventos que
representan la cooperacin). El segundo en su lugar se refiere a la estructura de
un solo agente (atributos, mtodos, clases internas) y el comportamiento
(especificado de una manera apropiada).
1. System Requirements Model. A lo largo de las diferentes etapas de esta fase se
identifican los agentes, y se determinan los casos de uso del sistema. Se platean
los posibles roles de cada agente mediante diagramas de secuencia y se
especifican las tareas asignadas a cada agente mediante diagramas de actividad.
2. Agente Society Model. Se describe el conocimiento y las comunicaciones entre
los agentes siguiente los contenidos FIPA o definiendo nuevos protocolos
mediante diagramas AUML.
3. Agent Implentatios Model. Se define la estructura general de sistema mediante
un diagrama de clases que representa las interacciones significativas y por otro
lado se define la estructura individual de cada agente con un diagrama de clase
por cada agente. Tambin se define el comportamiento de los agentes mediante
diagramas de actividad. La estructura del sistema y los agentes est condicionada
a el comportamiento y al contrario por lo que se hace necesario realizar
interacciones entre estas dos etapas.
4. Code Model. Se lleva a cabo la implementacin haciendo uso de herramientas
que ayuden a la generacin de cdigo mediante plantillas y uso de patrones.
5. Deployment Model. Se describe el despliegue del sistema mediante diagramas
de despliegue con una sintaxis extendida que permita la expresar la movilidad de
los agentes.
Ejemplo.
El sistema de subastas Para el desarrollo de este trabajo se ha optado por la
subasta inglesa. Es una subasta bien conocida y que no presenta mayores
problemas, aunque surgen ciertos problemas derivados de la complejidad del
sistema completo. Uno de ellos es que tenemos mltiples vendedores de un
mismo producto. Todos ellos quieren vender lo mximo posible cubriendo gastos y
obteniendo beneficios. Por otro lado tenemos mltiples compradores que quieren
comprar lo ms barato posible, pero una vez que acepten un acuerdo ya no
podrn participar en el resto de subastas en las que podran obtener un precio
menor. Si se pretende satisfacer a los compradores - y suponiendo que el
agricultor tiene suficiente cantidad de producto - el sistema solo atender a
aquellos agricultores que proporcionen el menor precio mnimo de venta, ya que
son con ellos con los que hay mayor probabilidad de obtener un mejor precio de
venta. Esto ira en contra de propio sistema, ya que si los agricultores no venden,
al final no usaran el sistema, por lo que hace necesario buscar un mtodo en el
que el mayor nmero de agricultores vendan y que adems sea los ms equitativo
posible. La solucin que se propone en este trabajo es la de imponer un turno
rotatorio de subastas y estudiar varias estrategias a la hora de seleccionar el
orden de las subastas en las que participan. Solo hemos hablado hasta ahora del
agricultor y el comprador, pero adems tenemos que buscar un transporte. Es
aqu donde surge el punto ms interesante del sistema de subasta propuesto.
Para buscar a un transportista, tambin se levantara una subasta entre todos los
transportistas del sistema para encontrar aquel que nos oferte el transporte ms
econmico. Es posible que no se encuentre, por lo que la subasta anterior
tampoco tendra validez sin transporte y quedara automticamente anulada. Lo
ideal sera que esta situacin no se produjese, es decir, que el sistema no tuviera
que cancelar ninguna subasta. Para ello surge la idea de una subasta a tres
bandas de la que no se ha encontrado literatura al respecto y que tampoco ha
podido ser desarrollada en este trabajo.
Por otro lado, el transportista estar dispuesto a hacer un transporte, no solo en
funcin de la localizacin del agricultor y del punto de entrega, sino tambin de la
ruta que ya tenga previamente definida. En definitiva, el encontrar el reparto ms
equitativo posible, que a todos deje contentos, sera el objetivo ideal a conseguir
para este proyecto.
Diseo del sistema Veremos en esa seccin cada una de los subsistemas
desarrollados, centrndonos especialmente en el SMA. Aunque no se ha seguido
una metodologa de desarrollo con rigurosidad en este trabajo, el desarrollo del
SMA ha estado guiado por la filosofa de la metodologa PASSI y sus fases de
desarrollo.
Modelo de datos
El modelo de datos de la aplicacin que podemos ver en el diagrama 4.3 ha ido
evolucionando a lo largo del desarrollo de este trabajo apareciendo y
desapareciendo tablas y atributos. La informacin que se almacena en este es la
siguiente:
Informacin de autenticacin de usuarios en la tabla userprofile. De esta tabla se
derivan las tablas Farmer, Buyer y Shipper como una especializacin para cada rol
del sistema.
Diseo del sistema 61 Informacin sobre localizacin en la tablas Province, City y
Localizacin.
Informacin sobre los productos agrcolas en las tablas FoodType, Variety y
Treatment.
Informacin de reglas para el sistema de subastas en las tablas BuyerRule,
ShippingRule y SaleRule.
Informacion sobre los acuerdos alcanzados por el sistema entre un agricultor, un
comprador y un transportista en la tabla FullDeal. Informacion sobre el dispositivo
Android del usuario para realizar las notificaciones en la tabla UserDevice.

Aplicacin web:
diseo y manual de uso. La aplicacin web se ha desarrollo con un estilo que se
adapte lo mejor posible a los dispositivos mviles. En la parte inferior se presenta
un men con las secciones principales de la aplicacin segn el rol del usuario. De
entre ellas, la seccin Direcciones es comn a todos los roles. Todos ellos
necesitan especificar una o varias direcciones para la recogida y entrega del
producto. En el caso del transportista adems se usa para calcular el tiempo de
transporte desde su direccin hasta el productor y posteriormente hasta el punto
de entrega. Podemos ver las pantallas en la imagen
4.4. Las alertas o notificaciones, aunque tambin es una seccin que est
presente en todos los roles, difieren un poco en la informacin que se muestra a
cada uno de ellos. Para el agricultor y el transportista, estas son nicamente un
elemento informativo de aquellos acuerdos que se han realizado con xito. En el
caso del comprador, adems en cada notificacin de acuerdo realizado tiene la
posibilidad de aceptar o rechazar ese acuerdo y continuar participando en la
subasta, por lo que su seccin de notificaciones est divido en notificaciones
pendientes, aceptadas y rechazadas como se puede apreciar en la imagen.
4.5 El resto de secciones son particulares de cada rol. En agricultor, deber crear
una o varias cosechas para especificar el producto y variedad cosechada, as
como los tratamientos aplicados, la produccin total estimada y las fechas de
recoleccin. Esta informacin no se usa para el proceso de subasta (a excepcin
del producto, variedad y tratamientos), pero puede ser de inters de los
compradores para determinar si aceptan o no la oferta alcanzada. En la imagen
4.6 podemos ver la pantalla de lista de cosechas por un lado y la pantalla de
edicin de una de estas.
Los agentes

El SMA mantiene varios tipos de agentes. En concreto, cada regla definida para la
subasta sera un agente por lo que tendremos un agente por cada regla de venta
de los agricultores, uno por cada regla de compra y uno por cada regla de
transporte. Estos agentes funcionaran como iniciadores o participantes de la
subasta. Adems se creara un agente inicial, denominado SynAgent, que es el
encargado de iniciar todo el sistema, obteniendo todas las reglas mediante la
interfaz REST y creando el comportamiento del sistema de turnos que veremos
ms adelante.

Adems de los agentes anteriores, cuando se gana una subasta entre un

comprador y un agricultor se creara un agente, llamado BAF (Buyer And Farmer)
para identificar ese acuerdo alcanzado y que funcionara como iniciador de la
subasta dedicada a la bsqueda de un transporte.

En la figura 4.12 podemos ver un diagrama de secuencias del funcionamiento

bsico del SMA.

El sistema de turnos

Como se ha mencionado anteriormente, el agente SynAgent crea un

comportamiento para gestionar el sistema de turnos de las subastas. La
implementacin se hace mediante una maquina finita de estados que podemos
ver en la imagen.
4.13

Este agente mantiene una lista de los agentes que representan cada regla de
venta. Dado que el orden en que se obtiene estas reglas de venta de la base de
datos siempre es el mismo, lo primero que debe hacer es realizar una
(des)ordenacin aleatoria, para evitar favorecer a ningn agricultor. Esta
(des)ordenacin se realiza cada vez que ha pasado por todas las reglas de venta.

Se estara intentado levantando subasta constantemente hasta que hayan pasado

un cierto nmero de minutos definidos sin llegar a conseguir ningn acuerdo
completo entre agricultor, comprador y transportista.

Los comportamientos

Se ha implementado mltiples comportamientos que podemos clasificar en tres

grupos: comportamientos de mensajera, comportamientos del sistema de turnos y
comportamientos del sistema de subasta 4.14. En el punto anterior ya se han visto
los comportamientos de turnos. Vamos a ver los otros dos grupos:

Comportamientos de mensajera La implementacin de la mensajera ha sido lo

ms delicado de implementar. Para facilitar su desarrollo se ha creado varios
comportamientos genricos que, implementan el envo y recepcin de los
mensajes y agregan el protocolo adecuado en funcin de lo que se quiere informar
o solicitar. Al crear el comportamiento se debe indicar el tipo de conversacin. Los
tipos disponibles son:
 LOCATION REQUEST: Se solicita la localizacin.

MAX PRICE TRANSPORT REQUEST: Se solicita el precio mximo para la

subasta de transporte.

PRICE PAID: Se solicita el precio pagado. KILOGRAMS BUY: Se solicita el

nmero kilogramos a transportar.

NO TRANSPORT FOUND INFORM: Se informa de que no se ha encontrado

transporte.

REGISTER: Se solicita a un agente su registro en las pginas amarillas.

START AUCTION PRICE: Se solicita el precio de inicio de la subasta.

START AUCTION: Se informa del comienzo de la subasta.

De esta forma si el agente comprador est dispuesto a informar de su localizacin

en caso de que se le solicite, nicamente tiene que agregar a sus
comportamientos un comportamiento DataRequestReceiver de tipo LOCATION
REQUEST. Igualmente, cuando se quiere solicitar la localizacin a otro agente,
solo es necesario agregar un comportamiento DataRequest del mismo tipo.
DataRequest ya se encarga de esperar la respuesta (mediante un comportamiento
DataReceiver) y procesarla adecuadamente. Si solo se quiere enviar una
informacin a otro agente, sin esperar ningn tipo de respuesta asociada, solo es
necesario usar un comportamiento DataInform.
Comportamientos del protocolo de subasta Como vemos en el diagrama de clases

4.14, a excepcin del agente BuyerConsumer, el resto de agentes solo

implementan un comportamiento relacionado con la subasta inglesa. En el caso de
Buyer consumer se han implementado varias estrategias de participacin en las
subastas para investigar de qu forma puede evolucionar el sistema en funcin de
distintos comportamientos y cmo adaptar el sistema para que sea lo ms efectivo
y util posible.

Vamos a ver una breve descripcin de los comportamientos ms importantes:

SaleRuleInitiator: Implementa el comportamiento iniciador de la subasta inglesa

entre una regla de venta definida por el agricultor y las reglas de compra de los
compradores. Esta implementacin nicamente devuelve el siguiente precio en la
subasta actual y el identificador del agricultor.
BuyerAndFarmerDealInitiator: Implementa el comportamiento iniciador de la
subasta inglesa para encontrar un transportista para un acuerdo ya alcanzado
entre un agricultor y un comprador. Este comportamiento slo tiene la
particularidad de que toma un precio inicial (el restante entre el mximo
establecido en la regla de compra y el pagado al agricultor) y va decreciendo en
cada iteracin, ya que se busca aquel transportista ms barato. Adems del
siguiente precio en la subasta en cada iteracin se devuelven los kilogramos de
producto a transportar, ya que esta informacin la necesitan los transportistas para
calcular sus beneficios y por tanto el precio mnimo al que pueden hacer dicho
transporte.

ShippingRuleParticipant: Implementa el rol participante de la subasta inglesa entre

un BAF y una regla de transporte. Para determinar si puede o no aceptar un
precio, este comportamiento tiene en cuenta los anteriores transportes ya
acordados y calcula una ruta obteniendo el coste total de todos los transportes. La
aceptacin o no de la oferta actual de la subasta dependera de:

La distancia total a recorrer. Se hace un clculo del coste aproximado en

combustible que sera restado a los beneficios.

El tiempo de transporte. En funcin de la distancia se calcula el tiempo de

transporte, al que se le aade un tiempo de carga y descarga en funcin de los
kilos a transportar. Si este tiempo supera un lmite establecido, se rechazara la
oferta. Adems este tiempo es usado para calcular las ganancias por hora.
 Los kilogramos a transportar. Cuantos ms kilos incluya la oferta, menor sera el
precio al que el transportista puede hacer dicho transporte ya que disminuye el
nmero de paradas y por tanto el tiempo de carga y descarga. Por otro lado, cada
transportista define un nmero de kilogramos mximos que puede transportar.

El beneficio por hora. Una vez calculado todos los parmetros anteriores, se
calculara el beneficio por hora y solo se aceptara el transporte si supera un
beneficio mnimo.

BuyerRuleParticipant Es una clase abstracta que expone varios mtodos a ser

implementados por las clases hijas para especificar la estrategia a seguir. La
estrategias implementadas en el sistema se basan en la eleccin del orden a
participar en la subastas. Las estrategias implementadas son:

Orden por menor precio de salida. Este comportamiento lo primero que hace es
pedir a todos los agentes de venta que les informe de su precio de salida. El
comportamiento mantendr una lista ordenada de los precios, e ira participando
en las subastas segn este orden.

Orden aleatorio. En este caso, una vez obtenidos todos los precios de salida, los
ordena aleatoriamente, e ira participando en las subastas segn ese orden.

Orden por cercana al agricultor. Obtiene la localizacin de cada agricultor, e ira

participando en cada subasta segn lo cerca que se encuentre de este.

Generoso. Este comportamiento, independiente de los precios participara

primero en las subastas de aquellos agricultores a los que no haya comprado
recientemente.

Para la subasta inglesa se ha usado la implementacin del protocolo especie-

ficado por FIPA encontrada en Google code1, la cual tena algn error que fue
solventado. En los grficos 4.15 4.16 podemos ver los diagramas de estados del
iniciador (el vendedor en nuestro caso) y el participante (los compradores).
Adems de la resolucin de los errores encontrados en la implementacin, esta
ha sido adaptada a nuestro caso. La implementacin nicamente enviaba el
precio de la siguiente iteracin a los participantes, pero en nuestro caso los
participantes en la subasta necesitan ms informacin, como por ejemplo el
identificador del vendedor y la localizacin para calcular las rutas y el coste de los
transportes.

Despliegue del sistema El sistema completo ha sido desplegado en el servidor

Mowento. La direccin del portal es http://mowento.cs.us.es/mercadosp2p.

Para instalar la aplicacin mvil solo es necesario acceder a la web mediante el

navegador del mvil. Esta detectara que se trata de un dispositivo Android y le
redirigira a la pgina de descarga. Tras la instalacin, la aplicacin le pedira el rol
y el nombre para crear su usuario. Las autenticaciones posteriores las realizara la
aplicacin automticamente. El sistema est funcionando lanzando las subastas
cada 30 minutos, con reglas generadas automticamente, por lo que puede ser
probado en cualquier momento. Todas las reglas generadas de agricultores y
compradores son sobre el producto naranjas barberas con tratamiento ecolgico,
por lo que si se quiere probar un agricultor nuevo o comprador nuevo es
aconsejable usar este producto y tratamiento para entrar en dichas subastas.

Los estudiantes e investigadores apreciaron la gua paso a paso proporcionada

por la metodologa y la han encontrado bastante fcil de aprender y de usar. Entre
las caractersticas ms apreciadas, podemos listar: la facilidad de transicin para
los diseadores procedentes del mundo, ya que las partes iniciales de PASSI
adoptan conceptos de anlisis de requisitos que son muy comunes en ese
contexto; las mltiples vistas que permiten una anlisis de sistemas complejos de
muchos aspectos diferentes; el apoyo de un herramienta de diseo especfico
(PTK, un complemento para Rational Rose), y los patrones reutilizacin que
permite un rpido desarrollo de MAS. El entorno de aplicacin que se ha utilizado
se bas en la arquitectura del FIPA de acuerdo con el objetivo de adoptar normas
siempre que sea posible. Ahora estamos trabajando en la mejora de la
herramienta CASE que apoya a PASSI y la ampliacin del patrn de repositorio
con el fin de aumentar an ms la productividad de la PASSI desarrollador.
 CONCLUCION

Se ha realizo un anlisis de distintas aproximaciones al problema de la

construccin de sistemas multi-agente. Como se pudo observar, estas
metodologas poseen una forma muy distinta de trabajo. Hay ms metodologas y
nos encontraremos que Cada una de ellas utiliza distintas tcnicas y modelos en
su bsqueda de modelar e implementar un sistema multi-agente. Tambin se vio
que esta metodologa de diseo y desarrollo de sistemas multi-agente est
fuertemente basada en el paradigma de orientacin a objetos. Basadas en este
paradigma hacen uso de algunos de sus modelos y de UML para las etapas de
anlisis y diseo del sistema.
 WEBGRAFIA Y BIBLIOGRAFIA

Brian Henderson-Sellers_ Paolo Giorgin ... ethodologies-Idea Group Pub (2005).

http://eprints.ucm.es/22643/1/principal.

http://sedici.unlp.edu.ar/bitstream/handle/10915/22566/Documento_completo.pdf?

sequence=1

http://opera.eii.us.es/sinergia/public/uploads/sinergia/entregables/2013-

2014/G2013-2014-12/Grupo12Memoria1.pdf

Wood, M. F. Multiagent systems engineering: A methodology for analysis and

design of multiagent systems. Masters thesis, Air Force Institute of Technology,

2000.

GIORGINI, Paolo y otros. Security and Trust Requirements Engineering. In

Foundations of Security Analysis and Design III - Tutorial Lectures, LNCS 3655,
2005.

AGENTTOOL. The agentTool Proyect. Kansas State University, Department of

Computing and Information Sciences, http://www.cis.ksu.edu/

sdeloach/ai/agentool.htm, 2003.

FIPA. Foundation for Intelligent Physical Agents. http://www.fipa.org/, 2002.