Principles of the solution
One reason for live feedback requirement is a need to allow users to modify a definition of any modular model and to see what is the impact on the resulting model immediately after each change. Furthermore, user needs to see not only changes made in the topmost model itself, but also changes in any module or module of the module etc. Finally, the same applies also for replacing one module by another or adding new module to existing model.
To help a user get the live visual feedback for any made changes, graphical user interface of such modular modeling tool would consist of two separate views. A left view used for defining models and the right view for providing results. Both views use models displayed as diagrams. Such user interface has been implemented for the tool based on OpenPonk.
These results and outputs are updated every time the user makes any kind of change, thus providing the live feedback. The user can select any model on the left and any model on the right, thus can make changes to a concern and watch how it affects the resulting model, or can switch concerns that the model integrates and immediately see what is the impact on the model.
Although the solution focuses on diagrams, not all models are made with diagramming in mind. If the user works with an API or a DSL, there might not be a way to undo some changes in existing instances of the model without modifying and re-evaluating all the code again, thus creating completely new instance of a model. For the use case of live diagramming, more incremental updating is required. For example, in Kendrick, even during interactive sessions, once a concern (module) is integrated into a model, there is no way to undo the integration other than rebuilding the whole model. Furthermore, the integration may even make changes to the integrated concern instance, thus changing even the diagram of that concern. One way to overcome such issues is to heavily modify such modeling system and its DSL to accommodate for these needs of live diagramming. However, such extensive changes might not always be possible or preferable for all backend systems. This solution proposes to create intermediate, diagram-friendly models, which are used by the diagramming tool for defining the model on the left side of the screen and displaying the composition results on the right side. Models created especially for defining models on the left side of a screen are called definition models and those created to display results on the right side of a screen are called resulting models. Single set of diagram-friendly models might be used for both defining and displaying results, but there might be a need for separate definition models and resulting models. In case of Kendrick, a single model suffices at the current state of implementation.
The case study tool is based on OpenPonk not only by inspiration, but also by directly subclassing and using parts of the existing OpenPonk infrastructure. That way proved that this solution can be applied for tools derived from already existing ones. OpenPonk classes are used as a base for most of aspects of the tool, specifically model elements, projects, controllers and user interface. Most of classes used for the solution are subclasses of OpenPonk core abstract classes and some of them even subclasses of OpenPonk finite state machine classes, especially those used for Kendrick. If needed, even completely custom classes may be used, if they provide similar functionality.
How such extension of OpenPonk has been made, along with usage for Kendrick, is shown in figure below.
To connect definition and resulting models while extending and composing models, new kind of model elements have been created. These elements are called links in this work and can be used as parts of a model just as any other element. Links do not have any identity on their own, but provide a reference from the definition model to the resulting model or its elements. Such links are used only in definition diagrams and never appear in resulting ones. These links can have various semantics and impact on the model they are created in.
There are two kinds of links – module links, which reference resulting model itself as a whole and element links, which reference a single element (or a relationship) in one of linked modules. Adding a module link to the diagram provides an information that this model extends or is composed of another one and simply adding such link may change the resulting model. Element links, on the other hand, do not change any result on its own and the information about just adding such link to the diagram is not even forwarded to the external model in any way. All such links, however, can have attributes on its own. For example, Kendrick models have API for delaying transitions between states and when such transition is delayed, there is another state created and put between original ones and original transition is replaced by new ones. Element links do have necessary attributes for this delay, specifically name of new state and probability of new transition, which user can fill in. Also, to add a new state and create a transition from old state to new state, a user creates a link to the state from extended model, a new state in current model and a transition from the link to the new state. Although such semantics of links are used as default in the tool and are used for Kendrick in the exactly same way, meaning of adding a link to the definition model can be altered so that even adding a module link does not mean anything or adding an element link does. Also, by default, only one module link to a single resulting model should be created, but it needs to be altered for subclasses of systems with hierarchical models.
Whenever a user makes any change, the tool calls a bridge component, which handles communication with the execution back-end (for e.g. Kendrick). The bridge provides external models and other outputs from definition models and then provides resulting models from external models. External model is usually an instance of a class of the execution back-end, but can be provided by the back-end even in other forms like XML. One example of external model is an instance of KEModel or KEModelPart. Such external models cannot be directly modified by a user or the tool itself – only by the bridge. Simulations and other outputs provided by the back-end are saved in the resulting model and then used by user interface. Bridge is called after a change in definition models that are displayed as diagrams on the left side of GUI and can be changed from different sources (including a user). Resulting models are displayed on the right side of GUI and cannot be changed, only replaced by the project when bridge creates new ones.
To explain it further, let’s use Kendrick concerns as an example. If the user makes a change in a definition diagram for Kendrick “SIR” concern (model part), the bridge creates an instance of the Kendrick model part with all the information from the diagram. Then it goes on to create the resulting diagram from this Kendrick model. If there are any links to original “SIR” resulting model, it means that there are dependent models or model parts.
Since new resulting diagram has been generated, the old one is replaced by this new one in the project and in user interface. If there are no depending models, updating requires no further action of the project or views. However, if there are any depending definition models, their links now point to the old, already replaced model and its elements. In this case, if there is for example a “SEIRS” concern defined as extension of “SIR”, all links in “SEIRS” definition model need to be updated to point to this new model. The bridge takes the new resulting model with same name as the model to which the module link is pointing to now and switches these models in the link. Right after that, element links in “SEIRS” definition model are updated in a similar way to point to elements of this new resulting “SIR” diagram by searching for elements with same names as previous ones. Since updating links is in fact change of the “SEIRS” model, its resulting model needs to be updated too, so after updating links, the whole process is repeated for this depending model (“SEIRS” model in this example). This is all recursively repeated for all depending models, so if any concern or model depends on this “SEIRS” model, its links get updated and new resulting model is generated too.
In the case of relationships without names, those are linked by names of source and target elements. Similarly, any other kind of attribute or structure might be used for such identification, but such alternatives have not been fully explored during designing this solution and therefore are not even directly supported by current state of the implementation.
As a last step, the project asks the bridge for resulting diagrams that were removed or created and replaces old ones by new ones in the user interface.
In the example of “SIR” and “SEIRS” concerns, original tabs with their resulting diagrams are replaced by new ones. A setback of this way of updating is that the tool does not remember which element has been selected (clicked-on) by the user, nor even changes to their layout on the canvas done by dragging them to new positions. Most important steps of this process are shown in figure below. Note that this figure does not show that the whole process repeats for the “SEIRS” definition diagram.
While updating links to new model, there may not be any corresponding element, or even whole model, to link to. The model or element could have been removed or renamed. In that case, bridge points these links to broken reference objects, causing no resulting model to be generated in the bridge until the model object required by the link reappears or after a user fixes the problem by providing name of new model object to link to. Links pointing to broken references are further called invalid and model object are called validly linkable to if a link is valid if it points to that object. Example of links with invalid references is shown in figure below.
If a resulting model is not generated, it is instantly removed from the right side of the user interface. When all problems get fixed and resulting model is generated again, it reappears on its original position. Links are considered invalid in a few more cases.
First one occurs when element it links to does not have a name. Such element is not considered as a valid object to link to, because it might not be findable after generating new resulting models. In some kinds of models, such elements might not be valid even in the external back-end model and for that reason, do not even become part of resulting models.
Another one occurs if the link depends on another link on the same definition model, but that link gets invalid. There can be four main reasons for that:
- Link to relationship is invalid if source or target element cannot be validly linked to (does not have a name in case of original elements or is invalid in case of links)
- Link to any object is invalid if link to its whole model is invalid. For example, if there is a link to “SIR” model and link to state “S” from the “SIR” model and then the link to “SIR” becomes invalid, even link to state “S” becomes invalid.
- Link to any object is invalid if link to its container is invalid. This is, however, generalization of second one, because even whole model (diagram) itself is specific case of container.
- If user manually reconnects the link (in the case study tool it can be done by writing different name), the link gets immediately linked to a broken reference object with that name specified by user no matter if any element with such name exists, because it is not role of the model to search in other models for such linkable elements, or even search in project for other models. Renamed link notifies project (possibly by announcement), which calls a bridge to update links. Remember here that when links are updated, it is considered a change and whole resulting model generation process begins. This is the only case where links are updated before any creation of resulting models happens, along with the moment when new definition model is added to the project.
While bridge updates links, it, therefore, does not just relink current valid links to model objects from new resulting models that replaced old ones, but also relinks invalid links to new resulting models if the proper model object starts to exist and it also, as stated above, may relink valid links to broken references, thus making the link invalid.
This text and images are based on a master's thesis of Jan Blizničenko:
Blizničenko, Jan. Live Visualization of Epidemiological Models. Master’s thesis. Czech Technical University in Prague, Faculty of Information Technology, 2017.