Trabajo Final de carrera - Ingeniería de Sistemas
Un enfoque multi-agente para la
asistencia en la toma de decisiones
de diseño de Software
Alumnos
Matías Adrián Musante
Carlos Nicolás Otranto
Directores
Dr. J. Andrés Díaz-Pace
Dr. Ariel Monteserin
Marzo de 2016
Este trabajo está dedicado a nuestros familiares, amigos, y a
aquellas personas que de algún modo nos han apoyado y
alentado durante el transcurso de nuestras carreras.
Una mención especial a aquellos quienes partieron y aún siguen
motivándonos a seguir adelante y cumplir nuestras metas.
Índice general
1. Introducción 1
1.1. Objetivos . . . 2
1.2. Estructura del trabajo . . . 2
2. Marco teórico: Arquitecturas de software 5 2.1. Arquitectura de software . . . 5
2.2. Funcionalidad y arquitectura . . . 8
2.2.1. Atributos de calidad . . . 8
2.2.2. Puntos de Trade-off . . . 10
2.2.3. Escenarios de calidad . . . 11
2.3. Diseño de arquitecturas conducido por atributos de calidad . . . 15
2.3.1. Proceso de diseño según ADD . . . 15
2.4. Estilos arquitectónicos . . . 18
2.5. Tácticas y modelos . . . 19
2.5.1. Tácticas de modificabilidad . . . 21
2.5.2. Tácticas de performance . . . 24
2.6. Herramientas CASE . . . 25
2.7. Resumen . . . 27
3. Marco teórico: Agentes inteligentes 28 3.1. Agentes inteligentes . . . 28
3.2. Sistemas expertos y agentes de asistencia . . . 31
3.3. Negociación entre agentes inteligentes . . . 32
3.3.1. Enfoques de negociación . . . 34
3.3.2. Protocolo de concesión monótona . . . 36
3.4. Resumen . . . 41
Índice general
4.2. DesignBots . . . 46
4.3. SoftArch . . . 50
4.4. Enfoque basado en algoritmos genéticos . . . 52
4.5. Resumen . . . 56
5. Enfoque 57 5.1. Descripción general del sistema . . . 57
5.2. Elementos de la aplicación . . . 58
5.2.1. Escenarios de calidad . . . 59
5.2.2. Tácticas . . . 60
5.2.3. Design Bots . . . 61
5.2.4. Análisis de arquitectura . . . 62
5.3. Enfoque propuesto . . . 62
5.4. Mejoras desarrolladas . . . 63
5.4.1. Búsqueda de soluciones . . . 63
5.4.2. Algoritmo de negociación . . . 69
5.5. Características incorporadas . . . 70
5.5.1. Función de utilidad . . . 70
5.5.2. Estrategia de Zeuthen . . . 73
5.5.3. Umbral de utilidad . . . 74
5.6. Resumen . . . 75
6. Diseño e implementación 76 6.1. Descripción de la arquitectura de Architect . . . 76
6.1.1. Motor de Architect . . . 78
6.1.2. Búsqueda de soluciones . . . 80
6.2. Diseño de mejoras propuestas . . . 83
6.2.1. Estructura de soporte para evaluación multi-agente . . . 84
6.2.2. Búsqueda de soluciones . . . 85
6.2.3. Algoritmo de negociación . . . 88
6.3. Tecnologías utilizadas . . . 92
6.3.1. Spring MVC . . . 92
Índice general
7. Análisis de enfoques 97
7.1. Caso de estudio . . . 97
7.1.1. Actores de CTAS . . . 98
7.1.2. Características de CTAS . . . 98
7.2. Experimentos realizados . . . 104
7.2.1. Ejecución de pruebas experimentales . . . 105
7.2.2. Análisis de resultados obtenidos . . . 107
7.2.3. Discusión . . . 113
8. Conclusiones 117 8.1. Limitaciones . . . 118
8.2. Trabajos futuros . . . 119
A. Anexo I: Modelos de modificabilidad 121
B. Anexo II: Modelos de performance 123
C. Anexo III: Resultados de Experimentos 125
1. Introducción
La construcción de sistemas de software es una de las disciplinas más prolíficas de los últimos tiempos, debido a los constantes avances tecnológicos y una masiva tendencia hacia la automatización e informatización de tareas. En este contexto, y sobretodo en aquellos sistemas que presentan una complejidad considerable, o cuyo funcionamiento es crítico para el éxito de una actividad, resulta de gran importancia la toma correcta de decisiones de diseño por parte de los ingenieros a fines de obtener aplicaciones de calidad, que cumplan con los requerimientos establecidos, reduzcan costos por re-planificación y re-trabajo y, por ejemplo en sistemas de tiempo real, eviten resultados desastrosos.
Una situación típica se da cuando se debe elegir un patrón de arquitectura para sa-tisfacer un conjunto de requerimientos de atributos de calidad predefinidos, donde la evaluación de los patrones candidatos dependerá de varios factores tales como las prioridades de los atributos de calidad, los intereses de los stakeholders involucrados y el costo de la aplicación de los diferentes patrones. En este contexto, las herramientas de asistencia al desarrollo de software (herramientas CASE) adquieren gran relevan-cia, dado que facilitan el análisis de las diferentes alternativas de diseño contemplando todas las posibles variables influyentes [Díaz-Pace y Campo, 2008]. El enfoque Design-Bots, recientemente materializado por la aplicación Architect, es un ejemplo de este tipo de herramientas.
multi-1.1 Objetivos
lateral pueden ajustarse convenientemente a la problemática de evaluar una arqui-tectura considerando los tradeoffs existentes en la especificación de la misma.
1.1. Objetivos
El principal objetivo del presente trabajo es el desarrollo de una solución basada en un enfoque de negociación multi-agente que permita al usuario de la aplicación to-mar decisiones de arquitectura basadas en múltiples criterios de evaluación de manera conjunta, incluyendo dicha solución como una nueva característica en la herramienta Architect. La implementación de esta solución incluye el análisis y aplicación de diver-sas estrategias de negociación y concesión, basadas en la utilidad de cada alternativa de arquitectura. Esta utilidad dependerá principalmente del costo de aplicación de una determinada táctica y de la prioridad asignada al escenario de calidad asociado. Dichos aspectos pueden ser configurados en forma individual para cada agente, ajus-tando diversos parámetros (por ejemplo, prioridad de los escenarios, determinación de umbrales de utilidad, función matemática asociada - lineal, cuadrática, exponencial) de acuerdo a las preferencias del usuario de la herramienta y de la naturaleza de la arquitectura a evaluar.
Adicionalmente, se propone una modificación al algoritmo de búsqueda actual de Ar-chitect para intentar mejorar la calidad de las alternativas de análisis. Actualmente, el espacio de búsqueda de alternativas posibles de cada agente está limitado a la explo-ración de soluciones conformadas por tácticas propias (es decir, el árbol de búsqueda de un determinado agente se genera de acuerdo a las alternativas propuestas por dicho agente). La nueva implementación considera soluciones conjuntas, esto es, alternativas conformadas por la aplicación de tácticas de los distintos agentes que intervienen en el proceso de análisis. De este modo se intenta ampliar el espacio de búsqueda, contri-buyendo a optimizar el desempeño de este enfoque de evaluación multi-criterio y los beneficios que la misma ofrece.
1.2. Estructura del trabajo
1.2 Estructura del trabajo
En el capítulo 2 se presenta un marco teórico detallando los principales conceptos involucrados acerca de arquitecturas de software. En primer término se describe el concepto de arquitectura y su importancia sobre el diseño de sistemas. Luego se deta-llan aspectos y características inherentes a este tema, tales como atributos de calidad, escenarios, tácticas y modelos. Además se describe brevemente el proceso de diseño propuesto por el método ADD para definir y refinar una arquitectura en base a los principales requerimientos de un sistema.
El capítulo 3 se enfoca en la explicación de conceptos teóricos asociados a Agen-tes InteligenAgen-tes, haciendo énfasis principalmente en su utilización en la definición de protocolos de negociación para resolución de casos donde existe dependencia entre variables y puntos de conflicto.
Existen algunos antecedentes de utilización de herramientas de asistencia al usuario en la definición de arquitecturas, las cuales apuntan a la mejora de diversos aspectos de las mismas. En este trabajo, se mencionan principalmente tres casos (ArchE, DesignBots y SoftArch), los cuales son detallados en el capítulo 4. Asimismo, en dicho capítulo se hace una mención especial sobre un enfoque alternativo de evaluación basado en Algoritmos Genéticos.
En el capítulo 5 se exponen las principales características actuales de la herramien-ta Architect, identificando a su vez las limiherramien-taciones que motivan al desarrollo de la propuesta de este trabajo, y fundamentando las mejoras sugeridas e implementadas sobre el núcleo de análisis y evaluación de resultados de la aplicación. Esto considera fundamentalmente la inclusión del protocolo de negociación y la personalización del mismo mediante la utilización de parámetros de ajuste. Asimismo, se detallan las mo-dificaciones sobre el motor de búsqueda para incorporar una exploración de soluciones que combinan tácticas de los diferentes agentes.
El capítulo 6 constituye una explicación sobre el diseño detallado de la implementación realizada, identificando los puntos de vista más relevantes en la inclusión en Architect del enfoque de negociación, mejoras sobre algoritmos de búsqueda y parámetros de ajuste que permiten personalizar el proceso de análisis.
1.2 Estructura del trabajo
tradicional y las mejoras propuestas, teniendo en cuenta las variaciones realizadas sobre los distintos parámetros de ajuste.
2. Marco teórico: Arquitecturas de
software
Una arquitectura de software permite reflejar los principales aspectos funcionales y no funcionales (atributos de calidad) del diseño de un sistema. Dada la complejidad de la tarea, suele ser necesaria la aplicación de herramientas de asistencia, facilitando el proceso de diseño.
En el presente capítulo se tratarán diversos conceptos relacionados con arquitecturas de software, los cuales brindan un marco para facilitar el entendimiento y comprensión de las características de la herramienta tratada en este trabajo.
2.1. Arquitectura de software
Existen varias definiciones acerca de qué es una arquitectura de software. En términos generales, “la arquitectura de software es la estructura o estructuras de un sistema, que se compone de elementos de software, las propiedades externamente visibles de dichos elementos y las relaciones existentes entre ellos” [Bass et al., 2003].
De la definición anterior surgen algunas implicancias, las cuales se mencionan a con-tinuación.
La arquitectura es una abstracción del sistema que contiene información acerca de cómo los elementos que la componen interactúan unos con otros, omitiendo por otra parte datos que no se corresponden con esa interacción. En la práctica, los elementos de una arquitectura interactúan mediante interfaces; la información “privada” y detalles de implementación propios de cada elemento no es relevante para la descripción de una arquitectura.
2.1 Arquitectura de software
“externamente visibles” de los elementos que la componen pueden ser, por ejemplo, servicios provistos, características de performance, manejo de errores o utilización de recursos compartidos.
Una arquitectura puede involucrar varias y diferentes estructuras, cada una de las cuales aporta distinta información acerca del sistema.
Para facilitar el entendimiento acerca de los conceptos a tratar, durante el transcurso de este capítulo se presentarán situaciones sobre una arquitectura asociada a un sistema de administración de itinerarios para viajeros. En principio este sistema está compuesto por tres módulos que representan la interfaz de entrada e interacción con el usuario, presentación de resultados y lógica y modelo de datos. El sistema permite, entre otras cosas, cargar y consultar itinerarios de viajes, crear perfiles de usuarios y consultar servicios acerca de rutas y puntos de interés. La figura 2.1muestra distintos puntos de vista de la arquitectura presentada.
Figura 2.1.: Vista de módulos y responsabilidades de un sistema de administración de itinerarios
Se asume que todo sistema de software posee una arquitectura, ya que cualquier sis-tema puede ser descrito en términos de conjuntos de elementos y sus relaciones. El comportamiento de cada elemento del sistema forma parte de la arquitectura, siem-pre que pueda ser observado desde el punto de vista de otro elemento. De aquí se desprende la siguiente afirmación: “una arquitectura NO es simplemente un diagrama conceptual de flechas y cajas”. Esto se debe a que cada diagrama representa un punto de vista diferente de la arquitectura, exponiendo ciertas características del sistema y ocultando otras.
2.1 Arquitectura de software
mala para un determinado sistema. Esto depende de la naturaleza del problema y los requerimientos presentados. De aquí radica la importancia del diseño y evaluación de arquitecturas.
Una arquitectura es el resultado de un conjunto de decisiones técnicas y del negocio. En su diseño hay diversas influencias que varían dependiendo del contexto y la naturaleza para los cuales el sistema es requerido. Algunas características del sistema a diseñar se hacen visibles a través de los requerimientos funcionales, pero esto sólo constituye una parte de la arquitectura. Existen otras propiedades del sistema requeridas por el negocio que pocas veces son explicitadas de manera consciente.
Entre los factores que influencian una arquitectura, se destacan los siguientes:
Stakeholders: las personas interesadas en la construcción de un sistema de soft-ware poseen diferentes objetivos y opiniones acerca de las características que el sistema debe optimizar y/o garantizar, los cuales pueden ser contradictorios. Organización que desarrolla el sistema: la estructura y naturaleza de los recursos de la organización, las inversiones en activos y estrategias de desarrollo a corto plazo, o bien los objetivos estratégicos de la misma.
Ambiente técnico: esto incluye tecnologías, prácticas y estándares adoptados en la industria del software.
Experiencia del arquitecto: el arquitecto se basa en resultados anteriores (tanto buenos como malos), y en su entrenamiento para poder tomar decisiones sobre la arquitectura.
2.2 Funcionalidad y arquitectura
2.2. Funcionalidad y arquitectura
Si la funcionalidad fuera el único requerimiento para la construcción de un sistema, el mismo estaría formado por un único módulo sin ninguna otra estructura interna; esto indica que los requerimientos funcionales son independientes de la estructura del sistema. Por el contrario, un sistema se descompone en módulos para facilitar su entendimiento, y para poder soportar otro tipo de requerimientos no funcionales. De este modo, una arquitectura posee una estructura determinada de acuerdo con los requerimientos de atributos de calidad más prioritarios.
2.2.1. Atributos de calidad
Se puede pensar en atributos de calidad como propiedades de un sistema que son orto-gonales a los requerimientos funcionales. Mientras que la funcionalidad se corresponde con la facultad que posee un sistema para realizar el trabajo requerido, un atributo de calidad define ciertas restricciones sobre la realización de dicha funcionalidad, tales como performance o seguridad, entre otros.
Si bien la arquitectura del sistema por sí sola no garantiza el cumplimiento de los atributos de calidad deseados, ya que los detalles de implementación también tienen influencia sobre los mismos, la correcta elección de su estructura es crítica para poder alcanzarlos. Por este motivo, los requerimientos no funcionales deben ser contemplados y evaluados a nivel arquitectónico.
A continuación, se describen brevemente los principales atributos de calidad de un sistema:
2.2.1.1. Disponibilidad
2.2 Funcionalidad y arquitectura
2.2.1.2. Modificabilidad
La modificabilidad se relaciona con el costo de cambio. Esto involucra dos aspectos: el primero se corresponde con qué artefacto del sistema puede llegar a cambiar. El segundo es determinar cuándo se realizará un cambio y quién lo realiza. Un cambio puede ocurrir sobre cualquier elemento del sistema, tales como tecnología utilizada para su construcción, o una funcionalidad del mismo [Bass et al., 2003]. Una vez que se ha especificado el cambio, la nueva implementación debe ser diseñada, implementada, testeada y deployada. Todas esas acciones cuestan tiempo y dinero.
La modificabilidad está estrechamente ligada a aspectos de mantenibilidad de un sis-tema, tal como se indica en la tabla 2.1 [Wiegers y Beatty, 2013]:
Tipo de mantenimiento Dimensión Descripción
Correctivo Mantenibilidad,
entendimiento
Corrección de defectos
Perfectivo Flexibilidad,
extensibilidad, escalabilidad
Mejora y modificación de funcionalidades para
satisfacer nuevas necesidades y requerimientos
Adaptativo Mantenibilidad Modificación del sistema para
funcionar en un ambiente de operación diferente, sin agregar nuevas
funcionalidades
Soporte Soporte Corrección de fallas, o
mantenimiento/reparación de dispositivos.
Tabla 2.1.: Dimensiones de modificabilidad por tipo de mantenimiento
2.2.1.3. Performance
La performance se basa en el cumplimiento de una función de acuerdo a restricciones de velocidad y tiempo.
Un sistema debe responder a ciertos eventos tales como interrupciones, mensajes, peticiones de usuarios, entre otros. La performance indica cuánto tiempo toma al sistema responder a dichos eventos.
2.2 Funcionalidad y arquitectura
que arriba un evento hasta que se produce una respuesta; mientras que el throughput expresa la razón de respuestas generadas por el sistema sobre un intervalo de tiempo [Lazowska et al., 1984].
2.2.1.4. Seguridad
Existen dos aspectos relacionados con la palabra seguridad: ambos definen a esta característica como la capacidad del sistema para evitar posibles fallas que produzcan daños en parte o la totalidad del mismo. En el primer caso, una falla ocasiona un daño inmediato e involuntario (safety); mientras que en el segundo, una falla aumenta las probabilidades de que un agente externo produzca daños de manera voluntaria sobre el sistema (security) [Burns et al., 1992].
2.2.1.5. Testeabilidad
Al menos el 40 % del costo de desarrollo de sistemas se corresponde con la fase de testing. La testeabilidad de un sistema se manifiesta como la facilidad con la cual se pueden demostrar sus fallas a través de la realización de pruebas. Generalmente se puede expresar como la probabilidad (asumiendo que el sistema posee al menos una falla) de que ocurra un fallo en la próxima ejecución de un caso de test.
Para que un sistema sea testeable es necesario que tanto el estado interno de todos los componentes como así también sus inputs puedan ser controlados, como así también debe poder observarse cada uno de los outputs.
2.2.1.6. Usabilidad
Este atributo de calidad está relacionado con las facilidades que el sistema provee al usuario para realizar una determinada tarea. Algunos temas relacionados con la usabilidad son la facilidad de uso, familiarización con las funcionalidades del sistema, adaptabilidad a las necesidades del usuario, minimización del impacto de errores de usuario, etc.
2.2.2. Puntos de Trade-off
general-2.2 Funcionalidad y arquitectura
mente tiene efectos (en ocasiones positivos, y en otras ocasiones negativos) sobre otros atributos de calidad, lo que se conoce como punto de trade-off.
Por ejemplo, la performance y la modificabilidad podrían considerarse como atribu-tos de calidad antagónicos con respecto al concepto anterior. La modificabilidad está generalmente dada por una clara separación de responsabilidades y modularización; y conforme aumenta la cantidad de intermediarios e invocaciones entre estos, la veloci-dad de procesamiento suele reducirse, lo que afecta negativamente a la performance de un sistema. En consecuencia, en un sistema que tiene requerimientos sobre ambos atributos de calidad se dice que existe untrade-off entre modificabilidad y performan-ce.
Dado lo anterior, los requerimientos de atributos de calidad de un sistema deben ser evaluados en un conjunto analizando los posibles puntos de trade-off existentes entre estos, permitiendo modelar la arquitectura estableciendo un balance entre el grado de cumplimiento de los principales atributos de calidad identificados por los stakeholders. La matriz de latabla 2.2muestra distintospuntos de trade-off (generales) identificados entre pares de atributos de calidad. El signo+indica que el efecto de una característica
sobre otra es positivo. Por el contrario, el signo- establece que el cumplimiento de un
atributo de calidad impacta negativamente sobre otro [Wiegers y Beatty, 2013].
2.2.3. Escenarios de calidad
En el estudio y definición de un atributo de calidad se identifican tres problemas que afectan al entendimiento de los mismos:
La aplicación directa de la definición de un atributo de calidad sobre un sistema carece de sentido y podría presentar ambigüedades (¿Qué significa que un siste-ma sea modificable o perforsiste-mante?). Todo sistesiste-ma cumple generalmente con un determinado atributo de calidad para cierto conjunto de elementos y para otros no.
En ocasiones resulta difícil asociar un aspecto del sistema con un atributo de calidad en particular (¿Qué tipo de atributo de calidad se corresponde con una “falla del sistema”? Podría ser un aspecto de disponibilidad, o de seguridad por ejemplo).
2.2 Funcionalidad y arquitectura
Disp
onibilidad
Eficiencia Flexibilidad Integridad Interop
erabilidad
Man
tenibilidad
P
ortabilidad
Confiabilidad Reusabilidad Robustez Testeabilidad Usabilidad
Disponibilidad + +
Eficiencia - - -
-Flexibilidad - - + + + +
Integridad - - - -
-Interoperabilidad - + - +
Mantenibilidad + - + + +
Portabilidad - + + - + +
-Confiabilidad + - + + + + +
Reusabilidad - + - - +
Robustez + - + +
Testeabilidad + - + + + +
Usabilidad - +
-Tabla 2.2.: Trade off entre atributos de calidad
Para solucionar los inconvenientes anteriores, los requerimientos de atributos de cali-dad de un sistema son modelados a través de escenarios de calidad.
Un escenario de calidad consta de seis partes:
Fuente del estímulo: puede ser una persona, un sistema de cómputo u otro actor. Estímulo: es una condición que debe ser considerada cuando se produce en el sistema.
Ambiente: se refiere a las condiciones en las que ocurre el estímulo.
Artefacto: identifica a la parte o partes del sistema que son afectadas por el estímulo.
Respuesta: indica qué actividad se debe realizar luego de la llegada del estímulo. Medida de respuesta: la respuesta dada tiene que poder ser analizada mediante alguna métrica para determinar si el requerimiento se satisface o no.
2.2 Funcionalidad y arquitectura
2.2.3.1. Escenarios de modificabilidad
Parte del escenario Posibles valores
Fuente Responsable de realizar los cambios: desarrollador, administrador del sistema o bien un usuario final.
Estímulo Alta, baja o modificación de una funcionalidad o característica del sistema.
Artefacto Cualquier elemento del sistema que interactúe directamente con la fuente: interfaz de usuario, configuración del sistema, etc.
Ambiente Tiempo de diseño, desarrollo, compilación o ejecución.
Respuesta Modificación de una parte del sistema sin afectar al resto de sus funciones.
Medida de respuesta Costo en términos de número de elementos afectados, esfuerzo, dinero o tiempo que demanda la modificación, etc.
Tabla 2.3.: Partes de escenario de calidad de modificabilidad
Una instancia concreta de un escenario de modificabilidad sobre el caso de ejemplo puede ser (figura 2.2):
“Un desarrollador experimentado debe agregar una nueva variable al modelo de perfiles de usuario. Este cambio será realizado en un plazo de 5 días de esfuerzo”.
2.2 Funcionalidad y arquitectura
2.2.3.2. Escenarios de performance
Parte del escenario Posibles valores
Fuente Una de un conjunto de fuentes independientes, posiblemente interna al sistema.
Estímulo Eventos de entrada con un patrón de frecuencia periódico, esporádico o estocástico.
Artefacto Servicios provistos por el sistema.
Ambiente Estado del sistema al momento de la llegada de eventos: operación normal, sobrecarga, etc.
Respuesta Procesamiento de los eventos. Esto podría ocasionar un cambio en el modo de funcionamiento del sistema.
Medida de respuesta Varios tipos de aspectos: latencia (tiempo que demora el procesamiento de eventos), throughput (número de eventos procesados en un intervalo de tiempo), jitter (variación del tiempo de respuesta), etc.
Tabla 2.4.: Partes de escenario de calidad de performance
Un ejemplo de un escenario concreto de performance puede ser (figura 2.3):
“Un usuario consulta un itinerario bajo condiciones normales. El itinerario es mostrado en menos de 5 segundos”.
2.3 Diseño de arquitecturas conducido por atributos de calidad
2.3. Diseño de arquitecturas conducido por atributos
de calidad
El método ADD (Attribute-Driven Design) [Wojcik et al., 2006] es un enfoque uti-lizado para definir una arquitectura de software en el cual el proceso de diseño está guiado por requerimientos sobre atributos de calidad. ADD sigue un proceso de diseño recursivo que descompone elementos del sistema mediante la aplicación de transfor-maciones (tácticas y patrones arquitectónicos) que intentan satisfacer los principales requerimientos.
El modelo de ADD sigue un ciclo de “plan, do, check”. Esto significa que, primero se consideran los requerimientos y restricciones sobre la arquitectura para determinar qué tipo de elementos serán transformados; luego estos elementos son instanciados para satisfacer los requerimientos funcionales y no funcionales; finalmente, la resultante es analizada para determinar si los requerimientos fueron tratados. Este proceso es repetido en forma iterativa hasta que todos los requerimientos significantes hayan sido alcanzados.
2.3.1. Proceso de diseño según ADD
La figura 2.4 muestra una vista general del proceso de diseño establecido por ADD.
2.3.1.1. Entradas y salidas de ADD
Los elementos de entrada necesarios para la ejecución del proceso de ADD están con-formados por requerimientos funcionales, restricciones de diseño y requerimientos so-bre atributos de calidad que los stakeholders del sistema priorizan de acuerdo a sus intereses y objetivos.
2.3 Diseño de arquitecturas conducido por atributos de calidad
Figura 2.4.: Proceso de diseño según ADD
Paso 1: Confirmar si hay suficiente información sobre los requerimientos
El arquitecto deberá asegurarse de que los stakeholders han priorizado los requerimien-tos de acuerdo a sus objetivos, confirmando además que existe suficiente información acerca de los requerimientos de calidad para poder proceder con el diseño.
2.3 Diseño de arquitecturas conducido por atributos de calidad
Paso 2: Seleccionar un elemento del sistema a descomponer
Conforme al avance del proceso, el sistema será refinado y descompuesto en más ele-mentos, cada uno asociado a un conjunto de requerimientos. Se deberá seleccionar uno de ellos y hacer foco en este elemento durante los pasos sub-secuentes.
La elección de un elemento del sistema para refinar está basada sobre cierta informa-ción acerca del contexto dado, por ejemplo conocimiento sobre la arquitectura actual, riesgo y dificultad para satisfacer los requerimientos asociados, o su impacto sobre la utilización de recursos.
Paso 3: Identificar “architectural drivers” candidatos
Dados los requerimientos priorizados en el primer paso, se realizará una segunda pon-deración de los mismos en base a su impacto sobre la arquitectura, la cual ayudará a ordenar y priorizar en forma más detallada el conjunto de requerimientos. Una vez realizada esta actividad, se escogen los 5 o 6 requerimientos con prioridad más alta para continuar con el proceso de diseño. Estos son llamados “architectural drivers” y serán los que condicionen el diseño del sistema.
Paso 4: Elegir una transformación que satisfaga los architectural drivers
De acuerdo a los architectural drivers candidatos se puede determinar el tipo de trans-formaciones asociadas a aplicar sobre la arquitectura para intentar cumplir con los requerimientos dados.
De esta forma, se deberá realizar un análisis sobre los patterns y tácticas que conciernen a los requerimientos de calidad seleccionados en el paso anterior, analizando pros y contras de la aplicación de cada uno de ellos sobre la arquitectura actual.
Paso 5: Instanciar elementos y asignar responsabilidades
2.4 Estilos arquitectónicos
Estas definiciones serán documentadas utilizando diversas vistas del sistema, por ejem-plo una vista de módulos que muestre las propiedades estructurales del sistema, una vista de componentes y conectores que demuestre el comportamiento de sus elementos, o una vista de asignación que permita reflejar cómo los distintos elementos de software serán asignados a recursos de hardware.
Paso 6: Definir interfaces para los elementos instanciados
Las interfaces definen los servicios y propiedades requeridas y provistas por cada uno de los elementos del diseño. Para definir estas interfaces, será necesario considerar las necesidades de información de acuerdo a los requerimientos funcionales incluidos en los elementos instanciados en el punto anterior.
Paso 7: Verificar y refinar requerimientos
En este paso se debe verificar que todos los requerimientos y restricciones considera-dos en una iteración han sido correctamente trataconsidera-dos y asociaconsidera-dos según el elemento padre a uno o más elementos surgidos durante el refinamiento. Además, se deben re-finar también los requerimientos de calidad seleccionados tanto como sea necesario, y se traducen las responsabilidades asignadas en requerimientos funcionales para los elementos asociados. De modo que este paso sirve como preparación de la arquitectura resultante junto con sus elementos identificados para una nueva iteración.
2.4. Estilos arquitectónicos
2.5 Tácticas y modelos
mediante terminología específica contribuye a mejorar la comunicación y facilitar el entendimiento entre los stakeholders.
Los estilos arquitectónicos se definen a partir de su observación en forma repetida en varios sistemas de software. En los años 90, diversos autores contribuyeron a conformar un catálogo con los principales patrones identificados. Algunos de ellos se mencionan en [Garlan y Shaw, 1993].
La figura 2.5 muestra a clasificación de algunos estilos arquitectónicos organizados de acuerdo a su naturaleza.
El caso de ejemplo que guía el presente capítulo se basa en el patrón model-view-controller (MVC). Este patrón divide el sistema en tres componentes principales: el modelo contiene la funcionalidad y datos básicos de la aplicación, las vistas muestran la información al usuario, y los controladores manejan los eventos de usuario. Las vistas y controladores pueden verse como la interfaz de usuario. En consecuencia, el mecanismo de propagación de cambios asegura consistencia entre la interfaz de usuario y el modelo de la aplicación mediante la reducción de acoplamiento entre ambos, y favoreciendo así la modificabilidad del sistema.
La figura 2.6 muestra la estructura modular del patrón MVC.
2.5. Tácticas y modelos
Se considera una táctica como una transformación posible que afecta al comporta-miento/estructura de un diseño con respecto a un atributo de calidad en particular [Bachmann et al., 2007].
Una táctica permite satisfacer la medida de respuesta de un determinado escenario de calidad mediante la manipulación de algún aspecto del modelo asociado al diseño (ver anexos I y II), a través de decisiones de diseño arquitectónicas [Bachmann et al., 2003a]. Esta definición implica los siguientes puntos:
Una táctica arquitectónica aplica el conocimiento de diversos conceptos teóricos (tales como, teoría de scheduling, teoría de colas, etc) para la creación de modelos que satisfagan un atributo de calidad en particular.
2.5 Tácticas y modelos
Figura 2.5.: Taxonomía de estilos arquitectónicos
2.5 Tácticas y modelos
escenario (entrada, variables independientes y propiedades de sus elementos) pueden ser controlados a través de decisiones arquitectónicas para alcanzar la medida de respuesta deseada. Esto significa que una táctica representa un mode-lo que relaciona un conjunto de decisiones arquitectónicas y ciertos parámetros de calidad.
Cada táctica es una opción de diseño para el arquitecto y presenta diversas caracterís-ticas. Por ejemplo, una táctica permite introducir un intermediario en el diseño para mejorar la modificabilidad, pero no es la única táctica que satisface este requerimiento de calidad. Además, el uso de intermediarios requiere además localizar el cambio para asegurar que el costo de acoplamiento no se vea comprometido.
Los estilos arquitectónicos pueden ser definidos mediante el agrupamiento de un con-juntos tácticas. Por ejemplo, un estilo que soporta modificabilidad probablemente utilice tácticas para reducir el costo de acoplamiento.
A continuación, se explican algunas de las principales tácticas de modificabilidad y performance tratadas durante la implementación asociada a este trabajo.
2.5.1. Tácticas de modificabilidad
Las tácticas de modificabilidad apuntan, de acuerdo a su naturaleza, a reducir el aco-plamiento entre módulos, aumentar la cohesión, o bien a modificar los costos directos asociados a una determinada responsabilidad.
Se pueden identificar tres grandes grupos en la clasificación de tácticas de modificabi-lidad:
Localización de cambios: las responsabilidades asignadas a cada uno de módulos influencian en gran medida el costo de modificación. Dependiendo de cómo es realizada su asignación, un cambio específico puede afectar a un solo módulo o a varios. El objetivo de este conjunto de tácticas es reducir la cantidad de módulos afectados tanto como sea posible durante un cambio, mediante la localización de asignación de responsabilidades.
2.5 Tácticas y modelos
Diferir el tiempo de binding: este conjunto de tácticas apunta a reducir los costos de deploy de la aplicación, y a permitir la realización de cambios en el sistema a cargo de usuarios (no desarrolladores).
Lafigura 2.7muestra un cuadro de resumen con la clasificación de tácticas identificadas por [Bass et al., 2003].
Figura 2.7.: Tácticas de modificabilidad
Algunas tácticas de modificabilidad utilizadas en la herramienta son:
2.5 Tácticas y modelos
Figura 2.8.: División de responsabilidades
Abstraer responsabilidades comunes: en este caso, considerar los servicios A’ y B’, las cuales proveen de características similares a A” y B” para cumplir con las responsabilidades A y B respectivamente. En consecuencia, tanto A’ y B’ podrían ser implementados en forma conjunta de un modo más genérico. Luego, cada modificación al servicio sería realizada una sola vez y sobre esta nueva responsabilidad, reduciendo el costo de modificabilidad directo asociado al caso inicial.
Figura 2.9.: Abstraer responsabilidades comunes
2.5 Tácticas y modelos
Figura 2.10.: Insertar responsabilidad intermediaria
2.5.2. Tácticas de performance
El objetivo de las tácticas de performance es controlar/reducir el tiempo que demora generar una respuesta a determinados eventos que arriban al sistema (latencia). La latencia generalmente es afectada por el nivel y la naturaleza de la demanda de recursos. Esto incluye la tasa de arribo de eventos, tiempo de ejecución de tareas en respuesta a dichos eventos, y la variación del nivel de cada uno. La latencia es además afectada por forma de asignar recursos a cada tarea. La incapacidad para utilizar un recurso, ya sea debido a que otro proceso lo está ocupando, o debido a alguna falla, también afecta a esta métrica [Bachmann et al., 2003a].
Las tácticas de performance pueden ser divididas en tres grandes grupos:
Administración de demandas: controlan tiempos de ejecución y transferencia administrando la demanda de recursos.
Mediación entre demandas conflictivas: estas tácticas controlan la apropiación de recursos y tiempos de espera para tareas que compiten por recursos, de acuerdo a su prioridad, deadline, etc.
2.6 Herramientas CASE
Lafigura 2.11resume las principales tácticas de performance identificadas por [Bass et al., 2003].
Figura 2.11.: Tácticas de performance
Una posible táctica a aplicar para mejorar la performance de un sistema (utilizada en la herramienta Architect) se basa en el aumento del período de evaluación de uno de los escenarios de performance. Dado que el periodo es una métrica inversa de la tasa de eventos, esta táctica basada en RMA (Rate Monotonic Analysis) contribuirá a mejorar los costos asociados a la performance del sistema, identificando aquellos escenarios con alta latencia y reduciendo su tasa de ocurrencia, mejorando así la asignación de recursos [Champagne y Gagné, 2011].
2.6. Herramientas CASE
Conforme al crecimiento de la disciplina de diseño de sistemas, surge la necesidad de utilizar herramientas que brinden asistencia en ciertos aspectos de esta tarea, con el objetivo de hacer más rápida y eficiente la construcción de arquitecturas de sistemas cada vez más complejos y que demandan alta calidad.
2.6 Herramientas CASE
requerimientos, análisis, diseño, implementación, testing). En este contexto, se pue-den clasificar las herramientas CASE en tres divisiones:
Upper CASE: se refiere a herramientas que brindan soporte en etapas tempranas del desarrollo de sistemas (análisis y diseño).
Lower CASE: las herramientas de esta clasificación se enfocan en la implemen-tación del sistema, testing y mantenimiento.
I-CASE (Integrated CASE): soportan todas las fases del desarrollo de sistemas.
Figura 2.12.: Clasificación de herramientas CASE según su enfoque en etapas de desarrollo
Las herramientas CASE que brindan asistencia en el proceso de diseño de sistemas, proveen un conjunto de diagramas y componentes que permiten documentar los di-versos puntos de vista de una arquitectura. A continuación, se enumeran algunas características que puede proveer este tipo de aplicaciones:
Soporte para uso de diagramas UML (casos de uso, clases, C&C, deployment, secuencia, etc).
Verificación/Corrección de sintaxis en la documentación. Glosario de patrones arquitectónicos y templates.
Exportación de documentación a diversos formatos.
2.7 Resumen
2.7. Resumen
Una arquitectura es una abstracción del sistema que contiene información acerca de cómo los elementos que la componen interactúan unos con otros.
El diseño de la arquitectura de un sistema intenta reflejar la estructura y comporta-miento del mismo, considerando las funcionalidades requeridas y contemplando prin-cipalmente los escenarios de calidad asociados y restricciones dadas. Debido a que los distintos requerimientos de atributos de calidad por definición resultan conflictivos (trade-off), es necesario que el diseño pondere estos requerimientos y los evalúe en con-junto, intentando establecer un punto de balance en el cumplimiento de los mismos. Precisamente, el método ADD desarrolla un proceso de diseño iterativo conducido por atributos de calidad dados en forma de escenarios que conforman los requerimientos iniciales del sistema, priorizando en cada iteración los requerimientos más importan-tes. Cada escenario del sistema está asociado a un atributo de calidad y define, entre otras cosas, un valor esperado o medida de respuesta del mismo.
Las tácticas son transformaciones sobre el diseño que influencian el control de la medi-da respuesta de alguno de los atributos de calimedi-dad del sistema, intentando satisfacer los escenarios de calidad establecidos. Estas tácticas están basadas en modelos teóricos, y se organizan en jerarquías de acuerdo a su naturaleza.
3. Marco teórico: Agentes inteligentes
La inteligencia artificial ha surgido como una disciplina orientada a la búsqueda de nuevas técnicas que permitan resolver problemáticas complejas sobre diversos ámbitos, mediante la construcción de entidades “racionales” que brindan ayuda y/o buscan soluciones de manera inteligente.
En este capítulo se tratarán los principales conceptos necesarios para entender qué es un agente inteligente y cómo se puede incluir en la construcción de herramientas de asistencia. Posteriormente, se explicará detalladamente acerca de la negociación multi-agente para la resolución de casos donde existe dependencia de variables y puntos de conflicto.
3.1. Agentes inteligentes
En términos generales, un agente es cualquier cosa que pueda percibir su entorno a
tra-vés de “sensores” y actuar sobre dicho entorno mediante “impulsores” [Russell y Norvig, 1995]. Lafigura 3.1ilustra los componentes principales y comportamiento del contexto de un
agente inteligente.
Tal vez, la forma más común de referirse a un agente inteligente es como un sistema de software o hardware que posee las siguientes facultades [Wooldridge y Jennings, 1995]: Autonomía: un agente opera sin la intervención del usuario ni de otros agentes, y poseen cierto control sobre sus acciones y estado interno.
3.1 Agentes inteligentes
Figura 3.1.: Esquema general de comportamiento de un agente inteligente
Comportamiento pro-activo: un agente no responde solamente a los cambios en su entorno; además posee la capacidad de actuar de acuerdo a un objetivo, tomando la iniciativa.
Algunos ejemplos de agentes se describen brevemente en la tabla 3.1, en conjunto con algunas características tales como ambiente, elementos de entrada (sensores) y salida (efectores) y tipo de respuesta.
La elección de una determinada acción a desarrollar por el agente en cualquier instante dependerá de la entrada percibida. Este comportamiento es modelado a través de una función, y la complejidad de la misma dependerá del dominio de aplicación, el ambiente y de las características del agente.
A modo de ejemplo, la función que determinará el comportamiento un sistema de calefacción se podría basar únicamente en la medición de la temperatura para encender o no la calefacción; mientras que un agente que juega al ajedrez requiere una función que contemple las aproximadamente 90040 variantes posibles del juego, además de
situaciones especiales de acuerdo con las reglas del mismo.
3.1 Agentes inteligentes
Tipo de agente Respuesta esperada
Ambiente Efectores Sensores
Sistema de diagnóstico
médico
Paciente saludable,
costos reducidos
Paciente, hospital,
staff
Display de preguntas,
tests, diagnósticos,
tratamientos, derivaciones
Ingreso de sintomas
por teclado,
búsquedas, respuestas de pacientes
Sistema de análisis satelital de imágenes
Clasificación correcta de imagen
Imagenes recibidas del satélite
Display de categorización
Arrays de colores de pixeles
Robot clasificador porcentaje de partes
en recipientes
correctos
cinta transportadora
con elementos,
recipientes
brazo y mano robótica Camara, sensores
angulares
Controlador de
refineria
Pureza, seguridad,
rendimiento
Refineria, operadores Válvulas, bombas,
tableros
Temperatura, presión,
sensores químicos
Tutor de inglés
interactivo
Calificación de
estudiante en un test
Conjunto de
estudiantes, agencia de tests
Display de ejercicios,
sugerencias, correcciones
Teclado de entrada
Tabla 3.1.: Ejemplos de agentes y características asociadas
implementación de su función asociada, se pueden identificar los siguientes tipos [Russell y Norvig, 1995]:
Accesible/Inaccesible: Un ambiente es accesible para un agente si sus “sensores” detectan todos los aspectos relevantes del mismo para poder seleccionar una acción a realizar.
3.2 Sistemas expertos y agentes de asistencia
de automóviles es continuo, dado que por ejemplo la velocidad y localización variarán en un intervalo de valores continuos.
“Episódico”/No “episódico”: En un ambiente “episódico” la experiencia del agen-te se divide en episodios/etapas, que consisagen-ten en percibir una entrada y luego actuar. La calidad de la acción tomada por una agente depende solamente de la etapa actual, debido a que las etapas son independientes y, por lo tanto, el resto de los episodios no depende de las acciones tomadas anteriormente. Los ambien-tes de este tipo son más simples debido a que el agente no necesita procesar información del estado anterior para determinar una acción.
3.2. Sistemas expertos y agentes de asistencia
Los sistemas expertos constituyen una de las más importantes aplicaciones de la Inteli-gencia Artificial desde los 80s. Un sistema experto es uno capaz de resolver problemas o asistir y recomendar acerca de una problemática determinada [Wooldridge y Jennings, 1995]. Este tipo de sistemas ha sido ampliamente adoptado para resolver problemas en di-versos campos.
Un ejemplo de este tipo de aplicaciones está constituido por MYCIN, un sistema desa-rrollado a fines de los 70s que intenta asistir a investigadores sobre el diagnóstico de enfermedades producidas por infecciones en sangre. Esta aplicación trabajaba median-te un proceso de inmedian-teracción con un usuario, recopilando una demedian-terminada cantidad de hechos sobre el entorno, los cuales eran procesados por el sistema para obtener una conclusión. En este punto se distingue una diferencia entre agentes y sistemas exper-tos, y es que estos últimos no interactúan directamente con el ambiente, sino a través de un usuario que actúa como mediador. No obstante, las características principales de ambos son prácticamente las mismas.
3.3 Negociación entre agentes inteligentes
Figura 3.2.: Esquema general de un sistema experto
Entre las numerosas aplicaciones de los sistemas expertos se pueden mencionar algunos ejemplos:
Aplicaciones para juegos de estrategia como el ajedrez: En 1997 la supercompu-tadora Deep Blue, desarrollada por IBM, venció al chessmaster Garry Kasparov en una partida sobre seis juegos (2 victorias para deep blue, una para el campeón y 3 empates).
Predicciones financieras: estas aplicaciones permiten realizar anticipaciones sobre el estado y tendencia de los mercados bursátiles.
Diagnósticos médicos: El anteriormente nombrado sistema MYCIN constituye un ejemplo de este tipo de aplicaciones destinadas a asistir en el campo de la medicina.
Monitoreo y control sobre sistemas de tiempo real: por ejemplo sistemas de piloto automático de aviones o dirección asistida en automóviles.
3.3. Negociación entre agentes inteligentes
3.3 Negociación entre agentes inteligentes
Puntualmente, en el campo de la Ingeniería de Software la negociación es una herra-mienta de interacción esencial en sistemas expertos compuestos por múltiples agentes, donde es necesario alcanzar acuerdos sobre un conjunto de alternativas y soluciones, y donde tales acuerdos implican que intereses conflictivos converjan [Monteserin, 2006]. En este contexto el proceso de negociación puede ser visto como una búsqueda distri-buida en un espacio de potenciales acuerdos, donde la dimensionalidad y topología de este espacio está determinada por la estructura del objeto de negociación, tal como lo muestra la figura 3.3 [Jennings et al., 2001].
Figura 3.3.: Esquema general de negociación
La naturaleza del proceso de negociación da lugar al surgimiento de conflictos, tanto en escenarios colaborativos como de competencia. La diferencia entre los anteriores es que un escenario competitivo presenta un tipo de negociación donde el conflicto resulta de los intereses/objetivos opuestos de cada agente; mientras que en una negociación colaborativa los agentes comparten objetivos, pero los conflictos surgen en base al modo de alcanzarlos que posee cada una de las partes [Monteserin y Amandi, 2011]. Para tratar con este asunto cada agente puede tener acceso a cierta información antes de iniciar el proceso de negociación:
3.3 Negociación entre agentes inteligentes
como preferencias, intereses y objetivos. Esta información condiciona el modo de actuar y el grado de acuerdo deseado por el agente.
Información acerca de sus “oponentes”: información sobre objetivos e intereses del resto de los agentes, recolectada en interacciones previas. En situaciones realistas, los agentes poseen información acotada sobre sus oponentes, debido a que cada agente contiene información “privada” sobre su estado, la cual no está disponible para el resto.
Información sobre el contexto: conocimiento relevante acerca de la resolución de conflictos, por ejemplo el espacio de potenciales acuerdos, e información histórica sobre negociaciones previas.
De acuerdo a lo anterior, en base a la información disponible se podrá desarrollar un modelo en el cual cada agente provea alternativas para alcanzar un acuerdo, como así también analizar propuestas ajenas y negociar en consecuencia.
3.3.1. Enfoques de negociación
Según el enfoque de negociación utilizado, se pueden distinguir tres tipos de negocia-ción [Jennings et al., 2001]:
3.3.1.1. Modelos basados en teoría de juegos
Este enfoque tiene sus bases en la teoría desarrollada por von Neumann y Morgenstern. Utiliza técnicas y resultados de la teoría de juegos, aplicándola a las interacciones que ocurren entre agentes con intereses propios. En este tipo de situaciones el resultado total dependerá de las elecciones realizadas por todos los agentes involucrados. Esto implica que cada agente deba razonar estratégicamente para escoger una opción que maximice su rendimiento; esto significa que se deben tener en cuenta las decisiones que los otros agentes pueden tomar, y asumir que cada uno de los agentes actuará de modo tal de maximizar también su ganancia.
3.3 Negociación entre agentes inteligentes
elementos, protocolo y estrategias, constituyen un mecanismo de negociación. Dicho mecanismo debe ser estable (no manipulable), es decir, que deberá motivar a cada agente a comportarse de la manera esperada.
Más allá de las características y beneficios que ofrece este enfoque, existen ciertos inconvenientes que dificultan su implementación [Jennings et al., 2001]: el enfoque ba-sado en teoría de juegos asume que es posible determinar qué resultados de la ne-gociación son preferibles para los agentes, mediante la definición de una función de utilidad; en ocasiones esto puede resultar muy complejo, por ejemplo cuando se debe negociar sobre múltiples temas, debido a la dificultad que presenta la definición de dicha función. Además, este enfoque se basa en la noción de racionalidad perfecta, lo que requiere que el agente tenga recursos computacionales ilimitados y el espacio de resultados sea completamente conocido.
3.3.1.2. Modelos basados en heurística
Este enfoque propone una solución a las limitaciones mencionadas para el enfoque de teoría de juegos, asumiendo que existe un costo relacionado con la computación y toma de decisiones, apuntando de este modo a realizar búsquedas no exhaustivas en el espacio de soluciones. En consecuencia, el enfoque basado en heurística apunta a producir buenos resultados (más que resultados óptimos). No obstante, los resultados producidos se acercan generalmente a los obtenidos mediante el uso de teoría de juegos. Entre las principales ventajas de la utilización del enfoque basado en heurística se puede enunciar que estos modelos proveen bases adecuadas para la automatización y pueden, en consecuencia, ser usados en una más amplia variedad de dominios de aplicación. Además, los diseñadores de agentes no están limitados por la teoría de juegos, y pueden utilizar alternativas y otros modelos de racionalidad para desarrollar diferentes arquitecturas de agentes.
3.3 Negociación entre agentes inteligentes
3.3.1.3. Modelos basados en argumentación
En los modelos anteriores, los agentes se limitan a intercambiar información referente a las propuestas de cada uno sobre los objetos de la negociación; esto puede ser pro-blemático en situaciones donde los agentes tienen información limitada del ambiente, o donde sus elecciones racionales dependen de otros agentes. Por otra parte, las uti-lidades o preferencias de los agentes son asumidas generalmente como características prioritarias de la interacción, y en consecuencia se asume que el agente posee un me-canismo por el cual puede evaluar y comparar dos propuestas; esta característica tiene limitaciones especialmente en situaciones complejas, donde se cuenta con información incompleta o bien cuando no existe una utilidad cuantificable. Además, en estos mode-los un agente no puede influir directamente en el modelo de preferencias de otro agente que determinan las propuestas generadas y la aceptación o rechazo de las recibidas. En el enfoque de negociación basado en argumentación, los agentes pueden intercam-biar información adicional, o argumentos para justificar sus propuestas, persuadir a otros agentes, y para alcanzar un acuerdo esperado. Así, sumada a las propuestas propias de la negociación, un agente puede ofrecer una crítica de éstas, en lugar de simplemente aceptarla o rechazarla, o acompañar una propuesta propia con una jus-tificación [Monteserin y Amandi, 2011].
3.3.2. Protocolo de concesión monótona
El protocolo de concesión monótona [Rosenschein y Zlotkin, 1994] establece un con-junto de reglas que definen el rango de acciones aceptables durante un proceso de negociación. Para esto se sigue un esquema general en el cual cada uno de los agentes involucrados en el proceso realiza inicialmente una propuesta que es beneficiosa para sí mismo, y posteriormente revisa y analiza las diferentes propuestas realizadas para alcanzar un acuerdo.
3.3.2.1. Definición para negociación bi-lateral
3.3 Negociación entre agentes inteligentes
A un conjunto finito de agentes, cada agente i A proveerá una función de utilidad ui : X→R+0 que asigna un valor a cada propuesta, siendo 0 el valor más bajo. En la
primer ronda, cada agente irealiza su mejor propuesta. En las rondas siguientes, cada
agente tiene dos opciones:
1. Realizar una concesión y proponer una nueva soluciónx0ique puede ser preferible
para el otro agente j: uj(xi)< uj(x0i)
2. Negarse a conceder y mantener su propuesta actual xi
Un acuerdo es alcanzado cuando un agente realiza una propuesta que su oponente pondera igual o mejor que su actual propuesta, es decir cuando u1(x1) ≤ u1(x2) o
u2(x2)≤u2(x1). Por otro lado, el estado deconflicto ocurre cuando ambos agentes se
rehúsan a realizar una concesión en una ronda. El protocolo de concesión monótona establece el fin de la negociación cuando se alcanza un acuerdo, o bien cuando surge un conflicto. En el caso de acuerdo, la propuesta que satisface a ambos agentes es escogida. En el caso de conflicto, por otro lado, no existirá propuesta que beneficie a todas las partes.
Para decidir qué acción debe tomar un agente en cada ronda de la negociación, se puede adoptar la estrategia propuesta por Zeuthen, que consiste en evaluar la cercanía al riesgo de conflicto, definida como el cociente de la pérdida de utilidad incurrida en caso de adoptar la propuesta de otro agente y la pérdida incurrida por causa de conflicto, de la siguiente manera:
Zi = ui(xi)
−ui(xj)
ui(xi)
En este caso, el agente que posea un menor valor de esta métrica, debería conceder. Adicionalmente, una concesión debería bastar para que el otro agente deba conceder en la próxima ronda.
3.3.2.2. Generalización del protocolo para N agentes
En base a las definiciones anteriores para el protocolo de concesión monótona, se puede extender el concepto para definir un protocolo general para negociación multi-lateral [Endriss, 2006].
3.3 Negociación entre agentes inteligentes
1. En la primera ronda, cada agente realiza una propuesta inicial (se asume que será la mejor propuesta de cada uno).
2. En cada ronda siguiente, cada agente realiza una concesión o mantiene su pro-puesta actual.
3. El proceso anterior se realiza iterativamente hasta que surja una situación de conflicto (ningún agente concede), o bien hasta que se alcance un acuerdo. En cuanto al concepto de acuerdo, se establece lo siguiente: un acuerdo es alcanzado si y sólo si un agente realiza una propuesta que es al menos tan buena para cada uno del resto de los agentes como sus propias propuestas, es decir, que existe un agente
i A tal que uj(xi)≥uj(xj) para todos los agentes j A.
En el caso de la concesión, no existe un criterio único. Se puede por ejemplo realizar una propuesta que beneficie a alguno de los otros agentes, o bien buscar una propuesta que beneficie a todos. A continuación se describen algunos criterios de concesión:
Concesión “fuerte” (Strong concession): realizar una propuesta que es estricta-mente mejor para cada uno del resto de los agentes.
Concesión “débil” (Weak concession): realizar una propuesta que es estrictamen-te mejor para al menos uno de los otros agenestrictamen-tes.
Concesión de Pareto (Pareto concession): realizar una propuesta que es al menos tan buena para los otros agentes como su propia propuesta, y estrictamente mejor para al menos uno de ellos.
Concesión “utilitaria” (Utilitarian concession): realizar una propuesta tal que la suma de las utilidades de los otros agentes incremente.
Concesión “igualitaria” (Egalitarian concession): realizar una propuesta tal que la utilidad mínima entre los otros agentes aumente.
Concesión de Nash (Nash concession): realizar una propuesta tal que el producto de las utilidades de los otros agentes incremente (producto de Nash).
Concesión “egocéntrica” (Egocentric concession): realizar una propuesta que es peor para sí mismo. Este criterio se basa en que lo que es peor para un agente, es mejor para el resto.
3.3 Negociación entre agentes inteligentes
Propiedad Concesión fuerte
Concesión débil
Pareto Nash Concesión Igualitaria
Concesión Utilitaria
Concesión Egocéntrica
Terminación Si No Si Si Si Si Si
Composición Si Si Si Si Si Si Si
Libre de
deadlocks
No Si No Si No Si Si
Verificabilidad Si Si Si No No No No
Tabla 3.2.: Características generales sobre criterios de concesión
Para evaluar y seleccionar el criterio de concesión más adecuado de acuerdo a los requerimientos de una situación, se pueden considerar las siguientes características de los protocolos de negociación:
Terminación: una propiedad importante de un protocolo de negociación es que este pueda garantizar que todo proceso de negociación que siga el patrón esta-blecido finalizará en algún momento.
Composición: Esta propiedad se satisface si y sólo si la composición de dos concesiones consecutivas de acuerdo a un criterio resultará igual que la aplicación de ambas concesiones por separado.
Libre de deadlocks: Un deadlock se produce cuando ningún agente puede realizar acción alguna de acuerdo con el modelo establecido, pero no se ha llegado a un estado final (acuerdo o conflicto). En el contexto de un protocolo de negociación monótona, cada agente siempre tiene la opción de conceder o mantener una pro-puesta; en consecuencia, siempre será posible continuar la negociación de acuerdo al protocolo. No obstante, existen situaciones para algunos criterios en las cuales un agente que debe realizar una concesión no cumple con las condiciones para hacerlo.
Verificabilidad: Un protocolo debería ser verificable de modo tal que debería ser posible evaluar que todo el mundo está siguiendo las reglas establecidas por el protocolo. Esta evaluación puede ser realizada por cualquiera de los agentes involucrados en la negociación, o bien por una entidad externa.
La tabla 3.2 muestra el cumplimiento (y garantía) de las características mencionadas anteriormente por cada uno de los criterios de concesión:
3.3 Negociación entre agentes inteligentes
tratar las diferentes situaciones que se puedan generar, y verifiquen el cumplimiento de tales características.
3.3.2.3. Estrategias de negociación
De acuerdo a lo explicado en la sección anterior, en la primer ronda de negocia-ción cada agente realiza una propuesta inicial. En las rondas siguientes, los agen-tes tienen dos alternativas: conceder o mantener su propuesta anterior. Esto im-plica considerar los siguientes aspectos en el proceso de negociación [Endriss, 2006] [Wooldridge et al., 1996]:
¿Cuál debería ser la propuesta inicial de un agente?
Se asume que la propuesta inicial de cada agente deberá ser la propuesta más conveniente/beneficiosa para sí mismo (aquella que maximiza su utilidad). ¿Quién debe conceder en cada ronda?
Para determinar qué agente debe conceder se puede utilizar una generalización de la estrategia de Zeuthen mencionada en lasección 3.3.2.1, aplicada a la situación de negociación multi-agente. En este caso, se evaluará la pérdida de utilidad en caso de concesión asumiendo el peor resultado para el agente en base a las propuestas actuales del resto. Formalmente, esta estrategia se define como:
Zi =
1si ui(xi) = 0 ui(xi)−min{ui(xk)|k A}
ui(xi) si ui(xi)>0
En efecto, el agente cuyo valor para esta medida sea el menor, será quien deba conceder en la ronda actual.
Si bien esta estrategia resuelve en forma intuitiva la problemática sobre quién debe conceder, podría acarrear el surgimiento de deadlocks como consecuencia de un agente que posee el menor valor Zi pero no puede realizar una concesión. En este caso, la
solución será elegir el agente cuya métrica sea la menor entre el conjunto de agentes que puedan realizar una concesión efectiva en una determinada ronda.
Otra generalización de la estrategia de Zeuthen consiste en evaluar el incremento del producto de utilidades para cada agente de la siguiente manera:
Z´i =Q kA
3.4 Resumen
De igual modo, aquel agente cuyo producto de utilidades sea el menor para una ronda determinada, será quien deba conceder.
¿Cuánto se debe conceder?
En principio, una concesión debería ser mínima con respecto a la pérdida de uti-lidad incurrida por el agente que realiza la concesión. Esto significa que, entre el conjunto de potenciales propuestas que satisfacen el criterio de concesión adop-tado por el protocolo de negociación, se debe seleccionar aquella que maximice su utilidad.
Por otra parte, un agente debería conceder lo suficiente de modo que no existan dos rondas consecutivas donde el mismo deba realizar una propuesta, para evi-tar un aumento innecesario en la cantidad de rondas del protocolo. En efecto, si una propuesta xi dada por un agente i está compuesta por las propuestas x0i y
x00i, y además esta genera que en la próxima ronda deba conceder otro agente j,
entonces es conveniente que el agente i proponga como alternativa a xi en una
única ronda, y no proponer x0i y luego x00i en dos rondas sucesivas.
3.4. Resumen
Los agentes inteligentes constituyen sistemas de software o hardware que pueden desa-rrollar actividades en forma autónoma, y proactiva, respondiendo a sucesos percibidos en su entorno. Una aplicación muy interesante sobre el campo de inteligencia artificial es la construcción de sistemas expertos, que permiten solucionar o diagnosticar pro-blemáticas en situaciones complejas sobre diversos dominios, sirviendo de gran ayuda como herramientas de asistencia a usuarios.
La negociación es una herramienta de interacción esencial en sistemas compuestos por múltiples agentes, donde es necesario alcanzar acuerdos y buscar una solución que intente beneficiar lo más posible las diversas partes con diferentes intereses, en ocasiones antagónicos.
3.4 Resumen
revisa y analiza las diferentes propuestas realizadas para alcanzar un acuerdo. Una vez que el algoritmo de negociación converge (por acuerdo de todas las partes, o bién por el surgimiento de conflicto al no encontrar una alternativa suficientemente beneficiosa para el conjunto), la solución obtenida constituye la resultante del proceso.
4. Trabajos relacionados
En este capítulo se hará referencia a diversas herramientas orientadas a la asistencia del usuario en el diseño de arquitecturas de software. Cada una de estas herramientas po-seen distintas características que serán identificadas y analizadas a fines de establecer referencias y comparaciones entre los enfoques existentes y su relación con el presente trabajo. En este contexto, lo interesante de estas aplicaciones, y en consecuencia lo que se pretende remarcar, es que todas presentan un cierto grado de automatización que contribuye a mejorar una parte del proceso de diseño de arquitecturas. Por otra parte, se mencionará una técnica alternativa a la negociación multi-agente para la resolución de problemas con variables dependientes.
4.1. Architecture Expert (ArchE)
La herramienta ArchE es un asistente para el arquitecto desarrollada por el SEI, utilizando como punto clave el tratamiento de los requerimientos de atributos de calidad para el modelado de arquitecturas. Esta herramienta se concibe como un soporte en la exploración de soluciones arquitectónicas orientadas a atributos de calidad, más que una herramienta de diseño automatizado [Diaz-Pace et al., 2008] [Bachmann et al., 2003b].
ArchE está basado en cuatro conceptos principales:
1. Escenarios de calidad: requiere que los escenarios sean especificados utilizando la estructura formal de seis partes que incluye estímulo, fuente, ambiente, artefacto, respuesta y medida de la misma.
responsa-4.1 Architecture Expert (ArchE)
bilidades pueden ser agregadas, divididas o modificadas conforme al avance del diseño, para contribuir al alcance de un atributo de calidad en particular. 3. Frameworks de razonamiento (Reasoning Frameworks): El conocimiento acerca
de los atributos de calidad es encapsulado en frameworks. Un framework de razo-namiento incluye conocimiento relevante sobre un atributo de calidad particular (por ej., un modelo de análisis), y permite evaluar cuándo una arquitectura satis-face los requerimientos de dicho atributo, proponiendo tácticas como mecanismos de mejora.
4. Tácticas arquitectónicas: las tácticas permiten satisfacer un escenario de calidad mediante la manipulación de ciertos aspectos del diseño arquitectural.
Mediante ArchE, los requerimientos funcionales son representados como un grafo de responsabilidades, reforzado con requerimientos de calidad mediante escenarios. Esos escenarios son categorizados de acuerdo al atributo de calidad que modelan. Por cada atributo de calidad existen frameworks de razonamiento que convierten los escena-rios en un modelo dependiente del atributo de calidad que representan. Cada modelo representa un diseño que satisface los requerimientos establecidos para ese atributo de calidad. Los frameworks de razonamiento generan propuestas de transformaciones (en forma individual) a aplicar sobre la arquitectura, que intentan resolver conflictos entre diferentes modelos para crear un modelo general que satisface todos los reque-rimientos de atributos de calidad. Finalmente, este modelo general se convierte en la representación del diseño arquitectónico (figura 4.1).
Concep-4.1 Architecture Expert (ArchE)
Figura 4.1.: Modelo general de diseño arquitectónico según ArchE
tualmente, el motor de ArchE construye un árbol de soluciones candidatas, con la arquitectura actual como raíz de dicho árbol y cada rama asociada a una táctica, cu-yos nodos representan soluciones generadas a partir de la aplicación de cada táctica sobre la arquitectura actual. El árbol es expandido sobre un número fijo de niveles, y el motor de ArchE utiliza reglas de decisión para evaluar las soluciones de cada nivel y propagar/aplicar los resultados a la arquitectura actual.
Siempre que un usuario desee realizar cambios en alguna parte del diseño arquitec-tónico, ArchE inicia un ciclo de búsqueda y aplicación de soluciones, que incluye las siguientes interacciones:
1. Si se decide aplicar una táctica, el motor de ArchE envía un mensaje ( applyTac-tics) al framework de razonamiento (RF) que sugirió la táctica conveniente, y en consecuencia el RF modifica la arquitectura de acuerdo a lo sugerido.
2. Por cada RF, ArchE envía el mensaje AnalyzeAndSuggest en forma secuencial. Cada RF realiza un análisis sobre la arquitectura actual para determinar si los escenarios implicados se satisfacen. Si esto no ocurre, se intentará buscar tácticas apropiadas para modificar la arquitectura en consecuencia. Luego, cada RF retorna el resultado del análisis y una lista de tácticas sugeridas.
3. Por cada táctica sugerida:
