Model checker Mudi

The main use case considered for the model checker Mudi is to validate a given computational model relative to a PBLSTL specification describing how both numeric and spatial properties are expected to change over time. Other use cases considered include choosing the model checking algorithm (see Table 2.1) and the maximum tolerated model checking approximation error, and providing as input the maximum number of minutes to wait for new STML files to be generated and the paths to the file containing the PBLSTL specification, the folder containing STML files and the script used to generate STML files on demand (see Algorithm 2). A graphical description of the use cases is given in Figure 3.8 as a Unified Modelling Language (UML) use case diagram.

The architecture of Mudi was designed to be modular and is conceptually separated into the model checking and the inference engine layers as depicted in Figure 3.9. The main advantage of this design choice is that changes of the model checking layer do not require updates of the inference engine layer and vice versa.

The model checking layer comprises all model checking approaches supported by Mudi. Independently of the chosen model checking approach the same inference engine is employed to evaluate formal PBLSTL statements against executions

Figure 3.8: Use case diagram for multidimensional spatio-temporal model checking using the model checker Mudi. The user can validate a computational model relative to a PBLSTL specification de- scribing how both numeric and spatial properties are expected to change over time. The validation of the computational model relative to a PBLSTL specification includes choosing the model checking algorithm and the maximum tolerated model checking approximation error, and providing as input the maximum number of minutes to wait for new STML files to be generated and the paths to the file containing the PBLSTL specification, the folder containing STML files, and the script used to generate STML files on demand. Conversely the model checker Mudi employs the model checking algorithm cho- sen by the user to verify if a PBLSTL specification holds for the computational model considered. The validation of the computational model includes evaluating the PBLSTL specification against STML files and outputting the model validation results. The evaluation of the PBLSTL specification against STML files includes parsing the PBLSTL specification, checking if the STML files are syntactically correct and generating STML files on demand.

of the model considered. For explanatory purposes the integration of the model checking approaches, and the PBLSTL logic property parser and evaluator is described by the UML class diagram in Figure 3.10.

For both efficiency and cross platform compatibility purposes Mudi was im- plemented in C++. The current version of the model checker was designed to be executed only from the command line. The user chooses the desired model checking algorithm and enters the required parameters via command line flags; run Mudi with the “--help” command line argument for more details. The model checking approaches supported were implemented without any external library dependencies. Conversely the PBLSTL logic property parsing and evaluation

Chernoff-Hoeffding

bounds Frequentiststatistical Probabilisticblack-box Bayesian mean

and variance estimate Bayesian statistical

Model checking

PBLSTL logic

property parser property evaluatorPBLSTL logic

In

fer

ence engine

Figure 3.9: The modular architecture of Mudi comprises the model checking and inference engine layers. The model checking layer contains all model checking approaches supported by Mudi. Con- versely the inference engine layer consists of the PBLSTL logic property parser (considering the BLSTL syntax) and evaluator (considering the BLSTL semantics). Every model checking approach supported by Mudi employs the PBLSTL logic property evaluator to determine if PBLSTL logic properties hold for executions of the model considered.

modules depend on the Boost Spirit C++ parser generator library (Guzman and Kaiser, 2015). The main reason for choosing this specific parser generator as opposed to more established ones (e.g. Bison and yacc) is its ability to generate the parser and construct the abstract syntax tree corresponding to the logic property using inline C++ code. Parsers generated with this library are top-down recursive descent.

Mudi was implemented as an offline model checker and takes as input model simulation traces (i.e. time series data) rather than computational models. The offline model checking approach has two main advantages. First of all the model checker implementation is decoupled from the specific modelling formalisms em- ployed to encode the computational models. Consequently Mudi can be employed to verify computational models encoded using various modelling formalisms pro- vided that the corresponding computational models satisfy the constraints of an SSpDES model. Secondly Mudi can be employed to evaluate PBLSTL specifica- tions against time series data recorded both during in silico model simulations and in vitro experiments. Therefore the model checker can be employed for systems biology applications to check if executions of computational models match observa- tions of the real-life systems they encode, and for synthetic biology applications to check if the behaviour of synthetically engineered biological systems matches the

Figure 3.10: Class diagram corresponding to the model checking approaches considered (see Ta- ble 2.1), and the PBLSTL logic property parser and evaluator. The ModelCheckingManager class is employed to run the model checking tasks. It stores a collection of (PBLSTL) logic properties rep- resented as strings of characters, and a collection of paths to STML files. For each logic property considered a separate model checker instance is created (e.g. StatisticalModelChecker) using a model checker factory class (e.g. StatisticalModelCheckerFactory) corresponding to the model checking ap- proach chosen by the user. The supported model checking approaches and corresponding factories are implemented in classes which realize the ModelChecker, respectively the ModelCheckerFactory inter- face. An instance of a model checking class can be used to evaluate a logic property, represented as an instance of the AbstractSyntaxTree class, relative to a given execution of the model, represented as an instance of the SpatialTemporalTrace class. The classes used to encode the model checking approaches correspond to the model checking layer in Figure 3.9. To evaluate logic properties, the logic properties need to be first parsed to check if they are syntactically correct using the Parser class, which corresponds to the PBLSTL logic property parser in Figure 3.9. If the PBLSTL logic prop- erty is syntactically correct then it is stored as an instance of the AbstractSyntaxTree class and can be evaluated against executions of the model considered (i.e. spatio-temporal traces). Therefore the AbstractSyntaxTree class corresponds to the PBLSTL logic property evaluator in Figure 3.9.

in silico predictions of the computational models employed for their design. Con- versely the main disadvantage of implementing Mudi as an offline model checker is efficiency, because model simulation traces cannot be generated on-demand, in-memory and potentially stopped early. Moreover the model simulation traces need to be stored and loaded from disk which leads to increased model checker execution times.

To check for the presence of bugs in the implementation of Mudi both black- and white-box testing was employed. Unit tests were implemented using the Google

Test unit testing framework (Google, 2015) and covered all the main functionalities of the model checker, namely parsing, evaluation and model checking. The case studies considered in the unit tests were illustrative examples chosen for validation purposes and were not derived from experimental studies or the literature. As per the principles of test-driven development unit tests were typically written first, and then the corresponding features were implemented such that the unit tests executed successfully. Moreover when releasing a new version of Mudi the minimum requirement was that all unit tests needed to execute successfully.