Trabajo no presencial: Implementación de un servicio de búsqueda de información sobre monumentos de Zaragoza

Transcripción

1 Trabajo no presencial: Implementación de un servicio de búsqueda de información sobre monumentos de Zaragoza Programación de Sistemas Concurrentes y Distribuidos Grado de Ingeniería Informática Escuela de Ingeniería y Arquitectura Universidad de Zaragoza 15 de diciembre de Objetivos Los objetivos de este trabajo no presencial son los siguientes: Desarrollar una aplicación distribuida cliente/servidor. Profundizar en el modelo de comunicación síncrona para procesos distribuidos. Asentar los conocimientos adquiridos para la programación de aplicaciones distribuidas en C++. Acceder desde programa a información disponible en internet Trabajar en equipo. 2. Descripción del sistema El Ayuntamiento de Zaragoza se ha adherido a la Carta Internacional de Datos Abiertos 1 por la que, entre otras cosas, publica en abierto muchos de los datos relacionados con la ciudad, su gestión, su patrimonio, etc., de manera que entidades tanto públicas como privadas puedan explotar dichos datos. En este trabajo vamos a utilizar algunos de los datos publicados referentes con el patrimonio y el arte público de la ciudad. En la página zaragoza.es/ciudad/risp/detalle_risp?id=13 hay una enlace a un listado, en formato json, de un catálogo de 385 monumentos, del que se muestran los dos primeros en el Anexo I. Para cada monumento, además de otra información, contiene sus coordenadas geográficas (en formato UTM), el título dado al monumento, y un enlace (etiqueta link ) a una página web (está en formato html ) con más información adicional sobre el monumento, fotos, etc

2 Programación de Sistemas Concurrentes y Distribuidos, curso El trabajo debe desarrollar un sistema cliente servidor en el que los clientes solicitan al servidor información sobre los monumentos de Zaragoza. Para darle un valor añadido a este servicio, también vamos a utilizar los datos abiertos que ofrece el Ayuntamiento sobre los restaurantes de la ciudad. Estos datos están disponibles en la página detalle_risp?id=285 también en formato json. Para cada restaurante, entre otras informaciones, se especifica su localización geográfica, también en formato UTM. Estas coordenadas las utilizaremos para, dado un monumento de interés para el cliente, obtener información de los restaurantes más próximos. Por último, el servidor facturará al cliente un precio adecuado por sus servicios de información. 3. El punto de vista del cliente Cada cliente, que tiene un identificador único, se conecta con el servicio, y realiza sucesivas peticiones de servicio, hasta que decide terminar la sesión. En cada petición suministra al servidor un conjunto de entre uno y cinco términos referentes a un monumento del catálogo. Estos términos pueden referirse al título, a la descripción, autor, etc. (análogo a lo que pondríamos en un buscador para encontrar información sobre el monumento). Como resultado de la petición el servicio le hace llegar una respuesta que puede ser de tres tipos: o bien un mensaje de denegación de servicio si no puede atenderlo, un mensaje con Nada encontrado si no ha encontrado ningún monumento, o bien un mensaje con las URLs de la información adicional de los monumentos que el sistema considera más adecuados según la petición enviada al servidor (no más de 5), ordenados por el índice de proximidad. En los dos primeros casos el programa cliente muestra por la salida estándar el mensaje; en el tercero, además de mostrar la información recibida de cada monumento (URL a la página de información adicional), abre un navegador con una solapa por cada uno de los enlaces devueltos, donde los muestra. Después, el cliente podrá solicitar información sobre el restaurante más cercano a uno de los monumentos recibidos como respuesta. El servidor devolverá las coordenadas del restaurante más próximo al monumento. El cliente abrirá una ventana en el navegador con el restaurante, de manera análoga al caso anterior. Una vez que el cliente envía el mensaje de fin de sesión se queda a la espera de que el servidor le envíe otro mensaje con el precio final (precio fijado con un modelo de costes que debe definir el grupo de desarrollo, y que debe estar definido atendiendo a parámetros de sentido común ). 4. El punto de vista del servicio En el momento de iniciar su ejecución, debe cargar en una estructura de datos la información del fichero de monumentos y en otra la información de los restaurantes. Ambos ficheros deben ser descargados y procesados en el momento de inicio de la ejecución desde su URL original. Cada vez que un cliente abra una sesión, el servicio generará un thread específico para atenderlo (lo denominamos representante del cliente, pues es quien se va a encargar de

3 Programación de Sistemas Concurrentes y Distribuidos, curso interaccionar con él). El representante da de alta al cliente en la estructura de datos que utilice el servicio para almacenar su información durante la sesión, de cara a facturar por los servicios. Por otro lado, el representante atiende las peticiones de su representado y, cuando se despida, gestiona el precio, lo da de baja de la estructura y acaba su ejecución. 5. Algunas consideraciones a tener en cuenta 1. Para descargar un fichero desde su URL se puede usar la clase ImageDownloader que se suministró en el ejemplo de uso de opencv para la práctica anterior. 2. El índice de proximidad de un monumento para un conjunto de términos dado debe definirlo el grupo desarrollador. Para ello se deberá mirar tanto el campo title del fichero con el catálogo como la página web asociada con información adicional, a la que se accede desde el campo link. 3. Las coordenadas geográficas de los monumentos y restaurantes proporcionadas en los datos del Ayuntamiento están en formato UTM. Sin embargo, Google Maps requiere que las coordenadas estén en formato latitud longitud. En el material suministrado para la realización del trabajo se incluye un pequeño programa de ejemplo de tansformación entre coordenadas UTM y coordenadas geográficas, cuyas funciones pueden ser usadas. 4. La política de precios del servicio debe ser definida por los desarrolladores, aplicando criterios de sentido común. 5. En general, el enunciado deja bastantes cuestiones abiertas que deberán ser concretadas por cada equipo de desarrollo y debidamente justificadas en la documentación de diseño del proyecto. 6. Para abrir un mapa en google centrado en un punto de coordenadas geográficas latitud longitud, basta con pegarlas a Así, la URL muestra la EINA, que tiene latitud (norte, por ponerlo en positivo) y longitud (oeste, por ponerlo en negativo) 7. Cualquier comando que pueda ejecutarse desde una terminal puede ejecutarse desde un programa en C++ mediante la instrucción system (ver manual de referencia del lenguaje). 8. Para el desarrollo del trabajo se podrán utilizar las clases disponibles en la Standard Template Library (STL) de C++, así como las desarrolladas en la asignatura de estructuras de datos y algoritmos. 9. Es necesario que el servicio termine de una manera ordenada: en un momento determinado, el gestor del sistema le hace llegar una orden de terminación. A partir de ese momento ya no se aceptan nuevas peticiones de clientes, el sistema espera a que se terminen todas las transacción con

4 Programación de Sistemas Concurrentes y Distribuidos, curso clientes en curso y termina, mostrando un pequeño informe, por la salida estándar, del número de transacciones realizada, el total facturado, etc. 6. Instrucciones para el desarrollo y la entrega del trabajo 6.1. Organización inicial del trabajo El trabajo tiene una naturaleza no presencial. Inicialmente, los alumnos se organizarán en tríos, obligatoriamente (los propios alumnos serán responsable de formar estos tríos). Una vez formado, se deberá enviar un correo a alvaper@unizar.es con el asunto [PSCD] Equipo de trabajo TP6 en el que se comunique quiénes son los componentes del trío. Para cada componente concreto se deberá especificar su NIP y nombre completo con los dos apellidos. Esta información es indispensable y debe ser completa. Cada trío deberá programar una aplicación distribuida conforme las pautas de implementación descritas en las secciones previas. La fecha límite para enviar la composición de cada equipo de trabajo es el 22 de Diciembre del 2016 a las 23:59 horas. Aquellos tríos que no comuniquen su composición antes de esta fecha no serán evaluados. No se admitirán trabajos realizados individualmente o en pareja. Si algún alumno no encuentra compañeros de trabajo después de un tiempo razonable, deberá ponerse en contacto con el profesor (antes de la fecha límite de composición de equipos de trabajo) y éste le asignará a algún equipo. No obstante, esta solución será de carácter excepcional Ficheros a entregar como resultado Cuando se finalice el trabajo los alumnos deberán entregar un fichero comprimido trabajonp NIP1 NIP2 NIP3.zip (donde NIP1, NIP2 y NIP3 sean el NIP de los tres autores del trabajo) con el siguiente contenido: 1. Un fichero de texto denominado autores.txt que contendrá el NIP, los apellidos y el nombre de los tres autores del trabajo en las primeras líneas del fichero. Por ejemplo: NIP Apellidos Nombre Rodríguez Quintela Sabela Hernández Castillo Luis Rúiz Palomares Sara Además, el fichero deberá contener obligatoriamente un informe de dedicación. Este informe debe recoger las horas que cada alumno del trío ha dedicado a la realización del trabajo. En concreto, es importante que aparezca el número de horas totales por alumno y un desglose más detallado de días trabajados y número de horas dedicadas en esos días concretos, así como de las tareas a las que se ha dedicado el tiempo: análisis, diseño, implementación, test, etc. Esta información no será utilizada para evaluar el trabajo de los alumnos (es decir, no tiene ninguna

5 Programación de Sistemas Concurrentes y Distribuidos, curso influencia directa o indirecta en la nota de los alumnos). Su objetivo es medir el esfuerzo medio que ha costado realizar el trabajo a los alumnos. 2. Un documento pdf, llamado disenio.pdf, donde se explique claramente el diseño de la aplicación. Este documento debe contener como mínimo una descripción detallada de: el diseño interno de los procesos del sistema (una descripción de alto nivel de la lógica de control de los procesos, decisiones relativas a la gestión de errores, estructuras de datos utilizadas, o algoritmos concretos de interés), los protocolos de interacción concretos que han sido implementados (es decir, cuál es el formato de los mensajes, en qué orden se intercambian los mensajes, y cómo se gestionan los posibles errores de interacción), los mecanismos programados para gestionar los aspectos de concurrencia en el servidor, las políticas de precio del servicio y los procesos para facturar a cada cliente, etc. En general, deberán estar debidamente justificadas todas aquellas decisiones de diseño que hayan sido adoptadas durante el desarrollo del sistema. 3. Un documento pdf, llamado pruebas.pdf, donde se expliquen claramente las pruebas que han sido realizadas para comprobar el correcto funcionamiento de la aplicación. Este documento es un compromiso de garantía de funcionamiento del sistema, y debe contener una descripción detallada de: el método seguido para la fase de pruebas, las pruebas concretas realizadas, los resultados obtenidos y, si procede, las acciones correctivas programadas para su resolución. 4. Un directorio denominado src, que contendrá los ficheros fuente C++ utilizados en la implementación del trabajo. 5. Un directorio bin, que contendrá todos los ficheros resultantes de la compilación de los fuentes en src. 6. Un fichero Makefile para la compilación y limpieza. 7. Los siguientes scripts: lanza servidor.sh: requiere como parámetro un puerto donde estará escuchando a la espera de clientes. Lanza el proceso servidor. lanza clientes.sh: requiere como parámetros una IP y un puerto correspondientes al servicio. Abre tres terminales distintas, cada una con un cliente con un identificador distinto (el desarrollador determina cómo es un identificador). Es de ayuda para esta parte mirar la documentación de la instrucción (unix/linux) xterm -e. Es importante seguir las convenciones de nombrado y la estructura de ficheros y directorios (src, bin, etc.) descrita Procedimiento y fechas de entrega de la práctica Para la entrega del fichero.zip descrito anteriormente, se utilizará el comando someter en la máquina hendrix01.cps.unizar.es. Los tres alumnos que forman un trío deberán someter individualmente el mismo fichero.zip generado como resultado de su trabajo conjunto. La fecha límite para someter el trabajo es el 10 de Enero del 2017 a las 22:00h.

6 Programación de Sistemas Concurrentes y Distribuidos, curso Procedimiento y recomendaciones para su evaluación El procedimiento de entrega anterior constituye el primer paso para la evaluación de esta actividad. El segundo paso tiene un carácter presencial y para ello se habilitará una sesión especial en el laboratorio de prácticas (Laboratorio 0.01, Edificio Ada Byron). Una vez entregados los trabajos, se publicarán con antelación suficiente las fechas y horas concretas en las que se realizará esta evaluación presencial. Es obligatorio la asistencia de todos los miembros del equipo a la misma. El trabajo debe entregarse en los términos indicados anteriormente, debe funcionar correctamente y no haber sido copiado. En particular, hay que asegurarse de que la práctica funciona correctamente en los ordenadores del laboratorio (vigilar aspectos como los permisos de ejecución, juego de caracteres utilizado en los ficheros, etc.). También es importante someter código limpio. El tratamiento de errores debe ser adecuado, de forma que si se producen debería informarse al usuario del tipo de error producido. Además se considerarán otros aspectos importantes como calidad del diseño del programa, adecuada documentación de los fuentes, correcto formateado de los fuentes, etc. Para el adecuado formateado de los fuentes, es conveniente seguir unas pautas. Hay varias, y es posible que podáis configurar el entorno de desarrollo para cualquiera de ellas. Una posible, sencilla de seguir, es la Google C++ Style Guide, que se puede encontrar en:

7 Programación de Sistemas Concurrentes y Distribuidos, curso Anexo I: parte del catálogo de monumentos { "type": "FeatureCollection", "crs": { "type": "EPSG", "code": } "title": "Arte P\u00fablico", "icon": " "link": " "description": "Ayuntamiento de Zaragoza" "features": [ { "type": "Feature", "geometry": { "type": "Point", "coordinates": [ , ] "title": "A cuantos murieron por la Libertad y la Democracia y postguerra", "link": " "description": "", "category": "", "date": "", "icon": " } { "type": "Feature", "geometry": { "type": "Point", "coordinates": [ , ] "title": "A D. Francisco de Goya", "link": " "description": "", "category": "", "date": "", "icon": " }...