Requerimientos



Descargar 299,99 Kb.
Página1/2
Fecha de conversión02.05.2017
Tamaño299,99 Kb.
  1   2
Capítulo V

Implementación
  1. Requerimientos


La herramienta de implementación a ser escogida, para el desarrollo del sistema diseñado mediante la aplicación de la metodología al caso de estudio del restaurante, debe cumplir con algunos requerimientos básicos. Dichos requerimientos fueron obtenidos al analizar las principales ventajas que deben ser demostradas gracias a la aplicación de la metodología propuesta. Además de cumplir con la orientación principal de la misma, que es el sentido organizacional del sistema diseñado.

La siguiente es la lista de requerimientos, en donde se explica de manera concisa el por que debe ser cumplido.



  • Manejo de directorios para registrar a los agentes que se han creado en el sistema: Es necesario el manejo de un mecanismo que permita tener un registro de los agentes que existen en el sistema, y por medio del cual se puedan reconocer según su nombre o identificación, y también por la clase de servicio que prestan.

  • Manejo del ciclo de vida de los agentes del sistema: La herramienta debe tener un mecanismo para crear a los agentes, tener un control de sus actividades durante su periodo de vida, y además eliminarlos si es necesario.

  • Ofrezca mecanismos de comunicación entre agentes: El paso de mensajes entre los agentes, es necesario para implementar un SMA en el que se presenten situaciones de interacción y cooperación.

  • Permitir implementación organizacional: El concepto de organización requiere el manejo de formas de interacción, relaciones sociales, y facilidad de cooperación entre los agentes. De esta manera, la herramienta debe tener mecanismos que faciliten la implementación de dichos conceptos, como permitir la implementación de protocolos de interacción, además de los mecanismos de comunicación ya nombrados.

  • Disponibilidad, código libre.

  • Permita el manejo de sistemas distribuidos: Se debe poder hacer una distribución de la aplicación, para que funcione sobre una o más máquinas.

  • Compatibilidad con la metodología desarrollada: La herramienta debe permitir implementar fácilmente los resultados obtenidos mediante la aplicación de la metodología. Es decir, que dichos resultados deben poder ser trasladados fácilmente a los conceptos utilizados para hacer un desarrollo en la herramienta, permitiendo aplicarlos para crear un modelo que represente los artefactos que produce la metodología.

  • Documentación: Deben existir manuales disponibles para el desarrollador.

  • Escalabilidad: Debe permitir que la aplicación crezca según las necesidades del sistema.
  1. Estudio de Herramientas

    1. Herramientas recomendadas


A continuación se hace una breve reseña de algunas de las herramientas existentes para el desarrollo de sistemas orientados a agentes. Las mismas fueron escogidas teniendo en cuenta que cumplieran con algunos de los requerimientos básicos para la implementación de un sistema de agentes, como son la capacidad de construir agentes autónomos y de permitir mecanismos de interacción y de comunicación entre los mismos. La página en la que se realizó la consulta de las herramientas aquí expuestas es www.agentbuilder.com/AgentTools/commercial.php. Otras herramientas pueden ser consultadas en www.csee.umbc.edu/aw.
      1. AgenTalk


AgenTalk es un lenguaje para describir protocolos de coordinación para Sistemas Multiagentes. Permite que los protocolos de coordinación sean definidos de manera incremental y además ser elaborados a la medida para poder acomodarse a cualquier tipo de aplicación, por medio de la incorporación de un mecanismo de herencia. El software está escrito en Common Lisp.

La creación de este lenguaje surgió de la necesidad de manejar el problema de lograr coordinación entre los agentes en un SMA. AgentTalk no pretende ser un lenguaje especificación formal; su objetivo es el de ser un lenguaje de programación capaz de implementar protocolos y el comportamiento de los agentes de acuerdo a dichos protocolos [KEL03].



Políticas de diseño

  • Representación de estados explícitos de un protocolo. El lenguaje actúa como una máquina de estados finitos extendida que permite utilizar variables como base para describir protocolos de coordinación. La representación de esta máquina de estados es llamada script. Usando este modelo, los estados de un protocolo pueden ser definidos de manera explícita, y las acciones de una agente pueden ser definidas fácilmente para cada estado.

  • Definición de un protocolo incremental. Introduciendo un mecanismo de herencia en la definición de un Script, los protocolos pueden ser definidos incrementalmente haciendo extensiones en un script existente.

  • Adaptación fácil de un protocolo. Se define una interfaz de programación, la cual especifica la porción de una regla de transición de estados que posiblemente necesitará ser adaptada para cada agente. Por medio de la utilización de esta interfaz, la estrategia de un agente puede ser descrita.

  • Resolución de conflictos entre procesos de coordinación. Un solo agente puede estar involucrado simultáneamente en varios procesos de negociación (por ejemplo en varios procesos de asignación de tareas), entre los cuales existen algunas interacciones (por ejemplo que los recursos de los agentes deban ser compartidos). Un mecanismo de resolución de conflictos entre procesos de coordinación, puede ser descrito permitiendo que en un agente se ejecuten múltiples scripts, y permitiendo que exista comunicación entre estos scripts.

Modelo de Ejecución

Los agentes son tratados como entidades que pueden enviar y recibir mensajes. La dirección a la cual puede ser enviado un mensaje está especificada por el nombre del agente.

El agente lleva a cabo una acción al recibir un mensaje, y el tipo de acción que efectúa está determinado por un manejador de mensajes, el cual especifica que hacer ante un mensaje determinado. Los mensajes son especificados como patrones de mensajes y las primitivas que definen un tipo de mensaje, además de su manejador asociado son proveídos.

Adicionalmente, un estado en un proceso de coordinación puede ser representado explícitamente. Desde el punto de vista de un manejador de mensajes, el estado define un conjunto de mensajes que pueden ser manejados y la manera en que son manejados. Los manejadores de mensajes pueden ser añadidos y removidos de manera dinámica cuando ocurre la transición de un estado. Un interpretador de scripts actualiza automáticamente los manejadores de mensajes de acuerdo al script.


      1. AgentBuilder


AgentBuilder [AGE03] es una suite de herramientas integradas para construir agentes de software inteligentes. Consiste de dos componentes principales: el Toolkit y el Run-Time System. El AgentBuilder Toolkit contiene herramientas para manejar el proceso de desarrollo de software basado en agentes, analizando el dominio de las operaciones de los agentes, diseñando y desarrollando redes de agentes comunicadores, definiendo comportamientos para agentes individuales, y depurando y probando el software de agentes. El Run-Time System incluye una máquina de agentes que provee un ambiente de ejecución para el software.

Los agentes que se construyen usando AgentBuilder se comunican utilizando KQML y dan soporte a las performativas definidas por este lenguaje. Adicionalmente, AgentBuilder permite al desarrollador definir nuevos comandos de comunicaciones interagentes, que llenan sus necesidades particulares. Todos los componentes del Run-Time System y del Toolkit son implementados en Java. La figura 5.1 muestra los componentes principales del AgentBuilder y la relación que existe entre los mismos.



F
igura 5.1. Principales componentes de AgentBuilder


Herramientas de Control de Proyecto

Estas herramientas son proveídas para ayudar al desarrollador de agentes a manejar todo el proceso de desarrollo. Incluyen el Administrador del Proyecto, el Diccionario del Proyecto, y el Administrador del Repositorio del Proyecto.



Administrador de Ontología

El administrador de ontología da asistencia al desarrollador en analizar el dominio del problema de la aplicación e identificar y definir los conceptos relevantes a la operación de los agentes en ese dominio.



Administrador de agencia

El administrador de agencia esta diseñado para ayudar al administrador a construir una agencia. Una agencia consiste en dos o más agentes que se pueden comunicar y cooperar para ejecutar alguna tarea. Los agentes pueden ser idénticos o especializados para ejecutar diferentes funciones. El administrador de agencia permite al desarrollador identificar y caracterizar a todos los agentes y tipos de agentes en el sistema que se encuentra en desarrollo.

El administrador de agencia provee una ventana de tiempo de ejecución para ver las operaciones del sistema de agentes. De esta manera, el desarrollador puede monitorear las comunicaciones entre agentes, o correr el depurador de agentes para examinar el estado de cada uno de los agentes.

Administrador de agentes

El administrador de agentes provee herramientas para definir un modelo mental inicial y un comportamiento individuales para los agentes. Las herramientas de definición de agentes incluyen editores gráficos para definir las diferentes construcciones mentales que constituyen al agente: creencias iniciales, compromisos iniciales, intenciones iniciales, capacidades y reglas de comportamiento. Adicionalmente, el administrador mantiene herramientas para añadir capacidades de planeación y aprendizaje a un agente.



Planeación y aprendizaje

El toolkit del AgentBuilder provee asistencia para añadir capacidades de aprendizaje y planeación a los agentes. Los editores de aprendizaje y planeación proveen al desarrollador la habilidad de construir módulos de planeación y aprendizaje de dominio específico.



Depurador de agentes

El depurador de agentes provee herramientas de tiempo de ejecución para comunicarse con un agente en ejecución. El depurador provee al desarrollador una salida gráfica que describe el modelo mental del agente, los mensajes entrantes y los salientes. Estas herramientas permiten al desarrollador establecer puntos de detención en el programa y seguir paso a paso la operación de los agentes.


      1. OpenCybele


OpenCybele [OPE03] es un ambiente (open source) construido sobre la plataforma Java(TM)2 para la ejecución y el control de agentes. Bajo esta infraestructura, la ejecución de los agentes es enfocada a los eventos y es controlada por OpenCybele en vez de la maquina virtual de Java. La arquitectura utilizada consiste en varias capas de servicios que facilitan el manejo de los servicios de los agentes por medio de una capacidad de plug-n-play. De este modo, se maneja la concurrencia, los eventos, los hilos de ejecución, las comunicaciones, y los eventos generados internamente. OpenCybele promueve el paradigma de programación centrado en actividades (ACP) para codificar los agentes. Este paradigma impulsa el encapsulamiento del comportamiento autónomo de los agentes como un grupo de actividades. Estas actividades pueden ser codificadas usando las interfaces Orientadas a Actividades (AOPIs) que son parte del kernel de OpenCybele. Otras características que ofrece son: comunicación independiente de la ubicación, mensajes basados en publicadores y subscriptores, sincronía, asincronía, difusión, y mensajes punto-punto.

Características

  • Da soporte a la programación centrada en actividades (ACP). Un agente es un grupo de actividades manejadas por eventos que comparten datos, hilos, y una estructura de ejecución concurrente. Una actividad no es un hilo.

  • La funcionalidad de las actividades es encapsulada. Ningún otro objeto puede invocar sus métodos.

  • Las actividades son manejadas por eventos. Un evento puede ser un mensaje, un reloj, una GUI (Java-AWT & Swing), e interno (dentro de un agente). Un evento no puede ser generado de manera arbitraria por lo tanto, la funcionalidad de las actividades es autónoma.

  • Mensajería basada en publicación-subscripción. Un agente publica y subscribe funcionalidades y mensajes. Los agentes no publican ni subscriben objetos.

  • Soporta mensajería sincrónica, asincrónica, broadcast y P2P entre los agentes.

  • Soporta la mensajería de localización independiente entre los agentes.

  • Las actividades de un agente pueden correr concurrentemente o dependiendo de los demás (bloquearse y esperar). Está es una facilidad brindada por la programación centrada en actividades.

  • Los servicios de los agentes pueden ser Plug-n-play. Esta habilidad es útil para reemplazar un servicio de un agente con otro, con el objetivo de mejorar el rendimiento de una aplicación sin re-escribir el código del agente.

  • Reutilización del código de un agente. El código de un agente escrito por un usuario es re-usable aún si los servicios son modificados.

  • Portabilidad del código de los agentes: El código de un agente escrito por un usuario corre en cualquier configuración Cybele, en la cual al menos una implementación de cada uno de los servicios requeridos por el código del agente se encuentre disponible.

  • Computación de alto rendimiento. Al hacer una prueba con por lo menos 200 agentes corriendo en un solo ambiente de OpenCybele, en el cual cada uno de los agentes tiene una actividad, se generaron eventos de mensajes a una tasa de más de 1200 eventos por segundo.
      1. MadKit


MadKit [MAD03] es una plataforma construida sobre un modelo basado en los conceptos claves de organizaciones multiagentes, como son agentes, grupo y roles. De acuerdo a este modelo, un agente se considera una entidad que se comunica con otros agentes por medio del paso de mensajes, y desempeña roles en grupos. Una organización por su parte, puede ser descrita con base en la manera en que los grupos y roles se organizan para formar un todo, sin poner interés en el modo en que los agentes se comportan, es decir que no interesa su arquitectura interna; el diseño de la misma es escogida por el diseñador de acuerdo a la aplicación. Los SMA son analizados desde afuera como un conjunto de interacciones y actividades entre los roles y los grupos que definen.

El concepto de grupo define una agregación de agentes en un conjunto atómico, el cual etiqueta a los agentes. Si se reúne con el concepto de rol, puede representar cualquier SMA. Entre sus características se tiene que un agente puede ser parte de uno o más grupos, de manera que los grupos se pueden sobreponer. Además, un grupo puede ser fundado por cualquier agente, y un agente puede pedir formar parte de cualquier grupo, sea aceptado o no. Por último, la ubicación de los miembros de un grupo puede ser local o distribuida sobre varías máquinas.

La tercera noción importante, la de rol, conlleva la representación abstracta de una función, servicio o identificación de un agente dentro de un grupo. Cada agente puede desempeñar múltiples roles, y cada rol desempañado por un agente es local a un grupo. El agente debe pedir que se le otorgue el rol que desea dentro de un grupo, y éste le puede ser otorgado o no. Así, el esquema abstracto de comunicaciones puede ser definido para los roles durante el proceso de diseño.

El modelo organizacional facilita el diseño y desarrollo de SMA y permite la construcción dinámica de aplicaciones. Entre los desarrolladores de la plataforma se encuentra Jaques Ferber. La misma está desarrollada en Java y funciona de manera distribuida en varias maquinas (que pueden tener diferentes sistemas operativos) sin necesidad de un servidor central. Los agentes pueden programarse en diferentes lenguajes como Java, Scheme y Jess. Los servicios del sistema y las herramientas de debugging son agentes, de este modo extensiones al sistema son fáciles de implementar. Hasta el momento MadKit no es compatible con FIPA.

MadKit [MAD03] se puede obtener gratuitamente en la página www.madkit.org.

Arquitectura

De acuerdo a su arquitectura, la plataforma MadKit puede ser utilizada donde se requiera, ya que todos los servicios asegurados por su micro-kernel, que ocupa menos de 50 Kb, son manejados por agentes. El diseño de la plataforma se basa en tres principios, descritos a continuación.

Arquitectura de Micro-kernel

El micro-kernel está compuesto por librerías de mensajes, pruebas y agentes. Fue elaborado para desempeñar únicamente las siguientes tareas:



  • Control de grupos y roles locales: Los grupos y los roles son manejados en el nivel más bajo de la plataforma, para que un agente pueda realizar está función. Se mantiene una información correcta acerca de los miembros de un grupo y de los roles que se manejan dentro del mismo, además de revisar que las peticiones hechas a los grupos y a las estructuras de roles sean correctas.

  • Manejo del ciclo de vida de los agentes: El kernel activa, y eventualmente detiene la ejecución de los agentes, además de mantener tablas y referencias a sus instancias. Mantiene también la información personal y del identificador que les asigna en el momento de su creación: el AgentAddress.

  • Paso local de mensajes: El kernel maneja el enrutamiento y distribución de mensajes entre los agentes. El kernel en sí consiste en un agente especial llamado KernelAgent. El control y monitoreo del kernel ocurre dentro del modelo del agente.

El kernel es extensible a través de los hooks del kernel y de las operaciones del kernel. Cualquier agente al que le ha sido otorgado pertenecer al grupo del sistema, le puede pedir al KernelAgent que lo subscriba a un hook del kernel o que le permita invocar operaciones en el kernel.

Los hooks son la extensión genérica del comportamiento clave de la plataforma, que permite subscribir y publicar en el esquema. Cada función clave del kernel (añadir un agente a un grupo, activar un agente, enviar un mensaje) implementa estos mecanismos.

Los hooks de monitoreo permiten a los agentes pedir al KernelAgent, información acerca de las operaciones que se están realizando en el kernel. Cualquier número de agentes se pueden subscribir a un hook de monitoreo.

Los hooks de Intercepción sólo pueden ser poseídos por un agente, sobre una operación del kernel dada. Previenen la ejecución de dicha operación, interceptando la llamada al kernel. Esto es útil por ejemplo, para escribir agentes de mensajería distribuída, o sincronizadores de grupos, cambiando el comportamiento una operación básica.

Por otra parte la extensión mediante operaciones del kernel, puede ser realizada permitiendo que un agente invoque acciones directamente en el kernel, por medio de una interacción con el AgentKernel.

Por último, con respecto al manejo de agentes, roles y grupos, en la plataforma un agente genérico es una clase que define su ciclo de vida completo. Los agentes son desarrollados por medio de la herencia de la clase AbstractAgent. Esta clase define los métodos que identifican a un agente, el manejo de paso de mensajes, y provee el manejo de grupos y roles (creación, unión, peticiones, delegación, etc.).



Agentificación de los servicios y de la distribución

Todos los servicios aparte de los prestados por el kernel, son ejecutados por agentes usando grupos y roles para ejecutar sus propias tareas. Por ejemplo, la comunicación remota es ejecutada por un agente comunicador.

También existe la posibilidad de definir aplicaciones distribuidas sin tener que preocuparse por detalles de bajo nivel como los sockets. No es necesario realizar modificaciones al código para lograr que una aplicación de MadKit sea distribuida. Después de que los principios fundamentales como el uso del modelo AGR (agente, grupo, rol), la mensajeria, la referenciación de los agentes a través de su dirección, son aplicados, se puede hacer de manera directa que la aplicación trabaje sobre varios kernels.

Se maneja además el concepto de comunidad, el cual se viene del concepto de grupos aplicado a los kernels de MadKit.



Modelo gráfico

La interfaz gráfica de MadKit se basa en la especificación de Java Bean. Cada agente es responsable de su propia interfaz en todos los aspectos, y ésta puede ser tan simple o compleja como se quiera.

Un “shell gráfico”, llamado MadKit Desktop, activa el kernel y activa las interfaces de los diferentes agentes para realizar su manejo en una GUI global.

Debido a que las interfaces gráficas de los agentes son desacopladas del kernel, la plataforma puede correr en varios modos (applet, sólo consola, etc.) y el código del agente no necesita ninguna modificación.


      1. JADE


JADE es una plataforma de software para desarrollar aplicaciones de agentes compatibles con las especificaciones de FIPA para interoperabilidad de SMA. El objetivo es simplificar el desarrollo mientras se garantiza la compatibilidad con los estándares. JADE puede considerarse como un middle-ware que implementa una plataforma de desarrollo de agentes. Maneja aspectos tales como transporte de mensajes, codificación y depuración, o el ciclo de vida de los agentes.

JADE ofrece las siguientes características a un programador:



  • Una Plataforma de Agentes compatible con FIPA, la cual incluye el AMS (Agent Management System), el DF (Directory Facilitator), y el ACC (Agent Communication Channel). Estos tres agentes son activados automáticamente en el momento en que la plataforma de agentes es activada.

  • Una plataforma de agentes distribuida, la cual puede ser desplegada en diferentes host (teniendo en cuenta que no exista un firewall entre ellos). En cada uno de los host existe una sola máquina virtual, y además se ejecuta sólo una aplicación. Los agentes son implementados como hilos de java y se utilizan eventos para brindar una comunicación ligera entre los agentes que se encuentran en un mismo host. Las tareas paralelas pueden ser ejecutadas por un mismo agente, para lo cual JADE las organiza de una manera más eficiente de la que la Maquina Virtual de Java lo hace para los hilos.

  • Un número de DFs (Directory Facilitartor) compatibles con FIPA pueden ser iniciados en tiempo de ejecución de manera que se puedan implementar aplicaciones en múltiples dominios. La noción de dominio se encuentra descrita en FIPA97, parte 1.

  • Una interfaz de programación para simplificar el registro de los servicios de los agentes con uno o más dominios.

  • Mecanismos e interfaces de transporte para enviar y recibir mensajes para y de otros agentes.

  • Un protocolo IIOP compatible con FIPA97 para conectarse a diferentes plataformas de agentes.

  • Transporte ligero de mensajes ACL dentro de la misma plataforma de agentes, debido a que los mensajes son transferidos codificados como objetos de Java, más que como cadenas de caracteres, de manera que se pueda evitar llevar a cabo procedimientos de empaquetamiento y desempaquetamiento. Cuando un emisor o un receptor no pertenecen a la misma plataforma, el mensaje es convertido automáticamente a un, o, de un formato de cadena de caracteres compatible con FIPA. De esta manera, la conversión es ocultada a los implementadores, quienes solo tienen que manejar las mismas clases de objetos de Java.

  • Una librería de protocolos de interacción de FIPA listos para ser usados.

  • Registro automático de los agentes con el AMS.

  • Un servicio de nombres compatible con FIPA. Al iniciar los agentes obtienen su GUID (Globally Unique Identifier) de la plataforma.

  • Una interfaz de usuario gráfica para manejar diferentes agentes y plataformas de agentes desde el mismo agente. La actividad de cada plataforma puede ser monitoreada y registrada.
      1. BESA


BESA (Behavior-oriented, Event-driven and Social-based Agent Framework) es una plataforma de desarrollo de sistemas multiagentes [GON03b].

Las principales características generales de la arquitectura son:



  • Se da cumplimiento del estándar FIPA, tomando como base la plataforma JADE. En particular se realiza un manejo de ACL y algunos aspectos propios de FIPA.

  • El lenguaje de programación es Java con el fin de aprovechar la portabilidad del mismo.

  • Un agente se implementa por un canal y un conjunto de comportamientos. Debe existir al menos un comportamiento. El canal y cada uno de los comportamientos corresponden a un hilo. Todos los hilos de un agente corren en una misma máquina virtual.

  • Cada agente incluye un canal, el cual es un hilo que se encarga de cumplir la función de interface con otros agentes. Este hilo recibe los eventos y tiene a su cargo el manejo del mecanismo de guardas, lo cual incluye el enrutamiento de eventos hacia los comportamientos interesados.

  • El agente recibe los eventos a través de un buzón, el cuál es bloqueante para el canal cuando no hay ningún evento recibido en el mismo. La mayoría de los eventos provienen desde el exterior del agente, es decir de otros agentes; sin embargo, también existen algunos eventos internos que provienen de los comportamientos del agente. Estos eventos internos permiten realizar sincronizaciones controladas de los comportamientos; gracias a estos eventos internos, el canal puede manejar un mecanismo de sincronización que sirva de soporte a la movilidad del agente y a apoyar la gestión de los mecanismos de cooperación del nivel organizacional.

  • La conducta de un agente se implementa/programa por un conjunto de comportamientos, los hilos asociados son manejados en forma expropiativa directamente por el sistema operativo. Estos hilos corren sobre la misma máquina y la comunicación entre los mismos se realiza en forma controlada con un mecanismo basado en memoria compartida con exclusión mutua. Los eventos, que llegan a un comportamiento, son ubicados en una cola prioritaria. Únicamente los eventos internos que se generan en forma controlada por la arquitectura pueden tener prioridades altas. Con el fin de prevenir problemas de inanición, todos los mensajes que no son producidos para el manejo interno de la plataforma tienen la prioridad más baja.

  • Un comportamiento está encargado de realizar el procesamiento adecuado para un conjunto bien definido de eventos, los cuales, dada la naturaleza concurrente del sistema, ocurren en forma no determinista. Para poder manejar apropiadamente este alto paralelismo, cada comportamiento estructura su funcionamiento en el mecanismo de select.

  • Un select está constituido por un conjunto de guardas, cada una de las cuales está asociada a un evento. Adicionalmente, una guarda posee una condición, que permite regular/controlar el paso de los eventos desde el canal hacia el comportamiento. Los eventos se distribuyen a los comportamientos interesados únicamente en el momento en que la guarda asociada se dispara, es decir si el evento ha ocurrido y la condición de la guarda se cumple.

  • A cada guarda se le asocia el concepto de puerto, a través del cual se maneja el almacenamiento de los mensajes asociados a la guarda y la distribución de los mismos hacia los comportamientos interesados en el evento asociado a la guarda.

  • Para el manejo de la condición de una guarda, a cada una se le asocian un objeto y una función de evaluación. El objeto encapsula todas las informaciones que se requieren para poder evaluar si la condición se cumple. La función toma como parámetro el objeto y retorna verdadero si la condición se cumple. Se debe incluir un mecanismo que asegure que cuando el objeto cambia de valor se verifique si la guarda o guardas asociadas se disparan.

  • Una guarda debe ser verificada, es decir validar si se dispara, cada vez que ocurre el evento asociado o se modifica el objeto de evaluación de la condición asociada. En el disparo de una guarda solo se transfiere el primer evento en cola y se espera que el tratamiento del mismo haya concluido antes de volver a verificar la guarda.

  • Los agentes podrán organizarse en estructuras jerárquicas dinámicas, es decir que un agente puede cambiar su posición en la jerarquía cuando el sistema está en operación. No se requiere que todos los agentes que están bajo un nodo de la jerarquía se encuentren en la misma máquina. El uso de este concepto de organización es optativo al programador, por lo tanto debe ser posible diseñar un SMA completamente plano, en el que todos los agentes están al mismo nivel y asumen la responsabilidad total del manejo de sus interacciones.

  • El registro de un agente asciende a través de la jerarquía, dando la posibilidad a los agentes de niveles superiores de redireccionar los mensajes de un agente hacia ellos. Esta característica busca facilitar la implantación del concepto de “pool” de agentes similares administrados por un agente de nivel superior y otros mecanismos de control y gestión de nivel organizacional.

  • Un agente de nivel superior debe prestar servicios que faciliten el envío de mensajes a grupos bien definidos de agentes del nivel inmediatamente inferior, con lo cual se pueden implantar mecanismos de traducción de mensajes y de distribución de mensajes muy flexibles.

  • Un agente de nivel superior debe prestar servicios que faciliten la coordinación de agentes ejecutando planes cooperativos a través del manejo de eventos de activación e inhibición de la actividad de los agentes involucrados. Estos mecanismos permiten además el manejo controlado de acceso a recursos y la implantación de protocolos para el manejo de conflictos entre agentes.

  • El diseño de la arquitectura se divide en tres niveles. Esta división en niveles facilita el entendimiento y manejo de la abstracción, sin embargo no hay que olvidar que estos se subsumen mutuamente; la organización y funcionamiento de un nivel está íntimamente ligada con la de los otros.

    • Nivel intra-agente, en el cual se define como se estructura un agente internamente.

    • Nivel organizacional, en el cual se define la estructuración y funcionamiento de las jerarquías de la organización, así como también el soporte de mecanismos facilitadores de la cooperación.

    • Nivel sistema, en el cual se definen los mecanismos globales de registro, comunicación e interacción entre agentes, así como también la forma en que agentes/clientes externos pueden interactuar con los agentes del sistema.

La implementación de la arquitectura en este momento se ha realizado hasta el primer nivel.
  1   2


La base de datos está protegida por derechos de autor ©absta.info 2016
enviar mensaje

    Página principal