X-Git-Url: https://git.llucax.com/z.facultad/75.42/plaqui.git/blobdiff_plain/5798894e5519b029abd9393b9a1bd6a899a683c9..17c51386e9da2d8d694d80ca8dd660bf927fe429:/docs/manual_proyecto.lyx?ds=sidebyside diff --git a/docs/manual_proyecto.lyx b/docs/manual_proyecto.lyx index ea90816..d748d40 100644 --- a/docs/manual_proyecto.lyx +++ b/docs/manual_proyecto.lyx @@ -36,64 +36,244 @@ Manual del Proyecto PlaQui \layout Section -Integrantes: +Integrantes. +\layout Itemize + +Nicolás Dimov (77.624) +\layout Itemize + +Leandro Lucarella (77.891) +\layout Itemize + +Ricardo Markiewicz (78.226) +\layout Section + +Programas de Prueba. \layout Standard -Nicolás Dimov +Los programas de prueba se pueden encontrar en la carpeta +\emph on +tests +\emph default +, allí se almacenaron los primeros ejecutables con los que luego se comenzó + el desarrollo. \layout Standard -Ricardo Markiewicz +Con la ayuda de la herramienta subversion no fue necesario ir guardando + parcialmente el proyecto, ya que subversion guarda en un repositorio todas + las versiones intermedias del proyecto. + Para obtener una versión particular del proyecto basta ejecutar: +\layout LyX-Code + +svn co -r[rev|{fecha}] http://svn.llucax.hn.org/svn/plaqui/ \layout Standard -Leandro Lucarella -\layout Section +Donde +\family typewriter +-r +\family default + toma un parametro que puede ser el número de revisión que se quiere obtener + ( +\family typewriter +rev +\family default +) o una fecha ingresada entre llaves ( +\family typewriter +{fecha} +\family default +). + Por ejemplo para obtener la revisión 1 se puede hacer: +\layout LyX-Code -Programas de Prueba: +svn co -r1 http://svn.llucax.hn.org/svn/plaqui/ \layout Standard -Los programas de prueba se pueden encontrar en /plaqui/test, ahi se almacenaron - los primeros ejecutables con los que luego se comenzó el desarrollo. +Y para obtener la versión de la fecha de la preentrega se puede hacer: +\layout LyX-Code + +svn co -r'{2003-11-20 18:00}' http://svn.llucax.hn.org/svn/plaqui/ \layout Standard -Con la ayuda del repositorio ( Subversion ) no fue demasiado necesario ir - guardando parcialmente el proyecto, ya que este puede ser accedido en cualquier -a de sus versiones en cualquier momento del desarrollo. +Es por esto que nos pareció que no tenía mucho sentido acompañar este manual + con una versión particular del repositorio en un momento dado. \layout Section -Cronograma Real: -\layout Comment +Evolución del proyecto. +\layout Standard -aca va el log !!! -\layout Section +La evolución del proyecto también se documentó a través del subversion, + ya que a cada versión que se sube al servidor se la acompaña de un comentario + sobre los avances realizados. + Para ver el mensaje de cualquier cambio realizado en una revisión +\family typewriter +X +\family default + se puede hacer: +\layout LyX-Code + +svn log -rX http://svn.llucax.hn.org/svn/plaqui/ +\layout Standard -División de Tareas: +Para ver todos los mensajes basta con: +\layout LyX-Code + +svn log -r0:HEAD http://svn.llucax.hn.org/svn/plaqui/ \layout Standard -PlaQui-Server a cargo de Leandro Lucarella. +Por conveniencia, en el directoria raíz del código fuente entregado en el + CD se encuentra un archivo ChangeLog con los mensajes de todas las revisiones + del proyecto. +\layout Section + +División de Tareas. \layout Standard -PlaQui-Model y PlaQui-Client a cargo de Ricardo Markiewicz. +A continuación se menciona, en terminos generales la tarea que realizó cada + integrante: +\layout Description + +Leandro\SpecialChar ~ +Lucarella PlaQui Server. +\layout Description + +Ricardo\SpecialChar ~ +Markiewicz PlaQui Model y PlaQui Client. +\layout Description + +Nicolás\SpecialChar ~ +Dimov PlaQui Constructor. \layout Standard -PlaQui Constructor a cargo de Nicolás Dimov. +Obviamente en algunas circunstancias algún integrante aporto al desarrollo + de un módulo que no le estaba asignado. + La documentación fue realizada y revisada entre todos los integrantes. \layout Section -Inconvenientes Encontrados: +Inconvenientes Encontrados. +\layout Subsection + +Servidor. \layout Standard El servidor termina su ejecución si el XML que se le pasa como argumento no es válido. -\layout Standard +\layout Comment los otros puntos no se como explicarlos (sockets no bloqueantes etc) +\layout Subsection + +Constructor. +\layout Standard + +A lo largo del desarrollo nos hemos encontrado con diferentes tipos de problemas + los cuales pudieron ser solucionados, en su mayoría, de una forma aceptable. + +\layout Standard + +Al tabajar con imágenes independientes, las verificaciones sobre cada una + de estas, dependen mucho de su posición en el área de trabajo y su orientación. + Esto provoca que haya que realizar demasiadas validaciones para los diferentes + tipos de verificaciones, y trae apareados problemas en la codificación + por el uso de gran cantidad de coordenadas. +\layout Standard + +Otro inconveniente no solucionado, fue que las imágenes de cada elemento + que se coloca sobre la grilla se crean tantas veces como elementos de ese + tipo haya. + La idea en un principio fue crear todas estas imágenes estáticas, de modo + que para un elemento de cuatro imágenes, se cargarían en memoria solamente + esas cuatro imágenes y luego los elementos iguales apuntarían su imagen + actual a la que corresponda. + Esto no pudo ser solucionado pués no encontramos la forma de inicializar + las imágenes de manera estática, se producían errores en el momento del + linkeo. +\layout Subsection + +Cliente. +\layout Standard + +El principal problema del cliente fueron las threads. + El asunto fue descubrir la forma de hacer que las actualizaciones de refresco + de las propiedades y la creación dinámica de objetos sea thread-safe para + garantizar a la Gtk+ cierta estabilidad. + Luego de mucho leer se encontro el Glib::Distpatcher, que es un evento + asíncrono especialmente diseñado para comunicación entre hilos. +\layout Subsection + +Modelo. +\layout Standard + +El Modelo tenía la complicación de la Union. + Este elemento es complicado ya que para poder saber el estado a su salida + se necesitaba saber el estado a sus 2 entradas, y esta información llegaba + en forma asíncrona. + Luego de mucho diseño, análisis de todas las combinaciones posibles entre + las entradas se llego a un método que resulto exitoso en la mayoría de + las pruebas y fue adoptado como definivito. +\layout Standard + +Otro inconveniente fue la suma de colores. + El ejemplo dado en el enunciado no era para nada correcto. + Para solucionar esto nos pusimos en contacto con Nicolás Reyna, estudiante + de diseño industrial en la Universidad de La Plata, quien tiene un conocimiento + mayor al nuestro acerca del comportamiento de los colores aditivos y su + distribución RGB. + En base a sus recomendaciones hicimos las sumas de colores en los distintos + objetos. \layout Section -Conclusiones Generales: +Conclusiones Generales. +\layout Standard + +Se reforzaron los conocimientos en programación C++ y la programación orientada + a objetos. + El modelo utilizado aplica fuertemente estos conceptos, motivo por el cual + no fue necesario utilizar un grafo para verificar los flujos por el circuito + creado. \layout Standard -Se reforzaron los conocimientos en programación C++. +Con el programa de desarrollo de interfaces, Glade-2, y las bibliotecas + Gtk+ y Glademm facilitaron mucho la creación del Cliente y el Constructor, + y nos hemos familiarizado con sus prestaciones, para crear aplicaciones + visuales. \layout Standard -Nos familiarizamos con las bibliotecas Gtk+. +Contamos con la ayuda de trabajar a distancia, gracias al subversion el + cual facilitó muchisimo las cosas y permitió que los tres integrantes del + equipo pudieramos contar con la totalidad del proyecto en todo momento, + pudiendo conocer el trabajo de los demás y al mismo tiempo reportar +\begin_inset Quotes eld +\end_inset + +bugs +\begin_inset Quotes erd +\end_inset + +. + En todo momento estuvimos actualizados sobre el desarrollo. +\layout Standard + +Nos ha parecido muy importante haber hecho todo el trabajo con ayuda de + herramientas comunes de desarrollo de software libre, las cuales dejaron + un producto final de una calidad igual o superior a cualquier otro entorno + de desarrollo de aplicaciones, sobre todo las aplicaciones visuales. +\layout Standard + +La documentación online generada con el Doxygen, si es bien utilizado, queda + muy completa y es muy fácil realizar una búsqueda con la ayuda de un navegador. + Esto puede comprobarse con la documentación online de la biblioteca Gtkmm + (www.gtkmm.org). +\layout Standard + +Hubo algunas ideas que no pudieron ser implementadas por cuestión de tiempo, + y la documentación estaba programada para realizarse en cuatro días, pero + tres días antes de la entrega nos avisaron que debíamos entregar el martes, + siendo que nosotros cursábamos los jueves, lo que redujo el tiempo de documenta +ción a solo dos días. +\layout Standard + +En general estamos muy conformes con el trabajo y la forma en la cuál fué + realizado, cumplimos los requisitos pedidos por el enunciado y creemos + que lo hicimos de una manera sobresaliente. \the_end