The internal division into mathematical and visual models was done to avoid mixing unrelated responsibilities of the classes. The mathematical model describes all the semantics, it checks model integrity, tells whether some operation is possible/valid (connection, simulation, etc.). It knows nothing about the visual model presenting it. In future versions there might be several different visual presentations showing different aspects of the same mathematical model.
Visual model provides manageable interface between user and both the mathematical and the visual model, allowing the user to do changes. The visual model classes know how to draw/present the model, keep information such as colors, pattern, etc. (as long as this information is presentation only and irrelevant to the semantics).
Deserialisation of models relies on reflection and requires on presence of appropriate constructors, therefore:
MathModelinterface must implement a constructor with two parameters:
(Container root, References refs).
VisualModelinterface must implement a constructor with the following parameters:
(Graph model, VisualGroup root).
VisualNodeinterface must implement a constructor with a single parameter: