Diseño de sistemas multiagente

Diseño de sistemas multiagentePrometheus

ECSDI

CS-FIB-UPC cbea

Curso 2017/2018

ECSDI (CS-FIB-UPC cbea) Diseño de sistemas multiagente Curso 2017/2018 1 / 63

Índice

1 Introducción

2 Fases de diseñoEspecificación del sistemaDiseño ArquitectónicoDiseño Detallado


Introducción

1 Introducción

2 Fases de diseño


Introducción

Introducción

Prometheus es una metodología iterativa que cubre el procesocompleto de ingeniería de software

Análisis

Diseño

Diseño detallado

Implementación

Su objetivo es el desarrollo de agentes inteligentes, orientado enparticular a agentes BDI

Usa como abstracciones objetivos, creencias, planes y eventos


Introducción

Prometheus

La especificación resultante puede ser desarrollada en cualquierimplementación de agentes que cubra esas abstracciones

En particular está pensada para la implementación con ellenguaje de agentes JACK

Es una metodología que ha evolucionado a partir de laexperiencia práctica en el desarrollo de sistemas agentes

Está enfocada al desarrollo de software en la industria

Ha recibido la experiencia de uso en proyectos tanto a pequeñaescala (estudiantes) como en la industria (AOS Grouphttp://aosgrp.com/)


http://aosgrp.com/

Introducción

Prometheus

Esta focalizada en dar una guía y una estructuración detalladapara facilitar el desarrollo de herramientas de diseño

Es una mezcla de:Una notación gráfica para facilitar una vista general del sistema

Una notación textual estructurada para una vista detallada

Es jerárquica y modular

Existe un prototipo de herramienta para el diseño (PDTool)


Introducción

Antes de empezar

Estamos diseñando sistemas distribuidos (no monolíticos)

El sistema interactúa con múltiples entidades externas (tambiéndistribuidas) al mismo tiempo

El sistema puede tener múltiples réplicas de cada entidad que locompone

Las entidades internas y externas pueden aparecer y desaparecerdinámicamente

Las acciones que realiza el sistema no han de ser síncronas

Puede haber múltiples flujos de ejecución simultáneamente


Fases de diseño

1 Introducción

2 Fases de diseño


Fases de diseño

Prometheus - Fases

(1) Especificación del sistema:

Focalizada en la identificación de las funciones básicas delsistema:

Roles (funcionalidades)

Objetivos

Escenarios

Entradas (percepts), salidas (actions) y su procesamiento


Fases de diseño

Prometheus - Fases

(2) Diseño arquitectónico:Detemina qué agentes contendrá el sistema y cómointeraccionarán

(3) Diseño detallado:Describe los elementos internos de los agentes

La forma en la que realizarán sus tareas dentro del sistema

Enfoque en describir capacidades (capabilities, módulos dentrodel agente), eventos internos, planes y estructuras de datosinternas


Fases de diseño

Prometheus - Vista del proceso


Fases de diseño Especificación del sistema

1 Introducción




PrometheusFase de especificación del sistema

Sistema definido por:Objetivos: Diagrama de objetivos

Escenarios: Escenarios de casos de uso

Roles: Descriptores de funcionalidades

La interacción con el entorno se describe en términos de:Acciones

Percepciones

Datos externos



PrometheusFase de especificación del sistema



Fase de especificación del sistemaProceso

Comenzar con una descripción a alto nivel del sistema (textual)

Identificar los actores

Identificar los objetivos del sistema (y subobjetivos)

Identificar los roles (funcionalidades) que cubren los objetivos

Identificar/definir escenarios

Identificar entradas y salidas (percepciones y acciones)

¡Atención!¡No es un proceso secuencial!Cada elemento realimenta/se interrelaciona con los otrosECSDI (CS-FIB-UPC cbea) Diseño de sistemas multiagente Curso 2017/2018 15 / 63


Fase de especificación del sistemaObjetivos

¿Para que se construye el sistema? Objetivos principales

¿Cuales son los subobjetivos que permiten conseguirlos?

Descritos en el diagrama de objetivos

¿Cómo? (subobjetivos)

¿Porqué? (objetivos padre)

Objetivo



Fase de especificación del sistemaPercepciones

Los agentes están en un entorno y recibirán información de él(percepciones)

Habrá cosas que sucederán en el entorno que serán significativaspara los agentes (eventos)

Estos pueden ser directamente percepciones u obtenerse depercepciones después de un procesamiento

Percepción



Fase de especificación del sistemaAcciones

Las acciones son lo que hacen los agentes para modificar suentorno

Pueden ser simples y directas o ser interacciones complejas

Preguntas:¿Tienen una duración?

¿Pueden fallar?

¿Sabremos si lo hacen?

¿Si fallan tendrán un efecto en el entorno?

Acción



Fase de especificación del sistemaRoles

Los roles describen funcionalidades que el diseñador piensa quedebe tener el sistema

Las funcionalidades deben ser específicas y poder ser definidasen una o dos frases

Los roles estarán ligados a los objetivosPuede haber más de un rol por objetivo

Un rol puede aparecer en más de un objetivo

La metodología define una serie de descriptores que debenusarse para detallar un rol (funcionalidad)

Rol



Fase de especificación del sistemaEscenarios

Los escenarios muestran una instancia particular de la ejecucióndel sistema (alternativas son escenarios separados o variaciones)

Un escenario consiste en una secuencia de pasos (acciones,percepciones, objetivos, escenarios)

Cada paso está ligado a un rol y a los datos usados y producidos

Cada objetivo del sistema debe aparecer en al menos unescenario

Escenarios habitualmente involucran más de un rol(funcionalidad)

Escenario



Especificación del sistema - EjemploDescripción de alto nivel

Queremos un sistema que sea capaz de manejar losrequerimientos de una biblioteca, básicamente:

Permitir sacar libros, informando al usuario de la fecha deretorno

Permitir retornar libros

Permitir la reserva de libros aún no disponibles

Permitir la notificación de libros prestados que están fuera deplazo

Permitir la notificación de llegada de libros reservados



Especificación del sistema - EjemploActores

Podemos identificar dos actoresBibliotecaUsuario

Estos actores no tienen porque ser agentes en el diseño finalTambién pueden ser actores que no modelemos pero quequeramos tener para representar por ejemplo los elementos delentorno que generan las percepciones o reciben las acciones



Especificación del sistema - EjemploObjetivos, primer nivel

Podríamos identificar como objetivos de alto nivel del sistema:Prestar libros (notificando fecha retorno)

Retornar libros

Reservar libros no disponibles

Notificar libros fuera de plazo

Notificar la llegada de libros reservados



Especificación del sistema - EjemploSubobjetivos

Para cada uno de los objetivos nos preguntamos cómo son obtenidosPrestar libro =⇒

Registrar el identificador del libro al identificador del usuario

Informar de la fecha de retorno

Retornar libro =⇒Borrar identificador de libro del identificador de usuario

Reservar libros no disponibles =⇒Registrar el id del libro como reservado por el id del usuario

Informar de la fecha de retorno registrada del libro al usuario



Especificación del sistema - EjemploSubobjetivos

Para cada uno de los objetivos nos preguntamos cómo son obtenidosNotificar libro fuera de plazo =⇒

Acceder al registro de libros al inicio del día

Enviar correo para los libros no entregados a tiempo

Notificar la llegada de libros reservados =⇒Acceder a la lista de libros reservados por los usuarios

Enviar correo informando de la llegada del libro



Especificación del sistema - EjemploDiagrama de objetivos



Especificación del sistema - EjemploEscenarios

Identificaremos cinco posibles escenarios1 Cuando el usuario viene a pedir un libro (Préstamo Libro)2 Cuando el usuario retorna un libro (Devolución Libro)3 Cuando un libro está fuera de plazo (Fuera de plazo)4 Cuando el usuario pide reservar un libro (Reserva Libro)5 Cuando el libro reservado llega (Llegada libro)



Especificación del sistema - EjemploEscenarios - Detalle

Un escenario se define a partir de:Subescenarios/variantes: Descomposición del escenario ovariantes

Objetivos: Cuáles son los objetivos que se persiguen en esteescenario

Percepciones: Qué eventos exteriores ponen en marcha elescenario

Actividades y acciones: Cuales son las funcionalidades que sedesarrollan dentro del escenario

Mensajes: Cuáles son las comunicaciones (generador −→receptor) que se realizan dentro del escenario

Roles: Cuáles son los roles que participan en el escenarioECSDI (CS-FIB-UPC cbea) Diseño de sistemas multiagente Curso 2017/2018 28 / 63


Especificación del sistema - EjemploEscenarios - Detalle

Podemos esbozar los pasos que componen cada escenarioPréstamo Libro

1 Petición de libro2 Dar fecha de retorno3 Registrar el código de libro como prestado4 Dar el libro

Devolución Libro1 Devolver libro2 Borrar el código del libro de los prestados

...



Especificación del sistema - EjemploRoles del sistema

Podemos identificar cinco roles en el sistema:1 Procesador de prestamos de libros

2 Procesador de libros retornados

3 Procesador de libros fuera de plazo

4 Procesador de reserva de libros

5 Procesador de llegada de libros reservados

Los roles pueden estar asignados al mismo actor/agente o variospueden compartir roles



Especificación del sistema - EjemploPercepciones/acciones

Hemos de identificar las entradas y salidas del sistema en forma depercepciones y acciones y asignarlas a los roles

Préstamo de libros:Percepción: Petición de libroAcción: Dar libro

Retorno de libro:Percepción: Libro retornado

Libros fuera de plazoPercepción: Inicio del díaAcción: Enviar correo de libro retrasado



Especificación del sistema - EjemploPercepciones/acciones

Hemos de identificar las entradas y salidas del sistema en forma depercepciones y acciones y asignarlas a los roles

Reserva de libroPercepción: Petición de reservaAcción: Informar de fecha de retorno del libro

Llegada de libros reservadosPercepción: Llegada de libro reservadoAcción: Enviar correo de llegada de libro



Especificación del sistema - EjemploRelaciones entre elementos

Hemos de ligar los objetivos con los escenarios y los rolesHemos de ligar las percepciones y acciones a roles



Especificación del sistema - DescriptoresRoles

RolNombre Libro Fuera de PlazoDescripción Se encarga de informar a los usua-

rios que no han devuelto un libroa tiempo

Evento Iniciador Inicio del diaAcciones Enviar un mail avisando del retra-

soInformación usada Fecha de retorno de los libros pres-

tadosInformación Producida ningunaObjetivos Notificar retraso



Especificación del sistema - DescriptoresEscenarios

EscenarioNombre Fuera de plazoDescripción Hay libros prestados que no han sido retornados

a tiempoEvento Inicio del díaPasosTipo Nombre Rol DatosPercepción Inicio Día P. Libro fuera PlazoObjetivo Notificar Retraso P. Libro fuera PlazoObjetivo Buscar Libros Re-

trasadosP. Libro fuera Plazos Libros Prestado

Objetivo Enviar Mail LibroRetrasado

P. Libro fuera Plazos

Acción Enviar e-mail P. Libro fuera Plazo e-mail usuario



Especificación del sistema - DescriptoresPercepciones

PercepciónNombre Inicio del díaDescripción Evento que indica el inicio de

un nuevo díaInformación NingunaConocimiento Actualizado Hay un nuevo díaFuente EntornoProcesamiento NingunoAgentes que responden Por determinarFrecuencia Una vez al día



Especificación del sistema - DescriptoresAcciones

AcciónNombre Enviar mail retrasoDescripción Enviar un mail a un usuario que no ha

retornado un libroParámetros E-mail usuario, código del libroDuración InstantáneoFallo Puede no llegar al usuarioEfectos Laterales Ninguno


Fases de diseño Diseño Arquitectónico

1 Introducción




PrometheusFase de diseño arquitectónico



Fase de diseño arquitectónico

¿Cuando un componente del sistema es un agente?¿Es autónomo?

¿Tiene objetivos?

¿Es activo? (tiene procesos internos en ejecución de maneraconcurrente)

¿Hace varias cosas a la vez? ¿debe razonar respecto a lainteracción entre ellas?

¿Debe cambiar la manera de hacer las cosas basándose encambios en el entorno?

Si la respuesta es mayoritariamente sí deberíamos modelarlocomo un agente




Identificar los agentes del sistema:Agrupar las funcionalidades en tipos de agentes basándose en sucohesión y acoplamientoAgrupar funcionalidades que:

Están relacionadas según el sentido comúnRequieren la misma información

No agrupar funcionalidades queNo están claramente relacionadasHan de ejecutarse en plataformas separadasNo pueden compartir información por seguridad/privacidadHan de ser modificadas por diferentes desarrolladores




Generar descriptores de agentes basados en sus tipos:¿Cuántos agentes de cada tipo debe haber (uno, muchos,dinámico)?

¿Cuál es el tiempo de vida del agente (permanente/ocasional)?

¿Cuál es el estado inicial del agente?

¿Qué pasa cuando un agente desaparece del sistema?

¿Cuáles son los datos usados/producidos por el agente?

¿A qué eventos reaccionan los agentes?

¿Cuáles son sus interacciones? ¿Cómo se realizan?



Fase de diseño arquitectónicoDiagramas intermedios

Tres diagramas intermedios nos facilitarán las decisiones:El diagrama de agrupación de roles a agentes

El diagrama de relación entre agentes

El diagrama de acoplamiento entre datos y roles



Fase de diseño arquitectónicoDiagramas de interacción/protocolos

Identificamos y diseñamos la interacción entre los agentes

Usamos como base los pasos de los escenarios (casos de uso):Si un paso involucra un rol asignado a un agente y el siguienteinvolucra otro rol asignado a otro agente, tendrá que haber unintercambio de mensajes

Definir los protocolos de interacción

Protocolo



Diseño Arquitectónico - Ejemplo

Identificamos como creencias que han de manejar los agentes delsistema la información de todos los libros prestados y reservadosEl rol del procesador de préstamo y procesador de retornomodifican la creencia del préstamo de un libroEl rol de procesador de fuera de plazo utiliza esa creencia pararealizar su acciónEl rol de procesador de reserva modifica la creencia de la reservade un libroEl rol de procesador de llegada de reserva usa esta creencia pararealizar su acción



Diseño Arquitectónico - EjemploDiagrama de roles/agentes

Identificamos tres agentes diferentes (prestador, reclamador yreservador)Agrupamos los roles según su coherencia semántica



Diseño Arquitectónico - EjemploDiagrama de acoplamiento de datos

Identificamos dos fuentes de datos (préstamos y reservas)Asignamos los roles a las fuentes de datos indicando en quedirección (entrada/salida) va la relaciónNo tienen por que corresponder a fuentes de datos físicamenteseparadasTampoco una fuente de datos tiene porque corresponder a unafuente de común entre todos los roles



Diseño Arquitectónico - EjemploDiagrama de relación entre agentes

Decidimos que los agentes se vayan comunicando entre si lasfechas de final de plazoEsto relaciona a los agentes prestador con el reservador y elprestador con el reclamador



Diseño Arquitectónico - EjemploMensajes y Protocolos

La comunicación entre los agentes nos obligará a definir:Mensajes: ¿Cuál es su contenido y su significado?Protocolos: ¿Quién interviene en el protocolo? ¿Como se realizael intercambio de mensajes?



Diseño Arquitectónico - DescriptoresAgentes

AgenteNombre Agente ReclamadorDescripción Se encarga de procesar los libros retrasadosCardinalidadmínima

1 Cardinalidadmáxima

1

Duración ilimitada Inicialización NingunaEn casode fallo

Nada Percepciones Inicio de día

Acciones Enviar mail retraso ausuario

Usa datos Libros prestadosa usuarios

Producedatos

Ninguno Datosinternos

Por definir

Objetivos Notificar restraso, ... Roles Procesador Fueraplazo

Protocolos Protocolo Fecha



Diseño Arquitectónico - DescriptoresProtocolos

ProtocoloNombre Pedir FechaDescripción Obtener la fecha de retorno de un libroMensajes Pedir Fecha Retorno, Enviar Fecha RetornoEscenarios Fuera de plazo, Reserva libroAgentes Prestador, Reservador, Reclamador

Notas



Diseño Arquitectónico - DescriptoresMensajes

MensajeNombre Pedir Fecha RetornoDescripción Pedir la fecha de retorno de un li-

broDistribución De Reservador a Prestador, De Re-

clamador a PrestadorPropósito Obtener la fecha de retorno de un

libroInformación contenida Identificador del usuario y libro



Diseño Arquitectónico - EjemploVisión General del Sistema


Fases de diseño Diseño Detallado

1 Introducción




PrometheusFase de diseño detallado



Diseño Detallado

En esta fase se desarrollan los elementos internos de los agentesSe definen en función de capacidades, datos, eventos y planesSe usan diagramas de proceso como un paso intermedio entreprotocolos de interacción y planes

Pasos:Desarrollar la estructura interna de cada agente individualIdentificar las capacidades de cada agente empezando con susfuncionalidadesGenerar los descriptores de capacidadesGenerar los diagramas de visión general del agenteGenerar los descriptores de los planesGenerar los descriptores de los eventosGenerar los descriptores de los mensajes externos e internosGenerar los descriptores de los datos



Diseño DetalladoCapacidades

Las capacidades se definen como módulos (un trozo de códigoque hace una cosa en particular)

Se toma como partida los roles (funcionalidades) definidos en laprimera fase dividiéndolos hasta obtener capacidades primitivas

Las funcionalidades de bajo nivel que son comunes entre variosagentes pueden usarse también como capacidades

Hay que tener presente la reusabilidad a la hora de determinarlas

Capacidad



Diseño DetalladoCapacidades/planes

Las capacidades se descomponen a su vez en planes, que sonlos que llevan a cabo las tareasEstos estarán:

Conectados a las percepciones/eventosRecibirán los mensajes generados por los protocolos deinteracción entre los agentesGenerarán mensajes internos para comunicarse con otros planesdentro de la capacidad

PlanMensaje



Diseño Detallado - EjemploDiagrama general del agente/capacidades

Diagrama del agente Prestador

Entorno

Agente



Diseño Detallado - EjemploDiagrama de plan

Planes de la capacidad Prestar Libro



Diseño Detallado - DescriptoresCapacidades

CapacidadNombre Prestar Libro (C)Descripción Obtiene un libro físico, determina la fecha de

retorno, ...Objetivos Prestamo, ...Protocolos NingunoMensajes Entrantes NingunoMensajes Salientes NingunoMensajes Internos Pedir registro libro, fecha retorno libro, ...Percepciones Petición de libro (P)Acciones Dar Libro (A)Datos usados Base de datos usuarioDatos producidos Fecha de retorno libro, registro de préstamoDatos Internos Por definirPlanes incluidos Prestar Libro, Registrar préstamo, ...Capacidades incluidas Ninguna



Diseño Detallado - DescriptoresPlanes

PlanNombre Prestar Libro (P)Descripción Desarrolla las acciones necesarias para

prestar un libroIniciador Percepción de petición de préstamoMensajes Entrantes NingunoMensajes Salientes Pedir registro libro, Coger libro físicoDatos usados Base de datos usuarioDatos producidos NingunoFallo Falta de acceso a los datosRecuperación de fallo Enviar mensaje a mantenimientoProcedimiento Código del planECSDI (CS-FIB-UPC cbea) Diseño de sistemas multiagente Curso 2017/2018 62 / 63


Diseño Detallado - DescriptoresDatos

DatosNombre Base de datos de préstamosDescripción Contiene los registros de los préstamos de

libros a usuariosTipo de datos Registro préstamo de libro a usuarioCampos Id usuario, Id Libro, Fecha retornoPersistente SíExterna al sistema NoIncialización VacíaProducida por Agente prestador, plan registrar préstamoUsada por Agente Prestador, Agente Reclamador, ...Usada cuando El usuario pide un libro, ...ECSDI (CS-FIB-UPC cbea) Diseño de sistemas multiagente Curso 2017/2018 63 / 63

Diseño de sistemas multiagente

Documents

Transcript of Diseño de sistemas multiagente