R81682

ROADMAP

Araujo Gómez, Inés
Cid Paredes, Miriam

Introducción

Paradigma SMA Nuevas abstracciones y
principios de diseño y desarrollo
Necesidad de nuevas metodologías

Intentos de identificar abstracciones propias de SMA
y desarrollar metodologías adecuadas
Sistemas específicos o extensiones de metodologías OO
Propuestas que intentan definir metodologías completas y
generales
Abstracciones específicas para agentes

1

Introducción

Metodologías con diferentes terminología y abstracciones, pero
todas coinciden en que:

Proceso de construcción de MAS <> Proceso de construcción de
sistemas SW tradicionales
MAS = Sociedad organizada de individuales en la que cada
agente tiene un rol específico e interactúa con otros agentes de
acuerdo a protocolos
Necesario identificar abstracciones adicionales orientadas a la
organización

Hoy en día, sistemas SW abiertos entorno dinámico

Metodología GAIA (Versión original)

Alcance: Análisis Diseño
Excluye especificación de requerimientos e implementación

Metáfora organizacional:
SMA = Organización computacional de agentes
Cada agente desempeña uno o varios roles específicos en
la organización
Agentes cooperan o interaccionan unos con otros para el
logro de un objetivo común

En general, el proceso de Gaia consiste en construir
ordenadamente una serie de modelos

2

Definir esquema para cada rol en función de cuatro
atributos:
• Actividades: tareas o acciones que un rol puede hacer
sin interactuar con otros roles
• Protocolos: tareas o acciones que un rol puede hacer
interactuando con otros roles

• Permisos:
METODOLOGÍA recursos del entorno disponibles para el rol

• Responsabilidades: funcionalidad actual del rol
Especificación
de Requerimientos
• Seguridad: propiedades que el rol tiene que
preservar siempre.
Predicados sobre variables/recursos de los
Modelo Análisis
permisos
de Rol

• Esquema depatrón roles son atómicos generalizado
Vitalidad: rol: descripción semi-formal No
En Gaia los de comportamiento del
del rol
comportamiento función de otros roles
definidos en de un agente
Expresión regular sobre actividades y
protocolos

Modelo de Interacción:

Metodologíadefinición de(Versión original)
• Incluye una
GAIA alto nivel para cada uno de
los protocolos de cada rol del sistema.

• Definición de protocolo tabla simple con los
METODOLOGÍA
siguientes datos:

• Rol que inicia el protocolo
Especificación
de Requerimientos
• Rol encargado de responder al anterior

• Información de entrada en el protocolo
Modelo Modelo de Análisis
de Rol Interacción
• Información de salida en el protocolo

• Breve descripción textual del tipo de información
que se procesa durante la ejecución del protocolo

3


METODOLOGÍA
Modelo de Agentes:

• Especifica los tipos de agentes que forman el sistema
Especificación
actual de Requerimientos

• Se crea asignando roles a tipos de agentes asignar
un tipo de agentes a uno Modelo deroles
Modelo o más Análisis
de Rol Interacción

• Anotar cardinalidad para cada tipo de agente

• Similar al modelo de clases en la O.O.
Modelo de Diseño
agentes

Servicio: bloque coherente de funcionalidad (neutral
respecto a detalles de implementación)

Modelo de Servicio:
METODOLOGÍA
• Lista todos los servicios que proveen los tipos de agentes
Especificación
• Estos servicios se derivan de las actividades y protocolos
de Requerimientos
de los roles

• Especificar para cada servicio: de
Modelo Modelo Análisis
de Rol Interacción

• Entradas
• Salidas
• Precondiciones
Modelo de Modelo de Diseño
• Postcondiciones
agentes Servicio

4


METODOLOGÍA

Modelo de Comunicación:
Especificación
de Requerimientos

• Gráfica directa entre tipos de agentes

• Arco de A a B: A puede enviar mensajes a B
Modelo Modelo de Análisis
de Rol Interacción

• Permite visualizar el grado de acoplamiento entre
tipos de agentes
Modelo de Modelo de Modelo de Diseño
agentes Servicio Comunicación
• Se ignoran tipos de mensajes

Limitaciones:
Diseñada para el manejo de sistemas pequeños y cerrados
No trata la fase de especificación de requerimientos
No ofrece un modelo de entorno: información del entorno implícita
en los permisos y protocolos de los roles
Gaia inapropiada para aplicaciones con entornos dinámicos y
heterogéneos.
No ofrece un modelo de conocimiento del dominio: conocimiento
del dominio implícito en los atributos de los roles
Roles no jerárquicos: modelo de roles con un solo nivel de
abstracción
Gaia no puede manejar sistemas complejos
Notación simple pero pobre para representar sistemas complejos
y no sigue ningún estándar

5

Consecuencia: Surgen extensiones para mejorar Gaia:
Para modelar SMA abiertos en entornos complejos:
Gaia v.2
• Se basa en la identificación de abstracciones organizacionales adicionales
a parte de los roles y protocolos:
- Entorno en el que el SMA está inmerso entidades y recursos con
los que el SMA tiene que interaccionar
- Reglas organizacionales: restricciones que la organización tiene que
cumplir
- Estructuras organizacionales: para hacer explícita la arquitectura
global del sistema posición de cada rol en la organización y sus
relaciones con otros roles

Roadmap
Para mejorar sus técnicas de notación
Gaia extendido con AUML

Metodología ROADMAP

INTRODUCCIÓN
Propuesta por la universidad de Melbourne en el 2002.
Roadmap tiene las siguientes mejoras con respecto a Gaia
Modelos de conocimiento y entorno
Jerarquía de Roles
Representación explícita de estructuras sociales y relaciones
Incorporación de cambios dinámicos

La ingeniería de sistemas abiertos complejos, requiere que la metodología
empleada tenga dos características:
Independencia arquitectónica: Una metodología no debe suscribir un paradigma de
programación en particular, un lenguaje, un agente arquitectónico o un marco de
trabajo de implementación
Robustez y escalabilidad: La metodología debe facilitar cambios dinámicos sin
comprometer la robustez del sistema. La escalabilidad debe fomentar la facilidad de
crecimiento de sistemas abiertos.

6


METODOLOGÍA
Es independiente de la implementación de la arquitectura
Soporta análisis y diseño arquitectónico del sistema

METODOLOGÍA ESQUELETO

Modelos: Diseñados para ser simples y asociarse fácilmente con los
modelos O.O:
Permite a diseñadores sin conocimiento de agentes ver la facilidad de uso
de la tecnología
Relación Roles - Agentes ≈ Relación Interfaces - Objetos en la
aproximación O.O.
• Como las interfaces, los roles proporcionan un modelo de clases del sistema
bajo una implementación concreta de funcionalidades
• A diferencia de las interfaces, los roles pueden ser cambiados en ejecución.

No soporta diseño detallado, Usa características opcionales de otra
metodología dependiente de la arquitectura.

Roadmap Arquitectura independiente Puede añadirse a la
metodología esqueleto para facilitar el análisis y un diseño de alto
nivel.

7

MODELOS:

Análisis: Amplia la versión original de Gaia para cubrir totalmente la
especificación de requisitos.
Se crean modelos para permitir la conceptualización y documentación de
requisitos.

Diseño: Los modelos del análisis se llevan a al diseño. En el diseño
arquitectónico, se redefinen los modelos y se optimizan para
conseguir objetivos de calidad.
Al final de la fase de diseño arquitectónico se escoge para cada agente
una arquitectura de implementación.

Los modelos son secuenciales y cada modelo toma todos los
modelos anteriores.


MODELOS
• Describir requerimientos
• Incluye diagramas gráficos generales
• Describe los escenarios mediante texto.
• Uso de conceptos de Roadmap de zonas y roles.
• Semántica para capturar el comportamiento de
agentes diferente a la aproximación O.O:
O.O usuario interacciona con el
software del sistema para trabajar
Roadmap usuarios interacciona con un
equipo de agentes abstractos ideal

8


MODELOS
• Metodología esqueleto Es una lista de
percepciones y acciones posibles en un entorno de
agentes .

• Roadmap En lugar de un espacio uniforme, el
entorno es ahora modelado en zonas. Contiene:
• Jerarquías de zonas en el entorno
• Conjunto de esquemas de zona que describe
cada zona en la jerarquía. La jerarquía de zonas
es similar a la jerarquía de clases O.O
conteniendo herencia y agregación para
relacionar zonas y objetos en esas zonas.


MODELOS

9


MODELOS


MODELOS

10


MODELOS

Contiene diagramas de secuencia
como los propuestos en AUML

Modelo de Conocimiento:

• Jerarquía
MODELOS de componentes del conocimiento
• Conjunto de esquemas (descripción) para cada componente
del conocimiento.

• Componente del conocimiento:
• Bloque coherente de conocimiento.
• Permiten escalabilidad de conocimiento y reusabilidad en el
sistema.
• Puede ser incluido en un rol o en un agente.

• El modelo de rol es paralelo a este modelo.

• Si cambia el comportamiento del sistema o el entorno, se
tiene que revisar el conocimiento en los roles.

11

MetodologíayROADMAP en Gaia
• El concepto de rol esquema de rol es como
• Añade con respecto a Gaia la Jerarquía de roles
• La jerarquía de Rol se representa como un árbol:
MODELOS
• Los nodos hoja del árbol son roles atómicos: con semántica
original de Gaia y representan características de un agente
individual.
• El resto de roles son roles compuestos que se definen en términos
de otros roles que a su vez pueden ser atómicos o compuestos.
• La raíz del árbol es un rol compuesto especial que representa al
sistema completamente
• El mecanismo usado en esta jerarquía es la agregación.
• Los roles tienen una relación de participación implícita que no
puede ser eliminada
• Se permite a un rol leer, escribir o crear permisos para definir
otros roles.


MODELOS

Igual que el modelo de interacción de Gaia.

12

Metamodelo de ROADMAP
Deriva de la metodología de Roadmap
Un metamodelo es un modelo que define el lenguaje para expresar otros modelos,
en este caso se trata de un modelo genérico para describir sistemas multiagente.
Este metamodelo tiene dos jerarquías de ejecución:
La jerarquía de rol: representa un elevado nivel de abstracción para la especificación de
requerimientos
La jerarquía de agentes: proporciona una implementación concreta de las
funcionalidades del sistema.

Todas las entidades del metamodelo se crean en tiempo de ejecución
Un rol en un metamodelo de Roadmap: Como en la metodología de Roadmap
pero con dos mejoras:
El ciclo de vida de un rol puede estar dividido en responsabilidades y protocolos
Las comunicaciones y mensajes en la organización van a través de roles que aseguran
que el comportamiento de agentes pueda ser validado en tiempo de ejecución.

Un agente: Entidad en tiempo de ejecución que tiene un identificador único, se
comunica usando mensajes síncronos y asíncronos, manteniendo una lista de
roles.

Escalabilidad los roles pueden agregar subroles recursivamente, mientras que los agentes
pueden agregar subagentes.
Se espera que un sistema multiagente contenga una jerarquía de agentes, separando la
especificación del sistema (roles) de la implementación (agentes).

13

Paso de mensajes entre agentes y roles
El mensaje del Agente A es el primero mandado y validado por el rol. Si todas las
restricciones se satisfacen, el mensaje es propagarlo al rol del Agente B. Después de
ser el mensaje validado, el Agente B, recibe el mensaje y puede responderlo. Como
parte de acuerdo organizacional, el mensaje también es remitido al rol del Agente C y
el Agente C después lo valida para funciones de monitorización.

Nombre del rol:
Transporte en Red
Subroles: Definición de un rol
Controlador y Conexión
Conocimiento:
Perfil de tráfico de aplicación
Objetivos:
DatoTransporte
Max. Fiabilidad() durante Trabajo
Max. () durante Transmisión
Min. ConexionActiva() durante Trabajo
Según Prioridad()
Responsabilidades:
R1: Fiabilidad()>8 durante Trabajo implica Conexión.Seguridad2
R2: ()>3 durante Transmisión implica Conexión.Seguridad1
R3: ConexiónActiva()< ConexionFondo antes Conexión implica Controlador.Seguridad1
R4: TiempoRespuesta()<4 durante Conexión
Permisos:
Leer y escribir a Sockets durante Trabajo
Leer Perfil de tráfico de aplicación durante Conexión
Leer y escribir Conexión
Protocolos:
Trabajo=Conexión.Transmisión.Desconectar satisface DatoTransporte
Conexión
Tranmisión implica Conexión.Transmisión
Desconectar
Esperar

14


Nombre de agente:
AgenteRed
Roles implementados:
TransporteRed Definición de un agente
Sub-agentes:
AgenteControl, AgenteConexión
Servicios:
ConexionSvS implementa Conexión
TransmisionSvS implementa Transmisión
DesconexionSvS implementa Desconexion
EsperaSvS implementa Espera

Los agentes y los roles se comunican mediante el paso de mensajes. El uso de mensajes
para el modelo de interacción reduce el acoplamiento entre agentes, así como mensajes
que puedan ser rechazados o remitidos a otros agentes. La interacción de agentes, puede
ser a través de roles. Cuando los agentes interaccionan directamente sin ser a través de
roles, la interacción es considerada privada muchas veces indeseable o prohibida.

Los agentes deberían aprender de sus roles en la organización para que el sistema actúe
de forma correcta sin intervención humana.

Características deseables de un metamodelo
Ejecución escalar del sistema: Los sistemas en entornos abiertos deben de
poderse escalar incorporando o eliminando sistemas durante la ejecución.
Representación en ejecución de requerimientos y atributos de calidad:
para permitir comportamientos en el agente que estén validados en la
organización.
Abstracción del conocimiento de las funcionalidades: Un metamodelo debe
separar el conocimiento de los agentes de las funcionalidades de bajo nivel.
Modulación del conocimiento: El conocimiento debe de ser desarrollado y
mantenido en unidades modulares con alta cohesión y bajo acoplamiento.
Nivel variable de características de agentes en ejecución: Un metamodelo
debe permitir variar en tiempo de ejecución las características de un agente
tales como el nivel de inteligencia, autonomía, proactividad y reactividad
Nivel variable de atributos de calidad en la ejecución: Un metamodelo
debería permitir que el nivel de atributos de calidad se pudiera cambiar durante
la ejecución.
Simplicidad
Facilidad de aprendizaje

15

Características que cumple el metamodelo de Roadmap

La habilidad de que roles y agentes puedan modificar otros roles y
agentes permite al sistema escalarlo durante la ejecución.

Los roles de Roadmap pueden representar requerimientos del
sistema y atributos de calidad. Teniendo separada la herencia de
roles de la de agentes se asegura la separación entre
especificación e implementación del sistema.

El metamodelo es similar a la aproximación O.O, esta similitud
sugiere que el metamodelo es tan simple como la O.O y no
debería imponer complejidad durante el desarrollo.

El metamodelo de Roadmap cumple los criterios de evaluación de
forma correcta.

Bibliografía
ARTÍCULOS:

“The Gaia Methodology: Basic Concepts and Extensions”, Luca Cernuzzi,
Thomas Juan, Leon Sterling, Franco Zambonelli
“Developing Multiagent Systems: The Gaia Methodology”, Franco Zambonelli,
Nicholas R. Jennings, Michael Wooldridge
“ROADMAP: Extending the Gaia Methodology for open complex systems”,
Thomas Juan, Adrian Pearce, Leon Sterling
“The Gaia Methodology for Agent-Oriented Analysis and Design”, Nicholas R.
Jennings, Michael Wooldridge, David Kinny
“The ROADMAP Meta-Model for Intelligent Adaptive Multi-Agent Systems in
Open Environments”, Thomas Juan, Leon Sterling
“Achieving Dynamic Interfaces with Agent Concepts”, Thomas Juan, Leon
Sterling
“Assembling Agent Oriented Software Engineering Methodologies from
features”, Thomas Juan, Leon Sterling, Michael Winikoff
“A Meta-model for Intelligent Adaptive Multi-Agent Systems in Open
Environments”, Thomas Juan, Leon Sterling

16

R81682

Recommended

Recommended

More Related Content

What's hot

What's hot (19)

Similar to R81682

Similar to R81682 (20)

R81682