From c8ee011d14ae8e574791d0f4cc852cf6cf2ab96c Mon Sep 17 00:00:00 2001 From: Ricardo Markiewicz Date: Tue, 2 Dec 2003 06:32:05 +0000 Subject: [PATCH] =?utf8?q?=20Me=20tiro=20flores=20en=20el=20dise=C3=B1o=20?= =?utf8?q?del=20modelo=20y=20tiro=20abajo=20el=20modelo=20del=20grafo=20:-?= =?utf8?q?D?= MIME-Version: 1.0 Content-Type: text/plain; charset=utf8 Content-Transfer-Encoding: 8bit --- Model/include/documentation.h | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/Model/include/documentation.h b/Model/include/documentation.h index cdd68e5..36cc4c1 100644 --- a/Model/include/documentation.h +++ b/Model/include/documentation.h @@ -6,6 +6,18 @@ (plaqui-model) 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 super + 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 n 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 -- 2.43.0