Metodologas de diseo de un SMA

La construccin de un SMA integran tecnologas de diferentes reas del conocimiento:

- Tcnicas de ingeniera de software para estructurar el proceso de desarrollo
- Tcnicas de inteligencia artificial para adoptar a los programas de capacidad para tratar
situaciones imprevistas y tomar decisiones.
- Tcnicas de programacin concurrente y distribuidos para tratar la coordinacin de tareas
ejecutadas en diferentes maquinas bajo diferentes polticas de planificacin.
Existen plataformas de desarrollo que dan soluciones parciales al modelado de comportamiento y a
la coordinacin de agentes. El rango va desde proporcionar servicios bsicos (gestin de agentes,
libreras de algoritmo, localizacin de agentes o movilidad), como JADE, Grasshopper o ABBLE,
hasta entornos de desarrollo donde se configuran armazones (frameworks) software como ZEUS o
agentTool.
A continuacin se describiran algunas metodologas que pueden ser utilizadas para el diseo de un
sistema multiagente (SMA).
AAII/BDI
Dentro de esta metodologa se consideran dos puntos de vistas:
- externo en el que se identifican los agentes y sus interacciones
- interno que describe el comportamiento de cada uno de los agentes
El desarrollo de un SMA est guiado por la elaboracin y refinamiento de estos puntos de vistas. El
proceso consta de varias iteraciones, considerando primero el punto de vista externo, seguido del
punto de vista interno.
El propsito del punto de vista externo es identificar una jerarqua de clases de agentes (el modelo
de agentes) y un conjunto de relaciones entre agentes (modelo de interacciones). Este proceso
permite asignar funcionalidad (servicios) a los agentes y determinar sus relaciones (de servicio e
interacciones).
El punto de vista interno, est basado en el modelo BDI, partiendo de los servicios proporcionados
por el agente y las interacciones y eventos asociados al agente, lo que permite determinar los
objetivos del agente, y mediante su descomposicin se van identificando sus subobjetivos hasta
llegar a un nivel suficiente de detalle en el que se pueden asociar planes par su ejecucin.
Ingeniera de las vocales
Esta metodologa considera cinco puntos de vista:
- Agente
- Entorno
- Interacciones
- Organizacin
- Usuario
Rol aparece de forma natural cuando se considera el aspecto organizacional del sistema, como es
el caso de los SMA. Los roles identifican la funcionalidad, en trminos de servicios, y las
caractersticas de las partes en las interacciones. Los agentes representan roles en el sistema, tiene
capacidades para realizar los servicios correspondientes.
MESSAGE e INGENIAS
MESSAGE (Methodology for Engineering Systems of Software Agents), sta es una metodologa
orientada a agentes la cual incorpora tcnicas de ingeniera del software cubriendo el anlisis y
diseo de sistemas multiagente. La metodologa provee un lenguaje, un mtodo y unas guas de
1

cmo aplicar la metodologa, centrndose en las fases de anlisis y diseo y lanzando ideas sobre el
resto de etapas como implementacin, pruebas e implantacin.
MESSAGE hace uso de un metamodelo para el modelado del SMA. Un agente es definido a partir
de un conjunto de caractersticas que deben tener aquellas entidades etiquetadas como agentes.
Estas caractersticas son:
- Un agente tiene cierto conocimiento del mundo donde vive.
- Un agente es responsable de alcanzar y mantener ciertos objetivos que caracterizan su conducta.
- Un agente es capaz de observar el estado de ciertos objetos en el entorno y de sentir ciertos
eventos.
- Las interacciones entre agentes son descritas en trminos de acciones comunicativas.
- Un agente puede ejecutar acciones que afecten a los objetos del entorno.
Una extensin de los metamodelos y su validacin mediante la experimentacin y el desarrollo de
varios casos de estudio, es la metodologa INGENIAS.
INGENIAS, como MESSAGE, define un conjunto de meta-modelos (una descripcin de alto nivel
de qu elementos tiene un modelo) con los que hay que describir el sistema. Los meta-modelos
indican qu hace falta para describir: agentes aislados, organizaciones de agentes, el entorno,
interacciones entre agentes o roles, tareas y objetivos. Estos metamodelos se construyen mediante
un lenguaje de meta-modelado, el GOPRR (Graph, Object, Property, Relationship, and Role). En la
construccin de estos meta-modelos se integran resultados de investigacin en forma de entidades y
relaciones entre entidades. La instanciacin de estos meta-modelos produce diagramas, los modelos,
similares a los que se usa en UML, con la diferencia de que estos diagramas se han creado
exclusivamente para definir el sistema multiagente.
El proceso de instanciacin de los meta-modelos no es trivial. Existen muchas entidades y
relaciones a identificar, adems de dependencias entre distintos modelos. Por ello, INGENIAS
define un conjunto de actividades cuya ejecucin termina en un conjunto de modelos. Estas
actividades a su vez se organizan siguiendo un paradigma de ingeniera del software, el Proceso
Unificado.
INGENIAS considera cinco puntos de vista para el diseo del SMA:
- Agente describe las responsabilidades con tareas y roles, control del agente definiendo sus
objetivos y estados mentales.
- Organizacin marco en el que existen agentes, recursos, tareas y propsitos del sistema. Para
definir la organizacin hay que considerar su estructura, relaciones sociales y funcionalidad.
- Entorno define sensores y actuadotes de los agentes, identificando recursos, agentes y
aplicaciones con las que tiene interaccin el agente (Web, BD, APIs).
- Tareas y objetivos descomposicin de tareas y objetivos.
- Interacciones coordinacin entre agentes.
MASSIVE
MASSIVE (Multi-Agent SystemS Iterative View Engineering) est constituido por un conjunto de
vistas diferentes del sistema a construir (siete puntos de vista) donde el desarrollo que se sigue
consiste en una visin iterativa del mismo. En l se combinan procesos de reingeniera junto con un
mtodo en cascada mejorado que permite realizar refinamientos. Los puntos de vistas son:
- Entorno
- Tareas
- Sistema
- Roles
- Interacciones
- Sociedad
- Arquitectura
2

ODAC
Esta metodologa considera utiliza los puntos de vista definidos en el estndar ODP (Open
Distributed Processing), los cuales son:
- Empresa
- Informacin
- Computacional
- Tecnologa
- Ingeniera
Tropos
En Tropos se presenta una metodologa de desarrollo de software basado en agentes mediante
extensiones de UML y empleando un entorno de modelado denominado i*. El concepto principal
sobre el que se desarrolla el proceso de anlisis y modelado es el de actor, as como sus objetivos y
posibles dependencias con otros actores. Maneja los puntos de vista siguientes:
- Requerimientos iniciales
- Requerimientos finales
(modelo actores y organziacion)
- Diseo arquitectnico (refinado y creacin de agentes)
- Diseo detallado (modelo interno de agentes)
MaSE
MaSE (Multiagent System Engineering), es una metodologa desarrollada en el Air Force Institute
of Technology. Dicha metodologa trata de cubrir todas la etapas en el proceso de construccin de
un sistema multiagente, partiendo de la especificacin del mismo hasta su implementacin. Dispone
de un lenguaje de especificacin basado en UML+OCL y una herramienta de desarrollo
denominada AgentTool que trata de cubrir la totalidad de fases de la metodologa pero que por el
momento se queda en slo una parte de ellas.
Un agente es visto como una abstraccin til para resolver problemas en dominios especficos.
Segn esto, un agente vendra caracterizado por lo siguiente:
- Los agentes son entidades que estn distribuidas.
- Los agentes son entidades autnomas, dirigidas por objetivos y sociales.
- Los agentes comparten informacin con otros agentes de forma interactiva, conformando sistemas
multiagente.
Puntos de vista manejados en MaSE:
- Captura de objetivos
- Aplicacin de casos de uso
- Transformacin de roles
- Creacin de clases de agente
- Construccin de conversaciones
- Ensamblado clase de agentes
- Diseo del sistema
MAS-CommonKADS
Esta metodologa extiende CommonKADS aplicando ideas de metodologas orientadas a objetos
para su aplicacin a la produccin de SMA. La metodologa CommonKADS gira alrededor del
modelo de experiencia y est pensada para desarrollar sistemas expertos que interactuen con el
usuario. De hecho considera slo dos agentes bsicos: el usuario y el sistema. MASCommonKADS
extiende los modelos de CommonKADS para tener en cuenta la posibilidad de que dos o ms
componentes del sistema interacten.

MAS-CommonKADS ha sido la primera en plantear un desarrollo de SMA integrado con un ciclo

de vida de software, concretamente el espiral dirigido por riesgos. Propone siete modelos para la
definicin del sistema:
- agente
- tareas
- experiencia
- coordinacin
-comunicacin
-organizacin
- diseo
Cada modelo presenta referencias a la teora sobre la que se basa. El modelo en s parte de una
descripcin grfica que luego se complementa con explicaciones en lenguaje natural de cada
elemento. Existe por cada modelo una descripcin de las dependencias respecto de otros modelos y
de las actividades involucradas. Estos modelos se hayan descritos ampliamente en lenguaje natural,
complementndose con otras notaciones como SDL (Specification and Description Language) o
MSC (Message Sequence Chart) para describir el comportamiento de los agentes cuando
interaccionan.
Regresando a sus principios, CommonKADS es una metodologa diseada para el desarrollo de
sistemas basados en conocimiento (SBC) de forma anloga a los mtodos empleados en ingeniera
software. El desarrollo de esta metodologa ha sido financiado por la Comunidad Europea entre
1983 y 1994 a travs de varios proyectos. Esta metodologa sigue una aproximacin al desarrollo de
SBC como la construccin de un nmero de modelos interrelacionados que capturan los principales
rasgos del sistema y de su entorno. El proceso de desarrollo de SBC consiste en rellenar un conjunto
de plantillas de los modelos. Asociados a estas plantillas, CommonKADS define estados de los
modelos que caracterizan hitos en el desarrollo de cada modelo. Estos estados permiten la gestin
del proyecto, cuyo desarrollo se realiza de una forma cclica dirigida por riesgos. Hay seis modelos
definidos en esta metodologa:
- Modelo de la Organizacin (OM): es una herramienta para analizar la organizacin en que
el SBC va a ser introducido.
- Modelo de Tarea (TM): describe a un nivel general las tareas que son realizadas o sern realizadas
en el entorno organizativo en que se propone instalar el SBC y proporciona el marco para la
distribucin de tareas entre los agentes.
- Modelo de Agente (AM): un agente es un ejecutor de una tarea. Puede ser humano, software o
cualquier otra entidad capaz de realizar una tarea. Este modelo describe las capacidades y
caractersticas de los agentes.
- Modelo de Comunicaciones (CM): detalla el intercambio de informacin entre los diferentes
agentes involucrados en la ejecucin de las tareas descritas en el modelo de tarea.
- Modelo de la Experiencia (EM): ste es el corazn de la metodologa y modela el conocimiento de
resolucin de problemas empleado por un agente para realizar una tarea.
El Modelo de la Experiencia distingue entre el conocimiento de la aplicacin y el conocimiento de
resolucin del problema. El conocimiento de la aplicacin se divide en tres subniveles: nivel del
dominio (conocimiento declarativo sobre el dominio), nivel de inferencia (una biblioteca de
estructuras genricas de inferencia) y nivel de tarea (orden de las inferencias).
- Modelo de Diseo (DM): mientras que los otros cinco modelos tratan del anlisis del SBC, este
modelo se utiliza para describir la arquitectura y el diseo tcnico del SBC como paso previo a su
implementacin.
En el caso de MAS-CommonKADS se proponen los siguientes modelos para el desarrollo de SMA:
- Modelo de Agente (AM): especfica las caractersticas de un agente: sus capacidades de
razonamiento, habilidades, servicios, sensores, efectores, grupos de agentes a los que pertenece y
4

clase de agente. Un agente puede ser un agente humano, software, o cualquier entidad capaz de
emplear un lenguaje de comunicacin de agentes.
- Modelo de Organizacin (OM): es una herramienta para analizar la organizacin humana en que el
sistema multiagente va a ser introducido y para describir la organizacin de los agentes software y
su relacin con el entorno.
- Modelo de Tareas (TM): describe las tareas que los agentes pueden realizar: los objetivos de cada
tarea, su descomposicin, los ingredientes y los mtodos de resolucin de problemas para resolver
cada objetivo.
- Modelo de la Experiencia (EM): describe el conocimiento necesitado por los agentes para
alcanzar sus objetivos. Sigue la descomposicin de CommonKADS y reutiliza las bibliotecas de
tareas genricas.
- Modelo de Comunicacin (CM): describe las interacciones entre un agente humano y un
agente software. Se centra en la consideracin de factores humanos para dicha interaccin.
- Modelo de Coordinacin (CoM): describe las interacciones entre agentes software.
- Modelo de Diseo (DM): mientras que los otros cinco modelos tratan del anlisis del sistema
multiagente, este modelo se utiliza para describir la arquitectura y el diseo del sistema multiagente
como paso previo a su implementacin.
El modelo de ciclo de vida para el desarrollo de sistemas multiagente con CommonKADS sigue las
siguientes fases:
- Conceptuacin: tarea de elicitacin (extraccin o adquisicin de conocimiento) para obtener una
primera descripcin del problema y la determinacin de los casos de uso que pueden ayudar a
entender los requisitos informales y a probar el sistema.
- Anlisis: determinacin de los requisitos de nuestro sistema partiendo del enunciado del problema.
Durante esta fase se desarrollan los siguientes modelos: organizacin, tareas, agente, comunicacin,
coordinacin y experiencia.
- Diseo: determinacin de cmo los requisitos de la fase de anlisis pueden ser logrados mediante
el desarrollo del modelo de diseo. Se determinan las arquitecturas tanto de la red
multiagente como de cada agente.
- Codificacin y prueba de cada agente.
- Integracin: el sistema completo es probado.
- Operacin y mantenimiento.
El modelo de ciclo de vida propuesto para desarrollar estas tareas en la metodologa es el modelo en
espiral dirigido por riesgos, siguiendo la gestin de proyectos de CommonKADS. Tanto para
proyectos pequeos como para el aprendizaje de la metodologa, se propone seguir otro modelo de
ciclo de vida, basado en un modelo en cascada con reutilizacin.
Los proyectos pequeos, desarrollados por una nica persona y con un nmero reducido de
agentes, pueden emplear un ciclo de vida convencional en el que se incluye la utilizacin de
componentes, que tambin se incluye en los proyectos grandes.
El desarrollo basado en componentes es un movimiento de la ingeniera software orientada a
objetos cuya base es el ensamblaje de componentes software previamente desarrollados y probados.
Para poder realizar este ensamblaje entre componentes heterogneos, la tecnologa de componentes
software debe basarse en estndares para componentes software como OpenDoc, CORBA u
OLE2.0. El paradigma de agentes tiene tambin como objetivo la interoperabilidad del software, y
parece apropiado hacer nfasis en el empleo de reutilizacin.
En un sistema multiagente se pueden identificar varios tipos de componentes: el agente, las
ontologas, los mtodos de resolucin de problemas, los servicios de un agente, y sus objetivos y
sus planes. En el caso de esta metodologa, la tarea de bsqueda y clasificacin de componentes se
lleva a cabo mediante la definicin de plantillas textuales para cada componente desarrollado en
cada modelo de sta.
5

Pasos de la metodologa
- Conceptuacin -- El objetivo de esta fase es comprender mejor cul es el sistema que desea el
cliente. Los principales resultados de esta fase sern una identificacin de los objetivos que debe
satisfacer el sistema desde el punto de vista del usuario, junto con la identificacin de los actores
que interactan con el sistema.
- Anlisis -- El resultado de esta fase es la especificacin del sistema compuesto a travs del
desarrollo de los modelos descritos anteriormente. Slo las extensiones a CommonKADS ern
desarrolladas en esta seccin. Los pasos de esta fase son:
1. Estudio de viabilidad: el modelo de organizacin permite modelar la organizacin en que
va a ser introducido el sistema multiagente, para estudiar las reas posibles de aplicacin de
sistemas inteligentes, su viabilidad y su posible impacto.
2. Delimitacin: delimita el sistema multiagente de los sistemas externos. El desarrollo del
modelo de organizacin habr delimitado la interaccin del sistema multiagente con el resto
de sistemas de la organizacin.
Los sistemas externos (predefinidos) deben ser encapsulados en agentes, modelados
mediante el desarrollo de ejemplares del modelo de agente, y modelando sus interacciones
mediante el desarrollo de modelos de coordinacin. En el caso de que haya interaccin con
agentes humanos, esta interaccin se describe en el modelo de comunicacin.
3. Descomposicin: el sistema se analiza mediante el desarrollo solapado de varios puntos
de vista:
= Descomposicin funcional: se descompone el sistema en funciones (tareas u objetivos)
que deben ser realizados, mediante el desarrollo de un modelo de tareas global.
= Descomposicin en ejecutores: el sistema se descompone en agentes que realizan las
funciones anteriormente desarrolladas, mediante el desarrollo del modelo de agente.
4. Descripcin de las interfaces: tomando como punto de partida la fase de conceptuacin y
el modelo de agente, se describen las relaciones estticas que determinan los canales de
comunicacin con otros agentes y con el exterior mediante el desarrollo del modelo de la
organizacin de los agentes. Es necesario identificar los flujos de comunicacin de la
organizacin, que sern motivados, principalmente, por la necesidad de informacin y para
evitar o resolver conflictos.
5. Identificacin y descripcin de interacciones: la identificacin y descripcin de las
relaciones dinmicas entre los agentes se realiza de la siguiente manera:
= Las interacciones dinmicas con otros agentes software se describen en el modelo de
coordinacin.
= Las interacciones dinmicas con agentes humanos se describen en el modelo de
comunicacin.
6. Descripcin del razonamiento de los agentes: para cada agente, se debe modelar el
conocimiento que necesita para llevar a cabo sus objetivos, mediante el desarrollo del
modelo de la experiencia.
7. Validacin:
= Cada vez que un agente es descompuesto en nuevos agentes, stos deben ser consistentes
lgicamente con la definicin previa:
* Los subagentes son responsables de los objetivos del agente.
* Los subagentes deben ser consistentes con el modelo de coordinacin y mantener las
mismas interacciones externas.
= Validacin cruzada con los otros modelos.
= Los conflictos detectados en los escenarios deben tener determinado al menos un mtodo
de resolucin de conflictos.
- Diseo -- Como resultado de la fase de anlisis, un conjunto inicial de agentes ha sido
determinado, as como sus objetivos, capacidades e interacciones. Durante esta fase se desarrolla el
Modelo de Diseo, que se basa en extender el modelo homnimo de CommonKADS para disear
6

sistemas multiagente. El Modelo de Diseo recopila los modelos desarrollados en el anlisis y se

subdivide en tres actividades:
= Diseo de la aplicacin. El sistema es descompuesto en subsistemas. Para una arquitectura
multiagente, se determina la arquitectura de ms adecuada para cada agente.
= Diseo de la arquitectura. En nuestro caso, se selecciona una arquitectura multiagente (en
vez de, por ejemplo, una pizarra o una descomposicin orientada a objetos). Se propone que en este
punto se determine la infraestructura del sistema multiagente (el denominado
modelo de red). Durante el diseo de la arquitectura se definen los agentes (denominados
agentes de red) que mantienen dicha infraestructura.
= Diseo de la plataforma. Se especifica el software y hardware que se necesita (o est disponible)
para el sistema.
- Codificacin y prueba -- sta es una cuestin abierta. Las dos tendencias principales son el
uso de un lenguaje de propsito general y la utilizacin de un lenguaje formal de agentes, que puede
ser directamente ejecutable o traducible a una forma ejecutable.
- Integracin y prueba global -- Se puede comprobar parcialmente la correccin de la conducta
global del sistema utilizando los escenarios tpicos que tratan los posibles conflictos y los mtodos
de resolucin de los mismos. Pero, dado que la conducta global del sistema no puede ser
determinada durante la fase de anlisis o diseo, porque depende de los acuerdos y compromisos
concretos realizados entre los agentes, normalmente se necesitar recurrir a la simulacin.
- Operacin y mantenimiento -- Una vez probado el sistema, puede ponerse en operacin. La
filosofa de los agentes facilita el mantenimiento del sistema dada su naturaleza modular.
Para el caso de modelo de proyectos grandes, se sigue un ciclo de vida en espiral, dirigido por
riesgos. En la primera fase de cada ciclo se identifican los objetivos de dicho ciclo y se establece
qu productos deben desarrollarse para satisfacer dichos objetivos; en la segunda se identifican los
riesgos asociados tanto a los objetivos como a la realizacin de productos, y se ordenan dichos
riesgos por orden de prioridad; el tercer paso es construir un plan de trabajo, definiendo actividades
para realizar los productos y asignando recursos a dichas actividades; para finalizar, la ltima fase
de cada ciclo consiste en realizar los planes y supervisar los criterios de calidad establecidos.
En MAS-CommonKADS, los productos se corresponden con estados alcanzados de un modelo.
Estos estados se asocian a objetivos y riesgos. Es necesario, por tanto, establecer los estados del
modelo de coordinacin para que pueda ser gestionado.
Definicin de estados de MAS-CommonKADS
Se define el estado a partir de los siguientes atributos:
- Modelo: nombre del modelo de MAS-CommonKADS para el que se define el estado (modelo de
agente, modelo de tarea, modelo de la experiencia, modelo de organizacin, modelo de
comunicacin, modelo de coordinacin, modelo de diseo).
- Variable del estado: nombre del aspecto del modelo cuyo estado es de inters. Dicho aspecto
depende de la granularidad escogida para gestionar un modelo. Normalmente ser el nombre de un
constituyente del modelo o de una relacin del modelo.
- Valor: Valor de la variable del estado. Este valor puede definirse de una forma cuantitativa (p. ej.
33% del modelo realizado), declarativa (empleando un lenguaje de representacin formal,
semiformal o informal) o cualitativa. Se ha preferido la descripcin cualitativa, definiendo el
siguiente conjunto de etiquetas:
= Vaco: ningn trabajo ha sido hecho.
= Requisitos identificados: los requisitos que parten de otras partes del modelo se han listado.
= Restricciones identificadas: las restricciones de la estructura interna se han clarificado.
= Entradas identificadas: las fuentes de informacin necesarias para construir los componentes del
modelo han sido documentadas.
= Identificado: los rasgos de los componentes del modelo han sido listados.
1. Debido a la simultaneidad en el desarrollo de la mayora de los modelos de CommonKADS y a
que fueron desarrollados por diferentes autores, no se emplean de forma consistente los estados en
7

la definicin de los modelos. En este apartado se adopta la definicin de los estados segn las
directrices generales de CommonKADS y el modelo de Organizacin, ya que ambos documentos
fueron elaborados por los mismos autores.
= Descrito: los componentes del modelo han sido descritos en detalle.
= Verificado: la consistencia interna y correccin de los componentes del modelo ha sido
establecida.
= Validado: los componentes del modelo han sido comprobados con criterios (externos) de
validacin.
= Completo: el modelo ha sido descrito y validado con respecto a su completitud.
= Descartado: los trabajos adicionales han sido cancelados.
= Aprobado: la especificacin de los componentes del modelo ha sido aceptada y aprobada por el
cliente.
- Papel: los estados pueden desempear los siguientes papeles (roles):
= Intermedio: empleado slo para supervisin interna.
= Hito interno (landmark): empleado para revisin en la conclusin de un ciclo de gestin del
proyecto.
= Hito externo (milestone): estado hito interno en que se entrega un producto al cliente.
= Obligatorio: estado que debe realizarse en todo proyecto para asegurar la calidad del proyecto.
= Definido por el usuario: cualquier estado que el usuario de la metodologa desee definir.
- Dependencias entre estados: representa cmo un estado est relacionado con otros estados.
Pueden darse dependencias internas (entre elementos de un modelo) o externas (entre elementos de
modelos diferentes).
- Mtricas de calidad del estado.
En la prctica, se emplean simplificaciones en la definicin de un estado:
- Se omite la descripcin cuantitativa y declarativa de los estados.
- La designacin de estado hito (interno o externo) o definido por el usuario se deja al gestor del
proyecto. Salvo que se indique que el estado es obligatorio, se considera que un estado es
intermedio.
- No se definen mtricas de calidad, que se deja para futuras investigaciones.
- Los modelos slo emplean cuatro estados posibles: vaco, identificado, descrito y validado, con el
siguiente significado:
= Vaco: no hay informacin disponible sobre el componente del modelo.
= Identificado: los nombres de los principales componentes se han definido, por ejemplo, los
nombres de los agentes del sistema, pero an no se ha concretado su significado.
= Descrito: se han descrito los nombres previamente identificados.
= Validado: hay una fuerte evidencia de que la informacin es correcta.
- Se asume una relacin de orden entre los valores posibles de un estado: descrito requiere
identificado, y validado requiere descrito.