FAQ

¿Por qué una metodología para el desarrollo de agentes?

Existen múltiples metodologías, así que quizá una más pueda parecer algo innecesario. embargo, un estudio somero de las existentes muestra serias faltas. Por ejemplo, llama la atención la falta de desarrollos que prueben su validez. La mayoría de los que se pueden encontrar ocupan la longitud de un artículo de investigación, de siete a quince páginas. Existen intentos para establecer ejemplos estándar sobre los que aplicar las metodologías por parte del grupo de metodologías de AgentLink, sin embargo todavía no existe ningún acuerdo al respecto.

Otra característica que se aprecia en las metodologías existentes se centran en aspectos muy concretos del desarrollo de Sistemas Multi-Agente. La mayoría parte de enfoques conocidos como el paradigma de objetos (MaSE), ingeniería del conocimiento (MAS-CommonKADS), o diseño dirigido por requisitos (TROPOS). El partir de estos enfoques significa centrarse en elementos considerados como fundamentales en las disciplinas de las que parten, como objetos, métodos de resolución de problemas y objetivos respectivamente. Este punto de vista condiciona el desarrollo de la metodología y hace difícil en algunos casos la integración de resultados de investigación.

Las metodologías existentes han sido desarrolladas en ámbitos académicos, por lo que queda por demostrar su aplicabilidad según métodos industriales. Los elementos presentados en la metodología hay que integrarlos con un paradigma de ingeniería del software. Este paradigma es importante cuando se trata de un desarrollo mediano-grande, y fundamental cuando participa más de una persona. El paradigma asegura la calidad del desarrollo estableciendo métricas y aporta medios para gestionar su evolución. Para desarrollos pequeños estos elementos no son necesarios, pero en la industria sí que lo son. Llama la atención sobre todo el proceso de desarrollo que se propone en la mayoría de los casos, diez pasos de media en los que hay que generar un conjunto determinado de diagramas. Como ejemplo de integración con un paradigma de ingeniería del software , se puede tomar MESSAGE, que se integra con el Proceso Unificado de Desarrollo,  y Mas-CommonKADS, que utiliza el modelo de desarrollo en espiral. Para ver una comparativa de ambas, puede verse el estado del arte.

¿Qué tiene esta metodología que no tengan otras?

Principalmente, se trata de que INGENIAS está siendo probada con desarrollos cercanos a la complejidad de un desarrollo industrial.

¿Qué es un meta-modelo?

Un meta-modelo define las primitivas y las propiedades sintácticas y semánticas de un modelo. A diferencia de otros enfoques más formales, como Z [Spivey 92] , los meta-modelos están orientados a la generación de representaciones visuales de aspectos concretos del sistema de forma incremental y flexible. Los modelos crecen incorporando más detalle gracias a que no es necesario que se instancien absolutamente todos los elementos del meta-modelo para tener un modelo. Como ha demostrado UML [OMG 00d] , construido también con meta-modelos, este tipo de notación facilita enormemente el desarrollo de sistemas. Otra ventaja de utilizar meta-modelos es que las especificaciones generadas de SMA son lo suficientemente estructuradas para ser procesadas de forma automática. Así, se puede plantear la verificación automática de la construcción de los modelos para ver si cumplen restricciones identificadas por el desarrollador, generar documentación del sistema en diferentes formatos de diferentes partes de los modelos, e incluso establecer la generación automática de código desde la información recogida en los modelos.

El meta-modelado se comprende a partir de una estructura de cuatro niveles ( Ilustración 1). En esta estructura, el nivel M1 establece las primitivas de meta-modelado, esto es, el lenguaje de meta-modelado. En el nivel M2, se definen los meta-modelos en sí con las primitivas de M1. En M3 se aplican los meta-modelos para generar instancias, que se denominan modelos. Por último, la instanciación de los modelos, lleva al nivel donde se tiene la información que se manejará en el sistema.

Ilustración 1. Estructura de cuatro niveles utilizada en el meta-modelado [OMG 00b]

Los lenguajes de meta-modelado (nivel M1) considerados son dos:  Meta-Object Facilities (MOF) [OMG 00b] y GOPRR  (Graph, Object, Property, Relationship, and Role) [Lyytinen y Rossi 99] . Ambos son similares y de hecho se pueden hacer traducciones de uno a otro. En esta tesis la definición e implementación de los meta-modelos se hace con GOPRR. El motivo es que actualmente no hay herramientas que soporten meta-modelado con MOF, pero sí con GOPRR.

Ilustración 2 . Primitivas de GOPRR

2. Primitivas de GOPRR

Las primitivas de GOPRR son reducidas (Ilustración 2 ). Estas primitivas permiten definir la documentación del sistema, que se concibe como grafos (entidad Graph), en términos de asociaciones (Relationship) cuyos extremos se definen con roles (Role) y que conectan entidades (Object). Todos estos elementos contienen propiedades (Property) que pueden ser otros objetos, grafos, roles o relaciones.  Existen más elementos en GOPRR como las restricciones en gráficos (número de elementos, presencia o ausencia de elementos) o la cardinalidad de las relaciones. Con estos elementos es sencillo definir una gramática para la construcción de UML. De hecho, la herramienta que implementa este lenguaje (METAEDIT+ [Lyytinen y Rossi 99] ) incluye entre sus demostraciones la especificación GOPRR de UML.

¿Por qué no utilizar UML?

Existe la iniciativa AUML, que está orientada a extender UML para su uso con agentes.

¿Cómo se implementa el sistema especificado?

Referencias al deliverable 3. Propuesta actual de generación automática.

¿Realmente existe un diseño orientado a agentes?

Los resultados en el área de agentes hacen referencia sobre todo al uso de los agentes como medio para analizar un sistema. INGENIAS