AMZI! PROLOG. Inteligencia Artificial. Componentes básicas. Componentes adicionales. Listener. Componentes y Archivos

Transcripción

1 AMZI! PROLOG Inteligencia Artificial AMZI! PROLOG Proyectos de Cursado 2º cuatrimestre 2004 Amzi! Prolog + Logic Server consiste de componentes básicas para distintas plataformas junto con componentes adicionales que dependen de cada plataforma Resultado: aplicaciones Prolog independientes o embebidas Ia Componentes básicas Logic Server: máquina virtual interpreta código Prolog Logic Server Application Program Interface (API) interface para integrar Prolog y otros entornos Listener/Debugger: consola (?- ) Compilador Linker Runtime Componentes adicionales Language-specific Logic Server APIs - Wrappers sobre LSAPI para C/C++, Java, VB, Delphi. Database support Interface para base de datos externas Internet tools otras... Ia Ia Componentes y Archivos Listener Listener/Debugger *.PRO Código Fuente Compilador Linker *.PLM *.XPL Código Compilado Módulo ensamblado Runtime Ejecución *.PPJ Proyecto Ia Código fuente (ej1.pro) Listener (Consola) Para debugging y corrección de programas Item Listener Opciones para abrir, cerrar la consola, (re)consultar archivos, (des)activar herramienta de debugging 6 1

2 Ejemplo 1 Debugger member(x, [X Xs]). member(x, [Y Ys]):- member(x,ys). length([ ],0). length([x Xs], N):- length(xs, Ns), N is Ns+1. Ia Ia Debugging *.PRO VS *.PLM Predicados para debugging buginit/1 buginit/0 abre un archivo donde volcar información de debugging. bug/1 -?/1: para trazar una meta bugclose/0 cierra el archivo de debugging.... Predicados para logging Openlog/1, writelog/1, nllog/0...?- consult (ej1).?- reconsult.?- consult(ej1)....?- consult(ej1).?- load(ej2). (ej1.pro: código fuente) % OJO! (ej2.plm: código compilado) Ia Ia Interpretado VS Compilado Proyectos (1) *.pro código fuente Se interpretan (dinámicamente) Ejecución + lenta Modificación dinámica de código?- consult (archivopro) Debugger SI *.plm código compilado Código compilado es estático Ejecución + rápida Modificación dinámica de código con restricciones?- load (archivoplm) Debugger NO Los proyectos proporcionan una forma fácil de organizar el desarrollo de aplicaciones que están compuestas por varios archivos y/o librerías Ia Ia

3 Proyectos (2) Archivo XPL: módulo resultante de ensamblar todos los archivos que componen el proyecto Directorio del proyecto Archivos del proyecto: todos los archivos *.pro (o *.plm) que contienen en su conjunto todo el código del programa Archivos incluidos: lista de archivos *.plm que deben incluirse en el proyecto 13 Distribución MiProyecto.xpl amzi.dll MiProyecto.exe: una copia renombrada de arun.exe Cuando Prolog está embebido en otras aplicaciones el *.exe no es necesario Ia Módulos Un módulo es una colección nombrada de predicados. Un módulo puede importar predicados de otros módulos Un módulo puede exportar predicados para que sean usados por otros módulos. Ia Módulos (2) Módulo: User Por default todos los predicados están definidos en un módulo llamado 'user' Todos los predicados en el módulo 'user' son visibles para cualquier otro módulo Módulo: System Todos los predicados pre-definidos están en el módulo especial que es visible por todos los otros módulos Ia Módulos (3) :- module(m1). :- export( [ p/0, q/1] ). :- import( M2 ). p:- r, w. q(x):- t(x), u(x). q(x):- t(y). r:- q(x), s(x). :- end_module(m1). Ia append??- append ( [a,b,c], [1,2,3], L ). no append/3 está definido en list.plm Hay que importar el predicado o el módulo entero?- load ( list ), import( list ). yes?- append ( [a,b,c], [1,2,3], L ). L = [a, b, c, 1, 2, 3] Ia

4 Tipos de predicados Dinámicos: sus cláusulas pueden agregarse o eliminarse dinámicamente Estáticos: son los predicados compilados Pueden coexistir predicados dinámicos y estáticos, pero... Un mismo predicado no puede ser estático y dinámico a la vez Directiva dynamic?- consult(arch1) Todos los predicados definidos en arch1.pro son dinámicos?-load(arch2) Un predicado definido en un arch2.plm puede ser dinámico si se usa la directiva :- dynamic functor/aridad Ia Ia Proyectos En general serán proyectos de programación Inteligencia Artificial Proyectos del cursado 2º cuatrimestre 2004 Se evaluará en cada caso: Funcionamiento de los programas implementados Anda o no anda para casos generales, especiales Diseño, implementación, codificación Originalidad, claridad, correctitud, documentación de código... Informe Estructura, contenido, completitud, utilidad... Ia Funcionamiento de los programas Se considerará en la evaluación: -funcionamiento - las convenciones de representación y denominaciones - la facilidad de uso y testeo - el cumplimiento de los objetivos propuestos en cada proyecto Ia Diseño - Implementación Se considerará en la evaluación: - la calidad y claridad del diseño realizado (cómo se diseña la solución adoptada, ED s, etc ) - la calidad y claridad de la implementación (cómo se implementa el diseño realizado, etc ) Para que tales puntos puedan ser evaluados, deberán ser documentados en forma adecuada (ver obs. sobre informe y documentación de código) Ia

5 Informe (1) Informe (2) Puede organizarse de muchas maneras pero debe tener alguna estructura u organización interna que favorezca la lectura y el entendimiento de aquello que se quiere expresar. Algunas características de un buen informe: - Buena presentación/organización/prolijidad - Completitud / Utilidad - Buena redacción / O R T O G R A F Í A - Claridad en la expresión de conceptos Ia Algunos elementos de un informe: Título Introducción Planteo del problema Análisis / diseño / elección de soluciones Análisis/explicación de la solución implementada Convenciones adoptadas Restricciones de representación/uso Instrucciones/ejemplos de uso Conclusiones /Observaciones finales Ia Documentación del código (1) Documentación del código (2) % obtenerancenstros(+n,-la): dado N, obtiene en % LA la lista de ancestros de N obtenerancenstro(+n,-la):-... obtenerancenstro(+n,-la): El comentario NO DICE NADA que no pueda inferirse desde el nombre del predicado y sus argumentos - Ese solo comentario no alcanza. - Sin ninguna otra aclaración el comentario NO SIRVE. La documentación debe ayudar a entender el significado pretendido de cada parte del programa... entender cómo se implementa cada parte de la solución propuesta... entender el funcionamiento y a encontrar posibles causas de errores.... mantener/modificar/extender de la implementación realizada - La única forma de entender el predicado es leer/entender/adivinar/probar su implementación Ia errores y ERRORES!!! Quien corrige el proyecto... Un pequeño error puede causar que un programa no funcione Un código BIEN documentado, junto con un informe COMPLETO pueden evidenciar si el mal funcionamiento de un programa es causa de pequeños errores. En un código MAL documentado cualquier error es simplemente un error cuya causa se desconoce pero cuya consecuencia es clara: EL PROGRAMA NO FUNCIONA!!! :(lo siento) Ia no participó en su desarrollo... no tiene por qué saber todos los detalles... no puede adivinar lo que no se dice... no tiene por qué modificar el código fuente para poder probar el programa... etc. CONSEJO: ponerse en lugar de quien corrige el proyecto Ia