UNIVERSITĀ DEGLI STUDI DI FIRENZE Dipartimento di Sistemi e ...

UNIVERSITÀ DEGLI STUDI DI FIRENZEDipartimento di Sistemi e InformaticaDottorato di Ricerca in Informatica e ApplicazioniXXIII CicloS O F T WA R E E N V I R O N M E N T F O R S P E C I F I C AT I O N O FP R O C E S S A L G E B R A Sfrancesco calzolaiSupervisor: prof. Michele LoretiPhD Coordinator: prof. Rocco De NicolaDecember, 2010

Francesco Calzolai: Software Environment For Specification Of Process Algebras,Dottorato di Ricerca in Informatica e Applicazioni, © December, 2010

A B S T R A C TConcurrency Theory is an active research area within theoretical computerscience that aims at studying systems composed by many computational entitiesthat act and interact with each other via shared resources. To facilitate theformalization and analysis of complex systems, a wide variety of formalismshave been developed. A particularly important class of such techniques isrepresented by Process Algebras: a set of mathematically rigorous languageswith well defined semantics.In this thesis TAPAs, a software environment for supporting specification andanalysis of concurrent systems via Process Algebras, is presented. TAPAs isdesigned with a plug-in architecture: a set of software components (plug-ins)adds specific capabilities to a larger software application. Each plug-in supportsa specific Process Algebra and it can be easy deployed in the TAPAs mainapplication. The main application provides basic libraries that, from one hand,permit simplifying developing of automatic tools and, on the other hand, permitintegrating existing tools in a more usable environment. Moreover, since TAPAsrelies on loosely coupled components, new features can be introduced withoutaffecting existing implementations.Beside presenting the overall TAPAs architecture, thesis introduces three differentplug-ins that support three Process Algebras: CCSP, PEPA and StoKlaim.The first plug-in adds support for CCSP: a process algebra obtained from CCSby incorporating some operators of CSP. This plug-in is specifically thoughtfor teaching Concurrency Theory to undergraduate students. By its nature,Concurrency Theory is complicated not only study but also to teach. To facilitatethe formalization and analysis of complex systems, CCSP plug-in provides botha graphical and textual system specification and it consistently updates termswhen the graphical representation is changed and redraw process graphs whentextual terms are modified. Moreover this plug-in provides graphical interfacesthat guide users in analyzing and debugging the specified models.The second plug-in adds support for PEPA: a stochastic process algebra designedfor modeling computer and communication systems. For the specificationphase, this plug-in provides a rich graphical interface that simplifies processspecification. On the contrary, for the analysis phase, it exploits the PEPA librariesdistributed with the "PEPA Eclipse Plug-in" developed by the PEPAgroup at University of Edinburgh. TAPAs uses this libraries to perform steadystate and transient analysis on the specified models.The third plug-in adds support for StoKlaim, a variant of Klaim. StoKlaimis an experimental language specifically designed to model distributed systemwith code mobility. This plug-in is a research tool used for developing comiii

ivplex case studies. It provides only textual specification and it does not exploitTAPAs embedded analysis tools, but it implements new ones. StoKlaim allowsto formalize properties by mean of a stochastic logic that, together with qualitativeproperties, permits specifying time-bounded probabilistic reachabilityproperties. This plug-in can also be used for supporting analysis of biologicalsystem specified in BioKlaim (a variant of StoKlaim) introduced in this thesis.In BioKlaim a "molecules as tuples" approach is used: tuples are used to modelthe molecules, agents identifies the reactions enabled, and localities are used tomodel the spatial structure of biological systems.For each plug-in many case studies are presented. CCSP and PEPA pluginsare used for modeling two atomic commitment protocols. These didacticexamples are analyzed by performing qualitative (CCSP) and quantitative (PEPA)evaluation. StoKlaim plug-in is used to perform quantitative evaluation onclassical leader election algorithms, while BioKlaim is used for modeling fourdifferent case studies: Groupies&Celebrities, spatially distributed enzymaticreactions, Microglia and excitable cells.

A C K N O W L E D G M E N T SI would like to thank my supervisor Prof. Michele Loreti for the time, the patientguidance and willingness to share experience with me. He has given me valuableadvice and support in the writing of this thesis.I would like also to thank my PhD course coordinator Prof. Rocco De Nicolafor his assistance and important comments he gave me during my PhD study.My thanks go to all the students involved in this project: both those who havecontributed to its development and those who have just used it.I am really grateful to all people who shared PhD student office with me.Thank you all for great chats during these three years: Alessandro D., AlessandroL., Andrea C., Andrea M., Antonio, Carlo, Carlotta, Federico, FrancescoB., Francesco T., Leonardo, Liliana, Lucia, Maddalena, Massimiliano, Paolo,Pierluigi, Sara, Stefano Bi., Stefano Br., Tania.Furthermore I would like to thank all the people I met at DSI for all the goodtimes and discussions at coffee breaks.I would say thanks to my family for their support and for everything theyhave done for me. Finally, I thank Genny for her support, great sympathy andenormous patience.v

C O N T E N T S1 introduction 11.1 Process Algebras 51.2 Equivalence Checking 61.3 Model Checking 71.4 Related Tools 82 tapas 132.1 Backgrounds 142.1.1 Behavioral Equivalences 162.1.2 Temporal Logics 192.2 Design of TAPAs 232.2.1 Infrastructure 242.3 The Kernel Modules 262.4 Model Checker 302.5 Equivalence Checker 322.5.1 Counter Examples Generator 353 ccsp and pepa plugin 473.1 CCSP plug-in 483.1.1 CCSP Syntax and Semantic 483.1.2 CCSP Back-end 503.1.3 CCSP Front-end 523.2 Case Study: Two-Phase Commit Protocol 553.2.1 Atomic Commitment Protocol 553.2.2 Two-phase Commit Protocol 563.2.3 Modeling Networks 573.2.4 Networks 593.2.5 2PC and E-2PC: Properties and Models 603.3 PEPA PLUG-IN 663.3.1 PEPA Syntax And Semantics 663.3.2 PEPA Back-End 673.3.3 PEPA Front-End 683.4 Case Study: Two-Phase Commit Protocols 713.4.1 Networks Modeling in PEPA 713.4.2 Two-Phase Commit Protocols: Concrete Systems 724 stoklaim 774.1 Klaim 784.2 Concepts of Probability Theory 794.2.1 Exponential Distribution 794.2.2 Continuous Time Markov Chain 80vii

viiicontents4.2.3 Rate Transition Systems 814.3 StoKlaim: Stochastic Klaim 824.3.1 Syntax 824.3.2 Operational semantics 844.4 MoSL: Mobile Stochastic Logic 854.4.1 MoSL Semantics 854.4.2 MoSL Satisfaction Relation 914.5 Statistical Model Checker 954.6 StoKlaim-plugin 974.6.1 StoKlaim Specification 984.6.2 Analyzing a specification 1024.7 Leader Election 1034.7.1 All the way 1044.7.2 As far as it can 1054.7.3 Controlled distance 1054.7.4 Asynchronous leader election 1074.7.5 Comparing Algorithms 1095 bioklaim 1115.1 Introduction 1115.2 BioKlaim 1125.3 BioKlaim plug-in 1145.4 Biological Models 1185.4.1 Groupies and Celebrities 1185.4.2 Intracellular Enzymatic Reactions 1235.4.3 Microglia 1265.4.4 Excitable Cells 1366 conclusions 149

L I S T O F F I G U R E SFigure 1 TAPAs structure 25Figure 2 TAPAs engine 28Figure 3 TAPAs Plug-in 29Figure 4 Three simple counter examples 37Figure 5 Pseudocode for minimum representer R ⊥ (F) 38Figure 6 A simple example 40Figure 7 Pseudocode for initialization phase 41Figure 8 Pseudocode for iterative phase 44Figure 9 CCSP operators structure 51Figure 10 Graphical and textual specification of Bill and Ben. 52Figure 11 Model checker and Equivalence checker 53Figure 12 The navigator 54Figure 13 (Extended) Two-Phase Commit Protocol schema 57Figure 14 A reliable (above) and an unreliable (below) link 58Figure 15 Parallel and Series networks 59Figure 16 New network models 60Figure 17 Coordinator and Cohort for the 2PC 62Figure 18 Coordinator and Cohort for the E-2PC 63Figure 19 Simulator 64Figure 20 Networks 65Figure 21 PEPA syntax and semantics. 67Figure 22 PEPA operators structure 68Figure 23 Graphical and textual specification of Bill and Ben. 69Figure 24 Steady state analysis panel 69Figure 25 Passage time analysis panel 70Figure 26 Coordinator and Cohort for the 2PC 72Figure 27 2PC steady state analysis 73Figure 28 Rollback or Complete probability tree 74Figure 29 PDF and CDF for 2PC 75Figure 30 StoKlaim plugin main panel 97Figure 31 AllTheWay simulation 105Figure 32 AsFarAsItCan simulation 106Figure 33 ControlledDistance simulation 108Figure 34 Asynchronous simulation 109Figure 35 Comparison between the four algorithm 109Figure 36 Celebrities in all the grid (left) and in the central node(right) 120ix

xList of FiguresFigure 37 Groupies results: in all the grid (left), and in the centralnode (right) 121Figure 38 Mixed population results: in all the grid (left), and in thecentral node (right) 122Figure 39 Slow groupies (2G left, and 3G right) overall behavior 123Figure 40 Initial conditions 124Figure 41 Substrate (above) and product (below) diffusion at time =0s, 5s, 10s 125Figure 42 Michaelis-Menten results 126Figure 43 No mutated system (wild type) behavior 135Figure 44 Mutated system behavior 136Figure 45 NK activation trends in various models 137Figure 46 Probability through time that AEA and 2-AG substratesare present outside the cell. 138Figure 47 Action potential in neurons 139Figure 48 Action potential with ions activity 145Figure 49 Action potential without ions activity 145Figure 50 Comparing Model Checking results 146

L I S T O F TA B L E STable 1 Observation satisfaction relations 19Table 2 µ − calculus syntax 20Table 3 µ − calculus satisfaction relation 21Table 4 ACTL syntax 22Table 5 ACTL satisfaction relation 23Table 6 µ − calculus reduction rules for on-the-fly model checking32Table 7 Complexity analysis of partition refinement algorithms. 33Table 8 Flags settings for decorated traces 34Table 9 Creation of the minimum representers 39Table 10 Table after initialization phase 41Table 11 CCSP Syntax and Semantics. 49Table 12 Execution times. 55Table 13 StoKlaim syntax 83Table 14 Pattern-matching of tuples against templates 83Table 15 StoKlaim Operational Semantics (Part 1) 86Table 16 StoKlaim Operational Semantics (Part 2) 87Table 17 Syntax of MoSL formulas 88Table 18 Operators on paths 92Table 19 Satisfaction relation for path formulas 93Table 20 Satisfaction relation for state formulas 94Table 21 Satisfaction relation for action specifiers 94Table 22 BioKlaim syntax 112Table 23 BioKlaim Operational Semantics (Part 1) 115Table 24 BioKlaim Operational Semantics (Part 2) 116Table 25 Propagation of the potential difference in a list tissue 147Table 26 Potential difference propagation in a square tissue 148xi

I N T R O D U C T I O N1From the beginning, software systems have tended to increase their complexityby increasing their level of interaction. The earliest computer systems havebeen developed as stand-alone application that, sometimes, could be accessedremotely. Afterwards they have started to support data exchange and remoteprocess invocation among themselves without human support. Nowadays, theyare no longer isolated entities, but rather a set of applications networked intolarge distributed systems and therefore communications networks are not justa medium to convey information, but backbones connecting these concurrentsystems.The last two decades have seen impressive growth of the Internet and communicationnetworks. The concept of "global computing" allows to fully highlight thesignificant evolution of the concept of "calculation". This change can be noticedconsidering two main issues: first, now many software must have an infinitebehavior, namely that applications must respond to an endless series of requests.Secondly, since modern computer devices (e.g., laptop, mobile phones) interactin the context of decentralized communication networks, their underlying behavioris inherently concurrent, rather than sequentially. In other words theremany software that provide distributed services, for example: instantaneous communicationsystems and P2P protocol for file-sharing. These distributed servicesmake simultaneous interactions among the users involved.Today, one of the biggest challenges is to build fault tolerant concurrentdistributed systems, and when failures will occur would be very useful to beable to predict the consequences. Estimate the damage caused by a failurepermits taking appropriate countermeasures, either by increasing the systemreliability or providing a more effective recovery method in case of system crash.Systems reliability closely depends on damages that their failure will cause.Obviously, the systems with an infinite behavior can hardly be made morereliable.Until recently, the most important applications having infinite behavior wereoperating systems. No matter how catastrophic failures may be, they had onlylocal repercussions, in practice the damage that a failure could cause can beestablished "a priori", and hence the system could be designed with due attentionto replicated resources. Today, however, there are many more applications thathave an infinite behavior; first of all the Web-based applications, such as: on-linebanking, e-commerce or even a simple on-line storage services. In these case,their failures may cause both "local" and "global" damages. If an on-line bankingwebsite is no longer available, the bank public image will be seriously damaged1

2 introductionand it will not be able to collect the commissions fee of the lost transactions(local damages). However there will be also "global" damages; in fact even thosecompanies who use on-line banking service will probably have to suspend someof their services, undergoing both direct (the loss of income) and indirect (publicimage damages) harms. Even in the seemingly simple on-line storage service,damages could be substantial. In fact, if this service completely replace otherback-up methods (USB-key, DVD, local server), the absence of such a servicecould cause many problems.The damages caused by the lack of a stand-alone service will be alwayslocalized, no matter how high these may be. For example the consequences of afailure in a railway station control system could be catastrophic but localizedin a (possible wide) surrounding area. In general, the more a local service isconsidered to be critical, the more damages will occur. On the contrary, thedamages caused by a distributed service fail largely depends on its distribution;but if it is not possible estimate in advance the service pervasiveness, it is notalso possible estimate the damage that will be caused by a future failure.The new way of conceiving modern applications have a direct impact on theway of the software is built and tested. In particular, the continuous interactionbetween software systems (Business-To-Business, B2B) is a serious challengein software verification. The traditional approach, focused on studying outputwith respect to a given set of inputs, it is clearly inappropriate in the context ofsoftware components that should work forever.Concurrency Theory (CT) was born just to satisfy this requirement: the studyof systems in which several computations are executing simultaneously, andpotentially interacting with each other. Nowadays, CT is both an active researchfield and provides the basis of many key technologies such as: parallel anddistributed computing, network protocols and modern web technologies (serviceorientedarchitectures and Web Services).Information Technology industries are increasing their focus on ConcurrencyTheory. They start to consider CT as valuable technique in designing and analysisof complex reactive computing systems. Several companies are interested inapplying concurrency-theoretic ideas and tools, since this reduces the time tomarket and increases the quality of their products. Despite the benefits that couldbe achieved using concurrency-theoretical approach, there is still some reluctanceto insert it in the software development process. This delay is known especiallyin small and medium companies in which, typically, there is not a formalmethods team. From the companies point of view, bridge this gap by formingappropriate staff, requires resources without giving an immediate economicreturn. Academic courses offered to students and to industry practitioners playa key role in the transfer of these methodologies into industrial practice. Thestudents should be able to model and analyze real-life industrial case studies. Inthis way, when students go and work in industry, they will know that there are

introduction 3effective modeling languages and tools that can be used to check designs beforeimplement.By its nature, Concurrency Theory is complicated not only study but also toteach. Classical tools can not be sufficient to explain the evolution of severalparallel components, and even teachers could have great difficulty in describingnon-trivial concurrency problems by using only a blackboard and a chalk. Tofacilitate the formalization and analysis of complex systems, a wide variety offormalisms have been developed including Petri nets, theorem provers and actormodel. Some of these formalisms are primarily intended to support reasoningand specification, while others can be used through the entire developmentcycle, including design, implementation, verification, testing and simulation ofconcurrent systems.A particularly important class of such techniques is represented by processalgebras (PA). Process algebras (or Process Calculi, PC) are smalls programminglanguages provided with a few operators that are intended to capture the essentialinteractive and non-deterministic features of the systems of interest. Theystudy the behavior of concurrent distributed systems by algebraic means, andpermit verifying whether a given specification satisfies the expected properties.Moreover, PA often come equipped with observational mechanisms that permitidentifying (through behavioral equivalences) those systems that cannot be takenapart by external observations. The research work carried out in the last threedecades was started with the introduction of CCS [117, 118], CSP [52] and ACP[44].Verification of concurrent system within the process algebraic approach isperformed by means of two different techniques: equivalence checking and modelchecking. The former one exploits behavioral equivalences [118, 150, 101, 72] forproving conformance of processes to specifications, the latter checks whether aprocess enjoy properties described by some temporal logic’s formulas, suchas Hennessy-Milner Logic (HML) [97], Linear Temporal Logic (LTL) [125],µ − calculus [110], Computational Tree Logic (CTL) [62] or Action-based ComputationalTree Logic (ACTL) [73]. In temporal logics the notion of truth is extendedto take into account its necessity or equivalently its persistence throughtime. Temporal logic formulas are a mix of logical operators and modal operators.The former are the usual boolean operators, while the latter are those that permitreasoning about systems evolution in time.Concurrent systems are specified as terms of a process description languageand their formal behavior is defined by means of Structural Operational Semantics(SOS) [123] that permits associating to each specification a Labeled TransitionSystems (LTS). LTSs consist of a set of states, a set of transition labels and atransition relation. States correspond to the configurations systems can reach.Labels describe the actions systems can perform to interact with the environment.Transition relation describes systems evolution as determined by the execution

4 introductionof specific actions. As we shall see, LTSs play a crucial role in process algebraterms analysis.There are many tools for modeling concurrent systems via process algebras.These can be divided into two broad categories: (semi-)industrial tools and educationaltools. The first ones have achieved a high degree of development andallow users to model real case studies, but require advanced theoretical knowledges.For example, many of these tools use complex specification languagesthat allow to specify probabilistic, real-rime or stochastic systems. Unfortunately,the use of these languages requires knowledge that are often beyond the scopeof an university course. In contrast, the educational tools have simpler specificationlanguages, that are easier to learn. They often (but not always) providegraphical interfaces but almost never graphical terms specification. Furthermorethese tools rarely provide all the features that theoretical studies identified; forexample few provide both a Model and an Equivalence Checker.Generally these tools have been developed in university environment wherethere are no dedicated development teams and projects leaders can not devotethe proper (and considerable) time for development. As Kim G Larsen said [31]:"Tool development is labor intensive, and one needs the sustainedeffort of many people over many years to produce good softwaretools."Sometimes, it is not possible to provide resources to support projects, forso long. In fact the primary purpose of these projects (successfully transferconcurrency-theoretic ideas in the industry) are fundamental in the modernworld, but there is a scientific return only after many intense developmentefforts.In this thesis we present TAPAs [54, 16]: a software environment for supportingspecification and analysis of concurrent systems via process algebras. It aimsat providing a software environment that, from one hand, permits simplifyingdeveloping of automatic tools and, on the other hand, permits integratingexisting tools in an usable environment. In order to obtain a modular structure,TAPAs is designed with a plug-in architecture: a set of software components(plug-ins ) adds specific capabilities to a larger software application. Every pluginadds supports for a specific PA and main application provides basic librariesthat can be used by every plug-in for modeling, analyzing and debuggingconcurrent models. Each plug-in is developed as an independent module thatinteract with main application by means of some predefined extension points:well-defined methods that can be extended by every new module.Among other advantages, this specific architecture allows to hide most of theimplementation details and shows clear extension points: well-defined methodsthat can be extended by every new module. TAPAs aims also to allow developersto implement their own plug-in with a minimal initial effort, indeed, with sucharchitecture, the knowledges necessary to develop a new plug-in are relatively

1.1 process algebras 5few. A plug-in can be created in a reasonable time, even without knowing allthe implementation details.In the rest of the Thesis, first we will describe the TAPAs architecture and itsmain features (Chap. 2), rather it will be described three different plug-ins: CCSPplug-in (Sec. 3.1), PEPA plug-in (Sec. 3.3) and StoKlaim plug-in (Chap. 4). Foreach plug-ins, it will be described the algebra supported, its implementationsand some examples which show its distinguishing features.In rest of this Chapter we will introduce Process Algebra (Section 1.1) andsome analysis techniques (Section 1.2 and 1.3). Finally we will describe otherautomatic analysis tools by pointing out the main features, characteristics andthe differences with TAPAs (Section 1.4).1.1 process algebrasThirty years ago the first created process algebras were: CCS, CSP and ACP. Sincethen many other process algebras have been developed and a huge amountof research work on their unification was carried out. In fact, despite somesimilarities, these calculi have been developed starting from different pointsof view. CSP, which is based on notions of "events" and "processes", was firstdescribed in a 1978 paper by C. A. R. Hoare, but has since evolved substantially.It strives to have a simple semantic model in which it is easy to define newoperators as they are needed. CCS, which is based on notions of "actions" and"agents", was introduced by Robin Milner around 1980 and was designed tohave a minimal set of operators with binary communications between exactlytwo participants. ACP was initially developed by Jan Bergstra and Jan WillemKlop in 1982. It started from a completely different viewpoint and provideda purely mathematical algebraic view of concurrent systems. ACP processesare the solutions of systems of equations (axioms) over the signature of theconsidered algebra.Over the years, their similarities and relationships have been studied andunderstood. In fact, behavioral equivalences developed for one were appliedto the others. Despite this, in university courses PAs continue to be taughtseparately and sometimes one excludes the others. Indeed there are morebooks on just a process algebra (CCS [118], CSP [102, 132, 135], ACP [37, 83],Lotos [49]) rather than on a general process algebraic approach. TAPAs projectaims at providing a tool for teaching process algebras theory showing differentlanguages as specific instances of a general approach. To do this, first wehave characterized the general structure of process algebra, extracting theirfundamental components and then we have developed a software environmentthat provides a set of features as complete as possible and finally we haveimplemented three plug-ins for handling as many process algebras.

6 introductionEvery process calculus (PC) is characterized by means of three main ingredients:a minimal set of operators, a structural operational semantics describing theevolution of each operators, and an equivalence notion that permits abstractingfrom irrelevant details. PC allows to describe models as terms and their formalbehavior is defined by means of LTSs. Processes verification can be performed byusing equivalence checking or model checking, both based on LTSs. In equivalencechecking approach, two descriptions (one very detailed, the other more abstract)of a given system are provided and tested for the chosen equivalence. Theassociated LTSs are used to check terms equivalence under some abstractionassumption. In model checking approach, given a system, its corresponding LTSis used for checking whether the formula holds.1.2 equivalence checkingEquivalence Checking is commonly used to formally prove that two representationsof a system design exhibit "similar" behavior. Generally, given a system,two different models are developed: one is very detailed and close to the actualconcurrent implementation, whereas the other is more abstract and describesthe abstract tree of relevant actions the system has to perform. Then these twosystems are compared up to some equivalence notion that permits abstractingfrom irrelevant details. This allows to demonstrate that the implementation of asystem (how it is made) is correct with respect to a given specification (what weask it to do).The choice of equivalence used for comparing these systems depends onwhich characteristics are considered important and which irrelevant details.Often the intended use of the systems under consideration determines thebehavioral aspects which must be taken into account and those that can beignored. For example, control systems (control panels of railway station, powerplant, . . . ) have to guide the operator through the sequence of allowed actionstrying to minimize human errors. In this case, they are high reliability artifactsthat have to prevent users to bring the system under control into a potentiallydangerous state, according to: "what is not allowed is forbidden". In contrast, asupport system (car’s Electronic Control Unit, for example) may be less reliable,but its possible failure must not prevent users from carrying out their task (acar’s Electronic Control Unit failure must not impair driving nor be dangerousfor the driver).Thus, for each equivalence, it is important to know the preserved properties.Therefore it is not surprising that in the literature several equivalences have beenproposed because of the many system features that might be worth considering.In the further, we will consider the so called observational equivalences. In theseequivalences what matters is not the internal structure of a process, but itsbehavior in relation to the outside world. There is not agreement within the

1.3 model checking 7scientific community on which is the right notion of observation nor on howthe observation results should be used to distinguish or identify systems. Forthese reasons, several observational equivalences are defined, each of whichis based on a specific and reasonable notion of "observable". In fact, there is awhole range of equivalences that can be organized in a hierarchy: from the mostrestrictive (LTS isomorphism), to the weaker (weak traces).Process calculi often use the notions of equivalence for systems analysisto develop a methodology for stepwise-development that allows to develop acomplex system specification into its implementation by performing a series ofcomponents substitutions with other equivalent or more refined.1.3 model checkingEven if behavioral equivalences are largely used to support system analysis,this technique is not suitable for checking whether a given system satisfies aproperty like: "at any time the system can perform the α action". To verify this kindof properties on concurrent and reactive systems, model checking techniques isneeded. Model checking (MC) verifies if the model satisfies logical propertieswritten as temporal logic formulas. Indeed, given a finite state model of a systemand a formula that describes a property by means of some appropriate logicalformalism (such as a modal or temporal logic), MC can verify if the systemsatisfies the property. The model checking is a very general technique that isapplied in various areas, such as the verification of hardware circuits, softwaresystems and network protocols.Most of the concurrent systems properties can be divided into two basiccategories: Safety and Liveness. Many other properties can be described as acombination of them. Informally, Safety category includes all those propertiesasserting that: "nothing bad happens during system execution". To satisfy theseproperty the system should never perform the avoided actions. Usually thesafety properties express invariant, i.e. conditions that has to be verified byall states of the system. One of these properties is the deadlock-freedom whichensures that all the system components will never be blocked simultaneously.On the other hand, Liveness category includes all those properties assertingthat: "something good eventually happens during system execution". To satisfy theseproperties, the system must perform some desired action. Liveness propertiesexpress that, in the future, a given condition must hold at least once, manytimes, or continuously from a certain point onwards. The properties that expressthe progress of a system are liveness properties.

8 introduction1.4 related toolsBefore starting with our project, we focused on the state of the art of formalmethods software. Several public resources provide comprehensive informationson verification tools: for Petri nets [11, 15], for Theorem prover [17, 26] and alsonot-specialized databases [7, 4, 2]. However, tools database are not well-structureand rather behind the times. The development in this area is very fast and itis difficult to keep informations up-to-date. Moreover, these database often donot support the users in choosing the tool better fit they needs. Users mustbrowse through all the (wrong, no longer existing, out-of-date) web pages, andread the informations, details and features about each of them. One of themost up-to-date resource permitting filtering by features is YAHODA [27, 70]:a verification tools database based on a relational database. This applicationmaintains structured information, and thus allows to search for tools that bestfit the desired features. At the time of writing, there are 66 tools includingTAPAs. Almost all permit model checking but only 14 permit both model andequivalence checking. Moreover only 9 of these, provides a GUI for managingprojects, but only TAPAs permits graphical specification and simulation. In thissection, we will review some representative tools and we will briefly describetheir main features.CWB-NC [66, 1] supports reachability analysis, model checking of mu-calculusand equivalence checking of various equivalences. Using this tool a numberof front ends have been implemented to support a number of different designlanguages, including: CCS [118, 117], timed CCS (TCCS, [113]), CSP [52], andBasic Lotos [147]. The model checker support three different logics for propertiesspecifications: Alternation Free Modal mu-Calculus (AFMC, [67]), Computation TreeLogic (CTL, [62]) and Generalized CTL* (GCTL*, [81]). Moreover, the equivalencechecker provides four difference equivalences: strong and weak bisimulation[118], must and may equivalences [72]. Moreover it provides a simulator forinteractive, step-by-step execution. CWB-NC is designed in a modular way sothat the analysis routines are localized in one module and independent from thespecific language used. This feature allows to change the language accepted bythe tool; however, doing so is a tedious and time-consuming task. The ProcessAlgebra Compiler of New Century (PAC-NC, [65]) help to create new languagefor CWB-NC: given a high-level description of the syntax and semantics of aspecification language, the PAC-NC generates Standard ML source code implementingan interface which allows the CWB-NC to analyze systems specifiedin the new language. CWB-NC provides both a command line interface and agraphic interface. The former is able to run on a variety of different platforms,and the latter is easier to use. Even if CWB-NC is no longer developed (the lastversion was released in June 2000), it is yet used to teach process algebras theoryand to develop complex case studies.

1.4 related tools 9LTSA [116, 8] permit specifying systems as Finite State Processes (FSP), whilethe properties are described as Fluent Linear Temporal Logic (FLTL, [115]) formulas.This tool has a simple GUI that supports: step-by-step model exploration,compositional reachability analysis and the LTS generation and graphical visualization.Moreover, the integrated model checker permits verification with respectto safety properties, specified as automata, and progress properties, specified asaction sets. For checking a property, the tool composes the target system and theproperty automata, then performs reachability analysis over the resulting LTSto detect error and deadlock states. If a system does not verify a property, it isshown the shortest trace of actions to that state. A complete set of examples aredistributed within the installation file, and a set of lecture notes can be found in[29].UPPAAL [43, 20] performs verification of safety and bounded liveness propertiesof real-time systems modeled as networks of timed automata. Timedautomata permit specifying non-deterministic processes with finite controlstructure and real-valued clocks, communicating through channels or sharedvariables. The language accepts non-deterministic guarded commands extendedwith integer variables, structured data types, and channel synchronization. Inthe last versions, it is possible to specified template: parametric automata inwhich parameters are defined during the process declaration. The GUI arecomposed of three main parts: a developing environment, a simulator and amodel checker. The developing environment has a GUI with advanced featuresand allows graphical specification of terms. The simulator can be used in threedifferent mode:step-by-step, random and trace. In the first one, the user can alwayschoose which transitions to take; in the second the tools follows a random path;in the last one, the user can execute a trace (saved or imported from the verifier)to see a possible arriving state. The model checker accepts formulas written ina fragment of CTL: it consists of state formulas and no nested path formulas.Path formulas can be classified into reachability safety and liveness. To facilitatemodeling and debugging, the model-checker may automatically generate adiagnostic trace that explains why a property is (or is not) satisfied by a systemdescription. UPPAAL development is started in 1991, and from the very firstversion (released in 1995) many improvements have been added: the runtimeand memory consumption have been reduced, the modeling language has beenextended with new data types and user defined functions, and it is augmentedthe software stability and the GUI usability. Since 2000, new tools, all based onUPPAAL, have been developed:• TIMES [24]: Tool for Modeling and Implementation of Embedded Systems isa tool set for modeling, schedulability analysis, synthesis of (optimal)schedules and executable code.

10 introduction• CORA [18]: Cost Optimal Reachability Analysis uses an extension of timedautomata called LPTA that allows to annotate the model with the notionof cost.• TRON [25]: Testing Real-time systems ON-line is a testing tool, suited forblack-box conformance testing of timed systems, mainly targeted for embeddedsoftware commonly found in various controllers.• TIGA [23]: TImed GAmes implements the first efficient on-the-fly algorithmfor solving games based on timed game automata with respect toreachability and safety properties.• COVER [19]: it is a tool for creating test suites from UPPAAL modelswith coverage specified by coverage observers also known as observerautomata.• PORT [21]: Partial Order Reduction Techniques is a tool for component-basedmodeling, simulation, and verification of real-time and embedded systemsmodeled as real-time components.• PRO [22]: Probabilistic timed automata is an extension of UPPAAL whichsupports probabilistic reachability for probabilistic timed automata.PEPA Eclipse Plug-in [144, 10] is a tool for the development and the analysisof stochastic systems. Models are described by using PEPA [87]: a stochasticprocess algebra that extends classical process algebra by introducing probabilisticbranching and timing of transitions. This algebra offers several interestingfeatures such as compositionality, formality and abstraction. The project is deployedas a contribution to the Eclipse framework [3] and it is designed as a set ofplug-ins which perform various tasks. This tool permits four different kind ofanalysis: Markovian analysis, simulation, ODE analysis and model checking.In Markovian analysis, the tool generates a Continuous Time Markov Chain(CTMC) of a given model, and then it performs steady-state analysis providingthree main measures: Utilization, Throughput and Population. The first one showsutilization of each top-level component, the second one lists the rate at which theactions are performed, and the last one indicates the average number of copiesof a sequential component. In an effort to reduce the state explosion problem,it is implemented the aggregation algorithm presented in [88]. Informally, thealgorithm creates a partition of the state-space and then replace each set ofstates with a macro-state. Even if aggregation allows to handle larger models,it still suffers from state space explosion. In order to scale with larger models,PEPA provides discrete and continuous simulation: the former is supported byusing Gillespie’s Stochastic Simulation Algorithm (SSA) [86], while the latter byusing Fluid Flow Approximation [99]. The model checker accepts ContinuousStochastic Logic (CSL, [36, 40]) formulas, but the action performed by the model,

1.4 related tools 11can not be used as atomic properties. The properties have to be added manuallyby the user that has to labels every interesting state in the abstract view withthe chosen names.MRMC [105, 9] is a command-line model checker for discrete-time and continuoustime Markov reward models. It supports few types of probabilisticmodels: Discrete Time Markov Chains (DTMCs), Continuous Time MarkovChains (CTMCs), Discrete Time Markov Reward Models (DMRMs), ContinuousTime Markov Reward Models (CMRMs) and Continuous Time Markov DecisionProcesses (CTMDPIs). MRMC allows automated verification of properties concerningsteady-state and instantaneous rewards as well as cumulative rewards.The properties can be expressed in one of the following logics: ProbabilisticComputation Tree Logic (PCTL, [96]), Continuous Stochastic Logic (CSL), ProbabilisticReward Computation Tree Logic (PRCTL, [34]) and Continuous StochasticReward Logic (CSRL, [106]). Moreover it permits both formula-dependent andformula-independent bisimulation; the formulas for the minimization can bewritten in PCTL, CSL, PRCTL and CSRL (for the latter two without impulserewards.)PRISM [112, 13] is deployed in two version, one based on a graphical userinterface, the other based on a command line interface. It can perform modelchecking over three different structure: DTMCs, CTMCs and Markov DecisionProcesses (MDPs). In the last version, it has been added new features such as:the ability to create models with cost and rewards, a step-by-step simulatorand a distributed approximate model checker. Last tool paper [100] presents anhigh-level overview of PRISM including all features and addictions. This toolsupports four different temporal logics: PCTL, CSL, LTL and PCTL* [38], as wellas extensions for quantitative specifications and costs/rewards, and it allows toeither compute the exact probability, or determine whether it is within a givenbound. Moreover it provides many other powerful ability, such as check theworst-case (or best-case) scenarios. PRISM has been used to create a wide rangeof case studies in many different research area. The website [12] lists about fiftycase studies which include performance analysis, reliability or correctness of:randomized distributed algorithms, communication and multimedia protocols,security, biological process modeling, power management systems, reliabilitystudies, game theory.To allow interconnections, many tools allow to import/export models in avariety of others formats. For example PRISM can export its project in MRMCformat, while MRMC can accepts PEPA formats.

12 introduction

TA PA S2In this Chapter we will introduce TAPAs project and a few basic definitions about ProcessAlgebras; then we will present a set of behavioral equivalences and two temporal logics:µ − calculus and ACTL. In the second Section, we will describe TAPAs plug-insarchitecture design and the analysis features provided by TAPAs main applications:Model Checker, Equivalence Checker, Minimizer and the step-by-step interactive navigator.Finally we will describe TAPAs algorithm for generating counterexamples forinequivalent systems.TAPAs [54, 16] aims at providing a software environment for supportingspecification through a set of process algebras. A complete infrastructure inwhich new automatic tools or existing ones can be simply easily deployed orintegrated. In order to obtain a modular structure, TAPAs is designed with aplug-in structure: a main module (called Kernel) provides a set of functionalitiesuseful to every plug-ins each of which adds support for a specific processalgebra.By relying on sophisticated graphics interface TAPAs allows users to specifyand analyze concurrent systems, supporting them throughout all the developmentprocess. As in all graphical tools, graphical interfaces are crucial to thesuccess of a tool. Over the years we have seen how a poor GUI not only does nothelp, but it can also slow down the development process. Moreover, the lack ofsome features, or worse, their poor implementation can be very frustrating forthe users. The success of a software tool, especially a didactic tool, also dependson graphical features that increase its usability. For example TAPAs providesfacilities for saving settings on exit (opened windows, recently opened files orprojects, . . . ), managing project (save all project files in a single compressedfile, save project settings, . . . ), changing features parameters and for displayingresults. Although these features may seem trivial and obvious, it is importantto note that not all the tools (especially didactic tools) make them available.Obviously, their absence does not affect the tool performance, but it affects theuser perception and, more importantly, the speed of development.TAPAs Model Checker permits deciding whether or not a model satisfies logicalproperties. The model checker takes as input both µ-calculus and ACTL formulas.Because of a more intuitive temporal operators set, ACTL turns out to be moreuser friendly than µ-calculus.TAPAs can be used to analyze concurrent systems also by using EquivalencesChecker that permits verifying two kind of equivalences between pairs of systems:13

14 tapasbisimulations based equivalences such as strong, weak and branching [118, 150],or decorated trace equivalences, such as weak and strong variants of trace, completedtrace, divergence sensitive trace, must and testing [101, 72]. Equivalencechecker algorithms are also used for implementing a LTSs Minimizer that permitsreducing the size of LTS preserving the intended behavior.Moreover TAPAs provides a navigator for helping users in debugging thespecification by a step-by-step interaction. The user may examine the state of themodel and its sub-components before and after execution of a particular action.The navigator shows the components of the system and all the available actions;after an action is performed the system status is updated with new informations.This allows to evaluate the effects of that action and thereby gain insight intothe behavior (or misbehavior) of the model evolution.In Section 2.1 few backgrounds definitions are introduced. In Section 2.2 ispresented the philosophy that has guided us in TAPAs development, the designchoices and its overall plug-ins architecture. In Section 2.3, it is shown mainmodules and how plug-ins exploit their functionalities. In Sections 2.4 and 2.5,TAPAs Model and Equivalence Checker are presented.2.1 backgroundsThere are several approaches to describe semantics of process calculi. From theoperational point of view we can use transition graphs and describe the behaviorof processes in terms of states and transitions between states. The two mostcommonly used types of graphs are Kripke Structures (KS) introduced by Kripke[111] in 1963 and Labeled Transition Systems (LTS) introduced by Keller [107] in1976. In the first case the states of the graph are labeled to describe how theyare modified by the transitions, in the second case, as the name implies, thetransitions are labeled using the actions that cause the status change.Actions represent atomic (i.e. non-interruptible) computational steps that areperformed by a system to evolve from one state to another. There are two kindsof actions that a system can perform: interactions with the environment orinternal computations. The former occur through specific ports or communicationchannels of the system, and in this case is said to be external or visible action. Thelatter describe system internal steps that can not interact with the environmentand is called internal action.In some process calculi such as CCS, external actions are conventionally dividedinto inputs, denoted by the same name as the port/channel on whichthey occur, and output actions, indicated by the name of the port/channel onwhich they occur, with a bar over the name. The actions a and ā are complementaryand have a key role in the interaction which can occur only between twoprocesses running in parallel that perform simultaneously two complementaryactions. Intuitively, when a process performs an input action a, it receives a

2.1 backgrounds 15signal on the channel a, when performs an action ā, it emits a signal throughthe channel a. In other calculi, such as in CSP, no distinction is made betweeninput and output actions, so they have the same name of the channel on whichthey occur. In this case the interaction can occur between any number of parallelcomponents performing simultaneously the same action.Internal actions are so named because are unobservable and therefore notdistinguishable each other, so just a symbol (generally τ) is used to denotethem. Internal computations can be the result of an interaction between systemcomponents specified at a lower level of abstraction. In some calculi such asCCS, this feature is also reflected by the fact that action τ is the visible resultof the simultaneous execution of two complementary actions by two parallelcomponents.Labeled Transition Systems (LTS) were introduced by Keller [107] as a formalmodel to describe parallel programs and later were used by Plotkin [123] to givea Structural Operational Semantics (SOS) to programming languages.Definition 2.1.1 (LTS) A Labeled Transition Systems (LTS) is a triple (S, A, →),where S is a set of state, A is a set of labels and →⊆ S × A × S is a transition relation.If p, q ∈ S and α ∈ A then (p, α, q) ∈→ is written as: p −→ α q.We now introduce some notations and definitions that will be use further.Given an LTS (S, A, →), we define I(p) as the set of all actions outgoing from p,more formally: I(p) = {a ∈ A|∃p ′ : p −−→ α p ′ }. Symbols ρ, θ indicate paths:sequences of the form (q 0 , α, q 1 )(q 1 , α, q 2 )(q 2 , α, q 3 ) . . . where every triple(q i , α, q i+1 ) ∈→. A path can be finite or infinite and can contain loops. Thereexist null path corresponding to an empty sequence. In the following p, q, . . .represent states, α, β . . . visible actions, µ both a visible and invisible action, sa finite sequence of actions and ɛ the empty sequence. Sometimes we will useapex or subscript for labeling states (p 1 , q ′ ), actions (α 1 , β ′ ) or paths (ρ 1 , θ ′ ).The state q is an α-derivative of p, if p −−→ α q. Given a sequence of actionss = α 1 . . . α n , q is a s-derivative if p α 1 α−−→ · · · −−−→nq.Given the relation −→, we define a new relation =⇒∈ S × A × S that considerinvisible actions in a special way. We will write p =⇒ α q if p ( tau−−−→ ) ∗ α −−→( tau−−−→ ) ∗ , and q is called an α-descendant of p. The α-descent corresponds tothe α-derivative preceded and followed by zero or more τ actions. Given thesequence s = α 1 . . . α n , we will write p =⇒ s q if p α 1 α=⇒ · · · =⇒nq and q is ans-descendant of p.In some cases we may be interested only to the ability of a state to perform anaction α or sequence of actions s, abstracting from reached state. We will writep −−→ α α(p −−→) ̸ if p can (can not) perform α. The meanings of the notations p −→,ssp ̸ −→, p =⇒, α αp ̸=⇒, p =⇒, s sp ̸=⇒ can be gathered from the previous definitions.

16 tapas2.1.1 Behavioral EquivalencesIn this section we will introduce some observational equivalences that allowto compare two representations of a system design abstracting from irrelevantinformation. The semantics definitions will be given without reference to aspecific set of operators. This is made possible by the fact that every process canbe represented as an LTS by means of SOS. These equivalences definitions maybe provided for specific process calculus without any changes.Observational semantics will be defined as relations between states of the sameLTS, rather than between states of two different LTS. This is because sometimeswe will compare the states of the same LTS. Obviously, the definitions can beeasily applied to two LTSs, just applying them to the union of the two LTSs.The equivalences that we will consider can be grouped into two broad categories:strong equivalences and weak equivalences. In the first ones, the visibleand invisible actions are all considered in the same way. In the second ones theinvisible actions (τ actions) are considered not-observable, in other words it cannot be observed by an external observer.Strong BisimulationBisimulation is an equivalence relation that associates systems which behave inthe same way in the sense that one system simulates the other and vice-versa.Intuitively, if two systems are bisimilar, it is possible for one to simulate thebehavior of the other: hence the term bisimulation. In this sense, a system cannotbe distinguished from the other by an observer. More specifically, a relation is abisimulation if the related states must be able to perform the same transitions,moving to states that are still related. Two states are equivalent when there is abisimulation relation that contains them.Definition 2.1.2 (Bisimulation) Let (S, A, →) be an LTS. The relation R ∈ S × S isa bisimulation if, given p and q such that 〈p, q〉 ∈ R then:1. For all α ∈ A and p ∈ S, if p −−→ α p ′ then exists q ∈ S such that q −−→ α q ′ and〈p ′ , q ′ 〉 ∈ R.2. For all α ∈ A and q ∈ S, if q −−→ α q ′ then exists p ∈ S such that p −−→ α p ′ and〈p ′ , q ′ 〉 ∈ R.Weak BisimulationWeak bisimulation is a less discriminating version of strong bisimulation. Theweak equivalence aims at decreasing sensitivity to the internal action of strongone. The definition of this relation is based on the idea of considering internalaction in a special way, so that when a system performs internal action, the other

2.1 backgrounds 17system can respond performing any number (including zero) of internal actions.First we introduce a new notation.Definition 2.1.3 Let (S, A τ , →) be an LTS, with A τ = A ∪ {τ}. If s ∈ (A τ ) ∗ is asequence of action, then ŝ is a visible actions sequence (possibly empty), obtained deletingall invisible (τ) actions from s.Intuitively, ŝ is the "visible content" (that is, elements other than τ) of s, and itcan be defined inductively on the length of s, in particular, given µ ∈ A τ ,̂µ ={ɛif µ = τµ if µ ≠ τwhere q =⇒ s q ′ indicates that q can perform a sequence of transitions withthe same visible content of s and then evolves in q ′ . In this case, note that thecomplete sequence of visible transitions is the same as s except that it maycontain an arbitrary number of τ transitions between the visible actions of s. Theweak bisimulation can be defined as follows.Definition 2.1.4 (Weak Bisimulation) Let (S, A, →) be an LTS. The relation R ∈S × S is a bisimulation if, given p and q such that 〈p, q〉 ∈ R then:1. For all α ∈ A and p ∈ S, if p =⇒ ̂α p ′ then exists q ∈ S such that q =⇒ α q ′ and〈p ′ , q ′ 〉 ∈ R.2. For all α ∈ A and q ∈ S, if q =⇒ ̂α q ′ then exists p ∈ S such that p =⇒ α p ′ and〈p ′ , q ′ 〉 ∈ R.Branching BisimulationThe Branching Bisimulation is in between strong and weak bisimulation, becauseon the one hand it treats internal actions in a special way (as weak bisimulation),on the other other it does not ignore all intermediate states traversed by performinginternal actions and it preserves the branching structure of systems (asstrong bisimulation). Intuitively, the branching bisimulation is a way to matcha state making an action to another that, in order to perform the same action,perform several internal actions going through equivalent states.Definition 2.1.5 (Branching Bisimulation) Let (S, A, →) be an LTS. The symmetricrelation R ∈ S × S is a branching bisimulation if, given α ∈ A τ , p and q such that〈p, q〉 ∈ R then one of the following condition holds:1. α = τ and 〈p ′ , q〉 ∈ R2. There exist q ′ , q ′′ ∈ S such that q =⇒ q ′ α −−→ q ′′ and 〈p, q ′ 〉, 〈p, q ′′ 〉 ∈ R.

18 tapasDecorated TraceThe approach of the decorated trace relations is based on an explicit notion ofobserver carrying out tests on the systems under observation. In this scenario, itis important not only to know whether a process pass a specific test, but even ifthe process is responding in a consistent manner each time the test is performed.More specifically, two processes are equivalent if they pass the same tests. Asystematic investigation on decorated trace equivalences is presented in [148]and [149] where all the known behavioral equivalences and preorders over LTSsare described and ordered by inclusion. In these papers author presents thelinear time/branching time spectrum motivating decorated trace equivalencesin terms of button pushing experiments of testing scenarios on reactive systems.An observer performs an observation on a process by attempting to press one ofmany buttons that a process exposes as interface to the external environment.The observation succeeds if the button is enabled and therefore goes down, failsotherwise. In response to a successful experiment, the process change its stateand is then ready for another observation.This gave rise to a characterization in terms of observations that an observercould make interacting with a process. We can imagine a set of systems anda set of tests, two systems are equivalent (with respect to this set) if they passexactly the same tests. The set O of observation δ is defined as follows: Let A bea set of actions, the set O of all potential observations is defined inductively by:• ⊤ ∈ O: the trivial observation.• αδ ∈ O: if δ ∈ O and α ∈ A. The observation of action α followed by theobservation δ.• ˜α ∈ O: for all α ∈ A. The observation that the process can not perform α.• δ 1 ∧ δ 2 ∈ O: if δ 1 and δ 2 ∈ O, the process admits both δ 1 and δ 2 .• ¬δ ∈ O: if φ ∈ O, it can be observed that δ cannot be observed.Let O be a set of observations, L = (S, A, →) an LTS and p ∈ S, the satisfactionrelation telling which observation are possible for which state is defined inTable 1.We will use I, J to indicate generic set and ∧ i∈I α i as an abbreviation ofα 1 ∧ . . . ∧ α n with i ∈ I. Here below, several subsets of O have been defined:O T δ ::= ⊤ ∣ αδ ′ (δ ′ ∈ O T ) trace formulasO CT δ ::= ⊤ ∣ αδ ′ (δ ′ ∈ O CT ) ∣ ∧ α∈A ˜α complete trace formulasO F δ ::= ⊤ ∣ αδ ′ (δ ′ ∈ O F ) ∣ ∧ i∈I ˜α i failure formulasO R δ ::= ⊤ ∣ αδ ′ (δ ′ ∈ O R ) ∣ ∧ i∈I ˜α i ∧ ∧ j∈J β j⊤ readiness formulas

2.1 backgrounds 19p |= ⊤ truep |= αδ iff ∃ p ′ : p −−→ α p ′ and p ′ |= δp |= ˜ααif p ̸−−→p |= δ 1 ∧ δ 2 iff p |= δ 1 and p |= δ 2p |= ¬δ iff p ̸|= δTable 1: Observation satisfaction relationsIn [148] and [149] the author shown that fourteen different decorated equivalencecan be defined by means of an observations (sub-)sets. For example twostates p and q are:• Trace equivalent iff ∀ δ ∈ O T (p |= δ ∧ q |= δ)• Completed Trace equivalent iff ∀ δ ∈ O CT (p |= δ ∧ q |= δ)• Failure (MUST) equivalent iff ∀ δ ∈ O F (p |= δ ∧ q |= δ)• Readiness equivalent iff ∀ δ ∈ O R (p |= δ ∧ q |= δ)2.1.2 Temporal LogicsTemporal logics allow to express properties qualified in terms of time for reasoningabout reactive and concurrent systems behavior. Many variants of temporallogic have been studied over the past 20 years. Two of the most used logics toexpress properties are the modal logics and temporal logic. Modal logic formulasare local, (or next-step properties) in the sense that they allow only the immediatecapabilities for interaction (and internal action) of a process to be described.For example, they can not state that a certain property is valid always (in everystate of the system) or from a certain point in the future. Properties involvingtime constraints can be expressed by means of temporal logics. These kind oflogics can be divided into two broad categories: Linear Time (LTL, HML) andBranching Time (µ − calculus, CTL and ACTL). Linear Time logics have the abilityto reason about a single time line. These logics consider a system as the set of allpossible computations (execution sequences) and allow to express properties onthe individual computations of a system. Branching Time logics can reason aboutmultiple time lines and their model of time is a tree-like structure in whichthe future is not determined; there are different paths in the future, any one of

20 tapasφ ::= tt ∣ ∣ ff∣ ∣ ¬φ∣ ∣ φ1 ∧ φ 2∣ ∣ φ1 ∨ φ 2 Boolean Op.∣ 〈A〉φ ∣ ∣ [A]φ∣ ∣ 〈〈A〉〉φ∣ ∣ [[A]]φ∣ ∣ 〈〈〉〉φ∣ ∣ [[]]φ Modal Op.∣ µX.φ ∣ ∣ νX.φ Fixpoints Op.A ::= {α 1 , . . . , α n } ∣ ∣ − {α1 , . . . , α n }Table 2: µ − calculus syntaxwhich might be an actual path that is realized. Branching Time logics containsoperators that allow explicit quantification over the different possible futures.These two types of logics, however, are not comparable in terms of expressivity.µ − calculusOne of the most powerful temporal logic is µ − calculus: a branching-time logicthat use the modal logic operators with least (µ) and greatest (ν) fixed pointoperators to express temporal properties. This logic is action-based and so it isparametric to a set of action A. The µ − calculus syntax is defined in Table 2.Notice that the symbol "−", is used to indicate the complementary set withrespect to A. The notation −{α 1 , . . . , α n } is equivalent to A\{α 1 , . . . , α n }.A formula is well-formed if in every subformula of µX.φ (νX.φ) the variable Xoccurs positively, i.e within a scope of an even number of negations. A formulais closed if it does not contain free variables, where the only binding operatorsare µ and ν. For the concrete syntax, we will assume that modal operatorshave higher precedence than boolean, and that fixpoint operators have lowestprecedence, so that the scope of a fixpoint extends as far to the right as possible.The operators can be informally explained as follows (please note that formulasmust be interpreted with respect to the states of an LTS). Symbols tt (ff)represents constant formula that holds for every (any) state. Symbols ¬, ∧, ∨represent the three standard boolean operators: negation, conjunction and disjunction.The six modals operators allow to formulate properties of a systemin terms of transitions outgoing from a state. The diamond operators (strongdiamond 〈A〉 and weak variants 〈〈A〉〉, 〈〈〉〉) express the possibility, for examplea state satisfies 〈α〉φ if one of its α−derivatives satisfies φ. The box operators(strong box [A] and weak variants [[A]], [[]]) express the necessity, for examplea state satisfies [α]φ if all its α−derivatives satisfy φ. The least and greatestfixpoint operators are used to express recursive properties: the former for propertiesthat eventually will be true, the latter for properties that are always true.

2.1 backgrounds 21 tt = S〈〈〉〉φ = { q|∃q ′ ∈ S, q ⇒ q ′ ∧ q ′ |= φ } ff = ∅[[]]φ = { q|∀q ′ ∈ S, q ⇒ q ′ ∧ q ′ |= φ } ¬φ = S\ φ〈〈α〉〉φ = { q|∃q ′ ∈ S, q ⇒ α q ′ ∧ q ′ |= φ } φ 1 ∧ φ 2 =φ 1 ∩φ 2 [[α]]φ = { q|∀q ′ ∈ S, q ⇒ α q ′ ∧ q ′ |= φ } φ 1 ∨ φ 2 =φ 1 ∪φ 2 〈α〉φ = { q|∃q ′ ∈ S, q → α q ′ ∧ q ′ |= φ } νX.φ = ⋃ { } E ⊆ S|E ⊆ φ[E/X] µX.φ = ⋂ { }E ⊆ S|φ[E/X] ⊆ E [α]φ = { q|∀q ′ ∈ S, q → α q ′ ∧ q ′ |= φ }Table 3: µ − calculus satisfaction relationHowever, the set of operators shown in Table 2 is not minimal, indeed some ofthem could be eliminated without affecting the expressive power of logic. Wechose to give a non-minimal syntax in order to show all the operators acceptedby TAPAs.The semantics of closed and well-formed formulas, are defined on generic LTSof the form (S, A, →). The satisfaction relation associates to each well-formedformula φ the set of states E ⊆ S that satisfy it. Notice that in the fixpointoperators µX.φ and νX.φ the φ formula correspond to a function g : 2 S → 2 Sthat associates to E the set defined by φ[E/X]. Table 3 shows the satisfactionrelation defined for induction over the formulas structure. We chose to definethe satisfiability relation for all operators and not only for the minimal subset tofacilitate their understanding.Action-based Computational Tree LogicAction-based Computational Tree Logic (ACTL) is a propositional branchingtimetemporal logic derived from CTL (Computational Tree Logic). However,they are defined on different structures CTL is interpreted over KS while ACTLis interpreted over LTSs. As in µ − calculus, ACTL is parameterized on a set ofaction A.As shown in Table 4, state formulas include standard boolean operators(¬, ∨, ∧), path quantifiers, ∃ ("there exists a path") and ∀ ("for all paths") usedfor describe the branching structure of the computation tree. When existentialpath quantifier ∃ is used, the property expressed by the following path formulahas to hold in at least one path starting from the given state. Otherwise, when

22 tapasState formulasPath formulasφ ::= tt ∣ ∣ ff∣ ∣ ¬φ∣ ∣ φ1 ∧ φ 2∣ ∣ φ1 ∨ φ 2∣ ∣ ∃ γ∣ ∣ ∀ γγ ::= X χ φ ∣ ∣ Xτ φ ∣ ∣ φ χ U χ ′ φ ′ ∣ ∣ φ χ U φ ′ ∣ ∣ F φ∣ ∣ G φAction formulas χ ::= α ∣ ∣ ¬χ∣ ∣ χ ∧ χ′ ∣ ∣ χ ∨ χ′Table 4: ACTL syntaxuniversal path quantifier ∀ is used, the property expressed by the following pathformula has to hold in all paths starting from the given state.Path formulas are used to express temporal properties about paths: X ("for thenext state"), U ("until"), F ("for some state in the future"), and G ("for all statesin the future"). The formula Xφ means next time, the property φ has to hold atthe next state (this operator is sometimes noted N instead of X). In the formulaφ U φ ′ , φ has to hold until at some state φ ′ holds. This implies that φ ′ will beverified in the future. Formula Fφ eventually has to hold (somewhere on thesubsequent path), while Gφ has to hold on the entire subsequent path.Action formulas specify a set of visible actions; from now on, the derivedactions formulas true (α ∨ ¬α) will be used to indicate the set of all visibleactions, while false (α ∧ ¬α) stands for the empty set of visible actions. In orderto show all the operators accepted by TAPAs the set of operators is not minimal.Satisfiability for ACTL formulas is inductively defined over labeled transitionsystems (LTS). Given a generic LTS 〈S, A, →〉 with q ∈ S and α ∈ A, where ρ, θindicate generic paths, and path(q) indicates the set of all paths starting from q.The semantic rules shown in Table 5 inductively define the satisfaction relationfor: action formulas χ by an action α (written χ |= α), state formula φ by a state q(written q |= φ), and path formula γ by a path ρ (written ρ |= γ)Satisfaction of action formula χ by an action α (written χ |= α), state formulaφ by a state q (written q |= φ), and path formula γ by a path ρ (written ρ |= γ)is given inductively by the semantic rules shown in Table 5.ACTL is more expressive of HML because, however, is able to describe all thebehaviors of a finite state LTS. ACTL is also powerful enough to express safetyand liveness properties of concurrent systems without adding recursion, whichis used in the µ − calculus. However, compared to µ − calculus, ACTL lacksthe ability to express cyclic properties of a system. However, this lack can beovercome by introducing the least fixed point operator, which can be used toderive the dual greatest fixed-point operator and obtaining the logic µ − ACTLwhich is as expressive as the µ − calculus.

2.2 design of tapas 23q |= tt for all q ∈ S.q |= ¬φ iif q ̸|= φ.q |= φ ∨ φ ′ iif q |= φ or q |= φ ′ .q |= ∃ γ iif ∃ ρ ∈ path(q) such that ρ |= γ.q |= ∀ γ iif ∀ ρ ∈ path(q) such that ρ |= γ.ρ |= X χ φ iif ρ = (q, α, q ′ )θ, q ′ |= φ and α |= χ.ρ |= X τ φ iif ρ = (q, τ, q ′ )θ and q ′ |= φ.ρ |= φ χ U χ ′φ ′ iif exists θ = (q, α, q ′ )θ ′ suffix of ρ, such that q |= φ, α |=χ ′ , q ′ |= φ ′ and for all suffixes θ 1 = (q 1 , β, q1 ′ ) of ρ, such thatθ is a proper suffix of θ 1 , then q 1 |= φ and β |= χ or β = τ.ρ |= φ χ Uφ ′ iif exists θ = (q, α, q ′ )θ ′ suffix of ρ, such that q |= φ and forall suffixes θ 1 = (q 1 , β, q1 ′ ) of ρ, such that θ is a proper suffixof θ 1 , then q 1 |= φ and β |= χ or β = τ.α |= β iif α = β.α |= ¬χ iif α ̸|= χ.α |= χ ∨ χ ′ iif α |= χ ∨ α |= χ ′ .Table 5: ACTL satisfaction relation2.2 design of tapasSoftware development in academic environment can be subject to many problems.Usually there is not a dedicated group to tools development, but manypeople take it in turns in development phase experiencing communication difficulties.They work autonomously, at different times, on separated features.In addition, often neither the objectives nor the road-map is clear from theoutset. Usually software projects start with a small number of features thatwill be gradually increased, modified or removed. Furthermore the softwaredevelopment can be temporarily suspended, due to priorities changes withinthe research group.To avoid problems related to developers interaction and non-continuous development,we decided to adopt an Agile-like methodology (for Agile cfr. [98]).This development technique is particularly suitable in academic environmentwhere people can be involved with very different time and roles. This approachfits with this context where different kind of developers can be involved in theproject: Master and Graduate Students are involved from 3 to 6 months anddevelop just a feature; PhD Students are involved for years (typically from 3to 5) but do not spend all the time in the project, and they deal to integratedifferent features into a single module; and supervisors can follow the wholedevelopment process, overseeing the work and advising on the direction to

24 tapastake. The iterative and incremental development, permits breaking tasks intosmall software projects (typically the workload required by a Master Thesis)without the need to have a fixed long-term planning. Every new feature developmentinvolves students through a full software development cycle, including:requirements analysis, coding, testing, documentation writing and, sometimes,integration. Students are advised to "Code a little, test a little", while we havefollowed the Agile principle "Release Early, Release Often". This is proved by thenumber of versions released every year: 8 versions in 2008, 12 version in 2009and 14 versions in 2010.In order to use an Agile-like development model, we paid particular attentionduring the design phase taking into account its futures extensions and possiblychanging in development team. TAPAs was designed as a framework composedof sub-components as much as possible independent. A main module providesboth the features for analyzing modules and the utilities that support all themodels development process. Every Process Algebra module is implemented ina separated plug-in that interacts with the main application. In this way, addingor modifying features do not require an overall code refactoring, i.e. the changesare localized as much as possible.From the beginning, one of the main goals was to build an "open" tool thatcan be extended by other than our research groups. The idea was to allow andfacilitate the integration of new features, even by people who did not have theknowledge of the entire project. For this reason we placed a lot of attention tothe code extensibility and reusability. Through the use of appropriate design andprogramming techniques, it is relatively simple to ensure adequate extensibility.For example, design patterns [84] and Java generics [120] give programmersan high-level widespread languages for easing the design of software applications.Design patterns allow us to break down a complex applications into manysimpler components and to apply proven and known solutions to commonlyoccurring design problems. Given their extensive use in software design, theyimprove code readability for programmers who are familiar with used patterns.Moreover all the patterns are documented in a wide variety of formats (books,tutorial, examples), this allowed us to make the communication between developerseasier, simplify the documentation writing. Java Generics add stability tocode by making more bugs detectable at compile time. Moreover they increasesthe tests lifetime and localizes modifications when a change is required.2.2.1 InfrastructureTo increase extensibility, TAPAs was designed to reduce the level of effortneeded to implement new features, while avoiding (or minimizing) impact toexisting system functions. It is designed using a plug-in structure: a kernelprovides foremost features, and every new process algebra is deployed as a new

2.2 design of tapas 25Generics moduleskernelTAPAs UtilsTAPAs EngineuseextendConcrete modulesCCSP Plug-inStoKlaim Plug-inCCSP UtilsCCSP EngineStoKlaimEngineStoKlaimUtilsPEPA Plug-inPEPA UtilsPEPA EngineFigure 1: TAPAs structureplug-in. The plug-in architecture is designed to include hooks and mechanismsfor expanding the system with new process algebras without having to makeany changes to the main infrastructure, but just copying the right file in theright place. In the further sections we will show how to develop and deploy anew Process Algebra Plug-in (PAP), using as example three already developedplug-ins: CCSP Plug-in, PEPA Plug-in and StoKlaim Plug-in.Provide a high-grade of reusability has been a more complicated task, especiallyfor the GUI components. The appearance is an important aspect for allGUI tools, in particular for didactic tool. Indeed, to facilitate learning process, didactictools need to provide a set features for increasing their usability. Althoughthese do not affect the tools performance, are very important to support studentsthroughout the process development and their absence (or poor implementation)can be very frustrating for them. Unfortunately, the creation of these features isa time consuming task, both in development phase and in testing phase. It isimportant to note that many tools are developed without any graphic features,and, only after, a GUI is developed. Generally the first graphic interface onlysupports the "projects management" and the graphical specification is providedat a later stage.To facilitate the development of new PAPs, we provide a set of graphicalfeatures that can be used in every new plug-in. The reuse of these componentsrelieves future developers from the need to create nice and correct GUI. In thisway, a developer can extend TAPAs focusing only on the back-end, devotingmuch time to code functional modules; the native graphics components guaranteea minimum level of usability. We believe that this choice will be crucial forTAPAs success as teaching tool.

26 tapasFigure 1 gives an overview of TAPAs architecture: the kernel (above) containsgenerics modules (TAPAs Engine and TAPAs Plug-in), while the CCSP Plug-inand PEPA Plug-in (below) contain the modules for CCSP and PEPA respectively.In TAPAs Engine module there are all the kernel algorithms used for key features,such as: graph generation, model checking, equivalence checking and minimization.In TAPAs Plug-in module, there are the classes for: abstract plug-in, graphicpanels and projects management.For managing PAP, we use Java Plug-in Framework (JPF, [5]) an open source,LGPL licensed plug-in infrastructure library for Java projects. JPF permits buildingplug-in based infrastructures that dynamically discovers and loads plug-ins.A plug-in is a structured self-describing component providing features (codeand resources) to the main application in a structured way. When a new plug-inis found, JPF adds an item in the registry of available plug-ins and stores thefunctions provided. These plug-ins define extension points, namely well-definedmethods that can be extended by other plug-ins. With such architecture, TAPAsoperates independently of the plug-ins, and it is possible for developers toadd, modify and then deploy a PAP without knowing any TAPAs kernel implementationdetails. This approach allows to build an highly modular and easilyextendible application.2.3 the kernel modulesIn this subsection, we will detail the modules composing the kernel. First we willintroduce the main modules for the TAPAs Engine and then we will describe themajor TAPAs Plug-in features. One of the our aims was to build not only a tool,but a framework in which new process algebra plug-in can be easily added. Inorder to make the system independent from a specific process calculi, the engineis parameterized with respect to process algebra.The main aim of every process algebra is to allow users to build and analyzemodels. All the analysis algorithms (and few others features) are based onLTS. In (almost) every PA, the operators semantics are given by means ofStructured Operational Semantics (SOS, [124]) and it is used to describe how termsis interpreted as sequences of computational steps. The basic idea behind SOSis to define the behavior of a program in terms of the behavior of its parts. AnSOS rule is an inference rule that defines the valid transitions of a compositeoperator in terms of the transitions of its components. In other word, given thecomponents behavior, the SOS rule defines the evolution of a composed termsspecifying the current state, the computational step and the new term state.Hence a term evolution can be characterized with an LTS in which every LTSstate is associated to a term state and edges to computational steps.TAPAs is not tied to a specific process algebra, so kernel modules is still ableto generate the LTS associated to a term of a generic process algebra. Since basic

2.3 the kernel modules 27LTS components are states and actions, TAPAs main classes are parameterizedon state and action which depend on the specific process algebra. For examplea state can be just a string used for identified it, while action can be a string(identifying the channel’s name) with a symbol identified the modality (inputor output), or it can be coupled with a rate, a probability or time of execution.In order to represent the structures of processes in a lightweight manner, weused the Composite pattern. This pattern aims to "compose" processes into atree structures to represent the hierarchical relation "operator-operands": theinternal nodes represent the operators, their children the operands; while theleafs correspond to PA constants.Thus, the semantics of each operator is defined over the structured operationalsemantic rules. In all the process algebras, the operator semantic is described bymeans of the following notation:P α → P ′Intuitively, process P performs action α and then behaves as P ′ . The operationalsemantic describes the process evolution and permits building theassociated derivation tree. The interface APProcess aims at capturing this characteristic;there are three methods that return all the possible evolution of aprocess:1. getNext(): return all the process evolutions.2. getNext(Action a): return all the process evolutions in which a is the actionperformed.3. getNext(Filter f): return all the process evolutions verifying thefilter f.where Filter is an interface parametric on Action that permits filteringthe evolution of the operator: only the actions that pass the filter are consideredin building results. For every process algebra operator, a class implementing theAPProcess interface has to be created. Its semantics is defined by returning thelist of all possible process evolutions in terms of outgoing actions and reachablestates.Figure 2 shows the Engine structure: a process of a generic process algebra(APProcess) can be expanded (by APGraph) to create the corresponding LTS(IGraph), in which a set of states (IState) are connected by labeled links (IAction).These data structures are used as basis for all types of analysis. IState andIAction represent the most abstract state and action definitions: they both havean attribute to identified them, and IAction also has a boolean attribute todetermine whether the action is visible or not. Because APProcess implementsIState, APGraph can associate a state to each process and then, given a derivationtree, build the associated LTS. The classes IGraph, APGraph, APProcess and

28 tapasextenduseIActionIStateLogical formulaAPProcessIGraphACTLEq. checkerµ-calculusModel checkerAPGraphMinimizerFigure 2: TAPAs engineLogicalFormula are all parameterized with two parameters: the notion of state andthe notion of action. Given two appropriate subclasses, it is possible instantiateobjects whose methods use and return only subclasses objects. More formally,they are declared as follows:IGraphAPGraphAPProcessLogicalFormulaGenerics allowed us to build most kernel algorithms without specify the typeof the object they operate with. In order to refer to not-already-specified types,they use placeholder that will be replaced by a concrete type, so we no longerneed to cast to a type since the methods return references to objects of a specifictype.To analyze concurrent systems Model Checker (MC) permits deciding whetheror not a model satisfies logical properties. TAPAs MC takes as input both µ-calculus and ACTL formulas. Because of a more intuitive temporal operatorsset, ACTL turns out to be more user friendly than µ-calculus.Although this technique is efficient and automated, its main limitation is thestate explosion problem, which occurs when models are too large to fit in computermemory. For handling models with a large state space, TAPAs implementstwo On-The-Fly Model Checking Algorithms: one [153] for µ − calculus, and theother [46] for ACTL. These algorithms do not need to pre-generate all the statesspace, they build it in an incremental way, decomposing the given formulain sub-formulas. Only a portion of the model needed to check the formula isexpanded, namely the portion whose exploration is essential for determiningthe satisfaction/unsatisfaction of the specification.

2.3 the kernel modules 29TAPAs UtilsPlug-in UtilsGUIPlug-in ManagerProject Man.TAPAs EnginePlug-in RegistryLTS Gener.APProcessEq. checkerPlug-in PropertiesNavigatorMC DialogM. CheckerEC DialogFigure 3: TAPAs Plug-inGiven a pair of processes, TAPAs Equivalence Checker (EC) permits verifyingtwo kind of equivalences: bisimulations based equivalences and decorated traceequivalences. When two processes are found to be inequivalent, the EC providesan evidence. While the others equivalence checkers (CWB-NC, MRMC, . . . )create just one logical formula, TAPAs exhibits two sets of HML formulas. Theformulas into a set are satisfied by a process but not by the other. Becausethe algorithm generates two set of formulas instead of a single formula, thedebugging phase is easier than with other tools; the user can understand fasterand better the origin of the processes inequivalence.Finally, the minimizer permits reducing the size of LTS while preserving theintended behavior. As shown in Figure 2, the minimization algorithms use theEC methods.TAPAs Engine contains all the data structures and algorithms needed for thecharacterization and analysis of concurrent systems. On the contrary, TAPAs Utilsis responsible for managing plug-ins, users’ projects and few graphical interfaces.As shown in Figure 3, TAPAs Utils is divide into two main parts: Plug-in Utilsand GUI. The former provides modules for plug-in definition, integration andmanagement, the latter provides GUI elements for interacting with Engine, suchas dialog for: model checker, equivalence checker and minimizer.The Plug-in Utils modules allows to add new plug-ins in TAPAs environment.At start-up, TAPAs scans the "./plugins" directory to collect all the availableplug-ins; for each of them, the Plug-in Manager checks its integrity and registersit in the Plug-in Registry. TAPAs plug-in developers need not worry about pluginactivation/deactivation, because this is done automatically by JPF. Even ifplug-in is added to the registry, it is not loaded until it is called: this feature mayhelp to reduce the resources requirements. In fact the application should not payany memory or performance penalty for plug-ins that are installed, but not used.All required information about a plug-in is defined in an XML manifest file

30 tapasthat has to be compliant with the provided DTD. It is very important to includeas much plug-in information as possible, because the JPF framework uses thisinformation to check plug-in consistency, plug-in dependencies (relationshipsbetween plug-ins, including version compatibility check) and whether all thedeclared resources are available. JPF also checks that all provided extensionshave been declared with the required parameters.The methods for managing users’ projects are included in TAPAs Plug-in. Forexample it manages the procedures for storing and loading projects as compressedarchives files. It provides the file chooser, the zip/unzip functionalitiesand all the checks needed. The PAP developer has only to decide what to save,TAPAs Plug-in takes care of all the rest. Every concrete plug-ins have to provideinformations that depends on its particular instance, such as: files to be saved,the menu bar and tool-bar and help pages to show to the users. Moreover, foreach analysis utility provided by the engine, TAPAs Plug-in provides a panel forchoosing options, showing results and managing possible failures. Because theanalysis tools do not depend on the concrete plug-in, they should not rewrittenevery time a new plug-in is added. For the same reason, when a new feature isadded in the kernel modules, it is immediately available for all plug-ins.2.4 model checkerIn this section we will introduce the on-the-fly model checking algorithm implementedin TAPAs. Model Checking is one of the most used techniques foranalyzing a wide variety of reactive systems, like hardware circuits, softwaresystems, network protocols and many others [61, 134]. Storically, there are twobasic approach to this problem: global and local (on-the-fly) model checking.The Global MC constructs all the state space of the model, then iterativelycomputes the set of states that satisfy the given formula and finally checks ifthe set contains the initial state [62, 130]. Many algorithms for global MC havebeen developed, but, even if they have good worst-case behavior, they performmuch unnecessary work. For example, even for checking the trivial formula tt,they expand all the state space and then they verify that the formula holds inevery states. Obviously if the process is particularly complex, the creation ofthe state space takes a long time even if the formula is trivially true. In manyother case, the truth of a formula can be verified by checking only a subset ofthe entire state space. The Local MC avoids the creation of those states that donot contribute to the formula satisfiability by constructing the state space inan on-demand way [51, 50, 64, 140]. Given a process and a formula, Local MCcreates a proof tree using the operational semantics for determining the processevolution and the satisfaction relation for the formula satisfiability.TAPAs provide two on-the-fly model checking algorithms: one for µ − calculus[153], and the other for ACTL [46]. First we present the algorithm for µ −

2.4 model checker 31calculus and then ACTL will be straightforward. Both algorithms exploit thesame idea: given a process p and a formula φ, sometimes the truth of φ in p canbe determined locally, i.e there is no need to unfold the process nor the formulaαbecause the satisfiability can be decided immediately. For example if p ̸−−→ it istrivial to see that the formula 〈α〉φ can not hold in p, whatever the φ form. Forthe same reason, the formula [α]ψ holds in p regardless of ψ form.TAPAs implements the model checking algorithm as proposed in [153]. Asone might aspect, the operator more difficult to treat is the fixed point. Theproposed approach is based on annotating fixed point operator with a set ofstates encountered during the unfolding operation. This solution exploits theReduction Lemma that follows from Tarski’s fixed point theorem:Theorem 2.4.1 (Reduction Lemma) Let S be a set of processes and φ a monotonicfunction on a powerset Pow(S)S ⊆ νX.φ(X) ⇔ S ⊆ φ(νX.(S ∪ φ(X)))This lemma says a process p satisfies a recursively defined property if andonly if the process satisfies a certain kind of unfolding of the recursively definedproperty. With the help of the Reduction Lemma a set of reduction rules aredefined; every rule tries to decide as son as possible if the process satisfies (ornot) the formula. If satisfiability can not decided locally, the algorithm proceedsunfolding the process, the formula or both. The algorithm is presented by meansof reduction rules (Tab. 6) each of which tries to establish if p |= φ is true orfalse.The idea is to try to establish locally if the property holds. For example, thiscan be done with the formulas 〈α〉φ and [α]φ when the process does not performany α. In this case the algorithm terminates immediately without having tounfold neither the process nor the formula. If the satisfiability can not be decidelocally, the truth value of the satisfaction assertion on the left is reduced tofinding that of the expression on the right.From the rules definitions, it is clear that all of them induce some form ofprogress: after applying a rule either the right-hand-side is a truth value, or thesatisfaction of strictly smaller formulas have to be checked. Only for the last ruleis not immediately clear that the reduction will terminate. It is important to notethat formulas are checked against finite-state process and eventually the taggingprocedure will terminate: either a state will be found to be in the set or a statewill not satisfy the recursively defined property.The algorithm for ACTL exploits the same principle: it constructs the statespace in an on-demand way. To do this, it couples process and formula and itunfolds them until it is able to determine if the process satisfy the formula.

32 tapasp |= tt −→ truep |= ¬φ −→ p ̸|= φp |= (φ 1 ∧ φ 2 ) −→ p |= φ 1 ∧ p |= φ 2{αfalseif p ̸−−→p |= 〈α〉φ −→p 1 |= φ ∨ . . . ∨ p n |= φ p i ∈ {p ′ |p −−→ α p ′ }p |= [α]φ −→{̸trueif p −−→p 1 |= φ ∧ . . . ∧ p n |= φ p i ∈ {p ′ |p −−→ α p ′ }αp |= νX.{⃗r}φ(X) −→{truep |= φ(νX.{p, ⃗r}φ/X)if p ∈ ⃗rif p ∉ ⃗rTable 6: µ − calculus reduction rules for on-the-fly model checking2.5 equivalence checkerVerification of concurrent systems within the process algebraic approach canbe performed by resorting to behavioral equivalences for proving conformanceof processes to specifications. Generally given a system, two different modelsare developed: one is very detailed and close to the actual concurrent implementation,whereas the other is more abstract and it describes the abstract treeof relevant actions the system has to perform. Afterwards, the two models arechecked against the chosen behavioral equivalences. When two system are foundto be inequivalent, equivalence checker provides a counterexample: generally atemporal logic formula that is satisfied by a model but not by the other.In literature there are a lot of algorithms for computing bisimulation [122,104, 78] and branching [93] equivalence. The others equivalences are not usuallycalculated by using specific algorithms, but just creating an equivalent LTS andcalculating the strong bisimulation on it.The bisimulation and branching algorithms are both based on the so calledpartition refinement algorithm (PRA): the state space of two generic systems S 1and S 2 , is split into equivalence classes until fixpoint is reached. The equivalenceclasses (called blocks) are a partition of the states space, namely a set of pairwisedisjointsubsets. The states in the same subset are equivalent, so the systems (S 1and S 2 ) are equivalent if the corresponding initial states (s 1 and s 2 ) are in thesame equivalence class. These algorithms are implemented in a lot of process

2.5 equivalence checker 33Strong BisimulationAlg. Average case Worst caseKS O(m · n) O(m · n)KS2 O(m · log(n)) O(m · n)PT O(m · log(n)) O(m · log(n))Branching BisimulationAlg. Average case Worts caseGV O(m · n) O(m · n)GV2 O(m · n) O(m · n)GVKS O(m · log(n)) O(m · n)Table 7: Complexity analysis of partition refinement algorithms.algebra analysis tools, such as: CWB_NC, Edinburgh CWB [119] or MRMC. Inthese tools, PRAs are enriched in order to generate a counterexample. In [63]and [109] are described two techniques to calculate formulas for distinguishingbisimulation-inequivalent and branching-inequivalent systems respectively.TAPAs provides behavioral verification for several equivalences: strong, weakand branching bisimulation [118, 150] and decorated trace equivalences, such as:weak and strong variants of trace, completed trace, divergence sensitive trace,must, testing [101, 72]. Like many others tools, it implements only algorithms forcomputing two kind of equivalences (strong bisimulation and branching bisimulation),but provides several implementations for each of them. For computingstrong bisimulation, it implements three different algorithms: Kanellakis-Smolka(KS, [104]) a variant of Kanellakis-Smolka (KS2) and Paige-Tarjan (PT, [122]).The idea behind the three previous algorithms is the same: split iteratively thestates space and check is the two initial states of the interested processes are inthe same subset. The difference is how they choose the subset to split. For thebranching bisimulation, three algorithms are implemented: the classical Groote-Vaandrager (GV, [94]) algorithm, known for its efficiency, a GV simplification(GV2) and a new algorithm with better performance (GVKS) [143]. In Table 7are shown the complexity analysis of the algorithms implemented.All the others equivalences is computed just applying a few transformationson the associated LTS, and then the strong bisimulation algorithm is used.For example the weak bisimulation algorithm simply consists in first computingthe reflexive-transitive τ-closure of the transition relation and successivelycomputing strong bisimulation equivalence.Decorated trace equivalences have been implemented by combining a setflags, which enable or disable checking specific properties. When a flag is set,a specific transformation is applied on the corresponding LTS. Flags, and theirmeanings, are the following:• WEAK: weak equivalences;• FINL: equivalences sensitive to deadlock states;• DIVE: equivalences sensitive to divergence;

34 tapasFlags →Equivalences ↓S TraceW TraceCS TraceWEAK FINL DIVE ACPT CUTC HISŤ̌CW Trace ̌ ̌DS TraceDW Trace ̌ ̌CDS Trace ̌ ̌CDW Trace ̌ ̌ ̌S MustMust ̌ ̌ ̌ ̌ ̌S Testing ̌ ̌ ̌Testing ̌ ̌ ̌ ̌̌̌Table 8: Flags settings for decorated tracesS = Strong, W = Weak, C = Convergence, D = Divergence sensitive• ACPT: equivalences sensitive to acceptance sets;• CUTC: equivalences that ignore all behaviors after divergent nodes;• HIST: equivalences that consider past divergences as catastrophic.For example, weak trace equivalence is obtained by enabling only the WEAKflag, the completed trace equivalence is obtained by enabling the FINL flag, andthe weak completed trace is obtained by enabling the WEAK and the FINL flags.Table 8 shows the flags settings for all the decorated traces.Equivalence checker algorithms are also used for implementing a LTSs Minimizer.The minimization is computed by means of the equivalence checkeralgorithm. After chosen an equivalence relation, a partition refinement algorithmsplits the state space into equivalence classes. Afterwards it is create anew graph in which all the states in the same equivalence class are collapsedinto one.TAPAs minimizer can minimize the associated LTS up to three different equivalencerelations: strong bisimulation, weak bisimulation, and tau ∗ .a [82]. Theminimization facility could be used to reduce the size of the components beforecomposing them into complex systems. The strong and weak bisimulationspreserve branching structure, and so the minimized LTS could still have τ actions.On the contrary the minimization up to tau ∗ .a, completely eliminate

2.5 equivalence checker 35the non-determinism induced by the silent actions. This is particularly usefulwhen modeling structured (deterministic) systems, such as a complex scheduleror SCADA (Supervisory Control And Data Acquisition) control logic. Whendefining such kind of systems, there are two possible solutions: build the modelas a huge, monolithic LTS including all the possible behaviors or create it assum of several interacting components (as semaphores, mutual exclusion resources,counters, ecc). The first solution is not always viable, because the modelcould have thousand of states; the second solution model has τ actions thatperturbs the interactions with the environment. The tau ∗ .a allows to createthe reduced τ-free LTS that can be used as a sub-component in a more complexsystems. The wide variety of equivalences provided allows users to compareand analyze models from different point of views, evaluating their similaritiesand differences.2.5.1 Counter Examples GeneratorWhenever an equivalence check turns out to be unsuccessful, TAPAs providescounterexamples, i.e. evidences that the analyzed systems do behave differently.As written in Sec.2.5, three algorithms for strong bisimulation and three algorithmsfor branching bisimulation are implemented in TAPAs. Modifying thesealgorithms to provide a counter-example is not the best choice. Indeed all thealgorithms should be modified to generated counter-examples, and the changesshould be implemented and tested to guarantee their correctness. Moreoverif better partition refinement algorithms emerge, they must be modified togenerate counter-examples.In this Subsection, it will be described TAPAs algorithm for generating counterexamplesby using only the equivalence classes (called blocks), i.e. the outcomeof every Partition Refinement Algorithm (PRA). This algorithm exhibits two setsof HML formulas capturing properties satisfied only by one of the two inequivalentsystems: the formulas into a set are satisfied by a system but not bythe other.BackgroundsFirst we will give some useful definitions about partitions, blocks and formulas.In PRA, the state space is split into equivalence classes until a fix-point is reached.At the end, each equivalence classes will contain all and only equivalent states.B i , B j indicate two generic equivalence classes (also called blocks) of the partitionP. A partition of the state space is defined as:Definition 2.5.1 (Partition) Let L = (S, A, →) be a generic LTS and B i , B j twogeneric sets of states. P = {B 1 , . . . , B n } is a partition of the state space, if and only if:1. ∀ B i , B j ∈ P, B i ∩ B j = ∅

36 tapas2.⋃i={1,...,n} B i = S3. ∀p, q ∈ S, p is equivalent to q ⇔ ∃B i ∈ P : p ∈ B i ∧ q ∈ B i .Definition 2.5.2 Let A be a set of actions, and B i , B j be two generic blocks belongingto the partition P. The transition relation between blocks → ∈ P × A × P is defined asfollows:(Bi , α, B j)α⇐⇒ ∀ p ∈ B i ∃ α ∈ A, q ∈ B j∣ ∣ pα −→ qWhere(p −→)q is the classical transition relation between states. For sick of simplicityαBi , α, B j ∈→ will be written as Bi −→ Bj .The same terminology used for state will be used also for blocks, for instanceB −→ ααindicates that each state in B can perform an α, and B ̸−→ indicatesthat any states in B can not perform an α. Also the formulas satisfiability iswritten using the same symbol: B i |= φ indicates that all states in B i satisfies φ,while B i ̸|= φ indicates that any states in B i satisfies φ. Moreover, we give thefollowing definitions:• Act(B i ) = { α | B iα → Bj}: the set of actions that can be performed fromB i .• Act(B i , B j ) = Act(B i )\Act(B j ): the set of actions that can be performedfrom B i but not from B j .• Dest α (B i ) = { B j∣ ∣ Biα → Bj}: the set of blocks that can be reached fromB i performing α.• Dest α (B i , B j ) = Dest α (B i )\Dest α (B j ): the set of blocks that can bereached from B i but not from B j performing α.In the rest of the section s i , s j indicate generic states and B i , B j generic blocks(B i = {s i , . . . , s n }). Moreover F is a set of formulas (F = {ψ 0 , . . . , ψ n }), F denotesa family (set of set) of formulas and B denotes set of blocks: F = {F 1 , F 2 , . . . , F n }and B = {B 1 , B 2 , . . . , B m }. A formula φ distinguishes B i from B j if it is satisfiedby all the states in B i , but it is not satisfied by any states in B j (B i |= φ ∧ B j ̸|= φ),or vice-versa (B i ̸|= φ ∧ B j |= φ). A key feature of all equivalence checkeris to generate counter-examples as small as possible. Although there are noalgorithms that ensure minimum examples (as short to be found), some of themare able to ensure minimality, i.e. given a formula, all sub-formulas are necessary.In fact, if one of them is eliminated, the formula is no longer a counter example;typically, the formula is satisfied by both systems.Mainly, counter examples are used as evidences of two systems inequivalence,but they are also used to detect errors during the debugging phase. Generallythe user specifies two descriptions of the same system: one abstract and the other

2.5 equivalence checker 37more concrete, and then checks their equivalence. If they are not equivalent, userexploits the counterexample to understand systems behavior, finds the error andcorrects it. For this reason, formulas should be as readable as possible.Counter examples can be build in very different manners, it depends on manyfactors including the preferred operators. For example, we chose not to use thenot (¬) operator in order to improve the formulas readability. Indeed when it isin front of the others boolean operators, generally user apply De Morgan laws toremove it. Moreover the diamond operator (〈·〉·) is preferred to the box operator([·]·). We made this choice considering the way in which users try to understandwhy a process does not satisfy a formula. The diamond interpretation can bedone following only an action at a time, whereas the box interpretation has to bedone following all the possible actions. Since a short formula with box operatoris better than a long one with diamond operator the algorithm builds formulaswith both operators.For estimating formulas readability, in [63] it is defined the minimality criterionin assessing whether a formula contains redundant informations. Intuitively,φ is a minimal distinguishing formula if each of its subterms plays a rolein distinguishing the two system (i.e. all the subterms are necessary). In [63]the authors write that the algorithm described yields formulas that are oftenminimal. Nevertheless, the minimality does not ensure the readability.For example, let’s take into account the example shown in Figure 4. Thereare two (non-bisimilar) processes (p and q) that can be distinguished by threeformulas (φ 1 , φ 2 and φ 3 ): p satisfies all of them, instead q does not. It isimportant to note that the first two formulas are minimal, while the third is not.φ 1 is minimal because it has only a subterm, φ 2 is minimal because both of itssubterms (〈b〉true and 〈c〉true) are necessary: if one of them was missing, theformula would be satisfied even by q. φ 3 is not minimal, indeed the sub-formula〈d〉tt can be omitted still getting a counter-example.cqpp 1 p 2 q 1a bad bcaq 2bφ 1 = 〈b〉ttφ 2 = 〈a〉 ( 〈b〉tt ∧ 〈c〉tt )φ 3 = 〈a〉 ( 〈b〉tt ∧ 〈c〉tt ∧ 〈d〉tt )Figure 4: Three simple counter examplesThis simple example shows how the minimality criterion guarantees the nonredundancyof information, but it can not be use to evaluate the formulas readability.Indeed φ 1 can be considered more readable than φ 2 .In order to guarantee the minimality, we have defined a "reduction" function.Given a family F of formulas, this function remove the redundant formulas to

38 tapasobtain set of formulas as small as possible. The reduced sets, called "representer",are smaller but "equally powerful" then F, i.e. they can distinguish the same statesof F. More formally:Definition 2.5.3 Let F be a family of formulas, the set of formulas F is a representerif and only if:• F ⊆ ⋃ F i ∈F F i• ∀ F i ∈ F ⇒ F i ∩ F ≠ ∅Moreover R(F) denotes a set of representers of F, and R ⊥ (F) denotes a set ofminimum representers defined as follows:R ⊥ (F) = {F | ∀ F ′ ∈ R(F) ⇒ |F| |F ′ |}Given a family of formulas, the set of minimum representers can be simplycalculated iterating all over the sets in F and calculating the minimum representersbetween the sets seen so far. The Figure 5 shows the pseudocode forcalculating R ⊥ (F).1: function minRep (F ) ⊲ F = {F 0 , . . . , F n }2: V 0 = F 0 ;3: for (i = 1; i n; i + +) do4: for all (F ′ ∈ V i−1 ) do5: if (F ′ ∩ F i ≠ ∅) then V i = V i ∪ {F ′ };6: end7: if (V i = ∅) then8: for all (F ′ ∈ V i−1 , ψ ∈ F i ) do9: V i += {F ′ ∪ {ψ}};10: end11: end12: end13: return V n ;14: endFigure 5: Pseudocode for minimum representer R ⊥ (F)Given F (with |F| = n), the set of minimum representer R ⊥ (F) can be simplycalculated creating a vector V[n] in which every elements V[i] contains only andall the minimum representers of [F 0 , . . . , F i ]. In the first element of the vector(V[0]) the representers are the formulas in F 0 . In the element V[i + 1] (with i > 0)the representers are created from V[i] and F i+1 as follows:V[i + 1] ={ {F ′ | F ′ ∈ V[i] } ∃ F ′ ∈ V[i] | F ′ ∩ F i+1 ≠ ∅{F ′ ∪ ψ | F ′ }∈ V[i] ∧ ψ ∈ F i+1 otherwise

2.5 equivalence checker 39In the last element of the vector, there are all the minimum representers ofF. The following example shows how the algorithm generates the minimumrepresenters of five sets of formulas.Example 1 Let F = [F 1 , F 2 , F 3 , F 4 , F 5 ] be a family of formulas composed of:• F 1 = {ψ 1 , ψ 3 }• F 2 = {ψ 2 , ψ 3 }• F 3 = {ψ 4 }• F 4 = {ψ 3 , ψ 5 }• F 5 = {ψ 2 , ψ 5 }In Table 9 it is shown the vector V at the end of the computation. In the last positionthere are the two minimum representers of F.F 1 F 2 F 3 F 4 F 5{ψ 1 } {ψ 3 } {ψ 3 } {ψ 3 , ψ 4 } {ψ 3 , ψ 4 }{ψ 2 , ψ 3 , ψ 4 }{ψ 3 , ψ 4 , ψ 5 }The algorithmTable 9: Creation of the minimum representersAs written above, this algorithm exploits the partition P calculated using a PRA.The basic idea is to create a table T[N × N] (where N = |P|) indexed by blocks.Each element contains a set of HML formulas that can be used to distinguishblocks it is associated to. For example, in the element T[B i , B j ] there will be theformulas which are satisfied by all the states in B i , but not satisfied by any statesin B j . The blocks B i and B j are distinguishable if T[B i , B j ] or T[B j , B i ] are notempty. The notation φ ij will denote a generic formula φ in T[B i , B j ].The proposed algorithm operates through two distinct phases: the initializationphase and the iterative phase. In the first one, those blocks that perform differentactions are considered: a formula is added in T[B i , B j ], if B i performs an actionthat can not be performed by B j . More formally:T[B i , B j ] ≠ ∅ ⇐⇒ ∃ α | B i −→ and Bj ̸−→αIn the second phase the rest of blocks are considered: if B i and B j , performingthe same action α, can reach distinguishable blocks B h and B k , then at least aformula can be added in the table. New formulas are built exploiting the actionα and the formulas in T[B h , B k ] and T[B k , B h ]. This phase will be repeateduntil the desired counterexamples will be created. In next two paragraphs thealgorithm phases will be explained in detail. To help in understanding theα

40 tapasalgorithm we will refer to the example shown in Figure 6. The left-hand sideshows a partition P of a state space, composed of seven blocks (B 1 , . . . , B 6 ) andthe transition relation between blocks. The right-hand side show few Dest α (·)sets.αBB 31βαγB 4αB 7α B 5B 2δBα6 ɛDest α (B 1 ) = {B 3 , B 4 }Dest α (B 2 ) = {B 4 , B 5 , B 6 }Dest α (B 1 , B 2 ) = {B 3 }Dest α (B 2 , B 1 ) = {B 5 , B 6 }Figure 6: A simple exampleinitialization phase In the initialization phase, the algorithm createsformulas to distinguish those blocks performing different actions. For instance,ββsince B 3 −→ and B5 ̸−→, formulas 〈β〉tt and [β]ff distinguish B 3 from B 5 ,indeed:• B 3 |= 〈β〉tt and B 5 ̸|= 〈β〉tt.• B 3 ̸|= [β]ff and B 5 |= [β]ff.For every couple 〈B i , B j 〉, the algorithm calculates Act(B i , B j ) and if:1. Act(B i , B j ) = ∅: the blocks B i can perform the same actions of B j , thereforeno formula will be added in the table.2. Act(B i , B j ) ≠ ∅: B i can perform at least one action that can not be performedby B j . In this case the table will change are as follows:T[B i , B j ] = T[B i , B j ] ⋃ { 〈α〉 true | α ∈ Act(B i , B j ) }T[B j , B i ] = T[B j , B i ] ⋃ { [α]false | α ∈ Act(B i , B j ) }Each blocks couple, except 〈B 1 , B 2 〉, can be distinguished at this phase.The content of the table T after the iterative phase is shown in Table 10: emptycells are T[B 1 , B 2 ] and T[B 2 , B 3 ] because they can not be distinguished at thisalgorithm phase, and the cells T[B i , B i ] because they can never be distinguished.The Figure 7 shows the pseudocode for the initialization phase.iterative phase In this phase the algorithm exploits the formulas insertedin previous iterations. For every indistinguishable blocks B i and B j , if they canreach distinguishable blocks the algorithm try to create new counterexamples.Notice that in this phase Act(B i ) = Act(B i ), since if it were not so, at least

2.5 equivalence checker 41B 1 B 2 B 3 B 4 B 5 B 6 B 7B 1 〈α〉tt 〈α〉tt 〈α〉tt 〈α〉tt 〈α〉tt[β]ff [γ]ff [δ]ff [ɛ]ffB 2 〈α〉tt 〈α〉tt 〈α〉tt 〈α〉tt 〈α〉tt[β]ff [γ]ff [δ]ff [ɛ]ffB 3 〈β〉tt 〈β〉tt 〈β〉tt 〈β〉tt 〈β〉tt 〈β〉tt[α]ff [α]ff [γ]ff [δ]ff [ɛ]ffB 4 〈γ〉tt 〈γ〉tt 〈γ〉tt 〈γ〉tt 〈γ〉tt 〈γ〉tt[α]ff [α]ff [β]ff [δ]ff [ɛ]ffB 5 〈δ〉tt 〈δ〉tt 〈δ〉tt 〈δ〉tt 〈δ〉tt 〈δ〉tt[α]ff [α]ff [β]ff [γ]ff [ɛ]ffB 6 〈ɛ〉tt 〈ɛ〉tt 〈ɛ〉tt 〈ɛ〉tt 〈ɛ〉tt 〈ɛ〉tt[α]ff [α]ff [β]ff [γ]ff [δ]ffB 7 [α]ff [α]ff [β]ff [γ]ff [δ]ff [ɛ]ffTable 10: Table after initialization phase1: function init (T) ⊲ T: Table containing formulas2: for all (B i , B j ∈ T) do3: Act ij := Act(B i ) \ Act(B j );4: for all (α ∈ Act ij ) do5: T[B i , B j ] += {〈α〉tt};6: T[B j , B i ] += {[α]ff};7: end8: end9: endFigure 7: Pseudocode for initialization phasea formula would be added in the initialization phase. In iterative phase, thealgorithm can create two kind of formulas : the diamond formulas and the boxformulas . The first ones capture a characteristic aspect of a block, whereas thesecond ones show the overall behavior of a block.Given two blocks B i and B j and the action α, the diamond formula is buildtaking a block in Dest α (B i , B j ) and all the blocks in Dest α (B j ). The purpose

42 tapasof this formula is to distinguish a specific B i path from all the other B j paths.Diamond formula is built as follows:()∧⋄ α φ ij = 〈α〉φ hk ∀ B h ∈ Dest α (B i , B j )B k ∈Dest α (B j ))where φ hk denotes a formula in T[B h , B k ]. With reference to the exampleshown in Figure 6, let’s consider blocks B 1 and B 2 . The diamond formuladistinguishing B 1 from B 2 can be built exploiting each block in Dest α (B 1 , B 2 ) ={B 3 } from all the blocks in Dest α (B 2 ) = {B 4 , B 5 , B 6 }. For construction thegeneric formula φ 3 4 (φ 3 5 , φ 3 6 ) holds in every state of B 3 and does not holdsin any state of B 4 (B 5 , B 6 ). Using the formulas previously added in the table, itis possible create the following diamond formula:⋄φ 12 = 〈α〉(φ 34 ∧ φ 35 ∧ φ 36 )It is easy to see that ⋄φ 12 is satisfied by B 1 but not by B 2 . The outgoing edgefrom B 1 to B 3 satisfies the sub-formula (φ 34 ∧ φ 35 ∧ φ 36 ) by construction. Onthe contrary B 2 does not satisfy the diamond formula: its outgoing α edgeslead to three different blocks (B 4 , B 5 , B 6 ), but no one satisfy the sub-formula(φ 34 ∧ φ 35 ∧ φ 36 ). The block B 4 does not satisfy φ 34 , B 5 does not satisfy φ 35 ,and B 6 does not satisfy φ 36 .Until now no assumptions have been made on sub-formulas φ hk , it may bethat not all of them are necessary to define the diamond formula. For examplethe formula 〈β〉tt appears in T[B 3 , B 4 ], T[B 3 , B 5 ] and T[B 3 , B 6 ] thus only oneformula can be used to distinguish all the considered blocks (B 3 from B 4 , B 3from B 5 and B 3 from B 6 ). Indeed the formula 〈α〉〈β〉tt is a counter example forB 1 and B 2 , i.e. it holds for every state in B 1 , and does not hold for any state inB 2 . The reduction function presented in subsection 2.5.1, is used to reduce thenumber of sub-formulas, guaranteeing their minimality.Diamond formula can be build if and only if all the need φ hk are alreadypresent in the table. If one φ hk is missing, the algorithm takes a different block inDest α (B i , B j ) to try to build a counter example. In the best case, the algorithmcan creates a diamond formula for each block in Dest α (B i , B j ).Theorem 2.5.1 Let B i and B j two blocks, α an action and ⋄ α φ ij the correspondingdiamond formula. B i satisfies ⋄ α φ ij , whereas B j does not.Proof. (B i |= ⋄ α φ ij ). By construction, there exists a block B h in Dest α (B i , B j )αsuch that B i −→ Bh and it satisfies all the sub-formulas φ hk .(B j ̸|= ⋄ α φ ij ). The block B j satisfies the diamond prefix 〈α〉 because there existαat least a B k such that B j −→ Bk . However, for all B k in Dest α (B j ) there existsthe corresponding sub-formula φ hk that is not satisfied by B k .□

2.5 equivalence checker 43Box formula for B i and B j is build using all the blocks in Dest α (B i ) and allthe blocks in Dest α (B j , B i ). The purpose of this formula is to characterize theoverall behavior of B i against B j . Box formula is built as follows:□ α φ ij= [α](∨B h ∈Dest α (B i )(∧B k ∈Dest α (B j , B i )φ hk} {{ }and sub_formulaAfter the box prefix [α], algorithm builds a sub-formula to distinguish allblocks in Dest α (B i ) from all blocks in Diff α (B j , B i ). With reference to the exampleshown in Figure 6, let’s consider blocks B 1 and B 2 . In this case, the algorithmuses the blocks in Dest α (B 1 ) = {B 3 , B 4 } and in Dest α (B 2 , B 1 ) = {B 5 , B 6 }. Thebox formula, after the box prefix [α], has a sub-formula for distinguishing B 3and B 4 from B 5 and B 6 . Following the box formula definition the counter exampleassociated to the example is shown below:()[α] (φ 3 5 ∧ φ 3 6 ) ∨ (φ 4 5 ∧ φ 4 6 )As for diamond formula, the reduction function is applied to remove redundantsub-formulas. One of the possible minimal counter-example is:[α] ( 〈β〉tt ∨ 〈γ〉tt )Recalling that the formula [α]φ requires that every α-descendant has tosatisfy φ, it is easy to see that the previous formula distinguishes B 1 fromB 2 . B 1 outgoing α edges lead to B 3 and B 4 and both satisfy the sub-formula(B 3 |= (φ 3 5 ∧ φ 3 6 ) and B 4 |= (φ 4 5 ∧ φ 4 6 )). B 2 outgoing α edges lead to B 4 ,B 5 and B 6 ; B 4 satisfies the sub-formula but B 5 and B 6 do not. Indeed B 5 dosenot satisfy either φ 3 5 nor φ 4 5 and B 6 dose not satisfy either φ 3 6 nor φ 4 6, byconstruction. The box formula can be build if and only if all the need φ hk arealready created, but, differently from diamond formula, much more formulasare needed. For this reason the algorithm generates more diamond than boxformulas.Theorem 2.5.2 Let B i and B j two blocks, α an action and □ α φ ij the correspondingbox formula. B i satisfies □ α φ ij , whereas B j does not.Proof. (B i □ α φ ij ). By construction, for all B h in Dest α (B i ), B h satisfies thecorresponding and sub-formula: ∧ B k ∈Dest α (B j , B i ) φ hk.(B j □ α φ ij ). Let B k be a generic block in Dest α (B j , B i ), in every and subformulasthere exist a φ hk that is not satisfied by B k (by construction): i.e. B kdoes not satisfy any and sub-formulas. For this reason it can not even satisfied thedisjunction of all the and sub-formulas.□))

44 tapasAfter defining the two kind of formulas , we introduce some new definitionsthat will be useful to create formulas as short as possible.Definition 1 Let B be a block and B be a family of blocks. If B is distinguishable fromall the blocks in B, then T[B, B] and T[B, B] denotes the family of formulas :T[B, B] = {T[B, B i ] | B i ∈ B}T[B, B] = {T[B i , B] | B i ∈ B}Moreover, R ⊥ (T[B, B]) and R ⊥ (T[B, B]) indicates the minimum representer of T[B, B]and T[B, B] respectively.Figure 8 shows the pseudo-code for the iterative phase, that is repeated until itis found the desired counter-example. Let n be the number of blocks, it is easyto see that the iterative phase is repeated at most ( )n−12 times.function iterative_Phasefor all (T[B i , B j ] ≠ ∅) dofor all (α ∈ Act(B i )) dofor all (B h ∈ Diff α (B i , B j )) doF := R ⊥ (T[B h , Dest α (B j )]);for all (F ∈ F) doT[B i , B j ]+= { 〈α〉 ( ∧ φ∈F φ)} ;endendF ′ := ∅;for all (B h ∈ Dest α (B i )) doF := R ⊥ (T[B h , Diff α (B j , B i )]);for all (F ∈ F) doF ′ += { ∧ φ∈F φ} ;endendT[B i , B j ]+= { [α] ( ∨ φ∈R ⊥ (F ′ ) φ)} ;endendend⊲ For all the couple in T⊲ Minimum representers⊲ Diamond formulas⊲ Family of formulas⊲ Minimum representers⊲ And sub-formula⊲ Minimum representers⊲ Box formulaFigure 8: Pseudocode for iterative phaseThe algorithm is divided into two parts: initialization phase and iterative phase.Let n be the number of blocks, in the first phase the algorithm scans the tableT once, and for each couple of distinguishable blocks it creates two formulas .The complexity of this phase is O(n 2 ). For every non-trivial system, the number

2.5 equivalence checker 45of blocks in a partition can be very large and close to the number of states ofthe process. LTSs associated to non-trivial systems have thousands of statesand its partitions can have a number of blocks of the same order of magnitude.The iterative phase scans the table T and, for every empty element, tries to buildone or more formulas. Typically the degree of a generic node is much smallerthan the number states, so the formulas construction cost is considered constant.During the second phase, the algorithm accesses to every cell of the table (n 2 )trying to add at least a formula. Since the second phase is repeated at most n−12times, the complexity is O ( n 2 ∗ n−1 )2 = O(n 3 ).

46 tapas

C C S P A N D P E PA P L U G I N3In this Chapter we will present two plug-ins developed for TAPAs: CCSP plug-in andPEPA plug-in. each of which support the specification of different process algebras.The former supports specification for CCSP: a process algebra obtained from CCSby incorporating some operators of CSP. The latter supports specification for PEPA(Performance Evaluation Process Algebra): an expressive formal language for modelingdistributed systems. In the first Chapter we will introduce CCSP plug-in: first CCSPsyntax and semantics, rather the back-end and then then front-end with its maingraphical features. In the second Chapter we will describe how to use CCSP plug-in tomodel non-trivial case studies: Distributed Atomic Commitment Protocols (DACPs). Inthe third Chapter we will present PEPA plug-in: first PEPA syntax and semantics, andthen its back-end and front-end. In the last Chapter we will model DACPs using PEPAplug-in.In this Chapter we will present two PAPs (Process Algebra Plugins) for TAPAs:CCSP plug-in and PEPA plug-in. The former supports CCSP (CCS with someoperators of CSP) and permits qualitative evaluation (yes or no answer), whilethe latter supports PEPA (Performance Evaluation Process Algebra) and permitsquantitative evaluation.We have chosen to present these two plug-ins together because their similarities.Both have a graphical interface that allows graphical specification withouthiding the corresponding textual representation. The graphical representationfacilitates the beginning students in the development phase, while the textualone is used by advance users. Moreover we did not completely hide the textualspecification in order to allow absolute beginner to make an initial testing phase,monitoring that what they draw has the same textual representation seen inclassroom or red in a book.Furthermore they can manage projects and not only plain txt file, so that theycan save projects preferences, such as: workspace directory, the graphic arrangementof the nodes and arcs and last open windows. There are other features thathelp users during the developing activity, for example an undo/redo systemthat maintains consistency between the graphical and the textual representation.Although these features may seem trivial, they prevent users from wasting timein tedious task and speed up models development process.Despite many similarities there are also some differences. First, the twoprocess algebras allow two completely different types of analysis: on CCSPterms can be performed qualitative analysis, namely proving the functionality of47

48 ccsp and pepa pluginsystems is correct; on PEPA terms can be performed quantitative analysis, namelydetermining whether a system meets both the behavioral and the temporalrequirements demanded of it. Moreover CCSP plug-in exploits all the featuresprovided by TAPAs Kernel, on the contrary PEPA plug-in uses external librariesfor providing analysis features.In Section 3.1, CCSP plug-in will be presented: syntax and semantics of thesupported language, back-end and front-end structure. In Section 3.2 CCSPplug-in will be used to models two different Distributed Atomic CommitmentProtocols (DACPs): Two-Phase Commit Protocol and Extended Two-Phase CommitProtocol. In Section 3.3 PEPA plug-in will be presented: syntax and semantics ofthe supported language, its main structure and how it has been integrated withalready developed libraries. In Section 3.4 DACPs will be modeled using PEPAand then quantitative analysis will be performed over them.3.1 ccsp plug-inAs mentioned in Section 2.2, TAPAs Kernel is composed of basic libraries thatpermit simplifying developing of automatic tools. From one hand they providealgorithms for models analysis and verification and, on the other hand, they takecare of users projects management implementing some graphical interfaces foranalysis features and results visualization. It will be shown how to develop anddeploy a PAP (Process Algebra Plug-in), using CCSP plug-in as example. Sincethis plug-in exploits all the features provided by TAPAs Kernel, this Section givesa complete overview of the main application, showing it features and graphicappearance.3.1.1 CCSP Syntax and SemanticThis plug-in implements CCSP a process algebra obtained from CCS by incorporatingsome operators of CSP. Although the name is borrowed from [121] ourvariant is slightly different from the one considered by Olderog and the oneproposed by van Glabbeek and Vaandrager [146] due to the different mix ofoperators. As shown in Table 11, CCSP provides a set of operators that can beused to create systems as sub-components composition. They can be obtainedby parallel composition with binary or broadcast synchronization, relabelingand restriction of components.As in most process calculi, basic elements of CCSP processes are actions.Intuitively, actions represent (internal or external) atomic computational steps.All internal actions (τ actions) represent computational steps invisible to theenvironment. On the contrary, external actions are input/output operationsrepresenting potential interactions with the external environment. Figure 11shows the CCSP syntax and semantics, where α (ᾱ) represents generic input

3.1 ccsp plug-in 49Syntax P = nil ∣ α.P ∣ P 1 + P 2∣ ∣ ∣ ∣ ∣ ∣∣ ∣∣ ∣∣ ∣∣ ∣∣S = P ∣ S 1 ⊕ S 2 S1 □ S 2 S\{cs} S[f] S1 | S 2 S1 || {L} S 2SemanticsInt. Choice :P ⊕ Q τ −→ PP ⊕ Q τ −→ QPrefix :µ.P µ −→ PExt. Choice :P µ−→ P ′ Q −→ µ Q ′P □ Q −→ µ P ′ P □ Q µ−→ Q ′ Sum :P µ−→ P ′ Q −→ µ Q ′P+Q −→ µ P ′ P+Q −→ µ Q ′Restriction :P µ −→ P ′P \L µ−→ P ′ \L (µ = τ ∨ µ /∈ L) Relabeling : P µ → P ′P[f] ˆf(µ) −→ P ′ [f]Parallel :P µ −→ P ′P|Q µ −→ P ′ |QQ −→ µ Q ′P −→ α P ′ Q −→ ᾱ Q ′P|Q −→ µ P|Q ′ P|Q −→ τ P ′ |Q ′P −→Brodcast : µ P ′(µ /∈ L) Q −→ µ Q ′(µ /∈ L)P|| {L} Q −→ µ P ′ || {L} Q P|| {L} Q −→ µ P|| {L} Q ′P µ −→ P ′ Q µ −→ Q ′P|| {L} Q µ −→ P ′ || {L} Q ′ (µ ∈ L)Table 11: CCSP Syntax and Semantics.

50 ccsp and pepa plugin(output) action over the channel α; while µ represents a generic input, outputor τ action. An input and output on the same channel are called complementarylabels.When designing CCSP Plug-in, we decided to use a two levels syntax thatpermits defining models by means of processes, (Prefix and Sum), and systemswhich are obtained by process compositions (Restriction, Relabeling, Internal andExternal Choice, Parallel and Broadcast). A CCSP model is a sequence of processdeclaration and system declarations. Processes are defined by “state_ name =∑i∈Iaction. process", where an action can be the silent action τ, an input oroutput actions, while a process can be the empty process nil (which cannotperform any actions), a reference to another process or system. Systems aredefined as the composition via parallel operator, external and internal choiceoperators of other components. These can be processes or the result of applyingan operators (broadcast-synchronization, renaming or restriction operators)to processes. The multi-synchronization construct is inspired by the paralleloperator of CSP and allows parallel components to synchronize on any channelof the specified set when all of them can perform the same action. Renamingand restriction are the standard CCS operators; the former permits changingchannel names, while the latter is used for delimiting their scope. For multisynchronizationand restriction operations, we use the wild-card symbol * toindicate all the channels names.CCSP operational semantics is defined only for well-formed models, i.e. modelswhere all used processes and systems have corresponding declarations anddistinct names. Moreover, well-formedness check can be statically performed.CCSP semantics is described as a labeled transition relation µ−−→ over componentsinduced by the rules in Table 11.Rules for renaming, restriction, parallel composition, internal and externalchoice are standard (see [117] and [52]). Rules for Broadcast permit the interleavingof the actions of parallel components when actions outside the specifiedchannel set are performed, and allows multiple synchronization of processes onone of the synchronization channels.3.1.2 CCSP Back-endA process algebra can be added in TAPAs just defining notions of state and actionand the semantics of all operators. Figure 9 shown the class diagram definingCCSP plug-in back-end: the state, the actions and the operators. CCSPState(not shown in Fig. 9) defines the CCSP state notion and is represented justwith a name. There are three classes defining three different kind of actions:Input, Output and Tau. The first two classes have an attribute for channel, whilethe third class represent the invisible action τ. For each CCSP operator, it iscreated a new Java class that have to implement the three methods: getNext(),

3.1 ccsp plug-in 51extenduseParallelCCSPProcessRestrictionCCSPActionInputBroadcastRelabelingOutputInt. ChcPrefixTauExt. ChcNilFigure 9: CCSP operators structuregetNext(Action a) and getNext(Filter f) defining its structural operationalsemantics.Finally, we build a compiler that transforms a textual representation of a CCSPmodel into an appropriate Java-Object-Graph: i.e. an objects representation ofthe given string. To perform this task, we decided to use JavaCC (Java CompilerCompiler, [6, 68]): a very powerful parser/scanner generator that processes agrammar specification. It also produces a set of Java classes that can read andanalyze input matching that grammar. JavaCC integrates JJTree, a tree builderthat enhances the generated parser by decorating it with an Abstract SyntaxTree (AST).The back-end structure was thought having in mind the analysis tools andGUI features. In order to facilitate back-end and front-end integration, we minimizethe interaction between these two components, adopting a transactionalapproach in which a set of operations is performed in an independent unit ofwork. To do this we used the pattern Command that allows to isolate the portionof code that performs an action (possibly very complex) from the code thatrequires execution. This approach allows us to easily implement an undo/redosystem. Every command has a do() and an undo() methods, and whenever theuser wants to modify the model, a new command instance is created. After itscreation, a command is executed through the do() method and then it is stored inthe commands history. When the user wants to undo a command, the programsimply pops the most recent command object and executes its undo() method.The back-end undo/redo system has to be integrated with the front-end one,indeed not all the actions performed on the GUI modify the model structure.Basically there are two different undo/redo systems: one for the model structureand the other for graphic appearance, CCSP Plug-in decides which action has tobe redone or undone.

52 ccsp and pepa pluginFigure 10: Graphical and textual specification of Bill and Ben.3.1.3 CCSP Front-endThis plug-in allows to insert terms into the system by using either a textualrepresentation or a graphical notation. A process can be represented both asa CCSP term and as a graph whose edges are labeled with the actions it canperform. TAPAs consistently updates terms when the graphical representationof LTS is changed and redraws process graphs when terms are modified. Thisfeatures allow users to appreciate the close correspondence between terms andprocesses.To draw processes and LTS, we use JGraph [32] a graph drawing open sourcesoftware written in Java; it started by Gaudenz Alder as a University project in2000 at ETH Zurich, Switzerland. Thanks to its strict adherence to Swing designand a large community following, JGraph matured into a professional-gradeoffering with a large number of applications. A lot of projects, both open sourceand commercial, chose JGraph as part of their critical applications.On the left-hand side, Figure 10 shows textual and graphical representationsof two CCSP processes: Bill and Ben. Process Bill can perform an input onchannel play and continue with an input on meet, while process Ben can performfirst an output on work and then an output on meet. Systems, like processes,are represented both graphically and textually. The system corresponding tothe parallel composition of the processes Bill and Ben is shown on the righthandside of Figure 10. In the graphical representation, a system is representedby a box containing a set of elements. To guarantee synchronization betweenBill and Ben, channel meet is restricted. This is represented graphically bya black barrier around parallel composition. Moreover when an user wantsto restrict a system, GUI shows automatically the set of actions that can berestricted. In Figure 10 under the label "Restricted Channels", it is shownthe set of "restrictable" channels (meet, play, work) and only the checked one(meet) is restricted. Furthermore CCSP plug-in allows to restrict a terms over a

3.1 ccsp plug-in 53Figure 11: Model checker and Equivalence checkerchannel that a system does not use. To do this, user has to click button labeledwith "+" and the insert manually the channel name. This plug-in support userthrough development process with many other features, for example it retrievesautomatically the set of channels that can be renamed by using relabelingoperator. To provide a first debugging help, CCSP plug-in shows the set ofaction that can be performed by every sub-terms just clicking on respectivegraphic components. On the right-hand side of Figure 10, under the label"Actions", are shown all the actions that the root system (BillBen) can perform:play? and work?. When users select a different graphic element, actions arereplaced with those of the selected one. In the example of Figure 10, selectingBill[X1], the actions play? and meet? will be shown. As for processes, textualrepresentation of BillBen system is shown in the respective text area. After asystem is defined, TAPAs allows to generate the corresponding LTS that can bere-imported as process or minimized up-to a predefined equivalence.Usually, after having been defined, a model is analyzed by using some verificationtechniques. In Figure 11 are shown the model checker (left-hand side)and the equivalence checker (right-hand side) panels. In the first one, the userhas to select the system under verification, and import a text file containing theproperties definitions. Notably, model checker can accept both ACTL (Fig. 11:EWork, AWork and AWorkPlay) and µ − calculus (Fig. 11: Sys_specification,Deadlock_freedom and Livelock_freedom) formulas. After the button "Check"is pressed, TAPAs verifies whether the system satisfies the formulas or not.In the equivalence checker panel (Figure 11, right-hand side), the user hasto select two CCSP terms (processes or systems), and an equivalence. For eachequivalence, the panel allows user to select specific options through propergraphic elements; for example it permits choosing the algorithm to computethe bisimulation. Changing the equivalence selected, also available optionswill change. Whenever an equivalence check turns out to be unsuccessful,

54 ccsp and pepa pluginFigure 12: The navigatorthe bottom right text area shows the results. TAPAs provides evidences thatthe analyzed systems do behave differently: two set of HML formulas thatcapture a properties satisfied only by one of the two in-equivalent processes areexhibited. Equivalence checker algorithms are also used for implementing theLTSs Minimizer. This module allows users to minimize LTSs with large numberof states while preserving strong, weak bisimulation or tau.∗ equivalence.After the analysis phase, an user may wish to interpret the results, by controllingmodel behavior just analyzed. For example, user would like to know whya CCSP term does not satisfy a formula, or why two terms are not equivalent.TAPAs provides a navigator for step-by-step analysis: starting from the initialstate, it allows to unfold the system choosing one of the possible traces. It keepstrack of actions taken, shows the current status of the system, and, for each availableaction, the next state. Figure 12 shows two navigator screen-shots: on theleft hand-side the BillBen system in its initial state, on the right hand-side thesame system after two steps. The navigator panel is composed of four graphicelements that show the system status and allows the step-by-step navigation:1. Current state: it shows the textual representation of the current state.2. Actions: it shows the list of all available actions and provides buttons (upand down arrows) for performing system evolution.3. Next state: it shows the textual representation of the next state; it dependson the action selected.4. Components visualization: it shows the actions taken and the componentsinvolved.When an user change the selected action, the panel automatically changesthe Next state content and highlights (in green) the sub-components that are

3.2 case study: two-phase commit protocol 554 Dining 5 Dining Peterson’s mutual 5 ClientPhilosophers Philosophers exclusion algor. 4 Server(1173 states) (7035 states) (115 states) (4032 states)Deadlock Freedom yes (1.5 s) yes (60.2 s) yes (0.04) s yes (0.8 s)Starvation Freedom yes (0.8 s) yes (9.6 s) yes (0.02) s yes (2.9 s)Table 12: Execution times.involved in performing that action. When down (up) arrow button is pressed,the navigator does (undoes) the selected action and then it updates itself with thenew status informations. This simple tool assists the user in the debugging phaseshowing the available actions and the interactions between sub-components.In Table 12 are shown results of few well-known problems: (four and five)dining philosophers, Peterson’s mutual exclusion algorithm and a client/serversystem. The models generate from hundred to thousand of states and they allare checked against three commons properties: Deadlock, Starvation, and Livelock.Obviously, the models satisfy the properties, but, in this case, we are moreinterested in execution times. TAPAs can always give an answer in less then oneminute.3.2 case study: two-phase commit protocolDistributed atomic commitment protocols (DACPs) are well-known [89, 139, 138]protocols for achieving agreement in distributed environments. They are distributedalgorithms that coordinate all the processes participating in a distributedatomic transaction. Their aim is to reach consensus on whether to commit orabort the transaction. In [139] a formal model describing two different protocolsis defined: the Two-Phase Commit Protocol (2PC) and Extended Two-Phase CommitProtocol (E-2PC). The authors show how the proposed protocols are (or are not)resilient to a site or network failure. In this Section we use CCSP plug-in toprove correctness of the considered protocols under different assumptions onthe underling network infrastructure.3.2.1 Atomic Commitment ProtocolIn distributed systems a transaction is a (logically) atomic operation. In orderto provide safe data sharing, transactions have to enjoy the ACID properties:Atomicity, Consistency, Isolation and Durability. The execution of a transactioncan be viewed as follows: at some time a “commit point” is reached and thesite decides whether to commit or abort the transaction. A commit indicates thata set of distinct changes are made as a single operation. Conversely, an abort

56 ccsp and pepa pluginindicates that the effects of the transaction are nullified: the system’s state isrollbacked to before the transaction started. Distributed atomic commitmentprotocols aim to guarantee global atomicity (all sites either abort or commit thetransaction), while avoiding inconsistent configurations (some sites abort, whileothers commit).A protocol is non-blocking if it is never blocked because of a failure, andresilient if it is non-blocking and ensures transaction atomicity even in presenceof failures. In many applications blocking protocols are undesirable. Indeedblocked processes do not release the acquired locks leading the system in adangerous configuration. Notice that the success of a transaction depends onthe weakest site in the distributed system.When failures occur, sites have to perform suitable operations that permitssystem to recover a consistent state. A site perform an independent recovery whenonly local information are used during the recovery phase (i.e. without anymessage exchange). Hence, recovery is independent of any event occurring afterthe site’s failure. To guarantee the independent recovery, after a fail, a site hasto immediately decide if commit or abort the transaction. In this regards, independentrecovery provides a real non-blocking recovery strategy: if a site usedalso non-local data, it should gain access to some remote resources; obviously itwould be blocked if the remote resources were temporarily unavailable.In DACPs a network is thought of as a set of point-to-point links between anypair of sites. Moreover it is assumed that either messages are delivered within atime interval T or it is reported a timeout to the sender. This is a very strongassumption because a slow (but correct) network behavior is not taken intoaccount. After receiving a timeout, the sender can assume that the network orthe recipient or both have failed. If the network fails, it is not possible to knowwhether the message was delivered to the receiver.3.2.2 Two-phase Commit ProtocolAchieving consensus allows a distributed system to act as a single entity, withevery individual site aware of and in agreement with the actions of the wholenetwork. The protocol lets all sites in a distributed system agree to either completeor rollback a transaction, thus achieving global atomicity in a networkedenvironment. It assumes that one site is the coordinator, the master site, whilethe others sites in the network are called cohorts. Other assumptions of theprotocol include stable storage and local atomic transactions at each site. Theseassumptions guarantee that every site is able to tell whether it has failed andnever ends up in an inconsistent local state. The behavior of protocols can besummarized as follows:• Coordinator:1. Contact every cohort, request a transaction and gather their responses.

3.2 case study: two-phase commit protocol 572. If everyone agrees, contact every cohort again to let them know.Otherwise, contact every cohort to abort the transaction.• Cohort:1. When a transaction request is received prepare the transaction upto the commit point. Send an agreement and wait if able to commit,otherwise report an abort.2. If a commit message is received complete the transaction. Otherwiseif an abort message is received abort the transaction.The “extended” version of the Two-Phase Commit Protocol (E-2PC) schedulesa further message: after receiving a commit message, the Cohort sends anacknowledgement message (ack) to the Coordinator. Figure 13 shows an unifiedschema of the two protocols with only two sites.Ask to cohorts phase 1Coordinatorcan commit?CohortDecidedfor commit(abort)phase 2yes (no)commit (abort)ackTimeout causes abort.Perhaps ack thecommitFigure 13: (Extended) Two-Phase Commit Protocol schema3.2.3 Modeling NetworksDistributed systems are classically defined as a set of sites communicating via aset of links (cfr. for instance [133]). From this point of view a network is viewedas a set of links connecting sites. In communicating systems it is possible todistinguish three different entities: links, network and environment. A link providesa communication medium between two sites, the network is a set of links and theenvironment is the set of communicating sites. Each of these entities has its ownproperties and their combination defines the particular system. In this section, itwill be shown how links and network can be modeled as CCSP terms.LinksA link is the lowest level communication entity and it is characterized by twomain properties: reliability and communication direction. A link is reliable if every

58 ccsp and pepa pluginmessage sent will be eventually delivered. Moreover, a site can never receivetwice the same message and it only receives messages that have been previouslysent. Hence there can be no loss, duplication, or spurious creation of messages.Communication direction indicates the direction in which messages can betransmitted. Simplex, if messages can be sent in one direction only; half duplex,if communication can occur in both directions (not simultaneously); and fullduplex, if communication can simultaneously occur in both directions. A simplexlink can be thought of as a process that sends over a channel b all the messagesreceived on channel a. Let M = {m 1 , . . . , m n } be a set of messages that can besent over a link; the following CCSP processes implements a simplex reliablelink.RL a,bM ∑m∈Ma m ?.b m !.RL a,bMIt performs an input on port a m and then it always performs an output onport b m . On the contrary, after an input, the unreliable link (UL a,bM) can performeither an output or a τ action simulating message loss. The following processesmodel an unreliable link managing all the messages in M.UL a,bM ∑m∈Ma m ?.(b m !.UL a,bM+ τ.ULa,b M )For example in Figure14 shows a reliable (above) and an unreliable (below)links that can manage two different messages: request and response.Figure 14: A reliable (above) and an unreliable (below) linkHalf duplex and full duplex links can be obtained by composing two simplexlinks. In the first case the simplex links have to work in turn, whereas in thesecond case they can work independently. Let L a,bMand Lc,dMbe two simplex′(reliable or unreliable) links, the full duplex link can be implemented as follows:Full Duplex Link:LC (L a,bM| Lc,d M ′ )

3.2 case study: two-phase commit protocol 593.2.4 NetworksLinks can be composed in a network in order to guarantee specific properties,like, for instance message ordering. Network status can change as a consequenceof internal/external events leading to a different network behavior: for instancea fail can interrupt the message delivering.A network model combines the links processes to describe the expected behavior.Links can be combined in many different ways. Figure 15 shows thegraphical representations of two connection patterns: parallel and series. Componentsconnected in parallel are connected so that the external input/outputchannels are applied to each component (Fig. 15 left side). Components connectedin series are connected along a single path, so that a value flows throughall of the components (Fig. 15 center).a m1· a mnL a,bML a,bMParallela m1· a mna m1a · mnL a,bMLa,b MSeriesa m1a · mnPar ( L a,bM| )La,b MSer ( L a,cM \ [c m/b m ]| L c,bM \ [c m/a m ] ) \{c m }Figure 15: Parallel and Series networksThe networks code (right-hand side of Figure 15) is written using some shortcuts:[c m /b m ] and [c m /a m ] stand for [c m1 /a m1 , . . . , c mn /a mn ] and [c m1 /a m1 ,. . . , c mn /a mn ] respectively; and {c m } stands for {c m1 , . . . , c mn }Process Par models a network that can receive at most two inputs beforeperforming an output, but it has not constraints on the output order. On thecontrary, process Ser preserves message order by just linking every componentsto each other: every links receives the input from its predecessor and forwardsit to its successor.Besides processes modeling links, other components can be considered in anetwork specification. For instance we can take into account a complex scenariowhere messages are lost when a fail event occur, and network restores thenormal behavior when a restore event is performed.This new network model has two additional components: Store and Actuator(cfr. Fig. 16). The first process stores the network status (Failed or Working),and upon receiving a fail or restore message changes its status. The status ofStore process can be checked using the channels isWorking and isFailed. The

60 ccsp and pepa pluginsecond process checks the network status and delivers messages if the networkis working. Here below are shown the models for these processes:Store W isWorking!.Store W + fail?.Store F + restore?.Store WStore F isFailed!.Store F + fail?.Store F + restore?.Store WChan_Actuator a?.(isWorking?.b!.Chan_Actuator+ isFailed?.Chan_Actuator)Actuator (Chan_Actuator\ [a m1 /a, b m1 /b]| Chan_Actuator\ [a m2 /a, b m2 /b]| Store W ) /{isWorking, isFailed}Now the previous processes can be integrated with an old network model:for instance network Ser. Figure 16 shows the graphical representation and thecode for this new model.m 1L a,bML a,bm 1m nMAct m nStoNewNet ( L a,bM \ [L1m/b m]| L a,bM \ [L1m/a m, L2m/b m ]| Act\ [L2m/a m ])\{L1m, L2m}fail restoreFigure 16: New network models3.2.5 2PC and E-2PC: Properties and ModelsIn this section we will model both the 2PC and the E-2PC using network modelsdescribed so far. After defining some interesting properties, we will checkwhich model satisfies them by using Model Checking and Equivalence Checkingtechniques. Our purpose is to highlight how assumptions of network modelscan affect the properties and correctness of distributed algorithms.Abstract Specification and Protocol Properties2PC and E-2PC are two protocols that resolve the same problem: atomic commitmentin a distributed environment. For this reason we consider the sameabstract behavior and expected properties for both of them. The former is specifiedby means of a CCSP process that summarize expected behavior (expressed interms of visible actions) of a DACPs. The latter is formalized as a set of logicalformulas. There are two fundamental properties one can assume satisfied byeach instance of a DACPs:1. Termination: all sites eventually decide.

3.2 case study: two-phase commit protocol 612. Agreement: all sites decide on the same action (Complete! or Rollback!).Abstract specification of the 2-site system is very simple. Indeed, the systemis required to perform a transaction, either both the sites complete it or bothabort it. The decision is taken internally by the system and cannot be forced bythe environment. More formally:2PCP_Spec TxReq?.(τ.Complete!.Complete!.nil+ τ.Rollback!.Rollback!.nil)It is immediately clear that this system will eventually terminate because itdoes not contain any recursive definition. Furthermore the only possible tracesare:• TxReq?.τ.Complete!.Complete!.nil• TxReq?.τ.Rollback!.Rollback!.nilwhich obviously fulfill both Agreement and Termination properties.Property Termination simply tells that the system will eventually stop (i.e.every possible execution path is finite) and it expressed as the existence ofdeadlock for every possible paths.Termination ∆ = AF [∗] ffProperty Agreement is satisfied when action Complete! can not be performedafter action Rollback!, and vice-versa. This is easily expressed using the formulaslisted below.NO_CR ¬EF < Complete! > EF < Rollback! > ttNO_RC ¬EF < Rollback! > EF < Complete! > ttAgreement NO_RC ∧ NO_CRThis property guarantees that once the system has chosen an action, it willstick with it. Notice that the abstract specification satisfies both Terminationand Agreement formula.Two-Phase Commit Protocol: Concrete SystemThe concrete 2-sites system can be modeled just following the simple descriptiongiven at the beginning of this section: it has to models the interactions betweenthe Coordinator and Cohort via the Network. As shown in Figure 17, the Coordinatorand Cohort models are very simple and straightforward.The network connecting Coordinator and Cohort has to manage five differentmessages: RTC, Yes, No, Commit and Abort. In this first case it is not necessary

62 ccsp and pepa pluginFigure 17: Coordinator and Cohort for the 2PCto keep message order, so a parallel network is sufficient. The network code isshown below:Net ( RL a,bMRL c,dM| RLa,b M | RLc,d M| M = {RTC, Yes, No, Commit, Abort})The system modeling the 2PC contains parallel composition of processes:Coordinator, Cohort and Net, conveniently restricted. Using the provided EC andMC, it easy to see that this model is equivalent to the abstract representationand satisfies both the properties.To take site failure into account, processes of Figure 17 have to be extendedwith failure transitions. These transitions will be intercepted by the underlingnetwork that will send a timeout to the remote participant. As described in [139],this simple protocol can not be made resilient. Indeed, according to independentrecovery, after a failure, a participant has to immediately decides if abort orcommit the transaction.In Cohort process (Fig. 17) it is not possible add correctly a failure transitionoutgoing from the state 2. In this case there are two possible arrival states (3 and4), but both solutions do not allow to create a correct 2PC model. Indeed, whenevera fail transition is considered, the resulting system violates the Agreementproperty. To prove this, one can create two new Cohort models modifying theexisting one by adding a fail! transition. In the first case, it is between states 2and 3, in the second case it is between states 2 and 4.Using TAPAs equivalence checker, it is easy see that these two variants are not"may" equivalent to the abstract specification. TAPAs generates the followingcounterexamples.• ≪ TxReq? ≫≪ Complete! ≫≪ Rollback! ≫ tt.• ≪ TxReq? ≫≪ Rollback! ≫≪ Complete! ≫ tt.

3.2 case study: two-phase commit protocol 63It is also possible use the TAPAs model checker to check the Agreement and Terminationproperties. As expected the two protocol variants satisfy the Terminationbut not the Agreement property.Extended Two-Phase Commit Protocol: Concrete SystemTo make the protocol resilient to site failure, in [139] the Extended Two-PhaseCommit Protocol (E-2PC) has been proposed. The Cohort has to ack its decisionto commit, sending an Ack message to the Coordinator. As shown in Figure18, the actions Fail! and TimeOut! can be added to the two participants asdescribed in [139]. Both processes can fail and when one fails the other receivesthe time out generated by the network. Notice that unfailing Coordinator andCohort can be simply derived by restricting them on the Fail! action.Figure 18: Coordinator and Cohort for the E-2PCSince E-2PC is only resilient to a single site failure, it is necessary to define twodifferent systems: in the first (FaCoo_UnCoh) there will be a failing Coordinatorand an unfailing Cohort, in the second (UnCoo_FaCoh) there will be an unfailingCoordinator and a failing Cohort. The network definition is still Net for bothsystems.Now the equivalence checker can be used to prove the correctness of bothsystems. As expected the UnCoo_FaCoh and 2PCP_Spec are weakly bisimilar.Surprisingly the FaCoo_UnCoh is not even "may" equivalent to 2PCP_Spec. Thecounterexamples generated by TAPAs are shown below.• ≪ TxReq? ≫≪ Complete! ≫≪ Rollback! ≫ tt.• ≪ TxReq? ≫≪ Rollback! ≫≪ Complete! ≫ tt.As you can see, these are the same counterexamples generated for the previoussystem: the system FaCoo_UnCoh violates the agreement property. Figure 19shows a simulation that leads to a non-agreement condition.

64 ccsp and pepa pluginFigure 19: SimulatorThe left side of the simulator lists the actions (Complete! and Rollback!) thatcan be performed from the current state: so the system is in an non-agreementcondition. The right side shows the evolution of the three interacting components(Coordinator, Net and Cohort). In the simulator tau#α denotes a τ transition thatis obtained as the consequence of a synchronization over channel α.At the beginning the Coordinator receives a request (TxReq?) and send arequest to commit through the net (tau#b_RTC). The Cohort receives the request(tau#c_RTC) and respond affirmatively (tau#d_Yes). The Coordinatorreceives the affirmative response (tau#a_Yes), then sends the commit message(tau#b_Commit) and then immediately fails (tau#b_Fail) moving to a commitstate. At this moment there are two messages on the net: tau#b_Commitand tau#b_Fail. The Net model is not required to keep the message order, sothe second message sent (tau#b_Fail) can be delivered before the first one(tau#b_Commit). The Cohort receives the time out message (tau#c_TimeOut)and then moves to a rollback state. Therefore a process wants to commit whereasthe other wants to rollback.Obviously this problem concerns only the model, and not the protocol. Indeedthe non-agreement condition is due to the disorder delivering of the commitand TimeOut messages. In the E-2PC model, the TimeOut is generated by thenetwork in response to a site failure, but in the protocol implementation the

3.2 case study: two-phase commit protocol 65TimeOut message does not exist. A site failure is detected by the absence of theexpected message. Classically it is assumed that each site has a time interval Tto bound the time it waits for the receipt of a message. If the timer expires, thesite assume a failure of the remote participant and it behaves accordingly to theprotocol specification.To guarantee the correctness of models, the TimeOut messages has to bedelivered after all the messages previously sent. The simplest solution is tomodel a network that can keep the messages totally order (left-hand side of Fig.20). In this case this additional strong hypothesis should be added also on theprotocol definition.Another solution is to model a network keeping messages in partial order: theTimeOut! is delivered after all the messages previously sent. This solution stillsolves the problem (right-hand side of Fig. 20) and it adds a constraint about amessage that does not exist in the protocol definition.L MCooL MCoo FailFail CohL M L ML MCohL M L ML MFigure 20: NetworksIn both cases two simplex links are needed: one from Coordinator to Cohort(blue/dark arrow) and the other from Cohort to Coordinator (orange/light arrow).In the second example links are composed in parallel and the system hastwo additional (Fail) modules. If a site fails, the Fail module waits until the twolinks are empty and then sends a TimeOut! over the net (red arrows). In thisway the network provides a partial message order. The link specifications haveto be slightly modified to take into account the Fail modules. As expected thesystems using these new network models are weakly bisimilar to the systemspecification and they also satisfy the Agreement and Termination properties.In the next future, networks will become more and more complex and heterogeneous,thus hard to define and model. Process algebras can help in thistask providing some techniques for formal verification. Nevertheless there isthe need to have good and well-defined practices for modeling complex (andcommon) systems.In this Section we have presented some patterns to model networks. Theycould be reused in many others cases to simplify protocols specifications andreduce design errors We have shown how even a well-known protocol can havesome unexpected behavior if the network is not formally specified and verified.

66 ccsp and pepa plugin3.3 pepa plug-inTAPAs can be also used to create GUI for already developed analysis tools.Thanks to its modular structure, is not necessary to implement all the Javainterfaces declared in TAPAs Kernel. In this section, we will show how tointegrate the (already developed) PEPA libraries into TAPAs, creating a newtool that provides a graphical specification and several new features. PEPA [87]is a stochastic formal language for modeling distributed systems. Actions areassumed to have a duration, thus (α, r) represents the action α exponentiallydistributed with rate r. This rate gives an average delay of 1/r and variance of1/λ 2 . Exponentially timed actions describe activities that are relevant from theperformance point of view.PEPA process algebra is supported by PEPA Eclipse Plug-in Project [144, 10],an integrated development environment for Eclipse. The tool has an editor andan analyzer which can use Markov chain and ODE methods for performingsimulation or model checking. It does not provide graphical specification, butsome results are displayed graphically on Eclipse panels. This plug-in is knownto work with Eclipse 3.3 (Europa), 3.4 (Ganymede), and 3.5 (Galileo) but, at thetime of writing, there are no indications as to its compatibility with the newversion 3.6 (Helios). It has been built using Java 1.5, thus is compatible withWindows, Linux but there are some known issues about SWT on OS X. Theplug-in is composed of six different jar having a total size of approximately5MB, but the suggested Eclipse distribution (Eclipse IDE for Java Developers)has a size of 99MB. Therefore, before installing the PEPA Eclipse Plug-in, it isnecessary to install a software that is 20 times bigger. For these reasons, itseemed advantageous to develop a PEPA plug-in for TAPAs that was lighter andeasier to install.3.3.1 PEPA Syntax And SemanticsAs in CCSP, terms are generated by the two-level syntax shown in Figure 21,where P defines sequential components and S defines model components. Prefixand Sum are the standard operators that permit specifying non-deterministicsequential components, while Hiding and Cooperation are used to create complexmodels using simple sub-components.The process (α, r).P describes a terms which performs the action α, and thenbehaves as P. The time taken to perform α is described by an exponentiallydistributed random variable with parameter r. The process P 1 + P 2 represents aterm which can behave like P 1 or P 2 . The ability of a system to hide some transitionsto the external environment is provided by the Hiding operator, denoted byS/L. The set L identifies those actions which are considered private by the systemand they are presented to external environment as τ. Processes can also be

3.3 pepa plug-in 67SyntaxP = (α, r).P ∣ P 1 + P 2S = P ∣ S 1 ⊲⊳L S 2∣ S/{L}SemanticsPrefix :(α, r)(α, r).P −→ PSum :P 1(α, r)−→ P ′ 1P 1 +P 2(α, r)−→ P ′ 1P 2(α, r)−→ P ′ 2P 1 +P 2(α, r)−→ P ′ 2Cooperation :(α, r)S 1 −→ S 1′S 1 ⊲⊳ S (α, r)2 −→ S ′L1 ⊲⊳ S 2L(α ∉ L)(α, r)S 2 −→ S 2′S 1 ⊲⊳ S (α, r)2 −→ S 1 ⊲⊳L L S′ 2(α ∉ L)(α, rS 1 )1 −→ S 1 ′ (α, rS 2 )2 −→ S 2′S 1 ⊲⊳ S (α, R)2 −→ S ′L1 ⊲⊳ L S′ 2(α ∈ L) R = r 1r α (S 1 )r 2r α (S 2 ) min(r α(S 1 ), r α (S 2 ))(α, r)SHiding :−→ S ′(α, r)S/L −→ S ′ /L(α, r)S(α /∈ L)−→ S ′(τ, r)S/L −→ S ′ /L(α ∈ L)Figure 21: PEPA syntax and semantics.forced to contemporaneously perform activities; the synchronization is obtainedby means of the Cooperation operator. The actions within the cooperation setmust be performed together, while other actions are performed independentlyand concurrently. The cooperation between S 1 and S 2 synchronized over thecooperation set L, is denoted as S 1 ⊲⊳ S 2. If SL 1 can perform an action α ∈ L, then itmust first wait for S 2 to reach a point where it is also capable of producing an αaction, and vice-versa. The rate parameter may also be undefined (representedwith the symbol ⊤), which makes the action passive in a cooperation. In anactive cooperation, two components jointly produce an α action with a rate thatreflects the slower of the two components (usually the minimum of the twoindividual rates). In a passive cooperation, just one of two components (not both)can perform a passive action, the join α action inherits its rate from the activeaction. For example if S 1 and S 2 perform actions (α, ⊤) and (α, λ) respectively,the join rate is r.3.3.2 PEPA Back-EndTAPAs Kernel provides two tools for models analysis (model checker and equivalencechecker), and three tools for models debugging (LTS generator, minimizer,and the navigator). Since PEPA libraries already provides analysis tools, we

68 ccsp and pepa pluginextendusePEPAProcessCooperationPrefixSumPEPAActionActivePassiveFigure 22: PEPA operators structurechose to use them and not to reimplement. On the contrary we exploited TAPAsKernel methods for providing debugging features. The debugging tools comprisethe navigator and the LTS generator and they are provided by implementingthe interfaces available in the Kernel modules. The analysis tool comprise thesteady state and passage time analysis and they are provided by using librariesdeveloped for PEPA Eclipse Plug-in, PEPA libraries henceforth. These librariesare partially integrated in the PEPA Plug-in, indeed not all the provided featuresare available in the GUI.To create PEPA plug-in, we acted as in the CCSP plug-in case, that is justdefying state and action notions and the operational semantics for each operator.The Figure 22 shown the class diagram defining the PEPA plug-in back-end:operators and actions. As done into CCSP plug-in developing, a new Javaclass for each operators that has to be implemented. Notice that the Hidingoperator has not been implemented even if it is in PEPA syntax. This is becausePEPA libraries do not seem to support such operator. These new classes haveto implement the already mentioned three methods: getNext(), getNext(Actiona) and getNext(Filter f) that define structural operational semantics for thecorresponding operators. In PEPA there are only two possible kind of actions:active or passive actions. active is defined by means of a channel and a rate, whilepassive action has only the channel name and the rate is considered to be infinite.PEPA Plug-in needs a compiler for transforming textual representation in theappropriate object structure. As for CCSP Plug-in, we use JavaCC for build thePEPA compiler. Furthermore, even in this case a transactional approach allowedto reduce the interaction between front-end and back-end and to obtain anundo/redo system in an easy way.3.3.3 PEPA Front-EndPEPA plug-in allows users to specify components by using either a textualrepresentation or a graphical notation, and handles the update of the tworepresentation. When the user change the graphical representation, it updatesterms, while redraws process graphs when textual specification is modified. Fordrawing LTS we used again JGraph libraries.

3.3 pepa plug-in 69Figure 23: Graphical and textual specification of Bill and Ben.Figure 24: Steady state analysis panelFigure 23 shows the Bill&Ben example, modeled as a PEPA process. Thesystem is composed of two sequential components (Bill and Ben) cooperatingon meet action. The processes perform their first action in race condition, andthen they synchronize themselves on meet action. The rate of the shared actionis the minimum of the rates in the cooperating components. Notice that the ratesof the actions can be variables, (i.e. r1 or r2); in this case they must be specifiedin the cooperation component. An user can change the default rate value usingthe table in the model component panel (right-hand side of Figure 23).Thanks to the support offered to us by PEPA Eclipse Plug-in developers, theintegration between PEPA plug-in and PEPA libraries was relatively straightforward.First of all, we built a visitor that scans the model object structure andcreate the appropriate representation according to the PEPA libraries syntax.In this way we can use analysis methods developed for PEPA Eclipse Plug-in.

70 ccsp and pepa pluginFigure 25: Passage time analysis panelAfterwards we created panels for setting analysis parameters and formattingresults. Figure 24 shows the panel laid out for steady state analysis, while Figure25 shows the panel for passage time analysis.In order to facilitate users, we have decided to make the GUI as similar aspossible to that provided in Eclipse plug-in. The only change we made was toinclude the choice of all options in a single panel, thereby eliminating all theclick on the "Next" buttons. Panel are divided into three parts: on the left thereare buttons for choosing the kind of the analysis (steady state or passage time), inthe middle there are the graphical components for changing options (the solverto use, time constraints, source and target actions, etc.) and the right-hand sidepanel is used to show analysis results.Steady state panel permits analyzing systems after they have reached anequilibrium condition, namely when the passage of time does not change thesystem state. PEPA allows to analyze three different properties for steady statesystems: Utilization, Throughput and Population. The first one shows the utilizationof each top-level component of the model in a tree manner. In particular Figure 24shows the results of the analysis performed on the Bill&Ben system: the processBill (Ben) stays the 40% of the time in the state s0 and the rest of the time inthe state s1. The Throughput tab lists the rate at which actions are performed (0.4for all the three actions), while Population shows the utilization of each top-levelcomponent weighted with its multiplicity, in this case is exactly the same thatUtilization.

3.4 case study: two-phase commit protocols 71Passage time analysis requires to specify more parameters than steady stateanalysis. First of all the user has to specify time constraints regarding thebeginning, the in-between steps and end of the simulation; then at least asource and a target action have to be chosen. Finally user can decide whichfunction to calculate: Cumulative Distribution Function (CDF) or Probability DensityFunction (PDF). Moreover, passage time panel allows to perform experimentsby specifying values over which vary a variable rate. Figure 25 shows theBill&Ben passage time analysis where source and target actions are play andmeet respectively; three experiments were done by varying r1 from 1.0 to 3.0and the CDF has been calculated.As you notice, CCSP plug-in and PEPA plug-in have a similar structure.Both implements a process algebra with two level syntax: first level includesprefix and non-deterministic choice, while the second has composition operators.Moreover both provides a consistent doubly (graphical and textual) specificationand an undo/redo system. Therefore during PEPA plug-in implementation, itwas possible to reuse much of the code written for CCSP plug-in.3.4 case study: two-phase commit protocolsIn Section 3.2 two models for distributed atomic commitment protocols havebeen presented: Two-Phase Commit Protocol (2PC) and Extended Two-PhaseCommit Protocol (E-2PC). Qualitative analysis states that the former can not bemade resilient to a single site failure, and the latter can be resilient only underspecific condition over networks.In this Section the same 2PC protocol will be modeled by using the sameapproach for modeling networks seen previously. The aim is not to perform qualitativeanalysis (yes or no answer) but quantitative analysis. Our purpose is tohighlight how assumptions on communication channels can affect performancesof this distributed system.3.4.1 Networks Modeling in PEPAAs written previously, the lowest level communication entities are links, simpleprocesses that receive a message on a channel and forward it to another channel.In this case, links are characterized by three properties:1. Reliability: there are not loss, duplication, or spurious creation of messages.2. Communication direction: the direction in which messages can be transmitted.Simplex (one direction only), half duplex (both directions but notsimultaneously) and full duplex (both directions).3. Forward rate: the speed with which messages are propagated through thenetwork.

72 ccsp and pepa pluginWhen links wait for messages from others entities they are passive components,i.e. they do not affect the speed at which messages are generated, but unilaterallydetermine the speed with which they are forwarded through the network. Forthese reasons links have to perform a passive action when receive a message, butan active action forwarding it. For the same reason, a term sending a messageperforms an active action, but passive receiving it. Let M = {m 1 , . . . , m n } bea set of messages that can be sent over a link; the following PEPA processesimplements reliable, unreliable and full duplex link respectively.RL a,bM ∑m∈MUL a,bM ∑m∈MLC (L a,bM(a m , infty).(b m , λ).RL a,bM(a m , infty).(b m , λ).UL a,b|| Lc,dM) ′M+ (a m, infty).UL a,bMLinks can be composed to create complex network structures. Since PEPA hasa broadcast synchronization and has not renaming operator, users should takeparticular care in choosing links names. Indeed networks with duplicated linksnames may show interference phenomena difficult to identify. Having said that,parallel and series networks are built in the same way as was done for CCSP.Figure 26: Coordinator and Cohort for the 2PC3.4.2 Two-Phase Commit Protocols: Concrete SystemsIn this subsection it will be presented a PEPA model representing 2PC ascharacterized in Section 3.2.2. In CCSP models, the Coordinator and the Cohortcoordinate themselves on whether to commit or abort the transaction andthen both are in a deadlock state. Since in PEPA every model component has tohave an infinite behavior, the two 2PC processes have to continuously interact

3.4 case study: two-phase commit protocols 73for achieving consensus, hence, after terminating protocol, both restart fromtheir initial state. Moreover, in the two sequential components, every action isequipped with a rate: ⊤ (infty) for received messages, a positive real numberotherwise. Figure 26 shows the sequential components for Coordinator and Cohort.This case study aims at showing the main PEPA plug-in features and theirgraphic interface. For this reason, the rates of all active actions are set to one.Users can simply change value rates with just a click on the GUI.The network for this models has to manage five different messages, three fromCoordinator to Cohort (RTC, Commit and Abort), and the others two in (Yes andNo) opposite direction. This network is implemented composing two differentlinks, its code is shown below:Net ( RL a,bM)|| RLc,dM ′M = {RTC, Commit, Abort}M ′ = {Yes, No}The system modeling the 2PC contains the cooperation of three processes:Coordinator, Cohort and Net.The steady state analysis can reveal interesting properties of system under consideration.Figure 27 shows the steady state results for Utilization and Throughput.The Utilization analysis panel shows the long-run utilization of each top-levelcomponent. For each of them, it shows the percentage of time it is in a particularlocal state. The Coordinator component stay 44% of the time in S2, namely itwaits the Cohort response. On the contrary, Cohort stays more than half the timewaiting the "request to commit" messages (state S1). On the right-hand side ofFigure 27, Throughput panel lists the rate at which the actions are performed.For example, the complete rate (0.083) is one-third of rollback rate (0.249).Figure 27: 2PC steady state analysisThese values are justified by considering model behavior and recalling that allactive actions have the same rate. After receiving a request to commit, Cohort

74 ccsp and pepa pluginnon-deterministically decides whether to answer in the affirmative or not. If theCoordinator receives a No answer decides to abort, otherwise, if it receives Yes,non-deterministically decides whether complete or abort the transaction. Thisbehavior is summarized in the probability tree of Figure 28. The total probabilityto choose a Rollback leaves is 0.75 and 0.25 to choose Complete, that is theprobability to abort the transaction is three times more likely than complete it.CohortNo Yes0.5 0.5CoordinatorCoordinatorAbort 1.0Abort0.50.5CommitRollback=0.5Rollback=0.25Complete=0.25Figure 28: Rollback or Complete probability treeIt is interesting to note that the total rate of Rollback or Complete is 0.332,twice the txReq rate, this means that for every txReq action there are two actionsRollback or Complete. The values obtained from static analysis can be usedboth to verify the model correctness and to detect critical situation or bottleneck.Passage-Time Analysis computes performance measures such as probabilitydensity functions (PDFs) and cumulative distribution functions (CDFs) betweentwo events. The events that start and stop measurements is defined by meansof two sets of actions: Start actions and Target actions. As the names suggest, thestart actions are used to start the measurement and the target actions are usedto stop it. Together the PDF and CDF give a complete description of a randomvariable evaluated against increasing time.Panel for Passage-Time Analysis allows users to set values before starting theanalysis: Time values, Experimentation, Source and Target actions. Time valuesdetermine the time interval in which performing measurement. Users specifythe start and stop time as well as the time step which determines how manysamplings have to be done. The panel has default values for all these threetime values. The Start and Target actions define the random variable used formeasurements; the tool starts the measurement when the model performs anactions within the start set and the measurement is terminated when the modelperforms any actions within the target set. In order to identified values thatenhance the performance of the model, the Experimentation allows users to varythe rate of a specified action.Figure 29 shows the PDF and CDF of the Two-Phase Commit Protocol modelwith following settings:• Time values = [0, 0.1, 10.0]

3.4 case study: two-phase commit protocols 75Figure 29: PDF and CDF for 2PC• Start actions = {txReq}• Targetactions = {Complete, Rollback}The PDF shows that the probability to terminate the protocol in 1s, 2s or 3sare 0.35, 0.15 and 0.07 respectively. The CDF shows that the protocol terminateswithin 3s in the 90% of cases.

76 ccsp and pepa plugin

S T O K L A I M4In this Chapter first we will introduce StoKlaim a stochastic extension of Klaim specificallycreated to describe distributed systems with stochastic behavior, and MoSL (MobileStochastic Logic) a stochastic logic for expressing performance and dependability properties.Then we will present StoKlaim plug-in a plugin for supporting specification ofStoKlaim models and verification of MoSL formulas. This plug-in integrates with SAM(Stochastic Analyser for Mobility) for simulating systems behavior and model checkingMoSL formulas. After we will describe a statistical techniques implemented in SAMfor mitigating the state space explosion problem during systems verification. Finally wewill see few case studies: leader election protocols in ring network.Network and distributed systems typically consist of a large number of actorsthat act and interact with each other in a highly dynamic environment. Manyprogramming and specification formalisms have been developed that can dealwith issues such as (code and agent) mobility, remote execution, security, privacyand integrity. Important examples of such languages and frameworks are, amongothers, Obliq [56], Seal [59], ULM [47] and Klaim (Kernel Language for AgentsInteraction and Mobility) [71, 45].Performance and dependability issues are of utmost importance for "networkaware"computing, due to the number of involved actors and their strongdependence on mobility and interaction. Spontaneous computer crashes mayeasily lead to failure of remote execution or process movement, while spuriousnetwork failures may cause loss of code fragments or unpredictable delays.Correctness in network and distributed systems, as well as their safety guarantees,is not a rigid notion "either it is correct or not" but has a less absolute nature: "in99.7% of the cases, safety can be ensured".To facilitate the incorporation of random phenomena in models for networkawarecomputing a stochastic extension of Klaim [71, 45], named StoKlaim,has been proposed in [74]. Klaim is an experimental language for distributedsystems that aims at modeling and programming mobile code applications,i.e., applications for which exploiting code mobility is the prime distinctivefeature. In StoKlaim, every action has a random duration governed by a negativeexponential distribution.In [75], MoSL (Mobile Stochastic Logic), a logic that allows one to refer to thespatial structure of the network for the specification of properties for StoKlaimmodels has been proposed. MoSL is a stochastic logic (inspired by CSL [35, 39])that, together with qualitative properties, permits specifying time-bounded prob-77

78 stoklaimabilistic reachability properties, such as "the likelihood to reach a goal state withint time units while visiting only legal states is at least 0.92". MoSL is also equippedwith operators that permit describing properties resulting from resource productionand consumption. In particular, state properties incorporate features forresource management and context verification. Context verification allows theverification of assumptions on resources and processes in a system at the logicallevel, i.e. without having to change the model to investigate the effect of eachassumption on the system behavior.In this chapter we present StoKlaim plug-in a TAPAs plug-in that can beused for specifying StoKlaim models and verifying quantitative properties ofsuch distributed systems. Differently from the two already presented plug-ins,StoKlaim plug-in does not exploit TAPAs embedded analysis tools nor alreadydeveloped libraries, but it interacts ,via a network connection, with a server thatprovides all the features needed. To support analysis of StoKlaim systems, weuse SAM (Stochastic Analyser for Mobility) [14]: a command-line tool developedin OCaML [114] that provide functionalities for executing, simulating and modelcheckingspecifications. StoKlaim plug-in connects to the server on which a SAMinstance is running and, after sending a request, it receives the analysis results.As case study, we will show how StoKlaim plug-in can be used to model fourclassical leader election algorithms.In Section 4.1 we recall the modeling language Klaim, in Section 4.2 we introducesome probability concepts. In Sections 4.3 and 4.4 we describe StoKlaimlanguage and MoSL logic respectively, while in Section 4.5 we present the StatisticalModel Checking algorithm implemented in SAM. In Section 4.6 we describeStoKlaim plug-in and its main functionality. This plug-in is used to analyze fourleader election protocols, and results analysis (Sec. 4.7) concludes the chapter.4.1 klaimKlaim [45] is a formalism introduced for specifying concurrent and distributedsystems. It has been designed to provide programmers primitives for handlingphysical distribution, scoping and mobility of processes. Klaim is based onprocess algebras but makes use of Linda-like asynchronous communicationand models distribution via multiple shared tuple spaces [85]. Tuple spacesand processes are distributed over different localities and the classical Lindaoperations are indexed with the location of the tuple space they operate on.The Linda communication model was originally proposed for parallel programmingon isolated machines. The model permits time uncoupling (data lifetime is independent of the life time of the producer process), destination uncoupling(the producer of a datum does not need to know the future use or the finaldestination of that datum) and space uncoupling (communicating processes needto know a single interface, i.e. the operations over the tuple space).

4.2 concepts of probability theory 79In Klaim, the network infrastructure is clearly distinguishable from userprocesses and explicitly modeled; localities are “first-class citizens” that can bedynamically created and communicated. We argue that this feature permits amore accurate handling of Global Computing applications. Indeed, structuringthese applications in terms of located processes and coordinators provides aclean and powerful abstraction and is instrumental to define security policiesand their enforcement mechanisms.A Klaim system, called a net, is a set of nodes, each of which is identifiedby a physical locality. Physical Localities can be seen as the addresses of networknodes. Every node has a computational component (a set of processes runningin parallel), an allocation environment and a data component (a tuple space).Processes interact with each other either locally or remotely by posting andretrieving tuples to and from a tuple space. Processes can refer nodes by usingeither physical localities or logical localities. While physical localities have aglobal meaning, logical localities have a local meaning and their interpretationdepends on the node where processes run. Indeed, each node is equipped withan allocation environment mapping logical localities to physical localities. Whena process uses a logical locality, the allocation environment is used to resolvethis name into a physical address.Processes interact with each other by means of messages, named tuples, insertedinto located tuple spaces. Tuples are retrieved from tuple spaces viapattern matching using templates. Processes can also be spawned to be evaluatedremotely.4.2 concepts of probability theoryIn this section a brief introduction to Continuous Time Markov Chains (CTMC)is reported. A full discussion can be found in [28]. Moreover Rate TransitionSystem (RTS) as proposed in [76] will be presented.4.2.1 Exponential DistributionA continuous random variable X is exponential with parameter λ > 0, if itsCumulative Distribution Function (CDF), is of the form:F X (d) ∆ = P{X d} = 1 − e −λd for d 0The CDF is usually indicated with F(x) and describes the probability that areal-valued random variable X will be found at a value less than or equal to x.The real number λ is called the rate of X and determines uniquely the exponentialdistribution. The mean or expected value of an exponentially distributed randomvariable X with rate λ is 1 λ , and the variance of X is given by 1 λ 2 .

80 stoklaimThe CDF describes quantitative phenomena using values measured on differentscales: ordinal, interval or proportional. The first has a total order relation,that is the values can be ordered and any pair of elements are mutually comparableunder the relation. In the second, it is possible to calculate the differencebetween two values, then even order them. Finally, in the last case, it is possibleto calculate the proportion between two values, hence their difference. Theexponential distributions have important characteristics:1. Memoryless: if a random variable X is exponentially distributed, its conditionalprobability obeys:P{X > t + d | X > t} = P{X > d}2. Let X and Y be two random exponential variables with rates λ and µ respectively,the exponential variable min(X, Y) is exponentially distributedwith rate λ + µ. Note that the max(X, Y) is not exponentially distributed.The second property is also called "race condition" because it appears to bea "race" between a number of possible selectable events and the faster eventis executed. When there are two random variables X and Y, with rate λ and µrespectively, the probability that X is faster than Y is determined by:P{X = min(X, Y)} =λλ + µ4.2.2 Continuous Time Markov ChainA CTMC is a pair (S, R) where S is a countable set of states and R is a matrix thatassigns non-negative rate to each pairs of states, such that ∀s ∈ S : ∑ s ′ ∈S R[s, s′ ]converges. (S, R) describes a stochastic process where, for any state s ∈ S, when∑s ′ ∈S R[s, s′ ], the probability of selecting a transition outgoing from s at time tis 1 − e − ∑ s ′ ∈S R[s,s′ ]·t . That is, the probability distribution of the waiting time isexponentially distributed with rate ∑ s ′ ∈S R[s, s′ ] and the probability that thetransition from s to s ′ happens isR[s,s ′ ]∑s ′′ ∈S R[s,s′′ ] .If ∑ s ′ ∈S R[s, s′ ] = 0, then s is called absorbing state, because if a process entersin the state s will always be in there. If R[s, s] > 0 we say that s has a self-loop.Self-loops can be added or removed without the transient nor steady-stateanalysis results were being altered.Theorem 4.2.1 The transient behavior of the CTMC C = (S, R) with R[s, s] > 0 forsome s ∈ S coincides with that of CTMC ˜C = (S, ˜R), such that:{˜R[s, s ′ 0 if s = s ′] = defR[s, s ′ ] otherwiseFor demonstration crf. [33].

4.2 concepts of probability theory 814.2.3 Rate Transition SystemsA Rate Transition System [108] is a generalization of a Labeled Transition System,specifically define to describe stochastic process algebra behavior. It also allowsto generate CTMC associated with a given system. More formally:Definition 4.2.1 (Rate Transition System). An RTS is a triple (S, A, →), where S is aset of states, A is a set of labels and → is a subset of S × A × ∑ s where ∑ s is the setof total function from S to R 0 : [S → R 0 ].Henceforth the symbols R, R 1 , R ′ , . . . indicate the RTS; B, L, R, . . . indicateelements of ∑ s ; while the notation s −−→ α B is a equivalent to (s, α, B) ∈→.αLet s 1 , s 2 be two states in S, if s 1 −−→ B and B(s2 ) = λ ∈ R, then from s 1to s 2 exists a transition α characterized by a exponential distribution with rateλ. B(s 2 ) = 0 indicates that s 2 is not reachable from s 1 through α. From nowon the symbol ∅ indicates the constant function 0, and [s 1 ↦→ v 1 , . . . , s n ↦→ v n ]indicates the function associating s i to every v i and 0 to all others states. ∑ Shas some interesting operators:• + : ∑ S × ∑ S → (S → R 0) with (B + L)s = (Bs) + (Ls);• ⊕ : ∑ S → 2S → R 0 with ⊕BC = ∑ s∈C (Bs), for C ⊂ S;• ⊕B indicates ⊕B(S).Definition 4.2.2 Let R = (S, A, →) be an RTS, then:• R is well-defined if and only if ∀ s ∈ S, α ∈ A and B ∈ ∑ S such that s −−→ α Bthen: ∃ x : ⊕B x;• R is image finite if and only if ∀ s ∈ S, α ∈ A and B ∈ ∑ S such that s −−→ α B,then : B = ∅ or B = [s 1 ↦→ v 1 , . . . , s n ↦→ v n ]• R is fully stochastic, if and only if ∀ s ∈ S, α ∈ A and B, L ∈ ∑ S then:S −−→ α B, S −−→ α L ⇒ B = L.From now on, only well-defined RTS will be considered.Definition 4.2.3 Let R = (S, A, →) be an RTS; for sets S ′ ⊆ S and A ′ ⊆ A, the set ofderivatives of S ′ through A ′ , denoted Der(S ′ , A ′ ), is the smallest set such that:• S ′ ⊆ Der(S ′ , A ′ ),• if s ∈ Der(S ′ , A ′ ) and there exists α ∈ A and L ∈ ∑ S such that s −−→ α L then{s ′ ∈ S|L(s ′ ) > 0} ⊆ Der(S ′ , A ′ ).Definition 4.2.4 Let R = (S, A, →) be a fully stochastic RTS; for S ′ ⊆ S the CTMC ofS ′ , when one considers only labels in finite set A ′ ⊆ A is defined as CTMC[S ′ , A ′ ] = def(Der(S ′ , A ′ ), R) where for all s 1 , s 2 ∈ Der(S ′ , A ′ ) : R[s 1 s 2 ] = def∑α∈A ′ B(s 2)αwith s 1 −−→ B.

82 stoklaim4.3 stoklaim: stochastic klaimAs written before, to deal with performance and dependability issues Klaim hasbeen extended by adding distribution rates to its actions [74]. In the proposedextension, actions are assumed to have a random duration governed by anegative exponential distribution. System specifying by means of the stochasticextension of Klaim can be formally analyzed by using the logic and the modelchecking technique presented in [75].4.3.1 SyntaxWe distinguish the following basic syntactic categories.• Val, ranged over by v, v ′ , v 1 , . . ., is a set of (basic data) values;• LLoc, ranged over by l, l ′ , l 1 , . . ., is a set of logical localities, also calledlocalities; we assume the locality self ∈ LLoc;• PLoc, ranged over by s, s ′ , s 1 , . . ., is a set of physical localities, also calledsites;• Val-var, ranged over by x, x ′ , x 1 , . . ., is a set of value variables;• Loc-var, ranged over by u, u ′ , u 1 , . . ., is set of locality variables;• Proc-var, ranged over by X, X ′ , X 1 , . . ., be a set of process variables.All the above sets are countable and are mutually disjoint. Let l, l ′ , l 1 rangeover Loc = LLoc ∪ PLoc ∪ Loc-var. We will also use e, e ′ , e 1 , . . . to denote valueexpressions. The precise syntax of expressions e is not specified: we assume thatexpressions contain, at least, basic values Val and variables Val-var.We adopt the (⃗·)-notation for sequences; e.g., ⃗l = l 1 , l 2 , . . . , l n denotes asequence over Loc and ⃗x = x 1 , x 2 , . . . , x m is a sequence over Val-var. For sequence⃗s = s 1 , . . . , s n , let {⃗s} denote the set of elements in ⃗s, i.e., {⃗s} = {s 1 , . . . , s n }. Oneelementsequences and singleton sets are denoted as the element they contain,i.e., {s} is denoted as s and ⃗s = s ′ as s ′ . The empty sequence is denoted by ɛ.As shown in Table 13, StoKlaim specifications consist of nets and processes.The most elementary net is the null net, denoted by 0. A net consisting of a singlenode with site s 1 is denoted with s 1 : E where E is a node element. In general,nets consist of several nodes composed in parallel. Node elements are eitherprocesses executing at a node or data represented as a tuple 〈⃗d〉 that is stored ata node (s 1 : 〈⃗d〉). Processes are built up from the terminated process nil, a setof randomly delayed actions, and standard process algebraic constructors suchas prefix, choice, parallel composition and process instantiation with optionalparameters.

4.3 stoklaim: stochastic klaim 83N ::= 0 ∣ ∣ l : E N | N NetsE ::= P ∣ 〈 ⃗d〉 NodesP ::= nil ∣ ∣ ∣ ∣ (A, λ).P P + P P | P X ProcessesA ::= ∣out(⃗d)@l ∣ in( ⃗t)@lread(⃗t)@l ∣ eval(P)@lActionst ::= d ∣ ∣ ?x ?u Templatesd ::= l ∣ e ValuesTable 13: StoKlaim syntaxThe process (A, λ).P executes action A with a random duration that is exponentiallydistributed with rate λ ∈ R + . Note that the execution of an action cantrigger new agents in every location on the net. As mentioned earlier, the processesinteract each other inserting, reading or withdrawing tuples in a specificlocation. A tuple is a sequence of values, and is recovered using templates andpattern-matching. A template is a sequence of template fields. These can be eitheractual fields or a formal fields, i.e. a variables prefixed with a question mark toindicate binding of such variable.A process can withdraw a tuple matching pattern ⃗t from l. The pattermatchingparadigm is very simple: a template matches a tuple if they havethe same number of fields and corresponding fields match (i.e. they are of thesame type). Two values match only if identical, while a value and a variables ortwo variables match if they are of the same type. Matching predicate match isformally defined in Table 14. This leads to a substitution Θ associating values tothe corresponding variables, where Θ 1 ◦ Θ 2 denotes the usual composition ofsubstitutions Θ 1 and Θ 2 .match(?u, l) def= [l/u] match(l, l) def= []match(?x, v) def= [v/x] match(v, v) def= []match(t 1 , d 1 ) = Θ 1 . . . match(t n , d n ) = Θ nmatch((t 1 , . . . , t n ), (d 1 , . . . , d n )) def= Θ 1 ◦ . . . ◦ Θ nTable 14: Pattern-matching of tuples against templates

84 stoklaimA process can write tuple ⃗d in repository l by the action out(⃗d)@l. With aninput action in(t)@l a process can withdraw a tuple matching pattern ⃗t from l.Action read(⃗t)@l is similar to in(⃗t)@l except that retrieved tuple is not deletedfrom the tuple spaces at l. The action eval(P)@l spawns process P at site l. AStoKlaim specification S is a triple E, ∆ ⊢ N where:• E is a function associating to each site in the net N an allocation environment;• ∆ is the set of process definitions (X ∆ = P);• N is a net describing both the structure and the behavior of a system.Allocation environments are used to associate logical localities to physicallocalities. Formally, an allocation environment ρ is a (total) function from Loc toPLoc. We say that a StoKlaim specification E, ∆ ⊢ N is well-formed if and only ifit is type-correct and:• for each s ∈ PLoc, if E(s) = ρ then:– ∀s ′ ∈ PLoc: ρ(s ′ ) = s ′ ;– ρ(self) = s• for each X ∆ = P ∈ ∆, process variable X occurs guarded, i.e. prefixed by anaction, in P or as the argument of an eval action;• processes use only localities that really exist.In the remainder we assume specifications to be well-formed. Moreover, wewill also omit E and ∆ from the specification when their definition is clear fromthe context. Finally we let Spec denotes the set of StoKlaim specifications.4.3.2 Operational semanticsOperational semantics specifications is defined by means of Rate TransitionSystems (RTS). Behavior of StoKlaim specifications is described by means R bk =(Spec, Λ, −→). Where Spec is the set of StoKlaim specifications, while Λ is the setof transition labels γ defined as follows:γ ::=∣ ∣ ∣s 1 : o(⃗d)@s 2 s1 : e(P)@s 2 s1 : i(⃗d)@s 2 s1 : r(⃗d)@s 2∣∣ ∣ ∣s 1 ⊲ ⃗d@s 2 s1 ◮ ⃗d@s 2 s1 ⊳ ⃗d@s 2 s1 ◭ ⃗d@s 2where s 1 : o(⃗d)@s 2 and s 1 : e(P)@s 2 identify output and eval actions; s 1 :i(⃗d)@s 2 and s 1 : r(⃗d)@s 2 identify input and read actions retrieving tuples. Theselabels model internal interactions. Label s 1 ⊲ ⃗d@s 2 and s 1 ◮ ⃗d@s 2 model

4.4 mosl: mobile stochastic logic 85the offer of an input or read action performed by a process. These actionssynchronize with s 1 ⊳ ⃗d@s 2 and s 1 ◭ ⃗d@s 2 that model the availability of tuples.Transition −→ is formally defined by the rules in Tables 15 and 16. Theserules permit deriving with a single proof all the configurations which arereachable from a net with a given transition label. In the operational semanticsthe following notations are used:• For next state function P and net N we let P op N (resp. N op P) be thefunction R such that R(R) is P(N ′ ) if N ′ = N ′ op N (resp. N op N ′ ) and0 otherwise.• For next state functions P and Q, P ‖ Q denotes next state function Rsuch that R(N) is P(N 1 ) · Q(N 2 ) if N = N 1 ‖ N 2 and 0 otherwise. F• For next state function P and value λ ∈ R, P λdenotes next state functionR such that R(N) = P(N)λif λ ≠ 0, 0 otherwise.Interest reader can refer to [76, 33] for a detailed description of RTSs and howthese can be used for describing semantics of stochastic process calculi.4.4 mosl: mobile stochastic logicPerformance and dependability properties of StoKlaim systems can be specifiedby means MoSL [75] (Mobile Stochastic Logic). Key features of this logic are:• it is a temporal logic that permits describing the dynamic evolution of thesystem;• it is both action- and state-based;• it is a real-time logic that permits the use of real-time bounds in the logicalcharacterization of the behaviors of interest;• it is a probabilistic logic that permits expressing not only functional properties,but also properties related to performance and dependability aspects;• it is a spatial logic that references the spatial structure of the network forthe specification.4.4.1 MoSL SemanticsIn this section we briefly recall MoSL syntax (Table 17) and the intuitive semanticsof MoSL. As in the branching-time temporal logic CTL, also in MoSLtwo classes of formulas are considered: state formulas (Φ, Φ ′ , Φ 1 , . . .) and pathformulas (φ, φ ′ , φ 1 , . . .).

86 stoklaim(Out)E(s 1 )(l) = s 2s 1 : (out(⃗d)@l, λ).E s 1:o(⃗d)@s 2−−−−−−−−→ [s1 : E ‖ s 2 : 〈⃗d〉 ↦→ λ](Eval)E(s 1 )(l) = s 2s 1 : (eval(Q)@l, λ).P s 1:e(Q)@s 2−−−−−−−−→ [s1 : P ‖ s 2 : Q ↦→ λ](P-In)(P-Read)E(s 1 )(l) = s 2 ∧ match(⃗t, ⃗d) = Θs 1 : (in(⃗t)@l, λ).P −−−−−−−→ s 1⊲⃗d@s 2[s1 : PΘ ↦→ λ]E(s 1 )(l) = s 2 ∧ match(⃗t, ⃗d) = Θs 1 : (read(⃗t)@l, λ).P −−−−−−−→ s 1◮⃗d@s 2[s1 : PΘ ↦→ λ](T-In)s 2 : 〈⃗d〉s 1 ⊳⃗d@s 2−−−−−−−→ [0 ↦→ 1](T-Read)s 2 : 〈⃗d〉s 1 ◭⃗d@s 2−−−−−−−→ [s2 : 〈v〉 ↦→ 1](P-Chc)l : P−−→ γP ∧ l : Q −−→ γQl : P + Qγ−−→ P + Q(P-Par)l : E 1 ‖ l : E 2l : E 1 |E 2γ−−→ Pγ−−→ P(P-Par)N 1γγ−−→ P ∧ N2 −−→ Q ∧ γ ∉ {s1 : i(⃗d)@s 2 , s 1 : r(⃗t)@s 2 }N 1 ‖ N 2γ−−→ P ‖ N2 + N 1 ‖ QTable 15: StoKlaim Operational Semantics (Part 1)

4.4 mosl: mobile stochastic logic 87s 1 :i(⃗d)@s 2N 1 −−−−−−−−→ Ps sN1 ⊲⃗d@s 21 −−−−−−−→ Pi sN1 ⊳⃗d@s 21 −−−−−−−→ Po(In)s 1 :i(⃗d)@s 2N 2 −−−−−−−−→ Qs sN1 ⊲⃗d@s 22 −−−−−−−→ Qi sN1 ⊳⃗d@s 22 −−−−−−−→ Qos 1 :i(⃗d)@s 2N 1 ‖ N 2 −−−−−−−−→ P s ‖ N 2 + N 1 ‖ Q s + Pi ‖ Q o⊕Q o + Po ‖ Q i⊕P os 1 :r(⃗d)@s 2N 1 −−−−−−−−→ Ps sN1 ◮⃗d@s 21 −−−−−−−→ Pi sN1 ◭⃗d@s 21 −−−−−−−→ Po(Read)s 1 :r(⃗d)@s 2N 2 −−−−−−−−→ Qs sN1 ◮⃗d@s 22 −−−−−−−→ Qi sN1 ◭⃗d@s 22 −−−−−−−→ Qos 1 :r(⃗d)@s 2N 1 ‖ N 2 −−−−−−−−→ P s ‖ N 2 + Pi ‖ Q o⊕Q o + Po ‖ Q i⊕P o(Rec)X ∆ = P ∈ ∆ ∧ l : Pl : Xγ−−→ Pγ−−→ P(F-0) 0 γ−−→ ∅(F-Nil)s 1 : nilγ−−→ ∅(F-Out)γ ≠ s 1 : o(⃗d)@E(s 1 )(l)s 1 : (out(⃗d)@l, λ).Pγ−−→ ∅(F-Eval)γ ≠ s 1 : e(Q)@E(s 1 )(l)s 1 : (eval(Q)@l, λ).Pγ−−→ ∅(F-In)γ ≠ s 1 ⊲ ⃗d@s 1 ∧ ¬match(⃗t, ⃗d)s 1 : (in(⃗t)@s 2 , λ).Pγ−−→ ∅(F-Read)γ ≠ s 1 ◮ ⃗d@s 1 ∧ ¬match(⃗t, ⃗d)s 1 : (read(⃗t)@s 2 , λ).Pγ−−→ ∅(F-Tuple)γ ≠ s 1 ⊳ ⃗d@s 2 ∧ s 1 ◭ ⃗d@s 2s 2 : 〈⃗d〉γ−−→ ∅Table 16: StoKlaim Operational Semantics (Part 2)

88 stoklaimΦ ::= tt | ℵ | ¬ Φ | Φ ∨ Φ | P ⊲⊳p (φ) | S ⊲⊳p (Φ)φ ::= Φ ∆U

4.4 mosl: mobile stochastic logic 89A production formula:Q@l ← Φholds if the network satisfies Φ, whenever a process Q is running at locality l.The formula:〈⃗d〉@l ← Φholds if the network satisfies Φ whenever the tuple ⃗v at l. The productionformulas are very useful for specifying system context. For example, given anetwork N, there may be interest in studying the reaction of a system whenprocess Q is running in a location l ∈ N. Indeed it could be shown that thenetwork can continue to satisfy a formula Φ when Q has been executed: thisproperty may be checked with the formula Q@l ← Φ. The property is directlycontrolled on the network N: in other words, to prove the formula there is noneed to modify the model by adding Q to the system.The production formulas are used to specify how the system reacts to newservice requests. For example, 〈@〉S 2 ← AΦ holds when Φ is satisfied afterreceiving a type S 2 service request.Action Specifiers and Action SetsSince MoSL is both state- and action-based, it is useful to be able to refer tothese actions in the logic, in much the same vein as in action-based CTL [73]. Infact, the actions are specified by sets of action specifiers. For action specifier ξ i ,sets of action specifiers are built using the grammar:∆ ::= ⊤ | {} | {ξ 1 , . . . , ξ n } .Here, ⊤ stands for "any set" and can be used when no requirement on actions isimposed. A set of action specifiers is satisfied by an action if the latter satisfiesat least one of the elements of the set. Action specifiers are a kind of templatesfor actions. They have the following shape:ξ ::= s : O(⃗F, s) | s : I(⃗F, s) | s : R(⃗F, s) | s : E(Q, s)where g is a locality. The action specifier loc 1 : O(GO, loc 2 ), is satisfied only bya process at loc 1 writing GO tuple in loc 2 .Path FormulasPath formulas basic rely on the CTL until operator Φ U Ψ. In order to be ableto refer also to actions executed along a path, a variant of the until operator isproposed. For this purpose, the until-operator is parameterized with two sets ofactions.

90 stoklaimA path satisfies Φ ∆U ΩΨ whenever eventually a state satisfying Ψ is reachedvia a Φ-path and, while evolving between Φ states, actions are performedsatisfying ∆ and then the process, performing an action satisfying Ω arrivesin a state satisfying Ψ. Finally, we add a time constraint t on path formulas.In addition to the requirements described just above, it is now imposed that aΨ-state should be reached within t time units. If t = ∞, this time constraint isnegligible. A path satisfies Φ ∆U

4.4 mosl: mobile stochastic logic 91states that, in the long run, the probability of finding the local resource free is atleast 0.2. In summary, state-formulas are built according to the grammar:Φ ::= tt∣ ℵ∣ ∣ ¬ Φ∣ ∣ Φ ∨ Φ∣ ∣ P⊲⊳p (ϕ) ∣ ∣ S⊲⊳p (Φ)4.4.2 MoSL Satisfaction RelationPaths play a central role in the formal definition of the semantics of MoSL. Theyare defined below:Definition 4.4.1 Let A = (§, ACT, ↦→) be an action-labeled CTMC. A path π of A isa sequences 0 (g 0 , t 0 ) s 1 (g 1 , t 1 ) . . .such that the following two conditions hold:• s j ∈ §, γ j ∈ ACT, t j ∈ R >0 and s j ↦→ g j , λs j+1 for some λ > 0, for all j 0;• π is minimal, namely it is infinite or there exists natural number l such that s lis absorbing (i.e. there are no s, g, and λ s.t. s l ↦→ g, λs).Five path operators which will be used in the sequel are defined in Table 18.They are len(π), giving the length of the path, as the number of transitions itcontains; st(π, j), giving the j th state in the path π; ac(π, j), giving the label ofthe j th transition in the path; dl(π, j), giving the actual delay of the j th transitionif it exists in the path; π(t), giving the state reached in the path after t time unitspassed. For any state s of an AMC A, we let Paths A (s) denote the set of allpaths s 0 (g 0 , t 0 )s 1 (g 1 , t 1 ) . . . over A with s 0 = s.Definition 4.4.2 A StoKlaim specification (B 0 , N 0 , ⃗D) satisfies a state-formula Φ,written (B 0 , N 0 , ⃗D) |= stoK Φ if and only if s 0 |= A Φ, where s 0 is the initial state ofA = AMC(B 0 , N 0 , ⃗D) and |= A is defined in Table 20.State formulasThe satisfaction relation for state-formulas exploits pattern-matching. For thispurpose, the definition of function match given in [74] must be extended in orderto cover addresses. There we use Θ to denote a substitution [d 1 /w 1 . . . d n /w n ],with w i ≠ w j for i ≠ j, which replaces w j by d j for 0 < j n. the symbol []denotes the empty substitution. The match is a partial function that returns thesubstitution built from a template and a tuple.

92 stoklaimFor path π = s 0 (g 0 , t 0 ) s 1 (g 1 , t 1 ) . . ., natural number j and t ∈ R 0 :{∞ if π is infinitelen(π) = defl otherwise, where s l is the absorbing state of πst(π, j) = def{ac(π, j) = def{s jundefinedg jundefinedif 0 j len(π)otherwiseif 0 j < len(π)otherwise⎧⎪ ⎨ t j if 0 j < len(π)dl(π, j) = def ∞ if j = len(π)⎪ ⎩undefinedotherwise⎧⎪ ⎨ st(π, len(π)) if t > ∑ len(π)−1j=0t jπ(t) = def st(π, m) otherwise, where⎪ ⎩m = min { j|t ∑ jk=0 t }kTable 18: Operators on paths

4.4 mosl: mobile stochastic logic 93π |= A Φ ∆U ∑ k−1j=0 dl(π, j)2) there exists Θ k−1 s.t. the following three conditions hold:2.1) st(π, k − 1) |= A Φ2.2) ac(π, k − 1), Θ k−1 |= A Ω2.3) st(π, k) |= A ΨΘ k−13) if k > 1 then there exist Θ 0 , . . . , Θ k−2 s.t.for all j, 0 j k − 2 the following two conditions hold:3.1) st(π, j) |= A Φ3.2) ac(π, j), Θ j |= A ∆π |= A Φ ∆U ∑ k−1j=0 dl(π, j)2) st(π, k) |= A Ψ3) there exist Θ 0 , . . . , Θ k−1 s.t.for all j, 0 j k − 1 the following two conditions hold:3.1) st(π, j) |= A Φ3.2) ac(π, j), Θ j |= A ∆Table 19: Satisfaction relation for path formulas

94 stoklaims |= A tts |= A ¬ Φs |= A Φ ∨ Ψs |= A S ⊲⊳p (Φ)s |= A P ⊲⊳p (ϕ)s |= A Q@i → Ψs |= A 〈⃗F〉@i → Ψs |= A Q( ⃗Q ′ ,⃗l,⃗e)@i ← Ψs |= A 〈⃗f〉@i ← Ψiff s |= Φ does not holdiff s |= A Φ or s |= A Ψiff lim t→∞ P{π ∈ Paths A (s)π(t) |= A Φ} ⊲⊳ piff P{π ∈ Paths A (s)|π |= A ϕ} ⊲⊳ piff there exist N, ρ, P, and Θ s.t. the following threeconditions hold:1) N s ≡ N | i : ρ P2) match(Q, P) = Θ3) (B 0 , N, ⃗D) |= SK ΨΘiff there exist N, ρ, ⃗f, and Θ s.t. the following threeconditions hold:1) N s ≡ N | i : ρ 〈⃗f〉2) match(⃗F, ⃗f) = Θ3) (B 0 , N, ⃗D) |= SK ΨΘiff there exist N, E, and ρ s.t. the following twoconditions hold:1) N s ≡ N | i : ρ E2) (B 0 , N s | i : ρ Q( ⃗Q ′ ,⃗l,⃗e), ⃗D) |= SK Ψiff there exist N, E, and ρ s.t. the following twoconditions hold:1) N s ≡ N | i : ρ E2) (B 0 , N s | i : ρ 〈⃗f〉, ⃗D) |= SK ΨTable 20: Satisfaction relation for state formulasg, Θ |= A ⊤g, Θ |= A {ξ 1 , . . . , ξ n } iff there exists j, 0 < j n, s.t. g, Θ |= A ξ jg, Θ |= A ξ iff match(ξ, g) = ΘTable 21: Satisfaction relation for action specifiers

4.5 statistical model checker 95Path formulasThe definition of the satisfaction relation for path formulas is presented inTable 19. Notice that in the definition of Φ ∆U

96 stoklaimwith rate p. The outcome of B i , denoted as b i , is 1 if the sample satisfies φ, 0otherwise. In our case, a sample is obtained by generating a sample path ρ i ,using discrete event simulation, and then testing if ρ i satisfies φ.The proposed solution for solving qualitative question are based on Hypothesistesting. Let p = Pr(s, φ) be the probability that state s satisfies φ, to test whetherp θ, we can determine if H : p θ against K : p < θ. The proposed solutiondoes not calculate an exact solution but estimate the probability to make anerror. In particular the algorithm bounds the probability α of calculating K whenH holds and the probability β of calculating K when H holds. The first kind oferror is known as Type-I error or false negative, while the second kind of erroris known as Type-II error or false positive. The parameters α and β determinethe strength of the acceptance sampling test.To control both errors probability (α, β), an indifference region (p 1 , p 0 ) has beenintroduced. In this case p 1 < θ < p 0 and we test H 0 : p p 0 against H 1 : p p 1instead of H against K. We require that the probability of calculating H 1 whenH 0 holds is at most α, and the probability of H 0 when H 1 holds is at most β.The thresholds p 0 and p 1 are generally defined in term of the single threshold θ,e.g., p 1 = θ − ɛ and p 0 = θ + ɛ, where ɛ is the tolerance. To test the requirementsabove (H 0 : p p 0 against H 1 : p p 1 ), we use sequential probability ratio test(SPRT) proposed in [152].The sample size for the SPRT is not fixed in advance, but after each observationit determines if the information collected so far is sufficient to decide for one ofthe two hypothesis (H 0 or H 1 ) or if another observation is needed. The approachis briefly described below.In SPRT, one has to choose two values A and B (A > B) that ensure that theprobability of a false positive (accepting H 0 when H 1 holds) is at most α, and atmost β of a false negative (accepting H 1 when H 0 holds). Let m be the numberof observations that have been made so far. The test is based on the followingquotient:p 1mp 0m=m∏ Pr(B i = b i | p = p 1 )Pr(B i = b i | p = p 0 ) = pd m1(1 − p 1 ) m−d mp d ,m0(1 − p 0 ) m−d mi=1where d m = ∑ mi=1 b i. The test accepts H 0 if p 1mp 0m A, and H 1 if p 1mp 0m B. TheSPRT algorithm computes p 1mp 0mfor successive values of m until either H 0 or H 1is satisfied. Computing appropriate A and B is a laborious procedure, in [152] itis shown that if A = (1−β)αand B = (1−α)βa new test is obtained, Let (α ′ , β ′ )be its strength, then α ′ − β ′ α + β, this means that either α ′ α or β ′ β. Inreal case studies both inequivalences often hold.The main advantage of statistical approach is that solutions can be rapidlycalculate but they are affected by some uncertainty and, reducing it, is computationallyexpensive. Moreover these technique only requires that the model

4.6 stoklaim-plugin 97generate "runs", i.e. sample execution traces derived accordingly to measurespace defined by the system. Notice that we have never dealt with the structureunderling models (CTMC, DTMC, MDP), but only simulation features areneeded. Thus, it can be applied to a larger class of systems than numericalmodel checking including, for example, infinite state systems. However statisticalmodel checking also has some drawback: the observations number growsrapidly when the answer has to be highly accurate or when test procedureconverges slowly to the desired thresholds.4.6 stoklaim-pluginStoKlaim plug-in supports the stochastic analysis of StoKlaim specificationsand can be used for executing interactively specifications, simulating stochasticbehaviors or model checking MoSL formulas. It provides textual specificationand few features for managing non-trivial projects.At start-up (Fig. 30), StoKlaim plug-in shows a desktop, a lateral bar, and amenu bar. The desktop contains editor windows for manipulating txt files thatdefine model specifications, the lateral bar shows all the file in the current projectand the menu bar allows to launch all the features provided by the plug-in.Figure 30: StoKlaim plugin main panelA StoKlaim plug-in project is composed of three different kind of files: ".net",".map" and ".sim. Files with extension ".net" contain models specifications(nets, agents, localities, . . . ). The agents interact each others by means of actionswhich permit adding, reading and removing tuples from the tuples space. Everyaction has a random duration governed by rate defining a negative exponentialdistribution. StoKlaim plug-in allows to not specify a value for each rate leavingit undefined within specification. All the variable rates will be specified within a

98 stoklaim".map" file. This can be useful during tuning phase, in which one needs to studysystem mutations: namely models with the same behavior but different speedsof execution. StoKlaim plug-in provides features for two different analysistechniques: simulation and model checking. During simulation phase, it monitorsthe tuples number varying with time. User can decide which kinds of tupleshave to be monitored, by setting the ".sim" file.StoKlaim plug-in does not exploit TAPAs embedded analysis tool nor exploitsalready developed libraries. For providing analysis features, it connects, via anetwork connection, to a SAM server which takes care of simulating stochasticbehaviors and model checking MoSL formulas. SAM server, after receiving allthe files needed, checks files syntax, performs the analysis requested and thensends back the result.After configuring the server, user can analyze a StoKlaim specification. First,the specification under analysis, the experiments and the mapping file associatedwith it (if any) must be uploaded to the server. If all the files pass the syntaxcheck, the user can perform a serie of simulations or properties verifications,and, at the end of the analysis, the result will be shown in graphical form in aStoKlaim window. Completed the analysis, user can save the data and use themoff-line.4.6.1 StoKlaim SpecificationA StoKlaim specification (see Listing 4.1 ) consists of four sections: localities,environments, agents and system. The first three sections respectively containsdeclaration of localities (both physical and logical), allocation environments andagents that will occur in the specified system. After this declarative sections,there is the section containing the initial configuration of the system. Commentsstart with symbol ’#’ and extend to the end of the line, moreover they can appearanywhere in the source code where whitespace is allowed.localities:...environments:...agents:...system:..end# Comment about localities# Comment about systemListing 4.1: Main sections✆The first section of a module (localities) is used for declaring logical andphysical localities used in the specification. Notice that, a name can be used onlyif it is has been correctly declared. Notice that identifier self can only be used

4.6 stoklaim-plugin 99as a logical localities. The code in Listing 4.2 is used for declaring 3 physicallocalities (l1, l2,l3) and three logical localities (self, next, pred).localities:physical l1;physical l2;physical l3;# Comment about localities# Physical locality declarationlogical self; # Logical locality declarationlogical next;logical pred;Listing 4.2: Localities declarations✆Each node is equipped with an allocation environment that maps logical localitiesto physical ones. The environments section lists the associations betweenphysical and logical localities previously declared. Notice that an environmentcannot be empty and can only map (declared) logical localities to (declared)physical localities. In the code shown in Listing 4.3 the allocation environmentsof physical localities (l1,l1 and l3) is presented. The allocation environment ofl i maps self to l i , next to l i+1 and pred to l i−1 (where + and − are intendedmodulo 3).environments:l1:[self->l1, next->l2, pred->l3];l2:[self->l2, next->l3, pred->l1];l3:[self->l3, next->l1, pred->l2];Listing 4.3: Environments declarations✆In StoKlaim plug-in three kind of values are available: booleans, integers andstrings. Basic boolean values are true and false, while operators on booleansare: and, or and not. Relation operators can be used for comparing integervalues: = (equal), < (less), (greater), => (greater or equal), !=(not equal). Integers are composed by standard operators: + (sum), - (difference),* (multiplication) and / (difference). Like in other programming languages,strings are delimited by ". StoKlaim plug-in does not provide operators forcombining strings.Values and expressions are composed to perform tuples. These are composedof a (non-empty) sequence of expressions separated by a comma ’,’. Templatesare tuples that can contain formal fields. These are represented by identifierspreceded by a ’?’. Moreover, it is possible to annotate templates with a guard.This is a boolean expression that permits selecting values according to somepredefined constraints. The template (3, ?x:!=4), matches against every tuplethat has 3 as the first element and an integer different from 4 in the secondelement.The third section (agents) is devoted to declare the agents that will occurin the considered system. Each agent is univocally identified by a name (an

100 stoklaimidentifier) and it can be parameterized with respect to a (possibly empty) list ofvalues separated by comma. Possible types are: int, for an integer; bool, for aboolean; loc, for a locality and string, for a string. An agent can also use localvariables. These have to be declared at the beginning of the body of the agent.The Listing 4.4 shows the code used for declaring an agent (anAgent) with twoparameters and two local variable. The parameters count and src are of integerand locality type respectively, while the variables name and check are of stringand boolean type respectively.let anAgent[int count, loc src] bestring name;bool check;...endListing 4.4: Agent declarations✆Finally the body of an agent contains the statements the agent has to performduring the execution. An agent consists of a sequence of statements separatedby a semicolon (;). Statements are: agent invocation, iteration, selection, nondeterministicchoice, block or actions. Moreover, specific statements for memoryhandling are also provided. Agents are invoked as functions. Hence, the agentanAgent can be invoked with the following code: anAgent(0, l1) where l1 hasto be declared localities section. Notice that, a process invocation MUST BEthe last statement in a block. Indeed, all the statements following an agentinvocation are never executed. So, for instance, in the following code, agentdeadAgent is never invoked:anAgent(0, l1);deadAgent();StoKlaim plug-in provides actions for inserting and withdrawing tuples fromlocated tuple spaces and for spawning agents for code mobility. Syntax of actionsis shown in Listing 4.5.✆out(tuple)@loc:rate;in(template)@loc:rate;read(template)@loc:rate;eval(process(parameters))@loc:rate;wait(rate);Listing 4.5: Actions syntax✆where loc is the locality in which tuple will be inserted and rate is theparameter of an exponentially distributed random variable used for describing theaction duration time. Intuitively, if the action has a rate λ, then its averageduration time is 1/λ time units and variance is 1/λ 2 . Notice that identifierscan be used as rates. In this case, the actual rate governing the considered

4.6 stoklaim-plugin 101random variable will be determined at analysis time. A rate mapping is a filecontaining a sequence of assignments that bind rates to names. Each mappinghas the following structure a_id -> a_value. Rate mapping are particularlyuseful when the same system is analyzed by considering different executionrates.Action out is used for inserting a tuple into a located tuple space. Indeed, thisaction takes as parameters the tuple to insert and the target locality. Notice that,if loc is a logical locality, the local allocation environment is used for resolvingthe logical name to a physical ones. At the same time, all the logical localitiespossibly occurring in tuple are resolved with the same allocation environment.Tuples can be retrieved from tuple spaces either by action in or by action read.the former removes tuples from tuple space, the latter leaves the read tupleavailable. However, both actions look for a tuple matching a given templateat a given locality, and both are blocking task. If an agent tries to retrieves anonexistent tuple, it will be blocked until a matching tuple will appear in thespecified tuples space. It is important to note that these actions can cause agentsdeadlock. Like for the out action, actual fields in the template are evaluated byconsidering the allocation environment where the action is executed.Agents can be spawned to be evaluated to a remote locality. This task isperformed by means of action eval. However, while in Klaim any processcan be spawned, for the sake of simplicity in StoKlaim plug-in only processinvocation can be evaluated remotely. Action wait is used to model internalsteps that requires time. This action takes as parameter a rate modeling theaverage execution time.StoKlaim plug-in also has conditional and iteration operators. Classical if-thenelseconstruct can be used to select different computations according to someboolean expression, while iteration is performed by means of a while-do-donestatement. Sometime is useful to perform some activities when an tuple is notavailable. For this reason, like in Linda, in StoKlaim plug-in predicative versionsof input and output actions are available. These actions, identified by inp andreadp work similarly to in and read, but they are not blocking. A true value isreturned if a tuple matching a given template is found, false if such a tuple doesnot exist. Notice that this kind of action can be used only either in a iteration orin a selection conditional statement.if (b_exp|pred_act) then...else...endifwhile (b_exp|pred_act) do.........done✆✆chcDifferent behaviors can be composed nondeterministically by using chc block

102 stoklaim+ beginend...+ beginendchc✆4.6.2 Analyzing a specificationTo analyze behavior of distributed systems, StoKlaim plug-in provides twomain tools: a simulator and a model checker. The simulator randomly generatespossible computations. At each step of the simulation the next state is determinedby using the Kinetic Monte Carlo Algorithms [156, 69]. A simulation continuesuntil in the considered computation either a time limit or a deadlock configurationis reached.Fixed a sampling time, each computation is described in term of the numberof resources (located tuple) available in the system during the computation.At the end of a simulation, the average amount of resources available in thesystem at specified time intervals is provided. To identify the values to collect ina simulation a sequence of elements (named experiments) of the form:label: tuple@locmust be provided. An experiments associate a label to a locate tuple (tuple@loc)where loc can be either a site or a wild card ( * ). In the former case, the numberof tuples in the considered localities are counted. In the latter, the tuples in allthe localities are summed. For instance what follows are two experiments thatcan be used for computing the number of tuple ["FOLLOWER"] and ["LEADER"]available in a net:follower: ["FOLLOWER"]@*leader: ["LEADER"]@*StoKlaim plug-in permits verifying whether a given specification satisfiesor not a MoSL formula. This feature allows to highlight the emergence ofcertain behaviors such as the presence of anomalies in the studied model, andto understand what is the relationship between known data and the trend ofcertain reactions. MoSL can be used not only for dependability checking butalso for what-if scenarios. Indeed, production and consumption operators allowto determine the network evolution when a tuple is added or removed fromthe tuple-space. This kind of formula can be checked on the network withoutmodifying the model, but just specifying the desired tuples in the formula. Themodel checker provides three different features:✆✆

4.7 leader election 1031. plot the path formula trend. The verification start and stop at a giveninstants of time with fixed sampling times. The results are then store in afile.2. calculate the probability of a path formula.3. check if a formula holds (yes or no answer).This algorithm is parametrized with respect to a given tolerance ε and errorprobability p. The algorithm guarantees that the difference between the computedvalues and the exact ones are greater than ε with a probability that is less thanp.4.7 leader electionIn this Section we use StoKlaim for specifying a system where n distributed sites(nodes) have to elect a leader (a uniquely designed process): we will considerthree well known leader election protocols [55, 133, 103]: All The Way, As far asit can and Asynchronous leader election. The first two protocols are modeled byrelying on agents and code mobility, while the third is modeled by relying onmessage passing.In all the considered algorithms, it is assumed that the nodes are alwaysarranged in a ring: in this particular network topology every node is connectedto two other nodes (called prev and next). This is a common assumption forleader election algorithms [133].In StoKlaim the system consists of n nodes each of which hosts the executionof an agent or a process. We assume these nodes are identified by sites (s 0 ,. . . ,s n−1 ). The index associated to a site identifies the position of the node in thering: the process located at s i precedes (follows) the one located at s i+1 mod n(s i−1 mod n ) in the ring. We also assume that the allocation environment ρ i ofsites s i , beside the standard mapping self ↦→ s i , maps logical locality next tos i+1 mod n and logical locality pred to s i−1 mod n . In the performance analysiswe will consider four ring sizes: 25, 50, 75 and 100. Notice that, for theseconfigurations, standard model checking techniques are note easily applicable.Indeed, if n is the number of nodes in the ring, the first two algorithms generatemodels with more than n! states while the models generated from the thirdalgorithm are composed of more than 2 n states.In the considered models we assume that local communications are performedwith rate 15.0 while remote communications have rate 1.0. In the analysis we willuse simulations and (statistical) model checking. Simulations will be performedby considering 300 iterations and will be used to determine how, in the average,

104 stoklaimprocess change their state. Statistical model checking will be used to computethe probability, when t varies from 0 to 600, of:tt ⊤ U

4.7 leader election 105Figure 31: AllTheWay simulation4.7.2 As far as it canThe algorithm considered in the previous section is not very efficient. Indeed,every agent keeps traveling even if its id is not the smaller. An improvement ofthe All the way algorithm is the As far as it can. In this algorithm an agent movesto the next node if and only if its id is smaller than the local identifier. An agenttravels along the ring “as far as it can”, until it stops in a site with a smaller (orequals) id. Only the agent with the smaller id is able to return to its starting site,all the others will be eventually stopped. After the survivor agent traveling allthe ring, it sets the starting node as leader and then creates the agent notify thatrevisits all the other nodes setting them as follower. The following is the agentused in the StoKlaim specification to visit the ring.agent[int id, int min]∆=(read("ID", ?lId)@self, local).if (id = lId) then(out("LEADER")@self, local).(eval(notify(id))@next, remote)else if (min < lId) then(eval(agent(id, min))@next, remote)notify[int id]∆=(read("ID", ?lId)@self, local).if (id! = lId) then(out("FOLLOWER")@self, local).(eval(notify(id))@next, remote)Simulation results, reported in Figure 32, shows that, differently from All theway, the leader is selected before followers.4.7.3 Controlled distanceThe algorithms presented in the previous sections use, in the worsts case, anO(n 2 ) messages. In AllTheWay there will be sent exactly n 2 messages in total,each carrying a counter and a value. In the worst case, also AsFarAsItCan still

106 stoklaimFigure 32: AsFarAsItCan simulationgenerates a number of messages quadratic in the number of nodes (O(n 2 )), howeverthe algorithm cost, on average, is only O(n log n) messages. In this sectionwe present an algorithm, named Controlled distance that guarantees O(n log n)exchanged messages: the idea is to increase the number of messages sent tobecame the leader and to give more control over messages to the processes.In both the previous algorithms, every process makes only one attempt tobecome leader (i.e. it send just one message) and, once the message is sent, theprocess can not control it anymore. The idea is to create an algorithm in whichprocesses make several attempts (called electoral stage) to become leader: at everynew stage, the number of sites still involved into leader election procedure ishalved.Controlled distance is divided into electoral stage by using three main ideas:1. Limited distance: every message can travel through a limited number ofsites.2. Return messages: if a message travels until its limit, it will return back to itsoriginator to get authorization for further travel.3. Check both sides: the entity will send a message in both directions; only ifthey both return, they will be allowed to travel a further distance.If a sites is defeated (i.e. it does not receive one of its messages back) in anelectoral stage, it only forwards messages arrives from the the other candidates.A synthetic description of the protocol will thus be as follows:1. in each electoral stage there are some candidates;2. each candidate sends a message in both directions carrying its own id (aswell as the stage number);3. a message travels until it encounters a smaller id or it reaches a certaindistance (whose value depends on the stage);

4.7 leader election 1074. if a message does not encounter a smaller id, it will return back to itsoriginator;5. a candidate that receives both of its own messages back survives this stageand starts the next one;with three meta rules:1. if a candidate receives its message from the opposite side it sent to, itbecomes the leader and notifies all the other entities of termination;2. if a candidate receives a message with a smaller id, it becomes defeated,regardless of the stage number;3. a defeated entity forwards the messages originating from the other entities;if the message is notification of termination, it will terminate.The agent shown below is used to simulate the Controlled Distance behavior.active[int id, int stage, int count] ∆ =+ (in("FORTH", ?idRec, ?stageRec, ?limitRec)@self, local).if (idRec < id) thenif (limitRec = 1) then (out("BACK", idRec, stageRec)@next, remote)else (out("FORTH", idRec, stageRec, limitRec − 1)@next, remote)else (out("LEADER")@self, local).(eval(notify(id))@next, remote)+ (in("BACK", idRec, stageRec)@self, locale).if (idRec = id) then (out("FORTH", id, stage + 1, 2 ∗ (stage + 1))@next, remote)else (out("BACK", ?idRec, ?stageRec)@next, remote)Simulation results, reported in Figure 33, shows that, at the beginning, theprobability to decide leader grows rapidly but then slows down, taking along time to reach one. This is probably due to the electoral stage behavior: earlyelectoral stage eliminate a large number of nodes, but then the number of defeatednodes gradually (logarithmically) decreases. In other words, this algorithm isefficient during the early stages but slow in terminating. This might suggesta new algorithm in which, at the beginning, the Controlled distance approachis used, and, when the number of nodes is decreased, the leader is elected byusing another algorithm among the survivors nodes.4.7.4 Asynchronous leader electionThe algorithms considered in the previous sections identify the leader as thenode with the minimum id. In this section we consider a randomized protocolthat is an adaptation of the asynchronous leader election protocol proposed in [103].

108 stoklaimFigure 33: ControlledDistance simulationProcesses in the system can be either active or inactive. Until a process becomesinactive, it performs the following steps:1. Chooses 0 or 1 each with a given probability, and sends the choice to thenext process.2. If the process chose 0 and the active process preceding it in the ring chose1 it becomes inactive and only continues to relay received messages.3. If it is still active, it sends a counter around the ring to check whether itis the only active process. In that case it becomes the leader, otherwiseanother round of the algorithm is repeated.The model for an active process is shown below. Notice that process testLeaderis the process used for verifying if the current node is a leader.active[int id] ∆ =+ (out(0)@next, remote).(in(?val)@self, local).if (val = 1) then (out("FOLLOWER")@self, local).inactive()else testLeader(id)+ (out(1)@next, remote).(in(?val)@self, local).testLeader(id)testLeader[int id] =∆(out("CHECK", id)@next, remote).(in("CHECK", ?c :)@self, local).if (c = id) then (out("LEADER")@self, local)else active(id)The simulation of considered system (Fig. 34) shows that, differently fromthe specifications considered in previous sections, a large number of nodesbecome inactive before the leader is selected. Unfortunately, the time needed todetermine the leader increases significantly.

4.7 leader election 109Figure 34: Asynchronous simulation4.7.5 Comparing AlgorithmsWe now use statistical model checker to compare the four considered algorithms.In particular we study how the probability to select a leader within t time unitsvaries in the four algorithms. In Figure 35 are reported the model checkingresults for a configuration with n = 75 nodes in the ring. The results respect theone obtained with the simulation.As far as it can elects leader before the others,Controlled Distance sometimes is better then All The Way and Asynchronous leaderelection the slowest.Notice that to compute the probability of the considered formulas, due to thesize of considered system, the use of numerical model checking is not practicable.On the contrary, statistical model checker allow us to compute an approximationof the requested probability.Figure 35: Comparison between the four algorithm

110 stoklaim

B I O K L A I M5In the last years many languages and calculi have been proposed as formal tools formodeling, simulating and analyzing biological systems. These languages and calculi,which are mainly based on CCS and CSP process algebras, render biological systemsas sets of agents that interact with each other via channels. In this chapter we aim atmodeling biological systems as Klaim networks. In the section we present BioKlaim,a variant of Klaim, and show how it can be used for specifying and reasoning aboutbiological systems.5.1 introductionIn recent years the process algebraic approach has been used for describingbiological systems. The idea is to represent macromolecules, the building blocksof biological systems, as process algebraic terms. Indeed, a macromolecule isa large complex molecule that has inner mutable states and external activities.Using this approach, a macromolecule is modeled as an automaton. Transitionamong states, which is typically driven by external interactions, are equippedwith rates identifying the transition duration time. Many languages and calculihave been proposed as formal tools for modeling, simulating and analyzingbiological systems [48, 53, 91, 126, 127, 128]. These languages and calculi aremainly based on CCS and CSP process algebras. In this section we aim at modelingbiological systems as Klaim networks. We present BioKlaim, an extensionof Klaim specifically thought for modeling biological systems. The proposedcalculus follows a molecules as tuples approach. In BioKlaim tuples are usedto model the molecules concentration while processes identifies the reactionsenabled in that particular part of the considered system. Moreover, BioKlaimlocalities will be used to model the spatial structure of biological systems. Thisstructure can be related to the presence of compartments [58, 60, 131, 151] or tothe distribution of the considered species over a physical area. The rest of thechapter is organized as follows. In Section 5.2, we will describe BioKlaim syntaxand operational semantics, in Section 5.3 we will introduce BioKlaim plug-inand its main features and in Section5.4 BioKlaim plug-in will be used to modeland analyze for biological systems.111

112 bioklaimN ::= 0 ∣ ∣ s : E N | N NetsE ::= P ∣ 〈 ⃗d〉 NodesP ::= nil ∣ ∣ ∣ ∣ (A, λ).E P + P P | P X ProcessesA ::= ∣{G} out(⃗d)@l ∣ {G} in(π)@ ⃗dl{G} read(π)@l ∣ {G} eval(P)@ ⃗dlActionsG ::= true ∣ ∣ ∣ B ⊲⊳ B !G G ∧ G GuardsB ::= 〈⃗d〉@l ∣ ∣ ∣ B bop B uop B d Operatorsπ ::= ⃗t ∣ ⃗t ⊗ π PatternsT ::= ⃗d ∣ ⃗d ⊗ T Tuplest ::= d ∣ ∣ ?x ?u Templatesd ::= l ∣ e ValuesTable 22: BioKlaim syntax5.2 bioklaimIn this chapter we present BioKlaim, an extension of Klaim specifically thoughtfor modeling biological systems. Like in Klaim, in BioKlaim systems are describedas a set of nodes each of which identifies a part of the described system.Following a molecules as tuples approach, tuples in the tuple space of a nodemodel the molecules concentration while processes identifies the reactions enabledin that particular part of the considered system. To model reactions, Klaimactions have been enriched in order to permit retrieving multiple tuples with asingle operation on a tuple space. Moreover every transition may be precededby a guard: the transition is enabled if and only if the guard is true.The BioKlaim syntax is shown in Table 22. Nets, Nodes and Processes are definedas in StoKlaim, while the other operators are created to take into account theBioKlaim specific characteristics. It is important to note that, differently fromStoKlaim, each action is preceded by a guard G and in and read can retrievepatterns instead of templates.The most elementary net is the null net, denoted 0. A net consisting of a singlenode with site s is denoted s : E where E is a node element. In general, nets consistof several nodes composed in parallel.Node elements (E, E 1 ,. . . ) are either processes executing at a node—processnodes in the sequel— data represented as a tuple 〈⃗v〉 that is stored at a node or

5.2 bioklaim 113the parallel composition of node elements (E 1 |E 2 ). We let Nets denote the set ofall BioKlaim nets.Processes are built up from the terminated process nil, a set of randomlydelayed actions, and standard process algebraic constructors such as prefix,choice, parallel composition and process instantiation.The process (A, λ).P executes action A with a random duration that is distributedexponentially with rate λ ∈ R >0 . Notice that the execution of an actioncan activate new elements in the node where the process is running.As you can see from the syntax, a guard may be associated to every action. Aguard is a boolean expression that enables or disables the related action. If anaction has not a guard, this will always be considered as enabled. The symbol⊲⊳ corresponds to a comparison operators {, , }, v ∈ R 0 , while bopand uop are binary and unary operators with values in R, such as: bop =+, −, ∗, /, . . . and uop = sin, cos, ln, log, . . ..Processes interact with each other by means of messages, named tuples, insertedinto located tuple spaces. A tuple is a sequence of actual fields, i.e. values.Tuples are retrieved from tuple spaces by using Templates and Pattern Matching.A Template field can be a tuple field (a datum) or ⋆.The pattern-matching predicate match is straightforward: a template matchesagainst a tuple if both have the same number of fields and the correspondingfields do match; two values match only if they are identical, while ⋆ matchesany value. Templates can be composed with operator ⊗ to select multiple tuples.Predicate match is then extended in order to take patterns into account. Apattern ⃗t ⊗ π matches against sequence ⃗v ⊗ T if and only if ⃗t matches against⃗v and π matches against T. Notice that, differently from Klaim, in BioKlaimmore tuples can be retrieved in a single input action. This permits implementingsophisticated synchronization patterns. From a biological point of view, thisallow to model different kind of reactions that can be influenced by many localparameters like for instance the temperature or electric charge (see Section 5.4).A process can write tuple ⃗v in repository l by the action out(⃗v)@l. With aninput action in(π)@l a process can withdraw a set of tuples matching pattern πfrom l. Processes can be written to/withdrawn from a repository as well.Action read(π)@l is similar to in(π)@l except that retrieved tuples are notdeleted from the tuple spaces at l. The action eval(P)@l spawns process P atsite l. A locality variable u can be used in place of l in all above actions. For thesake of simplicity, we do not consider the action for creating new nodes.Operational semantics specifications is defined by means of Rate TransitionSystems (RTS), defined in 4.2.3. Behavior of BioKlaim specifications is describedby means R bk = (Spec, Λ, ↦→). Where Spec is the set of BioKlaim specifications,while Λ is the set of transition labels γ defined as in StoKlaim.

114 bioklaimThe transition relation ↦→ is defined by means of the relation −→ FN as follows:αN −−→ FN PN ↦−→ α PThis relation, formally defined in Tables 23 and 24, is parameterized to thefunction F N used to evaluate the guards in processes. This function is definedinductively on the networks syntax as follows:F 0 (〈⃗v〉@s) = 0F 〈⃗v〉@s (〈⃗v〉@s) = 1F N1 |N 2(〈⃗v〉@s) = F N1 (〈⃗v〉@s) + F N2 (〈⃗v〉@s)Given a network N, the function is useful to assess satisfiability of a guard,which is defined by the rules of grammar defined in the previous section asfollows:F N |= trueF N |= B 1 ⊲⊳ B 2 ⇐⇒ eval(B 1 ) FN ⊲⊳ eval(B 2 ) FNF N |=!G ⇐⇒ F N ̸|= GF N |= G 1 ∧ G 2 ⇐⇒ F N |= G 1 ∧ F N |= G 2where eval(B i ) FN corresponds to the evaluation of the operator B i in the networkN. Transition −→ is formally defined by the rules in Tables 23 and 24.These rules permit deriving with a single proof all the configurations which arereachable from a net with a given transition label.5.3 bioklaim plug-inThis plugin provides an environment for interactive execution of models specifiedin a specific file. The rate of the actions present in these model can bespecified as variable and their values can be specified separately in another file.Having the ability to easily change the values associates to rates, permitcreating structured experiments that aims at searching specific values for ratesof chemical reactions. A BioKlaim specification has the structure shown inListing 5.1.biolocalities:...environments:...messages;...agents:# Comment about localities

5.3 bioklaim plug-in 115(Out)E(s 1 )(l) = s 2s 1 : (out(⃗d)@l, λ).E s 1:o(⃗d)@s 2−−−−−−−−→ [s1 : E ‖ s 2 : 〈⃗d〉 ↦→ λ](Eval)E(s 1 )(l) = s 2s 1 : (eval(Q)@l, λ).P s 1:e(Q)@s 2−−−−−−−−→ [s1 : P ‖ s 2 : Q ↦→ λ](P-In)E(s 1 )(l) = s 2 ∧ match(π, T)s 1 : (in(π)@l, λ).P s 1⊲T @s−−−−−−−→2[s1 : P ↦→ λ](P-Read)E(s 1 )(l) = s 2 ∧ match(π, T)s 1 : (read(T)@l, λ).P s 1◮T @s−−−−−−−→2[s1 : P ↦→ λ](T-In)s 2 : 〈⃗v〉match(T, ⃗d)s 1 ⊳⃗v@s 2−−−−−−−→ [0 ↦→ 1](T-Read)s 2 : 〈⃗v〉s 1 ◭⃗v@s 2−−−−−−−→ [s2 : 〈v〉 ↦→ 1](T-In2)sN1 ⊳⃗v@s 21 −−−−−−−→ P1 sN1 ⊳T@s 21 −−−−−−−→ P2 sN1 ⊳⃗v⊗T @s 21 −−−−−−−−−→ P3sN1 ⊳⃗v@s 22 −−−−−−−→ Q1 sN1 ⊳T @s 22 −−−−−−−→ Q2 sN1 ⊳⃗v⊗T@s 22 −−−−−−−−−→ Q3sN 1 ‖ N1 ⊳⃗v⊗T @s 22 −−−−−−−−−→ P 1 ‖ Q 2 + P 2 ‖ Q 1 + P 3 ‖ N 2 + N 1 ‖ Q 3(T-Read2)sN1 ⊳⃗v@s 21 −−−−−−−→ P1 sN1 ⊳T@s 21 −−−−−−−→ P2 sN1 ⊳⃗v⊗T @s 21 −−−−−−−−−→ P3sN1 ⊳⃗v@s 22 −−−−−−−→ Q1 sN1 ⊳T @s 22 −−−−−−−→ Q2 sN1 ⊳⃗v⊗T@s 22 −−−−−−−−−→ Q3sN 1 ‖ N1 ⊳⃗v⊗T @s 22 −−−−−−−−−→ P 1 ‖ Q 2 + P 2 ‖ Q 1 + P 3 ‖ N 2 + N 1 ‖ Q 3(T-Read2)l : P−−→ γP ∧ l : Q −−→ γQl : P + Qγ−−→ P + Q(P-Par)l : E 1 ‖ l : E 2l : E 1 |E 2γ−−→ Pγ−−→ P(P-Par)N 1γγ−−→ P ∧ N2 −−→ Q ∧ γ ∉ {s1 : i(T)@s 2 , s 1 : r(T)@s 2 , s 1 ⊳ ⃗v ⊗ T@s 2 , s 1 ◭ ⃗v ⊗ T@s 2 }N 1 ‖ N 2γ−−→ P ‖ N2 + N 1 ‖ QTable 23: BioKlaim Operational Semantics (Part 1)

116 bioklaims 1 :i(T)@s 2N 1 −−−−−−−−→ Ps sN1 ⊲T @s 21 −−−−−−−→ Pi sN1 ⊳⃗d@s 21 −−−−−−−→ Po(In)s 1 :i(T )@s 2N 2 −−−−−−−−→ Qs sN1 ⊲T @s 22 −−−−−−−→ Qi sN1 ⊳⃗d@s 22 −−−−−−−→ Qos 1 :i(T )@s 2N 1 ‖ N 2 −−−−−−−−→ P s ‖ N 2 + N 1 ‖ Q s + P i ‖ Q o + P o ‖ Q is 1 :r(T )@s 2N 1 −−−−−−−−→ Ps sN1 ◮T @s 21 −−−−−−−→ Pi sN1 ◭T@s 21 −−−−−−−→ Po(Read)s 1 :r(T )@s 2N 2 −−−−−−−−→ Qs sN1 ◮T @s 22 −−−−−−−→ Qi sN1 ◭T @s 22 −−−−−−−→ Qos 1 :r(T)@s 2N 1 ‖ N 2 −−−−−−−−→ P s ‖ N 2 + N 1 ‖ Q s + P i |Q o + P o |Q i(Rec)X ∆ = P ∈ ∆ ∧ l : Pl : Xγ−−→ Pγ−−→ P(F-0) 0 γ−−→ ∅(F-Nil)s 1 : nilγ−−→ ∅(F-Out)γ ≠ s 1 : o(⃗v)@E(s 1 )(l)s 1 : (out(⃗v)@l, λ).Pγ−−→ ∅(F-Eval)γ ≠ s 1 : e(Q)@E(s 1 )(l)s 1 : (eval(Q)@l, λ).Pγ−−→ ∅(F-In)γ ≠ s 1 ⊲ T@s 1 ∧ ¬match(π, T)s 1 : (in(π)@s 2 , λ).Pγ−−→ ∅(F-Read)γ ≠ s 1 ◮ T@s 1 ∧ ¬match(π, T)s 1 : (read(π)@s 2 , λ).Pγ−−→ ∅(F-Tuple)γ ≠ s 1 ⊳ T@s 2 ∧ s 1 ◭ T@s 2s 2 : 〈⃗d〉γ−−→ ∅Table 24: BioKlaim Operational Semantics (Part 2)

5.3 bioklaim plug-in 117...system:..end# Comment about systemListing 5.1: Main sections✆1. localities: physical and logical localities used in the system,2. environments: allocation environments,3. messages: tuples used in the system,4. agents: agents declaration,5. system: network definition with its initial configuration.The first section of a specification is used for the declaration of physical andlogical localities used in the system.In BioKlaim each node is provided with an allocation environment thatassociates physical locality to each logical locality. An environment can not beempty and can be used only declared logical locality associated with physicallocality already declared.The agents that appear in the system are declared in the fourth part of aspecification. Each agent is uniquely identified by a name and its body iscomposed of a or more processes. Another important aspect in the specificationis the key word bio, which means that the rates of the actions in the system willbe proportional to the number of tuples that match the template. This is a keycharacteristic for modeling chemical reactions.A reaction is a process that transforms a set of substances to another. Reactionsare typically described be means of chemical equations that identify thesubstances that are mixed (reactants) and the result of the transformation (products).Reactants and products are separated by GGA usually read as "yields".Although the biological reaction could be considerably complex, they can bemodeled as a single step that is characterized by an apparent rate k. The rate of areaction is annotated over symbol GGA. For instance, what follows is a chemicalequation indicating that elements A and B can be transformed in C and D, thistransformation is performed with rate k:A + BkGGGGA C + DIn BioKlaim we use a molecules as tuples approach. Indeed, tuples are usedto model the molecules in a system. A reaction is modeled as a process thatretrieves tuples corresponding to reactants while emitting the ones associated

118 bioklaimto products. This operation is performed at the reaction rate. For instance, theBioKlaim process associated to the reaction above is:P ∆ = (in(A ⊗ B)@self, k).〈C〉|〈D〉|PNotice that, since in BioKlaim the rate of an in action is proportional to thenumber of tuples matching the specified templates, action in(A ⊗ B)@self isperformed at rate K · |A| · |B|, where |A| (resp. |B|) denotes the number of tuplesA (resp. B) in the the local tuple space. This formula corresponds to the law ofmass action, used for determining the rate of a generic chemical reaction.5.4 biological modelsSpecification and verification of BioKlaim models can be performed by usingStoKlaim plug-in, indeed BioKlaim was thought as a StoKlaim dialect. When creatinga new StoKlaim plug-in project, users are asked which language (StoKlaimor BioKlaim) they want to use, it is for the SAM server to identify the dialectand use appropriate methods. In this section we will show how BioKlaim canbe used for specifying biological systems.To validate the proposed approach we consider four examples:1. a variant of Groupies and Celebrities as proposed in [57],2. a spatial model for Intracellular Enzymatic Reactions as modeled in [92] andin [48]),3. Microglia cells: mutated and non mutated models for microglia cells asdescribed in [80, 145, 90],4. Excitable cells: models for single excitable cell and for tissues of excitablecells. as proposed in [41].5.4.1 Groupies and CelebritiesIn this first example, two different kind of molecules will be investigated:Groupies and Celebrities. Both of them are two-states system, they can be in Aor B state and, when they "meet" another molecule they could change state.Moreover, the molecules move in a two-dimensional space interacting only withthe closest molecules.The Celebrities are odd and so they want to be different: if one of them meetsanother molecule in its own state, it changes. Notice that when two celebritiesinteract, one changes state but the other holds steady. If there are two celebritiesin state A, one moves to state B and the other remains in state A. If there aretwo celebrities in state B, only one moves to A. However, if there are one in stateA and one in state B there is not any interaction, and both remains in their state.

5.4 biological models 119On the contrary, the Groupies are conformist: if two groupies in different states,meet each others, one of them change its state. As for celebrities, when twogroupies interact only one changes its state: if a groupie in state A and a groupiein state B interact there are two possible cases: both move to A state or bothmove to B state. When all the groupies in a system are in the same state they cannot interact and the system is in deadlock. Notice that neither a single groupienor celebrity can change state by itself, but it has to interact with another one.In [57] stochastic automata are used for modeling the Groupies and Celebritiesscenario. Two different automata are defined: one for groupies and one forcelebrities. Therefore a simulation consist of a population of automata and it isinvestigated the system evolution. That approach allows to describe at the sametime the model (static view) and its behavior (dynamic view). Because of thestochastic automata can not be used for describing molecules position, all thereaction can occur only in the same location.In BioKlaim celebrities are modeled by means of tuples 〈A, C〉 and 〈B, C〉. Theformer identifies a celebrity in state A, the latter a celebrity in state B. Similarly,groupies are modeled by means of tuples 〈A, G〉 and 〈B, G〉. The net is composedof 9 nodes arranged in a square grid (3x3) and every node is linked to itsneighbors: the boundary nodes are linked to either 2 or 3 nodes (corner or sidenodes respectively), while the central node is linked to its 4 neighbors. Thislinked structure is modeled using four logical names defined for every nodes: nfor north, e for east, s for south and w for west. By using the logical names it ispossible define many others geometric structures both 2D (pipe, rectangle, etc)and 3D (cubes, parallelepiped, torus, etc).Celebrities and groupies reactions are completely described by the followingprocesses:rC = ∆ (in(A, C ⊗ A, C)@self, λ).〈B, C〉|〈A, C〉|rC+ (in(A, C ⊗ A, G)@self, λ).〈B, C〉|〈A, G〉|rC+ (in(B, C ⊗ B, C)@self, λ).〈A, C〉|〈B, C〉|rC+ (in(B, C ⊗ B, G)@self, λ).〈A, C〉|〈B, G〉|rCrG = ∆ (in(A, G ⊗ B, C)@self, λ).〈B, G〉|〈B, C〉|rG+ (in(A, G ⊗ B, G)@self, λ).〈B, G〉|〈B, G〉|rG+ (in(B, G ⊗ A, C)@self, λ).〈A, G〉|〈A, C〉|rG+ (in(B, G ⊗ A, G)@self, λ).〈A, G〉|〈A, G〉|rG

120 bioklaimwhile the Celebrities movements are described by the following process (theGroupies movements can be described by a very similar process):Cm ∆ = (in(A, C)@ln, λ).〈A, C〉|Cm + (in(A, C)@le, λ).〈A, C〉|Cm+ (in(A, C)@ls, λ).〈A, C〉|Cm + (in(A, C)@lw, λ).〈A, C〉|Cm+ (in(B, C)@ln, λ).〈B, C〉|Cm + (in(B, C)@le, λ).〈B, C〉|Cm+ (in(B, C)@ls, λ).〈B, C〉|Cm + (in(B, C)@lw, λ).〈B, C〉|CmIn the rest of the section, four different simulations will be presented: thefirst one with only celebrities, the second one only groupies, the third one withmixed populations and the last one with a different kind of groupies.celebrities. In Celebrities simulation, the system is composed of 9 nodesarranged in a square grid; in every node there are 11 A tuples, 11 B tuples, aCelebrity and a Cm process.Figure 36: Celebrities in all the grid (left) and in the central node (right)On the left-hand side of Figure 36, it is shown the overall behavior of thesystem: the red and green lines (colors on-line) indicate the number of A and Bcelebrities in all the system, while the others lines show the number of celebritiesin every single nodes. The lines at the bottom of the graph can not be used for adetailed analysis but they show that all the nodes have a similar behavior: inevery single node, the number of A and B tuples is always greater than 0 andlesser than 20.The first thing to notice is the overall system stability: the total number of Aand B tuples fluctuate round about 100. This fact can be intuitively explained asfollows.• Celebrities want to be different: A would like to be B, and B would like tobe A.

5.4 biological models 121• The changing rate is multiplicative in the number of similar tuples: if|A|>|B| the changing from A to B is faster then from B to A; whereas if|B|>|A| the changing from B to A is faster then from A to B.Therefore the greater is the difference between |A| and |B|, the greater thechanging speed is. Moreover the system can not be in deadlock and tuples keepchanging state. It is important to note that different simulations give similaroutcomes: the number of A and B oscillate round about 100.On the right-hand side of Figure 36, it is shown the number of A and Bcelebrities in the central node of the grid. It is important to note that two linesare not symmetric, in fact the number of tuples can change either by theirinteraction in the node or by their migration from and to others nodes.groupies. In Groupies simulation, the system is composed of 9 nodes arrangedin a square grid; in every node there are 11 A tuples, 11 B tuples, aGroupies and a Gm process (the process for moving groupies).Figure 37: Groupies results: in all the grid (left), and in the central node (right)On the left-hand side of Figure 37, the red and green lines indicates the totalnumber of A and B tuples respectively, while the others lines show the numberof groupies in every single nodes.The overall system behavior evolves through a bounded random walk, andthe outcome remains uncertain until the end of the simulation. Because ofthe groupies are conformist, they will be of the same type: all A or all B.Eventually, a type could die out and then the system will not change anymore(it is in deadlock). Differently from celebrities, in this case different runs of thesimulations can give two very different outcomes: all tuples are A type or alltuples are B type. This kind of system is called bistable. In this case the, whenthe total number of A tuples becomes 0 (at time 6s), half of lines at the bottomof the graph disappear because the A type die out. On the right-hand side ofFigure 37, it is shows the number of tuples in the central node of the grid: in this

122 bioklaimcase the number of A tuples becomes 0 several times before die out permanently.The increase of the extinct tuples is due to migration from others nodes.mixed population. In [57], it is take into account another simulation withmixed populations: a groupies group with just one celebrity. Because of theirnature, all groupies will try to became of the same type. When this will be done,the celebrity will change its state breaking the deadlock. Consequently, whenthe groupie meets the (different) celebrity, it changes in order to became as wellthe celebrity. In this simulation there are both Groupie and Celebrity processes,100 A groupies, 100 B groupies and only one A celebrity placed at the centralnode of the grid.Figure 38: Mixed population results: in all the grid (left), and in the central node (right)As shown in Figure 38 the total number of A or B tuples can be zero but, inthis case, the Celebrity change a tuple state avoiding deadlocks. This particularsimulation shows how a microscopic change can produce macroscopic effectstransforming a system that always deadlocks to a system that never deadlocks.It is sufficient to add a celebrity to a groupies group to completely modify thesystem behavior.slow groupies. Now it will described a new type of groupies that has asort of resistance to changes. It has to meet more than one different groupiesto change its state, but these meetings can be not simultaneously; moreoveronce started, the state transition can not be interrupt. For these reasons this newkind of molecule is called Slow Groupies (Hysteric groupies in [57]). In the nexttwo simulations, a groupie has to meet two (first simulation) or three (secondsimulation) different groupies to change its state.For avoiding deadlocks two new agents is needed: A-DopingCelebrity andB-DopingCelebrity. Their aim is to avoiding the extinction of one kind of groupie;to do so they can change the state of just one groupie.

5.4 biological models 123r2G ∆ = (in(A, G ⊗ B, C)@self, λ).(read(B, ⋆)@self, λ).〈B, G〉|〈B, C〉|rAC+ (in(A, G ⊗ B, G)@self, λ).(read(B, ⋆)@self, λ).〈B, G〉|〈B, G〉|rAC+ (in(B, G ⊗ A, C)@self, λ).(read(A, ⋆)@self, λ).〈A, G〉|〈A, C〉|rAC+ (in(B, G ⊗ A, G)@self, λ).(read(A, ⋆)@self, λ).〈A, G〉|〈A, G〉|rACr3G ∆ = (in(A, G ⊗ B, C)@self, λ).(read(B, ⋆)@self, λ).(read(B, ⋆)@self, λ).〈B, G〉|〈B, C〉|rAC+ (in(A, G ⊗ B, G)@self, λ).(read(B, ⋆)@self, λ).(read(B, ⋆)@self, λ).〈B, G〉|〈B, G〉|rAC+ (in(B, G ⊗ A, C)@self, λ).(read(A, ⋆)@self, λ).(read(A, ⋆)@self, λ).〈A, G〉|〈A, C〉|rAC+ (in(B, G ⊗ A, G)@self, λ).(read(A, ⋆)@self, λ).(read(A, ⋆)@self, λ).〈A, G〉|〈A, G〉|rACIn this simulation there are Groupie, A-DopingCelebrity and B-DopingCelebrityagents, 100 A groupies, 100 B groupies.Figure 39: Slow groupies (2G left, and 3G right) overall behaviorAs it is shown in in Figure 39, the groupies slowdown induces an unexpectedchange in system behavior: the slower is a groupie, the greater the systemregularity is. In fact 2Groupie simulation is irregular but not completely random,whereas the 3Groupie simulation gives (almost) regular oscillation. Notice thatthese two simulations depends strongly on doping agents: without them thesystem could be in deadlock as soon as a groupie type dies out.5.4.2 Intracellular Enzymatic ReactionsMost reactions in biological systems do not occur at any perceptible rate inthe absence of an enzyme to catalyze them, even when thermodynamicallyfavored. This behavior is approximately described by Michaelis-Menten Kineticsone of the most important chemical reaction mechanism in biochemistry. Using

124 bioklaimthe usual biochemical symbols for substrate (S), enzyme (E), product (P), andenzyme-substrate complex (ES), this mechanism is written as:E + Sk1GGGGGBFGGGGGk-1ESk2GGGA E + PGenerally, the enzymatic reactions are modeled in well-mixed systems withoutany spatial notions. However there exist more structured systems in which thespatial constraints affect the enzymatic reactions: for instance the presence ofmembranes may influence the overall behavior of the system by reducing thediffusion of the particles and hence affecting their interactions rate. In this casestudy, following the same approach proposed in [48] and [92], we will considera system where enzymes are localized to regions of a semi-porous membraneand the substrate particles are also all placed on one side of the membrane.Figure 40 shows the initial configuration of the system: the red area representsthe substrate and the blue area the enzymes.The substrate, initially on the left side, goes through the membrane to theother side. After a complex interaction with the enzymes, substrates can beconverted into products. The latter can go through the cell membrane withoutany change.Figure 40: Initial conditionsThe Michaelis-Menten Kinetics can be modeled with the following threeprocesses:K1K-1K2∆= (in(E ⊗ S)@self, k 1 ).〈ES〉|K1∆= (in(ES)@self, k −1 ).〈E〉|〈S〉|K-1∆= (in(ES)@self, k 2 ).〈E〉|〈P〉|K2These processes are located at the nodes corresponding to the cells containingenzymes. After defining the processes, it is possible creating the net withthe right quantity of reactants. The net is composed of 100 nodes arrangedas a (10x10) grid: in every nodes in the left-hand side there are 25 substratetuples (1000 tuples in all) while 500 enzymes tuples are distributed among the

5.4 biological models 125two enzyme locations (Fig. 40 blue square). Like in the case of Groupies andCelebrities, movement of substrates and products is modeled via processes thatcontinuously moves elements from neighbor cells to the local one.Figure 41 shows the evolution of substrate (above) and product (below) atthree different instants of time (t = 0s, t = 5s, and t = 10s). At the beginning thesubstrate is all on the left side of the grid, then it starts to migrate to the right side.Because of the enzymatic reactions, the overall S concentration decreases overtime while the P concentration increases. The product is created in the centrallocations and then it spreads all over the grid because there is not constraint onthe membrane.Figure 41: Substrate (above) and product (below) diffusion at time = 0s, 5s, 10sFigure 42 shows the differences between the structured system described inthis section (continuous lines) and a well-mixed system (dotted lines). Bothsimulations have the same parameters (number of particles and reaction rates)but the well-mixed system is much more faster than the structured one. Indeedthe membrane, the constraints on the enzymes distribution and the movingparticles slow down the overall reaction speed. It is easy to see that our results(Fig. 42) fit with those in [48]. This fact support the correctness of the modelsand effectiveness of the tool.

126 bioklaimFigure 42: Michaelis-Menten results5.4.3 MicrogliaBesides neurons, glial cells (sometimes called neuroglia or simply glia) constitutethe majority of brain cells, they support nourish and protect neurons ensuringthe isolation and protection of neural tissues in case of injury. Glial cells reproductionoccurs very frequently for mitosis, in contrast to neurons for which thephenomenon occurs rarely. Within the brain, microglia cells account for 20%of total glial cells population. They are distributed in large non-overlappingregions in the spinal cord and brain. This type of cell is constantly trying to finddamaged neurons, plaques and infectious agents, in the central nervous system.The brain and spinal cord are considered immune to infection because theyare separated from the rest of the body from endothelial cells. In the eventthat an infectious agent breakdown of the endothelial barrier, microglia cellssuddenly react to decrease inflammation and destroy the infection before neuraltissue is significantly damaged. Because of the antibodies inability to cross theblood-brain barrier (BBB), the microglia cells must be able to detect foreignbodies and neutralize them.In this section, it will be presented, as a BioKlaim model, a study of the CB 2receptor in microglia cells, allowing research and analysis on specific subjects:• show the behavior of some microglia characteristics, analyzing some parametersof the system;• study how a drug might affect a mutated system, so that known thecharacteristics of the drug, we can quantify the best concentration toovercome the dysfunction;• enable the research to be more efficient with the help of simulations thatare the premise to (expensive) in vivo and in vitro experiments.The CB 2 activation has not behavioral effects in animals. However, the roleof this receptor may have potential purposes in therapeutic treatment of neu-

5.4 biological models 127rodegenerative diseases (eg Alzheimer’s disease), treatment of depression anddrugs addiction and also for the treatment of pain resistant to conventionaltreatments, such as neuropathic pain, caused by dysfunction or damage to thenervous system.The Micoglia CellsA receptor is a protein molecule, embedded in either the plasma membrane or thecytoplasm of a cell, to which one or more specific kinds of signaling moleculesmay attach. A molecule that binds to a receptor is called ligand and may be amolecule, an hormone, a drug or a toxin. Each kind of receptor can bind onlywith some ligands. A cell usually has several receptors, of many different types.When binding takes place, the receptor undergoes a conformational change(a change in the 3D protein shape) without affecting the aminoacid sequencecomposing it and, after a binding, an intracellular response starts. However,some ligands merely block receptors without inducing any response. Theseligands are called antagonists. There exist a classification for ligands [142]:1. Full agonist: agent that elicits the maximal biological response2. Partial agonist: agent that elicits a biological response; however, the maximumresponse obtained is less than that of full agonist.3. Antagonist: agent that binds to the receptor but does not elicit a response.Note that an antagonist can block an agonist from binding to the receptor,as with an enzyme inhibitor.4. Inverse agonist: many receptors, have basal activity (i.e. activity in theabsence of any agonist). In these cases, a compound binding these receptorsand decreasing basal activity is called inverse agonist. Note that a trueantagonist in these systems will bind to the receptor and not change thebasal activity.Endocannabinoid SystemEndocannabinoids are a class of molecules that can bind to specific receptors. Thefirst endocannabinoid to be discovered was, in 1992, anandamide (AEA), whichappears to be a partial agonist. Later it was discovered 2-Arachidonoylglycerol(2 − AG), full agonist, and only recently (within the last 10 years) were identifiedother cannabinoids, their study is still an open topic for biological research.2 − AG and AEA are primarily generated within neural cells: they are notstored but produced on request and the endocannabinoid system. The purposeof this system if to protect the body from damage caused by various pathologicalconditions and can exert an antioxidant, hypotensive, immunosuppressive andanti-inflammatory effect. Moreover endocannabinoid has a role in movement

128 bioklaimcontrol and perception, in altering the learning processes and memory and inthe regulation of emotional states.After the endocannabinoids have been synthesized, they are immediatelyreleased from the cell. Thus the cannabinoids receptors of neighboring cells havethe opportunity to interact with the ligands.The principal enzyme for AEA degradation is the fatty acid amide hydrolase(FAAH), while MAGL (Mono Acyl Glycerol Lipase) is the enzyme for 2 − AG. AEAand 2 − AG are metabolized to arachidonic acid (AA). Then, the cyclooxygenase(COX 2 ) enzymes catalyze the conversion of (AA) to prostaglandins (PGE).The cannabinoid receptors are a class of receptors activated by three groupsligands: the endocannabinoids (produced by the body of mammals), the cannabinoidsfrom plants (such as THC produced by the plant cannabis) and syntheticcannabinoids. To date, two subtypes cannabinoid receptors have been discovered:the CB 1 and CB 2 . The former is essentially located in the brain (central nervoussystem, CNS), but also in peripheral tissues, and the latter is found only in theimmune system and in microglia cells.The stimulation of CB 2 is primarily responsible for anti-inflammatory andimmunomodulatory action of cannabinoids and was understood the importanceof this receptor plays in the functioning of the immune system in embryonicdevelopment, osteoporosis, apoptosis (cell death) and cell chemotaxis. Thestudy of CB 2 allows the research to fight a series of diseases, such as: cancer,osteoporosis and depression.The CB 2 receptor is present in microglial cells and allows the cells products tomigrate where there is need to combat neuroinflammation. After thier activation,Microglia cells increase the number of receptors in its membrane and they alsoproduce a series of substrates (such as AEA and 2 − AG) that allow cells to doits work. Thus they can eliminate pathogens agents and infected tissues by usingsome cells called Natural Killers Cells (NK). NK act by activating apoptosis cell towhich they bind.In the model, 2 − AG (total agonist) binds cannabinoid receptors CB 2 andactivates the production of interleukins which help in the inflammatory response.Interleukins are proteins that mediates a signal: in this case, apoptosis. The AEAinstead inhibits interleukins production and then slows down the inflammatoryresponse.The Microglia ModelsIn the following is presented and discussed several "in silicio" experiments, conceivedto display and highlight some properties concerning activation, and theirpossible intervention to fight a neuroinflammation. In addition to interactionwith the receptor, was also structured the process of disposal (by ) , in order tohave a vision of the entire endocannabinoid system.

5.4 biological models 129It is possible to identify two starting models: one that describes the microglialcells without genetic alterations (called also "wild type") and a second one wherethere is a mutation which leads a more high constant decoupling between theCB2 and , making the link between these two proteins less likely. In this secondscenario is considered the presence of a drug that acts as a full agonist for theCB2 (such as 2-AG), to compensate for this genetic mutation. Everyone has somekind of genetic mutation, more or less marked, which differs from another, thenthe "wild type" model can be considered as a theoretical approach.In this context, it is possible to study the efficiency of the drug in changingvalues, returning to those of the system with no mutations. This simulationcan be used to better understand the best concentration to obtain the expectedresults. In addition it is important to remember that on average "in vitro" and"in vivo" costs are very high. The research costs can be cut down by precedingclassical experiments with "in silicio" tests in order to eliminate any unpromisingdirections.Wild Type ModelThe wild type model is shown in listing 5.2: it is built through the use of threelocations, two physical and logical: outside, inside and self. As the name suggestsoutside is the space outside the cell, inside is the space inside the inside one andself is the logical name with which a physical location refers to itsself. There arenine different types of tuples involved in the system:1. Ag: 2-AG molecule, the full agonist.2. Aea: AEA molecule, the partial agonist.3. R: it is a receptor.4. Faah: FAAH molecule, the enzyme responsible for the AEA metabolism.5. Magl: MAGL molecule, the enzyme responsible for the termination ofendocannabinoid signaling.6. Aa: AA molecule, AEA and 2AG are hydrolyzed by intracellular enzymesto AA.7. Cox: Cox-2 molecule, the enzyme responsible for the AA termination.8. Pge: PGE molecule, the COX-2 enzyme catalyzed AA to PGE2.9. Plus: is a "dummy" tuple, used to store the enzyme complex with asubstrate (2-AG or AEA) and a receptor.

130 bioklaimbiolocalities:physical outside;physical inside;logical self;environments:outside:[self -> outside];inside:[self -> inside];messages: Aea, Ag, Aa, Pge, Plus, R, Cox, Faah, Magl;agents:let ReceptorManager beX -> read(Ag|R)@self:agcb.[Ag, Plus] | X+ read(Aea|R)@self:aeacb.[Aea, Plus] | Xendlet InOutCanal beX -> in(Aea)@inside:atm.[Aea] | X+ in(Ag)@inside:atm.[Ag] | Xendlet OutInCanal beX -> in(Aea)@outside:atm.[Aea] | X+ in(Ag)@outside:atm.[Ag] | Xendlet EnzymesManager beX -> in(Aea | Faah)@self:aeafaah.[Faah] | [Aa] | X+ in(Ag | Magl)@self:agmagl.[Magl] | [Aa] | X+ in(Aa | Cox)@self:aacox.[Cox] | [Pge] | Xendsystem:outside::[Ag]{35000} || outside::[Aea]{50000}|| outside::[R]{5} || outside::ReceptorManager [X]{1}|| outside::InOutCanal[X]{1} || inside::OutInCanal[X]{1}|| inside::EnzymesManager[X]{1} || inside::[Faah]{89000}|| inside::[Magl]{383500} || inside::[Cox]{250000}endListing 5.2: BioKlam specification of a microglia cell without mutation✆The agents in the specification describe the reactions involving substrates.ReceptorManager is the agent that manages the enzyme-substrate complex for-

5.4 biological models 131mation for the two agonist and CB2. A read action is used because substratesthat have participated in the interaction are not destroyed but still remain readyto bind again for activating or inhibiting Natural Killer (NK). InOutCanal andOutInCanal, as the names suggest, are agents that transport the substrates insideand outside the cell. Last agent is EnzymesManager and it destroys the substratesproducing, after two steps, a PGE molecule.Finally the initial configuration: Aea and Ag substrates and R receptor are putoutside the cell with ReceptorManager and InOutCanal agents. Instead inside thecell there are the enzymes and the agents OutInCanal and EnzymesManager. Sincethe phenomenon to be analyzed is the production and activation of interleukin,it is assumed that the cell is already activated, and the substrates are placedoutside. As you can see, the rate of action is defined in a mapping file presentedin the listing 5.3.aeafaah -> 600000000.0;aeacb -> 350000.0;agmagl -> 110000.0;agcb -> 15000000.0;aacox -> 24000000.0;atm -> 700000.0;Listing 5.3: Mapping file for model without mutation✆The number of tuples associated with substrates and enzymes are the cellularconcentrations of these proteins, since, in this study, a unit volume is considered.Moreover the values in the mapping file are the reciprocal of the disassociationconstant, then larger values will be associated with a greater affinity betweenelements into account. All numeric values are studied in the literature [141, 90,80, 145] and the data presented are all reported to the same unit measure pM g ,or (pico mole per gram).Model with MutationThe BioKlaim model with a mutation is shown in listing 5.4. As you can see,this is almost identical to the specific without mutation. Among the things thatdiffer two models, there are a tenth tuple, Drug, which is a drug molecule. Thishas the same behavior as the tuples representing substrates AEA and 2-AG. Itis also worth noting that the process describing the possible bind between CB2and drug produces the same result produced by the process that describes theinteraction between CB2 and 2-AG. This is because the considered drug has thesame function as 2-AG, namely full agonist.bio

132 bioklaimlocalities:physical outside;physical inside;logical self;environments:outside:[self -> outside];inside:[self -> inside];messages: Aea, Ag, Aa, Pge, Plus, R, Cox, Faah, Magl;agents:let ReceptorManager beX -> read(Ag|R)@self:agcb.[Ag, Plus] | X+ read(Aea|R)@self:aeacb.[Aea, Plus] | X+ read(Drug|R)@self:drugcb.[Ag, Plus ] | X # Rule for mutation of 1/Kiof receptor with Agendlet InOutCanal beX -> in(Aea)@inside:atm.[Aea] | X+ in(Ag)@inside:atm.[Ag] | Xendlet OutInCanal beX -> in(Aea)@outside:atm.[Aea] | X+ in(Ag)@outside:atm.[Ag] | Xendlet EnzymesManager beX -> in(Aea | Faah)@self:aeafaah.[Faah] | [Aa] | X+ in(Ag | Magl)@self:agmagl.[Magl] | [Aa] | X+ in(Aa | Cox)@self:aacox.[Cox] | [Pge] | Xendsystem:outside::[Ag]{35000} || outside::[Aea]{50000}|| outside::[R]{5} || outside::ReceptorManager [X]{1}|| outside::InOutCanal[X]{1} || inside::OutInCanal[X]{1}|| inside::EnzymesManager[X]{1} || inside::[Faah]{89000}|| inside::[Magl]{383500} || inside::[Cox]{250000}endListing 5.4: BioKlam specification of a mutated microglia cell✆The initial system configuration is the same of the no-mutated model exceptfor the Drug tuple initialization and the mapping file is shown in listing 5.5.

5.4 biological models 133aeafaah -> 600000000.0;aeacb -> 350000.0;agmagl -> 110000.0;agcb -> 15000000.0;aacox -> 24000000.0;atm -> 700000.0;drugmagl -> 110000.0;drugcb -> 20000000.0;Listing 5.5: Mapping file for mutated model✆The only differences within the two mapping files are: a smaller rate value forthe 2-AG and CB2 binding (this is the mutation) and new rates associated withthe binding factor of the drug and CB2, needed to define the drug interactions.The "in silicio" experiments aim to find the best drug concentration to returnvalues of the system as close as possible to the theoretical one. This type ofstudy is done, for example, for drugs such as JWH-0151 1 which known affinitywith the receptor, but for a proper administration know the best amount to beentered into the system is needed.In general, with some negligible modifications to the mutated model, it isalso possible the study of other series, for example the situation in which thedrug amount is known and you want to understand the administration results.Another possible study is to recognize the type of mutation that characterizes asystem, always being aware of the type of drug and amount administer.The SimulationThe simulation aims to determine the concentrations of activated and inhibitedNK, and PGE synthesized by enzymes. For both models the data to be collectedare the same and are shown in listing 5.6.Activated_Natural_Killer:[Ag,Plus]@outsideBlocked_Natural_Killer_Bloccato:[Aea,Plus]@outsideProstaglandins:[Pge]@insideListing 5.6: Data to collect during simulation✆The parameters for each simulation are:1 JWH-015 is a chemical from the naphthoylindole family, which acts as a subtype-selectivecannabinoid agonist. It binds almost 28x more strongly to CB2 than CB1. It has been shown topossess immunomodulatory effects, and CB2 agonists may be useful in the treatment of pain andinflammation.

134 bioklaim• deadline = 0.00003, since the approval of the characteristic developmentof NK activity occurs within this value;• dt = 0.0000000001, the analyzed interval divided into 300001 values;• iterations = 1000, so as to have an average behavior of model.Simulations have been performed for the system with and withour mutations,with different drug concentrations.Properties VerificationThe property to be verified in this model concerns the probability that the systemhas reached deadlock. The deadlock is given by the fact that all substrates AEAand 2-AG is transported from outside within the cell, no longer interacting withCB2 receptors, and thus not activating (or inhibiting) other NK. The formula tobe tested is the same for all models, and it is shown in listing 5.7.plot"true{true}Utrue&&![Ag]@outside->true)"with[0:0.0003:0.0000001]Listing 5.7: Data to collect during simulation✆This property returns the probability value that the Aea and 2-Ag tuples arenot outside the cell.This formula has been tested on a series of specifications describing the modelwith and without mutation. In the latter case with various concentrations ofdrug, in order to evaluate the effect that the drug has on the entire system.Regarding the performance of the verification process, the same machine forsimulations is used and the average values are:• 120 seconds for the mutated system without drug.• 240 seconds for the system with and without mutation and drug. The drugamount varied from 10 −8 M g to 2 ∗ 10−8 M g .ResultsIt will then be shown the results of in silicio experiments w.r.t. microglia modelswith and without mutation. Underlying these is the research for the best drugconcentration, as well as to show the functioning of the cell when it has beenactivated to fight any pathogen.For simulation, eight simulation scenarios were prepared: one for the wildtype model, while the remaining seven to see how a mutation and values ofdifferent drug concentrations should be to amend the behavior of the system.Each simulation shows the performance of the three monitored values: activated/blockedNK and PGE production. The graphs of Figures 43 and 44 showthe behavior of the healthy and mutated system in the absence of drug.

5.4 biological models 135Since the mutation affects only the dissociation constant between the CB2receptor and 2-AG, the trends of the blocked NK and the PGE production arethe same for all simulations. For this reason, the different trends activation ofNK are listed in another chart (Fig. 45).The results has the same trend as those reported in literature [141, 90, 80, 145],especially as regards the duration the reaction. As highlighted by the datacollected, in all the models the variance is about ±23% of the mean value.Also you can see that the concentration of drug that better compensate for themutated system ranges from 1.7 × 10 −8 M g to 1.8 × 10−8 M gand using the modelchecker this statement will be confirmed.Figure 43: No mutated system (wild type) behaviorThe model checker was used to investigate the probability that AEA and 2-AGsubstrates are present or not, outside the cell. Th results are shown in Figure 46.Varying the drug concentration, allows the model checker to compare the trendsof the two systems (mutated and not-mutated). This difference can be seenthrough the deadlock probability: this is higher in systems with mutated cells.Through this verification, the drug concentrations compensating the mutationranges from 1.7 × 10 −8 M g to 1.8 × 10−8 M g .

136 bioklaimFigure 44: Mutated system behavior5.4.4 Excitable CellsAn excitable cell has the ability to propagate an electrical signal to surroundingcells. Examples of excitable cells are muscle cells, endocrine cells and cardiacmyocytes. We now consider neurons which use electrical signaling to processesand transmits information. The movement of ions between the inside and outsidethe cell causes a change of electrostatic potential along the cell membrane. Thisvariation is called action potential: a short-lasting event in which the electricalmembrane potentiall of a cell rapidly rises and falls, the outside is positivelycharged and the inside negatively.The ions involved in cells stimulation are, among others, sodium (Na+) andpotassium (K+), which move inside and outside the cell by using both voltagegatedion channel and pumps present on the membrane of excitable cells. Problemswith electrical signal propagation may occur both in ion channels and in thepropagation of electric waves in the cellular network. In general, a cell triggersan action potential in response to an external stimulus. Figure 47 shows an actionpotential in neurons.The action potential can be divided into five parts.1. The Rising phase: a variation in the membrane voltage (external stimulus)opens Na+ voltage-gated ion channels and this changes the membrane’s

Figure 45: NK activation trends in various models5.4 biological models 137

138 bioklaimFigure 46: Probability through time that AEA and 2-AG substrates are present outsidethe cell.

5.4 biological models 139Figure 47: Action potential in neuronspermeability to Na+ ions: sodium ions enter the cell, further depolarizingthe membrane and opening most or all of the sodium channels.2. The Peak phase: the point at which depolarization stops. When the membranepotential reaches the maximum, the sodium channel are closedand, at the same time, the voltage-sensitive potassium (K+) channels areopened.3. The Falling phase: since the potassium channels are opened, potassiumions flow out the cell changing the electrochemical gradient. This causemembrane voltage to drop quickly.4. The Undershoot phase: at this point the membrane potential becomesmore negatively charged than when at rest.5. The Refractory period: the ion pumps use cellular energy (ATP) to "pump"the ions against their concentration gradient. They take ions from frominside the membrane (decreasing its concentration) and release them onthe other side (increasing its concentration). Ion pumps transports threesodium ions out of the cell and two potassium ions in. At the end of thisphase sodium and potassium concentrations return to their initial values.The variation of sodium and potassium concentration induces a variation ofthe membrane potential. The action potential is characterized by the presence oftwo acting works: electrical work, characterized by the formula W e = z ∗ F ∗ E,and the chemical work W c = R ∗ T ∗ ln [Ioneout][Ionein]. The first is due to the electricfield between the two side of the cellular membrane, while the second is related

140 bioklaimto ion concentrations between the interior and exterior of the cell. The Nernstequation derives from the equivalence of these two works.E = RTzF ln[ion] out[ion] inwhere:• R is the ideal gas constant, that is 8, 314472J◦ K mol ;• T is the temperature in kelvin ( ◦ K = ◦ C + 273, 15);• z is the number of moles of electrons transferred in the cell;• F is the Faraday constant, the number of coulombs per mole of electrons,F = 96485, 339Cmol ;• [Ione] out the extracellular concentration of that ion, in moles per cubicmeter ( molm 3 );• [Ione] in the intracellular concentration of that ion.The purpose of these experiments is to show how a tissues of excitable cellsbehave in relation to the action potential. Initially, it will be shown two systemsmodeling a single cell, then will be presented how cells can be composed tobuild a tissue.We created two BioKlaim models for studying action potential in a singlecell. The first one, more complex, simulates the action potential of excitablecells considering the ions movements, i.e. the electric potential variation in asingle cell induced by the ions exchange between the cell and the environment.The second one, more simple, models directly the action potential variationnot considering the causes. It will be used to build tissue of excitable cells forstudying signals propagations.The guards on the actions have been adopted to help in the creation of modelsfor excitable cells. Indeed it is was necessary to characterize enabled/disabledactions in each phase of the cycle described by the action potential. Anotherfeature introduced in BioKlaim is the ability to express the results simulationas a function of several model parameters. In the first example two modelsfor a single cell will be presented and then will be described how the cells arecomposed to build a tissue.Models for a Single Excitable CellThe first model deals with the action potential phenomenon as an ion exchangeprocess between the interior and exterior of a cell. The action potential ischaracterized by the presence of two works: electrical and chemical works.When the electrical and chemical works reach equilibrium, i.e. W c = −W e ,

5.4 biological models 141the considered ions stop moving through the cell and the system goes indeadlock. Afterwards ion pumps are activated and transport specific typesof ions from one side of the membrane to the other, sometimes using energyderived from metabolic processes. This completes the excitation process, andafter the Refractory period, the cell may be ready to begin the process again andtransmit a new action potential. This model is shown in listing 5.8.biolocalities:physical inside;physical outside;physical inside_1;logical self;logical next;environments :inside:[ self -> inside , next -> inside_1 ];messages: Na,K,Signal,NaChan,KChan,Pump,Ddp,Ready,Ignore,Excited;# F = 96.485 J / ( V * mol ) [ Cost . Faraday ]# R = 8.314 J / ( K * mol ) [ Cost . Gas ]# T = 310.15 K [Temperature]# z = valence number of ions ( in this case 1)# Electric Work:# We = z * F * E# Chemical Work:# Wc = R * T * ln ([ I ]@outside / [ I ]@inside )# Equilibrium :# Wc = -Leagents :let Cell beX -> in(Signal)@self:1.0.[NaChan]|[Ignore]|X1 #Stymulus.X1 -> {[Ignore]@inside=>1.0}in(Signal)@self:1000000000000000.0.X1+ {[NaChan]@inside>0.0&&(8.314*310.15*ln([Na]@outside/[Na]@inside))>-(96.485*30)}in(Na)@outside:0.65.[Na]|X1+ {[NaChan]@inside>0.0&&(8.314*310.15*ln([Na]@outside/[Na]@inside))0.0&&(8.314*310.15*ln([K]@outside/[K]@inside))0.0&&(8.314*310.15*ln([K]@outside/[K]@inside))=>(96.485*90)}in(KChan)@self:0.7.[Pump]|X3

142 bioklaimX3 ->eval(Cell[X4])@self:100000.0.X2X4 -> {[Ignore]@inside=>1.0}in(Signal)@self:1000000000000000.0.X4+ {[Pump]@inside>0.0&&[Ddp]@inside {[Ignore]@inside=>1.0}in(Signal)@self:1000000000000000.0.X2+ {[Pump]@inside>0.0&&[K]@inside0.0&&[Na]@outside0.0&&[K]@inside=>117.0&&[Na]@outside=>63.0}in(Ignore|Pump|Ready)@self:10000.0.Xendsystem:inside::[Signal]{1}||inside::Cell[X]{1}||inside::[K]{117}||outside::[K]{4}||inside::[Na]{20}||outside::[Na]{63}endListing 5.8: Excitable Cell model with ions activity✆In this model there are five localities: three physical and two logical. inside isthe interior of the cell, outside the exterior of the cell, while inside_1 representsthe interior of the cell that will receive the activation signal from the previouscell. As you can see from the specification, the logical localities have the samemeaning as in the previous model. In this model there are nine tuples:1. Na: a Na + molecule;2. K: a K + molecule;3. NaChan: activates the Na + voltage dependent channels;4. KChan: activates the K + voltage dependent channels;5. Pump: activates the Na + /K + pumps;6. dp: indicates the potential difference (1mV);7. Ready: activates the agent that reports the system in the initial configuration;8. Ignore: when present, the system ignore all the possible activation requests.

5.4 biological models 143Cell agent, just as in the previous model, contains the processes that lead thephenomenon. In this case the guards and actions refer to the exchange of ionsand the activation/deactivation of cellular structures. The initial configurationsets the initial ions concentrations (expressed in nM), put the Cell agent in thecell tuple and set the Signal tuple to trigger the action potential. The values ofthe actions rates and the model behavior were obtained from literature, mainlyfrom [42, 79, 30].It is remarkable that the use of guards allows to characterize reactions thathave to be enabled only after the occurrence of certain events (such as theachievement of equilibrium potential for Na + ). BioKlaim will activate themwhen the conditions expressed in the guard will become true.The second model is more simple then the previous one. Indeed in thefirst model simulate the action potential studying interior and exterior ionicconcentrations, while the second simulate the electric potential difference. Listing5.9 shows the code for this second model.biolocalities :physical c1;physical c2;logical self;logical next;environments :c1: [self->c1, next->c2];messages: Ddp, Signal, Stimulated, Excited, Ignore;agents:let Cell beX -> in(Signal)@self:1.0.[Stimulated]|[Ignore]|X1 #StimulatedX1 -> {[Ignore]@c1=>1.0} in(Signal)@self:10000000.0.X1+ {[Ddp]@c11.0} read(Ddp)@self:0.112.[Ddp]|X1+ {[Ddp]@c1=>160.0&&[Stimulated]@c1=>1.0} in(Stimulated)@self:1.0.[Excited]|[Signal]@c2 |X1+ {[Ddp]@c1=>40.0&&[Stimulated]@c11.0} in(Ddp)@self:0.12.X1+ {[Ddp]@c11.0}in(Signal)@self:10000000.0.X2+ {[Ddp]@c160.0}in(Ddp|Excited|Ignore)@self:1.0.[Ddp]|Xend

144 bioklaimsystem:c1::[Signal]{1}||c1::[Ddp]{60}||c1::Cell[X]{1}endListing 5.9: Excitable Cell model without ions activity✆This model is build through the use of four localities, two physical (c1 andc2) and two logical (self and next). The first physical locality corresponds tothe cell, whilst the second locality is used as repository for the signal that startthe same reaction in the neighbor cell. To improve specification readability, thelogical location are used to refer to the two physical locations. self states thecurrent location and next is the locality in which the cell send the signal toforward the stimulus. The model have five tuples:1. dp: indicates the potential difference (1mV);2. Signal: the initial stimulus that start the excitable reaction;3. Stimulated: tuple that marks the stimulated cell;4. Excited: tuple that marks the excited cell;5. Ignore: when present, the system ignore all the possible activation requests.The Cell agent describes the cell behavior in depolarization and hyperpolarizationphases. The initial configuration is quite simple: the Cell is placed,along with Signal tuple in the c1 locality. It is also worth noting the presence of60 dp tuples in c1: this is due to the fact that the resting potential is higher thanthe equilibrium potential for K + , then the system has to be initialized with thesetuples. In order to get a good overview of how the potential variation behaveson average, each of the two models were simulated 2000 times.The statistical model checker has been used to verify whether the single cellmodels have the same behavior during the action potential. The formula isshown in listing 5.10.plot"true{true}Utrue)"with[0:1000:0.001]Listing 5.10: Property to verify with the Model Checker✆The simulation results are shown in Figures48 and 49, while model checkingresult are shown in Figure 50. These experiments show that the two modelshave a similar behavior and therefore they can be used either at will.Excitable Cells Tissues ModelsThese experiments also try to model tissues as well as a single cell. This in silicioexperiments are based on the creation of cells tissue and aim at analyzing the

5.4 biological models 145Figure 48: Action potential with ions activityFigure 49: Action potential without ions activity

146 bioklaimFigure 50: Comparing Model Checking resultsexcitation propagation. Such experiments are the basis for studying specificdiseases such as epilepsy, convulsions and, in general, all those diseases thatare related to cells organization. For example: the epilepsy is characterized byan abnormal neuronal excitability due to alterations in ion channel function ormalformed tissues.The tissues models are created by composing single cells shown above. Wepresent two different connection configurations: square and list. In square configurationevery cell is linked to eight other neighboring cells and send them asignal that triggers the membrane depolarization. In the list configuration everycell is linked only to two other cells. The first configuration is characteristic ofmuscle tissue, while the second axon. The experiments proposed are:• Single cell with ionic activity.• Single cell without ionic activity.• 10 × 10 tissue without ionic activity. The first stimulated cell is in theposition (0, 0).• 10 × 10 tissue without ionic activity. The first stimulated cell is in theposition (5, 5).• 1 × 10 tissue without ionic activity. The first stimulated cell is in theposition (0, 0).

5.4 biological models 147The simulation is performed only once, in order to see exactly how the signalspread in the tissue. The simulation time is an average of 0, 01 seconds periteration for experiments with a single cells, and 60 seconds for experimentswith tissues.simulations25 and 26.The results of the proposed experiments are shown in Figures1ms 5ms 9msTable 25: Propagation of the potential difference in a list tissueAs regards the analysis of single cells and tissues, the results have the sametrend as those reported in the literature [41].

148 bioklaim0ms 0.5ms 1ms2ms 4ms 6msTable 26: Potential difference propagation in a square tissue

C O N C L U S I O N S6In this thesis we have presented TAPAs [54, 16]: a software environment forsupporting specification and analysis of concurrent systems via Process Algebras.It has been developed with an highly modularized structure: a Kernel applicationprovides algorithms and few graphic features to a set of plug-ins each of whichadds supports for a specific Process Algebra. Each plug-in is developed asan independent module that interact with main application for modelling,analyzing and debugging concurrent models.Such architecture allows us to factorize common behavior and obtain a modularstructure that provide to all plug-ins a set of basic characteristics. In particular,the reuse of the graphic Kernel components relieves future developers from theneed to create GUI. In this way, a developer can create a new plug-in focusingonly on the back-end, devoting much time to code functional modules. Moreoverplug-in structure hides most of the implementation details, allowing developersto implement their own plug-in with a minimal initial effort. We believe thatthe chosen programming language, the modular architecture and ready-for-usefeatures allow programmers to create new plugins in a reasonable time.Since TAPAs relies on loosely coupled components, plug-ins programmers canchoose which Kernel features to exploit and which not. This characteristic allowto create plug-ins with different degrees of integration with TAPAs back-end.In the thesis, three plug-ins have been described. CCSP plug-in exploits all thefeatures provided by Kernel and shows how TAPAs can be used as a tool forsupport teaching of concurrency. PEPA plug-in uses native modules only forLTS generation and step-by-step navigation while uses already developed PEPAlibraries [87, 144, 10] for providing analysis features. This partial integrationshows how TAPAs can integrate pre-existenting modules relatively easily providinggraphical specification and few debugging features. StoKlaim plug-inintegrates only the methods for projects managements and use another tool(SAM [14]) for performing analysis. This plug-in shows how to quickly creategraphical interface even for tools developed in different programming languages.These three different plug-ins allow to appreciate the variety of plugins that canbe developed for TAPAs.The proposed examples show the TAPAs capability both as teaching tool andas a software environment for prototypes development. The Two-Phase CommitProtocol described in CCSP shows that TAPAs can be used to develop known(but non-trivial) models while providing analysis and debugging features. Infact, during the modeling phase the example above can easily lead to errors andmisunderstandings which may not even be obvious to identify. However, such149

150 conclusionserrors can be corrected using the appropriate debugging features. The samesample was then modeled with PEPA, this allows to appreciate the differencebetween qualitative and quantitative analysis.The examples developed with StoKlaim [74] and BioKlaim are much moreresearch-oriented than teaching-oriented. Leader election examples serve to showboth the expressive power of the language and computational capacity of thetool. In fact, StoKlaim syntactic features allow users to model complex systems ina very compact form by using a simple and intuitive language. Moreover a newstatistical analysis technique has been used to analyze distributed protocols in nosmallnetworks. In BioKlaim we have presented four examples having increasingcomplexity: at first, two simple didactic case studies have been consideredand then after, two much more complex examples. Groupies&Celebrities is ateaching case study, while in intracellular enzymatic reaction model, a wellknownexample has been studied in a bidimensional structure which largelyaffects its behavior. The others biological examples are much more complexand closely related to computational biology. These examples do not aim atteaching either process algebras or biological processes, but they aim at definingnew methodologies for in silico experiments which allow to perform an initialphase of analysis faster and less expensive than traditional in vitro and in vivoexperiments.

B I B L I O G R A P H Y[1] Cwb-nc home page. http://www.cs.sunysb.edu/~cwb/. (Cited on page 8.)[2] Database of existing mechanized reasoning systems. http://www-formal.stanford.edu/clt/ARS/systems.html. (Cited on page 8.)[3] Eclipse foundation home page. http://eclipse.org. (Cited on page 10.)[4] Formal methods repositories. http://formalmethods.wikia.com/wiki/Repositories. (Cited on page 8.)[5] Java plugin framework home page. http://jpf.sourceforge.net/index.html, Year = 2007. (Cited on page 26.)[6] Javacc home page. (Cited on page 51.)[7] List of model checking tools. http://en.wikipedia.org/wiki/List_of_Model_Checking_Tools. (Cited on page 8.)[8] Ltsa home page. http://www.doc.ic.ac.uk/ltsa/. (Cited on page 9.)[9] Mrmc home page. http://www.mrmc-tool.org/trac/wiki. (Cited onpage 11.)[10] Pepa home page. http://www.dcs.ed.ac.uk/pepa/. (Cited on pages 10,66, and 149.)[11] Petri net tools databse. http://www.informatik.uni-hamburg.de/TGI/PetriNets/tools/db.html. (Cited on page 8.)[12] Prism case studies. http://www.prismmodelchecker.org/casestudies/index.php. (Cited on page 11.)[13] Prism home page. http://www.prismmodelchecker.org/. (Cited onpage 11.)[14] Sam: Stochastic analyser for mobility. http://rap.dsi.unifi.it/SAM/. (Citedon pages 78 and 149.)[15] Systems related to hol. http://www.cl.cam.ac.uk/research/hvg/HOL/history.html. (Cited on page 8.)[16] Tapas home page. http://rap.dsi.unifi.it/tapas. (Cited on pages 4,13, and 149.)151

152 Bibliography[17] Tools for formal reasoning, written in haskell. http://www.haskell.org/haskellwiki/Libraries_and_tools/Theorem_provers. (Cited on page 8.)[18] Uppaal-cora. http://www.cs.aau.dk/~behrmann/cora/. (Cited onpage 10.)[19] Uppaal-cover. http://www.uppaal.com/CoVer. (Cited on page 10.)[20] Uppaal home page. http://www.uppaal.com/. (Cited on page 9.)[21] Uppaal-port. http://www.uppaal.com/port. (Cited on page 10.)[22] Uppaal-pro. http://www.cs.aau.dk/~arild/uppaal-probabilistic/.(Cited on page 10.)[23] Uppaal-tiga. http://www.cs.aau.dk/~adavid/tiga/. (Cited on page 10.)[24] Uppaal-times. http://www.timestool.com/. (Cited on page 9.)[25] Uppaal-tron. http://www.cs.aau.dk/~marius/tron/. (Cited on page 10.)[26] Wiki page: Automated theorem proving. http://en.wikipedia.org/wiki/Automated_theorem_proving. (Cited on page 8.)[27] Yahoda: verification tools database. http://anna.fi.muni.cz/yahoda/.(Cited on page 8.)[28] Modelling and Analysis of Stochastic Systems. Chapman & Hall, 1995. (Citedon page 79.)[29] Concurrency: State models & java programs. http://www.doc.ic.ac.uk/~jnm/book/, 2009. (Cited on page 9.)[30] Electrostatic tuning of cellular excitability. Biophysical journal, 98(3):396–403,February 2010. (Cited on page 143.)[31] Baeten J.C.M. Fokkink W.J. Ingolfsdottir A. Nestmann U. Aceto, L. Applyingconcurrency research in industry: Report on a strategic workshop.Technical report, Bulletin of the European Association for TheoreticalComputer Science, 2007. (Cited on page 4.)[32] Gaudenz Alder. Jgraph home page. (Cited on page 52.)[33] María Alpuente, Byron Cook, and Christophe Joubert, editors. On aUniform Framework for the Definition of Stochastic Process Languages, volume5825 of Lecture Notes in Computer Science. Springer, 2009. (Cited on pages 80and 85.)

Bibliography 153[34] Suzana Andova, Holger Hermanns, and Joost-Pieter Katoen. Discrete-timerewards model-checked. In FORMATS, pages 88–104, 2003. (Cited onpage 11.)[35] A. Aziz, K. Sanwal, V. Singhal, and R. Brayton. Model checking ContinuousTime Markov Chains. Transations on Computational Logic, 1(1):162–170, 2000.(Cited on page 77.)[36] Adnan Aziz, Kumud Sanwal, Vigyan Singhal, and Robert K. Brayton.Verifying continuous time markov chains. In CAV ’96: Proceedings of the8th International Conference on Computer Aided Verification, pages 269–276,London, UK, 1996. Springer-Verlag. (Cited on page 10.)[37] J.C.M. Baeten and W.P. Weijland. Process algebra, volume 18 of CambridgeTracts in Theoretical Computer Science. Cambridge University Press, 1990.(Cited on page 5.)[38] C. Baier. On algorithmic verification methods for probabilistic systems. PhDthesis, Fakultat fur Mathematik and Informatik, Universitat Mannheim,1998. (Cited on page 11.)[39] C. Baier, J.-P. Katoen, and H. Hermanns. Approximate Symbolic ModelChecking of Continuous-Time Markov Chains. In J. Baeten and S. Mauw,editors, Concur ’99, volume 1664, pages 146–162. Springer, 1999. (Cited onpage 77.)[40] Christel Baier, Joost-Pieter Katoen, and Holger Hermanns. Approximatesymbolic model checking of continuous-time markov chains. In CONCUR’99: Proceedings of the 10th International Conference on Concurrency Theory,pages 146–161, London, UK, 1999. Springer-Verlag. (Cited on page 10.)[41] E. Bartocci. A Formal Framework for Modeling, Simulating and AnalyzingNetworks of Excitabile Cells. PhD thesis, Università degli studi di Camerino,2008. (Cited on pages 118 and 147.)[42] M F Bear, B W Connors, and M A Paradiso. Neuroscience: Exploring theBrain. Lippincott Williams & Wilkins, 2006. (Cited on page 143.)[43] Johan Bengtsson, Kim Larsen, Fredrik Larsson, Paul Pettersson, and WangYi. Uppaal - a tool suite for automatic verification of real-time systems,1996. (Cited on page 9.)[44] J.A. Bergstra and J.W. Klop. Process algebra for synchronous communication.Information and Control, 60(1-3):109–137, 1984. (Cited on page 3.)[45] L. Bettini, V. Bono, R. De Nicola, G. Ferrari, D. Gorla, M. Loreti, E. Moggi,R. Pugliese, E. Tuosto, and B. Venneri. The Klaim Project: Theory and

154 BibliographyPractice. In C. Priami, editor, Global Computing: Programming Environments,Languages, Security and Analysis of Systems, volume 2874, pages 88–150.Springer, 2003. (Cited on pages 77 and 78.)[46] Girish Bhat, Rance Cleaveland, and Orna Grumberg. Efficient on-the-flymodel checking for ctl. pages 388–397. IEEE Computer Society Press, 1995.(Cited on pages 28 and 30.)[47] G. Boudol. ULM: a core programming model for global computing:(extended abstract). In D.A. Schmidt, editor, Programming Languages andSystems, 13th European Symposium on Programming (ESOP), volume 2986,pages 234–248. Springer, 2004. (Cited on page 77.)[48] Laurier Boulianne, Michel Dumontier, and Warren J. Gross. A stochasticparticle-based biological system simulator. In SCSC: Proceedings of the 2007summer computer simulation conference, pages 794–801, San Diego, CA, USA,2007. Society for Computer Simulation International. (Cited on pages 111,118, 124, and 125.)[49] H. Bowman and R. Gomez. Concurrency Theory: Calculi an Automata forModelling Untimed and Timed Concurrent Systems. Springer–Verlag, 2006.(Cited on page 5.)[50] Julian Bradfield and Colin Stirling. Local model checking for infinite statespaces. Theor. Comput. Sci., 96:157–174, April 1992. (Cited on page 30.)[51] Julian Charles Bradfield. Verifying temporal properties of systems. BirkhauserBoston Inc., Cambridge, MA, USA, 1992. (Cited on page 30.)[52] S. D. Brookes, C. A. R. Hoare, and A. W. Roscoe. A theory of communicatingsequential processes. J. ACM, 31(3):560–599, 1984. (Cited on pages 3,8, and 50.)[53] Muffy Calder and Jane Hillston. Process algebra modelling styles forbiomolecular processes. T. Comp. Sys. Biology, 11(5750):1–25, 2009. (Citedon page 111.)[54] Francesco Calzolai, Rocco De Nicola, Michele Loreti, and Francesco Tiezzi.TAPAs: A Tool for the Analysis of Process Algebras . Transactions on PetriNets and Other Models of Concurrency I, 5100:54–70, 2008. (Cited on pages 4,13, and 149.)[55] Francesco Calzolai and Michele Loreti. Simulation and analysis of distributedsystems in klaim. In COORDINATION, pages 122–136, 2010.(Cited on page 103.)

Bibliography 155[56] L. Cardelli. A Language with Distributed Scope. In 22nd Annual ACMSymposium on Principles of Programming Languages, pages 286–297. ACM,1995. (Cited on page 77.)[57] L. Cardelli. Artificial biochemistry. Natural Computing Series, 2009. (Citedon pages 118, 119, and 122.)[58] Luca Cardelli. Brane calculi. In CMSB, pages 257–278, 2004. (Cited onpage 111.)[59] G. Castagna and J. Vitek. Seal: A framework for Secure Mobile Computations.In H. Bal, B. Belkhouche, and L. Cardelli, editors, InternetProgramming Languages, volume 1686, pages 47–77. Springer, 1999. (Citedon page 77.)[60] Federica Ciocchetta and Maria Luisa Guerriero. Modelling biologicalcompartments in bio-pepa. Electr. Notes Theor. Comput. Sci., 227:77–95, 2009.(Cited on page 111.)[61] E. Clarke, O. Grumberg, and D. Peled. Model Checking. 1999. ISBN0-262-03270-8. (Cited on page 30.)[62] Edmund M. Clarke and E. Allen Emerson. Design and synthesis ofsynchronization skeletons using branching-time temporal logic. In Logicof Programs, pages 52–71, 1981. (Cited on pages 3, 8, and 30.)[63] R. Cleaveland. On automatically explaining bisimulation inequivalence.In CAV ’90: Proceedings of the 2nd International Workshop on Computer AidedVerification, pages 364–372, London, UK, 1991. Springer-Verlag. (Cited onpages 33 and 37.)[64] Rance Cleaveland. Tableau-based model checking in the propositionalmu-calculus. Acta Informatica, 27:725–747, 1990. (Cited on page 30.)[65] Rance Cleaveland, Eric Madelaine, and Steve Sims. A front-end generatorfor verification tools. In TACAS ’95: Proceedings of the First InternationalWorkshop on Tools and Algorithms for Construction and Analysis of Systems,pages 153–173, London, UK, 1995. Springer-Verlag. (Cited on page 8.)[66] Rance Cleaveland and Steve Sims. The ncsu concurrency workbench. InCAV, pages 394–397, 1996. (Cited on page 8.)[67] Rance Cleaveland and Bernhard Steffen. A linear-time model-checkingalgorithm for the alternation-free modal mu-calculus. Formal Methods inSystem Design, 2(2):121–147, 1993. (Cited on page 8.)[68] T. Copeland. Generating Parsers with JavaCC. 2007. (Cited on page 51.)

156 Bibliography[69] D. R. Cox and H. D. Miller. The theory of stockastic processes : [by] D. R. Cox[and] H. D. Miller. Wiley, New York :, 1965. (Cited on page 102.)[70] J. Crhová, P. Krvcál, J. Strejvcek, D. vSafránek, and P. vSimevcek. Yahoda:Verification tools database. In Proc. of TOOLSDAY affiliated to CONCUR2002. FI MU report series, 2002. (Cited on page 8.)[71] R. De Nicola, G. Ferrari, and R. Pugliese. KLAIM: A Kernel Language forAgents Interaction and Mobility. IEEE Transactions on Software Engineering,24(5):315–329, 1998. (Cited on page 77.)[72] R. De Nicola and M. Hennessy. Testing equivalences for processes. Theor.Comput. Sci., 34:83–133, 1984. (Cited on pages 3, 8, 14, and 33.)[73] R. De Nicola and F.W. Vaandrager. Action versus state based logics fortransition systems. In Proceedings of the Ecole de Printemps on Semanticsof Concurrency, volume 469 of Lecture Notes in Computer Science, pages407–419. Springer–Verlag, 1990. (Cited on pages 3 and 89.)[74] Rocco De Nicola, Joost-Pieter Katoen, Diego Latella, Michele Loreti, andMieke Massink. Klaim and its stochastic semantics. Technical report, Dipartimentodi Sistemi e Informatica, Università di Firenze, 2006. Availableat http://rap.dsi.unifi.it/~loreti/papers/TR062006.pdf. (Cited onpages 77, 82, 91, and 150.)[75] Rocco De Nicola, Joost-Pieter Katoen, Diego Latella, Michele Loreti, andMieke Massink. Model checking mobile stochastic logic. Theoretical ComputerScience, 382(1):42–70, 2007. (Cited on pages 77, 82, and 85.)[76] Rocco De Nicola, Diego Latella, Michele Loreti, and Mieke Massink. Rate-Based Transition Systems for Stochastic Process Calculi. Automata, Languagesand Programming, 36th Internatilonal Collogquium, ICALP 2009, Rhodes,greece, July 5-12, 2009, Proceedings, Part II, 5556:435–446, 2009. (Cited onpages 79 and 85.)[77] Rocco De Nicola and Michele Loreti. Multiple-labelled transition systemsfor nominal calculi and their logics. Mathematical Structures in ComputerScience, 18(1):107–143, February 2008. (Cited on page 88.)[78] A. Dovier, C. Piazza, and A. Policriti. An efficient algorithm for computingbisimulation equivalence. Theor. Comput. Sci., 311(1-3):221–256, 2004. (Citedon page 32.)[79] Todor Dudev and Carmay Lim. Determinants of K+ vs Na+ Selectivity inPotassium Channels. Journal of the American Chemical Society, 131(23):8092–8101, June 2009. (Cited on page 143.)

Bibliography 157[80] Leah Edelstein-Keshet. Mathematical Models in Biology. Society for Industrialand Applied Mathematics, Philadelphia, PA, USA, 2005. (Cited onpages 118, 131, and 135.)[81] E. Allen Emerson and Joseph Y. Halpern. “sometimes” and “not never”revisited: on branching versus linear time temporal logic. J. ACM, 33(1):151–178, 1986. (Cited on page 8.)[82] Jean-Claude Fernandez and Laurent Mounier. ön the fly¨verification ofbehavioural equivalences and preorders. In CAV ’91: Proceedings of the3rd International Workshop on Computer Aided Verification, pages 181–191,London, UK, 1992. Springer-Verlag. (Cited on page 34.)[83] W. Fokkink. Introduction to Process Algebra. Springer–Verlag, 2000. (Citedon page 5.)[84] Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. DesignPatterns: Elements of Reusable Object-Oriented Software. Addison-WesleyProfessional, 1 edition, January 1994. (Cited on page 24.)[85] David Gelernter. Generative Communication in Linda. ACM Transactionson Programming Languages and Systems, 7(1):80–112, 1985. (Cited onpage 78.)[86] Daniel T. Gillespie. Exact stochastic simulation of coupled chemical reactions.The Journal of Physical Chemistry, 81(25):2340–2361, December 1977.(Cited on page 10.)[87] Stephen Gilmore and Jane Hillston. The pepa workbench: a tool to supporta process algebra-based approach to performance modelling. In Proceedingsof the 7th international conference on Computer performance evaluation: modelling techniques and tools, pages 353–368, Secaucus, NJ, USA, 1994.Springer-Verlag New York, Inc. (Cited on pages 10, 66, and 149.)[88] Stephen Gilmore, Jane Hillston, and Marina Ribaudo. An efficient algorithmfor aggregating pepa models. IEEE Trans. Software Eng., 27(5):449–464, 2001. (Cited on page 10.)[89] Jim Gray. Notes on data base operating systems. In Operating Systems,An Advanced Course, pages 393–481, London, UK, 1978. Springer-Verlag.(Cited on page 55.)[90] Abood ME Griffin G, Tao Q. Cloning and pharmacological characterizationof the rat cb(2) cannabinoid receptor. In The Journal Of Pharmacology andExperimental Therapeutics. (Cited on pages 118, 131, and 135.)

158 Bibliography[91] Grima, Ramon, Schnell, and Santiago. A mesoscopic simulation approachfor modeling intracellular reactions. Journal of Statistical Physics, 128(1-2):139–164, July 2007. (Cited on page 111.)[92] Ramon Grima. A mesoscopic simulation approach for modeling intracellularreactions. Journal of Statistical Physics, 128:139–164(26), July 2007.(Cited on pages 118 and 124.)[93] J. F. Groote and F. Vaandrager. An efficient algorithm for branchingbisimulation and stuttering equivalence. In Proceedings of the seventeenthinternational colloquium on Automata, languages and programming. Springer-Verlag, 1990. (Cited on page 32.)[94] Jan Friso Groote and Frits Vaandrager. An efficient algorithm for branchingbisimulation and stuttering equivalence. In Proceedings of the seventeenthinternational colloquium on Automata, languages and programming, pages 626–638, New York, NY, USA, 1990. Springer-Verlag New York, Inc. (Cited onpage 33.)[95] G. Norman H. Younes, M. Kwiatkowska and D. Parker. Numerical vs.statistical probabilistic model checking. International Journal on SoftwareTools for Technology Transfer, 8(3):216–228, June 2006. (Cited on page 95.)[96] Hans Hansson and Bengt Jonsson. A logic for reasoning about time andreliability. Formal Aspects of Computing, 6:102–111, 1994. (Cited on page 11.)[97] M. Hennessy and R. Milner. Algebraic laws for nondeterminism andconcurrency. J. ACM, 32(1):137–161, 1985. (Cited on page 3.)[98] J. Highsmith and A. Cockburn. Agile software development: the businessof innovation. Computer, 34(9):120–127, August 2002. (Cited on page 23.)[99] J. Hillston. Fluid flow approximation of pepa models. In QEST ’05: Proceedingsof the Second International Conference on the Quantitative Evaluationof Systems, page 33, Washington, DC, USA, 2005. IEEE Computer Society.(Cited on page 10.)[100] A. Hinton, M. Kwiatkowska, G. Norman, and D. Parker. PRISM: A toolfor automatic verification of probabilistic systems. In H. Hermanns andJ. Palsberg, editors, Proc. 12th International Conference on Tools and Algorithmsfor the Construction and Analysis of Systems (TACAS’06), volume 3920 ofLNCS, pages 441–444. Springer, 2006. (Cited on page 11.)[101] C.A.R. Hoare. A Model for Communicating Sequential Processes. In Onthe Construction of Programs, pages 229–254. Cambridge University Press,1980. (Cited on pages 3, 14, and 33.)

Bibliography 159[102] C.A.R. Hoare. Communicating Sequential Processes. Prentice Hall, 1985.(Cited on page 5.)[103] A. Itai and M. Rodeh. Symmetry breaking in distributed networks. Informationand Computation, 88(1), 1990. (Cited on pages 103 and 107.)[104] P. C. Kanellakis and S. A. Smolka. Ccs expressions finite state processes,and three problems of equivalence. Inf. Comput., 86(1):43–68, 1990. (Citedon pages 32 and 33.)[105] J.-P. Katoen, M. Khattri, and I. S. Zapreev. A Markov reward model checker.In Quantitative Evaluation of Systems (QEST), pages 243–244, Los Alamos,CA, USA, 2005. IEEE Computer Society. (Cited on page 11.)[106] Joost-Pieter Katoen, Maneesh Khattri, and Reza Pulungan. Model checkingmarkov reward models with impulse rewards. In DSN ’05: Proceedings ofthe 2005 International Conference on Dependable Systems and Networks, pages722–731, Washington, DC, USA, 2005. IEEE Computer Society. (Cited onpage 11.)[107] Robert M. Keller. Formal verification of parallel programs. Commun. ACM,19:371–384, July 1976. (Cited on pages 14 and 15.)[108] Bartek Klin and Vladimiro Sassone. Structural operational semantics forstochastic process calculi. In Proceedings of FOSSACS 2008, volume 4968 ofLecture Notes in Computer Science. Springer, 2008. (Cited on page 81.)[109] H. Korver. Computing distinguishing formulas for branching bisimulation.In CAV, pages 13–23, 1991. (Cited on page 33.)[110] D. Kozen. Results on the propositional µ-calculus. Theor. Comput. Sci.,27:333–354, 1983. (Cited on page 3.)[111] Saul A. Kripke. Semantical considerations on modal logic. Acta PhilosophicaFennica, 16:83–94, 1963. (Cited on page 14.)[112] M. Kwiatkowska, G. Norman, and D. Parker. Verifying randomizeddistributed algorithms with PRISM. In Proc. Workshop on Advances inVerification (Wave’2000), July 2000. (Cited on page 11.)[113] S. Anderson L. Chen and F. Moller. A timed calculus of communicatingsystems. Technical report, Laboratory for Foundations of ComputerScience, 1990. (Cited on page 8.)[114] X. Leroy, D. Rémy, J. Vouillon, and D. Doligez. TheObjective Caml system, documentation and user’s guide.http://caml.inria.fr/ocaml/htmlman/, 1999. (Cited on page 78.)

160 Bibliography[115] Emmanuel Letier, Jeff Kramer, Jeff Magee, and Sebastian Uchitel. Fluenttemporal logic for discrete-time event-based models. SIGSOFT Softw. Eng.Notes, 30(5):70–79, 2005. (Cited on page 9.)[116] Jeff Magee. Concurrency: State Models And Java Programs. John Wiley &Sons, 2006. (Cited on page 9.)[117] R. Milner. A Calculus of Communicating Systems., volume 92 of Lecture Notesin Computer Science. Springer–Verlag, 1980. (Cited on pages 3, 8, and 50.)[118] R. Milner. Communication and concurrency. Prentice-Hall, Inc., UpperSaddle River, NJ, USA, 1989. (Cited on pages 3, 5, 8, 14, and 33.)[119] F. Moller and P. Stevens. Edinburgh Concurrency Workbench user manual.Available from http://homepages.inf.ed.ac.uk/perdita/cwb/. (Citedon page 33.)[120] Maurice Naftalin and Philip Wadler. Java Generics and Collections. O’ReillyMedia, Inc., 2006. (Cited on page 24.)[121] Ernst-Rüdiger Olderog. Operational Petri net semantics for CCSP. InProceedings of European Workshop on Applications and Theory of Petri Nets,volume 266, pages 196–223. Springer–Verlag, 1987. (Cited on page 48.)[122] R. Paige and R. E. Tarjan. Three partition refinement algorithms. SIAM J.Comput., 16(6):973–989, 1987. (Cited on pages 32 and 33.)[123] G. D. Plotkin. A structural approach to operational semantics. TechnicalReport DAIMI FN-19, Computer Science Department, Aarhus University,Aarhus, Denmark, September 1981. (Cited on pages 3 and 15.)[124] G.D. Plotkin. A structural approach to operational semantics. TechnicalReport DAIMI-FN-19, Aarhus Univ. - Comp. Scie. Dept., 1981. (Cited onpage 26.)[125] Amir Pnueli. The temporal semantics of concurrent programs. TheoreticalComputer Science, 13(1):45 – 60, 1981. (Cited on page 3.)[126] Corrado Priami, Paolo Ballarini, and Paola Quaglia. Blenx4bio - blenxfor biologists. In Pierpaolo Degano and Roberto Gorrieri, editors, CMSB,volume 5688 of Lecture Notes in Computer Science, pages 26–51. Springer,2009. (Cited on page 111.)[127] Corrado Priami and Paola Quaglia. Operational patterns in beta-binders.T. Comp. Sys. Biology, 3380(1):50–65, 2005. (Cited on page 111.)

Bibliography 161[128] Corrado Priami, Aviv Regev, Ehud Y. Shapiro, and William Silverman.Application of a stochastic name-passing calculus to representation andsimulation of molecular processes. Inf. Process. Lett., 80(1):25–31, 2001.(Cited on page 111.)[129] Paola Quaglia and Stefano Schivo. Approximate model checking ofstochastic cows. In Proc. of TGC 2010. To appear., 2010. (Cited on page 95.)[130] Jean-Pierre Queille and Joseph Sifakis. Specification and verificationof concurrent systems in cesar. In Proceedings of the 5th Colloquium onInternational Symposium on Programming, pages 337–351, London, UK, 1982.Springer-Verlag. (Cited on page 30.)[131] Aviv Regev, Ekaterina M. Panina, William Silverman, Luca Cardelli, andEhud Y. Shapiro. Bioambients: an abstraction for biological compartments.Theor. Comput. Sci., 325(1):141–167, 2004. (Cited on page 111.)[132] A.W. Roscoe. The Theory and Practice of Concurrency. Prentice-Hall, 1997.(Cited on page 5.)[133] Nicola Santoro. Design and Analysis of Distributed Algorithms (Wiley Serieson Parallel and Distributed Computing). Wiley-Interscience, 2006. (Cited onpages 57 and 103.)[134] K. Schneider. Verification of Reactive Systems - Formal Methods and Algorithms.Texts in Theoretical Computer Science (EATCS Series). Springer, 2003.(Cited on page 30.)[135] S.A. Schneider. Concurrent and Real-Time Systems: The CSP Approach. Wiley& Sons, 1999. (Cited on page 5.)[136] Koushik Sen, Mahesh Viswanathan, and Gul Agha. Statistical modelchecking of black-box probabilistic systems. In CAV, pages 202–215, 2004.(Cited on page 95.)[137] Koushik Sen, Mahesh Viswanathan, and Gul Agha. On statistical modelchecking of stochastic systems. In CAV, pages 266–280, 2005. (Cited onpage 95.)[138] Abraham Silberschatz. Operating Systems Concepts. John Wiley & Sons,2005. (Cited on page 55.)[139] Dale Skeen and Michael Stonebraker. A formal model of crash recovery ina distributed system. pages 295–317, 1987. (Cited on pages 55, 62, and 63.)[140] Colin Stirling and David Walker. Local model checking in the modalmu-calculus. In 2nd international joint conference on Theory and practice

162 Bibliographyof software development, TAPSOFT ’89, pages 161–177, Amsterdam, TheNetherlands, The Netherlands, 1991. Elsevier Science Publishers B. V.(Cited on page 30.)[141] T. Sugiura, Y. Kobayashi, S. Oka, and K. Waku. Biosynthesis and degradationof anandamide and 2-arachidonoylglycerol and their possible physiologicalsignificance. Prostaglandins, Leukotrienes and Essential Fatty Acids,66(2-3):173 – 192, 2002. (Cited on pages 131 and 135.)[142] R. A. Bond T. P. Kenakin and T. I. Bonner. Definition of pharmacologicalreceptors. Pharmacol. Rev., 1992. (Cited on page 127.)[143] Guzman Tierno. Algoritmi per equivalenze su sistemi di transizione. Master’sthesis, Universitaá degli Studi di Firenze, 2005. (Cited on page 33.)[144] Mirco Tribastone, Adam Duguid, and Stephen Gilmore. The pepa eclipseplugin. SIGMETRICS Perform. Eval. Rev., 36(4):28–33, 2009. (Cited onpages 10, 66, and 149.)[145] A. Uzman. Molecular Cell Biology (4th edition) - Harvey Lodish, ArnoldBerk, S. Lawrence Zipursky, Paul Matsudaira, David Baltimore and JamesDarnell; Freeman &amp; Co., New York, NY, 2000, 1084 pp., list price$102.25, ISBN 0-7167-3136-3. Biochemistry and Molecular Biology Education,pages 126–128, 2001. (Cited on pages 118, 131, and 135.)[146] R.J. van Glabbeek and F.W. Vaandrager. Bundle event structures andCCSP. In Proceedings of 14th International Conference on Concurrency Theory(CONCUR 2003), volume 2761 of Lecture Notes in Computer Science, pages57–71. Springer–Verlag, 2003. (Cited on page 48.)[147] P.H.J. van Eijk, C.A. Vissers, and M. Diaz. The formal description techniqueLOTOS. Elsevier Science Publishers B.V., 1989. (Cited on page 8.)[148] R. J. van Glabbeek. The linear time-branching time spectrum (extendedabstract). In Proceedings on Theories of concurrency : unification and extension:unification and extension, CONCUR ’90, pages 278–297, New York, NY, USA,1990. Springer-Verlag New York, Inc. (Cited on pages 18 and 19.)[149] R.J. van Glabbeek. The linear time-branching time spectrum ii - thesemantics of sequential systems with silent moves, 1993. (Cited on pages 18and 19.)[150] R.J. van Glabbeek and W.P. Weijland. Branching time and abstraction inbisimulation semantics. J. ACM, 43(3):555–600, 1996. (Cited on pages 3,14, and 33.)

Bibliography 163[151] Cristian Versari and Nadia Busi. Stochastic biological modelling in thepresence of multiple compartments. Theor. Comput. Sci., 410:3039–3064,August 2009. (Cited on page 111.)[152] A. Wald. Sequential Tests of Statistical Hypotheses. The Annals of MathematicalStatistics, 16(2):117–186, 1945. (Cited on page 96.)[153] Glynn Winskel. Topics in concurrency lecture notes, 2009. (Cited onpages 28, 30, and 31.)[154] Håkan L. S. Younes. Probabilistic verification for "black-box" systems. InCAV, pages 253–265, 2005. (Cited on page 95.)[155] Håkan L. S. Younes and Reid G. Simmons. Probabilistic verification ofdiscrete event systems using acceptance sampling. In Proceedings of the14th International Conference on Computer Aided Verification, pages 223–235,London, UK, 2002. Springer-Verlag. (Cited on page 95.)[156] W. M. Young and E. W. Elcock. Monte Carlo studies of vacancy migrationin binary ordered alloys: I. Proceedings of the Physical Society, 89(3):735–746,1966. (Cited on page 102.)