Characteristics of mathematical modeling languages that facilitate model reuse in systems biology: a software engineering perspective

Abstract

Reuse of mathematical models becomes increasingly important in systems biology as research moves toward large, multi-scale models composed of heterogeneous subcomponents. Currently, many models are not easily reusable due to inflexible or confusing code, inappropriate languages, or insufficient documentation. Best practice suggestions rarely cover such low-level design aspects. This gap could be filled by software engineering, which addresses those same issues for software reuse. We show that languages can facilitate reusability by being modular, human-readable, hybrid (i.e., supporting multiple formalisms), open, declarative, and by supporting the graphical representation of models. Modelers should not only use such a language, but be aware of the features that make it desirable and know how to apply them effectively. For this reason, we compare existing suitable languages in detail and demonstrate their benefits for a modular model of the human cardiac conduction system written in Modelica.

Fig. 1. Simple variable definition with assignment rule in three modeling languages with different levels of focus on human- versus machine-readability.

Each of the three code snippets contains the same information defining a variable y, which depends on another preexisting variable x. Antimony mainly focuses on how humans would write equations in text form, but requires a specialized parser. CellML Text—an intermediary editing language used by the tool OpenCOR—adds some syntax that is easy to parse by a machine (due to using braces that do not conflict with other symbols in the code), but is not an intuitive representation of unit information for a human unfamiliar with the language. SBML focuses more on machine-readability, since XML can be parsed by the standard libraries of most modern programming languages, ensuring minimal barriers for tool support. However, while the SBML code is still readable and editable in a text editor, it takes some effort and familiarity with the language to decipher the meaning from the symbols.

Fig. 2. Simple predator-prey model in a language without (PyDSTool) and with (Modelica) support for documentation strings.

a While regular Python comments (#) can be used to annotate PyDSTool models, they are ignored by the compiler and are only useful when reading the code directly. b Modelica comments are part of the model syntax and can therefore be read by tools to, e.g., provide automated tooltips in dialogs and graphs or to enrich model summaries in databases.

Fig. 3. Definition of a discrete variable x_max in a language with (Modelica) and without (Antimony) support for declaring discrete variables.

The variable x_max captures the peak value of the continuous variable x obtained within two seconds after an event event. a The Modelica model defines a discrete boolean variable in_window, to simplify the when condition later in the code. The information that this variable is discrete already lies in the type definition as Boolean. For real variables like x_max, there exists a keyword discrete, which determines that the variable value may only change within a when equation. b The same model structure and semantics can also be achieved in Antimony, but the discrete variables in_window and x_max each need an explicit rate rule to ensure that their value only changes when an event occurs (lines 3 and 8). Additionally, two events are needed to emulate the boolean variable in_window: One to update the value when the condition becomes true (line 4) and one to do so when it becomes false (line 5).

Fig. 4. Two different ways in which modeling languages can support graphical representations of models as part of their syntax.

a CellML allows to include diagrams or plots as figures in the model documentation. The image files remain separate from the model code and have no semantic connection to it except for the figure caption. b Modelica allows to add graphical annotations using a vector graphics syntax. Models and their components can have icons graphics (//(1)), which can be placed in a diagram coordinate system (//(2)) and connected with lines (//(3)). This graphical representation is tied to the structure of the model. If, e.g., a component is removed from a model, the placement annotation (//(2)) must also be removed, which automatically updates the diagram and ensures that it still accurately reflects the new model structure.

Fig. 5. Diagram of the modular conduction model with symbols for the components.

Components from left to right: Pacemaker for the pacemaker effect of the AV node, RefractoryGate for the refractory behavior of the SA node and AVConductionDelay for the combined delay between the SA node and the ventricles. The C in a black box indicates that the main variable of the component is held constant while the stopwatch symbol for the delay should indicate that the duration is time-dependent. Components have their input on the left, their output on the right and the pacemaker has the additional reset input at the bottom.

Fig. 6. Diagram of the extension of the modular conduction model with a trigger for (PVCs).

The components are the same as in Fig. 5 with additional components and connections highlighted in blue: reset inputs, second RefractoryGate (right) for the refractory period of the ventricles, two logical OR gates and one AND gate. The letters on the outside of the rectangle represent the connections of the model to the outside world: the input from the SA node (S), the output to the ventricles (V) and the trigger signal for PVCs (PVC).