From: Ricardo Markiewicz Date: Mon, 1 Dec 2003 23:36:21 +0000 (+0000) Subject: Agrego mi intendo de documentacion con doxygen :-) ... X-Git-Tag: svn_import~86 X-Git-Url: https://git.llucax.com/z.facultad/75.42/plaqui.git/commitdiff_plain/c5c8d16a2d8c4a0ec1a8d3e83104f73512c91001?hp=a55be4baabc452fb5ba393ebd5f3a219eb8e61e9 Agrego mi intendo de documentacion con doxygen :-) ... --- diff --git a/Model/include/documentation.h b/Model/include/documentation.h new file mode 100644 index 0000000..7c8d774 --- /dev/null +++ b/Model/include/documentation.h @@ -0,0 +1,69 @@ +/** \page page_model PlaQui Model + +\section page_model_general Descripción General. + El modelo es quien se encarga de la simulación de una planta química dentro + de esta suite de herramientas. Puede ser utilizado como un programa independiente + (plaqui-model) o como una biblioteca estática y ser compilado dentro de un + ejecutable como lo hace PlaQui Server. + + \subsection page_model_general_clases Clases del Modelo + Para cada elemento que es posible simular, el modelo tiene una clase que se encarga + de ello. También existe una clase Simulator que es quien se encarga de manejar una + simulación, cargar una planta desde un archivo XML y da una interfaz para poder + acceder a propiedades del modelo desde el exterior. + + \subsection page_model_general_simulacion Simulación. + Para entender que es lo que vemos al simular una planta, primero debemos entender + como es que el modelo resuelve la simulación. + + En cada paso de la simulación se realizan 3 tareas por separado, que deben ser ejecutadas + de forma correcta, ya que la alteración del orden puede provocar resultados inesperados. El + primer paso es el de actualización (update), luego el de simulación (simulate) + y por último la actualización de colores. + + \subsection page_model_update Update. + El objetivo de esta face es que todos los elementos del modelo calculen el flujo que va a + circular por ellos en la iteración actual. Para poder hacer esto, siempre se debe llamar + al update de las bombas únicamente, ya que desde ellas sale el fluido. + + La bomba envía un mensaje a su salida, consultando por el flujo máximo que el elemento al + que está conectado es capaz de manejar, informandole también cual es la capacidad de envío + de flujo propio. + + Este primer envío da como resultado una reacción en cadena hasta llegar a los + drenajes que tenga el circuito. Cada elemento reacciona de manera distinta y reacciona + en base a sus requerimientos. + + Cuando la bomba recibe una respuesta de flujo máximo saliente menor a su capacidad, esta + se queda con la menor de ambas. Esto es debido a que el conducto no puede soportar más + de lo que responde, y el restante que la bomba pueda entregar rebotaría y debería + elevar la presión dentro de la bomba hasta explotar. Tambíen aparecerían turbulencias + que harían que el flujo sea fluctuante. Sin embargo, como estos parámetros no son tomados + en cuenta, el resultado de la simulación es que la bomba se limita a enviar solo + lo que la salida pueda aceptar, pareciendo que se auto regula. + + La consecuencia de lo explicado anteriormente es por requerimiento del enunciado y simplificacion + del modelo debido al poco tiempo con el que se cuentó para el total del proyecto. + + \subsection page_model_simulate Simulate. + Es esta face, con los flujos actuales a la orden del día, cada objeto se actualiza. + El tanque se suma el flujo entrante y se resta el flujo saliente. + + \subsection page_model_color Update Color. + Aquí comienza una cadena de mensajes similar al del update, pero esta vez se envía hacia + las entradas, y se pide que nos envíe el color. + Entonces, por ejemplo, una union pide un color a cada salida y luego los suma. + + + +*/ + +/** \namespace PlaQui::Model + +Infrastructura del modelo de simulación para PlaQui. + +Bajo este espacio de nombres (namespace) se encuentran todas las clases para la +simulación de PlaQui. + +*/ + diff --git a/Model/include/iconector.h b/Model/include/iconector.h index 98455fc..828b7d2 100644 --- a/Model/include/iconector.h +++ b/Model/include/iconector.h @@ -11,7 +11,7 @@ namespace Model { /** Conector genérico de elementos * * El conector es un interfaz común que permite a objetos de distinto - * tipo comunicarse entre sí sin la necesidad de conocerse. + * tipo comunicarse entre sí, sin la necesidad de conocerse. * Maneja una lista de elementos conectados a uno, que pueden estar * tanto conectados a una entrada como a una salida. */ diff --git a/Model/include/plantitem.h b/Model/include/plantitem.h index 25b7eb2..ff35727 100644 --- a/Model/include/plantitem.h +++ b/Model/include/plantitem.h @@ -26,7 +26,6 @@ public: * \param _name Nombre único que identifica el objeto */ PlantItem(const std::string &_name); - /// FIXME : agregar el nombre! PlantItem(unsigned ins, unsigned outs); /// Destructor virtual ~PlantItem(); @@ -64,8 +63,8 @@ public: MSG_QUERY_MAX_FLOW_OUT = IConector::MSG_LAST, ///< flujo maximo a la salida MSG_QUERY_MAX_FLOW_IN, ///< flujo maximo a la entrada MSG_RESPONSE_MAX_FLOW, ///< responde al mensage QUERY_MAX_FLOW. data == float - MSG_QUERY_COLOR, - MSG_RESPONSE_COLOR, + MSG_QUERY_COLOR, ///< Consulta por el color del elemento adyacente + MSG_RESPONSE_COLOR, ///< Recibe una respuesta sobre color MSG_LAST };