3.

METODOLOGAS POA
La construccin de un Sistema MultiAgente (SMA), implica una visin diferente en
trminos del proceso de desarrollo de software requerido para su implementacin. Este
debe incluir y tener en cuenta las caractersticas intrnsecas de los agentes, un conjunto
de entidades autnomas cooperativas. Estas caractersticas permiten la resolucin de
problemas complejos, e implican adems la creacin o adecuacin de metodologas para
el desarrollo de sistemas basados en agentes, denominadas de manera genrica
Programacin Orientada a Agentes (POA). Estas metodologas deben incorporar
actividades y artefactos que permitan identificar y asociar las caractersticas 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
solucin que se adapte al continuo cambio de los procesos dentro de una organizacin o
cuando no se presenta un comportamiento autnomo que permita resolver problemas con
mayor facilidad, dando como resultado mayor supervisin humana. De acuerdo con
Zambonelli [ZAMB2003], las actuales aplicaciones de software estn tendiendo a ser ms
complejas, manejando aspectos como el uso de recursos de manera distribuida,
manteniendo altos estndares de disponibilidad y manejo de concurrencia, buscando la
manera de ser ms autnomas y reconfigurables en los ambientes donde se hayan
desplegado, adaptndose a de los cambios que se puedan presentar en tiempo real.
Aunque los desarrollos contemporneos basados en el paradigma orientado a objetos
pueden llegar a satisfacer las necesidades actuales de estas aplicaciones, los SMA se
perfilan como la opcin ideal para desarrollar nuevos sistemas basndose en POA y
superando en varios aspectos a las aplicaciones desarrolladas con otros paradigmas. Por
ejemplo, la autonoma de las entidades (agentes), que conforman los SMA, forman grupo
y actan 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 tambin con recursos externos a ellos de forma concurrente, manejando los
conflictos, distribuyendo tareas y percibiendo el ambiente donde se enmarcan los SMA.
Sin embargo, slo existe una limitante para que la POA y los SMA lleguen a ser tan
utilizados como el paradigma orientado a objetos y bsicamente 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 aos y ha tenido mucha
aceptacin entre diseadores y desarrolladores de software, muchas herramientas,
lenguajes de programacin y metodologas han sido desarrolladas, las cuales han
impulsado la popularizacin de ste paradigma. Segn Mouratidis, para que los SMA
empiecen a tener una mayor aceptacin y uso dentro de la comunidad diseadora y
desarrolladora de software es necesario que se desarrollen tcnicas de ingeniera de
software que sean enfocadas especialmente hacia ellos [MOUR2003].
Dentro del desarrollo de este captulo, para motivar an ms el aprendizaje y
popularizacin de POA y los SMA, se resaltarn las principales caractersticas de las
metodologas para SMA y su relacin con la disciplina de la ingeniera de software.

Posteriormente, se describirn los tipos de metodologas para desarrollar SMA y

finalmente se introducirn las metodologas ms importantes en el contexto de los SMA.

3.1.

Caractersticas Generales de las Metodologas para Desarrollar SMA

Una metodologa de construccin 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 caractersticas de calidad que permitan la mantenibilidad y soporte
de un sistema durante su etapa de operacin. Las actividades describen el proceso a
llevar a cabo para construir uno o ms artefactos que pueden ser: documentos,
diagramas, modelos, programas, planes, etc. stos soportarn otras actividades del
proceso de desarrollo o simplemente permitirn la supervisin y seguimiento del proceso.
Una metodologa ayuda entonces al desarrollo de un sistema por medio de:
-

La gua a travs de un proceso de ciclo de vida, actividades y secuencia de las

mismas.

El conjunto de tcnicas predefinidas, lineamientos, heursticas, etc.

El modelado del problema a travs de una notacin formal.

Disear sistemas complejos no es una tarea fcil, los SMA son una de las principales
soluciones para realizar esta labor. Sin embargo, para desarrollar aplicaciones basadas
en agentes, es necesario tambin desarrollar mtodos prcticos, que permitan establecer
los pasos necesarios para definir correctamente un SMA.
La importancia de las metodologas para el diseo de SMA, radica en la definicin formal
de cada una de las actividades que se deben llevar a cabo dentro de un proceso
metodolgico y que permiten la difusin del paradigma POA. A continuacin se introducen
los principales lineamientos que se deben tener en cuenta en una metodologa para
desarrollar un SMA, as como tambin se resalta la relacin con la ingeniera de software
y se presenta un vistazo a los principales problemas que surgen en el momento de
modelar un SMA.
Lineamientos de las Metodologas para SMA
Segn Alonso [ALON2004], una buena metodologa para el desarrollo de SMA debe
definir un modelo genrico de anlisis independiente de la plataforma, y un modelo de
diseo que permita identificar los agentes de forma sistemtica, 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 mayora de las implementaciones de SMA son
realizadas usando tecnologas orientadas a objetos por medio del uso de plataformas
superpuestas al lenguaje, proporcionando un nivel de abstraccin hacia el SMA que
resulta en una mayor facilidad para la implementacin y comprensin por parte de los
desarrolladores.
Otros autores como Sudeikat [SUDE2004], proponen que en el momento de evaluar
metodologas orientadas a agentes se debe tener en cuenta la plataforma en la cual se
har la implementacin, en contra posicin con Alonso [ALON2004], puesto que dicha
plataforma implica restricciones adicionales que deben ser tenidas en cuenta en el
anlisis y diseo del SMA. Por esta razn Sudeikat, presenta una estrategia que permite
interrelacionar a las metodologas con las plataformas, mediante la evaluacin de ciertos

criterios tanto de las plataformas como de las metodologas, que simplifican este proceso
de clasificacin.
En la actualidad existen varias metodologas 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 metodologa de desarrollo orientada a agentes
debera poseer las siguientes caractersticas:
-

No se debera forzar a la utilizacin de una metodologa basada en el paradigma de

los agentes desde la fase de anlisis.

Debera llevar naturalmente a la conclusin de si es factible o no solucionar un

problema con el paradigma POA.

Debera identificar sistemticamente los componentes del SMA.

Si el problema requiere una sociedad de agentes, debera guiar de manera natural al

uso de un modelo organizacional.

Debera producir agentes reutilizables, ser de fcil aplicacin y no requerir

conocimientos muy avanzados en agentes.

En cuanto a metodologas Sudeikat [SUDE2004] define los siguientes criterios, que

complementan las cinco caractersticas fundamentales que se introdujeron anteriormente:
-

Facilidad de uso notacin intuitiva y comprensible, fcil 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 identificacin de relaciones entre los mismos.

Definicin clara la semntica y sintaxis de un lenguaje de formalizacin y de las

caractersticas de la metodologa 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, anlisis, diseo, implementacin y pruebas).

Administrable administracin de un proyecto de software orientado a agentes con

heursticas y lineamientos.

Complejidad la complejidad del proceso mide el esfuerzo necesario para aprender a

usar la metodologa.

Enfoque del proceso definicin si tiene un enfoque iterativo, lineal, top-down, botomup, etc.

Soporte a herramientas como por ejemplo herramientas CASE o de diagramacin

para la metodologa.

Documentacin tanto de la metodologa, como de los artefactos y herramientas

asociadas, tiene un gran impacto en el uso y apropiacin de la metodologa.

Uso en proyectos para juzgar la madurez de la metodologa.

Otro criterio que no se considera en el trabajo de Sudeikat [SUDE2004], pero es vlido

para integrar tanto a las metodologas como a las plataformas es el de la seguridad.
Algunos elementos asociados a dicho criterio son:
-

Aplicacin de patrones de seguridad.

Modelo de la seguridad integrada a la metodologa o a la plataforma.

Pruebas de seguridad que puedan ser fcilmente definidas en el momento del diseo
y la implementacin.

Relaciones de confianza y dependencias, posesin de recursos y derechos sobre

recursos.

UML y Extensiones
En general, cuando se habla de enfoques y metodologas, es necesario el uso de algn
tipo de notacin grfica que permita representar vistas y modelos generados durante las
etapas de anlisis y diseo. Algunas de estas metodologas 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 precisin en el
modelo.
En el primer frente se encuentra la propuesta de Bauer y Odell [BAUE2005], que se apoya
en el amplio reconocimiento del estndar UML para proponer su utilizacin en el campo
de los agentes, fundamentando que de esta manera la transicin del diseo orientado a
objetos al diseo orientado a agentes ser mucho ms fcil.
Torres [TORR2004], propone una extensin a UML llamada MAS-ML basada en el
framework TAO (Taming Agents and Objects). Las extensiones son puramente de adicin,
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 tambin
los diagramas de clase para representar las relaciones entre agentes, entre agentes y
clases y entre ambientes con ambientes y clases. Otros diagramas estticos incluyen el
de Organizacin y el de Roles. En el terreno de los diagramas dinmicos, el diagrama de
secuencia es modificado. Por ltimo, MAS-ML tiene asociada la herramienta MASML2Java para transformar los diagramas y generarlos en cdigo Java. La herramienta fue
creada utilizando el lenguaje TXL.
Tambin se han propuesto lenguajes formales para la estandarizacin como AUML
[ODEL2004a], derivado de UML o los estndares propuestos por FIPA, como por ejemplo
los especificados para la interaccin entre agentes ACL, Agent Communication Language.
Muchas de las metodologas desarrollan herramientas alternas como plataformas o
herramientas CASE que ayudan a popularizar el uso de stas para el diseo de SMA y
proporcionan una base ms slida soportndose en los lineamientos propuestos por la
ingeniera de software.
En general, UML y sus extensiones ofrecen recursos exclusivamente representacionales,
que no ofrecen mecanismos para el anlisis y diseo de SMA.
Problemas en el Modelado de un SMA
1

Un tipo de dato definido para modelar caractersticas de datos de objetos del mundo real.

En general, una metodologa de desarrollo de SMA, debera, adems de tener en cuenta

el entorno, proporcionar bases slidas para las fases de anlisis, diseo e
implementacin, indicando como los conceptos de diseo deben ser llevados a las
rdenes de un lenguaje determinado. En este orden de ideas Dastani, et.al. [DAST2004],
identifica algunos tpicos que suelen ser problemticos con las metodologas existentes:
1. No existe un acuerdo en la forma en que se deben identificar y caracterizar los
roles en la fase de anlisis y los tipos de agentes en la fase de diseo.
2. Los conceptos utilizados en las diferentes metodologas, como responsabilidad,
permisos, metas y tareas, no tienen una semntica formal o propiedades formales
explcitas.
3. Existe una brecha entre los modelos de diseo y los lenguajes de desarrollo
existentes. Para reducir esta brecha, una metodologa debe incluir refinamientos
en los modelos de diseo de modo que puedan ser implementados de forma
directa en algn lenguaje de programacin disponible.
4. Las metodologas que incluyen una fase de implementacin como
Tropos[BRES2004][GIUN2002], proponen un lenguaje de implementacin en el
cual no se explica como implementar el razonamiento acerca de las creencias,
metas, planes y comunicacin.
5. Un agente puede representar diferentes roles. En ninguna de las metodologas se
tiene en cuenta este hecho.
6. En general, las metodologas ignoran las normas organizacionales y no explican
como especificarlas y disearlas.
7. Los sistemas abiertos no son realmente soportados. Durante el anlisis, diseo e
implementacin, las entidades deben ser preconcebidas.

3.2.

Tipos de Metodologas

Existen muchas metodologas, todas ellas se enmarcan dentro del ciclo de vida del
software, la mayora de ellas abarcan las fases de anlisis y diseo, otras se extienden
hasta las etapas de implementacin y verificacin o trabajan en conjunto con alguna
plataforma desarrollada propiamente para la metodologa o con otras ms genricas. La
mayora de metodologas, proponen una serie de artefactos que formalizan el diseo de
los SMA, incluyendo diagramas y entregables que definen correctamente cada una de las
etapas que se incluyan en el proceso.
Segn Dastani [DAST2004], las metodologas para el desarrollo de SMA deberan ayudar
al desarrollador en la toma de decisiones sobre aquellos aspectos del anlisis, diseo e
implementacin que son cruciales para un SMA. Hoy en da, existe un gran nmero de
estas metodologas, las cuales difieren en muchos aspectos como por ejemplo: en las
fases de desarrollo que utilizan y cmo las utilizan, otras se enfocan en aspectos de
comunicacin entre agentes, mientras que otras lo hacen en el comportamiento interno de
cada agente; otras tienen adems en cuenta el entorno.
Alonso [ALON2004] propone una taxonoma para organizar dichas metodologas en tres
categoras: metodologas basadas en agentes; metodologas basadas en el paradigma de
orientacin a objetos y finalmente metodologas basadas en el paradigma de la ingeniera
del conocimiento.
En las siguientes subsecciones se explica brevemente esta clasificacin de las
metodologas para SMA y se enuncian algunas de las metodologas ms importantes que

pertenecen a cada una de las clasificaciones. Posteriormente, a partir de la seccin 3.3,

se introducen brevemente las metodologas ms representativas de los SMA,
concentrndose principalmente en el proceso metodolgico que cada una de ellas
describe.
Metodologas basadas en agentes
Estas metodologas se basan en la abstraccin de niveles sociales como grupos u
organizaciones y que han ganando bastante terreno en el campo de la especificacin de
SMA, sin embargo, tienen algunas caractersticas:
-

Estas metodologas proponen la utilizacin del paradigma de agentes para las fases
de especificacin y diseo, pero la mayora no tienen en cuenta la utilizacin de un
modelo de anlisis genrico que pueda ser utilizado para evaluar si una aproximacin
basada en agentes es adecuada o no.

Las metodologas 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 metodologas:
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 metodologas:

Prometheus, Tropos, SODA, Styx, Gaia, HLIM, Casiopea, entre otras.
Metodologas Basadas en Ingeniera de Software Orientada a Objetos
En las metodologas 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 abstraccin mayor, y adems, fallan al no plantear claramente el comportamiento
autnomo de los agentes, sus interacciones y las estructuras organizacionales.
Estas metodologas se caracterizan por extender el paradigma del anlisis y diseo
orientado a objetos. Desde el punto de vista del diseo de SMA, estas metodologas
tienen algunos problemas recurrentes como: no tener en cuenta un modelo genrico de
anlisis, slo algunas identifican agentes durante el anlisis, no cubrir los aspectos
referentes a la estructura social del sistema y no tener en cuenta las caractersticas del
ambiente. Visto de una forma ms general, estas metodologas tratan a los agentes como
objetos complejos, reduciendo el nivel de abstraccin real que tienen los agentes.
Dentro de este grupo Alonso [ALON2004] clasifica las siguientes metodologas: ODAC,
MaSE, MASSIVE, DESIRE, AAII, AOMEM, AOAD, MASB.
Metodologas Basadas en Ingeniera del Conocimiento
Estas metodologas se caracterizan por el nfasis en la identificacin, adquisicin y
modelado del conocimiento utilizado por los agentes. Las metodologas ms
representativas son extensiones de la metodologa de desarrollo de sistemas basados en
conocimiento CommonKADS [SCHR1999]. Dentro de este grupo Alonso [ALON2004] y
Sudeikat [SUDE2004] clasifican las siguientes metodologas: MAS-CommonKADS y
CoMoMAS.

En general, las metodologas que utilizan directamente la tecnologa de agentes pueden

ser mejores que las otras dos, debido a que se basan en los conceptos de agentes y de
organizacin de agentes en un SMA, aunque tienden a confinar cualquier problema a este
paradigma, an si este no es apropiado para resolverlo.

3.3.

Metodologa Tropos

Tropos es una metodologa 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 metodologas que ms impacto ha tenido en el rea de los SMA y ha sido
desarrollada desde mediados de los aos 90s, donde se ha venido refinando y ampliando
su formalismo y extensin en las etapas de ingeniera de software.
La metodologa 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 nocin 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 metodologas
que mejor explica los conceptos relacionados a los SMA como son actor, meta,
dependencia, plan, recurso, capacidad y creencia.
Como metodologa Tropos se encuentra bien estructurada y define claramente diagramas
que permiten disear un SMA de forma didctica. Parte de una visin 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 definicin de capacidades para cumplir las
metas. Las interacciones son identificadas desde las primeras fases de la metodologa, lo
cual implica que se debe tener un anlisis exhaustivo de los requerimientos.
Etapas de la Metodologa Tropos
La metodologa Tropos tiene cuatro etapas denominadas: requerimientos tempranos y
tardos, diseo arquitectnico y diseo detallado, que fueron las descritas en los trabajos
de Mouratidis [MOUR2002], [MOUR2003]; sin embargo, en los trabajos ms recientes de
Bresciani [BRES2004] y Giunchiglia [GIUN2002], se adiciono una quinta fase llamada
implementacin.
-

Anlisis de Requerimientos Tempranos y Tardos: el principal objetivo en esta etapa

es proporcionar un conjunto de requerimientos funcionales y no-funcionales para el
sistema. La diferencia entre estos anlisis de requerimientos radica en que en la etapa
de requerimientos tempranos, el diseador modela el sistema de forma general
incluyendo a los stakeholders2 principales y estableciendo las primeras dependencias.
Mientras que en la etapa de requerimientos tardos, el diseador modela el sistema
como tal integrando a todos los actores y especificando sus dependencias.

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

Diseo Arquitectnico: en esta etapa se define la arquitectura global del sistema en

trminos 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.

Diseo Detallado: durante la etapa de diseo detallado el desarrollador especifica en

detalle los agentes, sus metas, creencias y capacidades as como tambin la
comunicacin entre ellos.

Implementacin: finalmente en la etapa de implementacin, todos los artefactos

producidos en la etapa de diseo detallado son transformados en el esqueleto de la
implementacin y se hace mediante un mapeo de lo construido por la metodologa 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 anlisis temprano de
requerimientos y se van refinando a medida que se va avanzando en las dems etapas de
la metodologa. 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 metodologa.

Modelo de Dependencias: incluye la identificacin 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 anlisis de las metas de los actores,
usando tres tcnicas 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 terminacin satisfactoria de una meta por
analizar. El tercero descompone una meta raz en otras metas aplicando predicados
AND/OR.

Modelado de Planes: permite incorporar una tcnica adicional a las propuestas en el

modelado de metas; es similar en cuanto a las tcnicas de razonamiento propuestas
anteriormente.

Modelado de Capacidades: se construye al final de la etapa de diseo arquitectnico,

cuando los subactores del sistema han sido especificados en trminos de sus propias
metas y dependencias con otros actores.

La metodologa Tropos ha definido tambin un metamodelo que resume la concepcin de

la metodologa 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 metodologa.

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

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

Extensiones a la Metodologa Tropos

Otros autores tambin han propuesto extensiones a la metodologa Tropos, como por
ejemplo la descripcin de un lenguaje para la formalizacin 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
formalizacin es encontrar brechas e inconsistencias en los requerimientos tempranos
que evitan problemas en etapas posteriores de la metodologa.
En cuanto al diseo de SMA con un enfoque organizacional, Penserini [PENS2004],
propone utilizar patrones de diseo sociales que sean capaces de modelar la
organizacin de un SMA. stos son similares a los patrones de diseo que se pueden
aplicar para disear 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 cules son las conductas sociales de todos los involucrados dentro del proceso
de transformacin de las materias primas a productos, luego de analizar dichas conductas
aplicar Patrones de Diseo Sociales que puedan representar la organizacin 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 ms adecuadas y
si no se realiza un estudio riguroso se podra estar llevando procesos ineficientes a un
SMA. Para no cometer esos errores se puede complementar el estudio con
aproximaciones organizacionales heredadas de la teora administrativa.
Otro de las extensiones ms representativas de la metodologa Tropos se ha realizado es
en el rea de seguridad, requerimiento que casi no es tenido en cuenta por las

10

metodologas para disear 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 extensin de la metodologa Tropos que maneja los requerimientos de
seguridad; la aproximacin considera los problemas de seguridad a travs 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 bsicamente ha utilizado los conceptos definidos por la metodologa y se han
conjugado con las caractersticas de seguridad. Tambin se definieron nuevos diagramas
adicionales a los que propone originalmente Tropos para formalizar Secure Tropos, pero
que conservan una relacin cercana a los existentes. En este trabajo, se enfatiz en dar
solucin 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 integracin entre las disciplinas sea
ms difcil.

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

En el trabajo de Mouratidis [MOUR2004], surgi la necesidad de extender aun ms a

Secure Tropos para dar solucin a los siguientes dos problemas:
-

Llevar un conjunto de requerimientos de seguridad al diseo, donde es difcil obtener

evidencia emprica de los problemas de seguridad.

Probar a nivel de diseo una solucin de seguridad adoptada.

Con el fin de solucionar estos problemas Mouratidis [MOUR2004], propone 3

subactividades que son: la seleccin de una arquitectura para la solucin 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
diseo y por ltimo crear escenarios de seguridad para probar una solucin de seguridad
implementada.
Otro aporte importante en el rea de seguridad lo realiza Giorgini [GIOR2004]. La idea
bsica 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.

Metodologa Prometheus

Prometheus es una metodologa para disear agentes inteligentes desarrollada en

colaboracin con Agent Oriented Software Group3 y se ha aplicado en la industria y en las
universidades. Esta metodologa segn Padgham [PADG2002], se caracteriza por ser
3

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

11

detallada y completa en el sentido que cubre las actividades requeridas para desarrollar
sistemas multiagente inteligentes, abarcando desde el anlisis de requerimientos hasta la
implementacin, donde se ha integrado el framework JACK [HOWD2001]. La metodologa
se caracteriza por asistir a los desarrolladores para disear, documentar y construir un
SMA completo.
De acuerdo con Padgham [PADG2002], Prometheus difiere de otras metodologas en las
siguientes apreciaciones:
-

Soporta el desarrollo de agentes inteligentes que usan metas, creencias, planes y

eventos, basndose en el desarrollo de agentes BDI.

Proporciona un soporte desde la especificacin hasta la implementacin con un

proceso detallado.

Proporciona mecanismos de estructuracin jerrquicos para mltiples niveles de

abstraccin.

Utiliza un proceso iterativo durante el desarrollo de las etapas de ingeniera de

software.

Ha sido probada en la industria y en la educacin con gran xito.

Fases de la metodologa
La metodologa Prometheus consiste en tres fases. La primera es la Especificacin del
Sistema, donde se identifican las principales funcionalidades del mismo, las entradas
(percepciones), las salidas (acciones) y fuentes de datos compartidos. La segunda fase,
Diseo Arquitectnico, utiliza las salidas, especificadas anteriormente, para determinar
que agentes contendr el sistema y sus interacciones. La tercera fase, Diseo 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 metodologa Prometheus. A
continuacin se describe en detalle cada una de las fases.

12

Figura 3-3. Fases de la metodologa Prometheus, adaptado de [PADG2002].

Especificacin del Sistema: en esta fase se inicia con la descripcin funcional del
SMA. Para definir correctamente esta funcionalidad se debe especificar el tipo de
informacin que es requerida e informacin adicional que sea producida.
Paralelamente se debe entender cmo el SMA interactuar con el ambiente. El flujo
de informacin que llega del ambiente y es captado por el agente se llama percepcin
y los mecanismos para afectar el ambiente son llamados acciones. Tambin 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 metodologa. El
primero de ellos es el Descriptor de Funcionalidad, que contiene la informacin de
percepcin, accin e interaccin con el ambiente. El segundo artefacto utilizado para
proporcionar una visin ms holstica del sistema, son los Escenarios de Casos de
Uso.

Diseo Arquitectnico: en esta fase se definen los agentes que existirn 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.

13

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 estarn en el sistema se inicia una descripcin
detallada de cada uno de ellos mediante un artefacto llamado Descriptor de Agentes,
el cual contiene la informacin sobre funcionalidad, datos e interacciones.
Adicionalmente en esta fase se debe identificar que eventos sern generados como
resultado de la informacin del ambiente. Para lograr las metas del sistema los
agentes deben comunicarse enviado mensajes unos a otros, actividad que tambin
debe especificarse en esta etapa. Adems de la comunicacin entre los agentes se
debe identificar los Objetos de Datos Compartidos para relacionar a todos los agentes
que utilicen recursos y que necesiten especificar tcnicas de sincronizacin. Estos
objetos de datos compartidos, pueden ser descritos utilizando POO. En esta fase se
incluye la definicin del Diagrama de Descripcin 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 diseados en la fase de
especificacin del sistema y se construyen los diagramas de interaccin.
Finalmente, para definir an ms las interacciones del sistema a partir del diagrama de
interacciones se genera el Diagrama de Interaccin de Protocolos, que describe las
secuencias de interacciones vlidas dentro del sistema.
-

Diseo Detallado: esta fase se concentra en desarrollar la estructura interna de cada

uno de los agentes y definir cmo cada uno de ellos lograrn 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 especificacin del sistema proporcionan un buen conjunto inicial para definir
las capacidades del agente, que luego de varios refinamientos, quedarn descritas en
trminos de los planes eventos y datos.
Cada capacidad debe ser descrita utilizando un Descriptor de Capacidades, que
contiene la informacin que especifica el comportamiento de lo que puede hacer y
cmo reacciona un agente ante un evento.
Para describir grficamente las capacidades se utiliza el Diagrama de Descripcin 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 implementacin.
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 metodologa.

3.5.

Metodologa Gaia

De acuerdo con Zambonelli [ZAMB2003], un SMA, puede ser naturalmente visto y

construido como una organizacin computacional. La visin tradicional de un SMA dice
que puede ser concebido en trminos de una sociedad organizada de individuos, en la

14

que cada agente juega un rol especfico e interacta con otros agentes de acuerdo a
protocolos determinados por los roles.
Sin embargo, esta visin debe profundizarse ms, porque se debe asumir que la
organizacin es ms que una simple coleccin de roles y para construir efectivamente un
SMA en trminos organizacionales, las abstracciones orientadas a las organizaciones
necesitan ser identificadas y ubicadas en el contexto de la metodologa. Por esta razn
los esfuerzos de Zambonelli, van encaminados a identificar esas abstracciones
organizacionales y extender la metodologa Gaia.
La Metfora Organizacional
El trabajo de Zambonelli, se concentra en desarrollar de sistemas medianos y grandes,
posiblemente divididos en ambientes abiertos y dinmicos garantizando predictibilidad y
comportamientos confiables. En este contexto define al sistema como la instancia
computacional de un grupo de individuos interactuantes y autnomos (agentes). Cada
agente juega uno o ms roles especficos, 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 organizacin 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 ms. 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 visin micro y macro, para el comportamiento
de los agentes y el sistema.

Figura 3-4. SMA como una organizacin 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 sern despus integradas como extensin a la metodologa Gaia.

15

stas son en su orden: el ambiente, los roles, las interacciones, las reglas
organizacionales y las estructuras organizacionales, que son presentadas a continuacin.
-

El Ambiente: un SMA siempre est situado en un ambiente. Zambonelli considera que

sta debe ser la primera abstraccin en las etapas de anlisis y diseo. Identificar y
modelar el ambiente envuelve la determinacin de las entidades y recursos que el
SMA puede explotar, controlar o consumir cuando se trabaja hacia la satisfaccin de
una meta organizacional. Adicionalmente el ambiente no debe ser implcitamente
asumido, sus caractersticas deben ser identificadas, modeladas y posiblemente
relacionadas a los propsitos especficos de las aplicaciones.

Roles e Interacciones: los roles de un agente definen lo que se espera que haga
dentro de la organizacin. Dan al agente una posicin bien definida dentro de la
organizacin con una asociacin 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 bsicas (funcionalidades y competencias), requeridas por la
organizacin, as como tambin las interacciones bsicas requeridas para la
explotacin de esas habilidades. Antes de caracterizar totalmente la organizacin, el
anlisis del SMA debe identificar las restricciones que la organizacin actualmente
tiene, para que con ese conjunto de reglas organizacionales se pueda modelar
correctamente el sistema.
Esta identificacin de las reglas organizacionales permite definir explcitamente:
1. Cuando permitir a nuevos agentes entrar a la organizacin y una vez aceptados
establecerles que posicin ocuparn.
2. Tambin debe permitir identificar que comportamientos deben ser considerados
legtima expresin de intereses propios y debe permitir identificar cules de dichos
comportamientos deben ser prevenidos por la organizacin.
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

organizacin y sus posiciones en la organizacin, implcitamente define la topologa de
interaccin y el rgimen 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 construccin de software siempre trae cambios en la
organizacin 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 organizacin, sta debe respetar sus reglas
organizacionales, empezando por su estructura organizacional.

16

Etapas de la Metodologa Gaia

Teniendo en cuenta los conceptos bsicos introducidos anteriormente, se puede definir
formalmente la metodologa Gaia. En la Figura 3-5, se ilustran todos los pasos de la
metodologa incluyendo aquellos que se introdujeron en la extensin propuesta por
Zambonelli [Zamb2003]. El proceso inicia con la fase de requerimientos, los cuales
pueden recolectarse usando algn mtodo tradicional de la ingeniera de software. A
continuacin en fase de anlisis, se identifican las metas de la organizacin y se
constituye como ser el comportamiento global del sistema; la organizacin 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 organizacin debe respetar y reforzar en su comportamiento global.
La siguiente fase es el diseo arquitectnico, que involucra la definicin de la estructura
organizacional del sistema en trminos de la topologa, el rgimen de control y la
refinacin de los modelos preliminares de roles e interaccin definidos en la fase de
anlisis. Finalmente en la fase de diseo detallado, se genera la definicin del modelo de
agentes y la definicin del modelo de servicios. A pesar que la metodologa define
claramente tres fases para el diseo de SMA, Gaia no maneja directamente tcnicas
particulares de modelado, tampoco los problemas inherentes a la implementacin,
tampoco las actividades para capturar los requerimientos ni el modelado tpico de la
ingeniera de software.

Figura 3-5. Metodologa Gaia con nuevas extensiones [ZAMB2003].

Fase de Anlisis

17

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 continuacin 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 organizacin en
suborganizaciones.

Modelo del Ambiente: se define como una representacin computacional abstracta en

el cual el SMA est situado.

Modelo Preliminar de Roles: identifica las habilidades bsicas requeridas por la

organizacin, contiene los roles que son identificados sin comprometer la imposicin
de una estructura organizacional.

Modelo de Interacciones Preliminar: identifica las interacciones bsicas requeridas

para completar los roles preliminares.

Las reglas Organizacionales: esta caracterstica es una de las nuevas adiciones a la

metodologa Gaia, estas reglas expresan las restricciones en la ejecucin 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
organizacin. Se pueden definir dos tipos de reglas organizacionales:
-

Reglas de Supervivencia: definen como la dinmica de la organizacin 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 organizacin debe respetar, como por ejemplo el hecho de que un rol debe
ser ejecutado slo por una entidad durante el tiempo que dure la organizacin, o
que dos roles nunca pueden ser ejecutados por una misma entidad.

En general, las reglas organizacionales y su correcta identificacin son fundamentales

para la etapa de diseo, porque restringen la definicin de la estructura organizacional
y restringe el nmero de implementaciones propias de una organizacin. Tambin son
importantes para saber cuando un nuevo agente puede ser admitido en la
organizacin y que roles tienen permisos de ejecutar una accin sobre el ambiente;
adicionalmente identifican que clases de protocolos pueden ser iniciadas por los
miembros de una organizacin y cuando esta clase de protocolos son una expresin
de intereses propios legtimos.
Fase de Diseo Arquitectnico
Esta fase expone todas las caractersticas funcionales que el SMA expresar e
identificar la forma de estructurar el SMA en la organizacin. Dentro de esta fase se
realizan dos actividades importantes:
-

Estructura Organizacional: segn Zambonelli [ZAMB2003], la seleccin de la

estructura organizacional debe escogerse en trminos de una topologa y un rgimen
de control, teniendo en cuenta la eficiencia y simplicidad organizacional, la influencia
de la organizacin del mundo real y la influencia de las reglas organizacionales.
Cuando la topologa es simple, es posible manejar la complejidad computacional y la
coordinacin. Conforme aumenta el tamao de la organizacin aumenta la
complejidad y la coordinacin, llevando a adoptar una topologa jerrquica hasta

18

alcanzar mximos niveles de complejidad y adoptar mltiples jerarquas. El rgimen

de control maneja las interacciones entre los miembros de las organizaciones y es de
alguna manera ortogonal a la topologa de la organizacin.
En cuanto a la influencia de las reglas organizacionales, el SMA debe respetar y estar
en la capacidad de decretarlas durante la ejecucin. Las reglas organizacionales
impactan sobre la estructura organizacional, donde el reforzamiento de las mismas
tendr un efecto en los costos computacionales y de coordinacin. Por otra parte, en
lo que se refiere a la influencia de la organizacin del mundo real, sta se presenta
como una fuerza de atraccin en la definicin de la estructura organizacional.
-

Refinamiento de los Modelos de Roles e Interaccin Preliminares: esta actividad se

realiza una vez se ha definido la estructura organizacional; es importante mantener la
distincin entre las caractersticas que son intrnsecas, independientes de los roles y
protocolos en una organizacin especfica, y las extrnsecas, derivadas de la adopcin
de una estructura organizacional especfica.

Fase de Diseo Detallado

Esta fase es la responsable de identificar el modelo de agentes y de servicios, que
resultarn siendo la base para la implementacin de los agentes y sus actividades. Se
definen los siguientes modelos:
-

Modelo de Agentes: encargado de identificar las clases de agentes que compondrn

el sistema y las instancias de agentes que sern generadas a partir de dichas clases.
Se realizan las correspondencias entre los tipos de agentes y los roles.

Definicin 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 anlisis y diseo se obtienen los artefactos necesarios para pasar a la
etapa de implementacin que no es definida por la metodologa Gaia, actividad que
dependera del programador del SMA.

Finalmente, cabe anotar que Sutandiyo [SUTA2004], presenta mGaia, una extensin a la
metodologa Gaia para el diseo de SMA que tiene en cuenta la movilidad. La propuesta
presentada, modifica Gaia aadiendo un modelo a la etapa de diseo: 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 travs
de los ambientes donde se despliegan. Adems, para ser coherente con el resto de la
metodologa, se adicionan caractersticas a los otros modelos, como por ejemplo la
descripcin del agente identificando si es mvil o no en el Modelo de Agentes.

3.6.

Metodologa MAS-CommonKADS

Esta metodologa est basada en la metodologa CommonKADS propuesta por Schreiber

et.al. [SCHR1999], la cual es adaptada para disear SMA aadindole tcnicas del
anlisis y diseo orientado por objetos, como la tcnica de modelado de objetos (OMT),
ingeniera de software orientada a objetos y diseo basado en responsabilidades; as
como metodologas orientadas a protocolos, el lenguaje de especificacin y descripcin
(SDL) y grficos de secuencias de mensajes (MSC96).
Esta metodologa desarrolla siete modelos: Modelo de Organizacin, 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 caractersticas de cada agente; Modelo de Comunicacin, que describe las
relaciones dinmicas entre agentes humanos y sus respectivos agentes de software;

19

Modelo de Conocimiento, que describe el conocimiento que debe tener un agente para
lograr sus metas; Modelo de Diseo, que refina los modelos anteriores y determina la
arquitectura ms apropiada para cada agente as como los requerimientos para la red de
agentes; y un Modelo de Coordinacin, que describe las relaciones dinmicas entre
agentes de software [IGLE1998].
De estos siete modelos, los seis primeros pertenecen a la metodologa CommonKADS y
el ltimo es incorporado para aplicaciones multiagente. MAS-CommonKADS divide el
proceso de anlisis y diseo de la siguiente forma: primero, hay una fase
conceptualizacin, en la que se obtiene una visin preliminar del problema, una fase de
anlisis, en la que se obtienen los requerimientos y tercero una fase de diseo, en donde
se determina el conjunto inicial de agentes que se van a utilizar.
Fase de Conceptualizacin
En esta fase se obtiene una descripcin preliminar del problema y se hace un bosquejo de
las interacciones, con las cuales se har un refinamiento cuando se cree el modelo de
coordinacin. Esto se hace siguiendo una aproximacin 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 notacin 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 Anlisis
El resultado de esta fase debe ser el conjunto de requerimientos que especifican el
sistema multiagente a travs de los modelos descritos anteriormente (a excepcin del
modelo de diseo). Los pasos para desarrollar dichos modelos son los siguientes:
-

Modelado de Agentes: identificacin de agentes. Para esto se pueden seguir algunas

estrategias:
-

Anlisis de los actores de los casos de uso encontrados en la fase de

conceptualizacin.

Anlisis del planteamiento del problema.

20

La realizacin de un modelo inicial de tareas y de conocimiento puede ayudar a

identificar las capacidades requeridas por los agentes.

Aplicacin de la tcnica 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 aproximacin

topdown. Esta descripcin incluye el nombre, una descripcin corta, entradas,
salidas, estructura de tareas, su control, frecuencia de aplicacin, precondiciones y
habilidades requeridas.

Modelo de Coordinacin: este modelo tiene dos hitos: el primero es la definicin de los
canales de comunicacin y la construccin de un prototipo y el segundo es el anlisis
y determinacin 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 ontologas 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 fsicos 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 aplicacin, 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 descomposicin 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 Mtodo
de Solucin de Problemas (PSM, por sus iniciales en ingls) [IGLE1998], el cual
define como se debe llevar a cabo una inferencia para realizar una tarea.

Modelo de Organizacin: este modelo define la estructura y comportamiento de la

organizacin en el que el sistema va a ser desplegado. Este modelo muestra las
relaciones estructurales o estticas entre los agentes. La notacin bsica utilizada es
la del modelo de objetos de OMT, aadiendo algunos smbolos para diferenciar a los
agentes de los objetos.
En la Figura 3-7, se puede observar un ejemplo de la jerarqua de los agentes
identificados. Aunque los smbolos 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.

21

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

Fase de Diseo
Como resultado de la fase de anlisis, se ha determinado un conjunto inicial de agentes,
los cuales deben ser detallados en esta fase. En la metodologa CommonKADS, el
modelo de diseo se utiliza para describir la arquitectura y el diseo tcnico del sistema
justo antes de su implementacin. En MAS-CommonKADS, este modelo es extendido
para modelar SMA y posee los siguientes pasos [IGLE1998]:
-

Diseo de la Red de Agentes: corresponde a la infraestructura del SMA; consiste en

los elementos de red, conocimiento y coordinacin.

Diseo de Agentes: se determina la arquitectura interna ms adecuada para cada

agente.

Diseo de la Plataforma: seleccin del software (entorno de desarrollo de agentes) y

del hardware necesario para el sistema.

3.7.

MaSE

Es una metodologa para desarrollar SMA de propsito general segn DeLoach

[DELO2000]. La idea es guiar al diseador desde la especificacin inicial del sistema
hasta la implementacin del SMA.
La metodologa est dividida en dos fases: anlisis y diseo. Sin embargo, slo se
estudiar la fase de anlisis, pues es la ms importante y es la que tiene mayor relevancia
para DeLoach. Aunque MaSE no est diseada para ser utilizada con alguna arquitectura
particular, lenguaje de programacin o plataforma de comunicacin, est asociada con
una herramienta CASE llamada agentTool.
Fase de anlisis
El primer paso en la fase de anlisis 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 ms 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.

22

En MaSE, una meta siempre est definida como un objetivo a nivel de sistema. El proceso
de capturar metas produce una jerarqua 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 extrados 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 anlisis,
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 diseadas para
ejecutarse de forma concurrente como lo describe DeLoach [DELO2001]. Aunque en un
artculo posterior, DeLoach [DELO2002], propone modelar el comportamiento utilizando
un medio hbrido de coordinacin y concurrencia.

3.8.

Metodologa 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 razn, 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 fsicas o lgicas dentro de un ambiente, del cual pueden sentir y actuar.
Para disear un SMA, se debe seguir una metodologa, segn Tian, la mayora de
metodologas orientadas a agentes se limitan a describir roles y sus relaciones o generar
modelos grficos y formales, otras describen la descomposicin de roles en tareas. Sin
embargo, en comn las metodologas no tratan con el diseo arquitectnico de una
manera completa. Por esta razn, se define una metodologa que enfatice la arquitectura
del sistema para reducir la complejidad y que se desarrolle con un ciclo de vida lineal.
Tian, describe su metodologa teniendo en cuenta la perspectiva de rol, flujos de
informacin y perspectivas de control, con un mapeo muchos a muchos entre
subfunciones, roles y los agentes.
El punto clave de esta metodologa 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 metodologa se
utiliza un ciclo de vida lineal; adicionalmente se ha aplicado esta metodologa en un caso
de estudio para la medicina utilizando la herramienta Agent Tool.
La metodologa se compone de tres fases bsicas, cada una de las cuales describe una
serie de pasos. Estas son: Anlisis de Requerimientos, Diseo Arquitectnico del SMA y
Diseo Detallado del SMA.
Anlisis 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:

23

1. Se realiza el anlisis y agregacin de los requerimientos dentro de un SMA, una

vez realizado el anlisis de requerimientos y haber descompuesto el SMA en
subfunciones, stas se diferencian y relacionan unas con otras que ms adelante
se agregarn en grupos.
Diseo Arquitectnico 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 informacin 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 informacin, se debe entender que un SMA tiene una interaccin dinmica y
comunicacin dentro del SMA. Y finalmente desde la perspectiva de control, el SMA debe
ser organizado como una jerarqua de control rgida, para subdividir en varias capas que
se encarguen de distintas tareas. En conclusin dentro de esta fase se llevan a cabo los
siguientes pasos:
1. Se realiza la identificacin de los roles de los agentes y sus responsabilidades;
respondiendo desde la perspectiva de roles; en este paso se identifican los roles
que sern ejecutados por los agentes y sus responsabilidades, que es lo que el
agente debe hacer, cundo y cmo 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 determinacin de la jerarqua 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 jerarqua 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 determinacin de las interacciones del SMA; respondiendo a la
perspectiva del flujo de informacin, en este paso se determinan las interacciones
entre los agentes y los sistemas externos, que se define como envo y recepcin
de mensajes.
Diseo Detallado del SMA
En esta fase se selecciona la plataforma de implementacin de los agentes y se llevan a
cabo detalles de implementacin como la comunicacin y el despliegue de estos agentes.
En esta fase se realizan los siguientes pasos:
1. Se realiza la configuracin de la plataforma de agentes; este paso es basado en el
domino de la aplicacin.

24

2. Se realiza la construccin de los agentes; stos son diseados sobre la plataforma

seleccionada de acuerdo a los roles y planes definidos, el programador debe
especificar una ontologa para la aplicacin.
3. Se realiza la especificacin de la infraestructura de comunicacin de los agentes;
en este paso se define un ACL (Agent Communication Language), las reglas de
comunicacin son diseadas en detalle.

3.9.

Metodologa para el Anlisis y Diseo de Sistemas - ADS

Ramos [RAMO2004], propone una metodologa formal para el desarrollo de soluciones de

software soportado en agentes. sta tiene un enfoque basado en una arquitectura BeliefsIntentions (Creencias - Intenciones) y utiliza un alfabeto de lgica temporal y axiomas para
modelar el sistema. La metodologa detalla explcitamente las fases de la especificacin,
la implementacin y la verificacin.
La metodologa toma como unidad fundamental a los agentes (como la mayora de
metodologas) 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 electrnico; entre los aportes que se pueden apreciar,
se puede destacar la formalizacin en la fase de especificacin, en ella Ramos
[RAMO2004] utiliza un lenguaje con una estructura sintctica llamado LCIASA, con el cual
se puede describir las interacciones de los agentes basado en planes y mensajes con
notacin BNF.
Otro aspecto destacable es en la fase de implementacin, 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 interaccin con el ambiente. Adicionalmente, tambin propone un framework
llamado Agents Plataform [AGUI2001] que le permite disear los agentes y ejecutarlos. A
continuacin se describen las tres fases de la metodologa.
Fase de Especificacin
Esta fase abarca la perspectiva de diseo, el modelo de agentes, el modelo formal y los
protocolos de interaccin.
-

Perspectiva de Diseo: esta etapa se concentra en identificar qu se va a resolver y

cmo 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
diseo 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, propsitos, servicios
ofrecidos y relaciones.

Modelo de Agentes: estableciendo una estructura organizacional para los agentes,

una herramienta estndar 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 Interaccin: 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 lgica temporal y
el lenguaje LCIASA el cual describe mensajes de intercambio entre agentes , AML

25

es utilizado para ayudar en la tarea de especificacin e interpretacin, obteniendo al

final un estudio sobre las caractersticas, propiedades y comportamientos del SMA.
La descripcin del lenguaje LCIASA, proporciona una estructura esttica e
interpretacin semntica 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
asociacin entre LCIASA y AML es percibida observando que las acciones de AML
corresponden a los mensajes de LCIASA y que LCIASA proporciona una estructura
sintctica para AML.
Fase de Implementacin
Esta fase estudia el cambio de la especificacin abstracta a un sistema computacional
concreto. En la Figura 3-8, se ilustra la arquitectura utilizada para la metodologa, donde
las decisiones se toman mediante un razonamiento lgico.

Figura 3-8. Arquitectura para la metodologa, adaptado de [RAMO2004].

Fase de Verificacin
Es el proceso de probar que un sistema implementado est correcto con respecto a su
especificacin. Para la metodologa se utilizan dos procesos de verificacin, el primero es
verificacin por ciclo de vida y el segundo es una verificacin formal.
-

Verificacin por Ciclo de Vida: determina el valor de satisfaccin del SMA para una
especificacin establecida, durante cada uno de las fases del desarrollo.

Verificacin Formal: para verificar formalmente el sistema se utiliza el modelo lgico

obtenido.

3.10. Metamodelo para Agentes, Roles y Grupos

26

De acuerdo con Odell [ODEL2004a], los sistemas multiagente a gran escala contienen
mltiples agentes con distintas capacidades que en el momento de satisfacer una tarea;
deben operar como sistemas cerrados, formando grupos dinmicos para completar
satisfactoriamente una labor. Por esta razn Odell [ODEL2004a], propone la
especificacin 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 especificacin
se extiende de la especificacin 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 asignacin dinmica 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 clasificacin dinmica y la
activacin dinmica.
Cuando se habla de clasificacin dinmica, se refiere a la habilidad de cambiar la
clasificacin de una entidad o en este caso un agente [ODEL2004b]. La idea principal de
este concepto es que un agente tiene un rol mnimo o base y a partir de all se pueden
aadir, 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
activacin dinmica se puede entender como la revelacin 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
aproximacin Odell [ODEL2004a], pretende mostrar la dinmica 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
homogneos.

27

El modelo principal se compone de tres clases principales, de las cuales se definen otras
para mayor especificacin del SMA. stas son Clasificador de Agentes, Agentes y
Grupos. A continuacin se profundiza ms 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 Fsico y Clasificador de
Agentes por Roles.
-

Clasificador de Agentes Fsico: define las primitivas bsicas de los requerimientos que
todos los agentes deben poseer independientemente del rol que estn
desempeando. Un ejemplo es el siguiente: el agente debe poseer un nombre nico;
otras caractersticas que dependen de la implementacin son la manera como los
agentes envan y reciben mensajes, la forma en que mantienen sus atributos (estados
o creencias) y la manera como interactan 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 caractersticas, contextualizadas dentro de un
grupo donde esos roles son desempeados. Los agentes pueden ser asociados con
ms de un Clasificador de Agentes por Roles, permitiendo una mltiple clasificacin y
puede cambiar roles en el tiempo, permitiendo una clasificacin dinmica. Los roles
proporcionan los bloques para construir un sistema social y proporcionan los
requerimientos por los cuales los agentes interactan. Un Clasificador de Agentes por
Roles debe estar asociado a uno o ms 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
clasificacin. Las instancias definen a las entidades autnomas e interactivas conocidas
como agentes y las clasificaciones proporcionan las caractersticas subyacentes para
cada agente. En otras palabras cada instancia de un Clasificador de Agentes especifica
las caractersticas que poseen sus Agentes asociados.
Para comprender an ms, a continuacin 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 Fsicos con los Clasificadores de Agentes por
Roles. A partir de esta asociacin se conforman los agentes, introduciendo al Clasificador
de Agentes, y a los Agentes que definen completamente a cada uno de los agentes,
relacionndolos con los roles y con agentes fsicos que dependen de una plataforma en
particular (Figura 3-10).

28

Figura 3-10. Asociacin 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 razn.
Estn relacionados por sus roles, donde cada grupo de roles tiene un nmero 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 caractersticas que un slo agente posee.
En otras palabras el grupo de agentes puede ser visto como un slo 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

organizacin conceptual, o sinergias intergrupo. En otras palabras el grupo noagentizado 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 diseo de un SMA, mediante este metamodelo es la

asignacin 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 dinmicas un agente podra cumplir un rol en un grupo, pero no en otro, por esta
razn se introduce una nueva clase llamada Asignacin 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
asignacin de roles con los grupos, en donde esta asignacin debe estar definida por el
contexto del grupo.

29

Figura 3-11. Asociacin entre Agentes, Grupos y Clasificador de Agentes [ODEL2004a].

3.11. SONIA
La metodologa SONIA, Set of mOdels for a Natural Identification of Agents, propuesta por
Alonso [ALON2004], permite la generacin de una arquitectura multiagente para resolver
un problema de acuerdo con un Modelo de Diseo Multiagente, que sistematiza y
automatiza las actividades para identificar los componentes del SMA. La metodologa
define una sociedad de agentes que facilita la solucin de un problema y puede ser
utilizada para integrar sistemas antiguos indispensables. A continuacion se presentan las
cuatro fases de la metodologa.
Fase de Anlisis
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, clasificacin de conceptos y clasificacin de asociaciones. El
segundo, describe la forma en que los problemas del dominio son solucionados (basado
en las tareas y mtodos). 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 interactan con el sistema.

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

Fase de Diseo
Esta fase est dividida en dos etapas: sntesis y diseo arquitectnico. La primera, provee
la identificacin de agentes segn componentes. Adicionalmente, los elementos del

30

modelo estructural y del de tareas, son agrupados dependiendo de las caractersticas 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 cohesin interna de los miembros y el acoplamiento con otros grupos es bajo y
son usadas para desempear tareas que tienen comportamientos similares.

Modelo de Comportamiento: producido a partir del agrupamiento del modelo de

tareas, las subtareas y los mtodos. Esta agrupacin 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 propsito es el de identificar agentes y los objetos del

entorno.

Fase de Diseo Arquitectnico

Esta fase se enfoca en la definicin de los componentes arquitectnicos a travs de los
siguientes modelos:
-

Modelo de Agentes: identifica a partir de los modelos de responsabilidad,

conocimiento y comportamiento, cuales entidades deberan ser diseadas como
agentes autnomos. 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 Interaccin: identifica y define las interrelaciones entre los agentes, el

sistema y los objetos.

La Fase de Diseo de la Sociedad de Agentes

Esta fase consiste en la solucin de un problema distribuido, generado en el diseo de la
arquitectura multiagente, en el cual, los agentes comparten metas y el problema es
dividido en pequeas tareas compartidas dentro de la sociedad de agentes. En este caso,
la metodologa lleva a un modelo de sociedad de agentes, basado en el paradigma de
suscripcin-publicacin. 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. Anlisis General de las Metodologas

Despus de analizar las principales metodologas y propuestas para disear SMA se
puede afirmar lo siguiente:
-

La mayora de las metodologas contemplan las etapas de anlisis y diseo. En el

anlisis se concentran en especificar los requerimientos, tanto funcionales como nofuncionales. Dentro del diseo generalmente contemplan el diseo del sistema y el
diseo de la arquitectura interna del agente.

Es comn encontrar que el enfoque de la mayora de las metodologas sea top-down y

que mantengan un ciclo de vida iterativo e incremental.

31

La metodologa Tropos es la nica que contempla un anlisis 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
tardos modela el sistema como tal, especificando los actores y las dependencias
entre ellos.

Una caracterstica comn a todas las metodologas es el soporte en modelos que

ayudan grficamente 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 an ms integrando metas, eventos, recursos y planes.

En la metodologa Tropos se propone el uso de patrones organizacionales, que se

resume en el modelamiento de las organizaciones, es decir grupos, estructuras
jerrquicas, etc., que representan a la organizacin en el mundo real.

Algunas metodologas introducen el uso de diagramas de AUML para mostrar las

interacciones entre los agentes, como lo hace la metodologa Prometheus.

Algunas metodologas como Tropos, Prometheus, y la propuesta ADS de Flix Ramos

[RAMO2004], integran una fase de implementacin, que realizan con herramientas o
plataformas de agentes, que no estn atadas a la metodologa.

La metodologa Prometheus se destaca principalmente por la generacin de los

artefactos que brindan una mejor especificacin de los detalles del sistema que se
est construyendo.

Prometheus difiere de otras metodologas en que no define roles de forma explcita.

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 metodologas son los metamodelos.

Tropos ha incluido los metamodelos, con el fin de explicar mejor la metodologa y
hacer la transicin ms fcil 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 caractersticas bsicas (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 slo agente que agrupa
a varios) o no-agentizados (vistos como un grupo de agentes).

Pocas metodologas manejan el concepto de roles dinmicos, 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 segn
las tareas que hace el agente.

3.13. REFERENCIAS BIBLIOGRFICAS

[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., Martnez, L., and Montes, C. (2004). Sonia: A
methodology for natural agent development. ESAW2004 - 5th Intl.
Workshop on Engineering in the Agents World.

32

[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):203236.
[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 922929, 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

Autonomous Agents 2001, 2001.

Behavior

as

Concurrent

Tasks,

[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 - AAMAS2004, 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., Gonzlez, 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

33

joint conference on Autonomous agents and multiagent systems, pages

859866, 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,
AAMAS2004, 2004
[ODEL2004a] Odell, J., Nodine, M. H., and Levy, R. (2004). A metamodel for agents,
roles, and groups. In AOSE, pages 7892.
[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 (IAT04), 2004.
[RAMO2004] Ramos, F. F. (2004). Methodology for analysis and design of systems. In
WSTFEUS, pages 8084.
[SALC2002] Salcedo, P. (2002). Commonkads y el lenguaje de modelado unificado - uml.
Artculo de la Revista DIICC-Revista Informtica, 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 126141.
[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 (IAT04), pages
373376, 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.

34

[YU1997] Yu, E. S. (1997). Towards modelling and reasoning support for earlyphase
requirements engineering. In International Symposium on Requirements
Engineering, pages 226235, 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):317370.

35