AN APPROACH TO INCREASE THE EFFECTIVENESS OF TLC VERIFICATION WITH RESPECT TO THE CONCURRENT STRUCTURE OF TLA+ SPECIFICATION

Modern approaches to distributed software systems engineering are tightly bounded with formal methods usage. The effective way of certain method application can leverage significant outcome, in terms of corresponding time costs reduction for instance. To this end the TLC model checker has been considered – with respect to TLA+ specifications with concurrent structure. The concurrency itself has been implemented as interleaving. Two different approaches to TLC model checking have been used. The first approach is based on model checking via breadth-first state space search (BFS), the second one – via depth-first search (DFS). The main result of a paper is the new approach to increasing the effectiveness of TLC verification with respect to the concurrent structure of TLA+ specification. To analytically represent synthesized TLA+ specifications with concurrent structure, the Kripke structure has been taken. To assess the measures of state space explosion problem, taking place during the experimentation, the appropriate estimations have been proposed. These estimations have been proved during the case study. The composite web service usage scenario has been considered as a case study. The results, obtained during the experimentation, can be used to increase the effectiveness of automated TLC verification with respect to the concurrent structure of TLA+ specification.


INTRODUCTION
These days formal methods (model checkers in particular) are intensively used in different spheres of engineering.One of those are the distributed software systems.Designing certain software system, it's vital to periodically check, whether current solution actually meets the specified requirements.Here the another question ariseswhether we can conduct such checking in an automated manner.This peculiarity is especially important in context of iterative development.To this end, to check in an automated manner whether our current design solution meets the specified requirements, the formal verification is going to be considered from the model checking viewpoint.
Our attention has been put on the TLC (TLA Checker) model checker (Lamport, 2002).This method has already proved its applicability, having been successfully used to find the design flaws in Amazon Web Services for instance (Newcombe, Rath, Zhang, Munteanu, Brooker & Deardeuff, 2015).Moreover, this method is aimed at mathematically rigorous and easy reconfigurable TLA+ specifications (Temporal Logic of Actions) automated verification.Named formalism provides the abilities to create specifications with the desired level of abstraction, grounding on an "action" conceptthe specification of relation between some current and subsequent states of system's formal model.This level can be subsequently increased/decreased during the designing, which leverages the flexibility with respect to the altering nature of requirements.In our work the specification is being considered as a composition of parallel and sequential constructs.
To proceed further, let's consider the Software Development Life Cycle (SDLC) with respect to iterative model (Larman, 2004).In accordance with this model, each iteration is a sequence of the following stages (phases): requirements analysis, designing, implementation and testing.We put our focus on the second phasethe designing.During this process a bunch of various models and specifications with different levels of abstraction are being created.It's vital here to operate with correct and unambiguous specificationsto lessen the expenses, taking place within the forthcoming phasesimplementation and testing in particular.
The altering nature of different modern business scenarios prompts the necessity to deploy scalable and easy reconfigurable solutions.To this end the principles of Service Oriented Architecture (SOA), e.g., reusability, interoperability, composability, can be utilized (Martini & Paganelli, 2016).The key concept here is the Composite Web Service (CWS).In our work the CWS is considered as a system.The components of such system are some other services (atomic or composite).We contemplate the scenario, when system functioning is provided by way of orchestrationcentralized coordination (invocation) of system's components.
The exhaustive overview of SOA-and cloud-related SDLCs has already been conducted (Tran & Feuerlicht, 2016).It can be seen that the number of distinguished SDLC-phases and the phases set itself vary significantly.For instance, SOA-related SDLC can be considered as follows: requirements analysis, services discovery, negotiation, composition and consumption.With respect to this model our focus is put on a composition phaseto check the consistency of system's components.
To sum up, the main insight of our work is that modern SDLC of distributed software system is almost unimaginable without formal verification being conducted.The corresponding verification-related time costs influence the overall SDLC-related expenses, more or less.This influence is even more essential, when iterative SDLC takes place.To diminish this effectto lessen the verification-related time coststhe model checking method has to be used properly, in particular.To this end the TLC method is being considered in our work from the efficiency viewpoint.We are willing to find out whether the effectiveness of TLC method usage actually depends on a structure of certain TLA+ specification to be verified in an automated manner by way of model checking.And if it is, whether we can influence this effectiveness (in terms of corresponding time costs reduction) by using the right approach to TLC-driven model checkingby way of breadth-first state space search (BFS) or by way of depth-first search (DFS).The preliminary work has already been done: the investigation of TLC with respect to TLA+ specification with solely sequential structure has been conducted (Shkarupylo, Tomičić & Kasian, 2016).Both approaches (the BFS-and the DFS-driven one) have been used.It has been found out that DFS-driven approach is about two times more effective, comparing to BFS-driven alternative, but the following drawbacks also take place: the necessity to manually specify the depth of state space search, which directly harms the model checking process in terms of automation.Taking into consideration all the aforesaid, we are willing to find out whether the effectiveness of TLC method usage actually depends on a structure of TLA+ specification.

PROBLEM STATEMENT
Given a set of TLA+ specifications with concurrent structures.Let's consider the effectiveness of TLC method usage from the verificationrelated time costs viewpoint.There are two approaches to TLC method usage distinguished: model checking by way of BFS and by way of DFS.
Let's consider CWS as a system (Shkarupylo, 2016).Let's assume that CWS is represented with WS-BPEL-description (Web Services Business Process Execution Language), which is the implementation of centralized orchestration model (Mecheraoui, Belala & Saïdouni, 2016).According to this model, the components of CWS are depicted with <invoke> tags.Each <invoke> tag is a certain web service to be invoked.
To analytically represent TLA+ specification, the Kripke structure on a set of atomic prepositions AP has been used (Clarke, Grumberg & Peled, 2001): where S -finite set of states, S s  states labeling function.The S set is as follows: where set of state variables: N n is a number of CWS's componentsthe amount of <invoke> tags in WS-BPEL-description; To unify the experimentation process, the analytical model of automatically synthesized TLA+ specification has to be proposed.This model should provide the scalability to get specifications for CWSs with different numbers of components.
To assess the effectiveness of TLC method usage with respect to the concurrent structure of TLA+ specification, the estimations of model checking tasks to be solved have to be proposed.These estimations have to be proved experimentally.
The experimentation has to be conducted by using two approaches to TLC model checkingthe BFS-and the DFS-driven one.Corresponding results have to be compared in terms of effectiveness.
To generalize the conclusion on TLC method usage effectiveness, the obtained results (with respect to the concurrent structures of TLA+ specifications) have to be compared to the ones, obtained previously (with respect to solely sequential structures of specifications).

APPROACH DESCRIPTION
Let's suppose that there are two groups of TLA+ specificationsthe specifications with purely sequential structures (first group) and the ones with concurrent structures (second group).
To synthesize the first-group specifications the <sequence> and <invoke> tags have been used as a basis.The <sequence> tagas the representative of WS-BPEL Structured Activities group.The <invoke> tagas the element of WS-BPEL Basic Activities group.To synthesize the second-group specifications, the <flow> tags from Structured Activities group have also been considered.
Let's consider the V set (Eq.( 2)): there are only two possible Boolean values allowedfalse (0) or true (1).Now let's talk in terms of atomic prepositionsto interpret the elements of AP set (Eq.( 1)).For instance, the   takes place, then it has already been invoked.
Let's consider the first-group specification.The precondition for   atomic preposition.This means that i -th component has already been invoked.In this case 1 , where S s n  is the final state to be reached during the automated TLC verification.The more detailed view on TLA+ specifications with solely sequential structure has already been provided (Shkarupylo et al., 2016).Now let's take a look at TLA+ specifications with concurrent structures.Let's represent the concurrency as interleaving.Let's suppose that the structure of any TLA+ specification is binary tree-like.This decision has been made to obtain scalable and demonstrative solutions.The vertices of such structures are pre-and post-conditions for components invocations.The invocation itself is considered in given scope as an activity (action).In TLA context the activities are the atomic building blocks of specification.To specify certain activity the precondition of its implementation should be given and specified first.
Let's represent the activity as an implication, coupled with X (neXt) temporal (Shkarupylo, Polska & Kudermetov, 2015).This means that truth of certain   atomic preposition.That should be interpreted as follows: if certain component is intended to be invoked (in accordance with specification), it has to be invoked.This formalization is built on the following basis: is a subsequent statethe basis for the post-condition, represented with   s L  label as a result of i -th component invocation.
Let's synthesize the TLA+ specifications with concurrent binary tree-like structures.The binary tree template will be slightly modified to more naturally represent the real-world scenarios: all the terminal vertices will be joined to a single onethe final point, representing the final activity of gatherer-component invocation, modeling the intermediate computational results obtaining.
At least 2 2  V state variables are required to synthesize such specification: , where V v  1 is the basis for the 1-st components invocation activity; this component should initiate the computational process by distributing the tasks to be processed concurrently by a pair of components, represented with the representation of a component, intended to be a gatherer (Figure 1).
; the 2-nd onewith a pair of activities to be implemented concurrently: . For this particular example let's assume the scenario of distributed  value calculation (Shkarupylo, 2016): In accordance with Eq.( 3 state variable represents some initiator of computational process.It can be a distinct web service (atomic or composite) that actually initiates the computational processdistributes the whole task for instance.It can also be the representation of WS-BPEL-engine itselfthe entity, which initiates and coordinates the computational process in a centralized manner, to provide the consistent system functioning.Finally, the V v  4 variable is a representation of some gatherercomponentthe atomic or composite web service, which gathers the intermediate computational results, obtained from the components, represented with Let's consider the 1-st and the 3-rd layers as the boundary ones (Figure 1).Paired with intermediate (2-nd) layer, each of them form fork-and join-constructs, respectively.The 1-st layer represents the initiation of some computational process and the 3-rd onethe finalization of it.So, in our case to form the minimum basis of concurrency inspired TLA+ specification at least 4 state variables are required.That provides us with minimum set of pair of boundary layers and at least one intermediate layer, representing the concurrency.Such concurrency is going to be modeled as interleaving.To form the additional intermediate layer another 4 state variables should be added, then 8, and so on.The main idea here is that the activities within certain intermediate layer should be implemented concurrently, and this particular layeroriented concurrency should be modeled as interleaving.Such approach stipulates the state explosion problem within the intermediate layers.To sum up, the main idea here is that each TLA+ specification with concurrent structure should possess strictly a pair of boundary layers and at least one intermediate layer.Then, during the experimentation, the number of intermediate layers should be increased step-by-step, until the limitation of random access memory is faced.
In case of two or more intermediate layers, the boundaries between such adjacent layers then should be considered as barrier-functions (MPI_Barrier for instance, when some computational process is waiting for all another processes to continue/resume the computation).That means that no activity from adjacent subsequent intermediate layer can be executed until all the activities from some current intermediate layer are committed.In general this statement is also fair when some representative of a pair of adjacent layers is the boundary one.
The To synthesize the specifications, the n values are going to be taken from the sequence . The 7 2 value has been chosen as an upper limit in accordance with the results, obtained earlier (Shkarupylo et. al., 2016).In accordance with these results, the limitation of random access memory volume has been faced while using the DFS-driven approach to automated TLC verification with respect to the sequential structures of TLA+ specifications.
Let's estimate the total number of components to be invoked concurrently: where   It should be emphasized that there is always a pair of state variables ( V v 1  and V v n  ) from the boundary layers: n  -from fork-and join-boundary layers, respectively.This means that the total number of state variables can be obtained with the following expression: is the total number of state variables from both boundary layers.
To estimate (count) the number of states to be reached during the successful TLC-verification, the following function has been proposed: where   activity occurrence (Figure 2).For instance, for , respectively (Eq.( 5)).It will allow to check the results of automated TLC-verification of synthesized TLA+ specifications with binary tree-like structure (Figure 1).
To estimate (count) the number of transitions, needed to visit all the states of S set (Eq.( 1)), the following function has been proposed: is the number of transitions (activities in particular), taking their ground solely on the boundary layers . For instance, considering the boundary fork-layer transition takes place: For this activity the precondition  2).Considering the boundary join-layer a post-conditionthe representation of the final state S s  5 , to be reached during the automated TLC verification.
The   n f 3 function can be used to estimate the complexity of model checking task to be solved and to actually check the successfulness of the solution obtained.

THE CASE STUDY
To conduct the case study, the 2.05 version of TLC has been used.
The numbers of states, found during the verification, are given in Table 1.In Table 1 Gen is the total number of states, generated by TLC to verify the TLA+ specification, synthesized in accordance with proposed analytical model.Found the numbers of states, found and checked during the verification.These values have been obtained experimentallyfrom the TLC log-files.They can also be obtained analyticallywith Eq.( 5).
Depththe depth of state space searchthe number of states (including S s  0 ) to be visited, starting from the initial S s  0 state and finishing in the final S s    state.Taking into consideration the interleaving nature of our concurrency, the Depth is also the length of each path from the initial to the final state.Due to the initial state presence and interleaving, these paths are of the same length for a given n (Figure 2): where   n f 4 is a function to get the length of each path from the initial state to the final one for a given V n  .To calculate the total number of such paths, the following expression can be used: where   n f 5 is a function to get the total number of paths to be walked through during the automated TLC-verification of certain TLA+ specification, synthesized with accordance to the proposed analytical model.Thus, using Eq.( 7) and Eq.( 8), the complexity assessment of model checking task to be solved can be represented as multiplication of   The calculated estimations for , obtained with Eq.( 8), are given in Table 2.  induces some doubts about the random access memory sufficiency to successfully resolve the model checking task (Eq.( 9)).
, given in Table 2, have been proved with TLC logging data.
To discover the ways for TLC-verification effectiveness increasing, the time costs for BFS-and DFS-driven verifications have been measured (Table 3).In In Table 3 there are two sectionsthe "sequential" section and the "concurrent" one.
In the first section the results of previous experimentations are given (Shkarupylo et. al., 2016).These results have been obtained for TLA+ specifications with purely sequential structure.The ratio between BFS t and DFS t values has been chosen as effectiveness criterion.It can be seen from the Table 3 that BFS-driven approach is about two times more time consuming, comparing to the DFS-driven one (considering the sequential specifications).Thus, in this scenario the DFS-driven approach is about two times more effective, comparing to the BFS-driven alternative.The first one, though, is paired with the significant limitationsthe depth of state space search has to be assigned manually.This peculiarity significantly restricts the DFSdriven approach practical usage in terms of automation.
Considering the "concurrent" section of Table 3, we can observe a bit different picture.These results have been obtained during the current experimentation.It can be seen from this section that DFS-related time costs are growing significantly quicker, but the whole picture is pretty similar (considering the cases for ).Thus, the general recommendations in terms of effectiveness are going to be similar to the ones with respect to the aforesaid "sequential" section: the DFS-driven approach is significantly more effective, comparing to BFS-driven one.Nevertheless, the advantage of the first over the later one is not as significant, when talking about the verification of TLA+ specifications with purely sequential structure ("sequential" section).Moreover, the aforesaid drawbacks are still here: the necessity to manually assign the depth of state space search and also the significantly bigger number of accompanying states, generated during the verification (Table 1).It can be assumed that the later peculiarity imposes some extra-requirements to the RAM volume.Nevertheless, both considered approaches (the BFS-and the DFS-driven one) appeared to be inapplicable to conduct the verification of TLA+ specification with a concurrent structure for 4 2  n , taking into consideration the estimations, given in Table 2, and also the limitation of RAM volume.
It should be noted, however, that the sizes of TLA+ specifications, synthesized with respect to the proposed analytical model, were the following: for about 210 MB.While changing the volume of JVM-accessible (Java Virtual Machine) memory buffer from 256 to 1280 MB, the corresponding BFS-and DFS-related time costs were almost identical (Figure 3).The model checking task hasn't been solved though., taking into consideration the limitation of memory space.

CONCLUSION
In this paper the novel approach to increasing the effectiveness of TLC verification with respect to the concurrent structure of TLA+ specification has been proposed.The following results have been obtained: 1.The layered binary tree-like concurrent structure of TLA+ specification has been proposed.The concurrency has been represented as interleaving.This allowed to synthesize unified and structured specifications for the purpose of experimentation.
2. The estimations of TLC model checking tasks have been proposed and proved by way of experimentation.It has been determined that DFS-driven approach to TLC verification of TLA+ specifications with concurrent structures generates significantly larger number of states, comparing to BFS-driven one.
3. The case study has been conducted.It has been determined that the overall tendency of time costs growing for TLA+ specifications with concurrent structure is similar to the one, previously found out by us for specifications with purely sequential structure: the DFS-driven approach is about two times more effective (in terms of corresponding time costs), comparing to the BFS-driven one.
4. The limitation of random access memory has been faced.It has been determined that both approachesthe DFS-and the BFS-driven oneare inapplicable to solve the verification task with respect to TLA+ specifications with 4 2  n state variables, synthesized in accordance with proposed analytical model, taking into consideration the 1280 MB limitation of JVM buffer size.
The further research is aimed at proposed analytical model sophistication, by increasing the set of state variables values to make synthesized formal specifications more relevant.

Figure 1 .
Figure 1.The activity diagram of concurrency of states to be reached due to the concurrent invocation of the components, represented with state variables from H take into consideration the adjacency of some current and subsequent intermediate layers, when the resulting state for H of states, associated with boundary layersinduced by invocation of state variables from the boundary layers: the pre-and post-conditions for the final

Figure 2 .
Figure 2. The state diagram for 4  n

Figure
Figure 3.The verification time costs for representatives of intermediate layer(s) jointly cause the exponential state space growth.Herein the number of state variables, involved in concurrent activities, is

Table 1 .
The BFS-to-DFS model checking tasks measures comparison

Table 2 .
The estimations of model checking tasks complexities

Table 3 .
The time costs for BFS-and DFS-driven model checking