Los meta-modelos son una gran ayuda en el proceso de desarrollo de SMA, ya que determinan qué entidades tienen que existir y cómo deben conectarse. Desde el punto de vista de ingeniería, lo que interesa de los meta-modelos, además de servir de guía, es cómo pueden ayudar a estructurar el desarrollo de SMA. Para estudiar la aplicación de los meta-modelos a procesos de ingeniería, se han tomado los meta-modelos como lenguaje de especificación del SMA, de forma similar a los diagramas UML como especificación de un desarrollo orientado a objetos. Partiendo de este lenguaje se estudian qué actividades y productos son necesarios para generar los modelos que constituyen la especificación del sistema. Estas actividades y productos son relevantes porque se pueden integrarse dentro de un proceso de ingeniería del software. Las actividades se pueden distribuir entre los diferentes componentes de un equipo de trabajo, estableciendo qué productos se esperan de cada actividad y cómo se combinan.
Como aplicación práctica de esta idea, en este capítulo se plantea la integración con el Rational Unified Process (RUP) [Jacobson, Booch y Rumbaugh 00] en las fases de análisis y diseño. Se ha elegido este modelo de desarrollo de software por las dependencias observadas entre los distintos meta-modelos. Al ser iterativo e incremental, es más sencilla la generación de modelos, ya que se pueden elaborar poco poco aplicando los criterios de integración de resultados de los modelos para asegurar su coherencia. Además, el RUP toma la arquitectura del sistema como guía del desarrollo, del mismo modo que en el capítulo anterior se señalaba que el modelo de organización constituía la espina dorsal de la especificación del SMA. Por último, el RUP utiliza casos de uso para determinar la funcionalidad del sistema y diagramas de colaboración y secuencia (entre otros) para describirlos. Ya se ha comentado la utilidad de las interacciones como generalización de diagramas de colaboración y diagramas de secuencia. Así, lo más lógico es utilizar interacciones como especificación del comportamiento de los casos de uso.
En este capítulo se presenta la integración propuesta definiendo primero el nivel de detalle a alcanzar en cada una de las etapas del RUP y después las diferentes actividades requeridas para generar modelos. El nivel de detalle se obtiene a partir de la estimación hecha en el RUP para los modelos generados con UML. Las actividades se obtienen a partir de la experiencia obtenida en el desarrollo de casos prácticos, uno de los cuales se presenta en el siguiente capítulo, y se expresan con diagramas de actividades de UML. Como complemento al estudio de la generación de la especificación del sistema, en las dos últimas secciones se estudia cómo llevar a cabo la implementación del sistema de forma automatizada y qué elementos arquitectónicos deben existir en la arquitectura final del sistema.
En el RUP, el esfuerzo del análisis y diseño se encuentra localizado en tres fases: inicio, elaboración y construcción. Dentro de cada fase se desarrollan las iteraciones (ciclos completos de desarrollo incluyendo análisis, diseño, implementación y pruebas) que construyen gradualmente el sistema. La Tabla 5 muestra el conjunto de actividades que según [Jacobson, Booch y Rumbaugh 00] se realizan en esas etapas. Como se puede apreciar, la principal diferencia en cada etapa consiste en el nivel de detalle alcanzado al final de las iteraciones que se realizan en cada una de ellas.
Tabla 5. Actividades a realizar en las etapas de inicio, elaboración y construcción.
La generación de modelos a partir de meta-modelos se guía por el conjunto de actividades que se presentarán a lo largo de este capítulo. Estas actividades no sustituyen las indicadas por el RUP, sino que se integran en el paradigma como complemento de los elementos de especificación ya existentes. De hecho, en las actividades de generación se mencionan técnicas convencionales refiriéndose a la utilización de notaciones como UML y modelos de desarrollo como RUP para atacar el diseño de elementos concretos.
Para orientar la integración, se plantean una serie de asociaciones entre elementos del RUP y elementos de los meta-modelos (ver Tabla 6 ).
Tabla 6. Asociaciones entre los elementos del RUP y entidades de MAS GRASIA
El agente, como la clase, define tipos. Lo que aquí se ha denominado agente en ejecución sería un objeto en el RUP. La organización equivale a la arquitectura en el RUP por su carácter estructurador. La organización da una visión global del sistema agrupando agentes, roles, recursos y aplicaciones y estableciendo su participación en los flujos de trabajo del SMA. El grupo es la unidad de estructuración utilizada en la organización. Su similitud con un subsistema se debe a que como éste, se utiliza para organizar elementos en unidades de abstracción mayores y define un conjunto de interfaces para interaccionar, los roles en este caso. La interacción, como se comentó en la introducción, se ve como una generalización de los diagramas de colaboración y secuencia. En el RUP, los diagramas de secuencia y colaboración se ven como escenarios que describen cada caso de uso. Por último, roles, tareas y los flujos de trabajo proporcionan el encapsulamiento de acciones que en el RUP dan métodos e interfaces.
Tabla 7. Adecuación de las etapas del RUP a los meta-modelos presentados.
Estas asociaciones marcan prioridades a la hora de profundizar en la generación de los distintos modelos (agente, organización, interacción, entorno, objetivo y tareas). De acuerdo con estas equivalencias y el proceso del RUP, la generación de modelos se estructuraría según indica la Tabla 7 . Las distintas iteraciones consistirían en seguir las actividades de las subsecciones anteriores, ya dispuestas con un inicio y final.
Las fases de pruebas e implementación no se han incluido. La fase de pruebas no tiene por qué ser diferente de la del software convencional. El software final ha de satisfacer casos de uso identificados, y como indica la tabla Tabla 7 , el concepto de casos de uso se mantiene. En cuanto a la implementación, se admite que el diseñador puede actuar como en diseños usuales, desarrollando elementos computacionales que hagan lo que está especificado. En este dominio, este enfoque no sería el más adecuado, ya que sería deseable aprovechar los desarrollos existentes, donde ya están resueltos los problemas de comunicación o implantación del control en los agentes. Por ello, se propone reutilizar el software de agentes personalizándolo con los modelos generados a partir de los meta-modelos de esta tesis. El proceso se denomina parametrización porque toma un software operativo y lo concreta con información extraída de los modelos generados. Desde este punto de vista, el software se ve como un resolutor general de problemas que ha de ser particularizado para el dominio actual. Aunque la parametrización puede realizarse manualmente, en este trabajo se propone automatizar en parte este proceso.
El proceso de parametrización implica ser capaz de recorrer los modelos generados y de poder extraer datos de ellos. Aunque la herramienta de soporte utilizada, METAEDIT+, no proporciona primitivas adecuadas para recorrer los modelos, permite traducir los modelos a otras representaciones. En este caso, se ha optado por traducir los modelos a términos PROLOG. Desde estos predicados, se ha diseñado un programa con el cual es posible volcar las especificaciones directamente en código fuente. Sólo se requiere que el código fuente que se parametriza esté marcado de una forma especial y que se generen las secuencias de datos a volcar. Para proporcionar más detalles de este proceso, puede consultarse la sección 3.7 .
Al instanciar el meta-modelo de agente, se está describiendo cómo son los elementos fundamentales del sistema, los agentes. Debido a que lo normal es que la información reflejada en estos modelos sea una recolección de información presentada en los otros, no suele constituir un buen punto de partida.
La generación de instancias de este meta-modelo se organiza en torno a los resultados esperables durante el análisis y el diseño. Los resultados que se obtienen durante el análisis son los siguientes:
o Funcionalidad del agente. Un conjunto de roles que desempeña cada agente. Un conjunto de tareas asociadas a los agentes o a roles que estos jueguen.
o Requisitos del agente. Qué cualidades se esperan del agente. Como ya se ha mencionado, si se espera del agente que demuestre inteligencia o autonomía, hay que especificar con detalle qué tipo de inteligencia y qué tipo de autonomía se espera. A este nivel basta con una descripción en lenguaje natural acompañada de casos de uso que lo ejemplifiquen.
Los resultados a obtener durante el diseño se refieren al control del agente:
o Restricciones de control. Se representan mediante los estados mentales por los que pasa el agente a lo largo de las interacciones.
o Medios de control. Cómo es el control que asegura la transición entre los distintos estado mentales identificados. La especificación de estos medios puede hacerse en lenguaje natural o utilizando referencias a modelos de objetivos y tareas.
Para lograr estos resultados, se proponen las actividades de la Ilustración 85 e Ilustración 84 :
§ Producto. Un conjunto de instancias básicas del meta-modelo de agente con un único participante, el agente.
Ilustración 84. Actividades involucradas en la generación de modelos de agente en el análisis
Ilustración 85. Actividades involucradas en la generación de modelos de agente en el diseño
2. Asociar tareas o roles para alcanzar los objetivos del agente. Según el esquema de control visto, los objetivos se alcanzan ejecutando tareas o desempañando roles que participan en interacciones que persiguen objetivos. Tras la identificación de objetivos, la asociación de tareas a objetivos o el desempeñar un rol sirve para clarificar el por qué una tarea existe.
§ Producto. Un conjunto de objetivos asociados al agente por meta-relaciones GTPersigue o WFPersigue. Inclusión del objetivo en el estado mental si se trata del estado inicial del agente. Si pertenece a algún estado intermedio, indicarlo con insancias de Consulta Agente y asociar estas instancias con el tipo de agente.
§ Productos. Un conjunto de tareas y asociaciones WFResponsable, AResponsable. Un conjunto de roles y asociaciones WFJuega.
2.c. Asociar funcionalidad a objetivos. Justifica la ejecución de tareas o el desempeñar roles, asociando un sentido (el objetivo) a la funcionalidad del agente. Si se trata de tareas, el objetivo se asocia a las tareas mediante instancias de GTAfecta. Si lo que se ha identificado son roles, el objetivo se asocia al rol mediante instancias de WFPersigue o bien se puede omitir si se indica la participación del rol en interacciones, ya que las interacciones tienen asociado un objetivo. Más tarde, las tareas asociadas a los roles, dentro de flujos de trabajo o interacciones, se tendrán que asociar a objetivos relacionados, si no iguales, al del rol. Los objetivos también se pueden alcanzar mediante la satisfacción o fracaso de otros objetivos, esto es, sin necesidad de que se ejecuten otras tareas. Para determinar si es ésta la situación, hay que estudiar los modelos de objetivos y tareas buscando instancias de GTDepende. Hay aclarar que aunque algunos objetivos se puedan satisfacer de esta forma, el resto siguen teniéndose que alcanzar mediante tareas o roles.
§ Productos. Asociaciones de tareas y objetivos (GTAfecta). Asociaciones de roles a objetivos WFPersigue.
§ Producto. Descripción de las características deseables (tipo de inteligencia, tipo de aprendizaje, algoritmos y heurísticas aplicables) en el agente en lenguaje natural acompañada de un conjunto de casos de uso ilustrativos.
§ Producto. Instancias de Procesador y Gestor de estado mental asociadas al agente mediante instancias de las meta-relaciones ATieneProcesadorEM y ATieneGestorEM. Estas entidades deben acompañarse de una descripción en lenguaje natural del tipo de gestión y procesamiento deseado utilizando la propiedad Descripción.
5. Actualizar modelos con los requisitos de las plataformas destino. Implica por lo general añadir información a la presentada en el modelo. Esta nueva información surge de la necesidad de instanciar un armazón software para que lleve a cabo las especificaciones del modelo. Según los requisitos impuestos por el armazón software, la especificación del sistema debiera modificarse. Así, un armazón software donde la comunicación entre agentes es importante, como JADE, influiría pidiendo un nivel de detalle alto en los modelos de interacciones.
§ Productos. Nuevas entidades en el modelo o más detalle en las existentes.
§ Producto. Nuevos modelos donde se reflejan los estados mentales requeridos.
7. Diseño del control del agente. El control del agente se diseña de acuerdo a las necesidades identificadas durante el análisis (inteligencia, autonomía, descripciones del gestor y procesador de estado mental). Es probable que el usuario decida dejar el control del agente en manos de un algoritmo, como en TAEMS [Decker 96;Decker y Lesser 95;Decker 95] . En tal caso esta actividad se delega en la actividad de generación de diseño convencional.
7.a. Partiendo del conjunto de estados mentales, determinar cómo se pasa de uno a otro. En esta actividad es determinante el tipo de gestor de estado mental elegido. A modo de guía, si se trata de un sistema basado en reglas, el gestor establecería qué entidades nuevas deben añadirse, cuáles modificarse y cuáles eliminarse en términos de operaciones assert, retract y modify. Para ver cómo se pasa de un estado a otro hay que estudiar las tareas asociadas con el agente, qué requieren en su ejecución y qué efectos tienen. Parte de los difgerentes estados mentales por los que pasa el agente se enumeran dentro de los diagramas GRASIA.
§ Productos. Operaciones a realizar para asegurar la transición entre los diferentes estados mentales identificados. Las operaciones dependen del tipo de gestor de estado mental elegido.
§ Productos. Referencias a modelos de objetivos y tareas.
7.c. Asociar los estados mentales a la ejecución de acciones. Esta actividad depende del tipo de procesador de estado mental elegido. La decisión de ejecutar una acción puede ser fruto de la ejecución de una regla. La condición de ejecución se reflejaría en la parte izquierda de la regla mientras que la acción se codificaría en la parte derecha. La decisión también puede surgir como resultado de un proceso deliberativo complejo, como el propuesto por SOAR o IRMA. Estas alternativas pueden expresarse también utilizando modelos de objetivos y tareas.
§ Productos. Descripción del proceso deliberativo que lleva a la ejecución de acciones en función del estado mental. La descripción depende del tipo de procesador de estado mental elegido. Es admisible la utilización de modelos de objetivos y tareas
8. Validar el modelo contra los otros modelos. La validación se realiza según los criterios de la sección 2.2.7 del capítulo segundo.
§ Productos. Lista de inconsistencias
9. Corregir el modelo. Para hacer el modelo consistente con las instancias de otros meta-modelos
§ Productos. Modificaciones a efectuar.
El meta-modelo de interaccion refleja el comportamiento deseado de un agente cuando recibe instrucciones de otro agente o bien requiere de otro agente para realizar una tarea. Como en los modelos de agentes, la generación de modelos de instancias se inicia en el análisis y se continúa en el diseño.
Para el análisis se ha fijado que los resultados esperables son:
o Interacciones relevantes en el sistema. Indicando participantes y objetivos perseguidos.
o Esquema inicial de intercambio de mensajes. Realizado con diagramas de colaboración o de secuencia UML. La realización de estos diagramas es menos costosa que los diagramas GRASIA.
Como en procesos convencionales de ingeniería, no es de esperar que los diagramas de colaboración resultantes sean definitivos. Estos diagramas sufrirán cambios cuando se entre en profundidad en la especificación de interacciones. Del diseño se espera :
o Descripciones detalladas de las interacciones. Han de ser tan detalladas como para permitir una generación automática de código. El nivel de detalle es función de las entidades que se escogen para implementar las interacciones.
o Contexto de las interacciones. Las interacciones contextualizadas en los flujos de trabajo de la organización y con información adicional acerca de las condiciones de participación en la interacción.
o Conjunto de unidades de interacción asociadas a los participantes. Cada participante en las interacciones comparte con los otros unidades de interacción. Esto forma parte de la descripción funcional del agente.
Para lograr estos resultados se proponen las siguientes actividades:
§ Productos. Un conjunto de objetivos asociados a la interacción mediante instancias de IPersigue.
§ Productos. Un conjunto de roles o agentes asociados a la interacción mediante relaciones IInicia e IColabora.
3. Identificar la naturaleza de la interaccion. La naturaleza de la interaccion influye en el tipo de control que se va a aplicar al agente. Si se necesita generar una secuencia de tareas para alcanzar un objetivo, la naturaleza es planificación. Si se trata de intercambiar mensajes en un orden concreto y un contenido predecible, se habla de cooperación. Si hay recursos limitados o existe algún bien que regula la predisposición de los agentes a colaborar, se tendrá negociación. Las negociaciones siguen reglas concretas, como el contract-net [Smith 80] . Cuando éstas no son rígidas y hay libertad para que un agente acapare recursos o bienes del sistema, se tendrá competición.
§ Productos. caracterización del tipo de interacción según la clasificación de [Huhns 00] (Ilustración 32 ).
4.a. Identificar mensajes intercambiados. Para cada actor, determinar los mensajes intercambiados estableciendo el orden en que son pasados de un actor a otro y el propósito de los mismos.
§ Productos: Un conjunto de pasos de mensaje etiquetados según la notación de UML (notación de secuencia, guardas, nombre de operación y parámetros)
4.b. Identificar emisores y receptores. Cada mensaje necesita de un un emisor y uno o varios receptores. Aunque aún no es momento de pensar acerca de la motivación de cada uno, sí que se puede determinar para cada participante qué mensajes envía y cuáles recibe.
§ Productos: Se obtiene un diagrama de colaboración UML donde los actores son roles o agentes.
Ilustración 86. Actividades de análisis para la generación de modelos de interacciones
Ilustración 87. Actividades de diseño para la generación de modelos de interacciones
5. Generar una especificación GRASIA. La especificación GRASIA ha sido elaborada pensando en separar la ejecución de unidades de interacción de la asociación entre emisor y receptor. Esta separación es útil a la hora de generar código automáticamente.
§ Productos: Un conjunto de unidades de interacción donde cada unidad de interacción se corresponde con uno o más mensajes.
§ Productos: Instancias de las relaciones UIInicia y UIColabora asociadas a las unidades de interacción.
§ Productos: Un conjunto de patrones de estado mental asociados a las relaciones UIInicia y UIColaba.
§ Productos: Instancias de las meta-relaciones UIItera, UIConcurren, Precede y Bifurca ordenando la ejecución de las unidades de interacción.
6. Actualizar modelos con los requisitos de las plataformas destino. Implica por lo general añadir información a la presentada en el modelo. Esta nueva información surge de la necesidad de instanciar un armazón software para que lleve a cabo las especificaciones del modelo. Según los requisitos impuestos por el armazón software, la especificación del sistema debiera modificarse. Así, un armazón software donde la comunicación entre agentes es importante, como JADE, influiría pidiendo un nivel de detalle alto en los modelos de interacciones.
§ Productos. Nuevas entidades en el modelo o más detalle en las existentes.
7. Validar el modelo contra los otros modelos. La validación se realiza según los criterios de la sección 2.3.4 del capítulo segundo.
§ Productos: Lista de inconsistencias
8. Corregir el modelo. Para hacer el modelo consistente con las instancias de otros meta-modelos
§ Productos: Modificaciones a efectuar.
El meta-modelo de interaccion refleja el comportamiento deseado de un agente cuando recibe instrucciones de otro agente o bien requiere de otro agente para realizar una tarea. Como en los modelos de agentes, la generación de modelos de instancias se inicia en el análisis y se continúa en el diseño.
Para el análisis se ha fijado que los resultados esperables son:
o Tareas y objetivos. Los objetivos que se persiguen en el sistema, que han de ser resumen de todos los incluidos en los modelos de agente y organización. Se admite la descomposición estructural de tareas y objetivos (GTDescompone y WFDescompone). De hecho, se espera que se aplique con vistas a disminuir su complejidad. Esta descomposición se acompaña de dependencias entre objetivos (GTDepende)
o Tareas asociadas a objetivos. La asociación consiste inicialmente en instancias de GTAfecta que evolucionarán en el diseño hacia GTSatisface o GTFalla. Esta asociación constituye la justificación de la ejecución de la tarea.
o Precondiciones y postcondiciones tentativas. Las precondiciones mínimas son determinar qué entidades mentales se consumen (WFConsume), qué interacciones y entidades mentales se producen (WFProduce y GTCrea) y qué aplicaciones se usarán en el proceso (WFUsa).
Ilustración 88. Actividades de análisis para la generación de modelos de tareas y objetivos
Ilustración 89. Actividades de diseño para la generación de modelos de tareas y objetivos
Para el diseño se ha fijado que los resultados esperables son:
o Refinamiento de las dependencias entre objetivos. Se detalla la dependencia indicando si se trata de dependencia Y (GTDependeY) o dependencia O (GTDependeO). Las dependencias pueden desaparecer con motivo de cambios en la dependencias estructurales entre objetivos.
o Condiciones de satisfacción o fallo de los objetivos. Las relaciones GTAfecta entre tareas y objetivos evolucionan a GTFalla y GTSatisface. En estos dos casos es necesario además indicar bajo qué condiciones se asume el éxito o fracaso del objetivo. Estas condiciones se expresan con patrones de estado mental.
o Precondiciones detalladas. El detalle en las precondiciones viene de añadir los recursos que necesita la tarea (WFUsa) y de incluir nuevas instancias de WFConsume, GTDestruye, GTModifica. Estas dos últimas se interpretan como precondiciones en el sentido de que requieren la existencia de la entidad mental con la que se relaciona.
o Postcondiciones detalladas. Se asocian nuevas instancias WFProduce con recursos para expresar la restitución de los mismos. Adicionalmente, se incluyen instancias WFUsaLlamada que expresan qué operaciones se están utilizando de las aplicaciones asociadas. Asimismo, se incluyen instancias de GTDestruye, GTModifica y GTCrea para mostrar cómo se modifica el estado mental. Se pueden asociar también entidades mentales con WFProduce, pero en dicho caso se interpreta la producción en términos de flujo de trabajo (información pasada de una tarea a otra).
Para conseguir estos resultados, se proponen las siguientes actividades:
§ Producto: Un conjunto de objetivos y tareas.
2. Asociar tareas a objetivos. Las asociación de tareas a objetivos se hace mediante instancias de meta-relaciones GTAfecta. Esta asociación determina cómo se satisface un objetivo, pero los objetivos también se pueden satisfacer mediante instancias de GTDepende. Por ello, no existe obligación de que todos y cada uno de los objetivos esté asociado con una tarea (el recíproco no es cierto).
§ Producto: Un conjunto de objetivos y tareas asociados por meta-relaciones GTAfecta.
§ Productos: Un conjunto de tareas asociadas con la relación WFDescompone.
§ Productos: Un conjunto de objetivos relacionados por instancias de GTDescompone.
§ Productos: Cada sub-objetivo relacionado con el objetivo padre mediante GTDepende.
6. Precondiciones y postcondiciones tentativas. Es necesario establecer a nivel de análisis qué es necesario para ejecutar las tareas y cuales son las consecuencias para el agente. Parte de las pre y postcondiciones se han fijado ya con instancias de meta-relaciones GTDepende y GTAfecta.
§ Productos: Asociaciones entre interacciones y tareas con WFProduce.
§ Productos: Asociaciones entre tareas y entidades mentales mediante instancias de WFProduce y GTCrea.
§ Productos: Asociaciones entre tareas y entidades mentales mediante instancias de GTDestruye.
§ Productos: Asociaciones entre tareas y aplicaciones mediante instancias de WFUsa.
7. Identificar postcondiciones de tareas. Las postcondiciones establecidas hasta ahora son sólo indicaciones de lo que puede pasar que no entran en detalles. Las actividades que se enmarcan dentro de ésta se orientan a la obtención de una descripción detallada de los efectos de las tareas.
§ Productos: Instancias de WFProduce asociando tareas y recursos.
§ Productos. Instancias de GTSatisface y GTFalla asociando tareas y objetivos.
§ Productos: Instancias de WFUsaLlamada indicando la operación utilizada sobre la aplicación.
8. Identificar precondiciones de las tareas. Las precondiciones en el diseño recogen información adicional respecto a los recursos consumidos y las entidades mentales que se utilizan como entradas para las tareas.
§ Productos: Nuevas entidades mentales, modificaciones en entidades existentes, instancias de WFConsume
§ Productos: Instancias de WFUsa asociando tareas y recursos.
9. Actualizar modelos con los requisitos de las plataformas destino. Implica por lo general añadir información a la presentada en el modelo. Esta nueva información surge de la necesidad de instanciar un armazón software para que lleve a cabo las especificaciones del modelo. Según los requisitos impuestos por el armazón software, la especificación del sistema debiera modificarse. Así, un armazón software donde la comunicación entre agentes es importante, como JADE, influiría pidiendo un nivel de detalle alto en los modelos de interacciones.
§ Productos. Nuevas entidades en el modelo o más detalle en las existentes.
10. Refinar dependencias de objetivos. Los objetivos se alcanzan o bien por sus dependencias respecto de otros objetivos existentes o bien por sus asociaciones con tareas.
§ Productos.Instancias de GTDependeY o GTDependeO.
§ Productos. Instancias de GTSatisface y GTFalla asociadas con instancias de patron de estado mental.
11. Validar el modelo contra los otros modelos. La validación se realiza según los criterios de la sección 2.4.5 del capítulo segundo.
§ Productos: Lista de inconsistencias
12. Corregir el modelo. Para hacer el modelo consistente con las instancias de otros meta-modelos
§ Productos: Modificaciones a efectuar.
El meta-modelo de organización es comparable a la arquitectura del sistema en un SMA. Este meta-modelo relaciona las entidades activas (agentes, roles), pasivas (aplicaciones, recursos) y los elementos que proporcionan la funcionalidad del sistema (flujos de trabajo, tareas). Por ello, es aconsejable que este meta-modelo sea el primero en estudiarse para generar meta-modelos y que se vuelva a él con frecuencia a medida que van apareciendo nuevos elementos en los demás modelos.
Para el análisis se ha fijado que los resultados esperables son:
o Estructura de la organización. La idenficicación de los elementos del sistema es primordial. El detalle aquí alcanzado ha de ser el mayor posible, ya que ello posibilitará el tratamiento de las entidades encontradas en el resto de actividades.
o Flujos de trabajo. Aunque no se llegue a un gran detalle, hay que generar una lista de las tareas, con sus responsables correspondientes, conectadas unas con otras y resaltando aquellas tareas cuya ejecución afecte a otros agentes.
o Dependencias sociales. En el análisis basta con tejer una red de instancias de AGORelacion como se definieron en el meta-modelo de organización.
Para el diseño se ha fijado que los resultados esperables son:
o Contexto de ejecución de las tareas. Las tareas se asocian con sus ejecutores para indicar quien se ve afectado por ellas, qué recursos y entidades mentales se consumen y qué entidades de información se producen.
o Refinamiento de las dependencias sociales. Hay que detallar qué tipo de relaciones se están definiendo cuando se interconectan dos entidades con AGORelacion. Concretamente, se debe determinar si hay o no subordinación o si se trata de una relación cliente-servidor, indicando en cada caso las condiciones de prestación de servicio y el servicio en sí.
Ilustración 90. Actividades del análisis para generación de modelos de organización
Ilustración 91. Actividades del diseño para generación de modelos de organización
Para conseguir estos resultados, se proponen las siguientes actividades:
1. Generar Definición Estructural. Antes de comenzar cualquier otra actividad, hay que identificar las entidades que componen el sistema, en este caso, agentes, roles, recusos, aplicaciones, grupos y organizaciones.
§ Productos: Un conjunto de grupos asociados a la organización por instancias de OContieneOrganizacion.
§ Productos: Un conjunto de roles, agentes, recursos y aplicaciones asociados a uno o varios grupos mediante instancias de OContieneGrupo.
1.c. Aplicar descomposición grupos para reducir complejidad. La complejidad de los grupos que actúan en ellos puede ser demasiado elevada en algunos casos. Mediante la descomposición (aplicando divide y vencerás) el ingeniero asigna trabajo a los diferentes componentes del equipo de desarrollo para facilitar la construcción del SMA.
§ Productos: Nuevos grupos asociados a los grupos existentes mediante instancias ODescomponeGrupo.
2. Generar definición funcional. La especificación funcional en el análisis se construye identificando las tareas más relevantes, relacionándolas con sus ejecutores y entre sí y destacando aquellas tareas que conllevan la ejecución de tareas en otros agentes.
§ Productos: Un conjunto de flujos de trabajo asociados a la organización por instancias de OContieneFlujoTrabajo.
§ Productos: Nuevos flujos de trabajo asociados a los flujos de trabajo existentes mediante instancias ODescomponeFlujo.
§ Productos: Objetivos asociados a la organización mediante instancias de GTPersigue.
3. Generar definición social. La definición social en el análisis se limita a identificar la existencias de relaciones sociales a cada uno de los tres niveles organizativos expuestos al presentar la definición de relaciones sociales en el meta-modelo de organización.
§ Productos: Instancias de AGORelacion entre organizaciones.
§ Productos: Instancias de AGORelacion entre grupos
§ Productos: Instancias de AGORelacion entre agentes o roles.
4. Refinar dependencias entre organizaciones, grupos, roles y agentes. Durante el diseño, las relaciones sociales del análisis se refinan en dependencias concretas del tipo AGOSubordinacionCondicional, AGOSubordinacionIncondicional o AGOClienteServidor.
§ Productos:Instancias de AGOSubordinacionCondicional, asociadas a instancias de patrones de estado mental para indicar las condiciones de obediencia, o AGOSubordinacionIncondicional
§ Productos: Instancias de AGOClienteServidor
5. Refinamiento de la descripción funcional. La descripción funcional en el diseño ha de ser lo más detallada posible desde el punto de vista de interacción con otras tareas. De forma individual, las tareas se describen en el meta-modelo de tareas y objetivos.
5.a. Identificar tareas. Se trata de identificar tareas dentro de los flujos de trabajo definidos en el análisis. Las tareas a ejecutar se pueden obtener mediantes técnicas convencionales de ingeniería del software a partir de la especificación del problema o bien obtenerse de otros modelos (modelo de tareas y objetivos, modelo de agente). Estas tareas se asocian a los flujos de trabajo mediante relaciones de pertenencia y relaciones de flujo de datos (WFProduce, WFConecta, WFConsume).
§ Productos: Un conjunto de tareas asociadas a flujos de trabajo.
§ Productos: Instancias de WFConecta conectando las distintas tareas.
5.c. Identificar tareas no locales. Las tareas que conlleven la ejecución de otras tareas en otros agentes se identifican asociándoles una interacción. Se asume que en un flujo de trabajo, donde cada tarea previsiblemente se ejecutará en distintos agentes, sólo produce una interacción la tarea que da comienzo al flujo de trabajo. Estas tareas se asocian con la interacción con instancias de WFEspecificaEjecucion.
§ Productos: Instancias de Interaccion asociadas con tareas mediantes instancias de WFProduce y WFEspecificaEjecucion.
§ Productos: Instancias de WFResponsable asociando agentes o roles y tareas
§ Productos: Instancias de WFUsa y WFProduce asociando recursos a las tareas.
§ Productos: Instancias de WFConsume asociando a las tareas entidades mentales requeridas. Instancias de WFProduce asociando instancias de entidades mentales generadas por las tareas.
6. Actualizar modelos con los requisitos de las plataformas destino. Implica por lo general añadir información a la presentada en el modelo. Esta nueva información surge de la necesidad de instanciar un armazón software para que lleve a cabo las especificaciones del modelo. Según los requisitos impuestos por el armazón software, la especificación del sistema debiera modificarse. Así, un armazón software donde la comunicación entre agentes es importante, como JADE, influiría pidiendo un nivel de detalle alto en los modelos de interacciones.
§ Productos. Nuevas entidades en el modelo o más detalle en las existentes.
7. Validar el modelo contra los otros modelos. La validación se realiza según los criterios de la sección 2.5.4 en el capítulo segundo
§ Productos: Lista de inconsistencias
8. Corregir el modelo. Para hacer el modelo consistente con las instancias de otros meta-modelos
§ Productos: Modificaciones a efectuar.
La mayoría de la información para la generación de instancias del meta-modelo de entorno proviene de la captura de requisitos, que es la entrada para el análisis.
Para el análisis se ha fijado que los resultados esperables son:
o Entidades del entorno. Una enumeración de las entidades que preceden al sistema a desarrollar. Estas entidades se categorizan como aplicaciones, agentes o recursos. Cada entidad se acompaña de una descripción de sus funciones, que se entiende han de extraerse de la captura de requisitos.
o Percepción del agente. Aunque se detallará más adelante, la percepción del agente se asocia con las aplicaciones del entorno.
Para el diseño se ha fijado que los resultados esperables son:
o Configuración de la percepción del agente. Cada agente asociado con aplicaciones explicita cómo va a percibir, si va a utilizar mecanismos de muestreo o notificación y qué es lo que espera recibir.
o Relaciones con tareas. Aunque se considera en otros meta-modelos, se identifican asociaciones de producción y utilización de aplicaciones y recursos con tareas.
o Definición detallada de los recursos. Consiste en especificar exactamente cómo es cada recurso, detallando su categoría concreta, el límite inferior de consumo, el superior y el estado en que se encuentra inicialmente.
Para conseguir estos resultados, se proponen las siguientes actividades
1. Identificar aplicaciones. Las aplicaciones se conciben como objetos. Será una aplicación todo software o hardware con que el sistema debe interactuar y que no puede ser modelado (o no conviene) como agente.
§ Productos: Conjunto de instancias de AplicacionEntorno
§ Productos: Conjunto de instancias de AplicacionInterna.
Ilustración 92. Actividades de análisis para la generación de modelos de entorno
Ilustración 93. Actividades de diseño para la generación de modelos de entorno
§ Productos: Un conjunto de instancias de Operación asociadas a las aplicaciones.
§ Productos: Los establecidos por el método elegido
4. Identificar agentes del entorno. Los agentes del entorno son entidades similares a las instancias de aplicación solo que son modelables utilizando los meta-modelos aquí presentados. Principalmente, se aplica el principio de racionalidad para distinguirlas del software convencional, aunque se cuenta con que dentro de la captura de requisitos ya aparecen identificados.
§ Productos: Un conjunto de agentes
5. Definir agentes utilizando los meta-modelos. Para el caso en que se trate de software convencional que hay que recubrir con una capa de software de agentes, se aplican los meta-modelos aquí expuestos para definir el nuevo agente.
§ Productos: Instancias de los meta-modelos de agente, organización, tareas y objetivos, entorno e interacción para los nuevos agentes.
§ Productos: Instancias de EPercibe asociando agentes a instancias de aplicación.
§ Productos: Instancias de Recurso.
8. Asociar recursos a agentes y grupos. Los recursos se asocian a agentes o roles, indicando quién es el responsable de su gestión. Cuando se asocian a un grupo, no hay un responsable directo, salvo que el ingeniero acuerde tácitamente que determinado agente o rol es responsable de los recursos de su grupo.
§ Productos: Instancias de ERecursoPertenece asociando recusos a agentes o grupos.
§ Productos: Instancias de EPercibeNotificacion y EPercibeMuestreo donde antes había solo instancias de EPercibe. Es obligatorio el indicar la operación asociada.
§ Productos: Los establecidos por el método elegido
§ Productos: Determinar el valor de los umbrales de los recursos y su estado inicial
§ Productos: Instancias de WFUsa asociando tareas y aplicaciones. Instancias de WFConsume y WFProduce asociando tareas y recursos
13. Actualizar modelos con los requisitos de las plataformas destino. Implica por lo general añadir información a la presentada en el modelo. Esta nueva información surge de la necesidad de instanciar un armazón software para que lleve a cabo las especificaciones del modelo. Según los requisitos impuestos por el armazón software, la especificación del sistema debiera modificarse. Así, un armazón software donde la comunicación entre agentes es importante, como JADE, influiría pidiendo un nivel de detalle alto en los modelos de interacciones.
§ Productos. Nuevas entidades en el modelo o más detalle en las existentes.
14. Validar el modelo contra los otros modelos. La validación se realiza según los criterios de la sección 2.6.4 en el capítulo segundo
§ Productos: Lista de inconsistencias
15. Corregir el modelo. Para hacer el modelo consistente con las instancias de otros meta-modelos
§ Productos: Modificaciones a efectuar.
La fase de implementación en esta tesis se plantea como la parametrización de un armazón software ya existente. Existen múltiples desarrollos que pueden servir como armazón software, por ejemplo, los ya vistos, JADE, ZEUS o Grasshopper. Sobre estos armazones se construrían esqueletos genéricos que serían concretados más tarde con los datos de los modelos que especifican el SMA.
Este planteamiento es diferente del adoptado por la mayoría de las herramientas de análisis y diseño, donde la generación automática de código es fija y sin posibilidad de modificación. Herramientas como Rational Rose o TogetherJ trabajan con elementos como diagramas de secuencia y de estados para los que existen representaciones únicas dentro de un lenguaje destino a elegir por el desarrollador (JAVA , Smalltalk, C++).
A diferencia de estas herramientas, en este trabajo se busca traducciones de los modelos en elementos conocidos como máquinas de estado, protocolos o arquitecturas de agente. Estos elementos se suponen organizados para formar un armazón de SMA. Para facilitar esta traducción, se propone un método genérico de parametrización de armazones basado en el marcado con XML del código del armazón. A grandes rasgos, el proceso consiste en sustituir el código marcado en el armazón por información elaborada a partir de los modelos que componen la especificación.
La selección de un armazón adecuado es importante. El armazón destino debe reunir ciertos elementos recogidos en los modelos, por ejemplo, elementos a cargo de la gestión del estado mental o de la toma de decisiones.
En esta sección, primero se describe informalmente el proceso completo de generación del sistema para ubicar la parte de parametrización del armazón. A continuación se describen los elementos que se utilizan en la parametrización, las plantillas y las secuencias. El proceso en sí se presenta después utilizando diagramas de decisión. Para terminar, algunas consideraciones sobre el armazón sobre el que se aplicará el proceso.
La generación de código se realiza de acuerdo con las actividades de la Ilustración 94 .
Ilustración 94. Actividades para la generación automática de código
La generación de modelos consiste en el diseño del sistema utilizando los meta-modelos de este trabajo. Se soporta con la herramienta METAEDIT+, que genera editores de modelos personalizados para cada uno de los meta-modelos.
Al análizar los modelos se transforma la representación de METAEDIT+ en un conjunto de predicados PROLOG más sencillos de procesar. La transformación se hace también desde PROLOG.
La generación de secuencias se hace teniendo en cuenta los parámetros que admite el armazón sobre el que se va a trabajar. Las secuencias son listas de listas de términos clave = valor. Esta parte es dependiente del armazón destino, por lo que debe ser programada especialmente para cada tipo de armazón.
Por último, la instanciación del armazón se realiza utilizando el intérprete de lenguaje de marcado de PiLLOw (Programming in (Constraint) Logic Languages on the Web) [Departamento de Inteligencia Artificial (UPM) 02] . La instanciación consiste en sustituir marcas (tags) en el armazón por el valor indicado en las secuencias del paso anterior.
El resultado final es un armazón parametrizado donde los programadores tienen que insertar su código. El proceso se realiza mediante la utilización de plantillas marcadas.
Como ya se ha comentado, parte del código dentro del armazón sobre el que se desarrolla está marcado. Las partes que están marcadas se denominan plantillas. Las plantillas pueden estar escritas en cualquier lenguaje de programación, siembre que se respeten las marcas establecidas. Las marcas indican los lugares donde se ubicarán los datos extraídos de los modelos. Las plantillas, entonces, se conciben como documentos XML que satisfacen la especificación de la Ilustración 95 .
Para rellenar las plantillas, se utilizan la misma solución que en los lenguajes de que integran SQL en páginas HTML. La información de las instancias del meta-modelo se pasa a un formato de listas de listas de términos igualdad (ver Ilustración 96 ) . Estas secuencias se incrustan en las plantillas mediante dos clases de etiquetas: repeat y v (de variable).
Ilustración 95. Especificación de una plantilla con marcado con esquemas XML.
La etiqueta repeat tiene un atributo id cuyo valor sirve para identificar las secuencias que contienen datos relevantes para el fragmento de código actual. Estas secuencias se caracterizan por contener un identificador id con el mismo valor asociado que en la plantilla. Para repeat anidados, se admite la existencia de múltiples id siempre y cuando no se repitan sus valores. La etiqueta v señala la existencia de una variable cuyo identificador aparece en la secuencia considerada.
Ilustración 96. Expresión BNF para definir secuencias de datos.
Las secuencias que describen la parametrización del armazón se especifican con la Ilustración 96 . Se trata de listas de listas de términos identificador = valor. El identificador se utiliza para identificar la variable a sustituir (marca v de la Ilustración 95 ). Existe un identificador reservado. Este identificador es id y se utiliza para identificar secuencias, posiblemente anidadas, de parametrizaciones.
El proceso para la reescritura de las plantillas está escrito íntegramente en PROLOG (ver Anexo I. ). La idea general es que hay que sustituir las etiquetas de las plantillas por información de los modelos. La información de los modelos viene en forma de lista de listas de términos que han de ser cotejados contra los identificadores asociados a las etiquetas repeat y v en la plantilla. El proceso se basa en la librería PiLLOW. Esta librería lee cualquier documento de texto y es capaz de extraer las marcas. El resultado es una lista de términos donde hay etiquetas o texto. El proceso (ver Ilustración 97 ) comienza analizando la plantilla.
Tras el análisis, se procede a estudiar la lista resultante, comprobando si el término a analizar es texto o una etiqueta. Si es texto, se imprime por pantalla. Si es una etiqueta y además un repeat, se filtran las secuencias que contienen la información de los modelos dejando solo aquéllas que contengan un término id cuyo valor coincida con el del atributo id de la etiqueta repeat encontrada. Con las secuencias filtradas, se vuelve a aplica recursivamente el análisis. Cuando la etiqueta es v, se realiza una sustitución de la etiqueta por el valor asociado dentro de las secuencias de datos de los modelos.
Al término del proceso, todas las etiquetas de la plantilla han desaparecido y sólo quedan los valores extraidos de los modelos ya situados en el código del armazón. Como ejemplo de aplicación, la Ilustración 98 muestra cómo se instancia una plantilla de regla de producción con una secuencia de datos ficticia.
Ilustración 97. Diagrama de decisión del proceso de instanciación de plantillas
Ilustración 98. Ejemplo de aplicación de secuencias a plantillas.
Los modelos generados para especificar un SMA definen implícitamente un conjunto de patrones arquitectónicos que deben soportarse en la arquitectura final. Los patrones arquitectónicos se entienden como abstracciones de arquitecturas del sistema y sus componentes. Al identificar el conjunto de elementos necesarios para definir el agente y el SMA, se está aludiendo a qué elementos han de estar presentes en la arquitectura que soporte el SMA, cómo se relacionan y qué funcionalidad deben aportar.
Respecto de la arquitectura del agente, los meta-modelos indican que deben existir componentes que representen:
§ El estado mental. Contiene toda aquella información que permite al agente tomar decisiones. A lo largo de la tesis, se ha expresado el estado mental como agregación de entidades mentales utilizando instancias del modelo de agente. Se ha distinguido entre el estado mental inicial del agente, asociando el agente a una instancia de estado mental, y los estados mentales intermedios, asociando una instancia de consulta autónoma a una instancia de estado mental. El paso del estado mental inicial por cada uno de los intermedios se indica mediante la ordenación de tareas dentro de flujos de trabajo e interacciones, que son las que modifican el estado mental. El estado mental, en este trabajo, se ha descrito de forma simbólica, por lo que se espera que en la arquitectura aparezca de igual forma. Sin embargo, hay desarrollos precedentes que muestran que no es necesario. Así, en los Situated Autómata se establecen procedimientos para transformar especificaciones simbólicas en autómatas equivalentes [Rosenschein y Kaelbling 95]
§ El gestor de estado mental. Describe cómo se gestionan las entidades mentales. Este gestor completa la definición de la evolución del estado mental estableciendo, por ejemplo, qué ocurre con los objetivos una vez se alcanzan, qué entidades ya no son válidas y si se pueden añadir nuevas entidades mentales mientras se está tomando una decisión. Estos aspectos se definen utilizando texto y modelos de tareas y objetivos.
§ El procesador de estado mental. Es el encargado de tomar las decisiones a partir del estado mental. A la descripción textual de este elemento se añade una descripción en forma de modelos y tareas. A veces es suficiente con decir que se trata de un planificador STRIPS, otras hay que detallar un conjunto de tareas que describan cómo se activan otras tareas.
§ Percepción. La percepción del agente obliga a que la arquitectura considere la comunicación con elementos anteriores a la construcción del sistema o con nuevos elementos identificados durante el análisis y el desarrollo. La percepción se puede encapsular en un componente o aparecer distribuida en un conjunto de componentes especializados.
§ Otros componentes. Durante el desarrollo aparecen instancias de aplicación asociadas al agente dentro del modelo de entorno. Estas asociaciones se trasladan a la arquitectura como componentes casi directamente ya que se trata de elementos cuyo desarrollo se hace utilizando técnicas convencionales, como tecnología de objetos.
Alguno de estos elementos son combinables, como el procesador y gestor de estado mental, dentro de la arquitectua final. De hecho, los motores de reglas, como se verá más tarde, son combinación de los elementos de gestión y procesamiento del estado mental.
Respecto a patrones arquitectónicos del SMA, su tratamiento difiere de los de los agentes. Estos patrones, no implican la existencia de una entidad SMA como componente, ya que en la mayoría de desarrollos existentes, los componentes asociables al SMA como tal se distribuyen entre los agentes del sistema, buscando sobre todo la descentralización. De cualquier forma, la arquitectura que soporte el SMA, debe tener en cuenta:
§ Coordinación. Las interacciones constituyen el comportamiento del agente cara a otros agentes. Dependiendo de cómo se planteen las interacciones, la arquitectura deberá soportar comunicación síncrona, asíncrona, dirigida por datos o dirigida por mecanismos de control [Papadopoulos y Arbab 98] . Además, hay que tener en cuenta que el agente puede participar en varios procesos de coordinación simultáneos, por lo que serán necesarios mecanismos de gestión de sesiones de comunicación.
§ Restricciones sociales. Las restricciones sociales se observan en la implementación mediante elementos que limiten las actuaciones o las percepciones de los agentes. Estas restricciones pueden aparecer como condiciones adicionales para la ejecución de tareas o como componentes arquitectónicos que inhiben al agente.
§ Funcionalidad. La funcionalidad del sistema se recoge principalmente en tareas, flujos de trabajo y objetivos. La existencia de tareas en la arquitectura final es difícil de evitar. Sin embargo, en el caso de los flujos de trabajo y los objetivos, se pueden obviar. MaSE consigue omitir los objetivos igualando un rol a un objetivo durante la implementación,. Los flujos de trabajo, aunque no aparezcan explícitamente, estarán presentes en la arquitectura como asociación entre tareas.
§ Estructuración del sistema. El modelo de organización proporciona una estructuración de elementos que sirve de partida a la hora de elaborar la arquitectura final del sistema. La estructuración en grupos es similar a la estructuración en paquetes aplicada en JAVA. A diferencia de los paquetes JAVA, la inclusión de los grupos en la organización se rige por la conveniencia de la agrupación en tanto se facilite la la consecución de los objetivos de la organización. La arquitectura final del sistema respetará esta estructura y proporcionará, si fuera necesario, mecanismos de gestión de los miembros de la organización así como servicios de localicación y, en caso necesario, matchmaking.
Para facilitar la revisión de estos aspectos de la especificación, se ha organizado la documentación del sistema siguiendo una estructura similar a la enumeración ya vista. Parte de estos aspectos ya han sido estudiados dentro de MESSAGE, identificando elementos computacionales que parecen especialmente adecuados como implementación de las especificaciones aquí mostradas. Estos componentes se utilizaron durante el desarrollo de MESSAGE como implementación de las especificaciones iniciales:
· Motores de reglas. Se usan para definir el comportamiento del agente. Se han utilizado especialmente motores de reglas de inferencia con encadenamiento hacia delante y hacia atrás. Estos motores permiten gestionar eficientemente la ejecución de un conjunto grande de reglas. La definición de reglas así como su gestión se consigue a través de un lenguajes de definición de reglas específico del motor. Las reglas constan de guardas, tambien conocidas como parte izquierda de la regla o LHS (Left Hand Side), y acciones, tambien conocidas como parte derecha de la regla o RHS (Right Hand Side). Su funcionamiento se limita a chequear la parte izquierda de la regla contra la memoria de trabajo del motor, si se satisfacen las guardas, entonces se ejecuta de forma mutuamente exclusiva la parte derecha de la regla. Las reglas pueden utilizarse para propósitos de gestión y procesamiento del estado mental mientras que las entidades mentales se pueden mostrar como hechos. Las restricciones sociales también se presentan dentro de un motor de reglas como reglas de alta prioridad o como guardas adicionales en las reglas existentes.
· Máquinas de estado para los protocolos. Las interacciones se pueden codificar en forma de máquinas de estados, donde dentro de cada estado o en la transición de un estado a otro se ejecutan tareas. Es importante la reutilización y flexbilidad de la implementación de la máquina de estados. Para el caso de MESSAGE, ya que se implementaban muchos protocolos, se diseñó un intérprete para plantillas de definición de máquinas de estado en XML. Gracias a este intérprete, las modificaciones en la comunicación tenían un impacto reducido en el diseño.
· Comunicación CORBA y FIPA ACL. Se utiliza para implementar las unidades de interacción. La comunicación mediante paso de mensajes utilizando FIPA ACL puede ser una buena opción desde las especificaciones de esta metodología, ya que en cada unidad de interacción se están transportando entidades mentales de un agente a otro. FIPA ACL se adecúa a este uso con facilidad, ya que el paso de mensajes es asíncrono y además contempla el transporte de entidades mentales de un agente a otro. Sin embargo, diseñar un agente que se comunique correctamente utilizando FIPA ACL no es trivial. Uno de los mayores problemas consiste en verificar la estructura y contenido de los mensajes, ya que es muy fácil que, debido a errores de programación, se malformen los mensajes. En este sentido, uso de CORBA es más sencillo y seguro ya que define interfaces de forma convencional y no requiere arquitecturas que soporten mensajería asíncrona.
Objetos. La POO es conveniente para representar y encapsular el comportamiento de entidades como las tareas, los objetivos o los eventos. Para la representación de tareas, OMG proporciona un conjunto de interfaces compatibles con el uso de las tareas tal y como se ha mostrado aquí [OMG 00c] . Para los objetivos, reutilizando la experiencia de proyectos anteriores [Gomez-Sanz, Garijo y Pavon 00]" ADDIN REFMAN ÿ\11\05‘\19\01\00\00\00\1F[Gomez-Sanz, Garijo y Pavon 00]\00\1F\00\13d:\5Ctesis\5Crefinitiva\03\00\03139'Gomez-Sanz, Garijo, et al. 2000 139 /id\00'\00 [Gomez-Sanz, Garijo y Pavon 00] , se diseñaron estructuras de datos arbóreas que facilitaban la gestión de los mismos. Estas estructuras se basaban en los arboles Y/O ya comentados en la presentación del meta-modelo de objetivos y tareas (ver sección 2.4 ).
Este capítulo se ha mostrado una integración de la generación de la especificación del sistema como una actividad más en el modelo de desarrollo del RUP. La integración se ha planteado por un lado definiendo qué productos son deseables en cada iteración y fase, y por otro qué actividades se involucran en cada fase de desarrollo.
En este trabajo, estas actividades han sido tomadas como guía de los productos que deberían generarse y de las posibles dependencias que se pueden encontrar los usuarios finales de esta metodología. Aunque su número es elevado, no se plantea en ningún momento que el proceso de desarrollo tenga que seguir tantos pasos. Los usuarios pueden decidir unir varias actividades para generar otras más genéricas siempre y cuando se respeten los productos que se deben generar. Además, las actividades identificadas constituyen un punto de partida para futuros trabajos. Su número y propósito concreto deberán ser probados en distintos desarrollos.
En cuanto a la composición de las actividades dentro de los diagramas de actividades de análisis y diseño, no se prevén cambios en estos diagramas al variar las iteraciones. Los diagramas marcan las dependencias entre las actividades y, por lo tanto, el orden en que debieran producirse cada parte del modelo completo. Si el desarrollador en una iteración encuentra que el nivel de detalle alcanzado por una actividad es suficiente, entonces, puede dar la actividad por concluida.
La implementación final del sistema se ha estudiado desde dos puntos de vista: como un proceso automatizado de parametrización de arquitecturas software y como un problema de aplicación de patrones arquitectónicos de diseño. Dentro del primer enfoque, se ha proporcionado un medio de instanciación de arquitecturas software que toma como entrada los modelos que forman la especificación del sistema. Dentro del segundo, se ha estudiado qué patrones arquitectónicos son más relevantes y qué elementos computacionales pueden soportarlos.