Your SlideShare is downloading. ×
Ingeniería del software orientada a agentes
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Ingeniería del software orientada a agentes

4,126
views

Published on

Published in: Technology

1 Comment
2 Likes
Statistics
Notes
  • good my friend..!!!
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total Views
4,126
On Slideshare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
284
Comments
1
Likes
2
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. >>>> GRUPO LIMIA <<<< Miguel Casas del Río ( [email_address] ) Maite Molinos Iglesias ( [email_address] ) Belén Pereira García ( [email_address] ) INGENIERÍA DEL SOFTWARE ORIENTADA A AGENTES
  • 2. Introducción
  • 3. Introducción
    • Avance hacia un enfoque realista respecto al proceso de desarrollo del software.
    • Los modelos de desarrollo secuenciales suponen que, con suficiente estudio y análisis, es posible identificar los requisitos de un sistema antes de comenzar con su diseño e implementación > FALSO
    • Los requisitos de un sistema cambian con el tiempo > DIFICULTAD
  • 4. Introducción
    • Se han ido definiendo nuevos modelos evolutivos donde el sistema se construye a través de una serie de iteraciones.
      • Proporcionando incrementalmente nueva funcionalidad al sistema.
    • Necesario paradigma que facilite la reutilización -> orientación a objetos (clases, herencia y composición).
  • 5. Introducción
    • Casi todas las propuestas metodológicas adaptan un modelo orientado a objetos.
    • Están apareciendo algunas propuestas para aplicar metodologías ágiles, como la Programación Extrema, en el desarrollo de sistemas basados en agentes.
  • 6. Metodologías
    • Metodología: es un conjunto de guías para cubrir todo el ciclo de desarrollo de un sistema.
    • Debe proveer:
        • El ciclo de vida del proceso completo.
        • Un conjunto de conceptos y modelos.
        • Un conjunto de técnicas.
        • Un conjunto de métricas.
        • Aseguramiento de la calidad.
        • Estándares de codificación.
        • Consejos para la reutilización.
        • Guías para la administración de proyectos.
  • 7. Metodologías
    • Metodologías y notaciones de ingeniería de software orientada a agentes:
      • Ingenias.
      • MaSE.
      • Gaia.
      • AgentUML.
      • MADKiT.
      • ADELFE.
      • Mas-CommonKADS.
      • SemanticAgent.
      • Etc.
  • 8. MaSE
  • 9. MaSE
    • MaSE (Multi-agent systems Software Engineering): abstracción del paradigma orientado a objetos donde los agentes son especializaciones de objetos.
    • Los agentes se coordinan unos con otros vía conversaciones y actúan proactivamente para alcanzar metas individuales y del sistema.
  • 10. MaSE
    • Los agentes:
      • Son simplemente una abstracción que puede o no poseer inteligencia.
        • Se gestionan igualmente dentro del mismo armazón.
      • Se ven como especializaciones de objetos.
    • El sistema se construye sobre tecnología orientada a objetos y su aplicación a la especificación y diseño de sistemas multi-agente.
  • 11. MaSE
    • Análisis.
      • 3 pasos:
        • Capturar los objetivos.
        • Aplicar los casos de uso.
        • Refinar roles.
  • 12. MaSE
    • Capturar Objetivos.
      • El analista debe cumplir 2 tareas: identificar y estructurar los objetivos.
      • A partir de los documentos de requerimientos se extraen los objetivos principales del sistema.
        • Sin tener en cuenta las actividades o desarrollos que llevan hasta estos.
      • Estos objetivos son analizados y estructurados según su importancia en un diagrama de jerarquía de objetivos.
      • Todos los objetivos son siempre de nivel de sistema.
      • El analista puede asociar un rol a cada objetivo (en determinados casos).
  • 13. MaSE
    • Capturar Objetivos.
  • 14. MaSE
    • Aplicar los casos de uso.
      • Paso para convertir objetivos en roles y tareas asociadas.
      • El analista estructura los casos de uso en diagramas de secuencia mostrando la secuencia de eventos entre roles.
      • Se define la mínima comunicación necesaria entre ellos.
  • 15. MaSE
    • Refinar roles.
      • Asegurar:
        • Identificación de todos los roles necesarios.
        • El desarrollo de las tareas que definen el comportamiento y los patrones de comunicación de los agentes.
        • Todos los objetivos son tenidos en cuenta asignando un rol a cada uno.
          • Existen situaciones en las que conviene asignar más de un objetivo a un mismo rol por motivos de eficiencia.
      • Los roles son captados en el modelo de roles.
  • 16. MaSE
    • Diseño
      • Crear clases de agentes.
      • Construir conversaciones.
      • Ensamblar clases de agentes.
      • Diseño del sistema.
  • 17. MaSE
    • Construir conversaciones.
      • Una conversación MaSE define un protocolo de coordinación entre dos agentes.
        • Una conversación consiste en dos diagramas de clases de comunicación, uno para el emisor y otro para el receptor.
      • Un diagrama de clases de comunicación es un par de máquinas de estados finitos que definen una conversación entre dos clases agente participantes.
  • 18. MaSE
    • Ensamblar clases de agentes.
      • Se crea el interior de los agentes.
      • Se usa un lenguaje de modelado arquitectónico que combina la naturaleza abstracta de los lenguajes tradicionales de descripción con el leguaje de restricción de objetos (especificación de detalles de bajo nivel).
  • 19. MaSE
    • Diseño del sistema.
      • En esta fase se decide la configuración final del sistema a implementar.
      • Se define la arquitectura global del sistema mediante diagramas de despliegue para mostrar el número, tipo y localización de los agentes.
      • Se toman las decisiones de implementación que no se habían tomado antes, como el lenguaje de programación a usar o el “framework” para las comunicaciones.
  • 20. Herramientas que soportan MaSE.
    • AgentTool
      • Es el software de soporte que actualmente implementa los siete pasos del proceso MaSE.
      • Con soporte para transformar modelos de análisis en modelos de diseño.
      • Permite crear de modo visual todos los diagramas del proceso de desarrollo, pudiendo realizar cualquiera de los 7 pasos en el orden que se prefiera.
      • Dispone de una base de conocimiento persistente, un verificador de conversaciones y generación automática de código.
  • 21. MESSAGE E INGENIAS
  • 22. MESSAGE
    • MESSAGE (Methodology for Engineering Systems of Software Agents) es una metodología orientada al desarrollo de sistemas industriales, de media o gran escala.
    • La metodología MESSAGE cubre las fases de Análisis y Diseño y su contribución principal son los conceptos que utiliza, de un nivel de abstracción superior al de las metodologías orientadas a objetos (nivel de conocimiento), y los diagramas para ilustrar estos conceptos en el modelo de análisis, añadidos al UML.
    • Integra de forma coherente los conceptos de organización, tarea, rol y objetivo y aporta nuevos diagramas como el diagrama de delegación, de flujo de trabajo o de dominio, y otros similares a los aportados por otras metodologías, como el diagrama de objetivos, tareas o interacciones.
  • 23. MESSAGE
    • Conceptos :
      • Agente: es una entidad autónoma y atómica, capaz de prestar una función (potencialmente) útil. Esa capacidad funcional se la denomina servicio.
      • Rol : es una descripción externa de un agente en un contexto particular. Un agente puede desempeñar varios roles, y un mismo rol puede estar representado por varios agentes.
      • Organización : es un grupo de agentes que cooperan y con un propósito común.
      • Recursos: son las entidades no autónomas, utilizadas por los agentes. Se describen con los conceptos tradicionales de orientación a objetos.
  • 24. MESSAGE
    • Conceptos
      • Tareas : son la unidad que representa la actividad en el nivel de conocimiento, realizada por un solo realizador principal. Las tareas tienen dos situaciones que describen pre-condiciones y post-condiciones. Además, las tareas se pueden subdividir en subtareas, ejecutadas (posiblemente) por otros realizadores. Como se considera a las tareas como máquinas de estados (StateMachines), se utilizan los diagramas de actividad de UML para describirlas.
      • Las interacciones: representan la segunda forma de actividad, junto con las tareas. Las interacciones, por definición, son realizadas por varios participantes y tienen un propósito que todos los participantes persiguen. Un protocolo de interacción (InteractionProtocol).
  • 25. MESSAGE
    • MESSAGE utiliza las siguientes vistas:
      • Vista de Organización (OV). Muestra entidades concretas (ConcreteEntities) (Agentes, Organizaciones, Roles, Recursos) en el sistema y su entorno y relaciones de alto nivel entre ellos como agregación, poder, “conocimiento de” (acquaintance).
      • Vista de Objetivo/Tarea (GTV). Muestra objetivos, tareas, situaciones y sus dependencias. Los objetivos y las tareas tienen atributos de tipo situación que permiten crear dependencias lógicas, mostrar división de objetivos y tareas, etc. Las dependencias temporales se denotan con la sintaxis de los diagramas de actividad de UML.
  • 26. MESSAGE
    • MESSAGE utiliza las siguientes vistas:
      • Vista de Agente/Role (AV). Se representan los objetivos del agente, tareas que sabe cómo realizar, recursos que utiliza, eventos a los que atiende, etc. En el siguiente diagrama se muestra un Diagrama de Delegación, además se utilizan Diagramas de Workflow y tablas-esquema.
      • Vista de Interacción (IV). Se representa el iniciador, el motivador, los colaboradores, la información relevante comunicada, los eventos que dispara, y efectos relevantes de la interacción.
      • Vista de Dominio (DV). Muestra los conceptos importantes del dominio donde se desarrolla el SMA y sus relaciones.
  • 27. MESSAGE
    • El proceso de análisis de MESSAGE consiste en aplicar sucesivamente una estrategia de refinamiento de los modelos del sistema.
    • El nivel inicial de descomposición del sistema es el nivel 0, que se ocupa de definir el sistema a desarrollar con respecto a las entidades externas (sistemas, usuarios) y entorno. En este nivel se identifican las principales entidades y sus relaciones. El sistema se ve como el conjunto de organizaciones que interactúan con recursos, actores o otras organizaciones. Se construyen las vistas de organización y vista de objetivos/tareas.
    • En el nivel 1, se estudia la estructura y el comportamiento de entidades como la organización, tareas, objetivos, dominio, etc.
    • Se pueden añadir más niveles para tratar otros aspectos como requisitos no funcionales, rendimiento, distribución, tolerancia a fallos, seguridad...
  • 28. Ingenias
    • INGENIAS ha sido desarrollada a partir de los resultados obtenidos en MESSAGE. INGENIAS mejora MESSAGE en tres aspectos:
      • Integración de las vistas de diseño del s istema.
      • Integración de resultados de investigación.
      • Integración con el ciclo de vida de desarrollo de software.
  • 29. Ingenias
    • Modelos
      • Agente : describe las responsabilidades con tareas y roles. También considera el control del agente definiendo sus objetivos y los estados mentales que se requieren durante su ejecución.
      • Organización : describe el marco en el que existen los agentes, los recursos, las tareas y el propósito del sistema. Para definir la organización hay que considerar su estructura, relaciones sociales y funcionalidad. La estructura determina la arquitectura del sistema. Se describe en términos de grupos y flujos de trabajo. Los flujos de trabajo relacionan tareas, los recursos asociados a las mismas y sus responsabilidades.
      • Entorno : define los sensores y actuadores de los agentes. También identifica los recursos, agentes y aplicaciones existentes con las que tienen que interactuar los agentes.
  • 30. Ingenias
    • Modelos
      • Tareas y Objetivos: este punto de vista está influenciado por el principio de racionalidad y su principal propósito es justificar la ejecución d e tareas en función de los objetivos. También proporciona la descomposición de tareas y objetivos. Para relacionar ambos, hay relaciones especializadas que determinan la información que es necesaria para considerar que un objetivo se ha satisfecho o no. Finalmente, este punto de vista detalla aspectos de bajo nivel de las tareas, como los recursos que necesitan para su ejecución, los módulos de software que utilizan y sus entradas y salidas.
      • Interacciones: describen cómo se produce la coordinación entre los agentes. Esta descripción va más allá de los que serían los diagramas de secuencia o colaboración en UML ya que muestran también la motivación de los participantes en la interacción. Para ello incluyen información del estado mental que requieren los agentes en su ejecución, así como las tareas que ejecutarán. Esto permite justificar a nivel de diseño por qué los agentes participan en una interacción y por qué deben continuar.
  • 31. Ingenias
  • 32. Ingenias
    • Herramientas que soportan Ingenias:
      • INGENIAS cuenta con un entorno de desarrollo integrado (IDE) que incorpora una herramienta de especificación y un generador de código.
      • La herramienta de especificación se ha construido con la herramienta METAEDIT+ que procesa los meta-modelos que define INGENIAS, generando editores particularizados. Se está desarrollando una versión distribuible de estos meta-modelos.
      • La generación de código se basa en una sustitución de texto avanzada, contemplando variables, repeticiones y órdenes. Está hecha en Java, aunque es posible en cualquier lenguaje gracias a la utilización de lenguajes de marcado, aplicables a cualquier documento de texto.
  • 33. La metodología GAIA
  • 34. La metodología GAIA
    • Considera un sistema basado en agentes como una sociedad u organización.
    • Especialmente indicada para:
      • La organización de la estructura del sistema no varía en el tiempo.
      • Con agentes heterogéneos.
      • Pocos tipos de agentes.
      • Cada agente realiza un uso importante de recursos.
  • 35. La metodología GAIA
    • La especificación de requerimientos independiente del de análisis y diseño del sistema.
  • 36. La metodología GAIA
    • Conceptos abstractos (entidades que no tienen por qué tener una imagen directa de sí mismos sobre la implementación).
    • Conceptos concretos (entidades que tienen un reflejo directo de sí mismas en la implementación del sistema).
  • 37. La metodología GAIA - Roles
    • GAIA está basada en el concepto de roles.
    • Una organización consta de una colección de roles.
    • Los roles mantienen ciertas relaciones entre ellos y forman parte de patrones de interacción institucionalizados con otros roles.
  • 38. La metodología GAIA - Roles
    • Cada rol se define mediante cuatro atributos:
      • Responsabilidades del agente (funcionalidad)
        • Propiedades dinámicas : estados positivos que debe alcanzar, dadas ciertas condiciones del entorno.
        • Propiedades de seguridad : estados que se mantienen a lo largo de la ejecución (invariantes).
      • Permisos (E/S y o generación de información, la cuál es necesaria para llevar a cabo las responsabilidades)
      • Tareas asociadas (actividades que realiza independiente, sin interactuar con otros agentes).
      • Protocolos : interacciones asociadas que definen el modo en el que se comunican con otros agentes.
  • 39. Análisis – Modelo de roles
    • El modelo de roles define los principales roles que aparecen en el sistema junto con sus propiedades definitorias (descripción abstracta).
      • Los permisos/derechos asociados con el rol
      • Las responsabilidades del rol.
      • Tareas asociadas.
  • 40. Análisis – Modelo de interacciones
    • El modelo de interacciones define las interacciones y dependencias. Los protocolos de describen mediante las propiedades siguientes:
      • Objetivo.
      • Iniciador.
      • Receptor.
      • Entradas.
      • Salidas.
      • Procesamiento.
  • 41. Fase de análisis – Paso 1
    • Identificar los roles en el sistema: lista de roles, cada uno descrito de manera informal.
    • Una lista de posibles roles para el ejemplo:
      • Atendedor.
      • Buscador.
      • Seleccionador.
      • Geolocalizador.
      • Calculador de distancias.
    • Descripción informal del rol Seleccionador:
      • Rol Seleccionador: es el encargado de determinar cuáles de los candidatos que cumplen con los requisitos de búsqueda para ser presentados al usuario.
  • 42. Fase de análisis – Paso 2
    • Modelo de interacciones: identificar y documentar los protocolos.
    • Una lista posible de protocolos:
      • Ubicar candidatos.
      • Georreferenciar candidato.
      • Seleccionar candidatos.
      • Determinar distancia entre dos candidatos.
    • Definición de un protocolo:
  • 43. Fase de análisis – Paso 3
    • Modelo de roles con la información anterior.
    • E squema de definición de un rol:
  • 44. Fase de análisis – Paso 4
    • Repetir los pasos 2 y 3 hasta obtener el nivel de detalle deseado.
  • 45. Diseño – Modelo de agentes
    • El modelo de agentes : define los tipos de agente, número de instancias de cada tipo (se creará en tiempo de ejecución) y rol.
      • Los tipos de agentes se crean por agregación de roles. El diseñador empaqueta todos aquellos que guardan relación entre sí.
      • La notación en forma de árbol, permite definir los tipos de manera jerárquica: si un tipo está compuesto por varios subtipos, es que está compuesto por los roles incluidos en cada subtipos. Cada hoja se corresponde con los roles del modelo de roles mientras que el resto de nodos son tipos de agente.
      • El número de instancias se indica con un intervalo (m…n) encima de la entidad
  • 46. Diseño – Modelo de servicios
    • El modelo de servicios : define los servicios del agente asociados a cada rol y las propiedades de los mismos.
      • Un servicio es una función de un agente y se define
        • Entradas
        • Salidas
        • Pre-condiciones
        • Post-condiciones
    • Las entradas y salidas derivarán del modelo de interacción.
    • Las pre-condiciones y post-condiciones representan restricciones sobre estos servicios, y son derivadas de las propiedades de seguridad del rol.
  • 47. Diseño – Modelo de conocimiento
    • El modelo de conocimiento: define los flujos de comunicación entre los tipos de agentes.
    • Para ello se utiliza la notación de grafos dirigidos, en los que los nodos representan los tipos de agente y los arcos a caminos de comunicación.
  • 48. Fase de diseño – Paso 1
    • Crear el modelo de agentes juntando roles en tipos de agente y formando una jerarquía.
    • Una posible identificación de roles:
      • Atendedor -> 1.
      • Buscador -> * (una por cada nivel de búsqueda).
      • Seleccionador -> 1.
      • Geolocalizador -> 1.
      • Calculador de distancias -> 1.
  • 49. Fase de diseño – Paso 2
    • Crea el modelo de servicios con las actividades, protocolos y propiedades dinámicas y de seguridad de los roles.
    • Un modelo se servicios para uno de los roles:
  • 50. Fase de diseño – Paso 3
    • Crear un modelo de conocidos a partir del modelo de interacción y el de agentes.
    • Un modelo se servicios para el ejemplo sería:
  • 51. Fase de implementación
    • GAIA propone aplicar técnicas de diseño OO.
    • GAIA sólo busca especificar cómo una sociedad de agentes colabora para alcanzar los objetivos del sistema, y qué se requiere de cada uno para lograr dichos objetivos.
    • Por lo tanto, nos quedamos en un nivel de abstracción bastante alto.
    • GAIA pretende conseguir desacoplar GAIA de las distintas soluciones de implementación de agentes pero no se ha demostrado.
  • 52. Variante GAIA
    • GAIA con Abstracciones Organizacionales.
      • En la fase de análisis, se introducen reglas organizacionales que impactarán en la fase de diseño sobre los modelos de roles e interacciones de la fase de análisis.
      • En la fase de diseño, se detalla la estructura organizacional, aplicando cuando es posible el uso de patrones organizacionales.
  • 53. Variante GAIA
    • Facilita trabajar con sistemas más complejos donde existan reglas organizacionales:
      • Sistemas abiertos en los que es necesario establecer políticas de seguridad y validación.
      • Sistemas grandes donde es necesario agrupar los agentes en organizaciones.
      • .. etc.
    • Permite establecer propiedades a nivel de organización.
      • Simplifica la arquitectura de sistemas multi-agente, eliminando la necesidad de creación de roles específicos, para tratar esta serie de propiedades, habituales en el mundo real que se pretende modelar.
  • 54. Conclusiones
  • 55. Conclusiones
    • ¿cuál es la metodología que debemos utilizar o cuál es la mejor metodología?
      • La respuesta no es sencilla ya que cada metodología parte de un concepto distinto de agente y cada una de ellas se especializa en áreas concretas de trabajo.
      • Una posible solución es partir de la propia experiencia del desarrollador.
  • 56. Conclusiones
    • MaSe
      • para desarrolladores acostumbrado al proceso unificado y herramientas de orientación a objetos ya que les puede resultar más familiar.
  • 57. Conclusiones
    • INGENIAS
      • Esta sería la metodología más apropiada si lo que se quiere es conducir y razonar el análisis y diseño utilizando los conceptos específicos de los sistemas.
  • 58. Conclusiones
    • GAIA
      • Si lo que se busca es un enfoque más orientado a agente se puede escoger una metodología como GAIA que nos da una visión más superficial del sistema sin entrar en detalles de diseño e implementación.