]> git.llucax.com Git - z.facultad/75.42/plaqui.git/blobdiff - docs/manual_proyecto.lyx
- Se agrega una parte solo para la salida HTML del doxygen, con links a todos
[z.facultad/75.42/plaqui.git] / docs / manual_proyecto.lyx
index ea90816f0a9cae8d85123a58439f401117708308..d748d40d75c62ba2615fb09556c9d00e057ceafe 100644 (file)
@@ -36,64 +36,244 @@ Manual del Proyecto PlaQui
 
 \layout Section
 
 
 \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
 
 \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
 
 \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
 
 \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
 
 \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
 
 \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
 
 \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
 
 \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
 
 \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
 
 \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
 
 \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
 
 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)
 
 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
 
 \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
 
 \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
 
  
 \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
 \the_end