Sistema Multiagente de Negociación Automática Basada en
Transcripción
Sistema Multiagente de Negociación Automática Basada en
Universidad Nacional del Centro de la Provincia de Buenos Aires FACULTAD DE CS. EXACTAS Sistema Multiagente de Negociación Automática Basada en Diálogos Expresivos para Compras en un Ámbito Municipal Tesis de Grado en Ingeniería de Sistemas Alumno Leandro Martín Delgado Director Dr. Ariel Monteserin Tandil, 2015 Resumen En un ámbito municipal de gobierno, las compras de todo tipo de artículos son muy habituales. En algunos casos, la adquisición de un producto no admite pérdida de tiempo ni retrasos. La pregunta que nos hacemos es ¿cómo podemos mejorar dicho proceso a través del uso de tecnología? Los portales de comercio electrónico tradicionales son cada vez más utilizados. En ellos, el comprador, con un requerimiento de compra bien especificado, selecciona manualmente, de las diferentes opciones, la que mejor se ajuste a sus pretensiones. Este enfoque continua insumiendo un tiempo considerable, carece de eficiencia y disponibilidad; todo esto consecuencia de la intervención humana en gran parte del proceso. En el presente trabajo proponemos un sistema de negociación automática basado en restricciones difusas, aplicado a un contexto de compras en un gobierno municipal. En este sentido, desarrollamos un estudio de los diferentes modelos de negociación, y los actores involucrados, con el fin de obtener la mejor alternativa que cumpla con las características planteadas. A sí mismo, experimentamos sobre la herramienta con el propósito de comprobar su efectividad. Tabla de contenido Capítulo 1. Introducción ................................................................................................ 11 1.1 Motivación ............................................................................................................. 12 1.2 Solución propuesta ................................................................................................. 17 1.3 Esquema de la tesis ................................................................................................. 20 Capítulo 2. Comercio electrónico en un Municipio ...................................................... 23 2.1 Introducción ........................................................................................................... 23 2.2 Gobierno electrónico y sus tipos ............................................................................. 26 2.2.1 Modelo de Negocio a Gobierno ........................................................................ 27 2.3 Resumen general .................................................................................................... 29 Capítulo 3. Sistemas Multiagente y Modelos de Negociación ....................................... 32 3.1 Agentes Inteligentes y Sistemas Multiagente .......................................................... 32 3.1.1 Agentes inteligentes ......................................................................................... 32 3.1.1.1 Propiedades de los agentes inteligentes ...................................................... 35 3.1.1.2 Entorno de un agente ................................................................................. 36 3.1.2 Sistemas multiagente ........................................................................................ 37 3.1.3 Comunicación de agentes ................................................................................. 39 3.1.3.1 Lenguajes de comunicación ....................................................................... 40 3.1.4 Ontologías ........................................................................................................ 42 3.1.5 Plataformas de desarrollo de sistemas multiagente ............................................ 45 3.1.5.1 JADE (Java Agent DEvelopment Framework) ........................................... 45 3.1.5.2 JADEX ...................................................................................................... 45 3.1.5.3 JACK......................................................................................................... 46 3.1.5.4 ZEUS......................................................................................................... 47 3.2 Modelos de negociación ......................................................................................... 47 3.2.1 Componentes de un modelo de negociación ..................................................... 49 3.2.2 Teoría de juegos ............................................................................................... 51 3.2.3 Enfoques basados en heurísticas ....................................................................... 53 3.2.4 Enfoques basados en argumentación................................................................. 54 3.2.5 Enfoques basados en restricciones difusas ........................................................ 56 3.2.6 Resumen .......................................................................................................... 57 3.3 Resumen general .................................................................................................... 59 Capítulo 4. Modelo de negociación basado en restricciones difusas ............................ 63 4.1 Introducción ........................................................................................................... 63 4.2 Modelo de preferencias del comprador y vendedor ................................................. 68 4.3 Problemas de satisfacción de restricciones (CSP) .................................................... 70 4.4 Problema de satisfacción de restricciones difusas (FCSP) ....................................... 71 4.5 Conocimiento del dominio de los agentes ............................................................... 73 4.5.1 Conocimiento del dominio del agente comprador ............................................. 73 4.5.2 Conocimiento del dominio del agente vendedor ............................................... 77 4.6. Modelo de diálogo de alto nivel ............................................................................. 79 4.7 Mecanismos de decisión y locuciones ..................................................................... 81 4.7.1 Mecanismos de decisión del agente comprador ................................................ 81 4.7.2 Mecanismos de decisión del agente vendedor ................................................... 87 4.8 Resumen general .................................................................................................... 94 Capítulo 5. Instanciación del modelo de negociación ................................................... 97 5.1 Introducción ........................................................................................................... 97 5.2 Instanciación de los mecanismos de decisión del Sector de Compras ...................... 99 5.3 Instanciación de los mecanismos de decisión del Proveedor .................................. 104 5.4 Detalles de diseño ................................................................................................. 113 5.4.1 Arquitectura del sistema ................................................................................. 114 5.4.2 Diseño e implementación de la lógica de negociación .................................... 115 5.4.2.1 Implementación de agentes inteligentes y sus componentes ..................... 116 5.4.2.2 Agente municipal: Mecanismos de decisión ............................................. 117 5.4.2.3 Agente proveedor: Mecanismos de decisión ............................................. 121 5.5 Resumen general .................................................................................................. 123 Capítulo 6. Evaluación experimental .......................................................................... 125 6.1 Caso de estudio 1: Compra de una impresora ........................................................ 125 6.1.1 Introducción ................................................................................................... 125 6.1.2 Desarrollo del caso de estudio ........................................................................ 126 6.1.2.1 Apertura del diálogo ................................................................................ 127 6.1.2.2 Negociación ............................................................................................. 129 6.1.2.3 Confirmación y Cierre del Diálogo .......................................................... 141 6.1.3 Conclusión del caso de estudio ....................................................................... 142 6.2 Caso de estudio 2: Análisis de performance .......................................................... 143 6.2.1 Introducción ................................................................................................... 143 6.2.2 Diez productos ............................................................................................... 144 6.2.3 Cincuenta productos ....................................................................................... 146 6.2.4 Cien productos ............................................................................................... 148 6.2.5 Quinientos productos...................................................................................... 149 6.2.6 Atributos incrementales y no incrementales .................................................... 151 6.2.7 Conclusión del caso de estudio ....................................................................... 153 6.3 Conclusión ........................................................................................................... 154 Capítulo 7. Conclusiones.............................................................................................. 156 7.1 Contribuciones...................................................................................................... 156 7.2 Limitaciones encontradas...................................................................................... 158 7.3 Trabajos futuros.................................................................................................... 160 Índice de figuras Figura 1 Agente inteligente y su interacción con el entorno .............................................. 34 Figura 2 Entorno de un agente inteligente ........................................................................ 36 Figura 3 Evolución del grado de satisfacción para una entidad municipal ......................... 65 Figura 4 Catálogo del proveedor ...................................................................................... 65 Figura 5 Diálogo negociador ............................................................................................ 66 Figura 6 Diagrama de reglas de transición ........................................................................ 93 Figura 7 Vista de despliegue .......................................................................................... 114 Figura 8 Diagrama de clases para los mecanismos de decisión del agente municipal ...... 117 Figura 9 Diagrama de secuencia para la modificación de un requerimiento de compra ... 119 Figura 10 Diagrama de secuencia para la evaluación de una oferta ................................. 120 Figura 11 Diagrama de clases para los mecanismos de decisión del agente proveedor .... 121 Figura 12 Diagrama de secuencia para la generación de ofertas potenciales ................... 122 Figura 13 Selección del requerimiento de compra inicial ................................................ 128 Figura 14 Gráfico de líneas para un catálogo de 10 productos ........................................ 145 Figura 15 Gráfico de líneas para un catálogo de 50 productos ........................................ 147 Figura 16 Gráfico de líneas para un catálogo de 100 productos ...................................... 149 Figura 17 Gráfico de líneas para un catálogo de 500 productos ...................................... 150 Figura 18 Gráfico de barras para atributos incrementales y no incrementales ................. 153 Índice de tablas Tabla 1 Ventajas y desventajas de los enfoques basados en teoría de juegos, heurística y argumentación ................................................................................................................. 56 Tabla 2 Detalle de la locución L1: open_dialogue(.) ......................................................... 82 Tabla 3 Detalle de la locución L6: prefer_to_buy(.) ......................................................... 85 Tabla 4 Detalle de la locución L7: refuse_to_buy(.) ......................................................... 86 Tabla 5 Detalle de la locución L9: agree_to_buy(.) .......................................................... 86 Tabla 6 Detalle de la locución L11: withdraw_dialogue(.) ................................................ 87 Tabla 7 Detalle de la locución L2: enter_dialogue(.) ........................................................ 88 Tabla 8 Detalle de la locución L3: willing_to_sell(.) ........................................................ 88 Tabla 9 Detalle de la locución L5: prefer_to_sell(.) .......................................................... 90 Tabla 10 Detalle de la locución L8: refuse_to_sell(.) ........................................................ 91 Tabla 11 Detalle de la locución L10: agree_to_sell(.) ....................................................... 91 Tabla 12 Reglas de transición ........................................................................................... 92 Tabla 13 Atributos, intervalos difusos y niveles de corte para la categoría Impresora ..... 129 Tabla 14 Atributos de la impresora BROTHER HL-5450DN ......................................... 130 Tabla 15 Atributos de la impresora BROTHER HL-2270DW ........................................ 131 Tabla 16 Atributos de la impresora LEXMARK MS811dn ............................................ 132 Tabla 17 Porción de la negociación entre el agente proveedor y el municipal ................. 140 Tabla 18 Situación de la negociación en el tramo final ................................................... 140 Tabla 19 Duraciones, media y desviación estándar para un catálogo de 10 productos ..... 145 Tabla 20 Duraciones, media y desviación estándar para un catálogo de 50 productos ..... 147 Tabla 21 Duraciones, media y desviación estándar para un catálogo de 100 productos ... 148 Tabla 22 Duraciones, media y desviación estándar para un catálogo de 500 productos ... 150 Tabla 23 Duraciones, media y desviación estándar para atributos incrementales y no incrementales ................................................................................................................. 152 Capítulo 1 Introducción La Oficina de Compras de una entidad municipal de gobierno es la encargada del suministro de todos los sectores municipales. Su función es de suma importancia y, en algunos casos, puede ser crítica en el sentido de obtener los productos solicitados en tiempo y forma. Sería inadmisible, por ejemplo, un retraso en la adquisición de un medicamento de vital importancia para un paciente internado en el hospital municipal. Actualmente la mecánica de funcionamiento de la Oficina consiste en recepcionar solicitudes de adquisición de productos perfectamente especificados por parte de los sectores; para luego contactar a los proveedores con el fin de recabar cotizaciones y realizar la compra al más conveniente. Podemos mencionar algunas observaciones sobre esta metodología: la primera es que la Oficina de Compras no evalúa alternativas igualmente convenientes a la solicitud de compra recibida debido al desconocimiento sobre el rubro del producto en cuestión; la segunda es que existe un horario operativo, es decir, salvo una situación crítica, la Oficina funciona en un rango de seis horas como la gran mayoría de los sectores municipales; la tercera es que la comunicación con los proveedores suele insumir un tiempo considerable relacionado a la tardanza que puede implicar toda operatoria llevada a cabo por personas. En este contexto planteamos el diseño e implementación de una herramienta informática que mejore sustancialmente la operatoria de compra en un ámbito municipal. Esta se basa en la teoría de negociación automática, es decir, con la mínima intervención humana posible. Para ello hacemos un análisis de los diferentes modelos de negociación con el fin de obtener la mejor alternativa que se ajuste a nuestro escenario. Concluimos que los modelos de negociación automática basados en restricciones difusas cuentan con varias ventajas por sobre el resto. A su vez, para lograr este automatismo, nos introducimos en el concepto de agentes inteligentes, más precisamente en un conjunto de ellos con capacidades de diálogo para lograr beneficiar al usuario que representan. Esto no es otra cosa que un sistema multiagente. 1.1 Motivación Aunque los gobiernos generalmente no venden productos o servicios a clientes, realizan compras de diversos artículos para el normal funcionamiento de las instituciones, las cuales pueden mejorarse mediante el uso del comercio electrónico. Los gobiernos también realizan actividades de tipo empresarial; por ejemplo, emplean gente, compran suministros a proveedores y distribuyen pagos de beneficios de muchos tipos. También cobran una variedad de impuestos y tarifas. El uso del comercio electrónico por parte de los gobiernos y agentes gubernamentales para realizar estas funciones a menudo se enmarca en el área de gobierno electrónico (e-government) (Scheneider, 2004). Cuando las empresas establecen relaciones legales o comerciales con las Entidades Gubernamentales, suministrando productos y servicios a los gobiernos a través de la Web, se está desarrollando un tipo de negociación denominado B2G (Empresas a Gobierno o Bussines to Government). En negociaciones de tipo B2G las empresas venden productos y servicios a gobiernos locales, estatales y federales. En general, el sector público ha sido más lento en adoptar el comercio electrónico respecto al sector privado. Esto, sin embargo, está cambiando lentamente como resultado de las iniciativas de gobierno electrónico orientadas a adaptar las contrataciones públicas y otras actividades a un ámbito online (Deborah Morley, 2009). La negociación B2G básicamente consiste en optimizar los procesos de negociación entre empresas y gobierno a través del uso de Internet. Proporciona transparencia en el desarrollo de convocatorias y licitaciones con una mayor rapidez en el desarrollo de los trámites, permitiéndole al gobierno encontrar los mejores precios y condiciones de pago. Es un proceso simple y estandarizado el cual ayuda a las Administraciones Públicas a ahorrar tiempo y dinero, accediendo eficientemente a la oferta de los proveedores, comparando productos y realizando pedidos en un marco de mayor transparencia de mercado. Generalmente se aplica a sitios o portales especializados en la relación con la administración pública. En ellos las instituciones oficiales (hacienda, contrataciones públicas, etc.) pueden ponerse en contacto con sus proveedores, y estos pueden agrupar ofertas o servicios. En una entidad municipal de gobierno, el Sector de Compras es una de las áreas más sensibles. Esta afirmación se sustenta en tres aspectos importantes que dicho sector debe considerar: Por un lado la minimización del tiempo que transcurre desde que un determinado sector efectúa el pedido de un producto en particular a la Oficina de Compras, hasta el momento en que éste es adquirido y entregado a dicho sector. El pedido de un producto (entiéndase elementos informáticos, insumos hospitalarios, mueblería, etc.) implica que el sector solicitante tiene la necesidad de contar con él para mantener un buen funcionamiento. Por lo tanto, un tiempo prolongado en su adquisición puede repercutir directa o indirectamente en la correcta atención de las necesidades de los ciudadanos. Por otro lado la eficiencia en obtener el producto que se adapte a las necesidades del sector solicitante, sin incurrir en elevados gastos que afecten a la contabilidad del Municipio. Generalmente, una Oficina de Compras adquiere productos que se ajusten exactamente a lo que se le pidió, luego de evaluar las ofertas de los diferentes proveedores por su precio. Por desconocimiento sobre el producto pedido, no se considera la posibilidad de negociar alternativas igualmente buenas, ya sea en características, precio, tiempo de la garantía, etc. Esto a su vez afecta a los proveedores limitando sus posibilidades de vender productos que le reporten un mayor grado de utilidad (por ejemplo, un artículo cuyo fabricante premie de alguna manera al proveedor que lo venda) sin que se alejen del requerimiento de compra original. Por último, otro aspecto importante es la disponibilidad. Existen compras urgentes que deben realizarse en cualquier momento del día, e incluso en cualquier día del año. En este contexto, contar con una herramienta informática de negociación automática B2G que logre optimizar considerablemente estos aspectos es una posibilidad inmejorable. Además debe permitir la interoperabilidad entre los múltiples sistemas heterogéneos con los que puedan contar los diferentes proveedores. Esto plantea desafíos que pueden ser abordados con sistemas distribuidos que posibiliten llevar a cabo negociaciones entre las partes. Mientras que los primeros sistemas informáticos eran entidades aisladas, sólo para la comunicación con sus operadores humanos, los sistemas informáticos actuales están generalmente interconectados entre sí, a través de una red en sistemas distribuidos amplios. Internet es el ejemplo obvio, y cada vez es más raro encontrar computadoras de uso comercial o en ámbitos académicos que no tengan la capacidad para acceder a Internet. Hasta hace poco tiempo, los sistemas distribuidos y concurrentes fueron vistos por muchos como estructuras extrañas y complicadas que eran mejor ser evitadas. El rápido y visible crecimiento de la Internet ha disipado esta creencia. Actualmente los sistemas distribuidos y concurrentes son esencialmente la clave en la informática comercial e industrial, y esto ha llevado a investigadores y profesionales a revisar los fundamentos mismos de la informática, en busca de modelos teóricos que reflejen mejor la realidad de la misma, principalmente como un proceso de interacción (Wooldridge M. , 2002). Esta constante búsqueda de modelos teóricos ha llevado a obtener sistemas cada vez más inteligentes. La tendencia creciente a la delegación e inteligencia implica la necesidad de construir sistemas informáticos que puedan actuar con eficacia en nuestro nombre. Esto a su vez involucra dos aspectos fundamentales. El primero es la capacidad de los sistemas para operar de forma independiente, sin la intervención directa del hombre. El segundo es la necesidad de que los sistemas informáticos puedan actuar de tal manera que representen nuestros intereses mientras interactúan con otros seres humanos o con sistemas de la misma índole. Estas tendencias, sumadas a las de interconexión y distribución, plantea en la ciencia de la computación convencional un desafío clave que ha llevado en las últimas tres décadas a que gran parte de la energía de los intelectuales en la materia se concentrara en el desarrollo de herramientas de software y mecanismos que permitan construir sistemas distribuidos con mayor facilidad y fiabilidad. Sin embargo, cuando se combina con la necesidad de que los sistemas puedan representar nuestros intereses, la distribución plantea otro problema fundamental. Cuando un sistema informático que actúe en nuestro nombre debe interactuar con otro sistema informático que representa los intereses de otro, probablemente pueda ocurrir que los intereses no sean los mismos. Por lo tanto se vuelve necesario dotar a estos sistemas con la capacidad de cooperar y llegar a acuerdos con otros sistemas. En conjunto, este estudio ha conducido a la aparición de un nuevo campo en la ciencia de la computación: los sistemas multiagente. La idea de un sistema multiagente es simple. Un agente es un sistema informático capaz de llevar a cabo una acción independiente en nombre de un usuario o propietario. En otras palabras, un agente puede averiguar por sí mismo lo que necesita hacer para satisfacer sus objetivos de diseño, en lugar de que se les diga de forma explícita lo que debe hacer en cada momento. Un sistema multiagente consiste de un número de agentes, que interactúan entre sí, típicamente por el intercambio de mensajes a través de algún tipo de infraestructura de red informática. Generalmente esta interacción se basa en objetivos y motivaciones muy diferentes. Por lo tanto, se requiere de la capacidad de cooperar, coordinar y negociar mutuamente, de la misma forma en que lo hacen las personas en la vida diaria. En resumen, los sistemas multiagente son un conjunto de agentes autónomos con tres características fundamentales: organización, coordinación y comunicación. La organización establece una jerarquía social de los agentes. La coordinación puede ser por cooperación y/o competición. La comunicación se realiza por medio de protocolos que permiten estructurar la interacción entre agentes. En este contexto, la negociación en interacciones humanas como medio para alcanzar decisiones conjuntas, ha sido objeto de investigación durante muchos años. Sus resultados han servido como base para la investigación de los procesos de negociación automatizados, esto es, los llevados a cabo por componentes software. En general, la negociación se puede ver como el proceso por el cual dos o más partes (negociación bilateral y multilateral respectivamente) pueden obtener una decisión conjunta. En el dominio del comercio electrónico, por ejemplo, se define negociación como el proceso por el cual dos o más entidades regatean multilateralmente sobre recursos con el propósito de alcanzar una ganancia conjunta (Beam & Segev, 1997). La negociación llevada a cabo por humanos es relativamente lenta y sub-óptima (es decir, no se obtiene el mejor resultado posible para todas las partes), de forma que la negociación automatizada cobra mayor interés. La negociación automática tiene lugar cuando la función de negociación la realizan sistemas computarizados como, por ejemplo, los agentes inteligentes. El proceso de negociación se puede entender como un tipo de interacción automática entre las distintas partes que mantienen propósitos y objetivos diferentes (Jennings & Narayanan, 2005). Aunque la negociación entre humanos es un proceso extremadamente complejo, los agentes que se encuentren llevando a cabo este proceso en un entorno automatizado no deben de incorporar dicha complejidad. Ciertamente, la unión de diversos agentes “sencillos” puede llegar a constituir un entorno que actúe de forma muy sofisticada (Beam & Segev, 1997). Fatima (Fatima, 2004) propone una definición muy simple de negociación en entornos multiagente: “La negociación es el medio por el cual los agentes se comunican y se comprometen a alcanzar acuerdos mutuamente beneficiosos.” En esta definición, se deja claro el hecho de que en los procesos de negociación se debe buscar un acuerdo que satisfaga a todas las partes involucradas. Es posible llegar a una situación en la que una negociación no tenga un final satisfactorio por el hecho de que alguna de las partes no esté de acuerdo con ninguna de las propuestas realizadas. Sin embargo, en la mayoría de los casos, esta es la situación menos deseada y, por tanto, siempre se busca llegar a buen término el proceso de negociación por medio de concesiones de las partes. Rahwan (Rahwan, 2004) plantea otra definición donde son resaltados otros elementos importantes del proceso de negociación en sistemas multiagente: “La negociación es una forma de interacción en la cual un grupo de agentes, con intereses conflictivos y un deseo de cooperar, intentan llegar a un acuerdo mutuamente aceptable en la división de recursos escasos.” En esta definición, se destaca la necesidad de que los agentes tengan un deseo en cooperar lo cual, tal y como se mencionó anteriormente, indica que el final menos deseado es aquel en el que las partes no alcanzan un acuerdo. Por otro lado, se utiliza el término recurso, en el sentido más amplio de la palabra, para identificar servicios, tiempo, dinero, artículos, etc. En general, la necesidad de negociar surge cuando se tiene que compartir el uso de uno de estos recursos. En conclusión, es importante tener en cuenta que no existe una solución válida para todos los problemas y dominios (Rahwan, 2004), sino que debe ser el diseñador quien, dependiendo de las condiciones en las que el proceso de negociación se vaya a producir, elija la técnica a aplicar en cada momento. Dada esta limitación y los requisitos a satisfacer para el desarrollo con éxito del entorno multiagente, resulta manifiesta la necesidad de encontrar una solución que permita a los agentes, dinámicamente y en tiempo de ejecución, determinar el mecanismo de negociación más apropiado para cada interacción que deba de producirse. 1.2 Solución propuesta En la presente tesis proponemos desarrollar una herramienta de negociación automática del tipo B2G, con la cual puedan satisfacerse los aspectos planteados en la introducción: minimización de los tiempos, compras eficientes, disponibilidad e interoperabilidad de los sistemas. A partir de esto, consideramos que un sistema multiagente que permita la negociación automática es la solución más apropiada. La solución propuesta se divide en dos partes: la primera consiste en la selección de un sistema de negociación automática. Partiendo del modelo de negociación seleccionado, se implementará un sistema multiagente donde los agentes representen al Sector de Compras (Comprador) y a los proveedores del municipio (Vendedor). En términos generales, el sistema se compondrá de una Web para la entidad Municipal, y un proceso vendedor que representa a los proveedores. Cada parte implica la creación de un agente inteligente el cual, a partir de su lógica de negociación, dialogará con la otra parte para intentar llegar a un acuerdo en común. Dada la necesidad de dotar a los agentes de la habilidad suficiente para dialogar y modificar sus preferencias durante el propio proceso de negociación, se seleccionó un modelo de negociación basado en restricciones difusas. Este mecanismo se basa en una forma de argumentación de propuestas fundada en la declaración parcial de preferencias o grados de satisfacción (López Carmona, 2006). En este sentido los modelos de preferencias basados en restricciones difusas, se presentan como una alternativa muy adecuada para solucionar el problema de la formalización y representación de preferencias. La solución elegida se basa en el trabajo propuesto por López Carmona (López Carmona, 2006) y consiste en estrategias de negociación automática basadas en restricciones difusas sobre sistemas multiagente. Esto implica la codificación de distintos protocolos de negociación, y las estrategias asociadas a los mismos, mediante el uso de ontologías, de forma que son los agentes quienes, en el momento que necesiten llevar a cabo una interacción, decidan qué mecanismo (esto es, qué protocolo y qué estrategia) desean utilizar. La segunda parte de la tesis consiste en integrar el sistema multiagente desarrollado en el ámbito de negociación entre una entidad municipal y sus proveedores. Para ello, se contrasta la metodología de trabajo actual de un Sector de Compras de una determinada municipalidad (entorno no negociado), con los beneficios que proporciona la utilización de nuestro sistema. Para la gestión de los agentes inteligentes se utilizará la plataforma multiagente de libre distribución Java Agent DEvelopment (JADE)1 (Bellifemine, Poggi, & Rimassa, 2001). Todo el desarrollo se llevará a cabo en Java. La flexibilidad que proporciona la plataforma JADE permite que cualquier proveedor que desee implementar su propio agente negociador, pueda hacerlo previo acuerdo del protocolo a utilizar. JADE es un entorno que simplifica la implementación de sistemas multiagente mediante una capa de soporte (middle-ware) que respeta las especificaciones FIPA 2 y con un conjunto de herramientas para el desarrollo y debugging. La plataforma JADE está escrita en el lenguaje Java y se compone de varios paquetes, proporcionando a los programadores módulos funcionales ya desarrollados e 1 En la sección 3.1.5 se detallan algunas de las características de la plataforma JADE, como así también de otras popularmente conocidas. 2 La Foundation for Intelligent Physical Agents (FIPA) es un organismo para el desarrollo y establecimiento de estándares de software para agentes heterogéneos que interactúan y sistemas basados en agentes. interfaces abstractas configurables. Java fue el lenguaje de programación elegido debido a sus múltiples ventajas, como su paradigma orientado a objetos en entornos heterogéneos distribuidos, la serialización de objetos y la invocación de métodos remotos (RMI), entre otras. El modelo que se implementa en la tesis emplea la noción de restricciones difusas en su núcleo (en particular, para determinar qué oferta debe ser enviada, si una oferta es aceptable, y que contra-oferta debe hacerse). De forma general, una restricción difusa puede entenderse como un conjunto de valores de un atributo al que se le asigna un determinado grado de satisfacción, de manera que este rango puede ser representado como un conjunto de valores, o como un término lingüístico que representa de forma abstracta un conjunto de valores (Xudong Luo, 2003). La mayor parte de los modelos de negociación bilateral automática asumen que los agentes tienen predefinidas las preferencias, y que éstas son estáticas. En otras palabras, los agentes han decidido a priori qué necesitan de los otros, y cómo diferentes acuerdos satisfacen estas necesidades. El problema se reduce entonces a una búsqueda que sea lo suficientemente satisfactoria para todos los agentes. Sin embargo, los agentes pueden empezar a negociar sin tener un conocimiento completo y preciso acerca de sus preferencias por acuerdos concretos. Un caso preciso viene dado por la aparición o desaparición de productos del catálogo de un proveedor, o por la evolución de las utilidades asignadas a cada producto como consecuencia de la existencia de factores externos, como por ejemplo el paso del tiempo. El objetivo es dotar a los agentes de la habilidad suficiente para que sean capaces de dialogar, y que puedan modificar sus preferencias durante el propio proceso de negociación. El mecanismo utilizado se basa por tanto en una forma de argumentación de propuestas fundada en la declaración parcial de preferencias o grados de satisfacción. 1.3 Esquema de la tesis La presente tesis se estructura en 6 capítulos. A continuación describiremos brevemente cada uno de ellos. En el capítulo 1: se presentó el ámbito de la tesis. Se introdujeron en forma general los conceptos que serán desarrollados en profundidad a los largo del trabajo. Tales son: negociaciones B2G, sistemas multiagente y negociación. En el capítulo 2: nos introducimos en los conceptos de negociaciones dentro de un ámbito municipal de gobierno. Vemos los diferentes tipos de negoción y cómo lentamente las entidades gubernamentales orientan su gestión hacia la utilización de tecnología. En el capítulo 3: desarrollamos en profundidad dos de los grandes pilares en los que se basa la presente tesis: sistemas multiagente y modelos de negociación. Los primeros son los encargados de poner en funcionamiento el modelo de negociación elegido. Para llegar a una correcta selección de un modelo adecuado para nuestro contexto, hacemos un repaso de los diferentes enfoques, analizando sus ventajas y desventajas. En el capítulo 4: nos enfocamos específicamente en el modelo de negociación basado en restricciones difusas. Comenzamos a definir cada componente del modelo: conocimientos del dominio para agente comprador y vendedor, mecanismos de decisión, locuciones y transiciones. En el capítulo 5: se aborda la instanciación del modelo elegido. Se explican los diferentes algoritmos y funciones utilizadas para la implementación de un sistema de negociación automática. A su vez, presentamos los detalles de diseño que derivaron en el desarrollo del sistema. En el capítulo 6: desarrollamos dos casos de estudio. El primero deja en evidencia los beneficios de la utilización de un sistema de negociación automática en un ámbito municipal de compra. El segundo caso presenta las diferentes variaciones en las duraciones de las negociaciones a medida que modifican los parámetros que definen a una negociación (cantidad de productos en el catálogo, número de atributos, etc.). En el capítulo 7: presentamos las conclusiones. Cuenta con un resumen general de toda la tesis, contribuciones, limitaciones y algunas propuestas para futuros trabajos. Capítulo 2 Comercio electrónico en un Municipio Todas las relaciones que se establecen entre una entidad de gobierno con su entorno (empresas, contribuyentes, empleados, etc.) pueden ser potenciadas con la utilización de la tecnología, orientando la gestión hacia un Gobierno Electrónico. Este nuevo paradigma lentamente está siendo adoptado en la medida en que los participantes comprenden sus amplios beneficios. En este capítulo presentaremos conceptos básicos sobre comercio electrónico y su aplicación en un ámbito municipal. 2.1 Introducción Una de las principales tendencias en las últimas décadas es la formación de una sociedad moderna interconectada basada en la adopción definitiva de la tecnología de la información y la comunicación (TIC). Los avances de la TIC se han percibido como uno de los responsables más importante en el cambio estructural de la sociedad. Sistemas basados en Internet, con un alto grado de estandarización y de bajo costo, han acelerado dicha reestructuración, tanto dentro de las organizaciones como entre ellas mismas. Desde motores de búsqueda web avanzados (por ejemplo, Google y Bing) a sistemas de gestión del conocimiento (como Wikipedia), de comunidades personales y sociales en línea (por ejemplo, blogs, Linked-in, Facebook y Twitter) a varias redes de comercio electrónico (como ser, B2B, C2C, B2C, etc.), nuestra estructura social y los estilos de vida han cambiado inevitablemente con el fin de hacer frente a los desafíos que las TIC e Internet nos traen (Liu, 2010). Organizaciones colaborativas e interconectadas pueden obtener beneficios que una sola organización difícilmente puede lograr. Un claro ejemplo son las cadenas de suministro modernas: la mayoría de las multinacionales e incluso algunas PYMES (pequeñas y medianas empresas) son capaces de desarrollar su planificación interrelacionando sistemas de recursos empresariales para hacer que la gestión de la cadena de suministro sea más eficiente y eficaz. Lento pero seguro, los gobiernos han estado participando en la reforma de la revolución de las redes y tomando un papel activo sobre todo en la primera década del siglo 21. Este movimiento se simboliza mediante la creación de muchos proyectos/programas de e-Government o Gobierno electrónico en los últimos años. El Gobierno electrónico se define como "la transformación de las relaciones internas y externas del sector público a través de las operaciones sobre redes, utilizando tecnología de la información y las comunicaciones hasta optimizar la prestación de servicios del gobierno, la participación electoral y la gobernabilidad". Además, el e-Government intenta tener centralizadas las operaciones que se encuentran dispersas para maximizar la eficiencia, la productividad y la prestación de servicios. Dado que los gobiernos obviamente tienen un limitado conjunto de productos para vender al público o empresas (comparado con el sector privado), podemos esperar ver más aplicaciones de comercio electrónico en áreas donde se producen intercambios de fondos: impuestos, licencias y permisos. Si bien la mayor parte de la actividad del sector privado en el que se modelan estos nuevos esfuerzos implica la entrega de bienes y servicios de “empresa a empresa”, su experiencia con actividades de “empresa a consumidor” puede ser utilizada como un modelo para mejorar las acciones de “gobierno a ciudadano” del sector público como así también el actual modelo dominante de “gobierno a empresa” y “empresa a gobierno” (Abramson & Means, 2001). Obviamente, una diferencia significativa entre los sectores público y privado es que el sector público principalmente intercambia información y no siempre cobran por ella, aunque también existen intercambios de bienes. Por tanto, la definición de comercio electrónico en el sector público no sólo debe contemplar la transferencia de bienes y servicios, sino que también debe incluir el intercambio de información. Una "brecha digital" se ha desarrollado entre las jurisdicciones del sector público. Las jurisdicciones más grandes (estados, las grandes ciudades) se están moviendo rápidamente en aspectos tecnológicos llevando la delantera y se encuentran entre los más innovadores, allanando el camino para los demás. Esto deja a las jurisdicciones más pequeñas retrasadas en la carrera por la prestación de servicios en línea y aplicaciones de comercio electrónico de gobierno. Mientras que uno de los beneficios del comercio electrónico en el sector privado es la posibilidad de extenderse más allá de las fronteras geográficas (para llegar a todo el mundo), las jurisdicciones del sector público se limitan a sus propias fronteras geográficas. Con un potencial mercado del cual beneficiarse, las empresas del sector privado son capaces de tomar ventaja de las nuevas tecnologías. Pueden contar con personal para mantener sus sitios web con la más reciente información, diseños, seguridad y metodologías de transacción. Los gobiernos, sin embargo, sólo sirven a sus propios ciudadanos y un área geográfica limitada. Excepto cuando las jurisdicciones son lo suficientemente grandes (estados), esto hace que el comercio electrónico sea menos eficiente que el de las empresas del sector privado. Es más difícil obtener beneficios a mayor escala y sobre un gran número de clientes. Los gobiernos también tienen restricciones adicionales. Estas incluyen la necesidad absoluta de confidencialidad de la información de los clientes, la necesidad de rendir cuentas a sus ciudadanos y la obligación de facilitar el acceso a todos ellos. Debido a estas restricciones, los gobiernos se han orientado más lentamente hacia el comercio electrónico que el sector privado, y es más probable que se encuentren transacciones de comercio electrónico en sitios web de sectores público más grandes, como son las agencias federales, los estados y las grandes ciudades. Pero aun así, en un período muy corto de tiempo, algunas de estas agencias federales, estados y ciudades han desarrollado aplicaciones muy innovadoras que proporcionan servicios útiles al público. El e-business o e-commerce ha sido un tema de gran preocupación para los gobiernos, empresas y ciudadanos por igual. Grandes cantidades de tiempo y esfuerzo se invierten en el examen de la mejor manera de hacer este tipo de transacciones eficientes, eficaces, y como un medio ampliamente aceptado de hacer negocios. Esto no es tarea fácil, pues aunque se da a entender que el comercio electrónico es una parte esencial de los desarrollos futuros de los negocios a nivel nacional e internacional, existe todavía poca evidencia para sugerir que hay una amplia aceptación de los consumidores de estos modos de realizar transacciones comerciales. La falta de confianza de los consumidores se ha centrado en la práctica sobre operaciones de negocios, los problemas de seguridad, y las dudas sobre qué leyes se aplican a las transacciones realizadas por vía electrónica a través de Internet (Cyber Law in Australia, 2010). 2.2 Gobierno electrónico y sus tipos Los gobiernos de todo el mundo están llevando a cabo una serie de iniciativas de gobierno electrónico para mejorar la eficiencia y eficacia de las operaciones internas, la comunicación con el público y la participación en los procesos transaccionales con los componentes individuales y organizacionales. A diferencia de los procesos de gobierno tradicionales, el gobierno electrónico está particularmente caracterizado por el uso extensivo de la tecnología de la comunicación, la naturaleza impersonal del entorno en línea, la facilidad con la que la información puede ser recolectada, procesada y utilizada por varios sectores, por la incertidumbre implícita en el uso de una infraestructura de tecnológica abierta y por lo novedoso del medio de comunicación. Los ciudadanos van a interactuar con un sitio web del Gobierno por lo que la información personal puede ser fácilmente recogida, manipulada y utilizada por múltiples sectores del mismo. La utilización de aplicaciones de gobierno electrónico aumenta la separación espacial y temporal entre los ciudadanos y el Gobierno. Existen en general ocho modelos de aplicaciones de gobierno electrónico. El primer tipo de Gobierno a Ciudadano (G2C) proporciona el impulso para poner los servicios públicos en línea, en particular a través de la prestación de servicios electrónicos para ofrecer información y comunicación. El tipo de Ciudadano a Gobierno (C2G) donde nuevamente las aplicaciones proporcionarán el impulso de poner los servicios públicos en línea, pero esta vez a través de la prestación de servicios electrónicos para el intercambio de información y comunicación. El modelo de Gobierno a Negocio (G2B) impulsa iniciativas de transacción tales como las contrataciones electrónicas y el desarrollo de mercados electrónicos para las compras del Gobierno. El cuarto tipo denominado de Negocio a Gobierno (B2G) es básicamente lo mismo que el modelo anterior, con el agregado de actividades de transacciones electrónicas, poniendo el foco en la venta de bienes y servicios por parte de las empresas. El modelo de Gobierno a Empleado (G2E) se embarca en iniciativas que faciliten la gestión de la administración pública y la comunicación interna con los empleados. El sexto modelo llamado de Gobierno a Gobierno (G2G) proporciona cooperación y comunicación en línea entre los departamentos gubernamentales. Por último, los modelos de Gobierno a Organizaciones no comerciales y viceversa (G2N y N2G) proporcionan información y comunicación para organizaciones sin fines de lucro, partidos políticos y organizaciones sociales. Nuestro trabajo de negociación automática se enfoca en un modelo de Negocio a Gobierno en un ámbito municipal, en donde las compras realizadas son directas. Es decir, sin necesidad de llevar a cabos procesos licitatorios. En la sección 5.1 describimos el proceso de compra directa. 2.2.1 Modelo de Negocio a Gobierno Básicamente este modelo contempla las iniciativas de Gobierno Electrónico destinadas a brindar servicios administrativos y de información a las empresas a través de Internet. Es importante considerar el tipo de empresa y el sector al que se está atendiendo, ya que la estrategia de desarrollo debe estar alineada con los intereses y las prioridades del sector privado mayoritario. Los beneficios que aportan estas iniciativas a las empresas son similares a los que consiguen los ciudadanos, en términos de ahorro de tiempo y dinero, y flexibilidad, además se pueden alcanzar importantes ahorros en sus costos administrativos, demostrar transparencia en la gestión pública, agilizar los procesos de licitaciones, entre otros (Naser & Concha, 2011). Las instituciones gubernamentales, que tienen como objetivo ofrecer servicios (usando innovaciones en tecnologías de la información) útiles y eficientes en un entorno en constante desarrollo, se enfrentan a un problema concreto relacionado con la transformación y los cambios en el sistema. El aumento de las relaciones comerciales entre las empresas nacionales e internacionales determina el fortalecimiento del papel del Estado y de sus instituciones en los procesos de negocio. La comunicación entre gobiernos y objetos de negocio es especialmente importante con el fin de garantizar la realización de los intereses del Estado y de la legalidad de los procesos de negocio. El Gobierno, así como los objetos de negocio que buscan una mayor eficiencia en su funcionamiento, utilizan tecnologías de la información innovadoras: crean sitios web, donde están disponibles los actos jurídicos y demás información relevante para los objetos de negocio. El modelo de Negocios a Gobierno describe la cooperación entre las organizaciones empresariales y el gobierno utilizando formas más comunes, como así también el uso de Internet. Hoy en día, en la mayoría de los países, este campo se supone como muy importante, ya que la declaración de los actos del Estado en Internet, enviando, recibiendo y registrando los diversos documentos de negocios utilizando tecnologías electrónicas permiten una comunicación más rápida, reduce los gastos de transacción y de coordinación gubernamental. El uso del modelo de Negocios a Gobierno estimula el desarrollo de la actividad de los estados en campos tan importantes para las empresas como la difusión de información, los impuestos, y otros. En la mayoría de los países los gobiernos coordinan sus actividades con las empresas utilizando canales tradicionales. Internet se utiliza como un recurso adicional para la difusión de información, pero en el futuro la mayoría de las instituciones deberían conceder más posibilidades para los temas relacionados con los negocios. Teniendo en cuenta el análisis de literatura académica, se pueden destacar las siguientes ventajas del modelo de Negocio a Gobierno: una mejor calidad de los servicios ofrecidos; eficacia de los gastos, mejorar las relaciones con representantes de las empresas y otras partes interesadas. El objetivo principal de la implementación de este modelo es conseguir la inmediata cooperación entre las empresas y el gobierno. En la red creada por el gobierno, se destacan tres tipos de servicios: servicio de información, servicio de relaciones y servicio de cooperación. El servicio de información se utiliza para conocer indirectamente los requerimientos de una persona u organismo. El servicio de relaciones está destinado a los mismos grupos de objetivos para proporcionar retroalimentación con ellos. Los servicios de información o de cooperación son ofrecidos principalmente por las instituciones del Estado. El servicio de cooperación permite a los representantes de las empresas y a las personas cooperar con el Gobierno, mientras éste realiza diversas operaciones oficiales (por ejemplo, informar acerca de posibles pérdidas ocurridas durante el transporte de mercancías de un país a otro). Mientras se utilice el modelo de Negocios a Gobierno, estas dos partes pueden comunicarse entre sí directamente, como así también con el uso de Internet. Como la mayoría de los representantes de las empresas desean comunicarse con el Gobierno utilizando Internet, esta forma de comunicación se torna complicada. Las grandes empresas por lo general tienden a utilizar los recursos interactivos y comunicativos creados por organizaciones estatales y aplicarlas a su sistema de negocio. Sin embargo, tales conexiones entre sistemas heterogéneos deben ser regularizadas muy bien para obtener el máximo beneficio. En resumen, es posible llegar a la conclusión de que la realización del modelo de Negocios a Gobierno está asociado a muchos aspectos: la base jurídica debe ser clara y correctamente definida, los sistemas de información deben ser regularizados, los intereses de las empresas asociadas deben estar constantemente coordinados. Sólo la aplicación coherente de este modelo puede garantizar sus posibles ventajas y un trabajo eficiente (Jovarauskienė & Pilinkienė, 2009). 2.3 Resumen general En la actualidad se percibe un intento de acercamiento hacia la utilización de tecnologías por parte de los gobiernos con el fin de obtener un mayor dinamismo en sus funciones. Cada vez es más frecuente encontrar una entidad de gobierno que cuente con su portal Web, en donde, en algunos casos, se permite efectuar una serie de trámites (emisión de facturas de pago de impuestos, registro de proveedores, obtención de turnos para determinadas atenciones, etc.). Esta “tecnologización” de la gestión pública de gobierno lo acerca al concepto de Gobierno Electrónico, permitiendo optimizar la prestación de servicios, la participación electoral y la gobernabilidad; y centralizando las operaciones dispersas a fin de maximizar la eficiencia y la productividad. Existen varios modelos de aplicaciones de gobierno electrónico. Nuestro interés se centra en el tipo de Negocio (o Empresa) a Gobierno o B2G, el cual proporciona servicios administrativos y de información a las empresas a través de Internet. Este enfoque aporta ahorros significativos en tiempo y costos, flexibilidad, eficiencia y transparencia. Si a estos beneficios les sumamos una alta disponibilidad, un mayor ahorro de tiempo y la posibilidad de comprar eficientemente y de forma beneficiosa para ambas partes, nos encontramos con que la implementación de un modelo B2G se convierte en una solución más que auspiciosa. Este enriquecimiento del modelo se logra automatizando operaciones, y más precisamente, las relacionadas con las compras. En el siguiente capítulo nos introduciremos en los conceptos de sistemas multiagente, los cuales permitirán llevar a cabo operaciones de compras en una entidad de gobierno con una mínima intervención humana. En base al intercambio de mensajes, los agentes inteligentes que componen el sistema efectuarán una negociación que maximice los beneficios de ambas partes. Por lo tanto, es importante analizar los diferentes modelos de negociación con el propósito de concluir en el que mejor se ajuste al contexto de compras de una entidad de gobierno, más precisamente el de una entidad municipal. Capítulo 3 Sistemas Multiagente y Modelos de Negociación El comercio electrónico en un ámbito municipal podría desarrollarse con la intervención humana a través del envío de correos electrónicos o la implementación de formularios Web estáticos. Evidentemente este enfoque carece de beneficios como la rapidez, disponibilidad y eficiencia que puede proporcionar la utilización de sistemas multiagente. Al seleccionar un modelo de negociación que facilite la especificación de los requerimientos de compra y obtenga resultados favorables para ambas partes, e implementar un sistema multiagente que lo ponga en funcionamiento, se obtienen múltiples beneficios operativos, como son la reducción de tiempo, compras eficientes, disponibilidad e interoperabilidad entre sistemas heterogéneos. 3.1 Agentes Inteligentes y Sistemas Multiagente A continuación abordaremos la teoría de dos componentes fundamentales en la presente tesis: por un lado los Agentes Inteligentes, y por el otro el agrupamiento de estos interaccionando entre sí, denominado Sistemas Multiagente. 3.1.1 Agentes inteligentes No existe una definición consensuada del término agente ni un acuerdo en cuanto a las propiedades que este tipo de entidades debe de presentar. El diseño de agentes inteligentes es una rama del mundo de la Inteligencia Artificial. En este dominio, una de las definiciones de agente más citadas es la establecida por Russell y Norvig (Russell & Norvig, 2004): “Un agente es cualquier cosa capaz de percibir su medioambiente con la ayuda de sensores y actuar en ese medio utilizando actuadores.” Esta definición se centra en el componente físico del término y en su interacción con el mundo que le rodea. Acercándose más a la parte funcional del concepto, una definición comúnmente aceptada es la propuesta por Wooldridge y Jennings (Wooldridge & Jennings, 1995), posteriormente adaptada por Wooldridge (Wooldridge M. , 2002): “Un agente es un sistema computarizado que está situado en algún entorno, y que es capaz de actuar de forma autónoma en este entorno para satisfacer sus objetivos de diseño.” En esta definición, ya se destacan algunas de las propiedades comunes que debe de poseer todo sistema compuesto por agentes, como son la autonomía y su localización en algún medio con el que tiene que interactuar. En la siguiente definición, Jennings (Jennings N. , 2001) señala otras características como la flexibilidad y la actuación en representación de otros, además de enfatizar nuevamente la idea de que todo agente realiza las acciones pertinentes con el único propósito de alcanzar objetivos predefinidos: “Los agentes son programas software que actúan flexiblemente en representación de sus propietarios para alcanzar objetivos particulares.” Un agente inteligente es básicamente un sistema basado en conocimientos que percibe su entorno (que puede ser el mundo físico, una persona a través de una interfaz gráfica de usuario, una colección de agentes, Internet u otro entorno complejo); razona para interpretar las percepciones, administrar interfaces, resolver problemas y determinar acciones; y actúa sobre el medio ambiente para lograr un conjunto de metas o tareas para las que fue diseñado. Interactúa con su entorno a través de algún tipo de lenguaje de comunicación de agente y no puede obedecer ciegamente a comandos, pero puede tener la capacidad de modificar la solicitud, hacer preguntas de aclaración, o incluso negarse a cumplir ciertas peticiones. Puede aceptar solicitudes de alto nivel que indican lo que el usuario quiere y decidir cómo satisfacer cada solicitud con un cierto grado de independencia o autonomía, exhibiendo conductas dirigidas a objetivos y elegir dinámicamente qué acciones tomar y en qué secuencia. Puede colaborar con el usuario para mejorar el cumplimiento de su tarea o puede llevarlas a cabo en su nombre, empleando algo del conocimiento o de la representación de los objetivos o deseos del usuario. Puede controlar los eventos o procedimientos por el usuario, asesorarlo sobre los conocimientos para llevar a cabo una tarea, o puede ayudar a los diferentes usuarios a colaborar (Tecuci, 1998). Agente sensor de entrada acción de salida Medio ambiente Figura 1 Agente inteligente y su interacción con el entorno La figura 1 proporciona una visión abstracta de un agente. En este diagrama, se puede ver la acción de salida generada por el agente con el fin de afectar a su medio ambiente. En la mayoría de los dominios de complejidad razonable, un agente no tendrá el control total sobre su entorno. Contará en el mejor de los caso de un control parcial, y que además podrá influir sobre él. Desde el punto de vista del agente, esto significa que la misma acción realizada dos veces en circunstancias aparentemente idénticas pueden parecer tener efectos completamente diferentes, y, en particular, no tener el resultado deseado. Así, los agentes deben estar preparados para la posibilidad de fracaso en todos los ambientes, pero más aún en aquellos que parecen triviales. Se puede resumir esta situación formalmente diciendo que se asume que los entornos en general son no deterministas. Normalmente, un agente tendrá un repertorio de acciones de las cuales dispone. Este conjunto representa la capacidad efectiva del agente: su habilidad de modificar sus entornos. Se debe tener en cuenta que no todas las acciones se pueden realizar en todas las situaciones. Por ejemplo, la acción “comprar un Ferrari” producirá un error si los fondos disponibles son insuficientes para ello. Las acciones por lo tanto tienen precondiciones asociadas que definen las situaciones posibles en las que pueden ser aplicadas. Aunque son similares, los agentes tienen características que no poseen los objetos como la autonomía, la cooperación, la percepción y la proactividad. La principal diferencia es que los objetos son pasivos, reaccionan a estímulos externos, pero no tienen metas que direccionen su comportamiento, como los agentes. Otra diferencia es que los agentes usan un lenguaje común entre todos los agentes, mientras que los mensajes entre los objetos dependen de las clases (Ortiz, López Gallego, & Oviedo Carrascal, 2009). 3.1.1.1 Propiedades de los agentes inteligentes Se pueden determinar cuatro propiedades fundamentales de los agentes inteligentes: Autonomía: los agentes actúan en nombre de otras entidades en forma autónoma. Ellos operan sin la intervención directa de los seres humanos u otros, y tienen algún tipo de control sobre sus acciones y estado interno. Habilidad social: los agentes utilizan un lenguaje de comunicación de agente para interactuar con otros agentes. Reactividad: los agentes perciben su entorno y responden de manera oportuna para cumplir con los objetivos propuestos. El entorno puede ser el mundo físico, un usuario, otros agentes, o la combinación de estas entidades. Klusch (Matthias Klusch, 2000) llama a esta característica cooperación social. Los agentes son capaces de cooperar en grupos con otros agentes y/o seres humanos cuando sea necesario. Pro-actividad: los agentes son capaces de exhibir comportamientos de iniciativa orientada a objetivos en lugar de simplemente responder a su entorno. Jennnings y Wooldridge (Wooldridge & Jennings, 1995) enriquecen estas propiedades y clasifican a los agentes según una noción débil o fuerte de agencia. En la noción débil de agencia, los agentes tienen voluntad propia (autonomía), pueden interaccionar entre ellos (habilidad social), responder a estímulos (reactividad), y tomar la iniciativa (pro-actividad). En la noción fuerte, se preservan las propiedades de agencia débil, pero, además, los agentes pueden moverse alrededor de una red (movilidad), son veraces (veracidad), hacen lo que se les dijo que hicieran (benevolencia) y consiguen realizar los objetivos propuestos de manera óptima (racionalidad). Por simplicidad se utilizará el término agente en el resto de la tesis, asumiendo su carácter inteligente y autónomo, su habilidad para interactuar con otros agentes o humanos, y su capacidad de percepción y actuación sobre su entorno. 3.1.1.2 Entorno de un agente El entorno de un agente se caracteriza, como se muestra en la figura 2, por las siguientes cuatro propiedades principales (Russell & Norvig, 2004): No determinista Continuo Entorno Dinámico Inaccesible Figura 2 Entorno de un agente inteligente • No determinista • Inaccesible • Dinámico • Continuo Puesto que un agente no tiene el control total sobre su entorno, su influencia es sólo parcial. Como se mencionó anteriormente, una acción realizada por un agente dentro de un entorno no tiene un efecto único garantizado y el estado resultante de esta acción es incierto. Por esta razón, los entornos del agente se suponen que son no deterministas. El entorno de Internet es cada vez menos accesible para los agentes a medida que más y más información está disponible en línea. Es imposible para los agentes obtener información precisa, completa y al día dentro de este entorno. Es cada vez más difícil construir agentes que pueden operar efectivamente dentro de este conjunto de información heterogénea. Por esta razón, la mayoría de los entornos reales son inaccesibles. Un entorno dinámico es aquel que tiene otros procesos que operan sobre el mismo, causando así su cambio de estado. Como resultado, este entorno está cambiando más allá del control del agente. En contraste, un entorno estático se supone que cambia sólo por las actuaciones del agente. La mayoría de los agentes se ubican en un entorno altamente dinámico y que cambian continuamente, como es el caso de la Internet. La distinción entre discreto y continuo se puede aplicar al estado del medio, a la forma en la que se maneja el tiempo y a las percepciones y acciones del agente. Por ejemplo, un juego de ajedrez es un medio con un número finito de estados, que lo convierten en un entorno discreto para un agente jugador. Un vehículo que debe moverse por un espacio compone un medio continuo, por contar con infinitas posibilidades. Puesto que un conjunto discreto está contenido dentro de uno continuo, se definen a los entornos como continuos. 3.1.2 Sistemas multiagente Los agentes pueden ser útiles como entidades independientes en entornos aislados a los que se les delegan ciertas tareas repetitivas y que se pueden automatizar en representación de unos determinados usuarios. Sin embargo, en la mayoría de los casos, los agentes se encuentran en entornos que contienen otros agentes constituyendo de este modo un Sistema Multiagente, esto es, un sistema constituido por un grupo de agentes que pueden interaccionar (Vlassis, 2003). Una definición más elaborada es la propuesta por el Laboratorio de Agentes Software Inteligentes (2001): “Un sistema multiagente es una red poco acoplada de agentes software que interaccionan para resolver problemas que van más allá de las capacidades o conocimiento individual de cada uno de los componentes que resuelven problemas.” Cuando un grupo de agentes individuales forma un sistema multiagente, surge la necesidad de disponer de un mecanismo para coordinar dicho grupo de agentes y de un lenguaje para permitir la comunicación entre ellos. Entre los mecanismos de coordinación, se pueden distinguir los casos en los que los agentes tienen objetivos comunes y, por tanto cooperan, de los casos en los que los agentes tienen intereses propios y que entran en conflicto con el de los demás, para lo cual se hace necesario dotarlos de mecanismos de negociación (Huhns, 1999). De forma análoga a esta clasificación, Wooldridge (Wooldridge M. , 2009) distingue entre sistemas distribuidos de resolución de problemas (constituidos por agentes diseñados explícitamente para conseguir de forma cooperativa un objetivo dado) y sistemas abiertos (donde confluyen agentes elaborados por distintos desarrolladores y que poseen posiblemente objetivos diferentes). En el caso de agentes cooperativos, los mecanismos de cooperación más comunes son las estructuras organizacionales, la planificación multiagente (centralizada y distribuida), redes de contratos y cooperación funcionalmente exacta. Por otro lado, para el caso de agentes competitivos, se hace necesario un mecanismo de negociación. Entre los tipos de mecanismos de negociación más utilizados en la literatura se destacan la formación de coaliciones, los mecanismos de mercados, la teoría del regateo, la votación, las subastas y la asignación de tareas entre dos agentes. Para que se pueda producir una comunicación efectiva entre los agentes, se han elaborado diversos lenguajes. Estos lenguajes fueron diseñados bajo la influencia de la Teoría de los actos del habla (Austin, 1962) (Searle, 1969). Esta teoría está basada, fundamentalmente, en la existencia de los denominados actos del habla o performativas (p.ej. solicitar, informar, prometer). Por tanto, las conversaciones se basan en estos actos del habla y proporcionan el potencial necesario para la coordinación, la cooperación y la negociación. La coordinación se puede definir como la manera en que los agentes se comportan individual y socialmente para que se satisfagan los objetivos personales y los globales. Por su parte, la cooperación puede verse como la actuación coordinada entre agentes de tal manera que unos colaboran, interesada o desinteresadamente, en la resolución de tareas de otros. Por último, la negociación es un proceso mediante el cual un grupo de agentes llegan a un acuerdo mutuamente aceptable sobre algún asunto. La construcción de sistemas multiagente integra tecnologías de distintas áreas de conocimiento. Por un lado la Inteligencia Artificial se ha ocupado de dar comportamientos inteligentes a los agentes basándose en actitudes como: racionalidad, coherencia y capacidad de adaptación. Por otro lado la Ingeniería de Software ha apoyado el desarrollo de metodologías orientadas a agentes por su relación tan cercana a la tecnología del objeto y a las metodologías orientadas al objeto. El término adoptado para estas metodologías es AOSE (Agent-Oriented Software Engineering). Las dos áreas mencionadas han dado gran impulso al desarrollo de los sistemas multiagente, promoviendo un proceso de formación de la computación orientada a agentes. 3.1.3 Comunicación de agentes Como se mencionó anteriormente, la capacidad de comunicación de los agentes es de vital importancia para que puedan llevar a cabo el fin para los cuales fueron diseñados. Un sistema multiagente no sería tal si los agentes que lo componen no tuvieran esta capacidad. Las partes con las que un agente puede desear comunicarse incluyen: • Su entorno. • Otros agentes. • Los usuarios. Los agentes se comunican con su entorno por diversos fines tales como determinar los recursos o servicios existentes, acceder a los datos, transferir los resultados, determinar la ubicación de otro agente, y otras razones similares. La comunicación entre los agentes es de gran importancia para diversas situaciones, como ser compartir información, realizar consultas a otros agentes, y para coordinar las actividades entre ellos, lo que les permitirá trabajar en colaboración. Los agentes deben tomar las peticiones de los usuarios y comunicarles los resultados. Esta es una de las tareas principales de los agentes de interfaz. Otros agentes pueden registrar sus datos con el agente de interfaz el cual entrega la información "tal cual es" o pre-procesada. Esta información puede ser recogida de diversos agentes y organizada en un formato que es conveniente para la visualización por parte del usuario. 3.1.3.1 Lenguajes de comunicación Si dos o más agentes desean comunicarse entre sí, deben compartir un lenguaje común. El lenguaje utilizado por los agentes en las comunicaciones se llama lenguaje de comunicación del agente (ACL). Las características deseables de los lenguajes de comunicación entre agente (Finin, Labrou, & Mayfield, 1995) se relacionan con: 1) la forma 2) el contenido 3) la semántica 4) la aplicación 5) las redes 6) el entorno 7) la fiabilidad La forma del lenguaje debería ser sencilla y lineal (o es conveniente que pueda ser fácilmente traducida a una forma lineal) a causa del mecanismo de transporte utilizado. Un lenguaje de comunicación entre agentes debe ser declarativo y legible por las personas. Su sintaxis debe ser simple y extensible, ya que tiene que ser integrado en diversos sistemas. El lenguaje de comunicación que expresa actos comunicativos tiene que ser separado del lenguaje de contenido que expresa hechos sobre el dominio. Un enfoque de capas que separe el lenguaje de comunicación del de contenido ayuda a lograr este propósito, ya que permite la integración exitosa del lenguaje con las aplicaciones, y además proporciona un marco conceptual para la comprensión del lenguaje. Independientemente de la aplicación, por ejemplo una base de datos orientada a objetos o una base de conocimientos, debe ser especificado un conjunto de primitivas que capturen la mayor parte de los actos comunicativos. Este conjunto de primitivas de actos comunicativos necesita ser extensible para permitir que el lenguaje sea utilizado por una variedad de sistemas. Al igual que en cualquier otro lenguaje, la semántica de un lenguaje de comunicación debe basarse en un marco teórico, ser clara y mostrarse en la forma canónica (la similitud en un significado debe conducir a una similitud en la representación). A medida que el lenguaje de comunicación permite la interacción entre aplicaciones dispersas en un espacio, y esta interacción se extiende a lo largo del tiempo, el espacio y el tiempo necesario deben ser abordados por la semántica de un lenguaje de comunicación. Las partes que se comunican deben tener una comprensión compartida del lenguaje, y además, sus primitivas y protocolos asociados deben ser formalmente descritos. La implementación de un lenguaje de comunicación debe acoplarse bien a la tecnología actual de software. La aplicación del lenguaje también tiene que ser eficiente. La interfaz debe poder ser fácilmente utilizada por las capas de red que se encuentran por debajo de los actos comunicativos primitivos que son ocultos para el usuario. Como algunos agentes pueden requerir sólo un subconjunto de los actos comunicativos primitivos, debería ser posible la aplicación parcial del lenguaje. Un lenguaje de comunicación de agente debe actuar con eficiencia en un entorno muy distribuido, heterogéneo y dinámico. Por otra parte, debería posibilitar la aplicación de funciones tales como la interoperabilidad con otros lenguajes y protocolos, y permitir el descubrimiento de conocimiento en redes de gran tamaño. Tiene que ser fácilmente acoplable a los sistemas heredados existentes. Tiene que permitir una comunicación fiable y segura. El lenguaje debe ser compatible con la autenticación de los agentes, así como identificar y señalar los errores y las advertencias. Los lenguajes de comunicación entre agentes más destacables son KQML (Knowledge Query and Manipulation Language), KIF (Knowledge Interchange Format) y FIPA-ACL (FIPA Agent Communication Language). KQML se ocupa de definir un formato común para los mensajes sin meterse en el contenido de los mismos (Finin, Labrou, & Mayfield, 1995). Cada mensaje en KQML está formado por una performativa que define el tipo de mensaje y un conjunto de parámetros (p.ej. contenido, remitente, receptor). KIF es un lenguaje que permite representar conocimiento sobre un determinado dominio del discurso (Genesereth & Fikes, 1992). KIF es usado, principalmente, para formar la parte del contenido de mensajes KQML. FIPA-ACL es similar a KQML en tanto que define el formato de los mensajes sin preocuparse ni implicar el uso de un lenguaje específico para el contenido de los mensajes (FIPA, 2002b). 3.1.4 Ontologías Una de las cuestiones importantes de la que no hemos hablado hasta el momento ha sido la de ontologías. El tema de las de ontologías surge por la siguiente razón. Si dos agentes desean entablar una comunicación acerca de algún dominio, entonces es necesario que se pongan de acuerdo sobre la terminología que utilizarán para describir este dominio. Por ejemplo, supongamos el caso en que un agente está comprándole a otro agente un artículo en particular, como ser una tuerca o tornillo: el comprador debe ser capaz de especificar de forma inequívoca al vendedor las propiedades deseadas del elemento, tales como su tamaño. Los agentes por tanto, necesitan ser capaces de ponerse de acuerdo tanto en lo que significa "tamaño", como así también el significado de 'pulgadas' o 'centímetro'. Una de las definiciones más citadas es la enunciada por Gruber (Gruber, 1993): “Una ontología es una especificación explícita de una conceptualización.” El autor considera que una conceptualización está compuesta por objetos, conceptos y otras entidades que existen en una determinada área, y las relaciones que se dan entre ellos. Por explícita, se entiende que los conceptos y las restricciones se definen de forma explícita. La definición de Gruber fue posteriormente refinada por Borst (Borst, 1997) de la siguiente manera: “Una ontología es una especificación formal de una conceptualización compartida.” En este contexto, formal se refiere a la necesidad de disponer de ontologías comprensibles por las aplicaciones informáticas. Por otro lado, compartida enfatiza la necesidad de consenso en la conceptualización, refiriéndose al tipo de conocimiento contenido en las ontologías, esto es, conocimiento consensuado y público. Studer y sus colegas (Studer, Benjamins, & Fensel, 1998) se encargaron de fusionar las definiciones de Gruber y Borst, llegando a la siguiente conclusión: “Una ontología es una especificación formal y explícita de una conceptualización compartida.” Cabe aclarar que no existe una definición consensuada de ontología, por lo tanto, se puede entender a qué se refiere enumerando los elementos que la componen. En general, las ontologías proporcionan un vocabulario común de un área y definen, a diferentes niveles de formalismo, el significado de los términos y relaciones entre ellos. El conocimiento en ontologías se formaliza principalmente usando seis tipos de componentes: clases, atributos, relaciones, funciones, axiomas e instancias (Gruber, 1993): Una clase puede ser algo sobre lo que se dice algo, como por ejemplo un tipo de objeto, la descripción de una tarea, función, acción, estrategia, proceso de razonamiento, etc. Las clases en la ontología se suelen organizar en taxonomías. En todo caso, cabe destacar que ontología y taxonomía son dos elementos diferentes, aunque algunas veces la noción de ontología se diluye en el sentido que las taxonomías se consideran ontologías completas (Studer, Benjamins, & Fensel, 1998). Se suelen usar indistintamente los términos clase y concepto. Los atributos representan la estructura interna de los conceptos. Atendiendo a su origen, los atributos se clasifican en específicos y heredados. Los atributos específicos son aquellos que son propios del concepto al que pertenecen, mientras que los heredados vienen dados por las relaciones taxonómicas en las que el concepto desempeña el rol de hijo y, por tanto, hereda los atributos del padre. Los atributos vienen caracterizados por el dominio en el cual pueden tomar valor. Las relaciones representan un tipo de interacción entre los conceptos del dominio. Se definen formalmente como cualquier subconjunto de un producto de n conjuntos, esto es: R: C1 x C2 x…x Cn. Entre los distintos tipos de relaciones posibles, se encuentran las relaciones taxonómicas (“es_un”) y las mereológicas o partonómicas (“parte_de”) como relaciones binarias más destacadas. Las funciones son un tipo especial de relaciones en las que el n-ésimo elemento de la relación es único para los n-1 precedentes. Formalmente, definimos las funciones (F) como: F: C1 x C2 x…x Cn-1 → Cn. Como ejemplos, se pueden mencionar las funciones “madre de” y “precio de un coche usado”. Los axiomas son expresiones que son siempre ciertas. Pueden ser incluidas en una ontología con muchos propósitos, tales como definir el significado de los componentes ontológicos, definir restricciones complejas sobre los valores de los atributos, argumentos de relaciones, etc., verificando la corrección de la información especificada en la ontología o deduciendo nueva información. Por último, las instancias son las ocurrencias en el mundo real de los conceptos. En una instancia todos los atributos del concepto tienen asignado un valor concreto. 3.1.5 Plataformas de desarrollo de sistemas multiagente Existen variedades de plataformas que difieren en el tipo de lenguaje utilizado (FIPA y/o KQML), si soportan movilidad de código, en la arquitectura base de la plataforma, los tipos de agentes soportados, el lenguaje de desarrollo, entre otros. A continuación haremos un repaso de algunas de ellas. 3.1.5.1 JADE (Java Agent DEvelopment Framework) Como mencionamos en el capítulo 1, JADE es un entorno que simplifica la implementación de sistemas multiagente mediante una capa de soporte (middleware) respetando las especificaciones FIPA. La plataforma puede ser distribuida en varias máquinas (las cuales no necesitan compartir el mismo sistema operativo) y la configuración, que puede ser controlada mediante una interface gráfica remota, incluso puede ser cambiada en tiempo de ejecución (por ejemplo, moviendo agentes de una máquina a otra, cuando es necesario). La arquitectura de comunicación ofrece mensajes flexibles y eficientes. El modelo de comunicación de FIPA se ha implementado en forma completa y sus componentes han sido claramente especificados y completamente integrados: protocolos de interacción, ACL (Agent Communication Language), lenguaje de contenido, esquemas de codificación, ontologías y finalmente protocolos de transporte. Muchos de los protocolos de interacción de FIPA están disponibles y pueden ser instanciados después de definir las dependencias de cada estado del protocolo. Cuenta con soporte para lenguajes de contenido y ontologías definidas e implementadas por el usuario que automáticamente son utilizadas por el Framework. 3.1.5.2 JADEX El sistema de agentes JADEX es una extensión de JADE, enfocada en los protocolos orientados a objetivos. JADEX tiene por objeto facilitar el desarrollo de sistemas multiagente introduciendo nociones abstractas tales como creencias, metas y planes. Proporciona una arquitectura estable y un Framework de programación para agentes orientados a objetivos, que utilizan tecnologías ya consolidadas como XML y Java. JADEX se basa en el modelo BDI. Son las siglas de creencias (Beliefs), deseos (Desires) e intenciones (Intentions), que son componentes mentales presentes en muchas arquitecturas de agentes. Las creencias representan el conocimiento del agente, los deseos representan los objetivos y las intenciones otorgan deliberación al agente. 3.1.5.3 JACK JACK provee un entorno de desarrollo orientado a agentes construido sobre Java y completamente integrado con este lenguaje de programación. Incluye todas las componentes del entorno de desarrollo de Java así como también ofrece extensiones específicas para implementar el comportamiento de los agentes. La relación entre JACK y Java es análoga a la relación entre los lenguajes C++ y C, JACK fue desarrollado para proveer extensiones al lenguaje Java orientadas a agentes. El código JACK es primero compilado a código Java regular antes de ser ejecutado. El lenguaje JACK Agent hace más que extender la funcionalidad de Java, además provee un entorno para soportar un nuevo paradigma de programación. Este lenguaje es orientado a los agentes y es utilizado para implementar sistemas de software orientados a agentes. Todas las formas en las que extiende a Java, son implementadas como plugins, lo que permite que el lenguaje sea lo más extensible y flexible posible. Les extensiones son las siguientes: Define nuevas clases base, interfaces y métodos. Provee extensiones a la sintaxis de Java para soportar clases orientadas a agentes. Provee extensiones semánticas para soportar la ejecución del modelo. 3.1.5.4 ZEUS El objetivo del proyecto ZEUS es facilitar el rápido desarrollo de nuevas aplicaciones multiagente mediante la abstracción de los principios y componentes más comunes a una herramienta. La idea es proveer una herramienta de propósito general y personalizable, que permita la creación de agentes colaborativos y que pueda ser usada por ingenieros de software con poca experiencia en tecnología de agentes para crear sistemas multiagente. Para esto es necesario cumplir con los siguientes principios: La herramienta debe permitir separar el problema de nivel de dominio y la funcionalidad de nivel de agente. La herramienta debe estar basada en el paradigma de programación visual. La herramienta debe soportar un diseño abierto para asegurar que sea fácilmente extensible. Se debe utilizar tecnología “estandarizada” siempre que sea posible. Los agentes deben ser deliberativos en el sentido de que deben explícitamente razonar acerca de sus acciones en términos de qué metas seguir, cuándo considerar nuevas metas y cuándo abandonar metas existentes. Es más, el requerimiento del comportamiento dirigido por metas implica que el agente solo seleccionaría acciones que espera de alguna manera lo acerque a la meta deseada. Sólo se descartan metas cuando, no son alcanzables o las motivaciones para alcanzar dicha meta ya no se verifican. 3.2 Modelos de negociación En las secciones anteriores señalamos que en un sistema multiagente debe existir una comunicación efectiva entre sus integrantes. Esto llevó a la elaboración de diferentes lenguajes diseñados en base a los actos del habla o performativas. Las conversaciones que pueden producirse dentro de un sistema multiagente se basan en estos actos del habla y permiten, entre otras cosas, llegar a un acuerdo mutuamente aceptable sobre algún asunto. Esto último se denomina Negociación, y compone otro de los pilares fundamentales de la presente tesis. Partiendo de los principios de la teoría de negociación, haremos un estudio de los diferentes conceptos y técnicas que nos llevará a la elección del mejor modelo que se aplique a nuestro marco de negociación automática en el contexto de un ámbito municipal, más precisamente en sus operaciones de compra. El diseño debe cumplir con una serie de requerimientos. En primer lugar, las soluciones deben ser justas para ambas partes. En segundo lugar, ambas partes deben tratar de maximizar su propia rentabilidad en el transcurso de una negociación. Así, si el oponente no puede aceptar una oferta entonces el que llevó a cabo la propuesta debe esforzarse por encontrar una alternativa que tenga el mismo valor que la misma (por ejemplo, el agente puede variar los valores de los distintos atributos de negociación). En otras palabras, un agente debe evitar hacer una concesión, siempre que sea posible, ya que esto disminuye su rentabilidad en la operatoria. Por otra parte, cuando un agente tiene que hacer una concesión debe ser lo mínima posible. En tercer lugar, es importante que los agentes minimicen la cantidad de información revelada sobre sus preferencias, ya que cualquier revelación puede debilitar su posición negociadora. Hay una gran diversidad de propuestas en cuanto a modelos y protocolos de negociación se refiere, abarcando gran parte de los desafíos que plantea la negociación. Estos modelos se pueden clasificar de acuerdo a diferentes criterios (Buttner, 2006), como pueden ser su estructura, la dinámica del proceso de negociación, o las restricciones temporales o de información del escenario. Haciendo una clasificación asentada en los fundamentos teóricos del modelo, se pueden encontrar enfoques basados en teoría de juegos, enfoques heurísticos y enfoques basados en argumentación. Los enfoques basados en teoría de juegos tratan de encontrar soluciones óptimas desde el punto de vista analítico, basándose en el análisis de condiciones de equilibrio (Nash, 1950). Estos modelos son sólidos desde el punto de vista matemático, pero su uso práctico está muy restringido debido a los supuestos de los que parte: recursos ilimitados, racionalidad perfecta e información completa. En los enfoques basados en heurísticas estas suposiciones se relajan, y los participantes tratan de encontrar una solución aproximada de acuerdo a los principios de razonamiento limitado mediante el uso de técnicas de búsqueda y evaluación heurísticas. En las negociaciones basadas en argumentación, se añade a los agentes la capacidad de razonar sus posturas incluyendo un nivel de metainformación que permite utilizar promesas, recompensas, amenazas y otras formas de incentivos (Rahwan, 2004). 3.2.1 Componentes de un modelo de negociación Los cuatro componentes de un modelo de negociación son los siguientes: 1- El protocolo de negociación. 2- Las estrategias de negociación. 3- La información de estado de los agentes. 4- El equilibrio de la negociación. El protocolo especifica las reglas para el encuentro de los participantes en la negociación. Es decir, define las circunstancias en las que la interacción entre los agentes se lleva a cabo, qué ofertas se pueden hacer y qué secuencias de ofertas están permitidas. En general, los agentes deben alcanzar un acuerdo sobre el protocolo de negociación a ser utilizado antes que la negociación propiamente dicha comience. Un protocolo de negociación se puede diseñar para el manejo de uno o múltiples atributos. Para las negociaciones de múltiples atributos, se puede disponer de protocolos que negocian cada uno de ellos a la vez o todos juntos. Una estrategia de negociación para un agente es una especificación de la secuencia de acciones (por lo general ofertas o respuestas) que este tiene previsto realizar durante la negociación. Normalmente habrá muchas estrategias que son compatibles con un protocolo en particular, cada uno de los cuales puede producir un resultado diferente. Por ejemplo, un agente podría conceder en la primera ronda o negociar muy duramente a lo largo de la negociación hasta que el tiempo de finalización sea alcanzado. De ello se deduce que la estrategia de negociación que emplea un agente es fundamental para el resultado de la negociación. También debe quedar en claro que las estrategias que funcionan bien con ciertos protocolos no necesariamente lo hacen con otros. La elección de una estrategia a utilizar es por tanto una función no sólo de las características específicas del escenario de negociación, sino también del protocolo en uso. La información de estado de un agente describe el conocimiento que este tiene sobre las bases de la negociación tal como si fuera una partida o juego entre sus participantes. Von Neumann y Morgenstern (von Neuman & Morgenstern, 1944) introdujeron una clasificación fundamental para estos juegos: de información completa y de información incompleta. La primera categoría es básica. En estos juegos se supone que los jugadores conocen toda la información relevante acerca de las reglas del juego y las preferencias de los jugadores (representadas por funciones de utilidad). En la segunda categoría, la información puede carecer de una variedad de factores para el problema de negociación. Así, cada jugador puede tener alguna información privada acerca de su propia situación que no está disponible para los demás jugadores, y a su vez sólo contar con datos probabilísticos sobre la información privada de los demás. Harsanyi (Harsanyi, 1968) propuso que los modelos de juegos de información incompleta partan del supuesto de que todos los jugadores empiezan con la misma distribución de probabilidad sobre esta información privada y que estos antecedentes son de conocimiento común. Así, los jugadores no sólo tienen antecedentes sobre la información privada de los demás, también saben lo que a priori los otros participantes conocen acerca de su propia información privada. Los modelos estratégicos de información incompleta incluyen por lo tanto un mayor nivel de detalle, ya que no solo se especifican las acciones y la información disponible a los otros jugadores en el transcurso de la negociación, sino también sus distribuciones de probabilidad e información antes del inicio de la misma. Un mecanismo de negociación consiste en un protocolo de negociación junto con las estrategias de negociación de los agentes implicados. Tiene que ser estable (es decir, un perfil estratégico debe constituir un equilibrio), y el concepto más cercano para tal propósito es el de equilibrio de Nash para juegos de ofertas simultáneas. Dos estrategias se encuentran en equilibrio de Nash si la estrategia de cada agente es la mejor respuesta a la estrategia de su oponente. Esta es una condición necesaria para la estabilidad del sistema donde ambos agentes actúan estratégicamente. Para protocolos de ofertas secuenciales, el concepto de equilibrio de Nash se ve fortalecido en varias formas, al exigir que las estrategias mantengan el equilibrio a cada paso del juego. En resumen, la racionalidad en un mecanismo de negociación requiere que cada agente va a seleccionar una estrategia de equilibrio cuando se elige de forma independiente. Ante esto, se establecen los siguientes criterios principales para evaluar el resultado de equilibrio: 1- Unicidad. Si la solución del juego de negociación es única, entonces se puede identificar de manera inequívoca. 2- Eficiencia. Un acuerdo es eficiente si no hay pérdida de utilidad (es decir, el acuerdo es Pareto-óptimo). Un resultado es Pareto-eficiente si no hay otro resultado que mejore la rentabilidad de un agente sin hacer que empeore la de otro agente. Todas las soluciones Pareto-eficientes son preferibles a aquellas que no lo son. 3- Simetría. Un mecanismo de negociación se dice que es simétrico si no trata de manera diferente a los jugadores sobre la base de criterios inapropiados. Puntualmente lo que constituye a los criterios no apropiados depende del dominio específico. Por ejemplo, si el resultado de la negociación sigue siendo el mismo independientemente de qué jugador comienza el proceso de negociación, entonces se dice que es simétrico con respecto a la identidad del primer jugador. 4- Distribución. Esta propiedad está relacionada con la cuestión de cómo los beneficios del comercio se reparten entre los jugadores, ¿el resultado debe surgir de dividir las ganancias por igual entre los comerciantes o tiene que favorecer a un agente más que a otro? 3.2.2 Teoría de juegos La teoría de juegos es una rama de la economía que estudia las interacciones estratégicas entre agentes egoístas (Osborne & Rubinstein, 1994). La palabra agente se emplea aquí en su sentido más amplio, y puede referirse tanto a un agente económico (por ejemplo un comprador) como a un agente software. Por interacciones estratégicas se entiende que son aquellas en que el éxito de la toma de decisiones de un agente depende también de las decisiones que tomen el resto de los agentes implicados. Los agentes se consideran egoístas cuando buscan maximizar su propio interés. El trabajo teórico fundamental sobre teoría de juegos se origina en el campo de la economía por parte de Neuman y Morgenstern (von Neuman & Morgenstern, 1944), si bien la primera aplicación de este trabajo teórico al estudio de las interacciones estratégicas entre agentes se puede encontrar en (Rosenschein & Zlotkin, 1994). De forma general, y para el marco de la negociación automática, la teoría de juegos puede aplicarse a dos problemas bien diferenciados: el diseño de protocolos de interacción entre agentes y el diseño de estrategias para los agentes. El diseño de protocolos (también llamados mecanismos de interacción) abarca la definición de las reglas de encuentro entre agentes, es decir, el conjunto de reglas que gobiernan la interacción. El objetivo es encontrar mecanismos que satisfagan una serie de propiedades, como pueden ser la garantía de éxito, la estabilidad, la incentivo-compatibilidad (incentive compatibility) o la simplicidad (Sandholm, 1999). Por otro lado, el diseño de estrategias (también llamadas mecanismos de decisión) se refiere a la especificación de las acciones que debe llevar a cabo un agente ante cada una de las situaciones que pueden darse en el transcurso de la negociación. La propiedad deseable en el caso de las estrategias es la optimalidad (por ejemplo que el agente en cada caso lleve a cabo la acción que le lleva a maximizar su propio beneficio). Esta optimalidad en la definición de estrategias se delimita mediante distintos tipos de equilibrio, como son las estrategias dominantes, el equilibrio Nash y el equilibrio perfecto en subjuegos (Kraus, 2001b). El uso de teoría de juegos para la resolución de problemas de negociación tiene indudables ventajas, como son la solidez matemática y el carácter analítico de sus propuestas y resultados. No obstante, algunos de los supuestos de los que parte la teoría de juegos limitan su aplicabilidad a problemas de negociación reales (Jennings, Sycara, & Wooldridge, 1998b). En primer lugar, los modelos de teoría de juegos asumen que los agentes tienen racionalidad ilimitada, esto es, que no existen costes computacionales asociados a la búsqueda de acuerdos. Esta suposición es evidentemente inalcanzable en entornos de computación real. Por otro lado, los enfoques basados en teoría de juegos también suelen asumir que el espacio de soluciones es completamente conocido para los agentes, así como que cada agente conoce la utilidad que le proporciona cada posible solución. En escenarios de negociación complejos, donde el número de atributos que se negocian es elevado y cada atributo toma valores de un conjunto de cardinalidad elevada o incluso infinita, la evaluación de todos los posibles acuerdos puede ser un problema computacionalmente intratable. Otra suposición general es la de información completa, que alude al hecho de que las preferencias de cada agente son conocidas por el resto de agentes implicados en la negociación. En entornos reales competitivos, es usual que los agentes participantes no deseen revelar completamente su información de preferencias al resto de los negociadores, por lo que esta suposición también es inadecuada para muchos entornos. Por último, la teoría de juegos busca estrategias óptimas bajo la suposición de que todos los demás agentes actúan racionalmente (tratando de maximizar su utilidad de la manera más óptima posible). En escenarios reales, con agentes heterogéneos, esta suposición tampoco es necesariamente cierta. Estas limitaciones hacen que la teoría de juegos no sea un enfoque adecuado para la resolución de problemas de negociación en determinados escenarios, para los que será necesario emplear aproximaciones alternativas. 3.2.3 Enfoques basados en heurísticas Los enfoques basados en heurísticas surgen como un modo de afrontar las limitaciones concernientes a los enfoques basados en teoría de juegos (Jennings N. , 2001). En entornos reales, existe un coste asociado a la computación y a la toma de decisiones, y por ello la búsqueda exhaustiva de soluciones hasta encontrar una solución óptima no es factible. Los enfoques heurísticos tienen como objetivo, por tanto, la consecución de soluciones suficientemente buenas. Los mecanismos que se emplean dentro de los enfoques heurísticos son muy variados, aunque suelen ser aproximaciones de los métodos de teoría de juegos o implementaciones de modelos de negociación humanos (Raiffa, 1982) (Faratin, 2000). Existen diferentes enfoques heurísticos al problema de la negociación en la literatura. Sandip Sen (Sen, 1997) aplica un enfoque de negociación heurística al escenario de la planificación de reuniones. Faratin, Sierra y Jennings proponen una serie de métodos heurísticos para un escenario de negociación bilateral multiatributo. El protocolo de negociación es un intercambio posicional, en el que los agentes se envían mutuamente posibles soluciones al problema. Los sucesivos envíos de propuestas se controlan mediante heurísticas, que modulan las exigencias de los agentes en función del tiempo, de la disponibilidad de recursos o del comportamiento del oponente (Faratin, Sierra, & Jennings, 1998). Asimismo, definen mecanismos para la búsqueda de soluciones de compensaciones (trade-offs) basados en criterios de similaridad entre ofertas. La principal ventaja de los enfoques basados en heurísticas al problema de la negociación radica en que los modelos heurísticos se basan en suposiciones realistas en cuanto al coste computacional y a la disponibilidad de información se refiere, por lo que pueden aplicarse en escenarios en los que la teoría de juegos no es adecuada. No obstante, es necesario tener en cuenta que, debido a que los enfoques heurísticos no exploran el espacio completo de soluciones, con esto se obtienen a menudo soluciones subóptimas. Por otro lado, los modelos basados en heurísticas carecen de la elegancia y de la solidez matemática de la teoría de juegos, por lo que la justificación de dichos modelos debe efectuarse por medio de evaluaciones extensivas de carácter empírico. Otra limitación de los enfoques heurísticos es que, como en la teoría de juegos, se asume que los agentes conocen o saben lo que quieren. En otras palabras, los agentes tienen una forma correcta y precisa de calcular la calidad de los resultados o soluciones de una negociación, normalmente mediante el uso de funciones numéricas de utilidad. Este requerimiento no puede ser siempre satisfecho, en cuyo caso se necesitan técnicas alternativas. 3.2.4 Enfoques basados en argumentación Los diferentes enfoques al problema de la negociación citados anteriormente se basan en un intercambio de propuestas. Estas propuestas en general denotan un único punto dentro del espacio de soluciones, y la única realimentación que un agente recibe con respecto a una propuesta que ha hecho es la aceptación, el rechazo o una contrapropuesta (Jennings, Faratin, Lomuscio, Parsons, Sierra, & Wooldridge, 2001). Los enfoques basados en argumentación buscan añadir flexibilidad al proceso de negociación permitiendo a los agentes intercambiar metainformación que justifique o razone sus posturas dentro de la negociación. Esta metainformación se denomina argumento, y puede ir orientada tanto a justificar la postura del agente que lo emite como a influir en la postura del agente que lo recibe (Jennings, Parsons, Noriega, & Sierra, 1998a). Por ejemplo, ante una determinada propuesta de un agente A, un agente B puede decidir rechazarla y justificar su rechazo alegando que un atributo supera un determinado umbral. Este argumento puede hacer que el agente A busque nuevas soluciones que satisfagan el umbral impuesto por B (reduciendo de este modo el espacio de búsqueda). Por el contrario, puede ser que A decida hacer una nueva propuesta que tampoco satisfaga el umbral de B, pero añadiendo a esta propuesta un argumento con la esperanza de hacerla más atractiva para A. Los argumentos pueden ser de muy diversos tipos (Sycara, 1989) (Kraus, Sycara, & Evenchick, 1998), pero en general encajan en tres categorías: amenazas, recompensas y alegaciones. La principal ventaja de la negociación basada en argumentación es la posibilidad de que los agentes alteren sus puntos de vista como resultado de los argumentos recibidos. Este hecho, unido al efecto reductor del espacio de búsqueda que tiene el intercambio de metainformación, hace que se incremente la probabilidad de alcanzar un acuerdo, así como la calidad del mismo (Buttner, 2006). Los marcos de negociación basados en argumentación son cada vez más populares, debido a su capacidad potencial de generar diálogos flexibles con los que definir procesos de negociación más eficientes. El gran inconveniente sin duda alguna de estos enfoques radica en su tremenda complejidad, mucho mayor normalmente que otros enfoques. Requiere el diseño de complejos protocolos y lenguajes de comunicación, lenguajes de dominio muy sofisticados, y la implementación de procesos de evaluación y generación de argumentos que por definición son tareas que presentan gran dificultad. La implementación práctica en escenarios de comercio electrónico reales queda todavía muy lejos, aunque se vislumbra un gran potencial a más corto plazo en la aplicación de formas de argumentación más básicas, como las basadas en la declaración de preferencias. Enfoques Basados en Teoría de juegos Ventajas Desventajas Solidez matemática y un carácter Complejidad para ser aplicada en analítico de sus propuestas y escenarios de negociación reales. resultados. Busca soluciones óptimas. Asume que el espacio de soluciones es conocido. Altos costes computacionales. Basados en heurística Aplicable a escenarios de negociación Soluciones subóptimas al no reales. Bajo costes computacionales. explorar el espacio completo de soluciones. Modelos carentes de solidez matemática basados en evaluaciones empíricas. Basados en argumentación Añaden flexibilidad al proceso de Alta complejidad: protocolos y negociación permitiendo a los agentes lenguajes de comunicación intercambiar información adicional sofisticados. Dificultad en la para justificar su postura o influenciar implementación de procesos de la del otro. evaluación y generación de argumentos. Tabla 1 Ventajas y desventajas de los enfoques basados en teoría de juegos, heurística y argumentación 3.2.5 Enfoques basados en restricciones difusas Independientemente del escenario de aplicación o del tipo de técnica utilizada, el modelado de preferencias, utilidades, o grados de satisfacción, es una componente fundamental en cualquier sistema de negociación automática. Dado que los participantes en una negociación desean maximizar de alguna manera su beneficio, la especificación de un modelo de preferencias que permita interoperar con los mecanismos de decisión de los agentes de forma eficiente es un aspecto clave (López Carmona, 2006). En este sentido los modelos de preferencias basados en restricciones difusas se presentan como una alternativa muy adecuada para solucionar los problemas de la formalización y representación de preferencias. En el modelo propuesto por López Carmona (López Carmona, 2006) se emplea la noción de restricciones difusas en su núcleo (en particular, para determinar qué oferta debe ser enviada, si una oferta es aceptable, y que contra-oferta debe hacerse). 3.2.6 Resumen Luego de analizar los diferentes enfoques de negociación detalladamente, optamos por utilizar el modelo de negociación automática basado en restricciones difusas para un ámbito municipal de compras. Esta decisión se sustenta en las siguientes razones: 1) En muchos casos, los compradores desconocen los detalles exactos del producto que desean comprar, y más aún en un ámbito municipal donde la Oficina de Compras no conoce sobre todas las posibles categorías de productos que le pueden ser solicitados. Por lo tanto, sus necesidades se expresan a menudo como restricciones sobre múltiples atributos. Por ejemplo, consideremos el caso de una solicitud a la Oficina de Compras para la adquisición de un televisor para la visualización de turnos en la guardia pediátrica del Hospital Municipal. Ya que el sector no es experto en tecnología de televisores no puede comunicarle a un determinado proveedor qué es exactamente lo que quiere, pero, naturalmente, puede expresar sus necesidades a través de algunas restricciones (por ejemplo, un televisor de gran tamaño, de bajo costo, y en lo posible con buena calidad de imagen). 2) Cuando los compradores y vendedores negocian, no es común el caso de que una oferta sea completamente aceptable o completamente inconsistente con sus respectivas restricciones. Más bien, por lo general una oferta satisface una parte de las restricciones del comprador. Por ejemplo, una oferta del proveedor, un televisor de 24 pulgadas a $2500, en parte puede satisfacer el requerimiento de compra, porque aunque su tamaño no es grande, su bajo precio se ajusta a lo que se destinó para dicha compra y hace que la oferta siga siendo igual de aceptable. Evidentemente un televisor más grande sería más aceptable aún. Las restricciones difusas son ideales para la captura de las limitaciones de este tipo debido a que pueden ser parcialmente satisfechas o insatisfechas. De hecho, las limitaciones del Sector de Compras son restricciones difusas. 3) Para un solo atributo del producto deseado, un comprador podría preferir ciertos valores por encima de otros (por ejemplo, para el tipo de televisor, se prefiere uno con tecnología “LED” por sobre un “LCD”). Tal preferencia se puede expresar como una restricción difusa sobre un solo atributo, y el nivel de preferencia a un determinado valor del atributo es el grado de satisfacción de la restricción para ese valor. Del mismo modo, para los productos de múltiples atributos, un comprador podría preferir ciertas combinaciones de valores por sobre otros (por ejemplo, para el tamaño y precio de un televisor, se prefiere “grande y barato” por sobre “pequeño y caro”). Tal preferencia se puede expresar como una restricción difusa sobre ambos atributos, y el nivel de preferencia a un valor de cierta combinación de estos atributos determinarse con el grado de satisfacción de la restricción para el valor de combinación. 4) Una de las cuestiones fundamentales de la negociación es la de representar las compensaciones (trade-offs o balances) entre los diferentes valores posibles para los atributos. Las preferencias del comprador sobre el balance entre los diferentes atributos del producto deseado pueden ser modeladas por restricciones difusas. Por ejemplo, consideremos la compensación de un agente que surge de decidir si prefiere obtener exactamente el valor deseado de un atributo que es muy importante o un conjunto de valores no tan buenos para atributos que son menos importantes para él. Esta compensación puede ser modelada por una restricción difusa. Por ejemplo, volviendo al escenario de la compra de un televisor, supongamos que el tamaño es lo más importante, haciendo que el precio y la calidad de imagen sean atributos más flexibles. Supongamos ahora que el tamaño ideal es de 42 pulgadas, y que el costo de $9000 y una calidad de imagen media son aceptables. Sin embargo, si el tamaño fuera de 32 pulgadas, el precio de $4000 y una calidad de imagen muy alta, este televisor sería todavía aceptable. Para estas combinaciones de valores de atributos, simplemente se asigna el mismo grado de satisfacción (la restricción difusa es sobre los atributos tamaño, el valor y la calidad de imagen). Si hay alguna otra compensación, la preferencia de la Oficina de Compras para estos casos puede ser modelada mediante la asignación de diferentes grados de satisfacción (el valor más grande para el más preferible). 3.3 Resumen general Los sistemas multiagente son una gran herramienta para el desarrollo de negociaciones sin la intervención humana. Cada agente que compone el sistema percibe su entorno, que para nuestro contexto de B2G puede ser la escases de algún artículo en particular, y en base a su capacidad pro-activa poder iniciar una negociación sin recibir orden alguna. Cada agente inteligente componiendo un sistema multiagente debe disponer de un mecanismo para su coordinación, y de un lenguaje que permita la comunicación entre ellos. Existen diversos lenguajes comunicación diseñados en base a la Teoría de los actos del habla, particularmente en las performativas (por ejemplo, informar, confirmar, prometer). El utilizado por los agentes en las comunicaciones se llama lenguaje de comunicación del agente (ACL). Otro componente importante para la comunicación de agentes son las ontologías, que no son otra cosa que un acuerdo dentro de un sistema multiagente acerca de la especificación de los conceptos utilizados. Por ejemplo, la negociación de una impresora implica que las partes sepan qué atributos la definen, y a su vez, conocer que las páginas por minuto se definen en unidades y el consumo eléctrico en vatios. La plataforma elegida para implementar el sistema multiagente es JADE y sus principales características (Bellifemine, Poggi, & Rimassa, Developing multi-agent systems with a FIPA-compliant agent framework, Software - Practice and Experience, 31, 2001) que motivaron su utilización son: Plataforma de agentes distribuida. La plataforma de agentes se puede dividir entre varios hosts. Cada uno de ellos puede ejecutar una sola aplicación Java, y por lo tanto, una sola máquina virtual de Java. Los agentes se implementan como hilos (threads) Java y son alojados dentro de los Contenedores de Agentes los cuales proporcionan el soporte necesario para la ejecución de cada agente. Interfaz gráfica de usuario para gestionar varios agentes y contenedores desde un host remoto. Suporte para la ejecución de múltiples actividades de los agentes en forma concurrente a través del modelo de comportamiento. Plataforma de agentes compatible con el estándar FIPA, que incluye el AMS (Sistema de Gestión de Agente), el DF (Facilitador de Directorio), y el ACC (Canal de Comunicación de Agente). Todos estos tres componentes se activan automáticamente en el arranque de la plataforma. Transporte eficiente de mensajes ACL dentro de la misma plataforma de agentes. De hecho, los mensajes se transfieren codificados como objetos Java, en lugar de cadenas de texto, con el fin de evitar la implementación de procedimientos de clasificación de mensajes. Al traspasar los límites de la plataforma, el mensaje es convertido automáticamente a sintaxis compatible con FIPA, con su codificación y su protocolo de transporte. Esta conversión es transparente para los desarrolladores que sólo necesitan trabajar con objetos Java. Soporte para la definición de lenguajes de ontologías y contenido que se ajusten a la aplicación que se está desarrollando. El otro componente importante en la presente tesis es el modelo de negociación, base fundamental para definir el protocolo, las estrategias, la información de estado y equilibrio de la negociación llevada a cabo por cada agente dentro del sistema. Existen diferentes tipos de modelos, basados en algún enfoque particular. Los modelos de negociación basados en teoría de juegos, definidos bajo sólidos conceptos matemáticos, busca soluciones óptimas, tornándolos complejos para su aplicación en escenarios reales. Los basados en enfoques heurísticos son más simples de aplicar en contextos reales, pero dejan fuera de consideración soluciones de la negociación debido al intento por reducir los costes computacionales, por lo que el resultado final es una solución alejada de la óptima. Los modelos de negociación basados en argumentación son una buena alternativa, ya que su funcionamiento se sustenta en los actos del habla al intercambiar información adicional para justificar la postura de los participantes, aportándole flexibilidad; lamentablemente esto conlleva a una alta complejidad en la definición de los protocolos y los lenguajes de comunicación, como así también la evaluación y generación de argumentos. En este punto aparece un cuarto tipo de modelo basado en restricciones difusas, las cuales se emplean para determinar qué oferta enviar, si una oferta es aceptable y que contra-oferta efectuar. Obtiene las ventajas de los enfoques argumentados, pero potenciándolas con la flexibilidad que aporta la utilización de restricciones difusas. En el siguiente capítulo analizaremos en profundidad los modelos de negociación basados en restricciones difusas. Capítulo 4 Modelo de negociación basado en restricciones difusas Como mencionamos en el capítulo anterior, los modelos de negociación basados en restricciones difusas resultan ventajosos en un ámbito de gobierno donde la definición de los requerimientos de compra recae en personas ajenas a la especialidad del artículo a comprar. Sumado a los beneficios de contar con negociaciones más cercanas a lo que podría ser un diálogo real entre el Municipio y las empresas. Esto conlleva a la definición formal del modelo y a dotar a los agentes inteligentes de una mayor capacidad expresiva. 4.1 Introducción En el capítulo anterior analizamos los diferentes enfoques al problema de la negociación automática y determinamos que los basados en teoría de juegos, heurística y argumentación carecen de las virtudes necesarias para ser aplicados en un dominio de compras en un ámbito municipal. Eso derivó en inferir como una buena opción la utilización de un modelo de negociación automática basado en un enfoque de restricciones difusas. Para ejemplificar la utilización del modelo, planteamos un escenario de negociación bilateral entre un municipio y un proveedor. Estos entablan un diálogo negociador sobre la compra de una impresora, definida a partir de características o atributos los cuales serán negociados a través del diálogo. La entidad compradora, en este caso el municipio, no conoce con exactitud lo que quiere, solo tiene una idea aproximada sobre los valores de los atributos, por lo que resulta práctica la utilización de restricciones difusas para expresar formalmente de una manera más natural sus necesidades. El comprador expresa su deseo de compra indicando que “quiere adquirir una impresora de alta calidad, con un alto número de páginas por minuto impresas (PPM) y a un precio muy bajo” 3. Los atributos negociables son la calidad, el número de páginas por minuto y el precio; y a su vez, están acotados bajo restricciones difusas, lo que implica que no existe un intervalo específico para cada uno de ellos que determina el cumplimiento o no de las restricciones. Por contraposición, una formulación de preferencias de compra mediante restricciones estrictas o duras (crip) sería del tipo: “deseo una impresora con un nivel de calidad de 8 sobre 10, un valor de PPM de entre 15 y 25, y un precio entre $400 y $800”. Para este caso se observa que una posible negociación tendría un final por lo menos rápido, ya que las restricciones se cumplen o no. Pero se pierde la flexibilidad que proporciona una negociación real. El proveedor cuenta con una definición del catálogo de productos perfectamente especificados. Dicho catálogo es flexible en el sentido de que puede ir variando tanto la disponibilidad de los productos como sus atributos durante la negociación. En la figura 3 se presentan las preferencias de compra del municipio. En el eje vertical se observan los tres atributos negociables, cada uno de ellos dividido en una escala que mide el valor difuso del atributo a través de un término lingüístico. En el eje horizontal se determina el nivel de satisfacción que le reporta cada asignación de valores difusos a los atributos. Así por ejemplo, partiendo de la asignación que mayor satisfacción le reporta al comprador, en una posible concesión los atributos afectados serían la calidad y/o la cantidad de PPM (disminuyendo en menor medida el grado de satisfacción, que si se relajase el precio). 3 Evidentemente debe haber un acuerdo entre las partes para entender, por ejemplo, cuándo un precio es bajo. A pesar de que las restricciones difusas están definidas por términos lingüísticos, debe existir un consenso sobre los valores aproximados que definen dicho intervalo difuso. Figura 3 Evolución del grado de satisfacción para una entidad municipal En la figura 4 puede observarse el catálogo de productos con que cuenta el proveedor. Cada fila determina un producto, con los valores de sus atributos declarados como intervalos difusos, y las utilidades que el proveedor consigue a partir de la venta de cada uno de ellos Productos Calidad PPM Precio Utilidad Impresora 1 Alto Bajo Muy bajo Alto Impresora 2 Alto Medio Bajo Alto Impresora 3 Bajo Muy bajo Medio Medio Impresora 4 Medio Alto Muy alto Bajo Figura 4 Catálogo del proveedor A continuación se ejemplifica el funcionamiento del modelo a partir de un posible diálogo negociador entre el municipio y el proveedor. Comprador Más importante Quiero: Muy alto Muy alto Muy bajo Calidad PPM Precio Vendedor ¿Puede relajar la calidad o el PPM? 1 Más importante Quiero: Muy alto Alto Muy bajo Calidad PPM Precio ¿Nuevamente puede relajar la calidad o el PPM? 2 Quiero: Más importante Más importante Alto Alto Muy bajo Calidad PPM Precio ¿Puede relajar el PPM o el precio? 3 Más importante Quiero: Alto Alto Bajo Calidad PPM Precio ¿Puede relajar el PPM? 4 Más importante Quiero: Alto Medio Bajo Calidad PPM Precio Le vendo la Impresora 2 Atributo más importante Atributo degradado Figura 5 Diálogo negociador En el diálogo, desplegado en la figura 5, observamos dos características importantes del modelo: en primer lugar el comprador no solamente tiene capacidad de emisión de requerimientos en forma de restricciones, sino que además, dichas restricciones se pueden valorar de forma subjetiva; en segundo lugar el vendedor tiene la capacidad de matizar su rechazo a ofrecer un producto, haciendo uso de locuciones que expresan preferencias de relajación explícitas al respecto de las restricciones emitidas por el comprador. En lugar de enfocar el proceso de negociación según la forma tradicional mediante la defensa de posiciones, es decir, adoptando una determinada posición negociadora, se negocia sobre la base de los intereses de las partes, intereses que subyacen a las posiciones que las mismas suelen adoptar en el proceso de negociación (López Carmona, 2006). Analicemos ahora el curso del diálogo. 1. La primera propuesta del comprador es la que subjetivamente le podría reportar mayor satisfacción. La propuesta está definida como un conjunto de restricciones duras extraídas del requerimiento original del comprador en donde se expresa como restricciones difusas. La restricción Muy bajo para el precio remite una importancia debido a que una relajación del mismo provoca un mayor decremento en el grado de satisfacción para el comprador. Esto se puede observar en la figura 3 en donde decrementar la calidad o el PPM no tienen el mismo impacto en el nivel de satisfacción como lo tiene el precio. A partir del catálogo del vendedor vemos que no cuenta con un producto que satisfaga todas las restricciones. Sin embargo, argumenta el rechazo con una contra propuesta basada en preferencias. Evidentemente el vendedor no conoce cuál es el o los atributos más importantes para el comprador, por lo tanto su propuesta de relajación se basa en criterios como podría ser la “cercanía” de la propuesta de compra a algún producto con el que cuente, entre otros criterios. 2. La segunda propuesta del comprador ha implicado la relajación de la restricción de PPM. Dado que el vendedor no tenía una preferencia expresa porque se relajase una restricción más que otra, el comprador opta por relajar una de las restricciones que menor pérdida de satisfacción comporta (calidad o PPM) de forma aleatoria. La restricción precio sigue siendo la más importante por el mismo motivo que en el caso anterior: una relajación de Muy bajo a Bajo produce una baja considerable en el nivel de satisfacción para el comprador. El vendedor de acuerdo a sus preferencias vuelve a solicitarle la relajación de una de las restricciones de calidad o PPM. 3. En la tercera parte del diálogo el comprador relaja la restricción de calidad. Esta nueva propuesta determina un razonamiento por parte del vendedor que vale la pena analizar. Como puede observarse en el catálogo existen dos productos que se acercan a los requerimientos de la propuesta: la impresora 1 y 2. Ambos reportan utilidades aceptables. Para lograr un mayor acercamiento, la restricción a relajar debería ser la de PPM o la de precio. 4. En la cuarta propuesta del comprador la restricción relajada fue la de precio, y resulta lógico debido a que la de PPM era una de las restricciones importantes junto con la de calidad. En este punto el vendedor determina una gran proximidad a la impresora 2, por lo tanto rechaza la propuesta solicitando una relajación de la restricción de PPM. 5. El comprador, tras recibir la propuesta de relajación, se encuentra con que a priori, no tendría inconveniente en relajar la restricción de PPM. El vendedor dispone de un producto que sí cumple los requisitos actuales: la impresora 2. La negociación termina satisfactoriamente. Una vez analizado el ejemplo, intuimos que la utilidad de este tipo de aproximación al problema de la negociación bilateral puede encontrarse también de forma muy concreta en escenarios de comercio electrónico dinámicos, donde los modelos de preferencias de compradores y vendedores se vean modificados incluso durante el propio curso de la negociación. El hecho de incluir en la comunicación metainformación referente a las preferencias parciales de los participantes, puede permitir que en el transcurso de la negociación, ésta se pueda reconducir hacia zonas del espacio de negociación donde aparezcan las nuevas intersecciones. 4.2 Modelo de preferencias del comprador y vendedor Según la teoría de marketing la preferencia de un comprador por un producto será función del valor que tome cada uno de sus atributos, y evidentemente, de la interpretación subjetiva que el comprador haga de ese valor. Además, cada consumidor asignará una importancia relativa a cada uno de los atributos. La decisión de compra de un consumidor puede ser modelada por tanto como una función de diferentes combinaciones de atributos (Keeny & Raiffa, 1976). Los modelos de toma de decisiones de compra asumen que el proceso exhaustivo de evaluación de productos se lleva a cabo sobre un subconjunto reducido denominado conjunto de consideración (Hauser & Wernerfelt, 1990). Este conjunto de consideración se entiende como aquel conjunto de productos que superan los umbrales predefinidos para uno o más atributos. Estos umbrales son los mínimos requisitos que todo producto debe cumplir para que sea tenido en consideración a la hora de pasar a la fase de selección del producto preferido. Estos atributos que tienen definidos unos umbrales mínimos para la inclusión en el conjunto de consideración se denominan no compensatorios. Esto significa que un valor por debajo del umbral no puede compensarse con valores de otros atributos. Se distinguen dos enfoques fundamentales en la definición de un modelo de preferencias para un comprador: por un lado la división del proceso de extracción de preferencias en dos fases, una de inclusión y otra de selección, y por el otro la fusión de las dos fases en una mediante la adaptación de los umbrales de inclusión en el modelo de decisión compensatorio. El primero requeriría de un diálogo previo que estableciese los criterios de inclusión de forma explícita. De esta forma el diálogo excluiría automáticamente aquellos productos no pertenecientes al conjunto de consideración. El segundo enfoque no requiere de un diálogo previo porque los criterios de inclusión están implícitos en el modelo de preferencias único, y son aplicables durante todo el proceso negociador. En el modelo de negociación utilizado se optó por aplicar este segundo enfoque en base a que la primera alternativa es trivial en cuanto a la declaración explícita de criterios de inclusión; y además porque utilizar argumentación permite que la valoración subjetiva de los atributos sea declarada de forma explícita, lo que puede permitir que un atributo sea tenido en cuenta por el vendedor como un criterio de inclusión. El modelo de decisión del vendedor es más sencillo que el modelo del comprador, a efectos de declaración de preferencias. Cada agente vendedor dispone de un conjunto variable de productos que desea vender. Cada uno de los productos está definido por un conjunto de atributos, separados en atributos visibles y no visibles. Un atributo es visible si es negociable, es decir, pertenece al espacio de negociación. Un atributo es no visible, si no es negociable. Tanto los atributos visibles como los no visibles pueden influir en la percepción del vendedor acerca de la preferencia que tenga por realizar una venta concreta en un determinado momento. Esta preferencia se va a modelar como una función de utilidad que no tiene por qué ser invariable ni en el tiempo ni para cada producto. Esto último significa que de forma determinista el vendedor podría asignar a un producto una cierta utilidad independientemente de las utilidades de otros productos atendiendo a cualquier criterio. La idea de aplicar estas suposiciones es permitir la definición de un catálogo tan flexible como se quiera. Por último hay que dejar claro que el precio no tiene por qué ser el único criterio de utilidad, es decir, la venta de un producto muy caro no tiene por qué implicar una utilidad mayor. Incluso la utilidad no tiene por qué estar asociada a los atributos del producto. 4.3 Problemas de satisfacción de restricciones (CSP) El núcleo de los modelos de preferencias del comprador y vendedor consta de definiciones formales que permiten describir su funcionamiento. A continuación describimos los problemas de satisfacción de restricciones (CSP) como un paso previo a la definición de los problemas de satisfacción de restricciones difusas (FCSP). Definición 4.3.1. Un problema de satisfacción de restricciones o constraint satisfaction problem (CSP) (Yokoo, 2001) es una tupla (X, D, C), donde: 1. X xi i 1,..., n es un conjunto finito de variables. 2. D di i 1,..., n es un conjunto de dominios. Cada dominio di es un conjunto finito que contiene los posibles valores para las correspondientes variables xi en X. 3. C Ri Ri x j var( Ri ) d j , i 1,..., m es un conjunto de restricciones. En este caso var(Ri) define el conjunto de variables incluidas en una determinada restricción Ri: varRi x1' ,..., x'k R X i Definición 4.3.2. Una etiqueta de una variable x es una asignación de un valor a la variable, llamada vx. Una etiqueta compuesta vX´ de todas las variables del conjunto X ' x1' ,..., x'n X es una asignación simultánea de valores a todas las variables del conjunto X´: vX' vx ' ,..., vx ' 1 n Definición 4.3.3. En un CSP(X, D, C), la función característica de Ri C, Ri : xjvar Ri dj 0,1, se define como: R vvar( R i i ) si vvar( Ri ) Ri , 1 0 el resto. Una solución al CSP(X, D, C) es una etiqueta compuesta vX = (vx1,..., vxn) de todas las variables en X tal que: Ri C , Ri vvar( Ri ) 1 En definitiva, una restricción sólo permite dos posibilidades, que esta se cumpla o que no se cumpla. Una solución debe satisfacer todas las restricciones. Sin embargo, esta representación de restricciones es excesivamente rígida. Este es el motivo por el que se introduce el CSP difuso (Dubois, Fargier, & Prade, 1994). 4.4 Problema de satisfacción de restricciones difusas (FCSP) Como mencionamos en la sección anterior, un problema de satisfacción de restricciones es un enfoque muy rígido, en el sentido de que una solución debe cumplir todas las restricciones. Para flexibilizar esta representación aparece el concepto de problemas de satisfacción de restricciones difusas (FCSP). A continuación presentamos su definición. Definición 4.4.1. Un problema de satisfacción de restricciones difusas o fuzzy constraint satisfaction problem (FCSP) es una tupla (X,D,Cf), donde X y D son los mismos que para el caso de los CSP, y Cf es un conjunto de restricciones difusas: C f Ri R f : x var( R f ) d j 0,1, i 1,..., m f i j i f donde var( Ri f ) designa el conjunto de variables incluidas en Ri . Utilizando una técnica de corte de matemática difusa (Klir & Yuan, 1995), una restricción difusa puede incluir una restricción dura. Definición 4.4.2 (Nivel de corte y extracción de una restricción dura) Dado un nivel de corte 0,1, la extracción de una restricción dura Rc a partir de una restricción difusa Rf implica que: R vvar( R c f ) 10 , si R f var R f el resto. Este nivel de corte no es más por tanto que un umbral. Si el nivel de satisfacción sobrepasa este umbral, la solución es satisfactoria. Finalmente es necesario definir una medida de satisfacción global de las restricciones, dada una etiqueta compuesta. 4.4.3 Definición (Grado de satisfacción global) El grado de satisfacción global de una etiqueta compuesta vX se define como: vX R (vX ) R f C f f donde es un operador de agregación de [0,1]n a [0,1]. El operador que hemos utilizado en la presente tesis es min. 4.5 Conocimiento del dominio de los agentes A continuación se presentan las conceptualizaciones de los agentes comprador y vendedor basadas en la definición de un conjunto de requerimientos genéricos que se van a plasmar en un modelo de requerimientos. Este desarrollo se fundamenta a partir de la tesis doctoral de López Carmona (López Carmona, 2006). En dicho trabajo, a modo experimental, introduce el concepto de perfil del agente. Agentes comprador y vendedor cuentan con dicho perfil, que a su vez se divide en perfil expresivo y perfil receptivo. La configuración de estos perfiles permite observar la contribución de un marco de negociación automática basado en argumentación, respecto del no argumentado (o inexpresivo). No intentaremos desarrollar un estudio exhaustivo sobre ambos modelos, por lo tanto optamos por instanciar un marco de negociación automática expresivo. De todas formas, en la presentación de los conceptos subsiguientes, se mencionan dichos perfiles a modo de demostrar la flexibilidad del modelo. 4.5.1 Conocimiento del dominio del agente comprador Como se mencionó en gran parte de la tesis, es de suma importancia la extracción de preferencias de los agentes negociadores, y la formalización de dichas preferencias. Esto concluyó en que un modelo de definición de preferencias basado en restricciones difusas era muy conveniente para el caso de un agente comprador. En este sentido, uno de los aspectos fundamentales en la definición de un modelo de requerimientos es el que trata la descripción de preferencias, teniendo en cuenta que en base a esas preferencias el agente comprador interacciona conforme a una estrategia para conseguir los objetivos, normalmente la maximización de sus preferencias. Al mismo tiempo se extiende el concepto de preferencia al ámbito de la actitud frente al oponente, con el objeto de conseguir un modelo de negociación más general. Se define a continuación el ámbito de conocimiento básico de un agente comprador, como un modelo de requerimientos basado en un modelo de preferencias sobre los atributos de productos, y un modelo de actitud o perfil negociador. Definición 4.5.1.1 (Modelo de requerimientos de un comprador) El modelo de requerimientos de un comprador es definido como Breq = (F,Nb), donde F = (X, D, Cf) es un FCSP que describe el modelo de preferencias sobre los atributos de productos, tal que X es un conjunto de atributos de un producto, D es el conjunto de dominios de los atributos, y Cf es un conjunto de restricciones difusas que expresan los requerimientos sobre los atributos. Nb , es el perfil negociador del comprador mencionado anteriormente, donde 0,1 representa el perfil expresivo (argumenta o no las propuestas emitidas) del agente, y 0,1 representa el perfil receptivo (modula la importancia que van a tener en los procesos de decisión los argumentos del vendedor). A fin de otorgarle al agente comprador la mayor expresividad posible, ambos valores toman un valor de 1. La funcionalidad del modelo de preferencias es doble, por una parte permite calcular la satisfacción que le reporta a un comprador la adquisición de un determinado producto, y por otra permite disponer de una fuente de información a partir de la cual generar peticiones de compra basadas en la maximización de la utilidad subjetiva. En base a esta funcionalidad, por otra parte imprescindible en un agente de compra, se presentarán una serie de definiciones derivadas que son piezas clave en el ámbito operativo del agente. En primer lugar vamos a formalizar la evaluación del grado de satisfacción que obtiene un comprador con un producto, y en segundo lugar se señalará el concepto de requerimiento de compra y la evaluación del grado de satisfacción que puede obtener un comprador a partir de un requerimiento de compra. Definición 4.5.1.2. (Grado de satisfacción global para un producto) Dado un modelo de preferencias F de un comprador, el grado de satisfacción global para un producto pk = (a1,..., an), donde aj representa el valor del atributo j, viene dado por la ecuación descrita en la definición 4.4.3 del cálculo del grado de satisfacción global de una etiqueta compuesta. vX R (vX ) R f C f f En este caso el producto pk es equivalente a la etiqueta compuesta, de manera que el grado de satisfacción global será función del grado de cumplimiento de las funciones características de cada una de las restricciones definidas en F. Como mencionamos anteriormente, el operador utilizado para la presente tesis es min, por lo tanto, de todos esos grados de cumplimientos generados, el grado de satisfacción global será definido por aquel cuyo valor sea mínimo. Definición 4.5.1.3. (Requerimiento de compra) Sea Ric i una restricción dura extraída a partir de la restricción difusa Ri f C f i 1, ..., m a un nivel de corte i , un requerimiento de compra se define como una proposición: req c k1 B Rk 1 c , ..., Rki ki C f k j 1, ..., m Esto significa que un requerimiento de compra es una proposición que enlaza un conjunto de restricciones duras mediante operadores lógicos4. Estas restricciones duras se extraen de sus correspondientes restricciones difusas a niveles de corte independientes. El requerimiento de compra podrá estar formado por un subconjunto o por el conjunto de restricciones difusas definidas en el modelo de preferencias. Definición 4.5.1.4. (Grado de satisfacción global potencial de un requerimiento de compra) Dado un requerimiento de compra Breq , el grado de satisfacción global que un comprador puede alcanzar si dicho requerimiento es satisfecho por el vendedor, es el denominado grado de satisfacción global potencial, que se define como: Breq i i 1, ..., m Cabe aclarar que aunque el operador definido es una “y lógica”, también sería factible por ejemplo la aplicación de una “o lógica” , o una combinación de operadores lógicos distintos. La selección de un operador u otro debe ser función del operador utilizado en el cálculo de satisfacción global (ver ecuación de la definición 4.4.3). 4 donde el operador es el operador utilizado en la ecuación descripta en la definición 4.4.3 para el cálculo del grado de satisfacción global, y i representa el nivel de corte aplicado a la restricción Ri f para la generación del requerimiento de compra. El operador aplicado es min, por lo que el grado de satisfacción global potencial representa el mínimo valor de corte aplicado a la restricción Ri f . Es importante puntualizar que mientras un requerimiento de compra no tiene por qué incluir un extracto de todas las restricciones difusas, el cálculo de la satisfacción potencial de un requerimiento de compra requiere el cálculo del grado de cumplimiento de todas las restricciones. Recordemos que un requerimiento de compra está formado por restricciones duras que se extraen de un subconjunto o el conjunto completo de las restricciones difusas definidas, es decir, un comprador puede enviar un requerimiento muy vago donde sólo se envíe información al respecto de una o dos restricciones por ejemplo. Sin embargo, independientemente de la emisión del requerimiento y en definitiva de lo que se haya querido expresar en la locución enviada a un vendedor, un producto ofertado por el vendedor debe satisfacer no sólo las restricciones enviadas, sino todas aquellas que localmente determinan el grado de satisfacción deseado. Esto significa que deben tenerse en cuenta los cortes aplicados a las restricciones difusas, aunque dichas restricciones no sean incluidas en el requerimiento de compra. Definición 4.5.1.5. (Valoración de requerimiento de compra) Dado un requerimiento de compra Breq , se define la valoración de un requerimiento de compra como un vector: vBreq vk1 , ..., vki vk j 0,1, k j 1, ..., m donde vk j expresa la preferencia que el comprador tiene por que la restricción kj sea satisfecha. vk j 1 define el mayor grado de preferencia, y vk j 0 el menor. Cabe aclarar que con esta definición, no se asume que una expresión de preferencia tenga que ser verdadera. Es decir, el agente comprador puede mentir acerca de sus preferencias reales. Con las herramientas definidas hasta este punto, un agente comprador sería capaz de describir la sintaxis de un requerimiento de compra, de evaluar una oferta concreta de un vendedor y calcular el grado de satisfacción que obtendría con la compra, de calcular el grado de satisfacción que obtendría con una oferta que se ajustase a un requerimiento de compra concreto y, por último, de valorar requerimientos de compra. 4.5.2 Conocimiento del dominio del agente vendedor El ámbito de conocimiento básico de un agente vendedor es el modelo de requerimientos que se define a continuación: Definición 4.5.2.1. (Modelo de requerimientos de un vendedor) El modelo de requerimientos de un vendedor se define como Sreq = (S,Ns), donde S representa el catálogo de productos del vendedor, y Ns define el perfil negociador del vendedor. El catálogo de productos se especifica de la siguiente manera: S s j s j p j , u j , p j a j1 , ..., a jn , 0 j k donde sj representa una entrada en el catálogo de productos, pj es un vector de atributos del producto, y uj asigna un valor de utilidad a la venta de un producto pj . k define el número total de productos en el catálogo. El perfil negociador del vendedor es definido por la tupla: N S , , t donde 0, 1 representa el perfil expresivo (argumenta o no las propuestas emitidas) del agente, y 0, 1 representa el perfil receptivo (modula la importancia que van a tener en los procesos de decisión los argumentos procedentes de un comprador). De igual modo que en el comprador, a fin de otorgarle al agente vendedor la mayor expresividad posible, ambos valores toman un valor de 1. t representa el conjunto de creencias del agente vendedor. Este conjunto se define como: t it , it , i 1, ..., m donde it representa la creencia en el instante t acerca de la estrategia de relajación utilizada por el comprador al respecto de la restricción difusa Ri, y it 0, 1 , es el grado de certidumbre acerca de la creencia it . El catálogo de productos del vendedor es dinámico en un doble sentido. En primer lugar se asume que el número de productos del catálogo no es estático, es decir, incluso durante una negociación pueden aparecer o desaparecer productos. En segundo lugar, para un conjunto definido de productos, las utilidades asignadas uj pueden verse modificadas por factores externos. Con las herramientas definidas hasta este punto, un agente vendedor sería capaz de describir la sintaxis de una oferta: Definición 4.5.2.2. (Oferta de venta) Una oferta de venta está definida por un producto pj del catálogo sj. Podría además evaluar el grado de satisfacción que obtendría con la venta, a partir de la utilidad asignada uj. Sin embargo, cubriendo solamente estos aspectos, no se está habilitando al vendedor para que pueda expresar su valoración acerca de la no disponibilidad de una oferta adecuada, conforme a un requerimiento de compra recibido. Es decir, el único tipo de diálogo que podría entablar sería inexpresivo. Para dotar a un agente vendedor de la capacidad expresiva suficiente para valorar la no disponibilidad de ofertas, se define a continuación el concepto de requerimiento de relajación: Definición 4.5.2.3. (Requerimiento de relajación) Dado un requerimiento de compra B , se define un requerimiento de relajación como un vector: req B rk , ..., rk req 1 i rk j 0, 1, k j 1, ..., m donde rk j expresa la preferencia que el vendedor tiene por que la restricción kj sea relajada. rk j 1 define el mayor grado de preferencia, y rk j 0 el menor. Al igual que en la valoración de un requerimiento de compra, con esta definición, no se asume que una expresión de preferencia tenga que ser verdadera, y la graduación de preferencias sigue siendo arbitraria. Por último, esta definición tampoco entra en aspectos tales como qué criterios aplica el vendedor para valorar los requerimientos de relajación, que entrarían dentro de la definición de los mecanismos de decisión. 4.6. Modelo de diálogo de alto nivel Habiendo hecho una introducción a los conceptos que definen el modelo de negociación basado en restricciones difusas, expondremos los mecanismos de decisión de ambos agentes. A continuación se presenta el modelo de alto nivel para los diálogos de negociación entre compradores y vendedores en una transacción de compraventa. Todo diálogo está restringido a dos agentes, uno comprador (en nuestro caso el Municipio) y otro vendedor (un proveedor en particular), de manera que los diálogos son exclusivamente bilaterales. Esto no significa que ambos agentes no puedan mantener en paralelo diálogos con otros compradores y vendedores, pero serán en cualquier caso diálogos diferentes. Un diálogo está estructurado en fases según la siguiente lista: 1. Apertura del diálogo: el diálogo comienza. 2. Negociación: esta fase está definida por una secuencia de interacciones. Dichas interacciones se enumeran a continuación: Un comprador: o Emite requerimientos de compra. o Emite valoraciones de requerimientos de compra. o Rechaza ofertas de venta. Un vendedor: o Emite ofertas de venta. o Rechaza requerimientos de compra. o Propone la relajación de los requerimientos de compra. o Rechaza compromisos de compra. 3. Confirmación: los participantes comprometen y confirman un acuerdo. 4. Cierre del diálogo: el diálogo termina. Cabe señalar que dicho diálogo está sujeto a las siguientes reglas: La primera fase en todo diálogo es Apertura del diálogo. Las fases Apertura y Cierre del diálogo sólo pueden ocurrir una vez en todo diálogo. Las únicas fases que deben aparecer en todo diálogo que termina normalmente son Apertura y Cierre del diálogo. La fase de Confirmación requiere que previamente se haya pasado por la fase de Negociación. La última fase de todo diálogo que termina normalmente es Cierre del diálogo. Los participantes pueden conmutar entre las fases de Negociación y Confirmación, sujetos sólo a las reglas y restricciones definidas por las reglas de combinación de locuciones. 4.7 Mecanismos de decisión y locuciones Es imprescindible equipar a cada participante con los mecanismos que permitan invocar determinadas locuciones en el momento adecuado, como respuesta a locuciones pasadas, o como anticipo de futuras locuciones. A este tipo de mecanismos se los denomina mecanismos de decisión semánticos. A continuación presentamos una lista completa de todos los mecanismos de decisión semánticos que van a permitir la generación de diálogos automáticos entre un comprador y un vendedor, con el objeto negociar la compra de un producto de categoría , conforme al conjunto de locuciones definidas. Los mecanismos se van a agrupar en función del rol de participante: Comprador (B) o Vendedor (S). Para cada mecanismo se van a describir sus directrices generales, y a continuación se van a detallar sus funcionalidades específicas. Además, se especifican las salidas generadas por el mecanismo. La información relativa al número de veces que un producto ha sido ofertado se encuentra en el Almacén de información del vendedor AI(Ps). 4.7.1 Mecanismos de decisión del agente comprador B1: Recognize Need Permite que un agente comprador reconozca la necesidad de adquirir un producto. Dicho reconocimiento es consecuencia de la iniciativa explícita de un usuario el cual a través de una interfaz da la orden a su agente personal de su intención de adquirir un producto5. El propósito final del mecanismo es la inicialización de un diálogo negociador con un vendedor. Sin embargo, el reconocimiento de una necesidad de compra no significa que el proceso de negociación pueda llevarse a cabo inmediatamente, por ejemplo, porque no haya vendedores adecuados con los que ponerse en contacto. En este último caso el mecanismo indica que se encuentra en un estado de espera o wait. Cuando se identifica la necesidad, y además se interpreta que la inicialización de un diálogo es factible, la salida del mecanismo es have_need( ). Salidas: wait, have_need( ), donde define una categoría de producto. Este mecanismo emite la locución L1: open_dialogue(.). L1: open_dialogue(.) Locución open_dialogue(Pb, Ps, ) Precondiciones Esta locución no debe haber sido emitida previamente. El comprador Pb debe tener la necesidad de adquirir un producto en la categoría Significado . El comprador Pb sugiere la apertura de un diálogo negociador con el vendedor Ps sobre productos de la categoría . Un diálogo siempre debe comenzar con esta locución. Se asume que la identidad del vendedor Ps es conocida, por lo que esta locución no implica una búsqueda de un destinatario. Respuesta El vendedor Ps debe responder con enter_dialogue(Ps, Pb, ) si desea participar en dicho diálogo. Actualización AI No se produce actualización. Tabla 2 Detalle de la locución L1: open_dialogue(.) B2: Generate Purchase Requirement Este mecanismo responde a la necesidad de un agente comprador de generar requerimientos de compra. Cualquier requerimiento de compra es compatible con la locución prefer_to_buy(.). El mecanismo además prevé la imposibilidad de generar el requerimiento. Así, se identifican dos posibles salidas, la que describe la imposibilidad de 5 También podría reconocerse a partir de un proceso basado en umbrales que se dispare automáticamente (p.ej. cuando un agente personal detecta que se encuentra en las cercanías de un mercado electrónico que ofrece un determinado tipo de productos, y dichos productos se encuentran dentro de las preferencias del usuario propietario del agente personal) generar un requerimiento, y la que especifica un requerimiento concreto generado. La imposibilidad se formaliza mediante un conjunto vacío o empty_set . Salidas: empty_set , Breq Según el modelo de preferencias del comprador descrito en la definición 4.5.1.1, un FCSP modela dichas preferencias. Un requerimiento de compra (ver definición 4.5.1.3) se define como una proposición formada por un conjunto de restricciones duras unidas por operadores lógicos, extraídas del FCSP a determinados niveles de corte. Se especifica además que un requerimiento de compra no tiene por qué incluir todas las restricciones difusas definidas en el FCSP, de manera que el agente comprador puede extraer dichas restricciones de forma estratégica. La estrategia de extracción de restricciones duras tiene por tanto una implicación directa en la forma que toma el requerimiento de compra, y de manera indirecta, en la satisfacción global potencial (ver definición 4.5.1.4) que espera como mínimo obtener el comprador. Teniendo en cuenta que un agente racional intentará maximizar su utilidad, la o las estrategias del comprador al respecto de la generación de requerimientos de compra estarán centradas en la gestión adecuada del grado de satisfacción global potencial. Existen dos formas de composición de un nuevo requerimiento de compra: 1. Incorporación de una nueva restricción difusa, mediante la extracción de la correspondiente restricción dura. Está pensada para dos situaciones concretas: el inicio de la negociación, cuando se debe preparar el primer requerimiento de compra, y durante la negociación, tras una oferta de venta que no satisface las restricciones duras no incluidas en el requerimiento de compra. Este proceso de reenvío de requerimientos repetidos estará limitado por un umbral predeterminado. Una vez superado el umbral se deberá seleccionar aleatoriamente una restricción de entre aquellas no incluidas en el requerimiento de compra y que no han sido satisfechas por las ofertas de venta. El objetivo es conducir al vendedor hacia una oferta de venta correcta, pero minimizando la cantidad de información revelada. 2. Modificación del requerimiento de compra previo sin incorporación de nuevas restricciones difusas. Está pensada para una situación concreta: la emisión durante la negociación por parte del vendedor de las locuciones prefer_to_sell(.) o refuse_to_sell(.), destinadas a expresar su rechazo a satisfacer el requerimiento del comprador. B3: Generate Purchase Requirement Valuation Este mecanismo permite generar un argumento de valoración de un requerimiento de compra todavía no enviado, es decir, una valoración de requerimiento de compra vBreq . Ésta podrá ser comunicada mediante la locución prefer_to_buy(.). Salidas: vBreq Como se introdujo en la definición 4.5.1.5, una valoración de requerimiento de compra pretende ser una expresión de la importancia relativa que tiene para el comprador el cumplimiento de cada una de las restricciones que componen un requerimiento de compra, o cuando menos, es lo que el comprador quiere hacer creer. Indirectamente el comprador está indicando qué restricciones preferiría relajar, que serán evidentemente aquellas menos prioritarias. Aparentemente, el vendedor podría actuar estratégicamente y esperar a que el comprador relajase más sus requerimientos, teniendo en cuenta que están priorizados e indican una disposición del comprador por relajar. Sin embargo, nada le garantiza al vendedor que el comprador consiga una solución satisfactoria con otro vendedor (suponiendo que existe algún mecanismo externo que es capaz de garantizar esto). Este mecanismo emite la locución L6: prefer_to_buy(.). L6: prefer_to_buy(.) Locución prefer_to_buy(Pb, Ps, B req , vBreq ). Precondiciones No hay precondiciones. Significado El agente comprador Pb le indica al vendedor Ps, su deseo de adquirir un producto que satisfaga el requerimiento de compra B req , y expresa sus preferencias en cuanto a la importancia relativa que tienen las restricciones incluidas en el requerimiento de compra mediante la valoración de requerimiento de compra vBreq . Respuesta No se requiere. Actualización AI Se almacena en un registro el requerimiento de compra B req . Tabla 3 Detalle de la locución L6: prefer_to_buy(.) B4: Consider Offers Este mecanismo responde a la necesidad que tiene un agente comprador de decidir en un determinado momento si: aceptar la oferta de venta propuesta por un agente vendedor, rechazar la oferta de venta propuesta, o generar un nuevo requerimiento de compra. Enviado un requerimiento de compra tBreq , un agente comprador acepta una oferta de venta pj cuando el grado de satisfacción global ( p j ) (ver definición 4.5.1.2) es mayor o igual que el grado de satisfacción global potencial del requerimiento de compra tBreq1 . Esto es así porque desde que se emite un requerimiento, hasta que se recibe una oferta de venta, pueden verse modificadas las preferencias del vendedor, de manera que tBreq1 va a capturar las necesidades reales actuales del agente comprador. En este caso el mecanismo retorna accept_offer(pj). La aceptación de una oferta desemboca en una fase de diálogo de confirmación de la oferta. Si una oferta de venta no se puede aceptar, y dicha oferta no satisface las restricciones enviadas en tBreq , el mecanismo retorna reject_offer(pj) indicando que se debe generar una expresión de rechazo. Finalmente, si la oferta de venta no puede ser aceptada, pero satisface las restricciones enviadas en tBreq , el mecanismo retorna generate_purchase_requirement(pj), indicando que se debe generar un nuevo requerimiento de compra. Salidas: accept_offer(pj), reject_offer (pj), generate_purchase_requirement(pj), donde pj es una oferta de venta. Las locuciones que emite este mecanismo son L7: refuse_to_buy(.) y L9: agree_to_buy(.). L7: refuse_to_buy(.) Locución refuse_to_buy(Pb, Ps, pj) Precondiciones No puede ser emitida tras agree_to_buy (Pb, Ps, pj). Significado El agente comprador Pb expresa su rechazo a la compra de un producto pj. Respuesta No se requiere. Actualización AI No se actualiza. Tabla 4 Detalle de la locución L7: refuse_to_buy(.) L9: agree_to_buy(.) Locución agree_to_buy(Pb, Ps, pj). Precondiciones Esta locución es siempre una respuesta a willing_to_sell(Ps, Pb, pj). Significado El agente comprador Pb dirigiéndose al agente vendedor Ps se compromete a comprar el producto pj. Respuesta Si el agente vendedor Ps desea vender el producto pj, puede responder con la locución agree_to_sell(Ps, Pb, pj). Actualización AI Se almacena en un registro el compromiso de compra pj. Tabla 5 Detalle de la locución L9: agree_to_buy(.) B5: Consider Withdrawal Este mecanismo responde a la necesidad que tiene un agente comprador de decidir en un determinado momento si debe finalizar el diálogo con un vendedor. El mecanismo puede permanecer en estado de espera, retornará entonces wait, o indicar que se debe abandonar el diálogo, en cuyo caso retornará withdraw( ). Salidas: wait, withdraw( ) La locución emitida por el mecanismo es L11: withdraw_dialogue(.). L11: withdraw_dialogue(.) Locución withdraw_dialogue(Px, Py, _), donde Px and Py son participantes con diferentes roles, es decir, compradores o vendedores. Precondiciones Esta locución puede emitirse en cualquier momento tras la apertura del diálogo. Significado Un agente Px anuncia al agente Py que abandona el diálogo de negociación de compra de productos de la categoría . Respuesta No se requiere. Actualización AI No se actualiza. Tabla 6 Detalle de la locución L11: withdraw_dialogue(.) 4.7.2 Mecanismos de decisión del agente vendedor S1: Recognize Category Permite que un agente comprador reconozca la necesidad de vender un producto. El mecanismo simplemente asegura que el agente vendedor dispone de productos de la categoría en su catálogo. Si se dispone de productos el mecanismo retorna wish_to_enter( ), y si no wish_not_to_enter( ). El mecanismo puede permanecer a la espera, retornando entonces wait. Salidas: wait, wish_to_enter( ), wish_not_to_enter( ) La locución emitida por este mecanismo es L2: enter_dialogue(.). L2: enter_dialogue(.) Locución enter_dialogue(Ps, Pb, ). Precondiciones El comprador Pb debe haber emitido open_dialogue(Pb, Ps, ). Ps debe tener la necesidad de vender productos de la categoría especificada . Significado El agente vendedor Ps indica su deseo de incorporarse a un diálogo de negociación de compra sobre productos de la categoría Respuesta No se requiere. con el comprador Pb. Actualización AI No se produce actualización. Tabla 7 Detalle de la locución L2: enter_dialogue(.) S2: Assess Purchase_Requirement Este mecanismo responde a la necesidad del agente vendedor de valorar requerimientos de compra. El objetivo central de una valoración será detectar la existencia de productos en el catálogo que satisfagan dichos requerimientos de compra. Si no se encuentran productos, el mecanismo decidirá argumentar el rechazo al requerimiento de compra recibido. Cuando existe una oferta de venta el mecanismo retorna sale_offer(pj), en caso contrario se argumenta el requerimiento de compra devolviendo purchase_requirement( tBreq ). Salidas: purchase_requirement( tBreq ), sale_offer(pj) La locución que emite este mecanismo es L3: willing_to_sell(.). L3: willing_to_sell(.) Locución willing_to_sell(Ps, Pb, pj). Precondiciones Un comprador debe emitir una locución prefer_to_buy (Pb, Ps, Breq , vBreq ) donde pj debe satisfacer el requerimiento de compra Significado B req . El vendedor Ps le indica al comprador Pb su deseo de vender un producto pj que satisface el requerimiento de compra B req recibido anteriormente mediante la locución prefer_to_buy (Pb, Ps, Breq , vBreq ). Respuesta No se requiere. Actualización AI Se almacena en un registro la oferta de venta pj. Tabla 8 Detalle de la locución L3: willing_to_sell(.) S3: Generate Potential Sale-Offers Este mecanismo de generación de ofertas de venta potenciales responde a la necesidad que tiene un agente vendedor de analizar mediante introspección, qué productos del catálogo pueden considerarse como buenas ofertas de venta en un determinado momento. Estas ofertas se denominan ofertas de venta potenciales porque el propósito no es el de ser enviadas inmediatamente al comprador, sino el de servir como guía en un proceso de argumentación del rechazo a un requerimiento de compra. Se podría decir que es un mecanismo que estima qué productos del catálogo son buenos candidatos para futuras ofertas de venta. Este mecanismo retorna el conjunto de productos del catálogo S que se consideran buenas opciones para una futura oferta al comprador. Salidas: Sp, que describe el conjunto de productos que el agente vendedor considera como buenas opciones para una oferta futura. Este mecanismo constituye el núcleo del sistema de argumentación del vendedor. Cuando un agente vendedor no puede satisfacer un requerimiento de compra, puede estimular al comprador para que cambie sus preferencias, y en consecuencia sus propuestas o requerimientos de compra. En un esquema no argumental, el vendedor tiene como única herramienta el rechazo, sin embargo esto no permite reconducir la negociación hacia posiciones favorables para el vendedor, y mucho menos permite llegar a soluciones compensadas win-to-win. Es evidente que definir un espacio de búsqueda compatible es clave para alcanzar soluciones satisfactorias. S4: Generate Relax Requirement Este mecanismo responde a la necesidad del vendedor de componer un requerimiento de relajación Breq . Conforma la segunda fase del proceso de generación de requerimientos de relajación descrito en el mecanismo S3. Dado un conjunto de ofertas de venta potenciales SP, este mecanismo compone un requerimiento de relajación con el objeto de conducir al comprador hacia uno de los productos contenidos en SP. El mecanismo retorna un requerimiento de relajación Breq . Salidas: Breq El principio básico de composición del requerimiento de relajación es el de conseguir que el comprador relaje aquellas restricciones del requerimiento de compra que no son satisfechas por los productos contenidos en SP. El mecanismo emite la locución L5: prefer_to_sell(.). L5: prefer_to_sell(.) Locución Precondiciones Significado prefer_to_sell(Ps, Pb, B req , Breq ). Pb debe emitir una locución prefer_to_buy(Pb, Ps, B req , B req ). El agente vendedor Ps le indica al comprador Pb, que debería relajar el requerimiento de compra prefer_to_buy(Pb, Ps, B req B req recibido a través de la locución , vBreq ), y expresa su preferencia por la relajación de restricciones específicas del requerimiento de compra mediante el requerimiento de relajación Respuesta No se requiere. Actualización AI No se actualiza. B req . Tabla 9 Detalle de la locución L5: prefer_to_sell(.) S5: Accept or Reject Offer Este mecanismo responde a la necesidad del agente vendedor de decidir en un determinado momento si se debe o no aceptar una oferta de compra del producto pj emitida por un agente comprador mediante una locución agree_to_buy(.). Sólo existen dos posibles valores de retorno, accept(pj) si se acepta la oferta, y reject(pj) si se rechaza la oferta. Salidas: accept(pj), reject(pj) Las locuciones que emite este mecanismo son L8: refuse_to_sell(.) y L10: agree_to_sell(.). L8: refuse_to_sell(.) Locución Precondiciones refuse_to_sell(Ps, Pb, pj) ó refuse_to_sell(Ps, Pb, B req ). La locución refuse_to_sell(Pb, Ps, pj) no puede emitirse tras una emisión válida de agree_to_sell(Ps, Pb, pj), siendo válida únicamente tras la recepción de agree_to_buy(Pb, Ps, pj). Un comprador Pb debe emitir prefer_to_buy(Pb, Ps, B Significado req , vBreq ) para que refuse_to_sell(Ps, Pb, B req ) sea válida. El agente vendedor Ps expresa su rechazo a vender el producto pj o a vender un producto que satisfaga el requerimiento de compra Breq . Respuesta No se requiere. Actualización AI No se actualiza. Tabla 10 Detalle de la locución L8: refuse_to_sell(.) L10: agree_to_sell(.) Locución agree_to_sell(Ps, Pb, pj). Precondiciones Debe haberse recibido una locución agree_to_buy(Pb, Ps, pj). Significado El agente vendedor Ps, dirigiéndose al agente comprador Pb, se compromete a vender el producto pj. Respuesta No se requiere. Actualización AI Se almacena en un registro el compromiso de venta pj. Tabla 11 Detalle de la locución L10: agree_to_sell(.) S6: Consider Withdrawal Este mecanismo responde a la necesidad que tiene un agente vendedor de decidir en un determinado momento si debe finalizar el diálogo con un comprador. El mecanismo puede permanecer en estado de espera, retornará entonces wait, o indicar que se debe abandonar el diálogo, en cuyo caso retornará withdraw( ). Salidas: wait, withdraw( ) Este mecanismo emite la locución L11: withdraw_dialogue(.) descripta en el mecanismo B5: Consider Withdrawal. En la figura 6 podemos observar el diagrama de transición. En él aparecen estados delegadores (delegator) cuya función es la de ordenar las transiciones y proporcionarle una secuencialidad a las mismas. A continuación mostramos un listado con las reglas de transición y qué locuciones se envían en cada cambio de estado. Una tupla <Px, K, s> describe el mecanismo de decisión K del agente Px cuando se genera una salida s. Cabe señalar que las transiciones TR9 y TR11 no fueron tenidas en cuenta por involucrar aspectos no expresivos de los agentes. L1 TR1 : Pb , B1, have _ need ( ) Ps , S1, . TR2 : Pb , B1, have _ no _ need ( ) Ps , B1, wait TR3 : Ps , S1, wish _ not _ to _ enter ( ) Ps , S1, wait L2 TR4 : Ps , S1, wish _ to _ enter ( ) Pb , B2, . TR5 : Pb , B2, Pb , B5, . L11 TR6 : Pb , B5, withdraw( ) Ps , S 6, . L11 TR7 : Ps , S 6, withdraw( ) Pb , B5, . TR8 : Pb , B2, Breq Pb , B3, . L6 TR10 : Pb , B3, vBreq Ps , S 2, . L3 TR12 : Ps , S 2, sale _ offer ( p j ) Pb , B4, . TR13 : Ps , S 2, purchase _ requirement (tBreq ) Ps , S 3, . TR14 : Ps , S 3, S P Ps , S 4, . L5 TR15 : Ps , S 4, Breq Pb , B2, . TR16 : Pb , B4, generate _ purchase _ requirement ( p j ) Pb , B2, . L9 TR17 : Pb , B4, accept _ offer ( p j ) Ps , S 5, . L7 TR18 : Pb , B4, reject _ offer ( p j ) Ps , S 2, . 10 TR19 : Ps , S 5, accept ( p j ) L Pb , B5, . L8 TR20 : Ps , S 5, reject ( p j ) Pb , B2, . Tabla 12 Reglas de transición Figura 6 Diagrama de reglas de transición 4.8 Resumen general Los modelos de negociación basados en restricciones difusas aportan un mayor grado de flexibilidad y eficiencia respecto a otros modelos, los cuales se enfocan en la defensa de posiciones. Este modelo se acerca más a los procesos de negociación en escenarios reales donde se negocia sobre la base de los intereses de las partes involucradas. El comprador, en nuestro caso un Municipio, cuenta con la capacidad de emitir requerimientos de compra en forma de restricciones difusas, valoradas en forma subjetiva. Los proveedores pueden optar por no ofrecer un determinado producto utilizando locuciones que manifiestan explícitamente un deseo de relajación sobre el requerimiento de compra recibido. En definitiva, ambas partes cuentan con las herramientas necesarias para orientar la negociación hacia el beneficio de sus propios intereses, pero sin dejar de lado los intereses de la otra parte. Este enfoque permite que el transcurso de la negociación se dirija hacia zonas del espacio de soluciones donde los resultados son beneficiosos para las partes (resultados del tipo win-to-win). El modelo de diálogo de alto nivel para un agente Municipal y otro proveedor se compone de tres fases: la primera es la apertura del diálogo en donde las partes acuerdan comenzar una negociación. La segunda es la negociación propiamente dicha; en ella el agente Municipal emite requerimientos de compras en forma de restricciones difusas, valora sugestivamente los requerimientos de compra y se lo comunica al proveedor, y por último rechaza ofertas de venta que no le resultan convenientes; el proveedor emite ofertas de ventas que se acerquen al requerimiento de compra recibido y que le resulten beneficiosas para él, rechaza requerimientos de compras argumentando su decisión con pedidos de relajación, y emite rechazos de compromisos de compra por no contar con un producto que se ajuste al requerimiento. La tercera fase es la confirmación que ocurre cuando ambas partes llegan a un acuerdo. Y por último, la cuarta fase se refiere al cierre del diálogo. Cada una de las acciones llevada a cabo por los agentes dentro de las fases se basan en mecanismos de decisión y locuciones. Los agentes están equipados con estos mecanismos, llamados mecanismos de decisión semánticos, que le permiten invocar determinadas locuciones en el momento adecuado, como respuesta a locuciones pasadas, o como anticipo de futuras locuciones. Evidentemente lo expuesto en este capítulo es una visión teórica de los mecanismos, es decir, no hemos profundizado en cada uno de ellos, solo fueron mencionados. En el siguiente capítulo presentaremos una instanciación del mismo con el fin de acercarnos aún más a la lógica del funcionamiento de nuestro sistema. Capítulo 5 Instanciación del modelo de negociación El objetivo de este capítulo es el de presentar una instanciación del modelo de negociación exhibido anteriormente, basándonos en la teoría propuesta por López Carmona (López Carmona, 2006). Todo el proceso de instanciación recae en presentar la definición detallada de los mecanismos de decisión del Sector de Compras y proveedor. 5.1 Introducción Antes de presentar la instanciación del modelo de negociación haremos una breve descripción del contexto donde lo aplicaremos, a fin de no perder de vista el ámbito de será utilizado. Toda negociación llevada a cabo en la presente tesis será del tipo B2G (Empresas a Gobierno o Bussines to Government) en un ámbito municipal. Todos los procesos de compra de los municipios de la provincia de Buenos Aires están regulados por las Ley Orgánica de las Municipalidades de la provincia. La misma establece tres artículos que reglamentan la estructura de una Oficina de Compras: ARTICULO 197°: Cada Municipalidad organizará una Oficina de Compras, cuyas funciones serán reglamentadas por el Departamento Ejecutivo. ARTICULO 198°: El Jefe de la Oficina de Compras, con asesoramiento de las reparticiones técnicas en los casos necesarios, tendrá a su cargo y bajo su responsabilidad, el diligenciamiento de los suministros que deban efectuarse a la Municipalidad con arreglo a las normas establecidas para la adquisición directa, el concurso de precios y las licitaciones públicas y privadas. ARTICULO 199°: Es obligación del Jefe de Compras comprobar y certificar la efectiva recepción de los artículos adquiridos por la Municipalidad. Será personalmente responsable de los perjuicios que se produzcan a consecuencia de los ingresos que certifique sin estar fundado en la verdad de los hechos. Estos tres artículos evidencian la gran responsabilidad que recae sobre el Jefe de Compras en el desarrollo de sus funciones. Dicha responsabilidad se traslada a toda herramienta que la oficina utilice, como podría ser un sistema de negociación automática. Dependiendo del monto del bien a adquirir existen cuatro tipos de procesos: Compra directa: Son las compras básicas donde el monto no supera los $37000. El proceso carece de regularización y no remite demasiada complejidad: el jefe de la Oficina de Compras solicita a diversos proveedores inscriptos en el registro de proveedores el envío de cotizaciones del bien en cuestión, y es él mismo el que decide a quién efectuarle la compra. No existe una fecha de apertura (fecha en la que el Municipio deja de recibir cotizaciones, para así comenzar a evaluarlas), salvo contadas excepciones. Concurso de precios: Son las compras donde los montos van de $37000 a $170000. Deben efectuarse enviando pedidos de cotización formales a tres proveedores registrados como mínimo. Existe una fecha de apertura donde el Municipio comienza a evaluar las ofertas recibidas. Licitación privada: Para montos que van de $170000 a $650000. Al igual que en el concurso de precios, se realiza por invitación, pero para este caso el mínimo de proveedores registrados a invitar son 5. Licitación pública: Este proceso se inicia cuando una obra, bien o servicio excede los $650000. El pedido de cotización se efectúa a través de medios públicos: diarios, televisión, boletín oficial, etc. Debe ser obligatorio contar con más de una oferta, en caso contrario se realiza una nueva licitación. Si nuevamente se recibe una sola cotización será el Honorable Concejo Deliberante el que decida los pasos a seguir. En la fecha de apertura estipulada se celebra un acto de apertura de sobres donde los proveedores registrados pueden estar presentes si lo desean (incluso se asientan en un acta). Como mencionamos anteriormente, el marco de aplicación de la presente tesis se desarrolla sobre un proceso de compra directa donde las restricciones y regulaciones están más relajadas. Cada proveedor registrado contará con su agente vendedor que negociará con el agente comprador de un determinado Municipio, consultando constantemente en su catálogo dinámico. A continuación presentaremos la instanciación del modelo de negociación considerando el contexto antes mencionado. Para nuestro caso contamos con dos entidades: una compradora (Sector de Compras) y una vendedora (proveedor). En el resto del capítulo utilizaremos los términos Sector de Compras y proveedor para referirnos exclusivamente a sus respectivos agentes inteligentes. 5.2 Instanciación de los mecanismos de decisión del Sector de Compras En esta sección se desarrolla la propuesta detallada de cada uno de los mecanismos de decisión del agente que representa al Sector de Compras. B1: Recognize Need El mecanismo ya fue especificado en el capítulo anterior. La necesidad de iniciar un diálogo se lleva a cabo a través de una interfaz. Una vez que el encargado de las compras del Municipio declara la categoría del producto y las restricciones difusas sobre sus atributos, el sistema crea un agente negociador comprador que será el responsable de entablar el dialogo con el agente proveedor. Por lo tanto este mecanismo es el receptor del requerimiento de compra del sector. B2: Generate Purchase Requirement El mecanismo aborda el problema de la generación de requerimientos de compra. Son tres las estrategias que se especifican a continuación: la incorporación de nuevas restricciones difusas a un requerimiento de compra tBreq para generar un nuevo tBreq1 ; la incorporación de la primera o primeras restricciones a un tBreq ; la definición de una función llamada función de modificación de requerimiento de compra o fmrc : Breq , Breq Breq , para la modificación de requerimientos de compra, con el objeto de generar también un nuevo tBreq1 sin añadir nuevas restricciones. Algoritmo (Modificación de requerimientos de compra) 1) Dado un requerimiento de compra tBreq , se obtiene un vector con los grados de satisfacción global potencial para todos los posibles requerimientos de compra ficticios, resultantes de relajar cada vez sólo una de las restricciones contenidas en tB : req t 1 t 1 B ki Breq k1 req ... donde t 1 k x B req representa el grado de satisfacción global potencial que se obtiene si la restricción Rkfx es relajada lo mínimo posible. Las restricciones que no pueden ser relajadas más se eliminan del vector. Si no es posible relajar ninguna restricción la función retorna . 2) Se calcula el máximo del vector anterior: t 1 max t 1 1 k 1 Btreq B ki max ... req 3) Se genera un nuevo vector en el que se incluyen únicamente los elementos que satisfacen la siguiente igualdad: t 1 max t 1 k x B req que se denominará t 1 max 4) Finalmente se aplica la siguiente función: arg máx t 1 t max , max donde t max es un requerimiento ( t 1) k x B req rk x de relajación del proveedor en el que sólo se tienen en cuenta los requerimientos que se corresponden con las restricciones incluidas en el vector creado en el paso 3). Si no existe requerimiento de relajación, rk x tomará siempre valor 0. Esta función selecciona la o las restricciones que maximizan la suma de la satisfacción global potencial que inducen si son relajadas. 5) Una vez seleccionada la o las restricciones con opción a ser relajadas, se elige una aleatoriamente y se compone el nuevo requerimiento de compra tBreq1 , en el que se modifica únicamente la restricción elegida. Las tres primeras fases del algoritmo se centran en la búsqueda de aquellas restricciones del requerimiento de compra tBreq1 que si se relajan comportan la menor pérdida de satisfacción global potencial posible. Una vez detectadas estas restricciones, la fase 4) tiene en cuenta sólo estas restricciones, y si existe un requerimiento de relajación, las preferencias que tiene el proveedor por la relajación de éstas. Se está teniendo en cuenta por tanto no sólo el criterio local de minimización de pérdida de satisfacción, sino también el argumento de rechazo del proveedor. B3: Generate Purchase Requirement Valuation El mecanismo aborda el problema de la valoración de requerimientos de compra. Sólo se activa internamente en la regla de transición TR8 tras la generación de un requerimiento de compra. En este caso, se utiliza la función de valoración de requerimientos de compra fvrc : Breq vBreq . Algoritmo (Valoración de requerimiento de compra) 1) Dado un requerimiento de compra a enviar tBreq1 , se obtiene un vector con los grados de satisfacción global potencial para todos los posibles requerimientos de compra ficticios, resultantes de relajar cada vez sólo una de las restricciones en tBreq1 . Los grados de satisfacción global potencial de aquellas restricciones no relajables toman valor 0: t 2 t 2 B ki Breq k1 req ... 2) Se toman los elementos del vector anterior y se define un nuevo vector normalizado que representa la valoración del requerimiento de compra: t 2 vBreq t 2 k1 ki 1 req ,..., 1 req t 2 t 2 k1 ki req sum 1 ,..., 1 req El mecanismo define la estrategia de valoración de requerimientos de compra como una estrategia basada en los grados de satisfacción potenciales. Maticemos de qué grados de satisfacción potencial estamos hablando, describiendo para ello un proceso normal de valoración. Cuando se ejecuta el mecanismo B2: Generate Purchase Requirement, se genera un requerimiento de compra tBreq1 , a partir de un requerimiento ya enviado antes denominado tBreq . Para la generación de tBreq1 se han utilizado los grados de satisfacción potencial ficticios de tBreq . En cambio, en la generación de valoración se están generando los grados de satisfacción potencial ficticios de la propuesta tBreq1 , que todavía no se ha enviado. En definitiva, se están estimando los grados de satisfacción potencial que se podrían conseguir si el Sector de Compras vuelve a solicitar un nuevo requerimiento. B4: Consider Offers Este mecanismo está completamente especificado. Se activa únicamente cuando se recibe una oferta de venta (ver TR12). La consideración de la oferta está representada en las reglas de transición TR16, TR17 y TR18. La regla TR16 se dispara cuando la oferta de venta recibida no cumple el requerimiento de compra al completo, mientras la regla TR17 se activa cuando se acepta la oferta. La regla TR18 representa un rechazo frontal de la oferta de venta. B5: Consider Withdrawal El mecanismo identifica una necesidad de abandono de un diálogo de negociación. El mecanismo se activa en tres supuestos: en la transición TR5 cuando el Sector de Compras no puede relajar más sus requerimientos de compra; en la transición TR7 cuando se recibe un aviso de abandono asíncrono del proveedor mediante la locución L11: withdraw_dialogue(.); y finalmente en la transición TR19 (pasando por el delegador) cuando el proveedor emite un compromiso de venta que completa la transacción. Vemos por tanto que la única tarea explícita de este mecanismo es emitir la locución L11: withdraw_dialogue(.), y que la identificación de la necesidad de abandono está implícita en las reglas de transición. 5.3 Instanciación de los mecanismos de decisión del Proveedor En esta sección se explica la propuesta detallada de cada uno de los mecanismos de decisión del proveedor. S1: Recognize Category Este mecanismo está completamente especificado. Sólo se activa cuando se recibe una petición de inicio de diálogo (ver TR1). Si se encuentran productos sobre los que negociar se emite la locución L2: enter_dialogue(.) para confirmar la participación (ver TR4), y si no se encuentran se entra en estado de espera (ver TR3). S2: Assess Purchase_Requirement Cabe recordar que el objetivo de este mecanismo es buscar productos que satisfagan los requerimientos de compra, y si existen, seleccionar los más adecuados. Si no hay productos, se activa la regla de transición TR13, la cual transfiere el requerimiento de compra para ser utilizado como entrada a los procedimientos de generación de argumentos. Cuando existen productos se selecciona sólo uno de ellos mediante la función de selección de ofertas de ventas fsov : Breq , S S . Dicha función toma como entrada el requerimiento de compra que se está analizando, y el subconjunto de productos del catálogo que satisfacen dicho requerimiento. La función retorna el producto que se va a utilizar como oferta de venta. Dicha función se basa en dos criterios fundamentales: la utilidad uj que reporta la venta del producto, y el número de veces que dicho producto ha sido ofertado durante el transcurso del diálogo. Según esta estrategia, cuando un proveedor tiene que seleccionar un producto para formar parte de una oferta de venta, en primer lugar tiene que satisfacer las necesidades expresadas por el Sector de Compras. Dado que pueden aparecer en el catálogo múltiples productos que satisfagan un requerimiento de compra, la decisión final tendrá que ser función de los dos únicos criterios existentes, la utilidad que le reporte al proveedor ofrecer el producto, y el número de veces que se haya ofertado un producto. Hay que tener en cuenta que un producto que inicialmente sea rechazado, no tiene por qué ser descartado en iteraciones futuras del diálogo por una razón fundamental: el Sector de Compras podría realizar concesiones. A continuación se detalla el algoritmo para implementar esta función. Algoritmo (Selección de ofertas de venta) 1) Por cada producto se aplica la fórmula: aceptación utilidad 1 cantidad de envíos Se seleccionan los productos cuyo nivel de aceptación sea igual al máximo. 2) De los productos seleccionados en 2) se elige uno aleatoriamente. Este producto es el que retorna la función. 3) Se actualiza el almacén de información AI(Ps) del proveedor, incrementando el número de envíos asociado al producto elegido en 2). El elegir el producto de mayor utilidad es consecuente con la racionalidad del agente al respecto de la maximización de la utilidad. Seleccionar el producto menos veces enviado responde al razonamiento lógico de estimar que si un producto no ha sido aceptado antes, probablemente tampoco será aceptado ahora, y es mejor probar por tanto con otro producto que dando la misma utilidad, no haya sido enviado todavía. S3: Generate Potential Sale-Offers La generación de ofertas de venta potenciales constituye el núcleo del sistema de argumentación del proveedor. Tiene un único punto de activación en la regla de transición TR13, cuando el mecanismo S2: Assess Purchase Requirement de análisis de requerimiento de compra solicita que se haga un rechazo argumentado. La única salida del mecanismo (una lista con ofertas de venta potenciales) activa internamente en la transición TR14 el mecanismo S4: Generate Relax Requirement para la composición de un requerimiento de relajación. Se define un único marco estratégico acotado por la función fgovp : Breq , S , vBreq S de generación de ofertas de venta potenciales. Las entradas de la función son un requerimiento de compra tBreq sobre el que se quiere argumentar un rechazo, el catálogo de productos del proveedor S del que se tienen que extraer los productos candidatos o preferidos, y una valoración vBreq del requerimiento de compra. La función devuelve como resultado una lista SP con los productos que el proveedor considera deben ser tomados como referencia para generar requerimientos de relajación. En la especificación del mecanismo son dos los criterios que el autor tuvo en cuenta: la utilidad y la viabilidad. En función de todos estos datos desarrollamos la implementación de fgovp. Implementación de fgovp Teniendo en cuenta que la función debe discriminar productos para ser incluidos en una lista de ofertas de venta potenciales, se define en primer lugar una función prefer(sj) que asigna un valor de preferencia a cada uno de los productos del catálogo. Esta función se llama tantas veces como productos tenga el catálogo S. Dado que los dos criterios tenidos en cuenta son los de utilidad y viabilidad, el primero interno, y el segundo externo, se define una constante que cuantifica el perfil receptivo del proveedor modulando la importancia que van a tener los argumentos procedentes del Sector de Compras. Por lo tanto la función prefer queda definida de la siguiente manera: prefer (s j ) u j 1 viability p j , tBreq , vBreq Puede verificarse que el valor controla en qué medida se tienen en cuenta los factores internos y externos, a la hora de decidir la preferencia que tiene el agente proveedor porque una entrada del catálogo se constituya como oferta de venta. En un extremo, si 1 , la función queda como prefer (s j ) u j , mientras que si 0 la función queda como prefer (s j ) viability p j , tBreq , vBreq . El primer caso no tiene en cuenta ni el requerimiento de compra recibido, ni su posible valoración, de manera que el criterio de selección recae únicamente en la utilidad local. El segundo caso no tiene en cuenta la utilidad, por lo que el criterio de selección de productos se basa únicamente en la viabilidad estimada de la venta. Basándonos en las pruebas llevadas a cabo por el autor fijamos el valor de la constante en 0.5 para contar con proporciones iguales de ambos criterios. Una vez que se han calculado los valores de preferencia con la función prefer para todos los productos del catálogo, es posible generar la lista de ofertas de venta potenciales mediante un filtrado por umbral de dichos valores. A continuación se desarrolla el algoritmo para el filtrado de valores de preferencia para la obtención de ofertas de venta potenciales. Algoritmo. (Filtrado de valores de preferencia para la obtención de ofertas de venta potenciales) 1) Se selecciona aquella entrada del catálogo cuyo valor de preferencia calculado sea el mayor. Estas entradas constituyen la salida SP de la función fgovp. Hasta aquí, toda la funcionalidad de fgovp está descrita, a excepción del cálculo o estimación de la viabilidad que desarrollamos a continuación, y que constituye sin duda la parte más compleja del mecanismo. Definición de la estimación de viabilidad viability La estimación de viabilidad de venta de un producto pj se basa conforme a la descripción del mecanismo en: el grado de similitud entre el producto pj y el requerimiento de compra tBreq ; y una estimación de la valoración que hará el Sector de Compras sobre el producto en cuestión si se ofrece para la venta. Estos aspectos se condensan en la siguiente definición de estimación de viabilidad: viability sim p j , tBreq Ebv vBreq El primer término representa una estimación de la similaridad entre el producto pj y el requerimiento de compra tBreq . El segundo término define la estimación de la valoración del Sector de Compras como una función de estimación que depende del producto pj, y de la valoración del requerimiento de compra emitida por este. El operador tiene la función de ponderar ambos términos (este operador se describe más abajo). Abordamos ahora cada término por separado. Similaridad La similaridad se define como una función de la distancia de la siguiente forma: sim p j , tBreq 1 dist ( p j , tBreq ) donde dist ( p j , tBreq ) representa la estimación de la distancia normalizada existente entre un producto pj y un requerimiento de compra tBreq . Para estimar la distancia se utiliza una medida basada en la distancia euclídea. n dist ( p j , tBreq ) sqrt dist aij , tB,ireq i1 / n 2 donde dist (a ji , tB,ireq ) representa la distancia del atributo aji del producto pj al conjunto de restricciones incluidas en tBreq que hacen referencia a dicho atributo. Esto significa que en primer lugar se deben calcular las distancias del atributo a cada una de estas restricciones. Este cálculo es una medida de la distancia al límite estimado más cercano que delimita la restricción dura correspondiente. Sin embargo, esta medida de distancia entre un atributo y un límite de una restricción dura es una medida absoluta que tiene que ser normalizada. Es necesaria la definición de los siguientes valores: el valor de reserva estimado aires para cada uno de los atributos; el límite más lejano a cada uno de los atributos aji, que se obtiene mediante la función boundary(tB,ireq ) ; la velocidad de relajación estimada para cada atributo aji que se denomina it (0, ) ; y por último, el grado de certidumbre de la estimación de distancia de un atributo aji llamado it [0, ] . Los valores de reserva, de velocidad de relajación y el grado de certidumbre forman parte del modelo de requerimientos del proveedor, en concreto del conjunto de creencias t {( it , it ), i 1, ..., m} , donde it (aires , it ) . Comentamos a continuación cada uno de estos valores. El valor de reserva aires expresa la creencia del proveedor al respecto de cuál es el valor de relajación límite que estaría dispuesto a asumir el Sector de Compra para un determinado atributo. En nuestro caso tomamos el valor promedio de cada atributo teniendo en cuenta todos los productos del catálogo. De esta creencia parcial no se tiene por qué inducir la creencia de que el Sector de Compras estaría dispuesto a relajar todas las restricciones hasta estos valores de reserva simultáneamente. Si esto fuese así, el proveedor podría sencillamente rechazar todas las propuestas hasta que el Sector de Compras relajase todas las restricciones. Sin embargo, en un entorno de múltiples vendedores, la utilización por parte del proveedor de una estrategia de este tipo está también condicionada por la aversión al riesgo de perder una venta. El límite más lejano requiere en primer lugar el cálculo de los límites que definen las restricciones duras que restringen un atributo aji. Se asume que estos límites son los más cercanos al atributo. Una vez que se tienen los límites se pueden calcular las distancias absolutas al atributo. El límite más lejano será el límite que genera la mayor de estas distancias. Es decir, la distancia absoluta del atributo aji a un requerimiento de compra, será la mayor de las distancias de dicho atributo a las restricciones duras que restringen dicho atributo. La velocidad de relajación estimada es una estimación de la predisposición del Sector de Compras a relajar las restricciones sobre un determinado atributo. En este caso no se estima el valor de reserva, sino la velocidad con que se estima se va a llegar al valor de reserva. La idea es que una distancia calculada sobre un atributo para el que se estima una relajación rápida, debe interpretarse como una distancia menor en relación con una distancia igual calculada sobre un atributo para el que se estima una relajación lenta. El grado de certidumbre it es una medida de la certidumbre que tiene el Sector de Compras al respecto de la medida de distancia realizada para el atributo aji. Finalmente presentamos a continuación la función dist (a ji , tB,ireq ) que aglutina todos estos conceptos. a ji boundary(tB,ireq ) 1t t i * 1 (abs res ) 1 ai boundary(tB,i ) i req dist (a ji , tB,ireq ) 0 1 a ji [aires , boundary(tB,ireq )) a ji tB,ireq resto Esta estimación de distancia tiene las siguientes propiedades: 1- La distancia está normalizada a 1 en todos los casos. 2- Los valores de atributo que sobrepasan los valores de reserva estimados se fijan a distancia 1. 3- Si el atributo satisface las restricciones la distancia es 0. 4- Si el atributo se encuentra entre el valor de reserva y el límite de las restricciones, la distancia es función de la lejanía a las restricciones, y está normalizada por la distancia entre el valor de reserva y el límite de las restricciones. Es importante señalar que en nuestro caso los valores de los parámetros fueron prefijados en base a los resultados de las experiencias llevadas a cabo por el autor. En el caso del grado de certidumbre se verifica que a medida que éste se hace menor a 1, la distancia estimada se hace mayor. Por lo que resulta óptimo un valor de 1 para dicho parámetro. En el caso de la velocidad de relajación, el estudio demuestra que un valor de 1 converge más rápidamente a la distancia estimada. Estimación de la valoración del Sector de Compras La estimación de la valoración que el Sector de Compras haría de una oferta de venta está directamente relacionada con la valoración explícita que éste puede hacer sobre un requerimiento de compra, es decir, de vBreq . Esta valoración, siguiendo un razonamiento parecido al que nos llevaba a definir la velocidad de relajación it y el grado de certidumbre it , va a influir en la estimación de distancia de la siguiente manera. Si las restricciones sobre un atributo aji son muy valoradas, significa que la predisposición del Sector de Compras a relajar dichas restricciones es baja, con lo que la medida de distancia debe ponderarse al alza. Así, cuando el Sector de Compras emite valoraciones de compra el autor propone la siguiente función de viabilidad que implementa el operador : n viability 1 sqrt( (dist (a ji , tB,ireq ) vboundary( t ,i ) ) 2 / n) Breq i 1 donde vboundary( t ,i Breq ) representa la preferencia que el Sector de Compras tiene porque la restricción más lejana al atributo aji sea satisfecha. La función prefer queda finalmente como: n prefer ( s j ) u j (1 ) (1 sqrt( (dist (a ji , tB,ireq ) vboundary( t ,i ) ) 2 / n)) i 1 Breq S4: Generate Relax Requirement La generación de requerimientos de relajación se activa en la regla de transición TR14, cuando el mecanismo S3: Generate Potential Sale-Offers ha generado la lista de ofertas de venta potenciales SP. La ejecución de este mecanismo activa la regla de transición TR15, que emite un requerimiento de relajación mediante la locución L5: prefer_to_sell(.). El marco estratégico que se define en este mecanismo es el de la composición de requerimiento de relajación, especificado mediante la función fcrr : Breq , S P Breq de composición de requerimiento de relajación. Dicha función recibe como parámetros de entrada: el requerimiento de compra Breq cuyo rechazo se quiere argumentar, y la lista de ofertas de venta potenciales SP. La salida de la función es el requerimiento de relajación Breq . Se especifica además que la estrategia debe estar basada en la generación de un mapa de distribución de frecuencias de cumplimiento de restricciones en Breq por parte de los productos en SP. En cualquier caso la función fcrr debe basar su estrategia en cómo tratar el no cumplimiento de restricciones por parte de los productos. Para no sobrecargar la técnica de generación del requerimiento de relajación con excesivos matices se aplica el siguiente algoritmo de composición de requerimiento de relajación: Algoritmo. (Composición de requerimiento de relajación) 1) Se compone el requerimiento de relajación como un vector rk1 , ..., rki , donde rkx 1 indica que la restricción Rk x no es satisfecha por producto alguno, y rkx 0 indica que la restricción Rk x es satisfecha por lo menos por un producto. Por ejemplo, el requerimiento de relajación del tipo (0,0,0) para 3 atributos indica que todas las restricciones son satisfechas individualmente (no hace falta que sea simultáneamente) por al menos un producto. Es decir, el proveedor no tiene una preferencia especial porque una restricción sea relajada, porque cualquier relajación puede conducir a la venta de un producto en SP. S5: Accept or Reject Offer Este mecanismo está completamente especificado. Sólo se activa cuando se recibe una locución L9: agree_to_buy(.) del Sector de Compras con un compromiso explícito de compra (ver TR17). Si se acepta el compromiso de compra se activa la regla de transición TR19, de forma que el proveedor emite la locución L10: agree_to_sell(.) confirmando la transacción. Si no se acepta el compromiso de compra se activa la regla de transición TR20, donde el proveedor emite la locución L8: refuse_to_sell(.) en la que se rechaza la propuesta. S6: Consider Withdrawal El mecanismo identifica una necesidad de abandono de un diálogo de negociación. El mecanismo se activa en la transición TR6 cuando el agente Sector de Compras informa del abandono del diálogo mediante la locución L11: withdraw_dialogue(.). La única tarea explícita de este mecanismo es emitir la locución L11: withdraw_dialogue(.). En definitiva, el proveedor sólo considera el abandono del diálogo cuando el Sector de Compras decide abandonar. 5.4 Detalles de diseño En esta sección mostramos detalles del diseño e implementación del sistema de negociación automática que incorpora los conceptos hasta el momento desarrollados. La implementación en general de divide en dos ámbitos fundamentales: uno que se ocupa de la comunicación entre agentes y la gestión de los mismos; y el otro que abarca toda la lógica de negociación, es decir, la implementación de los agentes, sus comportamientos y transiciones, las locuciones, las ontologías y los mecanismos de decisión. El primer ámbito lo abordamos utilizando la plataforma JADE, como ya hemos mencionado. Por lo tanto, contamos con un servidor de agentes el cual los contiene y los comunica, liberándonos de dichas tareas en el proceso de diseño e implementación. Para el segundo ámbito, es decir, la lógica de negociación, utilizamos el lenguaje Java. Todo el desarrollo podría funcionar en un solo servidor, pero evidentemente este sería un entorno no distribuido. Como ya hemos mencionado, una de las ventajas del sistema de negociación radica en la posibilidad de distribuirlo y así integrar sistemas heterogéneos. Un proveedor que cuenta con el apoyo de un desarrollador calificado puede implementar su agente negociador sin ningún inconveniente, conociendo el protocolo de negociación. 5.4.1 Arquitectura del sistema En la figura 7 presentamos la vista de despliegue de todo el sistema. Figura 7 Vista de despliegue En la vista podemos observar la distribución completa del sistema, aunque como mencionamos anteriormente, todos los módulos podrían funcionar en una sola máquina. Cabe señalar que toda conexión entre los módulos puede producirse a través de la Web por accesos públicos. El envío de e-mail se produce con el fin de informar el resultado de una negociación; aunque no está contemplado en el diagrama, este correo se envía a través de la Web utilizando el servidor de correos de Gmail. Podemos ver que los servidores Municipalidad y proveedor tienen diferencias sustanciales, ligadas a los modos en que se ejecutan sus respectivas lógicas. El servidor Municipalidad tiene corriendo un contenedor Web Tomcat que le permite al titular de la Oficina de Compras ejecutar la aplicación por medio de un navegador Web. Cada inicio de negociación por parte del usuario, determina en el servidor una comunicación con el Contenedor Principal JADE para solicitar la creación de un agente negociador municipal. A su vez, este mismo servidor se encarga de la búsqueda de servicios de venta en el DF (Directory Facilitator), la ejecución de los mecanismos de decisión y de la notificación por correo electrónico al usuario de los resultados de la negociación. El servidor proveedor, en cambio, ejecuta un proceso en Java (a través de la JVM o Máquina Virtual de Java) el cual le solicita al Contenedor Principal JADE la creación del agente correspondiente con todos los comportamientos necesarios para llevar a cabo una negociación. Además, publica su servicio de vendedor en el DF y, una vez iniciada una negociación, efectúa constantes accesos a la base de datos que contiene los productos y el AI (Almacén de información). Luego de concluirse la negociación, envía un correo electrónico al proveedor para notificarlo del resultado de la misma. Se diseñó de esta manera porque no es necesario que un proveedor ejecute constantemente instancias del sistema, con tener un proceso a la espera de una solicitud de compra por parte de la Municipalidad es suficiente. En contra parte, el director de la Oficina de Compras debe ejecutar nuevas instancias por cada requerimiento de compra que arribe a su Oficina. Cada ejecución implica el establecimiento de nuevos parámetros de negociación (producto deseado y valores difusos para sus atributos), por lo que una interfaz de usuario es de suma importancia. 5.4.2 Diseño e implementación de la lógica de negociación Como mencionamos anteriormente, la lógica de negociación se compone de los agentes inteligentes, los comportamientos y las transiciones entre ellos, las locuciones, las ontologías y los mecanismos de decisión. En secciones anteriores indicamos que JADE es un framework de desarrollo de software destinado a desarrollar sistemas multiagente y aplicaciones que se ajusten a las normas FIPA para agentes inteligentes. Incluye dos productos principales: una plataforma de agentes compatibles con FIPA y un paquete para desarrollar agentes en Java. JADE ha sido codificado totalmente en Java, por lo que, un desarrollador, a fin de aprovechar el framework, debe codificar sus agentes en Java extendiendo clases o creando instancias del mismo (Bellifemine, Caire, Trucco, & Rimassa, 2005). 5.4.2.1 Implementación de agentes inteligentes y sus componentes El framework JADE cuenta con una clase de agente (Agent) que representa la base común para la implementación de los agentes definidos por el usuario. Por lo tanto, desde el punto de vista del programador, un agente JADE es simplemente una instancia de una clase definida por el usuario en Java que extiende la clase Agent. Esto implica la herencia de características para llevar a cabo las interacciones básicas con la plataforma de agentes (registro, configuración, administración remota, etc.) y un conjunto básico de métodos que pueden ser redefinidos para implementar el comportamiento personalizado del agente (por ejemplo, envío y recepción de mensajes, utilización de protocolos de interacción estándar, etc.). La clase Agent cuenta con el método setup() que es el punto donde se inicia cualquier actividad del agente. Por lo tanto, para inicializar los agentes, implementamos el método setup(). Esta inicialización consiste en la registración en la plataforma, la instanciación de los comportamientos y la creación de la máquina de estados que ejecutará cada comportamiento. Para que los agentes lleven a cabo tareas específicas definimos subclases de la clase Behaviour (Comportamiento): creamos instancias de ellas y las agregamos a sus respectivas máquinas de estados, las cuales permiten establecer los órdenes de ejecución entre los comportamientos de acuerdo a cómo hayan finalizado cada uno de ellos. Cada subclase de Behaviour hereda sus métodos, pero nuestro interés se enfocó particularmente en la implementación de tres de ellos: el método action() que es el encargado de llevar a cabo la tarea del comportamiento, done() es el método que se invoca cuando la tarea finalizó y onEnd() permite retornar un número entero que será el que determine el próximo comportamiento a ejecutar en la máquina de estados. En lo que respecta a locuciones FIPA/ACL, las cuatro que hemos utilizado para agrupar las originales necesarias para el sistema, son: inform, propose, accept-proposal y refuse. La estructura de la ontología define dos clases abstractas, Concept y Predicate, y dos clases derivadas de Concept: AID (Agent Identifier) y AgentAction. Las clases que representen una acción, deben ubicarse bajo AgenteAction. AID es una clase predefinida que especifica el identificador de un agente, es decir, su nombre en la plataforma. El resto de las clases definidas, constituyen realmente la ontología del sistema. Para facilitar la implementación de las clases que componen toda la ontología del sistema, se utilizó el software Protégé, el cual es un editor de ontología, gratuito y de código abierto. Este programa tiene un gran soporte por parte de la comunidad académica, gubernamental, y usuarios corporativos. 5.4.2.2 Agente municipal: Mecanismos de decisión En esta sección nos enfocaremos en el diseño e implementación de los mecanismos de decisión del agente negociador que representa a la Municipalidad. A continuación podemos observar el diagrama de clases de los módulos que le permiten al agente llevar a cabo una negociación. Figura 8 Diagrama de clases para los mecanismos de decisión del agente municipal La clase Buyer_Decision_Logic representa el núcleo de la unidad de negociación del agente municipal. Esta clase es instanciada en el instante en que la negociación es iniciada y el agente es creado en la plataforma. Cada comportamiento agregado a la máquina de estados tiene la posibilidad de utilizarla en caso de que sea necesario. Entre sus atributos podemos mencionar dos que remiten cierta utilizada: el identificador del agente proveedor (seller:AID) para enviarle mensajes en cualquier parte del código y el identificador de conversación (conversationid:String) para mantener un control de las conversaciones a fin de evitar inconvenientes en negociaciones concurrentes. Otro atributo importante de Buyer_Decision_Logic es un arreglo de instancias de la clase NegotiationElement, la cual representa cada restricción difusa que constituye las preferencias del agente municipal. Contiene entre otras cosas, las diferentes etiquetas difusas con sus respectivos niveles de cortes (instancias de la clase EtiquetaDifusa), un valor booleano que indica si el atributo del producto es incremental o no 6, y métodos necesarios para operar con dicha restricción difusa (relajarla, obtener la restricción dura al nivel de corte actual, verificar si un determinado valor se encuentra dentro de ella, calcular su valoración y el grado de pertenencia). Los métodos de la clase Buyer_Decision_Logic son los encargados de poner en funcionamiento los mecanismos de decisión del agente municipal. La gran mayoría son invocados desde los comportamientos del agente y en muchos casos determinan el próximo comportamiento hacia donde seguirá la ejecución en la máquina de estados. De las funciones que posee la clase, podemos destacar las dos más importantes: la modificación de un requerimiento de compra y la evaluación de una oferta de venta. En el siguiente diagrama de secuencia observamos la primera función. 6 Un atributo es incremental cuando la pérdida de satisfacción global se produce elevando el valor del límite superior en caso de una relajación. El atributo precio es un ejemplo, ya que es menos conveniente aceptar valores altos respecto a los valores bajos. Un atributo no incremental es el caso contrario, como puede ser la calidad de un producto, ya que son menos convenientes valores bajos del mismo. Figura 9 Diagrama de secuencia para la modificación de un requerimiento de compra En el comportamiento B2: Generate Purchase Requirement se genera el primer requerimiento o se modifica uno ya existente. Por lo tanto, desde dicho comportamiento se invoca el método generatePurchaseRequirement(ACLMessage msg): boolean. El booleano que retorna determina la siguiente ejecución: si es verdadero significa que se pudo generar un requerimiento de compra, por lo que la ejecución continua en el comportamiento B3: GeneratePurchaseRequirementValuation; si es falso nos encontramos en el caso contrario donde se debe abandonar la negociación, es decir, la ejecución continuará en B5: Consider Withdrawal. El mensaje ACL, parámetro del método, permite obtener el contenido del mismo para ser procesado, y a su vez, de acuerdo al tipo de locución, determinar si se debe generar el primer requerimiento de compra (seleccionando una restricción al azar) o si se debe modificar (agregando una restricción aleatoriamente de las no enviadas o relajando una ya enviada). El diagrama de secuencia muestra el caso en que el requerimiento de compra debe ser modificado relajando algún atributo. Para el caso de la evaluación de una oferta de venta, la ejecución puede ser visualizada en el siguiente diagrama de secuencia. Figura 10 Diagrama de secuencia para la evaluación de una oferta El comportamiento B4: Consider Offers recibe la oferta de venta a través de una locución willing_to_sell. Desde este comportamiento se invoca el método considerOffers(Willing_to_sell willing):int de la clase Buyer_Decision_Logic para ser evaluada. El número entero que retorna el método determina la continuidad de la ejecución de acuerdo al resultado de la evaluación: puede aceptar o rechazar la oferta, continuando en el estado Delegator, o puede generar una contra oferta lo que implica continuar en B2: Generate Purchase Requirement. El parámetro willing permite obtener toda la información necesaria para ser procesada por el método. Internamente la primera evaluación verifica si todas las restricciones enviadas fueron cumplidas, en caso contrario se rechaza la oferta. La segunda evaluación consiste en verificar el cumplimiento de las restricciones no enviadas, si alguna no se cumple se deberá generar un nuevo requerimiento de compra. La tercera implica el cálculo de los grados de satisfacción global y potencial para compararlos; si el grado de satisfacción global supera o iguala al potencial, la oferta se acepta; en caso contrario la oferta se rechaza. 5.4.2.3 Agente proveedor: Mecanismos de decisión De igual modo que en la implementación de los mecanismos de decisión del agente municipal, la clase Seller_Decision_Logic representa la unidad funcional que le permite al agente proveedor llevar a cabo una negociación. Esta clase también se instancia en el momento en que una negociación es iniciada, pero en este caso el agente se crea en la plataforma cuando el proceso Java es ejecutado. Sus atributos son similares a los del agente municipal: el identificador del agente municipal (buyer: AID) como un acceso directo para el envío de mensajes, y el identificador de conversación (conversationid:String) para el control de conversaciones. Figura 11 Diagrama de clases para los mecanismos de decisión del agente proveedor La clase NegotiationElement es un concepto diferente para este caso. En el agente municipal representa una restricción difusa, en el agente proveedor está asociado al concepto producto. Cuenta con métodos para determinar el cumplimiento de restricciones duras y para el cálculo de preferencia, entre otros. Indudablemente, entre las funciones que tiene la Seller_Decision_Logic, la más importante es la generación de ofertas potenciales. El método encargado de dicha tarea es generatePotencialSaleOffers(); a continuación podemos observar su diagrama de secuencia. Figura 12 Diagrama de secuencia para la generación de ofertas potenciales Cuando en el transcurso de la negociación se llega al comportamiento S3: Generate Potencial Sale-Offers (clase S3_GeneratePSOffers) debe generarse una oferta potencial debido a que el agente proveedor no pudo obtener de entre sus productos uno que se ajuste exactamente al requerimiento del agente municipal. El comportamiento invoca al método generatePotencialSaleOffers() para obtener dicha oferta. El requerimiento de compra actual se almacena como un atributo dentro de la misma clase Seller_Decision_Logic. Como mencionamos en capítulos anteriores, para obtener la oferta potencial es necesario calcular el valor de preferencia de cada producto y quedarnos con aquel cuyo cálculo sea el mayor. La clase NegotiationElement es la que lleva adelante este cálculo con el método getPrefer. Interiormente se realizan otras operaciones anidadas, es decir, la preferencia necesita del valor de viabilidad, que a su vez necesita de la sumatoria de operaciones con la distancia entre el valor del atributo del producto y la restricción dura, que a su vez necesita del valor de reserva y el boundary. 5.5 Resumen general Anteriormente hemos introducido los conceptos del modelo de negociación utilizado en la presente tesis y sus mecanismos. En este capítulo presentamos la instanciación del mismo, es decir, se detalló cada una de las posibles formas de llevar a cabo las tareas que deben realizar los mecanismos descriptos. Cada uno de los participantes del modelo, Municipalidad y proveedor, poseen en sus mecanismos estrategias y algoritmos que insumen un mayor grado de análisis. En el caso del agente comprador o Municipal, las principales estrategias radican en la generación de los requerimientos de compra y en la valoración de los mismos. Ambas estrategias se basan en el cálculo del grado de satisfacción global potencial, y son parte fundamental de las herramientas de argumentación con las que cuenta el agente. Por un lado permiten plasmar el requerimiento de compra establecido por el usuario (el titular de la Oficina de Compras) y la importancia de que ciertos atributos sean satisfechos, en términos que sean entendidos por los agentes; y por otro establece los criterios con los que el agente puede evaluar una oferta. La estrategia fundamental y que compone el núcleo del sistema de argumentación del proveedor es sin duda la generación de ofertas potenciales. De esta forma el agente puede conducir la negociación hacia espacios de soluciones que le resulten más beneficiosos, teniendo en cuenta en la evaluación factores internos (el valor de utilidad) y externos (la cercanía de un producto al requerimiento de compra recibido). Estos mecanismos fueron implementados en el sistema de negociación que acompaña a la tesis. En los siguientes capítulos desarrollamos dos casos de estudios para presentar los resultados y verificar que el modelo de negociación funciona correctamente y es sin dudas una herramienta importante para facilitar los procesos de compras en un ámbito municipal. Capítulo 6 Evaluación experimental En el presente capítulo hacemos un análisis sobre dos casos de estudios basados en la utilización del sistema de negociación automática desarrollado y que agrupa todos los conceptos expuestos en la presente tesis. El primero de ellos presenta una situación de negociación entre un Municipio y un proveedor con el fin de verificar los beneficios que proporciona el sistema. El segundo caso de estudio evalúa la incidencia en la duración de una negociación cuando se varían los diferentes parámetros que la componen (cantidad de productos, número de atributos por producto, etc.). 6.1 Caso de estudio 1: Compra de una impresora El primer caso de estudio consiste en entablar una negociación bilateral entre el Municipio y un proveedor determinado para la adquisición de una impresora que se ajuste (o se acerque) a las necesidades del comprador. La intención de este caso de estudio es presentar el modelo y la implementación del sistema multiagente en forma práctica, haciendo un análisis de cada paso de la negociación: el diálogo que se produce, los diferentes cálculos llevados a cabo, las transiciones entre estados, etc. Además se expondrán las conclusiones contrastándolas con un ámbito real. 6.1.1 Introducción El caso contempla la necesidad de compra de una impresora para el área de Rentas. El principal uso que se le pretendía dar era el de imprimir grandes lotes de recibos de tasas municipales para ser repartidas entre los ciudadanos, por lo que debía ser una impresora potente, rápida y de buena calidad. La tarea de encontrar un modelo de impresora que se adapte a los atributos indicados fue encomendada al área de Sistemas por considerarse más idónea. En el transcurso de 2 horas se determinó que una buena opción era la impresora Lexmark MS811dn. Los pedidos de cotización fueron entregados a cuatro proveedores registrados de la Municipalidad. Dos de ellos no contaban con el producto en cuestión por lo que no respondieron al pedido. De los dos restantes se optó por el de menor precio. Cabe señalar que hasta la llegada de la última cotización se invirtieron 2 días para determinar el proveedor al que finalmente se le efectuó la compra. 6.1.2 Desarrollo del caso de estudio Este caso consiste de una negociación bilateral por lo que sólo contaremos con la ejecución de dos agentes inteligentes, uno para cada parte. El vendedor dispone de un catálogo de 78 impresoras, especificadas en atributos valorizados, los cuales son: precio (en pesos), páginas por minuto (PPM), capacidad de entrada estándar (medido en hojas), ciclo mensual de trabajo máximo (medido en hojas), consumo eléctrico (medido en vatios) y un valor de calidad. Los valores para cada atributo fueron extraídos de un catálogo en la Web (www.pixmania.es), a excepción de la calidad la cual es un valor arbitrario. El catálogo contiene a la impresora Lexmark MS811dn con una utilidad de 0.99 sobre 1. La elección de este valor surge de la intención de verificar que la negociación será conducida hacia dicho producto, por ser conveniente para el vendedor y por contar con atributos aceptables para el comprador. Las características de esta impresora en términos de lenguaje difuso son: Precio: MEDIO Páginas por minuto: MUY ALTO Capacidad de entrada estándar: MEDIO Ciclo mensual de trabajo máximo: MUY ALTO Consumo eléctrico: MEDIO Calidad: MUY ALTA Es importante señalar que estas expresiones lingüísticas que definen los intervalos difusos se consensuan entre las partes. Para facilitar este acuerdo, se establecen valores máximos y mínimos a cada atributo. Luego, el intervalo formado entre ambos valores se divide en subintervalos de iguales dimensiones los cuales se corresponden con cada término lingüístico. Como ejemplo tomamos el atributo precio; establecemos un valor mínimo de 500 y un máximo de 18000. A este rango lo dividimos por cinco que es la cantidad de términos lingüísticos que hemos utilizado (muy bajo, bajo, medio, alto y muy alto). (18000 – 500) / 5 = 17500 / 5 = 3500 Esto significa que cada intervalo difuso para el atributo precio tiene una dimensión de 3500 unidades. Por lo tanto, tenemos que para un precio muy alto su intervalo difuso se compone de 18000 para el límite superior, y 18000 – 3500 = 14500 para el límite inferior. En realidad el intervalo es [14501 – 18000], porque el valor 14500 representa el límite superior para un precio alto. Evidentemente el caso ideal a priori comprendería un precio y un consumo eléctrico muy bajos y valores de PPM, capacidad de entrada estándar, ciclo mensual de trabajo máximo y calidad muy altas. Aquí radica el desafío del presente caso de estudio: partiendo de un requerimiento ideal por parte del comprador, la negociación debería ser conducida hacia un producto real que sea igualmente satisfactorio para ambas partes. 6.1.2.1 Apertura del diálogo Para la primera fase contamos con un agente vendedor ejecutándose en un servidor y cuyo servicio de venta se encuentra registrado en las páginas amarillas de la plataforma JADE. El servicio registrado sólo sirve de nexo entre agentes vendedores y compradores, no indica ni las categorías ni los productos del catálogo con los que cuentan los vendedores. A través de un navegador Web ingresamos a la página del comprador en la cual especificamos la categoría (para este caso Impresora) y el requerimiento de compra a partir de restricciones difusas. Como mencionamos anteriormente, planteamos el caso ideal para el requerimiento de compra inicial, como puede observarse en la figura 13. Al momento de indicar el inicio de la negociación (presionando el botón “Negociar!”), internamente se crea un agente comprador en la misma plataforma del vendedor con toda la información necesaria para desarrollar la negociación. Figura 13 Selección del requerimiento de compra inicial Cuando el agente comprador encuentra un servicio de venta en las páginas amarillas contacta al vendedor enviándole la locución L1: open_dialogue generada por el mecanismo B1: Recognize Need. En salida de este mecanismo (have_need) se especifica la categoría Impresora que es el interés del comprador. El vendedor verifica la existencia de productos en esa categoría, y al contar con los mismo responde con la locución L2: enter_dialogue desde el mecanismo S1: Recognize Category dado que la salida generada fue un wish_to_enter. Aquí termina la fase de apertura del diálogo y comienza la de negociación. Internamente ambos agentes cargan sus comportamientos y en particular el comprador genera las restricciones difusas con las que negociará. En la tabla 13 se listan los atributos de la categoría Impresora con sus intervalos difusos en forma de rangos de valores y sus niveles de corte. Niv. de corte Precio PPM Capacidad de entrada estándar Ciclo mensual de trabajo máximo Consumo eléctrico Calidad 1 [501, 4000] [60, 70] [941, 1150] [240161, 300100] [81, 364] [81, 100] 0.8 [4001, 7500] [49, 59] [731, 940] [180221, 240160] [365, 648] [61, 80] 0.6 [7501, 11000] [38, 48] [521, 730] [120281, 180220] [649, 932] [41, 60] 0.4 [11000, 14500] [27, 37] [311, 520] [60341, 120280] [933, 1216] [21, 40] 0.2 [14501, 18000] [16, 26] [101, 310] [401, 60340] [1217, 1500] [1, 20] 0 0 0 0 0 0 0 Tabla 13 Atributos, intervalos difusos y niveles de corte para la categoría Impresora Se puede observar que los rangos de valores para el precio y el consumo eléctrico difieren del resto, en el sentido de que a menor nivel de corte, los rangos crecen. Esto se debe a que la penalización de relajar un atributo puede variar. Por ejemplo, un comprador va a preferir un precio muy bajo a uno muy alto, pero va a querer una calidad muy alta a una muy baja. Relajar el precio implica aceptar productos más caros, pero en el caso de la calidad significa permitir un decrecimiento de la misma. 6.1.2.2 Negociación La fase de negociación se inicia cuando el comprador emite su primer requerimiento de compra. El agente a partir del mecanismo B2: Generate Purchase Requirement y aplicando la estrategia de incorporación de nuevas restricciones selecciona la primera restricción en forma aleatoria. Obtiene el atributo precio al azar y aplicando el nivel de corte máximo, que para el caso inicial es de uno, se obtiene la restricción dura [501, 4000]. El agente conmuta al comportamiento que permite valorar el requerimiento aplicando el mecanismo B3: Generate Purchase Requirement Valuation. Ejecutando el algoritmo de valoración de requerimiento de compra presentado en la sección 5.2 obtenemos: vBreq precio 1 0.8 sum1 0.8 0.2 0.2 1 El valor de 0.8 es el grado de satisfacción global potencial para el precio, luego de relajarlo una vez. Obtenido el primer requerimiento de compra Breq y su valoración, se envían al vendedor a través de la locución L6: prefer_to_buy y se efectúa una transición al comportamiento B: Delegator, que funciona como un conmutador donde, dependiendo el mensaje recibido, delega en el comportamiento adecuado. El agente vendedor, que luego de confirmar el inicio de la negociación se encuentra en el estado S: Delegator, recibe prefer_to_buy por lo que conmuta al mecanismo S2: Assess Purchase Requirement donde analizará la posibilidad de satisfacer el requerimiento recibido con algún producto del catálogo. Aplicando el algoritmo de la sección 5.3 con su función de selección de ofertas de venta (fsov) se obtiene la impresora BROTHER HL5450DN con los siguientes atributos: Atributos Precio PPM Capacidad de entrada estándar Ciclo mensual de trabajo máximo Consumo eléctrico Calidad Valor 2967.38 38 150 25000 665 58 Valor difuso MUY BAJO MEDIO MUY BAJO MUY BAJO MEDIO MEDIO Tabla 14 Atributos de la impresora BROTHER HL-5450DN El producto conseguido consta de un nivel de aceptación de uno (de un máximo de uno) y fue el mayor obtenido. Esto se deprende de la aplicación de la función fsov, por lo que: aceptación utilidad 1 cantidad de envíos 1 1 0 1 Se observa que la utilidad del producto es de uno (de un máximo de uno) y la cantidad de envíos es cero. Una vez obtenido el producto lo envía al comprador a través de la locución L3: willing_to_sell y conmuta al comportamiento S: Delegator. El comprador que se encuentra en B: Delgator al recibir la oferta conmuta al comportamiento que contiene el mecanismo B4: Consider Offers. El producto cumple con la restricción enviada, pero no cumple con las no enviadas por lo que la rechazará. Esto implica que el comprador selecciona una nueva restricción aleatoriamente, que para este caso resultó ser la calidad. Aplicando el máximo nivel de corte, que en este caso es de uno, extrae la restricción dura [81, 100]. Luego conmuta al estado que contiene el mecanismo B2: Generate Purchase Requirement donde extrae esta nueva restricción para luego valorar el requerimiento de compra con B3: Generate Purchase Requirement Valuation. Aplicando el mismo algoritmo presentado anteriormente obtenemos: vBreq precio , calidad 1 0.8, 1 0.8 0.2, 0.2 0.5, 0.5 sum1 0.8 1 0.8 0.4 Se observa que las valoraciones son de 0.5 para ambas restricciones. Es decir, de la valoración absoluta de 1 obtenida para el precio en el primer cálculo del algoritmo, ahora se distribuye igualmente para ambas partes. Todo lo obtenido es enviado por L6: prefer_to_buy y conmuta a B: Delegator. Aquí el vendedor se comporta del mismo modo que en la primera recepción de requerimiento: De S: Delegator conmuta a S2: Assess Purchase Requeriment para obtener los productos que cumplan con el nuevo requerimiento enviado en L6. Son dos los productos, ambos con utilidad de 0.99, mismo valor para el nivel de aceptación, considerando que la cantidad de envíos es cero para los dos casos. Se obtiene uno aleatoriamente, que resulta ser la BROTHER Impresora láser monócromo HL-2270DW red. Atributos Precio PPM Capacidad de entrada estándar Ciclo mensual de trabajo máximo Consumo eléctrico Calidad Valor 1760.879 26 250 6000 495 94 Valor difuso MUY BAJO MUY BAJO MUY BAJO MUY BAJO BAJO MUY ALTO Tabla 15 Atributos de la impresora BROTHER HL-2270DW Luego es enviado al comprador a través de la locución L3: willing_to_sell y conmuta al comportamiento S: Delegator. El comprador recibe con L3: willing_to_sell la oferta y conmuta a B4: Consider Offers para evaluarla. No la acepta por lo mismo que anteriormente: no cumple con restricciones no enviadas. Selecciona una nueva restricción al azar que resulta ser páginas por minutos (PPM). La restricción dura que se extrae de aplicar el máximo nivel de corte es [60, 70]. Conmuta a B2 para extraerla y luego a B3 para valorarla. La valoración resulta en el siguiente cálculo: vBreq precio , PPM , calidad 1 0.8, 1 0.8, 1 0.8 0.2, 0.2, 0.2 0.33, 0.33, 0.33 sum1 0.8 1 0.8 1 0.8 0.6 El requerimiento con su valoración es enviado por L6: prefer_to_buy y conmuta a B: Delegator. El vendedor recibe el mensaje y conmuta a S2. Busca en su catálogo un producto que cumpla con el requerimiento recibido y en este punto descubre que no cuenta con uno, por lo que ingresa al mecanismo S3: Generate Potencial Sale-Offers para seleccionar una oferta potencialmente buena hacia donde conducir la negociación. Como mencionamos anteriormente, este mecanismo constituye el núcleo del sistema de argumentación del vendedor, por lo que cabe detallar su funcionamiento. La impresora seleccionada por el mecanismo es Lexmark MS811dn cuyos atributos son: Atributos Precio PPM Capacidad de entrada estándar Ciclo mensual de trabajo máximo Consumo eléctrico Calidad Valor 8267.08 63 650 275000 770 90 Valor difuso MEDIO MUY ALTO MEDIO MUY ALTO MEDIO MUY ALTO Tabla 16 Atributos de la impresora LEXMARK MS811dn La función que rige la elección de una oferta potencial es prefer presentada en la sección 5.3. La iremos desmembrando para explicar los resultados obtenidos. Recordemos que: prefer (s j ) u j 1 viability p j , tBreq , vBreq Reemplazando las variables por sus valores, y teniendo en cuenta que la utilidad del producto es de 0.99 y que = 0.5, el resultado obtenido es: prefer (s j ) 0.5 0.99 0.5 0.8095 0.89975 Ahora analizaremos la función de viabilidad. Como mencionamos en la sección 5.3, la viabilidad depende del grado de similitud entre cada producto del catálogo y el requerimiento de compra, y de la valoración que el comprador calculó para dicho requerimiento. Es decir, la viabilidad aglutina los conceptos de similaridad (entre productos y requerimiento) y estimación de la valoración del comprador. Haber obtenido en esta primera instancia un producto muy próximo a la necesidad del comprador demuestra la efectividad de la función de viabilidad. Las entradas para esta función son: El requerimiento en forma de restricciones duras. En este punto de la negociación contamos con [501, 4000] para el precio, [60, 70] para páginas por minuto y [81, 100] para la calidad. La valoración del requerimiento que en nuestro caso es: vBreq precio, PPM , calidad 0.33, 0.33, 0.33 El producto que se está evaluando, concretamente sus atributos. Solo consideraremos el que finalmente fue el que obtuvo la mayor preferencia. De la función de viabilidad presentada en la sección 5.3, nos enfocaremos en la n expresión (dist (a i 1 ji , tB,ireq ) vboundary( t ,i ) )2 / n) . Comenzaremos con el precio para el Breq cálculo de la distancia. El producto tiene un precio de 8267.08, es un valor fuera de la restricción dura [501, 4000] por lo que la distancia no es de cero. En este punto debemos calcular los valores de reserva aires (hasta dónde podría relajar el comprador) y el límite más lejano (boundary). El primero lo definimos arbitrariamente como el promedio de todos los valores del atributo para todos los productos que componen el catálogo. El precio promedio es de 4569.18 y es por tanto el valor de reserva. El límite más lejano es un tanto más complejo. A partir de la restricción dura, debemos obtener uno de los dos valores que definen el rango cuya distancia al atributo del producto es la más lejana. Para este caso tenemos que 501 (límite menor de la restricción) se encuentra a 7766.08 unidades de 8267.08 (valor del atributo), y que 4000 (límite mayor) se encuentra a 4267.08 unidades, por lo que el valor de boundary es 501. El próximo paso es verificar si el valor del atributo se encuentra dentro del intervalo formado por el valor de reserva y el límite más lejano, es decir, comprobar si 8267.08 está dentro de [501, 4569.18]. Claramente no lo está, entonces la distancia es de 1, la máxima posible. Por lo tanto, aplicando la expresión antes mencionada, tenemos que para la primera iteración de la sumatoria, considerando el precio y n = 3 (cantidad de atributos hasta el momento): (dist a ji , tB,ireq vboundary( t ,i ) )2 / n) 1 * 0.33 / 3 0.0363 2 Breq Ahora analizaremos las páginas por minuto o PPM. El valor del atributo para el producto es de 63, y teniendo en cuenta que la restricción dura enviada por el comprador es de [60, 70], podemos decir que la distancia es de cero por encontrarse dentro del intervalo. Esto no afecta a la iteración de la sumatoria. Con la calidad ocurre algo similar. El valor para el atributo es de 90 y la restricción dura es [81, 100], por lo que nuevamente la distancia es cero y tampoco afecta a la sumatoria. Finalmente podemos determinar el valor de viabilidad reemplazando su función (sección 5.3): viability 1 sqrt(0.0363) 0.8095 El valor de preferencia de 0.89975 es el máximo obtenido entre todos los productos y nos indica que el vendedor cuenta con una opción igualmente beneficiosa para ambas partes: se acerca al requerimiento del comprador y a su vez le reporta una utilidad más que aceptable. Luego de esto, el vendedor conmuta al mecanismo S4: Generate Relax Requirement para indicarle al comprador cuáles restricciones deberían ser relejadas. El algoritmo del mecanismo analiza cuáles restricciones del requerimiento de compra son satisfechas y cuáles no por el producto seleccionado anteriormente. Observando los valores, el único atributo no satisfecho es el precio, por lo que el mecanismo retorna el vector (1, 0, 0) para (precio, PPM, calidad). Este requerimiento de relajación Breq es enviado al comprador en la locución L5: prefer_to_sell, y luego conmuta al estado S: Delegator. El comprador, que se encontraba en B: Delegator, conmuta a B2: Generate Purchase Requirement luego de recibir el mensaje del vendedor. Nuevamente se debe aplicar la función de modificación de requerimiento de compra, puntualmente el algoritmo de la sección 5.2 que la define, pero con una diferencia importante: existe un requerimiento de relajación que debe ser tenido en cuenta. El primer paso es obtener un vector con los grados de satisfacción global potencial que surgen de relajar cada restricción una vez, y cuyo grado es igual al máximo. Recordemos que ninguna de las tres restricciones fue relajada aun, por lo que el nivel de corte para cada una de ellas se encuentra en 1 (el máximo posible). Relajando cada una y obteniendo el valor máximo nos queda un grado de satisfacción global potencial de 0.8, y un vector con las tres restricciones. Finalmente aplicamos la última función del algoritmo: arg máx t 1 t max , max ( t 1) k x B req rk x Teniendo en cuenta que rk x 1 solamente para el precio, tenemos que el valor máximo de la función anterior es 0.8 + 1 = 1.8 y por consiguiente es este atributo el único que se corresponde con dicho valor, por lo que es el elegido para ser relajado. Su nivel de corte pasa a ser 0.8 y la restricción dura que se obtiene de él es [501, 7500]. El próximo paso es valorar el requerimiento en B3: Generate Purchase Requirement Valuation. Aplicando el mismo principio del algoritmo explicado anteriormente tenemos que: vBreq precio , PPM , calidad 1 0.6, 1 0.8, 1 0.8 0.4, 0.2, 0.2 0.5, 0.25, 0.25 sum1 0.6 1 0.8 1 0.8 0.8 El requerimiento junto con su valuación es enviado al vendedor a través de la locución L6: prefer_to_buy y conmuta a B: Delegator. Hasta este punto hemos demostrado el funcionamiento de los mecanismos que componen la fase de negociación. El resto se desarrolla de forma similar por lo que nos limitaremos a presentar en forma resumida el paso a paso de la negociación. Comprador En B:Delegator. En B: Delegator recibe L5: prefer_to_sell. Conmuta a B2. Estando en B2 se obtiene: - Máx. Grado de Satisfacción Global Potencial: 0.8 - El vector con cálculos máximos se compone solo de PPM, por lo que será relajado. - Corte de PPM: 0.8. Conmuta a B3 para valorar el requerimiento. Restricciones y valoraciones a enviar: - Precio: [501, 7500] al corte de 0.8. Valoración: 0.4 - PPM: [49, 70] al corte de 0.8. Valoración: 0.4 - Calidad: [81, 100] al corte de 1. Valoración: 0.2 Envía L6: prefer_to_buy y conmuta a B: Delegator. En B:Delegator. Vendedor En S: Delegator recibe L6: prefer_to_buy. Conmuta a S2. En S2 no obtuvo ningún producto que cumple con el requerimiento. Conmuta a S3. En S3 obtiene el producto BROTHER Impresora láser monocromo HL-2270DW red (utilidad: 0.99) cuyas características son: Precio: 1760.879 (MUY BAJO) PPM: 26 (MUY BAJO) Capacidad: 250 (MUY BAJO) Ciclo: 6000 (MUY BAJO) Consumo: 495 (BAJO) Calidad: 94 (MUY ALTO) Preferencia: 0.92283 Viabilidad: 0.8556 Cálculo: - Precio: se cumple. La distancia es 0. - PPM: Valor de reserva=32.307; boundary=70; Distancia=1. - Calidad: se cumple. La distancia es 0. Sumatoria: 02083 Una vez obtenido el producto conmuta a S4. En S4 genera el vector de relajamiento (0, 1, 0) para (precio, PPM, calidad). Lo envía a través de la locución L5: prefer_to_sell. Conmuta a S: Delegator. En S: Delegator. En S: Delegator recibe L6: prefer_to_buy. Conmuta a S2. En S2 no obtuvo ningún producto que cumple con el requerimiento. Conmuta a S3. En S3 obtiene el producto BROTHER HL-5450DN (utilidad: 1) cuyas características son: Precio: 2967.38 (MUY BAJO) PPM: 38 (MEDIO) Capacidad: 150 (MUY BAJO) Ciclo: 25000 (MUY BAJO) Consumo: 665 (MEDIO) Calidad: 58 (MEDIO) Preferencia: 0.8862 Viabilidad: 0.7724 Cálculo: - Precio: se cumple. La distancia es 0. - PPM: VR=32.307; boundary=70; Dist.= 0.85. - Calidad: VR=60.295; boundary=100; Dist.= 1. Sumatoria: 0.05177 En B: Delegator recibe L5: prefer_to_sell. Conmuta a B2. Estando en B2 se obtiene: - Máx. Grado de Satisfacción Global Potencial: 0.8 - El vector con cálculos máximos se compone solo de Calidad, por lo que será relajada. - Corte de Calidad: 0.8. Conmuta a B3 para valorar el requerimiento. Restricciones y valoraciones a enviar: - Precio: [501, 7500] al corte de 0.8. Valoración: 0.33 - PPM: [49, 70] al corte de 0.8. Valoración: 0.33 - Calidad: [61, 100] al corte de 0.8. Valoración: 0.33 Envía L6: prefer_to_buy y conmuta a B: Delegator. En B:Delegator. En B: Delegator recibe L5: prefer_to_sell. Conmuta a B2. Estando en B2 se obtiene: - Máx. Grado de Satisfacción Global Potencial: 0.6 - El vector con cálculos máximos se compone solo de Precio, por lo que será relajado. - Corte de Precio: 0.6. Conmuta a B3 para valorar el requerimiento. Restricciones y valoraciones a enviar: - Precio: [501, 11000] al corte de 0.6. Valoración: 0.4285 - PPM: [49, 70] al corte de 0.8. Valoración: 0.2857 - Calidad: [61, 100] al corte de 0.8. Valoración: 0.2857 Envía L6: prefer_to_buy y conmuta a B: Delegator. En B:Delegator. En B: Delegator recibe L3: willing_to_sell. Conmuta a B4 para evaluar la oferta. En B4 determina que cumple con las restricciones enviadas. Pero hay restricciones no enviadas que no fueron cumplidas. Por lo tanto no acepta la oferta. Selecciona al azar una nueva restricción que resultó ser Consumo eléctrico. Conmuta a B2. En B2 extrae el requerimiento y conmuta a B3. En B3 valoriza el requerimiento Restricciones y valoraciones a enviar: - Precio: [501, 7500] al corte de 0.8. Valoración: 0.375 - PPM: [49, 70] al corte de 0.8. Valoración: 0.25 - Consumo: [81, 364] al corte de 1. Valoración: 0.125 - Calidad: [61, 100] al corte de 0.8. Valoración: 0.25 Envía L6: prefer_to_buy y conmuta a B: Delegator. En B:Delegator. Una vez obtenido el producto conmuta a S4. En S4 genera el vector de relajamiento (0, 1, 1) para (precio, PPM, calidad). Lo envía a través de la locución L5: prefer_to_sell. Conmuta a S: Delegator. En S: Delegator. En S: Delegator recibe L6: prefer_to_buy. Conmuta a S2. En S2 no obtuvo ningún producto que cumple con el requerimiento. Conmuta a S3. En S3 obtiene el producto Lexmark MS811dn (utilidad: 0.99) cuyas características se encuentran en la tabla 16: Preferencia: 0.8988 Viabilidad: 0.80754 Cálculo: - Precio: VR=4569.1825; boundary=501; Dist.=1. - PPM: se cumple. La distancia es 0. - Calidad: se cumple. La distancia es 0. Sumatoria: 0.05177 Una vez obtenido el producto conmuta a S4. En S4 genera el vector de relajamiento (1, 0, 0) para (precio, PPM, calidad). Lo envía a través de la locución L5: prefer_to_sell. Conmuta a S: Delegator. En S: Delegator. En S: Delegator recibe L6: prefer_to_buy. Conmuta a S2. En S2 obtuvo el producto Lexmark MS811dn (utilidad: 0.99) con un nivel de aceptación de 0.33. Aumenta la cantidad de envíos del producto. Lo envía a través de L3: willing_to_sell. Conmuta a S: Delgator. En S: Delegator. En S: Delegator recibe L6: prefer_to_buy. Conmuta a S2. En B: Delegator recibe L5: prefer_to_sell. Conmuta a B2. Estando en B2 se obtiene: - Máx. Grado de Satisfacción Global Potencial: 0.8 - El vector con cálculos máximos se compone solo de Consumo, por lo que será relajado. - Corte de Consumo: 0.8. Conmuta a B3 para valorar el requerimiento. Restricciones y valoraciones a enviar: - Precio: [501, 11000] al corte de 0.6. Valoración: 0.33 - PPM: [49, 70] al corte de 0.8. Valoración: 0.22 - Consumo: [81, 648] al corte de 0.8. Valoración: 0.22 - Calidad: [61, 100] al corte de 0.8. Valoración: 0.22 Envía L6: prefer_to_buy y conmuta a B: Delegator. En B:Delegator. En B: Delegator recibe L5: prefer_to_sell. Conmuta a B2. Estando en B2 se obtiene: - Máx. Grado de Satisfacción Global Potencial: 0.6 - El vector con cálculos máximos se compone solo de Consumo, por lo que será relajado. - Corte de Consumo: 0.6. Conmuta a B3 para valorar el requerimiento. Restricciones y valoraciones a enviar: - Precio: [501, 11000] al corte de 0.6. Valoración: 0.3 - PPM: [49, 70] al corte de 0.8. Valoración: 0.3 - Consumo: [81, 932] al corte de 0.6. Valoración: 0.3 - Calidad: [61, 100] al corte de 0.8. Valoración: 0.2 Envía L6: prefer_to_buy y conmuta a B: Delegator. En B:Delegator. En S2 no obtuvo ningún producto que cumple con el requerimiento. Conmuta a S3. En S3 obtiene nuevamente el producto Lexmark MS811dn (utilidad: 0.99): Preferencia: 0.96375 Viabilidad: 0.9375 Cálculo: - Precio: se cumple. La distancia es 0. - PPM: se cumple. La distancia es 0. - Consumo: VR=604.359; boundary=81; Dist.=1. - Calidad: se cumple. La distancia es 0. Sumatoria: 0.00391 Una vez obtenido el producto conmuta a S4. En S4 genera el vector de relajamiento (0, 0, 1, 0) para (precio, PPM, consumo, calidad). Lo envía a través de la locución L5: prefer_to_sell. Conmuta a S: Delegator. En S: Delegator. En S: Delegator recibe L6: prefer_to_buy. Conmuta a S2. En S2 no obtuvo ningún producto que cumple con el requerimiento. Conmuta a S3. En S3 obtiene nuevamente el producto Lexmark MS811dn (utilidad: 0.99): Preferencia: 0.9395 Viabilidad: 0.88 Cálculo: - Precio: se cumple. La distancia es 0. - PPM: se cumple. La distancia es 0. - Consumo: VR=604.359; boundary=81; Dist.=1. - Calidad: se cumple. La distancia es 0. Sumatoria: 0.01235 Una vez obtenido el producto conmuta a S4. En S4 genera el vector de relajamiento (0, 0, 1, 0) para (precio, PPM, consumo, calidad). Lo envía a través de la locución L5: prefer_to_sell. Conmuta a S: Delegator. En S: Delegator. En S: Delegator recibe L6: prefer_to_buy. Conmuta a S2. En S2 obtuvo el producto Lexmark MS811dn (utilidad: 0.99) con un nivel de aceptación de 0.25. Aumenta la cantidad de envíos del producto. Lo envía a través de L3: willing_to_sell. Conmuta a S: Delgator. En B: Delegator recibe L3: willing_to_sell. Conmuta a B4 para evaluar la oferta. En B4 determina que cumple con las restricciones enviadas. Pero hay restricciones no enviadas que no fueron cumplidas. Por lo tanto no acepta la oferta. Selecciona al azar una nueva restricción que resultó ser Capacidad de entrada estándar. Conmuta a B2. En B2 extrae el requerimiento y conmuta a B3. En B3 valoriza el requerimiento Restricciones y valoraciones a enviar: - Precio: [501, 11000] al corte de 0.6. Valoración: 0.2727 - PPM: [49, 70] al corte de 0.8. Valoración: 0.1818 - Capacidad: [941, 1150] al corte de 1. Valoración: 0.0909 - Consumo: [81, 932] al corte de 0.6. Valoración: 0.2727 - Calidad: [61, 100] al corte de 0.8. Valoración: 0.1818 Envía L6: prefer_to_buy y conmuta a B: Delegator. En B:Delegator. En B: Delegator recibe L5: prefer_to_sell. Conmuta a B2. Estando en B2 se obtiene: - Máx. Grado de Satisfacción Global Potencial: 0.8 - El vector con cálculos máximos se compone solo de Capacidad, por lo que será relajada. - Corte de Capacidad: 0.8. Conmuta a B3 para valorar el requerimiento. Restricciones y valoraciones a enviar: - Precio: [501, 11000] al corte de 0.6. Valoración: 0.25 - PPM: [49, 70] al corte de 0.8. Valoración: 0.166 - Capacidad: [731, 1150] al corte de 0.8. Valoración: 0.166 - Consumo: [81, 932] al corte de 0.6. Valoración: 0.25 - Calidad: [61, 100] al corte de 0.8. Valoración: 0.166 Envía L6: prefer_to_buy y conmuta a B: Delegator. En B:Delegator. En S: Delegator. En S: Delegator recibe L6: prefer_to_buy. Conmuta a S2. En S2 no obtuvo ningún producto que cumple con el requerimiento. Conmuta a S3. En S3 obtiene nuevamente el producto Lexmark MS811dn (utilidad: 0.99): Preferencia: 0.9823 Viabilidad: 0.9746 Cálculo: - Precio: se cumple. La distancia es 0. - PPM: se cumple. La distancia es 0. - Capacidad: VR=350.5641; boundary=1150; Dist.= 0.62544. - Consumo: se cumple. La distancia es 0. - Calidad: se cumple. La distancia es 0. Sumatoria: 0.0006466 Una vez obtenido el producto conmuta a S4. En S4 genera el vector de relajamiento (0, 0, 1, 0, 0) para (precio, PPM, capacidad, consumo, calidad). Lo envía a través de la locución L5: prefer_to_sell. Conmuta a S: Delegator. En S: Delegator. En S: Delegator recibe L6: prefer_to_buy. Conmuta a S2. En S2 no obtuvo ningún producto que cumple con el requerimiento. Conmuta a S3. En S3 obtiene nuevamente el producto Lexmark MS811dn (utilidad: 0.99): Preferencia: 0.9717 Viabilidad: 0.9534 Cálculo: - Precio: se cumple. La distancia es 0. - PPM: se cumple. La distancia es 0. - Capacidad: VR=350.5641; boundary=1150; Dist.= 0.62544. - Consumo: se cumple. La distancia es 0. - Calidad: se cumple. La distancia es 0. Sumatoria: 0.0021732 Una vez obtenido el producto conmuta a S4. En S4 genera el vector de relajamiento (0, 0, 1, 0, 0) para (precio, PPM, capacidad, consumo, calidad). Lo envía a través de la locución En B: Delegator recibe L5: prefer_to_sell. Conmuta a B2. Estando en B2 se obtiene: - Máx. Grado de Satisfacción Global Potencial: 0.6 - El vector con cálculos máximos se compone solo de Capacidad, por lo que será relajada. - Corte de Capacidad: 0.6. Conmuta a B3 para valorar el requerimiento. Restricciones y valoraciones a enviar: - Precio: [501, 11000] al corte de 0.6. Valoración: 0.2308 - PPM: [49, 70] al corte de 0.8. Valoración: 0.15385 - Capacidad: [521, 1150] al corte de 0.6. Valoración: 0.2308 - Consumo: [81, 932] al corte de 0.6. Valoración: 0.2308 - Calidad: [61, 100] al corte de 0.8. Valoración: 0.15385 Envía L6: prefer_to_buy y conmuta a B: Delegator. En B:Delegator. L5: prefer_to_sell. Conmuta a S: Delegator. En S: Delegator. En S: Delegator recibe L6: prefer_to_buy. Conmuta a S2. En S2 obtuvo el producto Lexmark MS811dn (utilidad: 0.99) con un nivel de aceptación de 0.11. Aumenta la cantidad de envíos del producto. Lo envía a través de L3: willing_to_sell. Conmuta a S: Delgator. Tabla 17 Porción de la negociación entre el agente proveedor y el municipal Nos detenemos en este punto de la negociación en que el comprador evaluará la oferta en el mecanismo B4: Consider Offers. Verifica el cumplimiento de las restricciones y determina que las enviadas y las no enviadas fueron satisfechas por la oferta recibida. Por lo que queda calcular los grados de satisfacción para inferir si la oferta es aceptable o no. Recordemos que una oferta es aceptable si el grado de satisfacción global v X es mayor o igual al grado de satisfacción global potencial Breq del requerimiento de compra B . El grado de satisfacción global se compone del mínimo grado de pertenencia. Para req decirlo de una manera sencilla, de cada valor de los atributos del producto se determina el intervalo difuso en el que está contenido. Ese intervalo tiene asociado un grado de pertenencia que no es otra cosa que el nivel de corte del intervalo. Analizando el producto recibido tenemos que: Atributos Precio PPM Capacidad de entrada estándar Ciclo mensual de trabajo máximo Consumo eléctrico Calidad Valor 8267.08 63 650 275000 770 90 Tabla 18 Situación de la negociación en el tramo final Intervalo difuso al que pertenece [7501, 11000] [60, 70] [521, 730] [240161, 300100] [649, 932] [81, 100] Grado de pertenencia 0.6 1 0.6 1 0.6 1 Observando la tabla vemos que el menor grado de pertenencia es 0.6, por lo que este es el grado de satisfacción global. El grado de satisfacción global potencial es el mínimo nivel de corte utilizado para extraer las restricciones duras que compusieron el último requerimiento de compra enviado. Para nuestro caso este valor es 0.6. En conclusión, ambos grados de satisfacción son equivalentes por lo que la oferta debe ser aceptada. En este punto se inicia la fase de confirmación. 6.1.2.3 Confirmación y Cierre del Diálogo En este punto nos encontramos que el comprador, a partir del mecanismo B4: Consider Offers determina que la oferta es satisfactoria y por lo tanto la acepta. El agente emite la locución L9: agree_to_buy y conmuta al mecanismo B: Delegator. El vendedor que se encontraba en S: Delegator, al recibir la confirmación del comprador cambia al estado S5: Accept or Reject Offer. Cabe señalar que el agente vendedor tiene un comportamiento no estratégico, es decir, no especula con relajaciones por parte del comprador aun contando con el producto que satisface su requerimiento, a fin de mejorar sus beneficios. El agente cuenta con el producto por lo tanto emite la aceptación de la confirmación a partir de la locución L10: agree_to_sell. El cierre del diálogo se produce luego del envío de la locución L11: withdraw_dialogue por parte de ambos agentes. Luego de esto, el comprador se destruye y el vendedor sigue su ejecución a la espera de nuevas aperturas de diálogos7. 7 Es importante destacar que los agentes comprador y vendedor tienen comportamientos concurrentes, es decir, pueden llevar adelante diferentes negociaciones sin inconvenientes. El comprador es destruido porque cada vez que se inicia una negociación desde la interface de usuario, se crea un nuevo agente, por lo que nunca se darán negociaciones paralelas. Esto no ocurre con el vendedor el cual puede recepcionar en cualquier instante la apertura de un nuevo diálogo. 6.1.3 Conclusión del caso de estudio El primer caso de estudio demuestra la efectividad del marco de negociación automática que elegimos como base para la presente tesis. En el experimento se establecieron condiciones iniciales con las que podían evidenciarse un producto ganador. El desafío pasó por demostrar que el algoritmo tendiera a negociar dicho producto, y así lo fue. Podemos inferir que bajo condiciones reales, una negociación será conducida hacía la mejor opción para ambas partes. Haciendo un seguimiento de la ejecución pudimos observar también la flexibilidad del sistema para adaptarse a posibles cambios en el catálogo. En los mecanismo S2: Assess Purchase Requirement y S3: Generate Potencial Sale-Offers el proveedor “interactúa” con su catálogo el cual pudo haber sido modificado previamente. Para el primer caso, el agente debe obtener un producto que cumpla con el requerimiento del comprador. Si uno de ellos es eliminado del catálogo o alguno de sus atributos es modificado, no será considerado en este mecanismo o bien no cumplirá con el requerimiento de compra (aun cuando posiblemente se haya tenido en cuenta previamente en la negociación). Lo mismo ocurre para el mecanismo S3 en donde, cualquier cambio en los valores de los atributos afectará directamente a la función de preferencia relegando algún producto que anteriormente pudo ser una oferta potencial. Evidentemente un producto eliminado tampoco será contemplado en este mecanismo. Un atributo destacable del sistema es su buena usabilidad, potenciada por el uso de restricciones difusas para la definición de los requerimientos. En un ámbito real, la Oficina de Compras (la cual no tiene por qué saber de impresoras) establece las condiciones iniciales en el sistema de una forma fácil e intuitiva de acuerdo a las necesidades de compra de algún sector municipal (en este caso el área de Rentas). Indudablemente el aspecto más importante que evidencia los beneficios de utilizar un marco de negociación automática respecto a un ámbito de compra real es la minimización del tiempo que transcurre desde el momento que se plantea la necesidad hasta que se acuerda con un proveedor la adquisición del producto. Como mencionamos en la introducción del capítulo, el tiempo real que se invirtió en determinar la mejor opción de compra a un determinado proveedor fue de 2 días, considerando el tiempo insumido en el pedido y recepción de cotizaciones, y la selección de la impresora a comprar. La negociación automática insumió un tiempo considerablemente menor: desde el momento en que se inició la negociación hasta su finalización satisfactoria transcurrieron aproximadamente 4 minutos. Vale aclarar que este tiempo puede variar en diferentes negociaciones, aun estableciendo iguales condiciones iniciales, debido a que en ciertos puntos existen decisiones aleatorias que pueden prolongar o acortar el tiempo transcurrido. En este sentido, en el caso de estudio 2 se analizará la performance del sistema cuando se negocia varias veces sobre un mismo catálogo, como así también, cuando se varía la cantidad de productos y de atributos por producto del catálogo con el que cuenta el proveedor. 6.2 Caso de estudio 2: Análisis de performance La intención de este caso de estudio es llevar a cabo un análisis de las variaciones en los tiempos que insume una negociación cuando se modifican la cantidad de productos con los que cuenta el proveedor en su catálogo, y el número de atributos para cada uno de ellos. Incluso, como mencionamos en la conclusión del caso de estudio anterior, expondremos la variación del tiempo para una determinada cantidad de negociaciones sobre un mismo catálogo. 6.2.1 Introducción Para el análisis de las duraciones de las negociaciones, implementamos un proceso generador de catálogos. Indicando la cantidad de productos y de atributos para cada uno de ellos, se crearon diferentes catálogos que demostrarán la variabilidad de los tiempos. Con el fin de brindar transparencia al caso de estudio, se determinaron valores en forma aleatoria, como ser: la utilidad de cada producto (un número entre 0 y 1), los valores para los atributos (entre 0 y 1000), y si cada uno de los atributos es incremental o no. Se generaron catálogos de 10, 50, 100 y 500 productos; con 2, 5 y 10 atributos por producto, lo que da como resultado 12 catálogos diferentes. A su vez, con el propósito de evaluar la incidencia en el tiempo de negociación por parte de los atributos incrementales sobre los no incrementales, agregamos dos catálogos de 50 productos cada uno, con 5 atributos incrementales para uno de ellos y 5 no incrementales para el otro. Se llevaron a cabo 20 negociaciones por cada catálogo utilizando el portal de compras, como lo haría el Sector de Compras. Luego, por cada escenario se calcularon la media y la desviación estándar de los tiempos insumidos en todas las negociaciones para cada análisis. Además, se estableció un valor difuso MEDIO para todos los atributos en los requerimientos de compra. 6.2.2 Diez productos A continuación presentamos los tiempos insumidos en cada negociación para un catálogo de diez productos. En las dos últimas filas se observan los cálculos de la media y la desviación estándar para cada conjunto de atributos. Número de ejecución 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 2 atributos 5 atributos 10 atributos 0:00:38 0:00:40 0:00:36 0:00:36 0:00:37 0:00:38 0:00:36 0:00:37 0:00:39 0:00:37 0:00:38 0:00:37 0:00:36 0:00:38 0:00:38 0:00:39 0:00:39 0:00:38 0:00:39 0:00:40 0:01:17 0:01:34 0:01:37 0:01:56 0:01:38 0:01:39 0:01:45 0:01:41 0:01:57 0:01:15 0:01:41 0:01:38 0:01:22 0:02:04 0:01:11 0:01:52 0:01:49 0:01:38 0:01:22 0:01:40 0:01:38 0:03:09 0:02:02 0:02:02 0:03:10 0:02:36 0:02:48 0:03:31 0:03:14 0:03:49 0:02:40 0:02:38 0:01:27 0:01:34 0:02:09 0:02:04 0:02:15 0:02:56 0:02:02 0:01:41 Media: Desv. Estándar: 00:00:38 0,0000148 00:01:38 0,0001675 00:02:28 0,0004754 Tabla 19 Duraciones, media y desviación estándar para un catálogo de 10 productos En la tabla 19 podemos observar, que para un catálogo pequeño las negociaciones son de poca duración. De los valores de desviación estándar también podemos apreciar que no existen grandes variaciones entre los tiempos respecto de las medias. Para los catálogos generados aleatoriamente, se logró llegar a resultados satisfactorios en los casos de 2 y 5 atributos en donde siempre se obtuvo el mismo producto para todas las negociaciones. No fue el mismo caso para 10 atributos donde en todas las negociaciones los participantes se retiraron sin llegar a un acuerdo. Evidentemente, es más probable llegar a un acuerdo cuando la cantidad de atributos a negociar es poca. Con el fin de visualizar los resultados obtenidos, más precisamente los valores de las medias, en forma gráfica, presentamos en la figura 14 una representación en gráfico de líneas. El eje X se relaciona a la cantidad de atributos y el eje Y a las duraciones en promedio de cada negociación. Figura 14 Gráfico de líneas para un catálogo de 10 productos La representación gráfica muestra que entre 2 y 5 atributos hay un mayor crecimiento en relación a los atributos 5 y 10. El tiempo insumido por los productos de 5 atributos es 2,6 veces mayor que el de 2 atributos. En cambio el de 10 atributos es 1,51 veces el tiempo que insumió la negociación para 5 atributos. Esto indica que con un número pequeño de productos en el catálogo, a mayor cantidad de atributos la negociación no durará mucho más que las anteriores. La causa es que la negociación se trunca porque el proveedor no puede obtener productos candidatos debido a su corto catálogo, esto dispara solicitudes de relajación de las restricciones del requerimiento de compra. El agente que representa al Municipio llega a un punto donde ya no pueda relajar sus restricciones por lo que se retira de la negociación. Esta situación no variará demasiado aumentando la cantidad de atributos. En cambio, aumentando el tamaño del catálogo, se obtienen productos candidatos, aún avanzada la negociación, por lo que implicará más intercambio de mensajes entre los agentes y un aumento en la duración. 6.2.3 Cincuenta productos En la tabla 20 observamos las duraciones de las negociaciones, la media y la desviación estándar para un catálogo de 50 productos. Número de ejecución 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 2 atributos 5 atributos 10 atributos 00:00:48 00:00:48 00:00:48 00:00:49 00:00:48 00:00:50 00:00:48 00:00:49 00:00:48 00:00:49 00:00:52 00:00:52 00:00:48 00:00:50 00:00:49 00:00:51 00:00:50 00:00:48 00:00:50 00:00:50 00:06:32 00:06:16 00:08:01 00:05:55 00:05:40 00:05:46 00:06:28 00:08:05 00:05:30 00:06:22 00:06:16 00:06:30 00:05:34 00:05:52 00:06:21 00:06:13 00:05:49 00:05:29 00:05:45 00:06:20 00:19:00 00:18:28 00:24:06 00:25:58 00:15:47 00:26:54 00:25:05 00:15:47 00:16:17 00:18:55 00:25:48 00:19:16 00:24:13 00:24:58 00:22:55 00:19:18 00:19:11 00:20:28 00:23:50 00:24:23 Media: Desv. Estándar: 00:00:49 0,0000154 00:06:14 0,0004933 00:21:32 0,0025356 Tabla 20 Duraciones, media y desviación estándar para un catálogo de 50 productos Observamos tiempos mayores en la duración de las negociaciones. Las desviaciones de los valores respecto de las medias no son significativas. Al igual que el catálogo de 10 productos, los casos de 2 y 5 atributos obtuvieron un mismo producto como resultado de la negociación para cada caso; en cambio para 10 atributos no hubo acuerdo. A continuación, en la figura 15, presentamos el gráfico de líneas. Figura 15 Gráfico de líneas para un catálogo de 50 productos A simple vista se aprecia un mayor crecimiento en la duración para el catálogo de 10 atributos. Cuando son pocos los atributos negociables, es más probable que el proveedor cuente con productos que se acerquen al requerimiento de compra, por lo que a priori la duración de la negociación será corta y en la mayoría de los casos se llegará a un acuerdo. Con 10 atributos por negociar y un catálogo un poco más nutrido que el caso anterior, el proveedor contará con productos que orienten la negociación a buen puerto. Pero a medida que el agente municipal le entregue nuevas restricciones, el proveedor deberá reconducir la negociación hacia nuevas alternativas. Sumado a la posibilidad de no contar con productos que se ajusten al requerimiento de compra en varios puntos de la negociación, se alargará la duración y, como en este caso, se concluirá sin llegar a un acuerdo. 6.2.4 Cien productos Al igual que los casos anteriores, presentamos la tabla 21 con los valores resultantes de las pruebas. Número de ejecución 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 2 atributos 5 atributos 10 atributos 00:01:34 00:01:42 00:01:33 00:01:39 00:01:33 00:01:40 00:01:35 00:01:39 00:01:40 00:01:39 00:01:32 00:01:38 00:01:47 00:01:35 00:01:34 00:01:36 00:01:39 00:01:48 00:01:42 00:01:35 00:22:28 00:20:34 00:19:34 00:20:44 00:22:03 00:20:49 00:22:30 00:21:18 00:22:00 00:22:35 00:19:55 00:19:22 00:20:36 00:22:14 00:20:37 00:19:52 00:19:52 00:20:56 00:19:49 00:19:33 00:54:58 00:45:28 00:53:17 00:39:31 00:54:22 00:56:18 00:54:47 00:44:57 00:57:04 00:46:49 00:54:30 00:50:22 00:56:25 00:57:07 00:55:38 00:53:12 00:45:17 00:42:27 00:54:22 00:48:54 Media: Desv. Estándar: 00:01:38 0,0000514 00:20:52 0,0007614 00:51:17 0,0037487 Tabla 21 Duraciones, media y desviación estándar para un catálogo de 100 productos Como era de esperarse, las duraciones son mayores respecto a los casos anteriores. Las desviaciones estándar siguen siendo mínimas para los tres casos. Todas las negociaciones terminaron en acuerdos, pero ocurrieron algunas particularidades: para 2 atributos, al igual que las pruebas anteriores, se obtuvo un único producto; pero para los casos de 5 y 10 atributos se acordaron la compra de 4 y 2 productos respectivamente distribuidos entre las diferentes negociaciones. Esta peculiaridad se debe a dos factores: por un lado, a ciertas similitudes entre productos que se encuentran en los catálogos generados; y por el otro, la aleatoriedad con que el agente municipal entrega las restricciones del requerimiento de compra al proveedor. Cada vez que se deben proporcionar nuevas restricciones, se selecciona en forma aleatoria un de ellas del conjunto de restricciones difusas que componen el requerimiento de compra. Esta nueva restricción, sumado al hecho de contar en el catálogo con productos similares en características, provoca que el proveedor conduzca la negociación hacia una alternativa u otra. Estos quiebres en el proceso de negociación determinan acuerdos donde el producto final varía respecto a otras ejecuciones. Figura 16 Gráfico de líneas para un catálogo de 100 productos En el gráfico de líneas de la figura 16 observamos que no hay un crecimiento muy pronunciado entre los diferentes valores de atributos; incluso se puede decir que el aumento en las duraciones, a medida que se agregan atributos, es prácticamente lineal. Aunque el crecimiento entre 2 y 5 atributos es levemente superior al de 5 y 10 atributos, no es un caso comparable al catálogo de 10 productos donde este último crecimiento cae abruptamente. Esto significa que, aumentando la cantidad de atributos, la duración de la negociación es mayor aun superando los 10 atributos, pero sin producirse un “achatamiento” en los tiempos por los motivos mencionados en las pruebas con 10 productos. 6.2.5 Quinientos productos En la tabla 22, observamos los resultados obtenidos de las diferentes negociaciones. Número de ejecución 1 2 2 atributos 5 atributos 10 atributos 00:05:07 00:05:09 00:25:07 00:24:54 04:19:56 03:02:39 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 00:05:28 00:04:57 00:05:13 00:05:11 00:05:07 00:05:05 00:05:01 00:05:06 00:05:07 00:05:05 00:05:15 00:05:23 00:05:32 00:05:21 00:05:12 00:05:38 00:05:23 00:05:12 00:43:20 00:37:30 00:25:53 00:29:01 00:38:21 00:41:33 00:36:25 00:42:05 00:24:25 00:44:46 00:56:14 00:58:38 00:40:10 00:27:25 01:01:06 01:03:58 00:41:29 00:27:45 04:12:55 04:18:13 04:33:57 02:44:28 04:35:56 03:24:26 03:14:31 03:16:32 04:27:34 04:29:32 03:29:55 04:33:59 04:26:41 03:14:13 02:47:12 03:29:22 03:35:01 03:06:09 Media: Desv. Estándar: 00:05:14 0,0001239 00:39:30 0,0087417 03:46:10 0,0275890 Tabla 22 Duraciones, media y desviación estándar para un catálogo de 500 productos Evidentemente las duraciones son mucho mayores, en el orden de horas para 10 atributos. Todas las negociaciones terminaron en acuerdo; para los casos de 2 y 5 atributos se obtuvieron un único producto, en cambio para el catálogo de 10 atributos fueron 4 los productos obtenidos en diferentes negociaciones. Como en el catálogo de 100 productos, la similitud en los productos y la aleatoriedad en la selección de restricciones provocan esta variación en los productos resultantes. Figura 17 Gráfico de líneas para un catálogo de 500 productos Se observa en el gráfico de líneas que el aumento en el crecimiento de la duración en las negociaciones aumenta considerablemente para el catálogo de 10 atributos respecto a los otros casos. Contar con un gran número de productos y atributos para cada uno de ellos tiene dos consecuencias importantes en el aumento desmedido del tiempo: Por un lado, cuando el agente municipal recibe una oferta por parte del proveedor, el producto que la compone debe cumplir con todas las restricciones sobre los 10 atributos que lo definen. Muchas ofertas son rechazadas por este motivo provocando que la llegada a un acuerdo se prolongue. Por otro lado, aunque el proveedor posea un gran catálogo, existen situaciones donde no cuente con un producto que se ajuste a los requerimientos del agente municipal. Esto determina el cálculo de preferencia para cada uno de los 500 productos que componen el catálogo con el fin de obtener un producto candidato hacia donde orientar la negociación. 6.2.6 Atributos incrementales y no incrementales La última prueba que desarrollamos tiene como objetivo determinar la influencia de los atributos incrementales y no incrementales en la duración de una negociación. Recordemos que un atributo es incremental cuando la pérdida de satisfacción global se produce elevando el valor del límite superior en caso de una relajación (por ejemplo, el precio, ya que es menos conveniente elevar las restricciones sobre él). Un atributo no incremental es el caso contrario (por ejemplo, la calidad de un producto, debido a que son menos convenientes valores bajos del mismo). La intención es determinar la influencia del tipo de atributo en la duración de negociación sobre un mismo catálogo. Es decir, utilizando el catálogo para los experimentos con 50 productos y 5 atributos, planteamos dos escenarios: uno en que todos los atributos son incrementales y otro donde son todos no incrementales. A continuación, podemos observar los tiempos obtenidos para ambos casos. Número de ejecución 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Media: Desv. Estándar: Incrementales 00:06:58 00:07:01 00:08:28 00:09:33 00:08:44 00:10:00 00:08:42 00:07:48 00:10:02 00:08:25 00:07:21 00:05:43 00:07:49 00:08:07 00:06:58 00:08:30 00:07:38 00:08:31 00:06:22 00:07:40 No incrementales 00:03:41 00:03:43 00:03:02 00:03:53 00:04:27 00:07:02 00:03:17 00:04:26 00:03:14 00:03:21 00:03:51 00:03:07 00:05:57 00:03:25 00:05:34 00:06:22 00:05:51 00:04:29 00:03:41 00:04:01 00:08:01 0,0007838 00:04:19 0,0008271 Tabla 23 Duraciones, media y desviación estándar para atributos incrementales y no incrementales En la tabla 23 se observa claramente la influencia de un tipo sobre otro. Los atributos incrementales duplican el tiempo de duración de la negociación respecto de los incrementales. Esto significa que para los diferentes experimentos, las cantidades de atributos de un tipo y de otro inciden sobre las duraciones. Por esta razón, fue de suma importancia la generación de catálogos en forma aleatoria incluso en los tipos de atributos, con el fin de no incidir en los tiempos de las pruebas. Evidentemente los valores de los atributos para cada producto y la selección de las restricciones iniciales para el requerimiento de compra (como ya mencionamos, en todos los casos fue de un intervalo difuso MEDIO) también impacta en la duración. Por ejemplo, un catálogo cuyos atributos contienen en mayor medida valores bajos, estableciendo requerimientos iniciales como MUY ALTO provocará que la negociación dure más respecto a aquella en la que se establecieron valores iniciales como MUY BAJO. En el siguiente gráfico de barras observamos la gran diferencia entre las duraciones de las negociaciones. Por muy poco, el caso de atributos incrementales casi duplica al de los atributos no incrementales. 00:08:38 00:07:12 00:05:46 00:04:19 00:02:53 00:01:26 00:00:00 Incrementales No incrementales Figura 18 Gráfico de barras para atributos incrementales y no incrementales 6.2.7 Conclusión del caso de estudio Indudablemente, la duración de una negociación está relacionada en gran medida a diversos parámetros iniciales. La cantidad de productos con los que cuenta el catálogo incide sobre el tiempo, particularmente en situaciones donde el proveedor no cuente con un producto que se ajuste al requerimiento del agente municipal y deba obtener un producto candidato a través de los cálculos de preferencia en todo el catálogo. Pero el mayor impacto se produce cuando aumenta el número de atributos negociables, salvo en los casos en que la cantidad de productos es escasa. Cada nueva restricción que recibe el proveedor implica determinar el mejor producto para él que se ajuste al requerimiento del agente municipal. En el peor de los casos, no encontrarlo involucra diversos cálculos para obtener una opción cercana a dicho requerimiento, como hemos mencionado. Aun encontrando el producto que se ajuste a cada restricción, falta determinar el cumplimiento del resto de los atributos que el agente municipal todavía no envió. Si la cantidad de atributos es grande, probablemente no se satisfagan todas las restricciones no enviadas, por lo que se producirá un rechazo y nuevos diálogos para acordar hacia dónde seguir. Los valores y tipo de cada atributo, la utilidad de los productos y los requerimientos de compra iniciales también inciden en los tiempos. Supongamos un caso en donde se presenta la necesidad de comprar un televisor LED. Estos artículos generalmente son caros, por lo que plantear como restricción de compra inicial sobre el precio un valor MUY BAJO provocará que la negociación se prolongue. Más aún si el proveedor tiene valores de utilidad mínimos para los televisores de precios muy bajos. 6.3 Conclusión Con los casos de estudio planteados se demostraron el cumplimiento de los beneficios que proporciona el marco de negociación automática basado en restricciones difusas respecto a un ámbito de compras real. Los tiempos fueron ampliamente reducidos, al punto de durar minutos lo que en la realidad tarda días. De todas formas se comprobó la incidencia en los tiempos cuando el catálogo es alterado en su contenido. Pero aun así, las duraciones de las negociaciones son insignificantes en comparación con un escenario real. La eficiencia es otro aspecto que quedó de manifiesto en el primer caso de estudio, al momento de acordar la adquisición del mejor producto del catálogo del proveedor. Además el sistema cuenta con una buena usabilidad, permitiendo al usuario iniciar una compra sin conocer en detalle el dominio del producto que se desea adquirir. Capítulo 7 Conclusiones En este último capítulo presentamos las contribuciones y conclusiones del trabajo, haciendo foco en los puntos más destacados. A su vez, describimos las limitaciones, que no son otra cosa que aspectos no contemplados en la presente tesis. Por último presentamos algunas ideas para extender la herramienta en trabajos futuros. 7.1 Contribuciones Una herramienta de negociación automática que lleve a cabo un comercio electrónico entre varias partes es de gran utilidad en cualquier escenario. Si le sumamos la posibilidad de definir el requerimiento de compra a partir de restricciones difusas, los beneficios son aún mayores. Particularmente una entidad municipal, a través de su Oficina de Compras, es un ámbito donde se potencia su utilización. La modernización en la gestión pública nos abre una puerta para el estudio de nuevas tecnologías, que, en nuestro caso, lo enfocamos en un aspecto crítico para las entidades gubernamentales, y más específicamente, los gobiernos municipales: las compras de suministros en forma eficiente. El propósito de nuestro trabajo fue el de desarrollar dicha herramienta, la cual cuenta con una serie de atributos que la convierten en una mejora sustancial respecto a la metodología clásica de compra. Por un lado, minimiza considerablemente los tiempos que se invierten desde el momento en que un sector notifica la necesidad de abastecimiento, hasta la determinación del producto y del proveedor al que se le efectuará la compra. El producto acordado en cada negociación se ajusta lo máximo posible al requerimiento de compra de la entidad de gobierno. Posee una disponibilidad absoluta que permite el inicio de negociaciones en cualquier momento. Por su carácter de sistema informático, permite la interoperabilidad con otros sistemas con el fin de que cada proveedor implemente su propia herramienta como lo desee. Además, un aspecto importante con el que cuenta, es una fácil utilización de la misma que posibilita a cualquier usuario definir requerimientos de compra sin necesidad de conocer por completo el dominio sobre el que se negociará. En este sentido, estudiamos los diferentes conceptos que nos condujeron al desarrollo de la herramienta. Por un lado, presentamos a los representantes de cada participante en una negociación; así llegamos al concepto de agente inteligente; más precisamente a un número de ellos interactuando, es decir, un sistema multiagente. Utilizamos la plataforma JADE para la coordinación de los agentes; la cual, a su vez, proporciona el soporte para comunicarlos, el Facilitador de Directorio, y la ejecución concurrente de comportamientos, en otras tantas virtudes. Por otra parte, se definió un modelo de negociación que se ajustó de la mejor forma posible a las pretensiones funcionales de la herramienta. En este sentido, desarrollamos un estudio sobre los diferentes modelos basados en enfoques particulares, determinando los pros y las contras de cada uno. Así fue que concluimos en que la mejor opción son los modelos basados en restricciones difusas, las cuales se emplean para determinar qué oferta enviar, si una oferta es aceptable y que contra-oferta efectuar. Proporciona métodos para argumentar la postura de cada participante, pero se potencia con la flexibilidad que otorga el empleo de lógica difusa. A su vez, contar con la posibilidad de definir los requerimientos de compra a partir de restricciones difusas tiene un valor agregado en la facilidad de uso de la herramienta, siendo esto un aspecto importante para nuestro contexto. Posteriormente, estudiamos en profundidad el modelo de negociación automática basado en restricciones difusas, ejemplificándolo con una situación en la que un agente municipal y un proveedor desean negociar entre sí. Con el fin de comprobar, con el sistema desarrollado, el cumplimiento de los objetivos que nos fijamos en el presente trabajo, planteamos dos casos de estudios. El primero de ellos consistió en utilizar la herramienta en un ámbito de negociación entre un Municipio y un proveedor para la adquisición de una impresora. El segundo tuvo como propósito, analizar la performance del sistema cuando se varían los escenarios. Las conclusiones obtenidas de ambos casos determinaron el cumplimiento de los beneficios que proporciona el marco de negociación automática basado en restricciones difusas. Se produjo una considerable minimización del tiempo respecto a un marco de negociación real. Demostramos que, aunque la duración de las negociaciones es mínima, está fuertemente relacionada con diversos parámetros como ser la cantidad de productos en el catálogo, el número, tipo y valores de cada atributo, los valores de utilidad y las restricciones difusas iniciales establecidas por la Oficina de Compras. La eficiencia quedó en evidencia al momento de establecer una negociación en donde el catálogo del proveedor contenía un producto conveniente para él, que se acercaba a los requerimientos del Municipio. La negociación fue conducida a un acuerdo de venta de dicho producto, por lo que resultó eficiente su utilización. No se verificó la disponibilidad del sistema aunque este aspecto quedó implícito en el primer caso de estudio. El agente proveedor se encuentra disponible en cualquier momento, ya que su servicio es publicado en el Directory Facilitator. La Oficina de Compras, en el momento que lo desee, puede iniciar una negociación. Tampoco se verificó la interoperabilidad. Esta característica es propia de los sistemas multiagente. Cualquier proveedor puede desarrollar su agente y este operará sin ningún inconveniente con el agente municipal implementado. Siempre y cuando respete los protocolos definidos en la presente tesis. La usabilidad del sistema es una virtud que cabe destacar. El usuario del sistema es totalmente ajeno al dominio sobre el que se negocia. A partir de términos lingüísticos fácilmente entendibles, cualquier persona puede especificar un requerimiento de compra. 7.2 Limitaciones encontradas Las limitaciones que surgen del presente trabajo se relacionan principalmente con la adaptación de la herramienta a un contexto real de compras en una entidad municipal de gobierno. Como mencionamos en el capítulo 5, el sistema es de utilidad para los casos de compra directa, donde cada proveedor se debe encontrar registrado en el municipio para poder participar. No existen trabas legales para implementar la herramienta bajo este marco (siempre que se considere que los precios de los productos no superen los $37000 que permite la compra directa), pero indudablemente la adaptación implica que cada proveedor cuente con un catálogo de sus productos, cada uno de ellos especificado con sus atributos, lo cuales serán negociados. Este requerimiento para que los proveedores participen puede resultarles engorroso, y provocar un efecto reticente en la utilización de la herramienta por parte de ellos. Todo lo expuesto en este trabajo se aplica en negociaciones bilaterales, entre un municipio y un proveedor en particular. Cada vez que el Sector de Compras especifica un requerimiento de compra en el sistema, y comienza el proceso de búsqueda de proveedores, cada negociación que se inicia es bilateral, independiente de las demás. El sector debe comprarle a un único proveedor, aunque se haya negociado con varios al mismo tiempo, sobre un mismo requerimiento de compra. El sistema no contempla esta situación final, por lo que es una limitación a ser resuelta. A su vez, esta independencia en las negociaciones imposibilita que puedan compararse determinados atributos dentro del protocolo entre los proveedores participantes, como sí puede hacerse en un ámbito real. Por ejemplo, el Sector de Compras puede estar particularmente interesado en los precios de los productos ofrecidos; cuando se recibe una oferta de venta, se podría querer comparar su precio con el de otras ofertas recibidas en el resto de las negociaciones. Otro aspecto no contemplado en el estudio de la presente tesis es la proactividad del sistema ante situaciones de escases de determinados productos. La disponibilidad que brinda la herramienta y que permite iniciar una negociación en cualquier momento, puede ser potenciada si, además, se define una situación crítica en donde se torne imperioso negociar un producto con pocas unidades en el stock municipal. En forma automática, se puede detectar esta escases y comenzar una negociación utilizando un requerimiento de compra pre fijado con anterioridad. 7.3 Trabajos futuros Partiendo desde las limitaciones mencionadas en la sección anterior, una posibilidad de ampliar la funcionalidad de la herramienta en trabajos futuros es resolver dichas limitaciones. Señalamos lo engorroso que puede resultarle a un proveedor generar una base de datos con todos los productos con los que cuenta, detallados a partir de sus atributos; todo esto con el fin de poder participar en negociaciones automáticas. Una solución es que el municipio proporcione a cada proveedor un gran catálogo general bien definido, para que luego cada uno de ellos especifique las unidades con las que cuenta (que puede ser 0 si es que no trabaja con una determinada firma) y el valor de utilidad que le reporta vender cada uno de esos productos. Con esta propuesta se facilitaría en gran medida el proceso de adaptación. Otra limitación a resolver es la de a qué proveedor comprarle luego de entablar varias negociaciones sobre un mismo requerimiento de compra. Una posibilidad es implementar un proceso de resolución de compra en el que, de todas las negociaciones que llegaron a un acuerdo, nos quedamos con el proveedor cuyo producto reportó un mayor grado de satisfacción global respecto a los demás. Se puede refinar el proceso indicando la preferencia de uno a más atributos por sobre otros, al momento de definir al proveedor ganador. Por ejemplo, la Oficina de Compras puede especificar que al momento de definir al ganador, se tome en cuenta el precio más bajo y la calidad más alta. Esta preferencia es independiente de la valoración de los atributos en el requerimiento de compra, y solo tiene un propósito final que es la de obtener un solo producto entre los acordados en las diferentes negociaciones. El modelo de negociación que utilizamos como referencia, se basa, en su mayoría, en la idea de que el agente comprador revele la mínima información posible respecto de sus pretensiones. Esta característica está orientada a negociaciones bilaterales en donde la revelación de información por parte del comprador puede provocar una actitud especulativa en el agente vendedor. Por este motivo, nuestro agente municipal envía cada restricción del requerimiento de compra en la medida que lo crea necesario y el proveedor se lo solicite. Al momento de llevar a cabo el segundo caso de estudio, con el fin de analizar la performance del sistema, notamos algunas situaciones en donde el producto que se obtuvo luego de haber negociado un determinado tiempo, se ajustaba exactamente al requerimiento de compras inicial del agente municipal. Evidentemente la duración hubiera sido mínima si el requerimiento de compra hubiera sido enviado completamente desde el inicio de la negociación. El agente municipal mantendría en reserva todo lo que se refiera a la valoración de cada producto recibido, y el agente proveedor solicitaría relajaciones en forma conveniente, siempre y cuando no cuente con un producto que se ajuste al requerimiento. Claramente, esta propuesta se contrapone con la idea de no revelar información; pero podemos considerar que en nuestro contexto, donde contamos con varias negociaciones bilaterales, no le resulta conveniente a un proveedor tomar una actitud especulativa, porque puede hacerle perder una venta en manos de otro que ofrezca un producto que se ajuste mejor al requerimiento de compra. Puede ser interesante el análisis de este nuevo enfoque en futuros trabajos. En otro sentido, cuando hablamos de las características que tiene la herramienta, mencionamos la posibilidad de integrar sistemas heterogéneos. Esto permite a cada proveedor implementar su propio agente inteligente negociador que, a su vez, cuente con sus propios mecanismos de decisión. El requisito principal es que debe respetarse el protocolo que hemos definido en la presente tesis. El resultado de esto es un sistema multiagente altamente extensible, que irá creciendo en la medida que los proveedores vayan sumándose al mismo. Bibliografía Abramson, M. A., & Means, G. (2001). E-government 2001. Rowman & Littlefield Publishers, Inc. Austin, J. L. (1962). How To Do Things With Words. Oxford University Press, Oxford. Beam, C., & Segev, A. (1997). Automated Negotiations: A Survey of the State of the Art. Wirtschaftsinformatik. Bellifemine, F., Caire, G., Trucco, T., & Rimassa, G. (2005). JADE Programmer's Guide. Bellifemine, F., Poggi, A., & Rimassa, G. (2001). Developing multi-agent systems with a FIPA-compliant agent framework, Software - Practice and Experience, 31. 103-128. Borst, W. (1997). Construction of Engineering Ontologies for Knowledge Sharing and Reuse. University of Twente. Enschede, The Netherlands. Buttner, R. (2006). A classification structure for automated negotiations. In WI-IATW ’06: Proceedings of the 2006 IEEE/WIC/ACM international conference on Web Intelligence and Intelligent Agent Technology. Washington, DC, USA. Cyber Law in Australia. (2010). Kluwer Law International. Deborah Morley, C. S. (2009). Understanding Computers: Today & Tomorrow. Course Technology Cengage Learning. Dubois, D., Fargier, H., & Prade, H. (1994). Propagation and satisfaction of flexible constraints. Fuzzy Sets, Neural Networks and Soft Computing. Elamy, A. H. (2005). Perspectives in Agent-Based Technology. AgentLink News. Faratin, P. (2000). Automated Service Negotiation Between Autonomous Computational Agents. University of London, Queen Mary and Westfield College Department of Electronic Engineering. Faratin, P., Sierra, C., & Jennings, N. R. (1998). Negotiation decision functions for autonomous agents. Robotics and Autonomous Systems. Fatima, S. S. (2004). An agenda-based framework for multi-issue negotiation. Finin, T., Labrou, Y., & Mayfield, J. (1995). KQML as an Agent Communication Language. In Proc. of the 3rd International Conference on Information and Knowledge Management. FIPA. (2002b). FIPA ACL Message Structure Specification. Obtenido de FIPA Standard Specification 00061: http://www.fipa.org/specs/fipa00061/SC00061G.pdf Genesereth, M., & Fikes, R. (1992). Knowledge Interchange Format, Version 3.0 Reference Manual. Technical report logic. Computer Science Department, Stanford University. Gruber, T. R. (1993). A translation approach to portable ontology specifications. Knowledge Acquisition. Harsanyi, J. C. (1968). Games with Incomplete Information Played by ‘Bayesian' Players. Management Science. Hauser, J. R., & Wernerfelt, B. (1990). An evaluation cost model of considerations sets. Journal of Consumer Research. Huhns, M. N. (1999). Multiagent Systems and Societies of Agents, in G. Weiss (ed.), Multiagent Systems: A Modern Approach to Distributed Artificial Itelligence. Cambridge, MA: The MIT Press. Jennings, N. (2001). An Agent-Based Approach for building Complex Software Systems. Communications of the ACM. Jennings, N. R., & Narayanan, V. (2005). An adaptive bilateral negotiation model for ecommerce settings. In Proc. of the 7th IEEE International Conference on ECommerce Technology (CEC 2005). Jennings, N. R., Faratin, P., Lomuscio, A. R., Parsons, S., Sierra, C., & Wooldridge, M. (2001). Automated negotiation: Prospects, methods and challenges. International Journal of Group Decision and Negotiation. Jennings, N. R., Parsons, S., Noriega, P., & Sierra, C. (1998a). On argumentation-based negotiation. Dedham, USA: In Proceedings of International Workshop on MultiAgent. Jennings, N. R., Sycara, K., & Wooldridge, M. (1998b). A roadmap for agent research and development. Autonomous Agents and Multi-Agent Systems. Jovarauskienė, D., & Pilinkienė, V. (2009). E-Business or E-Technology? COMMERCE OF ENGINEERING DECISIONS. ISSN 1392-2785 ENGINEERING ECONOMICS. 2009. No 1 (61). Keeny, R., & Raiffa, H. (1976). Decisions with Multiple Objectives: Preferences and Value Tradeoffs. John Wiley and Sons. Klir, G. J., & Yuan, B. (1995). Fuzzy Sets and Fuzzy Logic: Theory and Applications. Prentice-Hall. Kraus, S. (2001b). Strategic Negotiation in Multiagent Environments. Mit Press. Kraus, S., Sycara, K., & Evenchick, A. (1998). Reaching agreements through argumentation: A logical model and implementation. Artificial Intelligence. Laboratorio de Agentes Software Inteligentes. (2001). Multi-Agent Systems. Universidad de Carnegie Mellon. Liu, J. W. (2010). Breaking the ice between Government and business: From IT-Enabled Control Procedure Redesign to truested relationship building. López Carmona, M. A. (2006). Estrategias de Negociación Automática Basadas en Restricciones Difusas sobre Sistemas Multiagente. Alcalá de Henares. Matthias Klusch, L. K. (2000). Cooperative Information Agents IV - The Future of Information Agents in Cyberspace. Springer. Naser, A., & Concha, G. (Abril de 2011). El gobierno electrónico en la gestión pública. Santiago de Chile, Chile: Instituto Latinoamerica y del Caribe de Planificación Económica y Social (ILPES). Nash, J. (1950). The bargaining problem. Econometrica. Ortiz, S., López Gallego, C., & Oviedo Carrascal, A. I. (2009). Sistema multiagente para el apoyo a la gestion de inventarios en itil mediante el monitoreo distribuido de software y hardware en una red corporativa. Avances en Sistemas e Informática. Osborne, M. J., & Rubinstein, A. (1994). A Course in Game Theory. MIT Press, Cambridge, Massachusetts. Rahwan, I. R. (2004). Argumentation-based negotiation. The knowledge Engineering Review. Raiffa, H. (1982). The Art and Science of Negotiation. Harvard University Press. Rosenschein, J. S., & Zlotkin, G. (1994). Rules of Encounter. MIT Press, Cambridge MA, USA. Russell, S., & Norvig, P. (2004). Inteligencia Artificial. Un Enfoque Moderno. Segunda edición. Pearson Prentice. Sandholm, T. W. (1999). Distributed rational decision making. Scheneider, G. P. (2004). Comercio Electrónico - Tercera edición. Thomson. Searle, J. R. (1969). Speech Acts: an Essay in the Philosophy of Language. Cambridge University Press, Cambridge. Sen, S. (1997). Developing an automated distributed meeting scheduler. IEEE Intelligent Systems. Studer, R., Benjamins, R., & Fensel, D. (1998). Knowledge Engineering: Principles and Methods. Data and Knowledge Engineering. Sycara, K. (1989). Argumentation: Planning other agent's plans. In Proceedings of the 11th International Joint Conference on Artificial Intelligence. Tecuci, G. (1998). Building Intelligents Agents (An Apprenticeship Multistrategy Learning Theory, Methodology, Tool and Case Studies). Vlassis, N. (2003). A Concise Introduction to Multiagent Systems and Distributed AI. von Neuman, J., & Morgenstern, O. (1944). The Theory of Games and Economic Behaviour. Princeton University Press, Princeton NJ, USA. Wooldridge, M. (2002). An Introduction to Multiagent Systems. John Wiley & Sons. Wooldridge, M. (2009). An Introduction to MultiAgent Systems - Second Edition. John Wiley & Sons. Wooldridge, M., & Jennings, N. R. (1995). Intelligent Agents: theory and practice. The Knowledge Engineering Review. Xudong Luo, J. H.-m.-f. (2003). Prioritised Fuzzy Constraint Satisfaction Problems: Axioms, Instantiation and Validation. Yokoo, M. (2001). Distributed Constraint Satisfaction. Springer Verlag.