Advertisement

Journal of Membrane Computing

, Volume 1, Issue 4, pp 241–250 | Cite as

Search-based testing in membrane computing

  • Ana Ţurlea
  • Marian GheorgheEmail author
  • Florentin Ipate
  • Savas Konur
Regular Paper
  • 57 Downloads

Abstract

Search-based testing is widely used for generating test sets. It is also applied in the case of model-based testing, especially for (extended) finite state machines. In this paper, we define such an approach for kernel P system models. We consider a specific kernel P system model and a define a search-based testing method. The test set generated consists of input sequences producing a given computation defined by the model. An example illustrates the use of the introduced method.

Keywords

Membrane computing Kernel P systems Search-based testing Genetic algorithms Test data generation 

1 Introduction

Membrane computing represents a nature-inspired computing paradigm. Its models are called membrane systems or P systems [1]. This research was introduced by Gheorghe Păun in a seminal technical report [2] and then published as a journal paper [3]. The initial model was inspired by the structure and functioning of the living cells, but then other more complex biological structures have been considered and different phenomena utilised in defining new variants.

Another line of research is represented by the study of membrane systems of a more expressive power obtained by bringing together the features of different membrane models with the aim of providing a generic computing framework that allows to formally specify and analyse models derived from various systems and applications. One such membrane computing model is kernel P systems (kP systems, for short), introduced in [4, 5]. kP systems are widely used in various applications, ranging from systems and synthetic biology to engineering applications [6, 7, 8, 9, 10, 11, 12]. It allows models to be simulated and formally verified using third party model checkers using a software framework, called kPWorkbench [13]. This integrated software platform benefits from a specification language, called kP-Lingua allowing the simulation of the systems using either its own native simulator or the agent-based FLAME high-performance simulation environment [14, 15].

In parallel with these developments for kP systems, given the need to check that applications derived from such models are correct, some testing strategies have been considered. Conformance testing methods have been developed aiming to check that the implementation behaves in accordance with its specification, a kP system model, otherwise faults have to be identified and revealed. The testing approach has to consider difficulties posed by parallel and non-deterministic models.

So far, P system-based testing has been considered in the context of linking P system models with other computational models benefiting from testing approaches. Cell-like P system testing has been derived from testing methods based on finite state machines [16], stream X-machines [17], mutation testing [18], model checking-based testing [19] and testing identifiable kP systems using X-machines [20, 21].

Automated test data generation is one of the topics of great importance in software validation. The process of test data generation can be linked with the code or a model of it. Search-based testing [22], using evolutionary methods, is widely used for generating test data sets, but not yet considered in the case of membrane systems.

This paper presents a testing approach aimed at generating test data consisting of input data for models based on a special class of kP systems. The test sets are generated using genetic algorithms.

The rest of the paper is structured as follows: the basic kP systems concepts and search-based testing for extended finite state machines are introduced in Sect. 2. Section 3 introduces some constraints on kP systems used for testing, and describes the genetic algorithm used in this context and the experimental results obtained for a case study. Section 4 summarises the conclusions and presents our future work.

2 Preliminaries

In this section, the basic concepts and main definitions related to kP systems are introduced. The basic idea of search-based testing for extended finite state machine (EFSM, for short) models is presented.

2.1 Kernel P systems

The formal definition of kP systems [4] is introduced below. Before this, we need to introduce some preliminary concepts such as compartment type which is utilised for defining the compartments of a kP system.

Definition 1

T is a set of compartment types, \(T=\{t_1, \ldots , t_s\},\) where \(t_i=(R_i, \sigma _i)\), \(1 \le i \le s\), consists of a set of rules, \(R_i\), and an execution strategy, \(\sigma _i\), defined over \(Lab(R_i)\), the labels of the rules of \(R_i\).

Definition 2

A kP system of degree n is a tuple \(k\varPi = (A, \mu , C_1, \ldots , C_n, i_0)\), where
  • A is a finite set of elements called objects;

  • \(\mu\) defines the membrane structure, which is a graph, (VE), where V (vertices of the graph) represents the finite set of components (compartments) of the kP system, and E (edges of the graph) is the finite set of links between components;

  • \(C_i = (t_i, w_{i,0})\), \(1 \le i \le n\), is a compartment of the system consisting of a compartment type, \(t_i\), from a set T and an initial multiset, \(w_{i,0}\) over A;

  • \(i_0\) is the output compartment where the result is obtained.

In every kP system, one can have the following evolution rules:
  • Rewriting and communication rules: \(x \rightarrow y \{g\}\), where \(x \in A^{+}\), \(y = (a_1, t_1) \ldots\)\((a_h, t_h)\), \(h \ge 0\), and for each \(1 \le j \le h\), \(a_j \in A\) and \(t_j\) indicates a compartment type from T; g is a guard. The format of a guard will be presented below.

  • Structure changing rules, such as membrane division, membrane dissolution, link creation and link destruction rules. These are presented in detail in [4] and will not be considered in this paper.

For a multiset w over A and an element \(a\in A\), we denote by \(|w|_a\) the number of objects a occurring in w. Let us denote \(\mathrm{Rel}=\{<, \le , =, \ne , \ge , >\}\), the set of relational operators, \(\gamma \in Rel\), a relational operator, and \(a^{n}\) a multiset, consisting of n copies of a. We first introduce an abstract relational expression.

Definition 3

If g is the abstract relational expression denoting \(\gamma a^n\) and w a multiset, then the guard g applied to w denotes the relational expression \(|w|_a \gamma n\).

The abstract relational expression g is true for the multiset w, if \(|w|_a \gamma n\) is true.

We consider now the following Boolean operators \(\lnot\) (negation), \(\wedge\) (conjunction) and \(\vee\) (disjunction). An abstract Boolean expression is defined by one of the following conditions:
  • any abstract relational expression is an abstract Boolean expression;

  • if g and h are abstract Boolean expressions then \(\lnot g\), \(g \wedge h\) and \(g\vee h\) are abstract Boolean expressions.

The concept of a guard, introduced for kP systems, is a generalisation of the promoter and inhibitor concepts utilised by some variants of P systems.

Definition 4

If g is an abstract Boolean expression containing \(g_i,\)\(1\le i \le q,\) abstract relational expressions and w a multiset, then g applied to w means the Boolean expression is obtained from g by applying \(g_i\) to w for any \(i, 1\le i \le q\).

As in the case of an abstract relational expression, the guard g is true with respect to the multiset w, if the abstract Boolean expression g applied to w is true.

2.2 Search-based testing for EFSM models

Search-based testing is used for generating test data mainly starting from the code, but it is also applied to models for deriving these tests. In the sequel, we refer to a widely spread model used in testing, namely extended finite state machine.

Definition 5

An extended finite state machine (EFSM) is a six-tuple (S\(s_{0}, V,\)IOT) [23] where
  • S is the finite set of states,

  • \(s_{0}\) is the initial state,

  • V is the finite set of context variables,

  • I is the finite set of inputs,

  • O is the finite set of outputs and

  • T is the finite set of transitions. A transition is represented by a start state and an end state, an input that may have associated input parameters, a guard (logical expression) and a sequential operation (a method with assignments and output statements).

A transition from state \(S_1\) to \(S_2\), denoted \(S_1 \xrightarrow {f_1[g_1]} S_2\), consists of a method to be executed, \(f_1\), and a guard, \(g_1\).

Definition 6

A path of an EFSM is a sequence of adjacent transitions, \(p = S_1 \xrightarrow {f_1[g_1]} S_2 \xrightarrow {f_2[g_2]} \dots S_m \xrightarrow {f_m[g_m]} S_{m+1}\). A path is called feasible, when there exist values for the input parameters to satisfy guards and to trigger all transitions for that path, and infeasible, otherwise.

For a given path p, one of the problems in testing based on EFSM is that of finding input values satisfying the guards along the path. The use of search-based testing has been investigated in [24] using search techniques such as simulated annealing, genetic algorithms and particle swarm optimisation. Kalaji et al. [23] proposed an integrated search-based test data generation instead. Lefticaru and Ipate [25] proposed an approach in two steps. In the first step, all the feasible paths to achieve some coverage criteria are identified. In the second step, for each path, the input values for parameters occurring in guards and triggering each transition of the path are obtained. [26] generates test data for EFSMs using a hybrid genetic algorithm, which is an improvement from the approach presented in [25]. In these approaches, the test data generation problem is converted to an optimisation problem.

Genetic algorithms (GAs) are metaheuristic search techniques, mainly applied in optimisation problems. They are inspired by evolutionary biology using a few concepts, such as populations of chromosomes—these are individuals, selection according to a fitness function, crossover to produce new offspring and random mutation of such offspring [27].

GAs start with an initial population consisting of random candidate solutions. The population will evolve until a solution is found. Each element of the population, the chromosome, is defined by some variables/parameters. These variables take values from a given set.

During the evolution process, certain operations are applied to the population of chromosomes with the aim of optimising a fitness function. The key operations used, crossover and mutation, are briefly presented below.

Crossover is applied to the randomly selected parent chromosomes, by exchanging information and generating children with newly obtained features. The most used chromosome crossover operations are: single-point crossover, multi-point crossover and uniform crossover.

Mutation is applied, with some probability, to each chromosome, by randomly changing the values of some genes. The main purpose of the mutation operation is to create diversity in the population and to prevent the evolution process from stopping too early.

A generic schema of a population evolving follows the steps below [27]:
  1. 1.

    An initial population is randomly generated.

     
  2. 2.

    The fitness function is evaluated for each chromosome in the population.

     
  3. 3.
    The following steps are repeated until a stopping condition is met or the maximum number of generations is obtained.
    1. (a)

      Select a pair of parent individuals from the current population.

       
    2. (b)

      Apply crossover to the current pair to form two offspring.

       
    3. (c)

      Mutate the two offspring chromosomes, with a given probability, and place the resulting individuals in the new population.

       
     
  4. 4.

    Selection is applied on the current population along with the new population.

     
  5. 5.

    Using the newly evolved population go to step 2.

     
For a particular path in the EFSM, a chromosome (individual, possible solution) is given by a list of values, \(x = (x_1, x_2, \dots , x_n)\). The components of the list correspond to the parameters that appear along the path. A solution is given by a chromosome with the fitness function 0. This solution triggers the transitions occurring on the path, making the guards true.
The fitness function used in this approach is:
$$\begin{aligned} \mathrm{Fitness} = \mathrm{Approach\_level} + \mathrm{Normalized\_branch\_level} \end{aligned}$$
(1)
in short, \(f = al+nbl\). We have \(\mathrm{approach\_level}\) calculated by \(m - 1 - p\), where m is the length of the path to be executed and p is the number of nodes executed until the first unsatisfied guard on the path occurs. \(\mathrm{normalized\_branch\_level}\) is the mapping onto [0, 1) for \(\mathrm{branch\_level}\). \(\mathrm{branch\_level}\) computes, for the predicate that is not satisfied, how close the predicate was to being true, using the transformations from Table 1. The normalisation function is \(\mathrm{norm}: [0,101] \rightarrow [0,1], \mathrm{norm}(d) = 1 - 1.05^{-d}\).
Table 1

Tracey’s objective functions for relational predicates and logical connectives

Element

Objective function value obj

Boolean

if TRUE then 0 else K

\(a = b\)

if \(\mathrm{abs}(a - b) = 0\) then 0 else \(\mathrm{abs}(a - b) + K\)

\(a \ne b\)

if \(\mathrm{abs}(a - b) \ne 0\) then 0 else K

\(a < b\)

if \(a - b < 0\) then 0 else \((a - b) + K\)

\(a \le b\)

if \(a - b \le 0\) then 0 else \((a - b) + K\)

\(a > b\)

if \(b -a < 0\) then 0 else \((b - a) + K\)

\(a \ge b\)

if \(b - a \le 0\) then 0 else \((b - a) + K\)

\(a \wedge b\)

\(\mathrm{obj}(a) + \mathrm{obj}(b)\)

\(a \vee b\)

\(\mathrm{min}(\mathrm{obj}(a), \mathrm{obj}(b))\)

\(a \ xor \ b\)

\(obj((a \wedge \lnot b) \vee (\lnot a \wedge b))\)

\(\lnot a\)

Negation is moved inwards and propagated over a

The value K, \(K > 0\), refers to a constant which is always added if the term is not true

3 Search-based testing for kP systems

In this paper, we will introduce a variant of kP systems with states that will allow us to model systems in a way very close to EFSMs, but offering the flexibility of using other features of kP systems. This version of kP systems uses states in a manner similar to hyperdag P systems [28] or the more recently investigated cP systems [29].

In the sequel, we will consider only deterministic kP systems with states and two compartments.

In the main compartment, the rules will be of the form \(Aa \rightarrow Bb \{g\}\), where AB are states as in [28, 29]; ab are selected from an alphabet disjoint from states and denote input and output symbols, respectively; g is the guard of the rules. The compartment does not include any input symbol. These will be provided by the other compartment.

The other compartment acts as an environment providing inputs to the main compartment. The rules have the form \(C \rightarrow D(a,t_\mathrm{M})\), where CD are states and a is the input sent to the main compartment of type \(t_\mathrm{M}\).

The execution strategy is sequential, which means at any moment in time only one rule is executed. In fact, an input symbol from the input compartment will be sent to the main compartment and this one will execute the rule corresponding to a state and matching the input received instead, given that the guard is true. This observation is important when the test set is built using inputs in accordance with the above-mentioned constraints.

Test data for kP systems will be generated using genetic algorithms and the kPWorkbench tool will simulate the evolution of the system by moving from one state to another and performing transitions similar to an EFSM.

3.1 kP systems definition

In this subsection, we will present the formal definition of kP systems.

Definition 7

A kP system with states is a tuple \(k\varPi = (A, \mu , \mathrm{cM}, \mathrm{cInp}, i_0)\), where
  • \(\mu = (V,E)\), where \(V ={\{{\rm cM}, {\rm cInp}\}}\), \(\mathrm{cM}\) is the main compartment and cInp is the input compartment, \(E = \{(\mathrm{cM, cInp})\}\);

  • A is the set of objects, defined as \(A=A_\mathrm{ST} \cup A_\mathrm{IO}\), where \(A_\mathrm{ST}\) and \(A_\mathrm{IO}\) are two disjoint sets, \(A_\mathrm{ST}\) denotes symbols corresponding to states in the two compartments. \(A_\mathrm{IO}\) denotes the set of input and output symbols; they may be used in guards;

  • \(i_0\) denotes the label of the main compartment, cM.

The two compartments are defined as \(\mathrm{cM} = (t_\mathrm{M}, w_\mathrm{M0})\) and \(\mathrm{cInp}= (t_\mathrm{I}, w_\mathrm{I0})\), where
  • \(t_\mathrm{M} = (R_\mathrm{M},\sigma _\mathrm{M})\) is the type of the main compartment and \(w_\mathrm{M0}\) is the initial multiset over A. The main compartment type \(t_M=(R_\mathrm{M},\sigma _\mathrm{M})\) consists of a set of evolution rules, \(R_M\), of the form \(A a \rightarrow B b \{g\}\), where \(A, B \in A_\mathrm{ST}\) and \(a, b \in A_\mathrm{IO}\) and a sequential execution strategy, \(\sigma _M\).

  • \(t_\mathrm{I} = (R_\mathrm{I},\sigma _\mathrm{I})\) is the type of the input compartment and \(w_{I0}\) is the initial multiset over A. The input compartment type \(t_\mathrm{I} = (R_\mathrm{I},\sigma _\mathrm{I})\) consists of a set of rewriting and communication rules \(R_\mathrm{I}\) of the form \(C\rightarrow D (a,t_\mathrm{M})\), where \(C, D \in A_\mathrm{ST}\) and \(a\in A_\mathrm{IO}\), and a sequential execution strategy, \(\sigma _\mathrm{I}\).

Example 1

A kP system with states that models a simple ATM is provided below.

A failing attempt to access the bank account is denoted by rule \(r_1\); two wrong attempts are allowed—f stands for the wrong attempt and output a counts the attempts. If a third wrong attempt appears then the system will stop in error state (E)—as described by rule \(r_2\). A successful attempt to access the bank account is denoted by rule \(r_3\), where t stands for right attempt; immediately afterwards, the system will move to state B.

From state B, there are two options, either withdrawing from or depositing a certain amount of money into a bank account. In the first case input x is processed (rule \(r_4\)), whereas for banking, input d is processed instead (\(r_5\)). For withdrawing an amount, this is provided as a multiplicity of x (rule \(r_6\) is applied until the entire amount is extracted from the bank account); the amount in the bank account is denoted by a multiplicity of b. Similarly, the depositing operation is captured by the rules \(r_5\) and \(r_7\).

Once any of these operations is completed, either \(r_8\) or \(r_9\) will stop the process—input o signals this. This model is described by compartment cM below. Compartment cInp is meant to provide suitable inputs to cM.

Notation In this example, we will use slightly different notations that are closer to kP-Lingua than to the formal kP system definition. A multiset \(a^5\ b^{10}\) will be written as \(5a\ 10b\). When the objects that appear on the right-hand side of a rule are sent to the same compartment type, a notation \((a_1,t) \ldots (a_p,t)\) is replaced by \((a_1 \ldots a_p, t)\). When an object appears several times, then the multiplicity factor will be used. For example, instead of \((a,t)\, (b,t)\, (a,t)\), either \((2a\, 1b, t)\) or \((2a\, b, t)\) is used.

The formal definition of the kP system given by \(k\varPi _1=(A,\mu ,\mathrm{cM}, \mathrm{cInp}, i_0)\), where \(\mu\) is as in Definition 7, \(i_0=cM\), and A is the union of \(A_\mathrm{ST}=\{A,B,C,\)D\(E,F,A_1, \ldots ,A_6\}\) and \(A_{IO}=\{a,b,f,d,o,t,x\},\)
$$\begin{aligned} R_\mathrm{M}= & {} {\left\{ \begin{array}{ll} r_1: A, f \rightarrow A, a \{< 3a \& = f\} \\ r_2: A, f \rightarrow E \{ = 3a \} \\ r_3: A, t \rightarrow B, a \{< 3a \& = t \& < f\} \\ r_4: B, x \rightarrow C \{ = x\} \\ r_5: B, d \rightarrow D \{ = d \} \\ r_6: C, b, x \rightarrow C \{>= x \} \\ r_7: D, d \rightarrow D, b \{ >= d \} \\ r_8: C, o \rightarrow F \{< x \} \\ r_9: D, o \rightarrow F \{< d \} \end{array}\right. } \\ R_\mathrm{I}= & {} {\left\{ \begin{array}{ll} r_{10}: A_1 \rightarrow A_2,(f,t_M) &{} r_{11}: A_2 \rightarrow A_3, (f,t_M) \\ r_{12}: A_3 \rightarrow A_4, (t, t_M) &{} r_{13}: A_4 \rightarrow A_5, (x, t_M) \\ r_{14}: A_5 \rightarrow A_6, (3x, t_M) &{} r_{15}: A_6 \rightarrow A_7, (o,t_M). \end{array}\right. } \end{aligned}$$
The initial configuration of \(k\varPi _1\) is \(M_0 = (100b \, A, A_1)\). This means that the system will start with compartment cM in state A and have 100 units, i.e., 100b in the bank account. The other compartment, cInp, will start in state \(A_1\).

The only applicable rule in the initial configuration is \(r_{10}\) from cInp. This rule will send the input f to cM. This input denotes a wrong attempt. In this case, we have the computation step \(M_0 \Longrightarrow ^{r_{10}} (100b \, A \, f, A_2) = M_1\).

In this configuration, \(M_1\), we can only apply the rule \(r_1\) from cM and \(r_{11}\) in cInp, i.e., the wrong attempt is processed in cM and another wrong attempt is generated by cInp, hence we have the computation step \(M_1 \Longrightarrow ^{r_1, r_{11}} (100b \, A \, a \, f, A_3) = M_2\).

The next step handles the wrong attempt in cM (rule \(r_1\)); at the same time a correct attempt (use of rule \(r_{12}\) in cInp) is signalled. These two sequential executions are given by \(M_2 \Longrightarrow ^{r_1, r_{12}} (100b \, A \, 2a \, t, A_4) = M_3\).

In configuration \(M_3\), the compartment cM processes the input signalling correct attempt, t, and cInp produces the request for withdrawing, x, hence \(M_3 \Longrightarrow ^{r_3, r_{13}} (100b \; B \; 3a \; x, A_5) = M_4\). Now, the input for withdrawing is processed in cM and the amount to be withdrawn is communicated from cInp, which is 3x. This step is illustrated by \(M_4 \Longrightarrow ^{r_4, r_{14}} (100b \, C \, 3a \, 3x, A_6) = M_5\).

Now, the amount from the bank account will be decreased by 3; in each step, a pair xb will be removed from cM using \(r_6\), whereas a stop symbol, o, is generated in cInp, rule \(r_{15}\). So, we have the following steps:

\(M_5 \Longrightarrow ^{r_6, r_{15}} (99b \, C \, 3a \, 2x \, o, A_7) = M_6 \Longrightarrow ^{r_6} (98b \, C \, 3a \, x \, o, A_7) = M_7\)

\(\Longrightarrow ^{r_6} (97b \, C \, 3a \, o, A_7) = M_8.\)

In the last step, the only applicable rule is \(r_8\) which stops the process, i.e., \(M_8 \Longrightarrow ^{r_8} (97b \, F \, 3a, A_7) = M_9\).

Below we provide the steps described above as well as the rules used in each of them:
  • Step 1: rule \(r_{10}\)

  • Step 2: rules \(r_1 r_{11}\)

  • Step 3: rules \(r_1 r_{12}\)

  • Step 4: rules \(r_3 r_{13}\)

  • Step 5: rules \(r_4 r_{14}\)

  • Step 6: rules \(r_6 r_{15}\)

  • Step 7: rule \(r_6\)

  • Step 8: rule \(r_6\)

  • Step 9: rule \(r_8\)

We now use kPWorkbench, an integrated software suite [13] that is able to model and analyse the behaviour of the kP system, as the one described in Example 1. The tool includes some simulation and verification components that refer to the model specified in kP-Lingua [30]. The kPWorkbench tool includes two simulators, a native one, which allows the execution of the entire system or a step-wise approach, and the Flame simulator [14], a general purpose large-scale agent-based simulation environment. The latter is meant to allow a kP system to be expressed as a set of communicating X-machines [31] and then executed on high-performance hardware platform [32].

The verification component of kPWorkbench [33] checks the correctness of kP system models. Verification, in particular model checking, has been widely applied to the analysis of various systems [34, 35, 36, 37]. The verification process works by exhaustively analysing all possible execution paths, the verification checks if system in question meets requirements, expressed in a formal logic [38, 39, 40].

kPWorkbench provides a property language specification, called kP-Queries, which comprises a list of property patterns written as natural language statements. This is very useful for non-experts as they do not need to know the syntax of such query languages, relying on existing pre-defined patterns. The properties expressed in kP-Queries are verified using the Spin [41] and NuSMV [42] model checkers after being translated into corresponding linear temporal logic (LTL) and computation tree logic (CTL) syntax.

We can check various properties of the ATM system to verify that the model satisfies the system requirements using the verification component of the kPWorkbench tool. For example, by looking at the verification results of some informal properties, e.g.,“whenever more than two attempts fail, the system will move to the Error state”, “the account holder will eventually withdraw some money”, “the account holder cannot withdraw money without the withdrawal request”, “the account holder cannot withdraw more than his/her balance”, etc., we can say whether there errors occur in the model or not. This will allow the user to verify the correctness of the model without generating execution traces to understand the evolution of the system, which is a cumbersome process for large systems.

3.2 Algorithm configuration

The algorithm uses a kP system similar to the one in Example 1. The input of the algorithm is a configuration file containing the description of the cM compartment, \(A_{IO}\) and the initial configuration. The compartment cInp will be generated by the algorithm for each potential solution. We need to know the number of rules from cInp, which will be added to the input configuration file (in the rest of the paper we will use the notation size for this value). The number of the rules from cInp will denote the size of the set that will be generated by the genetic algorithm. To the input configuration file we also add the scenario we want to test, denoted by a set of steps for which the genetic algorithm will find the input symbols.

The output of the algorithm will be a set of input symbols with the size equal to size. These values will be used to create the cInp compartment, by adding a rule for each input. By simulating the system using the newly created input compartment, we can obtain the resulting simulation steps.

The genetic algorithm has the following steps:
  • create random initial population—length N: this population contains N potential solutions (chromosomes, individuals) that will be evolved until we find a solution.

  • evaluate the population using the fitness function: we need to evaluate each individual to find out how close it is to the solution. A solution is an individual with fitness function equal to 0.

  • repeat the following steps until the stopping condition is met (the maximum number of evolution steps is reached or a solution is found):
    • offspring population \(\leftarrow\) mutation(reproduction(population));

    • evaluate offspring population;

    • population \(\leftarrow\) reinsertion+selection(population, offspring population).

A chromosome \((x_1, x_2, \dots , x_n)\) is represented as a list of input symbols corresponding to the input set, provided for each step from 1 to n. A gene represents the input for the corresponding step and consists of a list of strings (input symbols) \(x_i = (k_1 s_1, \dots , k_n s_n)\), where \(s_i\) is a symbol from the alphabet, and \(k_i\) is the number of times the symbol appears in the input set.
The crossover operator creates two new chromosomes from the two existing parent chromosomes, using one of the two operations, with equal probability.
  • exchange only the value for a gene from a random selected point
    $$\begin{aligned} {\left\{ \begin{array}{ll} (x_1, x_2, \ldots , x_n) \\ (y_1, y_2, \ldots ,y_n) \end{array}\right. } \rightarrow {\left\{ \begin{array}{ll} (x_1, x_2, \dots , y_i, \ldots , x_n) \\ (y_1, y_2, \ldots , x_i, \ldots ,y_n) \end{array}\right. } \end{aligned}$$
  • exchange only a part of the gene for a random point
    $$\begin{aligned} {\left\{ \begin{array}{ll} (x_1, x_2, \dots , x_i, \ldots , x_n) \\ (y_1, y_2, \ldots , y_i, \dots ,y_n) \end{array}\right. } \rightarrow {\left\{ \begin{array}{ll} (x_1, x_2, \dots , x'_i, \dots , x_n) \\ (y_1, y_2, \dots , y'_i, \ldots ,y_n) \end{array}\right. } \end{aligned}$$
    where \(x_i = (r_1 s_1, \ldots , r_m s_m) , y_i = (t_1 s_1, \ldots , t_m s_m),\)\(x'_i = (r_1 s_1, \ldots , t_i s_i, \ldots , t_m s_m) , y'_i = (t_1 s_1, \dots ,r_i s_i, \ldots , r_m s_m)\)
A chromosome can be mutated in many different ways. To identify possible mutation operators, we have considered the characteristics of a chromosome. We have defined the following different mutation operators, which are all applied with 0.5 probability:
  • completely change a gene (an input value)

  • remove gene part—for an input value choose randomly a symbol that will not be used (\(k_i = 0\))

  • for a random gene—replace random symbol number (\(k_i\))

  • exchange materials between two genes

We have applied the selection operator as it is used in many test data generation approaches. The reinsertion of the offspring population into the new population is done in different ways:
  • the new population := the offspring population [25];

  • the new population := the offspring population and the fittest individual is kept in the next generation [26];

  • apply the selection operator and select N chromosomes from the offspring population along with the old population, using different selectors: best chromosome selection, binary tournament selection.

None of these methods worked for our problem. The algorithm was stuck in a local optimum. To overcome this problem, we have changed the reinsertion method: the best \(50\%\) of the current generation and the best \(50\%\) of the new offspring are retained. In the next evolution step, the crossover operator will use a parent that comes from the old population and a parent that comes from the offspring population and will create a new individual. This reinsertion method is inspired and adapted from [43].

\(P = \{x_1,y_1, x_2, y_2, \ldots , x_{25}, y_{25}\}\), where \(x_1, x_2, \ldots , x_{25} \in{{\rm Old}_{\rm Population}}\) and \(y_1,y_2,\ldots,y_{25} \in {{\rm Offspring}_{\rm Population}}.\)

To evaluate an individual, we need to compute the objective function. To verify if a chromosome is the solution, we need to simulate the system with the corresponding input values and compare the simulation traces with the given steps. The fitness function, as it appears in Eq. 1, is based on the approach level and the branch distance. It checks if the input steps are exactly the needed ones (representing a solution) or how far is the chromosome from the solution. The approach level records how many steps were not executed by a particular input. The fewer steps executed, the further away the input is from executing the steps. The branch distance is computed using the conditions of the guards of the rule at which the evolution diverted away from the current target step. To compute the fitness function, we need to perform a simulation of the system, using kPWorkbench.

3.3 Experiments

In our experiments, we have used the kP system presented in Example 1 (except for the input compartment that will be generated for each chromosome). In these experiments, we aim to execute a different sequence of steps and in each case the inputs are calculated with the method described above.

Experiment 1 consists of generating input symbols that can simulate the following scenario: the account holder will introduce at first, a wrong pin. Then, at the second attempt, the correct pin is introduced and withdrawing a certain amount of money (five units) is selected. Finally, the transaction process will stop. For this simple scenario, we can guess the inputs very easy, but for a more complex example, it might be harder just to guess them. Also, this problem might not have an unique solution.

This experiment consists in generating test data. i.e., input sequence, for the following evolution steps:

\(\mathrm{Steps}= \{r_{10}, (r_1,r_{11}), (r_3,r_{12}), (r_5,r_{13}), (r_7,r_{14}),r_7, r_7, r_7, r_7, r_8 \}.\)

This means that we want to search for the input values associated with cInp that will generate the given Steps. The size of the input set is 5. In this example, we have ten steps, but only the first six will receive inputs. The other steps will consume the inputs until the system reaches the final configuration. An example solution found by the algorithm is the set:

\(\mathrm{Inputs} = \langle 1f\, 2x, 1t, 1d, 1f\, 3x\, 3d, 2x\, 2d\, 1o \rangle\)

The associated input compartment type is:
$$\begin{aligned} R_I = {\left\{ \begin{array}{ll} r_{10}: A_1 \rightarrow A_2,(1f\, 2x,t_\mathrm{M}) &{} r_{11}: A_2 \rightarrow A_3, (1t,,t_\mathrm{M}) \\ r_{12}: A_3 \rightarrow A_4, (1d, t_\mathrm{M}) &{} r_{13}: A_4 \rightarrow A_5, (1f\, 3x\, 3d, t_\mathrm{M}) \\ r_{14}: A_5 \rightarrow A_6, (2x\, 2d\, 1o, t_\mathrm{M}) \end{array}\right. } \end{aligned}$$
The maximum number of evolutions is set to 50.

This experiment was carried out to find the suitable configuration for the algorithm, including the reinsertion method. As described in Sect. 3.2, the initial configurations failed. After running the algorithm 100 times for each configuration, we could not find a solution. Only for the new reinsertion method, the algorithm has been successful with a success rate of \(75\%\). The average number of evolutions needed to find a solution is 37.

There are many input sets that create the given scenario. Table 2 contains some examples of solutions obtained using this experiment. The first column shows the number of evolutions needed by the genetic algorithm to find the solution.
Table 2

Example of solutions for Experiment 1

Evolutions

Input1

Input 2

Input 3

Input 4

Input 5

45

\(1f\, 2x\)

1t

1d

\(1f\, 3x\, 3d\)

\(2x\, 2d\, 1o\)

41

\(1f\, 2x\)

\(1t\, 1d\)

 

\(2x\, 2d\)

\(1f\, 6x\, 3d\, 1o\)

33

1f

\(1f\, 1t\, 5x\)

\(1d\, 1o\)

5x

4d

32

\(1f\, 1t\)

1d

1x

\(1f\, 4x\, 5d\, 1o\)

1x

28

\(1f\, 1t\, 1d\)

1o

2x

\(3x\, 1d\)

\(1f\, 1x\, 4d\)

27

\(1f\, 1t\)

 

\(1d\, 1o\)

\(1t\, 2d\)

\(1f\, 3d\)

43

\(1f\, 1t\, 1x\)

3x

1d

\(2x\, 1d\, 1o\)

\(1f\, 4x\, 4d\)

Experiment 2 consists of generating the test data for other examples of evolution steps, using the configuration established in Experiment 1. One of the following evolution steps we have used is:

\(\mathrm{Steps}= \{r_{10}, (r_1,r_{11}), (r_3,r_{12}), (r_4,r_{13}), (r_6,r{14}),r_6, r_6, r_6, r_6,r_8 \}\)

The scenario associated with these steps is the following: the account holder will introduce at first a wrong pin. At the second attempt, the correct pin is introduced. Then, the user will select to withdraw a certain amount of money (five units), and will stop the transaction process.

The size of the input set is 5. In this example, we have ten steps, but only the first six will receive inputs. The other steps will consume the inputs until the system reaches the final configuration. The maximum number of evolution steps is set to 50. After running the algorithm 100 times, the success rate for this example was \(62\%\) and the average number of evolutions needed to find a solution was 36.

Using these experiments, we have established the configuration of the genetic algorithm.

4 Conclusions

In conclusion, we have used genetic algorithms as part of search-based testing to generate test data for kP systems. The algorithm input is represented by a kP system model and a set of computation steps; the output is the set of input sets needed to create the given input scenario. The algorithm uses kP systems with states that behave similar to EFSMs. Here, we have applied some genetic algorithms defined for EFSMs directly, but it was not successful. We have overcome this problem by changing the population reinsertion method. With this configuration, the algorithm was successful.

As future work, we will extend this algorithm to other kP systems where the execution strategy is not only sequential. We will apply the testing strategy derived from this approach to other examples and case studies. It will be of interest to look at other search-based testing problems, such as the identification of the computation that takes place in certain circumstances, i.e., linking two states or multisets.

Notes

Acknowledgements

The work of AT, FI and MG is supported by a grant of the Romanian National Authority for Scientific Research, CNCS-UEFISCDI, project number PN-III-P4-ID-PCE-2016-0210. The work of SK is supported by EPSRC (EP/R043787/1). The authors are indebted to the anonymous reviewers for their comments made on a previous version of the paper which have contributed to significant improvement of the current work.

References

  1. 1.
    The P systems website. http://ppage.psystems.eu. Accessed 12 May 2018.
  2. 2.
    Păun, Gh. (1998). Computing with membranes. Tech. rep., Turku Centre for Computer Science.Google Scholar
  3. 3.
    Păun, Gh. (2000). Computing with membranes. Journal of Computer and System Sciences, 61(1), 108–143.  https://doi.org/10.1006/jcss.1999.1693.MathSciNetCrossRefzbMATHGoogle Scholar
  4. 4.
    Gheorghe, M., Ipate, F., Dragomir, C., Mierlă, L., Valencia-Cabrera, L., García-Quismondo, M., & Pérez-Jiménez, M.J. (2013). Kernel P Systems - Version I. Eleventh Brainstorming Week on Membrane Computing (11BWMC), pp. 97–124.Google Scholar
  5. 5.
    Gheorghe, M., Ceterchi, R., Ipate, F., Konur, S., & Lefticaru, R. (2018). Kernel P systems: from modelling to verification and testing. Theoretical Computer Science 724, 45–60. http://hdl.handle.net/10454/11720.
  6. 6.
    Blakes, J., Twycross, J., Konur, S., Romero-Campero, F.J., Krasnogor, N., & Gheorghe, M. (2014). Infobiotics workbench: A P systems based tool for systems and synthetic biology. In Applications of membrane computing in systems and synthetic biology, emergence, complexity and computation, vol. 7, pp. 1–41. Springer International Publishing.Google Scholar
  7. 7.
    Sanassy, D., Fellermann, H., Krasnogor, N., Konur, S., Mierlă, L., Gheorghe, M., Ladroue, C., & Kalvala, S. (2014). Modelling and stochastic simulation of synthetic biological boolean gates. In 2014 IEEE International Conference on High Performance Computing and Communications, HPCC 2014, Paris, France, pp. 404–408.Google Scholar
  8. 8.
    Konur, S., Gheorghe, M., Dragomir, C., Mierlă, L., Ipate, F., & Krasnogor, N. (2015). Qualitative and quantitative analysis of systems and synthetic biology constructs using P systems. ACS Synthetic Biology, 4(1), 83–92.CrossRefGoogle Scholar
  9. 9.
    Konur, S., Gheorghe, M., Dragomir, C., Ipate, F., & Krasnogor, N. (2014). Conventional verification for unconventional computing: a genetic XOR gate example. Fundamenta Informaticae, 134(1–2), 97–110.MathSciNetCrossRefGoogle Scholar
  10. 10.
    Konur, S., Kiran, M., Gheorghe, M., Burkitt, M., & Ipate, F. (2015). Agent-based high-performance simulation of biological systems on the GPU. In 17th IEEE International Conference on High Performance Computing and Communications, HPCC 2015, pp. 84–89.Google Scholar
  11. 11.
    Gheorghe, M., Konur, S., & Ipate, F. (2017). Kernel P systems and stochastic P systems for modelling and formal verification of genetic logic gates, pp. 661–675. Springer International Publishing, Cham.Google Scholar
  12. 12.
    Lefticaru, R., Konur, S., Yildirim, U., Uddin, A., Campean, F., & Gheorghe, M. (2017). Towards an integrated approach to verification and model-based testing in system engineering. In The International Workshop on Engineering Data- & Model-driven Applications (EDMA-2017) within the IEEE International Conference on Cyber, Physical and Social Computing (CPSCom), pp. 131–138. http://hdl.handle.net/10454/12322
  13. 13.
    Dragomir, C., Ipate, F., Konur, S., Lefticaru, R., & Mierlă, L. (2014). Model checking kernel P systems. In A. Alhazov, S. Cojocaru, M. Gheorghe, Y. Rogozhin, G. Rozenberg, & A. Salomaa (Eds.), Membrane computing (Vol. 8340, pp. 151–172), Lecture Notes in Computer Science Berlin Heidelberg: Springer.Google Scholar
  14. 14.
    Coakley, S., Gheorghe, M., Holcombe, M., Chin, S., Worth, D., & Greenough, C. (2012). Exploitation of high performance computing in the FLAME agent-based simulation framework. In 14th IEEE International Conference on High Performance Computing and Communication, HPCC 2012, pp. 538–545.Google Scholar
  15. 15.
    Kiran, M., Konur, S., Gheorghe, M., Burkitt, M., & Ipate, F. (2015). Agent-based high-performance simulation of biological systems on the GPU. In 2015 IEEE 17th International Conference on High Performance Computing and Communications. pp. 84–89.Google Scholar
  16. 16.
    Ipate, F., & Gheorghe, M. (2009). Finite state based testing of P systems. Natural Computing, 8(4), 833–846.  https://doi.org/10.1007/s11047-008-9099-3.MathSciNetCrossRefzbMATHGoogle Scholar
  17. 17.
    Ipate, F., & Gheorghe, M. (2009). Testing non-deterministic stream X-machine models and P systems. Electronic Notes in Theoretical Computer Science, 227, 113–126.  https://doi.org/10.1016/j.entcs.2008.12.107.CrossRefzbMATHGoogle Scholar
  18. 18.
    Lefticaru, R., Gheorghe, M., & Ipate, F. (2011). An empirical evaluation of P system testing techniques. Natural Computing, 10(1), 151–165.  https://doi.org/10.1007/s11047-010-9188-y.MathSciNetCrossRefzbMATHGoogle Scholar
  19. 19.
    Ipate, F., Gheorghe, M., & Lefticaru, R. (2010). Test generation from P systems using model checking. Journal of Logic and Algebraic Programming, 79(6), 350–362.  https://doi.org/10.1016/j.jlap.2010.03.007.MathSciNetCrossRefzbMATHGoogle Scholar
  20. 20.
    Gheorghe, M., Ipate, F., & Konur, S. (2016). Testing based on identifiable P systems using cover automata and X-machines. Information Sciences 372, 565–578. https://doi.org/10.1016/j.ins.2016.08.028.CrossRefGoogle Scholar
  21. 21.
    Gheorghe, M., Ipate, F., Lefticaru, R., & Ţurlea, A. (2018). Testing identifiable kernel P systems using an X-machine approach. In International Conference on Membrane Computing, pp. 142–159, Springer.Google Scholar
  22. 22.
    Harman, M., & McMinn, P. (2010). A theoretical and empirical study of search-based testing: Local, global, and hybrid search. IEEE Transactions on Software Engineering, 36(2), 226–247.CrossRefGoogle Scholar
  23. 23.
    Kalaji, A. S., Hierons, R. M., & Swift, S. (2011). An integrated search-based approach for automatic testing from extended finite state machine (EFSM) models. Information & Software Technology, 53(12), 1297–1318.CrossRefGoogle Scholar
  24. 24.
    Lefticaru, R., & Ipate, F. (2008). Functional Search-based Testing from State Machines. In First International Conference on Software Testing, Verification, and Validation, ICST 2008, Lillehammer, Norway, pp. 525–528.Google Scholar
  25. 25.
    Lefticaru, R., & Ipate, F. (2007). Automatic state-based test generation using genetic algorithms. In Proc. SYNASC’07, pp. 188–195. IEEE Computer Society.Google Scholar
  26. 26.
    Ţurlea, A., Ipate, F., & Lefticaru, R. (2016). A hybrid test generation approach based on extended finite state machines. In 18th International Symposium on Symbolic and Numeric Algorithms for Scientific Computing, SYNASC 2016, Timişoara, Romania, pp. 173–180. https://doi.org/10.1109/SYNASC.2016.037.
  27. 27.
    Mitchell, M. (1998). An Introduction to Genetic Algorithms. Cambridge: MIT Press.zbMATHGoogle Scholar
  28. 28.
    Nicolescu, R., Dinneen, M.J., & Kim, Y.B. (2009). Structure modelling with hyperdag p systems: Part B. Tech. rep., Centre for Discrete Mathematics and Theoretical Computer Science, CDMTCS-373.Google Scholar
  29. 29.
    Henderson, A., & Nicolescu, R. (2019). Actor-like cP systems. In T. Hinze, G. Rozenberg, A. Salomaa, & C. Zandron (Eds.), Membrane Computing (Vol. 11399, pp. 160–187), Lecture Notes in Computer Science Berlin Heidelberg: Springer.Google Scholar
  30. 30.
    Bakir, M.E., Ipate, F., Konur, S., Mierlă, L., & Niculescu, I. (2014). Extended simulation and verification platform for kernel P systems. In Membrane Computing—15th International Conference, CMC 2014, pp. 158–178.Google Scholar
  31. 31.
    Holcombe, M. (1988). X-machines as a basis for dynamic system specification. Software Engineering Journal, 3(2), 69–76.CrossRefGoogle Scholar
  32. 32.
    Bakir, M.E., Konur, S., Gheorghe, M., Niculescu, I., & Ipate, F. (2014). High performance simulations of kernel P systems. In 2014 IEEE international conference on high performance computing and communications, HPCC 2014, pp. 409–412.Google Scholar
  33. 33.
    Gheorghe, M., Konur, S., Ipate, F., Mierlă, L., Bakir, M.E., & Stannett, M. (2015). An integrated model checking toolset for kernel P systems. In Membrane Computing - 16th International Conference, CMC 2015, pp. 153–170Google Scholar
  34. 34.
    Arapinis, M., Calder, M., Denis, L., Fisher, M., Gray, P., Konur, S., et al. (2009). Towards the verification of pervasive systems. Electronic Communications of the EASST, 2009, 22.Google Scholar
  35. 35.
    Konur, S., Fisher, M., Dobson, S., & Knox, S. (2014). Formal verification of a pervasive messaging system. Formal Aspects of Computing, 26(4), 677–694.CrossRefGoogle Scholar
  36. 36.
    Konur, S., & Gheorghe, M. (2015). A property-driven methodology for formal analysis of synthetic biology systems. IEEE/ACM Transactions on Computational Biology and Bioinformatics., 12, 360–371.CrossRefGoogle Scholar
  37. 37.
    Bakir, M. E., Konur, S., Gheorghe, M., Krasnogor, N., & Stannett, M. (2018). Automatic selection of verification tools for efficient analysis of biochemical models. Bioinformatics, 34(18), 3187–3195.CrossRefGoogle Scholar
  38. 38.
    Konur, S. (2010). Real-time and probabilistic temporal logics: An overview. CoRR arXiv:1005.3200.
  39. 39.
    Konur, S. (2013). A survey on temporal logics for specifying and verifying real-time systems. Frontiers of Computer Science, 7(3), 370–403.MathSciNetCrossRefGoogle Scholar
  40. 40.
    Konur, S. (2014). Specifying safety-critical systems with a decidable duration logic. Science of Computer Programming, 80, 264–287.CrossRefGoogle Scholar
  41. 41.
    Holzmann, G. J. (1997). The model checker SPIN. IEEE Transactions on Software Engineering, 23(5), 275–295.CrossRefGoogle Scholar
  42. 42.
    Cimatti, A., Clarke, E.M., Giunchiglia, E., Giunchiglia, F., Pistore, M., Roveri, M., Sebastiani, R., & Tacchella, A. (2002). NuSMV 2: An open source tool for symbolic model checking. In Computer Aided Verification, 14th International Conference, CAV 2002, Proceedings, pp. 359–364.Google Scholar
  43. 43.
    Harman, M., & McMinn, P.: A theoretical & empirical analysis of evolutionary testing and hill climbing for structural test data generation. In Proceedings of the 2007 international symposium on Software testing and analysis. pp. 73–83. ACM (2007).Google Scholar

Copyright information

© Springer Nature Singapore Pte Ltd. 2019

Authors and Affiliations

  1. 1.Faculty of Mathematics and Computer Science and ICUBUniversity of BucharestBucharestRomania
  2. 2.Department of Computer ScienceUniversity of BradfordBradfordUK

Personalised recommendations