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

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 INGENIASMESSAGE (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 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

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

TroposEn 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)MaSEMaSE (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 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.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 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 eluso 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 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.PAGE 8