Steps in Exploring Connections, Presenting Data:

Esta fase está orientada al diseño específico de agentes en el cual se definen las metas de cada agente así como sus habilidades, creencias y la comunicación con otros agentes.

En esta fase se utilizan diagramas UML de actividades para representar habilidades y planes y un subconjunto de los diagramas AUML descritos en [30] para la especificación de protocolos.

3.3.1.5 La implementación

La fase de implementación de acuerdo a la metodología TROPOS está basada en el modelo BDI [36] y en la plataforma JACK [8], la cual es un ambiente de desarrollo orientado a agentes basado y completamente integrado en Java [13]. La descripción del uso de la plataforma JACK va más allá del objetivo de este trabajo.

3.3.2 GAIA

GAIA, descrita en [40] y [41], es una metodología de diseño de sistemas multi- agente, esto quiere decir que está completamente orientada al diseño y no hace ningún énfasis en fases como la especificación o recolección de requerimientos ni sobre la implementación del sistema.

La base de esta metodología es una metáfora organizacional, esto quiere decir que el diseño se basa en replicar, con organizaciones de agentes, organizaciones humanas. Esta metodología propone un proceso en cascada con tres etapas sucesivas: análisis, diseño arquitectural y diseño detallado, el proceso de diseño propuesto por GAIA se presenta en la

Figura 3.3. Requerimientos División en Sub-organizaciones Modelo del ambiente Modelo preliminar de roles Modelo preliminar de interacciones Reglas organizacionales Estructura organizacional Modelo de roles Modelo de interacciones Modelo de agentes Modelo de servicios Análisis Diseño arquitectural Diseño detallado Implementación G A I A

Figura 3.3. Proceso de diseño de acuerdo a la metodología GAIA.

La primera fase de GAIA es la de análisis y durante esta fase se identifican y organizan las especificaciones que son la base del diseño de la organización. Es en esta fase donde se identifican las metas y comportamiento global del sistema, el ambiente en el que se situará, las habilidades básicas requeridas, las interacciones que existirán y las reglas que gobernarán el comportamiento global del sistema.

En la fase de diseño arquitectural se define la estructura organizacional del sistema en términos de topología y régimen de control, los roles que estarán presentes en el sistema así como las interacciones necesarias entre ellos.

Finalmente en la fase de diseño detallado tiene como finalidad establecer una relación entre roles y clases de agentes así como detallar los servicios que estarán presentes en el sistema.

En las siguientes secciones se presenta una descripción más completa de cada una de estas etapas.

3.3.2.1 El análisis

Esta fase se enfoca en organizar y modelar los requerimientos del sistema en 4 modelos, del ambiente, de roles, de interacciones y en reglas organizacionales. Esta fase toma como entrada la salida de una fase previa de análisis de requerimientos, la cual no es especificada por GAIA pero que debe ser llevada a cabo. Se sugiere el uso de un enfoque orientado a metas para la fase previa de análisis, como aquella presentada en [41].

La primera etapa de esta fase incurre en la subdivisión del sistema en sub- organizaciones. Esto no es siempre necesario ya que puede darse el caso de que una sola organización sea adecuada para el sistema a diseñar. La subdivisión es fácilmente identificable en casos como cuando la especificación lo establece, el sistema replica una organización real (ya subdividida), porciones bien delimitadas de la organización tienen metas específicas diferentes de las del resto del sistema o requieren capacidades o habilidades no requeridas por el resto del sistema.

Como segunda etapa esta metodología propone el modelado del ambiente, para el cual se hace uso de abstracciones simples como recursos computacionales (variables o tuplas), la cuales pueden ser creadas, consumidas o detectadas por los agentes y sobre las cuales los agentes podrán actuar. El modelo del ambiente puede realizarse simplemente estableciendo para cada recurso su nombre y el tipo de acciones que los agentes podrán realizar sobre ellas. A continuación se presenta un ejemplo de modelo de ambiente.

LEÍDO variable1

vairable2 ESCRITO variable1

Esta fase no pretende definir la organización del sistema, no obstante es posible durante esta fase identificar características del sistema que estarán presentes independientemente de la organización que presente el sistema. Estas características incluyen las habilidades básicas con las que deberá de contar y las principales interacciones necesarias para explotar estas habilidades.

Identificando las habilidades e interacciones básicas del sistema se pueden definir modelos preliminares de roles e interacciones. Estos modelos son puramente preliminares pues los roles identificados no pueden ser considerados roles organizacionales mientras no se establezca la estructura de la organización, por lo mismo, los protocolos (interacciones) identificadas no pueden ser consideradas definitivas.

El modelo preliminar de roles incluye un conjunto de esquemas de rol como el presentado a continuación:

Esquema de rol: ROL1

Protocolos y actividades: protocolo1, actividad1, …

Permisos: derechos asociados a este rol (con respecto a los recursos) Responsabilidades

Liveness: ciclo de vida del rol

Seguridad: condiciones que se deben mantener

El esquema de rol incluye el nombre del rol, su descripción general, una lista de actividades que realizará el rol y protocolos de interacción en los que participará, los permisos que tiene para actuar sobre los recursos del sistema y sus responsabilidades.

Las responsabilidades del rol se dividen en dos categorías: liveness y seguridad. Las

responsabilidades de vida, que podrían considerarse el ciclo de vida del rol, están conformadas por una sentencia que describe la secuencia de actividades e interacciones que el rol deberá realizar, GAIA propone el uso de una notación heredada de FUSION [9]. Las responsabilidades de seguridad son útiles para establecer condiciones que deberán ser verificadas por el rol en todo momento.

Las interacciones identificadas son modeladas mediante protocolos, los cuales de acuerdo a la metodología GAIA son vistos como patrones institucionalizados de interacciones, esto quiere decir que el protocolo no se define en términos de una secuencia de pasos a seguir sino en términos de su objetivo, su naturaleza y propósito. El modelo preliminar de interacción incluye un conjunto de esquemas de protocolos, los cuales presentan la siguiente estructura:

Nombre del protocolo: nombre Iniciador: rol que inicia la interacción Par: rol con el que se interactúa

Entradas: información presentada por el iniciador de la interacción Salidas: información obtenida del rol con el que se interactúa Descripción: descripción genérica del protocolo

Las reglas organizacionales del sistema se proponen de manera similar a las responsabilidades de los roles, es decir que si las responsabilidades de los roles indican las tareas que deberán realizar y las condiciones que deberán mantener, las reglas organizacionales indican las tareas que el sistema en general deberá realizar y las condiciones que deberá mantener.

Al igual que las responsabilidades, las reglas organizacionales se dividen en dos categorías: liveness y seguridad. Las reglas liveness indican como debe evolucionar la

dinámica de la organización, por ejemplo, si una actividad deberá llevarse a cabo por un rol sí y solo sí es rol ha realizado otra actividad previamente. Las reglas de seguridad establecen invariantes del sistema que deberán mantenerse en todo momento, por ejemplo, si una entidad no puede asumir dos roles al mismo tiempo. Las reglas organizacionales se presentan como sentencias de manera similar a las responsabilidades de los roles.

3.3.2.2 El diseño arquitectural

Los modelos obtenidos en la fase de análisis documentan las características funcionales que el sistema deberá presentar así como el ambiente operacional en el que

estará situado. Esta especificación es usada en el diseño arquitectural para identificar una estructura acorde para la organización del sistema y para completar los modelos preliminares de acuerdo a la estructura elegida.

La fase de análisis está orientada a entender que es lo que el sistema debería realizar, la fase de diseño se enfoca en la toma de decisiones acerca de las características que el sistema presentará.

La primera etapa de esta fase es establecer la estructura de la organización. Como lineamiento básico para la elección de una topología/régimen de control se tiene que se deberá escoger la topología más simple que permita manejar adecuadamente la complejidad computacional y de coordinación.

La topología puede ir desde cargar todo el trabajo a una sola entidad, lo cual incurre en un costo nulo de coordinación, pero es poco factible que un sistema pueda ser construido de esta forma. Un conjunto de pares aporta un costo de coordinación que va incrementándose de acuerdo al número de pares que tengan que ser coordinados, este costo puede verse reducido si la responsabilidad de coordinación se deja a una entidad en específico. Cualquier tipo de topología puede ser adoptada pero debe tenerse especial cuidado en que el costo de coordinación sea adecuado para el sistema.

En cuanto al régimen de control, se puede optar por dos alternativas principales, subdividir el trabajo entre un conjunto de entidades que adoptan los mismos roles y ofrecen los mismos servicios o crear especializaciones donde cada entidad asume un rol diferente y que ofrece servicios diferentes. Sin embargo estas dos alternativas, dependiendo de la aplicación pueden incurrir en incrementar el costo de coordinación.

Es necesario elegir la mejor alternativa de estructura organizacional de modo que se cumpla con los requerimientos del sistema manteniendo un costo bajo tanto en complejidad como en coordinación.

Las reglas organizacionales obtenidas en la fase de diseño en la mayoría de los casos ayudan a discriminar entre alternativas de estructura organizacional pues en muchos casos establecen de manera explícita restricciones que apuntan hacia cierto tipo de estructuras.

Para representar la estructura organizacional se puede optar por una visión gráfica o una especificación escrita. Gráficamente se representa la estructura organizacional a través de la representación de los roles y la relación entre ellos. En la Figura 3.4 se presenta la representación gráfica de tres estructuras organizacionales simples.

Rol1 Rol2 Rol3 par par pa_r Rol1

Rol2 Rol3 Rol3 Rol4 Rol1 Rol2 depende de depende de depende de depende de

par

Conjunto de pares Jerarquía Estructura híbrida Figura 3.4. Representación gráfica de estructuras organizacionales.

La estructura organizacional se puede especificar de manera textual a través de sentencias como la siguiente:

Rol relación Rol

Para cada rol se establece la relación que tiene con los demás roles, la relación puede ser de dependencia, de paridad, entre otras.

Una vez definida la estructura organizacional del sistema es posible completar los modelos preliminares de roles e interacciones. La estructura organizacional establece de manera explícita actividades que los roles deberán realizar y protocolos con los cuales interactuarán así como también nuevos roles (roles organizacionales) que no fueron identificados en la fase de análisis pero que son necesarios para poder dar al sistema la estructura elegida.

Para poder completar los modelos preliminares es necesario:

1. Definir todas las actividades en las que cada rol estará envuelto así como las responsabilidades específicas de cada rol.

2. Definir roles organizacionales derivados directamente de la selección de la estructura organizacional.

3. Completar la definición de protocolos requeridos por el sistema y establecer que roles los ejecutarán.

4. Definir protocolos organizacionales derivados de la selección de la estructura organizacional.

Una vez completados los modelos de roles e interacciones, a través de ellos se tiene una representación operacional de la organización del sistema que será usada en conjunto con las reglas organizacionales y el modelo del ambiente para el diseño detallado del sistema.

3.3.2.3 El diseño detallado

Esta fase tiene por objetivo definir un modelo de agentes y uno de servicios, los cuales serán utilizados para la implementación de agentes y de sus actividades.

Dentro del contexto de esta metodología, los agentes son entidades software asumiendo o actuando un conjunto de roles de agente, por lo tanto el modelo de roles trata de especificar clases de agentes para asumir cada uno de los roles y de cuántas instancias de cada clase serán necesarias dentro del sistema.

Comúnmente puede haber una relación uno a uno entre roles y clases de agentes, esto es que se define para cada rol una clase de agente que lo ejecutará. Sin embargo, el diseñador puede decidir establecer una sola clase de agente para ejecutar un conjunto de roles estrechamente relacionados y que interactúen entre sí. Esto puede hacerse por conveniencia pero tomando en cuenta que no se violen reglas organizacionales, la eficiencia organizacional no se vea alterada y que no se generen problemas de este hecho.

También es necesario tomar en cuenta la coherencia de la clase de agente, es decir que su funcionalidad sea entendible, y que se reduzca en lo posible la discrepancia entre la organización real y la del sistema cuando el sistema este replicando una organización real.

El modelo de agentes se establece de manera simple definiendo para cada clase de agente la cardinalidad (número de instancias) y los roles que asumirá, la siguiente línea muestra un ejemplo de modelo de agentes.

ClaseAgenteNejecuta Rol1, Rol2, …

Los servicios en GAIA representan actividades específicas en las que una clase de agente, o de manera equivalente un rol ejecutado por una clase de agente, se verá envuelta. En el paradigma orientado a objetos un servicio es representado por un método, los servicios de agentes no son necesariamente vistos como métodos pues no estarán disponibles para otros agentes como los métodos. Dada la autonomía de los agentes, un servicio no necesariamente obedecerá a una solicitud externa y debido a la capacidad de decisión, una solicitud externa no forzosamente desencadenará un servicio.

Para cada servicio presente en el sistema, el modelo de servicios requiere que se definan sus principales características, en específico se requiere describir sus entradas, sus salidas, pre-condiciones y post-condiciones. Las entradas y salidas se heredan directamente de los protocolos mientras que las pre y post-condiciones pueden identificarse de las responsabilidades de los roles y de las reglas organizacionales.

El modelo de servicios de GAIA puede representarse mediante una simple tabla en la que cada renglón se refiera a un método y que mantenga columnas para el nombre del servicio, su entrada, salida pre-condiciones y post-condiciones.

GAIA no incluye en el modelo de servicios ninguna especificación referente a la implementación de los servicios que documenta sino que se deja al diseñador la elección de la mejor manera de implementarlos.

Finalizando esta fase, el diseño del sistema ha terminado y se tiene bien documentado el conjunto de clases de agentes, sus instancias y los servicios que cada uno presentará. Este diseño será utilizado en la fase de implementación de acuerdo a las necesidades y habilidades del equipo de diseño, el cual puede optar por implementar agentes y servicios de manera tradicional en un lenguaje orientado a objetos o utilizar el ambiente de desarrollo de agentes que mejor se adecué al sistema diseñado.

3.3.3 MaSE

Esta metodología (Ingeniaría de sistemas multi-agente, por sus siglas en inglés), descrita en [10] y [11] se enfoca en el análisis y diseño de sistemas multi-agente a los cuales define en términos de clases de agentes y su organización. La organización de los agentes se establece con respecto a su habilidad de comunicarse mediante conversaciones.

Esta metodología consta de dos fases en cascada, la primera de análisis y la segunda de diseño. El proceso de análisis y diseño propuesto por esta metodología se presenta en la siguiente figura (Figura 3.5).

Requerimientos Jerarquía de metas Casos de uso Diagramas de secuencia Roles Tareas concurrentes Clases de agentes Conversaciones Arquitectura de agentes Diagramas de despliegue Captura de metas Aplicación de casos de uso Refinamiento de roles Creación de clases de agente Construcción de conversaciones Ensamblado de clases de agente Diseño del sistema A N Á L I S I S D I S E Ñ O

Figura 3.5. Proceso de análisis y diseño en MaSE.

3.3.3.1 El análisis

Esta es la fase inicial de MaSE y tiene tres etapas: captura de metas, aplicación de casos de uso y refinamiento de roles. La primera etapa tiene como objetivo obtener, a partir de la especificación del sistema, un conjunto estructurado de reglas, las cuales son presentadas en un diagrama de jerarquía de reglas como el presentado en la siguiente figura (Figura 3.6). Las metas en MaSE son siempre definidas como objetivos globales del sistema.

1. Meta

1.1 Meta 1.2 Meta

1.1.1 Meta 1.1.2 Meta

Figura 3.6. Diagrama de jerarquía de metas.

Para la captura de metas se proponen dos pasos: la identificación y la estructuración de las mismas. El desarrollador deberá identificar las metas directamente de la

especificación del sistema para después estructurarlas de acuerdo a su importancia. Así mismo, el desarrollador deberá identificar sub-metas que aportarán al conseguimiento de las metas principales.

La segunda etapa del análisis en MaSE es la aplicación de casos de uso, la cual es de crucial importancia para relacionar las metas con los roles y sus tareas. Los casos de uso son descripciones escritas de secuencias de eventos que definen el comportamiento esperado del sistema [11]. Para determinar las comunicaciones requeridas en el sistema, el desarrollador debe reestructurar los casos de uso en diagramas de secuencia.

Los diagramas de secuencia (Figura 3.7) presentan la secuencia de eventos entre diversos roles y definen la comunicación mínima requerida en el sistema así como el conjunto inicial de roles que estarán presentes.

Rol 1 Rol 2 Rol 3 Evento

Evento Evento Evento

Figura 3.7. Diagrama de secuencia.

La última etapa del análisis es refinar los roles identificados durante la aplicación de casos de uso. Esto quiere decir que se deberá establecer el comportamiento de cada rol a través de las tareas que realizará y los patrones de comunicación que usará. Además se deben incorporar nuevos roles según sea necesario. Para asegurar que todas las metas sean consideradas, se asocia a cada meta un rol que buscará satisfacerla. Comúnmente se establece una relación uno a uno entre metas y roles pero es válido asignar a un solo rol el conseguimiento de más de una meta. El modelo de roles en MaSE presenta el conjunto de roles, sus tareas y la comunicación con otros roles. En la siguiente figura se presenta un ejemplo de modelo de roles (Figura 3.8).

Rol 1 1.1

Rol 2 1.2

Tarea 1.1.1Evento Tarea 1.1.2EventoTarea 1.2.1 Figura 3.8. Modelo de roles.

Las tareas mostradas en el modelo de roles deben ser detalladas mediante el uso de máquinas de estados finitos.

3.3.3.2 El diseño

En la fase de diseño el enfoque es el de convertir los diagramas obtenidos de la fase de análisis en artefactos aplicables directamente en la implementación del sistema. Esta fase tiene cuatro etapas: creación de clases de agentes, construcción de conversaciones, ensamblado de agentes y diseño del sistema.

La primera etapa se identifican clases de agentes necesarias a partir de los roles establecidos en el modelo de roles. Al igual que entre metas y roles, generalmente se hace un mapeo directo de roles a clases de agentes, sin embargo el desarrollador puede optar por asignar a una misma clase de agente diversos roles. La comunicación entre roles es heredada por las clases de agentes por lo que en el diagrama de clases de agentes se incluyen también las comunicaciones. Un ejemplo de diagrama de clases de agentes se aprecia en la siguiente figura (Figura 3.9).

Clase 1 Rol 1 Rol 3 Clase 2 Rol 2 Rol 4