docs/manual_proyecto.lyx

   1 #LyX 1.3 created this file. For more info see http://www.lyx.org/
   2 \lyxformat 221
   3 \textclass article
   4 \language spanish
   5 \inputencoding auto
   6 \fontscheme default
   7 \graphics default
   8 \paperfontsize default
   9 \papersize Default
  10 \paperpackage a4
  11 \use_geometry 0
  12 \use_amsmath 0
  13 \use_natbib 0
  14 \use_numerical_citations 0
  15 \paperorientation portrait
  16 \secnumdepth 3
  17 \tocdepth 3
  18 \paragraph_separation indent
  19 \defskip medskip
  20 \quotes_language english
  21 \quotes_times 2
  22 \papercolumns 1
  23 \papersides 1
  24 \paperpagestyle default
  25
  26 \layout Title
  27
  28 Manual del Proyecto PlaQui
  29 \layout Standard
  30
  31
  32 \begin_inset LatexCommand \tableofcontents{}
  33
  34 \end_inset
  35
  36
  37 \layout Section
  38
  39 Integrantes.
  40 \layout Itemize
  41
  42 Nicolás Dimov (77.624)
  43 \layout Itemize
  44
  45 Leandro Lucarella (77.891)
  46 \layout Itemize
  47
  48 Ricardo Markiewicz (78.226)
  49 \layout Section
  50
  51 Programas de Prueba.
  52 \layout Standard
  53
  54 Los programas de prueba se pueden encontrar en la carpeta
  55 \emph on
  56 tests
  57 \emph default
  58 , allí se almacenaron los primeros ejecutables con los que luego se comenzó
  59  el desarrollo.
  60 \layout Standard
  61
  62 Con la ayuda de la herramienta subversion no fue necesario ir guardando
  63  parcialmente el proyecto, ya que subversion guarda en un repositorio todas
  64  las versiones intermedias del proyecto.
  65  Para obtener una versión particular del proyecto basta ejecutar:
  66 \layout LyX-Code
  67
  68 svn co -r[rev|{fecha}] http://svn.llucax.hn.org/svn/plaqui/
  69 \layout Standard
  70
  71 Donde
  72 \family typewriter
  73 -r
  74 \family default
  75  toma un parametro que puede ser el número de revisión que se quiere obtener
  76  (
  77 \family typewriter
  78 rev
  79 \family default
  80 ) o una fecha ingresada entre llaves (
  81 \family typewriter
  82 {fecha}
  83 \family default
  84 ).
  85  Por ejemplo para obtener la revisión 1 se puede hacer:
  86 \layout LyX-Code
  87
  88 svn co -r1 http://svn.llucax.hn.org/svn/plaqui/
  89 \layout Standard
  90
  91 Y para obtener la versión de la fecha de la preentrega se puede hacer:
  92 \layout LyX-Code
  93
  94 svn co -r'{2003-11-20 18:00}' http://svn.llucax.hn.org/svn/plaqui/
  95 \layout Standard
  96
  97 Es por esto que nos pareció que no tenía mucho sentido acompañar este manual
  98  con una versión particular del repositorio en un momento dado.
  99 \layout Section
 100
 101 Evolución del proyecto.
 102 \layout Standard
 103
 104 La evolución del proyecto también se documentó a través del subversion,
 105  ya que a cada versión que se sube al servidor se la acompaña de un comentario
 106  sobre los avances realizados.
 107  Para ver el mensaje de cualquier cambio realizado en una revisión
 108 \family typewriter
 109 X
 110 \family default
 111  se puede hacer:
 112 \layout LyX-Code
 113
 114 svn log -rX http://svn.llucax.hn.org/svn/plaqui/
 115 \layout Standard
 116
 117 Para ver todos los mensajes basta con:
 118 \layout LyX-Code
 119
 120 svn log -r0:HEAD http://svn.llucax.hn.org/svn/plaqui/
 121 \layout Standard
 122
 123 Por conveniencia, en el directoria raíz del código fuente entregado en el
 124  CD se encuentra un archivo ChangeLog con los mensajes de todas las revisiones
 125  del proyecto.
 126 \layout Section
 127
 128 División de Tareas.
 129 \layout Standard
 130
 131 A continuación se menciona, en terminos generales la tarea que realizó cada
 132  integrante:
 133 \layout Description
 134
 135 Leandro\SpecialChar ~
 136 Lucarella PlaQui Server.
 137 \layout Description
 138
 139 Ricardo\SpecialChar ~
 140 Markiewicz PlaQui Model y PlaQui Client.
 141 \layout Description
 142
 143 Nicolás\SpecialChar ~
 144 Dimov PlaQui Constructor.
 145 \layout Standard
 146
 147 Obviamente en algunas circunstancias algún integrante aporto al desarrollo
 148  de un módulo que no le estaba asignado.
 149  La documentación fue realizada y revisada entre todos los integrantes.
 150 \layout Section
 151
 152 Inconvenientes Encontrados.
 153 \layout Subsection
 154
 155 Servidor.
 156 \layout Standard
 157
 158 El servidor termina su ejecución si el XML que se le pasa como argumento
 159  no es válido.
 160 \layout Comment
 161
 162 los otros puntos no se como explicarlos (sockets no bloqueantes etc)
 163 \layout Subsection
 164
 165 Constructor.
 166 \layout Standard
 167
 168 A lo largo del desarrollo nos hemos encontrado con diferentes tipos de problemas
 169  los cuales pudieron ser solucionados, en su mayoría, de una forma aceptable.
 170
 171 \layout Standard
 172
 173 Al tabajar con imágenes independientes, las verificaciones sobre cada una
 174  de estas, dependen mucho de su posición en el área de trabajo y su orientación.
 175  Esto provoca que haya que realizar demasiadas validaciones para los diferentes
 176  tipos de verificaciones, y trae apareados problemas en la codificación
 177  por el uso de gran cantidad de coordenadas.
 178 \layout Standard
 179
 180 Otro inconveniente no solucionado, fue que las imágenes de cada elemento
 181  que se coloca sobre la grilla se crean tantas veces como elementos de ese
 182  tipo haya.
 183  La idea en un principio fue crear todas estas imágenes estáticas, de modo
 184  que para un elemento de cuatro imágenes, se cargarían en memoria solamente
 185  esas cuatro imágenes y luego los elementos iguales apuntarían su imagen
 186  actual a la que corresponda.
 187  Esto no pudo ser solucionado pués no encontramos la forma de inicializar
 188  las imágenes de manera estática, se producían errores en el momento del
 189  linkeo.
 190 \layout Subsection
 191
 192 Cliente.
 193 \layout Standard
 194
 195 El principal problema del cliente fueron las threads.
 196  El asunto fue descubrir la forma de hacer que las actualizaciones de refresco
 197  de las propiedades y la creación dinámica de objetos sea thread-safe para
 198  garantizar a la Gtk+ cierta estabilidad.
 199  Luego de mucho leer se encontro el Glib::Distpatcher, que es un evento
 200  asíncrono especialmente diseñado para comunicación entre hilos.
 201 \layout Subsection
 202
 203 Modelo.
 204 \layout Standard
 205
 206 El Modelo tenía la complicación de la Union.
 207  Este elemento es complicado ya que para poder saber el estado a su salida
 208  se necesitaba saber el estado a sus 2 entradas, y esta información llegaba
 209  en forma asíncrona.
 210  Luego de mucho diseño, análisis de todas las combinaciones posibles entre
 211  las entradas se llego a un método que resulto exitoso en la mayoría de
 212  las pruebas y fue adoptado como definivito.
 213 \layout Standard
 214
 215 Otro inconveniente fue la suma de colores.
 216  El ejemplo dado en el enunciado no era para nada correcto.
 217  Para solucionar esto nos pusimos en contacto con Nicolás Reyna, estudiante
 218  de diseño industrial en la Universidad de La Plata, quien tiene un conocimiento
 219  mayor al nuestro acerca del comportamiento de los colores aditivos y su
 220  distribución RGB.
 221  En base a sus recomendaciones hicimos las sumas de colores en los distintos
 222  objetos.
 223 \layout Section
 224
 225 Conclusiones Generales.
 226 \layout Standard
 227
 228 Se reforzaron los conocimientos en programación C++ y la programación orientada
 229  a objetos.
 230  El modelo utilizado aplica fuertemente estos conceptos, motivo por el cual
 231  no fue necesario utilizar un grafo para verificar los flujos por el circuito
 232  creado.
 233 \layout Standard
 234
 235 Con el programa de desarrollo de interfaces, Glade-2, y las bibliotecas
 236  Gtk+ y Glademm facilitaron mucho la creación del Cliente y el Constructor,
 237  y nos hemos familiarizado con sus prestaciones, para crear aplicaciones
 238  visuales.
 239
 240 \layout Standard
 241
 242 Contamos con la ayuda de trabajar a distancia, gracias al subversion el
 243  cual facilitó muchisimo las cosas y permitió que los tres integrantes del
 244  equipo pudieramos contar con la totalidad del proyecto en todo momento,
 245  pudiendo conocer el trabajo de los demás y al mismo tiempo reportar
 246 \begin_inset Quotes eld
 247 \end_inset
 248
 249 bugs
 250 \begin_inset Quotes erd
 251 \end_inset
 252
 253 .
 254  En todo momento estuvimos actualizados sobre el desarrollo.
 255 \layout Standard
 256
 257 Nos ha parecido muy importante haber hecho todo el trabajo con ayuda de
 258  herramientas comunes de desarrollo de software libre, las cuales dejaron
 259  un producto final de una calidad igual o superior a cualquier otro entorno
 260  de desarrollo de aplicaciones, sobre todo las aplicaciones visuales.
 261 \layout Standard
 262
 263 La documentación online generada con el Doxygen, si es bien utilizado, queda
 264  muy completa y es muy fácil realizar una búsqueda con la ayuda de un navegador.
 265  Esto puede comprobarse con la documentación online de la biblioteca Gtkmm
 266  (www.gtkmm.org).
 267 \layout Standard
 268
 269 Hubo algunas ideas que no pudieron ser implementadas por cuestión de tiempo,
 270  y la documentación estaba programada para realizarse en cuatro días, pero
 271  tres días antes de la entrega nos avisaron que debíamos entregar el martes,
 272  siendo que nosotros cursábamos los jueves, lo que redujo el tiempo de documenta
 273 ción a solo dos días.
 274 \layout Standard
 275
 276 En general estamos muy conformes con el trabajo y la forma en la cuál fué
 277  realizado, cumplimos los requisitos pedidos por el enunciado y creemos
 278  que lo hicimos de una manera sobresaliente.
 279 \the_end