le agregue unas lineas a lo que dejo ricky, nada del otro mundo, muy formal

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

diff --git a/Constructor/include/item.h b/Constructor/include/item.h
index 41348ca046260d98712fe080579fa9df6b2e2d8f..74001672fa3a9c4a236a23433720a43e75daf1b1 100644 (file)
--- a/Constructor/include/item.h
+++ b/Constructor/include/item.h
@@ -37,41 +37,41 @@ class Connector {
                }
 };
 
                }
 };
 

-/**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.
+/**
+ * Clase padre de todos los items que puedan aparecer.
+ * En esta clase están definidos todos los comportamientos en común
+ * y en algunos casos hay funciones abstractas para que cada item
+ * defina su propio comportamiento.
+ * Comportamientos comunes que se definen son, por ejemplo,
+ * 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ía 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().
+ * 
+ * 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 está conectado.
+ * 
+ * Al ser esta clase abstracta, no puede ser instanciada, 
+ * con lo cual existiría una clase derivada de esta para 
+ * cada item que se quiera agregar en la aplicación.

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


@@ -127,82 +127,82 @@ public:
        */
        virtual void save(FILE *archivo) = 0;
        
        */
        virtual void save(FILE *archivo) = 0;
        

-       /**Funcion abstracta que debe ser implementada en las clases descendientes
-         * 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.
-*/
+       /**
+        * Verifica que el ítem esté bien conectado.
+        * Las clases que heredan de CItem son las siguientes:
+        *
+        *      -# Conduct: representa un tubo.
+        *              
+        *      -# Splitter: representa un codo.
+        *              
+        *      -# Union: representa un empalme ( UNION ó DIVISION).
+        *      
+        *      -# Cistern: representa un tanque,
+        *      
+        *      -# Exclusa: representa una exclusa.
+        *      
+        *      -# Drain: representa un drenaje.
+        *      
+        *      -# 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 check_connection.png
+        *       \image latex check_connection.eps "Planta de ejemplo." width=10cm
+        *       
+        *      Donde \c bomba0 y \c tubo0 son los de la izquiera y \c bomba1 y 
+        *      \c 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 \c bomba0, este debe 
+        *      preguntar con quién esta conectado en su salida pero ya 
+        *      sabe, por ser bomba que tendrá una salida, luego el 
+        *      \c 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 \c bomba0 y el 
+        *      \c tubo0 se setean sus conectores y se establecen como \e conectados.
+        *
+        *      Continuando con la iteración, es el turno del \c 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 
+        *      \c bomba1 y el \c 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;
        
        ///Setea los conectores en su estado inicial.
        virtual bool check_connection()=0;
        
        ///Setea los conectores en su estado inicial.