En esta etapa se aumenta el nivel de detalle en la especificación determinando cómo se llevan a cabo los casos de uso identificados. Los resultados se centran en refinar los flujos de trabajo y las tareas asociadas, las interacciones, cómo es el control del agente y cómo se satisfacen los objetivos del sistema.

1.1.1  Estructuración de la etapa

Al detallar las interacciones y los flujos de trabajo, es normal que aparezcan nuevas tareas. Idealmente, con estas tareas se deberían estudiar en otra iteración dentro de la etapa de análisis-elaboración. En esta ocasión, este estudio se omite.

En esta etapa, la documentación es extensa, por ello se ha preferido mostrar sólo aquellos aspectos más relevantes y dejar el resto para la consulta de los lectores en una página web. Así, la documentación completa se puede consultar en http://grasia.fdi.ucm.es/metodologia.

Los modelos de organizaciones se refinan asociando tareas a los flujos de trabajo, actividad identificar tareas (5.a ). Estas tareas se obtienen de modelos de objetivos y tareas y de las interacciones esquematizadas en el análisis. Las tareas se conectan entre sí uniendo aquellas que produzcan entidades con aquellas que las consuman, actividad conectar tareas (5.b ). Se describen también qué recursos se consumen, actividad recursos en las tareas (5.e ), detallando qué tareas implican la ejecución de otras tareas en otros agentes, identificar tareas no locales (5.c ), y quién se encarga de ejecutarlas, identificar responsables (5.d ). Las instancias WFConecta se complementan con la información elaborada por la actividad identificar entidades mentales (5.f ), que produce los elementos intercambiados dentro de los flujos de trabajo.

Los modelos de interacción se relacionan con los flujos de trabajo a través de las entidades interacción. Estas entidades especifican la ejecución de tareas no locales tomando como guía los diagramas de colaboración existentes. La especificación se presenta con un conjunto de diagramas GRASIA. Estos diagramas parten de los diagramas de colaboración de la etapa anterior. La conversión se inicia traduciendo pasos de mensajes a unidades de interacción, actividad traducir mensajes ( 5.a ). En las unidades de interacción se explica por qué un agente decide mandar el mensaje,actividad establecer condiciones mentales 5.c , y qué tareas se ejecutan al enviar o recibire el mensaje, actividad asociar tareas (5.b ). Por último, se organizan las unidades de interacción en un diagrama de flujo para explicar en qué orden se ejecutan, actividad establecer orden de ejecución (5.d ).

Los modelos de agente no se modifican en este caso, aunque sí que se detalla cómo se espera que sea su control. Se estudian los estados mentales extraídos de las interacciones y los requeridos por los flujos de trabajo, actividad detallar los estados intermedios (6 ). Obtenidos estos estados mentales, hay que estudiar cómo se pasa de uno a otro, actividad determinar cómo se pasa de un estado mental a otro  ( 7.a ),  y detallar cómo decide el agente qué tarea ejecutar a continuación ( 7.c ).

Los modelos de entorno se refinan atendiendo al tipo de percepción de los agentes y detallando cuales son los parámetros de los recursos. Los recursos se asocian con tareas cuando sea necesario indicar necesidades relevantes, como tareas que consumen mucho tiempo de procesador. Aquí se utilizan principalmente para refinar la percepción de los agentes, actividad refinar la percepción de los agentes (9 ). Para determinar los parámetros adecuados de los recursos, actividad definir los atributos propios de cada recurso (11 ), conviene conocer antes qué necesidades se tienen. Para clarificar esta visión es apropiado aplicar la actividad asociar recursos, aplicaciones y tareas (12 ), a partir de lo cual será más sencillo determinar exactamente qué se necesita.

Los objetivos y tareas se estudian para indicar exactamente cómo se resuelven los objetivos y cómo se ejecutan las tareas. Para las tareas se describen las postcondiciones y precondiciones del análisis con detalle. Así, se indican qué recursos se consumen, actividad determinar recursos a consumir (8.b ), cuáles se restablecen, actividad indicar qué recursos se restablecen ( 7.a ), qué ocurre con las entidades mentales requeridas, actividad asociar tareas con entidades mentales (7.b ), si se necesitan nuevas entidades mentales, actividad refinar  entidades mentales consumidas (8.a ), qué operaciones se están invocando sobre las aplicaciones, actividad asociar tareas con operaciones de las aplicaciones (7.c ). Los objetivos, por otro lado, se refinan indicando qué dependencias existen, actividad refinar dependencias de objetivos (10.a ), y cómo se satisfacen o fracasan, refinar satisfacción/fracaso de objetivos (10.b ).

1.1.2  Resultados obtenidos

La gestión de comunidades se ha descompuesto en una serie de tareas atómicas que implementan primitivas de gestión (tareas basicas de gestion), y en dos flujos de trabajo destinados a la tramitación de altas (altas en comunidad)  y bajas en la comunidad ( bajas en comunidad).

Ilustración 123. Tareas que componen el flujo de trabajo altas en la comunidad

La identificación de tareas para el flujo altas en la comunidad (Ilustración 123 ) se basa en el diagrama de colaboración de la Ilustración 104 . El número final se debe a refinamientos con motivo de la definición de diagramas GRASIA que se mostrarán más tarde. La ordenación de estas tareas se muestra en la Ilustración 124 .

Ilustración 124. Dependencias entre las tareas del flujo altas en comunidad.

La tarea inicial (Ilustración 124 ) es la de solicitar la incorporación a la comunidad (solicitar incorporación). Esta petición es procesada por procesar petición suscripción, que puede continuarse con una evaluación de la idoneidad del nuevo miembro (enviar petición envaluacion suscripción) o con la agregación directa (agregar nuevo miembro), en el caso en que no haya otros usuarios registrados. Los evaluadores de la suscripción estudian la petición ejecutando procesar evaluación suscripción y devuelven la respuesta con enviar respuesta evaluación. Esta respuesta es procesada con procesa evaluaciones suscripción que terminará con la agregación  de un nuevo miembro o no. De cualquier forma, la respuesta se envía con enviar respuesta solicitud suscripción que será procesada por el solicitante con procesar respuesta alta.

Ilustración 125. Descripción detallada del flujo solicitar alta en comunidad

La Ilustración 125 describe las entidades mentales intercambiadas en el flujo de trabajo solicitar alta en comunidad. Como en el flujo de trabajo evaluar documento, existen tareas cuya ejecución no dispara la ejecución de otras tareas. En este caso se trata de la tarea agregar nuevo miembro.

Las ejecución de las tareas del flujo dar alta en comunidad se definen dentro de un diagrama GRASIA asociado a la interacción solicitar alta en comunidad.

Ilustración 126. Relación de las tareas del flujo dar alta en comunidad con la interacción solicitar alta en comunidad

Para especificar esta ejecución se añade una nueva especificación de interacción a solicitar alta en comunidad. El tipo de la nueva especificación es un diagrama GRASIA (Ilustración 127 )

Ilustración 127. Refinamiento del modelo de interacción de solicitar alta en comunidad.

La Ilustración 127 muestra el modelo de interacción para solicitar alta en comunidad en el que se ha añadido una nueva especificación de tipo GRASIA.

Ilustración 128. Unidades de interacción identificadas para la interacción solicitar alta en comunidad.

Las unidades de interacción de la Ilustración 128 se obtienen a partir del diagrama de colaboración de la Ilustración 104 . Se ha intentado asimilar cada unidad de interacción con un paso de mensaje y  cada tarea con las acciones esperadas por el emisor y el receptor.

Ilustración 129. Ordenación de las unidades de interacción en solicitar alta en comunidad

Estas unidades de interacción se ordenan según indica la Ilustración 129 . Respecto del flujo de trabajo inicial, sólo queda detallar quién es responsable de ejecutar la tarea, pero a partir de la ilustración anterior, es sencillo.

Ilustración 130. Responsables de la ejecución de tareas en el flujo dar alta en comunidad

La Ilustración 130 muestra la asociación de roles con tareas según lo indicado en la Ilustración 128 .

Ilustración 131. Tareas que componen el flujo de trabajo bajas en comunidad

Las bajas en la comunidad se rigen por el conjunto de tareas de la Ilustración 131 . De estas tareas, llama la atención dar de baja sesiones. Esta tarea se ha incluido para dar una solución al problema de qué hacer con las evaluaciones en que el usuario está participando cuando éste se da de baja. En principio, esta tarea elimina al usuario de cuanto proceso de evaluación existe y de cualquier difusión de sugerencias planificada.

Ilustración 132. Dependencias entre las tareas del flujo bajas en comunidad

La tarea inicial de la Ilustración 132 es la ejecutada por el solicitante de baja (solicitar baja). Esta tarea es la que origina la petición en el Agente de Comunidad que se procesa con procesa baja en comunidad. Estas tareas identifica las sugerencias que el usuario está pendiente de recibir y se las proporciona a dar baja sesiones. El paso siguiente es informar al solicitante que ha sido dado de baja (enviar baja en comunidad y procesar respuesta solicitud).

Ilustración 133. Descripción detallada del flujo dar de baja en comunidad

Las entidades mentales intercambiadas en el flujo de trabajo dar de baja en comunidad se presentan en la Ilustración 133 . La tarea dar baja sesiones se encargaría de asegurar que el usuario ha sido de baja en las sesiones de evaluación de documentos o usuarios. Una vez conseguido, procedería a dar de baja al usuario en el registro de miembros. Cuando estas operaciones concluyen, produce un hecho usuario desuscrito que, aparte de informar al usuario de la ejecución de la baja, sirve para indicar la finalización de otro flujo de trabajo, monitorizar acciones.

Ilustración 134. Relación de las tareas del flujo dar baja en comunidad con la interacción solicitar baja en comunidad

Las tareas de la Ilustración 132 se asocian con la interacción solicitar baja en comunidad en la Ilustración 134 . Asociada a esta interacción se ha incluido un nuevo diagrama GRASIA para especificar la ejecución de tareas.

Ilustración 135. Diagrama GRASIA asociado a la interacción solicitar baja en comunidad.

Como en el caso anterior, las unidades de interacción provienen de los pasos de mensaje dentro del diagrama de colaboración de Ilustración 107 (B).

Ilustración 136. Responsables de la ejecución de tareas en el flujo dar de baja en comunidad

Como resultado del diagrama de la Ilustración 135 se obtienen las asociaciones de responsabilidad de tareas con respecto a los roles. Estas relaciones se ofrecen en la Ilustración 136 .

Ilustración 137. Refinamiento del flujo de trabajo para la compartición de documentos

El refinamiento del flujo de trabajo compartir documentos se hace de acuerdo con el diagrama de colaboración de la Ilustración 105 . El planteamiento de este flujo de trabajo difiere de los anteriores en un detalle: existen flujos de trabajo dentro de un flujo de trabajo. Esta solución que podría haber sido aplicada a los otros flujos, se ha aplicado aquí para evaluar la importancia de la posibilidad de abstraer conjuntos de tareas e interacciones. En este caso, se trata de considerar el flujo evaluar documento como una unidad similar a la tarea, pero de orden superior, ya que la tarea no puede contener flujos de trabajo.

Ilustración 138. Relaciones entre las tareas del flujo de trabajo compartir documentos

Siguiendo este diagrama, primero el cliente ejecuta propagar sugerencia, en respuesta, la comunidad ejecuta tratar sugerencia. Esta tarea se descompone en el lanzamiento de las evaluaciones a realizar por los miembros de la comunidad (evaluar sugerencia), la evaluación de las respuestas (procesar preevaluaciones sugerencias), la difusión de la sugerencia a los otros miembros de la comunidad (difundir sugerencia), la recogida de las opiniones de los usuarios después de revisar el documento (procesar evaluaciones sugerencias) y la recepción de la respuesta por parte del usuario que sugirió el documento (revisar evaluaciones sugerencia).

Ilustración 139. Descripción detallada del flujo de trabajo compartir documentos

La Ilustración 139 muestra cómo se ejecuta el flujo de trabajo de la Ilustración 138 . De esta ilustración se comentará sólo cómo se consigue integrar el flujo de trabajo evaluar documento dentro del flujo compartir documentos. Las tareas procesar sugerencia y difusión sugerencia en curso producen un hecho, sugerencia recibida, que activa el flujo de trabajo evaluar documento. Este flujo produce a su término o bien un hecho evaluación positiva o bien evaluación negativa. Las distintas evaluaciones se recogen mediante las tareas procesar preevaluación sugerencia y procesar evaluación sugerencia. Cual de las dos debe ser, se discierne por el hecho difusión sugerencia en curso, producido por difundir sugerencia.

Ilustración 140. Relación de las tareas del flujo compartir documentos con la interacción propagar sugerencias

Las tareas de la Ilustración 138 se asocian con la interacción propagar sugerencias (ver Ilustración 140 ). A esta interacción se asocia un diagrama GRASIA para detallar la ejecución de tareas (Ilustración 141 ).

Ilustración 141. Diagrama GRASIA asociado a la interacción compartir documentos.

Dentro de este diagrama llama la atención que entre el Receptor de Sugerencias y el Evaluador de sugerencias  no existen unidades de interacción, sino interacciones. Esto es consecuencia de haber definido el flujo de trabajo compartir documentos en términos del flujo evaluar documentos. Para iniciar esta interacción se ejecuta procesar sugerencia y para procesar los resultados, se ejecuta procesar preevaluación sugerencia, que no aparece en la ilustración porque su ejecución es posterior al término de la interacción. Otro elemento que destaca es que se implican  N evaluadores en el proceso. Por cada evaluador habrá una instancia en ejecución de la interacción evaluar documento.

Ilustración 142. Ordenación de las unidades de interacción en la interacción propagar sugerencias

La ejecución de las unidades de interacción de la Ilustración 141 está sujeta a una bifurcación dependiendo de si la sugerencia encaja en los intereses de la comunidad o no (Ilustración 142 ). Si encaja, existe otra posible bifurcación dependiendo de si la evaluación de los usuarios ha sido positiva o negativa. De cualquier forma, la última unidad de interacción ejecutada será la de comunicación de resultados (comunicar resultados evaluación).

Ilustración 143. Responsables de la ejecución de tareas en el flujo compartir documentos

De la Ilustración 141 se obtienen los responsables de la ejecución de las tareas identificadas. Estos responsables se muestran en la Ilustración 143 .

Ilustración 144. Tareas involucradas en el flujo de trabajo Evaluar Documento

El flujo de trabajo evaluar documento consiste en enviar un documento a un usuario y hacer que éste lo evalúe. Para ahorrar trabajo al usuario, se han dispuesto tareas que permiten desarrollar la tarea de evaluación de forma semiautomática. La tarea cotejar documento con perfil usuario se encarga de hacer un análisis estadístico del documento entrante contra la colección de documentos que definen al usuario. Si este análisis no es determinante, se acude al usuario.

Ilustración 145. Relaciones entre las tareas del flujo Evaluar Documento

La primera tarea (Ilustración 145 ) es la que ejecuta la petición de evaluación (inicia evaluación documento). Ésta dispara el proceso de evaluación dentro del cual se ejecuta la evaluación semi-automática (evaluar) y  después se envía la respuesta para que la reciba el iniciador (recibe respuesta evaluación).

Ilustración 146. Descripción detallada del flujo evaluar documento

La Ilustración 147 muestra las entidades mentales intercambiadas según las instancias de WFConecta de la Ilustración 145 . Se puede apreciar que el flujo de trabajo parece descompuesto en dos, la parte encargada de evaluar (tareas cotejar documento con perfil usuario y solicitar opinion usuario) y la encargada del proceso de petición y distribución de evaluaciones (el resto de tareas). El motivo es que la tarea evaluar, iniciada a petición de otro agente, se descompone en tareas cuya ejecución es local (no implica la ejecución de tareas en otros agentes). De hecho, estas tareas locales no aparecen el diagrama GRASIA de la Ilustración 148 . El resultado devuelto por evaluar es un hecho resultado evaluación que puede proceder o bien de cotejar documento con perfil usuario o bien solicitar opinión al usuario.

Ilustración 147. Asociación entre las tareas del flujo Evaluar Documento y la interacción evaluar documento

La interacción que define la ejecución de las tareas del flujo evaluar documento recibe el mismo nombre, evaluar documento. Nótese que la tarea evaluar no se ejecuta a primera vista dentro de la interacción.  La ejecución de la tarea de evaluación se dispara no porque haya una interacción, sino porque de repente hay que satisfacer el objetivo evaluar autónomamente, como se verá más adelante.

Ilustración 148. Diagrama GRASIA asociado a la interacción Evaluar Documento.

El diagrama GRASIA que especifica la interacción evaluar documento es uno de los más simples. Se trata de hacer una petición (evaluar sugerencia)  y de esperar una respuesta (respuesta evaluación sugerencia).

Ilustración 149. Responsables de la ejecución de las tareas del flujo Evaluar Documento

Los responsables de la ejecución de tareas, como en los casos anteriores, se obtienen directamente de la especificación de diagrama GRASIA de la Ilustración 148 .

Ilustración 150. Tareas involucradas en el flujo de trabajo monitorizar acciones.

El refinamiento del flujo de trabajo monitorizar acciones se hace a partir del diagrama de colaboración de la Ilustración 110 . Consiste en definir un patrón observador [Gamma et al. 95] utilizando los elementos de esta notación. Este flujo de trabajo permite elaborar estadísticas de las acciones de los usuarios y así saber si están satisfechos o no con los resultados proporcionados por sus agentes.

Ilustración 151. Relaciones entre las tareas del flujo de trabajo monitorizar acciones.

El flujo comienza con solicitar_monitorización que elabora una petición para el colaborador con el objetivo de que le informe de cuantas acciones se realicen (aquí interesan en concreto los votos positivos y negativos emitidos por los usuarios). La tarea registrar_observador_acciones registra al solicitante para informarle de futuras acciones. Se admite que varias entidades soliciten ser informadas de las acciones de los usuarios. Cada acción realizada se registra con la tarea registrar_acción que utilizará el gestor de estadísticas para actualizar los datos de cada usuario. Cuando la monitorización se dé por terminada, el monitor ejecutará terminar monitorización, tras lo cual el agente observado tendrá que deregistrar al monitor con la tarea dar_baja_observador.

Como en el flujo evaluar documento (Ilustración 146 ), se tienen flujos separados de ejecución. En este caso existen tres componentes, primero la encargada de solicitar la monitorización (tareas solicitar monitorización y registrar observador acciones), por otro el registro de las acciones (tarea registrar acción) y para terminar la finalización de la monitorización (tareas terminar monitorización y dar baja observador). Esta vez, el motivo de la separación es que aunque existen dependencias (e.g. no se pueden recibir las acciones de los usuarios si no se ha registrado antes el observador) estas se refieren únicamente al instante de ejecución y para especificar el instante de ejecución se usan diagramas GRASIA. Por ello, no se han interconectado las tareas correspondientes.

Ilustración 152. Descripción detallada del flujo de trabajo monitorizar acciones

Las entidades mentales intercambiadas en el proceso descrito en la Ilustración 151 se detallan en la Ilustración 152 . La obtención de acciones se realiza obligando a las tareas a monitorizar a producir evidencias adicionales. Tal es el caso del flujo evaluar documento que generará evidencias de tipo accion para que estas se registren en el observador. Nótese que este flujo no aparece dentro del diagrama GRASIA de la Ilustración 153 . Ello se debe a que este flujo se ha introducido unicamente por motivos de claridad, y no porque pertenezca realmente al flujo evaluar documento.

Ilustración 153. Diagrama GRASIA asociado a la interacción monitorizar usuario.

La especificación GRASIA de la interacción monitorizar usuarios (Ilustración 150 ) implementa un patrón observador. La unidad de interacción accion_ejecutada se repite hasta que el monitor decide que ya no necesita más información, esto es, hasta que se satisface el patrón de estado mental inicia deja de informar. Este patrón indica que debe existir un hecho usuario desuscrito para terminar la monitorización.

Ilustración 154. Tareas participantes en el flujo de trabajo echar_comunidad.

El flujo de trabajo echar de comunidad es el más simple de todos. Comienza cuando el gestor de suscripciones de la comunidad decide que un usuario no beneficia a la comunidad. Esta decisión se toma a partir de las estadísticas recolectadas sobre las acciones de los usuarios. La tarea echar de comunidad se encarga principalmente de eliminar de la comunidad al usuario y comunicarle el por qué del despido. El exmiembro de la comunidad, procesa la solicitud con procesar_expulsión_comunidad. Una decisión que se puede tomar a partir de la expulsión es volver a suscribirse.

Ilustración 155. Descripción detallada del flujo de trabajo echar de comunidad

La Ilustración 155 muestra las entidades mentales intercambiadas en el flujo de trabajo echar de comunidad. La tarea echar de comunidad se activa cada vez que se modifican las estadísticas del usuario (hecho acciones usuario). Con esta información y la configuración del agente (no mostrada aquí pero sí en el patrón de estado mental inicia echar comunidad en http://grasia.fdi.ucm.es/metodologia) se procede a expulsar de la comunidad indicando el motivo (usuario inactivo, usuario insatisfecho con la información recibida o por proporcionar siempre información que no gusta a los otros miembros de la comunidad). Con esta información el agente personal, el que jugaba el rol miembro de comunidad, deberá decidir qué hacer. Una opción es hacer que la tarea produzca una entidad hay que suscribirse a comunidad para iniciar otra vez la suscripción automática a la comunidad (ver Ilustración 125 ).

Ilustración 156. Diagrama GRASIA para representar la interacción echar_usuarios.

Las tareas de la Ilustración 167 se organizan según indica la Ilustración 156 . No es necesario detallar ningun orden de ejecución porque sólo hay una unidad de interacción.

En cuanto a la satisfacción de objetivos, en esta sección se mostrará solamente como se satisfacen los objetivos asociados a las tareas del flujo de trabajo compartir documentos (ver Ilustración 137 ) asociadas al rol emisor de sugerencias. El resto de tareas se muestran en http://grasia.fdi.ucm.es/metodologia. Ya se ha estudiado cómo tiene lugar la ejecución de tareas dentro de flujos de trabajo, ahora se estudia cómo su ejecución consigue satisfacer objetivos. Para ello será relevante estudiar también las entradas, salidas, aplicaciones y recursos utilizados por las tareas.

Ilustración 157. Satisfacción de los objetivos iniciales en base a la participación en flujos de trabajo (I)

La Ilustración 157 muestra cómo se satisface el objetivo proporcionar documentos interesantes. Este objetivo se satisface mediante dos tareas propagar sugerencia y revisar evaluaciones sugerencia. La que proporciona realmente las evidencias requeridas por el objetivo, que serán comentadas a continuación, es la segunda. Sin embargo, la segunda no puede suceder si no se ejecuta antes propagar sugerencia, de acuerdo con el flujo de trabajo. Así, se llega a la conclusión de que para alcanzar el objetivo proporcionar documentos interesantes, hay que ejecutar las dos tareas. Esto se indica en el diagrama asociando ambas tareas al mismo objetivo. Nótese que tras la ejecución de propagar sugerencia, no se satisface el objetivo asociado, pero su solución está más cercana ya que produce un hecho sesion usuario sugiere documento que se requiere en las condiciones de éxito y fracaso.

El hecho sesion usuario sugiere documento recoge el estado de la comunicación para poder detectar, por ejemplo, fallos en la comunicación y si la interacción ha terminado. En la Ilustración 157 , las tareas pueden indicar estas situaciones durante la creación de este hecho fijando el valor “FALLO” (tarea propagar sugerencia) o bien modificando el slot estado de este hecho (tarea revisar evaluaciones sugerencia) cuando ya existe.

Al término del flujo de trabajo, la tarea revisar evaluaciones sugerencia utiliza la aplicación servidor de aplicaciones para informar al usuario de que se tiene el informe de aceptación de la sugerencia enviada.

Ilustración 158. Condiciones para dar por fallido el objetivo proporcionar documentos interesantes

Para dar por fracasado el objetivo proporcionar documentos interesantes, se tiene que o bien ha ocurrido un fallo (el slot estado del hecho sesion usuario sugiere documento contiene el valor “FALLO”), o bien todo ha seguido los cauces normales, pero el documento no ha sido considerado interesante por la comunidad (el slot aceptada de resultado propagación está fijado a false).

Ilustración 159. Condiciones para satisfacer el objetivo proporcionar documentos interesantes

Para dar por alcanzado el objetivo proporcionar documentos interesantes, el flujo de trabajo debe haber terminado, esto es, la tarea revisar evaluaciones sugerencia debe haberse ejecutado, y la sugerencia debe haber sido aceptada por la comunidad de usuarios (el slot aceptada de resultado propagación está fijado a true).

La satisfacción de los objetivos del sistema no tiene por qué depender exclusivamente de la existencia de entidades mentales. Así, existen objetivos que pueden alcanzarse o fracasar debido a las dependencias que exhiben respecto de otros objetivos.

Ilustración 160. Dependencias entre objetivos (I)

Así, para satisfacer el objetivo mantener la calidad de documentos, se entiende que se pueden satisfacer cualquiera de sus subobjetivos (ver Ilustración 112 ). El motivo es que si se satisface alguno de ellos, se tendrán valoraciones de la calidad de la información, lo cual permitirá decidir con más acierto, o bien se evitará que aparezca información proveniente de fuentes que no han funcionado bien en el pasado. Por ello la calidad de la información que circule en las comunidades será, cuanto menos, mantenida.

El caso de sus sub-objetivos es diferente. Prevenir malas fuentes de información y disminuir malas fuentes de información necesitan que se satisfagan ambos sub-objetivos. Mientras que detectar mala información sólo necesita que se cumpla alguno. En los dos primeros, el motivo es que una identificación parcial o una eliminación parcial de malas fuentes, no es satisfactoria. Mientras que para detectar la mala información se puede confiar o bien en los expertos o bien en las herramientas de evaluación automática.

Ilustración 161. Dependencias entre objetivos (II)

Para no molestar al usuario se confía en la combinación de los mecanismos de evaluación automática junto con la consulta de expertos. El objetivo evaluar autónomamente se satiface invocando a los medios de evaluación automática, mientras que no enviar información no deseada utiliza mecanismos de filtrado colaborativo. Por ello, se requiere de la satisfacción de los dos objetivos.

La distribución de documentos interesantes es un objetivo compartido por agentes personales y por agentes de comunidad. Por ello, se entiende que se satisface cuando el agente sugiere documentos a la comunidad (objetivo proporcionar documentos interesantes) o cuando la comunidad incrementa su colección de documentos interesantes. Relacionado con incrementar colección de documentos interesantes están los objetivos encaminados a incrementar el número de usuarios en la comunidad (objetivos suscribirse fuentes información e incorporar usuarios), y a aceptar sugerencias de la comunidad (objetivo aceptar sugerencias), gracias a lo cual tienen lugar los procesos de filtrado colaborativo.

Las entidades mentales son importantes tanto para expresar la satisfacción o fracaso de los objetivos como para pasar información de una tarea a otra. Sin embargo, la actuación de las tareas, como se ha visto, crea muchos hechos que no son destruidos. Como se explicó en la sección 2.2 , los modelos de objetivos y tareas pueden emplearse para especificar qué hacer con estas entidades mentales.

Ilustración 162. Descripción de la gestión del estado mental

La Ilustración 165 muestra un ejemplo de tareas que se encargan de destruir entidades mentales. La tarea destruye temporizacion elimina los eventos de temporización utilizados para detectar fallos en la comunicación o inactividad del usuario a la hora de evaluar documentos. Estos eventos han de ser eliminados si se producen cuando la sesión a la que están asociados ha terminado (ver la documentación completa). La tarea destruye hechos asociados a sesiones elimina la información relacionada con las distintas sesiones iniciadas por el agente una vez que estas han terminado.

Para terminar, queda hablar de la percepción de los agentes personales. El único agente que de momento necesita de modelos de entorno para definir su percepción es el agente personal. Hasta ahora la percepción era una asociación simple con el servidor de aplicaciones. Este agente está unido al servidor de aplicaciones ya que es a través de él que percibe las acciones de su usuario. Tras el estudio de tareas asociadas al agente, se está en condiciones de determinar exactamente cómo es esta percepción.

Ilustración 163. Percepción del agente personal

Según la Ilustración 166 , cuando el usuario ejecuta una acción, se producen eventos. Los eventos que se tratan en el agente son usuario sugirió documento, que denota una sugerencia a una comunidad, usuario quiere suscribirse, que es interpretado por el agente como que hay que suscribirse a una comunidad, y opinión usuario, que hace referencia a la evaluación, positiva o negativa, de un documento o solicitud de evaluación de petición de suscripción.