Metodología para crear aplicaciones de programación por restricciones como servicio web. Definición e implementación con diversos casos

Transcripción

1 Metodología para crear aplicaciones de programación por restricciones como servicio web. Definición e implementación con diversos casos Juan Francisco Díaz. Ph.D, Carlos Martinez. Ing, Carlos Andrés Delgado. Ing, María Andrea Cruz, Luis Felipe Vargas. Grupo de investigación AVISPA. Escuela de Ingeniería de Sistemas y Computación, Universidad del Valle {juanfco, camarti, cardel87, andrea1391, felipex1991}@gmail.com Febrero, 2012 Resumen El paradigma de programación por restricciones permite solucionar un gran número de problemas combinatorios y de optimización, sin embargo la mayor parte de desarrollos sólo funcionan localmente y se requiere la instalación de librerías; cumplir con ciertas restricciones de compatibilidad de versiones del sistema operativo y sus librerías de núcleo, y configurar ciertas variables de entorno, lo que entorpece la expansión de las aplicaciones. Para ello se presenta una propuesta de metodología que permita acceder a estás aplicaciones utilizando un Navegador Web y no sea necesario que el usuario necesite instalar alguna aplicación o librería para hacer uso de ella. En esta metodología se plantea el uso de XML como el formato para la codificación de las entradas y salidas de las aplicaciones donde sea posible, el uso de gestores de contenido para crear y administrar los portales Web, el uso de librerías de código abierto para implementar la interactividad con el usuario y el uso de lenguajes como PHP para crear las rutinas necesarias para el funcionamiento de la aplicación desde una página Web. Términos clave Programación por restricciones, metodología, XML, PHP, Portal Web. I. INTRODUCCIÓN Una de las líneas de investigación del grupo AVISPA es la programación por restricciones. Un buen número de proyectos de grado han sido desarrollados resolviendo problemas del mundo real usando la programación por restricciones. Sin embargo, esos desarrollos no son visibles hoy debido a que se desarrollaron en una máquina específica con un software específico que debe ser instalado para que se pueda correr. En el año 2010, se abordó la tarea de construir una aplicación funcionalmente parecida a CREAR[1], una aplicación por restricciones construida con los mismos inconvenientes mencionados, pero que pudiera ser usada como un Servicio Web, ofrecido desde el servidor de AVISPA. El resultado es visible hoy en y le permite al grupo mostrar en diferentes eventos el producto de ese trabajo. Se pretende entonces definir una metodología general para el desarrollo de aplicaciones por restricciones, basada en el trabajo realizado para construir la versión web de CREAR, y aplicarla a trabajos desarrollados previamente en el grupo como la aplicación de planificación del decolaje de aviones desarrollada por Javier Mena, u otras desarrolladas por Jairo Maldonado[2] o Aldemar Villegas[3]. Con esto se busca en los proyectos que se realizan bajo el paradigma de programación por restricciones se aplique una metodología para que la aplicación sea un servicio WEB. II. LA METODOLOGÍA Para que una aplicación desarrollada bajo el paradigma de programación por restricciones se pueda acceder vía Web, se deben realizar los siguientes pasos: 1. Estandarización de las entradas: Aunque en algunos problemas no es posible utilizarlo como se verá más adelante, se recomienda utilizar el formato XCSP para definir las entradas del problema. 2. Estandarización de las salidas: Se establece utilizar el lenguaje XML para definir las salidas. 3. Estandarización de los parámetros de las aplicaciones: Se establece que las aplicaciones reciben parámetros desde la línea de comandos. 4. Uso de gestores de contenido: Los gestores de contenido permiten la construcción rápida de sitios Web con funciones de gestión de usuarios, contenido y acceso. 5. Uso de PHP como conector El lenguaje PHP, el cual es interpretado por el servidor permite el envío y la recepción de información a aplicaciones residentes en el servidor 6. Uso de librerías de JavaScript para interactividad: Estás librerías permiten desarrollar funciones para que la experiencia de los usuarios con el portal sea agradable e intuitiva. 7. Uso de APIs de libre uso como herramienta de apoyo: Existen en la red algunos APIs que proporcionan funciones de creación de gráficas interactivas o de animación, en la metodología propuesta sirven como apoyo para la visualización de los resultados que arroja la aplicación, en otras palabras es el uso de SaaS o Software como Servicio proveído por grids o clouds en la red.

2 II-A. Estandarización de las entradas Para las entradas en XML se recomienda utilizar el formato XCSP[4] para definirlas. En éste caso se utiliza la definición conocida como dict. El formato XCSP se utiliza para representar redes de restricciones utilizando XML. El objetivo de la representación XCSP es reducir el esfuerzo requerido para probar y comparar diferentes algoritmos que proveen un banco de pruebas para instancias de satisfacción de restricciones. La representación XCSP es de bajo nivel para cada instancia, los dominios, variables, relaciones, predicados y las restricciones son exhaustivamente definidas. Estructuras que son de control de flujo como lo son los ciclos for o sentencias if o else pueden ser utilizadas. Existen dos variantes del formato XCSP: una representación totalmente etiquetada y una representación abreviada. La representación totalmente etiquetada está completamente estructurada para ser utilizada por herramientas XML genéricas. Un ejemplo es el siguiente considere un problema que tiene dos variables A1 y A2, se asume que las variables se encuentran en el Domino [1, 2] <domains nbdomains= 1 > <domain name= d0 nbvalues = 2 >1..2 </ domain> </ domains> <v a r i a b l e s n b V a r i a b l e s = 2 > <v a r i a b l e name= A1 domain= d0 /> <v a r i a b l e name= A2 domain= d0 /> </ v a r i a b l e s > <c o n s t r a i n t name= c0 a r i t y = 2 scope = A1 A2 r e f e r e n c e = g l o b a l : a l l d i f f e r e n t /> Es importante resaltar que este estándar es especialmente útil para la especificación de problemas que no tengan parámetros de entrada por ejemplo, el problema de las N Reinas, por lo anterior no se descarta el uso de un formato XML propio o uno que no sea XML que sea más expresivo, según sea el tipo de problema a trabajar. La definición conocida como dict[5] o diccionario, es asociar un orden convencional con un diccionario. Este orden convencional especifica un orden de llaves que pueden ser usadas para acortar notaciones. Mientras el grupo de llaves pueda ser conocido desde el contexto, los valores de cada llave puede ser escrito en un notación abreviada listando los valores de cada llave que son conocidas en el diccionario. Por ejemplo, las coordenadas de un punto pueden ser representadas por un diccionario que contiene dos llaves x e y. El punto de coordenadas (2, 5) puede ser representado de la siguientes formas: <d i c t > <e n t r y key= x >2</e n t r y > <e n t r y key= y >5</e n t r y > </ d i c t > <d i c t > <e n t r y key= y >5</e n t r y > <e n t r y key= x >2</e n t r y > </ d i c t > { / x 2 / y 5} { / y 5 / x 2} { / x 2 / y 5 } Un orden convencional es correcto cuando indica que la llave x está antes de la llave y, en el diccionario se puede escribir: {2 5} II-B. Estandarización de las salidas El lenguaje XML permite la libre definición de etiquetas. Para efectos de estandarizar el formato XML de las salidas se opta por: 1. Establecer la raíz del documento: <s o l u t i o n > </ s o l u t i o n > 2. Establecer el encabezado y el reporte de la salida, en el encabezado va la información referente a la ejecución, costos e información general de la solución de un problema por restricciones, y en el reporte se encuentra la solución a una entrada específica. <s o l u t i o n > <head>... </ head> <r e p o r t >... </ r e p o r t > </ s o l u t i o n > Con la especificación de ésta representación, queda a libertad del desarrollador de la aplicación especificar cómo desea representar la salida de los datos; sin embargo se recomienda tener en cuenta que la representación debe ser coherente y ser de fácil entendimiento.

3 II-C. Estandarización de los parámetros de las aplicaciones Se define que para el paso de parámetros por consola de la siguiente manera: Sí el parámetro es de un sólo carácter se utiliza un guión para indicarlo, por ejemplo f. En caso de que el parámetro tenga más de un carácter se utiliza doble guión para indicarlo, por ejemplo file. En los parámetros de la aplicación permiten que el usuario pueda definir algunas opciones de ejecución de la aplicación, por ejemplo que archivo de entrada se utiliza, que tiempo máximo de ejecución es permitido, entre otros. El control del tipo y rango de cada uno de los parámetros se realiza en la misma aplicación de la siguiente manera: ARGS= { A p p l i c a t i o n. getcmdargs r e c o r d ( f ( s i n g l e c h a r :& f t y p e : s t r i n g d e f a u l t : b e a s l e y examples / a i r l a n d 1. t x t ) r c ( s i n g l e t y p e : i n t ( min : 1 ) d e f a u l t : 1 ) ds ( s i n g l e t y p e : i n t d e f a u l t : 2 ) tm ( s i n g l e t y p e : i n t d e f a u l t :30000 ) np ( s i n g l e t y p e : i n t ( min : 1 ) d e f a u l t : 1 ) ) } En este caso se define así: f es una cadena de caracteres, rc es un entero cuyo valor mínimo es 1, ds es un entero cuyo valor mínimo es 2, tm es un entero de valor máximo y np que es un entero cuyo valor mínimo es 1. II-D. Gestores de contenido Los gestores de contenido permiten crear una estructura para la creación y administración de contenidos, principalmente en páginas web. Estos consisten de una interfaz que permite controlar una o varias bases de datos donde se almacena el contenido del sitio web, por lo que es posible manejar de forma independiente el contenido y el diseño del sitio. Por lo tanto es posible administrar el contenido y aplicar en cualquier momento un diseño distinto al sitio web sin tener que modificar el contenido; además permite el manejo de roles de usuarios para manejar la visualización y administración del sitio. En este caso se ha seleccionado el gestor de contenidos Drupal porque: II-E. A pesar que tiene una curva de aprendizaje un poco más elevada que Joomla, tiene a su favor que tiene un mayor número de herramientas a su disposición. Permite la fácil integración de Frameworks y código PHP dentro de sus páginas. Presenta un entorno simplificado de gestión de usuarios y de estructura del portal web. Uso de PHP como conector PHP es un lenguaje de programación interpretado para la creación de páginas Web con contenido dinámico. Este permite tomar los datos y archivos suministrados al usuario, ejecutar una aplicación en el servidor y retornar los resultados o archivos de salida. En la metodología, PHP se utiliza para lo siguiente: Enviar el archivo que suministra el usuario de entrada y los parámetros de la aplicación. Seleccionar una entrada predefinida en el servidor en lugar de la entrada suministrada por el usuario. Ejecutar la aplicación en el servidor. Tomar la salida de la ejecución y desplegarla para ser visualizada por el usuario, o bien mostrar un mensaje de error si la aplicación no funciona correctamente. El paso por parámetros de la aplicación. II-F. Uso de librerías de JavaScript para interactividad Existen muchas librerías para JavaScript como lo son JQuery y ExtJS sin embargo, debido a que algunas proporcionan toda la interfaz son incompatibles con un gestor de contenido como es el caso de ExtJS. Por lo tanto se ha seleccionado JQuery para proporcionar interactividad al portal Web; ésta librería es gratuita, de código abierto y cuenta con una gran cantidad de plugins que permiten realizar algunas funciones interactivas con gran facilidad. II-G. Uso de APIs de libre uso como herramienta de apoyo En la red existen algunas herramientas o APIs de uso gratuito que permiten el uso de sus funciones para ser desplegadas en una página Web. Se utiliza la herramienta Google Chart API, para la generación de las gráficas que permiten una mejor comprensión de las salidas III. LA METODOLOGÍA APLICADA A PROBLEMAS CONOCIDOS A continuación, se realiza un estudio aplicando la metodología anteriormente descrita a dos problemas anteriormente desarrolladas por el grupo. III-A. El problema de cadena de suministros como aplicación Web El problema de cadena de suministros[2] es aquél donde se deben satisfacer los siguientes lineamientos: Satisfacción del requerimiento de un cliente. Cumplir con estándares óptimos de calidad. Ofrecer el producto a precios razonables. Emplear tiempos de servicio óptimos. Ejecutar todas las etapas de la cadena al menor costo posible. III-A1. Descripción de la entrada: La entrada original de la aplicación es un archivo de texto simple, el cual posee la siguiente estructura: P l a n t a s : Numero e n t e r o C e n t r o s : Numero e n t e r o Bodegas : Numero e n t e r o P r o d u c t o s : Numero e n t e r o P e r i o d o s : Numero e n t e r o T i p o s V e h i c u l o : Numero e n t e r o

4 T a s a O p o r t u n i d a d : Numero e n t r e 0 y 1 F a c t o r I n v e n t a r i o S e g u r i d a d : Numero Demanda : p r o d u c t o ( bodega ( p e r i o d o (< L i s t a de numero e n t e r o s >) DesEsta : p r o d u c t o ( bodega ( p e r i o d o (< L i s t a de numero e n t e r o s >) Capacidad almacenamiento:<<capacidad almacenamiento de cada Bodega>> Capacidad p r o d u c c i o n ::<< Capacidad almacenamiento de cada p l a n t a >> c o s t o s P r o d u c c i o n:<<capacidad ó p r o d u c c i n por p r o d u c t o de cada p l a n t a >> c o s t o almacenamiento:<<capacidad almacenamiento de cada Bodega>> I n v e n t a r i o I n i c i a l :<> C o s t o T r a n s p o r t e:<<costo de t r a n s p o r t e de cada p l a n t a a bodega>> FactorDePeso:<< F a c t o r de peso de cada producto >> C o s t o T r a n s p o r t e:<<costo de t r a n s p o r t e de cada t i p o de ívehculo>> Capacidad:<<Capacidad de t r a n s p o r t e de cada t i p o de ívehculo>> C a n t i d a d:<<c a n t i d a d i s p o n i b l e de cada t i p o de ívehculo>> Utilizando la definición dict del formato XCSP se obtiene la transformación de la entrada a la siguiente forma: <?xml v e r s i o n = 1. 0 encoding = UTF 8?> R e p r e s e n t a c i o n d e l problema de l a ó m i n i m i z a c i n de c o s t o s en l a s c a d e n a s de s u m i n i s t r o s <d i c t > <e n t r y key= P l a n t a s > <l i s t > i n t i n t </ l i s t > </ e n t r y > <! p a r a t o d o s l o s ítem > <e n t r y key= Demanda > <t u p l e > <e n t r y key= p r o d u c t o > <t u p l e > <e n t r y key= bodega > <t u p l e > <e n t r y key= p e r i o d o > <l i s t > i n t i n t </ l i s t > </ e n t r y > </ t u p l e > </ e n t r y > </ t u p l e > </ e n t r y > </ t u p l e > </ e n t r y > <! e n t r y key para l o s o t r o s ítem > </ d i c t > III-A2. Parametrización de la aplicación: Los parámetros de la aplicación son los siguientes: Tabla I PARÁMETROS APLICACIÓN CADENA DE SUMINISTROS Componente Equivalencia Datos del programa El parámetro f tipo string Estrategia de búsqueda El parámetro es tipo string, puede ser None, CostLess, PeriodLess, PeriodAndCostLess y DistributionOrder Propagador costo El parámetro pc tipo int 0 false o 1 true. Imponer Restricciones Técnicas El parámetro rt tipo int cuyo mínimo valor aceptado es 0 false y su máximo valor 1 true. Nivel de recomputación El parámetro rc int Mínimo 1 y máximo 10 Tiempo de ejecución [Seg] El parámetro tm tipo int Mínimo 1 y máximo Motor de búsqueda El parámetro m tipo string, puede ser: search- Best o exploreone III-A3. Descripción de la salida: La salida contiene la siguiente información: Envíos de productos en los periodos especificados en la entrada, desde una planta a un centro de distribución. Envíos de productos en los periodos especificados en la entrada, desde un centro de distribución a una bodega menor. Uso de los vehículos de transporte de mercancías, de un centro de distribución a una bodega menor en los periodos especificados en la entrada. El inventario cíclico de cada centro de distribución en los periodos indicados en la entrada. El inventario cíclico de cada bodega menor en los periodos indicados en la entrada. Los costos finales, es decir, de todos los periodos, de producción, transporte, de inventarios cíclicos y de seguridad. Para el formato XML de la salida de la aplicación, se muestra toda la información mostrada en los reportes de la aplicación original. El siguiente es el formato de salida, para cuando la aplicación genera una solución. <?xml v e r s i o n = 1. 0 encoding = UTF 8?> <s o l u t i o n authorxml= Maria Andrea Cruz Blandon > <head s o l u t i o n = Tipo s o l u c i o n Óptima o No óptima > <searchtime> f l o a t </ searchtime> <numbersolution > i n t </ numbersolution > <! Otra i n f o r m a c i o n r e l e v a n t e > </ head> <r e p o r t > <DCShippings> <DCShipping> <f a c t o r y > i n t id F </ f a c t o r y > <c e n t e r > i n t id C </ c e n t e r > <t r a n s p o r t a t i o n P r i c e > i n t </ t r a n s p o r t a t i o n P r i c e > i n t id P

5 i n t i n t <n u m b e r O f S h i p p i n g s P e r P e r i o d > <l i s t > i n t i n t </ l i s t > </ n u m b e r O f S h i p p i n g s P e r P e r i o d > </ DCShipping> </ DCShippings> <SWShippings> <SWShipping> <! I n f o r m a c i o n r e l e v a n t e > </SWShipping> </ SWShippings> <t r a n s p o r t a t i o n V e h i c l e s > <t r a n s p o r t a t i o n V e h i c l e > <! I n f o r m a c i o n r e l e v a n t e > </ t r a n s p o r t a t i o n V e h i c l e > </ t r a n s p o r t a t i o n V e h i c l e s > <DCInventoryTurnovers> <DCInventoryTurn> <! I n f o r m a c i o n r e l e v a n t e > </ DCInventoryTurn> </ DCInventoryTurnovers> <SWInventoryTurnovers> <SWInventoryTurn> <! I n f o r m a c i o n r e l e v a n t e > </ SWInventoryTurn> </ SWInventoryTurnovers> <! Costo de cada i t e m > <c o s t s > <c o s t > <name> T o t a l </name> <value> i n t </ value> </ c o s t > </ c o s t s > </ r e p o r t > </ s o l u t i o > Los errores que se presenten durante la ejecución son mostrados en la salida estándar. Por lo que el portal Web, debe verificar si se presentó un error captando el contenido de la salida estándar. III-B. El problema de secuenciamiento de aviones como aplicación Web El problema de secuenciamiento de aviones[6] se establece cuando a la entrada del rango del radar del controlador de trafico aéreo (ATC) en un aeropuerto, entra un avión que requiere se le asigne un tiempo de aterrizaje y la pista donde debe aterrizar. El tiempo de aterrizaje está ligado a una ventana de tiempo que tiene cada avión, limitada por un tiempo inicial mínimo y un tiempo final máximo, estos tiempo varían para cada avión, El tiempo mínimo representa el tiempo más temprano en el cual un avión puede aterrizar si vuela a su máxima velocidad aérea. El tiempo máximo representa el tiempo más tarde en el cual el avión puede aterrizar si vuela a una velocidad que tenga el mejor rendimiento de combustible, mientras se mantiene en el aire dando vueltas se generan costos adicionales por gasto de combustible. Cada avión tiene una velocidad en la cual los costos son los mínimos, la velocidad preferida, que es llamada velocidad de crucero. Se dice de un avión que está asignado en su tiempo favorito, o tiempo objetivo, si se necesita que planee su tiempo de aterrizaje de manera que vuele en su velocidad de crucero. Si el controlador necesita que el avión ya sea, baje su velocidad, la mantenga o acelere, se incurrirá en un costo, el cual crecerá en la medida que la diferencia entre el tiempo asignado para que aterrice y el tiempo objetivo aumente. El tiempo entre el aterrizaje de un avión en particular, y el aterrizaje sucesivo de cualquier avión, debe ser mayor o igual que un mínimo especificado (el tiempo de separación) el cual depende de los aviones involucrados. Con estas restricciones el objetivo de la aplicación es asignar el tiempo de aterrizaje de los aviones y la pista. III-B1. Descripción de la entrada: La entrada se describe de la siguiente forma: <numero de aviones> <tiempo muerto o freeze time > por cada avión i (i=1,2,3... p) : < tiempo aparición> <tiempo mínimo de aterrizaje> <tiempo Objetivo > <tiempo máximo aterrizaje> <costo antes de tiempo objetivo> <costo después de tiempo objetivo>. por cada avión j = (1, 2, 3,...p) el tiempo de separación mínimo requerido para que ocurra otro aterrizaje una vez i ya haya aterrizado. si i es igual a j se modela con el infinito en el caso de los ejemplos En otras palabras siendo S i,j la variable que representa el tiempo de separación obligatorio entre el par de aviones i, j se tiene j datos a continuación Este ejemplo se lee de la siguiente manera. Se tienen 10 aviones el tiempo de separación mínimo entre cada par de aviones es 10. Para el avión numero 1 sus datos se interpretan así:

6 Aparecerá en el tiempo 54 Lo máximo que puede esperar es 559 Tabla II DATOS AVIÓN 1 Como mínimo debe esperar 129 unidades de tiempo para aterrizar El costo de aterrizar antes de su tiempo objetivo es Si espera 155 unidades de tiempo el costo de la espera sera 0 ya que es su tiempo objetivo Su tiempo objetivo es Una vez que aterrice el avión 1, este avión 1 se relaciona con todo el resto de aviones y se establecerá el tiempo que estos deben esperar en caso de que el avión 1 aterrice justo antes que ellos. En este ejemplo se tienen 10 aviones por lo tanto se relaciona con los diez contándose a sí mismo y se coloca (que indica infinito) donde corresponde al dato avión 1 con avión 1. Sea S i,j Tiempo que debe esperar el avión j una vez haya aterrizado el avión i Para el avión numero 2 sus datos se interpretan así: Aparecerá en el tiempo 120 Lo máximo que puede esperar es 744 Tabla III DATOS AVIÓN 2 Como mínimo debe esperar 195 unidades de tiempo para aterrizar El costo de aterrizar antes de su tiempo objetivo es Si espera 258 unidades de tiempo el costo de la espera sera 0 ya que es su tiempo objetivo Su tiempo objetivo es Se repite el proceso para los aviones 3, Para éste problema se ha decidido no transformar la entrada a formato XML teniendo en cuenta que la forma de representar las entradas ya está definida en [BS1][7] y [BS2][8]. III-B2. Parametrización de la aplicación: En el caso de éste problema se utilizan los siguientes parámetros: Tabla IV PARÁMETROS APLICACIÓN SECUENCIAMIENTO AVIONES f <ruta > rc <valor > ds <valor > tm <valor > np <valor > <valor >: String ubicación del archivo entrada <valor >: dato numérico grado de recomputación por defecto es 1 <valor >: dato numérico distribuidor que usara la búsqueda por defecto es 1 <valor >: dato numérico tiempo máximo de ejecución por defecto es 3000 ms <valor >: dato numérico cantidad de pistas por defecto es 1 procedimientos para acceder a los argumentos de las aplicaciones. Como el paso de los argumentos es por consola se usa getcmdargs el cual recibe los argumentos y los asigna a las variables que se definen en el registro ingresado. Un ejemplo de ejecución es:. / ASPSolver. exe f a i r l a n d 1. t x t r c 1 ds 1 tm 3000 Una vez se toma por consola los parámetros, se le asignan a variables que ya en la implementación con la interfaz gráfica eran asignadas. ENA =ARGS. f %r u t a de a r c h i v o s NER =ARGS. r c % Recomputacion NTM =ARGS. tm % TMax NPS =ARGS. np % NumPistas III-B3. Descripción de la salida: Una vez se remueve todo lo referente a la interfaz de entrada y de salida en el código fuente de la aplicación, se realiza una serie de modificaciones en el código para que sólo sea necesario un llamado desde consola para que genere la solución directamente sin necesidad de intervención del usuario. A continuación se muestra un ejemplo de el archivo de salida, para la ejecución del archivo de prueba airland2.txt 1 paso seguido se explican las etiquetas y el significado del orden en el cual aterrizan los aviones en cada pista de aterrizaje. <?xml v e r s i o n = 1. 0 encoding = UTF 8 s t a n d a l o n e = yes?> <s o l u t i o n > <Head> <numsolutionsfound Optimal = yes > <<Numero s o l u c i o n e s >> </ numsolutionsfound> <c o s t > << Costo >></c o s t > <T o t a l t i m e > 10 </ T o t a l t i m e > </Head> <r e p o r t > <runway id = 1 > <id >5</id> <o r d e r > Orden en que l l e g a </ o r d e r > <timelanding>tiempo a t e r r i z a j e </ timelanding > <t i m e T a r g e t >Tiempo o b j e t i v o </ t i m e T a r g e t > <t o t a l C o s t >Costo t o t a l </ t o t a l C o s t > <minimumwait>tiempo e s p e r a ímnimo</minimumwait> <!... > <!... > Se utiliza Aplication de Oz qué es un módulo que provee 1 Disponible en: trunk/instance/airland2.txt?spec=svn2&r=2 a Febrero de 2012

7 </runway> <o r d e r >5 </ o r d e r > <!... > <runway id = n > <!... > </runway> </ r e p o r t > </ s o l u t i o n > <timelanding >150 </ timelanding> Se puede observar en este ejemplo el archivo de salida se tienen aparte de las etiquetas estándar otras etiquetas que se explican a continuación. La solución se divide en dos partes un encabezado del XML que tendrá información de rendimiento y de la calidad de la solución retornada, más no la solución como <t i m e T a r g e t >150</ t i m e T a r g e t > tal. Lo anteriormente mencionado se encapsula en la etiqueta < head > y en ella se encuentran las siguientes etiquetas: <numsolutionsfound Optimal = yes > 6 </ numsolutionsfound> En esta etiqueta se va almacena la siguiente información: primero en el atributo optimal de la etiqueta se indicara si la solución arrojada por el solver es una solución óptima al problema, mientras que el valor agrupado en la etiqueta en este caso 6, indica la cantidad de soluciones encontradas. <c o s t > 9000</ c o s t > Almacena la información del costo de la solución arrojada por el solver, es decir si el solver encuentra n soluciones se va a retornar la solución con el menor costo. <T o t a l t i m e > 10 </ T o t a l t i m e > Almacena la información referente al tiempo de ejecución en que el solver encuentra una solución. La solución con el menor costo encontrada por el solver, se encuentra encapsulada en la etiqueta <report> La primera etiqueta observada es: </ plane> Esta etiqueta encapsula los atributos específicos que describen un avión. Debe existir una etiqueta por cada avión. Dentro de ésta etiqueta se encuentran: <id >9</id> la etiqueta < id > hace referencia al número que se le asigna a un avión en la entrada de los datos. La etiqueta < order > indica el orden de aterrizaje del avión en la pista. < timelanding > indica el tiempo en el cual aterriza el avión. < timet arget > es el tiempo objetivo del aterrizaje del avión; cuando el tiempo de aterrizaje es igual al tiempo objetivo, el costo de ese aterrizaje es 0. <t o t a l C o s t >0 </ t o t a l C o s t > Esta etiqueta indica el costo que causa el aterrizaje del avión. <minimumwait>8 </minimumwait> Esta es una etiqueta muy importante ya que es dependiente del orden de aterrizaje de los aviones en la pista, esta etiqueta contiene la información del tiempo mínimo que le debe esperar un avión para aterrizar, dado el aterrizaje del anterior avión, en el caso que no haya uno antes que él el valor es 0. En procura de un buen manejo de los errores, ya sea al ingresar datos o en el archivo de entrada, se generan otros dos tipos de salida, una de ellas es por EXCEPTION de el archivo de texto ya sea por que la ruta no es válida o por que se genera un error al leerlo, y la otra es por que no encontró ninguna solución. Los errores son mostrados en salida estándar y no se genera archivo de salida. III-C. CREAR como aplicación Web dentro del Portal Debido a que CREAR fue diseñado utilizando un Frame- <runway id = 1 > </runway> Work como ExtJS que provee toda la interfaz de usuario, Esta etiqueta encapsula todos los aviones que aterrizaran en no es posible integrarlo como aplicación dentro del mismo la pista con ese id. sitio, ya que no se pude integrar un FrameWork que provee toda la interfaz en un gestor de contenidos. Además ExtJS dificulta en gran medida la escalabilidad del producto ya que no posee funciones o módulos que permitan crear fácilmente nuevo contenido. Sin embargo se puede integrar éste tipo de proyectos débilmente al portal, agregándolos como enlaces externos al mismo. III-D. El portal Web III-D1. Estructura del portal: Se recomienda tener una estructura para el sitio: Contenido externo: Es aquél contenido que no tiene información de impacto de investigación del grupo, puede

8 ser visible por cualquier persona en el portal, es muy útil incluir información de interés o de ventajas del paradigma de programación en este caso de programación por restricciones para atraer a las personas Contenido interno: Es la información sobre los proyectos y las aplicaciones para utilizarlas. Esto sólo debe ser visible por usuarios autenticados para permitir un control de acceso sobre las mismas En el portal se diferencian tres tipos de usuarios: Usuario anónimo: Este no requiere autenticación, por lo general sólo debe darse acceso a las páginas que contienen información de poco impacto para los proyectos, como lo son información general sobre el grupo, los autores y del uso del portal Usuario autenticado: Tiene acceso a la información sobre los proyectos y las aplicaciones para su uso Usuario administrador: Tiene los mismos accesos que el usuario autenticado, sin embargo puede administrar el portal, editar contenidos, administrar usuarios, etc El gestor de contenidos permite una gran variedad de temas y formas de estructuras el sitio, por lo que es posible tener cierta libertad para realizar éste proceso, sin embargo se recomiendan las siguientes buenas prácticas para realizar éste proceso: Separar por bloques: Se recomienda tener bloques diferentes para los datos de usuario o inicio de sesión, los proyectos, enlaces externos del portal e información del portal. Con esto se busca que el portal se agradable al usuario y la información sea fácilmente accesible Bloques de los proyectos: Proporciona una gran facilidad tener páginas separadas para la información del problema, el modelo y la aplicación, con esto se evita tener páginas sobrecargadas de información que distorsionan la experiencia del usuario en el portal Información sobre el portal y autores: Tiene como objetivo atraer a los usuarios a que se interesen en buscar información sobre el paradigma de programación por restricciones y así ellos puedan tenerlo en cuenta si desean solucionar algún problema o necesidad en el momento Enlaces externos: Con esto se busca que los usuarios puedan acceder a sitios de otros proyectos del grupo que no permiten Los gestores de contenidos proveen algunos módulos para agregar funciones adicionales al mismo, se recomiendan los siguientes: Un módulo que permita la creación de contenido en varios idiomas. Un módulo que permita la integración de las librerías de JavaScript y sus plugins en este caso JQuery. III-D2. Funciones del portal: El uso de gestores de contenido presenta algunas desventajas con respecto a las transparencia con respecto a JavaScript y PHP ya que que no es posible editar el encabezado de la página, definir código PHP o JavaScript directamente, para esto se deben investigar la funciones o formas que provee el gestor de contenidos para realizar éste proceso. Se requiere que el gestor de contenidos provea las siguientes funciones: 1. Acepte y permita interpretar código PHP, en el caso de Drupal es directo, ya que se puede especificar que la entrada sea código PHP directamente 2. Permita la inclusión de archivos o código JavaScript, en el caso de Drupal se requiere el uso de algunas funciones externas para modificar el encabezado de la página, por este medio se carga el API de Google y el JQuery 3. Permita subir archivos, se deben habilitar los permisos a los usuarios de hacerlo, ya que por defecto no lo permite 4. Permita la creación de formularios Web y el envío de parámetros por el método POST (Para evitar se vean los parámetros en la URL) a la misma página u otra para la ejecución de la página III-D3. Interfaces de las aplicaciones: Las interfaces de las aplicaciones varían de acuerdo a cada una de ellas, sin embargo de recomienda tener en cuenta: 1. Tener dos campos para ingresar las entradas, uno para que el usuario la suba desde un archivo y otra para que seleccione una predefinida 2. Realizar el proceso de validación de datos para evitar que un usuario pueda romper el sistema especificando parámetros en los cuales la aplicación se ejecuta eternamente Se recomienda dividir o tabular la información de la salida de tal forma que sea de fácil lectura. La idea es no sobrecargar al usuario con información si no presentarla de una forma agradable e intuitiva, es decir que se pueda entender fácilmente que significa cada cosa. También es muy útil cuando es posible presentar la información en tablas utilizando funciones para paginado, ordenamiento, filtrado y búsqueda en las mismas y gráficas para hacer más agradable la presentación de la información. La estética también cuenta para garantizar una buena experiencia para el usuario. IV. ANÁLISIS Y RESULTADOS Al utilizar la metodología propuesta en éste trabajo a los tres trabajos de programación por restricciones, se encuentra que es posible aplicarla de forma genérica para los trabajos futuros que se realicen utilizando éste paradigma, sin embargo como cada trabajo tiene sus propias particularidades, es posible que no se pueda aplicar parte de la metodología para permitir sea utilizado desde la Internet, como fue el caso del secuenciamiento de aviones donde la entrada no se pudo codificar como XML debido a su estructura y la imposibilidad de representar la información utilizando éste formato. Una vez fueron integradas ambas aplicaciones al portal, se realizaron pruebas de caja negra, donde se especificaban

9 las entradas, se establecían los parámetros y se observaban los resultados, utilizando los registros del servidor de PHP y Apache, se observa un funcionamiento sin errores, sin embargo faltan realizar pruebas de estrés y carga de usuarios utilizando la aplicación, por lo que en el momento no se puede asegurar que la aplicación funcione correctamente con cierto número de usuarios concurrentes accediendo a una misma aplicación, ya que para ello se debe estudiar si el motor de Oz tiene soporte para ejecutar varias instancias de la misma aplicación al mismo tiempo. Como resultado, se observa que efectivamente, es posible conectar una aplicación de escritorio de programación por restricciones, sin importar cual fue la plataforma en la que fue desarrollada (OZ, Gecode, etc), sistema operativo donde se encuentra o dependencias de librerías; en un portal Web en el que se especifican las entradas, parámetros de ejecución y se visualizan las salidas. La facilidad proporcionada al utilizar el formato XML para especificar las entradas y salidas es que ya existen funciones y métodos para la lectura de las mismas, por ejemplo en PHP existen muchos paquetes que lo hacen, en este proyecto se ha utilizado SimpleXML para ello. V. CONCLUSIONES 1. La especificación de la salida en formato XML, facilita en gran medida el proceso de convertir en Servicio Web una aplicación de programación por restricciones, ya que ésta debe ser desplegada al usuario y ya existe un gran número de herramientas para hacerlo que no se deben construir. Sin embargo especificar algunas entradas o salidas utilizando formato XML, puede ser complicado y se podría perder información al realizar éste proceso. 2. El uso de gestores de contenido, evita tener que realizar el proceso de conexión a base de datos, gestión de usuarios, gestión de roles de usuario, especificación de temas y formatos del sitio, entre otros, lo que permite concentrarse en construir la aplicación e ingresar la información del proyecto en especifico, lo que deriva en una gran ganancia de tiempo. pero se debe tener en cuenta que requieren tiempo para entender su funcionamiento y funciones. Cuando se cambia de versión de éstos es posible que algunas cosas queden fuera de funcionamiento, por lo tanto no es recomendable actualizar los módulos del portal sin estudiar muy detenidamente que cambia entre las versiones. 3. El uso de librerías minimalistas como es el caso de JQuery y Google API, permite integrarlas fácilmente a la aplicación a diferencia de librerías que aportan la interfaz como es el caso de ExtJS las cuales no se pueden integrar al portal Web. Sin embargo las librerías minimalistas tienen funciones limitadas, aunque algunas de ellas lo solventan al ser de libre uso y código abierto, existen una multitud de plugins desarrollados por su comunidad de usuarios que proporcionan buenas soluciones a problemas que se presenten en el camino 4. La metodología propuesta demuestra ser apropiada para un gran número de problemas de programación por restricciones sin embargo en algunos casos no es posible aplicarla en su totalidad, como lo fue en el caso de secuenciamiento de aviones donde por la estructura de la entrada no fue posible codificarla en formato XML. 5. CREAR demostró ser un ejemplo de una aplicación Web de programación por restricciones, en la cual se utilizaron herramientas como ExtJS para la creación de interfaz que impidieron su expansión e integración con otros proyectos, por lo que la selección de las herramientas con que se aplicar la metodología es vital para garantizar escalabilidad. VI. TRABAJO FUTURO 1. El diseño e implementación del portal de aplicaciones de programación por restricciones para aplicaciones móviles, tomando en cuenta las limitaciones de los dispositivos móviles y las implicaciones de interactividad con el usuario. 2. Se debe estandarizar usar el formato institucional de la Universidad del Valle integrado con el gestor de contenidos para que el portal quede acorde a las políticas de la universidad. 3. Crear un módulo en el portal Web para la creación de las entradas en formato XML a partir del ingreso de los datos del problema. 4. Modificar y realizar las pruebas de carga y estrés sobre las aplicaciones para medir cuantos usuarios concurrentes con carga promedio puede soportar al mismo tiempo. 5. Implementar un módulo que permita la creación de los formularios de entrada de las aplicaciones, especificando los parámetros de entrada, ubicación de archivos y forma de ejecutar la aplicación de forma automática. 6. Establecer un procedimiento para la validación de datos y así evitar posibles problemas por paso de parámetros erróneos. REFERENCIAS [1] J. A. Aranda, J. F. Díaz, and J. J. Ortíz, Crear: Consejero para la repartición de artículos y evaluadores en eventos académicos, Universidad del Valle, [2] J. F. Díaz and J. Maldonado, Prototipo para la minimización de costos en cadenas de abastecimiento usando programación por restricciones, Ph.D. dissertation, Universidad del Valle. Facultad de Ingeniería, [3] J. F. Díaz and A. A. Villegas, Mejoramiento del servicio de una red de comunicaciones móviles usando programación por restricciones en mozart, Ph.D. dissertation, Universidad del Valle. Facultad de Ingeniería, [4] M. Morara, J. Mauro, and M. Gabbrielli, Solving xcsp problems by using gecode, University of Bologna, [5] O. C. of the Third International Competition of CSP Solvers, xml representation of constraint networks: Format xcsp 2.1, Third International Competition of CSP Solvers, January [6] J. F. Díaz and J. A. Mena, Solución al problema de secuenciamiento de aviones en mozart, Ph.D. dissertation, Universidad del Valle. Facultad de Ingeniería, [7] Y. S. J.E. Beasley, M. Krishnamoorthy, heduling aircraft landings - the static case, Parallel Processing Institute, Fudan University, vol. 34, [8] Y. S. D. A. J.E. Beasley, M. Krishnamoorthy, the displacement problem and dynamically scheduling aircraft landings, The Management School,Imperial College, 2000.