From: Leandro Lucarella Date: Mon, 1 Dec 2003 19:52:25 +0000 (+0000) Subject: Se corrige la documentacion en linea del doxygen. X-Git-Tag: svn_import~104 X-Git-Url: https://git.llucax.com/z.facultad/75.42/plaqui.git/commitdiff_plain/5120dd633e2834c127174517a250a089ea8abdeb?ds=sidebyside Se corrige la documentacion en linea del doxygen. --- diff --git a/Constructor/include/constructor.h b/Constructor/include/constructor.h index 5ba90be..69cc418 100644 --- a/Constructor/include/constructor.h +++ b/Constructor/include/constructor.h @@ -25,39 +25,40 @@ #include "or.h" #include "not.h" #include "libxml/parser.h" -/**La clase principal de esta aplicación es la clase - * Constructor. Ella es la encargada de obtener e - * inicializar todos los elementos de la ventana - * principal, ya sean botones, cuadros de diálogo, barras - * de herramientas, etc. - * - * Para cada botón referenciado por esta clase, es - * conectado a ellos una señal, que será el método que - * deben invocar al ser presionados. - * - * Uno de los métodos mas importantes de esta clase es - * on_item_drop_drag_recived() que es la encargada de - * crear un nuevo elemento si es arrastrado desde la barra - * de elementos, o de moverlo dentro del área de trabajo - * si este ya estaba creado. - * - * Para facilitar el diseño y disminuir la complejidad, la - * grilla fue dividida en sectores de 32x32 pixels, lo que - * permite que el usuario no tenga que ser muy preciso a - * la hora de soltar un item en el área de trabajo. - * - * Cada nuevo elemento creado es almacenado en una lista - * de elementos ( listaItems ) de transporte o - * almacenamiento de fluido, o de elementos lógicos, según - * cual sea ( lista_logic_items). +/** + * Clase principal de esta aplicación. + * Esta clase se encargada de obtener e + * inicializar todos los elementos de la ventana + * principal, ya sean botones, cuadros de diálogo, barras + * de herramientas, etc. + * + * Para cada botón referenciado por esta clase, es + * conectado a ellos una señal, que será el método que + * deben invocar al ser presionados. + * + * Uno de los métodos mas importantes de esta clase es + * on_item_drop_drag_recived() que es la encargada de + * crear un nuevo elemento si es arrastrado desde la barra + * de elementos, o de moverlo dentro del + * \ref WorkPlace "área de trabajo" si este ya estaba creado. + * + * Para facilitar el diseño y disminuir la complejidad, la + * grilla fue dividida en sectores de 32x32 píxels, lo que + * permite que el usuario no tenga que ser muy preciso a + * la hora de soltar un item en el + * \ref WorkPlace "área de trabajo". + * + * Cada nuevo elemento creado es almacenado en una + * \ref listaItems "lista de elementos de transporte o almacenamiento de fluido", + * o en una \ref lista_logic_items "lista de elementos lógicos". * - * Otra de las funciones principales es "check_connection()" + * Otra de las funciones principales es check_connection() * que recorre todos los items de ambas listas y verifica - * que se haya formado en el momento del diseño un + * que se haya formado en el momento del diseño un * circuito posible. * - * Esta clase contiene los métodos necesarios para guardar - * y cargar un archivo XML cuyo formato se explica mas adelante. + * Esta clase contiene los métodos necesarios para guardar + * y cargar un archivo XML cuyo formato se explica más adelante. */ class Constructor : public Gtk::Window { public: diff --git a/Constructor/include/item.h b/Constructor/include/item.h index 41348ca..d249a79 100644 --- 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 { @@ -127,82 +127,82 @@ public: */ 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 ckeck_connection.png + * \image latex ckeck_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 + * 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.