1.1 Análisis-Elaboración

Se analizan los casos de uso que se consideran relevantes para obtener la arquitectura del sistema, en este caso, la estructura de la organización y los flujos de trabajo fundamentales. Los casos de uso de la etapa anterior se refinan y se asocian con modelos de interacciones para estudiar cómo se llevan a cabo.

1.1.1  Estructuración de la etapa

Cada modelo de interacción se inicia con la actividad identificar los objetivos que persigue la interacción (1 ), que puede partir del conjunto de objetivos identificados en la organización, identificar su naturaleza (3 ), que dados los objetivos no puede ser otra cosa que cooperación, e identificar los participantes (2 ), en este caso roles para agrupar la funcionalidad que se irá descubriendo. La especificación inicial de las interacciones se hace mediante diagramas de colaboración de UML, siguiendo la actividad generar una primera especificación (4 ).

Para conocer mejor los agentes de la organización de la etapa anterior, se elaboran modelos de agente. La actividad Identificar agentes utilizando el principio de racionalidad (1 ) no es necesaria ya que se conocen de antemano qué agentes van a existir, no obstante se puede utilizar esta actividad para verificar la corrección de la decisión. Los objetivos del agente, actividad identificar los objetivos (2.a ) se deducen a partir de los objetivos de la organización y del papel que se prevee van a jugar los agentes en ella. La funcionalidad surge asociando tareas a los objetivos, ya identificados, y roles al agente según la actividad identificar funcionalidad (2.b ) y asociar funcionalidad con objetivos (2.c ). Los aspectos de autonomía e inteligencia son función directa de la especificación del comportamiento del agente (modelos de interaccion, organización, tareas y objetivos). Por ello, antes de ejecutar la actividad identificar aspectos de autonomía e inteligencia ( 3 ) y determinar cómo será el gestor y procesador de estado mental (4 ) sería conveniente avanzar los otros modelos.

Todos los objetivos y tareas identificados se organizan dentro de modelos de tareas y objetivos. Estas tareas y objetivos aparecen tras la ejecución de las actividades Identificar tareas y objetivos (1 ) y asociar tareas a objetivos (2 ). Tras estas actividades, se plantea la descomposición de objetivos y tareas, que se realiza mediante las actividades descomponer objetivos (4 ) y descomponer tareas (3 ) respectivamente. En este caso se ha preferido ahondar en la descomposición de objetivos para relacionar con tareas los objetivos hoja del grafo acíclico resultante. La satisfacción de los objetivos intermedios se realiza mediante dependencias según la actividad establecer dependencias entre objetivos (5 ). Las tareas se detallan más indicando si producen interacciones, asociar tareas con interacciones (6.a ), si producen o consumen entidades mentales, asociar tareas con entidades producidas (6.c )  y consumidas (6.b ), y qué aplicaciones requieren, asociar tareas con aplicaciones (6.d ).

Una vez decidido cómo se alcanzan los objetivos, surgen nuevas necesidades que han de representarse con modelos de entorno. Se trata de las aplicaciones requeridas por las tareas para ejecutar su cometido. Esta vez, se ejecutan las actividades identificar aplicaciones internas (1.b ), asociar operaciones (2 ) y actividades del análisis de las aplicaciones (3 ) (los resultados de esta actividad no se han incluido) para describir estas aplicaciones requeridas por las tareas. Esta vez, la información de la que se dispone es mayor, ya que se tienen interacciones en las que se enmarcan las tareas y asociaciones con objetivos señalando qué se espera de ellas.

Para terminar, el modelo de organización recoge todos estos resultados y procede a su estructuración. Se asocian las nuevas aplicaciones con la actividad generar miembros (1.b ). Cómo ya se tienen un conjunto razonable de tareas, procede agruparlas en flujos de trabajo,identificar flujos de trabajo (2.a ) y refinar estos grupos de trabajo, aplicar descomposición de flujos (2.b ). Las relaciones sociales todavía no son necesarias.

1.1.2  Resultados obtenidos

Los casos de uso iniciales se refinan en la Ilustración 102 . El caso de uso Usuarios molestos se refina en dos nuevos: Monitorización de los usuarios y Echar usuarios. Propagar información también se refina creando el nuevo caso de uso Sugerencia directa de documentos. Por último, para decidir si la información suministrada es de calidad, se plantea la necesidad de evaluar la información.

Ilustración 102. Casos de uso asociados

A continuación se muestra una descripción más detallada de los casos de uso:

o       Monitorizar usuarios. Los usuarios molestos se detectan recogiendo estadísticas acerca de sus acciones. En concreto interesan:

§         Número total de veces que un documento del usuario ha sido evaluado negativamente.

§         Número total de veces que un documento del usuario ha sido evaluado positivamente.

§         Número total de veces que un usuario ha evaluado positivamente algún documento.

§         Número total de veces que un usuario ha evaluado negativamente algún documento.

o       Echar usuarios molestos. A los usuarios molestos se les echa de la comunidad dándoles detalles acerca de los motivos de la expulsión.

o       Propagar sugerencias Se permite a los usuarios sugerir información en las comunidades a las que están suscritos.

o       Evaluar información. Define el proceso de filtrado de información tomando como referencia un único evaluador. Este caso de uso se reutiliza para decidir si las sugerencias se propagan a los usuarios finales.

o       suscribirse a la comunidad

o       borrarse de comunidades.

o       Extraer información de foros de noticias. Se trata de utilizar un foro de noticias como fuente de información. Dado un foro cuya temática se considere interesante de acuerdo con los gustos de los miembros de una comunidad, sería apropriado que los nuevos anuncios insertados en el foro se retransmitieran al resto de la comunidad.

o       Intercambiar documentos interesantes. El intercambio de información no tiene por qué ser restrictivo a una organización. Varias organizaciones pueden, de mutuo acuerdo, intercambiar información de sus comunidades.

De estos casos de uso, se toman como relevantes para la arquitectura del sistema sólo los cuatro primeros. Para la extracción de noticias, se puede tomar un agente personal modificado que extienda su percepción al foro de noticias y así poder observar nuevos anuncios. Para el intercambio de documentos, habría que crear un nuevo agente con la capacidad de participar en las comunidades actuando como representante de una organización. En el funcionamiento de este agente serán necesarios elementos no contemplados con anterioridad, sin embargo, estos cambios no afectarán a la arquitectura básica del sistema, de hecho se apoyarán en ella.

Para detallar lo que se pretende con cada caso de uso, se utilizan los modelos de interacción que se muestran a continuación. Los roles que se muestran en cada una de las interacciones provienen de los diagramas de colaboración generados como especificación inicial.

Ilustración 103. Interacciones para detallar la realización de casos de uso altas en comunidad (A), y  propagar sugerencias (B).

La interacción solicitar alta en comunidad (ver Ilustración 106 (A)) se inicia para disponer de más fuentes de información (objetivo suscribirse fuentes de información) y se ejecuta de forma que el nuevo usuario sea compatible con la temática tratada en la comunidad (objetivo mantener calidad de documentos).

La interacción propagar sugerencias (ver Ilustración 106 (B)) se inicia para incrementar la cantidad de documentos relevantes para los usuarios (incrementar colección de documentos interesantes) pero manteniendo la calidad de los documentos (mantener calidad documentos). Los usuarios colaboran en el mantenimiento de calidad porque buscan documentos que les interesen (buscar documentos interesantes).

Ilustración 104. Diagrama de colaboración para la interacción solicitar alta en comunidad

Para garantizar la idoneidad de un nuevo miembro con respecto a los gustos de una comunidad (ver Ilustración 104 )  se sigue un proceso similar al de propagación de sugerencias (ver Ilustración 105 ). El usuario, al solicitar su entrada en la comunidad, proporciona un resumen de los gustos que le caracterizan. Este resumen es comparado con un perfil de la comunidad, para determinar si merece la pena seguir adelante y consultar a los otros miembros. Si es así, se inicia el proceso de evaluación para N miembros seleccionados de entre los miembros de la comunidad. Al término de las evaluaciones, se decide si aceptar finalmente al usuario o no.

Ilustración 105. Diagrama de colaboración para la interacción propagar sugerencias.

El proceso de tramitación de sugerencias es similar al otro en cuanto que se precisa de la opinión de los miembros de la comunidad. La diferencia radica en que las sugerencias, si son evaluadas positivamente por usuarios y comunidad, se radian al resto de miembros y se recogen sus opiniones nuevamente. El resultado es evaluado en el emisor de sugerencias de forma que se preserva el anonimato de los evaluadores.

Ilustración 106. Interacciones para detallar la realización de casos de uso bajas en comunidad (A) y evaluar información (B).

Ambos procesos, donde se solicita la opinión de los usuarios, convierten el sistema de gestión de la comunidad en una democracia donde todos opinan alguna vez sobre lo que se hace en la comunidad.

La interacción solicitar baja en comunidad (Ilustración 106 (A)) muestra el proceso que permite a un miembro de la comunidad darse de baja. En principio este proceso obedece a la voluntad del usuario, sin embargo también puede ser decisión del agente motivada por una serie de evaluaciones negativas por parte del usuario de documentos procedentes de una comunidad. En cualquiera de los casos, la baja es por insatisfacción del usuario. Por ello, se han indicado que la interacción persigue no molestar más al usuario (objetivo no molestar usuario) y no recibir más información de una comunidad (objetivo no enviar información no deseada).

La interacción evaluar documento (Ilustración 106 (B)) expresa la evaluación de un documento. El propósito de esta interacción es mostrar cómo se consigue no molestar al usuario con el proceso de evaluación. Así, se tienen como objetivos el evaluar autónomamente la información que llega (evaluar autónomamente) con la menor intervención posible del usuario y que esta evaluación no termine en información no deseada por el usuario (No enviar información no deseada).

Ilustración 107. Diagrama de colaboración para la interacción solicitar baja en comunidad (B) y la interacción evaluar información (A)

Los diagramas de colaboración en este caso son limitados a propósito. El caso de la Ilustración 107 (A) es comprensible ya que una baja en una comunidad no reviste un problema aparente. Sin embargo para el caso Ilustración 107 (B), la viabilidad del proceso no está clara. Para detallarlo un poco, se utilizará un modelo de objetivos y tareas (Ilustración 108 ) donde se muestren las tareas involucradas.

Ilustración 108. Tareas involucradas en la evaluación de documentos

El proceso de evaluación autónoma es posible mediante la utilización de clasificadores que permitan determinar en qué medida un documento pertenece a una categoría. Esta categoría es una abstracción de un sub-conjunto de los gustos del usuario expresados como conjuntos de páginas.

Ilustración 109. Interacciones para la realización de los casos de uso monitorizar usuarios (A) y echar de comunidad (B)

La interacción monitorizar acciones (Ilustración 109 (A)) tiene como objetivos la monitorización de las acciones de los usuarios con vistas a detectar usuarios que disturben el orden de la comunidad (objetivo detectar usuarios molestos) y usuarios que no estén satisfechos con la información recibida (objetivo detectar usuarios insatisfechos).

La interacción echar de comunidad (Ilustración 109 (B)) es similar a la de solicitar baja en la comunidad  (Ilustración 106 (A)) salvo que ésta se invoca cuando la presencia del usuario no es bien recibida. El único motivo que justifica el echar a un usuario es que se trate de un usuario molesto (objetivo eliminar_usuarios_molestos).

Ilustración 110. Diagramas de colaboración para las interacciones monitorizar usuarios (A) y echar de comunidad (B)

Para lograr los objetivos anteriores se plantean los diagramas de colaboración de la Ilustración 110 . El monitorizar usuarios se ve como un patrón observador [Gamma et al. 95] . El diagrama de colaboración de la Ilustración 110 (A) utiliza las primitivas de expresiones secuenciales de UML para reflejar que existe un número no determinado de notificaciones antes del final del cese de la observación. El echar a usuarios de la comunidad no requiere mayor comentario.

Los objetivos encontrados en las interacciones y arquitectura inicial del sistema se estructuran utilizando un modelo de tareas y objetivos.

Ilustración 111. Estructuración inicial de objetivos (I)

La distribución de documentos interesantes se descompone en la voluntad de proporcionarlos (Proporcionar documentos interesantes) y la voluntad de aceptarlos (incrementar colección de documentos interesantes).

En paralelo, se persigue molestar al usuario lo menos posible (no molestar usuario) que aquí se entiende como el evaluar autónomamente cuando sea posible (evaluar autónomamente) y que el usuario no reciba información que, según las estimaciones realizadas, no le van a gustar (no enviar información no deseada).

Ilustración 112. Estructuración inicial de objetivos (II)

Para terminar, se busca mantener la calidad de los documentos del sistema (mantener calidad documentos), para lo cual se plantean tres frentes: detectar malas fuentes de información (detectar mala información), prevenir que usuarios se puedan convertir en malas fuentes de información (prevenir malas fuentes información) y disminuir la mala información en la organización (disminuir mala información). Para detectar malas fuentes de información se debería perseguir o bien una evaluación automática de la información contenida en esta fuente (evaluar autónomamente) o bien consultar a expertos, los usuarios, para que den su opinión acerca de la calidad de la fuente (consultar expertos). Para prevenir que las fuentes existentes se corrompan, se debería detectar qué usuarios molestan con la información que sugieren (detectar usuarios molestos), qué usuarios no proporcionan información acorde con la temática de la comunidad (detectar usuarios molestos) o que evalúan negativamente toda la información que les llega (detectar usuarios insatisfechos). El último frente, disminuir la mala información, se consigue echando de la comunidad a aquellos usuarios identificados como molestos (eliminar usuarios molestos) y haciendo que los usuarios puedan salirse de la comunidad cuando no estén satisfechos con los resultados (eliminar malas fuentes de información).

Las dependencias entre objetivos (instancias de GTAfecta) no se muestran aquí ya que en este caso coinciden exactamente con las relaciones de descomposición. Para satisfacer estos objetivos, se definen tareas que más tarde se incorporarán a los flujos de trabajo de la organización.

Ilustración 113. Tareas asociadas a los objetivos

La identificación de tareas ha sido guiada por los objetivos que se han encontrado en los modelos de interacción. Para cada objetivo se han creado tareas cuya ejecución pueda enmarcarse dentro de los diagramas de colaboración anteriores. La forma exacta en que intervienen estas tareas se definirá en la siguiente sección:

o       Solicitar monitorización. Ordena a un agente que informe de todas sus actividades a otro agente. Se utiliza para elaborar estadísticas acerca del comportamiento de los usuarios. Gracias a estas estadísticas, se pueden detectar los usuarios molestos o insatisfechos.

o       Propagar sugerencia. Un documento suministrado por el usuario se traslada a una comunidad. Mediante esta tarea se busca difundir información que pueda ser interesante para los miembros de una comunidad.

o       Procesar sugerencia. Toma una sugerencia y la compara contra los gustos conocidos de los miembros actuales de la comunidad. Si el grado de similitud es elevado, se procede a preguntar a un subconjunto de usuarios por su parecer acerca de la calidad de la sugerencia recibida. Esta tarea se ejecuta tras haber recibido una sugerencia de un miembro de la comunidad.

o       Procesar preevaluación sugerencia. Tras haber recibido una sugerencia, se pregunta a los miembros de la comunidad por su opinión acerca de la calidad del documento. En respuesta, los agentes que representan a los usuarios generan evaluaciones positivas y negativas. El cometido de esta tarea es decidir, una vez recibidas las evaluaciones, si la sugerencia se difunde al resto de los miembros de la comunidad o bien si su calidad no es la suficiente. El criterio es comparar los votos a favor y en contra para comprobar si a la mayoría le gusta el documento sugerido.

o       Procesar evaluaciones sugerencia. Tras haber difundido la sugerencia, se procesan las reacciones de los usuarios. Esta nueva información también se incorpora al historial.

o       Inicia evaluación del documento. Esta tarea la ejecuta un agente de comunidad para averiguar la opinión de un miembro de la comunidad acerca de la calidad de un documento. La evaluación la puede generar el agente personal que representa al miembro consultado o bien el propio miembro.

o       Evaluar. Evalúa un documento dentro de un agente personal de acuerdo con el perfil de su usuario o, si esto no es suficiente, preguntando directamente cual es la opinión de su usuario.

o       Solicitar incorporación. Pide a una comunidad que le acepte como miembro. La aceptación está condicionada por la opinión de los miembros y por el perfil de la comunidad. Si la comunidad tiene como temática el fútbol y al usuario sólo le interesa, de acuerdo con su perfil, la economía nacional, entonces la solicitud puede ser rechazada. Este hecho puede ser detectado de forma automática, mediante el clasificador (ver Ilustración 108 ) o bien por los propios miembros, mediante votación.

o       Solicitar baja. La baja en una comunidad se pide cuando el usuario no está satisfecho con la información que recibe. Para procesar la baja, además de eliminar al usuario de la lista de miembros de la comunidad, hay que dar de baja al solicitante en los procesos de evaluación en curso y otros relacionados, como el proceso de monitorización.

o       Procesar petición de suscripción. Se ejecuta después de que un usuario solicite su incorporación a una comunidad. Esta tarea realiza la comparación de los gustos del usuario, incluidos en la petición, contra los gustos de la comunidad. Si existe un grado de similitud suficiente, la solicitud pasa a ser revisada por un subconjunto de los miembros de la comunidad. Si éstos consienten, el usuario es aceptado.

o       Echar de comunidad. Echa a un usuario de una comunidad. Para ello se debe descartar al expulsado de cuantos procesos de comunicación existieran, en especial, del proceso de monitorización de acciones de los usuarios, iniciado mediante la tarea solicitar monitorización (ver Ilustración 115 ).

De estas tareas las que producen interacciones son las que se muestran en la Ilustración 114 y la Ilustración 115 . Estas se muestran con detalle a continuación. El resto de tareas se describe en http://grasia.fdi.ucm.es/metodologia.

Ilustración 114. Entidades producidas y consumidas por tareas (I)

La tarea echar de comunidad toma como entrada las acciones realizadas por el usuario hasta ahora, que se suponen han sido extraídas del Gestor de Estadísticas. El criterio para decidir si se echa se indica en un patrón de estado mental asociado a la unidad de interacción echar usuario en la interacción echar de comunidad, que se menciona en la siguiente sección. Para dar de baja al usuario en la comunidad hay que usar el gestor de miembros de la comunidad y el gestor de estadísticas. La notificación se envía al usuario mediante la interacción echar de comunidad.

La tarea solicitar incorporación necesita saber a qué comunidad se quiere suscribir el usuario (hecho hay que suscribirse) y a qué comunidades pertenece ya (hecho comunidades suscritas), para no suscribirse a una comunidad en que ya está suscrito. Para localizar al agente de comunidad correspondiente, se utiliza el Gestor de Agentes. La suscripción se realiza dentro de la interacción solicitar alta en comunidad.

Ilustración 115. Entidades producidas y consumidas por tareas (II)

La tarea propagar sugerencia consume el documento a sugerir (hecho documento) y la comunidad a la que hay que enviarlo (hecho comunidad interesada). Con estos datos, la tarea inicia una interacción propagar sugerencias.

La tarea sólo necesita conocer cuándo ha sido un usuario aceptado en una comunidad. Esto se conoce cuando aparece el hecho usuario aceptado. Esto es posible porque las tareas implicadas en los procesos de alta en la comunidad producen este hecho automáticamente cuando se ha finalizado el proceso de admisión.

Por último, la tarea solicitar baja da de baja a un agente personal de una comunidad. El motivo puede ser por solicitud del usuario o instatisfacción del mismo por la información obtenida de ella hasta ahora. La comunidad se indica con el hecho comunidad interesada y la tarea tiene como efecto la modificación del hecho comunidades suscritas. La baja se realiza dentro de la interacción solicitar baja en comunidad.

La participación de los roles en las interacciones está sujeta a la relación entre los objetivos que persiguen y los asociados a la interacción. Las ilustraciones siguientes muestran la asociación de los objetivos con roles. Se puede comprobar que existe relación directa con los objetivos de las interacciones utilizando como referencia la Ilustración 111 y Ilustración 112 .

Ilustración 116. Asociaciones entre objetivos y roles (I)

La Ilustración 116 muestra la motivación de los roles miembro de comunidad, evaluador de sugerencias, emisor de sugerencias y receptor de sugerencias. El primer rol describe los objetivos generales que persigue un miembro de la comunidad. A estos se añaden los incorporados a los roles evaluador sugerencias y emisor sugerencias, ya que se trata de roles concretos de los que miembro de comunidad es una generalización. El rol receptor de sugerencias lo desempeñan agentes de comunidad y se encarga de guiar el proceso de propagación de sugerencias (interacción propagar sugerencias).

Ilustración 117. Asociaciones entre objetivos y roles (II)

La Ilustración 117 muestra los objetivos perseguidos por un solicitante de suscripción a la comunidad y un gestor de suscripciones a la comunidad. El primero solicita su entrada a la comunidad, satisfaciendo el objetivo suscribirse fuentes de información. El gestor de suscripciones colabora en el proceso porque desea incorporar usuarios. El resto de objetivos describen bajo que condiciones tendrá lugar el proceso de suscripción y la permanencia del solicitante en la comunidad. Los procesos de evaluación de la petición del solicitante aseguran que no se molesta al usuario y que, además, el usuario no enviará información no deseada. Además, el gestor se encargará de vigilar al nuevo miembro de la comunidad porque desea detectar usuarios molestos.

Los roles identificados en las interacciones se asocian con los agentes que los desempeñarán. Inicialmente sólo hay dos clases de agentes: Agentes Personales y Agentes de Comunidad. El número reducido de roles que desempeñan los agentes contrasta con el número de roles identificados en las interacciones. Sin embargo, hay que comentar que alguno de estos roles, como el rol miembro de la comunidad agrupan otros roles, por lo que el reducido número no implica el que no se tengan en cuenta los ya identificados.

Ilustración 118. Modelos de agente para el Agente Personal (B) y Agente de Comunidad (A).

Los Agentes Personales (Ilustración 118 (A)) y Agentes de Comunidad (Ilustración 118 (B)) asumen los objetivos de distribuir documentos interesantes y el de mantener calidad de los documentos. Adicionalmente, cada agente se responsabiliza de no molestar a su usuario (Agente Personal) o a los miembros de la comunidad (Agente de Comunidad). Estos objetivos se pueden completar gracias a que los agente despempeñan roles de las ilustraciones Ilustración 117 y Ilustración 116 . Los procesadores y gestores de estado mental son del mismo tipo para ambos agentes.

El procesador de estado mental en los dos casos se basa en el algoritmo RETE. El mecanismo deliberativo utiliza reglas de producción. El gestor de estado mental tiene como restricción el que la introducción de nueva información se debe hacer escalonadamente. Sólo se mete una nueva entidad de información cuando el agente ha terminado de tomar decisiones.

La inteligencia del agente se concreta en la forma en que ambos se adaptan a los gustos de sus usuarios utilizando como alimentación el resultado de las evaluaciones ejecutadas. La comunidad obtiene información de sus miembros mediante los procesos de monitorización (ver Ilustración 109 ). Los agentes personales, en los procesos de propagación de sugerencias, modifican el perfil del usuario para constatar que determinado documento le gusta a su usuario.

Del diseño de los diagramas de colaboración ya se ha deducido la existencia de una entidad Clasificador. En este punto se puede extrapolar la existencia de otras tres entidades: un gestor de estadísticas, un gestor de miembros de la comunidad y un gestor de agentes. La necesidad del primero se deduce de la monitorización de usuarios, donde se deben almacenar las veces que se ejecuta cada acción. La necesidad del segundo viene implícita del proceso de alta y baja en la comunidad, lo cual implica llevar cuenta de quién pertenece a la comunidad en un momento dado. El tercero sirve para localizar agentes en el sistema. Es útil cuando el agente personal no pertenece a ninguna comunidad, ya que permite localizar las comunidades existentes.

Ilustración 119. Nuevos elementos identificados en el entorno

Estos elementos se asocian a grupos de la organización siguiendo un criterio de utilización: aquellas aplicaciones que cualquier miembro de la organización pueda utilizarla, pertenecerá al grupo administración, mientras que las aplicaciones que sólo puedan ser utilizadas por los miembros de una comunidad, pertenecerán al grupo comunidad.

Ilustración 120. Recursos identificados y asociación de aplicaciones a grupos

La descripción de estos elementos (Ilustración 119 ) se muestra a continuación:

o       Clasificador. Es una herramienta que permite en base a una colección de documentos, crear una categoría y decidir con posterioridad si un documento encaja en alguna de las categorías creadas.

o       Gestor de Estadísticas. Para registrar las actividades del usuario se definen contadores asociados con claves. El desarrollador definirá claves que se identifiquen con las distintas acciones y para cada una se crearán contadores.

o       Gestor de Miembros de la comunidad. Esta aplicación gestiona los miembros de una comunidad, permitiendo al agente llevar cuenta de quiénes están asociados.

o       Gestor de agentes. Sirve para localizar, crear y destruir agentes en el sistema. Mediante esta aplicación se puede ordenar la creación de agentes específicos así como obtener información de los existentes.

Con esta información, se revisa la arquitectura del sistema propuesta anteriormente:

Ilustración 121. Representación del sistema Multi-Agente para el sistema personalizado de distribución de documentos

Los agentes en la organización se disponen por grupos. El más relevante es Comunidad que agrupa un conjunto de agentes personales, un único agente de comunidad y los recursos propiedad de la comunidad. Estos recursos son utilizados para gestionar los miembros de la comunidad, las estadísticas de funcionamiento y la categorización estadística de documentos.

El grupo Administración reúne recursos comunes a todos los agentes. En este caso se trata de un gestor de agentes y un gestor de documentos. El gestor de agentes actúa como factoría de agentes, permitiendo la creación o destrucción de Agentes Personales o Agentes de Comunidad.

Dentro de la organización se distinguen dos flujos de trabajo: los destinados a la gestión de la comunidad (Gestionar Comunidades) y aquellos que soportan la distribución de documentos (Compartir documentos). La existencia de estos flujos se debe a la necesidad de organizar las tareas que se han identificado.

Los flujos de trabajo Gestionar comunidades y Compartir documentos se refinan en más tareas y flujos de trabajo. Este refinamiento se avanzarán en el diseño con la interconexión de tareas y la definición de su ejecución dentro de interacciones (cuando la ejecución de las tareas involucra a otros agentes).

Ilustración 122. Refinamiento del flujo de trabajo para la gestión de comunidades

El flujo de trabajo Compartir documentos se refina distinguiendo entre evaluación de documentos, monitorizar acciones, echar comunidad y propagación de las sugerencias. En la siguiente sección se ofrecerán más detalles respecto a cómo tiene lugar esta descomposición.