Constructor/doc/especificaciones_tecnicas.txt

   1 PlaQui Constructor
   2
   3 Documentación Técnica
   4
   5 Table of Contents
   6
   7 1 Introducción:
   8 2 Descripción del desarrollo:
   9     2.1 Constructor:
  10     2.2 WorkPlace:
  11     2.3 CItem:
  12         2.3.1 Método check_connection():
  13 3 Formtato del archivo:
  14
  15
  16
  17 1 Introducción:
  18
  19 Al ser una aplicación visual, algunos conceptos de la
  20 programación orientada a objetos no se han tomados al
  21 pie de la letra, ya sea cuestiones de encapsulamiento o
  22 abstracción.
  23
  24 2 Descripción del desarrollo:
  25
  26 2.1 Constructor:
  27
  28 La clase principal de esta aplicación es la clase
  29 Constructor. Ella es la encargada de obtener e
  30 inicializar todos los elementos de la ventana
  31 principal, ya sean botones, cuadros de diálogo, barras
  32 de herramientas, etc.
  33
  34 Para cada botón referenciado por esta clase, es
  35 conectado a ellos una señal, que será el método que
  36 deben invocar al ser presionados.
  37
  38 Uno de los métodos mas importantes de esta clase es "
  39 on_item_drop_drag_recived()" que es la encargada de
  40 crear un nuevo elemento si es arrastrado desde la barra
  41 de elementos, o de moverlo dentro del área de trabajo
  42 si este ya estaba creado.
  43
  44 Para facilitar el diseño y disminuir la complejidad, la
  45 grilla fue dividida en sectores de 32x32 pixels, lo que
  46 permite que el usuario no tenga que ser muy preciso a
  47 la hora de soltar un item en el área de trabajo.
  48
  49 Cada nuevo elemento creado es almacenado en una lista
  50 de elementos ( "listaItems" ) de transporte o
  51 almacenamiento de fluido, o de elementos lógicos, según
  52 cual sea ( "lista_logic_items").
  53
  54 Otra de las funciones principales es "check_connection()"
  55 que recorre todos los items de ambas listas y verifica
  56 que se haya formado en el momento del diseño un
  57 circuito posible. Mas adelante se verá como cada
  58 elemento verifica su conexión.
  59
  60 Esta clase contiene los métodos necesarios para guardar
  61 y cargar un archivo XML cuyo formato se explica mas adelante.
  62
  63 También está contenida en ella la clase WorkPlace, que
  64 detalla a continuación.
  65
  66 2.2 WorkPlace:
  67
  68 Esta clase es la encarga de de manejar el área trabajo.
  69 Deriva de Gtk::DrawingArea pues es donde se van a
  70 dibujar todos los elementos. Una de sus principales
  71 tareas es redibujarse cuando sea necesario y al mismo
  72 tiempo, redibujar los elementos que contiene, como
  73 pueden ser los items de la planta o las líneas lógicas
  74 que conectan los mismos.
  75
  76 Para lograr esto, se ha redefinido el método virtual
  77 (contenido en la clase ancestro) "on_expose_event()" de
  78 manera conveniente.
  79
  80 También se encarga de eliminar correctamente un item,
  81 eliminando al mismo tiempo las lineas que llegan o
  82 salen de él.
  83
  84 2.3 CItem:
  85
  86 Acá se definen los comportamientos comunes de todo los
  87 items de la aplicación, como puede ser la imagen
  88 actual, la posición en la grilla, el caudal máximo,el
  89 número único de identificación y diferentes punteros a
  90 otros objetos.
  91
  92 Por cuestiones de diseño los elementos de la planta
  93 además de tener un número único que los identifica,
  94 también deben tener nombres difrerentes.
  95
  96 También esta definida en esta clase la estuctura que
  97 representa los conectores físicos, y otra que
  98 representa a los conectores lógicos.
  99
 100 Esta clase contiene métodos abstractos ya que cualquier
 101 elemento que descienda de ella deberá poder implementar
 102 los mismos porque, por ejemplo, ningún item se guarda
 103 en un archivo de la misma manera; este es el caso del
 104 método "save( FILE archivo)".
 105
 106 Existe otro método abstracto dentro de esta clase que
 107 es "check_connection()". Del mismo modo que un item se
 108 guarda de forma diferente que otro, también verifica su
 109 conexión de distinta forma, es por eso que cada item
 110 debe implementar su manera de verificar como y con
 111 quién esta conectado.
 112
 113 Al ser esta clase abstracta, no puede ser instanciada,
 114 con lo cual existirá una clase derivada de esta para
 115 cada item que se quiera agregar en la aplicación.
 116
 117 2.3.1 Método check_connection():
 118
 119 Anteriormente se mencionó que cada item verifica sus
 120 conexiones de manera diferente.
 121
 122 Las clases que heredan de CItem son las siguientes:
 123
 124 1. Conduct: representa un tubo.
 125
 126 2. Splitter: representa un codo.
 127
 128 3. Union: representa un empalme ( UNION ó DIVISION).
 129
 130 4. Cistern: representa un tanque,
 131
 132 5. Exclusa: representa una exclusa.
 133
 134 6. Drain: representa un drenaje.
 135
 136 7. Pump: representa una bomba.
 137
 138 Para las clases Conduct, Splitter y Exclusa, este
 139 método es bastante similar, sobre todo teniendo en
 140 cuenta que una exclusa es un tubo con una propiedad mas
 141 (abierto/cerrado) y el codo es un tubo que en la
 142 aplicación representa un curva.
 143
 144 Estos tres elementos tienen la particularidad que sus
 145 conectores físicos no estan definidos en el momento de
 146 su creación, sino que se definen una vez que pertenecen
 147 a un circuito.
 148
 149 La verificación se realiza recorriendo la lista de
 150 items y preguntandole a cada uno que posee en sus extremos.
 151
 152 El tanque, la bomba, el empalme y el drenaje, tiene
 153 definidos sus conectores en el momento de la creación.
 154
 155 Supongamos que el circuito es el siguiente:
 156
 157 <Graphics file: /home/nico/plaqui/Constructor/doc/check_connection.png>
 158
 159
 160 Donde bomba0 y tubo0 son los de la izquiera y bomba1 y
 161 tubo1 son los de la derecha, para poder diferenciarlos.
 162
 163 Cabe aclarar que no importa con cual de los items se
 164 comience la iteración.
 165
 166 Según la imagen actual de la bomba0, este debe
 167 preguntar con quién esta conectado en su salida pero ya
 168 sabe, por ser bomba que tendrá una salida, luego el
 169 tubo0 que en ese momento no esta definido, debe
 170 averiguar como definirse, para hacerlo pregunta en su
 171 otro extremo el cual esta conectado con una unión, que
 172 por ser unión posee dos entradas (horizontales en este
 173 caso) y una salida (vertical). La unión le responde que
 174 posee una entrada, por lo tanto el extremo derecho del
 175 tubo será una salida, lo cual implica que el extremo
 176 izquierdo tiene que ser una entrada, y esto es
 177 compatible con la bomba. De esta forma la bomba0 y el
 178 tubo0 se setean sus conectores y se establecen como "conectados"
 179 . Continuando con la iteración, es el turno del tubo0
 180 (por el orden de incersión en la lista), pero este ya
 181 está conectado, por lo tanto no se realizan verificaciones.
 182
 183 Lo mismo ocurre del lado derecho del circuito con la
 184 bomba1 y el tubo1.
 185
 186 Algo similar ocurre cuando la unión pregunta que tiene
 187 en su salida, la exclusa debe preguntarle al tanque y
 188 este le responderá que posee una entrada, luego la
 189 exculsa tendrá una entrada en el extremo superior y una
 190 salida en el inferior; nuevamente el circuito es
 191 compatible. Por último el tanque le solicita al codo
 192 que le informe su estado y el proceso se repite con el
 193 drenaje que posee solamente una salida.
 194
 195 Así todos los elementos han quedado conectados y
 196 conocen también con quién o quienes lo están.
 197
 198 3 Formtato del archivo:
 199
 200 El archivo de salida de la planta al guardarla tiene un
 201 formato XML.
 202
 203 Para el ejemplo anterior el archivo sería el siguiente: