\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
projects / z.facultad / 75.42 / plaqui.git / blobdiff