AGIL-Shell

miércoles, 21 de mayo de 2008

AGIL-Shell, es una herramienta para el modelado de procesos. Esta herramienta para el diseño e implementación de sistemas multi-agente empleando una metodología ágil. Su visión se basa en 3 pasos:
1.- Expertos del dominio construyen un modelo es los procesos de trabajo existentes.
2.- Estos procesos existentes se analizan para detectar escenarios de aplicación de agentes.
3.- Estos procesos se van incrementando para introducir agentes en ellos.

Process Graph: La vista principal de AGIL-Shell es un gráfico en el cual los ingenieros y expertos pueden definir procesos ordenando actividades y datos como nodos, y representando el flujo de datos y la secuencia de actividades mediante flechas. Para cada actividad, su nombre y su rol es visualizado. Para cada agente mensaje, el comando y la ontología son mostradas.

Process Explorer: Modelos de proceso complejos se representan y se visualizan empleando un orden jerarquico de procesos y sub-procesos en una vista de arbol.

Customizer: Las propiedades de la actividad seleccionada actualmente, de los procesos, mensajes, agentes u ontologías pueden ser editadas.

Community Viewer: Este gráfico muestra los caminos de ejecución entre los roles(humanos, actores,...) en el sistema. Los agentes son mostrados en nodos, los cuales muestra el tipo de rol. Esta vista permite detectar cuellos de botella. Los nodos con muchas flechas entrantes y salientes representan roles que operan en una gran cúmulode datos. Estos puntos de información puede ser que no lleguen a beneficiarse de los servicios de información basados en agentes.

Además de estas vistas, existen otras vistas de procesos que pueden derivarse del metamodel. Por ejemplo, la secuencia de actividades permite extraer una vista de ciclo de vida en la cual solo las actividades que son llevadas a cabo por un agente o un humano son mostradas. Estas vistas permiten realizar el diseño con los procesos humanos participantes, los cuales (desde su punto de vista) pueden evaluar si su rutina diaria está suficientemente cubierta por el conjunto de todos los procesos.

Un caso llevado a la práctica II

Introducción

La tecnología Multiagente se supone que es una posible solución, debido a su adaptabilidad y flexibilidad, para satisfacer las necesidades procedentes de los complejos y dinámicos entornos que puede representar un hospital.

Además como el funcionamiento de un hospital se puede dividir en pequeñas áreas de funcionalidad, cuyos requisitos son muy cambiantes, se pueden desarrollar bajo las metodologías ágiles.



Logistica de un Hospital como objeto de investigación.

Un hospital está dividida en areas funcionales semi-autónomas, donde los pacientes se clasifican de acuerdo a sus propias enfermedades. Estas áreas se organizan a su vez en departamentos pueden ser desplegados en varios departamentos.Sin embargo funcionalmente la explotación de salas y recursos es centralizada y, por tanto aparece la necesidad de una coordinación entre los departamentos médicos.

Esta coordinación pasa por varios niveles (medico-coordinador quirófano-enfermeras,etc) proceso que se lleva a cabo en muchos hospitales manualmente, es decir, sin soporte de TI.

Además, existe el problema de que la enfermedad del paciente es solo parcialmente conocido en el momento de su admisión. Por lo tanto, los procedimientos, como exámenes y los tratamientos no pueden ser predeterminados (fijos) por completo.

Con el fin de reaccionar con flexibilidad a las incertidumbres se ha pensado en los sistemas multiagente.
Actualmente existen sistemas de información hospitalaria pero no son capaces de solucionar los problemas de coordinación de recursos, cooperación en las investigaciones y en los diagnósticos; e información de pacientes, tratamientos, etc .



Objetivos y Proyectos participantes

El proyecto de Política de Agentes tiene por objetivo la solución al problema de la programación de los quirófanos. Usa un agente basado en algoritmos de planificación para automatizar al máximo esta tarea.
Estos agentes son autónomos y negocian en la búsqueda de horarios para tratar de llegar a una asignación eficiente de recursos muy por debajo de los costos de las transacciones habituales (certificados burocráticos, papeleo, etc).

El proyecto MedPAge se ocupa de la planificación, control y coordinación de los procesos clínicos. Elegir a un paciente es el objetivo del proyecto MedPage, donde se modelan los recursos hospitalarios y los pacientes como agentes de software autónomos.
Se basan en funciones de preferencia, y los agentes representan a pacientes que negocian autónomamente entre sí por los escasos recursos hospitalarios.

El enfoque del proyecto EMIKA se centra en el tiempo real de coordinación con el fin de integrar los casos de emergencia aguda en el calendario actual sin demora y el análisis de la precisión de estos en términos de tiempo.
Es una ejecución descentralizada con agentes que representan su entorno fisico para generar en cada momento un estado de la realidad de los dispositivos (quirófanos,etc). Además, decide de forma autónoma si el calendario actual se puede cumplir o son necesarios nuevos instrumentos de planificación. Utiliza retroalimentación permanente entre la realidad y el sistema de información a través de la comunicación entre agentes móviles sin un control central.

El proyecto ADAPT se centra en soluciones a los problemas descritos en los ensayos clínicos. El objetivo principal es la construcción de un agente basado en un sistema de simulación de la aplicación de los ensayos clínicos.

El proyecto ASAinlog aborda las cuestiones de información logística en relación con los registros de pacientes.(documentos médicos se representan como agentes y otro agentes serán los que los analicen).
El proyecto AGIL , es una parte que se basa en utilizar la herramienta basada en Java (AGILShell), y puede ser desplegado para el diseño y la aplicación de sistemas multiagente.

El enfoque perseguido tiene tres pasos:

(1) Análisis de los procesos a fin de determinar los escenarios de aplicación de los agentes.
(2) Cual es el modelo de dominio de los procesos expertos existentes.
(3) Optimización de los procesos a través de la integración de los agentes.


Teniendo en cuenta los procesos existentes en los proyectos descritos anteriormente se desarrolla un proceso "agentified" para la cooperación. En este proceso, los agentes llevan a cabo tareas que anteriormente eran realizadas por los humanos (medicos, especialistas, administrativos, etc.).

Por lo tanto, como expone el manifiesto ágil, se mejora la calidad del software, ya que el usuario y los expertos deben participar activamente para indicar claramente como cooperan las distintos proyectos.

Desarrollo de la ontología común OntHoS
OntHoS es la ontología para el dominio del hospital y fue desarrollada con la herramienta de ingeniería, Protégé. Para que, solo tengamos que definir la ontología y poder transformarla directamente en código Java.



Bases de XP para las pruebas Agent.Hospital
Como especifica la metodología agil XP se necesitan unidades de testeo para los modulos y ese es el Agent.Hospital. Es un agente de pruebas para el apoyo al desarrollo y a la evaluación del modelo y de la implementación.

Dado que la integración de modelos parciales multiagente y los cambiantes requisitos han sido una exigencia desde el principio, Agent.Hospital está diseñado para ser un marco abierto y sigue una metodología agil.




Agent.Hospital - Health Care Applications of Intelligent Agents
Multiagent Engineering. Springer Berlin Heidelberg. 2006.
http://www.winfobase.de/lehrstuhl/publikat.nsf/intern01/97BE669257D701E9C125720D003D31F2/$FILE/06-28.pdf

Agent Factory. Una herramienta para el desarrollo ágil de agentes.

Para cumplir los principios del manifiesto ágil una de las fases más importantes es la de producción de código, que en esta metodología se basa en una herramienta (Agent Factory) para la generación automática de las estructuras del agente.
Esta herramienta:

  • Analiza los diagramas de identificación de agentes y de la Ontología y genera un primer esqueleto de las clases del agente necesarias.
  • Permite introducir patrones en el proyecto para mejorar la funcionalidad.
  • Genera código para el sistema multiagente. Este código consiste en un esqueleto del agente y clases con sus tareas, que más tarde se completa con los patrones reutilizados. Algunos experimentos han demostrado un porcentaje de reutilización de código que es de aproximadamente 50-60%.

Otra parte importante son las pruebas ya que estas comprueban el cumplimiento de los requisitos. Estas pruebas deberían prepararse antes de la fase de codificación, de acuerdo con las especificaciones. El Agent Factory facilita el testeo de los agentes.

Agile Passi. Una metodología ágil orientada al uso de Agentes (II)

Vamos a continuar describiendo los procesos de Agile Passi. Tenemos:

  • Un modelo de requisitos con dos subfases (Planificación y Descripción de los subdominios de requisitos).
    Durante la primera fase el equipo de desarrollo decide qué actividades tienen que ser realizadas y el orden en que deben hacerse, el resultado es una división del problema en varios sub-problemas que sufren iteraciones de forma continua(de manera descrita en las metodologías ágiles)
  • Escenario de los agentes, un punto de vista de los agentes implicados en la solución, sus interacciones y sus conocimientos sobre el mundo. Se compone de dos etapas (Descripción de ontología de dominio y la identificación de agentes).
    La primera parte permite ver a un agente como un caso de uso o un conjunto de casos de uso y la en la segunda podemos ver las funcionalidades del sistema a partir de un diagrama detallado.
  • Código. Incluye dos definiciones: Plan de reutilización y Codificación. En la primera tratamos la reutilización de patrones y la obtención de piezas de código reutilizable que se documenta con una vista estructural y un comportamiento. Nos ayudamos con la herramienta Agent Factory. Se producen cuatro documentos:

1. COD – Clases que representan los agentes, sus comunicaciones y los parámetros relacionados con él (contenido del lenguaje, la interacción del agente, protocolo y ontología)

2. (M) ASD - Clases que representan un nivel de abstracción del sistema multiagente. Representa a cada agente con una clase y las tareas del agente como los métodos de la clase.

3. (M) ABD – Representa el diagrama de flujo de control y comunicación entre todos los agentes.

4. SASD - una clase para cada agente con el fin de representar a su estructura interna, y todas sus tareas de forma más detallada.
En la segunda parte se completa el código generado anteriormente

  • Las pruebas. En esta fase se representa lo que ocurre antes y después de la codificación (característica expuesta en el manifiesto ágil). La fase de prueba comienza antes de que se codifica, se preparan las pruebas para tener algún tipo de control sobre la codificación. Si alguna preuba falla, será necesaria una refactorización hasta que se cumplan todas las pruebas. Cuando se cumplen todas las pruebas tenemos un prototipo válido para mostrar al cliente.

Agile Passi. Una metodología ágil orientada al uso de Agentes.

Esta entrada esta dedicada a introducirnos en una metodología desarrollada en 2004 en Palermo, una descripción más detallada podemos encontrarla en el documento siguiente. Otro documento interesante podría ser este, donde nos explica como una metodología de agentes llamada Passi, fue reestructurada para convertirse en una metodología ágil.

Nosotros vamos a exponer un pequeño resumen para ver su funcionamiento básico.

Agile-Passi fue desarrollado a partir de la metodología Passi, que una vez experimentado con ella se comprobaba que no era demasiado flexible y rápida de desarrollar. Por ello surgió Agile-Passi, que pretendía disminuir el esfuerzo al desarrollar un sistema multiagente.


Podemos ver un gráfico de su estructura.



Se reutilizaron una serie de características de Passi:

  • La identificación de los agentes como un conjunto de funciones expresadas en forma de casos de uso.
  • El papel central de la descripción de la ontología en el análisis.

Además se tuvieron en cuenta estrategias del Manifiesto Ágil:

  • Los individuos y las interacciones sobre procesos y herramientas.
  • El software desarrollado sobre una completa documentación
  • La colaboración con el cliente

Las cinco actividades reutilizadas para generar la nueva metodología a partir de Passi fueron:

  • Descripción del dominio de requisitos(DRD)
  • Identificación de agentes (AID)
  • Descripción de la Ontología (DOD)
  • Reutilización de código (CR)
  • Pruebas

Para cumplir los principios del manifiesto ágil una de las fases más importantes es la de producción de código, que en esta metodología se basa en una herramienta (Agent Factory) para la generación automática de las estructuras del agente.

Otra parte importante son las pruebas ya que estas comprueban el cumplimiento de los requisitos. Estas pruebas deberían prepararse antes de la fase de codificación, de acuerdo con las especificaciones. El Agent Factory facilita el testeo de los agentes.

Continuamos más detalladamente en la siguiente entrada.

Metodologías de Agentes. Algunos conceptos.

En esta entrada vamos a ver una serie de metodologías para agentes que fueron expuestas en el foro “AOSE Technical Forum Group“ en Roma en el año 2004. Se expusieron las siguientes metodologías:

IDE-Eli

Conjuto de herramientas destinadas a apoyar la ingeniería de sistemas multiagente como instituciones electrónicas. El Software de agentes aparecen como la herramienta clave detrás de la tecnología electrónica instituciones visión.

INGENIAS

Esta metodología se basa en la definición de un conjunto de meta-modelos que describen los elementos que forman un MAS desde varios puntos de vista, y que permiten definir un lenguaje de especificación para el MAS. Los puntos de vista son cinco: el agente (definición, control y gestión del estado del agente), las interacciones, organización, escenario, objetivos y tareas.

META-DIMA
MetaDIMA se inspira en el Modelo-Driven Architecture (MDA), propuesto por OMG, que tiene por objeto la separación de la lógica de aplicación y de las tecnologías para mejorar la reutilización y el proceso de desarrollo.

Agile passi
En Agile passi, la exigencia principal es que los desarrolladores no se distraigan del objetivo principal (la producción de un sistema que resuelve algún tipo de problema algorítmico, por ejemplo en robótica), con un largo proceso de diseño. Esto podría lograrse mediante un proceso ágil que apoya fase de diseño al tiempo que alienta la reutilización de las contribuciones en forma de patrones.

RIO
El modelo RIO se centra en dos conceptos: los roles y la Organización.

Adelfe
Se basa en un proceso conocido, el RUP (Rational Unified Process), que se adapta para tener en cuenta las circunstancias particulares de los sistemas multiagente.

MASE
Mase divide el proceso de desarrollo en dos grandes fases: la fase de análisis y la fase de diseño, dividida cada una de ellas en una serie de subfases. El proceso de desarrollo en Mase es iterativo.


Nos vamos a centrar en Agile Passi, ya que nuestro objetivo es profundizar sobre las metodologías ágiles de agentes. Todo en la siguiente entrada.

Un caso llevado a la práctica

Estudiando el artículo aportado por Holger Knublauch llamado “Extreme Programming of MultiAgent Systems” que vamos consultando en este blog nos encontramos con un caso de programación extrema en un sistema multiagente, más en concreto en un proyecto de investigación alemán llamado . “Towards a Multi-Agent System for Pro-active Information Management in Anesthesia. In Proc. of the Agents-2000 Workshop on Autonomous Agents in Health Care” para optimizar la distribución de los datos clínicos de pacientes.


En un principio, el modelo fue construido por expertos del dominio clínico con la herramienta AGIL-Shell. La tarea siguiente era conseguir un modelo de proceso con un conjunto inicial de agentes y la comunicación de estos, para lo que los expertos y el desarrollador se reunieron durante tres días para definir los escenarios con AGIL-Shell.

Para la siguiente actividad lo que hicieron fue organizar un curso práctico para una serie de alumnos con un entrenador (el desarrollador del sistema) y una serie de expertos del dominio que aclaraban dudas y exponían necesidades del sistema a los alumnos. Ninguno de los alumnos tenían experiencia ni formación en XP ni en agentes, e incluso algunos se iniciaban en Java, por lo que también se proporciono un curso inicial de XP y de otras herramientas de desarrollo.

Experiencias sacadas de este proyecto fueron:

  • El trabajo se realizaba durante 40 horas a la semana, en un ambiente agradable que estimulaba la creatividad y la comunicación con actividades como por ejemplo una presentación entre los alumnos tomando un café.

  • Planificación. Al comienzo de cada día, el equipo conjuntamente seguía un enfoque de planificación para definir las características que deben llevarse a cabo.

  • Desarrolladores organizados de dos en dos, esto los hacía estar más motivados y concentrados y además de acelerar el ritmo de aprendizaje. Aunque no todas las parejas tuvieron experiencias positivas.

  • Pruebas. Durante el curso, los alumnos han aplicado las pruebas de 30 clases con 76 casos de prueba, por un total de 4909 líneas de código, mientras que el código de los 43 agentes ascienden a 5673 líneas (con exclusión de las clases ontología).

  • Derechos de propiedad colectiva. Esto permite a cualquier miembro del equipo modificar cualquier parte del código en cualquier momento. Apenas hubo solapamiento ya que cada pareja de desarrolladores programaban los paquetes de un solo agente. Sólo las clases de ontología se repartieron entre los agentes y, por tanto, fueron modificadas por diversos equipos. La coordinación de estos cambios se lograron de manera informal con una buena comunicación entre los desarrolladores.

  • Normas de codificación: definiendo una escala estándar de codificación.

  • Diseño simple: los estudiantes se centraron en la programación. El modelo inicial fue evolucionando ya que los mismos estudiantes identificaban funcionalidades útiles del sistema, pero el diseño global se mantuvo estable en general

  • Refactorización. Al ser pequeñas unidades de código en general fue muy fácil de mantener y refactorizar.

  • Integración continúa. Como mínimo, cada noche se integraba en el servidor CVS los agentes desarrollados Los agentes fueron subidos en el servidor CVS e integrado, como mínimo, cada noche. Los estudiantes solo podían subir al servidor agentes que habían superado todos los test de prueba, por lo que apenas hubo problemas de integración.

  • En el lugar del cliente. Los estudiantes valoraron positivamente la presencia de expertos en el dominio que les aportase conocimiento con regularidad por lo que se pudieron prevenir muchos errores.


    Al final, el proyecto dio lugar a 17 tipos de agentes que cubrían la tercera parte del modelo de proceso y resolvían tareas de notificación, filtrado o monitorización de pacientes.
    Otros 5 tipos de agente fueron identificados en la fase de codificación, en general, ofreciendo servicios a los agentes más generales.
    El agente de escenarios, sin embargo, sufrió cambios más significativos ya que incluye casi el doble de las actividades y los mensajes que el diseñado originalmente. Normalmente estas actividades se refieren a la transferencia de información entre los agentes ya que algunos de ellos no tienen acceso a recursos necesarios. Estas nuevas funcionalidades surgieron de la creatividad de los miembros del equipo durante la fase de ejecución.


Un enlace interesante: http://www.navegapolis.net/content/view/773/96


Muestra brevemente como trabajarían los desarrolladores siguiendo los principios de la metodología ágil XP. Son interesante, cortos y bastante claros.