Algunas metodologia para el desarrollo de Agentes

Metodologías de diseño de un SMA
La construcción de un SMA integran tecnologías de diferentes áreas del conocimiento:
- Técnicas de ingeniería de software para estructurar el proceso de desarrollo
- Técnicas de inteligencia artificial para adoptar a los programas de capacidad para tratar
situaciones imprevistas y tomar decisiones.
- Técnicas de programación concurrente y distribuidos para tratar la coordinación de tareas
ejecutadas en diferentes maquinas bajo diferentes políticas de planificación.
Existen plataformas de desarrollo que dan soluciones parciales al modelado de comportamiento y a
la coordinación de agentes. El rango va desde proporcionar servicios básicos (gestión de agentes,
librerías de algoritmo, localización de agentes o movilidad), como JADE, Grasshopper o ABBLE,
hasta entornos de desarrollo donde se configuran armazones (frameworks) software como ZEUS o
agentTool.
A continuación se describiran algunas metodologías que pueden ser utilizadas para el diseño de un
sistema multiagente (SMA).
AAII/BDI
Dentro de esta metodología 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 elaboración 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 propósito del punto de vista externo es identificar una jerarquía 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 descomposición se van identificando sus subobjetivos hasta
llegar a un nivel suficiente de detalle en el que se pueden asociar planes par su ejecución.
Ingeniería de las vocales
Esta metodología considera cinco puntos de vista:
- Agente
- Entorno
- Interacciones
- Organización
- 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 términos de servicios, y las
características 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 metodología
orientada a agentes la cual incorpora técnicas de ingeniería del software cubriendo el análisis y
diseño de sistemas multiagente. La metodología provee un lenguaje, un método y unas guías de
1
cómo aplicar la metodología, centrándose en las fases de análisis y diseño y lanzando ideas sobre el
resto de etapas como implementación, pruebas e implantación.
MESSAGE hace uso de un metamodelo para el modelado del SMA. Un agente es definido a partir
de un conjunto de características que deben tener aquellas entidades etiquetadas como agentes.
Estas características 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 términos de acciones comunicativas.
- Un agente puede ejecutar acciones que afecten a los objetos del entorno.
Una extensión de los metamodelos y su validación mediante la experimentación y el desarrollo de
varios casos de estudio, es la metodología INGENIAS.
INGENIAS, como MESSAGE, define un conjunto de meta-modelos (una descripción 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
construcción de estos meta-modelos se integran resultados de investigación en forma de entidades y
relaciones entre entidades. La instanciación 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 instanciación de los meta-modelos no es trivial. Existen muchas entidades y
relaciones a identificar, además de dependencias entre distintos modelos. Por ello, INGENIAS
define un conjunto de actividades cuya ejecución termina en un conjunto de modelos. Estas
actividades a su vez se organizan siguiendo un paradigma de ingeniería del software, el Proceso
Unificado.
INGENIAS considera cinco puntos de vista para el diseño del SMA:
- Agente – describe las responsabilidades con tareas y roles, control del agente definiendo sus
objetivos y estados mentales.
- Organización – marco en el que existen agentes, recursos, tareas y propósitos del sistema. Para
definir la organización 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 interacción el agente (Web, BD, API´s).
- Tareas y objetivos – descomposición de tareas y objetivos.
- Interacciones – coordinación 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 visión iterativa del mismo. En él se combinan procesos de reingeniería junto con un
método en cascada mejorado que permite realizar refinamientos. Los puntos de vistas son:
- Entorno
- Tareas
- Sistema
- Roles
- Interacciones
- Sociedad
- Arquitectura
2
ODAC
Esta metodología considera utiliza los puntos de vista definidos en el estándar ODP (Open
Distributed Processing), los cuales son:
- Empresa
- Información
- Computacional
- Tecnología
- Ingeniería
Tropos
En Tropos se presenta una metodología 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 análisis 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)
- Diseño arquitectónico (refinado y creación de agentes)
- Diseño detallado (modelo interno de agentes)
MaSE
MaSE (Multiagent System Engineering), es una metodología desarrollada en el Air Force Institute
of Technology. Dicha metodología trata de cubrir todas la etapas en el proceso de construcción de
un sistema multiagente, partiendo de la especificación del mismo hasta su implementación. Dispone
de un lenguaje de especificación basado en UML+OCL y una herramienta de desarrollo
denominada AgentTool que trata de cubrir la totalidad de fases de la metodología pero que por el
momento se queda en sólo una parte de ellas.
Un agente es visto como una abstracción útil para resolver problemas en dominios específicos.
Según esto, un agente vendría caracterizado por lo siguiente:
- Los agentes son entidades que están distribuidas.
- Los agentes son entidades autónomas, dirigidas por objetivos y sociales.
- Los agentes comparten información con otros agentes de forma interactiva, conformando sistemas
multiagente.
Puntos de vista manejados en MaSE:
- Captura de objetivos
- Aplicación de casos de uso
- Transformación de roles
- Creación de clases de agente
- Construcción de conversaciones
- Ensamblado clase de agentes
- Diseño del sistema
MAS-CommonKADS
Esta metodología extiende CommonKADS aplicando ideas de metodologías orientadas a objetos
para su aplicación a la producción de SMA. La metodología CommonKADS gira alrededor del
modelo de experiencia y está pensada para desarrollar sistemas expertos que interactuen con el
usuario. De hecho considera sólo dos agentes básicos: el usuario y el sistema. MASCommonKADS
extiende los modelos de CommonKADS para tener en cuenta la posibilidad de que dos o más
componentes del sistema interactúen.
3
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
definición del sistema:
- agente
- tareas
- experiencia
- coordinación
-comunicación
-organización
- diseño
Cada modelo presenta referencias a la teoría sobre la que se basa. El modelo en sí parte de una
descripción gráfica que luego se complementa con explicaciones en lenguaje natural de cada
elemento. Existe por cada modelo una descripción de las dependencias respecto de otros modelos y
de las actividades involucradas. Estos modelos se hayan descritos ampliamente en lenguaje natural,
complementándose 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 metodología diseñada para el desarrollo de
sistemas basados en conocimiento (SBC) de forma análoga a los métodos empleados en ingeniería
software. El desarrollo de esta metodología ha sido financiado por la Comunidad Europea entre
1983 y 1994 a través de varios proyectos. Esta metodología sigue una aproximación al desarrollo de
SBC como la construcción de un número 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 gestión
del proyecto, cuyo desarrollo se realiza de una forma cíclica dirigida por riesgos. Hay seis modelos
definidos en esta metodología:
- Modelo de la Organización (OM): es una herramienta para analizar la organización en que
el SBC va a ser introducido.
- Modelo de Tarea (TM): describe a un nivel general las tareas que son realizadas o serán realizadas
en el entorno organizativo en que se propone instalar el SBC y proporciona el marco para la
distribución 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
características de los agentes.
- Modelo de Comunicaciones (CM): detalla el intercambio de información entre los diferentes
agentes involucrados en la ejecución de las tareas descritas en el modelo de tarea.
- Modelo de la Experiencia (EM): éste es el corazón de la metodología y modela el conocimiento de
resolución de problemas empleado por un agente para realizar una tarea.
El Modelo de la Experiencia distingue entre el conocimiento de la aplicación y el conocimiento de
resolución del problema. El conocimiento de la aplicación se divide en tres subniveles: nivel del
dominio (conocimiento declarativo sobre el dominio), nivel de inferencia (una biblioteca de
estructuras genéricas de inferencia) y nivel de tarea (orden de las inferencias).
- Modelo de Diseño (DM): mientras que los otros cinco modelos tratan del análisis del SBC, este
modelo se utiliza para describir la arquitectura y el diseño técnico del SBC como paso previo a su
implementación.
En el caso de MAS-CommonKADS se proponen los siguientes modelos para el desarrollo de SMA:
- Modelo de Agente (AM): específica las características 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 comunicación de agentes.
- Modelo de Organización (OM): es una herramienta para analizar la organización humana en que
el sistema multiagente va a ser introducido y para describir la organización de los agentes software
y su relación con el entorno.
- Modelo de Tareas (TM): describe las tareas que los agentes pueden realizar: los objetivos de cada
tarea, su descomposición, los ingredientes y los métodos de resolución de problemas para resolver
cada objetivo.
- Modelo de la Experiencia (EM): describe el conocimiento necesitado por los agentes para
alcanzar sus objetivos. Sigue la descomposición de CommonKADS y reutiliza las bibliotecas de
tareas genéricas.
- Modelo de Comunicación (CM): describe las interacciones entre un agente humano y un
agente software. Se centra en la consideración de factores humanos para dicha interacción.
- Modelo de Coordinación (CoM): describe las interacciones entre agentes software.
- Modelo de Diseño (DM): mientras que los otros cinco modelos tratan del análisis del sistema
multiagente, este modelo se utiliza para describir la arquitectura y el diseño del sistema multiagente
como paso previo a su implementación.
El modelo de ciclo de vida para el desarrollo de sistemas multiagente con CommonKADS sigue las
siguientes fases:
- Conceptuación: tarea de elicitación (extracción o adquisición de conocimiento) para obtener una
primera descripción del problema y la determinación de los casos de uso que pueden ayudar a
entender los requisitos informales y a probar el sistema.
- Análisis: determinación de los requisitos de nuestro sistema partiendo del enunciado del problema.
Durante esta fase se desarrollan los siguientes modelos: organización, tareas, agente, comunicación,
coordinación y experiencia.
- Diseño: determinación de cómo los requisitos de la fase de análisis pueden ser logrados mediante
el desarrollo del modelo de diseño. Se determinan las arquitecturas tanto de la red
multiagente como de cada agente.
- Codificación y prueba de cada agente.
- Integración: el sistema completo es probado.
- Operación y mantenimiento.
El modelo de ciclo de vida propuesto para desarrollar estas tareas en la metodología es el modelo en
espiral dirigido por riesgos, siguiendo la gestión de proyectos de CommonKADS. Tanto para
proyectos pequeños como para el aprendizaje de la metodología, se propone seguir otro modelo de
ciclo de vida, basado en un modelo en cascada con reutilización.
Los proyectos pequeños, desarrollados por una única persona y con un número reducido de
agentes, pueden emplear un ciclo de vida convencional en el que se incluye la utilización de
componentes, que también se incluye en los proyectos grandes.
El desarrollo basado en componentes es un movimiento de la ingeniería software orientada a
objetos cuya base es el ensamblaje de componentes software previamente desarrollados y probados.
Para poder realizar este ensamblaje entre componentes heterogéneos, la tecnología de componentes
software debe basarse en estándares para componentes software como OpenDoc, CORBA u
OLE2.0. El paradigma de agentes tiene también como objetivo la interoperabilidad del software, y
parece apropiado hacer énfasis en el empleo de reutilización.
En un sistema multiagente se pueden identificar varios tipos de componentes: el agente, las
ontologías, los métodos de resolución de problemas, los servicios de un agente, y sus objetivos y
sus planes. En el caso de esta metodología, la tarea de búsqueda y clasificación de componentes se
lleva a cabo mediante la definición de plantillas textuales para cada componente desarrollado en
cada modelo de ésta.
5
Pasos de la metodología
- Conceptuación -- El objetivo de esta fase es comprender mejor cuál es el sistema que desea el
cliente. Los principales resultados de esta fase serán una identificación de los objetivos que debe
satisfacer el sistema desde el punto de vista del usuario, junto con la identificación de los actores
que interactúan con el sistema.
- Análisis -- El resultado de esta fase es la especificación del sistema compuesto a través del
desarrollo de los modelos descritos anteriormente. Sólo las extensiones a CommonKADS erán
desarrolladas en esta sección. Los pasos de esta fase son:
1. Estudio de viabilidad: el modelo de organización permite modelar la organización en que
va a ser introducido el sistema multiagente, para estudiar las áreas posibles de aplicación de
sistemas inteligentes, su viabilidad y su posible impacto.
2. Delimitación: delimita el sistema multiagente de los sistemas externos. El desarrollo del
modelo de organización habrá delimitado la interacción del sistema multiagente con el resto
de sistemas de la organización.
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 coordinación. En el caso de que haya interacción con
agentes humanos, esta interacción se describe en el modelo de comunicación.
3. Descomposición: el sistema se analiza mediante el desarrollo solapado de varios puntos
de vista:
= Descomposición funcional: se descompone el sistema en funciones (tareas u objetivos)
que deben ser realizados, mediante el desarrollo de un modelo de tareas global.
= Descomposición en ejecutores: el sistema se descompone en agentes que realizan las
funciones anteriormente desarrolladas, mediante el desarrollo del modelo de agente.
4. Descripción de las interfaces: tomando como punto de partida la fase de conceptuación y
el modelo de agente, se describen las relaciones estáticas que determinan los canales de
comunicación con otros agentes y con el exterior mediante el desarrollo del modelo de la
organización de los agentes. Es necesario identificar los flujos de comunicación de la
organización, que serán motivados, principalmente, por la necesidad de información y para
evitar o resolver conflictos.
5. Identificación y descripción de interacciones: la identificación y descripción de las
relaciones dinámicas entre los agentes se realiza de la siguiente manera:
= Las interacciones dinámicas con otros agentes software se describen en el modelo de
coordinación.
= Las interacciones dinámicas con agentes humanos se describen en el modelo de
comunicación.
6. Descripción 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. Validación:
= Cada vez que un agente es descompuesto en nuevos agentes, éstos deben ser consistentes
lógicamente con la definición previa:
* Los subagentes son responsables de los objetivos del agente.
* Los subagentes deben ser consistentes con el modelo de coordinación y mantener las
mismas interacciones externas.
= Validación cruzada con los otros modelos.
= Los conflictos detectados en los escenarios deben tener determinado al menos un método
de resolución de conflictos.
- Diseño -- Como resultado de la fase de análisis, un conjunto inicial de agentes ha sido
determinado, así como sus objetivos, capacidades e interacciones. Durante esta fase se desarrolla el
Modelo de Diseño, que se basa en extender el modelo homónimo de CommonKADS para diseñar
6
sistemas multiagente. El Modelo de Diseño recopila los modelos desarrollados en el análisis y se
subdivide en tres actividades:
= Diseño de la aplicación. El sistema es descompuesto en subsistemas. Para una arquitectura
multiagente, se determina la arquitectura de más adecuada para cada agente.
= Diseño de la arquitectura. En nuestro caso, se selecciona una arquitectura multiagente (en
vez de, por ejemplo, una pizarra o una descomposición orientada a objetos). Se propone que en este
punto se determine la infraestructura del sistema multiagente (el denominado
modelo de red). Durante el diseño de la arquitectura se definen los agentes (denominados
agentes de red) que mantienen dicha infraestructura.
= Diseño de la plataforma. Se especifica el software y hardware que se necesita (o está disponible)
para el sistema.
- Codificación y prueba -- ésta es una cuestión abierta. Las dos tendencias principales son el
uso de un lenguaje de propósito general y la utilización de un lenguaje formal de agentes, que puede
ser directamente ejecutable o traducible a una forma ejecutable.
- Integración y prueba global -- Se puede comprobar parcialmente la corrección de la conducta
global del sistema utilizando los escenarios típicos que tratan los posibles conflictos y los métodos
de resolución de los mismos. Pero, dado que la conducta global del sistema no puede ser
determinada durante la fase de análisis o diseño, porque depende de los acuerdos y compromisos
concretos realizados entre los agentes, normalmente se necesitará recurrir a la simulación.
- Operación y mantenimiento -- Una vez probado el sistema, puede ponerse en operación. La
filosofía 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 realización 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 coordinación para que pueda ser gestionado.
Definición 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 organización, modelo de
comunicación, modelo de coordinación, modelo de diseño).
- Variable del estado: nombre del aspecto del modelo cuyo estado es de interés. Dicho aspecto
depende de la granularidad escogida para gestionar un modelo. Normalmente será el nombre de un
constituyente del modelo o de una relación 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 representación formal,
semiformal o informal) o cualitativa. Se ha preferido la descripción cualitativa, definiendo el
siguiente conjunto de etiquetas:
= Vacío: ningún 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 información 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 mayoría de los modelos de CommonKADS y a
que fueron desarrollados por diferentes autores, no se emplean de forma consistente los estados en
7
la definición de los modelos. En este apartado se adopta la definición de los estados según las
directrices generales de CommonKADS y el modelo de Organización, 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 corrección de los componentes del modelo ha sido
establecida.
= Validado: los componentes del modelo han sido comprobados con criterios (externos) de
validación.
= Completo: el modelo ha sido descrito y validado con respecto a su completitud.
= Descartado: los trabajos adicionales han sido cancelados.
= Aprobado: la especificación de los componentes del modelo ha sido aceptada y aprobada por el
cliente.
- Papel: los estados pueden desempeñar los siguientes papeles (roles):
= Intermedio: empleado sólo para supervisión interna.
= Hito interno (landmark): empleado para revisión en la conclusión de un ciclo de gestión 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 metodología desee definir.
- Dependencias entre estados: representa cómo un estado está relacionado con otros estados.
Pueden darse dependencias internas (entre elementos de un modelo) o externas (entre elementos de
modelos diferentes).
- Métricas de calidad del estado.
En la práctica, se emplean simplificaciones en la definición de un estado:
- Se omite la descripción cuantitativa y declarativa de los estados.
- La designación 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 métricas de calidad, que se deja para futuras investigaciones.
- Los modelos sólo emplean cuatro estados posibles: vacío, identificado, descrito y validado, con el
siguiente significado:
= Vacío: no hay información 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 aún no se ha concretado su significado.
= Descrito: se han descrito los “nombres” previamente identificados.
= Validado: hay una fuerte evidencia de que la información es correcta.
- Se asume una relación de orden entre los valores posibles de un estado: “descrito” requiere
“identificado”, y “validado” requiere “descrito”.
8
9