X-Git-Url: https://git.llucax.com/z.facultad/75.42/plaqui.git/blobdiff_plain/f935b3a37c3134004ec41eeea5dd1f6571804f81..44617167ac216781537290dce9cc097df89dc3d2:/Model/include/documentation.h?ds=sidebyside

diff --git a/Model/include/documentation.h b/Model/include/documentation.h
index cdd68e5..48cd4f6 100644
--- a/Model/include/documentation.h
+++ b/Model/include/documentation.h
@@ -6,6 +6,18 @@
 	(<tt>plaqui-model</tt>) o como una biblioteca estática y ser compilado dentro de un
 	ejecutable como lo hace PlaQui Server.
 
+	No se utilizó el modelo de grafo para resolver el enunciado ya que presentaba
+	varias limitaciones importantes, y no hacía que la solución sea más simple.
+	Como primer desventaja se tenía que en el grafo cada elemento era representado
+	por un vértice, menos los conductos que eran aristas, lo que hacía que el
+	objeto grafo sea el único objeto en el modelo. Esto implicaba tener una <em>super</em>
+	clase que hacía todo el trabajo y la idea de POO es descentralizar y reutilizar.
+
+	Por otro lado, y más importante aún, el modelo del grafo no permitía tener múltiples
+	circuitos independientes simulados al mismo tiempo. El enfoque utilizado permite
+	, como se muestra en el ejemplo 2_circuitos.xml, simular <em>n</em> plantas al mismo
+	tiempo, y conectar unas a otra mediante la lógica de control.
+
 	\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 PlaQui::Model::Simulator que es quien se encarga
@@ -58,7 +70,7 @@
 		\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 \ref PlaQui::Model::PlantItem::update_color "color".
-			Entonces, por ejemplo, una union pide un color a cada salida y luego los suma.
+			Entonces, por ejemplo, una unión pide un color a cada salida y luego los suma.