dataesr/scientific-paragraphs-categorization huggingface dataset:
E. PROPOSED ALGORITHM The optimisation problem described in section II. B includes integer variables, constraints and is non-linear because of SCR calculations. GA is often used for mixed-integer nonlinear optimisation problems and more globally in many power system problems  [31]. In this work, a joint platform consisting of a Genetic Algorithm (GA) and PSS R E is established. The GA is developed in Python by defining mutation, selection and crossover functions. The steps of the proposed algorithm are outlined as follows: • The GA randomly creates the initial generation and sends it to PSS R E. Note that here generation does not mean power generation. Instead, it indicates biological inception used in GA algorithm. • Synchronous condensers are installed in the network. Then load flow analysis is performed via PSS R E, and voltages of all PCC buses are recorded.
This process is executed using Python scripts. • System strength calculation is done using TDDS in PSS R E at every PCC of wind power plants. • PSS R E sends the results to the GA which creates the next generation, and so on until the stopping criteria is fulfilled. In the proposed algorithm, the optimisation process terminates if the total number of generation exceeds a predefined maximum and/or there are high similarities between subsequent generations. Fig. 1  illustrates the problem formulation, with the red box as input (i. e. a wind dominated power grid model) and the green box as output (i. e. the best synchronous condenser installation and the economic details).
Executable domain-specific languages (DSLs) enable the execution of behavioral models. While an execution is mostly driven by the model content (e. g. , control structures), many use cases require interacting with the running model, such as simulating scenarios in an automated or interactive way, or coupling the model with other models of the system or environment. The management of these interactions is usually hardcoded into the semantics of the DSL, which prevents its reuse for other DSLs and the provision of generic interaction-centric tools (e. g. , event injector). In this paper, we propose a metalanguage for complementing the definition of executable DSLs with explicit behavioral interfaces to enable external tools to interact with executed models in a unified way. We implemented the proposed metalanguage in the GEMOC Studio and show how behavioral interfaces enable the realization of tools that are generic and thus usable for different executable DSLs.
eclipse. org/papyrus/. part of the execution framework of the GEMOC Studio  [5] , an Eclipse-based language and modeling workbench for xDSLs. We evaluate the approach with three demonstration cases. In the first one, we show that the proposed metalanguage can be used to define the behavioral interface of two xDSLs. In the second one, we show that behavioral interfaces enable the definition of generic tools and their use across several xDSLs. In the third one, we show that a single behavioral interface can be subtyped by several xDSLs, allowing to interact with and reason about the execution of conforming models through a common behavioral interface. The remainder of this paper is structured as follows. Section 2 presents the background and the motivation for this work, as well as the requirements for the approach.
Background on executable DSLs An xDSL is composed of an abstract syntax defining the concepts of the considered domain and an execution semantics defining the meaning of these concepts. In this paper, we focus on DSLs where (1) the abstract syntax is provided as a metamodel defined using a metamodeling language (e. g. , MOF  [32]  or Ecore  [40] ) and (2) the execution semantics is provided as an operational semantics (i. e. , an interpreter). In addition to the metamodel defining its abstract syntax, an xDSL can expose several structural language interfaces constituting its available model types  [11, 15, 39]. These model types define a set of metaclasses and structural features that are guaranteed to be present in the metamodel constituting the abstract syntax of the DSL and thus supported by its conforming models.
Definition 2 We define an xDSL as a tuple AS, OS where AS is its abstract syntax and OS its operational semantics. Figure  1  shows the definition of the Arduino xDSL, which will be used as a running example throughout this paper. The abstract syntax of the DSL is defined as a metamodel (a in Fig. 1 ). A Project contains a Board and a Sketch. The board of the project represents the physical Arduino board on which the sketch of the project is executed. A Board contains Modules, which have an id attribute. A Module can either be an OutputModule, such as a Led, or an InputModule, such as a PushButton. Being a program to be executed on a Board, a Sketch contains a Block of Instructions that can be Control, ModuleSet, Delay or WaitFor instructions. Control instructions come in the usual forms of If and While instructions.
They contain a Block (or potentially two for the If instruction) and a condition in the form of an Expression. For the sake of brevity, the whole class diagram of Expression is not shown here, except for the ButtonGet and LedGet classes, which, respectively, point to a PushButton and a Led. The ModuleSet class is further specialized for each Output-Module: Here, SetLed is a ModuleSet instruction for Led modules, setting the level attribute of its associated Led to the result of the evaluation of its value expression. The Delay instruction suspends the execution for the specified amount of milliseconds. The WaitFor instruction points to an InputModule and suspends the execution until the level of the referenced module reaches the provided value. The bottom part of Fig. 1  shows the two parts of the operational semantics of the Arduino DSL.
The execution metamodel (b in Fig. 1 ) extends the Module class with the level integer attribute, indicating the logic level of the signal transiting between a Module and its containing Board. For Led modules, the level represents whether the LED is lit or not, whereas for PushButton modules, it indicates whether the button is currently pressed or not. The execution rules (c in Fig. 1 ) import this execution metamodel and consist of model transformations defining how the state of a running model is altered. In the case of the Arduino DSL, only the level attributes of Led and PushButton elements can be changed, either by the SetLed. execute rule for Led modules, or PushButton. press and PushButton. release for PushButton modules. As the execution semantics of the Arduino DSL is implemented as a visitor, the scheduling of the execution rules is determined internally.
The referenced model elements are accessed through the read-only structural language interface of the metamodel they conform to, thereby preventing their unauthorized modification. In addition, this allows for event parameters to reference metaclasses that are compatible with several xDSLs, if these references are typed by metaclasses contained in a model type common to these DSLs. In the proposed approach, event occurrences do not need to be contained in another entity. However, a language engineer aiming to provide tooling that revolves around event occurrences can define metamodels (e. g. , scenario or trace metamodels) with a composition relationship toward event occurrences, which is the approach adopted in the GEMOC Studio.
Through this relationship, the language engineer defines the mapping between activate and activated events and the run, button_pressed, button_released and led_level_changed events. In this example relationship, when a button is activated, it means it has been pressed and then released. Likewise, a LED is considered as having been activated if it has been switched from off to on. Two accept rules and one expose rule are defined as part of this relationship. The OnActivateSketch rule is triggered by occurrences of activate and has a condition stating that a Sketch element with a name corresponding to the id carried out by the event occurrence must exist in the running model. The OnActivateButton rule is also triggered by occurrences of activate but has a different condition, stating that a Button element with the appropriate name must exist in the running model instead.
CEP-based event management Implementation and subtyping relationships, as introduced in Sect. 4. 2, require a concrete strategy to define and manage enclosed ECA rules. In this section, we present a strategy based on complex event processing (CEP) and more specifically on Esper's event processing language (EPL). First, we mention the salient features of CEP that make it an interesting candidate for event management in our approach. Then, we introduce the event manager component acting as an ECA rule engine. Next, we detail how event occurrences are modeled in Esper, and finally, we explain the design process of relationships and their ECA rules.
If it is a stepping rule, the engine notifies observers at the beginning and at the end of the execution of the rule. Note that depending on the metalanguage, an execution rule may trigger the nested execution of other stepping rules, in which case observers are also notified when the nested execution of these stepping rules begins or ends. For instance, in the Arduino model shown in Fig. 2 , calls to SetLed. execute will be nested within calls to If. execute, which will in turn be nested within calls to Sketch. run. Note that no distinction is made between the notifications from nested and non-nested rule calls. -registerObserver registers a component as an observer that gets notified when the execution of a stepping rule begins or ends and when the engine starts or stops. When an observer gets registered, an associated priority policy needs to be supplied as well.
Such a policy provides, for each kind of notification, the priority at which the observer must be notified. This operation is called by the execution engine during the initialization phase, to register a predefined set of execution observer, retrieved from a configuration file for instance, but it can also be called at any time. The specification of this component is by design as generic as possible to be able to cover a wide range of metalanguages. As such, it provides an abstraction over the multiple execution engines dedicated to various metalanguages available in the GEMOC Studio (see Sect. 5. 3). The implementation of this component is, however, heavily dependent on the metalanguage used to implement the operational semantics, especially regarding the procedure to dynamically call an arbitrary execution rule (e.
Tool support We implemented our approach as part of the GEMOC Studio  [5] , a language and modeling workbench atop the Eclipse platform  [25]. The metamodel of the behavioral interface language is defined using Ecore, and the event manager is written in both Java and Xtend. The source code is available on Github. 3 he language workbench of the GEMOC Studio offers multiple metaprogramming approaches to define the operational semantics of a DSL (e. g. , Java/Kermeta  [20] , xMOF  [24]  or Henshin  [2] ), as well as one execution engine for each approach. Our implementation of the event manager is agnostic to the kind of execution engine that is used, in accordance with Sect. 5, and comes with a metalanguage integration facade for the Java/Kermeta-based execution engine. In order to make use of the approach, a reflective event injection GUI was designed, allowing to send and receive event occurrences from running models and complementing the existing generic omniscient debugger for xDSLs defined in the language workbench  [6].
The implementation relationship defined between this behavioral interface and the operational semantics of the Arduino DSL is straightforward: run occurrences are translated into call requests to the Sketch. run execution rule, -button_pressed and button_released occurrences are translated into call requests to the Button. press and Button. release execution rules, and -calls to the SetLed. execute execution rule are translated into led_level_changed occurrences, with the new level being directly queried from the model. In total, the implementation relationship itself required, for each ECA rule, around 5-6 lines of Java code for the method bodies, while we were able to define a library specific to Esper-based implementation relationships that can be reused for any implementation relationship.
Second, call notifications for the Behavior. execute execution rule are translated into signal_sent occurrences. In total, the implementation relationship itself required, for each ECA rule, around 5-8 lines of Java code for the method bodies, and we were able to reuse the same library for Esper-based implementation relationships that we defined when applying the approach to the Arduino DSL. Fulfilling Req. 1. We successfully applied the approach on two xDSLs, one very specific and the other more general. In the process, we defined a library that language engineers can reuse to define their Esper-based implementation relationships. This allowed to keep the amount of lines of code required to implement each ECA rules very low, at around 5 to 8 lines of Java code. This shows that the proposed metalanguage is expressive enough to define in a unified way the possible interactions with models conforming to these two DSLs.
Finally, the GUI provides a log of exposed event occurrences listing all the received event occurrences. As we implemented our approach and tools within the GEMOC Studio, we are able to use the reflective event injection GUI in conjugation with the generic debugger already provided by the GEMOC Studio  [6]. Using this extended debugger, we are able to pause the execution, queue event occurrences, use stepping operators (forward and backward), define breakpoints and resume a paused execution to evaluate the impact of queued event occurrences on this execution. This can be used on any model conforming to any DSL developed with any of the metalanguages provided by the language workbench for which an integration facade is defined. Fulfilling Req. 2  No tool-specific line of code is required to interact with running models, indicating that the event manager component provides a sufficiently expressive API for both tools.
By leveraging this library, the ECA rules of the subtyping relationship required around 3 to 5 lines of Java code per method body. Subtyping with UML state machines Figure  12  details the content of the OnActivateSignal and OnSignalSent ECA rules of the subtyping relationship between ActivatableInterface (as a supertype) and StateMachineInterface (as a subtype). The left part of the figure highlights the fact that activate occurrences (from ActivatableInterface) are translated into run, signal_received and call_performed occurrences (from StateMachineInterface). The OnActivateSignal rule is detailed. Upon detecting an activate occurrence, it first checks that a Signal element with a name identical to the value supplied for the id parameter of the activate occurrence exists in the executed model.
If that is the case, the rule translates the original event occurrence into a signal_received occurrence from StateMachineInterface. This new occurrence is configured to carry a newly instantiated occurrence of the proper signal. The right part of the figure highlights the fact that signal_sent occurrences (from StateMachineInterface) are translated into activated occurrences (from Activat-ableInterface) through the OnSignalSent rule. This rule is straightforward as it maps occurrences of the signal_sent event to occurrence of the activated event carrying the name of the signal (i. e. , the type of the signal occurrence carried out by signal_sent event occurrences) as the value of their id parameter. In total, the ECA rules of the subtyping relationship each required around 3-7 lines of Java code for the method bodies, as we were able to reuse the library for Esper-based subtyping relationships.
Fulfilling Req. 3  In this demonstration case, we defined ActivatableInterface as a common supertype of both the Arduino DSL and UML State Machines through subtyping relationships between ActivatableInterface and both ArduinoInterface and StateMachineInterface. In the process, we defined a library dedicated to Esper-based subtyping relationships, allowing us to keep the number of lines of Java code required to define each ECA rule of these relationship between 3 and 7 per method body. Once defined, the subtyping relationships allow the previously defined reflective tools to be indiscriminately used with models conforming to either DSL, sending and receiving event occurrences from the ActivatableInterface interface in both cases. For example, the test runner can be used to check whether an Arduino model being a realization of a State Machine model behaves in the same expected way, by running the exact same test suite on both models, provided this test suite is designed with event occurrences from the Acti-vatableInterface interface.
Threats to validity Internal validity As we are experienced in using the GEMOC Studio, we might have overlooked limitations to our approach that would make it hard to use for language engineers. Conducting a user study to assess the usefulness of our tools and the usability of our approach is an important direction of our future work. External validity We verified that our approach yields its benefits for two xDSLs and two generic tools, which externally threatens the ability of our approach to be generalized to multiple DSLs and tools. However, the two selected xDSLs are relevant and representative of the languages supported by the approach as their abstract syntax is defined as a metamodel and their execution semantics is defined as a discrete-event operational semantics written in an object-oriented language and orchestrated by an execution engine.
Critical discussion While the approach works well for xDSLs whose conforming models are similar to state/transition systems, it presents some limitations when working with xDSLs that have timerelated concepts, such as the Arduino DSL. More precisely, defining an ECA rule similar to the activate rule for PushButton elements that allows for a customized duration between pressing and releasing a button (and more generally between two event occurrences) would require to be able to specify waiting times before specific event occurrences are sent by the event manager. Since the approach works at the language level, the issue is then to decide on a waiting time that will fit all conforming models, or to find a way to derive or define this waiting time on a model-by-model basis. Addi-tionally, expressing time durations also requires a time unit, which could either be a generic unit (e.
Therefore, as long as language engineers implemented the execution semantics of their xDSL according to the separation of concern, little to no refactoring is necessary for adopting the approach. Finally, the use of the Stop event discussed in Sect. 5. 2. 3 and the existence of a run event in both ArduinoInterface and StateMachineInterface indicate that a kind of "system" behavioral interface, dedicated to execution specific events (e. g. , starting and stopping the execution, pausing it, waiting) would be beneficial. This in turn hints at another purpose for behavioral interfaces, defined at the metalanguage level, which is worth investigating. While a sizable amount of work has been done on language interfaces, most of it is dedicated to structural language interfaces, i. e. , language interfaces for interacting with models on the structural level.
In some of our previous work  [9] , we advocate for the inclusion of an event definition metamodel in the specification of xDSLs, to which occurrences of domain-specific events conform. Our proposed behavioral interface metalanguage is a more expressive mean to define such an event definition metamodel. Beyond this extended expressivity, our proposed metalanguage relies on behavioral typing to enable implementation and subtyping relationships, and its execution semantics allows to safely interact with running models. In  [27] , Meyers et al. presented the ProMoBox approach, which includes the generation of an input metamodel from a DSL definition, which can also be seen as a behavioral interface. However, this interface is only used for model checking, while our contribution is geared toward model execution.
We implemented our approach for the GEMOC Studio, a language and modeling workbench for xDSLs. We demonstrated the value of our approach through two demonstration cases based on the implementation of two generic event-centric tools and their usage on two xDSLs through their respective implemented interface in a first time, and through their common supertype interface in a second time. Perspectives for future work can be sorted in two categories: extending/improving the approach and leveraging the approach. Future work extending the approach includes leveraging formally defined behavior for xDSLs and behavioral interface to automatically infer the implementation and subtyping relationships between them. Such an extension would take inspiration from existing work (e. g. ,  [41] ) on model refinement operators that are behavior-preserving and could leverage existing languages for CEP with a formally defined semantics such as  [1].
Acknowledgements Open access funding provided by  Austrian Science Fund (FWF). This work is partially funded by the  Austrian Science Fund (FWF) :  P 28519-N31  and P 30525-N31 as well as by the  Austrian Federal Ministry for Digital and Economic Affairs  and the  National Foundation for Research, Technology and Development. This work is also partially funded by the  Austrian Agency for International Mobility and Cooperation in Education, Science and Research (OeAD)  on behalf of the  Federal Ministry for Science, Research and Economy (BMWFW)  under the Grand No. FR 08/2017 , by the  French Ministries of Foreign Affairs and International Development (MAEDI)  and the  French Ministry of Education, Higher Education and Research (MENESR) , and by the  French Project ELOGE (Atlanstic 2020 Amorçage)  financed by  Région des Pays de la Loire.
For instance, in the Arduino DSL, an event signaling the push of a button will carry a reference (thus a Reference-Value) to the button being pushed, whereas in UML State Machines, an equivalent event would carry an instance of UML event only created to send the event occurrence (thus an InstanceValue), named "button_pushed" and itself carrying the identifier of the button being pushed. 4. 1. 2 Examples of behavioral interfacesArduinoInterface Figure6shows a possible behavioral interface for the Arduino DSL, using the textual concrete syntax of the behavioral interface metalanguage. This interface defines three accepted events and one exposed event. As they are accepted events, occurrences of run, button_pressed.
6 onsent is not simply a conversion of a paper PICF into an electronically delivered version. It also holds the promise of improving participant engagement in clinical trials through a variety of features that include: • the use of multimedia tools to enhance comprehension; • ready conversion into multiple languages; • a means to track consent in a highly portable man- ner; and • the opportunity to provide information in a more convenient way to persons with an inability to attend clinics. The use of eConsent does not replace the opportunity for participants to ask direct questions to their doctor or the investigators. Moreover, in most instances, participants will still be required to make a physical visit to a clinic to receive their treatment, whereupon they can ask questions and confirm their willingness to participate.