Técnicas Avanzadas en Ingeniería Informatica (I)
Curso 2009-2010
1. Fecha de entrega
La fecha límite de entrega será el 26 de Abril (Lunes) hasta las 20:00 horas.
2. Planificación de rutas turísticas urbanas
El principal objetivo de esta práctica consiste en la realización de un programa en PROLOG que permita la integración de sentencias basadas en lógica proposicional sobre una aplicación que permita realizar guías turísticas a través de una ciudad. El sistema Prolog representará parte del callejero de Madrid (o cualquier otra ciudad que se considere oportuna), de tal forma que el usuario pueda realizar una serie de consultas expresadas en un lenguaje lógico.
Cualquier callejero puede definirse en base a dos elementos fundamentales, calles e intersecciones o cruces, a estos últimos se le incluirá los puntos de interés (e.g. museos, monumentos, parques y jardines, etc…) que deberán ser representados como parte del callejero. Dada la complejidad actual de cada uno de los elementos anteriores, se pide modelizar y representar parcialmente un callejero con la información turística adecuada. Se recomienda consultar alguno de los siguientes web sites para hacerse una idea inicial de la información a representar:
• http://www.turismomadrid.es/ESPA/MTUR/pagina/MTURCallejero_vtm.shtml
• http://www.turismomadrid.es/ESPA/CMAD/pagina/CMAD.shtml
• http://www.esmadrid.com/monograficos/visita/es/monografico.html
Fig 1. Detalle de la zona centro de Madrid con los Museos destacados
2.1 Modelado del callejero e información de interés turístico
Utilizando una representación adecuada de una parte del callejero de el área metropolitana de Madrid, así como de aquellos parámetros que se consideren necesarios, se pide implementar los siguientes predicados:
1. Representar en Prolog la sección del área metropolitana considerada intentando optimizar esa representación, evitando redundancias. Debe incluirse en el modelo la posibilidad de indicar tiempos de desplazamiento o conexiones entre calles. Se valorará de forma positiva aquellos modelos que permitan una representación enriquecida del callejero (por ejemplo, horario de visita de los sitios a visitar, accesibilidad de los sitios de interés turístico, tiempos medio de desplazamiento en función del medio empleado: caminando, transporte urbano, taxi, etc…). El modelo debe recoger el estado actual del área metropolitana considerada. Se debe modelar un mínimo de 10 calles que contengan sitios de interés.
2. Implementar las reglas que posteriormente puedan ser empleadas por los usuarios al plantear las sistema consultas del tipo:
rutas_mas_cortas(origen, destino, tiempo_maximo).
ruta_optima(origen, destino, Tiempo).
ruta_turistica(origen, destino, [lista_interés], Tiempo).
ruta_turistica_optima(origen, destino, [lista_interés],Tiempo).
El programa deberá ser capaz de buscar las rutas más cortas, es decir, las que menor duración de trayecto supongan. El primer predicado debe ser capaz de encontrar todas las rutas entre un origen y un destino preestablecido que supongan un tiempo de recorrido inferior a tiempo_máximo. El segundo predicado debe encontrar aquella ruta que requiera el menor tiempo de trayecto posible. Los predicados tercero y cuarto funcionan de forma análoga a los anteriores pero considerando una lista de sitios de interés por los que debe pasar la ruta considerada, en el caso del tercer predicado (ruta_turística), la variable Tiempo se utilizará para devolver el tiempo empleado en recorrer la lista de sitios de interés (o si se pasase instanciado para saber si es posible hacer la ruta en el tiempo considerado), en el caso del cuarto predicado la variable Tiempo se utilizará para devolver el tiempo mínimo necesario para recorrer los sitios.
Para realizar los puntos 1 y 2 deberán tenerse en cuenta las siguientes circunstancias:
• Una calle podrá ser dividida en tantas secciones o tramos como se consideren necesarios. Cada una de estas secciones tendrá un tiempo predefinido, en minutos, que indicará (por defecto) el tiempo de su recorrido a pie.
• Podrá establecerse un tiempo variable para “visitar” cada uno de los sitios de interés considerados
• El tiempo total para recorrer una calle será la suma de los tiempos necesarios en recorrer tramos.
• El tiempo total de una ruta guiada será la suma del recorrido establecido más el tiempo dedicado a realizar las visitas oportunas.
• No se deben producir ciclos en los recorridos.
Sugerencias:
• Se deben detectar o ignorar casos absurdos como la consulta:
rutas_mas_cortas(gran_via_secc1, gran_via_secc1).
• Se deben detectar los bucles en los recorridos, para evitar que el programa entre en una búsqueda recursiva de la que no pueda salir.
• Se debe prestar especial atención a los cortes. Hay predicados que requieren un corte para evitar que se produzcan resultados redundantes. La falta de cortes es el motivo más frecuente de que se repitan caminos idénticos en una búsqueda.
• Prolog permite definir reglas generales y algunas excepciones de forma sencilla. Debe tenerse en cuenta a la hora de definir las duraciones de tramos y transbordos.
Fig 2. Representación de una posible ruta turística en el centro de Madrid
2.2 Ampliaciones (Opcional)
Para mejorar la flexibilidad de las reglas anteriores, y adecuar el modelo más a la realidad, se proponen realizar las siguientes ampliaciones del modelo:
• Ampliar los predicados para admitir consultas del tipo:
o ¿A qué sitios de interés puedo llegar desde A en menos de t minutos?
sitios_accesibles(inicio, final, t_maximo).
• Incluir predicados adicionales que permitan al usuario incluir en la base de hechos sitios de interés que por motivo de huelgas, problemas técnicos u obras no estén operativos, también puede extenderse a la representación de una calle o un tramo concreto que pueda estar cerrada por obras y que por lo tanto hubiese de ser evitada en una posible ruta. Los predicados de búsqueda deberán tener en cuenta esta circunstancia y evitar dichos sitios. Intentar representar estos casos con un solo predicado. De cara al usuario puede haber varios predicados que faciliten la introducción de cambios, por ejemplo:
sitio_inoperativo(sitio).
calle_inoperativa(calle).
tramos_inoperativos([lista_tramos]).
borrar_cambios.
Dichos predicados se encargarán de realizar las aserciones necesarias para que la Base de Hechos incluya la nueva información. El predicado borrar_cambios se encargará de eliminar las cláusulas introducidas.
3. Sistema de consultas basado en lógica proposicional
Sobre el sistema de cálculo de rutas anterior se pretende utilizar una descripción basada en lógica clásica para permitir realizar consultas combinadas sobre el sistema de transporte. Para ello se desarrollará una descripción sintáctica de entrada que permita representar fórmulas bien formadas (fbf’s) en lógica proposicional, y que posteriormente serán adaptadas al sistema previamente desarrollado.
3.1 EncuentraAsignación
1. Se pide implementar un predicado llamado encuentraAsignacion (o findAssignment) con tres argumentos:
• El primer argumento será una fórmula lógica.
• El segundo argumento será una lista de asignaciones de valores a las variables como punto de partida. En caso de que no se quiera presuponer ningún valor, será una lista vacía: [ ]
• En el tercer argumento, se devolverá una asignación de valores a las variables que satisfaga la fórmula.
Realizando backtracking, será posible ir recogiendo varias asignaciones.
Aunque se proporciona un código que puede ser modificado, y adaptado, se sugiere una implementación propia del mismo. En particular pensando en la posibilidad de generalizar de Lógica Proposicional a Lógica de Predicados, y teniendo en cuenta las características propias del problema resuelto en el apartado anterior.
En el caso de utilizar el código proporcionado, las fórmulas lógicas se representarán utilizando tres predicados; el predicado not/1, el predicado and/2, el predicado or/2. Utilizando los tres predicados anteriores, es posible representar cualquier fórmula en lógica proposicional. Por ejemplo, dadas las variables x,y,z, la codificación de la fórmula: x ∧(┐y ∨ z), sería: and(x,or(not(y),z)). Ejemplo del predicado findAssignment proporcionado:
2. Se pide modificar el predicado encuentraAsignacion, para permitir la inclusión de la implicación (→) y de la doble implicación (↔).
3. Implementar un predicado en Prolog que dada una fórmula proposicional devuelva si se trata de una tautología, una contradicción o una contingencia. Se pide describir cómo podrían ser utilizados estos conceptos sobre el sistema de transporte urbano definido en el apartado anterior.
3.2 Búsquedas y ejecución de consultas (Opcional)
En este apartado se pide, utilizando el código Prolog desarrollado en los dos anteriores. Se pide crear las reglas correspondientes (en forma de casos de prueba) que permiten representar en lógica proposicional consultas, que podrían expresarse en lenguaje natural, tales como:
• Gran_Vía está conectada con Callao.
• Preciados está conectada con Puerta_del_Sol y con C_Mayor y C_Carretas.
• Preciados está conectada con C_Mayor y C_Carretas pero no con Retiro.
• ¿Cuál es la ruta para llegar de Arenal a Montera?
• ¿Cuales son las rutas para llegar de M_Prado a M_Reina_Sofia?
• ¿Cuál es la ruta más corta entre M_Ejercito y P_Retiro?
• ¿Cuánto tiempo se tarda de Arenal a P_España?
• ¿Cuántos sitios de interés hay entre Goya y Quevedo, y P_Prado, y P_Recoletos?
Fig 3. Representación de una posible ruta entre Gran Vía y Callao
Se pide dar una representación en lógica de las anteriores sentencias en lenguaje natural (y de otras similares), así como implementar los predicados prolog que fuesen necesarios.
• (Opcional) Adaptar el predicado encuentraAsignacion para permitir que la representación anterior de las sentencias en lenguaje natural (basadas sobre las reglas definidas en la sección 2 de la práctica), puedan utilizar esa sintaxis en la representación de las consultas contra el sistema.
4. Entrega de la memoria y del programa
La práctica (tanto el código como la memoria) se entregarán en un fichero comprimido como se indica en la página de la asignatura, y cuyo nombre debe indicar, el número de práctica y el número de grupo del que se trata. Se aceptarán ficheros comprimidos zip, rar, tar.gz, o tgz. Ejemplo:
par05prac1.tar.gz, par06prac1.tgz, par02prac1.zip, par04prac1.rar
La práctica se entregará utilizando la zona de envío de prácticas de la EPS (http://www.ii.uam.es/esp/alumnos/practicas/envio practicas.php3). El código fuente entregado tendrá todo lo necesario para que se pueda ejecutar los diferentes procedimientos, así como los casos de prueba que se consideren necesarios. El código deberá estar adecuadamente comentado.
La memoria constará de las siguientes secciones:
1. Introducción (una hoja de descripción de lo que hay que hacer desde vuestro punto de vista y no copiando el enunciado).
2. Descripción a alto nivel de lo realizado: qué predicados se han definido y porqué, qué problema resuelve cada uno de ellos y cómo se relacionan unos con otros, etc.
3. Código fuente completo con comentarios (el código final no debería ser muy largo)
4. Consideraciones sobre la eficiencia del programa, si es que se han tenido en cuenta cuestiones como el orden de las cláusulas, orden de los objetivos en los cuerpos, cut,…
5. Conclusiones (qué se ha aprendido, dificultades encontradas, comentarios sobre PROLOG, etc).
6. Medida del esfuerzo del desarrollo de la práctica, en este último apartado podrá mostrarse una tabla donde los alumnos indiquen (de forma aproximada) el número de horas dedicadas al desarrollo de la misma. Pueden indicarse los siguientes elementos (u otros que se consideren oportunos): Análisis del problema, Desarrollo del programa, Diseño
5. Criterios de evaluación
Se valorará:
1. La corrección del programa (que funcione en todos los casos) 2. La claridad del código
3. La claridad de las explicaciones en la memoria
4. Las consideraciones que haya hecho el alumno para mejorar la eficiencia (cambiar el orden de los objetivos, etc), si estas están justificadas en la memoria
