Estructura de soporte para evaluación multi-agente

En base a las facilidades de extensibilidad que provee el diseño existente de la apli- cación, y a las necesidades surgidas para soportar el proceso de negociación entre los agentes configurados en la aplicación, se modificó la estructura del motor de análisis, agregando nuevas características a la implementación utilizada para representar a los Design Bots.

En principio, hace uso del patrón de composición para definir la clase DBNegotiatio- nExecutor, la cual encapsula el comportamiento general de un Design Bot establecido por la clase DesignBotExecutor, e incluye nuevas características tales como una lista de las soluciones candidatas encontradas; una función de utilidad (UtilityFunction) para priorizar estas soluciones candidatas de acuerdo a su costo/ganancia asociada; una estrategia de evaluación, conocida como función de Zeuthen tal como se trató en el capítulo 4, utilizada para guiar el proceso de negociación (IZeuthenFunction); y diversos métodos y atributos, tales como funciones de comparación y selección de solu- ciones parciales, los cuales son fuertemente utilizados durante el proceso de búsqueda y evaluación de alternativas.

La interfaz UtilityFunction define un único método getUtility que, dado un valor (ge- neralmente asociado a un costo de acuerdo al atributo de calidad evaluado) retorna una utilidad equivalente. Posteriormente, se incluyen funciones de utilidad que imple- mentan esta interfaz. El objetivo de la utilización de utilidades es establecer una única forma de evaluar y comparar arquitecturas, independientemente del tipo de métrica utilizada en cada escenario de calidad. Por ejemplo, para escenarios de performance, la utilización de una métrica basada en el throughput establece que el beneficio es mayor cuanto mayor sea el valor obtenido; ocurriendo lo contrario para el uso de una métrica basada en latencia (cuanto mayor sea el valor, menor el beneficio). En este caso, el uso de utilidades para evaluar alternativas permitirá fácilmente establecer límites y comparaciones de manera “normalizada”.

De acuerdo a la métrica utilizada y a la ponderación asociada al escenario de cali- dad, es posible configurar diferentes funciones de utilidad para un agente de análisis. Actualmente se encuentran disponibles solamente tres implementaciones (LinearUti- lity, ExponentialUtility, ExponentialDecreasingUtility), siendo posible incorporar nue- vas funciones en tiempo de diseño/programación, aprovechando el soporte extensible que provee la interfaz definida.

6.2 Diseño de mejoras propuestas

senta mediante una variable de clase para DBNegotiationExecutor, siendo esta una implementación de la interface IZeuthenFunction (llamada así dado que las funciones utilizadas son generalizaciones de la teoría propuesta por Zeuthen, tal como se explicó en el capítulo anterior). Esta interface define un único método getZeuthenValue que retorna un valor dada una alternativa candidata propuesta, en base al cual se definirá luego qué Design Bot debe conceder en cada ronda.

Por último, uno de los puntos de modificación que más se destacan es la inclusión de una entidad que oficia de mediador entre los agentes de análisis durante el proceso de negociación. Este es implementado a través de la clase NegotiationMediator y provee la lógica necesaria para iniciar la fase de negociación (initNegotiation), gestionar las sucesivas rondas de evaluación de propuestas, determinar qué agente debe conceder en cada una (selectAgentForConcession) y obtener los resultados finales una vez concluido el proceso (showResults), ya sea alcanzando o no un acuerdo entre los Design Bots. En lafigura 6.6se muestra un diagrama general con las principales clases intervinientes en el diseño de la solución propuesta.

6.2.2. Búsqueda de soluciones

Partiendo sobre las bases del enfoque inicialmente incluido en la herramienta, se en- contró la necesidad de implementar un algoritmo de búsqueda de soluciones en forma más exhaustiva, en donde no sólo cada agente obtenga un conjunto de soluciones ba- sadas en sus propias tácticas, sino que también se interactúe con las tácticas del resto de los Design Bots activos.

Por lo tanto, el proceso de análisis se vió modificado, comenzando en principio este de igual modo, recibiendo una petición hacia el servicio asociado (AnalysisService) con los parámetros correspondientes. Luego, se crea una bifurcación con dos caminos en don- de la decisión de tomar una opción u otra dependerá de una variable establecida que indica si el usuario ha seleccionado un análisis mediante negociación entre los agentes activos. En el caso de que esto no sea así, el proceso de análisis actuará de manera tal como que se explicó en la sección 6.1.2. Si se ha optado por la aplicación del proceso de negociación, el servicio creará una instancia de un agente de negociación (DBNego- tiationExecutor), el cual es una composición del DesignBotExecutor, por cada Design Bot configurado para el análisis de la arquitectura. En el mismo se le asigna, además de los parámetros mencionados anteriormente, una función de utilidad y un umbral

6.2 Diseño de mejoras propuestas

que serán posteriormente utilizados en la negociación con el resto de los agentes. Tam- bién se adiciona una lista sincronizada de soluciones candidatas (NegotiationChoice), donde cada elemento contiene una architectura y una lista de tácticas utilizados para la búsqueda. Esta última estructura (List<NegotiationChoice>) es la que contiene las soluciones combinadas de los agentes.

Una vez que los agentes de negociación han sido inicializados, se comienza un ciclo en el cual habrá un hilo principal que se desempeñará como mediador, y varios hilos in- dependientes caracterizando a cada agente, los cuales recorrerán la lista de soluciones candidatas actual y, por cada uno de sus elementos, generarán nuevas posibles solucio- nes que se irán agregando en la lista. Con la lista resultante, cada agente realizará una priorización de acuerdo a la función de utilidad configurada. Esta búsqueda, de acuer- do a como se vió en el capítulo anterior, puede ser considerada más fácilmente como un árbol cuya creación incluye varios pasos que serán enumerados a continuación:

1. El mediador inicia el proceso. Establece el valor para el nivel actual y un índice de nodo sobre dicho nivel. Ambos índices son utilizados para indicar posiciona- miento durante el recorrido del árbol, y asegurar que al final del proceso se hayan explorado N niveles completos (siendo N indicado por el usuario en tiempo de configuración).

2. Mientras que el nivel del árbol no haya alcanzado el límite establecido por el usuario, se selecciona en forma ordenada un nodo del árbol, y posteriormente los agentes son notificados para generar en forma paralela nuevas soluciones. 3. Cada Design Bot obtiene la arquitectura representada por el nodo actual, y

por cada táctica disponible que contengan los mismos, se generará una solución basada en el algoritmo de búsqueda seleccionado (implementación de TrackAl- gorithm, ya sea Predictive o Backtracking), la arquitectura actual y el escenario asociado al agente. Esta solución encontrada, será incluída en la lista principal de alternativas candidatas. El agente entonces entra en estado de espera hasta la notificación del mediador.

4. Si se alcanzó el límite de amplitud del nivel (es decir todas las posibles soluciones combinadas de los agentes han sido evaluadas), se incrementa el nivel actual en una unidad. Este aumento implica que se recorrerá el siguiente nivel del árbol, que contiene las soluciones recientemente encontradas en el nivel anterior. 5. Se repite el ciclo a partir del punto 2.

6.2 Diseño de mejoras propuestas

6. Finalmente, con el árbol de exploración completo, se notifica a los agentes para que prosigan con el ordenamiento de la lista global de soluciones de acuerdo a su prioridad asociada (UtilityFunction). Además, cada agente retorna su mejor solución que será visualizada por el usuario.

En el diagrama de secuencia UML de la figura 6.7 se muestra en resumen el proceso de búsqueda de soluciones.

Figura 6.7.: Diagrama de secuencia de proceso de búsqueda de soluciones