El sistema a desarrollar es un complemento a los servicios que se ofrecen en un web comercial. El beneficio que obtiene la empresa que lo instala es un sistema de información personalizada en base a los contenidos que la empresa elija y una segmentación de sus usuarios en grupos de intereses comunes.
El sistema se concibe como un Sistema Multi-Agente en el que el usuario es representado por un Agente Personal que se agrupa con otros Agentes Personales para formar comunidades, representadas a su vez por Agentes de Comunidad. El motivo de que se dispongan estas comunidades es favorecer la segmentación de intereses (un tema por comunidad) porque con esta segmentación es más sencillo asegurar la calidad de los documentos proporcionados a cada usuario.
Las comunidades pueden verse como fuentes de información a las que el usuario se suscribe buscando información relevante a sus intereses. Una vez suscrito, el usuario comienza a recibir información de la comunidad. La información recibida se origina en los propios miembros de la comunidad o en la asociación de otras fuentes de información a la comunidad no especificadas. La información que llega al usuario debe pasar por una serie de filtros para asegurar su calidad. Cuando un usuario proporciona una sugerencia a la comunidad, la comunidad primero coteja la sugerencia con el perfil asociado a la comunidad. Si la comparación es satisfactoria, el documento pasa a ser evaluado por un conjunto de miembros de la comunidad. Antes de acudir al usuario, cada Agente Personal intenta decidir si el documento puede interesar o no a su usuario. En caso afirmativo, la petición de evaluación pasa al usuario para que este evalúe el documento recibido. En caso negativo, se emite automáticamente un voto en contra.
Tras la votación, la comunidad difunde la sugerencia sólo si la mayoría de los usuarios consultados han votado a favor del documento. Las evaluaciones positivas y negativas se contabilizan durante el proceso, influyendo en la aceptación de futuras sugerencias por parte de la comunidad y sus miembros. Puede llegar el caso en que sea necesario cuestionarse la pertenencia a la comunidad de un usuario que insiste en proporcionar información que a nadie interesa. Ello plantea una serie de políticas de permanencia en la comunidad y de aceptación de sugerencias.
o Echar a los usuarios que sólo sugieren documentos evaluados negativamente. Se trata de usuarios molestos cuyos intereses no coinciden con los de la comunidad.
o
Echar a los usuarios que evalúan negativamente demasiados
documentos. Son usuarios que aunque no hayan suministrado información
criticable, sí que han demostrado que no les interesa el tipo de información
que aquí se proporciona.
Agentes de Comunidad y Agentes Personales se caracterizan por un perfil que puede ser un conjunto de documentos, palabras clave o categorías. Los perfiles evolucionan en ambos agentes según las actuaciones de sus usuarios (miembros de la comunidad en el caso de los Agentes de Comunidad). La evolución para el caso del conjunto de documentos se describe por una ventana de documentos de anchura N, esto es, los N últimos documentos evaluados positivamente por el usuario. Para el resto de los casos, palabras clave o categorías, se admiten únicamente modificaciones realizadas por el usuario.
El sistema a desarrollar ha de admitir la incorporación de nuevas fuentes de información, en concreto foros de noticias y réplicas de este sistema. Nuevas noticias publicadas en un foro pueden ser de interés para los miembros de una comunidad cuya temática esté relacionada. Otras réplicas de este sistema podrían colaborar entre sí para intercambiar información interesante. Debe permitirse el intercambio de información siempre y cuando haya sido debidamente autorizado por el administrador del sistema. Ambas alternativas están sirven para inyectar información adicional en las comunidades, salvando así una evantual pasividad de los usuarios.
Los agentes deben poder ubicarse en distintas máquinas para distribuir la carga del sistema. Además, los agentes no podrán estar operativos permanentemente, ya que el número de usuarios es demasiado grande como para tener un número igual de Agentes Personales permanantemente activados. Se ha comprobado que cada usuario se conecta una media de una hora al día. Así, en un sitio web con diez mil usuarios registrados, cada hora se pueden encontrar 300 usuarios conectados. Esto permite que la carga media que debe soportar el sistema no sea de diez mil agentes, sino sólo trescientos. Para lograr esto, los agentes han de poder pararse, almacenando su estado previamente, para reanudar más tarde su funcionamiento.
Los usuarios se conectan con los agentes mediante una interfaz web que les permite:
o Sugerir documentos
o Evaluar documentos
o Ver documentos sugeridos por las distintas comunidades
Ver estadísticas de funcionamiento Adicionalmente, existe la figura de administrador del sistema que se encarga de:
o Definir cuántos agentes pueden existir en el sistema.
o Anexionar nuevas máquinas al sistema, incrementando así el número posible de agentes activos.
o Eliminar máquinas del sistema.
o Crear nuevas comunidades de usuarios.
o Eliminar comunidades con un número de usuarios bajo.
o Eliminar agentes cuyos usuarios han permanecido inactivos demasiado tiempo.
o Configurar parámetros de ejecución de los agentes. Umbrales de aceptación de documentos, veces que un usuario puede evaluar negativamente un documento antes de ser echado de la comunidad, número de usuarios a seleccionar cada vez que haya que evaluar un documento.
En esta sección se muestra la aplicación de actividades al caso de estudio. La especificación completa puede accederse en ...
En esta etapa el objetivo es convencerse de que el desarrollo es posible. Para ello se identifican los casos de uso más importantes que reflejen los problemas principales que se van a encontrar y cuáles van a ser los componentes del sistema que participarán en su resolució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.
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.
Tras desarrollar los casos de uso necesarios para determinar la arquitectura del sistema, se estudian los restantes siguiendo las mismas actividades que en análisis-elaboración. Los modelos resultantes no deberían modifcar sustancialmente la visión que se tiene hasta ahora del sistema. En este caso de estudio, los nuevos casos de uso reutilizan los resultados de anteriores modelos para mostrar que en realidad sólo se están considerando situaciones especiales.
Los nuevos casos de uso requieren que se tengan en cuenta las relaciones sociales. De hecho esta es la principal novedad respecto de lo que está hecho. Como resultado de esta etapa se obtendrán flujos de trabajo y diagramas GRASIA. El resto de la documentación se encuentra en http://grasia.fdi.ucm.es/metodologia.