Ingeniería del software orientada a agentes - Presentación

Ingeniería del software orientada a agentes

View more presentations from kasas12.

Ingeniería del software orientada a agentes

Introducción

La Ingeniería del Software ha avanzado considerablemente en la última década imponiéndose un enfoque realista respecto al proceso de desarrollo del software que difiere considerablemente de los modelos de producción industrial. Los modelos de desarrollo secuenciales suponen que, con suficiente estudio y análisis, es posible identificar los requisitos de un sistema antes de comenzar con su diseño e implementación. La experiencia ha demostrado que esta suposición es falsa y que incluso los requisitos de un sistema cambian con el tiempo. El proceso de software, por tanto, debe asumir esta dificultad. Por esta razón, se han ido definiendo nuevos modelos, de carácter evolutivo, donde el sistema se construye a través de una serie de iteraciones, proporcionando incrementalmente nueva funcionalidad al sistema. Para ello es necesario un paradigma que facilite la reutilización, como es el caso de la orientación a objetos, mediante la herencia de clases y composición de objetos.

En el caso de los agentes software, el planteamiento, en este sentido, difiere poco de los modelos orientados a objetos. Casi todas las propuestas metodológicas adaptan un modelo orientado a objetos, en la mayoría de las ocasiones el Proceso Unificado, definiendo algunas actividades específicas para la concepción del sistema de agentes. Recientemente también están apareciendo algunas propuestas para aplicar metodologías ágiles, como la Programación Extrema, en el desarrollo de sistemas basados en agentes.

Metodologías

Para desarrollar sistemas basados en agentes, se requiere de una metodología que apoye los proecesos de desarrollo comunes. Una metodología es un conjunto de guías para cubrir todo el ciclo de desarrollo de un sistema, y debe proveer:

• El ciclo de vida del proceso completo.
• Un conjunto de conceptos y modelos.
• Un conjunto de técnicas.
• Un conjunto de métricas.
• Aseguramiento de la calidad.
• Estándares de codificación.
• Consejos para la reutilización.
• Guías para la administración de proyectos.

Ejemplos de metodologías y notaciones de ingeniería de software oreintada a agentes son:

• Ingenias del grupo GRASIA de la UCM, extie nde la metodología MESSAGE y proporciona un conjunto de herramientas para modelar y generar código de sistemas multiagente.
• MaSe de Scott A. Deloach propone agentes como extensiones de objetos y proporciona la herramienta AgentTool para análisis, diseño e implementación
• GAIA de Michael Wooldridge y Nick Jennings de la Univ. de Southampton, propone cómo realizar un análisis basado en roles del sistema multiagente.
• AgentUML de James Odell, propone una notación, extendiendo UML, para especificar protocolos de comunicación entre agentes.
• …

MaSE

MaSE (Multi-agent systems Software Engineering) se concibe como una abstracción del paradigma oreintado a objetos donde los agentes son especializaciones de objetos. En lugar de simples objetos, con métodos que pueden invoccarse desde otros objetos, los agentes se coordinan unos con otros vía conversaciones y actúan proactivamente para alcanzar metas individuales y del sistema.

En MaSE los agentes son simplemente una abstracción conveniente, que puede o no poseer inteligencia. En este sentido, los componentes inteligentes y no inteligentes se gestionan igualmente entro del mismo armazón. Dado el enfoque incial, los agentes se ven como especializaciones de objetos. De hecho, el sistema se construye sobre tecnología oreintada a objetos y su aplicación a la especificación y diseño de sistemas multi-agente.

El análisis
El análisis en MaSE consta de tres pasos:

• Capturar los objetivos: En esta fase, el analista debe cumplir 2 tareas: identificar y estructurar los objetivos. Primero, a partir de los documentos de requerimientos, se extraen los objetivos principales del sistema, sin tener en cuenta las actividades o desarrollos que llevan hasta estos. Esto se hace así porque los objetivos son lo que menos tiende a cambiar en el tiempo. Después, estos objetivos son analizados y estructurados según su importancia en un diagrama de jerarquía de objetivos. Los subobjetivos son necesarios para la consecución de los objetivos principales. Es importante notar que todos los objetivos son siempre de nivel de sistema. En algunos casos, el analista puede asociar un rol a cada objetivo.
  
  

• Aplicar los casos de uso: Este paso es crucial para convertir objetivos en roles y tareas asociadas. El analista dibuja casos de uso para explicar el comportamiento deseado del sistema. Después, estructura los casos de uso en diagramas de secuencia mostrando la secuencia de eventos entre roles y, como resultado, define la mínima comunicación necesaria entre ellos.
• Refinar roles: El tercer paso en MaSE es para asegurar que hemos identificado todos los roles necesarios y desarrollar las tareas que definen el comportamiento de los mismos y los patrones de comunicación. Se asegura que todos los objetivos son tenidos en cuenta asignando un rol a cada uno, siendo desempeñado este último por al menos un agente en el diseño final. Pese a que, generalmente, cada objetivo es mapeado a un rol individual, existen situaciones en las que conviene asignar más de un objetivo a un mismo rol, por motivos de eficiencia. Este tipo de decisiones son basadas en conceptos clásicos de ingeniería del software como la cohesión funcional, comunicacional, procedural o temporal. También podría ser por distribución de recursos o por cuestiones especiales de las interfaces. Finalmente, los roles son captados en el modelo de roles.

El diseño

• Crear clases de agentes: Las clases de agentes son identificadas a partir de los roles y descritas en el diagrama de clases de agentes. De nuevo, lo más corriente es establecer una correspondencia uno a uno entre roles y clases de agente. Sin embargo, el diseñador puede decidir unificar varios roles en una clase o crear varias clases de un mismo rol. Una vez creado el diagrama de clases, la organización del sistema queda definida. En este punto es bueno fusionar roles que tengan en común un gran volumen de tráfico de mensajes para optimizar el sistema.
• Construir conversaciones: Este paso se encuentra íntimamente ligado con el siguiente (Ensamblaje de agentes). Una conversación MaSE define un protocolo de coordinación entre dos agentes. Específicamente, una conversación consiste en dos diagramas de clases de comunicación, uno para el emisor y otro para el receptor. Un diagrama de clases de comunicación es un par de máquinas de estados finitos que definen una conversación entre dos clases agente participantes.
• Ensamblar clases de agentes: En este paso se crea el interior de los agentes. Este proceso se simplifica usando un lenguaje de modelado arquitectónico que combina la naturaleza abstracta de los lenguajes tradicionales de descripción arquitectónica con el leguaje de restricción de objetos, que permite al diseñador especificar detalles de bajo nivel.
• Diseño del sistema: En esta fase se decide la configuración final del sistema a ser implementado. Hasta ahora en MaSE sólo se consideran sistemas estáticos no móviles. En MaSE se define la arquitectura global del sistema mediante diagramas de despliegue para mostrar el número, tipo y localización de los agentes. En este momento también se toman las decisiones de implementación que no se habían tomado antes, como el lenguaje de programación a usar o el “framework” para las comunicaciones.

Herramientas que soportan MaSE

AgentTool

La herramienta agentTool es el software de soporte que actualmente implementa los siete pasos del proceso MaSE con soporte para transformar modelos de análisis en modelos de diseño. Permite crear de modo visual todos los diagramas del proceso de desarrollo, pudiendo realizar cualquiera de los 7 pasos en el orden que se prefiera (siempre respetando las dependencias entre unos y otros). Además, dispone de una base de conocimiento persistente, un verificador de conversaciones y generación automática de código.

MESSAGE e INGENIAS

MESSAGE

MESSAGE (Methodology for Engineering Systems of Software Agents) es una metodología orientada al desarrollo de sistemas industriales, de media o gran escala. Para ello, MESSAGE se apoya en estándares de la industria como UML y en las “buenas prácticas” de ingeniería del software aceptadas en el momento.

La metodología MESSAGE cubre las fases de Análisis y Diseño y su contribución principal son los conceptos que utiliza, de un nivel de abstracción superior al de las metodologías orientadas a objetos (nivel de conocimiento), y los diagramas para ilustrar estos conceptos en el modelo de análisis, añadidos al UML. MESSAGE integra de forma coherente los conceptos de organización, tarea, rol y objetivo y aporta nuevos diagramas como el diagrama de delegación, de flujo de trabajo o de dominio, y otros similares a los aportados por otras metodologías, como el diagrama de objetivos, tareas o interacciones.

Conceptos y Propiedades

Los conceptos principales en MESSAGE son los siguientes:

• Agente: es una entidad autónoma y atómica, capaz de prestar una función (potencialmente) útil. Esa capacidad funcional se la denomina servicio.
• Rol: es una descripción externa de un agente en un contexto particular. Un agente puede desempeñar varios roles, y un mismo rol puede estar representado por varios agentes.
• Organización: es un grupo de agentes que cooperan y con un propósito común.
• Recursos: son las entidades no autónomas, utilizadas por los agentes. Se describen con los conceptos tradicionales de orientación a objetos.
• Tareas: son la unidad que representa la actividad en el nivel de conocimiento, realizada por un solo realizador principal. Las tareas tienen dos situaciones que describen pre-condiciones y post-condiciones. Además, las tareas se pueden subdividir en subtareas, ejecutadas (posiblemente) por otros realizadores. Como se considera a las tareas como máquinas de estados (StateMachines), se utilizan los diagramas de actividad de UML para describirlas.
• Las interacciones: representan la segunda forma de actividad, junto con las tareas. Las interacciones, por definición, son realizadas por varios participantes y tienen un propósito que todos los participantes persiguen. Un protocolo de interacción (InteractionProtocol).

Otros conceptos importantes en MESSAGE son el concepto de Entidad de Información (InformationEntity), que representa un objeto que encapsula información, y los Mensajes cuyo concepto difiere del utilizado en la orientación a objetos. En orientación a objetos, un mensaje es un enlace causal en una cadena de comportamiento, pues dispara la ejecución de un método en un objeto. En MESSAGE, los mensajes son objetos comunicados entre agentes y tienen un tiempo finito y requieren una tarea en el iniciador y otra tarea en el receptor del mensaje, y sus atributos comprenden emisor, receptor, acto de comunicación, y contenido (entidad de información).

Notaciones y Técnicas

MESSAGE parte de UML como lenguaje de modelado, por su amplia adopción, por ser un lenguaje basado en el lenguaje de meta-modelado MOF, lo que lo hace extensible y por el gran número de herramientas que lo soportan.
MESSAGE extiende los conceptos de UML aportando los nuevos conceptos del paradigma de orientación a agentes, situados en el nivel de conocimiento.
En cuanto a los modelos, la metodología utiliza las siguientes vistas:

• Vista de Organización (OV). Muestra entidades concretas (ConcreteEntities) (Agentes, Organizaciones, Roles, Recursos) en el sistema y su entorno y relaciones de alto nivel entre ellos como agregación, poder, “conocimiento de” (acquaintance).
• Vista de Objetivo/Tarea (GTV). Muestra objetivos, tareas, situaciones y sus dependencias. Los objetivos y las tareas tienen atributos de tipo situación que permiten crear dependencias lógicas, mostrar división de objetivos y tareas, etc. Las dependencias temporales se denotan con la sintaxis de los diagramas de actividad de UML.
• Vista de Agente/Role (AV). Se representan los objetivos del agente, tareas que sabe cómo realizar, recursos que utiliza, eventos a los que atiende, etc. En el siguiente diagrama se muestra un Diagrama de Delegación, además se utilizan Diagramas de Workflow y tablas-esquema.
• Vista de Interacción (IV). Se representa el iniciador, el motivador, los colaboradores, la información relevante comunicada, los eventos que dispara, y efectos relevantes de la interacción.
• Vista de Dominio (DV). Muestra los conceptos importantes del dominio donde se desarrolla el SMA y sus relaciones.

Proceso
El proceso de análisis de MESSAGE consiste en aplicar sucesivamente una estrategia de refinamiento de los modelos del sistema.
El nivel inicial de descomposición del sistema es el nivel 0, que se ocupa de definir el sistema a desarrollar con respecto a las entidades externas (sistemas, usuarios) y entorno. En este nivel se identifican las principales entidades y sus relaciones. El sistema se ve como el conjunto de organizaciones que interactúan con recursos, actores o otras organizaciones. Se construyen las vistas de organización y vista de objetivos/tareas.
En el nivel 1, se estudia la estructura y el comportamiento de entidades como la organización, tareas, objetivos, dominio, etc.
Se pueden añadir más niveles para tratar otros aspectos como requisitos no funcionales, rendimiento, distribución, tolerancia a fallos, seguridad...

INGENIAS
INGENIAS ha sido desarrollada a partir de los resultados obtenidos en MESSAGE. INGENIAS mejora MESSAGE en tres aspectos:

• Integración de las vistas de diseño del s istema.
• Integración de resultados de investigación.
• Integración con el ciclo de vida de desarrollo de software.

La metodología INGENIAS considera cinco puntos de vista para el modelado de un SMA:

1. Agente: describe las responsabilidades con tare as y roles. También considera el control del agente definiendo sus objetivos y los estados mentales que se requieren durante su ejecución.
2. Organización: describe el marco en el que existen los agentes, los recursos, las tareas y el propósito del sistema. Para definir la organización hay que considerar su estructura, relaciones sociales y funcionalidad. La estructura determina la arquitectura del sistema. Se describe en términos de grupos y flujos de trab ajo. Los flujos de trabajo relacionan tareas, los recursos asociados a las mismas y sus responsabilidades.
3. Entorno: define los sensores y actuadore s de los agentes. También identifica los recursos, agentes y aplicaciones existentes con las que tienen que interactuar los agentes.
4. Tareas y Objetivos: este punto de vista está influenciado por el principio de racionalidad y su principal propósito es justificar la ejecución d e tareas en función de los objetivos. También proporciona la descomposición de tareas y objetivos. Para r elacionar ambos, hay relaciones especializadas que determinan la información que es necesaria para considerar que un objetivo se ha satisfecho o no. Finalmente, este punto de vista detalla aspectos de bajo nivel de las tareas, como los recursos que necesitan para su ejecución, los módulos de software que utilizan y sus entradas y salidas.
5. Interacciones: describen cómo se produce l a coordinación entre los agentes. Esta descripción va más allá de los que serían los diagramas de secuencia o colaboración en UML ya que muestran también la motivación de los participantes en la interacción. Para ello incluyen información del estado mental que requieren los agentes en su ejecución, así como las tareas que ejecutarán. Esto permite justificar a nivel de diseño por qué los agentes participan en una interacción y por qué deben continuar.

En la siguiente figura podemos ver los puntos de vista de un SMA en la metodología INGENIAS:

Herramientas que soportan INGENIAS

INGENIAS cuenta con un entorno de desarrollo integrado (IDE) que incorpora una herramienta de especificación y un generador de código.
La herramienta de especificación se ha construído con la herramienta METAEDIT+ que procesa los meta-modelos que define INGENIAS, generando editores particularizados. Se está desarrollando una versión distribuíble de estos meta-modelos.
La generación de código se basa en una sustitución de texto avanzada, contemplando variables, repeticiones y órdenes. Está hecha en Java, aunque es posible en cualquier lenguaje gracias a la utilización de lenguajes de marcado, aplicables a cualquier documento de texto.

La metodología GAIA

GAIA es una metodología para el desarrollo de apli caciones bajo el paradigma de Agentes . Esta metodología se considera adecuada para realizar aplicaciones con las siguientes características:

• Cada agente realiza un uso importante de recursos.
• Son agentes heterogéneos (diferentes tecnolo gías, lenguajes o arquitecturas).
• La organización de la estructura del sistema (las relaciones entre los agentes), así como las habilidades y servicios proveídos por los agentes son estáticos, en el sentido de que no varían en el tiempo.
• El sistema al completo suele contener un número relativamente bajo de tipos de agentes (normalmente menos de 100).

La metodología GAIA considera un sistema basad o en agentes como una sociedad u organización. GAIA pretende ayudar al analista a ir sistemáticamente desde unos requisitos iniciales a un diseño suficientemente detallado, para así poder pasar a la implementación.

La metodología GAIA está orientada principalmente sobre la fase de análisis y diseño de un sistema multi-agente. Las tres fases principales se citan a continuación:

1. Captura de Requisitos
2. Análisis
3. Diseño

Uno de los aspectos más curiosos de GAIA, es el hecho de que la especificación de requerimientos sea completamente independiente del proceso de análisis y diseño del sistema.

Otra cosa bastante interesante es la separación que realiza entre la fase de análisis y la fase de diseño. GAIA separa los conceptos puramente abstractos de la etapa de análisis (que, por lo tanto, no tienen por qué tener una imagen directa de sí mismos sobre la implementación), de lo que son conceptos concretos de la etapa de diseño, o lo que es lo mismo, entidades que tienen un reflejo directo de sí mismas en la implementación del sistema.

Conceptos abstractos (análisis)	Conceptos concretos (diseño)
Roles	Tipos de agentes (clases)
Permisos	Servicios
Responsabilidades	Conocimientos
Protocolos
Actividades
Propiedades dinámicas o vivas
Propiedades de seguridad

Captura de requisitos
Para entender claramente la metodología vamos a explicar dichos conceptos con un ejemplo.El propósito general del sistema será el presentado a continuación:

“Desarrollar una aplicación basada en agentes de software que permita hacer uso de los servicios disponibles en la web 2.0 para la ubicación de talento/búsqueda de trabajo explotando los servicios y bases de datos consolidadas de las redes sociales y la geolocalización “.

Vamos a suponer que la captura de requisitos ya ha sido realizada.

Fase de análisis
El objetivo de GAIA, en la fase de análisis, es conseguir comprender el sistema y su estructura sin referenciar ningún aspecto de implementación. Esto se consigue a través de la idea de organización e interacción. GAIA está basada en el concepto de roles, al igual que MASE, concepto en el que profundizaremos seguidamente.
Una organización consta de una colección de roles. Los roles mantienen ciertas relaciones entre ellos y forman parte de patrones de interacción institucionalizados con otros roles.
Cada rol se define mediante cuatro atributos:

1. Responsabilidades del agente (funcionalidad)

• Propiedades dinámicas: estados positivos que el agente debe alcanzar, dadas ciertas condiciones del entorno (propiedades de disponibilidad).
• Propiedades de seguridad: estados que se pretenden mantener a lo largo de la ejecución (invariantes).

2. Permisos (lectura, escritura y o generación de información, la cuál es requerida para llevar a cabo las responsabilidades): se definirá los recursos que permite utilizar a cada rol.

3. Tareas asociadas (actividades que realiza independiente, sin interactuar con otros agentes).

4. Protocolos: interacciones asociadas que definen el modo en el que se comunican con otros agentes.

GAIA propone realizar el análisis a alto nivel usando dos modelos:

Modelo de roles
El modelo de roles comprende las definiciones de los principales roles que aparecen en el sistema junto con sus propiedades definitorias, entendiendo rol como una descripción abstracta de la función esperada de una determinada entidad:

1. Los permisos/derechos asociados con el rol
2. Las responsabilidades del rol.
3. Tareas asociadas.

Modelo de interacciones
El modelo de interacciones que define las interacciones y dependencias mediante una referencia a un modelo de intercambio de mensajes, como el FIPA-Request. Los protocolos de describen mediante las propiedades siguientes:

1. Objetivo.
2. Iniciador.
3. Receptor.
4. Entradas.
5. Salidas.
6. Procesamiento.

Ejemplo:
Para que esclarecer dichos conceptos de la fase de análisis vamos utilizar el ejemplo anteriormente explicado. Los siguientes pasos de GAIA para la realización del análisis:

1. Identificar los roles en el sistema. Los roles pueden ser individuos, departamentos u organizaciones. El resultado es una lista de roles, cada uno descrito de manera informal.

Una lista de posible roles para el ejemplo:

• Usuario.
• Atendedor.
• Buscador.
• Seleccionador.
• Geolocalizador.
• Calculador de distancias.

Descripción informal del rol Seleccionador:

Rol Seleccionador: es el encargado de determinar cuáles de los candidatos que cumplen con los requisitos de búsqueda para ser presentados al usuario.

• Recibe el listado de candidatos.
• Recibe la cantidad de perfiles requeridos por parte del Usuario.
• Según el criterio de selección del sistema (distancia geográfica para el prototipo actual) y la cantidad de perfiles solicitados determina cuales son los candidatos seleccionados.
• Obtiene la información de distancias geográficas entre candidatos para realizar sus cálculos de selección mediante ayuda por parte de los Calculadores de distancias.

2. Para cada rol, identificar y documentar los protocolos asociados. Esto permite definir el modelo de interacciones.

Una lista posible de protocolos:

• Ubicar candidatos.
• Georreferenciar candidato.
• Seleccionar candidatos.
• Determinar distancia entre dos candidatos.

Definición de un protocolo:

Protocolo	Seleccionar candidatos
Objetivo	Determinar cuáles de los candidatos que cumplen en mayor medida los requisitos y deberán ser mostrados al usuario
Iniciador	Atendedor
Receptor	Seleccionador
Entradas	Lista de candidatos georreferenciados, Cantidad solicitada
Salidas	Listado de candidatos elegidos
Procesamiento	(Breve descripción de todo cálculo que el iniciador realice durante la comunicación)

3. Elaborar el modelo de roles con la información anterior (modelo de interacción).

Esquema de definición de un rol:

Esquema rol	Seleccionador
Descripción	Se encarga de determinar cuáles de los candidatos son los elegidos para ser presentados al Usuario
Actividades	Recibir el listado de candidatos opcionados del Atendedor Determinar según un criterio de selección cuales candidatos son elegidos Calcular la distancia entre dos candidatos mediante utilización del Calculador de distancias Entregar el listado de candidatos elegidos al Atendedor.
Permisos	Reads	Listado de candidatos opcionados Cantidad de perfiles solicitados
	Changes	Ninguno.
	Generates	Listado de candidatos elegidos
Responsabilidades	Dinámicas	Ninguna
	Seguridad	Cantidad de elementos del listado de candidatos opcionados >= cantidad de perfiles elegidos

4. Repetir los pasos 2 y 3 hasta obtener el nivel de detalle deseado.

Fase de diseño
El objetivo de GAIA, en la fase de diseño, es el de transformar los modelos abstractos creados durante el análisis, en modelos con suficiente bajo nivel de abstracción como para poder ser implementados. Se pretende transformar el resultado del análisis en un modelo con el suficiente detalle, como para poder aplicarle técnicas clásicas de diseño orientado a objetos, que nos lleven a una posterior implementación del sistema.
Para llevar a cabo dicha tarea, se generan 3 modelos: modelo de agentes, modelo de servicios y modelo de conocimiento:

1. El modelo de agentes: define los tipos de agente, número de instancias de cada tipo que se creará en tiempo de ejecución y rol.

Los tipos de agentes se crean por agregación de roles. El diseñador empaqueta todos aquellos que guardan relación entre sí. La notación en forma de árbol, permite definir los tipos de manera jerárquica: si un tipo está compuesto por varios subtipos, es que está compuesto por los roles incluidos en cada subtipos. Cada hoja se corresponde con los roles del modelo de roles mientras que el resto de nodos son tipos de agente. La definición de estos tipos tendrá una directa relación con la eficiencia del sistema, ya que marcará su granularidad. El número de instancias de cada tipo de agente que se ejecutarán en el sistema se indica con un intervalo (m…n) encima de la entidad, con * para significar que habrán 0 o más instancias y con + para simbolizar 1 o más instancias.

2. El modelo de servicios: define los servicios del agente asociados a cada rol y las propiedades de los mismos. Un servicio es una función de un agente que se define mediante las siguientes propiedades:

• Entradas
• Salidas
• Pre-condiciones
• Post-condiciones

Cada actividad identificada en la fase de análisis se corresponderá con un servicio, aunque no todos los servicios provendrán necesariamente de actividades. Las entradas y salidas derivarán de forma obvia del modelo de interacción, mientras que pre-condiciones y post-condiciones representan restricciones sobre estos servicios, y son derivadas de las propiedades de seguridad del rol.
La metodología GAIA no incluye una forma de implementar los servicios que documenta. El desarrollador es libre de realizar la implementación como considere apropiado.

3. El modelo de conocimiento (modelo de conocidos): define los flujos de comunicación entre los tipos de agentes. El objetivo concreto de este modelo es la identificación de cuellos de botella en las comunicaciones, lo que podría causar graves problemas en tiempo de ejecución.
Para ello se utiliza la notación de grafos dirigidos, en los que los nodos representan los tipos de agente y los arcos a caminos de comunicación.

Ejemplo:
Para que esclarecer dichos conceptos de la fase de diseño vamos utilizar el ejemplo anteriormente explicado. Los siguientes pasos de GAIA para la realización del diseño son:

1. Crear el modelo de agentes juntando roles en tipos de agente y formando una jerarquía.

Una posible identificación de roles:

• Atendedor -> 1.
• Buscador -> * (una por cada nivel de búsqueda).
• Seleccionador -> 1.
• Geolocalizador -> 1.
• Calculador de distancias -> 1.

Se puede ver como los roles definidos coinciden uno a uno con los agentes encontrados, exceptuando el caso de rol Usuario el cual se fusiona al interior del agente Atendedor.

2. Desarrollar un modelo de servicios examinando las actividades, protocolos y propiedades dinámicas y de seguridad de los roles.

Un modelo se servicios para uno de los roles:

Rol	Seleccionador
Servicio	Determinar los candidatos elegidos
Entradas	Listado de candidatos Cantidad de candidatos requeridos
Salidas	Listado de candidatos
Pre-condiciones	Los candidatos deberán estar georreferenciados Cantidad > 0 Longitud(listado) >= Cantidad
Post-condiciones	Ninguna

3. Desarrollar un modelo de conocidos a partir del modelo de interacción y el de agentes.

Un modelo se servicios para la aplicación de ejemplo sería:

Fase de implementación
A partir de la fase de diseño, GAIA propone aplicar técnicas clásicas de diseño orientado a objetos y que ello se queda fuera de su ámbito. Esta metodología sólo busca especificar cómo una sociedad de agentes colabora para alcanzar los objetivos del sistema, y qué se requiere de cada uno para lograr dichos objetivos.
Por lo tanto nos quedamos en un nivel de abstracción bastante alto. Con ello GAIA pretende conseguir desacoplar GAIA de las distintas soluciones de implementación de agentes pero no se ha demostrado. El nivel de abstracción en que se queda, es de esperar, que el esfuerzo a invertir para pasar de una especificación GAIA hasta su implementación sea alto. GAIA carece de herramientas de soporte para esta metodología, lo cual sorprende bebido al impacto que ha tenido.

Variante de GAIA
Existe una variante, GAIA con Abstracciones Organizacionales. En la fase de análisis, se introducen reglas organizacionales que impactarán en la fase de diseño sobre los modelos de roles e interacciones de la fase de análisis (llamados ahora modelos de roles e interacciones preliminares).En la fase de diseño, se detalla la estructura organizacional, aplicando cuando es posible el uso de patrones organizacionales
La extensión de abstracciones organizacionales facilita la metodología trabajar con sistemas más complejos donde existan reglas organizacionales, como sistemas abiertos en los que es necesario establecer políticas de seguridad y validación, sistemas grandes donde es necesario agrupar los agentes en organizaciones, etc. Además, permite establecer propiedades a nivel de organización, lo que simplifica la arquitectura de sistemas multi-agente, eliminando la necesidad de creación de roles específicos para tratar esta serie de propiedades, habituales en el mundo real que se pretende modelar.

Conclusiones
Como se ha dicho anteriormente, existen muchas metodologías para el desarrollo de sistemas multiagente lo cual nos lleva a preguntarnos cuál es la metodología que debemos utilizar o cuál es la mejor metodología. Las respuestas a estas preguntas no son sencillas ya que cada metodología parte de un concepto distinto de agente y cada una de ellas se especializa en áreas concretas de trabajo.
Por tanto, para escoger una de las metodologías lo que se puede hacer es partir de la propia experiencia del desarrollador, por ejemplo, para desarrolladores acostumbrado al proceso unificado y herramientas de orientación a objetas pueden utilizar la metodología MaSe ya que puede resultar más familiar. Si lo que se quiere es conduicir y razonar el análisis y diseño utilizando los conceptos específicos de los sistemas multiagente la metodología apropiada sería INGENIAS y si lo que se busca es un enfoque más orientado a agente se puede escoger una metodología como GAIA que nos da una visión más superficial del sistema sin entrar en detalles de diseño e implentación.

Bibliografía
Wooldridge M., Jennings N. R., Kinny D.,The Gaia Methodology for Agent-Oriented Analysis and Design. Journal of Autonomous Agents and Multi-Agent Systems, Kluwer Academic Publishers, 2000.

Francisco José Gallego Durán, Faraón Llorens Largo y Ramón Rizo Aldeguer. Breve análisis de algunas metodologías de diseño de SMA, Departamento de Ciencia de la Computación, 2004.

Jorge Iván Meza Martínez. Informe metodología GAIA: “Buscador de talento amigo”, Especialización en Ingeniería de Software .Arquitectura de sistemas multi-agentes. Universidad Autónoma de Manizales,2008.

Zambonelli F., Jennings N. R., Wooldridge M., Organizational Rules as an Abstraction for the Analysis of Multiagent Systems, Intl. Jour. Of SE and KE, Vol 11, No 4., pp. 303-328, April 2001.

Specification and development of reactive systems. A. Pnueli. Information Processing 86, Elsevier Science Publishers B.V.: Amsterdam, the Netherlands, 1986.

Ana Mas,Agentes software y sistemas multiagente. Conceptos, arquitecturas y aplicaciones. Pearson - Prentice hall, 2005.