[Pfc-prolog-cvs] prolix-doc/pfc-es/conclusiones conclusiones.tex,1.2,1.3
Status: Beta
Brought to you by:
ivanfrade
From: <iva...@us...> - 2003-09-05 16:29:07
|
Update of /cvsroot/pfc-prolog/prolix-doc/pfc-es/conclusiones In directory sc8-pr-cvs1:/tmp/cvs-serv7200 Modified Files: conclusiones.tex Log Message: Completadas conclusiones Index: conclusiones.tex =================================================================== RCS file: /cvsroot/pfc-prolog/prolix-doc/pfc-es/conclusiones/conclusiones.tex,v retrieving revision 1.2 retrieving revision 1.3 diff -C2 -d -r1.2 -r1.3 *** conclusiones.tex 4 Sep 2003 20:31:02 -0000 1.2 --- conclusiones.tex 5 Sep 2003 16:29:03 -0000 1.3 *************** *** 1,4 **** ! \section{Conclusiones generales} \section{Conclusiones sobre las herramientas} ! \section{Conclusiones sobre la metodologia} ! \section{Posibles mejoras} \ No newline at end of file --- 1,78 ---- ! Siendo coherentes con la filosofía de desarrollo del proyecto, estas no son las conclusiones de un trabajo terminado cuyo proceso de evolución ha concluido, sino las de un desarrollador que, después de comenzar y elaborar las bases de ese proyecto, espera poder continuar trabajando en él con la ayuda de otros usuarios y programadores, una vez liberado de su categoría de Proyecto Fin de Carrera, para pasar a ser un proyecto de Software Libre. ! ! El proyecto realizado se puede considerar una base lo suficientemente sólida como para empezar a utilizarse en un entorno real, y con una estructura fácilmente adaptable y ampliable a nuevas necesidades. El objetivo inicial de obtener una aplicación de uso real ha sido lograda, y ahora los alumnos dispondrán de una herramienta que facilite su aprendizaje de Prolog. ! ! \section{Conclusiones a la metodología} ! ! El sistema no se elaboró siguiendo el esquema habitual de desarrollo, sino en fases o iteraciones. La principal ventaja obtenida fue el dosificar el aprendizaje de nuevas tecnologías en un proceso continuo, en función de la demanda, ahorrando un tiempo de aprendizaje previo donde las tecnologías estudiadas luego pueden resultar innecesarias, o las necesarias no haberse dominado con el nivel de detalle suficiente. Valga como experiencia el estudio previo del desarrollador del proyecto sobre XML, que resulto inadecuado a las necesidades reales: es difícil conocer qué se va a necesitar. ! ! La planificación y el crecimiento del programa se produjo de forma natural añadiendo las funcionalidades deseadas, en función de lo que en cada momento se creía más necesario o accesible. El precio a pagar por ello consiste en un cierto trabajo extra rediseñando código (<<refactorizando>>) que provoca (y aquí usamos la expresión de \cite{beck-XP}) <<miedo>> en el programador, pues debe modificar partes del programa que estaban funcionando bien. Sin embargo considero que la satisfacción de realizar esos cambios resulta muy motivadora para el informático como programador. ! ! La continua revisión del código del programa produce una mayor seguridad del programador, y una mejora de la calidad de ese código. Lo cual combinado con herramientas que permiten mantener la seguridad de tener una copia <<que funciona>> producen un software más consistente. ! ! Una percepción personal después de desarrollar el proyecto, es la mayor apreciación de la programación. Después de estudiar una ingeniería, donde se adquieren los conocimientos necesarios para desarrollar una labor a otro nivel, menos centrada en el teclado y más proximal al estudio teórico, resulta difícil enfrascarse en la tarea de teclear y compilar un programa. Sin embargo resultó un trabajo interesante y motivador, pues a menudo se olvida el reto intelectual que supone escribir código. Y aún más el de escribir buen código. ! \section{Conclusiones sobre las herramientas} ! ! Sin duda los tres elementos más importantes en el desarrollo de este proyecto fueron la herramienta de compilación \texttt{Ant}, el sistema de control de versiones, \texttt{CVS}, y el generador de código \texttt{XDoclet}. ! ! Por su genericidad no le dedicamos un apartado al lenguaje Java y sus librerías, pero debemos reseñar que su coherencia y su forma de trabajo contagian un estilo de programación ordenado y consistente. El uso de una biblioteca de funciones con un funcionamiento determinado (pensando, por ejemplo, en solicitar un objeto y trabajar con él directamente, no a través de quien nos lo cede) da una idea de lo que es diseño elegante, útil y reaprovechable. ! ! \subsection{Herramienta de compilación \texttt{Ant}} ! ! La facilidad de uso y la potencia para automatizar tareas agilizó el proceso de desarrollo de forma insospechada. Trabajando con java es muy fácil encontrarse con <<CLASSPATH>> muy grandes, cuando se desarrolla el programa en distintos terminales hay que mantener esa variable coherente, o como ocurría en el caso de este proyecto, el programa no puede probarse compilando simplemente, sino que es necesario empaquetarlo de una determinada manera y copiarlo a un sitio concreto. ! ! Todos estos problemas quedan resueltos con \texttt{Ant}. Inicialmente se pierde lo que parece demasiado tiempo configurando su \texttt{buildfile}, retocando tareas, dependencias (fue uno de los ficheros más modificados, como atestigua el CVS), y añadiendo funcionalidades necesarias. Sin embargo después de dominar unas cuantas tareas básicas (ayudados por una documentación envidiable), es rápido y sencillo realizar estas correcciones, y compensa con creces el esfuerzo pensando en el tiempo ahorrado posteriormente. ! ! Usando Ant pudo reducirse a la ejecución de un comando el compilar y desplegar el proyecto, el subir ficheros de back-up a la web del proyecto, o el realizar las operaciones para obtener ficheros para un <<release>>. ! ! \subsection{Sistema de control de versiones CVS} ! ! Esta herramienta, una vez que se comienza a utilizar resulta ya indispensable para el programador. Debemos reseñar con entusiasmo la seguridad que aporta al mantener un historial de cambios, y darnos la posibilidad de probar esos cambios sin perder la versión anterior, fácilmente recuperable. ! ! Cuando como en este caso además el CVS esta en otra máquina, en Internet, podemos además despreocuparnos de un fallo de nuestro ordenador, que podría ser catastrófico sin el uso de esta tecnología. ! ! Su manejo resulta muy sencillo, pues se puede empezar con las características más básicas (actualizar cambios, añadir cambios), y luego según surgen necesidades aprender nuevos comandos y características. ! ! También resulta una herramienta importantísima para permitir el trabajo coordinado desde diferentes puntos, como sucedió en este proyecto (por motivos laborales). ! ! \subsection{Generador de código \texttt{XDoclet}} ! ! Esta es otra de las piezas vitales del sistema. Como en las anteriores, los primeros pasos manejándola son un tanto difíciles, pero los resultados y el aumento de productividad que se puede obtener de su manejo hacen merecer de sobra los problemas iniciales. Puedo decir que desarrollando aplicaciones con EJB su uso resulta \emph{esencial}, pues por un poco que crezca la complejidad del programa nos encontramos con una cantidad de código que debe ser <<consistente>> muy difícil de mantener sin herramientas automáticas, añadiendo también una tediosa labor de compilación con mensajes poco descriptivos. ! ! La documentación disponible (instalada localmente al bajar sus ficheros) es muy buena en explicaciones, con ejemplos para los puntos esenciales. Puede generar código para varios contenedores del J2EE, y todos los ficheros de configuración necesarios se generan, al igual que el código de forma automática. ! ! \subsection{Otras herramientas} ! ! El editor XEmacs también ha sido una gran ayuda para el desarrollo de este proyecto, y es un programa que considero fundamental manejar para cualquier programador. Como simple editor permite moverse por el texto y realizar los cambios más habituales de forma rápida, y además dispone de numerosas ayudas para el programador. Esto, junto con la potencia del modo consola (especialmente en los sistemas Unix), suplen sobradamente un Entorno de Desarrollo Integrado (IDE). ! ! Deberíamos también recomendar phpMyAdmin, especialmente si los conocimientos del programados sobre SQL son básicos. Permite manejar la base de datos de forma intuitiva, traducido al español, y con abundante documentación. ! ! Otras herramientas utilizadas y cuya evolución no debemos perder de vista son <<argoUML>> y <<Umbrello>> como herramientas CASE de diseño con UML. Los diagramas de clases se han elaborado con <<Umbrello>>. Esta en un proceso de desarrollo temprano, pero es capaz de generar código, y es mucho más flexible que la Rational Rose, por lo que las características de las que no dispone (definir interfaces, por ejemplo) se pueden simular. Resulta muy facil mandar informes de errores desde el mismo programa y por experiencia propia podemos garantizar que se reciben y contestan. <<argoUML>> se utilizó al principio del problema, pero aún tenia fallos importantes, dando problemas bastante graves, como la corrupción de ficheros. ! ! Los demás diagramas que aparecen en esta documentación, se elaboraron con <<Dia>>, el programa de diagramas de Gnome. Resulta muy fácil de utilizar, tiene una paleta de símbolos a utilizar muy variada (para multitud de lenguajes, incluido UML, o STEP), y puede exportar gráficos a numerosos formatos. Además es posib le especificar que guarde los ficheros sin comprimir, siendo estos texto plano que se puede subir al CVS. ! ! Todas estas herramientas son software libre. ! ! \subsection{\LaTeX} ! ! Por último hablamos de \LaTeX, con el que se ha escrito esta documentación. Su curva de aprendizaje es muy pronunciada. Los primeros encuentros con esta forma de escribir documentos resultan un tanto frustrantes, quizá por el cambio de forma de pensar y escribir respecto a los métodos tradicionales. Sin embargo, según crece el documento se va justificando su elección. ! ! La inclusión de imágenes que parecía uno de los temas más espinosos resultó más fácil de lo esperado utilizando el formato .eps, al que exportan casi todos los programas utilizados, o al que es posible convertir gráficos en otros formatos (como png). ! ! El uso de paquetes especiales como pst-uml permitieron introducir los diagramas de casos de uso y escenarios sin recurrir a herramientas externas, aunque si que se utilizaron algunas, como lgrind para formatear código fuente e introducirlo en la documentación. En ese sentido es muy remarcable la facilidad de \LaTeX para importar ficheros. Con un script muy sencillo se generaron ficheros .tex con el código de aquellos ficheros del proyecto cuyo lenguaje no era java (jsp y xml), que se puede incluir en el documento maestro y pasan a numerarse y colocarse en el tomo con una tipografía y estilo similar al resto. ! ! Y por supuesto, al tratarse de ficheros en texto plano, pudo mantenerse la documentación en el CVS. ! ! \section{Posibles mejoras} ! ! Acabamos estas conclusiones proponiendo algunas mejoras al proyecto. Resulta importante poner en marcha en un entorno real la aplicación, pues la información recabada por el uso habitual podría considerarse una mejora en si, y una forma de afinar estas sugerencias: ! ! \begin{itemize} ! \item \textbf{Sistema de logs}. Utilizando el sistema de log del jBoss, mantener unos registros del sistema que permitan monitorizar algunas estadísticas como número de visitas por usuario, uso de la biblioteca, consultas por sesión. ! \item \textbf{Desarrollo de diferentes clientes}. Hay desarrollado uno en modo consola un tanto rústico, pero seria interesante poder realizar uno en Gtk o en las bibliotecas gráficas de windows. Esta mejora no implicaría modificación del código en funcionamiento. ! \item \textbf{Comentarios a los programas}. Quizá los usuarios podrían añadir comentarios a los programas de la biblioteca, haciendo sugerencias o preguntas al autor. ! \item \textbf{Utilización del e-mail}. Podrían encontrarse utilidades a disponer de la dirección de correo electrónico del usuario, como poder mandarse un programa a su correo, o notificarle el añadido de un comentario (ver punto anterior). ! \item \textbf{Integración de un foro}. Que pueda servir de punto de reunión a los usuarios de la aplicación, como sitio de consulta sobre Prolog, \dotx ! \item \textbf{Bibliografía y enlaces recomendados}. Mantener información a sitios interesantes referidos a la programación lógica y a Prolog. ! \end{itemize} \ No newline at end of file |