1 #LyX 1.3 created this file. For more info see http://www.lyx.org/
15 \use_numerical_citations 0
16 \paperorientation portrait
23 \paragraph_separation indent
25 \quotes_language english
29 \paperpagestyle default
38 Taller de Programación I
40 Universidad de Buenos Aires
44 \begin_inset LatexCommand \tableofcontents{}
54 Nicolás Dimov (77.624)
57 Leandro Lucarella (77.891)
60 Ricardo Markiewicz (78.226)
66 Los programas de prueba se pueden encontrar en la carpeta
70 , allí se almacenaron los primeros ejecutables con los cuales se experimentó
71 en temas que no se habían visto hasta el momento como
86 Con la ayuda de la herramienta subversion no fue necesario ir guardando
87 versiones parciales del proyecto, ya que subversion guarda en un repositorio
88 todas las versiones intermedias por nosotros, a las cuales se puede acceder
90 Para obtener una versión particular del proyecto basta ejecutar:
93 svn co -r[rev|{fecha}] http://svn.llucax.hn.org/svn/plaqui/
100 toma un parámetro que puede ser el número de revisión que se quiere obtener
105 ) o una fecha ingresada entre llaves (
110 Por ejemplo para obtener la revisión 1 se puede hacer:
113 svn co -r1 http://svn.llucax.hn.org/svn/plaqui/
116 Y para obtener la versión de la fecha de la pre-entrega se puede hacer:
119 svn co -r'{2003-11-20 18:00}' http://svn.llucax.hn.org/svn/plaqui/
122 Es por esto que nos pareció que no tenía mucho sentido acompañar este manual
123 con una versión particular del repositorio en un momento dado.
126 Evolución del proyecto.
129 La evolución del proyecto también se documentó a través del subversion,
130 ya que a cada versión que se sube al servidor se la acompaña de un comentario
131 sobre los avances realizados.
132 Para ver el mensaje de cualquier cambio realizado en una revisión
139 svn log -rX http://svn.llucax.hn.org/svn/plaqui/
142 Para ver todos los mensajes basta con:
145 svn log -r0:HEAD http://svn.llucax.hn.org/svn/plaqui/
148 Por conveniencia, en el directoria raíz del código fuente entregado en el
149 CD se encuentra un archivo
153 con los mensajes de todas las revisiones del proyecto.
156 A continuación se muestra una gráfica generada con un
164 , que se adjunta en el CD) que indica la cantidad de
168 (cambios de versión) que se hicieron día a día, donde cada
179 PlaQui - Grafica de Progreso SVN
182 --------------------------------
200 2003-10-12 **********
220 2003-10-17 ************
224 2003-10-18 **********
240 2003-10-22 ************
248 2003-10-24 ***********
272 2003-11-06 **********
296 2003-11-13 *************
308 2003-11-17 *************
312 2003-11-18 **********************
316 2003-11-19 ***************
320 2003-11-20 ***************************
332 2003-11-23 *****************
360 2003-11-30 **********************
364 2003-12-01 *******************************************************
368 2003-12-02 *****************************************
372 ( ) = Máximo/s Commiteador/es del Día
386 luca Leandro Lucarella
389 rmarkie Ricardo Markiewicz
392 Vale la pena aclarar que en este gráfico no se muestran la cantidad de líneas
393 modificadas, por lo que una gran cantidad de
397 no significa necesariamente un gran cambio en el repositorio.
403 A continuación se menciona, en términos generales la tarea que realizó cada
407 Leandro\SpecialChar ~
408 Lucarella PlaQui Server.
411 Ricardo\SpecialChar ~
412 Markiewicz PlaQui Model y PlaQui Client.
415 Nicolás\SpecialChar ~
416 Dimov PlaQui Constructor.
419 Obviamente en algunas circunstancias algún integrante aporto al desarrollo
420 de un módulo que no le estaba asignado.
421 La documentación fue realizada y revisada entre todos los integrantes.
424 Inconvenientes Encontrados.
430 El Servidor trajo varios problemas, en especial en cuanto al manejo de
439 El uso de señales (para hacer el servidor orientado a eventos) dio también
440 algunos problemas menores.
450 El principal problema de los threads fue el no poder saber fácilmente donde
451 se producía un error, en especial cuando el error venía por la falta de
457 En términos generales, cada vez que el server tenía una violación de segmento
458 se debía a la falta de un
465 Otro problema eran las excepciones no manejadas dentro del método
469 (que se ejecuta en su propio
474 Aunque se incluía un bloque
478 en el programa principal, al ocurrir una excepción en un
486 hasta el hilo padre y el programa sale con
495 tiene su propio bloque
499 donde pueda surgir una excepción y se incluyó la
507 para poder avisar de dicho error a quien lo necesite.
517 El principal problema con los
521 fue la imposibilidad (por enunciado) de usar
526 Esto tuvo particular repercusión en el
530 , ya que una vez llamado al
534 para aceptar una nueva conexión, esta no retorna hasta que efectivamente
535 se reciba una nueva conexión, haciendo imposible terminar el servidor de
537 Para resolver esto, al finalizar el
545 para hacer que la llamada a
549 retorne y el servidor pueda ser cerrado limpiamente.
555 La señales no dieron mayores problemas.
556 El único inconveniente es que complican la depuración del programa, ya
557 que uno no sabe de antemano quien las atenderá y se hace difícil seguir
564 El Server está preparado para servir (y simular) una cantidad indeterminada
566 Por problemas de tiempo esto no se llegó a implementar correctamente en
567 el programa, en particular por la complicación que traería implementar
568 dicha función en el cliente.
574 A lo largo del desarrollo nos hemos encontrado con diferentes tipos de problemas
575 los cuales pudieron ser solucionados, en su mayoría, de una forma aceptable.
579 Al trabajar con imágenes independientes, las verificaciones sobre cada una
580 de estas, dependen mucho de su posición en el área de trabajo y su orientación.
581 Esto provoca que haya que realizar demasiadas validaciones para los diferentes
582 tipos de verificaciones, y trae apareados problemas en la codificación
583 por el uso de gran cantidad de coordenadas.
586 Otro inconveniente no solucionado, fue que las imágenes de cada elemento
587 que se coloca sobre la grilla se crean tantas veces como elementos de ese
589 La idea en un principio fue crear todas estas imágenes estáticas, de modo
590 que para un elemento de cuatro imágenes, se cargarían en memoria solamente
591 esas cuatro imágenes y luego los elementos iguales apuntarían su imagen
592 actual a la que corresponda.
593 Esto no pudo ser solucionado pues no encontramos la forma de inicializar
594 las imágenes de manera estática, se producían errores en el momento del
598 Por problemas de tiempo, hubo algunas implementaciones sobre el Constructor
599 luego de cerrado el tema de la documentación, por ejemplo, el Constructor
600 pregunta si quiere guardar el trabajo antes de salir del programa.
601 Esto no fue documentado.
607 El principal problema del cliente fueron los
612 El asunto fue descubrir la forma de hacer que las actualizaciones de refresco
613 de las propiedades y la creación dinámica de objetos sea
617 para garantizar a la Gtk+ cierta estabilidad.
618 Luego de mucho leer se encontró el
622 , que es un evento asíncrono especialmente diseñado para comunicación entre
629 El Modelo tenía la complicación de la Union.
630 Este elemento es complicado ya que para poder saber el estado a su salida
631 se necesitaba saber el estado a sus 2 entradas, y esta información llegaba
633 Luego de mucho diseño, análisis de todas las combinaciones posibles entre
634 las entradas se llego a un método que resulto exitoso en la mayoría de
635 las pruebas y fue adoptado como definitivo.
638 Otro inconveniente fue la suma de colores.
639 El ejemplo dado en el enunciado no era para nada correcto.
640 Para solucionar esto nos pusimos en contacto con Nicolás Reyna, estudiante
641 de diseño industrial en la Universidad de La Plata, quien tiene un conocimiento
642 mayor al nuestro acerca del comportamiento de los colores aditivos y su
644 En base a sus recomendaciones hicimos las sumas de colores en los distintos
648 Por último, al verificarse la validez del conexionado de un archivo XML
649 de planta en el Constructor, el Modelo no vuelve a realizar el chequeo,
650 por lo que si se quiere levantar una planta desde un XML invalido los resultado
657 Se reforzaron los conocimientos en programación C++ y la programación orientada
659 El modelo utilizado aplica fuertemente estos conceptos, motivo por el cual
660 no fue necesario utilizar un grafo para verificar los flujos por el circuito
664 El programa de desarrollo de interfaces Glade-2, y las bibliotecas Gtk+
665 y Glademm facilitaron mucho la creación del Cliente y el Constructor, y
666 nos hemos familiarizado con sus prestaciones, para crear aplicaciones visuales.
670 Contamos con la ayuda del subversion y una lista de correos pudimos trabajar
671 a distancia cómodamente, lo cual facilitó muchísimo las cosas y permitió
672 que los tres integrantes del equipo pudiéramos contar con la totalidad
673 del proyecto en todo momento, pudiendo conocer el trabajo de los demás
674 y al mismo tiempo reportar
678 o complementar el trabajo de otro.
679 En todo momento estuvimos actualizados sobre el desarrollo.
680 Cabe mencionar que necesitamos juntarnos solamente una vez para distribuirnos
682 El resto del trabajo práctico se realizó a distancia.
685 Nos ha parecido muy importante haber hecho todo el trabajo con ayuda de
686 herramientas comunes de desarrollo de Software Libre, las cuales dejaron
687 un producto final de una calidad igual o superior a cualquier otro entorno
688 de desarrollo de aplicaciones, sobre todo las aplicaciones visuales que
689 aprovechan un excelente trabajo de la GTK+ que suma un valor agregado como
690 la posibilidad de cambiar la apariencia de la aplicación a través de
695 Esto también nos permitió hacer un trabajo práctico usando 100% software
696 legal, cosa que incluso grandes empresas no pueden realizar en muchos casos
697 (ni hablar un estudiante).
700 La documentación online generada con el Doxygen, si es bien utilizado, queda
701 muy completa y es muy fácil realizar una búsqueda con la ayuda de un navegador.
702 Esto puede comprobarse con la documentación online de la biblioteca Gtkmm
708 La documentación en formato HTML del proyecto se encuentra en el CD y en
711 http://www.llucax.hn.org/plaqui/docs/html/
716 Hubo algunas ideas que no pudieron ser implementadas por cuestión de tiempo,
717 y la documentación estaba programada para realizarse en cuatro días, pero
718 tres días antes de la entrega nos enteramos que debíamos entregar el Martes,
719 siendo que nosotros cursábamos los Jueves, lo que redujo el tiempo de documenta
720 ción a sólo dos días.
721 Aún así creemos que se logró hacer un trabajo muy completo de documentación,
722 en parte gracias a Doxygen (como se dijo antes) porque a medida que íbamos
723 escribiendo el código lo íbamos documentando en línea.
726 En general estamos muy conformes con el trabajo y la forma en la cuál fue
727 realizado, cumplimos los requisitos pedidos por el enunciado y creemos
728 que lo hicimos de una manera correcta.
731 El proyecto completo es entregado en un CD que puede ser leído desde cualquier
732 sistema operativo en cualquier tipo de lectora, pero también es un CD
736 con lo cual no es necesario ni siquiera tener un sistema operativo instalado
737 o un disco rígido para poder operar el PlaQui.
738 Basta activar la opción de