1

3. METODOLOGÍAS POA

La construcción de un Sistema MultiAgente (SMA), implica una visión diferente en términos del proceso de desarrollo de software requerido para su implementación. Este debe incluir y tener en cuenta las características intrínsecas de los agentes, un conjunto de entidades autónomas cooperativas. Estas características permiten la resolución de problemas complejos, e implican además la creación o adecuación de metodologías para el desarrollo de sistemas basados en agentes, denominadas de manera genérica Programación Orientada a Agentes (POA). Estas metodologías deben incorporar actividades y artefactos que permitan identificar y asociar las características esperadas tanto de los agentes como de sus relaciones sociales, así como de la arquitectura y estructura interna del SMA.

La POA, ha venido tomando fuerza como nuevo paradigma para el desarrollo de aplicaciones de software complejas, donde el enfoque orientado a objetos no ofrece un solución que se adapte al continuo cambio de los procesos dentro de una organización o cuando no se presenta un comportamiento autónomo que permita resolver problemas con mayor facilidad, dando como resultado mayor supervisión humana. De acuerdo con Zambonelli [ZAMB2003], las actuales aplicaciones de software están tendiendo a ser más complejas, manejando aspectos como el uso de recursos de manera distribuida, manteniendo altos estándares de disponibilidad y manejo de concurrencia, buscando la manera de ser más autónomas y reconfigurables en los ambientes donde se hayan desplegado, adaptándose a de los cambios que se puedan presentar en tiempo real.

Aunque los desarrollos contemporáneos basados en el paradigma orientado a objetos pueden llegar a satisfacer las necesidades actuales de estas aplicaciones, los SMA se perfilan como la opción ideal para desarrollar nuevos sistemas basándose en POA y superando en varios aspectos a las aplicaciones desarrolladas con otros paradigmas. Por ejemplo, la autonomía de las entidades (agentes), que conforman los SMA, forman grupo y actúan proactivamente con el fin de satisfacer sus propias metas y las de todo el SMA; al conformarse en sociedades son capaces de interactuar no solamente con otros agentes, sino también con recursos externos a ellos de forma concurrente, manejando los conflictos, distribuyendo tareas y percibiendo el ambiente donde se enmarcan los SMA.

Sin embargo, sólo existe una limitante para que la POA y los SMA lleguen a ser tan utilizados como el paradigma orientado a objetos y básicamente se debe a que la POA no es tan conocida y utilizada por la comunidad desarrolladora de software. El paradigma orientado a objetos ha sido desarrollado desde hace muchos años y ha tenido mucha aceptación entre diseñadores y desarrolladores de software, muchas herramientas, lenguajes de programación y metodologías han sido desarrolladas, las cuales han impulsado la popularización de éste paradigma. Según Mouratidis, para que los SMA empiecen a tener una mayor aceptación y uso dentro de la comunidad diseñadora y desarrolladora de software “es necesario que se desarrollen técnicas de ingeniería de software que sean enfocadas especialmente hacia ellos” [MOUR2003].

Dentro del desarrollo de este capítulo, para motivar aún más el aprendizaje y popularización de POA y los SMA, se resaltarán las principales características de las metodologías para SMA y su relación con la disciplina de la ingeniería de software.

2

Posteriormente, se describirán los tipos de metodologías para desarrollar SMA y finalmente se introducirán las metodologías más importantes en el contexto de los SMA.

3.1. Características Generales de las Metodologías para Desarrollar SMA

Una metodología de construcción de software se caracteriza por proporcionar una serie de actividades y artefactos usados y/o generados dentro del proceso de desarrollo, con el fin de producir un producto de software que cumpla con los requerimientos del usuario, así como con ciertas características de calidad que permitan la mantenibilidad y soporte de un sistema durante su etapa de operación. Las actividades describen el proceso a llevar a cabo para construir uno o más artefactos que pueden ser: documentos, diagramas, modelos, programas, planes, etc. Éstos soportarán otras actividades del proceso de desarrollo o simplemente permitirán la supervisión y seguimiento del proceso. Una metodología ayuda entonces al desarrollo de un sistema por medio de:

- La guía a través de un proceso de ciclo de vida, actividades y secuencia de las mismas.

- El conjunto de técnicas predefinidas, lineamientos, heurísticas, etc.

- El modelado del problema a través de una notación formal.

Diseñar sistemas complejos no es una tarea fácil, los SMA son una de las principales soluciones para realizar esta labor. Sin embargo, para desarrollar aplicaciones basadas en agentes, es necesario también desarrollar métodos prácticos, que permitan establecer los pasos necesarios para definir correctamente un SMA.

La importancia de las metodologías para el diseño de SMA, radica en la definición formal de cada una de las actividades que se deben llevar a cabo dentro de un proceso metodológico y que permiten la difusión del paradigma POA. A continuación se introducen los principales lineamientos que se deben tener en cuenta en una metodología para desarrollar un SMA, así como también se resalta la relación con la ingeniería de software y se presenta un vistazo a los principales problemas que surgen en el momento de modelar un SMA.

Lineamientos de las Metodologías para SMA

Según Alonso [ALON2004], una buena metodología para el desarrollo de SMA debe definir un modelo genérico de análisis independiente de la plataforma, y un modelo de diseño que permita identificar los agentes de forma sistemática, siguiendo un proceso orientado por componentes que pueda identificar la estructura interna de los agentes y la estructura social de los mismos incluyendo el entorno y los objetos contenidos en él. Claramente al mencionar el aspecto de independencia de plataforma es relevante mencionar que en la actualidad la mayoría de las implementaciones de SMA son realizadas usando tecnologías orientadas a objetos por medio del uso de plataformas superpuestas al lenguaje, proporcionando un nivel de abstracción hacia el SMA que resulta en una mayor facilidad para la implementación y comprensión por parte de los desarrolladores.

Otros autores como Sudeikat [SUDE2004], proponen que en el momento de evaluar metodologías orientadas a agentes se debe tener en cuenta la plataforma en la cual se hará la implementación, en contra posición con Alonso [ALON2004], puesto que dicha plataforma implica restricciones adicionales que deben ser tenidas en cuenta en el análisis y diseño del SMA. Por esta razón Sudeikat, presenta una estrategia que permite interrelacionar a las metodologías con las plataformas, mediante la evaluación de ciertos

3

criterios tanto de las plataformas como de las metodologías, que simplifican este proceso de clasificación.

En la actualidad existen varias metodologías de desarrollo orientadas a agentes, sin embargo, no proporcionan los mecanismos apropiados para formular un proceso natural para desarrollar un SMA o sociedades de agentes a partir de los requerimientos iniciales del sistema. De acuerdo lo anterior una metodología de desarrollo orientada a agentes debería poseer las siguientes características:

- No se debería forzar a la utilización de una metodología basada en el paradigma de los agentes desde la fase de análisis.

- Debería llevar naturalmente a la conclusión de si es factible o no solucionar un problema con el paradigma POA.

- Debería identificar sistemáticamente los componentes del SMA.

- Si el problema requiere una sociedad de agentes, debería guiar de manera natural al uso de un modelo organizacional.

- Debería producir agentes reutilizables, ser de fácil aplicación y no requerir conocimientos muy avanzados en agentes.

En cuanto a metodologías Sudeikat [SUDE2004] define los siguientes criterios, que complementan las cinco características fundamentales que se introdujeron anteriormente:

- Facilidad de uso – notación intuitiva y comprensible, fácil de dibujar.

- Expresiva – que soporte muchas vistas del sistema a desarrollar.

- Refinamiento – constante mejora en el proceso.

- Dependencia de los modelos – Para soportar trazabilidad y diferentes niveles de detalle.

- Trazabilidad – seguimiento de los artefactos generados a lo largo del proceso de desarrollo, así como la identificación de relaciones entre los mismos.

- Definición clara – la semántica y sintaxis de un lenguaje de formalización y de las características de la metodología en cuanto a los conceptos que ésta utilice, por ejemplo, agentes, metas, roles, tareas, habilidades, grupos, etc.

- Modularidad – por partes funcionales, relacionadas entre sí coherentemente.

- Cubrimiento del ciclo de vida de software – deseable que abarque todas las 5 etapas fundamentales (requerimientos, análisis, diseño, implementación y pruebas).

- Administrable – administración de un proyecto de software orientado a agentes con heurísticas y lineamientos.

- Complejidad – la complejidad del proceso mide el esfuerzo necesario para aprender a usar la metodología.

- Enfoque del proceso – definición si tiene un enfoque iterativo, lineal, top-down, botom-up, etc.

- Soporte a herramientas – como por ejemplo herramientas CASE o de diagramación para la metodología.

- Documentación – tanto de la metodología, como de los artefactos y herramientas asociadas, tiene un gran impacto en el uso y apropiación de la metodología.

4

- Uso en proyectos – para juzgar la madurez de la metodología.

Otro criterio que no se considera en el trabajo de Sudeikat [SUDE2004], pero es válido para integrar tanto a las metodologías como a las plataformas es el de la seguridad. Algunos elementos asociados a dicho criterio son:

- Aplicación de patrones de seguridad.

- Modelo de la seguridad integrada a la metodología o a la plataforma.

- Pruebas de seguridad que puedan ser fácilmente definidas en el momento del diseño y la implementación.

- Relaciones de confianza y dependencias, posesión de recursos y derechos sobre recursos.

UML y Extensiones

En general, cuando se habla de enfoques y metodologías, es necesario el uso de algún tipo de notación gráfica que permita representar vistas y modelos generados durante las etapas de análisis y diseño. Algunas de estas metodologías orientadas a agentes usan UML, Unified Modeling Language, en dos frentes de trabajo: Los que pretenden utilizar UML sin modificaciones para modelar SMA, y los que proponen extensiones y modificaciones al meta modelo UML con el fin de lograr mayor flexibilidad y precisión en el modelo.

En el primer frente se encuentra la propuesta de Bauer y Odell [BAUE2005], que se apoya en el amplio reconocimiento del estándar UML para proponer su utilización en el campo de los agentes, fundamentando que de esta manera la transición del diseño orientado a objetos al diseño orientado a agentes será mucho más fácil.

Torres [TORR2004], propone una extensión a UML llamada MAS-ML basada en el framework TAO (Taming Agents and Objects). Las extensiones son puramente de adición, y no modifican UML. Con este fin, se crean nuevas metaclases para definir agentes, organizaciones, ambientes y roles. No se utilizan estereotipos1, pues los elementos que se adicionan son fundamentalmente diferentes a los objetos. MAS-ML modifica también los diagramas de clase para representar las relaciones entre agentes, entre agentes y clases y entre ambientes con ambientes y clases. Otros diagramas estáticos incluyen el de Organización y el de Roles. En el terreno de los diagramas dinámicos, el diagrama de secuencia es modificado. Por último, MAS-ML tiene asociada la herramienta MAS-ML2Java para transformar los diagramas y generarlos en código Java. La herramienta fue creada utilizando el lenguaje TXL.

También se han propuesto lenguajes formales para la estandarización como AUML [ODEL2004a], derivado de UML o los estándares propuestos por FIPA, como por ejemplo los especificados para la interacción entre agentes ACL, Agent Communication Language. Muchas de las metodologías desarrollan herramientas alternas como plataformas o herramientas CASE que ayudan a popularizar el uso de éstas para el diseño de SMA y proporcionan una base más sólida soportándose en los lineamientos propuestos por la ingeniería de software.

En general, UML y sus extensiones ofrecen recursos exclusivamente representacionales, que no ofrecen mecanismos para el análisis y diseño de SMA.

Problemas en el Modelado de un SMA

1 Un tipo de dato definido para modelar características de datos de objetos del mundo real.

5

En general, una metodología de desarrollo de SMA, debería, además de tener en cuenta el entorno, proporcionar bases sólidas para las fases de análisis, diseño e implementación, indicando como los conceptos de diseño deben ser llevados a las órdenes de un lenguaje determinado. En este orden de ideas Dastani, et.al. [DAST2004], identifica algunos tópicos que suelen ser problemáticos con las metodologías existentes:

1. No existe un acuerdo en la forma en que se deben identificar y caracterizar los roles en la fase de análisis y los tipos de agentes en la fase de diseño.

2. Los conceptos utilizados en las diferentes metodologías, como responsabilidad, permisos, metas y tareas, no tienen una semántica formal o propiedades formales explícitas.

3. Existe una brecha entre los modelos de diseño y los lenguajes de desarrollo existentes. Para reducir esta brecha, una metodología debe incluir refinamientos en los modelos de diseño de modo que puedan ser implementados de forma directa en algún lenguaje de programación disponible.

4. Las metodologías que incluyen una fase de implementación como Tropos[BRES2004][GIUN2002], proponen un lenguaje de implementación en el cual no se explica como implementar el razonamiento acerca de las creencias, metas, planes y comunicación.

5. Un agente puede representar diferentes roles. En ninguna de las metodologías se tiene en cuenta este hecho.

6. En general, las metodologías ignoran las normas organizacionales y no explican como especificarlas y diseñarlas.

7. Los sistemas abiertos no son realmente soportados. Durante el análisis, diseño e implementación, las entidades deben ser preconcebidas.

3.2. Tipos de Metodologías

Existen muchas metodologías, todas ellas se enmarcan dentro del ciclo de vida del software, la mayoría de ellas abarcan las fases de análisis y diseño, otras se extienden hasta las etapas de implementación y verificación o trabajan en conjunto con alguna plataforma desarrollada propiamente para la metodología o con otras más genéricas. La mayoría de metodologías, proponen una serie de artefactos que formalizan el diseño de los SMA, incluyendo diagramas y entregables que definen correctamente cada una de las etapas que se incluyan en el proceso.

Según Dastani [DAST2004], las metodologías para el desarrollo de SMA deberían ayudar al desarrollador en la toma de decisiones sobre aquellos aspectos del análisis, diseño e implementación que son cruciales para un SMA. Hoy en día, existe un gran número de estas metodologías, las cuales difieren en muchos aspectos como por ejemplo: en las fases de desarrollo que utilizan y cómo las utilizan, otras se enfocan en aspectos de comunicación entre agentes, mientras que otras lo hacen en el comportamiento interno de cada agente; otras tienen además en cuenta el entorno.

Alonso [ALON2004] propone una taxonomía para organizar dichas metodologías en tres categorías: metodologías basadas en agentes; metodologías basadas en el paradigma de orientación a objetos y finalmente metodologías basadas en el paradigma de la ingeniería del conocimiento.

En las siguientes subsecciones se explica brevemente esta clasificación de las metodologías para SMA y se enuncian algunas de las metodologías más importantes que

6

pertenecen a cada una de las clasificaciones. Posteriormente, a partir de la sección 3.3, se introducen brevemente las metodologías más representativas de los SMA, concentrándose principalmente en el proceso metodológico que cada una de ellas describe.

Metodologías basadas en agentes

Estas metodologías se basan en la abstracción de niveles sociales como grupos u organizaciones y que han ganando bastante terreno en el campo de la especificación de SMA, sin embargo, tienen algunas características:

- Estas metodologías proponen la utilización del paradigma de agentes para las fases de especificación y diseño, pero la mayoría no tienen en cuenta la utilización de un modelo de análisis genérico que pueda ser utilizado para evaluar si una aproximación basada en agentes es adecuada o no.

- Las metodologías identifican los agentes a partir de roles sociales o de actores siguiendo un enfoque “top-down”.

- Hay tres aspectos que son especificados por las diferentes metodologías:

1. Estructura interna de los agentes

2. Estructura Intra-agentes

3. Estructura social y

4. Estructura del ambiente

Dentro de este grupo Alonso [ALON2004] clasifica las siguientes metodologías: Prometheus, Tropos, SODA, Styx, Gaia, HLIM, Casiopea, entre otras.

Metodologías Basadas en Ingeniería de Software Orientada a Objetos

En las metodologías orientadas a objetos, los agentes son tratados como objetos complejos, lo cual no es del todo correcto. En efecto, aunque los agentes tienen un nivel de abstracción mayor, y además, fallan al no plantear claramente el comportamiento autónomo de los agentes, sus interacciones y las estructuras organizacionales.

Estas metodologías se caracterizan por extender el paradigma del análisis y diseño orientado a objetos. Desde el punto de vista del diseño de SMA, estas metodologías tienen algunos problemas recurrentes como: no tener en cuenta un modelo genérico de análisis, sólo algunas identifican agentes durante el análisis, no cubrir los aspectos referentes a la estructura social del sistema y no tener en cuenta las características del ambiente. Visto de una forma más general, estas metodologías tratan a los agentes como objetos complejos, reduciendo el nivel de abstracción real que tienen los agentes.

Dentro de este grupo Alonso [ALON2004] clasifica las siguientes metodologías: ODAC, MaSE, MASSIVE, DESIRE, AAII, AOMEM, AOAD, MASB.

Metodologías Basadas en Ingeniería del Conocimiento

Estas metodologías se caracterizan por el énfasis en la identificación, adquisición y modelado del conocimiento utilizado por los agentes. Las metodologías más representativas son extensiones de la metodología de desarrollo de sistemas basados en conocimiento CommonKADS [SCHR1999]. Dentro de este grupo Alonso [ALON2004] y Sudeikat [SUDE2004] clasifican las siguientes metodologías: MAS-CommonKADS y CoMoMAS.

7

En general, las metodologías que utilizan directamente la tecnología de agentes pueden ser mejores que las otras dos, debido a que se basan en los conceptos de agentes y de organización de agentes en un SMA, aunque tienden a confinar cualquier problema a este paradigma, aún si este no es apropiado para resolverlo.

3.3. Metodología Tropos

Tropos es una metodología para construir sistemas de software orientados a agentes describiendo el sistema y el ambiente organizacional. Es un trabajo realizado por Paolo Giorgini, Fausto Guinchiglia y ha sido ampliamente descrita en los trabajos de Bresciani [BRES2004] y Giunchiglia [GIUN2002]. Desarrollado en Italia y en Canadá, Tropos es una de las metodologías que más impacto ha tenido en el área de los SMA y ha sido desarrollada desde mediados de los años 90s, donde se ha venido refinando y ampliando su formalismo y extensión en las etapas de ingeniería de software.

La metodología adopta el framework de modelado i* propuesto por Eric Yu, descrito en [YU1997], el cual utiliza conceptos tales como actor – agentes (social, organizacional, humanos o software), posiciones – roles, metas y dependencias sociales – metas suaves, tareas y recursos, para definir las obligaciones de los actores (dependees) con otros actores (dependers).

Tropos se basa en dos conceptos fundamentales, el primero es la noción de agente y todo lo relacionada con las nociones mentales (por ejemplo metas y planes), que son usadas durante todas las fases del desarrollo de software. El segundo es que Tropos cubre las fases de requerimientos tempranos, un entendimiento profundo del ambiente donde el software debe operar y las interacciones que se presentan entre agentes de software y humanos [BRES2004]. Por estas razones Tropos es una de las metodologías que mejor explica los conceptos relacionados a los SMA como son actor, meta, dependencia, plan, recurso, capacidad y creencia.

Como metodología Tropos se encuentra bien estructurada y define claramente diagramas que permiten diseñar un SMA de forma didáctica. Parte de una visión de los actores (incluyendo a los stakeholders) y el ambiente, hasta llegar a un nivel de granularidad que incluye el mapeo de los actores a agentes y la definición de capacidades para cumplir las metas. Las interacciones son identificadas desde las primeras fases de la metodología, lo cual implica que se debe tener un análisis exhaustivo de los requerimientos.

Etapas de la Metodología Tropos

La metodología Tropos tiene cuatro etapas denominadas: requerimientos tempranos y tardíos, diseño arquitectónico y diseño detallado, que fueron las descritas en los trabajos de Mouratidis [MOUR2002], [MOUR2003]; sin embargo, en los trabajos más recientes de Bresciani [BRES2004] y Giunchiglia [GIUN2002], se adiciono una quinta fase llamada implementación.

- Análisis de Requerimientos Tempranos y Tardíos: el principal objetivo en esta etapa es proporcionar un conjunto de requerimientos funcionales y no-funcionales para el sistema. La diferencia entre estos análisis de requerimientos radica en que en la etapa de requerimientos tempranos, el diseñador modela el sistema de forma general incluyendo a los stakeholders2 principales y estableciendo las primeras dependencias. Mientras que en la etapa de requerimientos tardíos, el diseñador modela el sistema como tal integrando a todos los actores y especificando sus dependencias.

2 Stakeholders se refiere a todas las personas involucradas en un proyecto de software [IEEE2004].

8

- Diseño Arquitectónico: en esta etapa se define la arquitectura global del sistema en términos de los actores y sus interconexiones, dependencias, mediante datos y controles de flujo. En esta etapa se relacionan los actores identificados a agentes de software caracterizando sus capacidades.

- Diseño Detallado: durante la etapa de diseño detallado el desarrollador especifica en detalle los agentes, sus metas, creencias y capacidades así como también la comunicación entre ellos.

- Implementación: finalmente en la etapa de implementación, todos los artefactos producidos en la etapa de diseño detallado son transformados en el esqueleto de la implementación y se hace mediante un mapeo de lo construido por la metodología a una plataforma de agentes.

Dentro de las cinco etapas establecidas, Tropos entrega modelos que sirven para definir el SMA, estos modelos son definidos desde la etapa de análisis temprano de requerimientos y se van refinando a medida que se va avanzando en las demás etapas de la metodología. Los modelos que se definen son los siguientes y pueden ser encontrados en el trabajo de Bresciani [BRES2004]:

- Modelo de Actores: se caracteriza por identificar y analizar a los actores del ambiente y a los actores del sistema y los agentes; éste se encuentra presente en las 5 etapas de la metodología.

- Modelo de Dependencias: incluye la identificación de los actores que dependen de otros para completar las metas, los planes que se desarrollan y los recursos utilizados; éste abarca las tres primeras etapas y proporciona la base para el modelado de capacidades.

- Modelado de Metas: construido a partir del análisis de las metas de los actores, usando tres técnicas de razonamiento: means-end analysis, contribution analysis y AND/OR decomposition. El primero identifica planes, recursos y metas suaves que proporcionan los medios para satisfacer una meta. El segundo identifica las metas que contribuyen positiva o negativamente a la terminación satisfactoria de una meta por analizar. El tercero descompone una meta raíz en otras metas aplicando predicados AND/OR.

- Modelado de Planes: permite incorporar una técnica adicional a las propuestas en el modelado de metas; es similar en cuanto a las técnicas de razonamiento propuestas anteriormente.

- Modelado de Capacidades: se construye al final de la etapa de diseño arquitectónico, cuando los subactores del sistema han sido especificados en términos de sus propias metas y dependencias con otros actores.

La metodología Tropos ha definido también un metamodelo que resume la concepción de la metodología y que se puede observar en las Figura 3-1 y Figura 3-2. Este modelo es inspirado de los diagramas de clases del lenguaje UML y representa las relaciones entre todos los conceptos de la metodología.

9

Figura 3-1. Actor en el metamodelo de Tropos, adaptado de [BRES2004].

10

Figura 3-2. Metas en el metamodelo de Tropos, adaptado de [BRES2004].

Extensiones a la Metodología Tropos

Otros autores también han propuesto extensiones a la metodología Tropos, como por ejemplo la descripción de un lenguaje para la formalización de los requerimientos tempranos llamado Formal Tropos, propuesto por Fuxman [FUXM2001], [FUXM2003], el cual está basado en el modelo i* de Eric YU [YU1997]. El principal objetivo de esta formalización es encontrar brechas e inconsistencias en los requerimientos tempranos que evitan problemas en etapas posteriores de la metodología.

En cuanto al diseño de SMA con un enfoque organizacional, Penserini [PENS2004], propone utilizar patrones de diseño sociales que sean capaces de modelar la organización de un SMA. Éstos son similares a los patrones de diseño que se pueden aplicar para diseñar un sistema con el paradigma orientado a objetos. El trabajo de Penserini, se basa en un ejemplo de la cadena de valor de las industrias. La idea es conocer cuáles son las conductas sociales de todos los involucrados dentro del proceso de transformación de las materias primas a productos, luego de analizar dichas conductas aplicar Patrones de Diseño Sociales que puedan representar la organización del mundo real en un SMA. Sin embargo, siempre se debe tener en cuenta que muchas veces las estructuras organizacionales del mundo real no son necesariamente las más adecuadas y si no se realiza un estudio riguroso se podría estar llevando procesos ineficientes a un SMA. Para no cometer esos errores se puede complementar el estudio con aproximaciones organizacionales heredadas de la teoría administrativa.

Otro de las extensiones más representativas de la metodología Tropos se ha realizado es en el área de seguridad, requerimiento que casi no es tenido en cuenta por las

11

metodologías para diseñar SMA. En los trabajos de Mouratidis [MOUR2002], [MOUR2003], [MOUR2004] y Giorgini [GIOR2004], se aprecia claramente que aunque Tropos no fue desarrollada considerando conceptos de seguridad, los esfuerzos de los autores se han encaminado al modelado de los requerimientos de seguridad en cualquier problema que se pueda solucionar con un SMA. Para ello, Mouratidis ha definido Secure Tropos como la extensión de la metodología Tropos que maneja los requerimientos de seguridad; la aproximación considera los problemas de seguridad a través de proceso de desarrollo. En estos trabajos se propone ver a la seguridad, requerimiento no-funcional, como un requerimiento funcional y no dejarlo como una actividad final, porque muchas veces se termina acomodando todo un sistema a la seguridad o simplemente no se hace.

Mouratidis básicamente ha utilizado los conceptos definidos por la metodología y se han conjugado con las características de seguridad. También se definieron nuevos diagramas adicionales a los que propone originalmente Tropos para formalizar Secure Tropos, pero que conservan una relación cercana a los existentes. En este trabajo, se enfatizó en dar solución a los siguientes tres problemas:

- Los desarrolladores que deben implementar un SMA seguro no tienen el conocimiento para hacerlo.

- Existe una brecha entre el lenguaje utilizado por los desarrolladores de software y los especialistas en seguridad, lo cual hace que la integración entre las disciplinas sea más difícil.

- Diferenciar entre los componentes de seguridad y los componentes de software.

En el trabajo de Mouratidis [MOUR2004], surgió la necesidad de extender aun más a Secure Tropos para dar solución a los siguientes dos problemas:

- Llevar un conjunto de requerimientos de seguridad al diseño, donde es difícil obtener evidencia empírica de los problemas de seguridad.

- Probar a nivel de diseño una solución de seguridad adoptada.

Con el fin de solucionar estos problemas Mouratidis [MOUR2004], propone 3 subactividades que son: la selección de una arquitectura para la solución a partir de los requerimientos de seguridad, utilizar patrones de seguridad que hayan sido probados por expertos o que sean reconocidos para llevar los requerimientos de seguridad a nivel de diseño y por último crear escenarios de seguridad para probar una solución de seguridad implementada.

Otro aporte importante en el área de seguridad lo realiza Giorgini [GIOR2004]. La idea básica es modelar la seguridad y la confianza, para ello se necesita distinguir entre los actores que manipulan recursos, los que cumplen metas, los que ejecutan tareas y aquellos que poseen recursos o metas. Luego se necesita construir un modelo de confianza y posteriormente se genera un modelo funcional, donde se analizan las actuales delegaciones contra el modelo de confianza, verificando si un actor que ofrece un servicio está autorizado a tenerlo.

3.4. Metodología Prometheus

Prometheus es una metodología para diseñar agentes inteligentes desarrollada en colaboración con Agent Oriented Software Group3 y se ha aplicado en la industria y en las universidades. Esta metodología según Padgham [PADG2002], se caracteriza por ser

3 http://www.agent-software.com/shared/home/ (Ultima Consulta Enero 2006)

12

detallada y completa en el sentido que cubre las actividades requeridas para desarrollar sistemas multiagente inteligentes, abarcando desde el análisis de requerimientos hasta la implementación, donde se ha integrado el framework JACK [HOWD2001]. La metodología se caracteriza por asistir a los desarrolladores para diseñar, documentar y construir un SMA completo.

De acuerdo con Padgham [PADG2002], Prometheus difiere de otras metodologías en las siguientes apreciaciones:

- Soporta el desarrollo de agentes inteligentes que usan metas, creencias, planes y eventos, basándose en el desarrollo de agentes BDI.

- Proporciona un soporte desde la especificación hasta la implementación con un proceso detallado.

- Proporciona mecanismos de estructuración jerárquicos para múltiples niveles de abstracción.

- Utiliza un proceso iterativo durante el desarrollo de las etapas de ingeniería de software.

- Ha sido probada en la industria y en la educación con gran éxito.

Fases de la metodología

La metodología Prometheus consiste en tres fases. La primera es la Especificación del Sistema, donde se identifican las principales funcionalidades del mismo, las entradas (percepciones), las salidas (acciones) y fuentes de datos compartidos. La segunda fase, Diseño Arquitectónico, utiliza las salidas, especificadas anteriormente, para determinar que agentes contendrá el sistema y sus interacciones. La tercera fase, Diseño Detallado, comprende el estudio de la arquitectura interna de los agentes y proporciona la forma para completar las tareas de dichos agentes dentro del sistema. En la Figura 3-3, se pueden observan todas las fases que pertenecen a la metodología Prometheus. A continuación se describe en detalle cada una de las fases.

13

Figura 3-3. Fases de la metodología Prometheus, adaptado de [PADG2002].

- Especificación del Sistema: en esta fase se inicia con la descripción funcional del SMA. Para definir correctamente esta funcionalidad se debe especificar el tipo de información que es requerida e información adicional que sea producida.

Paralelamente se debe entender cómo el SMA interactuará con el ambiente. El flujo de información que llega del ambiente y es captado por el agente se llama percepción y los mecanismos para afectar el ambiente son llamados acciones. También se debe distinguir entre eventos y percepciones. Un evento es una ocurrencia significativa para el sistema de agentes, mientras que las percepciones son los datos en bruto disponibles para el sistema de agentes. Algunas veces las percepciones deben ser procesadas para identificar eventos ante los cuales unos agentes pueden reaccionar.

Dentro de esta fase se generan dos artefactos – entregables de la metodología. El primero de ellos es el Descriptor de Funcionalidad, que contiene la información de percepción, acción e interacción con el ambiente. El segundo artefacto utilizado para proporcionar una visión más holística del sistema, son los Escenarios de Casos de Uso.

- Diseño Arquitectónico: en esta fase se definen los agentes que existirán en el SMA. Se asignan funcionalidades en el sistema basados en los artefactos anteriores. Los agentes son agrupados de acuerdo a las funcionalidades a las que van a responder para ser acordes con los conceptos de bajo acoplamiento y alta coherencia.

14

Con el fin de agrupar los agentes para que cumplan los requerimientos anteriormente descritos se utiliza un Diagrama de Agrupamiento de Agentes, que relaciona unos agentes con otros.

Una vez definidos qué agentes estarán en el sistema se inicia una descripción detallada de cada uno de ellos mediante un artefacto llamado Descriptor de Agentes, el cual contiene la información sobre funcionalidad, datos e interacciones.

Adicionalmente en esta fase se debe identificar que eventos serán generados como resultado de la información del ambiente. Para lograr las metas del sistema los agentes deben comunicarse enviado mensajes unos a otros, actividad que también debe especificarse en esta etapa. Además de la comunicación entre los agentes se debe identificar los Objetos de Datos Compartidos para relacionar a todos los agentes que utilicen recursos y que necesiten especificar técnicas de sincronización. Estos objetos de datos compartidos, pueden ser descritos utilizando POO. En esta fase se incluye la definición del Diagrama de Descripción del Sistema, que representa a los agentes, los eventos y los objetos de datos compartidos, mostrando las relaciones en el sistema. El último paso en esta fase es representar las interacciones entre los agentes del sistema. Para esta labor se utiliza un Diagrama de Interacciones, heredado de la POO, en donde se toman los casos de uso diseñados en la fase de especificación del sistema y se construyen los diagramas de interacción.

Finalmente, para definir aún más las interacciones del sistema a partir del diagrama de interacciones se genera el Diagrama de Interacción de Protocolos, que describe las secuencias de interacciones válidas dentro del sistema.

- Diseño Detallado: esta fase se concentra en desarrollar la estructura interna de cada uno de los agentes y definir cómo cada uno de ellos lograrán sus metas dentro del sistema. Adicionalmente se tienen en cuenta las capacidades de los agentes, los eventos internos, planes y estructuras internas detalladas. Las funcionalidades de la fase de especificación del sistema proporcionan un buen conjunto inicial para definir las capacidades del agente, que luego de varios refinamientos, quedarán descritas en términos de los planes eventos y datos.

Cada capacidad debe ser descrita utilizando un Descriptor de Capacidades, que contiene la información que especifica el comportamiento de lo que puede hacer y cómo reacciona un agente ante un evento.

Para describir gráficamente las capacidades se utiliza el Diagrama de Descripción de Agentes, que es parecido al diagrama general del sistema, pero se diferencia en que éste describe las capacidades de un agente, mostrando eventos, flujos entre las capacidades y datos internos del agente. Los últimos artefactos requeridos son los descriptores de planes, eventos y datos, que proporcionan los detalles necesarios para moverse a la implementación.

Como artefacto adicional, se puede incluir un Diccionario de Datos, que debe ser construido desde el principio del proyecto y constantemente modificado. En él se deben especificar los conceptos para mantener una coherencia durante todo el desarrollo de la metodología.

3.5. Metodología Gaia

De acuerdo con Zambonelli [ZAMB2003], un SMA, puede ser naturalmente visto y construido como una organización computacional. La visión tradicional de un SMA dice que puede ser concebido en términos de una sociedad organizada de individuos, en la

15

que cada agente juega un rol específico e interactúa con otros agentes de acuerdo a protocolos determinados por los roles.

Sin embargo, esta visión debe profundizarse más, porque se debe asumir que la organización es más que una simple colección de roles y para construir efectivamente un SMA en términos organizacionales, las abstracciones orientadas a las organizaciones necesitan ser identificadas y ubicadas en el contexto de la metodología. Por esta razón los esfuerzos de Zambonelli, van encaminados a identificar esas abstracciones organizacionales y extender la metodología Gaia.

La Metáfora Organizacional

El trabajo de Zambonelli, se concentra en desarrollar de sistemas medianos y grandes, posiblemente divididos en ambientes abiertos y dinámicos garantizando predictibilidad y comportamientos confiables. En este contexto define al sistema como la instancia computacional de un grupo de individuos interactuantes y autónomos (agentes). Cada agente juega uno o más roles específicos, con un conjunto de responsabilidades enmarcado en un contexto, donde ellos toman decisiones altruistas y oportunistas.

Las interacciones son vistas como el medio por el cual los agentes cumplen sus roles en el sistema y ayudan a organizar la estructura del sistema y los agentes en ella. Esta perspectiva se puede ver ilustrada en la Figura 3-4, en donde sistemas simples pueden ser vistos como un sola organización y a medida que aumenta la complejidad se subdividen en sistemas que dan a lugar suborganizaciones, con subconjuntos de agentes ubicados en cada una de ellas, incluso con agentes ubicados en dos o más. El SMA se ve inmerso en un ambiente del cual los agentes necesitan interactuar para cumplir con su rol. Estas interacciones con el ambiente ocurren mediante sensores y efectores, que son mecanismos que les ayudan a los agentes a percibir y actuar con el ambiente. Con este enfoque organizacional se promueve una visión micro y macro, para el comportamiento de los agentes y el sistema.

Figura 3-4. SMA como una organización computacional, adaptada de [ZAMB2003].

Ahora bien para definir completamente el SMA con el enfoque organizacional que propone Zambonelli [ZAMB2003], se deben identificar y contextualizar las abstracciones organizacionales, que serán después integradas como extensión a la metodología Gaia.

16

Éstas son en su orden: el ambiente, los roles, las interacciones, las reglas organizacionales y las estructuras organizacionales, que son presentadas a continuación.

- El Ambiente: un SMA siempre está situado en un ambiente. Zambonelli considera que ésta debe ser la primera abstracción en las etapas de análisis y diseño. Identificar y modelar el ambiente envuelve la determinación de las entidades y recursos que el SMA puede explotar, controlar o consumir cuando se trabaja hacia la satisfacción de una meta organizacional. Adicionalmente el ambiente no debe ser implícitamente asumido, sus características deben ser identificadas, modeladas y posiblemente relacionadas a los propósitos específicos de las aplicaciones.

- Roles e Interacciones: los roles de un agente definen lo que se espera que haga dentro de la organización. Dan al agente una posición bien definida dentro de la organización con una asociación de comportamientos esperados. Por otra parte las interacciones organizacionales describen los protocolos que gobiernan las interacciones entre los roles.

- Reglas Organizacionales: en la fase de captura de requerimientos del SMA, se deben identificar las habilidades básicas (funcionalidades y competencias), requeridas por la organización, así como también las interacciones básicas requeridas para la explotación de esas habilidades. Antes de caracterizar totalmente la organización, el análisis del SMA debe identificar las restricciones que la organización actualmente tiene, para que con ese conjunto de reglas organizacionales se pueda modelar correctamente el sistema.

Esta identificación de las reglas organizacionales permite definir explícitamente:

1. Cuando permitir a nuevos agentes entrar a la organización y una vez aceptados establecerles que posición ocuparán.

2. También debe permitir identificar que comportamientos deben ser considerados legítima expresión de intereses propios y debe permitir identificar cuáles de dichos comportamientos deben ser prevenidos por la organización.

Con lo expuesto anteriormente se refuerza la estructura organizacional y se previenen comportamientos indeseables en los agentes.

- Estructuras Organizacionales: un modelo de roles describe todos los roles de una organización y sus posiciones en la organización, implícitamente define la topología de interacción y el régimen de control en las actividades organizacionales; esto es la arquitectura del SMA organizacional, es decir la estructura organizacional. De acuerdo con lo anterior se debe establecer lo siguiente:

1. Aunque la estructura organizacional del SMA esté inspirada en la estructura organizacional del mundo real, esto no implica que la estructura del mundo real se deba hacer equivalente a la estructura del SMA organizacional en todos los casos. Existe la posibilidad que la estructura del mundo real no esté bien definida y los problemas existentes en ella se puedan hacer equivalentes en el SMA. Adicionalmente una construcción de software siempre trae cambios en la organización del mundo real.

2. Se debe tener en cuenta que las organizaciones son cambiantes y en todo momento se debe garantizar la eficiencia organizacional.

3. Una vez que se haya definido una organización, ésta debe respetar sus reglas organizacionales, empezando por su estructura organizacional.

17

Etapas de la Metodología Gaia

Teniendo en cuenta los conceptos básicos introducidos anteriormente, se puede definir formalmente la metodología Gaia. En la Figura 3-5, se ilustran todos los pasos de la metodología incluyendo aquellos que se introdujeron en la extensión propuesta por Zambonelli [Zamb2003]. El proceso inicia con la fase de requerimientos, los cuales pueden recolectarse usando algún método tradicional de la ingeniería de software. A continuación en fase de análisis, se identifican las metas de la organización y se constituye como será el comportamiento global del sistema; la organización se descompone en suborganizaciones. En esta fase, se realizan los siguientes modelos para satisfacer los objetivos expresados anteriormente: modelo del ambiente, modelo preliminar de roles y el modelo preliminar de interacciones; se deben definir las reglas que la organización debe respetar y reforzar en su comportamiento global.

La siguiente fase es el diseño arquitectónico, que involucra la definición de la estructura organizacional del sistema en términos de la topología, el régimen de control y la refinación de los modelos preliminares de roles e interacción definidos en la fase de análisis. Finalmente en la fase de diseño detallado, se genera la definición del modelo de agentes y la definición del modelo de servicios. A pesar que la metodología define claramente tres fases para el diseño de SMA, Gaia no maneja directamente técnicas particulares de modelado, tampoco los problemas inherentes a la implementación, tampoco las actividades para capturar los requerimientos ni el modelado típico de la ingeniería de software.

Figura 3-5. Metodología Gaia con nuevas extensiones [ZAMB2003].

Fase de Análisis

18

El principal objetivo de esta fase es organizar los requerimientos del sistema en el modelo ambiental, en el modelo preliminar de roles, el modelo de interacciones y el conjunto de reglas organizacionales para cada una de las suborganizaciones que componen todo el sistema. A continuación se explican los artefactos principales de esta fase:

- Subdividir Sistemas en Suborganizaciones: se identifican las metas que constituyen todo el sistema y su comportamiento esperado, dividiendo la organización en suborganizaciones.

- Modelo del Ambiente: se define como una representación computacional abstracta en el cual el SMA está situado.

- Modelo Preliminar de Roles: identifica las habilidades básicas requeridas por la organización, contiene los roles que son identificados sin comprometer la imposición de una estructura organizacional.

- Modelo de Interacciones Preliminar: identifica las interacciones básicas requeridas para completar los roles preliminares.

- Las reglas Organizacionales: esta característica es una de las nuevas adiciones a la metodología Gaia, estas reglas expresan las restricciones en la ejecución de las actividades de los roles y protocolos, pero a su vez representa las relaciones entre los roles y protocolos; deben ser consideradas como las responsabilidades de la organización. Se pueden definir dos tipos de reglas organizacionales:

- Reglas de Supervivencia: definen como la dinámica de la organización debe desarrollarse con el tiempo, como por ejemplo que un rol pude ser ejecutado por una entidad solamente cuando haya ejecutado otro rol anterior.

- Reglas de Seguridad: definen las invariantes globales de independencia temporal que la organización debe respetar, como por ejemplo el hecho de que un rol debe ser ejecutado sólo por una entidad durante el tiempo que dure la organización, o que dos roles nunca pueden ser ejecutados por una misma entidad.

En general, las reglas organizacionales y su correcta identificación son fundamentales para la etapa de diseño, porque restringen la definición de la estructura organizacional y restringe el número de implementaciones propias de una organización. También son importantes para saber cuando un nuevo agente puede ser admitido en la organización y que roles tienen permisos de ejecutar una acción sobre el ambiente; adicionalmente identifican que clases de protocolos pueden ser iniciadas por los miembros de una organización y cuando esta clase de protocolos son una expresión de intereses propios legítimos.

Fase de Diseño Arquitectónico

Esta fase expone todas las características funcionales que el SMA expresará e identificará la forma de estructurar el SMA en la organización. Dentro de esta fase se realizan dos actividades importantes:

- Estructura Organizacional: según Zambonelli [ZAMB2003], la selección de la estructura organizacional debe escogerse en términos de una topología y un régimen de control, teniendo en cuenta la eficiencia y simplicidad organizacional, la influencia de la organización del mundo real y la influencia de las reglas organizacionales.

Cuando la topología es simple, es posible manejar la complejidad computacional y la coordinación. Conforme aumenta el tamaño de la organización aumenta la complejidad y la coordinación, llevando a adoptar una topología jerárquica hasta

19

alcanzar máximos niveles de complejidad y adoptar múltiples jerarquías. El régimen de control maneja las interacciones entre los miembros de las organizaciones y es de alguna manera ortogonal a la topología de la organización.

En cuanto a la influencia de las reglas organizacionales, el SMA debe respetar y estar en la capacidad de decretarlas durante la ejecución. Las reglas organizacionales impactan sobre la estructura organizacional, donde el reforzamiento de las mismas tendrá un efecto en los costos computacionales y de coordinación. Por otra parte, en lo que se refiere a la influencia de la organización del mundo real, ésta se presenta como una fuerza de atracción en la definición de la estructura organizacional.

- Refinamiento de los Modelos de Roles e Interacción Preliminares: esta actividad se realiza una vez se ha definido la estructura organizacional; es importante mantener la distinción entre las características que son intrínsecas, independientes de los roles y protocolos en una organización específica, y las extrínsecas, derivadas de la adopción de una estructura organizacional específica.

Fase de Diseño Detallado

Esta fase es la responsable de identificar el modelo de agentes y de servicios, que resultarán siendo la base para la implementación de los agentes y sus actividades. Se definen los siguientes modelos:

- Modelo de Agentes: encargado de identificar las clases de agentes que compondrán el sistema y las instancias de agentes que serán generadas a partir de dichas clases. Se realizan las correspondencias entre los tipos de agentes y los roles.

- Definición del Modelo de Servicios: identifica los servicios principales que son requeridos para conformar los roles de los agentes y sus propiedades. Adicionalmente con un buen análisis y diseño se obtienen los artefactos necesarios para pasar a la etapa de implementación que no es definida por la metodología Gaia, actividad que dependería del programador del SMA.

Finalmente, cabe anotar que Sutandiyo [SUTA2004], presenta mGaia, una extensión a la metodología Gaia para el diseño de SMA que tiene en cuenta la movilidad. La propuesta presentada, modifica Gaia añadiendo un modelo a la etapa de diseño: el Modelo de Movilidad. En este modelo, se definen ambientes, las relaciones entre agentes y los ambientes, la cardinalidad de estas relaciones y las rutas de viaje de los agentes a través de los ambientes donde se despliegan. Además, para ser coherente con el resto de la metodología, se adicionan características a los otros modelos, como por ejemplo la descripción del agente identificando si es móvil o no en el Modelo de Agentes.

3.6. Metodología MAS-CommonKADS

Esta metodología está basada en la metodología CommonKADS propuesta por Schreiber et.al. [SCHR1999], la cual es adaptada para diseñar SMA añadiéndole técnicas del análisis y diseño orientado por objetos, como la técnica de modelado de objetos (OMT), ingeniería de software orientada a objetos y diseño basado en responsabilidades; así como metodologías orientadas a protocolos, el lenguaje de especificación y descripción (SDL) y gráficos de secuencias de mensajes (MSC96).

Esta metodología desarrolla siete modelos: Modelo de Organización, que describe las relaciones estructurales entre agentes (agentes humanos o de software); Modelo de Tareas, que describe las tareas que un agente llevará a cabo; Modelo de Agentes, que describe las características de cada agente; Modelo de Comunicación, que describe las relaciones dinámicas entre agentes humanos y sus respectivos agentes de software;

20

Modelo de Conocimiento, que describe el conocimiento que debe tener un agente para lograr sus metas; Modelo de Diseño, que refina los modelos anteriores y determina la arquitectura más apropiada para cada agente así como los requerimientos para la red de agentes; y un Modelo de Coordinación, que describe las relaciones dinámicas entre agentes de software [IGLE1998].

De estos siete modelos, los seis primeros pertenecen a la metodología CommonKADS y el último es incorporado para aplicaciones multiagente. MAS-CommonKADS divide el proceso de análisis y diseño de la siguiente forma: primero, hay una fase conceptualización, en la que se obtiene una visión preliminar del problema, una fase de análisis, en la que se obtienen los requerimientos y tercero una fase de diseño, en donde se determina el conjunto inicial de agentes que se van a utilizar.

Fase de Conceptualización

En esta fase se obtiene una descripción preliminar del problema y se hace un bosquejo de las interacciones, con las cuales se hará un refinamiento cuando se cree el modelo de coordinación. Esto se hace siguiendo una aproximación centrada en el usuario, determinando algunos casos de uso o escenarios, los cuales ayudan a entender algunos requerimientos informales y a probar el sistema.

Los casos de uso son descritos utilizando la notación OOSE y las interacciones son formalizadas utilizando diagramas de secuencias de mensajes, MSC. En la Figura 3-6, se puede ver un ejemplo del diagrama de casos de uso. En este caso, los agentes humanos son los que tienen cabeza redonda y los agentes de software son los que tienen la cabeza cuadrada.

Figura 3-6. Diagrama de Casos de Uso, adaptado de [IGLE1998].

Fase de Análisis

El resultado de esta fase debe ser el conjunto de requerimientos que especifican el sistema multiagente a través de los modelos descritos anteriormente (a excepción del modelo de diseño). Los pasos para desarrollar dichos modelos son los siguientes:

- Modelado de Agentes: identificación de agentes. Para esto se pueden seguir algunas estrategias:

- Análisis de los actores de los casos de uso encontrados en la fase de conceptualización.

- Análisis del planteamiento del problema.

21

- La realización de un modelo inicial de tareas y de conocimiento puede ayudar a identificar las capacidades requeridas por los agentes.

- Aplicación de la técnica de casos de uso internos. Para esto se utilizan tarjetas CRC (Class Resposibility Collaboraton) y RDD (Responsibility Driven Desing).

- Modelado de Tareas: las tareas se descomponen siguiendo una aproximación “topdown”. Esta descripción incluye el nombre, una descripción corta, entradas, salidas, estructura de tareas, su control, frecuencia de aplicación, precondiciones y habilidades requeridas.

- Modelo de Coordinación: este modelo tiene dos hitos: el primero es la definición de los canales de comunicación y la construcción de un prototipo y el segundo es el análisis y determinación de las interacciones complejas.

- Modelo de Conocimiento: mediante este modelo se busca establecer las capacidades de “razonamiento” de los agentes, es decir, como deben ejecutar sus tareas para lograr sus metas. Este modelo de conocimiento se divide de la siguiente manera:

- Conocimiento del Dominio: representa el conocimiento declarativo del problema. Está compuesto por las ontologías del dominio [SALC2002], que proporcionan el vocabulario de las entidades del dominio, sus relaciones y las restricciones en su estructura; los modelos del dominio, que describen el conocimiento sobre el dominio particular; los conceptos, que corresponden a clases de objetos que son las abstracciones del mundo real que representan objetos físicos o estados; las propiedades, que son los atributos de los conceptos; las expresiones, que son afirmaciones del tipo “la propiedad x del concepto y tiene el valor z”; y las relaciones, que son las conexiones entre los diferentes elementos del dominio.

- Conocimiento Sobre Inferencias: describe los procesos primitivos de razonamiento que tienen lugar en una aplicación, así como los roles de conocimiento que son usados por las inferencias. En general, definen los pasos a seguir para resolver una tarea.

- Conocimiento de Tareas: describe de una forma recurrente la descomposición de una tarea de alto nivel en subtareas, es decir, representa el orden en que las inferencias son ejecutadas. Con este conocimiento, se puede establecer el Método de Solución de Problemas (PSM, por sus iniciales en inglés) [IGLE1998], el cual define como se debe llevar a cabo una inferencia para realizar una tarea.

- Modelo de Organización: este modelo define la estructura y comportamiento de la organización en el que el sistema va a ser desplegado. Este modelo muestra las relaciones estructurales o estáticas entre los agentes. La notación básica utilizada es la del modelo de objetos de OMT, añadiendo algunos símbolos para diferenciar a los agentes de los objetos.

En la Figura 3-7, se puede observar un ejemplo de la jerarquía de los agentes identificados. Aunque los símbolos utilizados son similares a los de OMT, su significado es un poco diferente; el diagrama de ese agente se compone de dos cajas ubicadas debajo del nombre del agente. En la caja de arriba no almacena los atributos sino el estado mental y los atributos internos del agente, mientras que en la caja de abajo se almacenan los atributos externos de los agentes como: sensores, efectores y servicios.

22

Figura 3-7. Diagrama de clases de agentes [IGLE1998].

Fase de Diseño

Como resultado de la fase de análisis, se ha determinado un conjunto inicial de agentes, los cuales deben ser detallados en esta fase. En la metodología CommonKADS, el modelo de diseño se utiliza para describir la arquitectura y el diseño técnico del sistema justo antes de su implementación. En MAS-CommonKADS, este modelo es extendido para modelar SMA y posee los siguientes pasos [IGLE1998]:

- Diseño de la Red de Agentes: corresponde a la infraestructura del SMA; consiste en los elementos de red, conocimiento y coordinación.

- Diseño de Agentes: se determina la arquitectura interna más adecuada para cada agente.

- Diseño de la Plataforma: selección del software (entorno de desarrollo de agentes) y del hardware necesario para el sistema.

3.7. MaSE

Es una metodología para desarrollar SMA de propósito general según DeLoach [DELO2000]. La idea es guiar al diseñador desde la especificación inicial del sistema hasta la implementación del SMA.

La metodología está dividida en dos fases: análisis y diseño. Sin embargo, sólo se estudiará la fase de análisis, pues es la más importante y es la que tiene mayor relevancia para DeLoach. Aunque MaSE no está diseñada para ser utilizada con alguna arquitectura particular, lenguaje de programación o plataforma de comunicación, está asociada con una herramienta CASE llamada agentTool.

Fase de análisis

El primer paso en la fase de análisis es el de obtener las metas del SMA, lo cual se hace a partir de las especificaciones iniciales. Esta fase es orientada a metas, porque éstas son generalmente más estables que las funciones y procesos, es decir, es menos probable que las metas cambien en el tiempo. Las metas contienen lo que el sistema intenta lograr.

23

En MaSE, una meta siempre está definida como un objetivo a nivel de sistema. El proceso de capturar metas produce una jerarquía de metas, la cual, no es necesariamente siempre un árbol, de hecho, se pueden combinar nodos entre las ramas, generando así un grafo dirigido.

Luego de haber identificado las metas y su estructura, se deben crear los casos de uso, los cuales son extraídos del contexto inicial del problema. En este caso, se deben tener en cuenta el flujo normal, que describe lo que pasa en condiciones normales, y el flujo alterno, que describe como se debe comportar el sistema en caso de una falla. Una vez se hayan identificado los casos de uso, estos son utilizados para crear los diagramas de secuencias entre los roles identificados en ellos. El último paso de la fase de análisis, consiste en refinar los roles encontrados, esto es, transformar los objetivos y los diagramas de secuencias en roles y sus respectivas tareas. En MaSE, las tareas son definidas para cada rol de modo que se ejecuten de forma concurrente. Las tareas se utilizan para modelar el comportamiento de los agentes, estas puede ser diseñadas para ejecutarse de forma concurrente como lo describe DeLoach [DELO2001]. Aunque en un artículo posterior, DeLoach [DELO2002], propone modelar el comportamiento utilizando un medio híbrido de coordinación y concurrencia.

3.8. Metodología para el Desarrollo Orientado a Agentes - DOA

De acuerdo con J. Tian [TIAN2004], los desarrollos de software complejo afrontan grandes retos como son la vaguedad, criticidad, volatilidad; evolucionan y deben manejar el tiempo del proyecto adecuadamente. Por esta razón, Tian propone el uso de SMA, porque son adecuados para manejar todas las variables anteriormente mencionadas y tienen la capacidad de desarrollar sistemas de software complejos. Para ello el SMA se debe valer de su unidad fundamental que son los agentes, los cuales Tian define como “unas entidades físicas o lógicas dentro de un ambiente, del cual pueden sentir y actuar”.

Para diseñar un SMA, se debe seguir una metodología, según Tian, la mayoría de metodologías orientadas a agentes se limitan a describir roles y sus relaciones o generar modelos gráficos y formales, otras describen la descomposición de roles en tareas. Sin embargo, en común las metodologías no tratan con el diseño arquitectónico de una manera completa. Por esta razón, se define una metodología que enfatice la arquitectura del sistema – para reducir la complejidad – y que se desarrolle con un ciclo de vida lineal. Tian, describe su metodología teniendo en cuenta la perspectiva de rol, flujos de información y perspectivas de control, con un mapeo muchos a muchos entre subfunciones, roles y los agentes.

El punto clave de esta metodología es identificar la funcionalidad general del sistema, descomponerla y agruparla, para luego entrar a definir agentes que puedan satisfacer dichas subfunciones, mediante metas, submetas y planes individuales que logren satisfacer la funcionalidad general del sistema. Para el desarrollo de la metodología se utiliza un ciclo de vida lineal; adicionalmente se ha aplicado esta metodología en un caso de estudio para la medicina utilizando la herramienta Agent Tool.

La metodología se compone de tres fases básicas, cada una de las cuales describe una serie de pasos. Estas son: Análisis de Requerimientos, Diseño Arquitectónico del SMA y Diseño Detallado del SMA.

Análisis de Requerimientos

En esta fase el objetivo fundamental es obtener los requerimientos funcionales y no funcionales, basado en los requerimientos la funcionalidad general del SMA debe ser descompuesta en varias subfunciones. En esta fase encontramos el siguiente paso:

24

1. Se realiza el análisis y agregación de los requerimientos dentro de un SMA, una vez realizado el análisis de requerimientos y haber descompuesto el SMA en subfunciones, éstas se diferencian y relacionan unas con otras que más adelante se agregarán en grupos.

Diseño Arquitectónico del SMA

En esta fase se identifican y se especifican los componentes del sistema y sus interrelaciones. La arquitectura debe contener a los agentes como componentes del sistema y las comunicaciones sociales como las interacciones. Dentro de este proceso, los roles de los agentes y las relaciones entre ellos son definidas.

La arquitectura se define desde tres perspectivas: la perspectiva de roles, la perspectiva de flujos de información y la perspectiva de control. En la perspectiva de roles las funciones del SMA se decomponen en muchas subfunciones, mientras que el sistema se descompone en subsistemas, muchos agentes juegan diferentes roles para distintos servicios, éstos deben ser relacionados a las subfunciones. Desde la perspectiva del flujo de información, se debe entender que un SMA tiene una interacción dinámica y comunicación dentro del SMA. Y finalmente desde la perspectiva de control, el SMA debe ser organizado como una jerarquía de control rígida, para subdividir en varias capas que se encarguen de distintas tareas. En conclusión dentro de esta fase se llevan a cabo los siguientes pasos:

1. Se realiza la identificación de los roles de los agentes y sus responsabilidades; respondiendo desde la perspectiva de roles; en este paso se identifican los roles que serán ejecutados por los agentes y sus responsabilidades, que es lo que el agente debe hacer, cuándo y cómo los agentes colaboran para lograr una meta. Desde un punto de vista interno los SMA son como subsistemas, cada uno de los cuales puede ser un agente o varios agentes (grupo – cluster- de agentes). Estos subsistemas, juegan diferentes roles que proporcionan diferentes funciones al SMA. Desde un punto de vista externo los agentes o clusters de agentes proporcionan servicios hacia el exterior.

2. Se realiza la determinación de la jerarquía de metas y la estructura de creencias del SMA; respondiendo a la perspectiva de control, un SMA tiene metas mientras que los agentes tienen sus propias submetas, subsubmetas y planes que llevan acabo por sus roles. Todo lo anterior forma la jerarquía de metas. Una estructura de creencias es establecida para denotar todos los flujos de trabajo, componentes y relaciones de control entre los componentes, en el SMA. Todos los agentes del sistema satisfacen sus metas mediante esta estructura de creencias.

3. Se realiza la determinación de las interacciones del SMA; respondiendo a la perspectiva del flujo de información, en este paso se determinan las interacciones entre los agentes y los sistemas externos, que se define como envío y recepción de mensajes.

Diseño Detallado del SMA

En esta fase se selecciona la plataforma de implementación de los agentes y se llevan a cabo detalles de implementación como la comunicación y el despliegue de estos agentes. En esta fase se realizan los siguientes pasos:

1. Se realiza la configuración de la plataforma de agentes; este paso es basado en el domino de la aplicación.

25

2. Se realiza la construcción de los agentes; éstos son diseñados sobre la plataforma seleccionada de acuerdo a los roles y planes definidos, el programador debe especificar una ontología para la aplicación.

3. Se realiza la especificación de la infraestructura de comunicación de los agentes; en este paso se define un ACL (Agent Communication Language), las reglas de comunicación son diseñadas en detalle.

3.9. Metodología para el Análisis y Diseño de Sistemas - ADS

Ramos [RAMO2004], propone una metodología formal para el desarrollo de soluciones de software soportado en agentes. Ésta tiene un enfoque basado en una arquitectura Beliefs-Intentions (Creencias - Intenciones) y utiliza un alfabeto de lógica temporal y axiomas para modelar el sistema. La metodología detalla explícitamente las fases de la especificación, la implementación y la verificación.

La metodología toma como unidad fundamental a los agentes (como la mayoría de metodologías) y se enfoca en solucionar los problemas de la interoperabilidad entre los agentes inmersos en un contexto cooperativo y distribuido. Fue probada con un caso de estudio orientado hacia el comercio electrónico; entre los aportes que se pueden apreciar, se puede destacar la formalización en la fase de especificación, en ella Ramos [RAMO2004] utiliza un lenguaje con una estructura sintáctica llamado LCIASA, con el cual se puede describir las interacciones de los agentes basado en planes y mensajes con notación BNF.

Otro aspecto destacable es en la fase de implementación, en donde Ramos propuso utilizar una arquitectura subconjunto llamada Arquitectura Deliberativa [JENN2000] de las arquitecturas BDI. Esta arquitectura está orientada hacia el racionamiento interno de los agentes y su interacción con el ambiente. Adicionalmente, también propone un framework llamado Agent’s Plataform [AGUI2001] que le permite diseñar los agentes y ejecutarlos. A continuación se describen las tres fases de la metodología.

Fase de Especificación

Esta fase abarca la perspectiva de diseño, el modelo de agentes, el modelo formal y los protocolos de interacción.

- Perspectiva de Diseño: esta etapa se concentra en identificar qué se va a resolver y cómo se va a resolver. Aquí se identifican y se determinan los agentes envueltos en el problema. Con el fin de definir correctamente el problema y resolverlo, se toma un diseño organizacional para los agentes y se definen las actividades de cada uno de ellos en el sistema. Los agentes deben ser caracterizados por las funciones que prestan y por sus atributos como roles, responsabilidades, propósitos, servicios ofrecidos y relaciones.

- Modelo de Agentes: estableciendo una estructura organizacional para los agentes, una herramienta estándar es usada para modelar dicha estructura. En este caso se utiliza de UML los diagrama de clases, mostrando un modelo que presenta los agentes involucrados en el sistema, las relaciones entre ellos y los atributos que los caracterizan.

- Modelo Formal y los Protocolos de Interacción: este modelo describe la funcionalidad y operatividad del SMA, y muestra la consistencia que el sistema debe exhibir. El modelo utiliza el AML (Agent Meta Language), que está basado en la lógica temporal y el lenguaje LCIASA – el cual describe mensajes de intercambio entre agentes –, AML

26

es utilizado para ayudar en la tarea de especificación e interpretación, obteniendo al final un estudio sobre las características, propiedades y comportamientos del SMA.

La descripción del lenguaje LCIASA, proporciona una estructura estática e interpretación semántica de las acciones expresadas en AML. LCIASA, está formado por un conjunto de mensajes KQML y acciones compuestas. La sintaxis está definida por un conjunto de reglas que generan las oraciones correctas del lenguaje. La asociación entre LCIASA y AML es percibida observando que las acciones de AML corresponden a los mensajes de LCIASA y que LCIASA proporciona una estructura sintáctica para AML.

Fase de Implementación

Esta fase estudia el cambio de la especificación abstracta a un sistema computacional concreto. En la Figura 3-8, se ilustra la arquitectura utilizada para la metodología, donde las decisiones se toman mediante un razonamiento lógico.

Figura 3-8. Arquitectura para la metodología, adaptado de [RAMO2004].

Fase de Verificación

Es el proceso de probar que un sistema implementado está correcto con respecto a su especificación. Para la metodología se utilizan dos procesos de verificación, el primero es verificación por ciclo de vida y el segundo es una verificación formal.

- Verificación por Ciclo de Vida: determina el valor de satisfacción del SMA para una especificación establecida, durante cada uno de las fases del desarrollo.

- Verificación Formal: para verificar formalmente el sistema se utiliza el modelo lógico obtenido.

3.10. Metamodelo para Agentes, Roles y Grupos

27

De acuerdo con Odell [ODEL2004a], los sistemas multiagente a gran escala contienen múltiples agentes con distintas capacidades que en el momento de satisfacer una tarea; deben operar como sistemas cerrados, formando grupos dinámicos para completar satisfactoriamente una labor. Por esta razón Odell [ODEL2004a], propone la especificación de una superestructura, que permita definir a los agentes por medio de sus roles y así conformarlos en grupos para satisfacer una tarea asignada. Esta especificación se extiende de la especificación de UML para los diagramas de clases y se define como se puede observar en la Figura 3-9.

Figura 3-9. Sintaxis Abstracta Propuesta, adaptada de [ODEL2004a].

En Odell [ODEL2004b], se analiza en profundidad la asignación dinámica de los roles. Aquí se identifican los roles dentro del contexto donde se enmarcan los grupos. Para ello Odell [ODEL2004b] propone dos conceptos interesantes, la clasificación dinámica y la activación dinámica.

Cuando se habla de clasificación dinámica, se refiere a la habilidad de cambiar la clasificación de una entidad o en este caso un agente [ODEL2004b]. La idea principal de este concepto es que un agente tiene un rol mínimo o base y a partir de allí se pueden añadir, remover o cambiar roles, siempre enmarcados en el contexto del grupo donde esta el agente o los agentes. En otras palabras, este concepto hace referencia a que cuando se instancia un agente toma un rol y cuando se desactiva, pierde el rol. La activación dinámica se puede entender como la revelación de un rol, que ya posee la entidad, dado un contexto, pero sin perder su rol base. En otras palabras, un agente puede tener varios roles, pero no estar activados todos al mismo tiempo. Con esta aproximación Odell [ODEL2004a], pretende mostrar la dinámica dentro de los grupos, puesto que tiene la independencia para definir todos los elementos por aparte, pero con el metamodelo los puede relacionar de forma que puedan modelar sistemas complejos y homogéneos.

28

El modelo principal se compone de tres clases principales, de las cuales se definen otras para mayor especificación del SMA. Éstas son Clasificador de Agentes, Agentes y Grupos. A continuación se profundiza más sobre estos conceptos.

Clasificador de Agentes

Odell [ODEL2004a], define varias formas en las cuales un agente puede ser clasificado. Se divide en dos subclases que son: Clasificador de Agentes Físico y Clasificador de Agentes por Roles.

- Clasificador de Agentes Físico: define las primitivas básicas de los requerimientos que todos los agentes deben poseer independientemente del rol que estén desempeñando. Un ejemplo es el siguiente: el agente debe poseer un nombre único; otras características que dependen de la implementación son la manera como los agentes envían y reciben mensajes, la forma en que mantienen sus atributos (estados o creencias) y la manera como interactúan con el ambiente o con otros componentes de software.

- Clasificador de Agentes por Roles: clasifica a los agentes por los varios tipos de roles que un agente puede tomar en cierto tiempo. Los roles se definen como repertorios normativos del comportamiento y otras características, contextualizadas dentro de un grupo donde esos roles son desempeñados. Los agentes pueden ser asociados con más de un Clasificador de Agentes por Roles, permitiendo una múltiple clasificación y puede cambiar roles en el tiempo, permitiendo una clasificación dinámica. Los roles proporcionan los bloques para construir un sistema social y proporcionan los requerimientos por los cuales los agentes interactúan. Un Clasificador de Agentes por Roles debe estar asociado a uno o más grupos, para darle un significado en un contexto.

Agentes

Odell, define el conjunto de agentes que conforman el sistema por medio de las clases Clasificador de Agentes y Agentes, para definir las instancias de un agente y su clasificación. Las instancias definen a las entidades autónomas e interactivas conocidas como agentes y las clasificaciones proporcionan las características subyacentes para cada agente. En otras palabras cada instancia de un Clasificador de Agentes especifica las características que poseen sus Agentes asociados.

Para comprender aún más, a continuación se ilustran las meta-clases que establecen relaciones entre los Clasificadores de Agentes (y sus subclases) con los Agentes; la forma de asociar a los Clasificadores de Agentes Físicos con los Clasificadores de Agentes por Roles. A partir de esta asociación se conforman los agentes, introduciendo al Clasificador de Agentes, y a los Agentes que definen completamente a cada uno de los agentes, relacionándolos con los roles y con agentes físicos que dependen de una plataforma en particular (Figura 3-10).

29

Figura 3-10. Asociación entre la clase Clasificador de Agentes y la clase Agentes [ODEL2004a].

Grupos de Agentes

Los grupos son un conjunto de agentes que se han colocado juntos por alguna razón. Están relacionados por sus roles, donde cada grupo de roles tiene un número de instancias de agentes. Estos grupos son clasificados de dos formas que pueden ser un grupo agentizado o un grupo no-agentizado.

- Los Grupos Agentizados: poseen todas las características que un sólo agente posee. En otras palabras el grupo de agentes puede ser visto como un sólo agente que puede responder por cualquiera de los agentes que conforman su grupo.

- Los Grupos No-Agentizados: establece un conjunto de agentes que representan una organización conceptual, o sinergias intergrupo. En otras palabras el grupo no-agentizado es un grupo que no es una subclase de un Agente. En este caso se debe interactuar con cada uno de los miembros del grupo.

El último paso para completar el diseño de un SMA, mediante este metamodelo es la asignación de los roles. En la Figura 3-10 se ilustró las asociaciones entre las clases Agente y Clasificador de Agentes (y sus subclases). Como las asignaciones de los roles son dinámicas un agente podría cumplir un rol en un grupo, pero no en otro, por esta razón se introduce una nueva clase llamada Asignación de Roles a Agente, que se encarga de modelar este comportamiento. Por lo tanto, ésta clase asocia las instancias de los Roles los Grupos y los Agentes. En la Figura 3-11, se ilustra el paso final al integrar la asignación de roles con los grupos, en donde esta asignación debe estar definida por el contexto del grupo.

30

Figura 3-11. Asociación entre Agentes, Grupos y Clasificador de Agentes [ODEL2004a].

3.11. SONIA

La metodología SONIA, Set of mOdels for a Natural Identification of Agents, propuesta por Alonso [ALON2004], permite la generación de una arquitectura multiagente para resolver un problema de acuerdo con un Modelo de Diseño Multiagente, que sistematiza y automatiza las actividades para identificar los componentes del SMA. La metodología define una sociedad de agentes que facilita la solución de un problema y puede ser utilizada para integrar sistemas antiguos indispensables. A continuacion se presentan las cuatro fases de la metodología.

Fase de Análisis

Basada en SETCM (Set Theory Base Conceptual Model) con lo que se genera el modelo estructural inicial y el modelo inicial de tareas. El primero, describe la estructura general del dominio del problema basado en conceptos, atributos de conceptos, asociaciones, atributos de asociaciones, clasificación de conceptos y clasificación de asociaciones. El segundo, describe la forma en que los problemas del dominio son solucionados (basado en las tareas y métodos). Luego, estos modelos son redefinidos para capturar el entorno del sistema y las entidades externas, produciendo los siguientes modelos:

- Modelo del Entorno: define las entidades externas al sistema y sus interacciones con este.

- Modelo Estructural: incluye estructuras del conocimiento del dominio de las entidades externas que interactúan con el sistema.

- Modelo de Tareas: añade las funcionalidades requeridas para interactuar con las entidades externas al sistema definidas en el modelo del entorno.

Fase de Diseño

Esta fase está dividida en dos etapas: síntesis y diseño arquitectónico. La primera, provee la identificación de agentes según componentes. Adicionalmente, los elementos del

31

modelo estructural y del de tareas, son agrupados dependiendo de las características de los agentes, conocimiento, comportamiento y responsabilidades, obteniendo los siguientes modelos:

- Modelo de Conocimiento: identifica los componentes de conocimiento agrupando los conceptos del modelo estructural y las asociaciones. Estas agrupaciones se dan por la alta cohesión interna de los miembros y el acoplamiento con otros grupos es bajo y son usadas para desempeñar tareas que tienen comportamientos similares.

- Modelo de Comportamiento: producido a partir del agrupamiento del modelo de tareas, las subtareas y los métodos. Esta agrupación se da debido a que las tareas y subtareas dependen unas de otras y utilizan el mismo conocimiento para resolver los problemas.

- Modelo de Responsabilidad: su propósito es el de identificar agentes y los objetos del entorno.

Fase de Diseño Arquitectónico

Esta fase se enfoca en la definición de los componentes arquitectónicos a través de los siguientes modelos:

- Modelo de Agentes: identifica a partir de los modelos de responsabilidad, conocimiento y comportamiento, cuales entidades deberían ser diseñadas como agentes autónomos. Un agente es identificado porque es una entidad sensitiva al entorno y tiene el conocimiento necesario para llevar a cabo las tareas necesarias para lograr su objetivo (meta).

- Modelo de Objetos: identifica y define a partir de los modelos de responsabilidad, conocimiento y comportamiento, los elementos pasivos que hacen parte del entorno.

- Modelo de Interacción: identifica y define las interrelaciones entre los agentes, el sistema y los objetos.

La Fase de Diseño de la Sociedad de Agentes

Esta fase consiste en la solución de un problema distribuido, generado en el diseño de la arquitectura multiagente, en el cual, los agentes comparten metas y el problema es dividido en pequeñas tareas compartidas dentro de la sociedad de agentes. En este caso, la metodología lleva a un modelo de sociedad de agentes, basado en el paradigma de suscripción-publicación. La sociedad de agentes está compuesta por los siguientes objetos: agentes, que son los objetos activos, y pizarras, o entidades pasivas en la sociedad.

3.12. Análisis General de las Metodologías

Después de analizar las principales metodologías y propuestas para diseñar SMA se puede afirmar lo siguiente:

- La mayoría de las metodologías contemplan las etapas de análisis y diseño. En el análisis se concentran en especificar los requerimientos, tanto funcionales como no-funcionales. Dentro del diseño generalmente contemplan el diseño del sistema y el diseño de la arquitectura interna del agente.

- Es común encontrar que el enfoque de la mayoría de las metodologías sea top-down y que mantengan un ciclo de vida iterativo e incremental.

32

- La metodología Tropos es la única que contempla un análisis de requerimientos tempranos, en donde involucra a todos los stakeholders que hacen parte del problema y establece las primeras dependencias. Posteriormente, en la etapa de requerimientos tardíos modela el sistema como tal, especificando los actores y las dependencias entre ellos.

- Una característica común a todas las metodologías es el soporte en modelos que ayudan gráficamente a especificar el SMA. Entre estos se encuentran modelos donde se especifican actores dentro de un ambiente, otros muestran las relaciones entre los actores, otros especifican aún más integrando metas, eventos, recursos y planes.

- En la metodología Tropos se propone el uso de patrones organizacionales, que se resume en el modelamiento de las organizaciones, es decir grupos, estructuras jerárquicas, etc., que representan a la organización en el mundo real.

- Algunas metodologías introducen el uso de diagramas de AUML para mostrar las interacciones entre los agentes, como lo hace la metodología Prometheus.

- Algunas metodologías como Tropos, Prometheus, y la propuesta ADS de Félix Ramos [RAMO2004], integran una fase de implementación, que realizan con herramientas o plataformas de agentes, que no están atadas a la metodología.

- La metodología Prometheus se destaca principalmente por la generación de los artefactos que brindan una mejor especificación de los detalles del sistema que se está construyendo.

- Prometheus difiere de otras metodologías en que no define roles de forma explícita. En vez de ello define funcionalidades que luego son agrupadas en agentes, para luego combinarlas con los planes, metas recursos, etc.

- Otro concepto interesante en el campo de las metodologías son los metamodelos. Tropos ha incluido los metamodelos, con el fin de explicar mejor la metodología y hacer la transición más fácil desde el paradigma de objetos hacia el paradigma de agentes.

- James Odell [ODEL2004a] propone un metamodelo interesante en el que relaciona a los agentes, grupos y clasificador de agentes. Los agentes son clasificados en primera instancia de acuerdo a sus características básicas (como el esqueleto de los agentes) y por los roles que puede tomar en distintos tiempos. Finalmente los interrelaciona en grupos que pueden ser agentizados (es decir vistos como un sólo agente que agrupa a varios) o no-agentizados (vistos como un grupo de agentes).

- Pocas metodologías manejan el concepto de roles dinámicos, James Odell en [ODEL2004b] introduce este concepto para el manejo de roles. Allí se propone que los roles se ganen debido a un suceso dentro del sistema o se activen y se pasiven según las tareas que hace el agente.

3.13. REFERENCIAS BIBLIOGRÁFICAS

[AGUI2001] Aguirre P.Z.S. “Modeling of Dynamic Organizations for CSCW” Master dissertation, Dept. Electric Engineering, CINVESTAV-IPN, Guadalajara Mexico, 2001

[ALON2004] Alonso, F., Frutos, S., Martínez, L., and Montes, C. (2004). Sonia: A methodology for natural agent development. ESAW’2004 - 5th Intl. Workshop on Engineering in the Agents World.

33

[BAUE2005] Bauer, B., Odell, J., UML 2.0 and agents: how to build agent-based systems with the new UML Standard, Journal of Engineering Applications of Artificial Intelligence Volume 18, Issue 2 , March 2005

[BRES2004] Bresciani, P., Perini, A., Giorgini, P., Giunchiglia, F., and Mylopoulos, J. (2004). Tropos: An agent-oriented software development methodology. Autonomous Agents and Multi-Agent Systems, 8(3):203–236.

[CHAN2004] Chan,K., Sterling, L., Adapting Roles for Agent-Oriented Software Engineering, Disponible en: http://citeseer.ist.psu.edu/chan04adapting.html (Ultima Visita Nov. 2005)

[DAST2004] Dastani, M., Hulstijn, J., Dignum, F., and Meyer, J.-J. C. (2004). Issues in multiagent system development. In AAMAS ’04: Proceedings of the Third International Joint Conference on Autonomous Agents and Multiagent Systems, pages 922–929, Washington, DC, USA. IEEE Computer Society.

[DELO2000] DeLoach, S. A., W. M. F. (2000). Multiagent systems engineering: the analysis phase. Technical report, Air Force Institute of Technology.

[DELO2001] DeLoach, S.A., Specifying Agent Behavior as Concurrent Tasks, Autonomous Agents 2001, 2001.

[DELO2002] DeLoach, S.A., Analysis and Design of Multiagent Systems Using Hybrid Coordination Media, Proceedings of the World Multiconference on Systemics, Cybernetics and Informatics, 2002.

[FUXM2001] Fuxman, A.; Pistore, M.; Mylopoulos, J.; Traverso, P., Model checking early requirements specifications in Tropos, Proceedings. Fifth IEEE International Symposium on Requirements Engineering, 2001

[FUXM2003] Fuxman, A., Liu, L., Pistote, M., Roveri, M., Mylopoulos, J., Specifying and Analyzing Early Requirements: Some Experimental Results, Procedings of ICRE'03, 2003.

[GIOR2004] Mouratidis, H.; Giorgini, P., Enhancing secure Tropos to effectively deal with security requirements in the development of multiagent systems, : Proceedings of the Third International Joint Conference on Autonomous Agents and Multiagent Systems - AAMAS’2004, 2004

[GIUN2002] Giunchiglia, F., Mylopoulos, J., and Perini, A. (2002). The tropos software development methodology: Processes, models and diagrams. In Inproceedings of AOSE02.

[IEEE2004] IEEE Computer Society, Guide to the software engineering body of knowledge : 2004 version, Ed. Alain Abran, James W. Moore, 2004

[IGLE1998] Iglesias, C. A., Garijo, M., González, J. C., and Velasco, J. R. (1998). Analysis and design of multiagent systems using mas-commonkads. In Woldridge, M., S. M. y. R. A., editor, INTELLIGENT AGENTS IV: Agent Theories, Architectures and Languages, Lecture Notes in Computer Science, 1365, pages 313 – 327. Springer-Verlag.

[JENN2000] Jennings N.R., “On Agent-Based Software Engineering”, Journal Artificial Intelligence, volume 177, number 2, pages 277-296, 2000.

[MOUR2003] Mouratidis, H., Giorgini, P., and Manson, G. (2003). Modelling secure multiagent systems. In AAMAS ’03: Proceedings of the second international

34

joint conference on Autonomous agents and multiagent systems, pages 859–866, New York, NY, USA. ACM Press.

[MOUR2002] Mouratidis, H., Giorgini, P., Manson, G., and Philp, I. (2002). A natural extension of tropos methodology for modelling security. In Proceedings of the Agent Oriented Methodologies Workshop (at the OOPSLA 2002), Seattle - USA.

[MOUR2004] Mouratidis, H.; Giorgini, P., Enhancing secure Tropos to effectively deal with security requirements in the development of multiagent systems, AAMAS’2004, 2004

[ODEL2004a] Odell, J., Nodine, M. H., and Levy, R. (2004). A metamodel for agents, roles, and groups. In AOSE, pages 78–92.

[ODEL2004b] Odell, J.; Van Dyke, H.; Breuckner, S.; Fleischer, M., Temporal Aspects of Dynamic Role Assignment, Lecture Notes on Computer Science volume 2935, 2004.

[PADG2002] Padgham, L. and Winikoff, M. (2002). Prometheus: A methodology for developing intelligent agents. In Proceedings of the Third International Workshop on AgentOriented Software Engineering, Bologna - Italy. AMMAS.

[PENS2004] Penserini, L.; Kolp, M.; Spalazzi, L.; Panti, M., Socially-based design meets agent capabilities, Proceedings of the IEEE/WIC/ACM International Conference on Intelligent Agent Technology (IAT’04), 2004.

[RAMO2004] Ramos, F. F. (2004). Methodology for analysis and design of systems. In WSTFEUS, pages 80–84.

[SALC2002] Salcedo, P. (2002). Commonkads y el lenguaje de modelado unificado - uml. Artículo de la Revista DIICC-Revista Informática, Disponible en: http://www.inf.udec.cl/revista/down08.html.

[SCHR1994] A. Th. Schreiber, B. J. Wielinga, J. M. A. W. V. d. V. (1994). Commonkads: A comprehensive methodology for kbs development. Deliverable DM1.2a KADSII/M1/RR/UvA/70/1.1, University of Amsterdam.

[SCHR1999] Schreiber, G., Akkermans, H., Anjewierden, A., de Hoog, R., Shadbolt, N., Velde, W. V. D., and Wielinga, B. (1999). Knowlede Engineering and Management: The CommonKADS Methodology. MIT Press.

[SUDE2004] Sudeikat, J., Braubach, L., Pokahr, A., and Lamersdorf, W. (2004). Evaluation of agent-oriented software methodologies – examination of the gap between modeling and platform. In AOSE, pages 126–141.

[SUTA2004] Sutandiyo, W.; Chhetri, M.B.; Krishnaswamy, S.; Loke, S.W., Experiences with software engineering of mobile agent applications, Proceedings Australian Software Engineering Conference, 2004

[TIAN2004] Tian, J., Foley, R., and Tianfield, H. (2004). A new agent-oriented development methodology. In IAT ’04: Proceedings of the Intelligent Agent Technology, IEEE/WIC/ACM International Conference on (IAT’04), pages 373–376, Washington, DC, USA. IEEE Computer Society.

[TORR2004] Torres da Silva, V., Choren, R. and J. P. de Lucena , C., A UML Based Approach for Modeling and Implementing Multi-Agent Systems, ACM, 2004.

35

[YU1997] Yu, E. S. (1997). Towards modelling and reasoning support for earlyphase requirements engineering. In International Symposium on Requirements Engineering, pages 226–235, Annapolis, Maryland.

[ZAMB2003] Zambonelli, F., Jennings, N. R., and Wooldridge, M. (2003). Developing multiagent systems: The Gaia methodology. ACM Trans. Softw. Eng. Methodol., 12(3):317–370.