Erwan Bousse
email: erwan.bousse@ls2n.fr

Manuel Wimmer
email: manuel.wimmer@jku.at

Domain-Level Observation and Control for Compiled Executable DSLs

Keywords: Software Language Engineering, Domain-Specific Languages, Executable DSL, Compilation, Feedback

Executable Domain-Specific Languages (DSLs) are commonly defined with either operational semantics (i.e., interpretation) or translational semantics (i.e., compilation). An interpreted DSL relies on domain concepts to specify the possible execution states and steps, which enables the observation and control of executions using the very same domain concepts. In contrast, a compiled DSL relies on a transformation to an arbitrarily different target language. This creates a conceptual gap, where the execution can only be observed and controlled through target domain concepts, to the detriment of experts or tools that only understand the source domain. To address this problem, we propose a language engineering architecture for compiled DSLs that enables the observation and control of executions using source domain concepts. The architecture requires the definition of the source domain execution steps and states, along with a feedback manager that translates steps and states of the target domain back to the source domain. We evaluate the architecture with two different compiled DSLs, and show that it does enable domain-level observation and control while increasing execution time by 2× in the worst observed case.

I. INTRODUCTION

A large number of Domain-Specific Languages (DSLs) can be used to describe the dynamic aspects of systems (e.g., [START_REF] Wimmer | Semantics of a Foundational Subset for Executable UML Models[END_REF]- [START_REF]Web Services Business Process Execution Language Version 2[END_REF]). In that context, early dynamic verification and validation (V&V) techniques, such as omniscient debugging [START_REF] Bousse | Supporting Efficient and Advanced Omniscient Debugging for xDSMLs[END_REF], testing [START_REF] Meyers | Automated testing support for reactive domain-specific modelling languages[END_REF], or tracing [START_REF] Bousse | Advanced and efficient execution trace management for executable domainspecific modeling languages[END_REF] are necessary to ensure that models conforming to such languages are correct. These techniques require models to be executable, which can be achieved by defining the execution semantics of the DSLs used to define them. To that effect, a lot of efforts have been made to provide facilities to design so-called executable DSLs (e.g., [START_REF] Combemale | A Design Pattern to Build Executable DSMLs and Associated V&V Tools[END_REF]- [START_REF] Tatibouët | Formalizing Execution Semantics of UML Profiles with fUML Models[END_REF]), which can be used to define executable models. More precisely, two different approaches are commonly used to define the semantics of an executable DSL: operational semantics (i.e., interpretation) and translational semantics (i.e., compilation). In this paper we are interested in both approaches, and we specifically focus our work on discrete-event semantics.

All previously mentioned V&V approaches rely on two key tasks: the observation of the progress of the execution (e.g., which execution steps are occurring), and the control of the execution (e.g., pausing and resuming). With an interpreter, the dynamic state of a model conforming to the DSL is defined along with the possible execution steps that modify such state over time. These definitions can directly rely on domain-specific concepts, opening the possibility to observe and control executions from a domain perspective (e.g., visualizing the active state of a state machine). However, with a compiler, a model conforming to the DSL is translated into another executable language. By default, observing the resulting execution yields information specific to the target language instead of the considered DSL, i.e., there is no feedback at the domain level. For instance, when code is generated from a model, it is common to rely on an interactive debugger of the target language, but without the possibility to directly relate information back to the original model.

While ad-hoc solutions have been proposed for both compiled programming languages (e.g., jdb translates bytecodelevel information back to the Java-level) and compiled modeling languages (e.g., several UML code generators provide model-level feedback [START_REF] Ciccozzi | Execution of UML models: a systematic review of research and practice[END_REF]), there is to our knowledge no systematic approach to provide domain-level observation and control for any compiled DSL. Having such an approach would in addition enable the use and reuse of a wide range of runtime services-i.e., tools that provide dynamic V&Vat the domain-level of compiled DSLs. However, to obtain such benefits, some important challenges must be considered: [START_REF] Wimmer | Semantics of a Foundational Subset for Executable UML Models[END_REF] the same level of observation and control must be provided for compiled DSLs as what is possible for interpreted DSLs;

(2) the use of a wide range of runtime services must be possible with compiled DSLs, and, to reduce development efforts, the reuse of the same runtime services must be possible among both interpreted and compiled DSLs; (3) the overhead on the execution time must be as small as possible.

To address these challenges, we propose a language engineering architecture where a compiled DSL is supplemented with a feedback manager, which relies on traceability links to translate execution steps and states of the target language back into the original domain. This feedback manager is connected to the ongoing execution of the target model, and thus provides domain-level feedback at execution time. Runtime services (e.g., an interactive debugger or a tracer) may be attached to the feedback manager in order to continuously observe and control the execution at the domain-level. In addition, runtime services can interchangeably be used both for interpreted and compiled DSLs. To limit the overhead during the execution, the state of the source model is only modified when changes occur in the state of the target model.

We implemented our approach as part of the execution framework of the GEMOC Studio, an Eclipse-based language and modeling workbench. Our evaluation relies on the application of the proposed architecture on two different compiled DSLs: first a subset of fUML activity diagrams compiled to Petri nets, and second, a subset of UML state machines compiled to MiniJava. Results show that two existing runtime services initially targeting interpreted DSLs can be used for both DSLs, while increasing execution time by 2x in the fUML case, and by 1,01x in the UML state machines case.

Section II defines the scope of considered executable DSLs. Section III gives an overview of the architecture, which is then presented in Section IV. Section V presents our evaluation. Section VI compares the related work with our approach. Finally, Section VII concludes with research directions.

II. EXECUTABLE DSLS

A. Abstract Syntax

We focus in this paper on metamodel-based DSLs, i.e., DSLs whose abstract syntaxes are metamodels defined using metamodeling languages (e.g., MOF [START_REF]Meta Object Facility (MOF) Core Specification, V 2.5[END_REF] or Ecore [START_REF] Steinberg | EMF: Eclipse Modeling Framework, 2nd Edition, ser. Eclipse Series[END_REF]). Definition 1. A metamodel is composed of a set of metaclasses, each composed of a set of properties typed either by another metaclass or by a primitive type.

Accordingly, a model conforming to a metamodel takes the form of an object graph where each object is an instance of a metaclass of the metamodel. An object is composed of fields, each setting the value of a corresponding property.

The top-left corner of Figure 1 shows the abstract syntax of a Petri nets DSL. It contains three metaclasses: Net, Place and Transition. Each metaclass contains properties; for instance Net contains a set of Place and Transition objects through the places and transitions properties.

B. Interpreted DSL

An interpreted DSL is based on an operational semantics, in which we distinguish three main constituents.

First, the possible execution states of models conforming to an interpreted DSL must be defined. This is commonly accomplished either by extending the abstract syntax with dynamic properties and metaclasses [START_REF] Mayerhofer | xMOF: Executable DSMLs based on fUML[END_REF], [START_REF] Jézéquel | Mashup of metalanguages and its implementation in the Kermeta language workbench[END_REF]-in which case the state is part of the executed model-or by defining a separate metamodel [START_REF] Hegedüs | Replaying Execution Trace Models for Dynamic Modeling Languages[END_REF]-in which case the state is a separate model. While our proposed architecture remains valid with both approaches, our examples in this paper rely on the first one, i.e., the possible states are defined by extending the abstract syntax with new dynamic properties and metaclasses.

Second, we call interpretation rules what defines how the state of an interpreted model changes over time. Such rules can be defined using a wide range of model transformation techniques (e.g., Java or Xtend with EMF [START_REF] Steinberg | EMF: Eclipse Modeling Framework, 2nd Edition, ser. Eclipse Series[END_REF], Kermeta [START_REF] Jézéquel | Mashup of metalanguages and its implementation in the Kermeta language workbench[END_REF], xMOF [START_REF] Mayerhofer | xMOF: Executable DSMLs based on fUML[END_REF], ATL [START_REF] Jouault | Transforming models with ATL[END_REF], [START_REF] Yie | Advanced Traceability for ATL[END_REF], etc.).

Third, the possible execution steps that may occur during the interpretation of a model must be defined. We call an execution step a set of observable changes applied on the model state. Accordingly, the model state is considered to be only observable either just before or just after the changes embodied by a step were performed. A step also carries data such as a name (e.g., "fire" step for when a transition is fired, "call" step for when a method is called) and data on the elements involved in a step (e.g., the transition that was fired, the method that was called). A step can be composite, in which case the only changes it carries are those of its children steps. Execution steps are produced at runtime by the interpretation rules of the DSL, and can be used as input data by runtime services (e.g., monitoring, tracing, interactive debugging) to observe the execution progress. The possible execution steps of an interpreted DSL can be defined in various ways, e.g., by considering that each interpretation rule produces a kind of step, or by defining step types in a separate model.

To summarize, the interpreted DSLs considered in the scope of this paper can be defined in the following way: Definition 2. An interpreted DSL is defined by the following elements: (1) An abstract syntax, that is a metamodel. (2) An operational semantics (or interpreter), with: a) A model state definition, b) A set of interpretation rules, c) A definition of execution steps that are produced by the interpretation rules. Figure 1 shows an example of a interpreted Petri nets DSL. Next to the abstract syntax-described in Section II-Athe model state definition is shown. It is a metamodel that extends the metaclass Place using package merge with a new dynamic property tokens. At the right, short descriptions of the interpretation rules are depicted. When called, these rules change the tokens fields of the different Place objects, with run being the entry point of the execution. Each rule defines a kind of step, e.g., an application of the fire rule produces a step called "fire" pointing to the Transition that was fired. When applied, the fire rule consumes tokens from all input Place elements of a given Transition, and produces tokens in all its output Place elements.

Lastly, executing a model conforming to an interpreted DSL consists in creating an initial state, and in running the interpretation rules that will both change this state over time and produce steps. We call observation point an instant in the execution reached just before or just after each step.

Figure 2 presents an execution trace of a Petri net conforming to the Petri net interpreted DSL shown in Figure 1. The trace is composed of four model states (from A to D), on top of which the steps of the execution are depicted as arrows. Three steps where produced by the applications of the fire step rule. They are enclosed in a larger step that goes from the first model state (A) to the last model state (D), which is the application of the run rule. The possible observation points (from 1 to 6) are depicted in diamond shapes.

C. Compiled DSL

A compiled DSL is based on a translational semantics, i.e., a model transformation from the abstract syntax of the considered DSL, to the abstract syntax of another executable target language. As compared to an interpreted DSL, a compiled DSL does not explicitly define how the execution is : while there is an enabled transition, fires it. : removes a token from each input Place and adds one to each output Place. performed in terms of states and steps of the source domain, and relies instead on the execution of target models obtained after compilation. In summary, the compiled DSLs considered in the scope of this paper are defined as follows:

* transitions

Definition 3. A compiled DSL is composed of: (1) An abstract syntax, that is a metamodel. (2) A translational semantics (or compiler), that is a model transformation from the abstract syntax of the compiled DSL, to the abstract syntax of another executable language.

Figure 3 shows an example of an Activity Diagram compiled DSL which uses the Petri nets DSL from Figure 1 as a target language. This example is a simplified version of the part of fUML [START_REF] Wimmer | Semantics of a Foundational Subset for Executable UML Models[END_REF] related to the control flow of activities. The proposed translational semantics is inspired from several approaches aiming at translating UML activities and process models to Petri nets [START_REF] Syriani | Operational semantics of UML activity diagram: An application in project management[END_REF], [START_REF] Staines | Intuitive Mapping of UML 2 Activity Diagrams into Fundamental Modeling Concept Petri Net Diagrams and Colored Petri Nets[END_REF]. At the top, the abstract syntax defines an Activity as a set of inter-connected Node and Edge objects, with several types of nodes. InitialNode and FinalNode mark the beginning and the end of the Activity. A ForkNode starts concurrent execution branches, which can be joined back in a JoinNode. An Action represents an opaque action realized in the process. The semantics of activities are based on a token flow, which we summarize below with an example. Figure 4 shows an example of Activity. Init is an InitialNode, which creates the initial token, and End is a FinalNode. Next, e1-e7 are Edge elements, and receive tokens offered by their source Node elements. If there are offered tokens on all its incoming edges, a Node takes the tokens and offers new ones to its outgoing edges. A,B and C are Action nodes, F is a ForkNode, and J is a JoinNode. Figure 5 shows the Petri net model obtained after compiling the activity shown in Figure 4.

Finally, executing a model conforming to a compiled DSL is the compilation of this model into a model conforming to the target language, and the execution of the obtained model.

III. OVERVIEW

This section shows an overview of the proposed architecture. The idea is to observe the execution of the target model obtained by compilation, and translate target states and steps back to the source domain. Figure 6 depicts this architecture.

a) Assumptions: The compiled DSL follows the definition given in Section II-C, hence it is metamodel-based, with a compiler defined as a model transformation. Second, the target language is a metamodel-based interpreted language1 that follows the definition given in Section II-B. Thus, the target language is able to produce execution steps that can then be sent to runtime services (e.g., trace construction, interactive debugging) attached to the execution. These steps are sent in a synchronous fashion, which means that attached services may safely observe (e.g., access the model state) and control the execution (e.g., pause the thread) when informed of starting or ending steps. Consequently, we only focus on single-threaded executions. Note that while both source and target languages are depicted here in the same metamodel-based technical space, the presented architecture can be adapted for target languages that are not metamodel-based, as long as target execution steps can be observed synchronously and as long as the target execution state is observable. b) Compilation: At the top of Figure 6, the compilation follows what was presented in Section II-C. On the left, the considered source DSL is based on a compiler relying on the DSL abstract syntax. The compiler produces a target model conforming to the abstract syntax of the target language, shown on the right. The architecture also requires the compiler to produce a set of compilation links a conforming to a traceability metamodel. This part is described in Section IV-A.

Compilation Results

Runtime services

Target

Target Engine Feedback Engine

c) Compiled DSL with Feedback Management: On the left, to provide feedback to the source model, the considered compiled DSL is supplemented with three additional parts. d) Execution with Feedback: On the right, the interpreter of the target language is used to execute the target model, which consists in modifying the target model state and in producing target steps. These target steps must then be sent to the feedback manager-or any other runtime service attached to the execution of the target model-to be translated into source execution steps and states. For this purpose, a component called the target execution engine receives target execution steps produced by the target interpreter, and transmit them to all runtime services attached to the execution. The feedback manager is considered to be a specific runtime service attached to the target executing engine, and as such can continuously receive all produced execution steps to perform its tasks. Lastly, a second execution engine called the feedback engine e is responsible for listening to the feedback manager, and for relaying notifications to runtime services attached at the source compiled DSL level. Thereby, for instance, an interactive debugger can be attached to the feedback engine in order to debug the source model at the domain-level during the execution. This part is described in Section IV-E.

IV. COMPILED DSL ARCHITECTURE

This section presents each part of the proposed architecture: first the management of traceability, then the definition of source states and steps, and lastly the feedback manager.

A. Compilation and Traceability Management

In Section II-C, we defined the main constituents of a compiled DSL. However, our approach requires that a com- piler not only produces a target model, but also produces a set of compilation links (labeled a in Figure 6), i.e., a traceability model that relates produced target elements to their originating source elements. This is required in later stages to be able to relate execution states and steps of the target model back to the source model. We require a traceability metamodel allowing both many-to-many links and annotations to uniquely identify the elements in a many-tomany traceability link. Figure 7 shows one possible generic traceability metamodel that satisfies this constraint, where each Link element connects source objects of the source model and target objects of the target model. Annotations can be used to distinguish elements and links as necessary. Figure 8 shows an example of traceability model produced by the compilation of a simple activity diagram. The source Action A is connected to two Transition elements: one annotated "take" since it represents the incoming edge of an action used for taking nodes from preceding nodes, and one annotated "offer" since it represents the outgoing edge of an action used for offering tokens to successive nodes.

B. Source Model State Definition

A compiled DSL is mostly defined by a compiler, while everything related to execution is delegated to the target language. Yet, observing the execution of a model requires an access its state as it changes. It is therefore necessary to define the possible states of models conforming to a compiled DSL. For interpreted DSLs, possible states are defined by the model state definition which extends the abstract syntax of the DSL with dynamic properties and metaclasses. Following this idea, our architecture extends a compiled DSL with a model state definition of its own (labeled b in Figure 6).

Figure 9 shows the model state definition for the activity diagram compiled DSL introduced in Figure 3. Using a package merge, it extends the abstract syntax of the DSL with a new dynamic metaclass Token, and extends the two metaclasses Node and Edge with a dynamic property heldTokens using a common super type TokenHolder. In other words, at a given instant, the nodes of an activity may hold tokens, and edges may contain tokens offered by their source nodes.

C. Source Execution Steps Definition

While adding a model state definition to a compiled DSL is required for observing the state of a compiled model (e.g., to know where tokens can be found in the model), observing and controlling the execution of the model also requires knowing about the execution steps that occur in the model (e.g., which Following this idea, our architecture extends a compiled DSL with a steps definition of its own (labeled c in Figure 6). While the possible execution steps of an interpreted DSL can notably be declared through dedicated interpretation rules, a compiled DSL requires a formalism to explicitly declare its possible source execution steps. For that purpose, the top right corner of Figure 10 shows a simple step definition metamodel that can be used to define the possible execution steps of a DSL (note: the left and middle parts of Figure 10 are described in Section IV-D). A StepDefinition defines one type of execution steps through a name and a set of StepParameter elements. A StepParameter also has a name and is typed either by a Metaclass-from the abstract syntax or from the model state definition-or by a PrimitiveType (e.g., Integer, String).

As an example, for the activity diagram compiled DSL introduced in Figure 3, we consider the following source StepDefinition elements, each with the type of its single Step-Parameter shown between parentheses: offer(Node) for the offering of tokens of a Node to the outgoing edges of the Node; take(Node) for the taking of tokens by a Node from the incoming edges of the Node; executeNode(Node) for the taking and offering of tokens by a Node, i.e., a composite step containing both an offer step and a take step; executeActivity(Activity) for the execution of the Activity until no tokens can be offered or taken, i.e., a composite step containing executeNode steps.

D. Feedback Manager

The feedback manager is responsible of translating states and steps of the target model back to the source model. Feedback management is specific to the compiled DSL: only the language engineer knows how target steps and states should be translated to source states and steps. This approach offers to concentrate this knowledge in a manually defined feedback manager (labeled d in Figure 6) specific to the considered compiled DSL.

The feedback manager must be informed of starting and ending target steps, and it has to react to such steps by changing the source model state and creating corresponding source execution steps. Furthermore, it requires access to the generated execution links. A feedback manager can be divided into the following services that must be called at the start and at the end of target execution steps:

• feedbackState: Update the source model state based on the set of changes applied on the target model state in the last target execution step. For efficiency reasons, change notifications such as those provided by the Eclipse Modeling Framework (EMF) [START_REF] Steinberg | EMF: Eclipse Modeling Framework, 2nd Edition, ser. Eclipse Series[END_REF] can be used for determining target model changes.

• processTargetStepStart: Translate a target starting step into source steps. Depending on the correspondences between target steps and source steps, it may produce zero, one or several source steps. • processTargetStepEnd: Translate a target ending step into source steps. Again, depending on the correspondences between target steps and source steps, it may produce zero, one or several source steps.

Based on the runtime step metamodel shown in the middle of Figure 10,a StepStart element is produced when an execution step starts, and references both a StepDefinition from the execution steps definition of the DSL (e.g., the rule fire from Figure 1), and a set of parameters (e.g., a reference to the Transition that was fired). A StepEnd element is produced when an execution step ends, and references both the StepStart of the step that is ending, and the set of Object elements from the model state that changed during this step.

We present in what follows a possible feedback manager for the activity diagram compiled DSL shown in Figure 3. Regarding the feedback of states, the tokens in each target Petri net Place must be translated back into Tokens objects in source TokenHolder elements. Regarding the feedback of steps, we consider the following mapping: (1) executeActivity is translated back from the corresponding run target step.

(2) offer is translated back from the corresponding fire target step. (3) take is translated back from the corresponding fire target step. (4) executeNode is translated back from one or two fire target steps, based on the kind of Node.

For the pseudo-code we assume that the following operations are available: (1) getLinkEnd retrieves from the traceability model the LinkEnd corresponding to an object;

(2) createStepStart produces a source StepStart by retrieving the required StepDefinition, and pushes this StepStart object atop an internal stack; (3) createStepEnd produces a source StepEnd object, then retrieves and remove the latest StepStart pushed atop the internal stack and assigns it to the StepEnd, then retrieves all objects that have changed in the model state since the last call to createStepEnd and assign them to the StepEnd. (4) stepStart and stepEnd transmit source steps to the feedback engine, which itself relays source steps to attached runtime services (e.g., an interactive debugger). The feedback engine is explained in more details in Section IV-E. First, Algorithm 1 shows the definition of the feedbackState service, which creates or deletes Token elements in the source model state, based on the amount of tokens in the changed Place elements in the target model state.

Second, Algorithm 2 shows the definition of the processTar-getStepStart service. If a target Petri net run step is starting for a Net element, then an activity diagram executeActivity step is sent as feedback. This feedback requires the Activity element from which the Net was created, which is found using the traceability links. In the case of a starting fire target step, the feedback depends on which Petri net Transition is (or was) fired, based on the annotations in the execution links. If the annotation is "take" (i.e., a Transition is fired that was created for the incoming edge of an activity Node), the feedback consists in first starting an executeNode source step for the corresponding Node. Then, a take source step for the same Node is sent. If the annotation is "offer" (i.e., a Transition is fired that was created for the outgoing edge of an activity Node), we only start an executeNode in the case of a starting InitialNode, and we always feedback an offer source step. Third, Algorithm 3 shows the definition of the processTar-getStepEnd service. If a target Petri net run step is ending, then we end the current source executeActivity step. In the case of an ending fire target step, we must again handle two cases. If the annotation is "take", we end the current source take step. We also end the current source executeNode step if we are in a FinalNode, as such a node will not offer tokens afterwards. If the annotation is "offer", we first end the current source offer step, then we end the current source executeNode step.

E. Feedback Management Integration

Lastly, the feedback manager must be integrated with the interpreter of the target language, i.e., it must be notified when execution steps start and end. In addition, it must be possible to attach runtime services to the compiled DSLs, so that they can benefit from the reconstructed source states and steps.

a) Engines and Runtime Services: For this integration, our approach relies on our previous work [START_REF] Bousse | Omniscient debugging for executable DSLs[END_REF] to ease the sharing of runtime services among a wide range of executable DSLs. The main principles can be summarized as follows:

• An execution engine is responsible for running the interpreter of the DSL. The engine is aware of executions step produced by the interpreter, which may require instrumenting the interpreter to realize callbacks to the engine. An engine is specific to the approach used to define an interpreter (e.g., an engine for Java interpreters can rely on code instrumentation to be notified of occuring steps). • A runtime service can be attached to an execution engine, and receives notifications when execution steps start or end. It also has access to the executed model. Notifications are sent in a synchronous way, hence the execution is suspended while a notification is being processed by a runtime service. These opportunities can be used to safely control the execution (i.e., pause the thread) or safely observe it (e.g., access the state) in between steps. These roles make it simpler to define runtime services independent of interpreted DSLs, and independent of the way their interpreters are defined. For instance, we have previously defined a complete omniscient debugger as a generic runtime service that provides a complete set of debugging services to any interpreted DSL. Without changing a single line of its code, this runtime service can be used with different interpreted DSLs defined using different metaprogramming approaches (e.g., xMOF [START_REF] Mayerhofer | xMOF: Executable DSMLs based on fUML[END_REF], Kermeta [START_REF] Jézéquel | Mashup of metalanguages and its implementation in the Kermeta language workbench[END_REF], Moccml [START_REF] Deantoni | Towards a Meta-Language for the Concurrency Concern in DSLs[END_REF]).

b) Integrating Feedback Management with Engines: For the proposed compiled DSL architecture, we rely on execution engines in two ways. First, the feedback manager is defined as a runtime service attached to the target language's execution engine. Thereby, the feedback manager triggers the processTargetStepStart service when notified by the target engine with a StepStart, and triggers both the feedbackState and processTargetStepEnd services when notified with a StepEnd.

Second, we define a so-called feedback engine (labeled e in Figure 6) as a generic execution engine responsible for executing models conforming to compiled DSLs. Instead of running an interpreter, this engine receives source execution steps produced by the feedback manager of the compiled DSL, and relays these source steps to runtime services attached to the source model execution. Being an engine, it can directly benefit from any runtime service, including services originally meant for interpreted DSLs.

F. Example of Execution with Feedback

To illustrate how our architecture unfolds, we present the execution of the activity introduced at the top of Figure 8, which is compiled into the Petri net shown at the bottom.

Figure 11 shows the execution traces resulting from the execution. At the top, the execution of the target Petri net is shown. It directly results from the application of the interpretation rules introduced in Figure 1, which means that the execution is enclosed in a run(Net) step, which itself contains a sequence of fire(Transition) steps for each Transition. Note that this Petri net execution is completely hidden from the runtime services connected to the feedback engine.

At the bottom, the execution of the source activity is shown, which directly results from the use of the example feedback manager presented in Section IV-D. This trace reflects the execution that can be observed by runtime services connected to the feedback engine. The step executeActivity(activity) corresponds to the target step run(net) according to the definition of the processTargetStepStart and processTargetStepEnd operations (see Algorithm 2 lines 2-5, and Algorithm 3 lines 2-3). Each offer(Node) step corresponds to a target fire(Transition) if this target step concerns a Transition representing the outgoing edge of an activity Node (see Algorithm 2 lines 14-17, and Algorithm 3 lines 12-13). Similarly, each step take(Node) corresponds to a target step fire(Transition) if it concerns a Transition representing the incoming edge of an activity Node (see Algorithm 2 lines 11-13, and Algorithm 3 lines 8-9). In addition, an executeNode(Node) encloses the offer(Node) and take(Node) steps of each Node (see Algorithm 2 lines 12 and 16, and Algorithm 3 lines 11 and 14).

G. Implementation

We have implemented common parts of the approach (e.g., the feedback engine) for the GEMOC Studio [START_REF] Bousse | Execution Framework of the GEMOC Studio (Tool Demo)[END_REF], an Eclipse package composed of a language workbench and a modeling workbench. The language workbench relies on Ecore for defining abstract syntaxes, and provides multiple languages (e.g., Kermeta [START_REF] Jézéquel | Mashup of metalanguages and its implementation in the Kermeta language workbench[END_REF], xMOF [START_REF] Mayerhofer | xMOF: Executable DSMLs based on fUML[END_REF], etc.) for defining operational semantics. The modeling workbench is an environment for creating, executing and debugging models, and provides one execution engine per supported kind of operational semantics.

Originally, the GEMOC Studio focused on providing facilities to design and implement interpreted DSLs. Hence, our approach is the first attempt to support compiled DSLs in the GEMOC Studio. The source code is available on Github 2 and consists in Eclipse plugins written in Xtend and Java.

V. EVALUATION

We considered the following research questions, each matching one of the challenges stated in the introduction: RQ#1: Given an interpreted DSL and a compiled DSL with trace-equivalent semantics, does the approach make it possible to observe the same traces with both DSLs?

RQ#2: Does the approach enable the use of runtime services at the domain-level of compiled DSLs? In particular, (2.1) Can different sorts of runtime services be used? (2.2) Can the same runtime services be shared across both interpreted and compiled DSLs?

RQ#3: What is the time overhead when executing compiled models with feedback management? In particular, how does it compare to: (3.1) executing without feedback management? (3.2) executing with an interpreter?

2 https://github.com/tetrabox/gemoc-compilation-engine

A. Setup

Using the implementation presented in Section IV-G, the evaluation was made using the GEMOC Studio. We used this environment both for implementing the required DSLs and for executing the models. All material used for the evaluation can be found in the repository 2 . We describe the artifacts below.

1) Languages: Our evaluation relies on two different compiled DSLs: the fUML subset presented throughout the paper using Petri nets as a target language, and a subset of UML state machines implemented as a standalone DSL using a subset of Java as a target language. We reimplemented a subset of Java as MiniJava in order to have a metamodel-based objectoriented programming language that fits the requirements of our approach, and that can be used for transforming UML state machines into Java following the state design pattern.

Below we first describe common points between both studied DSLs. We then describe in more detail the UML state machines DSL, while we do not describe the fUML activity diagram DSL as it was already presented in the paper.

a) Common points: The fUML activity diagram DSL and the UML state machine diagram DSL were both defined in two flavors: one compiled version, and one interpreted version. Both share the same abstract syntax defined using Ecore. For the compiled versions, both the compiler and the feedback manager were defined using Xtend. All interpreters were defined using Kermeta [START_REF] Jézéquel | Mashup of metalanguages and its implementation in the Kermeta language workbench[END_REF]. The semantics of the interpreted and of the compiled versions are designed to be trace-equivalent.

b) UML state machines compiled DSL: For the second compiled DSL, we considered a subset of UML state machines where a conforming model contains a single StateMachine with a single Region, which contains one initial State, one FinalState and arbitrary many regular State elements. All nodes are connected using Transition elements, each with at least

B. Conducted Experiments and Results

a) RQ #1 (same observations): We have executed each of the 130 generated models with both the interpreted and the compiled versions of both executable DSLs, and captured one domain-level trace per execution. For compiled DSLs, the feedback manager was used for domain-level observation to construct traces. We automatically compared each trace from an interpreted execution with the corresponding trace from a compiled execution, and did not find any differences.

To summarize and answer RQ #1, the approach makes it possible to observe the exact same executions with both interpreted and compiled versions of a DSL.

b) RQ #2 (runtime services): We were able to use both the trace constructor and the omniscient debugger with both the interpreted and compiled versions of each considered DSL, without changing a single line of the services' code. For example, when the omniscient debugger is used with the activity diagram DSL, it is able to pause on a breakpoint defined in the activity, to show the active node, to display a view of all domain-level variables (i.e., the held tokens), and to display a stack of ongoing domain-level execution steps. The underlying executed Petri net is invisible to the modeler.

To summarize and answer RQ #2, the approach does enable the use of different sorts of runtime services, which can be shared among both interpreted and compiled DSLs. c) RQ #3 (overhead): Using Java's System.nanotime, we measured the duration when executing each of the models of each of the DSLs using: (1) the compiled version of the DSL with the feedback manager; (2) the compiled version of the DSL without the feedback manager; (3) the interpreted version of the DSL. Each execution was done 25 times, starting with 14 warmups (i.e., without measuring). The retained value is then the median of the remaining 11 measured durations.

Figure 13a shows the collected results for the fUML activity diagram DSL. We observe that the fastest executions are the ones from the compiled version of the DSL without the feedback manager, i.e., from the Petri net interpreter alone. When adding the feedback manager, the execution time is on average multiplied by 2, i.e., the execution takes twice the time. In both cases, the execution times seem to grow linearly with the number of execution steps. The interpreted version of the DSL is on average 1,6 times slower compared to the compiled DSL without feedback management.

Figure 13b shows the results for the UML state machines DSL. Here we observe that the interpreted version of the DSL is the fastest, which is explained by lack of optimizations within the MiniJava interpreter, which makes the compiled version much slower. When using the feedback manager with the compiled version, the execution time is on average only multiplied by 1,01, i.e., the execution time is increased by 1%.

To summarize and answer RQ #3, we observe that when using a feedback manager with a compiled DSL, execution times are multiplied by 1,01 with UML state machines, and by 2 with fUML activity diagrams. If we consider the overhead categorizations proposed by Maplesden etal. [START_REF] Maplesden | Performance Analysis for Object-Oriented Software: A systematic mapping[END_REF], these two numbers respectively match the "Very Low overhead" category, and the lowest bound of the "High overhead" category. While we consider these slowdowns acceptableonly a few milliseconds of absolute overhead in average in both cases-this discrepancy suggests that the overhead may not be inherent to the architecture itself, and may instead be dependent on how the feedback manager is implemented.

C. Threats to Validity

First, the evaluation was made using only two compiled DSLs, thus it does not show whether similar results would be obtained with yet another different compiled DSL. To mitigate this problem, we chose cases with very different target DSLs, hence with very different semantic gaps between source and target languages. Applying the architecture on more cases is one of the ongoing next steps of our work. Second, as we already mentioned, the comparison of execution times between the interpreted and compiled versions of the considered DSLs may not be fair due to discrepancies in the optimizations of the source or target interpreters. For this reason, we did not include these results as part of the answer given to the research question, and only provide them as an interesting observation. Lastly, we considered generated models instead of models from a real world source. This is partly compensated by the considerable amount of models we generated.

VI. RELATED WORK a) Back-tracing verification results: When the translational semantics of a DSL are defined to target a formal language with model checking tool-support, counter-examples produced by the model checker are not expressed with the DSL concepts. Hence, many back-tracing approaches aim at translating such counter-examples back to the source domain [START_REF] Combemale | A Generic Tool for Tracing Executions Back to a DSML's Operational Semantics[END_REF]- [START_REF] Haberl | Model-Level Debugging of Embedded Real-Time Systems[END_REF]. However, these techniques focus on translating back execution traces obtained after execution (e.g., counterexamples given by analysis tools), while our approach provides observation and control during the execution, b) Monitoring and debugging for compiled DSLs: Several approaches aim at supporting domain-level debugging or monitoring for compiled DSLs, which always imply some form of observation or control over the execution. Wu et al. [START_REF] Wu | Grammar-driven Generation of Domain-specific Language Debuggers[END_REF] propose a generative approach focusing on grammarbased compiled DSLs, where the lines of the source program are mapped to the lines of the target program, in order to map domain-level debugging actions to the existing target debugger. Still for grammar-based compiled DSLs, Lindeman et al. [START_REF] Lindeman | Declaratively Defining Domain-specific Language Debuggers[END_REF] proposes a similar approach were the source DSL program is instrumented with debug information. In the context of extensible languages, Pavletic et al. [START_REF] Pavletic | Extensible Debugger Framework for Extensible Languages[END_REF] proposes a framework to define and extend debuggers. Das et al. [START_REF] Das | Supporting the Model-driven Development of Real-time Embedded Systems with Run-time Monitoring and Animation via Highly Customizable Code Generation[END_REF] describe a framework to monitor at the domain-level the execution of models that were compiled to code, with a strong focus on UML-RT. Yet, all these approaches focus on specific runtime services, while our approach aim to lay the foundations for defining and using of any kind of runtime service for metamodel-based compiled DSLs.

VII. CONCLUSION AND FUTURE WORK

Observing and controlling the execution of models conforming to a compiled DSL is a difficult task, due to the semantic gap between the considered source and target languages. We addressed this problem through a generic approach to provide feedback management for compiled DSLs. The direct perspectives of this work include: studying how the feedback manager materializes a weak bisimulation relation [START_REF] Combemale | A Generic Tool for Tracing Executions Back to a DSML's Operational Semantics[END_REF], [START_REF] Combemale | Essay on Semantics Definition in MDE -An Instrumented Approach for Model Verification[END_REF] between the source and target languages; handling compiled DSLs defined through a code generator instead of a model transformation; providing an easier way to define the feedback manager (e.g., using a dedicated DSL, similarly to [START_REF] Zalila | A DSL to Feedback Formal Verification Results[END_REF]); managing the stimuli sent to the source model during the execution, by translating them to stimuli for the target model; and measuring the amount of effort required to define a feedback manager as compared to defining an interpreter.

Figure 1 :Figure 2 :

 12 Figure 1: Petri nets interpreted DSL

Figure 3 :

 3 Figure 3: Activity Diagram compiled DSL, which uses the Petri net DSL shown in Figure 1 as a target language

Figure 4 :

 4 Figure 4: Example of an activity conforming to the compiled DSL shown in Figure 3.

Figure 5 :

 5 Figure 5: Petri net produced by the compilation of the activity from Figure 4, conforming to the interpreted DSL from Figure 1.

Figure 6 :

 6 Figure 6: Overview of the architecture.

  First, a source model state definition b is required to define what are the possible states of the source domain. Second, a source execution steps definition c must define what are the possible execution steps of the source domain. Third, the feedback manager d is responsible for translating execution steps occurring in the target model into execution steps occurring in the source model, and for updating the source model's state accordingly. These three parts are at the core of the architecture for defining compiled DSLs proposed in this work, and are described in Sections IV-B, IV-C and IV-D.

TraceabilityModelFigure 7 :

 7 Figure 7: Generic traceability metamodel

Figure 8 :

 8 Figure 8: Example of activity compiled to a Petri net, with a traceability model. Each gray triangle represents a Link.

Figure 9 :

 9 Figure 9: Activity diagram model state definition, added to the DSL to define the states of conforming models.

Figure 10 :

 10 Figure 10: Step definition metamodel, and runtime step metamodel. The subtypes of PrimitiveValue are not shown.

Algorithm 3 : 2 if

 32 Example of processTargetStepEnd definition for the activity diagram compiled DSL Input: stepEnd t : the target StepEnd object to process links : the compilation links engine f : the feedback engine 1 begin stepEnd t .start.definition.name = "run" then 3 engine f .stepEnd(createStepEnd()) 4 else if stepEnd t .start.definition.name = "fire" then 5 transition ← stepEnd t .params [0].object 6 linkEnd ← getLinkEnd (transition,links) 7 annotation ← linkEnd.annotation 8 if annotation = "take" then 9 engine f .stepEnd(createStepEnd()) 10 if node is FinalNode then 11 engine f .stepEnd(createStepEnd()) 12 else if annotation = "offer" then 13 engine f .stepEnd(createStepEnd()) 14 engine f .stepEnd(createStepEnd())

Figure 11 :

 11 Figure 11: Execution traces resulting from the execution of the models shown in Figure 8, after connecting the feedback manager of the activity diagram DSL to the Petri net interpreter. Refer to Figure 2 for the legend.

  fUML activity diagram DSL, compiled to Petri nets. feedback interpreted (b) UML state machines DSL, compiled to MiniJava.

Figure 13 :

 13 Figure 13: Execution times in three cases: compiled with feedback, compiled without feedback, and interpreted.

run(Net) fire(Transition)

	Abstract Syntax
	Place places * name: String initialTokens: Integer	input Net 1..* output 1..*	Transition name: String	merges	Model State Definition Place tokens: Integer	imports	Interpretation rules (summarized)

Activity Edge Action ForkNode JoinNode InitialNode FinalNode <<abstract>> NamedElement

	AD abstract syntax
				nodes	edges
				*	*
		+name: String	<<abstract>>
				Node	source	outgoing
					1	*
					target	incoming
					1	*
					imports
	Petri nets abstract syntax	imports	... transformActivity(Activity) transformEdge(Edge) transformAction(Action)	: Creates a Net : Creates a Place : Creates a Place and two Transitions
					Compiler (summarized)

Language Source Language

	Compiler
	Source Abstract Syntax	Source Model	Compilation Links	Target Model	Target Abstract Syntax
	Source Model State Definition	Source State	Tracer	Target State	Target Model State Definition
			Debugger
	Source Execution Steps Definition	Source Steps Source Steps	...	Steps Steps Target Source	Target Execution Steps Definition
	Feedback				Interpretation
	Manager				Rules

Algorithm 1 :

 1 Example of feedbackState definition for the activity diagram compiled DSL

		Input:
		stepEnd t : the target StepEnd object to process
		links : the execution links
	1 begin
	2	changed ← stepEnd t .changedObjects
	3	foreach place ∈ changed do
	4	tokenHolder ← getLinkEnd(place).link.source[0].object
	5	diff ← place.tokens -size(tokenHolder.heldTokens)
	6	for i ← 1; i≤ |diff |; i ← i + 1 do
	7	if diff > 0 then
	8	tokenHolder.heldTokens.add(createObject(Token))
	9	else
	10	tokenHolder.heldTokens.remove(source.heldTokens[0])
	Algorithm 2: Example of processTargetStepStart def-
	inition for the activity diagram compiled DSL
		Input:
		stepStart t : the target StepStart object to process
		links : the compilation links
		engine f : the feedback engine
		stepsDef s : the source execution steps definition
	1 begin
	2	if stepStart t .definition.name = "run" then
	3	net ← stepStart t .params [0].object
	4	act ← getLinkEnd (net,links).link.source [0].object
	5	engine f .stepStart (createStepStart (stepsDef s ,"executeActivity", [act]))

6 else if stepStart t .definition.name = "fire" then 7 transition ← stepStart t .params [0].object 8 linkEnd ← getLinkEnd (transition,links) 9 annotation ← linkEnd.annotation 10 node ← linkEnd.link.source [0].object 11 if annotation = "take" then 12 engine f .stepStart (createStepStart (stepsDef s ,"executeNode", [node])) 13 engine f .stepStart (createStepStart (stepsDef s ,"take", [node])) 14 else if annotation = "offer" then 15 if node is InitialNode then 16 engine f .stepStart (createStepStart (stepsDef s ,"executeNode", [node])) 17 engine f .stepStart (createStepStart (stepsDef s ,"offer", [node]))

  Target Petri net execution trace. This execution is hidden from runtime services connected to the activity diagram execution. Source activity diagram execution trace, obtained using the feedback manager, based on the Petri net execution shown above. This shows what can be observed by runtime services connected to the activity diagram execution, i.e., at the source domain level.

					fire(Init_offer)										fire(A_offer)			fire(End_take)
								3						4						5	6	7
	Init_offer	A_take	A_offer	End_take	Init_offer	A_take	A_offer	End_take	Init_offer	A_take		A_offer	End_take	Init_offer	A_take	A_offer	End_take	Init_offer	A_take	A_offer	End_take
	Init_node	e1_edge	A_node	e2_edge	Init_node	e1_edge	A_node		e2_edge	Init_node	e1_edge	A_node	e2_edge	Init_node	e1_edge	A_node	e2_edge	Init_node	e1_edge	A_node	e2_edge
	executeNode(Init) (a) take(A) executeActivity(activity) executeNode(A) offer(Init) offer(A)				executeNode(End) take(End)
	I	II.1	II.2		III.1	III.2		III.3			IV			V.1	V.2	V.3	VI.1	VI.2	VII
	e1	A	e2			e1	A	e2			e1	A	e2			e1	A	e2	e1	A	e2
	Init			End		Init					End	Init					End	Init			End	Init	End
	(b)

Note that the target language may also be compiled as long as it follows the presented approach, i.e., it is possible to chain the application of our approach. For clarity, we always describe the target language as an interpreted language.

http://www.cambridge.org/resources/052182060X/

https://github.com/tetrabox/minijava machines with sizes ranging from 10 to 100 states, and 3 scenarios per state machine, thus for a total of 90 different combinations of {UML state machine, scenario}.

ACKNOWLEDGEMENT This work is partially funded by the Austrian Science Fund (FWF) under the grant numbers P 30525-N31 and P 28519, by the Austrian Federal Ministry for Digital and Economic Affairs and the National Foundation for Research, Technology and Development, and by the French project ELOGE (Atlanstic 2020 Amorçage) financed by Région des Pays de la Loire.

one Trigger referencing an Event, without any guards. The target language is an interpreted DSL called MiniJava that was inspired by an educational language of the same name 3 that we made available on GitHub 4 . It supports a subset of Java that includes classes, interfaces, methods, a subset of primitive types, and a subset of expressions. The Xtext textual concrete syntax is identical to Java, and a MiniJava program is always a valid Java program that compiles and runs with the same behavior. The UML state machine compiler we developed is based on the well-known state design pattern from Gamma et al. [START_REF] Gamma | Design Patterns: Elements of Reusable Object-oriented Software[END_REF], which describes how to implement a state machine as an object-oriented program. Figure 12 shows an example of a source UML state machine model and the target MiniJava program resulting from its compilation. We applied and wrote a definition of states, a definition of steps, and a feedback manager for MiniJava.

2) Runtime Services and Tracing: To answer RQ #2, we considered two runtime services provided in the GEMOC Studio: a trace constructor (described in [START_REF] Bousse | Advanced and efficient execution trace management for executable domainspecific modeling languages[END_REF]) and an omniscient debugger (described in [START_REF] Bousse | Omniscient debugging for executable DSLs[END_REF]). While these services were originally designed for interpreted DSLs, our approach makes compiled DSLs seemingly indistinguishable from interpreted DSLs. Hence, our experiment consists in reusing these services with compiled DSLs without changing a line of their code.

3) Models: To answer RQ #1 and RQ #3, which require executing models, we have implemented both a random activity diagram generator and a random state machine generator. Both generators are by a fixed amount of nodes to create, and always create valid models where the final node of the model can be reached. We generated 30 UML state


Some remarks on correlations between conflict and instability

P.


Emmanuel Lerayer

Patrice Renaut

Julien Roger

Nadine Pirio

Hélène Cattey

Paul Fleurat-Lessard

Maxime Boudjelel

Stéphane Massou

Ghenwa Bouhadir

Didier Bourissou

A sterically congested 1,2-diphosphino-1'-boryl-ferrocene: synthesis, characterization and coordination to platinum

A new class of tritopic ferrocene-based ambiphilic compound has been prepared by assembling diphosphino-and borylsubstituted cyclopentadienides at iron. The presence of five 10 sterically demanding substituents on the ferrocene platform induces conformation constraints, as apparent from XRD and NMR data, but does not prevent chelating coordination to platinum. The Lewis acid moiety is pendant in both the free ligand and the platinum complex.

15 Ambiphilic compounds combine Lewis acids and Lewis bases on a common platform. 1 When strong donor-acceptor interaction between these antagonist moieties is prevented sterically and/or geometrically, their juxtaposition opens great opportunities in small molecule activation and ultimately metal-free catalysis (so-20 called frustrated Lewis Pair -FLP-catalysis), 2 as well as in coordination chemistry and metal/Lewis acid cooperativity. 3 Various scaffolds have been used to build ambiphilic compounds. In particular, C2 spacers have attracted great interest due to the proximity they impart to the antagonist sites, while 25 enabling to tailor rigidity (cf. ortho-C 6 H 4 , CH=CH, CH 2 -CH 2 bridges). Due to its unique and versatile properties, the ferrocene platform is also very appealing and over the years, an increasing variety of ferrocene-based ambiphilic compounds have been described (Figure 1). Most studies have focused to date on 30 monophosphine-boranes, in which the relative position of the phosphorus and boron atoms have been varied (see compounds A-D). [4][5][6][7][8] A few tritopic compounds have also been reported. Landis and co-workers studied early on compounds E in which a pendant benzoxaborolidine moiety was appended to a 1,1'- To take advantage of possible cooperativity between neighbouring sites we became interested in ambiphilic compounds featuring three or more functional groups directly bonded to the ferrocene platform. To our knowledge, only one such compound was reported to date: the 1-phosphino-1',3'-45 diboryl ferrocene G that was prepared by Clark and co-workers via direct iridium-catalysed C-H borylation of (diphenylphosphino)ferrocene. 11 The stepwise introduction of phosphino and boryl groups on ferrocene is tedious and inherently complicated by compatibility/selectivity issues.

50 Reacting pre-functionalized cyclopentadienides with iron dichloride is more convergent and might be synthetically attractive. This assembling methodology proved to be very efficient for the preparation of polyphosphines such as the 1,2,1'triphosphino-ferrocenes H. 12 In such tritopic compounds the two 55 bulky t-Bu groups exert conformational control and maintain the phosphorus atoms in close proximity, resulting in unique coordinating properties towards transition metals, as well as rare "through-space" nuclear spin-spin couplings. 13 Recently, we extended this assembling strategy to the preparation of 1,1'-60 diboryl ferrocenes I (and related cobaltocenes) from borylsubstituted cyclopentadienides. 14,[START_REF] Herberich | For pioneering work on non-substituted borylcyclopentadienides[END_REF] These advances prompted us to test the same approach for the preparation of hitherto unknown 1,2-diphosphino-1'-boryl-ferrocenes. In this context, we report here the preparation and full characterization of a sterically congested compound J featuring 70 five bulky substituents on a ferrocene. Coordination of this

2 | Journal Name, [year], [vol], 00-00
This journal is © The Royal Society of Chemistry [year] diphosphine-borane to platinum is described. The conformations of the free (P, P, B)-ambiphilic ligand (Figure 2) and of its platinum complex are discussed based on X-ray crystallographic data, along with their multi-nuclear NMR properties, in particular 5 with respect to "through-space" nuclear spin-spin couplings. Solutions of the 4-tert-butyl-1,2-bis(diphenylphosphino)-10 cyclopentadienide lithium salt 1 (a well-known and useful precursor for polyphosphino-ferrocenes such as H) 12 and 3-tertbutyl-1-dimesitylborylcyclopentadienide lithium salt 2 (used to prepare 1,1'-diboryl-metallocenes I) 14,[START_REF] Herberich | For pioneering work on non-substituted borylcyclopentadienides[END_REF] in tetrahydrofuran were successively added to FeCl 2 at -50°C (Fig. 2). Conditions were 15 varied, but a mixture of ferrocenes was systematically formed. † Nevertheless, this route gave direct access to the targeted 1,2diphosphino-1'-boryl-ferrocene 3 ferrocene in a reasonable 32% isolated yield. Simple work-up followed by crystallization afforded 3 as a purple air-stable crystalline powder. The structure 20 of 3 was analysed by X-ray diffraction (Figure 3, racemate, centrosymmetric space group P21/n). The diphosphine-borane 3, bearing five bulky groups on the 35 ferrocene backbone, is among the most hindered polyfunctionalized ferrocenes reported to date. 5,12,16 To optimize the spatial distribution of the substituents, sterically hindered ferrocenes classically adopt a staggered 12a,c,d or an eclipsed 12b conformation. In compound 3, the two cyclopentadienyl (Cp)

40 rings are about eclipsed with a cisoid arrangement of the two tert-butyl groups. Steric congestion also induces some tilting of the two Cp rings that are not exactly parallel [tilt ang. = 10.21( 13) °]. With this conformation, the three heteroatoms are oriented in the same direction, opposite to the tert-butyl groups. The two 45 phosphorus atoms are in quite different environments, the one referred as P2 sitting closer to boron. The P2-C2-Ct1 bond angle deviates from linearity by ca. 11° (Fig. 3 and Fig. S1) [START_REF]The boron center noticeably deviates out the plane of the Cp ring [B-C(6)-Ct(2)[END_REF] but this distortion does not result in intramolecular P→B interaction. The boron atom is in trigonal planar environment [sum of bond angles 50 of 359.1(2) °], and the P2…B is long at 4.239(2) Å. This value falls in the low range of those observed in related monophosphino-boryl-ferrocenes [P…B distances ranging from 4.106(3) to 6.731(3) Å]. 4,5 It is also noteworthy that the orientation of the lone pairs at P1 and P2 differs from that usually 55 encountered in sterically congested 1,2-diphosphino-ferrocenes. 12 Indeed, the P lone pairs typically point to each other in a conformation prone to the chelating coordination of transition metals, and to the existence of strong through-space J PP coupling ( TS J PP , see below). 13 In the diphosphino-boryl-ferrocene 3, the 60 lone pair at P1 points towards P2, while the P2 lone pair is oriented outwards making an angle of 45° with the P2-B axis.

Given this conformation and the steric congestion of the ferrocene backbone, we were intrigued about the coordination properties of the diphosphino-boryl-ferrocene 3. Are the two 65 phosphorus atoms accessible enough and does the framework retains enough conformational freedom for 3 to behave as a chelating ligand? To address these questions, 3 was reacted with PtCl 2 (COD). The platinum complex 4 was thereby obtained in quantitative yield (Figure 4). 7) Å] and sits far from the Pt coordination sphere. The Lewis acid moiety does not interact with the metal center, as observed in previously reported diphosphine-borane Pt complexes, 10,18 but remains pendant. 18); P2-Ct1-90 Ct2-B = -72.14 (18); B … P1 = 6.555 (7); B … P2 = 5.294 (7).

The difference in energy between the conformations of 1,2diphosphino-1'-boryl-ferrocene in the free ligand 3 and in the Pt complex 4 was assessed by DFT. † Accordingly, rotating the P2 lone pair to enable chelation of platinum (conformation 3*, see 5 ESI) was found to cost in energy about 2.6 kcal mol -1 .

Polyphosphino-ferrocenes featuring proximal phosphorus atoms such as triphosphine H (Fig. 2) display rather strong nuclear spin couplings operating "through-space" (TS). 12,13 This non-classical coupling prompted us to have a closer look at the 10 NMR features of the diphosphine-borane 3 and of its platinum complex 4. The 31 P NMR spectrum of diphosphine-borane 3 in CDCl 3 solution exhibits two signals, consistent with two inequivalent phosphorus atoms, but in a puzzling pattern. As depicted in Figure 5, an apparent doublet is found at -23.8 ppm (J 15 = 60 Hz), which is attributed to the phosphorus atom P1 by comparison with analogous trifunctionalized polyphosphinoferrocenes. 12 The second phosphorus P2 is characterized by a broad signal at -18.2 ppm with a width at half-height of 167 Hz.

To confirm the existence of spin coupling, the 31 P NMR spectrum The magnitude of the J P1P2 coupling is clearly very strong for a covalent "through-bond" (TB) 3 J coupling, suggesting some 30 "through-space" (TS) spin coupling, in line with the relatively short internuclear distance d(P1…P2) = 3.871(2) Å observed in the XRD of 3. [START_REF]For a consistent correlation between "geometric parameters" and "through-space" nucleus spin-couplings[END_REF] The contribution of a J "through-space" component was further supported by the solvent-dependence of the J P1P2 coupling noticed when replacing chloroform for toluene 35 (from 60 to 44 Hz, see Fig. S2). TS couplings have been authenticated in various types of constrained molecules, 13,20 including functionalized ferrocenes, and the pathways for such spin-spin couplings have been analysed theoretically. 21 The J P1P2 coupling displayed by 3 falls in the lower range of those reported 40 for polyphosphino-ferrocenes, 12c where couplings as high as 98 Hz have been found, 12b while values up to 180 have been predicted for model compounds such as cis-(H 2 P)CH=CH(PH 2 ). 21a The origin of the P2 signal broadness was intriguing, and 31 P 45 NMR analysis of 3 in the range 325-220 K (Fig. S3) did not evidence major changes of the two 31 P NMR signals in terms of chemical shift and TS J P1P2 coupling (60 ± 3 Hz). The coupling became apparent at P2 below 260 K, but the signal remained broad ( 1/2 = 80-170 Hz). This variable-temperature analysis 50 ruled out the hypothesis of an equilibrium between open and closed forms as the result of an intramolecular P→B interaction.

Such a dynamic phenomenon was reported by Erker et al. for the 1-PMes 2 -2-(CH 2 ) 2 B(C 6 F 5 ) 2 ]-ferrocene D. 8a In compound D, the closed form dominated at low temperature with a 31 P NMR signal 55 shifted downfield by ca. 40 ppm compared to the open form. Steric congestion and conformational restraints are likely to contribute to the broadness of the P2 NMR signal. Indeed, hindered rotation around the Fc-B bond of 3 was apparent from the inequivalence of the mesityl groups at boron in the 1 H NMR 60 spectrum (Fig. S4). Comparison with a less sterically congested diphosphino-boryl-ferrocene 3' (Fig. 2) featuring a B(i-Pr) 2 instead of BMes 2 group, corroborated this view. In this case, a sharp 31 P NMR signal was conversely observed for P2. † Since the lone pair of P2 points towards the vicinity of the 65 boron atom, we wondered about the existence of non-bonding 31 P-11 B nuclear spin coupling which might also contribute to broaden the P2 NMR signal. [START_REF] Ts | NMR owing to nuclear spin coupling and[END_REF] In the absence of visible 11 B signal, [START_REF] Bouhadir | It is not uncommon that 11 B NMR signals are hardly detected for tricoordinate boron species[END_REF] a series of 31 P{ 1 H, 11 B} spectra were recorded by varying the 11 B decoupling frequency from +100 to -100 ppm 70 (Fig. S5). These decoupling experiments did not result in any sharpening of the P2 NMR signal, discarding the hypothesis of TS 31 P-11 B spin coupling in 3. Also noteworthy is the modification of the 31 P NMR spectrum upon coordination of 3 to platinum (Figure 6). Consistent with 75 the crystallographic structure of 4, the eclipsed conformation of the ferrocene backbone together with the cis-chelation of the two PPh 2 groups to platinum places the BMes 2 moiety further away from P2. Accordingly, complex 4 displays two well-resolved 31 P NMR signals at close chemical shifts (22.0 and 21.6 ppm). The 80 J P1P2 spin-spin coupling constant is very much decreased (12.0 Hz for 4), as expected from the quaternization of the phosphorus atoms that no longer allows lone pair-conveyed spin-spin interaction. In conclusion, the diphosphine-borane 3, a new type of tritopic ferrocene, was prepared by reacting functionalized cyclopentadienides with FeCl 2 . The presence of five sterically demanding substituents, including a BMes 2 moiety, on the ferrocene core induces conformational constraints, but does not 95 prevent chelating coordination of the two phosphorus atoms to platinum to give complex 4. The presence of "through-space"

4 | Journal Name, [year], [vol], 00-00
This journal is © The Royal Society of Chemistry [year] spin nuclear couplings in these (P, P', B)-functionalized ferrocenes has been analysed. Future work will seek to generalize this assembling approach to other densely functionalized ferrocene-based ambiphilic compounds with the ultimate goal of 5 triggering reactivity and ligand behaviour thanks to the redoxproperties of the ferrocene moiety. 4b,25 This work was supported by the ANR (ANR-11-INTB-1008 MENOLEP), CNRS, Université de Bourgogne, Université de Toulouse, Conseil Régional de Bourgogne through the plan 10 d'actions régional pour l'innovation (PARI-3MIM and PARI-CDEA) and the fonds européen de développement regional (FEDER) programs. Calculations were performed using HPC resources from DNUM CCUB (Centre de Calcul de l'Université de Bourgogne).

15 Notes and References

Fig. 1

 1 Fig.1Selected ferrocene-based (di)phosphine-boranes, poly-phosphines and poly-boranes.

Fig. 3

 3 Fig. 3 Molecular views of the 1,2-diphosphino-1'-boryl-ferrocene 3 (top 25 and side views, thermal ellipsoids at 50% probability, Ct1 = C1-C2-C3-C4-C5 and Ct2 = C6-C7-C8-C9-C10 centroids). Hydrogen atoms omitted for clarity. Selected bond length (Å) and angles, torsions (°): Fe-Ct1 = 1.6645(10); Fe-Ct2 = 1.6816(10); P1-C1 = 1.827(2); P2-C2 = 1.824(2); B-C6 = 1.545(3); Ct1-Fe-Ct2 = 173.87(5); P1-C1-Ct1 = 179.46(15); P2-30 C2-Ct1 = 168.56(16); B-C6-Ct2 = 166.42(19); P1-Ct1-Ct2-B = -120.62(6); P2-<Ct1-Ct2-B = -41.76(6); B … P1 = 6.132(2); B … P2 = 4.239(2). Bottom right: P-lone pairs (green) visualized by ELF analysis.

  Despite the conformational 70 restrictions imposed by the five sterically demanding substituents, compound 3 preserves enough conformational flexibility to enable rotation around the Cp-P2 bond, allowing the chelating coordination of phosphorus P1/P2 to platinum. The two Cp rings are quasi perfectly eclipsed in 4 [the dihedral angle 75 P2…Ct1…Ct2…B = -72.14(18) °]. The boron center shifts further away from P2 [P2…B = 5.294(

  Synthesis and molecular structure of the 1,2-diphosphino-1'-borylferrocene platinum dichloride complex 4. Thermal ellipsoids at 50% probability, same numbering as for 3. Hydrogen atoms and dichloromethane molecules omitted for clarity. Selected bond length (Å) and angles, torsions (°): Fe-Ct1 = 1.670(3); Fe-Ct2 = 1.689(3); P1-C1 = 85 1.802(6); P2-C2 = 1.783(6); B-C6=1.562(9); P1-Pt = 2.2185(15) ; P2-Pt = 2.2406(15) ; Pt-Cl1 = 2.3587(15); Pt-Cl2 = 2.3387(14); Ct1-Fe-Ct2 = 177.71(14); P1-C1-Ct1 = 170.6(5); P2-C2-Ct1 = 168.8(5); B-C6-Ct2 = 155.9(6); Cl2-Pt-Cl1 = 88.60(5); Cl1-Pt-P1 = 92.41(5); P1-Pt-P2 = 85.47(5); P2-Pt-Cl2 = 93.21(5); P1-Ct1-Ct2-B = -132.64(

  20 was recorded at various frequencies(243, 202 and 121 MHz).The same value of J = 60 Hz was retained for P1. The signal for P2 remained broad but the 60 Hz coupling became distinguishable at low frequency (Fig.5, bottom). 25 Fig. 5. 31 P NMR of the diphosphino-boryl-ferrocene 3 in CDCl 3 at 243, 202 and 121 MHz (CDCl 3 , 300 K).

  Institut de Chimie Moléculaire de l'Université de Bourgogne (ICMUB-UMR CNRS 6302), Université de Bourgogne Franche-Comté, 9, avenue Alain Savary, 21078 Dijon, France ; b Laboratoire Hétérochimie Fondamentale et Appliquée (UMR 5069), Université de Toulouse, CNRS, 20 118 route de Narbonne, 31062 Toulouse cedex 9, France. c Institut de Chimie de Toulouse (FR 2599). 118 Route de Narbonne, 31062 Toulouse Cedex 09 (France) ; d Institut Universitaire de France (IUF), 103, Boulevard Saint Michel, 75005 Paris Cedex, France †Electronic Supplementary Information (ESI) available: Experimental 25 details and analytical data, NMR data and X-ray crystallographic data. CCDC 1902394 (3) and 1902395 (4). Computational details, ELF and AIM analysis, relative energy for conformers 3 and 3* (Figs. S6-S8). For ESI and crystallographic data in CIF or other electronic format see DOI: 10.1039/x0xx00000x

a

Published on 04 July 2019. Downloaded by INIST -CNRS on 7/5/2019 12:26:32 PM. View Article Online DOI: 10.1039/C9DT01921A

Dalton