corregi las imagenes del manual del usuario y agregue una mas

[z.facultad/75.42/plaqui.git] / Constructor / include / item.h

diff --git a/Constructor/include/item.h b/Constructor/include/item.h
index 3259d8d1170acf472cad7d8ca6d8f6d6ff0e9d35..41348ca046260d98712fe080579fa9df6b2e2d8f 100644 (file)
--- a/Constructor/include/item.h
+++ b/Constructor/include/item.h
@@ -12,12 +12,6 @@
 #include "itemptywnd.h"
 #include "workplace.h"
 
 #include "itemptywnd.h"
 #include "workplace.h"
 

-/**Esta es la clase padre de todos los items que puedan aparecer
-  *Aca estan definidos todos los comportamientos en comun y en 
-  *algunos casos hay funciones abstractas para que cada item defina
-  * su propio comportamiento.
-*/
-

 ///Tipo de estado en el que pueden estar los conectores de un item
 typedef enum { UNDEF, IN, OUT } ConnectorType;
 
 ///Tipo de estado en el que pueden estar los conectores de un item
 typedef enum { UNDEF, IN, OUT } ConnectorType;
 


@@ -43,8 +37,43 @@ class Connector {
                }
 };
 
                }
 };
 

-//class WorkPlace;
-       
+/**Esta es la clase padre de todos los items que puedan aparecer
+  *Aca estan definidos todos los comportamientos en comun y en 
+  *algunos casos hay funciones abstractas para que cada item defina
+  * su propio comportamiento.
+*/
+/**Acá se definen los comportamientos comunes de todo los 
+ *     items de la aplicación, como puede ser la imagen 
+ *     actual, la posición en la grilla, el caudal máximo,el 
+ *     número único de identificación y diferentes punteros a 
+ *     otros objetos.
+ *     
+ *     Por cuestiones de diseño los elementos de la planta 
+ *     además de tener un número único que los identifica, 
+ *     también deben tener nombres difrerentes.
+ *     
+ *     También esta definida en esta clase la estuctura que 
+ *     representa los conectores físicos, y otra que 
+ *     representa a los conectores lógicos.
+ *     
+ *     Esta clase contiene métodos abstractos ya que cualquier 
+ *     elemento que descienda de ella deberá poder implementar 
+ *     los mismos porque, por ejemplo, ningún item se guarda 
+ *     en un archivo de la misma manera; este es el caso del 
+ *     método save( FILE archivo).
+ *     
+ *     Existe otro método abstracto dentro de esta clase que 
+ *     es check_connection(). Del mismo modo que un item se 
+ *     guarda de forma diferente que otro, también verifica su 
+ *     conexión de distinta forma, es por eso que cada item 
+ *     debe implementar su manera de verificar como y con 
+ *     quién esta conectado.
+ *     
+ *     Al ser esta clase abstracta, no puede ser instanciada, 
+ *     con lo cual existirá una clase derivada de esta para 
+ *     cada item que se quiera agregar en la aplicación.
+*/
+

 class CItem:public Gtk::DrawingArea {
 public:
        ///Constructor
 class CItem:public Gtk::DrawingArea {
 public:
        ///Constructor


@@ -69,9 +98,6 @@ public:
        
        ///Elimina el Item al seleccionarse la opcion en el menu flotante
        virtual void on_menu_popup_eliminar();
        
        ///Elimina el Item al seleccionarse la opcion en el menu flotante
        virtual void on_menu_popup_eliminar();

-       
-       ///TODO: conectar los items con lineas!!!
-       virtual void on_menu_popup_conectar();

                
        ///Retorna un puntero a la imagen actual.
        Glib::RefPtr<Gdk::Pixbuf> get_image() { return image; }
                
        ///Retorna un puntero a la imagen actual.
        Glib::RefPtr<Gdk::Pixbuf> get_image() { return image; }


@@ -105,10 +131,84 @@ public:
          * ya que cada item verifica sus conexione de manera difenrente y todos deben
          * hacerlo.
        */
          * ya que cada item verifica sus conexione de manera difenrente y todos deben
          * hacerlo.
        */

+/**Las clases que heredan de CItem son las siguientes:
+       
+ *     1. Conduct: representa un tubo.
+ *             
+ *     2. Splitter: representa un codo.
+ *             
+ *     3. Union: representa un empalme ( UNION ó DIVISION).
+ *     
+ *     4. Cistern: representa un tanque,
+ *     
+ *     5. Exclusa: representa una exclusa.
+ *     
+ *     6. Drain: representa un drenaje.
+ *     
+ *     7. Pump: representa una bomba.
+ *     
+ *     Para las clases Conduct, Splitter y Exclusa, este 
+ *     método es bastante similar, sobre todo teniendo en 
+ *     cuenta que una exclusa es un tubo con una propiedad mas 
+ *     (abierto/cerrado) y el codo es un tubo que en la 
+ *     aplicación representa un curva.
+ *     
+ *     Estos tres elementos tienen la particularidad que sus 
+ *     conectores físicos no estan definidos en el momento de 
+ *     su creación, sino que se definen una vez que pertenecen 
+ *     a un circuito.
+ *     
+ *     La verificación se realiza recorriendo la lista de 
+ *     items y preguntandole a cada uno que posee en sus extremos.
+ *     
+ *     El tanque, la bomba, el empalme y el drenaje, tiene 
+ *     definidos sus conectores en el momento de la creación.
+ *     
+ *     Supongamos que el circuito es el siguiente:
+ *      \image html ckeck_connection.png
+ *      
+ *     Donde bomba0 y tubo0 son los de la izquiera y bomba1 y 
+ *     tubo1 son los de la derecha, para poder diferenciarlos.
+ *     Cabe aclarar que no importa con cual de los items se 
+ *     comience la iteración.
+ *     Según la imagen actual de la bomba0, este debe 
+ *     preguntar con quién esta conectado en su salida pero ya 
+ *     sabe, por ser bomba que tendrá una salida, luego el 
+ *     tubo0 que en ese momento no esta definido, debe 
+ *     averiguar como definirse, para hacerlo pregunta en su 
+ *     otro extremo el cual esta conectado con una unión, que 
+ *     por ser unión posee dos entradas (horizontales en este 
+ *     caso) y una salida (vertical). La unión le responde que 
+ *     posee una entrada, por lo tanto el extremo derecho del 
+ *     tubo será una salida, lo cual implica que el extremo 
+ *     izquierdo tiene que ser una entrada, y esto es 
+ *     compatible con la bomba. De esta forma la bomba0 y el 
+ *     tubo0 se setean sus conectores y se establecen como "conectados". 
+ * Continuando con la iteración, es el turno del tubo0 
+ *     (por el orden de incersión en la lista), pero este ya 
+ *     está conectado, por lo tanto no se realizan verificaciones.
+ *     
+ *     Lo mismo ocurre del lado derecho del circuito con la 
+ *     bomba1 y el tubo1.
+ *     
+ *     Algo similar ocurre cuando la unión pregunta que tiene 
+ *     en su salida, la exclusa debe preguntarle al tanque y 
+ *     este le responderá que posee una entrada, luego la 
+ *     exculsa tendrá una entrada en el extremo superior y una 
+ *     salida en el inferior; nuevamente el circuito es 
+ *     compatible. Por último el tanque le solicita al codo 
+ *     que le informe su estado y el proceso se repite con el 
+ *     drenaje que posee solamente una salida.
+ *     
+ *     Así todos los elementos han quedado conectados y 
+ *     conocen también con quién o quienes lo están.
+*/

        virtual bool check_connection()=0;
        
        virtual bool check_connection()=0;
        

-       ///TODO: hacer abstractas estas funciones... en item no hacen nada....
+       ///Setea los conectores en su estado inicial.

        virtual void set_default_connector();   
        virtual void set_default_connector();   

+       
+       ///Devuelve el tipo de conector que tiene el item en la posicion (_a,_b).

        virtual ConnectorType get_connector_type( int _a, int _b );
        
        /**Devuelve en _a y _b la posicion de los conectores logicos del item segun su posicion.
        virtual ConnectorType get_connector_type( int _a, int _b );
        
        /**Devuelve en _a y _b la posicion de los conectores logicos del item segun su posicion.