dataesr/scientific-paragraphs-categorization huggingface dataset:
e. , tuples of synchronizable tasks for each gate. Then, we automatically produce a C library that offers an interface to the synchronization vectors. A gate program has a generic behavior parametrized by the possible rendezvous in the system. We implemented this generic behavior in a C library, once and for all. For a given distributed system model, we link this generic module against the synchronization vector library to eventually obtain gate programs that coordinate tasks with respect to the parallel composition of the system. This approach allows us to isolate the synchronization core logic in a standalone module, for easier debugging and maintenance. Concerning tasks, we use the EXEC/CAESAR  [11]  sequential code generator, already available in CADP, to produce a C implementation of each task process.
DLC is a command-line tool that takes as input a file containing an LNT parallel composition. In one command, DLC automatically generates C code for tasks, synchronization vectors library, glue code, and eventually calls a C compiler to produce the main, task, and gate programs. The protocol relies on asynchronous message passing on a reliable network that keeps messages ordered between two programs; we use TCP sockets to meet these requirements. Moreover, the main program uses a framework already employed in the context of distributed model checking  [34]  to deploy, start and monitor other programs on several machines. The main program parses a user-given, plain-text, network configuration file, which indicates on which machine each program should run, and then deploys the system using ssh (or equivalent tools) for distant access.
A default configuration file where all programs are located on the local host is generated, enabling the implementation to be tested locally right after program generation. Scripts can be used to generate configuration files for deployment on clusters or grids. The code generator comprises about 1500 lines of code (mainly shell scripts), and its internal libraries represent about 2200 lines of C code. On the example of Section III, DLC also generates 2302 lines of C code for each server, and 84 lines of C code for the synchronization vector library.
A gate program executes its post-negotiation hook before it checks that all data offer variables are set. Therefore, the user can use the postnegotiation hook to detect unset variables, assign to them a   -----------------logger task hook -----------------*   --------------------GET hooks ---------------------*   -----------------INTERRUPT hooks ------------------*   4. Hook functions permit to interact with the external environment and to control system actions. Here, the logger task gets some value from an external database and logs it to the local storage, until it is interrupted. These operations are abstracted away in the LNT model, while the user-defined hook functions enable to actually perform side effects in the external environment, and to control when the interruption happens. value from the external environment, and flag them as set.
This enables feeding data values from the external environment into the system at runtime, while preserving LNT semantics, which allow any value in such situations. Figure  4  illustrates various usages of hooks. We consider a unique logger task which loops on getting the data associated to a key in a database and logging this data, until it receives an interruption. The task hook writes the data passed on LOG actions onto the local storage of the machine where the task program runs. There is no motivation to prevent actions on gate GET, so its pre-negotiation hook always returns true. The GET post-negotiation hook retrieves the key from data offers, connects to an external database to fetch the corresponding value, and then provides this value to the logger task by setting the second data offer variable.
For our second experiment, we modeled Raft  [8]  in LNT in order to demonstrate DLC on a non-trivial system. Raft, like the better known Paxos  [35] , is a consensus algorithm: it maintains a consistent log of entries replicated among a set of servers, while surviving the failure of some servers. It thus enables fault tolerant services to be built using the replicated state machine technique  [36]. A TLA+ formal specification of Raft core features (leader election and log replication) is available, upon which a hand written safety proof is built  [37]. Our LNT model includes a basic key-value store made fault tolerant using Raft: every client request to the store is first committed on a majority of servers before the answer is sent back to the client. We use hook functions to implement (a) the timeout mechanism needed in Raft, (b) the control of server crashes, and (c) a socket interface to the key-value store, such that external client programs can be implemented in any language.
VII. CONCLUSION A distributed system made of asynchronous concurrent processes can be formally modeled in LNT, using powerful primitives such as multiway rendezvous. An LNT model can be formally verified thanks to the numerous and mature tools of CADP. The tool DLC, presented in this paper, now also enables rapid prototyping by automatically generating a distributed implementation in C. We think the combination of LNT, CADP and DLC provides a featureful framework for the formal verification and rapid prototyping of distributed systems. We covered how DLC proceeds to generate distributed programs, and we exposed DLC internal architecture. Besides task and gate programs, DLC also generates a main program which eases the deployment on a cluster of machines. In order to let the end-user have some control on the generated programs and define interactions with the external world, we introduced hook functions, which enable user-defined C procedures to be integrated into the final implementation.
The hook functions can only restrict the system behavior, therefore they should not be able to make it behave incorrectly with respect to the original model semantics. We presented two experiments made with DLC, including the implementation of the non-trivial Raft algorithm. The observed performances reveal that even if DLC generated programs are currently slower than solutions written in general programming languages, we consider that they still qualify for rapid prototyping. As future work, we plan to make DLC handle elaborate types, such as lists and arrays, in data offers. Moreover, it would be useful to implement timing mechanisms (such as timeouts) as primitives of LNT, as already suggested in  [38]. Finally, a way to raise the trust in the correctness of the generated implementation could be to monitor its execution.
This work was partly funded by the  French Fonds national pour la Société Numérique (FSN) ,  Pôles Minalogic, Systematic and SCS  (project OpenCloudware). Experiments presented in this paper were carried out using the Grid'5000 testbed, supported by a scientific interest group hosted by  Inria  and including  CNRS , RENATER and several Universities as well as other organizations (see https://www. grid5000. fr).
g. , in conditional statements the link between the result of the evaluation of a condition expression (computed in the semantic rules) and which branch is consequently executed (determined in the concurrency model). This paper proposes a dedicated meta-language to define a sound protocol between the concurrency model and the semantic rules. This protocol allows the specification of the data-dependent parts of the concurrency model, by specifying how to determine if an execution path allowed by the concurrency model is consistent with regards to the runtime state of the model. The concurrency model is kept independent from the data, enabling concurrency-aware analyses to be performed in order to ensure properties of the xDSML. We also depict its implementation and integration in a language workbench, the GEMOC Studio, for validation purposes.
Separation of Concerns Previous work  [7]  has proposed the following approach to design a Concurrency-aware xDSML. At the heart of a Concurrency-aware xDSML is its Abstract Syntax, which defines the syntactic concepts of the domain and their relations. The AS is extended with several elements. First, the Execution Data (ED), which are the set of classes, attributes and references representing the runtime state of the model. Then, the semantic rules of its concepts, called Execution Functions (EF) in our approach. They specify in an operational manner how the runtime state of the model evolves. The concurrency model defines the pure concurrent control flow of the language, orchestrating the semantic rules but leaving all the data-dependent aspects of the control flow in the semantic rules.
This solution is enough for conflicts independent of any data (the language is thus indeterministic). But conflicts can also depend on data available at runtime in the model, as is the case for fUML DecisionNodes. In that case, realizing an arbitrary choice can lead to a meaningless execution of the rest of the model, or to errors (e. g. , when trying to execute nodes with no tokens on their incoming edges). Data-dependent conflicts should thus be resolved with respect to the runtime state of the model. The concurrency model of fUML is able to specify that after executing a DecisionNode, each of its branches may or may not be executed. It is also able to specify that ultimately only one of the branches will actually be executed. Additionally, it is able to specify that if one of the branches that may be executed has the default guard "else", it will only be executed if it is the only one allowed.
The results are respectively "True" and "False" when the OutputPin of "CheckTableForDrinks" returns "Coffee" (as is assumed in Figure  6 ). Therefore, the function f will return true for the first path (it is compatible with the runtime state of the model) and false for the second one (it is inconsistent with regards to the runtime state of the model). The Feedback Protocol must specify (at the language level, i. e. , in intention) the set of data-dependent execution paths (i. e. , P D ) together with the set of functions f p (where f p determines whether a path p ∈ P D may be taken or not). This specification must be independent of any model, but be applicable to any model conforming to the abstract syntax of the language. For a specific model, applying the Feedback Protocol consists in removing the execution paths from P D that are inconsistent with the runtime state of the model.
Existing Elements To specify the Abstract Syntax, we rely on Ecore, the EMF implementation of EMOF  [37]. The associated static semantics are expressed in terms of Object Constraint Language (OCL) invariants  [36]. Both EMOF and OCL are standards from the Object Management Group (OMG) 2. The Semantic Rules are implemented using the Kermeta 3 Action Language (K3AL)  [13] , built on top of xTend  [4]. K3AL allows the definition of aspects for Ecore metaclasses, allowing us to weave the additional classes, attributes, references and operation implementations specifying the Execution Data and the Execution Functions. K3AL, just like xTend, compiles into Java Bytecode and provides an executor based on the Java Reflection API to dynamically execute the Execution Functions. To specify the MoCC, we use MoCCML  [10] , a declarative meta-language designed to express constraints between events which can be capitalized into libraries agnostic of any AS.
The definition of the EventType Structure is realized using the Event Constraint Language (ECL)  [11] , an extension of OCL which allows the definition of EventTypes for concepts from the AS. It can also use constraints defined in MoCCML to specify how the Event Structure at the model level must be obtained. The MoCC is compiled to a Clock Constraint Specification Language (CCSL)  [27]  model inter-1 http://gemoc. org/studio/ 2 http://omg. org/ preted by the TimeSquare  [12]  tool. For the practical reasons mentioned in 3. 4, TimeSquare only provides the next set of possible configurations. At runtime, an Execution Engine written mostly in Java coordinates the K3AL interpreter and the CCSL solver to realize the execution of a model conforming to a Concurrency-aware xDSML. Figure  8  shows the sequence diagram for an execution step.
Communication Protocol Our meta-language to specify the Communication Protocol (both the Mapping Protocol and the Feedback Protocol) is called GEMOC Events Language (GEL). Figure  9  shows an excerpt from its Abstract Syntax, specified as an Ecore model. It has a textual concrete syntax developed using Xtext  [4]. In GEL, Domain-Specific Events implement both the Mod-ifierMapping and QueryMapping concepts. If the referenced Execution Function is a Query, then a Feedback Policy may be specified. A Feedback Policy is constituted of at least two rules, including a default one. A Feedback Rule is constituted of a Predicate on the return type of the associated Query, and of an allowed EventType (MoccEvent). Since the consequences of all the rules of a policy constitute the set of data-dependent EventTypes, we can specify in the rules either the consistent ones or the inconsistent ones and deduce the others by getting its complement.
Execution of the Example Model A video showing the execution of the example model is available at http://gemoc. org/sle15/. It also provides the GEMOC Studio and the workspaces containing the source for our implementation of fUML and the example model. We have used Groovy as an action language to define the body of the fUML Actions. Figure  11  shows a close-up on the DecisionNode part of the Event Structure. Based on the value returned by each guard, an event corresponding to each guard occurs (the "May. " if true was returned, "MayNot. " if false was returned). Since the branch for drinking water has the default guard "else", it is only executed if none of the other two branches can be executed. If both tea and coffee are available (although in our model this will never happen), then an arbitrary choice is made by the runtime.
In that case, the concurrency model is unable to specify how the evaluation of a guard relates to its transition being allowed to fire or not. As in fUML, a Feedback Protocol is needed to specify that if a guard evaluates to true, then the associated transition may be fired, else it may not be. Another example of this is the Simulink [28] language. In Simulink a model is usually a dataflow of blocks where the output of a block is used as input for the next block. However, the output of a block can also be connected to a special port of the next block, the EnablePort 3. In that case, the output of the first block is compared to 0. If it is greater, then the block with the EnablePort is executed, else it is not. In that case, the Feedback Protocol is required to specify that if the output value of the first block is greater than zero, then the second block will be executed, else it will not.
Note that this requires being able to manage the same data type as returned by a Simulink block, and then to compare it to 0. This assumes a certain expressive power from the meta-language used to specify the Feedback Policy as discussed later in the limitations of the approach. More generally, any language construct whose semantics rely on conditionals where the condition expression can be based on runtime data from the model will raise the same problem as fUML DecisionNodes: the concurrency model is able to enumerate all the possible scenarios, but it does not have the expressive power to specify how to choose among them. We rely on the classification of control flow constructs in workflow systems provided in  [41]  to identify more formally the applicability of our approach. In this study, the authors have identified 43 patterns describing the control flow perspective of workflow systems.
Related Work Concurrency models have been the subject of theoretical computer science for a long time, establishing well-known concepts such as Petri Nets  [33] ; Process Algebras  [21, 30, 31] ; the Actor Model  [1] ; Event Structures  [45] ; Tagged Signals  [25]. Some tools allow the design of multi-paradigm systems based on models of concurrency, such as Ptolemy  [39]  or ModHel'X  [19] , but the concept of concurrency model has not been reified to the language level. Some frameworks, libraries or languages promote a form of separation between the control flow and the operational aspects of an application. Event-driven programming such as promoted by node. js usually uses a form of Callback, inspired from the Continuation-passing style of programming  [2]. This can lead to a complicated programming style commonly known as "Callback hell", where the control flow is spread all over the code, and the code itself is hard to read, debug and refactor.
Therefore, the model of concurrency of the program (model) is guaranteed by the definition of the concurrency of the language. DSL editors, usually called Language Workbenches  [15] , such as Metacase's MetaEdit+  [24] , JetBrain's MPS  [44] , Microsoft's DSL Tools  [9] , Spoofax  [23]  or Rascal  [43] , and executable metamodeling approaches such as the K Framework  [40]  or xMOF  [29]  do not provide an explicit model of the concurrency of the semantics of the DSLs created. Instead, the implicit model of concurrency is usually the one used by the hosting platform or language. This means that running concurrency-aware analyses on the language or refining it for a specific platform is complex. In our approach the concurrency model is explicit and specified in an appropriate meta-language, making it more suitable for analyses and refinement.
Conclusion and Perspectives We have proposed a concurrent executable metamodeling approach which allows the specification of Concurrency-aware xDSMLs. Previously, this approach did not support the specification of data-dependent language constructs. This issue hindered many languages from being specific correctly, as illustrated by the proportion of control flow patterns whose semantics relies on runtime data, identified in  [41]. Thanks to our contribution, which extends the Communication Protocol between the concurrency model and the semantic rules with a Feedback Protocol, the approach now support the specification of these constructs. We have also described how the Feedback Protocol is applied at the model level so as to respect the concurrency model of the language. Our approach has been illustrated on fUML, a language in which branches outgoing a DecisionNode are allowed depending on the evaluation of their guard, and implemented in a language workbench, the GEMOC Studio.
INTRODUCTION Biological macromolecules do not act in isolation, but rather interact with each other to perform their cellular functions. In particular, thousands of interactions are observed between proteins, forming the basis of cellular biological processes. Thanks to the scaling of the experimental techniques allowing interaction discovery, and to the development of centralized databases, recent years have witnessed the accumulation of thousands of physical and functional interactions of various nature  (Sharan & Ideker, 2006). For instance, data obtained from yeast two-hybrid and affinity purification-mass spectrometry experiments inform on the physical interactions between proteins and their organization as molecular complexes; mRNA expression correlations identify the genes that are coexpressed in a set of experimental conditions, and signaling pathway data describe the cascades of reactions transmitting signals within and between cells.
Biological multiplex networks Four biological networks were constructed from different sources of interactions between human genes or proteins. A network of physical binary protein-protein interactions was created from the PSICQUIC portal  (Del-Toro et al. , 2013)  and the CCSB Interactome database  (Rolland et al. , 2014) , and contains 60,669 direct interactions between 12,110 proteins. A co-expression network was constructed from RNA-Seq data downloaded from the Human Protein Atlas (http://www. proteinatlas. org). Spearman correlations of expression were computed between all genes based on FPKM values in 27 tissues and 44 cell lines, and correlation ≥0. 7 were selected as interactions (1,107,547 interactions between 9,212 genes). A pathway network was constructed from Biocarta (http://www.
biocarta. com), Spike  (Paz et al. , 2011) , Kegg  (Kanehisa et al. , 2008) , PID  (Schaefer et al. , 2009)  and Reactome  (Croft et al. , 2014) , using the R package graphite  (Sales, Calura & Romualdi, 2014). It contains 166,761 interactions between 8,839 genes. A network of complexes was constructed from the CORUM database  (Ruepp et al. , 2009)  using the matrix model, and contains 36,762 interactions between 2,528 genes. For detailed protocol and options, the markdown is available at GitHub (https://github. com/gillesdidier/MolTi). Data were fetched and networks created in May, 2015. Networks in the Fig. 4  are represented with Cytoscape  (Saito et al. , 2012). The 4 biological networks correspond to the different layers of the multiplex biological network, sharing the same set of vertices (i.
Annotation enrichment The actual biological communities are unknown, but the accuracy of the detected communities can be assessed by verifying their consistency with known biological processes. We performed exact Fisher tests  (Fisher, 1954)  to search for enrichment in Gene Ontology Biological Process (GOBP) terms  (Ashburner et al. , 2000)  associated with the genes/proteins of each community. The Bonferroni correction for multiple testing was applied on the Fisher p-values by taking into account both the number of tested ontology terms and communities. Similarly, the communities were screened for enrichment in disease genes extracted from the CTD database  (Davis et al. , 2014)  and filtered to select the curated gene-disease associations (marker/mechanisms/therapeutic).
MolTi software We developed MolTi, a standalone user-friendly graphical software. MolTi detects communities from multiplex networks provided by the users, by optimizing the multiplexmodularity with the adapted Louvain algorithm. MolTi further optionally performs Fisher tests of annotation enrichment for the detected communities, and allows an easy exploration of the results. MolTi and corresponding source code are freely available at Github (https://github. com/gilles-didier/MolTi).
The identification of communities from 4 biological networks and the issue of the resolution parameter We constructed 4 biological networks from physical functional interaction data: a protein-protein interaction network, a network of pathways, a network of protein complex, and a mRNA co-expression network (Methods, Section 'Biological multiplex networks'). These networks are sparse, heterogeneous in densities and incomplete. Their densities range from 0. 001 to 0. 023, with an average of 0. 01. They are also prone to missing data as their sizes range from 2,528 to 12,110 nodes (Table  S1 ). Missing data is indeed an important feature in biological networks since insufficient depth and coverage of the interaction space leads to incomplete interaction datasets  (Venkatesan et al. , 2009; Braun et al.
DISCUSSION Interactions between genes and proteins can be of various nature and are identified by diverse experimental approaches. We focused here on different facets of protein cellular functions by taking into account (i) physical interactions between proteins, extracted from experiments such as yeast 2-hybrid screens, (ii) interactions derived from the belonging of proteins to complexes, (iii) functional interactions extracted from pathway databases and (iv) co-expression correlations derived from mRNA expression in different cellular contexts. However, other types of functional relationships between genes or proteins, such as their implication in the same disease  (Goh et al. , 2007)  or their targeting by the same drug  (Yildirim et al. , 2007)  could be considered. Consequently, many networks can depict gene/protein functional relationships.